From xen-devel-bounces@lists.xensource.com Thu Dec 01 02:09:31 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 02: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.xensource.com>)
	id 1RVw4w-0005JH-9g; Thu, 01 Dec 2011 02:08:50 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <henanwxr@hotmail.com>) id 1RVw4u-00041K-1c
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 02:08:48 +0000
X-Env-Sender: henanwxr@hotmail.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1322705287!5680033!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.1 required=7.0 tests=FORGED_HOTMAIL_RCVD,
	ML_RADAR_SPEW_LINKS_14,spamassassin: 
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26759 invoked from network); 1 Dec 2011 02:08:08 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-6.tower-216.messagelabs.com with AES256-SHA encrypted SMTP;
	1 Dec 2011 02:08:08 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <henanwxr@hotmail.com>) id 1RVw4E-0008Hx-W0
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 18:08:06 -0800
Date: Wed, 30 Nov 2011 18:08:06 -0800 (PST)
From: confucius <henanwxr@hotmail.com>
To: xen-devel@lists.xensource.com
Message-ID: <1322705286985-5037367.post@n5.nabble.com>
MIME-Version: 1.0
Subject: [Xen-devel] How does vmm get all mmio areas of pci devices?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi, any one help? I have puzzled by the question of device's MMIO areas. I
know a MMIO operation of guest os  handled by VMM as follow steps:

1: Qemu-dm does its initialization and presents virtual devices for guest
os.
2: virtual bios executes PCI_setup, it will scan the pci bus and get
configure space of all devices,then virtual bios allocation system
resources(like port I/O range,MMIO range, interrupt) for device.
3: I think in this step vmm will get all  mmio range that in step 2, then
vmm will set ept entry which can cause ept  violation when guest os attemp
to access corresponding MMIO ares.
4: In ept violation exit, vmm will pass mmio operation to qemu-dm.
5: Qemu-dm do mmio operation with its callback functions, if qemu-dm could
not find (or register) callback function for some MMIO ares(for example, in
DMA write process ,the targe physical address is not stationary but
determined by guest os's driver,then when qemu-dm find no callback for DMA
target address, it will pass the  content of write  operation to vmm  by
default, vmm then pass the result into the space of guest os).

what I want to know is step2 and step5:
In step2, how does vmm get all mmio areas of devices? and how vmm set ept
entry with these mmio areas ?
In setp5, is it ture for DMA operatin I described? and when qemu-dm find no
callback function for some MMIO area, what it will do?

Thanks for your help.

--
View this message in context: http://xen.1045712.n5.nabble.com/How-does-vmm-get-all-mmio-areas-of-pci-devices-tp5037367p5037367.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 02:09:31 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 02: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.xensource.com>)
	id 1RVw4w-0005JH-9g; Thu, 01 Dec 2011 02:08:50 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <henanwxr@hotmail.com>) id 1RVw4u-00041K-1c
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 02:08:48 +0000
X-Env-Sender: henanwxr@hotmail.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1322705287!5680033!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.1 required=7.0 tests=FORGED_HOTMAIL_RCVD,
	ML_RADAR_SPEW_LINKS_14,spamassassin: 
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26759 invoked from network); 1 Dec 2011 02:08:08 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-6.tower-216.messagelabs.com with AES256-SHA encrypted SMTP;
	1 Dec 2011 02:08:08 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <henanwxr@hotmail.com>) id 1RVw4E-0008Hx-W0
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 18:08:06 -0800
Date: Wed, 30 Nov 2011 18:08:06 -0800 (PST)
From: confucius <henanwxr@hotmail.com>
To: xen-devel@lists.xensource.com
Message-ID: <1322705286985-5037367.post@n5.nabble.com>
MIME-Version: 1.0
Subject: [Xen-devel] How does vmm get all mmio areas of pci devices?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi, any one help? I have puzzled by the question of device's MMIO areas. I
know a MMIO operation of guest os  handled by VMM as follow steps:

1: Qemu-dm does its initialization and presents virtual devices for guest
os.
2: virtual bios executes PCI_setup, it will scan the pci bus and get
configure space of all devices,then virtual bios allocation system
resources(like port I/O range,MMIO range, interrupt) for device.
3: I think in this step vmm will get all  mmio range that in step 2, then
vmm will set ept entry which can cause ept  violation when guest os attemp
to access corresponding MMIO ares.
4: In ept violation exit, vmm will pass mmio operation to qemu-dm.
5: Qemu-dm do mmio operation with its callback functions, if qemu-dm could
not find (or register) callback function for some MMIO ares(for example, in
DMA write process ,the targe physical address is not stationary but
determined by guest os's driver,then when qemu-dm find no callback for DMA
target address, it will pass the  content of write  operation to vmm  by
default, vmm then pass the result into the space of guest os).

what I want to know is step2 and step5:
In step2, how does vmm get all mmio areas of devices? and how vmm set ept
entry with these mmio areas ?
In setp5, is it ture for DMA operatin I described? and when qemu-dm find no
callback function for some MMIO area, what it will do?

Thanks for your help.

--
View this message in context: http://xen.1045712.n5.nabble.com/How-does-vmm-get-all-mmio-areas-of-pci-devices-tp5037367p5037367.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 02:42:29 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 02:42:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVwat-0003ok-8A; Thu, 01 Dec 2011 02:41:51 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RVwar-0003of-5Y
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 02:41:49 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1322707248!43100303!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTM2Mw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6828 invoked from network); 1 Dec 2011 02:40:48 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 02:40:48 -0000
X-IronPort-AV: E=Sophos;i="4.71,275,1320624000"; 
   d="scan'208";a="9219597"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Dec 2011 02:41:13 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 1 Dec 2011 02:41:13 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RVwaH-0007TD-Hs;
	Thu, 01 Dec 2011 02:41:13 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RVwaH-0003Iv-HM;
	Thu, 01 Dec 2011 02:41:13 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10195-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 1 Dec 2011 02:41:13 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10195: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

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

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-win         14 guest-start.2               fail pass in 10192
 test-amd64-amd64-xl-sedf     11 guest-localmigrate fail in 10192 pass in 10195

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install          fail never pass
 test-amd64-i386-xl-win7-amd64  7 windows-install              fail  never pass
 test-amd64-i386-xend-winxpsp3  7 windows-install              fail  never pass
 test-amd64-amd64-xl-win7-amd64  7 windows-install              fail never pass
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   never pass
 test-i386-i386-xl-winxpsp3    7 windows-install              fail   never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-i386-i386-win           14 guest-start.2         fail in 10192 like 10190
 test-amd64-amd64-win         16 leak-check/check      fail in 10192 never pass

version targeted for testing:
 xen                  3c4c29899d8a
baseline version:
 xen                  64088ba60263

------------------------------------------------------------
People who touched revisions under test:
  George Dunlap <george.dunlap@eu.citrix.com>
  Haitao Shan <maillists.shan@gmail.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
------------------------------------------------------------

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


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

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

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


Pushing revision :

+ branch=xen-unstable
+ revision=3c4c29899d8a
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-unstable 3c4c29899d8a
+ branch=xen-unstable
+ revision=3c4c29899d8a
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ : xen@xenbits.xensource.com
+ : xen@xenbits.xensource.com:git/linux-pvops
+ : master
+ : tested/2.6.39.x
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r 3c4c29899d8a ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 10 changesets with 26 changes to 18 files

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 02:42:29 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 02:42:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVwat-0003ok-8A; Thu, 01 Dec 2011 02:41:51 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RVwar-0003of-5Y
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 02:41:49 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1322707248!43100303!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTM2Mw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6828 invoked from network); 1 Dec 2011 02:40:48 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 02:40:48 -0000
X-IronPort-AV: E=Sophos;i="4.71,275,1320624000"; 
   d="scan'208";a="9219597"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Dec 2011 02:41:13 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 1 Dec 2011 02:41:13 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RVwaH-0007TD-Hs;
	Thu, 01 Dec 2011 02:41:13 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RVwaH-0003Iv-HM;
	Thu, 01 Dec 2011 02:41:13 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10195-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 1 Dec 2011 02:41:13 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10195: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

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

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-win         14 guest-start.2               fail pass in 10192
 test-amd64-amd64-xl-sedf     11 guest-localmigrate fail in 10192 pass in 10195

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install          fail never pass
 test-amd64-i386-xl-win7-amd64  7 windows-install              fail  never pass
 test-amd64-i386-xend-winxpsp3  7 windows-install              fail  never pass
 test-amd64-amd64-xl-win7-amd64  7 windows-install              fail never pass
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   never pass
 test-i386-i386-xl-winxpsp3    7 windows-install              fail   never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-i386-i386-win           14 guest-start.2         fail in 10192 like 10190
 test-amd64-amd64-win         16 leak-check/check      fail in 10192 never pass

version targeted for testing:
 xen                  3c4c29899d8a
baseline version:
 xen                  64088ba60263

------------------------------------------------------------
People who touched revisions under test:
  George Dunlap <george.dunlap@eu.citrix.com>
  Haitao Shan <maillists.shan@gmail.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
------------------------------------------------------------

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


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

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

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


Pushing revision :

+ branch=xen-unstable
+ revision=3c4c29899d8a
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-unstable 3c4c29899d8a
+ branch=xen-unstable
+ revision=3c4c29899d8a
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ : xen@xenbits.xensource.com
+ : xen@xenbits.xensource.com:git/linux-pvops
+ : master
+ : tested/2.6.39.x
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r 3c4c29899d8a ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 10 changesets with 26 changes to 18 files

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 03:01:50 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 03:01:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVwti-0004Nb-3r; Thu, 01 Dec 2011 03:01:18 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <horms@verge.net.au>) id 1RVwtf-0004NW-Uq
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 03:01:16 +0000
X-Env-Sender: horms@verge.net.au
X-Msg-Ref: server-6.tower-216.messagelabs.com!1322708434!5682879!1
X-Originating-IP: [202.4.237.240]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26663 invoked from network); 1 Dec 2011 03:00:35 -0000
Received: from kirsty.vergenet.net (HELO kirsty.vergenet.net) (202.4.237.240)
	by server-6.tower-216.messagelabs.com with SMTP;
	1 Dec 2011 03:00:35 -0000
Received: from joe.kanocho.kobe.vergenet.net (joe.isobedori.kobe.vergenet.net
	[IPv6:2001:470:4832:303:1ec1:deff:fe98:754d])
	by kirsty.vergenet.net (Postfix) with ESMTP id D0CAB25BF17;
	Thu,  1 Dec 2011 14:00:31 +1100 (EST)
Received: by joe.kanocho.kobe.vergenet.net (Postfix, from userid 7100)
	id E83AA574001; Thu,  1 Dec 2011 12:00:29 +0900 (JST)
Date: Thu, 1 Dec 2011 12:00:29 +0900
From: Simon Horman <horms@verge.net.au>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <20111201030029.GL16125@verge.net.au>
References: <4ED399A7.1070108@citrix.com> <CAF9A2A8.25D24%keir.xen@gmail.com>
	<20111129055139.GB3222@verge.net.au> <4ED4B8C0.20108@citrix.com>
	<4ED4D1A90200007800064095@nat28.tlf.novell.com>
	<4ED4D5F1.2080000@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4ED4D5F1.2080000@citrix.com>
Organisation: Horms Solutions Ltd.
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Keir Fraser <keir.xen@gmail.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] Unaligned writes on the kexec path
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Nov 29, 2011 at 12:54:09PM +0000, Andrew Cooper wrote:
> On 29/11/11 11:35, Jan Beulich wrote:
> >>>> On 29.11.11 at 11:49, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
> >> On 29/11/11 05:51, Simon Horman wrote:
> >>> Hi Keir, Hi Andrew,
> >>>
> >>> On Mon, Nov 28, 2011 at 08:42:16PM +0000, Keir Fraser wrote:
> >>>> On 28/11/2011 14:24, "Andrew Cooper" <andrew.cooper3@citrix.com> wrote:
> >>>>
> >>>>> Hello,
> >>>>>
> >>>>> In c/s 7493bb48d89f, you change the internals of kexec_crash_save_info()
> >>>> The patch is by Simon Horman, cc'ed, not me.
> >> Right.  Sorry.  I should have remembered that basing "who wrote the
> >> patch" on a simple hg log was not a safe bet.
> > I don't think there's much room for improvement - all members of
> > crash_xen_info_t are of "unsigned long" type, but ELF note handling
> > will only ever guarantee 4-byte alignment.
> >
> > Jan
> >
> Depending on how flexible we want to be, we can either specify that the
> name field should be 2n words long plus 1-4 bytes, which will cause it
> to align to an odd number of 4 bytes, which will cause the desc field to
> be aligned to 8 bytes when the type field in the note header is taken
> into account.  Then, the desc field should be constrained to be (2n+1) +
> 1-4bytes which would cause it to have 8 byte alignment, and subsequently
> 8 byte align the next note.
> 
> Alternatively, we could artificially extend the name up to an odd 4 byte
> alignment, and desc field up to 8 byte alignment with trailing \0's and
> include this as part of their length fields.  All names should be
> processed as Null terminating strings (which wont suffer from having
> extra Nulls at the end) and I have yet to see processing of a note which
> doesn't take the buffer and cast it to a structure pointer.  This also
> wont suffer from from trailing data.
> 
> Then again, this does sound like quite a lot of work for not a lot, and
> there is no guarantee that we wont break some of the more special code
> which works with elf files in 'special' ways.

I believe that the scheme you suggest would work. But elf parsing
does tend to be a bit special. So I lean towards not changing things.

> (What really should have happened was for ELF64 to specify 64bit
> alignment of things like this, but we live and learn)

Agreed.

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 03:01:50 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 03:01:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVwti-0004Nb-3r; Thu, 01 Dec 2011 03:01:18 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <horms@verge.net.au>) id 1RVwtf-0004NW-Uq
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 03:01:16 +0000
X-Env-Sender: horms@verge.net.au
X-Msg-Ref: server-6.tower-216.messagelabs.com!1322708434!5682879!1
X-Originating-IP: [202.4.237.240]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26663 invoked from network); 1 Dec 2011 03:00:35 -0000
Received: from kirsty.vergenet.net (HELO kirsty.vergenet.net) (202.4.237.240)
	by server-6.tower-216.messagelabs.com with SMTP;
	1 Dec 2011 03:00:35 -0000
Received: from joe.kanocho.kobe.vergenet.net (joe.isobedori.kobe.vergenet.net
	[IPv6:2001:470:4832:303:1ec1:deff:fe98:754d])
	by kirsty.vergenet.net (Postfix) with ESMTP id D0CAB25BF17;
	Thu,  1 Dec 2011 14:00:31 +1100 (EST)
Received: by joe.kanocho.kobe.vergenet.net (Postfix, from userid 7100)
	id E83AA574001; Thu,  1 Dec 2011 12:00:29 +0900 (JST)
Date: Thu, 1 Dec 2011 12:00:29 +0900
From: Simon Horman <horms@verge.net.au>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <20111201030029.GL16125@verge.net.au>
References: <4ED399A7.1070108@citrix.com> <CAF9A2A8.25D24%keir.xen@gmail.com>
	<20111129055139.GB3222@verge.net.au> <4ED4B8C0.20108@citrix.com>
	<4ED4D1A90200007800064095@nat28.tlf.novell.com>
	<4ED4D5F1.2080000@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4ED4D5F1.2080000@citrix.com>
Organisation: Horms Solutions Ltd.
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Keir Fraser <keir.xen@gmail.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] Unaligned writes on the kexec path
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Nov 29, 2011 at 12:54:09PM +0000, Andrew Cooper wrote:
> On 29/11/11 11:35, Jan Beulich wrote:
> >>>> On 29.11.11 at 11:49, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
> >> On 29/11/11 05:51, Simon Horman wrote:
> >>> Hi Keir, Hi Andrew,
> >>>
> >>> On Mon, Nov 28, 2011 at 08:42:16PM +0000, Keir Fraser wrote:
> >>>> On 28/11/2011 14:24, "Andrew Cooper" <andrew.cooper3@citrix.com> wrote:
> >>>>
> >>>>> Hello,
> >>>>>
> >>>>> In c/s 7493bb48d89f, you change the internals of kexec_crash_save_info()
> >>>> The patch is by Simon Horman, cc'ed, not me.
> >> Right.  Sorry.  I should have remembered that basing "who wrote the
> >> patch" on a simple hg log was not a safe bet.
> > I don't think there's much room for improvement - all members of
> > crash_xen_info_t are of "unsigned long" type, but ELF note handling
> > will only ever guarantee 4-byte alignment.
> >
> > Jan
> >
> Depending on how flexible we want to be, we can either specify that the
> name field should be 2n words long plus 1-4 bytes, which will cause it
> to align to an odd number of 4 bytes, which will cause the desc field to
> be aligned to 8 bytes when the type field in the note header is taken
> into account.  Then, the desc field should be constrained to be (2n+1) +
> 1-4bytes which would cause it to have 8 byte alignment, and subsequently
> 8 byte align the next note.
> 
> Alternatively, we could artificially extend the name up to an odd 4 byte
> alignment, and desc field up to 8 byte alignment with trailing \0's and
> include this as part of their length fields.  All names should be
> processed as Null terminating strings (which wont suffer from having
> extra Nulls at the end) and I have yet to see processing of a note which
> doesn't take the buffer and cast it to a structure pointer.  This also
> wont suffer from from trailing data.
> 
> Then again, this does sound like quite a lot of work for not a lot, and
> there is no guarantee that we wont break some of the more special code
> which works with elf files in 'special' ways.

I believe that the scheme you suggest would work. But elf parsing
does tend to be a bit special. So I lean towards not changing things.

> (What really should have happened was for ELF64 to specify 64bit
> alignment of things like this, but we live and learn)

Agreed.

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 03:17:25 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 03:17:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVx8i-0004Yc-KP; Thu, 01 Dec 2011 03:16:48 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>)
	id 1RVx8h-0004YU-EZ; Thu, 01 Dec 2011 03:16:47 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-7.tower-174.messagelabs.com!1322709364!3779609!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10207 invoked from network); 1 Dec 2011 03:16:05 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-7.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 1 Dec 2011 03:16:05 -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
	pB13G2VY032315
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Wed, 30 Nov 2011 22:16:02 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pB13G1bk032302;
	Wed, 30 Nov 2011 22:16:01 -0500
Date: Wed, 30 Nov 2011 23:16:01 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Artur Baruchi <mail.baruchi@gmail.com>
Message-ID: <20111201031601.GA32261@andromeda.dapyr.net>
References: <CAAiDW_RNUWUUm7rsgXUMJnc6gnQ7FbEv0eVX-tJQ+PAnjrOmeg@mail.gmail.com>
	<CAAiDW_Trg-B8Bq=sjnedZoxjxi2T+H=ADvuiBdE8jr+B1a5Jgg@mail.gmail.com>
	<20111130221545.GB16651@andromeda.dapyr.net>
	<CAAiDW_T2Eutw=NibLv2s1f1DJsbSY39oHL_pH8RkmAi=iWK0HA@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAAiDW_T2Eutw=NibLv2s1f1DJsbSY39oHL_pH8RkmAi=iWK0HA@mail.gmail.com>
User-Agent: Mutt/1.5.9i
Cc: Xen-devel@lists.xensource.com, xen-users <Xen-users@lists.xensource.com>
Subject: Re: [Xen-devel] VM Hanging after reboot
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Nov 30, 2011 at 09:09:58PM -0200, Artur Baruchi wrote:
> Hi Konrad.
> 
> That was my first though (disk going bad). But I create another VM in
> a different host and faced the same error. I tried to create another

So is the error from within the guest or from the dom0?

> file and use a physical device (logical volume) too, but no lucky. Im
> guessing that it can be:
> 
> - There is a bug in this kernel version or in paravirtualized drivers
> used by opensuse 11.3 (based on some google searchs that I made, with
> similar errors); OR
> - Some configuration problem (for example, need to enable acpi in my
> vm kernel, or anything like this).
> 
> Thanks.
> 
> Att.
> Artur Baruchi
> 
> 
> On Wed, Nov 30, 2011 at 8:15 PM, Konrad Rzeszutek Wilk
> <konrad@darnok.org> wrote:
> > On Wed, Nov 30, 2011 at 04:46:55PM -0200, Artur Baruchi wrote:
> >> I just configured the serial console to see what is going on during
> >> the boot. I tried to run fsck and changed the grub to use the device
> >> path (/dev/sdaX) instead udisks-part-id, but no success.
> >>
> >> Follow the console errors:
> >>
> >
> > That looks like your disk is going bad?
> >
> > Was there anything before this? Like the IRQs not setup properly?
> >
> >> Loading drivers, configuring devices: [ ? 69.701448] ata1.00:
> >> exception Emask 0x0 SAct 0x0 SErr 0x0 act
> >> ?ion 0x6 frozen
> >> [ ? 69.705706] ata1.00: failed command: READ DMA
> >> [ ? 69.708402] ata1.00: cmd c8/00:20:b8:7a:66/00:00:00:00:00/e0 tag 0
> >> dma 16384 in
> >> [ ? 69.708403] ? ? ? ? ?res 40/00:01:00:00:00/00:00:00:00:00/a0 Emask
> >> 0x4 (timeout)
> >> [ ? 69.717358] ata1.00: status: { DRDY }
> >> [ ? 69.872400] ata1.00: revalidation failed (errno=-2)
> >> [ ? 75.023385] ata1.00: revalidation failed (errno=-2)
> >> [ ? 80.174383] ata1.00: revalidation failed (errno=-2)
> >> [ ? 80.329687] end_request: I/O error, dev sda, sector 6716088
> >> [ ? 80.333096] end_request: I/O error, dev sda, sector 6716088
> >> [ ? 80.336676] end_request: I/O error, dev sda, sector 6716088
> >> [ ? 80.340408] end_request: I/O error, dev sda, sector 6145504
> >> [ ? 80.344063] end_request: I/O error, dev sda, sector 6145504
> >> [ ? 80.347465] end_request: I/O error, dev sda, sector 6145504
> >> [ ? 80.351795] end_request: I/O error, dev sda, sector 6145504
> >> [ ? 80.356081] end_request: I/O error, dev sda, sector 6145504
> >> [ ? 80.359587] end_request: I/O error, dev sda, sector 6145504
> >> [ ? 80.363115] end_request: I/O error, dev sda, sector 6145504
> >> [ ? 80.366535] end_request: I/O error, dev sda, sector 6145504
> >> [ ? 80.370034] end_request: I/O error, dev sda, sector 6145504
> >> [ ? 80.373924] end_request: I/O error, dev sda, sector 9979920
> >> [ ? 80.377458] Buffer I/O error on device sda3, logical block 721410
> >> [ ? 80.389108] end_request: I/O error, dev sda, sector 4970504
> >> [ ? 80.392576] end_request: I/O error, dev sda, sector 4970504
> >> [ ? 80.396208] end_request: I/O error, dev sda, sector 11290592
> >> [ ? 80.399747] EXT3-fs error (device sda3): ext3_get_inode_loc: unable
> >> to read inode block - inode=2231 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 26,
> >> block=885244
> >> [ ? 80.406333] end_request: I/O error, dev sda, sector 4208640
> >> [ ? 80.409650] Buffer I/O error on device sda3, logical block 0
> >> udevd-work[1631]: exec of program '/lib/udev/ata_id' failed
> >>
> >> [ ? 80.416228] end_request: I/O error, dev sda, sector 6796224
> >> [ ? 80.419759] end_request: I/O error, dev sda, sector 6796288
> >> [ ? 80.423135] end_request: I/O error, dev sda, sector 6796288
> >> [ ? 80.425117] end_request: I/O error, dev sda, sector 6796288
> >> [ ? 80.427447] end_request: I/O error, dev sda, sector 6796288
> >> [ ? 80.429840] end_request: I/O error, dev sda, sector 6796288
> >> [ ? 80.432094] end_request: I/O error, dev sda, sector 6796288
> >> [ ? 80.434425] end_request: I/O error, dev sda, sector 6796288
> >> [ ? 80.436746] end_request: I/O error, dev sda, sector 6796288
> >> [ ? 80.439043] end_request: I/O error, dev sda, sector 6796288
> >> [ ? 80.441358] end_request: I/O error, dev sda, sector 6796288
> >> [ ? 80.443626] end_request: I/O error, dev sda, sector 6796288
> >> [ ? 80.445864] end_request: I/O error, dev sda, sector 6796288
> >> [ ? 80.448051] end_request: I/O error, dev sda, sector 6796288
> >> [ ? 80.450271] end_request: I/O error, dev sda, sector 6796288
> >> [ ? 80.452482] end_request: I/O error, dev sda, sector 6796288
> >> [ ? 80.454745] end_request: I/O error, dev sda, sector 6796288
> >> [ ? 80.457029] end_request: I/O error, dev sda, sector 6796288
> >> [ ? 80.459299] end_request: I/O error, dev sda, sector 6796288
> >> [ ? 80.461604] end_request: I/O error, dev sda, sector 6796288
> >> [ ? 80.463843] end_request: I/O error, dev sda, sector 6796288
> >> [ ? 80.466045] end_request: I/O error, dev sda, sector 6796288
> >> [ ? 80.468274] end_request: I/O error, dev sda, sector 6796288
> >> [ ? 80.470510] end_request: I/O error, dev sda, sector 6796288
> >> [ ? 80.472725] end_request: I/O error, dev sda, sector 6796288
> >> [ ? 80.474902] end_request: I/O error, dev sda, sector 6796288
> >> [ ? 80.477103] end_request: I/O error, dev sda, sector 6796288
> >> [ ? 80.479278] end_request: I/O error, dev sda, sector 6796288
> >> [ ? 80.481514] end_request: I/O error, dev sda, sector 6796288
> >> [ ? 80.483647] end_request: I/O error, dev sda, sector 6796288
> >> [ ? 80.485780] end_request: I/O error, dev sda, sector 6796288
> >> [ ? 80.487838] end_request: I/O error, dev sda, sector 6796288
> >> [ ? 80.489897] end_request: I/O error, dev sda, sector 6796224
> >> [ ? 80.491920] end_request: I/O error, dev sda, sector 6796224
> >> [ ? 80.494294] end_request: I/O error, dev sda, sector 4971928
> >> [ ? 80.496445] end_request: I/O error, dev sda, sector 4971928
> >> [ ? 80.498650] end_request: I/O error, dev sda, sector 11290592
> >> [ ? 80.500834] EXT3-fs error (device sda3): ext3_get_inode_loc: unable
> >> to read inode block - inode=2231 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 26,
> >> block=885244
> >> [ ? 80.504930] end_request: I/O error, dev sda, sector 4208640
> >> [ ? 80.507019] Buffer I/O error on device sda3, logical block 0
> >> udevd-work[1632]: exec of program '/lib/udev/scsi_id' failed
> >>
> >> [ ? 80.511028] end_request: I/O error, dev sda, sector 12352272
> >> [ ? 80.513236] Buffer I/O error on device sda3, logical block 1017954
> >> [ ? 80.515677] end_request: I/O error, dev sda, sector 12360888
> >> [ ? 80.518021] Buffer I/O error on device sda3, logical block 1019031
> >> [ ? 80.520527] Buffer I/O error on device sda3, logical block 1019032
> >> [ ? 80.523072] end_request: I/O error, dev sda, sector 9980016
> >> [ ? 80.525394] journal_bmap: journal block not found at offset 12 on sda3
> >> [ ? 80.527956] Aborting journal on device sda3.
> >> [ ? 80.529854] end_request: I/O error, dev sda, sector 9979920
> >> [ ? 80.532119] Buffer I/O error on device sda3, logical block 721410
> >> [ ? 80.534799] end_request: I/O error, dev sda, sector 9979928
> >> [ ? 80.537239] end_request: I/O error, dev sda, sector 9979936
> >> [ ? 80.539639] end_request: I/O error, dev sda, sector 9370632
> >> [ ? 80.542144] end_request: I/O error, dev sda, sector 9370632
> >> [ ? 80.544499] EXT3-fs (sda3): error: ext3_journal_start_sb: Detected
> >> aborted journal
> >> [ ? 80.547659] EXT3-fs (sda3): error: remounting filesystem read-only
> >> [ ? 80.550535] end_request: I/O error, dev sda, sector 11290592
> >> [ ? 80.552989] EXT3-fs error (device sda3): ext3_get_inode_loc: unable
> >> to read inode block - inode=2231 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 26,
> >> block=885244
> >> udevd-work[1634]: exec of program '/sbin/blkid' failed
> >>
> >> [ ? 80.559337] end_request: I/O error, dev sda, sector 4972560
> >> [ ? 80.561964] end_request: I/O error, dev sda, sector 4972560
> >> [ ? 80.564546] end_request: I/O error, dev sda, sector 11290592
> >> [ ? 80.567069] EXT3-fs error (device sda3): ext3_get_inode_loc: unable
> >> to read inode block - inode=2231 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 26,
> >> block=885244
> >> udevd-work[1635]: exec of program '/lib/udev/edd_id' failed
> >>
> >> [ ? 80.576377] end_request: I/O error, dev sda, sector 4952712
> >> [ ? 80.580086] end_request: I/O error, dev sda, sector 4952712
> >> [ ? 80.583689] end_request: I/O error, dev sda, sector 11290592
> >> [ ? 80.586292] EXT3-fs error (device sda3): ext3_get_inode_loc: unable
> >> to read inode block - inode=2231 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 26,
> >> block=885244
> >> udevd-work[1636]: exec of program '/lib/udev/udisks-part-id' failed
> >>
> >> [ ? 80.593995] end_request: I/O error, dev sda, sector 9370632
> >> [ ? 80.596704] end_request: I/O error, dev sda, sector 9370632
> >> [ ? 80.596755] end_request: I/O error, dev sda, sector 11290592
> >> [ ? 80.596760] EXT3-fs error (device sda3): ext3_get_inode_loc: unable
> >> to read inode block - inode=2231 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 26,
> >> block=885244
> >> udevd-work[1637][ ? 80.608632] end_request: I/O error, dev sda, sector 11290592
> >> : exec of program '/sbin/blkid' failed[ ? 80.612951] EXT3-fs error
> >> (device sda3): ext3_get_inode_loc: u
> >> nable to read inode block - inode=223126, block=885244
> >>
> >>
> >> [ ? 80.621449] end_request: I/O error, dev sda, sector 9370632
> >> [ ? 80.624665] end_request: I/O error, dev sda, sector 11290592
> >> [ ? 80.627305] EXT3-fs error (device sda3): ext3_get_inode_loc: unable
> >> to read inode block - inode=2231 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 26,
> >> block=885244
> >> udevd-work[1638]: exec of program '/sbin/blkid' failed
> >>
> >> udevd-work[1639]: exec of program '/sbin/blkid' failed
> >>
> >> [ ? 80.635017] end_request: I/O error, dev sda, sector 4952712
> >> [ ? 80.637899] end_request: I/O error, dev sda, sector 4952712
> >> [ ? 80.637956] end_request: I/O error, dev sda, sector 11290592
> >> [ ? 80.637962] EXT3-fs error (device sda3): ext3_get_inode_loc: unable
> >> to read inode block - inode=2231 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 26,
> >> block=885244
> >> [ ? 80.649954] end_request: I/O error, dev sda, sector 4952712
> >> udevd-work[1640]: exec of program '/lib/udev/udi[ ? 80.649974]
> >> end_request: I/O error, dev sda, sector
> >> 11290592
> >> sks-part-id' failed
> >> [ ? 80.649981] EXT3-fs error (device sda3): ext3_get_inode_loc: unable
> >> to read inode block - inode=2231 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 26,
> >> block=885244
> >>
> >> udevd-work[1641][ ? 80.664921] end_request: I/O error, dev sda, sector 11290592
> >> : exec of program '/lib/udev/udisks-part-id' fai[ ? 80.669088] EXT3-fs
> >> error (device sda3): ext3_get_in
> >> ode_loc: ledunable to read inode block - inode=223126, block=885244
> >>
> >>
> >> udevd-work[1642]: exec of program '/lib/udev/udisks-part-id' failed
> >>
> >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? done
> >> [ ? 80.688649] end_request: I/O error, dev sda, sector 11516760
> >> [ ? 80.693402] end_request: I/O error, dev sda, sector 11517320
> >> [ ? 80.698410] end_request: I/O error, dev sda, sector 11516760
> >> boot.loadmodules: Input/output error
> >> [ ? 80.705752] end_request: I/O error, dev sda, sector 11517320
> >> boot.rootfsck: Input/output error
> >> [ ? 80.712719] end_request: I/O error, dev sda, sector 11516496
> >> [ ? 80.717814] end_request: I/O error, dev sda, sector 11516704
> >> [ ? 80.730101] end_request: I/O error, dev sda, sector 11516496
> >> boot.clock: Input/output error
> >> [ ? 80.736217] end_request: I/O error, dev sda, sector 11516768
> >> [ ? 80.741296] end_request: I/O error, dev sda, sector 11352104
> >> [ ? 80.745949] end_request: I/O error, dev sda, sector 11352104
> >> boot.device-mapper: Input/output error
> >> [ ? 80.753208] end_request: I/O error, dev sda, sector 11516768
> >> boot.localfs: Input/output error
> >> [ ? 80.760052] end_request: I/O error, dev sda, sector 11516488
> >> [ ? 80.764909] end_request: I/O error, dev sda, sector 11499608
> >> [ ? 80.769502] end_request: I/O error, dev sda, sector 11303224
> >> [ ? 80.775085] end_request: I/O error, dev sda, sector 11516744
> >> [ ? 80.779703] end_request: I/O error, dev sda, sector 11517168
> >> [ ? 80.784166] end_request: I/O error, dev sda, sector 11517360
> >> [ ? 80.788596] end_request: I/O error, dev sda, sector 11518640
> >> [ ? 80.793861] end_request: I/O error, dev sda, sector 11518640
> >> [ ? 80.798273] end_request: I/O error, dev sda, sector 11517360
> >> [ ? 80.803364] end_request: I/O error, dev sda, sector 11517176
> >> boot.swap: Input/output error
> >> [ ? 80.809435] end_request: I/O error, dev sda, sector 11517168
> >> boot.proc: Input/output error
> >> [ ? 80.815339] end_request: I/O error, dev sda, sector 11516488
> >> boot.localnet: Input/output error[ ? 80.820846] end_request: I/O
> >> error, dev sda, sector 11516744
> >> [ ? 80.825458] end_request: I/O error, dev sda, sector 11499608
> >> [ ? 80.829771] end_request: I/O error, dev sda, sector 11303224
> >> [ ? 80.834086] end_request: I/O error, dev sda, sector 11516752
> >>
> >> boot.cleanup: In[ ? 80.838667] end_request: I/O error, dev sda, sector 11518160
> >> put/output error[ ? 80.843568] end_request: I/O error, dev sda, sector 11516752
> >>
> >> [ ? 80.847792] end_request: I/O error, dev sda, sector 11518160
> >> boot.cycle: Input/output error[ ? 80.853141] end_request: I/O error,
> >> dev sda, sector 11417656
> >>
> >> [ ? 80.853840] end_request: I/O error, dev sda, sector 11417656
> >> boot.fuse: Input/output error
> >> boot.klog: Input/output error
> >> boot.sysctl: Input/output error
> >> [ ? 80.865148] end_request: I/O error, dev sda, sector 11516712
> >> [ ? 80.865199] end_request: I/O error, dev sda, sector 11516712
> >> boot.ldconfig: Input/output error
> >> boot.udev_retry: Input/output error
> >> boot.apparmor: Input/output error
> >> boot.ipconfig: Input/output error
> >> System Boot Control: The system has been ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?set up
> >> Failed features: boot.loadmodules boot.rootfsck boot.clock
> >> boot.device-mapper boot.localfs boot.cleanup
> >> ? ? ?boot.cycle boot.fuse boot.klog boot.localnet boot.proc boot.swap
> >> boot.sysctl boot.ldconfig boot.udev_r
> >> etry boot.apparmor boot.ipconfig
> >> System Boot Control: Running /etc/init.d/boot.local
> >> [ ? 80.890020] end_request: I/O error, dev sda, sector 11540760
> >> [ ? 80.892185] end_request: I/O error, dev sda, sector 11540760
> >> /etc/init.d/boot.local: /etc/init.d/boot.local: Input/output error ? ?failed
> >> [ ? 80.897735] end_request: I/O error, dev sda, sector 9369944
> >> [ ? 80.900025] end_request: I/O error, dev sda, sector 9369944
> >> [ ? 80.902265] end_request: I/O error, dev sda, sector 9369944
> >> /etc/init.d/boot: line 314: /sbin/killproc: Input/output error
> >> /etc/init.d/boot: line 326: /var/run/no_blogd: Read-only file system
> >> [ ? 80.909885] end_request: I/O error, dev sda, sector 12335128
> >> [ ? 80.913314] EXT3-fs error (device sda3): ext3_get_inode_loc: unable
> >> to read inode block - inode=2539 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 69,
> >> block=1015811
> >> [ ? 80.920333] end_request: I/O error, dev sda, sector 12335128
> >> [ ? 80.923922] EXT3-fs error (device sda3): ext3_get_inode_loc: unable
> >> to read inode block - inode=2539 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 69,
> >> block=1015811
> >> [ ? 80.931552] end_request: I/O error, dev sda, sector 12335128
> >> [ ? 80.935604] EXT3-fs error (device sda3): ext3_get_inode_loc: unable
> >> to read inode block - inode=2539 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 69,
> >> block=1015811
> >> [ ? 80.944776] end_request: I/O error, dev sda, sector 11290592
> >> [ ? 80.948819] EXT3-fs error (device sda3): ext3_get_inode_loc: unable
> >> to read inode block - inode=2231 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 26,
> >> block=885244
> >> INIT: Entering runlevel: 3
> >> [ ? 80.965451] end_request: I/O error, dev sda, sector 11519720
> >> [ ? 80.969737] end_request: I/O error, dev sda, sector 11519720
> >> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
> >> [ ? 80.980514] end_request: I/O error, dev sda, sector 11519720
> >> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error[
> >> 80.987414] end_request: I/O erro ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? r, dev
> >> sda, sector 11519720
> >>
> >> [ ? 80.991743] end_request: I/O error, dev sda, sector 11519720
> >> /etc/initscript:[ ? 80.996145] end_request: I/O error, dev sda, sector 11519720
> >> ?line 77: /etc/sysconfig/ulimit: Input/output error
> >> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
> >> /etc/initscript: line 77: /etc/s[ ? 81.005996] end_request: I/O error,
> >> dev sda, sector 11519720
> >> ysconfig/ulimit: Input/output er[ ? 81.010510] end_request: I/O error,
> >> dev sda, sector 11519720
> >> ror[ ? 81.016077] end_request: I/O error, dev sda, sector 11519720
> >>
> >> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error[
> >> 81.022320] end_request: I/O erro ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? r, dev
> >> sda, sector 11519720
> >>
> >> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
> >> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
> >> /etc/initscript:[ ? 81.030711] end_request: I/O error, dev sda, sector 11519720
> >> ?line 77: /etc/sysconfig/ulimit:[ ? 81.035523] end_request: I/O error,
> >> dev sda, sector 11519720
> >> ?Input/output error
> >> /etc/initscript:[ ? 81.043077] end_request: I/O error, dev sda, sector 11519720
> >> ?line 77: /etc/sysconfig/ulimit:[ ? 81.047889] end_request: I/O error,
> >> dev sda, sector 11519720
> >> ?Input/output error[ ? 81.052231] end_request: I/O error, dev sda,
> >> sector 11519720
> >>
> >> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
> >> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
> >> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/outp[
> >> 81.062739] end_request: I/O error, dev s
> >> da, sector 11519720
> >> ut error
> >> [ ? 81.066952] end_request: I/O error, dev sda, sector 11519720
> >> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
> >> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
> >> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
> >> [ ? 81.081287] end_request: I/O error, dev sda, sector 11519720
> >> /etc/initscript: line 77: /etc/sysconfig/ulimit:[ ? 81.087077]
> >> end_request: I/O error, dev sda, sector
> >> 11519720
> >> ?Input/output error
> >> [ ? 81.092828] end_request: I/O error, dev sda, sector 11519720
> >> [ ? 81.097171] end_request: I/O error, dev sda, sector 11519720
> >> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
> >> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output er[
> >> 81.105199] end_request: I/O error, ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?dev
> >> sda, sector 11519720
> >> ror
> >> /etc/initscript: line 77: /[ ? 81.109861] end_request: I/O error, dev
> >> sda, sector 11519720
> >> etc/sysconfig/ulimit: Input/output error
> >> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input[ ? 81.116079]
> >> end_request: I/O error, dev sda, s ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ector
> >> 11519720
> >> /output error
> >> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
> >> /etc/initscript: line 77: /etc/sysconfig/uli[ ? 81.123656]
> >> end_request: I/O error, dev sda, sector 1151
> >> ? ? 9720
> >> mit: Input/output error
> >> [ ? 81.131077] end_request: I/O error, dev sda, sector 11519720
> >> /etc/initscript:[ ? 81.135256] end_request: I/O error, dev sda, sector 11519720
> >> ?line 77: /etc/sysconfig/ulimit: Input/output error
> >> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
> >> [ ? 81.145043] end_request: I/O error, dev sda, sector 11519720
> >> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error[
> >> 81.151102] end_request: I/O erro ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? r, dev
> >> sda, sector 11519720
> >>
> >> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
> >> /etc/initscript:[ ? 81.158246] end_request: I/O error, dev sda, sector 11519720
> >> ?line 77: /etc/sysconfig/ulimit: Input/output error[ ? 81.163908]
> >> end_request: I/O error, dev sda, sect ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? or
> >> 11519720
> >>
> >> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
> >> /etc/initscript:[ ? 81.170077] end_request: I/O error, dev sda, sector 11519720
> >> ?line 77: /etc/sysconfig/ulimit: Input/output error
> >> [ ? 81.175614] end_request: I/O error, dev sda, sector 11519720
> >> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error[
> >> 81.181692] end_request: I/O erro ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? r, dev
> >> sda, sector 11519720
> >>
> >> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
> >> [ ? 81.188834] end_request: I/O error, dev sda, sector 11519720
> >> [ ? 81.193074] end_request: I/O error, dev sda, sector 11519720
> >> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
> >> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
> >> /etc/initscript: line 77: /etc/sysconfig/ul[ ? 81.202959] end_request:
> >> I/O error, dev sda, sector 11519 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 720
> >> imit: Input/output error
> >> [ ? 81.209078] end_request: I/O error, dev sda, sector 11519720
> >> [ ? 81.215046] end_request: I/O error, dev sda, sector 11519720
> >> /etc/initscript: line 77: /etc/sysconfig/ulimit:[ ? 81.220029]
> >> end_request: I/O error, dev sda, sector
> >> 11519720
> >> ?Input/output error
> >> /etc/initscript:[ ? 81.224860] end_request: I/O error, dev sda, sector 11519720
> >> ?line 77: /etc/sysconfig/ulimit: Input/output error[ ? 81.230950]
> >> end_request: I/O error, dev sda, sect ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? or
> >> 11519720
> >>
> >> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
> >> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
> >> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
> >> [ ? 81.241445] end_request: I/O error, dev sda, sector 11519720
> >> [ ? 81.245133] end_request: I/O error, dev sda, sector 11519720
> >> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
> >> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error[
> >> 81.253519] end_request: I/O erro ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? r, dev
> >> sda, sector 11519720
> >>
> >> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output er[
> >> 81.259342] end_request: I/O error, ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?dev
> >> sda, sector 11519720
> >> ror
> >> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/outp[
> >> 81.265077] end_request: I/O error, dev s
> >> da, sector 11519720
> >> ut error
> >> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
> >> /etc/initscript: line 77: /etc/sy[ ? 81.271786] end_request: I/O
> >> error, dev sda, sector 11519720
> >> sconfig/ulimit: Input/output error
> >> [ ? 81.277066] end_request: I/O error, dev sda, sector 11519720
> >> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
> >> [ ? 81.284078] end_request: I/O error, dev sda, sector 11519720
> >> [ ? 81.287740] end_request: I/O error, dev sda, sector 11519720
> >> /etc/initscript: line 77: /etc/sysconfig/ulimit:[ ? 81.292708]
> >> end_request: I/O error, dev sda, sector
> >> 11519720
> >> ?Input/output error[ ? 81.298719] end_request: I/O error, dev sda,
> >> sector 11519720
> >>
> >> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
> >> /etc/initscript:[ ? 81.304841] end_request: I/O error, dev sda, sector 11519720
> >> ?line 77: /etc/sysconfig/ulimit: Input/output error
> >> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
> >> [ ? 81.313187] end_request: I/O error, dev sda, sector 11519720
> >> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
> >> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
> >> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
> >> [ ? 81.324518] end_request: I/O error, dev sda, sector 11519720
> >> [ ? 81.329435] end_request: I/O error, dev sda, sector 11519720
> >> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output er[
> >> 81.334830] end_request: I/O error, ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?dev
> >> sda, sector 11519720
> >> ror
> >> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
> >> /etc/initscript: line [ ? 81.341698] end_request: I/O error, dev sda,
> >> sector 11519720
> >> 77: /etc/sysconfig/ulimit: Input/output error
> >> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
> >> INIT: Id "6[ ? 81.349010] end_request: I/O error, dev sda, sector 11519720
> >> " respawning too fast: disabled for 5 minutes
> >> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output er[
> >> 81.355880] end_request: I/O error, ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?dev
> >> sda, sector 11519720
> >> ror
> >> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
> >> [ ? 81.363875] end_request: I/O error, dev sda, sector 11519720
> >> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output er[
> >> 81.369261] end_request: I/O error, ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?dev
> >> sda, sector 11519720
> >> ror
> >> INIT: Id "co" respawning too fast: disabled for 5 minutes
> >> /etc/initscript: line 77: /etc[ ? 81.376228] end_request: I/O error,
> >> dev sda, sector 11519720
> >> /sysconfig/ulimit: Input/output error
> >> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
> >> INI[ ? 81.383188] end_request: I/O error, dev sda, sector 11519720
> >> T: Id "3" respawning too fast: disabled for 5 minutes
> >> /etc/initscript: line 77[ ? 81.389244] end_request: I/O error, dev
> >> sda, sector 11519720
> >> : /etc/sysconfig/ulimit: Input/output error
> >> INIT: Id "4" respawning too fast: disabled for 5 minutes
> >> /etc/in[ ? 81.395907] end_request: I/O error, dev sda, sector 11519720
> >> itscript: line 77: /etc/sysconfig/ulimit: Input/output error
> >> /etc/initscript: line 77: /etc/sysconfig/ulimit: I[ ? 81.403341]
> >> end_request: I/O error, dev sda, secto ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? r
> >> 11519720
> >> nput/output error
> >> INIT: Id "5" respawning too fast: disabled for 5 minutes
> >> /etc/initscript: [ ? 81.410018] end_request: I/O error, dev sda, sector 11519720
> >> line 77: /etc/sysconfig/ulimit: Input/output error
> >> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
> >> INIT: Id "1" respawning too fast: disabled for 5 minutes
> >> [ ? 81.420725] end_request: I/O error, dev sda, sector 11519720
> >> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
> >> [ ? 81.430746] end_request: I/O error, dev sda, sector 11519720
> >> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
> >> [ ? 81.440664] end_request: I/O error, dev sda, sector 11519720
> >> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
> >> INIT: Id "2" respawning too fast: disabled for 5 minutes
> >> INIT: no more processes left in this runlevel
> >>
> >>
> >>
> >>
> >> On Wed, Nov 30, 2011 at 11:48 AM, Artur Baruchi <mail.baruchi@gmail.com> wrote:
> >> > Hi.
> >> >
> >> > Im installing a VM to run a benchmark, Im able to install the VM issue
> >> > the first boot (to setup network configurations), but if I reboot the
> >> > VM it just hangs and do not boot. I've re-installed the machine but no
> >> > success. Follow some details:
> >> >
> >> > - Dom0: Opensuse 11.3 (x86_64), kernel 2.6.34-12-xen,
> >> > xen-4.0.0_21091_05-6.6.x86_64
> >> > - DomU: Full Virtualization, Opensuse 11.3 (x86_64), kernel 2.6.34-12-desktop
> >> >
> >> > Some errors in message file (not sure that this errors mean something
> >> > for this problem):
> >> > Nov 27 23:02:17 linuxtemp01 kernel: [ 5681.075141] ata1: link is slow
> >> > to respond, please be patient (ready=0)
> >> > Nov 27 23:02:22 linuxtemp01 kernel: [ 5686.073141] ata1: device not
> >> > ready (errno=-16), forcing hardreset
> >> > Nov 27 23:02:22 linuxtemp01 kernel: [ 5686.073236] ata1: soft resetting link
> >> > Nov 27 23:02:22 linuxtemp01 kernel: [ 5686.228817] ata1.00: configured
> >> > for MWDMA2
> >> > Nov 27 23:02:22 linuxtemp01 kernel: [ 5686.230503] ata1.01: configured
> >> > for MWDMA1
> >> > Nov 27 23:02:22 linuxtemp01 kernel: [ 5686.230508] ata1.00: device
> >> > reported invalid CHS sector 0
> >> > Nov 27 23:02:22 linuxtemp01 kernel: [ 5686.230515] ata1: EH complete
> >> > Nov 27 23:08:24 linuxtemp01 kernel: [ 6047.701259] ata1.01: exception
> >> > Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
> >> > Nov 27 23:08:24 linuxtemp01 kernel: [ 6047.701262] ata1.01: failed
> >> > command: WRITE DMA EXT
> >> > Nov 27 23:08:24 linuxtemp01 kernel: [ 6047.701265] ata1.01: cmd
> >> > 35/00:98:ef:c0:24/00:02:02:00:00/f0 tag 0 dma 339968 out
> >> > Nov 27 23:08:24 linuxtemp01 kernel: [ 6047.701266] ? ? ? ? ?res
> >> > 40/00:01:00:00:00/00:00:00:00:00/b0 Emask 0x4 (timeout)
> >> > Nov 27 23:08:24 linuxtemp01 kernel: [ 6047.701268] ata1.01: status: { DRDY }
> >> > Nov 27 23:08:29 linuxtemp01 kernel: [ 6052.750078] ata1: link is slow
> >> > to respond, please be patient (ready=0)
> >> > Nov 27 23:08:34 linuxtemp01 kernel: [ 6057.748079] ata1: device not
> >> > ready (errno=-16), forcing hardreset
> >> > Nov 27 23:08:34 linuxtemp01 kernel: [ 6057.748134] ata1: soft resetting link
> >> > Nov 27 23:08:34 linuxtemp01 kernel: [ 6057.902320] ata1.00: configured
> >> > for MWDMA2
> >> > Nov 27 23:08:35 linuxtemp01 kernel: [ 6057.903499] ata1.01: configured
> >> > for MWDMA1
> >> > Nov 27 23:08:35 linuxtemp01 kernel: [ 6057.903503] ata1.01: device
> >> > reported invalid CHS sector 0
> >> > Nov 27 23:08:35 linuxtemp01 kernel: [ 6057.903506] ata1: EH complete
> >> >
> >> > My problem is very similar to this one:
> >> > http://web.archiveorange.com/archive/v/wmeLDfqXdkxOOQURv2Ak
> >> >
> >> > But the workaround for this issue is not working for me.
> >> >
> >> > Any help will be welcome.
> >> >
> >> > Thanks in advance.
> >> >
> >> > Att.
> >> > Artur Baruchi
> >>
> >> _______________________________________________
> >> Xen-devel mailing list
> >> Xen-devel@lists.xensource.com
> >> http://lists.xensource.com/xen-devel

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 03:17:25 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 03:17:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVx8i-0004Yc-KP; Thu, 01 Dec 2011 03:16:48 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>)
	id 1RVx8h-0004YU-EZ; Thu, 01 Dec 2011 03:16:47 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-7.tower-174.messagelabs.com!1322709364!3779609!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10207 invoked from network); 1 Dec 2011 03:16:05 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-7.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 1 Dec 2011 03:16:05 -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
	pB13G2VY032315
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Wed, 30 Nov 2011 22:16:02 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pB13G1bk032302;
	Wed, 30 Nov 2011 22:16:01 -0500
Date: Wed, 30 Nov 2011 23:16:01 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Artur Baruchi <mail.baruchi@gmail.com>
Message-ID: <20111201031601.GA32261@andromeda.dapyr.net>
References: <CAAiDW_RNUWUUm7rsgXUMJnc6gnQ7FbEv0eVX-tJQ+PAnjrOmeg@mail.gmail.com>
	<CAAiDW_Trg-B8Bq=sjnedZoxjxi2T+H=ADvuiBdE8jr+B1a5Jgg@mail.gmail.com>
	<20111130221545.GB16651@andromeda.dapyr.net>
	<CAAiDW_T2Eutw=NibLv2s1f1DJsbSY39oHL_pH8RkmAi=iWK0HA@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAAiDW_T2Eutw=NibLv2s1f1DJsbSY39oHL_pH8RkmAi=iWK0HA@mail.gmail.com>
User-Agent: Mutt/1.5.9i
Cc: Xen-devel@lists.xensource.com, xen-users <Xen-users@lists.xensource.com>
Subject: Re: [Xen-devel] VM Hanging after reboot
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Nov 30, 2011 at 09:09:58PM -0200, Artur Baruchi wrote:
> Hi Konrad.
> 
> That was my first though (disk going bad). But I create another VM in
> a different host and faced the same error. I tried to create another

So is the error from within the guest or from the dom0?

> file and use a physical device (logical volume) too, but no lucky. Im
> guessing that it can be:
> 
> - There is a bug in this kernel version or in paravirtualized drivers
> used by opensuse 11.3 (based on some google searchs that I made, with
> similar errors); OR
> - Some configuration problem (for example, need to enable acpi in my
> vm kernel, or anything like this).
> 
> Thanks.
> 
> Att.
> Artur Baruchi
> 
> 
> On Wed, Nov 30, 2011 at 8:15 PM, Konrad Rzeszutek Wilk
> <konrad@darnok.org> wrote:
> > On Wed, Nov 30, 2011 at 04:46:55PM -0200, Artur Baruchi wrote:
> >> I just configured the serial console to see what is going on during
> >> the boot. I tried to run fsck and changed the grub to use the device
> >> path (/dev/sdaX) instead udisks-part-id, but no success.
> >>
> >> Follow the console errors:
> >>
> >
> > That looks like your disk is going bad?
> >
> > Was there anything before this? Like the IRQs not setup properly?
> >
> >> Loading drivers, configuring devices: [ ? 69.701448] ata1.00:
> >> exception Emask 0x0 SAct 0x0 SErr 0x0 act
> >> ?ion 0x6 frozen
> >> [ ? 69.705706] ata1.00: failed command: READ DMA
> >> [ ? 69.708402] ata1.00: cmd c8/00:20:b8:7a:66/00:00:00:00:00/e0 tag 0
> >> dma 16384 in
> >> [ ? 69.708403] ? ? ? ? ?res 40/00:01:00:00:00/00:00:00:00:00/a0 Emask
> >> 0x4 (timeout)
> >> [ ? 69.717358] ata1.00: status: { DRDY }
> >> [ ? 69.872400] ata1.00: revalidation failed (errno=-2)
> >> [ ? 75.023385] ata1.00: revalidation failed (errno=-2)
> >> [ ? 80.174383] ata1.00: revalidation failed (errno=-2)
> >> [ ? 80.329687] end_request: I/O error, dev sda, sector 6716088
> >> [ ? 80.333096] end_request: I/O error, dev sda, sector 6716088
> >> [ ? 80.336676] end_request: I/O error, dev sda, sector 6716088
> >> [ ? 80.340408] end_request: I/O error, dev sda, sector 6145504
> >> [ ? 80.344063] end_request: I/O error, dev sda, sector 6145504
> >> [ ? 80.347465] end_request: I/O error, dev sda, sector 6145504
> >> [ ? 80.351795] end_request: I/O error, dev sda, sector 6145504
> >> [ ? 80.356081] end_request: I/O error, dev sda, sector 6145504
> >> [ ? 80.359587] end_request: I/O error, dev sda, sector 6145504
> >> [ ? 80.363115] end_request: I/O error, dev sda, sector 6145504
> >> [ ? 80.366535] end_request: I/O error, dev sda, sector 6145504
> >> [ ? 80.370034] end_request: I/O error, dev sda, sector 6145504
> >> [ ? 80.373924] end_request: I/O error, dev sda, sector 9979920
> >> [ ? 80.377458] Buffer I/O error on device sda3, logical block 721410
> >> [ ? 80.389108] end_request: I/O error, dev sda, sector 4970504
> >> [ ? 80.392576] end_request: I/O error, dev sda, sector 4970504
> >> [ ? 80.396208] end_request: I/O error, dev sda, sector 11290592
> >> [ ? 80.399747] EXT3-fs error (device sda3): ext3_get_inode_loc: unable
> >> to read inode block - inode=2231 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 26,
> >> block=885244
> >> [ ? 80.406333] end_request: I/O error, dev sda, sector 4208640
> >> [ ? 80.409650] Buffer I/O error on device sda3, logical block 0
> >> udevd-work[1631]: exec of program '/lib/udev/ata_id' failed
> >>
> >> [ ? 80.416228] end_request: I/O error, dev sda, sector 6796224
> >> [ ? 80.419759] end_request: I/O error, dev sda, sector 6796288
> >> [ ? 80.423135] end_request: I/O error, dev sda, sector 6796288
> >> [ ? 80.425117] end_request: I/O error, dev sda, sector 6796288
> >> [ ? 80.427447] end_request: I/O error, dev sda, sector 6796288
> >> [ ? 80.429840] end_request: I/O error, dev sda, sector 6796288
> >> [ ? 80.432094] end_request: I/O error, dev sda, sector 6796288
> >> [ ? 80.434425] end_request: I/O error, dev sda, sector 6796288
> >> [ ? 80.436746] end_request: I/O error, dev sda, sector 6796288
> >> [ ? 80.439043] end_request: I/O error, dev sda, sector 6796288
> >> [ ? 80.441358] end_request: I/O error, dev sda, sector 6796288
> >> [ ? 80.443626] end_request: I/O error, dev sda, sector 6796288
> >> [ ? 80.445864] end_request: I/O error, dev sda, sector 6796288
> >> [ ? 80.448051] end_request: I/O error, dev sda, sector 6796288
> >> [ ? 80.450271] end_request: I/O error, dev sda, sector 6796288
> >> [ ? 80.452482] end_request: I/O error, dev sda, sector 6796288
> >> [ ? 80.454745] end_request: I/O error, dev sda, sector 6796288
> >> [ ? 80.457029] end_request: I/O error, dev sda, sector 6796288
> >> [ ? 80.459299] end_request: I/O error, dev sda, sector 6796288
> >> [ ? 80.461604] end_request: I/O error, dev sda, sector 6796288
> >> [ ? 80.463843] end_request: I/O error, dev sda, sector 6796288
> >> [ ? 80.466045] end_request: I/O error, dev sda, sector 6796288
> >> [ ? 80.468274] end_request: I/O error, dev sda, sector 6796288
> >> [ ? 80.470510] end_request: I/O error, dev sda, sector 6796288
> >> [ ? 80.472725] end_request: I/O error, dev sda, sector 6796288
> >> [ ? 80.474902] end_request: I/O error, dev sda, sector 6796288
> >> [ ? 80.477103] end_request: I/O error, dev sda, sector 6796288
> >> [ ? 80.479278] end_request: I/O error, dev sda, sector 6796288
> >> [ ? 80.481514] end_request: I/O error, dev sda, sector 6796288
> >> [ ? 80.483647] end_request: I/O error, dev sda, sector 6796288
> >> [ ? 80.485780] end_request: I/O error, dev sda, sector 6796288
> >> [ ? 80.487838] end_request: I/O error, dev sda, sector 6796288
> >> [ ? 80.489897] end_request: I/O error, dev sda, sector 6796224
> >> [ ? 80.491920] end_request: I/O error, dev sda, sector 6796224
> >> [ ? 80.494294] end_request: I/O error, dev sda, sector 4971928
> >> [ ? 80.496445] end_request: I/O error, dev sda, sector 4971928
> >> [ ? 80.498650] end_request: I/O error, dev sda, sector 11290592
> >> [ ? 80.500834] EXT3-fs error (device sda3): ext3_get_inode_loc: unable
> >> to read inode block - inode=2231 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 26,
> >> block=885244
> >> [ ? 80.504930] end_request: I/O error, dev sda, sector 4208640
> >> [ ? 80.507019] Buffer I/O error on device sda3, logical block 0
> >> udevd-work[1632]: exec of program '/lib/udev/scsi_id' failed
> >>
> >> [ ? 80.511028] end_request: I/O error, dev sda, sector 12352272
> >> [ ? 80.513236] Buffer I/O error on device sda3, logical block 1017954
> >> [ ? 80.515677] end_request: I/O error, dev sda, sector 12360888
> >> [ ? 80.518021] Buffer I/O error on device sda3, logical block 1019031
> >> [ ? 80.520527] Buffer I/O error on device sda3, logical block 1019032
> >> [ ? 80.523072] end_request: I/O error, dev sda, sector 9980016
> >> [ ? 80.525394] journal_bmap: journal block not found at offset 12 on sda3
> >> [ ? 80.527956] Aborting journal on device sda3.
> >> [ ? 80.529854] end_request: I/O error, dev sda, sector 9979920
> >> [ ? 80.532119] Buffer I/O error on device sda3, logical block 721410
> >> [ ? 80.534799] end_request: I/O error, dev sda, sector 9979928
> >> [ ? 80.537239] end_request: I/O error, dev sda, sector 9979936
> >> [ ? 80.539639] end_request: I/O error, dev sda, sector 9370632
> >> [ ? 80.542144] end_request: I/O error, dev sda, sector 9370632
> >> [ ? 80.544499] EXT3-fs (sda3): error: ext3_journal_start_sb: Detected
> >> aborted journal
> >> [ ? 80.547659] EXT3-fs (sda3): error: remounting filesystem read-only
> >> [ ? 80.550535] end_request: I/O error, dev sda, sector 11290592
> >> [ ? 80.552989] EXT3-fs error (device sda3): ext3_get_inode_loc: unable
> >> to read inode block - inode=2231 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 26,
> >> block=885244
> >> udevd-work[1634]: exec of program '/sbin/blkid' failed
> >>
> >> [ ? 80.559337] end_request: I/O error, dev sda, sector 4972560
> >> [ ? 80.561964] end_request: I/O error, dev sda, sector 4972560
> >> [ ? 80.564546] end_request: I/O error, dev sda, sector 11290592
> >> [ ? 80.567069] EXT3-fs error (device sda3): ext3_get_inode_loc: unable
> >> to read inode block - inode=2231 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 26,
> >> block=885244
> >> udevd-work[1635]: exec of program '/lib/udev/edd_id' failed
> >>
> >> [ ? 80.576377] end_request: I/O error, dev sda, sector 4952712
> >> [ ? 80.580086] end_request: I/O error, dev sda, sector 4952712
> >> [ ? 80.583689] end_request: I/O error, dev sda, sector 11290592
> >> [ ? 80.586292] EXT3-fs error (device sda3): ext3_get_inode_loc: unable
> >> to read inode block - inode=2231 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 26,
> >> block=885244
> >> udevd-work[1636]: exec of program '/lib/udev/udisks-part-id' failed
> >>
> >> [ ? 80.593995] end_request: I/O error, dev sda, sector 9370632
> >> [ ? 80.596704] end_request: I/O error, dev sda, sector 9370632
> >> [ ? 80.596755] end_request: I/O error, dev sda, sector 11290592
> >> [ ? 80.596760] EXT3-fs error (device sda3): ext3_get_inode_loc: unable
> >> to read inode block - inode=2231 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 26,
> >> block=885244
> >> udevd-work[1637][ ? 80.608632] end_request: I/O error, dev sda, sector 11290592
> >> : exec of program '/sbin/blkid' failed[ ? 80.612951] EXT3-fs error
> >> (device sda3): ext3_get_inode_loc: u
> >> nable to read inode block - inode=223126, block=885244
> >>
> >>
> >> [ ? 80.621449] end_request: I/O error, dev sda, sector 9370632
> >> [ ? 80.624665] end_request: I/O error, dev sda, sector 11290592
> >> [ ? 80.627305] EXT3-fs error (device sda3): ext3_get_inode_loc: unable
> >> to read inode block - inode=2231 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 26,
> >> block=885244
> >> udevd-work[1638]: exec of program '/sbin/blkid' failed
> >>
> >> udevd-work[1639]: exec of program '/sbin/blkid' failed
> >>
> >> [ ? 80.635017] end_request: I/O error, dev sda, sector 4952712
> >> [ ? 80.637899] end_request: I/O error, dev sda, sector 4952712
> >> [ ? 80.637956] end_request: I/O error, dev sda, sector 11290592
> >> [ ? 80.637962] EXT3-fs error (device sda3): ext3_get_inode_loc: unable
> >> to read inode block - inode=2231 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 26,
> >> block=885244
> >> [ ? 80.649954] end_request: I/O error, dev sda, sector 4952712
> >> udevd-work[1640]: exec of program '/lib/udev/udi[ ? 80.649974]
> >> end_request: I/O error, dev sda, sector
> >> 11290592
> >> sks-part-id' failed
> >> [ ? 80.649981] EXT3-fs error (device sda3): ext3_get_inode_loc: unable
> >> to read inode block - inode=2231 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 26,
> >> block=885244
> >>
> >> udevd-work[1641][ ? 80.664921] end_request: I/O error, dev sda, sector 11290592
> >> : exec of program '/lib/udev/udisks-part-id' fai[ ? 80.669088] EXT3-fs
> >> error (device sda3): ext3_get_in
> >> ode_loc: ledunable to read inode block - inode=223126, block=885244
> >>
> >>
> >> udevd-work[1642]: exec of program '/lib/udev/udisks-part-id' failed
> >>
> >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? done
> >> [ ? 80.688649] end_request: I/O error, dev sda, sector 11516760
> >> [ ? 80.693402] end_request: I/O error, dev sda, sector 11517320
> >> [ ? 80.698410] end_request: I/O error, dev sda, sector 11516760
> >> boot.loadmodules: Input/output error
> >> [ ? 80.705752] end_request: I/O error, dev sda, sector 11517320
> >> boot.rootfsck: Input/output error
> >> [ ? 80.712719] end_request: I/O error, dev sda, sector 11516496
> >> [ ? 80.717814] end_request: I/O error, dev sda, sector 11516704
> >> [ ? 80.730101] end_request: I/O error, dev sda, sector 11516496
> >> boot.clock: Input/output error
> >> [ ? 80.736217] end_request: I/O error, dev sda, sector 11516768
> >> [ ? 80.741296] end_request: I/O error, dev sda, sector 11352104
> >> [ ? 80.745949] end_request: I/O error, dev sda, sector 11352104
> >> boot.device-mapper: Input/output error
> >> [ ? 80.753208] end_request: I/O error, dev sda, sector 11516768
> >> boot.localfs: Input/output error
> >> [ ? 80.760052] end_request: I/O error, dev sda, sector 11516488
> >> [ ? 80.764909] end_request: I/O error, dev sda, sector 11499608
> >> [ ? 80.769502] end_request: I/O error, dev sda, sector 11303224
> >> [ ? 80.775085] end_request: I/O error, dev sda, sector 11516744
> >> [ ? 80.779703] end_request: I/O error, dev sda, sector 11517168
> >> [ ? 80.784166] end_request: I/O error, dev sda, sector 11517360
> >> [ ? 80.788596] end_request: I/O error, dev sda, sector 11518640
> >> [ ? 80.793861] end_request: I/O error, dev sda, sector 11518640
> >> [ ? 80.798273] end_request: I/O error, dev sda, sector 11517360
> >> [ ? 80.803364] end_request: I/O error, dev sda, sector 11517176
> >> boot.swap: Input/output error
> >> [ ? 80.809435] end_request: I/O error, dev sda, sector 11517168
> >> boot.proc: Input/output error
> >> [ ? 80.815339] end_request: I/O error, dev sda, sector 11516488
> >> boot.localnet: Input/output error[ ? 80.820846] end_request: I/O
> >> error, dev sda, sector 11516744
> >> [ ? 80.825458] end_request: I/O error, dev sda, sector 11499608
> >> [ ? 80.829771] end_request: I/O error, dev sda, sector 11303224
> >> [ ? 80.834086] end_request: I/O error, dev sda, sector 11516752
> >>
> >> boot.cleanup: In[ ? 80.838667] end_request: I/O error, dev sda, sector 11518160
> >> put/output error[ ? 80.843568] end_request: I/O error, dev sda, sector 11516752
> >>
> >> [ ? 80.847792] end_request: I/O error, dev sda, sector 11518160
> >> boot.cycle: Input/output error[ ? 80.853141] end_request: I/O error,
> >> dev sda, sector 11417656
> >>
> >> [ ? 80.853840] end_request: I/O error, dev sda, sector 11417656
> >> boot.fuse: Input/output error
> >> boot.klog: Input/output error
> >> boot.sysctl: Input/output error
> >> [ ? 80.865148] end_request: I/O error, dev sda, sector 11516712
> >> [ ? 80.865199] end_request: I/O error, dev sda, sector 11516712
> >> boot.ldconfig: Input/output error
> >> boot.udev_retry: Input/output error
> >> boot.apparmor: Input/output error
> >> boot.ipconfig: Input/output error
> >> System Boot Control: The system has been ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?set up
> >> Failed features: boot.loadmodules boot.rootfsck boot.clock
> >> boot.device-mapper boot.localfs boot.cleanup
> >> ? ? ?boot.cycle boot.fuse boot.klog boot.localnet boot.proc boot.swap
> >> boot.sysctl boot.ldconfig boot.udev_r
> >> etry boot.apparmor boot.ipconfig
> >> System Boot Control: Running /etc/init.d/boot.local
> >> [ ? 80.890020] end_request: I/O error, dev sda, sector 11540760
> >> [ ? 80.892185] end_request: I/O error, dev sda, sector 11540760
> >> /etc/init.d/boot.local: /etc/init.d/boot.local: Input/output error ? ?failed
> >> [ ? 80.897735] end_request: I/O error, dev sda, sector 9369944
> >> [ ? 80.900025] end_request: I/O error, dev sda, sector 9369944
> >> [ ? 80.902265] end_request: I/O error, dev sda, sector 9369944
> >> /etc/init.d/boot: line 314: /sbin/killproc: Input/output error
> >> /etc/init.d/boot: line 326: /var/run/no_blogd: Read-only file system
> >> [ ? 80.909885] end_request: I/O error, dev sda, sector 12335128
> >> [ ? 80.913314] EXT3-fs error (device sda3): ext3_get_inode_loc: unable
> >> to read inode block - inode=2539 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 69,
> >> block=1015811
> >> [ ? 80.920333] end_request: I/O error, dev sda, sector 12335128
> >> [ ? 80.923922] EXT3-fs error (device sda3): ext3_get_inode_loc: unable
> >> to read inode block - inode=2539 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 69,
> >> block=1015811
> >> [ ? 80.931552] end_request: I/O error, dev sda, sector 12335128
> >> [ ? 80.935604] EXT3-fs error (device sda3): ext3_get_inode_loc: unable
> >> to read inode block - inode=2539 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 69,
> >> block=1015811
> >> [ ? 80.944776] end_request: I/O error, dev sda, sector 11290592
> >> [ ? 80.948819] EXT3-fs error (device sda3): ext3_get_inode_loc: unable
> >> to read inode block - inode=2231 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 26,
> >> block=885244
> >> INIT: Entering runlevel: 3
> >> [ ? 80.965451] end_request: I/O error, dev sda, sector 11519720
> >> [ ? 80.969737] end_request: I/O error, dev sda, sector 11519720
> >> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
> >> [ ? 80.980514] end_request: I/O error, dev sda, sector 11519720
> >> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error[
> >> 80.987414] end_request: I/O erro ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? r, dev
> >> sda, sector 11519720
> >>
> >> [ ? 80.991743] end_request: I/O error, dev sda, sector 11519720
> >> /etc/initscript:[ ? 80.996145] end_request: I/O error, dev sda, sector 11519720
> >> ?line 77: /etc/sysconfig/ulimit: Input/output error
> >> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
> >> /etc/initscript: line 77: /etc/s[ ? 81.005996] end_request: I/O error,
> >> dev sda, sector 11519720
> >> ysconfig/ulimit: Input/output er[ ? 81.010510] end_request: I/O error,
> >> dev sda, sector 11519720
> >> ror[ ? 81.016077] end_request: I/O error, dev sda, sector 11519720
> >>
> >> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error[
> >> 81.022320] end_request: I/O erro ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? r, dev
> >> sda, sector 11519720
> >>
> >> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
> >> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
> >> /etc/initscript:[ ? 81.030711] end_request: I/O error, dev sda, sector 11519720
> >> ?line 77: /etc/sysconfig/ulimit:[ ? 81.035523] end_request: I/O error,
> >> dev sda, sector 11519720
> >> ?Input/output error
> >> /etc/initscript:[ ? 81.043077] end_request: I/O error, dev sda, sector 11519720
> >> ?line 77: /etc/sysconfig/ulimit:[ ? 81.047889] end_request: I/O error,
> >> dev sda, sector 11519720
> >> ?Input/output error[ ? 81.052231] end_request: I/O error, dev sda,
> >> sector 11519720
> >>
> >> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
> >> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
> >> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/outp[
> >> 81.062739] end_request: I/O error, dev s
> >> da, sector 11519720
> >> ut error
> >> [ ? 81.066952] end_request: I/O error, dev sda, sector 11519720
> >> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
> >> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
> >> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
> >> [ ? 81.081287] end_request: I/O error, dev sda, sector 11519720
> >> /etc/initscript: line 77: /etc/sysconfig/ulimit:[ ? 81.087077]
> >> end_request: I/O error, dev sda, sector
> >> 11519720
> >> ?Input/output error
> >> [ ? 81.092828] end_request: I/O error, dev sda, sector 11519720
> >> [ ? 81.097171] end_request: I/O error, dev sda, sector 11519720
> >> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
> >> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output er[
> >> 81.105199] end_request: I/O error, ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?dev
> >> sda, sector 11519720
> >> ror
> >> /etc/initscript: line 77: /[ ? 81.109861] end_request: I/O error, dev
> >> sda, sector 11519720
> >> etc/sysconfig/ulimit: Input/output error
> >> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input[ ? 81.116079]
> >> end_request: I/O error, dev sda, s ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ector
> >> 11519720
> >> /output error
> >> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
> >> /etc/initscript: line 77: /etc/sysconfig/uli[ ? 81.123656]
> >> end_request: I/O error, dev sda, sector 1151
> >> ? ? 9720
> >> mit: Input/output error
> >> [ ? 81.131077] end_request: I/O error, dev sda, sector 11519720
> >> /etc/initscript:[ ? 81.135256] end_request: I/O error, dev sda, sector 11519720
> >> ?line 77: /etc/sysconfig/ulimit: Input/output error
> >> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
> >> [ ? 81.145043] end_request: I/O error, dev sda, sector 11519720
> >> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error[
> >> 81.151102] end_request: I/O erro ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? r, dev
> >> sda, sector 11519720
> >>
> >> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
> >> /etc/initscript:[ ? 81.158246] end_request: I/O error, dev sda, sector 11519720
> >> ?line 77: /etc/sysconfig/ulimit: Input/output error[ ? 81.163908]
> >> end_request: I/O error, dev sda, sect ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? or
> >> 11519720
> >>
> >> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
> >> /etc/initscript:[ ? 81.170077] end_request: I/O error, dev sda, sector 11519720
> >> ?line 77: /etc/sysconfig/ulimit: Input/output error
> >> [ ? 81.175614] end_request: I/O error, dev sda, sector 11519720
> >> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error[
> >> 81.181692] end_request: I/O erro ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? r, dev
> >> sda, sector 11519720
> >>
> >> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
> >> [ ? 81.188834] end_request: I/O error, dev sda, sector 11519720
> >> [ ? 81.193074] end_request: I/O error, dev sda, sector 11519720
> >> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
> >> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
> >> /etc/initscript: line 77: /etc/sysconfig/ul[ ? 81.202959] end_request:
> >> I/O error, dev sda, sector 11519 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 720
> >> imit: Input/output error
> >> [ ? 81.209078] end_request: I/O error, dev sda, sector 11519720
> >> [ ? 81.215046] end_request: I/O error, dev sda, sector 11519720
> >> /etc/initscript: line 77: /etc/sysconfig/ulimit:[ ? 81.220029]
> >> end_request: I/O error, dev sda, sector
> >> 11519720
> >> ?Input/output error
> >> /etc/initscript:[ ? 81.224860] end_request: I/O error, dev sda, sector 11519720
> >> ?line 77: /etc/sysconfig/ulimit: Input/output error[ ? 81.230950]
> >> end_request: I/O error, dev sda, sect ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? or
> >> 11519720
> >>
> >> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
> >> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
> >> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
> >> [ ? 81.241445] end_request: I/O error, dev sda, sector 11519720
> >> [ ? 81.245133] end_request: I/O error, dev sda, sector 11519720
> >> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
> >> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error[
> >> 81.253519] end_request: I/O erro ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? r, dev
> >> sda, sector 11519720
> >>
> >> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output er[
> >> 81.259342] end_request: I/O error, ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?dev
> >> sda, sector 11519720
> >> ror
> >> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/outp[
> >> 81.265077] end_request: I/O error, dev s
> >> da, sector 11519720
> >> ut error
> >> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
> >> /etc/initscript: line 77: /etc/sy[ ? 81.271786] end_request: I/O
> >> error, dev sda, sector 11519720
> >> sconfig/ulimit: Input/output error
> >> [ ? 81.277066] end_request: I/O error, dev sda, sector 11519720
> >> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
> >> [ ? 81.284078] end_request: I/O error, dev sda, sector 11519720
> >> [ ? 81.287740] end_request: I/O error, dev sda, sector 11519720
> >> /etc/initscript: line 77: /etc/sysconfig/ulimit:[ ? 81.292708]
> >> end_request: I/O error, dev sda, sector
> >> 11519720
> >> ?Input/output error[ ? 81.298719] end_request: I/O error, dev sda,
> >> sector 11519720
> >>
> >> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
> >> /etc/initscript:[ ? 81.304841] end_request: I/O error, dev sda, sector 11519720
> >> ?line 77: /etc/sysconfig/ulimit: Input/output error
> >> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
> >> [ ? 81.313187] end_request: I/O error, dev sda, sector 11519720
> >> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
> >> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
> >> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
> >> [ ? 81.324518] end_request: I/O error, dev sda, sector 11519720
> >> [ ? 81.329435] end_request: I/O error, dev sda, sector 11519720
> >> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output er[
> >> 81.334830] end_request: I/O error, ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?dev
> >> sda, sector 11519720
> >> ror
> >> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
> >> /etc/initscript: line [ ? 81.341698] end_request: I/O error, dev sda,
> >> sector 11519720
> >> 77: /etc/sysconfig/ulimit: Input/output error
> >> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
> >> INIT: Id "6[ ? 81.349010] end_request: I/O error, dev sda, sector 11519720
> >> " respawning too fast: disabled for 5 minutes
> >> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output er[
> >> 81.355880] end_request: I/O error, ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?dev
> >> sda, sector 11519720
> >> ror
> >> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
> >> [ ? 81.363875] end_request: I/O error, dev sda, sector 11519720
> >> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output er[
> >> 81.369261] end_request: I/O error, ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?dev
> >> sda, sector 11519720
> >> ror
> >> INIT: Id "co" respawning too fast: disabled for 5 minutes
> >> /etc/initscript: line 77: /etc[ ? 81.376228] end_request: I/O error,
> >> dev sda, sector 11519720
> >> /sysconfig/ulimit: Input/output error
> >> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
> >> INI[ ? 81.383188] end_request: I/O error, dev sda, sector 11519720
> >> T: Id "3" respawning too fast: disabled for 5 minutes
> >> /etc/initscript: line 77[ ? 81.389244] end_request: I/O error, dev
> >> sda, sector 11519720
> >> : /etc/sysconfig/ulimit: Input/output error
> >> INIT: Id "4" respawning too fast: disabled for 5 minutes
> >> /etc/in[ ? 81.395907] end_request: I/O error, dev sda, sector 11519720
> >> itscript: line 77: /etc/sysconfig/ulimit: Input/output error
> >> /etc/initscript: line 77: /etc/sysconfig/ulimit: I[ ? 81.403341]
> >> end_request: I/O error, dev sda, secto ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? r
> >> 11519720
> >> nput/output error
> >> INIT: Id "5" respawning too fast: disabled for 5 minutes
> >> /etc/initscript: [ ? 81.410018] end_request: I/O error, dev sda, sector 11519720
> >> line 77: /etc/sysconfig/ulimit: Input/output error
> >> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
> >> INIT: Id "1" respawning too fast: disabled for 5 minutes
> >> [ ? 81.420725] end_request: I/O error, dev sda, sector 11519720
> >> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
> >> [ ? 81.430746] end_request: I/O error, dev sda, sector 11519720
> >> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
> >> [ ? 81.440664] end_request: I/O error, dev sda, sector 11519720
> >> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
> >> INIT: Id "2" respawning too fast: disabled for 5 minutes
> >> INIT: no more processes left in this runlevel
> >>
> >>
> >>
> >>
> >> On Wed, Nov 30, 2011 at 11:48 AM, Artur Baruchi <mail.baruchi@gmail.com> wrote:
> >> > Hi.
> >> >
> >> > Im installing a VM to run a benchmark, Im able to install the VM issue
> >> > the first boot (to setup network configurations), but if I reboot the
> >> > VM it just hangs and do not boot. I've re-installed the machine but no
> >> > success. Follow some details:
> >> >
> >> > - Dom0: Opensuse 11.3 (x86_64), kernel 2.6.34-12-xen,
> >> > xen-4.0.0_21091_05-6.6.x86_64
> >> > - DomU: Full Virtualization, Opensuse 11.3 (x86_64), kernel 2.6.34-12-desktop
> >> >
> >> > Some errors in message file (not sure that this errors mean something
> >> > for this problem):
> >> > Nov 27 23:02:17 linuxtemp01 kernel: [ 5681.075141] ata1: link is slow
> >> > to respond, please be patient (ready=0)
> >> > Nov 27 23:02:22 linuxtemp01 kernel: [ 5686.073141] ata1: device not
> >> > ready (errno=-16), forcing hardreset
> >> > Nov 27 23:02:22 linuxtemp01 kernel: [ 5686.073236] ata1: soft resetting link
> >> > Nov 27 23:02:22 linuxtemp01 kernel: [ 5686.228817] ata1.00: configured
> >> > for MWDMA2
> >> > Nov 27 23:02:22 linuxtemp01 kernel: [ 5686.230503] ata1.01: configured
> >> > for MWDMA1
> >> > Nov 27 23:02:22 linuxtemp01 kernel: [ 5686.230508] ata1.00: device
> >> > reported invalid CHS sector 0
> >> > Nov 27 23:02:22 linuxtemp01 kernel: [ 5686.230515] ata1: EH complete
> >> > Nov 27 23:08:24 linuxtemp01 kernel: [ 6047.701259] ata1.01: exception
> >> > Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
> >> > Nov 27 23:08:24 linuxtemp01 kernel: [ 6047.701262] ata1.01: failed
> >> > command: WRITE DMA EXT
> >> > Nov 27 23:08:24 linuxtemp01 kernel: [ 6047.701265] ata1.01: cmd
> >> > 35/00:98:ef:c0:24/00:02:02:00:00/f0 tag 0 dma 339968 out
> >> > Nov 27 23:08:24 linuxtemp01 kernel: [ 6047.701266] ? ? ? ? ?res
> >> > 40/00:01:00:00:00/00:00:00:00:00/b0 Emask 0x4 (timeout)
> >> > Nov 27 23:08:24 linuxtemp01 kernel: [ 6047.701268] ata1.01: status: { DRDY }
> >> > Nov 27 23:08:29 linuxtemp01 kernel: [ 6052.750078] ata1: link is slow
> >> > to respond, please be patient (ready=0)
> >> > Nov 27 23:08:34 linuxtemp01 kernel: [ 6057.748079] ata1: device not
> >> > ready (errno=-16), forcing hardreset
> >> > Nov 27 23:08:34 linuxtemp01 kernel: [ 6057.748134] ata1: soft resetting link
> >> > Nov 27 23:08:34 linuxtemp01 kernel: [ 6057.902320] ata1.00: configured
> >> > for MWDMA2
> >> > Nov 27 23:08:35 linuxtemp01 kernel: [ 6057.903499] ata1.01: configured
> >> > for MWDMA1
> >> > Nov 27 23:08:35 linuxtemp01 kernel: [ 6057.903503] ata1.01: device
> >> > reported invalid CHS sector 0
> >> > Nov 27 23:08:35 linuxtemp01 kernel: [ 6057.903506] ata1: EH complete
> >> >
> >> > My problem is very similar to this one:
> >> > http://web.archiveorange.com/archive/v/wmeLDfqXdkxOOQURv2Ak
> >> >
> >> > But the workaround for this issue is not working for me.
> >> >
> >> > Any help will be welcome.
> >> >
> >> > Thanks in advance.
> >> >
> >> > Att.
> >> > Artur Baruchi
> >>
> >> _______________________________________________
> >> Xen-devel mailing list
> >> Xen-devel@lists.xensource.com
> >> http://lists.xensource.com/xen-devel

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 03:30:05 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 03: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.xensource.com>)
	id 1RVxLA-0004lP-CQ; Thu, 01 Dec 2011 03:29:40 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fajar@fajar.net>)
	id 1RVxL9-0004lH-1B; Thu, 01 Dec 2011 03:29:39 +0000
X-Env-Sender: fajar@fajar.net
X-Msg-Ref: server-10.tower-21.messagelabs.com!1322710138!6405263!1
X-Originating-IP: [209.85.213.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1865 invoked from network); 1 Dec 2011 03:28:59 -0000
Received: from mail-yw0-f43.google.com (HELO mail-yw0-f43.google.com)
	(209.85.213.43)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 03:28:59 -0000
Received: by ywt34 with SMTP id 34so6534680ywt.30
	for <multiple recipients>; Wed, 30 Nov 2011 19:28:58 -0800 (PST)
MIME-Version: 1.0
Received: by 10.236.192.233 with SMTP id i69mr8757472yhn.60.1322710138184;
	Wed, 30 Nov 2011 19:28:58 -0800 (PST)
Received: by 10.146.93.20 with HTTP; Wed, 30 Nov 2011 19:28:58 -0800 (PST)
In-Reply-To: <20111201031601.GA32261@andromeda.dapyr.net>
References: <CAAiDW_RNUWUUm7rsgXUMJnc6gnQ7FbEv0eVX-tJQ+PAnjrOmeg@mail.gmail.com>
	<CAAiDW_Trg-B8Bq=sjnedZoxjxi2T+H=ADvuiBdE8jr+B1a5Jgg@mail.gmail.com>
	<20111130221545.GB16651@andromeda.dapyr.net>
	<CAAiDW_T2Eutw=NibLv2s1f1DJsbSY39oHL_pH8RkmAi=iWK0HA@mail.gmail.com>
	<20111201031601.GA32261@andromeda.dapyr.net>
Date: Thu, 1 Dec 2011 10:28:58 +0700
Message-ID: <CAG1y0sfjmeDoLJ131TV-GUphhcuu+LcmJLJC-3h5=DzMKe7Jmg@mail.gmail.com>
From: "Fajar A. Nugraha" <list@fajar.net>
To: Artur Baruchi <mail.baruchi@gmail.com>
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>, Xen-devel@lists.xensource.com,
	xen-users <Xen-users@lists.xensource.com>
Subject: Re: [Xen-devel] VM Hanging after reboot
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Dec 1, 2011 at 10:16 AM, Konrad Rzeszutek Wilk
<konrad@darnok.org> wrote:
> On Wed, Nov 30, 2011 at 09:09:58PM -0200, Artur Baruchi wrote:
>> Hi Konrad.
>>
>> That was my first though (disk going bad). But I create another VM in
>> a different host and faced the same error. I tried to create another
>
> So is the error from within the guest or from the dom0?
>

As Konrad asked, is the error in dom0 or domU?

If dom0, then most likely it's disk problem. One way to diagnose it is
by reading from the disk (dd_rescue is nice) and see if at least it's
able to read the disk completely.

If domU, then it's probably a bug in dom0 kernel (the blkback driver,
perhaps). In which case novell guys might be able to help you more. I
recall something like this when using older kernel for dom0 (forgot
the exact version, sorry), but the error went away after I used
vanilla 3.1.0 for dom0 kernel.

-- 
Fajar

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 03:30:05 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 03: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.xensource.com>)
	id 1RVxLA-0004lP-CQ; Thu, 01 Dec 2011 03:29:40 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fajar@fajar.net>)
	id 1RVxL9-0004lH-1B; Thu, 01 Dec 2011 03:29:39 +0000
X-Env-Sender: fajar@fajar.net
X-Msg-Ref: server-10.tower-21.messagelabs.com!1322710138!6405263!1
X-Originating-IP: [209.85.213.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1865 invoked from network); 1 Dec 2011 03:28:59 -0000
Received: from mail-yw0-f43.google.com (HELO mail-yw0-f43.google.com)
	(209.85.213.43)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 03:28:59 -0000
Received: by ywt34 with SMTP id 34so6534680ywt.30
	for <multiple recipients>; Wed, 30 Nov 2011 19:28:58 -0800 (PST)
MIME-Version: 1.0
Received: by 10.236.192.233 with SMTP id i69mr8757472yhn.60.1322710138184;
	Wed, 30 Nov 2011 19:28:58 -0800 (PST)
Received: by 10.146.93.20 with HTTP; Wed, 30 Nov 2011 19:28:58 -0800 (PST)
In-Reply-To: <20111201031601.GA32261@andromeda.dapyr.net>
References: <CAAiDW_RNUWUUm7rsgXUMJnc6gnQ7FbEv0eVX-tJQ+PAnjrOmeg@mail.gmail.com>
	<CAAiDW_Trg-B8Bq=sjnedZoxjxi2T+H=ADvuiBdE8jr+B1a5Jgg@mail.gmail.com>
	<20111130221545.GB16651@andromeda.dapyr.net>
	<CAAiDW_T2Eutw=NibLv2s1f1DJsbSY39oHL_pH8RkmAi=iWK0HA@mail.gmail.com>
	<20111201031601.GA32261@andromeda.dapyr.net>
Date: Thu, 1 Dec 2011 10:28:58 +0700
Message-ID: <CAG1y0sfjmeDoLJ131TV-GUphhcuu+LcmJLJC-3h5=DzMKe7Jmg@mail.gmail.com>
From: "Fajar A. Nugraha" <list@fajar.net>
To: Artur Baruchi <mail.baruchi@gmail.com>
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>, Xen-devel@lists.xensource.com,
	xen-users <Xen-users@lists.xensource.com>
Subject: Re: [Xen-devel] VM Hanging after reboot
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Dec 1, 2011 at 10:16 AM, Konrad Rzeszutek Wilk
<konrad@darnok.org> wrote:
> On Wed, Nov 30, 2011 at 09:09:58PM -0200, Artur Baruchi wrote:
>> Hi Konrad.
>>
>> That was my first though (disk going bad). But I create another VM in
>> a different host and faced the same error. I tried to create another
>
> So is the error from within the guest or from the dom0?
>

As Konrad asked, is the error in dom0 or domU?

If dom0, then most likely it's disk problem. One way to diagnose it is
by reading from the disk (dd_rescue is nice) and see if at least it's
able to read the disk completely.

If domU, then it's probably a bug in dom0 kernel (the blkback driver,
perhaps). In which case novell guys might be able to help you more. I
recall something like this when using older kernel for dom0 (forgot
the exact version, sorry), but the error went away after I used
vanilla 3.1.0 for dom0 kernel.

-- 
Fajar

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 05:40:40 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 05:40:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVzNF-00069Z-L6; Thu, 01 Dec 2011 05:39:57 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RVzND-00069U-Lv
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 05:39:55 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1322717956!6309020!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTM2Mw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30095 invoked from network); 1 Dec 2011 05:39:16 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 05:39:16 -0000
X-IronPort-AV: E=Sophos;i="4.71,276,1320624000"; 
   d="scan'208";a="9220377"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Dec 2011 05:39:15 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 1 Dec 2011 05:39:15 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RVzMZ-0008RM-8y;
	Thu, 01 Dec 2011 05:39:15 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RVzMZ-00028g-4b;
	Thu, 01 Dec 2011 05:39:15 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10201-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 1 Dec 2011 05:39:15 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10201: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-i386-xend-winxpsp3  7 windows-install              fail  never pass
 test-amd64-amd64-xl-win7-amd64  7 windows-install              fail never pass
 test-amd64-i386-xl-win7-amd64  7 windows-install              fail  never pass
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install          fail never pass
 test-i386-i386-xl-winxpsp3    7 windows-install              fail   never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           14 guest-start.2                fail   like 10192
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  62ff6a318c5d
baseline version:
 xen                  3c4c29899d8a

------------------------------------------------------------
People who touched revisions under test:
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Keir Fraser <keir@xen.org>
  Paul Durrant <paul.durrant@citrix.com>
------------------------------------------------------------

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


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

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

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


Pushing revision :

+ branch=xen-unstable
+ revision=62ff6a318c5d
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-unstable 62ff6a318c5d
+ branch=xen-unstable
+ revision=62ff6a318c5d
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ : xen@xenbits.xensource.com
+ : xen@xenbits.xensource.com:git/linux-pvops
+ : master
+ : tested/2.6.39.x
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r 62ff6a318c5d ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 1 changesets with 1 changes to 1 files

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 05:40:40 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 05:40:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVzNF-00069Z-L6; Thu, 01 Dec 2011 05:39:57 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RVzND-00069U-Lv
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 05:39:55 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1322717956!6309020!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTM2Mw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30095 invoked from network); 1 Dec 2011 05:39:16 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 05:39:16 -0000
X-IronPort-AV: E=Sophos;i="4.71,276,1320624000"; 
   d="scan'208";a="9220377"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Dec 2011 05:39:15 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 1 Dec 2011 05:39:15 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RVzMZ-0008RM-8y;
	Thu, 01 Dec 2011 05:39:15 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RVzMZ-00028g-4b;
	Thu, 01 Dec 2011 05:39:15 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10201-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 1 Dec 2011 05:39:15 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10201: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-i386-xend-winxpsp3  7 windows-install              fail  never pass
 test-amd64-amd64-xl-win7-amd64  7 windows-install              fail never pass
 test-amd64-i386-xl-win7-amd64  7 windows-install              fail  never pass
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install          fail never pass
 test-i386-i386-xl-winxpsp3    7 windows-install              fail   never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           14 guest-start.2                fail   like 10192
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  62ff6a318c5d
baseline version:
 xen                  3c4c29899d8a

------------------------------------------------------------
People who touched revisions under test:
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Keir Fraser <keir@xen.org>
  Paul Durrant <paul.durrant@citrix.com>
------------------------------------------------------------

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


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

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

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


Pushing revision :

+ branch=xen-unstable
+ revision=62ff6a318c5d
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-unstable 62ff6a318c5d
+ branch=xen-unstable
+ revision=62ff6a318c5d
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ : xen@xenbits.xensource.com
+ : xen@xenbits.xensource.com:git/linux-pvops
+ : master
+ : tested/2.6.39.x
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r 62ff6a318c5d ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 1 changesets with 1 changes to 1 files

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 08:02:09 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 08:02:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW1a8-0007JG-3i; Thu, 01 Dec 2011 08:01:24 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RW1a6-0007JB-FE
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 08:01:22 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1322726439!6425461!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ0NTA=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15050 invoked from network); 1 Dec 2011 08:00:39 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-10.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 1 Dec 2011 08:00:39 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 01 Dec 2011 08:00:39 +0000
Message-Id: <4ED7423602000078000648FE@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 01 Dec 2011 08:00:38 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Keir Fraser" <keir.xen@gmail.com>
References: <4ED6676F02000078000646BC@nat28.tlf.novell.com>
	<CAFBA259.26155%keir.xen@gmail.com>
In-Reply-To: <CAFBA259.26155%keir.xen@gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 2/2] x86/microcode: enable boot time
 (pre-Dom0) loading
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 30.11.11 at 10:05, Keir Fraser <keir.xen@gmail.com> wrote:
> On 30/11/2011 16:27, "Jan Beulich" <JBeulich@suse.com> wrote:
> 
>> 
>> In order to not convert the spin_lock() in microcode_update_cpu() (and
>> then obviously also all other uses on microcode_mutex) to
>> spin_lock_irqsave() (which would be undesirable for the hypercall
>> context in which the function also runs), the boot time handling gets
>> done using a tasklet (instead of using on_selected_cpus()).
> 
> Can you explain this some more? Why would the conversion to
> spin_lock_irqsave be required when spin_lock is sufficient for current usage
> from dom0 hypercall?

Because check_lock() wants locks to be acquired consistently?

Jan


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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 08:02:09 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 08:02:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW1a8-0007JG-3i; Thu, 01 Dec 2011 08:01:24 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RW1a6-0007JB-FE
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 08:01:22 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1322726439!6425461!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ0NTA=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15050 invoked from network); 1 Dec 2011 08:00:39 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-10.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 1 Dec 2011 08:00:39 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 01 Dec 2011 08:00:39 +0000
Message-Id: <4ED7423602000078000648FE@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 01 Dec 2011 08:00:38 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Keir Fraser" <keir.xen@gmail.com>
References: <4ED6676F02000078000646BC@nat28.tlf.novell.com>
	<CAFBA259.26155%keir.xen@gmail.com>
In-Reply-To: <CAFBA259.26155%keir.xen@gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 2/2] x86/microcode: enable boot time
 (pre-Dom0) loading
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 30.11.11 at 10:05, Keir Fraser <keir.xen@gmail.com> wrote:
> On 30/11/2011 16:27, "Jan Beulich" <JBeulich@suse.com> wrote:
> 
>> 
>> In order to not convert the spin_lock() in microcode_update_cpu() (and
>> then obviously also all other uses on microcode_mutex) to
>> spin_lock_irqsave() (which would be undesirable for the hypercall
>> context in which the function also runs), the boot time handling gets
>> done using a tasklet (instead of using on_selected_cpus()).
> 
> Can you explain this some more? Why would the conversion to
> spin_lock_irqsave be required when spin_lock is sufficient for current usage
> from dom0 hypercall?

Because check_lock() wants locks to be acquired consistently?

Jan


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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 08:06:24 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 08:06:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW1eI-0007Pg-QX; Thu, 01 Dec 2011 08:05:42 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RW1eH-0007PU-H8
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 08:05:41 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1322726701!6509061!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ0NTA=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5247 invoked from network); 1 Dec 2011 08:05:01 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-14.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 1 Dec 2011 08:05:01 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 01 Dec 2011 08:05:02 +0000
Message-Id: <4ED7433A0200007800064903@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 01 Dec 2011 08:04:58 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad@darnok.org>
References: <4ED6676F02000078000646BC@nat28.tlf.novell.com>
	<20111130222359.GC16651@andromeda.dapyr.net>
In-Reply-To: <20111130222359.GC16651@andromeda.dapyr.net>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Borislav Petkov <borislav.petkov@amd.com>, hpa@zytor.com
Subject: Re: [Xen-devel] [PATCH 2/2] x86/microcode: enable boot time
 (pre-Dom0) loading
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 30.11.11 at 23:23, Konrad Rzeszutek Wilk <konrad@darnok.org> wrote:
> On Wed, Nov 30, 2011 at 04:27:11PM +0000, Jan Beulich wrote:
>> Largely as a result of the continuing resistance of Linux maintainers
>> to accept a microcode loading patch for pv-ops Xen kernels, this
>> follows the suggested route and provides a means to load microcode
>> updates without the assistance of Dom0, thus also addressing eventual
>> problems in the hardware much earlier.
>> 
>> This leverages the fact that via the multiboot protocol another blob
>> of data can be easily added in the form of just an extra module. Since
>> microcode data cannot reliably be recognized by looking at the
>> provided data, this requires (in the non-EFI case) the use of a
>> command line parameter ("ucode=<number>") to identify which of the
> 
> Well, usually there would be two modules - the kernel (which we can
> identify) and the initramfs (which I guess one can also identify)?
> It seems that by process of elimination we could determine that the
> remaining module is the blob? Or would that be simple too dangerous
> to make such assumption?

For one, we must not imply that what Linux calls "initrd" isn't used as
something completely different on other possible Dom0 OSes. Hence
we can't make assumptions on the format of this module.

And second, yes, I consider it too dangerous to guess on what might
be the microcode blob.

>> modules is to be parsed for an eventual microcode update (in the EFI
>> case the module is being identified in the config file, and hence the
>> command line argument, if given, will be ignored).
>> 
>> This required to adjust the XSM module determination logic accordingly.
>> 
>> The format of the data to be provided is the raw binary blob already
>> used for AMD CPUs, and the output of the intel-microcode2ucode utility
>> for the Intel case (either the per-(family,model,stepping) file or -
>> to make things easier for distro-s integration-wise - simply the
>> concatenation of all of them).
> 
> There was some talk by hpa and borislav of how they wanted the payload,
> but it never got finalized I think? Would it make sense to CC them on
> this to see how they are planning to implement it in GRUB2?

Adding them to Cc now.

> I got the impression they wanted some new .pack format or so?
> Or is the format that they were talking about exactly what you picked?

I merely picked the binary formats that are already in use; I see no
reason to invent another one.

Jan


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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 08:06:24 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 08:06:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW1eI-0007Pg-QX; Thu, 01 Dec 2011 08:05:42 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RW1eH-0007PU-H8
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 08:05:41 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1322726701!6509061!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ0NTA=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5247 invoked from network); 1 Dec 2011 08:05:01 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-14.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 1 Dec 2011 08:05:01 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 01 Dec 2011 08:05:02 +0000
Message-Id: <4ED7433A0200007800064903@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 01 Dec 2011 08:04:58 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad@darnok.org>
References: <4ED6676F02000078000646BC@nat28.tlf.novell.com>
	<20111130222359.GC16651@andromeda.dapyr.net>
In-Reply-To: <20111130222359.GC16651@andromeda.dapyr.net>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Borislav Petkov <borislav.petkov@amd.com>, hpa@zytor.com
Subject: Re: [Xen-devel] [PATCH 2/2] x86/microcode: enable boot time
 (pre-Dom0) loading
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 30.11.11 at 23:23, Konrad Rzeszutek Wilk <konrad@darnok.org> wrote:
> On Wed, Nov 30, 2011 at 04:27:11PM +0000, Jan Beulich wrote:
>> Largely as a result of the continuing resistance of Linux maintainers
>> to accept a microcode loading patch for pv-ops Xen kernels, this
>> follows the suggested route and provides a means to load microcode
>> updates without the assistance of Dom0, thus also addressing eventual
>> problems in the hardware much earlier.
>> 
>> This leverages the fact that via the multiboot protocol another blob
>> of data can be easily added in the form of just an extra module. Since
>> microcode data cannot reliably be recognized by looking at the
>> provided data, this requires (in the non-EFI case) the use of a
>> command line parameter ("ucode=<number>") to identify which of the
> 
> Well, usually there would be two modules - the kernel (which we can
> identify) and the initramfs (which I guess one can also identify)?
> It seems that by process of elimination we could determine that the
> remaining module is the blob? Or would that be simple too dangerous
> to make such assumption?

For one, we must not imply that what Linux calls "initrd" isn't used as
something completely different on other possible Dom0 OSes. Hence
we can't make assumptions on the format of this module.

And second, yes, I consider it too dangerous to guess on what might
be the microcode blob.

>> modules is to be parsed for an eventual microcode update (in the EFI
>> case the module is being identified in the config file, and hence the
>> command line argument, if given, will be ignored).
>> 
>> This required to adjust the XSM module determination logic accordingly.
>> 
>> The format of the data to be provided is the raw binary blob already
>> used for AMD CPUs, and the output of the intel-microcode2ucode utility
>> for the Intel case (either the per-(family,model,stepping) file or -
>> to make things easier for distro-s integration-wise - simply the
>> concatenation of all of them).
> 
> There was some talk by hpa and borislav of how they wanted the payload,
> but it never got finalized I think? Would it make sense to CC them on
> this to see how they are planning to implement it in GRUB2?

Adding them to Cc now.

> I got the impression they wanted some new .pack format or so?
> Or is the format that they were talking about exactly what you picked?

I merely picked the binary formats that are already in use; I see no
reason to invent another one.

Jan


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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 08:46:07 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 08:46:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW2Gq-0007qG-CV; Thu, 01 Dec 2011 08:45:32 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RW2Gp-0007pi-1u
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 08:45:31 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1322729088!3620091!1
X-Originating-IP: [209.85.210.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3466 invoked from network); 1 Dec 2011 08:44:50 -0000
Received: from mail-pz0-f43.google.com (HELO mail-pz0-f43.google.com)
	(209.85.210.43)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 08:44:50 -0000
Received: by dadz13 with SMTP id z13so627816dad.30
	for <xen-devel@lists.xensource.com>;
	Thu, 01 Dec 2011 00:44:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=/XB21EErkbUGWxOP/IrgBO6wUhSI1g71j8F1g1Vgbco=;
	b=b8+kJm0WoHmpTVHzwGVYUJxWuoZT/817eLDsSPhBbkj5qBP9QpVzdrTx4U7Ef3Prfc
	Zmf6j/htDPVyvD/k+Bca1BDztLCd19ZlM9ahsVI5eiGljodRBdBeU62fdq8/TxWO2TWR
	b8VppD38S8mMkhpqs+Qhx3NJ5R8bvqLLU304w=
MIME-Version: 1.0
Received: by 10.68.42.100 with SMTP id n4mr3240889pbl.38.1322729087783; Thu,
	01 Dec 2011 00:44:47 -0800 (PST)
Received: by 10.142.212.12 with HTTP; Thu, 1 Dec 2011 00:44:47 -0800 (PST)
In-Reply-To: <1322137170.1005.184.camel@zakaz.uk.xensource.com>
References: <patchbomb.1321617576@loki.upc.es>
	<1d81d1c4c851c0b07696.1321617582@loki.upc.es>
	<1322137170.1005.184.camel@zakaz.uk.xensource.com>
Date: Thu, 1 Dec 2011 09:44:47 +0100
X-Google-Sender-Auth: 2tayAPm19OHD8KMPBHUrX7BcdtE
Message-ID: <CAPLaKK4yt4RQ9gcRbXLs08e+nHWUAry-3c6DJPm25Xd7Ca6DPw@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 6 of 9 v2] libxl: execute hotplug scripts
 directly from libxl
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

MjAxMS8xMS8yNCBJYW4gQ2FtcGJlbGwgPElhbi5DYW1wYmVsbEBjaXRyaXguY29tPjoKPiBJIHdh
cyBqdXN0IGxvb2tpbmcgYXQgdGhpcyBhZ2FpbiBiZWNhdXNlIHNvbWVvbmUgd2FzIHRhbGtpbmcg
YWJvdXQKPiBob3RwbHVnIGlzc3VlcyBvbiBMaW51eCBhbmQgc29tZXRoaW5nIG5ldyBvY2N1cnJl
ZCB0byBtZS4KPgo+IE9uIEZyaSwgMjAxMS0xMS0xOCBhdCAxMTo1OSArMDAwMCwgUm9nZXIgUGF1
IE1vbm5lIHdyb3RlOgo+PiBbLi4uXQo+PiArKysgYi90b29scy9saWJ4bC9ob3RwbHVnX2xpbnV4
LmMgwqAgwqAgwqAgRnJpIFNlcCAzMCAxNDozODo1NSAyMDExICswMjAwCj4+IFsuLi5dCj4+ICtp
bnQgbGlieGxfZGlza19ob3RwbHVnKGxpYnhsX19nYyAqZ2MsIGxpYnhsX19kZXZpY2UgKmRldikK
Pj4gWy4uLl0KPj4gK2ludCBsaWJ4bF9uaWNfaG90cGx1Z19jb25uZWN0KGxpYnhsX19nYyAqZ2Ms
IGxpYnhsX19kZXZpY2UgKmRldikKPj4gWy4uLl0KPj4gKysrIGIvdG9vbHMvbGlieGwvaG90cGx1
Z19uZXRic2QuYyDCoCDCoCDCoEZyaSBTZXAgMzAgMTQ6Mzg6NTUgMjAxMSArMDIwMAo+PiBbLi4u
XQo+PiAraW50IGxpYnhsX19kaXNrX2hvdHBsdWcobGlieGxfX2djICpnYywgbGlieGxfX2Rldmlj
ZSAqZGV2KQo+PiBbLi4uXQo+PiAraW50IGxpYnhsX19uaWNfaG90cGx1ZyhsaWJ4bF9fZ2MgKmdj
LCBsaWJ4bF9fZGV2aWNlICpkZXYpCj4KPiBBbHRob3VnaCBMaW51eCBkb2Vzbid0IGRvIGhvdHBs
dWcgdGhpcyB3YXkgbm93IEkgdGhpbmsgaXQgd2lsbC9zaG91bGQgaW4KPiB0aGUgZnV0dXJlIGFu
ZCB0aGUgY29kZSB3aWxsIGxvb2sgdmVyeSBtdWNoIGxpa2UgdGhlIG5ldGJzZCBvbmUuIFNvIEkK
PiB0aGluayB0aGF0IHRoZSBjb2RlIHdoaWNoIGFjdHVhbGx5IGhhbmRsZXMgY2FsbGluZyB0aGUg
c2NyaXB0IHNob3VsZAo+IHByb2JhYmx5IGJlIGEgZ2VuZXJpYyBmdW5jdGlvbiwgb25seSB0aGUg
c2VsZWN0b3Igb24gd2hldGhlciB0byBkbyBzbwo+IG5lZWRzIHRvIGJlIHBsYXRmb3JtIHNwZWNp
ZmljLgoKU29ycnkgZm9yIHRoZSBkZWxheSwgSSd2ZSBiZWVuIGlsbCBtb3N0IG9mIHRoaXMgd2Vl
ay4gRnJvbSB3aGF0IEkgc2F3LAp0aGUgcHJvYmxlbSBpcyB0aGF0IE5ldEJTRCBhbmQgTGludXgg
aG90cGx1ZyBzY3JpcHRzIGhhdmUgZGlmZmVyZW50CnBhcmFtZXRlcnMsIHRoYXQncyB3aHkgSSd2
ZSBzcGxpdCB0aGUgY2FsbGluZyBmdW5jdGlvbnMgaW50byB0d28KZGlmZmVyZW50IGZpbGVzLCBh
bmQgbWFkZSB0aGVtIE9TLWRlcGVuZGVudC4gSSB0aGluayBJIHNhaWQgdGhhdApiZWZvcmUsIGJ1
dCBJIHdvdWxkIGJlIGdvb2QgdG8gYWdyZWUgb24gdGhlIGNhbGxpbmcgcGFyYW1ldGVycyBwYXNz
ZWQKdG8gaG90cGx1ZyBzY3JpcHRzLiBDdXJyZW50bHkgTmV0QlNEIGhhcyB0aGUgZm9sbG93aW5n
IHBhcmFtZXRlcnM6CgogKiBibG9jazogPGJhY2tlbmQgcGF0aD4gPHN0YXR1cz4gPHR5cGU+CiAg
ICAgICAgICB3aGVyZSA8dHlwZT4gY2FuIGJlICJmaWxlIiBvciAicGh5IgoKICogdmlmLWJyaWRn
ZTogPGJhY2tlbmQgcGF0aD4gPHN0YXR1cz4KCiAqIHZpZi1pcDogPGJhY2tlbmQgcGF0aD4gPHN0
YXR1cz4KCkFsc28gTGludXggaG90cGx1ZyBzY3JpcHRzIG5lZWQgYSBnb29kIGNsZWFuIHVwLCBo
YXJkIHRhYnMgYW5kIHNwYWNlcwphcmUgYWxsIG1peGVkLCBhbmQgbWFrZXMgdGhlIGNvZGUgcmVh
bGx5IGhhcmQgdG8gdW5kZXJzdGFuZC4KClJlZ2FyZHMsIFJvZ2VyLgoKX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApY
ZW4tZGV2ZWxAbGlzdHMueGVuc291cmNlLmNvbQpodHRwOi8vbGlzdHMueGVuc291cmNlLmNvbS94
ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Thu Dec 01 08:46:07 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 08:46:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW2Gq-0007qG-CV; Thu, 01 Dec 2011 08:45:32 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RW2Gp-0007pi-1u
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 08:45:31 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1322729088!3620091!1
X-Originating-IP: [209.85.210.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3466 invoked from network); 1 Dec 2011 08:44:50 -0000
Received: from mail-pz0-f43.google.com (HELO mail-pz0-f43.google.com)
	(209.85.210.43)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 08:44:50 -0000
Received: by dadz13 with SMTP id z13so627816dad.30
	for <xen-devel@lists.xensource.com>;
	Thu, 01 Dec 2011 00:44:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=/XB21EErkbUGWxOP/IrgBO6wUhSI1g71j8F1g1Vgbco=;
	b=b8+kJm0WoHmpTVHzwGVYUJxWuoZT/817eLDsSPhBbkj5qBP9QpVzdrTx4U7Ef3Prfc
	Zmf6j/htDPVyvD/k+Bca1BDztLCd19ZlM9ahsVI5eiGljodRBdBeU62fdq8/TxWO2TWR
	b8VppD38S8mMkhpqs+Qhx3NJ5R8bvqLLU304w=
MIME-Version: 1.0
Received: by 10.68.42.100 with SMTP id n4mr3240889pbl.38.1322729087783; Thu,
	01 Dec 2011 00:44:47 -0800 (PST)
Received: by 10.142.212.12 with HTTP; Thu, 1 Dec 2011 00:44:47 -0800 (PST)
In-Reply-To: <1322137170.1005.184.camel@zakaz.uk.xensource.com>
References: <patchbomb.1321617576@loki.upc.es>
	<1d81d1c4c851c0b07696.1321617582@loki.upc.es>
	<1322137170.1005.184.camel@zakaz.uk.xensource.com>
Date: Thu, 1 Dec 2011 09:44:47 +0100
X-Google-Sender-Auth: 2tayAPm19OHD8KMPBHUrX7BcdtE
Message-ID: <CAPLaKK4yt4RQ9gcRbXLs08e+nHWUAry-3c6DJPm25Xd7Ca6DPw@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 6 of 9 v2] libxl: execute hotplug scripts
 directly from libxl
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

MjAxMS8xMS8yNCBJYW4gQ2FtcGJlbGwgPElhbi5DYW1wYmVsbEBjaXRyaXguY29tPjoKPiBJIHdh
cyBqdXN0IGxvb2tpbmcgYXQgdGhpcyBhZ2FpbiBiZWNhdXNlIHNvbWVvbmUgd2FzIHRhbGtpbmcg
YWJvdXQKPiBob3RwbHVnIGlzc3VlcyBvbiBMaW51eCBhbmQgc29tZXRoaW5nIG5ldyBvY2N1cnJl
ZCB0byBtZS4KPgo+IE9uIEZyaSwgMjAxMS0xMS0xOCBhdCAxMTo1OSArMDAwMCwgUm9nZXIgUGF1
IE1vbm5lIHdyb3RlOgo+PiBbLi4uXQo+PiArKysgYi90b29scy9saWJ4bC9ob3RwbHVnX2xpbnV4
LmMgwqAgwqAgwqAgRnJpIFNlcCAzMCAxNDozODo1NSAyMDExICswMjAwCj4+IFsuLi5dCj4+ICtp
bnQgbGlieGxfZGlza19ob3RwbHVnKGxpYnhsX19nYyAqZ2MsIGxpYnhsX19kZXZpY2UgKmRldikK
Pj4gWy4uLl0KPj4gK2ludCBsaWJ4bF9uaWNfaG90cGx1Z19jb25uZWN0KGxpYnhsX19nYyAqZ2Ms
IGxpYnhsX19kZXZpY2UgKmRldikKPj4gWy4uLl0KPj4gKysrIGIvdG9vbHMvbGlieGwvaG90cGx1
Z19uZXRic2QuYyDCoCDCoCDCoEZyaSBTZXAgMzAgMTQ6Mzg6NTUgMjAxMSArMDIwMAo+PiBbLi4u
XQo+PiAraW50IGxpYnhsX19kaXNrX2hvdHBsdWcobGlieGxfX2djICpnYywgbGlieGxfX2Rldmlj
ZSAqZGV2KQo+PiBbLi4uXQo+PiAraW50IGxpYnhsX19uaWNfaG90cGx1ZyhsaWJ4bF9fZ2MgKmdj
LCBsaWJ4bF9fZGV2aWNlICpkZXYpCj4KPiBBbHRob3VnaCBMaW51eCBkb2Vzbid0IGRvIGhvdHBs
dWcgdGhpcyB3YXkgbm93IEkgdGhpbmsgaXQgd2lsbC9zaG91bGQgaW4KPiB0aGUgZnV0dXJlIGFu
ZCB0aGUgY29kZSB3aWxsIGxvb2sgdmVyeSBtdWNoIGxpa2UgdGhlIG5ldGJzZCBvbmUuIFNvIEkK
PiB0aGluayB0aGF0IHRoZSBjb2RlIHdoaWNoIGFjdHVhbGx5IGhhbmRsZXMgY2FsbGluZyB0aGUg
c2NyaXB0IHNob3VsZAo+IHByb2JhYmx5IGJlIGEgZ2VuZXJpYyBmdW5jdGlvbiwgb25seSB0aGUg
c2VsZWN0b3Igb24gd2hldGhlciB0byBkbyBzbwo+IG5lZWRzIHRvIGJlIHBsYXRmb3JtIHNwZWNp
ZmljLgoKU29ycnkgZm9yIHRoZSBkZWxheSwgSSd2ZSBiZWVuIGlsbCBtb3N0IG9mIHRoaXMgd2Vl
ay4gRnJvbSB3aGF0IEkgc2F3LAp0aGUgcHJvYmxlbSBpcyB0aGF0IE5ldEJTRCBhbmQgTGludXgg
aG90cGx1ZyBzY3JpcHRzIGhhdmUgZGlmZmVyZW50CnBhcmFtZXRlcnMsIHRoYXQncyB3aHkgSSd2
ZSBzcGxpdCB0aGUgY2FsbGluZyBmdW5jdGlvbnMgaW50byB0d28KZGlmZmVyZW50IGZpbGVzLCBh
bmQgbWFkZSB0aGVtIE9TLWRlcGVuZGVudC4gSSB0aGluayBJIHNhaWQgdGhhdApiZWZvcmUsIGJ1
dCBJIHdvdWxkIGJlIGdvb2QgdG8gYWdyZWUgb24gdGhlIGNhbGxpbmcgcGFyYW1ldGVycyBwYXNz
ZWQKdG8gaG90cGx1ZyBzY3JpcHRzLiBDdXJyZW50bHkgTmV0QlNEIGhhcyB0aGUgZm9sbG93aW5n
IHBhcmFtZXRlcnM6CgogKiBibG9jazogPGJhY2tlbmQgcGF0aD4gPHN0YXR1cz4gPHR5cGU+CiAg
ICAgICAgICB3aGVyZSA8dHlwZT4gY2FuIGJlICJmaWxlIiBvciAicGh5IgoKICogdmlmLWJyaWRn
ZTogPGJhY2tlbmQgcGF0aD4gPHN0YXR1cz4KCiAqIHZpZi1pcDogPGJhY2tlbmQgcGF0aD4gPHN0
YXR1cz4KCkFsc28gTGludXggaG90cGx1ZyBzY3JpcHRzIG5lZWQgYSBnb29kIGNsZWFuIHVwLCBo
YXJkIHRhYnMgYW5kIHNwYWNlcwphcmUgYWxsIG1peGVkLCBhbmQgbWFrZXMgdGhlIGNvZGUgcmVh
bGx5IGhhcmQgdG8gdW5kZXJzdGFuZC4KClJlZ2FyZHMsIFJvZ2VyLgoKX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApY
ZW4tZGV2ZWxAbGlzdHMueGVuc291cmNlLmNvbQpodHRwOi8vbGlzdHMueGVuc291cmNlLmNvbS94
ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Thu Dec 01 08:47:27 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 08:47:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW2IF-0007xb-SY; Thu, 01 Dec 2011 08:46:59 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RW2ID-0007wy-W1
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 08:46:58 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1322729177!3761102!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTM2Mw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18823 invoked from network); 1 Dec 2011 08:46:18 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 08:46:18 -0000
X-IronPort-AV: E=Sophos;i="4.71,277,1320624000"; 
   d="scan'208";a="9222356"
Received: from lonpmailmx02.citrite.net ([10.30.203.163])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Dec 2011 08:46:17 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.161]) by
	LONPMAILMX02.citrite.net ([10.30.203.163]) with mapi; Thu, 1 Dec 2011
	08:46:17 +0000
From: Paul Durrant <Paul.Durrant@citrix.com>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
Date: Thu, 1 Dec 2011 08:46:18 +0000
Thread-Topic: [Xen-devel] [PATCH] Add code to track the address of the VM
	generation id buffer across a
Thread-Index: AcyvrWwIYFt1gilVTJKn52jeOWWt6wAV+a/w
Message-ID: <291EDFCB1E9E224A99088639C4762022B5988E50D4@LONPMAILBOX01.citrite.net>
References: <94a17182f386c8bb414e.1322686717@cosworth.uk.xensource.com>
	<20111130221419.GA16651@andromeda.dapyr.net>
In-Reply-To: <20111130221419.GA16651@andromeda.dapyr.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] Add code to track the address of the VM
 generation id buffer across a
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Konrad,

  Did you see my previous patch set? The introductory comment was:

-----
The following is a revised patch series to add support for a VM generation ID virtual device for HVM guests.
The basic requirements of this device are as follows:

- It must be exposed somewhere in ACPI namespace with a _CID of
  "VM_Gen_Counter".
- It must also include a _DDN of "VM_Gen_Counter".
- It must contain a _HID object but no particular value is
  required.
- It must expose a package called ADDR which evaluates to two
  integers; the first being the low order 32-bits of a guest
  physical address (GPA), the second by the high order 32-bits of
  the GPA. This GPA is the address of an 8-byte aligned 8-byte
  buffer containing the VM generation ID.
  This buffer must not be in ranges supported as AddressRangeMemory
  or AddressRangeACPI and must not be mapped by any PTE with caching
  disabled.

The semantics of the VM generation ID itself are left up to the tools but it must be possible to change it each time the VM is booted, migrated, or restored from a saved image.
-----

  Does that help?

    Paul

> -----Original Message-----
> From: Konrad Rzeszutek Wilk [mailto:konrad@darnok.org]
> Sent: 30 November 2011 22:14
> To: Paul Durrant
> Cc: xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] [PATCH] Add code to track the address of
> the VM generation id buffer across a
>
> On Wed, Nov 30, 2011 at 08:58:37PM +0000, Paul Durrant wrote:
> > # HG changeset patch
> > # User Paul Durrant <paul.durrant@citrix.com> # Date 1322686267 0
> #
> > Node ID 94a17182f386c8bb414eba55dddf763b8982c76d
> > # Parent  3c4c29899d8a2a0c0f9109b7236da95bb72b77b6
> > Add code to track the address of the VM generation id buffer
> across a
> > save/restore or migrate and inject a new value.
>
> So what is a generation id? What is the use-case for this?
>
> > The address of the buffer is written into xenstore by hvmloader at
> > boot time. It must be read from xenstore by the caller of
> > xc_domain_save() and then written back again by the caller of
> > xc_domain_restore().
> >
> > Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
> >
> > diff -r 3c4c29899d8a -r 94a17182f386
> tools/libxc/ia64/xc_ia64_linux_restore.c
> > --- a/tools/libxc/ia64/xc_ia64_linux_restore.c      Wed Nov 30
> 07:18:11 2011 -0800
> > +++ b/tools/libxc/ia64/xc_ia64_linux_restore.c      Wed Nov 30
> 20:51:07 2011 +0000
> > @@ -548,7 +548,8 @@ int
> >  xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
> >                    unsigned int store_evtchn, unsigned long
> *store_mfn,
> >                    unsigned int console_evtchn, unsigned long
> *console_mfn,
> > -                  unsigned int hvm, unsigned int pae, int
> superpages)
> > +                  unsigned int hvm, unsigned int pae, int
> superpages,
> > +                  uint64_t gid)
> >  {
> >      DECLARE_DOMCTL;
> >      int rc = 1;
> > diff -r 3c4c29899d8a -r 94a17182f386
> tools/libxc/ia64/xc_ia64_linux_save.c
> > --- a/tools/libxc/ia64/xc_ia64_linux_save.c Wed Nov 30 07:18:11
> 2011 -0800
> > +++ b/tools/libxc/ia64/xc_ia64_linux_save.c Wed Nov 30 20:51:07
> 2011 +0000
> > @@ -382,7 +382,8 @@ out:
> >  int
> >  xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom,
> uint32_t max_iters,
> >                 uint32_t max_factor, uint32_t flags,
> > -               struct save_callbacks* callbacks, int hvm)
> > +               struct save_callbacks* callbacks, int hvm,
> > +               unsigned long vm_gid_addr)
> >  {
> >      DECLARE_DOMCTL;
> >      xc_dominfo_t info;
> > diff -r 3c4c29899d8a -r 94a17182f386
> tools/libxc/xc_domain_restore.c
> > --- a/tools/libxc/xc_domain_restore.c       Wed Nov 30 07:18:11 2011 -
> 0800
> > +++ b/tools/libxc/xc_domain_restore.c       Wed Nov 30 20:51:07 2011
> +0000
> > @@ -676,6 +676,7 @@ typedef struct {
> >      uint64_t console_pfn;
> >      uint64_t acpi_ioport_location;
> >      uint64_t viridian;
> > +    uint64_t vm_gid_addr;
> >  } pagebuf_t;
> >
> >  static int pagebuf_init(pagebuf_t* buf) @@ -820,6 +821,17 @@
> static
> > int pagebuf_get_one(xc_interface
> >          }
> >          return pagebuf_get_one(xch, ctx, buf, fd, dom);
> >
> > +    case XC_SAVE_ID_HVM_GENERATION_ID_ADDR:
> > +        /* Skip padding 4 bytes then read the generation id
> buffer location. */
> > +        if ( RDEXACT(fd, &buf->vm_gid_addr, sizeof(uint32_t)) ||
> > +             RDEXACT(fd, &buf->vm_gid_addr, sizeof(uint64_t)) )
> > +        {
> > +            PERROR("error read the generation id buffer
> location");
> > +            return -1;
> > +        }
> > +        DPRINTF("read generation id buffer address");
> > +        return pagebuf_get_one(xch, ctx, buf, fd, dom);
> > +
> >      default:
> >          if ( (count > MAX_BATCH_SIZE) || (count < 0) ) {
> >              ERROR("Max batch size exceeded (%d). Giving up.",
> count);
> > @@ -1186,7 +1198,8 @@ static int apply_batch(xc_interface *xch
> int
> > xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
> >                        unsigned int store_evtchn, unsigned long
> *store_mfn,
> >                        unsigned int console_evtchn, unsigned long
> *console_mfn,
> > -                      unsigned int hvm, unsigned int pae, int
> superpages)
> > +                      unsigned int hvm, unsigned int pae, int
> superpages,
> > +                      uint64_t gid, unsigned long *vm_gid_addr)
> >  {
> >      DECLARE_DOMCTL;
> >      int rc = 1, frc, i, j, n, m, pae_extended_cr3 = 0,
> > ext_vcpucontext = 0; @@ -1386,6 +1399,33 @@ int
> xc_domain_restore(xc_interface *xch,
> >                  xc_set_hvm_param(xch, dom, HVM_PARAM_VM86_TSS,
> pagebuf.vm86_tss);
> >              if ( pagebuf.console_pfn )
> >                  console_pfn = pagebuf.console_pfn;
> > +            if ( pagebuf.vm_gid_addr ) {
> > +                unsigned int offset;
> > +                unsigned char *buf;
> > +
> > +                /*
> > +                 * Map the VM generation id buffer and inject the
> new value.
> > +                 */
> > +
> > +                pfn = pagebuf.vm_gid_addr >> PAGE_SHIFT;
> > +                offset = pagebuf.vm_gid_addr & (PAGE_SIZE - 1);
> > +
> > +                if ( (pfn >= dinfo->p2m_size) ||
> > +                     (pfn_type[pfn] != XEN_DOMCTL_PFINFO_NOTAB) )
> > +                {
> > +                    ERROR("generation id buffer frame is bad");
> > +                    goto out;
> > +                }
> > +
> > +                mfn = ctx->p2m[pfn];
> > +                buf = xc_map_foreign_range(xch, dom, PAGE_SIZE,
> > +                                           PROT_READ |
> PROT_WRITE, mfn);
> > +                *(unsigned long long *)(buf + offset) = gid;
> > +                munmap(buf, PAGE_SIZE);
> > +
> > +                *vm_gid_addr = pagebuf.vm_gid_addr;
> > +            }
> > +
> >              break;  /* our work here is done */
> >          }
> >
> > diff -r 3c4c29899d8a -r 94a17182f386 tools/libxc/xc_domain_save.c
> > --- a/tools/libxc/xc_domain_save.c  Wed Nov 30 07:18:11 2011 -
> 0800
> > +++ b/tools/libxc/xc_domain_save.c  Wed Nov 30 20:51:07 2011
> +0000
> > @@ -754,7 +754,8 @@ static int save_tsc_info(xc_interface *x
> >
> >  int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom,
> uint32_t max_iters,
> >                     uint32_t max_factor, uint32_t flags,
> > -                   struct save_callbacks* callbacks, int hvm)
> > +                   struct save_callbacks* callbacks, int hvm,
> > +                   unsigned long vm_gid_addr)
> >  {
> >      xc_dominfo_t info;
> >      DECLARE_DOMCTL;
> > @@ -1460,6 +1461,16 @@ int xc_domain_save(xc_interface *xch, in
> >              uint64_t data;
> >          } chunk = { 0, };
> >
> > +        chunk.id = XC_SAVE_ID_HVM_GENERATION_ID_ADDR;
> > +        chunk.data = vm_gid_addr;
> > +
> > +        if ( (chunk.data != 0) &&
> > +             wrexact(io_fd, &chunk, sizeof(chunk)) )
> > +        {
> > +            PERROR("Error when writing the generation id buffer
> location for guest");
> > +            goto out;
> > +        }
> > +
> >          chunk.id = XC_SAVE_ID_HVM_IDENT_PT;
> >          chunk.data = 0;
> >          xc_get_hvm_param(xch, dom, HVM_PARAM_IDENT_PT, diff -r
> > 3c4c29899d8a -r 94a17182f386 tools/libxc/xenguest.h
> > --- a/tools/libxc/xenguest.h        Wed Nov 30 07:18:11 2011 -0800
> > +++ b/tools/libxc/xenguest.h        Wed Nov 30 20:51:07 2011 +0000
> > @@ -57,7 +57,8 @@ struct save_callbacks {
> >   */
> >  int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom,
> uint32_t max_iters,
> >                     uint32_t max_factor, uint32_t flags /*
> XCFLAGS_xxx */,
> > -                   struct save_callbacks* callbacks, int hvm);
> > +                   struct save_callbacks* callbacks, int hvm,
> > +                   unsigned long vm_gid_addr);
> >
> >
> >  /**
> > @@ -71,12 +72,15 @@ int xc_domain_save(xc_interface *xch, in
> >   * @parm hvm non-zero if this is a HVM restore
> >   * @parm pae non-zero if this HVM domain has PAE support enabled
> >   * @parm superpages non-zero to allocate guest memory with
> superpages
> > + * @parm gid the new generation id of the VM
> > + * @parm vm_gid_addr returned with the address of the generation
> id
> > + buffer
> >   * @return 0 on success, -1 on failure
> >   */
> >  int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
> >                        unsigned int store_evtchn, unsigned long
> *store_mfn,
> >                        unsigned int console_evtchn, unsigned long
> *console_mfn,
> > -                      unsigned int hvm, unsigned int pae, int
> superpages);
> > +                      unsigned int hvm, unsigned int pae, int
> superpages,
> > +                      uint64_t gid, unsigned long *vm_gid_addr);
> >  /**
> >   * xc_domain_restore writes a file to disk that contains the
> device
> >   * model saved state.
> > diff -r 3c4c29899d8a -r 94a17182f386 tools/libxc/xg_save_restore.h
> > --- a/tools/libxc/xg_save_restore.h Wed Nov 30 07:18:11 2011 -
> 0800
> > +++ b/tools/libxc/xg_save_restore.h Wed Nov 30 20:51:07 2011
> +0000
> > @@ -135,6 +135,7 @@
> >  #define XC_SAVE_ID_LAST_CHECKPOINT    -9 /* Commit to restoring
> after completion of current iteration. */
> >  #define XC_SAVE_ID_HVM_ACPI_IOPORTS_LOCATION -10
> >  #define XC_SAVE_ID_HVM_VIRIDIAN       -11
> > +#define XC_SAVE_ID_HVM_GENERATION_ID_ADDR -12
> >
> >  /*
> >  ** We process save/restore/migrate in batches of pages; the below
> > diff -r 3c4c29899d8a -r 94a17182f386 tools/libxl/libxl_create.c
> > --- a/tools/libxl/libxl_create.c    Wed Nov 30 07:18:11 2011 -0800
> > +++ b/tools/libxl/libxl_create.c    Wed Nov 30 20:51:07 2011 +0000
> > @@ -101,6 +101,7 @@ int libxl_init_build_info(libxl_ctx *ctx
> >          b_info->u.hvm.vpt_align = 1;
> >          b_info->u.hvm.timer_mode = 1;
> >          b_info->u.hvm.nested_hvm = 0;
> > +        b_info->u.hvm.generation_id = 0;
> >          break;
> >      case LIBXL_DOMAIN_TYPE_PV:
> >          b_info->u.pv.slack_memkb = 8 * 1024; @@ -191,13 +192,15
> @@
> > int libxl__domain_build(libxl__gc *gc,
> >          vments[4] = "start_time";
> >          vments[5] = libxl__sprintf(gc, "%lu.%02d",
> > start_time.tv_sec,(int)start_time.tv_usec/10000);
> >
> > -        localents = libxl__calloc(gc, 7, sizeof(char *));
> > +        localents = libxl__calloc(gc, 9, sizeof(char *));
> >          localents[0] = "platform/acpi";
> >          localents[1] = (info->u.hvm.acpi) ? "1" : "0";
> >          localents[2] = "platform/acpi_s3";
> >          localents[3] = (info->u.hvm.acpi_s3) ? "1" : "0";
> >          localents[4] = "platform/acpi_s4";
> >          localents[5] = (info->u.hvm.acpi_s4) ? "1" : "0";
> > +        localents[6] = "platform/generation_id";
> > +        localents[7] = libxl__sprintf(gc, "0x%llx",
> > + info->u.hvm.generation_id);
> >
> >          break;
> >      case LIBXL_DOMAIN_TYPE_PV:
> > diff -r 3c4c29899d8a -r 94a17182f386 tools/libxl/libxl_dom.c
> > --- a/tools/libxl/libxl_dom.c       Wed Nov 30 07:18:11 2011 -0800
> > +++ b/tools/libxl/libxl_dom.c       Wed Nov 30 20:51:07 2011 +0000
> > @@ -125,7 +125,7 @@ int libxl__build_post(libxl__gc *gc, uin
> >      if (info->cpuid != NULL)
> >          libxl_cpuid_set(ctx, domid, info->cpuid);
> >
> > -    ents = libxl__calloc(gc, 12 + (info->max_vcpus * 2) + 2,
> sizeof(char *));
> > +    ents = libxl__calloc(gc, 14 + (info->max_vcpus * 2) + 2,
> > + sizeof(char *));
> >      ents[0] = "memory/static-max";
> >      ents[1] = libxl__sprintf(gc, "%d", info->max_memkb);
> >      ents[2] = "memory/target";
> > @@ -138,9 +138,11 @@ int libxl__build_post(libxl__gc *gc, uin
> >      ents[9] = libxl__sprintf(gc, "%"PRIu32, state->store_port);
> >      ents[10] = "store/ring-ref";
> >      ents[11] = libxl__sprintf(gc, "%lu", state->store_mfn);
> > +    ents[12] = "data/generation-id";
> > +    ents[13] = libxl__sprintf(gc, "0x%lx", state->vm_gid_addr);
> >      for (i = 0; i < info->max_vcpus; i++) {
> > -        ents[12+(i*2)]   = libxl__sprintf(gc,
> "cpu/%d/availability", i);
> > -        ents[12+(i*2)+1] = (i && info->cur_vcpus && !(info-
> >cur_vcpus & (1 << i)))
> > +        ents[14+(i*2)]   = libxl__sprintf(gc,
> "cpu/%d/availability", i);
> > +        ents[14+(i*2)+1] = (i && info->cur_vcpus && !(info-
> >cur_vcpus
> > + & (1 << i)))
> >                              ? "offline" : "online";
> >      }
> >
> > @@ -357,16 +359,19 @@ int libxl__domain_restore_common(libxl__
> >      /* read signature */
> >      int rc;
> >      int hvm, pae, superpages;
> > +    uint64_t gid;
> >      switch (info->type) {
> >      case LIBXL_DOMAIN_TYPE_HVM:
> >          hvm = 1;
> >          superpages = 1;
> >          pae = info->u.hvm.pae;
> > +        gid = info->u.hvm.generation_id;
> >          break;
> >      case LIBXL_DOMAIN_TYPE_PV:
> >          hvm = 0;
> >          superpages = 0;
> >          pae = 1;
> > +        gid = 0;
> >          break;
> >      default:
> >          return ERROR_INVAL;
> > @@ -374,7 +379,7 @@ int libxl__domain_restore_common(libxl__
> >      rc = xc_domain_restore(ctx->xch, fd, domid,
> >                             state->store_port, &state->store_mfn,
> >                             state->console_port, &state-
> >console_mfn,
> > -                           hvm, pae, superpages);
> > +                           hvm, pae, superpages, gid,
> > + &state->vm_gid_addr);
> >      if ( rc ) {
> >          LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "restoring
> domain");
> >          return ERROR_FAIL;
> > @@ -540,12 +545,22 @@ int libxl__domain_suspend_common(libxl__
> >      struct save_callbacks callbacks;
> >      struct suspendinfo si;
> >      int hvm, rc = ERROR_FAIL;
> > +    unsigned long vm_gid_addr;
> >
> >      switch (type) {
> > -    case LIBXL_DOMAIN_TYPE_HVM:
> > +    case LIBXL_DOMAIN_TYPE_HVM: {
> > +        char *path;
> > +        char *addr;
> > +
> > +        path = libxl__sprintf(gc, "%s/data/generation-id",
> libxl__xs_get_dompath(gc, domid));
> > +        addr = libxl__xs_read(gc, XBT_NULL, path);
> > +
> > +        vm_gid_addr = (addr) ? strtoul(addr, NULL, 0) : 0;
> >          hvm = 1;
> >          break;
> > +    }
> >      case LIBXL_DOMAIN_TYPE_PV:
> > +        vm_gid_addr = 0;
> >          hvm = 0;
> >          break;
> >      default:
> > @@ -583,7 +598,8 @@ int libxl__domain_suspend_common(libxl__
> >      callbacks.switch_qemu_logdirty =
> libxl__domain_suspend_common_switch_qemu_logdirty;
> >      callbacks.data = &si;
> >
> > -    rc = xc_domain_save(ctx->xch, fd, domid, 0, 0, flags,
> &callbacks, hvm);
> > +    rc = xc_domain_save(ctx->xch, fd, domid, 0, 0, flags,
> &callbacks,
> > +                        hvm, vm_gid_addr);
> >      if ( rc ) {
> >          LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "saving domain:
> %s",
> >                           si.guest_responded ?
> > diff -r 3c4c29899d8a -r 94a17182f386 tools/libxl/libxl_internal.h
> > --- a/tools/libxl/libxl_internal.h  Wed Nov 30 07:18:11 2011 -
> 0800
> > +++ b/tools/libxl/libxl_internal.h  Wed Nov 30 20:51:07 2011
> +0000
> > @@ -199,6 +199,8 @@ typedef struct {
> >
> >      uint32_t console_port;
> >      unsigned long console_mfn;
> > +
> > +    unsigned long vm_gid_addr;
> >  } libxl__domain_build_state;
> >
> >  _hidden int libxl__build_pre(libxl__gc *gc, uint32_t domid, diff
> -r
> > 3c4c29899d8a -r 94a17182f386 tools/libxl/libxl_types.idl
> > --- a/tools/libxl/libxl_types.idl   Wed Nov 30 07:18:11 2011 -
> 0800
> > +++ b/tools/libxl/libxl_types.idl   Wed Nov 30 20:51:07 2011
> +0000
> > @@ -183,6 +183,7 @@ libxl_domain_build_info = Struct("domain
> >                                         ("vpt_align", bool),
> >                                         ("timer_mode", integer),
> >                                         ("nested_hvm", bool),
> > +                                       ("generation_id", uint64),
> >                                         ])),
> >                   ("pv", Struct(None, [("kernel",
> libxl_file_reference),
> >                                        ("slack_memkb", uint32),
> diff
> > -r 3c4c29899d8a -r 94a17182f386 tools/libxl/libxlu_cfg.c
> > --- a/tools/libxl/libxlu_cfg.c      Wed Nov 30 07:18:11 2011 -0800
> > +++ b/tools/libxl/libxlu_cfg.c      Wed Nov 30 20:51:07 2011 +0000
> > @@ -235,6 +235,37 @@ int xlu_cfg_get_long(const XLU_Config *c
> >      return 0;
> >  }
> >
> > +int xlu_cfg_get_long_long(const XLU_Config *cfg, const char *n,
> > +                          long long *value_r, int dont_warn) {
> > +    long long ll;
> > +    XLU_ConfigSetting *set;
> > +    int e;
> > +    char *ep;
> > +
> > +    e= find_atom(cfg,n,&set,dont_warn);  if (e) return e;
> > +    errno= 0; ll= strtoll(set->values[0], &ep, 0);
> > +    e= errno;
> > +    if (errno) {
> > +        e= errno;
> > +        assert(e==EINVAL || e==ERANGE);
> > +        if (!dont_warn)
> > +            fprintf(cfg->report,
> > +                    "%s:%d: warning: parameter `%s' could not be
> parsed"
> > +                    " as a number: %s\n",
> > +                    cfg->filename, set->lineno, n, strerror(e));
> > +        return e;
> > +    }
> > +    if (*ep || ep==set->values[0]) {
> > +        if (!dont_warn)
> > +            fprintf(cfg->report,
> > +                    "%s:%d: warning: parameter `%s' is not a
> valid number\n",
> > +                    cfg->filename, set->lineno, n);
> > +        return EINVAL;
> > +    }
> > +    *value_r= ll;
> > +    return 0;
> > +}
> > +
> >
> >  int xlu_cfg_get_list(const XLU_Config *cfg, const char *n,
> >                       XLU_ConfigList **list_r, int *entries_r, int
> > dont_warn) { diff -r 3c4c29899d8a -r 94a17182f386
> tools/libxl/libxlutil.h
> > --- a/tools/libxl/libxlutil.h       Wed Nov 30 07:18:11 2011 -0800
> > +++ b/tools/libxl/libxlutil.h       Wed Nov 30 20:51:07 2011 +0000
> > @@ -52,6 +52,8 @@ int xlu_cfg_replace_string(const XLU_Con
> >                             char **value_r, int dont_warn);  int
> > xlu_cfg_get_long(const XLU_Config*, const char *n, long *value_r,
> >                       int dont_warn);
> > +int xlu_cfg_get_long_long(const XLU_Config*, const char *n, long
> long *value_r,
> > +                          int dont_warn);
> >
> >  int xlu_cfg_get_list(const XLU_Config*, const char *n,
> >                       XLU_ConfigList **list_r /* may be 0 */, diff
> -r
> > 3c4c29899d8a -r 94a17182f386 tools/libxl/xl_cmdimpl.c
> > --- a/tools/libxl/xl_cmdimpl.c      Wed Nov 30 07:18:11 2011 -0800
> > +++ b/tools/libxl/xl_cmdimpl.c      Wed Nov 30 20:51:07 2011 +0000
> > @@ -573,6 +573,7 @@ static void parse_config_data(const char  {
> >      const char *buf;
> >      long l;
> > +    long long ll;
> >      XLU_Config *config;
> >      XLU_ConfigList *vbds, *nics, *pcis, *cvfbs, *cpuids;
> >      int pci_power_mgmt = 0;
> > @@ -764,6 +765,8 @@ static void parse_config_data(const char
> >              b_info->u.hvm.timer_mode = l;
> >          if (!xlu_cfg_get_long (config, "nestedhvm", &l, 0))
> >              b_info->u.hvm.nested_hvm = l;
> > +        if (!xlu_cfg_get_long_long (config, "generation_id", &ll,
> 0))
> > +            b_info->u.hvm.nested_hvm = ll;
> >          break;
> >      case LIBXL_DOMAIN_TYPE_PV:
> >      {
> > diff -r 3c4c29899d8a -r 94a17182f386
> tools/python/xen/lowlevel/checkpoint/libcheckpoint.c
> > --- a/tools/python/xen/lowlevel/checkpoint/libcheckpoint.c  Wed
> Nov 30 07:18:11 2011 -0800
> > +++ b/tools/python/xen/lowlevel/checkpoint/libcheckpoint.c  Wed
> Nov 30 20:51:07 2011 +0000
> > @@ -174,6 +174,7 @@ int checkpoint_start(checkpoint_state* s  {
> >      int hvm, rc;
> >      int flags = XCFLAGS_LIVE;
> > +    unsigned long vm_gid_addr;
> >
> >      if (!s->domid) {
> >         s->errstr = "checkpoint state not opened"; @@ -184,14
> +185,25
> > @@ int checkpoint_start(checkpoint_state* s
> >
> >      hvm = s->domtype > dt_pv;
> >      if (hvm) {
> > +       char path[128];
> > +       char *addr;
> > +
> > +       sprintf(path, "/local/domain/%u/data/generation-id", s-
> >domid);
> > +       addr = xs_read(s->xsh, XBT_NULL, path, NULL);
> > +
> > +       vm_gid_addr = (addr) ? strtoul(addr, NULL, 0) : 0;
> > +       free(addr);
> > +
> >         flags |= XCFLAGS_HVM;
> >         if (switch_qemu_logdirty(s, 1))
> >             return -1;
> > +    } else {
> > +       vm_gid_addr = 0;
> >      }
> >
> >      callbacks->switch_qemu_logdirty = noop_switch_logdirty;
> >
> > -    rc = xc_domain_save(s->xch, fd, s->domid, 0, 0, flags,
> callbacks, hvm);
> > +    rc = xc_domain_save(s->xch, fd, s->domid, 0, 0, flags,
> callbacks,
> > + hvm, vm_gid_addr);
> >
> >      if (hvm)
> >         switch_qemu_logdirty(s, 0);
> > diff -r 3c4c29899d8a -r 94a17182f386 tools/xcutils/xc_restore.c
> > --- a/tools/xcutils/xc_restore.c    Wed Nov 30 07:18:11 2011 -0800
> > +++ b/tools/xcutils/xc_restore.c    Wed Nov 30 20:51:07 2011 +0000
> > @@ -23,7 +23,8 @@ main(int argc, char **argv)
> >      xc_interface *xch;
> >      int io_fd, ret;
> >      int superpages;
> > -    unsigned long store_mfn, console_mfn;
> > +    unsigned long store_mfn, console_mfn, vm_gid_addr;
> > +    uint64_t gid;
> >
> >      if ( (argc != 8) && (argc != 9) )
> >          errx(1, "usage: %s iofd domid store_evtchn "
> > @@ -40,19 +41,25 @@ main(int argc, char **argv)
> >      hvm  = atoi(argv[5]);
> >      pae  = atoi(argv[6]);
> >      apic = atoi(argv[7]);
> > -    if ( argc == 9 )
> > +    if ( argc >= 9 )
> >         superpages = atoi(argv[8]);
> >      else
> >         superpages = !!hvm;
> > +    if ( argc >= 10 )
> > +       gid = strtoll(argv[9], NULL, 0);
> > +    else
> > +       gid = 0;
> >
> >      ret = xc_domain_restore(xch, io_fd, domid, store_evtchn,
> &store_mfn,
> > -                            console_evtchn, &console_mfn, hvm,
> pae, superpages);
> > +                            console_evtchn, &console_mfn, hvm,
> pae, superpages,
> > +                            gid, &vm_gid_addr);
> >
> >      if ( ret == 0 )
> >      {
> >     printf("store-mfn %li\n", store_mfn);
> >          if ( !hvm )
> >              printf("console-mfn %li\n", console_mfn);
> > +   printf("vm-gid-addr %lx\n", vm_gid_addr);
> >     fflush(stdout);
> >      }
> >
> > diff -r 3c4c29899d8a -r 94a17182f386 tools/xcutils/xc_save.c
> > --- a/tools/xcutils/xc_save.c       Wed Nov 30 07:18:11 2011 -0800
> > +++ b/tools/xcutils/xc_save.c       Wed Nov 30 20:51:07 2011 +0000
> > @@ -169,6 +169,10 @@ main(int argc, char **argv)
> >      unsigned int maxit, max_f;
> >      int io_fd, ret, port;
> >      struct save_callbacks callbacks;
> > +    char path[128];
> > +    struct xs_handle *xs;
> > +    char *addr;
> > +    unsigned long vm_gid_addr;
> >
> >      if (argc != 6)
> >          errx(1, "usage: %s iofd domid maxit maxf flags",
> argv[0]); @@
> > -207,8 +211,21 @@ main(int argc, char **argv)
> >      memset(&callbacks, 0, sizeof(callbacks));
> >      callbacks.suspend = suspend;
> >      callbacks.switch_qemu_logdirty = switch_qemu_logdirty;
> > +
> > +    sprintf(path, "/local/domain/%d/data/generation-id",
> si.domid);
> > +
> > +    if ((xs = xs_daemon_open()) == NULL)
> > +        errx(1, "Couldn't contact xenstore");
> > +
> > +    addr = xs_read(xs, XBT_NULL, path, NULL);
> > +
> > +    xs_daemon_close(xs);
> > +
> > +    vm_gid_addr = (addr) ? strtoul(addr, NULL, 0) : 0;
> > +    free(addr);
> > +
> >      ret = xc_domain_save(si.xch, io_fd, si.domid, maxit, max_f,
> si.flags,
> > -                         &callbacks, !!(si.flags & XCFLAGS_HVM));
> > +                         &callbacks, !!(si.flags & XCFLAGS_HVM),
> > + vm_gid_addr);
> >
> >      if (si.suspend_evtchn > 0)
> >      xc_suspend_evtchn_release(si.xch, si.xce, si.domid,
> > si.suspend_evtchn);
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xensource.com
> > http://lists.xensource.com/xen-devel

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 08:47:27 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 08:47:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW2IF-0007xb-SY; Thu, 01 Dec 2011 08:46:59 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RW2ID-0007wy-W1
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 08:46:58 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1322729177!3761102!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTM2Mw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18823 invoked from network); 1 Dec 2011 08:46:18 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 08:46:18 -0000
X-IronPort-AV: E=Sophos;i="4.71,277,1320624000"; 
   d="scan'208";a="9222356"
Received: from lonpmailmx02.citrite.net ([10.30.203.163])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Dec 2011 08:46:17 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.161]) by
	LONPMAILMX02.citrite.net ([10.30.203.163]) with mapi; Thu, 1 Dec 2011
	08:46:17 +0000
From: Paul Durrant <Paul.Durrant@citrix.com>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
Date: Thu, 1 Dec 2011 08:46:18 +0000
Thread-Topic: [Xen-devel] [PATCH] Add code to track the address of the VM
	generation id buffer across a
Thread-Index: AcyvrWwIYFt1gilVTJKn52jeOWWt6wAV+a/w
Message-ID: <291EDFCB1E9E224A99088639C4762022B5988E50D4@LONPMAILBOX01.citrite.net>
References: <94a17182f386c8bb414e.1322686717@cosworth.uk.xensource.com>
	<20111130221419.GA16651@andromeda.dapyr.net>
In-Reply-To: <20111130221419.GA16651@andromeda.dapyr.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] Add code to track the address of the VM
 generation id buffer across a
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Konrad,

  Did you see my previous patch set? The introductory comment was:

-----
The following is a revised patch series to add support for a VM generation ID virtual device for HVM guests.
The basic requirements of this device are as follows:

- It must be exposed somewhere in ACPI namespace with a _CID of
  "VM_Gen_Counter".
- It must also include a _DDN of "VM_Gen_Counter".
- It must contain a _HID object but no particular value is
  required.
- It must expose a package called ADDR which evaluates to two
  integers; the first being the low order 32-bits of a guest
  physical address (GPA), the second by the high order 32-bits of
  the GPA. This GPA is the address of an 8-byte aligned 8-byte
  buffer containing the VM generation ID.
  This buffer must not be in ranges supported as AddressRangeMemory
  or AddressRangeACPI and must not be mapped by any PTE with caching
  disabled.

The semantics of the VM generation ID itself are left up to the tools but it must be possible to change it each time the VM is booted, migrated, or restored from a saved image.
-----

  Does that help?

    Paul

> -----Original Message-----
> From: Konrad Rzeszutek Wilk [mailto:konrad@darnok.org]
> Sent: 30 November 2011 22:14
> To: Paul Durrant
> Cc: xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] [PATCH] Add code to track the address of
> the VM generation id buffer across a
>
> On Wed, Nov 30, 2011 at 08:58:37PM +0000, Paul Durrant wrote:
> > # HG changeset patch
> > # User Paul Durrant <paul.durrant@citrix.com> # Date 1322686267 0
> #
> > Node ID 94a17182f386c8bb414eba55dddf763b8982c76d
> > # Parent  3c4c29899d8a2a0c0f9109b7236da95bb72b77b6
> > Add code to track the address of the VM generation id buffer
> across a
> > save/restore or migrate and inject a new value.
>
> So what is a generation id? What is the use-case for this?
>
> > The address of the buffer is written into xenstore by hvmloader at
> > boot time. It must be read from xenstore by the caller of
> > xc_domain_save() and then written back again by the caller of
> > xc_domain_restore().
> >
> > Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
> >
> > diff -r 3c4c29899d8a -r 94a17182f386
> tools/libxc/ia64/xc_ia64_linux_restore.c
> > --- a/tools/libxc/ia64/xc_ia64_linux_restore.c      Wed Nov 30
> 07:18:11 2011 -0800
> > +++ b/tools/libxc/ia64/xc_ia64_linux_restore.c      Wed Nov 30
> 20:51:07 2011 +0000
> > @@ -548,7 +548,8 @@ int
> >  xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
> >                    unsigned int store_evtchn, unsigned long
> *store_mfn,
> >                    unsigned int console_evtchn, unsigned long
> *console_mfn,
> > -                  unsigned int hvm, unsigned int pae, int
> superpages)
> > +                  unsigned int hvm, unsigned int pae, int
> superpages,
> > +                  uint64_t gid)
> >  {
> >      DECLARE_DOMCTL;
> >      int rc = 1;
> > diff -r 3c4c29899d8a -r 94a17182f386
> tools/libxc/ia64/xc_ia64_linux_save.c
> > --- a/tools/libxc/ia64/xc_ia64_linux_save.c Wed Nov 30 07:18:11
> 2011 -0800
> > +++ b/tools/libxc/ia64/xc_ia64_linux_save.c Wed Nov 30 20:51:07
> 2011 +0000
> > @@ -382,7 +382,8 @@ out:
> >  int
> >  xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom,
> uint32_t max_iters,
> >                 uint32_t max_factor, uint32_t flags,
> > -               struct save_callbacks* callbacks, int hvm)
> > +               struct save_callbacks* callbacks, int hvm,
> > +               unsigned long vm_gid_addr)
> >  {
> >      DECLARE_DOMCTL;
> >      xc_dominfo_t info;
> > diff -r 3c4c29899d8a -r 94a17182f386
> tools/libxc/xc_domain_restore.c
> > --- a/tools/libxc/xc_domain_restore.c       Wed Nov 30 07:18:11 2011 -
> 0800
> > +++ b/tools/libxc/xc_domain_restore.c       Wed Nov 30 20:51:07 2011
> +0000
> > @@ -676,6 +676,7 @@ typedef struct {
> >      uint64_t console_pfn;
> >      uint64_t acpi_ioport_location;
> >      uint64_t viridian;
> > +    uint64_t vm_gid_addr;
> >  } pagebuf_t;
> >
> >  static int pagebuf_init(pagebuf_t* buf) @@ -820,6 +821,17 @@
> static
> > int pagebuf_get_one(xc_interface
> >          }
> >          return pagebuf_get_one(xch, ctx, buf, fd, dom);
> >
> > +    case XC_SAVE_ID_HVM_GENERATION_ID_ADDR:
> > +        /* Skip padding 4 bytes then read the generation id
> buffer location. */
> > +        if ( RDEXACT(fd, &buf->vm_gid_addr, sizeof(uint32_t)) ||
> > +             RDEXACT(fd, &buf->vm_gid_addr, sizeof(uint64_t)) )
> > +        {
> > +            PERROR("error read the generation id buffer
> location");
> > +            return -1;
> > +        }
> > +        DPRINTF("read generation id buffer address");
> > +        return pagebuf_get_one(xch, ctx, buf, fd, dom);
> > +
> >      default:
> >          if ( (count > MAX_BATCH_SIZE) || (count < 0) ) {
> >              ERROR("Max batch size exceeded (%d). Giving up.",
> count);
> > @@ -1186,7 +1198,8 @@ static int apply_batch(xc_interface *xch
> int
> > xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
> >                        unsigned int store_evtchn, unsigned long
> *store_mfn,
> >                        unsigned int console_evtchn, unsigned long
> *console_mfn,
> > -                      unsigned int hvm, unsigned int pae, int
> superpages)
> > +                      unsigned int hvm, unsigned int pae, int
> superpages,
> > +                      uint64_t gid, unsigned long *vm_gid_addr)
> >  {
> >      DECLARE_DOMCTL;
> >      int rc = 1, frc, i, j, n, m, pae_extended_cr3 = 0,
> > ext_vcpucontext = 0; @@ -1386,6 +1399,33 @@ int
> xc_domain_restore(xc_interface *xch,
> >                  xc_set_hvm_param(xch, dom, HVM_PARAM_VM86_TSS,
> pagebuf.vm86_tss);
> >              if ( pagebuf.console_pfn )
> >                  console_pfn = pagebuf.console_pfn;
> > +            if ( pagebuf.vm_gid_addr ) {
> > +                unsigned int offset;
> > +                unsigned char *buf;
> > +
> > +                /*
> > +                 * Map the VM generation id buffer and inject the
> new value.
> > +                 */
> > +
> > +                pfn = pagebuf.vm_gid_addr >> PAGE_SHIFT;
> > +                offset = pagebuf.vm_gid_addr & (PAGE_SIZE - 1);
> > +
> > +                if ( (pfn >= dinfo->p2m_size) ||
> > +                     (pfn_type[pfn] != XEN_DOMCTL_PFINFO_NOTAB) )
> > +                {
> > +                    ERROR("generation id buffer frame is bad");
> > +                    goto out;
> > +                }
> > +
> > +                mfn = ctx->p2m[pfn];
> > +                buf = xc_map_foreign_range(xch, dom, PAGE_SIZE,
> > +                                           PROT_READ |
> PROT_WRITE, mfn);
> > +                *(unsigned long long *)(buf + offset) = gid;
> > +                munmap(buf, PAGE_SIZE);
> > +
> > +                *vm_gid_addr = pagebuf.vm_gid_addr;
> > +            }
> > +
> >              break;  /* our work here is done */
> >          }
> >
> > diff -r 3c4c29899d8a -r 94a17182f386 tools/libxc/xc_domain_save.c
> > --- a/tools/libxc/xc_domain_save.c  Wed Nov 30 07:18:11 2011 -
> 0800
> > +++ b/tools/libxc/xc_domain_save.c  Wed Nov 30 20:51:07 2011
> +0000
> > @@ -754,7 +754,8 @@ static int save_tsc_info(xc_interface *x
> >
> >  int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom,
> uint32_t max_iters,
> >                     uint32_t max_factor, uint32_t flags,
> > -                   struct save_callbacks* callbacks, int hvm)
> > +                   struct save_callbacks* callbacks, int hvm,
> > +                   unsigned long vm_gid_addr)
> >  {
> >      xc_dominfo_t info;
> >      DECLARE_DOMCTL;
> > @@ -1460,6 +1461,16 @@ int xc_domain_save(xc_interface *xch, in
> >              uint64_t data;
> >          } chunk = { 0, };
> >
> > +        chunk.id = XC_SAVE_ID_HVM_GENERATION_ID_ADDR;
> > +        chunk.data = vm_gid_addr;
> > +
> > +        if ( (chunk.data != 0) &&
> > +             wrexact(io_fd, &chunk, sizeof(chunk)) )
> > +        {
> > +            PERROR("Error when writing the generation id buffer
> location for guest");
> > +            goto out;
> > +        }
> > +
> >          chunk.id = XC_SAVE_ID_HVM_IDENT_PT;
> >          chunk.data = 0;
> >          xc_get_hvm_param(xch, dom, HVM_PARAM_IDENT_PT, diff -r
> > 3c4c29899d8a -r 94a17182f386 tools/libxc/xenguest.h
> > --- a/tools/libxc/xenguest.h        Wed Nov 30 07:18:11 2011 -0800
> > +++ b/tools/libxc/xenguest.h        Wed Nov 30 20:51:07 2011 +0000
> > @@ -57,7 +57,8 @@ struct save_callbacks {
> >   */
> >  int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom,
> uint32_t max_iters,
> >                     uint32_t max_factor, uint32_t flags /*
> XCFLAGS_xxx */,
> > -                   struct save_callbacks* callbacks, int hvm);
> > +                   struct save_callbacks* callbacks, int hvm,
> > +                   unsigned long vm_gid_addr);
> >
> >
> >  /**
> > @@ -71,12 +72,15 @@ int xc_domain_save(xc_interface *xch, in
> >   * @parm hvm non-zero if this is a HVM restore
> >   * @parm pae non-zero if this HVM domain has PAE support enabled
> >   * @parm superpages non-zero to allocate guest memory with
> superpages
> > + * @parm gid the new generation id of the VM
> > + * @parm vm_gid_addr returned with the address of the generation
> id
> > + buffer
> >   * @return 0 on success, -1 on failure
> >   */
> >  int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
> >                        unsigned int store_evtchn, unsigned long
> *store_mfn,
> >                        unsigned int console_evtchn, unsigned long
> *console_mfn,
> > -                      unsigned int hvm, unsigned int pae, int
> superpages);
> > +                      unsigned int hvm, unsigned int pae, int
> superpages,
> > +                      uint64_t gid, unsigned long *vm_gid_addr);
> >  /**
> >   * xc_domain_restore writes a file to disk that contains the
> device
> >   * model saved state.
> > diff -r 3c4c29899d8a -r 94a17182f386 tools/libxc/xg_save_restore.h
> > --- a/tools/libxc/xg_save_restore.h Wed Nov 30 07:18:11 2011 -
> 0800
> > +++ b/tools/libxc/xg_save_restore.h Wed Nov 30 20:51:07 2011
> +0000
> > @@ -135,6 +135,7 @@
> >  #define XC_SAVE_ID_LAST_CHECKPOINT    -9 /* Commit to restoring
> after completion of current iteration. */
> >  #define XC_SAVE_ID_HVM_ACPI_IOPORTS_LOCATION -10
> >  #define XC_SAVE_ID_HVM_VIRIDIAN       -11
> > +#define XC_SAVE_ID_HVM_GENERATION_ID_ADDR -12
> >
> >  /*
> >  ** We process save/restore/migrate in batches of pages; the below
> > diff -r 3c4c29899d8a -r 94a17182f386 tools/libxl/libxl_create.c
> > --- a/tools/libxl/libxl_create.c    Wed Nov 30 07:18:11 2011 -0800
> > +++ b/tools/libxl/libxl_create.c    Wed Nov 30 20:51:07 2011 +0000
> > @@ -101,6 +101,7 @@ int libxl_init_build_info(libxl_ctx *ctx
> >          b_info->u.hvm.vpt_align = 1;
> >          b_info->u.hvm.timer_mode = 1;
> >          b_info->u.hvm.nested_hvm = 0;
> > +        b_info->u.hvm.generation_id = 0;
> >          break;
> >      case LIBXL_DOMAIN_TYPE_PV:
> >          b_info->u.pv.slack_memkb = 8 * 1024; @@ -191,13 +192,15
> @@
> > int libxl__domain_build(libxl__gc *gc,
> >          vments[4] = "start_time";
> >          vments[5] = libxl__sprintf(gc, "%lu.%02d",
> > start_time.tv_sec,(int)start_time.tv_usec/10000);
> >
> > -        localents = libxl__calloc(gc, 7, sizeof(char *));
> > +        localents = libxl__calloc(gc, 9, sizeof(char *));
> >          localents[0] = "platform/acpi";
> >          localents[1] = (info->u.hvm.acpi) ? "1" : "0";
> >          localents[2] = "platform/acpi_s3";
> >          localents[3] = (info->u.hvm.acpi_s3) ? "1" : "0";
> >          localents[4] = "platform/acpi_s4";
> >          localents[5] = (info->u.hvm.acpi_s4) ? "1" : "0";
> > +        localents[6] = "platform/generation_id";
> > +        localents[7] = libxl__sprintf(gc, "0x%llx",
> > + info->u.hvm.generation_id);
> >
> >          break;
> >      case LIBXL_DOMAIN_TYPE_PV:
> > diff -r 3c4c29899d8a -r 94a17182f386 tools/libxl/libxl_dom.c
> > --- a/tools/libxl/libxl_dom.c       Wed Nov 30 07:18:11 2011 -0800
> > +++ b/tools/libxl/libxl_dom.c       Wed Nov 30 20:51:07 2011 +0000
> > @@ -125,7 +125,7 @@ int libxl__build_post(libxl__gc *gc, uin
> >      if (info->cpuid != NULL)
> >          libxl_cpuid_set(ctx, domid, info->cpuid);
> >
> > -    ents = libxl__calloc(gc, 12 + (info->max_vcpus * 2) + 2,
> sizeof(char *));
> > +    ents = libxl__calloc(gc, 14 + (info->max_vcpus * 2) + 2,
> > + sizeof(char *));
> >      ents[0] = "memory/static-max";
> >      ents[1] = libxl__sprintf(gc, "%d", info->max_memkb);
> >      ents[2] = "memory/target";
> > @@ -138,9 +138,11 @@ int libxl__build_post(libxl__gc *gc, uin
> >      ents[9] = libxl__sprintf(gc, "%"PRIu32, state->store_port);
> >      ents[10] = "store/ring-ref";
> >      ents[11] = libxl__sprintf(gc, "%lu", state->store_mfn);
> > +    ents[12] = "data/generation-id";
> > +    ents[13] = libxl__sprintf(gc, "0x%lx", state->vm_gid_addr);
> >      for (i = 0; i < info->max_vcpus; i++) {
> > -        ents[12+(i*2)]   = libxl__sprintf(gc,
> "cpu/%d/availability", i);
> > -        ents[12+(i*2)+1] = (i && info->cur_vcpus && !(info-
> >cur_vcpus & (1 << i)))
> > +        ents[14+(i*2)]   = libxl__sprintf(gc,
> "cpu/%d/availability", i);
> > +        ents[14+(i*2)+1] = (i && info->cur_vcpus && !(info-
> >cur_vcpus
> > + & (1 << i)))
> >                              ? "offline" : "online";
> >      }
> >
> > @@ -357,16 +359,19 @@ int libxl__domain_restore_common(libxl__
> >      /* read signature */
> >      int rc;
> >      int hvm, pae, superpages;
> > +    uint64_t gid;
> >      switch (info->type) {
> >      case LIBXL_DOMAIN_TYPE_HVM:
> >          hvm = 1;
> >          superpages = 1;
> >          pae = info->u.hvm.pae;
> > +        gid = info->u.hvm.generation_id;
> >          break;
> >      case LIBXL_DOMAIN_TYPE_PV:
> >          hvm = 0;
> >          superpages = 0;
> >          pae = 1;
> > +        gid = 0;
> >          break;
> >      default:
> >          return ERROR_INVAL;
> > @@ -374,7 +379,7 @@ int libxl__domain_restore_common(libxl__
> >      rc = xc_domain_restore(ctx->xch, fd, domid,
> >                             state->store_port, &state->store_mfn,
> >                             state->console_port, &state-
> >console_mfn,
> > -                           hvm, pae, superpages);
> > +                           hvm, pae, superpages, gid,
> > + &state->vm_gid_addr);
> >      if ( rc ) {
> >          LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "restoring
> domain");
> >          return ERROR_FAIL;
> > @@ -540,12 +545,22 @@ int libxl__domain_suspend_common(libxl__
> >      struct save_callbacks callbacks;
> >      struct suspendinfo si;
> >      int hvm, rc = ERROR_FAIL;
> > +    unsigned long vm_gid_addr;
> >
> >      switch (type) {
> > -    case LIBXL_DOMAIN_TYPE_HVM:
> > +    case LIBXL_DOMAIN_TYPE_HVM: {
> > +        char *path;
> > +        char *addr;
> > +
> > +        path = libxl__sprintf(gc, "%s/data/generation-id",
> libxl__xs_get_dompath(gc, domid));
> > +        addr = libxl__xs_read(gc, XBT_NULL, path);
> > +
> > +        vm_gid_addr = (addr) ? strtoul(addr, NULL, 0) : 0;
> >          hvm = 1;
> >          break;
> > +    }
> >      case LIBXL_DOMAIN_TYPE_PV:
> > +        vm_gid_addr = 0;
> >          hvm = 0;
> >          break;
> >      default:
> > @@ -583,7 +598,8 @@ int libxl__domain_suspend_common(libxl__
> >      callbacks.switch_qemu_logdirty =
> libxl__domain_suspend_common_switch_qemu_logdirty;
> >      callbacks.data = &si;
> >
> > -    rc = xc_domain_save(ctx->xch, fd, domid, 0, 0, flags,
> &callbacks, hvm);
> > +    rc = xc_domain_save(ctx->xch, fd, domid, 0, 0, flags,
> &callbacks,
> > +                        hvm, vm_gid_addr);
> >      if ( rc ) {
> >          LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "saving domain:
> %s",
> >                           si.guest_responded ?
> > diff -r 3c4c29899d8a -r 94a17182f386 tools/libxl/libxl_internal.h
> > --- a/tools/libxl/libxl_internal.h  Wed Nov 30 07:18:11 2011 -
> 0800
> > +++ b/tools/libxl/libxl_internal.h  Wed Nov 30 20:51:07 2011
> +0000
> > @@ -199,6 +199,8 @@ typedef struct {
> >
> >      uint32_t console_port;
> >      unsigned long console_mfn;
> > +
> > +    unsigned long vm_gid_addr;
> >  } libxl__domain_build_state;
> >
> >  _hidden int libxl__build_pre(libxl__gc *gc, uint32_t domid, diff
> -r
> > 3c4c29899d8a -r 94a17182f386 tools/libxl/libxl_types.idl
> > --- a/tools/libxl/libxl_types.idl   Wed Nov 30 07:18:11 2011 -
> 0800
> > +++ b/tools/libxl/libxl_types.idl   Wed Nov 30 20:51:07 2011
> +0000
> > @@ -183,6 +183,7 @@ libxl_domain_build_info = Struct("domain
> >                                         ("vpt_align", bool),
> >                                         ("timer_mode", integer),
> >                                         ("nested_hvm", bool),
> > +                                       ("generation_id", uint64),
> >                                         ])),
> >                   ("pv", Struct(None, [("kernel",
> libxl_file_reference),
> >                                        ("slack_memkb", uint32),
> diff
> > -r 3c4c29899d8a -r 94a17182f386 tools/libxl/libxlu_cfg.c
> > --- a/tools/libxl/libxlu_cfg.c      Wed Nov 30 07:18:11 2011 -0800
> > +++ b/tools/libxl/libxlu_cfg.c      Wed Nov 30 20:51:07 2011 +0000
> > @@ -235,6 +235,37 @@ int xlu_cfg_get_long(const XLU_Config *c
> >      return 0;
> >  }
> >
> > +int xlu_cfg_get_long_long(const XLU_Config *cfg, const char *n,
> > +                          long long *value_r, int dont_warn) {
> > +    long long ll;
> > +    XLU_ConfigSetting *set;
> > +    int e;
> > +    char *ep;
> > +
> > +    e= find_atom(cfg,n,&set,dont_warn);  if (e) return e;
> > +    errno= 0; ll= strtoll(set->values[0], &ep, 0);
> > +    e= errno;
> > +    if (errno) {
> > +        e= errno;
> > +        assert(e==EINVAL || e==ERANGE);
> > +        if (!dont_warn)
> > +            fprintf(cfg->report,
> > +                    "%s:%d: warning: parameter `%s' could not be
> parsed"
> > +                    " as a number: %s\n",
> > +                    cfg->filename, set->lineno, n, strerror(e));
> > +        return e;
> > +    }
> > +    if (*ep || ep==set->values[0]) {
> > +        if (!dont_warn)
> > +            fprintf(cfg->report,
> > +                    "%s:%d: warning: parameter `%s' is not a
> valid number\n",
> > +                    cfg->filename, set->lineno, n);
> > +        return EINVAL;
> > +    }
> > +    *value_r= ll;
> > +    return 0;
> > +}
> > +
> >
> >  int xlu_cfg_get_list(const XLU_Config *cfg, const char *n,
> >                       XLU_ConfigList **list_r, int *entries_r, int
> > dont_warn) { diff -r 3c4c29899d8a -r 94a17182f386
> tools/libxl/libxlutil.h
> > --- a/tools/libxl/libxlutil.h       Wed Nov 30 07:18:11 2011 -0800
> > +++ b/tools/libxl/libxlutil.h       Wed Nov 30 20:51:07 2011 +0000
> > @@ -52,6 +52,8 @@ int xlu_cfg_replace_string(const XLU_Con
> >                             char **value_r, int dont_warn);  int
> > xlu_cfg_get_long(const XLU_Config*, const char *n, long *value_r,
> >                       int dont_warn);
> > +int xlu_cfg_get_long_long(const XLU_Config*, const char *n, long
> long *value_r,
> > +                          int dont_warn);
> >
> >  int xlu_cfg_get_list(const XLU_Config*, const char *n,
> >                       XLU_ConfigList **list_r /* may be 0 */, diff
> -r
> > 3c4c29899d8a -r 94a17182f386 tools/libxl/xl_cmdimpl.c
> > --- a/tools/libxl/xl_cmdimpl.c      Wed Nov 30 07:18:11 2011 -0800
> > +++ b/tools/libxl/xl_cmdimpl.c      Wed Nov 30 20:51:07 2011 +0000
> > @@ -573,6 +573,7 @@ static void parse_config_data(const char  {
> >      const char *buf;
> >      long l;
> > +    long long ll;
> >      XLU_Config *config;
> >      XLU_ConfigList *vbds, *nics, *pcis, *cvfbs, *cpuids;
> >      int pci_power_mgmt = 0;
> > @@ -764,6 +765,8 @@ static void parse_config_data(const char
> >              b_info->u.hvm.timer_mode = l;
> >          if (!xlu_cfg_get_long (config, "nestedhvm", &l, 0))
> >              b_info->u.hvm.nested_hvm = l;
> > +        if (!xlu_cfg_get_long_long (config, "generation_id", &ll,
> 0))
> > +            b_info->u.hvm.nested_hvm = ll;
> >          break;
> >      case LIBXL_DOMAIN_TYPE_PV:
> >      {
> > diff -r 3c4c29899d8a -r 94a17182f386
> tools/python/xen/lowlevel/checkpoint/libcheckpoint.c
> > --- a/tools/python/xen/lowlevel/checkpoint/libcheckpoint.c  Wed
> Nov 30 07:18:11 2011 -0800
> > +++ b/tools/python/xen/lowlevel/checkpoint/libcheckpoint.c  Wed
> Nov 30 20:51:07 2011 +0000
> > @@ -174,6 +174,7 @@ int checkpoint_start(checkpoint_state* s  {
> >      int hvm, rc;
> >      int flags = XCFLAGS_LIVE;
> > +    unsigned long vm_gid_addr;
> >
> >      if (!s->domid) {
> >         s->errstr = "checkpoint state not opened"; @@ -184,14
> +185,25
> > @@ int checkpoint_start(checkpoint_state* s
> >
> >      hvm = s->domtype > dt_pv;
> >      if (hvm) {
> > +       char path[128];
> > +       char *addr;
> > +
> > +       sprintf(path, "/local/domain/%u/data/generation-id", s-
> >domid);
> > +       addr = xs_read(s->xsh, XBT_NULL, path, NULL);
> > +
> > +       vm_gid_addr = (addr) ? strtoul(addr, NULL, 0) : 0;
> > +       free(addr);
> > +
> >         flags |= XCFLAGS_HVM;
> >         if (switch_qemu_logdirty(s, 1))
> >             return -1;
> > +    } else {
> > +       vm_gid_addr = 0;
> >      }
> >
> >      callbacks->switch_qemu_logdirty = noop_switch_logdirty;
> >
> > -    rc = xc_domain_save(s->xch, fd, s->domid, 0, 0, flags,
> callbacks, hvm);
> > +    rc = xc_domain_save(s->xch, fd, s->domid, 0, 0, flags,
> callbacks,
> > + hvm, vm_gid_addr);
> >
> >      if (hvm)
> >         switch_qemu_logdirty(s, 0);
> > diff -r 3c4c29899d8a -r 94a17182f386 tools/xcutils/xc_restore.c
> > --- a/tools/xcutils/xc_restore.c    Wed Nov 30 07:18:11 2011 -0800
> > +++ b/tools/xcutils/xc_restore.c    Wed Nov 30 20:51:07 2011 +0000
> > @@ -23,7 +23,8 @@ main(int argc, char **argv)
> >      xc_interface *xch;
> >      int io_fd, ret;
> >      int superpages;
> > -    unsigned long store_mfn, console_mfn;
> > +    unsigned long store_mfn, console_mfn, vm_gid_addr;
> > +    uint64_t gid;
> >
> >      if ( (argc != 8) && (argc != 9) )
> >          errx(1, "usage: %s iofd domid store_evtchn "
> > @@ -40,19 +41,25 @@ main(int argc, char **argv)
> >      hvm  = atoi(argv[5]);
> >      pae  = atoi(argv[6]);
> >      apic = atoi(argv[7]);
> > -    if ( argc == 9 )
> > +    if ( argc >= 9 )
> >         superpages = atoi(argv[8]);
> >      else
> >         superpages = !!hvm;
> > +    if ( argc >= 10 )
> > +       gid = strtoll(argv[9], NULL, 0);
> > +    else
> > +       gid = 0;
> >
> >      ret = xc_domain_restore(xch, io_fd, domid, store_evtchn,
> &store_mfn,
> > -                            console_evtchn, &console_mfn, hvm,
> pae, superpages);
> > +                            console_evtchn, &console_mfn, hvm,
> pae, superpages,
> > +                            gid, &vm_gid_addr);
> >
> >      if ( ret == 0 )
> >      {
> >     printf("store-mfn %li\n", store_mfn);
> >          if ( !hvm )
> >              printf("console-mfn %li\n", console_mfn);
> > +   printf("vm-gid-addr %lx\n", vm_gid_addr);
> >     fflush(stdout);
> >      }
> >
> > diff -r 3c4c29899d8a -r 94a17182f386 tools/xcutils/xc_save.c
> > --- a/tools/xcutils/xc_save.c       Wed Nov 30 07:18:11 2011 -0800
> > +++ b/tools/xcutils/xc_save.c       Wed Nov 30 20:51:07 2011 +0000
> > @@ -169,6 +169,10 @@ main(int argc, char **argv)
> >      unsigned int maxit, max_f;
> >      int io_fd, ret, port;
> >      struct save_callbacks callbacks;
> > +    char path[128];
> > +    struct xs_handle *xs;
> > +    char *addr;
> > +    unsigned long vm_gid_addr;
> >
> >      if (argc != 6)
> >          errx(1, "usage: %s iofd domid maxit maxf flags",
> argv[0]); @@
> > -207,8 +211,21 @@ main(int argc, char **argv)
> >      memset(&callbacks, 0, sizeof(callbacks));
> >      callbacks.suspend = suspend;
> >      callbacks.switch_qemu_logdirty = switch_qemu_logdirty;
> > +
> > +    sprintf(path, "/local/domain/%d/data/generation-id",
> si.domid);
> > +
> > +    if ((xs = xs_daemon_open()) == NULL)
> > +        errx(1, "Couldn't contact xenstore");
> > +
> > +    addr = xs_read(xs, XBT_NULL, path, NULL);
> > +
> > +    xs_daemon_close(xs);
> > +
> > +    vm_gid_addr = (addr) ? strtoul(addr, NULL, 0) : 0;
> > +    free(addr);
> > +
> >      ret = xc_domain_save(si.xch, io_fd, si.domid, maxit, max_f,
> si.flags,
> > -                         &callbacks, !!(si.flags & XCFLAGS_HVM));
> > +                         &callbacks, !!(si.flags & XCFLAGS_HVM),
> > + vm_gid_addr);
> >
> >      if (si.suspend_evtchn > 0)
> >      xc_suspend_evtchn_release(si.xch, si.xce, si.domid,
> > si.suspend_evtchn);
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xensource.com
> > http://lists.xensource.com/xen-devel

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 08:56:50 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 08:56:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW2RP-0008NZ-54; Thu, 01 Dec 2011 08:56:27 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <niall.fleming@webanywhere.co.uk>) id 1RW2RO-0008NR-AI
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 08:56:26 +0000
X-Env-Sender: niall.fleming@webanywhere.co.uk
X-Msg-Ref: server-10.tower-182.messagelabs.com!1322729746!5411586!1
X-Originating-IP: [212.227.126.187]
X-SpamReason: No, hits=0.6 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMTIuMjI3LjEyNi4xODcgPT4gNzMxMTg=\n,sa_preprocessor: 
	QmFkIElQOiAyMTIuMjI3LjEyNi4xODcgPT4gNzMxMTg=\n, HTML_40_50, HTML_MESSAGE
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25304 invoked from network); 1 Dec 2011 08:55:46 -0000
Received: from moutng.kundenserver.de (HELO moutng.kundenserver.de)
	(212.227.126.187) by server-10.tower-182.messagelabs.com with SMTP;
	1 Dec 2011 08:55:46 -0000
Received: from [192.168.80.60] (host81-130-62-168.in-addr.btopenworld.com
	[81.130.62.168])
	by mrelayeu.kundenserver.de (node=mrbap3) with ESMTP (Nemesis)
	id 0M8zxV-1Rfi7f3497-00Cgpt; Thu, 01 Dec 2011 09:55:27 +0100
Message-ID: <4ED740FD.4070603@webanywhere.co.uk>
Date: Thu, 01 Dec 2011 08:55:25 +0000
From: Niall Fleming <niall.fleming@webanywhere.co.uk>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
References: <4EBD5AA0.3090906@webanywhere.co.uk>
	<20111111183913.GA9283@phenom.dumpdata.com>
	<4EC0F20D0200007800060B7D@nat28.tlf.novell.com>
	<20111114180045.GA14517@phenom.dumpdata.com>
	<4EC16CA7.70901@goop.org>
	<20111116142604.GA7476@phenom.dumpdata.com>
	<4ED662B0.8060105@webanywhere.co.uk>
	<20111130222628.GE16651@andromeda.dapyr.net>
In-Reply-To: <20111130222628.GE16651@andromeda.dapyr.net>
X-Provags-ID: V02:K0:wDLOOuUjKFdV4BC6jQkZw/OTdmXINFakTrMqG7AjZ3n
	nBmhYDkUPIv/QoIlUEDK2tWezi9FHVpSzrnl+mg5hDu9ly/bPl
	ZJxFyDl18T7pFGNF/Ib3fUqyP1OxTuWzYJjz0cGKQu07U52oZS
	BSwkWe2DsmTWqbsr6S2/49LaJ83sF/fNWDE1RUvWmO/EvQ6yGG
	UA0IVIUAZXi3EtVWJISezKCooqlbY6Ct23zIx8y3vshdAMxyjW
	xeipzEz2pDUBNWGQF2qDw5SPuoPIcoMpxzUxmC/NMVU6LSikiX
	O6RCkMct1+T8Nhb+cOJYd4zOWJ7uInUoFstATIhnuYajDCwmsC
	IVsXASNp+9lN3dj1SX/1V17iFHe+zQkIYQW6V1UC0
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	keir.xen@gmail.com, Jan Beulich <JBeulich@suse.com>,
	pbonzini@redhat.com, lersek@redhat.com
Subject: Re: [Xen-devel] Time Change Issue Xen 4.1
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6540729954828015765=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

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

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

Cheers, at least I know that someone is still looking at it!

If someone could give me a general timeframe, like it'll be a month, 
before we fix it, or
two weeks or whatever, I just need to give my line manager something so 
he gets off my
case about it!


*Niall Fleming BSc. (Hons)*
Systems Administrator
Webanywhere Limited

Phone: 0800 862 0131 Ext: 203
Web: http://www.webanywhere.co.uk

Aire Valley Business Centre, Lawkholme Lane, Keighley, BD21 3BB
Registered in England with company number 4881346

On 30/11/2011 22:26, Konrad Rzeszutek Wilk wrote:
> On Wed, Nov 30, 2011 at 05:06:56PM +0000, Niall Fleming wrote:
>> Another week, and no response?
> I am sooo tempted to make a time joke :-)
>> ping?
> We are just swamped.<sigh>  Wish I had a better response,
> like: Try this patch, but not yet.
>
>> Please?
>>
>> *Niall Fleming BSc. (Hons)*
>> Systems Administrator
>> Webanywhere Limited
>>
>> Phone: 0800 862 0131 Ext: 203
>> Web: http://www.webanywhere.co.uk
>>
>> Aire Valley Business Centre, Lawkholme Lane, Keighley, BD21 3BB
>> Registered in England with company number 4881346
>>
>> On 16/11/2011 14:26, Konrad Rzeszutek Wilk wrote:
>>> On Mon, Nov 14, 2011 at 11:31:51AM -0800, Jeremy Fitzhardinge wrote:
>>>> On 11/14/2011 10:00 AM, Konrad Rzeszutek Wilk wrote:
>>>>> Right. With those patches too (he used the xen-settime patch set which
>>>>> has it).
>>>>> The hypercall is done (and the do_settime gets called) and the results
>>>>> are saved
>>>>> in the RTC. And the wc_sec and wc_nsec are updated and propagated.
>>>>>
>>>>> The problem is that wc_sec and wc_nsec are only propagated to the
>>>>> existing guests.
>>>>>
>>>>> If you launch a new guest after the 'hwclock', the new guests
>>>>> retains the old wallclock time.
>>>> Existing (pvops) guests shouldn't see updated wallclock time, because
>>>> they never look at the hypervisor's wallclock after boot time.
>>>>
>>>> It's surprising that new guests don't see the updated wallclock though.
>>>> That sounds like a Xen issue.
>>> <nods>   That is what I think is happening here.
>>>
>>> _______________________________________________
>>> Xen-devel mailing list
>>> Xen-devel@lists.xensource.com
>>> http://lists.xensource.com/xen-devel
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel

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

<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Cheers, at least I know that someone is still looking at it!<br>
    <br>
    If someone could give me a general timeframe, like it'll be a month,
    before we fix it, or<br>
    two weeks or whatever, I just need to give my line manager something
    so he gets off my<br>
    case about it!<br>
    <br>
    <div class="moz-signature"><br>
      <b>Niall Fleming BSc. (Hons)</b><br>
      Systems Administrator<br>
      Webanywhere Limited<br>
      <br>
      Phone: 0800 862 0131 Ext: 203<br>
      Web: <a class="moz-txt-link-freetext" href="http://www.webanywhere.co.uk">http://www.webanywhere.co.uk</a><br>
      <br>
      Aire Valley Business Centre, Lawkholme Lane, Keighley, BD21 3BB<br>
      Registered in England with company number 4881346</div>
    <br>
    On 30/11/2011 22:26, Konrad Rzeszutek Wilk wrote:
    <blockquote cite="mid:20111130222628.GE16651@andromeda.dapyr.net"
      type="cite">
      <pre wrap="">On Wed, Nov 30, 2011 at 05:06:56PM +0000, Niall Fleming wrote:
</pre>
      <blockquote type="cite">
        <pre wrap="">Another week, and no response?
</pre>
      </blockquote>
      <pre wrap="">
I am sooo tempted to make a time joke :-)
</pre>
      <blockquote type="cite">
        <pre wrap="">
ping?
</pre>
      </blockquote>
      <pre wrap="">
We are just swamped. &lt;sigh&gt; Wish I had a better response,
like: Try this patch, but not yet.

</pre>
      <blockquote type="cite">
        <pre wrap="">
Please?

*Niall Fleming BSc. (Hons)*
Systems Administrator
Webanywhere Limited

Phone: 0800 862 0131 Ext: 203
Web: <a class="moz-txt-link-freetext" href="http://www.webanywhere.co.uk">http://www.webanywhere.co.uk</a>

Aire Valley Business Centre, Lawkholme Lane, Keighley, BD21 3BB
Registered in England with company number 4881346

On 16/11/2011 14:26, Konrad Rzeszutek Wilk wrote:
</pre>
        <blockquote type="cite">
          <pre wrap="">On Mon, Nov 14, 2011 at 11:31:51AM -0800, Jeremy Fitzhardinge wrote:
</pre>
          <blockquote type="cite">
            <pre wrap="">On 11/14/2011 10:00 AM, Konrad Rzeszutek Wilk wrote:
</pre>
            <blockquote type="cite">
              <pre wrap="">Right. With those patches too (he used the xen-settime patch set which 
has it).
The hypercall is done (and the do_settime gets called) and the results 
are saved
in the RTC. And the wc_sec and wc_nsec are updated and propagated.

The problem is that wc_sec and wc_nsec are only propagated to the
existing guests.

If you launch a new guest after the 'hwclock', the new guests
retains the old wallclock time.
</pre>
            </blockquote>
            <pre wrap="">Existing (pvops) guests shouldn't see updated wallclock time, because
they never look at the hypervisor's wallclock after boot time.

It's surprising that new guests don't see the updated wallclock though.
That sounds like a Xen issue.
</pre>
          </blockquote>
          <pre wrap="">&lt;nods&gt;  That is what I think is happening here.

_______________________________________________
Xen-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Xen-devel@lists.xensource.com">Xen-devel@lists.xensource.com</a>
<a class="moz-txt-link-freetext" href="http://lists.xensource.com/xen-devel">http://lists.xensource.com/xen-devel</a>
</pre>
        </blockquote>
      </blockquote>
      <pre wrap="">
</pre>
      <blockquote type="cite">
        <pre wrap="">_______________________________________________
Xen-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Xen-devel@lists.xensource.com">Xen-devel@lists.xensource.com</a>
<a class="moz-txt-link-freetext" href="http://lists.xensource.com/xen-devel">http://lists.xensource.com/xen-devel</a>

</pre>
      </blockquote>
      <pre wrap="">
</pre>
      <blockquote type="cite">
        <pre wrap="">_______________________________________________
Xen-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Xen-devel@lists.xensource.com">Xen-devel@lists.xensource.com</a>
<a class="moz-txt-link-freetext" href="http://lists.xensource.com/xen-devel">http://lists.xensource.com/xen-devel</a>
</pre>
      </blockquote>
      <pre wrap="">
</pre>
    </blockquote>
  </body>
</html>

--------------090609040509070806080705--


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

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

--===============6540729954828015765==--


From xen-devel-bounces@lists.xensource.com Thu Dec 01 08:56:50 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 08:56:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW2RP-0008NZ-54; Thu, 01 Dec 2011 08:56:27 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <niall.fleming@webanywhere.co.uk>) id 1RW2RO-0008NR-AI
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 08:56:26 +0000
X-Env-Sender: niall.fleming@webanywhere.co.uk
X-Msg-Ref: server-10.tower-182.messagelabs.com!1322729746!5411586!1
X-Originating-IP: [212.227.126.187]
X-SpamReason: No, hits=0.6 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMTIuMjI3LjEyNi4xODcgPT4gNzMxMTg=\n,sa_preprocessor: 
	QmFkIElQOiAyMTIuMjI3LjEyNi4xODcgPT4gNzMxMTg=\n, HTML_40_50, HTML_MESSAGE
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25304 invoked from network); 1 Dec 2011 08:55:46 -0000
Received: from moutng.kundenserver.de (HELO moutng.kundenserver.de)
	(212.227.126.187) by server-10.tower-182.messagelabs.com with SMTP;
	1 Dec 2011 08:55:46 -0000
Received: from [192.168.80.60] (host81-130-62-168.in-addr.btopenworld.com
	[81.130.62.168])
	by mrelayeu.kundenserver.de (node=mrbap3) with ESMTP (Nemesis)
	id 0M8zxV-1Rfi7f3497-00Cgpt; Thu, 01 Dec 2011 09:55:27 +0100
Message-ID: <4ED740FD.4070603@webanywhere.co.uk>
Date: Thu, 01 Dec 2011 08:55:25 +0000
From: Niall Fleming <niall.fleming@webanywhere.co.uk>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
References: <4EBD5AA0.3090906@webanywhere.co.uk>
	<20111111183913.GA9283@phenom.dumpdata.com>
	<4EC0F20D0200007800060B7D@nat28.tlf.novell.com>
	<20111114180045.GA14517@phenom.dumpdata.com>
	<4EC16CA7.70901@goop.org>
	<20111116142604.GA7476@phenom.dumpdata.com>
	<4ED662B0.8060105@webanywhere.co.uk>
	<20111130222628.GE16651@andromeda.dapyr.net>
In-Reply-To: <20111130222628.GE16651@andromeda.dapyr.net>
X-Provags-ID: V02:K0:wDLOOuUjKFdV4BC6jQkZw/OTdmXINFakTrMqG7AjZ3n
	nBmhYDkUPIv/QoIlUEDK2tWezi9FHVpSzrnl+mg5hDu9ly/bPl
	ZJxFyDl18T7pFGNF/Ib3fUqyP1OxTuWzYJjz0cGKQu07U52oZS
	BSwkWe2DsmTWqbsr6S2/49LaJ83sF/fNWDE1RUvWmO/EvQ6yGG
	UA0IVIUAZXi3EtVWJISezKCooqlbY6Ct23zIx8y3vshdAMxyjW
	xeipzEz2pDUBNWGQF2qDw5SPuoPIcoMpxzUxmC/NMVU6LSikiX
	O6RCkMct1+T8Nhb+cOJYd4zOWJ7uInUoFstATIhnuYajDCwmsC
	IVsXASNp+9lN3dj1SX/1V17iFHe+zQkIYQW6V1UC0
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	keir.xen@gmail.com, Jan Beulich <JBeulich@suse.com>,
	pbonzini@redhat.com, lersek@redhat.com
Subject: Re: [Xen-devel] Time Change Issue Xen 4.1
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6540729954828015765=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

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

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

Cheers, at least I know that someone is still looking at it!

If someone could give me a general timeframe, like it'll be a month, 
before we fix it, or
two weeks or whatever, I just need to give my line manager something so 
he gets off my
case about it!


*Niall Fleming BSc. (Hons)*
Systems Administrator
Webanywhere Limited

Phone: 0800 862 0131 Ext: 203
Web: http://www.webanywhere.co.uk

Aire Valley Business Centre, Lawkholme Lane, Keighley, BD21 3BB
Registered in England with company number 4881346

On 30/11/2011 22:26, Konrad Rzeszutek Wilk wrote:
> On Wed, Nov 30, 2011 at 05:06:56PM +0000, Niall Fleming wrote:
>> Another week, and no response?
> I am sooo tempted to make a time joke :-)
>> ping?
> We are just swamped.<sigh>  Wish I had a better response,
> like: Try this patch, but not yet.
>
>> Please?
>>
>> *Niall Fleming BSc. (Hons)*
>> Systems Administrator
>> Webanywhere Limited
>>
>> Phone: 0800 862 0131 Ext: 203
>> Web: http://www.webanywhere.co.uk
>>
>> Aire Valley Business Centre, Lawkholme Lane, Keighley, BD21 3BB
>> Registered in England with company number 4881346
>>
>> On 16/11/2011 14:26, Konrad Rzeszutek Wilk wrote:
>>> On Mon, Nov 14, 2011 at 11:31:51AM -0800, Jeremy Fitzhardinge wrote:
>>>> On 11/14/2011 10:00 AM, Konrad Rzeszutek Wilk wrote:
>>>>> Right. With those patches too (he used the xen-settime patch set which
>>>>> has it).
>>>>> The hypercall is done (and the do_settime gets called) and the results
>>>>> are saved
>>>>> in the RTC. And the wc_sec and wc_nsec are updated and propagated.
>>>>>
>>>>> The problem is that wc_sec and wc_nsec are only propagated to the
>>>>> existing guests.
>>>>>
>>>>> If you launch a new guest after the 'hwclock', the new guests
>>>>> retains the old wallclock time.
>>>> Existing (pvops) guests shouldn't see updated wallclock time, because
>>>> they never look at the hypervisor's wallclock after boot time.
>>>>
>>>> It's surprising that new guests don't see the updated wallclock though.
>>>> That sounds like a Xen issue.
>>> <nods>   That is what I think is happening here.
>>>
>>> _______________________________________________
>>> Xen-devel mailing list
>>> Xen-devel@lists.xensource.com
>>> http://lists.xensource.com/xen-devel
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel

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

<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Cheers, at least I know that someone is still looking at it!<br>
    <br>
    If someone could give me a general timeframe, like it'll be a month,
    before we fix it, or<br>
    two weeks or whatever, I just need to give my line manager something
    so he gets off my<br>
    case about it!<br>
    <br>
    <div class="moz-signature"><br>
      <b>Niall Fleming BSc. (Hons)</b><br>
      Systems Administrator<br>
      Webanywhere Limited<br>
      <br>
      Phone: 0800 862 0131 Ext: 203<br>
      Web: <a class="moz-txt-link-freetext" href="http://www.webanywhere.co.uk">http://www.webanywhere.co.uk</a><br>
      <br>
      Aire Valley Business Centre, Lawkholme Lane, Keighley, BD21 3BB<br>
      Registered in England with company number 4881346</div>
    <br>
    On 30/11/2011 22:26, Konrad Rzeszutek Wilk wrote:
    <blockquote cite="mid:20111130222628.GE16651@andromeda.dapyr.net"
      type="cite">
      <pre wrap="">On Wed, Nov 30, 2011 at 05:06:56PM +0000, Niall Fleming wrote:
</pre>
      <blockquote type="cite">
        <pre wrap="">Another week, and no response?
</pre>
      </blockquote>
      <pre wrap="">
I am sooo tempted to make a time joke :-)
</pre>
      <blockquote type="cite">
        <pre wrap="">
ping?
</pre>
      </blockquote>
      <pre wrap="">
We are just swamped. &lt;sigh&gt; Wish I had a better response,
like: Try this patch, but not yet.

</pre>
      <blockquote type="cite">
        <pre wrap="">
Please?

*Niall Fleming BSc. (Hons)*
Systems Administrator
Webanywhere Limited

Phone: 0800 862 0131 Ext: 203
Web: <a class="moz-txt-link-freetext" href="http://www.webanywhere.co.uk">http://www.webanywhere.co.uk</a>

Aire Valley Business Centre, Lawkholme Lane, Keighley, BD21 3BB
Registered in England with company number 4881346

On 16/11/2011 14:26, Konrad Rzeszutek Wilk wrote:
</pre>
        <blockquote type="cite">
          <pre wrap="">On Mon, Nov 14, 2011 at 11:31:51AM -0800, Jeremy Fitzhardinge wrote:
</pre>
          <blockquote type="cite">
            <pre wrap="">On 11/14/2011 10:00 AM, Konrad Rzeszutek Wilk wrote:
</pre>
            <blockquote type="cite">
              <pre wrap="">Right. With those patches too (he used the xen-settime patch set which 
has it).
The hypercall is done (and the do_settime gets called) and the results 
are saved
in the RTC. And the wc_sec and wc_nsec are updated and propagated.

The problem is that wc_sec and wc_nsec are only propagated to the
existing guests.

If you launch a new guest after the 'hwclock', the new guests
retains the old wallclock time.
</pre>
            </blockquote>
            <pre wrap="">Existing (pvops) guests shouldn't see updated wallclock time, because
they never look at the hypervisor's wallclock after boot time.

It's surprising that new guests don't see the updated wallclock though.
That sounds like a Xen issue.
</pre>
          </blockquote>
          <pre wrap="">&lt;nods&gt;  That is what I think is happening here.

_______________________________________________
Xen-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Xen-devel@lists.xensource.com">Xen-devel@lists.xensource.com</a>
<a class="moz-txt-link-freetext" href="http://lists.xensource.com/xen-devel">http://lists.xensource.com/xen-devel</a>
</pre>
        </blockquote>
      </blockquote>
      <pre wrap="">
</pre>
      <blockquote type="cite">
        <pre wrap="">_______________________________________________
Xen-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Xen-devel@lists.xensource.com">Xen-devel@lists.xensource.com</a>
<a class="moz-txt-link-freetext" href="http://lists.xensource.com/xen-devel">http://lists.xensource.com/xen-devel</a>

</pre>
      </blockquote>
      <pre wrap="">
</pre>
      <blockquote type="cite">
        <pre wrap="">_______________________________________________
Xen-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Xen-devel@lists.xensource.com">Xen-devel@lists.xensource.com</a>
<a class="moz-txt-link-freetext" href="http://lists.xensource.com/xen-devel">http://lists.xensource.com/xen-devel</a>
</pre>
      </blockquote>
      <pre wrap="">
</pre>
    </blockquote>
  </body>
</html>

--------------090609040509070806080705--


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

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

--===============6540729954828015765==--


From xen-devel-bounces@lists.xensource.com Thu Dec 01 09:00:05 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 09: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.xensource.com>)
	id 1RW2Ue-0008VS-Pu; Thu, 01 Dec 2011 08:59:48 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RW2Ud-0008VH-Cd
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 08:59:47 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1322729947!5736033!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU2Nw==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20483 invoked from network); 1 Dec 2011 08:59:07 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 08:59:07 -0000
X-IronPort-AV: E=Sophos;i="4.71,277,1320624000"; 
   d="scan'208";a="9222628"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Dec 2011 08:59:07 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 1 Dec 2011
	08:59:07 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Paul Durrant <Paul.Durrant@citrix.com>
Date: Thu, 1 Dec 2011 08:59:07 +0000
In-Reply-To: <291EDFCB1E9E224A99088639C4762022B5988E50D4@LONPMAILBOX01.citrite.net>
References: <94a17182f386c8bb414e.1322686717@cosworth.uk.xensource.com>
	<20111130221419.GA16651@andromeda.dapyr.net>
	<291EDFCB1E9E224A99088639C4762022B5988E50D4@LONPMAILBOX01.citrite.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322729947.31810.151.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] Add code to track the address of the VM
 generation id buffer across a
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2011-12-01 at 08:46 +0000, Paul Durrant wrote:
> Konrad,
> 
>   Did you see my previous patch set? The introductory comment was:


I think that description belongs somewhere permanent, either in
docs/misc or as a comment in an appropriate header.

Ian.

> 
> -----
> The following is a revised patch series to add support for a VM generation ID virtual device for HVM guests.
> The basic requirements of this device are as follows:
> 
> - It must be exposed somewhere in ACPI namespace with a _CID of
>   "VM_Gen_Counter".
> - It must also include a _DDN of "VM_Gen_Counter".
> - It must contain a _HID object but no particular value is
>   required.
> - It must expose a package called ADDR which evaluates to two
>   integers; the first being the low order 32-bits of a guest
>   physical address (GPA), the second by the high order 32-bits of
>   the GPA. This GPA is the address of an 8-byte aligned 8-byte
>   buffer containing the VM generation ID.
>   This buffer must not be in ranges supported as AddressRangeMemory
>   or AddressRangeACPI and must not be mapped by any PTE with caching
>   disabled.
> 
> The semantics of the VM generation ID itself are left up to the tools but it must be possible to change it each time the VM is booted, migrated, or restored from a saved image.
> -----
> 
>   Does that help?
> 
>     Paul
> 
> > -----Original Message-----
> > From: Konrad Rzeszutek Wilk [mailto:konrad@darnok.org]
> > Sent: 30 November 2011 22:14
> > To: Paul Durrant
> > Cc: xen-devel@lists.xensource.com
> > Subject: Re: [Xen-devel] [PATCH] Add code to track the address of
> > the VM generation id buffer across a
> >
> > On Wed, Nov 30, 2011 at 08:58:37PM +0000, Paul Durrant wrote:
> > > # HG changeset patch
> > > # User Paul Durrant <paul.durrant@citrix.com> # Date 1322686267 0
> > #
> > > Node ID 94a17182f386c8bb414eba55dddf763b8982c76d
> > > # Parent  3c4c29899d8a2a0c0f9109b7236da95bb72b77b6
> > > Add code to track the address of the VM generation id buffer
> > across a
> > > save/restore or migrate and inject a new value.
> >
> > So what is a generation id? What is the use-case for this?
> >
> > > The address of the buffer is written into xenstore by hvmloader at
> > > boot time. It must be read from xenstore by the caller of
> > > xc_domain_save() and then written back again by the caller of
> > > xc_domain_restore().
> > >
> > > Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
> > >
> > > diff -r 3c4c29899d8a -r 94a17182f386
> > tools/libxc/ia64/xc_ia64_linux_restore.c
> > > --- a/tools/libxc/ia64/xc_ia64_linux_restore.c      Wed Nov 30
> > 07:18:11 2011 -0800
> > > +++ b/tools/libxc/ia64/xc_ia64_linux_restore.c      Wed Nov 30
> > 20:51:07 2011 +0000
> > > @@ -548,7 +548,8 @@ int
> > >  xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
> > >                    unsigned int store_evtchn, unsigned long
> > *store_mfn,
> > >                    unsigned int console_evtchn, unsigned long
> > *console_mfn,
> > > -                  unsigned int hvm, unsigned int pae, int
> > superpages)
> > > +                  unsigned int hvm, unsigned int pae, int
> > superpages,
> > > +                  uint64_t gid)
> > >  {
> > >      DECLARE_DOMCTL;
> > >      int rc = 1;
> > > diff -r 3c4c29899d8a -r 94a17182f386
> > tools/libxc/ia64/xc_ia64_linux_save.c
> > > --- a/tools/libxc/ia64/xc_ia64_linux_save.c Wed Nov 30 07:18:11
> > 2011 -0800
> > > +++ b/tools/libxc/ia64/xc_ia64_linux_save.c Wed Nov 30 20:51:07
> > 2011 +0000
> > > @@ -382,7 +382,8 @@ out:
> > >  int
> > >  xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom,
> > uint32_t max_iters,
> > >                 uint32_t max_factor, uint32_t flags,
> > > -               struct save_callbacks* callbacks, int hvm)
> > > +               struct save_callbacks* callbacks, int hvm,
> > > +               unsigned long vm_gid_addr)
> > >  {
> > >      DECLARE_DOMCTL;
> > >      xc_dominfo_t info;
> > > diff -r 3c4c29899d8a -r 94a17182f386
> > tools/libxc/xc_domain_restore.c
> > > --- a/tools/libxc/xc_domain_restore.c       Wed Nov 30 07:18:11 2011 -
> > 0800
> > > +++ b/tools/libxc/xc_domain_restore.c       Wed Nov 30 20:51:07 2011
> > +0000
> > > @@ -676,6 +676,7 @@ typedef struct {
> > >      uint64_t console_pfn;
> > >      uint64_t acpi_ioport_location;
> > >      uint64_t viridian;
> > > +    uint64_t vm_gid_addr;
> > >  } pagebuf_t;
> > >
> > >  static int pagebuf_init(pagebuf_t* buf) @@ -820,6 +821,17 @@
> > static
> > > int pagebuf_get_one(xc_interface
> > >          }
> > >          return pagebuf_get_one(xch, ctx, buf, fd, dom);
> > >
> > > +    case XC_SAVE_ID_HVM_GENERATION_ID_ADDR:
> > > +        /* Skip padding 4 bytes then read the generation id
> > buffer location. */
> > > +        if ( RDEXACT(fd, &buf->vm_gid_addr, sizeof(uint32_t)) ||
> > > +             RDEXACT(fd, &buf->vm_gid_addr, sizeof(uint64_t)) )
> > > +        {
> > > +            PERROR("error read the generation id buffer
> > location");
> > > +            return -1;
> > > +        }
> > > +        DPRINTF("read generation id buffer address");
> > > +        return pagebuf_get_one(xch, ctx, buf, fd, dom);
> > > +
> > >      default:
> > >          if ( (count > MAX_BATCH_SIZE) || (count < 0) ) {
> > >              ERROR("Max batch size exceeded (%d). Giving up.",
> > count);
> > > @@ -1186,7 +1198,8 @@ static int apply_batch(xc_interface *xch
> > int
> > > xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
> > >                        unsigned int store_evtchn, unsigned long
> > *store_mfn,
> > >                        unsigned int console_evtchn, unsigned long
> > *console_mfn,
> > > -                      unsigned int hvm, unsigned int pae, int
> > superpages)
> > > +                      unsigned int hvm, unsigned int pae, int
> > superpages,
> > > +                      uint64_t gid, unsigned long *vm_gid_addr)
> > >  {
> > >      DECLARE_DOMCTL;
> > >      int rc = 1, frc, i, j, n, m, pae_extended_cr3 = 0,
> > > ext_vcpucontext = 0; @@ -1386,6 +1399,33 @@ int
> > xc_domain_restore(xc_interface *xch,
> > >                  xc_set_hvm_param(xch, dom, HVM_PARAM_VM86_TSS,
> > pagebuf.vm86_tss);
> > >              if ( pagebuf.console_pfn )
> > >                  console_pfn = pagebuf.console_pfn;
> > > +            if ( pagebuf.vm_gid_addr ) {
> > > +                unsigned int offset;
> > > +                unsigned char *buf;
> > > +
> > > +                /*
> > > +                 * Map the VM generation id buffer and inject the
> > new value.
> > > +                 */
> > > +
> > > +                pfn = pagebuf.vm_gid_addr >> PAGE_SHIFT;
> > > +                offset = pagebuf.vm_gid_addr & (PAGE_SIZE - 1);
> > > +
> > > +                if ( (pfn >= dinfo->p2m_size) ||
> > > +                     (pfn_type[pfn] != XEN_DOMCTL_PFINFO_NOTAB) )
> > > +                {
> > > +                    ERROR("generation id buffer frame is bad");
> > > +                    goto out;
> > > +                }
> > > +
> > > +                mfn = ctx->p2m[pfn];
> > > +                buf = xc_map_foreign_range(xch, dom, PAGE_SIZE,
> > > +                                           PROT_READ |
> > PROT_WRITE, mfn);
> > > +                *(unsigned long long *)(buf + offset) = gid;
> > > +                munmap(buf, PAGE_SIZE);
> > > +
> > > +                *vm_gid_addr = pagebuf.vm_gid_addr;
> > > +            }
> > > +
> > >              break;  /* our work here is done */
> > >          }
> > >
> > > diff -r 3c4c29899d8a -r 94a17182f386 tools/libxc/xc_domain_save.c
> > > --- a/tools/libxc/xc_domain_save.c  Wed Nov 30 07:18:11 2011 -
> > 0800
> > > +++ b/tools/libxc/xc_domain_save.c  Wed Nov 30 20:51:07 2011
> > +0000
> > > @@ -754,7 +754,8 @@ static int save_tsc_info(xc_interface *x
> > >
> > >  int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom,
> > uint32_t max_iters,
> > >                     uint32_t max_factor, uint32_t flags,
> > > -                   struct save_callbacks* callbacks, int hvm)
> > > +                   struct save_callbacks* callbacks, int hvm,
> > > +                   unsigned long vm_gid_addr)
> > >  {
> > >      xc_dominfo_t info;
> > >      DECLARE_DOMCTL;
> > > @@ -1460,6 +1461,16 @@ int xc_domain_save(xc_interface *xch, in
> > >              uint64_t data;
> > >          } chunk = { 0, };
> > >
> > > +        chunk.id = XC_SAVE_ID_HVM_GENERATION_ID_ADDR;
> > > +        chunk.data = vm_gid_addr;
> > > +
> > > +        if ( (chunk.data != 0) &&
> > > +             wrexact(io_fd, &chunk, sizeof(chunk)) )
> > > +        {
> > > +            PERROR("Error when writing the generation id buffer
> > location for guest");
> > > +            goto out;
> > > +        }
> > > +
> > >          chunk.id = XC_SAVE_ID_HVM_IDENT_PT;
> > >          chunk.data = 0;
> > >          xc_get_hvm_param(xch, dom, HVM_PARAM_IDENT_PT, diff -r
> > > 3c4c29899d8a -r 94a17182f386 tools/libxc/xenguest.h
> > > --- a/tools/libxc/xenguest.h        Wed Nov 30 07:18:11 2011 -0800
> > > +++ b/tools/libxc/xenguest.h        Wed Nov 30 20:51:07 2011 +0000
> > > @@ -57,7 +57,8 @@ struct save_callbacks {
> > >   */
> > >  int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom,
> > uint32_t max_iters,
> > >                     uint32_t max_factor, uint32_t flags /*
> > XCFLAGS_xxx */,
> > > -                   struct save_callbacks* callbacks, int hvm);
> > > +                   struct save_callbacks* callbacks, int hvm,
> > > +                   unsigned long vm_gid_addr);
> > >
> > >
> > >  /**
> > > @@ -71,12 +72,15 @@ int xc_domain_save(xc_interface *xch, in
> > >   * @parm hvm non-zero if this is a HVM restore
> > >   * @parm pae non-zero if this HVM domain has PAE support enabled
> > >   * @parm superpages non-zero to allocate guest memory with
> > superpages
> > > + * @parm gid the new generation id of the VM
> > > + * @parm vm_gid_addr returned with the address of the generation
> > id
> > > + buffer
> > >   * @return 0 on success, -1 on failure
> > >   */
> > >  int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
> > >                        unsigned int store_evtchn, unsigned long
> > *store_mfn,
> > >                        unsigned int console_evtchn, unsigned long
> > *console_mfn,
> > > -                      unsigned int hvm, unsigned int pae, int
> > superpages);
> > > +                      unsigned int hvm, unsigned int pae, int
> > superpages,
> > > +                      uint64_t gid, unsigned long *vm_gid_addr);
> > >  /**
> > >   * xc_domain_restore writes a file to disk that contains the
> > device
> > >   * model saved state.
> > > diff -r 3c4c29899d8a -r 94a17182f386 tools/libxc/xg_save_restore.h
> > > --- a/tools/libxc/xg_save_restore.h Wed Nov 30 07:18:11 2011 -
> > 0800
> > > +++ b/tools/libxc/xg_save_restore.h Wed Nov 30 20:51:07 2011
> > +0000
> > > @@ -135,6 +135,7 @@
> > >  #define XC_SAVE_ID_LAST_CHECKPOINT    -9 /* Commit to restoring
> > after completion of current iteration. */
> > >  #define XC_SAVE_ID_HVM_ACPI_IOPORTS_LOCATION -10
> > >  #define XC_SAVE_ID_HVM_VIRIDIAN       -11
> > > +#define XC_SAVE_ID_HVM_GENERATION_ID_ADDR -12
> > >
> > >  /*
> > >  ** We process save/restore/migrate in batches of pages; the below
> > > diff -r 3c4c29899d8a -r 94a17182f386 tools/libxl/libxl_create.c
> > > --- a/tools/libxl/libxl_create.c    Wed Nov 30 07:18:11 2011 -0800
> > > +++ b/tools/libxl/libxl_create.c    Wed Nov 30 20:51:07 2011 +0000
> > > @@ -101,6 +101,7 @@ int libxl_init_build_info(libxl_ctx *ctx
> > >          b_info->u.hvm.vpt_align = 1;
> > >          b_info->u.hvm.timer_mode = 1;
> > >          b_info->u.hvm.nested_hvm = 0;
> > > +        b_info->u.hvm.generation_id = 0;
> > >          break;
> > >      case LIBXL_DOMAIN_TYPE_PV:
> > >          b_info->u.pv.slack_memkb = 8 * 1024; @@ -191,13 +192,15
> > @@
> > > int libxl__domain_build(libxl__gc *gc,
> > >          vments[4] = "start_time";
> > >          vments[5] = libxl__sprintf(gc, "%lu.%02d",
> > > start_time.tv_sec,(int)start_time.tv_usec/10000);
> > >
> > > -        localents = libxl__calloc(gc, 7, sizeof(char *));
> > > +        localents = libxl__calloc(gc, 9, sizeof(char *));
> > >          localents[0] = "platform/acpi";
> > >          localents[1] = (info->u.hvm.acpi) ? "1" : "0";
> > >          localents[2] = "platform/acpi_s3";
> > >          localents[3] = (info->u.hvm.acpi_s3) ? "1" : "0";
> > >          localents[4] = "platform/acpi_s4";
> > >          localents[5] = (info->u.hvm.acpi_s4) ? "1" : "0";
> > > +        localents[6] = "platform/generation_id";
> > > +        localents[7] = libxl__sprintf(gc, "0x%llx",
> > > + info->u.hvm.generation_id);
> > >
> > >          break;
> > >      case LIBXL_DOMAIN_TYPE_PV:
> > > diff -r 3c4c29899d8a -r 94a17182f386 tools/libxl/libxl_dom.c
> > > --- a/tools/libxl/libxl_dom.c       Wed Nov 30 07:18:11 2011 -0800
> > > +++ b/tools/libxl/libxl_dom.c       Wed Nov 30 20:51:07 2011 +0000
> > > @@ -125,7 +125,7 @@ int libxl__build_post(libxl__gc *gc, uin
> > >      if (info->cpuid != NULL)
> > >          libxl_cpuid_set(ctx, domid, info->cpuid);
> > >
> > > -    ents = libxl__calloc(gc, 12 + (info->max_vcpus * 2) + 2,
> > sizeof(char *));
> > > +    ents = libxl__calloc(gc, 14 + (info->max_vcpus * 2) + 2,
> > > + sizeof(char *));
> > >      ents[0] = "memory/static-max";
> > >      ents[1] = libxl__sprintf(gc, "%d", info->max_memkb);
> > >      ents[2] = "memory/target";
> > > @@ -138,9 +138,11 @@ int libxl__build_post(libxl__gc *gc, uin
> > >      ents[9] = libxl__sprintf(gc, "%"PRIu32, state->store_port);
> > >      ents[10] = "store/ring-ref";
> > >      ents[11] = libxl__sprintf(gc, "%lu", state->store_mfn);
> > > +    ents[12] = "data/generation-id";
> > > +    ents[13] = libxl__sprintf(gc, "0x%lx", state->vm_gid_addr);
> > >      for (i = 0; i < info->max_vcpus; i++) {
> > > -        ents[12+(i*2)]   = libxl__sprintf(gc,
> > "cpu/%d/availability", i);
> > > -        ents[12+(i*2)+1] = (i && info->cur_vcpus && !(info-
> > >cur_vcpus & (1 << i)))
> > > +        ents[14+(i*2)]   = libxl__sprintf(gc,
> > "cpu/%d/availability", i);
> > > +        ents[14+(i*2)+1] = (i && info->cur_vcpus && !(info-
> > >cur_vcpus
> > > + & (1 << i)))
> > >                              ? "offline" : "online";
> > >      }
> > >
> > > @@ -357,16 +359,19 @@ int libxl__domain_restore_common(libxl__
> > >      /* read signature */
> > >      int rc;
> > >      int hvm, pae, superpages;
> > > +    uint64_t gid;
> > >      switch (info->type) {
> > >      case LIBXL_DOMAIN_TYPE_HVM:
> > >          hvm = 1;
> > >          superpages = 1;
> > >          pae = info->u.hvm.pae;
> > > +        gid = info->u.hvm.generation_id;
> > >          break;
> > >      case LIBXL_DOMAIN_TYPE_PV:
> > >          hvm = 0;
> > >          superpages = 0;
> > >          pae = 1;
> > > +        gid = 0;
> > >          break;
> > >      default:
> > >          return ERROR_INVAL;
> > > @@ -374,7 +379,7 @@ int libxl__domain_restore_common(libxl__
> > >      rc = xc_domain_restore(ctx->xch, fd, domid,
> > >                             state->store_port, &state->store_mfn,
> > >                             state->console_port, &state-
> > >console_mfn,
> > > -                           hvm, pae, superpages);
> > > +                           hvm, pae, superpages, gid,
> > > + &state->vm_gid_addr);
> > >      if ( rc ) {
> > >          LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "restoring
> > domain");
> > >          return ERROR_FAIL;
> > > @@ -540,12 +545,22 @@ int libxl__domain_suspend_common(libxl__
> > >      struct save_callbacks callbacks;
> > >      struct suspendinfo si;
> > >      int hvm, rc = ERROR_FAIL;
> > > +    unsigned long vm_gid_addr;
> > >
> > >      switch (type) {
> > > -    case LIBXL_DOMAIN_TYPE_HVM:
> > > +    case LIBXL_DOMAIN_TYPE_HVM: {
> > > +        char *path;
> > > +        char *addr;
> > > +
> > > +        path = libxl__sprintf(gc, "%s/data/generation-id",
> > libxl__xs_get_dompath(gc, domid));
> > > +        addr = libxl__xs_read(gc, XBT_NULL, path);
> > > +
> > > +        vm_gid_addr = (addr) ? strtoul(addr, NULL, 0) : 0;
> > >          hvm = 1;
> > >          break;
> > > +    }
> > >      case LIBXL_DOMAIN_TYPE_PV:
> > > +        vm_gid_addr = 0;
> > >          hvm = 0;
> > >          break;
> > >      default:
> > > @@ -583,7 +598,8 @@ int libxl__domain_suspend_common(libxl__
> > >      callbacks.switch_qemu_logdirty =
> > libxl__domain_suspend_common_switch_qemu_logdirty;
> > >      callbacks.data = &si;
> > >
> > > -    rc = xc_domain_save(ctx->xch, fd, domid, 0, 0, flags,
> > &callbacks, hvm);
> > > +    rc = xc_domain_save(ctx->xch, fd, domid, 0, 0, flags,
> > &callbacks,
> > > +                        hvm, vm_gid_addr);
> > >      if ( rc ) {
> > >          LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "saving domain:
> > %s",
> > >                           si.guest_responded ?
> > > diff -r 3c4c29899d8a -r 94a17182f386 tools/libxl/libxl_internal.h
> > > --- a/tools/libxl/libxl_internal.h  Wed Nov 30 07:18:11 2011 -
> > 0800
> > > +++ b/tools/libxl/libxl_internal.h  Wed Nov 30 20:51:07 2011
> > +0000
> > > @@ -199,6 +199,8 @@ typedef struct {
> > >
> > >      uint32_t console_port;
> > >      unsigned long console_mfn;
> > > +
> > > +    unsigned long vm_gid_addr;
> > >  } libxl__domain_build_state;
> > >
> > >  _hidden int libxl__build_pre(libxl__gc *gc, uint32_t domid, diff
> > -r
> > > 3c4c29899d8a -r 94a17182f386 tools/libxl/libxl_types.idl
> > > --- a/tools/libxl/libxl_types.idl   Wed Nov 30 07:18:11 2011 -
> > 0800
> > > +++ b/tools/libxl/libxl_types.idl   Wed Nov 30 20:51:07 2011
> > +0000
> > > @@ -183,6 +183,7 @@ libxl_domain_build_info = Struct("domain
> > >                                         ("vpt_align", bool),
> > >                                         ("timer_mode", integer),
> > >                                         ("nested_hvm", bool),
> > > +                                       ("generation_id", uint64),
> > >                                         ])),
> > >                   ("pv", Struct(None, [("kernel",
> > libxl_file_reference),
> > >                                        ("slack_memkb", uint32),
> > diff
> > > -r 3c4c29899d8a -r 94a17182f386 tools/libxl/libxlu_cfg.c
> > > --- a/tools/libxl/libxlu_cfg.c      Wed Nov 30 07:18:11 2011 -0800
> > > +++ b/tools/libxl/libxlu_cfg.c      Wed Nov 30 20:51:07 2011 +0000
> > > @@ -235,6 +235,37 @@ int xlu_cfg_get_long(const XLU_Config *c
> > >      return 0;
> > >  }
> > >
> > > +int xlu_cfg_get_long_long(const XLU_Config *cfg, const char *n,
> > > +                          long long *value_r, int dont_warn) {
> > > +    long long ll;
> > > +    XLU_ConfigSetting *set;
> > > +    int e;
> > > +    char *ep;
> > > +
> > > +    e= find_atom(cfg,n,&set,dont_warn);  if (e) return e;
> > > +    errno= 0; ll= strtoll(set->values[0], &ep, 0);
> > > +    e= errno;
> > > +    if (errno) {
> > > +        e= errno;
> > > +        assert(e==EINVAL || e==ERANGE);
> > > +        if (!dont_warn)
> > > +            fprintf(cfg->report,
> > > +                    "%s:%d: warning: parameter `%s' could not be
> > parsed"
> > > +                    " as a number: %s\n",
> > > +                    cfg->filename, set->lineno, n, strerror(e));
> > > +        return e;
> > > +    }
> > > +    if (*ep || ep==set->values[0]) {
> > > +        if (!dont_warn)
> > > +            fprintf(cfg->report,
> > > +                    "%s:%d: warning: parameter `%s' is not a
> > valid number\n",
> > > +                    cfg->filename, set->lineno, n);
> > > +        return EINVAL;
> > > +    }
> > > +    *value_r= ll;
> > > +    return 0;
> > > +}
> > > +
> > >
> > >  int xlu_cfg_get_list(const XLU_Config *cfg, const char *n,
> > >                       XLU_ConfigList **list_r, int *entries_r, int
> > > dont_warn) { diff -r 3c4c29899d8a -r 94a17182f386
> > tools/libxl/libxlutil.h
> > > --- a/tools/libxl/libxlutil.h       Wed Nov 30 07:18:11 2011 -0800
> > > +++ b/tools/libxl/libxlutil.h       Wed Nov 30 20:51:07 2011 +0000
> > > @@ -52,6 +52,8 @@ int xlu_cfg_replace_string(const XLU_Con
> > >                             char **value_r, int dont_warn);  int
> > > xlu_cfg_get_long(const XLU_Config*, const char *n, long *value_r,
> > >                       int dont_warn);
> > > +int xlu_cfg_get_long_long(const XLU_Config*, const char *n, long
> > long *value_r,
> > > +                          int dont_warn);
> > >
> > >  int xlu_cfg_get_list(const XLU_Config*, const char *n,
> > >                       XLU_ConfigList **list_r /* may be 0 */, diff
> > -r
> > > 3c4c29899d8a -r 94a17182f386 tools/libxl/xl_cmdimpl.c
> > > --- a/tools/libxl/xl_cmdimpl.c      Wed Nov 30 07:18:11 2011 -0800
> > > +++ b/tools/libxl/xl_cmdimpl.c      Wed Nov 30 20:51:07 2011 +0000
> > > @@ -573,6 +573,7 @@ static void parse_config_data(const char  {
> > >      const char *buf;
> > >      long l;
> > > +    long long ll;
> > >      XLU_Config *config;
> > >      XLU_ConfigList *vbds, *nics, *pcis, *cvfbs, *cpuids;
> > >      int pci_power_mgmt = 0;
> > > @@ -764,6 +765,8 @@ static void parse_config_data(const char
> > >              b_info->u.hvm.timer_mode = l;
> > >          if (!xlu_cfg_get_long (config, "nestedhvm", &l, 0))
> > >              b_info->u.hvm.nested_hvm = l;
> > > +        if (!xlu_cfg_get_long_long (config, "generation_id", &ll,
> > 0))
> > > +            b_info->u.hvm.nested_hvm = ll;
> > >          break;
> > >      case LIBXL_DOMAIN_TYPE_PV:
> > >      {
> > > diff -r 3c4c29899d8a -r 94a17182f386
> > tools/python/xen/lowlevel/checkpoint/libcheckpoint.c
> > > --- a/tools/python/xen/lowlevel/checkpoint/libcheckpoint.c  Wed
> > Nov 30 07:18:11 2011 -0800
> > > +++ b/tools/python/xen/lowlevel/checkpoint/libcheckpoint.c  Wed
> > Nov 30 20:51:07 2011 +0000
> > > @@ -174,6 +174,7 @@ int checkpoint_start(checkpoint_state* s  {
> > >      int hvm, rc;
> > >      int flags = XCFLAGS_LIVE;
> > > +    unsigned long vm_gid_addr;
> > >
> > >      if (!s->domid) {
> > >         s->errstr = "checkpoint state not opened"; @@ -184,14
> > +185,25
> > > @@ int checkpoint_start(checkpoint_state* s
> > >
> > >      hvm = s->domtype > dt_pv;
> > >      if (hvm) {
> > > +       char path[128];
> > > +       char *addr;
> > > +
> > > +       sprintf(path, "/local/domain/%u/data/generation-id", s-
> > >domid);
> > > +       addr = xs_read(s->xsh, XBT_NULL, path, NULL);
> > > +
> > > +       vm_gid_addr = (addr) ? strtoul(addr, NULL, 0) : 0;
> > > +       free(addr);
> > > +
> > >         flags |= XCFLAGS_HVM;
> > >         if (switch_qemu_logdirty(s, 1))
> > >             return -1;
> > > +    } else {
> > > +       vm_gid_addr = 0;
> > >      }
> > >
> > >      callbacks->switch_qemu_logdirty = noop_switch_logdirty;
> > >
> > > -    rc = xc_domain_save(s->xch, fd, s->domid, 0, 0, flags,
> > callbacks, hvm);
> > > +    rc = xc_domain_save(s->xch, fd, s->domid, 0, 0, flags,
> > callbacks,
> > > + hvm, vm_gid_addr);
> > >
> > >      if (hvm)
> > >         switch_qemu_logdirty(s, 0);
> > > diff -r 3c4c29899d8a -r 94a17182f386 tools/xcutils/xc_restore.c
> > > --- a/tools/xcutils/xc_restore.c    Wed Nov 30 07:18:11 2011 -0800
> > > +++ b/tools/xcutils/xc_restore.c    Wed Nov 30 20:51:07 2011 +0000
> > > @@ -23,7 +23,8 @@ main(int argc, char **argv)
> > >      xc_interface *xch;
> > >      int io_fd, ret;
> > >      int superpages;
> > > -    unsigned long store_mfn, console_mfn;
> > > +    unsigned long store_mfn, console_mfn, vm_gid_addr;
> > > +    uint64_t gid;
> > >
> > >      if ( (argc != 8) && (argc != 9) )
> > >          errx(1, "usage: %s iofd domid store_evtchn "
> > > @@ -40,19 +41,25 @@ main(int argc, char **argv)
> > >      hvm  = atoi(argv[5]);
> > >      pae  = atoi(argv[6]);
> > >      apic = atoi(argv[7]);
> > > -    if ( argc == 9 )
> > > +    if ( argc >= 9 )
> > >         superpages = atoi(argv[8]);
> > >      else
> > >         superpages = !!hvm;
> > > +    if ( argc >= 10 )
> > > +       gid = strtoll(argv[9], NULL, 0);
> > > +    else
> > > +       gid = 0;
> > >
> > >      ret = xc_domain_restore(xch, io_fd, domid, store_evtchn,
> > &store_mfn,
> > > -                            console_evtchn, &console_mfn, hvm,
> > pae, superpages);
> > > +                            console_evtchn, &console_mfn, hvm,
> > pae, superpages,
> > > +                            gid, &vm_gid_addr);
> > >
> > >      if ( ret == 0 )
> > >      {
> > >     printf("store-mfn %li\n", store_mfn);
> > >          if ( !hvm )
> > >              printf("console-mfn %li\n", console_mfn);
> > > +   printf("vm-gid-addr %lx\n", vm_gid_addr);
> > >     fflush(stdout);
> > >      }
> > >
> > > diff -r 3c4c29899d8a -r 94a17182f386 tools/xcutils/xc_save.c
> > > --- a/tools/xcutils/xc_save.c       Wed Nov 30 07:18:11 2011 -0800
> > > +++ b/tools/xcutils/xc_save.c       Wed Nov 30 20:51:07 2011 +0000
> > > @@ -169,6 +169,10 @@ main(int argc, char **argv)
> > >      unsigned int maxit, max_f;
> > >      int io_fd, ret, port;
> > >      struct save_callbacks callbacks;
> > > +    char path[128];
> > > +    struct xs_handle *xs;
> > > +    char *addr;
> > > +    unsigned long vm_gid_addr;
> > >
> > >      if (argc != 6)
> > >          errx(1, "usage: %s iofd domid maxit maxf flags",
> > argv[0]); @@
> > > -207,8 +211,21 @@ main(int argc, char **argv)
> > >      memset(&callbacks, 0, sizeof(callbacks));
> > >      callbacks.suspend = suspend;
> > >      callbacks.switch_qemu_logdirty = switch_qemu_logdirty;
> > > +
> > > +    sprintf(path, "/local/domain/%d/data/generation-id",
> > si.domid);
> > > +
> > > +    if ((xs = xs_daemon_open()) == NULL)
> > > +        errx(1, "Couldn't contact xenstore");
> > > +
> > > +    addr = xs_read(xs, XBT_NULL, path, NULL);
> > > +
> > > +    xs_daemon_close(xs);
> > > +
> > > +    vm_gid_addr = (addr) ? strtoul(addr, NULL, 0) : 0;
> > > +    free(addr);
> > > +
> > >      ret = xc_domain_save(si.xch, io_fd, si.domid, maxit, max_f,
> > si.flags,
> > > -                         &callbacks, !!(si.flags & XCFLAGS_HVM));
> > > +                         &callbacks, !!(si.flags & XCFLAGS_HVM),
> > > + vm_gid_addr);
> > >
> > >      if (si.suspend_evtchn > 0)
> > >      xc_suspend_evtchn_release(si.xch, si.xce, si.domid,
> > > si.suspend_evtchn);
> > >
> > > _______________________________________________
> > > Xen-devel mailing list
> > > Xen-devel@lists.xensource.com
> > > http://lists.xensource.com/xen-devel
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 09:00:05 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 09: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.xensource.com>)
	id 1RW2Ue-0008VS-Pu; Thu, 01 Dec 2011 08:59:48 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RW2Ud-0008VH-Cd
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 08:59:47 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1322729947!5736033!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU2Nw==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20483 invoked from network); 1 Dec 2011 08:59:07 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 08:59:07 -0000
X-IronPort-AV: E=Sophos;i="4.71,277,1320624000"; 
   d="scan'208";a="9222628"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Dec 2011 08:59:07 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 1 Dec 2011
	08:59:07 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Paul Durrant <Paul.Durrant@citrix.com>
Date: Thu, 1 Dec 2011 08:59:07 +0000
In-Reply-To: <291EDFCB1E9E224A99088639C4762022B5988E50D4@LONPMAILBOX01.citrite.net>
References: <94a17182f386c8bb414e.1322686717@cosworth.uk.xensource.com>
	<20111130221419.GA16651@andromeda.dapyr.net>
	<291EDFCB1E9E224A99088639C4762022B5988E50D4@LONPMAILBOX01.citrite.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322729947.31810.151.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] Add code to track the address of the VM
 generation id buffer across a
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2011-12-01 at 08:46 +0000, Paul Durrant wrote:
> Konrad,
> 
>   Did you see my previous patch set? The introductory comment was:


I think that description belongs somewhere permanent, either in
docs/misc or as a comment in an appropriate header.

Ian.

> 
> -----
> The following is a revised patch series to add support for a VM generation ID virtual device for HVM guests.
> The basic requirements of this device are as follows:
> 
> - It must be exposed somewhere in ACPI namespace with a _CID of
>   "VM_Gen_Counter".
> - It must also include a _DDN of "VM_Gen_Counter".
> - It must contain a _HID object but no particular value is
>   required.
> - It must expose a package called ADDR which evaluates to two
>   integers; the first being the low order 32-bits of a guest
>   physical address (GPA), the second by the high order 32-bits of
>   the GPA. This GPA is the address of an 8-byte aligned 8-byte
>   buffer containing the VM generation ID.
>   This buffer must not be in ranges supported as AddressRangeMemory
>   or AddressRangeACPI and must not be mapped by any PTE with caching
>   disabled.
> 
> The semantics of the VM generation ID itself are left up to the tools but it must be possible to change it each time the VM is booted, migrated, or restored from a saved image.
> -----
> 
>   Does that help?
> 
>     Paul
> 
> > -----Original Message-----
> > From: Konrad Rzeszutek Wilk [mailto:konrad@darnok.org]
> > Sent: 30 November 2011 22:14
> > To: Paul Durrant
> > Cc: xen-devel@lists.xensource.com
> > Subject: Re: [Xen-devel] [PATCH] Add code to track the address of
> > the VM generation id buffer across a
> >
> > On Wed, Nov 30, 2011 at 08:58:37PM +0000, Paul Durrant wrote:
> > > # HG changeset patch
> > > # User Paul Durrant <paul.durrant@citrix.com> # Date 1322686267 0
> > #
> > > Node ID 94a17182f386c8bb414eba55dddf763b8982c76d
> > > # Parent  3c4c29899d8a2a0c0f9109b7236da95bb72b77b6
> > > Add code to track the address of the VM generation id buffer
> > across a
> > > save/restore or migrate and inject a new value.
> >
> > So what is a generation id? What is the use-case for this?
> >
> > > The address of the buffer is written into xenstore by hvmloader at
> > > boot time. It must be read from xenstore by the caller of
> > > xc_domain_save() and then written back again by the caller of
> > > xc_domain_restore().
> > >
> > > Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
> > >
> > > diff -r 3c4c29899d8a -r 94a17182f386
> > tools/libxc/ia64/xc_ia64_linux_restore.c
> > > --- a/tools/libxc/ia64/xc_ia64_linux_restore.c      Wed Nov 30
> > 07:18:11 2011 -0800
> > > +++ b/tools/libxc/ia64/xc_ia64_linux_restore.c      Wed Nov 30
> > 20:51:07 2011 +0000
> > > @@ -548,7 +548,8 @@ int
> > >  xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
> > >                    unsigned int store_evtchn, unsigned long
> > *store_mfn,
> > >                    unsigned int console_evtchn, unsigned long
> > *console_mfn,
> > > -                  unsigned int hvm, unsigned int pae, int
> > superpages)
> > > +                  unsigned int hvm, unsigned int pae, int
> > superpages,
> > > +                  uint64_t gid)
> > >  {
> > >      DECLARE_DOMCTL;
> > >      int rc = 1;
> > > diff -r 3c4c29899d8a -r 94a17182f386
> > tools/libxc/ia64/xc_ia64_linux_save.c
> > > --- a/tools/libxc/ia64/xc_ia64_linux_save.c Wed Nov 30 07:18:11
> > 2011 -0800
> > > +++ b/tools/libxc/ia64/xc_ia64_linux_save.c Wed Nov 30 20:51:07
> > 2011 +0000
> > > @@ -382,7 +382,8 @@ out:
> > >  int
> > >  xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom,
> > uint32_t max_iters,
> > >                 uint32_t max_factor, uint32_t flags,
> > > -               struct save_callbacks* callbacks, int hvm)
> > > +               struct save_callbacks* callbacks, int hvm,
> > > +               unsigned long vm_gid_addr)
> > >  {
> > >      DECLARE_DOMCTL;
> > >      xc_dominfo_t info;
> > > diff -r 3c4c29899d8a -r 94a17182f386
> > tools/libxc/xc_domain_restore.c
> > > --- a/tools/libxc/xc_domain_restore.c       Wed Nov 30 07:18:11 2011 -
> > 0800
> > > +++ b/tools/libxc/xc_domain_restore.c       Wed Nov 30 20:51:07 2011
> > +0000
> > > @@ -676,6 +676,7 @@ typedef struct {
> > >      uint64_t console_pfn;
> > >      uint64_t acpi_ioport_location;
> > >      uint64_t viridian;
> > > +    uint64_t vm_gid_addr;
> > >  } pagebuf_t;
> > >
> > >  static int pagebuf_init(pagebuf_t* buf) @@ -820,6 +821,17 @@
> > static
> > > int pagebuf_get_one(xc_interface
> > >          }
> > >          return pagebuf_get_one(xch, ctx, buf, fd, dom);
> > >
> > > +    case XC_SAVE_ID_HVM_GENERATION_ID_ADDR:
> > > +        /* Skip padding 4 bytes then read the generation id
> > buffer location. */
> > > +        if ( RDEXACT(fd, &buf->vm_gid_addr, sizeof(uint32_t)) ||
> > > +             RDEXACT(fd, &buf->vm_gid_addr, sizeof(uint64_t)) )
> > > +        {
> > > +            PERROR("error read the generation id buffer
> > location");
> > > +            return -1;
> > > +        }
> > > +        DPRINTF("read generation id buffer address");
> > > +        return pagebuf_get_one(xch, ctx, buf, fd, dom);
> > > +
> > >      default:
> > >          if ( (count > MAX_BATCH_SIZE) || (count < 0) ) {
> > >              ERROR("Max batch size exceeded (%d). Giving up.",
> > count);
> > > @@ -1186,7 +1198,8 @@ static int apply_batch(xc_interface *xch
> > int
> > > xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
> > >                        unsigned int store_evtchn, unsigned long
> > *store_mfn,
> > >                        unsigned int console_evtchn, unsigned long
> > *console_mfn,
> > > -                      unsigned int hvm, unsigned int pae, int
> > superpages)
> > > +                      unsigned int hvm, unsigned int pae, int
> > superpages,
> > > +                      uint64_t gid, unsigned long *vm_gid_addr)
> > >  {
> > >      DECLARE_DOMCTL;
> > >      int rc = 1, frc, i, j, n, m, pae_extended_cr3 = 0,
> > > ext_vcpucontext = 0; @@ -1386,6 +1399,33 @@ int
> > xc_domain_restore(xc_interface *xch,
> > >                  xc_set_hvm_param(xch, dom, HVM_PARAM_VM86_TSS,
> > pagebuf.vm86_tss);
> > >              if ( pagebuf.console_pfn )
> > >                  console_pfn = pagebuf.console_pfn;
> > > +            if ( pagebuf.vm_gid_addr ) {
> > > +                unsigned int offset;
> > > +                unsigned char *buf;
> > > +
> > > +                /*
> > > +                 * Map the VM generation id buffer and inject the
> > new value.
> > > +                 */
> > > +
> > > +                pfn = pagebuf.vm_gid_addr >> PAGE_SHIFT;
> > > +                offset = pagebuf.vm_gid_addr & (PAGE_SIZE - 1);
> > > +
> > > +                if ( (pfn >= dinfo->p2m_size) ||
> > > +                     (pfn_type[pfn] != XEN_DOMCTL_PFINFO_NOTAB) )
> > > +                {
> > > +                    ERROR("generation id buffer frame is bad");
> > > +                    goto out;
> > > +                }
> > > +
> > > +                mfn = ctx->p2m[pfn];
> > > +                buf = xc_map_foreign_range(xch, dom, PAGE_SIZE,
> > > +                                           PROT_READ |
> > PROT_WRITE, mfn);
> > > +                *(unsigned long long *)(buf + offset) = gid;
> > > +                munmap(buf, PAGE_SIZE);
> > > +
> > > +                *vm_gid_addr = pagebuf.vm_gid_addr;
> > > +            }
> > > +
> > >              break;  /* our work here is done */
> > >          }
> > >
> > > diff -r 3c4c29899d8a -r 94a17182f386 tools/libxc/xc_domain_save.c
> > > --- a/tools/libxc/xc_domain_save.c  Wed Nov 30 07:18:11 2011 -
> > 0800
> > > +++ b/tools/libxc/xc_domain_save.c  Wed Nov 30 20:51:07 2011
> > +0000
> > > @@ -754,7 +754,8 @@ static int save_tsc_info(xc_interface *x
> > >
> > >  int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom,
> > uint32_t max_iters,
> > >                     uint32_t max_factor, uint32_t flags,
> > > -                   struct save_callbacks* callbacks, int hvm)
> > > +                   struct save_callbacks* callbacks, int hvm,
> > > +                   unsigned long vm_gid_addr)
> > >  {
> > >      xc_dominfo_t info;
> > >      DECLARE_DOMCTL;
> > > @@ -1460,6 +1461,16 @@ int xc_domain_save(xc_interface *xch, in
> > >              uint64_t data;
> > >          } chunk = { 0, };
> > >
> > > +        chunk.id = XC_SAVE_ID_HVM_GENERATION_ID_ADDR;
> > > +        chunk.data = vm_gid_addr;
> > > +
> > > +        if ( (chunk.data != 0) &&
> > > +             wrexact(io_fd, &chunk, sizeof(chunk)) )
> > > +        {
> > > +            PERROR("Error when writing the generation id buffer
> > location for guest");
> > > +            goto out;
> > > +        }
> > > +
> > >          chunk.id = XC_SAVE_ID_HVM_IDENT_PT;
> > >          chunk.data = 0;
> > >          xc_get_hvm_param(xch, dom, HVM_PARAM_IDENT_PT, diff -r
> > > 3c4c29899d8a -r 94a17182f386 tools/libxc/xenguest.h
> > > --- a/tools/libxc/xenguest.h        Wed Nov 30 07:18:11 2011 -0800
> > > +++ b/tools/libxc/xenguest.h        Wed Nov 30 20:51:07 2011 +0000
> > > @@ -57,7 +57,8 @@ struct save_callbacks {
> > >   */
> > >  int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom,
> > uint32_t max_iters,
> > >                     uint32_t max_factor, uint32_t flags /*
> > XCFLAGS_xxx */,
> > > -                   struct save_callbacks* callbacks, int hvm);
> > > +                   struct save_callbacks* callbacks, int hvm,
> > > +                   unsigned long vm_gid_addr);
> > >
> > >
> > >  /**
> > > @@ -71,12 +72,15 @@ int xc_domain_save(xc_interface *xch, in
> > >   * @parm hvm non-zero if this is a HVM restore
> > >   * @parm pae non-zero if this HVM domain has PAE support enabled
> > >   * @parm superpages non-zero to allocate guest memory with
> > superpages
> > > + * @parm gid the new generation id of the VM
> > > + * @parm vm_gid_addr returned with the address of the generation
> > id
> > > + buffer
> > >   * @return 0 on success, -1 on failure
> > >   */
> > >  int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
> > >                        unsigned int store_evtchn, unsigned long
> > *store_mfn,
> > >                        unsigned int console_evtchn, unsigned long
> > *console_mfn,
> > > -                      unsigned int hvm, unsigned int pae, int
> > superpages);
> > > +                      unsigned int hvm, unsigned int pae, int
> > superpages,
> > > +                      uint64_t gid, unsigned long *vm_gid_addr);
> > >  /**
> > >   * xc_domain_restore writes a file to disk that contains the
> > device
> > >   * model saved state.
> > > diff -r 3c4c29899d8a -r 94a17182f386 tools/libxc/xg_save_restore.h
> > > --- a/tools/libxc/xg_save_restore.h Wed Nov 30 07:18:11 2011 -
> > 0800
> > > +++ b/tools/libxc/xg_save_restore.h Wed Nov 30 20:51:07 2011
> > +0000
> > > @@ -135,6 +135,7 @@
> > >  #define XC_SAVE_ID_LAST_CHECKPOINT    -9 /* Commit to restoring
> > after completion of current iteration. */
> > >  #define XC_SAVE_ID_HVM_ACPI_IOPORTS_LOCATION -10
> > >  #define XC_SAVE_ID_HVM_VIRIDIAN       -11
> > > +#define XC_SAVE_ID_HVM_GENERATION_ID_ADDR -12
> > >
> > >  /*
> > >  ** We process save/restore/migrate in batches of pages; the below
> > > diff -r 3c4c29899d8a -r 94a17182f386 tools/libxl/libxl_create.c
> > > --- a/tools/libxl/libxl_create.c    Wed Nov 30 07:18:11 2011 -0800
> > > +++ b/tools/libxl/libxl_create.c    Wed Nov 30 20:51:07 2011 +0000
> > > @@ -101,6 +101,7 @@ int libxl_init_build_info(libxl_ctx *ctx
> > >          b_info->u.hvm.vpt_align = 1;
> > >          b_info->u.hvm.timer_mode = 1;
> > >          b_info->u.hvm.nested_hvm = 0;
> > > +        b_info->u.hvm.generation_id = 0;
> > >          break;
> > >      case LIBXL_DOMAIN_TYPE_PV:
> > >          b_info->u.pv.slack_memkb = 8 * 1024; @@ -191,13 +192,15
> > @@
> > > int libxl__domain_build(libxl__gc *gc,
> > >          vments[4] = "start_time";
> > >          vments[5] = libxl__sprintf(gc, "%lu.%02d",
> > > start_time.tv_sec,(int)start_time.tv_usec/10000);
> > >
> > > -        localents = libxl__calloc(gc, 7, sizeof(char *));
> > > +        localents = libxl__calloc(gc, 9, sizeof(char *));
> > >          localents[0] = "platform/acpi";
> > >          localents[1] = (info->u.hvm.acpi) ? "1" : "0";
> > >          localents[2] = "platform/acpi_s3";
> > >          localents[3] = (info->u.hvm.acpi_s3) ? "1" : "0";
> > >          localents[4] = "platform/acpi_s4";
> > >          localents[5] = (info->u.hvm.acpi_s4) ? "1" : "0";
> > > +        localents[6] = "platform/generation_id";
> > > +        localents[7] = libxl__sprintf(gc, "0x%llx",
> > > + info->u.hvm.generation_id);
> > >
> > >          break;
> > >      case LIBXL_DOMAIN_TYPE_PV:
> > > diff -r 3c4c29899d8a -r 94a17182f386 tools/libxl/libxl_dom.c
> > > --- a/tools/libxl/libxl_dom.c       Wed Nov 30 07:18:11 2011 -0800
> > > +++ b/tools/libxl/libxl_dom.c       Wed Nov 30 20:51:07 2011 +0000
> > > @@ -125,7 +125,7 @@ int libxl__build_post(libxl__gc *gc, uin
> > >      if (info->cpuid != NULL)
> > >          libxl_cpuid_set(ctx, domid, info->cpuid);
> > >
> > > -    ents = libxl__calloc(gc, 12 + (info->max_vcpus * 2) + 2,
> > sizeof(char *));
> > > +    ents = libxl__calloc(gc, 14 + (info->max_vcpus * 2) + 2,
> > > + sizeof(char *));
> > >      ents[0] = "memory/static-max";
> > >      ents[1] = libxl__sprintf(gc, "%d", info->max_memkb);
> > >      ents[2] = "memory/target";
> > > @@ -138,9 +138,11 @@ int libxl__build_post(libxl__gc *gc, uin
> > >      ents[9] = libxl__sprintf(gc, "%"PRIu32, state->store_port);
> > >      ents[10] = "store/ring-ref";
> > >      ents[11] = libxl__sprintf(gc, "%lu", state->store_mfn);
> > > +    ents[12] = "data/generation-id";
> > > +    ents[13] = libxl__sprintf(gc, "0x%lx", state->vm_gid_addr);
> > >      for (i = 0; i < info->max_vcpus; i++) {
> > > -        ents[12+(i*2)]   = libxl__sprintf(gc,
> > "cpu/%d/availability", i);
> > > -        ents[12+(i*2)+1] = (i && info->cur_vcpus && !(info-
> > >cur_vcpus & (1 << i)))
> > > +        ents[14+(i*2)]   = libxl__sprintf(gc,
> > "cpu/%d/availability", i);
> > > +        ents[14+(i*2)+1] = (i && info->cur_vcpus && !(info-
> > >cur_vcpus
> > > + & (1 << i)))
> > >                              ? "offline" : "online";
> > >      }
> > >
> > > @@ -357,16 +359,19 @@ int libxl__domain_restore_common(libxl__
> > >      /* read signature */
> > >      int rc;
> > >      int hvm, pae, superpages;
> > > +    uint64_t gid;
> > >      switch (info->type) {
> > >      case LIBXL_DOMAIN_TYPE_HVM:
> > >          hvm = 1;
> > >          superpages = 1;
> > >          pae = info->u.hvm.pae;
> > > +        gid = info->u.hvm.generation_id;
> > >          break;
> > >      case LIBXL_DOMAIN_TYPE_PV:
> > >          hvm = 0;
> > >          superpages = 0;
> > >          pae = 1;
> > > +        gid = 0;
> > >          break;
> > >      default:
> > >          return ERROR_INVAL;
> > > @@ -374,7 +379,7 @@ int libxl__domain_restore_common(libxl__
> > >      rc = xc_domain_restore(ctx->xch, fd, domid,
> > >                             state->store_port, &state->store_mfn,
> > >                             state->console_port, &state-
> > >console_mfn,
> > > -                           hvm, pae, superpages);
> > > +                           hvm, pae, superpages, gid,
> > > + &state->vm_gid_addr);
> > >      if ( rc ) {
> > >          LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "restoring
> > domain");
> > >          return ERROR_FAIL;
> > > @@ -540,12 +545,22 @@ int libxl__domain_suspend_common(libxl__
> > >      struct save_callbacks callbacks;
> > >      struct suspendinfo si;
> > >      int hvm, rc = ERROR_FAIL;
> > > +    unsigned long vm_gid_addr;
> > >
> > >      switch (type) {
> > > -    case LIBXL_DOMAIN_TYPE_HVM:
> > > +    case LIBXL_DOMAIN_TYPE_HVM: {
> > > +        char *path;
> > > +        char *addr;
> > > +
> > > +        path = libxl__sprintf(gc, "%s/data/generation-id",
> > libxl__xs_get_dompath(gc, domid));
> > > +        addr = libxl__xs_read(gc, XBT_NULL, path);
> > > +
> > > +        vm_gid_addr = (addr) ? strtoul(addr, NULL, 0) : 0;
> > >          hvm = 1;
> > >          break;
> > > +    }
> > >      case LIBXL_DOMAIN_TYPE_PV:
> > > +        vm_gid_addr = 0;
> > >          hvm = 0;
> > >          break;
> > >      default:
> > > @@ -583,7 +598,8 @@ int libxl__domain_suspend_common(libxl__
> > >      callbacks.switch_qemu_logdirty =
> > libxl__domain_suspend_common_switch_qemu_logdirty;
> > >      callbacks.data = &si;
> > >
> > > -    rc = xc_domain_save(ctx->xch, fd, domid, 0, 0, flags,
> > &callbacks, hvm);
> > > +    rc = xc_domain_save(ctx->xch, fd, domid, 0, 0, flags,
> > &callbacks,
> > > +                        hvm, vm_gid_addr);
> > >      if ( rc ) {
> > >          LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "saving domain:
> > %s",
> > >                           si.guest_responded ?
> > > diff -r 3c4c29899d8a -r 94a17182f386 tools/libxl/libxl_internal.h
> > > --- a/tools/libxl/libxl_internal.h  Wed Nov 30 07:18:11 2011 -
> > 0800
> > > +++ b/tools/libxl/libxl_internal.h  Wed Nov 30 20:51:07 2011
> > +0000
> > > @@ -199,6 +199,8 @@ typedef struct {
> > >
> > >      uint32_t console_port;
> > >      unsigned long console_mfn;
> > > +
> > > +    unsigned long vm_gid_addr;
> > >  } libxl__domain_build_state;
> > >
> > >  _hidden int libxl__build_pre(libxl__gc *gc, uint32_t domid, diff
> > -r
> > > 3c4c29899d8a -r 94a17182f386 tools/libxl/libxl_types.idl
> > > --- a/tools/libxl/libxl_types.idl   Wed Nov 30 07:18:11 2011 -
> > 0800
> > > +++ b/tools/libxl/libxl_types.idl   Wed Nov 30 20:51:07 2011
> > +0000
> > > @@ -183,6 +183,7 @@ libxl_domain_build_info = Struct("domain
> > >                                         ("vpt_align", bool),
> > >                                         ("timer_mode", integer),
> > >                                         ("nested_hvm", bool),
> > > +                                       ("generation_id", uint64),
> > >                                         ])),
> > >                   ("pv", Struct(None, [("kernel",
> > libxl_file_reference),
> > >                                        ("slack_memkb", uint32),
> > diff
> > > -r 3c4c29899d8a -r 94a17182f386 tools/libxl/libxlu_cfg.c
> > > --- a/tools/libxl/libxlu_cfg.c      Wed Nov 30 07:18:11 2011 -0800
> > > +++ b/tools/libxl/libxlu_cfg.c      Wed Nov 30 20:51:07 2011 +0000
> > > @@ -235,6 +235,37 @@ int xlu_cfg_get_long(const XLU_Config *c
> > >      return 0;
> > >  }
> > >
> > > +int xlu_cfg_get_long_long(const XLU_Config *cfg, const char *n,
> > > +                          long long *value_r, int dont_warn) {
> > > +    long long ll;
> > > +    XLU_ConfigSetting *set;
> > > +    int e;
> > > +    char *ep;
> > > +
> > > +    e= find_atom(cfg,n,&set,dont_warn);  if (e) return e;
> > > +    errno= 0; ll= strtoll(set->values[0], &ep, 0);
> > > +    e= errno;
> > > +    if (errno) {
> > > +        e= errno;
> > > +        assert(e==EINVAL || e==ERANGE);
> > > +        if (!dont_warn)
> > > +            fprintf(cfg->report,
> > > +                    "%s:%d: warning: parameter `%s' could not be
> > parsed"
> > > +                    " as a number: %s\n",
> > > +                    cfg->filename, set->lineno, n, strerror(e));
> > > +        return e;
> > > +    }
> > > +    if (*ep || ep==set->values[0]) {
> > > +        if (!dont_warn)
> > > +            fprintf(cfg->report,
> > > +                    "%s:%d: warning: parameter `%s' is not a
> > valid number\n",
> > > +                    cfg->filename, set->lineno, n);
> > > +        return EINVAL;
> > > +    }
> > > +    *value_r= ll;
> > > +    return 0;
> > > +}
> > > +
> > >
> > >  int xlu_cfg_get_list(const XLU_Config *cfg, const char *n,
> > >                       XLU_ConfigList **list_r, int *entries_r, int
> > > dont_warn) { diff -r 3c4c29899d8a -r 94a17182f386
> > tools/libxl/libxlutil.h
> > > --- a/tools/libxl/libxlutil.h       Wed Nov 30 07:18:11 2011 -0800
> > > +++ b/tools/libxl/libxlutil.h       Wed Nov 30 20:51:07 2011 +0000
> > > @@ -52,6 +52,8 @@ int xlu_cfg_replace_string(const XLU_Con
> > >                             char **value_r, int dont_warn);  int
> > > xlu_cfg_get_long(const XLU_Config*, const char *n, long *value_r,
> > >                       int dont_warn);
> > > +int xlu_cfg_get_long_long(const XLU_Config*, const char *n, long
> > long *value_r,
> > > +                          int dont_warn);
> > >
> > >  int xlu_cfg_get_list(const XLU_Config*, const char *n,
> > >                       XLU_ConfigList **list_r /* may be 0 */, diff
> > -r
> > > 3c4c29899d8a -r 94a17182f386 tools/libxl/xl_cmdimpl.c
> > > --- a/tools/libxl/xl_cmdimpl.c      Wed Nov 30 07:18:11 2011 -0800
> > > +++ b/tools/libxl/xl_cmdimpl.c      Wed Nov 30 20:51:07 2011 +0000
> > > @@ -573,6 +573,7 @@ static void parse_config_data(const char  {
> > >      const char *buf;
> > >      long l;
> > > +    long long ll;
> > >      XLU_Config *config;
> > >      XLU_ConfigList *vbds, *nics, *pcis, *cvfbs, *cpuids;
> > >      int pci_power_mgmt = 0;
> > > @@ -764,6 +765,8 @@ static void parse_config_data(const char
> > >              b_info->u.hvm.timer_mode = l;
> > >          if (!xlu_cfg_get_long (config, "nestedhvm", &l, 0))
> > >              b_info->u.hvm.nested_hvm = l;
> > > +        if (!xlu_cfg_get_long_long (config, "generation_id", &ll,
> > 0))
> > > +            b_info->u.hvm.nested_hvm = ll;
> > >          break;
> > >      case LIBXL_DOMAIN_TYPE_PV:
> > >      {
> > > diff -r 3c4c29899d8a -r 94a17182f386
> > tools/python/xen/lowlevel/checkpoint/libcheckpoint.c
> > > --- a/tools/python/xen/lowlevel/checkpoint/libcheckpoint.c  Wed
> > Nov 30 07:18:11 2011 -0800
> > > +++ b/tools/python/xen/lowlevel/checkpoint/libcheckpoint.c  Wed
> > Nov 30 20:51:07 2011 +0000
> > > @@ -174,6 +174,7 @@ int checkpoint_start(checkpoint_state* s  {
> > >      int hvm, rc;
> > >      int flags = XCFLAGS_LIVE;
> > > +    unsigned long vm_gid_addr;
> > >
> > >      if (!s->domid) {
> > >         s->errstr = "checkpoint state not opened"; @@ -184,14
> > +185,25
> > > @@ int checkpoint_start(checkpoint_state* s
> > >
> > >      hvm = s->domtype > dt_pv;
> > >      if (hvm) {
> > > +       char path[128];
> > > +       char *addr;
> > > +
> > > +       sprintf(path, "/local/domain/%u/data/generation-id", s-
> > >domid);
> > > +       addr = xs_read(s->xsh, XBT_NULL, path, NULL);
> > > +
> > > +       vm_gid_addr = (addr) ? strtoul(addr, NULL, 0) : 0;
> > > +       free(addr);
> > > +
> > >         flags |= XCFLAGS_HVM;
> > >         if (switch_qemu_logdirty(s, 1))
> > >             return -1;
> > > +    } else {
> > > +       vm_gid_addr = 0;
> > >      }
> > >
> > >      callbacks->switch_qemu_logdirty = noop_switch_logdirty;
> > >
> > > -    rc = xc_domain_save(s->xch, fd, s->domid, 0, 0, flags,
> > callbacks, hvm);
> > > +    rc = xc_domain_save(s->xch, fd, s->domid, 0, 0, flags,
> > callbacks,
> > > + hvm, vm_gid_addr);
> > >
> > >      if (hvm)
> > >         switch_qemu_logdirty(s, 0);
> > > diff -r 3c4c29899d8a -r 94a17182f386 tools/xcutils/xc_restore.c
> > > --- a/tools/xcutils/xc_restore.c    Wed Nov 30 07:18:11 2011 -0800
> > > +++ b/tools/xcutils/xc_restore.c    Wed Nov 30 20:51:07 2011 +0000
> > > @@ -23,7 +23,8 @@ main(int argc, char **argv)
> > >      xc_interface *xch;
> > >      int io_fd, ret;
> > >      int superpages;
> > > -    unsigned long store_mfn, console_mfn;
> > > +    unsigned long store_mfn, console_mfn, vm_gid_addr;
> > > +    uint64_t gid;
> > >
> > >      if ( (argc != 8) && (argc != 9) )
> > >          errx(1, "usage: %s iofd domid store_evtchn "
> > > @@ -40,19 +41,25 @@ main(int argc, char **argv)
> > >      hvm  = atoi(argv[5]);
> > >      pae  = atoi(argv[6]);
> > >      apic = atoi(argv[7]);
> > > -    if ( argc == 9 )
> > > +    if ( argc >= 9 )
> > >         superpages = atoi(argv[8]);
> > >      else
> > >         superpages = !!hvm;
> > > +    if ( argc >= 10 )
> > > +       gid = strtoll(argv[9], NULL, 0);
> > > +    else
> > > +       gid = 0;
> > >
> > >      ret = xc_domain_restore(xch, io_fd, domid, store_evtchn,
> > &store_mfn,
> > > -                            console_evtchn, &console_mfn, hvm,
> > pae, superpages);
> > > +                            console_evtchn, &console_mfn, hvm,
> > pae, superpages,
> > > +                            gid, &vm_gid_addr);
> > >
> > >      if ( ret == 0 )
> > >      {
> > >     printf("store-mfn %li\n", store_mfn);
> > >          if ( !hvm )
> > >              printf("console-mfn %li\n", console_mfn);
> > > +   printf("vm-gid-addr %lx\n", vm_gid_addr);
> > >     fflush(stdout);
> > >      }
> > >
> > > diff -r 3c4c29899d8a -r 94a17182f386 tools/xcutils/xc_save.c
> > > --- a/tools/xcutils/xc_save.c       Wed Nov 30 07:18:11 2011 -0800
> > > +++ b/tools/xcutils/xc_save.c       Wed Nov 30 20:51:07 2011 +0000
> > > @@ -169,6 +169,10 @@ main(int argc, char **argv)
> > >      unsigned int maxit, max_f;
> > >      int io_fd, ret, port;
> > >      struct save_callbacks callbacks;
> > > +    char path[128];
> > > +    struct xs_handle *xs;
> > > +    char *addr;
> > > +    unsigned long vm_gid_addr;
> > >
> > >      if (argc != 6)
> > >          errx(1, "usage: %s iofd domid maxit maxf flags",
> > argv[0]); @@
> > > -207,8 +211,21 @@ main(int argc, char **argv)
> > >      memset(&callbacks, 0, sizeof(callbacks));
> > >      callbacks.suspend = suspend;
> > >      callbacks.switch_qemu_logdirty = switch_qemu_logdirty;
> > > +
> > > +    sprintf(path, "/local/domain/%d/data/generation-id",
> > si.domid);
> > > +
> > > +    if ((xs = xs_daemon_open()) == NULL)
> > > +        errx(1, "Couldn't contact xenstore");
> > > +
> > > +    addr = xs_read(xs, XBT_NULL, path, NULL);
> > > +
> > > +    xs_daemon_close(xs);
> > > +
> > > +    vm_gid_addr = (addr) ? strtoul(addr, NULL, 0) : 0;
> > > +    free(addr);
> > > +
> > >      ret = xc_domain_save(si.xch, io_fd, si.domid, maxit, max_f,
> > si.flags,
> > > -                         &callbacks, !!(si.flags & XCFLAGS_HVM));
> > > +                         &callbacks, !!(si.flags & XCFLAGS_HVM),
> > > + vm_gid_addr);
> > >
> > >      if (si.suspend_evtchn > 0)
> > >      xc_suspend_evtchn_release(si.xch, si.xce, si.domid,
> > > si.suspend_evtchn);
> > >
> > > _______________________________________________
> > > Xen-devel mailing list
> > > Xen-devel@lists.xensource.com
> > > http://lists.xensource.com/xen-devel
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 09:10:03 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 09:10:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW2e4-0000PI-NM; Thu, 01 Dec 2011 09:09:32 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RW2e3-0000PD-BX
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 09:09:31 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1322730531!5698227!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQzODQ=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11219 invoked from network); 1 Dec 2011 09:08:51 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-3.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 1 Dec 2011 09:08:51 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 01 Dec 2011 09:09:33 +0000
Message-Id: <4ED7522E0200007800064973@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 01 Dec 2011 09:08:46 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>
References: <CAFA7027.25E35%keir.xen@gmail.com>
	<4ED62C50.7060204@citrix.com> <4ED666D5.5060603@citrix.com>
In-Reply-To: <4ED666D5.5060603@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Keir Fraser <keir.xen@gmail.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [RFC] KEXEC: allocate crash note buffers at boot
	time v2
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 30.11.11 at 18:24, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>-static DEFINE_PER_CPU_READ_MOSTLY(void *, crash_notes);
>+static void * crash_notes[NR_CPUS];

If at all possible, can you please allocate this dynamically using
nr_cpu_ids for the size?

>+static int kexec_init_cpu_notes(const int cpu)

If the function's argument was made 'unsigned int' (as it already is in
its caller), then ...

>+    BUG_ON( cpu < 0 || cpu >= NR_CPUS );

... only the second check would be needed. Furthermore, it's
pointless to use signed types for CPU numbers (and it's
inefficient on various architectures), despite there being numerous
(bad) examples throughout the tree.

>+    if ( 0 == cpu )
>+        nr_bytes = nr_bytes +
>+            sizeof_note("Xen", sizeof(crash_xen_info_t));

Minor nit: Why not use += here (presumably allowing the statement to
fit on one line)?

>+    if ( ! note )
>+        /* Ideally, this would be -ENOMEM.  However, there are more problems
>+         * assocated with trying to deal with -ENOMEM sensibly than just
>+         * pretending that the crash note area doesn't exist. */
>+        return 0;

The only current caller ignores the return value, so why the bogus
return value?

>+    if ( nr < 0 || nr >= nr_cpu_ids || !cpu_online(nr) || !crash_notes[nr] )
>...
>-    if ( per_cpu(crash_notes, nr) == NULL )
>-    {
>...
>-    }

I would suggest to retry allocation here. Even if this isn't suitable for
a 32-bit kdump kernel on large systems, there#s no reason to penalize
fully 64-bit environment.

And here it would also become meaningful that kexec_init_cpu_notes()
actually returns a meaningful error upon failure.

Also, I can't see the reason for the patch to move around
do_crashdump_trigger() and crashdump_trigger_keyhandler.

Jan


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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 09:10:03 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 09:10:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW2e4-0000PI-NM; Thu, 01 Dec 2011 09:09:32 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RW2e3-0000PD-BX
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 09:09:31 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1322730531!5698227!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQzODQ=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11219 invoked from network); 1 Dec 2011 09:08:51 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-3.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 1 Dec 2011 09:08:51 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 01 Dec 2011 09:09:33 +0000
Message-Id: <4ED7522E0200007800064973@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 01 Dec 2011 09:08:46 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>
References: <CAFA7027.25E35%keir.xen@gmail.com>
	<4ED62C50.7060204@citrix.com> <4ED666D5.5060603@citrix.com>
In-Reply-To: <4ED666D5.5060603@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Keir Fraser <keir.xen@gmail.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [RFC] KEXEC: allocate crash note buffers at boot
	time v2
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 30.11.11 at 18:24, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>-static DEFINE_PER_CPU_READ_MOSTLY(void *, crash_notes);
>+static void * crash_notes[NR_CPUS];

If at all possible, can you please allocate this dynamically using
nr_cpu_ids for the size?

>+static int kexec_init_cpu_notes(const int cpu)

If the function's argument was made 'unsigned int' (as it already is in
its caller), then ...

>+    BUG_ON( cpu < 0 || cpu >= NR_CPUS );

... only the second check would be needed. Furthermore, it's
pointless to use signed types for CPU numbers (and it's
inefficient on various architectures), despite there being numerous
(bad) examples throughout the tree.

>+    if ( 0 == cpu )
>+        nr_bytes = nr_bytes +
>+            sizeof_note("Xen", sizeof(crash_xen_info_t));

Minor nit: Why not use += here (presumably allowing the statement to
fit on one line)?

>+    if ( ! note )
>+        /* Ideally, this would be -ENOMEM.  However, there are more problems
>+         * assocated with trying to deal with -ENOMEM sensibly than just
>+         * pretending that the crash note area doesn't exist. */
>+        return 0;

The only current caller ignores the return value, so why the bogus
return value?

>+    if ( nr < 0 || nr >= nr_cpu_ids || !cpu_online(nr) || !crash_notes[nr] )
>...
>-    if ( per_cpu(crash_notes, nr) == NULL )
>-    {
>...
>-    }

I would suggest to retry allocation here. Even if this isn't suitable for
a 32-bit kdump kernel on large systems, there#s no reason to penalize
fully 64-bit environment.

And here it would also become meaningful that kexec_init_cpu_notes()
actually returns a meaningful error upon failure.

Also, I can't see the reason for the patch to move around
do_crashdump_trigger() and crashdump_trigger_keyhandler.

Jan


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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 09:16:46 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 09:16:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW2kC-0000ZN-Jj; Thu, 01 Dec 2011 09:15:52 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RW2kB-0000ZC-6w
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 09:15:51 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1322730911!3620426!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU2Nw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9849 invoked from network); 1 Dec 2011 09:15:11 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 09:15:11 -0000
X-IronPort-AV: E=Sophos;i="4.71,277,1320624000"; 
   d="scan'208";a="9223041"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Dec 2011 09:15:10 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 1 Dec 2011
	09:15:09 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Paul Durrant <paul.durrant@citrix.com>
Date: Thu, 1 Dec 2011 09:15:09 +0000
In-Reply-To: <94a17182f386c8bb414e.1322686717@cosworth.uk.xensource.com>
References: <94a17182f386c8bb414e.1322686717@cosworth.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322730909.31810.163.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] Add code to track the address of the VM
 generation id buffer across a
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2011-11-30 at 20:58 +0000, Paul Durrant wrote:

> diff -r 3c4c29899d8a -r 94a17182f386
> tools/libxc/ia64/xc_ia64_linux_restore.c
> --- a/tools/libxc/ia64/xc_ia64_linux_restore.c  Wed Nov 30 07:18:11
> 2011 -0800
> +++ b/tools/libxc/ia64/xc_ia64_linux_restore.c  Wed Nov 30 20:51:07
> 2011 +0000
> @@ -548,7 +548,8 @@ int
>  xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
>                    unsigned int store_evtchn, unsigned long
> *store_mfn,
>                    unsigned int console_evtchn, unsigned long
> *console_mfn,
> -                  unsigned int hvm, unsigned int pae, int superpages)
> +                  unsigned int hvm, unsigned int pae, int superpages,
> +                  uint64_t gid)

This is a uint64_t * in the non-ia64 case. is that right?

> diff -r 3c4c29899d8a -r 94a17182f386 tools/libxl/libxl_internal.h
> --- a/tools/libxl/libxl_internal.h      Wed Nov 30 07:18:11 2011 -0800
> +++ b/tools/libxl/libxl_internal.h      Wed Nov 30 20:51:07 2011 +0000
> @@ -199,6 +199,8 @@ typedef struct {
> 
>      uint32_t console_port;
>      unsigned long console_mfn;
> +
> +    unsigned long vm_gid_addr;

Is this large enough for a 64 bit guest even with 32 bit tools?

>  } libxl__domain_build_state;
> 
>  _hidden int libxl__build_pre(libxl__gc *gc, uint32_t domid,
> diff -r 3c4c29899d8a -r 94a17182f386 tools/libxl/libxl_types.idl
> --- a/tools/libxl/libxl_types.idl       Wed Nov 30 07:18:11 2011 -0800
> +++ b/tools/libxl/libxl_types.idl       Wed Nov 30 20:51:07 2011 +0000
> @@ -183,6 +183,7 @@ libxl_domain_build_info = Struct("domain
>                                         ("vpt_align", bool),
>                                         ("timer_mode", integer),
>                                         ("nested_hvm", bool),
> +                                       ("generation_id", uint64),
>                                         ])),
>                   ("pv", Struct(None, [("kernel", libxl_file_reference),
>                                        ("slack_memkb", uint32),
> diff -r 3c4c29899d8a -r 94a17182f386 tools/libxl/xl_cmdimpl.c
> --- a/tools/libxl/xl_cmdimpl.c  Wed Nov 30 07:18:11 2011 -0800
> +++ b/tools/libxl/xl_cmdimpl.c  Wed Nov 30 20:51:07 2011 +0000
> @@ -573,6 +573,7 @@ static void parse_config_data(const char
>  {
>      const char *buf;
>      long l;
> +    long long ll;
>      XLU_Config *config;
>      XLU_ConfigList *vbds, *nics, *pcis, *cvfbs, *cpuids;
>      int pci_power_mgmt = 0;
> @@ -764,6 +765,8 @@ static void parse_config_data(const char
>              b_info->u.hvm.timer_mode = l;
>          if (!xlu_cfg_get_long (config, "nestedhvm", &l, 0))
>              b_info->u.hvm.nested_hvm = l;
> +        if (!xlu_cfg_get_long_long (config, "generation_id", &ll, 0))
> +            b_info->u.hvm.nested_hvm = ll;

Are you you tested this?

Also please patch docs/man/xl.cfg.pod.5 with a description of this new
key.

> diff -r 3c4c29899d8a -r 94a17182f386 tools/xcutils/xc_restore.c
> --- a/tools/xcutils/xc_restore.c        Wed Nov 30 07:18:11 2011 -0800
> +++ b/tools/xcutils/xc_restore.c        Wed Nov 30 20:51:07 2011 +0000
> @@ -23,7 +23,8 @@ main(int argc, char **argv)
>      xc_interface *xch;
>      int io_fd, ret;
>      int superpages;
> -    unsigned long store_mfn, console_mfn;
> +    unsigned long store_mfn, console_mfn, vm_gid_addr;
> +    uint64_t gid;
> 
>      if ( (argc != 8) && (argc != 9) )
>          errx(1, "usage: %s iofd domid store_evtchn "
> @@ -40,19 +41,25 @@ main(int argc, char **argv)
>      hvm  = atoi(argv[5]);
>      pae  = atoi(argv[6]);
>      apic = atoi(argv[7]);
> -    if ( argc == 9 )
> +    if ( argc >= 9 )
>             superpages = atoi(argv[8]);
>      else
>             superpages = !!hvm;
> +    if ( argc >= 10 )
> +           gid = strtoll(argv[9], NULL, 0);
> +    else
> +           gid = 0;

I don't think you need to do anything more complex than pass vm_gid_addr
as NULL here unless you are also going to patch xend.

I didn't see anywhere which cranked the value on restore, it seems to
just propagate the value from the cfg file. Is that actually useful?

Does the user really need to be able to specify the initial value? Would
it not be easier to just generate a new value somehow when creating the
domain? No ones going to edit their cfg each time they start the vm.

Ian.



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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 09:16:46 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 09:16:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW2kC-0000ZN-Jj; Thu, 01 Dec 2011 09:15:52 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RW2kB-0000ZC-6w
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 09:15:51 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1322730911!3620426!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU2Nw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9849 invoked from network); 1 Dec 2011 09:15:11 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 09:15:11 -0000
X-IronPort-AV: E=Sophos;i="4.71,277,1320624000"; 
   d="scan'208";a="9223041"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Dec 2011 09:15:10 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 1 Dec 2011
	09:15:09 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Paul Durrant <paul.durrant@citrix.com>
Date: Thu, 1 Dec 2011 09:15:09 +0000
In-Reply-To: <94a17182f386c8bb414e.1322686717@cosworth.uk.xensource.com>
References: <94a17182f386c8bb414e.1322686717@cosworth.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322730909.31810.163.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] Add code to track the address of the VM
 generation id buffer across a
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2011-11-30 at 20:58 +0000, Paul Durrant wrote:

> diff -r 3c4c29899d8a -r 94a17182f386
> tools/libxc/ia64/xc_ia64_linux_restore.c
> --- a/tools/libxc/ia64/xc_ia64_linux_restore.c  Wed Nov 30 07:18:11
> 2011 -0800
> +++ b/tools/libxc/ia64/xc_ia64_linux_restore.c  Wed Nov 30 20:51:07
> 2011 +0000
> @@ -548,7 +548,8 @@ int
>  xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
>                    unsigned int store_evtchn, unsigned long
> *store_mfn,
>                    unsigned int console_evtchn, unsigned long
> *console_mfn,
> -                  unsigned int hvm, unsigned int pae, int superpages)
> +                  unsigned int hvm, unsigned int pae, int superpages,
> +                  uint64_t gid)

This is a uint64_t * in the non-ia64 case. is that right?

> diff -r 3c4c29899d8a -r 94a17182f386 tools/libxl/libxl_internal.h
> --- a/tools/libxl/libxl_internal.h      Wed Nov 30 07:18:11 2011 -0800
> +++ b/tools/libxl/libxl_internal.h      Wed Nov 30 20:51:07 2011 +0000
> @@ -199,6 +199,8 @@ typedef struct {
> 
>      uint32_t console_port;
>      unsigned long console_mfn;
> +
> +    unsigned long vm_gid_addr;

Is this large enough for a 64 bit guest even with 32 bit tools?

>  } libxl__domain_build_state;
> 
>  _hidden int libxl__build_pre(libxl__gc *gc, uint32_t domid,
> diff -r 3c4c29899d8a -r 94a17182f386 tools/libxl/libxl_types.idl
> --- a/tools/libxl/libxl_types.idl       Wed Nov 30 07:18:11 2011 -0800
> +++ b/tools/libxl/libxl_types.idl       Wed Nov 30 20:51:07 2011 +0000
> @@ -183,6 +183,7 @@ libxl_domain_build_info = Struct("domain
>                                         ("vpt_align", bool),
>                                         ("timer_mode", integer),
>                                         ("nested_hvm", bool),
> +                                       ("generation_id", uint64),
>                                         ])),
>                   ("pv", Struct(None, [("kernel", libxl_file_reference),
>                                        ("slack_memkb", uint32),
> diff -r 3c4c29899d8a -r 94a17182f386 tools/libxl/xl_cmdimpl.c
> --- a/tools/libxl/xl_cmdimpl.c  Wed Nov 30 07:18:11 2011 -0800
> +++ b/tools/libxl/xl_cmdimpl.c  Wed Nov 30 20:51:07 2011 +0000
> @@ -573,6 +573,7 @@ static void parse_config_data(const char
>  {
>      const char *buf;
>      long l;
> +    long long ll;
>      XLU_Config *config;
>      XLU_ConfigList *vbds, *nics, *pcis, *cvfbs, *cpuids;
>      int pci_power_mgmt = 0;
> @@ -764,6 +765,8 @@ static void parse_config_data(const char
>              b_info->u.hvm.timer_mode = l;
>          if (!xlu_cfg_get_long (config, "nestedhvm", &l, 0))
>              b_info->u.hvm.nested_hvm = l;
> +        if (!xlu_cfg_get_long_long (config, "generation_id", &ll, 0))
> +            b_info->u.hvm.nested_hvm = ll;

Are you you tested this?

Also please patch docs/man/xl.cfg.pod.5 with a description of this new
key.

> diff -r 3c4c29899d8a -r 94a17182f386 tools/xcutils/xc_restore.c
> --- a/tools/xcutils/xc_restore.c        Wed Nov 30 07:18:11 2011 -0800
> +++ b/tools/xcutils/xc_restore.c        Wed Nov 30 20:51:07 2011 +0000
> @@ -23,7 +23,8 @@ main(int argc, char **argv)
>      xc_interface *xch;
>      int io_fd, ret;
>      int superpages;
> -    unsigned long store_mfn, console_mfn;
> +    unsigned long store_mfn, console_mfn, vm_gid_addr;
> +    uint64_t gid;
> 
>      if ( (argc != 8) && (argc != 9) )
>          errx(1, "usage: %s iofd domid store_evtchn "
> @@ -40,19 +41,25 @@ main(int argc, char **argv)
>      hvm  = atoi(argv[5]);
>      pae  = atoi(argv[6]);
>      apic = atoi(argv[7]);
> -    if ( argc == 9 )
> +    if ( argc >= 9 )
>             superpages = atoi(argv[8]);
>      else
>             superpages = !!hvm;
> +    if ( argc >= 10 )
> +           gid = strtoll(argv[9], NULL, 0);
> +    else
> +           gid = 0;

I don't think you need to do anything more complex than pass vm_gid_addr
as NULL here unless you are also going to patch xend.

I didn't see anywhere which cranked the value on restore, it seems to
just propagate the value from the cfg file. Is that actually useful?

Does the user really need to be able to specify the initial value? Would
it not be easier to just generate a new value somehow when creating the
domain? No ones going to edit their cfg each time they start the vm.

Ian.



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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 09:24:15 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 09:24:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW2rt-0000kA-Hz; Thu, 01 Dec 2011 09:23:49 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RW2rt-0000k0-12
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 09:23:49 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1322731389!3817570!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU2Nw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2592 invoked from network); 1 Dec 2011 09:23:09 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 09:23:09 -0000
X-IronPort-AV: E=Sophos;i="4.71,277,1320624000"; 
   d="scan'208";a="9223274"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Dec 2011 09:23:09 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 1 Dec 2011
	09:23:09 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Date: Thu, 1 Dec 2011 09:23:08 +0000
In-Reply-To: <20111130205037.GA5176@aepfle.de>
References: <patchbomb.1322576442@cosworth.uk.xensource.com>
	<37b46c492f8ac8d356b2.1322576453@cosworth.uk.xensource.com>
	<20111130205037.GA5176@aepfle.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322731389.31810.165.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Ian
	Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 11 of 17 v3] docs: generate an index for the
 html output
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2011-11-30 at 20:50 +0000, Olaf Hering wrote:
> On Tue, Nov 29, Ian Campbell wrote:
> 
> > +use List::MoreUtils qw/ uniq /;
> 
> This adds a new requires of perl-List-MoreUtils.rpm for make docs.
> I'm not sure wether such buildrequires need to be listed in the README,
> but at least markdown is listed. I think it is recommended for make docs

Lets just nuke the requirement, it's trivial to reimplement.

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1322731354 0
# Node ID faab9e3c36f0a4eaec7f2af5cad9d3c038ea489b
# Parent  89f7273681696022cc44db4f2ec5b22560482869
docs: implement uniq instead of depending on List::MoreUtils

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

diff -r 89f727368169 -r faab9e3c36f0 docs/gen-html-index
--- a/docs/gen-html-index	Thu Dec 01 08:51:35 2011 +0100
+++ b/docs/gen-html-index	Thu Dec 01 09:22:34 2011 +0000
@@ -10,7 +10,6 @@ use warnings;
 use Getopt::Long;
 use IO::File;
 use File::Basename;
-use List::MoreUtils qw/ uniq /;
 
 Getopt::Long::Configure('bundling');
 
@@ -99,6 +98,12 @@ sub read_index ($$) {
     }
 }
 
+sub uniq (@) {
+    my %h;
+    foreach (@_) { $h{$_} = 1; }
+    return keys %h;
+}
+    
 for (@docs) { s,^\Q$outdir\E/,, }
 
 @docs = grep { -e "$outdir/$_" && (make_linktext($_) ne "NO-INDEX") } @docs;



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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 09:24:15 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 09:24:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW2rt-0000kA-Hz; Thu, 01 Dec 2011 09:23:49 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RW2rt-0000k0-12
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 09:23:49 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1322731389!3817570!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU2Nw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2592 invoked from network); 1 Dec 2011 09:23:09 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 09:23:09 -0000
X-IronPort-AV: E=Sophos;i="4.71,277,1320624000"; 
   d="scan'208";a="9223274"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Dec 2011 09:23:09 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 1 Dec 2011
	09:23:09 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Date: Thu, 1 Dec 2011 09:23:08 +0000
In-Reply-To: <20111130205037.GA5176@aepfle.de>
References: <patchbomb.1322576442@cosworth.uk.xensource.com>
	<37b46c492f8ac8d356b2.1322576453@cosworth.uk.xensource.com>
	<20111130205037.GA5176@aepfle.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322731389.31810.165.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Ian
	Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 11 of 17 v3] docs: generate an index for the
 html output
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2011-11-30 at 20:50 +0000, Olaf Hering wrote:
> On Tue, Nov 29, Ian Campbell wrote:
> 
> > +use List::MoreUtils qw/ uniq /;
> 
> This adds a new requires of perl-List-MoreUtils.rpm for make docs.
> I'm not sure wether such buildrequires need to be listed in the README,
> but at least markdown is listed. I think it is recommended for make docs

Lets just nuke the requirement, it's trivial to reimplement.

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1322731354 0
# Node ID faab9e3c36f0a4eaec7f2af5cad9d3c038ea489b
# Parent  89f7273681696022cc44db4f2ec5b22560482869
docs: implement uniq instead of depending on List::MoreUtils

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

diff -r 89f727368169 -r faab9e3c36f0 docs/gen-html-index
--- a/docs/gen-html-index	Thu Dec 01 08:51:35 2011 +0100
+++ b/docs/gen-html-index	Thu Dec 01 09:22:34 2011 +0000
@@ -10,7 +10,6 @@ use warnings;
 use Getopt::Long;
 use IO::File;
 use File::Basename;
-use List::MoreUtils qw/ uniq /;
 
 Getopt::Long::Configure('bundling');
 
@@ -99,6 +98,12 @@ sub read_index ($$) {
     }
 }
 
+sub uniq (@) {
+    my %h;
+    foreach (@_) { $h{$_} = 1; }
+    return keys %h;
+}
+    
 for (@docs) { s,^\Q$outdir\E/,, }
 
 @docs = grep { -e "$outdir/$_" && (make_linktext($_) ne "NO-INDEX") } @docs;



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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 09:25:33 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 09:25:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW2tB-0000o1-7N; Thu, 01 Dec 2011 09:25:09 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RW2t9-0000ne-SZ
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 09:25:08 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1322731467!3778654!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQzODQ=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21071 invoked from network); 1 Dec 2011 09:24:27 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-2.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 1 Dec 2011 09:24:27 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 01 Dec 2011 09:25:41 +0000
Message-Id: <4ED755D70200007800064987@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 01 Dec 2011 09:24:23 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: <ke.yu@intel.com>,<kevin.tian@intel.com>,
	"Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <1322673664-14642-1-git-send-email-konrad.wilk@oracle.com>
	<1322673664-14642-6-git-send-email-konrad.wilk@oracle.com>
In-Reply-To: <1322673664-14642-6-git-send-email-konrad.wilk@oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: jeremy@goop.org, xen-devel@lists.xensource.com, Ian.Campbell@citrix.com,
	linux-acpi@vger.kernel.org, mike.mcclurg@citrix.com,
	linux-kernel@vger.kernel.org, stefan.bader@canonical.com,
	rjw@sisk.pl, konrad@kernel.org, liang.tang@oracle.com, lenb@kernel.org
Subject: Re: [Xen-devel] [PATCH 5/8] ACPI: add processor driver for Xen
 virtual CPUs.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 30.11.11 at 18:21, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> --- a/drivers/acpi/Makefile
> +++ b/drivers/acpi/Makefile
> @@ -66,6 +66,7 @@ obj-$(CONFIG_ACPI_CUSTOM_METHOD)+= custom_method.o
>  # processor has its own "processor." module_param namespace
>  processor-y			:= processor_driver.o processor_throttling.o
>  processor-y			+= processor_idle.o processor_thermal.o
> +processor-y			+= processor_xen.o

This should minimally be processor-$(CONFIG_XEN), with other things
adjusted as necessary.

>  processor-$(CONFIG_CPU_FREQ)	+= processor_perflib.o
>  
>  obj-$(CONFIG_ACPI_PROCESSOR_AGGREGATOR) += acpi_pad.o
>...
> --- a/drivers/xen/Kconfig
> +++ b/drivers/xen/Kconfig
> @@ -117,6 +117,11 @@ config XEN_SYS_HYPERVISOR
>  	 virtual environment, /sys/hypervisor will still be present,
>  	 but will have no xen contents.
>  
> +config ACPI_PROCESSOR_XEN
> +	tristate
> +	depends on XEN_DOM0 && ACPI_PROCESSOR && CPU_FREQ
> +	default m

default ACPI_PROCESSOR

> +
>  config XEN_XENBUS_FRONTEND
>  	tristate
>  
> diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
> index 974fffd..f67450c 100644
> --- a/drivers/xen/Makefile
> +++ b/drivers/xen/Makefile
> @@ -19,6 +19,9 @@ obj-$(CONFIG_XEN_TMEM)			+= tmem.o
>  obj-$(CONFIG_SWIOTLB_XEN)		+= swiotlb-xen.o
>  obj-$(CONFIG_XEN_DOM0)			+= pci.o
>  obj-$(CONFIG_XEN_PCIDEV_BACKEND)	+= xen-pciback/
> +ifdef CONFIG_ACPI_PROCESSOR_XEN
> +obj-$(CONFIG_ACPI_PROCESSOR)		+= acpi_processor.o
> +endif

obj-$(CONFIG_ACPI_PPROCESSOR_XEN)

Jan


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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 09:25:33 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 09:25:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW2tB-0000o1-7N; Thu, 01 Dec 2011 09:25:09 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RW2t9-0000ne-SZ
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 09:25:08 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1322731467!3778654!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQzODQ=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21071 invoked from network); 1 Dec 2011 09:24:27 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-2.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 1 Dec 2011 09:24:27 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 01 Dec 2011 09:25:41 +0000
Message-Id: <4ED755D70200007800064987@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 01 Dec 2011 09:24:23 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: <ke.yu@intel.com>,<kevin.tian@intel.com>,
	"Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <1322673664-14642-1-git-send-email-konrad.wilk@oracle.com>
	<1322673664-14642-6-git-send-email-konrad.wilk@oracle.com>
In-Reply-To: <1322673664-14642-6-git-send-email-konrad.wilk@oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: jeremy@goop.org, xen-devel@lists.xensource.com, Ian.Campbell@citrix.com,
	linux-acpi@vger.kernel.org, mike.mcclurg@citrix.com,
	linux-kernel@vger.kernel.org, stefan.bader@canonical.com,
	rjw@sisk.pl, konrad@kernel.org, liang.tang@oracle.com, lenb@kernel.org
Subject: Re: [Xen-devel] [PATCH 5/8] ACPI: add processor driver for Xen
 virtual CPUs.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 30.11.11 at 18:21, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> --- a/drivers/acpi/Makefile
> +++ b/drivers/acpi/Makefile
> @@ -66,6 +66,7 @@ obj-$(CONFIG_ACPI_CUSTOM_METHOD)+= custom_method.o
>  # processor has its own "processor." module_param namespace
>  processor-y			:= processor_driver.o processor_throttling.o
>  processor-y			+= processor_idle.o processor_thermal.o
> +processor-y			+= processor_xen.o

This should minimally be processor-$(CONFIG_XEN), with other things
adjusted as necessary.

>  processor-$(CONFIG_CPU_FREQ)	+= processor_perflib.o
>  
>  obj-$(CONFIG_ACPI_PROCESSOR_AGGREGATOR) += acpi_pad.o
>...
> --- a/drivers/xen/Kconfig
> +++ b/drivers/xen/Kconfig
> @@ -117,6 +117,11 @@ config XEN_SYS_HYPERVISOR
>  	 virtual environment, /sys/hypervisor will still be present,
>  	 but will have no xen contents.
>  
> +config ACPI_PROCESSOR_XEN
> +	tristate
> +	depends on XEN_DOM0 && ACPI_PROCESSOR && CPU_FREQ
> +	default m

default ACPI_PROCESSOR

> +
>  config XEN_XENBUS_FRONTEND
>  	tristate
>  
> diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
> index 974fffd..f67450c 100644
> --- a/drivers/xen/Makefile
> +++ b/drivers/xen/Makefile
> @@ -19,6 +19,9 @@ obj-$(CONFIG_XEN_TMEM)			+= tmem.o
>  obj-$(CONFIG_SWIOTLB_XEN)		+= swiotlb-xen.o
>  obj-$(CONFIG_XEN_DOM0)			+= pci.o
>  obj-$(CONFIG_XEN_PCIDEV_BACKEND)	+= xen-pciback/
> +ifdef CONFIG_ACPI_PROCESSOR_XEN
> +obj-$(CONFIG_ACPI_PROCESSOR)		+= acpi_processor.o
> +endif

obj-$(CONFIG_ACPI_PPROCESSOR_XEN)

Jan


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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 09:36:03 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 09:36:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW33R-0001Lk-2z; Thu, 01 Dec 2011 09:35:45 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <sandr8@gmail.com>) id 1RW33Q-0001Lf-F2
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 09:35:44 +0000
X-Env-Sender: sandr8@gmail.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1322732103!6337090!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25953 invoked from network); 1 Dec 2011 09:35:04 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-11.tower-21.messagelabs.com with AES256-SHA encrypted SMTP;
	1 Dec 2011 09:35:04 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <sandr8@gmail.com>) id 1RW32k-0003Ez-NL
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 01:35:02 -0800
Date: Thu, 1 Dec 2011 01:35:02 -0800 (PST)
From: sandr8 <sandr8@gmail.com>
To: xen-devel@lists.xensource.com
Message-ID: <1322732102716-5038145.post@n5.nabble.com>
In-Reply-To: <1316571734360-4824822.post@n5.nabble.com>
References: <1316338995760-4815691.post@n5.nabble.com>
	<alpine.DEB.2.00.1109201908010.8700@kaball-desktop>
	<1316571734360-4824822.post@n5.nabble.com>
MIME-Version: 1.0
Subject: Re: [Xen-devel] Permission for xenstore operation on HVM
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

[re-sending because it didn't go through at first, and - while at that -
editing]

duolvxendev, 

  I am hitting this too and I really wish there were a trick to avoid
this... 

I have a theory with regard to this. 

char *rw_paths[] = { "control/shutdown", "device",
"device/suspend/event-channel" , "data"}; 

should actually also include "vm-data". People who bypass libxl (maybe by
using xm?) will not notice the issue. Unfortunately, I don't have a system
with xm at hand to double check this wild guess of mine... 

thanks! 
-alessandro-

--
View this message in context: http://xen.1045712.n5.nabble.com/Permission-for-xenstore-operation-on-HVM-tp4815691p5038145.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 09:36:03 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 09:36:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW33R-0001Lk-2z; Thu, 01 Dec 2011 09:35:45 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <sandr8@gmail.com>) id 1RW33Q-0001Lf-F2
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 09:35:44 +0000
X-Env-Sender: sandr8@gmail.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1322732103!6337090!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25953 invoked from network); 1 Dec 2011 09:35:04 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-11.tower-21.messagelabs.com with AES256-SHA encrypted SMTP;
	1 Dec 2011 09:35:04 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <sandr8@gmail.com>) id 1RW32k-0003Ez-NL
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 01:35:02 -0800
Date: Thu, 1 Dec 2011 01:35:02 -0800 (PST)
From: sandr8 <sandr8@gmail.com>
To: xen-devel@lists.xensource.com
Message-ID: <1322732102716-5038145.post@n5.nabble.com>
In-Reply-To: <1316571734360-4824822.post@n5.nabble.com>
References: <1316338995760-4815691.post@n5.nabble.com>
	<alpine.DEB.2.00.1109201908010.8700@kaball-desktop>
	<1316571734360-4824822.post@n5.nabble.com>
MIME-Version: 1.0
Subject: Re: [Xen-devel] Permission for xenstore operation on HVM
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

[re-sending because it didn't go through at first, and - while at that -
editing]

duolvxendev, 

  I am hitting this too and I really wish there were a trick to avoid
this... 

I have a theory with regard to this. 

char *rw_paths[] = { "control/shutdown", "device",
"device/suspend/event-channel" , "data"}; 

should actually also include "vm-data". People who bypass libxl (maybe by
using xm?) will not notice the issue. Unfortunately, I don't have a system
with xm at hand to double check this wild guess of mine... 

thanks! 
-alessandro-

--
View this message in context: http://xen.1045712.n5.nabble.com/Permission-for-xenstore-operation-on-HVM-tp4815691p5038145.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 09:47:18 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 09: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.xensource.com>)
	id 1RW3EF-0001bX-9X; Thu, 01 Dec 2011 09:46:55 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <vase@selfip.ru>) id 1RW3EE-0001bP-9Y
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 09:46:54 +0000
X-Env-Sender: vase@selfip.ru
X-Msg-Ref: server-12.tower-21.messagelabs.com!1322732772!6363020!1
X-Originating-IP: [74.125.83.43]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_50_60,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_TEST_2,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11070 invoked from network); 1 Dec 2011 09:46:12 -0000
Received: from mail-ee0-f43.google.com (HELO mail-ee0-f43.google.com)
	(74.125.83.43)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 09:46:12 -0000
Received: by eeaq46 with SMTP id q46so1915161eea.30
	for <xen-devel@lists.xensource.com>;
	Thu, 01 Dec 2011 01:46:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=selfip.ru; s=google;
	h=mime-version:sender:x-originating-ip:in-reply-to:references:from
	:date:x-google-sender-auth:message-id:subject:to:cc:content-type;
	bh=M8N0FdtFKyJvYYnUHtjTnFQDV4IyV70Z9fP1/OJikC0=;
	b=QecMvkhX9xKDDxiFJIgCT+ewBojcqd6i6jomqstMaHawaEwhHj6KKsR9rcXcEhgJa4
	opkQWoh94nn84zsaPYKKZAxGDq2t+0m6AdR6W61lOYUj9TRKE+wrK+RqS4DkrdZv29zp
	OeYjC45wivUvLJI7xWeJJVgE4gQImRV31OMmc=
Received: by 10.216.221.143 with SMTP id r15mr651467wep.71.1322732771965; Thu,
	01 Dec 2011 01:46:11 -0800 (PST)
MIME-Version: 1.0
Received: by 10.217.2.202 with HTTP; Thu, 1 Dec 2011 01:45:55 -0800 (PST)
X-Originating-IP: [85.143.161.18]
In-Reply-To: <1316571734360-4824822.post@n5.nabble.com>
References: <1316338995760-4815691.post@n5.nabble.com>
	<alpine.DEB.2.00.1109201908010.8700@kaball-desktop>
	<1316571734360-4824822.post@n5.nabble.com>
From: Vasiliy Tolstov <v.tolstov@selfip.ru>
Date: Thu, 1 Dec 2011 13:45:55 +0400
X-Google-Sender-Auth: za0190VnYBEmpZ2qnG1h6LW6MEI
Message-ID: <CACaajQs+WP3XnHLSbLk_-3LpsmRvWeJGY9Ws=-fRTgPyaNzwVw@mail.gmail.com>
To: duolvxendev <duolvxendev@yahoo.cn>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Permission for xenstore operation on HVM
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0124699668927056737=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============0124699668927056737==
Content-Type: multipart/alternative; boundary=0016e659f5cc017aa104b304b9bd

--0016e659f5cc017aa104b304b9bd
Content-Type: text/plain; charset=UTF-8

2011/9/21 duolvxendev <duolvxendev@yahoo.cn>

> I'm trying to create a directory and write some messages, i.e. to some path
> like /local/domain/$DOMID/my_directory/my_key. This is OK on pv domU, but
> denied on HVM. I can write to /local/domain/device directory by frontend
> driver, but I cannot create or write to some arbitrary path that doesn't
> exist. It looks like that one needs special permission on HVM.
>
> --
>

In HVM mode You allow write to /local/domain/$DOMID/data


-- 
Vasiliy Tolstov,
Clodo.ru
e-mail: v.tolstov@selfip.ru
jabber: vase@selfip.ru

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

<br><br><div class=3D"gmail_quote">2011/9/21 duolvxendev <span dir=3D"ltr">=
&lt;<a href=3D"mailto:duolvxendev@yahoo.cn">duolvxendev@yahoo.cn</a>&gt;</s=
pan><br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border=
-left:1px #ccc solid;padding-left:1ex;">

I&#39;m trying to create a directory and write some messages, i.e. to some =
path<br>
like /local/domain/$DOMID/my_directory/my_key. This is OK on pv domU, but<b=
r>
denied on HVM. I can write to /local/domain/device directory by frontend<br=
>
driver, but I cannot create or write to some arbitrary path that doesn&#39;=
t<br>
exist. It looks like that one needs special permission on HVM.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
--<br></font></span></blockquote><div><br></div><div>In HVM mode You allow =
write to /local/domain/$DOMID/data=C2=A0</div></div><br clear=3D"all"><div>=
<br></div>-- <br><span style=3D"border-collapse:collapse;color:rgb(136, 136=
, 136);font-family:arial, sans-serif;font-size:13px"><div>

<div>Vasiliy Tolstov,</div><div>Clodo.ru</div><div>e-mail: <a href=3D"mailt=
o:v.tolstov@selfip.ru" target=3D"_blank">v.tolstov@selfip.ru</a></div><div>=
jabber: <a href=3D"mailto:vase@selfip.ru" target=3D"_blank">vase@selfip.ru<=
/a></div>

</div></span><br>

--0016e659f5cc017aa104b304b9bd--


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

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

--===============0124699668927056737==--


From xen-devel-bounces@lists.xensource.com Thu Dec 01 09:47:18 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 09: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.xensource.com>)
	id 1RW3EF-0001bX-9X; Thu, 01 Dec 2011 09:46:55 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <vase@selfip.ru>) id 1RW3EE-0001bP-9Y
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 09:46:54 +0000
X-Env-Sender: vase@selfip.ru
X-Msg-Ref: server-12.tower-21.messagelabs.com!1322732772!6363020!1
X-Originating-IP: [74.125.83.43]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_50_60,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_TEST_2,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11070 invoked from network); 1 Dec 2011 09:46:12 -0000
Received: from mail-ee0-f43.google.com (HELO mail-ee0-f43.google.com)
	(74.125.83.43)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 09:46:12 -0000
Received: by eeaq46 with SMTP id q46so1915161eea.30
	for <xen-devel@lists.xensource.com>;
	Thu, 01 Dec 2011 01:46:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=selfip.ru; s=google;
	h=mime-version:sender:x-originating-ip:in-reply-to:references:from
	:date:x-google-sender-auth:message-id:subject:to:cc:content-type;
	bh=M8N0FdtFKyJvYYnUHtjTnFQDV4IyV70Z9fP1/OJikC0=;
	b=QecMvkhX9xKDDxiFJIgCT+ewBojcqd6i6jomqstMaHawaEwhHj6KKsR9rcXcEhgJa4
	opkQWoh94nn84zsaPYKKZAxGDq2t+0m6AdR6W61lOYUj9TRKE+wrK+RqS4DkrdZv29zp
	OeYjC45wivUvLJI7xWeJJVgE4gQImRV31OMmc=
Received: by 10.216.221.143 with SMTP id r15mr651467wep.71.1322732771965; Thu,
	01 Dec 2011 01:46:11 -0800 (PST)
MIME-Version: 1.0
Received: by 10.217.2.202 with HTTP; Thu, 1 Dec 2011 01:45:55 -0800 (PST)
X-Originating-IP: [85.143.161.18]
In-Reply-To: <1316571734360-4824822.post@n5.nabble.com>
References: <1316338995760-4815691.post@n5.nabble.com>
	<alpine.DEB.2.00.1109201908010.8700@kaball-desktop>
	<1316571734360-4824822.post@n5.nabble.com>
From: Vasiliy Tolstov <v.tolstov@selfip.ru>
Date: Thu, 1 Dec 2011 13:45:55 +0400
X-Google-Sender-Auth: za0190VnYBEmpZ2qnG1h6LW6MEI
Message-ID: <CACaajQs+WP3XnHLSbLk_-3LpsmRvWeJGY9Ws=-fRTgPyaNzwVw@mail.gmail.com>
To: duolvxendev <duolvxendev@yahoo.cn>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Permission for xenstore operation on HVM
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0124699668927056737=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============0124699668927056737==
Content-Type: multipart/alternative; boundary=0016e659f5cc017aa104b304b9bd

--0016e659f5cc017aa104b304b9bd
Content-Type: text/plain; charset=UTF-8

2011/9/21 duolvxendev <duolvxendev@yahoo.cn>

> I'm trying to create a directory and write some messages, i.e. to some path
> like /local/domain/$DOMID/my_directory/my_key. This is OK on pv domU, but
> denied on HVM. I can write to /local/domain/device directory by frontend
> driver, but I cannot create or write to some arbitrary path that doesn't
> exist. It looks like that one needs special permission on HVM.
>
> --
>

In HVM mode You allow write to /local/domain/$DOMID/data


-- 
Vasiliy Tolstov,
Clodo.ru
e-mail: v.tolstov@selfip.ru
jabber: vase@selfip.ru

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

<br><br><div class=3D"gmail_quote">2011/9/21 duolvxendev <span dir=3D"ltr">=
&lt;<a href=3D"mailto:duolvxendev@yahoo.cn">duolvxendev@yahoo.cn</a>&gt;</s=
pan><br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border=
-left:1px #ccc solid;padding-left:1ex;">

I&#39;m trying to create a directory and write some messages, i.e. to some =
path<br>
like /local/domain/$DOMID/my_directory/my_key. This is OK on pv domU, but<b=
r>
denied on HVM. I can write to /local/domain/device directory by frontend<br=
>
driver, but I cannot create or write to some arbitrary path that doesn&#39;=
t<br>
exist. It looks like that one needs special permission on HVM.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
--<br></font></span></blockquote><div><br></div><div>In HVM mode You allow =
write to /local/domain/$DOMID/data=C2=A0</div></div><br clear=3D"all"><div>=
<br></div>-- <br><span style=3D"border-collapse:collapse;color:rgb(136, 136=
, 136);font-family:arial, sans-serif;font-size:13px"><div>

<div>Vasiliy Tolstov,</div><div>Clodo.ru</div><div>e-mail: <a href=3D"mailt=
o:v.tolstov@selfip.ru" target=3D"_blank">v.tolstov@selfip.ru</a></div><div>=
jabber: <a href=3D"mailto:vase@selfip.ru" target=3D"_blank">vase@selfip.ru<=
/a></div>

</div></span><br>

--0016e659f5cc017aa104b304b9bd--


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

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

--===============0124699668927056737==--


From xen-devel-bounces@lists.xensource.com Thu Dec 01 09:48:37 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 09:48:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW3FZ-0001fM-Pn; Thu, 01 Dec 2011 09:48:17 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RW3FX-0001ez-Ki
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 09:48:15 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1322732855!3830001!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU2Nw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18557 invoked from network); 1 Dec 2011 09:47:36 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 09:47:36 -0000
X-IronPort-AV: E=Sophos;i="4.71,277,1320624000"; 
   d="scan'208";a="9223892"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Dec 2011 09:47:14 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.161]) by
	LONPMAILMX01.citrite.net ([10.30.203.162]) with mapi; Thu, 1 Dec 2011
	09:47:14 +0000
From: Paul Durrant <Paul.Durrant@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Thu, 1 Dec 2011 09:47:21 +0000
Thread-Topic: [Xen-devel] [PATCH] Add code to track the address of the VM
	generation id buffer across a
Thread-Index: AcywB3wwvd9blO5dQbqY8GP3HI30NgABphsw
Message-ID: <291EDFCB1E9E224A99088639C4762022B5988E50EA@LONPMAILBOX01.citrite.net>
References: <94a17182f386c8bb414e.1322686717@cosworth.uk.xensource.com>
	<20111130221419.GA16651@andromeda.dapyr.net>
	<291EDFCB1E9E224A99088639C4762022B5988E50D4@LONPMAILBOX01.citrite.net>
	<1322729947.31810.151.camel@zakaz.uk.xensource.com>
In-Reply-To: <1322729947.31810.151.camel@zakaz.uk.xensource.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] Add code to track the address of the VM
 generation id buffer across a
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> -----Original Message-----
> From: Ian Campbell
> Sent: 01 December 2011 08:59
> To: Paul Durrant
> Cc: Konrad Rzeszutek Wilk; xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] [PATCH] Add code to track the address of
> the VM generation id buffer across a
> 
> On Thu, 2011-12-01 at 08:46 +0000, Paul Durrant wrote:
> > Konrad,
> >
> >   Did you see my previous patch set? The introductory comment was:
> 
> 
> I think that description belongs somewhere permanent, either in
> docs/misc or as a comment in an appropriate header.
> 

Good point. Perhaps I should stick the comment just above the device description in the dsdt?

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 09:48:37 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 09:48:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW3FZ-0001fM-Pn; Thu, 01 Dec 2011 09:48:17 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RW3FX-0001ez-Ki
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 09:48:15 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1322732855!3830001!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU2Nw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18557 invoked from network); 1 Dec 2011 09:47:36 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 09:47:36 -0000
X-IronPort-AV: E=Sophos;i="4.71,277,1320624000"; 
   d="scan'208";a="9223892"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Dec 2011 09:47:14 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.161]) by
	LONPMAILMX01.citrite.net ([10.30.203.162]) with mapi; Thu, 1 Dec 2011
	09:47:14 +0000
From: Paul Durrant <Paul.Durrant@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Thu, 1 Dec 2011 09:47:21 +0000
Thread-Topic: [Xen-devel] [PATCH] Add code to track the address of the VM
	generation id buffer across a
Thread-Index: AcywB3wwvd9blO5dQbqY8GP3HI30NgABphsw
Message-ID: <291EDFCB1E9E224A99088639C4762022B5988E50EA@LONPMAILBOX01.citrite.net>
References: <94a17182f386c8bb414e.1322686717@cosworth.uk.xensource.com>
	<20111130221419.GA16651@andromeda.dapyr.net>
	<291EDFCB1E9E224A99088639C4762022B5988E50D4@LONPMAILBOX01.citrite.net>
	<1322729947.31810.151.camel@zakaz.uk.xensource.com>
In-Reply-To: <1322729947.31810.151.camel@zakaz.uk.xensource.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] Add code to track the address of the VM
 generation id buffer across a
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> -----Original Message-----
> From: Ian Campbell
> Sent: 01 December 2011 08:59
> To: Paul Durrant
> Cc: Konrad Rzeszutek Wilk; xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] [PATCH] Add code to track the address of
> the VM generation id buffer across a
> 
> On Thu, 2011-12-01 at 08:46 +0000, Paul Durrant wrote:
> > Konrad,
> >
> >   Did you see my previous patch set? The introductory comment was:
> 
> 
> I think that description belongs somewhere permanent, either in
> docs/misc or as a comment in an appropriate header.
> 

Good point. Perhaps I should stick the comment just above the device description in the dsdt?

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 09:49:54 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 09:49:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW3Gt-0001lZ-8s; Thu, 01 Dec 2011 09:49:39 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RW3Gs-0001lI-Jo
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 09:49:38 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-2.tower-174.messagelabs.com!1322732938!3782884!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20666 invoked from network); 1 Dec 2011 09:48:59 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-2.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 1 Dec 2011 09:48:59 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RW3G4-000FcX-AM; Thu, 01 Dec 2011 09:48:48 +0000
Date: Thu, 1 Dec 2011 09:48:47 +0000
From: Tim Deegan <tim@xen.org>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
Message-ID: <20111201094847.GA59696@ocelot.phlegethon.org>
References: <4ED6676F02000078000646BC@nat28.tlf.novell.com>
	<20111130222359.GC16651@andromeda.dapyr.net>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20111130222359.GC16651@andromeda.dapyr.net>
User-Agent: Mutt/1.4.2.1i
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 2/2] x86/microcode: enable boot time
	(pre-Dom0) loading
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 18:23 -0400 on 30 Nov (1322677439), Konrad Rzeszutek Wilk wrote:
> On Wed, Nov 30, 2011 at 04:27:11PM +0000, Jan Beulich wrote:
> > Largely as a result of the continuing resistance of Linux maintainers
> > to accept a microcode loading patch for pv-ops Xen kernels, this
> > follows the suggested route and provides a means to load microcode
> > updates without the assistance of Dom0, thus also addressing eventual
> > problems in the hardware much earlier.
> > 
> > This leverages the fact that via the multiboot protocol another blob
> > of data can be easily added in the form of just an extra module. Since
> > microcode data cannot reliably be recognized by looking at the
> > provided data, this requires (in the non-EFI case) the use of a
> > command line parameter ("ucode=<number>") to identify which of the
> 
> Well, usually there would be two modules - the kernel (which we can
> identify) and the initramfs (which I guess one can also identify)?
> It seems that by process of elimination we could determine that the
> remaining module is the blob?

I'd really rather not do it that way - what if you want no initrd but do
have a microcode update? :)  And what if we want to add another
special-purpose multiboot module later?

It might be nice if that number could take negative values, though -
i.e. ucode=-1 to say 'use the last module in the list'.  Then the user
could adjust the dom0 modules without needing to recalculate.

Tim.

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 09:49:54 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 09:49:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW3Gt-0001lZ-8s; Thu, 01 Dec 2011 09:49:39 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RW3Gs-0001lI-Jo
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 09:49:38 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-2.tower-174.messagelabs.com!1322732938!3782884!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20666 invoked from network); 1 Dec 2011 09:48:59 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-2.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 1 Dec 2011 09:48:59 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RW3G4-000FcX-AM; Thu, 01 Dec 2011 09:48:48 +0000
Date: Thu, 1 Dec 2011 09:48:47 +0000
From: Tim Deegan <tim@xen.org>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
Message-ID: <20111201094847.GA59696@ocelot.phlegethon.org>
References: <4ED6676F02000078000646BC@nat28.tlf.novell.com>
	<20111130222359.GC16651@andromeda.dapyr.net>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20111130222359.GC16651@andromeda.dapyr.net>
User-Agent: Mutt/1.4.2.1i
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 2/2] x86/microcode: enable boot time
	(pre-Dom0) loading
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 18:23 -0400 on 30 Nov (1322677439), Konrad Rzeszutek Wilk wrote:
> On Wed, Nov 30, 2011 at 04:27:11PM +0000, Jan Beulich wrote:
> > Largely as a result of the continuing resistance of Linux maintainers
> > to accept a microcode loading patch for pv-ops Xen kernels, this
> > follows the suggested route and provides a means to load microcode
> > updates without the assistance of Dom0, thus also addressing eventual
> > problems in the hardware much earlier.
> > 
> > This leverages the fact that via the multiboot protocol another blob
> > of data can be easily added in the form of just an extra module. Since
> > microcode data cannot reliably be recognized by looking at the
> > provided data, this requires (in the non-EFI case) the use of a
> > command line parameter ("ucode=<number>") to identify which of the
> 
> Well, usually there would be two modules - the kernel (which we can
> identify) and the initramfs (which I guess one can also identify)?
> It seems that by process of elimination we could determine that the
> remaining module is the blob?

I'd really rather not do it that way - what if you want no initrd but do
have a microcode update? :)  And what if we want to add another
special-purpose multiboot module later?

It might be nice if that number could take negative values, though -
i.e. ucode=-1 to say 'use the last module in the list'.  Then the user
could adjust the dom0 modules without needing to recalculate.

Tim.

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 09:50:30 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 09:50:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW3HW-0001rg-4R; Thu, 01 Dec 2011 09:50:18 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1RW3HV-0001qv-21
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 09:50:17 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1322732976!5363385!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDM2NDY=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15594 invoked from network); 1 Dec 2011 09:49:37 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 09:49:37 -0000
X-IronPort-AV: E=Sophos;i="4.71,277,1320642000"; d="scan'208";a="19552280"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Dec 2011 04:49:35 -0500
Received: from [10.80.2.18] (10.80.2.18) by FTLPMAILMX01.citrite.net
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Thu, 1 Dec 2011
	04:49:35 -0500
Message-ID: <4ED74DAD.1040903@citrix.com>
Date: Thu, 1 Dec 2011 09:49:33 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.23) Gecko/20110921 Lightning/1.0b2 Thunderbird/3.1.15
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <CAFA7027.25E35%keir.xen@gmail.com> <4ED62C50.7060204@citrix.com>
	<4ED666D5.5060603@citrix.com>
	<4ED7522E0200007800064973@nat28.tlf.novell.com>
In-Reply-To: <4ED7522E0200007800064973@nat28.tlf.novell.com>
X-Enigmail-Version: 1.1.2
Cc: Keir Fraser <keir.xen@gmail.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [RFC] KEXEC: allocate crash note buffers at boot
	time v2
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/12/11 09:08, Jan Beulich wrote:
>>>> On 30.11.11 at 18:24, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>> -static DEFINE_PER_CPU_READ_MOSTLY(void *, crash_notes);
>> +static void * crash_notes[NR_CPUS];
> If at all possible, can you please allocate this dynamically using
> nr_cpu_ids for the size?

Ok

>> +static int kexec_init_cpu_notes(const int cpu)
> If the function's argument was made 'unsigned int' (as it already is in
> its caller), then ...
>
>> +    BUG_ON( cpu < 0 || cpu >= NR_CPUS );
> ... only the second check would be needed. Furthermore, it's
> pointless to use signed types for CPU numbers (and it's
> inefficient on various architectures), despite there being numerous
> (bad) examples throughout the tree.

Good point.  I will clean this up

>> +    if ( 0 == cpu )
>> +        nr_bytes = nr_bytes +
>> +            sizeof_note("Xen", sizeof(crash_xen_info_t));
> Minor nit: Why not use += here (presumably allowing the statement to
> fit on one line)?

Because the next few patches in my series adds a new crash notes at this
point.  I felt it was neater to leave in this form for a reduced diff
next patch, and gcc will optimize it to +=

>> +    if ( ! note )
>> +        /* Ideally, this would be -ENOMEM.  However, there are more problems
>> +         * assocated with trying to deal with -ENOMEM sensibly than just
>> +         * pretending that the crash note area doesn't exist. */
>> +        return 0;
> The only current caller ignores the return value, so why the bogus
> return value?

Originally it passed the return value back up to the cpu hotplug
notifier, but I decided that causing an -ENOMEM at this point was a
little silly given that:
1) a lack of mem on boot will quickly kill the host in other ways, and
2) while there is no way useful way to ensure that the crashdump kernel
gets reloaded with new notes pointers, blocking on not being able to
allocate notes is silly.

Would you consider this enough of a problem to actually fail the
CPU_PREPARE_UP ?

On further thought from my musings yesterday, it would be fantastic if
we were able to point the kdump kernel at a PT_NOTE header without
discerned length, at which point Xen can rewrite its crash notes without
having to get /sbin/kexec to repackage its magic elf blog pointing to
new/different memory locations.  However, as this would involve changes
to kexec-tools, Linux (and Xen) in a not trivially backward compatible
fashion, the chances of it happening are slim.

>> +    if ( nr < 0 || nr >= nr_cpu_ids || !cpu_online(nr) || !crash_notes[nr] )
>> ...
>> -    if ( per_cpu(crash_notes, nr) == NULL )
>> -    {
>> ...
>> -    }
> I would suggest to retry allocation here. Even if this isn't suitable for
> a 32-bit kdump kernel on large systems, there#s no reason to penalize
> fully 64-bit environment.

At this point, none of the allocation makes it suitable for a 32bit
system.  For that, I need to start investigating something akin to
xalloc_below(), which is probably going to be todays task.  If we have
previously failed to allocate the notes buffer (and are somehow still
running), what if anything makes it likely that we will successfully
allocate memory this time?

> And here it would also become meaningful that kexec_init_cpu_notes()
> actually returns a meaningful error upon failure.
> Also, I can't see the reason for the patch to move around
> do_crashdump_trigger() and crashdump_trigger_keyhandler.

This is probably collateral damage from having to reorder sizeof_note()
and setup_note() in preference to making a forward declaration of them. 
I will see about fixing.

> Jan
>

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com


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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 09:50:30 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 09:50:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW3HW-0001rg-4R; Thu, 01 Dec 2011 09:50:18 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1RW3HV-0001qv-21
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 09:50:17 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1322732976!5363385!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDM2NDY=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15594 invoked from network); 1 Dec 2011 09:49:37 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 09:49:37 -0000
X-IronPort-AV: E=Sophos;i="4.71,277,1320642000"; d="scan'208";a="19552280"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Dec 2011 04:49:35 -0500
Received: from [10.80.2.18] (10.80.2.18) by FTLPMAILMX01.citrite.net
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Thu, 1 Dec 2011
	04:49:35 -0500
Message-ID: <4ED74DAD.1040903@citrix.com>
Date: Thu, 1 Dec 2011 09:49:33 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.23) Gecko/20110921 Lightning/1.0b2 Thunderbird/3.1.15
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <CAFA7027.25E35%keir.xen@gmail.com> <4ED62C50.7060204@citrix.com>
	<4ED666D5.5060603@citrix.com>
	<4ED7522E0200007800064973@nat28.tlf.novell.com>
In-Reply-To: <4ED7522E0200007800064973@nat28.tlf.novell.com>
X-Enigmail-Version: 1.1.2
Cc: Keir Fraser <keir.xen@gmail.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [RFC] KEXEC: allocate crash note buffers at boot
	time v2
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/12/11 09:08, Jan Beulich wrote:
>>>> On 30.11.11 at 18:24, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>> -static DEFINE_PER_CPU_READ_MOSTLY(void *, crash_notes);
>> +static void * crash_notes[NR_CPUS];
> If at all possible, can you please allocate this dynamically using
> nr_cpu_ids for the size?

Ok

>> +static int kexec_init_cpu_notes(const int cpu)
> If the function's argument was made 'unsigned int' (as it already is in
> its caller), then ...
>
>> +    BUG_ON( cpu < 0 || cpu >= NR_CPUS );
> ... only the second check would be needed. Furthermore, it's
> pointless to use signed types for CPU numbers (and it's
> inefficient on various architectures), despite there being numerous
> (bad) examples throughout the tree.

Good point.  I will clean this up

>> +    if ( 0 == cpu )
>> +        nr_bytes = nr_bytes +
>> +            sizeof_note("Xen", sizeof(crash_xen_info_t));
> Minor nit: Why not use += here (presumably allowing the statement to
> fit on one line)?

Because the next few patches in my series adds a new crash notes at this
point.  I felt it was neater to leave in this form for a reduced diff
next patch, and gcc will optimize it to +=

>> +    if ( ! note )
>> +        /* Ideally, this would be -ENOMEM.  However, there are more problems
>> +         * assocated with trying to deal with -ENOMEM sensibly than just
>> +         * pretending that the crash note area doesn't exist. */
>> +        return 0;
> The only current caller ignores the return value, so why the bogus
> return value?

Originally it passed the return value back up to the cpu hotplug
notifier, but I decided that causing an -ENOMEM at this point was a
little silly given that:
1) a lack of mem on boot will quickly kill the host in other ways, and
2) while there is no way useful way to ensure that the crashdump kernel
gets reloaded with new notes pointers, blocking on not being able to
allocate notes is silly.

Would you consider this enough of a problem to actually fail the
CPU_PREPARE_UP ?

On further thought from my musings yesterday, it would be fantastic if
we were able to point the kdump kernel at a PT_NOTE header without
discerned length, at which point Xen can rewrite its crash notes without
having to get /sbin/kexec to repackage its magic elf blog pointing to
new/different memory locations.  However, as this would involve changes
to kexec-tools, Linux (and Xen) in a not trivially backward compatible
fashion, the chances of it happening are slim.

>> +    if ( nr < 0 || nr >= nr_cpu_ids || !cpu_online(nr) || !crash_notes[nr] )
>> ...
>> -    if ( per_cpu(crash_notes, nr) == NULL )
>> -    {
>> ...
>> -    }
> I would suggest to retry allocation here. Even if this isn't suitable for
> a 32-bit kdump kernel on large systems, there#s no reason to penalize
> fully 64-bit environment.

At this point, none of the allocation makes it suitable for a 32bit
system.  For that, I need to start investigating something akin to
xalloc_below(), which is probably going to be todays task.  If we have
previously failed to allocate the notes buffer (and are somehow still
running), what if anything makes it likely that we will successfully
allocate memory this time?

> And here it would also become meaningful that kexec_init_cpu_notes()
> actually returns a meaningful error upon failure.
> Also, I can't see the reason for the patch to move around
> do_crashdump_trigger() and crashdump_trigger_keyhandler.

This is probably collateral damage from having to reorder sizeof_note()
and setup_note() in preference to making a forward declaration of them. 
I will see about fixing.

> Jan
>

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com


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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 09:54:23 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 09:54:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW3LE-0002D8-Pv; Thu, 01 Dec 2011 09:54:08 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RW3LC-0002Ct-Vu
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 09:54:07 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1322733207!6364539!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU2Nw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15364 invoked from network); 1 Dec 2011 09:53:27 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 09:53:27 -0000
X-IronPort-AV: E=Sophos;i="4.71,277,1320624000"; 
   d="scan'208";a="9224045"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Dec 2011 09:53:26 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 1 Dec 2011
	09:53:26 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Niall Fleming <niall.fleming@webanywhere.co.uk>
Date: Thu, 1 Dec 2011 09:53:26 +0000
In-Reply-To: <4ED740FD.4070603@webanywhere.co.uk>
References: <4EBD5AA0.3090906@webanywhere.co.uk>
	<20111111183913.GA9283@phenom.dumpdata.com>
	<4EC0F20D0200007800060B7D@nat28.tlf.novell.com>
	<20111114180045.GA14517@phenom.dumpdata.com>	<4EC16CA7.70901@goop.org>
	<20111116142604.GA7476@phenom.dumpdata.com>
	<4ED662B0.8060105@webanywhere.co.uk>
	<20111130222628.GE16651@andromeda.dapyr.net>
	<4ED740FD.4070603@webanywhere.co.uk>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322733206.31810.173.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"keir.xen@gmail.com" <keir.xen@gmail.com>, Jan
	Beulich <JBeulich@suse.com>, "pbonzini@redhat.com" <pbonzini@redhat.com>,
	Konrad Rzeszutek Wilk <konrad@darnok.org>,
	"lersek@redhat.com" <lersek@redhat.com>
Subject: Re: [Xen-devel] Time Change Issue Xen 4.1
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2011-12-01 at 08:55 +0000, Niall Fleming wrote:
> Cheers, at least I know that someone is still looking at it!
> 
> If someone could give me a general timeframe, like it'll be a month,
> before we fix it, or two weeks or whatever, I just need to give my
> line manager something so he gets off my case about it!

I'm afraid OSS software doesn't generally work like that. If you (or
your boss) wants something fixed on a specific time scale or priority
you'll have to role your sleeves up and scratch the itch. Otherwise I'm
sorry but you will just have to wait until someone has the cycles to
look into this issue.

Ian.



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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 09:54:23 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 09:54:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW3LE-0002D8-Pv; Thu, 01 Dec 2011 09:54:08 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RW3LC-0002Ct-Vu
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 09:54:07 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1322733207!6364539!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU2Nw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15364 invoked from network); 1 Dec 2011 09:53:27 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 09:53:27 -0000
X-IronPort-AV: E=Sophos;i="4.71,277,1320624000"; 
   d="scan'208";a="9224045"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Dec 2011 09:53:26 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 1 Dec 2011
	09:53:26 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Niall Fleming <niall.fleming@webanywhere.co.uk>
Date: Thu, 1 Dec 2011 09:53:26 +0000
In-Reply-To: <4ED740FD.4070603@webanywhere.co.uk>
References: <4EBD5AA0.3090906@webanywhere.co.uk>
	<20111111183913.GA9283@phenom.dumpdata.com>
	<4EC0F20D0200007800060B7D@nat28.tlf.novell.com>
	<20111114180045.GA14517@phenom.dumpdata.com>	<4EC16CA7.70901@goop.org>
	<20111116142604.GA7476@phenom.dumpdata.com>
	<4ED662B0.8060105@webanywhere.co.uk>
	<20111130222628.GE16651@andromeda.dapyr.net>
	<4ED740FD.4070603@webanywhere.co.uk>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322733206.31810.173.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"keir.xen@gmail.com" <keir.xen@gmail.com>, Jan
	Beulich <JBeulich@suse.com>, "pbonzini@redhat.com" <pbonzini@redhat.com>,
	Konrad Rzeszutek Wilk <konrad@darnok.org>,
	"lersek@redhat.com" <lersek@redhat.com>
Subject: Re: [Xen-devel] Time Change Issue Xen 4.1
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2011-12-01 at 08:55 +0000, Niall Fleming wrote:
> Cheers, at least I know that someone is still looking at it!
> 
> If someone could give me a general timeframe, like it'll be a month,
> before we fix it, or two weeks or whatever, I just need to give my
> line manager something so he gets off my case about it!

I'm afraid OSS software doesn't generally work like that. If you (or
your boss) wants something fixed on a specific time scale or priority
you'll have to role your sleeves up and scratch the itch. Otherwise I'm
sorry but you will just have to wait until someone has the cycles to
look into this issue.

Ian.



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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 09:55:32 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 09:55:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW3MO-0002Ip-9D; Thu, 01 Dec 2011 09:55:20 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RW3MM-0002IG-2G
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 09:55:18 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1322733278!6525946!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQzODQ=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17385 invoked from network); 1 Dec 2011 09:54:38 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-14.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 1 Dec 2011 09:54:38 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 01 Dec 2011 09:54:37 +0000
Message-Id: <4ED75CED02000078000649C2@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 01 Dec 2011 09:54:37 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad@darnok.org>,
 "Tim Deegan" <tim@xen.org>
References: <4ED6676F02000078000646BC@nat28.tlf.novell.com>
	<20111130222359.GC16651@andromeda.dapyr.net>
	<20111201094847.GA59696@ocelot.phlegethon.org>
In-Reply-To: <20111201094847.GA59696@ocelot.phlegethon.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 2/2] x86/microcode: enable boot time
 (pre-Dom0) loading
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 01.12.11 at 10:48, Tim Deegan <tim@xen.org> wrote:
> It might be nice if that number could take negative values, though -
> i.e. ucode=-1 to say 'use the last module in the list'.  Then the user
> could adjust the dom0 modules without needing to recalculate.

That's certainly a nice enhancement; I'll put this on my to-to list.

Jan


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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 09:55:32 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 09:55:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW3MO-0002Ip-9D; Thu, 01 Dec 2011 09:55:20 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RW3MM-0002IG-2G
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 09:55:18 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1322733278!6525946!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQzODQ=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17385 invoked from network); 1 Dec 2011 09:54:38 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-14.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 1 Dec 2011 09:54:38 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 01 Dec 2011 09:54:37 +0000
Message-Id: <4ED75CED02000078000649C2@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 01 Dec 2011 09:54:37 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad@darnok.org>,
 "Tim Deegan" <tim@xen.org>
References: <4ED6676F02000078000646BC@nat28.tlf.novell.com>
	<20111130222359.GC16651@andromeda.dapyr.net>
	<20111201094847.GA59696@ocelot.phlegethon.org>
In-Reply-To: <20111201094847.GA59696@ocelot.phlegethon.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 2/2] x86/microcode: enable boot time
 (pre-Dom0) loading
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 01.12.11 at 10:48, Tim Deegan <tim@xen.org> wrote:
> It might be nice if that number could take negative values, though -
> i.e. ucode=-1 to say 'use the last module in the list'.  Then the user
> could adjust the dom0 modules without needing to recalculate.

That's certainly a nice enhancement; I'll put this on my to-to list.

Jan


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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 09:56:47 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 09:56:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW3Nd-0002QO-PH; Thu, 01 Dec 2011 09:56:37 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RW3Nc-0002Q2-BK
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 09:56:36 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1322733323!46149923!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU2Nw==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15655 invoked from network); 1 Dec 2011 09:55:23 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 09:55:23 -0000
X-IronPort-AV: E=Sophos;i="4.71,277,1320624000"; 
   d="scan'208";a="9224114"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Dec 2011 09:55:58 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 1 Dec 2011
	09:55:58 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Thu, 1 Dec 2011 09:55:58 +0000
In-Reply-To: <4ED7433A0200007800064903@nat28.tlf.novell.com>
References: <4ED6676F02000078000646BC@nat28.tlf.novell.com>
	<20111130222359.GC16651@andromeda.dapyr.net>
	<4ED7433A0200007800064903@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322733358.31810.174.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Borislav Petkov <borislav.petkov@amd.com>, "hpa@zytor.com" <hpa@zytor.com>
Subject: Re: [Xen-devel] [PATCH 2/2] x86/microcode: enable boot time
 (pre-Dom0) loading
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2011-12-01 at 08:04 +0000, Jan Beulich wrote:
> 
> > I got the impression they wanted some new .pack format or so?
> > Or is the format that they were talking about exactly what you
> picked?
> 
> I merely picked the binary formats that are already in use; I see no
> reason to invent another one. 

Adding a header/magic number so you can detect which of the blobs is
microcode?

Ian.



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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 09:56:47 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 09:56:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW3Nd-0002QO-PH; Thu, 01 Dec 2011 09:56:37 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RW3Nc-0002Q2-BK
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 09:56:36 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1322733323!46149923!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU2Nw==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15655 invoked from network); 1 Dec 2011 09:55:23 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 09:55:23 -0000
X-IronPort-AV: E=Sophos;i="4.71,277,1320624000"; 
   d="scan'208";a="9224114"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Dec 2011 09:55:58 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 1 Dec 2011
	09:55:58 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Thu, 1 Dec 2011 09:55:58 +0000
In-Reply-To: <4ED7433A0200007800064903@nat28.tlf.novell.com>
References: <4ED6676F02000078000646BC@nat28.tlf.novell.com>
	<20111130222359.GC16651@andromeda.dapyr.net>
	<4ED7433A0200007800064903@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322733358.31810.174.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Borislav Petkov <borislav.petkov@amd.com>, "hpa@zytor.com" <hpa@zytor.com>
Subject: Re: [Xen-devel] [PATCH 2/2] x86/microcode: enable boot time
 (pre-Dom0) loading
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2011-12-01 at 08:04 +0000, Jan Beulich wrote:
> 
> > I got the impression they wanted some new .pack format or so?
> > Or is the format that they were talking about exactly what you
> picked?
> 
> I merely picked the binary formats that are already in use; I see no
> reason to invent another one. 

Adding a header/magic number so you can detect which of the blobs is
microcode?

Ian.



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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 09:58:34 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 09: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.xensource.com>)
	id 1RW3PL-0002a3-9Q; Thu, 01 Dec 2011 09:58:23 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RW3PK-0002ZY-7D
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 09:58:22 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1322733462!6295498!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU2Nw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3981 invoked from network); 1 Dec 2011 09:57:42 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 09:57:42 -0000
X-IronPort-AV: E=Sophos;i="4.71,277,1320624000"; 
   d="scan'208";a="9224175"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Dec 2011 09:57:40 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 1 Dec 2011
	09:57:40 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: duolvxendev <duolvxendev@yahoo.cn>
Date: Thu, 1 Dec 2011 09:57:40 +0000
In-Reply-To: <1316571734360-4824822.post@n5.nabble.com>
References: <1316338995760-4815691.post@n5.nabble.com>
	<alpine.DEB.2.00.1109201908010.8700@kaball-desktop>
	<1316571734360-4824822.post@n5.nabble.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322733460.31810.175.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Permission for xenstore operation on HVM
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2011-09-21 at 03:22 +0100, duolvxendev wrote:
> I'm trying to create a directory and write some messages, i.e. to some path
> like /local/domain/$DOMID/my_directory/my_key. This is OK on pv domU, but
> denied on HVM.

There is no deliberate difference between PV and HVM and indeed:
# ./xen-detect 
Running in PV context on Xen v4.2.
# xenstore-write my_directory/my_key "foo"
xenstore-write: could not write path my_directory/my_key

even if I use dom0 tools to get the domid:
# xenstore-write /local/domain/413/my_directory/my_key "foo"
xenstore-write: could not write path /local/domain/413/my_directory/my_key

If you use one of the xs areas set aside for guest use then this works. e.g.
# xenstore-write data/foo "test"

>  I can write to /local/domain/device directory by frontend
> driver, but I cannot create or write to some arbitrary path that doesn't
> exist.

Correct, the locations which a guest can write to are deliberately
restricted as explained by Stefano.

Ian.

>  It looks like that one needs special permission on HVM.
> 
> --
> View this message in context: http://xen.1045712.n5.nabble.com/Permission-for-xenstore-operation-on-HVM-tp4815691p4824822.html
> Sent from the Xen - Dev mailing list archive at Nabble.com.
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 09:58:34 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 09: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.xensource.com>)
	id 1RW3PL-0002a3-9Q; Thu, 01 Dec 2011 09:58:23 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RW3PK-0002ZY-7D
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 09:58:22 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1322733462!6295498!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU2Nw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3981 invoked from network); 1 Dec 2011 09:57:42 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 09:57:42 -0000
X-IronPort-AV: E=Sophos;i="4.71,277,1320624000"; 
   d="scan'208";a="9224175"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Dec 2011 09:57:40 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 1 Dec 2011
	09:57:40 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: duolvxendev <duolvxendev@yahoo.cn>
Date: Thu, 1 Dec 2011 09:57:40 +0000
In-Reply-To: <1316571734360-4824822.post@n5.nabble.com>
References: <1316338995760-4815691.post@n5.nabble.com>
	<alpine.DEB.2.00.1109201908010.8700@kaball-desktop>
	<1316571734360-4824822.post@n5.nabble.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322733460.31810.175.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Permission for xenstore operation on HVM
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2011-09-21 at 03:22 +0100, duolvxendev wrote:
> I'm trying to create a directory and write some messages, i.e. to some path
> like /local/domain/$DOMID/my_directory/my_key. This is OK on pv domU, but
> denied on HVM.

There is no deliberate difference between PV and HVM and indeed:
# ./xen-detect 
Running in PV context on Xen v4.2.
# xenstore-write my_directory/my_key "foo"
xenstore-write: could not write path my_directory/my_key

even if I use dom0 tools to get the domid:
# xenstore-write /local/domain/413/my_directory/my_key "foo"
xenstore-write: could not write path /local/domain/413/my_directory/my_key

If you use one of the xs areas set aside for guest use then this works. e.g.
# xenstore-write data/foo "test"

>  I can write to /local/domain/device directory by frontend
> driver, but I cannot create or write to some arbitrary path that doesn't
> exist.

Correct, the locations which a guest can write to are deliberately
restricted as explained by Stefano.

Ian.

>  It looks like that one needs special permission on HVM.
> 
> --
> View this message in context: http://xen.1045712.n5.nabble.com/Permission-for-xenstore-operation-on-HVM-tp4815691p4824822.html
> Sent from the Xen - Dev mailing list archive at Nabble.com.
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 10:01:25 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 10:01:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW3Rv-0002sv-SS; Thu, 01 Dec 2011 10:01:03 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RW3Rt-0002sl-VA
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 10:01:02 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1322733622!3832373!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU2Nw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18142 invoked from network); 1 Dec 2011 10:00:22 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 10:00:22 -0000
X-IronPort-AV: E=Sophos;i="4.71,277,1320624000"; 
   d="scan'208";a="9224239"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Dec 2011 10:00:22 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 1 Dec 2011
	10:00:21 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Paul Durrant <Paul.Durrant@citrix.com>
Date: Thu, 1 Dec 2011 10:00:21 +0000
In-Reply-To: <291EDFCB1E9E224A99088639C4762022B5988E50EA@LONPMAILBOX01.citrite.net>
References: <94a17182f386c8bb414e.1322686717@cosworth.uk.xensource.com>
	<20111130221419.GA16651@andromeda.dapyr.net>
	<291EDFCB1E9E224A99088639C4762022B5988E50D4@LONPMAILBOX01.citrite.net>
	<1322729947.31810.151.camel@zakaz.uk.xensource.com>
	<291EDFCB1E9E224A99088639C4762022B5988E50EA@LONPMAILBOX01.citrite.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322733621.31810.176.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] Add code to track the address of the VM
 generation id buffer across a
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2011-12-01 at 09:47 +0000, Paul Durrant wrote:
> > -----Original Message-----
> > From: Ian Campbell
> > Sent: 01 December 2011 08:59
> > To: Paul Durrant
> > Cc: Konrad Rzeszutek Wilk; xen-devel@lists.xensource.com
> > Subject: Re: [Xen-devel] [PATCH] Add code to track the address of
> > the VM generation id buffer across a
> > 
> > On Thu, 2011-12-01 at 08:46 +0000, Paul Durrant wrote:
> > > Konrad,
> > >
> > >   Did you see my previous patch set? The introductory comment was:
> > 
> > 
> > I think that description belongs somewhere permanent, either in
> > docs/misc or as a comment in an appropriate header.
> > 
> 
> Good point. Perhaps I should stick the comment just above the device description in the dsdt?

That would do I guess.

I guess more important would be the user facing toolstack specific
semantics/documentation i.e. the manpage.

Ian.



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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 10:01:25 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 10:01:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW3Rv-0002sv-SS; Thu, 01 Dec 2011 10:01:03 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RW3Rt-0002sl-VA
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 10:01:02 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1322733622!3832373!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU2Nw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18142 invoked from network); 1 Dec 2011 10:00:22 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 10:00:22 -0000
X-IronPort-AV: E=Sophos;i="4.71,277,1320624000"; 
   d="scan'208";a="9224239"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Dec 2011 10:00:22 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 1 Dec 2011
	10:00:21 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Paul Durrant <Paul.Durrant@citrix.com>
Date: Thu, 1 Dec 2011 10:00:21 +0000
In-Reply-To: <291EDFCB1E9E224A99088639C4762022B5988E50EA@LONPMAILBOX01.citrite.net>
References: <94a17182f386c8bb414e.1322686717@cosworth.uk.xensource.com>
	<20111130221419.GA16651@andromeda.dapyr.net>
	<291EDFCB1E9E224A99088639C4762022B5988E50D4@LONPMAILBOX01.citrite.net>
	<1322729947.31810.151.camel@zakaz.uk.xensource.com>
	<291EDFCB1E9E224A99088639C4762022B5988E50EA@LONPMAILBOX01.citrite.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322733621.31810.176.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] Add code to track the address of the VM
 generation id buffer across a
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2011-12-01 at 09:47 +0000, Paul Durrant wrote:
> > -----Original Message-----
> > From: Ian Campbell
> > Sent: 01 December 2011 08:59
> > To: Paul Durrant
> > Cc: Konrad Rzeszutek Wilk; xen-devel@lists.xensource.com
> > Subject: Re: [Xen-devel] [PATCH] Add code to track the address of
> > the VM generation id buffer across a
> > 
> > On Thu, 2011-12-01 at 08:46 +0000, Paul Durrant wrote:
> > > Konrad,
> > >
> > >   Did you see my previous patch set? The introductory comment was:
> > 
> > 
> > I think that description belongs somewhere permanent, either in
> > docs/misc or as a comment in an appropriate header.
> > 
> 
> Good point. Perhaps I should stick the comment just above the device description in the dsdt?

That would do I guess.

I guess more important would be the user facing toolstack specific
semantics/documentation i.e. the manpage.

Ian.



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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 10:02:22 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 10:02:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW3Sx-0002yQ-BS; Thu, 01 Dec 2011 10:02:07 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RW3Sw-0002xp-33
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 10:02:06 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1322733686!6527044!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQzODQ=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10889 invoked from network); 1 Dec 2011 10:01:26 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-14.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 1 Dec 2011 10:01:26 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 01 Dec 2011 10:01:25 +0000
Message-Id: <4ED75E8402000078000649E6@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 01 Dec 2011 10:01:24 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>
References: <CAFA7027.25E35%keir.xen@gmail.com>
	<4ED62C50.7060204@citrix.com> <4ED666D5.5060603@citrix.com>
	<4ED7522E0200007800064973@nat28.tlf.novell.com>
	<4ED74DAD.1040903@citrix.com>
In-Reply-To: <4ED74DAD.1040903@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Keir Fraser <keir.xen@gmail.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [RFC] KEXEC: allocate crash note buffers at boot
	time v2
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 01.12.11 at 10:49, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
> On 01/12/11 09:08, Jan Beulich wrote:
>>>>> On 30.11.11 at 18:24, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>>> +    if ( ! note )
>>> +        /* Ideally, this would be -ENOMEM.  However, there are more problems
>>> +         * assocated with trying to deal with -ENOMEM sensibly than just
>>> +         * pretending that the crash note area doesn't exist. */
>>> +        return 0;
>> The only current caller ignores the return value, so why the bogus
>> return value?
> 
> Originally it passed the return value back up to the cpu hotplug
> notifier, but I decided that causing an -ENOMEM at this point was a
> little silly given that:
> 1) a lack of mem on boot will quickly kill the host in other ways, and
> 2) while there is no way useful way to ensure that the crashdump kernel
> gets reloaded with new notes pointers, blocking on not being able to
> allocate notes is silly.
> 
> Would you consider this enough of a problem to actually fail the
> CPU_PREPARE_UP ?

No, absolutely not. Ignoring the return value there is fine.

>>> +    if ( nr < 0 || nr >= nr_cpu_ids || !cpu_online(nr) || !crash_notes[nr] )
>>> ...
>>> -    if ( per_cpu(crash_notes, nr) == NULL )
>>> -    {
>>> ...
>>> -    }
>> I would suggest to retry allocation here. Even if this isn't suitable for
>> a 32-bit kdump kernel on large systems, there#s no reason to penalize
>> fully 64-bit environment.
> 
> At this point, none of the allocation makes it suitable for a 32bit
> system.  For that, I need to start investigating something akin to
> xalloc_below(), which is probably going to be todays task.  If we have
> previously failed to allocate the notes buffer (and are somehow still
> running), what if anything makes it likely that we will successfully
> allocate memory this time?

Because memory got freed meanwhile? I'm particularly having post-
boot onlining of CPUs in mind; of course, if allocation failed during
boot we have bigger problems than this one.

Jan


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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 10:02:22 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 10:02:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW3Sx-0002yQ-BS; Thu, 01 Dec 2011 10:02:07 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RW3Sw-0002xp-33
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 10:02:06 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1322733686!6527044!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQzODQ=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10889 invoked from network); 1 Dec 2011 10:01:26 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-14.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 1 Dec 2011 10:01:26 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 01 Dec 2011 10:01:25 +0000
Message-Id: <4ED75E8402000078000649E6@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 01 Dec 2011 10:01:24 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>
References: <CAFA7027.25E35%keir.xen@gmail.com>
	<4ED62C50.7060204@citrix.com> <4ED666D5.5060603@citrix.com>
	<4ED7522E0200007800064973@nat28.tlf.novell.com>
	<4ED74DAD.1040903@citrix.com>
In-Reply-To: <4ED74DAD.1040903@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Keir Fraser <keir.xen@gmail.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [RFC] KEXEC: allocate crash note buffers at boot
	time v2
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 01.12.11 at 10:49, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
> On 01/12/11 09:08, Jan Beulich wrote:
>>>>> On 30.11.11 at 18:24, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>>> +    if ( ! note )
>>> +        /* Ideally, this would be -ENOMEM.  However, there are more problems
>>> +         * assocated with trying to deal with -ENOMEM sensibly than just
>>> +         * pretending that the crash note area doesn't exist. */
>>> +        return 0;
>> The only current caller ignores the return value, so why the bogus
>> return value?
> 
> Originally it passed the return value back up to the cpu hotplug
> notifier, but I decided that causing an -ENOMEM at this point was a
> little silly given that:
> 1) a lack of mem on boot will quickly kill the host in other ways, and
> 2) while there is no way useful way to ensure that the crashdump kernel
> gets reloaded with new notes pointers, blocking on not being able to
> allocate notes is silly.
> 
> Would you consider this enough of a problem to actually fail the
> CPU_PREPARE_UP ?

No, absolutely not. Ignoring the return value there is fine.

>>> +    if ( nr < 0 || nr >= nr_cpu_ids || !cpu_online(nr) || !crash_notes[nr] )
>>> ...
>>> -    if ( per_cpu(crash_notes, nr) == NULL )
>>> -    {
>>> ...
>>> -    }
>> I would suggest to retry allocation here. Even if this isn't suitable for
>> a 32-bit kdump kernel on large systems, there#s no reason to penalize
>> fully 64-bit environment.
> 
> At this point, none of the allocation makes it suitable for a 32bit
> system.  For that, I need to start investigating something akin to
> xalloc_below(), which is probably going to be todays task.  If we have
> previously failed to allocate the notes buffer (and are somehow still
> running), what if anything makes it likely that we will successfully
> allocate memory this time?

Because memory got freed meanwhile? I'm particularly having post-
boot onlining of CPUs in mind; of course, if allocation failed during
boot we have bigger problems than this one.

Jan


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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 10:04:03 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 10:04:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW3UY-00037c-T1; Thu, 01 Dec 2011 10:03:46 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1RW3UX-000373-6B
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 10:03:45 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1322733784!5432229!1
X-Originating-IP: [134.134.136.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjQgPT4gMzIwNDI3\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23008 invoked from network); 1 Dec 2011 10:03:05 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-4.tower-182.messagelabs.com with SMTP;
	1 Dec 2011 10:03:05 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga102.jf.intel.com with ESMTP; 01 Dec 2011 02:03:04 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.67,352,1309762800"; d="scan'208";a="81679284"
Received: from pgsmsx601.gar.corp.intel.com ([10.221.43.69])
	by orsmga001.jf.intel.com with ESMTP; 01 Dec 2011 02:02:43 -0800
Received: from pgsmsx102.gar.corp.intel.com (10.221.44.80) by
	pgsmsx601.gar.corp.intel.com (10.221.43.69) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Thu, 1 Dec 2011 18:01:43 +0800
Received: from shsmsx601.ccr.corp.intel.com (10.239.4.112) by
	PGSMSX102.gar.corp.intel.com (10.221.44.80) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Thu, 1 Dec 2011 18:01:43 +0800
Received: from shsmsx502.ccr.corp.intel.com ([10.239.4.96]) by
	shsmsx601.ccr.corp.intel.com ([10.239.4.112]) with mapi; Thu, 1 Dec 2011
	18:01:42 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Thu, 1 Dec 2011 18:01:40 +0800
Thread-Topic: [PATCH 3/6] X86: Disable PCID/INVPCID for dom0
Thread-Index: AcytogY9JOWjbFW2Qhy2Xb/FBKvaNABAl/QQAFrsSyA=
Message-ID: <BC00F5384FCFC9499AF06F92E8B78A9E2870BB41EE@shsmsx502.ccr.corp.intel.com>
References: <BC00F5384FCFC9499AF06F92E8B78A9E2867CF9A7E@shsmsx502.ccr.corp.intel.com>
	<4ECFA6C302000078000634A1@nat28.tlf.novell.com>
	<BC00F5384FCFC9499AF06F92E8B78A9E286DAED1B8@shsmsx502.ccr.corp.intel.com>
	<4ED34AA2020000780006394D@nat28.tlf.novell.com>
	<BC00F5384FCFC9499AF06F92E8B78A9E28707E67E4@shsmsx502.ccr.corp.intel.com>
In-Reply-To: <BC00F5384FCFC9499AF06F92E8B78A9E28707E67E4@shsmsx502.ccr.corp.intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"keir@xen.org" <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH 3/6] X86: Disable PCID/INVPCID for dom0
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Liu, Jinsong wrote:
> Jan Beulich wrote:
>>>>> On 27.11.11 at 11:16, "Liu, Jinsong" <jinsong.liu@intel.com>
>>>>> wrote: 
>>> Jan Beulich wrote:
>>>>>>> On 24.11.11 at 16:53, "Liu, Jinsong" <jinsong.liu@intel.com>
>>>>>>> wrote:
>>>>> This patch disable PCID/INVPCID for dom0.
>>>> 
>>>> Do we really need to disable it, rather than making it work?
>>>> Conceptually the feature seems usable, and the instruction would
>>>> need replacement by a hypercall anyway (just like invlpg).
>>> 
>>> It's a design choice.
>>> Exposing PCID/INVPCID to pv would involve some additional task, like
>>> coordinated PCID allocation algorithm, or change vmm vcpu context
>>> swich, which would make it complex. However, exposing PCID/INVPCID
>>> to pv has not obvious benefit or even result in performance
>>> regression.
>> 
>> Would you mind elaborating on that statement?
>> 
>> Jan
> 
> For pv, if expose PCID to pv, the PCIDs of different pv domain may
> conflict, which make processor confused at TLB. 
> To make PCID work at pv, it need
> 1, either a coordinated PCID allocation algorithm, so that the local
> PCID of pv domain can be changed to a global unique PCID; 2, or, a
> 'clean' vcpu context switch logic to flush all TLB; 
> method 1 make things complex w/o obvious benefit;
> method 2 need change current vcpu context switch logic (i.e, mov cr3
> only flush TLB entries of specific PCID if PCID enabled), and if
> flush *all* TLB is required at context switch, we lose the change to
> optimize context switch by partly flush TLB case by case, which may
> result in performance regression;    
> 
> Thanks,
> Jinsong

Jan, any comments? Thanks, Jinsong

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 10:04:03 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 10:04:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW3UY-00037c-T1; Thu, 01 Dec 2011 10:03:46 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1RW3UX-000373-6B
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 10:03:45 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1322733784!5432229!1
X-Originating-IP: [134.134.136.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjQgPT4gMzIwNDI3\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23008 invoked from network); 1 Dec 2011 10:03:05 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-4.tower-182.messagelabs.com with SMTP;
	1 Dec 2011 10:03:05 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga102.jf.intel.com with ESMTP; 01 Dec 2011 02:03:04 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.67,352,1309762800"; d="scan'208";a="81679284"
Received: from pgsmsx601.gar.corp.intel.com ([10.221.43.69])
	by orsmga001.jf.intel.com with ESMTP; 01 Dec 2011 02:02:43 -0800
Received: from pgsmsx102.gar.corp.intel.com (10.221.44.80) by
	pgsmsx601.gar.corp.intel.com (10.221.43.69) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Thu, 1 Dec 2011 18:01:43 +0800
Received: from shsmsx601.ccr.corp.intel.com (10.239.4.112) by
	PGSMSX102.gar.corp.intel.com (10.221.44.80) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Thu, 1 Dec 2011 18:01:43 +0800
Received: from shsmsx502.ccr.corp.intel.com ([10.239.4.96]) by
	shsmsx601.ccr.corp.intel.com ([10.239.4.112]) with mapi; Thu, 1 Dec 2011
	18:01:42 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Thu, 1 Dec 2011 18:01:40 +0800
Thread-Topic: [PATCH 3/6] X86: Disable PCID/INVPCID for dom0
Thread-Index: AcytogY9JOWjbFW2Qhy2Xb/FBKvaNABAl/QQAFrsSyA=
Message-ID: <BC00F5384FCFC9499AF06F92E8B78A9E2870BB41EE@shsmsx502.ccr.corp.intel.com>
References: <BC00F5384FCFC9499AF06F92E8B78A9E2867CF9A7E@shsmsx502.ccr.corp.intel.com>
	<4ECFA6C302000078000634A1@nat28.tlf.novell.com>
	<BC00F5384FCFC9499AF06F92E8B78A9E286DAED1B8@shsmsx502.ccr.corp.intel.com>
	<4ED34AA2020000780006394D@nat28.tlf.novell.com>
	<BC00F5384FCFC9499AF06F92E8B78A9E28707E67E4@shsmsx502.ccr.corp.intel.com>
In-Reply-To: <BC00F5384FCFC9499AF06F92E8B78A9E28707E67E4@shsmsx502.ccr.corp.intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"keir@xen.org" <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH 3/6] X86: Disable PCID/INVPCID for dom0
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Liu, Jinsong wrote:
> Jan Beulich wrote:
>>>>> On 27.11.11 at 11:16, "Liu, Jinsong" <jinsong.liu@intel.com>
>>>>> wrote: 
>>> Jan Beulich wrote:
>>>>>>> On 24.11.11 at 16:53, "Liu, Jinsong" <jinsong.liu@intel.com>
>>>>>>> wrote:
>>>>> This patch disable PCID/INVPCID for dom0.
>>>> 
>>>> Do we really need to disable it, rather than making it work?
>>>> Conceptually the feature seems usable, and the instruction would
>>>> need replacement by a hypercall anyway (just like invlpg).
>>> 
>>> It's a design choice.
>>> Exposing PCID/INVPCID to pv would involve some additional task, like
>>> coordinated PCID allocation algorithm, or change vmm vcpu context
>>> swich, which would make it complex. However, exposing PCID/INVPCID
>>> to pv has not obvious benefit or even result in performance
>>> regression.
>> 
>> Would you mind elaborating on that statement?
>> 
>> Jan
> 
> For pv, if expose PCID to pv, the PCIDs of different pv domain may
> conflict, which make processor confused at TLB. 
> To make PCID work at pv, it need
> 1, either a coordinated PCID allocation algorithm, so that the local
> PCID of pv domain can be changed to a global unique PCID; 2, or, a
> 'clean' vcpu context switch logic to flush all TLB; 
> method 1 make things complex w/o obvious benefit;
> method 2 need change current vcpu context switch logic (i.e, mov cr3
> only flush TLB entries of specific PCID if PCID enabled), and if
> flush *all* TLB is required at context switch, we lose the change to
> optimize context switch by partly flush TLB case by case, which may
> result in performance regression;    
> 
> Thanks,
> Jinsong

Jan, any comments? Thanks, Jinsong

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 10:13:03 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 10: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.xensource.com>)
	id 1RW3dI-0003Sl-6H; Thu, 01 Dec 2011 10:12:48 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RW3dG-0003Sg-GJ
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 10:12:46 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1322734291!46153537!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQzODQ=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25128 invoked from network); 1 Dec 2011 10:11:31 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-10.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 1 Dec 2011 10:11:31 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 01 Dec 2011 10:12:06 +0000
Message-Id: <4ED761060200007800064A09@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 01 Dec 2011 10:12:06 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Jinsong Liu" <jinsong.liu@intel.com>
References: <BC00F5384FCFC9499AF06F92E8B78A9E2867CF9A7E@shsmsx502.ccr.corp.intel.com>
	<4ECFA6C302000078000634A1@nat28.tlf.novell.com>
	<BC00F5384FCFC9499AF06F92E8B78A9E286DAED1B8@shsmsx502.ccr.corp.intel.com>
	<4ED34AA2020000780006394D@nat28.tlf.novell.com>
	<BC00F5384FCFC9499AF06F92E8B78A9E28707E67E4@shsmsx502.ccr.corp.intel.com>
	<BC00F5384FCFC9499AF06F92E8B78A9E2870BB41EE@shsmsx502.ccr.corp.intel.com>
In-Reply-To: <BC00F5384FCFC9499AF06F92E8B78A9E2870BB41EE@shsmsx502.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"keir@xen.org" <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH 3/6] X86: Disable PCID/INVPCID for dom0
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 01.12.11 at 11:01, "Liu, Jinsong" <jinsong.liu@intel.com> wrote:
> Liu, Jinsong wrote:
>> Jan Beulich wrote:
>>>>>> On 27.11.11 at 11:16, "Liu, Jinsong" <jinsong.liu@intel.com>
>>>>>> wrote: 
>>>> Jan Beulich wrote:
>>>>>>>> On 24.11.11 at 16:53, "Liu, Jinsong" <jinsong.liu@intel.com>
>>>>>>>> wrote:
>>>>>> This patch disable PCID/INVPCID for dom0.
>>>>> 
>>>>> Do we really need to disable it, rather than making it work?
>>>>> Conceptually the feature seems usable, and the instruction would
>>>>> need replacement by a hypercall anyway (just like invlpg).
>>>> 
>>>> It's a design choice.
>>>> Exposing PCID/INVPCID to pv would involve some additional task, like
>>>> coordinated PCID allocation algorithm, or change vmm vcpu context
>>>> swich, which would make it complex. However, exposing PCID/INVPCID
>>>> to pv has not obvious benefit or even result in performance
>>>> regression.
>>> 
>>> Would you mind elaborating on that statement?
>>> 
>>> Jan
>> 
>> For pv, if expose PCID to pv, the PCIDs of different pv domain may
>> conflict, which make processor confused at TLB. 
>> To make PCID work at pv, it need
>> 1, either a coordinated PCID allocation algorithm, so that the local
>> PCID of pv domain can be changed to a global unique PCID; 2, or, a
>> 'clean' vcpu context switch logic to flush all TLB; 
>> method 1 make things complex w/o obvious benefit;
>> method 2 need change current vcpu context switch logic (i.e, mov cr3
>> only flush TLB entries of specific PCID if PCID enabled), and if
>> flush *all* TLB is required at context switch, we lose the change to
>> optimize context switch by partly flush TLB case by case, which may
>> result in performance regression;    
>> 
>> Thanks,
>> Jinsong
> 
> Jan, any comments? Thanks, Jinsong

No, no further comments (just don't have the time right now to think
through the possible alternatives). So for the moment I think things
could go in as posted by you. It's not immediately clear though
whether the series needs to be applied in order (it would seem that's
not a requirement, but I'd like your confirmation), as I could at most
take care of patches 2, 3, and 6.

Jan


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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 10:13:03 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 10: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.xensource.com>)
	id 1RW3dI-0003Sl-6H; Thu, 01 Dec 2011 10:12:48 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RW3dG-0003Sg-GJ
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 10:12:46 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1322734291!46153537!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQzODQ=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25128 invoked from network); 1 Dec 2011 10:11:31 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-10.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 1 Dec 2011 10:11:31 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 01 Dec 2011 10:12:06 +0000
Message-Id: <4ED761060200007800064A09@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 01 Dec 2011 10:12:06 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Jinsong Liu" <jinsong.liu@intel.com>
References: <BC00F5384FCFC9499AF06F92E8B78A9E2867CF9A7E@shsmsx502.ccr.corp.intel.com>
	<4ECFA6C302000078000634A1@nat28.tlf.novell.com>
	<BC00F5384FCFC9499AF06F92E8B78A9E286DAED1B8@shsmsx502.ccr.corp.intel.com>
	<4ED34AA2020000780006394D@nat28.tlf.novell.com>
	<BC00F5384FCFC9499AF06F92E8B78A9E28707E67E4@shsmsx502.ccr.corp.intel.com>
	<BC00F5384FCFC9499AF06F92E8B78A9E2870BB41EE@shsmsx502.ccr.corp.intel.com>
In-Reply-To: <BC00F5384FCFC9499AF06F92E8B78A9E2870BB41EE@shsmsx502.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"keir@xen.org" <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH 3/6] X86: Disable PCID/INVPCID for dom0
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 01.12.11 at 11:01, "Liu, Jinsong" <jinsong.liu@intel.com> wrote:
> Liu, Jinsong wrote:
>> Jan Beulich wrote:
>>>>>> On 27.11.11 at 11:16, "Liu, Jinsong" <jinsong.liu@intel.com>
>>>>>> wrote: 
>>>> Jan Beulich wrote:
>>>>>>>> On 24.11.11 at 16:53, "Liu, Jinsong" <jinsong.liu@intel.com>
>>>>>>>> wrote:
>>>>>> This patch disable PCID/INVPCID for dom0.
>>>>> 
>>>>> Do we really need to disable it, rather than making it work?
>>>>> Conceptually the feature seems usable, and the instruction would
>>>>> need replacement by a hypercall anyway (just like invlpg).
>>>> 
>>>> It's a design choice.
>>>> Exposing PCID/INVPCID to pv would involve some additional task, like
>>>> coordinated PCID allocation algorithm, or change vmm vcpu context
>>>> swich, which would make it complex. However, exposing PCID/INVPCID
>>>> to pv has not obvious benefit or even result in performance
>>>> regression.
>>> 
>>> Would you mind elaborating on that statement?
>>> 
>>> Jan
>> 
>> For pv, if expose PCID to pv, the PCIDs of different pv domain may
>> conflict, which make processor confused at TLB. 
>> To make PCID work at pv, it need
>> 1, either a coordinated PCID allocation algorithm, so that the local
>> PCID of pv domain can be changed to a global unique PCID; 2, or, a
>> 'clean' vcpu context switch logic to flush all TLB; 
>> method 1 make things complex w/o obvious benefit;
>> method 2 need change current vcpu context switch logic (i.e, mov cr3
>> only flush TLB entries of specific PCID if PCID enabled), and if
>> flush *all* TLB is required at context switch, we lose the change to
>> optimize context switch by partly flush TLB case by case, which may
>> result in performance regression;    
>> 
>> Thanks,
>> Jinsong
> 
> Jan, any comments? Thanks, Jinsong

No, no further comments (just don't have the time right now to think
through the possible alternatives). So for the moment I think things
could go in as posted by you. It's not immediately clear though
whether the series needs to be applied in order (it would seem that's
not a requirement, but I'd like your confirmation), as I could at most
take care of patches 2, 3, and 6.

Jan


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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 10:17:59 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 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.xensource.com>)
	id 1RW3i7-0003cV-2P; Thu, 01 Dec 2011 10:17:47 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <sandr8@gmail.com>) id 1RW3i4-0003cE-La
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 10:17:44 +0000
X-Env-Sender: sandr8@gmail.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1322734622!5710728!1
X-Originating-IP: [209.85.213.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9930 invoked from network); 1 Dec 2011 10:17:03 -0000
Received: from mail-yw0-f43.google.com (HELO mail-yw0-f43.google.com)
	(209.85.213.43)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 10:17:03 -0000
Received: by ywt34 with SMTP id 34so10755066ywt.30
	for <xen-devel@lists.xensource.com>;
	Thu, 01 Dec 2011 02:17:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:reply-to:in-reply-to:references:from:date:message-id
	:subject:to:cc:content-type;
	bh=hEG29/pasyrGcVuFkNRO49yabK6ickrPbk2TFonxGUE=;
	b=PMH+peSqQ9fTxuUMw4II+PbrZ3GD4tu6NIuqPXsdd/VZC1qCev0FTeRE9A0f2Kwc16
	umgyMRpZWHhO/zVivvz+j+tOaIPAnU9z4DIJqofi9cj2p62ogbH6dCZ1PThvj/pi/fFp
	VwuqQZDXMpq4k1Rvyec7faNb3u/W/+pMYwbds=
Received: by 10.236.91.84 with SMTP id g60mr1682669yhf.90.1322734621303; Thu,
	01 Dec 2011 02:17:01 -0800 (PST)
MIME-Version: 1.0
Received: by 10.236.60.132 with HTTP; Thu, 1 Dec 2011 02:16:30 -0800 (PST)
In-Reply-To: <CACaajQs+WP3XnHLSbLk_-3LpsmRvWeJGY9Ws=-fRTgPyaNzwVw@mail.gmail.com>
References: <1316338995760-4815691.post@n5.nabble.com>
	<alpine.DEB.2.00.1109201908010.8700@kaball-desktop>
	<1316571734360-4824822.post@n5.nabble.com>
	<CACaajQs+WP3XnHLSbLk_-3LpsmRvWeJGY9Ws=-fRTgPyaNzwVw@mail.gmail.com>
From: Alessandro Salvatori <sandr8@gmail.com>
Date: Thu, 1 Dec 2011 02:16:30 -0800
Message-ID: <CAJeBh4sWv-4ZHaYWBQSKb91hzsXno4XM+4eQ8ZVVoX3zjU8B=A@mail.gmail.com>
To: Vasiliy Tolstov <v.tolstov@selfip.ru>
Cc: xen-devel@lists.xensource.com, duolvxendev <duolvxendev@yahoo.cn>
Subject: Re: [Xen-devel] Permission for xenstore operation on HVM
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: sandr8@gmail.com
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Dec 1, 2011 at 01:45, Vasiliy Tolstov <v.tolstov@selfip.ru> wrote:
> In HVM mode You allow write to /local/domain/$DOMID/data

do you mean that in PV mode one can write to vm-data, and in HVM mode
one can write to data?

in fact in my first message that never went through I had two
theories, and I chopped the first one because I was thinking it
sounded too ridiculous of me to say :)

> theory 1: for HVM guests Xen gives the ownership of the xenstore variables
> to dom0 instead of the domU that is running the guest. My humble guess is
> that Xen assumes that HVM guests are gonna be hypervisor agnostic and
> not gonna be using xenstore. Of course this assumption breaks when you
> have PV-HVM guests.

of course, if that is the case, then at provisioning time one wouldn't
know an HVM guest is gonna actually become a PV-HVM... so it will
still be treated as an HVM guest... sigh...

now, I wonder: can one get the data directory through XAPI though?

thanks!
-Alessandro-

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 10:17:59 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 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.xensource.com>)
	id 1RW3i7-0003cV-2P; Thu, 01 Dec 2011 10:17:47 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <sandr8@gmail.com>) id 1RW3i4-0003cE-La
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 10:17:44 +0000
X-Env-Sender: sandr8@gmail.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1322734622!5710728!1
X-Originating-IP: [209.85.213.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9930 invoked from network); 1 Dec 2011 10:17:03 -0000
Received: from mail-yw0-f43.google.com (HELO mail-yw0-f43.google.com)
	(209.85.213.43)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 10:17:03 -0000
Received: by ywt34 with SMTP id 34so10755066ywt.30
	for <xen-devel@lists.xensource.com>;
	Thu, 01 Dec 2011 02:17:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:reply-to:in-reply-to:references:from:date:message-id
	:subject:to:cc:content-type;
	bh=hEG29/pasyrGcVuFkNRO49yabK6ickrPbk2TFonxGUE=;
	b=PMH+peSqQ9fTxuUMw4II+PbrZ3GD4tu6NIuqPXsdd/VZC1qCev0FTeRE9A0f2Kwc16
	umgyMRpZWHhO/zVivvz+j+tOaIPAnU9z4DIJqofi9cj2p62ogbH6dCZ1PThvj/pi/fFp
	VwuqQZDXMpq4k1Rvyec7faNb3u/W/+pMYwbds=
Received: by 10.236.91.84 with SMTP id g60mr1682669yhf.90.1322734621303; Thu,
	01 Dec 2011 02:17:01 -0800 (PST)
MIME-Version: 1.0
Received: by 10.236.60.132 with HTTP; Thu, 1 Dec 2011 02:16:30 -0800 (PST)
In-Reply-To: <CACaajQs+WP3XnHLSbLk_-3LpsmRvWeJGY9Ws=-fRTgPyaNzwVw@mail.gmail.com>
References: <1316338995760-4815691.post@n5.nabble.com>
	<alpine.DEB.2.00.1109201908010.8700@kaball-desktop>
	<1316571734360-4824822.post@n5.nabble.com>
	<CACaajQs+WP3XnHLSbLk_-3LpsmRvWeJGY9Ws=-fRTgPyaNzwVw@mail.gmail.com>
From: Alessandro Salvatori <sandr8@gmail.com>
Date: Thu, 1 Dec 2011 02:16:30 -0800
Message-ID: <CAJeBh4sWv-4ZHaYWBQSKb91hzsXno4XM+4eQ8ZVVoX3zjU8B=A@mail.gmail.com>
To: Vasiliy Tolstov <v.tolstov@selfip.ru>
Cc: xen-devel@lists.xensource.com, duolvxendev <duolvxendev@yahoo.cn>
Subject: Re: [Xen-devel] Permission for xenstore operation on HVM
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: sandr8@gmail.com
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Dec 1, 2011 at 01:45, Vasiliy Tolstov <v.tolstov@selfip.ru> wrote:
> In HVM mode You allow write to /local/domain/$DOMID/data

do you mean that in PV mode one can write to vm-data, and in HVM mode
one can write to data?

in fact in my first message that never went through I had two
theories, and I chopped the first one because I was thinking it
sounded too ridiculous of me to say :)

> theory 1: for HVM guests Xen gives the ownership of the xenstore variables
> to dom0 instead of the domU that is running the guest. My humble guess is
> that Xen assumes that HVM guests are gonna be hypervisor agnostic and
> not gonna be using xenstore. Of course this assumption breaks when you
> have PV-HVM guests.

of course, if that is the case, then at provisioning time one wouldn't
know an HVM guest is gonna actually become a PV-HVM... so it will
still be treated as an HVM guest... sigh...

now, I wonder: can one get the data directory through XAPI though?

thanks!
-Alessandro-

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 10:23:10 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 10:23:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW3n6-0003mK-V5; Thu, 01 Dec 2011 10:22:56 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RW3n5-0003mB-AK
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 10:22:55 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1322734910!50702441!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQzODQ=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8691 invoked from network); 1 Dec 2011 10:21:50 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-4.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 1 Dec 2011 10:21:50 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 01 Dec 2011 10:02:12 +0000
Message-Id: <4ED75EB202000078000649E9@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 01 Dec 2011 10:02:10 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
References: <4ED6676F02000078000646BC@nat28.tlf.novell.com>
	<20111130222359.GC16651@andromeda.dapyr.net>
	<4ED7433A0200007800064903@nat28.tlf.novell.com>
	<1322733358.31810.174.camel@zakaz.uk.xensource.com>
In-Reply-To: <1322733358.31810.174.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Borislav Petkov <borislav.petkov@amd.com>, "hpa@zytor.com" <hpa@zytor.com>
Subject: Re: [Xen-devel] [PATCH 2/2] x86/microcode: enable boot time
 (pre-Dom0) loading
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 01.12.11 at 10:55, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Thu, 2011-12-01 at 08:04 +0000, Jan Beulich wrote:
>> 
>> > I got the impression they wanted some new .pack format or so?
>> > Or is the format that they were talking about exactly what you
>> picked?
>> 
>> I merely picked the binary formats that are already in use; I see no
>> reason to invent another one. 
> 
> Adding a header/magic number so you can detect which of the blobs is
> microcode?

This is precisely what I did *not* want to do.

Jan


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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 10:23:10 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 10:23:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW3n6-0003mK-V5; Thu, 01 Dec 2011 10:22:56 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RW3n5-0003mB-AK
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 10:22:55 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1322734910!50702441!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQzODQ=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8691 invoked from network); 1 Dec 2011 10:21:50 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-4.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 1 Dec 2011 10:21:50 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 01 Dec 2011 10:02:12 +0000
Message-Id: <4ED75EB202000078000649E9@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 01 Dec 2011 10:02:10 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
References: <4ED6676F02000078000646BC@nat28.tlf.novell.com>
	<20111130222359.GC16651@andromeda.dapyr.net>
	<4ED7433A0200007800064903@nat28.tlf.novell.com>
	<1322733358.31810.174.camel@zakaz.uk.xensource.com>
In-Reply-To: <1322733358.31810.174.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Borislav Petkov <borislav.petkov@amd.com>, "hpa@zytor.com" <hpa@zytor.com>
Subject: Re: [Xen-devel] [PATCH 2/2] x86/microcode: enable boot time
 (pre-Dom0) loading
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 01.12.11 at 10:55, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Thu, 2011-12-01 at 08:04 +0000, Jan Beulich wrote:
>> 
>> > I got the impression they wanted some new .pack format or so?
>> > Or is the format that they were talking about exactly what you
>> picked?
>> 
>> I merely picked the binary formats that are already in use; I see no
>> reason to invent another one. 
> 
> Adding a header/magic number so you can detect which of the blobs is
> microcode?

This is precisely what I did *not* want to do.

Jan


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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 10:25:06 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 10:25:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW3p2-0003sM-GH; Thu, 01 Dec 2011 10:24:56 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RW3p1-0003sD-8s
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 10:24:55 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1322735055!5760818!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU2Nw==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26178 invoked from network); 1 Dec 2011 10:24:15 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 10:24:15 -0000
X-IronPort-AV: E=Sophos;i="4.71,277,1320624000"; 
   d="scan'208";a="9224930"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Dec 2011 10:24:15 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 1 Dec 2011
	10:24:15 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "sandr8@gmail.com" <sandr8@gmail.com>
Date: Thu, 1 Dec 2011 10:24:15 +0000
In-Reply-To: <CAJeBh4sWv-4ZHaYWBQSKb91hzsXno4XM+4eQ8ZVVoX3zjU8B=A@mail.gmail.com>
References: <1316338995760-4815691.post@n5.nabble.com>
	<alpine.DEB.2.00.1109201908010.8700@kaball-desktop>
	<1316571734360-4824822.post@n5.nabble.com>
	<CACaajQs+WP3XnHLSbLk_-3LpsmRvWeJGY9Ws=-fRTgPyaNzwVw@mail.gmail.com>
	<CAJeBh4sWv-4ZHaYWBQSKb91hzsXno4XM+4eQ8ZVVoX3zjU8B=A@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322735055.31810.189.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	duolvxendev <duolvxendev@yahoo.cn>, Vasiliy Tolstov <v.tolstov@selfip.ru>
Subject: Re: [Xen-devel] Permission for xenstore operation on HVM
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2011-12-01 at 10:16 +0000, Alessandro Salvatori wrote:
> On Thu, Dec 1, 2011 at 01:45, Vasiliy Tolstov <v.tolstov@selfip.ru> wrote:
> > In HVM mode You allow write to /local/domain/$DOMID/data
> 
> do you mean that in PV mode one can write to vm-data, and in HVM mode
> one can write to data?

With the xl toolstack it is "data" in both cases. I can't speak for
other toolstacks but it would be nice if they were all consistent...

> in fact in my first message that never went through I had two
> theories, and I chopped the first one because I was thinking it
> sounded too ridiculous of me to say :)
> 
> > theory 1: for HVM guests Xen gives the ownership of the xenstore variables
> > to dom0 instead of the domU that is running the guest. My humble guess is
> > that Xen assumes that HVM guests are gonna be hypervisor agnostic and
> > not gonna be using xenstore. Of course this assumption breaks when you
> > have PV-HVM guests.
> 
> of course, if that is the case, then at provisioning time one wouldn't
> know an HVM guest is gonna actually become a PV-HVM... so it will
> still be treated as an HVM guest... sigh...
> 
> now, I wonder: can one get the data directory through XAPI though?

If you are running xapi then xen-api@lists.xensource.com is the correct
place to ask for help.

Ian.

> 
> thanks!
> -Alessandro-
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 10:25:06 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 10:25:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW3p2-0003sM-GH; Thu, 01 Dec 2011 10:24:56 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RW3p1-0003sD-8s
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 10:24:55 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1322735055!5760818!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU2Nw==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26178 invoked from network); 1 Dec 2011 10:24:15 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 10:24:15 -0000
X-IronPort-AV: E=Sophos;i="4.71,277,1320624000"; 
   d="scan'208";a="9224930"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Dec 2011 10:24:15 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 1 Dec 2011
	10:24:15 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "sandr8@gmail.com" <sandr8@gmail.com>
Date: Thu, 1 Dec 2011 10:24:15 +0000
In-Reply-To: <CAJeBh4sWv-4ZHaYWBQSKb91hzsXno4XM+4eQ8ZVVoX3zjU8B=A@mail.gmail.com>
References: <1316338995760-4815691.post@n5.nabble.com>
	<alpine.DEB.2.00.1109201908010.8700@kaball-desktop>
	<1316571734360-4824822.post@n5.nabble.com>
	<CACaajQs+WP3XnHLSbLk_-3LpsmRvWeJGY9Ws=-fRTgPyaNzwVw@mail.gmail.com>
	<CAJeBh4sWv-4ZHaYWBQSKb91hzsXno4XM+4eQ8ZVVoX3zjU8B=A@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322735055.31810.189.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	duolvxendev <duolvxendev@yahoo.cn>, Vasiliy Tolstov <v.tolstov@selfip.ru>
Subject: Re: [Xen-devel] Permission for xenstore operation on HVM
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2011-12-01 at 10:16 +0000, Alessandro Salvatori wrote:
> On Thu, Dec 1, 2011 at 01:45, Vasiliy Tolstov <v.tolstov@selfip.ru> wrote:
> > In HVM mode You allow write to /local/domain/$DOMID/data
> 
> do you mean that in PV mode one can write to vm-data, and in HVM mode
> one can write to data?

With the xl toolstack it is "data" in both cases. I can't speak for
other toolstacks but it would be nice if they were all consistent...

> in fact in my first message that never went through I had two
> theories, and I chopped the first one because I was thinking it
> sounded too ridiculous of me to say :)
> 
> > theory 1: for HVM guests Xen gives the ownership of the xenstore variables
> > to dom0 instead of the domU that is running the guest. My humble guess is
> > that Xen assumes that HVM guests are gonna be hypervisor agnostic and
> > not gonna be using xenstore. Of course this assumption breaks when you
> > have PV-HVM guests.
> 
> of course, if that is the case, then at provisioning time one wouldn't
> know an HVM guest is gonna actually become a PV-HVM... so it will
> still be treated as an HVM guest... sigh...
> 
> now, I wonder: can one get the data directory through XAPI though?

If you are running xapi then xen-api@lists.xensource.com is the correct
place to ask for help.

Ian.

> 
> thanks!
> -Alessandro-
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 10:27:44 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 10:27:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW3rN-00040u-2u; Thu, 01 Dec 2011 10:27:21 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RW3rL-00040W-9V
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 10:27:19 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1322735198!5435890!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU2Nw==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23628 invoked from network); 1 Dec 2011 10:26:38 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 10:26:38 -0000
X-IronPort-AV: E=Sophos;i="4.71,277,1320624000"; 
   d="scan'208";a="9225016"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Dec 2011 10:26:38 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 1 Dec 2011
	10:26:37 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Date: Thu, 1 Dec 2011 10:26:37 +0000
In-Reply-To: <alpine.DEB.2.00.1111301820290.31179@kaball-desktop>
References: <alpine.DEB.2.00.1111281009090.31179@kaball-desktop>
	<201111301432.54463.arnd@arndb.de>
	<1322670473.31810.129.camel@zakaz.uk.xensource.com>
	<201111301815.01297.arnd@arndb.de>
	<alpine.DEB.2.00.1111301820290.31179@kaball-desktop>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322735197.31810.191.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linaro-dev@lists.linaro.org" <linaro-dev@lists.linaro.org>,
	Arnd Bergmann <arnd@arndb.de>, Pawel Moll <pawel.moll@arm.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"virtualization@lists.linux-foundation.org"
	<virtualization@lists.linux-foundation.org>,
	"android-virt@lists.cs.columbia.edu" <android-virt@lists.cs.columbia.edu>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	"embeddedxen-devel@lists.sourceforge.net"
	<embeddedxen-devel@lists.sourceforge.net>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [Embeddedxen-devel] [ANNOUNCE] Xen port to
 Cortex-A15 / ARMv7 with virt extensions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2011-11-30 at 18:32 +0000, Stefano Stabellini wrote:
> On Wed, 30 Nov 2011, Arnd Bergmann wrote:

> 
> > KVM and Xen at least both fall into the single-return-value category,
> > so we should be able to agree on a calling conventions. KVM does not
> > have an hcall API on ARM yet, and I see no reason not to use the
> > same implementation that you have in the Xen guest.
> > 
> > Stefano, can you split out the generic parts of your asm/xen/hypercall.h
> > file into a common asm/hypercall.h and submit it for review to the
> > arm kernel list?
> 
> Sure, I can do that.
> Usually the hypercall calling convention is very hypervisor specific,
> but if it turns out that we have the same requirements I happy to design
> a common interface.

I expect the only real decision to be made is hypercall page vs. raw hvc
instruction.

The page was useful on x86 where there is a variety of instructions
which could be used (at least for PV there was systenter/syscall/int, I
think vmcall instruction differs between AMD and Intel also) and gives
some additional flexibility. It's hard to predict but I don't think I'd
expect that to be necessary on ARM.

Another reason for having a hypercall page instead of a raw instruction
might be wanting to support 32 bit guests (from ~today) on a 64 bit
hypervisor in the future and perhaps needing to do some shimming/arg
translation. It would be better to aim for having the interface just be
32/64 agnostic but mistakes do happen.

Ian.


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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 10:27:44 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 10:27:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW3rN-00040u-2u; Thu, 01 Dec 2011 10:27:21 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RW3rL-00040W-9V
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 10:27:19 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1322735198!5435890!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU2Nw==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23628 invoked from network); 1 Dec 2011 10:26:38 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 10:26:38 -0000
X-IronPort-AV: E=Sophos;i="4.71,277,1320624000"; 
   d="scan'208";a="9225016"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Dec 2011 10:26:38 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 1 Dec 2011
	10:26:37 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Date: Thu, 1 Dec 2011 10:26:37 +0000
In-Reply-To: <alpine.DEB.2.00.1111301820290.31179@kaball-desktop>
References: <alpine.DEB.2.00.1111281009090.31179@kaball-desktop>
	<201111301432.54463.arnd@arndb.de>
	<1322670473.31810.129.camel@zakaz.uk.xensource.com>
	<201111301815.01297.arnd@arndb.de>
	<alpine.DEB.2.00.1111301820290.31179@kaball-desktop>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322735197.31810.191.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linaro-dev@lists.linaro.org" <linaro-dev@lists.linaro.org>,
	Arnd Bergmann <arnd@arndb.de>, Pawel Moll <pawel.moll@arm.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"virtualization@lists.linux-foundation.org"
	<virtualization@lists.linux-foundation.org>,
	"android-virt@lists.cs.columbia.edu" <android-virt@lists.cs.columbia.edu>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	"embeddedxen-devel@lists.sourceforge.net"
	<embeddedxen-devel@lists.sourceforge.net>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [Embeddedxen-devel] [ANNOUNCE] Xen port to
 Cortex-A15 / ARMv7 with virt extensions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2011-11-30 at 18:32 +0000, Stefano Stabellini wrote:
> On Wed, 30 Nov 2011, Arnd Bergmann wrote:

> 
> > KVM and Xen at least both fall into the single-return-value category,
> > so we should be able to agree on a calling conventions. KVM does not
> > have an hcall API on ARM yet, and I see no reason not to use the
> > same implementation that you have in the Xen guest.
> > 
> > Stefano, can you split out the generic parts of your asm/xen/hypercall.h
> > file into a common asm/hypercall.h and submit it for review to the
> > arm kernel list?
> 
> Sure, I can do that.
> Usually the hypercall calling convention is very hypervisor specific,
> but if it turns out that we have the same requirements I happy to design
> a common interface.

I expect the only real decision to be made is hypercall page vs. raw hvc
instruction.

The page was useful on x86 where there is a variety of instructions
which could be used (at least for PV there was systenter/syscall/int, I
think vmcall instruction differs between AMD and Intel also) and gives
some additional flexibility. It's hard to predict but I don't think I'd
expect that to be necessary on ARM.

Another reason for having a hypercall page instead of a raw instruction
might be wanting to support 32 bit guests (from ~today) on a 64 bit
hypervisor in the future and perhaps needing to do some shimming/arg
translation. It would be better to aim for having the interface just be
32/64 agnostic but mistakes do happen.

Ian.


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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 10:27:55 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 10:27:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW3rd-00042M-Gn; Thu, 01 Dec 2011 10:27:37 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RW3rc-00041k-8L
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 10:27:36 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1322735185!54975250!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQzODQ=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2752 invoked from network); 1 Dec 2011 10:26:26 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-9.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 1 Dec 2011 10:26:26 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 01 Dec 2011 10:26:56 +0000
Message-Id: <4ED7647D0200007800064A32@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 01 Dec 2011 10:26:53 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartDAF54E7D.0__="
Subject: [Xen-devel] [PATCH] x86-64/mmcfg: remove __initdata annotation
 overlooked in 23749:e8d1c8f074ba
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

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

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

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

--- a/xen/arch/x86/x86_64/mmconfig_64.c
+++ b/xen/arch/x86/x86_64/mmconfig_64.c
@@ -23,7 +23,7 @@ struct mmcfg_virt {
     char __iomem *virt;
 };
 static struct mmcfg_virt *pci_mmcfg_virt;
-static int __initdata mmcfg_pci_segment_shift;
+static unsigned int mmcfg_pci_segment_shift;
=20
 static char __iomem *get_virt(unsigned int seg, unsigned int *bus)
 {




--=__PartDAF54E7D.0__=
Content-Type: text/plain; name="x86_64-mmcfg-fix-23749.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86_64-mmcfg-fix-23749.patch"

x86-64/mmcfg: remove __initdata annotation overlooked in 23749:e8d1c8f074ba=
=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=0A=0A--- a/xen/arch/x8=
6/x86_64/mmconfig_64.c=0A+++ b/xen/arch/x86/x86_64/mmconfig_64.c=0A@@ =
-23,7 +23,7 @@ struct mmcfg_virt {=0A     char __iomem *virt;=0A };=0A =
static struct mmcfg_virt *pci_mmcfg_virt;=0A-static int __initdata =
mmcfg_pci_segment_shift;=0A+static unsigned int mmcfg_pci_segment_shift;=0A=
 =0A static char __iomem *get_virt(unsigned int seg, unsigned int *bus)=0A =
{=0A
--=__PartDAF54E7D.0__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--=__PartDAF54E7D.0__=--


From xen-devel-bounces@lists.xensource.com Thu Dec 01 10:27:55 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 10:27:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW3rd-00042M-Gn; Thu, 01 Dec 2011 10:27:37 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RW3rc-00041k-8L
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 10:27:36 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1322735185!54975250!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQzODQ=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2752 invoked from network); 1 Dec 2011 10:26:26 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-9.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 1 Dec 2011 10:26:26 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 01 Dec 2011 10:26:56 +0000
Message-Id: <4ED7647D0200007800064A32@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 01 Dec 2011 10:26:53 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartDAF54E7D.0__="
Subject: [Xen-devel] [PATCH] x86-64/mmcfg: remove __initdata annotation
 overlooked in 23749:e8d1c8f074ba
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

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

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

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

--- a/xen/arch/x86/x86_64/mmconfig_64.c
+++ b/xen/arch/x86/x86_64/mmconfig_64.c
@@ -23,7 +23,7 @@ struct mmcfg_virt {
     char __iomem *virt;
 };
 static struct mmcfg_virt *pci_mmcfg_virt;
-static int __initdata mmcfg_pci_segment_shift;
+static unsigned int mmcfg_pci_segment_shift;
=20
 static char __iomem *get_virt(unsigned int seg, unsigned int *bus)
 {




--=__PartDAF54E7D.0__=
Content-Type: text/plain; name="x86_64-mmcfg-fix-23749.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86_64-mmcfg-fix-23749.patch"

x86-64/mmcfg: remove __initdata annotation overlooked in 23749:e8d1c8f074ba=
=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=0A=0A--- a/xen/arch/x8=
6/x86_64/mmconfig_64.c=0A+++ b/xen/arch/x86/x86_64/mmconfig_64.c=0A@@ =
-23,7 +23,7 @@ struct mmcfg_virt {=0A     char __iomem *virt;=0A };=0A =
static struct mmcfg_virt *pci_mmcfg_virt;=0A-static int __initdata =
mmcfg_pci_segment_shift;=0A+static unsigned int mmcfg_pci_segment_shift;=0A=
 =0A static char __iomem *get_virt(unsigned int seg, unsigned int *bus)=0A =
{=0A
--=__PartDAF54E7D.0__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--=__PartDAF54E7D.0__=--


From xen-devel-bounces@lists.xensource.com Thu Dec 01 10:28:24 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 10:28:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW3sA-00047K-Vj; Thu, 01 Dec 2011 10:28:10 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <lersek@redhat.com>) id 1RW3s9-00046G-KC
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 10:28:09 +0000
X-Env-Sender: lersek@redhat.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1322735249!3633589!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDU3OTQ=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22458 invoked from network); 1 Dec 2011 10:27:29 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-14.tower-174.messagelabs.com with SMTP;
	1 Dec 2011 10:27:29 -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 pB1AQbYj002543
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 1 Dec 2011 05:26:37 -0500
Received: from [10.34.1.169] (dhcp-1-169.brq.redhat.com [10.34.1.169])
	by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id pB1AQYrP002457; Thu, 1 Dec 2011 05:26:34 -0500
Message-ID: <4ED756BE.3070309@redhat.com>
Date: Thu, 01 Dec 2011 11:28:14 +0100
From: Laszlo Ersek <lersek@redhat.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.24) Gecko/20111108 Fedora/3.1.16-1.fc14
	Lightning/1.0b3pre Mnenhy/0.8.4 Thunderbird/3.1.16
MIME-Version: 1.0
To: Niall Fleming <niall.fleming@webanywhere.co.uk>
References: <4EBD5AA0.3090906@webanywhere.co.uk>	
	<20111111183913.GA9283@phenom.dumpdata.com>	
	<4EC0F20D0200007800060B7D@nat28.tlf.novell.com>	
	<20111114180045.GA14517@phenom.dumpdata.com>	<4EC16CA7.70901@goop.org>	
	<20111116142604.GA7476@phenom.dumpdata.com>	
	<4ED662B0.8060105@webanywhere.co.uk>	
	<20111130222628.GE16651@andromeda.dapyr.net>	
	<4ED740FD.4070603@webanywhere.co.uk>
	<1322733206.31810.173.camel@zakaz.uk.xensource.com>
In-Reply-To: <1322733206.31810.173.camel@zakaz.uk.xensource.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"keir.xen@gmail.com" <keir.xen@gmail.com>, Jan Beulich <JBeulich@suse.com>,
	"pbonzini@redhat.com" <pbonzini@redhat.com>,
	Konrad Rzeszutek Wilk <konrad@darnok.org>
Subject: Re: [Xen-devel] Time Change Issue Xen 4.1
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hello Niall,

On 12/01/11 10:53, Ian Campbell wrote:
> On Thu, 2011-12-01 at 08:55 +0000, Niall Fleming wrote:
>> Cheers, at least I know that someone is still looking at it!
>>
>> If someone could give me a general timeframe, like it'll be a month,
>> before we fix it, or two weeks or whatever, I just need to give my
>> line manager something so he gets off my case about it!
>
> I'm afraid OSS software doesn't generally work like that. If you (or
> your boss) wants something fixed on a specific time scale or priority
> you'll have to role your sleeves up and scratch the itch. Otherwise I'm
> sorry but you will just have to wait until someone has the cycles to
> look into this issue.

I shouldn't comment on this, because
- it'll be off-topic, and
- (more importantly) personally I'm not knowledgeable enough to fix the 
problem,

but I feel compelled to point out that *in general* it's not about the 
various rights accompanying the bits (ie. proprietary / open source / 
free software). It's about who gets to allocate whose resources. Under 
this aspect it's irrelevant under what rights the end product will be 
released, the question is instead who backs the effort & costs of the 
end product being hammered into existence.

Users of FLOSS tend to mix up these two things ("what rights do I have 
to the code?" vs. "work on this for my sake!"). For the second concept, 
commercial relationships are (and have always been) the default, even if 
extremely forthcoming FLOSS developers used to evoke a different impression.

(To make it abundantly clear, this is not an advertisment, and I'm 
speaking *strictly* personally, for myself alone.)

Laszlo

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 10:28:24 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 10:28:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW3sA-00047K-Vj; Thu, 01 Dec 2011 10:28:10 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <lersek@redhat.com>) id 1RW3s9-00046G-KC
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 10:28:09 +0000
X-Env-Sender: lersek@redhat.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1322735249!3633589!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDU3OTQ=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22458 invoked from network); 1 Dec 2011 10:27:29 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-14.tower-174.messagelabs.com with SMTP;
	1 Dec 2011 10:27:29 -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 pB1AQbYj002543
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 1 Dec 2011 05:26:37 -0500
Received: from [10.34.1.169] (dhcp-1-169.brq.redhat.com [10.34.1.169])
	by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id pB1AQYrP002457; Thu, 1 Dec 2011 05:26:34 -0500
Message-ID: <4ED756BE.3070309@redhat.com>
Date: Thu, 01 Dec 2011 11:28:14 +0100
From: Laszlo Ersek <lersek@redhat.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.24) Gecko/20111108 Fedora/3.1.16-1.fc14
	Lightning/1.0b3pre Mnenhy/0.8.4 Thunderbird/3.1.16
MIME-Version: 1.0
To: Niall Fleming <niall.fleming@webanywhere.co.uk>
References: <4EBD5AA0.3090906@webanywhere.co.uk>	
	<20111111183913.GA9283@phenom.dumpdata.com>	
	<4EC0F20D0200007800060B7D@nat28.tlf.novell.com>	
	<20111114180045.GA14517@phenom.dumpdata.com>	<4EC16CA7.70901@goop.org>	
	<20111116142604.GA7476@phenom.dumpdata.com>	
	<4ED662B0.8060105@webanywhere.co.uk>	
	<20111130222628.GE16651@andromeda.dapyr.net>	
	<4ED740FD.4070603@webanywhere.co.uk>
	<1322733206.31810.173.camel@zakaz.uk.xensource.com>
In-Reply-To: <1322733206.31810.173.camel@zakaz.uk.xensource.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"keir.xen@gmail.com" <keir.xen@gmail.com>, Jan Beulich <JBeulich@suse.com>,
	"pbonzini@redhat.com" <pbonzini@redhat.com>,
	Konrad Rzeszutek Wilk <konrad@darnok.org>
Subject: Re: [Xen-devel] Time Change Issue Xen 4.1
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hello Niall,

On 12/01/11 10:53, Ian Campbell wrote:
> On Thu, 2011-12-01 at 08:55 +0000, Niall Fleming wrote:
>> Cheers, at least I know that someone is still looking at it!
>>
>> If someone could give me a general timeframe, like it'll be a month,
>> before we fix it, or two weeks or whatever, I just need to give my
>> line manager something so he gets off my case about it!
>
> I'm afraid OSS software doesn't generally work like that. If you (or
> your boss) wants something fixed on a specific time scale or priority
> you'll have to role your sleeves up and scratch the itch. Otherwise I'm
> sorry but you will just have to wait until someone has the cycles to
> look into this issue.

I shouldn't comment on this, because
- it'll be off-topic, and
- (more importantly) personally I'm not knowledgeable enough to fix the 
problem,

but I feel compelled to point out that *in general* it's not about the 
various rights accompanying the bits (ie. proprietary / open source / 
free software). It's about who gets to allocate whose resources. Under 
this aspect it's irrelevant under what rights the end product will be 
released, the question is instead who backs the effort & costs of the 
end product being hammered into existence.

Users of FLOSS tend to mix up these two things ("what rights do I have 
to the code?" vs. "work on this for my sake!"). For the second concept, 
commercial relationships are (and have always been) the default, even if 
extremely forthcoming FLOSS developers used to evoke a different impression.

(To make it abundantly clear, this is not an advertisment, and I'm 
speaking *strictly* personally, for myself alone.)

Laszlo

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 10:35:52 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 10:35:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW3zP-0004bO-Kl; Thu, 01 Dec 2011 10:35:39 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RW3zO-0004bA-J5
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 10:35:38 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1322735698!3780937!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU2Nw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30098 invoked from network); 1 Dec 2011 10:34:59 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 10:34:59 -0000
X-IronPort-AV: E=Sophos;i="4.71,277,1320624000"; 
   d="scan'208";a="9225291"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Dec 2011 10:34:58 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 1 Dec 2011
	10:34:58 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Arnd Bergmann <arnd@arndb.de>
Date: Thu, 1 Dec 2011 10:34:58 +0000
In-Reply-To: <201111301815.01297.arnd@arndb.de>
References: <alpine.DEB.2.00.1111281009090.31179@kaball-desktop>
	<201111301432.54463.arnd@arndb.de>
	<1322670473.31810.129.camel@zakaz.uk.xensource.com>
	<201111301815.01297.arnd@arndb.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322735698.31810.194.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linaro-dev@lists.linaro.org" <linaro-dev@lists.linaro.org>,
	Pawel Moll <pawel.moll@arm.com>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>, Stefano
	Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"virtualization@lists.linux-foundation.org"
	<virtualization@lists.linux-foundation.org>,
	"android-virt@lists.cs.columbia.edu" <android-virt@lists.cs.columbia.edu>,
	"embeddedxen-devel@lists.sourceforge.net"
	<embeddedxen-devel@lists.sourceforge.net>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [ANNOUNCE] Xen port to Cortex-A15 / ARMv7 with virt
 extensions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2011-11-30 at 18:15 +0000, Arnd Bergmann wrote:
> On Wednesday 30 November 2011, Ian Campbell wrote:
> > On Wed, 2011-11-30 at 14:32 +0000, Arnd Bergmann wrote:
> > > On Wednesday 30 November 2011, Ian Campbell wrote:
> > > What I suggested to the KVM developers is to start out with the
> > > vexpress platform, but then generalize it to the point where it fits
> > > your needs. All hardware that one expects a guest to have (GIC, timer,
> > > ...) will still show up in the same location as on a real vexpress,
> > > while anything that makes no sense or is better paravirtualized (LCD,
> > > storage, ...) just becomes optional and has to be described in the
> > > device tree if it's actually there.
> > 
> > That's along the lines of what I was thinking as well.
> > 
> > The DT contains the address of GIC, timer etc as well right? So at least
> > in principal we needn't provide e.g. the GIC at the same address as any
> > real platform but in practice I expect we will.
> 
> Yes.
> 
> > In principal we could also offer the user options as to which particular
> > platform a guest looks like.
> 
> At least when using a qemu based simulation. Most platforms have some
> characteristics that are not meaningful in a classic virtualization
> scenario, but it would certainly be helpful to use the virtualization
> extensions to run a kernel that was built for a particular platform
> faster than with pure qemu, when you want to test that kernel image.
> 
> It has been suggested in the past that it would be nice to run the
> guest kernel built for the same platform as the host kernel by
> default, but I think it would be much better to have just one
> platform that we end up using for guests on any host platform,
> unless there is a strong reason to do otherwise.

Yes, I agree, certainly that is what we were planning to target in the
first instance. Doing this means that we can get away with minimal
emulation of actual hardware, relying instead on PV drivers or hardware
virtualisation features.

Supporting specific board platforms as guests would be nice to have
eventually. We would need to do more emulation (e.g. running qemu as a
device model) for that case.

> There is also ongoing restructuring in the ARM Linux kernel to
> allow running the same kernel binary on multiple platforms. While
> there is still a lot of work to be done, you should assume that
> we will finish it before you see lots of users in production, there
> is no need to plan for the current one-kernel-per-board case.

We were absolutely banking on targeting the results of this work, so
that's good ;-)

Ian.



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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 10:35:52 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 10:35:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW3zP-0004bO-Kl; Thu, 01 Dec 2011 10:35:39 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RW3zO-0004bA-J5
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 10:35:38 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1322735698!3780937!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU2Nw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30098 invoked from network); 1 Dec 2011 10:34:59 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 10:34:59 -0000
X-IronPort-AV: E=Sophos;i="4.71,277,1320624000"; 
   d="scan'208";a="9225291"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Dec 2011 10:34:58 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 1 Dec 2011
	10:34:58 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Arnd Bergmann <arnd@arndb.de>
Date: Thu, 1 Dec 2011 10:34:58 +0000
In-Reply-To: <201111301815.01297.arnd@arndb.de>
References: <alpine.DEB.2.00.1111281009090.31179@kaball-desktop>
	<201111301432.54463.arnd@arndb.de>
	<1322670473.31810.129.camel@zakaz.uk.xensource.com>
	<201111301815.01297.arnd@arndb.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322735698.31810.194.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linaro-dev@lists.linaro.org" <linaro-dev@lists.linaro.org>,
	Pawel Moll <pawel.moll@arm.com>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>, Stefano
	Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"virtualization@lists.linux-foundation.org"
	<virtualization@lists.linux-foundation.org>,
	"android-virt@lists.cs.columbia.edu" <android-virt@lists.cs.columbia.edu>,
	"embeddedxen-devel@lists.sourceforge.net"
	<embeddedxen-devel@lists.sourceforge.net>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [ANNOUNCE] Xen port to Cortex-A15 / ARMv7 with virt
 extensions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2011-11-30 at 18:15 +0000, Arnd Bergmann wrote:
> On Wednesday 30 November 2011, Ian Campbell wrote:
> > On Wed, 2011-11-30 at 14:32 +0000, Arnd Bergmann wrote:
> > > On Wednesday 30 November 2011, Ian Campbell wrote:
> > > What I suggested to the KVM developers is to start out with the
> > > vexpress platform, but then generalize it to the point where it fits
> > > your needs. All hardware that one expects a guest to have (GIC, timer,
> > > ...) will still show up in the same location as on a real vexpress,
> > > while anything that makes no sense or is better paravirtualized (LCD,
> > > storage, ...) just becomes optional and has to be described in the
> > > device tree if it's actually there.
> > 
> > That's along the lines of what I was thinking as well.
> > 
> > The DT contains the address of GIC, timer etc as well right? So at least
> > in principal we needn't provide e.g. the GIC at the same address as any
> > real platform but in practice I expect we will.
> 
> Yes.
> 
> > In principal we could also offer the user options as to which particular
> > platform a guest looks like.
> 
> At least when using a qemu based simulation. Most platforms have some
> characteristics that are not meaningful in a classic virtualization
> scenario, but it would certainly be helpful to use the virtualization
> extensions to run a kernel that was built for a particular platform
> faster than with pure qemu, when you want to test that kernel image.
> 
> It has been suggested in the past that it would be nice to run the
> guest kernel built for the same platform as the host kernel by
> default, but I think it would be much better to have just one
> platform that we end up using for guests on any host platform,
> unless there is a strong reason to do otherwise.

Yes, I agree, certainly that is what we were planning to target in the
first instance. Doing this means that we can get away with minimal
emulation of actual hardware, relying instead on PV drivers or hardware
virtualisation features.

Supporting specific board platforms as guests would be nice to have
eventually. We would need to do more emulation (e.g. running qemu as a
device model) for that case.

> There is also ongoing restructuring in the ARM Linux kernel to
> allow running the same kernel binary on multiple platforms. While
> there is still a lot of work to be done, you should assume that
> we will finish it before you see lots of users in production, there
> is no need to plan for the current one-kernel-per-board case.

We were absolutely banking on targeting the results of this work, so
that's good ;-)

Ian.



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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 10:36:45 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 10:36:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW40H-0004hB-9s; Thu, 01 Dec 2011 10:36:33 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1RW40F-0004gH-5P
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 10:36:31 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1322735734!47818972!1
X-Originating-IP: [134.134.136.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjQgPT4gMzIwNDI3\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27813 invoked from network); 1 Dec 2011 10:35:35 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-11.tower-27.messagelabs.com with SMTP;
	1 Dec 2011 10:35:35 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga102.jf.intel.com with ESMTP; 01 Dec 2011 02:35:50 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.67,351,1309762800"; d="scan'208";a="81992542"
Received: from pgsmsx602.gar.corp.intel.com ([10.221.43.81])
	by orsmga002.jf.intel.com with ESMTP; 01 Dec 2011 02:35:49 -0800
Received: from shsmsx602.ccr.corp.intel.com (10.239.4.104) by
	pgsmsx602.gar.corp.intel.com (10.221.43.81) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Thu, 1 Dec 2011 18:35:48 +0800
Received: from shsmsx502.ccr.corp.intel.com ([10.239.4.96]) by
	SHSMSX602.ccr.corp.intel.com ([10.239.4.104]) with mapi; Thu, 1 Dec 2011
	18:35:47 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Thu, 1 Dec 2011 18:35:44 +0800
Thread-Topic: [PATCH 3/6] X86: Disable PCID/INVPCID for dom0
Thread-Index: AcywEbN5bTupIpBTQbqY7Jb6t80iQAAAhfaw
Message-ID: <BC00F5384FCFC9499AF06F92E8B78A9E2870BB4205@shsmsx502.ccr.corp.intel.com>
References: <BC00F5384FCFC9499AF06F92E8B78A9E2867CF9A7E@shsmsx502.ccr.corp.intel.com>
	<4ECFA6C302000078000634A1@nat28.tlf.novell.com>
	<BC00F5384FCFC9499AF06F92E8B78A9E286DAED1B8@shsmsx502.ccr.corp.intel.com>
	<4ED34AA2020000780006394D@nat28.tlf.novell.com>
	<BC00F5384FCFC9499AF06F92E8B78A9E28707E67E4@shsmsx502.ccr.corp.intel.com>
	<BC00F5384FCFC9499AF06F92E8B78A9E2870BB41EE@shsmsx502.ccr.corp.intel.com>
	<4ED761060200007800064A09@nat28.tlf.novell.com>
In-Reply-To: <4ED761060200007800064A09@nat28.tlf.novell.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"keir@xen.org" <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH 3/6] X86: Disable PCID/INVPCID for dom0
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Jan Beulich wrote:
>>>> On 01.12.11 at 11:01, "Liu, Jinsong" <jinsong.liu@intel.com> wrote:
>> Liu, Jinsong wrote:
>>> Jan Beulich wrote:
>>>>>>> On 27.11.11 at 11:16, "Liu, Jinsong" <jinsong.liu@intel.com>
>>>>>>> wrote:
>>>>> Jan Beulich wrote:
>>>>>>>>> On 24.11.11 at 16:53, "Liu, Jinsong" <jinsong.liu@intel.com>
>>>>>>>>> wrote:
>>>>>>> This patch disable PCID/INVPCID for dom0.
>>>>>> 
>>>>>> Do we really need to disable it, rather than making it work?
>>>>>> Conceptually the feature seems usable, and the instruction would
>>>>>> need replacement by a hypercall anyway (just like invlpg).
>>>>> 
>>>>> It's a design choice.
>>>>> Exposing PCID/INVPCID to pv would involve some additional task,
>>>>> like coordinated PCID allocation algorithm, or change vmm vcpu
>>>>> context swich, which would make it complex. However, exposing
>>>>> PCID/INVPCID to pv has not obvious benefit or even result in
>>>>> performance regression.
>>>> 
>>>> Would you mind elaborating on that statement?
>>>> 
>>>> Jan
>>> 
>>> For pv, if expose PCID to pv, the PCIDs of different pv domain may
>>> conflict, which make processor confused at TLB.
>>> To make PCID work at pv, it need
>>> 1, either a coordinated PCID allocation algorithm, so that the local
>>> PCID of pv domain can be changed to a global unique PCID; 2, or, a
>>> 'clean' vcpu context switch logic to flush all TLB;
>>> method 1 make things complex w/o obvious benefit;
>>> method 2 need change current vcpu context switch logic (i.e, mov cr3
>>> only flush TLB entries of specific PCID if PCID enabled), and if
>>> flush *all* TLB is required at context switch, we lose the change to
>>> optimize context switch by partly flush TLB case by case, which may
>>> result in performance regression;
>>> 
>>> Thanks,
>>> Jinsong
>> 
>> Jan, any comments? Thanks, Jinsong
> 
> No, no further comments (just don't have the time right now to think
> through the possible alternatives). So for the moment I think things
> could go in as posted by you. It's not immediately clear though
> whether the series needs to be applied in order (it would seem that's
> not a requirement, but I'd like your confirmation), as I could at most
> take care of patches 2, 3, and 6.
> 
> Jan

Do you mean checkin patches 2/3/6 first?
It's OK to checkin patches 2/3/6 first, they are ./xen code, no order-dependence with patches 1/4/5 (which are ./tools code).

Thanks,
Jinsong


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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 10:36:45 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 10:36:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW40H-0004hB-9s; Thu, 01 Dec 2011 10:36:33 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1RW40F-0004gH-5P
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 10:36:31 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1322735734!47818972!1
X-Originating-IP: [134.134.136.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjQgPT4gMzIwNDI3\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27813 invoked from network); 1 Dec 2011 10:35:35 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-11.tower-27.messagelabs.com with SMTP;
	1 Dec 2011 10:35:35 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga102.jf.intel.com with ESMTP; 01 Dec 2011 02:35:50 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.67,351,1309762800"; d="scan'208";a="81992542"
Received: from pgsmsx602.gar.corp.intel.com ([10.221.43.81])
	by orsmga002.jf.intel.com with ESMTP; 01 Dec 2011 02:35:49 -0800
Received: from shsmsx602.ccr.corp.intel.com (10.239.4.104) by
	pgsmsx602.gar.corp.intel.com (10.221.43.81) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Thu, 1 Dec 2011 18:35:48 +0800
Received: from shsmsx502.ccr.corp.intel.com ([10.239.4.96]) by
	SHSMSX602.ccr.corp.intel.com ([10.239.4.104]) with mapi; Thu, 1 Dec 2011
	18:35:47 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Thu, 1 Dec 2011 18:35:44 +0800
Thread-Topic: [PATCH 3/6] X86: Disable PCID/INVPCID for dom0
Thread-Index: AcywEbN5bTupIpBTQbqY7Jb6t80iQAAAhfaw
Message-ID: <BC00F5384FCFC9499AF06F92E8B78A9E2870BB4205@shsmsx502.ccr.corp.intel.com>
References: <BC00F5384FCFC9499AF06F92E8B78A9E2867CF9A7E@shsmsx502.ccr.corp.intel.com>
	<4ECFA6C302000078000634A1@nat28.tlf.novell.com>
	<BC00F5384FCFC9499AF06F92E8B78A9E286DAED1B8@shsmsx502.ccr.corp.intel.com>
	<4ED34AA2020000780006394D@nat28.tlf.novell.com>
	<BC00F5384FCFC9499AF06F92E8B78A9E28707E67E4@shsmsx502.ccr.corp.intel.com>
	<BC00F5384FCFC9499AF06F92E8B78A9E2870BB41EE@shsmsx502.ccr.corp.intel.com>
	<4ED761060200007800064A09@nat28.tlf.novell.com>
In-Reply-To: <4ED761060200007800064A09@nat28.tlf.novell.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"keir@xen.org" <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH 3/6] X86: Disable PCID/INVPCID for dom0
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Jan Beulich wrote:
>>>> On 01.12.11 at 11:01, "Liu, Jinsong" <jinsong.liu@intel.com> wrote:
>> Liu, Jinsong wrote:
>>> Jan Beulich wrote:
>>>>>>> On 27.11.11 at 11:16, "Liu, Jinsong" <jinsong.liu@intel.com>
>>>>>>> wrote:
>>>>> Jan Beulich wrote:
>>>>>>>>> On 24.11.11 at 16:53, "Liu, Jinsong" <jinsong.liu@intel.com>
>>>>>>>>> wrote:
>>>>>>> This patch disable PCID/INVPCID for dom0.
>>>>>> 
>>>>>> Do we really need to disable it, rather than making it work?
>>>>>> Conceptually the feature seems usable, and the instruction would
>>>>>> need replacement by a hypercall anyway (just like invlpg).
>>>>> 
>>>>> It's a design choice.
>>>>> Exposing PCID/INVPCID to pv would involve some additional task,
>>>>> like coordinated PCID allocation algorithm, or change vmm vcpu
>>>>> context swich, which would make it complex. However, exposing
>>>>> PCID/INVPCID to pv has not obvious benefit or even result in
>>>>> performance regression.
>>>> 
>>>> Would you mind elaborating on that statement?
>>>> 
>>>> Jan
>>> 
>>> For pv, if expose PCID to pv, the PCIDs of different pv domain may
>>> conflict, which make processor confused at TLB.
>>> To make PCID work at pv, it need
>>> 1, either a coordinated PCID allocation algorithm, so that the local
>>> PCID of pv domain can be changed to a global unique PCID; 2, or, a
>>> 'clean' vcpu context switch logic to flush all TLB;
>>> method 1 make things complex w/o obvious benefit;
>>> method 2 need change current vcpu context switch logic (i.e, mov cr3
>>> only flush TLB entries of specific PCID if PCID enabled), and if
>>> flush *all* TLB is required at context switch, we lose the change to
>>> optimize context switch by partly flush TLB case by case, which may
>>> result in performance regression;
>>> 
>>> Thanks,
>>> Jinsong
>> 
>> Jan, any comments? Thanks, Jinsong
> 
> No, no further comments (just don't have the time right now to think
> through the possible alternatives). So for the moment I think things
> could go in as posted by you. It's not immediately clear though
> whether the series needs to be applied in order (it would seem that's
> not a requirement, but I'd like your confirmation), as I could at most
> take care of patches 2, 3, and 6.
> 
> Jan

Do you mean checkin patches 2/3/6 first?
It's OK to checkin patches 2/3/6 first, they are ./xen code, no order-dependence with patches 1/4/5 (which are ./tools code).

Thanks,
Jinsong


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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 10:36:55 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 10:36:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW40V-0004kJ-I4; Thu, 01 Dec 2011 10:36:47 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <sandr8@gmail.com>) id 1RVLOL-0007Yg-HD
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 10:58:25 +0000
X-Env-Sender: sandr8@gmail.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1322564266!3515016!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4759 invoked from network); 29 Nov 2011 10:57:48 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-13.tower-174.messagelabs.com with AES256-SHA encrypted SMTP;
	29 Nov 2011 10:57:48 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <sandr8@gmail.com>) id 1RVLNi-00020Q-69
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 02:57:46 -0800
Date: Tue, 29 Nov 2011 02:57:46 -0800 (PST)
From: sandr8 <sandr8@gmail.com>
To: xen-devel@lists.xensource.com
Message-ID: <1322564266184-5031946.post@n5.nabble.com>
In-Reply-To: <1316571734360-4824822.post@n5.nabble.com>
References: <1316338995760-4815691.post@n5.nabble.com>
	<alpine.DEB.2.00.1109201908010.8700@kaball-desktop>
	<1316571734360-4824822.post@n5.nabble.com>
MIME-Version: 1.0
X-Mailman-Approved-At: Thu, 01 Dec 2011 10:36:45 +0000
Subject: Re: [Xen-devel] Permission for xenstore operation on HVM
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

duolvxendev,

  I am hitting this too and I really wish there were a trick to avoid
this...

I have two theories with regard to this.

theory 1: for HVM guests Xen gives the ownership of the xenstore variables
to dom0 instead of the domU that is running the guest. My humble guess is
that Xen assumes that HVM guests are gonna be hypervisor agnostic and not
gonna be using xenstore. Of course this assumption breaks when you have
PV-HVM guests.

theory 2: in libxenlight, @libxl_create.c:290

char *rw_paths[] = { "control/shutdown", "device",
"device/suspend/event-channel" , "data"};

should actually also include "vm-data". People who bypass libxl (maybe by
using xm?) will not notice the issue. Unfortunately, I don't have a system
with xm at hand to double check this wild guess of mine...

thanks!
-alessandro-

--
View this message in context: http://xen.1045712.n5.nabble.com/Permission-for-xenstore-operation-on-HVM-tp4815691p5031946.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 10:36:55 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 10:36:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW40V-0004kJ-I4; Thu, 01 Dec 2011 10:36:47 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <sandr8@gmail.com>) id 1RVLOL-0007Yg-HD
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 10:58:25 +0000
X-Env-Sender: sandr8@gmail.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1322564266!3515016!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4759 invoked from network); 29 Nov 2011 10:57:48 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-13.tower-174.messagelabs.com with AES256-SHA encrypted SMTP;
	29 Nov 2011 10:57:48 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <sandr8@gmail.com>) id 1RVLNi-00020Q-69
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 02:57:46 -0800
Date: Tue, 29 Nov 2011 02:57:46 -0800 (PST)
From: sandr8 <sandr8@gmail.com>
To: xen-devel@lists.xensource.com
Message-ID: <1322564266184-5031946.post@n5.nabble.com>
In-Reply-To: <1316571734360-4824822.post@n5.nabble.com>
References: <1316338995760-4815691.post@n5.nabble.com>
	<alpine.DEB.2.00.1109201908010.8700@kaball-desktop>
	<1316571734360-4824822.post@n5.nabble.com>
MIME-Version: 1.0
X-Mailman-Approved-At: Thu, 01 Dec 2011 10:36:45 +0000
Subject: Re: [Xen-devel] Permission for xenstore operation on HVM
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

duolvxendev,

  I am hitting this too and I really wish there were a trick to avoid
this...

I have two theories with regard to this.

theory 1: for HVM guests Xen gives the ownership of the xenstore variables
to dom0 instead of the domU that is running the guest. My humble guess is
that Xen assumes that HVM guests are gonna be hypervisor agnostic and not
gonna be using xenstore. Of course this assumption breaks when you have
PV-HVM guests.

theory 2: in libxenlight, @libxl_create.c:290

char *rw_paths[] = { "control/shutdown", "device",
"device/suspend/event-channel" , "data"};

should actually also include "vm-data". People who bypass libxl (maybe by
using xm?) will not notice the issue. Unfortunately, I don't have a system
with xm at hand to double check this wild guess of mine...

thanks!
-alessandro-

--
View this message in context: http://xen.1045712.n5.nabble.com/Permission-for-xenstore-operation-on-HVM-tp4815691p5031946.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 10:36:55 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 10:36:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW40V-0004k8-4D; Thu, 01 Dec 2011 10:36:47 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Jonathan.Davies@eu.citrix.com>) id 1RVKi4-0005x1-SY
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 10:14:45 +0000
X-Env-Sender: Jonathan.Davies@eu.citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1322561647!5994217!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAwNw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14916 invoked from network); 29 Nov 2011 10:14:07 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 10:14:07 -0000
X-IronPort-AV: E=Sophos;i="4.69,590,1315180800"; 
   d="scan'208";a="9179771"
Received: from lonpmailmx02.citrite.net ([10.30.203.163])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Nov 2011 10:14:06 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.161]) by
	LONPMAILMX02.citrite.net ([10.30.203.163]) with mapi; Tue, 29 Nov 2011
	10:14:06 +0000
From: Jonathan Davies <Jonathan.Davies@eu.citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 29 Nov 2011 10:14:06 +0000
Thread-Topic: [Xen-devel] [PATCH] [OCaml] Release the global lock during
	some	hypercalls
Thread-Index: Acyq2WQn/RVv8D0PSWearrs8mWIn9QDpUFsA
Message-ID: <CCE8682617CC8E4693CEF507039F8E86B59B2F5330@LONPMAILBOX01.citrite.net>
References: <10758a9aa01ce39c4075.1321268775@localhost6.localdomain6>
	<20171.61030.71499.197458@mariner.uk.xensource.com>
	<CCE8682617CC8E4693CEF507039F8E86B59B2F52F4@LONPMAILBOX01.citrite.net>
	<20174.37130.453340.517982@mariner.uk.xensource.com>
In-Reply-To: <20174.37130.453340.517982@mariner.uk.xensource.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
X-Mailman-Approved-At: Thu, 01 Dec 2011 10:36:45 +0000
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] [OCaml] Release the global lock
	during	some	hypercalls
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


Ian Jackson wrote:
> Jonathan Davies writes ("Re: [Xen-devel] [PATCH] [OCaml] Release the
> global lock during some	hypercalls"):
> > It hasn't yet gone through XenRT, although I've done some manual xapi
> > stress testing in addition to some basic functional verification
> > tests.
> >
> > It sounds like you'd prefer it to go through XenRT before accepting
> > it here. I'll do so, and then confirm if all is well.
> 
> I think that would be useful, if that's OK with you.

The patch has now gone through a XenRT nightly test; no problems were observed. Is that sufficient to allay your potential concern?

Thanks,
Jonathan

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 10:36:55 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 10:36:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW40V-0004k8-4D; Thu, 01 Dec 2011 10:36:47 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Jonathan.Davies@eu.citrix.com>) id 1RVKi4-0005x1-SY
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 10:14:45 +0000
X-Env-Sender: Jonathan.Davies@eu.citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1322561647!5994217!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAwNw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14916 invoked from network); 29 Nov 2011 10:14:07 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 10:14:07 -0000
X-IronPort-AV: E=Sophos;i="4.69,590,1315180800"; 
   d="scan'208";a="9179771"
Received: from lonpmailmx02.citrite.net ([10.30.203.163])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Nov 2011 10:14:06 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.161]) by
	LONPMAILMX02.citrite.net ([10.30.203.163]) with mapi; Tue, 29 Nov 2011
	10:14:06 +0000
From: Jonathan Davies <Jonathan.Davies@eu.citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 29 Nov 2011 10:14:06 +0000
Thread-Topic: [Xen-devel] [PATCH] [OCaml] Release the global lock during
	some	hypercalls
Thread-Index: Acyq2WQn/RVv8D0PSWearrs8mWIn9QDpUFsA
Message-ID: <CCE8682617CC8E4693CEF507039F8E86B59B2F5330@LONPMAILBOX01.citrite.net>
References: <10758a9aa01ce39c4075.1321268775@localhost6.localdomain6>
	<20171.61030.71499.197458@mariner.uk.xensource.com>
	<CCE8682617CC8E4693CEF507039F8E86B59B2F52F4@LONPMAILBOX01.citrite.net>
	<20174.37130.453340.517982@mariner.uk.xensource.com>
In-Reply-To: <20174.37130.453340.517982@mariner.uk.xensource.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
X-Mailman-Approved-At: Thu, 01 Dec 2011 10:36:45 +0000
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] [OCaml] Release the global lock
	during	some	hypercalls
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


Ian Jackson wrote:
> Jonathan Davies writes ("Re: [Xen-devel] [PATCH] [OCaml] Release the
> global lock during some	hypercalls"):
> > It hasn't yet gone through XenRT, although I've done some manual xapi
> > stress testing in addition to some basic functional verification
> > tests.
> >
> > It sounds like you'd prefer it to go through XenRT before accepting
> > it here. I'll do so, and then confirm if all is well.
> 
> I think that would be useful, if that's OK with you.

The patch has now gone through a XenRT nightly test; no problems were observed. Is that sufficient to allay your potential concern?

Thanks,
Jonathan

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 10:36:55 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 10:36:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW40U-0004jx-NM; Thu, 01 Dec 2011 10:36:46 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anitawang1989@gmail.com>) id 1RV2dp-0002gu-RF
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 14:57:10 +0000
X-Env-Sender: anitawang1989@gmail.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1322492192!4987101!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31070 invoked from network); 28 Nov 2011 14:56:33 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-2.tower-182.messagelabs.com with AES256-SHA encrypted SMTP;
	28 Nov 2011 14:56:33 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <anitawang1989@gmail.com>) id 1RV2dD-00027B-Ac
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 06:56:31 -0800
Date: Mon, 28 Nov 2011 06:56:31 -0800 (PST)
From: anita <anitawang1989@gmail.com>
To: xen-devel@lists.xensource.com
Message-ID: <1322492191323-5029084.post@n5.nabble.com>
In-Reply-To: <1322489515.1005.296.camel@zakaz.uk.xensource.com>
References: <1322289225863-5024421.post@n5.nabble.com>
	<1322489515.1005.296.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
X-Mailman-Approved-At: Thu, 01 Dec 2011 10:36:45 +0000
Subject: Re: [Xen-devel] 2 questions about hypercall
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Thanks very much for your reply!
1.   I'm using kernel 2.6.32.13
2.   Do you mean that when the tools want to use hypercall, it doesn't
need to do
     --->HYPERVISOR_XX  ---> __hypercalln  ----> int 0x82    as the
dom0 or domU do.
     It simply executes  the assembly-code in the privcmd_ioctl to do
the int0x82 ???

--
View this message in context: http://xen.1045712.n5.nabble.com/2-questions-about-hypercall-tp5024421p5029084.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 10:36:55 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 10:36:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW40U-0004jx-NM; Thu, 01 Dec 2011 10:36:46 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anitawang1989@gmail.com>) id 1RV2dp-0002gu-RF
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 14:57:10 +0000
X-Env-Sender: anitawang1989@gmail.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1322492192!4987101!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31070 invoked from network); 28 Nov 2011 14:56:33 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-2.tower-182.messagelabs.com with AES256-SHA encrypted SMTP;
	28 Nov 2011 14:56:33 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <anitawang1989@gmail.com>) id 1RV2dD-00027B-Ac
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 06:56:31 -0800
Date: Mon, 28 Nov 2011 06:56:31 -0800 (PST)
From: anita <anitawang1989@gmail.com>
To: xen-devel@lists.xensource.com
Message-ID: <1322492191323-5029084.post@n5.nabble.com>
In-Reply-To: <1322489515.1005.296.camel@zakaz.uk.xensource.com>
References: <1322289225863-5024421.post@n5.nabble.com>
	<1322489515.1005.296.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
X-Mailman-Approved-At: Thu, 01 Dec 2011 10:36:45 +0000
Subject: Re: [Xen-devel] 2 questions about hypercall
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Thanks very much for your reply!
1.   I'm using kernel 2.6.32.13
2.   Do you mean that when the tools want to use hypercall, it doesn't
need to do
     --->HYPERVISOR_XX  ---> __hypercalln  ----> int 0x82    as the
dom0 or domU do.
     It simply executes  the assembly-code in the privcmd_ioctl to do
the int0x82 ???

--
View this message in context: http://xen.1045712.n5.nabble.com/2-questions-about-hypercall-tp5024421p5029084.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 10:36:55 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 10:36:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW40V-0004kU-UR; Thu, 01 Dec 2011 10:36:47 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <sploving1@gmail.com>) id 1RVOa6-0005zp-De
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 14:22:46 +0000
X-Env-Sender: sploving1@gmail.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1322576485!55325484!1
X-Originating-IP: [209.85.213.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17531 invoked from network); 29 Nov 2011 14:21:26 -0000
Received: from mail-yw0-f43.google.com (HELO mail-yw0-f43.google.com)
	(209.85.213.43)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 14:21:26 -0000
Received: by ywt34 with SMTP id 34so7018108ywt.30
	for <xen-devel@lists.xensource.com>;
	Tue, 29 Nov 2011 06:22:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:date:message-id:subject:from:to:content-type
	:content-transfer-encoding;
	bh=dP2sKSNMRxX/xj6W12DiWbBOKYSkXuD+GqfX+EmMWIo=;
	b=vDcFhgjnUCBdAWK04uU5YHQvi6UaNeHsZkFZJXI3WIAwHVfCkSQPoY3ic4V6KyzCVU
	W1Zobb/rzcoyNxDDlHOYr6oIZQ1MZB9aVrYOwGFcV10Rv+GKKcggnjMxBrOBn/UuKVW7
	96iASWikrifGtHwiIouWvcbk0T3q7T3urBu0I=
MIME-Version: 1.0
Received: by 10.204.148.4 with SMTP id n4mr50883082bkv.42.1322576527081; Tue,
	29 Nov 2011 06:22:07 -0800 (PST)
Received: by 10.205.125.139 with HTTP; Tue, 29 Nov 2011 06:22:06 -0800 (PST)
Date: Tue, 29 Nov 2011 22:22:06 +0800
Message-ID: <CAP=GMUEvnnOGmiM9ar+oQw4c6fwzvWa+HX98C3kV_XgMc3xg9Q@mail.gmail.com>
From: Baozeng <sploving1@gmail.com>
To: xen-devel@lists.xensource.com
X-Mailman-Approved-At: Thu, 01 Dec 2011 10:36:45 +0000
Subject: [Xen-devel] any exit function in xen that is similar to exit_kernel?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hello all,
I added a hypercall "do_greet" that only prints "Hello world" to do a
small experiment. After it prints the "hello world", I would it to
exit from Xen and stop current process. For instance:
the hypercall is like this:
int do_greet(){
   pirntk("Hello world\n");
   /*then I would it exit from Xen and stop current process that called it.=
*/
   exit_?? //exit(0) does not work.
}

If a process at the application level calls this hypercall through
privcmd file, I would like it kill this process after the hypercall
prints "Hello world". Then how to do that?
In linux kernel, there is a function exit_kernel, which switch the
kernel address space into the user address space. But I did not find
any similar function in Xen. Any idea? thanks

-- =

=A0=A0=A0=A0 Best Regards,
=A0=A0=A0=A0=A0=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0=A0=A0=A0 Baozeng Ding
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 OSTG,NFS,ISCAS

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 10:36:55 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 10:36:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW40V-0004kU-UR; Thu, 01 Dec 2011 10:36:47 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <sploving1@gmail.com>) id 1RVOa6-0005zp-De
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 14:22:46 +0000
X-Env-Sender: sploving1@gmail.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1322576485!55325484!1
X-Originating-IP: [209.85.213.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17531 invoked from network); 29 Nov 2011 14:21:26 -0000
Received: from mail-yw0-f43.google.com (HELO mail-yw0-f43.google.com)
	(209.85.213.43)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 14:21:26 -0000
Received: by ywt34 with SMTP id 34so7018108ywt.30
	for <xen-devel@lists.xensource.com>;
	Tue, 29 Nov 2011 06:22:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:date:message-id:subject:from:to:content-type
	:content-transfer-encoding;
	bh=dP2sKSNMRxX/xj6W12DiWbBOKYSkXuD+GqfX+EmMWIo=;
	b=vDcFhgjnUCBdAWK04uU5YHQvi6UaNeHsZkFZJXI3WIAwHVfCkSQPoY3ic4V6KyzCVU
	W1Zobb/rzcoyNxDDlHOYr6oIZQ1MZB9aVrYOwGFcV10Rv+GKKcggnjMxBrOBn/UuKVW7
	96iASWikrifGtHwiIouWvcbk0T3q7T3urBu0I=
MIME-Version: 1.0
Received: by 10.204.148.4 with SMTP id n4mr50883082bkv.42.1322576527081; Tue,
	29 Nov 2011 06:22:07 -0800 (PST)
Received: by 10.205.125.139 with HTTP; Tue, 29 Nov 2011 06:22:06 -0800 (PST)
Date: Tue, 29 Nov 2011 22:22:06 +0800
Message-ID: <CAP=GMUEvnnOGmiM9ar+oQw4c6fwzvWa+HX98C3kV_XgMc3xg9Q@mail.gmail.com>
From: Baozeng <sploving1@gmail.com>
To: xen-devel@lists.xensource.com
X-Mailman-Approved-At: Thu, 01 Dec 2011 10:36:45 +0000
Subject: [Xen-devel] any exit function in xen that is similar to exit_kernel?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hello all,
I added a hypercall "do_greet" that only prints "Hello world" to do a
small experiment. After it prints the "hello world", I would it to
exit from Xen and stop current process. For instance:
the hypercall is like this:
int do_greet(){
   pirntk("Hello world\n");
   /*then I would it exit from Xen and stop current process that called it.=
*/
   exit_?? //exit(0) does not work.
}

If a process at the application level calls this hypercall through
privcmd file, I would like it kill this process after the hypercall
prints "Hello world". Then how to do that?
In linux kernel, there is a function exit_kernel, which switch the
kernel address space into the user address space. But I did not find
any similar function in Xen. Any idea? thanks

-- =

=A0=A0=A0=A0 Best Regards,
=A0=A0=A0=A0=A0=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0=A0=A0=A0 Baozeng Ding
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 OSTG,NFS,ISCAS

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 10:36:55 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 10:36:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW40a-0004oU-RL; Thu, 01 Dec 2011 10:36:52 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <addarathbone@googlemail.com>) id 1RVra0-0004wq-Sa
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 21:20:37 +0000
X-Env-Sender: addarathbone@googlemail.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1322687997!3758783!1
X-Originating-IP: [209.85.161.43]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18678 invoked from network); 30 Nov 2011 21:19:57 -0000
Received: from mail-fx0-f43.google.com (HELO mail-fx0-f43.google.com)
	(209.85.161.43)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Nov 2011 21:19:57 -0000
Received: by fagn18 with SMTP id n18so1386917fag.30
	for <xen-devel@lists.xensource.com>;
	Wed, 30 Nov 2011 13:19:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=googlemail.com; s=gamma;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=XTJoCn/U6p1DjeQwmdJhxzrdIbICLK039B7cJQPtyjc=;
	b=m9MwOHoSHAXpBDKi3BIcHUT3zGA7RMOAevQnEhNqzJHj2HG/yM5gHmC3XGSwisYPYl
	mmpwALl8S8yt0tDG6Fxn2zzIZx/8Gd30KtXcNRsTYtUp3IOW5I/9jpFnMcPPLRqVVAmd
	kFRpIJFZfJbaXJpe6FB9IRM72DcswEv/x6oLY=
MIME-Version: 1.0
Received: by 10.180.106.104 with SMTP id gt8mr3022067wib.6.1322687997260; Wed,
	30 Nov 2011 13:19:57 -0800 (PST)
Received: by 10.180.96.225 with HTTP; Wed, 30 Nov 2011 13:19:57 -0800 (PST)
Date: Wed, 30 Nov 2011 22:19:57 +0100
Message-ID: <CANrAofX3ARD8CN8HtoBnetfMZvBUS5RSC89ExuGoVSzqmE2V9A@mail.gmail.com>
From: Adda Rathbone <addarathbone@googlemail.com>
To: xen-devel@lists.xensource.com
X-Mailman-Approved-At: Thu, 01 Dec 2011 10:36:45 +0000
Subject: [Xen-devel] Compile error with Ubuntu 11.10
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============8650634902156781188=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============8650634902156781188==
Content-Type: multipart/alternative; boundary=f46d04428ee239b4c704b2fa4c8d

--f46d04428ee239b4c704b2fa4c8d
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Hi,
compilation of xen-unstable with a fresh Ubuntu 11.10 x86_64 fails with
following error:

cc1: warnings being treated as errors
libxl_create.c: In function =91store_libxl_entry=92:
libxl_create.c:465: error: format not a string literal and no format
arguments

Steps to reproduce:

- Install Ubuntu 11.10 (
http://www.ubuntu.com/start-download?distro=3Ddesktop&bits=3D64&release=3Dl=
atest)
- sudo apt-get install mercurial libsdl-dev pciutils-dev ncurses-dev
uuid-dev gettext libyajl-dev flex zlib1g-dev libssl-dev xorg-dev bcc bin86
iasl libc6-dev-i386 patch git
- hg clone http://xenbits.xensource.com/xen-unstable.hg
- cd xen-unstable.hg/tools
- make

Adda

--f46d04428ee239b4c704b2fa4c8d
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Hi,<br>compilation of xen-unstable with a fresh Ubuntu 11.10 x86_64 fails w=
ith following error:<br><br>cc1: warnings being treated as errors<br>libxl_=
create.c: In function =91store_libxl_entry=92:<br>libxl_create.c:465: error=
: format not a string literal and no format arguments<br>

<br>Steps to reproduce:<br><br>- Install Ubuntu 11.10 (<a href=3D"http://ww=
w.ubuntu.com/start-download?distro=3Ddesktop&amp;bits=3D64&amp;release=3Dla=
test" target=3D"_blank">http://www.ubuntu.com/start-download?distro=3Ddeskt=
op&amp;bits=3D64&amp;release=3Dlatest</a>)<br>

- sudo apt-get install mercurial libsdl-dev pciutils-dev ncurses-dev uuid-d=
ev gettext libyajl-dev flex zlib1g-dev libssl-dev xorg-dev bcc bin86 iasl l=
ibc6-dev-i386 patch git<br>- hg clone <a href=3D"http://xenbits.xensource.c=
om/xen-unstable.hg" target=3D"_blank">http://xenbits.xensource.com/xen-unst=
able.hg</a><br>

- cd xen-unstable.hg/tools<br>- make<br><br>Adda<br>

--f46d04428ee239b4c704b2fa4c8d--


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

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

--===============8650634902156781188==--


From xen-devel-bounces@lists.xensource.com Thu Dec 01 10:36:55 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 10:36:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW40Y-0004mI-FW; Thu, 01 Dec 2011 10:36:50 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raghavendra.kt@linux.vnet.ibm.com>)
	id 1RVg2L-0007gd-P6
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 09:01:06 +0000
X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1322643625!4718552!1
X-Originating-IP: [32.97.110.153]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMzIuOTcuMTEwLjE1MyA9PiAzMzgzMDk=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31573 invoked from network); 30 Nov 2011 09:00:27 -0000
Received: from e35.co.us.ibm.com (HELO e35.co.us.ibm.com) (32.97.110.153)
	by server-13.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 30 Nov 2011 09:00:27 -0000
Received: from /spool/local
	by e35.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only!
	Violators will be prosecuted for <xen-devel@lists.xensource.com> from
	<raghavendra.kt@linux.vnet.ibm.com>; Wed, 30 Nov 2011 02:00:23 -0700
Received: from d03relay04.boulder.ibm.com ([9.17.195.106])
	by e35.co.us.ibm.com ([192.168.1.135]) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Wed, 30 Nov 2011 01:59:48 -0700
Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170])
	by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	pAU8xmOL128888
	for <xen-devel@lists.xensource.com>; Wed, 30 Nov 2011 01:59:48 -0700
Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1])
	by d03av04.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP
	id pAU8xjbk023855
	for <xen-devel@lists.xensource.com>; Wed, 30 Nov 2011 01:59:47 -0700
Received: from oc5400248562.ibm.com (oc5400248562.in.ibm.com [9.124.158.199])
	by d03av04.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP
	id pAU8xaot023253; Wed, 30 Nov 2011 01:59:37 -0700
From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
To: Greg Kroah-Hartman <gregkh@suse.de>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Gleb Natapov <gleb@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>, x86@kernel.org,
	KVM <kvm@vger.kernel.org>, Dave Jiang <dave.jiang@intel.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	LKML <linux-kernel@vger.kernel.org>,
	Sedat Dilek <sedat.dilek@gmail.com>, Yinghai Lu <yinghai@kernel.org>,
	Marcelo Tosatti <mtosatti@redhat.com>, Ingo Molnar <mingo@redhat.com>, 
	Avi Kivity <avi@redhat.com>, Rik van Riel <riel@redhat.com>,
	Xen <xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Wed, 30 Nov 2011 14:29:39 +0530
Message-Id: <20111130085939.23386.1242.sendpatchset@oc5400248562.ibm.com>
In-Reply-To: <20111130085921.23386.89708.sendpatchset@oc5400248562.ibm.com>
References: <20111130085921.23386.89708.sendpatchset@oc5400248562.ibm.com>
x-cbid: 11113008-6148-0000-0000-000001A2198F
X-Mailman-Approved-At: Thu, 01 Dec 2011 10:36:45 +0000
Cc: Peter Zijlstra <peterz@infradead.org>,
	Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Dave Hansen <dave@linux.vnet.ibm.com>,
	Suzuki Poulose <suzuki@linux.vnet.ibm.com>,
	Sasha Levin <levinsasha928@gmail.com>
Subject: [Xen-devel] [PATCH RFC V3 1/4] debugfs: Add support to print u32
	array in debugfs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Add debugfs support to print u32-arrays in debugfs. Move the code from Xen to debugfs
to make the code common for other users as well.

Signed-off-by: Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>
Signed-off-by: Suzuki Poulose <suzuki@in.ibm.com>
Signed-off-by: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
---
diff --git a/arch/x86/xen/debugfs.c b/arch/x86/xen/debugfs.c
index 7c0fedd..c8377fb 100644
--- a/arch/x86/xen/debugfs.c
+++ b/arch/x86/xen/debugfs.c
@@ -19,107 +19,3 @@ struct dentry * __init xen_init_debugfs(void)
 	return d_xen_debug;
 }
 
-struct array_data
-{
-	void *array;
-	unsigned elements;
-};
-
-static int u32_array_open(struct inode *inode, struct file *file)
-{
-	file->private_data = NULL;
-	return nonseekable_open(inode, file);
-}
-
-static size_t format_array(char *buf, size_t bufsize, const char *fmt,
-			   u32 *array, unsigned array_size)
-{
-	size_t ret = 0;
-	unsigned i;
-
-	for(i = 0; i < array_size; i++) {
-		size_t len;
-
-		len = snprintf(buf, bufsize, fmt, array[i]);
-		len++;	/* ' ' or '\n' */
-		ret += len;
-
-		if (buf) {
-			buf += len;
-			bufsize -= len;
-			buf[-1] = (i == array_size-1) ? '\n' : ' ';
-		}
-	}
-
-	ret++;		/* \0 */
-	if (buf)
-		*buf = '\0';
-
-	return ret;
-}
-
-static char *format_array_alloc(const char *fmt, u32 *array, unsigned array_size)
-{
-	size_t len = format_array(NULL, 0, fmt, array, array_size);
-	char *ret;
-
-	ret = kmalloc(len, GFP_KERNEL);
-	if (ret == NULL)
-		return NULL;
-
-	format_array(ret, len, fmt, array, array_size);
-	return ret;
-}
-
-static ssize_t u32_array_read(struct file *file, char __user *buf, size_t len,
-			      loff_t *ppos)
-{
-	struct inode *inode = file->f_path.dentry->d_inode;
-	struct array_data *data = inode->i_private;
-	size_t size;
-
-	if (*ppos == 0) {
-		if (file->private_data) {
-			kfree(file->private_data);
-			file->private_data = NULL;
-		}
-
-		file->private_data = format_array_alloc("%u", data->array, data->elements);
-	}
-
-	size = 0;
-	if (file->private_data)
-		size = strlen(file->private_data);
-
-	return simple_read_from_buffer(buf, len, ppos, file->private_data, size);
-}
-
-static int xen_array_release(struct inode *inode, struct file *file)
-{
-	kfree(file->private_data);
-
-	return 0;
-}
-
-static const struct file_operations u32_array_fops = {
-	.owner	= THIS_MODULE,
-	.open	= u32_array_open,
-	.release= xen_array_release,
-	.read	= u32_array_read,
-	.llseek = no_llseek,
-};
-
-struct dentry *xen_debugfs_create_u32_array(const char *name, mode_t mode,
-					    struct dentry *parent,
-					    u32 *array, unsigned elements)
-{
-	struct array_data *data = kmalloc(sizeof(*data), GFP_KERNEL);
-
-	if (data == NULL)
-		return NULL;
-
-	data->array = array;
-	data->elements = elements;
-
-	return debugfs_create_file(name, mode, parent, data, &u32_array_fops);
-}
diff --git a/arch/x86/xen/debugfs.h b/arch/x86/xen/debugfs.h
index e281320..12ebf33 100644
--- a/arch/x86/xen/debugfs.h
+++ b/arch/x86/xen/debugfs.h
@@ -3,8 +3,4 @@
 
 struct dentry * __init xen_init_debugfs(void);
 
-struct dentry *xen_debugfs_create_u32_array(const char *name, mode_t mode,
-					    struct dentry *parent,
-					    u32 *array, unsigned elements);
-
 #endif /* _XEN_DEBUGFS_H */
diff --git a/arch/x86/xen/spinlock.c b/arch/x86/xen/spinlock.c
index fc506e6..14a8961 100644
--- a/arch/x86/xen/spinlock.c
+++ b/arch/x86/xen/spinlock.c
@@ -286,7 +286,7 @@ static int __init xen_spinlock_debugfs(void)
 	debugfs_create_u64("time_blocked", 0444, d_spin_debug,
 			   &spinlock_stats.time_blocked);
 
-	xen_debugfs_create_u32_array("histo_blocked", 0444, d_spin_debug,
+	debugfs_create_u32_array("histo_blocked", 0444, d_spin_debug,
 				     spinlock_stats.histo_spin_blocked, HISTO_BUCKETS + 1);
 
 	return 0;
diff --git a/fs/debugfs/file.c b/fs/debugfs/file.c
index 90f7657..df44ccf 100644
--- a/fs/debugfs/file.c
+++ b/fs/debugfs/file.c
@@ -18,6 +18,7 @@
 #include <linux/pagemap.h>
 #include <linux/namei.h>
 #include <linux/debugfs.h>
+#include <linux/slab.h>
 
 static ssize_t default_read_file(struct file *file, char __user *buf,
 				 size_t count, loff_t *ppos)
@@ -525,3 +526,130 @@ struct dentry *debugfs_create_blob(const char *name, mode_t mode,
 	return debugfs_create_file(name, mode, parent, blob, &fops_blob);
 }
 EXPORT_SYMBOL_GPL(debugfs_create_blob);
+
+struct array_data {
+	void *array;
+	u32 elements;
+};
+
+static int u32_array_open(struct inode *inode, struct file *file)
+{
+	file->private_data = NULL;
+	return nonseekable_open(inode, file);
+}
+
+static size_t format_array(char *buf, size_t bufsize, const char *fmt,
+			   u32 *array, u32 array_size)
+{
+	size_t ret = 0;
+	u32 i;
+
+	for (i = 0; i < array_size; i++) {
+		size_t len;
+
+		len = snprintf(buf, bufsize, fmt, array[i]);
+		len++;	/* ' ' or '\n' */
+		ret += len;
+
+		if (buf) {
+			buf += len;
+			bufsize -= len;
+			buf[-1] = (i == array_size-1) ? '\n' : ' ';
+		}
+	}
+
+	ret++;		/* \0 */
+	if (buf)
+		*buf = '\0';
+
+	return ret;
+}
+
+static char *format_array_alloc(const char *fmt, u32 *array,
+						u32 array_size)
+{
+	size_t len = format_array(NULL, 0, fmt, array, array_size);
+	char *ret;
+
+	ret = kmalloc(len, GFP_KERNEL);
+	if (ret == NULL)
+		return NULL;
+
+	format_array(ret, len, fmt, array, array_size);
+	return ret;
+}
+
+static ssize_t u32_array_read(struct file *file, char __user *buf, size_t len,
+			      loff_t *ppos)
+{
+	struct inode *inode = file->f_path.dentry->d_inode;
+	struct array_data *data = inode->i_private;
+	size_t size;
+
+	if (*ppos == 0) {
+		if (file->private_data) {
+			kfree(file->private_data);
+			file->private_data = NULL;
+		}
+
+		file->private_data = format_array_alloc("%u", data->array,
+							      data->elements);
+	}
+
+	size = 0;
+	if (file->private_data)
+		size = strlen(file->private_data);
+
+	return simple_read_from_buffer(buf, len, ppos,
+					file->private_data, size);
+}
+
+static int u32_array_release(struct inode *inode, struct file *file)
+{
+	kfree(file->private_data);
+
+	return 0;
+}
+
+static const struct file_operations u32_array_fops = {
+	.owner	 = THIS_MODULE,
+	.open	 = u32_array_open,
+	.release = u32_array_release,
+	.read	 = u32_array_read,
+	.llseek  = no_llseek,
+};
+
+/**
+ * debugfs_create_u32_array - create a debugfs file that is used to read u32
+ * array.
+ * @name: a pointer to a string containing the name of the file to create.
+ * @mode: the permission that the file should have.
+ * @parent: a pointer to the parent dentry for this file.  This should be a
+ *          directory dentry if set.  If this parameter is %NULL, then the
+ *          file will be created in the root of the debugfs filesystem.
+ * @array: u32 array that provides data.
+ * @elements: total number of elements in the array.
+ *
+ * This function creates a file in debugfs with the given name that exports
+ * @array as data. If the @mode variable is so set it can be read from.
+ * Writing is not supported. Seek within the file is also not supported.
+ * Once array is created its size can not be changed.
+ *
+ * The function returns a pointer to dentry on success. If debugfs is not
+ * enabled in the kernel, the value -%ENODEV will be returned.
+ */
+struct dentry *debugfs_create_u32_array(const char *name, mode_t mode,
+					    struct dentry *parent,
+					    u32 *array, u32 elements)
+{
+	struct array_data *data = kmalloc(sizeof(*data), GFP_KERNEL);
+
+	if (data == NULL)
+		return NULL;
+
+	data->array = array;
+	data->elements = elements;
+
+	return debugfs_create_file(name, mode, parent, data, &u32_array_fops);
+}
+EXPORT_SYMBOL_GPL(debugfs_create_u32_array);
diff --git a/include/linux/debugfs.h b/include/linux/debugfs.h
index e7d9b20..253e2fb 100644
--- a/include/linux/debugfs.h
+++ b/include/linux/debugfs.h
@@ -74,6 +74,10 @@ struct dentry *debugfs_create_blob(const char *name, mode_t mode,
 				  struct dentry *parent,
 				  struct debugfs_blob_wrapper *blob);
 
+struct dentry *debugfs_create_u32_array(const char *name, mode_t mode,
+					struct dentry *parent,
+					u32 *array, u32 elements);
+
 bool debugfs_initialized(void);
 
 #else
@@ -193,6 +197,13 @@ static inline bool debugfs_initialized(void)
 	return false;
 }
 
+struct dentry *debugfs_create_u32_array(const char *name, mode_t mode,
+					struct dentry *parent,
+					u32 *array, u32 elements)
+{
+	return ERR_PTR(-ENODEV);
+}
+
 #endif
 
 #endif


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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 10:36:55 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 10:36:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW40a-0004oU-RL; Thu, 01 Dec 2011 10:36:52 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <addarathbone@googlemail.com>) id 1RVra0-0004wq-Sa
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 21:20:37 +0000
X-Env-Sender: addarathbone@googlemail.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1322687997!3758783!1
X-Originating-IP: [209.85.161.43]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18678 invoked from network); 30 Nov 2011 21:19:57 -0000
Received: from mail-fx0-f43.google.com (HELO mail-fx0-f43.google.com)
	(209.85.161.43)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Nov 2011 21:19:57 -0000
Received: by fagn18 with SMTP id n18so1386917fag.30
	for <xen-devel@lists.xensource.com>;
	Wed, 30 Nov 2011 13:19:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=googlemail.com; s=gamma;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=XTJoCn/U6p1DjeQwmdJhxzrdIbICLK039B7cJQPtyjc=;
	b=m9MwOHoSHAXpBDKi3BIcHUT3zGA7RMOAevQnEhNqzJHj2HG/yM5gHmC3XGSwisYPYl
	mmpwALl8S8yt0tDG6Fxn2zzIZx/8Gd30KtXcNRsTYtUp3IOW5I/9jpFnMcPPLRqVVAmd
	kFRpIJFZfJbaXJpe6FB9IRM72DcswEv/x6oLY=
MIME-Version: 1.0
Received: by 10.180.106.104 with SMTP id gt8mr3022067wib.6.1322687997260; Wed,
	30 Nov 2011 13:19:57 -0800 (PST)
Received: by 10.180.96.225 with HTTP; Wed, 30 Nov 2011 13:19:57 -0800 (PST)
Date: Wed, 30 Nov 2011 22:19:57 +0100
Message-ID: <CANrAofX3ARD8CN8HtoBnetfMZvBUS5RSC89ExuGoVSzqmE2V9A@mail.gmail.com>
From: Adda Rathbone <addarathbone@googlemail.com>
To: xen-devel@lists.xensource.com
X-Mailman-Approved-At: Thu, 01 Dec 2011 10:36:45 +0000
Subject: [Xen-devel] Compile error with Ubuntu 11.10
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============8650634902156781188=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============8650634902156781188==
Content-Type: multipart/alternative; boundary=f46d04428ee239b4c704b2fa4c8d

--f46d04428ee239b4c704b2fa4c8d
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Hi,
compilation of xen-unstable with a fresh Ubuntu 11.10 x86_64 fails with
following error:

cc1: warnings being treated as errors
libxl_create.c: In function =91store_libxl_entry=92:
libxl_create.c:465: error: format not a string literal and no format
arguments

Steps to reproduce:

- Install Ubuntu 11.10 (
http://www.ubuntu.com/start-download?distro=3Ddesktop&bits=3D64&release=3Dl=
atest)
- sudo apt-get install mercurial libsdl-dev pciutils-dev ncurses-dev
uuid-dev gettext libyajl-dev flex zlib1g-dev libssl-dev xorg-dev bcc bin86
iasl libc6-dev-i386 patch git
- hg clone http://xenbits.xensource.com/xen-unstable.hg
- cd xen-unstable.hg/tools
- make

Adda

--f46d04428ee239b4c704b2fa4c8d
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Hi,<br>compilation of xen-unstable with a fresh Ubuntu 11.10 x86_64 fails w=
ith following error:<br><br>cc1: warnings being treated as errors<br>libxl_=
create.c: In function =91store_libxl_entry=92:<br>libxl_create.c:465: error=
: format not a string literal and no format arguments<br>

<br>Steps to reproduce:<br><br>- Install Ubuntu 11.10 (<a href=3D"http://ww=
w.ubuntu.com/start-download?distro=3Ddesktop&amp;bits=3D64&amp;release=3Dla=
test" target=3D"_blank">http://www.ubuntu.com/start-download?distro=3Ddeskt=
op&amp;bits=3D64&amp;release=3Dlatest</a>)<br>

- sudo apt-get install mercurial libsdl-dev pciutils-dev ncurses-dev uuid-d=
ev gettext libyajl-dev flex zlib1g-dev libssl-dev xorg-dev bcc bin86 iasl l=
ibc6-dev-i386 patch git<br>- hg clone <a href=3D"http://xenbits.xensource.c=
om/xen-unstable.hg" target=3D"_blank">http://xenbits.xensource.com/xen-unst=
able.hg</a><br>

- cd xen-unstable.hg/tools<br>- make<br><br>Adda<br>

--f46d04428ee239b4c704b2fa4c8d--


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

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

--===============8650634902156781188==--


From xen-devel-bounces@lists.xensource.com Thu Dec 01 10:36:55 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 10:36:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW40Y-0004mI-FW; Thu, 01 Dec 2011 10:36:50 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raghavendra.kt@linux.vnet.ibm.com>)
	id 1RVg2L-0007gd-P6
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 09:01:06 +0000
X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1322643625!4718552!1
X-Originating-IP: [32.97.110.153]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMzIuOTcuMTEwLjE1MyA9PiAzMzgzMDk=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31573 invoked from network); 30 Nov 2011 09:00:27 -0000
Received: from e35.co.us.ibm.com (HELO e35.co.us.ibm.com) (32.97.110.153)
	by server-13.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 30 Nov 2011 09:00:27 -0000
Received: from /spool/local
	by e35.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only!
	Violators will be prosecuted for <xen-devel@lists.xensource.com> from
	<raghavendra.kt@linux.vnet.ibm.com>; Wed, 30 Nov 2011 02:00:23 -0700
Received: from d03relay04.boulder.ibm.com ([9.17.195.106])
	by e35.co.us.ibm.com ([192.168.1.135]) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Wed, 30 Nov 2011 01:59:48 -0700
Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170])
	by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	pAU8xmOL128888
	for <xen-devel@lists.xensource.com>; Wed, 30 Nov 2011 01:59:48 -0700
Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1])
	by d03av04.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP
	id pAU8xjbk023855
	for <xen-devel@lists.xensource.com>; Wed, 30 Nov 2011 01:59:47 -0700
Received: from oc5400248562.ibm.com (oc5400248562.in.ibm.com [9.124.158.199])
	by d03av04.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP
	id pAU8xaot023253; Wed, 30 Nov 2011 01:59:37 -0700
From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
To: Greg Kroah-Hartman <gregkh@suse.de>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Gleb Natapov <gleb@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>, x86@kernel.org,
	KVM <kvm@vger.kernel.org>, Dave Jiang <dave.jiang@intel.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	LKML <linux-kernel@vger.kernel.org>,
	Sedat Dilek <sedat.dilek@gmail.com>, Yinghai Lu <yinghai@kernel.org>,
	Marcelo Tosatti <mtosatti@redhat.com>, Ingo Molnar <mingo@redhat.com>, 
	Avi Kivity <avi@redhat.com>, Rik van Riel <riel@redhat.com>,
	Xen <xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Wed, 30 Nov 2011 14:29:39 +0530
Message-Id: <20111130085939.23386.1242.sendpatchset@oc5400248562.ibm.com>
In-Reply-To: <20111130085921.23386.89708.sendpatchset@oc5400248562.ibm.com>
References: <20111130085921.23386.89708.sendpatchset@oc5400248562.ibm.com>
x-cbid: 11113008-6148-0000-0000-000001A2198F
X-Mailman-Approved-At: Thu, 01 Dec 2011 10:36:45 +0000
Cc: Peter Zijlstra <peterz@infradead.org>,
	Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Dave Hansen <dave@linux.vnet.ibm.com>,
	Suzuki Poulose <suzuki@linux.vnet.ibm.com>,
	Sasha Levin <levinsasha928@gmail.com>
Subject: [Xen-devel] [PATCH RFC V3 1/4] debugfs: Add support to print u32
	array in debugfs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Add debugfs support to print u32-arrays in debugfs. Move the code from Xen to debugfs
to make the code common for other users as well.

Signed-off-by: Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>
Signed-off-by: Suzuki Poulose <suzuki@in.ibm.com>
Signed-off-by: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
---
diff --git a/arch/x86/xen/debugfs.c b/arch/x86/xen/debugfs.c
index 7c0fedd..c8377fb 100644
--- a/arch/x86/xen/debugfs.c
+++ b/arch/x86/xen/debugfs.c
@@ -19,107 +19,3 @@ struct dentry * __init xen_init_debugfs(void)
 	return d_xen_debug;
 }
 
-struct array_data
-{
-	void *array;
-	unsigned elements;
-};
-
-static int u32_array_open(struct inode *inode, struct file *file)
-{
-	file->private_data = NULL;
-	return nonseekable_open(inode, file);
-}
-
-static size_t format_array(char *buf, size_t bufsize, const char *fmt,
-			   u32 *array, unsigned array_size)
-{
-	size_t ret = 0;
-	unsigned i;
-
-	for(i = 0; i < array_size; i++) {
-		size_t len;
-
-		len = snprintf(buf, bufsize, fmt, array[i]);
-		len++;	/* ' ' or '\n' */
-		ret += len;
-
-		if (buf) {
-			buf += len;
-			bufsize -= len;
-			buf[-1] = (i == array_size-1) ? '\n' : ' ';
-		}
-	}
-
-	ret++;		/* \0 */
-	if (buf)
-		*buf = '\0';
-
-	return ret;
-}
-
-static char *format_array_alloc(const char *fmt, u32 *array, unsigned array_size)
-{
-	size_t len = format_array(NULL, 0, fmt, array, array_size);
-	char *ret;
-
-	ret = kmalloc(len, GFP_KERNEL);
-	if (ret == NULL)
-		return NULL;
-
-	format_array(ret, len, fmt, array, array_size);
-	return ret;
-}
-
-static ssize_t u32_array_read(struct file *file, char __user *buf, size_t len,
-			      loff_t *ppos)
-{
-	struct inode *inode = file->f_path.dentry->d_inode;
-	struct array_data *data = inode->i_private;
-	size_t size;
-
-	if (*ppos == 0) {
-		if (file->private_data) {
-			kfree(file->private_data);
-			file->private_data = NULL;
-		}
-
-		file->private_data = format_array_alloc("%u", data->array, data->elements);
-	}
-
-	size = 0;
-	if (file->private_data)
-		size = strlen(file->private_data);
-
-	return simple_read_from_buffer(buf, len, ppos, file->private_data, size);
-}
-
-static int xen_array_release(struct inode *inode, struct file *file)
-{
-	kfree(file->private_data);
-
-	return 0;
-}
-
-static const struct file_operations u32_array_fops = {
-	.owner	= THIS_MODULE,
-	.open	= u32_array_open,
-	.release= xen_array_release,
-	.read	= u32_array_read,
-	.llseek = no_llseek,
-};
-
-struct dentry *xen_debugfs_create_u32_array(const char *name, mode_t mode,
-					    struct dentry *parent,
-					    u32 *array, unsigned elements)
-{
-	struct array_data *data = kmalloc(sizeof(*data), GFP_KERNEL);
-
-	if (data == NULL)
-		return NULL;
-
-	data->array = array;
-	data->elements = elements;
-
-	return debugfs_create_file(name, mode, parent, data, &u32_array_fops);
-}
diff --git a/arch/x86/xen/debugfs.h b/arch/x86/xen/debugfs.h
index e281320..12ebf33 100644
--- a/arch/x86/xen/debugfs.h
+++ b/arch/x86/xen/debugfs.h
@@ -3,8 +3,4 @@
 
 struct dentry * __init xen_init_debugfs(void);
 
-struct dentry *xen_debugfs_create_u32_array(const char *name, mode_t mode,
-					    struct dentry *parent,
-					    u32 *array, unsigned elements);
-
 #endif /* _XEN_DEBUGFS_H */
diff --git a/arch/x86/xen/spinlock.c b/arch/x86/xen/spinlock.c
index fc506e6..14a8961 100644
--- a/arch/x86/xen/spinlock.c
+++ b/arch/x86/xen/spinlock.c
@@ -286,7 +286,7 @@ static int __init xen_spinlock_debugfs(void)
 	debugfs_create_u64("time_blocked", 0444, d_spin_debug,
 			   &spinlock_stats.time_blocked);
 
-	xen_debugfs_create_u32_array("histo_blocked", 0444, d_spin_debug,
+	debugfs_create_u32_array("histo_blocked", 0444, d_spin_debug,
 				     spinlock_stats.histo_spin_blocked, HISTO_BUCKETS + 1);
 
 	return 0;
diff --git a/fs/debugfs/file.c b/fs/debugfs/file.c
index 90f7657..df44ccf 100644
--- a/fs/debugfs/file.c
+++ b/fs/debugfs/file.c
@@ -18,6 +18,7 @@
 #include <linux/pagemap.h>
 #include <linux/namei.h>
 #include <linux/debugfs.h>
+#include <linux/slab.h>
 
 static ssize_t default_read_file(struct file *file, char __user *buf,
 				 size_t count, loff_t *ppos)
@@ -525,3 +526,130 @@ struct dentry *debugfs_create_blob(const char *name, mode_t mode,
 	return debugfs_create_file(name, mode, parent, blob, &fops_blob);
 }
 EXPORT_SYMBOL_GPL(debugfs_create_blob);
+
+struct array_data {
+	void *array;
+	u32 elements;
+};
+
+static int u32_array_open(struct inode *inode, struct file *file)
+{
+	file->private_data = NULL;
+	return nonseekable_open(inode, file);
+}
+
+static size_t format_array(char *buf, size_t bufsize, const char *fmt,
+			   u32 *array, u32 array_size)
+{
+	size_t ret = 0;
+	u32 i;
+
+	for (i = 0; i < array_size; i++) {
+		size_t len;
+
+		len = snprintf(buf, bufsize, fmt, array[i]);
+		len++;	/* ' ' or '\n' */
+		ret += len;
+
+		if (buf) {
+			buf += len;
+			bufsize -= len;
+			buf[-1] = (i == array_size-1) ? '\n' : ' ';
+		}
+	}
+
+	ret++;		/* \0 */
+	if (buf)
+		*buf = '\0';
+
+	return ret;
+}
+
+static char *format_array_alloc(const char *fmt, u32 *array,
+						u32 array_size)
+{
+	size_t len = format_array(NULL, 0, fmt, array, array_size);
+	char *ret;
+
+	ret = kmalloc(len, GFP_KERNEL);
+	if (ret == NULL)
+		return NULL;
+
+	format_array(ret, len, fmt, array, array_size);
+	return ret;
+}
+
+static ssize_t u32_array_read(struct file *file, char __user *buf, size_t len,
+			      loff_t *ppos)
+{
+	struct inode *inode = file->f_path.dentry->d_inode;
+	struct array_data *data = inode->i_private;
+	size_t size;
+
+	if (*ppos == 0) {
+		if (file->private_data) {
+			kfree(file->private_data);
+			file->private_data = NULL;
+		}
+
+		file->private_data = format_array_alloc("%u", data->array,
+							      data->elements);
+	}
+
+	size = 0;
+	if (file->private_data)
+		size = strlen(file->private_data);
+
+	return simple_read_from_buffer(buf, len, ppos,
+					file->private_data, size);
+}
+
+static int u32_array_release(struct inode *inode, struct file *file)
+{
+	kfree(file->private_data);
+
+	return 0;
+}
+
+static const struct file_operations u32_array_fops = {
+	.owner	 = THIS_MODULE,
+	.open	 = u32_array_open,
+	.release = u32_array_release,
+	.read	 = u32_array_read,
+	.llseek  = no_llseek,
+};
+
+/**
+ * debugfs_create_u32_array - create a debugfs file that is used to read u32
+ * array.
+ * @name: a pointer to a string containing the name of the file to create.
+ * @mode: the permission that the file should have.
+ * @parent: a pointer to the parent dentry for this file.  This should be a
+ *          directory dentry if set.  If this parameter is %NULL, then the
+ *          file will be created in the root of the debugfs filesystem.
+ * @array: u32 array that provides data.
+ * @elements: total number of elements in the array.
+ *
+ * This function creates a file in debugfs with the given name that exports
+ * @array as data. If the @mode variable is so set it can be read from.
+ * Writing is not supported. Seek within the file is also not supported.
+ * Once array is created its size can not be changed.
+ *
+ * The function returns a pointer to dentry on success. If debugfs is not
+ * enabled in the kernel, the value -%ENODEV will be returned.
+ */
+struct dentry *debugfs_create_u32_array(const char *name, mode_t mode,
+					    struct dentry *parent,
+					    u32 *array, u32 elements)
+{
+	struct array_data *data = kmalloc(sizeof(*data), GFP_KERNEL);
+
+	if (data == NULL)
+		return NULL;
+
+	data->array = array;
+	data->elements = elements;
+
+	return debugfs_create_file(name, mode, parent, data, &u32_array_fops);
+}
+EXPORT_SYMBOL_GPL(debugfs_create_u32_array);
diff --git a/include/linux/debugfs.h b/include/linux/debugfs.h
index e7d9b20..253e2fb 100644
--- a/include/linux/debugfs.h
+++ b/include/linux/debugfs.h
@@ -74,6 +74,10 @@ struct dentry *debugfs_create_blob(const char *name, mode_t mode,
 				  struct dentry *parent,
 				  struct debugfs_blob_wrapper *blob);
 
+struct dentry *debugfs_create_u32_array(const char *name, mode_t mode,
+					struct dentry *parent,
+					u32 *array, u32 elements);
+
 bool debugfs_initialized(void);
 
 #else
@@ -193,6 +197,13 @@ static inline bool debugfs_initialized(void)
 	return false;
 }
 
+struct dentry *debugfs_create_u32_array(const char *name, mode_t mode,
+					struct dentry *parent,
+					u32 *array, u32 elements)
+{
+	return ERR_PTR(-ENODEV);
+}
+
 #endif
 
 #endif


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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 10:36:55 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 10:36:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW40W-0004kl-By; Thu, 01 Dec 2011 10:36:48 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <techtonik@gmail.com>) id 1RVRts-0000i1-Lv
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 17:55:24 +0000
X-Env-Sender: techtonik@gmail.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1322589285!5183708!1
X-Originating-IP: [209.85.160.171]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14357 invoked from network); 29 Nov 2011 17:54:46 -0000
Received: from mail-gy0-f171.google.com (HELO mail-gy0-f171.google.com)
	(209.85.160.171)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 17:54:46 -0000
Received: by ghbz2 with SMTP id z2so10850425ghb.30
	for <xen-devel@lists.xensource.com>;
	Tue, 29 Nov 2011 09:54:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:content-type; bh=3b1uXDRnFA22JNUbgBXmzteTO9CQRqN4hyFz59WFwnQ=;
	b=KEMM1Bw/tVsuMhAzrfChRg8TMKD+aQp8EAuhG8yHQrEyt/r4Zu+GsKzOJB/nzc8Gzb
	7UYG0Q/DmYEfVvpe5tQ+TLPdyJQMo35ZD9oHgznThX5D/wcL6g+WAhrfHJYZ7mHF17a/
	SUnuuIrMD45oSCc5sS4l9c6Ppe+Kz6O9tYIfM=
Received: by 10.100.207.3 with SMTP id e3mr3073877ang.46.1322589285480; Tue,
	29 Nov 2011 09:54:45 -0800 (PST)
MIME-Version: 1.0
Received: by 10.100.40.19 with HTTP; Tue, 29 Nov 2011 09:54:24 -0800 (PST)
In-Reply-To: <CAPkN8xKwAsrF_ZuXWAF2uMVDYTbGwpSsvG+YfjrLfpf-oxqwJQ@mail.gmail.com>
References: <CAPkN8xKwAsrF_ZuXWAF2uMVDYTbGwpSsvG+YfjrLfpf-oxqwJQ@mail.gmail.com>
From: anatoly techtonik <techtonik@gmail.com>
Date: Tue, 29 Nov 2011 20:54:24 +0300
Message-ID: <CAPkN8xLX83Uxbo4UDWG2mmYctAQbwRcw3BJWzack8JZgQAg9nw@mail.gmail.com>
To: xen-devel@lists.xensource.com
X-Mailman-Approved-At: Thu, 01 Dec 2011 10:36:45 +0000
Subject: [Xen-devel] Low memory corruption - trap invalid opcode
 ip:7f5c688028b0 sp:7ffff97af848 error:0 in ld-2.11.2.so[7f5c687ef000+1e000]
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============8133032184147072677=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============8133032184147072677==
Content-Type: multipart/alternative; boundary=0016369205078b798904b2e35002

--0016369205078b798904b2e35002
Content-Type: text/plain; charset=UTF-8

My first message didn't get to the list, so I am trying once more.

---------- Forwarded message ----------
From: anatoly techtonik <techtonik@gmail.com>
Date: Mon, Nov 14, 2011 at 5:46 PM
Subject: Low memory corruption - trap invalid opcode ip:7f5c688028b0
sp:7ffff97af848 error:0 in ld-2.11.2.so[7f5c687ef000+1e000]
To: xen-devel@lists.xensource.com


I was redirected here from this bug report in Debian against
'svn-buildpackage' after I started getting 'Illegal instruction' error
after running 'svn-inject' and similar command on a brand new VM
instance for Debian Squeeze.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=646945#54

dmesg from VM
17067.210187] svn-inject[6026] trap invalid opcode ip:7f5c688028b0
sp:7ffff97af848 error:0 in ld-2.11.2.so[7f5c687ef000+1e000]


I am running Debian Squeeze 6.0.3 with this package:
Package: xen-hypervisor-4.0-amd64
State: installed
Version: 4.0.1-4

Guest is Debian Squeeze 6.0.3 as well.


How to fix my machine? Reinstallation doesn't help.


P.S. http://wiki.xen.org/wiki/ReportingBugs says to look for more info
in "Host console output (perhaps including hypervisor debug key
output)", but doesn't explain how to get into this console
P.P.S. But reporting link on http://www.xen.org/support/community.html is
broken

Please, CC.
--
anatoly t.

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

My first message didn&#39;t get to the list, so I am trying once more.<div>=
<br><div class=3D"gmail_quote">---------- Forwarded message ----------<br>F=
rom: <b class=3D"gmail_sendername">anatoly techtonik</b> <span dir=3D"ltr">=
&lt;<a href=3D"mailto:techtonik@gmail.com">techtonik@gmail.com</a>&gt;</spa=
n><br>

Date: Mon, Nov 14, 2011 at 5:46 PM<br>Subject: Low memory corruption - trap=
 invalid opcode ip:7f5c688028b0 sp:7ffff97af848 error:0 in <a href=3D"http:=
//ld-2.11.2.so">ld-2.11.2.so</a>[7f5c687ef000+1e000]<br>To: <a href=3D"mail=
to:xen-devel@lists.xensource.com">xen-devel@lists.xensource.com</a><br>

<br><br>I was redirected here from this bug report in Debian against<br>
&#39;svn-buildpackage&#39; after I started getting &#39;Illegal instruction=
&#39; error<br>
after running &#39;svn-inject&#39; and similar command on a brand new VM<br=
>
instance for Debian Squeeze.<br>
<a href=3D"http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=3D646945#54" ta=
rget=3D"_blank">http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=3D646945#5=
4</a><br>
<br>
dmesg from VM<br>
<a href=3D"tel:17067.210187" value=3D"+17067210187">17067.210187</a>] svn-i=
nject[6026] trap invalid opcode ip:7f5c688028b0<br>
sp:7ffff97af848 error:0 in <a href=3D"http://ld-2.11.2.so" target=3D"_blank=
">ld-2.11.2.so</a>[7f5c687ef000+1e000]<br>
<br>
<br>
I am running Debian Squeeze 6.0.3 with this package:<br>
Package: xen-hypervisor-4.0-amd64<br>
State: installed<br>
Version: 4.0.1-4<br>
<br>
Guest is Debian Squeeze 6.0.3 as well.<br>
<br>
<br>
How to fix my machine? Reinstallation doesn&#39;t help.<br>
<br>
<br>
P.S. <a href=3D"http://wiki.xen.org/wiki/ReportingBugs" target=3D"_blank">h=
ttp://wiki.xen.org/wiki/ReportingBugs</a> says to look for more info<br>
in &quot;Host console output (perhaps including hypervisor debug key<br>
output)&quot;, but doesn&#39;t explain how to get into this console<br>
P.P.S. But reporting link on <a href=3D"http://www.xen.org/support/communit=
y.html" target=3D"_blank">http://www.xen.org/support/community.html</a> is =
broken<br>
<br>
Please, CC.<br>
<span class=3D"HOEnZb"><font color=3D"#888888">--<br>
anatoly t.<br>
</font></span></div><br></div>

--0016369205078b798904b2e35002--


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

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

--===============8133032184147072677==--


From xen-devel-bounces@lists.xensource.com Thu Dec 01 10:36:55 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 10:36:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW40X-0004lj-Lb; Thu, 01 Dec 2011 10:36:49 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <s.seira@cdmon.com>) id 1RVfB7-0007Sk-Lg
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 08:06:05 +0000
X-Env-Sender: s.seira@cdmon.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1322640327!5244717!1
X-Originating-IP: [212.36.82.9]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4838 invoked from network); 30 Nov 2011 08:05:27 -0000
Received: from correo.cdmon.com (HELO correo.cdmon.com) (212.36.82.9)
	by server-2.tower-182.messagelabs.com with SMTP;
	30 Nov 2011 08:05:27 -0000
Received: from genocida (localhost.cdmon.com [127.0.0.1])
	by correo.cdmon.com (Postfix) with ESMTP id 5B803131556
	for <xen-devel@lists.xensource.com>;
	Wed, 30 Nov 2011 09:04:49 +0100 (CET)
Received: from antispam (localhost.cdmon.com [127.0.0.1])
	by correo.cdmon.com (Postfix) with ESMTP id 126E9131550
	for <xen-devel@lists.xensource.com>;
	Wed, 30 Nov 2011 09:04:49 +0100 (CET)
Received: from [192.168.0.30] (214.180.216.87.static.jazztel.es
	[87.216.180.214])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by correo.cdmon.com (Postfix) with ESMTP id A60AC131545
	for <xen-devel@lists.xensource.com>;
	Wed, 30 Nov 2011 09:04:48 +0100 (CET)
Message-ID: <4ED5FFBC.3080605@cdmon.com>
Date: Wed, 30 Nov 2011 11:04:44 +0100
From: Sergi Seira <s.seira@cdmon.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:8.0) Gecko/20111108 Thunderbird/8.0
MIME-Version: 1.0
To: xen-devel@lists.xensource.com
X-Enigmail-Version: 1.3.3
X-Mailman-Approved-At: Thu, 01 Dec 2011 10:36:45 +0000
Subject: [Xen-devel] ext4_mb_generate_buddy remounting read-only on domU
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

has anyone had ext4 filesystem remounting hours after a live-migration?

We've been having those 'read only remounts' always hours after a live-migration.
The more load a domU has the faster we get 'read only remount'.
We are suspecting something is getting corrupted after a live migration, and under load an error bumps:

 kernel: [3424760.190005] EXT4-fs error (device xvda3): ext4_mb_generate_buddy: EXT4-fs: group 55: 6102 blocks in bitmap, 6101 in gd
 kernel: [3424760.190059] Aborting journal on device xvda3-8.
 kernel: [3424760.191197] EXT4-fs (xvda3): Remounting filesystem read-only
 kernel: [3424760.204396] EXT4-fs (xvda3): delayed block allocation failed for inode 374665 at logical offset 318 with max blocks 1 with error -30
 kernel: [3424760.204447] This should not happen!!  Data will be lost
 kernel: [3424760.204483] EXT4-fs (xvda3): ext4_da_writepages: jbd2_start: 1015 pages, ino 374665; err -30

We have to fsck the volume from dom0 before re-creating domU.

Our system runs on :

 dom0 debian6 2.6.32-5-xen-amd64
 xen-hypervisor 4.0.1-2

DomU are:

 domU paravirtual debian6 2.6.32-5-xen-amd64
 3 iscsi volumes act as vxda's, swap, root and home (400G)
 7 vcpus
 8 GB RAM

Regards,
Sergi
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJO1f+8AAoJEN00VGSIizZ0zVIH/0KLyFgLAwJNmtXVbHo0VcsY
IicYbcv5CJNkJZ/WDskPK/33HsWH98epWzsRbr33qAibZrKfJig/1HuHs8SwGwGe
Xt1ii9+gnhy/oyNSnPbgmDpD6W81iEPkCTLm0fdHmndP9E5dbIWOzCMcIMvFB0RD
+2bPKQ3CcKEqnbXcriYzKVdfU2Y4/UbgZJYCQBJizK20A9KbqwAyLve/zRxJ7WP8
Q7+zWXkxefwcVq9rcBfkITvlrLQw9b9kK1KT7+7MrnxkG0ujIFYKVqkBxuIb4C3u
kILnz8Gh6vuiKhHy+5DKqEpGmhSsq/VVymLQCNerveluer2TF9QOTisv2kXw58Y=
=+hQj
-----END PGP SIGNATURE-----

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 10:36:55 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 10:36:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW40Y-0004mc-TX; Thu, 01 Dec 2011 10:36:50 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raghavendra.kt@linux.vnet.ibm.com>)
	id 1RVg2P-0007ge-US
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 09:01:10 +0000
X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1322643630!5597976!1
X-Originating-IP: [32.97.182.146]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMzIuOTcuMTgyLjE0NiA9PiA1MDU3NDY=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6893 invoked from network); 30 Nov 2011 09:00:31 -0000
Received: from e6.ny.us.ibm.com (HELO e6.ny.us.ibm.com) (32.97.182.146)
	by server-12.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 30 Nov 2011 09:00:31 -0000
Received: from /spool/local
	by e6.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only!
	Violators will be prosecuted for <xen-devel@lists.xensource.com> from
	<raghavendra.kt@linux.vnet.ibm.com>; Wed, 30 Nov 2011 04:00:29 -0500
Received: from d01relay03.pok.ibm.com ([9.56.227.235])
	by e6.ny.us.ibm.com ([192.168.1.106]) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Wed, 30 Nov 2011 04:00:28 -0500
Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64])
	by d01relay03.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	pAU90RAl314490
	for <xen-devel@lists.xensource.com>; Wed, 30 Nov 2011 04:00:27 -0500
Received: from d01av04.pok.ibm.com (loopback [127.0.0.1])
	by d01av04.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id
	pAU90PrG000336
	for <xen-devel@lists.xensource.com>; Wed, 30 Nov 2011 04:00:27 -0500
Received: from oc5400248562.ibm.com (oc5400248562.in.ibm.com [9.124.158.199])
	by d01av04.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	pAU90GBB031541; Wed, 30 Nov 2011 04:00:17 -0500
From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
To: Greg Kroah-Hartman <gregkh@suse.de>, "H. Peter Anvin" <hpa@zytor.com>,
	Gleb Natapov <gleb@redhat.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>, x86@kernel.org,
	KVM <kvm@vger.kernel.org>, Dave Jiang <dave.jiang@intel.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Xen <xen-devel@lists.xensource.com>,
	Sedat Dilek <sedat.dilek@gmail.com>, Yinghai Lu <yinghai@kernel.org>,
	Marcelo Tosatti <mtosatti@redhat.com>, Ingo Molnar <mingo@redhat.com>, 
	Avi Kivity <avi@redhat.com>, Rik van Riel <riel@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	LKML <linux-kernel@vger.kernel.org>
Date: Wed, 30 Nov 2011 14:30:19 +0530
Message-Id: <20111130090019.23386.95844.sendpatchset@oc5400248562.ibm.com>
In-Reply-To: <20111130085921.23386.89708.sendpatchset@oc5400248562.ibm.com>
References: <20111130085921.23386.89708.sendpatchset@oc5400248562.ibm.com>
x-cbid: 11113009-1976-0000-0000-000008146076
X-Mailman-Approved-At: Thu, 01 Dec 2011 10:36:45 +0000
Cc: Peter Zijlstra <peterz@infradead.org>,
	Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Dave Hansen <dave@linux.vnet.ibm.com>,
	Suzuki Poulose <suzuki@linux.vnet.ibm.com>,
	Sasha Levin <levinsasha928@gmail.com>
Subject: [Xen-devel] [PATCH RFC V3 3/4] kvm guest : Added configuration
	support to enable debug information for KVM Guests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Added configuration support to enable debug information
for KVM Guests in debugfs
    
Signed-off-by: Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>
Signed-off-by: Suzuki Poulose <suzuki@in.ibm.com>
Signed-off-by: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
---
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 5d8152d..526e3ae 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -561,6 +561,15 @@ config KVM_GUEST
 	  This option enables various optimizations for running under the KVM
 	  hypervisor.
 
+config KVM_DEBUG_FS
+	bool "Enable debug information for KVM Guests in debugfs"
+	depends on KVM_GUEST && DEBUG_FS
+	default n
+	---help---
+	  This option enables collection of various statistics for KVM guest.
+   	  Statistics are displayed in debugfs filesystem. Enabling this option
+	  may incur significant overhead.
+
 source "arch/x86/lguest/Kconfig"
 
 config PARAVIRT


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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 10:36:55 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 10:36:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW40X-0004lj-Lb; Thu, 01 Dec 2011 10:36:49 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <s.seira@cdmon.com>) id 1RVfB7-0007Sk-Lg
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 08:06:05 +0000
X-Env-Sender: s.seira@cdmon.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1322640327!5244717!1
X-Originating-IP: [212.36.82.9]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4838 invoked from network); 30 Nov 2011 08:05:27 -0000
Received: from correo.cdmon.com (HELO correo.cdmon.com) (212.36.82.9)
	by server-2.tower-182.messagelabs.com with SMTP;
	30 Nov 2011 08:05:27 -0000
Received: from genocida (localhost.cdmon.com [127.0.0.1])
	by correo.cdmon.com (Postfix) with ESMTP id 5B803131556
	for <xen-devel@lists.xensource.com>;
	Wed, 30 Nov 2011 09:04:49 +0100 (CET)
Received: from antispam (localhost.cdmon.com [127.0.0.1])
	by correo.cdmon.com (Postfix) with ESMTP id 126E9131550
	for <xen-devel@lists.xensource.com>;
	Wed, 30 Nov 2011 09:04:49 +0100 (CET)
Received: from [192.168.0.30] (214.180.216.87.static.jazztel.es
	[87.216.180.214])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by correo.cdmon.com (Postfix) with ESMTP id A60AC131545
	for <xen-devel@lists.xensource.com>;
	Wed, 30 Nov 2011 09:04:48 +0100 (CET)
Message-ID: <4ED5FFBC.3080605@cdmon.com>
Date: Wed, 30 Nov 2011 11:04:44 +0100
From: Sergi Seira <s.seira@cdmon.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:8.0) Gecko/20111108 Thunderbird/8.0
MIME-Version: 1.0
To: xen-devel@lists.xensource.com
X-Enigmail-Version: 1.3.3
X-Mailman-Approved-At: Thu, 01 Dec 2011 10:36:45 +0000
Subject: [Xen-devel] ext4_mb_generate_buddy remounting read-only on domU
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

has anyone had ext4 filesystem remounting hours after a live-migration?

We've been having those 'read only remounts' always hours after a live-migration.
The more load a domU has the faster we get 'read only remount'.
We are suspecting something is getting corrupted after a live migration, and under load an error bumps:

 kernel: [3424760.190005] EXT4-fs error (device xvda3): ext4_mb_generate_buddy: EXT4-fs: group 55: 6102 blocks in bitmap, 6101 in gd
 kernel: [3424760.190059] Aborting journal on device xvda3-8.
 kernel: [3424760.191197] EXT4-fs (xvda3): Remounting filesystem read-only
 kernel: [3424760.204396] EXT4-fs (xvda3): delayed block allocation failed for inode 374665 at logical offset 318 with max blocks 1 with error -30
 kernel: [3424760.204447] This should not happen!!  Data will be lost
 kernel: [3424760.204483] EXT4-fs (xvda3): ext4_da_writepages: jbd2_start: 1015 pages, ino 374665; err -30

We have to fsck the volume from dom0 before re-creating domU.

Our system runs on :

 dom0 debian6 2.6.32-5-xen-amd64
 xen-hypervisor 4.0.1-2

DomU are:

 domU paravirtual debian6 2.6.32-5-xen-amd64
 3 iscsi volumes act as vxda's, swap, root and home (400G)
 7 vcpus
 8 GB RAM

Regards,
Sergi
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJO1f+8AAoJEN00VGSIizZ0zVIH/0KLyFgLAwJNmtXVbHo0VcsY
IicYbcv5CJNkJZ/WDskPK/33HsWH98epWzsRbr33qAibZrKfJig/1HuHs8SwGwGe
Xt1ii9+gnhy/oyNSnPbgmDpD6W81iEPkCTLm0fdHmndP9E5dbIWOzCMcIMvFB0RD
+2bPKQ3CcKEqnbXcriYzKVdfU2Y4/UbgZJYCQBJizK20A9KbqwAyLve/zRxJ7WP8
Q7+zWXkxefwcVq9rcBfkITvlrLQw9b9kK1KT7+7MrnxkG0ujIFYKVqkBxuIb4C3u
kILnz8Gh6vuiKhHy+5DKqEpGmhSsq/VVymLQCNerveluer2TF9QOTisv2kXw58Y=
=+hQj
-----END PGP SIGNATURE-----

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 10:36:55 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 10:36:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW40a-0004o3-FS; Thu, 01 Dec 2011 10:36:52 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <pawel.moll@arm.com>) id 1RVlWC-0000yD-5J
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 14:52:16 +0000
X-Env-Sender: pawel.moll@arm.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1322664697!3705717!1
X-Originating-IP: [91.220.42.44]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogOTEuMjIwLjQyLjQ0ID0+IDEzNDYwNw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11300 invoked from network); 30 Nov 2011 14:51:37 -0000
Received: from service87.mimecast.com (HELO service87.mimecast.com)
	(91.220.42.44) by server-4.tower-174.messagelabs.com with SMTP;
	30 Nov 2011 14:51:37 -0000
Received: from cam-owa2.Emea.Arm.com (fw-tnat.cambridge.arm.com
	[217.140.96.21]) by service87.mimecast.com;
	Wed, 30 Nov 2011 14:51:32 +0000
Received: from [10.1.206.166] ([10.1.255.212]) by cam-owa2.Emea.Arm.com with
	Microsoft SMTPSVC(6.0.3790.3959); Wed, 30 Nov 2011 14:51:28 +0000
From: Pawel Moll <pawel.moll@arm.com>
To: Arnd Bergmann <arnd@arndb.de>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
In-Reply-To: <201111301432.54463.arnd@arndb.de>
References: <alpine.DEB.2.00.1111281009090.31179@kaball-desktop>
	<201111301303.23851.arnd@arndb.de>
	<1322659535.31810.97.camel@zakaz.uk.xensource.com>
	<201111301432.54463.arnd@arndb.de>
Date: Wed, 30 Nov 2011 14:51:28 +0000
Message-ID: <1322664688.3180.6.camel@hornet.cambridge.arm.com>
Mime-Version: 1.0
X-Mailer: Evolution 2.28.1
X-OriginalArrivalTime: 30 Nov 2011 14:51:28.0933 (UTC)
	FILETIME=[8AA6F550:01CCAF6F]
X-MC-Unique: 111113014513206201
X-Mailman-Approved-At: Thu, 01 Dec 2011 10:36:45 +0000
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linaro-dev@lists.linaro.org" <linaro-dev@lists.linaro.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"virtualization@lists.linux-foundation.org"
	<virtualization@lists.linux-foundation.org>,
	"android-virt@lists.cs.columbia.edu" <android-virt@lists.cs.columbia.edu>,
	"embeddedxen-devel@lists.sourceforge.net"
	<embeddedxen-devel@lists.sourceforge.net>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [ANNOUNCE] Xen port to Cortex-A15 / ARMv7 with virt
 extensions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gV2VkLCAyMDExLTExLTMwIGF0IDE0OjMyICswMDAwLCBBcm5kIEJlcmdtYW5uIHdyb3RlOgo+
IEkgZG9uJ3QgY2FyZSBtdWNoIGVpdGhlciB3YXksIGJ1dCBJIHRoaW5rIGl0IHdvdWxkIGJlIGdv
b2QgdG8KPiB1c2Ugc2ltaWxhciBzb2x1dGlvbnMgYWNyb3NzIGFsbCBoeXBlcnZpc29ycy4gVGhl
IHR3byBvcHRpb25zCj4gdGhhdCBJJ3ZlIHNlZW4gZGlzY3Vzc2VkIGZvciBLVk0gd2VyZSB0byB1
c2UgZWl0aGVyIGEgdmlydHVhbCBQQ0kKPiBidXMgd2l0aCBpbmRpdmlkdWFsIHZpcnRpby1wY2kg
ZGV2aWNlcyBhcyBvbiB0aGUgUEMsIG9yIHRvCj4gdXNlIHRoZSBuZXcgdmlydGlvLW1taW8gZHJp
dmVyIGFuZCBpbmRpdmlkdWFsbHkgcHV0IHZpcnRpbyBkZXZpY2VzCj4gaW50byB0aGUgZGV2aWNl
IHRyZWUuCgpMZXQgbWUganVzdCBhZGQgdGhhdCB0aGUgdmlydGlvLW1taW8gZGV2aWNlcyBjYW4g
YWxyZWFkeSBiZSBpbnN0YW50aWF0ZWQKZnJvbSBEVCAoc2VlIERvY3VtZW50YXRpb24vZGV2aWNl
dHJlZS9iaW5kaW5ncy92aXJ0aW8vbW1pby50eHQpLgoKRm9yIEE5LWJhc2VkIFZFIEknZCBzdWdn
ZXN0IHBsYWNpbmcgdGhlbSBhcm91bmQgMHgxMDAxZTAwMCwgZWcuOgoKICAgICAgICB2aXJ0aW9f
YmxvY2tAMTAwMWUwMDAgewogICAgICAgICAgICAgICAgY29tcGF0aWJsZSA9ICJ2aXJ0aW8sbW1p
byI7CiAgICAgICAgICAgICAgICByZWcgPSA8MHgxMDAxZTAwMCAweDEwMD47CiAgICAgICAgICAg
ICAgICBpbnRlcnJ1cHRzID0gPDQxPjsKICAgICAgICB9CgpDaGVlcnMhCgpQYXdlxYIKCgoKX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1h
aWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuc291cmNlLmNvbQpodHRwOi8vbGlzdHMueGVu
c291cmNlLmNvbS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Thu Dec 01 10:36:55 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 10:36:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW40W-0004kl-By; Thu, 01 Dec 2011 10:36:48 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <techtonik@gmail.com>) id 1RVRts-0000i1-Lv
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 17:55:24 +0000
X-Env-Sender: techtonik@gmail.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1322589285!5183708!1
X-Originating-IP: [209.85.160.171]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14357 invoked from network); 29 Nov 2011 17:54:46 -0000
Received: from mail-gy0-f171.google.com (HELO mail-gy0-f171.google.com)
	(209.85.160.171)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 17:54:46 -0000
Received: by ghbz2 with SMTP id z2so10850425ghb.30
	for <xen-devel@lists.xensource.com>;
	Tue, 29 Nov 2011 09:54:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:content-type; bh=3b1uXDRnFA22JNUbgBXmzteTO9CQRqN4hyFz59WFwnQ=;
	b=KEMM1Bw/tVsuMhAzrfChRg8TMKD+aQp8EAuhG8yHQrEyt/r4Zu+GsKzOJB/nzc8Gzb
	7UYG0Q/DmYEfVvpe5tQ+TLPdyJQMo35ZD9oHgznThX5D/wcL6g+WAhrfHJYZ7mHF17a/
	SUnuuIrMD45oSCc5sS4l9c6Ppe+Kz6O9tYIfM=
Received: by 10.100.207.3 with SMTP id e3mr3073877ang.46.1322589285480; Tue,
	29 Nov 2011 09:54:45 -0800 (PST)
MIME-Version: 1.0
Received: by 10.100.40.19 with HTTP; Tue, 29 Nov 2011 09:54:24 -0800 (PST)
In-Reply-To: <CAPkN8xKwAsrF_ZuXWAF2uMVDYTbGwpSsvG+YfjrLfpf-oxqwJQ@mail.gmail.com>
References: <CAPkN8xKwAsrF_ZuXWAF2uMVDYTbGwpSsvG+YfjrLfpf-oxqwJQ@mail.gmail.com>
From: anatoly techtonik <techtonik@gmail.com>
Date: Tue, 29 Nov 2011 20:54:24 +0300
Message-ID: <CAPkN8xLX83Uxbo4UDWG2mmYctAQbwRcw3BJWzack8JZgQAg9nw@mail.gmail.com>
To: xen-devel@lists.xensource.com
X-Mailman-Approved-At: Thu, 01 Dec 2011 10:36:45 +0000
Subject: [Xen-devel] Low memory corruption - trap invalid opcode
 ip:7f5c688028b0 sp:7ffff97af848 error:0 in ld-2.11.2.so[7f5c687ef000+1e000]
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============8133032184147072677=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============8133032184147072677==
Content-Type: multipart/alternative; boundary=0016369205078b798904b2e35002

--0016369205078b798904b2e35002
Content-Type: text/plain; charset=UTF-8

My first message didn't get to the list, so I am trying once more.

---------- Forwarded message ----------
From: anatoly techtonik <techtonik@gmail.com>
Date: Mon, Nov 14, 2011 at 5:46 PM
Subject: Low memory corruption - trap invalid opcode ip:7f5c688028b0
sp:7ffff97af848 error:0 in ld-2.11.2.so[7f5c687ef000+1e000]
To: xen-devel@lists.xensource.com


I was redirected here from this bug report in Debian against
'svn-buildpackage' after I started getting 'Illegal instruction' error
after running 'svn-inject' and similar command on a brand new VM
instance for Debian Squeeze.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=646945#54

dmesg from VM
17067.210187] svn-inject[6026] trap invalid opcode ip:7f5c688028b0
sp:7ffff97af848 error:0 in ld-2.11.2.so[7f5c687ef000+1e000]


I am running Debian Squeeze 6.0.3 with this package:
Package: xen-hypervisor-4.0-amd64
State: installed
Version: 4.0.1-4

Guest is Debian Squeeze 6.0.3 as well.


How to fix my machine? Reinstallation doesn't help.


P.S. http://wiki.xen.org/wiki/ReportingBugs says to look for more info
in "Host console output (perhaps including hypervisor debug key
output)", but doesn't explain how to get into this console
P.P.S. But reporting link on http://www.xen.org/support/community.html is
broken

Please, CC.
--
anatoly t.

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

My first message didn&#39;t get to the list, so I am trying once more.<div>=
<br><div class=3D"gmail_quote">---------- Forwarded message ----------<br>F=
rom: <b class=3D"gmail_sendername">anatoly techtonik</b> <span dir=3D"ltr">=
&lt;<a href=3D"mailto:techtonik@gmail.com">techtonik@gmail.com</a>&gt;</spa=
n><br>

Date: Mon, Nov 14, 2011 at 5:46 PM<br>Subject: Low memory corruption - trap=
 invalid opcode ip:7f5c688028b0 sp:7ffff97af848 error:0 in <a href=3D"http:=
//ld-2.11.2.so">ld-2.11.2.so</a>[7f5c687ef000+1e000]<br>To: <a href=3D"mail=
to:xen-devel@lists.xensource.com">xen-devel@lists.xensource.com</a><br>

<br><br>I was redirected here from this bug report in Debian against<br>
&#39;svn-buildpackage&#39; after I started getting &#39;Illegal instruction=
&#39; error<br>
after running &#39;svn-inject&#39; and similar command on a brand new VM<br=
>
instance for Debian Squeeze.<br>
<a href=3D"http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=3D646945#54" ta=
rget=3D"_blank">http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=3D646945#5=
4</a><br>
<br>
dmesg from VM<br>
<a href=3D"tel:17067.210187" value=3D"+17067210187">17067.210187</a>] svn-i=
nject[6026] trap invalid opcode ip:7f5c688028b0<br>
sp:7ffff97af848 error:0 in <a href=3D"http://ld-2.11.2.so" target=3D"_blank=
">ld-2.11.2.so</a>[7f5c687ef000+1e000]<br>
<br>
<br>
I am running Debian Squeeze 6.0.3 with this package:<br>
Package: xen-hypervisor-4.0-amd64<br>
State: installed<br>
Version: 4.0.1-4<br>
<br>
Guest is Debian Squeeze 6.0.3 as well.<br>
<br>
<br>
How to fix my machine? Reinstallation doesn&#39;t help.<br>
<br>
<br>
P.S. <a href=3D"http://wiki.xen.org/wiki/ReportingBugs" target=3D"_blank">h=
ttp://wiki.xen.org/wiki/ReportingBugs</a> says to look for more info<br>
in &quot;Host console output (perhaps including hypervisor debug key<br>
output)&quot;, but doesn&#39;t explain how to get into this console<br>
P.P.S. But reporting link on <a href=3D"http://www.xen.org/support/communit=
y.html" target=3D"_blank">http://www.xen.org/support/community.html</a> is =
broken<br>
<br>
Please, CC.<br>
<span class=3D"HOEnZb"><font color=3D"#888888">--<br>
anatoly t.<br>
</font></span></div><br></div>

--0016369205078b798904b2e35002--


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

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

--===============8133032184147072677==--


From xen-devel-bounces@lists.xensource.com Thu Dec 01 10:36:55 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 10:36:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW40Z-0004mv-AB; Thu, 01 Dec 2011 10:36:51 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raghavendra.kt@linux.vnet.ibm.com>)
	id 1RVg3A-0007hA-2b
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 09:01:56 +0000
X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1322643674!5587313!1
X-Originating-IP: [32.97.110.149]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMzIuOTcuMTEwLjE0OSA9PiA3OTM4OQ==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14938 invoked from network); 30 Nov 2011 09:01:16 -0000
Received: from e31.co.us.ibm.com (HELO e31.co.us.ibm.com) (32.97.110.149)
	by server-5.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 30 Nov 2011 09:01:16 -0000
Received: from /spool/local
	by e31.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only!
	Violators will be prosecuted for <xen-devel@lists.xensource.com> from
	<raghavendra.kt@linux.vnet.ibm.com>; Wed, 30 Nov 2011 02:01:11 -0700
Received: from d03relay04.boulder.ibm.com ([9.17.195.106])
	by e31.co.us.ibm.com ([192.168.1.131]) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Wed, 30 Nov 2011 02:00:28 -0700
Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168])
	by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	pAU90E5q132492
	for <xen-devel@lists.xensource.com>; Wed, 30 Nov 2011 02:00:18 -0700
Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1])
	by d03av02.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP
	id pAU906qV003927
	for <xen-devel@lists.xensource.com>; Wed, 30 Nov 2011 02:00:14 -0700
Received: from oc5400248562.ibm.com (oc5400248562.in.ibm.com [9.124.158.199])
	by d03av02.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP
	id pAU8xu00002902; Wed, 30 Nov 2011 01:59:56 -0700
From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
To: Greg Kroah-Hartman <gregkh@suse.de>, KVM <kvm@vger.kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Sedat Dilek <sedat.dilek@gmail.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>, x86@kernel.org,
	"H. Peter Anvin" <hpa@zytor.com>, Dave Jiang <dave.jiang@intel.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Gleb Natapov <gleb@redhat.com>, Yinghai Lu <yinghai@kernel.org>,
	Marcelo Tosatti <mtosatti@redhat.com>, Ingo Molnar <mingo@redhat.com>, 
	Avi Kivity <avi@redhat.com>, Rik van Riel <riel@redhat.com>,
	Xen <xen-devel@lists.xensource.com>, LKML <linux-kernel@vger.kernel.org>
Date: Wed, 30 Nov 2011 14:29:59 +0530
Message-Id: <20111130085959.23386.69166.sendpatchset@oc5400248562.ibm.com>
In-Reply-To: <20111130085921.23386.89708.sendpatchset@oc5400248562.ibm.com>
References: <20111130085921.23386.89708.sendpatchset@oc5400248562.ibm.com>
x-cbid: 11113009-7282-0000-0000-0000048B276D
X-Mailman-Approved-At: Thu, 01 Dec 2011 10:36:45 +0000
Cc: Peter Zijlstra <peterz@infradead.org>,
	Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Dave Hansen <dave@linux.vnet.ibm.com>,
	Suzuki Poulose <suzuki@linux.vnet.ibm.com>,
	Sasha Levin <levinsasha928@gmail.com>
Subject: [Xen-devel] [PATCH RFC V3 2/4] kvm hypervisor : Add a hypercall to
	KVM hypervisor to support pv-ticketlocks
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Add a hypercall to KVM hypervisor to support pv-ticketlocks 

KVM_HC_KICK_CPU allows the calling vcpu to kick another vcpu out of halt state.
    
The presence of these hypercalls is indicated to guest via
KVM_FEATURE_KICK_VCPU/KVM_CAP_KICK_VCPU.

Qemu needs a corresponding patch to pass up the presence of this feature to 
guest via cpuid. Patch to qemu will be sent separately.

There is no Xen/KVM hypercall interface to await kick from.
    
Signed-off-by: Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>
Signed-off-by: Suzuki Poulose <suzuki@in.ibm.com>
Signed-off-by: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
---
diff --git a/arch/x86/include/asm/kvm_para.h b/arch/x86/include/asm/kvm_para.h
index 734c376..8b1d65d 100644
--- a/arch/x86/include/asm/kvm_para.h
+++ b/arch/x86/include/asm/kvm_para.h
@@ -16,12 +16,14 @@
 #define KVM_FEATURE_CLOCKSOURCE		0
 #define KVM_FEATURE_NOP_IO_DELAY	1
 #define KVM_FEATURE_MMU_OP		2
+
 /* This indicates that the new set of kvmclock msrs
  * are available. The use of 0x11 and 0x12 is deprecated
  */
 #define KVM_FEATURE_CLOCKSOURCE2        3
 #define KVM_FEATURE_ASYNC_PF		4
 #define KVM_FEATURE_STEAL_TIME		5
+#define KVM_FEATURE_KICK_VCPU		6
 
 /* The last 8 bits are used to indicate how to interpret the flags field
  * in pvclock structure. If no bits are set, all flags are ignored.
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index c38efd7..6e1c8b4 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -2103,6 +2103,7 @@ int kvm_dev_ioctl_check_extension(long ext)
 	case KVM_CAP_XSAVE:
 	case KVM_CAP_ASYNC_PF:
 	case KVM_CAP_GET_TSC_KHZ:
+	case KVM_CAP_KICK_VCPU:
 		r = 1;
 		break;
 	case KVM_CAP_COALESCED_MMIO:
@@ -2577,7 +2578,8 @@ static void do_cpuid_ent(struct kvm_cpuid_entry2 *entry, u32 function,
 			     (1 << KVM_FEATURE_NOP_IO_DELAY) |
 			     (1 << KVM_FEATURE_CLOCKSOURCE2) |
 			     (1 << KVM_FEATURE_ASYNC_PF) |
-			     (1 << KVM_FEATURE_CLOCKSOURCE_STABLE_BIT);
+			     (1 << KVM_FEATURE_CLOCKSOURCE_STABLE_BIT) |
+			     (1 << KVM_FEATURE_KICK_VCPU);
 
 		if (sched_info_on())
 			entry->eax |= (1 << KVM_FEATURE_STEAL_TIME);
@@ -5305,6 +5307,26 @@ int kvm_hv_hypercall(struct kvm_vcpu *vcpu)
 	return 1;
 }
 
+/*
+ * kvm_pv_kick_cpu_op:  Kick a vcpu.
+ *
+ * @cpu - vcpu to be kicked.
+ */
+static void kvm_pv_kick_cpu_op(struct kvm *kvm, int cpu)
+{
+	struct kvm_vcpu *vcpu = kvm_get_vcpu(kvm, cpu);
+	struct kvm_mp_state mp_state;
+
+	mp_state.mp_state = KVM_MP_STATE_RUNNABLE;
+	if (vcpu) {
+		vcpu->kicked = 1;
+		/* Ensure kicked is always set before wakeup */
+		barrier();
+	}
+	kvm_arch_vcpu_ioctl_set_mpstate(vcpu, &mp_state);
+	kvm_vcpu_kick(vcpu);
+}
+
 int kvm_emulate_hypercall(struct kvm_vcpu *vcpu)
 {
 	unsigned long nr, a0, a1, a2, a3, ret;
@@ -5341,6 +5363,10 @@ int kvm_emulate_hypercall(struct kvm_vcpu *vcpu)
 	case KVM_HC_MMU_OP:
 		r = kvm_pv_mmu_op(vcpu, a0, hc_gpa(vcpu, a1, a2), &ret);
 		break;
+	case KVM_HC_KICK_CPU:
+		kvm_pv_kick_cpu_op(vcpu->kvm, a0);
+		ret = 0;
+		break;
 	default:
 		ret = -KVM_ENOSYS;
 		break;
diff --git a/include/linux/kvm.h b/include/linux/kvm.h
index f47fcd3..e760035 100644
--- a/include/linux/kvm.h
+++ b/include/linux/kvm.h
@@ -558,6 +558,7 @@ struct kvm_ppc_pvinfo {
 #define KVM_CAP_PPC_HIOR 67
 #define KVM_CAP_PPC_PAPR 68
 #define KVM_CAP_S390_GMAP 71
+#define KVM_CAP_KICK_VCPU 72
 
 #ifdef KVM_CAP_IRQ_ROUTING
 
diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
index d526231..ff3b6ff 100644
--- a/include/linux/kvm_host.h
+++ b/include/linux/kvm_host.h
@@ -154,6 +154,11 @@ struct kvm_vcpu {
 #endif
 
 	struct kvm_vcpu_arch arch;
+
+	/*
+	 * blocked vcpu wakes up by checking this flag set by unlocker.
+	 */
+	int kicked;
 };
 
 static inline int kvm_vcpu_exiting_guest_mode(struct kvm_vcpu *vcpu)
diff --git a/include/linux/kvm_para.h b/include/linux/kvm_para.h
index 47a070b..19f10bd 100644
--- a/include/linux/kvm_para.h
+++ b/include/linux/kvm_para.h
@@ -19,6 +19,7 @@
 #define KVM_HC_MMU_OP			2
 #define KVM_HC_FEATURES			3
 #define KVM_HC_PPC_MAP_MAGIC_PAGE	4
+#define KVM_HC_KICK_CPU			5
 
 /*
  * hypercalls use architecture specific
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index d9cfb78..8f4b6db 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -226,6 +226,7 @@ int kvm_vcpu_init(struct kvm_vcpu *vcpu, struct kvm *kvm, unsigned id)
 	vcpu->kvm = kvm;
 	vcpu->vcpu_id = id;
 	vcpu->pid = NULL;
+	vcpu->kicked = 0;
 	init_waitqueue_head(&vcpu->wq);
 	kvm_async_pf_vcpu_init(vcpu);
 


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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 10:36:55 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 10:36:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW40a-0004o3-FS; Thu, 01 Dec 2011 10:36:52 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <pawel.moll@arm.com>) id 1RVlWC-0000yD-5J
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 14:52:16 +0000
X-Env-Sender: pawel.moll@arm.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1322664697!3705717!1
X-Originating-IP: [91.220.42.44]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogOTEuMjIwLjQyLjQ0ID0+IDEzNDYwNw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11300 invoked from network); 30 Nov 2011 14:51:37 -0000
Received: from service87.mimecast.com (HELO service87.mimecast.com)
	(91.220.42.44) by server-4.tower-174.messagelabs.com with SMTP;
	30 Nov 2011 14:51:37 -0000
Received: from cam-owa2.Emea.Arm.com (fw-tnat.cambridge.arm.com
	[217.140.96.21]) by service87.mimecast.com;
	Wed, 30 Nov 2011 14:51:32 +0000
Received: from [10.1.206.166] ([10.1.255.212]) by cam-owa2.Emea.Arm.com with
	Microsoft SMTPSVC(6.0.3790.3959); Wed, 30 Nov 2011 14:51:28 +0000
From: Pawel Moll <pawel.moll@arm.com>
To: Arnd Bergmann <arnd@arndb.de>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
In-Reply-To: <201111301432.54463.arnd@arndb.de>
References: <alpine.DEB.2.00.1111281009090.31179@kaball-desktop>
	<201111301303.23851.arnd@arndb.de>
	<1322659535.31810.97.camel@zakaz.uk.xensource.com>
	<201111301432.54463.arnd@arndb.de>
Date: Wed, 30 Nov 2011 14:51:28 +0000
Message-ID: <1322664688.3180.6.camel@hornet.cambridge.arm.com>
Mime-Version: 1.0
X-Mailer: Evolution 2.28.1
X-OriginalArrivalTime: 30 Nov 2011 14:51:28.0933 (UTC)
	FILETIME=[8AA6F550:01CCAF6F]
X-MC-Unique: 111113014513206201
X-Mailman-Approved-At: Thu, 01 Dec 2011 10:36:45 +0000
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linaro-dev@lists.linaro.org" <linaro-dev@lists.linaro.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"virtualization@lists.linux-foundation.org"
	<virtualization@lists.linux-foundation.org>,
	"android-virt@lists.cs.columbia.edu" <android-virt@lists.cs.columbia.edu>,
	"embeddedxen-devel@lists.sourceforge.net"
	<embeddedxen-devel@lists.sourceforge.net>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [ANNOUNCE] Xen port to Cortex-A15 / ARMv7 with virt
 extensions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gV2VkLCAyMDExLTExLTMwIGF0IDE0OjMyICswMDAwLCBBcm5kIEJlcmdtYW5uIHdyb3RlOgo+
IEkgZG9uJ3QgY2FyZSBtdWNoIGVpdGhlciB3YXksIGJ1dCBJIHRoaW5rIGl0IHdvdWxkIGJlIGdv
b2QgdG8KPiB1c2Ugc2ltaWxhciBzb2x1dGlvbnMgYWNyb3NzIGFsbCBoeXBlcnZpc29ycy4gVGhl
IHR3byBvcHRpb25zCj4gdGhhdCBJJ3ZlIHNlZW4gZGlzY3Vzc2VkIGZvciBLVk0gd2VyZSB0byB1
c2UgZWl0aGVyIGEgdmlydHVhbCBQQ0kKPiBidXMgd2l0aCBpbmRpdmlkdWFsIHZpcnRpby1wY2kg
ZGV2aWNlcyBhcyBvbiB0aGUgUEMsIG9yIHRvCj4gdXNlIHRoZSBuZXcgdmlydGlvLW1taW8gZHJp
dmVyIGFuZCBpbmRpdmlkdWFsbHkgcHV0IHZpcnRpbyBkZXZpY2VzCj4gaW50byB0aGUgZGV2aWNl
IHRyZWUuCgpMZXQgbWUganVzdCBhZGQgdGhhdCB0aGUgdmlydGlvLW1taW8gZGV2aWNlcyBjYW4g
YWxyZWFkeSBiZSBpbnN0YW50aWF0ZWQKZnJvbSBEVCAoc2VlIERvY3VtZW50YXRpb24vZGV2aWNl
dHJlZS9iaW5kaW5ncy92aXJ0aW8vbW1pby50eHQpLgoKRm9yIEE5LWJhc2VkIFZFIEknZCBzdWdn
ZXN0IHBsYWNpbmcgdGhlbSBhcm91bmQgMHgxMDAxZTAwMCwgZWcuOgoKICAgICAgICB2aXJ0aW9f
YmxvY2tAMTAwMWUwMDAgewogICAgICAgICAgICAgICAgY29tcGF0aWJsZSA9ICJ2aXJ0aW8sbW1p
byI7CiAgICAgICAgICAgICAgICByZWcgPSA8MHgxMDAxZTAwMCAweDEwMD47CiAgICAgICAgICAg
ICAgICBpbnRlcnJ1cHRzID0gPDQxPjsKICAgICAgICB9CgpDaGVlcnMhCgpQYXdlxYIKCgoKX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1h
aWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuc291cmNlLmNvbQpodHRwOi8vbGlzdHMueGVu
c291cmNlLmNvbS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Thu Dec 01 10:36:55 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 10:36:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW40Y-0004mc-TX; Thu, 01 Dec 2011 10:36:50 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raghavendra.kt@linux.vnet.ibm.com>)
	id 1RVg2P-0007ge-US
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 09:01:10 +0000
X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1322643630!5597976!1
X-Originating-IP: [32.97.182.146]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMzIuOTcuMTgyLjE0NiA9PiA1MDU3NDY=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6893 invoked from network); 30 Nov 2011 09:00:31 -0000
Received: from e6.ny.us.ibm.com (HELO e6.ny.us.ibm.com) (32.97.182.146)
	by server-12.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 30 Nov 2011 09:00:31 -0000
Received: from /spool/local
	by e6.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only!
	Violators will be prosecuted for <xen-devel@lists.xensource.com> from
	<raghavendra.kt@linux.vnet.ibm.com>; Wed, 30 Nov 2011 04:00:29 -0500
Received: from d01relay03.pok.ibm.com ([9.56.227.235])
	by e6.ny.us.ibm.com ([192.168.1.106]) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Wed, 30 Nov 2011 04:00:28 -0500
Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64])
	by d01relay03.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	pAU90RAl314490
	for <xen-devel@lists.xensource.com>; Wed, 30 Nov 2011 04:00:27 -0500
Received: from d01av04.pok.ibm.com (loopback [127.0.0.1])
	by d01av04.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id
	pAU90PrG000336
	for <xen-devel@lists.xensource.com>; Wed, 30 Nov 2011 04:00:27 -0500
Received: from oc5400248562.ibm.com (oc5400248562.in.ibm.com [9.124.158.199])
	by d01av04.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	pAU90GBB031541; Wed, 30 Nov 2011 04:00:17 -0500
From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
To: Greg Kroah-Hartman <gregkh@suse.de>, "H. Peter Anvin" <hpa@zytor.com>,
	Gleb Natapov <gleb@redhat.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>, x86@kernel.org,
	KVM <kvm@vger.kernel.org>, Dave Jiang <dave.jiang@intel.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Xen <xen-devel@lists.xensource.com>,
	Sedat Dilek <sedat.dilek@gmail.com>, Yinghai Lu <yinghai@kernel.org>,
	Marcelo Tosatti <mtosatti@redhat.com>, Ingo Molnar <mingo@redhat.com>, 
	Avi Kivity <avi@redhat.com>, Rik van Riel <riel@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	LKML <linux-kernel@vger.kernel.org>
Date: Wed, 30 Nov 2011 14:30:19 +0530
Message-Id: <20111130090019.23386.95844.sendpatchset@oc5400248562.ibm.com>
In-Reply-To: <20111130085921.23386.89708.sendpatchset@oc5400248562.ibm.com>
References: <20111130085921.23386.89708.sendpatchset@oc5400248562.ibm.com>
x-cbid: 11113009-1976-0000-0000-000008146076
X-Mailman-Approved-At: Thu, 01 Dec 2011 10:36:45 +0000
Cc: Peter Zijlstra <peterz@infradead.org>,
	Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Dave Hansen <dave@linux.vnet.ibm.com>,
	Suzuki Poulose <suzuki@linux.vnet.ibm.com>,
	Sasha Levin <levinsasha928@gmail.com>
Subject: [Xen-devel] [PATCH RFC V3 3/4] kvm guest : Added configuration
	support to enable debug information for KVM Guests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Added configuration support to enable debug information
for KVM Guests in debugfs
    
Signed-off-by: Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>
Signed-off-by: Suzuki Poulose <suzuki@in.ibm.com>
Signed-off-by: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
---
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 5d8152d..526e3ae 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -561,6 +561,15 @@ config KVM_GUEST
 	  This option enables various optimizations for running under the KVM
 	  hypervisor.
 
+config KVM_DEBUG_FS
+	bool "Enable debug information for KVM Guests in debugfs"
+	depends on KVM_GUEST && DEBUG_FS
+	default n
+	---help---
+	  This option enables collection of various statistics for KVM guest.
+   	  Statistics are displayed in debugfs filesystem. Enabling this option
+	  may incur significant overhead.
+
 source "arch/x86/lguest/Kconfig"
 
 config PARAVIRT


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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 10:36:55 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 10:36:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW40Z-0004mv-AB; Thu, 01 Dec 2011 10:36:51 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raghavendra.kt@linux.vnet.ibm.com>)
	id 1RVg3A-0007hA-2b
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 09:01:56 +0000
X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1322643674!5587313!1
X-Originating-IP: [32.97.110.149]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMzIuOTcuMTEwLjE0OSA9PiA3OTM4OQ==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14938 invoked from network); 30 Nov 2011 09:01:16 -0000
Received: from e31.co.us.ibm.com (HELO e31.co.us.ibm.com) (32.97.110.149)
	by server-5.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 30 Nov 2011 09:01:16 -0000
Received: from /spool/local
	by e31.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only!
	Violators will be prosecuted for <xen-devel@lists.xensource.com> from
	<raghavendra.kt@linux.vnet.ibm.com>; Wed, 30 Nov 2011 02:01:11 -0700
Received: from d03relay04.boulder.ibm.com ([9.17.195.106])
	by e31.co.us.ibm.com ([192.168.1.131]) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Wed, 30 Nov 2011 02:00:28 -0700
Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168])
	by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	pAU90E5q132492
	for <xen-devel@lists.xensource.com>; Wed, 30 Nov 2011 02:00:18 -0700
Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1])
	by d03av02.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP
	id pAU906qV003927
	for <xen-devel@lists.xensource.com>; Wed, 30 Nov 2011 02:00:14 -0700
Received: from oc5400248562.ibm.com (oc5400248562.in.ibm.com [9.124.158.199])
	by d03av02.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP
	id pAU8xu00002902; Wed, 30 Nov 2011 01:59:56 -0700
From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
To: Greg Kroah-Hartman <gregkh@suse.de>, KVM <kvm@vger.kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Sedat Dilek <sedat.dilek@gmail.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>, x86@kernel.org,
	"H. Peter Anvin" <hpa@zytor.com>, Dave Jiang <dave.jiang@intel.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Gleb Natapov <gleb@redhat.com>, Yinghai Lu <yinghai@kernel.org>,
	Marcelo Tosatti <mtosatti@redhat.com>, Ingo Molnar <mingo@redhat.com>, 
	Avi Kivity <avi@redhat.com>, Rik van Riel <riel@redhat.com>,
	Xen <xen-devel@lists.xensource.com>, LKML <linux-kernel@vger.kernel.org>
Date: Wed, 30 Nov 2011 14:29:59 +0530
Message-Id: <20111130085959.23386.69166.sendpatchset@oc5400248562.ibm.com>
In-Reply-To: <20111130085921.23386.89708.sendpatchset@oc5400248562.ibm.com>
References: <20111130085921.23386.89708.sendpatchset@oc5400248562.ibm.com>
x-cbid: 11113009-7282-0000-0000-0000048B276D
X-Mailman-Approved-At: Thu, 01 Dec 2011 10:36:45 +0000
Cc: Peter Zijlstra <peterz@infradead.org>,
	Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Dave Hansen <dave@linux.vnet.ibm.com>,
	Suzuki Poulose <suzuki@linux.vnet.ibm.com>,
	Sasha Levin <levinsasha928@gmail.com>
Subject: [Xen-devel] [PATCH RFC V3 2/4] kvm hypervisor : Add a hypercall to
	KVM hypervisor to support pv-ticketlocks
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Add a hypercall to KVM hypervisor to support pv-ticketlocks 

KVM_HC_KICK_CPU allows the calling vcpu to kick another vcpu out of halt state.
    
The presence of these hypercalls is indicated to guest via
KVM_FEATURE_KICK_VCPU/KVM_CAP_KICK_VCPU.

Qemu needs a corresponding patch to pass up the presence of this feature to 
guest via cpuid. Patch to qemu will be sent separately.

There is no Xen/KVM hypercall interface to await kick from.
    
Signed-off-by: Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>
Signed-off-by: Suzuki Poulose <suzuki@in.ibm.com>
Signed-off-by: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
---
diff --git a/arch/x86/include/asm/kvm_para.h b/arch/x86/include/asm/kvm_para.h
index 734c376..8b1d65d 100644
--- a/arch/x86/include/asm/kvm_para.h
+++ b/arch/x86/include/asm/kvm_para.h
@@ -16,12 +16,14 @@
 #define KVM_FEATURE_CLOCKSOURCE		0
 #define KVM_FEATURE_NOP_IO_DELAY	1
 #define KVM_FEATURE_MMU_OP		2
+
 /* This indicates that the new set of kvmclock msrs
  * are available. The use of 0x11 and 0x12 is deprecated
  */
 #define KVM_FEATURE_CLOCKSOURCE2        3
 #define KVM_FEATURE_ASYNC_PF		4
 #define KVM_FEATURE_STEAL_TIME		5
+#define KVM_FEATURE_KICK_VCPU		6
 
 /* The last 8 bits are used to indicate how to interpret the flags field
  * in pvclock structure. If no bits are set, all flags are ignored.
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index c38efd7..6e1c8b4 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -2103,6 +2103,7 @@ int kvm_dev_ioctl_check_extension(long ext)
 	case KVM_CAP_XSAVE:
 	case KVM_CAP_ASYNC_PF:
 	case KVM_CAP_GET_TSC_KHZ:
+	case KVM_CAP_KICK_VCPU:
 		r = 1;
 		break;
 	case KVM_CAP_COALESCED_MMIO:
@@ -2577,7 +2578,8 @@ static void do_cpuid_ent(struct kvm_cpuid_entry2 *entry, u32 function,
 			     (1 << KVM_FEATURE_NOP_IO_DELAY) |
 			     (1 << KVM_FEATURE_CLOCKSOURCE2) |
 			     (1 << KVM_FEATURE_ASYNC_PF) |
-			     (1 << KVM_FEATURE_CLOCKSOURCE_STABLE_BIT);
+			     (1 << KVM_FEATURE_CLOCKSOURCE_STABLE_BIT) |
+			     (1 << KVM_FEATURE_KICK_VCPU);
 
 		if (sched_info_on())
 			entry->eax |= (1 << KVM_FEATURE_STEAL_TIME);
@@ -5305,6 +5307,26 @@ int kvm_hv_hypercall(struct kvm_vcpu *vcpu)
 	return 1;
 }
 
+/*
+ * kvm_pv_kick_cpu_op:  Kick a vcpu.
+ *
+ * @cpu - vcpu to be kicked.
+ */
+static void kvm_pv_kick_cpu_op(struct kvm *kvm, int cpu)
+{
+	struct kvm_vcpu *vcpu = kvm_get_vcpu(kvm, cpu);
+	struct kvm_mp_state mp_state;
+
+	mp_state.mp_state = KVM_MP_STATE_RUNNABLE;
+	if (vcpu) {
+		vcpu->kicked = 1;
+		/* Ensure kicked is always set before wakeup */
+		barrier();
+	}
+	kvm_arch_vcpu_ioctl_set_mpstate(vcpu, &mp_state);
+	kvm_vcpu_kick(vcpu);
+}
+
 int kvm_emulate_hypercall(struct kvm_vcpu *vcpu)
 {
 	unsigned long nr, a0, a1, a2, a3, ret;
@@ -5341,6 +5363,10 @@ int kvm_emulate_hypercall(struct kvm_vcpu *vcpu)
 	case KVM_HC_MMU_OP:
 		r = kvm_pv_mmu_op(vcpu, a0, hc_gpa(vcpu, a1, a2), &ret);
 		break;
+	case KVM_HC_KICK_CPU:
+		kvm_pv_kick_cpu_op(vcpu->kvm, a0);
+		ret = 0;
+		break;
 	default:
 		ret = -KVM_ENOSYS;
 		break;
diff --git a/include/linux/kvm.h b/include/linux/kvm.h
index f47fcd3..e760035 100644
--- a/include/linux/kvm.h
+++ b/include/linux/kvm.h
@@ -558,6 +558,7 @@ struct kvm_ppc_pvinfo {
 #define KVM_CAP_PPC_HIOR 67
 #define KVM_CAP_PPC_PAPR 68
 #define KVM_CAP_S390_GMAP 71
+#define KVM_CAP_KICK_VCPU 72
 
 #ifdef KVM_CAP_IRQ_ROUTING
 
diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
index d526231..ff3b6ff 100644
--- a/include/linux/kvm_host.h
+++ b/include/linux/kvm_host.h
@@ -154,6 +154,11 @@ struct kvm_vcpu {
 #endif
 
 	struct kvm_vcpu_arch arch;
+
+	/*
+	 * blocked vcpu wakes up by checking this flag set by unlocker.
+	 */
+	int kicked;
 };
 
 static inline int kvm_vcpu_exiting_guest_mode(struct kvm_vcpu *vcpu)
diff --git a/include/linux/kvm_para.h b/include/linux/kvm_para.h
index 47a070b..19f10bd 100644
--- a/include/linux/kvm_para.h
+++ b/include/linux/kvm_para.h
@@ -19,6 +19,7 @@
 #define KVM_HC_MMU_OP			2
 #define KVM_HC_FEATURES			3
 #define KVM_HC_PPC_MAP_MAGIC_PAGE	4
+#define KVM_HC_KICK_CPU			5
 
 /*
  * hypercalls use architecture specific
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index d9cfb78..8f4b6db 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -226,6 +226,7 @@ int kvm_vcpu_init(struct kvm_vcpu *vcpu, struct kvm *kvm, unsigned id)
 	vcpu->kvm = kvm;
 	vcpu->vcpu_id = id;
 	vcpu->pid = NULL;
+	vcpu->kicked = 0;
 	init_waitqueue_head(&vcpu->wq);
 	kvm_async_pf_vcpu_init(vcpu);
 


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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 10:36:56 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 10:36:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW40Z-0004nG-N1; Thu, 01 Dec 2011 10:36:51 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raghavendra.kt@linux.vnet.ibm.com>)
	id 1RVg3J-0007hI-6x
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 09:02:05 +0000
X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1322643684!5251929!1
X-Originating-IP: [32.97.110.149]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMzIuOTcuMTEwLjE0OSA9PiA3OTM4OQ==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6146 invoked from network); 30 Nov 2011 09:01:26 -0000
Received: from e31.co.us.ibm.com (HELO e31.co.us.ibm.com) (32.97.110.149)
	by server-14.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 30 Nov 2011 09:01:26 -0000
Received: from /spool/local
	by e31.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only!
	Violators will be prosecuted for <xen-devel@lists.xensource.com> from
	<raghavendra.kt@linux.vnet.ibm.com>; Wed, 30 Nov 2011 02:01:16 -0700
Received: from d03relay04.boulder.ibm.com ([9.17.195.106])
	by e31.co.us.ibm.com ([192.168.1.131]) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Wed, 30 Nov 2011 02:00:54 -0700
Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170])
	by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	pAU90lO4139978
	for <xen-devel@lists.xensource.com>; Wed, 30 Nov 2011 02:00:47 -0700
Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1])
	by d03av04.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP
	id pAU90jng030420
	for <xen-devel@lists.xensource.com>; Wed, 30 Nov 2011 02:00:47 -0700
Received: from oc5400248562.ibm.com (oc5400248562.in.ibm.com [9.124.158.199])
	by d03av04.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP
	id pAU90ZoW029372; Wed, 30 Nov 2011 02:00:37 -0700
From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
To: Greg Kroah-Hartman <gregkh@suse.de>, KVM <kvm@vger.kernel.org>,
	Sedat Dilek <sedat.dilek@gmail.com>, Ingo Molnar <mingo@redhat.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>, x86@kernel.org,
	"H. Peter Anvin" <hpa@zytor.com>, Dave Jiang <dave.jiang@intel.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Gleb Natapov <gleb@redhat.com>, Yinghai Lu <yinghai@kernel.org>,
	Marcelo Tosatti <mtosatti@redhat.com>,
	Xen <xen-devel@lists.xensource.com>, Avi Kivity <avi@redhat.com>,
	Rik van Riel <riel@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	LKML <linux-kernel@vger.kernel.org>
Date: Wed, 30 Nov 2011 14:30:38 +0530
Message-Id: <20111130090038.23386.4505.sendpatchset@oc5400248562.ibm.com>
In-Reply-To: <20111130085921.23386.89708.sendpatchset@oc5400248562.ibm.com>
References: <20111130085921.23386.89708.sendpatchset@oc5400248562.ibm.com>
x-cbid: 11113009-7282-0000-0000-0000048B2800
X-Mailman-Approved-At: Thu, 01 Dec 2011 10:36:45 +0000
Cc: Peter Zijlstra <peterz@infradead.org>,
	Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Dave Hansen <dave@linux.vnet.ibm.com>,
	Suzuki Poulose <suzuki@linux.vnet.ibm.com>,
	Sasha Levin <levinsasha928@gmail.com>
Subject: [Xen-devel] [PATCH RFC V3 4/4] kvm : pv-ticketlocks support for
	linux guests running on KVM hypervisor
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This patch extends Linux guests running on KVM hypervisor to support
pv-ticketlocks. 
During smp_boot_cpus  paravirtualied KVM guest detects if the hypervisor has
required feature (KVM_FEATURE_KICK_VCPU) to support pv-ticketlocks. If so,
 support for pv-ticketlocks is registered via pv_lock_ops.

Signed-off-by: Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>
Signed-off-by: Suzuki Poulose <suzuki@in.ibm.com>
Signed-off-by: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
---
diff --git a/arch/x86/include/asm/kvm_para.h b/arch/x86/include/asm/kvm_para.h
index 8b1d65d..7e419ad 100644
--- a/arch/x86/include/asm/kvm_para.h
+++ b/arch/x86/include/asm/kvm_para.h
@@ -195,10 +195,21 @@ void kvm_async_pf_task_wait(u32 token);
 void kvm_async_pf_task_wake(u32 token);
 u32 kvm_read_and_reset_pf_reason(void);
 extern void kvm_disable_steal_time(void);
-#else
-#define kvm_guest_init() do { } while (0)
+
+#ifdef CONFIG_PARAVIRT_SPINLOCKS
+void __init kvm_spinlock_init(void);
+#else /* CONFIG_PARAVIRT_SPINLOCKS */
+static void kvm_spinlock_init(void)
+{
+}
+#endif /* CONFIG_PARAVIRT_SPINLOCKS */
+
+#else /* CONFIG_KVM_GUEST */
+#define kvm_guest_init() do {} while (0)
 #define kvm_async_pf_task_wait(T) do {} while(0)
 #define kvm_async_pf_task_wake(T) do {} while(0)
+#define kvm_spinlock_init() do {} while (0)
+
 static inline u32 kvm_read_and_reset_pf_reason(void)
 {
 	return 0;
diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c
index a9c2116..dffeea3 100644
--- a/arch/x86/kernel/kvm.c
+++ b/arch/x86/kernel/kvm.c
@@ -33,6 +33,7 @@
 #include <linux/sched.h>
 #include <linux/slab.h>
 #include <linux/kprobes.h>
+#include <linux/debugfs.h>
 #include <asm/timer.h>
 #include <asm/cpu.h>
 #include <asm/traps.h>
@@ -545,6 +546,7 @@ static void __init kvm_smp_prepare_boot_cpu(void)
 #endif
 	kvm_guest_cpu_init();
 	native_smp_prepare_boot_cpu();
+	kvm_spinlock_init();
 }
 
 static void __cpuinit kvm_guest_cpu_online(void *dummy)
@@ -627,3 +629,248 @@ static __init int activate_jump_labels(void)
 	return 0;
 }
 arch_initcall(activate_jump_labels);
+
+#ifdef CONFIG_PARAVIRT_SPINLOCKS
+
+enum kvm_contention_stat {
+	TAKEN_SLOW,
+	TAKEN_SLOW_PICKUP,
+	RELEASED_SLOW,
+	RELEASED_SLOW_KICKED,
+	NR_CONTENTION_STATS
+};
+
+#ifdef CONFIG_KVM_DEBUG_FS
+
+static struct kvm_spinlock_stats
+{
+	u32 contention_stats[NR_CONTENTION_STATS];
+
+#define HISTO_BUCKETS	30
+	u32 histo_spin_blocked[HISTO_BUCKETS+1];
+
+	u64 time_blocked;
+} spinlock_stats;
+
+static u8 zero_stats;
+
+static inline void check_zero(void)
+{
+	u8 ret;
+	u8 old = ACCESS_ONCE(zero_stats);
+	if (unlikely(old)) {
+		ret = cmpxchg(&zero_stats, old, 0);
+		/* This ensures only one fellow resets the stat */
+		if (ret == old)
+			memset(&spinlock_stats, 0, sizeof(spinlock_stats));
+	}
+}
+
+static inline void add_stats(enum kvm_contention_stat var, int val)
+{
+	check_zero();
+	spinlock_stats.contention_stats[var] += val;
+}
+
+
+static inline u64 spin_time_start(void)
+{
+	return sched_clock();
+}
+
+static void __spin_time_accum(u64 delta, u32 *array)
+{
+	unsigned index = ilog2(delta);
+
+	check_zero();
+
+	if (index < HISTO_BUCKETS)
+		array[index]++;
+	else
+		array[HISTO_BUCKETS]++;
+}
+
+static inline void spin_time_accum_blocked(u64 start)
+{
+	u32 delta = sched_clock() - start;
+
+	__spin_time_accum(delta, spinlock_stats.histo_spin_blocked);
+	spinlock_stats.time_blocked += delta;
+}
+
+static struct dentry *d_spin_debug;
+static struct dentry *d_kvm_debug;
+
+struct dentry *kvm_init_debugfs(void)
+{
+	d_kvm_debug = debugfs_create_dir("kvm", NULL);
+	if (!d_kvm_debug)
+		printk(KERN_WARNING "Could not create 'kvm' debugfs directory\n");
+
+	return d_kvm_debug;
+}
+
+static int __init kvm_spinlock_debugfs(void)
+{
+	struct dentry *d_kvm = kvm_init_debugfs();
+
+	if (d_kvm == NULL)
+		return -ENOMEM;
+
+	d_spin_debug = debugfs_create_dir("spinlocks", d_kvm);
+
+	debugfs_create_u8("zero_stats", 0644, d_spin_debug, &zero_stats);
+
+	debugfs_create_u32("taken_slow", 0444, d_spin_debug,
+		   &spinlock_stats.contention_stats[TAKEN_SLOW]);
+	debugfs_create_u32("taken_slow_pickup", 0444, d_spin_debug,
+		   &spinlock_stats.contention_stats[TAKEN_SLOW_PICKUP]);
+
+	debugfs_create_u32("released_slow", 0444, d_spin_debug,
+		   &spinlock_stats.contention_stats[RELEASED_SLOW]);
+	debugfs_create_u32("released_slow_kicked", 0444, d_spin_debug,
+		   &spinlock_stats.contention_stats[RELEASED_SLOW_KICKED]);
+
+	debugfs_create_u64("time_blocked", 0444, d_spin_debug,
+			   &spinlock_stats.time_blocked);
+
+	debugfs_create_u32_array("histo_blocked", 0444, d_spin_debug,
+		     spinlock_stats.histo_spin_blocked, HISTO_BUCKETS + 1);
+
+	return 0;
+}
+fs_initcall(kvm_spinlock_debugfs);
+#else  /* !CONFIG_KVM_DEBUG_FS */
+#define TIMEOUT			(1 << 10)
+static inline void add_stats(enum kvm_contention_stat var, u32 val)
+{
+}
+
+static inline u64 spin_time_start(void)
+{
+	return 0;
+}
+
+static inline void spin_time_accum_blocked(u64 start)
+{
+}
+#endif  /* CONFIG_KVM_DEBUG_FS */
+
+struct kvm_lock_waiting {
+	struct arch_spinlock *lock;
+	__ticket_t want;
+};
+
+/* cpus 'waiting' on a spinlock to become available */
+static cpumask_t waiting_cpus;
+
+/* Track spinlock on which a cpu is waiting */
+static DEFINE_PER_CPU(struct kvm_lock_waiting, lock_waiting);
+
+static void kvm_lock_spinning(struct arch_spinlock *lock, __ticket_t want)
+{
+	struct kvm_lock_waiting *w = &__get_cpu_var(lock_waiting);
+	int cpu = smp_processor_id();
+	u64 start;
+	unsigned long flags;
+
+	start = spin_time_start();
+
+	/*
+	 * Make sure an interrupt handler can't upset things in a
+	 * partially setup state.
+	 */
+	local_irq_save(flags);
+
+	/*
+	 * The ordering protocol on this is that the "lock" pointer
+	 * may only be set non-NULL if the "want" ticket is correct.
+	 * If we're updating "want", we must first clear "lock".
+	 */
+	w->lock = NULL;
+	smp_wmb();
+	w->want = want;
+	smp_wmb();
+	w->lock = lock;
+
+	add_stats(TAKEN_SLOW, 1);
+
+	/*
+	 * This uses set_bit, which is atomic but we should not rely on its
+	 * reordering gurantees. So barrier is needed after this call.
+	 */
+	cpumask_set_cpu(cpu, &waiting_cpus);
+
+	barrier();
+
+	/*
+	 * Mark entry to slowpath before doing the pickup test to make
+	 * sure we don't deadlock with an unlocker.
+	 */
+	__ticket_enter_slowpath(lock);
+
+	/*
+	 * check again make sure it didn't become free while
+	 * we weren't looking.
+	 */
+	if (ACCESS_ONCE(lock->tickets.head) == want) {
+		add_stats(TAKEN_SLOW_PICKUP, 1);
+		goto out;
+	}
+
+	/* Allow interrupts while blocked */
+	local_irq_restore(flags);
+
+	/* halt until it's our turn and kicked. */
+	halt();
+
+	local_irq_save(flags);
+out:
+	cpumask_clear_cpu(cpu, &waiting_cpus);
+	w->lock = NULL;
+	local_irq_restore(flags);
+	spin_time_accum_blocked(start);
+}
+PV_CALLEE_SAVE_REGS_THUNK(kvm_lock_spinning);
+
+/* Kick a cpu */
+static inline void kvm_kick_cpu(int cpu)
+{
+	kvm_hypercall1(KVM_HC_KICK_CPU, cpu);
+}
+
+/* Kick vcpu waiting on @lock->head to reach value @ticket */
+static void kvm_unlock_kick(struct arch_spinlock *lock, __ticket_t ticket)
+{
+	int cpu;
+
+	add_stats(RELEASED_SLOW, 1);
+
+	for_each_cpu(cpu, &waiting_cpus) {
+		const struct kvm_lock_waiting *w = &per_cpu(lock_waiting, cpu);
+		if (ACCESS_ONCE(w->lock) == lock &&
+		    ACCESS_ONCE(w->want) == ticket) {
+			add_stats(RELEASED_SLOW_KICKED, 1);
+			kvm_kick_cpu(cpu);
+			break;
+		}
+	}
+}
+
+/*
+ * Setup pv_lock_ops to exploit KVM_FEATURE_KICK_VCPU if present.
+ */
+void __init kvm_spinlock_init(void)
+{
+	if (!kvm_para_available())
+		return;
+	/* Does host kernel support KVM_FEATURE_KICK_VCPU? */
+	if (!kvm_para_has_feature(KVM_FEATURE_KICK_VCPU))
+		return;
+
+	jump_label_inc(&paravirt_ticketlocks_enabled);
+
+	pv_lock_ops.lock_spinning = PV_CALLEE_SAVE(kvm_lock_spinning);
+	pv_lock_ops.unlock_kick = kvm_unlock_kick;
+}
+#endif	/* CONFIG_PARAVIRT_SPINLOCKS */
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index 8f4b6db..a89546b 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -1518,6 +1518,12 @@ void kvm_vcpu_block(struct kvm_vcpu *vcpu)
 			kvm_make_request(KVM_REQ_UNHALT, vcpu);
 			break;
 		}
+		if (vcpu->kicked) {
+			vcpu->kicked = 0;
+			barrier();
+			kvm_make_request(KVM_REQ_UNHALT, vcpu);
+			break;
+		}
 		if (kvm_cpu_has_pending_timer(vcpu))
 			break;
 		if (signal_pending(current))


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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 10:36:56 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 10:36:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW40X-0004lQ-7l; Thu, 01 Dec 2011 10:36:49 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anup@brainfault.org>) id 1RVc0Z-0005TR-MR
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 04:42:59 +0000
X-Env-Sender: anup@brainfault.org
X-Msg-Ref: server-8.tower-216.messagelabs.com!1322628139!5577767!1
X-Originating-IP: [209.85.215.171]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5278 invoked from network); 30 Nov 2011 04:42:20 -0000
Received: from mail-ey0-f171.google.com (HELO mail-ey0-f171.google.com)
	(209.85.215.171)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Nov 2011 04:42:20 -0000
Received: by eaad12 with SMTP id d12so173399eaa.30
	for <xen-devel@lists.xensource.com>;
	Tue, 29 Nov 2011 20:42:19 -0800 (PST)
MIME-Version: 1.0
Received: by 10.213.19.203 with SMTP id c11mr203922ebb.80.1322628139109; Tue,
	29 Nov 2011 20:42:19 -0800 (PST)
Received: by 10.213.34.203 with HTTP; Tue, 29 Nov 2011 20:42:19 -0800 (PST)
X-Originating-IP: [122.170.124.90]
In-Reply-To: <201111292129.20444.arnd@arndb.de>
References: <alpine.DEB.2.00.1111281009090.31179@kaball-desktop>
	<201111292129.20444.arnd@arndb.de>
Date: Wed, 30 Nov 2011 10:12:19 +0530
Message-ID: <CAAhSdy3F1oUQP=f_Tig4_MnufwPRpNooZYW8_cSTAse7aOaDoA@mail.gmail.com>
From: Anup Patel <anup@brainfault.org>
To: Arnd Bergmann <arnd@arndb.de>
X-Mailman-Approved-At: Thu, 01 Dec 2011 10:36:45 +0000
Cc: xen-devel@lists.xensource.com, linaro-dev@lists.linaro.org,
	kvm@vger.kernel.org, Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	linux-kernel@vger.kernel.org, virtualization@lists.linux-foundation.org,
	android-virt@lists.cs.columbia.edu,
	embeddedxen-devel@lists.sourceforge.net,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [Xen-devel] [ANNOUNCE] Xen port to Cortex-A15 / ARMv7 with virt
	extensions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6531383273647939908=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============6531383273647939908==
Content-Type: multipart/alternative; boundary=0015174be22c66cfcd04b2ec5c2b

--0015174be22c66cfcd04b2ec5c2b
Content-Type: text/plain; charset=ISO-8859-1

Hi all,

I wanted to know how Xen-ARM for A15 will address following concerns:

- How will Xen-ARM for A15 support legacy guest environment like ARMv5 or
ARMv6 ?
- What if my Cortex-A15 board does not have a GIC with virtualization
support ?

Best Regards,
Anup Patel

On Wed, Nov 30, 2011 at 2:59 AM, Arnd Bergmann <arnd@arndb.de> wrote:

> On Tuesday 29 November 2011, Stefano Stabellini wrote:
> > Hi all,
> > a few weeks ago I (and a few others) started hacking on a
> > proof-of-concept hypervisor port to Cortex-A15 which uses and requires
> > ARMv7 virtualization extensions. The intention of this work was to find
> > out how to best support ARM v7+ on Xen. See
> >
> http://old-list-archives.xen.org/archives/html/xen-arm/2011-09/msg00013.html
> > for more details.
> >
> > I am pleased to announce that significant progress has been made, and
> > that we now have a nascent Xen port for Cortex-A15. The port is based on
> > xen-unstable (HG CS 8d6edc3d26d2) and written from scratch exploiting
> > the latest virtualization, LPAE, GIC and generic timer support in
> > hardware.
>
> Very nice!
>
> Do you have a pointer to the kernel sources for the Linux guest?
> Since Xen and KVM are both in an early working state right now,
> it would be very nice if we could agree on the guest model to make
> sure that it's always possible to run the same kernel in both
> (and potentially other future) hypervisors without modifications.
>
>        Arnd
> --
> 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/
>

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

Hi all,<br><br>I wanted to know how Xen-ARM for A15 will address following =
concerns:<br><br>- How will Xen-ARM for A15 support legacy guest environmen=
t like ARMv5 or ARMv6 ?<br>- What if my Cortex-A15 board does not have a GI=
C with virtualization support ?<br>
<br>Best Regards,<br>Anup Patel<br><br><div class=3D"gmail_quote">On Wed, N=
ov 30, 2011 at 2:59 AM, Arnd Bergmann <span dir=3D"ltr">&lt;<a href=3D"mail=
to:arnd@arndb.de">arnd@arndb.de</a>&gt;</span> wrote:<br><blockquote class=
=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid=
 rgb(204, 204, 204); padding-left: 1ex;">
<div class=3D"im">On Tuesday 29 November 2011, Stefano Stabellini wrote:<br=
>
&gt; Hi all,<br>
&gt; a few weeks ago I (and a few others) started hacking on a<br>
&gt; proof-of-concept hypervisor port to Cortex-A15 which uses and requires=
<br>
&gt; ARMv7 virtualization extensions. The intention of this work was to fin=
d<br>
&gt; out how to best support ARM v7+ on Xen. See<br>
&gt; <a href=3D"http://old-list-archives.xen.org/archives/html/xen-arm/2011=
-09/msg00013.html" target=3D"_blank">http://old-list-archives.xen.org/archi=
ves/html/xen-arm/2011-09/msg00013.html</a><br>
&gt; for more details.<br>
&gt;<br>
&gt; I am pleased to announce that significant progress has been made, and<=
br>
&gt; that we now have a nascent Xen port for Cortex-A15. The port is based =
on<br>
&gt; xen-unstable (HG CS 8d6edc3d26d2) and written from scratch exploiting<=
br>
&gt; the latest virtualization, LPAE, GIC and generic timer support in<br>
&gt; hardware.<br>
<br>
</div>Very nice!<br>
<br>
Do you have a pointer to the kernel sources for the Linux guest?<br>
Since Xen and KVM are both in an early working state right now,<br>
it would be very nice if we could agree on the guest model to make<br>
sure that it&#39;s always possible to run the same kernel in both<br>
(and potentially other future) hypervisors without modifications.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
 =A0 =A0 =A0 =A0Arnd<br>
</font></span><div class=3D"HOEnZb"><div class=3D"h5">--<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 =A0<a href=3D"http://vger.kernel.org/majordomo-info.=
html" target=3D"_blank">http://vger.kernel.org/majordomo-info.html</a><br>
Please read the FAQ at =A0<a href=3D"http://www.tux.org/lkml/" target=3D"_b=
lank">http://www.tux.org/lkml/</a><br>
</div></div></blockquote></div><br>

--0015174be22c66cfcd04b2ec5c2b--


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

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

--===============6531383273647939908==--


From xen-devel-bounces@lists.xensource.com Thu Dec 01 10:36:56 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 10:36:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW40X-0004lQ-7l; Thu, 01 Dec 2011 10:36:49 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anup@brainfault.org>) id 1RVc0Z-0005TR-MR
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 04:42:59 +0000
X-Env-Sender: anup@brainfault.org
X-Msg-Ref: server-8.tower-216.messagelabs.com!1322628139!5577767!1
X-Originating-IP: [209.85.215.171]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5278 invoked from network); 30 Nov 2011 04:42:20 -0000
Received: from mail-ey0-f171.google.com (HELO mail-ey0-f171.google.com)
	(209.85.215.171)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Nov 2011 04:42:20 -0000
Received: by eaad12 with SMTP id d12so173399eaa.30
	for <xen-devel@lists.xensource.com>;
	Tue, 29 Nov 2011 20:42:19 -0800 (PST)
MIME-Version: 1.0
Received: by 10.213.19.203 with SMTP id c11mr203922ebb.80.1322628139109; Tue,
	29 Nov 2011 20:42:19 -0800 (PST)
Received: by 10.213.34.203 with HTTP; Tue, 29 Nov 2011 20:42:19 -0800 (PST)
X-Originating-IP: [122.170.124.90]
In-Reply-To: <201111292129.20444.arnd@arndb.de>
References: <alpine.DEB.2.00.1111281009090.31179@kaball-desktop>
	<201111292129.20444.arnd@arndb.de>
Date: Wed, 30 Nov 2011 10:12:19 +0530
Message-ID: <CAAhSdy3F1oUQP=f_Tig4_MnufwPRpNooZYW8_cSTAse7aOaDoA@mail.gmail.com>
From: Anup Patel <anup@brainfault.org>
To: Arnd Bergmann <arnd@arndb.de>
X-Mailman-Approved-At: Thu, 01 Dec 2011 10:36:45 +0000
Cc: xen-devel@lists.xensource.com, linaro-dev@lists.linaro.org,
	kvm@vger.kernel.org, Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	linux-kernel@vger.kernel.org, virtualization@lists.linux-foundation.org,
	android-virt@lists.cs.columbia.edu,
	embeddedxen-devel@lists.sourceforge.net,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [Xen-devel] [ANNOUNCE] Xen port to Cortex-A15 / ARMv7 with virt
	extensions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6531383273647939908=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============6531383273647939908==
Content-Type: multipart/alternative; boundary=0015174be22c66cfcd04b2ec5c2b

--0015174be22c66cfcd04b2ec5c2b
Content-Type: text/plain; charset=ISO-8859-1

Hi all,

I wanted to know how Xen-ARM for A15 will address following concerns:

- How will Xen-ARM for A15 support legacy guest environment like ARMv5 or
ARMv6 ?
- What if my Cortex-A15 board does not have a GIC with virtualization
support ?

Best Regards,
Anup Patel

On Wed, Nov 30, 2011 at 2:59 AM, Arnd Bergmann <arnd@arndb.de> wrote:

> On Tuesday 29 November 2011, Stefano Stabellini wrote:
> > Hi all,
> > a few weeks ago I (and a few others) started hacking on a
> > proof-of-concept hypervisor port to Cortex-A15 which uses and requires
> > ARMv7 virtualization extensions. The intention of this work was to find
> > out how to best support ARM v7+ on Xen. See
> >
> http://old-list-archives.xen.org/archives/html/xen-arm/2011-09/msg00013.html
> > for more details.
> >
> > I am pleased to announce that significant progress has been made, and
> > that we now have a nascent Xen port for Cortex-A15. The port is based on
> > xen-unstable (HG CS 8d6edc3d26d2) and written from scratch exploiting
> > the latest virtualization, LPAE, GIC and generic timer support in
> > hardware.
>
> Very nice!
>
> Do you have a pointer to the kernel sources for the Linux guest?
> Since Xen and KVM are both in an early working state right now,
> it would be very nice if we could agree on the guest model to make
> sure that it's always possible to run the same kernel in both
> (and potentially other future) hypervisors without modifications.
>
>        Arnd
> --
> 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/
>

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

Hi all,<br><br>I wanted to know how Xen-ARM for A15 will address following =
concerns:<br><br>- How will Xen-ARM for A15 support legacy guest environmen=
t like ARMv5 or ARMv6 ?<br>- What if my Cortex-A15 board does not have a GI=
C with virtualization support ?<br>
<br>Best Regards,<br>Anup Patel<br><br><div class=3D"gmail_quote">On Wed, N=
ov 30, 2011 at 2:59 AM, Arnd Bergmann <span dir=3D"ltr">&lt;<a href=3D"mail=
to:arnd@arndb.de">arnd@arndb.de</a>&gt;</span> wrote:<br><blockquote class=
=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid=
 rgb(204, 204, 204); padding-left: 1ex;">
<div class=3D"im">On Tuesday 29 November 2011, Stefano Stabellini wrote:<br=
>
&gt; Hi all,<br>
&gt; a few weeks ago I (and a few others) started hacking on a<br>
&gt; proof-of-concept hypervisor port to Cortex-A15 which uses and requires=
<br>
&gt; ARMv7 virtualization extensions. The intention of this work was to fin=
d<br>
&gt; out how to best support ARM v7+ on Xen. See<br>
&gt; <a href=3D"http://old-list-archives.xen.org/archives/html/xen-arm/2011=
-09/msg00013.html" target=3D"_blank">http://old-list-archives.xen.org/archi=
ves/html/xen-arm/2011-09/msg00013.html</a><br>
&gt; for more details.<br>
&gt;<br>
&gt; I am pleased to announce that significant progress has been made, and<=
br>
&gt; that we now have a nascent Xen port for Cortex-A15. The port is based =
on<br>
&gt; xen-unstable (HG CS 8d6edc3d26d2) and written from scratch exploiting<=
br>
&gt; the latest virtualization, LPAE, GIC and generic timer support in<br>
&gt; hardware.<br>
<br>
</div>Very nice!<br>
<br>
Do you have a pointer to the kernel sources for the Linux guest?<br>
Since Xen and KVM are both in an early working state right now,<br>
it would be very nice if we could agree on the guest model to make<br>
sure that it&#39;s always possible to run the same kernel in both<br>
(and potentially other future) hypervisors without modifications.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
 =A0 =A0 =A0 =A0Arnd<br>
</font></span><div class=3D"HOEnZb"><div class=3D"h5">--<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 =A0<a href=3D"http://vger.kernel.org/majordomo-info.=
html" target=3D"_blank">http://vger.kernel.org/majordomo-info.html</a><br>
Please read the FAQ at =A0<a href=3D"http://www.tux.org/lkml/" target=3D"_b=
lank">http://www.tux.org/lkml/</a><br>
</div></div></blockquote></div><br>

--0015174be22c66cfcd04b2ec5c2b--


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

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

--===============6531383273647939908==--


From xen-devel-bounces@lists.xensource.com Thu Dec 01 10:36:56 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 10:36:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW40Y-0004lw-23; Thu, 01 Dec 2011 10:36:50 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raghavendra.kt@linux.vnet.ibm.com>)
	id 1RVg1b-0007et-EY
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 09:00:19 +0000
X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1322643579!3465960!1
X-Originating-IP: [32.97.182.139]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMzIuOTcuMTgyLjEzOSA9PiA0ODUyODU=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15135 invoked from network); 30 Nov 2011 08:59:40 -0000
Received: from e9.ny.us.ibm.com (HELO e9.ny.us.ibm.com) (32.97.182.139)
	by server-14.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 30 Nov 2011 08:59:40 -0000
Received: from /spool/local
	by e9.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only!
	Violators will be prosecuted for <xen-devel@lists.xensource.com> from
	<raghavendra.kt@linux.vnet.ibm.com>; Wed, 30 Nov 2011 03:59:38 -0500
Received: from d01relay07.pok.ibm.com ([9.56.227.147])
	by e9.ny.us.ibm.com ([192.168.1.109]) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Wed, 30 Nov 2011 03:59:36 -0500
Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216])
	by d01relay07.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	pAU8xZJM3690698
	for <xen-devel@lists.xensource.com>; Wed, 30 Nov 2011 03:59:35 -0500
Received: from d01av02.pok.ibm.com (loopback [127.0.0.1])
	by d01av02.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id
	pAU8xQnN021555
	for <xen-devel@lists.xensource.com>; Wed, 30 Nov 2011 06:59:34 -0200
Received: from oc5400248562.ibm.com (oc5400248562.in.ibm.com [9.124.158.199])
	by d01av02.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	pAU8xII0020751; Wed, 30 Nov 2011 06:59:19 -0200
From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
To: Greg Kroah-Hartman <gregkh@suse.de>, Sedat Dilek <sedat.dilek@gmail.com>, 
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	KVM <kvm@vger.kernel.org>,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>, x86@kernel.org,
	"H. Peter Anvin" <hpa@zytor.com>, Dave Jiang <dave.jiang@intel.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Marcelo Tosatti <mtosatti@redhat.com>, Yinghai Lu <yinghai@kernel.org>, 
	Gleb Natapov <gleb@redhat.com>, Ingo Molnar <mingo@redhat.com>,
	Avi Kivity <avi@redhat.com>, Xen <xen-devel@lists.xensource.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Rik van Riel <riel@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	LKML <linux-kernel@vger.kernel.org>
Date: Wed, 30 Nov 2011 14:29:21 +0530
Message-Id: <20111130085921.23386.89708.sendpatchset@oc5400248562.ibm.com>
x-cbid: 11113008-7182-0000-0000-0000004827AB
X-Mailman-Approved-At: Thu, 01 Dec 2011 10:36:45 +0000
Cc: Peter Zijlstra <peterz@infradead.org>,
	Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Dave Hansen <dave@linux.vnet.ibm.com>,
	Suzuki Poulose <suzuki@linux.vnet.ibm.com>,
	Sasha Levin <levinsasha928@gmail.com>
Subject: [Xen-devel] [PATCH RFC V3 0/4] kvm : Paravirt-spinlock support for
	KVM guests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

The 4-patch series to follow this email extends KVM-hypervisor and Linux guest 
running on KVM-hypervisor to support pv-ticket spinlocks, based on Xen's implementation.

One hypercall is introduced in KVM hypervisor,that allows a vcpu to kick
another vcpu out of halt state.
The blocking of vcpu is done using halt() in (lock_spinning) slowpath.

The V2 change discussion was in:  
 https://lkml.org/lkml/2011/10/23/207
 
Previous discussions : (posted by Srivatsa V).
https://lkml.org/lkml/2010/7/26/24
https://lkml.org/lkml/2011/1/19/212

The BASE patch is tip 3.2-rc1 + Jeremy's following patches.
xadd (https://lkml.org/lkml/2011/10/4/328)
x86/ticketlocklock  (https://lkml.org/lkml/2011/10/12/496).

Changes in V3:
- rebased to 3.2-rc1
- use halt() instead of wait for kick hypercall.
- modify kick hyper call to do wakeup halted vcpu.
- hook kvm_spinlock_init to smp_prepare_cpus call (moved the call out of head##.c).
- fix the potential race when zero_stat is read.
- export debugfs_create_32 and add documentation to API.
- use static inline and enum instead of ADDSTAT macro. 
- add  barrier() in after setting kick_vcpu.
- empty static inline function for kvm_spinlock_init.
- combine the patches one and two readuce overhead.
- make KVM_DEBUGFS depends on DEBUGFS.
- include debugfs header unconditionally.

Changes in V2:
- rebased patchesto -rc9
- synchronization related changes based on Jeremy's changes (Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>) pointed by
Stephan Diestelhorst <stephan.diestelhorst@amd.com>
- enabling 32 bit guests
- splitted patches into two more chunks

 Srivatsa Vaddagiri, Suzuki Poulose, Raghavendra K T (4): 
  Add debugfs support to print u32-arrays in debugfs
  Add a hypercall to KVM hypervisor to support pv-ticketlocks
  Added configuration support to enable debug information for KVM Guests
  pv-ticketlocks support for linux guests running on KVM hypervisor
 
Results:
 From the results we can see that patched kernel performance is similar to
 BASE when  there is no lock contention. But once we start seeing more 
 contention, patched kernel outperforms BASE.

set up : 
Kernel for host/guest : 3.2-rc1 + Jeremy's xadd, pv spinlock patches as BASE

3 guests with 8VCPU, 4GB RAM, 1 used for kernbench (kernbench -f -H -M -o 20) other for cpuhog (shell script while 
true with an instruction)

scenario A: unpinned

1x: no hogs
2x: 8hogs in one guest
3x: 8hogs each in two guest

Result for Non PLE machine :
Machine : IBM xSeries with Intel(R) Xeon(R) x5570 2.93GHz CPU with 8 core , 64GB RAM
		 BASE                    BASE+patch            %improvement
		 mean (sd)               mean (sd)
Scenario A:	 			
case 1x:	 157.548 (10.624) 	 156.408 (11.1622) 	0.723589
case 2x:	 1110.18 (807.019) 	 310.96 (105.194) 	71.9901
case 3x:	 3110.36 (2408.03) 	 303.688 (110.474) 	90.2362

Result for PLE machine:
Machine : IBM xSeries with Intel(R) Xeon(R)  X7560 2.27GHz CPU with 32/64 core, with 8  
         online cores and 4*64GB RAM

		 BASE                    BASE+patch            %improvement
		 mean (sd)               mean (sd)
Scenario A:	 			
case 1x:	 159.725 (47.4906) 	 159.07 (47.8133) 	0.41008
case 2x:	 190.957 (49.2976) 	 187.273 (50.5469) 	1.92923
case 3x:	 226.317 (88.6023) 	 223.698 (90.4362) 	1.15723

---
 13 files changed, 454 insertions(+), 112 deletions(-)
 arch/x86/Kconfig                |    9 ++
 arch/x86/include/asm/kvm_para.h |   17 +++-
 arch/x86/kernel/kvm.c           |  247 +++++++++++++++++++++++++++++++++++++++
 arch/x86/kvm/x86.c              |   28 +++++-
 arch/x86/xen/debugfs.c          |  104 ----------------
 arch/x86/xen/debugfs.h          |    4 -
 arch/x86/xen/spinlock.c         |    2 +-
 fs/debugfs/file.c               |  128 ++++++++++++++++++++
 include/linux/debugfs.h         |   11 ++
 include/linux/kvm.h             |    1 +
 include/linux/kvm_host.h        |    5 +
 include/linux/kvm_para.h        |    1 +
 virt/kvm/kvm_main.c             |    7 +
 13 files changed, 452 insertions(+), 112 deletions(-)


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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 10:36:56 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 10:36:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW40a-0004nf-2l; Thu, 01 Dec 2011 10:36:52 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <catalin.marinas@gmail.com>) id 1RVktP-0004VW-5m
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 14:12:11 +0000
X-Env-Sender: catalin.marinas@gmail.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1322662291!5248335!1
X-Originating-IP: [209.85.216.50]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12943 invoked from network); 30 Nov 2011 14:11:32 -0000
Received: from mail-qw0-f50.google.com (HELO mail-qw0-f50.google.com)
	(209.85.216.50)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Nov 2011 14:11:32 -0000
Received: by qabg14 with SMTP id g14so97039qab.9
	for <xen-devel@lists.xensource.com>;
	Wed, 30 Nov 2011 06:11:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:from:date
	:x-google-sender-auth:message-id:subject:to:cc:content-type;
	bh=5+o6cpS24kBsj7vi3lX5QAdQTy91t6MfO0589otJ+3Y=;
	b=FQifRYKILTStw0ksvrIQb9hlpV3xTm02GL9ipycVNZ4ekVZvZ7SKLuM4ROBm8sZh7/
	0PVTT/dbtSdbtpMoIEq18Y9hLytaEZlRYVcvN9F5gfVjcwyym3gfxYDirkOzzDNytjXq
	AYo1XHHX+6OzXrHKRXTgNVV1cgRc9VAXC7weY=
Received: by 10.229.34.1 with SMTP id j1mr319482qcd.131.1322662291284; Wed, 30
	Nov 2011 06:11:31 -0800 (PST)
MIME-Version: 1.0
Received: by 10.229.248.146 with HTTP; Wed, 30 Nov 2011 06:11:10 -0800 (PST)
In-Reply-To: <alpine.DEB.2.00.1111301053300.31179@kaball-desktop>
References: <alpine.DEB.2.00.1111281009090.31179@kaball-desktop>
	<201111292129.20444.arnd@arndb.de>
	<alpine.DEB.2.00.1111301053300.31179@kaball-desktop>
From: Catalin Marinas <catalin.marinas@arm.com>
Date: Wed, 30 Nov 2011 14:11:10 +0000
X-Google-Sender-Auth: _zyn3ZrIA15MRST2lEiNTiQB5m0
Message-ID: <CAHkRjk48jHO19H04rf8252+v04hk9qSdKBrfYCqJsZyamVhMEw@mail.gmail.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-Mailman-Approved-At: Thu, 01 Dec 2011 10:36:45 +0000
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linaro-dev@lists.linaro.org" <linaro-dev@lists.linaro.org>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>, Arnd Bergmann <arnd@arndb.de>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"virtualization@lists.linux-foundation.org"
	<virtualization@lists.linux-foundation.org>,
	"android-virt@lists.cs.columbia.edu" <android-virt@lists.cs.columbia.edu>,
	"embeddedxen-devel@lists.sourceforge.net"
	<embeddedxen-devel@lists.sourceforge.net>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [ANNOUNCE] Xen port to Cortex-A15 / ARMv7 with virt
	extensions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 30 November 2011 11:39, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:
> A git branch is available here (not ready for submission):
>
> git://xenbits.xen.org/people/sstabellini/linux-pvhvm.git arm
>
> the branch above is based on git://linux-arm.org/linux-2.6.git arm-lpae,
> even though guests don't really need lpae support to run on Xen.

Indeed, you don't really need LPAE. What you may need though is
generic timers support for A15, it would allow less Hypervisor traps.
For up-to-date architecture patches (well, development tree, not
guaranteed to be stable), I would recommend this (they get into
mainline at some point):

http://git.kernel.org/?p=linux/kernel/git/cmarinas/linux-arm-arch.git;a=summary

Either use master or just cherry-pick the branches that you are interested in.

-- 
Catalin

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 10:36:56 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 10:36:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW40Z-0004nG-N1; Thu, 01 Dec 2011 10:36:51 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raghavendra.kt@linux.vnet.ibm.com>)
	id 1RVg3J-0007hI-6x
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 09:02:05 +0000
X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1322643684!5251929!1
X-Originating-IP: [32.97.110.149]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMzIuOTcuMTEwLjE0OSA9PiA3OTM4OQ==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6146 invoked from network); 30 Nov 2011 09:01:26 -0000
Received: from e31.co.us.ibm.com (HELO e31.co.us.ibm.com) (32.97.110.149)
	by server-14.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 30 Nov 2011 09:01:26 -0000
Received: from /spool/local
	by e31.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only!
	Violators will be prosecuted for <xen-devel@lists.xensource.com> from
	<raghavendra.kt@linux.vnet.ibm.com>; Wed, 30 Nov 2011 02:01:16 -0700
Received: from d03relay04.boulder.ibm.com ([9.17.195.106])
	by e31.co.us.ibm.com ([192.168.1.131]) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Wed, 30 Nov 2011 02:00:54 -0700
Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170])
	by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	pAU90lO4139978
	for <xen-devel@lists.xensource.com>; Wed, 30 Nov 2011 02:00:47 -0700
Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1])
	by d03av04.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP
	id pAU90jng030420
	for <xen-devel@lists.xensource.com>; Wed, 30 Nov 2011 02:00:47 -0700
Received: from oc5400248562.ibm.com (oc5400248562.in.ibm.com [9.124.158.199])
	by d03av04.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP
	id pAU90ZoW029372; Wed, 30 Nov 2011 02:00:37 -0700
From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
To: Greg Kroah-Hartman <gregkh@suse.de>, KVM <kvm@vger.kernel.org>,
	Sedat Dilek <sedat.dilek@gmail.com>, Ingo Molnar <mingo@redhat.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>, x86@kernel.org,
	"H. Peter Anvin" <hpa@zytor.com>, Dave Jiang <dave.jiang@intel.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Gleb Natapov <gleb@redhat.com>, Yinghai Lu <yinghai@kernel.org>,
	Marcelo Tosatti <mtosatti@redhat.com>,
	Xen <xen-devel@lists.xensource.com>, Avi Kivity <avi@redhat.com>,
	Rik van Riel <riel@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	LKML <linux-kernel@vger.kernel.org>
Date: Wed, 30 Nov 2011 14:30:38 +0530
Message-Id: <20111130090038.23386.4505.sendpatchset@oc5400248562.ibm.com>
In-Reply-To: <20111130085921.23386.89708.sendpatchset@oc5400248562.ibm.com>
References: <20111130085921.23386.89708.sendpatchset@oc5400248562.ibm.com>
x-cbid: 11113009-7282-0000-0000-0000048B2800
X-Mailman-Approved-At: Thu, 01 Dec 2011 10:36:45 +0000
Cc: Peter Zijlstra <peterz@infradead.org>,
	Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Dave Hansen <dave@linux.vnet.ibm.com>,
	Suzuki Poulose <suzuki@linux.vnet.ibm.com>,
	Sasha Levin <levinsasha928@gmail.com>
Subject: [Xen-devel] [PATCH RFC V3 4/4] kvm : pv-ticketlocks support for
	linux guests running on KVM hypervisor
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This patch extends Linux guests running on KVM hypervisor to support
pv-ticketlocks. 
During smp_boot_cpus  paravirtualied KVM guest detects if the hypervisor has
required feature (KVM_FEATURE_KICK_VCPU) to support pv-ticketlocks. If so,
 support for pv-ticketlocks is registered via pv_lock_ops.

Signed-off-by: Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>
Signed-off-by: Suzuki Poulose <suzuki@in.ibm.com>
Signed-off-by: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
---
diff --git a/arch/x86/include/asm/kvm_para.h b/arch/x86/include/asm/kvm_para.h
index 8b1d65d..7e419ad 100644
--- a/arch/x86/include/asm/kvm_para.h
+++ b/arch/x86/include/asm/kvm_para.h
@@ -195,10 +195,21 @@ void kvm_async_pf_task_wait(u32 token);
 void kvm_async_pf_task_wake(u32 token);
 u32 kvm_read_and_reset_pf_reason(void);
 extern void kvm_disable_steal_time(void);
-#else
-#define kvm_guest_init() do { } while (0)
+
+#ifdef CONFIG_PARAVIRT_SPINLOCKS
+void __init kvm_spinlock_init(void);
+#else /* CONFIG_PARAVIRT_SPINLOCKS */
+static void kvm_spinlock_init(void)
+{
+}
+#endif /* CONFIG_PARAVIRT_SPINLOCKS */
+
+#else /* CONFIG_KVM_GUEST */
+#define kvm_guest_init() do {} while (0)
 #define kvm_async_pf_task_wait(T) do {} while(0)
 #define kvm_async_pf_task_wake(T) do {} while(0)
+#define kvm_spinlock_init() do {} while (0)
+
 static inline u32 kvm_read_and_reset_pf_reason(void)
 {
 	return 0;
diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c
index a9c2116..dffeea3 100644
--- a/arch/x86/kernel/kvm.c
+++ b/arch/x86/kernel/kvm.c
@@ -33,6 +33,7 @@
 #include <linux/sched.h>
 #include <linux/slab.h>
 #include <linux/kprobes.h>
+#include <linux/debugfs.h>
 #include <asm/timer.h>
 #include <asm/cpu.h>
 #include <asm/traps.h>
@@ -545,6 +546,7 @@ static void __init kvm_smp_prepare_boot_cpu(void)
 #endif
 	kvm_guest_cpu_init();
 	native_smp_prepare_boot_cpu();
+	kvm_spinlock_init();
 }
 
 static void __cpuinit kvm_guest_cpu_online(void *dummy)
@@ -627,3 +629,248 @@ static __init int activate_jump_labels(void)
 	return 0;
 }
 arch_initcall(activate_jump_labels);
+
+#ifdef CONFIG_PARAVIRT_SPINLOCKS
+
+enum kvm_contention_stat {
+	TAKEN_SLOW,
+	TAKEN_SLOW_PICKUP,
+	RELEASED_SLOW,
+	RELEASED_SLOW_KICKED,
+	NR_CONTENTION_STATS
+};
+
+#ifdef CONFIG_KVM_DEBUG_FS
+
+static struct kvm_spinlock_stats
+{
+	u32 contention_stats[NR_CONTENTION_STATS];
+
+#define HISTO_BUCKETS	30
+	u32 histo_spin_blocked[HISTO_BUCKETS+1];
+
+	u64 time_blocked;
+} spinlock_stats;
+
+static u8 zero_stats;
+
+static inline void check_zero(void)
+{
+	u8 ret;
+	u8 old = ACCESS_ONCE(zero_stats);
+	if (unlikely(old)) {
+		ret = cmpxchg(&zero_stats, old, 0);
+		/* This ensures only one fellow resets the stat */
+		if (ret == old)
+			memset(&spinlock_stats, 0, sizeof(spinlock_stats));
+	}
+}
+
+static inline void add_stats(enum kvm_contention_stat var, int val)
+{
+	check_zero();
+	spinlock_stats.contention_stats[var] += val;
+}
+
+
+static inline u64 spin_time_start(void)
+{
+	return sched_clock();
+}
+
+static void __spin_time_accum(u64 delta, u32 *array)
+{
+	unsigned index = ilog2(delta);
+
+	check_zero();
+
+	if (index < HISTO_BUCKETS)
+		array[index]++;
+	else
+		array[HISTO_BUCKETS]++;
+}
+
+static inline void spin_time_accum_blocked(u64 start)
+{
+	u32 delta = sched_clock() - start;
+
+	__spin_time_accum(delta, spinlock_stats.histo_spin_blocked);
+	spinlock_stats.time_blocked += delta;
+}
+
+static struct dentry *d_spin_debug;
+static struct dentry *d_kvm_debug;
+
+struct dentry *kvm_init_debugfs(void)
+{
+	d_kvm_debug = debugfs_create_dir("kvm", NULL);
+	if (!d_kvm_debug)
+		printk(KERN_WARNING "Could not create 'kvm' debugfs directory\n");
+
+	return d_kvm_debug;
+}
+
+static int __init kvm_spinlock_debugfs(void)
+{
+	struct dentry *d_kvm = kvm_init_debugfs();
+
+	if (d_kvm == NULL)
+		return -ENOMEM;
+
+	d_spin_debug = debugfs_create_dir("spinlocks", d_kvm);
+
+	debugfs_create_u8("zero_stats", 0644, d_spin_debug, &zero_stats);
+
+	debugfs_create_u32("taken_slow", 0444, d_spin_debug,
+		   &spinlock_stats.contention_stats[TAKEN_SLOW]);
+	debugfs_create_u32("taken_slow_pickup", 0444, d_spin_debug,
+		   &spinlock_stats.contention_stats[TAKEN_SLOW_PICKUP]);
+
+	debugfs_create_u32("released_slow", 0444, d_spin_debug,
+		   &spinlock_stats.contention_stats[RELEASED_SLOW]);
+	debugfs_create_u32("released_slow_kicked", 0444, d_spin_debug,
+		   &spinlock_stats.contention_stats[RELEASED_SLOW_KICKED]);
+
+	debugfs_create_u64("time_blocked", 0444, d_spin_debug,
+			   &spinlock_stats.time_blocked);
+
+	debugfs_create_u32_array("histo_blocked", 0444, d_spin_debug,
+		     spinlock_stats.histo_spin_blocked, HISTO_BUCKETS + 1);
+
+	return 0;
+}
+fs_initcall(kvm_spinlock_debugfs);
+#else  /* !CONFIG_KVM_DEBUG_FS */
+#define TIMEOUT			(1 << 10)
+static inline void add_stats(enum kvm_contention_stat var, u32 val)
+{
+}
+
+static inline u64 spin_time_start(void)
+{
+	return 0;
+}
+
+static inline void spin_time_accum_blocked(u64 start)
+{
+}
+#endif  /* CONFIG_KVM_DEBUG_FS */
+
+struct kvm_lock_waiting {
+	struct arch_spinlock *lock;
+	__ticket_t want;
+};
+
+/* cpus 'waiting' on a spinlock to become available */
+static cpumask_t waiting_cpus;
+
+/* Track spinlock on which a cpu is waiting */
+static DEFINE_PER_CPU(struct kvm_lock_waiting, lock_waiting);
+
+static void kvm_lock_spinning(struct arch_spinlock *lock, __ticket_t want)
+{
+	struct kvm_lock_waiting *w = &__get_cpu_var(lock_waiting);
+	int cpu = smp_processor_id();
+	u64 start;
+	unsigned long flags;
+
+	start = spin_time_start();
+
+	/*
+	 * Make sure an interrupt handler can't upset things in a
+	 * partially setup state.
+	 */
+	local_irq_save(flags);
+
+	/*
+	 * The ordering protocol on this is that the "lock" pointer
+	 * may only be set non-NULL if the "want" ticket is correct.
+	 * If we're updating "want", we must first clear "lock".
+	 */
+	w->lock = NULL;
+	smp_wmb();
+	w->want = want;
+	smp_wmb();
+	w->lock = lock;
+
+	add_stats(TAKEN_SLOW, 1);
+
+	/*
+	 * This uses set_bit, which is atomic but we should not rely on its
+	 * reordering gurantees. So barrier is needed after this call.
+	 */
+	cpumask_set_cpu(cpu, &waiting_cpus);
+
+	barrier();
+
+	/*
+	 * Mark entry to slowpath before doing the pickup test to make
+	 * sure we don't deadlock with an unlocker.
+	 */
+	__ticket_enter_slowpath(lock);
+
+	/*
+	 * check again make sure it didn't become free while
+	 * we weren't looking.
+	 */
+	if (ACCESS_ONCE(lock->tickets.head) == want) {
+		add_stats(TAKEN_SLOW_PICKUP, 1);
+		goto out;
+	}
+
+	/* Allow interrupts while blocked */
+	local_irq_restore(flags);
+
+	/* halt until it's our turn and kicked. */
+	halt();
+
+	local_irq_save(flags);
+out:
+	cpumask_clear_cpu(cpu, &waiting_cpus);
+	w->lock = NULL;
+	local_irq_restore(flags);
+	spin_time_accum_blocked(start);
+}
+PV_CALLEE_SAVE_REGS_THUNK(kvm_lock_spinning);
+
+/* Kick a cpu */
+static inline void kvm_kick_cpu(int cpu)
+{
+	kvm_hypercall1(KVM_HC_KICK_CPU, cpu);
+}
+
+/* Kick vcpu waiting on @lock->head to reach value @ticket */
+static void kvm_unlock_kick(struct arch_spinlock *lock, __ticket_t ticket)
+{
+	int cpu;
+
+	add_stats(RELEASED_SLOW, 1);
+
+	for_each_cpu(cpu, &waiting_cpus) {
+		const struct kvm_lock_waiting *w = &per_cpu(lock_waiting, cpu);
+		if (ACCESS_ONCE(w->lock) == lock &&
+		    ACCESS_ONCE(w->want) == ticket) {
+			add_stats(RELEASED_SLOW_KICKED, 1);
+			kvm_kick_cpu(cpu);
+			break;
+		}
+	}
+}
+
+/*
+ * Setup pv_lock_ops to exploit KVM_FEATURE_KICK_VCPU if present.
+ */
+void __init kvm_spinlock_init(void)
+{
+	if (!kvm_para_available())
+		return;
+	/* Does host kernel support KVM_FEATURE_KICK_VCPU? */
+	if (!kvm_para_has_feature(KVM_FEATURE_KICK_VCPU))
+		return;
+
+	jump_label_inc(&paravirt_ticketlocks_enabled);
+
+	pv_lock_ops.lock_spinning = PV_CALLEE_SAVE(kvm_lock_spinning);
+	pv_lock_ops.unlock_kick = kvm_unlock_kick;
+}
+#endif	/* CONFIG_PARAVIRT_SPINLOCKS */
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index 8f4b6db..a89546b 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -1518,6 +1518,12 @@ void kvm_vcpu_block(struct kvm_vcpu *vcpu)
 			kvm_make_request(KVM_REQ_UNHALT, vcpu);
 			break;
 		}
+		if (vcpu->kicked) {
+			vcpu->kicked = 0;
+			barrier();
+			kvm_make_request(KVM_REQ_UNHALT, vcpu);
+			break;
+		}
 		if (kvm_cpu_has_pending_timer(vcpu))
 			break;
 		if (signal_pending(current))


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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 10:36:56 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 10:36:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW40Y-0004lw-23; Thu, 01 Dec 2011 10:36:50 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raghavendra.kt@linux.vnet.ibm.com>)
	id 1RVg1b-0007et-EY
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 09:00:19 +0000
X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1322643579!3465960!1
X-Originating-IP: [32.97.182.139]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMzIuOTcuMTgyLjEzOSA9PiA0ODUyODU=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15135 invoked from network); 30 Nov 2011 08:59:40 -0000
Received: from e9.ny.us.ibm.com (HELO e9.ny.us.ibm.com) (32.97.182.139)
	by server-14.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 30 Nov 2011 08:59:40 -0000
Received: from /spool/local
	by e9.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only!
	Violators will be prosecuted for <xen-devel@lists.xensource.com> from
	<raghavendra.kt@linux.vnet.ibm.com>; Wed, 30 Nov 2011 03:59:38 -0500
Received: from d01relay07.pok.ibm.com ([9.56.227.147])
	by e9.ny.us.ibm.com ([192.168.1.109]) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Wed, 30 Nov 2011 03:59:36 -0500
Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216])
	by d01relay07.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	pAU8xZJM3690698
	for <xen-devel@lists.xensource.com>; Wed, 30 Nov 2011 03:59:35 -0500
Received: from d01av02.pok.ibm.com (loopback [127.0.0.1])
	by d01av02.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id
	pAU8xQnN021555
	for <xen-devel@lists.xensource.com>; Wed, 30 Nov 2011 06:59:34 -0200
Received: from oc5400248562.ibm.com (oc5400248562.in.ibm.com [9.124.158.199])
	by d01av02.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	pAU8xII0020751; Wed, 30 Nov 2011 06:59:19 -0200
From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
To: Greg Kroah-Hartman <gregkh@suse.de>, Sedat Dilek <sedat.dilek@gmail.com>, 
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	KVM <kvm@vger.kernel.org>,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>, x86@kernel.org,
	"H. Peter Anvin" <hpa@zytor.com>, Dave Jiang <dave.jiang@intel.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Marcelo Tosatti <mtosatti@redhat.com>, Yinghai Lu <yinghai@kernel.org>, 
	Gleb Natapov <gleb@redhat.com>, Ingo Molnar <mingo@redhat.com>,
	Avi Kivity <avi@redhat.com>, Xen <xen-devel@lists.xensource.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Rik van Riel <riel@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	LKML <linux-kernel@vger.kernel.org>
Date: Wed, 30 Nov 2011 14:29:21 +0530
Message-Id: <20111130085921.23386.89708.sendpatchset@oc5400248562.ibm.com>
x-cbid: 11113008-7182-0000-0000-0000004827AB
X-Mailman-Approved-At: Thu, 01 Dec 2011 10:36:45 +0000
Cc: Peter Zijlstra <peterz@infradead.org>,
	Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Dave Hansen <dave@linux.vnet.ibm.com>,
	Suzuki Poulose <suzuki@linux.vnet.ibm.com>,
	Sasha Levin <levinsasha928@gmail.com>
Subject: [Xen-devel] [PATCH RFC V3 0/4] kvm : Paravirt-spinlock support for
	KVM guests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

The 4-patch series to follow this email extends KVM-hypervisor and Linux guest 
running on KVM-hypervisor to support pv-ticket spinlocks, based on Xen's implementation.

One hypercall is introduced in KVM hypervisor,that allows a vcpu to kick
another vcpu out of halt state.
The blocking of vcpu is done using halt() in (lock_spinning) slowpath.

The V2 change discussion was in:  
 https://lkml.org/lkml/2011/10/23/207
 
Previous discussions : (posted by Srivatsa V).
https://lkml.org/lkml/2010/7/26/24
https://lkml.org/lkml/2011/1/19/212

The BASE patch is tip 3.2-rc1 + Jeremy's following patches.
xadd (https://lkml.org/lkml/2011/10/4/328)
x86/ticketlocklock  (https://lkml.org/lkml/2011/10/12/496).

Changes in V3:
- rebased to 3.2-rc1
- use halt() instead of wait for kick hypercall.
- modify kick hyper call to do wakeup halted vcpu.
- hook kvm_spinlock_init to smp_prepare_cpus call (moved the call out of head##.c).
- fix the potential race when zero_stat is read.
- export debugfs_create_32 and add documentation to API.
- use static inline and enum instead of ADDSTAT macro. 
- add  barrier() in after setting kick_vcpu.
- empty static inline function for kvm_spinlock_init.
- combine the patches one and two readuce overhead.
- make KVM_DEBUGFS depends on DEBUGFS.
- include debugfs header unconditionally.

Changes in V2:
- rebased patchesto -rc9
- synchronization related changes based on Jeremy's changes (Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>) pointed by
Stephan Diestelhorst <stephan.diestelhorst@amd.com>
- enabling 32 bit guests
- splitted patches into two more chunks

 Srivatsa Vaddagiri, Suzuki Poulose, Raghavendra K T (4): 
  Add debugfs support to print u32-arrays in debugfs
  Add a hypercall to KVM hypervisor to support pv-ticketlocks
  Added configuration support to enable debug information for KVM Guests
  pv-ticketlocks support for linux guests running on KVM hypervisor
 
Results:
 From the results we can see that patched kernel performance is similar to
 BASE when  there is no lock contention. But once we start seeing more 
 contention, patched kernel outperforms BASE.

set up : 
Kernel for host/guest : 3.2-rc1 + Jeremy's xadd, pv spinlock patches as BASE

3 guests with 8VCPU, 4GB RAM, 1 used for kernbench (kernbench -f -H -M -o 20) other for cpuhog (shell script while 
true with an instruction)

scenario A: unpinned

1x: no hogs
2x: 8hogs in one guest
3x: 8hogs each in two guest

Result for Non PLE machine :
Machine : IBM xSeries with Intel(R) Xeon(R) x5570 2.93GHz CPU with 8 core , 64GB RAM
		 BASE                    BASE+patch            %improvement
		 mean (sd)               mean (sd)
Scenario A:	 			
case 1x:	 157.548 (10.624) 	 156.408 (11.1622) 	0.723589
case 2x:	 1110.18 (807.019) 	 310.96 (105.194) 	71.9901
case 3x:	 3110.36 (2408.03) 	 303.688 (110.474) 	90.2362

Result for PLE machine:
Machine : IBM xSeries with Intel(R) Xeon(R)  X7560 2.27GHz CPU with 32/64 core, with 8  
         online cores and 4*64GB RAM

		 BASE                    BASE+patch            %improvement
		 mean (sd)               mean (sd)
Scenario A:	 			
case 1x:	 159.725 (47.4906) 	 159.07 (47.8133) 	0.41008
case 2x:	 190.957 (49.2976) 	 187.273 (50.5469) 	1.92923
case 3x:	 226.317 (88.6023) 	 223.698 (90.4362) 	1.15723

---
 13 files changed, 454 insertions(+), 112 deletions(-)
 arch/x86/Kconfig                |    9 ++
 arch/x86/include/asm/kvm_para.h |   17 +++-
 arch/x86/kernel/kvm.c           |  247 +++++++++++++++++++++++++++++++++++++++
 arch/x86/kvm/x86.c              |   28 +++++-
 arch/x86/xen/debugfs.c          |  104 ----------------
 arch/x86/xen/debugfs.h          |    4 -
 arch/x86/xen/spinlock.c         |    2 +-
 fs/debugfs/file.c               |  128 ++++++++++++++++++++
 include/linux/debugfs.h         |   11 ++
 include/linux/kvm.h             |    1 +
 include/linux/kvm_host.h        |    5 +
 include/linux/kvm_para.h        |    1 +
 virt/kvm/kvm_main.c             |    7 +
 13 files changed, 452 insertions(+), 112 deletions(-)


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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 10:36:56 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 10:36:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW40W-0004l0-Pt; Thu, 01 Dec 2011 10:36:48 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andreslc@gridcentric.ca>) id 1RVU9D-0004dH-Ax
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 20:19:23 +0000
X-Env-Sender: andreslc@gridcentric.ca
X-Msg-Ref: server-8.tower-182.messagelabs.com!1322597924!634242!1
X-Originating-IP: [209.85.216.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16105 invoked from network); 29 Nov 2011 20:18:45 -0000
Received: from mail-qy0-f171.google.com (HELO mail-qy0-f171.google.com)
	(209.85.216.171)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 20:18:45 -0000
Received: by qyk29 with SMTP id 29so3737094qyk.30
	for <xen-devel@lists.xensource.com>;
	Tue, 29 Nov 2011 12:18:44 -0800 (PST)
Received: by 10.229.3.68 with SMTP id 4mr5591226qcm.278.1322597923850;
	Tue, 29 Nov 2011 12:18:43 -0800 (PST)
Received: from [192.168.5.143] ([206.223.182.18])
	by mx.google.com with ESMTPS id dm3sm38847838qab.12.2011.11.29.12.18.41
	(version=TLSv1/SSLv3 cipher=OTHER);
	Tue, 29 Nov 2011 12:18:41 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1251.1)
From: Andres Lagar-Cavilla <andreslc@gridcentric.ca>
In-Reply-To: <CAF50DE2.34CCA%keir@xen.org>
Date: Tue, 29 Nov 2011 15:18:59 -0500
Message-Id: <F37C935C-D7B1-4A6F-BA2C-95B044189E63@gridcentric.ca>
References: <CAF50DE2.34CCA%keir@xen.org>
To: Keir Fraser <keir@xen.org>
X-Mailer: Apple Mail (2.1251.1)
X-Mailman-Approved-At: Thu, 01 Dec 2011 10:36:45 +0000
Cc: xen-devel@lists.xensource.com, tim@xen.org, Jan Beulich <JBeulich@suse.com>,
	Adin Scannell <adin@gridcentric.ca>
Subject: Re: [Xen-devel] [PATCH] Don't trigger unnecessary shadow scans on
	p2m entry update
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Not sure about that. We need to check for either of two conditions on page->count_info. That it's zero, or that it's PGC_allocated | 1.

(__count & (PGC_count_mask|PGC_allocated)) matched against (1|PGC_allocated) would lose the zero case.

Resubmitting shortly.
Andres 

On Nov 25, 2011, at 4:18 AM, Keir Fraser wrote:

> On 25/11/2011 08:45, "Jan Beulich" <JBeulich@suse.com> wrote:
> 
>>>>> On 24.11.11 at 19:31, Keir Fraser <keir.xen@gmail.com> wrote:
>>> On 24/11/2011 17:58, "Andres Lagar-Cavilla" <andres@lagarcavilla.org> wrote:
>>>> @@ -815,6 +815,12 @@ static inline unsigned long vtlb_lookup(
>>>> }
>>>> #endif /* (SHADOW_OPTIMIZATIONS & SHOPT_VIRTUAL_TLB) */
>>>> 
>>>> +static inline int __check_page_no_refs(struct page_info *page)
>>>> +{
>>>> +    unsigned long __count = page->count_info;
>>>> +    return ( (__count & PGC_count_mask) ==
>>>> +             ((__count & PGC_allocated) ? 1 : 0) );
>>> 
>>> It's a fussy point, but it might be better to use
>>> atomic_read_ulong(&page->count_info) here, to ensure that the compiler reads
>>> the field once only. It's cheap (compiles to a single mov instruction), but
>>> atomic_read_ulong doesn't exist so you'd have to add its (obvious)
>>> definition to asm-x86/atomic.h
>> 
>> I think Tim suggested anyway to use
>> 
>> (__count & (PGC_count_mask|PGC_allocated)) matched against
>> (1|PGC_allocated) here, which would eliminate the multiple read
>> potential if used in a switch statement.
> 
> Yes, that would be better.
> 
> -- Keir
> 
>> Also, for clarity the function should probably return bool_t.
>> 
>> Jan
>> 
> 
> 


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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 10:36:56 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 10:36:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW40a-0004nf-2l; Thu, 01 Dec 2011 10:36:52 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <catalin.marinas@gmail.com>) id 1RVktP-0004VW-5m
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 14:12:11 +0000
X-Env-Sender: catalin.marinas@gmail.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1322662291!5248335!1
X-Originating-IP: [209.85.216.50]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12943 invoked from network); 30 Nov 2011 14:11:32 -0000
Received: from mail-qw0-f50.google.com (HELO mail-qw0-f50.google.com)
	(209.85.216.50)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Nov 2011 14:11:32 -0000
Received: by qabg14 with SMTP id g14so97039qab.9
	for <xen-devel@lists.xensource.com>;
	Wed, 30 Nov 2011 06:11:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:from:date
	:x-google-sender-auth:message-id:subject:to:cc:content-type;
	bh=5+o6cpS24kBsj7vi3lX5QAdQTy91t6MfO0589otJ+3Y=;
	b=FQifRYKILTStw0ksvrIQb9hlpV3xTm02GL9ipycVNZ4ekVZvZ7SKLuM4ROBm8sZh7/
	0PVTT/dbtSdbtpMoIEq18Y9hLytaEZlRYVcvN9F5gfVjcwyym3gfxYDirkOzzDNytjXq
	AYo1XHHX+6OzXrHKRXTgNVV1cgRc9VAXC7weY=
Received: by 10.229.34.1 with SMTP id j1mr319482qcd.131.1322662291284; Wed, 30
	Nov 2011 06:11:31 -0800 (PST)
MIME-Version: 1.0
Received: by 10.229.248.146 with HTTP; Wed, 30 Nov 2011 06:11:10 -0800 (PST)
In-Reply-To: <alpine.DEB.2.00.1111301053300.31179@kaball-desktop>
References: <alpine.DEB.2.00.1111281009090.31179@kaball-desktop>
	<201111292129.20444.arnd@arndb.de>
	<alpine.DEB.2.00.1111301053300.31179@kaball-desktop>
From: Catalin Marinas <catalin.marinas@arm.com>
Date: Wed, 30 Nov 2011 14:11:10 +0000
X-Google-Sender-Auth: _zyn3ZrIA15MRST2lEiNTiQB5m0
Message-ID: <CAHkRjk48jHO19H04rf8252+v04hk9qSdKBrfYCqJsZyamVhMEw@mail.gmail.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-Mailman-Approved-At: Thu, 01 Dec 2011 10:36:45 +0000
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linaro-dev@lists.linaro.org" <linaro-dev@lists.linaro.org>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>, Arnd Bergmann <arnd@arndb.de>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"virtualization@lists.linux-foundation.org"
	<virtualization@lists.linux-foundation.org>,
	"android-virt@lists.cs.columbia.edu" <android-virt@lists.cs.columbia.edu>,
	"embeddedxen-devel@lists.sourceforge.net"
	<embeddedxen-devel@lists.sourceforge.net>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [ANNOUNCE] Xen port to Cortex-A15 / ARMv7 with virt
	extensions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 30 November 2011 11:39, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:
> A git branch is available here (not ready for submission):
>
> git://xenbits.xen.org/people/sstabellini/linux-pvhvm.git arm
>
> the branch above is based on git://linux-arm.org/linux-2.6.git arm-lpae,
> even though guests don't really need lpae support to run on Xen.

Indeed, you don't really need LPAE. What you may need though is
generic timers support for A15, it would allow less Hypervisor traps.
For up-to-date architecture patches (well, development tree, not
guaranteed to be stable), I would recommend this (they get into
mainline at some point):

http://git.kernel.org/?p=linux/kernel/git/cmarinas/linux-arm-arch.git;a=summary

Either use master or just cherry-pick the branches that you are interested in.

-- 
Catalin

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 10:36:56 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 10:36:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW40W-0004l0-Pt; Thu, 01 Dec 2011 10:36:48 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andreslc@gridcentric.ca>) id 1RVU9D-0004dH-Ax
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 20:19:23 +0000
X-Env-Sender: andreslc@gridcentric.ca
X-Msg-Ref: server-8.tower-182.messagelabs.com!1322597924!634242!1
X-Originating-IP: [209.85.216.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16105 invoked from network); 29 Nov 2011 20:18:45 -0000
Received: from mail-qy0-f171.google.com (HELO mail-qy0-f171.google.com)
	(209.85.216.171)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 20:18:45 -0000
Received: by qyk29 with SMTP id 29so3737094qyk.30
	for <xen-devel@lists.xensource.com>;
	Tue, 29 Nov 2011 12:18:44 -0800 (PST)
Received: by 10.229.3.68 with SMTP id 4mr5591226qcm.278.1322597923850;
	Tue, 29 Nov 2011 12:18:43 -0800 (PST)
Received: from [192.168.5.143] ([206.223.182.18])
	by mx.google.com with ESMTPS id dm3sm38847838qab.12.2011.11.29.12.18.41
	(version=TLSv1/SSLv3 cipher=OTHER);
	Tue, 29 Nov 2011 12:18:41 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1251.1)
From: Andres Lagar-Cavilla <andreslc@gridcentric.ca>
In-Reply-To: <CAF50DE2.34CCA%keir@xen.org>
Date: Tue, 29 Nov 2011 15:18:59 -0500
Message-Id: <F37C935C-D7B1-4A6F-BA2C-95B044189E63@gridcentric.ca>
References: <CAF50DE2.34CCA%keir@xen.org>
To: Keir Fraser <keir@xen.org>
X-Mailer: Apple Mail (2.1251.1)
X-Mailman-Approved-At: Thu, 01 Dec 2011 10:36:45 +0000
Cc: xen-devel@lists.xensource.com, tim@xen.org, Jan Beulich <JBeulich@suse.com>,
	Adin Scannell <adin@gridcentric.ca>
Subject: Re: [Xen-devel] [PATCH] Don't trigger unnecessary shadow scans on
	p2m entry update
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Not sure about that. We need to check for either of two conditions on page->count_info. That it's zero, or that it's PGC_allocated | 1.

(__count & (PGC_count_mask|PGC_allocated)) matched against (1|PGC_allocated) would lose the zero case.

Resubmitting shortly.
Andres 

On Nov 25, 2011, at 4:18 AM, Keir Fraser wrote:

> On 25/11/2011 08:45, "Jan Beulich" <JBeulich@suse.com> wrote:
> 
>>>>> On 24.11.11 at 19:31, Keir Fraser <keir.xen@gmail.com> wrote:
>>> On 24/11/2011 17:58, "Andres Lagar-Cavilla" <andres@lagarcavilla.org> wrote:
>>>> @@ -815,6 +815,12 @@ static inline unsigned long vtlb_lookup(
>>>> }
>>>> #endif /* (SHADOW_OPTIMIZATIONS & SHOPT_VIRTUAL_TLB) */
>>>> 
>>>> +static inline int __check_page_no_refs(struct page_info *page)
>>>> +{
>>>> +    unsigned long __count = page->count_info;
>>>> +    return ( (__count & PGC_count_mask) ==
>>>> +             ((__count & PGC_allocated) ? 1 : 0) );
>>> 
>>> It's a fussy point, but it might be better to use
>>> atomic_read_ulong(&page->count_info) here, to ensure that the compiler reads
>>> the field once only. It's cheap (compiles to a single mov instruction), but
>>> atomic_read_ulong doesn't exist so you'd have to add its (obvious)
>>> definition to asm-x86/atomic.h
>> 
>> I think Tim suggested anyway to use
>> 
>> (__count & (PGC_count_mask|PGC_allocated)) matched against
>> (1|PGC_allocated) here, which would eliminate the multiple read
>> potential if used in a switch statement.
> 
> Yes, that would be better.
> 
> -- Keir
> 
>> Also, for clarity the function should probably return bool_t.
>> 
>> Jan
>> 
> 
> 


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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 10:42:09 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 10: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.xensource.com>)
	id 1RW45c-0001Rt-0q; Thu, 01 Dec 2011 10:42:04 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mail.baruchi@gmail.com>)
	id 1RW45a-0001Ob-ON; Thu, 01 Dec 2011 10:42:02 +0000
X-Env-Sender: mail.baruchi@gmail.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1322736081!3840027!1
X-Originating-IP: [209.85.220.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8617 invoked from network); 1 Dec 2011 10:41:22 -0000
Received: from mail-vx0-f171.google.com (HELO mail-vx0-f171.google.com)
	(209.85.220.171)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 10:41:22 -0000
Received: by vcbfo1 with SMTP id fo1so5522395vcb.30
	for <multiple recipients>; Thu, 01 Dec 2011 02:41:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=rquKlEImcGF2D2fTJ4jJGyDKljmSDJX8b1zcmuuUHa0=;
	b=Q1rZBJPK7jtaCgxP//rhlEXSNPRx32qjhl5hV1y+mDO/Npjay9B0EIdNAOaYZWobHI
	aXG6KUy9i/A7oLjeph4wzJ/atwSzyCml5mfphcvsO9CeXwpXLgJdhDqstDSejs+bD910
	TNs8onW3JNlZqAfT41+icOenBfB3u8+CGy/FE=
MIME-Version: 1.0
Received: by 10.220.153.12 with SMTP id i12mr1162802vcw.7.1322736080722; Thu,
	01 Dec 2011 02:41:20 -0800 (PST)
Received: by 10.52.187.4 with HTTP; Thu, 1 Dec 2011 02:41:20 -0800 (PST)
In-Reply-To: <CAG1y0sfjmeDoLJ131TV-GUphhcuu+LcmJLJC-3h5=DzMKe7Jmg@mail.gmail.com>
References: <CAAiDW_RNUWUUm7rsgXUMJnc6gnQ7FbEv0eVX-tJQ+PAnjrOmeg@mail.gmail.com>
	<CAAiDW_Trg-B8Bq=sjnedZoxjxi2T+H=ADvuiBdE8jr+B1a5Jgg@mail.gmail.com>
	<20111130221545.GB16651@andromeda.dapyr.net>
	<CAAiDW_T2Eutw=NibLv2s1f1DJsbSY39oHL_pH8RkmAi=iWK0HA@mail.gmail.com>
	<20111201031601.GA32261@andromeda.dapyr.net>
	<CAG1y0sfjmeDoLJ131TV-GUphhcuu+LcmJLJC-3h5=DzMKe7Jmg@mail.gmail.com>
Date: Thu, 1 Dec 2011 08:41:20 -0200
Message-ID: <CAAiDW_SRBf2jx_q=CysoQq8c=JDM6gXSfnpBvOi-z6=wSCmaDg@mail.gmail.com>
From: Artur Baruchi <mail.baruchi@gmail.com>
To: "Fajar A. Nugraha" <list@fajar.net>
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>, Xen-devel@lists.xensource.com,
	xen-users <Xen-users@lists.xensource.com>
Subject: Re: [Xen-devel] VM Hanging after reboot
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi.

The error is within the guest (HVM virtual machine).

Thanks.

Att.
Artur Baruchi



On Thu, Dec 1, 2011 at 1:28 AM, Fajar A. Nugraha <list@fajar.net> wrote:
> On Thu, Dec 1, 2011 at 10:16 AM, Konrad Rzeszutek Wilk
> <konrad@darnok.org> wrote:
>> On Wed, Nov 30, 2011 at 09:09:58PM -0200, Artur Baruchi wrote:
>>> Hi Konrad.
>>>
>>> That was my first though (disk going bad). But I create another VM in
>>> a different host and faced the same error. I tried to create another
>>
>> So is the error from within the guest or from the dom0?
>>
>
> As Konrad asked, is the error in dom0 or domU?
>
> If dom0, then most likely it's disk problem. One way to diagnose it is
> by reading from the disk (dd_rescue is nice) and see if at least it's
> able to read the disk completely.
>
> If domU, then it's probably a bug in dom0 kernel (the blkback driver,
> perhaps). In which case novell guys might be able to help you more. I
> recall something like this when using older kernel for dom0 (forgot
> the exact version, sorry), but the error went away after I used
> vanilla 3.1.0 for dom0 kernel.
>
> --
> Fajar

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 10:42:09 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 10: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.xensource.com>)
	id 1RW45c-0001Rt-0q; Thu, 01 Dec 2011 10:42:04 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mail.baruchi@gmail.com>)
	id 1RW45a-0001Ob-ON; Thu, 01 Dec 2011 10:42:02 +0000
X-Env-Sender: mail.baruchi@gmail.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1322736081!3840027!1
X-Originating-IP: [209.85.220.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8617 invoked from network); 1 Dec 2011 10:41:22 -0000
Received: from mail-vx0-f171.google.com (HELO mail-vx0-f171.google.com)
	(209.85.220.171)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 10:41:22 -0000
Received: by vcbfo1 with SMTP id fo1so5522395vcb.30
	for <multiple recipients>; Thu, 01 Dec 2011 02:41:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=rquKlEImcGF2D2fTJ4jJGyDKljmSDJX8b1zcmuuUHa0=;
	b=Q1rZBJPK7jtaCgxP//rhlEXSNPRx32qjhl5hV1y+mDO/Npjay9B0EIdNAOaYZWobHI
	aXG6KUy9i/A7oLjeph4wzJ/atwSzyCml5mfphcvsO9CeXwpXLgJdhDqstDSejs+bD910
	TNs8onW3JNlZqAfT41+icOenBfB3u8+CGy/FE=
MIME-Version: 1.0
Received: by 10.220.153.12 with SMTP id i12mr1162802vcw.7.1322736080722; Thu,
	01 Dec 2011 02:41:20 -0800 (PST)
Received: by 10.52.187.4 with HTTP; Thu, 1 Dec 2011 02:41:20 -0800 (PST)
In-Reply-To: <CAG1y0sfjmeDoLJ131TV-GUphhcuu+LcmJLJC-3h5=DzMKe7Jmg@mail.gmail.com>
References: <CAAiDW_RNUWUUm7rsgXUMJnc6gnQ7FbEv0eVX-tJQ+PAnjrOmeg@mail.gmail.com>
	<CAAiDW_Trg-B8Bq=sjnedZoxjxi2T+H=ADvuiBdE8jr+B1a5Jgg@mail.gmail.com>
	<20111130221545.GB16651@andromeda.dapyr.net>
	<CAAiDW_T2Eutw=NibLv2s1f1DJsbSY39oHL_pH8RkmAi=iWK0HA@mail.gmail.com>
	<20111201031601.GA32261@andromeda.dapyr.net>
	<CAG1y0sfjmeDoLJ131TV-GUphhcuu+LcmJLJC-3h5=DzMKe7Jmg@mail.gmail.com>
Date: Thu, 1 Dec 2011 08:41:20 -0200
Message-ID: <CAAiDW_SRBf2jx_q=CysoQq8c=JDM6gXSfnpBvOi-z6=wSCmaDg@mail.gmail.com>
From: Artur Baruchi <mail.baruchi@gmail.com>
To: "Fajar A. Nugraha" <list@fajar.net>
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>, Xen-devel@lists.xensource.com,
	xen-users <Xen-users@lists.xensource.com>
Subject: Re: [Xen-devel] VM Hanging after reboot
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi.

The error is within the guest (HVM virtual machine).

Thanks.

Att.
Artur Baruchi



On Thu, Dec 1, 2011 at 1:28 AM, Fajar A. Nugraha <list@fajar.net> wrote:
> On Thu, Dec 1, 2011 at 10:16 AM, Konrad Rzeszutek Wilk
> <konrad@darnok.org> wrote:
>> On Wed, Nov 30, 2011 at 09:09:58PM -0200, Artur Baruchi wrote:
>>> Hi Konrad.
>>>
>>> That was my first though (disk going bad). But I create another VM in
>>> a different host and faced the same error. I tried to create another
>>
>> So is the error from within the guest or from the dom0?
>>
>
> As Konrad asked, is the error in dom0 or domU?
>
> If dom0, then most likely it's disk problem. One way to diagnose it is
> by reading from the disk (dd_rescue is nice) and see if at least it's
> able to read the disk completely.
>
> If domU, then it's probably a bug in dom0 kernel (the blkback driver,
> perhaps). In which case novell guys might be able to help you more. I
> recall something like this when using older kernel for dom0 (forgot
> the exact version, sorry), but the error went away after I used
> vanilla 3.1.0 for dom0 kernel.
>
> --
> Fajar

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 10:48:26 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 10:48:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW4BZ-0002tE-Q8; Thu, 01 Dec 2011 10:48:13 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RW4BY-0002sN-Hd
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 10:48:12 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1322736452!5440769!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU2Nw==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22858 invoked from network); 1 Dec 2011 10:47:32 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 10:47:32 -0000
X-IronPort-AV: E=Sophos;i="4.71,277,1320624000"; 
   d="scan'208";a="9225739"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Dec 2011 10:47:02 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 1 Dec 2011
	10:47:02 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Adda Rathbone <addarathbone@googlemail.com>
Date: Thu, 1 Dec 2011 10:47:02 +0000
In-Reply-To: <CANrAofX3ARD8CN8HtoBnetfMZvBUS5RSC89ExuGoVSzqmE2V9A@mail.gmail.com>
References: <CANrAofX3ARD8CN8HtoBnetfMZvBUS5RSC89ExuGoVSzqmE2V9A@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322736422.31810.197.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Compile error with Ubuntu 11.10
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gV2VkLCAyMDExLTExLTMwIGF0IDIxOjE5ICswMDAwLCBBZGRhIFJhdGhib25lIHdyb3RlOgo+
IEhpLAo+IGNvbXBpbGF0aW9uIG9mIHhlbi11bnN0YWJsZSB3aXRoIGEgZnJlc2ggVWJ1bnR1IDEx
LjEwIHg4Nl82NCBmYWlscwo+IHdpdGggZm9sbG93aW5nIGVycm9yOgo+IAo+IGNjMTogd2Fybmlu
Z3MgYmVpbmcgdHJlYXRlZCBhcyBlcnJvcnMKPiBsaWJ4bF9jcmVhdGUuYzogSW4gZnVuY3Rpb24g
4oCYc3RvcmVfbGlieGxfZW50cnnigJk6Cj4gbGlieGxfY3JlYXRlLmM6NDY1OiBlcnJvcjogZm9y
bWF0IG5vdCBhIHN0cmluZyBsaXRlcmFsIGFuZCBubyBmb3JtYXQgCj4gYXJndW1lbnRzCgpMb29r
cyBsaWtlIFVidW50dSBoYXMgZW5hYmxlZCAtV2Zvcm1hdC1ub25saXRlcmFsIGJ5IGRlZmF1bHQK
CkkgZXhwZWN0IHRoYXQgdGhpcyBuZWVkcyB0byBjaGFuZ2UgdG8gYmUKICAgIHJldHVybiBsaWJ4
bF9feHNfd3JpdGUoZ2MsIFhCVF9OVUxMLCBwYXRoLCAiJXMiLCBsaWJ4bF9fc3RyZHVwKGdjLAog
ICAgICAgbGlieGxfZGV2aWNlX21vZGVsX3ZlcnNpb25fdG9fc3RyaW5nKGRtX2luZm8tPmRldmlj
ZV9tb2RlbF92ZXJzaW9uKSkpOwoobm90ZSB0aGUgYWRkaXRpb25hbCAiJXMiLCkKCkNhbiB5b3Ug
dHJ5IHRoYXQ/CgpUaGUgb3RoZXIgYWx0ZXJuYXRpdmUgd291bGQgYmUgdG8gYWRkIC1Xbm9mb3Jt
YXQtbm9ubGl0ZXJhbCBJIGd1ZXNzLgoKSXQncyBhbHNvIG5vdCBvYnZpb3VzIHdoYXQgdGhlIHN0
cmR1cCBpcyBmb3IgdGhlcmUuCgpJYW4uCgoKPiAKPiBTdGVwcyB0byByZXByb2R1Y2U6Cj4gCj4g
LSBJbnN0YWxsIFVidW50dSAxMS4xMAo+IChodHRwOi8vd3d3LnVidW50dS5jb20vc3RhcnQtZG93
bmxvYWQ/ZGlzdHJvPWRlc2t0b3AmYml0cz02NCZyZWxlYXNlPWxhdGVzdCkKPiAtIHN1ZG8gYXB0
LWdldCBpbnN0YWxsIG1lcmN1cmlhbCBsaWJzZGwtZGV2IHBjaXV0aWxzLWRldiBuY3Vyc2VzLWRl
dgo+IHV1aWQtZGV2IGdldHRleHQgbGlieWFqbC1kZXYgZmxleCB6bGliMWctZGV2IGxpYnNzbC1k
ZXYgeG9yZy1kZXYgYmNjCj4gYmluODYgaWFzbCBsaWJjNi1kZXYtaTM4NiBwYXRjaCBnaXQKPiAt
IGhnIGNsb25lIGh0dHA6Ly94ZW5iaXRzLnhlbnNvdXJjZS5jb20veGVuLXVuc3RhYmxlLmhnCj4g
LSBjZCB4ZW4tdW5zdGFibGUuaGcvdG9vbHMKPiAtIG1ha2UKPiAKPiBBZGRhCgoKCl9fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5n
IGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbnNvdXJjZS5jb20KaHR0cDovL2xpc3RzLnhlbnNvdXJj
ZS5jb20veGVuLWRldmVsCg==

From xen-devel-bounces@lists.xensource.com Thu Dec 01 10:48:26 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 10:48:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW4BZ-0002tE-Q8; Thu, 01 Dec 2011 10:48:13 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RW4BY-0002sN-Hd
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 10:48:12 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1322736452!5440769!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU2Nw==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22858 invoked from network); 1 Dec 2011 10:47:32 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 10:47:32 -0000
X-IronPort-AV: E=Sophos;i="4.71,277,1320624000"; 
   d="scan'208";a="9225739"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Dec 2011 10:47:02 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 1 Dec 2011
	10:47:02 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Adda Rathbone <addarathbone@googlemail.com>
Date: Thu, 1 Dec 2011 10:47:02 +0000
In-Reply-To: <CANrAofX3ARD8CN8HtoBnetfMZvBUS5RSC89ExuGoVSzqmE2V9A@mail.gmail.com>
References: <CANrAofX3ARD8CN8HtoBnetfMZvBUS5RSC89ExuGoVSzqmE2V9A@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322736422.31810.197.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Compile error with Ubuntu 11.10
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gV2VkLCAyMDExLTExLTMwIGF0IDIxOjE5ICswMDAwLCBBZGRhIFJhdGhib25lIHdyb3RlOgo+
IEhpLAo+IGNvbXBpbGF0aW9uIG9mIHhlbi11bnN0YWJsZSB3aXRoIGEgZnJlc2ggVWJ1bnR1IDEx
LjEwIHg4Nl82NCBmYWlscwo+IHdpdGggZm9sbG93aW5nIGVycm9yOgo+IAo+IGNjMTogd2Fybmlu
Z3MgYmVpbmcgdHJlYXRlZCBhcyBlcnJvcnMKPiBsaWJ4bF9jcmVhdGUuYzogSW4gZnVuY3Rpb24g
4oCYc3RvcmVfbGlieGxfZW50cnnigJk6Cj4gbGlieGxfY3JlYXRlLmM6NDY1OiBlcnJvcjogZm9y
bWF0IG5vdCBhIHN0cmluZyBsaXRlcmFsIGFuZCBubyBmb3JtYXQgCj4gYXJndW1lbnRzCgpMb29r
cyBsaWtlIFVidW50dSBoYXMgZW5hYmxlZCAtV2Zvcm1hdC1ub25saXRlcmFsIGJ5IGRlZmF1bHQK
CkkgZXhwZWN0IHRoYXQgdGhpcyBuZWVkcyB0byBjaGFuZ2UgdG8gYmUKICAgIHJldHVybiBsaWJ4
bF9feHNfd3JpdGUoZ2MsIFhCVF9OVUxMLCBwYXRoLCAiJXMiLCBsaWJ4bF9fc3RyZHVwKGdjLAog
ICAgICAgbGlieGxfZGV2aWNlX21vZGVsX3ZlcnNpb25fdG9fc3RyaW5nKGRtX2luZm8tPmRldmlj
ZV9tb2RlbF92ZXJzaW9uKSkpOwoobm90ZSB0aGUgYWRkaXRpb25hbCAiJXMiLCkKCkNhbiB5b3Ug
dHJ5IHRoYXQ/CgpUaGUgb3RoZXIgYWx0ZXJuYXRpdmUgd291bGQgYmUgdG8gYWRkIC1Xbm9mb3Jt
YXQtbm9ubGl0ZXJhbCBJIGd1ZXNzLgoKSXQncyBhbHNvIG5vdCBvYnZpb3VzIHdoYXQgdGhlIHN0
cmR1cCBpcyBmb3IgdGhlcmUuCgpJYW4uCgoKPiAKPiBTdGVwcyB0byByZXByb2R1Y2U6Cj4gCj4g
LSBJbnN0YWxsIFVidW50dSAxMS4xMAo+IChodHRwOi8vd3d3LnVidW50dS5jb20vc3RhcnQtZG93
bmxvYWQ/ZGlzdHJvPWRlc2t0b3AmYml0cz02NCZyZWxlYXNlPWxhdGVzdCkKPiAtIHN1ZG8gYXB0
LWdldCBpbnN0YWxsIG1lcmN1cmlhbCBsaWJzZGwtZGV2IHBjaXV0aWxzLWRldiBuY3Vyc2VzLWRl
dgo+IHV1aWQtZGV2IGdldHRleHQgbGlieWFqbC1kZXYgZmxleCB6bGliMWctZGV2IGxpYnNzbC1k
ZXYgeG9yZy1kZXYgYmNjCj4gYmluODYgaWFzbCBsaWJjNi1kZXYtaTM4NiBwYXRjaCBnaXQKPiAt
IGhnIGNsb25lIGh0dHA6Ly94ZW5iaXRzLnhlbnNvdXJjZS5jb20veGVuLXVuc3RhYmxlLmhnCj4g
LSBjZCB4ZW4tdW5zdGFibGUuaGcvdG9vbHMKPiAtIG1ha2UKPiAKPiBBZGRhCgoKCl9fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5n
IGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbnNvdXJjZS5jb20KaHR0cDovL2xpc3RzLnhlbnNvdXJj
ZS5jb20veGVuLWRldmVsCg==

From xen-devel-bounces@lists.xensource.com Thu Dec 01 10:52:12 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 10:52:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW4FD-0003Un-VR; Thu, 01 Dec 2011 10:51:59 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RW4FC-0003U3-Nd
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 10:51:58 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1322736678!4540045!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQzODQ=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17105 invoked from network); 1 Dec 2011 10:51:19 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-13.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 1 Dec 2011 10:51:19 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 01 Dec 2011 10:51:18 +0000
Message-Id: <4ED76A350200007800064ABD@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 01 Dec 2011 10:51:17 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part98B70C35.2__="
Cc: Eddie Dong <eddie.dong@intel.com>, Tim Deegan <Tim.Deegan@citrix.com>,
	qing.he@intel.com
Subject: [Xen-devel] [PATCH] vvmx: fix intended assignment
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

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

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

>From what I can tell, this was supposed to be an assignment (not warned
about by the compiler due to -Wno-unused, which is about to be removed).

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

--- a/xen/arch/x86/hvm/vmx/vvmx.c
+++ b/xen/arch/x86/hvm/vmx/vvmx.c
@@ -581,7 +581,7 @@ static void nvmx_purge_vvmcs(struct vcpu
     __clear_current_vvmcs(v);
     if ( nvcpu->nv_vvmcxaddr !=3D VMCX_EADDR )
         hvm_unmap_guest_frame(nvcpu->nv_vvmcx);
-    nvcpu->nv_vvmcx =3D=3D NULL;
+    nvcpu->nv_vvmcx =3D NULL;
     nvcpu->nv_vvmcxaddr =3D VMCX_EADDR;
     for (i=3D0; i<2; i++) {
         if ( nvmx->iobitmap[i] ) {




--=__Part98B70C35.2__=
Content-Type: text/plain; name="vvmx-fix-23526.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="vvmx-fix-23526.patch"

vvmx: fix intended assignment=0A=0AFrom what I can tell, this was supposed =
to be an assignment (not warned=0Aabout by the compiler due to -Wno-unused,=
 which is about to be removed).=0A=0ASigned-off-by: Jan Beulich <jbeulich@s=
use.com>=0A=0A--- a/xen/arch/x86/hvm/vmx/vvmx.c=0A+++ b/xen/arch/x86/hvm/vm=
x/vvmx.c=0A@@ -581,7 +581,7 @@ static void nvmx_purge_vvmcs(struct vcpu=0A =
    __clear_current_vvmcs(v);=0A     if ( nvcpu->nv_vvmcxaddr !=3D =
VMCX_EADDR )=0A         hvm_unmap_guest_frame(nvcpu->nv_vvmcx);=0A-    =
nvcpu->nv_vvmcx =3D=3D NULL;=0A+    nvcpu->nv_vvmcx =3D NULL;=0A     =
nvcpu->nv_vvmcxaddr =3D VMCX_EADDR;=0A     for (i=3D0; i<2; i++) {=0A      =
   if ( nvmx->iobitmap[i] ) {=0A
--=__Part98B70C35.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.xensource.com
http://lists.xensource.com/xen-devel

--=__Part98B70C35.2__=--


From xen-devel-bounces@lists.xensource.com Thu Dec 01 10:52:12 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 10:52:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW4FD-0003Un-VR; Thu, 01 Dec 2011 10:51:59 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RW4FC-0003U3-Nd
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 10:51:58 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1322736678!4540045!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQzODQ=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17105 invoked from network); 1 Dec 2011 10:51:19 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-13.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 1 Dec 2011 10:51:19 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 01 Dec 2011 10:51:18 +0000
Message-Id: <4ED76A350200007800064ABD@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 01 Dec 2011 10:51:17 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part98B70C35.2__="
Cc: Eddie Dong <eddie.dong@intel.com>, Tim Deegan <Tim.Deegan@citrix.com>,
	qing.he@intel.com
Subject: [Xen-devel] [PATCH] vvmx: fix intended assignment
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

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

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

>From what I can tell, this was supposed to be an assignment (not warned
about by the compiler due to -Wno-unused, which is about to be removed).

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

--- a/xen/arch/x86/hvm/vmx/vvmx.c
+++ b/xen/arch/x86/hvm/vmx/vvmx.c
@@ -581,7 +581,7 @@ static void nvmx_purge_vvmcs(struct vcpu
     __clear_current_vvmcs(v);
     if ( nvcpu->nv_vvmcxaddr !=3D VMCX_EADDR )
         hvm_unmap_guest_frame(nvcpu->nv_vvmcx);
-    nvcpu->nv_vvmcx =3D=3D NULL;
+    nvcpu->nv_vvmcx =3D NULL;
     nvcpu->nv_vvmcxaddr =3D VMCX_EADDR;
     for (i=3D0; i<2; i++) {
         if ( nvmx->iobitmap[i] ) {




--=__Part98B70C35.2__=
Content-Type: text/plain; name="vvmx-fix-23526.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="vvmx-fix-23526.patch"

vvmx: fix intended assignment=0A=0AFrom what I can tell, this was supposed =
to be an assignment (not warned=0Aabout by the compiler due to -Wno-unused,=
 which is about to be removed).=0A=0ASigned-off-by: Jan Beulich <jbeulich@s=
use.com>=0A=0A--- a/xen/arch/x86/hvm/vmx/vvmx.c=0A+++ b/xen/arch/x86/hvm/vm=
x/vvmx.c=0A@@ -581,7 +581,7 @@ static void nvmx_purge_vvmcs(struct vcpu=0A =
    __clear_current_vvmcs(v);=0A     if ( nvcpu->nv_vvmcxaddr !=3D =
VMCX_EADDR )=0A         hvm_unmap_guest_frame(nvcpu->nv_vvmcx);=0A-    =
nvcpu->nv_vvmcx =3D=3D NULL;=0A+    nvcpu->nv_vvmcx =3D NULL;=0A     =
nvcpu->nv_vvmcxaddr =3D VMCX_EADDR;=0A     for (i=3D0; i<2; i++) {=0A      =
   if ( nvmx->iobitmap[i] ) {=0A
--=__Part98B70C35.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.xensource.com
http://lists.xensource.com/xen-devel

--=__Part98B70C35.2__=--


From xen-devel-bounces@lists.xensource.com Thu Dec 01 10:52:44 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 10:52:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW4Fh-0003ah-Dy; Thu, 01 Dec 2011 10:52:29 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <sandr8@gmail.com>) id 1RW4Ff-0003ZS-Qo
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 10:52:28 +0000
X-Env-Sender: sandr8@gmail.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1322736707!5441544!1
X-Originating-IP: [209.85.213.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7881 invoked from network); 1 Dec 2011 10:51:48 -0000
Received: from mail-yx0-f171.google.com (HELO mail-yx0-f171.google.com)
	(209.85.213.171)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 10:51:48 -0000
Received: by yenr9 with SMTP id r9so10659086yen.30
	for <xen-devel@lists.xensource.com>;
	Thu, 01 Dec 2011 02:51:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:reply-to:in-reply-to:references:from:date:message-id
	:subject:to:content-type:content-transfer-encoding;
	bh=bCIWE2wK52nSTPibXPHWgkqBiNw1VtQER3NqENY2PSg=;
	b=fczpFS1nqrVLE/DcM06P1E3zb6VUx3nt0U2b++FhOZqUrJar/I11X2tWd+63RIaFJu
	bxmiYCoUUY0/Ol6PduHnhxig17rSuZDe+yVxjcW3BrIrsJ0S7r7woHXlcpj7hcpjk1t0
	nS3o8kafrQlmsV6JLbxNKTDUkIzs+zbYIPZQE=
Received: by 10.236.201.137 with SMTP id b9mr10096546yho.124.1322736705054;
	Thu, 01 Dec 2011 02:51:45 -0800 (PST)
MIME-Version: 1.0
Received: by 10.236.60.132 with HTTP; Thu, 1 Dec 2011 02:51:13 -0800 (PST)
In-Reply-To: <1322564266184-5031946.post@n5.nabble.com>
References: <1316338995760-4815691.post@n5.nabble.com>
	<alpine.DEB.2.00.1109201908010.8700@kaball-desktop>
	<1316571734360-4824822.post@n5.nabble.com>
	<1322564266184-5031946.post@n5.nabble.com>
From: Alessandro Salvatori <sandr8@gmail.com>
Date: Thu, 1 Dec 2011 02:51:13 -0800
Message-ID: <CAJeBh4vR7HUMswsuj4yZ1jT-5qonRk3jPR9UH42UtELvgfRXzA@mail.gmail.com>
To: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Permission for xenstore operation on HVM
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: sandr8@gmail.com
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

damn... there goes the original message sent from nabble.com... i
refrained for two days before re-posting because i didn't want to
annoy people with a double post if it ever went through...

sorry about that! :'(

-Alessandro-
=A0Here i am, A young man,
=A0A crashing computer program,
=A0Here is a pen, write out my name...

(from: The Servant - Orchestra)

On Tue, Nov 29, 2011 at 02:57, sandr8 <sandr8@gmail.com> wrote:
> duolvxendev,
>
> =A0I am hitting this too and I really wish there were a trick to avoid
> this...
>
> I have two theories with regard to this.
>
> theory 1: for HVM guests Xen gives the ownership of the xenstore variables
> to dom0 instead of the domU that is running the guest. My humble guess is
> that Xen assumes that HVM guests are gonna be hypervisor agnostic and not
> gonna be using xenstore. Of course this assumption breaks when you have
> PV-HVM guests.
>
> theory 2: in libxenlight, @libxl_create.c:290
>
> char *rw_paths[] =3D { "control/shutdown", "device",
> "device/suspend/event-channel" , "data"};
>
> should actually also include "vm-data". People who bypass libxl (maybe by
> using xm?) will not notice the issue. Unfortunately, I don't have a system
> with xm at hand to double check this wild guess of mine...
>
> thanks!
> -alessandro-
>
> --
> View this message in context: http://xen.1045712.n5.nabble.com/Permission=
-for-xenstore-operation-on-HVM-tp4815691p5031946.html
> Sent from the Xen - Dev mailing list archive at Nabble.com.
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 10:52:44 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 10:52:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW4Fh-0003ah-Dy; Thu, 01 Dec 2011 10:52:29 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <sandr8@gmail.com>) id 1RW4Ff-0003ZS-Qo
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 10:52:28 +0000
X-Env-Sender: sandr8@gmail.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1322736707!5441544!1
X-Originating-IP: [209.85.213.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7881 invoked from network); 1 Dec 2011 10:51:48 -0000
Received: from mail-yx0-f171.google.com (HELO mail-yx0-f171.google.com)
	(209.85.213.171)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 10:51:48 -0000
Received: by yenr9 with SMTP id r9so10659086yen.30
	for <xen-devel@lists.xensource.com>;
	Thu, 01 Dec 2011 02:51:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:reply-to:in-reply-to:references:from:date:message-id
	:subject:to:content-type:content-transfer-encoding;
	bh=bCIWE2wK52nSTPibXPHWgkqBiNw1VtQER3NqENY2PSg=;
	b=fczpFS1nqrVLE/DcM06P1E3zb6VUx3nt0U2b++FhOZqUrJar/I11X2tWd+63RIaFJu
	bxmiYCoUUY0/Ol6PduHnhxig17rSuZDe+yVxjcW3BrIrsJ0S7r7woHXlcpj7hcpjk1t0
	nS3o8kafrQlmsV6JLbxNKTDUkIzs+zbYIPZQE=
Received: by 10.236.201.137 with SMTP id b9mr10096546yho.124.1322736705054;
	Thu, 01 Dec 2011 02:51:45 -0800 (PST)
MIME-Version: 1.0
Received: by 10.236.60.132 with HTTP; Thu, 1 Dec 2011 02:51:13 -0800 (PST)
In-Reply-To: <1322564266184-5031946.post@n5.nabble.com>
References: <1316338995760-4815691.post@n5.nabble.com>
	<alpine.DEB.2.00.1109201908010.8700@kaball-desktop>
	<1316571734360-4824822.post@n5.nabble.com>
	<1322564266184-5031946.post@n5.nabble.com>
From: Alessandro Salvatori <sandr8@gmail.com>
Date: Thu, 1 Dec 2011 02:51:13 -0800
Message-ID: <CAJeBh4vR7HUMswsuj4yZ1jT-5qonRk3jPR9UH42UtELvgfRXzA@mail.gmail.com>
To: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Permission for xenstore operation on HVM
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: sandr8@gmail.com
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

damn... there goes the original message sent from nabble.com... i
refrained for two days before re-posting because i didn't want to
annoy people with a double post if it ever went through...

sorry about that! :'(

-Alessandro-
=A0Here i am, A young man,
=A0A crashing computer program,
=A0Here is a pen, write out my name...

(from: The Servant - Orchestra)

On Tue, Nov 29, 2011 at 02:57, sandr8 <sandr8@gmail.com> wrote:
> duolvxendev,
>
> =A0I am hitting this too and I really wish there were a trick to avoid
> this...
>
> I have two theories with regard to this.
>
> theory 1: for HVM guests Xen gives the ownership of the xenstore variables
> to dom0 instead of the domU that is running the guest. My humble guess is
> that Xen assumes that HVM guests are gonna be hypervisor agnostic and not
> gonna be using xenstore. Of course this assumption breaks when you have
> PV-HVM guests.
>
> theory 2: in libxenlight, @libxl_create.c:290
>
> char *rw_paths[] =3D { "control/shutdown", "device",
> "device/suspend/event-channel" , "data"};
>
> should actually also include "vm-data". People who bypass libxl (maybe by
> using xm?) will not notice the issue. Unfortunately, I don't have a system
> with xm at hand to double check this wild guess of mine...
>
> thanks!
> -alessandro-
>
> --
> View this message in context: http://xen.1045712.n5.nabble.com/Permission=
-for-xenstore-operation-on-HVM-tp4815691p5031946.html
> Sent from the Xen - Dev mailing list archive at Nabble.com.
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 11:08:31 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 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.xensource.com>)
	id 1RW4Uv-0004Fj-1l; Thu, 01 Dec 2011 11:08:13 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1RW4Uu-0004Fc-7y
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 11:08:12 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1322737651!6456534!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13611 invoked from network); 1 Dec 2011 11:07:32 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 11:07:32 -0000
Received: by iaen33 with SMTP id n33so3041237iae.30
	for <xen-devel@lists.xensource.com>;
	Thu, 01 Dec 2011 03:07:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=nUkqKVJ1Hq2EyTSHmOUU8Hkb01io6qkpglb2K6xMiqo=;
	b=QubbpQJDkeZyHcphhelsOQURN1bkQJtt3TFteqndvkMNL9MY5revkPMUyJBH7ZV7jD
	TipGDL6bbalMbPp7OBZsgYesfKK+mwRYZYz2d++yJUvYX2RRE0E6rcC7zjtrw3WyrGMv
	n5VPIJQYVbI6Fx9dB6VUt6//JNNUAJduBIV+Q=
MIME-Version: 1.0
Received: by 10.42.76.66 with SMTP id d2mr7727768ick.7.1322737650955; Thu, 01
	Dec 2011 03:07:30 -0800 (PST)
Received: by 10.231.169.13 with HTTP; Thu, 1 Dec 2011 03:07:30 -0800 (PST)
In-Reply-To: <1322705286985-5037367.post@n5.nabble.com>
References: <1322705286985-5037367.post@n5.nabble.com>
Date: Thu, 1 Dec 2011 11:07:30 +0000
X-Google-Sender-Auth: 3_tq-ojKPNLcY0gJEmYMvg_Ay4s
Message-ID: <CAFLBxZZCAmc7gYyr0NN3y7_i86std0xOnuwBPTeFUeLY1N92WQ@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: confucius <henanwxr@hotmail.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] How does vmm get all mmio areas of pci devices?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Dec 1, 2011 at 2:08 AM, confucius <henanwxr@hotmail.com> wrote:
> what I want to know is step2 and step5:
> In step2, how does vmm get all mmio areas of devices? and how vmm set ept
> entry with these mmio areas ?

At the moment, Xen will send all accesses to guest physical addresses
it doesn't recognize to qemu.  There is a general plan to have qemu
register these areas with Xen before starting the guest, but that's
not being actively worked on at the moment, AFAIK.

> In setp5, is it ture for DMA operatin I described? and when qemu-dm find no
> callback function for some MMIO area, what it will do?

I don't understand your thing about DMA.  DMA is emulated by QEMU; but
it's not done to MMIO regions, but to memory regions.  A guest driver
shouldn't request a DMA to a region of the physical address space that
isn't backed by RAM; if it tries to, the request will fail in QEMU.
(Not sure exactly what will happen.)

In any case, if qemu gets an MMIO request from the guest on an area of
physical memory where it doesn't have any devices, it will just pass
the request back to Xen without doing anything.  I believe this
typically this will results in writes doing nothing and reads getting
0.

 -George

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 11:08:31 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 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.xensource.com>)
	id 1RW4Uv-0004Fj-1l; Thu, 01 Dec 2011 11:08:13 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1RW4Uu-0004Fc-7y
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 11:08:12 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1322737651!6456534!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13611 invoked from network); 1 Dec 2011 11:07:32 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 11:07:32 -0000
Received: by iaen33 with SMTP id n33so3041237iae.30
	for <xen-devel@lists.xensource.com>;
	Thu, 01 Dec 2011 03:07:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=nUkqKVJ1Hq2EyTSHmOUU8Hkb01io6qkpglb2K6xMiqo=;
	b=QubbpQJDkeZyHcphhelsOQURN1bkQJtt3TFteqndvkMNL9MY5revkPMUyJBH7ZV7jD
	TipGDL6bbalMbPp7OBZsgYesfKK+mwRYZYz2d++yJUvYX2RRE0E6rcC7zjtrw3WyrGMv
	n5VPIJQYVbI6Fx9dB6VUt6//JNNUAJduBIV+Q=
MIME-Version: 1.0
Received: by 10.42.76.66 with SMTP id d2mr7727768ick.7.1322737650955; Thu, 01
	Dec 2011 03:07:30 -0800 (PST)
Received: by 10.231.169.13 with HTTP; Thu, 1 Dec 2011 03:07:30 -0800 (PST)
In-Reply-To: <1322705286985-5037367.post@n5.nabble.com>
References: <1322705286985-5037367.post@n5.nabble.com>
Date: Thu, 1 Dec 2011 11:07:30 +0000
X-Google-Sender-Auth: 3_tq-ojKPNLcY0gJEmYMvg_Ay4s
Message-ID: <CAFLBxZZCAmc7gYyr0NN3y7_i86std0xOnuwBPTeFUeLY1N92WQ@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: confucius <henanwxr@hotmail.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] How does vmm get all mmio areas of pci devices?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Dec 1, 2011 at 2:08 AM, confucius <henanwxr@hotmail.com> wrote:
> what I want to know is step2 and step5:
> In step2, how does vmm get all mmio areas of devices? and how vmm set ept
> entry with these mmio areas ?

At the moment, Xen will send all accesses to guest physical addresses
it doesn't recognize to qemu.  There is a general plan to have qemu
register these areas with Xen before starting the guest, but that's
not being actively worked on at the moment, AFAIK.

> In setp5, is it ture for DMA operatin I described? and when qemu-dm find no
> callback function for some MMIO area, what it will do?

I don't understand your thing about DMA.  DMA is emulated by QEMU; but
it's not done to MMIO regions, but to memory regions.  A guest driver
shouldn't request a DMA to a region of the physical address space that
isn't backed by RAM; if it tries to, the request will fail in QEMU.
(Not sure exactly what will happen.)

In any case, if qemu gets an MMIO request from the guest on an area of
physical memory where it doesn't have any devices, it will just pass
the request back to Xen without doing anything.  I believe this
typically this will results in writes doing nothing and reads getting
0.

 -George

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 11:21:29 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 11:21:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW4hR-0004eF-ET; Thu, 01 Dec 2011 11:21:09 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <haitao.shan@intel.com>) id 1RW4hP-0004eA-W0
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 11:21:08 +0000
X-Env-Sender: haitao.shan@intel.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1322738427!5431460!1
X-Originating-IP: [134.134.136.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjQgPT4gMzIwNDI3\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6638 invoked from network); 1 Dec 2011 11:20:27 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-9.tower-182.messagelabs.com with SMTP;
	1 Dec 2011 11:20:27 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga102.jf.intel.com with ESMTP; 01 Dec 2011 03:20:04 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.67,352,1309762800"; 
	d="p7s'?scan'208";a="81700234"
Received: from pgsmsx601.gar.corp.intel.com ([10.221.43.69])
	by orsmga001.jf.intel.com with ESMTP; 01 Dec 2011 03:20:02 -0800
Received: from shsmsx601.ccr.corp.intel.com (10.239.4.112) by
	pgsmsx601.gar.corp.intel.com (10.221.43.69) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Thu, 1 Dec 2011 19:20:02 +0800
Received: from shsmsx502.ccr.corp.intel.com ([10.239.4.96]) by
	shsmsx601.ccr.corp.intel.com ([10.239.4.112]) with mapi; Thu, 1 Dec 2011
	19:20:00 +0800
From: "Shan, Haitao" <haitao.shan@intel.com>
To: Jan Beulich <JBeulich@suse.com>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>
Date: Thu, 1 Dec 2011 19:19:58 +0800
Thread-Topic: [Xen-devel] [PATCH] vvmx: fix intended assignment
Thread-Index: AcywF4Hb20gFLSMJSMKXkw2TYA3pbwAA1naA
Message-ID: <04F972F38B3C4E4E91C4697DA8BF9F5284357D52A6@shsmsx502.ccr.corp.intel.com>
References: <4ED76A350200007800064ABD@nat28.tlf.novell.com>
In-Reply-To: <4ED76A350200007800064ABD@nat28.tlf.novell.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "Dong, Eddie" <eddie.dong@intel.com>, Tim Deegan <Tim.Deegan@citrix.com>,
	"He, Qing" <qing.he@intel.com>
Subject: Re: [Xen-devel] [PATCH] vvmx: fix intended assignment
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1791125040118541128=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============1791125040118541128==
Content-Language: en-US
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature";
	micalg=SHA1; boundary="----=_NextPart_000_014B_01CCB05E.3751E4B0"

------=_NextPart_000_014B_01CCB05E.3751E4B0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hi, Jan,

I think you cannot cc He Qing any more. As He Qing (who had done some work
on nested) has left Intel, while this email address is going to another
people who just has the same name.

Shan Haitao

> -----Original Message-----
> From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-
> bounces@lists.xensource.com] On Behalf Of Jan Beulich
> Sent: Thursday, December 01, 2011 6:51 PM
> To: xen-devel@lists.xensource.com
> Cc: Dong, Eddie; Tim Deegan; He, Qing
> Subject: [Xen-devel] [PATCH] vvmx: fix intended assignment
> 
> From what I can tell, this was supposed to be an assignment (not warned
> about by the compiler due to -Wno-unused, which is about to be removed).
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> --- a/xen/arch/x86/hvm/vmx/vvmx.c
> +++ b/xen/arch/x86/hvm/vmx/vvmx.c
> @@ -581,7 +581,7 @@ static void nvmx_purge_vvmcs(struct vcpu
>      __clear_current_vvmcs(v);
>      if ( nvcpu->nv_vvmcxaddr != VMCX_EADDR )
>          hvm_unmap_guest_frame(nvcpu->nv_vvmcx);
> -    nvcpu->nv_vvmcx == NULL;
> +    nvcpu->nv_vvmcx = NULL;
>      nvcpu->nv_vvmcxaddr = VMCX_EADDR;
>      for (i=0; i<2; i++) {
>          if ( nvmx->iobitmap[i] ) {
> 
> 


------=_NextPart_000_014B_01CCB05E.3751E4B0
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIYUDCCAyAw
ggKJoAMCAQICBDXe9M8wDQYJKoZIhvcNAQEFBQAwTjELMAkGA1UEBhMCVVMxEDAOBgNVBAoTB0Vx
dWlmYXgxLTArBgNVBAsTJEVxdWlmYXggU2VjdXJlIENlcnRpZmljYXRlIEF1dGhvcml0eTAeFw05
ODA4MjIxNjQxNTFaFw0xODA4MjIxNjQxNTFaME4xCzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVp
ZmF4MS0wKwYDVQQLEyRFcXVpZmF4IFNlY3VyZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwgZ8wDQYJ
KoZIhvcNAQEBBQADgY0AMIGJAoGBAMFdsVhnCGLuoJotHwhtkRRomAoe/toEbxOEYiHD0XzOnwXg
uAHwTjTs4oqVBGSs8WtTXwWzy2eAv0ICjv7dAQns4QAUT/z78AzdQ7pbK+EfgHCZFVeTFvEPl2q3
wmgjHMxNWTCsUR47ryvW7mNFe8XZX1DS41APOojnvxT94Me5AgMBAAGjggEJMIIBBTBwBgNVHR8E
aTBnMGWgY6BhpF8wXTELMAkGA1UEBhMCVVMxEDAOBgNVBAoTB0VxdWlmYXgxLTArBgNVBAsTJEVx
dWlmYXggU2VjdXJlIENlcnRpZmljYXRlIEF1dGhvcml0eTENMAsGA1UEAxMEQ1JMMTAaBgNVHRAE
EzARgQ8yMDE4MDgyMjE2NDE1MVowCwYDVR0PBAQDAgEGMB8GA1UdIwQYMBaAFEjmaPkr0rKV10fY
IyAQTzOYkJ/UMB0GA1UdDgQWBBRI5mj5K9KylddH2CMgEE8zmJCf1DAMBgNVHRMEBTADAQH/MBoG
CSqGSIb2fQdBAAQNMAsbBVYzLjBjAwIGwDANBgkqhkiG9w0BAQUFAAOBgQBYzinq/Pfetc4CuRe1
hdG54+CVzCUxDQCmkm5/tpJjnlCV0Zpv5BHeY4VumO6o/1rI01WyZnFX3sAh6z0qpyNJAQSGQnv8
7n+iFlK1Z2fTQNs7JliyKHc9rhR3Ydb6KmYnoA36p3Nc6nDxlCFlRF/6/O8paKmih3nvee9PrAd3
ODCCAz0wggKmoAMCAQICAwWw/zANBgkqhkiG9w0BAQUFADBOMQswCQYDVQQGEwJVUzEQMA4GA1UE
ChMHRXF1aWZheDEtMCsGA1UECxMkRXF1aWZheCBTZWN1cmUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5
MB4XDTA2MDIxNjE4MDEzMFoXDTE2MDIxOTE4MDEzMFowUjELMAkGA1UEBhMCVVMxGjAYBgNVBAoT
EUludGVsIENvcnBvcmF0aW9uMScwJQYDVQQDEx5JbnRlbCBFeHRlcm5hbCBCYXNpYyBQb2xpY3kg
Q0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDBpd/XOb9QVqEZ8mQ1042TdOIq3ATD
IsV2xDyt30yLyMR5Wjtus0bn3B+he89BiNO/LP6+rFzEwlD55PlX+HLGIKeNNG97dqyc30FElEUj
ZzTZFq2N4e3kVJ/XAEEgANzV8v9qp7qWwxugPgfc3z9BkYot+CifozexHLb/hEZj+yISCU61kRZv
uSQ0E11yYL4dRgcglJeaHo3oX57rvIckaLsYV5/1Aj+R8DM1Ppk965XQAKsHfnyT7C4S50T4lVn4
lz36wOdNZn/zegG1zp41lnoTFfT4KuKVJH5x7YD1p6KbgJCKLovnujGuohquBNfdXKpZkvz6pGv+
iC1HawJdAgMBAAGjgaAwgZ0wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBQaxgxKxEdvqNutK/D0
Vgaj7TdUDDA6BgNVHR8EMzAxMC+gLaArhilodHRwOi8vY3JsLmdlb3RydXN0LmNvbS9jcmxzL3Nl
Y3VyZWNhLmNybDAfBgNVHSMEGDAWgBRI5mj5K9KylddH2CMgEE8zmJCf1DAPBgNVHRMBAf8EBTAD
AQH/MA0GCSqGSIb3DQEBBQUAA4GBABMQOK2kVKVIlUWwLTdywJ+e2O+PC/uQltK2F3lRyrPfBn69
tOkIP4SgDJOfsxyobIrPLe75kBLw+Dom13OBDp/EMZJZ1CglQfVV8co9mT3aZMjSGGQiMgkJLR3j
Mfr900fXZKj5XeqCJ+JP0mEhJGEdVCY+FFlksJjV86fDrq1QMIIFijCCBHKgAwIBAgIKYSCKYgAA
AAAACDANBgkqhkiG9w0BAQUFADBSMQswCQYDVQQGEwJVUzEaMBgGA1UEChMRSW50ZWwgQ29ycG9y
YXRpb24xJzAlBgNVBAMTHkludGVsIEV4dGVybmFsIEJhc2ljIFBvbGljeSBDQTAeFw0wOTA1MTUx
OTI3MjZaFw0xNTA1MTUxOTM3MjZaMFYxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFJbnRlbCBDb3Jw
b3JhdGlvbjErMCkGA1UEAxMiSW50ZWwgRXh0ZXJuYWwgQmFzaWMgSXNzdWluZyBDQSAzQjCCASIw
DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKQEM1Wn9TU9vc9C+/Tc7KB+eiYElmrcEWE32WUd
HvWG+IcQHVQsikTmMyKKojNLw2B5s6Iekc8ivDo/wCfjZzX9JyftMnc+AArc0la87Olybzm8K9jX
EfTBvTnUSFSiI9ZYefITdiUgqlAFuljFZEHYKYtLuhrRacpmQfP4mV63NKdc2bT804HRf6YptZFa
4k6YN94zlrGNrBuQQ74WFzz/jLBusbUpEkro6Mu/ZYFOFWQrV9lBhF9Ruk8yN+3N6n9fUo/qBigi
F2kEn9xVh1ykl7SCGL2jBUkXx4qgV27a6Si8lRRdgrHGtN/HWnSWlLXTH5l575H4Lq++77OFv38C
AwEAAaOCAlwwggJYMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFA7GKvdZsggQkCVvw939imYx
MCvFMAsGA1UdDwQEAwIBhjASBgkrBgEEAYI3FQEEBQIDAQABMCMGCSsGAQQBgjcVAgQWBBQ5oFY2
ekKQ/5Ktim+VdMeSWb4QWTAZBgkrBgEEAYI3FAIEDB4KAFMAdQBiAEMAQTAfBgNVHSMEGDAWgBQa
xgxKxEdvqNutK/D0Vgaj7TdUDDCBvQYDVR0fBIG1MIGyMIGvoIGsoIGphk5odHRwOi8vd3d3Lmlu
dGVsLmNvbS9yZXBvc2l0b3J5L0NSTC9JbnRlbCUyMEV4dGVybmFsJTIwQmFzaWMlMjBQb2xpY3kl
MjBDQS5jcmyGV2h0dHA6Ly9jZXJ0aWZpY2F0ZXMuaW50ZWwuY29tL3JlcG9zaXRvcnkvQ1JML0lu
dGVsJTIwRXh0ZXJuYWwlMjBCYXNpYyUyMFBvbGljeSUyMENBLmNybDCB4wYIKwYBBQUHAQEEgdYw
gdMwYwYIKwYBBQUHMAKGV2h0dHA6Ly93d3cuaW50ZWwuY29tL3JlcG9zaXRvcnkvY2VydGlmaWNh
dGVzL0ludGVsJTIwRXh0ZXJuYWwlMjBCYXNpYyUyMFBvbGljeSUyMENBLmNydDBsBggrBgEFBQcw
AoZgaHR0cDovL2NlcnRpZmljYXRlcy5pbnRlbC5jb20vcmVwb3NpdG9yeS9jZXJ0aWZpY2F0ZXMv
SW50ZWwlMjBFeHRlcm5hbCUyMEJhc2ljJTIwUG9saWN5JTIwQ0EuY3J0MA0GCSqGSIb3DQEBBQUA
A4IBAQCxtQEHchVQhXyjEqtMVUMe6gkmPsIczHxSeqNbo9dsD+6xbT65JT+oYgpIAtfEsYXeUJu1
cChqpb22U5bMAz7eaQcW5bzefufWvA6lg2048B8oczBj/q+5P5NpYrUO8jOmN4jTjfJq3ElZ7yFW
py7rB3Vm/aN6ATYqWfMbS/xfh+JCxmH3droUmMJI0/aZJHsLtjbjFnNsHDNrJZX1vxlM78Lb1hjs
kTENPmhbVbfTj5i/ZGnhv4tmI8QZPCNtcegXJrfhRl2D9bWpdTOPrWiLDUqzy1Z6KL7TcOS/PCl8
RHCJXkPau/thTQCpIoDa2+c+3XA++gRTfAQ4svTO260NMIIGBzCCBO+gAwIBAgIKEx06gQABAAB7
rTANBgkqhkiG9w0BAQUFADBWMQswCQYDVQQGEwJVUzEaMBgGA1UEChMRSW50ZWwgQ29ycG9yYXRp
b24xKzApBgNVBAMTIkludGVsIEV4dGVybmFsIEJhc2ljIElzc3VpbmcgQ0EgM0IwHhcNMTExMDEy
MDEyNDIwWhcNMTQwOTI2MDEyNDIwWjA9MRUwEwYDVQQDEwxTaGFuLCBIYWl0YW8xJDAiBgkqhkiG
9w0BCQEWFWhhaXRhby5zaGFuQGludGVsLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC
ggEBALpHYbXkMy06K6Pl9IGxbsKl0zT/OYd523Rh3CX7tHG/80ZGcPeLlzFK+l+30Fhpzf8fsFwG
l5fX2pRtWqT96BUWecXEVJhisfa1Wrq7DBC6coxEnExFADU+2UsBQ/ACKFSCiq/fADojyFWJgPKv
4PLDKJ9LU23Q+g1WRruGHfBnhCMv0KxnkE7pTk3cFRXtNUSUnYLqcvrZwt9VogQNiNNw3jMlDb8t
bJjMsXdhrwqFGW49z/gAJ2Mnr6/lNnqBdcKF2Qm28SfYXRohGrmam3KReM49ZG0+J/+JPF5drbiw
UAV++PMHA3IXIvZF2c66jQM5BzbF93SkoZXmrQZA2jMCAwEAAaOCAu4wggLqMAsGA1UdDwQEAwIH
gDA8BgkrBgEEAYI3FQcELzAtBiUrBgEEAYI3FQiGw4x1hJnlUYP9gSiFjp9TgpHACWeB3r05lfBD
AgFkAgEIMB0GA1UdDgQWBBQ/OInBCgrko9ziRWiEhjM+SyeeoDAfBgNVHSMEGDAWgBQOxir3WbII
EJAlb8Pd/YpmMTArxTCBzwYDVR0fBIHHMIHEMIHBoIG+oIG7hldodHRwOi8vd3d3LmludGVsLmNv
bS9yZXBvc2l0b3J5L0NSTC9JbnRlbCUyMEV4dGVybmFsJTIwQmFzaWMlMjBJc3N1aW5nJTIwQ0El
MjAzQigxKS5jcmyGYGh0dHA6Ly9jZXJ0aWZpY2F0ZXMuaW50ZWwuY29tL3JlcG9zaXRvcnkvQ1JM
L0ludGVsJTIwRXh0ZXJuYWwlMjBCYXNpYyUyMElzc3VpbmclMjBDQSUyMDNCKDEpLmNybDCB9QYI
KwYBBQUHAQEEgegwgeUwbAYIKwYBBQUHMAKGYGh0dHA6Ly93d3cuaW50ZWwuY29tL3JlcG9zaXRv
cnkvY2VydGlmaWNhdGVzL0ludGVsJTIwRXh0ZXJuYWwlMjBCYXNpYyUyMElzc3VpbmclMjBDQSUy
MDNCKDEpLmNydDB1BggrBgEFBQcwAoZpaHR0cDovL2NlcnRpZmljYXRlcy5pbnRlbC5jb20vcmVw
b3NpdG9yeS9jZXJ0aWZpY2F0ZXMvSW50ZWwlMjBFeHRlcm5hbCUyMEJhc2ljJTIwSXNzdWluZyUy
MENBJTIwM0IoMSkuY3J0MB8GA1UdJQQYMBYGCCsGAQUFBwMEBgorBgEEAYI3CgMMMCkGCSsGAQQB
gjcVCgQcMBowCgYIKwYBBQUHAwQwDAYKKwYBBAGCNwoDDDBHBgNVHREEQDA+oCUGCisGAQQBgjcU
AgOgFwwVaGFpdGFvLnNoYW5AaW50ZWwuY29tgRVoYWl0YW8uc2hhbkBpbnRlbC5jb20wDQYJKoZI
hvcNAQEFBQADggEBAG5Us26ruu8jKt3RhZuirjqgF61p+wZer/xV6BTABUx5++DhWXslTztavsvy
JZ5WsZ7xaijBUO3UQViWTylwmSyGwbhEwreu3XRNGlMOnRk+sH7JGiXZJIpqoD/jtRWp0ypHG2g3
nDqAQ1/j4wUgcI0b12KUJyYAeN6cwEeAqIV4mdD8GpH3DS2nZbEZjTNhkaeJuT7lO1jRqzEGOSCk
KDHPfqUtqpw+wZa6mFbzSso9swc4ypgRIl4l5i/4OwNMQazHm2O6Ov91aDJs6j3DCdALzP736hmF
QFfHWL34GFQMRdpO/OI6z/Q0VYm/6N9o4SD/s4J9Edq8zyYNQxBR03QwggZOMIIFNqADAgECAgoT
I00xAAEAAHuuMA0GCSqGSIb3DQEBBQUAMFYxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFJbnRlbCBD
b3Jwb3JhdGlvbjErMCkGA1UEAxMiSW50ZWwgRXh0ZXJuYWwgQmFzaWMgSXNzdWluZyBDQSAzQjAe
Fw0xMTEwMTIwMTMwNTZaFw0xNDA5MjYwMTMwNTZaMD0xFTATBgNVBAMTDFNoYW4sIEhhaXRhbzEk
MCIGCSqGSIb3DQEJARYVaGFpdGFvLnNoYW5AaW50ZWwuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOC
AQ8AMIIBCgKCAQEApaOcuQtYCobUiLQTadd0Hi+U/ausgzeSE59iUrc57VUzvLsLNnKRxLPm+T26
KN9fMDAS3/MZOl5tf+9mKEwrergim5GzwJpfZWPLAyK2Gs57+F+BMgtX6DT0eh4sGQLQDahPZDhy
Ubo420AiTGuTA9/L22B/qbPNuDRNMMJoreAZeSNBSVPa7Q+Y0oXcfKpAmKzHH2Y+WAzupN5jfxhJ
6yb7MpsPDqoU0Ek4VttgUIl4AQlRFMI18ScKvAG2p9kWSSgq+Z9xdQl7F/3ASkXlQMKEOHCDw8E7
XUzqy4pOoXGaI3FVI4AerPeLgz2SkNINfqLnxdhN+BQ6iuRgsOeyIwIDAQABo4IDNTCCAzEwCwYD
VR0PBAQDAgQwMD0GCSsGAQQBgjcVBwQwMC4GJisGAQQBgjcVCIbDjHWEmeVRg/2BKIWOn1OCkcAJ
Z4S52UGHhP9OAgFkAgEMMEQGCSqGSIb3DQEJDwQ3MDUwDgYIKoZIhvcNAwICAgCAMA4GCCqGSIb3
DQMEAgIAgDAHBgUrDgMCBzAKBggqhkiG9w0DBzAdBgNVHQ4EFgQU/+6IdpvPrUveCml7StYwqL40
iqMwHwYDVR0jBBgwFoAUDsYq91myCBCQJW/D3f2KZjEwK8Uwgc8GA1UdHwSBxzCBxDCBwaCBvqCB
u4ZXaHR0cDovL3d3dy5pbnRlbC5jb20vcmVwb3NpdG9yeS9DUkwvSW50ZWwlMjBFeHRlcm5hbCUy
MEJhc2ljJTIwSXNzdWluZyUyMENBJTIwM0IoMSkuY3JshmBodHRwOi8vY2VydGlmaWNhdGVzLmlu
dGVsLmNvbS9yZXBvc2l0b3J5L0NSTC9JbnRlbCUyMEV4dGVybmFsJTIwQmFzaWMlMjBJc3N1aW5n
JTIwQ0ElMjAzQigxKS5jcmwwgfUGCCsGAQUFBwEBBIHoMIHlMGwGCCsGAQUFBzAChmBodHRwOi8v
d3d3LmludGVsLmNvbS9yZXBvc2l0b3J5L2NlcnRpZmljYXRlcy9JbnRlbCUyMEV4dGVybmFsJTIw
QmFzaWMlMjBJc3N1aW5nJTIwQ0ElMjAzQigxKS5jcnQwdQYIKwYBBQUHMAKGaWh0dHA6Ly9jZXJ0
aWZpY2F0ZXMuaW50ZWwuY29tL3JlcG9zaXRvcnkvY2VydGlmaWNhdGVzL0ludGVsJTIwRXh0ZXJu
YWwlMjBCYXNpYyUyMElzc3VpbmclMjBDQSUyMDNCKDEpLmNydDAfBgNVHSUEGDAWBggrBgEFBQcD
BAYKKwYBBAGCNwoDBDApBgkrBgEEAYI3FQoEHDAaMAoGCCsGAQUFBwMEMAwGCisGAQQBgjcKAwQw
RwYDVR0RBEAwPqAlBgorBgEEAYI3FAIDoBcMFWhhaXRhby5zaGFuQGludGVsLmNvbYEVaGFpdGFv
LnNoYW5AaW50ZWwuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQAqWvSRW8jKGuWVwUKo/+QRxKvuT3cv
/975omnwo7QeOj78XruY/Wsl6/tnzI8jgf6ZE5SRoj5sSGBHmy7qHSZNWodLuJgjN+a0Fk2hy0jB
wX2UJLS3ctijemo4e4u8/YFebLVXCzy81lWa7dZcidebnslLlcQXHNzl8hhFAfQwhcCXMAiA89NO
3uJqd9Sk/PSfG90b/f+1u2xIthxQmeh7u1yuiHZrf1u/e6rJWS50iW+LWmrH0c70XN8voHpLXVDo
09C9DETzJOUrhr1BqLVSxKjNn/uhCOcQxNYM3CYsgQBwVogKsGj59xeGFA5iWPKGRj7SfUXH0m3T
kiSaWLnWMYIDhjCCA4ICAQEwZDBWMQswCQYDVQQGEwJVUzEaMBgGA1UEChMRSW50ZWwgQ29ycG9y
YXRpb24xKzApBgNVBAMTIkludGVsIEV4dGVybmFsIEJhc2ljIElzc3VpbmcgQ0EgM0ICChMdOoEA
AQAAe60wCQYFKw4DAhoFAKCCAfcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0B
CQUxDxcNMTExMjAxMTExOTU4WjAjBgkqhkiG9w0BCQQxFgQUEXOV1KD932OM2TYRkUpApnPlkqQw
cwYJKwYBBAGCNxAEMWYwZDBWMQswCQYDVQQGEwJVUzEaMBgGA1UEChMRSW50ZWwgQ29ycG9yYXRp
b24xKzApBgNVBAMTIkludGVsIEV4dGVybmFsIEJhc2ljIElzc3VpbmcgQ0EgM0ICChMjTTEAAQAA
e64wdQYLKoZIhvcNAQkQAgsxZqBkMFYxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFJbnRlbCBDb3Jw
b3JhdGlvbjErMCkGA1UEAxMiSW50ZWwgRXh0ZXJuYWwgQmFzaWMgSXNzdWluZyBDQSAzQgIKEyNN
MQABAAB7rjCBqwYJKoZIhvcNAQkPMYGdMIGaMAoGCCqGSIb3DQMHMAsGCWCGSAFlAwQBKjALBglg
hkgBZQMEARYwCwYJYIZIAWUDBAECMA4GCCqGSIb3DQMCAgIAgDAHBgUrDgMCBzANBggqhkiG9w0D
AgIBQDANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAsG
CWCGSAFlAwQCATANBgkqhkiG9w0BAQEFAASCAQBtmYbiZXw/ajIP+upMNv+LLM0kDE+PKpP9IqdX
RrqyL5UetDZ6koj1tL9mqgLg0XxAp1sYuC1QQ3Sm1X8vMHLe0RbM4jAzBlJDHIVTIweZ9vIdFr/D
+o2ACOH2PJaQw48VndNT0TKGUCAA0qMa3iii/foIqf1yVDXR1VyB30FAgUAb2W6f5aomVQ5ZOF+K
TVp6UcOQoBxYNy6OBCgDAYbyJv8HZHEQyNZExmzBk1uk0/whB+DkRGL8DwrI55gwI4KbwSxrvdts
KBuj1BckCmglypS+XWufbac1wjzEBgNUrLQb1O75dtG2VrMK3kFdSzCyee9XAoKZl+r1u1r0YnBz
AAAAAAAA

------=_NextPart_000_014B_01CCB05E.3751E4B0--


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

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

--===============1791125040118541128==--


From xen-devel-bounces@lists.xensource.com Thu Dec 01 11:21:29 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 11:21:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW4hR-0004eF-ET; Thu, 01 Dec 2011 11:21:09 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <haitao.shan@intel.com>) id 1RW4hP-0004eA-W0
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 11:21:08 +0000
X-Env-Sender: haitao.shan@intel.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1322738427!5431460!1
X-Originating-IP: [134.134.136.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjQgPT4gMzIwNDI3\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6638 invoked from network); 1 Dec 2011 11:20:27 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-9.tower-182.messagelabs.com with SMTP;
	1 Dec 2011 11:20:27 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga102.jf.intel.com with ESMTP; 01 Dec 2011 03:20:04 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.67,352,1309762800"; 
	d="p7s'?scan'208";a="81700234"
Received: from pgsmsx601.gar.corp.intel.com ([10.221.43.69])
	by orsmga001.jf.intel.com with ESMTP; 01 Dec 2011 03:20:02 -0800
Received: from shsmsx601.ccr.corp.intel.com (10.239.4.112) by
	pgsmsx601.gar.corp.intel.com (10.221.43.69) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Thu, 1 Dec 2011 19:20:02 +0800
Received: from shsmsx502.ccr.corp.intel.com ([10.239.4.96]) by
	shsmsx601.ccr.corp.intel.com ([10.239.4.112]) with mapi; Thu, 1 Dec 2011
	19:20:00 +0800
From: "Shan, Haitao" <haitao.shan@intel.com>
To: Jan Beulich <JBeulich@suse.com>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>
Date: Thu, 1 Dec 2011 19:19:58 +0800
Thread-Topic: [Xen-devel] [PATCH] vvmx: fix intended assignment
Thread-Index: AcywF4Hb20gFLSMJSMKXkw2TYA3pbwAA1naA
Message-ID: <04F972F38B3C4E4E91C4697DA8BF9F5284357D52A6@shsmsx502.ccr.corp.intel.com>
References: <4ED76A350200007800064ABD@nat28.tlf.novell.com>
In-Reply-To: <4ED76A350200007800064ABD@nat28.tlf.novell.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "Dong, Eddie" <eddie.dong@intel.com>, Tim Deegan <Tim.Deegan@citrix.com>,
	"He, Qing" <qing.he@intel.com>
Subject: Re: [Xen-devel] [PATCH] vvmx: fix intended assignment
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1791125040118541128=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============1791125040118541128==
Content-Language: en-US
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature";
	micalg=SHA1; boundary="----=_NextPart_000_014B_01CCB05E.3751E4B0"

------=_NextPart_000_014B_01CCB05E.3751E4B0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hi, Jan,

I think you cannot cc He Qing any more. As He Qing (who had done some work
on nested) has left Intel, while this email address is going to another
people who just has the same name.

Shan Haitao

> -----Original Message-----
> From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-
> bounces@lists.xensource.com] On Behalf Of Jan Beulich
> Sent: Thursday, December 01, 2011 6:51 PM
> To: xen-devel@lists.xensource.com
> Cc: Dong, Eddie; Tim Deegan; He, Qing
> Subject: [Xen-devel] [PATCH] vvmx: fix intended assignment
> 
> From what I can tell, this was supposed to be an assignment (not warned
> about by the compiler due to -Wno-unused, which is about to be removed).
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> --- a/xen/arch/x86/hvm/vmx/vvmx.c
> +++ b/xen/arch/x86/hvm/vmx/vvmx.c
> @@ -581,7 +581,7 @@ static void nvmx_purge_vvmcs(struct vcpu
>      __clear_current_vvmcs(v);
>      if ( nvcpu->nv_vvmcxaddr != VMCX_EADDR )
>          hvm_unmap_guest_frame(nvcpu->nv_vvmcx);
> -    nvcpu->nv_vvmcx == NULL;
> +    nvcpu->nv_vvmcx = NULL;
>      nvcpu->nv_vvmcxaddr = VMCX_EADDR;
>      for (i=0; i<2; i++) {
>          if ( nvmx->iobitmap[i] ) {
> 
> 


------=_NextPart_000_014B_01CCB05E.3751E4B0
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIYUDCCAyAw
ggKJoAMCAQICBDXe9M8wDQYJKoZIhvcNAQEFBQAwTjELMAkGA1UEBhMCVVMxEDAOBgNVBAoTB0Vx
dWlmYXgxLTArBgNVBAsTJEVxdWlmYXggU2VjdXJlIENlcnRpZmljYXRlIEF1dGhvcml0eTAeFw05
ODA4MjIxNjQxNTFaFw0xODA4MjIxNjQxNTFaME4xCzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVp
ZmF4MS0wKwYDVQQLEyRFcXVpZmF4IFNlY3VyZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwgZ8wDQYJ
KoZIhvcNAQEBBQADgY0AMIGJAoGBAMFdsVhnCGLuoJotHwhtkRRomAoe/toEbxOEYiHD0XzOnwXg
uAHwTjTs4oqVBGSs8WtTXwWzy2eAv0ICjv7dAQns4QAUT/z78AzdQ7pbK+EfgHCZFVeTFvEPl2q3
wmgjHMxNWTCsUR47ryvW7mNFe8XZX1DS41APOojnvxT94Me5AgMBAAGjggEJMIIBBTBwBgNVHR8E
aTBnMGWgY6BhpF8wXTELMAkGA1UEBhMCVVMxEDAOBgNVBAoTB0VxdWlmYXgxLTArBgNVBAsTJEVx
dWlmYXggU2VjdXJlIENlcnRpZmljYXRlIEF1dGhvcml0eTENMAsGA1UEAxMEQ1JMMTAaBgNVHRAE
EzARgQ8yMDE4MDgyMjE2NDE1MVowCwYDVR0PBAQDAgEGMB8GA1UdIwQYMBaAFEjmaPkr0rKV10fY
IyAQTzOYkJ/UMB0GA1UdDgQWBBRI5mj5K9KylddH2CMgEE8zmJCf1DAMBgNVHRMEBTADAQH/MBoG
CSqGSIb2fQdBAAQNMAsbBVYzLjBjAwIGwDANBgkqhkiG9w0BAQUFAAOBgQBYzinq/Pfetc4CuRe1
hdG54+CVzCUxDQCmkm5/tpJjnlCV0Zpv5BHeY4VumO6o/1rI01WyZnFX3sAh6z0qpyNJAQSGQnv8
7n+iFlK1Z2fTQNs7JliyKHc9rhR3Ydb6KmYnoA36p3Nc6nDxlCFlRF/6/O8paKmih3nvee9PrAd3
ODCCAz0wggKmoAMCAQICAwWw/zANBgkqhkiG9w0BAQUFADBOMQswCQYDVQQGEwJVUzEQMA4GA1UE
ChMHRXF1aWZheDEtMCsGA1UECxMkRXF1aWZheCBTZWN1cmUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5
MB4XDTA2MDIxNjE4MDEzMFoXDTE2MDIxOTE4MDEzMFowUjELMAkGA1UEBhMCVVMxGjAYBgNVBAoT
EUludGVsIENvcnBvcmF0aW9uMScwJQYDVQQDEx5JbnRlbCBFeHRlcm5hbCBCYXNpYyBQb2xpY3kg
Q0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDBpd/XOb9QVqEZ8mQ1042TdOIq3ATD
IsV2xDyt30yLyMR5Wjtus0bn3B+he89BiNO/LP6+rFzEwlD55PlX+HLGIKeNNG97dqyc30FElEUj
ZzTZFq2N4e3kVJ/XAEEgANzV8v9qp7qWwxugPgfc3z9BkYot+CifozexHLb/hEZj+yISCU61kRZv
uSQ0E11yYL4dRgcglJeaHo3oX57rvIckaLsYV5/1Aj+R8DM1Ppk965XQAKsHfnyT7C4S50T4lVn4
lz36wOdNZn/zegG1zp41lnoTFfT4KuKVJH5x7YD1p6KbgJCKLovnujGuohquBNfdXKpZkvz6pGv+
iC1HawJdAgMBAAGjgaAwgZ0wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBQaxgxKxEdvqNutK/D0
Vgaj7TdUDDA6BgNVHR8EMzAxMC+gLaArhilodHRwOi8vY3JsLmdlb3RydXN0LmNvbS9jcmxzL3Nl
Y3VyZWNhLmNybDAfBgNVHSMEGDAWgBRI5mj5K9KylddH2CMgEE8zmJCf1DAPBgNVHRMBAf8EBTAD
AQH/MA0GCSqGSIb3DQEBBQUAA4GBABMQOK2kVKVIlUWwLTdywJ+e2O+PC/uQltK2F3lRyrPfBn69
tOkIP4SgDJOfsxyobIrPLe75kBLw+Dom13OBDp/EMZJZ1CglQfVV8co9mT3aZMjSGGQiMgkJLR3j
Mfr900fXZKj5XeqCJ+JP0mEhJGEdVCY+FFlksJjV86fDrq1QMIIFijCCBHKgAwIBAgIKYSCKYgAA
AAAACDANBgkqhkiG9w0BAQUFADBSMQswCQYDVQQGEwJVUzEaMBgGA1UEChMRSW50ZWwgQ29ycG9y
YXRpb24xJzAlBgNVBAMTHkludGVsIEV4dGVybmFsIEJhc2ljIFBvbGljeSBDQTAeFw0wOTA1MTUx
OTI3MjZaFw0xNTA1MTUxOTM3MjZaMFYxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFJbnRlbCBDb3Jw
b3JhdGlvbjErMCkGA1UEAxMiSW50ZWwgRXh0ZXJuYWwgQmFzaWMgSXNzdWluZyBDQSAzQjCCASIw
DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKQEM1Wn9TU9vc9C+/Tc7KB+eiYElmrcEWE32WUd
HvWG+IcQHVQsikTmMyKKojNLw2B5s6Iekc8ivDo/wCfjZzX9JyftMnc+AArc0la87Olybzm8K9jX
EfTBvTnUSFSiI9ZYefITdiUgqlAFuljFZEHYKYtLuhrRacpmQfP4mV63NKdc2bT804HRf6YptZFa
4k6YN94zlrGNrBuQQ74WFzz/jLBusbUpEkro6Mu/ZYFOFWQrV9lBhF9Ruk8yN+3N6n9fUo/qBigi
F2kEn9xVh1ykl7SCGL2jBUkXx4qgV27a6Si8lRRdgrHGtN/HWnSWlLXTH5l575H4Lq++77OFv38C
AwEAAaOCAlwwggJYMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFA7GKvdZsggQkCVvw939imYx
MCvFMAsGA1UdDwQEAwIBhjASBgkrBgEEAYI3FQEEBQIDAQABMCMGCSsGAQQBgjcVAgQWBBQ5oFY2
ekKQ/5Ktim+VdMeSWb4QWTAZBgkrBgEEAYI3FAIEDB4KAFMAdQBiAEMAQTAfBgNVHSMEGDAWgBQa
xgxKxEdvqNutK/D0Vgaj7TdUDDCBvQYDVR0fBIG1MIGyMIGvoIGsoIGphk5odHRwOi8vd3d3Lmlu
dGVsLmNvbS9yZXBvc2l0b3J5L0NSTC9JbnRlbCUyMEV4dGVybmFsJTIwQmFzaWMlMjBQb2xpY3kl
MjBDQS5jcmyGV2h0dHA6Ly9jZXJ0aWZpY2F0ZXMuaW50ZWwuY29tL3JlcG9zaXRvcnkvQ1JML0lu
dGVsJTIwRXh0ZXJuYWwlMjBCYXNpYyUyMFBvbGljeSUyMENBLmNybDCB4wYIKwYBBQUHAQEEgdYw
gdMwYwYIKwYBBQUHMAKGV2h0dHA6Ly93d3cuaW50ZWwuY29tL3JlcG9zaXRvcnkvY2VydGlmaWNh
dGVzL0ludGVsJTIwRXh0ZXJuYWwlMjBCYXNpYyUyMFBvbGljeSUyMENBLmNydDBsBggrBgEFBQcw
AoZgaHR0cDovL2NlcnRpZmljYXRlcy5pbnRlbC5jb20vcmVwb3NpdG9yeS9jZXJ0aWZpY2F0ZXMv
SW50ZWwlMjBFeHRlcm5hbCUyMEJhc2ljJTIwUG9saWN5JTIwQ0EuY3J0MA0GCSqGSIb3DQEBBQUA
A4IBAQCxtQEHchVQhXyjEqtMVUMe6gkmPsIczHxSeqNbo9dsD+6xbT65JT+oYgpIAtfEsYXeUJu1
cChqpb22U5bMAz7eaQcW5bzefufWvA6lg2048B8oczBj/q+5P5NpYrUO8jOmN4jTjfJq3ElZ7yFW
py7rB3Vm/aN6ATYqWfMbS/xfh+JCxmH3droUmMJI0/aZJHsLtjbjFnNsHDNrJZX1vxlM78Lb1hjs
kTENPmhbVbfTj5i/ZGnhv4tmI8QZPCNtcegXJrfhRl2D9bWpdTOPrWiLDUqzy1Z6KL7TcOS/PCl8
RHCJXkPau/thTQCpIoDa2+c+3XA++gRTfAQ4svTO260NMIIGBzCCBO+gAwIBAgIKEx06gQABAAB7
rTANBgkqhkiG9w0BAQUFADBWMQswCQYDVQQGEwJVUzEaMBgGA1UEChMRSW50ZWwgQ29ycG9yYXRp
b24xKzApBgNVBAMTIkludGVsIEV4dGVybmFsIEJhc2ljIElzc3VpbmcgQ0EgM0IwHhcNMTExMDEy
MDEyNDIwWhcNMTQwOTI2MDEyNDIwWjA9MRUwEwYDVQQDEwxTaGFuLCBIYWl0YW8xJDAiBgkqhkiG
9w0BCQEWFWhhaXRhby5zaGFuQGludGVsLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC
ggEBALpHYbXkMy06K6Pl9IGxbsKl0zT/OYd523Rh3CX7tHG/80ZGcPeLlzFK+l+30Fhpzf8fsFwG
l5fX2pRtWqT96BUWecXEVJhisfa1Wrq7DBC6coxEnExFADU+2UsBQ/ACKFSCiq/fADojyFWJgPKv
4PLDKJ9LU23Q+g1WRruGHfBnhCMv0KxnkE7pTk3cFRXtNUSUnYLqcvrZwt9VogQNiNNw3jMlDb8t
bJjMsXdhrwqFGW49z/gAJ2Mnr6/lNnqBdcKF2Qm28SfYXRohGrmam3KReM49ZG0+J/+JPF5drbiw
UAV++PMHA3IXIvZF2c66jQM5BzbF93SkoZXmrQZA2jMCAwEAAaOCAu4wggLqMAsGA1UdDwQEAwIH
gDA8BgkrBgEEAYI3FQcELzAtBiUrBgEEAYI3FQiGw4x1hJnlUYP9gSiFjp9TgpHACWeB3r05lfBD
AgFkAgEIMB0GA1UdDgQWBBQ/OInBCgrko9ziRWiEhjM+SyeeoDAfBgNVHSMEGDAWgBQOxir3WbII
EJAlb8Pd/YpmMTArxTCBzwYDVR0fBIHHMIHEMIHBoIG+oIG7hldodHRwOi8vd3d3LmludGVsLmNv
bS9yZXBvc2l0b3J5L0NSTC9JbnRlbCUyMEV4dGVybmFsJTIwQmFzaWMlMjBJc3N1aW5nJTIwQ0El
MjAzQigxKS5jcmyGYGh0dHA6Ly9jZXJ0aWZpY2F0ZXMuaW50ZWwuY29tL3JlcG9zaXRvcnkvQ1JM
L0ludGVsJTIwRXh0ZXJuYWwlMjBCYXNpYyUyMElzc3VpbmclMjBDQSUyMDNCKDEpLmNybDCB9QYI
KwYBBQUHAQEEgegwgeUwbAYIKwYBBQUHMAKGYGh0dHA6Ly93d3cuaW50ZWwuY29tL3JlcG9zaXRv
cnkvY2VydGlmaWNhdGVzL0ludGVsJTIwRXh0ZXJuYWwlMjBCYXNpYyUyMElzc3VpbmclMjBDQSUy
MDNCKDEpLmNydDB1BggrBgEFBQcwAoZpaHR0cDovL2NlcnRpZmljYXRlcy5pbnRlbC5jb20vcmVw
b3NpdG9yeS9jZXJ0aWZpY2F0ZXMvSW50ZWwlMjBFeHRlcm5hbCUyMEJhc2ljJTIwSXNzdWluZyUy
MENBJTIwM0IoMSkuY3J0MB8GA1UdJQQYMBYGCCsGAQUFBwMEBgorBgEEAYI3CgMMMCkGCSsGAQQB
gjcVCgQcMBowCgYIKwYBBQUHAwQwDAYKKwYBBAGCNwoDDDBHBgNVHREEQDA+oCUGCisGAQQBgjcU
AgOgFwwVaGFpdGFvLnNoYW5AaW50ZWwuY29tgRVoYWl0YW8uc2hhbkBpbnRlbC5jb20wDQYJKoZI
hvcNAQEFBQADggEBAG5Us26ruu8jKt3RhZuirjqgF61p+wZer/xV6BTABUx5++DhWXslTztavsvy
JZ5WsZ7xaijBUO3UQViWTylwmSyGwbhEwreu3XRNGlMOnRk+sH7JGiXZJIpqoD/jtRWp0ypHG2g3
nDqAQ1/j4wUgcI0b12KUJyYAeN6cwEeAqIV4mdD8GpH3DS2nZbEZjTNhkaeJuT7lO1jRqzEGOSCk
KDHPfqUtqpw+wZa6mFbzSso9swc4ypgRIl4l5i/4OwNMQazHm2O6Ov91aDJs6j3DCdALzP736hmF
QFfHWL34GFQMRdpO/OI6z/Q0VYm/6N9o4SD/s4J9Edq8zyYNQxBR03QwggZOMIIFNqADAgECAgoT
I00xAAEAAHuuMA0GCSqGSIb3DQEBBQUAMFYxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFJbnRlbCBD
b3Jwb3JhdGlvbjErMCkGA1UEAxMiSW50ZWwgRXh0ZXJuYWwgQmFzaWMgSXNzdWluZyBDQSAzQjAe
Fw0xMTEwMTIwMTMwNTZaFw0xNDA5MjYwMTMwNTZaMD0xFTATBgNVBAMTDFNoYW4sIEhhaXRhbzEk
MCIGCSqGSIb3DQEJARYVaGFpdGFvLnNoYW5AaW50ZWwuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOC
AQ8AMIIBCgKCAQEApaOcuQtYCobUiLQTadd0Hi+U/ausgzeSE59iUrc57VUzvLsLNnKRxLPm+T26
KN9fMDAS3/MZOl5tf+9mKEwrergim5GzwJpfZWPLAyK2Gs57+F+BMgtX6DT0eh4sGQLQDahPZDhy
Ubo420AiTGuTA9/L22B/qbPNuDRNMMJoreAZeSNBSVPa7Q+Y0oXcfKpAmKzHH2Y+WAzupN5jfxhJ
6yb7MpsPDqoU0Ek4VttgUIl4AQlRFMI18ScKvAG2p9kWSSgq+Z9xdQl7F/3ASkXlQMKEOHCDw8E7
XUzqy4pOoXGaI3FVI4AerPeLgz2SkNINfqLnxdhN+BQ6iuRgsOeyIwIDAQABo4IDNTCCAzEwCwYD
VR0PBAQDAgQwMD0GCSsGAQQBgjcVBwQwMC4GJisGAQQBgjcVCIbDjHWEmeVRg/2BKIWOn1OCkcAJ
Z4S52UGHhP9OAgFkAgEMMEQGCSqGSIb3DQEJDwQ3MDUwDgYIKoZIhvcNAwICAgCAMA4GCCqGSIb3
DQMEAgIAgDAHBgUrDgMCBzAKBggqhkiG9w0DBzAdBgNVHQ4EFgQU/+6IdpvPrUveCml7StYwqL40
iqMwHwYDVR0jBBgwFoAUDsYq91myCBCQJW/D3f2KZjEwK8Uwgc8GA1UdHwSBxzCBxDCBwaCBvqCB
u4ZXaHR0cDovL3d3dy5pbnRlbC5jb20vcmVwb3NpdG9yeS9DUkwvSW50ZWwlMjBFeHRlcm5hbCUy
MEJhc2ljJTIwSXNzdWluZyUyMENBJTIwM0IoMSkuY3JshmBodHRwOi8vY2VydGlmaWNhdGVzLmlu
dGVsLmNvbS9yZXBvc2l0b3J5L0NSTC9JbnRlbCUyMEV4dGVybmFsJTIwQmFzaWMlMjBJc3N1aW5n
JTIwQ0ElMjAzQigxKS5jcmwwgfUGCCsGAQUFBwEBBIHoMIHlMGwGCCsGAQUFBzAChmBodHRwOi8v
d3d3LmludGVsLmNvbS9yZXBvc2l0b3J5L2NlcnRpZmljYXRlcy9JbnRlbCUyMEV4dGVybmFsJTIw
QmFzaWMlMjBJc3N1aW5nJTIwQ0ElMjAzQigxKS5jcnQwdQYIKwYBBQUHMAKGaWh0dHA6Ly9jZXJ0
aWZpY2F0ZXMuaW50ZWwuY29tL3JlcG9zaXRvcnkvY2VydGlmaWNhdGVzL0ludGVsJTIwRXh0ZXJu
YWwlMjBCYXNpYyUyMElzc3VpbmclMjBDQSUyMDNCKDEpLmNydDAfBgNVHSUEGDAWBggrBgEFBQcD
BAYKKwYBBAGCNwoDBDApBgkrBgEEAYI3FQoEHDAaMAoGCCsGAQUFBwMEMAwGCisGAQQBgjcKAwQw
RwYDVR0RBEAwPqAlBgorBgEEAYI3FAIDoBcMFWhhaXRhby5zaGFuQGludGVsLmNvbYEVaGFpdGFv
LnNoYW5AaW50ZWwuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQAqWvSRW8jKGuWVwUKo/+QRxKvuT3cv
/975omnwo7QeOj78XruY/Wsl6/tnzI8jgf6ZE5SRoj5sSGBHmy7qHSZNWodLuJgjN+a0Fk2hy0jB
wX2UJLS3ctijemo4e4u8/YFebLVXCzy81lWa7dZcidebnslLlcQXHNzl8hhFAfQwhcCXMAiA89NO
3uJqd9Sk/PSfG90b/f+1u2xIthxQmeh7u1yuiHZrf1u/e6rJWS50iW+LWmrH0c70XN8voHpLXVDo
09C9DETzJOUrhr1BqLVSxKjNn/uhCOcQxNYM3CYsgQBwVogKsGj59xeGFA5iWPKGRj7SfUXH0m3T
kiSaWLnWMYIDhjCCA4ICAQEwZDBWMQswCQYDVQQGEwJVUzEaMBgGA1UEChMRSW50ZWwgQ29ycG9y
YXRpb24xKzApBgNVBAMTIkludGVsIEV4dGVybmFsIEJhc2ljIElzc3VpbmcgQ0EgM0ICChMdOoEA
AQAAe60wCQYFKw4DAhoFAKCCAfcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0B
CQUxDxcNMTExMjAxMTExOTU4WjAjBgkqhkiG9w0BCQQxFgQUEXOV1KD932OM2TYRkUpApnPlkqQw
cwYJKwYBBAGCNxAEMWYwZDBWMQswCQYDVQQGEwJVUzEaMBgGA1UEChMRSW50ZWwgQ29ycG9yYXRp
b24xKzApBgNVBAMTIkludGVsIEV4dGVybmFsIEJhc2ljIElzc3VpbmcgQ0EgM0ICChMjTTEAAQAA
e64wdQYLKoZIhvcNAQkQAgsxZqBkMFYxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFJbnRlbCBDb3Jw
b3JhdGlvbjErMCkGA1UEAxMiSW50ZWwgRXh0ZXJuYWwgQmFzaWMgSXNzdWluZyBDQSAzQgIKEyNN
MQABAAB7rjCBqwYJKoZIhvcNAQkPMYGdMIGaMAoGCCqGSIb3DQMHMAsGCWCGSAFlAwQBKjALBglg
hkgBZQMEARYwCwYJYIZIAWUDBAECMA4GCCqGSIb3DQMCAgIAgDAHBgUrDgMCBzANBggqhkiG9w0D
AgIBQDANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAsG
CWCGSAFlAwQCATANBgkqhkiG9w0BAQEFAASCAQBtmYbiZXw/ajIP+upMNv+LLM0kDE+PKpP9IqdX
RrqyL5UetDZ6koj1tL9mqgLg0XxAp1sYuC1QQ3Sm1X8vMHLe0RbM4jAzBlJDHIVTIweZ9vIdFr/D
+o2ACOH2PJaQw48VndNT0TKGUCAA0qMa3iii/foIqf1yVDXR1VyB30FAgUAb2W6f5aomVQ5ZOF+K
TVp6UcOQoBxYNy6OBCgDAYbyJv8HZHEQyNZExmzBk1uk0/whB+DkRGL8DwrI55gwI4KbwSxrvdts
KBuj1BckCmglypS+XWufbac1wjzEBgNUrLQb1O75dtG2VrMK3kFdSzCyee9XAoKZl+r1u1r0YnBz
AAAAAAAA

------=_NextPart_000_014B_01CCB05E.3751E4B0--


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

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

--===============1791125040118541128==--


From xen-devel-bounces@lists.xensource.com Thu Dec 01 11:31:51 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 11:31:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW4rV-0004ts-OH; Thu, 01 Dec 2011 11:31:33 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1RW4rU-0004tn-7P
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 11:31:32 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1322738949!54451875!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8092 invoked from network); 1 Dec 2011 11:29:11 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 11:29:11 -0000
Received: by iaen33 with SMTP id n33so3094703iae.30
	for <xen-devel@lists.xensource.com>;
	Thu, 01 Dec 2011 03:30:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=MnuAYNjwgpW/uGPJdFxeUqftu94jLf0EydxEV2pbY/k=;
	b=a7MT+rm0P7IPmFtwtDv16QyivuPK/rBODrRgnJg5JFrQL5CPTCfDFLpZR+V/zoo+8r
	CnsghR7sVOXrm7r37PM5rJ+8F75EFGNMe+CiANJsHKZzVrfUl7X0gxiiGY4p03pg1Jj+
	yClnccxdaZRwFapI1a5+YsWYgMbkJ9Sf0LbcY=
MIME-Version: 1.0
Received: by 10.50.216.167 with SMTP id or7mr7761138igc.22.1322739055760; Thu,
	01 Dec 2011 03:30:55 -0800 (PST)
Received: by 10.231.169.13 with HTTP; Thu, 1 Dec 2011 03:30:55 -0800 (PST)
In-Reply-To: <CAP=GMUEvnnOGmiM9ar+oQw4c6fwzvWa+HX98C3kV_XgMc3xg9Q@mail.gmail.com>
References: <CAP=GMUEvnnOGmiM9ar+oQw4c6fwzvWa+HX98C3kV_XgMc3xg9Q@mail.gmail.com>
Date: Thu, 1 Dec 2011 11:30:55 +0000
X-Google-Sender-Auth: 5FISUr0j69VN1A6Jh0x7VEm5j5A
Message-ID: <CAFLBxZYu4ormVzBJgakptUL6NvQSJrdQZUSVjeJtP4LCdVj3CA@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Baozeng <sploving1@gmail.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] any exit function in xen that is similar to
	exit_kernel?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Nov 29, 2011 at 2:22 PM, Baozeng <sploving1@gmail.com> wrote:
> Hello all,
> I added a hypercall "do_greet" that only prints "Hello world" to do a
> small experiment. After it prints the "hello world", I would it to
> exit from Xen and stop current process. For instance:
> the hypercall is like this:
> int do_greet(){
> =A0 pirntk("Hello world\n");
> =A0 /*then I would it exit from Xen and stop current process that called =
it.*/
> =A0 exit_?? //exit(0) does not work.
> }
>
> If a process at the application level calls this hypercall through
> privcmd file, I would like it kill this process after the hypercall
> prints "Hello world". Then how to do that?

A process is a guest kernel-level construct.  Xen doesn't know
anything about processes; it only knows things about VMs.  You can
easily kill the guest by doing this:
  domain_crash(current->domain);

If you want the process only to be killed, you have to have the guest
kernel do it.

 -George

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 11:31:51 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 11:31:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW4rV-0004ts-OH; Thu, 01 Dec 2011 11:31:33 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1RW4rU-0004tn-7P
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 11:31:32 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1322738949!54451875!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8092 invoked from network); 1 Dec 2011 11:29:11 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 11:29:11 -0000
Received: by iaen33 with SMTP id n33so3094703iae.30
	for <xen-devel@lists.xensource.com>;
	Thu, 01 Dec 2011 03:30:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=MnuAYNjwgpW/uGPJdFxeUqftu94jLf0EydxEV2pbY/k=;
	b=a7MT+rm0P7IPmFtwtDv16QyivuPK/rBODrRgnJg5JFrQL5CPTCfDFLpZR+V/zoo+8r
	CnsghR7sVOXrm7r37PM5rJ+8F75EFGNMe+CiANJsHKZzVrfUl7X0gxiiGY4p03pg1Jj+
	yClnccxdaZRwFapI1a5+YsWYgMbkJ9Sf0LbcY=
MIME-Version: 1.0
Received: by 10.50.216.167 with SMTP id or7mr7761138igc.22.1322739055760; Thu,
	01 Dec 2011 03:30:55 -0800 (PST)
Received: by 10.231.169.13 with HTTP; Thu, 1 Dec 2011 03:30:55 -0800 (PST)
In-Reply-To: <CAP=GMUEvnnOGmiM9ar+oQw4c6fwzvWa+HX98C3kV_XgMc3xg9Q@mail.gmail.com>
References: <CAP=GMUEvnnOGmiM9ar+oQw4c6fwzvWa+HX98C3kV_XgMc3xg9Q@mail.gmail.com>
Date: Thu, 1 Dec 2011 11:30:55 +0000
X-Google-Sender-Auth: 5FISUr0j69VN1A6Jh0x7VEm5j5A
Message-ID: <CAFLBxZYu4ormVzBJgakptUL6NvQSJrdQZUSVjeJtP4LCdVj3CA@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Baozeng <sploving1@gmail.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] any exit function in xen that is similar to
	exit_kernel?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Nov 29, 2011 at 2:22 PM, Baozeng <sploving1@gmail.com> wrote:
> Hello all,
> I added a hypercall "do_greet" that only prints "Hello world" to do a
> small experiment. After it prints the "hello world", I would it to
> exit from Xen and stop current process. For instance:
> the hypercall is like this:
> int do_greet(){
> =A0 pirntk("Hello world\n");
> =A0 /*then I would it exit from Xen and stop current process that called =
it.*/
> =A0 exit_?? //exit(0) does not work.
> }
>
> If a process at the application level calls this hypercall through
> privcmd file, I would like it kill this process after the hypercall
> prints "Hello world". Then how to do that?

A process is a guest kernel-level construct.  Xen doesn't know
anything about processes; it only knows things about VMs.  You can
easily kill the guest by doing this:
  domain_crash(current->domain);

If you want the process only to be killed, you have to have the guest
kernel do it.

 -George

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 11:54:57 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 11: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.xensource.com>)
	id 1RW5De-0005QO-Sv; Thu, 01 Dec 2011 11:54:26 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RW5Dd-0005QG-8Y
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 11:54:25 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1322740425!5742881!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQzODQ=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9618 invoked from network); 1 Dec 2011 11:53:45 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-15.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 1 Dec 2011 11:53:45 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 01 Dec 2011 11:53:45 +0000
Message-Id: <4ED778D70200007800064B1B@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 01 Dec 2011 11:53:43 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part4C63D8D7.0__="
Subject: [Xen-devel] [PATCH] x86/Intel: quiesce revised CPUID level message
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

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

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

Print this only once, for the boot CPU, unless "cpuinfo" was specified.
I found this particularly annoying on a machine which also didn't have
it MTRRs consistently set up across cores, resulting in the printing of
those messages being awfully slow (and with a second per-CPU message
added for debugging purposes this even lead to timeouts during AP
bringup).

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

--- a/xen/arch/x86/cpu/intel.c
+++ b/xen/arch/x86/cpu/intel.c
@@ -139,7 +139,9 @@ void __devinit early_intel_workaround(st
 			misc_enable &=3D ~MSR_IA32_MISC_ENABLE_LIMIT_CPUID;=

 			wrmsrl(MSR_IA32_MISC_ENABLE, misc_enable);
 			c->cpuid_level =3D cpuid_eax(0);
-			printk("revised cpuid_level =3D %d\n", c->cpuid_lev=
el);
+			if (opt_cpu_info || c =3D=3D &boot_cpu_data)
+				printk(KERN_INFO "revised cpuid level: =
%d\n",
+				       c->cpuid_level);
 		}
 	}
 }




--=__Part4C63D8D7.0__=
Content-Type: text/plain; name="x86-intel-revised-cpuid-level-once.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-intel-revised-cpuid-level-once.patch"

x86/Intel: quiesce revised CPUID level message=0A=0APrint this only once, =
for the boot CPU, unless "cpuinfo" was specified.=0AI found this particular=
ly annoying on a machine which also didn't have=0Ait MTRRs consistently =
set up across cores, resulting in the printing of=0Athose messages being =
awfully slow (and with a second per-CPU message=0Aadded for debugging =
purposes this even lead to timeouts during AP=0Abringup).=0A=0ASigned-off-b=
y: Jan Beulich <jbeulich@suse.com>=0A=0A--- a/xen/arch/x86/cpu/intel.c=0A++=
+ b/xen/arch/x86/cpu/intel.c=0A@@ -139,7 +139,9 @@ void __devinit =
early_intel_workaround(st=0A 			misc_enable &=3D ~MSR_IA32_=
MISC_ENABLE_LIMIT_CPUID;=0A 			wrmsrl(MSR_IA32_MISC_ENABLE=
, misc_enable);=0A 			c->cpuid_level =3D cpuid_eax(0);=0A=
-			printk("revised cpuid_level =3D %d\n", c->cpuid_lev=
el);=0A+			if (opt_cpu_info || c =3D=3D &boot_cpu_data=
)=0A+				printk(KERN_INFO "revised cpuid level: =
%d\n",=0A+				       c->cpuid_level);=0A 		=
}=0A 	}=0A }=0A
--=__Part4C63D8D7.0__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--=__Part4C63D8D7.0__=--


From xen-devel-bounces@lists.xensource.com Thu Dec 01 11:54:57 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 11: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.xensource.com>)
	id 1RW5De-0005QO-Sv; Thu, 01 Dec 2011 11:54:26 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RW5Dd-0005QG-8Y
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 11:54:25 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1322740425!5742881!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQzODQ=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9618 invoked from network); 1 Dec 2011 11:53:45 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-15.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 1 Dec 2011 11:53:45 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 01 Dec 2011 11:53:45 +0000
Message-Id: <4ED778D70200007800064B1B@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 01 Dec 2011 11:53:43 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part4C63D8D7.0__="
Subject: [Xen-devel] [PATCH] x86/Intel: quiesce revised CPUID level message
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

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

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

Print this only once, for the boot CPU, unless "cpuinfo" was specified.
I found this particularly annoying on a machine which also didn't have
it MTRRs consistently set up across cores, resulting in the printing of
those messages being awfully slow (and with a second per-CPU message
added for debugging purposes this even lead to timeouts during AP
bringup).

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

--- a/xen/arch/x86/cpu/intel.c
+++ b/xen/arch/x86/cpu/intel.c
@@ -139,7 +139,9 @@ void __devinit early_intel_workaround(st
 			misc_enable &=3D ~MSR_IA32_MISC_ENABLE_LIMIT_CPUID;=

 			wrmsrl(MSR_IA32_MISC_ENABLE, misc_enable);
 			c->cpuid_level =3D cpuid_eax(0);
-			printk("revised cpuid_level =3D %d\n", c->cpuid_lev=
el);
+			if (opt_cpu_info || c =3D=3D &boot_cpu_data)
+				printk(KERN_INFO "revised cpuid level: =
%d\n",
+				       c->cpuid_level);
 		}
 	}
 }




--=__Part4C63D8D7.0__=
Content-Type: text/plain; name="x86-intel-revised-cpuid-level-once.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-intel-revised-cpuid-level-once.patch"

x86/Intel: quiesce revised CPUID level message=0A=0APrint this only once, =
for the boot CPU, unless "cpuinfo" was specified.=0AI found this particular=
ly annoying on a machine which also didn't have=0Ait MTRRs consistently =
set up across cores, resulting in the printing of=0Athose messages being =
awfully slow (and with a second per-CPU message=0Aadded for debugging =
purposes this even lead to timeouts during AP=0Abringup).=0A=0ASigned-off-b=
y: Jan Beulich <jbeulich@suse.com>=0A=0A--- a/xen/arch/x86/cpu/intel.c=0A++=
+ b/xen/arch/x86/cpu/intel.c=0A@@ -139,7 +139,9 @@ void __devinit =
early_intel_workaround(st=0A 			misc_enable &=3D ~MSR_IA32_=
MISC_ENABLE_LIMIT_CPUID;=0A 			wrmsrl(MSR_IA32_MISC_ENABLE=
, misc_enable);=0A 			c->cpuid_level =3D cpuid_eax(0);=0A=
-			printk("revised cpuid_level =3D %d\n", c->cpuid_lev=
el);=0A+			if (opt_cpu_info || c =3D=3D &boot_cpu_data=
)=0A+				printk(KERN_INFO "revised cpuid level: =
%d\n",=0A+				       c->cpuid_level);=0A 		=
}=0A 	}=0A }=0A
--=__Part4C63D8D7.0__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--=__Part4C63D8D7.0__=--


From xen-devel-bounces@lists.xensource.com Thu Dec 01 11:55:16 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 11:55:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW5E4-0005Rz-FZ; Thu, 01 Dec 2011 11:54:52 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RW5E3-0005Ra-Ga
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 11:54:51 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1322740451!3842844!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU2Nw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6459 invoked from network); 1 Dec 2011 11:54:11 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 11:54:11 -0000
X-IronPort-AV: E=Sophos;i="4.71,277,1320624000"; 
   d="scan'208";a="9227691"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Dec 2011 11:54:11 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.161]) by
	LONPMAILMX01.citrite.net ([10.30.203.162]) with mapi; Thu, 1 Dec 2011
	11:54:11 +0000
From: Paul Durrant <Paul.Durrant@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Thu, 1 Dec 2011 11:54:18 +0000
Thread-Topic: [Xen-devel] [PATCH] Add code to track the address of the VM
	generation id buffer across a
Thread-Index: AcywEAn1OpW+k3cjTFKxraLKeoGhIwAD8suQ
Message-ID: <291EDFCB1E9E224A99088639C4762022B5988E50FE@LONPMAILBOX01.citrite.net>
References: <94a17182f386c8bb414e.1322686717@cosworth.uk.xensource.com>
	<20111130221419.GA16651@andromeda.dapyr.net>
	<291EDFCB1E9E224A99088639C4762022B5988E50D4@LONPMAILBOX01.citrite.net>
	<1322729947.31810.151.camel@zakaz.uk.xensource.com>
	<291EDFCB1E9E224A99088639C4762022B5988E50EA@LONPMAILBOX01.citrite.net>
	<1322733621.31810.176.camel@zakaz.uk.xensource.com>
In-Reply-To: <1322733621.31810.176.camel@zakaz.uk.xensource.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] Add code to track the address of the VM
 generation id buffer across a
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Would the following be sufficient?

  Paul

diff -r 62ff6a318c5d docs/man/xl.cfg.pod.5
--- a/docs/man/xl.cfg.pod.5     Wed Nov 30 16:59:58 2011 -0800
+++ b/docs/man/xl.cfg.pod.5     Thu Dec 01 11:52:58 2011 +0000
@@ -484,6 +484,12 @@ of Xen) within a Xen guest or to support
 which uses hardware virtualisation extensions (e.g. Windows XP
 compatibility mode on more modern Windows OS).

+=item B<generation_id=NUMBER>
+
+This value will be exposed inside the guest at an address which
+can be determined by evaluating the ADDR package of an ACPI device
+with _CID "VM_Gen_Counter".
+
 =back

 =head3 Guest Virtual Time Controls
diff -r 62ff6a318c5d tools/firmware/hvmloader/acpi/dsdt.asl
--- a/tools/firmware/hvmloader/acpi/dsdt.asl    Wed Nov 30 16:59:58 2011 -0800
+++ b/tools/firmware/hvmloader/acpi/dsdt.asl    Thu Dec 01 11:52:58 2011 +0000
@@ -398,6 +398,25 @@ DefinitionBlock ("DSDT.aml", "DSDT", 2,
                     })
                 }

+                /* VM Generation ID Device
+                 *
+                 * The basic requirements of this device are as follows:
+                 *
+                 * - It must be exposed somewhere in ACPI namespace with a _CID of
+                 *   "VM_Gen_Counter".
+                 * - It must also include a _DDN of "VM_Gen_Counter".
+                 * - It must contain a _HID object but no particular value is
+                 *   required.
+                 * - It must expose a package called ADDR which evaluates to two
+                 *   integers; the first being the low order 32-bits of a guest
+                 *   physical address (GPA), the second by the high order 32-bits of
+                 *   the GPA. This GPA is the address of an 8-byte aligned 8-byte
+                 *   buffer containing the VM generation ID.
+                 *   This buffer must not be in ranges supported as AddressRangeMemory
+                 *   or AddressRangeACPI and must not be mapped by any PTE with caching
+                 *   disabled. (See the code in tools/firmware/hvmloader/acpi/build.c
+                 *   which determines the address and contents of the buffer).
+                 */
                 Device(VGID) {
                     Name(_HID, EisaID ("PNP0A06"))
                     Name(_UID, 0x00)

> -----Original Message-----
> From: Ian Campbell
> Sent: 01 December 2011 10:00
> To: Paul Durrant
> Cc: Konrad Rzeszutek Wilk; xen-devel@lists.xensource.com
> Subject: RE: [Xen-devel] [PATCH] Add code to track the address of
> the VM generation id buffer across a
> 
> On Thu, 2011-12-01 at 09:47 +0000, Paul Durrant wrote:
> > > -----Original Message-----
> > > From: Ian Campbell
> > > Sent: 01 December 2011 08:59
> > > To: Paul Durrant
> > > Cc: Konrad Rzeszutek Wilk; xen-devel@lists.xensource.com
> > > Subject: Re: [Xen-devel] [PATCH] Add code to track the address
> of
> > > the VM generation id buffer across a
> > >
> > > On Thu, 2011-12-01 at 08:46 +0000, Paul Durrant wrote:
> > > > Konrad,
> > > >
> > > >   Did you see my previous patch set? The introductory comment
> was:
> > >
> > >
> > > I think that description belongs somewhere permanent, either in
> > > docs/misc or as a comment in an appropriate header.
> > >
> >
> > Good point. Perhaps I should stick the comment just above the
> device description in the dsdt?
> 
> That would do I guess.
> 
> I guess more important would be the user facing toolstack specific
> semantics/documentation i.e. the manpage.
> 
> Ian.
> 

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 11:55:16 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 11:55:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW5E4-0005Rz-FZ; Thu, 01 Dec 2011 11:54:52 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RW5E3-0005Ra-Ga
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 11:54:51 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1322740451!3842844!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU2Nw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6459 invoked from network); 1 Dec 2011 11:54:11 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 11:54:11 -0000
X-IronPort-AV: E=Sophos;i="4.71,277,1320624000"; 
   d="scan'208";a="9227691"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Dec 2011 11:54:11 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.161]) by
	LONPMAILMX01.citrite.net ([10.30.203.162]) with mapi; Thu, 1 Dec 2011
	11:54:11 +0000
From: Paul Durrant <Paul.Durrant@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Thu, 1 Dec 2011 11:54:18 +0000
Thread-Topic: [Xen-devel] [PATCH] Add code to track the address of the VM
	generation id buffer across a
Thread-Index: AcywEAn1OpW+k3cjTFKxraLKeoGhIwAD8suQ
Message-ID: <291EDFCB1E9E224A99088639C4762022B5988E50FE@LONPMAILBOX01.citrite.net>
References: <94a17182f386c8bb414e.1322686717@cosworth.uk.xensource.com>
	<20111130221419.GA16651@andromeda.dapyr.net>
	<291EDFCB1E9E224A99088639C4762022B5988E50D4@LONPMAILBOX01.citrite.net>
	<1322729947.31810.151.camel@zakaz.uk.xensource.com>
	<291EDFCB1E9E224A99088639C4762022B5988E50EA@LONPMAILBOX01.citrite.net>
	<1322733621.31810.176.camel@zakaz.uk.xensource.com>
In-Reply-To: <1322733621.31810.176.camel@zakaz.uk.xensource.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] Add code to track the address of the VM
 generation id buffer across a
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Would the following be sufficient?

  Paul

diff -r 62ff6a318c5d docs/man/xl.cfg.pod.5
--- a/docs/man/xl.cfg.pod.5     Wed Nov 30 16:59:58 2011 -0800
+++ b/docs/man/xl.cfg.pod.5     Thu Dec 01 11:52:58 2011 +0000
@@ -484,6 +484,12 @@ of Xen) within a Xen guest or to support
 which uses hardware virtualisation extensions (e.g. Windows XP
 compatibility mode on more modern Windows OS).

+=item B<generation_id=NUMBER>
+
+This value will be exposed inside the guest at an address which
+can be determined by evaluating the ADDR package of an ACPI device
+with _CID "VM_Gen_Counter".
+
 =back

 =head3 Guest Virtual Time Controls
diff -r 62ff6a318c5d tools/firmware/hvmloader/acpi/dsdt.asl
--- a/tools/firmware/hvmloader/acpi/dsdt.asl    Wed Nov 30 16:59:58 2011 -0800
+++ b/tools/firmware/hvmloader/acpi/dsdt.asl    Thu Dec 01 11:52:58 2011 +0000
@@ -398,6 +398,25 @@ DefinitionBlock ("DSDT.aml", "DSDT", 2,
                     })
                 }

+                /* VM Generation ID Device
+                 *
+                 * The basic requirements of this device are as follows:
+                 *
+                 * - It must be exposed somewhere in ACPI namespace with a _CID of
+                 *   "VM_Gen_Counter".
+                 * - It must also include a _DDN of "VM_Gen_Counter".
+                 * - It must contain a _HID object but no particular value is
+                 *   required.
+                 * - It must expose a package called ADDR which evaluates to two
+                 *   integers; the first being the low order 32-bits of a guest
+                 *   physical address (GPA), the second by the high order 32-bits of
+                 *   the GPA. This GPA is the address of an 8-byte aligned 8-byte
+                 *   buffer containing the VM generation ID.
+                 *   This buffer must not be in ranges supported as AddressRangeMemory
+                 *   or AddressRangeACPI and must not be mapped by any PTE with caching
+                 *   disabled. (See the code in tools/firmware/hvmloader/acpi/build.c
+                 *   which determines the address and contents of the buffer).
+                 */
                 Device(VGID) {
                     Name(_HID, EisaID ("PNP0A06"))
                     Name(_UID, 0x00)

> -----Original Message-----
> From: Ian Campbell
> Sent: 01 December 2011 10:00
> To: Paul Durrant
> Cc: Konrad Rzeszutek Wilk; xen-devel@lists.xensource.com
> Subject: RE: [Xen-devel] [PATCH] Add code to track the address of
> the VM generation id buffer across a
> 
> On Thu, 2011-12-01 at 09:47 +0000, Paul Durrant wrote:
> > > -----Original Message-----
> > > From: Ian Campbell
> > > Sent: 01 December 2011 08:59
> > > To: Paul Durrant
> > > Cc: Konrad Rzeszutek Wilk; xen-devel@lists.xensource.com
> > > Subject: Re: [Xen-devel] [PATCH] Add code to track the address
> of
> > > the VM generation id buffer across a
> > >
> > > On Thu, 2011-12-01 at 08:46 +0000, Paul Durrant wrote:
> > > > Konrad,
> > > >
> > > >   Did you see my previous patch set? The introductory comment
> was:
> > >
> > >
> > > I think that description belongs somewhere permanent, either in
> > > docs/misc or as a comment in an appropriate header.
> > >
> >
> > Good point. Perhaps I should stick the comment just above the
> device description in the dsdt?
> 
> That would do I guess.
> 
> I guess more important would be the user facing toolstack specific
> semantics/documentation i.e. the manpage.
> 
> Ian.
> 

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 11:57:50 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 11:57:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW5GS-0005e5-1z; Thu, 01 Dec 2011 11:57:20 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RW5GQ-0005du-ET
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 11:57:18 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1322740598!6547742!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQzODQ=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5953 invoked from network); 1 Dec 2011 11:56:38 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-14.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 1 Dec 2011 11:56:38 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 01 Dec 2011 11:56:38 +0000
Message-Id: <4ED779840200007800064B2B@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 01 Dec 2011 11:56:36 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartFED16A64.1__="
Cc: Wei Wang2 <wei.wang2@amd.com>
Subject: [Xen-devel] [PATCH] AMD IOMMU v2: minor cleanup
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

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

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

Despite this array living in an __init function, having such be an
automatic variable is rather inefficient in terms of generated code.

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

--- a/xen/drivers/passthrough/amd/iommu_detect.c
+++ b/xen/drivers/passthrough/amd/iommu_detect.c
@@ -66,7 +66,7 @@ void __init get_iommu_features(struct am
 {
     u32 low, high;
     int i =3D 0 ;
-    char * feature_str[] =3D {
+    static const char *__initdata feature_str[] =3D {
         "- Prefetch Pages Command",=20
         "- Peripheral Page Service Request",=20
         "- X2APIC Supported",=20




--=__PartFED16A64.1__=
Content-Type: text/plain; name="amd-iommu-v2-cleanup.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="amd-iommu-v2-cleanup.patch"

AMD IOMMU v2: minor cleanup=0A=0ADespite this array living in an __init =
function, having such be an=0Aautomatic variable is rather inefficient in =
terms of generated code.=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.com=
>=0A=0A--- a/xen/drivers/passthrough/amd/iommu_detect.c=0A+++ b/xen/drivers=
/passthrough/amd/iommu_detect.c=0A@@ -66,7 +66,7 @@ void __init get_iommu_f=
eatures(struct am=0A {=0A     u32 low, high;=0A     int i =3D 0 ;=0A-    =
char * feature_str[] =3D {=0A+    static const char *__initdata feature_str=
[] =3D {=0A         "- Prefetch Pages Command", =0A         "- Peripheral =
Page Service Request", =0A         "- X2APIC Supported", =0A
--=__PartFED16A64.1__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--=__PartFED16A64.1__=--


From xen-devel-bounces@lists.xensource.com Thu Dec 01 11:57:50 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 11:57:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW5GS-0005e5-1z; Thu, 01 Dec 2011 11:57:20 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RW5GQ-0005du-ET
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 11:57:18 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1322740598!6547742!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQzODQ=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5953 invoked from network); 1 Dec 2011 11:56:38 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-14.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 1 Dec 2011 11:56:38 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 01 Dec 2011 11:56:38 +0000
Message-Id: <4ED779840200007800064B2B@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 01 Dec 2011 11:56:36 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartFED16A64.1__="
Cc: Wei Wang2 <wei.wang2@amd.com>
Subject: [Xen-devel] [PATCH] AMD IOMMU v2: minor cleanup
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

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

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

Despite this array living in an __init function, having such be an
automatic variable is rather inefficient in terms of generated code.

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

--- a/xen/drivers/passthrough/amd/iommu_detect.c
+++ b/xen/drivers/passthrough/amd/iommu_detect.c
@@ -66,7 +66,7 @@ void __init get_iommu_features(struct am
 {
     u32 low, high;
     int i =3D 0 ;
-    char * feature_str[] =3D {
+    static const char *__initdata feature_str[] =3D {
         "- Prefetch Pages Command",=20
         "- Peripheral Page Service Request",=20
         "- X2APIC Supported",=20




--=__PartFED16A64.1__=
Content-Type: text/plain; name="amd-iommu-v2-cleanup.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="amd-iommu-v2-cleanup.patch"

AMD IOMMU v2: minor cleanup=0A=0ADespite this array living in an __init =
function, having such be an=0Aautomatic variable is rather inefficient in =
terms of generated code.=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.com=
>=0A=0A--- a/xen/drivers/passthrough/amd/iommu_detect.c=0A+++ b/xen/drivers=
/passthrough/amd/iommu_detect.c=0A@@ -66,7 +66,7 @@ void __init get_iommu_f=
eatures(struct am=0A {=0A     u32 low, high;=0A     int i =3D 0 ;=0A-    =
char * feature_str[] =3D {=0A+    static const char *__initdata feature_str=
[] =3D {=0A         "- Prefetch Pages Command", =0A         "- Peripheral =
Page Service Request", =0A         "- X2APIC Supported", =0A
--=__PartFED16A64.1__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--=__PartFED16A64.1__=--


From xen-devel-bounces@lists.xensource.com Thu Dec 01 12:22:43 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 12:22:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW5ej-00076l-Tx; Thu, 01 Dec 2011 12:22:25 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RW5eh-00075j-Tr
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 12:22:24 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-11.tower-182.messagelabs.com!1322742103!5441989!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMzM1OTc=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMzM1OTc=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3535 invoked from network); 1 Dec 2011 12:21:43 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-11.tower-182.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 1 Dec 2011 12:21:43 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1322742102; l=12024;
	s=domk; d=aepfle.de;
	h=To:From:Date:References:In-Reply-To:Subject:
	Content-Transfer-Encoding:MIME-Version:Content-Type:X-RZG-CLASS-ID:
	X-RZG-AUTH; bh=tk+w71d4W2adLA1YyvOXmg1NkKM=;
	b=s4O1ZhkHfzvn9Gdr4wybFL+fG/YryIMOwsZNva0NpLgjmXXd/qB0LITjfISvAbNMxKk
	kq2H48yxKw4Tl+VQBo5mgtHEndBwYUPSBUxQ3hDKK+YGKwQZmui0SNePHPrgED754F6Dk
	s3cPClruZpinNM65RAIie8+UxkbyopBuiPo=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/ll2c7pE6jG
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-080-213.pools.arcor-ip.net [84.57.80.213])
	by smtp.strato.de (fruni mo31) (RZmta 26.10 AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id e0628cnB1Bq1Zk
	for <xen-devel@lists.xensource.com>;
	Thu, 1 Dec 2011 13:21:28 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 3D8791863A
	for <xen-devel@lists.xensource.com>;
	Thu,  1 Dec 2011 13:21:27 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 0bf827a48a3c9efd43fe04c291b553d2bec46f8b
Message-Id: <0bf827a48a3c9efd43fe.1322737760@probook.site>
In-Reply-To: <patchbomb.1322737756@probook.site>
References: <patchbomb.1322737756@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Thu, 01 Dec 2011 12:09:20 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 4 of 4] Add tracing to mem_event and
	p2m_mem_paging functions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1322737677 -3600
# Node ID 0bf827a48a3c9efd43fe04c291b553d2bec46f8b
# Parent  c09ac3717a025a8ead44bbc795fedda715d134c7
Add tracing to mem_event and p2m_mem_paging functions

Maintaining these trace_var calls out-of-tree became a burden and made
debugging paging related issues harder. So putting it into the tree will
ease debugging with xenalyze.

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r c09ac3717a02 -r 0bf827a48a3c xen/arch/x86/mm/mem_event.c
--- a/xen/arch/x86/mm/mem_event.c
+++ b/xen/arch/x86/mm/mem_event.c
@@ -24,6 +24,7 @@
 #include <asm/domain.h>
 #include <xen/event.h>
 #include <xen/wait.h>
+#include <xen/trace.h>
 #include <asm/p2m.h>
 #include <asm/mem_event.h>
 #include <asm/mem_paging.h>
@@ -149,6 +150,13 @@ static int _mem_event_put_request(struct
     mem_event_front_ring_t *front_ring;
     int free_requests;
     RING_IDX req_prod;
+    struct trc_mem_event_put_request T = { .td = d->domain_id };
+    int ret = 0;
+
+    T.d = current->domain->domain_id;
+    T.v = current->vcpu_id;
+    T.ring_bit = med->bit;
+    T.gfn = req->gfn;
 
     mem_event_ring_lock(med);
 
@@ -156,7 +164,7 @@ static int _mem_event_put_request(struct
     /* Requests from foreign domain were claimed in mem_event_check_ring() */
     if ((current->domain == d && free_requests < med->foreign_producers) || !free_requests) {
         mem_event_ring_unlock(med);
-        return 0;
+        goto out;
     }
 
     front_ring = &med->front_ring;
@@ -176,7 +184,15 @@ static int _mem_event_put_request(struct
 
     notify_via_xen_event_channel(d, med->xen_port);
 
-    return 1;
+    ret = 1;
+
+out:
+    T.ret = ret;
+    T.room = free_requests;
+    T.foreign_producers = med->foreign_producers + ret;
+    trace_var(TRC_MEM_EVENT_PUT_REQUEST, 1, sizeof(T), &T);
+
+    return ret;
 }
 
 void mem_event_put_request(struct domain *d, struct mem_event_domain *med,
diff -r c09ac3717a02 -r 0bf827a48a3c xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -31,6 +31,7 @@
 #include <asm/hvm/vmx/vmx.h> /* ept_p2m_init() */
 #include <xen/iommu.h>
 #include <xen/wait.h>
+#include <xen/trace.h>
 #include <asm/mem_event.h>
 #include <public/mem_event.h>
 #include <asm/mem_sharing.h>
@@ -215,7 +216,12 @@ static struct p2m_mem_paging_queue *p2m_
 {
     struct p2m_mem_paging_queue_head *h;
     struct p2m_mem_paging_queue *q, *q_match, *q_free;
+    struct trc_mem_p2m_paging_queue T = { .td = d->domain_id };
     
+    T.d = current->domain->domain_id;
+    T.v = current->vcpu_id;
+    T.gfn = gfn;
+
     h = d->arch.hvm_domain.gfn_queue;
     q_match = q_free = NULL;
 
@@ -238,19 +244,37 @@ static struct p2m_mem_paging_queue *p2m_
             printk("wq woken for gfn %u:%u %lx %u %u %u\n", current->domain->domain_id, current->vcpu_id, gfn, q_match->index, q_match->woken, q_match->waiters);
         q_match->waiters++;
         q_match->gfn = gfn;
+
+        T.waiters = q_match->waiters;
+        T.woken = q_match->woken;
+        T.index = q_match->index;
     }
 
+    trace_var(TRC_MEM_P2M_PAGING_GET_QUEUE, 1, sizeof(T), &T);
+
     if (!q_match)
         printk("No wq_get for gfn %u:%u %lx\n", current->domain->domain_id, current->vcpu_id, gfn);
 
+
     spin_unlock(&d->arch.hvm_domain.gfn_lock);
     return q_match;
 }
 
 static void p2m_mem_paging_put_queue(struct domain *d, struct p2m_mem_paging_queue *q_match)
 {
+    struct trc_mem_p2m_paging_queue T = { .td = d->domain_id };
+
+    T.d = current->domain->domain_id;
+    T.v = current->vcpu_id;
+    T.gfn = q_match->gfn;
+    T.waiters = q_match->waiters;
+    T.woken = q_match->woken;
+    T.index = q_match->index;
+
     spin_lock(&d->arch.hvm_domain.gfn_lock);
 
+    trace_var(TRC_MEM_P2M_PAGING_PUT_QUEUE, 1, sizeof(T), &T);
+
     if (q_match->waiters == 0)
         printk("wq_put no waiters, gfn %u:%u %lx %u\n", current->domain->domain_id, current->vcpu_id, q_match->gfn, q_match->woken);
     else if (--q_match->waiters == 0)
@@ -263,6 +287,11 @@ static void p2m_mem_paging_wake_queue(st
 {
     struct p2m_mem_paging_queue_head *h;
     struct p2m_mem_paging_queue *q, *q_match = NULL;
+    struct trc_mem_p2m_paging_queue T = { .td = d->domain_id };
+
+    T.d = current->domain->domain_id;
+    T.v = current->vcpu_id;
+    T.gfn = gfn;
 
     spin_lock(&d->arch.hvm_domain.gfn_lock);
 
@@ -277,8 +306,15 @@ static void p2m_mem_paging_wake_queue(st
         if (q_match->woken || q_match->waiters == 0)
             printk("Wrong wake for gfn %u:%u %p %lx %u %u\n", current->domain->domain_id, current->vcpu_id, q_match, gfn, q_match->woken, q_match->waiters);
         q_match->woken++;
+
+        T.waiters = q_match->waiters;
+        T.woken = q_match->woken;
+        T.index = q_match->index;
+
         wake_up_all(&q_match->wq);
     }
+    trace_var(TRC_MEM_P2M_PAGING_WAKE_QUEUE, 1, sizeof(T), &T);
+
     spin_unlock(&d->arch.hvm_domain.gfn_lock);
 }
 
@@ -937,34 +973,45 @@ int p2m_mem_paging_nominate(struct domai
     p2m_access_t a;
     mfn_t mfn;
     int ret;
+    struct trc_mem_p2m_paging T = { .td = d->domain_id };
+
+    T.d = current->domain->domain_id;
+    T.v = current->vcpu_id;
+    T.gfn = gfn;
 
     p2m_lock(p2m);
 
     mfn = p2m->get_entry(p2m, gfn, &p2mt, &a, p2m_query, NULL);
 
+    T.reason++;
     /* Check if mfn is valid */
     ret = -EINVAL;
     if ( !mfn_valid(mfn) )
         goto out;
 
+    T.reason++;
     /* Check p2m type */
     ret = -EAGAIN;
     if ( !p2m_is_pageable(p2mt) )
         goto out;
 
+    T.reason++;
     /* Check for io memory page */
     if ( is_iomem_page(mfn_x(mfn)) )
         goto out;
 
+    T.reason++;
     /* Check page count and type */
     page = mfn_to_page(mfn);
     if ( (page->count_info & (PGC_count_mask | PGC_allocated)) !=
          (1 | PGC_allocated) )
         goto out;
 
+    T.reason++;
     if ( (page->u.inuse.type_info & PGT_type_mask) != PGT_none )
         goto out;
 
+    T.reason++;
     /* Fix p2m entry */
     set_p2m_entry(p2m, gfn, mfn, PAGE_ORDER_4K, p2m_ram_paging_out, a);
     audit_p2m(p2m, 1);
@@ -972,6 +1019,10 @@ int p2m_mem_paging_nominate(struct domai
 
  out:
     p2m_unlock(p2m);
+
+    T.mfn = mfn_x(mfn);
+    T.p2mt = p2mt;
+    trace_var(TRC_MEM_P2M_PAGING_NOMINATE, 1, sizeof(T), &T);
     return ret;
 }
 
@@ -1002,6 +1053,11 @@ int p2m_mem_paging_evict(struct domain *
     mfn_t mfn;
     struct p2m_domain *p2m = p2m_get_hostp2m(d);
     int ret = -EINVAL;
+    struct trc_mem_p2m_paging T = { .td = d->domain_id };
+
+    T.d = current->domain->domain_id;
+    T.v = current->vcpu_id;
+    T.gfn = gfn;
 
     p2m_lock(p2m);
 
@@ -1010,24 +1066,29 @@ int p2m_mem_paging_evict(struct domain *
     if ( unlikely(!mfn_valid(mfn)) )
         goto out;
 
+    T.reason++;
     /* Allow only nominated pages */
     if ( p2mt != p2m_ram_paging_out )
         goto out;
 
+    T.reason++;
     ret = -EBUSY;
     /* Get the page so it doesn't get modified under Xen's feet */
     page = mfn_to_page(mfn);
     if ( unlikely(!get_page(page, d)) )
         goto out;
 
+    T.reason++;
     /* Check page count and type once more */
     if ( (page->count_info & (PGC_count_mask | PGC_allocated)) !=
          (2 | PGC_allocated) )
         goto out_put;
 
+    T.reason++;
     if ( (page->u.inuse.type_info & PGT_type_mask) != PGT_none )
         goto out_put;
 
+    T.reason++;
     /* Decrement guest domain's ref count of the page */
     if ( test_and_clear_bit(_PGC_allocated, &page->count_info) )
         put_page(page);
@@ -1050,6 +1111,12 @@ int p2m_mem_paging_evict(struct domain *
 
  out:
     p2m_unlock(p2m);
+
+    T.flag_evict_fail = !!ret;
+    T.mfn = mfn_x(mfn);
+    T.p2mt = p2mt;
+    trace_var(TRC_MEM_P2M_PAGING_EVICT, 1, sizeof(T), &T);
+
     return ret;
 }
 
@@ -1065,10 +1132,16 @@ int p2m_mem_paging_evict(struct domain *
 void p2m_mem_paging_drop_page(struct domain *d, unsigned long gfn)
 {
     mem_event_request_t req = { .type = MEM_EVENT_TYPE_PAGING, .gfn = gfn };
+    struct trc_mem_p2m_paging T = { .td = d->domain_id };
 
     /* Send release notification to pager */
     req.flags = MEM_EVENT_FLAG_DROP_PAGE;
 
+    T.d = current->domain->domain_id;
+    T.v = current->vcpu_id;
+    T.gfn = gfn;
+    trace_var(TRC_MEM_P2M_PAGING_DROP, 1, sizeof(T), &T);
+
     mem_event_put_request(d, &d->mem_event->paging, &req);
 }
 
@@ -1101,11 +1174,13 @@ void p2m_mem_paging_populate(struct doma
     p2m_access_t a;
     mfn_t mfn;
     struct p2m_domain *p2m = p2m_get_hostp2m(d);
-    int put_request = 0;
+    int put_request = 0, ring_full;
+    struct trc_mem_p2m_paging T = { .td = d->domain_id };
 
     /* Check that there's space on the ring for this request */
-    if ( mem_event_check_ring(d, &d->mem_event->paging) )
-        return;
+    ring_full = mem_event_check_ring(d, &d->mem_event->paging);
+    if ( ring_full )
+        goto trace;
 
     /* Fix p2m mapping */
     p2m_lock(p2m);
@@ -1127,11 +1202,24 @@ void p2m_mem_paging_populate(struct doma
     }
     p2m_unlock(p2m);
 
-    /* One request per gfn, guest vcpus go to sleep, foreigners try again */
-    if ( put_request )
-        mem_event_put_request(d, &d->mem_event->paging, &req);
-    else
-        mem_event_put_req_producers(d, &d->mem_event->paging);
+    T.mfn = mfn_x(mfn);
+    T.p2mt = p2mt;
+
+trace:
+    T.d = current->domain->domain_id;
+    T.v = current->vcpu_id;
+    T.gfn = gfn;
+    T.reason = ring_full;
+    T.flag_drop_page = put_request;
+    trace_var(TRC_MEM_P2M_PAGING_POPULATE, 1, sizeof(T), &T);
+
+    if ( !ring_full ) {
+        /* One request per gfn, guest vcpus go to sleep, foreigners try again */
+        if ( put_request )
+            mem_event_put_request(d, &d->mem_event->paging, &req);
+        else
+            mem_event_put_req_producers(d, &d->mem_event->paging);
+    }
 }
 
 /**
@@ -1153,6 +1241,7 @@ int p2m_mem_paging_prep(struct domain *d
     mfn_t mfn;
     struct p2m_domain *p2m = p2m_get_hostp2m(d);
     int ret;
+    struct trc_mem_p2m_paging T = { .td = d->domain_id };
 
     p2m_lock(p2m);
 
@@ -1184,6 +1273,15 @@ int p2m_mem_paging_prep(struct domain *d
 
  out:
     p2m_unlock(p2m);
+
+    T.d = current->domain->domain_id;
+    T.v = current->vcpu_id;
+    T.gfn = gfn;
+    T.mfn = mfn_x(mfn);
+    T.p2mt = p2mt;
+    T.reason = ret;
+    trace_var(TRC_MEM_P2M_PAGING_PREP, 1, sizeof(T), &T);
+
     return ret;
 }
 
@@ -1209,6 +1307,7 @@ void p2m_mem_paging_resume(struct domain
     p2m_type_t p2mt;
     p2m_access_t a;
     mfn_t mfn;
+    struct trc_mem_p2m_paging T = { .td = d->domain_id };
 
     /* Pull the response off the ring */
     mem_event_get_response(&d->mem_event->paging, &rsp);
@@ -1230,8 +1329,16 @@ void p2m_mem_paging_resume(struct domain
             audit_p2m(p2m, 1);
         }
         p2m_unlock(p2m);
+        T.mfn = mfn_x(mfn);
+        T.p2mt = p2mt;
     }
 
+    T.d = current->domain->domain_id;
+    T.v = current->vcpu_id;
+    T.gfn = rsp.gfn;
+    T.flag_drop_page = !!(rsp.flags & MEM_EVENT_FLAG_DROP_PAGE);
+    trace_var(TRC_MEM_P2M_PAGING_RESUME, 1, sizeof(T), &T);
+
     /* Wake vcpus waiting for room in the ring */
     mem_event_wake_requesters(&d->mem_event->paging);
 
diff -r c09ac3717a02 -r 0bf827a48a3c xen/include/public/trace.h
--- a/xen/include/public/trace.h
+++ b/xen/include/public/trace.h
@@ -94,6 +94,37 @@
 #define TRC_MEM_POD_ZERO_RECLAIM    (TRC_MEM + 17)
 #define TRC_MEM_POD_SUPERPAGE_SPLINTER (TRC_MEM + 18)
 
+#define TRC_MEM_EVENT_PUT_REQUEST      (TRC_MEM + 19)
+struct trc_mem_event_put_request {
+    unsigned int d:16, v:16;
+    unsigned int td:16, room:16;
+    unsigned int gfn;
+    unsigned int foreign_producers:16, ret:1, ring_bit:5;
+} __attribute__((packed));
+
+#define TRC_MEM_P2M_PAGING_NOMINATE    (TRC_MEM + 20)
+#define TRC_MEM_P2M_PAGING_EVICT       (TRC_MEM + 21)
+#define TRC_MEM_P2M_PAGING_DROP        (TRC_MEM + 22)
+#define TRC_MEM_P2M_PAGING_POPULATE    (TRC_MEM + 23)
+#define TRC_MEM_P2M_PAGING_PREP        (TRC_MEM + 24)
+#define TRC_MEM_P2M_PAGING_RESUME      (TRC_MEM + 25)
+struct trc_mem_p2m_paging {
+    unsigned int d:16, v:16;
+    unsigned int td:16, p2mt:5, reason:5, flag_evict_fail:1, flag_drop_page:1;
+    unsigned int gfn;
+    unsigned int mfn;
+} __attribute__((packed));
+
+#define TRC_MEM_P2M_PAGING_GET_QUEUE   (TRC_MEM + 26)
+#define TRC_MEM_P2M_PAGING_PUT_QUEUE   (TRC_MEM + 27)
+#define TRC_MEM_P2M_PAGING_WAKE_QUEUE  (TRC_MEM + 28)
+struct trc_mem_p2m_paging_queue {
+    unsigned int d:16, v:16;
+    unsigned int td:16, woken:8;
+    unsigned int gfn;
+    unsigned int index:16, waiters:16;
+} __attribute__((packed));
+
 
 #define TRC_PV_HYPERCALL             (TRC_PV +  1)
 #define TRC_PV_TRAP                  (TRC_PV +  3)

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 12:22:43 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 12:22:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW5ej-00076l-Tx; Thu, 01 Dec 2011 12:22:25 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RW5eh-00075j-Tr
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 12:22:24 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-11.tower-182.messagelabs.com!1322742103!5441989!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMzM1OTc=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMzM1OTc=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3535 invoked from network); 1 Dec 2011 12:21:43 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-11.tower-182.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 1 Dec 2011 12:21:43 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1322742102; l=12024;
	s=domk; d=aepfle.de;
	h=To:From:Date:References:In-Reply-To:Subject:
	Content-Transfer-Encoding:MIME-Version:Content-Type:X-RZG-CLASS-ID:
	X-RZG-AUTH; bh=tk+w71d4W2adLA1YyvOXmg1NkKM=;
	b=s4O1ZhkHfzvn9Gdr4wybFL+fG/YryIMOwsZNva0NpLgjmXXd/qB0LITjfISvAbNMxKk
	kq2H48yxKw4Tl+VQBo5mgtHEndBwYUPSBUxQ3hDKK+YGKwQZmui0SNePHPrgED754F6Dk
	s3cPClruZpinNM65RAIie8+UxkbyopBuiPo=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/ll2c7pE6jG
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-080-213.pools.arcor-ip.net [84.57.80.213])
	by smtp.strato.de (fruni mo31) (RZmta 26.10 AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id e0628cnB1Bq1Zk
	for <xen-devel@lists.xensource.com>;
	Thu, 1 Dec 2011 13:21:28 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 3D8791863A
	for <xen-devel@lists.xensource.com>;
	Thu,  1 Dec 2011 13:21:27 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 0bf827a48a3c9efd43fe04c291b553d2bec46f8b
Message-Id: <0bf827a48a3c9efd43fe.1322737760@probook.site>
In-Reply-To: <patchbomb.1322737756@probook.site>
References: <patchbomb.1322737756@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Thu, 01 Dec 2011 12:09:20 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 4 of 4] Add tracing to mem_event and
	p2m_mem_paging functions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1322737677 -3600
# Node ID 0bf827a48a3c9efd43fe04c291b553d2bec46f8b
# Parent  c09ac3717a025a8ead44bbc795fedda715d134c7
Add tracing to mem_event and p2m_mem_paging functions

Maintaining these trace_var calls out-of-tree became a burden and made
debugging paging related issues harder. So putting it into the tree will
ease debugging with xenalyze.

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r c09ac3717a02 -r 0bf827a48a3c xen/arch/x86/mm/mem_event.c
--- a/xen/arch/x86/mm/mem_event.c
+++ b/xen/arch/x86/mm/mem_event.c
@@ -24,6 +24,7 @@
 #include <asm/domain.h>
 #include <xen/event.h>
 #include <xen/wait.h>
+#include <xen/trace.h>
 #include <asm/p2m.h>
 #include <asm/mem_event.h>
 #include <asm/mem_paging.h>
@@ -149,6 +150,13 @@ static int _mem_event_put_request(struct
     mem_event_front_ring_t *front_ring;
     int free_requests;
     RING_IDX req_prod;
+    struct trc_mem_event_put_request T = { .td = d->domain_id };
+    int ret = 0;
+
+    T.d = current->domain->domain_id;
+    T.v = current->vcpu_id;
+    T.ring_bit = med->bit;
+    T.gfn = req->gfn;
 
     mem_event_ring_lock(med);
 
@@ -156,7 +164,7 @@ static int _mem_event_put_request(struct
     /* Requests from foreign domain were claimed in mem_event_check_ring() */
     if ((current->domain == d && free_requests < med->foreign_producers) || !free_requests) {
         mem_event_ring_unlock(med);
-        return 0;
+        goto out;
     }
 
     front_ring = &med->front_ring;
@@ -176,7 +184,15 @@ static int _mem_event_put_request(struct
 
     notify_via_xen_event_channel(d, med->xen_port);
 
-    return 1;
+    ret = 1;
+
+out:
+    T.ret = ret;
+    T.room = free_requests;
+    T.foreign_producers = med->foreign_producers + ret;
+    trace_var(TRC_MEM_EVENT_PUT_REQUEST, 1, sizeof(T), &T);
+
+    return ret;
 }
 
 void mem_event_put_request(struct domain *d, struct mem_event_domain *med,
diff -r c09ac3717a02 -r 0bf827a48a3c xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -31,6 +31,7 @@
 #include <asm/hvm/vmx/vmx.h> /* ept_p2m_init() */
 #include <xen/iommu.h>
 #include <xen/wait.h>
+#include <xen/trace.h>
 #include <asm/mem_event.h>
 #include <public/mem_event.h>
 #include <asm/mem_sharing.h>
@@ -215,7 +216,12 @@ static struct p2m_mem_paging_queue *p2m_
 {
     struct p2m_mem_paging_queue_head *h;
     struct p2m_mem_paging_queue *q, *q_match, *q_free;
+    struct trc_mem_p2m_paging_queue T = { .td = d->domain_id };
     
+    T.d = current->domain->domain_id;
+    T.v = current->vcpu_id;
+    T.gfn = gfn;
+
     h = d->arch.hvm_domain.gfn_queue;
     q_match = q_free = NULL;
 
@@ -238,19 +244,37 @@ static struct p2m_mem_paging_queue *p2m_
             printk("wq woken for gfn %u:%u %lx %u %u %u\n", current->domain->domain_id, current->vcpu_id, gfn, q_match->index, q_match->woken, q_match->waiters);
         q_match->waiters++;
         q_match->gfn = gfn;
+
+        T.waiters = q_match->waiters;
+        T.woken = q_match->woken;
+        T.index = q_match->index;
     }
 
+    trace_var(TRC_MEM_P2M_PAGING_GET_QUEUE, 1, sizeof(T), &T);
+
     if (!q_match)
         printk("No wq_get for gfn %u:%u %lx\n", current->domain->domain_id, current->vcpu_id, gfn);
 
+
     spin_unlock(&d->arch.hvm_domain.gfn_lock);
     return q_match;
 }
 
 static void p2m_mem_paging_put_queue(struct domain *d, struct p2m_mem_paging_queue *q_match)
 {
+    struct trc_mem_p2m_paging_queue T = { .td = d->domain_id };
+
+    T.d = current->domain->domain_id;
+    T.v = current->vcpu_id;
+    T.gfn = q_match->gfn;
+    T.waiters = q_match->waiters;
+    T.woken = q_match->woken;
+    T.index = q_match->index;
+
     spin_lock(&d->arch.hvm_domain.gfn_lock);
 
+    trace_var(TRC_MEM_P2M_PAGING_PUT_QUEUE, 1, sizeof(T), &T);
+
     if (q_match->waiters == 0)
         printk("wq_put no waiters, gfn %u:%u %lx %u\n", current->domain->domain_id, current->vcpu_id, q_match->gfn, q_match->woken);
     else if (--q_match->waiters == 0)
@@ -263,6 +287,11 @@ static void p2m_mem_paging_wake_queue(st
 {
     struct p2m_mem_paging_queue_head *h;
     struct p2m_mem_paging_queue *q, *q_match = NULL;
+    struct trc_mem_p2m_paging_queue T = { .td = d->domain_id };
+
+    T.d = current->domain->domain_id;
+    T.v = current->vcpu_id;
+    T.gfn = gfn;
 
     spin_lock(&d->arch.hvm_domain.gfn_lock);
 
@@ -277,8 +306,15 @@ static void p2m_mem_paging_wake_queue(st
         if (q_match->woken || q_match->waiters == 0)
             printk("Wrong wake for gfn %u:%u %p %lx %u %u\n", current->domain->domain_id, current->vcpu_id, q_match, gfn, q_match->woken, q_match->waiters);
         q_match->woken++;
+
+        T.waiters = q_match->waiters;
+        T.woken = q_match->woken;
+        T.index = q_match->index;
+
         wake_up_all(&q_match->wq);
     }
+    trace_var(TRC_MEM_P2M_PAGING_WAKE_QUEUE, 1, sizeof(T), &T);
+
     spin_unlock(&d->arch.hvm_domain.gfn_lock);
 }
 
@@ -937,34 +973,45 @@ int p2m_mem_paging_nominate(struct domai
     p2m_access_t a;
     mfn_t mfn;
     int ret;
+    struct trc_mem_p2m_paging T = { .td = d->domain_id };
+
+    T.d = current->domain->domain_id;
+    T.v = current->vcpu_id;
+    T.gfn = gfn;
 
     p2m_lock(p2m);
 
     mfn = p2m->get_entry(p2m, gfn, &p2mt, &a, p2m_query, NULL);
 
+    T.reason++;
     /* Check if mfn is valid */
     ret = -EINVAL;
     if ( !mfn_valid(mfn) )
         goto out;
 
+    T.reason++;
     /* Check p2m type */
     ret = -EAGAIN;
     if ( !p2m_is_pageable(p2mt) )
         goto out;
 
+    T.reason++;
     /* Check for io memory page */
     if ( is_iomem_page(mfn_x(mfn)) )
         goto out;
 
+    T.reason++;
     /* Check page count and type */
     page = mfn_to_page(mfn);
     if ( (page->count_info & (PGC_count_mask | PGC_allocated)) !=
          (1 | PGC_allocated) )
         goto out;
 
+    T.reason++;
     if ( (page->u.inuse.type_info & PGT_type_mask) != PGT_none )
         goto out;
 
+    T.reason++;
     /* Fix p2m entry */
     set_p2m_entry(p2m, gfn, mfn, PAGE_ORDER_4K, p2m_ram_paging_out, a);
     audit_p2m(p2m, 1);
@@ -972,6 +1019,10 @@ int p2m_mem_paging_nominate(struct domai
 
  out:
     p2m_unlock(p2m);
+
+    T.mfn = mfn_x(mfn);
+    T.p2mt = p2mt;
+    trace_var(TRC_MEM_P2M_PAGING_NOMINATE, 1, sizeof(T), &T);
     return ret;
 }
 
@@ -1002,6 +1053,11 @@ int p2m_mem_paging_evict(struct domain *
     mfn_t mfn;
     struct p2m_domain *p2m = p2m_get_hostp2m(d);
     int ret = -EINVAL;
+    struct trc_mem_p2m_paging T = { .td = d->domain_id };
+
+    T.d = current->domain->domain_id;
+    T.v = current->vcpu_id;
+    T.gfn = gfn;
 
     p2m_lock(p2m);
 
@@ -1010,24 +1066,29 @@ int p2m_mem_paging_evict(struct domain *
     if ( unlikely(!mfn_valid(mfn)) )
         goto out;
 
+    T.reason++;
     /* Allow only nominated pages */
     if ( p2mt != p2m_ram_paging_out )
         goto out;
 
+    T.reason++;
     ret = -EBUSY;
     /* Get the page so it doesn't get modified under Xen's feet */
     page = mfn_to_page(mfn);
     if ( unlikely(!get_page(page, d)) )
         goto out;
 
+    T.reason++;
     /* Check page count and type once more */
     if ( (page->count_info & (PGC_count_mask | PGC_allocated)) !=
          (2 | PGC_allocated) )
         goto out_put;
 
+    T.reason++;
     if ( (page->u.inuse.type_info & PGT_type_mask) != PGT_none )
         goto out_put;
 
+    T.reason++;
     /* Decrement guest domain's ref count of the page */
     if ( test_and_clear_bit(_PGC_allocated, &page->count_info) )
         put_page(page);
@@ -1050,6 +1111,12 @@ int p2m_mem_paging_evict(struct domain *
 
  out:
     p2m_unlock(p2m);
+
+    T.flag_evict_fail = !!ret;
+    T.mfn = mfn_x(mfn);
+    T.p2mt = p2mt;
+    trace_var(TRC_MEM_P2M_PAGING_EVICT, 1, sizeof(T), &T);
+
     return ret;
 }
 
@@ -1065,10 +1132,16 @@ int p2m_mem_paging_evict(struct domain *
 void p2m_mem_paging_drop_page(struct domain *d, unsigned long gfn)
 {
     mem_event_request_t req = { .type = MEM_EVENT_TYPE_PAGING, .gfn = gfn };
+    struct trc_mem_p2m_paging T = { .td = d->domain_id };
 
     /* Send release notification to pager */
     req.flags = MEM_EVENT_FLAG_DROP_PAGE;
 
+    T.d = current->domain->domain_id;
+    T.v = current->vcpu_id;
+    T.gfn = gfn;
+    trace_var(TRC_MEM_P2M_PAGING_DROP, 1, sizeof(T), &T);
+
     mem_event_put_request(d, &d->mem_event->paging, &req);
 }
 
@@ -1101,11 +1174,13 @@ void p2m_mem_paging_populate(struct doma
     p2m_access_t a;
     mfn_t mfn;
     struct p2m_domain *p2m = p2m_get_hostp2m(d);
-    int put_request = 0;
+    int put_request = 0, ring_full;
+    struct trc_mem_p2m_paging T = { .td = d->domain_id };
 
     /* Check that there's space on the ring for this request */
-    if ( mem_event_check_ring(d, &d->mem_event->paging) )
-        return;
+    ring_full = mem_event_check_ring(d, &d->mem_event->paging);
+    if ( ring_full )
+        goto trace;
 
     /* Fix p2m mapping */
     p2m_lock(p2m);
@@ -1127,11 +1202,24 @@ void p2m_mem_paging_populate(struct doma
     }
     p2m_unlock(p2m);
 
-    /* One request per gfn, guest vcpus go to sleep, foreigners try again */
-    if ( put_request )
-        mem_event_put_request(d, &d->mem_event->paging, &req);
-    else
-        mem_event_put_req_producers(d, &d->mem_event->paging);
+    T.mfn = mfn_x(mfn);
+    T.p2mt = p2mt;
+
+trace:
+    T.d = current->domain->domain_id;
+    T.v = current->vcpu_id;
+    T.gfn = gfn;
+    T.reason = ring_full;
+    T.flag_drop_page = put_request;
+    trace_var(TRC_MEM_P2M_PAGING_POPULATE, 1, sizeof(T), &T);
+
+    if ( !ring_full ) {
+        /* One request per gfn, guest vcpus go to sleep, foreigners try again */
+        if ( put_request )
+            mem_event_put_request(d, &d->mem_event->paging, &req);
+        else
+            mem_event_put_req_producers(d, &d->mem_event->paging);
+    }
 }
 
 /**
@@ -1153,6 +1241,7 @@ int p2m_mem_paging_prep(struct domain *d
     mfn_t mfn;
     struct p2m_domain *p2m = p2m_get_hostp2m(d);
     int ret;
+    struct trc_mem_p2m_paging T = { .td = d->domain_id };
 
     p2m_lock(p2m);
 
@@ -1184,6 +1273,15 @@ int p2m_mem_paging_prep(struct domain *d
 
  out:
     p2m_unlock(p2m);
+
+    T.d = current->domain->domain_id;
+    T.v = current->vcpu_id;
+    T.gfn = gfn;
+    T.mfn = mfn_x(mfn);
+    T.p2mt = p2mt;
+    T.reason = ret;
+    trace_var(TRC_MEM_P2M_PAGING_PREP, 1, sizeof(T), &T);
+
     return ret;
 }
 
@@ -1209,6 +1307,7 @@ void p2m_mem_paging_resume(struct domain
     p2m_type_t p2mt;
     p2m_access_t a;
     mfn_t mfn;
+    struct trc_mem_p2m_paging T = { .td = d->domain_id };
 
     /* Pull the response off the ring */
     mem_event_get_response(&d->mem_event->paging, &rsp);
@@ -1230,8 +1329,16 @@ void p2m_mem_paging_resume(struct domain
             audit_p2m(p2m, 1);
         }
         p2m_unlock(p2m);
+        T.mfn = mfn_x(mfn);
+        T.p2mt = p2mt;
     }
 
+    T.d = current->domain->domain_id;
+    T.v = current->vcpu_id;
+    T.gfn = rsp.gfn;
+    T.flag_drop_page = !!(rsp.flags & MEM_EVENT_FLAG_DROP_PAGE);
+    trace_var(TRC_MEM_P2M_PAGING_RESUME, 1, sizeof(T), &T);
+
     /* Wake vcpus waiting for room in the ring */
     mem_event_wake_requesters(&d->mem_event->paging);
 
diff -r c09ac3717a02 -r 0bf827a48a3c xen/include/public/trace.h
--- a/xen/include/public/trace.h
+++ b/xen/include/public/trace.h
@@ -94,6 +94,37 @@
 #define TRC_MEM_POD_ZERO_RECLAIM    (TRC_MEM + 17)
 #define TRC_MEM_POD_SUPERPAGE_SPLINTER (TRC_MEM + 18)
 
+#define TRC_MEM_EVENT_PUT_REQUEST      (TRC_MEM + 19)
+struct trc_mem_event_put_request {
+    unsigned int d:16, v:16;
+    unsigned int td:16, room:16;
+    unsigned int gfn;
+    unsigned int foreign_producers:16, ret:1, ring_bit:5;
+} __attribute__((packed));
+
+#define TRC_MEM_P2M_PAGING_NOMINATE    (TRC_MEM + 20)
+#define TRC_MEM_P2M_PAGING_EVICT       (TRC_MEM + 21)
+#define TRC_MEM_P2M_PAGING_DROP        (TRC_MEM + 22)
+#define TRC_MEM_P2M_PAGING_POPULATE    (TRC_MEM + 23)
+#define TRC_MEM_P2M_PAGING_PREP        (TRC_MEM + 24)
+#define TRC_MEM_P2M_PAGING_RESUME      (TRC_MEM + 25)
+struct trc_mem_p2m_paging {
+    unsigned int d:16, v:16;
+    unsigned int td:16, p2mt:5, reason:5, flag_evict_fail:1, flag_drop_page:1;
+    unsigned int gfn;
+    unsigned int mfn;
+} __attribute__((packed));
+
+#define TRC_MEM_P2M_PAGING_GET_QUEUE   (TRC_MEM + 26)
+#define TRC_MEM_P2M_PAGING_PUT_QUEUE   (TRC_MEM + 27)
+#define TRC_MEM_P2M_PAGING_WAKE_QUEUE  (TRC_MEM + 28)
+struct trc_mem_p2m_paging_queue {
+    unsigned int d:16, v:16;
+    unsigned int td:16, woken:8;
+    unsigned int gfn;
+    unsigned int index:16, waiters:16;
+} __attribute__((packed));
+
 
 #define TRC_PV_HYPERCALL             (TRC_PV +  1)
 #define TRC_PV_TRAP                  (TRC_PV +  3)

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 12:22:43 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 12:22:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW5ej-00076O-BP; Thu, 01 Dec 2011 12:22:25 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RW5eh-00075x-AY
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 12:22:23 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-13.tower-27.messagelabs.com!1322742087!50486224!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMzM1OTc=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMzM1OTc=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2355 invoked from network); 1 Dec 2011 12:21:28 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-13.tower-27.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 1 Dec 2011 12:21:28 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1322742108; l=893;
	s=domk; d=aepfle.de;
	h=To:From:Date:Subject:Content-Transfer-Encoding:MIME-Version:
	Content-Type:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=hCqSWba1kfPvyIW7Zx541piEJTQ=;
	b=AAzh8M1BY79lpJwlae6H4JX9/LgW+A1ReQKMQTILnkMcfhwatb6XVbZnwmHzYgOxxI6
	DjKFpyBzQWRa8Vptp7OT3bzcZFrX26m5fxYXaVZCiDMIPFz8hGgOzn+HhtD5/6hpQoar5
	1CbSIAlpIGJLZATUnl0sdxlK+e3kSTIlh54=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/ll2c7pE6jG
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-080-213.pools.arcor-ip.net [84.57.80.213])
	by smtp.strato.de (fruni mo40) (RZmta 26.10 AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id L06952nB1AoCTa
	for <xen-devel@lists.xensource.com>;
	Thu, 1 Dec 2011 13:21:27 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 7D33618636
	for <xen-devel@lists.xensource.com>;
	Thu,  1 Dec 2011 13:21:26 +0100 (CET)
MIME-Version: 1.0
Message-Id: <patchbomb.1322737756@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Thu, 01 Dec 2011 12:09:16 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 0 of 4] RFC: wait queue usage
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


The following series is my current state of an attempt to use wait queues for
xenpaging and mem_event handling. I post it here for review and comments.

This series conflicts with work from Andres Lagar-Cavilla.


Olaf


 xen/arch/x86/hvm/emulate.c       |    3 
 xen/arch/x86/hvm/hvm.c           |   21 +-
 xen/arch/x86/mm.c                |   49 +----
 xen/arch/x86/mm/guest_walk.c     |    3 
 xen/arch/x86/mm/hap/guest_walk.c |    6 
 xen/arch/x86/mm/mem_event.c      |  150 +++++++++++++--
 xen/arch/x86/mm/mem_sharing.c    |   27 +-
 xen/arch/x86/mm/p2m-ept.c        |    3 
 xen/arch/x86/mm/p2m.c            |  378 +++++++++++++++++++++++++++++++++------
 xen/common/domctl.c              |    3 
 xen/common/grant_table.c         |    3 
 xen/include/asm-x86/hvm/domain.h |    3 
 xen/include/asm-x86/mem_event.h  |    8 
 xen/include/asm-x86/p2m.h        |   11 -
 xen/include/public/trace.h       |   31 +++
 xen/include/xen/sched.h          |   16 +
 16 files changed, 569 insertions(+), 146 deletions(-)


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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 12:22:43 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 12:22:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW5ej-00076O-BP; Thu, 01 Dec 2011 12:22:25 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RW5eh-00075x-AY
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 12:22:23 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-13.tower-27.messagelabs.com!1322742087!50486224!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMzM1OTc=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMzM1OTc=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2355 invoked from network); 1 Dec 2011 12:21:28 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-13.tower-27.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 1 Dec 2011 12:21:28 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1322742108; l=893;
	s=domk; d=aepfle.de;
	h=To:From:Date:Subject:Content-Transfer-Encoding:MIME-Version:
	Content-Type:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=hCqSWba1kfPvyIW7Zx541piEJTQ=;
	b=AAzh8M1BY79lpJwlae6H4JX9/LgW+A1ReQKMQTILnkMcfhwatb6XVbZnwmHzYgOxxI6
	DjKFpyBzQWRa8Vptp7OT3bzcZFrX26m5fxYXaVZCiDMIPFz8hGgOzn+HhtD5/6hpQoar5
	1CbSIAlpIGJLZATUnl0sdxlK+e3kSTIlh54=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/ll2c7pE6jG
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-080-213.pools.arcor-ip.net [84.57.80.213])
	by smtp.strato.de (fruni mo40) (RZmta 26.10 AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id L06952nB1AoCTa
	for <xen-devel@lists.xensource.com>;
	Thu, 1 Dec 2011 13:21:27 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 7D33618636
	for <xen-devel@lists.xensource.com>;
	Thu,  1 Dec 2011 13:21:26 +0100 (CET)
MIME-Version: 1.0
Message-Id: <patchbomb.1322737756@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Thu, 01 Dec 2011 12:09:16 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 0 of 4] RFC: wait queue usage
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


The following series is my current state of an attempt to use wait queues for
xenpaging and mem_event handling. I post it here for review and comments.

This series conflicts with work from Andres Lagar-Cavilla.


Olaf


 xen/arch/x86/hvm/emulate.c       |    3 
 xen/arch/x86/hvm/hvm.c           |   21 +-
 xen/arch/x86/mm.c                |   49 +----
 xen/arch/x86/mm/guest_walk.c     |    3 
 xen/arch/x86/mm/hap/guest_walk.c |    6 
 xen/arch/x86/mm/mem_event.c      |  150 +++++++++++++--
 xen/arch/x86/mm/mem_sharing.c    |   27 +-
 xen/arch/x86/mm/p2m-ept.c        |    3 
 xen/arch/x86/mm/p2m.c            |  378 +++++++++++++++++++++++++++++++++------
 xen/common/domctl.c              |    3 
 xen/common/grant_table.c         |    3 
 xen/include/asm-x86/hvm/domain.h |    3 
 xen/include/asm-x86/mem_event.h  |    8 
 xen/include/asm-x86/p2m.h        |   11 -
 xen/include/public/trace.h       |   31 +++
 xen/include/xen/sched.h          |   16 +
 16 files changed, 569 insertions(+), 146 deletions(-)


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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 12:22:43 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 12:22:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW5ef-00075q-Cn; Thu, 01 Dec 2011 12:22:21 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RW5ed-00075k-BY
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 12:22:19 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-13.tower-27.messagelabs.com!1322742083!50486213!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.5 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMzM1OTc=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMzM1OTc=\n,BODY_RANDOM_LONG
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2091 invoked from network); 1 Dec 2011 12:21:23 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-13.tower-27.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 1 Dec 2011 12:21:23 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1322742103; l=10286;
	s=domk; d=aepfle.de;
	h=To:From:Date:References:In-Reply-To:Subject:
	Content-Transfer-Encoding:MIME-Version:Content-Type:X-RZG-CLASS-ID:
	X-RZG-AUTH; bh=XodBOyiR9Xk2eLqxxKgzTGNdvdk=;
	b=K1geTqQ6jkH24gKYZdJdwVULpc/23YommGXUf3cLNJo4lS8XwMO8G994IBoW2m2nFVL
	RWdS3p2Q4MHEcAbEd/vhphBq7i69Nz66sQHS5U1z1uYUskkGs8gs31Gj4P+Cy03aMiJon
	yV4HefhURY9JcBsD3m038cWV1O7IxrL9cNg=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/ll2c7pE6jG
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-080-213.pools.arcor-ip.net [84.57.80.213])
	by smtp.strato.de (fruni mo9) (RZmta 26.10 AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id m00841nB1ADeYC
	for <xen-devel@lists.xensource.com>;
	Thu, 1 Dec 2011 13:21:28 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 0C20618639
	for <xen-devel@lists.xensource.com>;
	Thu,  1 Dec 2011 13:21:27 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: c09ac3717a025a8ead44bbc795fedda715d134c7
Message-Id: <c09ac3717a025a8ead44.1322737759@probook.site>
In-Reply-To: <patchbomb.1322737756@probook.site>
References: <patchbomb.1322737756@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Thu, 01 Dec 2011 12:09:19 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 3 of 4] xenpaging: add need_populate and
	paged_no_mfn checks
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1322737586 -3600
# Node ID c09ac3717a025a8ead44bbc795fedda715d134c7
# Parent  8147822efdee65d1f5b94656ab2032aedb76979f
xenpaging: add need_populate and paged_no_mfn checks

There is currently a mix of p2mt checks for the various paging types.
Some mean the p2mt needs to be populated, others mean a gfn without mfn.

Add a new p2m_do_populate() helper which covers the p2m_ram_paged and
p2m_ram_paging_out types. If a gfn is not in these states anymore another
populate request for the pager is not needed. This avoids a call to
p2m_mem_paging_populate() which in turn reduces the pressure on the ring
buffer because no temporary slot needs to be claimed. As such, this helper is
an optimization.

Modify the existing p2m_is_paged() helper which now covers also
p2m_ram_paging_in_start in addition to the current p2m_ram_paged type.  A gfn
in these two states is not backed by a mfn.

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 8147822efdee -r c09ac3717a02 xen/arch/x86/hvm/emulate.c
--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -66,7 +66,8 @@ static int hvmemul_do_io(
     ram_mfn = get_gfn_unshare(curr->domain, ram_gfn, &p2mt);
     if ( p2m_is_paging(p2mt) )
     {
-        p2m_mem_paging_populate(curr->domain, ram_gfn);
+        if ( p2m_do_populate(p2mt) )
+            p2m_mem_paging_populate(curr->domain, ram_gfn);
         put_gfn(curr->domain, ram_gfn); 
         return X86EMUL_RETRY;
     }
diff -r 8147822efdee -r c09ac3717a02 xen/arch/x86/hvm/hvm.c
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -363,7 +363,8 @@ static int hvm_set_ioreq_page(
     }
     if ( p2m_is_paging(p2mt) )
     {
-        p2m_mem_paging_populate(d, gmfn);
+        if ( p2m_do_populate(p2mt) )
+            p2m_mem_paging_populate(d, gmfn);
         put_gfn(d, gmfn);
         return -ENOENT;
     }
@@ -1300,7 +1301,7 @@ int hvm_hap_nested_page_fault(unsigned l
 
 #ifdef __x86_64__
     /* Check if the page has been paged out */
-    if ( p2m_is_paged(p2mt) || (p2mt == p2m_ram_paging_out) )
+    if ( p2m_do_populate(p2mt) )
         p2m_mem_paging_populate(v->domain, gfn);
 
     /* Mem sharing: unshare the page and try again */
@@ -1820,7 +1821,8 @@ static void *__hvm_map_guest_frame(unsig
     }
     if ( p2m_is_paging(p2mt) )
     {
-        p2m_mem_paging_populate(d, gfn);
+        if ( p2m_do_populate(p2mt) )
+            p2m_mem_paging_populate(d, gfn);
         put_gfn(d, gfn);
         return NULL;
     }
@@ -2280,7 +2282,8 @@ static enum hvm_copy_result __hvm_copy(
 
         if ( p2m_is_paging(p2mt) )
         {
-            p2m_mem_paging_populate(curr->domain, gfn);
+            if ( p2m_do_populate(p2mt) )
+                p2m_mem_paging_populate(curr->domain, gfn);
             put_gfn(curr->domain, gfn);
             return HVMCOPY_gfn_paged_out;
         }
@@ -3760,7 +3763,8 @@ long do_hvm_op(unsigned long op, XEN_GUE
             mfn_t mfn = get_gfn_unshare(d, pfn, &t);
             if ( p2m_is_paging(t) )
             {
-                p2m_mem_paging_populate(d, pfn);
+                if ( p2m_do_populate(t) )
+                    p2m_mem_paging_populate(d, pfn);
                 put_gfn(d, pfn);
                 rc = -EINVAL;
                 goto param_fail3;
@@ -3864,7 +3868,8 @@ long do_hvm_op(unsigned long op, XEN_GUE
             mfn = get_gfn_unshare(d, pfn, &t);
             if ( p2m_is_paging(t) )
             {
-                p2m_mem_paging_populate(d, pfn);
+                if ( p2m_do_populate(t) )
+                    p2m_mem_paging_populate(d, pfn);
                 put_gfn(d, pfn);
                 rc = -EINVAL;
                 goto param_fail4;
diff -r 8147822efdee -r c09ac3717a02 xen/arch/x86/mm.c
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -3525,9 +3525,10 @@ int do_mmu_update(
             if ( !p2m_is_valid(p2mt) )
                 mfn = INVALID_MFN;
 
-            if ( p2m_is_paged(p2mt) )
+            if ( p2m_is_paged(p2mt) && !mfn_valid(mfn) )
             {
-                p2m_mem_paging_populate(pg_owner, gmfn);
+                if ( p2m_do_populate(p2mt) )
+                    p2m_mem_paging_populate(pg_owner, gmfn);
                 put_gfn(pt_owner, gmfn);
                 rc = -ENOENT;
                 break;
@@ -3565,15 +3566,10 @@ int do_mmu_update(
     
                     l1emfn = mfn_x(get_gfn(pg_owner, l1egfn, &l1e_p2mt));
 
-                    if ( p2m_is_paged(l1e_p2mt) )
+                    if ( p2m_is_paged(l1e_p2mt) && !mfn_valid(l1emfn) )
                     {
-                        p2m_mem_paging_populate(pg_owner, l1e_get_pfn(l1e));
-                        put_gfn(pg_owner, l1egfn);
-                        rc = -ENOENT;
-                        break;
-                    }
-                    else if ( p2m_ram_paging_in_start == l1e_p2mt && !mfn_valid(mfn) )
-                    {
+                        if ( p2m_do_populate(l1e_p2mt) )
+                            p2m_mem_paging_populate(pg_owner, l1e_get_pfn(l1e));
                         put_gfn(pg_owner, l1egfn);
                         rc = -ENOENT;
                         break;
@@ -3613,15 +3609,10 @@ int do_mmu_update(
 
                     l2emfn = mfn_x(get_gfn(pg_owner, l2egfn, &l2e_p2mt));
 
-                    if ( p2m_is_paged(l2e_p2mt) )
+                    if ( p2m_is_paged(l2e_p2mt) && !mfn_valid(l2emfn) )
                     {
-                        p2m_mem_paging_populate(pg_owner, l2egfn);
-                        put_gfn(pg_owner, l2egfn);
-                        rc = -ENOENT;
-                        break;
-                    }
-                    else if ( p2m_ram_paging_in_start == l2e_p2mt && !mfn_valid(mfn) )
-                    {
+                        if ( p2m_do_populate(l2e_p2mt) )
+                            p2m_mem_paging_populate(pg_owner, l2egfn);
                         put_gfn(pg_owner, l2egfn);
                         rc = -ENOENT;
                         break;
@@ -3647,15 +3638,10 @@ int do_mmu_update(
 
                     l3emfn = mfn_x(get_gfn(pg_owner, l3egfn, &l3e_p2mt));
 
-                    if ( p2m_is_paged(l3e_p2mt) )
+                    if ( p2m_is_paged(l3e_p2mt) && !mfn_valid(l3emfn) )
                     {
-                        p2m_mem_paging_populate(pg_owner, l3egfn);
-                        put_gfn(pg_owner, l3egfn);
-                        rc = -ENOENT;
-                        break;
-                    }
-                    else if ( p2m_ram_paging_in_start == l3e_p2mt && !mfn_valid(mfn) )
-                    {
+                        if ( p2m_do_populate(l3e_p2mt) )
+                            p2m_mem_paging_populate(pg_owner, l3egfn);
                         put_gfn(pg_owner, l3egfn);
                         rc = -ENOENT;
                         break;
@@ -3681,15 +3667,10 @@ int do_mmu_update(
 
                     l4emfn = mfn_x(get_gfn(pg_owner, l4egfn, &l4e_p2mt));
 
-                    if ( p2m_is_paged(l4e_p2mt) )
+                    if ( p2m_is_paged(l4e_p2mt) && !mfn_valid(l4emfn) )
                     {
-                        p2m_mem_paging_populate(pg_owner, l4egfn);
-                        put_gfn(pg_owner, l4egfn);
-                        rc = -ENOENT;
-                        break;
-                    }
-                    else if ( p2m_ram_paging_in_start == l4e_p2mt && !mfn_valid(mfn) )
-                    {
+                        if ( p2m_do_populate(l4e_p2mt) )
+                            p2m_mem_paging_populate(pg_owner, l4egfn);
                         put_gfn(pg_owner, l4egfn);
                         rc = -ENOENT;
                         break;
diff -r 8147822efdee -r c09ac3717a02 xen/arch/x86/mm/guest_walk.c
--- a/xen/arch/x86/mm/guest_walk.c
+++ b/xen/arch/x86/mm/guest_walk.c
@@ -102,7 +102,8 @@ static inline void *map_domain_gfn(struc
     if ( p2m_is_paging(*p2mt) )
     {
         ASSERT(!p2m_is_nestedp2m(p2m));
-        p2m_mem_paging_populate(p2m->domain, gfn_x(gfn));
+        if ( p2m_do_populate(*p2mt) )
+            p2m_mem_paging_populate(p2m->domain, gfn_x(gfn));
         __put_gfn(p2m, gfn_x(gfn));
         *rc = _PAGE_PAGED;
         return NULL;
diff -r 8147822efdee -r c09ac3717a02 xen/arch/x86/mm/hap/guest_walk.c
--- a/xen/arch/x86/mm/hap/guest_walk.c
+++ b/xen/arch/x86/mm/hap/guest_walk.c
@@ -64,7 +64,8 @@ unsigned long hap_p2m_ga_to_gfn(GUEST_PA
     if ( p2m_is_paging(p2mt) )
     {
         ASSERT(!p2m_is_nestedp2m(p2m));
-        p2m_mem_paging_populate(p2m->domain, cr3 >> PAGE_SHIFT);
+        if ( p2m_do_populate(p2mt) )
+            p2m_mem_paging_populate(p2m->domain, cr3 >> PAGE_SHIFT);
 
         pfec[0] = PFEC_page_paged;
         __put_gfn(p2m, top_gfn);
@@ -101,7 +102,8 @@ unsigned long hap_p2m_ga_to_gfn(GUEST_PA
         if ( p2m_is_paging(p2mt) )
         {
             ASSERT(!p2m_is_nestedp2m(p2m));
-            p2m_mem_paging_populate(p2m->domain, gfn_x(gfn));
+            if ( p2m_do_populate(p2mt) )
+                p2m_mem_paging_populate(p2m->domain, gfn_x(gfn));
 
             pfec[0] = PFEC_page_paged;
             __put_gfn(p2m, gfn_x(gfn));
diff -r 8147822efdee -r c09ac3717a02 xen/arch/x86/mm/p2m-ept.c
--- a/xen/arch/x86/mm/p2m-ept.c
+++ b/xen/arch/x86/mm/p2m-ept.c
@@ -375,8 +375,7 @@ ept_set_entry(struct p2m_domain *p2m, un
          * Read-then-write is OK because we hold the p2m lock. */
         old_entry = *ept_entry;
 
-        if ( mfn_valid(mfn_x(mfn)) || direct_mmio || p2m_is_paged(p2mt) ||
-             (p2mt == p2m_ram_paging_in_start) )
+        if ( mfn_valid(mfn_x(mfn)) || direct_mmio || p2m_is_paged(p2mt) )
         {
             /* Construct the new entry, and then write it once */
             new_entry.emt = epte_get_entry_emt(p2m->domain, gfn, mfn, &ipat,
diff -r 8147822efdee -r c09ac3717a02 xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -313,7 +313,7 @@ static void p2m_mem_paging_wait(mfn_t *m
         return;
 
     /* Populate the page once */
-    if ( *t == p2m_ram_paging_out || *t == p2m_ram_paged )
+    if ( p2m_do_populate(*t) )
         p2m_mem_paging_populate(p2m->domain, gfn);
 
     wait_event(pmpq->wq, p2m_mem_paging_get_entry(mfn, p2m, gfn, t, a, q, page_order));
@@ -1111,7 +1111,7 @@ void p2m_mem_paging_populate(struct doma
     p2m_lock(p2m);
     mfn = p2m->get_entry(p2m, gfn, &p2mt, &a, p2m_query, NULL);
     /* Forward the state only if gfn is in page-out path */
-    if ( p2mt == p2m_ram_paging_out || p2mt == p2m_ram_paged ) {
+    if ( p2m_do_populate(p2mt) ) {
         /* Ignore foreign requests to allow mmap in pager */
         if ( mfn_valid(mfn) && p2mt == p2m_ram_paging_out && v->domain == d ) {
             /* Restore gfn because it is needed by guest before evict */
diff -r 8147822efdee -r c09ac3717a02 xen/common/grant_table.c
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -163,7 +163,8 @@ static int __get_paged_frame(unsigned lo
         *frame = mfn_x(mfn);
         if ( p2m_is_paging(p2mt) )
         {
-            p2m_mem_paging_populate(rd, gfn);
+            if ( p2m_do_populate(p2mt) )
+                p2m_mem_paging_populate(rd, gfn);
             put_gfn(rd, gfn);
             rc = GNTST_eagain;
         }
diff -r 8147822efdee -r c09ac3717a02 xen/include/asm-x86/p2m.h
--- a/xen/include/asm-x86/p2m.h
+++ b/xen/include/asm-x86/p2m.h
@@ -158,7 +158,11 @@ typedef enum {
                           | p2m_to_mask(p2m_ram_paging_in_start) \
                           | p2m_to_mask(p2m_ram_paging_in))
 
-#define P2M_PAGED_TYPES (p2m_to_mask(p2m_ram_paged))
+#define P2M_POPULATE_TYPES (p2m_to_mask(p2m_ram_paged) \
+                            | p2m_to_mask(p2m_ram_paging_out) )
+
+#define P2M_PAGED_NO_MFN_TYPES (p2m_to_mask(p2m_ram_paged) \
+                               | p2m_to_mask(p2m_ram_paging_in_start) )
 
 /* Shared types */
 /* XXX: Sharable types could include p2m_ram_ro too, but we would need to
@@ -183,7 +187,8 @@ typedef enum {
 #define p2m_has_emt(_t)  (p2m_to_mask(_t) & (P2M_RAM_TYPES | p2m_to_mask(p2m_mmio_direct)))
 #define p2m_is_pageable(_t) (p2m_to_mask(_t) & P2M_PAGEABLE_TYPES)
 #define p2m_is_paging(_t)   (p2m_to_mask(_t) & P2M_PAGING_TYPES)
-#define p2m_is_paged(_t)    (p2m_to_mask(_t) & P2M_PAGED_TYPES)
+#define p2m_do_populate(_t) (p2m_to_mask(_t) & P2M_POPULATE_TYPES)
+#define p2m_is_paged(_t)    (p2m_to_mask(_t) & P2M_PAGED_NO_MFN_TYPES)
 #define p2m_is_sharable(_t) (p2m_to_mask(_t) & P2M_SHARABLE_TYPES)
 #define p2m_is_shared(_t)   (p2m_to_mask(_t) & P2M_SHARED_TYPES)
 #define p2m_is_broken(_t)   (p2m_to_mask(_t) & P2M_BROKEN_TYPES)

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 12:22:43 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 12:22:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW5ef-00075q-Cn; Thu, 01 Dec 2011 12:22:21 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RW5ed-00075k-BY
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 12:22:19 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-13.tower-27.messagelabs.com!1322742083!50486213!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.5 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMzM1OTc=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMzM1OTc=\n,BODY_RANDOM_LONG
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2091 invoked from network); 1 Dec 2011 12:21:23 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-13.tower-27.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 1 Dec 2011 12:21:23 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1322742103; l=10286;
	s=domk; d=aepfle.de;
	h=To:From:Date:References:In-Reply-To:Subject:
	Content-Transfer-Encoding:MIME-Version:Content-Type:X-RZG-CLASS-ID:
	X-RZG-AUTH; bh=XodBOyiR9Xk2eLqxxKgzTGNdvdk=;
	b=K1geTqQ6jkH24gKYZdJdwVULpc/23YommGXUf3cLNJo4lS8XwMO8G994IBoW2m2nFVL
	RWdS3p2Q4MHEcAbEd/vhphBq7i69Nz66sQHS5U1z1uYUskkGs8gs31Gj4P+Cy03aMiJon
	yV4HefhURY9JcBsD3m038cWV1O7IxrL9cNg=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/ll2c7pE6jG
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-080-213.pools.arcor-ip.net [84.57.80.213])
	by smtp.strato.de (fruni mo9) (RZmta 26.10 AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id m00841nB1ADeYC
	for <xen-devel@lists.xensource.com>;
	Thu, 1 Dec 2011 13:21:28 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 0C20618639
	for <xen-devel@lists.xensource.com>;
	Thu,  1 Dec 2011 13:21:27 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: c09ac3717a025a8ead44bbc795fedda715d134c7
Message-Id: <c09ac3717a025a8ead44.1322737759@probook.site>
In-Reply-To: <patchbomb.1322737756@probook.site>
References: <patchbomb.1322737756@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Thu, 01 Dec 2011 12:09:19 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 3 of 4] xenpaging: add need_populate and
	paged_no_mfn checks
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1322737586 -3600
# Node ID c09ac3717a025a8ead44bbc795fedda715d134c7
# Parent  8147822efdee65d1f5b94656ab2032aedb76979f
xenpaging: add need_populate and paged_no_mfn checks

There is currently a mix of p2mt checks for the various paging types.
Some mean the p2mt needs to be populated, others mean a gfn without mfn.

Add a new p2m_do_populate() helper which covers the p2m_ram_paged and
p2m_ram_paging_out types. If a gfn is not in these states anymore another
populate request for the pager is not needed. This avoids a call to
p2m_mem_paging_populate() which in turn reduces the pressure on the ring
buffer because no temporary slot needs to be claimed. As such, this helper is
an optimization.

Modify the existing p2m_is_paged() helper which now covers also
p2m_ram_paging_in_start in addition to the current p2m_ram_paged type.  A gfn
in these two states is not backed by a mfn.

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 8147822efdee -r c09ac3717a02 xen/arch/x86/hvm/emulate.c
--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -66,7 +66,8 @@ static int hvmemul_do_io(
     ram_mfn = get_gfn_unshare(curr->domain, ram_gfn, &p2mt);
     if ( p2m_is_paging(p2mt) )
     {
-        p2m_mem_paging_populate(curr->domain, ram_gfn);
+        if ( p2m_do_populate(p2mt) )
+            p2m_mem_paging_populate(curr->domain, ram_gfn);
         put_gfn(curr->domain, ram_gfn); 
         return X86EMUL_RETRY;
     }
diff -r 8147822efdee -r c09ac3717a02 xen/arch/x86/hvm/hvm.c
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -363,7 +363,8 @@ static int hvm_set_ioreq_page(
     }
     if ( p2m_is_paging(p2mt) )
     {
-        p2m_mem_paging_populate(d, gmfn);
+        if ( p2m_do_populate(p2mt) )
+            p2m_mem_paging_populate(d, gmfn);
         put_gfn(d, gmfn);
         return -ENOENT;
     }
@@ -1300,7 +1301,7 @@ int hvm_hap_nested_page_fault(unsigned l
 
 #ifdef __x86_64__
     /* Check if the page has been paged out */
-    if ( p2m_is_paged(p2mt) || (p2mt == p2m_ram_paging_out) )
+    if ( p2m_do_populate(p2mt) )
         p2m_mem_paging_populate(v->domain, gfn);
 
     /* Mem sharing: unshare the page and try again */
@@ -1820,7 +1821,8 @@ static void *__hvm_map_guest_frame(unsig
     }
     if ( p2m_is_paging(p2mt) )
     {
-        p2m_mem_paging_populate(d, gfn);
+        if ( p2m_do_populate(p2mt) )
+            p2m_mem_paging_populate(d, gfn);
         put_gfn(d, gfn);
         return NULL;
     }
@@ -2280,7 +2282,8 @@ static enum hvm_copy_result __hvm_copy(
 
         if ( p2m_is_paging(p2mt) )
         {
-            p2m_mem_paging_populate(curr->domain, gfn);
+            if ( p2m_do_populate(p2mt) )
+                p2m_mem_paging_populate(curr->domain, gfn);
             put_gfn(curr->domain, gfn);
             return HVMCOPY_gfn_paged_out;
         }
@@ -3760,7 +3763,8 @@ long do_hvm_op(unsigned long op, XEN_GUE
             mfn_t mfn = get_gfn_unshare(d, pfn, &t);
             if ( p2m_is_paging(t) )
             {
-                p2m_mem_paging_populate(d, pfn);
+                if ( p2m_do_populate(t) )
+                    p2m_mem_paging_populate(d, pfn);
                 put_gfn(d, pfn);
                 rc = -EINVAL;
                 goto param_fail3;
@@ -3864,7 +3868,8 @@ long do_hvm_op(unsigned long op, XEN_GUE
             mfn = get_gfn_unshare(d, pfn, &t);
             if ( p2m_is_paging(t) )
             {
-                p2m_mem_paging_populate(d, pfn);
+                if ( p2m_do_populate(t) )
+                    p2m_mem_paging_populate(d, pfn);
                 put_gfn(d, pfn);
                 rc = -EINVAL;
                 goto param_fail4;
diff -r 8147822efdee -r c09ac3717a02 xen/arch/x86/mm.c
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -3525,9 +3525,10 @@ int do_mmu_update(
             if ( !p2m_is_valid(p2mt) )
                 mfn = INVALID_MFN;
 
-            if ( p2m_is_paged(p2mt) )
+            if ( p2m_is_paged(p2mt) && !mfn_valid(mfn) )
             {
-                p2m_mem_paging_populate(pg_owner, gmfn);
+                if ( p2m_do_populate(p2mt) )
+                    p2m_mem_paging_populate(pg_owner, gmfn);
                 put_gfn(pt_owner, gmfn);
                 rc = -ENOENT;
                 break;
@@ -3565,15 +3566,10 @@ int do_mmu_update(
     
                     l1emfn = mfn_x(get_gfn(pg_owner, l1egfn, &l1e_p2mt));
 
-                    if ( p2m_is_paged(l1e_p2mt) )
+                    if ( p2m_is_paged(l1e_p2mt) && !mfn_valid(l1emfn) )
                     {
-                        p2m_mem_paging_populate(pg_owner, l1e_get_pfn(l1e));
-                        put_gfn(pg_owner, l1egfn);
-                        rc = -ENOENT;
-                        break;
-                    }
-                    else if ( p2m_ram_paging_in_start == l1e_p2mt && !mfn_valid(mfn) )
-                    {
+                        if ( p2m_do_populate(l1e_p2mt) )
+                            p2m_mem_paging_populate(pg_owner, l1e_get_pfn(l1e));
                         put_gfn(pg_owner, l1egfn);
                         rc = -ENOENT;
                         break;
@@ -3613,15 +3609,10 @@ int do_mmu_update(
 
                     l2emfn = mfn_x(get_gfn(pg_owner, l2egfn, &l2e_p2mt));
 
-                    if ( p2m_is_paged(l2e_p2mt) )
+                    if ( p2m_is_paged(l2e_p2mt) && !mfn_valid(l2emfn) )
                     {
-                        p2m_mem_paging_populate(pg_owner, l2egfn);
-                        put_gfn(pg_owner, l2egfn);
-                        rc = -ENOENT;
-                        break;
-                    }
-                    else if ( p2m_ram_paging_in_start == l2e_p2mt && !mfn_valid(mfn) )
-                    {
+                        if ( p2m_do_populate(l2e_p2mt) )
+                            p2m_mem_paging_populate(pg_owner, l2egfn);
                         put_gfn(pg_owner, l2egfn);
                         rc = -ENOENT;
                         break;
@@ -3647,15 +3638,10 @@ int do_mmu_update(
 
                     l3emfn = mfn_x(get_gfn(pg_owner, l3egfn, &l3e_p2mt));
 
-                    if ( p2m_is_paged(l3e_p2mt) )
+                    if ( p2m_is_paged(l3e_p2mt) && !mfn_valid(l3emfn) )
                     {
-                        p2m_mem_paging_populate(pg_owner, l3egfn);
-                        put_gfn(pg_owner, l3egfn);
-                        rc = -ENOENT;
-                        break;
-                    }
-                    else if ( p2m_ram_paging_in_start == l3e_p2mt && !mfn_valid(mfn) )
-                    {
+                        if ( p2m_do_populate(l3e_p2mt) )
+                            p2m_mem_paging_populate(pg_owner, l3egfn);
                         put_gfn(pg_owner, l3egfn);
                         rc = -ENOENT;
                         break;
@@ -3681,15 +3667,10 @@ int do_mmu_update(
 
                     l4emfn = mfn_x(get_gfn(pg_owner, l4egfn, &l4e_p2mt));
 
-                    if ( p2m_is_paged(l4e_p2mt) )
+                    if ( p2m_is_paged(l4e_p2mt) && !mfn_valid(l4emfn) )
                     {
-                        p2m_mem_paging_populate(pg_owner, l4egfn);
-                        put_gfn(pg_owner, l4egfn);
-                        rc = -ENOENT;
-                        break;
-                    }
-                    else if ( p2m_ram_paging_in_start == l4e_p2mt && !mfn_valid(mfn) )
-                    {
+                        if ( p2m_do_populate(l4e_p2mt) )
+                            p2m_mem_paging_populate(pg_owner, l4egfn);
                         put_gfn(pg_owner, l4egfn);
                         rc = -ENOENT;
                         break;
diff -r 8147822efdee -r c09ac3717a02 xen/arch/x86/mm/guest_walk.c
--- a/xen/arch/x86/mm/guest_walk.c
+++ b/xen/arch/x86/mm/guest_walk.c
@@ -102,7 +102,8 @@ static inline void *map_domain_gfn(struc
     if ( p2m_is_paging(*p2mt) )
     {
         ASSERT(!p2m_is_nestedp2m(p2m));
-        p2m_mem_paging_populate(p2m->domain, gfn_x(gfn));
+        if ( p2m_do_populate(*p2mt) )
+            p2m_mem_paging_populate(p2m->domain, gfn_x(gfn));
         __put_gfn(p2m, gfn_x(gfn));
         *rc = _PAGE_PAGED;
         return NULL;
diff -r 8147822efdee -r c09ac3717a02 xen/arch/x86/mm/hap/guest_walk.c
--- a/xen/arch/x86/mm/hap/guest_walk.c
+++ b/xen/arch/x86/mm/hap/guest_walk.c
@@ -64,7 +64,8 @@ unsigned long hap_p2m_ga_to_gfn(GUEST_PA
     if ( p2m_is_paging(p2mt) )
     {
         ASSERT(!p2m_is_nestedp2m(p2m));
-        p2m_mem_paging_populate(p2m->domain, cr3 >> PAGE_SHIFT);
+        if ( p2m_do_populate(p2mt) )
+            p2m_mem_paging_populate(p2m->domain, cr3 >> PAGE_SHIFT);
 
         pfec[0] = PFEC_page_paged;
         __put_gfn(p2m, top_gfn);
@@ -101,7 +102,8 @@ unsigned long hap_p2m_ga_to_gfn(GUEST_PA
         if ( p2m_is_paging(p2mt) )
         {
             ASSERT(!p2m_is_nestedp2m(p2m));
-            p2m_mem_paging_populate(p2m->domain, gfn_x(gfn));
+            if ( p2m_do_populate(p2mt) )
+                p2m_mem_paging_populate(p2m->domain, gfn_x(gfn));
 
             pfec[0] = PFEC_page_paged;
             __put_gfn(p2m, gfn_x(gfn));
diff -r 8147822efdee -r c09ac3717a02 xen/arch/x86/mm/p2m-ept.c
--- a/xen/arch/x86/mm/p2m-ept.c
+++ b/xen/arch/x86/mm/p2m-ept.c
@@ -375,8 +375,7 @@ ept_set_entry(struct p2m_domain *p2m, un
          * Read-then-write is OK because we hold the p2m lock. */
         old_entry = *ept_entry;
 
-        if ( mfn_valid(mfn_x(mfn)) || direct_mmio || p2m_is_paged(p2mt) ||
-             (p2mt == p2m_ram_paging_in_start) )
+        if ( mfn_valid(mfn_x(mfn)) || direct_mmio || p2m_is_paged(p2mt) )
         {
             /* Construct the new entry, and then write it once */
             new_entry.emt = epte_get_entry_emt(p2m->domain, gfn, mfn, &ipat,
diff -r 8147822efdee -r c09ac3717a02 xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -313,7 +313,7 @@ static void p2m_mem_paging_wait(mfn_t *m
         return;
 
     /* Populate the page once */
-    if ( *t == p2m_ram_paging_out || *t == p2m_ram_paged )
+    if ( p2m_do_populate(*t) )
         p2m_mem_paging_populate(p2m->domain, gfn);
 
     wait_event(pmpq->wq, p2m_mem_paging_get_entry(mfn, p2m, gfn, t, a, q, page_order));
@@ -1111,7 +1111,7 @@ void p2m_mem_paging_populate(struct doma
     p2m_lock(p2m);
     mfn = p2m->get_entry(p2m, gfn, &p2mt, &a, p2m_query, NULL);
     /* Forward the state only if gfn is in page-out path */
-    if ( p2mt == p2m_ram_paging_out || p2mt == p2m_ram_paged ) {
+    if ( p2m_do_populate(p2mt) ) {
         /* Ignore foreign requests to allow mmap in pager */
         if ( mfn_valid(mfn) && p2mt == p2m_ram_paging_out && v->domain == d ) {
             /* Restore gfn because it is needed by guest before evict */
diff -r 8147822efdee -r c09ac3717a02 xen/common/grant_table.c
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -163,7 +163,8 @@ static int __get_paged_frame(unsigned lo
         *frame = mfn_x(mfn);
         if ( p2m_is_paging(p2mt) )
         {
-            p2m_mem_paging_populate(rd, gfn);
+            if ( p2m_do_populate(p2mt) )
+                p2m_mem_paging_populate(rd, gfn);
             put_gfn(rd, gfn);
             rc = GNTST_eagain;
         }
diff -r 8147822efdee -r c09ac3717a02 xen/include/asm-x86/p2m.h
--- a/xen/include/asm-x86/p2m.h
+++ b/xen/include/asm-x86/p2m.h
@@ -158,7 +158,11 @@ typedef enum {
                           | p2m_to_mask(p2m_ram_paging_in_start) \
                           | p2m_to_mask(p2m_ram_paging_in))
 
-#define P2M_PAGED_TYPES (p2m_to_mask(p2m_ram_paged))
+#define P2M_POPULATE_TYPES (p2m_to_mask(p2m_ram_paged) \
+                            | p2m_to_mask(p2m_ram_paging_out) )
+
+#define P2M_PAGED_NO_MFN_TYPES (p2m_to_mask(p2m_ram_paged) \
+                               | p2m_to_mask(p2m_ram_paging_in_start) )
 
 /* Shared types */
 /* XXX: Sharable types could include p2m_ram_ro too, but we would need to
@@ -183,7 +187,8 @@ typedef enum {
 #define p2m_has_emt(_t)  (p2m_to_mask(_t) & (P2M_RAM_TYPES | p2m_to_mask(p2m_mmio_direct)))
 #define p2m_is_pageable(_t) (p2m_to_mask(_t) & P2M_PAGEABLE_TYPES)
 #define p2m_is_paging(_t)   (p2m_to_mask(_t) & P2M_PAGING_TYPES)
-#define p2m_is_paged(_t)    (p2m_to_mask(_t) & P2M_PAGED_TYPES)
+#define p2m_do_populate(_t) (p2m_to_mask(_t) & P2M_POPULATE_TYPES)
+#define p2m_is_paged(_t)    (p2m_to_mask(_t) & P2M_PAGED_NO_MFN_TYPES)
 #define p2m_is_sharable(_t) (p2m_to_mask(_t) & P2M_SHARABLE_TYPES)
 #define p2m_is_shared(_t)   (p2m_to_mask(_t) & P2M_SHARED_TYPES)
 #define p2m_is_broken(_t)   (p2m_to_mask(_t) & P2M_BROKEN_TYPES)

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 12:22:43 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 12:22:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW5ei-00076D-UC; Thu, 01 Dec 2011 12:22:24 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RW5eg-00075i-Bs
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 12:22:23 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-11.tower-216.messagelabs.com!1322742097!5704704!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNDUxMTM=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNDUxMTM=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21588 invoked from network); 1 Dec 2011 12:21:41 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-11.tower-216.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 1 Dec 2011 12:21:41 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1322742097; l=15992;
	s=domk; d=aepfle.de;
	h=To:From:Date:References:In-Reply-To:Subject:
	Content-Transfer-Encoding:MIME-Version:Content-Type:X-RZG-CLASS-ID:
	X-RZG-AUTH; bh=2phNJUsXOnJ84zIkaza8VA8hq1c=;
	b=C/RVfsq0gXvJIsYYNYgD51o/IFDT9hCnjIO+uIzOo6T2EfimrYOVh0uGKGA4zyj+Sd2
	bBHHxfseVA/Sn27dzEevmn9qIbvOifbPV3i24TmYXvuoSdciwA9/1gcX8BCokfhp8vYnM
	7+pgeL8yGDHee3De3ukgEBdI3O7m9azYFwM=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/ll2c7pE6jG
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-080-213.pools.arcor-ip.net [84.57.80.213])
	by smtp.strato.de (klopstock mo3) (RZmta 26.10 AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id g0470enB1BxpLY
	for <xen-devel@lists.xensource.com>;
	Thu, 1 Dec 2011 13:21:27 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id AC30318637
	for <xen-devel@lists.xensource.com>;
	Thu,  1 Dec 2011 13:21:26 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 612f69531fd15cf59c58404f6e4762733a9a268c
Message-Id: <612f69531fd15cf59c58.1322737757@probook.site>
In-Reply-To: <patchbomb.1322737756@probook.site>
References: <patchbomb.1322737756@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Thu, 01 Dec 2011 12:09:17 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 1 of 4] mem_event: use wait queue when ring is
	full
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1322736732 -3600
# Node ID 612f69531fd15cf59c58404f6e4762733a9a268c
# Parent  3c4c29899d8a2a0c0f9109b7236da95bb72b77b6
mem_event: use wait queue when ring is full

This change is based on an idea/patch from Adin Scannell.

If the ring is full, put the current vcpu to sleep if it belongs to the
target domain. The wakeup happens in the p2m_*_resume functions. Wakeup
will take the number of free slots into account.

A request from another domain will use the existing ->req_producers
functionality because sleeping is not possible if the vcpu does not
belong to the target domain.

This change fixes also a bug in p2m_mem_paging_drop_page(). Up to now a
full ring will lead to harmless inconsistency in the pager.

v4:
 - fix off-by-one bug in _mem_event_put_request
 - add mem_event_wake_requesters() and use wake_up_nr()
 - rename mem_event_mark_and_pause() and mem_event_mark_and_pause() functions
 - req_producers counts foreign request producers, rename member

v3:
 - rename ->mem_event_bit to ->bit
 - remove me_ from new VPF_ defines

v2:
 - p2m_mem_paging_populate: move vcpu_pause after put_request, otherwise the
   vcpu will not wake_up after a wait_event because the pause_count was
   increased twice. Fixes guest hangs.
 - update free space check in _mem_event_put_request()
 - simplify mem_event_put_request()

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 3c4c29899d8a -r 612f69531fd1 xen/arch/x86/hvm/hvm.c
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -4107,7 +4107,7 @@ static int hvm_memory_event_traps(long p
         return 1;
     
     rc = mem_event_check_ring(d, &d->mem_event->access);
-    if ( rc )
+    if ( rc < 0 )
         return rc;
     
     memset(&req, 0, sizeof(req));
diff -r 3c4c29899d8a -r 612f69531fd1 xen/arch/x86/mm/mem_event.c
--- a/xen/arch/x86/mm/mem_event.c
+++ b/xen/arch/x86/mm/mem_event.c
@@ -23,6 +23,7 @@
 
 #include <asm/domain.h>
 #include <xen/event.h>
+#include <xen/wait.h>
 #include <asm/p2m.h>
 #include <asm/mem_event.h>
 #include <asm/mem_paging.h>
@@ -39,6 +40,7 @@
 
 static int mem_event_enable(struct domain *d,
                             xen_domctl_mem_event_op_t *mec,
+                            int bit,
                             struct mem_event_domain *med)
 {
     int rc;
@@ -107,8 +109,12 @@ static int mem_event_enable(struct domai
 
     mem_event_ring_lock_init(med);
 
+    med->bit = bit;
+
+    init_waitqueue_head(&med->wq);
+
     /* Wake any VCPUs paused for memory events */
-    mem_event_unpause_vcpus(d);
+    mem_event_wake_waiters(d, med);
 
     return 0;
 
@@ -124,6 +130,9 @@ static int mem_event_enable(struct domai
 
 static int mem_event_disable(struct mem_event_domain *med)
 {
+    if (!list_empty(&med->wq.list))
+        return -EBUSY;
+
     unmap_domain_page(med->ring_page);
     med->ring_page = NULL;
 
@@ -133,13 +142,23 @@ static int mem_event_disable(struct mem_
     return 0;
 }
 
-void mem_event_put_request(struct domain *d, struct mem_event_domain *med, mem_event_request_t *req)
+static int _mem_event_put_request(struct domain *d,
+                                  struct mem_event_domain *med,
+                                  mem_event_request_t *req)
 {
     mem_event_front_ring_t *front_ring;
+    int free_requests;
     RING_IDX req_prod;
 
     mem_event_ring_lock(med);
 
+    free_requests = RING_FREE_REQUESTS(&med->front_ring);
+    /* Requests from foreign domain were claimed in mem_event_check_ring() */
+    if ((current->domain == d && free_requests < med->foreign_producers) || !free_requests) {
+        mem_event_ring_unlock(med);
+        return 0;
+    }
+
     front_ring = &med->front_ring;
     req_prod = front_ring->req_prod_pvt;
 
@@ -148,13 +167,30 @@ void mem_event_put_request(struct domain
     req_prod++;
 
     /* Update ring */
-    med->req_producers--;
+    if (current->domain != d)
+        med->foreign_producers--;
     front_ring->req_prod_pvt = req_prod;
     RING_PUSH_REQUESTS(front_ring);
 
     mem_event_ring_unlock(med);
 
     notify_via_xen_event_channel(d, med->xen_port);
+
+    return 1;
+}
+
+void mem_event_put_request(struct domain *d, struct mem_event_domain *med,
+                           mem_event_request_t *req)
+{
+    /* Go to sleep if request came from guest */
+    if (current->domain == d) {
+        wait_event(med->wq, _mem_event_put_request(d, med, req));
+        return;
+    }
+    /* Ring was full anyway, unable to sleep in non-guest context */
+    if (!_mem_event_put_request(d, med, req))
+        printk("Failed to put memreq: d %u t %x f %x gfn %lx\n", d->domain_id,
+                req->type, req->flags, (unsigned long)req->gfn);
 }
 
 void mem_event_get_response(struct mem_event_domain *med, mem_event_response_t *rsp)
@@ -178,31 +214,95 @@ void mem_event_get_response(struct mem_e
     mem_event_ring_unlock(med);
 }
 
-void mem_event_unpause_vcpus(struct domain *d)
+/**
+ * mem_event_wake_requesters - Wake vcpus waiting for room in the ring
+ * @d: guest domain
+ * @med: mem_event ring
+ *
+ * mem_event_wake_requesters() will wakeup vcpus waiting for room in the
+ * ring. Only as many as can place another request in the ring will
+ * resume execution.
+ */
+void mem_event_wake_requesters(struct mem_event_domain *med)
+{
+    int free_requests;
+
+    mem_event_ring_lock(med);
+
+    free_requests = RING_FREE_REQUESTS(&med->front_ring);
+    if ( free_requests )
+        wake_up_nr(&med->wq, free_requests);
+
+    mem_event_ring_unlock(med);
+}
+
+/**
+ * mem_event_wake_waiters - Wake all vcpus waiting for the ring
+ * @d: guest domain
+ * @med: mem_event ring
+ *
+ * mem_event_wake_waiters() will wakeup all vcpus waiting for the ring to 
+ * become available.
+ */
+void mem_event_wake_waiters(struct domain *d, struct mem_event_domain *med)
 {
     struct vcpu *v;
 
     for_each_vcpu ( d, v )
-        if ( test_and_clear_bit(_VPF_mem_event, &v->pause_flags) )
+        if ( test_and_clear_bit(med->bit, &v->pause_flags) )
             vcpu_wake(v);
 }
 
-void mem_event_mark_and_pause(struct vcpu *v)
+/**
+ * mem_event_mark_and_sleep - Put vcpu to sleep
+ * @v: guest vcpu
+ * @med: mem_event ring
+ *
+ * mem_event_mark_and_sleep() tags vcpu and put it to sleep.
+ * The vcpu will resume execution in mem_event_wake_waiters().
+ */
+void mem_event_mark_and_sleep(struct vcpu *v, struct mem_event_domain *med)
 {
-    set_bit(_VPF_mem_event, &v->pause_flags);
+    set_bit(med->bit, &v->pause_flags);
     vcpu_sleep_nosync(v);
 }
 
-void mem_event_put_req_producers(struct mem_event_domain *med)
+/**
+ * mem_event_put_req_producers - Release a claimed slot
+ * @med: mem_event ring
+ *
+ * mem_event_put_req_producers() releases a claimed slot in the mem_event ring.
+ */
+void mem_event_put_req_producers(struct domain *d, struct mem_event_domain *med)
 {
+    if ( current->domain == d )
+        return;
+
     mem_event_ring_lock(med);
-    med->req_producers--;
+    med->foreign_producers--;
     mem_event_ring_unlock(med);
 }
 
+/**
+ * mem_event_check_ring - Check state of a mem_event ring
+ * @d: guest domain
+ * @med: mem_event ring
+ *
+ * Return codes: < 0: the ring is not yet configured
+ *                 0: the ring has some room
+ *               > 0: the ring is full
+ *
+ * mem_event_check_ring() checks the state of the given mem_event ring.
+ * If the current vcpu belongs to the guest domain, the function assumes that
+ * mem_event_put_request() will sleep until the ring has room again.
+ *
+ * If the current vcpu does not belong to the target domain the caller must try
+ * again until there is room. A slot is claimed and the caller can place a
+ * request. If the caller does not need to send a request, the claimed slot has
+ * to be released with mem_event_put_req_producers().
+ */
 int mem_event_check_ring(struct domain *d, struct mem_event_domain *med)
 {
-    struct vcpu *curr = current;
     int free_requests;
     int ring_full = 1;
 
@@ -212,15 +312,15 @@ int mem_event_check_ring(struct domain *
     mem_event_ring_lock(med);
 
     free_requests = RING_FREE_REQUESTS(&med->front_ring);
-    if ( med->req_producers < free_requests )
+
+    if ( current->domain == d )
+        ring_full = 0;
+    else if ( med->foreign_producers < free_requests )
     {
-        med->req_producers++;
+        med->foreign_producers++;
         ring_full = 0;
     }
 
-    if ( ring_full && (curr->domain == d) )
-        mem_event_mark_and_pause(curr);
-
     mem_event_ring_unlock(med);
 
     return ring_full;
@@ -287,7 +387,7 @@ int mem_event_domctl(struct domain *d, x
             if ( p2m->pod.entry_count )
                 break;
 
-            rc = mem_event_enable(d, mec, med);
+            rc = mem_event_enable(d, mec, _VPF_mem_paging, med);
         }
         break;
 
@@ -326,7 +426,7 @@ int mem_event_domctl(struct domain *d, x
             if ( boot_cpu_data.x86_vendor != X86_VENDOR_INTEL )
                 break;
 
-            rc = mem_event_enable(d, mec, med);
+            rc = mem_event_enable(d, mec, _VPF_mem_access, med);
         }
         break;
 
diff -r 3c4c29899d8a -r 612f69531fd1 xen/arch/x86/mm/mem_sharing.c
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -253,19 +253,11 @@ static void mem_sharing_audit(void)
 #endif
 
 
-static struct page_info* mem_sharing_alloc_page(struct domain *d, 
-                                                unsigned long gfn)
+static void mem_sharing_notify_helper(struct domain *d, unsigned long gfn)
 {
-    struct page_info* page;
     struct vcpu *v = current;
     mem_event_request_t req;
 
-    page = alloc_domheap_page(d, 0); 
-    if(page != NULL) return page;
-
-    memset(&req, 0, sizeof(req));
-    req.type = MEM_EVENT_TYPE_SHARED;
-
     if ( v->domain != d )
     {
         /* XXX This path needs some attention.  For now, just fail foreign 
@@ -275,20 +267,20 @@ static struct page_info* mem_sharing_all
         gdprintk(XENLOG_ERR, 
                  "Failed alloc on unshare path for foreign (%d) lookup\n",
                  d->domain_id);
-        return page;
+        return;
     }
 
-    vcpu_pause_nosync(v);
-    req.flags |= MEM_EVENT_FLAG_VCPU_PAUSED;
+    if (mem_event_check_ring(d, &d->mem_event->share) < 0)
+        return;
 
-    if(mem_event_check_ring(d, &d->mem_event->share)) return page;
-
+    memset(&req, 0, sizeof(req));
+    req.type = MEM_EVENT_TYPE_SHARED;
+    req.flags = MEM_EVENT_FLAG_VCPU_PAUSED;
     req.gfn = gfn;
     req.p2mt = p2m_ram_shared;
     req.vcpu_id = v->vcpu_id;
     mem_event_put_request(d, &d->mem_event->share, &req);
-
-    return page;
+    vcpu_pause_nosync(v);
 }
 
 unsigned int mem_sharing_get_nr_saved_mfns(void)
@@ -653,7 +645,7 @@ gfn_found:
     if(ret == 0) goto private_page_found;
         
     old_page = page;
-    page = mem_sharing_alloc_page(d, gfn);
+    page = alloc_domheap_page(d, 0); 
     if(!page) 
     {
         /* We've failed to obtain memory for private page. Need to re-add the
@@ -661,6 +653,7 @@ gfn_found:
         list_add(&gfn_info->list, &hash_entry->gfns);
         put_gfn(d, gfn);
         shr_unlock();
+        mem_sharing_notify_helper(d, gfn);
         return -ENOMEM;
     }
 
diff -r 3c4c29899d8a -r 612f69531fd1 xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -882,20 +882,12 @@ int p2m_mem_paging_evict(struct domain *
  */
 void p2m_mem_paging_drop_page(struct domain *d, unsigned long gfn)
 {
-    struct vcpu *v = current;
-    mem_event_request_t req;
+    mem_event_request_t req = { .type = MEM_EVENT_TYPE_PAGING, .gfn = gfn };
 
-    /* Check that there's space on the ring for this request */
-    if ( mem_event_check_ring(d, &d->mem_event->paging) == 0)
-    {
-        /* Send release notification to pager */
-        memset(&req, 0, sizeof(req));
-        req.flags |= MEM_EVENT_FLAG_DROP_PAGE;
-        req.gfn = gfn;
-        req.vcpu_id = v->vcpu_id;
+    /* Send release notification to pager */
+    req.flags = MEM_EVENT_FLAG_DROP_PAGE;
 
-        mem_event_put_request(d, &d->mem_event->paging, &req);
-    }
+    mem_event_put_request(d, &d->mem_event->paging, &req);
 }
 
 /**
@@ -960,7 +952,7 @@ void p2m_mem_paging_populate(struct doma
     else if ( p2mt != p2m_ram_paging_out && p2mt != p2m_ram_paged )
     {
         /* gfn is already on its way back and vcpu is not paused */
-        mem_event_put_req_producers(&d->mem_event->paging);
+        mem_event_put_req_producers(d, &d->mem_event->paging);
         return;
     }
 
@@ -1074,8 +1066,8 @@ void p2m_mem_paging_resume(struct domain
     if ( rsp.flags & MEM_EVENT_FLAG_VCPU_PAUSED )
         vcpu_unpause(d->vcpu[rsp.vcpu_id]);
 
-    /* Unpause any domains that were paused because the ring was full */
-    mem_event_unpause_vcpus(d);
+    /* Wake vcpus waiting for room in the ring */
+    mem_event_wake_requesters(&d->mem_event->paging);
 }
 
 void p2m_mem_access_check(unsigned long gpa, bool_t gla_valid, unsigned long gla, 
@@ -1114,7 +1106,7 @@ void p2m_mem_access_check(unsigned long 
                    "Memory access permissions failure, no mem_event listener: pausing VCPU %d, dom %d\n",
                    v->vcpu_id, d->domain_id);
 
-            mem_event_mark_and_pause(v);
+            mem_event_mark_and_sleep(v, &d->mem_event->access);
         }
         else
         {
@@ -1135,7 +1127,7 @@ void p2m_mem_access_check(unsigned long 
 
     /* Pause the current VCPU unconditionally */
     vcpu_pause_nosync(v);
-    req.flags |= MEM_EVENT_FLAG_VCPU_PAUSED;    
+    req.flags = MEM_EVENT_FLAG_VCPU_PAUSED;    
 
     /* Send request to mem event */
     req.gfn = gfn;
@@ -1164,9 +1156,11 @@ void p2m_mem_access_resume(struct p2m_do
     if ( rsp.flags & MEM_EVENT_FLAG_VCPU_PAUSED )
         vcpu_unpause(d->vcpu[rsp.vcpu_id]);
 
-    /* Unpause any domains that were paused because the ring was full or no listener 
-     * was available */
-    mem_event_unpause_vcpus(d);
+    /* Wake vcpus waiting for room in the ring */
+    mem_event_wake_requesters(&d->mem_event->access);
+
+    /* Unpause all vcpus that were paused because no listener was available */
+    mem_event_wake_waiters(d, &d->mem_event->access);
 }
 
 
diff -r 3c4c29899d8a -r 612f69531fd1 xen/include/asm-x86/mem_event.h
--- a/xen/include/asm-x86/mem_event.h
+++ b/xen/include/asm-x86/mem_event.h
@@ -24,13 +24,13 @@
 #ifndef __MEM_EVENT_H__
 #define __MEM_EVENT_H__
 
-/* Pauses VCPU while marking pause flag for mem event */
-void mem_event_mark_and_pause(struct vcpu *v);
 int mem_event_check_ring(struct domain *d, struct mem_event_domain *med);
-void mem_event_put_req_producers(struct mem_event_domain *med);
+void mem_event_put_req_producers(struct domain *d, struct mem_event_domain *med);
 void mem_event_put_request(struct domain *d, struct mem_event_domain *med, mem_event_request_t *req);
 void mem_event_get_response(struct mem_event_domain *med, mem_event_response_t *rsp);
-void mem_event_unpause_vcpus(struct domain *d);
+void mem_event_wake_requesters(struct mem_event_domain *med);
+void mem_event_wake_waiters(struct domain *d, struct mem_event_domain *med);
+void mem_event_mark_and_sleep(struct vcpu *v, struct mem_event_domain *med);
 
 int mem_event_domctl(struct domain *d, xen_domctl_mem_event_op_t *mec,
                      XEN_GUEST_HANDLE(void) u_domctl);
diff -r 3c4c29899d8a -r 612f69531fd1 xen/include/xen/sched.h
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -14,6 +14,7 @@
 #include <xen/nodemask.h>
 #include <xen/radix-tree.h>
 #include <xen/multicall.h>
+#include <xen/wait.h>
 #include <public/xen.h>
 #include <public/domctl.h>
 #include <public/sysctl.h>
@@ -183,7 +184,7 @@ struct mem_event_domain
 {
     /* ring lock */
     spinlock_t ring_lock;
-    unsigned int req_producers;
+    unsigned int foreign_producers;
     /* shared page */
     mem_event_shared_page_t *shared_page;
     /* shared ring page */
@@ -192,6 +193,10 @@ struct mem_event_domain
     mem_event_front_ring_t front_ring;
     /* event channel port (vcpu0 only) */
     int xen_port;
+    /* mem_event bit for vcpu->pause_flags */
+    int bit;
+    /* list of vcpus waiting for room in the ring */
+    struct waitqueue_head wq;
 };
 
 struct mem_event_per_domain
@@ -615,9 +620,12 @@ static inline struct domain *next_domain
  /* VCPU affinity has changed: migrating to a new CPU. */
 #define _VPF_migrating       3
 #define VPF_migrating        (1UL<<_VPF_migrating)
- /* VCPU is blocked on memory-event ring. */
-#define _VPF_mem_event       4
-#define VPF_mem_event        (1UL<<_VPF_mem_event)
+ /* VCPU is blocked due to missing mem_paging ring. */
+#define _VPF_mem_paging      4
+#define VPF_mem_paging       (1UL<<_VPF_mem_paging)
+ /* VCPU is blocked due to missing mem_access ring. */
+#define _VPF_mem_access      5
+#define VPF_mem_access       (1UL<<_VPF_mem_access)
 
 static inline int vcpu_runnable(struct vcpu *v)
 {

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 12:22:43 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 12:22:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW5ei-00076D-UC; Thu, 01 Dec 2011 12:22:24 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RW5eg-00075i-Bs
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 12:22:23 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-11.tower-216.messagelabs.com!1322742097!5704704!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNDUxMTM=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNDUxMTM=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21588 invoked from network); 1 Dec 2011 12:21:41 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-11.tower-216.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 1 Dec 2011 12:21:41 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1322742097; l=15992;
	s=domk; d=aepfle.de;
	h=To:From:Date:References:In-Reply-To:Subject:
	Content-Transfer-Encoding:MIME-Version:Content-Type:X-RZG-CLASS-ID:
	X-RZG-AUTH; bh=2phNJUsXOnJ84zIkaza8VA8hq1c=;
	b=C/RVfsq0gXvJIsYYNYgD51o/IFDT9hCnjIO+uIzOo6T2EfimrYOVh0uGKGA4zyj+Sd2
	bBHHxfseVA/Sn27dzEevmn9qIbvOifbPV3i24TmYXvuoSdciwA9/1gcX8BCokfhp8vYnM
	7+pgeL8yGDHee3De3ukgEBdI3O7m9azYFwM=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/ll2c7pE6jG
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-080-213.pools.arcor-ip.net [84.57.80.213])
	by smtp.strato.de (klopstock mo3) (RZmta 26.10 AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id g0470enB1BxpLY
	for <xen-devel@lists.xensource.com>;
	Thu, 1 Dec 2011 13:21:27 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id AC30318637
	for <xen-devel@lists.xensource.com>;
	Thu,  1 Dec 2011 13:21:26 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 612f69531fd15cf59c58404f6e4762733a9a268c
Message-Id: <612f69531fd15cf59c58.1322737757@probook.site>
In-Reply-To: <patchbomb.1322737756@probook.site>
References: <patchbomb.1322737756@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Thu, 01 Dec 2011 12:09:17 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 1 of 4] mem_event: use wait queue when ring is
	full
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1322736732 -3600
# Node ID 612f69531fd15cf59c58404f6e4762733a9a268c
# Parent  3c4c29899d8a2a0c0f9109b7236da95bb72b77b6
mem_event: use wait queue when ring is full

This change is based on an idea/patch from Adin Scannell.

If the ring is full, put the current vcpu to sleep if it belongs to the
target domain. The wakeup happens in the p2m_*_resume functions. Wakeup
will take the number of free slots into account.

A request from another domain will use the existing ->req_producers
functionality because sleeping is not possible if the vcpu does not
belong to the target domain.

This change fixes also a bug in p2m_mem_paging_drop_page(). Up to now a
full ring will lead to harmless inconsistency in the pager.

v4:
 - fix off-by-one bug in _mem_event_put_request
 - add mem_event_wake_requesters() and use wake_up_nr()
 - rename mem_event_mark_and_pause() and mem_event_mark_and_pause() functions
 - req_producers counts foreign request producers, rename member

v3:
 - rename ->mem_event_bit to ->bit
 - remove me_ from new VPF_ defines

v2:
 - p2m_mem_paging_populate: move vcpu_pause after put_request, otherwise the
   vcpu will not wake_up after a wait_event because the pause_count was
   increased twice. Fixes guest hangs.
 - update free space check in _mem_event_put_request()
 - simplify mem_event_put_request()

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 3c4c29899d8a -r 612f69531fd1 xen/arch/x86/hvm/hvm.c
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -4107,7 +4107,7 @@ static int hvm_memory_event_traps(long p
         return 1;
     
     rc = mem_event_check_ring(d, &d->mem_event->access);
-    if ( rc )
+    if ( rc < 0 )
         return rc;
     
     memset(&req, 0, sizeof(req));
diff -r 3c4c29899d8a -r 612f69531fd1 xen/arch/x86/mm/mem_event.c
--- a/xen/arch/x86/mm/mem_event.c
+++ b/xen/arch/x86/mm/mem_event.c
@@ -23,6 +23,7 @@
 
 #include <asm/domain.h>
 #include <xen/event.h>
+#include <xen/wait.h>
 #include <asm/p2m.h>
 #include <asm/mem_event.h>
 #include <asm/mem_paging.h>
@@ -39,6 +40,7 @@
 
 static int mem_event_enable(struct domain *d,
                             xen_domctl_mem_event_op_t *mec,
+                            int bit,
                             struct mem_event_domain *med)
 {
     int rc;
@@ -107,8 +109,12 @@ static int mem_event_enable(struct domai
 
     mem_event_ring_lock_init(med);
 
+    med->bit = bit;
+
+    init_waitqueue_head(&med->wq);
+
     /* Wake any VCPUs paused for memory events */
-    mem_event_unpause_vcpus(d);
+    mem_event_wake_waiters(d, med);
 
     return 0;
 
@@ -124,6 +130,9 @@ static int mem_event_enable(struct domai
 
 static int mem_event_disable(struct mem_event_domain *med)
 {
+    if (!list_empty(&med->wq.list))
+        return -EBUSY;
+
     unmap_domain_page(med->ring_page);
     med->ring_page = NULL;
 
@@ -133,13 +142,23 @@ static int mem_event_disable(struct mem_
     return 0;
 }
 
-void mem_event_put_request(struct domain *d, struct mem_event_domain *med, mem_event_request_t *req)
+static int _mem_event_put_request(struct domain *d,
+                                  struct mem_event_domain *med,
+                                  mem_event_request_t *req)
 {
     mem_event_front_ring_t *front_ring;
+    int free_requests;
     RING_IDX req_prod;
 
     mem_event_ring_lock(med);
 
+    free_requests = RING_FREE_REQUESTS(&med->front_ring);
+    /* Requests from foreign domain were claimed in mem_event_check_ring() */
+    if ((current->domain == d && free_requests < med->foreign_producers) || !free_requests) {
+        mem_event_ring_unlock(med);
+        return 0;
+    }
+
     front_ring = &med->front_ring;
     req_prod = front_ring->req_prod_pvt;
 
@@ -148,13 +167,30 @@ void mem_event_put_request(struct domain
     req_prod++;
 
     /* Update ring */
-    med->req_producers--;
+    if (current->domain != d)
+        med->foreign_producers--;
     front_ring->req_prod_pvt = req_prod;
     RING_PUSH_REQUESTS(front_ring);
 
     mem_event_ring_unlock(med);
 
     notify_via_xen_event_channel(d, med->xen_port);
+
+    return 1;
+}
+
+void mem_event_put_request(struct domain *d, struct mem_event_domain *med,
+                           mem_event_request_t *req)
+{
+    /* Go to sleep if request came from guest */
+    if (current->domain == d) {
+        wait_event(med->wq, _mem_event_put_request(d, med, req));
+        return;
+    }
+    /* Ring was full anyway, unable to sleep in non-guest context */
+    if (!_mem_event_put_request(d, med, req))
+        printk("Failed to put memreq: d %u t %x f %x gfn %lx\n", d->domain_id,
+                req->type, req->flags, (unsigned long)req->gfn);
 }
 
 void mem_event_get_response(struct mem_event_domain *med, mem_event_response_t *rsp)
@@ -178,31 +214,95 @@ void mem_event_get_response(struct mem_e
     mem_event_ring_unlock(med);
 }
 
-void mem_event_unpause_vcpus(struct domain *d)
+/**
+ * mem_event_wake_requesters - Wake vcpus waiting for room in the ring
+ * @d: guest domain
+ * @med: mem_event ring
+ *
+ * mem_event_wake_requesters() will wakeup vcpus waiting for room in the
+ * ring. Only as many as can place another request in the ring will
+ * resume execution.
+ */
+void mem_event_wake_requesters(struct mem_event_domain *med)
+{
+    int free_requests;
+
+    mem_event_ring_lock(med);
+
+    free_requests = RING_FREE_REQUESTS(&med->front_ring);
+    if ( free_requests )
+        wake_up_nr(&med->wq, free_requests);
+
+    mem_event_ring_unlock(med);
+}
+
+/**
+ * mem_event_wake_waiters - Wake all vcpus waiting for the ring
+ * @d: guest domain
+ * @med: mem_event ring
+ *
+ * mem_event_wake_waiters() will wakeup all vcpus waiting for the ring to 
+ * become available.
+ */
+void mem_event_wake_waiters(struct domain *d, struct mem_event_domain *med)
 {
     struct vcpu *v;
 
     for_each_vcpu ( d, v )
-        if ( test_and_clear_bit(_VPF_mem_event, &v->pause_flags) )
+        if ( test_and_clear_bit(med->bit, &v->pause_flags) )
             vcpu_wake(v);
 }
 
-void mem_event_mark_and_pause(struct vcpu *v)
+/**
+ * mem_event_mark_and_sleep - Put vcpu to sleep
+ * @v: guest vcpu
+ * @med: mem_event ring
+ *
+ * mem_event_mark_and_sleep() tags vcpu and put it to sleep.
+ * The vcpu will resume execution in mem_event_wake_waiters().
+ */
+void mem_event_mark_and_sleep(struct vcpu *v, struct mem_event_domain *med)
 {
-    set_bit(_VPF_mem_event, &v->pause_flags);
+    set_bit(med->bit, &v->pause_flags);
     vcpu_sleep_nosync(v);
 }
 
-void mem_event_put_req_producers(struct mem_event_domain *med)
+/**
+ * mem_event_put_req_producers - Release a claimed slot
+ * @med: mem_event ring
+ *
+ * mem_event_put_req_producers() releases a claimed slot in the mem_event ring.
+ */
+void mem_event_put_req_producers(struct domain *d, struct mem_event_domain *med)
 {
+    if ( current->domain == d )
+        return;
+
     mem_event_ring_lock(med);
-    med->req_producers--;
+    med->foreign_producers--;
     mem_event_ring_unlock(med);
 }
 
+/**
+ * mem_event_check_ring - Check state of a mem_event ring
+ * @d: guest domain
+ * @med: mem_event ring
+ *
+ * Return codes: < 0: the ring is not yet configured
+ *                 0: the ring has some room
+ *               > 0: the ring is full
+ *
+ * mem_event_check_ring() checks the state of the given mem_event ring.
+ * If the current vcpu belongs to the guest domain, the function assumes that
+ * mem_event_put_request() will sleep until the ring has room again.
+ *
+ * If the current vcpu does not belong to the target domain the caller must try
+ * again until there is room. A slot is claimed and the caller can place a
+ * request. If the caller does not need to send a request, the claimed slot has
+ * to be released with mem_event_put_req_producers().
+ */
 int mem_event_check_ring(struct domain *d, struct mem_event_domain *med)
 {
-    struct vcpu *curr = current;
     int free_requests;
     int ring_full = 1;
 
@@ -212,15 +312,15 @@ int mem_event_check_ring(struct domain *
     mem_event_ring_lock(med);
 
     free_requests = RING_FREE_REQUESTS(&med->front_ring);
-    if ( med->req_producers < free_requests )
+
+    if ( current->domain == d )
+        ring_full = 0;
+    else if ( med->foreign_producers < free_requests )
     {
-        med->req_producers++;
+        med->foreign_producers++;
         ring_full = 0;
     }
 
-    if ( ring_full && (curr->domain == d) )
-        mem_event_mark_and_pause(curr);
-
     mem_event_ring_unlock(med);
 
     return ring_full;
@@ -287,7 +387,7 @@ int mem_event_domctl(struct domain *d, x
             if ( p2m->pod.entry_count )
                 break;
 
-            rc = mem_event_enable(d, mec, med);
+            rc = mem_event_enable(d, mec, _VPF_mem_paging, med);
         }
         break;
 
@@ -326,7 +426,7 @@ int mem_event_domctl(struct domain *d, x
             if ( boot_cpu_data.x86_vendor != X86_VENDOR_INTEL )
                 break;
 
-            rc = mem_event_enable(d, mec, med);
+            rc = mem_event_enable(d, mec, _VPF_mem_access, med);
         }
         break;
 
diff -r 3c4c29899d8a -r 612f69531fd1 xen/arch/x86/mm/mem_sharing.c
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -253,19 +253,11 @@ static void mem_sharing_audit(void)
 #endif
 
 
-static struct page_info* mem_sharing_alloc_page(struct domain *d, 
-                                                unsigned long gfn)
+static void mem_sharing_notify_helper(struct domain *d, unsigned long gfn)
 {
-    struct page_info* page;
     struct vcpu *v = current;
     mem_event_request_t req;
 
-    page = alloc_domheap_page(d, 0); 
-    if(page != NULL) return page;
-
-    memset(&req, 0, sizeof(req));
-    req.type = MEM_EVENT_TYPE_SHARED;
-
     if ( v->domain != d )
     {
         /* XXX This path needs some attention.  For now, just fail foreign 
@@ -275,20 +267,20 @@ static struct page_info* mem_sharing_all
         gdprintk(XENLOG_ERR, 
                  "Failed alloc on unshare path for foreign (%d) lookup\n",
                  d->domain_id);
-        return page;
+        return;
     }
 
-    vcpu_pause_nosync(v);
-    req.flags |= MEM_EVENT_FLAG_VCPU_PAUSED;
+    if (mem_event_check_ring(d, &d->mem_event->share) < 0)
+        return;
 
-    if(mem_event_check_ring(d, &d->mem_event->share)) return page;
-
+    memset(&req, 0, sizeof(req));
+    req.type = MEM_EVENT_TYPE_SHARED;
+    req.flags = MEM_EVENT_FLAG_VCPU_PAUSED;
     req.gfn = gfn;
     req.p2mt = p2m_ram_shared;
     req.vcpu_id = v->vcpu_id;
     mem_event_put_request(d, &d->mem_event->share, &req);
-
-    return page;
+    vcpu_pause_nosync(v);
 }
 
 unsigned int mem_sharing_get_nr_saved_mfns(void)
@@ -653,7 +645,7 @@ gfn_found:
     if(ret == 0) goto private_page_found;
         
     old_page = page;
-    page = mem_sharing_alloc_page(d, gfn);
+    page = alloc_domheap_page(d, 0); 
     if(!page) 
     {
         /* We've failed to obtain memory for private page. Need to re-add the
@@ -661,6 +653,7 @@ gfn_found:
         list_add(&gfn_info->list, &hash_entry->gfns);
         put_gfn(d, gfn);
         shr_unlock();
+        mem_sharing_notify_helper(d, gfn);
         return -ENOMEM;
     }
 
diff -r 3c4c29899d8a -r 612f69531fd1 xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -882,20 +882,12 @@ int p2m_mem_paging_evict(struct domain *
  */
 void p2m_mem_paging_drop_page(struct domain *d, unsigned long gfn)
 {
-    struct vcpu *v = current;
-    mem_event_request_t req;
+    mem_event_request_t req = { .type = MEM_EVENT_TYPE_PAGING, .gfn = gfn };
 
-    /* Check that there's space on the ring for this request */
-    if ( mem_event_check_ring(d, &d->mem_event->paging) == 0)
-    {
-        /* Send release notification to pager */
-        memset(&req, 0, sizeof(req));
-        req.flags |= MEM_EVENT_FLAG_DROP_PAGE;
-        req.gfn = gfn;
-        req.vcpu_id = v->vcpu_id;
+    /* Send release notification to pager */
+    req.flags = MEM_EVENT_FLAG_DROP_PAGE;
 
-        mem_event_put_request(d, &d->mem_event->paging, &req);
-    }
+    mem_event_put_request(d, &d->mem_event->paging, &req);
 }
 
 /**
@@ -960,7 +952,7 @@ void p2m_mem_paging_populate(struct doma
     else if ( p2mt != p2m_ram_paging_out && p2mt != p2m_ram_paged )
     {
         /* gfn is already on its way back and vcpu is not paused */
-        mem_event_put_req_producers(&d->mem_event->paging);
+        mem_event_put_req_producers(d, &d->mem_event->paging);
         return;
     }
 
@@ -1074,8 +1066,8 @@ void p2m_mem_paging_resume(struct domain
     if ( rsp.flags & MEM_EVENT_FLAG_VCPU_PAUSED )
         vcpu_unpause(d->vcpu[rsp.vcpu_id]);
 
-    /* Unpause any domains that were paused because the ring was full */
-    mem_event_unpause_vcpus(d);
+    /* Wake vcpus waiting for room in the ring */
+    mem_event_wake_requesters(&d->mem_event->paging);
 }
 
 void p2m_mem_access_check(unsigned long gpa, bool_t gla_valid, unsigned long gla, 
@@ -1114,7 +1106,7 @@ void p2m_mem_access_check(unsigned long 
                    "Memory access permissions failure, no mem_event listener: pausing VCPU %d, dom %d\n",
                    v->vcpu_id, d->domain_id);
 
-            mem_event_mark_and_pause(v);
+            mem_event_mark_and_sleep(v, &d->mem_event->access);
         }
         else
         {
@@ -1135,7 +1127,7 @@ void p2m_mem_access_check(unsigned long 
 
     /* Pause the current VCPU unconditionally */
     vcpu_pause_nosync(v);
-    req.flags |= MEM_EVENT_FLAG_VCPU_PAUSED;    
+    req.flags = MEM_EVENT_FLAG_VCPU_PAUSED;    
 
     /* Send request to mem event */
     req.gfn = gfn;
@@ -1164,9 +1156,11 @@ void p2m_mem_access_resume(struct p2m_do
     if ( rsp.flags & MEM_EVENT_FLAG_VCPU_PAUSED )
         vcpu_unpause(d->vcpu[rsp.vcpu_id]);
 
-    /* Unpause any domains that were paused because the ring was full or no listener 
-     * was available */
-    mem_event_unpause_vcpus(d);
+    /* Wake vcpus waiting for room in the ring */
+    mem_event_wake_requesters(&d->mem_event->access);
+
+    /* Unpause all vcpus that were paused because no listener was available */
+    mem_event_wake_waiters(d, &d->mem_event->access);
 }
 
 
diff -r 3c4c29899d8a -r 612f69531fd1 xen/include/asm-x86/mem_event.h
--- a/xen/include/asm-x86/mem_event.h
+++ b/xen/include/asm-x86/mem_event.h
@@ -24,13 +24,13 @@
 #ifndef __MEM_EVENT_H__
 #define __MEM_EVENT_H__
 
-/* Pauses VCPU while marking pause flag for mem event */
-void mem_event_mark_and_pause(struct vcpu *v);
 int mem_event_check_ring(struct domain *d, struct mem_event_domain *med);
-void mem_event_put_req_producers(struct mem_event_domain *med);
+void mem_event_put_req_producers(struct domain *d, struct mem_event_domain *med);
 void mem_event_put_request(struct domain *d, struct mem_event_domain *med, mem_event_request_t *req);
 void mem_event_get_response(struct mem_event_domain *med, mem_event_response_t *rsp);
-void mem_event_unpause_vcpus(struct domain *d);
+void mem_event_wake_requesters(struct mem_event_domain *med);
+void mem_event_wake_waiters(struct domain *d, struct mem_event_domain *med);
+void mem_event_mark_and_sleep(struct vcpu *v, struct mem_event_domain *med);
 
 int mem_event_domctl(struct domain *d, xen_domctl_mem_event_op_t *mec,
                      XEN_GUEST_HANDLE(void) u_domctl);
diff -r 3c4c29899d8a -r 612f69531fd1 xen/include/xen/sched.h
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -14,6 +14,7 @@
 #include <xen/nodemask.h>
 #include <xen/radix-tree.h>
 #include <xen/multicall.h>
+#include <xen/wait.h>
 #include <public/xen.h>
 #include <public/domctl.h>
 #include <public/sysctl.h>
@@ -183,7 +184,7 @@ struct mem_event_domain
 {
     /* ring lock */
     spinlock_t ring_lock;
-    unsigned int req_producers;
+    unsigned int foreign_producers;
     /* shared page */
     mem_event_shared_page_t *shared_page;
     /* shared ring page */
@@ -192,6 +193,10 @@ struct mem_event_domain
     mem_event_front_ring_t front_ring;
     /* event channel port (vcpu0 only) */
     int xen_port;
+    /* mem_event bit for vcpu->pause_flags */
+    int bit;
+    /* list of vcpus waiting for room in the ring */
+    struct waitqueue_head wq;
 };
 
 struct mem_event_per_domain
@@ -615,9 +620,12 @@ static inline struct domain *next_domain
  /* VCPU affinity has changed: migrating to a new CPU. */
 #define _VPF_migrating       3
 #define VPF_migrating        (1UL<<_VPF_migrating)
- /* VCPU is blocked on memory-event ring. */
-#define _VPF_mem_event       4
-#define VPF_mem_event        (1UL<<_VPF_mem_event)
+ /* VCPU is blocked due to missing mem_paging ring. */
+#define _VPF_mem_paging      4
+#define VPF_mem_paging       (1UL<<_VPF_mem_paging)
+ /* VCPU is blocked due to missing mem_access ring. */
+#define _VPF_mem_access      5
+#define VPF_mem_access       (1UL<<_VPF_mem_access)
 
 static inline int vcpu_runnable(struct vcpu *v)
 {

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 12:22:44 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 12:22:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW5ek-00076t-Aw; Thu, 01 Dec 2011 12:22:26 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RW5ei-00075l-Vq
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 12:22:25 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-13.tower-21.messagelabs.com!1322742104!4555645!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNDUxMTM=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNDUxMTM=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9327 invoked from network); 1 Dec 2011 12:21:45 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-13.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 1 Dec 2011 12:21:45 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1322742104; l=11437;
	s=domk; d=aepfle.de;
	h=To:From:Date:References:In-Reply-To:Subject:
	Content-Transfer-Encoding:MIME-Version:Content-Type:X-RZG-CLASS-ID:
	X-RZG-AUTH; bh=PhT1VihJ3nbq48GPvpu3CAvkyXQ=;
	b=MBgsToPK09tIA4y6QNmKfJygB4h3ML5zKX3cdJLYyMq7+GDajNPBLlZ8oqJPbZTBpGt
	L05ZQ3mq5TG2IFK1gT8DRyYbY7/Z3c56bXKsL9da782JavMWI9rB3eZHCGgM4XKk7TgPU
	QAx+cSrpODyTwKszwflfdjRo4nkLu1DDW3M=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/ll2c7pE6jG
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-080-213.pools.arcor-ip.net [84.57.80.213])
	by smtp.strato.de (jimi mo30) (RZmta 26.10 AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id n0439anB1BHhzL
	for <xen-devel@lists.xensource.com>;
	Thu, 1 Dec 2011 13:21:27 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id DB93C18638
	for <xen-devel@lists.xensource.com>;
	Thu,  1 Dec 2011 13:21:26 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 8147822efdee65d1f5b94656ab2032aedb76979f
Message-Id: <8147822efdee65d1f5b9.1322737758@probook.site>
In-Reply-To: <patchbomb.1322737756@probook.site>
References: <patchbomb.1322737756@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Thu, 01 Dec 2011 12:09:18 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 2 of 4] xenpaging: use wait queues
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1322737507 -3600
# Node ID 8147822efdee65d1f5b94656ab2032aedb76979f
# Parent  612f69531fd15cf59c58404f6e4762733a9a268c
xenpaging: use wait queues

Use a wait queue to put a guest vcpu to sleep while the requested gfn is
in paging state. This adds missing p2m_mem_paging_populate() calls to
some callers of the new get_gfn* variants, which would crash now
because they get an invalid mfn. It also fixes guest crashes due to
unexpected returns from do_memory_op because copy_to/from_guest ran into
a paged gfn. Now those places will always get a valid mfn.

Since each gfn could be requested by several guest vcpus at the same
time a queue of paged gfns is maintained. Each vcpu will be attached to
that queue. Once p2m_mem_paging_resume restored the gfn the waiting
vcpus will resume execution.

There is untested code in p2m_mem_paging_init_queue() to allow cpu
hotplug. Since each vcpu may wait on a different gfn there have to be as
many queues as vcpus. But xl vcpu-set does not seem to work right now,
so this code path cant be excercised right now.


Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 612f69531fd1 -r 8147822efdee xen/arch/x86/hvm/hvm.c
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -454,6 +454,8 @@ int hvm_domain_initialise(struct domain 
     spin_lock_init(&d->arch.hvm_domain.irq_lock);
     spin_lock_init(&d->arch.hvm_domain.uc_lock);
 
+    spin_lock_init(&d->arch.hvm_domain.gfn_lock);
+
     INIT_LIST_HEAD(&d->arch.hvm_domain.msixtbl_list);
     spin_lock_init(&d->arch.hvm_domain.msixtbl_list_lock);
 
diff -r 612f69531fd1 -r 8147822efdee xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -30,6 +30,7 @@
 #include <asm/p2m.h>
 #include <asm/hvm/vmx/vmx.h> /* ept_p2m_init() */
 #include <xen/iommu.h>
+#include <xen/wait.h>
 #include <asm/mem_event.h>
 #include <public/mem_event.h>
 #include <asm/mem_sharing.h>
@@ -144,6 +145,182 @@ void p2m_change_entry_type_global(struct
     p2m_unlock(p2m);
 }
 
+#ifdef __x86_64__
+struct p2m_mem_paging_queue {
+    struct list_head list;
+    struct waitqueue_head wq;
+    unsigned long gfn;
+    unsigned short waiters;
+    unsigned short woken;
+    unsigned short index;
+};
+
+struct p2m_mem_paging_queue_head {
+    struct list_head list;
+    unsigned int max;
+};
+
+int p2m_mem_paging_init_queue(struct domain *d, unsigned int max)
+{
+    struct p2m_mem_paging_queue_head *h;
+    struct p2m_mem_paging_queue *q;
+    unsigned int i, nr;
+    int ret = 0;
+
+    spin_lock(&d->arch.hvm_domain.gfn_lock);
+
+    if (!d->arch.hvm_domain.gfn_queue) {
+        ret = -ENOMEM;
+        h = xzalloc(struct p2m_mem_paging_queue_head);
+        if (!h) {
+            domain_crash(d);
+            goto out;
+        }
+
+        INIT_LIST_HEAD(&h->list);
+        nr = max;
+    } else {
+        h = d->arch.hvm_domain.gfn_queue;
+        if (max <= h->max)
+            goto out;
+        nr = max - h->max;
+    }
+
+    ret = -ENOMEM;
+    q = xzalloc_array(struct p2m_mem_paging_queue, nr);
+    if (!q) {
+        if (!d->arch.hvm_domain.gfn_queue)
+            xfree(h);
+        domain_crash(d);
+        goto out;
+    }
+
+    for (i = 0; i < nr; i++) {
+        init_waitqueue_head(&q[i].wq);
+        INIT_LIST_HEAD(&q[i].list);
+        q[i].index = h->max + i + 1;
+        list_add_tail(&q[i].list, &h->list);
+    }
+
+    h->max = max;
+    d->arch.hvm_domain.gfn_queue = h;
+    ret = 0;
+
+out:
+    spin_unlock(&d->arch.hvm_domain.gfn_lock);
+    return ret;
+}
+
+static struct p2m_mem_paging_queue *p2m_mem_paging_get_queue(struct domain *d, unsigned long gfn)
+{
+    struct p2m_mem_paging_queue_head *h;
+    struct p2m_mem_paging_queue *q, *q_match, *q_free;
+    
+    h = d->arch.hvm_domain.gfn_queue;
+    q_match = q_free = NULL;
+
+    spin_lock(&d->arch.hvm_domain.gfn_lock);
+
+    list_for_each_entry(q, &h->list, list) {
+        if (q->gfn == gfn) {
+            q_match = q;
+            break;
+        }
+        if (!q_free && !q->waiters)
+            q_free = q;
+    }
+
+    if (!q_match && q_free)
+        q_match = q_free;
+
+    if (q_match) {
+        if (q_match->woken)
+            printk("wq woken for gfn %u:%u %lx %u %u %u\n", current->domain->domain_id, current->vcpu_id, gfn, q_match->index, q_match->woken, q_match->waiters);
+        q_match->waiters++;
+        q_match->gfn = gfn;
+    }
+
+    if (!q_match)
+        printk("No wq_get for gfn %u:%u %lx\n", current->domain->domain_id, current->vcpu_id, gfn);
+
+    spin_unlock(&d->arch.hvm_domain.gfn_lock);
+    return q_match;
+}
+
+static void p2m_mem_paging_put_queue(struct domain *d, struct p2m_mem_paging_queue *q_match)
+{
+    spin_lock(&d->arch.hvm_domain.gfn_lock);
+
+    if (q_match->waiters == 0)
+        printk("wq_put no waiters, gfn %u:%u %lx %u\n", current->domain->domain_id, current->vcpu_id, q_match->gfn, q_match->woken);
+    else if (--q_match->waiters == 0)
+        q_match->gfn = q_match->woken = 0;;
+
+    spin_unlock(&d->arch.hvm_domain.gfn_lock);
+}
+
+static void p2m_mem_paging_wake_queue(struct domain *d, unsigned long gfn)
+{
+    struct p2m_mem_paging_queue_head *h;
+    struct p2m_mem_paging_queue *q, *q_match = NULL;
+
+    spin_lock(&d->arch.hvm_domain.gfn_lock);
+
+    h = d->arch.hvm_domain.gfn_queue;
+    list_for_each_entry(q, &h->list, list) {
+        if (q->gfn == gfn) {
+            q_match = q;
+            break;
+        }
+    }
+    if (q_match) {
+        if (q_match->woken || q_match->waiters == 0)
+            printk("Wrong wake for gfn %u:%u %p %lx %u %u\n", current->domain->domain_id, current->vcpu_id, q_match, gfn, q_match->woken, q_match->waiters);
+        q_match->woken++;
+        wake_up_all(&q_match->wq);
+    }
+    spin_unlock(&d->arch.hvm_domain.gfn_lock);
+}
+
+/* Returns 0 if the gfn is still paged */
+static int p2m_mem_paging_get_entry(mfn_t *mfn,
+               struct p2m_domain *p2m, unsigned long gfn, 
+               p2m_type_t *t, p2m_access_t *a, p2m_query_t q,
+               unsigned int *page_order)
+{
+    *mfn = p2m->get_entry(p2m, gfn, t, a, q, page_order);
+
+    return p2m_is_paging(*t) ? 0 : 1;
+}
+
+/* Go to sleep in case of guest access */
+static void p2m_mem_paging_wait(mfn_t *mfn,
+                    struct p2m_domain *p2m, unsigned long gfn,
+                    p2m_type_t *t, p2m_access_t *a, p2m_query_t q,
+                    unsigned int *page_order)
+{
+    struct p2m_mem_paging_queue *pmpq;
+
+    /* Return p2mt as is in case of query */
+    if ( q == p2m_query )
+        return;
+    /* Foreign domains can not go to sleep */
+    if ( current->domain != p2m->domain )
+        return;
+
+    pmpq = p2m_mem_paging_get_queue(p2m->domain, gfn);
+    if ( !pmpq )
+        return;
+
+    /* Populate the page once */
+    if ( *t == p2m_ram_paging_out || *t == p2m_ram_paged )
+        p2m_mem_paging_populate(p2m->domain, gfn);
+
+    wait_event(pmpq->wq, p2m_mem_paging_get_entry(mfn, p2m, gfn, t, a, q, page_order));
+    p2m_mem_paging_put_queue(p2m->domain, pmpq);
+}
+#endif
+
 mfn_t get_gfn_type_access(struct p2m_domain *p2m, unsigned long gfn,
                     p2m_type_t *t, p2m_access_t *a, p2m_query_t q,
                     unsigned int *page_order)
@@ -161,6 +338,11 @@ mfn_t get_gfn_type_access(struct p2m_dom
     mfn = p2m->get_entry(p2m, gfn, t, a, q, page_order);
 
 #ifdef __x86_64__
+    if ( unlikely(p2m_is_paging(*t)) )
+        p2m_mem_paging_wait(&mfn, p2m, gfn, t, a, q, page_order);
+#endif
+
+#ifdef __x86_64__
     if ( q == p2m_unshare && p2m_is_shared(*t) )
     {
         ASSERT(!p2m_is_nestedp2m(p2m));
@@ -914,54 +1096,42 @@ void p2m_mem_paging_drop_page(struct dom
 void p2m_mem_paging_populate(struct domain *d, unsigned long gfn)
 {
     struct vcpu *v = current;
-    mem_event_request_t req;
+    mem_event_request_t req = { .type = MEM_EVENT_TYPE_PAGING, .gfn = gfn };
     p2m_type_t p2mt;
     p2m_access_t a;
     mfn_t mfn;
     struct p2m_domain *p2m = p2m_get_hostp2m(d);
+    int put_request = 0;
 
     /* Check that there's space on the ring for this request */
     if ( mem_event_check_ring(d, &d->mem_event->paging) )
         return;
 
-    memset(&req, 0, sizeof(req));
-    req.type = MEM_EVENT_TYPE_PAGING;
-
     /* Fix p2m mapping */
     p2m_lock(p2m);
     mfn = p2m->get_entry(p2m, gfn, &p2mt, &a, p2m_query, NULL);
-    /* Allow only nominated or evicted pages to enter page-in path */
-    if ( p2mt == p2m_ram_paging_out || p2mt == p2m_ram_paged )
-    {
-        /* Evict will fail now, tag this request for pager */
-        if ( p2mt == p2m_ram_paging_out )
-            req.flags |= MEM_EVENT_FLAG_EVICT_FAIL;
+    /* Forward the state only if gfn is in page-out path */
+    if ( p2mt == p2m_ram_paging_out || p2mt == p2m_ram_paged ) {
+        /* Ignore foreign requests to allow mmap in pager */
+        if ( mfn_valid(mfn) && p2mt == p2m_ram_paging_out && v->domain == d ) {
+            /* Restore gfn because it is needed by guest before evict */
+            set_p2m_entry(p2m, gfn, mfn, PAGE_ORDER_4K,
+                       paging_mode_log_dirty(d) ? p2m_ram_logdirty : p2m_ram_rw, a);
+        } else {
+            set_p2m_entry(p2m, gfn, mfn, PAGE_ORDER_4K, p2m_ram_paging_in_start, a);
+            put_request = 1;
+        }
+        /* Evict will fail now, the pager has to try another gfn */
 
-        set_p2m_entry(p2m, gfn, mfn, PAGE_ORDER_4K, p2m_ram_paging_in_start, a);
         audit_p2m(p2m, 1);
     }
     p2m_unlock(p2m);
 
-    /* Pause domain if request came from guest and gfn has paging type */
-    if (  p2m_is_paging(p2mt) && v->domain == d )
-    {
-        vcpu_pause_nosync(v);
-        req.flags |= MEM_EVENT_FLAG_VCPU_PAUSED;
-    }
-    /* No need to inform pager if the gfn is not in the page-out path */
-    else if ( p2mt != p2m_ram_paging_out && p2mt != p2m_ram_paged )
-    {
-        /* gfn is already on its way back and vcpu is not paused */
+    /* One request per gfn, guest vcpus go to sleep, foreigners try again */
+    if ( put_request )
+        mem_event_put_request(d, &d->mem_event->paging, &req);
+    else
         mem_event_put_req_producers(d, &d->mem_event->paging);
-        return;
-    }
-
-    /* Send request to pager */
-    req.gfn = gfn;
-    req.p2mt = p2mt;
-    req.vcpu_id = v->vcpu_id;
-
-    mem_event_put_request(d, &d->mem_event->paging, &req);
 }
 
 /**
@@ -1062,12 +1232,11 @@ void p2m_mem_paging_resume(struct domain
         p2m_unlock(p2m);
     }
 
-    /* Unpause domain */
-    if ( rsp.flags & MEM_EVENT_FLAG_VCPU_PAUSED )
-        vcpu_unpause(d->vcpu[rsp.vcpu_id]);
-
     /* Wake vcpus waiting for room in the ring */
     mem_event_wake_requesters(&d->mem_event->paging);
+
+    /* Unpause all vcpus that were paused because the gfn was paged */
+    p2m_mem_paging_wake_queue(d, rsp.gfn);
 }
 
 void p2m_mem_access_check(unsigned long gpa, bool_t gla_valid, unsigned long gla, 
diff -r 612f69531fd1 -r 8147822efdee xen/common/domctl.c
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -547,6 +547,9 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domc
                 goto maxvcpu_out;
         }
 
+        if ( p2m_mem_paging_init_queue(d, max) )
+            goto maxvcpu_out;
+
         ret = 0;
 
     maxvcpu_out:
diff -r 612f69531fd1 -r 8147822efdee xen/include/asm-x86/hvm/domain.h
--- a/xen/include/asm-x86/hvm/domain.h
+++ b/xen/include/asm-x86/hvm/domain.h
@@ -91,6 +91,9 @@ struct hvm_domain {
 
     struct viridian_domain viridian;
 
+    spinlock_t                        gfn_lock;
+    struct p2m_mem_paging_queue_head *gfn_queue;
+
     bool_t                 hap_enabled;
     bool_t                 mem_sharing_enabled;
     bool_t                 qemu_mapcache_invalidate;
diff -r 612f69531fd1 -r 8147822efdee xen/include/asm-x86/p2m.h
--- a/xen/include/asm-x86/p2m.h
+++ b/xen/include/asm-x86/p2m.h
@@ -468,6 +468,8 @@ p2m_pod_offline_or_broken_replace(struct
 /* Modify p2m table for shared gfn */
 int set_shared_p2m_entry(struct domain *d, unsigned long gfn, mfn_t mfn);
 
+/* Initialize per-gfn wait queue */
+int p2m_mem_paging_init_queue(struct domain *d, unsigned int max);
 /* Check if a nominated gfn is valid to be paged out */
 int p2m_mem_paging_nominate(struct domain *d, unsigned long gfn);
 /* Evict a frame */

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 12:22:44 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 12:22:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW5ek-00076t-Aw; Thu, 01 Dec 2011 12:22:26 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RW5ei-00075l-Vq
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 12:22:25 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-13.tower-21.messagelabs.com!1322742104!4555645!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNDUxMTM=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNDUxMTM=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9327 invoked from network); 1 Dec 2011 12:21:45 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-13.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 1 Dec 2011 12:21:45 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1322742104; l=11437;
	s=domk; d=aepfle.de;
	h=To:From:Date:References:In-Reply-To:Subject:
	Content-Transfer-Encoding:MIME-Version:Content-Type:X-RZG-CLASS-ID:
	X-RZG-AUTH; bh=PhT1VihJ3nbq48GPvpu3CAvkyXQ=;
	b=MBgsToPK09tIA4y6QNmKfJygB4h3ML5zKX3cdJLYyMq7+GDajNPBLlZ8oqJPbZTBpGt
	L05ZQ3mq5TG2IFK1gT8DRyYbY7/Z3c56bXKsL9da782JavMWI9rB3eZHCGgM4XKk7TgPU
	QAx+cSrpODyTwKszwflfdjRo4nkLu1DDW3M=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/ll2c7pE6jG
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-080-213.pools.arcor-ip.net [84.57.80.213])
	by smtp.strato.de (jimi mo30) (RZmta 26.10 AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id n0439anB1BHhzL
	for <xen-devel@lists.xensource.com>;
	Thu, 1 Dec 2011 13:21:27 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id DB93C18638
	for <xen-devel@lists.xensource.com>;
	Thu,  1 Dec 2011 13:21:26 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 8147822efdee65d1f5b94656ab2032aedb76979f
Message-Id: <8147822efdee65d1f5b9.1322737758@probook.site>
In-Reply-To: <patchbomb.1322737756@probook.site>
References: <patchbomb.1322737756@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Thu, 01 Dec 2011 12:09:18 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 2 of 4] xenpaging: use wait queues
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1322737507 -3600
# Node ID 8147822efdee65d1f5b94656ab2032aedb76979f
# Parent  612f69531fd15cf59c58404f6e4762733a9a268c
xenpaging: use wait queues

Use a wait queue to put a guest vcpu to sleep while the requested gfn is
in paging state. This adds missing p2m_mem_paging_populate() calls to
some callers of the new get_gfn* variants, which would crash now
because they get an invalid mfn. It also fixes guest crashes due to
unexpected returns from do_memory_op because copy_to/from_guest ran into
a paged gfn. Now those places will always get a valid mfn.

Since each gfn could be requested by several guest vcpus at the same
time a queue of paged gfns is maintained. Each vcpu will be attached to
that queue. Once p2m_mem_paging_resume restored the gfn the waiting
vcpus will resume execution.

There is untested code in p2m_mem_paging_init_queue() to allow cpu
hotplug. Since each vcpu may wait on a different gfn there have to be as
many queues as vcpus. But xl vcpu-set does not seem to work right now,
so this code path cant be excercised right now.


Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 612f69531fd1 -r 8147822efdee xen/arch/x86/hvm/hvm.c
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -454,6 +454,8 @@ int hvm_domain_initialise(struct domain 
     spin_lock_init(&d->arch.hvm_domain.irq_lock);
     spin_lock_init(&d->arch.hvm_domain.uc_lock);
 
+    spin_lock_init(&d->arch.hvm_domain.gfn_lock);
+
     INIT_LIST_HEAD(&d->arch.hvm_domain.msixtbl_list);
     spin_lock_init(&d->arch.hvm_domain.msixtbl_list_lock);
 
diff -r 612f69531fd1 -r 8147822efdee xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -30,6 +30,7 @@
 #include <asm/p2m.h>
 #include <asm/hvm/vmx/vmx.h> /* ept_p2m_init() */
 #include <xen/iommu.h>
+#include <xen/wait.h>
 #include <asm/mem_event.h>
 #include <public/mem_event.h>
 #include <asm/mem_sharing.h>
@@ -144,6 +145,182 @@ void p2m_change_entry_type_global(struct
     p2m_unlock(p2m);
 }
 
+#ifdef __x86_64__
+struct p2m_mem_paging_queue {
+    struct list_head list;
+    struct waitqueue_head wq;
+    unsigned long gfn;
+    unsigned short waiters;
+    unsigned short woken;
+    unsigned short index;
+};
+
+struct p2m_mem_paging_queue_head {
+    struct list_head list;
+    unsigned int max;
+};
+
+int p2m_mem_paging_init_queue(struct domain *d, unsigned int max)
+{
+    struct p2m_mem_paging_queue_head *h;
+    struct p2m_mem_paging_queue *q;
+    unsigned int i, nr;
+    int ret = 0;
+
+    spin_lock(&d->arch.hvm_domain.gfn_lock);
+
+    if (!d->arch.hvm_domain.gfn_queue) {
+        ret = -ENOMEM;
+        h = xzalloc(struct p2m_mem_paging_queue_head);
+        if (!h) {
+            domain_crash(d);
+            goto out;
+        }
+
+        INIT_LIST_HEAD(&h->list);
+        nr = max;
+    } else {
+        h = d->arch.hvm_domain.gfn_queue;
+        if (max <= h->max)
+            goto out;
+        nr = max - h->max;
+    }
+
+    ret = -ENOMEM;
+    q = xzalloc_array(struct p2m_mem_paging_queue, nr);
+    if (!q) {
+        if (!d->arch.hvm_domain.gfn_queue)
+            xfree(h);
+        domain_crash(d);
+        goto out;
+    }
+
+    for (i = 0; i < nr; i++) {
+        init_waitqueue_head(&q[i].wq);
+        INIT_LIST_HEAD(&q[i].list);
+        q[i].index = h->max + i + 1;
+        list_add_tail(&q[i].list, &h->list);
+    }
+
+    h->max = max;
+    d->arch.hvm_domain.gfn_queue = h;
+    ret = 0;
+
+out:
+    spin_unlock(&d->arch.hvm_domain.gfn_lock);
+    return ret;
+}
+
+static struct p2m_mem_paging_queue *p2m_mem_paging_get_queue(struct domain *d, unsigned long gfn)
+{
+    struct p2m_mem_paging_queue_head *h;
+    struct p2m_mem_paging_queue *q, *q_match, *q_free;
+    
+    h = d->arch.hvm_domain.gfn_queue;
+    q_match = q_free = NULL;
+
+    spin_lock(&d->arch.hvm_domain.gfn_lock);
+
+    list_for_each_entry(q, &h->list, list) {
+        if (q->gfn == gfn) {
+            q_match = q;
+            break;
+        }
+        if (!q_free && !q->waiters)
+            q_free = q;
+    }
+
+    if (!q_match && q_free)
+        q_match = q_free;
+
+    if (q_match) {
+        if (q_match->woken)
+            printk("wq woken for gfn %u:%u %lx %u %u %u\n", current->domain->domain_id, current->vcpu_id, gfn, q_match->index, q_match->woken, q_match->waiters);
+        q_match->waiters++;
+        q_match->gfn = gfn;
+    }
+
+    if (!q_match)
+        printk("No wq_get for gfn %u:%u %lx\n", current->domain->domain_id, current->vcpu_id, gfn);
+
+    spin_unlock(&d->arch.hvm_domain.gfn_lock);
+    return q_match;
+}
+
+static void p2m_mem_paging_put_queue(struct domain *d, struct p2m_mem_paging_queue *q_match)
+{
+    spin_lock(&d->arch.hvm_domain.gfn_lock);
+
+    if (q_match->waiters == 0)
+        printk("wq_put no waiters, gfn %u:%u %lx %u\n", current->domain->domain_id, current->vcpu_id, q_match->gfn, q_match->woken);
+    else if (--q_match->waiters == 0)
+        q_match->gfn = q_match->woken = 0;;
+
+    spin_unlock(&d->arch.hvm_domain.gfn_lock);
+}
+
+static void p2m_mem_paging_wake_queue(struct domain *d, unsigned long gfn)
+{
+    struct p2m_mem_paging_queue_head *h;
+    struct p2m_mem_paging_queue *q, *q_match = NULL;
+
+    spin_lock(&d->arch.hvm_domain.gfn_lock);
+
+    h = d->arch.hvm_domain.gfn_queue;
+    list_for_each_entry(q, &h->list, list) {
+        if (q->gfn == gfn) {
+            q_match = q;
+            break;
+        }
+    }
+    if (q_match) {
+        if (q_match->woken || q_match->waiters == 0)
+            printk("Wrong wake for gfn %u:%u %p %lx %u %u\n", current->domain->domain_id, current->vcpu_id, q_match, gfn, q_match->woken, q_match->waiters);
+        q_match->woken++;
+        wake_up_all(&q_match->wq);
+    }
+    spin_unlock(&d->arch.hvm_domain.gfn_lock);
+}
+
+/* Returns 0 if the gfn is still paged */
+static int p2m_mem_paging_get_entry(mfn_t *mfn,
+               struct p2m_domain *p2m, unsigned long gfn, 
+               p2m_type_t *t, p2m_access_t *a, p2m_query_t q,
+               unsigned int *page_order)
+{
+    *mfn = p2m->get_entry(p2m, gfn, t, a, q, page_order);
+
+    return p2m_is_paging(*t) ? 0 : 1;
+}
+
+/* Go to sleep in case of guest access */
+static void p2m_mem_paging_wait(mfn_t *mfn,
+                    struct p2m_domain *p2m, unsigned long gfn,
+                    p2m_type_t *t, p2m_access_t *a, p2m_query_t q,
+                    unsigned int *page_order)
+{
+    struct p2m_mem_paging_queue *pmpq;
+
+    /* Return p2mt as is in case of query */
+    if ( q == p2m_query )
+        return;
+    /* Foreign domains can not go to sleep */
+    if ( current->domain != p2m->domain )
+        return;
+
+    pmpq = p2m_mem_paging_get_queue(p2m->domain, gfn);
+    if ( !pmpq )
+        return;
+
+    /* Populate the page once */
+    if ( *t == p2m_ram_paging_out || *t == p2m_ram_paged )
+        p2m_mem_paging_populate(p2m->domain, gfn);
+
+    wait_event(pmpq->wq, p2m_mem_paging_get_entry(mfn, p2m, gfn, t, a, q, page_order));
+    p2m_mem_paging_put_queue(p2m->domain, pmpq);
+}
+#endif
+
 mfn_t get_gfn_type_access(struct p2m_domain *p2m, unsigned long gfn,
                     p2m_type_t *t, p2m_access_t *a, p2m_query_t q,
                     unsigned int *page_order)
@@ -161,6 +338,11 @@ mfn_t get_gfn_type_access(struct p2m_dom
     mfn = p2m->get_entry(p2m, gfn, t, a, q, page_order);
 
 #ifdef __x86_64__
+    if ( unlikely(p2m_is_paging(*t)) )
+        p2m_mem_paging_wait(&mfn, p2m, gfn, t, a, q, page_order);
+#endif
+
+#ifdef __x86_64__
     if ( q == p2m_unshare && p2m_is_shared(*t) )
     {
         ASSERT(!p2m_is_nestedp2m(p2m));
@@ -914,54 +1096,42 @@ void p2m_mem_paging_drop_page(struct dom
 void p2m_mem_paging_populate(struct domain *d, unsigned long gfn)
 {
     struct vcpu *v = current;
-    mem_event_request_t req;
+    mem_event_request_t req = { .type = MEM_EVENT_TYPE_PAGING, .gfn = gfn };
     p2m_type_t p2mt;
     p2m_access_t a;
     mfn_t mfn;
     struct p2m_domain *p2m = p2m_get_hostp2m(d);
+    int put_request = 0;
 
     /* Check that there's space on the ring for this request */
     if ( mem_event_check_ring(d, &d->mem_event->paging) )
         return;
 
-    memset(&req, 0, sizeof(req));
-    req.type = MEM_EVENT_TYPE_PAGING;
-
     /* Fix p2m mapping */
     p2m_lock(p2m);
     mfn = p2m->get_entry(p2m, gfn, &p2mt, &a, p2m_query, NULL);
-    /* Allow only nominated or evicted pages to enter page-in path */
-    if ( p2mt == p2m_ram_paging_out || p2mt == p2m_ram_paged )
-    {
-        /* Evict will fail now, tag this request for pager */
-        if ( p2mt == p2m_ram_paging_out )
-            req.flags |= MEM_EVENT_FLAG_EVICT_FAIL;
+    /* Forward the state only if gfn is in page-out path */
+    if ( p2mt == p2m_ram_paging_out || p2mt == p2m_ram_paged ) {
+        /* Ignore foreign requests to allow mmap in pager */
+        if ( mfn_valid(mfn) && p2mt == p2m_ram_paging_out && v->domain == d ) {
+            /* Restore gfn because it is needed by guest before evict */
+            set_p2m_entry(p2m, gfn, mfn, PAGE_ORDER_4K,
+                       paging_mode_log_dirty(d) ? p2m_ram_logdirty : p2m_ram_rw, a);
+        } else {
+            set_p2m_entry(p2m, gfn, mfn, PAGE_ORDER_4K, p2m_ram_paging_in_start, a);
+            put_request = 1;
+        }
+        /* Evict will fail now, the pager has to try another gfn */
 
-        set_p2m_entry(p2m, gfn, mfn, PAGE_ORDER_4K, p2m_ram_paging_in_start, a);
         audit_p2m(p2m, 1);
     }
     p2m_unlock(p2m);
 
-    /* Pause domain if request came from guest and gfn has paging type */
-    if (  p2m_is_paging(p2mt) && v->domain == d )
-    {
-        vcpu_pause_nosync(v);
-        req.flags |= MEM_EVENT_FLAG_VCPU_PAUSED;
-    }
-    /* No need to inform pager if the gfn is not in the page-out path */
-    else if ( p2mt != p2m_ram_paging_out && p2mt != p2m_ram_paged )
-    {
-        /* gfn is already on its way back and vcpu is not paused */
+    /* One request per gfn, guest vcpus go to sleep, foreigners try again */
+    if ( put_request )
+        mem_event_put_request(d, &d->mem_event->paging, &req);
+    else
         mem_event_put_req_producers(d, &d->mem_event->paging);
-        return;
-    }
-
-    /* Send request to pager */
-    req.gfn = gfn;
-    req.p2mt = p2mt;
-    req.vcpu_id = v->vcpu_id;
-
-    mem_event_put_request(d, &d->mem_event->paging, &req);
 }
 
 /**
@@ -1062,12 +1232,11 @@ void p2m_mem_paging_resume(struct domain
         p2m_unlock(p2m);
     }
 
-    /* Unpause domain */
-    if ( rsp.flags & MEM_EVENT_FLAG_VCPU_PAUSED )
-        vcpu_unpause(d->vcpu[rsp.vcpu_id]);
-
     /* Wake vcpus waiting for room in the ring */
     mem_event_wake_requesters(&d->mem_event->paging);
+
+    /* Unpause all vcpus that were paused because the gfn was paged */
+    p2m_mem_paging_wake_queue(d, rsp.gfn);
 }
 
 void p2m_mem_access_check(unsigned long gpa, bool_t gla_valid, unsigned long gla, 
diff -r 612f69531fd1 -r 8147822efdee xen/common/domctl.c
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -547,6 +547,9 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domc
                 goto maxvcpu_out;
         }
 
+        if ( p2m_mem_paging_init_queue(d, max) )
+            goto maxvcpu_out;
+
         ret = 0;
 
     maxvcpu_out:
diff -r 612f69531fd1 -r 8147822efdee xen/include/asm-x86/hvm/domain.h
--- a/xen/include/asm-x86/hvm/domain.h
+++ b/xen/include/asm-x86/hvm/domain.h
@@ -91,6 +91,9 @@ struct hvm_domain {
 
     struct viridian_domain viridian;
 
+    spinlock_t                        gfn_lock;
+    struct p2m_mem_paging_queue_head *gfn_queue;
+
     bool_t                 hap_enabled;
     bool_t                 mem_sharing_enabled;
     bool_t                 qemu_mapcache_invalidate;
diff -r 612f69531fd1 -r 8147822efdee xen/include/asm-x86/p2m.h
--- a/xen/include/asm-x86/p2m.h
+++ b/xen/include/asm-x86/p2m.h
@@ -468,6 +468,8 @@ p2m_pod_offline_or_broken_replace(struct
 /* Modify p2m table for shared gfn */
 int set_shared_p2m_entry(struct domain *d, unsigned long gfn, mfn_t mfn);
 
+/* Initialize per-gfn wait queue */
+int p2m_mem_paging_init_queue(struct domain *d, unsigned int max);
 /* Check if a nominated gfn is valid to be paged out */
 int p2m_mem_paging_nominate(struct domain *d, unsigned long gfn);
 /* Evict a frame */

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 12:31:09 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 12:31:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW5ms-0007yy-MU; Thu, 01 Dec 2011 12:30:50 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1RW5mr-0007yq-E6
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 12:30:49 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1322742605!5393965!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjc5MTU=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7135 invoked from network); 1 Dec 2011 12:30:07 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 12:30:07 -0000
X-IronPort-AV: E=Sophos;i="4.71,277,1320642000"; d="scan'208";a="172509955"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Dec 2011 07:30:01 -0500
Received: from [10.80.2.18] (10.80.2.18) by FTLPMAILMX01.citrite.net
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Thu, 1 Dec 2011
	07:30:01 -0500
Message-ID: <4ED77347.6060200@citrix.com>
Date: Thu, 1 Dec 2011 12:29:59 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.23) Gecko/20110921 Lightning/1.0b2 Thunderbird/3.1.15
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <CAFA7027.25E35%keir.xen@gmail.com> <4ED62C50.7060204@citrix.com>
	<4ED666D5.5060603@citrix.com>
	<4ED7522E0200007800064973@nat28.tlf.novell.com>
	<4ED74DAD.1040903@citrix.com>
	<4ED75E8402000078000649E6@nat28.tlf.novell.com>
In-Reply-To: <4ED75E8402000078000649E6@nat28.tlf.novell.com>
X-Enigmail-Version: 1.1.2
Content-Type: multipart/mixed; boundary="------------080604070905000400090807"
Cc: Keir Fraser <keir.xen@gmail.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [RFC] KEXEC: allocate crash note buffers at boot
	time v3
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--------------080604070905000400090807
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit

Here is v3 of this patch.

After some consideration, I am not so certain the spinlock is strictly
necessary.  However, as it is not a common codepath, I figure that it is
better to be safe than sorry.

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com


--------------080604070905000400090807
Content-Type: text/x-patch; name="KEXEC-setup-crash-notes-during-boot.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename="KEXEC-setup-crash-notes-during-boot.patch"

# HG changeset patch
# Parent b5ceec1ccccad6e79053a80820132303ff1e136f
KEXEC: Allocate crash notes on boot v3

Currently, the buffers for crash notes are allocated per CPU when a
KEXEC_CMD_kexec_get_range hypercall is made, referencing the CPU in
question.

Although it certainly works in general, there are a few edge case problems:

1) There appears to be no guarentee that dom0 will make this hypercall
   for each pcpu on the system.  There appears to be variable
   behaviour depending on how many cpus dom0 is compiled for, and how
   many vcpus Xen gives to dom0.

2) The allocation of these buffers occur at the whim of dom0.  While
   this is typically very early on dom0 boot, but not guarenteed.

3) It is possible (although not sensible) for a crash
   kernel to be loaded without these (or some of these) hypercalls
   being made. Under these circumstances, a crash would cause the
   crash note code path will suffer a slew of null pointer deferences.

4) If the hypercalls are made after late in the day, it is possible
   for the hypercall to return -ENOMEM.  As code tends to be more
   fragile once memory is enhausted, the likelyhood of us needing the
   crash kernel is greater.

In addition, my forthcoming code to support 32bit kdump kernels on
64bit Xen on large (>64GB) boxes will require some guarentees as to
where the crash note buffers are actually allocated in physical
memory.  This is far easier to sort out at boot time, rather than
after dom0 has been booted and potentially using the physical memory
required.

Therefore, allocate the crash note buffers at boot time.

Changes since v2:

 *  Allocate crash_notes dynamically using nr_cpu_ids at boot time,
    rather than statically using NR_CPUS.
 *  Fix the incorrect use of signed integers for cpu id.
 *  Fix collateral damage to do_crashdump_trigger() and
    crashdump_trigger_handler caused by reordering sizeof_note() and
    setup_note()
 *  Tweak the issue about returing -ENOMEM from kexec_init_cpu_note().
    No functional change.
 *  Change kexec_get_cpu() to attempt to allocate crash note buffers
    in case we have more free memory now than when the pcpu came up.
 *  Now that there are two codepaths possibly allocating crash notes,
    protect the allocation itself with a spinlock.

Changes since v1:

 *  Use cpu hotplug notifiers to handle allocating of the notes
    buffers rather than assuming the boot state of cpus will be the
    same as the crash state.
 *  Move crash_notes from being per_cpu.  This is because the kdump
    kernel elf binary put in the crash area is hard coded to physical
    addresses which the dom0 kernel typically obtains at boot time.
    If a cpu is offlined, its buffer should not be deallocated because
    the kdump kernel would read junk when trying to get the crash
    notes.  Similarly, the same problem would occur if the cpu was
    re-onlined later and its crash notes buffer was allocated elsewhere.
 *  Only attempt to allocate buffers if a crash area has been
    specified.  Else, allocating crash note buffers is a waste of
    space.  Along with this, change the test in kexec_get_cpu to
    return -EINVAL if no buffers have been allocated.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

diff -r df7cec2c6c03 xen/common/kexec.c
--- a/xen/common/kexec.c
+++ b/xen/common/kexec.c
@@ -25,13 +25,15 @@
 #include <xen/kexec.h>
 #include <public/elfnote.h>
 #include <xsm/xsm.h>
+#include <xen/cpu.h>
 #ifdef CONFIG_COMPAT
 #include <compat/kexec.h>
 #endif
 
 bool_t kexecing = FALSE;
 
-static DEFINE_PER_CPU_READ_MOSTLY(void *, crash_notes);
+static void ** crash_notes;
+static spinlock_t crash_notes_lock = SPIN_LOCK_UNLOCKED;
 
 static Elf_Note *xen_crash_note;
 
@@ -165,13 +167,17 @@ static void one_cpu_only(void)
 void kexec_crash_save_cpu(void)
 {
     int cpu = smp_processor_id();
-    Elf_Note *note = per_cpu(crash_notes, cpu);
+    Elf_Note *note;
     ELF_Prstatus *prstatus;
     crash_xen_core_t *xencore;
 
+    BUG_ON( ! crash_notes );
+
     if ( cpumask_test_and_set_cpu(cpu, &crash_saved_cpus) )
         return;
 
+    note = crash_notes[cpu];
+
     prstatus = (ELF_Prstatus *)ELFNOTE_DESC(note);
 
     note = ELFNOTE_NEXT(note);
@@ -257,13 +263,6 @@ static struct keyhandler crashdump_trigg
     .desc = "trigger a crashdump"
 };
 
-static __init int register_crashdump_trigger(void)
-{
-    register_keyhandler('C', &crashdump_trigger_keyhandler);
-    return 0;
-}
-__initcall(register_crashdump_trigger);
-
 static void setup_note(Elf_Note *n, const char *name, int type, int descsz)
 {
     int l = strlen(name) + 1;
@@ -280,6 +279,112 @@ static int sizeof_note(const char *name,
             ELFNOTE_ALIGN(descsz));
 }
 
+/* Allocate a crash note buffer for a newly onlined cpu. */
+static int kexec_init_cpu_notes(const unsigned long cpu)
+{
+    Elf_Note * note;
+    int ret = 0;
+    int nr_bytes = 0;
+
+    BUG_ON( cpu >= NR_CPUS || ! crash_notes );
+
+    /* If already allocated, nothing to do. */
+    if ( crash_notes[cpu] )
+        return ret;
+
+    spin_lock(&crash_notes_lock);
+
+    /* All CPUs present a PRSTATUS and crash_xen_core note. */
+    nr_bytes =
+        sizeof_note("CORE", sizeof(ELF_Prstatus)) +
+        sizeof_note("Xen", sizeof(crash_xen_core_t));
+
+    /* CPU0 also presents the crash_xen_info note. */
+    if ( 0 == cpu )
+        nr_bytes = nr_bytes +
+            sizeof_note("Xen", sizeof(crash_xen_info_t));
+
+    note = xmalloc_bytes(nr_bytes);
+    if ( ! note )
+    {
+        ret = -ENOMEM;
+        goto unlock;
+    }
+
+    crash_notes[cpu] = note;
+
+    /* Setup CORE note. */
+    setup_note(note, "CORE", NT_PRSTATUS, sizeof(ELF_Prstatus));
+    note = ELFNOTE_NEXT(note);
+
+    /* Setup Xen CORE note. */
+    setup_note(note, "Xen", XEN_ELFNOTE_CRASH_REGS,
+               sizeof(crash_xen_core_t));
+
+    if ( 0 == cpu )
+    {
+        /* Set up Xen Crash Info note. */
+        xen_crash_note = note = ELFNOTE_NEXT(note);
+        setup_note(note, "Xen", XEN_ELFNOTE_CRASH_INFO,
+                   sizeof(crash_xen_info_t));
+    }
+
+unlock:
+    spin_unlock(&crash_notes_lock);
+
+    return ret;
+}
+
+static int cpu_callback(
+    struct notifier_block *nfb, unsigned long action, void *hcpu)
+{
+    unsigned long cpu = (unsigned long)hcpu;
+
+    /* Only hook on CPU_UP_PREPARE because once a crash_note has been reported
+     * to dom0, it must keep it around in case of a crash, as the crash kernel
+     * will be hard coded to the original physical address reported. */
+    switch ( action )
+    {
+    case CPU_UP_PREPARE:
+        /* Ignore return value.  If this boot time, -ENOMEM will cause all
+         * manner of problems elsewhere very soon, and if it is during runtime,
+         * then failing to allocate crash notes is not a good enough reason to
+         * fail the CPU_UP_PREPARE */
+        kexec_init_cpu_notes(cpu);
+        break;
+    default:
+        break;
+    }
+    return NOTIFY_DONE;
+}
+
+static struct notifier_block cpu_nfb = {
+    .notifier_call = cpu_callback
+};
+
+static int __init kexec_init(void)
+{
+    void *cpu = (void *)(unsigned long)smp_processor_id();
+
+    register_keyhandler('C', &crashdump_trigger_keyhandler);
+
+    /* If no crash area, no need to allocate space for notes. */
+    if ( 0 == kexec_crash_area.size )
+        return 0;
+
+    crash_notes = xmalloc_bytes(nr_cpu_ids * sizeof(void*));
+    if ( ! crash_notes )
+        return -ENOMEM;
+
+    cpu_callback(&cpu_nfb, CPU_UP_PREPARE, cpu);
+    register_cpu_notifier(&cpu_nfb);
+    return 0;
+}
+/* The reason for this to be a presmp_initcall as opposed to a regular
+ * __initcall is to allow the setup of the cpu hotplug handler before APs are
+ * brought up. */
+presmp_initcall(kexec_init);
+
 static int kexec_get_reserve(xen_kexec_range_t *range)
 {
     if ( kexec_crash_area.size > 0 && kexec_crash_area.start > 0) {
@@ -296,7 +401,12 @@ static int kexec_get_cpu(xen_kexec_range
     int nr = range->nr;
     int nr_bytes = 0;
 
-    if ( nr < 0 || nr >= nr_cpu_ids || !cpu_online(nr) )
+    if ( nr < 0 || nr >= nr_cpu_ids || !cpu_online(nr) || !crash_notes)
+        return -EINVAL;
+
+    /* Try once again to allocate room for the crash notes.  It is just possible
+     * that more space has become available since we last tried. */
+    if ( !crash_notes[nr] && 0 != kexec_init_cpu_notes(nr) )
         return -EINVAL;
 
     nr_bytes += sizeof_note("CORE", sizeof(ELF_Prstatus));
@@ -306,31 +416,7 @@ static int kexec_get_cpu(xen_kexec_range
     if ( nr == 0 )
         nr_bytes += sizeof_note("Xen", sizeof(crash_xen_info_t));
 
-    if ( per_cpu(crash_notes, nr) == NULL )
-    {
-        Elf_Note *note;
-
-        note = per_cpu(crash_notes, nr) = xmalloc_bytes(nr_bytes);
-
-        if ( note == NULL )
-            return -ENOMEM;
-
-        /* Setup CORE note. */
-        setup_note(note, "CORE", NT_PRSTATUS, sizeof(ELF_Prstatus));
-
-        /* Setup Xen CORE note. */
-        note = ELFNOTE_NEXT(note);
-        setup_note(note, "Xen", XEN_ELFNOTE_CRASH_REGS, sizeof(crash_xen_core_t));
-
-        if (nr == 0)
-        {
-            /* Setup system wide Xen info note. */
-            xen_crash_note = note = ELFNOTE_NEXT(note);
-            setup_note(note, "Xen", XEN_ELFNOTE_CRASH_INFO, sizeof(crash_xen_info_t));
-        }
-    }
-
-    range->start = __pa((unsigned long)per_cpu(crash_notes, nr));
+    range->start = __pa((unsigned long)crash_notes[nr]);
     range->size = nr_bytes;
     return 0;
 }

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

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

--------------080604070905000400090807--


From xen-devel-bounces@lists.xensource.com Thu Dec 01 12:31:09 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 12:31:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW5ms-0007yy-MU; Thu, 01 Dec 2011 12:30:50 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1RW5mr-0007yq-E6
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 12:30:49 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1322742605!5393965!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjc5MTU=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7135 invoked from network); 1 Dec 2011 12:30:07 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 12:30:07 -0000
X-IronPort-AV: E=Sophos;i="4.71,277,1320642000"; d="scan'208";a="172509955"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Dec 2011 07:30:01 -0500
Received: from [10.80.2.18] (10.80.2.18) by FTLPMAILMX01.citrite.net
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Thu, 1 Dec 2011
	07:30:01 -0500
Message-ID: <4ED77347.6060200@citrix.com>
Date: Thu, 1 Dec 2011 12:29:59 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.23) Gecko/20110921 Lightning/1.0b2 Thunderbird/3.1.15
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <CAFA7027.25E35%keir.xen@gmail.com> <4ED62C50.7060204@citrix.com>
	<4ED666D5.5060603@citrix.com>
	<4ED7522E0200007800064973@nat28.tlf.novell.com>
	<4ED74DAD.1040903@citrix.com>
	<4ED75E8402000078000649E6@nat28.tlf.novell.com>
In-Reply-To: <4ED75E8402000078000649E6@nat28.tlf.novell.com>
X-Enigmail-Version: 1.1.2
Content-Type: multipart/mixed; boundary="------------080604070905000400090807"
Cc: Keir Fraser <keir.xen@gmail.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [RFC] KEXEC: allocate crash note buffers at boot
	time v3
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--------------080604070905000400090807
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit

Here is v3 of this patch.

After some consideration, I am not so certain the spinlock is strictly
necessary.  However, as it is not a common codepath, I figure that it is
better to be safe than sorry.

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com


--------------080604070905000400090807
Content-Type: text/x-patch; name="KEXEC-setup-crash-notes-during-boot.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename="KEXEC-setup-crash-notes-during-boot.patch"

# HG changeset patch
# Parent b5ceec1ccccad6e79053a80820132303ff1e136f
KEXEC: Allocate crash notes on boot v3

Currently, the buffers for crash notes are allocated per CPU when a
KEXEC_CMD_kexec_get_range hypercall is made, referencing the CPU in
question.

Although it certainly works in general, there are a few edge case problems:

1) There appears to be no guarentee that dom0 will make this hypercall
   for each pcpu on the system.  There appears to be variable
   behaviour depending on how many cpus dom0 is compiled for, and how
   many vcpus Xen gives to dom0.

2) The allocation of these buffers occur at the whim of dom0.  While
   this is typically very early on dom0 boot, but not guarenteed.

3) It is possible (although not sensible) for a crash
   kernel to be loaded without these (or some of these) hypercalls
   being made. Under these circumstances, a crash would cause the
   crash note code path will suffer a slew of null pointer deferences.

4) If the hypercalls are made after late in the day, it is possible
   for the hypercall to return -ENOMEM.  As code tends to be more
   fragile once memory is enhausted, the likelyhood of us needing the
   crash kernel is greater.

In addition, my forthcoming code to support 32bit kdump kernels on
64bit Xen on large (>64GB) boxes will require some guarentees as to
where the crash note buffers are actually allocated in physical
memory.  This is far easier to sort out at boot time, rather than
after dom0 has been booted and potentially using the physical memory
required.

Therefore, allocate the crash note buffers at boot time.

Changes since v2:

 *  Allocate crash_notes dynamically using nr_cpu_ids at boot time,
    rather than statically using NR_CPUS.
 *  Fix the incorrect use of signed integers for cpu id.
 *  Fix collateral damage to do_crashdump_trigger() and
    crashdump_trigger_handler caused by reordering sizeof_note() and
    setup_note()
 *  Tweak the issue about returing -ENOMEM from kexec_init_cpu_note().
    No functional change.
 *  Change kexec_get_cpu() to attempt to allocate crash note buffers
    in case we have more free memory now than when the pcpu came up.
 *  Now that there are two codepaths possibly allocating crash notes,
    protect the allocation itself with a spinlock.

Changes since v1:

 *  Use cpu hotplug notifiers to handle allocating of the notes
    buffers rather than assuming the boot state of cpus will be the
    same as the crash state.
 *  Move crash_notes from being per_cpu.  This is because the kdump
    kernel elf binary put in the crash area is hard coded to physical
    addresses which the dom0 kernel typically obtains at boot time.
    If a cpu is offlined, its buffer should not be deallocated because
    the kdump kernel would read junk when trying to get the crash
    notes.  Similarly, the same problem would occur if the cpu was
    re-onlined later and its crash notes buffer was allocated elsewhere.
 *  Only attempt to allocate buffers if a crash area has been
    specified.  Else, allocating crash note buffers is a waste of
    space.  Along with this, change the test in kexec_get_cpu to
    return -EINVAL if no buffers have been allocated.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

diff -r df7cec2c6c03 xen/common/kexec.c
--- a/xen/common/kexec.c
+++ b/xen/common/kexec.c
@@ -25,13 +25,15 @@
 #include <xen/kexec.h>
 #include <public/elfnote.h>
 #include <xsm/xsm.h>
+#include <xen/cpu.h>
 #ifdef CONFIG_COMPAT
 #include <compat/kexec.h>
 #endif
 
 bool_t kexecing = FALSE;
 
-static DEFINE_PER_CPU_READ_MOSTLY(void *, crash_notes);
+static void ** crash_notes;
+static spinlock_t crash_notes_lock = SPIN_LOCK_UNLOCKED;
 
 static Elf_Note *xen_crash_note;
 
@@ -165,13 +167,17 @@ static void one_cpu_only(void)
 void kexec_crash_save_cpu(void)
 {
     int cpu = smp_processor_id();
-    Elf_Note *note = per_cpu(crash_notes, cpu);
+    Elf_Note *note;
     ELF_Prstatus *prstatus;
     crash_xen_core_t *xencore;
 
+    BUG_ON( ! crash_notes );
+
     if ( cpumask_test_and_set_cpu(cpu, &crash_saved_cpus) )
         return;
 
+    note = crash_notes[cpu];
+
     prstatus = (ELF_Prstatus *)ELFNOTE_DESC(note);
 
     note = ELFNOTE_NEXT(note);
@@ -257,13 +263,6 @@ static struct keyhandler crashdump_trigg
     .desc = "trigger a crashdump"
 };
 
-static __init int register_crashdump_trigger(void)
-{
-    register_keyhandler('C', &crashdump_trigger_keyhandler);
-    return 0;
-}
-__initcall(register_crashdump_trigger);
-
 static void setup_note(Elf_Note *n, const char *name, int type, int descsz)
 {
     int l = strlen(name) + 1;
@@ -280,6 +279,112 @@ static int sizeof_note(const char *name,
             ELFNOTE_ALIGN(descsz));
 }
 
+/* Allocate a crash note buffer for a newly onlined cpu. */
+static int kexec_init_cpu_notes(const unsigned long cpu)
+{
+    Elf_Note * note;
+    int ret = 0;
+    int nr_bytes = 0;
+
+    BUG_ON( cpu >= NR_CPUS || ! crash_notes );
+
+    /* If already allocated, nothing to do. */
+    if ( crash_notes[cpu] )
+        return ret;
+
+    spin_lock(&crash_notes_lock);
+
+    /* All CPUs present a PRSTATUS and crash_xen_core note. */
+    nr_bytes =
+        sizeof_note("CORE", sizeof(ELF_Prstatus)) +
+        sizeof_note("Xen", sizeof(crash_xen_core_t));
+
+    /* CPU0 also presents the crash_xen_info note. */
+    if ( 0 == cpu )
+        nr_bytes = nr_bytes +
+            sizeof_note("Xen", sizeof(crash_xen_info_t));
+
+    note = xmalloc_bytes(nr_bytes);
+    if ( ! note )
+    {
+        ret = -ENOMEM;
+        goto unlock;
+    }
+
+    crash_notes[cpu] = note;
+
+    /* Setup CORE note. */
+    setup_note(note, "CORE", NT_PRSTATUS, sizeof(ELF_Prstatus));
+    note = ELFNOTE_NEXT(note);
+
+    /* Setup Xen CORE note. */
+    setup_note(note, "Xen", XEN_ELFNOTE_CRASH_REGS,
+               sizeof(crash_xen_core_t));
+
+    if ( 0 == cpu )
+    {
+        /* Set up Xen Crash Info note. */
+        xen_crash_note = note = ELFNOTE_NEXT(note);
+        setup_note(note, "Xen", XEN_ELFNOTE_CRASH_INFO,
+                   sizeof(crash_xen_info_t));
+    }
+
+unlock:
+    spin_unlock(&crash_notes_lock);
+
+    return ret;
+}
+
+static int cpu_callback(
+    struct notifier_block *nfb, unsigned long action, void *hcpu)
+{
+    unsigned long cpu = (unsigned long)hcpu;
+
+    /* Only hook on CPU_UP_PREPARE because once a crash_note has been reported
+     * to dom0, it must keep it around in case of a crash, as the crash kernel
+     * will be hard coded to the original physical address reported. */
+    switch ( action )
+    {
+    case CPU_UP_PREPARE:
+        /* Ignore return value.  If this boot time, -ENOMEM will cause all
+         * manner of problems elsewhere very soon, and if it is during runtime,
+         * then failing to allocate crash notes is not a good enough reason to
+         * fail the CPU_UP_PREPARE */
+        kexec_init_cpu_notes(cpu);
+        break;
+    default:
+        break;
+    }
+    return NOTIFY_DONE;
+}
+
+static struct notifier_block cpu_nfb = {
+    .notifier_call = cpu_callback
+};
+
+static int __init kexec_init(void)
+{
+    void *cpu = (void *)(unsigned long)smp_processor_id();
+
+    register_keyhandler('C', &crashdump_trigger_keyhandler);
+
+    /* If no crash area, no need to allocate space for notes. */
+    if ( 0 == kexec_crash_area.size )
+        return 0;
+
+    crash_notes = xmalloc_bytes(nr_cpu_ids * sizeof(void*));
+    if ( ! crash_notes )
+        return -ENOMEM;
+
+    cpu_callback(&cpu_nfb, CPU_UP_PREPARE, cpu);
+    register_cpu_notifier(&cpu_nfb);
+    return 0;
+}
+/* The reason for this to be a presmp_initcall as opposed to a regular
+ * __initcall is to allow the setup of the cpu hotplug handler before APs are
+ * brought up. */
+presmp_initcall(kexec_init);
+
 static int kexec_get_reserve(xen_kexec_range_t *range)
 {
     if ( kexec_crash_area.size > 0 && kexec_crash_area.start > 0) {
@@ -296,7 +401,12 @@ static int kexec_get_cpu(xen_kexec_range
     int nr = range->nr;
     int nr_bytes = 0;
 
-    if ( nr < 0 || nr >= nr_cpu_ids || !cpu_online(nr) )
+    if ( nr < 0 || nr >= nr_cpu_ids || !cpu_online(nr) || !crash_notes)
+        return -EINVAL;
+
+    /* Try once again to allocate room for the crash notes.  It is just possible
+     * that more space has become available since we last tried. */
+    if ( !crash_notes[nr] && 0 != kexec_init_cpu_notes(nr) )
         return -EINVAL;
 
     nr_bytes += sizeof_note("CORE", sizeof(ELF_Prstatus));
@@ -306,31 +416,7 @@ static int kexec_get_cpu(xen_kexec_range
     if ( nr == 0 )
         nr_bytes += sizeof_note("Xen", sizeof(crash_xen_info_t));
 
-    if ( per_cpu(crash_notes, nr) == NULL )
-    {
-        Elf_Note *note;
-
-        note = per_cpu(crash_notes, nr) = xmalloc_bytes(nr_bytes);
-
-        if ( note == NULL )
-            return -ENOMEM;
-
-        /* Setup CORE note. */
-        setup_note(note, "CORE", NT_PRSTATUS, sizeof(ELF_Prstatus));
-
-        /* Setup Xen CORE note. */
-        note = ELFNOTE_NEXT(note);
-        setup_note(note, "Xen", XEN_ELFNOTE_CRASH_REGS, sizeof(crash_xen_core_t));
-
-        if (nr == 0)
-        {
-            /* Setup system wide Xen info note. */
-            xen_crash_note = note = ELFNOTE_NEXT(note);
-            setup_note(note, "Xen", XEN_ELFNOTE_CRASH_INFO, sizeof(crash_xen_info_t));
-        }
-    }
-
-    range->start = __pa((unsigned long)per_cpu(crash_notes, nr));
+    range->start = __pa((unsigned long)crash_notes[nr]);
     range->size = nr_bytes;
     return 0;
 }

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

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

--------------080604070905000400090807--


From xen-devel-bounces@lists.xensource.com Thu Dec 01 12:45:08 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 12:45:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW60R-0008Fo-7G; Thu, 01 Dec 2011 12:44:51 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RW60P-0008Fg-KN
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 12:44:49 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-13.tower-174.messagelabs.com!1322743449!3844414!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMjA0ODc=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMjA0ODc=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18893 invoked from network); 1 Dec 2011 12:44:09 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-13.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 1 Dec 2011 12:44:09 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1322743448; l=1668;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=40USsY1gEt3et9F6XA2G8lMI8e0=;
	b=DFweqbbJZcgWKD/ICqFWiziPRwCaIWjY2O24wb3zMZkC67f7w93DpvCEuLzwJsZFs45
	cP9pmAFLkKFdJ1HCf7WhJvXUTWqt+dZ3qdoC0b2K6GMM3XpKW/LecfZ3r14oq60yw1toI
	Ow7CWWc7Di77gM8rjbXMYFpeEAP9fcj+KMM=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/ll2c7pE6jG
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-080-213.pools.arcor-ip.net [84.57.80.213])
	by smtp.strato.de (cohen mo53) (RZmta 26.10 AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id 205c72nB1BVw84 ;
	Thu, 1 Dec 2011 13:43:44 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id EFF3B18637; Thu,  1 Dec 2011 13:43:43 +0100 (CET)
Date: Thu, 1 Dec 2011 13:43:43 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20111201124343.GA11316@aepfle.de>
References: <patchbomb.1322603559@xdev.gridcentric.ca>
	<20111130132100.GA17890@aepfle.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20111130132100.GA17890@aepfle.de>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: xen-devel@lists.xensource.com, ian.campbell@citrix.com,
	andres@gridcentric.ca, tim@xen.org, keir.xen@gmail.com,
	JBeulich@suse.com, ian.jackson@citrix.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 0 of 2] Fix correctness race in
 xc_mem_paging_prep
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Nov 30, Olaf Hering wrote:

> On Tue, Nov 29, Andres Lagar-Cavilla wrote:
> 
> > P2m_mem_paging_prep ensures that an mfn is backing the paged-out gfn, and
> > transitions to the next state in the paging state machine for this page. 
> > Foreign mappings of the gfn will now succeed. This is the key idea, as it 
> > allows the pager to now map the gfn and fill in its contents.
> > 
> > Unfortunately, it also allows any other foreign mapper to map the gfn and read
> > its contents. This is particularly dangerous when the populate is launched
> > by a foreign mapper in the first place, which will be actively retrying the
> > map operation and might race with the pager. Qemu-dm being a prime example.
> 
> Yes, I think thats a real issue. The concept looks ok to me.

After some more thought I think we can kill two birds with one stone:

- merge p2m_mem_paging_prep() into p2m_mem_paging_resume().
p2m_mem_paging_populate() maintains a list of buffer pages and passes
one of them to the pager. The pager fills the buffer and passes it back
to p2m_mem_paging_resume() which copies that buffer into a newly
allocated page. Once the p2mt state is restored the buffer is released
for further uses in p2m_mem_paging_populate().
Its just the question: how to handle allocation failures?

- if both functions are merged, the communication between 
p2m_mem_paging_drop()/p2m_mem_paging_populate() and
p2m_mem_paging_resume() could be done entirely with th event channel.
The two domctls can disappear and also a p2mt could be removed. So both
page-out and page-in will be a two-step process.

What do you think about that idea?

Olaf

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 12:45:08 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 12:45:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW60R-0008Fo-7G; Thu, 01 Dec 2011 12:44:51 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RW60P-0008Fg-KN
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 12:44:49 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-13.tower-174.messagelabs.com!1322743449!3844414!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMjA0ODc=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMjA0ODc=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18893 invoked from network); 1 Dec 2011 12:44:09 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-13.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 1 Dec 2011 12:44:09 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1322743448; l=1668;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=40USsY1gEt3et9F6XA2G8lMI8e0=;
	b=DFweqbbJZcgWKD/ICqFWiziPRwCaIWjY2O24wb3zMZkC67f7w93DpvCEuLzwJsZFs45
	cP9pmAFLkKFdJ1HCf7WhJvXUTWqt+dZ3qdoC0b2K6GMM3XpKW/LecfZ3r14oq60yw1toI
	Ow7CWWc7Di77gM8rjbXMYFpeEAP9fcj+KMM=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/ll2c7pE6jG
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-080-213.pools.arcor-ip.net [84.57.80.213])
	by smtp.strato.de (cohen mo53) (RZmta 26.10 AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id 205c72nB1BVw84 ;
	Thu, 1 Dec 2011 13:43:44 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id EFF3B18637; Thu,  1 Dec 2011 13:43:43 +0100 (CET)
Date: Thu, 1 Dec 2011 13:43:43 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20111201124343.GA11316@aepfle.de>
References: <patchbomb.1322603559@xdev.gridcentric.ca>
	<20111130132100.GA17890@aepfle.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20111130132100.GA17890@aepfle.de>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: xen-devel@lists.xensource.com, ian.campbell@citrix.com,
	andres@gridcentric.ca, tim@xen.org, keir.xen@gmail.com,
	JBeulich@suse.com, ian.jackson@citrix.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 0 of 2] Fix correctness race in
 xc_mem_paging_prep
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Nov 30, Olaf Hering wrote:

> On Tue, Nov 29, Andres Lagar-Cavilla wrote:
> 
> > P2m_mem_paging_prep ensures that an mfn is backing the paged-out gfn, and
> > transitions to the next state in the paging state machine for this page. 
> > Foreign mappings of the gfn will now succeed. This is the key idea, as it 
> > allows the pager to now map the gfn and fill in its contents.
> > 
> > Unfortunately, it also allows any other foreign mapper to map the gfn and read
> > its contents. This is particularly dangerous when the populate is launched
> > by a foreign mapper in the first place, which will be actively retrying the
> > map operation and might race with the pager. Qemu-dm being a prime example.
> 
> Yes, I think thats a real issue. The concept looks ok to me.

After some more thought I think we can kill two birds with one stone:

- merge p2m_mem_paging_prep() into p2m_mem_paging_resume().
p2m_mem_paging_populate() maintains a list of buffer pages and passes
one of them to the pager. The pager fills the buffer and passes it back
to p2m_mem_paging_resume() which copies that buffer into a newly
allocated page. Once the p2mt state is restored the buffer is released
for further uses in p2m_mem_paging_populate().
Its just the question: how to handle allocation failures?

- if both functions are merged, the communication between 
p2m_mem_paging_drop()/p2m_mem_paging_populate() and
p2m_mem_paging_resume() could be done entirely with th event channel.
The two domctls can disappear and also a p2mt could be removed. So both
page-out and page-in will be a two-step process.

What do you think about that idea?

Olaf

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 12:54:13 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 12: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.xensource.com>)
	id 1RW69C-0008SG-CP; Thu, 01 Dec 2011 12:53:54 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1RW69B-0008S8-39
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 12:53:53 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1322743991!809608!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjc5MTU=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9893 invoked from network); 1 Dec 2011 12:53:13 -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;
	1 Dec 2011 12:53:13 -0000
X-IronPort-AV: E=Sophos;i="4.71,277,1320642000"; d="scan'208";a="172512446"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Dec 2011 07:53:01 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Thu, 1 Dec 2011 07:53:01 -0500
Received: from [127.0.1.1] (elijah.uk.xensource.com [10.80.2.24])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pB1Cqxj6024812;
	Thu, 1 Dec 2011 04:53:00 -0800
MIME-Version: 1.0
X-Mercurial-Node: 3ab01c6cd13fcaaa0d258eeccc3bace21f332a86
Message-ID: <3ab01c6cd13fcaaa0d25.1322744193@elijah>
User-Agent: Mercurial-patchbomb/1.4.3
Date: Thu, 1 Dec 2011 12:56:33 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH] Backport fixes to PoD codepaths related to 1GiB
	pages
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Backport of xen-unstable.hg c/s 24189:7da681c490e0 to xen-4.1-testing

The codepaths in p2m_gfn_to_mfn() and p2m_gfn_to_mfn_current() should
call p2m_pod_check_and_popualte(), as the 2MiB and 4k codepaths do.
This properly grabs the p2m lock.

Also, p2m_pod_demand_populate() shouldn't call p2m_unlock(), as it
didn't grab the lock in the first place.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

diff -r c613d436ca09 -r 3ab01c6cd13f xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c	Tue Nov 22 19:03:04 2011 +0000
+++ b/xen/arch/x86/mm/p2m.c	Thu Dec 01 12:56:18 2011 +0000
@@ -1244,7 +1244,6 @@ p2m_pod_demand_populate(struct p2m_domai
         set_p2m_entry(p2m, gfn_aligned, _mfn(POPULATE_ON_DEMAND_MFN), 9,
                       p2m_populate_on_demand, p2m->default_access);
         audit_p2m(p2m, 1);
-        p2m_unlock(p2m);
         return 0;
     }
 
@@ -1602,7 +1601,8 @@ pod_retry_l3:
             {
                 if ( q != p2m_query )
                 {
-                    if ( !p2m_pod_demand_populate(p2m, gfn, 18, q) )
+                    if ( !p2m_pod_check_and_populate(p2m, gfn,
+                              (l1_pgentry_t *) &l3e, 18, q) )
                         goto pod_retry_l3;
                 }
                 else
@@ -1733,7 +1733,8 @@ static mfn_t p2m_gfn_to_mfn_current(stru
                 /* The read has succeeded, so we know that mapping exists */
                 if ( q != p2m_query )
                 {
-                    if ( !p2m_pod_demand_populate(p2m, gfn, 18, q) )
+                    if ( !p2m_pod_check_and_populate(p2m, gfn,
+                              (l1_pgentry_t *) &l3e, 18, q) )
                         goto pod_retry_l3;
                     p2mt = p2m_invalid;
                     printk("%s: Allocate 1GB failed!\n", __func__);

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 12:54:13 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 12: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.xensource.com>)
	id 1RW69C-0008SG-CP; Thu, 01 Dec 2011 12:53:54 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1RW69B-0008S8-39
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 12:53:53 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1322743991!809608!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjc5MTU=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9893 invoked from network); 1 Dec 2011 12:53:13 -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;
	1 Dec 2011 12:53:13 -0000
X-IronPort-AV: E=Sophos;i="4.71,277,1320642000"; d="scan'208";a="172512446"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Dec 2011 07:53:01 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Thu, 1 Dec 2011 07:53:01 -0500
Received: from [127.0.1.1] (elijah.uk.xensource.com [10.80.2.24])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pB1Cqxj6024812;
	Thu, 1 Dec 2011 04:53:00 -0800
MIME-Version: 1.0
X-Mercurial-Node: 3ab01c6cd13fcaaa0d258eeccc3bace21f332a86
Message-ID: <3ab01c6cd13fcaaa0d25.1322744193@elijah>
User-Agent: Mercurial-patchbomb/1.4.3
Date: Thu, 1 Dec 2011 12:56:33 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH] Backport fixes to PoD codepaths related to 1GiB
	pages
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Backport of xen-unstable.hg c/s 24189:7da681c490e0 to xen-4.1-testing

The codepaths in p2m_gfn_to_mfn() and p2m_gfn_to_mfn_current() should
call p2m_pod_check_and_popualte(), as the 2MiB and 4k codepaths do.
This properly grabs the p2m lock.

Also, p2m_pod_demand_populate() shouldn't call p2m_unlock(), as it
didn't grab the lock in the first place.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

diff -r c613d436ca09 -r 3ab01c6cd13f xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c	Tue Nov 22 19:03:04 2011 +0000
+++ b/xen/arch/x86/mm/p2m.c	Thu Dec 01 12:56:18 2011 +0000
@@ -1244,7 +1244,6 @@ p2m_pod_demand_populate(struct p2m_domai
         set_p2m_entry(p2m, gfn_aligned, _mfn(POPULATE_ON_DEMAND_MFN), 9,
                       p2m_populate_on_demand, p2m->default_access);
         audit_p2m(p2m, 1);
-        p2m_unlock(p2m);
         return 0;
     }
 
@@ -1602,7 +1601,8 @@ pod_retry_l3:
             {
                 if ( q != p2m_query )
                 {
-                    if ( !p2m_pod_demand_populate(p2m, gfn, 18, q) )
+                    if ( !p2m_pod_check_and_populate(p2m, gfn,
+                              (l1_pgentry_t *) &l3e, 18, q) )
                         goto pod_retry_l3;
                 }
                 else
@@ -1733,7 +1733,8 @@ static mfn_t p2m_gfn_to_mfn_current(stru
                 /* The read has succeeded, so we know that mapping exists */
                 if ( q != p2m_query )
                 {
-                    if ( !p2m_pod_demand_populate(p2m, gfn, 18, q) )
+                    if ( !p2m_pod_check_and_populate(p2m, gfn,
+                              (l1_pgentry_t *) &l3e, 18, q) )
                         goto pod_retry_l3;
                     p2mt = p2m_invalid;
                     printk("%s: Allocate 1GB failed!\n", __func__);

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 12:57:30 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 12:57:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW6CO-00008Z-2t; Thu, 01 Dec 2011 12:57:12 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RW6CN-00008I-0u
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 12:57:11 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1322744190!5448574!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQzODQ=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24323 invoked from network); 1 Dec 2011 12:56:31 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-11.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 1 Dec 2011 12:56:31 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 01 Dec 2011 12:56:30 +0000
Message-Id: <4ED787870200007800064B6F@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 01 Dec 2011 12:56:23 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>
References: <CAFA7027.25E35%keir.xen@gmail.com>
	<4ED62C50.7060204@citrix.com> <4ED666D5.5060603@citrix.com>
	<4ED7522E0200007800064973@nat28.tlf.novell.com>
	<4ED74DAD.1040903@citrix.com>
	<4ED75E8402000078000649E6@nat28.tlf.novell.com>
	<4ED77347.6060200@citrix.com>
In-Reply-To: <4ED77347.6060200@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Keir Fraser <keir.xen@gmail.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [RFC] KEXEC: allocate crash note buffers at boot
	time v3
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 01.12.11 at 13:29, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>+static spinlock_t crash_notes_lock = SPIN_LOCK_UNLOCKED;

Please use DEFINE_SPINLOCK() here.

>+    register_keyhandler('C', &crashdump_trigger_keyhandler);
>+
>+    /* If no crash area, no need to allocate space for notes. */
>+    if ( 0 == kexec_crash_area.size )
>+        return 0;

Wouldn't it make sense to switch the order of these?

>+    crash_notes = xmalloc_bytes(nr_cpu_ids * sizeof(void*));

Please use xmalloc_array() here.

>+    if ( !crash_notes[nr] && 0 != kexec_init_cpu_notes(nr) )

The first check is pointless - the function will return zero if the
allocation was already done.

Further, you shouldn't take a lock around a call to xmalloc() or alike
unless absolutely necessary. It is pretty simple to avoid here - you
really only need to lock around the storing of the pointer and maybe
the setup_note() calls (but be careful with returning -ENOMEM - you
shouldn't if the allocation fails, but you then find - under the lock -
that a pointer was already set by another CPU).

Finally, one thing I failed to notice on the previous version - the
nr_bytes calculations are now being done twice. This should
probably be moved into a helper function, especially since you
said you intend to add stuff here subsequently.

Jan


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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 12:57:30 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 12:57:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW6CO-00008Z-2t; Thu, 01 Dec 2011 12:57:12 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RW6CN-00008I-0u
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 12:57:11 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1322744190!5448574!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQzODQ=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24323 invoked from network); 1 Dec 2011 12:56:31 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-11.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 1 Dec 2011 12:56:31 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 01 Dec 2011 12:56:30 +0000
Message-Id: <4ED787870200007800064B6F@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 01 Dec 2011 12:56:23 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>
References: <CAFA7027.25E35%keir.xen@gmail.com>
	<4ED62C50.7060204@citrix.com> <4ED666D5.5060603@citrix.com>
	<4ED7522E0200007800064973@nat28.tlf.novell.com>
	<4ED74DAD.1040903@citrix.com>
	<4ED75E8402000078000649E6@nat28.tlf.novell.com>
	<4ED77347.6060200@citrix.com>
In-Reply-To: <4ED77347.6060200@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Keir Fraser <keir.xen@gmail.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [RFC] KEXEC: allocate crash note buffers at boot
	time v3
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 01.12.11 at 13:29, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>+static spinlock_t crash_notes_lock = SPIN_LOCK_UNLOCKED;

Please use DEFINE_SPINLOCK() here.

>+    register_keyhandler('C', &crashdump_trigger_keyhandler);
>+
>+    /* If no crash area, no need to allocate space for notes. */
>+    if ( 0 == kexec_crash_area.size )
>+        return 0;

Wouldn't it make sense to switch the order of these?

>+    crash_notes = xmalloc_bytes(nr_cpu_ids * sizeof(void*));

Please use xmalloc_array() here.

>+    if ( !crash_notes[nr] && 0 != kexec_init_cpu_notes(nr) )

The first check is pointless - the function will return zero if the
allocation was already done.

Further, you shouldn't take a lock around a call to xmalloc() or alike
unless absolutely necessary. It is pretty simple to avoid here - you
really only need to lock around the storing of the pointer and maybe
the setup_note() calls (but be careful with returning -ENOMEM - you
shouldn't if the allocation fails, but you then find - under the lock -
that a pointer was already set by another CPU).

Finally, one thing I failed to notice on the previous version - the
nr_bytes calculations are now being done twice. This should
probably be moved into a helper function, especially since you
said you intend to add stuff here subsequently.

Jan


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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 12:58:45 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 12:58:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW6De-0000ES-IV; Thu, 01 Dec 2011 12:58:30 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <felipe.m.almeida@gmail.com>) id 1RW6Dc-0000Dw-UJ
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 12:58:29 +0000
X-Env-Sender: felipe.m.almeida@gmail.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1322744268!6557746!1
X-Originating-IP: [209.85.160.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11294 invoked from network); 1 Dec 2011 12:57:49 -0000
Received: from mail-gy0-f171.google.com (HELO mail-gy0-f171.google.com)
	(209.85.160.171)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 12:57:49 -0000
Received: by ghbz2 with SMTP id z2so12560215ghb.30
	for <xen-devel@lists.xensource.com>;
	Thu, 01 Dec 2011 04:57:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=subject:date:from:to:mime-version:x-mailer:message-id:content-type;
	bh=jwjyTg+yGgqVPTx3hvfHMwki7IJcbELLW+aQamy31ZE=;
	b=LqHbS4lGkf3+KQKm2Nsy3aUnisnBnIeTBvfi1YoH3jUKfG4wcJ6fdwnIXvyg+dsoVW
	9saohl3I7xMpkhwLXA1GdmD7rDXXoxHmz2kXRQ1RqhAl6r2VaTIJ4WMCokFJgmS51UAU
	GiDqSqQCxtpyRxuJgZbE8kWFhGCj37l44Lb78=
Received: by 10.100.5.9 with SMTP id 9mr1689892ane.79.1322744268273;
	Thu, 01 Dec 2011 04:57:48 -0800 (PST)
Received: from [189.119.213.12] ([189.119.213.12])
	by mx.google.com with ESMTPS id c10sm9467124yhj.2.2011.12.01.04.57.45
	(version=SSLv3 cipher=OTHER); Thu, 01 Dec 2011 04:57:47 -0800 (PST)
Date: Thu, 01 Dec 2011 10:57:37 -0200
From: "Felipe Magno de Almeida" <felipe.m.almeida@gmail.com>
To: xen-devel@lists.xensource.com
MIME-Version: 1.0
X-Mailer: LCG ProfiMail 3.48
Message-ID: <1130351363.1007204257@gmail.com>
Subject: [Xen-devel] yajl 2.0
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hello,

In Arch Linux. The yajl library distributed is a newer than used by Xen in 
mercurial. Is there an interest in this patch. I also have a PKGBUILD that 
builds Xen from mercurial in Arch Linux.

Regards,
--
Felipe Magno de Almeida
Sent from my Nokia E71


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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 12:58:45 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 12:58:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW6De-0000ES-IV; Thu, 01 Dec 2011 12:58:30 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <felipe.m.almeida@gmail.com>) id 1RW6Dc-0000Dw-UJ
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 12:58:29 +0000
X-Env-Sender: felipe.m.almeida@gmail.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1322744268!6557746!1
X-Originating-IP: [209.85.160.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11294 invoked from network); 1 Dec 2011 12:57:49 -0000
Received: from mail-gy0-f171.google.com (HELO mail-gy0-f171.google.com)
	(209.85.160.171)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 12:57:49 -0000
Received: by ghbz2 with SMTP id z2so12560215ghb.30
	for <xen-devel@lists.xensource.com>;
	Thu, 01 Dec 2011 04:57:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=subject:date:from:to:mime-version:x-mailer:message-id:content-type;
	bh=jwjyTg+yGgqVPTx3hvfHMwki7IJcbELLW+aQamy31ZE=;
	b=LqHbS4lGkf3+KQKm2Nsy3aUnisnBnIeTBvfi1YoH3jUKfG4wcJ6fdwnIXvyg+dsoVW
	9saohl3I7xMpkhwLXA1GdmD7rDXXoxHmz2kXRQ1RqhAl6r2VaTIJ4WMCokFJgmS51UAU
	GiDqSqQCxtpyRxuJgZbE8kWFhGCj37l44Lb78=
Received: by 10.100.5.9 with SMTP id 9mr1689892ane.79.1322744268273;
	Thu, 01 Dec 2011 04:57:48 -0800 (PST)
Received: from [189.119.213.12] ([189.119.213.12])
	by mx.google.com with ESMTPS id c10sm9467124yhj.2.2011.12.01.04.57.45
	(version=SSLv3 cipher=OTHER); Thu, 01 Dec 2011 04:57:47 -0800 (PST)
Date: Thu, 01 Dec 2011 10:57:37 -0200
From: "Felipe Magno de Almeida" <felipe.m.almeida@gmail.com>
To: xen-devel@lists.xensource.com
MIME-Version: 1.0
X-Mailer: LCG ProfiMail 3.48
Message-ID: <1130351363.1007204257@gmail.com>
Subject: [Xen-devel] yajl 2.0
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hello,

In Arch Linux. The yajl library distributed is a newer than used by Xen in 
mercurial. Is there an interest in this patch. I also have a PKGBUILD that 
builds Xen from mercurial in Arch Linux.

Regards,
--
Felipe Magno de Almeida
Sent from my Nokia E71


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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 13:05:04 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 13:05:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW6Jc-0000zE-Dp; Thu, 01 Dec 2011 13:04:40 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RW6Ja-0000yp-Ah
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 13:04:38 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1322744638!5754148!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU2Nw==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15870 invoked from network); 1 Dec 2011 13:03:59 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 13:03:59 -0000
X-IronPort-AV: E=Sophos;i="4.71,277,1320624000"; 
   d="scan'208";a="9229854"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Dec 2011 13:03:58 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 1 Dec 2011
	13:03:58 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Felipe Magno de Almeida <felipe.m.almeida@gmail.com>
Date: Thu, 1 Dec 2011 13:03:58 +0000
In-Reply-To: <1130351363.1007204257@gmail.com>
References: <1130351363.1007204257@gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322744638.31810.199.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] yajl 2.0
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2011-12-01 at 12:57 +0000, Felipe Magno de Almeida wrote:
> Hello,
> 
> In Arch Linux. The yajl library distributed is a newer than used by Xen in 
> mercurial. Is there an interest in this patch.

Sure, please do send it.

I think we need to support both at least for the time being though.

Ian.

> I also have a PKGBUILD that builds Xen from mercurial in Arch Linux.




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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 13:05:04 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 13:05:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW6Jc-0000zE-Dp; Thu, 01 Dec 2011 13:04:40 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RW6Ja-0000yp-Ah
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 13:04:38 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1322744638!5754148!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU2Nw==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15870 invoked from network); 1 Dec 2011 13:03:59 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 13:03:59 -0000
X-IronPort-AV: E=Sophos;i="4.71,277,1320624000"; 
   d="scan'208";a="9229854"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Dec 2011 13:03:58 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 1 Dec 2011
	13:03:58 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Felipe Magno de Almeida <felipe.m.almeida@gmail.com>
Date: Thu, 1 Dec 2011 13:03:58 +0000
In-Reply-To: <1130351363.1007204257@gmail.com>
References: <1130351363.1007204257@gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322744638.31810.199.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] yajl 2.0
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2011-12-01 at 12:57 +0000, Felipe Magno de Almeida wrote:
> Hello,
> 
> In Arch Linux. The yajl library distributed is a newer than used by Xen in 
> mercurial. Is there an interest in this patch.

Sure, please do send it.

I think we need to support both at least for the time being though.

Ian.

> I also have a PKGBUILD that builds Xen from mercurial in Arch Linux.




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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 13:20:33 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 13:20:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW6YX-0001Uw-4d; Thu, 01 Dec 2011 13:20:05 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RW6YW-0001Ur-BV
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 13:20:04 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1322745563!6505417!1
X-Originating-IP: [209.85.161.171]
X-SpamReason: No, hits=1.1 required=7.0 tests=DATE_IN_PAST_06_12,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2788 invoked from network); 1 Dec 2011 13:19:24 -0000
Received: from mail-gx0-f171.google.com (HELO mail-gx0-f171.google.com)
	(209.85.161.171)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 13:19:24 -0000
Received: by ggnr4 with SMTP id r4so12789509ggn.30
	for <xen-devel@lists.xensource.com>;
	Thu, 01 Dec 2011 05:19:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=zwjJo7oqvln9QcoAD/lFJiY7mOX/Fsb6nulFp/3Yhp8=;
	b=B2hMCgXH02barj+2fzSMnWyQ8gz2oL1Dyp1ceWHA6zI7VgFskEh6SMNnqaH6G+iYYf
	pOwGfNDH7irFDfDojr2Y+Xfb3HYpdHWPq8qcyvuAs1u8Zp2om+zOPBfMFS7pcR7morzu
	3fceMOzMWZIR8jYxHDSTcFLMRBWql76HVMcIo=
Received: by 10.236.197.103 with SMTP id s67mr11817706yhn.5.1322745563244;
	Thu, 01 Dec 2011 05:19:23 -0800 (PST)
Received: from [10.68.4.99] ([96.49.152.177])
	by mx.google.com with ESMTPS id 17sm11585838and.15.2011.12.01.05.19.18
	(version=SSLv3 cipher=OTHER); Thu, 01 Dec 2011 05:19:21 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Thu, 01 Dec 2011 05:19:14 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>,
	Jinsong Liu <jinsong.liu@intel.com>
Message-ID: <CAFCBED2.262CA%keir.xen@gmail.com>
Thread-Topic: [PATCH 3/6] X86: Disable PCID/INVPCID for dom0
Thread-Index: AcywK9H87r5cemygrE6Pva5Wvk+d3w==
In-Reply-To: <4ED761060200007800064A09@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 3/6] X86: Disable PCID/INVPCID for dom0
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/12/2011 10:12, "Jan Beulich" <JBeulich@suse.com> wrote:

>>> 
>>> For pv, if expose PCID to pv, the PCIDs of different pv domain may
>>> conflict, which make processor confused at TLB.
>>> To make PCID work at pv, it need
>>> 1, either a coordinated PCID allocation algorithm, so that the local
>>> PCID of pv domain can be changed to a global unique PCID; 2, or, a
>>> 'clean' vcpu context switch logic to flush all TLB;
>>> method 1 make things complex w/o obvious benefit;
>>> method 2 need change current vcpu context switch logic (i.e, mov cr3
>>> only flush TLB entries of specific PCID if PCID enabled), and if
>>> flush *all* TLB is required at context switch, we lose the change to
>>> optimize context switch by partly flush TLB case by case, which may
>>> result in performance regression;
>>> 
>>> Thanks,
>>> Jinsong
>> 
>> Jan, any comments? Thanks, Jinsong
> 
> No, no further comments (just don't have the time right now to think
> through the possible alternatives). So for the moment I think things
> could go in as posted by you. It's not immediately clear though
> whether the series needs to be applied in order (it would seem that's
> not a requirement, but I'd like your confirmation), as I could at most
> take care of patches 2, 3, and 6.

I'm happy for you to apply the whole lot.

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

> Jan
> 



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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 13:20:33 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 13:20:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW6YX-0001Uw-4d; Thu, 01 Dec 2011 13:20:05 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RW6YW-0001Ur-BV
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 13:20:04 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1322745563!6505417!1
X-Originating-IP: [209.85.161.171]
X-SpamReason: No, hits=1.1 required=7.0 tests=DATE_IN_PAST_06_12,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2788 invoked from network); 1 Dec 2011 13:19:24 -0000
Received: from mail-gx0-f171.google.com (HELO mail-gx0-f171.google.com)
	(209.85.161.171)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 13:19:24 -0000
Received: by ggnr4 with SMTP id r4so12789509ggn.30
	for <xen-devel@lists.xensource.com>;
	Thu, 01 Dec 2011 05:19:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=zwjJo7oqvln9QcoAD/lFJiY7mOX/Fsb6nulFp/3Yhp8=;
	b=B2hMCgXH02barj+2fzSMnWyQ8gz2oL1Dyp1ceWHA6zI7VgFskEh6SMNnqaH6G+iYYf
	pOwGfNDH7irFDfDojr2Y+Xfb3HYpdHWPq8qcyvuAs1u8Zp2om+zOPBfMFS7pcR7morzu
	3fceMOzMWZIR8jYxHDSTcFLMRBWql76HVMcIo=
Received: by 10.236.197.103 with SMTP id s67mr11817706yhn.5.1322745563244;
	Thu, 01 Dec 2011 05:19:23 -0800 (PST)
Received: from [10.68.4.99] ([96.49.152.177])
	by mx.google.com with ESMTPS id 17sm11585838and.15.2011.12.01.05.19.18
	(version=SSLv3 cipher=OTHER); Thu, 01 Dec 2011 05:19:21 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Thu, 01 Dec 2011 05:19:14 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>,
	Jinsong Liu <jinsong.liu@intel.com>
Message-ID: <CAFCBED2.262CA%keir.xen@gmail.com>
Thread-Topic: [PATCH 3/6] X86: Disable PCID/INVPCID for dom0
Thread-Index: AcywK9H87r5cemygrE6Pva5Wvk+d3w==
In-Reply-To: <4ED761060200007800064A09@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 3/6] X86: Disable PCID/INVPCID for dom0
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/12/2011 10:12, "Jan Beulich" <JBeulich@suse.com> wrote:

>>> 
>>> For pv, if expose PCID to pv, the PCIDs of different pv domain may
>>> conflict, which make processor confused at TLB.
>>> To make PCID work at pv, it need
>>> 1, either a coordinated PCID allocation algorithm, so that the local
>>> PCID of pv domain can be changed to a global unique PCID; 2, or, a
>>> 'clean' vcpu context switch logic to flush all TLB;
>>> method 1 make things complex w/o obvious benefit;
>>> method 2 need change current vcpu context switch logic (i.e, mov cr3
>>> only flush TLB entries of specific PCID if PCID enabled), and if
>>> flush *all* TLB is required at context switch, we lose the change to
>>> optimize context switch by partly flush TLB case by case, which may
>>> result in performance regression;
>>> 
>>> Thanks,
>>> Jinsong
>> 
>> Jan, any comments? Thanks, Jinsong
> 
> No, no further comments (just don't have the time right now to think
> through the possible alternatives). So for the moment I think things
> could go in as posted by you. It's not immediately clear though
> whether the series needs to be applied in order (it would seem that's
> not a requirement, but I'd like your confirmation), as I could at most
> take care of patches 2, 3, and 6.

I'm happy for you to apply the whole lot.

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

> Jan
> 



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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 13:21:59 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 13:21:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW6a4-0001YY-Kj; Thu, 01 Dec 2011 13:21:40 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RW6a3-0001YB-DZ
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 13:21:39 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1322745658!5485003!1
X-Originating-IP: [209.85.160.171]
X-SpamReason: No, hits=1.1 required=7.0 tests=DATE_IN_PAST_06_12,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2356 invoked from network); 1 Dec 2011 13:20:59 -0000
Received: from mail-gy0-f171.google.com (HELO mail-gy0-f171.google.com)
	(209.85.160.171)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 13:20:59 -0000
Received: by ghbz2 with SMTP id z2so12796454ghb.30
	for <xen-devel@lists.xensource.com>;
	Thu, 01 Dec 2011 05:20:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=zwT/ARlTj+7dYVNdD5ak7fXY8iyrels2PCfWGwJKFAU=;
	b=HYhI6HmgV7tYFKazuh9kgH3Ccb4XbqLTrO9hsqlUv1RlSNhXMjqhikrddbHzAASY3E
	/hXBHiN7/5pryNyEJZ/qIM2SnLJOGZ6XABMO1Tnl/VSpu2Lc+A7o8SJzJOQeGSNzq210
	eQy+k+DSClL2PisOnTOa2tY3E0xnpAR/Duy0s=
Received: by 10.101.9.2 with SMTP id m2mr1708233ani.78.1322745658397;
	Thu, 01 Dec 2011 05:20:58 -0800 (PST)
Received: from [10.68.4.99] ([96.49.152.177])
	by mx.google.com with ESMTPS id c10sm9569967yhj.2.2011.12.01.05.20.54
	(version=SSLv3 cipher=OTHER); Thu, 01 Dec 2011 05:20:56 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Thu, 01 Dec 2011 05:20:48 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>, Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <CAFCBF30.262CB%keir.xen@gmail.com>
Thread-Topic: [RFC] KEXEC: allocate crash note buffers at boot time v3
Thread-Index: AcywLAoEJ/mmweV3/EG0s7G8T0bpNA==
In-Reply-To: <4ED787870200007800064B6F@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [RFC] KEXEC: allocate crash note buffers at boot
	time v3
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/12/2011 12:56, "Jan Beulich" <JBeulich@suse.com> wrote:

>> +    register_keyhandler('C', &crashdump_trigger_keyhandler);
>> +
>> +    /* If no crash area, no need to allocate space for notes. */
>> +    if ( 0 == kexec_crash_area.size )
>> +        return 0;
> 
> Wouldn't it make sense to switch the order of these?

I also really hate this constant-first ordering.

 -- Keir



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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 13:21:59 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 13:21:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW6a4-0001YY-Kj; Thu, 01 Dec 2011 13:21:40 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RW6a3-0001YB-DZ
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 13:21:39 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1322745658!5485003!1
X-Originating-IP: [209.85.160.171]
X-SpamReason: No, hits=1.1 required=7.0 tests=DATE_IN_PAST_06_12,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2356 invoked from network); 1 Dec 2011 13:20:59 -0000
Received: from mail-gy0-f171.google.com (HELO mail-gy0-f171.google.com)
	(209.85.160.171)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 13:20:59 -0000
Received: by ghbz2 with SMTP id z2so12796454ghb.30
	for <xen-devel@lists.xensource.com>;
	Thu, 01 Dec 2011 05:20:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=zwT/ARlTj+7dYVNdD5ak7fXY8iyrels2PCfWGwJKFAU=;
	b=HYhI6HmgV7tYFKazuh9kgH3Ccb4XbqLTrO9hsqlUv1RlSNhXMjqhikrddbHzAASY3E
	/hXBHiN7/5pryNyEJZ/qIM2SnLJOGZ6XABMO1Tnl/VSpu2Lc+A7o8SJzJOQeGSNzq210
	eQy+k+DSClL2PisOnTOa2tY3E0xnpAR/Duy0s=
Received: by 10.101.9.2 with SMTP id m2mr1708233ani.78.1322745658397;
	Thu, 01 Dec 2011 05:20:58 -0800 (PST)
Received: from [10.68.4.99] ([96.49.152.177])
	by mx.google.com with ESMTPS id c10sm9569967yhj.2.2011.12.01.05.20.54
	(version=SSLv3 cipher=OTHER); Thu, 01 Dec 2011 05:20:56 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Thu, 01 Dec 2011 05:20:48 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>, Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <CAFCBF30.262CB%keir.xen@gmail.com>
Thread-Topic: [RFC] KEXEC: allocate crash note buffers at boot time v3
Thread-Index: AcywLAoEJ/mmweV3/EG0s7G8T0bpNA==
In-Reply-To: <4ED787870200007800064B6F@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [RFC] KEXEC: allocate crash note buffers at boot
	time v3
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/12/2011 12:56, "Jan Beulich" <JBeulich@suse.com> wrote:

>> +    register_keyhandler('C', &crashdump_trigger_keyhandler);
>> +
>> +    /* If no crash area, no need to allocate space for notes. */
>> +    if ( 0 == kexec_crash_area.size )
>> +        return 0;
> 
> Wouldn't it make sense to switch the order of these?

I also really hate this constant-first ordering.

 -- Keir



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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 13:26:54 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 13: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.xensource.com>)
	id 1RW6em-0001md-Cm; Thu, 01 Dec 2011 13:26:32 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RW6ek-0001mQ-3E
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 13:26:30 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1322745948!4566769!1
X-Originating-IP: [209.85.213.171]
X-SpamReason: No, hits=1.1 required=7.0 tests=DATE_IN_PAST_06_12,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9408 invoked from network); 1 Dec 2011 13:25:50 -0000
Received: from mail-yx0-f171.google.com (HELO mail-yx0-f171.google.com)
	(209.85.213.171)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 13:25:50 -0000
Received: by yenr9 with SMTP id r9so12200738yen.30
	for <xen-devel@lists.xensource.com>;
	Thu, 01 Dec 2011 05:25:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=zXgoxzXk0DxHZySIHHLpC2uqSxyXjPHqZMKllE3Kw4k=;
	b=BP4fFxrAkABP53jera6clnzEL7EprUcY+gkruaBFyEaZ2Aj0fz0wBsqkuUNLuQmfMi
	MjGGCIaWBvJXWRryc3zsdiXfNhNdExET6PbdswLSTNx42AXINMMNvBHjIr55IOeahanF
	zg6y8lUgeJobtesT3bcEy+g/a+ayJl2R5FpjI=
Received: by 10.236.161.4 with SMTP id v4mr11225736yhk.89.1322745948576;
	Thu, 01 Dec 2011 05:25:48 -0800 (PST)
Received: from [10.68.4.99] ([96.49.152.177])
	by mx.google.com with ESMTPS id x17sm15222285anj.18.2011.12.01.05.25.45
	(version=SSLv3 cipher=OTHER); Thu, 01 Dec 2011 05:25:47 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Thu, 01 Dec 2011 05:25:40 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <CAFCC054.262CD%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH 2/2] x86/microcode: enable boot time
	(pre-Dom0) loading
Thread-Index: AcywLLgPZVvol6w4/0e5OBeunJ0xDA==
In-Reply-To: <4ED7423602000078000648FE@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 2/2] x86/microcode: enable boot time
 (pre-Dom0) loading
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/12/2011 08:00, "Jan Beulich" <JBeulich@suse.com> wrote:

>>>> On 30.11.11 at 10:05, Keir Fraser <keir.xen@gmail.com> wrote:
>> On 30/11/2011 16:27, "Jan Beulich" <JBeulich@suse.com> wrote:
>> 
>>> 
>>> In order to not convert the spin_lock() in microcode_update_cpu() (and
>>> then obviously also all other uses on microcode_mutex) to
>>> spin_lock_irqsave() (which would be undesirable for the hypercall
>>> context in which the function also runs), the boot time handling gets
>>> done using a tasklet (instead of using on_selected_cpus()).
>> 
>> Can you explain this some more? Why would the conversion to
>> spin_lock_irqsave be required when spin_lock is sufficient for current usage
>> from dom0 hypercall?
> 
> Because check_lock() wants locks to be acquired consistently?

Oh I see, and we use continue_hypercall_on_cpu() in the hypercall case.
Makes sense then.

 -- Keir

> Jan
> 



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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 13:26:54 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 13: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.xensource.com>)
	id 1RW6em-0001md-Cm; Thu, 01 Dec 2011 13:26:32 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RW6ek-0001mQ-3E
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 13:26:30 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1322745948!4566769!1
X-Originating-IP: [209.85.213.171]
X-SpamReason: No, hits=1.1 required=7.0 tests=DATE_IN_PAST_06_12,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9408 invoked from network); 1 Dec 2011 13:25:50 -0000
Received: from mail-yx0-f171.google.com (HELO mail-yx0-f171.google.com)
	(209.85.213.171)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 13:25:50 -0000
Received: by yenr9 with SMTP id r9so12200738yen.30
	for <xen-devel@lists.xensource.com>;
	Thu, 01 Dec 2011 05:25:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=zXgoxzXk0DxHZySIHHLpC2uqSxyXjPHqZMKllE3Kw4k=;
	b=BP4fFxrAkABP53jera6clnzEL7EprUcY+gkruaBFyEaZ2Aj0fz0wBsqkuUNLuQmfMi
	MjGGCIaWBvJXWRryc3zsdiXfNhNdExET6PbdswLSTNx42AXINMMNvBHjIr55IOeahanF
	zg6y8lUgeJobtesT3bcEy+g/a+ayJl2R5FpjI=
Received: by 10.236.161.4 with SMTP id v4mr11225736yhk.89.1322745948576;
	Thu, 01 Dec 2011 05:25:48 -0800 (PST)
Received: from [10.68.4.99] ([96.49.152.177])
	by mx.google.com with ESMTPS id x17sm15222285anj.18.2011.12.01.05.25.45
	(version=SSLv3 cipher=OTHER); Thu, 01 Dec 2011 05:25:47 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Thu, 01 Dec 2011 05:25:40 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <CAFCC054.262CD%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH 2/2] x86/microcode: enable boot time
	(pre-Dom0) loading
Thread-Index: AcywLLgPZVvol6w4/0e5OBeunJ0xDA==
In-Reply-To: <4ED7423602000078000648FE@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 2/2] x86/microcode: enable boot time
 (pre-Dom0) loading
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/12/2011 08:00, "Jan Beulich" <JBeulich@suse.com> wrote:

>>>> On 30.11.11 at 10:05, Keir Fraser <keir.xen@gmail.com> wrote:
>> On 30/11/2011 16:27, "Jan Beulich" <JBeulich@suse.com> wrote:
>> 
>>> 
>>> In order to not convert the spin_lock() in microcode_update_cpu() (and
>>> then obviously also all other uses on microcode_mutex) to
>>> spin_lock_irqsave() (which would be undesirable for the hypercall
>>> context in which the function also runs), the boot time handling gets
>>> done using a tasklet (instead of using on_selected_cpus()).
>> 
>> Can you explain this some more? Why would the conversion to
>> spin_lock_irqsave be required when spin_lock is sufficient for current usage
>> from dom0 hypercall?
> 
> Because check_lock() wants locks to be acquired consistently?

Oh I see, and we use continue_hypercall_on_cpu() in the hypercall case.
Makes sense then.

 -- Keir

> Jan
> 



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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 13:27:11 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 13:27:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW6f8-0001oJ-Qc; Thu, 01 Dec 2011 13:26:54 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RW6f7-0001nh-ME
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 13:26:53 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1322745948!4566769!2
X-Originating-IP: [209.85.213.171]
X-SpamReason: No, hits=1.1 required=7.0 tests=DATE_IN_PAST_06_12,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11248 invoked from network); 1 Dec 2011 13:26:13 -0000
Received: from mail-yx0-f171.google.com (HELO mail-yx0-f171.google.com)
	(209.85.213.171)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 13:26:13 -0000
Received: by mail-yx0-f171.google.com with SMTP id r9so12200738yen.30
	for <xen-devel@lists.xensource.com>;
	Thu, 01 Dec 2011 05:26:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=As1VV+aXf61A6n2koe2pD28Ga9LYkKIWDYzlKaB6hqo=;
	b=FcM/1vPEf83ACz8K2Yy30tHO6XBFL9ee435fyOSg7h/uDLLEwRMnax0Mrip+etKjpg
	D3eC3MRMe0c6XL5b4ON7cQ9Svy8+KFgydCCI+Zw4go3aRdY3y+rTvSHq6Hxrrh49h7WB
	GrdpFDtU8aY9zCE+vI0BoMoJcU3qPmfowd8Xg=
Received: by 10.236.129.147 with SMTP id h19mr3298212yhi.96.1322745973368;
	Thu, 01 Dec 2011 05:26:13 -0800 (PST)
Received: from [10.68.4.99] ([96.49.152.177])
	by mx.google.com with ESMTPS id l18sm2348247anb.22.2011.12.01.05.26.10
	(version=SSLv3 cipher=OTHER); Thu, 01 Dec 2011 05:26:12 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Thu, 01 Dec 2011 05:26:08 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Message-ID: <CAFCC070.262CE%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH 0/2] x86: microcode fixes and improvements
Thread-Index: AcywLMjAbeQV21bJn0yW/IruQYH9Xw==
In-Reply-To: <4ED6670C02000078000646B4@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH 0/2] x86: microcode fixes and improvements
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 30/11/2011 16:25, "Jan Beulich" <JBeulich@suse.com> wrote:

> 1: x86: consolidate microcode loading code
> 2: x86/microcode: enable boot time (pre-Dom0) loading
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

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

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



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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 13:27:11 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 13:27:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW6f8-0001oJ-Qc; Thu, 01 Dec 2011 13:26:54 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RW6f7-0001nh-ME
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 13:26:53 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1322745948!4566769!2
X-Originating-IP: [209.85.213.171]
X-SpamReason: No, hits=1.1 required=7.0 tests=DATE_IN_PAST_06_12,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11248 invoked from network); 1 Dec 2011 13:26:13 -0000
Received: from mail-yx0-f171.google.com (HELO mail-yx0-f171.google.com)
	(209.85.213.171)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 13:26:13 -0000
Received: by mail-yx0-f171.google.com with SMTP id r9so12200738yen.30
	for <xen-devel@lists.xensource.com>;
	Thu, 01 Dec 2011 05:26:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=As1VV+aXf61A6n2koe2pD28Ga9LYkKIWDYzlKaB6hqo=;
	b=FcM/1vPEf83ACz8K2Yy30tHO6XBFL9ee435fyOSg7h/uDLLEwRMnax0Mrip+etKjpg
	D3eC3MRMe0c6XL5b4ON7cQ9Svy8+KFgydCCI+Zw4go3aRdY3y+rTvSHq6Hxrrh49h7WB
	GrdpFDtU8aY9zCE+vI0BoMoJcU3qPmfowd8Xg=
Received: by 10.236.129.147 with SMTP id h19mr3298212yhi.96.1322745973368;
	Thu, 01 Dec 2011 05:26:13 -0800 (PST)
Received: from [10.68.4.99] ([96.49.152.177])
	by mx.google.com with ESMTPS id l18sm2348247anb.22.2011.12.01.05.26.10
	(version=SSLv3 cipher=OTHER); Thu, 01 Dec 2011 05:26:12 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Thu, 01 Dec 2011 05:26:08 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Message-ID: <CAFCC070.262CE%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH 0/2] x86: microcode fixes and improvements
Thread-Index: AcywLMjAbeQV21bJn0yW/IruQYH9Xw==
In-Reply-To: <4ED6670C02000078000646B4@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH 0/2] x86: microcode fixes and improvements
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 30/11/2011 16:25, "Jan Beulich" <JBeulich@suse.com> wrote:

> 1: x86: consolidate microcode loading code
> 2: x86/microcode: enable boot time (pre-Dom0) loading
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

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

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



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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 14:00:27 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 14:00:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW7BA-0002Mr-K3; Thu, 01 Dec 2011 14:00:00 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RW7B9-0002Ml-Gf
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 13:59:59 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1322747959!6395870!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU2Nw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1976 invoked from network); 1 Dec 2011 13:59:19 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 13:59:19 -0000
X-IronPort-AV: E=Sophos;i="4.71,278,1320624000"; 
   d="scan'208";a="9231459"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Dec 2011 13:59:19 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 1 Dec 2011
	13:59:19 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: anatoly techtonik <techtonik@gmail.com>
Date: Thu, 1 Dec 2011 13:59:19 +0000
In-Reply-To: <CAPkN8xLX83Uxbo4UDWG2mmYctAQbwRcw3BJWzack8JZgQAg9nw@mail.gmail.com>
References: <CAPkN8xKwAsrF_ZuXWAF2uMVDYTbGwpSsvG+YfjrLfpf-oxqwJQ@mail.gmail.com>
	<CAPkN8xLX83Uxbo4UDWG2mmYctAQbwRcw3BJWzack8JZgQAg9nw@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322747959.31810.207.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Low memory corruption - trap invalid opcode
 ip:7f5c688028b0 sp:7ffff97af848 error:0 in ld-2.11.2.so[7f5c687ef000+1e000]
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2011-11-29 at 17:54 +0000, anatoly techtonik wrote:
> My first message didn't get to the list, so I am trying once more.
> 
> ---------- Forwarded message ----------
> From: anatoly techtonik <techtonik@gmail.com>
> Date: Mon, Nov 14, 2011 at 5:46 PM
> Subject: Low memory corruption - trap invalid opcode ip:7f5c688028b0
> sp:7ffff97af848 error:0 in ld-2.11.2.so[7f5c687ef000+1e000]
> To: xen-devel@lists.xensource.com
> 
> 
> I was redirected here from this bug report in Debian against
> 'svn-buildpackage' after I started getting 'Illegal instruction' error
> after running 'svn-inject' and similar command on a brand new VM
> instance for Debian Squeeze.
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=646945#54
> 
> dmesg from VM
> 17067.210187] svn-inject[6026] trap invalid opcode ip:7f5c688028b0
> sp:7ffff97af848 error:0 in ld-2.11.2.so[7f5c687ef000+1e000]

This is more than likely the same issue as
http://bugs.debian.org/646549.

Ian.

> 
> 
> I am running Debian Squeeze 6.0.3 with this package:
> Package: xen-hypervisor-4.0-amd64
> State: installed
> Version: 4.0.1-4
> 
> Guest is Debian Squeeze 6.0.3 as well.
> 
> 
> How to fix my machine? Reinstallation doesn't help.
> 
> 
> P.S. http://wiki.xen.org/wiki/ReportingBugs says to look for more info
> in "Host console output (perhaps including hypervisor debug key
> output)", but doesn't explain how to get into this console
> P.P.S. But reporting link on http://www.xen.org/support/community.html
> is broken
> 
> Please, CC.
> --
> anatoly t.
> 
> 
> 



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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 14:00:27 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 14:00:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW7BA-0002Mr-K3; Thu, 01 Dec 2011 14:00:00 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RW7B9-0002Ml-Gf
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 13:59:59 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1322747959!6395870!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU2Nw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1976 invoked from network); 1 Dec 2011 13:59:19 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 13:59:19 -0000
X-IronPort-AV: E=Sophos;i="4.71,278,1320624000"; 
   d="scan'208";a="9231459"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Dec 2011 13:59:19 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 1 Dec 2011
	13:59:19 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: anatoly techtonik <techtonik@gmail.com>
Date: Thu, 1 Dec 2011 13:59:19 +0000
In-Reply-To: <CAPkN8xLX83Uxbo4UDWG2mmYctAQbwRcw3BJWzack8JZgQAg9nw@mail.gmail.com>
References: <CAPkN8xKwAsrF_ZuXWAF2uMVDYTbGwpSsvG+YfjrLfpf-oxqwJQ@mail.gmail.com>
	<CAPkN8xLX83Uxbo4UDWG2mmYctAQbwRcw3BJWzack8JZgQAg9nw@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322747959.31810.207.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Low memory corruption - trap invalid opcode
 ip:7f5c688028b0 sp:7ffff97af848 error:0 in ld-2.11.2.so[7f5c687ef000+1e000]
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2011-11-29 at 17:54 +0000, anatoly techtonik wrote:
> My first message didn't get to the list, so I am trying once more.
> 
> ---------- Forwarded message ----------
> From: anatoly techtonik <techtonik@gmail.com>
> Date: Mon, Nov 14, 2011 at 5:46 PM
> Subject: Low memory corruption - trap invalid opcode ip:7f5c688028b0
> sp:7ffff97af848 error:0 in ld-2.11.2.so[7f5c687ef000+1e000]
> To: xen-devel@lists.xensource.com
> 
> 
> I was redirected here from this bug report in Debian against
> 'svn-buildpackage' after I started getting 'Illegal instruction' error
> after running 'svn-inject' and similar command on a brand new VM
> instance for Debian Squeeze.
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=646945#54
> 
> dmesg from VM
> 17067.210187] svn-inject[6026] trap invalid opcode ip:7f5c688028b0
> sp:7ffff97af848 error:0 in ld-2.11.2.so[7f5c687ef000+1e000]

This is more than likely the same issue as
http://bugs.debian.org/646549.

Ian.

> 
> 
> I am running Debian Squeeze 6.0.3 with this package:
> Package: xen-hypervisor-4.0-amd64
> State: installed
> Version: 4.0.1-4
> 
> Guest is Debian Squeeze 6.0.3 as well.
> 
> 
> How to fix my machine? Reinstallation doesn't help.
> 
> 
> P.S. http://wiki.xen.org/wiki/ReportingBugs says to look for more info
> in "Host console output (perhaps including hypervisor debug key
> output)", but doesn't explain how to get into this console
> P.P.S. But reporting link on http://www.xen.org/support/community.html
> is broken
> 
> Please, CC.
> --
> anatoly t.
> 
> 
> 



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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 14:00:29 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 14:00:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW7BE-0002QF-16; Thu, 01 Dec 2011 14:00:04 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RW7BC-0002Mm-0J
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 14:00:02 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-8.tower-174.messagelabs.com!1322747961!3849332!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14561 invoked from network); 1 Dec 2011 13:59:21 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-8.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 1 Dec 2011 13:59:21 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RW7AS-000GLQ-Ll; Thu, 01 Dec 2011 13:59:16 +0000
Date: Thu, 1 Dec 2011 13:59:16 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20111201135916.GB61203@ocelot.phlegethon.org>
References: <patchbomb.1320788543@xdev.gridcentric.ca>
	<6203a0549d8a1a21753b.1320788545@xdev.gridcentric.ca>
	<20111110125342.GG62117@ocelot.phlegethon.org>
	<4cb5acd8fa013dc40d5063d61296a319.squirrel@webmail.lagarcavilla.org>
	<20111124113507.GA77868@ocelot.phlegethon.org>
	<180057def2be9bc8eb519865f17aca96.squirrel@webmail.lagarcavilla.org>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <180057def2be9bc8eb519865f17aca96.squirrel@webmail.lagarcavilla.org>
User-Agent: Mutt/1.4.2.1i
Cc: olaf@aepfle.de, xen-devel@lists.xensource.com, george.dunlap@eu.citrix.com,
	andres@gridcentric.ca, keir.xen@gmail.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 2 of 3] Make p2m lookups fully synchronized
	wrt modifications
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 08:41 -0800 on 24 Nov (1322124101), Andres Lagar-Cavilla wrote:
> Here is one solution to consider: do not lock the p2m on lookups in shadow
> mode. Shadow mode does not support paging out and sharing of pages, which
> are primary reasons why we want synchronized p2m lookups. The hap cases
> where there is an inversion of the p2m_lock -> paging_lock order are
> reasonably simple to handle.
> 
> The other option is to invert the order and place paging_lock -> p2m_lock,
> but that will raise another set of potential inversions. I think this is a
> no go.

Is there scope for having the p2m lock split out into the overall one
(needed for allocations &c) and the per-record ones, and have them at
different levels in the lock hierarchy?

Tim.

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 14:00:29 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 14:00:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW7BE-0002QF-16; Thu, 01 Dec 2011 14:00:04 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RW7BC-0002Mm-0J
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 14:00:02 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-8.tower-174.messagelabs.com!1322747961!3849332!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14561 invoked from network); 1 Dec 2011 13:59:21 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-8.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 1 Dec 2011 13:59:21 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RW7AS-000GLQ-Ll; Thu, 01 Dec 2011 13:59:16 +0000
Date: Thu, 1 Dec 2011 13:59:16 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20111201135916.GB61203@ocelot.phlegethon.org>
References: <patchbomb.1320788543@xdev.gridcentric.ca>
	<6203a0549d8a1a21753b.1320788545@xdev.gridcentric.ca>
	<20111110125342.GG62117@ocelot.phlegethon.org>
	<4cb5acd8fa013dc40d5063d61296a319.squirrel@webmail.lagarcavilla.org>
	<20111124113507.GA77868@ocelot.phlegethon.org>
	<180057def2be9bc8eb519865f17aca96.squirrel@webmail.lagarcavilla.org>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <180057def2be9bc8eb519865f17aca96.squirrel@webmail.lagarcavilla.org>
User-Agent: Mutt/1.4.2.1i
Cc: olaf@aepfle.de, xen-devel@lists.xensource.com, george.dunlap@eu.citrix.com,
	andres@gridcentric.ca, keir.xen@gmail.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 2 of 3] Make p2m lookups fully synchronized
	wrt modifications
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 08:41 -0800 on 24 Nov (1322124101), Andres Lagar-Cavilla wrote:
> Here is one solution to consider: do not lock the p2m on lookups in shadow
> mode. Shadow mode does not support paging out and sharing of pages, which
> are primary reasons why we want synchronized p2m lookups. The hap cases
> where there is an inversion of the p2m_lock -> paging_lock order are
> reasonably simple to handle.
> 
> The other option is to invert the order and place paging_lock -> p2m_lock,
> but that will raise another set of potential inversions. I think this is a
> no go.

Is there scope for having the p2m lock split out into the overall one
(needed for allocations &c) and the per-record ones, and have them at
different levels in the lock hierarchy?

Tim.

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 14:00:48 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 14: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.xensource.com>)
	id 1RW7Bh-0002U5-Er; Thu, 01 Dec 2011 14:00:33 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1RW7Bg-0002T8-FE
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 14:00:32 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1322747991!7121368!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjc5MTU=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31367 invoked from network); 1 Dec 2011 13:59:52 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 13:59:52 -0000
X-IronPort-AV: E=Sophos;i="4.71,278,1320642000"; d="scan'208";a="172521668"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Dec 2011 08:59:51 -0500
Received: from [10.80.2.18] (10.80.2.18) by FTLPMAILMX02.citrite.net
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Thu, 1 Dec 2011
	08:59:50 -0500
Message-ID: <4ED78855.3080801@citrix.com>
Date: Thu, 1 Dec 2011 13:59:49 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.23) Gecko/20110921 Lightning/1.0b2 Thunderbird/3.1.15
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <CAFA7027.25E35%keir.xen@gmail.com> <4ED62C50.7060204@citrix.com>
	<4ED666D5.5060603@citrix.com>
	<4ED7522E0200007800064973@nat28.tlf.novell.com>
	<4ED74DAD.1040903@citrix.com>
	<4ED75E8402000078000649E6@nat28.tlf.novell.com>
	<4ED77347.6060200@citrix.com>
	<4ED787870200007800064B6F@nat28.tlf.novell.com>
In-Reply-To: <4ED787870200007800064B6F@nat28.tlf.novell.com>
X-Enigmail-Version: 1.1.2
Cc: Keir Fraser <keir.xen@gmail.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [RFC] KEXEC: allocate crash note buffers at boot
	time v3
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/12/11 12:56, Jan Beulich wrote:
>>>> On 01.12.11 at 13:29, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>> +static spinlock_t crash_notes_lock = SPIN_LOCK_UNLOCKED;
> Please use DEFINE_SPINLOCK() here.

Ok

>> +    register_keyhandler('C', &crashdump_trigger_keyhandler);
>> +
>> +    /* If no crash area, no need to allocate space for notes. */
>> +    if ( 0 == kexec_crash_area.size )
>> +        return 0;
> Wouldn't it make sense to switch the order of these?

Possibly.  In the case where a crash kernel has not been loaded, it
would degrade to a reboot, so it is still of some use if the there is no
kexec area.  Having said that, there is an explicit reboot handler, so
making this one disappear is probably a good thing.

>> +    crash_notes = xmalloc_bytes(nr_cpu_ids * sizeof(void*));
> Please use xmalloc_array() here.

Yes - it was dim of me to forget that.

>> +    if ( !crash_notes[nr] && 0 != kexec_init_cpu_notes(nr) )
> The first check is pointless - the function will return zero if the
> allocation was already done.

Good point - I missed that.

> Further, you shouldn't take a lock around a call to xmalloc() or alike
> unless absolutely necessary. It is pretty simple to avoid here - you
> really only need to lock around the storing of the pointer and maybe
> the setup_note() calls (but be careful with returning -ENOMEM - you
> shouldn't if the allocation fails, but you then find - under the lock -
> that a pointer was already set by another CPU).

So what we should do is this:

xmalloc
take lock
check to see if the entry is been filled in the meantime.  if so, free
the malloc'd region
release lock
only return -ENOMEM if we fail the malloc and the crash_note is still
NULL when we take the lock

I think this ought to cover all possible cases ?

(In reality I think the xmalloc itself should be covered by the fact we
will fail the !cpu_online(nr) test before we consider trying to
reallocate the buffer, but that doesn't preclude future proofing the code)

> Finally, one thing I failed to notice on the previous version - the
> nr_bytes calculations are now being done twice. This should
> probably be moved into a helper function, especially since you
> said you intend to add stuff here subsequently.

I had noticed this and was going to let it slide for now, considering
what would be best to do about it.  Playing with void pointers and
calculating lengths with sizeof is always more dangerous than
calculating a size, malloc'ing it and filling in a range start and size.

Given that it is such a rare codepath, I am honestly not sure which is
the better tradeof - an extra function call in 2 places or doubling the
size of the crash_notes array by introducing a size as well as a start. 
Both seem very minor in the grand scheme of things.

> Jan
>

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com


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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 14:00:48 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 14: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.xensource.com>)
	id 1RW7Bh-0002U5-Er; Thu, 01 Dec 2011 14:00:33 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1RW7Bg-0002T8-FE
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 14:00:32 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1322747991!7121368!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjc5MTU=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31367 invoked from network); 1 Dec 2011 13:59:52 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 13:59:52 -0000
X-IronPort-AV: E=Sophos;i="4.71,278,1320642000"; d="scan'208";a="172521668"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Dec 2011 08:59:51 -0500
Received: from [10.80.2.18] (10.80.2.18) by FTLPMAILMX02.citrite.net
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Thu, 1 Dec 2011
	08:59:50 -0500
Message-ID: <4ED78855.3080801@citrix.com>
Date: Thu, 1 Dec 2011 13:59:49 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.23) Gecko/20110921 Lightning/1.0b2 Thunderbird/3.1.15
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <CAFA7027.25E35%keir.xen@gmail.com> <4ED62C50.7060204@citrix.com>
	<4ED666D5.5060603@citrix.com>
	<4ED7522E0200007800064973@nat28.tlf.novell.com>
	<4ED74DAD.1040903@citrix.com>
	<4ED75E8402000078000649E6@nat28.tlf.novell.com>
	<4ED77347.6060200@citrix.com>
	<4ED787870200007800064B6F@nat28.tlf.novell.com>
In-Reply-To: <4ED787870200007800064B6F@nat28.tlf.novell.com>
X-Enigmail-Version: 1.1.2
Cc: Keir Fraser <keir.xen@gmail.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [RFC] KEXEC: allocate crash note buffers at boot
	time v3
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/12/11 12:56, Jan Beulich wrote:
>>>> On 01.12.11 at 13:29, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>> +static spinlock_t crash_notes_lock = SPIN_LOCK_UNLOCKED;
> Please use DEFINE_SPINLOCK() here.

Ok

>> +    register_keyhandler('C', &crashdump_trigger_keyhandler);
>> +
>> +    /* If no crash area, no need to allocate space for notes. */
>> +    if ( 0 == kexec_crash_area.size )
>> +        return 0;
> Wouldn't it make sense to switch the order of these?

Possibly.  In the case where a crash kernel has not been loaded, it
would degrade to a reboot, so it is still of some use if the there is no
kexec area.  Having said that, there is an explicit reboot handler, so
making this one disappear is probably a good thing.

>> +    crash_notes = xmalloc_bytes(nr_cpu_ids * sizeof(void*));
> Please use xmalloc_array() here.

Yes - it was dim of me to forget that.

>> +    if ( !crash_notes[nr] && 0 != kexec_init_cpu_notes(nr) )
> The first check is pointless - the function will return zero if the
> allocation was already done.

Good point - I missed that.

> Further, you shouldn't take a lock around a call to xmalloc() or alike
> unless absolutely necessary. It is pretty simple to avoid here - you
> really only need to lock around the storing of the pointer and maybe
> the setup_note() calls (but be careful with returning -ENOMEM - you
> shouldn't if the allocation fails, but you then find - under the lock -
> that a pointer was already set by another CPU).

So what we should do is this:

xmalloc
take lock
check to see if the entry is been filled in the meantime.  if so, free
the malloc'd region
release lock
only return -ENOMEM if we fail the malloc and the crash_note is still
NULL when we take the lock

I think this ought to cover all possible cases ?

(In reality I think the xmalloc itself should be covered by the fact we
will fail the !cpu_online(nr) test before we consider trying to
reallocate the buffer, but that doesn't preclude future proofing the code)

> Finally, one thing I failed to notice on the previous version - the
> nr_bytes calculations are now being done twice. This should
> probably be moved into a helper function, especially since you
> said you intend to add stuff here subsequently.

I had noticed this and was going to let it slide for now, considering
what would be best to do about it.  Playing with void pointers and
calculating lengths with sizeof is always more dangerous than
calculating a size, malloc'ing it and filling in a range start and size.

Given that it is such a rare codepath, I am honestly not sure which is
the better tradeof - an extra function call in 2 places or doubling the
size of the crash_notes array by introducing a size as well as a start. 
Both seem very minor in the grand scheme of things.

> Jan
>

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com


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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 14:01:45 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 14:01:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW7CV-0002ZJ-Tf; Thu, 01 Dec 2011 14:01:23 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1RW7CT-0002YW-Tx
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 14:01:22 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1322748040!5720249!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjc5MTU=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14598 invoked from network); 1 Dec 2011 14:00:42 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 14:00:42 -0000
X-IronPort-AV: E=Sophos;i="4.71,278,1320642000"; d="scan'208";a="172521797"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Dec 2011 09:00:40 -0500
Received: from [10.80.2.18] (10.80.2.18) by FTLPMAILMX02.citrite.net
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Thu, 1 Dec 2011
	09:00:39 -0500
Message-ID: <4ED78886.6070101@citrix.com>
Date: Thu, 1 Dec 2011 14:00:38 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.23) Gecko/20110921 Lightning/1.0b2 Thunderbird/3.1.15
MIME-Version: 1.0
To: Keir Fraser <keir.xen@gmail.com>
References: <CAFCBF30.262CB%keir.xen@gmail.com>
In-Reply-To: <CAFCBF30.262CB%keir.xen@gmail.com>
X-Enigmail-Version: 1.1.2
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [RFC] KEXEC: allocate crash note buffers at boot
	time v3
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/12/11 05:20, Keir Fraser wrote:
> On 01/12/2011 12:56, "Jan Beulich" <JBeulich@suse.com> wrote:
>
>>> +    register_keyhandler('C', &crashdump_trigger_keyhandler);
>>> +
>>> +    /* If no crash area, no need to allocate space for notes. */
>>> +    if ( 0 == kexec_crash_area.size )
>>> +        return 0;
>> Wouldn't it make sense to switch the order of these?
> I also really hate this constant-first ordering.
>
>  -- Keir
>

It was a useful habit I got into when learning C/C++ and has stayed with
me.  I will endeavor to not do it.

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com


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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 14:01:45 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 14:01:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW7CV-0002ZJ-Tf; Thu, 01 Dec 2011 14:01:23 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1RW7CT-0002YW-Tx
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 14:01:22 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1322748040!5720249!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjc5MTU=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14598 invoked from network); 1 Dec 2011 14:00:42 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 14:00:42 -0000
X-IronPort-AV: E=Sophos;i="4.71,278,1320642000"; d="scan'208";a="172521797"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Dec 2011 09:00:40 -0500
Received: from [10.80.2.18] (10.80.2.18) by FTLPMAILMX02.citrite.net
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Thu, 1 Dec 2011
	09:00:39 -0500
Message-ID: <4ED78886.6070101@citrix.com>
Date: Thu, 1 Dec 2011 14:00:38 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.23) Gecko/20110921 Lightning/1.0b2 Thunderbird/3.1.15
MIME-Version: 1.0
To: Keir Fraser <keir.xen@gmail.com>
References: <CAFCBF30.262CB%keir.xen@gmail.com>
In-Reply-To: <CAFCBF30.262CB%keir.xen@gmail.com>
X-Enigmail-Version: 1.1.2
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [RFC] KEXEC: allocate crash note buffers at boot
	time v3
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/12/11 05:20, Keir Fraser wrote:
> On 01/12/2011 12:56, "Jan Beulich" <JBeulich@suse.com> wrote:
>
>>> +    register_keyhandler('C', &crashdump_trigger_keyhandler);
>>> +
>>> +    /* If no crash area, no need to allocate space for notes. */
>>> +    if ( 0 == kexec_crash_area.size )
>>> +        return 0;
>> Wouldn't it make sense to switch the order of these?
> I also really hate this constant-first ordering.
>
>  -- Keir
>

It was a useful habit I got into when learning C/C++ and has stayed with
me.  I will endeavor to not do it.

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com


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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 14:02:40 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 14:02:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW7DW-0002kx-I7; Thu, 01 Dec 2011 14:02:26 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RW7DV-0002kb-Qu
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 14:02:26 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-10.tower-27.messagelabs.com!1322748075!46194681!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28375 invoked from network); 1 Dec 2011 14:01:15 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-10.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 1 Dec 2011 14:01:15 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RW7Cw-000GMK-Mk; Thu, 01 Dec 2011 14:01:50 +0000
Date: Thu, 1 Dec 2011 14:01:50 +0000
From: Tim Deegan <tim@xen.org>
To: Olaf Hering <olaf@aepfle.de>
Message-ID: <20111201140150.GC61203@ocelot.phlegethon.org>
References: <patchbomb.1322737756@probook.site>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <patchbomb.1322737756@probook.site>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 0 of 4] RFC: wait queue usage
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 12:09 +0100 on 01 Dec (1322741356), Olaf Hering wrote:
> 
> The following series is my current state of an attempt to use wait queues for
> xenpaging and mem_event handling. I post it here for review and comments.
> 
> This series conflicts with work from Andres Lagar-Cavilla.

Can you be clear about which of Andres's patchsets you are objecting to?
I have five series (!) of his on my todo list right now. 

Tim.

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 14:02:40 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 14:02:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW7DW-0002kx-I7; Thu, 01 Dec 2011 14:02:26 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RW7DV-0002kb-Qu
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 14:02:26 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-10.tower-27.messagelabs.com!1322748075!46194681!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28375 invoked from network); 1 Dec 2011 14:01:15 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-10.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 1 Dec 2011 14:01:15 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RW7Cw-000GMK-Mk; Thu, 01 Dec 2011 14:01:50 +0000
Date: Thu, 1 Dec 2011 14:01:50 +0000
From: Tim Deegan <tim@xen.org>
To: Olaf Hering <olaf@aepfle.de>
Message-ID: <20111201140150.GC61203@ocelot.phlegethon.org>
References: <patchbomb.1322737756@probook.site>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <patchbomb.1322737756@probook.site>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 0 of 4] RFC: wait queue usage
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 12:09 +0100 on 01 Dec (1322741356), Olaf Hering wrote:
> 
> The following series is my current state of an attempt to use wait queues for
> xenpaging and mem_event handling. I post it here for review and comments.
> 
> This series conflicts with work from Andres Lagar-Cavilla.

Can you be clear about which of Andres's patchsets you are objecting to?
I have five series (!) of his on my todo list right now. 

Tim.

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 14:13:39 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 14:13:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW7O7-0003MB-Od; Thu, 01 Dec 2011 14:13:23 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RW7O6-0003M6-Cf
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 14:13:22 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-10.tower-21.messagelabs.com!1322748761!6488085!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNDUxMTM=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNDUxMTM=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7558 invoked from network); 1 Dec 2011 14:12:42 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-10.tower-21.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 1 Dec 2011 14:12:42 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1322748761; l=928;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=RSbCQ9CbuFji+/nHYdPwNiNiC0E=;
	b=CgG5A4sFoTHH3u1sq1yLq2+pSUZFhZB7ExHHGkNWLkMMS94CG6ecKBaFhP3GeN7bEfG
	zxX9ZzYGBLqXVeUqiNqOBfKLn3Ggi2919G6CHga3GDaxq60ahTzJJ7dLE/pvGax42f3p0
	vH0NXfghp6FtAcm83hkp5mRexdAjMhhNHrw=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/ll2c7pE6jG
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-080-213.pools.arcor-ip.net [84.57.80.213])
	by smtp.strato.de (klopstock mo63) (RZmta 26.10 AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id 205b10nB1CoJnL ;
	Thu, 1 Dec 2011 15:12:24 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 5218518637; Thu,  1 Dec 2011 15:12:24 +0100 (CET)
Date: Thu, 1 Dec 2011 15:12:24 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Message-ID: <20111201141224.GA12300@aepfle.de>
References: <1322578893-9998-1-git-send-email-ian.jackson@eu.citrix.com>
	<1322578893-9998-5-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1322578893-9998-5-git-send-email-ian.jackson@eu.citrix.com>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 4/4] docs/html/: Arrange for automatic build
 of hypercall docs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Nov 29, Ian Jackson wrote:

> - Use index.html rather than a stamp file.
> - Automatically generate dependencies.
> - Wire into the docs build system
> 

> +-include html/hypercall/.deps

This creates a new .deps file which is also installed during make
install. Unfortunately the rpm post-build checks reject such a file and
the package build fails. My quick hack to remove it during make install
looks like this:

--- a/docs/Makefile
+++ b/docs/Makefile
@@ -102,7 +102,7 @@ install: all
 	$(INSTALL_DIR) $(DESTDIR)$(MANDIR)
 	cp -dR man1 $(DESTDIR)$(MANDIR)
 	cp -dR man5 $(DESTDIR)$(MANDIR)
-	[ ! -d html ] || cp -dR html $(DESTDIR)$(DOCDIR)
+	if [ -d html ] ; then cp -dR html $(DESTDIR)$(DOCDIR) ; find $(DESTDIR)$(DOCDIR) -name .deps -print0 | xargs -0 --no-run-if-empty rm -f ; fi
 
 pdf/%.pdf: ps/%.ps
 	$(INSTALL_DIR) $(@D)


There is probably a better way to get rid of the file.

Olaf

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 14:13:39 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 14:13:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW7O7-0003MB-Od; Thu, 01 Dec 2011 14:13:23 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RW7O6-0003M6-Cf
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 14:13:22 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-10.tower-21.messagelabs.com!1322748761!6488085!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNDUxMTM=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNDUxMTM=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7558 invoked from network); 1 Dec 2011 14:12:42 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-10.tower-21.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 1 Dec 2011 14:12:42 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1322748761; l=928;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=RSbCQ9CbuFji+/nHYdPwNiNiC0E=;
	b=CgG5A4sFoTHH3u1sq1yLq2+pSUZFhZB7ExHHGkNWLkMMS94CG6ecKBaFhP3GeN7bEfG
	zxX9ZzYGBLqXVeUqiNqOBfKLn3Ggi2919G6CHga3GDaxq60ahTzJJ7dLE/pvGax42f3p0
	vH0NXfghp6FtAcm83hkp5mRexdAjMhhNHrw=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/ll2c7pE6jG
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-080-213.pools.arcor-ip.net [84.57.80.213])
	by smtp.strato.de (klopstock mo63) (RZmta 26.10 AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id 205b10nB1CoJnL ;
	Thu, 1 Dec 2011 15:12:24 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 5218518637; Thu,  1 Dec 2011 15:12:24 +0100 (CET)
Date: Thu, 1 Dec 2011 15:12:24 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Message-ID: <20111201141224.GA12300@aepfle.de>
References: <1322578893-9998-1-git-send-email-ian.jackson@eu.citrix.com>
	<1322578893-9998-5-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1322578893-9998-5-git-send-email-ian.jackson@eu.citrix.com>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 4/4] docs/html/: Arrange for automatic build
 of hypercall docs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Nov 29, Ian Jackson wrote:

> - Use index.html rather than a stamp file.
> - Automatically generate dependencies.
> - Wire into the docs build system
> 

> +-include html/hypercall/.deps

This creates a new .deps file which is also installed during make
install. Unfortunately the rpm post-build checks reject such a file and
the package build fails. My quick hack to remove it during make install
looks like this:

--- a/docs/Makefile
+++ b/docs/Makefile
@@ -102,7 +102,7 @@ install: all
 	$(INSTALL_DIR) $(DESTDIR)$(MANDIR)
 	cp -dR man1 $(DESTDIR)$(MANDIR)
 	cp -dR man5 $(DESTDIR)$(MANDIR)
-	[ ! -d html ] || cp -dR html $(DESTDIR)$(DOCDIR)
+	if [ -d html ] ; then cp -dR html $(DESTDIR)$(DOCDIR) ; find $(DESTDIR)$(DOCDIR) -name .deps -print0 | xargs -0 --no-run-if-empty rm -f ; fi
 
 pdf/%.pdf: ps/%.ps
 	$(INSTALL_DIR) $(@D)


There is probably a better way to get rid of the file.

Olaf

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 14:20:21 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 14:20:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW7UZ-0003Xt-OZ; Thu, 01 Dec 2011 14:20:03 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RW7UY-0003Xh-9x
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 14:20:02 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-4.tower-27.messagelabs.com!1322749131!50746038!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNDUxMTM=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNDUxMTM=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13160 invoked from network); 1 Dec 2011 14:18:52 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-4.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 1 Dec 2011 14:18:52 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1322749161; l=698;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=dnSVAiymK8qVaeInMIIjP22LZGc=;
	b=L1RBEKjzNlYfhk0cPHNCdRyknt2r0HCM01JD11VNTDNNNZG4pmFwTY3s31BvB6FY2B/
	4q4a5kJ5/RdX0s3+9coHb43w9oKQsZjh7F4YHmLci8/rphvmjkY6I9KwJO0/Pj4sUHAuf
	QcRIE1rPEDRsQVddz9b3GX4MJfIt5VoHBgs=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/ll2c7pE6jG
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-080-213.pools.arcor-ip.net [84.57.80.213])
	by smtp.strato.de (jimi mo61) (RZmta 26.10 AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id o05a7fnB1D3Oy2 ;
	Thu, 1 Dec 2011 15:19:17 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id B095D18637; Thu,  1 Dec 2011 15:19:16 +0100 (CET)
Date: Thu, 1 Dec 2011 15:19:16 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Tim Deegan <tim@xen.org>
Message-ID: <20111201141916.GA12840@aepfle.de>
References: <patchbomb.1322737756@probook.site>
	<20111201140150.GC61203@ocelot.phlegethon.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20111201140150.GC61203@ocelot.phlegethon.org>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 0 of 4] RFC: wait queue usage
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Dec 01, Tim Deegan wrote:

> At 12:09 +0100 on 01 Dec (1322741356), Olaf Hering wrote:
> > 
> > The following series is my current state of an attempt to use wait queues for
> > xenpaging and mem_event handling. I post it here for review and comments.
> > 
> > This series conflicts with work from Andres Lagar-Cavilla.
> 
> Can you be clear about which of Andres's patchsets you are objecting to?
> I have five series (!) of his on my todo list right now. 

The "Improve ring management for memory events" change which tries to
achieve the same result as my "mem_event: use wait queue when ring is
full" change.
There is already a discussion about which way to choose.

Olaf

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 14:20:21 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 14:20:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW7UZ-0003Xt-OZ; Thu, 01 Dec 2011 14:20:03 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RW7UY-0003Xh-9x
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 14:20:02 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-4.tower-27.messagelabs.com!1322749131!50746038!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNDUxMTM=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNDUxMTM=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13160 invoked from network); 1 Dec 2011 14:18:52 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-4.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 1 Dec 2011 14:18:52 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1322749161; l=698;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=dnSVAiymK8qVaeInMIIjP22LZGc=;
	b=L1RBEKjzNlYfhk0cPHNCdRyknt2r0HCM01JD11VNTDNNNZG4pmFwTY3s31BvB6FY2B/
	4q4a5kJ5/RdX0s3+9coHb43w9oKQsZjh7F4YHmLci8/rphvmjkY6I9KwJO0/Pj4sUHAuf
	QcRIE1rPEDRsQVddz9b3GX4MJfIt5VoHBgs=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/ll2c7pE6jG
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-080-213.pools.arcor-ip.net [84.57.80.213])
	by smtp.strato.de (jimi mo61) (RZmta 26.10 AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id o05a7fnB1D3Oy2 ;
	Thu, 1 Dec 2011 15:19:17 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id B095D18637; Thu,  1 Dec 2011 15:19:16 +0100 (CET)
Date: Thu, 1 Dec 2011 15:19:16 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Tim Deegan <tim@xen.org>
Message-ID: <20111201141916.GA12840@aepfle.de>
References: <patchbomb.1322737756@probook.site>
	<20111201140150.GC61203@ocelot.phlegethon.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20111201140150.GC61203@ocelot.phlegethon.org>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 0 of 4] RFC: wait queue usage
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Dec 01, Tim Deegan wrote:

> At 12:09 +0100 on 01 Dec (1322741356), Olaf Hering wrote:
> > 
> > The following series is my current state of an attempt to use wait queues for
> > xenpaging and mem_event handling. I post it here for review and comments.
> > 
> > This series conflicts with work from Andres Lagar-Cavilla.
> 
> Can you be clear about which of Andres's patchsets you are objecting to?
> I have five series (!) of his on my todo list right now. 

The "Improve ring management for memory events" change which tries to
achieve the same result as my "mem_event: use wait queue when ring is
full" change.
There is already a discussion about which way to choose.

Olaf

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 14:23:06 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 14: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.xensource.com>)
	id 1RW7XD-0003gc-B6; Thu, 01 Dec 2011 14:22:47 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>)
	id 1RW7XB-0003gK-A0; Thu, 01 Dec 2011 14:22:45 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-10.tower-21.messagelabs.com!1322749317!6489793!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19833 invoked from network); 1 Dec 2011 14:22:04 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-10.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 1 Dec 2011 14:22:04 -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
	pB1ELs9B001366
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Thu, 1 Dec 2011 09:21:54 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pB1ELsYw001364;
	Thu, 1 Dec 2011 09:21:54 -0500
Date: Thu, 1 Dec 2011 10:21:54 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Artur Baruchi <mail.baruchi@gmail.com>
Message-ID: <20111201142154.GA336@andromeda.dapyr.net>
References: <CAAiDW_RNUWUUm7rsgXUMJnc6gnQ7FbEv0eVX-tJQ+PAnjrOmeg@mail.gmail.com>
	<CAAiDW_Trg-B8Bq=sjnedZoxjxi2T+H=ADvuiBdE8jr+B1a5Jgg@mail.gmail.com>
	<20111130221545.GB16651@andromeda.dapyr.net>
	<CAAiDW_T2Eutw=NibLv2s1f1DJsbSY39oHL_pH8RkmAi=iWK0HA@mail.gmail.com>
	<20111201031601.GA32261@andromeda.dapyr.net>
	<CAG1y0sfjmeDoLJ131TV-GUphhcuu+LcmJLJC-3h5=DzMKe7Jmg@mail.gmail.com>
	<CAAiDW_SRBf2jx_q=CysoQq8c=JDM6gXSfnpBvOi-z6=wSCmaDg@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAAiDW_SRBf2jx_q=CysoQq8c=JDM6gXSfnpBvOi-z6=wSCmaDg@mail.gmail.com>
User-Agent: Mutt/1.5.9i
Cc: Xen-devel@lists.xensource.com, xen-users <Xen-users@lists.xensource.com>,
	"Fajar A. Nugraha" <list@fajar.net>
Subject: Re: [Xen-devel] VM Hanging after reboot
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Dec 01, 2011 at 08:41:20AM -0200, Artur Baruchi wrote:
> Hi.
> 
> The error is within the guest (HVM virtual machine).
> 

OK, then ata messages.. point to it being the HVM driver - so no
usage of the PV drivers. Unless there is a switch-over happening where
the guest tells QEMU: "Hey, I am done with the HVM driver, please
disconnect it" and it switches the PV driver on.

Just to remove that possiblity, did you boot the guest with
'xen_emul_unplug=never' ?

Hmm, and the comment about "went away after I used vanilla 3.1.0"
is rather strange. Did you also switch the hypervisor and the tools?
Or did youkeep on using the ones provided by the distro?

Either way, happy to see that the vanilla 3.1 kernel fixes the issue.
> Thanks.
> 
> Att.
> Artur Baruchi
> 
> 
> 
> On Thu, Dec 1, 2011 at 1:28 AM, Fajar A. Nugraha <list@fajar.net> wrote:
> > On Thu, Dec 1, 2011 at 10:16 AM, Konrad Rzeszutek Wilk
> > <konrad@darnok.org> wrote:
> >> On Wed, Nov 30, 2011 at 09:09:58PM -0200, Artur Baruchi wrote:
> >>> Hi Konrad.
> >>>
> >>> That was my first though (disk going bad). But I create another VM in
> >>> a different host and faced the same error. I tried to create another
> >>
> >> So is the error from within the guest or from the dom0?
> >>
> >
> > As Konrad asked, is the error in dom0 or domU?
> >
> > If dom0, then most likely it's disk problem. One way to diagnose it is
> > by reading from the disk (dd_rescue is nice) and see if at least it's
> > able to read the disk completely.
> >
> > If domU, then it's probably a bug in dom0 kernel (the blkback driver,
> > perhaps). In which case novell guys might be able to help you more. I
> > recall something like this when using older kernel for dom0 (forgot
> > the exact version, sorry), but the error went away after I used
> > vanilla 3.1.0 for dom0 kernel.
> >
> > --
> > Fajar
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 14:23:06 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 14: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.xensource.com>)
	id 1RW7XD-0003gc-B6; Thu, 01 Dec 2011 14:22:47 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>)
	id 1RW7XB-0003gK-A0; Thu, 01 Dec 2011 14:22:45 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-10.tower-21.messagelabs.com!1322749317!6489793!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19833 invoked from network); 1 Dec 2011 14:22:04 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-10.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 1 Dec 2011 14:22:04 -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
	pB1ELs9B001366
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Thu, 1 Dec 2011 09:21:54 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pB1ELsYw001364;
	Thu, 1 Dec 2011 09:21:54 -0500
Date: Thu, 1 Dec 2011 10:21:54 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Artur Baruchi <mail.baruchi@gmail.com>
Message-ID: <20111201142154.GA336@andromeda.dapyr.net>
References: <CAAiDW_RNUWUUm7rsgXUMJnc6gnQ7FbEv0eVX-tJQ+PAnjrOmeg@mail.gmail.com>
	<CAAiDW_Trg-B8Bq=sjnedZoxjxi2T+H=ADvuiBdE8jr+B1a5Jgg@mail.gmail.com>
	<20111130221545.GB16651@andromeda.dapyr.net>
	<CAAiDW_T2Eutw=NibLv2s1f1DJsbSY39oHL_pH8RkmAi=iWK0HA@mail.gmail.com>
	<20111201031601.GA32261@andromeda.dapyr.net>
	<CAG1y0sfjmeDoLJ131TV-GUphhcuu+LcmJLJC-3h5=DzMKe7Jmg@mail.gmail.com>
	<CAAiDW_SRBf2jx_q=CysoQq8c=JDM6gXSfnpBvOi-z6=wSCmaDg@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAAiDW_SRBf2jx_q=CysoQq8c=JDM6gXSfnpBvOi-z6=wSCmaDg@mail.gmail.com>
User-Agent: Mutt/1.5.9i
Cc: Xen-devel@lists.xensource.com, xen-users <Xen-users@lists.xensource.com>,
	"Fajar A. Nugraha" <list@fajar.net>
Subject: Re: [Xen-devel] VM Hanging after reboot
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Dec 01, 2011 at 08:41:20AM -0200, Artur Baruchi wrote:
> Hi.
> 
> The error is within the guest (HVM virtual machine).
> 

OK, then ata messages.. point to it being the HVM driver - so no
usage of the PV drivers. Unless there is a switch-over happening where
the guest tells QEMU: "Hey, I am done with the HVM driver, please
disconnect it" and it switches the PV driver on.

Just to remove that possiblity, did you boot the guest with
'xen_emul_unplug=never' ?

Hmm, and the comment about "went away after I used vanilla 3.1.0"
is rather strange. Did you also switch the hypervisor and the tools?
Or did youkeep on using the ones provided by the distro?

Either way, happy to see that the vanilla 3.1 kernel fixes the issue.
> Thanks.
> 
> Att.
> Artur Baruchi
> 
> 
> 
> On Thu, Dec 1, 2011 at 1:28 AM, Fajar A. Nugraha <list@fajar.net> wrote:
> > On Thu, Dec 1, 2011 at 10:16 AM, Konrad Rzeszutek Wilk
> > <konrad@darnok.org> wrote:
> >> On Wed, Nov 30, 2011 at 09:09:58PM -0200, Artur Baruchi wrote:
> >>> Hi Konrad.
> >>>
> >>> That was my first though (disk going bad). But I create another VM in
> >>> a different host and faced the same error. I tried to create another
> >>
> >> So is the error from within the guest or from the dom0?
> >>
> >
> > As Konrad asked, is the error in dom0 or domU?
> >
> > If dom0, then most likely it's disk problem. One way to diagnose it is
> > by reading from the disk (dd_rescue is nice) and see if at least it's
> > able to read the disk completely.
> >
> > If domU, then it's probably a bug in dom0 kernel (the blkback driver,
> > perhaps). In which case novell guys might be able to help you more. I
> > recall something like this when using older kernel for dom0 (forgot
> > the exact version, sorry), but the error went away after I used
> > vanilla 3.1.0 for dom0 kernel.
> >
> > --
> > Fajar
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 14:26:11 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 14: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.xensource.com>)
	id 1RW7aG-0003qe-31; Thu, 01 Dec 2011 14:25:56 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RW7aE-0003pz-GO
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 14:25:54 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1322749513!3832090!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU2Nw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16698 invoked from network); 1 Dec 2011 14:25:14 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 14:25:14 -0000
X-IronPort-AV: E=Sophos;i="4.71,278,1320624000"; 
   d="scan'208";a="9232332"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Dec 2011 14:25:08 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 1 Dec 2011
	14:25:08 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Paul Durrant <Paul.Durrant@citrix.com>
Date: Thu, 1 Dec 2011 14:25:08 +0000
In-Reply-To: <291EDFCB1E9E224A99088639C4762022B5988E50FE@LONPMAILBOX01.citrite.net>
References: <94a17182f386c8bb414e.1322686717@cosworth.uk.xensource.com>
	<20111130221419.GA16651@andromeda.dapyr.net>
	<291EDFCB1E9E224A99088639C4762022B5988E50D4@LONPMAILBOX01.citrite.net>
	<1322729947.31810.151.camel@zakaz.uk.xensource.com>
	<291EDFCB1E9E224A99088639C4762022B5988E50EA@LONPMAILBOX01.citrite.net>
	<1322733621.31810.176.camel@zakaz.uk.xensource.com>
	<291EDFCB1E9E224A99088639C4762022B5988E50FE@LONPMAILBOX01.citrite.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322749508.31810.215.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] Add code to track the address of the VM
 generation id buffer across a
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2011-12-01 at 11:54 +0000, Paul Durrant wrote:
> Would the following be sufficient?
> 
>   Paul
> 
> diff -r 62ff6a318c5d docs/man/xl.cfg.pod.5
> --- a/docs/man/xl.cfg.pod.5     Wed Nov 30 16:59:58 2011 -0800
> +++ b/docs/man/xl.cfg.pod.5     Thu Dec 01 11:52:58 2011 +0000
> @@ -484,6 +484,12 @@ of Xen) within a Xen guest or to support
>  which uses hardware virtualisation extensions (e.g. Windows XP
>  compatibility mode on more modern Windows OS).
> 
> +=item B<generation_id=NUMBER>
> +
> +This value will be exposed inside the guest at an address which
> +can be determined by evaluating the ADDR package of an ACPI device
> +with _CID "VM_Gen_Counter".

Belongs more in the "Support for Paravirtualisation of HVM Guests"
section, which is just below? The "Processor and Platform Features" is
more about things which are optional (at least in theory) on real
systems.

Since the semantics of the number itself are up to the toolstack and
this toolstack defers this requirement up to the user it should probably
also say something along the lines of:

        The semantics of this value are guest dependent and it is up to
        the user to ensure those semantics are met.

(even better would be to implement something meaningful in xl,
obviously)

Ian.

> +
>  =back
> 
>  =head3 Guest Virtual Time Controls
> diff -r 62ff6a318c5d tools/firmware/hvmloader/acpi/dsdt.asl
> --- a/tools/firmware/hvmloader/acpi/dsdt.asl    Wed Nov 30 16:59:58 2011 -0800
> +++ b/tools/firmware/hvmloader/acpi/dsdt.asl    Thu Dec 01 11:52:58 2011 +0000
> @@ -398,6 +398,25 @@ DefinitionBlock ("DSDT.aml", "DSDT", 2,
>                      })
>                  }
> 
> +                /* VM Generation ID Device
> +                 *
> +                 * The basic requirements of this device are as follows:
> +                 *
> +                 * - It must be exposed somewhere in ACPI namespace with a _CID of
> +                 *   "VM_Gen_Counter".
> +                 * - It must also include a _DDN of "VM_Gen_Counter".
> +                 * - It must contain a _HID object but no particular value is
> +                 *   required.
> +                 * - It must expose a package called ADDR which evaluates to two
> +                 *   integers; the first being the low order 32-bits of a guest
> +                 *   physical address (GPA), the second by the high order 32-bits of
> +                 *   the GPA. This GPA is the address of an 8-byte aligned 8-byte
> +                 *   buffer containing the VM generation ID.
> +                 *   This buffer must not be in ranges supported as AddressRangeMemory
> +                 *   or AddressRangeACPI and must not be mapped by any PTE with caching
> +                 *   disabled. (See the code in tools/firmware/hvmloader/acpi/build.c
> +                 *   which determines the address and contents of the buffer).
> +                 */
>                  Device(VGID) {
>                      Name(_HID, EisaID ("PNP0A06"))
>                      Name(_UID, 0x00)
> 
> > -----Original Message-----
> > From: Ian Campbell
> > Sent: 01 December 2011 10:00
> > To: Paul Durrant
> > Cc: Konrad Rzeszutek Wilk; xen-devel@lists.xensource.com
> > Subject: RE: [Xen-devel] [PATCH] Add code to track the address of
> > the VM generation id buffer across a
> > 
> > On Thu, 2011-12-01 at 09:47 +0000, Paul Durrant wrote:
> > > > -----Original Message-----
> > > > From: Ian Campbell
> > > > Sent: 01 December 2011 08:59
> > > > To: Paul Durrant
> > > > Cc: Konrad Rzeszutek Wilk; xen-devel@lists.xensource.com
> > > > Subject: Re: [Xen-devel] [PATCH] Add code to track the address
> > of
> > > > the VM generation id buffer across a
> > > >
> > > > On Thu, 2011-12-01 at 08:46 +0000, Paul Durrant wrote:
> > > > > Konrad,
> > > > >
> > > > >   Did you see my previous patch set? The introductory comment
> > was:
> > > >
> > > >
> > > > I think that description belongs somewhere permanent, either in
> > > > docs/misc or as a comment in an appropriate header.
> > > >
> > >
> > > Good point. Perhaps I should stick the comment just above the
> > device description in the dsdt?
> > 
> > That would do I guess.
> > 
> > I guess more important would be the user facing toolstack specific
> > semantics/documentation i.e. the manpage.
> > 
> > Ian.
> > 
> 



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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 14:26:11 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 14: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.xensource.com>)
	id 1RW7aG-0003qe-31; Thu, 01 Dec 2011 14:25:56 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RW7aE-0003pz-GO
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 14:25:54 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1322749513!3832090!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU2Nw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16698 invoked from network); 1 Dec 2011 14:25:14 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 14:25:14 -0000
X-IronPort-AV: E=Sophos;i="4.71,278,1320624000"; 
   d="scan'208";a="9232332"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Dec 2011 14:25:08 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 1 Dec 2011
	14:25:08 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Paul Durrant <Paul.Durrant@citrix.com>
Date: Thu, 1 Dec 2011 14:25:08 +0000
In-Reply-To: <291EDFCB1E9E224A99088639C4762022B5988E50FE@LONPMAILBOX01.citrite.net>
References: <94a17182f386c8bb414e.1322686717@cosworth.uk.xensource.com>
	<20111130221419.GA16651@andromeda.dapyr.net>
	<291EDFCB1E9E224A99088639C4762022B5988E50D4@LONPMAILBOX01.citrite.net>
	<1322729947.31810.151.camel@zakaz.uk.xensource.com>
	<291EDFCB1E9E224A99088639C4762022B5988E50EA@LONPMAILBOX01.citrite.net>
	<1322733621.31810.176.camel@zakaz.uk.xensource.com>
	<291EDFCB1E9E224A99088639C4762022B5988E50FE@LONPMAILBOX01.citrite.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322749508.31810.215.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] Add code to track the address of the VM
 generation id buffer across a
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2011-12-01 at 11:54 +0000, Paul Durrant wrote:
> Would the following be sufficient?
> 
>   Paul
> 
> diff -r 62ff6a318c5d docs/man/xl.cfg.pod.5
> --- a/docs/man/xl.cfg.pod.5     Wed Nov 30 16:59:58 2011 -0800
> +++ b/docs/man/xl.cfg.pod.5     Thu Dec 01 11:52:58 2011 +0000
> @@ -484,6 +484,12 @@ of Xen) within a Xen guest or to support
>  which uses hardware virtualisation extensions (e.g. Windows XP
>  compatibility mode on more modern Windows OS).
> 
> +=item B<generation_id=NUMBER>
> +
> +This value will be exposed inside the guest at an address which
> +can be determined by evaluating the ADDR package of an ACPI device
> +with _CID "VM_Gen_Counter".

Belongs more in the "Support for Paravirtualisation of HVM Guests"
section, which is just below? The "Processor and Platform Features" is
more about things which are optional (at least in theory) on real
systems.

Since the semantics of the number itself are up to the toolstack and
this toolstack defers this requirement up to the user it should probably
also say something along the lines of:

        The semantics of this value are guest dependent and it is up to
        the user to ensure those semantics are met.

(even better would be to implement something meaningful in xl,
obviously)

Ian.

> +
>  =back
> 
>  =head3 Guest Virtual Time Controls
> diff -r 62ff6a318c5d tools/firmware/hvmloader/acpi/dsdt.asl
> --- a/tools/firmware/hvmloader/acpi/dsdt.asl    Wed Nov 30 16:59:58 2011 -0800
> +++ b/tools/firmware/hvmloader/acpi/dsdt.asl    Thu Dec 01 11:52:58 2011 +0000
> @@ -398,6 +398,25 @@ DefinitionBlock ("DSDT.aml", "DSDT", 2,
>                      })
>                  }
> 
> +                /* VM Generation ID Device
> +                 *
> +                 * The basic requirements of this device are as follows:
> +                 *
> +                 * - It must be exposed somewhere in ACPI namespace with a _CID of
> +                 *   "VM_Gen_Counter".
> +                 * - It must also include a _DDN of "VM_Gen_Counter".
> +                 * - It must contain a _HID object but no particular value is
> +                 *   required.
> +                 * - It must expose a package called ADDR which evaluates to two
> +                 *   integers; the first being the low order 32-bits of a guest
> +                 *   physical address (GPA), the second by the high order 32-bits of
> +                 *   the GPA. This GPA is the address of an 8-byte aligned 8-byte
> +                 *   buffer containing the VM generation ID.
> +                 *   This buffer must not be in ranges supported as AddressRangeMemory
> +                 *   or AddressRangeACPI and must not be mapped by any PTE with caching
> +                 *   disabled. (See the code in tools/firmware/hvmloader/acpi/build.c
> +                 *   which determines the address and contents of the buffer).
> +                 */
>                  Device(VGID) {
>                      Name(_HID, EisaID ("PNP0A06"))
>                      Name(_UID, 0x00)
> 
> > -----Original Message-----
> > From: Ian Campbell
> > Sent: 01 December 2011 10:00
> > To: Paul Durrant
> > Cc: Konrad Rzeszutek Wilk; xen-devel@lists.xensource.com
> > Subject: RE: [Xen-devel] [PATCH] Add code to track the address of
> > the VM generation id buffer across a
> > 
> > On Thu, 2011-12-01 at 09:47 +0000, Paul Durrant wrote:
> > > > -----Original Message-----
> > > > From: Ian Campbell
> > > > Sent: 01 December 2011 08:59
> > > > To: Paul Durrant
> > > > Cc: Konrad Rzeszutek Wilk; xen-devel@lists.xensource.com
> > > > Subject: Re: [Xen-devel] [PATCH] Add code to track the address
> > of
> > > > the VM generation id buffer across a
> > > >
> > > > On Thu, 2011-12-01 at 08:46 +0000, Paul Durrant wrote:
> > > > > Konrad,
> > > > >
> > > > >   Did you see my previous patch set? The introductory comment
> > was:
> > > >
> > > >
> > > > I think that description belongs somewhere permanent, either in
> > > > docs/misc or as a comment in an appropriate header.
> > > >
> > >
> > > Good point. Perhaps I should stick the comment just above the
> > device description in the dsdt?
> > 
> > That would do I guess.
> > 
> > I guess more important would be the user facing toolstack specific
> > semantics/documentation i.e. the manpage.
> > 
> > Ian.
> > 
> 



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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 14:28:27 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 14: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.xensource.com>)
	id 1RW7cR-0003yr-Kl; Thu, 01 Dec 2011 14:28:11 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RW7cQ-0003yi-DG
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 14:28:10 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-7.tower-27.messagelabs.com!1322749609!59076090!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21963 invoked from network); 1 Dec 2011 14:26:49 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-7.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 1 Dec 2011 14:26:49 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RW7bl-000GPp-SX; Thu, 01 Dec 2011 14:27:29 +0000
Date: Thu, 1 Dec 2011 14:27:29 +0000
From: Tim Deegan <tim@xen.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20111201142729.GD61203@ocelot.phlegethon.org>
References: <patchbomb.1322598097@xdev.gridcentric.ca>
	<b2097819f2d9f7087057.1322598102@xdev.gridcentric.ca>
	<4ED60F1D02000078000644C4@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4ED60F1D02000078000644C4@nat28.tlf.novell.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com, ian.campbell@citrix.com,
	andres@gridcentric.ca, keir.xen@gmail.com,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>,
	ian.jackson@citrix.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 5 of 9] x86/mm: Ensure maps used by nested
	hvm code cannot be paged out
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 10:10 +0000 on 30 Nov (1322647821), Jan Beulich wrote:
>  >>> On 29.11.11 at 21:21, Andres Lagar-Cavilla <andres@lagarcavilla.org> wrote:
> > --- a/xen/arch/x86/hvm/hvm.c
> > +++ b/xen/arch/x86/hvm/hvm.c
> > @@ -1828,7 +1831,12 @@ static void *__hvm_map_guest_frame(unsig
> >      if ( writable )
> >          paging_mark_dirty(d, mfn);
> >  
> > -    return map_domain_page(mfn);
> > +    pg = mfn_to_page(mfn);
> > +    page_get_owner_and_reference(pg);
> 
> This can (at least theoretically) fail, and you must handle failure (or
> explain in a comment why not).

Also, you should probably be using get_page(pg, d); is there any
reason to skip the ownership check?

Tim.

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 14:28:27 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 14: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.xensource.com>)
	id 1RW7cR-0003yr-Kl; Thu, 01 Dec 2011 14:28:11 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RW7cQ-0003yi-DG
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 14:28:10 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-7.tower-27.messagelabs.com!1322749609!59076090!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21963 invoked from network); 1 Dec 2011 14:26:49 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-7.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 1 Dec 2011 14:26:49 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RW7bl-000GPp-SX; Thu, 01 Dec 2011 14:27:29 +0000
Date: Thu, 1 Dec 2011 14:27:29 +0000
From: Tim Deegan <tim@xen.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20111201142729.GD61203@ocelot.phlegethon.org>
References: <patchbomb.1322598097@xdev.gridcentric.ca>
	<b2097819f2d9f7087057.1322598102@xdev.gridcentric.ca>
	<4ED60F1D02000078000644C4@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4ED60F1D02000078000644C4@nat28.tlf.novell.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com, ian.campbell@citrix.com,
	andres@gridcentric.ca, keir.xen@gmail.com,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>,
	ian.jackson@citrix.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 5 of 9] x86/mm: Ensure maps used by nested
	hvm code cannot be paged out
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 10:10 +0000 on 30 Nov (1322647821), Jan Beulich wrote:
>  >>> On 29.11.11 at 21:21, Andres Lagar-Cavilla <andres@lagarcavilla.org> wrote:
> > --- a/xen/arch/x86/hvm/hvm.c
> > +++ b/xen/arch/x86/hvm/hvm.c
> > @@ -1828,7 +1831,12 @@ static void *__hvm_map_guest_frame(unsig
> >      if ( writable )
> >          paging_mark_dirty(d, mfn);
> >  
> > -    return map_domain_page(mfn);
> > +    pg = mfn_to_page(mfn);
> > +    page_get_owner_and_reference(pg);
> 
> This can (at least theoretically) fail, and you must handle failure (or
> explain in a comment why not).

Also, you should probably be using get_page(pg, d); is there any
reason to skip the ownership check?

Tim.

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 14:30:02 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 14:30:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW7e0-00045n-52; Thu, 01 Dec 2011 14:29:48 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RW7dy-00045F-Q1
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 14:29:47 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1322749745!3682231!1
X-Originating-IP: [209.85.210.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7524 invoked from network); 1 Dec 2011 14:29:07 -0000
Received: from mail-pz0-f43.google.com (HELO mail-pz0-f43.google.com)
	(209.85.210.43)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 14:29:07 -0000
Received: by dadz13 with SMTP id z13so2336631dad.30
	for <xen-devel@lists.xensource.com>;
	Thu, 01 Dec 2011 06:29:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=wZVStL07GitdAbb3SShnAlxSUoHCkeqgpeyFThd2Em4=;
	b=tcI7VvoThNMB91BGH9FPat0W5XAd+Vus9BICC6AOrThRupo5JkI02vqp+3cdcaquq2
	z+QCcPPw/LTnTzre3oS0+Eq3AgRCxAf3ZlGOsLdk4L1utZSfNjmMBRaDFKgKlVxoqSxP
	GsOtOcROmYKjnfxhrOl5N5NHeZrMKci4z6Zrw=
MIME-Version: 1.0
Received: by 10.68.51.135 with SMTP id k7mr5423875pbo.72.1322749744829; Thu,
	01 Dec 2011 06:29:04 -0800 (PST)
Received: by 10.142.212.12 with HTTP; Thu, 1 Dec 2011 06:29:04 -0800 (PST)
In-Reply-To: <20174.35001.566794.745844@mariner.uk.xensource.com>
References: <patchbomb.1321617576@loki.upc.es>
	<ec94a7e4983ad6338db2.1321617579@loki.upc.es>
	<20174.35001.566794.745844@mariner.uk.xensource.com>
Date: Thu, 1 Dec 2011 15:29:04 +0100
X-Google-Sender-Auth: w6ne9DPg5niVOSM785qoJKNyEB8
Message-ID: <CAPLaKK5NWCZGF0pEfCDcO8-SSBHAR9P-RfMum-soyokihtULpA@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 3 of 9 v2] libxl: add libxl__forkexec
 function to libxl_exec
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

2011/11/24 Ian Jackson <Ian.Jackson@eu.citrix.com>:
> Conveniently, I have already written the second function for you:
> libxl_report_child_exitstatus :-).

Why does the libxl_report_child_exitstatus function print
"unexpectedly exited status zero", shouldn't it print something like
"child exited successfully"? Or I'm not supposed to call it if
WIFEXITED(status) && WEXITSTATUS(status) == 0?

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 14:30:02 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 14:30:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW7e0-00045n-52; Thu, 01 Dec 2011 14:29:48 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RW7dy-00045F-Q1
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 14:29:47 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1322749745!3682231!1
X-Originating-IP: [209.85.210.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7524 invoked from network); 1 Dec 2011 14:29:07 -0000
Received: from mail-pz0-f43.google.com (HELO mail-pz0-f43.google.com)
	(209.85.210.43)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 14:29:07 -0000
Received: by dadz13 with SMTP id z13so2336631dad.30
	for <xen-devel@lists.xensource.com>;
	Thu, 01 Dec 2011 06:29:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=wZVStL07GitdAbb3SShnAlxSUoHCkeqgpeyFThd2Em4=;
	b=tcI7VvoThNMB91BGH9FPat0W5XAd+Vus9BICC6AOrThRupo5JkI02vqp+3cdcaquq2
	z+QCcPPw/LTnTzre3oS0+Eq3AgRCxAf3ZlGOsLdk4L1utZSfNjmMBRaDFKgKlVxoqSxP
	GsOtOcROmYKjnfxhrOl5N5NHeZrMKci4z6Zrw=
MIME-Version: 1.0
Received: by 10.68.51.135 with SMTP id k7mr5423875pbo.72.1322749744829; Thu,
	01 Dec 2011 06:29:04 -0800 (PST)
Received: by 10.142.212.12 with HTTP; Thu, 1 Dec 2011 06:29:04 -0800 (PST)
In-Reply-To: <20174.35001.566794.745844@mariner.uk.xensource.com>
References: <patchbomb.1321617576@loki.upc.es>
	<ec94a7e4983ad6338db2.1321617579@loki.upc.es>
	<20174.35001.566794.745844@mariner.uk.xensource.com>
Date: Thu, 1 Dec 2011 15:29:04 +0100
X-Google-Sender-Auth: w6ne9DPg5niVOSM785qoJKNyEB8
Message-ID: <CAPLaKK5NWCZGF0pEfCDcO8-SSBHAR9P-RfMum-soyokihtULpA@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 3 of 9 v2] libxl: add libxl__forkexec
 function to libxl_exec
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

2011/11/24 Ian Jackson <Ian.Jackson@eu.citrix.com>:
> Conveniently, I have already written the second function for you:
> libxl_report_child_exitstatus :-).

Why does the libxl_report_child_exitstatus function print
"unexpectedly exited status zero", shouldn't it print something like
"child exited successfully"? Or I'm not supposed to call it if
WIFEXITED(status) && WEXITSTATUS(status) == 0?

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 14:30:37 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 14: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.xensource.com>)
	id 1RW7eZ-0004Av-JV; Thu, 01 Dec 2011 14:30:23 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RW7eX-0004AK-Fc
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 14:30:21 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-8.tower-27.messagelabs.com!1322749676!54485532!1
X-Originating-IP: [208.97.132.119]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xMTkgPT4gMTU4ODc=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17268 invoked from network); 1 Dec 2011 14:27:57 -0000
Received: from caiajhbdcbbj.dreamhost.com (HELO homiemail-a18.g.dreamhost.com)
	(208.97.132.119) by server-8.tower-27.messagelabs.com with SMTP;
	1 Dec 2011 14:27:57 -0000
Received: from homiemail-a18.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a18.g.dreamhost.com (Postfix) with ESMTP id BC0A7250077;
	Thu,  1 Dec 2011 06:29:42 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=VtyL3tXuAN5/266fAi3fUJmnzQvIEGHXcpfR+IA23Aw9
	X7LBRXw/g2dBohrqc1n9tAkeye6tfBnP7gjJz7gyOD3oITMPmqqRKOnl3ShMfuzt
	Ezr8ErbcFqRQHT7MWhK929Jy9UWnqMKHdmz7Y/05VI4vhFftp9gx7gTr8goZ1/M=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=UGk06u5/hAw+mI6qw7qWwm97y/s=; b=L12NOB6F
	1yb2d4AQ5HzBRpQVtsTfAuCoqcWtvc5SohhnYOz+OQahkYBZLPg+wj+Dx7I6K0Od
	ZE9Byc51Sa9SpyYFY1Dovewv/qO68T2CHU2ryWDHIW6C7EkHohvEIj3PikY89d7G
	D5tQL798JcNpPTmUrGkxwCCzaeNt0zfy50Q=
Received: from webmail.lagarcavilla.org (ahfbbjcaiaae.dreamhost.com
	[75.119.208.4]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a18.g.dreamhost.com (Postfix) with ESMTPA id 60B43250075; 
	Thu,  1 Dec 2011 06:29:42 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP; Thu, 1 Dec 2011 06:29:42 -0800
Message-ID: <ef6ea07873d854f37bc2230851c4b865.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20111201142729.GD61203@ocelot.phlegethon.org>
References: <patchbomb.1322598097@xdev.gridcentric.ca>
	<b2097819f2d9f7087057.1322598102@xdev.gridcentric.ca>
	<4ED60F1D02000078000644C4@nat28.tlf.novell.com>
	<20111201142729.GD61203@ocelot.phlegethon.org>
Date: Thu, 1 Dec 2011 06:29:42 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Tim Deegan" <tim@xen.org>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, ian.campbell@citrix.com,
	andres@gridcentric.ca, keir.xen@gmail.com,
	Jan Beulich <jbeulich@suse.com>, ian.jackson@citrix.com,
	adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 5 of 9] x86/mm: Ensure maps used by nested
 hvm code cannot be paged out
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> At 10:10 +0000 on 30 Nov (1322647821), Jan Beulich wrote:
>>  >>> On 29.11.11 at 21:21, Andres Lagar-Cavilla
>> <andres@lagarcavilla.org> wrote:
>> > --- a/xen/arch/x86/hvm/hvm.c
>> > +++ b/xen/arch/x86/hvm/hvm.c
>> > @@ -1828,7 +1831,12 @@ static void *__hvm_map_guest_frame(unsig
>> >      if ( writable )
>> >          paging_mark_dirty(d, mfn);
>> >
>> > -    return map_domain_page(mfn);
>> > +    pg = mfn_to_page(mfn);
>> > +    page_get_owner_and_reference(pg);
>>
>> This can (at least theoretically) fail, and you must handle failure (or
>> explain in a comment why not).
>
> Also, you should probably be using get_page(pg, d); is there any
> reason to skip the ownership check?

Shared pages, owner could be dom_cow. Could conditionally get_page if
writable, page_get_owner_and_ref if non writable.

Andres
>
> Tim.
>



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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 14:30:37 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 14: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.xensource.com>)
	id 1RW7eZ-0004Av-JV; Thu, 01 Dec 2011 14:30:23 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RW7eX-0004AK-Fc
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 14:30:21 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-8.tower-27.messagelabs.com!1322749676!54485532!1
X-Originating-IP: [208.97.132.119]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xMTkgPT4gMTU4ODc=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17268 invoked from network); 1 Dec 2011 14:27:57 -0000
Received: from caiajhbdcbbj.dreamhost.com (HELO homiemail-a18.g.dreamhost.com)
	(208.97.132.119) by server-8.tower-27.messagelabs.com with SMTP;
	1 Dec 2011 14:27:57 -0000
Received: from homiemail-a18.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a18.g.dreamhost.com (Postfix) with ESMTP id BC0A7250077;
	Thu,  1 Dec 2011 06:29:42 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=VtyL3tXuAN5/266fAi3fUJmnzQvIEGHXcpfR+IA23Aw9
	X7LBRXw/g2dBohrqc1n9tAkeye6tfBnP7gjJz7gyOD3oITMPmqqRKOnl3ShMfuzt
	Ezr8ErbcFqRQHT7MWhK929Jy9UWnqMKHdmz7Y/05VI4vhFftp9gx7gTr8goZ1/M=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=UGk06u5/hAw+mI6qw7qWwm97y/s=; b=L12NOB6F
	1yb2d4AQ5HzBRpQVtsTfAuCoqcWtvc5SohhnYOz+OQahkYBZLPg+wj+Dx7I6K0Od
	ZE9Byc51Sa9SpyYFY1Dovewv/qO68T2CHU2ryWDHIW6C7EkHohvEIj3PikY89d7G
	D5tQL798JcNpPTmUrGkxwCCzaeNt0zfy50Q=
Received: from webmail.lagarcavilla.org (ahfbbjcaiaae.dreamhost.com
	[75.119.208.4]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a18.g.dreamhost.com (Postfix) with ESMTPA id 60B43250075; 
	Thu,  1 Dec 2011 06:29:42 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP; Thu, 1 Dec 2011 06:29:42 -0800
Message-ID: <ef6ea07873d854f37bc2230851c4b865.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20111201142729.GD61203@ocelot.phlegethon.org>
References: <patchbomb.1322598097@xdev.gridcentric.ca>
	<b2097819f2d9f7087057.1322598102@xdev.gridcentric.ca>
	<4ED60F1D02000078000644C4@nat28.tlf.novell.com>
	<20111201142729.GD61203@ocelot.phlegethon.org>
Date: Thu, 1 Dec 2011 06:29:42 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Tim Deegan" <tim@xen.org>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, ian.campbell@citrix.com,
	andres@gridcentric.ca, keir.xen@gmail.com,
	Jan Beulich <jbeulich@suse.com>, ian.jackson@citrix.com,
	adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 5 of 9] x86/mm: Ensure maps used by nested
 hvm code cannot be paged out
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> At 10:10 +0000 on 30 Nov (1322647821), Jan Beulich wrote:
>>  >>> On 29.11.11 at 21:21, Andres Lagar-Cavilla
>> <andres@lagarcavilla.org> wrote:
>> > --- a/xen/arch/x86/hvm/hvm.c
>> > +++ b/xen/arch/x86/hvm/hvm.c
>> > @@ -1828,7 +1831,12 @@ static void *__hvm_map_guest_frame(unsig
>> >      if ( writable )
>> >          paging_mark_dirty(d, mfn);
>> >
>> > -    return map_domain_page(mfn);
>> > +    pg = mfn_to_page(mfn);
>> > +    page_get_owner_and_reference(pg);
>>
>> This can (at least theoretically) fail, and you must handle failure (or
>> explain in a comment why not).
>
> Also, you should probably be using get_page(pg, d); is there any
> reason to skip the ownership check?

Shared pages, owner could be dom_cow. Could conditionally get_page if
writable, page_get_owner_and_ref if non writable.

Andres
>
> Tim.
>



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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 14:37:36 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 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.xensource.com>)
	id 1RW7lG-0004fj-RI; Thu, 01 Dec 2011 14:37:18 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RW7lF-0004fa-G3
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 14:37:17 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-13.tower-21.messagelabs.com!1322750197!4578455!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29646 invoked from network); 1 Dec 2011 14:36:38 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-13.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 1 Dec 2011 14:36:38 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RW7ka-000GRn-LZ; Thu, 01 Dec 2011 14:36:36 +0000
Date: Thu, 1 Dec 2011 14:36:36 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20111201143636.GE61203@ocelot.phlegethon.org>
References: <patchbomb.1322598097@xdev.gridcentric.ca>
	<b2097819f2d9f7087057.1322598102@xdev.gridcentric.ca>
	<4ED60F1D02000078000644C4@nat28.tlf.novell.com>
	<20111201142729.GD61203@ocelot.phlegethon.org>
	<ef6ea07873d854f37bc2230851c4b865.squirrel@webmail.lagarcavilla.org>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <ef6ea07873d854f37bc2230851c4b865.squirrel@webmail.lagarcavilla.org>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com, ian.campbell@citrix.com,
	andres@gridcentric.ca, keir.xen@gmail.com,
	Jan Beulich <jbeulich@suse.com>, ian.jackson@citrix.com,
	adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 5 of 9] x86/mm: Ensure maps used by nested
	hvm code cannot be paged out
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 06:29 -0800 on 01 Dec (1322720982), Andres Lagar-Cavilla wrote:
> >> This can (at least theoretically) fail, and you must handle failure (or
> >> explain in a comment why not).
> >
> > Also, you should probably be using get_page(pg, d); is there any
> > reason to skip the ownership check?
> 
> Shared pages, owner could be dom_cow. Could conditionally get_page if
> writable, page_get_owner_and_ref if non writable.

That's probably best, plus a comment saying why.  

Tim.

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 14:37:36 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 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.xensource.com>)
	id 1RW7lG-0004fj-RI; Thu, 01 Dec 2011 14:37:18 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RW7lF-0004fa-G3
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 14:37:17 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-13.tower-21.messagelabs.com!1322750197!4578455!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29646 invoked from network); 1 Dec 2011 14:36:38 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-13.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 1 Dec 2011 14:36:38 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RW7ka-000GRn-LZ; Thu, 01 Dec 2011 14:36:36 +0000
Date: Thu, 1 Dec 2011 14:36:36 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20111201143636.GE61203@ocelot.phlegethon.org>
References: <patchbomb.1322598097@xdev.gridcentric.ca>
	<b2097819f2d9f7087057.1322598102@xdev.gridcentric.ca>
	<4ED60F1D02000078000644C4@nat28.tlf.novell.com>
	<20111201142729.GD61203@ocelot.phlegethon.org>
	<ef6ea07873d854f37bc2230851c4b865.squirrel@webmail.lagarcavilla.org>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <ef6ea07873d854f37bc2230851c4b865.squirrel@webmail.lagarcavilla.org>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com, ian.campbell@citrix.com,
	andres@gridcentric.ca, keir.xen@gmail.com,
	Jan Beulich <jbeulich@suse.com>, ian.jackson@citrix.com,
	adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 5 of 9] x86/mm: Ensure maps used by nested
	hvm code cannot be paged out
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 06:29 -0800 on 01 Dec (1322720982), Andres Lagar-Cavilla wrote:
> >> This can (at least theoretically) fail, and you must handle failure (or
> >> explain in a comment why not).
> >
> > Also, you should probably be using get_page(pg, d); is there any
> > reason to skip the ownership check?
> 
> Shared pages, owner could be dom_cow. Could conditionally get_page if
> writable, page_get_owner_and_ref if non writable.

That's probably best, plus a comment saying why.  

Tim.

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 14:52:23 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 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.xensource.com>)
	id 1RW7za-0004sV-EH; Thu, 01 Dec 2011 14:52:06 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RW7zY-0004sQ-O4
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 14:52:04 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1322751084!7130128!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU2Nw==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4199 invoked from network); 1 Dec 2011 14:51:25 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 14:51:25 -0000
X-IronPort-AV: E=Sophos;i="4.71,278,1320624000"; 
   d="scan'208";a="9233067"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Dec 2011 14:51:24 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 1 Dec 2011
	14:51:24 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: anatoly techtonik <techtonik@gmail.com>
Date: Thu, 1 Dec 2011 14:51:23 +0000
In-Reply-To: <CAPkN8xJiCTijVoi6YcHBa0tHYc8oQCmRw=ybRuhvWmWi2OLLmw@mail.gmail.com>
References: <CAPkN8xKwAsrF_ZuXWAF2uMVDYTbGwpSsvG+YfjrLfpf-oxqwJQ@mail.gmail.com>
	<CAPkN8xLX83Uxbo4UDWG2mmYctAQbwRcw3BJWzack8JZgQAg9nw@mail.gmail.com>
	<1322747959.31810.207.camel@zakaz.uk.xensource.com>
	<CAPkN8xJiCTijVoi6YcHBa0tHYc8oQCmRw=ybRuhvWmWi2OLLmw@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322751083.31810.217.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Low memory corruption - trap invalid opcode
 ip:7f5c688028b0 sp:7ffff97af848 error:0 in ld-2.11.2.so[7f5c687ef000+1e000]
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2011-12-01 at 14:45 +0000, anatoly techtonik wrote:
> On Thu, Dec 1, 2011 at 4:59 PM, Ian Campbell <Ian.Campbell@citrix.com>
> wrote:
>         On Tue, 2011-11-29 at 17:54 +0000, anatoly techtonik wrote:
>         > My first message didn't get to the list, so I am trying once
>         more.
>         >
>         > ---------- Forwarded message ----------
>         > From: anatoly techtonik <techtonik@gmail.com>
>         > Date: Mon, Nov 14, 2011 at 5:46 PM
>         > Subject: Low memory corruption - trap invalid opcode
>         ip:7f5c688028b0
>         > sp:7ffff97af848 error:0 in ld-2.11.2.so[7f5c687ef000+1e000]
>         > To: xen-devel@lists.xensource.com
>         >
>         >
>         > I was redirected here from this bug report in Debian against
>         > 'svn-buildpackage' after I started getting 'Illegal
>         instruction' error
>         > after running 'svn-inject' and similar command on a brand
>         new VM
>         > instance for Debian Squeeze.
>         > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=646945#54
>         >
>         > dmesg from VM
>         > 17067.210187] svn-inject[6026] trap invalid opcode
>         ip:7f5c688028b0
>         > sp:7ffff97af848 error:0 in ld-2.11.2.so[7f5c687ef000+1e000]
>         
>         
>         This is more than likely the same issue as
>         http://bugs.debian.org/646549.
> 
> 
> Thanks. The processor is the same Intel Xeon E31270, so I am going to
> subscribe to this bug. In the meanwhile - is it possible to disable
> this AVX somehow or find another workaround until it is fixed in
> Squeeze? 

There is some additional information about the Xen-specific
manifestation of this bug in
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=649349

One workaround is to use xsave=1 on your hypervisor command line, but
the cost is that you cannot migrate guests anymore.

Ian.




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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 14:52:23 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 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.xensource.com>)
	id 1RW7za-0004sV-EH; Thu, 01 Dec 2011 14:52:06 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RW7zY-0004sQ-O4
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 14:52:04 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1322751084!7130128!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU2Nw==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4199 invoked from network); 1 Dec 2011 14:51:25 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 14:51:25 -0000
X-IronPort-AV: E=Sophos;i="4.71,278,1320624000"; 
   d="scan'208";a="9233067"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Dec 2011 14:51:24 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 1 Dec 2011
	14:51:24 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: anatoly techtonik <techtonik@gmail.com>
Date: Thu, 1 Dec 2011 14:51:23 +0000
In-Reply-To: <CAPkN8xJiCTijVoi6YcHBa0tHYc8oQCmRw=ybRuhvWmWi2OLLmw@mail.gmail.com>
References: <CAPkN8xKwAsrF_ZuXWAF2uMVDYTbGwpSsvG+YfjrLfpf-oxqwJQ@mail.gmail.com>
	<CAPkN8xLX83Uxbo4UDWG2mmYctAQbwRcw3BJWzack8JZgQAg9nw@mail.gmail.com>
	<1322747959.31810.207.camel@zakaz.uk.xensource.com>
	<CAPkN8xJiCTijVoi6YcHBa0tHYc8oQCmRw=ybRuhvWmWi2OLLmw@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322751083.31810.217.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Low memory corruption - trap invalid opcode
 ip:7f5c688028b0 sp:7ffff97af848 error:0 in ld-2.11.2.so[7f5c687ef000+1e000]
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2011-12-01 at 14:45 +0000, anatoly techtonik wrote:
> On Thu, Dec 1, 2011 at 4:59 PM, Ian Campbell <Ian.Campbell@citrix.com>
> wrote:
>         On Tue, 2011-11-29 at 17:54 +0000, anatoly techtonik wrote:
>         > My first message didn't get to the list, so I am trying once
>         more.
>         >
>         > ---------- Forwarded message ----------
>         > From: anatoly techtonik <techtonik@gmail.com>
>         > Date: Mon, Nov 14, 2011 at 5:46 PM
>         > Subject: Low memory corruption - trap invalid opcode
>         ip:7f5c688028b0
>         > sp:7ffff97af848 error:0 in ld-2.11.2.so[7f5c687ef000+1e000]
>         > To: xen-devel@lists.xensource.com
>         >
>         >
>         > I was redirected here from this bug report in Debian against
>         > 'svn-buildpackage' after I started getting 'Illegal
>         instruction' error
>         > after running 'svn-inject' and similar command on a brand
>         new VM
>         > instance for Debian Squeeze.
>         > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=646945#54
>         >
>         > dmesg from VM
>         > 17067.210187] svn-inject[6026] trap invalid opcode
>         ip:7f5c688028b0
>         > sp:7ffff97af848 error:0 in ld-2.11.2.so[7f5c687ef000+1e000]
>         
>         
>         This is more than likely the same issue as
>         http://bugs.debian.org/646549.
> 
> 
> Thanks. The processor is the same Intel Xeon E31270, so I am going to
> subscribe to this bug. In the meanwhile - is it possible to disable
> this AVX somehow or find another workaround until it is fixed in
> Squeeze? 

There is some additional information about the Xen-specific
manifestation of this bug in
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=649349

One workaround is to use xsave=1 on your hypervisor command line, but
the cost is that you cannot migrate guests anymore.

Ian.




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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 14:52:32 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 14:52:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW7zi-0004sw-RH; Thu, 01 Dec 2011 14:52:14 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RW7zh-0004sc-M3
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 14:52:14 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-2.tower-182.messagelabs.com!1322751093!5478268!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNDUxMTM=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNDUxMTM=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1626 invoked from network); 1 Dec 2011 14:51:33 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-2.tower-182.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 1 Dec 2011 14:51:33 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1322751092; l=1939;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=YQ6cGzMXGoQXxO2NGhxA2rGr4KY=;
	b=aowiBhREqle17IRUaR0GknloMglAeR4deCx4OszH0zqnDHj9OLq0T9zk9IkuoZ1Qk4c
	q6MTOoVuU09/wiTcuwWe0qSO53JBsC35xO7e6QI8Wl3FVvRfvSWaiuNORvSBhmodDxuZC
	Waz/wA4XCHGU1kM31olUZCjXlgrTEws2VBk=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/ll2c7pE6jG
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-080-213.pools.arcor-ip.net [84.57.80.213])
	by smtp.strato.de (klopstock mo5) (RZmta 26.10 AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id Y052cfnB1DlnnA ;
	Thu, 1 Dec 2011 15:51:04 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id D2C5F18637; Thu,  1 Dec 2011 15:51:03 +0100 (CET)
Date: Thu, 1 Dec 2011 15:51:03 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20111201145103.GA13045@aepfle.de>
References: <patchbomb.1322603709@xdev.gridcentric.ca>
	<43dc614d543cdf84189d.1322603711@xdev.gridcentric.ca>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <43dc614d543cdf84189d.1322603711@xdev.gridcentric.ca>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: xen-devel@lists.xensource.com, ian.campbell@citrix.com,
	andres@gridcentric.ca, tim@xen.org, keir.xen@gmail.com,
	JBeulich@suse.com, ian.jackson@citrix.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 2 of 5] Improve ring management for memory
 events. Do not lose guest events
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Nov 29, Andres Lagar-Cavilla wrote:

> @@ -133,31 +185,95 @@ static int mem_event_disable(struct mem_
>      return 0;
>  }
>  
> -void mem_event_put_request(struct domain *d, struct mem_event_domain *med, mem_event_request_t *req)
> +static inline int mem_event_ring_free(struct domain *d, struct mem_event_domain *med)
>  {
> +    int free_requests;
> +
> +    free_requests = RING_FREE_REQUESTS(&med->front_ring);
> +    if ( unlikely(free_requests < d->max_vcpus) )
> +    {
> +        /* This may happen during normal operation (hopefully not often). */
> +        gdprintk(XENLOG_INFO, "mem_event request slots for domain %d: %d\n",
> +                               d->domain_id, free_requests);
> +    }
> +
> +    return free_requests;
> +}
> +
> +/* Return values
> + * zero: success
> + * -ENOSYS: no ring
> + * -EAGAIN: ring is full and the event has not been transmitted.
> + *          Only foreign vcpu's get EAGAIN
> + * -EBUSY: guest vcpu has been paused due to ring congestion
> + */ 
> +int mem_event_put_request(struct domain *d, struct mem_event_domain *med, mem_event_request_t *req)
> +{
> +    int ret = 0;
> +    int foreign = (d != current->domain);

> +    /*
> +     * We ensure that each vcpu can put at least *one* event -- because some
> +     * events are not repeatable, such as dropping a page.  This will ensure no
> +     * vCPU is left with an event that they must place on the ring, but cannot.
> +     * They will be paused after the event is placed.
> +     * See large comment below in mem_event_unpause_vcpus().
> +     */
> +    if ( !foreign && mem_event_ring_free(d, med) < d->max_vcpus )
> +    {
> +        mem_event_mark_and_pause(current, med);
> +        ret = -EBUSY;
> +    }
>  
>      mem_event_ring_unlock(med);
>  
>      notify_via_xen_event_channel(d, med->xen_port);
> +
> +    return ret;


What will happen if the guest has more vcpus than r->nr_ents in the ring
buffer? To me it looks like no event can be placed into the ring and
-EBUSY is returned instead.

Olaf

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 14:52:32 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 14:52:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW7zi-0004sw-RH; Thu, 01 Dec 2011 14:52:14 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RW7zh-0004sc-M3
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 14:52:14 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-2.tower-182.messagelabs.com!1322751093!5478268!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNDUxMTM=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNDUxMTM=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1626 invoked from network); 1 Dec 2011 14:51:33 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-2.tower-182.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 1 Dec 2011 14:51:33 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1322751092; l=1939;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=YQ6cGzMXGoQXxO2NGhxA2rGr4KY=;
	b=aowiBhREqle17IRUaR0GknloMglAeR4deCx4OszH0zqnDHj9OLq0T9zk9IkuoZ1Qk4c
	q6MTOoVuU09/wiTcuwWe0qSO53JBsC35xO7e6QI8Wl3FVvRfvSWaiuNORvSBhmodDxuZC
	Waz/wA4XCHGU1kM31olUZCjXlgrTEws2VBk=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/ll2c7pE6jG
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-080-213.pools.arcor-ip.net [84.57.80.213])
	by smtp.strato.de (klopstock mo5) (RZmta 26.10 AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id Y052cfnB1DlnnA ;
	Thu, 1 Dec 2011 15:51:04 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id D2C5F18637; Thu,  1 Dec 2011 15:51:03 +0100 (CET)
Date: Thu, 1 Dec 2011 15:51:03 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20111201145103.GA13045@aepfle.de>
References: <patchbomb.1322603709@xdev.gridcentric.ca>
	<43dc614d543cdf84189d.1322603711@xdev.gridcentric.ca>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <43dc614d543cdf84189d.1322603711@xdev.gridcentric.ca>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: xen-devel@lists.xensource.com, ian.campbell@citrix.com,
	andres@gridcentric.ca, tim@xen.org, keir.xen@gmail.com,
	JBeulich@suse.com, ian.jackson@citrix.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 2 of 5] Improve ring management for memory
 events. Do not lose guest events
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Nov 29, Andres Lagar-Cavilla wrote:

> @@ -133,31 +185,95 @@ static int mem_event_disable(struct mem_
>      return 0;
>  }
>  
> -void mem_event_put_request(struct domain *d, struct mem_event_domain *med, mem_event_request_t *req)
> +static inline int mem_event_ring_free(struct domain *d, struct mem_event_domain *med)
>  {
> +    int free_requests;
> +
> +    free_requests = RING_FREE_REQUESTS(&med->front_ring);
> +    if ( unlikely(free_requests < d->max_vcpus) )
> +    {
> +        /* This may happen during normal operation (hopefully not often). */
> +        gdprintk(XENLOG_INFO, "mem_event request slots for domain %d: %d\n",
> +                               d->domain_id, free_requests);
> +    }
> +
> +    return free_requests;
> +}
> +
> +/* Return values
> + * zero: success
> + * -ENOSYS: no ring
> + * -EAGAIN: ring is full and the event has not been transmitted.
> + *          Only foreign vcpu's get EAGAIN
> + * -EBUSY: guest vcpu has been paused due to ring congestion
> + */ 
> +int mem_event_put_request(struct domain *d, struct mem_event_domain *med, mem_event_request_t *req)
> +{
> +    int ret = 0;
> +    int foreign = (d != current->domain);

> +    /*
> +     * We ensure that each vcpu can put at least *one* event -- because some
> +     * events are not repeatable, such as dropping a page.  This will ensure no
> +     * vCPU is left with an event that they must place on the ring, but cannot.
> +     * They will be paused after the event is placed.
> +     * See large comment below in mem_event_unpause_vcpus().
> +     */
> +    if ( !foreign && mem_event_ring_free(d, med) < d->max_vcpus )
> +    {
> +        mem_event_mark_and_pause(current, med);
> +        ret = -EBUSY;
> +    }
>  
>      mem_event_ring_unlock(med);
>  
>      notify_via_xen_event_channel(d, med->xen_port);
> +
> +    return ret;


What will happen if the guest has more vcpus than r->nr_ents in the ring
buffer? To me it looks like no event can be placed into the ring and
-EBUSY is returned instead.

Olaf

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 15:00:03 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 15: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.xensource.com>)
	id 1RW86b-0005CE-O0; Thu, 01 Dec 2011 14:59:21 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RW86a-0005C9-UY
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 14:59:21 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1322751520!5816057!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU2Nw==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19500 invoked from network); 1 Dec 2011 14:58:41 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 14:58:41 -0000
X-IronPort-AV: E=Sophos;i="4.71,278,1320624000"; 
   d="scan'208";a="9233331"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Dec 2011 14:57:03 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 1 Dec 2011 14:57:03 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RW84M-00036V-Om; Thu, 01 Dec 2011 14:57:02 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RW84M-0007iJ-KW;
	Thu, 01 Dec 2011 14:57:02 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20183.38334.616867.451584@mariner.uk.xensource.com>
Date: Thu, 1 Dec 2011 14:57:02 +0000
To: Roger Pau =?iso-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
In-Reply-To: <CAPLaKK5NWCZGF0pEfCDcO8-SSBHAR9P-RfMum-soyokihtULpA@mail.gmail.com>
References: <patchbomb.1321617576@loki.upc.es>
	<ec94a7e4983ad6338db2.1321617579@loki.upc.es>
	<20174.35001.566794.745844@mariner.uk.xensource.com>
	<CAPLaKK5NWCZGF0pEfCDcO8-SSBHAR9P-RfMum-soyokihtULpA@mail.gmail.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 3 of 9 v2] libxl: add libxl__forkexec
 function to libxl_exec
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Roger Pau Monn=E9 writes ("Re: [Xen-devel] [PATCH 3 of 9 v2] libxl: add lib=
xl__forkexec function to libxl_exec"):
> 2011/11/24 Ian Jackson <Ian.Jackson@eu.citrix.com>:
> > Conveniently, I have already written the second function for you:
> > libxl_report_child_exitstatus :-).
> =

> Why does the libxl_report_child_exitstatus function print
> "unexpectedly exited status zero", shouldn't it print something like
> "child exited successfully"? Or I'm not supposed to call it if
> WIFEXITED(status) && WEXITSTATUS(status) =3D=3D 0?

You're not supposed to call it in that case, unless you weren't
expecting the process to exit.

And you can write
   WIFEXITED(status) && WEXITSTATUS(status) =3D=3D 0
more simply as
   status=3D=3D0
so this is quite easy to do.

Ian.

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 15:00:03 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 15: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.xensource.com>)
	id 1RW86b-0005CE-O0; Thu, 01 Dec 2011 14:59:21 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RW86a-0005C9-UY
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 14:59:21 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1322751520!5816057!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU2Nw==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19500 invoked from network); 1 Dec 2011 14:58:41 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 14:58:41 -0000
X-IronPort-AV: E=Sophos;i="4.71,278,1320624000"; 
   d="scan'208";a="9233331"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Dec 2011 14:57:03 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 1 Dec 2011 14:57:03 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RW84M-00036V-Om; Thu, 01 Dec 2011 14:57:02 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RW84M-0007iJ-KW;
	Thu, 01 Dec 2011 14:57:02 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20183.38334.616867.451584@mariner.uk.xensource.com>
Date: Thu, 1 Dec 2011 14:57:02 +0000
To: Roger Pau =?iso-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
In-Reply-To: <CAPLaKK5NWCZGF0pEfCDcO8-SSBHAR9P-RfMum-soyokihtULpA@mail.gmail.com>
References: <patchbomb.1321617576@loki.upc.es>
	<ec94a7e4983ad6338db2.1321617579@loki.upc.es>
	<20174.35001.566794.745844@mariner.uk.xensource.com>
	<CAPLaKK5NWCZGF0pEfCDcO8-SSBHAR9P-RfMum-soyokihtULpA@mail.gmail.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 3 of 9 v2] libxl: add libxl__forkexec
 function to libxl_exec
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Roger Pau Monn=E9 writes ("Re: [Xen-devel] [PATCH 3 of 9 v2] libxl: add lib=
xl__forkexec function to libxl_exec"):
> 2011/11/24 Ian Jackson <Ian.Jackson@eu.citrix.com>:
> > Conveniently, I have already written the second function for you:
> > libxl_report_child_exitstatus :-).
> =

> Why does the libxl_report_child_exitstatus function print
> "unexpectedly exited status zero", shouldn't it print something like
> "child exited successfully"? Or I'm not supposed to call it if
> WIFEXITED(status) && WEXITSTATUS(status) =3D=3D 0?

You're not supposed to call it in that case, unless you weren't
expecting the process to exit.

And you can write
   WIFEXITED(status) && WEXITSTATUS(status) =3D=3D 0
more simply as
   status=3D=3D0
so this is quite easy to do.

Ian.

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 15:04:21 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 15:04:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW8Ao-0005Tm-E9; Thu, 01 Dec 2011 15:03:42 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1RW8An-0005TT-Ci
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 15:03:41 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1322751780!5487403!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDQ0MzI=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8665 invoked from network); 1 Dec 2011 15:03:01 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 15:03:01 -0000
X-IronPort-AV: E=Sophos;i="4.71,278,1320642000"; d="scan'208";a="19560971"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Dec 2011 10:03:00 -0500
Received: from [10.80.2.18] (10.80.2.18) by FTLPMAILMX02.citrite.net
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Thu, 1 Dec 2011
	10:02:59 -0500
Message-ID: <4ED79722.7090404@citrix.com>
Date: Thu, 1 Dec 2011 15:02:58 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.23) Gecko/20110921 Lightning/1.0b2 Thunderbird/3.1.15
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <CAFA7027.25E35%keir.xen@gmail.com> <4ED62C50.7060204@citrix.com>
	<4ED666D5.5060603@citrix.com>
	<4ED7522E0200007800064973@nat28.tlf.novell.com>
	<4ED74DAD.1040903@citrix.com>
	<4ED75E8402000078000649E6@nat28.tlf.novell.com>
	<4ED77347.6060200@citrix.com>
	<4ED787870200007800064B6F@nat28.tlf.novell.com>
In-Reply-To: <4ED787870200007800064B6F@nat28.tlf.novell.com>
X-Enigmail-Version: 1.1.2
Cc: Keir Fraser <keir.xen@gmail.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [RFC] KEXEC: allocate crash note buffers at boot
	time v3
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/12/11 12:56, Jan Beulich wrote:
>>>> On 01.12.11 at 13:29, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>> +static spinlock_t crash_notes_lock = SPIN_LOCK_UNLOCKED;
> Please use DEFINE_SPINLOCK() here.
>
>> +    register_keyhandler('C', &crashdump_trigger_keyhandler);
>> +
>> +    /* If no crash area, no need to allocate space for notes. */
>> +    if ( 0 == kexec_crash_area.size )
>> +        return 0;
> Wouldn't it make sense to switch the order of these?
>
>> +    crash_notes = xmalloc_bytes(nr_cpu_ids * sizeof(void*));
> Please use xmalloc_array() here.
>
>> +    if ( !crash_notes[nr] && 0 != kexec_init_cpu_notes(nr) )
> The first check is pointless - the function will return zero if the
> allocation was already done.

I forgot to say in my previous email.  Short circuit evaluation should
prevent the kexec_init_cpu_notes() function call actually being made.

> Further, you shouldn't take a lock around a call to xmalloc() or alike
> unless absolutely necessary. It is pretty simple to avoid here - you
> really only need to lock around the storing of the pointer and maybe
> the setup_note() calls (but be careful with returning -ENOMEM - you
> shouldn't if the allocation fails, but you then find - under the lock -
> that a pointer was already set by another CPU).
>
> Finally, one thing I failed to notice on the previous version - the
> nr_bytes calculations are now being done twice. This should
> probably be moved into a helper function, especially since you
> said you intend to add stuff here subsequently.
>
> Jan
>

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com


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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 15:04:21 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 15:04:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW8Ao-0005Tm-E9; Thu, 01 Dec 2011 15:03:42 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1RW8An-0005TT-Ci
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 15:03:41 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1322751780!5487403!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDQ0MzI=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8665 invoked from network); 1 Dec 2011 15:03:01 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 15:03:01 -0000
X-IronPort-AV: E=Sophos;i="4.71,278,1320642000"; d="scan'208";a="19560971"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Dec 2011 10:03:00 -0500
Received: from [10.80.2.18] (10.80.2.18) by FTLPMAILMX02.citrite.net
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Thu, 1 Dec 2011
	10:02:59 -0500
Message-ID: <4ED79722.7090404@citrix.com>
Date: Thu, 1 Dec 2011 15:02:58 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.23) Gecko/20110921 Lightning/1.0b2 Thunderbird/3.1.15
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <CAFA7027.25E35%keir.xen@gmail.com> <4ED62C50.7060204@citrix.com>
	<4ED666D5.5060603@citrix.com>
	<4ED7522E0200007800064973@nat28.tlf.novell.com>
	<4ED74DAD.1040903@citrix.com>
	<4ED75E8402000078000649E6@nat28.tlf.novell.com>
	<4ED77347.6060200@citrix.com>
	<4ED787870200007800064B6F@nat28.tlf.novell.com>
In-Reply-To: <4ED787870200007800064B6F@nat28.tlf.novell.com>
X-Enigmail-Version: 1.1.2
Cc: Keir Fraser <keir.xen@gmail.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [RFC] KEXEC: allocate crash note buffers at boot
	time v3
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/12/11 12:56, Jan Beulich wrote:
>>>> On 01.12.11 at 13:29, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>> +static spinlock_t crash_notes_lock = SPIN_LOCK_UNLOCKED;
> Please use DEFINE_SPINLOCK() here.
>
>> +    register_keyhandler('C', &crashdump_trigger_keyhandler);
>> +
>> +    /* If no crash area, no need to allocate space for notes. */
>> +    if ( 0 == kexec_crash_area.size )
>> +        return 0;
> Wouldn't it make sense to switch the order of these?
>
>> +    crash_notes = xmalloc_bytes(nr_cpu_ids * sizeof(void*));
> Please use xmalloc_array() here.
>
>> +    if ( !crash_notes[nr] && 0 != kexec_init_cpu_notes(nr) )
> The first check is pointless - the function will return zero if the
> allocation was already done.

I forgot to say in my previous email.  Short circuit evaluation should
prevent the kexec_init_cpu_notes() function call actually being made.

> Further, you shouldn't take a lock around a call to xmalloc() or alike
> unless absolutely necessary. It is pretty simple to avoid here - you
> really only need to lock around the storing of the pointer and maybe
> the setup_note() calls (but be careful with returning -ENOMEM - you
> shouldn't if the allocation fails, but you then find - under the lock -
> that a pointer was already set by another CPU).
>
> Finally, one thing I failed to notice on the previous version - the
> nr_bytes calculations are now being done twice. This should
> probably be moved into a helper function, especially since you
> said you intend to add stuff here subsequently.
>
> Jan
>

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com


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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 15:11:04 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 15: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.xensource.com>)
	id 1RW8HQ-0005gF-9q; Thu, 01 Dec 2011 15:10:32 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <stefan.bader@canonical.com>) id 1RW8HO-0005g0-Aa
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 15:10:30 +0000
X-Env-Sender: stefan.bader@canonical.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1322752190!6395594!1
X-Originating-IP: [91.189.89.112]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13288 invoked from network); 1 Dec 2011 15:09:50 -0000
Received: from youngberry.canonical.com (HELO youngberry.canonical.com)
	(91.189.89.112) by server-11.tower-21.messagelabs.com with SMTP;
	1 Dec 2011 15:09:50 -0000
Received: from p5b2e33b7.dip.t-dialin.net ([91.46.51.183] helo=[192.168.2.5])
	by youngberry.canonical.com with esmtpsa
	(TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71)
	(envelope-from <stefan.bader@canonical.com>)
	id 1RW8Gj-0003wu-NF; Thu, 01 Dec 2011 15:09:49 +0000
Message-ID: <4ED798B2.1040309@canonical.com>
Date: Thu, 01 Dec 2011 16:09:38 +0100
From: Stefan Bader <stefan.bader@canonical.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:8.0) Gecko/20111124 Thunderbird/8.0
MIME-Version: 1.0
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
X-Enigmail-Version: 1.4a1pre
Cc: Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] Xen 4.x / Linux 3.x (dom0 and HVM domU) and NIC handling
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Moving to public discussion...

This was found with Xen hypervisor version supporting device unplugging and the
domU kernel having net-/blkfront and pci platform built-in (or as module).

The block device is defined as hda and the NIC type=ioemu (so theoretically
guests without pv support would work, too).

Since both drivers are present, the kernel tries to unplug the emulated devices
and succeeds. The blkfront driver detects the xvda device available in parallel
and is working ok.

However the network interface does not work. There are entries present under
sysfs for the xenbus but trying to bring it up fails with errors. And also there
seems to be no mac address set (all zeros in sysfs).
When the type=ioemu is removed in the configuration, this works.

I have not much more debugging information beyond that, yet. But it sounds a bit
like NICs should behave the same as block devices. So if there is an emulated
device defined there will be an alternate paravirt interface for it and after
unplugging the emulated ones we end up with the pv ones.
Is that something that can be seen with newer Xen versions, too (I am using 4.1.1)?

-Stefan

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 15:11:04 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 15: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.xensource.com>)
	id 1RW8HQ-0005gF-9q; Thu, 01 Dec 2011 15:10:32 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <stefan.bader@canonical.com>) id 1RW8HO-0005g0-Aa
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 15:10:30 +0000
X-Env-Sender: stefan.bader@canonical.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1322752190!6395594!1
X-Originating-IP: [91.189.89.112]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13288 invoked from network); 1 Dec 2011 15:09:50 -0000
Received: from youngberry.canonical.com (HELO youngberry.canonical.com)
	(91.189.89.112) by server-11.tower-21.messagelabs.com with SMTP;
	1 Dec 2011 15:09:50 -0000
Received: from p5b2e33b7.dip.t-dialin.net ([91.46.51.183] helo=[192.168.2.5])
	by youngberry.canonical.com with esmtpsa
	(TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71)
	(envelope-from <stefan.bader@canonical.com>)
	id 1RW8Gj-0003wu-NF; Thu, 01 Dec 2011 15:09:49 +0000
Message-ID: <4ED798B2.1040309@canonical.com>
Date: Thu, 01 Dec 2011 16:09:38 +0100
From: Stefan Bader <stefan.bader@canonical.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:8.0) Gecko/20111124 Thunderbird/8.0
MIME-Version: 1.0
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
X-Enigmail-Version: 1.4a1pre
Cc: Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] Xen 4.x / Linux 3.x (dom0 and HVM domU) and NIC handling
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Moving to public discussion...

This was found with Xen hypervisor version supporting device unplugging and the
domU kernel having net-/blkfront and pci platform built-in (or as module).

The block device is defined as hda and the NIC type=ioemu (so theoretically
guests without pv support would work, too).

Since both drivers are present, the kernel tries to unplug the emulated devices
and succeeds. The blkfront driver detects the xvda device available in parallel
and is working ok.

However the network interface does not work. There are entries present under
sysfs for the xenbus but trying to bring it up fails with errors. And also there
seems to be no mac address set (all zeros in sysfs).
When the type=ioemu is removed in the configuration, this works.

I have not much more debugging information beyond that, yet. But it sounds a bit
like NICs should behave the same as block devices. So if there is an emulated
device defined there will be an alternate paravirt interface for it and after
unplugging the emulated ones we end up with the pv ones.
Is that something that can be seen with newer Xen versions, too (I am using 4.1.1)?

-Stefan

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 15:11:51 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 15:11:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW8IP-0005is-RJ; Thu, 01 Dec 2011 15:11:33 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RW8IO-0005ie-GJ
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 15:11:32 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-8.tower-216.messagelabs.com!1322752252!5818200!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8425 invoked from network); 1 Dec 2011 15:10:52 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-8.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 1 Dec 2011 15:10:52 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RW8Gr-000GWi-Rc; Thu, 01 Dec 2011 15:09:57 +0000
Date: Thu, 1 Dec 2011 15:09:57 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20111201150957.GF61203@ocelot.phlegethon.org>
References: <patchbomb.1322598097@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <patchbomb.1322598097@xdev.gridcentric.ca>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com, ian.campbell@citrix.com,
	andres@gridcentric.ca, keir.xen@gmail.com, JBeulich@suse.com,
	ian.jackson@citrix.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 0 of 9] MM Bug fixes
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 15:21 -0500 on 29 Nov (1322580097), Andres Lagar-Cavilla wrote:
> This patch series includes a number of bug fixes previously
> submitted, or newly found, for the mm layer.
> 
> Patches 1 and 7 are tool patches, cc'ed tool maintainers. Everything 
> else is hypervisors-x86-mm.

Patch 4 I applied but then reverted -- the 32-bit version doesn't 
        even compile.
Patch 5 has been commented on separately.
Patch 8 I'll leave until the full patch that fixes all instances.

I've applied the others, with minor modifications to #2 (to use more
consistent names with the rest of shadow code) and #6 (tidying up the
domctl handler, in particular using rcu_lock_remote_target_domain_by_id() 
instead of open-coding the domain checks).

Cheers,

Tim.

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 15:11:51 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 15:11:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW8IP-0005is-RJ; Thu, 01 Dec 2011 15:11:33 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RW8IO-0005ie-GJ
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 15:11:32 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-8.tower-216.messagelabs.com!1322752252!5818200!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8425 invoked from network); 1 Dec 2011 15:10:52 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-8.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 1 Dec 2011 15:10:52 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RW8Gr-000GWi-Rc; Thu, 01 Dec 2011 15:09:57 +0000
Date: Thu, 1 Dec 2011 15:09:57 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20111201150957.GF61203@ocelot.phlegethon.org>
References: <patchbomb.1322598097@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <patchbomb.1322598097@xdev.gridcentric.ca>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com, ian.campbell@citrix.com,
	andres@gridcentric.ca, keir.xen@gmail.com, JBeulich@suse.com,
	ian.jackson@citrix.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 0 of 9] MM Bug fixes
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 15:21 -0500 on 29 Nov (1322580097), Andres Lagar-Cavilla wrote:
> This patch series includes a number of bug fixes previously
> submitted, or newly found, for the mm layer.
> 
> Patches 1 and 7 are tool patches, cc'ed tool maintainers. Everything 
> else is hypervisors-x86-mm.

Patch 4 I applied but then reverted -- the 32-bit version doesn't 
        even compile.
Patch 5 has been commented on separately.
Patch 8 I'll leave until the full patch that fixes all instances.

I've applied the others, with minor modifications to #2 (to use more
consistent names with the rest of shadow code) and #6 (tidying up the
domctl handler, in particular using rcu_lock_remote_target_domain_by_id() 
instead of open-coding the domain checks).

Cheers,

Tim.

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 15:12:04 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 15: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.xensource.com>)
	id 1RW8Ig-0005kI-GW; Thu, 01 Dec 2011 15:11:50 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RW8If-0005jf-5j
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 15:11:49 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1322752269!5759766!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU2Nw==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5405 invoked from network); 1 Dec 2011 15:11:09 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 15:11:09 -0000
X-IronPort-AV: E=Sophos;i="4.71,278,1320624000"; 
   d="scan'208";a="9233748"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Dec 2011 15:11:09 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 1 Dec 2011 15:11:09 +0000
Date: Thu, 1 Dec 2011 15:12:06 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1322735197.31810.191.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1112011441340.31179@kaball-desktop>
References: <alpine.DEB.2.00.1111281009090.31179@kaball-desktop>
	<201111301432.54463.arnd@arndb.de>
	<1322670473.31810.129.camel@zakaz.uk.xensource.com>
	<201111301815.01297.arnd@arndb.de>
	<alpine.DEB.2.00.1111301820290.31179@kaball-desktop>
	<1322735197.31810.191.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linaro-dev@lists.linaro.org" <linaro-dev@lists.linaro.org>,
	Pawel Moll <pawel.moll@arm.com>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"virtualization@lists.linux-foundation.org"
	<virtualization@lists.linux-foundation.org>, Arnd Bergmann <arnd@arndb.de>,
	"android-virt@lists.cs.columbia.edu" <android-virt@lists.cs.columbia.edu>,
	"embeddedxen-devel@lists.sourceforge.net"
	<embeddedxen-devel@lists.sourceforge.net>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [Embeddedxen-devel] [ANNOUNCE] Xen port to
 Cortex-A15 / ARMv7 with virt extensions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 1 Dec 2011, Ian Campbell wrote:
> On Wed, 2011-11-30 at 18:32 +0000, Stefano Stabellini wrote:
> > On Wed, 30 Nov 2011, Arnd Bergmann wrote:
> > > KVM and Xen at least both fall into the single-return-value category,
> > > so we should be able to agree on a calling conventions. KVM does not
> > > have an hcall API on ARM yet, and I see no reason not to use the
> > > same implementation that you have in the Xen guest.
> > > 
> > > Stefano, can you split out the generic parts of your asm/xen/hypercall.h
> > > file into a common asm/hypercall.h and submit it for review to the
> > > arm kernel list?
> > 
> > Sure, I can do that.
> > Usually the hypercall calling convention is very hypervisor specific,
> > but if it turns out that we have the same requirements I happy to design
> > a common interface.
> 
> I expect the only real decision to be made is hypercall page vs. raw hvc
> instruction.
> 
> The page was useful on x86 where there is a variety of instructions
> which could be used (at least for PV there was systenter/syscall/int, I
> think vmcall instruction differs between AMD and Intel also) and gives
> some additional flexibility. It's hard to predict but I don't think I'd
> expect that to be necessary on ARM.
>
> Another reason for having a hypercall page instead of a raw instruction
> might be wanting to support 32 bit guests (from ~today) on a 64 bit
> hypervisor in the future and perhaps needing to do some shimming/arg
> translation. It would be better to aim for having the interface just be
> 32/64 agnostic but mistakes do happen.

I always like to keep things as simple as possible, so I am in favor of
using the raw hvc instruction.
Besides with the bulk of mmu hypercalls gone, it should not be difficult
to design a 32/64 bit agnostic interface.

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 15:12:04 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 15: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.xensource.com>)
	id 1RW8Ig-0005kI-GW; Thu, 01 Dec 2011 15:11:50 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RW8If-0005jf-5j
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 15:11:49 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1322752269!5759766!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU2Nw==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5405 invoked from network); 1 Dec 2011 15:11:09 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 15:11:09 -0000
X-IronPort-AV: E=Sophos;i="4.71,278,1320624000"; 
   d="scan'208";a="9233748"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Dec 2011 15:11:09 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 1 Dec 2011 15:11:09 +0000
Date: Thu, 1 Dec 2011 15:12:06 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1322735197.31810.191.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1112011441340.31179@kaball-desktop>
References: <alpine.DEB.2.00.1111281009090.31179@kaball-desktop>
	<201111301432.54463.arnd@arndb.de>
	<1322670473.31810.129.camel@zakaz.uk.xensource.com>
	<201111301815.01297.arnd@arndb.de>
	<alpine.DEB.2.00.1111301820290.31179@kaball-desktop>
	<1322735197.31810.191.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linaro-dev@lists.linaro.org" <linaro-dev@lists.linaro.org>,
	Pawel Moll <pawel.moll@arm.com>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"virtualization@lists.linux-foundation.org"
	<virtualization@lists.linux-foundation.org>, Arnd Bergmann <arnd@arndb.de>,
	"android-virt@lists.cs.columbia.edu" <android-virt@lists.cs.columbia.edu>,
	"embeddedxen-devel@lists.sourceforge.net"
	<embeddedxen-devel@lists.sourceforge.net>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [Embeddedxen-devel] [ANNOUNCE] Xen port to
 Cortex-A15 / ARMv7 with virt extensions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 1 Dec 2011, Ian Campbell wrote:
> On Wed, 2011-11-30 at 18:32 +0000, Stefano Stabellini wrote:
> > On Wed, 30 Nov 2011, Arnd Bergmann wrote:
> > > KVM and Xen at least both fall into the single-return-value category,
> > > so we should be able to agree on a calling conventions. KVM does not
> > > have an hcall API on ARM yet, and I see no reason not to use the
> > > same implementation that you have in the Xen guest.
> > > 
> > > Stefano, can you split out the generic parts of your asm/xen/hypercall.h
> > > file into a common asm/hypercall.h and submit it for review to the
> > > arm kernel list?
> > 
> > Sure, I can do that.
> > Usually the hypercall calling convention is very hypervisor specific,
> > but if it turns out that we have the same requirements I happy to design
> > a common interface.
> 
> I expect the only real decision to be made is hypercall page vs. raw hvc
> instruction.
> 
> The page was useful on x86 where there is a variety of instructions
> which could be used (at least for PV there was systenter/syscall/int, I
> think vmcall instruction differs between AMD and Intel also) and gives
> some additional flexibility. It's hard to predict but I don't think I'd
> expect that to be necessary on ARM.
>
> Another reason for having a hypercall page instead of a raw instruction
> might be wanting to support 32 bit guests (from ~today) on a 64 bit
> hypervisor in the future and perhaps needing to do some shimming/arg
> translation. It would be better to aim for having the interface just be
> 32/64 agnostic but mistakes do happen.

I always like to keep things as simple as possible, so I am in favor of
using the raw hvc instruction.
Besides with the bulk of mmu hypercalls gone, it should not be difficult
to design a 32/64 bit agnostic interface.

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 15:15:21 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 15:15:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW8Lj-00062f-C5; Thu, 01 Dec 2011 15:14:59 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RW8Li-00061x-6f
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 15:14:58 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1322752457!5480430!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQzODQ=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7923 invoked from network); 1 Dec 2011 15:14:18 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-10.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 1 Dec 2011 15:14:18 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 01 Dec 2011 15:14:16 +0000
Message-Id: <4ED7A7D80200007800064C4D@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 01 Dec 2011 15:14:16 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>
References: <CAFA7027.25E35%keir.xen@gmail.com>
	<4ED62C50.7060204@citrix.com> <4ED666D5.5060603@citrix.com>
	<4ED7522E0200007800064973@nat28.tlf.novell.com>
	<4ED74DAD.1040903@citrix.com>
	<4ED75E8402000078000649E6@nat28.tlf.novell.com>
	<4ED77347.6060200@citrix.com>
	<4ED787870200007800064B6F@nat28.tlf.novell.com>
	<4ED78855.3080801@citrix.com>
In-Reply-To: <4ED78855.3080801@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Keir Fraser <keir.xen@gmail.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [RFC] KEXEC: allocate crash note buffers at boot
	time v3
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 01.12.11 at 14:59, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
> On 01/12/11 12:56, Jan Beulich wrote:
>> Further, you shouldn't take a lock around a call to xmalloc() or alike
>> unless absolutely necessary. It is pretty simple to avoid here - you
>> really only need to lock around the storing of the pointer and maybe
>> the setup_note() calls (but be careful with returning -ENOMEM - you
>> shouldn't if the allocation fails, but you then find - under the lock -
>> that a pointer was already set by another CPU).
> 
> So what we should do is this:
> 
> xmalloc
> take lock
> check to see if the entry is been filled in the meantime.  if so, free
> the malloc'd region

Don't call xfree() with the lock held either, if possible.

> release lock
> only return -ENOMEM if we fail the malloc and the crash_note is still
> NULL when we take the lock

Jan


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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 15:15:21 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 15:15:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW8Lj-00062f-C5; Thu, 01 Dec 2011 15:14:59 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RW8Li-00061x-6f
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 15:14:58 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1322752457!5480430!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQzODQ=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7923 invoked from network); 1 Dec 2011 15:14:18 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-10.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 1 Dec 2011 15:14:18 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 01 Dec 2011 15:14:16 +0000
Message-Id: <4ED7A7D80200007800064C4D@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 01 Dec 2011 15:14:16 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>
References: <CAFA7027.25E35%keir.xen@gmail.com>
	<4ED62C50.7060204@citrix.com> <4ED666D5.5060603@citrix.com>
	<4ED7522E0200007800064973@nat28.tlf.novell.com>
	<4ED74DAD.1040903@citrix.com>
	<4ED75E8402000078000649E6@nat28.tlf.novell.com>
	<4ED77347.6060200@citrix.com>
	<4ED787870200007800064B6F@nat28.tlf.novell.com>
	<4ED78855.3080801@citrix.com>
In-Reply-To: <4ED78855.3080801@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Keir Fraser <keir.xen@gmail.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [RFC] KEXEC: allocate crash note buffers at boot
	time v3
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 01.12.11 at 14:59, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
> On 01/12/11 12:56, Jan Beulich wrote:
>> Further, you shouldn't take a lock around a call to xmalloc() or alike
>> unless absolutely necessary. It is pretty simple to avoid here - you
>> really only need to lock around the storing of the pointer and maybe
>> the setup_note() calls (but be careful with returning -ENOMEM - you
>> shouldn't if the allocation fails, but you then find - under the lock -
>> that a pointer was already set by another CPU).
> 
> So what we should do is this:
> 
> xmalloc
> take lock
> check to see if the entry is been filled in the meantime.  if so, free
> the malloc'd region

Don't call xfree() with the lock held either, if possible.

> release lock
> only return -ENOMEM if we fail the malloc and the crash_note is still
> NULL when we take the lock

Jan


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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 15:16:09 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 15:16:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW8Me-000689-RH; Thu, 01 Dec 2011 15:15:56 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RW8Md-00067W-Eg
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 15:15:55 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1322752514!5506647!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQzODQ=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11190 invoked from network); 1 Dec 2011 15:15:15 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-3.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 1 Dec 2011 15:15:15 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 01 Dec 2011 15:15:14 +0000
Message-Id: <4ED7A8110200007800064C50@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 01 Dec 2011 15:15:13 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>
References: <CAFA7027.25E35%keir.xen@gmail.com>
	<4ED62C50.7060204@citrix.com> <4ED666D5.5060603@citrix.com>
	<4ED7522E0200007800064973@nat28.tlf.novell.com>
	<4ED74DAD.1040903@citrix.com>
	<4ED75E8402000078000649E6@nat28.tlf.novell.com>
	<4ED77347.6060200@citrix.com>
	<4ED787870200007800064B6F@nat28.tlf.novell.com>
	<4ED79722.7090404@citrix.com>
In-Reply-To: <4ED79722.7090404@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Keir Fraser <keir.xen@gmail.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [RFC] KEXEC: allocate crash note buffers at boot
	time v3
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 01.12.11 at 16:02, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
> On 01/12/11 12:56, Jan Beulich wrote:
>>>>> On 01.12.11 at 13:29, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>>> +static spinlock_t crash_notes_lock = SPIN_LOCK_UNLOCKED;
>> Please use DEFINE_SPINLOCK() here.
>>
>>> +    register_keyhandler('C', &crashdump_trigger_keyhandler);
>>> +
>>> +    /* If no crash area, no need to allocate space for notes. */
>>> +    if ( 0 == kexec_crash_area.size )
>>> +        return 0;
>> Wouldn't it make sense to switch the order of these?
>>
>>> +    crash_notes = xmalloc_bytes(nr_cpu_ids * sizeof(void*));
>> Please use xmalloc_array() here.
>>
>>> +    if ( !crash_notes[nr] && 0 != kexec_init_cpu_notes(nr) )
>> The first check is pointless - the function will return zero if the
>> allocation was already done.
> 
> I forgot to say in my previous email.  Short circuit evaluation should
> prevent the kexec_init_cpu_notes() function call actually being made.

What would that buy you? Performance is not an issue on this code
path.

Jan


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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 15:16:09 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 15:16:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW8Me-000689-RH; Thu, 01 Dec 2011 15:15:56 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RW8Md-00067W-Eg
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 15:15:55 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1322752514!5506647!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQzODQ=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11190 invoked from network); 1 Dec 2011 15:15:15 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-3.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 1 Dec 2011 15:15:15 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 01 Dec 2011 15:15:14 +0000
Message-Id: <4ED7A8110200007800064C50@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 01 Dec 2011 15:15:13 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>
References: <CAFA7027.25E35%keir.xen@gmail.com>
	<4ED62C50.7060204@citrix.com> <4ED666D5.5060603@citrix.com>
	<4ED7522E0200007800064973@nat28.tlf.novell.com>
	<4ED74DAD.1040903@citrix.com>
	<4ED75E8402000078000649E6@nat28.tlf.novell.com>
	<4ED77347.6060200@citrix.com>
	<4ED787870200007800064B6F@nat28.tlf.novell.com>
	<4ED79722.7090404@citrix.com>
In-Reply-To: <4ED79722.7090404@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Keir Fraser <keir.xen@gmail.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [RFC] KEXEC: allocate crash note buffers at boot
	time v3
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 01.12.11 at 16:02, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
> On 01/12/11 12:56, Jan Beulich wrote:
>>>>> On 01.12.11 at 13:29, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>>> +static spinlock_t crash_notes_lock = SPIN_LOCK_UNLOCKED;
>> Please use DEFINE_SPINLOCK() here.
>>
>>> +    register_keyhandler('C', &crashdump_trigger_keyhandler);
>>> +
>>> +    /* If no crash area, no need to allocate space for notes. */
>>> +    if ( 0 == kexec_crash_area.size )
>>> +        return 0;
>> Wouldn't it make sense to switch the order of these?
>>
>>> +    crash_notes = xmalloc_bytes(nr_cpu_ids * sizeof(void*));
>> Please use xmalloc_array() here.
>>
>>> +    if ( !crash_notes[nr] && 0 != kexec_init_cpu_notes(nr) )
>> The first check is pointless - the function will return zero if the
>> allocation was already done.
> 
> I forgot to say in my previous email.  Short circuit evaluation should
> prevent the kexec_init_cpu_notes() function call actually being made.

What would that buy you? Performance is not an issue on this code
path.

Jan


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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 15:17:04 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 15:17:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW8Nb-0006Et-AT; Thu, 01 Dec 2011 15:16:55 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RW8NZ-0006Dv-MK
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 15:16:53 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1322752572!6581537!1
X-Originating-IP: [209.85.161.171]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10704 invoked from network); 1 Dec 2011 15:16:13 -0000
Received: from mail-gx0-f171.google.com (HELO mail-gx0-f171.google.com)
	(209.85.161.171)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 15:16:13 -0000
Received: by ggnr4 with SMTP id r4so14010375ggn.30
	for <xen-devel@lists.xensource.com>;
	Thu, 01 Dec 2011 07:16:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:message-id:user-agent:date:from:to;
	bh=F+irDLy5T9dX32iyyu25Az55Vyn5cnrAh0ebS5idaDY=;
	b=hU3FK67KoEBxHNeA1yqw7BNZhZvXVKa5loxuXAks/eXD/YjXxSWNQ7/HjP8WCTDCNF
	rlgYJc01KWI7i+r3Tz2TFXbCQTKXSvFswa5+nBEkKkiLH07uLEQ1Eq1vL3ZQ9U3jbNiu
	mJeuWGOzLmdKxyzVv6eU4bSnhykZlhNd/FHCI=
Received: by 10.204.41.66 with SMTP id n2mr8006990bke.77.1322752571598;
	Thu, 01 Dec 2011 07:16:11 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id c4sm11924270bkk.13.2011.12.01.07.16.09
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 01 Dec 2011 07:16:09 -0800 (PST)
MIME-Version: 1.0
Message-Id: <patchbomb.1322752087@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Thu, 01 Dec 2011 16:08:07 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 00 of 11 v3] libxl: add support for hotplug
 script calling from libxl
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This patch series adds support for hotplug script calling directly
from libxl, instead of relying on xenbackendd. Also some patches
contain general bug fixes.

Currently Linux hotplug script call functions are empty, so Linux
continues to use udev rules to call hotplug scripts.

Patches 1, 7, 8, 9, 10 are NetBSD specific, and basicaly pave the way 
for the application of the bigger changes present in this series.

Patch 11 is a trivial update for an error message.

Patch 2 adds support for mounting raw image files using the vnd
device. Since NetBSD doesn't have qdisk or blktap support, the only
way to use raw images with guests is to mount the image and pass the
block device as a "PHY" backend. To check wheter an OS supports raw
images as "PHY" backends two new files are added to the project, to
avoid using #ifdefs, that contain a helper function. The file
to be included is decided during the compilation process.

Patch 3 adds a generic function to fork the current process and
execute a given file, which will be later used to execute hotplug
scripts synchronously.

Patches 4 and 5 add a new function to wait for a device to reach a
certain state, and replace wait_for_dev_destroy with this more generic
implementation. This function is also used to wait for device
initialization before calling hotplug scripts. The added function will
benefit from a rework after event support is added to libxl.

Finally patch 6 adds the calling of hotplug scripts when devices are
initializated and removed. Two new files are also added to support
hotplug scripts, since Linux and NetBSD hotplug scripts have different
call parameters. The path of the script to execute is retrieved
from xenstore. The file to include is also decided at compile
time.

Changes since v2:

 * Use libxl_linux.c and libxl_netbsd.c to place OS specific 
   functions.

 * Fixed libxl__forkexec comment, adding the need to pass NULL as the 
   last array member.

 * Use XenbusState instead of state numbers.

 * Use libxl_report_child_exit and return the exit status of the 
   process in libxl__forkexec.

 * Pass action to execute to hotplug scripts, either CONNECT or 
   DISCONNECT.

Please review, Roger.

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 15:17:04 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 15:17:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW8Nb-0006Et-AT; Thu, 01 Dec 2011 15:16:55 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RW8NZ-0006Dv-MK
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 15:16:53 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1322752572!6581537!1
X-Originating-IP: [209.85.161.171]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10704 invoked from network); 1 Dec 2011 15:16:13 -0000
Received: from mail-gx0-f171.google.com (HELO mail-gx0-f171.google.com)
	(209.85.161.171)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 15:16:13 -0000
Received: by ggnr4 with SMTP id r4so14010375ggn.30
	for <xen-devel@lists.xensource.com>;
	Thu, 01 Dec 2011 07:16:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:message-id:user-agent:date:from:to;
	bh=F+irDLy5T9dX32iyyu25Az55Vyn5cnrAh0ebS5idaDY=;
	b=hU3FK67KoEBxHNeA1yqw7BNZhZvXVKa5loxuXAks/eXD/YjXxSWNQ7/HjP8WCTDCNF
	rlgYJc01KWI7i+r3Tz2TFXbCQTKXSvFswa5+nBEkKkiLH07uLEQ1Eq1vL3ZQ9U3jbNiu
	mJeuWGOzLmdKxyzVv6eU4bSnhykZlhNd/FHCI=
Received: by 10.204.41.66 with SMTP id n2mr8006990bke.77.1322752571598;
	Thu, 01 Dec 2011 07:16:11 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id c4sm11924270bkk.13.2011.12.01.07.16.09
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 01 Dec 2011 07:16:09 -0800 (PST)
MIME-Version: 1.0
Message-Id: <patchbomb.1322752087@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Thu, 01 Dec 2011 16:08:07 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 00 of 11 v3] libxl: add support for hotplug
 script calling from libxl
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This patch series adds support for hotplug script calling directly
from libxl, instead of relying on xenbackendd. Also some patches
contain general bug fixes.

Currently Linux hotplug script call functions are empty, so Linux
continues to use udev rules to call hotplug scripts.

Patches 1, 7, 8, 9, 10 are NetBSD specific, and basicaly pave the way 
for the application of the bigger changes present in this series.

Patch 11 is a trivial update for an error message.

Patch 2 adds support for mounting raw image files using the vnd
device. Since NetBSD doesn't have qdisk or blktap support, the only
way to use raw images with guests is to mount the image and pass the
block device as a "PHY" backend. To check wheter an OS supports raw
images as "PHY" backends two new files are added to the project, to
avoid using #ifdefs, that contain a helper function. The file
to be included is decided during the compilation process.

Patch 3 adds a generic function to fork the current process and
execute a given file, which will be later used to execute hotplug
scripts synchronously.

Patches 4 and 5 add a new function to wait for a device to reach a
certain state, and replace wait_for_dev_destroy with this more generic
implementation. This function is also used to wait for device
initialization before calling hotplug scripts. The added function will
benefit from a rework after event support is added to libxl.

Finally patch 6 adds the calling of hotplug scripts when devices are
initializated and removed. Two new files are also added to support
hotplug scripts, since Linux and NetBSD hotplug scripts have different
call parameters. The path of the script to execute is retrieved
from xenstore. The file to include is also decided at compile
time.

Changes since v2:

 * Use libxl_linux.c and libxl_netbsd.c to place OS specific 
   functions.

 * Fixed libxl__forkexec comment, adding the need to pass NULL as the 
   last array member.

 * Use XenbusState instead of state numbers.

 * Use libxl_report_child_exit and return the exit status of the 
   process in libxl__forkexec.

 * Pass action to execute to hotplug scripts, either CONNECT or 
   DISCONNECT.

Please review, Roger.

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 15:17:09 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 15:17:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW8Nb-0006F2-OR; Thu, 01 Dec 2011 15:16:55 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RW8Na-0006E7-U7
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 15:16:55 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1322752574!4953754!1
X-Originating-IP: [209.85.214.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28569 invoked from network); 1 Dec 2011 15:16:15 -0000
Received: from mail-bw0-f43.google.com (HELO mail-bw0-f43.google.com)
	(209.85.214.43)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 15:16:15 -0000
Received: by bkwj4 with SMTP id j4so2238541bkw.30
	for <xen-devel@lists.xensource.com>;
	Thu, 01 Dec 2011 07:16:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=rIJw/yUbhXlo/6JNP9moJYJGk170Fpw5iLZGW2u7Ga8=;
	b=DLHq0kR1LD2JUGUH9pPI4+hED3hZqFb4ImzIWOcO457fWW+ebX7/SVOBcDEZaDvkSB
	UV39Bew1CFgGT1JtMkCxMKxEv0i2xw8WfflTMBx2QET/wLFBS2ZF53WvtMjFzLY0Us0N
	WdRjbgHyKdzTDaIsWzXsjew+CbGoyo9keCjc4=
Received: by 10.204.148.80 with SMTP id o16mr7615008bkv.93.1322752574614;
	Thu, 01 Dec 2011 07:16:14 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id c4sm11924270bkk.13.2011.12.01.07.16.11
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 01 Dec 2011 07:16:13 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 23578c9942bcc8767adc4e435bb1fd1cd89f5e18
Message-Id: <23578c9942bcc8767adc.1322752088@loki.upc.es>
In-Reply-To: <patchbomb.1322752087@loki.upc.es>
References: <patchbomb.1322752087@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Thu, 01 Dec 2011 16:08:08 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 01 of 11 v3] xenbackendd: pass type of block
 device to hotplug script
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1317386335 -7200
# Node ID 23578c9942bcc8767adc4e435bb1fd1cd89f5e18
# Parent  fd3567cafe1c7ccd0ddba0ad7fb067d435e13529
xenbackendd: pass type of block device to hotplug script

Pass the type of block device to attach to the block script instead
of reading it from xenstore, since new Xen versions don't make a
difference between a block device or an image.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r fd3567cafe1c -r 23578c9942bc tools/hotplug/NetBSD/block
--- a/tools/hotplug/NetBSD/block	Tue Nov 15 14:50:18 2011 +0100
+++ b/tools/hotplug/NetBSD/block	Fri Sep 30 14:38:55 2011 +0200
@@ -19,7 +19,7 @@ error() {
 
 xpath=$1
 xstatus=$2
-xtype=$(xenstore-read "$xpath/type")
+xtype=$3
 xparams=$(xenstore-read "$xpath/params")
 
 case $xstatus in
diff -r fd3567cafe1c -r 23578c9942bc tools/xenbackendd/xenbackendd.c
--- a/tools/xenbackendd/xenbackendd.c	Tue Nov 15 14:50:18 2011 +0100
+++ b/tools/xenbackendd/xenbackendd.c	Fri Sep 30 14:38:55 2011 +0200
@@ -89,15 +89,15 @@ dodebug(const char *fmt, ...)
 }
 
 static void
-doexec(const char *cmd, const char *arg1, const char *arg2)
+doexec(const char *cmd, const char *arg1, const char *arg2, const char *arg3)
 {
-	dodebug("exec %s %s %s", cmd, arg1, arg2);
+	dodebug("exec %s %s %s %s", cmd, arg1, arg2, arg3);
 	switch(vfork()) {
 	case -1:
 		dolog(LOG_ERR, "can't vfork: %s", strerror(errno));
 		break;
 	case 0:
-		execl(cmd, cmd, arg1, arg2, NULL);
+		execl(cmd, cmd, arg1, arg2, arg3, NULL);
 		dolog(LOG_ERR, "can't exec %s: %s", cmd, strerror(errno));
 		exit(EXIT_FAILURE);
 		/* NOTREACHED */
@@ -145,11 +145,14 @@ xen_setup(void)
 int
 main(int argc, char * const argv[])
 {
+	struct stat stab;
 	char **vec;
 	unsigned int num;
 	char *s;
 	int state;
 	char *sstate;
+	char *stype;
+	char *params;
 	char *p;
 	char buf[80];
 	int type;
@@ -297,11 +300,38 @@ main(int argc, char * const argv[])
 				    strerror(errno));
 				goto next2;
 			}
-			doexec(s, vec[XS_WATCH_PATH], sstate);
+			doexec(s, vec[XS_WATCH_PATH], sstate, NULL);
 			break;
 
 		case DEVTYPE_VBD:
-			doexec(vbd_script, vec[XS_WATCH_PATH], sstate);
+			/* check if given file is a block device or a raw image */
+			snprintf(buf, sizeof(buf), "%s/params", vec[XS_WATCH_PATH]);
+			params = xs_read(xs, XBT_NULL, buf, 0);
+			if(params == NULL) {
+				dolog(LOG_ERR,
+					"Failed to read %s (%s)", buf, strerror(errno));
+				goto next2;
+			}
+			if (stat(params, &stab) < 0) {
+				dolog(LOG_ERR,
+					"Failed to get info about %s (%s)", params,
+					strerror(errno));
+				goto next3;
+			}
+			stype = NULL;
+			if (S_ISBLK(stab.st_mode))
+				stype = "phy";
+			if (S_ISREG(stab.st_mode))
+				stype = "file";
+			if (stype == NULL) {
+				dolog(LOG_ERR,
+					"Failed to attach %s (not a block device or raw image)",
+					params, strerror(errno));
+				goto next3;
+			}
+			doexec(vbd_script, vec[XS_WATCH_PATH], sstate, stype);
+next3:
+			free(params);
 			break;
 
 		default:

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 15:17:09 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 15:17:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW8Nb-0006F2-OR; Thu, 01 Dec 2011 15:16:55 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RW8Na-0006E7-U7
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 15:16:55 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1322752574!4953754!1
X-Originating-IP: [209.85.214.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28569 invoked from network); 1 Dec 2011 15:16:15 -0000
Received: from mail-bw0-f43.google.com (HELO mail-bw0-f43.google.com)
	(209.85.214.43)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 15:16:15 -0000
Received: by bkwj4 with SMTP id j4so2238541bkw.30
	for <xen-devel@lists.xensource.com>;
	Thu, 01 Dec 2011 07:16:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=rIJw/yUbhXlo/6JNP9moJYJGk170Fpw5iLZGW2u7Ga8=;
	b=DLHq0kR1LD2JUGUH9pPI4+hED3hZqFb4ImzIWOcO457fWW+ebX7/SVOBcDEZaDvkSB
	UV39Bew1CFgGT1JtMkCxMKxEv0i2xw8WfflTMBx2QET/wLFBS2ZF53WvtMjFzLY0Us0N
	WdRjbgHyKdzTDaIsWzXsjew+CbGoyo9keCjc4=
Received: by 10.204.148.80 with SMTP id o16mr7615008bkv.93.1322752574614;
	Thu, 01 Dec 2011 07:16:14 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id c4sm11924270bkk.13.2011.12.01.07.16.11
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 01 Dec 2011 07:16:13 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 23578c9942bcc8767adc4e435bb1fd1cd89f5e18
Message-Id: <23578c9942bcc8767adc.1322752088@loki.upc.es>
In-Reply-To: <patchbomb.1322752087@loki.upc.es>
References: <patchbomb.1322752087@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Thu, 01 Dec 2011 16:08:08 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 01 of 11 v3] xenbackendd: pass type of block
 device to hotplug script
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1317386335 -7200
# Node ID 23578c9942bcc8767adc4e435bb1fd1cd89f5e18
# Parent  fd3567cafe1c7ccd0ddba0ad7fb067d435e13529
xenbackendd: pass type of block device to hotplug script

Pass the type of block device to attach to the block script instead
of reading it from xenstore, since new Xen versions don't make a
difference between a block device or an image.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r fd3567cafe1c -r 23578c9942bc tools/hotplug/NetBSD/block
--- a/tools/hotplug/NetBSD/block	Tue Nov 15 14:50:18 2011 +0100
+++ b/tools/hotplug/NetBSD/block	Fri Sep 30 14:38:55 2011 +0200
@@ -19,7 +19,7 @@ error() {
 
 xpath=$1
 xstatus=$2
-xtype=$(xenstore-read "$xpath/type")
+xtype=$3
 xparams=$(xenstore-read "$xpath/params")
 
 case $xstatus in
diff -r fd3567cafe1c -r 23578c9942bc tools/xenbackendd/xenbackendd.c
--- a/tools/xenbackendd/xenbackendd.c	Tue Nov 15 14:50:18 2011 +0100
+++ b/tools/xenbackendd/xenbackendd.c	Fri Sep 30 14:38:55 2011 +0200
@@ -89,15 +89,15 @@ dodebug(const char *fmt, ...)
 }
 
 static void
-doexec(const char *cmd, const char *arg1, const char *arg2)
+doexec(const char *cmd, const char *arg1, const char *arg2, const char *arg3)
 {
-	dodebug("exec %s %s %s", cmd, arg1, arg2);
+	dodebug("exec %s %s %s %s", cmd, arg1, arg2, arg3);
 	switch(vfork()) {
 	case -1:
 		dolog(LOG_ERR, "can't vfork: %s", strerror(errno));
 		break;
 	case 0:
-		execl(cmd, cmd, arg1, arg2, NULL);
+		execl(cmd, cmd, arg1, arg2, arg3, NULL);
 		dolog(LOG_ERR, "can't exec %s: %s", cmd, strerror(errno));
 		exit(EXIT_FAILURE);
 		/* NOTREACHED */
@@ -145,11 +145,14 @@ xen_setup(void)
 int
 main(int argc, char * const argv[])
 {
+	struct stat stab;
 	char **vec;
 	unsigned int num;
 	char *s;
 	int state;
 	char *sstate;
+	char *stype;
+	char *params;
 	char *p;
 	char buf[80];
 	int type;
@@ -297,11 +300,38 @@ main(int argc, char * const argv[])
 				    strerror(errno));
 				goto next2;
 			}
-			doexec(s, vec[XS_WATCH_PATH], sstate);
+			doexec(s, vec[XS_WATCH_PATH], sstate, NULL);
 			break;
 
 		case DEVTYPE_VBD:
-			doexec(vbd_script, vec[XS_WATCH_PATH], sstate);
+			/* check if given file is a block device or a raw image */
+			snprintf(buf, sizeof(buf), "%s/params", vec[XS_WATCH_PATH]);
+			params = xs_read(xs, XBT_NULL, buf, 0);
+			if(params == NULL) {
+				dolog(LOG_ERR,
+					"Failed to read %s (%s)", buf, strerror(errno));
+				goto next2;
+			}
+			if (stat(params, &stab) < 0) {
+				dolog(LOG_ERR,
+					"Failed to get info about %s (%s)", params,
+					strerror(errno));
+				goto next3;
+			}
+			stype = NULL;
+			if (S_ISBLK(stab.st_mode))
+				stype = "phy";
+			if (S_ISREG(stab.st_mode))
+				stype = "file";
+			if (stype == NULL) {
+				dolog(LOG_ERR,
+					"Failed to attach %s (not a block device or raw image)",
+					params, strerror(errno));
+				goto next3;
+			}
+			doexec(vbd_script, vec[XS_WATCH_PATH], sstate, stype);
+next3:
+			free(params);
 			break;
 
 		default:

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 15:17:09 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 15:17:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW8Ng-0006Ft-5y; Thu, 01 Dec 2011 15:17:00 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RW8Ne-0006EU-Rx
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 15:16:59 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1322752574!4953754!2
X-Originating-IP: [209.85.214.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28827 invoked from network); 1 Dec 2011 15:16:18 -0000
Received: from mail-bw0-f43.google.com (HELO mail-bw0-f43.google.com)
	(209.85.214.43)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 15:16:18 -0000
Received: by mail-bw0-f43.google.com with SMTP id j4so2238541bkw.30
	for <xen-devel@lists.xensource.com>;
	Thu, 01 Dec 2011 07:16:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=itURchC/5YhjKfDyft4eXMO31gp/EgddIY+gXln155g=;
	b=lzGUl+A9SloUUrF+cV766NsFR1Tm9ALIRNnf39Mu9rZ5WUhQneT8jyWuq77zJc0/YB
	S/FvhHR1p5PyfH4rZBPR+4qgnIRNUDGlrsmb0m55IUntD951eEtK/9plx9oi9eretKWb
	CvavPnK/AS+eYkLSun5x+AAvS0E3WEQnbiSrs=
Received: by 10.205.121.1 with SMTP id ga1mr7874407bkc.60.1322752578012;
	Thu, 01 Dec 2011 07:16:18 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id c4sm11924270bkk.13.2011.12.01.07.16.14
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 01 Dec 2011 07:16:15 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 097287f09ef3fba4f1d61d7073a77a122f3c597a
Message-Id: <097287f09ef3fba4f1d6.1322752089@loki.upc.es>
In-Reply-To: <patchbomb.1322752087@loki.upc.es>
References: <patchbomb.1322752087@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Thu, 01 Dec 2011 16:08:09 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 02 of 11 v3] libxl: add support for image files
	for NetBSD
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1317386335 -7200
# Node ID 097287f09ef3fba4f1d61d7073a77a122f3c597a
# Parent  23578c9942bcc8767adc4e435bb1fd1cd89f5e18
libxl: add support for image files for NetBSD

Created a helper function to detect if the OS is capable of using
image files as phy backends. Create two OS specific files, and
changed the Makefile to choose the correct one at compile time.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 23578c9942bc -r 097287f09ef3 tools/libxl/Makefile
--- a/tools/libxl/Makefile	Fri Sep 30 14:38:55 2011 +0200
+++ b/tools/libxl/Makefile	Fri Sep 30 14:38:55 2011 +0200
@@ -32,6 +32,15 @@ endif
 LIBXL_OBJS-$(CONFIG_X86) += libxl_cpuid.o
 LIBXL_OBJS-$(CONFIG_IA64) += libxl_nocpuid.o
 
+ifeq ($(CONFIG_NetBSD),y)
+LIBXL_OBJS-y += libxl_netbsd.o
+else ifeq ($(CONFIG_Linux),y)
+LIBXL_OBJS-y += libxl_linux.o
+else
+$(error Your Operating System is not supported by libxenlight, \
+please check libxl_linux.c and libxl_netbsd.c to see how to get it ported)
+endif
+
 LIBXL_LIBS += -lyajl
 
 LIBXL_OBJS = flexarray.o libxl.o libxl_create.o libxl_dm.o libxl_pci.o \
diff -r 23578c9942bc -r 097287f09ef3 tools/libxl/libxl_device.c
--- a/tools/libxl/libxl_device.c	Fri Sep 30 14:38:55 2011 +0200
+++ b/tools/libxl/libxl_device.c	Fri Sep 30 14:38:55 2011 +0200
@@ -138,15 +138,14 @@ static int disk_try_backend(disk_try_bac
               a->disk->format == LIBXL_DISK_FORMAT_EMPTY)) {
             goto bad_format;
         }
-        if (a->disk->format != LIBXL_DISK_FORMAT_EMPTY &&
-            !S_ISBLK(a->stab.st_mode)) {
-            LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Disk vdev=%s, backend phy"
-                       " unsuitable as phys path not a block device",
-                       a->disk->vdev);
-            return 0;
-        }
 
-        return backend;
+        if (libxl__try_phy_backend(a->stab.st_mode))
+            return backend;
+
+        LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Disk vdev=%s, backend phy"
+                   " unsuitable as phys path not a block device",
+                   a->disk->vdev);
+        return 0;
 
     case LIBXL_DISK_BACKEND_TAP:
         if (!libxl__blktap_enabled(a->gc)) {
diff -r 23578c9942bc -r 097287f09ef3 tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Fri Sep 30 14:38:55 2011 +0200
+++ b/tools/libxl/libxl_internal.h	Fri Sep 30 14:38:55 2011 +0200
@@ -252,6 +252,15 @@ _hidden int libxl__device_destroy(libxl_
 _hidden int libxl__devices_destroy(libxl__gc *gc, uint32_t domid, int force);
 _hidden int libxl__wait_for_backend(libxl__gc *gc, char *be_path, char *state);
 
+/*
+ * libxl__try_phy_backend - Check if there's support for the passed
+ * type of file using the PHY backend
+ * st_mode: mode_t of the file, as returned by stat function
+ *
+ * Returns 0 on success, and < 0 on error.
+ */
+_hidden int libxl__try_phy_backend(mode_t st_mode);
+
 /* from libxl_pci */
 
 _hidden int libxl__device_pci_add(libxl__gc *gc, uint32_t domid, libxl_device_pci *pcidev, int starting);
diff -r 23578c9942bc -r 097287f09ef3 tools/libxl/libxl_linux.c
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/tools/libxl/libxl_linux.c	Fri Sep 30 14:38:55 2011 +0200
@@ -0,0 +1,27 @@
+/*
+ * Copyright (C) 2011
+ * Author Roger Pau Monne <roger.pau@entel.upc.edu>
+ *
+ * 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 <sys/stat.h>
+
+#include "libxl_internal.h"
+ 
+int libxl__try_phy_backend(mode_t st_mode)
+{
+    if (!S_ISBLK(st_mode)) {
+        return 0;
+    }
+
+    return 1;
+}
diff -r 23578c9942bc -r 097287f09ef3 tools/libxl/libxl_netbsd.c
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/tools/libxl/libxl_netbsd.c	Fri Sep 30 14:38:55 2011 +0200
@@ -0,0 +1,26 @@
+/*
+ * Copyright (C) 2011
+ * Author Roger Pau Monne <roger.pau@entel.upc.edu>
+ *
+ * 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 <sys/stat.h>
+
+#include "libxl_internal.h"
+
+int libxl__try_phy_backend(mode_t st_mode)
+{
+    if (S_ISREG(st_mode) || S_ISBLK(st_mode))
+        return 1;
+
+    return 0;
+}

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 15:17:09 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 15:17:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW8Ng-0006Ft-5y; Thu, 01 Dec 2011 15:17:00 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RW8Ne-0006EU-Rx
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 15:16:59 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1322752574!4953754!2
X-Originating-IP: [209.85.214.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28827 invoked from network); 1 Dec 2011 15:16:18 -0000
Received: from mail-bw0-f43.google.com (HELO mail-bw0-f43.google.com)
	(209.85.214.43)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 15:16:18 -0000
Received: by mail-bw0-f43.google.com with SMTP id j4so2238541bkw.30
	for <xen-devel@lists.xensource.com>;
	Thu, 01 Dec 2011 07:16:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=itURchC/5YhjKfDyft4eXMO31gp/EgddIY+gXln155g=;
	b=lzGUl+A9SloUUrF+cV766NsFR1Tm9ALIRNnf39Mu9rZ5WUhQneT8jyWuq77zJc0/YB
	S/FvhHR1p5PyfH4rZBPR+4qgnIRNUDGlrsmb0m55IUntD951eEtK/9plx9oi9eretKWb
	CvavPnK/AS+eYkLSun5x+AAvS0E3WEQnbiSrs=
Received: by 10.205.121.1 with SMTP id ga1mr7874407bkc.60.1322752578012;
	Thu, 01 Dec 2011 07:16:18 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id c4sm11924270bkk.13.2011.12.01.07.16.14
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 01 Dec 2011 07:16:15 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 097287f09ef3fba4f1d61d7073a77a122f3c597a
Message-Id: <097287f09ef3fba4f1d6.1322752089@loki.upc.es>
In-Reply-To: <patchbomb.1322752087@loki.upc.es>
References: <patchbomb.1322752087@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Thu, 01 Dec 2011 16:08:09 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 02 of 11 v3] libxl: add support for image files
	for NetBSD
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1317386335 -7200
# Node ID 097287f09ef3fba4f1d61d7073a77a122f3c597a
# Parent  23578c9942bcc8767adc4e435bb1fd1cd89f5e18
libxl: add support for image files for NetBSD

Created a helper function to detect if the OS is capable of using
image files as phy backends. Create two OS specific files, and
changed the Makefile to choose the correct one at compile time.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 23578c9942bc -r 097287f09ef3 tools/libxl/Makefile
--- a/tools/libxl/Makefile	Fri Sep 30 14:38:55 2011 +0200
+++ b/tools/libxl/Makefile	Fri Sep 30 14:38:55 2011 +0200
@@ -32,6 +32,15 @@ endif
 LIBXL_OBJS-$(CONFIG_X86) += libxl_cpuid.o
 LIBXL_OBJS-$(CONFIG_IA64) += libxl_nocpuid.o
 
+ifeq ($(CONFIG_NetBSD),y)
+LIBXL_OBJS-y += libxl_netbsd.o
+else ifeq ($(CONFIG_Linux),y)
+LIBXL_OBJS-y += libxl_linux.o
+else
+$(error Your Operating System is not supported by libxenlight, \
+please check libxl_linux.c and libxl_netbsd.c to see how to get it ported)
+endif
+
 LIBXL_LIBS += -lyajl
 
 LIBXL_OBJS = flexarray.o libxl.o libxl_create.o libxl_dm.o libxl_pci.o \
diff -r 23578c9942bc -r 097287f09ef3 tools/libxl/libxl_device.c
--- a/tools/libxl/libxl_device.c	Fri Sep 30 14:38:55 2011 +0200
+++ b/tools/libxl/libxl_device.c	Fri Sep 30 14:38:55 2011 +0200
@@ -138,15 +138,14 @@ static int disk_try_backend(disk_try_bac
               a->disk->format == LIBXL_DISK_FORMAT_EMPTY)) {
             goto bad_format;
         }
-        if (a->disk->format != LIBXL_DISK_FORMAT_EMPTY &&
-            !S_ISBLK(a->stab.st_mode)) {
-            LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Disk vdev=%s, backend phy"
-                       " unsuitable as phys path not a block device",
-                       a->disk->vdev);
-            return 0;
-        }
 
-        return backend;
+        if (libxl__try_phy_backend(a->stab.st_mode))
+            return backend;
+
+        LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Disk vdev=%s, backend phy"
+                   " unsuitable as phys path not a block device",
+                   a->disk->vdev);
+        return 0;
 
     case LIBXL_DISK_BACKEND_TAP:
         if (!libxl__blktap_enabled(a->gc)) {
diff -r 23578c9942bc -r 097287f09ef3 tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Fri Sep 30 14:38:55 2011 +0200
+++ b/tools/libxl/libxl_internal.h	Fri Sep 30 14:38:55 2011 +0200
@@ -252,6 +252,15 @@ _hidden int libxl__device_destroy(libxl_
 _hidden int libxl__devices_destroy(libxl__gc *gc, uint32_t domid, int force);
 _hidden int libxl__wait_for_backend(libxl__gc *gc, char *be_path, char *state);
 
+/*
+ * libxl__try_phy_backend - Check if there's support for the passed
+ * type of file using the PHY backend
+ * st_mode: mode_t of the file, as returned by stat function
+ *
+ * Returns 0 on success, and < 0 on error.
+ */
+_hidden int libxl__try_phy_backend(mode_t st_mode);
+
 /* from libxl_pci */
 
 _hidden int libxl__device_pci_add(libxl__gc *gc, uint32_t domid, libxl_device_pci *pcidev, int starting);
diff -r 23578c9942bc -r 097287f09ef3 tools/libxl/libxl_linux.c
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/tools/libxl/libxl_linux.c	Fri Sep 30 14:38:55 2011 +0200
@@ -0,0 +1,27 @@
+/*
+ * Copyright (C) 2011
+ * Author Roger Pau Monne <roger.pau@entel.upc.edu>
+ *
+ * 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 <sys/stat.h>
+
+#include "libxl_internal.h"
+ 
+int libxl__try_phy_backend(mode_t st_mode)
+{
+    if (!S_ISBLK(st_mode)) {
+        return 0;
+    }
+
+    return 1;
+}
diff -r 23578c9942bc -r 097287f09ef3 tools/libxl/libxl_netbsd.c
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/tools/libxl/libxl_netbsd.c	Fri Sep 30 14:38:55 2011 +0200
@@ -0,0 +1,26 @@
+/*
+ * Copyright (C) 2011
+ * Author Roger Pau Monne <roger.pau@entel.upc.edu>
+ *
+ * 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 <sys/stat.h>
+
+#include "libxl_internal.h"
+
+int libxl__try_phy_backend(mode_t st_mode)
+{
+    if (S_ISREG(st_mode) || S_ISBLK(st_mode))
+        return 1;
+
+    return 0;
+}

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 15:17:10 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 15:17:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW8Ni-0006Gi-Li; Thu, 01 Dec 2011 15:17:02 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RW8Ng-0006Ey-VC
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 15:17:01 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1322752574!4953754!3
X-Originating-IP: [209.85.214.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28938 invoked from network); 1 Dec 2011 15:16:20 -0000
Received: from mail-bw0-f43.google.com (HELO mail-bw0-f43.google.com)
	(209.85.214.43)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 15:16:20 -0000
Received: by mail-bw0-f43.google.com with SMTP id j4so2238541bkw.30
	for <xen-devel@lists.xensource.com>;
	Thu, 01 Dec 2011 07:16:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=TtCTCDN8e3mGtGCekWe+37qg3svl4nb9wBI1f5TziAU=;
	b=xOPTYwmnhB+f+XqTEFyfGh8Wn9aqz1rdGy/wb8nGoWFbOGIk0DfPqzWrIu7JkOlQhy
	kI44zX1HCI+fpA/jutm1/qau8g91w3lp2MbPhzS3kyKRyOulDPkxvbFU9kEwBC8nTxys
	KxJFCG0jvIY1GlBSiI7YOtG2pySUtbpriHYsI=
Received: by 10.205.128.19 with SMTP id hc19mr8031382bkc.9.1322752580734;
	Thu, 01 Dec 2011 07:16:20 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id c4sm11924270bkk.13.2011.12.01.07.16.18
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 01 Dec 2011 07:16:19 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 0abd9540788822b58585c8f2d29571e63fb68865
Message-Id: <0abd9540788822b58585.1322752090@loki.upc.es>
In-Reply-To: <patchbomb.1322752087@loki.upc.es>
References: <patchbomb.1322752087@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Thu, 01 Dec 2011 16:08:10 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 03 of 11 v3] libxl: add libxl__forkexec function
	to libxl_exec
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1322751677 -3600
# Node ID 0abd9540788822b58585c8f2d29571e63fb68865
# Parent  097287f09ef3fba4f1d61d7073a77a122f3c597a
libxl: add libxl__forkexec function to libxl_exec

Add a new function to libxl_exec that performs a fork and executes
the passed arguments using libxl__exec.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 097287f09ef3 -r 0abd95407888 tools/libxl/libxl_exec.c
--- a/tools/libxl/libxl_exec.c	Fri Sep 30 14:38:55 2011 +0200
+++ b/tools/libxl/libxl_exec.c	Thu Dec 01 16:01:17 2011 +0100
@@ -450,6 +450,39 @@ int libxl__spawn_check(libxl__gc *gc, li
     return ERROR_FAIL;
 }
 
+int libxl__forkexec(libxl__gc *gc, int stdinfd, int stdoutfd,
+                    int stderrfd, char **args)
+{
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+    int status;
+    int rc = 0;
+    pid_t pid = fork();
+
+    switch (pid) {
+    case -1:
+        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "fork failed\n");
+        rc = -1;
+        break;
+    case 0:
+        libxl__exec(stdinfd, stdoutfd, stderrfd, args[0], args);
+        /* libxl__exec never returns */
+    default:
+        while (waitpid(pid, &status, 0) < 0) {
+            if (errno != EINTR) {
+                LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "waitpid failed\n");
+                rc = -1;
+                break;
+            }
+        }
+        if (status)
+            libxl_report_child_exitstatus(ctx, LIBXL__LOG_ERROR,
+                                          args[0], pid, status);
+        rc = status;
+        break;
+    }
+    return rc;
+}
+
 /*
  * Local variables:
  * mode: C
diff -r 097287f09ef3 -r 0abd95407888 tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Fri Sep 30 14:38:55 2011 +0200
+++ b/tools/libxl/libxl_internal.h	Thu Dec 01 16:01:17 2011 +0100
@@ -400,6 +400,22 @@ _hidden int libxl__spawn_check(libxl__gc
 _hidden void libxl__exec(int stdinfd, int stdoutfd, int stderrfd,
                const char *arg0, char **args); // logs errors, never returns
 
+/*
+ * libxl__forkexec - Executes a file synchronously
+ * gc: allocation pool
+ * stdinfd, stdoutfd, stderrfd: fds to pass to libxl__exec
+ * args: file to execute and arguments to pass in the following format
+ *      args[0]: file to execute
+ *      args[1]: first argument to pass to the called program
+ *      ...
+ *      args[n-1]: (n-1)th argument to pass to the called program
+ *      args[n]: NULL
+ *
+ * Returns the exit status, as reported by waitpid.
+ */
+_hidden int libxl__forkexec(libxl__gc *gc, int stdinfd, int stdoutfd,
+                            int stderrfd, char **args);
+
 /* from xl_create */
 _hidden int libxl__domain_make(libxl__gc *gc, libxl_domain_create_info *info, uint32_t *domid);
 _hidden int libxl__domain_build(libxl__gc *gc,

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 15:17:10 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 15:17:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW8Ni-0006Gi-Li; Thu, 01 Dec 2011 15:17:02 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RW8Ng-0006Ey-VC
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 15:17:01 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1322752574!4953754!3
X-Originating-IP: [209.85.214.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28938 invoked from network); 1 Dec 2011 15:16:20 -0000
Received: from mail-bw0-f43.google.com (HELO mail-bw0-f43.google.com)
	(209.85.214.43)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 15:16:20 -0000
Received: by mail-bw0-f43.google.com with SMTP id j4so2238541bkw.30
	for <xen-devel@lists.xensource.com>;
	Thu, 01 Dec 2011 07:16:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=TtCTCDN8e3mGtGCekWe+37qg3svl4nb9wBI1f5TziAU=;
	b=xOPTYwmnhB+f+XqTEFyfGh8Wn9aqz1rdGy/wb8nGoWFbOGIk0DfPqzWrIu7JkOlQhy
	kI44zX1HCI+fpA/jutm1/qau8g91w3lp2MbPhzS3kyKRyOulDPkxvbFU9kEwBC8nTxys
	KxJFCG0jvIY1GlBSiI7YOtG2pySUtbpriHYsI=
Received: by 10.205.128.19 with SMTP id hc19mr8031382bkc.9.1322752580734;
	Thu, 01 Dec 2011 07:16:20 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id c4sm11924270bkk.13.2011.12.01.07.16.18
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 01 Dec 2011 07:16:19 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 0abd9540788822b58585c8f2d29571e63fb68865
Message-Id: <0abd9540788822b58585.1322752090@loki.upc.es>
In-Reply-To: <patchbomb.1322752087@loki.upc.es>
References: <patchbomb.1322752087@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Thu, 01 Dec 2011 16:08:10 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 03 of 11 v3] libxl: add libxl__forkexec function
	to libxl_exec
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1322751677 -3600
# Node ID 0abd9540788822b58585c8f2d29571e63fb68865
# Parent  097287f09ef3fba4f1d61d7073a77a122f3c597a
libxl: add libxl__forkexec function to libxl_exec

Add a new function to libxl_exec that performs a fork and executes
the passed arguments using libxl__exec.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 097287f09ef3 -r 0abd95407888 tools/libxl/libxl_exec.c
--- a/tools/libxl/libxl_exec.c	Fri Sep 30 14:38:55 2011 +0200
+++ b/tools/libxl/libxl_exec.c	Thu Dec 01 16:01:17 2011 +0100
@@ -450,6 +450,39 @@ int libxl__spawn_check(libxl__gc *gc, li
     return ERROR_FAIL;
 }
 
+int libxl__forkexec(libxl__gc *gc, int stdinfd, int stdoutfd,
+                    int stderrfd, char **args)
+{
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+    int status;
+    int rc = 0;
+    pid_t pid = fork();
+
+    switch (pid) {
+    case -1:
+        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "fork failed\n");
+        rc = -1;
+        break;
+    case 0:
+        libxl__exec(stdinfd, stdoutfd, stderrfd, args[0], args);
+        /* libxl__exec never returns */
+    default:
+        while (waitpid(pid, &status, 0) < 0) {
+            if (errno != EINTR) {
+                LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "waitpid failed\n");
+                rc = -1;
+                break;
+            }
+        }
+        if (status)
+            libxl_report_child_exitstatus(ctx, LIBXL__LOG_ERROR,
+                                          args[0], pid, status);
+        rc = status;
+        break;
+    }
+    return rc;
+}
+
 /*
  * Local variables:
  * mode: C
diff -r 097287f09ef3 -r 0abd95407888 tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Fri Sep 30 14:38:55 2011 +0200
+++ b/tools/libxl/libxl_internal.h	Thu Dec 01 16:01:17 2011 +0100
@@ -400,6 +400,22 @@ _hidden int libxl__spawn_check(libxl__gc
 _hidden void libxl__exec(int stdinfd, int stdoutfd, int stderrfd,
                const char *arg0, char **args); // logs errors, never returns
 
+/*
+ * libxl__forkexec - Executes a file synchronously
+ * gc: allocation pool
+ * stdinfd, stdoutfd, stderrfd: fds to pass to libxl__exec
+ * args: file to execute and arguments to pass in the following format
+ *      args[0]: file to execute
+ *      args[1]: first argument to pass to the called program
+ *      ...
+ *      args[n-1]: (n-1)th argument to pass to the called program
+ *      args[n]: NULL
+ *
+ * Returns the exit status, as reported by waitpid.
+ */
+_hidden int libxl__forkexec(libxl__gc *gc, int stdinfd, int stdoutfd,
+                            int stderrfd, char **args);
+
 /* from xl_create */
 _hidden int libxl__domain_make(libxl__gc *gc, libxl_domain_create_info *info, uint32_t *domid);
 _hidden int libxl__domain_build(libxl__gc *gc,

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 15:17:11 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 15: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.xensource.com>)
	id 1RW8Nl-0006I8-7O; Thu, 01 Dec 2011 15:17:05 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RW8Nk-0006FV-62
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 15:17:04 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1322752583!5489632!1
X-Originating-IP: [209.85.161.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22726 invoked from network); 1 Dec 2011 15:16:24 -0000
Received: from mail-fx0-f43.google.com (HELO mail-fx0-f43.google.com)
	(209.85.161.43)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 15:16:24 -0000
Received: by fagn18 with SMTP id n18so2607398fag.30
	for <xen-devel@lists.xensource.com>;
	Thu, 01 Dec 2011 07:16:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=jYvnfaikUnwm7ETkYisJzP3a5PZL/HEtHPkke/azVGY=;
	b=WuuozD0RqVwYXc+MXTJB2uNTEPUVy5B6/3DJ+aBycSmKdgLZxD8y8JoPGwNYuLNUPW
	oS7A06mhW1zkA7KbGlmhDfKRR+g6xx8S6pKfSTol+hxPTsxR8yOFWkPVLVGzoHhQawTP
	ruvOCfTg5mAyax9L+CmW4Rvsez7XuPQe3rqaQ=
Received: by 10.204.148.145 with SMTP id p17mr7682742bkv.61.1322752583569;
	Thu, 01 Dec 2011 07:16:23 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id c4sm11924270bkk.13.2011.12.01.07.16.20
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 01 Dec 2011 07:16:21 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 3b5b14fcd208e7c5cb1840ea76eb11a63958a030
Message-Id: <3b5b14fcd208e7c5cb18.1322752091@loki.upc.es>
In-Reply-To: <patchbomb.1322752087@loki.upc.es>
References: <patchbomb.1322752087@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Thu, 01 Dec 2011 16:08:11 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 04 of 11 v3] libxl: introduce
	libxl__wait_for_device_state
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1322751691 -3600
# Node ID 3b5b14fcd208e7c5cb1840ea76eb11a63958a030
# Parent  0abd9540788822b58585c8f2d29571e63fb68865
libxl: introduce libxl__wait_for_device_state

This is a generic function, that waits for xs watches to reach a
certain state and then executes the passed helper function. Removed
wait_for_dev_destroy and used this new function instead. This
function will also be used by future patches that need to wait for
the initialization of devices before executing hotplug scripts.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 0abd95407888 -r 3b5b14fcd208 tools/libxl/libxl_device.c
--- a/tools/libxl/libxl_device.c	Thu Dec 01 16:01:17 2011 +0100
+++ b/tools/libxl/libxl_device.c	Thu Dec 01 16:01:31 2011 +0100
@@ -370,7 +370,9 @@ int libxl__device_disk_dev_number(const 
  * Returns 0 if a device is removed, ERROR_* if an error
  * or timeout occurred.
  */
-static int wait_for_dev_destroy(libxl__gc *gc, struct timeval *tv)
+int libxl__wait_for_device_state(libxl__gc *gc, struct timeval *tv,
+                                 XenbusState state,
+                                 libxl__device_state_handler handler)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
     int nfds, rc;
@@ -395,17 +397,14 @@ start:
         default:
             l1 = xs_read_watch(ctx->xsh, &n);
             if (l1 != NULL) {
-                char *state = libxl__xs_read(gc, XBT_NULL,
+                char *sstate = libxl__xs_read(gc, XBT_NULL,
                                              l1[XS_WATCH_PATH]);
-                if (!state || atoi(state) == 6) {
-                    xs_unwatch(ctx->xsh, l1[0], l1[1]);
-                    xs_rm(ctx->xsh, XBT_NULL, l1[XS_WATCH_TOKEN]);
-                    LIBXL__LOG(ctx, LIBXL__LOG_DEBUG,
-                               "Destroyed device backend at %s",
-                               l1[XS_WATCH_TOKEN]);
-                    rc = 0;
+                if (!sstate || atoi(sstate) == state) {
+                    /* Call handler function if present */
+                    if (handler)
+                        rc = handler(gc, l1, sstate);
                 } else {
-                    /* State is not "disconnected", continue waiting... */
+                    /* State is different than expected, continue waiting... */
                     goto start;
                 }
                 free(l1);
@@ -418,6 +417,23 @@ start:
 }
 
 /*
+ * Handler function for device destruction to be passed to
+ * libxl__wait_for_device_state
+ */
+static int destroy_device(libxl__gc *gc, char **l1, char *state)
+{
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+
+    xs_unwatch(ctx->xsh, l1[0], l1[1]);
+    xs_rm(ctx->xsh, XBT_NULL, l1[XS_WATCH_TOKEN]);
+    LIBXL__LOG(ctx, LIBXL__LOG_DEBUG,
+               "Destroyed device backend at %s",
+               l1[XS_WATCH_TOKEN]);
+
+    return 0;
+}
+
+/*
  * Returns 0 (device already destroyed) or 1 (caller must
  * wait_for_dev_destroy) on success, ERROR_* on fail.
  */
@@ -458,7 +474,8 @@ retry_transaction:
         struct timeval tv;
         tv.tv_sec = LIBXL_DESTROY_TIMEOUT;
         tv.tv_usec = 0;
-        rc = wait_for_dev_destroy(gc, &tv);
+        rc = libxl__wait_for_device_state(gc, &tv, XenbusStateClosed,
+                                          destroy_device);
         if (rc < 0) /* an error or timeout occurred, clear watches */
             xs_unwatch(ctx->xsh, state_path, be_path);
         xs_rm(ctx->xsh, XBT_NULL, libxl__device_frontend_path(gc, dev));
@@ -566,7 +583,8 @@ int libxl__devices_destroy(libxl__gc *gc
         tv.tv_sec = LIBXL_DESTROY_TIMEOUT;
         tv.tv_usec = 0;
         while (n_watches > 0) {
-            if (wait_for_dev_destroy(gc, &tv) < 0) {
+            if (libxl__wait_for_device_state(gc, &tv, XenbusStateClosed,
+                                             destroy_device) < 0) {
                 /* function returned ERROR_* */
                 break;
             } else {
diff -r 0abd95407888 -r 3b5b14fcd208 tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Thu Dec 01 16:01:17 2011 +0100
+++ b/tools/libxl/libxl_internal.h	Thu Dec 01 16:01:31 2011 +0100
@@ -20,11 +20,14 @@
 #include <stdint.h>
 #include <stdarg.h>
 #include <stdlib.h>
+#include <sys/time.h>
 
 #include <xs.h>
 #include <xenctrl.h>
 #include "xentoollog.h"
 
+#include <xen/io/xenbus.h>
+
 #if __GNUC__ > 3 || (__GNUC__ == 3 && __GNUC_MINOR__ >= 1)
 #define _hidden __attribute__((visibility("hidden")))
 #define _protected __attribute__((visibility("protected")))
@@ -252,6 +255,31 @@ _hidden int libxl__device_destroy(libxl_
 _hidden int libxl__devices_destroy(libxl__gc *gc, uint32_t domid, int force);
 _hidden int libxl__wait_for_backend(libxl__gc *gc, char *be_path, char *state);
 
+/* Handler for the libxl__wait_for_device_state callback */
+/*
+ * libxl__device_state_handler - Handler for the libxl__wait_for_device_state
+ * gc: allocation pool
+ * l1: array containing the path and token
+ * state: string that contains the state of the device
+ *
+ * Returns 0 on success, and < 0 on error.
+ */
+typedef int libxl__device_state_handler(libxl__gc *gc, char **l1, char *state);
+
+/*
+ * libxl__wait_for_device_state - waits a given time for a device to
+ * reach a given state
+ * gc: allocation pool
+ * tv: timeval struct containing the maximum time to wait
+ * state: state to wait for (check xen/io/xenbus.h)
+ * handler: callback function to execute when state is reached
+ *
+ * Returns 0 on success, and < 0 on error.
+ */
+_hidden int libxl__wait_for_device_state(libxl__gc *gc, struct timeval *tv,
+                                         XenbusState state,
+                                         libxl__device_state_handler handler);
+
 /*
  * libxl__try_phy_backend - Check if there's support for the passed
  * type of file using the PHY backend

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 15:17:11 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 15: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.xensource.com>)
	id 1RW8Nl-0006I8-7O; Thu, 01 Dec 2011 15:17:05 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RW8Nk-0006FV-62
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 15:17:04 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1322752583!5489632!1
X-Originating-IP: [209.85.161.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22726 invoked from network); 1 Dec 2011 15:16:24 -0000
Received: from mail-fx0-f43.google.com (HELO mail-fx0-f43.google.com)
	(209.85.161.43)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 15:16:24 -0000
Received: by fagn18 with SMTP id n18so2607398fag.30
	for <xen-devel@lists.xensource.com>;
	Thu, 01 Dec 2011 07:16:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=jYvnfaikUnwm7ETkYisJzP3a5PZL/HEtHPkke/azVGY=;
	b=WuuozD0RqVwYXc+MXTJB2uNTEPUVy5B6/3DJ+aBycSmKdgLZxD8y8JoPGwNYuLNUPW
	oS7A06mhW1zkA7KbGlmhDfKRR+g6xx8S6pKfSTol+hxPTsxR8yOFWkPVLVGzoHhQawTP
	ruvOCfTg5mAyax9L+CmW4Rvsez7XuPQe3rqaQ=
Received: by 10.204.148.145 with SMTP id p17mr7682742bkv.61.1322752583569;
	Thu, 01 Dec 2011 07:16:23 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id c4sm11924270bkk.13.2011.12.01.07.16.20
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 01 Dec 2011 07:16:21 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 3b5b14fcd208e7c5cb1840ea76eb11a63958a030
Message-Id: <3b5b14fcd208e7c5cb18.1322752091@loki.upc.es>
In-Reply-To: <patchbomb.1322752087@loki.upc.es>
References: <patchbomb.1322752087@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Thu, 01 Dec 2011 16:08:11 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 04 of 11 v3] libxl: introduce
	libxl__wait_for_device_state
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1322751691 -3600
# Node ID 3b5b14fcd208e7c5cb1840ea76eb11a63958a030
# Parent  0abd9540788822b58585c8f2d29571e63fb68865
libxl: introduce libxl__wait_for_device_state

This is a generic function, that waits for xs watches to reach a
certain state and then executes the passed helper function. Removed
wait_for_dev_destroy and used this new function instead. This
function will also be used by future patches that need to wait for
the initialization of devices before executing hotplug scripts.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 0abd95407888 -r 3b5b14fcd208 tools/libxl/libxl_device.c
--- a/tools/libxl/libxl_device.c	Thu Dec 01 16:01:17 2011 +0100
+++ b/tools/libxl/libxl_device.c	Thu Dec 01 16:01:31 2011 +0100
@@ -370,7 +370,9 @@ int libxl__device_disk_dev_number(const 
  * Returns 0 if a device is removed, ERROR_* if an error
  * or timeout occurred.
  */
-static int wait_for_dev_destroy(libxl__gc *gc, struct timeval *tv)
+int libxl__wait_for_device_state(libxl__gc *gc, struct timeval *tv,
+                                 XenbusState state,
+                                 libxl__device_state_handler handler)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
     int nfds, rc;
@@ -395,17 +397,14 @@ start:
         default:
             l1 = xs_read_watch(ctx->xsh, &n);
             if (l1 != NULL) {
-                char *state = libxl__xs_read(gc, XBT_NULL,
+                char *sstate = libxl__xs_read(gc, XBT_NULL,
                                              l1[XS_WATCH_PATH]);
-                if (!state || atoi(state) == 6) {
-                    xs_unwatch(ctx->xsh, l1[0], l1[1]);
-                    xs_rm(ctx->xsh, XBT_NULL, l1[XS_WATCH_TOKEN]);
-                    LIBXL__LOG(ctx, LIBXL__LOG_DEBUG,
-                               "Destroyed device backend at %s",
-                               l1[XS_WATCH_TOKEN]);
-                    rc = 0;
+                if (!sstate || atoi(sstate) == state) {
+                    /* Call handler function if present */
+                    if (handler)
+                        rc = handler(gc, l1, sstate);
                 } else {
-                    /* State is not "disconnected", continue waiting... */
+                    /* State is different than expected, continue waiting... */
                     goto start;
                 }
                 free(l1);
@@ -418,6 +417,23 @@ start:
 }
 
 /*
+ * Handler function for device destruction to be passed to
+ * libxl__wait_for_device_state
+ */
+static int destroy_device(libxl__gc *gc, char **l1, char *state)
+{
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+
+    xs_unwatch(ctx->xsh, l1[0], l1[1]);
+    xs_rm(ctx->xsh, XBT_NULL, l1[XS_WATCH_TOKEN]);
+    LIBXL__LOG(ctx, LIBXL__LOG_DEBUG,
+               "Destroyed device backend at %s",
+               l1[XS_WATCH_TOKEN]);
+
+    return 0;
+}
+
+/*
  * Returns 0 (device already destroyed) or 1 (caller must
  * wait_for_dev_destroy) on success, ERROR_* on fail.
  */
@@ -458,7 +474,8 @@ retry_transaction:
         struct timeval tv;
         tv.tv_sec = LIBXL_DESTROY_TIMEOUT;
         tv.tv_usec = 0;
-        rc = wait_for_dev_destroy(gc, &tv);
+        rc = libxl__wait_for_device_state(gc, &tv, XenbusStateClosed,
+                                          destroy_device);
         if (rc < 0) /* an error or timeout occurred, clear watches */
             xs_unwatch(ctx->xsh, state_path, be_path);
         xs_rm(ctx->xsh, XBT_NULL, libxl__device_frontend_path(gc, dev));
@@ -566,7 +583,8 @@ int libxl__devices_destroy(libxl__gc *gc
         tv.tv_sec = LIBXL_DESTROY_TIMEOUT;
         tv.tv_usec = 0;
         while (n_watches > 0) {
-            if (wait_for_dev_destroy(gc, &tv) < 0) {
+            if (libxl__wait_for_device_state(gc, &tv, XenbusStateClosed,
+                                             destroy_device) < 0) {
                 /* function returned ERROR_* */
                 break;
             } else {
diff -r 0abd95407888 -r 3b5b14fcd208 tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Thu Dec 01 16:01:17 2011 +0100
+++ b/tools/libxl/libxl_internal.h	Thu Dec 01 16:01:31 2011 +0100
@@ -20,11 +20,14 @@
 #include <stdint.h>
 #include <stdarg.h>
 #include <stdlib.h>
+#include <sys/time.h>
 
 #include <xs.h>
 #include <xenctrl.h>
 #include "xentoollog.h"
 
+#include <xen/io/xenbus.h>
+
 #if __GNUC__ > 3 || (__GNUC__ == 3 && __GNUC_MINOR__ >= 1)
 #define _hidden __attribute__((visibility("hidden")))
 #define _protected __attribute__((visibility("protected")))
@@ -252,6 +255,31 @@ _hidden int libxl__device_destroy(libxl_
 _hidden int libxl__devices_destroy(libxl__gc *gc, uint32_t domid, int force);
 _hidden int libxl__wait_for_backend(libxl__gc *gc, char *be_path, char *state);
 
+/* Handler for the libxl__wait_for_device_state callback */
+/*
+ * libxl__device_state_handler - Handler for the libxl__wait_for_device_state
+ * gc: allocation pool
+ * l1: array containing the path and token
+ * state: string that contains the state of the device
+ *
+ * Returns 0 on success, and < 0 on error.
+ */
+typedef int libxl__device_state_handler(libxl__gc *gc, char **l1, char *state);
+
+/*
+ * libxl__wait_for_device_state - waits a given time for a device to
+ * reach a given state
+ * gc: allocation pool
+ * tv: timeval struct containing the maximum time to wait
+ * state: state to wait for (check xen/io/xenbus.h)
+ * handler: callback function to execute when state is reached
+ *
+ * Returns 0 on success, and < 0 on error.
+ */
+_hidden int libxl__wait_for_device_state(libxl__gc *gc, struct timeval *tv,
+                                         XenbusState state,
+                                         libxl__device_state_handler handler);
+
 /*
  * libxl__try_phy_backend - Check if there's support for the passed
  * type of file using the PHY backend

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 15:17:11 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 15: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.xensource.com>)
	id 1RW8Nn-0006JN-Ky; Thu, 01 Dec 2011 15:17:07 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RW8Nl-0006G5-R0
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 15:17:06 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1322752574!4953754!4
X-Originating-IP: [209.85.214.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29279 invoked from network); 1 Dec 2011 15:16:25 -0000
Received: from mail-bw0-f43.google.com (HELO mail-bw0-f43.google.com)
	(209.85.214.43)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 15:16:25 -0000
Received: by mail-bw0-f43.google.com with SMTP id j4so2238541bkw.30
	for <xen-devel@lists.xensource.com>;
	Thu, 01 Dec 2011 07:16:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=aAzW1sR9Vji7J30H0f8nxTcczZj16YlZkoJw/JX4bz0=;
	b=ayy9xHMBaPbEFXSxej8iXsJ5N/ALQhWimoYQb+GlGNhxiy58GQAdRmLTyeygTYhSQw
	irUizjO/mukV/8lIZFJ6P09AKSbAKY7DdKG5jxLG9HDD5cnr7nTeP6AkkcRY1OhQAq8H
	1xKdaT2buGoCVq0KzOvMe3ZlStm+auGWX5QZ8=
Received: by 10.205.123.3 with SMTP id gi3mr8024740bkc.112.1322752585846;
	Thu, 01 Dec 2011 07:16:25 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id c4sm11924270bkk.13.2011.12.01.07.16.23
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 01 Dec 2011 07:16:24 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: e5128830bc1e13adbf0b07962821fe8b13ba93b8
Message-Id: <e5128830bc1e13adbf0b.1322752092@loki.upc.es>
In-Reply-To: <patchbomb.1322752087@loki.upc.es>
References: <patchbomb.1322752087@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Thu, 01 Dec 2011 16:08:12 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 05 of 11 v3] libxl: wait for devices to
 initialize upon addition to the domain
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1322751691 -3600
# Node ID e5128830bc1e13adbf0b07962821fe8b13ba93b8
# Parent  3b5b14fcd208e7c5cb1840ea76eb11a63958a030
libxl: wait for devices to initialize upon addition to the domain.

Block waiting for devices to initialize (switch to state 2). This is
necessary because we need to call the hotplug scripts when state is
2, otherwise the execution fails. Make use of the newly introduced
function libxl__wait_for_device_state.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 3b5b14fcd208 -r e5128830bc1e tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Thu Dec 01 16:01:31 2011 +0100
+++ b/tools/libxl/libxl.c	Thu Dec 01 16:01:31 2011 +0100
@@ -971,6 +971,8 @@ int libxl_device_disk_add(libxl_ctx *ctx
     flexarray_t *front;
     flexarray_t *back;
     char *dev;
+    char *be_path, *state_path, *state;
+    struct timeval tv;
     libxl__device device;
     int major, minor, rc;
 
@@ -1075,6 +1077,23 @@ int libxl_device_disk_add(libxl_ctx *ctx
                              libxl__xs_kvs_of_flexarray(&gc, back, back->count),
                              libxl__xs_kvs_of_flexarray(&gc, front, front->count));
 
+    be_path = libxl__device_backend_path(&gc, &device);
+    state_path = libxl__sprintf(&gc, "%s/state", be_path);
+    state = libxl__xs_read(&gc, XBT_NULL, state_path);
+
+    if (atoi(state) != XenbusStateInitWait) {
+        xs_watch(ctx->xsh, state_path, be_path);
+        tv.tv_sec = LIBXL_DESTROY_TIMEOUT;
+        tv.tv_usec = 0;
+        rc = libxl__wait_for_device_state(&gc, &tv, XenbusStateInitWait, NULL);
+        xs_unwatch(ctx->xsh, state_path, be_path);
+        if (rc < 0) {
+            LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
+                       "unable to initialize disk device: %s\n",
+                       disk->pdev_path);
+            goto out_free;
+        }
+    }
     rc = 0;
 
 out_free:
@@ -1450,6 +1469,8 @@ int libxl_device_nic_add(libxl_ctx *ctx,
     flexarray_t *back;
     libxl__device device;
     char *dompath, **l;
+    char *be_path, *state_path, *state;
+    struct timeval tv;
     unsigned int nb, rc;
 
     front = flexarray_make(16, 1);
@@ -1518,8 +1539,25 @@ int libxl_device_nic_add(libxl_ctx *ctx,
                              libxl__xs_kvs_of_flexarray(&gc, back, back->count),
                              libxl__xs_kvs_of_flexarray(&gc, front, front->count));
 
-    /* FIXME: wait for plug */
+    be_path = libxl__device_backend_path(&gc, &device);
+    state_path = libxl__sprintf(&gc, "%s/state", be_path);
+    state = libxl__xs_read(&gc, XBT_NULL, state_path);
+
+    if (atoi(state) != XenbusStateInitWait) {
+        xs_watch(ctx->xsh, state_path, be_path);
+        tv.tv_sec = LIBXL_DESTROY_TIMEOUT;
+        tv.tv_usec = 0;
+        rc = libxl__wait_for_device_state(&gc, &tv, XenbusStateInitWait, NULL);
+        xs_unwatch(ctx->xsh, state_path, be_path);
+        if (rc < 0) {
+            LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
+                       "unable to initialize nic device: %s\n",
+                       nic->ifname);
+            goto out_free;
+        }
+    }
     rc = 0;
+
 out_free:
     flexarray_free(back);
     flexarray_free(front);

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 15:17:11 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 15: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.xensource.com>)
	id 1RW8Nn-0006JN-Ky; Thu, 01 Dec 2011 15:17:07 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RW8Nl-0006G5-R0
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 15:17:06 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1322752574!4953754!4
X-Originating-IP: [209.85.214.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29279 invoked from network); 1 Dec 2011 15:16:25 -0000
Received: from mail-bw0-f43.google.com (HELO mail-bw0-f43.google.com)
	(209.85.214.43)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 15:16:25 -0000
Received: by mail-bw0-f43.google.com with SMTP id j4so2238541bkw.30
	for <xen-devel@lists.xensource.com>;
	Thu, 01 Dec 2011 07:16:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=aAzW1sR9Vji7J30H0f8nxTcczZj16YlZkoJw/JX4bz0=;
	b=ayy9xHMBaPbEFXSxej8iXsJ5N/ALQhWimoYQb+GlGNhxiy58GQAdRmLTyeygTYhSQw
	irUizjO/mukV/8lIZFJ6P09AKSbAKY7DdKG5jxLG9HDD5cnr7nTeP6AkkcRY1OhQAq8H
	1xKdaT2buGoCVq0KzOvMe3ZlStm+auGWX5QZ8=
Received: by 10.205.123.3 with SMTP id gi3mr8024740bkc.112.1322752585846;
	Thu, 01 Dec 2011 07:16:25 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id c4sm11924270bkk.13.2011.12.01.07.16.23
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 01 Dec 2011 07:16:24 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: e5128830bc1e13adbf0b07962821fe8b13ba93b8
Message-Id: <e5128830bc1e13adbf0b.1322752092@loki.upc.es>
In-Reply-To: <patchbomb.1322752087@loki.upc.es>
References: <patchbomb.1322752087@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Thu, 01 Dec 2011 16:08:12 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 05 of 11 v3] libxl: wait for devices to
 initialize upon addition to the domain
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1322751691 -3600
# Node ID e5128830bc1e13adbf0b07962821fe8b13ba93b8
# Parent  3b5b14fcd208e7c5cb1840ea76eb11a63958a030
libxl: wait for devices to initialize upon addition to the domain.

Block waiting for devices to initialize (switch to state 2). This is
necessary because we need to call the hotplug scripts when state is
2, otherwise the execution fails. Make use of the newly introduced
function libxl__wait_for_device_state.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 3b5b14fcd208 -r e5128830bc1e tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Thu Dec 01 16:01:31 2011 +0100
+++ b/tools/libxl/libxl.c	Thu Dec 01 16:01:31 2011 +0100
@@ -971,6 +971,8 @@ int libxl_device_disk_add(libxl_ctx *ctx
     flexarray_t *front;
     flexarray_t *back;
     char *dev;
+    char *be_path, *state_path, *state;
+    struct timeval tv;
     libxl__device device;
     int major, minor, rc;
 
@@ -1075,6 +1077,23 @@ int libxl_device_disk_add(libxl_ctx *ctx
                              libxl__xs_kvs_of_flexarray(&gc, back, back->count),
                              libxl__xs_kvs_of_flexarray(&gc, front, front->count));
 
+    be_path = libxl__device_backend_path(&gc, &device);
+    state_path = libxl__sprintf(&gc, "%s/state", be_path);
+    state = libxl__xs_read(&gc, XBT_NULL, state_path);
+
+    if (atoi(state) != XenbusStateInitWait) {
+        xs_watch(ctx->xsh, state_path, be_path);
+        tv.tv_sec = LIBXL_DESTROY_TIMEOUT;
+        tv.tv_usec = 0;
+        rc = libxl__wait_for_device_state(&gc, &tv, XenbusStateInitWait, NULL);
+        xs_unwatch(ctx->xsh, state_path, be_path);
+        if (rc < 0) {
+            LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
+                       "unable to initialize disk device: %s\n",
+                       disk->pdev_path);
+            goto out_free;
+        }
+    }
     rc = 0;
 
 out_free:
@@ -1450,6 +1469,8 @@ int libxl_device_nic_add(libxl_ctx *ctx,
     flexarray_t *back;
     libxl__device device;
     char *dompath, **l;
+    char *be_path, *state_path, *state;
+    struct timeval tv;
     unsigned int nb, rc;
 
     front = flexarray_make(16, 1);
@@ -1518,8 +1539,25 @@ int libxl_device_nic_add(libxl_ctx *ctx,
                              libxl__xs_kvs_of_flexarray(&gc, back, back->count),
                              libxl__xs_kvs_of_flexarray(&gc, front, front->count));
 
-    /* FIXME: wait for plug */
+    be_path = libxl__device_backend_path(&gc, &device);
+    state_path = libxl__sprintf(&gc, "%s/state", be_path);
+    state = libxl__xs_read(&gc, XBT_NULL, state_path);
+
+    if (atoi(state) != XenbusStateInitWait) {
+        xs_watch(ctx->xsh, state_path, be_path);
+        tv.tv_sec = LIBXL_DESTROY_TIMEOUT;
+        tv.tv_usec = 0;
+        rc = libxl__wait_for_device_state(&gc, &tv, XenbusStateInitWait, NULL);
+        xs_unwatch(ctx->xsh, state_path, be_path);
+        if (rc < 0) {
+            LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
+                       "unable to initialize nic device: %s\n",
+                       nic->ifname);
+            goto out_free;
+        }
+    }
     rc = 0;
+
 out_free:
     flexarray_free(back);
     flexarray_free(front);

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 15:17:16 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 15:17:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW8Nr-0006Ls-2t; Thu, 01 Dec 2011 15:17:11 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RW8Np-0006HN-0y
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 15:17:09 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1322752574!4953754!5
X-Originating-IP: [209.85.214.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29458 invoked from network); 1 Dec 2011 15:16:28 -0000
Received: from mail-bw0-f43.google.com (HELO mail-bw0-f43.google.com)
	(209.85.214.43)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 15:16:28 -0000
Received: by mail-bw0-f43.google.com with SMTP id j4so2238541bkw.30
	for <xen-devel@lists.xensource.com>;
	Thu, 01 Dec 2011 07:16:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=VXKRLw9wHOaSV+DgbJ+6HfMLB3fwRvZcQuJfmXkTcyw=;
	b=MEEM9Oc3aJFVLz7f4RSAX9DbuD8qNKCNmlBtpDNluL1PUUk3QTWWGRmFMTJLFJWmL0
	UxIb6hB4zLW/XaRpqJayWY7dIFqucGCHOXT+9VUxAR7GfWDDrBFKkjYGDrTHh7EE59hd
	YdAtaxWg9KoyEEwCZAgeUXzrGBed5/0bfYcOM=
Received: by 10.204.9.204 with SMTP id m12mr7771088bkm.131.1322752588774;
	Thu, 01 Dec 2011 07:16:28 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id c4sm11924270bkk.13.2011.12.01.07.16.25
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 01 Dec 2011 07:16:27 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 5e9c1fc4869fa14c2b54b33866a3784db94da852
Message-Id: <5e9c1fc4869fa14c2b54.1322752093@loki.upc.es>
In-Reply-To: <patchbomb.1322752087@loki.upc.es>
References: <patchbomb.1322752087@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Thu, 01 Dec 2011 16:08:13 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 06 of 11 v3] libxl: execute hotplug scripts
	directly from libxl
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1317386335 -7200
# Node ID 5e9c1fc4869fa14c2b54b33866a3784db94da852
# Parent  e5128830bc1e13adbf0b07962821fe8b13ba93b8
libxl: execute hotplug scripts directly from libxl.

Added the necessary handlers to execute hotplug scripts when necessary
from libxl. Split NetBSD and Linux hotplug calls into two separate
files, because parameters for hotplug scripts are different. Linux
has empty functions, since the calling of hotplug scripts is still
done using udev.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r e5128830bc1e -r 5e9c1fc4869f tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Thu Dec 01 16:01:31 2011 +0100
+++ b/tools/libxl/libxl.c	Fri Sep 30 14:38:55 2011 +0200
@@ -1018,6 +1018,11 @@ int libxl_device_disk_add(libxl_ctx *ctx
             flexarray_append(back, "params");
             flexarray_append(back, dev);
 
+            flexarray_append(back, "script");
+            flexarray_append(back, libxl__sprintf(&gc, "%s/%s",
+                                                  libxl_xen_script_dir_path(),
+                                                  "block"));
+
             assert(device.backend_kind == LIBXL__DEVICE_KIND_VBD);
             break;
         case LIBXL_DISK_BACKEND_TAP:
@@ -1094,6 +1099,15 @@ int libxl_device_disk_add(libxl_ctx *ctx
             goto out_free;
         }
     }
+
+    /* Call hotplug scripts to attach device */
+    if (libxl__device_execute_hotplug(&gc, &device, CONNECT) < 0) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to execute hotplug script for disk: %s\n",
+                   disk->pdev_path);
+        rc = -1;
+        goto out_free;
+    }
+
     rc = 0;
 
 out_free:
@@ -1556,6 +1570,15 @@ int libxl_device_nic_add(libxl_ctx *ctx,
             goto out_free;
         }
     }
+
+    /* Call hotplug scripts to attach device */
+    if (libxl__device_execute_hotplug(&gc, &device, CONNECT) < 0) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to execute hotplug script for nic: %s\n",
+                   nic->ifname);
+        rc = -1;
+        goto out_free;
+    }
+
     rc = 0;
 
 out_free:
diff -r e5128830bc1e -r 5e9c1fc4869f tools/libxl/libxl_device.c
--- a/tools/libxl/libxl_device.c	Thu Dec 01 16:01:31 2011 +0100
+++ b/tools/libxl/libxl_device.c	Fri Sep 30 14:38:55 2011 +0200
@@ -68,6 +68,25 @@ int libxl__parse_backend_path(libxl__gc 
     return libxl__device_kind_from_string(strkind, &dev->backend_kind);
 }
 
+int libxl__device_execute_hotplug(libxl__gc *gc, libxl__device *dev,
+                                  libxl__hotplug_action action)
+{
+    int rc = 0;
+
+    switch(dev->kind) {
+    case LIBXL__DEVICE_KIND_VIF:
+        rc = libxl__nic_hotplug(gc, dev, action);
+        break;
+    case LIBXL__DEVICE_KIND_VBD:
+        rc = libxl__disk_hotplug(gc, dev, action);
+        break;
+    default:
+        break;
+    }
+
+    return rc;
+}
+
 int libxl__device_generic_add(libxl__gc *gc, libxl__device *device,
                              char **bents, char **fents)
 {
@@ -449,6 +468,7 @@ int libxl__device_remove(libxl__gc *gc, 
     if (!state)
         goto out;
     if (atoi(state) != 4) {
+        libxl__device_execute_hotplug(gc, dev, DISCONNECT);
         libxl__device_destroy_tapdisk(gc, be_path);
         xs_rm(ctx->xsh, XBT_NULL, be_path);
         goto out;
@@ -493,6 +513,12 @@ int libxl__device_destroy(libxl__gc *gc,
     char *be_path = libxl__device_backend_path(gc, dev);
     char *fe_path = libxl__device_frontend_path(gc, dev);
 
+    /* 
+     * Run hotplug scripts, which will probably not be able to
+     * execute successfully since the device may still be plugged
+     */
+    libxl__device_execute_hotplug(gc, dev, DISCONNECT);
+
     xs_rm(ctx->xsh, XBT_NULL, be_path);
     xs_rm(ctx->xsh, XBT_NULL, fe_path);
 
diff -r e5128830bc1e -r 5e9c1fc4869f tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Thu Dec 01 16:01:31 2011 +0100
+++ b/tools/libxl/libxl_internal.h	Fri Sep 30 14:38:55 2011 +0200
@@ -289,6 +289,46 @@ _hidden int libxl__wait_for_device_state
  */
 _hidden int libxl__try_phy_backend(mode_t st_mode);
 
+/* hotplug functions */
+
+/* Action to pass to hotplug caller functions */
+typedef enum {
+    CONNECT = 1,
+    DISCONNECT = 2
+} libxl__hotplug_action;
+
+/*
+ * libxl__device_execute_hotplug - generic function to execute hotplug scripts
+ * gc: allocation pool
+ * dev: reference to the device that executes the hotplug scripts
+ * action: action to execute
+ *
+ * Returns 0 on success, and < 0 on error.
+ */
+_hidden int libxl__device_execute_hotplug(libxl__gc *gc, libxl__device *dev,
+                                          libxl__hotplug_action action);
+
+/*
+ * libxl__disk_hotplug - execute hotplug script for a disk type device
+ * gc: allocation pool
+ * dev: reference to the disk device
+ * action: action to execute
+ *
+ * Returns 0 on success, and < 0 on error.
+ */
+_hidden int libxl__disk_hotplug(libxl__gc *gc, libxl__device *dev,
+                                libxl__hotplug_action action);
+
+/*
+ * libxl__nic_hotplug - execute hotplug script for a nic type device
+ * gc: allocation pool
+ * dev: reference to the nic device
+ *
+ * Returns 0 on success, and < 0 on error.
+ */
+_hidden int libxl__nic_hotplug(libxl__gc *gc, libxl__device *dev,
+                               libxl__hotplug_action action);
+
 /* from libxl_pci */
 
 _hidden int libxl__device_pci_add(libxl__gc *gc, uint32_t domid, libxl_device_pci *pcidev, int starting);
diff -r e5128830bc1e -r 5e9c1fc4869f tools/libxl/libxl_linux.c
--- a/tools/libxl/libxl_linux.c	Thu Dec 01 16:01:31 2011 +0100
+++ b/tools/libxl/libxl_linux.c	Fri Sep 30 14:38:55 2011 +0200
@@ -25,3 +25,17 @@ int libxl__try_phy_backend(mode_t st_mod
 
     return 1;
 }
+
+/* Hotplug scripts caller functions */
+
+int libxl_disk_hotplug(libxl__gc *gc, libxl__device *dev,
+                       libxl__hotplug_action action)
+{
+    return 0;
+}
+
+int libxl_nic_hotplug_connect(libxl__gc *gc, libxl__device *dev,
+                              libxl__hotplug_action action)
+{
+    return 0;
+}
diff -r e5128830bc1e -r 5e9c1fc4869f tools/libxl/libxl_netbsd.c
--- a/tools/libxl/libxl_netbsd.c	Thu Dec 01 16:01:31 2011 +0100
+++ b/tools/libxl/libxl_netbsd.c	Fri Sep 30 14:38:55 2011 +0200
@@ -14,6 +14,7 @@
  */
  
 #include <sys/stat.h>
+#include <sys/wait.h>
 
 #include "libxl_internal.h"
 
@@ -24,3 +25,130 @@ int libxl__try_phy_backend(mode_t st_mod
 
     return 0;
 }
+
+/* Hotplug scripts caller functions */
+
+int libxl__disk_hotplug(libxl__gc *gc, libxl__device *dev,
+                        libxl__hotplug_action action)
+{
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+    char *be_path = libxl__device_backend_path(gc, dev);
+    struct stat stab;
+    char *stype, *sstate, *script, *params;
+    char **args;
+    int status, nr = 0;
+    int rc = -1;
+    flexarray_t *f_args;
+
+    script = libxl__xs_read(gc, XBT_NULL,
+                            libxl__sprintf(gc, "%s/%s", be_path, "script"));
+    if (!script) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Unable to read script from %s",
+                                          be_path);
+        return -1;
+    }
+
+    params = libxl__xs_read(gc, XBT_NULL,
+                            libxl__sprintf(gc, "%s/%s", be_path, "params"));
+    if (!params)
+        return -1;
+
+    sstate = libxl__xs_read(gc, XBT_NULL,
+                            libxl__sprintf(gc, "%s/%s", be_path, "state"));
+    if (!sstate) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Unable to read state from %s",
+                   be_path);
+        return -1;
+    }
+
+    if (stat(params, &stab) < 0) {
+        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "failed to get stat info\n");
+        return -1;
+    }
+    if (S_ISBLK(stab.st_mode))
+        stype = "phy";
+    if (S_ISREG(stab.st_mode))
+        stype = "file";
+    if (stype == NULL) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Not block or regular file");
+        return -1;
+    }
+
+    f_args = flexarray_make(5, 1);
+    if (!f_args)
+        return -1;
+
+    flexarray_set(f_args, nr++, script);
+    flexarray_set(f_args, nr++, be_path);
+    flexarray_set(f_args, nr++, libxl__sprintf(gc, "%d", action));
+    flexarray_set(f_args, nr++, stype);
+    flexarray_set(f_args, nr++, NULL);
+
+    args = (char **) flexarray_contents(f_args);
+
+    LIBXL__LOG(ctx, LIBXL__LOG_DEBUG,
+               "Calling disk hotplug script: %s %s %s %s",
+               args[0], args[1], args[2], args[3]);
+    status = libxl__forkexec(gc, -1, -1, -1, args);
+    if (!WIFEXITED(status) || WEXITSTATUS(status) == EXIT_FAILURE) {
+        rc = -1;
+        goto out;
+    }
+    rc = 0;
+
+out:
+    free(args);
+    return rc;
+}
+
+int libxl__nic_hotplug(libxl__gc *gc, libxl__device *dev,
+                       libxl__hotplug_action action)
+{
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+    char *be_path = libxl__device_backend_path(gc, dev);
+    char *sstate, *script;
+    char **args;
+    int status, nr = 0;
+    int rc = -1;
+    flexarray_t *f_args;
+
+    script = libxl__xs_read(gc, XBT_NULL,
+                            libxl__sprintf(gc, "%s/%s", be_path, "script"));
+    if (!script) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Unable to read script from %s",
+                   be_path);
+        return -1;
+    }
+
+    sstate = libxl__xs_read(gc, XBT_NULL,
+                            libxl__sprintf(gc, "%s/%s", be_path, "state"));
+    if (!sstate) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Unable to read state from %s",
+                                          be_path);
+        return -1;
+    }
+
+    f_args = flexarray_make(4, 1);
+    if (!f_args)
+        return -1;
+
+    flexarray_set(f_args, nr++, script);
+    flexarray_set(f_args, nr++, be_path);
+    flexarray_set(f_args, nr++, libxl__sprintf(gc, "%d", action));
+    flexarray_set(f_args, nr++, NULL);
+
+    args = (char **) flexarray_contents(f_args);
+
+    LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Calling nic hotplug script: %s %s %s",
+               args[0], args[1], args[2]);
+    status = libxl__forkexec(gc, -1, -1, -1, args);
+    if (!WIFEXITED(status) || WEXITSTATUS(status) == EXIT_FAILURE) {
+        rc = -1;
+        goto out;
+    }
+    rc = 0;
+
+out:
+    free(args);
+    return rc;
+}

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 15:17:16 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 15:17:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW8Nr-0006Ls-2t; Thu, 01 Dec 2011 15:17:11 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RW8Np-0006HN-0y
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 15:17:09 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1322752574!4953754!5
X-Originating-IP: [209.85.214.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29458 invoked from network); 1 Dec 2011 15:16:28 -0000
Received: from mail-bw0-f43.google.com (HELO mail-bw0-f43.google.com)
	(209.85.214.43)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 15:16:28 -0000
Received: by mail-bw0-f43.google.com with SMTP id j4so2238541bkw.30
	for <xen-devel@lists.xensource.com>;
	Thu, 01 Dec 2011 07:16:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=VXKRLw9wHOaSV+DgbJ+6HfMLB3fwRvZcQuJfmXkTcyw=;
	b=MEEM9Oc3aJFVLz7f4RSAX9DbuD8qNKCNmlBtpDNluL1PUUk3QTWWGRmFMTJLFJWmL0
	UxIb6hB4zLW/XaRpqJayWY7dIFqucGCHOXT+9VUxAR7GfWDDrBFKkjYGDrTHh7EE59hd
	YdAtaxWg9KoyEEwCZAgeUXzrGBed5/0bfYcOM=
Received: by 10.204.9.204 with SMTP id m12mr7771088bkm.131.1322752588774;
	Thu, 01 Dec 2011 07:16:28 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id c4sm11924270bkk.13.2011.12.01.07.16.25
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 01 Dec 2011 07:16:27 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 5e9c1fc4869fa14c2b54b33866a3784db94da852
Message-Id: <5e9c1fc4869fa14c2b54.1322752093@loki.upc.es>
In-Reply-To: <patchbomb.1322752087@loki.upc.es>
References: <patchbomb.1322752087@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Thu, 01 Dec 2011 16:08:13 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 06 of 11 v3] libxl: execute hotplug scripts
	directly from libxl
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1317386335 -7200
# Node ID 5e9c1fc4869fa14c2b54b33866a3784db94da852
# Parent  e5128830bc1e13adbf0b07962821fe8b13ba93b8
libxl: execute hotplug scripts directly from libxl.

Added the necessary handlers to execute hotplug scripts when necessary
from libxl. Split NetBSD and Linux hotplug calls into two separate
files, because parameters for hotplug scripts are different. Linux
has empty functions, since the calling of hotplug scripts is still
done using udev.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r e5128830bc1e -r 5e9c1fc4869f tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Thu Dec 01 16:01:31 2011 +0100
+++ b/tools/libxl/libxl.c	Fri Sep 30 14:38:55 2011 +0200
@@ -1018,6 +1018,11 @@ int libxl_device_disk_add(libxl_ctx *ctx
             flexarray_append(back, "params");
             flexarray_append(back, dev);
 
+            flexarray_append(back, "script");
+            flexarray_append(back, libxl__sprintf(&gc, "%s/%s",
+                                                  libxl_xen_script_dir_path(),
+                                                  "block"));
+
             assert(device.backend_kind == LIBXL__DEVICE_KIND_VBD);
             break;
         case LIBXL_DISK_BACKEND_TAP:
@@ -1094,6 +1099,15 @@ int libxl_device_disk_add(libxl_ctx *ctx
             goto out_free;
         }
     }
+
+    /* Call hotplug scripts to attach device */
+    if (libxl__device_execute_hotplug(&gc, &device, CONNECT) < 0) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to execute hotplug script for disk: %s\n",
+                   disk->pdev_path);
+        rc = -1;
+        goto out_free;
+    }
+
     rc = 0;
 
 out_free:
@@ -1556,6 +1570,15 @@ int libxl_device_nic_add(libxl_ctx *ctx,
             goto out_free;
         }
     }
+
+    /* Call hotplug scripts to attach device */
+    if (libxl__device_execute_hotplug(&gc, &device, CONNECT) < 0) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to execute hotplug script for nic: %s\n",
+                   nic->ifname);
+        rc = -1;
+        goto out_free;
+    }
+
     rc = 0;
 
 out_free:
diff -r e5128830bc1e -r 5e9c1fc4869f tools/libxl/libxl_device.c
--- a/tools/libxl/libxl_device.c	Thu Dec 01 16:01:31 2011 +0100
+++ b/tools/libxl/libxl_device.c	Fri Sep 30 14:38:55 2011 +0200
@@ -68,6 +68,25 @@ int libxl__parse_backend_path(libxl__gc 
     return libxl__device_kind_from_string(strkind, &dev->backend_kind);
 }
 
+int libxl__device_execute_hotplug(libxl__gc *gc, libxl__device *dev,
+                                  libxl__hotplug_action action)
+{
+    int rc = 0;
+
+    switch(dev->kind) {
+    case LIBXL__DEVICE_KIND_VIF:
+        rc = libxl__nic_hotplug(gc, dev, action);
+        break;
+    case LIBXL__DEVICE_KIND_VBD:
+        rc = libxl__disk_hotplug(gc, dev, action);
+        break;
+    default:
+        break;
+    }
+
+    return rc;
+}
+
 int libxl__device_generic_add(libxl__gc *gc, libxl__device *device,
                              char **bents, char **fents)
 {
@@ -449,6 +468,7 @@ int libxl__device_remove(libxl__gc *gc, 
     if (!state)
         goto out;
     if (atoi(state) != 4) {
+        libxl__device_execute_hotplug(gc, dev, DISCONNECT);
         libxl__device_destroy_tapdisk(gc, be_path);
         xs_rm(ctx->xsh, XBT_NULL, be_path);
         goto out;
@@ -493,6 +513,12 @@ int libxl__device_destroy(libxl__gc *gc,
     char *be_path = libxl__device_backend_path(gc, dev);
     char *fe_path = libxl__device_frontend_path(gc, dev);
 
+    /* 
+     * Run hotplug scripts, which will probably not be able to
+     * execute successfully since the device may still be plugged
+     */
+    libxl__device_execute_hotplug(gc, dev, DISCONNECT);
+
     xs_rm(ctx->xsh, XBT_NULL, be_path);
     xs_rm(ctx->xsh, XBT_NULL, fe_path);
 
diff -r e5128830bc1e -r 5e9c1fc4869f tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Thu Dec 01 16:01:31 2011 +0100
+++ b/tools/libxl/libxl_internal.h	Fri Sep 30 14:38:55 2011 +0200
@@ -289,6 +289,46 @@ _hidden int libxl__wait_for_device_state
  */
 _hidden int libxl__try_phy_backend(mode_t st_mode);
 
+/* hotplug functions */
+
+/* Action to pass to hotplug caller functions */
+typedef enum {
+    CONNECT = 1,
+    DISCONNECT = 2
+} libxl__hotplug_action;
+
+/*
+ * libxl__device_execute_hotplug - generic function to execute hotplug scripts
+ * gc: allocation pool
+ * dev: reference to the device that executes the hotplug scripts
+ * action: action to execute
+ *
+ * Returns 0 on success, and < 0 on error.
+ */
+_hidden int libxl__device_execute_hotplug(libxl__gc *gc, libxl__device *dev,
+                                          libxl__hotplug_action action);
+
+/*
+ * libxl__disk_hotplug - execute hotplug script for a disk type device
+ * gc: allocation pool
+ * dev: reference to the disk device
+ * action: action to execute
+ *
+ * Returns 0 on success, and < 0 on error.
+ */
+_hidden int libxl__disk_hotplug(libxl__gc *gc, libxl__device *dev,
+                                libxl__hotplug_action action);
+
+/*
+ * libxl__nic_hotplug - execute hotplug script for a nic type device
+ * gc: allocation pool
+ * dev: reference to the nic device
+ *
+ * Returns 0 on success, and < 0 on error.
+ */
+_hidden int libxl__nic_hotplug(libxl__gc *gc, libxl__device *dev,
+                               libxl__hotplug_action action);
+
 /* from libxl_pci */
 
 _hidden int libxl__device_pci_add(libxl__gc *gc, uint32_t domid, libxl_device_pci *pcidev, int starting);
diff -r e5128830bc1e -r 5e9c1fc4869f tools/libxl/libxl_linux.c
--- a/tools/libxl/libxl_linux.c	Thu Dec 01 16:01:31 2011 +0100
+++ b/tools/libxl/libxl_linux.c	Fri Sep 30 14:38:55 2011 +0200
@@ -25,3 +25,17 @@ int libxl__try_phy_backend(mode_t st_mod
 
     return 1;
 }
+
+/* Hotplug scripts caller functions */
+
+int libxl_disk_hotplug(libxl__gc *gc, libxl__device *dev,
+                       libxl__hotplug_action action)
+{
+    return 0;
+}
+
+int libxl_nic_hotplug_connect(libxl__gc *gc, libxl__device *dev,
+                              libxl__hotplug_action action)
+{
+    return 0;
+}
diff -r e5128830bc1e -r 5e9c1fc4869f tools/libxl/libxl_netbsd.c
--- a/tools/libxl/libxl_netbsd.c	Thu Dec 01 16:01:31 2011 +0100
+++ b/tools/libxl/libxl_netbsd.c	Fri Sep 30 14:38:55 2011 +0200
@@ -14,6 +14,7 @@
  */
  
 #include <sys/stat.h>
+#include <sys/wait.h>
 
 #include "libxl_internal.h"
 
@@ -24,3 +25,130 @@ int libxl__try_phy_backend(mode_t st_mod
 
     return 0;
 }
+
+/* Hotplug scripts caller functions */
+
+int libxl__disk_hotplug(libxl__gc *gc, libxl__device *dev,
+                        libxl__hotplug_action action)
+{
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+    char *be_path = libxl__device_backend_path(gc, dev);
+    struct stat stab;
+    char *stype, *sstate, *script, *params;
+    char **args;
+    int status, nr = 0;
+    int rc = -1;
+    flexarray_t *f_args;
+
+    script = libxl__xs_read(gc, XBT_NULL,
+                            libxl__sprintf(gc, "%s/%s", be_path, "script"));
+    if (!script) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Unable to read script from %s",
+                                          be_path);
+        return -1;
+    }
+
+    params = libxl__xs_read(gc, XBT_NULL,
+                            libxl__sprintf(gc, "%s/%s", be_path, "params"));
+    if (!params)
+        return -1;
+
+    sstate = libxl__xs_read(gc, XBT_NULL,
+                            libxl__sprintf(gc, "%s/%s", be_path, "state"));
+    if (!sstate) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Unable to read state from %s",
+                   be_path);
+        return -1;
+    }
+
+    if (stat(params, &stab) < 0) {
+        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "failed to get stat info\n");
+        return -1;
+    }
+    if (S_ISBLK(stab.st_mode))
+        stype = "phy";
+    if (S_ISREG(stab.st_mode))
+        stype = "file";
+    if (stype == NULL) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Not block or regular file");
+        return -1;
+    }
+
+    f_args = flexarray_make(5, 1);
+    if (!f_args)
+        return -1;
+
+    flexarray_set(f_args, nr++, script);
+    flexarray_set(f_args, nr++, be_path);
+    flexarray_set(f_args, nr++, libxl__sprintf(gc, "%d", action));
+    flexarray_set(f_args, nr++, stype);
+    flexarray_set(f_args, nr++, NULL);
+
+    args = (char **) flexarray_contents(f_args);
+
+    LIBXL__LOG(ctx, LIBXL__LOG_DEBUG,
+               "Calling disk hotplug script: %s %s %s %s",
+               args[0], args[1], args[2], args[3]);
+    status = libxl__forkexec(gc, -1, -1, -1, args);
+    if (!WIFEXITED(status) || WEXITSTATUS(status) == EXIT_FAILURE) {
+        rc = -1;
+        goto out;
+    }
+    rc = 0;
+
+out:
+    free(args);
+    return rc;
+}
+
+int libxl__nic_hotplug(libxl__gc *gc, libxl__device *dev,
+                       libxl__hotplug_action action)
+{
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+    char *be_path = libxl__device_backend_path(gc, dev);
+    char *sstate, *script;
+    char **args;
+    int status, nr = 0;
+    int rc = -1;
+    flexarray_t *f_args;
+
+    script = libxl__xs_read(gc, XBT_NULL,
+                            libxl__sprintf(gc, "%s/%s", be_path, "script"));
+    if (!script) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Unable to read script from %s",
+                   be_path);
+        return -1;
+    }
+
+    sstate = libxl__xs_read(gc, XBT_NULL,
+                            libxl__sprintf(gc, "%s/%s", be_path, "state"));
+    if (!sstate) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Unable to read state from %s",
+                                          be_path);
+        return -1;
+    }
+
+    f_args = flexarray_make(4, 1);
+    if (!f_args)
+        return -1;
+
+    flexarray_set(f_args, nr++, script);
+    flexarray_set(f_args, nr++, be_path);
+    flexarray_set(f_args, nr++, libxl__sprintf(gc, "%d", action));
+    flexarray_set(f_args, nr++, NULL);
+
+    args = (char **) flexarray_contents(f_args);
+
+    LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Calling nic hotplug script: %s %s %s",
+               args[0], args[1], args[2]);
+    status = libxl__forkexec(gc, -1, -1, -1, args);
+    if (!WIFEXITED(status) || WEXITSTATUS(status) == EXIT_FAILURE) {
+        rc = -1;
+        goto out;
+    }
+    rc = 0;
+
+out:
+    free(args);
+    return rc;
+}

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 15:17:17 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 15:17:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW8Nt-0006O6-Ho; Thu, 01 Dec 2011 15:17:13 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RW8Ns-0006Iy-3M
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 15:17:12 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1322752574!4953754!6
X-Originating-IP: [209.85.214.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29750 invoked from network); 1 Dec 2011 15:16:32 -0000
Received: from mail-bw0-f43.google.com (HELO mail-bw0-f43.google.com)
	(209.85.214.43)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 15:16:32 -0000
Received: by mail-bw0-f43.google.com with SMTP id j4so2238541bkw.30
	for <xen-devel@lists.xensource.com>;
	Thu, 01 Dec 2011 07:16:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=6gfnTItIJZc93tKP3Eg2tnTXLpvxEyNTOumu2Cc6Z18=;
	b=C/PmDrXuU1oRfl7vJ+RCo05u8BFdy6C5vYM6BWiksGN0OV71oMmE+nUleEfqLNUuUq
	rUB+oBvC30t3tQ1w8ohQVEX4/PNO6ATNu0CvvhIroPI511A5jA6N9xkACimARHy4nhNt
	eHGWURLQWZKLCSIBh417yMZJmJv3sNfwUEgwE=
Received: by 10.204.148.4 with SMTP id n4mr7911144bkv.42.1322752592082;
	Thu, 01 Dec 2011 07:16:32 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id c4sm11924270bkk.13.2011.12.01.07.16.28
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 01 Dec 2011 07:16:29 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 8ff55cfa427f123982884436f8b80614fb0ce50f
Message-Id: <8ff55cfa427f12398288.1322752094@loki.upc.es>
In-Reply-To: <patchbomb.1322752087@loki.upc.es>
References: <patchbomb.1322752087@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Thu, 01 Dec 2011 16:08:14 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 07 of 11 v3] hotplug NetBSD: pass an action
 instead of a state to hotplug scripts
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1322751691 -3600
# Node ID 8ff55cfa427f123982884436f8b80614fb0ce50f
# Parent  5e9c1fc4869fa14c2b54b33866a3784db94da852
hotplug NetBSD: pass an action instead of a state to hotplug scripts

change second parameter of NetBSD hotplug scripts to take an action
(CONNECT/DISCONNECT) instead of a xenbus state.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 5e9c1fc4869f -r 8ff55cfa427f tools/hotplug/NetBSD/block
--- a/tools/hotplug/NetBSD/block	Fri Sep 30 14:38:55 2011 +0200
+++ b/tools/hotplug/NetBSD/block	Thu Dec 01 16:01:31 2011 +0100
@@ -18,12 +18,12 @@ error() {
 	
 
 xpath=$1
-xstatus=$2
+xaction=$2
 xtype=$3
 xparams=$(xenstore-read "$xpath/params")
 
-case $xstatus in
-6)
+case $xaction in
+2)
 	# device removed
 	case $xtype in
 	file)
@@ -41,7 +41,7 @@ 6)
 	xenstore-rm $xpath
 	exit 0
 	;;
-2)
+1)
 	case $xtype in
 	file)
 		# Store the list of available vnd(4) devices in
diff -r 5e9c1fc4869f -r 8ff55cfa427f tools/hotplug/NetBSD/vif-bridge
--- a/tools/hotplug/NetBSD/vif-bridge	Fri Sep 30 14:38:55 2011 +0200
+++ b/tools/hotplug/NetBSD/vif-bridge	Thu Dec 01 16:01:31 2011 +0100
@@ -11,15 +11,15 @@ PATH=${BINDIR}:${SBINDIR}:${LIBEXEC}:${P
 export PATH
 
 xpath=$1
-xstatus=$2
+xaction=$2
 
-case $xstatus in
-6)
+case $xaction in
+2)
 	# device removed
 	xenstore-rm $xpath
 	exit 0
 	;;
-2)
+1)
 	xbridge=$(xenstore-read "$xpath/bridge")
 	xfid=$(xenstore-read "$xpath/frontend-id")
 	xhandle=$(xenstore-read "$xpath/handle")
diff -r 5e9c1fc4869f -r 8ff55cfa427f tools/hotplug/NetBSD/vif-ip
--- a/tools/hotplug/NetBSD/vif-ip	Fri Sep 30 14:38:55 2011 +0200
+++ b/tools/hotplug/NetBSD/vif-ip	Thu Dec 01 16:01:31 2011 +0100
@@ -11,15 +11,15 @@ PATH=${BINDIR}:${SBINDIR}:${LIBEXEC}:${P
 export PATH
 
 xpath=$1
-xstatus=$2
+xaction=$2
 
-case $xstatus in
-6)
+case $xaction in
+2)
 	# device removed
 	xenstore-rm $xpath
 	exit 0
 	;;
-2)
+1)
 	xip=$(xenstore-read "$xpath/ip")
 	xfid=$(xenstore-read "$xpath/frontend-id")
 	xhandle=$(xenstore-read "$xpath/handle")

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 15:17:17 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 15:17:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW8Nt-0006O6-Ho; Thu, 01 Dec 2011 15:17:13 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RW8Ns-0006Iy-3M
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 15:17:12 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1322752574!4953754!6
X-Originating-IP: [209.85.214.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29750 invoked from network); 1 Dec 2011 15:16:32 -0000
Received: from mail-bw0-f43.google.com (HELO mail-bw0-f43.google.com)
	(209.85.214.43)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 15:16:32 -0000
Received: by mail-bw0-f43.google.com with SMTP id j4so2238541bkw.30
	for <xen-devel@lists.xensource.com>;
	Thu, 01 Dec 2011 07:16:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=6gfnTItIJZc93tKP3Eg2tnTXLpvxEyNTOumu2Cc6Z18=;
	b=C/PmDrXuU1oRfl7vJ+RCo05u8BFdy6C5vYM6BWiksGN0OV71oMmE+nUleEfqLNUuUq
	rUB+oBvC30t3tQ1w8ohQVEX4/PNO6ATNu0CvvhIroPI511A5jA6N9xkACimARHy4nhNt
	eHGWURLQWZKLCSIBh417yMZJmJv3sNfwUEgwE=
Received: by 10.204.148.4 with SMTP id n4mr7911144bkv.42.1322752592082;
	Thu, 01 Dec 2011 07:16:32 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id c4sm11924270bkk.13.2011.12.01.07.16.28
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 01 Dec 2011 07:16:29 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 8ff55cfa427f123982884436f8b80614fb0ce50f
Message-Id: <8ff55cfa427f12398288.1322752094@loki.upc.es>
In-Reply-To: <patchbomb.1322752087@loki.upc.es>
References: <patchbomb.1322752087@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Thu, 01 Dec 2011 16:08:14 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 07 of 11 v3] hotplug NetBSD: pass an action
 instead of a state to hotplug scripts
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1322751691 -3600
# Node ID 8ff55cfa427f123982884436f8b80614fb0ce50f
# Parent  5e9c1fc4869fa14c2b54b33866a3784db94da852
hotplug NetBSD: pass an action instead of a state to hotplug scripts

change second parameter of NetBSD hotplug scripts to take an action
(CONNECT/DISCONNECT) instead of a xenbus state.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 5e9c1fc4869f -r 8ff55cfa427f tools/hotplug/NetBSD/block
--- a/tools/hotplug/NetBSD/block	Fri Sep 30 14:38:55 2011 +0200
+++ b/tools/hotplug/NetBSD/block	Thu Dec 01 16:01:31 2011 +0100
@@ -18,12 +18,12 @@ error() {
 	
 
 xpath=$1
-xstatus=$2
+xaction=$2
 xtype=$3
 xparams=$(xenstore-read "$xpath/params")
 
-case $xstatus in
-6)
+case $xaction in
+2)
 	# device removed
 	case $xtype in
 	file)
@@ -41,7 +41,7 @@ 6)
 	xenstore-rm $xpath
 	exit 0
 	;;
-2)
+1)
 	case $xtype in
 	file)
 		# Store the list of available vnd(4) devices in
diff -r 5e9c1fc4869f -r 8ff55cfa427f tools/hotplug/NetBSD/vif-bridge
--- a/tools/hotplug/NetBSD/vif-bridge	Fri Sep 30 14:38:55 2011 +0200
+++ b/tools/hotplug/NetBSD/vif-bridge	Thu Dec 01 16:01:31 2011 +0100
@@ -11,15 +11,15 @@ PATH=${BINDIR}:${SBINDIR}:${LIBEXEC}:${P
 export PATH
 
 xpath=$1
-xstatus=$2
+xaction=$2
 
-case $xstatus in
-6)
+case $xaction in
+2)
 	# device removed
 	xenstore-rm $xpath
 	exit 0
 	;;
-2)
+1)
 	xbridge=$(xenstore-read "$xpath/bridge")
 	xfid=$(xenstore-read "$xpath/frontend-id")
 	xhandle=$(xenstore-read "$xpath/handle")
diff -r 5e9c1fc4869f -r 8ff55cfa427f tools/hotplug/NetBSD/vif-ip
--- a/tools/hotplug/NetBSD/vif-ip	Fri Sep 30 14:38:55 2011 +0200
+++ b/tools/hotplug/NetBSD/vif-ip	Thu Dec 01 16:01:31 2011 +0100
@@ -11,15 +11,15 @@ PATH=${BINDIR}:${SBINDIR}:${LIBEXEC}:${P
 export PATH
 
 xpath=$1
-xstatus=$2
+xaction=$2
 
-case $xstatus in
-6)
+case $xaction in
+2)
 	# device removed
 	xenstore-rm $xpath
 	exit 0
 	;;
-2)
+1)
 	xip=$(xenstore-read "$xpath/ip")
 	xfid=$(xenstore-read "$xpath/frontend-id")
 	xhandle=$(xenstore-read "$xpath/handle")

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 15:17:21 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 15: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.xensource.com>)
	id 1RW8Ny-0006SW-6H; Thu, 01 Dec 2011 15:17:18 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RW8Nw-0006Lo-8c
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 15:17:16 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1322752574!4953754!7
X-Originating-IP: [209.85.214.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29991 invoked from network); 1 Dec 2011 15:16:36 -0000
Received: from mail-bw0-f43.google.com (HELO mail-bw0-f43.google.com)
	(209.85.214.43)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 15:16:36 -0000
Received: by mail-bw0-f43.google.com with SMTP id j4so2238541bkw.30
	for <xen-devel@lists.xensource.com>;
	Thu, 01 Dec 2011 07:16:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=DJWrsZQSjnEeMiQF6A0jOT5UFOA2mABewxaFzIdkm+w=;
	b=qYOHCNtOcNJBPWqsirzwzd/2as5xdNKiYBg/xqrQobNWFWKhD5rRm6WDNhl555YQzO
	aafPhbwvu+sqbVlppIzHyjqQkwftAgKdLA7aH3PKRxRujS8aNwjR94K2pmXzBzTA6k9s
	6ahpMfQErxtuFFUQk/JFD0ZYS1z1INBh2yy8E=
Received: by 10.204.155.141 with SMTP id s13mr8087098bkw.40.1322752596371;
	Thu, 01 Dec 2011 07:16:36 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id c4sm11924270bkk.13.2011.12.01.07.16.32
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 01 Dec 2011 07:16:34 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 698834eeca6709c5569ac5c091b1dfaa17146b7f
Message-Id: <698834eeca6709c5569a.1322752095@loki.upc.es>
In-Reply-To: <patchbomb.1322752087@loki.upc.es>
References: <patchbomb.1322752087@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Thu, 01 Dec 2011 16:08:15 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 08 of 11 v3] xenbackendd: pass action to hotplug
	script
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1322751691 -3600
# Node ID 698834eeca6709c5569ac5c091b1dfaa17146b7f
# Parent  8ff55cfa427f123982884436f8b80614fb0ce50f
xenbackendd: pass action to hotplug script

Pass an action to hotplug scripts instead of a xenbus state.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 8ff55cfa427f -r 698834eeca67 tools/xenbackendd/xenbackendd.c
--- a/tools/xenbackendd/xenbackendd.c	Thu Dec 01 16:01:31 2011 +0100
+++ b/tools/xenbackendd/xenbackendd.c	Thu Dec 01 16:01:31 2011 +0100
@@ -34,6 +34,9 @@
 #define DEVTYPE_VIF 1
 #define DEVTYPE_VBD 2
 
+#define CONNECT "1"
+#define DISCONNECT "2"
+
 #define DOMAIN_PATH "/local/domain/0"
 
 #ifndef XEN_SCRIPT_DIR
@@ -150,6 +153,7 @@ main(int argc, char * const argv[])
 	unsigned int num;
 	char *s;
 	int state;
+	char *action;
 	char *sstate;
 	char *stype;
 	char *params;
@@ -300,7 +304,8 @@ main(int argc, char * const argv[])
 				    strerror(errno));
 				goto next2;
 			}
-			doexec(s, vec[XS_WATCH_PATH], sstate, NULL);
+			action = (state == 6 ? DISCONNECT : CONNECT);
+			doexec(s, vec[XS_WATCH_PATH], action, NULL);
 			break;
 
 		case DEVTYPE_VBD:
@@ -329,7 +334,8 @@ main(int argc, char * const argv[])
 					params, strerror(errno));
 				goto next3;
 			}
-			doexec(vbd_script, vec[XS_WATCH_PATH], sstate, stype);
+			action = (state == 6 ? DISCONNECT : CONNECT);
+			doexec(vbd_script, vec[XS_WATCH_PATH], action, stype);
 next3:
 			free(params);
 			break;

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 15:17:21 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 15: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.xensource.com>)
	id 1RW8Ny-0006SW-6H; Thu, 01 Dec 2011 15:17:18 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RW8Nw-0006Lo-8c
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 15:17:16 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1322752574!4953754!7
X-Originating-IP: [209.85.214.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29991 invoked from network); 1 Dec 2011 15:16:36 -0000
Received: from mail-bw0-f43.google.com (HELO mail-bw0-f43.google.com)
	(209.85.214.43)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 15:16:36 -0000
Received: by mail-bw0-f43.google.com with SMTP id j4so2238541bkw.30
	for <xen-devel@lists.xensource.com>;
	Thu, 01 Dec 2011 07:16:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=DJWrsZQSjnEeMiQF6A0jOT5UFOA2mABewxaFzIdkm+w=;
	b=qYOHCNtOcNJBPWqsirzwzd/2as5xdNKiYBg/xqrQobNWFWKhD5rRm6WDNhl555YQzO
	aafPhbwvu+sqbVlppIzHyjqQkwftAgKdLA7aH3PKRxRujS8aNwjR94K2pmXzBzTA6k9s
	6ahpMfQErxtuFFUQk/JFD0ZYS1z1INBh2yy8E=
Received: by 10.204.155.141 with SMTP id s13mr8087098bkw.40.1322752596371;
	Thu, 01 Dec 2011 07:16:36 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id c4sm11924270bkk.13.2011.12.01.07.16.32
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 01 Dec 2011 07:16:34 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 698834eeca6709c5569ac5c091b1dfaa17146b7f
Message-Id: <698834eeca6709c5569a.1322752095@loki.upc.es>
In-Reply-To: <patchbomb.1322752087@loki.upc.es>
References: <patchbomb.1322752087@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Thu, 01 Dec 2011 16:08:15 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 08 of 11 v3] xenbackendd: pass action to hotplug
	script
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1322751691 -3600
# Node ID 698834eeca6709c5569ac5c091b1dfaa17146b7f
# Parent  8ff55cfa427f123982884436f8b80614fb0ce50f
xenbackendd: pass action to hotplug script

Pass an action to hotplug scripts instead of a xenbus state.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 8ff55cfa427f -r 698834eeca67 tools/xenbackendd/xenbackendd.c
--- a/tools/xenbackendd/xenbackendd.c	Thu Dec 01 16:01:31 2011 +0100
+++ b/tools/xenbackendd/xenbackendd.c	Thu Dec 01 16:01:31 2011 +0100
@@ -34,6 +34,9 @@
 #define DEVTYPE_VIF 1
 #define DEVTYPE_VBD 2
 
+#define CONNECT "1"
+#define DISCONNECT "2"
+
 #define DOMAIN_PATH "/local/domain/0"
 
 #ifndef XEN_SCRIPT_DIR
@@ -150,6 +153,7 @@ main(int argc, char * const argv[])
 	unsigned int num;
 	char *s;
 	int state;
+	char *action;
 	char *sstate;
 	char *stype;
 	char *params;
@@ -300,7 +304,8 @@ main(int argc, char * const argv[])
 				    strerror(errno));
 				goto next2;
 			}
-			doexec(s, vec[XS_WATCH_PATH], sstate, NULL);
+			action = (state == 6 ? DISCONNECT : CONNECT);
+			doexec(s, vec[XS_WATCH_PATH], action, NULL);
 			break;
 
 		case DEVTYPE_VBD:
@@ -329,7 +334,8 @@ main(int argc, char * const argv[])
 					params, strerror(errno));
 				goto next3;
 			}
-			doexec(vbd_script, vec[XS_WATCH_PATH], sstate, stype);
+			action = (state == 6 ? DISCONNECT : CONNECT);
+			doexec(vbd_script, vec[XS_WATCH_PATH], action, stype);
 next3:
 			free(params);
 			break;

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 15:17:24 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 15:17:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW8O0-0006Ub-Iy; Thu, 01 Dec 2011 15:17:20 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RW8Nz-0006PE-R8
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 15:17:20 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1322752574!4953754!8
X-Originating-IP: [209.85.214.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30202 invoked from network); 1 Dec 2011 15:16:40 -0000
Received: from mail-bw0-f43.google.com (HELO mail-bw0-f43.google.com)
	(209.85.214.43)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 15:16:40 -0000
Received: by mail-bw0-f43.google.com with SMTP id j4so2238541bkw.30
	for <xen-devel@lists.xensource.com>;
	Thu, 01 Dec 2011 07:16:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=au4sHXtMvJzcfbbqRAyJA101OteCNDy5UZ+rNQRkrCo=;
	b=C1sg2iElumX/0q1+TTJGsqZmwRlxH9NKn7Pds53DbJLtbnTpnSL3bFeZ9zrMYomICH
	huCq+/zPt+0egr1VacLDuEefxKOkg962uOJ27LzYv5uZycDvv0Xi8mtSrKC/u6h1sQ5i
	YOhFnqzvtEcZdfTmkWX7+ViwBTstCEj8enZaQ=
Received: by 10.204.0.80 with SMTP id 16mr7864071bka.29.1322752599891;
	Thu, 01 Dec 2011 07:16:39 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id c4sm11924270bkk.13.2011.12.01.07.16.36
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 01 Dec 2011 07:16:37 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 3e1212856bca08fda162eb27d6b9702d3f973f21
Message-Id: <3e1212856bca08fda162.1322752096@loki.upc.es>
In-Reply-To: <patchbomb.1322752087@loki.upc.es>
References: <patchbomb.1322752087@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Thu, 01 Dec 2011 16:08:16 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 09 of 11 v3] hotplug: remove debug messages from
 NetBSD hotplug scripts
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1322751691 -3600
# Node ID 3e1212856bca08fda162eb27d6b9702d3f973f21
# Parent  698834eeca6709c5569ac5c091b1dfaa17146b7f
hotplug: remove debug messages from NetBSD hotplug scripts

Remove unecessary debug messages from NetBSD hotplug scripts, left
error messages only.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 698834eeca67 -r 3e1212856bca tools/hotplug/NetBSD/block
--- a/tools/hotplug/NetBSD/block	Thu Dec 01 16:01:31 2011 +0100
+++ b/tools/hotplug/NetBSD/block	Thu Dec 01 16:01:31 2011 +0100
@@ -64,14 +64,12 @@ 1)
 			if [ "$status" = "free" ] && \
 			    vnconfig /dev/${disk}d $xparams >/dev/null; then
 				device=/dev/${disk}d
-				echo vnconfig /dev/${disk}d $xparams
 				break	
 			fi
 		done
 		if [ x$device = x ] ; then
 			error "no available vnd device"
 		fi
-		echo xenstore-write $xpath/vnd $device
 		xenstore-write $xpath/vnd $device
 		;;
 	phy)
@@ -79,9 +77,7 @@ 1)
 		;;
 	esac
 	physical_device=$(stat -f '%r' "$device")
-	echo xenstore-write $xpath/physical-device $physical_device
 	xenstore-write $xpath/physical-device $physical_device
-	echo xenstore-write $xpath/hotplug-status connected
 	xenstore-write $xpath/hotplug-status connected
 	exit 0
 	;;
diff -r 698834eeca67 -r 3e1212856bca tools/hotplug/NetBSD/vif-bridge
--- a/tools/hotplug/NetBSD/vif-bridge	Thu Dec 01 16:01:31 2011 +0100
+++ b/tools/hotplug/NetBSD/vif-bridge	Thu Dec 01 16:01:31 2011 +0100
@@ -24,12 +24,9 @@ 1)
 	xfid=$(xenstore-read "$xpath/frontend-id")
 	xhandle=$(xenstore-read "$xpath/handle")
 	iface=$(xenstore-read "$xpath/vifname")
-	echo ifconfig $iface up
 	ifconfig $iface up
 	brconfig $xbridge add $iface
-	echo brconfig $xbridge add $iface
 	xenstore-write $xpath/hotplug-status connected
-	echo xenstore-write $xpath/hotplug-status connected
 	exit 0
 	;;
 *)
diff -r 698834eeca67 -r 3e1212856bca tools/hotplug/NetBSD/vif-ip
--- a/tools/hotplug/NetBSD/vif-ip	Thu Dec 01 16:01:31 2011 +0100
+++ b/tools/hotplug/NetBSD/vif-ip	Thu Dec 01 16:01:31 2011 +0100
@@ -24,10 +24,8 @@ 1)
 	xfid=$(xenstore-read "$xpath/frontend-id")
 	xhandle=$(xenstore-read "$xpath/handle")
 	iface=$(xenstore-read "$xpath/vifname")
-	echo ifconfig $iface $xip up
 	ifconfig $iface $xip up
 	xenstore-write $xpath/hotplug-status connected
-	echo xenstore-write $xpath/hotplug-status connected
 	exit 0
 	;;
 *)

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 15:17:24 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 15:17:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW8O0-0006Ub-Iy; Thu, 01 Dec 2011 15:17:20 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RW8Nz-0006PE-R8
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 15:17:20 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1322752574!4953754!8
X-Originating-IP: [209.85.214.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30202 invoked from network); 1 Dec 2011 15:16:40 -0000
Received: from mail-bw0-f43.google.com (HELO mail-bw0-f43.google.com)
	(209.85.214.43)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 15:16:40 -0000
Received: by mail-bw0-f43.google.com with SMTP id j4so2238541bkw.30
	for <xen-devel@lists.xensource.com>;
	Thu, 01 Dec 2011 07:16:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=au4sHXtMvJzcfbbqRAyJA101OteCNDy5UZ+rNQRkrCo=;
	b=C1sg2iElumX/0q1+TTJGsqZmwRlxH9NKn7Pds53DbJLtbnTpnSL3bFeZ9zrMYomICH
	huCq+/zPt+0egr1VacLDuEefxKOkg962uOJ27LzYv5uZycDvv0Xi8mtSrKC/u6h1sQ5i
	YOhFnqzvtEcZdfTmkWX7+ViwBTstCEj8enZaQ=
Received: by 10.204.0.80 with SMTP id 16mr7864071bka.29.1322752599891;
	Thu, 01 Dec 2011 07:16:39 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id c4sm11924270bkk.13.2011.12.01.07.16.36
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 01 Dec 2011 07:16:37 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 3e1212856bca08fda162eb27d6b9702d3f973f21
Message-Id: <3e1212856bca08fda162.1322752096@loki.upc.es>
In-Reply-To: <patchbomb.1322752087@loki.upc.es>
References: <patchbomb.1322752087@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Thu, 01 Dec 2011 16:08:16 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 09 of 11 v3] hotplug: remove debug messages from
 NetBSD hotplug scripts
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1322751691 -3600
# Node ID 3e1212856bca08fda162eb27d6b9702d3f973f21
# Parent  698834eeca6709c5569ac5c091b1dfaa17146b7f
hotplug: remove debug messages from NetBSD hotplug scripts

Remove unecessary debug messages from NetBSD hotplug scripts, left
error messages only.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 698834eeca67 -r 3e1212856bca tools/hotplug/NetBSD/block
--- a/tools/hotplug/NetBSD/block	Thu Dec 01 16:01:31 2011 +0100
+++ b/tools/hotplug/NetBSD/block	Thu Dec 01 16:01:31 2011 +0100
@@ -64,14 +64,12 @@ 1)
 			if [ "$status" = "free" ] && \
 			    vnconfig /dev/${disk}d $xparams >/dev/null; then
 				device=/dev/${disk}d
-				echo vnconfig /dev/${disk}d $xparams
 				break	
 			fi
 		done
 		if [ x$device = x ] ; then
 			error "no available vnd device"
 		fi
-		echo xenstore-write $xpath/vnd $device
 		xenstore-write $xpath/vnd $device
 		;;
 	phy)
@@ -79,9 +77,7 @@ 1)
 		;;
 	esac
 	physical_device=$(stat -f '%r' "$device")
-	echo xenstore-write $xpath/physical-device $physical_device
 	xenstore-write $xpath/physical-device $physical_device
-	echo xenstore-write $xpath/hotplug-status connected
 	xenstore-write $xpath/hotplug-status connected
 	exit 0
 	;;
diff -r 698834eeca67 -r 3e1212856bca tools/hotplug/NetBSD/vif-bridge
--- a/tools/hotplug/NetBSD/vif-bridge	Thu Dec 01 16:01:31 2011 +0100
+++ b/tools/hotplug/NetBSD/vif-bridge	Thu Dec 01 16:01:31 2011 +0100
@@ -24,12 +24,9 @@ 1)
 	xfid=$(xenstore-read "$xpath/frontend-id")
 	xhandle=$(xenstore-read "$xpath/handle")
 	iface=$(xenstore-read "$xpath/vifname")
-	echo ifconfig $iface up
 	ifconfig $iface up
 	brconfig $xbridge add $iface
-	echo brconfig $xbridge add $iface
 	xenstore-write $xpath/hotplug-status connected
-	echo xenstore-write $xpath/hotplug-status connected
 	exit 0
 	;;
 *)
diff -r 698834eeca67 -r 3e1212856bca tools/hotplug/NetBSD/vif-ip
--- a/tools/hotplug/NetBSD/vif-ip	Thu Dec 01 16:01:31 2011 +0100
+++ b/tools/hotplug/NetBSD/vif-ip	Thu Dec 01 16:01:31 2011 +0100
@@ -24,10 +24,8 @@ 1)
 	xfid=$(xenstore-read "$xpath/frontend-id")
 	xhandle=$(xenstore-read "$xpath/handle")
 	iface=$(xenstore-read "$xpath/vifname")
-	echo ifconfig $iface $xip up
 	ifconfig $iface $xip up
 	xenstore-write $xpath/hotplug-status connected
-	echo xenstore-write $xpath/hotplug-status connected
 	exit 0
 	;;
 *)

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 15:17:28 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 15:17:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW8O5-0006YC-1C; Thu, 01 Dec 2011 15:17:25 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RW8O4-0006T6-1h
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 15:17:24 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1322752574!4953754!9
X-Originating-IP: [209.85.214.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30392 invoked from network); 1 Dec 2011 15:16:44 -0000
Received: from mail-bw0-f43.google.com (HELO mail-bw0-f43.google.com)
	(209.85.214.43)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 15:16:44 -0000
Received: by mail-bw0-f43.google.com with SMTP id j4so2238541bkw.30
	for <xen-devel@lists.xensource.com>;
	Thu, 01 Dec 2011 07:16:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=Algfkb5JzzRdj0OiCy+0irMeKGzdUiij05VI1AR5KWY=;
	b=u20et2/j9jkSiXjcAOCVfuTs0S1ywRxMPT7nl+NFFIPKPesdXgAEmYV2+qvTwr0VjO
	PsFLk7ZbOSeJz5p7HedPRwmdVHi4qLMJCGG28SjV/fg1Tq5kNkSmjC3/rL8vNpJMNXat
	aOklZdh2r6/yHz/WMuN9H5SkjMK82Aqa/FQRo=
Received: by 10.204.0.82 with SMTP id 18mr7682734bka.86.1322752603742;
	Thu, 01 Dec 2011 07:16:43 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id c4sm11924270bkk.13.2011.12.01.07.16.40
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 01 Dec 2011 07:16:42 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: ef23e64c6b8b6c6a3c75e48f20d05e9a0aa15b8c
Message-Id: <ef23e64c6b8b6c6a3c75.1322752097@loki.upc.es>
In-Reply-To: <patchbomb.1322752087@loki.upc.es>
References: <patchbomb.1322752087@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Thu, 01 Dec 2011 16:08:17 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 10 of 11 v3] rc.d NetBSD: don't start
 xenbackendd by default, only when xend needs it
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1317386335 -7200
# Node ID ef23e64c6b8b6c6a3c75e48f20d05e9a0aa15b8c
# Parent  3e1212856bca08fda162eb27d6b9702d3f973f21
rc.d NetBSD: don't start xenbackendd by default, only when xend needs it.

With the move of hotplug scripts from xenbackendd to libxl
xenbackendd is no longer needed by libxl, only start it when xend is
started.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 3e1212856bca -r ef23e64c6b8b tools/hotplug/NetBSD/rc.d/xenbackendd
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/tools/hotplug/NetBSD/rc.d/xenbackendd	Fri Sep 30 14:38:55 2011 +0200
@@ -0,0 +1,27 @@
+#!/bin/sh
+#
+# PROVIDE: xenbackendd
+# REQUIRE: xencommons
+
+. /etc/rc.subr
+
+DIR=$(dirname "$0")
+. "${DIR}/xen-hotplugpath.sh"
+
+LD_LIBRARY_PATH="${LIBDIR}"
+export LD_LIBRARY_PATH PYTHONPATH
+PATH="${PATH}:${SBINDIR}"
+export PATH
+
+name="xenbackendd"
+rcvar=$name
+command="${SBINDIR}/xenbackendd"
+if [ -n "${XENBACKENDD_DEBUG}" ]; then
+	command_args="${XENBACKENDD_ARGS} -d"
+else
+	command_args="${XENBACKENDD_ARGS}"
+fi
+
+load_rc_config $name
+run_rc_command "$1"
+
diff -r 3e1212856bca -r ef23e64c6b8b tools/hotplug/NetBSD/rc.d/xencommons
--- a/tools/hotplug/NetBSD/rc.d/xencommons	Thu Dec 01 16:01:31 2011 +0100
+++ b/tools/hotplug/NetBSD/rc.d/xencommons	Fri Sep 30 14:38:55 2011 +0200
@@ -22,8 +22,6 @@ required_files="/kern/xen/privcmd"
 
 XENSTORED_PIDFILE="/var/run/xenstored.pid"
 XENCONSOLED_PIDFILE="/var/run/xenconsoled.pid"
-XENBACKENDD_PIDFILE="/var/run/xenbackendd.pid"
-#XENBACKENDD_DEBUG=1
 #XENCONSOLED_TRACE="/var/log/xen/xenconsole-trace.log"
 #XENSTORED_TRACE="/var/log/xen/xenstore-trace.log"
 
@@ -46,7 +44,7 @@ xen_startcmd()
 			XENSTORED_ROOTDIR="/var/lib/xenstored"
 		fi
 		rm -f ${XENSTORED_ROOTDIR}/tdb* >/dev/null 2>&1
-		printf "Starting xenservices: xenstored, xenconsoled, xenbackendd."
+		printf "Starting xenservices: xenstored, xenconsoled."
 		XENSTORED_ARGS=" --pid-file ${XENSTORED_PIDFILE}"
 		if [ -n "${XENSTORED_TRACE}" ]; then
 			XENSTORED_ARGS="${XENSTORED_ARGS} -T /var/log/xen/xenstored-trace.log"
@@ -58,7 +56,7 @@ xen_startcmd()
 			sleep 1
 		done
 	else
-		printf "Starting xenservices: xenconsoled, xenbackendd."
+		printf "Starting xenservices: xenconsoled."
 	fi
 
 	XENCONSOLED_ARGS=""
@@ -68,13 +66,6 @@ xen_startcmd()
 
 	${SBINDIR}/xenconsoled ${XENCONSOLED_ARGS}
 
-	XENBACKENDD_ARGS=""
-	if [ -n "${XENBACKENDD_DEBUG}" ]; then
-		XENBACKENDD_ARGS="${XENBACKENDD_ARGS} -d"
-	fi
-
-	${SBINDIR}/xenbackendd ${XENBACKENDD_ARGS}
-
 	printf "\n"
 
 	printf "Setting domain 0 name.\n"
@@ -87,8 +78,6 @@ xen_stop()
 	printf "Stopping xencommons.\n"
 	printf "WARNING: Not stopping xenstored, as it cannot be restarted.\n"
 
-	rc_pid=$(check_pidfile ${XENBACKENDD_PIDFILE} ${SBINDIR}/xenbackendd)
-	pids="$pids $rc_pid"
 	rc_pid=$(check_pidfile ${XENCONSOLED_PIDFILE} ${SBINDIR}/xenconsoled)
 	pids="$pids $rc_pid"
 
@@ -108,17 +97,12 @@ xen_status()
 		pids="$pids $xenconsoled_pid"
 	fi
 
-	xenbackend_pid=$(check_pidfile ${XENBACKENDD_PIDFILE} ${SBINDIR}/xenbackendd)
-	if test -n ${xenbackend_pid}; then
-		pids="$pids $xenbackend_pid"
-	fi
-
-	if test -n "$xenbackend_pid" -a -n "$xenconsoled_pid" -a -n "$xenstored_pid";
+	if test -n "$xenconsoled_pid" -a -n "$xenstored_pid";
 	then
 		echo "xencommons are running as pids $pids."
 		return 0
 	fi
-	if test -z "$xenbackend_pid" -a -z "$xenconsoled_pid" -a -z "$xenstored_pid";
+	if test -z "$xenconsoled_pid" -a -z "$xenstored_pid";
 	then
 		echo "xencommons are not running."
 		return 0
@@ -134,11 +118,6 @@ xen_status()
 	else
 		echo "xenconsoled is not running."
 	fi
-	if test -n $xenbackend_pid; then
-		echo "xenbackendd is running as pid $xenbackend_pid."
-	else
-		echo "xenbackendd is not running."
-	fi
 }
 
 load_rc_config $name
diff -r 3e1212856bca -r ef23e64c6b8b tools/hotplug/NetBSD/rc.d/xend
--- a/tools/hotplug/NetBSD/rc.d/xend	Thu Dec 01 16:01:31 2011 +0100
+++ b/tools/hotplug/NetBSD/rc.d/xend	Fri Sep 30 14:38:55 2011 +0200
@@ -1,7 +1,7 @@
 #!/bin/sh
 #
 # PROVIDE: xend
-# REQUIRE: xencommons
+# REQUIRE: xencommons xenbackendd
 
 . /etc/rc.subr
 

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 15:17:28 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 15:17:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW8O5-0006YC-1C; Thu, 01 Dec 2011 15:17:25 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RW8O4-0006T6-1h
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 15:17:24 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1322752574!4953754!9
X-Originating-IP: [209.85.214.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30392 invoked from network); 1 Dec 2011 15:16:44 -0000
Received: from mail-bw0-f43.google.com (HELO mail-bw0-f43.google.com)
	(209.85.214.43)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 15:16:44 -0000
Received: by mail-bw0-f43.google.com with SMTP id j4so2238541bkw.30
	for <xen-devel@lists.xensource.com>;
	Thu, 01 Dec 2011 07:16:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=Algfkb5JzzRdj0OiCy+0irMeKGzdUiij05VI1AR5KWY=;
	b=u20et2/j9jkSiXjcAOCVfuTs0S1ywRxMPT7nl+NFFIPKPesdXgAEmYV2+qvTwr0VjO
	PsFLk7ZbOSeJz5p7HedPRwmdVHi4qLMJCGG28SjV/fg1Tq5kNkSmjC3/rL8vNpJMNXat
	aOklZdh2r6/yHz/WMuN9H5SkjMK82Aqa/FQRo=
Received: by 10.204.0.82 with SMTP id 18mr7682734bka.86.1322752603742;
	Thu, 01 Dec 2011 07:16:43 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id c4sm11924270bkk.13.2011.12.01.07.16.40
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 01 Dec 2011 07:16:42 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: ef23e64c6b8b6c6a3c75e48f20d05e9a0aa15b8c
Message-Id: <ef23e64c6b8b6c6a3c75.1322752097@loki.upc.es>
In-Reply-To: <patchbomb.1322752087@loki.upc.es>
References: <patchbomb.1322752087@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Thu, 01 Dec 2011 16:08:17 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 10 of 11 v3] rc.d NetBSD: don't start
 xenbackendd by default, only when xend needs it
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1317386335 -7200
# Node ID ef23e64c6b8b6c6a3c75e48f20d05e9a0aa15b8c
# Parent  3e1212856bca08fda162eb27d6b9702d3f973f21
rc.d NetBSD: don't start xenbackendd by default, only when xend needs it.

With the move of hotplug scripts from xenbackendd to libxl
xenbackendd is no longer needed by libxl, only start it when xend is
started.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 3e1212856bca -r ef23e64c6b8b tools/hotplug/NetBSD/rc.d/xenbackendd
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/tools/hotplug/NetBSD/rc.d/xenbackendd	Fri Sep 30 14:38:55 2011 +0200
@@ -0,0 +1,27 @@
+#!/bin/sh
+#
+# PROVIDE: xenbackendd
+# REQUIRE: xencommons
+
+. /etc/rc.subr
+
+DIR=$(dirname "$0")
+. "${DIR}/xen-hotplugpath.sh"
+
+LD_LIBRARY_PATH="${LIBDIR}"
+export LD_LIBRARY_PATH PYTHONPATH
+PATH="${PATH}:${SBINDIR}"
+export PATH
+
+name="xenbackendd"
+rcvar=$name
+command="${SBINDIR}/xenbackendd"
+if [ -n "${XENBACKENDD_DEBUG}" ]; then
+	command_args="${XENBACKENDD_ARGS} -d"
+else
+	command_args="${XENBACKENDD_ARGS}"
+fi
+
+load_rc_config $name
+run_rc_command "$1"
+
diff -r 3e1212856bca -r ef23e64c6b8b tools/hotplug/NetBSD/rc.d/xencommons
--- a/tools/hotplug/NetBSD/rc.d/xencommons	Thu Dec 01 16:01:31 2011 +0100
+++ b/tools/hotplug/NetBSD/rc.d/xencommons	Fri Sep 30 14:38:55 2011 +0200
@@ -22,8 +22,6 @@ required_files="/kern/xen/privcmd"
 
 XENSTORED_PIDFILE="/var/run/xenstored.pid"
 XENCONSOLED_PIDFILE="/var/run/xenconsoled.pid"
-XENBACKENDD_PIDFILE="/var/run/xenbackendd.pid"
-#XENBACKENDD_DEBUG=1
 #XENCONSOLED_TRACE="/var/log/xen/xenconsole-trace.log"
 #XENSTORED_TRACE="/var/log/xen/xenstore-trace.log"
 
@@ -46,7 +44,7 @@ xen_startcmd()
 			XENSTORED_ROOTDIR="/var/lib/xenstored"
 		fi
 		rm -f ${XENSTORED_ROOTDIR}/tdb* >/dev/null 2>&1
-		printf "Starting xenservices: xenstored, xenconsoled, xenbackendd."
+		printf "Starting xenservices: xenstored, xenconsoled."
 		XENSTORED_ARGS=" --pid-file ${XENSTORED_PIDFILE}"
 		if [ -n "${XENSTORED_TRACE}" ]; then
 			XENSTORED_ARGS="${XENSTORED_ARGS} -T /var/log/xen/xenstored-trace.log"
@@ -58,7 +56,7 @@ xen_startcmd()
 			sleep 1
 		done
 	else
-		printf "Starting xenservices: xenconsoled, xenbackendd."
+		printf "Starting xenservices: xenconsoled."
 	fi
 
 	XENCONSOLED_ARGS=""
@@ -68,13 +66,6 @@ xen_startcmd()
 
 	${SBINDIR}/xenconsoled ${XENCONSOLED_ARGS}
 
-	XENBACKENDD_ARGS=""
-	if [ -n "${XENBACKENDD_DEBUG}" ]; then
-		XENBACKENDD_ARGS="${XENBACKENDD_ARGS} -d"
-	fi
-
-	${SBINDIR}/xenbackendd ${XENBACKENDD_ARGS}
-
 	printf "\n"
 
 	printf "Setting domain 0 name.\n"
@@ -87,8 +78,6 @@ xen_stop()
 	printf "Stopping xencommons.\n"
 	printf "WARNING: Not stopping xenstored, as it cannot be restarted.\n"
 
-	rc_pid=$(check_pidfile ${XENBACKENDD_PIDFILE} ${SBINDIR}/xenbackendd)
-	pids="$pids $rc_pid"
 	rc_pid=$(check_pidfile ${XENCONSOLED_PIDFILE} ${SBINDIR}/xenconsoled)
 	pids="$pids $rc_pid"
 
@@ -108,17 +97,12 @@ xen_status()
 		pids="$pids $xenconsoled_pid"
 	fi
 
-	xenbackend_pid=$(check_pidfile ${XENBACKENDD_PIDFILE} ${SBINDIR}/xenbackendd)
-	if test -n ${xenbackend_pid}; then
-		pids="$pids $xenbackend_pid"
-	fi
-
-	if test -n "$xenbackend_pid" -a -n "$xenconsoled_pid" -a -n "$xenstored_pid";
+	if test -n "$xenconsoled_pid" -a -n "$xenstored_pid";
 	then
 		echo "xencommons are running as pids $pids."
 		return 0
 	fi
-	if test -z "$xenbackend_pid" -a -z "$xenconsoled_pid" -a -z "$xenstored_pid";
+	if test -z "$xenconsoled_pid" -a -z "$xenstored_pid";
 	then
 		echo "xencommons are not running."
 		return 0
@@ -134,11 +118,6 @@ xen_status()
 	else
 		echo "xenconsoled is not running."
 	fi
-	if test -n $xenbackend_pid; then
-		echo "xenbackendd is running as pid $xenbackend_pid."
-	else
-		echo "xenbackendd is not running."
-	fi
 }
 
 load_rc_config $name
diff -r 3e1212856bca -r ef23e64c6b8b tools/hotplug/NetBSD/rc.d/xend
--- a/tools/hotplug/NetBSD/rc.d/xend	Thu Dec 01 16:01:31 2011 +0100
+++ b/tools/hotplug/NetBSD/rc.d/xend	Fri Sep 30 14:38:55 2011 +0200
@@ -1,7 +1,7 @@
 #!/bin/sh
 #
 # PROVIDE: xend
-# REQUIRE: xencommons
+# REQUIRE: xencommons xenbackendd
 
 . /etc/rc.subr
 

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 15:17:33 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 15:17:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW8O8-0006ad-FD; Thu, 01 Dec 2011 15:17:28 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RW8O6-0006Ux-Bg
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 15:17:26 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1322752574!4953754!10
X-Originating-IP: [209.85.214.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30555 invoked from network); 1 Dec 2011 15:16:46 -0000
Received: from mail-bw0-f43.google.com (HELO mail-bw0-f43.google.com)
	(209.85.214.43)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 15:16:46 -0000
Received: by mail-bw0-f43.google.com with SMTP id j4so2238541bkw.30
	for <xen-devel@lists.xensource.com>;
	Thu, 01 Dec 2011 07:16:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=KcjIlnj99Gold/tsvdgIwv4l1cYk0WjoWdFRozGrEsA=;
	b=PfT5uCwK5ztuE6XzDsaB/b0P5e0lahRknFearG0PuX4MQIDHcqu41R9qlPWOFwrzrl
	EV9KEXjn8VWn0bwIGILhe8s6aTLuxrrDVbjfmplUuabjpDwVHsBj8dUvFBrmoqyO1X0M
	j4HK/WuOPD7TtkX+UDJqiKQIDf9tILZj3ZGNw=
Received: by 10.204.149.216 with SMTP id u24mr7652696bkv.73.1322752606530;
	Thu, 01 Dec 2011 07:16:46 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id c4sm11924270bkk.13.2011.12.01.07.16.43
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 01 Dec 2011 07:16:45 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 274fa4aea2a30fb82228513f969d7cb807813bb8
Message-Id: <274fa4aea2a30fb82228.1322752098@loki.upc.es>
In-Reply-To: <patchbomb.1322752087@loki.upc.es>
References: <patchbomb.1322752087@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Thu, 01 Dec 2011 16:08:18 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 11 of 11 v3] libxl: fix incorrect log message in
 libxl_domain_destroy
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1322751691 -3600
# Node ID 274fa4aea2a30fb82228513f969d7cb807813bb8
# Parent  ef23e64c6b8b6c6a3c75e48f20d05e9a0aa15b8c
libxl: fix incorrect log message in libxl_domain_destroy

Fix a log message that was referring to libxl_devices_dispose instead
of libxl__devices_destroy.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r ef23e64c6b8b -r 274fa4aea2a3 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Fri Sep 30 14:38:55 2011 +0200
+++ b/tools/libxl/libxl.c	Thu Dec 01 16:01:31 2011 +0100
@@ -768,7 +768,7 @@ int libxl_domain_destroy(libxl_ctx *ctx,
         libxl__qmp_cleanup(&gc, domid);
     }
     if (libxl__devices_destroy(&gc, domid, force) < 0)
-        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "libxl_devices_dispose failed for %d", domid);
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "libxl__devices_destroy failed for %d", domid);
 
     vm_path = libxl__xs_read(&gc, XBT_NULL, libxl__sprintf(&gc, "%s/vm", dom_path));
     if (vm_path)

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 15:17:33 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 15:17:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW8O8-0006ad-FD; Thu, 01 Dec 2011 15:17:28 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RW8O6-0006Ux-Bg
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 15:17:26 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1322752574!4953754!10
X-Originating-IP: [209.85.214.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30555 invoked from network); 1 Dec 2011 15:16:46 -0000
Received: from mail-bw0-f43.google.com (HELO mail-bw0-f43.google.com)
	(209.85.214.43)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 15:16:46 -0000
Received: by mail-bw0-f43.google.com with SMTP id j4so2238541bkw.30
	for <xen-devel@lists.xensource.com>;
	Thu, 01 Dec 2011 07:16:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=KcjIlnj99Gold/tsvdgIwv4l1cYk0WjoWdFRozGrEsA=;
	b=PfT5uCwK5ztuE6XzDsaB/b0P5e0lahRknFearG0PuX4MQIDHcqu41R9qlPWOFwrzrl
	EV9KEXjn8VWn0bwIGILhe8s6aTLuxrrDVbjfmplUuabjpDwVHsBj8dUvFBrmoqyO1X0M
	j4HK/WuOPD7TtkX+UDJqiKQIDf9tILZj3ZGNw=
Received: by 10.204.149.216 with SMTP id u24mr7652696bkv.73.1322752606530;
	Thu, 01 Dec 2011 07:16:46 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id c4sm11924270bkk.13.2011.12.01.07.16.43
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 01 Dec 2011 07:16:45 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 274fa4aea2a30fb82228513f969d7cb807813bb8
Message-Id: <274fa4aea2a30fb82228.1322752098@loki.upc.es>
In-Reply-To: <patchbomb.1322752087@loki.upc.es>
References: <patchbomb.1322752087@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Thu, 01 Dec 2011 16:08:18 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 11 of 11 v3] libxl: fix incorrect log message in
 libxl_domain_destroy
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1322751691 -3600
# Node ID 274fa4aea2a30fb82228513f969d7cb807813bb8
# Parent  ef23e64c6b8b6c6a3c75e48f20d05e9a0aa15b8c
libxl: fix incorrect log message in libxl_domain_destroy

Fix a log message that was referring to libxl_devices_dispose instead
of libxl__devices_destroy.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r ef23e64c6b8b -r 274fa4aea2a3 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Fri Sep 30 14:38:55 2011 +0200
+++ b/tools/libxl/libxl.c	Thu Dec 01 16:01:31 2011 +0100
@@ -768,7 +768,7 @@ int libxl_domain_destroy(libxl_ctx *ctx,
         libxl__qmp_cleanup(&gc, domid);
     }
     if (libxl__devices_destroy(&gc, domid, force) < 0)
-        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "libxl_devices_dispose failed for %d", domid);
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "libxl__devices_destroy failed for %d", domid);
 
     vm_path = libxl__xs_read(&gc, XBT_NULL, libxl__sprintf(&gc, "%s/vm", dom_path));
     if (vm_path)

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 15:18:04 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 15: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.xensource.com>)
	id 1RW8Of-0006wi-TM; Thu, 01 Dec 2011 15:18:01 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RW8Oe-0006vF-9E
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 15:18:00 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-8.tower-27.messagelabs.com!1322752537!54493675!1
X-Originating-IP: [208.97.132.207]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4yMDcgPT4gMTU1MDU=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30629 invoked from network); 1 Dec 2011 15:15:38 -0000
Received: from caiajhbdccah.dreamhost.com (HELO homiemail-a18.g.dreamhost.com)
	(208.97.132.207) by server-8.tower-27.messagelabs.com with SMTP;
	1 Dec 2011 15:15:38 -0000
Received: from homiemail-a18.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a18.g.dreamhost.com (Postfix) with ESMTP id 0F1AC250074;
	Thu,  1 Dec 2011 07:17:24 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=fxhJrHw49RrrnjGyo6MG8cBKvQaWWdJ2WFuJV/AZTqN+
	6dVkblJk2T6Ff/uNB4hmrJTgjzeq2ctgFCBTrmdnpm63+ziO4WSlY14V8QFiUtL9
	dOBnZL+C2st/vUYjfCVLUAuGt73Scqgxfjqg6g9VF3vSFq1aqKg9Iz8AfXiWj48=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:reply-to
	:mime-version:content-type:content-transfer-encoding; s=
	lagarcavilla.org; bh=H0e4rvYQctrqMBXXOX9nAPwIK04=; b=Vq8p+sb56DV
	ufodG/ygdCbWP4g2IZWSqoOKj3iJDrbggnArbY5dcwkqk1/DLOlj3Vcaybl87ZgE
	o9+37KJE5vVSVTjyINj6RQhXm+TlLz6eGcNr6tgsZlUH1XKIbtS88hO0Q5lLu9Pt
	oxx8zKzwzXfThK1UopcC1J0wOtIcPENg=
Received: from webmail.lagarcavilla.org (ahfbbjcaiaae.dreamhost.com
	[75.119.208.4]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a18.g.dreamhost.com (Postfix) with ESMTPA id 6196A250069; 
	Thu,  1 Dec 2011 07:17:23 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP; Thu, 1 Dec 2011 07:17:23 -0800
Message-ID: <782967b2dc26ac23e527e33839e8336f.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <mailman.3014.1322742146.12970.xen-devel@lists.xensource.com>
References: <mailman.3014.1322742146.12970.xen-devel@lists.xensource.com>
Date: Thu, 1 Dec 2011 07:17:23 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com,
 olaf@aepfle.de
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Subject: Re: [Xen-devel] [PATCH 2 of 4] xenpaging: use wait queues
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> Date: Thu, 01 Dec 2011 12:09:18 +0100
> From: Olaf Hering <olaf@aepfle.de>
> To: xen-devel@lists.xensource.com
> Subject: [Xen-devel] [PATCH 2 of 4] xenpaging: use wait queues
> Message-ID: <8147822efdee65d1f5b9.1322737758@probook.site>
> Content-Type: text/plain; charset="us-ascii"
>
> # HG changeset patch
> # User Olaf Hering <olaf@aepfle.de>
> # Date 1322737507 -3600
> # Node ID 8147822efdee65d1f5b94656ab2032aedb76979f
> # Parent  612f69531fd15cf59c58404f6e4762733a9a268c
> xenpaging: use wait queues
>
> Use a wait queue to put a guest vcpu to sleep while the requested gfn is
> in paging state. This adds missing p2m_mem_paging_populate() calls to
> some callers of the new get_gfn* variants, which would crash now
> because they get an invalid mfn. It also fixes guest crashes due to
> unexpected returns from do_memory_op because copy_to/from_guest ran into
> a paged gfn. Now those places will always get a valid mfn.
>
> Since each gfn could be requested by several guest vcpus at the same
> time a queue of paged gfns is maintained. Each vcpu will be attached to
> that queue. Once p2m_mem_paging_resume restored the gfn the waiting
> vcpus will resume execution.
>
> There is untested code in p2m_mem_paging_init_queue() to allow cpu
> hotplug. Since each vcpu may wait on a different gfn there have to be as
> many queues as vcpus. But xl vcpu-set does not seem to work right now,
> so this code path cant be excercised right now.
>
>
> Signed-off-by: Olaf Hering <olaf@aepfle.de>
>
> diff -r 612f69531fd1 -r 8147822efdee xen/arch/x86/hvm/hvm.c
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -454,6 +454,8 @@ int hvm_domain_initialise(struct domain
>      spin_lock_init(&d->arch.hvm_domain.irq_lock);
>      spin_lock_init(&d->arch.hvm_domain.uc_lock);
>
> +    spin_lock_init(&d->arch.hvm_domain.gfn_lock);
> +

Probably gfn_lock should be replaced with a name a bit more expressive.
That notwithstanding, it seems this lock only gets used in the mm layer.
If so, it should be declared as an mm_lock_t in arch/x86/mm-locks.h, and
subject to ordering constraints.

Both gfn_lock and the list of wait queues could be collapsed in a single
struct, so as to decrease pressure on the size of struct domain.

>      INIT_LIST_HEAD(&d->arch.hvm_domain.msixtbl_list);
>      spin_lock_init(&d->arch.hvm_domain.msixtbl_list_lock);
>
> diff -r 612f69531fd1 -r 8147822efdee xen/arch/x86/mm/p2m.c
> --- a/xen/arch/x86/mm/p2m.c
> +++ b/xen/arch/x86/mm/p2m.c
> @@ -30,6 +30,7 @@
>  #include <asm/p2m.h>
>  #include <asm/hvm/vmx/vmx.h> /* ept_p2m_init() */
>  #include <xen/iommu.h>
> +#include <xen/wait.h>
>  #include <asm/mem_event.h>
>  #include <public/mem_event.h>
>  #include <asm/mem_sharing.h>
> @@ -144,6 +145,182 @@ void p2m_change_entry_type_global(struct
>      p2m_unlock(p2m);
>  }
>
> +#ifdef __x86_64__
> +struct p2m_mem_paging_queue {
> +    struct list_head list;
> +    struct waitqueue_head wq;
> +    unsigned long gfn;
> +    unsigned short waiters;
> +    unsigned short woken;
> +    unsigned short index;
> +};
> +
> +struct p2m_mem_paging_queue_head {
> +    struct list_head list;
> +    unsigned int max;
> +};
> +
> +int p2m_mem_paging_init_queue(struct domain *d, unsigned int max)
> +{
> +    struct p2m_mem_paging_queue_head *h;
> +    struct p2m_mem_paging_queue *q;
> +    unsigned int i, nr;
> +    int ret = 0;
> +
> +    spin_lock(&d->arch.hvm_domain.gfn_lock);
> +
> +    if (!d->arch.hvm_domain.gfn_queue) {
> +        ret = -ENOMEM;
> +        h = xzalloc(struct p2m_mem_paging_queue_head);
> +        if (!h) {
> +            domain_crash(d);
> +            goto out;
> +        }
> +
> +        INIT_LIST_HEAD(&h->list);
> +        nr = max;
> +    } else {
> +        h = d->arch.hvm_domain.gfn_queue;
> +        if (max <= h->max)
> +            goto out;
> +        nr = max - h->max;
> +    }
> +
> +    ret = -ENOMEM;
> +    q = xzalloc_array(struct p2m_mem_paging_queue, nr);
> +    if (!q) {
> +        if (!d->arch.hvm_domain.gfn_queue)
> +            xfree(h);
> +        domain_crash(d);
> +        goto out;
> +    }
> +
> +    for (i = 0; i < nr; i++) {
> +        init_waitqueue_head(&q[i].wq);
> +        INIT_LIST_HEAD(&q[i].list);
> +        q[i].index = h->max + i + 1;
> +        list_add_tail(&q[i].list, &h->list);
> +    }
> +
> +    h->max = max;
> +    d->arch.hvm_domain.gfn_queue = h;
> +    ret = 0;
> +
> +out:
> +    spin_unlock(&d->arch.hvm_domain.gfn_lock);
> +    return ret;
> +}
> +
> +static struct p2m_mem_paging_queue *p2m_mem_paging_get_queue(struct
> domain *d, unsigned long gfn)
> +{
> +    struct p2m_mem_paging_queue_head *h;
> +    struct p2m_mem_paging_queue *q, *q_match, *q_free;
> +
> +    h = d->arch.hvm_domain.gfn_queue;
> +    q_match = q_free = NULL;
> +
> +    spin_lock(&d->arch.hvm_domain.gfn_lock);
> +
> +    list_for_each_entry(q, &h->list, list) {
"Hashing" the gfn ( i.e. gfn & ((1 << order_of_vcpus) - 1) ) and starting
the linear scan from there would shortcut the common case of finding a
queued gfn.

Checking the p2m type of the gfn for paging in would make the search O(1)
for the case in which the gfn is not queued.

> +        if (q->gfn == gfn) {
> +            q_match = q;
> +            break;
> +        }
> +        if (!q_free && !q->waiters)
> +            q_free = q;
> +    }
> +
> +    if (!q_match && q_free)
> +        q_match = q_free;
> +
> +    if (q_match) {
> +        if (q_match->woken)
> +            printk("wq woken for gfn %u:%u %lx %u %u %u\n",
> current->domain->domain_id, current->vcpu_id, gfn, q_match->index,
> q_match->woken, q_match->waiters);
> +        q_match->waiters++;
> +        q_match->gfn = gfn;
> +    }
> +
> +    if (!q_match)
> +        printk("No wq_get for gfn %u:%u %lx\n",
> current->domain->domain_id, current->vcpu_id, gfn);
> +
> +    spin_unlock(&d->arch.hvm_domain.gfn_lock);
> +    return q_match;
> +}
> +
> +static void p2m_mem_paging_put_queue(struct domain *d, struct
> p2m_mem_paging_queue *q_match)
> +{
> +    spin_lock(&d->arch.hvm_domain.gfn_lock);
> +
> +    if (q_match->waiters == 0)
> +        printk("wq_put no waiters, gfn %u:%u %lx %u\n",
> current->domain->domain_id, current->vcpu_id, q_match->gfn,
> q_match->woken);
> +    else if (--q_match->waiters == 0)
> +        q_match->gfn = q_match->woken = 0;;
> +
> +    spin_unlock(&d->arch.hvm_domain.gfn_lock);
> +}
> +
> +static void p2m_mem_paging_wake_queue(struct domain *d, unsigned long
> gfn)
> +{
> +    struct p2m_mem_paging_queue_head *h;
> +    struct p2m_mem_paging_queue *q, *q_match = NULL;
> +
> +    spin_lock(&d->arch.hvm_domain.gfn_lock);
> +
> +    h = d->arch.hvm_domain.gfn_queue;
Same here, re big O of searching the gfn.

> +    list_for_each_entry(q, &h->list, list) {
> +        if (q->gfn == gfn) {
> +            q_match = q;
> +            break;
> +        }
> +    }
> +    if (q_match) {
> +        if (q_match->woken || q_match->waiters == 0)
> +            printk("Wrong wake for gfn %u:%u %p %lx %u %u\n",
> current->domain->domain_id, current->vcpu_id, q_match, gfn,
> q_match->woken, q_match->waiters);
> +        q_match->woken++;
> +        wake_up_all(&q_match->wq);
> +    }
> +    spin_unlock(&d->arch.hvm_domain.gfn_lock);
> +}
> +
> +/* Returns 0 if the gfn is still paged */
> +static int p2m_mem_paging_get_entry(mfn_t *mfn,
> +               struct p2m_domain *p2m, unsigned long gfn,
> +               p2m_type_t *t, p2m_access_t *a, p2m_query_t q,
> +               unsigned int *page_order)
> +{
> +    *mfn = p2m->get_entry(p2m, gfn, t, a, q, page_order);
This will be called in the wake up routine, and it will be racy against
any concurrent p2m updates.

> +
> +    return p2m_is_paging(*t) ? 0 : 1;
> +}
> +
> +/* Go to sleep in case of guest access */
> +static void p2m_mem_paging_wait(mfn_t *mfn,
> +                    struct p2m_domain *p2m, unsigned long gfn,
> +                    p2m_type_t *t, p2m_access_t *a, p2m_query_t q,
> +                    unsigned int *page_order)
> +{
> +    struct p2m_mem_paging_queue *pmpq;
> +
> +    /* Return p2mt as is in case of query */
> +    if ( q == p2m_query )
> +        return;
> +    /* Foreign domains can not go to sleep */
> +    if ( current->domain != p2m->domain )
> +        return;
> +
> +    pmpq = p2m_mem_paging_get_queue(p2m->domain, gfn);
> +    if ( !pmpq )
> +        return;
> +
> +    /* Populate the page once */
> +    if ( *t == p2m_ram_paging_out || *t == p2m_ram_paged )
> +        p2m_mem_paging_populate(p2m->domain, gfn);
> +
> +    wait_event(pmpq->wq, p2m_mem_paging_get_entry(mfn, p2m, gfn, t, a, q,
> page_order));
> +    p2m_mem_paging_put_queue(p2m->domain, pmpq);
> +}
> +#endif
> +
>  mfn_t get_gfn_type_access(struct p2m_domain *p2m, unsigned long gfn,
>                      p2m_type_t *t, p2m_access_t *a, p2m_query_t q,
>                      unsigned int *page_order)
> @@ -161,6 +338,11 @@ mfn_t get_gfn_type_access(struct p2m_dom
>      mfn = p2m->get_entry(p2m, gfn, t, a, q, page_order);
>
>  #ifdef __x86_64__
> +    if ( unlikely(p2m_is_paging(*t)) )
> +        p2m_mem_paging_wait(&mfn, p2m, gfn, t, a, q, page_order);
> +#endif
> +
> +#ifdef __x86_64__
>      if ( q == p2m_unshare && p2m_is_shared(*t) )
>      {
>          ASSERT(!p2m_is_nestedp2m(p2m));
> @@ -914,54 +1096,42 @@ void p2m_mem_paging_drop_page(struct dom
>  void p2m_mem_paging_populate(struct domain *d, unsigned long gfn)
>  {
>      struct vcpu *v = current;
> -    mem_event_request_t req;
> +    mem_event_request_t req = { .type = MEM_EVENT_TYPE_PAGING, .gfn = gfn
> };
>      p2m_type_t p2mt;
>      p2m_access_t a;
>      mfn_t mfn;
>      struct p2m_domain *p2m = p2m_get_hostp2m(d);
> +    int put_request = 0;
>
>      /* Check that there's space on the ring for this request */
>      if ( mem_event_check_ring(d, &d->mem_event->paging) )
>          return;
>
> -    memset(&req, 0, sizeof(req));
> -    req.type = MEM_EVENT_TYPE_PAGING;
> -
>      /* Fix p2m mapping */
>      p2m_lock(p2m);
>      mfn = p2m->get_entry(p2m, gfn, &p2mt, &a, p2m_query, NULL);
> -    /* Allow only nominated or evicted pages to enter page-in path */
> -    if ( p2mt == p2m_ram_paging_out || p2mt == p2m_ram_paged )
> -    {
> -        /* Evict will fail now, tag this request for pager */
> -        if ( p2mt == p2m_ram_paging_out )
> -            req.flags |= MEM_EVENT_FLAG_EVICT_FAIL;
> +    /* Forward the state only if gfn is in page-out path */
> +    if ( p2mt == p2m_ram_paging_out || p2mt == p2m_ram_paged ) {
> +        /* Ignore foreign requests to allow mmap in pager */
> +        if ( mfn_valid(mfn) && p2mt == p2m_ram_paging_out && v->domain ==
> d ) {
> +            /* Restore gfn because it is needed by guest before evict */
> +            set_p2m_entry(p2m, gfn, mfn, PAGE_ORDER_4K,
> +                       paging_mode_log_dirty(d) ? p2m_ram_logdirty :
> p2m_ram_rw, a);
No event here to tell the pager to cancel its work?

You're not just adding wait queues, but also short-cutting the state
machine of paging, which, whilst delicate, works quite well right now. You
should definitely split that into two patches if possible.

And please keep in mind that there are pagers other than xenpaging, so
interface churn is a big headache for everyone, if unavoidable.

> +        } else {
> +            set_p2m_entry(p2m, gfn, mfn, PAGE_ORDER_4K,
> p2m_ram_paging_in_start, a);
> +            put_request = 1;
> +        }
> +        /* Evict will fail now, the pager has to try another gfn */
>
> -        set_p2m_entry(p2m, gfn, mfn, PAGE_ORDER_4K,
> p2m_ram_paging_in_start, a);
>          audit_p2m(p2m, 1);
>      }
>      p2m_unlock(p2m);
>
> -    /* Pause domain if request came from guest and gfn has paging type */
> -    if (  p2m_is_paging(p2mt) && v->domain == d )
> -    {
> -        vcpu_pause_nosync(v);
> -        req.flags |= MEM_EVENT_FLAG_VCPU_PAUSED;
> -    }
> -    /* No need to inform pager if the gfn is not in the page-out path */
> -    else if ( p2mt != p2m_ram_paging_out && p2mt != p2m_ram_paged )
> -    {
> -        /* gfn is already on its way back and vcpu is not paused */
> +    /* One request per gfn, guest vcpus go to sleep, foreigners try again
> */
> +    if ( put_request )
> +        mem_event_put_request(d, &d->mem_event->paging, &req);
> +    else
>          mem_event_put_req_producers(d, &d->mem_event->paging);
These (mem_event_put_req_producers, foreign_producers) are the kinds of
things that are really confusing in the ring management side right now.

Thanks, good stuff
Andres
> -        return;
> -    }
> -
> -    /* Send request to pager */
> -    req.gfn = gfn;
> -    req.p2mt = p2mt;
> -    req.vcpu_id = v->vcpu_id;
> -
> -    mem_event_put_request(d, &d->mem_event->paging, &req);
>  }
>
>  /**
> @@ -1062,12 +1232,11 @@ void p2m_mem_paging_resume(struct domain
>          p2m_unlock(p2m);
>      }
>
> -    /* Unpause domain */
> -    if ( rsp.flags & MEM_EVENT_FLAG_VCPU_PAUSED )
> -        vcpu_unpause(d->vcpu[rsp.vcpu_id]);
> -
>      /* Wake vcpus waiting for room in the ring */
>      mem_event_wake_requesters(&d->mem_event->paging);
> +
> +    /* Unpause all vcpus that were paused because the gfn was paged */
> +    p2m_mem_paging_wake_queue(d, rsp.gfn);
>  }
>
>  void p2m_mem_access_check(unsigned long gpa, bool_t gla_valid, unsigned
> long gla,
> diff -r 612f69531fd1 -r 8147822efdee xen/common/domctl.c
> --- a/xen/common/domctl.c
> +++ b/xen/common/domctl.c
> @@ -547,6 +547,9 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domc
>                  goto maxvcpu_out;
>          }
>
> +        if ( p2m_mem_paging_init_queue(d, max) )
> +            goto maxvcpu_out;
> +
>          ret = 0;
>
>      maxvcpu_out:
> diff -r 612f69531fd1 -r 8147822efdee xen/include/asm-x86/hvm/domain.h
> --- a/xen/include/asm-x86/hvm/domain.h
> +++ b/xen/include/asm-x86/hvm/domain.h
> @@ -91,6 +91,9 @@ struct hvm_domain {
>
>      struct viridian_domain viridian;
>
> +    spinlock_t                        gfn_lock;
> +    struct p2m_mem_paging_queue_head *gfn_queue;
> +
>      bool_t                 hap_enabled;
>      bool_t                 mem_sharing_enabled;
>      bool_t                 qemu_mapcache_invalidate;
> diff -r 612f69531fd1 -r 8147822efdee xen/include/asm-x86/p2m.h
> --- a/xen/include/asm-x86/p2m.h
> +++ b/xen/include/asm-x86/p2m.h
> @@ -468,6 +468,8 @@ p2m_pod_offline_or_broken_replace(struct
>  /* Modify p2m table for shared gfn */
>  int set_shared_p2m_entry(struct domain *d, unsigned long gfn, mfn_t mfn);
>
> +/* Initialize per-gfn wait queue */
> +int p2m_mem_paging_init_queue(struct domain *d, unsigned int max);
>  /* Check if a nominated gfn is valid to be paged out */
>  int p2m_mem_paging_nominate(struct domain *d, unsigned long gfn);
>  /* Evict a frame */
>
>
>
> ------------------------------
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>
>
> End of Xen-devel Digest, Vol 82, Issue 13
> *****************************************
>



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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 15:18:04 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 15: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.xensource.com>)
	id 1RW8Of-0006wi-TM; Thu, 01 Dec 2011 15:18:01 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RW8Oe-0006vF-9E
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 15:18:00 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-8.tower-27.messagelabs.com!1322752537!54493675!1
X-Originating-IP: [208.97.132.207]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4yMDcgPT4gMTU1MDU=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30629 invoked from network); 1 Dec 2011 15:15:38 -0000
Received: from caiajhbdccah.dreamhost.com (HELO homiemail-a18.g.dreamhost.com)
	(208.97.132.207) by server-8.tower-27.messagelabs.com with SMTP;
	1 Dec 2011 15:15:38 -0000
Received: from homiemail-a18.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a18.g.dreamhost.com (Postfix) with ESMTP id 0F1AC250074;
	Thu,  1 Dec 2011 07:17:24 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=fxhJrHw49RrrnjGyo6MG8cBKvQaWWdJ2WFuJV/AZTqN+
	6dVkblJk2T6Ff/uNB4hmrJTgjzeq2ctgFCBTrmdnpm63+ziO4WSlY14V8QFiUtL9
	dOBnZL+C2st/vUYjfCVLUAuGt73Scqgxfjqg6g9VF3vSFq1aqKg9Iz8AfXiWj48=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:reply-to
	:mime-version:content-type:content-transfer-encoding; s=
	lagarcavilla.org; bh=H0e4rvYQctrqMBXXOX9nAPwIK04=; b=Vq8p+sb56DV
	ufodG/ygdCbWP4g2IZWSqoOKj3iJDrbggnArbY5dcwkqk1/DLOlj3Vcaybl87ZgE
	o9+37KJE5vVSVTjyINj6RQhXm+TlLz6eGcNr6tgsZlUH1XKIbtS88hO0Q5lLu9Pt
	oxx8zKzwzXfThK1UopcC1J0wOtIcPENg=
Received: from webmail.lagarcavilla.org (ahfbbjcaiaae.dreamhost.com
	[75.119.208.4]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a18.g.dreamhost.com (Postfix) with ESMTPA id 6196A250069; 
	Thu,  1 Dec 2011 07:17:23 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP; Thu, 1 Dec 2011 07:17:23 -0800
Message-ID: <782967b2dc26ac23e527e33839e8336f.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <mailman.3014.1322742146.12970.xen-devel@lists.xensource.com>
References: <mailman.3014.1322742146.12970.xen-devel@lists.xensource.com>
Date: Thu, 1 Dec 2011 07:17:23 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com,
 olaf@aepfle.de
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Subject: Re: [Xen-devel] [PATCH 2 of 4] xenpaging: use wait queues
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> Date: Thu, 01 Dec 2011 12:09:18 +0100
> From: Olaf Hering <olaf@aepfle.de>
> To: xen-devel@lists.xensource.com
> Subject: [Xen-devel] [PATCH 2 of 4] xenpaging: use wait queues
> Message-ID: <8147822efdee65d1f5b9.1322737758@probook.site>
> Content-Type: text/plain; charset="us-ascii"
>
> # HG changeset patch
> # User Olaf Hering <olaf@aepfle.de>
> # Date 1322737507 -3600
> # Node ID 8147822efdee65d1f5b94656ab2032aedb76979f
> # Parent  612f69531fd15cf59c58404f6e4762733a9a268c
> xenpaging: use wait queues
>
> Use a wait queue to put a guest vcpu to sleep while the requested gfn is
> in paging state. This adds missing p2m_mem_paging_populate() calls to
> some callers of the new get_gfn* variants, which would crash now
> because they get an invalid mfn. It also fixes guest crashes due to
> unexpected returns from do_memory_op because copy_to/from_guest ran into
> a paged gfn. Now those places will always get a valid mfn.
>
> Since each gfn could be requested by several guest vcpus at the same
> time a queue of paged gfns is maintained. Each vcpu will be attached to
> that queue. Once p2m_mem_paging_resume restored the gfn the waiting
> vcpus will resume execution.
>
> There is untested code in p2m_mem_paging_init_queue() to allow cpu
> hotplug. Since each vcpu may wait on a different gfn there have to be as
> many queues as vcpus. But xl vcpu-set does not seem to work right now,
> so this code path cant be excercised right now.
>
>
> Signed-off-by: Olaf Hering <olaf@aepfle.de>
>
> diff -r 612f69531fd1 -r 8147822efdee xen/arch/x86/hvm/hvm.c
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -454,6 +454,8 @@ int hvm_domain_initialise(struct domain
>      spin_lock_init(&d->arch.hvm_domain.irq_lock);
>      spin_lock_init(&d->arch.hvm_domain.uc_lock);
>
> +    spin_lock_init(&d->arch.hvm_domain.gfn_lock);
> +

Probably gfn_lock should be replaced with a name a bit more expressive.
That notwithstanding, it seems this lock only gets used in the mm layer.
If so, it should be declared as an mm_lock_t in arch/x86/mm-locks.h, and
subject to ordering constraints.

Both gfn_lock and the list of wait queues could be collapsed in a single
struct, so as to decrease pressure on the size of struct domain.

>      INIT_LIST_HEAD(&d->arch.hvm_domain.msixtbl_list);
>      spin_lock_init(&d->arch.hvm_domain.msixtbl_list_lock);
>
> diff -r 612f69531fd1 -r 8147822efdee xen/arch/x86/mm/p2m.c
> --- a/xen/arch/x86/mm/p2m.c
> +++ b/xen/arch/x86/mm/p2m.c
> @@ -30,6 +30,7 @@
>  #include <asm/p2m.h>
>  #include <asm/hvm/vmx/vmx.h> /* ept_p2m_init() */
>  #include <xen/iommu.h>
> +#include <xen/wait.h>
>  #include <asm/mem_event.h>
>  #include <public/mem_event.h>
>  #include <asm/mem_sharing.h>
> @@ -144,6 +145,182 @@ void p2m_change_entry_type_global(struct
>      p2m_unlock(p2m);
>  }
>
> +#ifdef __x86_64__
> +struct p2m_mem_paging_queue {
> +    struct list_head list;
> +    struct waitqueue_head wq;
> +    unsigned long gfn;
> +    unsigned short waiters;
> +    unsigned short woken;
> +    unsigned short index;
> +};
> +
> +struct p2m_mem_paging_queue_head {
> +    struct list_head list;
> +    unsigned int max;
> +};
> +
> +int p2m_mem_paging_init_queue(struct domain *d, unsigned int max)
> +{
> +    struct p2m_mem_paging_queue_head *h;
> +    struct p2m_mem_paging_queue *q;
> +    unsigned int i, nr;
> +    int ret = 0;
> +
> +    spin_lock(&d->arch.hvm_domain.gfn_lock);
> +
> +    if (!d->arch.hvm_domain.gfn_queue) {
> +        ret = -ENOMEM;
> +        h = xzalloc(struct p2m_mem_paging_queue_head);
> +        if (!h) {
> +            domain_crash(d);
> +            goto out;
> +        }
> +
> +        INIT_LIST_HEAD(&h->list);
> +        nr = max;
> +    } else {
> +        h = d->arch.hvm_domain.gfn_queue;
> +        if (max <= h->max)
> +            goto out;
> +        nr = max - h->max;
> +    }
> +
> +    ret = -ENOMEM;
> +    q = xzalloc_array(struct p2m_mem_paging_queue, nr);
> +    if (!q) {
> +        if (!d->arch.hvm_domain.gfn_queue)
> +            xfree(h);
> +        domain_crash(d);
> +        goto out;
> +    }
> +
> +    for (i = 0; i < nr; i++) {
> +        init_waitqueue_head(&q[i].wq);
> +        INIT_LIST_HEAD(&q[i].list);
> +        q[i].index = h->max + i + 1;
> +        list_add_tail(&q[i].list, &h->list);
> +    }
> +
> +    h->max = max;
> +    d->arch.hvm_domain.gfn_queue = h;
> +    ret = 0;
> +
> +out:
> +    spin_unlock(&d->arch.hvm_domain.gfn_lock);
> +    return ret;
> +}
> +
> +static struct p2m_mem_paging_queue *p2m_mem_paging_get_queue(struct
> domain *d, unsigned long gfn)
> +{
> +    struct p2m_mem_paging_queue_head *h;
> +    struct p2m_mem_paging_queue *q, *q_match, *q_free;
> +
> +    h = d->arch.hvm_domain.gfn_queue;
> +    q_match = q_free = NULL;
> +
> +    spin_lock(&d->arch.hvm_domain.gfn_lock);
> +
> +    list_for_each_entry(q, &h->list, list) {
"Hashing" the gfn ( i.e. gfn & ((1 << order_of_vcpus) - 1) ) and starting
the linear scan from there would shortcut the common case of finding a
queued gfn.

Checking the p2m type of the gfn for paging in would make the search O(1)
for the case in which the gfn is not queued.

> +        if (q->gfn == gfn) {
> +            q_match = q;
> +            break;
> +        }
> +        if (!q_free && !q->waiters)
> +            q_free = q;
> +    }
> +
> +    if (!q_match && q_free)
> +        q_match = q_free;
> +
> +    if (q_match) {
> +        if (q_match->woken)
> +            printk("wq woken for gfn %u:%u %lx %u %u %u\n",
> current->domain->domain_id, current->vcpu_id, gfn, q_match->index,
> q_match->woken, q_match->waiters);
> +        q_match->waiters++;
> +        q_match->gfn = gfn;
> +    }
> +
> +    if (!q_match)
> +        printk("No wq_get for gfn %u:%u %lx\n",
> current->domain->domain_id, current->vcpu_id, gfn);
> +
> +    spin_unlock(&d->arch.hvm_domain.gfn_lock);
> +    return q_match;
> +}
> +
> +static void p2m_mem_paging_put_queue(struct domain *d, struct
> p2m_mem_paging_queue *q_match)
> +{
> +    spin_lock(&d->arch.hvm_domain.gfn_lock);
> +
> +    if (q_match->waiters == 0)
> +        printk("wq_put no waiters, gfn %u:%u %lx %u\n",
> current->domain->domain_id, current->vcpu_id, q_match->gfn,
> q_match->woken);
> +    else if (--q_match->waiters == 0)
> +        q_match->gfn = q_match->woken = 0;;
> +
> +    spin_unlock(&d->arch.hvm_domain.gfn_lock);
> +}
> +
> +static void p2m_mem_paging_wake_queue(struct domain *d, unsigned long
> gfn)
> +{
> +    struct p2m_mem_paging_queue_head *h;
> +    struct p2m_mem_paging_queue *q, *q_match = NULL;
> +
> +    spin_lock(&d->arch.hvm_domain.gfn_lock);
> +
> +    h = d->arch.hvm_domain.gfn_queue;
Same here, re big O of searching the gfn.

> +    list_for_each_entry(q, &h->list, list) {
> +        if (q->gfn == gfn) {
> +            q_match = q;
> +            break;
> +        }
> +    }
> +    if (q_match) {
> +        if (q_match->woken || q_match->waiters == 0)
> +            printk("Wrong wake for gfn %u:%u %p %lx %u %u\n",
> current->domain->domain_id, current->vcpu_id, q_match, gfn,
> q_match->woken, q_match->waiters);
> +        q_match->woken++;
> +        wake_up_all(&q_match->wq);
> +    }
> +    spin_unlock(&d->arch.hvm_domain.gfn_lock);
> +}
> +
> +/* Returns 0 if the gfn is still paged */
> +static int p2m_mem_paging_get_entry(mfn_t *mfn,
> +               struct p2m_domain *p2m, unsigned long gfn,
> +               p2m_type_t *t, p2m_access_t *a, p2m_query_t q,
> +               unsigned int *page_order)
> +{
> +    *mfn = p2m->get_entry(p2m, gfn, t, a, q, page_order);
This will be called in the wake up routine, and it will be racy against
any concurrent p2m updates.

> +
> +    return p2m_is_paging(*t) ? 0 : 1;
> +}
> +
> +/* Go to sleep in case of guest access */
> +static void p2m_mem_paging_wait(mfn_t *mfn,
> +                    struct p2m_domain *p2m, unsigned long gfn,
> +                    p2m_type_t *t, p2m_access_t *a, p2m_query_t q,
> +                    unsigned int *page_order)
> +{
> +    struct p2m_mem_paging_queue *pmpq;
> +
> +    /* Return p2mt as is in case of query */
> +    if ( q == p2m_query )
> +        return;
> +    /* Foreign domains can not go to sleep */
> +    if ( current->domain != p2m->domain )
> +        return;
> +
> +    pmpq = p2m_mem_paging_get_queue(p2m->domain, gfn);
> +    if ( !pmpq )
> +        return;
> +
> +    /* Populate the page once */
> +    if ( *t == p2m_ram_paging_out || *t == p2m_ram_paged )
> +        p2m_mem_paging_populate(p2m->domain, gfn);
> +
> +    wait_event(pmpq->wq, p2m_mem_paging_get_entry(mfn, p2m, gfn, t, a, q,
> page_order));
> +    p2m_mem_paging_put_queue(p2m->domain, pmpq);
> +}
> +#endif
> +
>  mfn_t get_gfn_type_access(struct p2m_domain *p2m, unsigned long gfn,
>                      p2m_type_t *t, p2m_access_t *a, p2m_query_t q,
>                      unsigned int *page_order)
> @@ -161,6 +338,11 @@ mfn_t get_gfn_type_access(struct p2m_dom
>      mfn = p2m->get_entry(p2m, gfn, t, a, q, page_order);
>
>  #ifdef __x86_64__
> +    if ( unlikely(p2m_is_paging(*t)) )
> +        p2m_mem_paging_wait(&mfn, p2m, gfn, t, a, q, page_order);
> +#endif
> +
> +#ifdef __x86_64__
>      if ( q == p2m_unshare && p2m_is_shared(*t) )
>      {
>          ASSERT(!p2m_is_nestedp2m(p2m));
> @@ -914,54 +1096,42 @@ void p2m_mem_paging_drop_page(struct dom
>  void p2m_mem_paging_populate(struct domain *d, unsigned long gfn)
>  {
>      struct vcpu *v = current;
> -    mem_event_request_t req;
> +    mem_event_request_t req = { .type = MEM_EVENT_TYPE_PAGING, .gfn = gfn
> };
>      p2m_type_t p2mt;
>      p2m_access_t a;
>      mfn_t mfn;
>      struct p2m_domain *p2m = p2m_get_hostp2m(d);
> +    int put_request = 0;
>
>      /* Check that there's space on the ring for this request */
>      if ( mem_event_check_ring(d, &d->mem_event->paging) )
>          return;
>
> -    memset(&req, 0, sizeof(req));
> -    req.type = MEM_EVENT_TYPE_PAGING;
> -
>      /* Fix p2m mapping */
>      p2m_lock(p2m);
>      mfn = p2m->get_entry(p2m, gfn, &p2mt, &a, p2m_query, NULL);
> -    /* Allow only nominated or evicted pages to enter page-in path */
> -    if ( p2mt == p2m_ram_paging_out || p2mt == p2m_ram_paged )
> -    {
> -        /* Evict will fail now, tag this request for pager */
> -        if ( p2mt == p2m_ram_paging_out )
> -            req.flags |= MEM_EVENT_FLAG_EVICT_FAIL;
> +    /* Forward the state only if gfn is in page-out path */
> +    if ( p2mt == p2m_ram_paging_out || p2mt == p2m_ram_paged ) {
> +        /* Ignore foreign requests to allow mmap in pager */
> +        if ( mfn_valid(mfn) && p2mt == p2m_ram_paging_out && v->domain ==
> d ) {
> +            /* Restore gfn because it is needed by guest before evict */
> +            set_p2m_entry(p2m, gfn, mfn, PAGE_ORDER_4K,
> +                       paging_mode_log_dirty(d) ? p2m_ram_logdirty :
> p2m_ram_rw, a);
No event here to tell the pager to cancel its work?

You're not just adding wait queues, but also short-cutting the state
machine of paging, which, whilst delicate, works quite well right now. You
should definitely split that into two patches if possible.

And please keep in mind that there are pagers other than xenpaging, so
interface churn is a big headache for everyone, if unavoidable.

> +        } else {
> +            set_p2m_entry(p2m, gfn, mfn, PAGE_ORDER_4K,
> p2m_ram_paging_in_start, a);
> +            put_request = 1;
> +        }
> +        /* Evict will fail now, the pager has to try another gfn */
>
> -        set_p2m_entry(p2m, gfn, mfn, PAGE_ORDER_4K,
> p2m_ram_paging_in_start, a);
>          audit_p2m(p2m, 1);
>      }
>      p2m_unlock(p2m);
>
> -    /* Pause domain if request came from guest and gfn has paging type */
> -    if (  p2m_is_paging(p2mt) && v->domain == d )
> -    {
> -        vcpu_pause_nosync(v);
> -        req.flags |= MEM_EVENT_FLAG_VCPU_PAUSED;
> -    }
> -    /* No need to inform pager if the gfn is not in the page-out path */
> -    else if ( p2mt != p2m_ram_paging_out && p2mt != p2m_ram_paged )
> -    {
> -        /* gfn is already on its way back and vcpu is not paused */
> +    /* One request per gfn, guest vcpus go to sleep, foreigners try again
> */
> +    if ( put_request )
> +        mem_event_put_request(d, &d->mem_event->paging, &req);
> +    else
>          mem_event_put_req_producers(d, &d->mem_event->paging);
These (mem_event_put_req_producers, foreign_producers) are the kinds of
things that are really confusing in the ring management side right now.

Thanks, good stuff
Andres
> -        return;
> -    }
> -
> -    /* Send request to pager */
> -    req.gfn = gfn;
> -    req.p2mt = p2mt;
> -    req.vcpu_id = v->vcpu_id;
> -
> -    mem_event_put_request(d, &d->mem_event->paging, &req);
>  }
>
>  /**
> @@ -1062,12 +1232,11 @@ void p2m_mem_paging_resume(struct domain
>          p2m_unlock(p2m);
>      }
>
> -    /* Unpause domain */
> -    if ( rsp.flags & MEM_EVENT_FLAG_VCPU_PAUSED )
> -        vcpu_unpause(d->vcpu[rsp.vcpu_id]);
> -
>      /* Wake vcpus waiting for room in the ring */
>      mem_event_wake_requesters(&d->mem_event->paging);
> +
> +    /* Unpause all vcpus that were paused because the gfn was paged */
> +    p2m_mem_paging_wake_queue(d, rsp.gfn);
>  }
>
>  void p2m_mem_access_check(unsigned long gpa, bool_t gla_valid, unsigned
> long gla,
> diff -r 612f69531fd1 -r 8147822efdee xen/common/domctl.c
> --- a/xen/common/domctl.c
> +++ b/xen/common/domctl.c
> @@ -547,6 +547,9 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domc
>                  goto maxvcpu_out;
>          }
>
> +        if ( p2m_mem_paging_init_queue(d, max) )
> +            goto maxvcpu_out;
> +
>          ret = 0;
>
>      maxvcpu_out:
> diff -r 612f69531fd1 -r 8147822efdee xen/include/asm-x86/hvm/domain.h
> --- a/xen/include/asm-x86/hvm/domain.h
> +++ b/xen/include/asm-x86/hvm/domain.h
> @@ -91,6 +91,9 @@ struct hvm_domain {
>
>      struct viridian_domain viridian;
>
> +    spinlock_t                        gfn_lock;
> +    struct p2m_mem_paging_queue_head *gfn_queue;
> +
>      bool_t                 hap_enabled;
>      bool_t                 mem_sharing_enabled;
>      bool_t                 qemu_mapcache_invalidate;
> diff -r 612f69531fd1 -r 8147822efdee xen/include/asm-x86/p2m.h
> --- a/xen/include/asm-x86/p2m.h
> +++ b/xen/include/asm-x86/p2m.h
> @@ -468,6 +468,8 @@ p2m_pod_offline_or_broken_replace(struct
>  /* Modify p2m table for shared gfn */
>  int set_shared_p2m_entry(struct domain *d, unsigned long gfn, mfn_t mfn);
>
> +/* Initialize per-gfn wait queue */
> +int p2m_mem_paging_init_queue(struct domain *d, unsigned int max);
>  /* Check if a nominated gfn is valid to be paged out */
>  int p2m_mem_paging_nominate(struct domain *d, unsigned long gfn);
>  /* Evict a frame */
>
>
>
> ------------------------------
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>
>
> End of Xen-devel Digest, Vol 82, Issue 13
> *****************************************
>



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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 15:19:43 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 15: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.xensource.com>)
	id 1RW8QA-0007es-PV; Thu, 01 Dec 2011 15:19:34 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RW8Q9-0007bS-1A
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 15:19:33 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1322752732!274486!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU2Nw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1137 invoked from network); 1 Dec 2011 15:18:52 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 15:18:52 -0000
X-IronPort-AV: E=Sophos;i="4.71,278,1320624000"; 
   d="scan'208";a="9234013"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Dec 2011 15:18:51 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.161]) by
	LONPMAILMX01.citrite.net ([10.30.203.162]) with mapi; Thu, 1 Dec 2011
	15:18:51 +0000
From: Paul Durrant <Paul.Durrant@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Thu, 1 Dec 2011 15:18:58 +0000
Thread-Topic: [Xen-devel] [PATCH] Add code to track the address of the VM
	generation id buffer across a
Thread-Index: AcywNQc8RivhEGvpQnW/Yp6g34dGxQAB05Kw
Message-ID: <291EDFCB1E9E224A99088639C4762022B5988E512B@LONPMAILBOX01.citrite.net>
References: <94a17182f386c8bb414e.1322686717@cosworth.uk.xensource.com>
	<20111130221419.GA16651@andromeda.dapyr.net>
	<291EDFCB1E9E224A99088639C4762022B5988E50D4@LONPMAILBOX01.citrite.net>
	<1322729947.31810.151.camel@zakaz.uk.xensource.com>
	<291EDFCB1E9E224A99088639C4762022B5988E50EA@LONPMAILBOX01.citrite.net>
	<1322733621.31810.176.camel@zakaz.uk.xensource.com>
	<291EDFCB1E9E224A99088639C4762022B5988E50FE@LONPMAILBOX01.citrite.net>
	<1322749508.31810.215.camel@zakaz.uk.xensource.com>
In-Reply-To: <1322749508.31810.215.camel@zakaz.uk.xensource.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] Add code to track the address of the VM
 generation id buffer across a
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> -----Original Message-----
> From: Ian Campbell
> Sent: 01 December 2011 14:25
> To: Paul Durrant
> Cc: Konrad Rzeszutek Wilk; xen-devel@lists.xensource.com
> Subject: RE: [Xen-devel] [PATCH] Add code to track the address of
> the VM generation id buffer across a
> 
> On Thu, 2011-12-01 at 11:54 +0000, Paul Durrant wrote:
> > Would the following be sufficient?
> >
> >   Paul
> >
> > diff -r 62ff6a318c5d docs/man/xl.cfg.pod.5
> > --- a/docs/man/xl.cfg.pod.5     Wed Nov 30 16:59:58 2011 -0800
> > +++ b/docs/man/xl.cfg.pod.5     Thu Dec 01 11:52:58 2011 +0000
> > @@ -484,6 +484,12 @@ of Xen) within a Xen guest or to support
> which
> > uses hardware virtualisation extensions (e.g. Windows XP
> > compatibility mode on more modern Windows OS).
> >
> > +=item B<generation_id=NUMBER>
> > +
> > +This value will be exposed inside the guest at an address which
> can
> > +be determined by evaluating the ADDR package of an ACPI device
> with
> > +_CID "VM_Gen_Counter".
> 
> Belongs more in the "Support for Paravirtualisation of HVM Guests"
> section, which is just below? The "Processor and Platform Features"
> is more about things which are optional (at least in theory) on real
> systems.
> 

Ok.

> Since the semantics of the number itself are up to the toolstack and
> this toolstack defers this requirement up to the user it should
> probably also say something along the lines of:
> 
>         The semantics of this value are guest dependent and it is up
> to
>         the user to ensure those semantics are met.
> 

Ok, I'll add something to that effect.

  Paul

> (even better would be to implement something meaningful in xl,
> obviously)
> 


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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 15:19:43 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 15: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.xensource.com>)
	id 1RW8QA-0007es-PV; Thu, 01 Dec 2011 15:19:34 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RW8Q9-0007bS-1A
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 15:19:33 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1322752732!274486!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU2Nw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1137 invoked from network); 1 Dec 2011 15:18:52 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 15:18:52 -0000
X-IronPort-AV: E=Sophos;i="4.71,278,1320624000"; 
   d="scan'208";a="9234013"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Dec 2011 15:18:51 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.161]) by
	LONPMAILMX01.citrite.net ([10.30.203.162]) with mapi; Thu, 1 Dec 2011
	15:18:51 +0000
From: Paul Durrant <Paul.Durrant@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Thu, 1 Dec 2011 15:18:58 +0000
Thread-Topic: [Xen-devel] [PATCH] Add code to track the address of the VM
	generation id buffer across a
Thread-Index: AcywNQc8RivhEGvpQnW/Yp6g34dGxQAB05Kw
Message-ID: <291EDFCB1E9E224A99088639C4762022B5988E512B@LONPMAILBOX01.citrite.net>
References: <94a17182f386c8bb414e.1322686717@cosworth.uk.xensource.com>
	<20111130221419.GA16651@andromeda.dapyr.net>
	<291EDFCB1E9E224A99088639C4762022B5988E50D4@LONPMAILBOX01.citrite.net>
	<1322729947.31810.151.camel@zakaz.uk.xensource.com>
	<291EDFCB1E9E224A99088639C4762022B5988E50EA@LONPMAILBOX01.citrite.net>
	<1322733621.31810.176.camel@zakaz.uk.xensource.com>
	<291EDFCB1E9E224A99088639C4762022B5988E50FE@LONPMAILBOX01.citrite.net>
	<1322749508.31810.215.camel@zakaz.uk.xensource.com>
In-Reply-To: <1322749508.31810.215.camel@zakaz.uk.xensource.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] Add code to track the address of the VM
 generation id buffer across a
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> -----Original Message-----
> From: Ian Campbell
> Sent: 01 December 2011 14:25
> To: Paul Durrant
> Cc: Konrad Rzeszutek Wilk; xen-devel@lists.xensource.com
> Subject: RE: [Xen-devel] [PATCH] Add code to track the address of
> the VM generation id buffer across a
> 
> On Thu, 2011-12-01 at 11:54 +0000, Paul Durrant wrote:
> > Would the following be sufficient?
> >
> >   Paul
> >
> > diff -r 62ff6a318c5d docs/man/xl.cfg.pod.5
> > --- a/docs/man/xl.cfg.pod.5     Wed Nov 30 16:59:58 2011 -0800
> > +++ b/docs/man/xl.cfg.pod.5     Thu Dec 01 11:52:58 2011 +0000
> > @@ -484,6 +484,12 @@ of Xen) within a Xen guest or to support
> which
> > uses hardware virtualisation extensions (e.g. Windows XP
> > compatibility mode on more modern Windows OS).
> >
> > +=item B<generation_id=NUMBER>
> > +
> > +This value will be exposed inside the guest at an address which
> can
> > +be determined by evaluating the ADDR package of an ACPI device
> with
> > +_CID "VM_Gen_Counter".
> 
> Belongs more in the "Support for Paravirtualisation of HVM Guests"
> section, which is just below? The "Processor and Platform Features"
> is more about things which are optional (at least in theory) on real
> systems.
> 

Ok.

> Since the semantics of the number itself are up to the toolstack and
> this toolstack defers this requirement up to the user it should
> probably also say something along the lines of:
> 
>         The semantics of this value are guest dependent and it is up
> to
>         the user to ensure those semantics are met.
> 

Ok, I'll add something to that effect.

  Paul

> (even better would be to implement something meaningful in xl,
> obviously)
> 


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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 15:26:39 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 15:26:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW8Wi-0000Ma-9U; Thu, 01 Dec 2011 15:26:20 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RW8Wg-0000MR-JG
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 15:26:18 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-6.tower-21.messagelabs.com!1322753137!6410670!1
X-Originating-IP: [208.97.132.74]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi43NCA9PiAxNTcwNQ==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23210 invoked from network); 1 Dec 2011 15:25:38 -0000
Received: from caiajhbdcahe.dreamhost.com (HELO homiemail-a15.g.dreamhost.com)
	(208.97.132.74) by server-6.tower-21.messagelabs.com with SMTP;
	1 Dec 2011 15:25:38 -0000
Received: from homiemail-a15.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a15.g.dreamhost.com (Postfix) with ESMTP id 4CA6776C06F;
	Thu,  1 Dec 2011 07:25:14 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=LdydYeGSuuY09M4kek6R0rUZpEiTfymzQev1vIRn8K4c
	cz86qr2hYZnDWZxR5IcDo3epzIJ76nNzHajI9JCyVc/KLzxQ/O7W9vyt7nfBq4z6
	e3LY16Qzk7B4zHQ7HGxcW27HK3gK1CAW+m/64UdvPOi7tXoXVS9E773yMLmsBjk=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=lCbLh41EydUQ+HO96//R8o7fW/M=; b=BF90PVPG
	2joTY9Jl9RCtwNfmGf3ClrGugD7ScK2tc4TFWVfIuufCy/X31SunHf0X1c/6CIAF
	r9qOrOrFL+W7BNZcKl33nfflxIG8m+6f3+c3TWmC2t2YleERNFuALS8PQdKWRZuo
	kitydW+RrGRMdGvaWwnNNTEtAT6+TOfBsqE=
Received: from webmail.lagarcavilla.org (ahfbbjcaiaae.dreamhost.com
	[75.119.208.4]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a15.g.dreamhost.com (Postfix) with ESMTPA id D377876C065; 
	Thu,  1 Dec 2011 07:25:13 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP; Thu, 1 Dec 2011 07:25:14 -0800
Message-ID: <457bf805a9709501746d2073fcd9082d.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20111201145103.GA13045@aepfle.de>
References: <patchbomb.1322603709@xdev.gridcentric.ca>
	<43dc614d543cdf84189d.1322603711@xdev.gridcentric.ca>
	<20111201145103.GA13045@aepfle.de>
Date: Thu, 1 Dec 2011 07:25:14 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Olaf Hering" <olaf@aepfle.de>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, ian.campbell@citrix.com,
	andres@gridcentric.ca, tim@xen.org, keir.xen@gmail.com,
	jbeulich@suse.com, ian.jackson@citrix.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 2 of 5] Improve ring management for memory
 events. Do not lose guest events
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> On Tue, Nov 29, Andres Lagar-Cavilla wrote:
>
>> @@ -133,31 +185,95 @@ static int mem_event_disable(struct mem_
>>      return 0;
>>  }
>>
>> -void mem_event_put_request(struct domain *d, struct mem_event_domain
>> *med, mem_event_request_t *req)
>> +static inline int mem_event_ring_free(struct domain *d, struct
>> mem_event_domain *med)
>>  {
>> +    int free_requests;
>> +
>> +    free_requests = RING_FREE_REQUESTS(&med->front_ring);
>> +    if ( unlikely(free_requests < d->max_vcpus) )
>> +    {
>> +        /* This may happen during normal operation (hopefully not
>> often). */
>> +        gdprintk(XENLOG_INFO, "mem_event request slots for domain %d:
>> %d\n",
>> +                               d->domain_id, free_requests);
>> +    }
>> +
>> +    return free_requests;
>> +}
>> +
>> +/* Return values
>> + * zero: success
>> + * -ENOSYS: no ring
>> + * -EAGAIN: ring is full and the event has not been transmitted.
>> + *          Only foreign vcpu's get EAGAIN
>> + * -EBUSY: guest vcpu has been paused due to ring congestion
>> + */
>> +int mem_event_put_request(struct domain *d, struct mem_event_domain
>> *med, mem_event_request_t *req)
>> +{
>> +    int ret = 0;
>> +    int foreign = (d != current->domain);
>
>> +    /*
>> +     * We ensure that each vcpu can put at least *one* event -- because
>> some
>> +     * events are not repeatable, such as dropping a page.  This will
>> ensure no
>> +     * vCPU is left with an event that they must place on the ring, but
>> cannot.
>> +     * They will be paused after the event is placed.
>> +     * See large comment below in mem_event_unpause_vcpus().
>> +     */
>> +    if ( !foreign && mem_event_ring_free(d, med) < d->max_vcpus )
>> +    {
>> +        mem_event_mark_and_pause(current, med);
>> +        ret = -EBUSY;
>> +    }
>>
>>      mem_event_ring_unlock(med);
>>
>>      notify_via_xen_event_channel(d, med->xen_port);
>> +
>> +    return ret;
>
>
> What will happen if the guest has more vcpus than r->nr_ents in the ring
> buffer? To me it looks like no event can be placed into the ring and
> -EBUSY is returned instead.

MAX_HVM_VCPUS sits at 128 right now. Haven't compile checked, but that
probably means we would need a two page ring. And then, when 1024-cpu
hosts arrive and we grow MAX_HVM_VCPUS, we grow the ring size again.

Or, we could limit the constraint to the number of online vcpus, which
would get somewhat tricky for vcpu hot-plugging.

I can fix that separately, once there is a decision on which way to go re
ring management.
Andres

>
> Olaf
>



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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 15:26:39 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 15:26:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW8Wi-0000Ma-9U; Thu, 01 Dec 2011 15:26:20 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RW8Wg-0000MR-JG
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 15:26:18 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-6.tower-21.messagelabs.com!1322753137!6410670!1
X-Originating-IP: [208.97.132.74]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi43NCA9PiAxNTcwNQ==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23210 invoked from network); 1 Dec 2011 15:25:38 -0000
Received: from caiajhbdcahe.dreamhost.com (HELO homiemail-a15.g.dreamhost.com)
	(208.97.132.74) by server-6.tower-21.messagelabs.com with SMTP;
	1 Dec 2011 15:25:38 -0000
Received: from homiemail-a15.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a15.g.dreamhost.com (Postfix) with ESMTP id 4CA6776C06F;
	Thu,  1 Dec 2011 07:25:14 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=LdydYeGSuuY09M4kek6R0rUZpEiTfymzQev1vIRn8K4c
	cz86qr2hYZnDWZxR5IcDo3epzIJ76nNzHajI9JCyVc/KLzxQ/O7W9vyt7nfBq4z6
	e3LY16Qzk7B4zHQ7HGxcW27HK3gK1CAW+m/64UdvPOi7tXoXVS9E773yMLmsBjk=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=lCbLh41EydUQ+HO96//R8o7fW/M=; b=BF90PVPG
	2joTY9Jl9RCtwNfmGf3ClrGugD7ScK2tc4TFWVfIuufCy/X31SunHf0X1c/6CIAF
	r9qOrOrFL+W7BNZcKl33nfflxIG8m+6f3+c3TWmC2t2YleERNFuALS8PQdKWRZuo
	kitydW+RrGRMdGvaWwnNNTEtAT6+TOfBsqE=
Received: from webmail.lagarcavilla.org (ahfbbjcaiaae.dreamhost.com
	[75.119.208.4]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a15.g.dreamhost.com (Postfix) with ESMTPA id D377876C065; 
	Thu,  1 Dec 2011 07:25:13 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP; Thu, 1 Dec 2011 07:25:14 -0800
Message-ID: <457bf805a9709501746d2073fcd9082d.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20111201145103.GA13045@aepfle.de>
References: <patchbomb.1322603709@xdev.gridcentric.ca>
	<43dc614d543cdf84189d.1322603711@xdev.gridcentric.ca>
	<20111201145103.GA13045@aepfle.de>
Date: Thu, 1 Dec 2011 07:25:14 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Olaf Hering" <olaf@aepfle.de>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, ian.campbell@citrix.com,
	andres@gridcentric.ca, tim@xen.org, keir.xen@gmail.com,
	jbeulich@suse.com, ian.jackson@citrix.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 2 of 5] Improve ring management for memory
 events. Do not lose guest events
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> On Tue, Nov 29, Andres Lagar-Cavilla wrote:
>
>> @@ -133,31 +185,95 @@ static int mem_event_disable(struct mem_
>>      return 0;
>>  }
>>
>> -void mem_event_put_request(struct domain *d, struct mem_event_domain
>> *med, mem_event_request_t *req)
>> +static inline int mem_event_ring_free(struct domain *d, struct
>> mem_event_domain *med)
>>  {
>> +    int free_requests;
>> +
>> +    free_requests = RING_FREE_REQUESTS(&med->front_ring);
>> +    if ( unlikely(free_requests < d->max_vcpus) )
>> +    {
>> +        /* This may happen during normal operation (hopefully not
>> often). */
>> +        gdprintk(XENLOG_INFO, "mem_event request slots for domain %d:
>> %d\n",
>> +                               d->domain_id, free_requests);
>> +    }
>> +
>> +    return free_requests;
>> +}
>> +
>> +/* Return values
>> + * zero: success
>> + * -ENOSYS: no ring
>> + * -EAGAIN: ring is full and the event has not been transmitted.
>> + *          Only foreign vcpu's get EAGAIN
>> + * -EBUSY: guest vcpu has been paused due to ring congestion
>> + */
>> +int mem_event_put_request(struct domain *d, struct mem_event_domain
>> *med, mem_event_request_t *req)
>> +{
>> +    int ret = 0;
>> +    int foreign = (d != current->domain);
>
>> +    /*
>> +     * We ensure that each vcpu can put at least *one* event -- because
>> some
>> +     * events are not repeatable, such as dropping a page.  This will
>> ensure no
>> +     * vCPU is left with an event that they must place on the ring, but
>> cannot.
>> +     * They will be paused after the event is placed.
>> +     * See large comment below in mem_event_unpause_vcpus().
>> +     */
>> +    if ( !foreign && mem_event_ring_free(d, med) < d->max_vcpus )
>> +    {
>> +        mem_event_mark_and_pause(current, med);
>> +        ret = -EBUSY;
>> +    }
>>
>>      mem_event_ring_unlock(med);
>>
>>      notify_via_xen_event_channel(d, med->xen_port);
>> +
>> +    return ret;
>
>
> What will happen if the guest has more vcpus than r->nr_ents in the ring
> buffer? To me it looks like no event can be placed into the ring and
> -EBUSY is returned instead.

MAX_HVM_VCPUS sits at 128 right now. Haven't compile checked, but that
probably means we would need a two page ring. And then, when 1024-cpu
hosts arrive and we grow MAX_HVM_VCPUS, we grow the ring size again.

Or, we could limit the constraint to the number of online vcpus, which
would get somewhat tricky for vcpu hot-plugging.

I can fix that separately, once there is a decision on which way to go re
ring management.
Andres

>
> Olaf
>



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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 15:27:23 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 15: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.xensource.com>)
	id 1RW8X9-0000OJ-N0; Thu, 01 Dec 2011 15:26:47 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RW8Wo-0000Mh-7J
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 15:26:46 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-10.tower-174.messagelabs.com!1322753145!3880992!1
X-Originating-IP: [208.97.132.202]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4yMDIgPT4gMTYwMTY=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2953 invoked from network); 1 Dec 2011 15:25:46 -0000
Received: from caiajhbdccac.dreamhost.com (HELO homiemail-a18.g.dreamhost.com)
	(208.97.132.202) by server-10.tower-174.messagelabs.com with SMTP;
	1 Dec 2011 15:25:46 -0000
Received: from homiemail-a18.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a18.g.dreamhost.com (Postfix) with ESMTP id 0B9F6250079;
	Thu,  1 Dec 2011 07:25:45 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=ZkHKjWgCBa+T40JRJc7j1dh4FZCChB6zjogIFodleyr4
	Wnpv45Wm0XLfcIbkbhQeWGxeTfLpEeGmC/tq92n/UXBhqv9vclXHfZRPGafrM129
	C4LZu3QmFdP+8u2HXrKSCQpfziVXkGwAi2YzNf7sQfMR+hIr2IaZfFJGlKg8nzg=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=zzceSG78PQ+A9kQ/huVmZ42gHtU=; b=JOj+sX8g
	fm63Qrtd1oepcO5J4BKlnfuZplREcAsJZC5RCCK15pfqI3eNK/RpZ7mrU/OxXObv
	x6WtZJZLQzboOKwT/+LVN4pJ8pX7Cd7dupAvhroAg/HcT6O/IJkoSB6o8kRuD1NP
	ZR0XfNgXM5c1H0l2aHFsSuhIRrcdyE+veG0=
Received: from webmail.lagarcavilla.org (ahfbbjcaiaae.dreamhost.com
	[75.119.208.4]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a18.g.dreamhost.com (Postfix) with ESMTPA id 6957C25006C; 
	Thu,  1 Dec 2011 07:25:44 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP; Thu, 1 Dec 2011 07:25:44 -0800
Message-ID: <82ee527c78c76c7b4139ee7cd0bf820b.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20111201150957.GF61203@ocelot.phlegethon.org>
References: <patchbomb.1322598097@xdev.gridcentric.ca>
	<20111201150957.GF61203@ocelot.phlegethon.org>
Date: Thu, 1 Dec 2011 07:25:44 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Tim Deegan" <tim@xen.org>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, ian.campbell@citrix.com,
	andres@gridcentric.ca, keir.xen@gmail.com, jbeulich@suse.com,
	ian.jackson@citrix.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 0 of 9] MM Bug fixes
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> At 15:21 -0500 on 29 Nov (1322580097), Andres Lagar-Cavilla wrote:
>> This patch series includes a number of bug fixes previously
>> submitted, or newly found, for the mm layer.
>>
>> Patches 1 and 7 are tool patches, cc'ed tool maintainers. Everything
>> else is hypervisors-x86-mm.
>
> Patch 4 I applied but then reverted -- the 32-bit version doesn't
>         even compile.
> Patch 5 has been commented on separately.
> Patch 8 I'll leave until the full patch that fixes all instances.
>
> I've applied the others, with minor modifications to #2 (to use more
> consistent names with the rest of shadow code) and #6 (tidying up the
> domctl handler, in particular using rcu_lock_remote_target_domain_by_id()
> instead of open-coding the domain checks).
Thanks, will take care of broken ones shortly.
Andres
>
> Cheers,
>
> Tim.
>



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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 15:27:23 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 15: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.xensource.com>)
	id 1RW8X9-0000OJ-N0; Thu, 01 Dec 2011 15:26:47 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RW8Wo-0000Mh-7J
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 15:26:46 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-10.tower-174.messagelabs.com!1322753145!3880992!1
X-Originating-IP: [208.97.132.202]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4yMDIgPT4gMTYwMTY=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2953 invoked from network); 1 Dec 2011 15:25:46 -0000
Received: from caiajhbdccac.dreamhost.com (HELO homiemail-a18.g.dreamhost.com)
	(208.97.132.202) by server-10.tower-174.messagelabs.com with SMTP;
	1 Dec 2011 15:25:46 -0000
Received: from homiemail-a18.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a18.g.dreamhost.com (Postfix) with ESMTP id 0B9F6250079;
	Thu,  1 Dec 2011 07:25:45 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=ZkHKjWgCBa+T40JRJc7j1dh4FZCChB6zjogIFodleyr4
	Wnpv45Wm0XLfcIbkbhQeWGxeTfLpEeGmC/tq92n/UXBhqv9vclXHfZRPGafrM129
	C4LZu3QmFdP+8u2HXrKSCQpfziVXkGwAi2YzNf7sQfMR+hIr2IaZfFJGlKg8nzg=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=zzceSG78PQ+A9kQ/huVmZ42gHtU=; b=JOj+sX8g
	fm63Qrtd1oepcO5J4BKlnfuZplREcAsJZC5RCCK15pfqI3eNK/RpZ7mrU/OxXObv
	x6WtZJZLQzboOKwT/+LVN4pJ8pX7Cd7dupAvhroAg/HcT6O/IJkoSB6o8kRuD1NP
	ZR0XfNgXM5c1H0l2aHFsSuhIRrcdyE+veG0=
Received: from webmail.lagarcavilla.org (ahfbbjcaiaae.dreamhost.com
	[75.119.208.4]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a18.g.dreamhost.com (Postfix) with ESMTPA id 6957C25006C; 
	Thu,  1 Dec 2011 07:25:44 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP; Thu, 1 Dec 2011 07:25:44 -0800
Message-ID: <82ee527c78c76c7b4139ee7cd0bf820b.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20111201150957.GF61203@ocelot.phlegethon.org>
References: <patchbomb.1322598097@xdev.gridcentric.ca>
	<20111201150957.GF61203@ocelot.phlegethon.org>
Date: Thu, 1 Dec 2011 07:25:44 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Tim Deegan" <tim@xen.org>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, ian.campbell@citrix.com,
	andres@gridcentric.ca, keir.xen@gmail.com, jbeulich@suse.com,
	ian.jackson@citrix.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 0 of 9] MM Bug fixes
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> At 15:21 -0500 on 29 Nov (1322580097), Andres Lagar-Cavilla wrote:
>> This patch series includes a number of bug fixes previously
>> submitted, or newly found, for the mm layer.
>>
>> Patches 1 and 7 are tool patches, cc'ed tool maintainers. Everything
>> else is hypervisors-x86-mm.
>
> Patch 4 I applied but then reverted -- the 32-bit version doesn't
>         even compile.
> Patch 5 has been commented on separately.
> Patch 8 I'll leave until the full patch that fixes all instances.
>
> I've applied the others, with minor modifications to #2 (to use more
> consistent names with the rest of shadow code) and #6 (tidying up the
> domctl handler, in particular using rcu_lock_remote_target_domain_by_id()
> instead of open-coding the domain checks).
Thanks, will take care of broken ones shortly.
Andres
>
> Cheers,
>
> Tim.
>



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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 15:37:34 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 15:37:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW8hN-0000t0-0V; Thu, 01 Dec 2011 15:37:21 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RW8hL-0000st-HB
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 15:37:19 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-6.tower-27.messagelabs.com!1322753769!49128977!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNDUxMTM=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNDUxMTM=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5109 invoked from network); 1 Dec 2011 15:36:10 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-6.tower-27.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 1 Dec 2011 15:36:10 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1322753804; l=1484;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=LBeXKMpFHnQvgM96R3zunBdDsdA=;
	b=UFaxpa8mZyrmH+1zmiqPLjzXzfnSf4gU2+r0i0IHQmDSe4grY8JNQEcOr8RXVRCZ2Gc
	+X9PLxh2yRVePRjo7rXf6KL5SAJNp8Nwh4qwJFC2lCDZaT5zlzw2BraGpONvF9Pjg24QF
	kbS/ZZG/tjmzJbnL9yZT3pLNG7LERrEHtk0=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/ll2c7pE6jG
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-080-213.pools.arcor-ip.net [84.57.80.213])
	by post.strato.de (mrclete mo8) (RZmta 26.10 AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id f037aanB1DQERA ;
	Thu, 1 Dec 2011 16:36:36 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id B919E18637; Thu,  1 Dec 2011 16:36:35 +0100 (CET)
Date: Thu, 1 Dec 2011 16:36:35 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20111201153635.GA14132@aepfle.de>
References: <patchbomb.1322603709@xdev.gridcentric.ca>
	<43dc614d543cdf84189d.1322603711@xdev.gridcentric.ca>
	<20111130125821.GB15723@aepfle.de>
	<86f622285e1ceb506d0bdbae7cfa9b0b.squirrel@webmail.lagarcavilla.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <86f622285e1ceb506d0bdbae7cfa9b0b.squirrel@webmail.lagarcavilla.org>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: xen-devel@lists.xensource.com, ian.campbell@citrix.com,
	andres@gridcentric.ca, tim@xen.org, keir.xen@gmail.com,
	jbeulich@suse.com, ian.jackson@citrix.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 2 of 5] Improve ring management for memory
 events. Do not lose guest events
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Nov 30, Andres Lagar-Cavilla wrote:

> - This isn't a problem that necessitates wait-queues for solving. Just
> careful logic.
> 
> - I am not sure what your concerns about the mix are. get_gfn* would call
> populate on a paged out gfn, and then go to sleep if it's a guest vcpu.
> With our patch, the guest vcpu event is guaranteed to go in the ring. vcpu
> pausing will stack (and unwind) properly.

Today I sent my current version of wait queues for mem_event and paging.
Unfortunately the earlier versions of mem_event had bugs which caused
trouble also for the paging change.
Please have a look wether my changes work for you.

I see you have a change to mem_event_get_response() which pulls all
requests instead of just one. Thats currently a noop for paging, but
it will be used once paging can get rid of the domctls.



I added p2m_mem_paging_wait() which calls p2m_mem_paging_populate(),
then goes to sleep until p2m_mem_paging_get_entry() indicates the gfn is
back. If I understand your change correctly a guest vcpu can always
place a request. If p2m_mem_paging_populate() happens to fail to put a
request, what is supposed to happen in p2m_mem_paging_wait()? Should it
skip the wait_event() and return to its caller?

With my implementation both p2m_mem_paging_wait() and
p2m_mem_paging_populate() will stop exectution until either the gfn is
back or if there is room in the buffer. There is no need for exit
code handling.

Olaf

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 15:37:34 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 15:37:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW8hN-0000t0-0V; Thu, 01 Dec 2011 15:37:21 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RW8hL-0000st-HB
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 15:37:19 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-6.tower-27.messagelabs.com!1322753769!49128977!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNDUxMTM=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNDUxMTM=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5109 invoked from network); 1 Dec 2011 15:36:10 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-6.tower-27.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 1 Dec 2011 15:36:10 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1322753804; l=1484;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=LBeXKMpFHnQvgM96R3zunBdDsdA=;
	b=UFaxpa8mZyrmH+1zmiqPLjzXzfnSf4gU2+r0i0IHQmDSe4grY8JNQEcOr8RXVRCZ2Gc
	+X9PLxh2yRVePRjo7rXf6KL5SAJNp8Nwh4qwJFC2lCDZaT5zlzw2BraGpONvF9Pjg24QF
	kbS/ZZG/tjmzJbnL9yZT3pLNG7LERrEHtk0=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/ll2c7pE6jG
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-080-213.pools.arcor-ip.net [84.57.80.213])
	by post.strato.de (mrclete mo8) (RZmta 26.10 AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id f037aanB1DQERA ;
	Thu, 1 Dec 2011 16:36:36 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id B919E18637; Thu,  1 Dec 2011 16:36:35 +0100 (CET)
Date: Thu, 1 Dec 2011 16:36:35 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20111201153635.GA14132@aepfle.de>
References: <patchbomb.1322603709@xdev.gridcentric.ca>
	<43dc614d543cdf84189d.1322603711@xdev.gridcentric.ca>
	<20111130125821.GB15723@aepfle.de>
	<86f622285e1ceb506d0bdbae7cfa9b0b.squirrel@webmail.lagarcavilla.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <86f622285e1ceb506d0bdbae7cfa9b0b.squirrel@webmail.lagarcavilla.org>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: xen-devel@lists.xensource.com, ian.campbell@citrix.com,
	andres@gridcentric.ca, tim@xen.org, keir.xen@gmail.com,
	jbeulich@suse.com, ian.jackson@citrix.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 2 of 5] Improve ring management for memory
 events. Do not lose guest events
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Nov 30, Andres Lagar-Cavilla wrote:

> - This isn't a problem that necessitates wait-queues for solving. Just
> careful logic.
> 
> - I am not sure what your concerns about the mix are. get_gfn* would call
> populate on a paged out gfn, and then go to sleep if it's a guest vcpu.
> With our patch, the guest vcpu event is guaranteed to go in the ring. vcpu
> pausing will stack (and unwind) properly.

Today I sent my current version of wait queues for mem_event and paging.
Unfortunately the earlier versions of mem_event had bugs which caused
trouble also for the paging change.
Please have a look wether my changes work for you.

I see you have a change to mem_event_get_response() which pulls all
requests instead of just one. Thats currently a noop for paging, but
it will be used once paging can get rid of the domctls.



I added p2m_mem_paging_wait() which calls p2m_mem_paging_populate(),
then goes to sleep until p2m_mem_paging_get_entry() indicates the gfn is
back. If I understand your change correctly a guest vcpu can always
place a request. If p2m_mem_paging_populate() happens to fail to put a
request, what is supposed to happen in p2m_mem_paging_wait()? Should it
skip the wait_event() and return to its caller?

With my implementation both p2m_mem_paging_wait() and
p2m_mem_paging_populate() will stop exectution until either the gfn is
back or if there is room in the buffer. There is no need for exit
code handling.

Olaf

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 15:39:29 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 15: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.xensource.com>)
	id 1RW8jB-0000yc-Ho; Thu, 01 Dec 2011 15:39:13 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RW8j9-0000y2-4n
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 15:39:11 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1322753911!3892626!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU2Nw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14571 invoked from network); 1 Dec 2011 15:38:31 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 15:38:31 -0000
X-IronPort-AV: E=Sophos;i="4.71,278,1320624000"; 
   d="scan'208";a="9234520"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Dec 2011 15:38:30 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 1 Dec 2011 15:38:30 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RW8iS-0003KT-Fy;
	Thu, 01 Dec 2011 15:38:28 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RW8iS-0001aJ-3v;
	Thu, 01 Dec 2011 15:38:28 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10202-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 1 Dec 2011 15:38:28 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10202: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

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

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-amd64-xl-sedf     13 guest-localmigrate.2      fail REGR. vs. 10201

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-i386-xend-winxpsp3  7 windows-install              fail  never pass
 test-amd64-amd64-xl-win7-amd64  7 windows-install              fail never pass
 test-amd64-i386-xl-win7-amd64  7 windows-install              fail  never pass
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install          fail never pass
 test-i386-i386-xl-winxpsp3    7 windows-install              fail   never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  20c1c0ff9677
baseline version:
 xen                  62ff6a318c5d

------------------------------------------------------------
People who touched revisions under test:
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Liu, Jinsong <jinsong.liu@intel.com>
------------------------------------------------------------

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


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

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

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


Not pushing.

------------------------------------------------------------
changeset:   24279:20c1c0ff9677
tag:         tip
user:        Liu, Jinsong <jinsong.liu@intel.com>
date:        Thu Dec 01 12:24:06 2011 +0100
    
    X86: implement PCID/INVPCID for hvm
    
    This patch handle PCID/INVPCID for hvm:
    
    For hap hvm, we enable PCID/INVPCID, since no need to intercept
    INVPCID, and we just set INVPCID non-root behavior as running natively;
    
    For shadow hvm, we disable PCID/INVPCID, otherwise we need to emulate
    INVPCID at vmm by setting INVPCID non-root behavior as vmexit.
    
    Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
    Committed-by: Jan Beulich <jbeulich@suse.com>
    
    
changeset:   24278:d9cb04ed5539
user:        Liu, Jinsong <jinsong.liu@intel.com>
date:        Thu Dec 01 12:22:43 2011 +0100
    
    X86: Disable PCID/INVPCID for dom0
    
    PCID (Process-context identifier) is a facility by which a logical
    processor may cache information for multiple linear-address spaces.
    INVPCID is an new instruction to invalidate TLB. Refer latest Intel SDM
    http://www.intel.com/content/www/us/en/processors/architectures-software-developer-manuals.html
    
    We disable PCID/INVPCID for dom0 and pv. Exposing them into dom0 and pv
    may result in performance regression, and it would trigger GP or UD
    depending on whether platform suppport INVPCID or not.
    
    This patch disables PCID/INVPCID for dom0.
    
    Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
    Committed-by: Jan Beulich <jbeulich@suse.com>
    
    
changeset:   24277:1f6b58c8e1ba
user:        Liu, Jinsong <jinsong.liu@intel.com>
date:        Thu Dec 01 12:21:24 2011 +0100
    
    X86: expose Intel new features to dom0
    
    This patch expose Intel new features to dom0, including
    FMA/AVX2/BMI1/BMI2/LZCNT/MOVBE.
    
    Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
    Committed-by: Jan Beulich <jbeulich@suse.com>
    
    
changeset:   24276:89f727368169
user:        Jan Beulich <jbeulich@suse.com>
date:        Thu Dec 01 08:51:35 2011 +0100
    
    x86/emulator: cleanup
    
    Utilize some of the additions in the prior patches to clean up other
    code:
    - keep track of REP prefixes in only one variable
    - use REX_W in a few more places (instead of a literal number)
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24275:76ea126f2172
user:        Jan Beulich <jbeulich@suse.com>
date:        Thu Dec 01 08:50:49 2011 +0100
    
    x86/emulator: properly handle lzcnt and tzcnt
    
    These instructions are prefix selected flavors of bsf and bsr
    respectively, and hence the presences of the F3 prefix must be handled
    in the emulation code in order to avoid running into problems on newer
    CPUs.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    
    --- a/xen/arch/x86/x86_emulate/x86_emulate.c
    +++ b/xen/arch/x86/x86_emulate/x86_emulate.c
    @@ -1058,6 +1058,9 @@ static bool_t vcpu_has(
         return rc == X86EMUL_OKAY;
     }
    
    +#define vcpu_has_lzcnt() vcpu_has(0x80000001, ECX,  5, ctxt, ops)
    +#define vcpu_has_bmi1()  vcpu_has(0x00000007, EBX,  3, ctxt, ops)
    +
     #define vcpu_must_have(leaf, reg, bit) \
         generate_exception_if(!vcpu_has(leaf, reg, bit, ctxt, ops), EXC_UD, -1)
     #define vcpu_must_have_mmx()  vcpu_must_have(0x00000001, EDX, 23)
    @@ -4357,13 +4360,24 @@ x86_emulate(
             dst.val   = (uint8_t)src.val;
             break;
    
    -    case 0xbc: /* bsf */ {
    -        int zf;
    +    case 0xbc: /* bsf or tzcnt */ {
    +        bool_t zf;
             asm ( "bsf %2,%0; setz %b1"
                   : "=r" (dst.val), "=q" (zf)
    -              : "r" (src.val), "1" (0) );
    +              : "r" (src.val) );
             _regs.eflags &= ~EFLG_ZF;
    -        if ( zf )
    +        if ( (rep_prefix == REPE_PREFIX) && vcpu_has_bmi1() )
    +        {
    +            _regs.eflags &= ~EFLG_CF;
    +            if ( zf )
    +            {
    +                _regs.eflags |= EFLG_CF;
    +                dst.val = op_bytes * 8;
    +            }
    +            else if ( !dst.val )
    +                _regs.eflags |= EFLG_ZF;
    +        }
    +        else if ( zf )
             {
                 _regs.eflags |= EFLG_ZF;
                 dst.type = OP_NONE;
    @@ -4371,13 +4385,28 @@ x86_emulate(
             break;
         }
    
    -    case 0xbd: /* bsr */ {
    -        int zf;
    +    case 0xbd: /* bsr or lzcnt */ {
    +        bool_t zf;
             asm ( "bsr %2,%0; setz %b1"
                   : "=r" (dst.val), "=q" (zf)
    -              : "r" (src.val), "1" (0) );
    +              : "r" (src.val) );
             _regs.eflags &= ~EFLG_ZF;
    -        if ( zf )
    +        if ( (rep_prefix == REPE_PREFIX) && vcpu_has_lzcnt() )
    +        {
    +            _regs.eflags &= ~EFLG_CF;
    +            if ( zf )
    +            {
    +                _regs.eflags |= EFLG_CF;
    +                dst.val = op_bytes * 8;
    +            }
    +            else
    +            {
    +                dst.val = op_bytes * 8 - 1 - dst.val;
    +                if ( !dst.val )
    +                    _regs.eflags |= EFLG_ZF;
    +            }
    +        }
    +        else if ( zf )
             {
                 _regs.eflags |= EFLG_ZF;
                 dst.type = OP_NONE;
    
    
changeset:   24274:07cf778d517f
user:        Jan Beulich <jbeulich@suse.com>
date:        Thu Dec 01 08:49:31 2011 +0100
    
    x86/emulator: add emulation of SIMD FP moves
    
    Clone the existing movq emulation to also support the most fundamental
    SIMD FP moves.
    
    Extend the testing code to also exercise these instructions.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24273:73a5655c2ac5
user:        Jan Beulich <jbeulich@suse.com>
date:        Thu Dec 01 08:48:14 2011 +0100
    
    x86/emulator: generalize movq emulation (SSE2 and AVX variants)
    
    Extend the existing movq emulation to also support its SSE2 and AVX
    variants, the latter implying the addition of VEX decoding. Fold the
    read and write cases (as most of the logic is identical), and add
    movntq and variants (as they're very similar).
    
    Extend the testing code to also exercise these instructions.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24272:62ff6a318c5d
user:        Keir Fraser <keir@xen.org>
date:        Wed Nov 30 16:59:58 2011 -0800
    
    xenpaging: Fix c/s 23507:0a29c8c3ddf7 ("update machine_to_phys_mapping[] during page deallocation")
    
    This patch clobbers page owner in free_heap_pages() before we are
    finished using it. This means that a subsequent test to determine
    whether it is safe to avoid safety TLB flushes incorrectly always
    determines that it is safe to do so.
    
    The fix is simple: we can defer the original patch's work until after
    we are done with the page-owner field.
    
    Thanks to Christian Limpach for spotting this one.
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
========================================
commit 89daacab7035d408f32f2cb1acf68c96d6cbefed
Author: Ian Jackson <ian.jackson@eu.citrix.com>
Date:   Mon Nov 28 17:16:52 2011 +0000

    qemu-dm: open char devices "file:..." with O_APPEND
    
    The "file:..." character open method is used by serial and parallel
    ports, to divert the output to a file (and these devices never produce
    any input).  This is like a logfile, and so should be opened for
    append.
    
    In qemu-xen-unstable, this is used only for the qemu stderr by libxl.
    
    Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 15:39:29 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 15: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.xensource.com>)
	id 1RW8jB-0000yc-Ho; Thu, 01 Dec 2011 15:39:13 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RW8j9-0000y2-4n
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 15:39:11 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1322753911!3892626!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU2Nw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14571 invoked from network); 1 Dec 2011 15:38:31 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 15:38:31 -0000
X-IronPort-AV: E=Sophos;i="4.71,278,1320624000"; 
   d="scan'208";a="9234520"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Dec 2011 15:38:30 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 1 Dec 2011 15:38:30 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RW8iS-0003KT-Fy;
	Thu, 01 Dec 2011 15:38:28 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RW8iS-0001aJ-3v;
	Thu, 01 Dec 2011 15:38:28 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10202-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 1 Dec 2011 15:38:28 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10202: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

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

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-amd64-xl-sedf     13 guest-localmigrate.2      fail REGR. vs. 10201

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-i386-xend-winxpsp3  7 windows-install              fail  never pass
 test-amd64-amd64-xl-win7-amd64  7 windows-install              fail never pass
 test-amd64-i386-xl-win7-amd64  7 windows-install              fail  never pass
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install          fail never pass
 test-i386-i386-xl-winxpsp3    7 windows-install              fail   never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  20c1c0ff9677
baseline version:
 xen                  62ff6a318c5d

------------------------------------------------------------
People who touched revisions under test:
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Liu, Jinsong <jinsong.liu@intel.com>
------------------------------------------------------------

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


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

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

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


Not pushing.

------------------------------------------------------------
changeset:   24279:20c1c0ff9677
tag:         tip
user:        Liu, Jinsong <jinsong.liu@intel.com>
date:        Thu Dec 01 12:24:06 2011 +0100
    
    X86: implement PCID/INVPCID for hvm
    
    This patch handle PCID/INVPCID for hvm:
    
    For hap hvm, we enable PCID/INVPCID, since no need to intercept
    INVPCID, and we just set INVPCID non-root behavior as running natively;
    
    For shadow hvm, we disable PCID/INVPCID, otherwise we need to emulate
    INVPCID at vmm by setting INVPCID non-root behavior as vmexit.
    
    Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
    Committed-by: Jan Beulich <jbeulich@suse.com>
    
    
changeset:   24278:d9cb04ed5539
user:        Liu, Jinsong <jinsong.liu@intel.com>
date:        Thu Dec 01 12:22:43 2011 +0100
    
    X86: Disable PCID/INVPCID for dom0
    
    PCID (Process-context identifier) is a facility by which a logical
    processor may cache information for multiple linear-address spaces.
    INVPCID is an new instruction to invalidate TLB. Refer latest Intel SDM
    http://www.intel.com/content/www/us/en/processors/architectures-software-developer-manuals.html
    
    We disable PCID/INVPCID for dom0 and pv. Exposing them into dom0 and pv
    may result in performance regression, and it would trigger GP or UD
    depending on whether platform suppport INVPCID or not.
    
    This patch disables PCID/INVPCID for dom0.
    
    Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
    Committed-by: Jan Beulich <jbeulich@suse.com>
    
    
changeset:   24277:1f6b58c8e1ba
user:        Liu, Jinsong <jinsong.liu@intel.com>
date:        Thu Dec 01 12:21:24 2011 +0100
    
    X86: expose Intel new features to dom0
    
    This patch expose Intel new features to dom0, including
    FMA/AVX2/BMI1/BMI2/LZCNT/MOVBE.
    
    Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
    Committed-by: Jan Beulich <jbeulich@suse.com>
    
    
changeset:   24276:89f727368169
user:        Jan Beulich <jbeulich@suse.com>
date:        Thu Dec 01 08:51:35 2011 +0100
    
    x86/emulator: cleanup
    
    Utilize some of the additions in the prior patches to clean up other
    code:
    - keep track of REP prefixes in only one variable
    - use REX_W in a few more places (instead of a literal number)
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24275:76ea126f2172
user:        Jan Beulich <jbeulich@suse.com>
date:        Thu Dec 01 08:50:49 2011 +0100
    
    x86/emulator: properly handle lzcnt and tzcnt
    
    These instructions are prefix selected flavors of bsf and bsr
    respectively, and hence the presences of the F3 prefix must be handled
    in the emulation code in order to avoid running into problems on newer
    CPUs.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    
    --- a/xen/arch/x86/x86_emulate/x86_emulate.c
    +++ b/xen/arch/x86/x86_emulate/x86_emulate.c
    @@ -1058,6 +1058,9 @@ static bool_t vcpu_has(
         return rc == X86EMUL_OKAY;
     }
    
    +#define vcpu_has_lzcnt() vcpu_has(0x80000001, ECX,  5, ctxt, ops)
    +#define vcpu_has_bmi1()  vcpu_has(0x00000007, EBX,  3, ctxt, ops)
    +
     #define vcpu_must_have(leaf, reg, bit) \
         generate_exception_if(!vcpu_has(leaf, reg, bit, ctxt, ops), EXC_UD, -1)
     #define vcpu_must_have_mmx()  vcpu_must_have(0x00000001, EDX, 23)
    @@ -4357,13 +4360,24 @@ x86_emulate(
             dst.val   = (uint8_t)src.val;
             break;
    
    -    case 0xbc: /* bsf */ {
    -        int zf;
    +    case 0xbc: /* bsf or tzcnt */ {
    +        bool_t zf;
             asm ( "bsf %2,%0; setz %b1"
                   : "=r" (dst.val), "=q" (zf)
    -              : "r" (src.val), "1" (0) );
    +              : "r" (src.val) );
             _regs.eflags &= ~EFLG_ZF;
    -        if ( zf )
    +        if ( (rep_prefix == REPE_PREFIX) && vcpu_has_bmi1() )
    +        {
    +            _regs.eflags &= ~EFLG_CF;
    +            if ( zf )
    +            {
    +                _regs.eflags |= EFLG_CF;
    +                dst.val = op_bytes * 8;
    +            }
    +            else if ( !dst.val )
    +                _regs.eflags |= EFLG_ZF;
    +        }
    +        else if ( zf )
             {
                 _regs.eflags |= EFLG_ZF;
                 dst.type = OP_NONE;
    @@ -4371,13 +4385,28 @@ x86_emulate(
             break;
         }
    
    -    case 0xbd: /* bsr */ {
    -        int zf;
    +    case 0xbd: /* bsr or lzcnt */ {
    +        bool_t zf;
             asm ( "bsr %2,%0; setz %b1"
                   : "=r" (dst.val), "=q" (zf)
    -              : "r" (src.val), "1" (0) );
    +              : "r" (src.val) );
             _regs.eflags &= ~EFLG_ZF;
    -        if ( zf )
    +        if ( (rep_prefix == REPE_PREFIX) && vcpu_has_lzcnt() )
    +        {
    +            _regs.eflags &= ~EFLG_CF;
    +            if ( zf )
    +            {
    +                _regs.eflags |= EFLG_CF;
    +                dst.val = op_bytes * 8;
    +            }
    +            else
    +            {
    +                dst.val = op_bytes * 8 - 1 - dst.val;
    +                if ( !dst.val )
    +                    _regs.eflags |= EFLG_ZF;
    +            }
    +        }
    +        else if ( zf )
             {
                 _regs.eflags |= EFLG_ZF;
                 dst.type = OP_NONE;
    
    
changeset:   24274:07cf778d517f
user:        Jan Beulich <jbeulich@suse.com>
date:        Thu Dec 01 08:49:31 2011 +0100
    
    x86/emulator: add emulation of SIMD FP moves
    
    Clone the existing movq emulation to also support the most fundamental
    SIMD FP moves.
    
    Extend the testing code to also exercise these instructions.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24273:73a5655c2ac5
user:        Jan Beulich <jbeulich@suse.com>
date:        Thu Dec 01 08:48:14 2011 +0100
    
    x86/emulator: generalize movq emulation (SSE2 and AVX variants)
    
    Extend the existing movq emulation to also support its SSE2 and AVX
    variants, the latter implying the addition of VEX decoding. Fold the
    read and write cases (as most of the logic is identical), and add
    movntq and variants (as they're very similar).
    
    Extend the testing code to also exercise these instructions.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24272:62ff6a318c5d
user:        Keir Fraser <keir@xen.org>
date:        Wed Nov 30 16:59:58 2011 -0800
    
    xenpaging: Fix c/s 23507:0a29c8c3ddf7 ("update machine_to_phys_mapping[] during page deallocation")
    
    This patch clobbers page owner in free_heap_pages() before we are
    finished using it. This means that a subsequent test to determine
    whether it is safe to avoid safety TLB flushes incorrectly always
    determines that it is safe to do so.
    
    The fix is simple: we can defer the original patch's work until after
    we are done with the page-owner field.
    
    Thanks to Christian Limpach for spotting this one.
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
========================================
commit 89daacab7035d408f32f2cb1acf68c96d6cbefed
Author: Ian Jackson <ian.jackson@eu.citrix.com>
Date:   Mon Nov 28 17:16:52 2011 +0000

    qemu-dm: open char devices "file:..." with O_APPEND
    
    The "file:..." character open method is used by serial and parallel
    ports, to divert the output to a file (and these devices never produce
    any input).  This is like a logfile, and so should be opened for
    append.
    
    In qemu-xen-unstable, this is used only for the qemu stderr by libxl.
    
    Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 15:43:24 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 15:43:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW8n2-0001EJ-3f; Thu, 01 Dec 2011 15:43:12 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <arnd@arndb.de>) id 1RW8n0-0001E3-OB
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 15:43:10 +0000
X-Env-Sender: arnd@arndb.de
X-Msg-Ref: server-9.tower-174.messagelabs.com!1322754150!3892375!1
X-Originating-IP: [212.227.17.8]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMTIuMjI3LjE3LjggPT4gODUwMTg=\n,sa_preprocessor: 
	QmFkIElQOiAyMTIuMjI3LjE3LjggPT4gODUwMTg=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24082 invoked from network); 1 Dec 2011 15:42:30 -0000
Received: from moutng.kundenserver.de (HELO moutng.kundenserver.de)
	(212.227.17.8) by server-9.tower-174.messagelabs.com with SMTP;
	1 Dec 2011 15:42:30 -0000
Received: from klappe2.localnet (deibp9eh1--blueice3n2.emea.ibm.com
	[195.212.29.180])
	by mrelayeu.kundenserver.de (node=mreu4) with ESMTP (Nemesis)
	id 0M7A5y-1QZFWb1sne-00x2Il; Thu, 01 Dec 2011 16:42:23 +0100
From: Arnd Bergmann <arnd@arndb.de>
To: Catalin Marinas <catalin.marinas@arm.com>
Date: Thu, 1 Dec 2011 15:42:19 +0000
User-Agent: KMail/1.12.2 (Linux/3.2.0-rc1+; KDE/4.3.2; x86_64; ; )
References: <alpine.DEB.2.00.1111281009090.31179@kaball-desktop>
	<1322735197.31810.191.camel@zakaz.uk.xensource.com>
	<20111201151043.GG27394@arm.com>
In-Reply-To: <20111201151043.GG27394@arm.com>
MIME-Version: 1.0
Message-Id: <201112011542.19377.arnd@arndb.de>
X-Provags-ID: V02:K0:Ycdbw+ncFty38WKX6qb8TPkidZ48FAgA7MIw/6DZTG2
	GXdjKYlLACwgkS7naCbeV5TR1TrfAH6eld5dEaUUieNUh0YP5P
	eSUG9qmH2w14JiS+/+Sbh+EJ+uVqREZs6sh0DBisSIU3FKNRyX
	k5uckZFQPPDDKC5qW2+Zd9BxH48CIdBD1cleue4Di3FkHLDm1S
	lkeg0EMqjzd79Zcpsi3QyuaAiNvB7HI7OyZye0Tkh+i+Y9fKCk
	+bSB5D7/i9gYXgrkKQUH4Hy9e4nmyykCpAUuRYAr0rtXgIMz+e
	b1g/cGwzy56gKDw5cNFCZvl702k8Mqax6eiaWLbWvCa3rAWxJp
	+cQbDW2VqhoxB2QxAxNM=
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linaro-dev@lists.linaro.org" <linaro-dev@lists.linaro.org>,
	Ian Campbell <Ian.Campbell@citrix.com>, Pawel Moll <Pawel.Moll@arm.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"virtualization@lists.linux-foundation.org"
	<virtualization@lists.linux-foundation.org>,
	"android-virt@lists.cs.columbia.edu" <android-virt@lists.cs.columbia.edu>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	"embeddedxen-devel@lists.sourceforge.net"
	<embeddedxen-devel@lists.sourceforge.net>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [Android-virt] [Embeddedxen-devel] [ANNOUNCE] Xen
	port to Cortex-A15 / ARMv7 with virt extensions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thursday 01 December 2011, Catalin Marinas wrote:
> Given the way register banking is done on AArch64, issuing an HVC on a
> 32-bit guest OS doesn't require translation on a 64-bit hypervisor. We
> have a similar implementation at the SVC level (for 32-bit user apps on
> a 64-bit kernel), the only modification was where a 32-bit SVC takes a
> 64-bit parameter in two separate 32-bit registers, so packing needs to
> be done in a syscall wrapper.

How do you deal with signed integer arguments passed into SVC or HVC from
a caller? If I understand the architecture correctly, the upper
halves of the argument register end up zero-padded, while the callee
expects sign-extension.

	Arnd

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 15:43:24 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 15:43:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW8n2-0001EJ-3f; Thu, 01 Dec 2011 15:43:12 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <arnd@arndb.de>) id 1RW8n0-0001E3-OB
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 15:43:10 +0000
X-Env-Sender: arnd@arndb.de
X-Msg-Ref: server-9.tower-174.messagelabs.com!1322754150!3892375!1
X-Originating-IP: [212.227.17.8]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMTIuMjI3LjE3LjggPT4gODUwMTg=\n,sa_preprocessor: 
	QmFkIElQOiAyMTIuMjI3LjE3LjggPT4gODUwMTg=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24082 invoked from network); 1 Dec 2011 15:42:30 -0000
Received: from moutng.kundenserver.de (HELO moutng.kundenserver.de)
	(212.227.17.8) by server-9.tower-174.messagelabs.com with SMTP;
	1 Dec 2011 15:42:30 -0000
Received: from klappe2.localnet (deibp9eh1--blueice3n2.emea.ibm.com
	[195.212.29.180])
	by mrelayeu.kundenserver.de (node=mreu4) with ESMTP (Nemesis)
	id 0M7A5y-1QZFWb1sne-00x2Il; Thu, 01 Dec 2011 16:42:23 +0100
From: Arnd Bergmann <arnd@arndb.de>
To: Catalin Marinas <catalin.marinas@arm.com>
Date: Thu, 1 Dec 2011 15:42:19 +0000
User-Agent: KMail/1.12.2 (Linux/3.2.0-rc1+; KDE/4.3.2; x86_64; ; )
References: <alpine.DEB.2.00.1111281009090.31179@kaball-desktop>
	<1322735197.31810.191.camel@zakaz.uk.xensource.com>
	<20111201151043.GG27394@arm.com>
In-Reply-To: <20111201151043.GG27394@arm.com>
MIME-Version: 1.0
Message-Id: <201112011542.19377.arnd@arndb.de>
X-Provags-ID: V02:K0:Ycdbw+ncFty38WKX6qb8TPkidZ48FAgA7MIw/6DZTG2
	GXdjKYlLACwgkS7naCbeV5TR1TrfAH6eld5dEaUUieNUh0YP5P
	eSUG9qmH2w14JiS+/+Sbh+EJ+uVqREZs6sh0DBisSIU3FKNRyX
	k5uckZFQPPDDKC5qW2+Zd9BxH48CIdBD1cleue4Di3FkHLDm1S
	lkeg0EMqjzd79Zcpsi3QyuaAiNvB7HI7OyZye0Tkh+i+Y9fKCk
	+bSB5D7/i9gYXgrkKQUH4Hy9e4nmyykCpAUuRYAr0rtXgIMz+e
	b1g/cGwzy56gKDw5cNFCZvl702k8Mqax6eiaWLbWvCa3rAWxJp
	+cQbDW2VqhoxB2QxAxNM=
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linaro-dev@lists.linaro.org" <linaro-dev@lists.linaro.org>,
	Ian Campbell <Ian.Campbell@citrix.com>, Pawel Moll <Pawel.Moll@arm.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"virtualization@lists.linux-foundation.org"
	<virtualization@lists.linux-foundation.org>,
	"android-virt@lists.cs.columbia.edu" <android-virt@lists.cs.columbia.edu>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	"embeddedxen-devel@lists.sourceforge.net"
	<embeddedxen-devel@lists.sourceforge.net>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [Android-virt] [Embeddedxen-devel] [ANNOUNCE] Xen
	port to Cortex-A15 / ARMv7 with virt extensions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thursday 01 December 2011, Catalin Marinas wrote:
> Given the way register banking is done on AArch64, issuing an HVC on a
> 32-bit guest OS doesn't require translation on a 64-bit hypervisor. We
> have a similar implementation at the SVC level (for 32-bit user apps on
> a 64-bit kernel), the only modification was where a 32-bit SVC takes a
> 64-bit parameter in two separate 32-bit registers, so packing needs to
> be done in a syscall wrapper.

How do you deal with signed integer arguments passed into SVC or HVC from
a caller? If I understand the architecture correctly, the upper
halves of the argument register end up zero-padded, while the callee
expects sign-extension.

	Arnd

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 15:44:08 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 15: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.xensource.com>)
	id 1RW8nm-0001Jn-IZ; Thu, 01 Dec 2011 15:43:58 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RW8nl-0001IU-F5
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 15:43:57 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-7.tower-182.messagelabs.com!1322754197!5427149!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21831 invoked from network); 1 Dec 2011 15:43:17 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-7.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 1 Dec 2011 15:43:17 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RW8n4-000GdA-1h; Thu, 01 Dec 2011 15:43:14 +0000
Date: Thu, 1 Dec 2011 15:43:13 +0000
From: Tim Deegan <tim@xen.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20111201154313.GG61203@ocelot.phlegethon.org>
References: <4ED76A350200007800064ABD@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4ED76A350200007800064ABD@nat28.tlf.novell.com>
User-Agent: Mutt/1.4.2.1i
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Eddie Dong <eddie.dong@intel.com>,
	Tim Deegan <Tim.Deegan@citrix.com>, qing.he@intel.com
Subject: Re: [Xen-devel] [PATCH] vvmx: fix intended assignment
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 10:51 +0000 on 01 Dec (1322736677), Jan Beulich wrote:
> From what I can tell, this was supposed to be an assignment (not warned
> about by the compiler due to -Wno-unused, which is about to be removed).
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> --- a/xen/arch/x86/hvm/vmx/vvmx.c
> +++ b/xen/arch/x86/hvm/vmx/vvmx.c
> @@ -581,7 +581,7 @@ static void nvmx_purge_vvmcs(struct vcpu
>      __clear_current_vvmcs(v);
>      if ( nvcpu->nv_vvmcxaddr != VMCX_EADDR )
>          hvm_unmap_guest_frame(nvcpu->nv_vvmcx);
> -    nvcpu->nv_vvmcx == NULL;
> +    nvcpu->nv_vvmcx = NULL;
>      nvcpu->nv_vvmcxaddr = VMCX_EADDR;
>      for (i=0; i<2; i++) {
>          if ( nvmx->iobitmap[i] ) {
> 
> 
> 

Applied, thanks.

Tim.

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 15:44:08 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 15: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.xensource.com>)
	id 1RW8nm-0001Jn-IZ; Thu, 01 Dec 2011 15:43:58 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RW8nl-0001IU-F5
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 15:43:57 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-7.tower-182.messagelabs.com!1322754197!5427149!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21831 invoked from network); 1 Dec 2011 15:43:17 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-7.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 1 Dec 2011 15:43:17 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RW8n4-000GdA-1h; Thu, 01 Dec 2011 15:43:14 +0000
Date: Thu, 1 Dec 2011 15:43:13 +0000
From: Tim Deegan <tim@xen.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20111201154313.GG61203@ocelot.phlegethon.org>
References: <4ED76A350200007800064ABD@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4ED76A350200007800064ABD@nat28.tlf.novell.com>
User-Agent: Mutt/1.4.2.1i
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Eddie Dong <eddie.dong@intel.com>,
	Tim Deegan <Tim.Deegan@citrix.com>, qing.he@intel.com
Subject: Re: [Xen-devel] [PATCH] vvmx: fix intended assignment
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 10:51 +0000 on 01 Dec (1322736677), Jan Beulich wrote:
> From what I can tell, this was supposed to be an assignment (not warned
> about by the compiler due to -Wno-unused, which is about to be removed).
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> --- a/xen/arch/x86/hvm/vmx/vvmx.c
> +++ b/xen/arch/x86/hvm/vmx/vvmx.c
> @@ -581,7 +581,7 @@ static void nvmx_purge_vvmcs(struct vcpu
>      __clear_current_vvmcs(v);
>      if ( nvcpu->nv_vvmcxaddr != VMCX_EADDR )
>          hvm_unmap_guest_frame(nvcpu->nv_vvmcx);
> -    nvcpu->nv_vvmcx == NULL;
> +    nvcpu->nv_vvmcx = NULL;
>      nvcpu->nv_vvmcxaddr = VMCX_EADDR;
>      for (i=0; i<2; i++) {
>          if ( nvmx->iobitmap[i] ) {
> 
> 
> 

Applied, thanks.

Tim.

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 15:53:34 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 15:53:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW8ws-0001xG-8m; Thu, 01 Dec 2011 15:53:22 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RW8wr-0001xA-Mt
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 15:53:21 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1322754746!50525128!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU2Nw==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10217 invoked from network); 1 Dec 2011 15:52:26 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 15:52:26 -0000
X-IronPort-AV: E=Sophos;i="4.71,278,1320624000"; 
   d="scan'208";a="9234932"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Dec 2011 15:52:46 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 1 Dec 2011
	15:52:46 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Catalin Marinas <catalin.marinas@arm.com>
Date: Thu, 1 Dec 2011 15:52:46 +0000
In-Reply-To: <20111201151043.GG27394@arm.com>
References: <alpine.DEB.2.00.1111281009090.31179@kaball-desktop>
	<201111301432.54463.arnd@arndb.de>
	<1322670473.31810.129.camel@zakaz.uk.xensource.com>
	<201111301815.01297.arnd@arndb.de>
	<alpine.DEB.2.00.1111301820290.31179@kaball-desktop>
	<1322735197.31810.191.camel@zakaz.uk.xensource.com>
	<20111201151043.GG27394@arm.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322754766.31810.240.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linaro-dev@lists.linaro.org" <linaro-dev@lists.linaro.org>,
	Arnd Bergmann <arnd@arndb.de>, Pawel Moll <Pawel.Moll@arm.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"virtualization@lists.linux-foundation.org"
	<virtualization@lists.linux-foundation.org>,
	"android-virt@lists.cs.columbia.edu" <android-virt@lists.cs.columbia.edu>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	"embeddedxen-devel@lists.sourceforge.net"
	<embeddedxen-devel@lists.sourceforge.net>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [Android-virt] [Embeddedxen-devel] [ANNOUNCE] Xen
 port to Cortex-A15 / ARMv7 with virt extensions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2011-12-01 at 15:10 +0000, Catalin Marinas wrote:
> On Thu, Dec 01, 2011 at 10:26:37AM +0000, Ian Campbell wrote:
> > On Wed, 2011-11-30 at 18:32 +0000, Stefano Stabellini wrote:
> > > On Wed, 30 Nov 2011, Arnd Bergmann wrote:
> > > > KVM and Xen at least both fall into the single-return-value category,
> > > > so we should be able to agree on a calling conventions. KVM does not
> > > > have an hcall API on ARM yet, and I see no reason not to use the
> > > > same implementation that you have in the Xen guest.
> > > > 
> > > > Stefano, can you split out the generic parts of your asm/xen/hypercall.h
> > > > file into a common asm/hypercall.h and submit it for review to the
> > > > arm kernel list?
> > > 
> > > Sure, I can do that.
> > > Usually the hypercall calling convention is very hypervisor specific,
> > > but if it turns out that we have the same requirements I happy to design
> > > a common interface.
> > 
> > I expect the only real decision to be made is hypercall page vs. raw hvc
> > instruction.
> > 
> > The page was useful on x86 where there is a variety of instructions
> > which could be used (at least for PV there was systenter/syscall/int, I
> > think vmcall instruction differs between AMD and Intel also) and gives
> > some additional flexibility. It's hard to predict but I don't think I'd
> > expect that to be necessary on ARM.
> > 
> > Another reason for having a hypercall page instead of a raw instruction
> > might be wanting to support 32 bit guests (from ~today) on a 64 bit
> > hypervisor in the future and perhaps needing to do some shimming/arg
> > translation. It would be better to aim for having the interface just be
> > 32/64 agnostic but mistakes do happen.
> 
> Given the way register banking is done on AArch64, issuing an HVC on a
> 32-bit guest OS doesn't require translation on a 64-bit hypervisor.

The issue I was thinking about was struct packing for arguments passed
as pointers etc rather than the argument registers themselves. Since the
preference appears to be for raw hvc we should just be careful that they
are agnostic in these.

Ian.

>  We
> have a similar implementation at the SVC level (for 32-bit user apps on
> a 64-bit kernel), the only modification was where a 32-bit SVC takes a
> 64-bit parameter in two separate 32-bit registers, so packing needs to
> be done in a syscall wrapper.
> 
> I'm not closely involved with any of the Xen or KVM work but I would
> vote for using HVC than a hypercall page.
> 



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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 15:53:34 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 15:53:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW8ws-0001xG-8m; Thu, 01 Dec 2011 15:53:22 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RW8wr-0001xA-Mt
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 15:53:21 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1322754746!50525128!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU2Nw==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10217 invoked from network); 1 Dec 2011 15:52:26 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 15:52:26 -0000
X-IronPort-AV: E=Sophos;i="4.71,278,1320624000"; 
   d="scan'208";a="9234932"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Dec 2011 15:52:46 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 1 Dec 2011
	15:52:46 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Catalin Marinas <catalin.marinas@arm.com>
Date: Thu, 1 Dec 2011 15:52:46 +0000
In-Reply-To: <20111201151043.GG27394@arm.com>
References: <alpine.DEB.2.00.1111281009090.31179@kaball-desktop>
	<201111301432.54463.arnd@arndb.de>
	<1322670473.31810.129.camel@zakaz.uk.xensource.com>
	<201111301815.01297.arnd@arndb.de>
	<alpine.DEB.2.00.1111301820290.31179@kaball-desktop>
	<1322735197.31810.191.camel@zakaz.uk.xensource.com>
	<20111201151043.GG27394@arm.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322754766.31810.240.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linaro-dev@lists.linaro.org" <linaro-dev@lists.linaro.org>,
	Arnd Bergmann <arnd@arndb.de>, Pawel Moll <Pawel.Moll@arm.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"virtualization@lists.linux-foundation.org"
	<virtualization@lists.linux-foundation.org>,
	"android-virt@lists.cs.columbia.edu" <android-virt@lists.cs.columbia.edu>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	"embeddedxen-devel@lists.sourceforge.net"
	<embeddedxen-devel@lists.sourceforge.net>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [Android-virt] [Embeddedxen-devel] [ANNOUNCE] Xen
 port to Cortex-A15 / ARMv7 with virt extensions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2011-12-01 at 15:10 +0000, Catalin Marinas wrote:
> On Thu, Dec 01, 2011 at 10:26:37AM +0000, Ian Campbell wrote:
> > On Wed, 2011-11-30 at 18:32 +0000, Stefano Stabellini wrote:
> > > On Wed, 30 Nov 2011, Arnd Bergmann wrote:
> > > > KVM and Xen at least both fall into the single-return-value category,
> > > > so we should be able to agree on a calling conventions. KVM does not
> > > > have an hcall API on ARM yet, and I see no reason not to use the
> > > > same implementation that you have in the Xen guest.
> > > > 
> > > > Stefano, can you split out the generic parts of your asm/xen/hypercall.h
> > > > file into a common asm/hypercall.h and submit it for review to the
> > > > arm kernel list?
> > > 
> > > Sure, I can do that.
> > > Usually the hypercall calling convention is very hypervisor specific,
> > > but if it turns out that we have the same requirements I happy to design
> > > a common interface.
> > 
> > I expect the only real decision to be made is hypercall page vs. raw hvc
> > instruction.
> > 
> > The page was useful on x86 where there is a variety of instructions
> > which could be used (at least for PV there was systenter/syscall/int, I
> > think vmcall instruction differs between AMD and Intel also) and gives
> > some additional flexibility. It's hard to predict but I don't think I'd
> > expect that to be necessary on ARM.
> > 
> > Another reason for having a hypercall page instead of a raw instruction
> > might be wanting to support 32 bit guests (from ~today) on a 64 bit
> > hypervisor in the future and perhaps needing to do some shimming/arg
> > translation. It would be better to aim for having the interface just be
> > 32/64 agnostic but mistakes do happen.
> 
> Given the way register banking is done on AArch64, issuing an HVC on a
> 32-bit guest OS doesn't require translation on a 64-bit hypervisor.

The issue I was thinking about was struct packing for arguments passed
as pointers etc rather than the argument registers themselves. Since the
preference appears to be for raw hvc we should just be careful that they
are agnostic in these.

Ian.

>  We
> have a similar implementation at the SVC level (for 32-bit user apps on
> a 64-bit kernel), the only modification was where a 32-bit SVC takes a
> 64-bit parameter in two separate 32-bit registers, so packing needs to
> be done in a syscall wrapper.
> 
> I'm not closely involved with any of the Xen or KVM work but I would
> vote for using HVC than a hypercall page.
> 



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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 15:54:44 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 15:54:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW8xm-00020S-Nx; Thu, 01 Dec 2011 15:54:18 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RW8xl-000202-8a
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 15:54:17 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-6.tower-216.messagelabs.com!1322754816!5782227!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2677 invoked from network); 1 Dec 2011 15:53:37 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-6.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 1 Dec 2011 15:53:37 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RW8x4-000Gh0-Oh; Thu, 01 Dec 2011 15:53:34 +0000
Date: Thu, 1 Dec 2011 15:53:34 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20111201155334.GH61203@ocelot.phlegethon.org>
References: <patchbomb.1322603559@xdev.gridcentric.ca>
	<0ce71e5bfaac7e8fe5b8.1322603560@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <0ce71e5bfaac7e8fe5b8.1322603560@xdev.gridcentric.ca>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com, ian.campbell@citrix.com,
	andres@gridcentric.ca, keir.xen@gmail.com, JBeulich@suse.com,
	ian.jackson@citrix.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 1 of 2] After preparing a page for page-in,
	allow immediate fill-in of the page contents
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi, 

This looks good to me.  I think it needs two more things to make it
correct (as well as the tools patch 2/2): 
 - an update to the xenpaging tool to use the new interface; and
 - a possible update to the paging state machine --- after all, if the 
   prep call allocates the pageand fills its contents, do we need 
   any more stages on the page-in path?

One more comment below: 

At 16:52 -0500 on 29 Nov (1322585560), Andres Lagar-Cavilla wrote:
> diff -r 4ee6d40edc2c -r 0ce71e5bfaac xen/arch/x86/mm/p2m.c
> --- a/xen/arch/x86/mm/p2m.c
> +++ b/xen/arch/x86/mm/p2m.c
> @@ -974,14 +974,43 @@ void p2m_mem_paging_populate(struct doma
>   * mfn if populate was called for  gfn which was nominated but not evicted. In
>   * this case only the p2mt needs to be forwarded.
>   */
> -int p2m_mem_paging_prep(struct domain *d, unsigned long gfn)
> +int p2m_mem_paging_prep(struct domain *d, unsigned long gfn, uint64_t buffer)
>  {
>      struct page_info *page;
>      p2m_type_t p2mt;
>      p2m_access_t a;
> -    mfn_t mfn;
> +    mfn_t mfn, buf_mfn = _mfn(INVALID_MFN);
>      struct p2m_domain *p2m = p2m_get_hostp2m(d);
> -    int ret;
> +    int ret, page_extant = 1;
> +    void *buf_map = NULL;
> +
> +    /* Map buffer page, if any, and get a reference */
> +    if ( buffer )
> +    {
> +        l1_pgentry_t l1e;
> +        unsigned long buf_gfn;
> +        p2m_type_t buf_p2mt;
> +
> +        if ( (buffer & (PAGE_SIZE - 1)) || 
> +             (!access_ok(buffer, PAGE_SIZE)) )
> +            return -EINVAL;
> +
> +        guest_get_eff_l1e(current, buffer, &l1e);
> +        buf_gfn = l1e_get_pfn(l1e);
> +        buf_mfn = get_gfn(current->domain, buf_gfn, 
> +                            &buf_p2mt);
> +
> +        if ( likely( mfn_valid(buf_mfn) &&
> +                     p2m_is_ram(buf_p2mt) ) )
> +        {
> +            get_page(mfn_to_page(buf_mfn), current->domain);
> +            buf_map = map_domain_page(mfn_x(buf_mfn));
> +            put_gfn(current->domain, buf_gfn);
> +        } else {
> +            put_gfn(current->domain, buf_gfn);
> +            return -EINVAL;
> +        }
> +    }

We could maybe avoid all this mechanism by doing a copy_from_user() of
the buffer contents directly into the new page, instead of an explicit
map-and-memcpy().

Cheers,

Tim.

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 15:54:44 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 15:54:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW8xm-00020S-Nx; Thu, 01 Dec 2011 15:54:18 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RW8xl-000202-8a
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 15:54:17 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-6.tower-216.messagelabs.com!1322754816!5782227!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2677 invoked from network); 1 Dec 2011 15:53:37 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-6.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 1 Dec 2011 15:53:37 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RW8x4-000Gh0-Oh; Thu, 01 Dec 2011 15:53:34 +0000
Date: Thu, 1 Dec 2011 15:53:34 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20111201155334.GH61203@ocelot.phlegethon.org>
References: <patchbomb.1322603559@xdev.gridcentric.ca>
	<0ce71e5bfaac7e8fe5b8.1322603560@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <0ce71e5bfaac7e8fe5b8.1322603560@xdev.gridcentric.ca>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com, ian.campbell@citrix.com,
	andres@gridcentric.ca, keir.xen@gmail.com, JBeulich@suse.com,
	ian.jackson@citrix.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 1 of 2] After preparing a page for page-in,
	allow immediate fill-in of the page contents
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi, 

This looks good to me.  I think it needs two more things to make it
correct (as well as the tools patch 2/2): 
 - an update to the xenpaging tool to use the new interface; and
 - a possible update to the paging state machine --- after all, if the 
   prep call allocates the pageand fills its contents, do we need 
   any more stages on the page-in path?

One more comment below: 

At 16:52 -0500 on 29 Nov (1322585560), Andres Lagar-Cavilla wrote:
> diff -r 4ee6d40edc2c -r 0ce71e5bfaac xen/arch/x86/mm/p2m.c
> --- a/xen/arch/x86/mm/p2m.c
> +++ b/xen/arch/x86/mm/p2m.c
> @@ -974,14 +974,43 @@ void p2m_mem_paging_populate(struct doma
>   * mfn if populate was called for  gfn which was nominated but not evicted. In
>   * this case only the p2mt needs to be forwarded.
>   */
> -int p2m_mem_paging_prep(struct domain *d, unsigned long gfn)
> +int p2m_mem_paging_prep(struct domain *d, unsigned long gfn, uint64_t buffer)
>  {
>      struct page_info *page;
>      p2m_type_t p2mt;
>      p2m_access_t a;
> -    mfn_t mfn;
> +    mfn_t mfn, buf_mfn = _mfn(INVALID_MFN);
>      struct p2m_domain *p2m = p2m_get_hostp2m(d);
> -    int ret;
> +    int ret, page_extant = 1;
> +    void *buf_map = NULL;
> +
> +    /* Map buffer page, if any, and get a reference */
> +    if ( buffer )
> +    {
> +        l1_pgentry_t l1e;
> +        unsigned long buf_gfn;
> +        p2m_type_t buf_p2mt;
> +
> +        if ( (buffer & (PAGE_SIZE - 1)) || 
> +             (!access_ok(buffer, PAGE_SIZE)) )
> +            return -EINVAL;
> +
> +        guest_get_eff_l1e(current, buffer, &l1e);
> +        buf_gfn = l1e_get_pfn(l1e);
> +        buf_mfn = get_gfn(current->domain, buf_gfn, 
> +                            &buf_p2mt);
> +
> +        if ( likely( mfn_valid(buf_mfn) &&
> +                     p2m_is_ram(buf_p2mt) ) )
> +        {
> +            get_page(mfn_to_page(buf_mfn), current->domain);
> +            buf_map = map_domain_page(mfn_x(buf_mfn));
> +            put_gfn(current->domain, buf_gfn);
> +        } else {
> +            put_gfn(current->domain, buf_gfn);
> +            return -EINVAL;
> +        }
> +    }

We could maybe avoid all this mechanism by doing a copy_from_user() of
the buffer contents directly into the new page, instead of an explicit
map-and-memcpy().

Cheers,

Tim.

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 15:55:22 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 15:55:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW8yg-000258-6s; Thu, 01 Dec 2011 15:55:14 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RW8ye-00024R-NC
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 15:55:12 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1322754873!6574787!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU2Nw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21367 invoked from network); 1 Dec 2011 15:54:33 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 15:54:33 -0000
X-IronPort-AV: E=Sophos;i="4.71,278,1320624000"; 
   d="scan'208";a="9234978"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Dec 2011 15:54:32 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 1 Dec 2011 15:54:32 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RW8y0-0003Px-EI; Thu, 01 Dec 2011 15:54:32 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RW8y0-0002A0-Ar;
	Thu, 01 Dec 2011 15:54:32 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20183.41784.323437.788869@mariner.uk.xensource.com>
Date: Thu, 1 Dec 2011 15:54:32 +0000
To: <rshriram@cs.ubc.ca>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <patchbomb.1321311101@athos.nss.cs.ubc.ca>
References: <patchbomb.1321311101@athos.nss.cs.ubc.ca>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: brendan@cs.ubc.ca, xen-devel@lists.xensource.com, ian.campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH 0 of 3 V7] libxc: checkpoint compression
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

rshriram@cs.ubc.ca writes ("[Xen-devel] [PATCH 0 of 3 V7] libxc: checkpoint compression"):
> This patch series adds checkpoint compression functionality, while
> running under Remus.
> 
> Changes since last version:
> 1. renamed page_aligned_alloc to xc_memalign and declare it as a global
>    function in xenctrl.h, instead of declaring it in xc_private.h

Thanks.

I have applied all three of these.

I fixed up a conflict in tools/libxc/xg_save_restore.h.  In particular
note that the new save file ids you allocated had to be changed to -12
and -13 since -11 had already been taken.

Ian.

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 15:55:22 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 15:55:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW8yg-000258-6s; Thu, 01 Dec 2011 15:55:14 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RW8ye-00024R-NC
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 15:55:12 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1322754873!6574787!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU2Nw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21367 invoked from network); 1 Dec 2011 15:54:33 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 15:54:33 -0000
X-IronPort-AV: E=Sophos;i="4.71,278,1320624000"; 
   d="scan'208";a="9234978"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Dec 2011 15:54:32 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 1 Dec 2011 15:54:32 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RW8y0-0003Px-EI; Thu, 01 Dec 2011 15:54:32 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RW8y0-0002A0-Ar;
	Thu, 01 Dec 2011 15:54:32 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20183.41784.323437.788869@mariner.uk.xensource.com>
Date: Thu, 1 Dec 2011 15:54:32 +0000
To: <rshriram@cs.ubc.ca>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <patchbomb.1321311101@athos.nss.cs.ubc.ca>
References: <patchbomb.1321311101@athos.nss.cs.ubc.ca>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: brendan@cs.ubc.ca, xen-devel@lists.xensource.com, ian.campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH 0 of 3 V7] libxc: checkpoint compression
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

rshriram@cs.ubc.ca writes ("[Xen-devel] [PATCH 0 of 3 V7] libxc: checkpoint compression"):
> This patch series adds checkpoint compression functionality, while
> running under Remus.
> 
> Changes since last version:
> 1. renamed page_aligned_alloc to xc_memalign and declare it as a global
>    function in xenctrl.h, instead of declaring it in xc_private.h

Thanks.

I have applied all three of these.

I fixed up a conflict in tools/libxc/xg_save_restore.h.  In particular
note that the new save file ids you allocated had to be changed to -12
and -13 since -11 had already been taken.

Ian.

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 15:59:47 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 15:59:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW92q-0002Qe-1R; Thu, 01 Dec 2011 15:59:32 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RW92o-0002QW-DD
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 15:59:30 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-11.tower-27.messagelabs.com!1322755118!47876852!1
X-Originating-IP: [208.97.132.66]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi42NiA9PiAxNDk4Mg==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15753 invoked from network); 1 Dec 2011 15:58:38 -0000
Received: from caiajhbdcagg.dreamhost.com (HELO homiemail-a13.g.dreamhost.com)
	(208.97.132.66) by server-11.tower-27.messagelabs.com with SMTP;
	1 Dec 2011 15:58:38 -0000
Received: from homiemail-a13.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a13.g.dreamhost.com (Postfix) with ESMTP id 8E10C334069;
	Thu,  1 Dec 2011 07:58:54 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=DwGfRuAXSbMsDyievGswvlh4yMbrBU/U1v/1YIZJAXOt
	isRW5OofEEkjZQfqQbvvnSMOxiHr0f0xEhKIoVC2HRvklMah5ieGyNeBq5bSfxX0
	m+jnEdjji+aaveYHWkUhsW8HoBcVM6JpOeEC1i9r0UXhWQauYI2Tg/Oxh5iDmcE=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=84/u7ntcWaxsg8DNQp0SsVJxj0k=; b=MFlqhHoX
	WuSpmVbtN9q3D2AEUdN6aKaX7+BNkc4Kb9ssXt3P3LWxWplO35Vd4JGJPetrW0FW
	BLfHbZ47nq5FsnW0ULU4T6iVN56KwzcUBdj2cRRwvunsT2WfmJEondfeNmCUMevY
	pH/KnyOPoEyXiWaEj0IEAA67PzhpCC7JouY=
Received: from webmail.lagarcavilla.org (ahfbbjcaiaae.dreamhost.com
	[75.119.208.4]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a13.g.dreamhost.com (Postfix) with ESMTPA id 01082334064; 
	Thu,  1 Dec 2011 07:58:52 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP; Thu, 1 Dec 2011 07:58:54 -0800
Message-ID: <ccdd32a797151f28b38992ad6de329b7.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20111201155334.GH61203@ocelot.phlegethon.org>
References: <patchbomb.1322603559@xdev.gridcentric.ca>
	<0ce71e5bfaac7e8fe5b8.1322603560@xdev.gridcentric.ca>
	<20111201155334.GH61203@ocelot.phlegethon.org>
Date: Thu, 1 Dec 2011 07:58:54 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Tim Deegan" <tim@xen.org>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, ian.campbell@citrix.com,
	andres@gridcentric.ca, keir.xen@gmail.com, jbeulich@suse.com,
	ian.jackson@citrix.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 1 of 2] After preparing a page for page-in,
 allow immediate fill-in of the page contents
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> Hi,
>
> This looks good to me.  I think it needs two more things to make it
> correct (as well as the tools patch 2/2):
>  - an update to the xenpaging tool to use the new interface; and
Sure, have it ready, will definitely cc Olaf for his ack on that one.
>  - a possible update to the paging state machine --- after all, if the
>    prep call allocates the pageand fills its contents, do we need
>    any more stages on the page-in path?
I am kind of torn about this. Maybe the pager wants to do a set of loads,
and then fire off many vcpu unpauses in a batched fashion (which is
possible with patches I submitted later).

This isn't a necessity for correctness, though. And we still need the
resume kick for cases like a guest accessing a page that has not been
paged out yet (p2m_ram_paging_out)

Andres

>
> One more comment below:
>
> At 16:52 -0500 on 29 Nov (1322585560), Andres Lagar-Cavilla wrote:
>> diff -r 4ee6d40edc2c -r 0ce71e5bfaac xen/arch/x86/mm/p2m.c
>> --- a/xen/arch/x86/mm/p2m.c
>> +++ b/xen/arch/x86/mm/p2m.c
>> @@ -974,14 +974,43 @@ void p2m_mem_paging_populate(struct doma
>>   * mfn if populate was called for  gfn which was nominated but not
>> evicted. In
>>   * this case only the p2mt needs to be forwarded.
>>   */
>> -int p2m_mem_paging_prep(struct domain *d, unsigned long gfn)
>> +int p2m_mem_paging_prep(struct domain *d, unsigned long gfn, uint64_t
>> buffer)
>>  {
>>      struct page_info *page;
>>      p2m_type_t p2mt;
>>      p2m_access_t a;
>> -    mfn_t mfn;
>> +    mfn_t mfn, buf_mfn = _mfn(INVALID_MFN);
>>      struct p2m_domain *p2m = p2m_get_hostp2m(d);
>> -    int ret;
>> +    int ret, page_extant = 1;
>> +    void *buf_map = NULL;
>> +
>> +    /* Map buffer page, if any, and get a reference */
>> +    if ( buffer )
>> +    {
>> +        l1_pgentry_t l1e;
>> +        unsigned long buf_gfn;
>> +        p2m_type_t buf_p2mt;
>> +
>> +        if ( (buffer & (PAGE_SIZE - 1)) ||
>> +             (!access_ok(buffer, PAGE_SIZE)) )
>> +            return -EINVAL;
>> +
>> +        guest_get_eff_l1e(current, buffer, &l1e);
>> +        buf_gfn = l1e_get_pfn(l1e);
>> +        buf_mfn = get_gfn(current->domain, buf_gfn,
>> +                            &buf_p2mt);
>> +
>> +        if ( likely( mfn_valid(buf_mfn) &&
>> +                     p2m_is_ram(buf_p2mt) ) )
>> +        {
>> +            get_page(mfn_to_page(buf_mfn), current->domain);
>> +            buf_map = map_domain_page(mfn_x(buf_mfn));
>> +            put_gfn(current->domain, buf_gfn);
>> +        } else {
>> +            put_gfn(current->domain, buf_gfn);
>> +            return -EINVAL;
>> +        }
>> +    }
>
> We could maybe avoid all this mechanism by doing a copy_from_user() of
> the buffer contents directly into the new page, instead of an explicit
> map-and-memcpy().
>
> Cheers,
>
> Tim.
>



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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 15:59:47 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 15:59:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW92q-0002Qe-1R; Thu, 01 Dec 2011 15:59:32 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RW92o-0002QW-DD
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 15:59:30 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-11.tower-27.messagelabs.com!1322755118!47876852!1
X-Originating-IP: [208.97.132.66]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi42NiA9PiAxNDk4Mg==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15753 invoked from network); 1 Dec 2011 15:58:38 -0000
Received: from caiajhbdcagg.dreamhost.com (HELO homiemail-a13.g.dreamhost.com)
	(208.97.132.66) by server-11.tower-27.messagelabs.com with SMTP;
	1 Dec 2011 15:58:38 -0000
Received: from homiemail-a13.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a13.g.dreamhost.com (Postfix) with ESMTP id 8E10C334069;
	Thu,  1 Dec 2011 07:58:54 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=DwGfRuAXSbMsDyievGswvlh4yMbrBU/U1v/1YIZJAXOt
	isRW5OofEEkjZQfqQbvvnSMOxiHr0f0xEhKIoVC2HRvklMah5ieGyNeBq5bSfxX0
	m+jnEdjji+aaveYHWkUhsW8HoBcVM6JpOeEC1i9r0UXhWQauYI2Tg/Oxh5iDmcE=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=84/u7ntcWaxsg8DNQp0SsVJxj0k=; b=MFlqhHoX
	WuSpmVbtN9q3D2AEUdN6aKaX7+BNkc4Kb9ssXt3P3LWxWplO35Vd4JGJPetrW0FW
	BLfHbZ47nq5FsnW0ULU4T6iVN56KwzcUBdj2cRRwvunsT2WfmJEondfeNmCUMevY
	pH/KnyOPoEyXiWaEj0IEAA67PzhpCC7JouY=
Received: from webmail.lagarcavilla.org (ahfbbjcaiaae.dreamhost.com
	[75.119.208.4]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a13.g.dreamhost.com (Postfix) with ESMTPA id 01082334064; 
	Thu,  1 Dec 2011 07:58:52 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP; Thu, 1 Dec 2011 07:58:54 -0800
Message-ID: <ccdd32a797151f28b38992ad6de329b7.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20111201155334.GH61203@ocelot.phlegethon.org>
References: <patchbomb.1322603559@xdev.gridcentric.ca>
	<0ce71e5bfaac7e8fe5b8.1322603560@xdev.gridcentric.ca>
	<20111201155334.GH61203@ocelot.phlegethon.org>
Date: Thu, 1 Dec 2011 07:58:54 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Tim Deegan" <tim@xen.org>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, ian.campbell@citrix.com,
	andres@gridcentric.ca, keir.xen@gmail.com, jbeulich@suse.com,
	ian.jackson@citrix.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 1 of 2] After preparing a page for page-in,
 allow immediate fill-in of the page contents
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> Hi,
>
> This looks good to me.  I think it needs two more things to make it
> correct (as well as the tools patch 2/2):
>  - an update to the xenpaging tool to use the new interface; and
Sure, have it ready, will definitely cc Olaf for his ack on that one.
>  - a possible update to the paging state machine --- after all, if the
>    prep call allocates the pageand fills its contents, do we need
>    any more stages on the page-in path?
I am kind of torn about this. Maybe the pager wants to do a set of loads,
and then fire off many vcpu unpauses in a batched fashion (which is
possible with patches I submitted later).

This isn't a necessity for correctness, though. And we still need the
resume kick for cases like a guest accessing a page that has not been
paged out yet (p2m_ram_paging_out)

Andres

>
> One more comment below:
>
> At 16:52 -0500 on 29 Nov (1322585560), Andres Lagar-Cavilla wrote:
>> diff -r 4ee6d40edc2c -r 0ce71e5bfaac xen/arch/x86/mm/p2m.c
>> --- a/xen/arch/x86/mm/p2m.c
>> +++ b/xen/arch/x86/mm/p2m.c
>> @@ -974,14 +974,43 @@ void p2m_mem_paging_populate(struct doma
>>   * mfn if populate was called for  gfn which was nominated but not
>> evicted. In
>>   * this case only the p2mt needs to be forwarded.
>>   */
>> -int p2m_mem_paging_prep(struct domain *d, unsigned long gfn)
>> +int p2m_mem_paging_prep(struct domain *d, unsigned long gfn, uint64_t
>> buffer)
>>  {
>>      struct page_info *page;
>>      p2m_type_t p2mt;
>>      p2m_access_t a;
>> -    mfn_t mfn;
>> +    mfn_t mfn, buf_mfn = _mfn(INVALID_MFN);
>>      struct p2m_domain *p2m = p2m_get_hostp2m(d);
>> -    int ret;
>> +    int ret, page_extant = 1;
>> +    void *buf_map = NULL;
>> +
>> +    /* Map buffer page, if any, and get a reference */
>> +    if ( buffer )
>> +    {
>> +        l1_pgentry_t l1e;
>> +        unsigned long buf_gfn;
>> +        p2m_type_t buf_p2mt;
>> +
>> +        if ( (buffer & (PAGE_SIZE - 1)) ||
>> +             (!access_ok(buffer, PAGE_SIZE)) )
>> +            return -EINVAL;
>> +
>> +        guest_get_eff_l1e(current, buffer, &l1e);
>> +        buf_gfn = l1e_get_pfn(l1e);
>> +        buf_mfn = get_gfn(current->domain, buf_gfn,
>> +                            &buf_p2mt);
>> +
>> +        if ( likely( mfn_valid(buf_mfn) &&
>> +                     p2m_is_ram(buf_p2mt) ) )
>> +        {
>> +            get_page(mfn_to_page(buf_mfn), current->domain);
>> +            buf_map = map_domain_page(mfn_x(buf_mfn));
>> +            put_gfn(current->domain, buf_gfn);
>> +        } else {
>> +            put_gfn(current->domain, buf_gfn);
>> +            return -EINVAL;
>> +        }
>> +    }
>
> We could maybe avoid all this mechanism by doing a copy_from_user() of
> the buffer contents directly into the new page, instead of an explicit
> map-and-memcpy().
>
> Cheers,
>
> Tim.
>



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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 16:04:47 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 16:04:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW97i-00036V-So; Thu, 01 Dec 2011 16:04:34 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RW97h-00036D-FK
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 16:04:33 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1322755432!3870290!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU2Nw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22440 invoked from network); 1 Dec 2011 16:03:53 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 16:03:53 -0000
X-IronPort-AV: E=Sophos;i="4.71,279,1320624000"; 
   d="scan'208";a="9235288"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Dec 2011 16:03:52 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 1 Dec 2011
	16:03:52 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefan Bader <stefan.bader@canonical.com>
Date: Thu, 1 Dec 2011 16:03:51 +0000
In-Reply-To: <4ED798B2.1040309@canonical.com>
References: <4ED798B2.1040309@canonical.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322755432.31810.244.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Xen 4.x / Linux 3.x (dom0 and HVM domU) and NIC
	handling
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2011-12-01 at 15:09 +0000, Stefan Bader wrote:
> Moving to public discussion...
> 
> This was found with Xen hypervisor version supporting device unplugging and the
> domU kernel having net-/blkfront and pci platform built-in (or as module).
> 
> The block device is defined as hda and the NIC type=ioemu (so theoretically
> guests without pv support would work, too).
> 
> Since both drivers are present, the kernel tries to unplug the emulated devices
> and succeeds. The blkfront driver detects the xvda device available in parallel
> and is working ok.
> 
> However the network interface does not work. There are entries present under
> sysfs for the xenbus but trying to bring it up fails with errors. And also there
> seems to be no mac address set (all zeros in sysfs).
> When the type=ioemu is removed in the configuration, this works.

Which toolstack are you using?

The weird thing is that, at least with xl, type=ioemu is the default for
an HVM guest.

What vif related entries do you get in xenstore, both front and backend?

Also what does your qemu-dm command line end up looking like?

> I have not much more debugging information beyond that, yet. But it sounds a bit
> like NICs should behave the same as block devices. So if there is an emulated
> device defined there will be an alternate paravirt interface for it and after
> unplugging the emulated ones we end up with the pv ones.

That is certainly the expectation.

> Is that something that can be seen with newer Xen versions, too (I am using 4.1.1)?

I appear to have some other problem with xen-unstable at the moment.
I've never noticed a problem in that past, although I don't habitually
use type=XXX at all in my vif configuration.

Ian.

> -Stefan



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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 16:04:47 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 16:04:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW97i-00036V-So; Thu, 01 Dec 2011 16:04:34 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RW97h-00036D-FK
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 16:04:33 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1322755432!3870290!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU2Nw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22440 invoked from network); 1 Dec 2011 16:03:53 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 16:03:53 -0000
X-IronPort-AV: E=Sophos;i="4.71,279,1320624000"; 
   d="scan'208";a="9235288"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Dec 2011 16:03:52 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 1 Dec 2011
	16:03:52 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefan Bader <stefan.bader@canonical.com>
Date: Thu, 1 Dec 2011 16:03:51 +0000
In-Reply-To: <4ED798B2.1040309@canonical.com>
References: <4ED798B2.1040309@canonical.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322755432.31810.244.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Xen 4.x / Linux 3.x (dom0 and HVM domU) and NIC
	handling
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2011-12-01 at 15:09 +0000, Stefan Bader wrote:
> Moving to public discussion...
> 
> This was found with Xen hypervisor version supporting device unplugging and the
> domU kernel having net-/blkfront and pci platform built-in (or as module).
> 
> The block device is defined as hda and the NIC type=ioemu (so theoretically
> guests without pv support would work, too).
> 
> Since both drivers are present, the kernel tries to unplug the emulated devices
> and succeeds. The blkfront driver detects the xvda device available in parallel
> and is working ok.
> 
> However the network interface does not work. There are entries present under
> sysfs for the xenbus but trying to bring it up fails with errors. And also there
> seems to be no mac address set (all zeros in sysfs).
> When the type=ioemu is removed in the configuration, this works.

Which toolstack are you using?

The weird thing is that, at least with xl, type=ioemu is the default for
an HVM guest.

What vif related entries do you get in xenstore, both front and backend?

Also what does your qemu-dm command line end up looking like?

> I have not much more debugging information beyond that, yet. But it sounds a bit
> like NICs should behave the same as block devices. So if there is an emulated
> device defined there will be an alternate paravirt interface for it and after
> unplugging the emulated ones we end up with the pv ones.

That is certainly the expectation.

> Is that something that can be seen with newer Xen versions, too (I am using 4.1.1)?

I appear to have some other problem with xen-unstable at the moment.
I've never noticed a problem in that past, although I don't habitually
use type=XXX at all in my vif configuration.

Ian.

> -Stefan



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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 16:06:58 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 16:06:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW99p-0003GP-Qa; Thu, 01 Dec 2011 16:06:45 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RW99n-0003Fs-Oe
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 16:06:43 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1322755563!3891203!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU2Nw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15412 invoked from network); 1 Dec 2011 16:06:03 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 16:06:03 -0000
X-IronPort-AV: E=Sophos;i="4.71,279,1320624000"; 
   d="scan'208";a="9235338"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Dec 2011 16:06:03 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 1 Dec 2011 16:06:03 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RW998-0003Tr-U0; Thu, 01 Dec 2011 16:06:02 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RW998-0002Cn-SK;
	Thu, 01 Dec 2011 16:06:02 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20183.42474.862718.429910@mariner.uk.xensource.com>
Date: Thu, 1 Dec 2011 16:06:02 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1322731389.31810.165.camel@zakaz.uk.xensource.com>
References: <patchbomb.1322576442@cosworth.uk.xensource.com>
	<37b46c492f8ac8d356b2.1322576453@cosworth.uk.xensource.com>
	<20111130205037.GA5176@aepfle.de>
	<1322731389.31810.165.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Olaf Hering <olaf@aepfle.de>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 11 of 17 v3] docs: generate an index for the
 html output
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("Re: [Xen-devel] [PATCH 11 of 17 v3] docs: generate an index for the html output"):
> docs: implement uniq instead of depending on List::MoreUtils

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 16:06:58 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 16:06:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW99p-0003GP-Qa; Thu, 01 Dec 2011 16:06:45 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RW99n-0003Fs-Oe
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 16:06:43 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1322755563!3891203!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU2Nw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15412 invoked from network); 1 Dec 2011 16:06:03 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 16:06:03 -0000
X-IronPort-AV: E=Sophos;i="4.71,279,1320624000"; 
   d="scan'208";a="9235338"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Dec 2011 16:06:03 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 1 Dec 2011 16:06:03 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RW998-0003Tr-U0; Thu, 01 Dec 2011 16:06:02 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RW998-0002Cn-SK;
	Thu, 01 Dec 2011 16:06:02 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20183.42474.862718.429910@mariner.uk.xensource.com>
Date: Thu, 1 Dec 2011 16:06:02 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1322731389.31810.165.camel@zakaz.uk.xensource.com>
References: <patchbomb.1322576442@cosworth.uk.xensource.com>
	<37b46c492f8ac8d356b2.1322576453@cosworth.uk.xensource.com>
	<20111130205037.GA5176@aepfle.de>
	<1322731389.31810.165.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Olaf Hering <olaf@aepfle.de>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 11 of 17 v3] docs: generate an index for the
 html output
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("Re: [Xen-devel] [PATCH 11 of 17 v3] docs: generate an index for the html output"):
> docs: implement uniq instead of depending on List::MoreUtils

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 16:12:07 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 16:12:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW9Em-0003Zx-RV; Thu, 01 Dec 2011 16:11:52 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RW9Em-0003ZF-A4
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 16:11:52 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1322755872!5784897!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU2Nw==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32526 invoked from network); 1 Dec 2011 16:11:12 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 16:11:12 -0000
X-IronPort-AV: E=Sophos;i="4.71,279,1320624000"; 
   d="scan'208";a="9235477"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Dec 2011 16:11:12 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 1 Dec 2011 16:11:12 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RW9E4-0003Vu-Ic; Thu, 01 Dec 2011 16:11:08 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RW9E4-0002Dj-Hg;
	Thu, 01 Dec 2011 16:11:08 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20183.42780.535637.521533@mariner.uk.xensource.com>
Date: Thu, 1 Dec 2011 16:11:08 +0000
To: <andres@lagarcavilla.org>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <46e688f8f091ced3a0d5458280392477.squirrel@webmail.lagarcavilla.org>
References: <patchbomb.1322603559@xdev.gridcentric.ca>
	<0ce71e5bfaac7e8fe5b8.1322603560@xdev.gridcentric.ca>
	<20182.16827.193505.730789@mariner.uk.xensource.com>
	<46e688f8f091ced3a0d5458280392477.squirrel@webmail.lagarcavilla.org>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <ian.campbell@citrix.com>,
	"andres@gridcentric.ca" <andres@gridcentric.ca>,
	"Tim \(Xen.org\)" <tim@xen.org>, "keir.xen@gmail.com" <keir.xen@gmail.com>,
	"JBeulich@suse.com" <jbeulich@suse.com>,
	"adin@gridcentric.ca" <adin@gridcentric.ca>
Subject: Re: [Xen-devel] [PATCH 1 of 2] After preparing a page for page-in,
 allow immediate fill-in of the page contents
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Andres Lagar-Cavilla writes ("Re: [Xen-devel] [PATCH 1 of 2] After preparing a page for page-in, allow immediate fill-in of the page contents"):
> I turned the field into a union of the same size, so it should be binary
> compatible. Should...

So you did.  Yesterday I thought it was a struct.  Sorry for being
confused.

Ian.

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 16:12:07 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 16:12:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW9Em-0003Zx-RV; Thu, 01 Dec 2011 16:11:52 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RW9Em-0003ZF-A4
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 16:11:52 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1322755872!5784897!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU2Nw==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32526 invoked from network); 1 Dec 2011 16:11:12 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 16:11:12 -0000
X-IronPort-AV: E=Sophos;i="4.71,279,1320624000"; 
   d="scan'208";a="9235477"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Dec 2011 16:11:12 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 1 Dec 2011 16:11:12 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RW9E4-0003Vu-Ic; Thu, 01 Dec 2011 16:11:08 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RW9E4-0002Dj-Hg;
	Thu, 01 Dec 2011 16:11:08 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20183.42780.535637.521533@mariner.uk.xensource.com>
Date: Thu, 1 Dec 2011 16:11:08 +0000
To: <andres@lagarcavilla.org>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <46e688f8f091ced3a0d5458280392477.squirrel@webmail.lagarcavilla.org>
References: <patchbomb.1322603559@xdev.gridcentric.ca>
	<0ce71e5bfaac7e8fe5b8.1322603560@xdev.gridcentric.ca>
	<20182.16827.193505.730789@mariner.uk.xensource.com>
	<46e688f8f091ced3a0d5458280392477.squirrel@webmail.lagarcavilla.org>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <ian.campbell@citrix.com>,
	"andres@gridcentric.ca" <andres@gridcentric.ca>,
	"Tim \(Xen.org\)" <tim@xen.org>, "keir.xen@gmail.com" <keir.xen@gmail.com>,
	"JBeulich@suse.com" <jbeulich@suse.com>,
	"adin@gridcentric.ca" <adin@gridcentric.ca>
Subject: Re: [Xen-devel] [PATCH 1 of 2] After preparing a page for page-in,
 allow immediate fill-in of the page contents
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Andres Lagar-Cavilla writes ("Re: [Xen-devel] [PATCH 1 of 2] After preparing a page for page-in, allow immediate fill-in of the page contents"):
> I turned the field into a union of the same size, so it should be binary
> compatible. Should...

So you did.  Yesterday I thought it was a struct.  Sorry for being
confused.

Ian.

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 16:18:21 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 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.xensource.com>)
	id 1RW9Kf-0003rZ-OS; Thu, 01 Dec 2011 16:17:57 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RW9Ke-0003rT-FE
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 16:17:56 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-2.tower-27.messagelabs.com!1322756197!55654905!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5549 invoked from network); 1 Dec 2011 16:16:37 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-2.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 1 Dec 2011 16:16:37 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RW9K2-000GnV-Kv; Thu, 01 Dec 2011 16:17:18 +0000
Date: Thu, 1 Dec 2011 16:17:18 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20111201161718.GI61203@ocelot.phlegethon.org>
References: <patchbomb.1322603903@xdev.gridcentric.ca>
	<d6354df726a063740423.1322603904@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <d6354df726a063740423.1322603904@xdev.gridcentric.ca>
User-Agent: Mutt/1.4.2.1i
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com, keir.xen@gmail.com,
	JBeulich@suse.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 1 of 2] x86/mm: When mem event automatically
	promotes access rights, let other subsystems know
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi, 

At 16:58 -0500 on 29 Nov (1322585904), Andres Lagar-Cavilla wrote:
>  xen/arch/x86/hvm/hvm.c    |  45 ++++++++++++++++++++++++++++++++++++++-------
>  xen/arch/x86/mm/p2m.c     |   8 +++++---
>  xen/include/asm-x86/p2m.h |   9 +++++----
>  3 files changed, 48 insertions(+), 14 deletions(-)
> 
> 
> The mem event fault handler in the p2m can automatically promote the access
> rights of a p2m entry. In those scenarios, vcpu's are not paused and they will
> immediately retry the faulting instructions. This will generate a second fault
> if the underlying entry type requires so (paging, unsharing, pod, etc).
> Collapse the two faults into a single one.
> 
> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
> 
> diff -r 29701f5bdd84 -r d6354df726a0 xen/arch/x86/hvm/hvm.c
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -1278,9 +1278,13 @@ int hvm_hap_nested_page_fault(unsigned l
>  
>          if ( violation )
>          {
> -            p2m_mem_access_check(gpa, gla_valid, gla, access_r, access_w, access_x);
> -            rc = 1;
> -            goto out_put_gfn;
> +            if ( !p2m_mem_access_check(gpa, gla_valid, gla, access_r, 
> +                                        access_w, access_x) )
> +            {
> +                /* Rights not promoted, vcpu paused, work here is done */
> +                rc = 1;
> +                goto out_put_gfn;
> +            }
>          }
>      }
>  
> @@ -1288,7 +1292,8 @@ int hvm_hap_nested_page_fault(unsigned l
>       * If this GFN is emulated MMIO or marked as read-only, pass the fault
>       * to the mmio handler.
>       */
> -    if ( (p2mt == p2m_mmio_dm) || (p2mt == p2m_ram_ro) )
> +    if ( (p2mt == p2m_mmio_dm) || 
> +         (access_w && (p2mt == p2m_ram_ro)) )

I think this is a separate change from the main intent of the patch; it
would be better to have two patches, once that inserts all these
'access_w' checks and a second that does what the cset comment
decribes. 

>      {
>          if ( !handle_mmio() )
>              hvm_inject_exception(TRAP_gp_fault, 0, 0);
> @@ -1302,7 +1307,7 @@ int hvm_hap_nested_page_fault(unsigned l
>          p2m_mem_paging_populate(v->domain, gfn);
>  
>      /* Mem sharing: unshare the page and try again */
> -    if ( p2mt == p2m_ram_shared )
> +    if ( access_w && (p2mt == p2m_ram_shared) )
>      {
>          ASSERT(!p2m_is_nestedp2m(p2m));
>          mem_sharing_unshare_page(p2m->domain, gfn, 0);
> @@ -1319,14 +1324,15 @@ int hvm_hap_nested_page_fault(unsigned l
>           * a large page, we do not change other pages type within that large
>           * page.
>           */
> -        paging_mark_dirty(v->domain, mfn_x(mfn));
> +        if ( access_w )
> +            paging_mark_dirty(v->domain, mfn_x(mfn));
>          p2m_change_type(v->domain, gfn, p2m_ram_logdirty, p2m_ram_rw);

No!  If we call p2m_change_type(-->ram_rw) we _must_ call mark_dirty()
too.  It would be OK to put both lines under the test, though. 

>          rc = 1;
>          goto out_put_gfn;
>      }
>  
>      /* Shouldn't happen: Maybe the guest was writing to a r/o grant mapping? */
> -    if ( p2mt == p2m_grant_map_ro )
> +    if ( access_w && (p2mt == p2m_grant_map_ro) )
>      {
>          gdprintk(XENLOG_WARNING,
>                   "trying to write to read-only grant mapping\n");
> @@ -1335,6 +1341,31 @@ int hvm_hap_nested_page_fault(unsigned l
>          goto out_put_gfn;
>      }
>  
> +    if ( access_x && (p2m_is_grant(p2mt)) )
> +    {
> +        gdprintk(XENLOG_WARNING,
> +                 "trying to execut a grant mapping\n");
> +        hvm_inject_exception(TRAP_gp_fault, 0, 0);
> +        rc = 1;
> +        goto out_put_gfn;
> +    }

Again, this is a separate bugfix and should go in its own patch.

> +    if ( p2m_is_grant(p2mt) )
> +    {
> +        /* If we haven't caught this by now, then it's a valid access */
> +        rc = 1;
> +        goto out_put_gfn;
> +    }
> +    if ( p2mt == p2m_mmio_direct )
> +    {
> +        if ( !(access_w && 
> +                rangeset_contains_singleton(mmio_ro_ranges, mfn_x(mfn))) ) {
> +            rc = 1;
> +            goto out_put_gfn;
> +        }
> +    }

I wonder whether, rather than trying to enumerate all the acceptable
cases here, you could just remember that p2m_mem_access_check() changed
something and always return 1 in that case. 

> +
>      rc = 0;
>  out_put_gfn:
>      put_gfn(p2m->domain, gfn);
> diff -r 29701f5bdd84 -r d6354df726a0 xen/arch/x86/mm/p2m.c
> --- a/xen/arch/x86/mm/p2m.c
> +++ b/xen/arch/x86/mm/p2m.c
> @@ -1126,7 +1126,7 @@ void p2m_mem_paging_resume(struct domain
>      mem_event_unpause_vcpus(d, &d->mem_paging);
>  }
>  
> -void p2m_mem_access_check(unsigned long gpa, bool_t gla_valid, unsigned long gla, 
> +int p2m_mem_access_check(unsigned long gpa, bool_t gla_valid, unsigned long gla, 
>                            bool_t access_r, bool_t access_w, bool_t access_x)
>  {
>      struct vcpu *v = current;
> @@ -1146,7 +1146,7 @@ void p2m_mem_access_check(unsigned long 
>      {
>          p2m->set_entry(p2m, gfn, mfn, PAGE_ORDER_4K, p2mt, p2m_access_rw);
>          p2m_unlock(p2m);
> -        return;
> +        return 1;
>      }
>      p2m_unlock(p2m);
>  
> @@ -1166,9 +1166,10 @@ void p2m_mem_access_check(unsigned long 
>              p2m_lock(p2m);
>              p2m->set_entry(p2m, gfn, mfn, PAGE_ORDER_4K, p2mt, p2m_access_rwx);
>              p2m_unlock(p2m);
> +            return 1;
>          }
>  
> -        return;
> +        return 0;
>      }
>  
>      memset(&req, 0, sizeof(req));
> @@ -1192,6 +1193,7 @@ void p2m_mem_access_check(unsigned long 
>  
>      (void)mem_event_put_request(d, &d->mem_access, &req);
>      /* VCPU paused */
> +    return 0;
>  }
>  
>  void p2m_mem_access_resume(struct domain *d)
> diff -r 29701f5bdd84 -r d6354df726a0 xen/include/asm-x86/p2m.h
> --- a/xen/include/asm-x86/p2m.h
> +++ b/xen/include/asm-x86/p2m.h
> @@ -491,8 +491,9 @@ static inline void p2m_mem_paging_popula
>  
>  #ifdef __x86_64__
>  /* Send mem event based on the access (gla is -1ull if not available).  Handles
> - * the rw2rx conversion */
> -void p2m_mem_access_check(unsigned long gpa, bool_t gla_valid, unsigned long gla, 
> + * the rw2rx conversion. Return value indicate if access rights have been
> + * promoted with no underlying vcpu pause. */

How does it indicate that -- i.e., what values can it return and what do
they mean?  (And if it only returns 0 or 1, maybe use bool_t.)

Cheers,

Tim.

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 16:18:21 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 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.xensource.com>)
	id 1RW9Kf-0003rZ-OS; Thu, 01 Dec 2011 16:17:57 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RW9Ke-0003rT-FE
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 16:17:56 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-2.tower-27.messagelabs.com!1322756197!55654905!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5549 invoked from network); 1 Dec 2011 16:16:37 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-2.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 1 Dec 2011 16:16:37 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RW9K2-000GnV-Kv; Thu, 01 Dec 2011 16:17:18 +0000
Date: Thu, 1 Dec 2011 16:17:18 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20111201161718.GI61203@ocelot.phlegethon.org>
References: <patchbomb.1322603903@xdev.gridcentric.ca>
	<d6354df726a063740423.1322603904@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <d6354df726a063740423.1322603904@xdev.gridcentric.ca>
User-Agent: Mutt/1.4.2.1i
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com, keir.xen@gmail.com,
	JBeulich@suse.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 1 of 2] x86/mm: When mem event automatically
	promotes access rights, let other subsystems know
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi, 

At 16:58 -0500 on 29 Nov (1322585904), Andres Lagar-Cavilla wrote:
>  xen/arch/x86/hvm/hvm.c    |  45 ++++++++++++++++++++++++++++++++++++++-------
>  xen/arch/x86/mm/p2m.c     |   8 +++++---
>  xen/include/asm-x86/p2m.h |   9 +++++----
>  3 files changed, 48 insertions(+), 14 deletions(-)
> 
> 
> The mem event fault handler in the p2m can automatically promote the access
> rights of a p2m entry. In those scenarios, vcpu's are not paused and they will
> immediately retry the faulting instructions. This will generate a second fault
> if the underlying entry type requires so (paging, unsharing, pod, etc).
> Collapse the two faults into a single one.
> 
> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
> 
> diff -r 29701f5bdd84 -r d6354df726a0 xen/arch/x86/hvm/hvm.c
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -1278,9 +1278,13 @@ int hvm_hap_nested_page_fault(unsigned l
>  
>          if ( violation )
>          {
> -            p2m_mem_access_check(gpa, gla_valid, gla, access_r, access_w, access_x);
> -            rc = 1;
> -            goto out_put_gfn;
> +            if ( !p2m_mem_access_check(gpa, gla_valid, gla, access_r, 
> +                                        access_w, access_x) )
> +            {
> +                /* Rights not promoted, vcpu paused, work here is done */
> +                rc = 1;
> +                goto out_put_gfn;
> +            }
>          }
>      }
>  
> @@ -1288,7 +1292,8 @@ int hvm_hap_nested_page_fault(unsigned l
>       * If this GFN is emulated MMIO or marked as read-only, pass the fault
>       * to the mmio handler.
>       */
> -    if ( (p2mt == p2m_mmio_dm) || (p2mt == p2m_ram_ro) )
> +    if ( (p2mt == p2m_mmio_dm) || 
> +         (access_w && (p2mt == p2m_ram_ro)) )

I think this is a separate change from the main intent of the patch; it
would be better to have two patches, once that inserts all these
'access_w' checks and a second that does what the cset comment
decribes. 

>      {
>          if ( !handle_mmio() )
>              hvm_inject_exception(TRAP_gp_fault, 0, 0);
> @@ -1302,7 +1307,7 @@ int hvm_hap_nested_page_fault(unsigned l
>          p2m_mem_paging_populate(v->domain, gfn);
>  
>      /* Mem sharing: unshare the page and try again */
> -    if ( p2mt == p2m_ram_shared )
> +    if ( access_w && (p2mt == p2m_ram_shared) )
>      {
>          ASSERT(!p2m_is_nestedp2m(p2m));
>          mem_sharing_unshare_page(p2m->domain, gfn, 0);
> @@ -1319,14 +1324,15 @@ int hvm_hap_nested_page_fault(unsigned l
>           * a large page, we do not change other pages type within that large
>           * page.
>           */
> -        paging_mark_dirty(v->domain, mfn_x(mfn));
> +        if ( access_w )
> +            paging_mark_dirty(v->domain, mfn_x(mfn));
>          p2m_change_type(v->domain, gfn, p2m_ram_logdirty, p2m_ram_rw);

No!  If we call p2m_change_type(-->ram_rw) we _must_ call mark_dirty()
too.  It would be OK to put both lines under the test, though. 

>          rc = 1;
>          goto out_put_gfn;
>      }
>  
>      /* Shouldn't happen: Maybe the guest was writing to a r/o grant mapping? */
> -    if ( p2mt == p2m_grant_map_ro )
> +    if ( access_w && (p2mt == p2m_grant_map_ro) )
>      {
>          gdprintk(XENLOG_WARNING,
>                   "trying to write to read-only grant mapping\n");
> @@ -1335,6 +1341,31 @@ int hvm_hap_nested_page_fault(unsigned l
>          goto out_put_gfn;
>      }
>  
> +    if ( access_x && (p2m_is_grant(p2mt)) )
> +    {
> +        gdprintk(XENLOG_WARNING,
> +                 "trying to execut a grant mapping\n");
> +        hvm_inject_exception(TRAP_gp_fault, 0, 0);
> +        rc = 1;
> +        goto out_put_gfn;
> +    }

Again, this is a separate bugfix and should go in its own patch.

> +    if ( p2m_is_grant(p2mt) )
> +    {
> +        /* If we haven't caught this by now, then it's a valid access */
> +        rc = 1;
> +        goto out_put_gfn;
> +    }
> +    if ( p2mt == p2m_mmio_direct )
> +    {
> +        if ( !(access_w && 
> +                rangeset_contains_singleton(mmio_ro_ranges, mfn_x(mfn))) ) {
> +            rc = 1;
> +            goto out_put_gfn;
> +        }
> +    }

I wonder whether, rather than trying to enumerate all the acceptable
cases here, you could just remember that p2m_mem_access_check() changed
something and always return 1 in that case. 

> +
>      rc = 0;
>  out_put_gfn:
>      put_gfn(p2m->domain, gfn);
> diff -r 29701f5bdd84 -r d6354df726a0 xen/arch/x86/mm/p2m.c
> --- a/xen/arch/x86/mm/p2m.c
> +++ b/xen/arch/x86/mm/p2m.c
> @@ -1126,7 +1126,7 @@ void p2m_mem_paging_resume(struct domain
>      mem_event_unpause_vcpus(d, &d->mem_paging);
>  }
>  
> -void p2m_mem_access_check(unsigned long gpa, bool_t gla_valid, unsigned long gla, 
> +int p2m_mem_access_check(unsigned long gpa, bool_t gla_valid, unsigned long gla, 
>                            bool_t access_r, bool_t access_w, bool_t access_x)
>  {
>      struct vcpu *v = current;
> @@ -1146,7 +1146,7 @@ void p2m_mem_access_check(unsigned long 
>      {
>          p2m->set_entry(p2m, gfn, mfn, PAGE_ORDER_4K, p2mt, p2m_access_rw);
>          p2m_unlock(p2m);
> -        return;
> +        return 1;
>      }
>      p2m_unlock(p2m);
>  
> @@ -1166,9 +1166,10 @@ void p2m_mem_access_check(unsigned long 
>              p2m_lock(p2m);
>              p2m->set_entry(p2m, gfn, mfn, PAGE_ORDER_4K, p2mt, p2m_access_rwx);
>              p2m_unlock(p2m);
> +            return 1;
>          }
>  
> -        return;
> +        return 0;
>      }
>  
>      memset(&req, 0, sizeof(req));
> @@ -1192,6 +1193,7 @@ void p2m_mem_access_check(unsigned long 
>  
>      (void)mem_event_put_request(d, &d->mem_access, &req);
>      /* VCPU paused */
> +    return 0;
>  }
>  
>  void p2m_mem_access_resume(struct domain *d)
> diff -r 29701f5bdd84 -r d6354df726a0 xen/include/asm-x86/p2m.h
> --- a/xen/include/asm-x86/p2m.h
> +++ b/xen/include/asm-x86/p2m.h
> @@ -491,8 +491,9 @@ static inline void p2m_mem_paging_popula
>  
>  #ifdef __x86_64__
>  /* Send mem event based on the access (gla is -1ull if not available).  Handles
> - * the rw2rx conversion */
> -void p2m_mem_access_check(unsigned long gpa, bool_t gla_valid, unsigned long gla, 
> + * the rw2rx conversion. Return value indicate if access rights have been
> + * promoted with no underlying vcpu pause. */

How does it indicate that -- i.e., what values can it return and what do
they mean?  (And if it only returns 0 or 1, maybe use bool_t.)

Cheers,

Tim.

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 16:21:27 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 16: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.xensource.com>)
	id 1RW9Nl-0003yu-Ba; Thu, 01 Dec 2011 16:21:09 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RW9Nj-0003yd-Jh
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 16:21:07 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1322756427!4964276!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU2Nw==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13535 invoked from network); 1 Dec 2011 16:20:28 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 16:20:28 -0000
X-IronPort-AV: E=Sophos;i="4.71,279,1320624000"; 
   d="scan'208";a="9235781"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Dec 2011 16:20:27 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 1 Dec 2011 16:20:27 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RW9N5-0003Z9-6B; Thu, 01 Dec 2011 16:20:27 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RW9N5-0002FS-5F;
	Thu, 01 Dec 2011 16:20:27 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20183.43339.148707.739163@mariner.uk.xensource.com>
Date: Thu, 1 Dec 2011 16:20:27 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1322648774.31810.69.camel@zakaz.uk.xensource.com>
References: <osstest-10135-mainreport@xen.org>
	<20179.30537.970866.190935@mariner.uk.xensource.com>
	<1322648774.31810.69.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [xen-unstable test] 10135: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("Re: [Xen-devel] [xen-unstable test] 10135: regressions - FAIL"):
> AIUI the tester is now installs libaio1 so we can revert this one?

Yes, I've done so.

# HG changeset patch
# User Ian Jackson <Ian.Jackson@eu.citrix.com>
# Date 1322756338 0
# Node ID a07e45d2aa7f792674b6325b11a48d297fd4d075
# Parent  7b180380681db3382f7c2f38e096bc551aa301d2
tools: Switch to system libaio (again)

The test system problems which prompted 24233:a9c67c2daf4b (itself a
tiny partial revert of 24184:4ecd3615e726 / 24186:7aa5838499d1) have
now been resolved, we think.  So revert 24233.

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

diff -r 7b180380681d -r a07e45d2aa7f Config.mk
--- a/Config.mk	Thu Dec 01 16:05:51 2011 +0000
+++ b/Config.mk	Thu Dec 01 16:18:58 2011 +0000
@@ -232,7 +232,7 @@ PYTHON_TOOLS       ?= y
 OCAML_TOOLS        ?= y
 CONFIG_MINITERM    ?= n
 CONFIG_LOMOUNT     ?= n
-CONFIG_SYSTEM_LIBAIO ?= n
+CONFIG_SYSTEM_LIBAIO ?= y
 
 ifeq ($(OCAML_TOOLS),y)
 OCAML_TOOLS := $(shell ocamlopt -v > /dev/null 2>&1 && echo "y" || echo "n")

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 16:21:27 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 16: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.xensource.com>)
	id 1RW9Nl-0003yu-Ba; Thu, 01 Dec 2011 16:21:09 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RW9Nj-0003yd-Jh
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 16:21:07 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1322756427!4964276!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU2Nw==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13535 invoked from network); 1 Dec 2011 16:20:28 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 16:20:28 -0000
X-IronPort-AV: E=Sophos;i="4.71,279,1320624000"; 
   d="scan'208";a="9235781"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Dec 2011 16:20:27 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 1 Dec 2011 16:20:27 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RW9N5-0003Z9-6B; Thu, 01 Dec 2011 16:20:27 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RW9N5-0002FS-5F;
	Thu, 01 Dec 2011 16:20:27 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20183.43339.148707.739163@mariner.uk.xensource.com>
Date: Thu, 1 Dec 2011 16:20:27 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1322648774.31810.69.camel@zakaz.uk.xensource.com>
References: <osstest-10135-mainreport@xen.org>
	<20179.30537.970866.190935@mariner.uk.xensource.com>
	<1322648774.31810.69.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [xen-unstable test] 10135: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("Re: [Xen-devel] [xen-unstable test] 10135: regressions - FAIL"):
> AIUI the tester is now installs libaio1 so we can revert this one?

Yes, I've done so.

# HG changeset patch
# User Ian Jackson <Ian.Jackson@eu.citrix.com>
# Date 1322756338 0
# Node ID a07e45d2aa7f792674b6325b11a48d297fd4d075
# Parent  7b180380681db3382f7c2f38e096bc551aa301d2
tools: Switch to system libaio (again)

The test system problems which prompted 24233:a9c67c2daf4b (itself a
tiny partial revert of 24184:4ecd3615e726 / 24186:7aa5838499d1) have
now been resolved, we think.  So revert 24233.

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

diff -r 7b180380681d -r a07e45d2aa7f Config.mk
--- a/Config.mk	Thu Dec 01 16:05:51 2011 +0000
+++ b/Config.mk	Thu Dec 01 16:18:58 2011 +0000
@@ -232,7 +232,7 @@ PYTHON_TOOLS       ?= y
 OCAML_TOOLS        ?= y
 CONFIG_MINITERM    ?= n
 CONFIG_LOMOUNT     ?= n
-CONFIG_SYSTEM_LIBAIO ?= n
+CONFIG_SYSTEM_LIBAIO ?= y
 
 ifeq ($(OCAML_TOOLS),y)
 OCAML_TOOLS := $(shell ocamlopt -v > /dev/null 2>&1 && echo "y" || echo "n")

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 16:23:25 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 16:23:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW9Pm-00046n-N2; Thu, 01 Dec 2011 16:23:14 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RW9Pk-00045l-UF
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 16:23:13 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-14.tower-21.messagelabs.com!1322756552!6591257!1
X-Originating-IP: [208.97.132.119]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xMTkgPT4gMTU4ODc=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21941 invoked from network); 1 Dec 2011 16:22:32 -0000
Received: from caiajhbdcbbj.dreamhost.com (HELO homiemail-a13.g.dreamhost.com)
	(208.97.132.119) by server-14.tower-21.messagelabs.com with SMTP;
	1 Dec 2011 16:22:32 -0000
Received: from homiemail-a13.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a13.g.dreamhost.com (Postfix) with ESMTP id A2D1E33406B;
	Thu,  1 Dec 2011 08:22:31 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id:date
	:from:to:cc; q=dns; s=lagarcavilla.org; b=DJC7QMvdNo0RskwmuSbTko
	JKo8c6IOkB4ppP+j9FDTWh1wNtihHnoYjSDu7lpc7QGzQxnw+jEvbt14YtGfl0E1
	Scl9SkzAzQJY8bvBQdj9lqT1y6ltzJGb7Y7I7NqzIAUyz7JMH39WiT8PiLiu+t6G
	gMjGQYrzArfWjPm5lnuhY=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:date:from:to:cc; s=lagarcavilla.org; bh=dVy5HDb2QZIt
	qS0Qv0G8JbQwiUs=; b=I880/i3gWKfQp0rFCcKT5KFp3dqcYtqbHrN9Nits2i/6
	t4u3ubYy1qD9OwrBn+pXM/mMV5OMD3ZzNpNlypvPaiNlDJJIMuj4zLAEVazUkkk3
	smH2yhadGcY+pKOCf1Ajqzab4EbTD6jspqdUb8fGFo0HDmDVVh7vKIvDIlgz/7U=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a13.g.dreamhost.com (Postfix) with ESMTPSA id C225D334064; 
	Thu,  1 Dec 2011 08:22:30 -0800 (PST)
MIME-Version: 1.0
Message-Id: <patchbomb.1322756504@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Thu, 01 Dec 2011 11:21:44 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, keir.xen@gmail.com, tim@xen.org, JBeulich@suse.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 0 of 3] Bugfixes resend
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Resending three bug fix patches after feedback from Tim Deegan and Jan 
Also rebased against 3c4c29899d8a.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

 xen/include/asm-x86/page.h        |  18 ++++++++++++-
 xen/include/asm-x86/x86_64/page.h |   5 +++
 xen/arch/x86/hvm/hvm.c            |  54 ++++++++++++++++++++++++++------------
 xen/arch/x86/hvm/svm/nestedsvm.c  |   6 ----
 xen/arch/x86/hvm/vmx/vvmx.c       |  11 +------
 xen/arch/x86/mm.c                 |  12 +++++--
 6 files changed, 69 insertions(+), 37 deletions(-)

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 16:23:25 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 16:23:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW9Pm-00046n-N2; Thu, 01 Dec 2011 16:23:14 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RW9Pk-00045l-UF
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 16:23:13 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-14.tower-21.messagelabs.com!1322756552!6591257!1
X-Originating-IP: [208.97.132.119]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xMTkgPT4gMTU4ODc=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21941 invoked from network); 1 Dec 2011 16:22:32 -0000
Received: from caiajhbdcbbj.dreamhost.com (HELO homiemail-a13.g.dreamhost.com)
	(208.97.132.119) by server-14.tower-21.messagelabs.com with SMTP;
	1 Dec 2011 16:22:32 -0000
Received: from homiemail-a13.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a13.g.dreamhost.com (Postfix) with ESMTP id A2D1E33406B;
	Thu,  1 Dec 2011 08:22:31 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id:date
	:from:to:cc; q=dns; s=lagarcavilla.org; b=DJC7QMvdNo0RskwmuSbTko
	JKo8c6IOkB4ppP+j9FDTWh1wNtihHnoYjSDu7lpc7QGzQxnw+jEvbt14YtGfl0E1
	Scl9SkzAzQJY8bvBQdj9lqT1y6ltzJGb7Y7I7NqzIAUyz7JMH39WiT8PiLiu+t6G
	gMjGQYrzArfWjPm5lnuhY=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:date:from:to:cc; s=lagarcavilla.org; bh=dVy5HDb2QZIt
	qS0Qv0G8JbQwiUs=; b=I880/i3gWKfQp0rFCcKT5KFp3dqcYtqbHrN9Nits2i/6
	t4u3ubYy1qD9OwrBn+pXM/mMV5OMD3ZzNpNlypvPaiNlDJJIMuj4zLAEVazUkkk3
	smH2yhadGcY+pKOCf1Ajqzab4EbTD6jspqdUb8fGFo0HDmDVVh7vKIvDIlgz/7U=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a13.g.dreamhost.com (Postfix) with ESMTPSA id C225D334064; 
	Thu,  1 Dec 2011 08:22:30 -0800 (PST)
MIME-Version: 1.0
Message-Id: <patchbomb.1322756504@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Thu, 01 Dec 2011 11:21:44 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, keir.xen@gmail.com, tim@xen.org, JBeulich@suse.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 0 of 3] Bugfixes resend
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Resending three bug fix patches after feedback from Tim Deegan and Jan 
Also rebased against 3c4c29899d8a.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

 xen/include/asm-x86/page.h        |  18 ++++++++++++-
 xen/include/asm-x86/x86_64/page.h |   5 +++
 xen/arch/x86/hvm/hvm.c            |  54 ++++++++++++++++++++++++++------------
 xen/arch/x86/hvm/svm/nestedsvm.c  |   6 ----
 xen/arch/x86/hvm/vmx/vvmx.c       |  11 +------
 xen/arch/x86/mm.c                 |  12 +++++--
 6 files changed, 69 insertions(+), 37 deletions(-)

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 16:23:26 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 16:23:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW9Pk-00046L-TN; Thu, 01 Dec 2011 16:23:12 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RW9Pj-00045n-7q
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 16:23:11 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-8.tower-27.messagelabs.com!1322756446!54505603!1
X-Originating-IP: [208.97.132.177]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNzcgPT4gMTU3NzI=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10521 invoked from network); 1 Dec 2011 16:20:46 -0000
Received: from caiajhbdcbhh.dreamhost.com (HELO homiemail-a13.g.dreamhost.com)
	(208.97.132.177) by server-8.tower-27.messagelabs.com with SMTP;
	1 Dec 2011 16:20:46 -0000
Received: from homiemail-a13.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a13.g.dreamhost.com (Postfix) with ESMTP id 90F7433406C;
	Thu,  1 Dec 2011 08:22:32 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=cKMVL2yVpuP5VQ+nHPPK991PeBpWhCkGXi/Lb8nTi/uN
	80c4gZFLAhh98saZ4sRFohBXIGXiDX8upR7k5+rVqAushM3crPSd2GDR7/9ImeQq
	ZP6ZkoBvbqdmYeDmXnpn99iOg6gzQwGg/gS4FuGUy0ecp3g5NLgRGenYgYi1ZgM=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=BpfKsoZQRBIoY/tTARf38JjGGHc=; b=FlW3U9lFlVY
	4+NTN8zUsJzPOihdHIkZghM47X0bWh/g4QaTVICur0H0MMSudVl2lkjjo9Gtc8ED
	yCsrC3CzGolr6UkSx1pRgU7EX63bUich/vIoz4ewyB6vetUiIq3nvMCaNC6vI2ud
	3XfL5HVRNGUbA7ghxfHpGdx7o9CdI0Sc=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a13.g.dreamhost.com (Postfix) with ESMTPSA id CF07C334064; 
	Thu,  1 Dec 2011 08:22:31 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 7b6db593bda0a2938857ef0254bf33f526081d37
Message-Id: <7b6db593bda0a2938857.1322756505@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1322756504@xdev.gridcentric.ca>
References: <patchbomb.1322756504@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Thu, 01 Dec 2011 11:21:45 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, keir.xen@gmail.com, tim@xen.org, JBeulich@suse.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 1 of 3] x86: Add conversion from a xen map to an
	mfn
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/include/asm-x86/page.h        |  18 +++++++++++++++++-
 xen/include/asm-x86/x86_64/page.h |   5 +++++
 2 files changed, 22 insertions(+), 1 deletions(-)


This conversion is a trivial invocation of virt_to_mfn in 64 bits.
In 32 bits it uses the linear_map.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 36aac3e56d01 -r 7b6db593bda0 xen/include/asm-x86/page.h
--- a/xen/include/asm-x86/page.h
+++ b/xen/include/asm-x86/page.h
@@ -296,8 +296,22 @@ void copy_page_sse2(void *, const void *
 #define __linear_l4_table \
  ((l4_pgentry_t *)(__linear_l3_table + l3_linear_offset(LINEAR_PT_VIRT_START)))
 
+#ifndef __ASSEMBLY__
+#ifndef __x86_64__
+/* We need to stash this here for 32 bits as it depends on constructs
+ * defined after including x86_32/page.h */
+static inline unsigned long __xen_map_to_mfn(void *va)
+{
+    l1_pgentry_t *l1e;
 
-#ifndef __ASSEMBLY__
+    ASSERT( (((unsigned long) va) >= MAPCACHE_VIRT_START) &&
+            (((unsigned long) va) <= MAPCACHE_VIRT_END) );
+    l1e = &__linear_l1_table[
+            l1_linear_offset((unsigned long) va)];
+    return l1e_get_pfn(*l1e);
+}
+#endif /* __x86_64__ */
+
 extern root_pgentry_t idle_pg_table[ROOT_PAGETABLE_ENTRIES];
 #if CONFIG_PAGING_LEVELS == 3
 extern l2_pgentry_t   idle_pg_table_l2[
@@ -317,6 +331,8 @@ void paging_init(void);
 void setup_idle_pagetable(void);
 #endif /* !defined(__ASSEMBLY__) */
 
+#define xen_map_to_mfn(va)  __xen_map_to_mfn(va)
+
 #define _PAGE_PRESENT  0x001U
 #define _PAGE_RW       0x002U
 #define _PAGE_USER     0x004U
diff -r 36aac3e56d01 -r 7b6db593bda0 xen/include/asm-x86/x86_64/page.h
--- a/xen/include/asm-x86/x86_64/page.h
+++ b/xen/include/asm-x86/x86_64/page.h
@@ -104,6 +104,11 @@ static inline void *__maddr_to_virt(unsi
                      ((ma & ma_top_mask) >> pfn_pdx_hole_shift)));
 }
 
+static inline unsigned long __xen_map_to_mfn(void *va)
+{
+    return (__virt_to_maddr((unsigned long) va) >> PAGE_SHIFT);
+}
+
 /* read access (should only be used for debug printk's) */
 typedef u64 intpte_t;
 #define PRIpte "016lx"

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 16:23:26 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 16:23:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW9Pk-00046L-TN; Thu, 01 Dec 2011 16:23:12 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RW9Pj-00045n-7q
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 16:23:11 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-8.tower-27.messagelabs.com!1322756446!54505603!1
X-Originating-IP: [208.97.132.177]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNzcgPT4gMTU3NzI=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10521 invoked from network); 1 Dec 2011 16:20:46 -0000
Received: from caiajhbdcbhh.dreamhost.com (HELO homiemail-a13.g.dreamhost.com)
	(208.97.132.177) by server-8.tower-27.messagelabs.com with SMTP;
	1 Dec 2011 16:20:46 -0000
Received: from homiemail-a13.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a13.g.dreamhost.com (Postfix) with ESMTP id 90F7433406C;
	Thu,  1 Dec 2011 08:22:32 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=cKMVL2yVpuP5VQ+nHPPK991PeBpWhCkGXi/Lb8nTi/uN
	80c4gZFLAhh98saZ4sRFohBXIGXiDX8upR7k5+rVqAushM3crPSd2GDR7/9ImeQq
	ZP6ZkoBvbqdmYeDmXnpn99iOg6gzQwGg/gS4FuGUy0ecp3g5NLgRGenYgYi1ZgM=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=BpfKsoZQRBIoY/tTARf38JjGGHc=; b=FlW3U9lFlVY
	4+NTN8zUsJzPOihdHIkZghM47X0bWh/g4QaTVICur0H0MMSudVl2lkjjo9Gtc8ED
	yCsrC3CzGolr6UkSx1pRgU7EX63bUich/vIoz4ewyB6vetUiIq3nvMCaNC6vI2ud
	3XfL5HVRNGUbA7ghxfHpGdx7o9CdI0Sc=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a13.g.dreamhost.com (Postfix) with ESMTPSA id CF07C334064; 
	Thu,  1 Dec 2011 08:22:31 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 7b6db593bda0a2938857ef0254bf33f526081d37
Message-Id: <7b6db593bda0a2938857.1322756505@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1322756504@xdev.gridcentric.ca>
References: <patchbomb.1322756504@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Thu, 01 Dec 2011 11:21:45 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, keir.xen@gmail.com, tim@xen.org, JBeulich@suse.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 1 of 3] x86: Add conversion from a xen map to an
	mfn
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/include/asm-x86/page.h        |  18 +++++++++++++++++-
 xen/include/asm-x86/x86_64/page.h |   5 +++++
 2 files changed, 22 insertions(+), 1 deletions(-)


This conversion is a trivial invocation of virt_to_mfn in 64 bits.
In 32 bits it uses the linear_map.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 36aac3e56d01 -r 7b6db593bda0 xen/include/asm-x86/page.h
--- a/xen/include/asm-x86/page.h
+++ b/xen/include/asm-x86/page.h
@@ -296,8 +296,22 @@ void copy_page_sse2(void *, const void *
 #define __linear_l4_table \
  ((l4_pgentry_t *)(__linear_l3_table + l3_linear_offset(LINEAR_PT_VIRT_START)))
 
+#ifndef __ASSEMBLY__
+#ifndef __x86_64__
+/* We need to stash this here for 32 bits as it depends on constructs
+ * defined after including x86_32/page.h */
+static inline unsigned long __xen_map_to_mfn(void *va)
+{
+    l1_pgentry_t *l1e;
 
-#ifndef __ASSEMBLY__
+    ASSERT( (((unsigned long) va) >= MAPCACHE_VIRT_START) &&
+            (((unsigned long) va) <= MAPCACHE_VIRT_END) );
+    l1e = &__linear_l1_table[
+            l1_linear_offset((unsigned long) va)];
+    return l1e_get_pfn(*l1e);
+}
+#endif /* __x86_64__ */
+
 extern root_pgentry_t idle_pg_table[ROOT_PAGETABLE_ENTRIES];
 #if CONFIG_PAGING_LEVELS == 3
 extern l2_pgentry_t   idle_pg_table_l2[
@@ -317,6 +331,8 @@ void paging_init(void);
 void setup_idle_pagetable(void);
 #endif /* !defined(__ASSEMBLY__) */
 
+#define xen_map_to_mfn(va)  __xen_map_to_mfn(va)
+
 #define _PAGE_PRESENT  0x001U
 #define _PAGE_RW       0x002U
 #define _PAGE_USER     0x004U
diff -r 36aac3e56d01 -r 7b6db593bda0 xen/include/asm-x86/x86_64/page.h
--- a/xen/include/asm-x86/x86_64/page.h
+++ b/xen/include/asm-x86/x86_64/page.h
@@ -104,6 +104,11 @@ static inline void *__maddr_to_virt(unsi
                      ((ma & ma_top_mask) >> pfn_pdx_hole_shift)));
 }
 
+static inline unsigned long __xen_map_to_mfn(void *va)
+{
+    return (__virt_to_maddr((unsigned long) va) >> PAGE_SHIFT);
+}
+
 /* read access (should only be used for debug printk's) */
 typedef u64 intpte_t;
 #define PRIpte "016lx"

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 16:23:28 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 16: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.xensource.com>)
	id 1RW9Po-00047Q-A7; Thu, 01 Dec 2011 16:23:16 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RW9Pn-000463-M4
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 16:23:15 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-5.tower-174.messagelabs.com!1322756554!3899833!1
X-Originating-IP: [208.97.132.83]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi44MyA9PiAxNTQ4OQ==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26747 invoked from network); 1 Dec 2011 16:22:35 -0000
Received: from caiajhbdcaid.dreamhost.com (HELO homiemail-a13.g.dreamhost.com)
	(208.97.132.83) by server-5.tower-174.messagelabs.com with SMTP;
	1 Dec 2011 16:22:35 -0000
Received: from homiemail-a13.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a13.g.dreamhost.com (Postfix) with ESMTP id 745D533406D;
	Thu,  1 Dec 2011 08:22:34 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=Qw/VowXqG2KOZ/dxFDgxq2vC10pZNMpaePevPPGAadg9
	N6zYPq/Oy9OcB13g2NKpxqUYjfu/fb5l8/wSysdanXPTyvz2mK2TZp08eL1k2aL+
	aL3U6YxOsnGalFIMq802CmgAID1mZsZ/DasA0wTUGa8E9tq44MAEftemAeFW4tc=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=tf0+MwTFQnxhs04Rp2Ibeug9lfo=; b=Hy45sjdl6lU
	LKMEwtatjGFQC6KDH5da6i+K+6YGDzQfBB3FNjiWrzbr5ZoKSJwFlbrEE2w95wP/
	WEECXVBknfNPa2CLqBLlfoEA3DczdFUty6EVhxjyG0CCwaViXqyIM4rMVzu8iCnS
	Fw4++/vu+biW8EC7LYN3aAYyrubafnaY=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a13.g.dreamhost.com (Postfix) with ESMTPSA id C4936334064; 
	Thu,  1 Dec 2011 08:22:33 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 2372d2bf76b563a63ed0fcd56727064768d90b81
Message-Id: <2372d2bf76b563a63ed0.1322756507@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1322756504@xdev.gridcentric.ca>
References: <patchbomb.1322756504@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Thu, 01 Dec 2011 11:21:47 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, keir.xen@gmail.com, tim@xen.org, JBeulich@suse.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 3 of 3] x86/mm: Fix checks during foreign
 mapping of paged pages
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/mm.c |  12 ++++++++----
 1 files changed, 8 insertions(+), 4 deletions(-)


Check that the valid mfn is the one we are mapping, not the
mfn of the page table of the foreign domain.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 4e0c533a3e1d -r 2372d2bf76b5 xen/arch/x86/mm.c
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -3572,7 +3572,8 @@ int do_mmu_update(
                         rc = -ENOENT;
                         break;
                     }
-                    else if ( p2m_ram_paging_in_start == l1e_p2mt && !mfn_valid(mfn) )
+                    else if ( p2m_ram_paging_in_start == l1e_p2mt && 
+                                !mfn_valid(l1emfn) )
                     {
                         put_gfn(pg_owner, l1egfn);
                         rc = -ENOENT;
@@ -3620,7 +3621,8 @@ int do_mmu_update(
                         rc = -ENOENT;
                         break;
                     }
-                    else if ( p2m_ram_paging_in_start == l2e_p2mt && !mfn_valid(mfn) )
+                    else if ( p2m_ram_paging_in_start == l2e_p2mt && 
+                                !mfn_valid(l2emfn) )
                     {
                         put_gfn(pg_owner, l2egfn);
                         rc = -ENOENT;
@@ -3654,7 +3656,8 @@ int do_mmu_update(
                         rc = -ENOENT;
                         break;
                     }
-                    else if ( p2m_ram_paging_in_start == l3e_p2mt && !mfn_valid(mfn) )
+                    else if ( p2m_ram_paging_in_start == l3e_p2mt && 
+                                !mfn_valid(l3emfn) )
                     {
                         put_gfn(pg_owner, l3egfn);
                         rc = -ENOENT;
@@ -3688,7 +3691,8 @@ int do_mmu_update(
                         rc = -ENOENT;
                         break;
                     }
-                    else if ( p2m_ram_paging_in_start == l4e_p2mt && !mfn_valid(mfn) )
+                    else if ( p2m_ram_paging_in_start == l4e_p2mt && 
+                                !mfn_valid(l4emfn) )
                     {
                         put_gfn(pg_owner, l4egfn);
                         rc = -ENOENT;

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 16:23:28 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 16: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.xensource.com>)
	id 1RW9Po-00047Q-A7; Thu, 01 Dec 2011 16:23:16 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RW9Pn-000463-M4
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 16:23:15 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-5.tower-174.messagelabs.com!1322756554!3899833!1
X-Originating-IP: [208.97.132.83]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi44MyA9PiAxNTQ4OQ==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26747 invoked from network); 1 Dec 2011 16:22:35 -0000
Received: from caiajhbdcaid.dreamhost.com (HELO homiemail-a13.g.dreamhost.com)
	(208.97.132.83) by server-5.tower-174.messagelabs.com with SMTP;
	1 Dec 2011 16:22:35 -0000
Received: from homiemail-a13.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a13.g.dreamhost.com (Postfix) with ESMTP id 745D533406D;
	Thu,  1 Dec 2011 08:22:34 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=Qw/VowXqG2KOZ/dxFDgxq2vC10pZNMpaePevPPGAadg9
	N6zYPq/Oy9OcB13g2NKpxqUYjfu/fb5l8/wSysdanXPTyvz2mK2TZp08eL1k2aL+
	aL3U6YxOsnGalFIMq802CmgAID1mZsZ/DasA0wTUGa8E9tq44MAEftemAeFW4tc=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=tf0+MwTFQnxhs04Rp2Ibeug9lfo=; b=Hy45sjdl6lU
	LKMEwtatjGFQC6KDH5da6i+K+6YGDzQfBB3FNjiWrzbr5ZoKSJwFlbrEE2w95wP/
	WEECXVBknfNPa2CLqBLlfoEA3DczdFUty6EVhxjyG0CCwaViXqyIM4rMVzu8iCnS
	Fw4++/vu+biW8EC7LYN3aAYyrubafnaY=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a13.g.dreamhost.com (Postfix) with ESMTPSA id C4936334064; 
	Thu,  1 Dec 2011 08:22:33 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 2372d2bf76b563a63ed0fcd56727064768d90b81
Message-Id: <2372d2bf76b563a63ed0.1322756507@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1322756504@xdev.gridcentric.ca>
References: <patchbomb.1322756504@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Thu, 01 Dec 2011 11:21:47 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, keir.xen@gmail.com, tim@xen.org, JBeulich@suse.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 3 of 3] x86/mm: Fix checks during foreign
 mapping of paged pages
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/mm.c |  12 ++++++++----
 1 files changed, 8 insertions(+), 4 deletions(-)


Check that the valid mfn is the one we are mapping, not the
mfn of the page table of the foreign domain.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 4e0c533a3e1d -r 2372d2bf76b5 xen/arch/x86/mm.c
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -3572,7 +3572,8 @@ int do_mmu_update(
                         rc = -ENOENT;
                         break;
                     }
-                    else if ( p2m_ram_paging_in_start == l1e_p2mt && !mfn_valid(mfn) )
+                    else if ( p2m_ram_paging_in_start == l1e_p2mt && 
+                                !mfn_valid(l1emfn) )
                     {
                         put_gfn(pg_owner, l1egfn);
                         rc = -ENOENT;
@@ -3620,7 +3621,8 @@ int do_mmu_update(
                         rc = -ENOENT;
                         break;
                     }
-                    else if ( p2m_ram_paging_in_start == l2e_p2mt && !mfn_valid(mfn) )
+                    else if ( p2m_ram_paging_in_start == l2e_p2mt && 
+                                !mfn_valid(l2emfn) )
                     {
                         put_gfn(pg_owner, l2egfn);
                         rc = -ENOENT;
@@ -3654,7 +3656,8 @@ int do_mmu_update(
                         rc = -ENOENT;
                         break;
                     }
-                    else if ( p2m_ram_paging_in_start == l3e_p2mt && !mfn_valid(mfn) )
+                    else if ( p2m_ram_paging_in_start == l3e_p2mt && 
+                                !mfn_valid(l3emfn) )
                     {
                         put_gfn(pg_owner, l3egfn);
                         rc = -ENOENT;
@@ -3688,7 +3691,8 @@ int do_mmu_update(
                         rc = -ENOENT;
                         break;
                     }
-                    else if ( p2m_ram_paging_in_start == l4e_p2mt && !mfn_valid(mfn) )
+                    else if ( p2m_ram_paging_in_start == l4e_p2mt && 
+                                !mfn_valid(l4emfn) )
                     {
                         put_gfn(pg_owner, l4egfn);
                         rc = -ENOENT;

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 16:23:28 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 16: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.xensource.com>)
	id 1RW9Pm-00046g-Am; Thu, 01 Dec 2011 16:23:14 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RW9Pk-00045w-Hv
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 16:23:12 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-15.tower-27.messagelabs.com!1322756538!57325530!1
X-Originating-IP: [208.97.132.207]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4yMDcgPT4gMTU1MDU=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11284 invoked from network); 1 Dec 2011 16:22:18 -0000
Received: from caiajhbdccah.dreamhost.com (HELO homiemail-a13.g.dreamhost.com)
	(208.97.132.207) by server-15.tower-27.messagelabs.com with SMTP;
	1 Dec 2011 16:22:18 -0000
Received: from homiemail-a13.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a13.g.dreamhost.com (Postfix) with ESMTP id 939C233406E;
	Thu,  1 Dec 2011 08:22:33 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=Xl8vfHlEfN2sY6W61IUjZHIJQ80tmt7yvcaidnGOYFTk
	00OtdJbx+u4NfgZKIMg8TbNtaM3Of+cS1FLPBeBOeAn1s2CJ4togoN3M7qOskGoB
	qI/OXWAUPFKib2anHgnhWsnxm9o6Pw0P0Na4vU/71eH8WEDc+dOiMbYygngBM3g=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=udk9MLq1HmKp51Wa66/xZkfJjM0=; b=c3xFXf/XCwI
	3uieOxHDPrk07N6PDHtUtO9WiExoZUCo4ql1b3W/K5mjY9/aEWVmizf0WGV0P/bI
	V6Ue9ym9CdR0I8Xw1rExu2I0lXOBf471TH7cU31HVE/Wjx4WHQJKJkLyPIcszxSc
	Jl3yWHGCOMqpLJslCyuKXk2BKrE4VCzw=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a13.g.dreamhost.com (Postfix) with ESMTPSA id BB7F7334064; 
	Thu,  1 Dec 2011 08:22:32 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 4e0c533a3e1d8bfd02e31a6116b6cdf1e9a08237
Message-Id: <4e0c533a3e1d8bfd02e3.1322756506@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1322756504@xdev.gridcentric.ca>
References: <patchbomb.1322756504@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Thu, 01 Dec 2011 11:21:46 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, keir.xen@gmail.com, tim@xen.org, JBeulich@suse.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 2 of 3] x86/mm: Ensure maps used by nested hvm
 code cannot be paged out
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/hvm/hvm.c           |  54 +++++++++++++++++++++++++++------------
 xen/arch/x86/hvm/svm/nestedsvm.c |   6 ----
 xen/arch/x86/hvm/vmx/vvmx.c      |  11 +------
 3 files changed, 39 insertions(+), 32 deletions(-)


The nested hvm code maps pages of the guest hvm. These maps live beyond
a hypervisor entry/exit pair, and thus their liveness cannot be ensured
with get_gfn/put_gfn critical sections. Ensure their liveness by
increasing the page ref count, instead.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 7b6db593bda0 -r 4e0c533a3e1d xen/arch/x86/hvm/hvm.c
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -1801,12 +1801,16 @@ int hvm_virtual_to_linear_addr(
     return 0;
 }
 
-/* We leave this function holding a lock on the p2m entry */
+/* On non-NULL return, we leave this function holding an additional 
+ * ref on the underlying mfn, if any */
 static void *__hvm_map_guest_frame(unsigned long gfn, bool_t writable)
 {
+    void *map;
     unsigned long mfn;
     p2m_type_t p2mt;
+    struct page_info *pg;
     struct domain *d = current->domain;
+    int rc;
 
     mfn = mfn_x(writable
                 ? get_gfn_unshare(d, gfn, &p2mt)
@@ -1828,7 +1832,21 @@ static void *__hvm_map_guest_frame(unsig
     if ( writable )
         paging_mark_dirty(d, mfn);
 
-    return map_domain_page(mfn);
+    /* Get a ref on the page, considering that it could be shared */
+    pg = mfn_to_page(mfn);
+    rc = get_page(pg, d);
+    if ( !rc && !writable )
+        /* Page could be shared */
+        rc = get_page(pg, dom_cow);
+    if ( !rc )
+    {
+        put_gfn(d, gfn);
+        return NULL;
+    }
+
+    map = map_domain_page(mfn);
+    put_gfn(d, gfn);
+    return map;
 }
 
 void *hvm_map_guest_frame_rw(unsigned long gfn)
@@ -1844,11 +1862,16 @@ void *hvm_map_guest_frame_ro(unsigned lo
 void hvm_unmap_guest_frame(void *p)
 {
     if ( p )
+    {
+        unsigned long mfn = xen_map_to_mfn(p);
         unmap_domain_page(p);
+        put_page(mfn_to_page(mfn));
+    }
 }
 
-static void *hvm_map_entry(unsigned long va, unsigned long *gfn)
+static void *hvm_map_entry(unsigned long va)
 {
+    unsigned long gfn;
     uint32_t pfec;
     char *v;
 
@@ -1865,11 +1888,11 @@ static void *hvm_map_entry(unsigned long
      * treat it as a kernel-mode read (i.e. no access checks).
      */
     pfec = PFEC_page_present;
-    *gfn = paging_gva_to_gfn(current, va, &pfec);
+    gfn = paging_gva_to_gfn(current, va, &pfec);
     if ( (pfec == PFEC_page_paged) || (pfec == PFEC_page_shared) )
         goto fail;
 
-    v = hvm_map_guest_frame_rw(*gfn);
+    v = hvm_map_guest_frame_rw(gfn);
     if ( v == NULL )
         goto fail;
 
@@ -1880,11 +1903,9 @@ static void *hvm_map_entry(unsigned long
     return NULL;
 }
 
-static void hvm_unmap_entry(void *p, unsigned long gfn)
+static void hvm_unmap_entry(void *p)
 {
     hvm_unmap_guest_frame(p);
-    if ( p && (gfn != INVALID_GFN) )
-        put_gfn(current->domain, gfn);
 }
 
 static int hvm_load_segment_selector(
@@ -1896,7 +1917,6 @@ static int hvm_load_segment_selector(
     int fault_type = TRAP_invalid_tss;
     struct cpu_user_regs *regs = guest_cpu_user_regs();
     struct vcpu *v = current;
-    unsigned long pdesc_gfn = INVALID_GFN;
 
     if ( regs->eflags & X86_EFLAGS_VM )
     {
@@ -1930,7 +1950,7 @@ static int hvm_load_segment_selector(
     if ( ((sel & 0xfff8) + 7) > desctab.limit )
         goto fail;
 
-    pdesc = hvm_map_entry(desctab.base + (sel & 0xfff8), &pdesc_gfn);
+    pdesc = hvm_map_entry(desctab.base + (sel & 0xfff8));
     if ( pdesc == NULL )
         goto hvm_map_fail;
 
@@ -1990,7 +2010,7 @@ static int hvm_load_segment_selector(
     desc.b |= 0x100;
 
  skip_accessed_flag:
-    hvm_unmap_entry(pdesc, pdesc_gfn);
+    hvm_unmap_entry(pdesc);
 
     segr.base = (((desc.b <<  0) & 0xff000000u) |
                  ((desc.b << 16) & 0x00ff0000u) |
@@ -2006,7 +2026,7 @@ static int hvm_load_segment_selector(
     return 0;
 
  unmap_and_fail:
-    hvm_unmap_entry(pdesc, pdesc_gfn);
+    hvm_unmap_entry(pdesc);
  fail:
     hvm_inject_exception(fault_type, sel & 0xfffc, 0);
  hvm_map_fail:
@@ -2021,7 +2041,7 @@ void hvm_task_switch(
     struct cpu_user_regs *regs = guest_cpu_user_regs();
     struct segment_register gdt, tr, prev_tr, segr;
     struct desc_struct *optss_desc = NULL, *nptss_desc = NULL, tss_desc;
-    unsigned long eflags, optss_gfn = INVALID_GFN, nptss_gfn = INVALID_GFN;
+    unsigned long eflags;
     int exn_raised, rc;
     struct {
         u16 back_link,__blh;
@@ -2047,11 +2067,11 @@ void hvm_task_switch(
         goto out;
     }
 
-    optss_desc = hvm_map_entry(gdt.base + (prev_tr.sel & 0xfff8), &optss_gfn);
+    optss_desc = hvm_map_entry(gdt.base + (prev_tr.sel & 0xfff8)); 
     if ( optss_desc == NULL )
         goto out;
 
-    nptss_desc = hvm_map_entry(gdt.base + (tss_sel & 0xfff8), &nptss_gfn);
+    nptss_desc = hvm_map_entry(gdt.base + (tss_sel & 0xfff8)); 
     if ( nptss_desc == NULL )
         goto out;
 
@@ -2216,8 +2236,8 @@ void hvm_task_switch(
     }
 
  out:
-    hvm_unmap_entry(optss_desc, optss_gfn);
-    hvm_unmap_entry(nptss_desc, nptss_gfn);
+    hvm_unmap_entry(optss_desc);
+    hvm_unmap_entry(nptss_desc);
 }
 
 #define HVMCOPY_from_guest (0u<<0)
diff -r 7b6db593bda0 -r 4e0c533a3e1d xen/arch/x86/hvm/svm/nestedsvm.c
--- a/xen/arch/x86/hvm/svm/nestedsvm.c
+++ b/xen/arch/x86/hvm/svm/nestedsvm.c
@@ -81,10 +81,6 @@ int nestedsvm_vmcb_map(struct vcpu *v, u
         if (nv->nv_vvmcx == NULL)
             return 0;
         nv->nv_vvmcxaddr = vmcbaddr;
-        /* put_gfn here even though the map survives beyond this caller.
-         * The map can likely survive beyond a hypervisor exit, thus we
-         * need to put the gfn */
-        put_gfn(current->domain, vmcbaddr >> PAGE_SHIFT);
     }
 
     return 1;
@@ -358,7 +354,6 @@ static int nsvm_vmrun_permissionmap(stru
     ioport_80 = test_bit(0x80, ns_viomap);
     ioport_ed = test_bit(0xed, ns_viomap);
     hvm_unmap_guest_frame(ns_viomap);
-    put_gfn(current->domain, svm->ns_iomap_pa >> PAGE_SHIFT);
 
     svm->ns_iomap = nestedhvm_vcpu_iomap_get(ioport_80, ioport_ed);
 
@@ -889,7 +884,6 @@ nsvm_vmcb_guest_intercepts_ioio(paddr_t 
 
     enabled = test_bit(port, io_bitmap);
     hvm_unmap_guest_frame(io_bitmap);
-    put_gfn(current->domain, gfn);
 
     if (!enabled)
         return NESTEDHVM_VMEXIT_HOST;
diff -r 7b6db593bda0 -r 4e0c533a3e1d xen/arch/x86/hvm/vmx/vvmx.c
--- a/xen/arch/x86/hvm/vmx/vvmx.c
+++ b/xen/arch/x86/hvm/vmx/vvmx.c
@@ -560,10 +560,7 @@ static void __map_io_bitmap(struct vcpu 
     if (nvmx->iobitmap[index])
         hvm_unmap_guest_frame (nvmx->iobitmap[index]); 
     gpa = __get_vvmcs(vcpu_nestedhvm(v).nv_vvmcx, vmcs_reg);
-    nvmx->iobitmap[index] = hvm_map_guest_frame_ro (gpa >> PAGE_SHIFT);
-    /* See comment in nestedsvm_vmcb_map re putting this gfn and 
-     * liveness of the map it backs */
-    put_gfn(current->domain, gpa >> PAGE_SHIFT);
+    nvmx->iobitmap[index] = hvm_map_guest_frame_ro(gpa >> PAGE_SHIFT);
 }
 
 static inline void map_io_bitmap_all(struct vcpu *v)
@@ -1138,12 +1135,9 @@ int nvmx_handle_vmptrld(struct cpu_user_
 
     if ( nvcpu->nv_vvmcxaddr == VMCX_EADDR )
     {
-        nvcpu->nv_vvmcx = hvm_map_guest_frame_rw (gpa >> PAGE_SHIFT);
+        nvcpu->nv_vvmcx = hvm_map_guest_frame_rw(gpa >> PAGE_SHIFT);
         nvcpu->nv_vvmcxaddr = gpa;
         map_io_bitmap_all (v);
-        /* See comment in nestedsvm_vmcb_map regarding putting this 
-         * gfn and liveness of the map that uses it */
-        put_gfn(current->domain, gpa >> PAGE_SHIFT);
     }
 
     vmreturn(regs, VMSUCCEED);
@@ -1205,7 +1199,6 @@ int nvmx_handle_vmclear(struct cpu_user_
         if ( vvmcs ) 
             __set_vvmcs(vvmcs, NVMX_LAUNCH_STATE, 0);
         hvm_unmap_guest_frame(vvmcs);
-        put_gfn(current->domain, gpa >> PAGE_SHIFT);
     }
 
     vmreturn(regs, VMSUCCEED);

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 16:23:28 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 16: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.xensource.com>)
	id 1RW9Pm-00046g-Am; Thu, 01 Dec 2011 16:23:14 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RW9Pk-00045w-Hv
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 16:23:12 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-15.tower-27.messagelabs.com!1322756538!57325530!1
X-Originating-IP: [208.97.132.207]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4yMDcgPT4gMTU1MDU=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11284 invoked from network); 1 Dec 2011 16:22:18 -0000
Received: from caiajhbdccah.dreamhost.com (HELO homiemail-a13.g.dreamhost.com)
	(208.97.132.207) by server-15.tower-27.messagelabs.com with SMTP;
	1 Dec 2011 16:22:18 -0000
Received: from homiemail-a13.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a13.g.dreamhost.com (Postfix) with ESMTP id 939C233406E;
	Thu,  1 Dec 2011 08:22:33 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=Xl8vfHlEfN2sY6W61IUjZHIJQ80tmt7yvcaidnGOYFTk
	00OtdJbx+u4NfgZKIMg8TbNtaM3Of+cS1FLPBeBOeAn1s2CJ4togoN3M7qOskGoB
	qI/OXWAUPFKib2anHgnhWsnxm9o6Pw0P0Na4vU/71eH8WEDc+dOiMbYygngBM3g=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=udk9MLq1HmKp51Wa66/xZkfJjM0=; b=c3xFXf/XCwI
	3uieOxHDPrk07N6PDHtUtO9WiExoZUCo4ql1b3W/K5mjY9/aEWVmizf0WGV0P/bI
	V6Ue9ym9CdR0I8Xw1rExu2I0lXOBf471TH7cU31HVE/Wjx4WHQJKJkLyPIcszxSc
	Jl3yWHGCOMqpLJslCyuKXk2BKrE4VCzw=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a13.g.dreamhost.com (Postfix) with ESMTPSA id BB7F7334064; 
	Thu,  1 Dec 2011 08:22:32 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 4e0c533a3e1d8bfd02e31a6116b6cdf1e9a08237
Message-Id: <4e0c533a3e1d8bfd02e3.1322756506@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1322756504@xdev.gridcentric.ca>
References: <patchbomb.1322756504@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Thu, 01 Dec 2011 11:21:46 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, keir.xen@gmail.com, tim@xen.org, JBeulich@suse.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 2 of 3] x86/mm: Ensure maps used by nested hvm
 code cannot be paged out
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/hvm/hvm.c           |  54 +++++++++++++++++++++++++++------------
 xen/arch/x86/hvm/svm/nestedsvm.c |   6 ----
 xen/arch/x86/hvm/vmx/vvmx.c      |  11 +------
 3 files changed, 39 insertions(+), 32 deletions(-)


The nested hvm code maps pages of the guest hvm. These maps live beyond
a hypervisor entry/exit pair, and thus their liveness cannot be ensured
with get_gfn/put_gfn critical sections. Ensure their liveness by
increasing the page ref count, instead.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 7b6db593bda0 -r 4e0c533a3e1d xen/arch/x86/hvm/hvm.c
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -1801,12 +1801,16 @@ int hvm_virtual_to_linear_addr(
     return 0;
 }
 
-/* We leave this function holding a lock on the p2m entry */
+/* On non-NULL return, we leave this function holding an additional 
+ * ref on the underlying mfn, if any */
 static void *__hvm_map_guest_frame(unsigned long gfn, bool_t writable)
 {
+    void *map;
     unsigned long mfn;
     p2m_type_t p2mt;
+    struct page_info *pg;
     struct domain *d = current->domain;
+    int rc;
 
     mfn = mfn_x(writable
                 ? get_gfn_unshare(d, gfn, &p2mt)
@@ -1828,7 +1832,21 @@ static void *__hvm_map_guest_frame(unsig
     if ( writable )
         paging_mark_dirty(d, mfn);
 
-    return map_domain_page(mfn);
+    /* Get a ref on the page, considering that it could be shared */
+    pg = mfn_to_page(mfn);
+    rc = get_page(pg, d);
+    if ( !rc && !writable )
+        /* Page could be shared */
+        rc = get_page(pg, dom_cow);
+    if ( !rc )
+    {
+        put_gfn(d, gfn);
+        return NULL;
+    }
+
+    map = map_domain_page(mfn);
+    put_gfn(d, gfn);
+    return map;
 }
 
 void *hvm_map_guest_frame_rw(unsigned long gfn)
@@ -1844,11 +1862,16 @@ void *hvm_map_guest_frame_ro(unsigned lo
 void hvm_unmap_guest_frame(void *p)
 {
     if ( p )
+    {
+        unsigned long mfn = xen_map_to_mfn(p);
         unmap_domain_page(p);
+        put_page(mfn_to_page(mfn));
+    }
 }
 
-static void *hvm_map_entry(unsigned long va, unsigned long *gfn)
+static void *hvm_map_entry(unsigned long va)
 {
+    unsigned long gfn;
     uint32_t pfec;
     char *v;
 
@@ -1865,11 +1888,11 @@ static void *hvm_map_entry(unsigned long
      * treat it as a kernel-mode read (i.e. no access checks).
      */
     pfec = PFEC_page_present;
-    *gfn = paging_gva_to_gfn(current, va, &pfec);
+    gfn = paging_gva_to_gfn(current, va, &pfec);
     if ( (pfec == PFEC_page_paged) || (pfec == PFEC_page_shared) )
         goto fail;
 
-    v = hvm_map_guest_frame_rw(*gfn);
+    v = hvm_map_guest_frame_rw(gfn);
     if ( v == NULL )
         goto fail;
 
@@ -1880,11 +1903,9 @@ static void *hvm_map_entry(unsigned long
     return NULL;
 }
 
-static void hvm_unmap_entry(void *p, unsigned long gfn)
+static void hvm_unmap_entry(void *p)
 {
     hvm_unmap_guest_frame(p);
-    if ( p && (gfn != INVALID_GFN) )
-        put_gfn(current->domain, gfn);
 }
 
 static int hvm_load_segment_selector(
@@ -1896,7 +1917,6 @@ static int hvm_load_segment_selector(
     int fault_type = TRAP_invalid_tss;
     struct cpu_user_regs *regs = guest_cpu_user_regs();
     struct vcpu *v = current;
-    unsigned long pdesc_gfn = INVALID_GFN;
 
     if ( regs->eflags & X86_EFLAGS_VM )
     {
@@ -1930,7 +1950,7 @@ static int hvm_load_segment_selector(
     if ( ((sel & 0xfff8) + 7) > desctab.limit )
         goto fail;
 
-    pdesc = hvm_map_entry(desctab.base + (sel & 0xfff8), &pdesc_gfn);
+    pdesc = hvm_map_entry(desctab.base + (sel & 0xfff8));
     if ( pdesc == NULL )
         goto hvm_map_fail;
 
@@ -1990,7 +2010,7 @@ static int hvm_load_segment_selector(
     desc.b |= 0x100;
 
  skip_accessed_flag:
-    hvm_unmap_entry(pdesc, pdesc_gfn);
+    hvm_unmap_entry(pdesc);
 
     segr.base = (((desc.b <<  0) & 0xff000000u) |
                  ((desc.b << 16) & 0x00ff0000u) |
@@ -2006,7 +2026,7 @@ static int hvm_load_segment_selector(
     return 0;
 
  unmap_and_fail:
-    hvm_unmap_entry(pdesc, pdesc_gfn);
+    hvm_unmap_entry(pdesc);
  fail:
     hvm_inject_exception(fault_type, sel & 0xfffc, 0);
  hvm_map_fail:
@@ -2021,7 +2041,7 @@ void hvm_task_switch(
     struct cpu_user_regs *regs = guest_cpu_user_regs();
     struct segment_register gdt, tr, prev_tr, segr;
     struct desc_struct *optss_desc = NULL, *nptss_desc = NULL, tss_desc;
-    unsigned long eflags, optss_gfn = INVALID_GFN, nptss_gfn = INVALID_GFN;
+    unsigned long eflags;
     int exn_raised, rc;
     struct {
         u16 back_link,__blh;
@@ -2047,11 +2067,11 @@ void hvm_task_switch(
         goto out;
     }
 
-    optss_desc = hvm_map_entry(gdt.base + (prev_tr.sel & 0xfff8), &optss_gfn);
+    optss_desc = hvm_map_entry(gdt.base + (prev_tr.sel & 0xfff8)); 
     if ( optss_desc == NULL )
         goto out;
 
-    nptss_desc = hvm_map_entry(gdt.base + (tss_sel & 0xfff8), &nptss_gfn);
+    nptss_desc = hvm_map_entry(gdt.base + (tss_sel & 0xfff8)); 
     if ( nptss_desc == NULL )
         goto out;
 
@@ -2216,8 +2236,8 @@ void hvm_task_switch(
     }
 
  out:
-    hvm_unmap_entry(optss_desc, optss_gfn);
-    hvm_unmap_entry(nptss_desc, nptss_gfn);
+    hvm_unmap_entry(optss_desc);
+    hvm_unmap_entry(nptss_desc);
 }
 
 #define HVMCOPY_from_guest (0u<<0)
diff -r 7b6db593bda0 -r 4e0c533a3e1d xen/arch/x86/hvm/svm/nestedsvm.c
--- a/xen/arch/x86/hvm/svm/nestedsvm.c
+++ b/xen/arch/x86/hvm/svm/nestedsvm.c
@@ -81,10 +81,6 @@ int nestedsvm_vmcb_map(struct vcpu *v, u
         if (nv->nv_vvmcx == NULL)
             return 0;
         nv->nv_vvmcxaddr = vmcbaddr;
-        /* put_gfn here even though the map survives beyond this caller.
-         * The map can likely survive beyond a hypervisor exit, thus we
-         * need to put the gfn */
-        put_gfn(current->domain, vmcbaddr >> PAGE_SHIFT);
     }
 
     return 1;
@@ -358,7 +354,6 @@ static int nsvm_vmrun_permissionmap(stru
     ioport_80 = test_bit(0x80, ns_viomap);
     ioport_ed = test_bit(0xed, ns_viomap);
     hvm_unmap_guest_frame(ns_viomap);
-    put_gfn(current->domain, svm->ns_iomap_pa >> PAGE_SHIFT);
 
     svm->ns_iomap = nestedhvm_vcpu_iomap_get(ioport_80, ioport_ed);
 
@@ -889,7 +884,6 @@ nsvm_vmcb_guest_intercepts_ioio(paddr_t 
 
     enabled = test_bit(port, io_bitmap);
     hvm_unmap_guest_frame(io_bitmap);
-    put_gfn(current->domain, gfn);
 
     if (!enabled)
         return NESTEDHVM_VMEXIT_HOST;
diff -r 7b6db593bda0 -r 4e0c533a3e1d xen/arch/x86/hvm/vmx/vvmx.c
--- a/xen/arch/x86/hvm/vmx/vvmx.c
+++ b/xen/arch/x86/hvm/vmx/vvmx.c
@@ -560,10 +560,7 @@ static void __map_io_bitmap(struct vcpu 
     if (nvmx->iobitmap[index])
         hvm_unmap_guest_frame (nvmx->iobitmap[index]); 
     gpa = __get_vvmcs(vcpu_nestedhvm(v).nv_vvmcx, vmcs_reg);
-    nvmx->iobitmap[index] = hvm_map_guest_frame_ro (gpa >> PAGE_SHIFT);
-    /* See comment in nestedsvm_vmcb_map re putting this gfn and 
-     * liveness of the map it backs */
-    put_gfn(current->domain, gpa >> PAGE_SHIFT);
+    nvmx->iobitmap[index] = hvm_map_guest_frame_ro(gpa >> PAGE_SHIFT);
 }
 
 static inline void map_io_bitmap_all(struct vcpu *v)
@@ -1138,12 +1135,9 @@ int nvmx_handle_vmptrld(struct cpu_user_
 
     if ( nvcpu->nv_vvmcxaddr == VMCX_EADDR )
     {
-        nvcpu->nv_vvmcx = hvm_map_guest_frame_rw (gpa >> PAGE_SHIFT);
+        nvcpu->nv_vvmcx = hvm_map_guest_frame_rw(gpa >> PAGE_SHIFT);
         nvcpu->nv_vvmcxaddr = gpa;
         map_io_bitmap_all (v);
-        /* See comment in nestedsvm_vmcb_map regarding putting this 
-         * gfn and liveness of the map that uses it */
-        put_gfn(current->domain, gpa >> PAGE_SHIFT);
     }
 
     vmreturn(regs, VMSUCCEED);
@@ -1205,7 +1199,6 @@ int nvmx_handle_vmclear(struct cpu_user_
         if ( vvmcs ) 
             __set_vvmcs(vvmcs, NVMX_LAUNCH_STATE, 0);
         hvm_unmap_guest_frame(vvmcs);
-        put_gfn(current->domain, gpa >> PAGE_SHIFT);
     }
 
     vmreturn(regs, VMSUCCEED);

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 16:26:26 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 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.xensource.com>)
	id 1RW9Si-0004eE-0T; Thu, 01 Dec 2011 16:26:16 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RW9Sg-0004db-K2
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 16:26:14 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-5.tower-27.messagelabs.com!1322756701!45064351!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25077 invoked from network); 1 Dec 2011 16:25:01 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-5.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 1 Dec 2011 16:25:01 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RW9S3-000Gqv-1d; Thu, 01 Dec 2011 16:25:35 +0000
Date: Thu, 1 Dec 2011 16:25:34 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20111201162534.GJ61203@ocelot.phlegethon.org>
References: <patchbomb.1322603903@xdev.gridcentric.ca>
	<52d6aede6206e2cd7d17.1322603905@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <52d6aede6206e2cd7d17.1322603905@xdev.gridcentric.ca>
User-Agent: Mutt/1.4.2.1i
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com, keir.xen@gmail.com,
	JBeulich@suse.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 2 of 2] x86/mm: New mem access type to log
	access
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 16:58 -0500 on 29 Nov (1322585905), Andres Lagar-Cavilla wrote:
> @@ -1162,10 +1167,13 @@ int p2m_mem_access_check(unsigned long g
>          }
>          else
>          {
> -            /* A listener is not required, so clear the access restrictions */
> -            p2m_lock(p2m);
> -            p2m->set_entry(p2m, gfn, mfn, PAGE_ORDER_4K, p2mt, p2m_access_rwx);
> -            p2m_unlock(p2m);
> +            if ( p2ma != p2m_access_n2rwx )
> +            {
> +                /* A listener is not required, so clear the access restrictions */
> +                p2m_lock(p2m);
> +                p2m->set_entry(p2m, gfn, mfn, PAGE_ORDER_4K, p2mt, p2m_access_rwx);
> +                p2m_unlock(p2m);
> +            }
>              return 1;
>          }

This logic is getting a bit convoluted, and I'm not sure it's correct.
If a page is marked n2rwx and there's no listener, it looks like this
will cause it to spin forever re-taking the fault rather than pausing it
waiting for the listener to attach.

Cheers,

Tim.

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 16:26:26 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 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.xensource.com>)
	id 1RW9Si-0004eE-0T; Thu, 01 Dec 2011 16:26:16 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RW9Sg-0004db-K2
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 16:26:14 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-5.tower-27.messagelabs.com!1322756701!45064351!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25077 invoked from network); 1 Dec 2011 16:25:01 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-5.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 1 Dec 2011 16:25:01 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RW9S3-000Gqv-1d; Thu, 01 Dec 2011 16:25:35 +0000
Date: Thu, 1 Dec 2011 16:25:34 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20111201162534.GJ61203@ocelot.phlegethon.org>
References: <patchbomb.1322603903@xdev.gridcentric.ca>
	<52d6aede6206e2cd7d17.1322603905@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <52d6aede6206e2cd7d17.1322603905@xdev.gridcentric.ca>
User-Agent: Mutt/1.4.2.1i
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com, keir.xen@gmail.com,
	JBeulich@suse.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 2 of 2] x86/mm: New mem access type to log
	access
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 16:58 -0500 on 29 Nov (1322585905), Andres Lagar-Cavilla wrote:
> @@ -1162,10 +1167,13 @@ int p2m_mem_access_check(unsigned long g
>          }
>          else
>          {
> -            /* A listener is not required, so clear the access restrictions */
> -            p2m_lock(p2m);
> -            p2m->set_entry(p2m, gfn, mfn, PAGE_ORDER_4K, p2mt, p2m_access_rwx);
> -            p2m_unlock(p2m);
> +            if ( p2ma != p2m_access_n2rwx )
> +            {
> +                /* A listener is not required, so clear the access restrictions */
> +                p2m_lock(p2m);
> +                p2m->set_entry(p2m, gfn, mfn, PAGE_ORDER_4K, p2mt, p2m_access_rwx);
> +                p2m_unlock(p2m);
> +            }
>              return 1;
>          }

This logic is getting a bit convoluted, and I'm not sure it's correct.
If a page is marked n2rwx and there's no listener, it looks like this
will cause it to spin forever re-taking the fault rather than pausing it
waiting for the listener to attach.

Cheers,

Tim.

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 16:28:31 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 16:28:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW9Ua-0004sg-HY; Thu, 01 Dec 2011 16:28:12 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RW9UY-0004s1-Ro
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 16:28:11 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1322756850!5743952!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU2Nw==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23387 invoked from network); 1 Dec 2011 16:27:31 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 16:27:31 -0000
X-IronPort-AV: E=Sophos;i="4.71,279,1320624000"; 
   d="scan'208";a="9235916"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Dec 2011 16:27:07 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 1 Dec 2011 16:27:07 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RW9TW-0003bS-Vo; Thu, 01 Dec 2011 16:27:07 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RW9TW-0002eW-TE;
	Thu, 01 Dec 2011 16:27:06 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20183.43738.892968.831165@mariner.uk.xensource.com>
Date: Thu, 1 Dec 2011 16:27:06 +0000
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <alpine.DEB.2.00.1111301409360.31179@kaball-desktop>
References: <alpine.DEB.2.00.1111301409360.31179@kaball-desktop>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH XenDocDay 00/19] xl.pod.1 updates and fixes
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Stefano Stabellini writes ("[Xen-devel] [PATCH XenDocDay 00/19] xl.pod.1 updates and fixes"):
> this patch series containes few updates and fixes to xl.pod.1.

Excellent.  Applied the lot, thanks.

Ian.

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 16:28:31 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 16:28:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW9Ua-0004sg-HY; Thu, 01 Dec 2011 16:28:12 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RW9UY-0004s1-Ro
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 16:28:11 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1322756850!5743952!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU2Nw==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23387 invoked from network); 1 Dec 2011 16:27:31 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 16:27:31 -0000
X-IronPort-AV: E=Sophos;i="4.71,279,1320624000"; 
   d="scan'208";a="9235916"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Dec 2011 16:27:07 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 1 Dec 2011 16:27:07 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RW9TW-0003bS-Vo; Thu, 01 Dec 2011 16:27:07 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RW9TW-0002eW-TE;
	Thu, 01 Dec 2011 16:27:06 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20183.43738.892968.831165@mariner.uk.xensource.com>
Date: Thu, 1 Dec 2011 16:27:06 +0000
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <alpine.DEB.2.00.1111301409360.31179@kaball-desktop>
References: <alpine.DEB.2.00.1111301409360.31179@kaball-desktop>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH XenDocDay 00/19] xl.pod.1 updates and fixes
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Stefano Stabellini writes ("[Xen-devel] [PATCH XenDocDay 00/19] xl.pod.1 updates and fixes"):
> this patch series containes few updates and fixes to xl.pod.1.

Excellent.  Applied the lot, thanks.

Ian.

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 16:29:46 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 16: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.xensource.com>)
	id 1RW9Vw-000517-16; Thu, 01 Dec 2011 16:29:36 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RW9Vv-00050l-8o
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 16:29:35 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1322756831!54506621!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU2Nw==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29403 invoked from network); 1 Dec 2011 16:27:11 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 16:27:11 -0000
X-IronPort-AV: E=Sophos;i="4.71,279,1320624000"; 
   d="scan'208";a="9235953"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Dec 2011 16:28:57 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 1 Dec 2011 16:28:57 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RW9VI-0003c3-Ta; Thu, 01 Dec 2011 16:28:56 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RW9VI-0002mF-Sl;
	Thu, 01 Dec 2011 16:28:56 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20183.43848.714684.20583@mariner.uk.xensource.com>
Date: Thu, 1 Dec 2011 16:28:56 +0000
To: Anthony PERARD <anthony.perard@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1322662744-27030-1-git-send-email-anthony.perard@citrix.com>
References: <1322662744-27030-1-git-send-email-anthony.perard@citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Xen Devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH V2] xl: Apply CLOEXEC to the restore_fd.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Anthony PERARD writes ("[Xen-devel] [PATCH V2] xl: Apply CLOEXEC to the restore_fd."):
> At restore time, the file descriptor opened on the migration state file is
> still open in the device model. Let's apply FD_CLOEXEC to it.

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 16:29:46 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 16: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.xensource.com>)
	id 1RW9Vw-000517-16; Thu, 01 Dec 2011 16:29:36 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RW9Vv-00050l-8o
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 16:29:35 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1322756831!54506621!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU2Nw==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29403 invoked from network); 1 Dec 2011 16:27:11 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 16:27:11 -0000
X-IronPort-AV: E=Sophos;i="4.71,279,1320624000"; 
   d="scan'208";a="9235953"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Dec 2011 16:28:57 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 1 Dec 2011 16:28:57 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RW9VI-0003c3-Ta; Thu, 01 Dec 2011 16:28:56 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RW9VI-0002mF-Sl;
	Thu, 01 Dec 2011 16:28:56 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20183.43848.714684.20583@mariner.uk.xensource.com>
Date: Thu, 1 Dec 2011 16:28:56 +0000
To: Anthony PERARD <anthony.perard@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1322662744-27030-1-git-send-email-anthony.perard@citrix.com>
References: <1322662744-27030-1-git-send-email-anthony.perard@citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Xen Devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH V2] xl: Apply CLOEXEC to the restore_fd.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Anthony PERARD writes ("[Xen-devel] [PATCH V2] xl: Apply CLOEXEC to the restore_fd."):
> At restore time, the file descriptor opened on the migration state file is
> still open in the device model. Let's apply FD_CLOEXEC to it.

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 16:34:38 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 16: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.xensource.com>)
	id 1RW9ae-0005P8-CM; Thu, 01 Dec 2011 16:34:28 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RW9ad-0005Oo-3x
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 16:34:27 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-2.tower-182.messagelabs.com!1322757226!5495852!1
X-Originating-IP: [208.97.132.207]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4yMDcgPT4gMTU1MDU=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4375 invoked from network); 1 Dec 2011 16:33:47 -0000
Received: from caiajhbdccah.dreamhost.com (HELO homiemail-a22.g.dreamhost.com)
	(208.97.132.207) by server-2.tower-182.messagelabs.com with SMTP;
	1 Dec 2011 16:33:47 -0000
Received: from homiemail-a22.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a22.g.dreamhost.com (Postfix) with ESMTP id 8ECE91A808B;
	Thu,  1 Dec 2011 08:33:45 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=tgfLH8t/Ye7pQdDU4+460UdGE5KNhYYHQAb6QUSQ58vv
	IM8SfbGSSKWLCO/G2RzGSK2JJJy3OA3+JkZbNp+o3j32M2v9QVBULTDji/paa9lB
	Av9XhyiAn7CnKsCu8C1LjM40btW8hcaR3t+V+91iW7QDmg5XxBvjmTs6wsGboIE=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=EBld7mbqutPkifsmSUxpWS/3weM=; b=lif0Mo99
	5fFrhs9c/xm1eN8aU/RBTKSUw+v3eydb+EScuRkaL6keE30521+hcwlzihOD79Pn
	DMD75F8xT2wE5wYgAi7K4P6LFivqXJ+WqmIw0Zqg/2P4e0IPDYByLHmE3LnPQanr
	428r1H/4AAiFNw06OoGM2D4WPdoNkioJ6OI=
Received: from webmail.lagarcavilla.org (ahfbbjcaiaae.dreamhost.com
	[75.119.208.4]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a22.g.dreamhost.com (Postfix) with ESMTPA id 18D2C1A8083; 
	Thu,  1 Dec 2011 08:33:45 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP; Thu, 1 Dec 2011 08:33:45 -0800
Message-ID: <4611eaffc30e98df4300542aa9ca5891.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20111201162534.GJ61203@ocelot.phlegethon.org>
References: <patchbomb.1322603903@xdev.gridcentric.ca>
	<52d6aede6206e2cd7d17.1322603905@xdev.gridcentric.ca>
	<20111201162534.GJ61203@ocelot.phlegethon.org>
Date: Thu, 1 Dec 2011 08:33:45 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Tim Deegan" <tim@xen.org>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com, keir.xen@gmail.com,
	jbeulich@suse.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 2 of 2] x86/mm: New mem access type to log
 access
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> At 16:58 -0500 on 29 Nov (1322585905), Andres Lagar-Cavilla wrote:
>> @@ -1162,10 +1167,13 @@ int p2m_mem_access_check(unsigned long g
>>          }
>>          else
>>          {
>> -            /* A listener is not required, so clear the access
>> restrictions */
>> -            p2m_lock(p2m);
>> -            p2m->set_entry(p2m, gfn, mfn, PAGE_ORDER_4K, p2mt,
>> p2m_access_rwx);
>> -            p2m_unlock(p2m);
>> +            if ( p2ma != p2m_access_n2rwx )
>> +            {
>> +                /* A listener is not required, so clear the access
>> restrictions */
>> +                p2m_lock(p2m);
>> +                p2m->set_entry(p2m, gfn, mfn, PAGE_ORDER_4K, p2mt,
>> p2m_access_rwx);
>> +                p2m_unlock(p2m);
>> +            }
>>              return 1;
>>          }
>
> This logic is getting a bit convoluted, and I'm not sure it's correct.
> If a page is marked n2rwx and there's no listener, it looks like this
> will cause it to spin forever re-taking the fault rather than pausing it
> waiting for the listener to attach.

The entry is set to p2m_access_rwx, so no additional faults will be
generated. In the n2rwx case, the entry was promoted to rwx previously, in
 a p2m_lock protected section. We're avoiding a repeat here.

Andres

>
> Cheers,
>
> Tim.
>



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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 16:34:38 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 16: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.xensource.com>)
	id 1RW9ae-0005P8-CM; Thu, 01 Dec 2011 16:34:28 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RW9ad-0005Oo-3x
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 16:34:27 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-2.tower-182.messagelabs.com!1322757226!5495852!1
X-Originating-IP: [208.97.132.207]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4yMDcgPT4gMTU1MDU=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4375 invoked from network); 1 Dec 2011 16:33:47 -0000
Received: from caiajhbdccah.dreamhost.com (HELO homiemail-a22.g.dreamhost.com)
	(208.97.132.207) by server-2.tower-182.messagelabs.com with SMTP;
	1 Dec 2011 16:33:47 -0000
Received: from homiemail-a22.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a22.g.dreamhost.com (Postfix) with ESMTP id 8ECE91A808B;
	Thu,  1 Dec 2011 08:33:45 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=tgfLH8t/Ye7pQdDU4+460UdGE5KNhYYHQAb6QUSQ58vv
	IM8SfbGSSKWLCO/G2RzGSK2JJJy3OA3+JkZbNp+o3j32M2v9QVBULTDji/paa9lB
	Av9XhyiAn7CnKsCu8C1LjM40btW8hcaR3t+V+91iW7QDmg5XxBvjmTs6wsGboIE=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=EBld7mbqutPkifsmSUxpWS/3weM=; b=lif0Mo99
	5fFrhs9c/xm1eN8aU/RBTKSUw+v3eydb+EScuRkaL6keE30521+hcwlzihOD79Pn
	DMD75F8xT2wE5wYgAi7K4P6LFivqXJ+WqmIw0Zqg/2P4e0IPDYByLHmE3LnPQanr
	428r1H/4AAiFNw06OoGM2D4WPdoNkioJ6OI=
Received: from webmail.lagarcavilla.org (ahfbbjcaiaae.dreamhost.com
	[75.119.208.4]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a22.g.dreamhost.com (Postfix) with ESMTPA id 18D2C1A8083; 
	Thu,  1 Dec 2011 08:33:45 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP; Thu, 1 Dec 2011 08:33:45 -0800
Message-ID: <4611eaffc30e98df4300542aa9ca5891.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20111201162534.GJ61203@ocelot.phlegethon.org>
References: <patchbomb.1322603903@xdev.gridcentric.ca>
	<52d6aede6206e2cd7d17.1322603905@xdev.gridcentric.ca>
	<20111201162534.GJ61203@ocelot.phlegethon.org>
Date: Thu, 1 Dec 2011 08:33:45 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Tim Deegan" <tim@xen.org>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com, keir.xen@gmail.com,
	jbeulich@suse.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 2 of 2] x86/mm: New mem access type to log
 access
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> At 16:58 -0500 on 29 Nov (1322585905), Andres Lagar-Cavilla wrote:
>> @@ -1162,10 +1167,13 @@ int p2m_mem_access_check(unsigned long g
>>          }
>>          else
>>          {
>> -            /* A listener is not required, so clear the access
>> restrictions */
>> -            p2m_lock(p2m);
>> -            p2m->set_entry(p2m, gfn, mfn, PAGE_ORDER_4K, p2mt,
>> p2m_access_rwx);
>> -            p2m_unlock(p2m);
>> +            if ( p2ma != p2m_access_n2rwx )
>> +            {
>> +                /* A listener is not required, so clear the access
>> restrictions */
>> +                p2m_lock(p2m);
>> +                p2m->set_entry(p2m, gfn, mfn, PAGE_ORDER_4K, p2mt,
>> p2m_access_rwx);
>> +                p2m_unlock(p2m);
>> +            }
>>              return 1;
>>          }
>
> This logic is getting a bit convoluted, and I'm not sure it's correct.
> If a page is marked n2rwx and there's no listener, it looks like this
> will cause it to spin forever re-taking the fault rather than pausing it
> waiting for the listener to attach.

The entry is set to p2m_access_rwx, so no additional faults will be
generated. In the n2rwx case, the entry was promoted to rwx previously, in
 a p2m_lock protected section. We're avoiding a repeat here.

Andres

>
> Cheers,
>
> Tim.
>



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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 16:40:28 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 16:40:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW9gF-0005XW-7u; Thu, 01 Dec 2011 16:40:15 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RW9gC-0005XG-Tj
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 16:40:13 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-9.tower-21.messagelabs.com!1322757571!311515!1
X-Originating-IP: [208.97.132.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMDguOTcuMTMyLjgxID0+IDE3ODM1\n,sa_preprocessor: 
	QmFkIElQOiAyMDguOTcuMTMyLjgxID0+IDE3ODM1\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16098 invoked from network); 1 Dec 2011 16:39:32 -0000
Received: from caiajhbdcaib.dreamhost.com (HELO homiemail-a13.g.dreamhost.com)
	(208.97.132.81) by server-9.tower-21.messagelabs.com with SMTP;
	1 Dec 2011 16:39:32 -0000
Received: from homiemail-a13.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a13.g.dreamhost.com (Postfix) with ESMTP id 21FF733406B;
	Thu,  1 Dec 2011 08:39:31 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=enqINpm5s9Y78iKE6b6TkGDx7bG9FoJ9k0KBQoPwTJMn
	EBVJuxgyjkfH2THDHYDtyyTn19ZroxDKwKCgR+L6mpknLtEKW6mhaLUe3y8yhJaY
	OayFmQtSq0sgnErmvw0ANzfRrexRqZeMscZnbMeVGhH5RIwTTjNtziStID2a6Gc=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=f8o1ho1x8215zGYxGqXW2+b8dNU=; b=Z/MOlqey
	SZkAz5DZ/5EFuC1pd+k2OoH8/r4I7ok3Z/S5bpS1LBp7BkHWODpfQrQSQrrcc93L
	xJD2A3ugGjwyJFmqY6/YCVxQcWKzD727EsIvHeiA/ur4j4JajKsEvjdtwoITepoQ
	pF4ysCPphLnmzYsr5MyVPJSR4tmVFn1et5E=
Received: from webmail.lagarcavilla.org (ahfbbjcaiaae.dreamhost.com
	[75.119.208.4]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a13.g.dreamhost.com (Postfix) with ESMTPA id 7CACB334064; 
	Thu,  1 Dec 2011 08:39:30 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP; Thu, 1 Dec 2011 08:39:31 -0800
Message-ID: <f797a50ffd0cdb8d401062e0e74810c7.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20111201161718.GI61203@ocelot.phlegethon.org>
References: <patchbomb.1322603903@xdev.gridcentric.ca>
	<d6354df726a063740423.1322603904@xdev.gridcentric.ca>
	<20111201161718.GI61203@ocelot.phlegethon.org>
Date: Thu, 1 Dec 2011 08:39:31 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Tim Deegan" <tim@xen.org>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com, keir.xen@gmail.com,
	jbeulich@suse.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 1 of 2] x86/mm: When mem event automatically
 promotes access rights, let other subsystems know
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> Hi,
>
> At 16:58 -0500 on 29 Nov (1322585904), Andres Lagar-Cavilla wrote:
>>  xen/arch/x86/hvm/hvm.c    |  45
>> ++++++++++++++++++++++++++++++++++++++-------
>>  xen/arch/x86/mm/p2m.c     |   8 +++++---
>>  xen/include/asm-x86/p2m.h |   9 +++++----
>>  3 files changed, 48 insertions(+), 14 deletions(-)
>>
>>
>> The mem event fault handler in the p2m can automatically promote the
>> access
>> rights of a p2m entry. In those scenarios, vcpu's are not paused and
>> they will
>> immediately retry the faulting instructions. This will generate a second
>> fault
>> if the underlying entry type requires so (paging, unsharing, pod, etc).
>> Collapse the two faults into a single one.
>>
>> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
>>
>> diff -r 29701f5bdd84 -r d6354df726a0 xen/arch/x86/hvm/hvm.c
>> --- a/xen/arch/x86/hvm/hvm.c
>> +++ b/xen/arch/x86/hvm/hvm.c
>> @@ -1278,9 +1278,13 @@ int hvm_hap_nested_page_fault(unsigned l
>>
>>          if ( violation )
>>          {
>> -            p2m_mem_access_check(gpa, gla_valid, gla, access_r,
>> access_w, access_x);
>> -            rc = 1;
>> -            goto out_put_gfn;
>> +            if ( !p2m_mem_access_check(gpa, gla_valid, gla, access_r,
>> +                                        access_w, access_x) )
>> +            {
>> +                /* Rights not promoted, vcpu paused, work here is done
>> */
>> +                rc = 1;
>> +                goto out_put_gfn;
>> +            }
>>          }
>>      }
>>
>> @@ -1288,7 +1292,8 @@ int hvm_hap_nested_page_fault(unsigned l
>>       * If this GFN is emulated MMIO or marked as read-only, pass the
>> fault
>>       * to the mmio handler.
>>       */
>> -    if ( (p2mt == p2m_mmio_dm) || (p2mt == p2m_ram_ro) )
>> +    if ( (p2mt == p2m_mmio_dm) ||
>> +         (access_w && (p2mt == p2m_ram_ro)) )
>
> I think this is a separate change from the main intent of the patch; it
> would be better to have two patches, once that inserts all these
> 'access_w' checks and a second that does what the cset comment
> decribes.
>
The new checks here and below are necessary because the fault handler
assumes that the fault could not have happened due to a constrain on the
access rights. So, new cases arise, such as the mmio_direct below. I can
add all the additional checks in patch 1, and allow the fall through in
patch 2.

(more below ...)

>>      {
>>          if ( !handle_mmio() )
>>              hvm_inject_exception(TRAP_gp_fault, 0, 0);
>> @@ -1302,7 +1307,7 @@ int hvm_hap_nested_page_fault(unsigned l
>>          p2m_mem_paging_populate(v->domain, gfn);
>>
>>      /* Mem sharing: unshare the page and try again */
>> -    if ( p2mt == p2m_ram_shared )
>> +    if ( access_w && (p2mt == p2m_ram_shared) )
>>      {
>>          ASSERT(!p2m_is_nestedp2m(p2m));
>>          mem_sharing_unshare_page(p2m->domain, gfn, 0);
>> @@ -1319,14 +1324,15 @@ int hvm_hap_nested_page_fault(unsigned l
>>           * a large page, we do not change other pages type within that
>> large
>>           * page.
>>           */
>> -        paging_mark_dirty(v->domain, mfn_x(mfn));
>> +        if ( access_w )
>> +            paging_mark_dirty(v->domain, mfn_x(mfn));
>>          p2m_change_type(v->domain, gfn, p2m_ram_logdirty, p2m_ram_rw);
>
> No!  If we call p2m_change_type(-->ram_rw) we _must_ call mark_dirty()
> too.  It would be OK to put both lines under the test, though.
>
Yup, thanks.

>>          rc = 1;
>>          goto out_put_gfn;
>>      }
>>
>>      /* Shouldn't happen: Maybe the guest was writing to a r/o grant
>> mapping? */
>> -    if ( p2mt == p2m_grant_map_ro )
>> +    if ( access_w && (p2mt == p2m_grant_map_ro) )
>>      {
>>          gdprintk(XENLOG_WARNING,
>>                   "trying to write to read-only grant mapping\n");
>> @@ -1335,6 +1341,31 @@ int hvm_hap_nested_page_fault(unsigned l
>>          goto out_put_gfn;
>>      }
>>
>> +    if ( access_x && (p2m_is_grant(p2mt)) )
>> +    {
>> +        gdprintk(XENLOG_WARNING,
>> +                 "trying to execut a grant mapping\n");
>> +        hvm_inject_exception(TRAP_gp_fault, 0, 0);
>> +        rc = 1;
>> +        goto out_put_gfn;
>> +    }
>
> Again, this is a separate bugfix and should go in its own patch.
>
>> +    if ( p2m_is_grant(p2mt) )
>> +    {
>> +        /* If we haven't caught this by now, then it's a valid access
>> */
>> +        rc = 1;
>> +        goto out_put_gfn;
>> +    }
>> +    if ( p2mt == p2m_mmio_direct )
>> +    {
>> +        if ( !(access_w &&
>> +                rangeset_contains_singleton(mmio_ro_ranges,
>> mfn_x(mfn))) ) {
>> +            rc = 1;
>> +            goto out_put_gfn;
>> +        }
>> +    }
>
> I wonder whether, rather than trying to enumerate all the acceptable
> cases here, you could just remember that p2m_mem_access_check() changed
> something and always return 1 in that case.
>
That's the behavior without this patch, isn't it?

>> +
>>      rc = 0;
>>  out_put_gfn:
>>      put_gfn(p2m->domain, gfn);
>> diff -r 29701f5bdd84 -r d6354df726a0 xen/arch/x86/mm/p2m.c
>> --- a/xen/arch/x86/mm/p2m.c
>> +++ b/xen/arch/x86/mm/p2m.c
>> @@ -1126,7 +1126,7 @@ void p2m_mem_paging_resume(struct domain
>>      mem_event_unpause_vcpus(d, &d->mem_paging);
>>  }
>>
>> -void p2m_mem_access_check(unsigned long gpa, bool_t gla_valid, unsigned
>> long gla,
>> +int p2m_mem_access_check(unsigned long gpa, bool_t gla_valid, unsigned
>> long gla,
>>                            bool_t access_r, bool_t access_w, bool_t
>> access_x)
>>  {
>>      struct vcpu *v = current;
>> @@ -1146,7 +1146,7 @@ void p2m_mem_access_check(unsigned long
>>      {
>>          p2m->set_entry(p2m, gfn, mfn, PAGE_ORDER_4K, p2mt,
>> p2m_access_rw);
>>          p2m_unlock(p2m);
>> -        return;
>> +        return 1;
>>      }
>>      p2m_unlock(p2m);
>>
>> @@ -1166,9 +1166,10 @@ void p2m_mem_access_check(unsigned long
>>              p2m_lock(p2m);
>>              p2m->set_entry(p2m, gfn, mfn, PAGE_ORDER_4K, p2mt,
>> p2m_access_rwx);
>>              p2m_unlock(p2m);
>> +            return 1;
>>          }
>>
>> -        return;
>> +        return 0;
>>      }
>>
>>      memset(&req, 0, sizeof(req));
>> @@ -1192,6 +1193,7 @@ void p2m_mem_access_check(unsigned long
>>
>>      (void)mem_event_put_request(d, &d->mem_access, &req);
>>      /* VCPU paused */
>> +    return 0;
>>  }
>>
>>  void p2m_mem_access_resume(struct domain *d)
>> diff -r 29701f5bdd84 -r d6354df726a0 xen/include/asm-x86/p2m.h
>> --- a/xen/include/asm-x86/p2m.h
>> +++ b/xen/include/asm-x86/p2m.h
>> @@ -491,8 +491,9 @@ static inline void p2m_mem_paging_popula
>>
>>  #ifdef __x86_64__
>>  /* Send mem event based on the access (gla is -1ull if not available).
>> Handles
>> - * the rw2rx conversion */
>> -void p2m_mem_access_check(unsigned long gpa, bool_t gla_valid, unsigned
>> long gla,
>> + * the rw2rx conversion. Return value indicate if access rights have
>> been
>> + * promoted with no underlying vcpu pause. */
>
> How does it indicate that -- i.e., what values can it return and what do
> they mean?  (And if it only returns 0 or 1, maybe use bool_t.)
>
Ok, bool_t.

> Cheers,
>
> Tim.
>



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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 16:40:28 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 16:40:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW9gF-0005XW-7u; Thu, 01 Dec 2011 16:40:15 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RW9gC-0005XG-Tj
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 16:40:13 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-9.tower-21.messagelabs.com!1322757571!311515!1
X-Originating-IP: [208.97.132.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMDguOTcuMTMyLjgxID0+IDE3ODM1\n,sa_preprocessor: 
	QmFkIElQOiAyMDguOTcuMTMyLjgxID0+IDE3ODM1\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16098 invoked from network); 1 Dec 2011 16:39:32 -0000
Received: from caiajhbdcaib.dreamhost.com (HELO homiemail-a13.g.dreamhost.com)
	(208.97.132.81) by server-9.tower-21.messagelabs.com with SMTP;
	1 Dec 2011 16:39:32 -0000
Received: from homiemail-a13.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a13.g.dreamhost.com (Postfix) with ESMTP id 21FF733406B;
	Thu,  1 Dec 2011 08:39:31 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=enqINpm5s9Y78iKE6b6TkGDx7bG9FoJ9k0KBQoPwTJMn
	EBVJuxgyjkfH2THDHYDtyyTn19ZroxDKwKCgR+L6mpknLtEKW6mhaLUe3y8yhJaY
	OayFmQtSq0sgnErmvw0ANzfRrexRqZeMscZnbMeVGhH5RIwTTjNtziStID2a6Gc=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=f8o1ho1x8215zGYxGqXW2+b8dNU=; b=Z/MOlqey
	SZkAz5DZ/5EFuC1pd+k2OoH8/r4I7ok3Z/S5bpS1LBp7BkHWODpfQrQSQrrcc93L
	xJD2A3ugGjwyJFmqY6/YCVxQcWKzD727EsIvHeiA/ur4j4JajKsEvjdtwoITepoQ
	pF4ysCPphLnmzYsr5MyVPJSR4tmVFn1et5E=
Received: from webmail.lagarcavilla.org (ahfbbjcaiaae.dreamhost.com
	[75.119.208.4]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a13.g.dreamhost.com (Postfix) with ESMTPA id 7CACB334064; 
	Thu,  1 Dec 2011 08:39:30 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP; Thu, 1 Dec 2011 08:39:31 -0800
Message-ID: <f797a50ffd0cdb8d401062e0e74810c7.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20111201161718.GI61203@ocelot.phlegethon.org>
References: <patchbomb.1322603903@xdev.gridcentric.ca>
	<d6354df726a063740423.1322603904@xdev.gridcentric.ca>
	<20111201161718.GI61203@ocelot.phlegethon.org>
Date: Thu, 1 Dec 2011 08:39:31 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Tim Deegan" <tim@xen.org>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com, keir.xen@gmail.com,
	jbeulich@suse.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 1 of 2] x86/mm: When mem event automatically
 promotes access rights, let other subsystems know
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> Hi,
>
> At 16:58 -0500 on 29 Nov (1322585904), Andres Lagar-Cavilla wrote:
>>  xen/arch/x86/hvm/hvm.c    |  45
>> ++++++++++++++++++++++++++++++++++++++-------
>>  xen/arch/x86/mm/p2m.c     |   8 +++++---
>>  xen/include/asm-x86/p2m.h |   9 +++++----
>>  3 files changed, 48 insertions(+), 14 deletions(-)
>>
>>
>> The mem event fault handler in the p2m can automatically promote the
>> access
>> rights of a p2m entry. In those scenarios, vcpu's are not paused and
>> they will
>> immediately retry the faulting instructions. This will generate a second
>> fault
>> if the underlying entry type requires so (paging, unsharing, pod, etc).
>> Collapse the two faults into a single one.
>>
>> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
>>
>> diff -r 29701f5bdd84 -r d6354df726a0 xen/arch/x86/hvm/hvm.c
>> --- a/xen/arch/x86/hvm/hvm.c
>> +++ b/xen/arch/x86/hvm/hvm.c
>> @@ -1278,9 +1278,13 @@ int hvm_hap_nested_page_fault(unsigned l
>>
>>          if ( violation )
>>          {
>> -            p2m_mem_access_check(gpa, gla_valid, gla, access_r,
>> access_w, access_x);
>> -            rc = 1;
>> -            goto out_put_gfn;
>> +            if ( !p2m_mem_access_check(gpa, gla_valid, gla, access_r,
>> +                                        access_w, access_x) )
>> +            {
>> +                /* Rights not promoted, vcpu paused, work here is done
>> */
>> +                rc = 1;
>> +                goto out_put_gfn;
>> +            }
>>          }
>>      }
>>
>> @@ -1288,7 +1292,8 @@ int hvm_hap_nested_page_fault(unsigned l
>>       * If this GFN is emulated MMIO or marked as read-only, pass the
>> fault
>>       * to the mmio handler.
>>       */
>> -    if ( (p2mt == p2m_mmio_dm) || (p2mt == p2m_ram_ro) )
>> +    if ( (p2mt == p2m_mmio_dm) ||
>> +         (access_w && (p2mt == p2m_ram_ro)) )
>
> I think this is a separate change from the main intent of the patch; it
> would be better to have two patches, once that inserts all these
> 'access_w' checks and a second that does what the cset comment
> decribes.
>
The new checks here and below are necessary because the fault handler
assumes that the fault could not have happened due to a constrain on the
access rights. So, new cases arise, such as the mmio_direct below. I can
add all the additional checks in patch 1, and allow the fall through in
patch 2.

(more below ...)

>>      {
>>          if ( !handle_mmio() )
>>              hvm_inject_exception(TRAP_gp_fault, 0, 0);
>> @@ -1302,7 +1307,7 @@ int hvm_hap_nested_page_fault(unsigned l
>>          p2m_mem_paging_populate(v->domain, gfn);
>>
>>      /* Mem sharing: unshare the page and try again */
>> -    if ( p2mt == p2m_ram_shared )
>> +    if ( access_w && (p2mt == p2m_ram_shared) )
>>      {
>>          ASSERT(!p2m_is_nestedp2m(p2m));
>>          mem_sharing_unshare_page(p2m->domain, gfn, 0);
>> @@ -1319,14 +1324,15 @@ int hvm_hap_nested_page_fault(unsigned l
>>           * a large page, we do not change other pages type within that
>> large
>>           * page.
>>           */
>> -        paging_mark_dirty(v->domain, mfn_x(mfn));
>> +        if ( access_w )
>> +            paging_mark_dirty(v->domain, mfn_x(mfn));
>>          p2m_change_type(v->domain, gfn, p2m_ram_logdirty, p2m_ram_rw);
>
> No!  If we call p2m_change_type(-->ram_rw) we _must_ call mark_dirty()
> too.  It would be OK to put both lines under the test, though.
>
Yup, thanks.

>>          rc = 1;
>>          goto out_put_gfn;
>>      }
>>
>>      /* Shouldn't happen: Maybe the guest was writing to a r/o grant
>> mapping? */
>> -    if ( p2mt == p2m_grant_map_ro )
>> +    if ( access_w && (p2mt == p2m_grant_map_ro) )
>>      {
>>          gdprintk(XENLOG_WARNING,
>>                   "trying to write to read-only grant mapping\n");
>> @@ -1335,6 +1341,31 @@ int hvm_hap_nested_page_fault(unsigned l
>>          goto out_put_gfn;
>>      }
>>
>> +    if ( access_x && (p2m_is_grant(p2mt)) )
>> +    {
>> +        gdprintk(XENLOG_WARNING,
>> +                 "trying to execut a grant mapping\n");
>> +        hvm_inject_exception(TRAP_gp_fault, 0, 0);
>> +        rc = 1;
>> +        goto out_put_gfn;
>> +    }
>
> Again, this is a separate bugfix and should go in its own patch.
>
>> +    if ( p2m_is_grant(p2mt) )
>> +    {
>> +        /* If we haven't caught this by now, then it's a valid access
>> */
>> +        rc = 1;
>> +        goto out_put_gfn;
>> +    }
>> +    if ( p2mt == p2m_mmio_direct )
>> +    {
>> +        if ( !(access_w &&
>> +                rangeset_contains_singleton(mmio_ro_ranges,
>> mfn_x(mfn))) ) {
>> +            rc = 1;
>> +            goto out_put_gfn;
>> +        }
>> +    }
>
> I wonder whether, rather than trying to enumerate all the acceptable
> cases here, you could just remember that p2m_mem_access_check() changed
> something and always return 1 in that case.
>
That's the behavior without this patch, isn't it?

>> +
>>      rc = 0;
>>  out_put_gfn:
>>      put_gfn(p2m->domain, gfn);
>> diff -r 29701f5bdd84 -r d6354df726a0 xen/arch/x86/mm/p2m.c
>> --- a/xen/arch/x86/mm/p2m.c
>> +++ b/xen/arch/x86/mm/p2m.c
>> @@ -1126,7 +1126,7 @@ void p2m_mem_paging_resume(struct domain
>>      mem_event_unpause_vcpus(d, &d->mem_paging);
>>  }
>>
>> -void p2m_mem_access_check(unsigned long gpa, bool_t gla_valid, unsigned
>> long gla,
>> +int p2m_mem_access_check(unsigned long gpa, bool_t gla_valid, unsigned
>> long gla,
>>                            bool_t access_r, bool_t access_w, bool_t
>> access_x)
>>  {
>>      struct vcpu *v = current;
>> @@ -1146,7 +1146,7 @@ void p2m_mem_access_check(unsigned long
>>      {
>>          p2m->set_entry(p2m, gfn, mfn, PAGE_ORDER_4K, p2mt,
>> p2m_access_rw);
>>          p2m_unlock(p2m);
>> -        return;
>> +        return 1;
>>      }
>>      p2m_unlock(p2m);
>>
>> @@ -1166,9 +1166,10 @@ void p2m_mem_access_check(unsigned long
>>              p2m_lock(p2m);
>>              p2m->set_entry(p2m, gfn, mfn, PAGE_ORDER_4K, p2mt,
>> p2m_access_rwx);
>>              p2m_unlock(p2m);
>> +            return 1;
>>          }
>>
>> -        return;
>> +        return 0;
>>      }
>>
>>      memset(&req, 0, sizeof(req));
>> @@ -1192,6 +1193,7 @@ void p2m_mem_access_check(unsigned long
>>
>>      (void)mem_event_put_request(d, &d->mem_access, &req);
>>      /* VCPU paused */
>> +    return 0;
>>  }
>>
>>  void p2m_mem_access_resume(struct domain *d)
>> diff -r 29701f5bdd84 -r d6354df726a0 xen/include/asm-x86/p2m.h
>> --- a/xen/include/asm-x86/p2m.h
>> +++ b/xen/include/asm-x86/p2m.h
>> @@ -491,8 +491,9 @@ static inline void p2m_mem_paging_popula
>>
>>  #ifdef __x86_64__
>>  /* Send mem event based on the access (gla is -1ull if not available).
>> Handles
>> - * the rw2rx conversion */
>> -void p2m_mem_access_check(unsigned long gpa, bool_t gla_valid, unsigned
>> long gla,
>> + * the rw2rx conversion. Return value indicate if access rights have
>> been
>> + * promoted with no underlying vcpu pause. */
>
> How does it indicate that -- i.e., what values can it return and what do
> they mean?  (And if it only returns 0 or 1, maybe use bool_t.)
>
Ok, bool_t.

> Cheers,
>
> Tim.
>



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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 16:42:35 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 16:42:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW9iH-0005f7-VB; Thu, 01 Dec 2011 16:42:21 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RW9iG-0005eh-Ul
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 16:42:21 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1322757654!59100421!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU2Nw==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11766 invoked from network); 1 Dec 2011 16:40:54 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 16:40:54 -0000
X-IronPort-AV: E=Sophos;i="4.71,279,1320624000"; 
   d="scan'208";a="9236184"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Dec 2011 16:41:41 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 1 Dec 2011 16:41:41 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RW9hc-0003gO-It; Thu, 01 Dec 2011 16:41:40 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RW9hc-0002nF-HN;
	Thu, 01 Dec 2011 16:41:40 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20183.44612.524027.670338@mariner.uk.xensource.com>
Date: Thu, 1 Dec 2011 16:41:40 +0000
To: Paul Durrant <Paul.Durrant@citrix.com>, Konrad Rzeszutek Wilk
	<konrad@darnok.org>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <20111130221419.GA16651@andromeda.dapyr.net>,
	<291EDFCB1E9E224A99088639C4762022B5988E50D4@LONPMAILBOX01.citrite.net>
References: <94a17182f386c8bb414e.1322686717@cosworth.uk.xensource.com>
	<20111130221419.GA16651@andromeda.dapyr.net>
	<291EDFCB1E9E224A99088639C4762022B5988E50D4@LONPMAILBOX01.citrite.net>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] Add code to track the address of the
	VM	generation id buffer across a [and 1 more messages]
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Konrad Rzeszutek Wilk writes ("Re: [Xen-devel] [PATCH] Add code to track the address of the VM generation id buffer across a"):
> So what is a generation id? What is the use-case for this?

Paul Durrant writes ("Re: [Xen-devel] [PATCH] Add code to track the address of the VM generation id buffer across a"):
>   Did you see my previous patch set? The introductory comment was:
> 
> -----
> The following is a revised patch series to add support for a VM generation ID virtual device for HVM guests.
> The basic requirements of this device are as follows:

This explains "what" but not "why".

Also, please don't top post.

Ian.

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 16:42:35 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 16:42:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW9iH-0005f7-VB; Thu, 01 Dec 2011 16:42:21 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RW9iG-0005eh-Ul
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 16:42:21 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1322757654!59100421!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU2Nw==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11766 invoked from network); 1 Dec 2011 16:40:54 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 16:40:54 -0000
X-IronPort-AV: E=Sophos;i="4.71,279,1320624000"; 
   d="scan'208";a="9236184"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Dec 2011 16:41:41 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 1 Dec 2011 16:41:41 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RW9hc-0003gO-It; Thu, 01 Dec 2011 16:41:40 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RW9hc-0002nF-HN;
	Thu, 01 Dec 2011 16:41:40 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20183.44612.524027.670338@mariner.uk.xensource.com>
Date: Thu, 1 Dec 2011 16:41:40 +0000
To: Paul Durrant <Paul.Durrant@citrix.com>, Konrad Rzeszutek Wilk
	<konrad@darnok.org>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <20111130221419.GA16651@andromeda.dapyr.net>,
	<291EDFCB1E9E224A99088639C4762022B5988E50D4@LONPMAILBOX01.citrite.net>
References: <94a17182f386c8bb414e.1322686717@cosworth.uk.xensource.com>
	<20111130221419.GA16651@andromeda.dapyr.net>
	<291EDFCB1E9E224A99088639C4762022B5988E50D4@LONPMAILBOX01.citrite.net>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] Add code to track the address of the
	VM	generation id buffer across a [and 1 more messages]
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Konrad Rzeszutek Wilk writes ("Re: [Xen-devel] [PATCH] Add code to track the address of the VM generation id buffer across a"):
> So what is a generation id? What is the use-case for this?

Paul Durrant writes ("Re: [Xen-devel] [PATCH] Add code to track the address of the VM generation id buffer across a"):
>   Did you see my previous patch set? The introductory comment was:
> 
> -----
> The following is a revised patch series to add support for a VM generation ID virtual device for HVM guests.
> The basic requirements of this device are as follows:

This explains "what" but not "why".

Also, please don't top post.

Ian.

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 16:46:06 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 16:46:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW9li-0005wS-K6; Thu, 01 Dec 2011 16:45:54 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <arnd@arndb.de>) id 1RW9lg-0005vp-JW
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 16:45:52 +0000
X-Env-Sender: arnd@arndb.de
X-Msg-Ref: server-6.tower-174.messagelabs.com!1322757912!3897201!1
X-Originating-IP: [212.227.126.171]
X-SpamReason: No, hits=0.5 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMTIuMjI3LjEyNi4xNzEgPT4gODE3NTg=\n,sa_preprocessor: 
	QmFkIElQOiAyMTIuMjI3LjEyNi4xNzEgPT4gODE3NTg=\n,BODY_RANDOM_LONG
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29296 invoked from network); 1 Dec 2011 16:45:12 -0000
Received: from moutng.kundenserver.de (HELO moutng.kundenserver.de)
	(212.227.126.171) by server-6.tower-174.messagelabs.com with SMTP;
	1 Dec 2011 16:45:12 -0000
Received: from klappe2.localnet (deibp9eh1--blueice3n2.emea.ibm.com
	[195.212.29.180])
	by mrelayeu.kundenserver.de (node=mrbap3) with ESMTP (Nemesis)
	id 0Lilwb-1QxdLS3N5J-00dBlj; Thu, 01 Dec 2011 17:44:44 +0100
From: Arnd Bergmann <arnd@arndb.de>
To: linux-arm-kernel@lists.infradead.org
Date: Thu, 1 Dec 2011 16:44:40 +0000
User-Agent: KMail/1.12.2 (Linux/3.2.0-rc1+; KDE/4.3.2; x86_64; ; )
References: <alpine.DEB.2.00.1111281009090.31179@kaball-desktop>
	<201112011542.19377.arnd@arndb.de> <20111201160241.GH27394@arm.com>
In-Reply-To: <20111201160241.GH27394@arm.com>
MIME-Version: 1.0
Message-Id: <201112011644.41101.arnd@arndb.de>
X-Provags-ID: V02:K0:p490NXiUoEFWV5EAU4sSp3+/rvpahtzfRdSmhYrWno5
	q5LsxWBu6wn990QuYgcEQDvPApnRTtcU3kNrsyYTCYQtLTUhIr
	23rhsoQbtwt3kcaUPuCVnFFoCmEfeDEVd8JCESh3gyx0CQcsU2
	mUnZSamNxIsRaB9j+2rq/kKdoM3UC6f9h8SksK2EZPUtZgnNNL
	HEGn+plDVWSLWDpjNXD5LBt2LmLm6kxBNb1eAgPP1R98ll1F5W
	MI7FwFW/0V6lJnSULvISihVYWoFHJ/g4u5v/RsuVXSwlx2WGOP
	cTQRDc2DeENy7buG8dTwO557HYz4xyxr4nRLkcLSWU+K094G9S
	ydysH5u8YaveLHbvhCm8=
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linaro-dev@lists.linaro.org" <linaro-dev@lists.linaro.org>,
	Ian Campbell <Ian.Campbell@citrix.com>, Pawel Moll <Pawel.Moll@arm.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"virtualization@lists.linux-foundation.org"
	<virtualization@lists.linux-foundation.org>,
	"android-virt@lists.cs.columbia.edu" <android-virt@lists.cs.columbia.edu>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	"embeddedxen-devel@lists.sourceforge.net"
	<embeddedxen-devel@lists.sourceforge.net>
Subject: Re: [Xen-devel] [Android-virt] [Embeddedxen-devel] [ANNOUNCE] Xen
	port to Cortex-A15 / ARMv7 with virt extensions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thursday 01 December 2011, Catalin Marinas wrote:
> On Thu, Dec 01, 2011 at 03:42:19PM +0000, Arnd Bergmann wrote:
> > On Thursday 01 December 2011, Catalin Marinas wrote:
> > How do you deal with signed integer arguments passed into SVC or HVC from
> > a caller? If I understand the architecture correctly, the upper
> > halves of the argument register end up zero-padded, while the callee
> > expects sign-extension.
> 
> If you treat it as an "int" (32-bit) and function prototype defined
> accordingly, then the generated code only accesses it as a W (rather
> than X) register and the top 32-bit part is ignored (no need for
> sign-extension). If it is defined as a "long" in the 32-bit world, then
> it indeed needs explicit conversion given the different sizes for long
> (for example sys_lseek, the second argument is a 'long' and we do
> explicit sign extension in the wrapper).

Ok, so it's actually different from most other 64 bit architectures, which
normally operate on 64-bit registers and expect the caller to do the
correct sign-extension.

Doing the sign-extension for long arguments then falls into the same
category as long long and unsigned long long arguments, which also need
a wrapper, as you mentioned. Strictly speaking, we only need to do it
for those where the long argument has a meaning outside of the 0..2^31
range, e.g. io_submit can only take small positive numbers although
the type is 'long'.

What about unsigned long and pointer? Can we always rely on the upper
half of the register to be zero-filled when we get an exception from 32
bit into 64 bit state, or do we also have to zero-extend those?

	Arnd

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 16:46:06 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 16:46:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW9li-0005wS-K6; Thu, 01 Dec 2011 16:45:54 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <arnd@arndb.de>) id 1RW9lg-0005vp-JW
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 16:45:52 +0000
X-Env-Sender: arnd@arndb.de
X-Msg-Ref: server-6.tower-174.messagelabs.com!1322757912!3897201!1
X-Originating-IP: [212.227.126.171]
X-SpamReason: No, hits=0.5 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMTIuMjI3LjEyNi4xNzEgPT4gODE3NTg=\n,sa_preprocessor: 
	QmFkIElQOiAyMTIuMjI3LjEyNi4xNzEgPT4gODE3NTg=\n,BODY_RANDOM_LONG
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29296 invoked from network); 1 Dec 2011 16:45:12 -0000
Received: from moutng.kundenserver.de (HELO moutng.kundenserver.de)
	(212.227.126.171) by server-6.tower-174.messagelabs.com with SMTP;
	1 Dec 2011 16:45:12 -0000
Received: from klappe2.localnet (deibp9eh1--blueice3n2.emea.ibm.com
	[195.212.29.180])
	by mrelayeu.kundenserver.de (node=mrbap3) with ESMTP (Nemesis)
	id 0Lilwb-1QxdLS3N5J-00dBlj; Thu, 01 Dec 2011 17:44:44 +0100
From: Arnd Bergmann <arnd@arndb.de>
To: linux-arm-kernel@lists.infradead.org
Date: Thu, 1 Dec 2011 16:44:40 +0000
User-Agent: KMail/1.12.2 (Linux/3.2.0-rc1+; KDE/4.3.2; x86_64; ; )
References: <alpine.DEB.2.00.1111281009090.31179@kaball-desktop>
	<201112011542.19377.arnd@arndb.de> <20111201160241.GH27394@arm.com>
In-Reply-To: <20111201160241.GH27394@arm.com>
MIME-Version: 1.0
Message-Id: <201112011644.41101.arnd@arndb.de>
X-Provags-ID: V02:K0:p490NXiUoEFWV5EAU4sSp3+/rvpahtzfRdSmhYrWno5
	q5LsxWBu6wn990QuYgcEQDvPApnRTtcU3kNrsyYTCYQtLTUhIr
	23rhsoQbtwt3kcaUPuCVnFFoCmEfeDEVd8JCESh3gyx0CQcsU2
	mUnZSamNxIsRaB9j+2rq/kKdoM3UC6f9h8SksK2EZPUtZgnNNL
	HEGn+plDVWSLWDpjNXD5LBt2LmLm6kxBNb1eAgPP1R98ll1F5W
	MI7FwFW/0V6lJnSULvISihVYWoFHJ/g4u5v/RsuVXSwlx2WGOP
	cTQRDc2DeENy7buG8dTwO557HYz4xyxr4nRLkcLSWU+K094G9S
	ydysH5u8YaveLHbvhCm8=
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linaro-dev@lists.linaro.org" <linaro-dev@lists.linaro.org>,
	Ian Campbell <Ian.Campbell@citrix.com>, Pawel Moll <Pawel.Moll@arm.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"virtualization@lists.linux-foundation.org"
	<virtualization@lists.linux-foundation.org>,
	"android-virt@lists.cs.columbia.edu" <android-virt@lists.cs.columbia.edu>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	"embeddedxen-devel@lists.sourceforge.net"
	<embeddedxen-devel@lists.sourceforge.net>
Subject: Re: [Xen-devel] [Android-virt] [Embeddedxen-devel] [ANNOUNCE] Xen
	port to Cortex-A15 / ARMv7 with virt extensions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thursday 01 December 2011, Catalin Marinas wrote:
> On Thu, Dec 01, 2011 at 03:42:19PM +0000, Arnd Bergmann wrote:
> > On Thursday 01 December 2011, Catalin Marinas wrote:
> > How do you deal with signed integer arguments passed into SVC or HVC from
> > a caller? If I understand the architecture correctly, the upper
> > halves of the argument register end up zero-padded, while the callee
> > expects sign-extension.
> 
> If you treat it as an "int" (32-bit) and function prototype defined
> accordingly, then the generated code only accesses it as a W (rather
> than X) register and the top 32-bit part is ignored (no need for
> sign-extension). If it is defined as a "long" in the 32-bit world, then
> it indeed needs explicit conversion given the different sizes for long
> (for example sys_lseek, the second argument is a 'long' and we do
> explicit sign extension in the wrapper).

Ok, so it's actually different from most other 64 bit architectures, which
normally operate on 64-bit registers and expect the caller to do the
correct sign-extension.

Doing the sign-extension for long arguments then falls into the same
category as long long and unsigned long long arguments, which also need
a wrapper, as you mentioned. Strictly speaking, we only need to do it
for those where the long argument has a meaning outside of the 0..2^31
range, e.g. io_submit can only take small positive numbers although
the type is 'long'.

What about unsigned long and pointer? Can we always rely on the upper
half of the register to be zero-filled when we get an exception from 32
bit into 64 bit state, or do we also have to zero-extend those?

	Arnd

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 16:54:04 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 16:54:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW9tO-0006DM-L7; Thu, 01 Dec 2011 16:53:50 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RW9tN-0006DD-Gk
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 16:53:49 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-4.tower-216.messagelabs.com!1322758389!5799562!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7982 invoked from network); 1 Dec 2011 16:53:09 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-4.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 1 Dec 2011 16:53:09 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RW9sd-000Gw8-Ih; Thu, 01 Dec 2011 16:53:03 +0000
Date: Thu, 1 Dec 2011 16:53:03 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20111201165303.GK61203@ocelot.phlegethon.org>
References: <patchbomb.1322603903@xdev.gridcentric.ca>
	<d6354df726a063740423.1322603904@xdev.gridcentric.ca>
	<20111201161718.GI61203@ocelot.phlegethon.org>
	<f797a50ffd0cdb8d401062e0e74810c7.squirrel@webmail.lagarcavilla.org>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <f797a50ffd0cdb8d401062e0e74810c7.squirrel@webmail.lagarcavilla.org>
User-Agent: Mutt/1.4.2.1i
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com, keir.xen@gmail.com,
	jbeulich@suse.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 1 of 2] x86/mm: When mem event automatically
	promotes access rights, let other subsystems know
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 08:39 -0800 on 01 Dec (1322728771), Andres Lagar-Cavilla wrote:
> > I wonder whether, rather than trying to enumerate all the acceptable
> > cases here, you could just remember that p2m_mem_access_check() changed
> > something and always return 1 in that case.
> >
> That's the behavior without this patch, isn't it?

Yes, but that's not the _interesting_ change in this patch. :) 
The interesting thing is that you can upgrade the access rights and also
pass the fault to the mmio emulator without returning and retrying in
between. 

That is, I thin the change from 

    if (access fixup) return 1
    handle MMIO
    ...
    return 0 /* unhandled -- crash */

to 

   if (access fixup) remember we've done something
   handle MMIO
   ...
   if (we did a fixup above)
     return 1  /* try again */
   else
     return 0  /* crash */

does what you want without making the handler much bigger and more
brittle. 

Tim.

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 16:54:04 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 16:54:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RW9tO-0006DM-L7; Thu, 01 Dec 2011 16:53:50 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RW9tN-0006DD-Gk
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 16:53:49 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-4.tower-216.messagelabs.com!1322758389!5799562!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7982 invoked from network); 1 Dec 2011 16:53:09 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-4.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 1 Dec 2011 16:53:09 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RW9sd-000Gw8-Ih; Thu, 01 Dec 2011 16:53:03 +0000
Date: Thu, 1 Dec 2011 16:53:03 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20111201165303.GK61203@ocelot.phlegethon.org>
References: <patchbomb.1322603903@xdev.gridcentric.ca>
	<d6354df726a063740423.1322603904@xdev.gridcentric.ca>
	<20111201161718.GI61203@ocelot.phlegethon.org>
	<f797a50ffd0cdb8d401062e0e74810c7.squirrel@webmail.lagarcavilla.org>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <f797a50ffd0cdb8d401062e0e74810c7.squirrel@webmail.lagarcavilla.org>
User-Agent: Mutt/1.4.2.1i
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com, keir.xen@gmail.com,
	jbeulich@suse.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 1 of 2] x86/mm: When mem event automatically
	promotes access rights, let other subsystems know
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 08:39 -0800 on 01 Dec (1322728771), Andres Lagar-Cavilla wrote:
> > I wonder whether, rather than trying to enumerate all the acceptable
> > cases here, you could just remember that p2m_mem_access_check() changed
> > something and always return 1 in that case.
> >
> That's the behavior without this patch, isn't it?

Yes, but that's not the _interesting_ change in this patch. :) 
The interesting thing is that you can upgrade the access rights and also
pass the fault to the mmio emulator without returning and retrying in
between. 

That is, I thin the change from 

    if (access fixup) return 1
    handle MMIO
    ...
    return 0 /* unhandled -- crash */

to 

   if (access fixup) remember we've done something
   handle MMIO
   ...
   if (we did a fixup above)
     return 1  /* try again */
   else
     return 0  /* crash */

does what you want without making the handler much bigger and more
brittle. 

Tim.

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 17:15:02 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 17:15:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWADZ-0006c4-TP; Thu, 01 Dec 2011 17:14:41 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1RWADY-0006bz-6C
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 17:14:40 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1322759638!316015!1
X-Originating-IP: [74.125.83.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11971 invoked from network); 1 Dec 2011 17:13:59 -0000
Received: from mail-ee0-f43.google.com (HELO mail-ee0-f43.google.com)
	(74.125.83.43)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 17:13:59 -0000
Received: by eeaq46 with SMTP id q46so2686129eea.30
	for <xen-devel@lists.xensource.com>;
	Thu, 01 Dec 2011 09:13:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=9ufX0sASMvZiWLrER/5AwBt6EHpocuUa1DKXB269Hsg=;
	b=dbxgqKoJ08qcqy1dPhCdWxq7NZjPGmVPctRVlXVj+BwYoe0srcGbCswV6d1g/5cSAO
	um+xRJhV+sshdiAp3zl2tupTlUCrRXt+ZppPXcCHRbAaf29SY2rpA9mLd0kh55SCCXij
	okWtlZ1Oj+iRC7xQDQXyKRyM5mmXUREIe6HTc=
MIME-Version: 1.0
Received: by 10.227.209.66 with SMTP id gf2mr3265078wbb.20.1322759638465; Thu,
	01 Dec 2011 09:13:58 -0800 (PST)
Received: by 10.216.187.209 with HTTP; Thu, 1 Dec 2011 09:13:58 -0800 (PST)
In-Reply-To: <C10D3FB0CD45994C8A51FEC1227CE22F37499C2733@shsmsx502.ccr.corp.intel.com>
References: <C10D3FB0CD45994C8A51FEC1227CE22F340768D793@shsmsx502.ccr.corp.intel.com>
	<CAFLBxZZ9nqeb7CVqTZCsEtJRjgGMTHF2Ak929kvauj2KUFSOyg@mail.gmail.com>
	<C10D3FB0CD45994C8A51FEC1227CE22F3428CB5EF9@shsmsx502.ccr.corp.intel.com>
	<1319789425.19320.12.camel@Abyss>
	<C10D3FB0CD45994C8A51FEC1227CE22F3428CB61F2@shsmsx502.ccr.corp.intel.com>
	<1319796584.19320.31.camel@Abyss>
	<1319818714.21033.414.camel@elijah>
	<C10D3FB0CD45994C8A51FEC1227CE22F34B3905D03@shsmsx502.ccr.corp.intel.com>
	<CAFLBxZa5v_YgnC1LTa4a5wis4h6eQPijCAfUDLDsR4ucMuBXWg@mail.gmail.com>
	<C10D3FB0CD45994C8A51FEC1227CE22F37499C2733@shsmsx502.ccr.corp.intel.com>
Date: Thu, 1 Dec 2011 17:13:58 +0000
X-Google-Sender-Auth: l8yhAcaJNNIK1rMFNaOn-LPttqE
Message-ID: <CAFLBxZZ-F2hNTNHtiBCuQ0tVqJDe6btPnvofHK4KaDDQz8Rxtw@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: "Lv, Hui" <hui.lv@intel.com>
Content-Type: multipart/mixed; boundary=000e0cd672025fbfeb04b30afaed
Cc: "Tian, Kevin" <kevin.tian@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, "Dong, Eddie" <eddie.dong@intel.com>,
	George Dunlap <george.dunlap@citrix.com>, "Duan,
	Jiangang" <jiangang.duan@intel.com>, Dario Faggioli <raistlin@linux.it>
Subject: Re: [Xen-devel] [PATCH] scheduler rate controller
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--000e0cd672025fbfeb04b30afaed
Content-Type: text/plain; charset=ISO-8859-1

On Mon, Nov 28, 2011 at 5:31 PM, Lv, Hui <hui.lv@intel.com> wrote:
> Sorry for the late. I also met issues to boot up xen according to your patch, which is same as credit_3.patch that I attached.

Thanks Hui; debugging someone else's buggy code is going beyond
expectations. :-)

> So I modified it to the credit_1.patch and credit_2.patch, both of which work well.

Standard patches for OSS development need to be -p1, not -p0; they
need to work if, in the toplevel of the directory (foo.hg) you type
"patch -p1 < bar.patch". The easiest way to make one of these patches
is to use "hg diff"; the best way (if you're using Mercurial) is to
use Mercurual queues.

> 2) credit_2 adopts the constant sched_ratelimit_us value 1000.

Looks fine overall.  One issue with the patch is that it will not only
fail to preempt for a higher-priority vcpu, it will also fail to
preempt for tasklets.  Tasklet work must be done immediately.  Perhaps
we can add "!tasklet_work_scheduled" to the list of conditions for

Why did you change "MICROSECS" to "MILLISECS" when calculating
timeslice?  In this case, it will set the timeslice to a full second!
Not what we want...

>From a software maintenance perspective, I'm not a fan of early
returns from functions.  I think it's too easy not to notice that
there's a different return path.  In this case, I think I'd prefer
adding a label, and using "goto out;" instead.

> 1) credit_1 adopts "scheduling frequency counting" to decide the value of sched_ratelimit_us, which makes it adaptive.

If you were using mercurial queues, you could put this after the last
one, and it would be easier to see the proposed "adaptive" part of the
code. :-)

Hypervisors are very complicated; it's best to keep things as
absolutely simple as possible.  This kind of mechanism is exactly the
sort of thing that makes it very hard to predict what will happen.  I
think unless you can show that it adds a significant benefit, it's
better just to use the min timeslice.

Regarding this particular code, a couple of items, just for feedback:
* All of the ratelimiting code and data structures should be in the
pluggable scheduler, not in common code.
* This code hard-codes in '1000' as the value it sets the global
variable to, overriding whatever the user may have entered on the
command-line
* Furthermore, global variable is shared by all of the cpus, however;
meaning, you may have one cpu enabling it one moment based on its own
conditions, and have nother cpu disabling it almost immediatly
afterwards, based on conditions on that cpu.  If you're testing with
this at the moment, you might as well stop -- you're going to get a
pretty random result.  If you really wanted this to be an adaptive
solution, you'd need to make a per-cpu variable with the per-cpu rate
scheduling; and then set it to the global variable (which is the user
configuration).
* Finally, this patch doesn't distinguish between schedules that
happen due to a yield, and schedules that happen due to preemption.
The only schedules we have any control over are schedules that happen
due to preemption.  If adaptivity has any value, it should pay
attention to what it can control.

I've taken your two patches, given them the proper formating, and made
them into a patch series (the first adding the ratelimiting, the
second adding the adaptive bit); they are attached.  You should be
able to easily pull them into a mercurial patchqueue using "hg qimport
/path/to/patches/*.diff".  In the future, I will not look at any
patches which do not apply using either "patch -p1" or "hg qimport."

Thanks again for all your work on this -- I hope we can get a simple,
effective solution in place soon.

 -George

--000e0cd672025fbfeb04b30afaed
Content-Type: text/plain; charset=US-ASCII; name="01-credit-ratelimit.diff"
Content-Disposition: attachment; filename="01-credit-ratelimit.diff"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_gvo117ao3

IyBIRyBjaGFuZ2VzZXQgcGF0Y2gKIyBVc2VyIEdlb3JnZSBEdW5sYXAgPGdlb3JnZS5kdW5sYXBA
ZXUuY2l0cml4LmNvbT4KIyBEYXRlIDEzMjI3NTgyMDUgMAojIE5vZGUgSUQgZTEyMjQ4NWRmMzdi
NTdmNThkYmYxM2VjODFhMTgxNjljMGE3ZTkwZgojIFBhcmVudCAgOTZiYmRjODk0MjI0ODIxZmJj
MTRhMzNlOTNiNTU2ODg5MjBjN2ZkMgppbXBvcnRlZCBwYXRjaCBjcmVkaXRfMi5wYXRjaAoKZGlm
ZiAtciBjNjEzZDQzNmNhMDkgeGVuL2NvbW1vbi9zY2hlZF9jcmVkaXQuYwotLS0gYS94ZW4vY29t
bW9uL3NjaGVkX2NyZWRpdC5jCVR1ZSBOb3YgMjIgMTk6MDM6MDQgMjAxMSArMDAwMAorKysgYi94
ZW4vY29tbW9uL3NjaGVkX2NyZWRpdC5jCVRodSBEZWMgMDEgMTc6MTU6MTIgMjAxMSArMDAwMApA
QCAtMTE1LDYgKzExNSwxMCBAQCBzdGF0aWMgYm9vbF90IF9fcmVhZF9tb3N0bHkgc2NoZWRfY3Jl
ZGl0CiBib29sZWFuX3BhcmFtKCJzY2hlZF9jcmVkaXRfZGVmYXVsdF95aWVsZCIsIHNjaGVkX2Ny
ZWRpdF9kZWZhdWx0X3lpZWxkKTsKIAogLyoKKyAqIFNjaGVkdWxlciBnZW5lcmljIHBhcmFtZXRl
cnMKKyAqLworZXh0ZXJuIGludCBzY2hlZF9yYXRlbGltaXRfdXM7CisvKgogICogUGh5c2ljYWwg
Q1BVCiAgKi8KIHN0cnVjdCBjc2NoZWRfcGNwdSB7CkBAIC0xMjk5LDEwICsxMzAzLDE1IEBAIGNz
Y2hlZF9zY2hlZHVsZSgKICAgICBzdHJ1Y3QgY3NjaGVkX3ByaXZhdGUgKnBydiA9IENTQ0hFRF9Q
UklWKG9wcyk7CiAgICAgc3RydWN0IGNzY2hlZF92Y3B1ICpzbmV4dDsKICAgICBzdHJ1Y3QgdGFz
a19zbGljZSByZXQ7CisgICAgc190aW1lX3QgcnVudGltZSwgdHNsaWNlOworICAgIHN0cnVjdCBz
Y2hlZHVsZV9kYXRhICpzZDsKIAogICAgIENTQ0hFRF9TVEFUX0NSQU5LKHNjaGVkdWxlKTsKICAg
ICBDU0NIRURfVkNQVV9DSEVDSyhjdXJyZW50KTsKIAorICAgIHJ1bnRpbWUgPSBub3cgLSBjdXJy
ZW50LT5ydW5zdGF0ZS5zdGF0ZV9lbnRyeV90aW1lOworICAgIGlmICggcnVudGltZSA8IDAgKSAv
KiBEb2VzIHRoaXMgZXZlciBoYXBwZW4/ICovCisgICAgICAgIHJ1bnRpbWUgPSAwOwogICAgIGlm
ICggIWlzX2lkbGVfdmNwdShzY3Vyci0+dmNwdSkgKQogICAgIHsKICAgICAgICAgLyogVXBkYXRl
IGNyZWRpdHMgb2YgYSBub24taWRsZSBWQ1BVLiAqLwpAQCAtMTMxNCw3ICsxMzIzLDMzIEBAIGNz
Y2hlZF9zY2hlZHVsZSgKICAgICAgICAgLyogUmUtaW5zdGF0ZSBhIGJvb3N0ZWQgaWRsZSBWQ1BV
IGFzIG5vcm1hbC1pZGxlLiAqLwogICAgICAgICBzY3Vyci0+cHJpID0gQ1NDSEVEX1BSSV9JRExF
OwogICAgIH0KLQorICAgIC8qIElmIHdlIGhhdmUgc2NoZWR1bGUgcmF0ZSBsaW1pdGluZyBlbmFi
bGVkLCBjaGVjayB0byBzZWUKKyAgICAgKiBob3cgbG9uZyB3ZSd2ZSBydW4gZm9yLiAqLworICAK
KyAgICBpZiAoIHNjaGVkX3JhdGVsaW1pdF91cworICAgICAgICAgJiYgdmNwdV9ydW5uYWJsZShj
dXJyZW50KQorICAgICAgICAgJiYgIWlzX2lkbGVfdmNwdShjdXJyZW50KQorICAgICAgICAgJiYg
cnVudGltZSA8IE1JQ1JPU0VDUyhzY2hlZF9yYXRlbGltaXRfdXMpICkKKyAgICB7CisgICAgICAg
IHNuZXh0ID0gc2N1cnI7CisgICAgICAgIHBlcmZjX2luY3IoZGVsYXlfbXMpOworICAgICAgICAv
KiBGSVhNRTogVXNlIHBydi0+dHNsaWNlX21zIGlmIHdlJ3JlIGFsc28gdGhlIGhlYWQgb2YgaHRl
IHF1ZXVlICovCisgICAgICAgIC8vdHNsaWNlID0gTUlDUk9TRUNTKHNjaGVkX3JhdGVsaW1pdF91
cyk7CisgICAgICAgIHRzbGljZSA9IE1JTExJU0VDUyhzY2hlZF9yYXRlbGltaXRfdXMpOworCXJl
dC50aW1lID0gdHNsaWNlOworCXJldC50YXNrID0gc25leHQtPnZjcHU7CisJcmV0Lm1pZ3JhdGVk
ID0gMDsKKwlDU0NIRURfVkNQVV9DSEVDSyhyZXQudGFzayk7CisgICAgCXJldHVybiByZXQ7Cisg
ICAgfQorICAgIGVsc2UKKyAgICB7CisgICAgICAgIC8qCisgICAgICAgICAqIFNlbGVjdCBuZXh0
IHJ1bm5hYmxlIGxvY2FsIFZDUFUgKGllIHRvcCBvZiBsb2NhbCBydW5xKQorICAgICAgICAgKi8K
KyAgICAgICAgdHNsaWNlID0gTUlMTElTRUNTKENTQ0hFRF9NU0VDU19QRVJfVFNMSUNFKTsKKyAg
ICB9CisgICAgCiAgICAgLyoKICAgICAgKiBTZWxlY3QgbmV4dCBydW5uYWJsZSBsb2NhbCBWQ1BV
IChpZSB0b3Agb2YgbG9jYWwgcnVucSkKICAgICAgKi8KQEAgLTEzNzMsNyArMTQwOCw3IEBAIGNz
Y2hlZF9zY2hlZHVsZSgKICAgICAgKiBSZXR1cm4gdGFzayB0byBydW4gbmV4dC4uLgogICAgICAq
LwogICAgIHJldC50aW1lID0gKGlzX2lkbGVfdmNwdShzbmV4dC0+dmNwdSkgPwotICAgICAgICAg
ICAgICAgIC0xIDogTUlMTElTRUNTKENTQ0hFRF9NU0VDU19QRVJfVFNMSUNFKSk7CisgICAgICAg
ICAgICAgICAgLTEgOiB0c2xpY2UpOwogICAgIHJldC50YXNrID0gc25leHQtPnZjcHU7CiAKICAg
ICBDU0NIRURfVkNQVV9DSEVDSyhyZXQudGFzayk7CmRpZmYgLXIgYzYxM2Q0MzZjYTA5IHhlbi9j
b21tb24vc2NoZWR1bGUuYwotLS0gYS94ZW4vY29tbW9uL3NjaGVkdWxlLmMJVHVlIE5vdiAyMiAx
OTowMzowNCAyMDExICswMDAwCisrKyBiL3hlbi9jb21tb24vc2NoZWR1bGUuYwlUaHUgRGVjIDAx
IDE3OjE1OjEyIDIwMTEgKzAwMDAKQEAgLTQ3LDYgKzQ3LDEwIEBAIHN0cmluZ19wYXJhbSgic2No
ZWQiLCBvcHRfc2NoZWQpOwogYm9vbF90IHNjaGVkX3NtdF9wb3dlcl9zYXZpbmdzID0gMDsKIGJv
b2xlYW5fcGFyYW0oInNjaGVkX3NtdF9wb3dlcl9zYXZpbmdzIiwgc2NoZWRfc210X3Bvd2VyX3Nh
dmluZ3MpOwogCisvKiBEZWZhdWx0IHNjaGVkdWxpbmcgcmF0ZSBsaW1pdDogMW1zICovCitpbnQg
c2NoZWRfcmF0ZWxpbWl0X3VzID0gMTAwMDsKK2ludGVnZXJfcGFyYW0oInNjaGVkX3JhdGVsaW1p
dF91cyIsIHNjaGVkX3JhdGVsaW1pdF91cyk7CisKIC8qIFZhcmlvdXMgdGltZXIgaGFuZGxlcnMu
ICovCiBzdGF0aWMgdm9pZCBzX3RpbWVyX2ZuKHZvaWQgKnVudXNlZCk7CiBzdGF0aWMgdm9pZCB2
Y3B1X3BlcmlvZGljX3RpbWVyX2ZuKHZvaWQgKmRhdGEpOwpkaWZmIC1yIGM2MTNkNDM2Y2EwOSB4
ZW4vaW5jbHVkZS94ZW4vcGVyZmNfZGVmbi5oCi0tLSBhL3hlbi9pbmNsdWRlL3hlbi9wZXJmY19k
ZWZuLmgJVHVlIE5vdiAyMiAxOTowMzowNCAyMDExICswMDAwCisrKyBiL3hlbi9pbmNsdWRlL3hl
bi9wZXJmY19kZWZuLmgJVGh1IERlYyAwMSAxNzoxNToxMiAyMDExICswMDAwCkBAIC0yMCw2ICsy
MCw3IEBAIFBFUkZDT1VOVEVSKHZjcHVfY2hlY2ssICAgICAgICAgICAgICJjc2MKIFBFUkZDT1VO
VEVSKHNjaGVkdWxlLCAgICAgICAgICAgICAgICJjc2NoZWQ6IHNjaGVkdWxlIikKIFBFUkZDT1VO
VEVSKGFjY3RfcnVuLCAgICAgICAgICAgICAgICJjc2NoZWQ6IGFjY3RfcnVuIikKIFBFUkZDT1VO
VEVSKGFjY3Rfbm9fd29yaywgICAgICAgICAgICJjc2NoZWQ6IGFjY3Rfbm9fd29yayIpCitQRVJG
Q09VTlRFUihkZWxheV9tcywJCSAgICAiY3NjaGVkOiAxbXMgZGVsYXkiKQogUEVSRkNPVU5URVIo
YWNjdF9iYWxhbmNlLCAgICAgICAgICAgImNzY2hlZDogYWNjdF9iYWxhbmNlIikKIFBFUkZDT1VO
VEVSKGFjY3RfcmVvcmRlciwgICAgICAgICAgICJjc2NoZWQ6IGFjY3RfcmVvcmRlciIpCiBQRVJG
Q09VTlRFUihhY2N0X21pbl9jcmVkaXQsICAgICAgICAiY3NjaGVkOiBhY2N0X21pbl9jcmVkaXQi
KQo=
--000e0cd672025fbfeb04b30afaed
Content-Type: text/plain; charset=US-ASCII; name="02-credit-adaptive.diff"
Content-Disposition: attachment; filename="02-credit-adaptive.diff"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_gvo118qk4

ZGlmZiAtciBlMTIyNDg1ZGYzN2IgeGVuL2NvbW1vbi9zY2hlZF9jcmVkaXQuYwotLS0gYS94ZW4v
Y29tbW9uL3NjaGVkX2NyZWRpdC5jCVRodSBEZWMgMDEgMTY6NTA6MDUgMjAxMSArMDAwMAorKysg
Yi94ZW4vY29tbW9uL3NjaGVkX2NyZWRpdC5jCVRodSBEZWMgMDEgMTY6NTU6MjcgMjAxMSArMDAw
MApAQCAtMTMwNyw2ICsxMzA3LDE4IEBAIGNzY2hlZF9zY2hlZHVsZSgKICAgICBDU0NIRURfU1RB
VF9DUkFOSyhzY2hlZHVsZSk7CiAgICAgQ1NDSEVEX1ZDUFVfQ0hFQ0soY3VycmVudCk7CiAKKyAg
ICBzZCA9ICZ0aGlzX2NwdShzY2hlZHVsZV9kYXRhKTsKKyAgICBzZC0+c19jc251bSsrOworICAg
IGlmICgobm93IC0gc2QtPnNfc3JjX2IpID49IE1JTExJU0VDUyhTQ0hFRF9TUkNfSU5URVJWQUwp
KQorICAgIHsKKyAgICAgICAgaWYgKHNkLT5zX2NzbnVtID49IFNDSEVEX1NSQ19USFJFU0hPTEQp
CisgICAgICAgICAgICBzY2hlZF9yYXRlbGltaXRfdXMgPSAxMDAwOworICAgICAgICBlbHNlCisg
ICAgICAgICAgICBzY2hlZF9yYXRlbGltaXRfdXMgPSAwOworCXNkLT5zX3NyY19iID0gbm93Owor
CXNkLT5zX2NzbnVtID0gMDsKKyAgICB9CisgICAgICAgIAogICAgIHJ1bnRpbWUgPSBub3cgLSBj
dXJyZW50LT5ydW5zdGF0ZS5zdGF0ZV9lbnRyeV90aW1lOwogICAgIGlmICggcnVudGltZSA8IDAg
KSAvKiBEb2VzIHRoaXMgZXZlciBoYXBwZW4/ICovCiAgICAgICAgIHJ1bnRpbWUgPSAwOwpkaWZm
IC1yIGUxMjI0ODVkZjM3YiB4ZW4vY29tbW9uL3NjaGVkdWxlLmMKLS0tIGEveGVuL2NvbW1vbi9z
Y2hlZHVsZS5jCVRodSBEZWMgMDEgMTY6NTA6MDUgMjAxMSArMDAwMAorKysgYi94ZW4vY29tbW9u
L3NjaGVkdWxlLmMJVGh1IERlYyAwMSAxNjo1NToyNyAyMDExICswMDAwCkBAIC0xMjYxLDYgKzEy
NjEsOCBAQCBzdGF0aWMgaW50IGNwdV9zY2hlZHVsZV91cCh1bnNpZ25lZCBpbnQgCiAgICAgc2Qt
PmN1cnIgPSBpZGxlX3ZjcHVbY3B1XTsKICAgICBpbml0X3RpbWVyKCZzZC0+c190aW1lciwgc190
aW1lcl9mbiwgTlVMTCwgY3B1KTsKICAgICBhdG9taWNfc2V0KCZzZC0+dXJnZW50X2NvdW50LCAw
KTsKKyAgICBzZC0+c19jc251bT0wOworICAgIHNkLT5zX3NyY19iPTA7CiAKICAgICAvKiBCb290
IENQVSBpcyBkZWFsdCB3aXRoIGxhdGVyIGluIHNjaGVkdWxlX2luaXQoKS4gKi8KICAgICBpZiAo
IGNwdSA9PSAwICkKZGlmZiAtciBlMTIyNDg1ZGYzN2IgeGVuL2luY2x1ZGUveGVuL3NjaGVkLWlm
LmgKLS0tIGEveGVuL2luY2x1ZGUveGVuL3NjaGVkLWlmLmgJVGh1IERlYyAwMSAxNjo1MDowNSAy
MDExICswMDAwCisrKyBiL3hlbi9pbmNsdWRlL3hlbi9zY2hlZC1pZi5oCVRodSBEZWMgMDEgMTY6
NTU6MjcgMjAxMSArMDAwMApAQCAtMTUsNiArMTUsMTAgQEAgZXh0ZXJuIHN0cnVjdCBjcHVwb29s
ICpjcHVwb29sMDsKIAogLyogY3B1cyBjdXJyZW50bHkgaW4gbm8gY3B1cG9vbCAqLwogZXh0ZXJu
IGNwdW1hc2tfdCBjcHVwb29sX2ZyZWVfY3B1czsKKy8qIFRoZSBwZXJpb2QgdGhhdCBTUkMgdXBk
YXRlZCBzY2hlZHVsZXIgZnJlcXVlbmN5ICovCisjZGVmaW5lIFNDSEVEX1NSQ19JTlRFUlZBTCAg
ICAgICAxMAorLyogVGhyZXNob2xkIHRvIHRyaWdnZXIgU1JDLCAgKi8KKyNkZWZpbmUgU0NIRURf
U1JDX1RIUkVTSE9MRCAgICAgNTAKIAogLyoKICAqIEluIG9yZGVyIHRvIGFsbG93IGEgc2NoZWR1
bGVyIHRvIHJlbWFwIHRoZSBsb2NrLT5jcHUgbWFwcGluZywKQEAgLTMyLDYgKzM2LDkgQEAgc3Ry
dWN0IHNjaGVkdWxlX2RhdGEgewogICAgIHN0cnVjdCB2Y3B1ICAgICAgICAqY3VycjsgICAgICAg
ICAgIC8qIGN1cnJlbnQgdGFzayAgICAgICAgICAgICAgICAgICAgKi8KICAgICB2b2lkICAgICAg
ICAgICAgICAgKnNjaGVkX3ByaXY7CiAgICAgc3RydWN0IHRpbWVyICAgICAgICBzX3RpbWVyOyAg
ICAgICAgLyogc2NoZWR1bGluZyB0aW1lciAgICAgICAgICAgICAgICAqLworICAgIGludCAgICAg
ICAgICAgICAgICAgc19jc251bTsgICAgICAgIC8qIHNjaGVkdWxpbmcgbnVtYmVyIGJhc2VkIG9u
IGxhc3QgcGVyaW9kICovCisgICAgc190aW1lX3QgICAgICAgICAgICBzX3NyY19iOyAgICAgICAg
LyogU1JDIGNvbnRpbmcgc3RhcnQgcG9pbnQgKi8KKyAgICBib29sX3QgICAgICAgICAgICAgIHNf
c3JjX2M7ICAgICAgICAvKmluZGljYXRlIHdoZXRoZXIgc3JjIHNob3VsZCBiZSB0cmlnZ2VyZWQg
Ki8KICAgICBhdG9taWNfdCAgICAgICAgICAgIHVyZ2VudF9jb3VudDsgICAvKiBob3cgbWFueSB1
cmdlbnQgdmNwdXMgICAgICAgICAgICovCiB9OwogCg==
--000e0cd672025fbfeb04b30afaed
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--000e0cd672025fbfeb04b30afaed--


From xen-devel-bounces@lists.xensource.com Thu Dec 01 17:15:02 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 17:15:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWADZ-0006c4-TP; Thu, 01 Dec 2011 17:14:41 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1RWADY-0006bz-6C
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 17:14:40 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1322759638!316015!1
X-Originating-IP: [74.125.83.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11971 invoked from network); 1 Dec 2011 17:13:59 -0000
Received: from mail-ee0-f43.google.com (HELO mail-ee0-f43.google.com)
	(74.125.83.43)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 17:13:59 -0000
Received: by eeaq46 with SMTP id q46so2686129eea.30
	for <xen-devel@lists.xensource.com>;
	Thu, 01 Dec 2011 09:13:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=9ufX0sASMvZiWLrER/5AwBt6EHpocuUa1DKXB269Hsg=;
	b=dbxgqKoJ08qcqy1dPhCdWxq7NZjPGmVPctRVlXVj+BwYoe0srcGbCswV6d1g/5cSAO
	um+xRJhV+sshdiAp3zl2tupTlUCrRXt+ZppPXcCHRbAaf29SY2rpA9mLd0kh55SCCXij
	okWtlZ1Oj+iRC7xQDQXyKRyM5mmXUREIe6HTc=
MIME-Version: 1.0
Received: by 10.227.209.66 with SMTP id gf2mr3265078wbb.20.1322759638465; Thu,
	01 Dec 2011 09:13:58 -0800 (PST)
Received: by 10.216.187.209 with HTTP; Thu, 1 Dec 2011 09:13:58 -0800 (PST)
In-Reply-To: <C10D3FB0CD45994C8A51FEC1227CE22F37499C2733@shsmsx502.ccr.corp.intel.com>
References: <C10D3FB0CD45994C8A51FEC1227CE22F340768D793@shsmsx502.ccr.corp.intel.com>
	<CAFLBxZZ9nqeb7CVqTZCsEtJRjgGMTHF2Ak929kvauj2KUFSOyg@mail.gmail.com>
	<C10D3FB0CD45994C8A51FEC1227CE22F3428CB5EF9@shsmsx502.ccr.corp.intel.com>
	<1319789425.19320.12.camel@Abyss>
	<C10D3FB0CD45994C8A51FEC1227CE22F3428CB61F2@shsmsx502.ccr.corp.intel.com>
	<1319796584.19320.31.camel@Abyss>
	<1319818714.21033.414.camel@elijah>
	<C10D3FB0CD45994C8A51FEC1227CE22F34B3905D03@shsmsx502.ccr.corp.intel.com>
	<CAFLBxZa5v_YgnC1LTa4a5wis4h6eQPijCAfUDLDsR4ucMuBXWg@mail.gmail.com>
	<C10D3FB0CD45994C8A51FEC1227CE22F37499C2733@shsmsx502.ccr.corp.intel.com>
Date: Thu, 1 Dec 2011 17:13:58 +0000
X-Google-Sender-Auth: l8yhAcaJNNIK1rMFNaOn-LPttqE
Message-ID: <CAFLBxZZ-F2hNTNHtiBCuQ0tVqJDe6btPnvofHK4KaDDQz8Rxtw@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: "Lv, Hui" <hui.lv@intel.com>
Content-Type: multipart/mixed; boundary=000e0cd672025fbfeb04b30afaed
Cc: "Tian, Kevin" <kevin.tian@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, "Dong, Eddie" <eddie.dong@intel.com>,
	George Dunlap <george.dunlap@citrix.com>, "Duan,
	Jiangang" <jiangang.duan@intel.com>, Dario Faggioli <raistlin@linux.it>
Subject: Re: [Xen-devel] [PATCH] scheduler rate controller
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--000e0cd672025fbfeb04b30afaed
Content-Type: text/plain; charset=ISO-8859-1

On Mon, Nov 28, 2011 at 5:31 PM, Lv, Hui <hui.lv@intel.com> wrote:
> Sorry for the late. I also met issues to boot up xen according to your patch, which is same as credit_3.patch that I attached.

Thanks Hui; debugging someone else's buggy code is going beyond
expectations. :-)

> So I modified it to the credit_1.patch and credit_2.patch, both of which work well.

Standard patches for OSS development need to be -p1, not -p0; they
need to work if, in the toplevel of the directory (foo.hg) you type
"patch -p1 < bar.patch". The easiest way to make one of these patches
is to use "hg diff"; the best way (if you're using Mercurial) is to
use Mercurual queues.

> 2) credit_2 adopts the constant sched_ratelimit_us value 1000.

Looks fine overall.  One issue with the patch is that it will not only
fail to preempt for a higher-priority vcpu, it will also fail to
preempt for tasklets.  Tasklet work must be done immediately.  Perhaps
we can add "!tasklet_work_scheduled" to the list of conditions for

Why did you change "MICROSECS" to "MILLISECS" when calculating
timeslice?  In this case, it will set the timeslice to a full second!
Not what we want...

>From a software maintenance perspective, I'm not a fan of early
returns from functions.  I think it's too easy not to notice that
there's a different return path.  In this case, I think I'd prefer
adding a label, and using "goto out;" instead.

> 1) credit_1 adopts "scheduling frequency counting" to decide the value of sched_ratelimit_us, which makes it adaptive.

If you were using mercurial queues, you could put this after the last
one, and it would be easier to see the proposed "adaptive" part of the
code. :-)

Hypervisors are very complicated; it's best to keep things as
absolutely simple as possible.  This kind of mechanism is exactly the
sort of thing that makes it very hard to predict what will happen.  I
think unless you can show that it adds a significant benefit, it's
better just to use the min timeslice.

Regarding this particular code, a couple of items, just for feedback:
* All of the ratelimiting code and data structures should be in the
pluggable scheduler, not in common code.
* This code hard-codes in '1000' as the value it sets the global
variable to, overriding whatever the user may have entered on the
command-line
* Furthermore, global variable is shared by all of the cpus, however;
meaning, you may have one cpu enabling it one moment based on its own
conditions, and have nother cpu disabling it almost immediatly
afterwards, based on conditions on that cpu.  If you're testing with
this at the moment, you might as well stop -- you're going to get a
pretty random result.  If you really wanted this to be an adaptive
solution, you'd need to make a per-cpu variable with the per-cpu rate
scheduling; and then set it to the global variable (which is the user
configuration).
* Finally, this patch doesn't distinguish between schedules that
happen due to a yield, and schedules that happen due to preemption.
The only schedules we have any control over are schedules that happen
due to preemption.  If adaptivity has any value, it should pay
attention to what it can control.

I've taken your two patches, given them the proper formating, and made
them into a patch series (the first adding the ratelimiting, the
second adding the adaptive bit); they are attached.  You should be
able to easily pull them into a mercurial patchqueue using "hg qimport
/path/to/patches/*.diff".  In the future, I will not look at any
patches which do not apply using either "patch -p1" or "hg qimport."

Thanks again for all your work on this -- I hope we can get a simple,
effective solution in place soon.

 -George

--000e0cd672025fbfeb04b30afaed
Content-Type: text/plain; charset=US-ASCII; name="01-credit-ratelimit.diff"
Content-Disposition: attachment; filename="01-credit-ratelimit.diff"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_gvo117ao3

IyBIRyBjaGFuZ2VzZXQgcGF0Y2gKIyBVc2VyIEdlb3JnZSBEdW5sYXAgPGdlb3JnZS5kdW5sYXBA
ZXUuY2l0cml4LmNvbT4KIyBEYXRlIDEzMjI3NTgyMDUgMAojIE5vZGUgSUQgZTEyMjQ4NWRmMzdi
NTdmNThkYmYxM2VjODFhMTgxNjljMGE3ZTkwZgojIFBhcmVudCAgOTZiYmRjODk0MjI0ODIxZmJj
MTRhMzNlOTNiNTU2ODg5MjBjN2ZkMgppbXBvcnRlZCBwYXRjaCBjcmVkaXRfMi5wYXRjaAoKZGlm
ZiAtciBjNjEzZDQzNmNhMDkgeGVuL2NvbW1vbi9zY2hlZF9jcmVkaXQuYwotLS0gYS94ZW4vY29t
bW9uL3NjaGVkX2NyZWRpdC5jCVR1ZSBOb3YgMjIgMTk6MDM6MDQgMjAxMSArMDAwMAorKysgYi94
ZW4vY29tbW9uL3NjaGVkX2NyZWRpdC5jCVRodSBEZWMgMDEgMTc6MTU6MTIgMjAxMSArMDAwMApA
QCAtMTE1LDYgKzExNSwxMCBAQCBzdGF0aWMgYm9vbF90IF9fcmVhZF9tb3N0bHkgc2NoZWRfY3Jl
ZGl0CiBib29sZWFuX3BhcmFtKCJzY2hlZF9jcmVkaXRfZGVmYXVsdF95aWVsZCIsIHNjaGVkX2Ny
ZWRpdF9kZWZhdWx0X3lpZWxkKTsKIAogLyoKKyAqIFNjaGVkdWxlciBnZW5lcmljIHBhcmFtZXRl
cnMKKyAqLworZXh0ZXJuIGludCBzY2hlZF9yYXRlbGltaXRfdXM7CisvKgogICogUGh5c2ljYWwg
Q1BVCiAgKi8KIHN0cnVjdCBjc2NoZWRfcGNwdSB7CkBAIC0xMjk5LDEwICsxMzAzLDE1IEBAIGNz
Y2hlZF9zY2hlZHVsZSgKICAgICBzdHJ1Y3QgY3NjaGVkX3ByaXZhdGUgKnBydiA9IENTQ0hFRF9Q
UklWKG9wcyk7CiAgICAgc3RydWN0IGNzY2hlZF92Y3B1ICpzbmV4dDsKICAgICBzdHJ1Y3QgdGFz
a19zbGljZSByZXQ7CisgICAgc190aW1lX3QgcnVudGltZSwgdHNsaWNlOworICAgIHN0cnVjdCBz
Y2hlZHVsZV9kYXRhICpzZDsKIAogICAgIENTQ0hFRF9TVEFUX0NSQU5LKHNjaGVkdWxlKTsKICAg
ICBDU0NIRURfVkNQVV9DSEVDSyhjdXJyZW50KTsKIAorICAgIHJ1bnRpbWUgPSBub3cgLSBjdXJy
ZW50LT5ydW5zdGF0ZS5zdGF0ZV9lbnRyeV90aW1lOworICAgIGlmICggcnVudGltZSA8IDAgKSAv
KiBEb2VzIHRoaXMgZXZlciBoYXBwZW4/ICovCisgICAgICAgIHJ1bnRpbWUgPSAwOwogICAgIGlm
ICggIWlzX2lkbGVfdmNwdShzY3Vyci0+dmNwdSkgKQogICAgIHsKICAgICAgICAgLyogVXBkYXRl
IGNyZWRpdHMgb2YgYSBub24taWRsZSBWQ1BVLiAqLwpAQCAtMTMxNCw3ICsxMzIzLDMzIEBAIGNz
Y2hlZF9zY2hlZHVsZSgKICAgICAgICAgLyogUmUtaW5zdGF0ZSBhIGJvb3N0ZWQgaWRsZSBWQ1BV
IGFzIG5vcm1hbC1pZGxlLiAqLwogICAgICAgICBzY3Vyci0+cHJpID0gQ1NDSEVEX1BSSV9JRExF
OwogICAgIH0KLQorICAgIC8qIElmIHdlIGhhdmUgc2NoZWR1bGUgcmF0ZSBsaW1pdGluZyBlbmFi
bGVkLCBjaGVjayB0byBzZWUKKyAgICAgKiBob3cgbG9uZyB3ZSd2ZSBydW4gZm9yLiAqLworICAK
KyAgICBpZiAoIHNjaGVkX3JhdGVsaW1pdF91cworICAgICAgICAgJiYgdmNwdV9ydW5uYWJsZShj
dXJyZW50KQorICAgICAgICAgJiYgIWlzX2lkbGVfdmNwdShjdXJyZW50KQorICAgICAgICAgJiYg
cnVudGltZSA8IE1JQ1JPU0VDUyhzY2hlZF9yYXRlbGltaXRfdXMpICkKKyAgICB7CisgICAgICAg
IHNuZXh0ID0gc2N1cnI7CisgICAgICAgIHBlcmZjX2luY3IoZGVsYXlfbXMpOworICAgICAgICAv
KiBGSVhNRTogVXNlIHBydi0+dHNsaWNlX21zIGlmIHdlJ3JlIGFsc28gdGhlIGhlYWQgb2YgaHRl
IHF1ZXVlICovCisgICAgICAgIC8vdHNsaWNlID0gTUlDUk9TRUNTKHNjaGVkX3JhdGVsaW1pdF91
cyk7CisgICAgICAgIHRzbGljZSA9IE1JTExJU0VDUyhzY2hlZF9yYXRlbGltaXRfdXMpOworCXJl
dC50aW1lID0gdHNsaWNlOworCXJldC50YXNrID0gc25leHQtPnZjcHU7CisJcmV0Lm1pZ3JhdGVk
ID0gMDsKKwlDU0NIRURfVkNQVV9DSEVDSyhyZXQudGFzayk7CisgICAgCXJldHVybiByZXQ7Cisg
ICAgfQorICAgIGVsc2UKKyAgICB7CisgICAgICAgIC8qCisgICAgICAgICAqIFNlbGVjdCBuZXh0
IHJ1bm5hYmxlIGxvY2FsIFZDUFUgKGllIHRvcCBvZiBsb2NhbCBydW5xKQorICAgICAgICAgKi8K
KyAgICAgICAgdHNsaWNlID0gTUlMTElTRUNTKENTQ0hFRF9NU0VDU19QRVJfVFNMSUNFKTsKKyAg
ICB9CisgICAgCiAgICAgLyoKICAgICAgKiBTZWxlY3QgbmV4dCBydW5uYWJsZSBsb2NhbCBWQ1BV
IChpZSB0b3Agb2YgbG9jYWwgcnVucSkKICAgICAgKi8KQEAgLTEzNzMsNyArMTQwOCw3IEBAIGNz
Y2hlZF9zY2hlZHVsZSgKICAgICAgKiBSZXR1cm4gdGFzayB0byBydW4gbmV4dC4uLgogICAgICAq
LwogICAgIHJldC50aW1lID0gKGlzX2lkbGVfdmNwdShzbmV4dC0+dmNwdSkgPwotICAgICAgICAg
ICAgICAgIC0xIDogTUlMTElTRUNTKENTQ0hFRF9NU0VDU19QRVJfVFNMSUNFKSk7CisgICAgICAg
ICAgICAgICAgLTEgOiB0c2xpY2UpOwogICAgIHJldC50YXNrID0gc25leHQtPnZjcHU7CiAKICAg
ICBDU0NIRURfVkNQVV9DSEVDSyhyZXQudGFzayk7CmRpZmYgLXIgYzYxM2Q0MzZjYTA5IHhlbi9j
b21tb24vc2NoZWR1bGUuYwotLS0gYS94ZW4vY29tbW9uL3NjaGVkdWxlLmMJVHVlIE5vdiAyMiAx
OTowMzowNCAyMDExICswMDAwCisrKyBiL3hlbi9jb21tb24vc2NoZWR1bGUuYwlUaHUgRGVjIDAx
IDE3OjE1OjEyIDIwMTEgKzAwMDAKQEAgLTQ3LDYgKzQ3LDEwIEBAIHN0cmluZ19wYXJhbSgic2No
ZWQiLCBvcHRfc2NoZWQpOwogYm9vbF90IHNjaGVkX3NtdF9wb3dlcl9zYXZpbmdzID0gMDsKIGJv
b2xlYW5fcGFyYW0oInNjaGVkX3NtdF9wb3dlcl9zYXZpbmdzIiwgc2NoZWRfc210X3Bvd2VyX3Nh
dmluZ3MpOwogCisvKiBEZWZhdWx0IHNjaGVkdWxpbmcgcmF0ZSBsaW1pdDogMW1zICovCitpbnQg
c2NoZWRfcmF0ZWxpbWl0X3VzID0gMTAwMDsKK2ludGVnZXJfcGFyYW0oInNjaGVkX3JhdGVsaW1p
dF91cyIsIHNjaGVkX3JhdGVsaW1pdF91cyk7CisKIC8qIFZhcmlvdXMgdGltZXIgaGFuZGxlcnMu
ICovCiBzdGF0aWMgdm9pZCBzX3RpbWVyX2ZuKHZvaWQgKnVudXNlZCk7CiBzdGF0aWMgdm9pZCB2
Y3B1X3BlcmlvZGljX3RpbWVyX2ZuKHZvaWQgKmRhdGEpOwpkaWZmIC1yIGM2MTNkNDM2Y2EwOSB4
ZW4vaW5jbHVkZS94ZW4vcGVyZmNfZGVmbi5oCi0tLSBhL3hlbi9pbmNsdWRlL3hlbi9wZXJmY19k
ZWZuLmgJVHVlIE5vdiAyMiAxOTowMzowNCAyMDExICswMDAwCisrKyBiL3hlbi9pbmNsdWRlL3hl
bi9wZXJmY19kZWZuLmgJVGh1IERlYyAwMSAxNzoxNToxMiAyMDExICswMDAwCkBAIC0yMCw2ICsy
MCw3IEBAIFBFUkZDT1VOVEVSKHZjcHVfY2hlY2ssICAgICAgICAgICAgICJjc2MKIFBFUkZDT1VO
VEVSKHNjaGVkdWxlLCAgICAgICAgICAgICAgICJjc2NoZWQ6IHNjaGVkdWxlIikKIFBFUkZDT1VO
VEVSKGFjY3RfcnVuLCAgICAgICAgICAgICAgICJjc2NoZWQ6IGFjY3RfcnVuIikKIFBFUkZDT1VO
VEVSKGFjY3Rfbm9fd29yaywgICAgICAgICAgICJjc2NoZWQ6IGFjY3Rfbm9fd29yayIpCitQRVJG
Q09VTlRFUihkZWxheV9tcywJCSAgICAiY3NjaGVkOiAxbXMgZGVsYXkiKQogUEVSRkNPVU5URVIo
YWNjdF9iYWxhbmNlLCAgICAgICAgICAgImNzY2hlZDogYWNjdF9iYWxhbmNlIikKIFBFUkZDT1VO
VEVSKGFjY3RfcmVvcmRlciwgICAgICAgICAgICJjc2NoZWQ6IGFjY3RfcmVvcmRlciIpCiBQRVJG
Q09VTlRFUihhY2N0X21pbl9jcmVkaXQsICAgICAgICAiY3NjaGVkOiBhY2N0X21pbl9jcmVkaXQi
KQo=
--000e0cd672025fbfeb04b30afaed
Content-Type: text/plain; charset=US-ASCII; name="02-credit-adaptive.diff"
Content-Disposition: attachment; filename="02-credit-adaptive.diff"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_gvo118qk4

ZGlmZiAtciBlMTIyNDg1ZGYzN2IgeGVuL2NvbW1vbi9zY2hlZF9jcmVkaXQuYwotLS0gYS94ZW4v
Y29tbW9uL3NjaGVkX2NyZWRpdC5jCVRodSBEZWMgMDEgMTY6NTA6MDUgMjAxMSArMDAwMAorKysg
Yi94ZW4vY29tbW9uL3NjaGVkX2NyZWRpdC5jCVRodSBEZWMgMDEgMTY6NTU6MjcgMjAxMSArMDAw
MApAQCAtMTMwNyw2ICsxMzA3LDE4IEBAIGNzY2hlZF9zY2hlZHVsZSgKICAgICBDU0NIRURfU1RB
VF9DUkFOSyhzY2hlZHVsZSk7CiAgICAgQ1NDSEVEX1ZDUFVfQ0hFQ0soY3VycmVudCk7CiAKKyAg
ICBzZCA9ICZ0aGlzX2NwdShzY2hlZHVsZV9kYXRhKTsKKyAgICBzZC0+c19jc251bSsrOworICAg
IGlmICgobm93IC0gc2QtPnNfc3JjX2IpID49IE1JTExJU0VDUyhTQ0hFRF9TUkNfSU5URVJWQUwp
KQorICAgIHsKKyAgICAgICAgaWYgKHNkLT5zX2NzbnVtID49IFNDSEVEX1NSQ19USFJFU0hPTEQp
CisgICAgICAgICAgICBzY2hlZF9yYXRlbGltaXRfdXMgPSAxMDAwOworICAgICAgICBlbHNlCisg
ICAgICAgICAgICBzY2hlZF9yYXRlbGltaXRfdXMgPSAwOworCXNkLT5zX3NyY19iID0gbm93Owor
CXNkLT5zX2NzbnVtID0gMDsKKyAgICB9CisgICAgICAgIAogICAgIHJ1bnRpbWUgPSBub3cgLSBj
dXJyZW50LT5ydW5zdGF0ZS5zdGF0ZV9lbnRyeV90aW1lOwogICAgIGlmICggcnVudGltZSA8IDAg
KSAvKiBEb2VzIHRoaXMgZXZlciBoYXBwZW4/ICovCiAgICAgICAgIHJ1bnRpbWUgPSAwOwpkaWZm
IC1yIGUxMjI0ODVkZjM3YiB4ZW4vY29tbW9uL3NjaGVkdWxlLmMKLS0tIGEveGVuL2NvbW1vbi9z
Y2hlZHVsZS5jCVRodSBEZWMgMDEgMTY6NTA6MDUgMjAxMSArMDAwMAorKysgYi94ZW4vY29tbW9u
L3NjaGVkdWxlLmMJVGh1IERlYyAwMSAxNjo1NToyNyAyMDExICswMDAwCkBAIC0xMjYxLDYgKzEy
NjEsOCBAQCBzdGF0aWMgaW50IGNwdV9zY2hlZHVsZV91cCh1bnNpZ25lZCBpbnQgCiAgICAgc2Qt
PmN1cnIgPSBpZGxlX3ZjcHVbY3B1XTsKICAgICBpbml0X3RpbWVyKCZzZC0+c190aW1lciwgc190
aW1lcl9mbiwgTlVMTCwgY3B1KTsKICAgICBhdG9taWNfc2V0KCZzZC0+dXJnZW50X2NvdW50LCAw
KTsKKyAgICBzZC0+c19jc251bT0wOworICAgIHNkLT5zX3NyY19iPTA7CiAKICAgICAvKiBCb290
IENQVSBpcyBkZWFsdCB3aXRoIGxhdGVyIGluIHNjaGVkdWxlX2luaXQoKS4gKi8KICAgICBpZiAo
IGNwdSA9PSAwICkKZGlmZiAtciBlMTIyNDg1ZGYzN2IgeGVuL2luY2x1ZGUveGVuL3NjaGVkLWlm
LmgKLS0tIGEveGVuL2luY2x1ZGUveGVuL3NjaGVkLWlmLmgJVGh1IERlYyAwMSAxNjo1MDowNSAy
MDExICswMDAwCisrKyBiL3hlbi9pbmNsdWRlL3hlbi9zY2hlZC1pZi5oCVRodSBEZWMgMDEgMTY6
NTU6MjcgMjAxMSArMDAwMApAQCAtMTUsNiArMTUsMTAgQEAgZXh0ZXJuIHN0cnVjdCBjcHVwb29s
ICpjcHVwb29sMDsKIAogLyogY3B1cyBjdXJyZW50bHkgaW4gbm8gY3B1cG9vbCAqLwogZXh0ZXJu
IGNwdW1hc2tfdCBjcHVwb29sX2ZyZWVfY3B1czsKKy8qIFRoZSBwZXJpb2QgdGhhdCBTUkMgdXBk
YXRlZCBzY2hlZHVsZXIgZnJlcXVlbmN5ICovCisjZGVmaW5lIFNDSEVEX1NSQ19JTlRFUlZBTCAg
ICAgICAxMAorLyogVGhyZXNob2xkIHRvIHRyaWdnZXIgU1JDLCAgKi8KKyNkZWZpbmUgU0NIRURf
U1JDX1RIUkVTSE9MRCAgICAgNTAKIAogLyoKICAqIEluIG9yZGVyIHRvIGFsbG93IGEgc2NoZWR1
bGVyIHRvIHJlbWFwIHRoZSBsb2NrLT5jcHUgbWFwcGluZywKQEAgLTMyLDYgKzM2LDkgQEAgc3Ry
dWN0IHNjaGVkdWxlX2RhdGEgewogICAgIHN0cnVjdCB2Y3B1ICAgICAgICAqY3VycjsgICAgICAg
ICAgIC8qIGN1cnJlbnQgdGFzayAgICAgICAgICAgICAgICAgICAgKi8KICAgICB2b2lkICAgICAg
ICAgICAgICAgKnNjaGVkX3ByaXY7CiAgICAgc3RydWN0IHRpbWVyICAgICAgICBzX3RpbWVyOyAg
ICAgICAgLyogc2NoZWR1bGluZyB0aW1lciAgICAgICAgICAgICAgICAqLworICAgIGludCAgICAg
ICAgICAgICAgICAgc19jc251bTsgICAgICAgIC8qIHNjaGVkdWxpbmcgbnVtYmVyIGJhc2VkIG9u
IGxhc3QgcGVyaW9kICovCisgICAgc190aW1lX3QgICAgICAgICAgICBzX3NyY19iOyAgICAgICAg
LyogU1JDIGNvbnRpbmcgc3RhcnQgcG9pbnQgKi8KKyAgICBib29sX3QgICAgICAgICAgICAgIHNf
c3JjX2M7ICAgICAgICAvKmluZGljYXRlIHdoZXRoZXIgc3JjIHNob3VsZCBiZSB0cmlnZ2VyZWQg
Ki8KICAgICBhdG9taWNfdCAgICAgICAgICAgIHVyZ2VudF9jb3VudDsgICAvKiBob3cgbWFueSB1
cmdlbnQgdmNwdXMgICAgICAgICAgICovCiB9OwogCg==
--000e0cd672025fbfeb04b30afaed
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--000e0cd672025fbfeb04b30afaed--


From xen-devel-bounces@lists.xensource.com Thu Dec 01 17:15:25 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 17: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.xensource.com>)
	id 1RWADx-0006dK-B5; Thu, 01 Dec 2011 17:15:05 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RWADw-0006cn-1z
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 17:15:04 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1322759663!3836462!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU2Nw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31142 invoked from network); 1 Dec 2011 17:14:23 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 17:14:23 -0000
X-IronPort-AV: E=Sophos;i="4.71,279,1320624000"; 
   d="scan'208";a="9236898"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Dec 2011 17:14:22 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 1 Dec 2011 17:14:22 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RWADG-0003rH-12; Thu, 01 Dec 2011 17:14:22 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RWADF-0002sR-U1;
	Thu, 01 Dec 2011 17:14:21 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20183.46573.894123.974575@mariner.uk.xensource.com>
Date: Thu, 1 Dec 2011 17:14:21 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1322736422.31810.197.camel@zakaz.uk.xensource.com>
References: <CANrAofX3ARD8CN8HtoBnetfMZvBUS5RSC89ExuGoVSzqmE2V9A@mail.gmail.com>
	<1322736422.31810.197.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Adda Rathbone <addarathbone@googlemail.com>
Subject: Re: [Xen-devel] Compile error with Ubuntu 11.10
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("Re: [Xen-devel] Compile error with Ubuntu 11.10"):
> I expect that this needs to change to be
>     return libxl__xs_write(gc, XBT_NULL, path, "%s", libxl__strdup(gc,
>        libxl_device_model_version_to_string(dm_info->device_model_version)));
> (note the additional "%s",)
> 
> Can you try that?

Here's a patch which I think should fix this.  Adda, can you try it
please ?

libxl: Fix format string problem resulting in compile warning

Fixes:
  libxl_create.c:465: error: format not a string literal and no format 
  arguments
(The warning does not relate to security problem in this case,
because the string erroneously used as a format came from our enum
conversion and is safe.)

Also remove a redundant strdup.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

diff -r 617b56ea3291 tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Thu Dec 01 16:28:51 2011 +0000
+++ b/tools/libxl/libxl_create.c	Thu Dec 01 16:52:30 2011 +0000
@@ -461,8 +461,8 @@ static int store_libxl_entry(libxl__gc *
 
     path = libxl__xs_libxl_path(gc, domid);
     path = libxl__sprintf(gc, "%s/dm-version", path);
-    return libxl__xs_write(gc, XBT_NULL, path, libxl__strdup(gc,
-        libxl_device_model_version_to_string(dm_info->device_model_version)));
+    return libxl__xs_write(gc, XBT_NULL, path, "%s",
+        libxl_device_model_version_to_string(dm_info->device_model_version));
 }
 
 static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 17:15:25 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 17: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.xensource.com>)
	id 1RWADx-0006dK-B5; Thu, 01 Dec 2011 17:15:05 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RWADw-0006cn-1z
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 17:15:04 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1322759663!3836462!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU2Nw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31142 invoked from network); 1 Dec 2011 17:14:23 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 17:14:23 -0000
X-IronPort-AV: E=Sophos;i="4.71,279,1320624000"; 
   d="scan'208";a="9236898"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Dec 2011 17:14:22 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 1 Dec 2011 17:14:22 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RWADG-0003rH-12; Thu, 01 Dec 2011 17:14:22 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RWADF-0002sR-U1;
	Thu, 01 Dec 2011 17:14:21 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20183.46573.894123.974575@mariner.uk.xensource.com>
Date: Thu, 1 Dec 2011 17:14:21 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1322736422.31810.197.camel@zakaz.uk.xensource.com>
References: <CANrAofX3ARD8CN8HtoBnetfMZvBUS5RSC89ExuGoVSzqmE2V9A@mail.gmail.com>
	<1322736422.31810.197.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Adda Rathbone <addarathbone@googlemail.com>
Subject: Re: [Xen-devel] Compile error with Ubuntu 11.10
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("Re: [Xen-devel] Compile error with Ubuntu 11.10"):
> I expect that this needs to change to be
>     return libxl__xs_write(gc, XBT_NULL, path, "%s", libxl__strdup(gc,
>        libxl_device_model_version_to_string(dm_info->device_model_version)));
> (note the additional "%s",)
> 
> Can you try that?

Here's a patch which I think should fix this.  Adda, can you try it
please ?

libxl: Fix format string problem resulting in compile warning

Fixes:
  libxl_create.c:465: error: format not a string literal and no format 
  arguments
(The warning does not relate to security problem in this case,
because the string erroneously used as a format came from our enum
conversion and is safe.)

Also remove a redundant strdup.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

diff -r 617b56ea3291 tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Thu Dec 01 16:28:51 2011 +0000
+++ b/tools/libxl/libxl_create.c	Thu Dec 01 16:52:30 2011 +0000
@@ -461,8 +461,8 @@ static int store_libxl_entry(libxl__gc *
 
     path = libxl__xs_libxl_path(gc, domid);
     path = libxl__sprintf(gc, "%s/dm-version", path);
-    return libxl__xs_write(gc, XBT_NULL, path, libxl__strdup(gc,
-        libxl_device_model_version_to_string(dm_info->device_model_version)));
+    return libxl__xs_write(gc, XBT_NULL, path, "%s",
+        libxl_device_model_version_to_string(dm_info->device_model_version));
 }
 
 static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 17:15:40 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 17:15:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWAEG-0006fW-Uw; Thu, 01 Dec 2011 17:15:24 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1RWAEF-0006ey-Nc
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 17:15:24 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1322759681!5828878!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjc5MTU=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27925 invoked from network); 1 Dec 2011 17:14:42 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 17:14:42 -0000
X-IronPort-AV: E=Sophos;i="4.71,279,1320642000"; d="scan'208";a="172558425"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Dec 2011 12:14:40 -0500
Received: from [10.80.2.18] (10.80.2.18) by FTLPMAILMX02.citrite.net
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Thu, 1 Dec 2011
	12:14:40 -0500
Message-ID: <4ED7B5FF.2090305@citrix.com>
Date: Thu, 1 Dec 2011 17:14:39 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.23) Gecko/20110921 Lightning/1.0b2 Thunderbird/3.1.15
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <CAFA7027.25E35%keir.xen@gmail.com> <4ED62C50.7060204@citrix.com>
	<4ED666D5.5060603@citrix.com>
	<4ED7522E0200007800064973@nat28.tlf.novell.com>
	<4ED74DAD.1040903@citrix.com>
	<4ED75E8402000078000649E6@nat28.tlf.novell.com>
	<4ED77347.6060200@citrix.com>
	<4ED787870200007800064B6F@nat28.tlf.novell.com>
	<4ED79722.7090404@citrix.com>
	<4ED7A8110200007800064C50@nat28.tlf.novell.com>
In-Reply-To: <4ED7A8110200007800064C50@nat28.tlf.novell.com>
X-Enigmail-Version: 1.1.2
Content-Type: multipart/mixed; boundary="------------090400080806010905040004"
Cc: Keir Fraser <keir.xen@gmail.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [RFC] KEXEC: allocate crash note buffers at boot
	time v4
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--------------090400080806010905040004
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit

Version 4 attached.

Fixed the logic regarding locking and x{malloc,free}'ing, added a few
more comments in places, and changed the coding style to avoid
constant-first compares.

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com


--------------090400080806010905040004
Content-Type: text/x-patch; name="KEXEC-setup-crash-notes-during-boot.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename="KEXEC-setup-crash-notes-during-boot.patch"

# HG changeset patch
# Parent b5ceec1ccccad6e79053a80820132303ff1e136f
KEXEC: Allocate crash notes on boot v4

Currently, the buffers for crash notes are allocated per CPU when a
KEXEC_CMD_kexec_get_range hypercall is made, referencing the CPU in
question.

Although it certainly works in general, there are a few edge case problems:

1) There appears to be no guarentee that dom0 will make this hypercall
   for each pcpu on the system.  There appears to be variable
   behaviour depending on how many cpus dom0 is compiled for, and how
   many vcpus Xen gives to dom0.

2) The allocation of these buffers occur at the whim of dom0.  While
   this is typically very early on dom0 boot, but not guarenteed.

3) It is possible (although not sensible) for a crash
   kernel to be loaded without these (or some of these) hypercalls
   being made. Under these circumstances, a crash would cause the
   crash note code path will suffer a slew of null pointer deferences.

4) If the hypercalls are made after late in the day, it is possible
   for the hypercall to return -ENOMEM.  As code tends to be more
   fragile once memory is enhausted, the likelyhood of us needing the
   crash kernel is greater.

In addition, my forthcoming code to support 32bit kdump kernels on
64bit Xen on large (>64GB) boxes will require some guarentees as to
where the crash note buffers are actually allocated in physical
memory.  This is far easier to sort out at boot time, rather than
after dom0 has been booted and potentially using the physical memory
required.

Therefore, allocate the crash note buffers at boot time.

Changes since v3:

 *  Alter the spinlocks to avoid calling xmalloc/xfree while holding
    the lock.
 *  Tidy up the coding style used.

Changes since v2:

 *  Allocate crash_notes dynamically using nr_cpu_ids at boot time,
    rather than statically using NR_CPUS.
 *  Fix the incorrect use of signed integers for cpu id.
 *  Fix collateral damage to do_crashdump_trigger() and
    crashdump_trigger_handler caused by reordering sizeof_note() and
    setup_note()
 *  Tweak the issue about returing -ENOMEM from kexec_init_cpu_note().
    No functional change.
 *  Change kexec_get_cpu() to attempt to allocate crash note buffers
    in case we have more free memory now than when the pcpu came up.
 *  Now that there are two codepaths possibly allocating crash notes,
    protect the allocation itself with a spinlock.

Changes since v1:

 *  Use cpu hotplug notifiers to handle allocating of the notes
    buffers rather than assuming the boot state of cpus will be the
    same as the crash state.
 *  Move crash_notes from being per_cpu.  This is because the kdump
    kernel elf binary put in the crash area is hard coded to physical
    addresses which the dom0 kernel typically obtains at boot time.
    If a cpu is offlined, its buffer should not be deallocated because
    the kdump kernel would read junk when trying to get the crash
    notes.  Similarly, the same problem would occur if the cpu was
    re-onlined later and its crash notes buffer was allocated elsewhere.
 *  Only attempt to allocate buffers if a crash area has been
    specified.  Else, allocating crash note buffers is a waste of
    space.  Along with this, change the test in kexec_get_cpu to
    return -EINVAL if no buffers have been allocated.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

diff -r df7cec2c6c03 xen/common/kexec.c
--- a/xen/common/kexec.c
+++ b/xen/common/kexec.c
@@ -25,13 +25,18 @@
 #include <xen/kexec.h>
 #include <public/elfnote.h>
 #include <xsm/xsm.h>
+#include <xen/cpu.h>
 #ifdef CONFIG_COMPAT
 #include <compat/kexec.h>
 #endif
 
 bool_t kexecing = FALSE;
 
-static DEFINE_PER_CPU_READ_MOSTLY(void *, crash_notes);
+/* Memory regions to store the per cpu register state etc. on a crash. */
+static void ** crash_notes;
+
+/* Lock to prevent race conditions when allocating the crash note buffers. */
+static DEFINE_SPINLOCK(crash_notes_lock);
 
 static Elf_Note *xen_crash_note;
 
@@ -165,13 +170,17 @@ static void one_cpu_only(void)
 void kexec_crash_save_cpu(void)
 {
     int cpu = smp_processor_id();
-    Elf_Note *note = per_cpu(crash_notes, cpu);
+    Elf_Note *note;
     ELF_Prstatus *prstatus;
     crash_xen_core_t *xencore;
 
+    BUG_ON( ! crash_notes );
+
     if ( cpumask_test_and_set_cpu(cpu, &crash_saved_cpus) )
         return;
 
+    note = crash_notes[cpu];
+
     prstatus = (ELF_Prstatus *)ELFNOTE_DESC(note);
 
     note = ELFNOTE_NEXT(note);
@@ -257,13 +266,6 @@ static struct keyhandler crashdump_trigg
     .desc = "trigger a crashdump"
 };
 
-static __init int register_crashdump_trigger(void)
-{
-    register_keyhandler('C', &crashdump_trigger_keyhandler);
-    return 0;
-}
-__initcall(register_crashdump_trigger);
-
 static void setup_note(Elf_Note *n, const char *name, int type, int descsz)
 {
     int l = strlen(name) + 1;
@@ -280,6 +282,128 @@ static int sizeof_note(const char *name,
             ELFNOTE_ALIGN(descsz));
 }
 
+/* Allocate a crash note buffer for a newly onlined cpu. */
+static int kexec_init_cpu_notes(const unsigned long cpu)
+{
+    Elf_Note * note;
+    int ret = 0;
+    int nr_bytes = 0;
+
+    BUG_ON( cpu >= nr_cpu_ids || ! crash_notes );
+
+    /* If already allocated, nothing to do. */
+    if ( crash_notes[cpu] )
+        return ret;
+
+    /* All CPUs present a PRSTATUS and crash_xen_core note. */
+    nr_bytes =
+        sizeof_note("CORE", sizeof(ELF_Prstatus)) +
+        sizeof_note("Xen", sizeof(crash_xen_core_t));
+
+    /* CPU0 also presents the crash_xen_info note. */
+    if ( ! cpu )
+        nr_bytes = nr_bytes +
+            sizeof_note("Xen", sizeof(crash_xen_info_t));
+
+    note = xmalloc_bytes(nr_bytes);
+
+    /* Protect the write into crash_notes[] with a spinlock, as this function
+     * is on a hotplug path and a hypercall path. */
+    spin_lock(&crash_notes_lock);
+
+    /* If we are racing with another CPU and it has beaten us, give up
+     * gracefully. */
+    if ( crash_notes[cpu] )
+    {
+        spin_unlock(&crash_notes_lock);
+        /* Always return ok, because whether we successfully allocated or not,
+         * another CPU has successfully allocated. */
+        if ( note )
+            xfree(note);
+    }
+    else
+    {
+        crash_notes[cpu] = note;
+        spin_unlock(&crash_notes_lock);
+
+        /* If the allocation failed, and another CPU did not beat us, give
+         * up with ENOMEM. */
+        if ( ! note )
+            ret = -ENOMEM;
+        /* else all is good so lets set up the notes. */
+        else
+        {
+            /* Set up CORE note. */
+            setup_note(note, "CORE", NT_PRSTATUS, sizeof(ELF_Prstatus));
+            note = ELFNOTE_NEXT(note);
+
+            /* Set up Xen CORE note. */
+            setup_note(note, "Xen", XEN_ELFNOTE_CRASH_REGS,
+                       sizeof(crash_xen_core_t));
+
+            if ( ! cpu )
+            {
+                /* Set up Xen Crash Info note. */
+                xen_crash_note = note = ELFNOTE_NEXT(note);
+                setup_note(note, "Xen", XEN_ELFNOTE_CRASH_INFO,
+                           sizeof(crash_xen_info_t));
+            }
+        }
+    }
+
+    return ret;
+}
+
+static int cpu_callback(
+    struct notifier_block *nfb, unsigned long action, void *hcpu)
+{
+    unsigned long cpu = (unsigned long)hcpu;
+
+    /* Only hook on CPU_UP_PREPARE because once a crash_note has been reported
+     * to dom0, it must keep it around in case of a crash, as the crash kernel
+     * will be hard coded to the original physical address reported. */
+    switch ( action )
+    {
+    case CPU_UP_PREPARE:
+        /* Ignore return value.  If this boot time, -ENOMEM will cause all
+         * manner of problems elsewhere very soon, and if it is during runtime,
+         * then failing to allocate crash notes is not a good enough reason to
+         * fail the CPU_UP_PREPARE */
+        kexec_init_cpu_notes(cpu);
+        break;
+    default:
+        break;
+    }
+    return NOTIFY_DONE;
+}
+
+static struct notifier_block cpu_nfb = {
+    .notifier_call = cpu_callback
+};
+
+static int __init kexec_init(void)
+{
+    void *cpu = (void *)(unsigned long)smp_processor_id();
+
+    /* If no crash area, no need to allocate space for notes. */
+    if ( !kexec_crash_area.size )
+        return 0;
+
+    register_keyhandler('C', &crashdump_trigger_keyhandler);
+
+    crash_notes = xmalloc_array(void *, nr_cpu_ids);
+    if ( ! crash_notes )
+        return -ENOMEM;
+
+    cpu_callback(&cpu_nfb, CPU_UP_PREPARE, cpu);
+    register_cpu_notifier(&cpu_nfb);
+    return 0;
+}
+/* The reason for this to be a presmp_initcall as opposed to a regular
+ * __initcall is to allow the setup of the cpu hotplug handler before APs are
+ * brought up. */
+presmp_initcall(kexec_init);
+
 static int kexec_get_reserve(xen_kexec_range_t *range)
 {
     if ( kexec_crash_area.size > 0 && kexec_crash_area.start > 0) {
@@ -296,7 +420,14 @@ static int kexec_get_cpu(xen_kexec_range
     int nr = range->nr;
     int nr_bytes = 0;
 
-    if ( nr < 0 || nr >= nr_cpu_ids || !cpu_online(nr) )
+    if ( nr < 0 || nr >= nr_cpu_ids || !cpu_online(nr) || !crash_notes )
+        return -EINVAL;
+
+    /* Try once again to allocate room for the crash notes.  It is just possible
+     * that more space has become available since we last tried.  If space has
+     * already been allocated, kexec_init_cpu_notes() will return early with 0.
+     */
+    if ( kexec_init_cpu_notes(nr) )
         return -EINVAL;
 
     nr_bytes += sizeof_note("CORE", sizeof(ELF_Prstatus));
@@ -306,31 +437,7 @@ static int kexec_get_cpu(xen_kexec_range
     if ( nr == 0 )
         nr_bytes += sizeof_note("Xen", sizeof(crash_xen_info_t));
 
-    if ( per_cpu(crash_notes, nr) == NULL )
-    {
-        Elf_Note *note;
-
-        note = per_cpu(crash_notes, nr) = xmalloc_bytes(nr_bytes);
-
-        if ( note == NULL )
-            return -ENOMEM;
-
-        /* Setup CORE note. */
-        setup_note(note, "CORE", NT_PRSTATUS, sizeof(ELF_Prstatus));
-
-        /* Setup Xen CORE note. */
-        note = ELFNOTE_NEXT(note);
-        setup_note(note, "Xen", XEN_ELFNOTE_CRASH_REGS, sizeof(crash_xen_core_t));
-
-        if (nr == 0)
-        {
-            /* Setup system wide Xen info note. */
-            xen_crash_note = note = ELFNOTE_NEXT(note);
-            setup_note(note, "Xen", XEN_ELFNOTE_CRASH_INFO, sizeof(crash_xen_info_t));
-        }
-    }
-
-    range->start = __pa((unsigned long)per_cpu(crash_notes, nr));
+    range->start = __pa((unsigned long)crash_notes[nr]);
     range->size = nr_bytes;
     return 0;
 }

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

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

--------------090400080806010905040004--


From xen-devel-bounces@lists.xensource.com Thu Dec 01 17:15:40 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 17:15:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWAEG-0006fW-Uw; Thu, 01 Dec 2011 17:15:24 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1RWAEF-0006ey-Nc
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 17:15:24 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1322759681!5828878!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjc5MTU=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27925 invoked from network); 1 Dec 2011 17:14:42 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 17:14:42 -0000
X-IronPort-AV: E=Sophos;i="4.71,279,1320642000"; d="scan'208";a="172558425"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Dec 2011 12:14:40 -0500
Received: from [10.80.2.18] (10.80.2.18) by FTLPMAILMX02.citrite.net
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Thu, 1 Dec 2011
	12:14:40 -0500
Message-ID: <4ED7B5FF.2090305@citrix.com>
Date: Thu, 1 Dec 2011 17:14:39 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.23) Gecko/20110921 Lightning/1.0b2 Thunderbird/3.1.15
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <CAFA7027.25E35%keir.xen@gmail.com> <4ED62C50.7060204@citrix.com>
	<4ED666D5.5060603@citrix.com>
	<4ED7522E0200007800064973@nat28.tlf.novell.com>
	<4ED74DAD.1040903@citrix.com>
	<4ED75E8402000078000649E6@nat28.tlf.novell.com>
	<4ED77347.6060200@citrix.com>
	<4ED787870200007800064B6F@nat28.tlf.novell.com>
	<4ED79722.7090404@citrix.com>
	<4ED7A8110200007800064C50@nat28.tlf.novell.com>
In-Reply-To: <4ED7A8110200007800064C50@nat28.tlf.novell.com>
X-Enigmail-Version: 1.1.2
Content-Type: multipart/mixed; boundary="------------090400080806010905040004"
Cc: Keir Fraser <keir.xen@gmail.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [RFC] KEXEC: allocate crash note buffers at boot
	time v4
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--------------090400080806010905040004
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit

Version 4 attached.

Fixed the logic regarding locking and x{malloc,free}'ing, added a few
more comments in places, and changed the coding style to avoid
constant-first compares.

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com


--------------090400080806010905040004
Content-Type: text/x-patch; name="KEXEC-setup-crash-notes-during-boot.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename="KEXEC-setup-crash-notes-during-boot.patch"

# HG changeset patch
# Parent b5ceec1ccccad6e79053a80820132303ff1e136f
KEXEC: Allocate crash notes on boot v4

Currently, the buffers for crash notes are allocated per CPU when a
KEXEC_CMD_kexec_get_range hypercall is made, referencing the CPU in
question.

Although it certainly works in general, there are a few edge case problems:

1) There appears to be no guarentee that dom0 will make this hypercall
   for each pcpu on the system.  There appears to be variable
   behaviour depending on how many cpus dom0 is compiled for, and how
   many vcpus Xen gives to dom0.

2) The allocation of these buffers occur at the whim of dom0.  While
   this is typically very early on dom0 boot, but not guarenteed.

3) It is possible (although not sensible) for a crash
   kernel to be loaded without these (or some of these) hypercalls
   being made. Under these circumstances, a crash would cause the
   crash note code path will suffer a slew of null pointer deferences.

4) If the hypercalls are made after late in the day, it is possible
   for the hypercall to return -ENOMEM.  As code tends to be more
   fragile once memory is enhausted, the likelyhood of us needing the
   crash kernel is greater.

In addition, my forthcoming code to support 32bit kdump kernels on
64bit Xen on large (>64GB) boxes will require some guarentees as to
where the crash note buffers are actually allocated in physical
memory.  This is far easier to sort out at boot time, rather than
after dom0 has been booted and potentially using the physical memory
required.

Therefore, allocate the crash note buffers at boot time.

Changes since v3:

 *  Alter the spinlocks to avoid calling xmalloc/xfree while holding
    the lock.
 *  Tidy up the coding style used.

Changes since v2:

 *  Allocate crash_notes dynamically using nr_cpu_ids at boot time,
    rather than statically using NR_CPUS.
 *  Fix the incorrect use of signed integers for cpu id.
 *  Fix collateral damage to do_crashdump_trigger() and
    crashdump_trigger_handler caused by reordering sizeof_note() and
    setup_note()
 *  Tweak the issue about returing -ENOMEM from kexec_init_cpu_note().
    No functional change.
 *  Change kexec_get_cpu() to attempt to allocate crash note buffers
    in case we have more free memory now than when the pcpu came up.
 *  Now that there are two codepaths possibly allocating crash notes,
    protect the allocation itself with a spinlock.

Changes since v1:

 *  Use cpu hotplug notifiers to handle allocating of the notes
    buffers rather than assuming the boot state of cpus will be the
    same as the crash state.
 *  Move crash_notes from being per_cpu.  This is because the kdump
    kernel elf binary put in the crash area is hard coded to physical
    addresses which the dom0 kernel typically obtains at boot time.
    If a cpu is offlined, its buffer should not be deallocated because
    the kdump kernel would read junk when trying to get the crash
    notes.  Similarly, the same problem would occur if the cpu was
    re-onlined later and its crash notes buffer was allocated elsewhere.
 *  Only attempt to allocate buffers if a crash area has been
    specified.  Else, allocating crash note buffers is a waste of
    space.  Along with this, change the test in kexec_get_cpu to
    return -EINVAL if no buffers have been allocated.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

diff -r df7cec2c6c03 xen/common/kexec.c
--- a/xen/common/kexec.c
+++ b/xen/common/kexec.c
@@ -25,13 +25,18 @@
 #include <xen/kexec.h>
 #include <public/elfnote.h>
 #include <xsm/xsm.h>
+#include <xen/cpu.h>
 #ifdef CONFIG_COMPAT
 #include <compat/kexec.h>
 #endif
 
 bool_t kexecing = FALSE;
 
-static DEFINE_PER_CPU_READ_MOSTLY(void *, crash_notes);
+/* Memory regions to store the per cpu register state etc. on a crash. */
+static void ** crash_notes;
+
+/* Lock to prevent race conditions when allocating the crash note buffers. */
+static DEFINE_SPINLOCK(crash_notes_lock);
 
 static Elf_Note *xen_crash_note;
 
@@ -165,13 +170,17 @@ static void one_cpu_only(void)
 void kexec_crash_save_cpu(void)
 {
     int cpu = smp_processor_id();
-    Elf_Note *note = per_cpu(crash_notes, cpu);
+    Elf_Note *note;
     ELF_Prstatus *prstatus;
     crash_xen_core_t *xencore;
 
+    BUG_ON( ! crash_notes );
+
     if ( cpumask_test_and_set_cpu(cpu, &crash_saved_cpus) )
         return;
 
+    note = crash_notes[cpu];
+
     prstatus = (ELF_Prstatus *)ELFNOTE_DESC(note);
 
     note = ELFNOTE_NEXT(note);
@@ -257,13 +266,6 @@ static struct keyhandler crashdump_trigg
     .desc = "trigger a crashdump"
 };
 
-static __init int register_crashdump_trigger(void)
-{
-    register_keyhandler('C', &crashdump_trigger_keyhandler);
-    return 0;
-}
-__initcall(register_crashdump_trigger);
-
 static void setup_note(Elf_Note *n, const char *name, int type, int descsz)
 {
     int l = strlen(name) + 1;
@@ -280,6 +282,128 @@ static int sizeof_note(const char *name,
             ELFNOTE_ALIGN(descsz));
 }
 
+/* Allocate a crash note buffer for a newly onlined cpu. */
+static int kexec_init_cpu_notes(const unsigned long cpu)
+{
+    Elf_Note * note;
+    int ret = 0;
+    int nr_bytes = 0;
+
+    BUG_ON( cpu >= nr_cpu_ids || ! crash_notes );
+
+    /* If already allocated, nothing to do. */
+    if ( crash_notes[cpu] )
+        return ret;
+
+    /* All CPUs present a PRSTATUS and crash_xen_core note. */
+    nr_bytes =
+        sizeof_note("CORE", sizeof(ELF_Prstatus)) +
+        sizeof_note("Xen", sizeof(crash_xen_core_t));
+
+    /* CPU0 also presents the crash_xen_info note. */
+    if ( ! cpu )
+        nr_bytes = nr_bytes +
+            sizeof_note("Xen", sizeof(crash_xen_info_t));
+
+    note = xmalloc_bytes(nr_bytes);
+
+    /* Protect the write into crash_notes[] with a spinlock, as this function
+     * is on a hotplug path and a hypercall path. */
+    spin_lock(&crash_notes_lock);
+
+    /* If we are racing with another CPU and it has beaten us, give up
+     * gracefully. */
+    if ( crash_notes[cpu] )
+    {
+        spin_unlock(&crash_notes_lock);
+        /* Always return ok, because whether we successfully allocated or not,
+         * another CPU has successfully allocated. */
+        if ( note )
+            xfree(note);
+    }
+    else
+    {
+        crash_notes[cpu] = note;
+        spin_unlock(&crash_notes_lock);
+
+        /* If the allocation failed, and another CPU did not beat us, give
+         * up with ENOMEM. */
+        if ( ! note )
+            ret = -ENOMEM;
+        /* else all is good so lets set up the notes. */
+        else
+        {
+            /* Set up CORE note. */
+            setup_note(note, "CORE", NT_PRSTATUS, sizeof(ELF_Prstatus));
+            note = ELFNOTE_NEXT(note);
+
+            /* Set up Xen CORE note. */
+            setup_note(note, "Xen", XEN_ELFNOTE_CRASH_REGS,
+                       sizeof(crash_xen_core_t));
+
+            if ( ! cpu )
+            {
+                /* Set up Xen Crash Info note. */
+                xen_crash_note = note = ELFNOTE_NEXT(note);
+                setup_note(note, "Xen", XEN_ELFNOTE_CRASH_INFO,
+                           sizeof(crash_xen_info_t));
+            }
+        }
+    }
+
+    return ret;
+}
+
+static int cpu_callback(
+    struct notifier_block *nfb, unsigned long action, void *hcpu)
+{
+    unsigned long cpu = (unsigned long)hcpu;
+
+    /* Only hook on CPU_UP_PREPARE because once a crash_note has been reported
+     * to dom0, it must keep it around in case of a crash, as the crash kernel
+     * will be hard coded to the original physical address reported. */
+    switch ( action )
+    {
+    case CPU_UP_PREPARE:
+        /* Ignore return value.  If this boot time, -ENOMEM will cause all
+         * manner of problems elsewhere very soon, and if it is during runtime,
+         * then failing to allocate crash notes is not a good enough reason to
+         * fail the CPU_UP_PREPARE */
+        kexec_init_cpu_notes(cpu);
+        break;
+    default:
+        break;
+    }
+    return NOTIFY_DONE;
+}
+
+static struct notifier_block cpu_nfb = {
+    .notifier_call = cpu_callback
+};
+
+static int __init kexec_init(void)
+{
+    void *cpu = (void *)(unsigned long)smp_processor_id();
+
+    /* If no crash area, no need to allocate space for notes. */
+    if ( !kexec_crash_area.size )
+        return 0;
+
+    register_keyhandler('C', &crashdump_trigger_keyhandler);
+
+    crash_notes = xmalloc_array(void *, nr_cpu_ids);
+    if ( ! crash_notes )
+        return -ENOMEM;
+
+    cpu_callback(&cpu_nfb, CPU_UP_PREPARE, cpu);
+    register_cpu_notifier(&cpu_nfb);
+    return 0;
+}
+/* The reason for this to be a presmp_initcall as opposed to a regular
+ * __initcall is to allow the setup of the cpu hotplug handler before APs are
+ * brought up. */
+presmp_initcall(kexec_init);
+
 static int kexec_get_reserve(xen_kexec_range_t *range)
 {
     if ( kexec_crash_area.size > 0 && kexec_crash_area.start > 0) {
@@ -296,7 +420,14 @@ static int kexec_get_cpu(xen_kexec_range
     int nr = range->nr;
     int nr_bytes = 0;
 
-    if ( nr < 0 || nr >= nr_cpu_ids || !cpu_online(nr) )
+    if ( nr < 0 || nr >= nr_cpu_ids || !cpu_online(nr) || !crash_notes )
+        return -EINVAL;
+
+    /* Try once again to allocate room for the crash notes.  It is just possible
+     * that more space has become available since we last tried.  If space has
+     * already been allocated, kexec_init_cpu_notes() will return early with 0.
+     */
+    if ( kexec_init_cpu_notes(nr) )
         return -EINVAL;
 
     nr_bytes += sizeof_note("CORE", sizeof(ELF_Prstatus));
@@ -306,31 +437,7 @@ static int kexec_get_cpu(xen_kexec_range
     if ( nr == 0 )
         nr_bytes += sizeof_note("Xen", sizeof(crash_xen_info_t));
 
-    if ( per_cpu(crash_notes, nr) == NULL )
-    {
-        Elf_Note *note;
-
-        note = per_cpu(crash_notes, nr) = xmalloc_bytes(nr_bytes);
-
-        if ( note == NULL )
-            return -ENOMEM;
-
-        /* Setup CORE note. */
-        setup_note(note, "CORE", NT_PRSTATUS, sizeof(ELF_Prstatus));
-
-        /* Setup Xen CORE note. */
-        note = ELFNOTE_NEXT(note);
-        setup_note(note, "Xen", XEN_ELFNOTE_CRASH_REGS, sizeof(crash_xen_core_t));
-
-        if (nr == 0)
-        {
-            /* Setup system wide Xen info note. */
-            xen_crash_note = note = ELFNOTE_NEXT(note);
-            setup_note(note, "Xen", XEN_ELFNOTE_CRASH_INFO, sizeof(crash_xen_info_t));
-        }
-    }
-
-    range->start = __pa((unsigned long)per_cpu(crash_notes, nr));
+    range->start = __pa((unsigned long)crash_notes[nr]);
     range->size = nr_bytes;
     return 0;
 }

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

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

--------------090400080806010905040004--


From xen-devel-bounces@lists.xensource.com Thu Dec 01 17:17:16 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 17:17:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWAFj-0006q0-Et; Thu, 01 Dec 2011 17:16:55 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RWAFi-0006pG-Ch
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 17:16:54 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1322759774!5526358!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU2Nw==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2180 invoked from network); 1 Dec 2011 17:16:14 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 17:16:14 -0000
X-IronPort-AV: E=Sophos;i="4.71,279,1320624000"; 
   d="scan'208";a="9236951"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Dec 2011 17:16:14 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.161]) by
	LONPMAILMX01.citrite.net ([10.30.203.162]) with mapi; Thu, 1 Dec 2011
	17:16:14 +0000
From: Paul Durrant <Paul.Durrant@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>, Konrad Rzeszutek Wilk
	<konrad@darnok.org>
Date: Thu, 1 Dec 2011 17:16:20 +0000
Thread-Topic: [Xen-devel] [PATCH] Add code to track the address of the VM
	generation id buffer across a [and 1 more messages]
Thread-Index: AcywSBpucP50lUNvSdCG+GIuDYtuhAABG2SQ
Message-ID: <291EDFCB1E9E224A99088639C4762022B5988E514F@LONPMAILBOX01.citrite.net>
References: <94a17182f386c8bb414e.1322686717@cosworth.uk.xensource.com>
	<20111130221419.GA16651@andromeda.dapyr.net>
	<291EDFCB1E9E224A99088639C4762022B5988E50D4@LONPMAILBOX01.citrite.net>
	<20183.44612.524027.670338@mariner.uk.xensource.com>
In-Reply-To: <20183.44612.524027.670338@mariner.uk.xensource.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] Add code to track the address of the
	VM	generation id buffer across a [and 1 more messages]
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> -----Original Message-----
> From: Ian Jackson [mailto:Ian.Jackson@eu.citrix.com]
> Sent: 01 December 2011 16:42
> To: Paul Durrant; Konrad Rzeszutek Wilk
> Cc: xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] [PATCH] Add code to track the address of
> the VM generation id buffer across a [and 1 more messages]
> 
> Konrad Rzeszutek Wilk writes ("Re: [Xen-devel] [PATCH] Add code to
> track the address of the VM generation id buffer across a"):
> > So what is a generation id? What is the use-case for this?
> 
> Paul Durrant writes ("Re: [Xen-devel] [PATCH] Add code to track the
> address of the VM generation id buffer across a"):
> >   Did you see my previous patch set? The introductory comment was:
> >
> > -----
> > The following is a revised patch series to add support for a VM
> generation ID virtual device for HVM guests.
> > The basic requirements of this device are as follows:
> 
> This explains "what" but not "why".
> 

OK. I already know there is one OS that consumes this interface and another hypervisor that produces it but unfortunately I'm not at liberty to say much more because I'm under NDA.
Hopefully a spec. will be forthcoming at some point.

> Also, please don't top post.
> 

Sorry, I wasn't aware that I was.

  Paul

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 17:17:16 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 17:17:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWAFj-0006q0-Et; Thu, 01 Dec 2011 17:16:55 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RWAFi-0006pG-Ch
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 17:16:54 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1322759774!5526358!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU2Nw==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2180 invoked from network); 1 Dec 2011 17:16:14 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 17:16:14 -0000
X-IronPort-AV: E=Sophos;i="4.71,279,1320624000"; 
   d="scan'208";a="9236951"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Dec 2011 17:16:14 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.161]) by
	LONPMAILMX01.citrite.net ([10.30.203.162]) with mapi; Thu, 1 Dec 2011
	17:16:14 +0000
From: Paul Durrant <Paul.Durrant@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>, Konrad Rzeszutek Wilk
	<konrad@darnok.org>
Date: Thu, 1 Dec 2011 17:16:20 +0000
Thread-Topic: [Xen-devel] [PATCH] Add code to track the address of the VM
	generation id buffer across a [and 1 more messages]
Thread-Index: AcywSBpucP50lUNvSdCG+GIuDYtuhAABG2SQ
Message-ID: <291EDFCB1E9E224A99088639C4762022B5988E514F@LONPMAILBOX01.citrite.net>
References: <94a17182f386c8bb414e.1322686717@cosworth.uk.xensource.com>
	<20111130221419.GA16651@andromeda.dapyr.net>
	<291EDFCB1E9E224A99088639C4762022B5988E50D4@LONPMAILBOX01.citrite.net>
	<20183.44612.524027.670338@mariner.uk.xensource.com>
In-Reply-To: <20183.44612.524027.670338@mariner.uk.xensource.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] Add code to track the address of the
	VM	generation id buffer across a [and 1 more messages]
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> -----Original Message-----
> From: Ian Jackson [mailto:Ian.Jackson@eu.citrix.com]
> Sent: 01 December 2011 16:42
> To: Paul Durrant; Konrad Rzeszutek Wilk
> Cc: xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] [PATCH] Add code to track the address of
> the VM generation id buffer across a [and 1 more messages]
> 
> Konrad Rzeszutek Wilk writes ("Re: [Xen-devel] [PATCH] Add code to
> track the address of the VM generation id buffer across a"):
> > So what is a generation id? What is the use-case for this?
> 
> Paul Durrant writes ("Re: [Xen-devel] [PATCH] Add code to track the
> address of the VM generation id buffer across a"):
> >   Did you see my previous patch set? The introductory comment was:
> >
> > -----
> > The following is a revised patch series to add support for a VM
> generation ID virtual device for HVM guests.
> > The basic requirements of this device are as follows:
> 
> This explains "what" but not "why".
> 

OK. I already know there is one OS that consumes this interface and another hypervisor that produces it but unfortunately I'm not at liberty to say much more because I'm under NDA.
Hopefully a spec. will be forthcoming at some point.

> Also, please don't top post.
> 

Sorry, I wasn't aware that I was.

  Paul

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 17:22:46 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 17:22:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWALA-0007EL-7q; Thu, 01 Dec 2011 17:22:32 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RWAL8-0007Dj-Gf
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 17:22:30 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-2.tower-216.messagelabs.com!1322760109!7151351!1
X-Originating-IP: [208.97.132.202]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4yMDIgPT4gMTYwMTY=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1501 invoked from network); 1 Dec 2011 17:21:50 -0000
Received: from caiajhbdccac.dreamhost.com (HELO homiemail-a75.g.dreamhost.com)
	(208.97.132.202) by server-2.tower-216.messagelabs.com with SMTP;
	1 Dec 2011 17:21:50 -0000
Received: from homiemail-a75.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a75.g.dreamhost.com (Postfix) with ESMTP id 23EEB5EC081;
	Thu,  1 Dec 2011 09:21:49 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id:date
	:from:to:cc; q=dns; s=lagarcavilla.org; b=TqpByiP9H/YD4evjmHFhSN
	EV5E5hZrmo3YIeY94XKQJnMXuhW09e1UgIrbqOYmyDXGs5nvMR0VFI3dGE0Fj0bx
	cw3A520beEsevNqSYcfavJgKmbqFymTA+0rWgDxeabdgI6cd7hXfWrV+0vkeVgnL
	25367xdYmmEcdH4pA8rjU=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:date:from:to:cc; s=lagarcavilla.org; bh=BAuMkTpufDHx
	RDy2yjQsTE3BqS4=; b=SomXRiD6V3InAnQBddz33PFbXHysWQTjwZAxkVHZ7G7f
	qS/KSbKIaPAqFiajAYT3rfjEK2SOaqZFftY4vydYKiHsV2I+Fk8Y3r2MeD/s5uEK
	UmxDI55CIkL/PrvfjrOvqao8WhpFySNY1khwc6s1vjObBneMEoi6UjayOdaCsh4=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a75.g.dreamhost.com (Postfix) with ESMTPSA id 74B885EC07C; 
	Thu,  1 Dec 2011 09:21:48 -0800 (PST)
MIME-Version: 1.0
Message-Id: <patchbomb.1322760071@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Thu, 01 Dec 2011 12:21:11 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com, andres@gridcentric.ca, tim@xen.org, olaf@aepfle.de,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 0 of 3] Resend: correctness race when paging-in
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

P2m_mem_paging_prep ensures that an mfn is backing the paged-out gfn, and
transitions to the next state in the paging state machine for this page. 
Foreign mappings of the gfn will now succeed. This is the key idea, as it 
allows the pager to now map the gfn and fill in its contents.

Unfortunately, it also allows any other foreign mapper to map the gfn and read
its contents. This is particularly dangerous when the populate is launched
by a foreign mapper in the first place, which will be actively retrying the
map operation and might race with the pager. Qemu-dm being a prime example.

Fix the race by allowing a buffer to be optionally passed in the prep
operation, and having the hypervisor memcpy from that buffer into the newly
prepped page before promoting the gfn type.

Second patch is a tools patch.

Resent after feedback: xenpaging patch attached, simplified with use of 
copy_from_guest. Left potntial short-cut to avoid pging_resume for further 
discussion.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
 xen/arch/x86/mm/mem_event.c  |   2 +-
 xen/arch/x86/mm/mem_paging.c |   2 +-
 xen/arch/x86/mm/p2m.c        |  32 ++++++++++++++++++++++++++++++--
 xen/include/asm-x86/p2m.h    |   2 +-
 xen/include/public/domctl.h  |   8 ++++++--
 tools/libxc/xc_mem_event.c   |   4 ++--
 tools/libxc/xc_mem_paging.c  |  23 +++++++++++++++++++++++
 tools/libxc/xenctrl.h        |   2 ++
 tools/xenpaging/xenpaging.c  |  43 +++++++++++++++++++++----------------------
 9 files changed, 87 insertions(+), 31 deletions(-)

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 17:22:46 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 17:22:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWALA-0007EL-7q; Thu, 01 Dec 2011 17:22:32 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RWAL8-0007Dj-Gf
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 17:22:30 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-2.tower-216.messagelabs.com!1322760109!7151351!1
X-Originating-IP: [208.97.132.202]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4yMDIgPT4gMTYwMTY=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1501 invoked from network); 1 Dec 2011 17:21:50 -0000
Received: from caiajhbdccac.dreamhost.com (HELO homiemail-a75.g.dreamhost.com)
	(208.97.132.202) by server-2.tower-216.messagelabs.com with SMTP;
	1 Dec 2011 17:21:50 -0000
Received: from homiemail-a75.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a75.g.dreamhost.com (Postfix) with ESMTP id 23EEB5EC081;
	Thu,  1 Dec 2011 09:21:49 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id:date
	:from:to:cc; q=dns; s=lagarcavilla.org; b=TqpByiP9H/YD4evjmHFhSN
	EV5E5hZrmo3YIeY94XKQJnMXuhW09e1UgIrbqOYmyDXGs5nvMR0VFI3dGE0Fj0bx
	cw3A520beEsevNqSYcfavJgKmbqFymTA+0rWgDxeabdgI6cd7hXfWrV+0vkeVgnL
	25367xdYmmEcdH4pA8rjU=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:date:from:to:cc; s=lagarcavilla.org; bh=BAuMkTpufDHx
	RDy2yjQsTE3BqS4=; b=SomXRiD6V3InAnQBddz33PFbXHysWQTjwZAxkVHZ7G7f
	qS/KSbKIaPAqFiajAYT3rfjEK2SOaqZFftY4vydYKiHsV2I+Fk8Y3r2MeD/s5uEK
	UmxDI55CIkL/PrvfjrOvqao8WhpFySNY1khwc6s1vjObBneMEoi6UjayOdaCsh4=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a75.g.dreamhost.com (Postfix) with ESMTPSA id 74B885EC07C; 
	Thu,  1 Dec 2011 09:21:48 -0800 (PST)
MIME-Version: 1.0
Message-Id: <patchbomb.1322760071@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Thu, 01 Dec 2011 12:21:11 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com, andres@gridcentric.ca, tim@xen.org, olaf@aepfle.de,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 0 of 3] Resend: correctness race when paging-in
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

P2m_mem_paging_prep ensures that an mfn is backing the paged-out gfn, and
transitions to the next state in the paging state machine for this page. 
Foreign mappings of the gfn will now succeed. This is the key idea, as it 
allows the pager to now map the gfn and fill in its contents.

Unfortunately, it also allows any other foreign mapper to map the gfn and read
its contents. This is particularly dangerous when the populate is launched
by a foreign mapper in the first place, which will be actively retrying the
map operation and might race with the pager. Qemu-dm being a prime example.

Fix the race by allowing a buffer to be optionally passed in the prep
operation, and having the hypervisor memcpy from that buffer into the newly
prepped page before promoting the gfn type.

Second patch is a tools patch.

Resent after feedback: xenpaging patch attached, simplified with use of 
copy_from_guest. Left potntial short-cut to avoid pging_resume for further 
discussion.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
 xen/arch/x86/mm/mem_event.c  |   2 +-
 xen/arch/x86/mm/mem_paging.c |   2 +-
 xen/arch/x86/mm/p2m.c        |  32 ++++++++++++++++++++++++++++++--
 xen/include/asm-x86/p2m.h    |   2 +-
 xen/include/public/domctl.h  |   8 ++++++--
 tools/libxc/xc_mem_event.c   |   4 ++--
 tools/libxc/xc_mem_paging.c  |  23 +++++++++++++++++++++++
 tools/libxc/xenctrl.h        |   2 ++
 tools/xenpaging/xenpaging.c  |  43 +++++++++++++++++++++----------------------
 9 files changed, 87 insertions(+), 31 deletions(-)

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 17:22:48 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 17:22:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWALC-0007Ex-7C; Thu, 01 Dec 2011 17:22:34 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RWALB-0007Dv-0v
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 17:22:33 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-14.tower-21.messagelabs.com!1322760112!6599652!1
X-Originating-IP: [208.97.132.119]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xMTkgPT4gMTU4ODc=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32172 invoked from network); 1 Dec 2011 17:21:52 -0000
Received: from caiajhbdcbbj.dreamhost.com (HELO homiemail-a75.g.dreamhost.com)
	(208.97.132.119) by server-14.tower-21.messagelabs.com with SMTP;
	1 Dec 2011 17:21:52 -0000
Received: from homiemail-a75.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a75.g.dreamhost.com (Postfix) with ESMTP id CB96D5EC07E;
	Thu,  1 Dec 2011 09:21:51 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=XA1gBiz1Fb76Y8W9RmDQM9eDVZSYI9bBfG+cjb1KXb2O
	kIzsWwAbLBqn+jKcCYAd8YwVCS/gCZMWvkOYtMEViWijChl0zST3BHVvxQxA+XOa
	M7MbONTLcK4UpgbvudAzNtQgIIcTQrIfcvBbbzJ8xpYKON7xnLNC9ssG7LD1V5c=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=q9QZ1QwBDlIShJcFBAhf5wtnwhs=; b=dhrgWNQFxCo
	yyEMOQjHDq0F8NbYwIMQisxxwgw7d4YiAtPZ9QNfNk8BM8Ap8jwC831vuoAMrMnK
	O7/5AGU79U3sVivizQo2r9tug1YS4vO7MlKV86GnelWmoN9v2+jxEaDW5SC8H6j1
	oki5Sfh7qIXHgftQY7jGpDHFoBTAEJ3E=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a75.g.dreamhost.com (Postfix) with ESMTPSA id 385F25EC080; 
	Thu,  1 Dec 2011 09:21:51 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 90ded86b0a30c34e16445c8745bac1b7bc738993
Message-Id: <90ded86b0a30c34e1644.1322760074@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1322760071@xdev.gridcentric.ca>
References: <patchbomb.1322760071@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Thu, 01 Dec 2011 12:21:14 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com, andres@gridcentric.ca, tim@xen.org, olaf@aepfle.de,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 3 of 3] Teach xenpaging to use the new and
 non-racy xc_mem_paging_load
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 tools/xenpaging/xenpaging.c |  43 +++++++++++++++++++++----------------------
 1 files changed, 21 insertions(+), 22 deletions(-)


interface.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r e71f880c0518 -r 90ded86b0a30 tools/xenpaging/xenpaging.c
--- a/tools/xenpaging/xenpaging.c
+++ b/tools/xenpaging/xenpaging.c
@@ -45,6 +45,7 @@ static char *dom_path;
 static char watch_token[16];
 static char *filename;
 static int interrupted;
+static void *paging_buffer = NULL;
 
 static void unlink_pagefile(void)
 {
@@ -438,6 +439,13 @@ static xenpaging_t *xenpaging_init(int a
         goto err;
     }
 
+    paging_buffer = init_page();
+    if ( !paging_buffer )
+    {
+        ERROR("Creating page aligned load buffer");
+        goto err;
+    }
+
     return paging;
 
  err:
@@ -649,10 +657,20 @@ static int xenpaging_populate_page(xenpa
     unsigned char oom = 0;
 
     DPRINTF("populate_page < gfn %"PRI_xen_pfn" pageslot %d\n", gfn, i);
+
+    /* Read page */
+    ret = read_page(fd, paging_buffer, i);
+    if ( ret != 0 )
+    {
+        ERROR("Error reading page");
+        goto out;
+    }
+
     do
     {
         /* Tell Xen to allocate a page for the domain */
-        ret = xc_mem_paging_prep(xch, paging->mem_event.domain_id, gfn);
+        ret = xc_mem_paging_load(xch, paging->mem_event.domain_id, gfn,
+                                    paging_buffer);
         if ( ret != 0 )
         {
             if ( errno == ENOMEM )
@@ -662,33 +680,14 @@ static int xenpaging_populate_page(xenpa
                 sleep(1);
                 continue;
             }
-            PERROR("Error preparing %"PRI_xen_pfn" for page-in", gfn);
-            goto out_map;
+            PERROR("Error loading %"PRI_xen_pfn" during page-in", gfn);
+            goto out;
         }
     }
     while ( ret && !interrupted );
 
-    /* Map page */
-    ret = -EFAULT;
-    page = xc_map_foreign_pages(xch, paging->mem_event.domain_id,
-                                PROT_READ | PROT_WRITE, &gfn, 1);
-    if ( page == NULL )
-    {
-        PERROR("Error mapping page %"PRI_xen_pfn": page is null", gfn);
-        goto out_map;
-    }
-
-    /* Read page */
-    ret = read_page(fd, page, i);
-    if ( ret != 0 )
-    {
-        PERROR("Error reading page %"PRI_xen_pfn"", gfn);
-        goto out;
-    }
 
  out:
-    munmap(page, PAGE_SIZE);
- out_map:
     return ret;
 }
 

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 17:22:48 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 17:22:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWALC-0007Ex-7C; Thu, 01 Dec 2011 17:22:34 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RWALB-0007Dv-0v
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 17:22:33 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-14.tower-21.messagelabs.com!1322760112!6599652!1
X-Originating-IP: [208.97.132.119]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xMTkgPT4gMTU4ODc=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32172 invoked from network); 1 Dec 2011 17:21:52 -0000
Received: from caiajhbdcbbj.dreamhost.com (HELO homiemail-a75.g.dreamhost.com)
	(208.97.132.119) by server-14.tower-21.messagelabs.com with SMTP;
	1 Dec 2011 17:21:52 -0000
Received: from homiemail-a75.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a75.g.dreamhost.com (Postfix) with ESMTP id CB96D5EC07E;
	Thu,  1 Dec 2011 09:21:51 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=XA1gBiz1Fb76Y8W9RmDQM9eDVZSYI9bBfG+cjb1KXb2O
	kIzsWwAbLBqn+jKcCYAd8YwVCS/gCZMWvkOYtMEViWijChl0zST3BHVvxQxA+XOa
	M7MbONTLcK4UpgbvudAzNtQgIIcTQrIfcvBbbzJ8xpYKON7xnLNC9ssG7LD1V5c=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=q9QZ1QwBDlIShJcFBAhf5wtnwhs=; b=dhrgWNQFxCo
	yyEMOQjHDq0F8NbYwIMQisxxwgw7d4YiAtPZ9QNfNk8BM8Ap8jwC831vuoAMrMnK
	O7/5AGU79U3sVivizQo2r9tug1YS4vO7MlKV86GnelWmoN9v2+jxEaDW5SC8H6j1
	oki5Sfh7qIXHgftQY7jGpDHFoBTAEJ3E=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a75.g.dreamhost.com (Postfix) with ESMTPSA id 385F25EC080; 
	Thu,  1 Dec 2011 09:21:51 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 90ded86b0a30c34e16445c8745bac1b7bc738993
Message-Id: <90ded86b0a30c34e1644.1322760074@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1322760071@xdev.gridcentric.ca>
References: <patchbomb.1322760071@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Thu, 01 Dec 2011 12:21:14 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com, andres@gridcentric.ca, tim@xen.org, olaf@aepfle.de,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 3 of 3] Teach xenpaging to use the new and
 non-racy xc_mem_paging_load
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 tools/xenpaging/xenpaging.c |  43 +++++++++++++++++++++----------------------
 1 files changed, 21 insertions(+), 22 deletions(-)


interface.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r e71f880c0518 -r 90ded86b0a30 tools/xenpaging/xenpaging.c
--- a/tools/xenpaging/xenpaging.c
+++ b/tools/xenpaging/xenpaging.c
@@ -45,6 +45,7 @@ static char *dom_path;
 static char watch_token[16];
 static char *filename;
 static int interrupted;
+static void *paging_buffer = NULL;
 
 static void unlink_pagefile(void)
 {
@@ -438,6 +439,13 @@ static xenpaging_t *xenpaging_init(int a
         goto err;
     }
 
+    paging_buffer = init_page();
+    if ( !paging_buffer )
+    {
+        ERROR("Creating page aligned load buffer");
+        goto err;
+    }
+
     return paging;
 
  err:
@@ -649,10 +657,20 @@ static int xenpaging_populate_page(xenpa
     unsigned char oom = 0;
 
     DPRINTF("populate_page < gfn %"PRI_xen_pfn" pageslot %d\n", gfn, i);
+
+    /* Read page */
+    ret = read_page(fd, paging_buffer, i);
+    if ( ret != 0 )
+    {
+        ERROR("Error reading page");
+        goto out;
+    }
+
     do
     {
         /* Tell Xen to allocate a page for the domain */
-        ret = xc_mem_paging_prep(xch, paging->mem_event.domain_id, gfn);
+        ret = xc_mem_paging_load(xch, paging->mem_event.domain_id, gfn,
+                                    paging_buffer);
         if ( ret != 0 )
         {
             if ( errno == ENOMEM )
@@ -662,33 +680,14 @@ static int xenpaging_populate_page(xenpa
                 sleep(1);
                 continue;
             }
-            PERROR("Error preparing %"PRI_xen_pfn" for page-in", gfn);
-            goto out_map;
+            PERROR("Error loading %"PRI_xen_pfn" during page-in", gfn);
+            goto out;
         }
     }
     while ( ret && !interrupted );
 
-    /* Map page */
-    ret = -EFAULT;
-    page = xc_map_foreign_pages(xch, paging->mem_event.domain_id,
-                                PROT_READ | PROT_WRITE, &gfn, 1);
-    if ( page == NULL )
-    {
-        PERROR("Error mapping page %"PRI_xen_pfn": page is null", gfn);
-        goto out_map;
-    }
-
-    /* Read page */
-    ret = read_page(fd, page, i);
-    if ( ret != 0 )
-    {
-        PERROR("Error reading page %"PRI_xen_pfn"", gfn);
-        goto out;
-    }
 
  out:
-    munmap(page, PAGE_SIZE);
- out_map:
     return ret;
 }
 

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 17:22:49 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 17:22:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWALI-0007GU-Kl; Thu, 01 Dec 2011 17:22:40 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RWALG-0007Ej-S6
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 17:22:39 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-8.tower-216.messagelabs.com!1322760111!5837739!1
X-Originating-IP: [208.97.132.83]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi44MyA9PiAxNTQ4OQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13478 invoked from network); 1 Dec 2011 17:21:51 -0000
Received: from caiajhbdcaid.dreamhost.com (HELO homiemail-a75.g.dreamhost.com)
	(208.97.132.83) by server-8.tower-216.messagelabs.com with SMTP;
	1 Dec 2011 17:21:51 -0000
Received: from homiemail-a75.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a75.g.dreamhost.com (Postfix) with ESMTP id E92825EC07C;
	Thu,  1 Dec 2011 09:21:50 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=GBmS/2M8yATf8ucrqnlYGrLizEOJwXekN5Cw7eD2tS5w
	tnibq0Kj8wc6FoJNKHE/jA17B5INvcnz8JwhLk9qj91EY6k0dS81TdBzSqwAf37s
	+crHkouhpNBoebX8M3Z7oUasowKSksh0Uj8BZpMYHIetq/of4/6nA9i6q72q5aY=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=FxRUszIchYA8g//JWAiZTdgQxFY=; b=V/UA6NU/ben
	x9BPTQ/SrX2rFW/E672bSLilS5mMolGO32orQNSsHJS/y8OLRvlokSoI2UycvmUP
	wC+LIYCSuBTQYNjRu8vzWaHAZ1YIZ+4MXX1JV3S6w5NtCWrpoHxvwZP84anG3ify
	Zt0YJnAgNSpzwr0s6HSrFikZ18449ojs=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a75.g.dreamhost.com (Postfix) with ESMTPSA id 429AE5EC080; 
	Thu,  1 Dec 2011 09:21:50 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: e71f880c0518eb9f05baf8369cc3b17f289b137b
Message-Id: <e71f880c0518eb9f05ba.1322760073@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1322760071@xdev.gridcentric.ca>
References: <patchbomb.1322760071@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Thu, 01 Dec 2011 12:21:13 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com, andres@gridcentric.ca, tim@xen.org, olaf@aepfle.de,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 2 of 3] Tools: Libxc wrappers to automatically
 fill in page oud page contents on prepare
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 tools/libxc/xc_mem_event.c  |   4 ++--
 tools/libxc/xc_mem_paging.c |  23 +++++++++++++++++++++++
 tools/libxc/xenctrl.h       |   2 ++
 3 files changed, 27 insertions(+), 2 deletions(-)


Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 2981bd752d51 -r e71f880c0518 tools/libxc/xc_mem_event.c
--- a/tools/libxc/xc_mem_event.c
+++ b/tools/libxc/xc_mem_event.c
@@ -24,7 +24,7 @@
 #include "xc_private.h"
 
 int xc_mem_event_control(xc_interface *xch, domid_t domain_id, unsigned int op,
-                         unsigned int mode, void *shared_page,
+                         unsigned int mode, void *page,
                          void *ring_page, unsigned long gfn)
 {
     DECLARE_DOMCTL;
@@ -34,7 +34,7 @@ int xc_mem_event_control(xc_interface *x
     domctl.u.mem_event_op.op = op;
     domctl.u.mem_event_op.mode = mode;
 
-    domctl.u.mem_event_op.shared_addr = (unsigned long)shared_page;
+    domctl.u.mem_event_op.u.shared_addr = (unsigned long)page;
     domctl.u.mem_event_op.ring_addr = (unsigned long)ring_page;
 
     domctl.u.mem_event_op.gfn = gfn;
diff -r 2981bd752d51 -r e71f880c0518 tools/libxc/xc_mem_paging.c
--- a/tools/libxc/xc_mem_paging.c
+++ b/tools/libxc/xc_mem_paging.c
@@ -65,6 +65,29 @@ int xc_mem_paging_prep(xc_interface *xch
                                 NULL, NULL, gfn);
 }
 
+int xc_mem_paging_load(xc_interface *xch, domid_t domain_id, 
+                                unsigned long gfn, void *buffer)
+{
+    int rc;
+
+    if ( !buffer )
+        return -EINVAL;
+
+    if ( ((unsigned long) buffer) & (XC_PAGE_SIZE - 1) )
+        return -EINVAL;
+
+    if ( mlock(buffer, XC_PAGE_SIZE) )
+        return -errno;
+        
+    rc = xc_mem_event_control(xch, domain_id,
+                                XEN_DOMCTL_MEM_EVENT_OP_PAGING_PREP,
+                                XEN_DOMCTL_MEM_EVENT_OP_PAGING,
+                                buffer, NULL, gfn);
+
+    (void)munlock(buffer, XC_PAGE_SIZE);
+    return rc;
+}
+
 int xc_mem_paging_resume(xc_interface *xch, domid_t domain_id, unsigned long gfn)
 {
     return xc_mem_event_control(xch, domain_id,
diff -r 2981bd752d51 -r e71f880c0518 tools/libxc/xenctrl.h
--- a/tools/libxc/xenctrl.h
+++ b/tools/libxc/xenctrl.h
@@ -1839,6 +1839,8 @@ int xc_mem_paging_nominate(xc_interface 
                            unsigned long gfn);
 int xc_mem_paging_evict(xc_interface *xch, domid_t domain_id, unsigned long gfn);
 int xc_mem_paging_prep(xc_interface *xch, domid_t domain_id, unsigned long gfn);
+int xc_mem_paging_load(xc_interface *xch, domid_t domain_id, 
+                        unsigned long gfn, void *buffer);
 int xc_mem_paging_resume(xc_interface *xch, domid_t domain_id,
                          unsigned long gfn);
 

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 17:22:49 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 17:22:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWALI-0007GU-Kl; Thu, 01 Dec 2011 17:22:40 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RWALG-0007Ej-S6
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 17:22:39 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-8.tower-216.messagelabs.com!1322760111!5837739!1
X-Originating-IP: [208.97.132.83]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi44MyA9PiAxNTQ4OQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13478 invoked from network); 1 Dec 2011 17:21:51 -0000
Received: from caiajhbdcaid.dreamhost.com (HELO homiemail-a75.g.dreamhost.com)
	(208.97.132.83) by server-8.tower-216.messagelabs.com with SMTP;
	1 Dec 2011 17:21:51 -0000
Received: from homiemail-a75.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a75.g.dreamhost.com (Postfix) with ESMTP id E92825EC07C;
	Thu,  1 Dec 2011 09:21:50 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=GBmS/2M8yATf8ucrqnlYGrLizEOJwXekN5Cw7eD2tS5w
	tnibq0Kj8wc6FoJNKHE/jA17B5INvcnz8JwhLk9qj91EY6k0dS81TdBzSqwAf37s
	+crHkouhpNBoebX8M3Z7oUasowKSksh0Uj8BZpMYHIetq/of4/6nA9i6q72q5aY=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=FxRUszIchYA8g//JWAiZTdgQxFY=; b=V/UA6NU/ben
	x9BPTQ/SrX2rFW/E672bSLilS5mMolGO32orQNSsHJS/y8OLRvlokSoI2UycvmUP
	wC+LIYCSuBTQYNjRu8vzWaHAZ1YIZ+4MXX1JV3S6w5NtCWrpoHxvwZP84anG3ify
	Zt0YJnAgNSpzwr0s6HSrFikZ18449ojs=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a75.g.dreamhost.com (Postfix) with ESMTPSA id 429AE5EC080; 
	Thu,  1 Dec 2011 09:21:50 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: e71f880c0518eb9f05baf8369cc3b17f289b137b
Message-Id: <e71f880c0518eb9f05ba.1322760073@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1322760071@xdev.gridcentric.ca>
References: <patchbomb.1322760071@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Thu, 01 Dec 2011 12:21:13 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com, andres@gridcentric.ca, tim@xen.org, olaf@aepfle.de,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 2 of 3] Tools: Libxc wrappers to automatically
 fill in page oud page contents on prepare
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 tools/libxc/xc_mem_event.c  |   4 ++--
 tools/libxc/xc_mem_paging.c |  23 +++++++++++++++++++++++
 tools/libxc/xenctrl.h       |   2 ++
 3 files changed, 27 insertions(+), 2 deletions(-)


Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 2981bd752d51 -r e71f880c0518 tools/libxc/xc_mem_event.c
--- a/tools/libxc/xc_mem_event.c
+++ b/tools/libxc/xc_mem_event.c
@@ -24,7 +24,7 @@
 #include "xc_private.h"
 
 int xc_mem_event_control(xc_interface *xch, domid_t domain_id, unsigned int op,
-                         unsigned int mode, void *shared_page,
+                         unsigned int mode, void *page,
                          void *ring_page, unsigned long gfn)
 {
     DECLARE_DOMCTL;
@@ -34,7 +34,7 @@ int xc_mem_event_control(xc_interface *x
     domctl.u.mem_event_op.op = op;
     domctl.u.mem_event_op.mode = mode;
 
-    domctl.u.mem_event_op.shared_addr = (unsigned long)shared_page;
+    domctl.u.mem_event_op.u.shared_addr = (unsigned long)page;
     domctl.u.mem_event_op.ring_addr = (unsigned long)ring_page;
 
     domctl.u.mem_event_op.gfn = gfn;
diff -r 2981bd752d51 -r e71f880c0518 tools/libxc/xc_mem_paging.c
--- a/tools/libxc/xc_mem_paging.c
+++ b/tools/libxc/xc_mem_paging.c
@@ -65,6 +65,29 @@ int xc_mem_paging_prep(xc_interface *xch
                                 NULL, NULL, gfn);
 }
 
+int xc_mem_paging_load(xc_interface *xch, domid_t domain_id, 
+                                unsigned long gfn, void *buffer)
+{
+    int rc;
+
+    if ( !buffer )
+        return -EINVAL;
+
+    if ( ((unsigned long) buffer) & (XC_PAGE_SIZE - 1) )
+        return -EINVAL;
+
+    if ( mlock(buffer, XC_PAGE_SIZE) )
+        return -errno;
+        
+    rc = xc_mem_event_control(xch, domain_id,
+                                XEN_DOMCTL_MEM_EVENT_OP_PAGING_PREP,
+                                XEN_DOMCTL_MEM_EVENT_OP_PAGING,
+                                buffer, NULL, gfn);
+
+    (void)munlock(buffer, XC_PAGE_SIZE);
+    return rc;
+}
+
 int xc_mem_paging_resume(xc_interface *xch, domid_t domain_id, unsigned long gfn)
 {
     return xc_mem_event_control(xch, domain_id,
diff -r 2981bd752d51 -r e71f880c0518 tools/libxc/xenctrl.h
--- a/tools/libxc/xenctrl.h
+++ b/tools/libxc/xenctrl.h
@@ -1839,6 +1839,8 @@ int xc_mem_paging_nominate(xc_interface 
                            unsigned long gfn);
 int xc_mem_paging_evict(xc_interface *xch, domid_t domain_id, unsigned long gfn);
 int xc_mem_paging_prep(xc_interface *xch, domid_t domain_id, unsigned long gfn);
+int xc_mem_paging_load(xc_interface *xch, domid_t domain_id, 
+                        unsigned long gfn, void *buffer);
 int xc_mem_paging_resume(xc_interface *xch, domid_t domain_id,
                          unsigned long gfn);
 

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 17:22:52 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 17: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.xensource.com>)
	id 1RWALA-0007ES-Kd; Thu, 01 Dec 2011 17:22:32 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RWAL9-0007Dn-DH
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 17:22:31 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-7.tower-216.messagelabs.com!1322760110!5820145!1
X-Originating-IP: [208.97.132.83]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi44MyA9PiAxNTQ4OQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30567 invoked from network); 1 Dec 2011 17:21:51 -0000
Received: from caiajhbdcaid.dreamhost.com (HELO homiemail-a75.g.dreamhost.com)
	(208.97.132.83) by server-7.tower-216.messagelabs.com with SMTP;
	1 Dec 2011 17:21:51 -0000
Received: from homiemail-a75.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a75.g.dreamhost.com (Postfix) with ESMTP id 1A56B5EC07E;
	Thu,  1 Dec 2011 09:21:50 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=YloOlw/M320eVKCx/kFJC5gKCLF3V4CM6TarmWAatxrH
	xLfWzS01ZNuYFuzsvsxRP3cRWz93CJ2etNNGBipuoktZMzj/Vzm43sjsb1R7GlBu
	pewDJlHm5zpJrMdEgYSRKSQbfFwpKj1Veuv8TFm6D+IG1jJjafbHYzRlDXg+GRg=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=EVpXy9e2Ws2pWlzZuV/mPeCQ/ng=; b=BhRWpC8NzjC
	FjmLlKuHE03qCQK1T2VmtSFftKy86mH3QwBW0DrHI4v7gnKEAWgPztr5T/BKHm+y
	vQqOIocANDVo54OwKQJNZtQuWw7Cv18kSkceCD0J3wjdOgzhjR9pzx3IAY0Zpv5/
	EVjNqBOMk/2d+7+Uz3aFDzS9WabGLDz8=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a75.g.dreamhost.com (Postfix) with ESMTPSA id 5310E5EC084; 
	Thu,  1 Dec 2011 09:21:49 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 2981bd752d51ad9b496784177f65f638300695d4
Message-Id: <2981bd752d51ad9b4967.1322760072@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1322760071@xdev.gridcentric.ca>
References: <patchbomb.1322760071@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Thu, 01 Dec 2011 12:21:12 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com, andres@gridcentric.ca, tim@xen.org, olaf@aepfle.de,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 1 of 3] After preparing a page for page-in,
 allow immediate fill-in of the page contents
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/mm/mem_event.c  |   2 +-
 xen/arch/x86/mm/mem_paging.c |   2 +-
 xen/arch/x86/mm/p2m.c        |  32 ++++++++++++++++++++++++++++++--
 xen/include/asm-x86/p2m.h    |   2 +-
 xen/include/public/domctl.h  |   8 ++++++--
 5 files changed, 39 insertions(+), 7 deletions(-)


p2m_mem_paging_prep ensures that an mfn is backing the paged-out gfn, and
transitions to the next state in the paging state machine for that page.
Foreign mappings of the gfn will now succeed. This is the key idea, as
it allows the pager to now map the gfn and fill in its contents.

Unfortunately, it also allows any other foreign mapper to map the gfn and read
its contents. This is particularly dangerous when the populate is launched
by a foreign mapper in the first place, which will be actively retrying the
map operation and might race with the pager. Qemu-dm being a prime example.

Fix the race by allowing a buffer to be optionally passed in the prep
operation, and having the hypervisor memcpy from that buffer into the newly
prepped page before promoting the gfn type.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 2372d2bf76b5 -r 2981bd752d51 xen/arch/x86/mm/mem_event.c
--- a/xen/arch/x86/mm/mem_event.c
+++ b/xen/arch/x86/mm/mem_event.c
@@ -45,7 +45,7 @@ static int mem_event_enable(struct domai
     struct domain *dom_mem_event = current->domain;
     struct vcpu *v = current;
     unsigned long ring_addr = mec->ring_addr;
-    unsigned long shared_addr = mec->shared_addr;
+    unsigned long shared_addr = mec->u.shared_addr;
     l1_pgentry_t l1e;
     unsigned long shared_gfn = 0, ring_gfn = 0; /* gcc ... */
     p2m_type_t p2mt;
diff -r 2372d2bf76b5 -r 2981bd752d51 xen/arch/x86/mm/mem_paging.c
--- a/xen/arch/x86/mm/mem_paging.c
+++ b/xen/arch/x86/mm/mem_paging.c
@@ -47,7 +47,7 @@ int mem_paging_domctl(struct domain *d, 
     case XEN_DOMCTL_MEM_EVENT_OP_PAGING_PREP:
     {
         unsigned long gfn = mec->gfn;
-        return p2m_mem_paging_prep(d, gfn);
+        return p2m_mem_paging_prep(d, gfn, mec->u.buffer);
     }
     break;
 
diff -r 2372d2bf76b5 -r 2981bd752d51 xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -983,14 +983,21 @@ void p2m_mem_paging_populate(struct doma
  * mfn if populate was called for  gfn which was nominated but not evicted. In
  * this case only the p2mt needs to be forwarded.
  */
-int p2m_mem_paging_prep(struct domain *d, unsigned long gfn)
+int p2m_mem_paging_prep(struct domain *d, unsigned long gfn, uint64_t buffer)
 {
     struct page_info *page;
     p2m_type_t p2mt;
     p2m_access_t a;
     mfn_t mfn;
     struct p2m_domain *p2m = p2m_get_hostp2m(d);
-    int ret;
+    int ret, page_extant = 1;
+    const void *user_ptr = (const void *) buffer;
+
+    if ( user_ptr )
+        /* Sanity check the buffer and bail out early if trouble */
+        if ( (buffer & (PAGE_SIZE - 1)) || 
+             (!access_ok(user_ptr, PAGE_SIZE)) )
+            return -EINVAL;
 
     p2m_lock(p2m);
 
@@ -1010,6 +1017,27 @@ int p2m_mem_paging_prep(struct domain *d
         if ( unlikely(page == NULL) )
             goto out;
         mfn = page_to_mfn(page);
+        page_extant = 0;
+    }
+
+    /* If we were given a buffer, now is the time to use it */
+    if ( !page_extant && user_ptr )
+    {
+        void *guest_map;
+        int rc;
+
+        ASSERT( mfn_valid(mfn) );
+        guest_map = map_domain_page(mfn_x(mfn));
+        rc = copy_from_user(guest_map, user_ptr, PAGE_SIZE);
+        unmap_domain_page(guest_map);
+        if ( rc )
+        {
+            gdprintk(XENLOG_ERR, "Failed to load paging-in gfn %lx domain %u "
+                                 "bytes left %d\n", gfn, d->domain_id, rc);
+            ret = -EFAULT;
+            put_page(page); /* Don't leak pages */
+            goto out;            
+        }
     }
 
     /* Fix p2m mapping */
diff -r 2372d2bf76b5 -r 2981bd752d51 xen/include/asm-x86/p2m.h
--- a/xen/include/asm-x86/p2m.h
+++ b/xen/include/asm-x86/p2m.h
@@ -477,7 +477,7 @@ void p2m_mem_paging_drop_page(struct dom
 /* Start populating a paged out frame */
 void p2m_mem_paging_populate(struct domain *d, unsigned long gfn);
 /* Prepare the p2m for paging a frame in */
-int p2m_mem_paging_prep(struct domain *d, unsigned long gfn);
+int p2m_mem_paging_prep(struct domain *d, unsigned long gfn, uint64_t buffer);
 /* Resume normal operation (in case a domain was paused) */
 void p2m_mem_paging_resume(struct domain *d);
 #else
diff -r 2372d2bf76b5 -r 2981bd752d51 xen/include/public/domctl.h
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -742,8 +742,12 @@ struct xen_domctl_mem_event_op {
     uint32_t       op;           /* XEN_DOMCTL_MEM_EVENT_OP_*_* */
     uint32_t       mode;         /* XEN_DOMCTL_MEM_EVENT_OP_* */
 
-    /* OP_ENABLE */
-    uint64_aligned_t shared_addr;  /* IN:  Virtual address of shared page */
+    union {
+        /* OP_ENABLE IN:  Virtual address of shared page */
+        uint64_aligned_t shared_addr;  
+        /* PAGING_PREP IN: buffer to immediately fill page in */
+        uint64_aligned_t buffer;
+    } u;
     uint64_aligned_t ring_addr;    /* IN:  Virtual address of ring page */
 
     /* Other OPs */

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 17:22:52 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 17: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.xensource.com>)
	id 1RWALA-0007ES-Kd; Thu, 01 Dec 2011 17:22:32 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RWAL9-0007Dn-DH
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 17:22:31 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-7.tower-216.messagelabs.com!1322760110!5820145!1
X-Originating-IP: [208.97.132.83]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi44MyA9PiAxNTQ4OQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30567 invoked from network); 1 Dec 2011 17:21:51 -0000
Received: from caiajhbdcaid.dreamhost.com (HELO homiemail-a75.g.dreamhost.com)
	(208.97.132.83) by server-7.tower-216.messagelabs.com with SMTP;
	1 Dec 2011 17:21:51 -0000
Received: from homiemail-a75.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a75.g.dreamhost.com (Postfix) with ESMTP id 1A56B5EC07E;
	Thu,  1 Dec 2011 09:21:50 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=YloOlw/M320eVKCx/kFJC5gKCLF3V4CM6TarmWAatxrH
	xLfWzS01ZNuYFuzsvsxRP3cRWz93CJ2etNNGBipuoktZMzj/Vzm43sjsb1R7GlBu
	pewDJlHm5zpJrMdEgYSRKSQbfFwpKj1Veuv8TFm6D+IG1jJjafbHYzRlDXg+GRg=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=EVpXy9e2Ws2pWlzZuV/mPeCQ/ng=; b=BhRWpC8NzjC
	FjmLlKuHE03qCQK1T2VmtSFftKy86mH3QwBW0DrHI4v7gnKEAWgPztr5T/BKHm+y
	vQqOIocANDVo54OwKQJNZtQuWw7Cv18kSkceCD0J3wjdOgzhjR9pzx3IAY0Zpv5/
	EVjNqBOMk/2d+7+Uz3aFDzS9WabGLDz8=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a75.g.dreamhost.com (Postfix) with ESMTPSA id 5310E5EC084; 
	Thu,  1 Dec 2011 09:21:49 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 2981bd752d51ad9b496784177f65f638300695d4
Message-Id: <2981bd752d51ad9b4967.1322760072@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1322760071@xdev.gridcentric.ca>
References: <patchbomb.1322760071@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Thu, 01 Dec 2011 12:21:12 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com, andres@gridcentric.ca, tim@xen.org, olaf@aepfle.de,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 1 of 3] After preparing a page for page-in,
 allow immediate fill-in of the page contents
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/mm/mem_event.c  |   2 +-
 xen/arch/x86/mm/mem_paging.c |   2 +-
 xen/arch/x86/mm/p2m.c        |  32 ++++++++++++++++++++++++++++++--
 xen/include/asm-x86/p2m.h    |   2 +-
 xen/include/public/domctl.h  |   8 ++++++--
 5 files changed, 39 insertions(+), 7 deletions(-)


p2m_mem_paging_prep ensures that an mfn is backing the paged-out gfn, and
transitions to the next state in the paging state machine for that page.
Foreign mappings of the gfn will now succeed. This is the key idea, as
it allows the pager to now map the gfn and fill in its contents.

Unfortunately, it also allows any other foreign mapper to map the gfn and read
its contents. This is particularly dangerous when the populate is launched
by a foreign mapper in the first place, which will be actively retrying the
map operation and might race with the pager. Qemu-dm being a prime example.

Fix the race by allowing a buffer to be optionally passed in the prep
operation, and having the hypervisor memcpy from that buffer into the newly
prepped page before promoting the gfn type.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 2372d2bf76b5 -r 2981bd752d51 xen/arch/x86/mm/mem_event.c
--- a/xen/arch/x86/mm/mem_event.c
+++ b/xen/arch/x86/mm/mem_event.c
@@ -45,7 +45,7 @@ static int mem_event_enable(struct domai
     struct domain *dom_mem_event = current->domain;
     struct vcpu *v = current;
     unsigned long ring_addr = mec->ring_addr;
-    unsigned long shared_addr = mec->shared_addr;
+    unsigned long shared_addr = mec->u.shared_addr;
     l1_pgentry_t l1e;
     unsigned long shared_gfn = 0, ring_gfn = 0; /* gcc ... */
     p2m_type_t p2mt;
diff -r 2372d2bf76b5 -r 2981bd752d51 xen/arch/x86/mm/mem_paging.c
--- a/xen/arch/x86/mm/mem_paging.c
+++ b/xen/arch/x86/mm/mem_paging.c
@@ -47,7 +47,7 @@ int mem_paging_domctl(struct domain *d, 
     case XEN_DOMCTL_MEM_EVENT_OP_PAGING_PREP:
     {
         unsigned long gfn = mec->gfn;
-        return p2m_mem_paging_prep(d, gfn);
+        return p2m_mem_paging_prep(d, gfn, mec->u.buffer);
     }
     break;
 
diff -r 2372d2bf76b5 -r 2981bd752d51 xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -983,14 +983,21 @@ void p2m_mem_paging_populate(struct doma
  * mfn if populate was called for  gfn which was nominated but not evicted. In
  * this case only the p2mt needs to be forwarded.
  */
-int p2m_mem_paging_prep(struct domain *d, unsigned long gfn)
+int p2m_mem_paging_prep(struct domain *d, unsigned long gfn, uint64_t buffer)
 {
     struct page_info *page;
     p2m_type_t p2mt;
     p2m_access_t a;
     mfn_t mfn;
     struct p2m_domain *p2m = p2m_get_hostp2m(d);
-    int ret;
+    int ret, page_extant = 1;
+    const void *user_ptr = (const void *) buffer;
+
+    if ( user_ptr )
+        /* Sanity check the buffer and bail out early if trouble */
+        if ( (buffer & (PAGE_SIZE - 1)) || 
+             (!access_ok(user_ptr, PAGE_SIZE)) )
+            return -EINVAL;
 
     p2m_lock(p2m);
 
@@ -1010,6 +1017,27 @@ int p2m_mem_paging_prep(struct domain *d
         if ( unlikely(page == NULL) )
             goto out;
         mfn = page_to_mfn(page);
+        page_extant = 0;
+    }
+
+    /* If we were given a buffer, now is the time to use it */
+    if ( !page_extant && user_ptr )
+    {
+        void *guest_map;
+        int rc;
+
+        ASSERT( mfn_valid(mfn) );
+        guest_map = map_domain_page(mfn_x(mfn));
+        rc = copy_from_user(guest_map, user_ptr, PAGE_SIZE);
+        unmap_domain_page(guest_map);
+        if ( rc )
+        {
+            gdprintk(XENLOG_ERR, "Failed to load paging-in gfn %lx domain %u "
+                                 "bytes left %d\n", gfn, d->domain_id, rc);
+            ret = -EFAULT;
+            put_page(page); /* Don't leak pages */
+            goto out;            
+        }
     }
 
     /* Fix p2m mapping */
diff -r 2372d2bf76b5 -r 2981bd752d51 xen/include/asm-x86/p2m.h
--- a/xen/include/asm-x86/p2m.h
+++ b/xen/include/asm-x86/p2m.h
@@ -477,7 +477,7 @@ void p2m_mem_paging_drop_page(struct dom
 /* Start populating a paged out frame */
 void p2m_mem_paging_populate(struct domain *d, unsigned long gfn);
 /* Prepare the p2m for paging a frame in */
-int p2m_mem_paging_prep(struct domain *d, unsigned long gfn);
+int p2m_mem_paging_prep(struct domain *d, unsigned long gfn, uint64_t buffer);
 /* Resume normal operation (in case a domain was paused) */
 void p2m_mem_paging_resume(struct domain *d);
 #else
diff -r 2372d2bf76b5 -r 2981bd752d51 xen/include/public/domctl.h
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -742,8 +742,12 @@ struct xen_domctl_mem_event_op {
     uint32_t       op;           /* XEN_DOMCTL_MEM_EVENT_OP_*_* */
     uint32_t       mode;         /* XEN_DOMCTL_MEM_EVENT_OP_* */
 
-    /* OP_ENABLE */
-    uint64_aligned_t shared_addr;  /* IN:  Virtual address of shared page */
+    union {
+        /* OP_ENABLE IN:  Virtual address of shared page */
+        uint64_aligned_t shared_addr;  
+        /* PAGING_PREP IN: buffer to immediately fill page in */
+        uint64_aligned_t buffer;
+    } u;
     uint64_aligned_t ring_addr;    /* IN:  Virtual address of ring page */
 
     /* Other OPs */

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 17:23:13 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 17:23:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWALh-0007Ok-31; Thu, 01 Dec 2011 17:23:05 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RWALf-0007NC-Iu
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 17:23:03 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-5.tower-21.messagelabs.com!1322760140!292662!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2788 invoked from network); 1 Dec 2011 17:22:23 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-5.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 1 Dec 2011 17:22:23 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RWAKv-000H1V-Mp; Thu, 01 Dec 2011 17:22:17 +0000
Date: Thu, 1 Dec 2011 17:22:17 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20111201172217.GL61203@ocelot.phlegethon.org>
References: <patchbomb.1322756504@xdev.gridcentric.ca>
	<7b6db593bda0a2938857.1322756505@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <7b6db593bda0a2938857.1322756505@xdev.gridcentric.ca>
User-Agent: Mutt/1.4.2.1i
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com, keir.xen@gmail.com,
	JBeulich@suse.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 1 of 3] x86: Add conversion from a xen map
	to an mfn
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Applied all three.  I moved the map-to-mfn function to beside the
map_domain_page functions, to avoid extra #ifdeffery. 

Thanks,

Tim.

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 17:23:13 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 17:23:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWALh-0007Ok-31; Thu, 01 Dec 2011 17:23:05 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RWALf-0007NC-Iu
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 17:23:03 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-5.tower-21.messagelabs.com!1322760140!292662!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2788 invoked from network); 1 Dec 2011 17:22:23 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-5.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 1 Dec 2011 17:22:23 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RWAKv-000H1V-Mp; Thu, 01 Dec 2011 17:22:17 +0000
Date: Thu, 1 Dec 2011 17:22:17 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20111201172217.GL61203@ocelot.phlegethon.org>
References: <patchbomb.1322756504@xdev.gridcentric.ca>
	<7b6db593bda0a2938857.1322756505@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <7b6db593bda0a2938857.1322756505@xdev.gridcentric.ca>
User-Agent: Mutt/1.4.2.1i
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com, keir.xen@gmail.com,
	JBeulich@suse.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 1 of 3] x86: Add conversion from a xen map
	to an mfn
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Applied all three.  I moved the map-to-mfn function to beside the
map_domain_page functions, to avoid extra #ifdeffery. 

Thanks,

Tim.

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 17:24:41 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 17:24:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWAN4-0007jU-K3; Thu, 01 Dec 2011 17:24:30 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RWAN2-0007hN-OU
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 17:24:28 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1322760227!5839484!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU2Nw==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30605 invoked from network); 1 Dec 2011 17:23:48 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 17:23:48 -0000
X-IronPort-AV: E=Sophos;i="4.71,279,1320624000"; 
   d="scan'208";a="9237112"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Dec 2011 17:23:46 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 1 Dec 2011 17:23:46 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RWAMM-0003uo-73; Thu, 01 Dec 2011 17:23:46 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RWAMM-0002un-6B;
	Thu, 01 Dec 2011 17:23:46 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20183.47138.179272.716638@mariner.uk.xensource.com>
Date: Thu, 1 Dec 2011 17:23:46 +0000
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
In-Reply-To: <e71f880c0518eb9f05ba.1322760073@xdev.gridcentric.ca>
References: <patchbomb.1322760071@xdev.gridcentric.ca>
	<e71f880c0518eb9f05ba.1322760073@xdev.gridcentric.ca>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "olaf@aepfle.de" <olaf@aepfle.de>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Tim
	\(Xen.org\)" <tim@xen.org>,
	"andres@gridcentric.ca" <andres@gridcentric.ca>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"adin@gridcentric.ca" <adin@gridcentric.ca>
Subject: Re: [Xen-devel] [PATCH 2 of 3] Tools: Libxc wrappers to
 automatically fill in page oud page contents on prepare
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Andres Lagar-Cavilla writes ("[PATCH 2 of 3] Tools: Libxc wrappers to automatically fill in page oud page contents on prepare"):
>  tools/libxc/xc_mem_event.c  |   4 ++--
>  tools/libxc/xc_mem_paging.c |  23 +++++++++++++++++++++++
>  tools/libxc/xenctrl.h       |   2 ++
>  3 files changed, 27 insertions(+), 2 deletions(-)
> 
> 
> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 17:24:41 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 17:24:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWAN4-0007jU-K3; Thu, 01 Dec 2011 17:24:30 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RWAN2-0007hN-OU
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 17:24:28 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1322760227!5839484!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU2Nw==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30605 invoked from network); 1 Dec 2011 17:23:48 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 17:23:48 -0000
X-IronPort-AV: E=Sophos;i="4.71,279,1320624000"; 
   d="scan'208";a="9237112"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Dec 2011 17:23:46 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 1 Dec 2011 17:23:46 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RWAMM-0003uo-73; Thu, 01 Dec 2011 17:23:46 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RWAMM-0002un-6B;
	Thu, 01 Dec 2011 17:23:46 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20183.47138.179272.716638@mariner.uk.xensource.com>
Date: Thu, 1 Dec 2011 17:23:46 +0000
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
In-Reply-To: <e71f880c0518eb9f05ba.1322760073@xdev.gridcentric.ca>
References: <patchbomb.1322760071@xdev.gridcentric.ca>
	<e71f880c0518eb9f05ba.1322760073@xdev.gridcentric.ca>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "olaf@aepfle.de" <olaf@aepfle.de>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Tim
	\(Xen.org\)" <tim@xen.org>,
	"andres@gridcentric.ca" <andres@gridcentric.ca>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"adin@gridcentric.ca" <adin@gridcentric.ca>
Subject: Re: [Xen-devel] [PATCH 2 of 3] Tools: Libxc wrappers to
 automatically fill in page oud page contents on prepare
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Andres Lagar-Cavilla writes ("[PATCH 2 of 3] Tools: Libxc wrappers to automatically fill in page oud page contents on prepare"):
>  tools/libxc/xc_mem_event.c  |   4 ++--
>  tools/libxc/xc_mem_paging.c |  23 +++++++++++++++++++++++
>  tools/libxc/xenctrl.h       |   2 ++
>  3 files changed, 27 insertions(+), 2 deletions(-)
> 
> 
> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 17:25:12 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 17: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.xensource.com>)
	id 1RWANY-0007qE-3P; Thu, 01 Dec 2011 17:25:00 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RWANV-0007p5-NS
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 17:24:57 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1322760257!5442164!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU2Nw==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22548 invoked from network); 1 Dec 2011 17:24:17 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 17:24:17 -0000
X-IronPort-AV: E=Sophos;i="4.71,279,1320624000"; 
   d="scan'208";a="9237118"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Dec 2011 17:24:17 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 1 Dec 2011 17:24:17 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RWAMr-0003v2-Be; Thu, 01 Dec 2011 17:24:17 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RWAMr-0002uw-AE;
	Thu, 01 Dec 2011 17:24:17 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20183.47169.122685.542076@mariner.uk.xensource.com>
Date: Thu, 1 Dec 2011 17:24:17 +0000
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
In-Reply-To: <90ded86b0a30c34e1644.1322760074@xdev.gridcentric.ca>
References: <patchbomb.1322760071@xdev.gridcentric.ca>
	<90ded86b0a30c34e1644.1322760074@xdev.gridcentric.ca>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "andres@gridcentric.ca" <andres@gridcentric.ca>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Tim
	\(Xen.org\)" <tim@xen.org>, "olaf@aepfle.de" <olaf@aepfle.de>,
	"adin@gridcentric.ca" <adin@gridcentric.ca>
Subject: Re: [Xen-devel] [PATCH 3 of 3] Teach xenpaging to use the new and
 non-racy xc_mem_paging_load
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Andres Lagar-Cavilla writes ("[PATCH 3 of 3] Teach xenpaging to use the new and non-racy xc_mem_paging_load"):
>  tools/xenpaging/xenpaging.c |  43 +++++++++++++++++++++----------------------
>  1 files changed, 21 insertions(+), 22 deletions(-)
> 
> interface.

This one should get an ack from Olaf, probably.

Also your commit message seems to have been mangled.

Thanks,
Ian.

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 17:25:12 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 17: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.xensource.com>)
	id 1RWANY-0007qE-3P; Thu, 01 Dec 2011 17:25:00 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RWANV-0007p5-NS
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 17:24:57 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1322760257!5442164!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU2Nw==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22548 invoked from network); 1 Dec 2011 17:24:17 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 17:24:17 -0000
X-IronPort-AV: E=Sophos;i="4.71,279,1320624000"; 
   d="scan'208";a="9237118"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Dec 2011 17:24:17 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 1 Dec 2011 17:24:17 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RWAMr-0003v2-Be; Thu, 01 Dec 2011 17:24:17 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RWAMr-0002uw-AE;
	Thu, 01 Dec 2011 17:24:17 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20183.47169.122685.542076@mariner.uk.xensource.com>
Date: Thu, 1 Dec 2011 17:24:17 +0000
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
In-Reply-To: <90ded86b0a30c34e1644.1322760074@xdev.gridcentric.ca>
References: <patchbomb.1322760071@xdev.gridcentric.ca>
	<90ded86b0a30c34e1644.1322760074@xdev.gridcentric.ca>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "andres@gridcentric.ca" <andres@gridcentric.ca>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Tim
	\(Xen.org\)" <tim@xen.org>, "olaf@aepfle.de" <olaf@aepfle.de>,
	"adin@gridcentric.ca" <adin@gridcentric.ca>
Subject: Re: [Xen-devel] [PATCH 3 of 3] Teach xenpaging to use the new and
 non-racy xc_mem_paging_load
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Andres Lagar-Cavilla writes ("[PATCH 3 of 3] Teach xenpaging to use the new and non-racy xc_mem_paging_load"):
>  tools/xenpaging/xenpaging.c |  43 +++++++++++++++++++++----------------------
>  1 files changed, 21 insertions(+), 22 deletions(-)
> 
> interface.

This one should get an ack from Olaf, probably.

Also your commit message seems to have been mangled.

Thanks,
Ian.

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 17:27:07 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 17:27:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWAPO-0008BO-L3; Thu, 01 Dec 2011 17:26:54 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RWAPN-0008AK-MY
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 17:26:53 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1322760373!3902563!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU2Nw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5423 invoked from network); 1 Dec 2011 17:26:13 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 17:26:13 -0000
X-IronPort-AV: E=Sophos;i="4.71,279,1320624000"; 
   d="scan'208";a="9237162"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Dec 2011 17:26:13 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 1 Dec 2011 17:26:13 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RWAOi-0003vi-Ng; Thu, 01 Dec 2011 17:26:12 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RWAOi-00033V-Ms;
	Thu, 01 Dec 2011 17:26:12 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20183.47282.24594.546415@mariner.uk.xensource.com>
Date: Thu, 1 Dec 2011 17:26:10 +0000
To: Jonathan Davies <Jonathan.Davies@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <CCE8682617CC8E4693CEF507039F8E86B59B2F5330@LONPMAILBOX01.citrite.net>
References: <10758a9aa01ce39c4075.1321268775@localhost6.localdomain6>
	<20171.61030.71499.197458@mariner.uk.xensource.com>
	<CCE8682617CC8E4693CEF507039F8E86B59B2F52F4@LONPMAILBOX01.citrite.net>
	<20174.37130.453340.517982@mariner.uk.xensource.com>
	<CCE8682617CC8E4693CEF507039F8E86B59B2F5330@LONPMAILBOX01.citrite.net>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] [OCaml] Release the global
	lock	during	some	hypercalls
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Jonathan Davies writes ("Re: [Xen-devel] [PATCH] [OCaml] Release the global lock during	some	hypercalls"):
> The patch has now gone through a XenRT nightly test; no problems were observed. Is that sufficient to allay your potential concern?

Yes, thanks, I have commited the patch.

Ian.

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 17:27:07 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 17:27:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWAPO-0008BO-L3; Thu, 01 Dec 2011 17:26:54 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RWAPN-0008AK-MY
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 17:26:53 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1322760373!3902563!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU2Nw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5423 invoked from network); 1 Dec 2011 17:26:13 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 17:26:13 -0000
X-IronPort-AV: E=Sophos;i="4.71,279,1320624000"; 
   d="scan'208";a="9237162"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Dec 2011 17:26:13 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 1 Dec 2011 17:26:13 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RWAOi-0003vi-Ng; Thu, 01 Dec 2011 17:26:12 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RWAOi-00033V-Ms;
	Thu, 01 Dec 2011 17:26:12 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20183.47282.24594.546415@mariner.uk.xensource.com>
Date: Thu, 1 Dec 2011 17:26:10 +0000
To: Jonathan Davies <Jonathan.Davies@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <CCE8682617CC8E4693CEF507039F8E86B59B2F5330@LONPMAILBOX01.citrite.net>
References: <10758a9aa01ce39c4075.1321268775@localhost6.localdomain6>
	<20171.61030.71499.197458@mariner.uk.xensource.com>
	<CCE8682617CC8E4693CEF507039F8E86B59B2F52F4@LONPMAILBOX01.citrite.net>
	<20174.37130.453340.517982@mariner.uk.xensource.com>
	<CCE8682617CC8E4693CEF507039F8E86B59B2F5330@LONPMAILBOX01.citrite.net>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] [OCaml] Release the global
	lock	during	some	hypercalls
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Jonathan Davies writes ("Re: [Xen-devel] [PATCH] [OCaml] Release the global lock during	some	hypercalls"):
> The patch has now gone through a XenRT nightly test; no problems were observed. Is that sufficient to allay your potential concern?

Yes, thanks, I have commited the patch.

Ian.

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 17:40:16 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 17:40:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWAc2-0000OJ-Dq; Thu, 01 Dec 2011 17:39:58 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RWAc0-0000OE-KC
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 17:39:56 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-9.tower-174.messagelabs.com!1322761156!3909412!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22688 invoked from network); 1 Dec 2011 17:39:16 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-9.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 1 Dec 2011 17:39:16 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RWAbK-000H51-Bt; Thu, 01 Dec 2011 17:39:14 +0000
Date: Thu, 1 Dec 2011 17:39:14 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20111201173914.GN61203@ocelot.phlegethon.org>
References: <patchbomb.1322760071@xdev.gridcentric.ca>
	<2981bd752d51ad9b4967.1322760072@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <2981bd752d51ad9b4967.1322760072@xdev.gridcentric.ca>
User-Agent: Mutt/1.4.2.1i
Cc: ian.jackson@citrix.com, andres@gridcentric.ca,
	xen-devel@lists.xensource.com, olaf@aepfle.de, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 1 of 3] After preparing a page for page-in,
	allow immediate fill-in of the page contents
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 12:21 -0500 on 01 Dec (1322742072), Andres Lagar-Cavilla wrote:
>  xen/arch/x86/mm/mem_event.c  |   2 +-
>  xen/arch/x86/mm/mem_paging.c |   2 +-
>  xen/arch/x86/mm/p2m.c        |  32 ++++++++++++++++++++++++++++++--
>  xen/include/asm-x86/p2m.h    |   2 +-
>  xen/include/public/domctl.h  |   8 ++++++--
>  5 files changed, 39 insertions(+), 7 deletions(-)
> 
> 
> p2m_mem_paging_prep ensures that an mfn is backing the paged-out gfn, and
> transitions to the next state in the paging state machine for that page.
> Foreign mappings of the gfn will now succeed. This is the key idea, as
> it allows the pager to now map the gfn and fill in its contents.
> 
> Unfortunately, it also allows any other foreign mapper to map the gfn and read
> its contents. This is particularly dangerous when the populate is launched
> by a foreign mapper in the first place, which will be actively retrying the
> map operation and might race with the pager. Qemu-dm being a prime example.
> 
> Fix the race by allowing a buffer to be optionally passed in the prep
> operation, and having the hypervisor memcpy from that buffer into the newly
> prepped page before promoting the gfn type.
> 
> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

Acked-by: Tim Deegan <tim@xen.org>

Once Olaf OKs the xenpaging change, this whole set can go in.

Tim.

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 17:40:16 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 17:40:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWAc2-0000OJ-Dq; Thu, 01 Dec 2011 17:39:58 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RWAc0-0000OE-KC
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 17:39:56 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-9.tower-174.messagelabs.com!1322761156!3909412!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22688 invoked from network); 1 Dec 2011 17:39:16 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-9.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 1 Dec 2011 17:39:16 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RWAbK-000H51-Bt; Thu, 01 Dec 2011 17:39:14 +0000
Date: Thu, 1 Dec 2011 17:39:14 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20111201173914.GN61203@ocelot.phlegethon.org>
References: <patchbomb.1322760071@xdev.gridcentric.ca>
	<2981bd752d51ad9b4967.1322760072@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <2981bd752d51ad9b4967.1322760072@xdev.gridcentric.ca>
User-Agent: Mutt/1.4.2.1i
Cc: ian.jackson@citrix.com, andres@gridcentric.ca,
	xen-devel@lists.xensource.com, olaf@aepfle.de, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 1 of 3] After preparing a page for page-in,
	allow immediate fill-in of the page contents
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 12:21 -0500 on 01 Dec (1322742072), Andres Lagar-Cavilla wrote:
>  xen/arch/x86/mm/mem_event.c  |   2 +-
>  xen/arch/x86/mm/mem_paging.c |   2 +-
>  xen/arch/x86/mm/p2m.c        |  32 ++++++++++++++++++++++++++++++--
>  xen/include/asm-x86/p2m.h    |   2 +-
>  xen/include/public/domctl.h  |   8 ++++++--
>  5 files changed, 39 insertions(+), 7 deletions(-)
> 
> 
> p2m_mem_paging_prep ensures that an mfn is backing the paged-out gfn, and
> transitions to the next state in the paging state machine for that page.
> Foreign mappings of the gfn will now succeed. This is the key idea, as
> it allows the pager to now map the gfn and fill in its contents.
> 
> Unfortunately, it also allows any other foreign mapper to map the gfn and read
> its contents. This is particularly dangerous when the populate is launched
> by a foreign mapper in the first place, which will be actively retrying the
> map operation and might race with the pager. Qemu-dm being a prime example.
> 
> Fix the race by allowing a buffer to be optionally passed in the prep
> operation, and having the hypervisor memcpy from that buffer into the newly
> prepped page before promoting the gfn type.
> 
> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

Acked-by: Tim Deegan <tim@xen.org>

Once Olaf OKs the xenpaging change, this whole set can go in.

Tim.

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 17:48:17 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 17:48:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWAjp-0000a7-CL; Thu, 01 Dec 2011 17:48:01 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <stefan.bader@canonical.com>) id 1RWAjn-0000a2-SQ
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 17:48:00 +0000
X-Env-Sender: stefan.bader@canonical.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1322761635!4976555!1
X-Originating-IP: [91.189.89.112]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8069 invoked from network); 1 Dec 2011 17:47:16 -0000
Received: from youngberry.canonical.com (HELO youngberry.canonical.com)
	(91.189.89.112) by server-13.tower-182.messagelabs.com with SMTP;
	1 Dec 2011 17:47:16 -0000
Received: from p5b2e33b7.dip.t-dialin.net ([91.46.51.183] helo=[192.168.2.5])
	by youngberry.canonical.com with esmtpsa
	(TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71)
	(envelope-from <stefan.bader@canonical.com>)
	id 1RWAj4-0001f7-AS; Thu, 01 Dec 2011 17:47:14 +0000
Message-ID: <4ED7BDA0.8050208@canonical.com>
Date: Thu, 01 Dec 2011 18:47:12 +0100
From: Stefan Bader <stefan.bader@canonical.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:8.0) Gecko/20111124 Thunderbird/8.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <4ED798B2.1040309@canonical.com>
	<1322755432.31810.244.camel@zakaz.uk.xensource.com>
In-Reply-To: <1322755432.31810.244.camel@zakaz.uk.xensource.com>
X-Enigmail-Version: 1.4a1pre
Content-Type: multipart/mixed; boundary="------------040709070607000105030506"
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Xen 4.x / Linux 3.x (dom0 and HVM domU) and NIC
	handling
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a multi-part message in MIME format.
--------------040709070607000105030506
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 01.12.2011 17:03, Ian Campbell wrote:
> On Thu, 2011-12-01 at 15:09 +0000, Stefan Bader wrote:
>> Moving to public discussion...
>>
>> This was found with Xen hypervisor version supporting device unplugging and the
>> domU kernel having net-/blkfront and pci platform built-in (or as module).
>>
>> The block device is defined as hda and the NIC type=ioemu (so theoretically
>> guests without pv support would work, too).
>>
>> Since both drivers are present, the kernel tries to unplug the emulated devices
>> and succeeds. The blkfront driver detects the xvda device available in parallel
>> and is working ok.
>>
>> However the network interface does not work. There are entries present under
>> sysfs for the xenbus but trying to bring it up fails with errors. And also there
>> seems to be no mac address set (all zeros in sysfs).
>> When the type=ioemu is removed in the configuration, this works.
> 
> Which toolstack are you using?
> 
xm (xl with the same config seems to work)

> The weird thing is that, at least with xl, type=ioemu is the default for
> an HVM guest.
> 
> What vif related entries do you get in xenstore, both front and backend?
> 
output of xenstore-ls attached (hopefully contains all info)

> Also what does your qemu-dm command line end up looking like?
> 
also in the attached file.

>> I have not much more debugging information beyond that, yet. But it sounds a bit
>> like NICs should behave the same as block devices. So if there is an emulated
>> device defined there will be an alternate paravirt interface for it and after
>> unplugging the emulated ones we end up with the pv ones.
> 
> That is certainly the expectation.
> 
>> Is that something that can be seen with newer Xen versions, too (I am using 4.1.1)?
> 
> I appear to have some other problem with xen-unstable at the moment.
> I've never noticed a problem in that past, although I don't habitually
> use type=XXX at all in my vif configuration.
> 
> Ian.
> 
>> -Stefan
> 
> 


--------------040709070607000105030506
Content-Type: text/plain;
 name="xl-run.txt"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename="xl-run.txt"

IDc3ODQgPyAgICAgICAgU0xzbCAgIDA6MTMgcWVtdS1kbSAtZCA5IC1kb21haW4tbmFtZSBQ
cmVjaXNlSFZNIC12bmMgMC4wLjAuMDowIC12bmN1bnVzZWQgLWsgZGUgLXNlcmlhbCBwdHkg
LXZpZGVvcmFtIDggLWJvb3QgY2QgLWFjcGkgLXZjcHVzIDIgLXZjcHVfYXZhaWwgMHgzIC1u
ZXQgbmljLHZsYW49MCxtYWNhZGRyPTAwOjE2OjNlOjEyOjA0OmYwLG1vZGVsPXJ0bDgxMzkg
LW5ldCB0YXAsdmxhbj0wLGlmbmFtZT10YXA5LjAsYnJpZGdlPXZpcmJyMCxzY3JpcHQ9bm8g
LU0geGVuZnYKIDc4OTUgaHZjMCAgICAgUysgICAgIDA6MDAgZ3JlcCAtLWNvbG9yPWF1dG8g
cWVtdS1kbQoKdG9vbCA9ICIiCiB4ZW5zdG9yZWQgPSAiIgpsb2NhbCA9ICIiCiBwb29sID0g
IiIKICAwID0gIiIKICAgb3RoZXJfY29uZmlnID0gIiIKICAgZGVzY3JpcHRpb24gPSAiUG9v
bC0wIgogICB1dWlkID0gImJlYmNlMTZmLTkwMmYtNjhjZS1kMzhiLWE0ZDQ5ZTgzNDZhNyIK
ICAgbmFtZSA9ICJQb29sLTAiCiBkb21haW4gPSAiIgogIDAgPSAiIgogICB2bSA9ICIvdm0v
MDAwMDAwMDAtMDAwMC0wMDAwLTAwMDAtMDAwMDAwMDAwMDAwIgogICBkZXZpY2UgPSAiIgog
ICBjb250cm9sID0gIiIKICAgIHBsYXRmb3JtLWZlYXR1cmUtbXVsdGlwcm9jZXNzb3Itc3Vz
cGVuZCA9ICIxIgogICBtZW1vcnkgPSAiIgogICAgdGFyZ2V0ID0gIjUyNDI4OCIKICAgIHN0
YXRpYy1tYXggPSAiNDI5NDk2NzI5MiIKICAgIGZyZWVtZW0tc2xhY2sgPSAiNTAzMjg4MCIK
ICAgZ3Vlc3QgPSAiIgogICBodm1wdiA9ICIiCiAgIGRhdGEgPSAiIgogICBjcHUgPSAiIgog
ICAgMSA9ICIiCiAgICAgYXZhaWxhYmlsaXR5ID0gIm9ubGluZSIKICAgIDMgPSAiIgogICAg
IGF2YWlsYWJpbGl0eSA9ICJvbmxpbmUiCiAgICAyID0gIiIKICAgICBhdmFpbGFiaWxpdHkg
PSAib25saW5lIgogICAgNyA9ICIiCiAgICAgYXZhaWxhYmlsaXR5ID0gIm9ubGluZSIKICAg
IDAgPSAiIgogICAgIGF2YWlsYWJpbGl0eSA9ICJvbmxpbmUiCiAgICA1ID0gIiIKICAgICBh
dmFpbGFiaWxpdHkgPSAib25saW5lIgogICAgNiA9ICIiCiAgICAgYXZhaWxhYmlsaXR5ID0g
Im9ubGluZSIKICAgIDQgPSAiIgogICAgIGF2YWlsYWJpbGl0eSA9ICJvbmxpbmUiCiAgIGRl
c2NyaXB0aW9uID0gIiIKICAgY29uc29sZSA9ICIiCiAgICBsaW1pdCA9ICIxMDQ4NTc2Igog
ICAgdHlwZSA9ICJ4ZW5jb25zb2xlZCIKICAgZG9taWQgPSAiMCIKICAgbmFtZSA9ICJEb21h
aW4tMCIKICAgYmFja2VuZCA9ICIiCiAgICBxZGlzayA9ICIiCiAgICAgOSA9ICIiCiAgICAg
IDc2OCA9ICIiCiAgICAgICBmcm9udGVuZCA9ICIvbG9jYWwvZG9tYWluLzkvZGV2aWNlL3Zi
ZC83NjgiCiAgICAgICBwYXJhbXMgPSAiYWlvOi9yb290L2luc3RhbmNlcy9wcmVjaXNlLXNl
cnZlci9oZGEtNjQuaW1nIgogICAgICAgZnJvbnRlbmQtaWQgPSAiOSIKICAgICAgIG9ubGlu
ZSA9ICIxIgogICAgICAgcmVtb3ZhYmxlID0gIjAiCiAgICAgICBib290YWJsZSA9ICIxIgog
ICAgICAgc3RhdGUgPSAiNCIKICAgICAgIGRldiA9ICJoZGEiCiAgICAgICB0eXBlID0gInRh
cCIKICAgICAgIG1vZGUgPSAidyIKICAgICAgIGZlYXR1cmUtYmFycmllciA9ICIxIgogICAg
ICAgaW5mbyA9ICIwIgogICAgICAgc2VjdG9yLXNpemUgPSAiNTEyIgogICAgICAgc2VjdG9y
cyA9ICIxNjM4NDAwMCIKICAgICAgIGhvdHBsdWctc3RhdHVzID0gImNvbm5lY3RlZCIKICAg
ICAgNTYzMiA9ICIiCiAgICAgICBmcm9udGVuZCA9ICIvbG9jYWwvZG9tYWluLzkvZGV2aWNl
L3ZiZC81NjMyIgogICAgICAgcGFyYW1zID0gImFpbzovcm9vdC9pc29zL3ByZWNpc2Utc2Vy
dmVyLWFtZDY0LmlzbyIKICAgICAgIGZyb250ZW5kLWlkID0gIjkiCiAgICAgICBvbmxpbmUg
PSAiMSIKICAgICAgIHJlbW92YWJsZSA9ICIxIgogICAgICAgYm9vdGFibGUgPSAiMSIKICAg
ICAgIHN0YXRlID0gIjYiCiAgICAgICBkZXYgPSAiaGRjIgogICAgICAgdHlwZSA9ICJ0YXAi
CiAgICAgICBtb2RlID0gInIiCiAgICAgICBmZWF0dXJlLWJhcnJpZXIgPSAiMSIKICAgICAg
IGluZm8gPSAiNCIKICAgICAgIHNlY3Rvci1zaXplID0gIjUxMiIKICAgICAgIHNlY3RvcnMg
PSAiMTMzNzk0NCIKICAgICAgIGhvdHBsdWctc3RhdHVzID0gImNvbm5lY3RlZCIKICAgIGNv
bnNvbGUgPSAiIgogICAgIDIgPSAiIgogICAgIDUgPSAiIgogICAgIDkgPSAiIgogICAgICAw
ID0gIiIKICAgICAgIGZyb250ZW5kID0gIi9sb2NhbC9kb21haW4vOS9jb25zb2xlIgogICAg
ICAgZnJvbnRlbmQtaWQgPSAiOSIKICAgICAgIG9ubGluZSA9ICIxIgogICAgICAgc3RhdGUg
PSAiMSIKICAgICAgIGRvbWFpbiA9ICJQcmVjaXNlSFZNIgogICAgICAgcHJvdG9jb2wgPSAi
dnQxMDAiCiAgICB2aWYgPSAiIgogICAgIDkgPSAiIgogICAgICAwID0gIiIKICAgICAgIGZy
b250ZW5kID0gIi9sb2NhbC9kb21haW4vOS9kZXZpY2UvdmlmLzAiCiAgICAgICBmcm9udGVu
ZC1pZCA9ICI5IgogICAgICAgb25saW5lID0gIjEiCiAgICAgICBzdGF0ZSA9ICI0IgogICAg
ICAgc2NyaXB0ID0gIi9ldGMveGVuL3NjcmlwdHMvdmlmLWJyaWRnZSIKICAgICAgIG1hYyA9
ICIwMDoxNjozZToxMjowNDpmMCIKICAgICAgIGJyaWRnZSA9ICJ2aXJicjAiCiAgICAgICBo
YW5kbGUgPSAiMCIKICAgICAgIGZlYXR1cmUtc2cgPSAiMSIKICAgICAgIGZlYXR1cmUtZ3Nv
LXRjcHY0ID0gIjEiCiAgICAgICBmZWF0dXJlLXJ4LWNvcHkgPSAiMSIKICAgICAgIGZlYXR1
cmUtcngtZmxpcCA9ICIwIgogICAgICAgaG90cGx1Zy1zdGF0dXMgPSAiY29ubmVjdGVkIgog
ICBkZXZpY2UtbW9kZWwgPSAiIgogICAgOSA9ICIiCiAgICAgZGlzYWJsZV9wZiA9ICIwIgog
ICAgIHN0YXRlID0gInJ1bm5pbmciCiAgOSA9ICIiCiAgIHZtID0gIi92bS81ZGUxYzYxYS1j
ZWU4LTRjMTgtYjI5NC00MDliOTIxNGY3YmUiCiAgIG5hbWUgPSAiUHJlY2lzZUhWTSIKICAg
Y29udHJvbCA9ICIiCiAgICBzaHV0ZG93biA9ICIiCiAgICBwbGF0Zm9ybS1mZWF0dXJlLW11
bHRpcHJvY2Vzc29yLXN1c3BlbmQgPSAiMSIKICAgZGV2aWNlID0gIiIKICAgIHN1c3BlbmQg
PSAiIgogICAgIGV2ZW50LWNoYW5uZWwgPSAiIgogICAgdmJkID0gIiIKICAgICA3NjggPSAi
IgogICAgICBiYWNrZW5kID0gIi9sb2NhbC9kb21haW4vMC9iYWNrZW5kL3FkaXNrLzkvNzY4
IgogICAgICBiYWNrZW5kLWlkID0gIjAiCiAgICAgIHN0YXRlID0gIjQiCiAgICAgIHZpcnR1
YWwtZGV2aWNlID0gIjc2OCIKICAgICAgZGV2aWNlLXR5cGUgPSAiZGlzayIKICAgICAgcmlu
Zy1yZWYgPSAiOCIKICAgICAgZXZlbnQtY2hhbm5lbCA9ICIxNyIKICAgICAgcHJvdG9jb2wg
PSAieDg2XzY0LWFiaSIKICAgICA1NjMyID0gIiIKICAgICAgYmFja2VuZCA9ICIvbG9jYWwv
ZG9tYWluLzAvYmFja2VuZC9xZGlzay85LzU2MzIiCiAgICAgIGJhY2tlbmQtaWQgPSAiMCIK
ICAgICAgc3RhdGUgPSAiNiIKICAgICAgdmlydHVhbC1kZXZpY2UgPSAiNTYzMiIKICAgICAg
ZGV2aWNlLXR5cGUgPSAiY2Ryb20iCiAgICB2aWYgPSAiIgogICAgIDAgPSAiIgogICAgICBi
YWNrZW5kID0gIi9sb2NhbC9kb21haW4vMC9iYWNrZW5kL3ZpZi85LzAiCiAgICAgIGJhY2tl
bmQtaWQgPSAiMCIKICAgICAgc3RhdGUgPSAiNCIKICAgICAgaGFuZGxlID0gIjAiCiAgICAg
IG1hYyA9ICIwMDoxNjozZToxMjowNDpmMCIKICAgICAgdHgtcmluZy1yZWYgPSAiNzY4Igog
ICAgICByeC1yaW5nLXJlZiA9ICI3NjkiCiAgICAgIGV2ZW50LWNoYW5uZWwgPSAiMTgiCiAg
ICAgIHJlcXVlc3QtcngtY29weSA9ICIxIgogICAgICBmZWF0dXJlLXJ4LW5vdGlmeSA9ICIx
IgogICAgICBmZWF0dXJlLXNnID0gIjEiCiAgICAgIGZlYXR1cmUtZ3NvLXRjcHY0ID0gIjEi
CiAgIGRhdGEgPSAiIgogICBjcHUgPSAiIgogICAgMCA9ICIiCiAgICAgYXZhaWxhYmlsaXR5
ID0gIm9ubGluZSIKICAgIDEgPSAiIgogICAgIGF2YWlsYWJpbGl0eSA9ICJvbmxpbmUiCiAg
IG1lbW9yeSA9ICIiCiAgICBzdGF0aWMtbWF4ID0gIjIwOTcxNTIiCiAgICB0YXJnZXQgPSAi
MjA4ODk2MCIKICAgIHZpZGVvcmFtID0gIjgxOTIiCiAgIGVycm9yID0gIiIKICAgZHJpdmVy
cyA9ICIiCiAgIGF0dHIgPSAiIgogICBtZXNzYWdlcyA9ICIiCiAgIGRvbWlkID0gIjkiCiAg
IHN0b3JlID0gIiIKICAgIHBvcnQgPSAiMyIKICAgIHJpbmctcmVmID0gIjEwNDQ0NzYiCiAg
IGNvbnNvbGUgPSAiIgogICAgYmFja2VuZCA9ICIvbG9jYWwvZG9tYWluLzAvYmFja2VuZC9j
b25zb2xlLzkvMCIKICAgIGJhY2tlbmQtaWQgPSAiMCIKICAgIGxpbWl0ID0gIjEwNDg1NzYi
CiAgICB0eXBlID0gInhlbmNvbnNvbGVkIgogICAgb3V0cHV0ID0gInB0eSIKICAgIHBvcnQg
PSAiNCIKICAgIHJpbmctcmVmID0gIjEwNDQ0NzkiCiAgICB0dHkgPSAiL2Rldi9wdHMvMCIK
ICAgIHZuYy1wb3J0ID0gIjU5MDAiCiAgICB2bmMtbGlzdGVuID0gIjAuMC4wLjAiCiAgIGlt
YWdlID0gIiIKICAgIGRldmljZS1tb2RlbC1waWQgPSAiNjc4NyIKICAgc2VyaWFsID0gIiIK
ICAgIDAgPSAiIgogICAgIHR0eSA9ICIvZGV2L3B0cy8xIgp2bSA9ICIiCiAwMDAwMDAwMC0w
MDAwLTAwMDAtMDAwMC0wMDAwMDAwMDAwMDAgPSAiIgogIG9uX3hlbmRfc3RvcCA9ICJpZ25v
cmUiCiAgcG9vbF9uYW1lID0gIlBvb2wtMCIKICBzaGFkb3dfbWVtb3J5ID0gIjAiCiAgdXVp
ZCA9ICIwMDAwMDAwMC0wMDAwLTAwMDAtMDAwMC0wMDAwMDAwMDAwMDAiCiAgb25fcmVib290
ID0gInJlc3RhcnQiCiAgaW1hZ2UgPSAiKGxpbnV4IChrZXJuZWwgJycpIChzdXBlcnBhZ2Vz
IDApIChub21pZ3JhdGUgMCkgKHRzY19tb2RlIDApKSIKICAgb3N0eXBlID0gImxpbnV4Igog
ICBrZXJuZWwgPSAiIgogICBjbWRsaW5lID0gIiIKICAgcmFtZGlzayA9ICIiCiAgb25fcG93
ZXJvZmYgPSAiZGVzdHJveSIKICBib290bG9hZGVyX2FyZ3MgPSAiIgogIG9uX3hlbmRfc3Rh
cnQgPSAiaWdub3JlIgogIG9uX2NyYXNoID0gInJlc3RhcnQiCiAgeGVuZCA9ICIiCiAgIHJl
c3RhcnRfY291bnQgPSAiMCIKICB2Y3B1cyA9ICI4IgogIHZjcHVfYXZhaWwgPSAiMjU1Igog
IGJvb3Rsb2FkZXIgPSAiIgogIG5hbWUgPSAiRG9tYWluLTAiCiA1ZGUxYzYxYS1jZWU4LTRj
MTgtYjI5NC00MDliOTIxNGY3YmUgPSAiIgogIHV1aWQgPSAiNWRlMWM2MWEtY2VlOC00YzE4
LWIyOTQtNDA5YjkyMTRmN2JlIgogIG5hbWUgPSAiUHJlY2lzZUhWTSIKICBwb29sX25hbWUg
PSAiUG9vbC0wIgogIHJ0YyA9ICIiCiAgIHRpbWVvZmZzZXQgPSAiIgogIGltYWdlID0gIiIK
ICAgb3N0eXBlID0gImxpbnV4IgogICBrZXJuZWwgPSAiIgogICBjbWRsaW5lID0gIiIKICAg
cmFtZGlzayA9ICIiCiAgc3RhcnRfdGltZSA9ICIxMzIyNzYwMTc2LjIyIgogIHZuY3Bhc3N3
ZCA9ICJcMDAwIgo=
--------------040709070607000105030506
Content-Type: text/plain;
 name="xm-run.txt"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename="xm-run.txt"

IDgxNjMgPyAgICAgICAgU0xsICAgIDA6MTEgL3Vzci9saWIveGVuLTQuMS9iaW4vcWVtdS1k
bSAtZCAxMiAtZG9tYWluLW5hbWUgUHJlY2lzZUhWTSAtdmlkZW9yYW0gNCAtayBkZSAtdm5j
IDAuMC4wLjA6MCAtdm5jdW51c2VkIC12Y3B1cyAyIC12Y3B1X2F2YWlsIDB4MyAtYm9vdCBj
ZCAtc2VyaWFsIHB0eSAtYWNwaSAtbmV0IG5pYyx2bGFuPTEsbWFjYWRkcj0wMDoxNjozZTox
MjowNDpmMCxtb2RlbD1ydGw4MTM5IC1uZXQgdGFwLHZsYW49MSxpZm5hbWU9dGFwMTIuMCxi
cmlkZ2U9dmlyYnIwIC1NIHhlbmZ2CgoKdG9vbCA9ICIiCiB4ZW5zdG9yZWQgPSAiIgpsb2Nh
bCA9ICIiCiBwb29sID0gIiIKICAwID0gIiIKICAgb3RoZXJfY29uZmlnID0gIiIKICAgZGVz
Y3JpcHRpb24gPSAiUG9vbC0wIgogICB1dWlkID0gImJlYmNlMTZmLTkwMmYtNjhjZS1kMzhi
LWE0ZDQ5ZTgzNDZhNyIKICAgbmFtZSA9ICJQb29sLTAiCiBkb21haW4gPSAiIgogIDAgPSAi
IgogICB2bSA9ICIvdm0vMDAwMDAwMDAtMDAwMC0wMDAwLTAwMDAtMDAwMDAwMDAwMDAwIgog
ICBkZXZpY2UgPSAiIgogICBjb250cm9sID0gIiIKICAgIHBsYXRmb3JtLWZlYXR1cmUtbXVs
dGlwcm9jZXNzb3Itc3VzcGVuZCA9ICIxIgogICBtZW1vcnkgPSAiIgogICAgdGFyZ2V0ID0g
IjUyNDI4OCIKICAgIHN0YXRpYy1tYXggPSAiNDI5NDk2NzI5MiIKICAgIGZyZWVtZW0tc2xh
Y2sgPSAiNTAzMjg4MCIKICAgZ3Vlc3QgPSAiIgogICBodm1wdiA9ICIiCiAgIGRhdGEgPSAi
IgogICBjcHUgPSAiIgogICAgMSA9ICIiCiAgICAgYXZhaWxhYmlsaXR5ID0gIm9ubGluZSIK
ICAgIDMgPSAiIgogICAgIGF2YWlsYWJpbGl0eSA9ICJvbmxpbmUiCiAgICAyID0gIiIKICAg
ICBhdmFpbGFiaWxpdHkgPSAib25saW5lIgogICAgNyA9ICIiCiAgICAgYXZhaWxhYmlsaXR5
ID0gIm9ubGluZSIKICAgIDAgPSAiIgogICAgIGF2YWlsYWJpbGl0eSA9ICJvbmxpbmUiCiAg
ICA1ID0gIiIKICAgICBhdmFpbGFiaWxpdHkgPSAib25saW5lIgogICAgNiA9ICIiCiAgICAg
YXZhaWxhYmlsaXR5ID0gIm9ubGluZSIKICAgIDQgPSAiIgogICAgIGF2YWlsYWJpbGl0eSA9
ICJvbmxpbmUiCiAgIGRlc2NyaXB0aW9uID0gIiIKICAgY29uc29sZSA9ICIiCiAgICBsaW1p
dCA9ICIxMDQ4NTc2IgogICAgdHlwZSA9ICJ4ZW5jb25zb2xlZCIKICAgZG9taWQgPSAiMCIK
ICAgbmFtZSA9ICJEb21haW4tMCIKICAgYmFja2VuZCA9ICIiCiAgICBxZGlzayA9ICIiCiAg
ICBjb25zb2xlID0gIiIKICAgICAyID0gIiIKICAgICA1ID0gIiIKICAgICA5ID0gIiIKICAg
ICAxMSA9ICIiCiAgICAgMTIgPSAiIgogICAgICAwID0gIiIKICAgICAgIGRvbWFpbiA9ICJQ
cmVjaXNlSFZNIgogICAgICAgcHJvdG9jb2wgPSAidnQxMDAiCiAgICAgICB1dWlkID0gIjVi
OWE1ZTMwLTFhNTItYjQ2Zi01YjY5LThkMzQxYjIxZTdjYyIKICAgICAgIGZyb250ZW5kID0g
Ii9sb2NhbC9kb21haW4vMTIvZGV2aWNlL2NvbnNvbGUvMCIKICAgICAgIHN0YXRlID0gIjIi
CiAgICAgICBsb2NhdGlvbiA9ICI0IgogICAgICAgb25saW5lID0gIjEiCiAgICAgICBmcm9u
dGVuZC1pZCA9ICIxMiIKICAgICAgIGhvdHBsdWctc3RhdHVzID0gImNvbm5lY3RlZCIKICAg
IHZpZiA9ICIiCiAgICAgMTIgPSAiIgogICAgICAwID0gIiIKICAgICAgIGJyaWRnZSA9ICJ2
aXJicjAiCiAgICAgICBkb21haW4gPSAiUHJlY2lzZUhWTSIKICAgICAgIGhhbmRsZSA9ICIw
IgogICAgICAgdXVpZCA9ICJlZDhjMjdhMS02ZDVlLTU4NDEtN2FjYi00MjZlNTkzYmE2NTci
CiAgICAgICBzY3JpcHQgPSAiL2V0Yy94ZW4vc2NyaXB0cy92aWYtYnJpZGdlIgogICAgICAg
c3RhdGUgPSAiNiIKICAgICAgIGZyb250ZW5kID0gIi9sb2NhbC9kb21haW4vMTIvZGV2aWNl
L3ZpZi8wIgogICAgICAgbWFjID0gIjAwOjE2OjNlOjEyOjA0OmYwIgogICAgICAgb25saW5l
ID0gIjEiCiAgICAgICBmcm9udGVuZC1pZCA9ICIxMiIKICAgICAgIHR5cGUgPSAiaW9lbXUi
CiAgICAgICBmZWF0dXJlLXNnID0gIjEiCiAgICAgICBmZWF0dXJlLWdzby10Y3B2NCA9ICIx
IgogICAgICAgZmVhdHVyZS1yeC1jb3B5ID0gIjEiCiAgICAgICBmZWF0dXJlLXJ4LWZsaXAg
PSAiMCIKICAgIHZmYiA9ICIiCiAgICAgMTIgPSAiIgogICAgICAwID0gIiIKICAgICAgIHZu
Y3VudXNlZCA9ICIxIgogICAgICAgZG9tYWluID0gIlByZWNpc2VIVk0iCiAgICAgICB2bmMg
PSAiMSIKICAgICAgIHV1aWQgPSAiYzRlYmI2MGUtZDIyYS0xNjdmLTNiN2EtZmMzMzc3M2Y4
NGRlIgogICAgICAgdm5jbGlzdGVuID0gIjAuMC4wLjAiCiAgICAgICB2bmNkaXNwbGF5ID0g
IjAiCiAgICAgICBmcm9udGVuZCA9ICIvbG9jYWwvZG9tYWluLzEyL2RldmljZS92ZmIvMCIK
ICAgICAgIHN0YXRlID0gIjEiCiAgICAgICBrZXltYXAgPSAiZGUiCiAgICAgICBvbmxpbmUg
PSAiMSIKICAgICAgIGZyb250ZW5kLWlkID0gIjEyIgogICAgICAgbG9jYXRpb24gPSAiMC4w
LjAuMDo1OTAwIgogICAgdmJkID0gIiIKICAgICAxMiA9ICIiCiAgICAgIDc2OCA9ICIiCiAg
ICAgICBkb21haW4gPSAiUHJlY2lzZUhWTSIKICAgICAgIGZyb250ZW5kID0gIi9sb2NhbC9k
b21haW4vMTIvZGV2aWNlL3ZiZC83NjgiCiAgICAgICB1dWlkID0gImZlNzM1M2ZhLTJmOWYt
OTk0My0xMGM3LTczOTAwMjM2NTU3MSIKICAgICAgIGJvb3RhYmxlID0gIjEiCiAgICAgICBk
ZXYgPSAiaGRhIgogICAgICAgc3RhdGUgPSAiNCIKICAgICAgIHBhcmFtcyA9ICIvcm9vdC9p
bnN0YW5jZXMvcHJlY2lzZS1zZXJ2ZXIvaGRhLTY0LmltZyIKICAgICAgIG1vZGUgPSAidyIK
ICAgICAgIG9ubGluZSA9ICIxIgogICAgICAgZnJvbnRlbmQtaWQgPSAiMTIiCiAgICAgICB0
eXBlID0gImZpbGUiCiAgICAgICBub2RlID0gIi9kZXYvbG9vcDEiCiAgICAgICBwaHlzaWNh
bC1kZXZpY2UgPSAiNzoxIgogICAgICAgaG90cGx1Zy1zdGF0dXMgPSAiY29ubmVjdGVkIgog
ICAgICAgZmVhdHVyZS1mbHVzaC1jYWNoZSA9ICIxIgogICAgICAgc2VjdG9ycyA9ICIxNjM4
NDAwMCIKICAgICAgIGluZm8gPSAiMCIKICAgICAgIHNlY3Rvci1zaXplID0gIjUxMiIKICAg
ICAgNTYzMiA9ICIiCiAgICAgICBkb21haW4gPSAiUHJlY2lzZUhWTSIKICAgICAgIGZyb250
ZW5kID0gIi9sb2NhbC9kb21haW4vMTIvZGV2aWNlL3ZiZC81NjMyIgogICAgICAgdXVpZCA9
ICJkM2ExYTY0My02NWM0LTZkMzEtNDFiYy03ODZiYjRkNmNmZWEiCiAgICAgICBib290YWJs
ZSA9ICIwIgogICAgICAgZGV2ID0gImhkYyIKICAgICAgIHN0YXRlID0gIjYiCiAgICAgICBw
YXJhbXMgPSAiL3Jvb3QvaXNvcy9wcmVjaXNlLXNlcnZlci1hbWQ2NC5pc28iCiAgICAgICBt
b2RlID0gInIiCiAgICAgICBvbmxpbmUgPSAiMSIKICAgICAgIGZyb250ZW5kLWlkID0gIjEy
IgogICAgICAgdHlwZSA9ICJmaWxlIgogICAgICAgbm9kZSA9ICIvZGV2L2xvb3AwIgogICAg
ICAgcGh5c2ljYWwtZGV2aWNlID0gIjc6MCIKICAgICAgIGhvdHBsdWctc3RhdHVzID0gImNv
bm5lY3RlZCIKICAgZGV2aWNlLW1vZGVsID0gIiIKICAgIDEyID0gIiIKICAgICBkaXNhYmxl
X3BmID0gIjAiCiAgICAgc3RhdGUgPSAicnVubmluZyIKICAxMiA9ICIiCiAgIHZtID0gIi92
bS9hZDA5NTJkNy01OWFhLWYxODUtYTRlMy05YWQzMjM0ZTk4NzEiCiAgIGRldmljZSA9ICIi
CiAgICB2ZmIgPSAiIgogICAgIDAgPSAiIgogICAgICBzdGF0ZSA9ICIxIgogICAgICBiYWNr
ZW5kLWlkID0gIjAiCiAgICAgIGJhY2tlbmQgPSAiL2xvY2FsL2RvbWFpbi8wL2JhY2tlbmQv
dmZiLzEyLzAiCiAgICB2YmQgPSAiIgogICAgIDc2OCA9ICIiCiAgICAgIGJhY2tlbmQtaWQg
PSAiMCIKICAgICAgdmlydHVhbC1kZXZpY2UgPSAiNzY4IgogICAgICBkZXZpY2UtdHlwZSA9
ICJkaXNrIgogICAgICBzdGF0ZSA9ICI0IgogICAgICBiYWNrZW5kID0gIi9sb2NhbC9kb21h
aW4vMC9iYWNrZW5kL3ZiZC8xMi83NjgiCiAgICAgIHJpbmctcmVmID0gIjgiCiAgICAgIGV2
ZW50LWNoYW5uZWwgPSAiMTciCiAgICAgIHByb3RvY29sID0gIng4Nl82NC1hYmkiCiAgICAg
NTYzMiA9ICIiCiAgICAgIGJhY2tlbmQtaWQgPSAiMCIKICAgICAgdmlydHVhbC1kZXZpY2Ug
PSAiNTYzMiIKICAgICAgZGV2aWNlLXR5cGUgPSAiY2Ryb20iCiAgICAgIHN0YXRlID0gIjYi
CiAgICAgIGJhY2tlbmQgPSAiL2xvY2FsL2RvbWFpbi8wL2JhY2tlbmQvdmJkLzEyLzU2MzIi
CiAgICB2aWYgPSAiIgogICAgIDAgPSAiIgogICAgICBzdGF0ZSA9ICI2IgogICAgICBiYWNr
ZW5kLWlkID0gIjAiCiAgICAgIGJhY2tlbmQgPSAiL2xvY2FsL2RvbWFpbi8wL2JhY2tlbmQv
dmlmLzEyLzAiCiAgICBjb25zb2xlID0gIiIKICAgICAwID0gIiIKICAgICAgc3RhdGUgPSAi
MSIKICAgICAgYmFja2VuZC1pZCA9ICIwIgogICAgICBiYWNrZW5kID0gIi9sb2NhbC9kb21h
aW4vMC9iYWNrZW5kL2NvbnNvbGUvMTIvMCIKICAgY29udHJvbCA9ICIiCiAgICBwbGF0Zm9y
bS1mZWF0dXJlLW11bHRpcHJvY2Vzc29yLXN1c3BlbmQgPSAiMSIKICAgZXJyb3IgPSAiIgog
ICAgZGV2aWNlID0gIiIKICAgICB2YmQgPSAiIgogICAgICA1NjMyID0gIiIKICAgICAgIGVy
cm9yID0gIjE5IHhlbmJ1c19kZXZfcHJvYmUgb24gZGV2aWNlL3ZiZC81NjMyIgogICAgIHZp
ZiA9ICIiCiAgICAgIDAgPSAiIgogICAgICAgZXJyb3IgPSAiMiBwYXJzaW5nIGRldmljZS92
aWYvMC9tYWMiCiAgIG1lbW9yeSA9ICIiCiAgICB0YXJnZXQgPSAiMjA5NzE1MiIKICAgZ3Vl
c3QgPSAiIgogICBodm1wdiA9ICIiCiAgIGRhdGEgPSAiIgogICBkZXZpY2UtbWlzYyA9ICIi
CiAgICB2aWYgPSAiIgogICAgIG5leHREZXZpY2VJRCA9ICIxIgogICAgY29uc29sZSA9ICIi
CiAgICAgbmV4dERldmljZUlEID0gIjEiCiAgIGltYWdlID0gIiIKICAgIGRldmljZS1tb2Rl
bC1maWZvID0gIi92YXIvcnVuL3hlbmQvZG0tMTItMTMyMjc2MTA0NC5maWZvIgogICAgZGV2
aWNlLW1vZGVsLXBpZCA9ICI4MTYzIgogICAgc3VzcGVuZC1jYW5jZWwgPSAiMSIKICAgY29u
c29sZSA9ICIiCiAgICBwb3J0ID0gIjQiCiAgICBsaW1pdCA9ICIxMDQ4NTc2IgogICAgdHlw
ZSA9ICJpb2VtdSIKICAgIHR0eSA9ICIvZGV2L3B0cy8xIgogICAgdm5jLXBvcnQgPSAiNTkw
MCIKICAgIHZuYy1saXN0ZW4gPSAiMC4wLjAuMCIKICAgZGVzY3JpcHRpb24gPSAiIgogICBk
b21pZCA9ICIxMiIKICAgY3B1ID0gIiIKICAgIDAgPSAiIgogICAgIGF2YWlsYWJpbGl0eSA9
ICJvbmxpbmUiCiAgICAxID0gIiIKICAgICBhdmFpbGFiaWxpdHkgPSAib25saW5lIgogICBz
dG9yZSA9ICIiCiAgICByaW5nLXJlZiA9ICIxMDQ0NDc2IgogICAgcG9ydCA9ICIzIgogICBu
YW1lID0gIlByZWNpc2VIVk0iCiAgIHNlcmlhbCA9ICIiCiAgICAwID0gIiIKICAgICB0dHkg
PSAiL2Rldi9wdHMvMCIKdm0gPSAiIgogMDAwMDAwMDAtMDAwMC0wMDAwLTAwMDAtMDAwMDAw
MDAwMDAwID0gIiIKICBvbl94ZW5kX3N0b3AgPSAiaWdub3JlIgogIHBvb2xfbmFtZSA9ICJQ
b29sLTAiCiAgc2hhZG93X21lbW9yeSA9ICIwIgogIHV1aWQgPSAiMDAwMDAwMDAtMDAwMC0w
MDAwLTAwMDAtMDAwMDAwMDAwMDAwIgogIG9uX3JlYm9vdCA9ICJyZXN0YXJ0IgogIGltYWdl
ID0gIihsaW51eCAoa2VybmVsICcnKSAoc3VwZXJwYWdlcyAwKSAobm9taWdyYXRlIDApICh0
c2NfbW9kZSAwKSkiCiAgIG9zdHlwZSA9ICJsaW51eCIKICAga2VybmVsID0gIiIKICAgY21k
bGluZSA9ICIiCiAgIHJhbWRpc2sgPSAiIgogIG9uX3Bvd2Vyb2ZmID0gImRlc3Ryb3kiCiAg
Ym9vdGxvYWRlcl9hcmdzID0gIiIKICBvbl94ZW5kX3N0YXJ0ID0gImlnbm9yZSIKICBvbl9j
cmFzaCA9ICJyZXN0YXJ0IgogIHhlbmQgPSAiIgogICByZXN0YXJ0X2NvdW50ID0gIjAiCiAg
dmNwdXMgPSAiOCIKICB2Y3B1X2F2YWlsID0gIjI1NSIKICBib290bG9hZGVyID0gIiIKICBu
YW1lID0gIkRvbWFpbi0wIgogYWQwOTUyZDctNTlhYS1mMTg1LWE0ZTMtOWFkMzIzNGU5ODcx
ID0gIiIKICBpbWFnZSA9ICIoaHZtIChrZXJuZWwgJycpIChzdXBlcnBhZ2VzIDApICh2aWRl
b3JhbSA0KSAoaHBldCAwKSAoc3RkdmdhIDApIFwuLi4iCiAgIG9zdHlwZSA9ICJodm0iCiAg
IGtlcm5lbCA9ICIiCiAgIGNtZGxpbmUgPSAiIgogICByYW1kaXNrID0gIiIKICAgZG1hcmdz
ID0gIi1kb21haW4tbmFtZSBQcmVjaXNlSFZNIC12aWRlb3JhbSA0IC1rIGRlIC12bmMgMC4w
LjAuMDowIC12bmN1blwuLi4iCiAgIGRldmljZS1tb2RlbCA9ICIvdXNyL2xpYi94ZW4tNC4x
L2Jpbi9xZW11LWRtIgogICBkaXNwbGF5ID0gIiIKICBydGMgPSAiIgogICB0aW1lb2Zmc2V0
ID0gIjAiCiAgZGV2aWNlID0gIiIKICAgdmZiID0gIiIKICAgIDAgPSAiIgogICAgIGZyb250
ZW5kID0gIi9sb2NhbC9kb21haW4vMTIvZGV2aWNlL3ZmYi8wIgogICAgIGZyb250ZW5kLWlk
ID0gIjEyIgogICAgIGJhY2tlbmQtaWQgPSAiMCIKICAgICBiYWNrZW5kID0gIi9sb2NhbC9k
b21haW4vMC9iYWNrZW5kL3ZmYi8xMi8wIgogICB2YmQgPSAiIgogICAgNzY4ID0gIiIKICAg
ICBmcm9udGVuZCA9ICIvbG9jYWwvZG9tYWluLzEyL2RldmljZS92YmQvNzY4IgogICAgIGZy
b250ZW5kLWlkID0gIjEyIgogICAgIGJhY2tlbmQtaWQgPSAiMCIKICAgICBiYWNrZW5kID0g
Ii9sb2NhbC9kb21haW4vMC9iYWNrZW5kL3ZiZC8xMi83NjgiCiAgICA1NjMyID0gIiIKICAg
ICBmcm9udGVuZCA9ICIvbG9jYWwvZG9tYWluLzEyL2RldmljZS92YmQvNTYzMiIKICAgICBm
cm9udGVuZC1pZCA9ICIxMiIKICAgICBiYWNrZW5kLWlkID0gIjAiCiAgICAgYmFja2VuZCA9
ICIvbG9jYWwvZG9tYWluLzAvYmFja2VuZC92YmQvMTIvNTYzMiIKICAgdmlmID0gIiIKICAg
IDAgPSAiIgogICAgIGZyb250ZW5kID0gIi9sb2NhbC9kb21haW4vMTIvZGV2aWNlL3ZpZi8w
IgogICAgIGZyb250ZW5kLWlkID0gIjEyIgogICAgIGJhY2tlbmQtaWQgPSAiMCIKICAgICBi
YWNrZW5kID0gIi9sb2NhbC9kb21haW4vMC9iYWNrZW5kL3ZpZi8xMi8wIgogICBjb25zb2xl
ID0gIiIKICAgIDAgPSAiIgogICAgIGZyb250ZW5kID0gIi9sb2NhbC9kb21haW4vMTIvZGV2
aWNlL2NvbnNvbGUvMCIKICAgICBmcm9udGVuZC1pZCA9ICIxMiIKICAgICBiYWNrZW5kLWlk
ID0gIjAiCiAgICAgYmFja2VuZCA9ICIvbG9jYWwvZG9tYWluLzAvYmFja2VuZC9jb25zb2xl
LzEyLzAiCiAgb25feGVuZF9zdG9wID0gImlnbm9yZSIKICBwb29sX25hbWUgPSAiUG9vbC0w
IgogIHNoYWRvd19tZW1vcnkgPSAiMTgiCiAgdXVpZCA9ICJhZDA5NTJkNy01OWFhLWYxODUt
YTRlMy05YWQzMjM0ZTk4NzEiCiAgb25fcmVib290ID0gInJlc3RhcnQiCiAgc3RhcnRfdGlt
ZSA9ICIxMzIyNzYxMDQ0LjQ4IgogIG9uX3Bvd2Vyb2ZmID0gImRlc3Ryb3kiCiAgYm9vdGxv
YWRlcl9hcmdzID0gIiIKICBvbl94ZW5kX3N0YXJ0ID0gImlnbm9yZSIKICBvbl9jcmFzaCA9
ICJyZXN0YXJ0IgogIHhlbmQgPSAiIgogICByZXN0YXJ0X2NvdW50ID0gIjAiCiAgdmNwdXMg
PSAiMiIKICB2Y3B1X2F2YWlsID0gIjMiCiAgYm9vdGxvYWRlciA9ICIiCiAgbmFtZSA9ICJQ
cmVjaXNlSFZNIgo=
--------------040709070607000105030506
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--------------040709070607000105030506--


From xen-devel-bounces@lists.xensource.com Thu Dec 01 17:48:17 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 17:48:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWAjp-0000a7-CL; Thu, 01 Dec 2011 17:48:01 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <stefan.bader@canonical.com>) id 1RWAjn-0000a2-SQ
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 17:48:00 +0000
X-Env-Sender: stefan.bader@canonical.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1322761635!4976555!1
X-Originating-IP: [91.189.89.112]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8069 invoked from network); 1 Dec 2011 17:47:16 -0000
Received: from youngberry.canonical.com (HELO youngberry.canonical.com)
	(91.189.89.112) by server-13.tower-182.messagelabs.com with SMTP;
	1 Dec 2011 17:47:16 -0000
Received: from p5b2e33b7.dip.t-dialin.net ([91.46.51.183] helo=[192.168.2.5])
	by youngberry.canonical.com with esmtpsa
	(TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71)
	(envelope-from <stefan.bader@canonical.com>)
	id 1RWAj4-0001f7-AS; Thu, 01 Dec 2011 17:47:14 +0000
Message-ID: <4ED7BDA0.8050208@canonical.com>
Date: Thu, 01 Dec 2011 18:47:12 +0100
From: Stefan Bader <stefan.bader@canonical.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:8.0) Gecko/20111124 Thunderbird/8.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <4ED798B2.1040309@canonical.com>
	<1322755432.31810.244.camel@zakaz.uk.xensource.com>
In-Reply-To: <1322755432.31810.244.camel@zakaz.uk.xensource.com>
X-Enigmail-Version: 1.4a1pre
Content-Type: multipart/mixed; boundary="------------040709070607000105030506"
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Xen 4.x / Linux 3.x (dom0 and HVM domU) and NIC
	handling
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a multi-part message in MIME format.
--------------040709070607000105030506
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 01.12.2011 17:03, Ian Campbell wrote:
> On Thu, 2011-12-01 at 15:09 +0000, Stefan Bader wrote:
>> Moving to public discussion...
>>
>> This was found with Xen hypervisor version supporting device unplugging and the
>> domU kernel having net-/blkfront and pci platform built-in (or as module).
>>
>> The block device is defined as hda and the NIC type=ioemu (so theoretically
>> guests without pv support would work, too).
>>
>> Since both drivers are present, the kernel tries to unplug the emulated devices
>> and succeeds. The blkfront driver detects the xvda device available in parallel
>> and is working ok.
>>
>> However the network interface does not work. There are entries present under
>> sysfs for the xenbus but trying to bring it up fails with errors. And also there
>> seems to be no mac address set (all zeros in sysfs).
>> When the type=ioemu is removed in the configuration, this works.
> 
> Which toolstack are you using?
> 
xm (xl with the same config seems to work)

> The weird thing is that, at least with xl, type=ioemu is the default for
> an HVM guest.
> 
> What vif related entries do you get in xenstore, both front and backend?
> 
output of xenstore-ls attached (hopefully contains all info)

> Also what does your qemu-dm command line end up looking like?
> 
also in the attached file.

>> I have not much more debugging information beyond that, yet. But it sounds a bit
>> like NICs should behave the same as block devices. So if there is an emulated
>> device defined there will be an alternate paravirt interface for it and after
>> unplugging the emulated ones we end up with the pv ones.
> 
> That is certainly the expectation.
> 
>> Is that something that can be seen with newer Xen versions, too (I am using 4.1.1)?
> 
> I appear to have some other problem with xen-unstable at the moment.
> I've never noticed a problem in that past, although I don't habitually
> use type=XXX at all in my vif configuration.
> 
> Ian.
> 
>> -Stefan
> 
> 


--------------040709070607000105030506
Content-Type: text/plain;
 name="xl-run.txt"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename="xl-run.txt"

IDc3ODQgPyAgICAgICAgU0xzbCAgIDA6MTMgcWVtdS1kbSAtZCA5IC1kb21haW4tbmFtZSBQ
cmVjaXNlSFZNIC12bmMgMC4wLjAuMDowIC12bmN1bnVzZWQgLWsgZGUgLXNlcmlhbCBwdHkg
LXZpZGVvcmFtIDggLWJvb3QgY2QgLWFjcGkgLXZjcHVzIDIgLXZjcHVfYXZhaWwgMHgzIC1u
ZXQgbmljLHZsYW49MCxtYWNhZGRyPTAwOjE2OjNlOjEyOjA0OmYwLG1vZGVsPXJ0bDgxMzkg
LW5ldCB0YXAsdmxhbj0wLGlmbmFtZT10YXA5LjAsYnJpZGdlPXZpcmJyMCxzY3JpcHQ9bm8g
LU0geGVuZnYKIDc4OTUgaHZjMCAgICAgUysgICAgIDA6MDAgZ3JlcCAtLWNvbG9yPWF1dG8g
cWVtdS1kbQoKdG9vbCA9ICIiCiB4ZW5zdG9yZWQgPSAiIgpsb2NhbCA9ICIiCiBwb29sID0g
IiIKICAwID0gIiIKICAgb3RoZXJfY29uZmlnID0gIiIKICAgZGVzY3JpcHRpb24gPSAiUG9v
bC0wIgogICB1dWlkID0gImJlYmNlMTZmLTkwMmYtNjhjZS1kMzhiLWE0ZDQ5ZTgzNDZhNyIK
ICAgbmFtZSA9ICJQb29sLTAiCiBkb21haW4gPSAiIgogIDAgPSAiIgogICB2bSA9ICIvdm0v
MDAwMDAwMDAtMDAwMC0wMDAwLTAwMDAtMDAwMDAwMDAwMDAwIgogICBkZXZpY2UgPSAiIgog
ICBjb250cm9sID0gIiIKICAgIHBsYXRmb3JtLWZlYXR1cmUtbXVsdGlwcm9jZXNzb3Itc3Vz
cGVuZCA9ICIxIgogICBtZW1vcnkgPSAiIgogICAgdGFyZ2V0ID0gIjUyNDI4OCIKICAgIHN0
YXRpYy1tYXggPSAiNDI5NDk2NzI5MiIKICAgIGZyZWVtZW0tc2xhY2sgPSAiNTAzMjg4MCIK
ICAgZ3Vlc3QgPSAiIgogICBodm1wdiA9ICIiCiAgIGRhdGEgPSAiIgogICBjcHUgPSAiIgog
ICAgMSA9ICIiCiAgICAgYXZhaWxhYmlsaXR5ID0gIm9ubGluZSIKICAgIDMgPSAiIgogICAg
IGF2YWlsYWJpbGl0eSA9ICJvbmxpbmUiCiAgICAyID0gIiIKICAgICBhdmFpbGFiaWxpdHkg
PSAib25saW5lIgogICAgNyA9ICIiCiAgICAgYXZhaWxhYmlsaXR5ID0gIm9ubGluZSIKICAg
IDAgPSAiIgogICAgIGF2YWlsYWJpbGl0eSA9ICJvbmxpbmUiCiAgICA1ID0gIiIKICAgICBh
dmFpbGFiaWxpdHkgPSAib25saW5lIgogICAgNiA9ICIiCiAgICAgYXZhaWxhYmlsaXR5ID0g
Im9ubGluZSIKICAgIDQgPSAiIgogICAgIGF2YWlsYWJpbGl0eSA9ICJvbmxpbmUiCiAgIGRl
c2NyaXB0aW9uID0gIiIKICAgY29uc29sZSA9ICIiCiAgICBsaW1pdCA9ICIxMDQ4NTc2Igog
ICAgdHlwZSA9ICJ4ZW5jb25zb2xlZCIKICAgZG9taWQgPSAiMCIKICAgbmFtZSA9ICJEb21h
aW4tMCIKICAgYmFja2VuZCA9ICIiCiAgICBxZGlzayA9ICIiCiAgICAgOSA9ICIiCiAgICAg
IDc2OCA9ICIiCiAgICAgICBmcm9udGVuZCA9ICIvbG9jYWwvZG9tYWluLzkvZGV2aWNlL3Zi
ZC83NjgiCiAgICAgICBwYXJhbXMgPSAiYWlvOi9yb290L2luc3RhbmNlcy9wcmVjaXNlLXNl
cnZlci9oZGEtNjQuaW1nIgogICAgICAgZnJvbnRlbmQtaWQgPSAiOSIKICAgICAgIG9ubGlu
ZSA9ICIxIgogICAgICAgcmVtb3ZhYmxlID0gIjAiCiAgICAgICBib290YWJsZSA9ICIxIgog
ICAgICAgc3RhdGUgPSAiNCIKICAgICAgIGRldiA9ICJoZGEiCiAgICAgICB0eXBlID0gInRh
cCIKICAgICAgIG1vZGUgPSAidyIKICAgICAgIGZlYXR1cmUtYmFycmllciA9ICIxIgogICAg
ICAgaW5mbyA9ICIwIgogICAgICAgc2VjdG9yLXNpemUgPSAiNTEyIgogICAgICAgc2VjdG9y
cyA9ICIxNjM4NDAwMCIKICAgICAgIGhvdHBsdWctc3RhdHVzID0gImNvbm5lY3RlZCIKICAg
ICAgNTYzMiA9ICIiCiAgICAgICBmcm9udGVuZCA9ICIvbG9jYWwvZG9tYWluLzkvZGV2aWNl
L3ZiZC81NjMyIgogICAgICAgcGFyYW1zID0gImFpbzovcm9vdC9pc29zL3ByZWNpc2Utc2Vy
dmVyLWFtZDY0LmlzbyIKICAgICAgIGZyb250ZW5kLWlkID0gIjkiCiAgICAgICBvbmxpbmUg
PSAiMSIKICAgICAgIHJlbW92YWJsZSA9ICIxIgogICAgICAgYm9vdGFibGUgPSAiMSIKICAg
ICAgIHN0YXRlID0gIjYiCiAgICAgICBkZXYgPSAiaGRjIgogICAgICAgdHlwZSA9ICJ0YXAi
CiAgICAgICBtb2RlID0gInIiCiAgICAgICBmZWF0dXJlLWJhcnJpZXIgPSAiMSIKICAgICAg
IGluZm8gPSAiNCIKICAgICAgIHNlY3Rvci1zaXplID0gIjUxMiIKICAgICAgIHNlY3RvcnMg
PSAiMTMzNzk0NCIKICAgICAgIGhvdHBsdWctc3RhdHVzID0gImNvbm5lY3RlZCIKICAgIGNv
bnNvbGUgPSAiIgogICAgIDIgPSAiIgogICAgIDUgPSAiIgogICAgIDkgPSAiIgogICAgICAw
ID0gIiIKICAgICAgIGZyb250ZW5kID0gIi9sb2NhbC9kb21haW4vOS9jb25zb2xlIgogICAg
ICAgZnJvbnRlbmQtaWQgPSAiOSIKICAgICAgIG9ubGluZSA9ICIxIgogICAgICAgc3RhdGUg
PSAiMSIKICAgICAgIGRvbWFpbiA9ICJQcmVjaXNlSFZNIgogICAgICAgcHJvdG9jb2wgPSAi
dnQxMDAiCiAgICB2aWYgPSAiIgogICAgIDkgPSAiIgogICAgICAwID0gIiIKICAgICAgIGZy
b250ZW5kID0gIi9sb2NhbC9kb21haW4vOS9kZXZpY2UvdmlmLzAiCiAgICAgICBmcm9udGVu
ZC1pZCA9ICI5IgogICAgICAgb25saW5lID0gIjEiCiAgICAgICBzdGF0ZSA9ICI0IgogICAg
ICAgc2NyaXB0ID0gIi9ldGMveGVuL3NjcmlwdHMvdmlmLWJyaWRnZSIKICAgICAgIG1hYyA9
ICIwMDoxNjozZToxMjowNDpmMCIKICAgICAgIGJyaWRnZSA9ICJ2aXJicjAiCiAgICAgICBo
YW5kbGUgPSAiMCIKICAgICAgIGZlYXR1cmUtc2cgPSAiMSIKICAgICAgIGZlYXR1cmUtZ3Nv
LXRjcHY0ID0gIjEiCiAgICAgICBmZWF0dXJlLXJ4LWNvcHkgPSAiMSIKICAgICAgIGZlYXR1
cmUtcngtZmxpcCA9ICIwIgogICAgICAgaG90cGx1Zy1zdGF0dXMgPSAiY29ubmVjdGVkIgog
ICBkZXZpY2UtbW9kZWwgPSAiIgogICAgOSA9ICIiCiAgICAgZGlzYWJsZV9wZiA9ICIwIgog
ICAgIHN0YXRlID0gInJ1bm5pbmciCiAgOSA9ICIiCiAgIHZtID0gIi92bS81ZGUxYzYxYS1j
ZWU4LTRjMTgtYjI5NC00MDliOTIxNGY3YmUiCiAgIG5hbWUgPSAiUHJlY2lzZUhWTSIKICAg
Y29udHJvbCA9ICIiCiAgICBzaHV0ZG93biA9ICIiCiAgICBwbGF0Zm9ybS1mZWF0dXJlLW11
bHRpcHJvY2Vzc29yLXN1c3BlbmQgPSAiMSIKICAgZGV2aWNlID0gIiIKICAgIHN1c3BlbmQg
PSAiIgogICAgIGV2ZW50LWNoYW5uZWwgPSAiIgogICAgdmJkID0gIiIKICAgICA3NjggPSAi
IgogICAgICBiYWNrZW5kID0gIi9sb2NhbC9kb21haW4vMC9iYWNrZW5kL3FkaXNrLzkvNzY4
IgogICAgICBiYWNrZW5kLWlkID0gIjAiCiAgICAgIHN0YXRlID0gIjQiCiAgICAgIHZpcnR1
YWwtZGV2aWNlID0gIjc2OCIKICAgICAgZGV2aWNlLXR5cGUgPSAiZGlzayIKICAgICAgcmlu
Zy1yZWYgPSAiOCIKICAgICAgZXZlbnQtY2hhbm5lbCA9ICIxNyIKICAgICAgcHJvdG9jb2wg
PSAieDg2XzY0LWFiaSIKICAgICA1NjMyID0gIiIKICAgICAgYmFja2VuZCA9ICIvbG9jYWwv
ZG9tYWluLzAvYmFja2VuZC9xZGlzay85LzU2MzIiCiAgICAgIGJhY2tlbmQtaWQgPSAiMCIK
ICAgICAgc3RhdGUgPSAiNiIKICAgICAgdmlydHVhbC1kZXZpY2UgPSAiNTYzMiIKICAgICAg
ZGV2aWNlLXR5cGUgPSAiY2Ryb20iCiAgICB2aWYgPSAiIgogICAgIDAgPSAiIgogICAgICBi
YWNrZW5kID0gIi9sb2NhbC9kb21haW4vMC9iYWNrZW5kL3ZpZi85LzAiCiAgICAgIGJhY2tl
bmQtaWQgPSAiMCIKICAgICAgc3RhdGUgPSAiNCIKICAgICAgaGFuZGxlID0gIjAiCiAgICAg
IG1hYyA9ICIwMDoxNjozZToxMjowNDpmMCIKICAgICAgdHgtcmluZy1yZWYgPSAiNzY4Igog
ICAgICByeC1yaW5nLXJlZiA9ICI3NjkiCiAgICAgIGV2ZW50LWNoYW5uZWwgPSAiMTgiCiAg
ICAgIHJlcXVlc3QtcngtY29weSA9ICIxIgogICAgICBmZWF0dXJlLXJ4LW5vdGlmeSA9ICIx
IgogICAgICBmZWF0dXJlLXNnID0gIjEiCiAgICAgIGZlYXR1cmUtZ3NvLXRjcHY0ID0gIjEi
CiAgIGRhdGEgPSAiIgogICBjcHUgPSAiIgogICAgMCA9ICIiCiAgICAgYXZhaWxhYmlsaXR5
ID0gIm9ubGluZSIKICAgIDEgPSAiIgogICAgIGF2YWlsYWJpbGl0eSA9ICJvbmxpbmUiCiAg
IG1lbW9yeSA9ICIiCiAgICBzdGF0aWMtbWF4ID0gIjIwOTcxNTIiCiAgICB0YXJnZXQgPSAi
MjA4ODk2MCIKICAgIHZpZGVvcmFtID0gIjgxOTIiCiAgIGVycm9yID0gIiIKICAgZHJpdmVy
cyA9ICIiCiAgIGF0dHIgPSAiIgogICBtZXNzYWdlcyA9ICIiCiAgIGRvbWlkID0gIjkiCiAg
IHN0b3JlID0gIiIKICAgIHBvcnQgPSAiMyIKICAgIHJpbmctcmVmID0gIjEwNDQ0NzYiCiAg
IGNvbnNvbGUgPSAiIgogICAgYmFja2VuZCA9ICIvbG9jYWwvZG9tYWluLzAvYmFja2VuZC9j
b25zb2xlLzkvMCIKICAgIGJhY2tlbmQtaWQgPSAiMCIKICAgIGxpbWl0ID0gIjEwNDg1NzYi
CiAgICB0eXBlID0gInhlbmNvbnNvbGVkIgogICAgb3V0cHV0ID0gInB0eSIKICAgIHBvcnQg
PSAiNCIKICAgIHJpbmctcmVmID0gIjEwNDQ0NzkiCiAgICB0dHkgPSAiL2Rldi9wdHMvMCIK
ICAgIHZuYy1wb3J0ID0gIjU5MDAiCiAgICB2bmMtbGlzdGVuID0gIjAuMC4wLjAiCiAgIGlt
YWdlID0gIiIKICAgIGRldmljZS1tb2RlbC1waWQgPSAiNjc4NyIKICAgc2VyaWFsID0gIiIK
ICAgIDAgPSAiIgogICAgIHR0eSA9ICIvZGV2L3B0cy8xIgp2bSA9ICIiCiAwMDAwMDAwMC0w
MDAwLTAwMDAtMDAwMC0wMDAwMDAwMDAwMDAgPSAiIgogIG9uX3hlbmRfc3RvcCA9ICJpZ25v
cmUiCiAgcG9vbF9uYW1lID0gIlBvb2wtMCIKICBzaGFkb3dfbWVtb3J5ID0gIjAiCiAgdXVp
ZCA9ICIwMDAwMDAwMC0wMDAwLTAwMDAtMDAwMC0wMDAwMDAwMDAwMDAiCiAgb25fcmVib290
ID0gInJlc3RhcnQiCiAgaW1hZ2UgPSAiKGxpbnV4IChrZXJuZWwgJycpIChzdXBlcnBhZ2Vz
IDApIChub21pZ3JhdGUgMCkgKHRzY19tb2RlIDApKSIKICAgb3N0eXBlID0gImxpbnV4Igog
ICBrZXJuZWwgPSAiIgogICBjbWRsaW5lID0gIiIKICAgcmFtZGlzayA9ICIiCiAgb25fcG93
ZXJvZmYgPSAiZGVzdHJveSIKICBib290bG9hZGVyX2FyZ3MgPSAiIgogIG9uX3hlbmRfc3Rh
cnQgPSAiaWdub3JlIgogIG9uX2NyYXNoID0gInJlc3RhcnQiCiAgeGVuZCA9ICIiCiAgIHJl
c3RhcnRfY291bnQgPSAiMCIKICB2Y3B1cyA9ICI4IgogIHZjcHVfYXZhaWwgPSAiMjU1Igog
IGJvb3Rsb2FkZXIgPSAiIgogIG5hbWUgPSAiRG9tYWluLTAiCiA1ZGUxYzYxYS1jZWU4LTRj
MTgtYjI5NC00MDliOTIxNGY3YmUgPSAiIgogIHV1aWQgPSAiNWRlMWM2MWEtY2VlOC00YzE4
LWIyOTQtNDA5YjkyMTRmN2JlIgogIG5hbWUgPSAiUHJlY2lzZUhWTSIKICBwb29sX25hbWUg
PSAiUG9vbC0wIgogIHJ0YyA9ICIiCiAgIHRpbWVvZmZzZXQgPSAiIgogIGltYWdlID0gIiIK
ICAgb3N0eXBlID0gImxpbnV4IgogICBrZXJuZWwgPSAiIgogICBjbWRsaW5lID0gIiIKICAg
cmFtZGlzayA9ICIiCiAgc3RhcnRfdGltZSA9ICIxMzIyNzYwMTc2LjIyIgogIHZuY3Bhc3N3
ZCA9ICJcMDAwIgo=
--------------040709070607000105030506
Content-Type: text/plain;
 name="xm-run.txt"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename="xm-run.txt"

IDgxNjMgPyAgICAgICAgU0xsICAgIDA6MTEgL3Vzci9saWIveGVuLTQuMS9iaW4vcWVtdS1k
bSAtZCAxMiAtZG9tYWluLW5hbWUgUHJlY2lzZUhWTSAtdmlkZW9yYW0gNCAtayBkZSAtdm5j
IDAuMC4wLjA6MCAtdm5jdW51c2VkIC12Y3B1cyAyIC12Y3B1X2F2YWlsIDB4MyAtYm9vdCBj
ZCAtc2VyaWFsIHB0eSAtYWNwaSAtbmV0IG5pYyx2bGFuPTEsbWFjYWRkcj0wMDoxNjozZTox
MjowNDpmMCxtb2RlbD1ydGw4MTM5IC1uZXQgdGFwLHZsYW49MSxpZm5hbWU9dGFwMTIuMCxi
cmlkZ2U9dmlyYnIwIC1NIHhlbmZ2CgoKdG9vbCA9ICIiCiB4ZW5zdG9yZWQgPSAiIgpsb2Nh
bCA9ICIiCiBwb29sID0gIiIKICAwID0gIiIKICAgb3RoZXJfY29uZmlnID0gIiIKICAgZGVz
Y3JpcHRpb24gPSAiUG9vbC0wIgogICB1dWlkID0gImJlYmNlMTZmLTkwMmYtNjhjZS1kMzhi
LWE0ZDQ5ZTgzNDZhNyIKICAgbmFtZSA9ICJQb29sLTAiCiBkb21haW4gPSAiIgogIDAgPSAi
IgogICB2bSA9ICIvdm0vMDAwMDAwMDAtMDAwMC0wMDAwLTAwMDAtMDAwMDAwMDAwMDAwIgog
ICBkZXZpY2UgPSAiIgogICBjb250cm9sID0gIiIKICAgIHBsYXRmb3JtLWZlYXR1cmUtbXVs
dGlwcm9jZXNzb3Itc3VzcGVuZCA9ICIxIgogICBtZW1vcnkgPSAiIgogICAgdGFyZ2V0ID0g
IjUyNDI4OCIKICAgIHN0YXRpYy1tYXggPSAiNDI5NDk2NzI5MiIKICAgIGZyZWVtZW0tc2xh
Y2sgPSAiNTAzMjg4MCIKICAgZ3Vlc3QgPSAiIgogICBodm1wdiA9ICIiCiAgIGRhdGEgPSAi
IgogICBjcHUgPSAiIgogICAgMSA9ICIiCiAgICAgYXZhaWxhYmlsaXR5ID0gIm9ubGluZSIK
ICAgIDMgPSAiIgogICAgIGF2YWlsYWJpbGl0eSA9ICJvbmxpbmUiCiAgICAyID0gIiIKICAg
ICBhdmFpbGFiaWxpdHkgPSAib25saW5lIgogICAgNyA9ICIiCiAgICAgYXZhaWxhYmlsaXR5
ID0gIm9ubGluZSIKICAgIDAgPSAiIgogICAgIGF2YWlsYWJpbGl0eSA9ICJvbmxpbmUiCiAg
ICA1ID0gIiIKICAgICBhdmFpbGFiaWxpdHkgPSAib25saW5lIgogICAgNiA9ICIiCiAgICAg
YXZhaWxhYmlsaXR5ID0gIm9ubGluZSIKICAgIDQgPSAiIgogICAgIGF2YWlsYWJpbGl0eSA9
ICJvbmxpbmUiCiAgIGRlc2NyaXB0aW9uID0gIiIKICAgY29uc29sZSA9ICIiCiAgICBsaW1p
dCA9ICIxMDQ4NTc2IgogICAgdHlwZSA9ICJ4ZW5jb25zb2xlZCIKICAgZG9taWQgPSAiMCIK
ICAgbmFtZSA9ICJEb21haW4tMCIKICAgYmFja2VuZCA9ICIiCiAgICBxZGlzayA9ICIiCiAg
ICBjb25zb2xlID0gIiIKICAgICAyID0gIiIKICAgICA1ID0gIiIKICAgICA5ID0gIiIKICAg
ICAxMSA9ICIiCiAgICAgMTIgPSAiIgogICAgICAwID0gIiIKICAgICAgIGRvbWFpbiA9ICJQ
cmVjaXNlSFZNIgogICAgICAgcHJvdG9jb2wgPSAidnQxMDAiCiAgICAgICB1dWlkID0gIjVi
OWE1ZTMwLTFhNTItYjQ2Zi01YjY5LThkMzQxYjIxZTdjYyIKICAgICAgIGZyb250ZW5kID0g
Ii9sb2NhbC9kb21haW4vMTIvZGV2aWNlL2NvbnNvbGUvMCIKICAgICAgIHN0YXRlID0gIjIi
CiAgICAgICBsb2NhdGlvbiA9ICI0IgogICAgICAgb25saW5lID0gIjEiCiAgICAgICBmcm9u
dGVuZC1pZCA9ICIxMiIKICAgICAgIGhvdHBsdWctc3RhdHVzID0gImNvbm5lY3RlZCIKICAg
IHZpZiA9ICIiCiAgICAgMTIgPSAiIgogICAgICAwID0gIiIKICAgICAgIGJyaWRnZSA9ICJ2
aXJicjAiCiAgICAgICBkb21haW4gPSAiUHJlY2lzZUhWTSIKICAgICAgIGhhbmRsZSA9ICIw
IgogICAgICAgdXVpZCA9ICJlZDhjMjdhMS02ZDVlLTU4NDEtN2FjYi00MjZlNTkzYmE2NTci
CiAgICAgICBzY3JpcHQgPSAiL2V0Yy94ZW4vc2NyaXB0cy92aWYtYnJpZGdlIgogICAgICAg
c3RhdGUgPSAiNiIKICAgICAgIGZyb250ZW5kID0gIi9sb2NhbC9kb21haW4vMTIvZGV2aWNl
L3ZpZi8wIgogICAgICAgbWFjID0gIjAwOjE2OjNlOjEyOjA0OmYwIgogICAgICAgb25saW5l
ID0gIjEiCiAgICAgICBmcm9udGVuZC1pZCA9ICIxMiIKICAgICAgIHR5cGUgPSAiaW9lbXUi
CiAgICAgICBmZWF0dXJlLXNnID0gIjEiCiAgICAgICBmZWF0dXJlLWdzby10Y3B2NCA9ICIx
IgogICAgICAgZmVhdHVyZS1yeC1jb3B5ID0gIjEiCiAgICAgICBmZWF0dXJlLXJ4LWZsaXAg
PSAiMCIKICAgIHZmYiA9ICIiCiAgICAgMTIgPSAiIgogICAgICAwID0gIiIKICAgICAgIHZu
Y3VudXNlZCA9ICIxIgogICAgICAgZG9tYWluID0gIlByZWNpc2VIVk0iCiAgICAgICB2bmMg
PSAiMSIKICAgICAgIHV1aWQgPSAiYzRlYmI2MGUtZDIyYS0xNjdmLTNiN2EtZmMzMzc3M2Y4
NGRlIgogICAgICAgdm5jbGlzdGVuID0gIjAuMC4wLjAiCiAgICAgICB2bmNkaXNwbGF5ID0g
IjAiCiAgICAgICBmcm9udGVuZCA9ICIvbG9jYWwvZG9tYWluLzEyL2RldmljZS92ZmIvMCIK
ICAgICAgIHN0YXRlID0gIjEiCiAgICAgICBrZXltYXAgPSAiZGUiCiAgICAgICBvbmxpbmUg
PSAiMSIKICAgICAgIGZyb250ZW5kLWlkID0gIjEyIgogICAgICAgbG9jYXRpb24gPSAiMC4w
LjAuMDo1OTAwIgogICAgdmJkID0gIiIKICAgICAxMiA9ICIiCiAgICAgIDc2OCA9ICIiCiAg
ICAgICBkb21haW4gPSAiUHJlY2lzZUhWTSIKICAgICAgIGZyb250ZW5kID0gIi9sb2NhbC9k
b21haW4vMTIvZGV2aWNlL3ZiZC83NjgiCiAgICAgICB1dWlkID0gImZlNzM1M2ZhLTJmOWYt
OTk0My0xMGM3LTczOTAwMjM2NTU3MSIKICAgICAgIGJvb3RhYmxlID0gIjEiCiAgICAgICBk
ZXYgPSAiaGRhIgogICAgICAgc3RhdGUgPSAiNCIKICAgICAgIHBhcmFtcyA9ICIvcm9vdC9p
bnN0YW5jZXMvcHJlY2lzZS1zZXJ2ZXIvaGRhLTY0LmltZyIKICAgICAgIG1vZGUgPSAidyIK
ICAgICAgIG9ubGluZSA9ICIxIgogICAgICAgZnJvbnRlbmQtaWQgPSAiMTIiCiAgICAgICB0
eXBlID0gImZpbGUiCiAgICAgICBub2RlID0gIi9kZXYvbG9vcDEiCiAgICAgICBwaHlzaWNh
bC1kZXZpY2UgPSAiNzoxIgogICAgICAgaG90cGx1Zy1zdGF0dXMgPSAiY29ubmVjdGVkIgog
ICAgICAgZmVhdHVyZS1mbHVzaC1jYWNoZSA9ICIxIgogICAgICAgc2VjdG9ycyA9ICIxNjM4
NDAwMCIKICAgICAgIGluZm8gPSAiMCIKICAgICAgIHNlY3Rvci1zaXplID0gIjUxMiIKICAg
ICAgNTYzMiA9ICIiCiAgICAgICBkb21haW4gPSAiUHJlY2lzZUhWTSIKICAgICAgIGZyb250
ZW5kID0gIi9sb2NhbC9kb21haW4vMTIvZGV2aWNlL3ZiZC81NjMyIgogICAgICAgdXVpZCA9
ICJkM2ExYTY0My02NWM0LTZkMzEtNDFiYy03ODZiYjRkNmNmZWEiCiAgICAgICBib290YWJs
ZSA9ICIwIgogICAgICAgZGV2ID0gImhkYyIKICAgICAgIHN0YXRlID0gIjYiCiAgICAgICBw
YXJhbXMgPSAiL3Jvb3QvaXNvcy9wcmVjaXNlLXNlcnZlci1hbWQ2NC5pc28iCiAgICAgICBt
b2RlID0gInIiCiAgICAgICBvbmxpbmUgPSAiMSIKICAgICAgIGZyb250ZW5kLWlkID0gIjEy
IgogICAgICAgdHlwZSA9ICJmaWxlIgogICAgICAgbm9kZSA9ICIvZGV2L2xvb3AwIgogICAg
ICAgcGh5c2ljYWwtZGV2aWNlID0gIjc6MCIKICAgICAgIGhvdHBsdWctc3RhdHVzID0gImNv
bm5lY3RlZCIKICAgZGV2aWNlLW1vZGVsID0gIiIKICAgIDEyID0gIiIKICAgICBkaXNhYmxl
X3BmID0gIjAiCiAgICAgc3RhdGUgPSAicnVubmluZyIKICAxMiA9ICIiCiAgIHZtID0gIi92
bS9hZDA5NTJkNy01OWFhLWYxODUtYTRlMy05YWQzMjM0ZTk4NzEiCiAgIGRldmljZSA9ICIi
CiAgICB2ZmIgPSAiIgogICAgIDAgPSAiIgogICAgICBzdGF0ZSA9ICIxIgogICAgICBiYWNr
ZW5kLWlkID0gIjAiCiAgICAgIGJhY2tlbmQgPSAiL2xvY2FsL2RvbWFpbi8wL2JhY2tlbmQv
dmZiLzEyLzAiCiAgICB2YmQgPSAiIgogICAgIDc2OCA9ICIiCiAgICAgIGJhY2tlbmQtaWQg
PSAiMCIKICAgICAgdmlydHVhbC1kZXZpY2UgPSAiNzY4IgogICAgICBkZXZpY2UtdHlwZSA9
ICJkaXNrIgogICAgICBzdGF0ZSA9ICI0IgogICAgICBiYWNrZW5kID0gIi9sb2NhbC9kb21h
aW4vMC9iYWNrZW5kL3ZiZC8xMi83NjgiCiAgICAgIHJpbmctcmVmID0gIjgiCiAgICAgIGV2
ZW50LWNoYW5uZWwgPSAiMTciCiAgICAgIHByb3RvY29sID0gIng4Nl82NC1hYmkiCiAgICAg
NTYzMiA9ICIiCiAgICAgIGJhY2tlbmQtaWQgPSAiMCIKICAgICAgdmlydHVhbC1kZXZpY2Ug
PSAiNTYzMiIKICAgICAgZGV2aWNlLXR5cGUgPSAiY2Ryb20iCiAgICAgIHN0YXRlID0gIjYi
CiAgICAgIGJhY2tlbmQgPSAiL2xvY2FsL2RvbWFpbi8wL2JhY2tlbmQvdmJkLzEyLzU2MzIi
CiAgICB2aWYgPSAiIgogICAgIDAgPSAiIgogICAgICBzdGF0ZSA9ICI2IgogICAgICBiYWNr
ZW5kLWlkID0gIjAiCiAgICAgIGJhY2tlbmQgPSAiL2xvY2FsL2RvbWFpbi8wL2JhY2tlbmQv
dmlmLzEyLzAiCiAgICBjb25zb2xlID0gIiIKICAgICAwID0gIiIKICAgICAgc3RhdGUgPSAi
MSIKICAgICAgYmFja2VuZC1pZCA9ICIwIgogICAgICBiYWNrZW5kID0gIi9sb2NhbC9kb21h
aW4vMC9iYWNrZW5kL2NvbnNvbGUvMTIvMCIKICAgY29udHJvbCA9ICIiCiAgICBwbGF0Zm9y
bS1mZWF0dXJlLW11bHRpcHJvY2Vzc29yLXN1c3BlbmQgPSAiMSIKICAgZXJyb3IgPSAiIgog
ICAgZGV2aWNlID0gIiIKICAgICB2YmQgPSAiIgogICAgICA1NjMyID0gIiIKICAgICAgIGVy
cm9yID0gIjE5IHhlbmJ1c19kZXZfcHJvYmUgb24gZGV2aWNlL3ZiZC81NjMyIgogICAgIHZp
ZiA9ICIiCiAgICAgIDAgPSAiIgogICAgICAgZXJyb3IgPSAiMiBwYXJzaW5nIGRldmljZS92
aWYvMC9tYWMiCiAgIG1lbW9yeSA9ICIiCiAgICB0YXJnZXQgPSAiMjA5NzE1MiIKICAgZ3Vl
c3QgPSAiIgogICBodm1wdiA9ICIiCiAgIGRhdGEgPSAiIgogICBkZXZpY2UtbWlzYyA9ICIi
CiAgICB2aWYgPSAiIgogICAgIG5leHREZXZpY2VJRCA9ICIxIgogICAgY29uc29sZSA9ICIi
CiAgICAgbmV4dERldmljZUlEID0gIjEiCiAgIGltYWdlID0gIiIKICAgIGRldmljZS1tb2Rl
bC1maWZvID0gIi92YXIvcnVuL3hlbmQvZG0tMTItMTMyMjc2MTA0NC5maWZvIgogICAgZGV2
aWNlLW1vZGVsLXBpZCA9ICI4MTYzIgogICAgc3VzcGVuZC1jYW5jZWwgPSAiMSIKICAgY29u
c29sZSA9ICIiCiAgICBwb3J0ID0gIjQiCiAgICBsaW1pdCA9ICIxMDQ4NTc2IgogICAgdHlw
ZSA9ICJpb2VtdSIKICAgIHR0eSA9ICIvZGV2L3B0cy8xIgogICAgdm5jLXBvcnQgPSAiNTkw
MCIKICAgIHZuYy1saXN0ZW4gPSAiMC4wLjAuMCIKICAgZGVzY3JpcHRpb24gPSAiIgogICBk
b21pZCA9ICIxMiIKICAgY3B1ID0gIiIKICAgIDAgPSAiIgogICAgIGF2YWlsYWJpbGl0eSA9
ICJvbmxpbmUiCiAgICAxID0gIiIKICAgICBhdmFpbGFiaWxpdHkgPSAib25saW5lIgogICBz
dG9yZSA9ICIiCiAgICByaW5nLXJlZiA9ICIxMDQ0NDc2IgogICAgcG9ydCA9ICIzIgogICBu
YW1lID0gIlByZWNpc2VIVk0iCiAgIHNlcmlhbCA9ICIiCiAgICAwID0gIiIKICAgICB0dHkg
PSAiL2Rldi9wdHMvMCIKdm0gPSAiIgogMDAwMDAwMDAtMDAwMC0wMDAwLTAwMDAtMDAwMDAw
MDAwMDAwID0gIiIKICBvbl94ZW5kX3N0b3AgPSAiaWdub3JlIgogIHBvb2xfbmFtZSA9ICJQ
b29sLTAiCiAgc2hhZG93X21lbW9yeSA9ICIwIgogIHV1aWQgPSAiMDAwMDAwMDAtMDAwMC0w
MDAwLTAwMDAtMDAwMDAwMDAwMDAwIgogIG9uX3JlYm9vdCA9ICJyZXN0YXJ0IgogIGltYWdl
ID0gIihsaW51eCAoa2VybmVsICcnKSAoc3VwZXJwYWdlcyAwKSAobm9taWdyYXRlIDApICh0
c2NfbW9kZSAwKSkiCiAgIG9zdHlwZSA9ICJsaW51eCIKICAga2VybmVsID0gIiIKICAgY21k
bGluZSA9ICIiCiAgIHJhbWRpc2sgPSAiIgogIG9uX3Bvd2Vyb2ZmID0gImRlc3Ryb3kiCiAg
Ym9vdGxvYWRlcl9hcmdzID0gIiIKICBvbl94ZW5kX3N0YXJ0ID0gImlnbm9yZSIKICBvbl9j
cmFzaCA9ICJyZXN0YXJ0IgogIHhlbmQgPSAiIgogICByZXN0YXJ0X2NvdW50ID0gIjAiCiAg
dmNwdXMgPSAiOCIKICB2Y3B1X2F2YWlsID0gIjI1NSIKICBib290bG9hZGVyID0gIiIKICBu
YW1lID0gIkRvbWFpbi0wIgogYWQwOTUyZDctNTlhYS1mMTg1LWE0ZTMtOWFkMzIzNGU5ODcx
ID0gIiIKICBpbWFnZSA9ICIoaHZtIChrZXJuZWwgJycpIChzdXBlcnBhZ2VzIDApICh2aWRl
b3JhbSA0KSAoaHBldCAwKSAoc3RkdmdhIDApIFwuLi4iCiAgIG9zdHlwZSA9ICJodm0iCiAg
IGtlcm5lbCA9ICIiCiAgIGNtZGxpbmUgPSAiIgogICByYW1kaXNrID0gIiIKICAgZG1hcmdz
ID0gIi1kb21haW4tbmFtZSBQcmVjaXNlSFZNIC12aWRlb3JhbSA0IC1rIGRlIC12bmMgMC4w
LjAuMDowIC12bmN1blwuLi4iCiAgIGRldmljZS1tb2RlbCA9ICIvdXNyL2xpYi94ZW4tNC4x
L2Jpbi9xZW11LWRtIgogICBkaXNwbGF5ID0gIiIKICBydGMgPSAiIgogICB0aW1lb2Zmc2V0
ID0gIjAiCiAgZGV2aWNlID0gIiIKICAgdmZiID0gIiIKICAgIDAgPSAiIgogICAgIGZyb250
ZW5kID0gIi9sb2NhbC9kb21haW4vMTIvZGV2aWNlL3ZmYi8wIgogICAgIGZyb250ZW5kLWlk
ID0gIjEyIgogICAgIGJhY2tlbmQtaWQgPSAiMCIKICAgICBiYWNrZW5kID0gIi9sb2NhbC9k
b21haW4vMC9iYWNrZW5kL3ZmYi8xMi8wIgogICB2YmQgPSAiIgogICAgNzY4ID0gIiIKICAg
ICBmcm9udGVuZCA9ICIvbG9jYWwvZG9tYWluLzEyL2RldmljZS92YmQvNzY4IgogICAgIGZy
b250ZW5kLWlkID0gIjEyIgogICAgIGJhY2tlbmQtaWQgPSAiMCIKICAgICBiYWNrZW5kID0g
Ii9sb2NhbC9kb21haW4vMC9iYWNrZW5kL3ZiZC8xMi83NjgiCiAgICA1NjMyID0gIiIKICAg
ICBmcm9udGVuZCA9ICIvbG9jYWwvZG9tYWluLzEyL2RldmljZS92YmQvNTYzMiIKICAgICBm
cm9udGVuZC1pZCA9ICIxMiIKICAgICBiYWNrZW5kLWlkID0gIjAiCiAgICAgYmFja2VuZCA9
ICIvbG9jYWwvZG9tYWluLzAvYmFja2VuZC92YmQvMTIvNTYzMiIKICAgdmlmID0gIiIKICAg
IDAgPSAiIgogICAgIGZyb250ZW5kID0gIi9sb2NhbC9kb21haW4vMTIvZGV2aWNlL3ZpZi8w
IgogICAgIGZyb250ZW5kLWlkID0gIjEyIgogICAgIGJhY2tlbmQtaWQgPSAiMCIKICAgICBi
YWNrZW5kID0gIi9sb2NhbC9kb21haW4vMC9iYWNrZW5kL3ZpZi8xMi8wIgogICBjb25zb2xl
ID0gIiIKICAgIDAgPSAiIgogICAgIGZyb250ZW5kID0gIi9sb2NhbC9kb21haW4vMTIvZGV2
aWNlL2NvbnNvbGUvMCIKICAgICBmcm9udGVuZC1pZCA9ICIxMiIKICAgICBiYWNrZW5kLWlk
ID0gIjAiCiAgICAgYmFja2VuZCA9ICIvbG9jYWwvZG9tYWluLzAvYmFja2VuZC9jb25zb2xl
LzEyLzAiCiAgb25feGVuZF9zdG9wID0gImlnbm9yZSIKICBwb29sX25hbWUgPSAiUG9vbC0w
IgogIHNoYWRvd19tZW1vcnkgPSAiMTgiCiAgdXVpZCA9ICJhZDA5NTJkNy01OWFhLWYxODUt
YTRlMy05YWQzMjM0ZTk4NzEiCiAgb25fcmVib290ID0gInJlc3RhcnQiCiAgc3RhcnRfdGlt
ZSA9ICIxMzIyNzYxMDQ0LjQ4IgogIG9uX3Bvd2Vyb2ZmID0gImRlc3Ryb3kiCiAgYm9vdGxv
YWRlcl9hcmdzID0gIiIKICBvbl94ZW5kX3N0YXJ0ID0gImlnbm9yZSIKICBvbl9jcmFzaCA9
ICJyZXN0YXJ0IgogIHhlbmQgPSAiIgogICByZXN0YXJ0X2NvdW50ID0gIjAiCiAgdmNwdXMg
PSAiMiIKICB2Y3B1X2F2YWlsID0gIjMiCiAgYm9vdGxvYWRlciA9ICIiCiAgbmFtZSA9ICJQ
cmVjaXNlSFZNIgo=
--------------040709070607000105030506
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--------------040709070607000105030506--


From xen-devel-bounces@lists.xensource.com Thu Dec 01 17:57:44 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 17:57:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWAsx-0000mi-LC; Thu, 01 Dec 2011 17:57:27 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RWAsw-0000ma-Cg
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 17:57:26 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1322762206!7155001!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU2Nw==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28119 invoked from network); 1 Dec 2011 17:56:46 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 17:56:46 -0000
X-IronPort-AV: E=Sophos;i="4.71,279,1320624000"; 
   d="scan'208";a="9237624"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Dec 2011 17:56:45 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 1 Dec 2011 17:56:45 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RWAsH-00045s-3p; Thu, 01 Dec 2011 17:56:45 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RWAsG-0003oO-Ir;
	Thu, 01 Dec 2011 17:56:44 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20183.49116.134853.919558@mariner.uk.xensource.com>
Date: Thu, 1 Dec 2011 17:56:44 +0000
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <alpine.DEB.2.00.1111181351190.3519@kaball-desktop>
References: <alpine.DEB.2.00.1111181351190.3519@kaball-desktop>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 0/3] prevent qemu-xen-traditional from
	waking up	needlessly
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Stefano Stabellini writes ("[Xen-devel] [PATCH 0/3] prevent qemu-xen-traditional from waking up needlessly"):
> this small patch series prevents qemu-xen-traditional from waking up
> needlessly several times a second in order to check some timers.
> 
> The first patch makes use of a new mechanism to receive buffered io
> event notifications from Xen, so that qemu doesn't need to check the
> buffered io page for data 10 times a sec for the entire life of the VM.

I see that the hypervisor patch has gone in, so I have applied 2 and 3
as well.

Ian.

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 17:57:44 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 17:57:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWAsx-0000mi-LC; Thu, 01 Dec 2011 17:57:27 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RWAsw-0000ma-Cg
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 17:57:26 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1322762206!7155001!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU2Nw==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28119 invoked from network); 1 Dec 2011 17:56:46 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 17:56:46 -0000
X-IronPort-AV: E=Sophos;i="4.71,279,1320624000"; 
   d="scan'208";a="9237624"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Dec 2011 17:56:45 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 1 Dec 2011 17:56:45 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RWAsH-00045s-3p; Thu, 01 Dec 2011 17:56:45 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RWAsG-0003oO-Ir;
	Thu, 01 Dec 2011 17:56:44 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20183.49116.134853.919558@mariner.uk.xensource.com>
Date: Thu, 1 Dec 2011 17:56:44 +0000
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <alpine.DEB.2.00.1111181351190.3519@kaball-desktop>
References: <alpine.DEB.2.00.1111181351190.3519@kaball-desktop>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 0/3] prevent qemu-xen-traditional from
	waking up	needlessly
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Stefano Stabellini writes ("[Xen-devel] [PATCH 0/3] prevent qemu-xen-traditional from waking up needlessly"):
> this small patch series prevents qemu-xen-traditional from waking up
> needlessly several times a second in order to check some timers.
> 
> The first patch makes use of a new mechanism to receive buffered io
> event notifications from Xen, so that qemu doesn't need to check the
> buffered io page for data 10 times a sec for the entire life of the VM.

I see that the hypervisor patch has gone in, so I have applied 2 and 3
as well.

Ian.

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 17:58:50 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 17:58:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWAu6-0000pz-40; Thu, 01 Dec 2011 17:58:38 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RWAu4-0000pn-Pq
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 17:58:36 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1322762247!55050717!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU2Nw==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6743 invoked from network); 1 Dec 2011 17:57:28 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 17:57:28 -0000
X-IronPort-AV: E=Sophos;i="4.71,279,1320624000"; 
   d="scan'208";a="9237647"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Dec 2011 17:57:58 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 1 Dec 2011 17:57:58 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RWAtS-00046L-5r; Thu, 01 Dec 2011 17:57:58 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RWAtS-0003p8-2l;
	Thu, 01 Dec 2011 17:57:58 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20183.49189.803920.871878@mariner.uk.xensource.com>
Date: Thu, 1 Dec 2011 17:57:57 +0000
To: Jan Beulich <JBeulich@suse.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <4ECBDB750200007800062680@nat28.tlf.novell.com>
References: <4ECBDB750200007800062680@nat28.tlf.novell.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Keir Fraser <keir@xen.org>, Jean Guyader <jean.guyader@eu.citrix.com>,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>
Subject: Re: [Xen-devel] [PATCH] ia64: build fixes (again)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Jan Beulich writes ("Re: [Xen-devel] [PATCH] ia64: build fixes (again)"):
> Oh, one more thing - would it be possible to add an ia64 build-only
> test to the stage testing logic?

That would be possible.  We used to have it in the old xenrt setup.
Nowadays though I want to be able to have a reproducible build
environment so I need a reproducible way to install the ia64 cross
tools.

This kind of thing is indeed on my todo list but I'm afraid it's not
very near the top.

Ian.

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 17:58:50 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 17:58:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWAu6-0000pz-40; Thu, 01 Dec 2011 17:58:38 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RWAu4-0000pn-Pq
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 17:58:36 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1322762247!55050717!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU2Nw==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6743 invoked from network); 1 Dec 2011 17:57:28 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 17:57:28 -0000
X-IronPort-AV: E=Sophos;i="4.71,279,1320624000"; 
   d="scan'208";a="9237647"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Dec 2011 17:57:58 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 1 Dec 2011 17:57:58 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RWAtS-00046L-5r; Thu, 01 Dec 2011 17:57:58 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RWAtS-0003p8-2l;
	Thu, 01 Dec 2011 17:57:58 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20183.49189.803920.871878@mariner.uk.xensource.com>
Date: Thu, 1 Dec 2011 17:57:57 +0000
To: Jan Beulich <JBeulich@suse.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <4ECBDB750200007800062680@nat28.tlf.novell.com>
References: <4ECBDB750200007800062680@nat28.tlf.novell.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Keir Fraser <keir@xen.org>, Jean Guyader <jean.guyader@eu.citrix.com>,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>
Subject: Re: [Xen-devel] [PATCH] ia64: build fixes (again)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Jan Beulich writes ("Re: [Xen-devel] [PATCH] ia64: build fixes (again)"):
> Oh, one more thing - would it be possible to add an ia64 build-only
> test to the stage testing logic?

That would be possible.  We used to have it in the old xenrt setup.
Nowadays though I want to be able to have a reproducible build
environment so I need a reproducible way to install the ia64 cross
tools.

This kind of thing is indeed on my todo list but I'm afraid it's not
very near the top.

Ian.

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 17:59:46 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 17:59:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWAv1-0000ur-JL; Thu, 01 Dec 2011 17:59:35 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RWAv0-0000u7-33
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 17:59:34 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1322762334!3712441!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU2Nw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2925 invoked from network); 1 Dec 2011 17:58:54 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 17:58:54 -0000
X-IronPort-AV: E=Sophos;i="4.71,279,1320624000"; 
   d="scan'208";a="9237655"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Dec 2011 17:58:53 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 1 Dec 2011 17:58:53 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RWAuL-00046d-IK; Thu, 01 Dec 2011 17:58:53 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RWAuL-0003pP-Ha;
	Thu, 01 Dec 2011 17:58:53 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20183.49245.499001.818529@mariner.uk.xensource.com>
Date: Thu, 1 Dec 2011 17:58:53 +0000
To: Roger Pau =?iso-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>, Lars Kurth
	<lars.kurth@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <CAPLaKK6hpSPTfoQ0gxCCV5bADeSo49F2C7XVmu7TmjL58cGAbA@mail.gmail.com>
References: <CAEwRVpObp89PW5LdrxdaBmyU+UzffXYM0bJApHJqAGU8f+RiHA@mail.gmail.com>
	<1321946469.20464.12.camel@dagon.hellion.org.uk>
	<CAEwRVpMWnL9wnvrqEJUx9R14wX6PRqjmxEPQq7dcKGd9sCvHFA@mail.gmail.com>
	<1321949903.20464.19.camel@dagon.hellion.org.uk>
	<CAEwRVpM+jBXs78XeTdJ2Hez+Y94tLVGQ3Sjbttfuu2vouqHnSA@mail.gmail.com>
	<1321950680.20464.20.camel@dagon.hellion.org.uk>
	<CAEwRVpMmFqtCRQUzUrww3yAzJYfva8fRFXfxQGXQVRBxFxn5PQ@mail.gmail.com>
	<1321952996.3664.401.camel@zakaz.uk.xensource.com>
	<CAEwRVpN_HtrAAr+mDkD4imf51bft3UMvjcH=YNydYsB6jch7Fg@mail.gmail.com>
	<alpine.DEB.2.00.1111221114160.31179@kaball-desktop>
	<CAEwRVpNOw3ONYMsWpnMuY6+TCpHFwx6biA3obO+kKQEH6EXWRA@mail.gmail.com>
	<alpine.DEB.2.00.1111231055330.31179@kaball-desktop>
	<CAPLaKK6hpSPTfoQ0gxCCV5bADeSo49F2C7XVmu7TmjL58cGAbA@mail.gmail.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Teck Choon Giam <giamteckchoon@gmail.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] libxl: error: libxl.c:2150:libxl_set_memory_target
 new target 0 for dom0 is below the minimum threshold
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Roger Pau Monn=E9 writes ("Re: [Xen-devel] libxl: error: libxl.c:2150:libxl=
_set_memory_target new target 0 for dom0 is below the minimum threshold"):
> 2011/11/23 Stefano Stabellini <stefano.stabellini@eu.citrix.com>:
> > Maybe it is worth documenting this somewhere, any suggestions where?
> =

> A note should be added here:
> http://wiki.xen.org/xenwiki/XenBooting.html (I can't find this page on
> the new wiki, but this should be migrated).

Lars, do you have an opinion ?

> Also in the xm/xl config file and probably in the man page for xl.cfg
> and xend-config.sxp.

Patches gratefully accepted :-).

Thanks,
Ian.

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 17:59:46 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 17:59:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWAv1-0000ur-JL; Thu, 01 Dec 2011 17:59:35 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RWAv0-0000u7-33
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 17:59:34 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1322762334!3712441!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU2Nw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2925 invoked from network); 1 Dec 2011 17:58:54 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 17:58:54 -0000
X-IronPort-AV: E=Sophos;i="4.71,279,1320624000"; 
   d="scan'208";a="9237655"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Dec 2011 17:58:53 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 1 Dec 2011 17:58:53 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RWAuL-00046d-IK; Thu, 01 Dec 2011 17:58:53 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RWAuL-0003pP-Ha;
	Thu, 01 Dec 2011 17:58:53 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20183.49245.499001.818529@mariner.uk.xensource.com>
Date: Thu, 1 Dec 2011 17:58:53 +0000
To: Roger Pau =?iso-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>, Lars Kurth
	<lars.kurth@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <CAPLaKK6hpSPTfoQ0gxCCV5bADeSo49F2C7XVmu7TmjL58cGAbA@mail.gmail.com>
References: <CAEwRVpObp89PW5LdrxdaBmyU+UzffXYM0bJApHJqAGU8f+RiHA@mail.gmail.com>
	<1321946469.20464.12.camel@dagon.hellion.org.uk>
	<CAEwRVpMWnL9wnvrqEJUx9R14wX6PRqjmxEPQq7dcKGd9sCvHFA@mail.gmail.com>
	<1321949903.20464.19.camel@dagon.hellion.org.uk>
	<CAEwRVpM+jBXs78XeTdJ2Hez+Y94tLVGQ3Sjbttfuu2vouqHnSA@mail.gmail.com>
	<1321950680.20464.20.camel@dagon.hellion.org.uk>
	<CAEwRVpMmFqtCRQUzUrww3yAzJYfva8fRFXfxQGXQVRBxFxn5PQ@mail.gmail.com>
	<1321952996.3664.401.camel@zakaz.uk.xensource.com>
	<CAEwRVpN_HtrAAr+mDkD4imf51bft3UMvjcH=YNydYsB6jch7Fg@mail.gmail.com>
	<alpine.DEB.2.00.1111221114160.31179@kaball-desktop>
	<CAEwRVpNOw3ONYMsWpnMuY6+TCpHFwx6biA3obO+kKQEH6EXWRA@mail.gmail.com>
	<alpine.DEB.2.00.1111231055330.31179@kaball-desktop>
	<CAPLaKK6hpSPTfoQ0gxCCV5bADeSo49F2C7XVmu7TmjL58cGAbA@mail.gmail.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Teck Choon Giam <giamteckchoon@gmail.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] libxl: error: libxl.c:2150:libxl_set_memory_target
 new target 0 for dom0 is below the minimum threshold
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Roger Pau Monn=E9 writes ("Re: [Xen-devel] libxl: error: libxl.c:2150:libxl=
_set_memory_target new target 0 for dom0 is below the minimum threshold"):
> 2011/11/23 Stefano Stabellini <stefano.stabellini@eu.citrix.com>:
> > Maybe it is worth documenting this somewhere, any suggestions where?
> =

> A note should be added here:
> http://wiki.xen.org/xenwiki/XenBooting.html (I can't find this page on
> the new wiki, but this should be migrated).

Lars, do you have an opinion ?

> Also in the xm/xl config file and probably in the man page for xl.cfg
> and xend-config.sxp.

Patches gratefully accepted :-).

Thanks,
Ian.

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 18:02:02 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 18:02:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWAxE-0001Hq-IS; Thu, 01 Dec 2011 18:01:52 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RWAxD-0001GU-5v
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 18:01:51 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-13.tower-21.messagelabs.com!1322762470!4608188!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNDUxMTM=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNDUxMTM=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18713 invoked from network); 1 Dec 2011 18:01:11 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-13.tower-21.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 1 Dec 2011 18:01:11 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1322762470; l=505;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=/tIU3Dz6UI9naanZolp3EBIjUts=;
	b=Wum8xUMbBpk2lOL1U3YfDXwmS/C7Qemb7gAxOy4fBN0JWEz9CDa0TQSsL5+x0GrRySh
	JzX9Ho3T0DTTMXrcZ3hG7bq2szfFl+WtSl3kytpmyBHn0y9+F+0gR5sDhJUPbW1IICg0M
	hkh/UhW4fbtc11rfx4JWX1uZoud54vpmgWE=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/ll2c7pE6jG
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-080-213.pools.arcor-ip.net [84.57.80.213])
	by smtp.strato.de (klopstock mo16) (RZmta 26.10 AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id L03f11nB1HCf7b ;
	Thu, 1 Dec 2011 19:01:00 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id E199D18637; Thu,  1 Dec 2011 19:00:59 +0100 (CET)
Date: Thu, 1 Dec 2011 19:00:59 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20111201180059.GA15876@aepfle.de>
References: <patchbomb.1322760071@xdev.gridcentric.ca>
	<90ded86b0a30c34e1644.1322760074@xdev.gridcentric.ca>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <90ded86b0a30c34e1644.1322760074@xdev.gridcentric.ca>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: ian.jackson@citrix.com, andres@gridcentric.ca,
	xen-devel@lists.xensource.com, tim@xen.org, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 3 of 3] Teach xenpaging to use the new and
 non-racy xc_mem_paging_load
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Dec 01, Andres Lagar-Cavilla wrote:

> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
 
Acked-by: Olaf Hering <olaf@aepfle.de>

> diff -r e71f880c0518 -r 90ded86b0a30 tools/xenpaging/xenpaging.c
> --- a/tools/xenpaging/xenpaging.c
> +++ b/tools/xenpaging/xenpaging.c
> @@ -45,6 +45,7 @@ static char *dom_path;
>  static char watch_token[16];
>  static char *filename;
>  static int interrupted;
> +static void *paging_buffer = NULL;

Globals need no assignment.

Olaf

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 18:02:02 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 18:02:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWAxE-0001Hq-IS; Thu, 01 Dec 2011 18:01:52 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RWAxD-0001GU-5v
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 18:01:51 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-13.tower-21.messagelabs.com!1322762470!4608188!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNDUxMTM=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNDUxMTM=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18713 invoked from network); 1 Dec 2011 18:01:11 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-13.tower-21.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 1 Dec 2011 18:01:11 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1322762470; l=505;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=/tIU3Dz6UI9naanZolp3EBIjUts=;
	b=Wum8xUMbBpk2lOL1U3YfDXwmS/C7Qemb7gAxOy4fBN0JWEz9CDa0TQSsL5+x0GrRySh
	JzX9Ho3T0DTTMXrcZ3hG7bq2szfFl+WtSl3kytpmyBHn0y9+F+0gR5sDhJUPbW1IICg0M
	hkh/UhW4fbtc11rfx4JWX1uZoud54vpmgWE=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/ll2c7pE6jG
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-080-213.pools.arcor-ip.net [84.57.80.213])
	by smtp.strato.de (klopstock mo16) (RZmta 26.10 AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id L03f11nB1HCf7b ;
	Thu, 1 Dec 2011 19:01:00 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id E199D18637; Thu,  1 Dec 2011 19:00:59 +0100 (CET)
Date: Thu, 1 Dec 2011 19:00:59 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20111201180059.GA15876@aepfle.de>
References: <patchbomb.1322760071@xdev.gridcentric.ca>
	<90ded86b0a30c34e1644.1322760074@xdev.gridcentric.ca>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <90ded86b0a30c34e1644.1322760074@xdev.gridcentric.ca>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: ian.jackson@citrix.com, andres@gridcentric.ca,
	xen-devel@lists.xensource.com, tim@xen.org, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 3 of 3] Teach xenpaging to use the new and
 non-racy xc_mem_paging_load
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Dec 01, Andres Lagar-Cavilla wrote:

> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
 
Acked-by: Olaf Hering <olaf@aepfle.de>

> diff -r e71f880c0518 -r 90ded86b0a30 tools/xenpaging/xenpaging.c
> --- a/tools/xenpaging/xenpaging.c
> +++ b/tools/xenpaging/xenpaging.c
> @@ -45,6 +45,7 @@ static char *dom_path;
>  static char watch_token[16];
>  static char *filename;
>  static int interrupted;
> +static void *paging_buffer = NULL;

Globals need no assignment.

Olaf

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 18:02:05 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 18:02:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWAxE-0001HX-6f; Thu, 01 Dec 2011 18:01:52 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RWAxD-0001GT-2C
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 18:01:51 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1322762470!5446030!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU2Nw==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30933 invoked from network); 1 Dec 2011 18:01:11 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 18:01:11 -0000
X-IronPort-AV: E=Sophos;i="4.71,279,1320624000"; 
   d="scan'208";a="9237681"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Dec 2011 18:01:10 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 1 Dec 2011
	18:01:10 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
In-Reply-To: <20183.46573.894123.974575@mariner.uk.xensource.com>
References: <CANrAofX3ARD8CN8HtoBnetfMZvBUS5RSC89ExuGoVSzqmE2V9A@mail.gmail.com>
	<1322736422.31810.197.camel@zakaz.uk.xensource.com>
	<20183.46573.894123.974575@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
Date: Thu, 1 Dec 2011 18:01:10 +0000
Message-ID: <1322762470.7376.27.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
X-Mailer: Evolution 2.32.3 
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Adda Rathbone <addarathbone@googlemail.com>
Subject: Re: [Xen-devel] Compile error with Ubuntu 11.10
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2011-12-01 at 17:14 +0000, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] Compile error with Ubuntu 11.10"):
> > I expect that this needs to change to be
> >     return libxl__xs_write(gc, XBT_NULL, path, "%s", libxl__strdup(gc,
> >        libxl_device_model_version_to_string(dm_info->device_model_version)));
> > (note the additional "%s",)
> > 
> > Can you try that?
> 
> Here's a patch which I think should fix this.  Adda, can you try it
> please ?
> 
> libxl: Fix format string problem resulting in compile warning
> 
> Fixes:
>   libxl_create.c:465: error: format not a string literal and no format 
>   arguments
> (The warning does not relate to security problem in this case,
> because the string erroneously used as a format came from our enum
> conversion and is safe.)

If distros (or gcc) are starting to enable -Wformat-nonliteral (assuming
that is what this is) by default perhaps we should preemptively set it
ourselves?

Setting it found one other instance of a weird strdup (actually a
sprintf of a string we just sprintf'd). but otherwise it seems to work.

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

libxl: build with -Wformat-nonliteral

Fix the remaining issue that this shows up.

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

diff -r 20c1c0ff9677 tools/libxl/Makefile
--- a/tools/libxl/Makefile	Thu Dec 01 12:24:06 2011 +0100
+++ b/tools/libxl/Makefile	Thu Dec 01 17:59:25 2011 +0000
@@ -11,7 +11,7 @@ MINOR = 0
 XLUMAJOR = 1.0
 XLUMINOR = 0
 
-CFLAGS += -Werror -Wno-format-zero-length -Wmissing-declarations
+CFLAGS += -Werror -Wno-format-zero-length -Wmissing-declarations -Wformat-nonliteral
 CFLAGS += -I. -fPIC
 
 ifeq ($(CONFIG_Linux),y)

 static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
diff -r 20c1c0ff9677 tools/libxl/libxl_device.c
--- a/tools/libxl/libxl_device.c	Thu Dec 01 12:24:06 2011 +0100
+++ b/tools/libxl/libxl_device.c	Thu Dec 01 17:59:25 2011 +0000
@@ -516,7 +516,7 @@ int libxl__devices_destroy(libxl__gc *gc
         for (j = 0; j < num_devs; j++) {
             path = libxl__sprintf(gc, "/local/domain/%d/device/%s/%s/backend",
                                   domid, kinds[i], devs[j]);
-            path = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, path));
+            path = libxl__xs_read(gc, XBT_NULL, path);
             if (path && libxl__parse_backend_path(gc, path, &dev) == 0) {
                 dev.domid = domid;
                 dev.kind = kind;



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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 18:02:05 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 18:02:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWAxE-0001HX-6f; Thu, 01 Dec 2011 18:01:52 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RWAxD-0001GT-2C
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 18:01:51 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1322762470!5446030!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU2Nw==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30933 invoked from network); 1 Dec 2011 18:01:11 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 18:01:11 -0000
X-IronPort-AV: E=Sophos;i="4.71,279,1320624000"; 
   d="scan'208";a="9237681"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Dec 2011 18:01:10 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 1 Dec 2011
	18:01:10 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
In-Reply-To: <20183.46573.894123.974575@mariner.uk.xensource.com>
References: <CANrAofX3ARD8CN8HtoBnetfMZvBUS5RSC89ExuGoVSzqmE2V9A@mail.gmail.com>
	<1322736422.31810.197.camel@zakaz.uk.xensource.com>
	<20183.46573.894123.974575@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
Date: Thu, 1 Dec 2011 18:01:10 +0000
Message-ID: <1322762470.7376.27.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
X-Mailer: Evolution 2.32.3 
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Adda Rathbone <addarathbone@googlemail.com>
Subject: Re: [Xen-devel] Compile error with Ubuntu 11.10
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2011-12-01 at 17:14 +0000, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] Compile error with Ubuntu 11.10"):
> > I expect that this needs to change to be
> >     return libxl__xs_write(gc, XBT_NULL, path, "%s", libxl__strdup(gc,
> >        libxl_device_model_version_to_string(dm_info->device_model_version)));
> > (note the additional "%s",)
> > 
> > Can you try that?
> 
> Here's a patch which I think should fix this.  Adda, can you try it
> please ?
> 
> libxl: Fix format string problem resulting in compile warning
> 
> Fixes:
>   libxl_create.c:465: error: format not a string literal and no format 
>   arguments
> (The warning does not relate to security problem in this case,
> because the string erroneously used as a format came from our enum
> conversion and is safe.)

If distros (or gcc) are starting to enable -Wformat-nonliteral (assuming
that is what this is) by default perhaps we should preemptively set it
ourselves?

Setting it found one other instance of a weird strdup (actually a
sprintf of a string we just sprintf'd). but otherwise it seems to work.

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

libxl: build with -Wformat-nonliteral

Fix the remaining issue that this shows up.

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

diff -r 20c1c0ff9677 tools/libxl/Makefile
--- a/tools/libxl/Makefile	Thu Dec 01 12:24:06 2011 +0100
+++ b/tools/libxl/Makefile	Thu Dec 01 17:59:25 2011 +0000
@@ -11,7 +11,7 @@ MINOR = 0
 XLUMAJOR = 1.0
 XLUMINOR = 0
 
-CFLAGS += -Werror -Wno-format-zero-length -Wmissing-declarations
+CFLAGS += -Werror -Wno-format-zero-length -Wmissing-declarations -Wformat-nonliteral
 CFLAGS += -I. -fPIC
 
 ifeq ($(CONFIG_Linux),y)

 static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
diff -r 20c1c0ff9677 tools/libxl/libxl_device.c
--- a/tools/libxl/libxl_device.c	Thu Dec 01 12:24:06 2011 +0100
+++ b/tools/libxl/libxl_device.c	Thu Dec 01 17:59:25 2011 +0000
@@ -516,7 +516,7 @@ int libxl__devices_destroy(libxl__gc *gc
         for (j = 0; j < num_devs; j++) {
             path = libxl__sprintf(gc, "/local/domain/%d/device/%s/%s/backend",
                                   domid, kinds[i], devs[j]);
-            path = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, path));
+            path = libxl__xs_read(gc, XBT_NULL, path);
             if (path && libxl__parse_backend_path(gc, path, &dev) == 0) {
                 dev.domid = domid;
                 dev.kind = kind;



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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 18:02:37 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 18:02:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWAxn-0001Pg-1K; Thu, 01 Dec 2011 18:02:27 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RWAxl-0001OT-JI
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 18:02:25 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1322762505!3898599!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU2Nw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27546 invoked from network); 1 Dec 2011 18:01:45 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 18:01:45 -0000
X-IronPort-AV: E=Sophos;i="4.71,279,1320624000"; 
   d="scan'208";a="9237687"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Dec 2011 18:01:45 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 1 Dec 2011 18:01:44 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RWAx6-00047Z-Q5	for xen-devel@lists.xensource.com;
	Thu, 01 Dec 2011 18:01:44 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RWAx6-0003rn-Ou	for
	xen-devel@lists.xensource.com; Thu, 01 Dec 2011 18:01:44 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20183.49416.735231.548215@mariner.uk.xensource.com>
Date: Thu, 1 Dec 2011 18:01:44 +0000
To: xen-devel@lists.xensource.com
X-Mailer: VM 7.19 under Emacs 21.4.1
Subject: [Xen-devel] [PATCH] docs: Say in xm(1) that xm is obsolete
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

diff -r 3b409f65abae docs/man/xm.pod.1
--- a/docs/man/xm.pod.1	Thu Dec 01 17:26:48 2011 +0000
+++ b/docs/man/xm.pod.1	Thu Dec 01 18:01:35 2011 +0000
@@ -1,6 +1,6 @@
 =head1 NAME
 
-xm - Xen management user interface
+xm - Obsolete xen management user interface
 
 =head1 SYNOPSIS
 
@@ -8,10 +8,14 @@ B<xm> I<subcommand> [I<args>]
 
 =head1 DESCRIPTION
 
-The B<xm> program is the main interface for managing Xen guest
-domains. The program can be used to create, pause, and shutdown
-domains. It can also be used to list current domains, enable or pin
-VCPUs, and attach or detach virtual block devices.
+This program is now superseded by B<xl>, which should be largely
+backwards-compatible with B<sm>.
+
+The B<xm> program is the main interface for managing Xen guest domains
+when the obsolete Xend toolstack is in use. The program can be used to
+create, pause, and shutdown domains. It can also be used to list
+current domains, enable or pin VCPUs, and attach or detach virtual
+block devices.
 
 The basic structure of every B<xm> command is almost always:
 

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 18:02:37 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 18:02:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWAxn-0001Pg-1K; Thu, 01 Dec 2011 18:02:27 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RWAxl-0001OT-JI
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 18:02:25 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1322762505!3898599!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU2Nw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27546 invoked from network); 1 Dec 2011 18:01:45 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 18:01:45 -0000
X-IronPort-AV: E=Sophos;i="4.71,279,1320624000"; 
   d="scan'208";a="9237687"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Dec 2011 18:01:45 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 1 Dec 2011 18:01:44 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RWAx6-00047Z-Q5	for xen-devel@lists.xensource.com;
	Thu, 01 Dec 2011 18:01:44 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RWAx6-0003rn-Ou	for
	xen-devel@lists.xensource.com; Thu, 01 Dec 2011 18:01:44 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20183.49416.735231.548215@mariner.uk.xensource.com>
Date: Thu, 1 Dec 2011 18:01:44 +0000
To: xen-devel@lists.xensource.com
X-Mailer: VM 7.19 under Emacs 21.4.1
Subject: [Xen-devel] [PATCH] docs: Say in xm(1) that xm is obsolete
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

diff -r 3b409f65abae docs/man/xm.pod.1
--- a/docs/man/xm.pod.1	Thu Dec 01 17:26:48 2011 +0000
+++ b/docs/man/xm.pod.1	Thu Dec 01 18:01:35 2011 +0000
@@ -1,6 +1,6 @@
 =head1 NAME
 
-xm - Xen management user interface
+xm - Obsolete xen management user interface
 
 =head1 SYNOPSIS
 
@@ -8,10 +8,14 @@ B<xm> I<subcommand> [I<args>]
 
 =head1 DESCRIPTION
 
-The B<xm> program is the main interface for managing Xen guest
-domains. The program can be used to create, pause, and shutdown
-domains. It can also be used to list current domains, enable or pin
-VCPUs, and attach or detach virtual block devices.
+This program is now superseded by B<xl>, which should be largely
+backwards-compatible with B<sm>.
+
+The B<xm> program is the main interface for managing Xen guest domains
+when the obsolete Xend toolstack is in use. The program can be used to
+create, pause, and shutdown domains. It can also be used to list
+current domains, enable or pin VCPUs, and attach or detach virtual
+block devices.
 
 The basic structure of every B<xm> command is almost always:
 

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 18:02:55 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 18:02:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWAy3-0001TM-Fx; Thu, 01 Dec 2011 18:02:43 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RWAy1-0001RX-NC
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 18:02:41 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-2.tower-174.messagelabs.com!1322762521!3863831!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11792 invoked from network); 1 Dec 2011 18:02:01 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-2.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 1 Dec 2011 18:02:01 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RWAxJ-000HAm-6Z; Thu, 01 Dec 2011 18:01:57 +0000
Date: Thu, 1 Dec 2011 18:01:57 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20111201180157.GO61203@ocelot.phlegethon.org>
References: <patchbomb.1322603709@xdev.gridcentric.ca>
	<c2b5e65331ee1fccdcd4.1322603713@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <c2b5e65331ee1fccdcd4.1322603713@xdev.gridcentric.ca>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com, ian.campbell@citrix.com,
	andres@gridcentric.ca, keir.xen@gmail.com, JBeulich@suse.com,
	ian.jackson@citrix.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 4 of 5] Make the prototype of
	p2m_mem_access_resume consistent
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 16:55 -0500 on 29 Nov (1322585713), Andres Lagar-Cavilla wrote:
>  xen/arch/x86/mm/mem_access.c |  3 +--
>  xen/arch/x86/mm/p2m.c        |  3 +--
>  xen/include/asm-x86/p2m.h    |  2 +-
>  3 files changed, 3 insertions(+), 5 deletions(-)
> 
> 
> Signed-off-by: Adin Scannell <adin@scannell.ca>
> Signed-off-by: Keir Fraser <keir@xen.org>
> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

I've applied this one obvious fixup in isolation; the rest of the series
clearly needs some further discussion.

Cheers,

Tim.

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 18:02:55 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 18:02:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWAy3-0001TM-Fx; Thu, 01 Dec 2011 18:02:43 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RWAy1-0001RX-NC
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 18:02:41 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-2.tower-174.messagelabs.com!1322762521!3863831!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11792 invoked from network); 1 Dec 2011 18:02:01 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-2.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 1 Dec 2011 18:02:01 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RWAxJ-000HAm-6Z; Thu, 01 Dec 2011 18:01:57 +0000
Date: Thu, 1 Dec 2011 18:01:57 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20111201180157.GO61203@ocelot.phlegethon.org>
References: <patchbomb.1322603709@xdev.gridcentric.ca>
	<c2b5e65331ee1fccdcd4.1322603713@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <c2b5e65331ee1fccdcd4.1322603713@xdev.gridcentric.ca>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com, ian.campbell@citrix.com,
	andres@gridcentric.ca, keir.xen@gmail.com, JBeulich@suse.com,
	ian.jackson@citrix.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 4 of 5] Make the prototype of
	p2m_mem_access_resume consistent
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 16:55 -0500 on 29 Nov (1322585713), Andres Lagar-Cavilla wrote:
>  xen/arch/x86/mm/mem_access.c |  3 +--
>  xen/arch/x86/mm/p2m.c        |  3 +--
>  xen/include/asm-x86/p2m.h    |  2 +-
>  3 files changed, 3 insertions(+), 5 deletions(-)
> 
> 
> Signed-off-by: Adin Scannell <adin@scannell.ca>
> Signed-off-by: Keir Fraser <keir@xen.org>
> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

I've applied this one obvious fixup in isolation; the rest of the series
clearly needs some further discussion.

Cheers,

Tim.

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 18:06:45 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 18:06:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWB1q-0001zJ-4z; Thu, 01 Dec 2011 18:06:38 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RWB1o-0001z0-Si
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 18:06:37 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-8.tower-182.messagelabs.com!1322762756!950183!1
X-Originating-IP: [208.97.132.83]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi44MyA9PiAxNTQ4OQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22888 invoked from network); 1 Dec 2011 18:05:56 -0000
Received: from caiajhbdcaid.dreamhost.com (HELO homiemail-a22.g.dreamhost.com)
	(208.97.132.83) by server-8.tower-182.messagelabs.com with SMTP;
	1 Dec 2011 18:05:56 -0000
Received: from homiemail-a22.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a22.g.dreamhost.com (Postfix) with ESMTP id 2D16B1A8063;
	Thu,  1 Dec 2011 10:05:56 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=Wpy2gG36yW1EUGtg4z6ITD0S3qmzO3kYU2e0Dly9Av3x
	h/2QSp7N3uWSVnXPTaE6Pm35RqxDvQy08Mn4FNEkOHO2/uNlcPSLYBoTjvPAIjY1
	zkp0IA/zuiZcRFl6rM7N0NnyTlRZ7CLNd3JMCumo7Lfh74zH919/dv4YhXu6VZE=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=3CCJZGSN2y+ZqTewjQSB+m/XjYg=; b=fIuGAghG
	sjuLKpoNk3N8fSG0CBfvfws9aTaEbV/PYtdRQbpH92MUaQfzZLZ1LgUinRREpaf/
	DVrxJb+HjlaRaDATLAvYyXOoIxR8HxkPEzqE8TWwGn7CrxmMM/2iADyzPU6yE1Rx
	d4i3Ie3TCA3YmCitWK9qCgsuwbPfEWn3Czg=
Received: from webmail.lagarcavilla.org (ahfbbjcaiaae.dreamhost.com
	[75.119.208.4]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a22.g.dreamhost.com (Postfix) with ESMTPA id BA2F51A805F; 
	Thu,  1 Dec 2011 10:05:55 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP; Thu, 1 Dec 2011 10:05:56 -0800
Message-ID: <a56b08caf211c8e60ddaf5be90af5c05.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20111201180157.GO61203@ocelot.phlegethon.org>
References: <patchbomb.1322603709@xdev.gridcentric.ca>
	<c2b5e65331ee1fccdcd4.1322603713@xdev.gridcentric.ca>
	<20111201180157.GO61203@ocelot.phlegethon.org>
Date: Thu, 1 Dec 2011 10:05:56 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Tim Deegan" <tim@xen.org>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, ian.campbell@citrix.com,
	andres@gridcentric.ca, keir.xen@gmail.com, jbeulich@suse.com,
	ian.jackson@citrix.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 4 of 5] Make the prototype of
 p2m_mem_access_resume consistent
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> At 16:55 -0500 on 29 Nov (1322585713), Andres Lagar-Cavilla wrote:
>>  xen/arch/x86/mm/mem_access.c |  3 +--
>>  xen/arch/x86/mm/p2m.c        |  3 +--
>>  xen/include/asm-x86/p2m.h    |  2 +-
>>  3 files changed, 3 insertions(+), 5 deletions(-)
>>
>>
>> Signed-off-by: Adin Scannell <adin@scannell.ca>
>> Signed-off-by: Keir Fraser <keir@xen.org>
>> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
>
> I've applied this one obvious fixup in isolation; the rest of the series
> clearly needs some further discussion.

Thanks Tim,

I had to rebase the main patch in the series given the recent commit
"mem_event: move mem_event_domain out of struct domain". The rebase is
obvious and does not affect the gist of the patch, but I can resend that
single patch, the whole series, etc.

Andres
>
> Cheers,
>
> Tim.
>



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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 18:06:45 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 18:06:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWB1q-0001zJ-4z; Thu, 01 Dec 2011 18:06:38 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RWB1o-0001z0-Si
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 18:06:37 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-8.tower-182.messagelabs.com!1322762756!950183!1
X-Originating-IP: [208.97.132.83]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi44MyA9PiAxNTQ4OQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22888 invoked from network); 1 Dec 2011 18:05:56 -0000
Received: from caiajhbdcaid.dreamhost.com (HELO homiemail-a22.g.dreamhost.com)
	(208.97.132.83) by server-8.tower-182.messagelabs.com with SMTP;
	1 Dec 2011 18:05:56 -0000
Received: from homiemail-a22.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a22.g.dreamhost.com (Postfix) with ESMTP id 2D16B1A8063;
	Thu,  1 Dec 2011 10:05:56 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=Wpy2gG36yW1EUGtg4z6ITD0S3qmzO3kYU2e0Dly9Av3x
	h/2QSp7N3uWSVnXPTaE6Pm35RqxDvQy08Mn4FNEkOHO2/uNlcPSLYBoTjvPAIjY1
	zkp0IA/zuiZcRFl6rM7N0NnyTlRZ7CLNd3JMCumo7Lfh74zH919/dv4YhXu6VZE=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=3CCJZGSN2y+ZqTewjQSB+m/XjYg=; b=fIuGAghG
	sjuLKpoNk3N8fSG0CBfvfws9aTaEbV/PYtdRQbpH92MUaQfzZLZ1LgUinRREpaf/
	DVrxJb+HjlaRaDATLAvYyXOoIxR8HxkPEzqE8TWwGn7CrxmMM/2iADyzPU6yE1Rx
	d4i3Ie3TCA3YmCitWK9qCgsuwbPfEWn3Czg=
Received: from webmail.lagarcavilla.org (ahfbbjcaiaae.dreamhost.com
	[75.119.208.4]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a22.g.dreamhost.com (Postfix) with ESMTPA id BA2F51A805F; 
	Thu,  1 Dec 2011 10:05:55 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP; Thu, 1 Dec 2011 10:05:56 -0800
Message-ID: <a56b08caf211c8e60ddaf5be90af5c05.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20111201180157.GO61203@ocelot.phlegethon.org>
References: <patchbomb.1322603709@xdev.gridcentric.ca>
	<c2b5e65331ee1fccdcd4.1322603713@xdev.gridcentric.ca>
	<20111201180157.GO61203@ocelot.phlegethon.org>
Date: Thu, 1 Dec 2011 10:05:56 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Tim Deegan" <tim@xen.org>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, ian.campbell@citrix.com,
	andres@gridcentric.ca, keir.xen@gmail.com, jbeulich@suse.com,
	ian.jackson@citrix.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 4 of 5] Make the prototype of
 p2m_mem_access_resume consistent
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> At 16:55 -0500 on 29 Nov (1322585713), Andres Lagar-Cavilla wrote:
>>  xen/arch/x86/mm/mem_access.c |  3 +--
>>  xen/arch/x86/mm/p2m.c        |  3 +--
>>  xen/include/asm-x86/p2m.h    |  2 +-
>>  3 files changed, 3 insertions(+), 5 deletions(-)
>>
>>
>> Signed-off-by: Adin Scannell <adin@scannell.ca>
>> Signed-off-by: Keir Fraser <keir@xen.org>
>> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
>
> I've applied this one obvious fixup in isolation; the rest of the series
> clearly needs some further discussion.

Thanks Tim,

I had to rebase the main patch in the series given the recent commit
"mem_event: move mem_event_domain out of struct domain". The rebase is
obvious and does not affect the gist of the patch, but I can resend that
single patch, the whole series, etc.

Andres
>
> Cheers,
>
> Tim.
>



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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 18:07:33 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 18: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.xensource.com>)
	id 1RWB2a-00025p-QJ; Thu, 01 Dec 2011 18:07:24 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pasik@iki.fi>) id 1RWB2Z-00024l-Mr
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 18:07:23 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-8.tower-182.messagelabs.com!1322762803!950286!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA0NTUxMDA=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24752 invoked from network); 1 Dec 2011 18:06:44 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-8.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 1 Dec 2011 18:06:44 -0000
X-Originating-Ip: [194.89.68.22]
Received: from ydin.reaktio.net (reaktio.net [194.89.68.22])
	by smtp.tele.fi (Postfix) with ESMTP id 2FC931EFD;
	Thu,  1 Dec 2011 20:06:42 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 09BD420083; Thu,  1 Dec 2011 20:06:41 +0200 (EET)
Date: Thu, 1 Dec 2011 20:06:41 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: "Shan, Haitao" <haitao.shan@intel.com>
Message-ID: <20111201180641.GG12984@reaktio.net>
References: <4ED76A350200007800064ABD@nat28.tlf.novell.com>
	<04F972F38B3C4E4E91C4697DA8BF9F5284357D52A6@shsmsx502.ccr.corp.intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <04F972F38B3C4E4E91C4697DA8BF9F5284357D52A6@shsmsx502.ccr.corp.intel.com>
User-Agent: Mutt/1.5.18 (2008-05-17)
Cc: "He, Qing" <qing.he@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Dong, Eddie" <eddie.dong@intel.com>, Tim Deegan <Tim.Deegan@citrix.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH] vvmx: fix intended assignment
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Dec 01, 2011 at 07:19:58PM +0800, Shan, Haitao wrote:
> Hi, Jan,
> 

Hello,

> I think you cannot cc He Qing any more. As He Qing (who had done some work
> on nested) has left Intel, while this email address is going to another
> people who just has the same name.
> 

Is there anyone from Intel currently working on nested virt? 

-- Pasi

> Shan Haitao
> 
> > -----Original Message-----
> > From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-
> > bounces@lists.xensource.com] On Behalf Of Jan Beulich
> > Sent: Thursday, December 01, 2011 6:51 PM
> > To: xen-devel@lists.xensource.com
> > Cc: Dong, Eddie; Tim Deegan; He, Qing
> > Subject: [Xen-devel] [PATCH] vvmx: fix intended assignment
> > 
> > From what I can tell, this was supposed to be an assignment (not warned
> > about by the compiler due to -Wno-unused, which is about to be removed).
> > 
> > Signed-off-by: Jan Beulich <jbeulich@suse.com>
> > 
> > --- a/xen/arch/x86/hvm/vmx/vvmx.c
> > +++ b/xen/arch/x86/hvm/vmx/vvmx.c
> > @@ -581,7 +581,7 @@ static void nvmx_purge_vvmcs(struct vcpu
> >      __clear_current_vvmcs(v);
> >      if ( nvcpu->nv_vvmcxaddr != VMCX_EADDR )
> >          hvm_unmap_guest_frame(nvcpu->nv_vvmcx);
> > -    nvcpu->nv_vvmcx == NULL;
> > +    nvcpu->nv_vvmcx = NULL;
> >      nvcpu->nv_vvmcxaddr = VMCX_EADDR;
> >      for (i=0; i<2; i++) {
> >          if ( nvmx->iobitmap[i] ) {
> > 
> > 
> 



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


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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 18:07:33 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 18: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.xensource.com>)
	id 1RWB2a-00025p-QJ; Thu, 01 Dec 2011 18:07:24 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pasik@iki.fi>) id 1RWB2Z-00024l-Mr
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 18:07:23 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-8.tower-182.messagelabs.com!1322762803!950286!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA0NTUxMDA=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24752 invoked from network); 1 Dec 2011 18:06:44 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-8.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 1 Dec 2011 18:06:44 -0000
X-Originating-Ip: [194.89.68.22]
Received: from ydin.reaktio.net (reaktio.net [194.89.68.22])
	by smtp.tele.fi (Postfix) with ESMTP id 2FC931EFD;
	Thu,  1 Dec 2011 20:06:42 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 09BD420083; Thu,  1 Dec 2011 20:06:41 +0200 (EET)
Date: Thu, 1 Dec 2011 20:06:41 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: "Shan, Haitao" <haitao.shan@intel.com>
Message-ID: <20111201180641.GG12984@reaktio.net>
References: <4ED76A350200007800064ABD@nat28.tlf.novell.com>
	<04F972F38B3C4E4E91C4697DA8BF9F5284357D52A6@shsmsx502.ccr.corp.intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <04F972F38B3C4E4E91C4697DA8BF9F5284357D52A6@shsmsx502.ccr.corp.intel.com>
User-Agent: Mutt/1.5.18 (2008-05-17)
Cc: "He, Qing" <qing.he@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Dong, Eddie" <eddie.dong@intel.com>, Tim Deegan <Tim.Deegan@citrix.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH] vvmx: fix intended assignment
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Dec 01, 2011 at 07:19:58PM +0800, Shan, Haitao wrote:
> Hi, Jan,
> 

Hello,

> I think you cannot cc He Qing any more. As He Qing (who had done some work
> on nested) has left Intel, while this email address is going to another
> people who just has the same name.
> 

Is there anyone from Intel currently working on nested virt? 

-- Pasi

> Shan Haitao
> 
> > -----Original Message-----
> > From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-
> > bounces@lists.xensource.com] On Behalf Of Jan Beulich
> > Sent: Thursday, December 01, 2011 6:51 PM
> > To: xen-devel@lists.xensource.com
> > Cc: Dong, Eddie; Tim Deegan; He, Qing
> > Subject: [Xen-devel] [PATCH] vvmx: fix intended assignment
> > 
> > From what I can tell, this was supposed to be an assignment (not warned
> > about by the compiler due to -Wno-unused, which is about to be removed).
> > 
> > Signed-off-by: Jan Beulich <jbeulich@suse.com>
> > 
> > --- a/xen/arch/x86/hvm/vmx/vvmx.c
> > +++ b/xen/arch/x86/hvm/vmx/vvmx.c
> > @@ -581,7 +581,7 @@ static void nvmx_purge_vvmcs(struct vcpu
> >      __clear_current_vvmcs(v);
> >      if ( nvcpu->nv_vvmcxaddr != VMCX_EADDR )
> >          hvm_unmap_guest_frame(nvcpu->nv_vvmcx);
> > -    nvcpu->nv_vvmcx == NULL;
> > +    nvcpu->nv_vvmcx = NULL;
> >      nvcpu->nv_vvmcxaddr = VMCX_EADDR;
> >      for (i=0; i<2; i++) {
> >          if ( nvmx->iobitmap[i] ) {
> > 
> > 
> 



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


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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 18:10:36 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 18:10:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWB5W-0002Ii-Dy; Thu, 01 Dec 2011 18:10:26 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pasik@iki.fi>) id 1RWB5U-0002IM-UY
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 18:10:25 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-9.tower-182.messagelabs.com!1322762984!5498911!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA0NTUxMDA=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1878 invoked from network); 1 Dec 2011 18:09:45 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-9.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 1 Dec 2011 18:09:45 -0000
X-Originating-Ip: [194.89.68.22]
Received: from ydin.reaktio.net (reaktio.net [194.89.68.22])
	by smtp.tele.fi (Postfix) with ESMTP id 376292C35;
	Thu,  1 Dec 2011 20:09:44 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 10DCE20083; Thu,  1 Dec 2011 20:09:44 +0200 (EET)
Date: Thu, 1 Dec 2011 20:09:44 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Stefan Bader <stefan.bader@canonical.com>
Message-ID: <20111201180944.GH12984@reaktio.net>
References: <4ED798B2.1040309@canonical.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4ED798B2.1040309@canonical.com>
User-Agent: Mutt/1.5.18 (2008-05-17)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Xen 4.x / Linux 3.x (dom0 and HVM domU) and
	NIC	handling
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Dec 01, 2011 at 04:09:38PM +0100, Stefan Bader wrote:
> Moving to public discussion...
> 
> This was found with Xen hypervisor version supporting device unplugging and the
> domU kernel having net-/blkfront and pci platform built-in (or as module).
> 
> The block device is defined as hda and the NIC type=ioemu (so theoretically
> guests without pv support would work, too).
> 
> Since both drivers are present, the kernel tries to unplug the emulated devices
> and succeeds. The blkfront driver detects the xvda device available in parallel
> and is working ok.
> 
> However the network interface does not work. There are entries present under
> sysfs for the xenbus but trying to bring it up fails with errors. And also there
> seems to be no mac address set (all zeros in sysfs).
> When the type=ioemu is removed in the configuration, this works.
> 
> I have not much more debugging information beyond that, yet. But it sounds a bit
> like NICs should behave the same as block devices. So if there is an emulated
> device defined there will be an alternate paravirt interface for it and after
> unplugging the emulated ones we end up with the pv ones.
> Is that something that can be seen with newer Xen versions, too (I am using 4.1.1)?
> 

Hey,

Have you seen?: 
http://wiki.xen.org/xenwiki/XenLinuxPVonHVMdrivers

Especially the following note:
"NOTE! If you have "type=ioemu" specified for the "vif"-line, PVHVM drivers WILL NOT work! Don't specify "type" parameter for the vif. (with type=ioemu the pvhvm nic in the VM will have mac address full of zeroes - and thus won't work!)."

"type=ioemu" is not needed, at least with xm/xend toolstack both HVM and PVHVM guests work OK without it.

-- Pasi


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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 18:10:36 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 18:10:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWB5W-0002Ii-Dy; Thu, 01 Dec 2011 18:10:26 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pasik@iki.fi>) id 1RWB5U-0002IM-UY
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 18:10:25 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-9.tower-182.messagelabs.com!1322762984!5498911!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA0NTUxMDA=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1878 invoked from network); 1 Dec 2011 18:09:45 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-9.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 1 Dec 2011 18:09:45 -0000
X-Originating-Ip: [194.89.68.22]
Received: from ydin.reaktio.net (reaktio.net [194.89.68.22])
	by smtp.tele.fi (Postfix) with ESMTP id 376292C35;
	Thu,  1 Dec 2011 20:09:44 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 10DCE20083; Thu,  1 Dec 2011 20:09:44 +0200 (EET)
Date: Thu, 1 Dec 2011 20:09:44 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Stefan Bader <stefan.bader@canonical.com>
Message-ID: <20111201180944.GH12984@reaktio.net>
References: <4ED798B2.1040309@canonical.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4ED798B2.1040309@canonical.com>
User-Agent: Mutt/1.5.18 (2008-05-17)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Xen 4.x / Linux 3.x (dom0 and HVM domU) and
	NIC	handling
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Dec 01, 2011 at 04:09:38PM +0100, Stefan Bader wrote:
> Moving to public discussion...
> 
> This was found with Xen hypervisor version supporting device unplugging and the
> domU kernel having net-/blkfront and pci platform built-in (or as module).
> 
> The block device is defined as hda and the NIC type=ioemu (so theoretically
> guests without pv support would work, too).
> 
> Since both drivers are present, the kernel tries to unplug the emulated devices
> and succeeds. The blkfront driver detects the xvda device available in parallel
> and is working ok.
> 
> However the network interface does not work. There are entries present under
> sysfs for the xenbus but trying to bring it up fails with errors. And also there
> seems to be no mac address set (all zeros in sysfs).
> When the type=ioemu is removed in the configuration, this works.
> 
> I have not much more debugging information beyond that, yet. But it sounds a bit
> like NICs should behave the same as block devices. So if there is an emulated
> device defined there will be an alternate paravirt interface for it and after
> unplugging the emulated ones we end up with the pv ones.
> Is that something that can be seen with newer Xen versions, too (I am using 4.1.1)?
> 

Hey,

Have you seen?: 
http://wiki.xen.org/xenwiki/XenLinuxPVonHVMdrivers

Especially the following note:
"NOTE! If you have "type=ioemu" specified for the "vif"-line, PVHVM drivers WILL NOT work! Don't specify "type" parameter for the vif. (with type=ioemu the pvhvm nic in the VM will have mac address full of zeroes - and thus won't work!)."

"type=ioemu" is not needed, at least with xm/xend toolstack both HVM and PVHVM guests work OK without it.

-- Pasi


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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 18:10:58 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 18:10:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWB5u-0002Lf-SJ; Thu, 01 Dec 2011 18:10:50 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RWB5t-0002Kz-18
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 18:10:49 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-16.tower-216.messagelabs.com!1322763007!5743527!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1917 invoked from network); 1 Dec 2011 18:10:08 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-16.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 1 Dec 2011 18:10:08 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RWB5C-000HCQ-Pu; Thu, 01 Dec 2011 18:10:06 +0000
Date: Thu, 1 Dec 2011 18:10:06 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20111201181006.GP61203@ocelot.phlegethon.org>
References: <patchbomb.1322603709@xdev.gridcentric.ca>
	<43dc614d543cdf84189d.1322603711@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <43dc614d543cdf84189d.1322603711@xdev.gridcentric.ca>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com, ian.campbell@citrix.com,
	andres@gridcentric.ca, keir.xen@gmail.com, JBeulich@suse.com,
	ian.jackson@citrix.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 2 of 5] Improve ring management for memory
	events. Do not lose guest events
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 16:55 -0500 on 29 Nov (1322585711), Andres Lagar-Cavilla wrote:
> The memevent code currently has a mechanism for reserving space in the ring
> before putting an event, but each caller must individually ensure that the
> vCPUs are correctly paused if no space is available.
> 
> This fixes that issue by reversing the semantics: we ensure that enough space
> is always left for one event per vCPU in the ring.  If, after putting the
> current request, this constraint will be violated by the current vCPU
> when putting putting another request in the ring, we pause the vCPU.

What about operations that touch more than one page of guest memory?
(E.g., pagetable walks, emulated faults and task switches).  Can't they
still fill up the ring?

IIRC there are still cases where we need wait-queues anyway (when we hit
a paged-out page after an non-idempotent action has already been
taken).  Is the purpose of this change just to reduce the number of
wait-queue uses or do you think you can do without them entirely?

Cheers,

Tim.

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 18:10:58 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 18:10:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWB5u-0002Lf-SJ; Thu, 01 Dec 2011 18:10:50 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RWB5t-0002Kz-18
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 18:10:49 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-16.tower-216.messagelabs.com!1322763007!5743527!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1917 invoked from network); 1 Dec 2011 18:10:08 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-16.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 1 Dec 2011 18:10:08 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RWB5C-000HCQ-Pu; Thu, 01 Dec 2011 18:10:06 +0000
Date: Thu, 1 Dec 2011 18:10:06 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20111201181006.GP61203@ocelot.phlegethon.org>
References: <patchbomb.1322603709@xdev.gridcentric.ca>
	<43dc614d543cdf84189d.1322603711@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <43dc614d543cdf84189d.1322603711@xdev.gridcentric.ca>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com, ian.campbell@citrix.com,
	andres@gridcentric.ca, keir.xen@gmail.com, JBeulich@suse.com,
	ian.jackson@citrix.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 2 of 5] Improve ring management for memory
	events. Do not lose guest events
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 16:55 -0500 on 29 Nov (1322585711), Andres Lagar-Cavilla wrote:
> The memevent code currently has a mechanism for reserving space in the ring
> before putting an event, but each caller must individually ensure that the
> vCPUs are correctly paused if no space is available.
> 
> This fixes that issue by reversing the semantics: we ensure that enough space
> is always left for one event per vCPU in the ring.  If, after putting the
> current request, this constraint will be violated by the current vCPU
> when putting putting another request in the ring, we pause the vCPU.

What about operations that touch more than one page of guest memory?
(E.g., pagetable walks, emulated faults and task switches).  Can't they
still fill up the ring?

IIRC there are still cases where we need wait-queues anyway (when we hit
a paged-out page after an non-idempotent action has already been
taken).  Is the purpose of this change just to reduce the number of
wait-queue uses or do you think you can do without them entirely?

Cheers,

Tim.

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 18:11:18 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 18: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.xensource.com>)
	id 1RWB6G-0002PQ-DL; Thu, 01 Dec 2011 18:11:12 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RWB6F-0002OW-Ea
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 18:11:11 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1322763031!3864658!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU2Nw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1165 invoked from network); 1 Dec 2011 18:10:31 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 18:10:31 -0000
X-IronPort-AV: E=Sophos;i="4.71,279,1320624000"; 
   d="scan'208";a="9237802"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Dec 2011 18:10:31 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 1 Dec 2011 18:10:30 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RWB5a-0004Az-MN; Thu, 01 Dec 2011 18:10:30 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RWB5a-00040H-Ku;
	Thu, 01 Dec 2011 18:10:30 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20183.49942.245446.669527@mariner.uk.xensource.com>
Date: Thu, 1 Dec 2011 18:10:30 +0000
To: Anthony PERARD <anthony.perard@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1322070039-439-1-git-send-email-anthony.perard@citrix.com>
References: <1322070039-439-1-git-send-email-anthony.perard@citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Xen Devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 0/3] Migration on QEMU upstream
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Anthony PERARD writes ("[Xen-devel] [PATCH 0/3] Migration on QEMU upstream"):
> This patch series introduce migration with QEMU upstream.

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 18:11:18 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 18: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.xensource.com>)
	id 1RWB6G-0002PQ-DL; Thu, 01 Dec 2011 18:11:12 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RWB6F-0002OW-Ea
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 18:11:11 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1322763031!3864658!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU2Nw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1165 invoked from network); 1 Dec 2011 18:10:31 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 18:10:31 -0000
X-IronPort-AV: E=Sophos;i="4.71,279,1320624000"; 
   d="scan'208";a="9237802"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Dec 2011 18:10:31 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 1 Dec 2011 18:10:30 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RWB5a-0004Az-MN; Thu, 01 Dec 2011 18:10:30 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RWB5a-00040H-Ku;
	Thu, 01 Dec 2011 18:10:30 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20183.49942.245446.669527@mariner.uk.xensource.com>
Date: Thu, 1 Dec 2011 18:10:30 +0000
To: Anthony PERARD <anthony.perard@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1322070039-439-1-git-send-email-anthony.perard@citrix.com>
References: <1322070039-439-1-git-send-email-anthony.perard@citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Xen Devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 0/3] Migration on QEMU upstream
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Anthony PERARD writes ("[Xen-devel] [PATCH 0/3] Migration on QEMU upstream"):
> This patch series introduce migration with QEMU upstream.

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 18:16:04 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 18:16:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWBAa-0002v1-FG; Thu, 01 Dec 2011 18:15:40 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <lars.kurth@citrix.com>) id 1RWBAY-0002uY-PR
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 18:15:38 +0000
X-Env-Sender: lars.kurth@citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1322763298!6547995!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU2Nw==\n,
	ML_RADAR_SPEW_LINKS_8, spamassassin: 
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24277 invoked from network); 1 Dec 2011 18:14:59 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 18:14:59 -0000
X-IronPort-AV: E=Sophos;i="4.71,279,1320624000"; 
   d="scan'208";a="9237858"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Dec 2011 18:14:58 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.161]) by
	LONPMAILMX01.citrite.net ([10.30.203.162]) with mapi; Thu, 1 Dec 2011
	18:14:58 +0000
From: Lars Kurth <lars.kurth@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	=?iso-8859-1?Q?Roger_Pau_Monn=E9?= <roger.pau@entel.upc.edu>
Date: Thu, 1 Dec 2011 18:14:57 +0000
Thread-Topic: [Xen-devel] libxl: error: libxl.c:2150:libxl_set_memory_target
	new target 0 for dom0 is below the minimum threshold
Thread-Index: AcywUuPeITmEp20DREyYXp3Z3yDycwAATVUQ
Message-ID: <344C0F67BC927847A2C92F9EE358DB0EBAFA8028B2@LONPMAILBOX01.citrite.net>
References: <CAEwRVpObp89PW5LdrxdaBmyU+UzffXYM0bJApHJqAGU8f+RiHA@mail.gmail.com>
	<1321946469.20464.12.camel@dagon.hellion.org.uk>
	<CAEwRVpMWnL9wnvrqEJUx9R14wX6PRqjmxEPQq7dcKGd9sCvHFA@mail.gmail.com>
	<1321949903.20464.19.camel@dagon.hellion.org.uk>
	<CAEwRVpM+jBXs78XeTdJ2Hez+Y94tLVGQ3Sjbttfuu2vouqHnSA@mail.gmail.com>
	<1321950680.20464.20.camel@dagon.hellion.org.uk>
	<CAEwRVpMmFqtCRQUzUrww3yAzJYfva8fRFXfxQGXQVRBxFxn5PQ@mail.gmail.com>
	<1321952996.3664.401.camel@zakaz.uk.xensource.com>
	<CAEwRVpN_HtrAAr+mDkD4imf51bft3UMvjcH=YNydYsB6jch7Fg@mail.gmail.com>
	<alpine.DEB.2.00.1111221114160.31179@kaball-desktop>
	<CAEwRVpNOw3ONYMsWpnMuY6+TCpHFwx6biA3obO+kKQEH6EXWRA@mail.gmail.com>
	<alpine.DEB.2.00.1111231055330.31179@kaball-desktop>
	<CAPLaKK6hpSPTfoQ0gxCCV5bADeSo49F2C7XVmu7TmjL58cGAbA@mail.gmail.com>
	<20183.49245.499001.818529@mariner.uk.xensource.com>
In-Reply-To: <20183.49245.499001.818529@mariner.uk.xensource.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Teck Choon Giam <giamteckchoon@gmail.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] libxl: error: libxl.c:2150:libxl_set_memory_target
 new target 0 for dom0 is below the minimum threshold
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>> A note should be added here:
>> http://wiki.xen.org/xenwiki/XenBooting.html (I can't find this page on
>> the new wiki, but this should be migrated).
>
>Lars, do you have an opinion ?
Yes, this page is on the list of pages which still need to be migrated (see=
 http://tinyurl.com/63ts9oc). I have not gotten round to it yet and relativ=
ely few others have in fact volunteered to migrate pages. On the other hand=
, this may be a page which is better suited to a Man page (and  x-reffed fr=
om the wiki). Part of why I have not done this, is because there is a simil=
ar page http://wiki.xen.org/wiki/XenHypervisorBootOptions which looks as if=
 it needed to be merged with http://wiki.xen.org/xenwiki/XenBooting.html .
	=

Instructions on how to migrate pages and the protocol are here http://wiki.=
xen.org/wiki/Wiki_Community/Migration_Instructions_from_Old_to_New_Xen_Wiki

I have a long backlog of stuff to do and cannot promise that I can migrate =
all the remaining wiki pages this week or next week.

Regards
Lars

-----Original Message-----
From: Ian Jackson [mailto:Ian.Jackson@eu.citrix.com] =

Sent: 01 December 2011 17:59
To: Roger Pau Monn=E9; Lars Kurth
Cc: Stefano Stabellini; xen-devel@lists.xensource.com; Teck Choon Giam; Ian=
 Campbell
Subject: Re: [Xen-devel] libxl: error: libxl.c:2150:libxl_set_memory_target=
 new target 0 for dom0 is below the minimum threshold

Roger Pau Monn=E9 writes ("Re: [Xen-devel] libxl: error: libxl.c:2150:libxl=
_set_memory_target new target 0 for dom0 is below the minimum threshold"):
> 2011/11/23 Stefano Stabellini <stefano.stabellini@eu.citrix.com>:
> > Maybe it is worth documenting this somewhere, any suggestions where?
> =

> A note should be added here:
> http://wiki.xen.org/xenwiki/XenBooting.html (I can't find this page on
> the new wiki, but this should be migrated).

Lars, do you have an opinion ?

> Also in the xm/xl config file and probably in the man page for xl.cfg
> and xend-config.sxp.

Patches gratefully accepted :-).

Thanks,
Ian.

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 18:16:04 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 18:16:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWBAa-0002v1-FG; Thu, 01 Dec 2011 18:15:40 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <lars.kurth@citrix.com>) id 1RWBAY-0002uY-PR
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 18:15:38 +0000
X-Env-Sender: lars.kurth@citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1322763298!6547995!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU2Nw==\n,
	ML_RADAR_SPEW_LINKS_8, spamassassin: 
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24277 invoked from network); 1 Dec 2011 18:14:59 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 18:14:59 -0000
X-IronPort-AV: E=Sophos;i="4.71,279,1320624000"; 
   d="scan'208";a="9237858"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Dec 2011 18:14:58 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.161]) by
	LONPMAILMX01.citrite.net ([10.30.203.162]) with mapi; Thu, 1 Dec 2011
	18:14:58 +0000
From: Lars Kurth <lars.kurth@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	=?iso-8859-1?Q?Roger_Pau_Monn=E9?= <roger.pau@entel.upc.edu>
Date: Thu, 1 Dec 2011 18:14:57 +0000
Thread-Topic: [Xen-devel] libxl: error: libxl.c:2150:libxl_set_memory_target
	new target 0 for dom0 is below the minimum threshold
Thread-Index: AcywUuPeITmEp20DREyYXp3Z3yDycwAATVUQ
Message-ID: <344C0F67BC927847A2C92F9EE358DB0EBAFA8028B2@LONPMAILBOX01.citrite.net>
References: <CAEwRVpObp89PW5LdrxdaBmyU+UzffXYM0bJApHJqAGU8f+RiHA@mail.gmail.com>
	<1321946469.20464.12.camel@dagon.hellion.org.uk>
	<CAEwRVpMWnL9wnvrqEJUx9R14wX6PRqjmxEPQq7dcKGd9sCvHFA@mail.gmail.com>
	<1321949903.20464.19.camel@dagon.hellion.org.uk>
	<CAEwRVpM+jBXs78XeTdJ2Hez+Y94tLVGQ3Sjbttfuu2vouqHnSA@mail.gmail.com>
	<1321950680.20464.20.camel@dagon.hellion.org.uk>
	<CAEwRVpMmFqtCRQUzUrww3yAzJYfva8fRFXfxQGXQVRBxFxn5PQ@mail.gmail.com>
	<1321952996.3664.401.camel@zakaz.uk.xensource.com>
	<CAEwRVpN_HtrAAr+mDkD4imf51bft3UMvjcH=YNydYsB6jch7Fg@mail.gmail.com>
	<alpine.DEB.2.00.1111221114160.31179@kaball-desktop>
	<CAEwRVpNOw3ONYMsWpnMuY6+TCpHFwx6biA3obO+kKQEH6EXWRA@mail.gmail.com>
	<alpine.DEB.2.00.1111231055330.31179@kaball-desktop>
	<CAPLaKK6hpSPTfoQ0gxCCV5bADeSo49F2C7XVmu7TmjL58cGAbA@mail.gmail.com>
	<20183.49245.499001.818529@mariner.uk.xensource.com>
In-Reply-To: <20183.49245.499001.818529@mariner.uk.xensource.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Teck Choon Giam <giamteckchoon@gmail.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] libxl: error: libxl.c:2150:libxl_set_memory_target
 new target 0 for dom0 is below the minimum threshold
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>> A note should be added here:
>> http://wiki.xen.org/xenwiki/XenBooting.html (I can't find this page on
>> the new wiki, but this should be migrated).
>
>Lars, do you have an opinion ?
Yes, this page is on the list of pages which still need to be migrated (see=
 http://tinyurl.com/63ts9oc). I have not gotten round to it yet and relativ=
ely few others have in fact volunteered to migrate pages. On the other hand=
, this may be a page which is better suited to a Man page (and  x-reffed fr=
om the wiki). Part of why I have not done this, is because there is a simil=
ar page http://wiki.xen.org/wiki/XenHypervisorBootOptions which looks as if=
 it needed to be merged with http://wiki.xen.org/xenwiki/XenBooting.html .
	=

Instructions on how to migrate pages and the protocol are here http://wiki.=
xen.org/wiki/Wiki_Community/Migration_Instructions_from_Old_to_New_Xen_Wiki

I have a long backlog of stuff to do and cannot promise that I can migrate =
all the remaining wiki pages this week or next week.

Regards
Lars

-----Original Message-----
From: Ian Jackson [mailto:Ian.Jackson@eu.citrix.com] =

Sent: 01 December 2011 17:59
To: Roger Pau Monn=E9; Lars Kurth
Cc: Stefano Stabellini; xen-devel@lists.xensource.com; Teck Choon Giam; Ian=
 Campbell
Subject: Re: [Xen-devel] libxl: error: libxl.c:2150:libxl_set_memory_target=
 new target 0 for dom0 is below the minimum threshold

Roger Pau Monn=E9 writes ("Re: [Xen-devel] libxl: error: libxl.c:2150:libxl=
_set_memory_target new target 0 for dom0 is below the minimum threshold"):
> 2011/11/23 Stefano Stabellini <stefano.stabellini@eu.citrix.com>:
> > Maybe it is worth documenting this somewhere, any suggestions where?
> =

> A note should be added here:
> http://wiki.xen.org/xenwiki/XenBooting.html (I can't find this page on
> the new wiki, but this should be migrated).

Lars, do you have an opinion ?

> Also in the xm/xl config file and probably in the man page for xl.cfg
> and xend-config.sxp.

Patches gratefully accepted :-).

Thanks,
Ian.

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 18:17:28 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 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.xensource.com>)
	id 1RWBC7-00030j-WF; Thu, 01 Dec 2011 18:17:16 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <niall.fleming@webanywhere.co.uk>) id 1RWBC6-00030E-My
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 18:17:15 +0000
X-Env-Sender: niall.fleming@webanywhere.co.uk
X-Msg-Ref: server-10.tower-216.messagelabs.com!1322763394!5724926!1
X-Originating-IP: [212.227.17.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjEyLjIyNy4xNy4xMCA9PiA4MDg3MA==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22617 invoked from network); 1 Dec 2011 18:16:34 -0000
Received: from moutng.kundenserver.de (HELO moutng.kundenserver.de)
	(212.227.17.10) by server-10.tower-216.messagelabs.com with SMTP;
	1 Dec 2011 18:16:34 -0000
Received: from [192.168.80.60] (host81-130-62-168.in-addr.btopenworld.com
	[81.130.62.168])
	by mrelayeu.kundenserver.de (node=mrbap0) with ESMTP (Nemesis)
	id 0MKKU2-1RUWkV1V6U-0023ty; Thu, 01 Dec 2011 19:16:06 +0100
Message-ID: <4ED7C464.6040609@webanywhere.co.uk>
Date: Thu, 01 Dec 2011 18:16:04 +0000
From: Niall Fleming <niall.fleming@webanywhere.co.uk>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: Laszlo Ersek <lersek@redhat.com>
References: <4EBD5AA0.3090906@webanywhere.co.uk>	
	<20111111183913.GA9283@phenom.dumpdata.com>	
	<4EC0F20D0200007800060B7D@nat28.tlf.novell.com>	
	<20111114180045.GA14517@phenom.dumpdata.com>	<4EC16CA7.70901@goop.org>	
	<20111116142604.GA7476@phenom.dumpdata.com>	
	<4ED662B0.8060105@webanywhere.co.uk>	
	<20111130222628.GE16651@andromeda.dapyr.net>	
	<4ED740FD.4070603@webanywhere.co.uk>
	<1322733206.31810.173.camel@zakaz.uk.xensource.com>
	<4ED756BE.3070309@redhat.com>
In-Reply-To: <4ED756BE.3070309@redhat.com>
X-Provags-ID: V02:K0:QNLY489ifQozEeYNH3RxKlrg9x/wwug4AmVFzDtNhDO
	sdaxPPpvtjdvU25rS/hqTu3rHLT0tnwB/nVwU6XPpeI2zntatm
	7pPiRrnvgs0rO16aua6uzxnem2b/ZjRdIPdEpAZ9HGhPYLpnta
	wPNEZp5bMMBYEH2TWIgE9DP+J/4b0Ohi+aC7BKtBbnFGR2Bpnn
	bIhr6KwWtfLwUjr0Fx/J2avz552pYc1G3ehBMy5JekIHEaaMTH
	J7ywDgbNJTZci0GYzelLS8x6O6QS20mzB/p98WGKUScOsiyx8u
	jzCo+clwAxnneLi5zXW4mxwEw+hvbSsZEF4fekICRE9k2Pa2+e
	kUeZcwVmz/I0R7lZw7hsTcwngUD+pDSKNTvo90xhx
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"keir.xen@gmail.com" <keir.xen@gmail.com>, Jan Beulich <JBeulich@suse.com>,
	"pbonzini@redhat.com" <pbonzini@redhat.com>,
	Konrad Rzeszutek Wilk <konrad@darnok.org>
Subject: Re: [Xen-devel] Time Change Issue Xen 4.1
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============4245614031396109523=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

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

This is a multi-part message in MIME format.
--------------060601090803010506070408
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

I wasn't expecting anyone to speed up and fix the issue, I just hoped 
that one or more of
people who were involved in the original ticket could respond to a 
request for an update,
I only asked for an update about once a week, even with busy schedules I 
would have
thought that that was possible.

I would look into the problem myself, but kernel hacking and hardcore 
XEN development is
not my thing, I did not intend to put anyone's back up about the issue. 
I'd love to fix the
problem myself, and am quite willing to test and debug stuff.

For reference the issue is not a massive deal-breaker for me, but it 
will be when the hardware
clock drifts next, particularly on the production machines which may 
have up to 100 instances
on, it becomes a massive ball-ache to down the server and reboot it just 
to get the instances to
boot with the correct time.

*Niall Fleming BSc. (Hons)*
Systems Administrator
Webanywhere Limited

Phone: 0800 862 0131 Ext: 203
Web: http://www.webanywhere.co.uk

Aire Valley Business Centre, Lawkholme Lane, Keighley, BD21 3BB
Registered in England with company number 4881346

On 01/12/2011 10:28, Laszlo Ersek wrote:
> Hello Niall,
>
> On 12/01/11 10:53, Ian Campbell wrote:
>> On Thu, 2011-12-01 at 08:55 +0000, Niall Fleming wrote:
>>> Cheers, at least I know that someone is still looking at it!
>>>
>>> If someone could give me a general timeframe, like it'll be a month,
>>> before we fix it, or two weeks or whatever, I just need to give my
>>> line manager something so he gets off my case about it!
>>
>> I'm afraid OSS software doesn't generally work like that. If you (or
>> your boss) wants something fixed on a specific time scale or priority
>> you'll have to role your sleeves up and scratch the itch. Otherwise I'm
>> sorry but you will just have to wait until someone has the cycles to
>> look into this issue.
>
> I shouldn't comment on this, because
> - it'll be off-topic, and
> - (more importantly) personally I'm not knowledgeable enough to fix 
> the problem,
>
> but I feel compelled to point out that *in general* it's not about the 
> various rights accompanying the bits (ie. proprietary / open source / 
> free software). It's about who gets to allocate whose resources. Under 
> this aspect it's irrelevant under what rights the end product will be 
> released, the question is instead who backs the effort & costs of the 
> end product being hammered into existence.
>
> Users of FLOSS tend to mix up these two things ("what rights do I have 
> to the code?" vs. "work on this for my sake!"). For the second 
> concept, commercial relationships are (and have always been) the 
> default, even if extremely forthcoming FLOSS developers used to evoke 
> a different impression.
>
> (To make it abundantly clear, this is not an advertisment, and I'm 
> speaking *strictly* personally, for myself alone.)
>
> Laszlo

--------------060601090803010506070408
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit

<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    I wasn't expecting anyone to speed up and fix the issue, I just
    hoped that one or more of<br>
    people who were involved in the original ticket could respond to a
    request for an update, <br>
    I only asked for an update about once a week, even with busy
    schedules I would have<br>
    thought that that was possible.<br>
    <br>
    I would look into the problem myself, but kernel hacking and
    hardcore XEN development is<br>
    not my thing, I did not intend to put anyone's back up about the
    issue. I'd love to fix the <br>
    problem myself, and am quite willing to test and debug stuff.<br>
    <br>
    For reference the issue is not a massive deal-breaker for me, but it
    will be when the hardware<br>
    clock drifts next, particularly on the production machines which may
    have up to 100 instances<br>
    on, it becomes a massive ball-ache to down the server and reboot it
    just to get the instances to<br>
    boot with the correct time.<br>
    <div class="moz-signature"><br>
      <b>Niall Fleming BSc. (Hons)</b><br>
      Systems Administrator<br>
      Webanywhere Limited<br>
      <br>
      Phone: 0800 862 0131 Ext: 203<br>
      Web: <a class="moz-txt-link-freetext" href="http://www.webanywhere.co.uk">http://www.webanywhere.co.uk</a><br>
      <br>
      Aire Valley Business Centre, Lawkholme Lane, Keighley, BD21 3BB<br>
      Registered in England with company number 4881346</div>
    <br>
    On 01/12/2011 10:28, Laszlo Ersek wrote:
    <blockquote cite="mid:4ED756BE.3070309@redhat.com" type="cite">Hello
      Niall,
      <br>
      <br>
      On 12/01/11 10:53, Ian Campbell wrote:
      <br>
      <blockquote type="cite">On Thu, 2011-12-01 at 08:55 +0000, Niall
        Fleming wrote:
        <br>
        <blockquote type="cite">Cheers, at least I know that someone is
          still looking at it!
          <br>
          <br>
          If someone could give me a general timeframe, like it'll be a
          month,
          <br>
          before we fix it, or two weeks or whatever, I just need to
          give my
          <br>
          line manager something so he gets off my case about it!
          <br>
        </blockquote>
        <br>
        I'm afraid OSS software doesn't generally work like that. If you
        (or
        <br>
        your boss) wants something fixed on a specific time scale or
        priority
        <br>
        you'll have to role your sleeves up and scratch the itch.
        Otherwise I'm
        <br>
        sorry but you will just have to wait until someone has the
        cycles to
        <br>
        look into this issue.
        <br>
      </blockquote>
      <br>
      I shouldn't comment on this, because
      <br>
      - it'll be off-topic, and
      <br>
      - (more importantly) personally I'm not knowledgeable enough to
      fix the problem,
      <br>
      <br>
      but I feel compelled to point out that *in general* it's not about
      the various rights accompanying the bits (ie. proprietary / open
      source / free software). It's about who gets to allocate whose
      resources. Under this aspect it's irrelevant under what rights the
      end product will be released, the question is instead who backs
      the effort &amp; costs of the end product being hammered into
      existence.
      <br>
      <br>
      Users of FLOSS tend to mix up these two things ("what rights do I
      have to the code?" vs. "work on this for my sake!"). For the
      second concept, commercial relationships are (and have always
      been) the default, even if extremely forthcoming FLOSS developers
      used to evoke a different impression.
      <br>
      <br>
      (To make it abundantly clear, this is not an advertisment, and I'm
      speaking *strictly* personally, for myself alone.)
      <br>
      <br>
      Laszlo
      <br>
    </blockquote>
  </body>
</html>

--------------060601090803010506070408--


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

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

--===============4245614031396109523==--


From xen-devel-bounces@lists.xensource.com Thu Dec 01 18:17:28 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 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.xensource.com>)
	id 1RWBC7-00030j-WF; Thu, 01 Dec 2011 18:17:16 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <niall.fleming@webanywhere.co.uk>) id 1RWBC6-00030E-My
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 18:17:15 +0000
X-Env-Sender: niall.fleming@webanywhere.co.uk
X-Msg-Ref: server-10.tower-216.messagelabs.com!1322763394!5724926!1
X-Originating-IP: [212.227.17.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjEyLjIyNy4xNy4xMCA9PiA4MDg3MA==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22617 invoked from network); 1 Dec 2011 18:16:34 -0000
Received: from moutng.kundenserver.de (HELO moutng.kundenserver.de)
	(212.227.17.10) by server-10.tower-216.messagelabs.com with SMTP;
	1 Dec 2011 18:16:34 -0000
Received: from [192.168.80.60] (host81-130-62-168.in-addr.btopenworld.com
	[81.130.62.168])
	by mrelayeu.kundenserver.de (node=mrbap0) with ESMTP (Nemesis)
	id 0MKKU2-1RUWkV1V6U-0023ty; Thu, 01 Dec 2011 19:16:06 +0100
Message-ID: <4ED7C464.6040609@webanywhere.co.uk>
Date: Thu, 01 Dec 2011 18:16:04 +0000
From: Niall Fleming <niall.fleming@webanywhere.co.uk>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: Laszlo Ersek <lersek@redhat.com>
References: <4EBD5AA0.3090906@webanywhere.co.uk>	
	<20111111183913.GA9283@phenom.dumpdata.com>	
	<4EC0F20D0200007800060B7D@nat28.tlf.novell.com>	
	<20111114180045.GA14517@phenom.dumpdata.com>	<4EC16CA7.70901@goop.org>	
	<20111116142604.GA7476@phenom.dumpdata.com>	
	<4ED662B0.8060105@webanywhere.co.uk>	
	<20111130222628.GE16651@andromeda.dapyr.net>	
	<4ED740FD.4070603@webanywhere.co.uk>
	<1322733206.31810.173.camel@zakaz.uk.xensource.com>
	<4ED756BE.3070309@redhat.com>
In-Reply-To: <4ED756BE.3070309@redhat.com>
X-Provags-ID: V02:K0:QNLY489ifQozEeYNH3RxKlrg9x/wwug4AmVFzDtNhDO
	sdaxPPpvtjdvU25rS/hqTu3rHLT0tnwB/nVwU6XPpeI2zntatm
	7pPiRrnvgs0rO16aua6uzxnem2b/ZjRdIPdEpAZ9HGhPYLpnta
	wPNEZp5bMMBYEH2TWIgE9DP+J/4b0Ohi+aC7BKtBbnFGR2Bpnn
	bIhr6KwWtfLwUjr0Fx/J2avz552pYc1G3ehBMy5JekIHEaaMTH
	J7ywDgbNJTZci0GYzelLS8x6O6QS20mzB/p98WGKUScOsiyx8u
	jzCo+clwAxnneLi5zXW4mxwEw+hvbSsZEF4fekICRE9k2Pa2+e
	kUeZcwVmz/I0R7lZw7hsTcwngUD+pDSKNTvo90xhx
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"keir.xen@gmail.com" <keir.xen@gmail.com>, Jan Beulich <JBeulich@suse.com>,
	"pbonzini@redhat.com" <pbonzini@redhat.com>,
	Konrad Rzeszutek Wilk <konrad@darnok.org>
Subject: Re: [Xen-devel] Time Change Issue Xen 4.1
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============4245614031396109523=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

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

This is a multi-part message in MIME format.
--------------060601090803010506070408
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

I wasn't expecting anyone to speed up and fix the issue, I just hoped 
that one or more of
people who were involved in the original ticket could respond to a 
request for an update,
I only asked for an update about once a week, even with busy schedules I 
would have
thought that that was possible.

I would look into the problem myself, but kernel hacking and hardcore 
XEN development is
not my thing, I did not intend to put anyone's back up about the issue. 
I'd love to fix the
problem myself, and am quite willing to test and debug stuff.

For reference the issue is not a massive deal-breaker for me, but it 
will be when the hardware
clock drifts next, particularly on the production machines which may 
have up to 100 instances
on, it becomes a massive ball-ache to down the server and reboot it just 
to get the instances to
boot with the correct time.

*Niall Fleming BSc. (Hons)*
Systems Administrator
Webanywhere Limited

Phone: 0800 862 0131 Ext: 203
Web: http://www.webanywhere.co.uk

Aire Valley Business Centre, Lawkholme Lane, Keighley, BD21 3BB
Registered in England with company number 4881346

On 01/12/2011 10:28, Laszlo Ersek wrote:
> Hello Niall,
>
> On 12/01/11 10:53, Ian Campbell wrote:
>> On Thu, 2011-12-01 at 08:55 +0000, Niall Fleming wrote:
>>> Cheers, at least I know that someone is still looking at it!
>>>
>>> If someone could give me a general timeframe, like it'll be a month,
>>> before we fix it, or two weeks or whatever, I just need to give my
>>> line manager something so he gets off my case about it!
>>
>> I'm afraid OSS software doesn't generally work like that. If you (or
>> your boss) wants something fixed on a specific time scale or priority
>> you'll have to role your sleeves up and scratch the itch. Otherwise I'm
>> sorry but you will just have to wait until someone has the cycles to
>> look into this issue.
>
> I shouldn't comment on this, because
> - it'll be off-topic, and
> - (more importantly) personally I'm not knowledgeable enough to fix 
> the problem,
>
> but I feel compelled to point out that *in general* it's not about the 
> various rights accompanying the bits (ie. proprietary / open source / 
> free software). It's about who gets to allocate whose resources. Under 
> this aspect it's irrelevant under what rights the end product will be 
> released, the question is instead who backs the effort & costs of the 
> end product being hammered into existence.
>
> Users of FLOSS tend to mix up these two things ("what rights do I have 
> to the code?" vs. "work on this for my sake!"). For the second 
> concept, commercial relationships are (and have always been) the 
> default, even if extremely forthcoming FLOSS developers used to evoke 
> a different impression.
>
> (To make it abundantly clear, this is not an advertisment, and I'm 
> speaking *strictly* personally, for myself alone.)
>
> Laszlo

--------------060601090803010506070408
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit

<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    I wasn't expecting anyone to speed up and fix the issue, I just
    hoped that one or more of<br>
    people who were involved in the original ticket could respond to a
    request for an update, <br>
    I only asked for an update about once a week, even with busy
    schedules I would have<br>
    thought that that was possible.<br>
    <br>
    I would look into the problem myself, but kernel hacking and
    hardcore XEN development is<br>
    not my thing, I did not intend to put anyone's back up about the
    issue. I'd love to fix the <br>
    problem myself, and am quite willing to test and debug stuff.<br>
    <br>
    For reference the issue is not a massive deal-breaker for me, but it
    will be when the hardware<br>
    clock drifts next, particularly on the production machines which may
    have up to 100 instances<br>
    on, it becomes a massive ball-ache to down the server and reboot it
    just to get the instances to<br>
    boot with the correct time.<br>
    <div class="moz-signature"><br>
      <b>Niall Fleming BSc. (Hons)</b><br>
      Systems Administrator<br>
      Webanywhere Limited<br>
      <br>
      Phone: 0800 862 0131 Ext: 203<br>
      Web: <a class="moz-txt-link-freetext" href="http://www.webanywhere.co.uk">http://www.webanywhere.co.uk</a><br>
      <br>
      Aire Valley Business Centre, Lawkholme Lane, Keighley, BD21 3BB<br>
      Registered in England with company number 4881346</div>
    <br>
    On 01/12/2011 10:28, Laszlo Ersek wrote:
    <blockquote cite="mid:4ED756BE.3070309@redhat.com" type="cite">Hello
      Niall,
      <br>
      <br>
      On 12/01/11 10:53, Ian Campbell wrote:
      <br>
      <blockquote type="cite">On Thu, 2011-12-01 at 08:55 +0000, Niall
        Fleming wrote:
        <br>
        <blockquote type="cite">Cheers, at least I know that someone is
          still looking at it!
          <br>
          <br>
          If someone could give me a general timeframe, like it'll be a
          month,
          <br>
          before we fix it, or two weeks or whatever, I just need to
          give my
          <br>
          line manager something so he gets off my case about it!
          <br>
        </blockquote>
        <br>
        I'm afraid OSS software doesn't generally work like that. If you
        (or
        <br>
        your boss) wants something fixed on a specific time scale or
        priority
        <br>
        you'll have to role your sleeves up and scratch the itch.
        Otherwise I'm
        <br>
        sorry but you will just have to wait until someone has the
        cycles to
        <br>
        look into this issue.
        <br>
      </blockquote>
      <br>
      I shouldn't comment on this, because
      <br>
      - it'll be off-topic, and
      <br>
      - (more importantly) personally I'm not knowledgeable enough to
      fix the problem,
      <br>
      <br>
      but I feel compelled to point out that *in general* it's not about
      the various rights accompanying the bits (ie. proprietary / open
      source / free software). It's about who gets to allocate whose
      resources. Under this aspect it's irrelevant under what rights the
      end product will be released, the question is instead who backs
      the effort &amp; costs of the end product being hammered into
      existence.
      <br>
      <br>
      Users of FLOSS tend to mix up these two things ("what rights do I
      have to the code?" vs. "work on this for my sake!"). For the
      second concept, commercial relationships are (and have always
      been) the default, even if extremely forthcoming FLOSS developers
      used to evoke a different impression.
      <br>
      <br>
      (To make it abundantly clear, this is not an advertisment, and I'm
      speaking *strictly* personally, for myself alone.)
      <br>
      <br>
      Laszlo
      <br>
    </blockquote>
  </body>
</html>

--------------060601090803010506070408--


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

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

--===============4245614031396109523==--


From xen-devel-bounces@lists.xensource.com Thu Dec 01 18:20:04 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 18:20:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWBEe-0003F7-Sk; Thu, 01 Dec 2011 18:19:52 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RWBEd-0003EZ-Lc
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 18:19:51 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1322763429!46650352!1
X-Originating-IP: [209.85.216.50]
X-SpamReason: No, hits=1.1 required=7.0 tests=DATE_IN_PAST_06_12,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 785 invoked from network); 1 Dec 2011 18:17:10 -0000
Received: from mail-qw0-f50.google.com (HELO mail-qw0-f50.google.com)
	(209.85.216.50)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 18:17:10 -0000
Received: by qabg14 with SMTP id g14so3199935qab.9
	for <xen-devel@lists.xensource.com>;
	Thu, 01 Dec 2011 10:19:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=Ct3Wl0kikpHpls2H/gpcAUMHrrIm+iigIViJd8oCCP8=;
	b=VQCQk6QykS9Sg3+q3EGAS4QGut5WATn2M6oKsoeCIzRaXt4I88O6Sz4Ml16uD3EVuL
	rnjhuVp0D5ujWmifmFsMbXTFyG/qomjZgApaqF69GlKYLq3R5SNeGE22QtbuOYqwdV66
	w+fRkH+WmKThXI1WZjpWvA7SlyXDOG/powc/k=
Received: by 10.182.45.102 with SMTP id l6mr1653125obm.0.1322763550371;
	Thu, 01 Dec 2011 10:19:10 -0800 (PST)
Received: from [192.168.0.132] ([142.103.56.220])
	by mx.google.com with ESMTPS id y4sm1549624obj.10.2011.12.01.10.19.07
	(version=SSLv3 cipher=OTHER); Thu, 01 Dec 2011 10:19:09 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Thu, 01 Dec 2011 10:19:05 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Tim Deegan <tim@xen.org>,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <CAFD0519.263F3%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH 2 of 5] Improve ring management for memory
	events. Do not lose guest events
Thread-Index: AcywVbV1dKCMM8UnU0yYYNM7EgeNcA==
In-Reply-To: <20111201181006.GP61203@ocelot.phlegethon.org>
Mime-version: 1.0
Cc: xen-devel@lists.xensource.com, ian.campbell@citrix.com,
	andres@gridcentric.ca, JBeulich@suse.com, ian.jackson@citrix.com,
	adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 2 of 5] Improve ring management for memory
 events. Do not lose guest events
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/12/2011 18:10, "Tim Deegan" <tim@xen.org> wrote:

> At 16:55 -0500 on 29 Nov (1322585711), Andres Lagar-Cavilla wrote:
>> The memevent code currently has a mechanism for reserving space in the ring
>> before putting an event, but each caller must individually ensure that the
>> vCPUs are correctly paused if no space is available.
>> 
>> This fixes that issue by reversing the semantics: we ensure that enough space
>> is always left for one event per vCPU in the ring.  If, after putting the
>> current request, this constraint will be violated by the current vCPU
>> when putting putting another request in the ring, we pause the vCPU.
> 
> What about operations that touch more than one page of guest memory?
> (E.g., pagetable walks, emulated faults and task switches).  Can't they
> still fill up the ring?
> 
> IIRC there are still cases where we need wait-queues anyway (when we hit
> a paged-out page after an non-idempotent action has already been
> taken).  Is the purpose of this change just to reduce the number of
> wait-queue uses or do you think you can do without them entirely?

It's definitely not possible to do without entirely. I'm pretty sure Andres
agrees at least that far.

 -- Keir

> Cheers,
> 
> Tim.



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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 18:20:04 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 18:20:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWBEe-0003F7-Sk; Thu, 01 Dec 2011 18:19:52 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RWBEd-0003EZ-Lc
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 18:19:51 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1322763429!46650352!1
X-Originating-IP: [209.85.216.50]
X-SpamReason: No, hits=1.1 required=7.0 tests=DATE_IN_PAST_06_12,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 785 invoked from network); 1 Dec 2011 18:17:10 -0000
Received: from mail-qw0-f50.google.com (HELO mail-qw0-f50.google.com)
	(209.85.216.50)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 18:17:10 -0000
Received: by qabg14 with SMTP id g14so3199935qab.9
	for <xen-devel@lists.xensource.com>;
	Thu, 01 Dec 2011 10:19:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=Ct3Wl0kikpHpls2H/gpcAUMHrrIm+iigIViJd8oCCP8=;
	b=VQCQk6QykS9Sg3+q3EGAS4QGut5WATn2M6oKsoeCIzRaXt4I88O6Sz4Ml16uD3EVuL
	rnjhuVp0D5ujWmifmFsMbXTFyG/qomjZgApaqF69GlKYLq3R5SNeGE22QtbuOYqwdV66
	w+fRkH+WmKThXI1WZjpWvA7SlyXDOG/powc/k=
Received: by 10.182.45.102 with SMTP id l6mr1653125obm.0.1322763550371;
	Thu, 01 Dec 2011 10:19:10 -0800 (PST)
Received: from [192.168.0.132] ([142.103.56.220])
	by mx.google.com with ESMTPS id y4sm1549624obj.10.2011.12.01.10.19.07
	(version=SSLv3 cipher=OTHER); Thu, 01 Dec 2011 10:19:09 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Thu, 01 Dec 2011 10:19:05 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Tim Deegan <tim@xen.org>,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <CAFD0519.263F3%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH 2 of 5] Improve ring management for memory
	events. Do not lose guest events
Thread-Index: AcywVbV1dKCMM8UnU0yYYNM7EgeNcA==
In-Reply-To: <20111201181006.GP61203@ocelot.phlegethon.org>
Mime-version: 1.0
Cc: xen-devel@lists.xensource.com, ian.campbell@citrix.com,
	andres@gridcentric.ca, JBeulich@suse.com, ian.jackson@citrix.com,
	adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 2 of 5] Improve ring management for memory
 events. Do not lose guest events
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/12/2011 18:10, "Tim Deegan" <tim@xen.org> wrote:

> At 16:55 -0500 on 29 Nov (1322585711), Andres Lagar-Cavilla wrote:
>> The memevent code currently has a mechanism for reserving space in the ring
>> before putting an event, but each caller must individually ensure that the
>> vCPUs are correctly paused if no space is available.
>> 
>> This fixes that issue by reversing the semantics: we ensure that enough space
>> is always left for one event per vCPU in the ring.  If, after putting the
>> current request, this constraint will be violated by the current vCPU
>> when putting putting another request in the ring, we pause the vCPU.
> 
> What about operations that touch more than one page of guest memory?
> (E.g., pagetable walks, emulated faults and task switches).  Can't they
> still fill up the ring?
> 
> IIRC there are still cases where we need wait-queues anyway (when we hit
> a paged-out page after an non-idempotent action has already been
> taken).  Is the purpose of this change just to reduce the number of
> wait-queue uses or do you think you can do without them entirely?

It's definitely not possible to do without entirely. I'm pretty sure Andres
agrees at least that far.

 -- Keir

> Cheers,
> 
> Tim.



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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 18:21:13 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 18: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.xensource.com>)
	id 1RWBFp-0003Lx-Bn; Thu, 01 Dec 2011 18:21:05 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RWBFn-0003LW-UZ
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 18:21:04 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1322763623!3717796!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU2Nw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1583 invoked from network); 1 Dec 2011 18:20:23 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 18:20:23 -0000
X-IronPort-AV: E=Sophos;i="4.71,279,1320624000"; 
   d="scan'208";a="9237944"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Dec 2011 18:20:23 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 1 Dec 2011 18:20:23 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RWBF9-0004EU-2q; Thu, 01 Dec 2011 18:20:23 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RWBF9-0004Ol-20;
	Thu, 01 Dec 2011 18:20:23 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20183.50535.44506.320186@mariner.uk.xensource.com>
Date: Thu, 1 Dec 2011 18:20:23 +0000
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1322240058-29038-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <4ECFC7F3.3080201@tycho.nsa.gov>
	<1322240058-29038-1-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com, konrad.wilk@oracle.com,
	Stefano.Stabellini@eu.citrix.com, Ian.Campbell@eu.citrix.com,
	Vasiliy Tolstov <v.tolstov@ghs.l.google.com>,
	Anil Madhavapeddy <anil@recoil.org>
Subject: Re: [Xen-devel] [PATCH] libxc: Fix checks on grant notify arguments
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Daniel De Graaf writes ("[Xen-devel] [PATCH] libxc: Fix checks on grant notify arguments"):
> The notify offset and event channels are both unsigned variables, so
> testing for >= 0 will not correctly detect the use of -1 to indicate
> the field is unused. Remove the useless comparison and replace with
> correct range checks or comparisons to -1.

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 18:21:13 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 18: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.xensource.com>)
	id 1RWBFp-0003Lx-Bn; Thu, 01 Dec 2011 18:21:05 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RWBFn-0003LW-UZ
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 18:21:04 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1322763623!3717796!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU2Nw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1583 invoked from network); 1 Dec 2011 18:20:23 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 18:20:23 -0000
X-IronPort-AV: E=Sophos;i="4.71,279,1320624000"; 
   d="scan'208";a="9237944"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Dec 2011 18:20:23 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 1 Dec 2011 18:20:23 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RWBF9-0004EU-2q; Thu, 01 Dec 2011 18:20:23 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RWBF9-0004Ol-20;
	Thu, 01 Dec 2011 18:20:23 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20183.50535.44506.320186@mariner.uk.xensource.com>
Date: Thu, 1 Dec 2011 18:20:23 +0000
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1322240058-29038-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <4ECFC7F3.3080201@tycho.nsa.gov>
	<1322240058-29038-1-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com, konrad.wilk@oracle.com,
	Stefano.Stabellini@eu.citrix.com, Ian.Campbell@eu.citrix.com,
	Vasiliy Tolstov <v.tolstov@ghs.l.google.com>,
	Anil Madhavapeddy <anil@recoil.org>
Subject: Re: [Xen-devel] [PATCH] libxc: Fix checks on grant notify arguments
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Daniel De Graaf writes ("[Xen-devel] [PATCH] libxc: Fix checks on grant notify arguments"):
> The notify offset and event channels are both unsigned variables, so
> testing for >= 0 will not correctly detect the use of -1 to indicate
> the field is unused. Remove the useless comparison and replace with
> correct range checks or comparisons to -1.

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 18:22:03 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 18:22:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWBGa-0003SD-QJ; Thu, 01 Dec 2011 18:21:52 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RWBGZ-0003RY-Hb
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 18:21:51 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-14.tower-174.messagelabs.com!1322763670!3707221!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18654 invoked from network); 1 Dec 2011 18:21:11 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-14.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 1 Dec 2011 18:21:11 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RWBFu-000HEv-5F; Thu, 01 Dec 2011 18:21:10 +0000
Date: Thu, 1 Dec 2011 18:21:10 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20111201182110.GQ61203@ocelot.phlegethon.org>
References: <patchbomb.1322760071@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <patchbomb.1322760071@xdev.gridcentric.ca>
User-Agent: Mutt/1.4.2.1i
Cc: ian.jackson@citrix.com, andres@gridcentric.ca,
	xen-devel@lists.xensource.com, olaf@aepfle.de, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 0 of 3] Resend: correctness race when
	paging-in
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 12:21 -0500 on 01 Dec (1322742071), Andres Lagar-Cavilla wrote:
> P2m_mem_paging_prep ensures that an mfn is backing the paged-out gfn, and
> transitions to the next state in the paging state machine for this page. 
> Foreign mappings of the gfn will now succeed. This is the key idea, as it 
> allows the pager to now map the gfn and fill in its contents.
> 
> Unfortunately, it also allows any other foreign mapper to map the gfn and read
> its contents. This is particularly dangerous when the populate is launched
> by a foreign mapper in the first place, which will be actively retrying the
> map operation and might race with the pager. Qemu-dm being a prime example.
> 
> Fix the race by allowing a buffer to be optionally passed in the prep
> operation, and having the hypervisor memcpy from that buffer into the newly
> prepped page before promoting the gfn type.
> 
> Second patch is a tools patch.
> 
> Resent after feedback: xenpaging patch attached, simplified with use of 
> copy_from_guest. Left potntial short-cut to avoid pging_resume for further 
> discussion.
> 
> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

Applied, thanks.

Tim.

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 18:22:03 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 18:22:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWBGa-0003SD-QJ; Thu, 01 Dec 2011 18:21:52 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RWBGZ-0003RY-Hb
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 18:21:51 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-14.tower-174.messagelabs.com!1322763670!3707221!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18654 invoked from network); 1 Dec 2011 18:21:11 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-14.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 1 Dec 2011 18:21:11 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RWBFu-000HEv-5F; Thu, 01 Dec 2011 18:21:10 +0000
Date: Thu, 1 Dec 2011 18:21:10 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20111201182110.GQ61203@ocelot.phlegethon.org>
References: <patchbomb.1322760071@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <patchbomb.1322760071@xdev.gridcentric.ca>
User-Agent: Mutt/1.4.2.1i
Cc: ian.jackson@citrix.com, andres@gridcentric.ca,
	xen-devel@lists.xensource.com, olaf@aepfle.de, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 0 of 3] Resend: correctness race when
	paging-in
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 12:21 -0500 on 01 Dec (1322742071), Andres Lagar-Cavilla wrote:
> P2m_mem_paging_prep ensures that an mfn is backing the paged-out gfn, and
> transitions to the next state in the paging state machine for this page. 
> Foreign mappings of the gfn will now succeed. This is the key idea, as it 
> allows the pager to now map the gfn and fill in its contents.
> 
> Unfortunately, it also allows any other foreign mapper to map the gfn and read
> its contents. This is particularly dangerous when the populate is launched
> by a foreign mapper in the first place, which will be actively retrying the
> map operation and might race with the pager. Qemu-dm being a prime example.
> 
> Fix the race by allowing a buffer to be optionally passed in the prep
> operation, and having the hypervisor memcpy from that buffer into the newly
> prepped page before promoting the gfn type.
> 
> Second patch is a tools patch.
> 
> Resent after feedback: xenpaging patch attached, simplified with use of 
> copy_from_guest. Left potntial short-cut to avoid pging_resume for further 
> discussion.
> 
> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

Applied, thanks.

Tim.

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 18:24:11 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 18: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.xensource.com>)
	id 1RWBId-0003h1-H7; Thu, 01 Dec 2011 18:23:59 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RWBIb-0003gN-Mb
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 18:23:57 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-13.tower-21.messagelabs.com!1322763797!4610386!1
X-Originating-IP: [208.97.132.83]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi44MyA9PiAxNTQ4OQ==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4497 invoked from network); 1 Dec 2011 18:23:17 -0000
Received: from caiajhbdcaid.dreamhost.com (HELO homiemail-a23.g.dreamhost.com)
	(208.97.132.83) by server-13.tower-21.messagelabs.com with SMTP;
	1 Dec 2011 18:23:17 -0000
Received: from homiemail-a23.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a23.g.dreamhost.com (Postfix) with ESMTP id BB7DF4B0091;
	Thu,  1 Dec 2011 10:23:16 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=N6I0zN9NyzCwG6OrMvQq4y2WyUDtVfIOazqIm8MoRaV9
	n+/OsAo2uD8Lb5opz8VydAjcxvOpx21NHc1ycJlEOejywp+ULnlQvgG7lv09Eqe2
	hKJvIO905bpzzfQ0RBzOZ+mjELIknJcL7bIYgsEiaiWbI0sDwz5NbI7PwzWo2AE=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=SYF1R+S9EqH22NyoO4LFHjRgMjI=; b=u4h+3GhT
	RQAV9cbjzeHmGZDEdaL5Fs6icC2VVGEBSdzQeOU0tUst3piFTE/cbR+YjAhAjdGk
	NI/BRD9QbkKENmV2TvpH6TtiVkEgLPQihwO2HUV80q/szXGh08oDsdleFMLKMTNj
	Ip9y28+k8HrZv/BXdhFF7/7zVgSPvzXE3e0=
Received: from webmail.lagarcavilla.org (ahfbbjcaiaae.dreamhost.com
	[75.119.208.4]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a23.g.dreamhost.com (Postfix) with ESMTPA id 1BCCD4B0062; 
	Thu,  1 Dec 2011 10:23:16 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP; Thu, 1 Dec 2011 10:23:16 -0800
Message-ID: <0851751b78cddf678a6d0f99ad958e55.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20111201181006.GP61203@ocelot.phlegethon.org>
References: <patchbomb.1322603709@xdev.gridcentric.ca>
	<43dc614d543cdf84189d.1322603711@xdev.gridcentric.ca>
	<20111201181006.GP61203@ocelot.phlegethon.org>
Date: Thu, 1 Dec 2011 10:23:16 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Tim Deegan" <tim@xen.org>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, ian.campbell@citrix.com,
	andres@gridcentric.ca, keir.xen@gmail.com, jbeulich@suse.com,
	ian.jackson@citrix.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 2 of 5] Improve ring management for memory
 events. Do not lose guest events
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> At 16:55 -0500 on 29 Nov (1322585711), Andres Lagar-Cavilla wrote:
>> The memevent code currently has a mechanism for reserving space in the
>> ring
>> before putting an event, but each caller must individually ensure that
>> the
>> vCPUs are correctly paused if no space is available.
>>
>> This fixes that issue by reversing the semantics: we ensure that enough
>> space
>> is always left for one event per vCPU in the ring.  If, after putting
>> the
>> current request, this constraint will be violated by the current vCPU
>> when putting putting another request in the ring, we pause the vCPU.
>
> What about operations that touch more than one page of guest memory?
> (E.g., pagetable walks, emulated faults and task switches).  Can't they
> still fill up the ring?
Those only generate events on paging, which would go to sleep on the first
fault with a wait queue.

There is one case in which the guest vcpu can generate unbound events, and
that is balloon down -> decrease_reservation -> paging_drop events. I
handle that with preemption of the decrease_reservation hypercall.

>
> IIRC there are still cases where we need wait-queues anyway (when we hit
> a paged-out page after an non-idempotent action has already been
> taken).  Is the purpose of this change just to reduce the number of
> wait-queue uses or do you think you can do without them entirely?

Certainly, there's no way around wait-queues, for, say hvm_copy with a
paged out page.

Andres
>
> Cheers,
>
> Tim.
>



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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 18:24:11 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 18: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.xensource.com>)
	id 1RWBId-0003h1-H7; Thu, 01 Dec 2011 18:23:59 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RWBIb-0003gN-Mb
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 18:23:57 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-13.tower-21.messagelabs.com!1322763797!4610386!1
X-Originating-IP: [208.97.132.83]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi44MyA9PiAxNTQ4OQ==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4497 invoked from network); 1 Dec 2011 18:23:17 -0000
Received: from caiajhbdcaid.dreamhost.com (HELO homiemail-a23.g.dreamhost.com)
	(208.97.132.83) by server-13.tower-21.messagelabs.com with SMTP;
	1 Dec 2011 18:23:17 -0000
Received: from homiemail-a23.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a23.g.dreamhost.com (Postfix) with ESMTP id BB7DF4B0091;
	Thu,  1 Dec 2011 10:23:16 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=N6I0zN9NyzCwG6OrMvQq4y2WyUDtVfIOazqIm8MoRaV9
	n+/OsAo2uD8Lb5opz8VydAjcxvOpx21NHc1ycJlEOejywp+ULnlQvgG7lv09Eqe2
	hKJvIO905bpzzfQ0RBzOZ+mjELIknJcL7bIYgsEiaiWbI0sDwz5NbI7PwzWo2AE=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=SYF1R+S9EqH22NyoO4LFHjRgMjI=; b=u4h+3GhT
	RQAV9cbjzeHmGZDEdaL5Fs6icC2VVGEBSdzQeOU0tUst3piFTE/cbR+YjAhAjdGk
	NI/BRD9QbkKENmV2TvpH6TtiVkEgLPQihwO2HUV80q/szXGh08oDsdleFMLKMTNj
	Ip9y28+k8HrZv/BXdhFF7/7zVgSPvzXE3e0=
Received: from webmail.lagarcavilla.org (ahfbbjcaiaae.dreamhost.com
	[75.119.208.4]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a23.g.dreamhost.com (Postfix) with ESMTPA id 1BCCD4B0062; 
	Thu,  1 Dec 2011 10:23:16 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP; Thu, 1 Dec 2011 10:23:16 -0800
Message-ID: <0851751b78cddf678a6d0f99ad958e55.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20111201181006.GP61203@ocelot.phlegethon.org>
References: <patchbomb.1322603709@xdev.gridcentric.ca>
	<43dc614d543cdf84189d.1322603711@xdev.gridcentric.ca>
	<20111201181006.GP61203@ocelot.phlegethon.org>
Date: Thu, 1 Dec 2011 10:23:16 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Tim Deegan" <tim@xen.org>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, ian.campbell@citrix.com,
	andres@gridcentric.ca, keir.xen@gmail.com, jbeulich@suse.com,
	ian.jackson@citrix.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 2 of 5] Improve ring management for memory
 events. Do not lose guest events
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> At 16:55 -0500 on 29 Nov (1322585711), Andres Lagar-Cavilla wrote:
>> The memevent code currently has a mechanism for reserving space in the
>> ring
>> before putting an event, but each caller must individually ensure that
>> the
>> vCPUs are correctly paused if no space is available.
>>
>> This fixes that issue by reversing the semantics: we ensure that enough
>> space
>> is always left for one event per vCPU in the ring.  If, after putting
>> the
>> current request, this constraint will be violated by the current vCPU
>> when putting putting another request in the ring, we pause the vCPU.
>
> What about operations that touch more than one page of guest memory?
> (E.g., pagetable walks, emulated faults and task switches).  Can't they
> still fill up the ring?
Those only generate events on paging, which would go to sleep on the first
fault with a wait queue.

There is one case in which the guest vcpu can generate unbound events, and
that is balloon down -> decrease_reservation -> paging_drop events. I
handle that with preemption of the decrease_reservation hypercall.

>
> IIRC there are still cases where we need wait-queues anyway (when we hit
> a paged-out page after an non-idempotent action has already been
> taken).  Is the purpose of this change just to reduce the number of
> wait-queue uses or do you think you can do without them entirely?

Certainly, there's no way around wait-queues, for, say hvm_copy with a
paged out page.

Andres
>
> Cheers,
>
> Tim.
>



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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 18:25:37 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 18:25:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWBK3-0003rg-1j; Thu, 01 Dec 2011 18:25:27 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RWBK0-0003rL-PE
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 18:25:24 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1322763854!46235515!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU2Nw==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31813 invoked from network); 1 Dec 2011 18:24:14 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 18:24:14 -0000
X-IronPort-AV: E=Sophos;i="4.71,279,1320624000"; 
   d="scan'208";a="9238008"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Dec 2011 18:24:50 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 1 Dec 2011 18:24:49 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RWBJR-0004G4-IM; Thu, 01 Dec 2011 18:24:49 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RWBJR-0004uq-HO;
	Thu, 01 Dec 2011 18:24:49 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20183.50801.525357.699390@mariner.uk.xensource.com>
Date: Thu, 1 Dec 2011 18:24:49 +0000
To: Jean Guyader <jean.guyader@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <20111125092908.GA11790@spongy.cam.xci-test.com>
References: <1322056319-19725-1-git-send-email-jean.guyader@eu.citrix.com>
	<20174.37746.873433.6131@mariner.uk.xensource.com>
	<20111125092908.GA11790@spongy.cam.xci-test.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"allen.m.kay@intel.com" <allen.m.kay@intel.com>,
	Jean Guyader <Jean.Guyader@citrix.com>
Subject: Re: [Xen-devel] [PATCH 1/3] qemu-xen: Change prototype for
 pt_pci_host_read/write
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Jean Guyader writes ("Re: [Xen-devel] [PATCH 1/3] qemu-xen: Change prototype for pt_pci_host_read/write"):
> I found it more elegant that having to do thing like that:
>         val = pt_pci_host_read(0, PCI_SLOT(pci_dev->devfn),
>                 0, config_addr, len);
> pci_dev is already of the right type.

Right, OK.  I have applied all three of your patches.

Ian.

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 18:25:37 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 18:25:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWBK3-0003rg-1j; Thu, 01 Dec 2011 18:25:27 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RWBK0-0003rL-PE
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 18:25:24 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1322763854!46235515!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU2Nw==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31813 invoked from network); 1 Dec 2011 18:24:14 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 18:24:14 -0000
X-IronPort-AV: E=Sophos;i="4.71,279,1320624000"; 
   d="scan'208";a="9238008"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Dec 2011 18:24:50 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 1 Dec 2011 18:24:49 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RWBJR-0004G4-IM; Thu, 01 Dec 2011 18:24:49 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RWBJR-0004uq-HO;
	Thu, 01 Dec 2011 18:24:49 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20183.50801.525357.699390@mariner.uk.xensource.com>
Date: Thu, 1 Dec 2011 18:24:49 +0000
To: Jean Guyader <jean.guyader@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <20111125092908.GA11790@spongy.cam.xci-test.com>
References: <1322056319-19725-1-git-send-email-jean.guyader@eu.citrix.com>
	<20174.37746.873433.6131@mariner.uk.xensource.com>
	<20111125092908.GA11790@spongy.cam.xci-test.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"allen.m.kay@intel.com" <allen.m.kay@intel.com>,
	Jean Guyader <Jean.Guyader@citrix.com>
Subject: Re: [Xen-devel] [PATCH 1/3] qemu-xen: Change prototype for
 pt_pci_host_read/write
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Jean Guyader writes ("Re: [Xen-devel] [PATCH 1/3] qemu-xen: Change prototype for pt_pci_host_read/write"):
> I found it more elegant that having to do thing like that:
>         val = pt_pci_host_read(0, PCI_SLOT(pci_dev->devfn),
>                 0, config_addr, len);
> pci_dev is already of the right type.

Right, OK.  I have applied all three of your patches.

Ian.

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 18:28:11 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 18: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.xensource.com>)
	id 1RWBMV-00045C-KR; Thu, 01 Dec 2011 18:27:59 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RWBMU-00044j-R9
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 18:27:59 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-7.tower-182.messagelabs.com!1322764038!5448887!1
X-Originating-IP: [208.97.132.207]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4yMDcgPT4gMTU1MDU=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29369 invoked from network); 1 Dec 2011 18:27:18 -0000
Received: from caiajhbdccah.dreamhost.com (HELO homiemail-a22.g.dreamhost.com)
	(208.97.132.207) by server-7.tower-182.messagelabs.com with SMTP;
	1 Dec 2011 18:27:18 -0000
Received: from homiemail-a22.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a22.g.dreamhost.com (Postfix) with ESMTP id 3BF951A8089;
	Thu,  1 Dec 2011 10:27:18 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=DBB1UBkWL+nOPA2cm3f8JYG06Tz4U9PER4l3OeZErwsn
	u0+niYESNrJLoZiBrbyIMJxnSFY/mobiRg7zY8kBmw8mjLROIySBML1MubHT0P9e
	BVw9u37cvxT+jByf6tyO6JG5E9HGyJpeH4ibei0lqw7R2aeqqccoN88l5kyiO34=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=VCpkFzwMiJi1CdIXVrs6shOuMCk=; b=vLn957jY
	tbPS3yjsHOg2P/r4d7E/eJi8cY2vEcF/dYUR56sSb3UMkbQuer0iNN5rEA0dAUKK
	jeSBhUZvmaqFSAl04WhyAEC9tty8P7buPh4lVQnWNK3YBuHHKQtmUgegGUC6yk5L
	V745H2EjlxahXW57PEKQlmPKe8aiIhPd2AI=
Received: from webmail.lagarcavilla.org (ahfbbjcaiaae.dreamhost.com
	[75.119.208.4]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a22.g.dreamhost.com (Postfix) with ESMTPA id D86071A8083; 
	Thu,  1 Dec 2011 10:27:17 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP; Thu, 1 Dec 2011 10:27:18 -0800
Message-ID: <3b11cabf069aee8a2fbb7c9a89addebe.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <CAFD0519.263F3%keir.xen@gmail.com>
References: <CAFD0519.263F3%keir.xen@gmail.com>
Date: Thu, 1 Dec 2011 10:27:18 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Keir Fraser" <keir.xen@gmail.com>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, ian.campbell@citrix.com,
	andres@gridcentric.ca, Tim Deegan <tim@xen.org>,
	jbeulich@suse.com, ian.jackson@citrix.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 2 of 5] Improve ring management for memory
 events. Do not lose guest events
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> On 01/12/2011 18:10, "Tim Deegan" <tim@xen.org> wrote:
>
>> At 16:55 -0500 on 29 Nov (1322585711), Andres Lagar-Cavilla wrote:
>>> The memevent code currently has a mechanism for reserving space in the
>>> ring
>>> before putting an event, but each caller must individually ensure that
>>> the
>>> vCPUs are correctly paused if no space is available.
>>>
>>> This fixes that issue by reversing the semantics: we ensure that enough
>>> space
>>> is always left for one event per vCPU in the ring.  If, after putting
>>> the
>>> current request, this constraint will be violated by the current vCPU
>>> when putting putting another request in the ring, we pause the vCPU.
>>
>> What about operations that touch more than one page of guest memory?
>> (E.g., pagetable walks, emulated faults and task switches).  Can't they
>> still fill up the ring?
>>
>> IIRC there are still cases where we need wait-queues anyway (when we hit
>> a paged-out page after an non-idempotent action has already been
>> taken).  Is the purpose of this change just to reduce the number of
>> wait-queue uses or do you think you can do without them entirely?
>
> It's definitely not possible to do without entirely. I'm pretty sure
> Andres
> agrees at least that far.
I do agree that far :)
Andres

>
>  -- Keir
>
>> Cheers,
>>
>> Tim.
>
>
>



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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 18:28:11 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 18: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.xensource.com>)
	id 1RWBMV-00045C-KR; Thu, 01 Dec 2011 18:27:59 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RWBMU-00044j-R9
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 18:27:59 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-7.tower-182.messagelabs.com!1322764038!5448887!1
X-Originating-IP: [208.97.132.207]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4yMDcgPT4gMTU1MDU=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29369 invoked from network); 1 Dec 2011 18:27:18 -0000
Received: from caiajhbdccah.dreamhost.com (HELO homiemail-a22.g.dreamhost.com)
	(208.97.132.207) by server-7.tower-182.messagelabs.com with SMTP;
	1 Dec 2011 18:27:18 -0000
Received: from homiemail-a22.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a22.g.dreamhost.com (Postfix) with ESMTP id 3BF951A8089;
	Thu,  1 Dec 2011 10:27:18 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=DBB1UBkWL+nOPA2cm3f8JYG06Tz4U9PER4l3OeZErwsn
	u0+niYESNrJLoZiBrbyIMJxnSFY/mobiRg7zY8kBmw8mjLROIySBML1MubHT0P9e
	BVw9u37cvxT+jByf6tyO6JG5E9HGyJpeH4ibei0lqw7R2aeqqccoN88l5kyiO34=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=VCpkFzwMiJi1CdIXVrs6shOuMCk=; b=vLn957jY
	tbPS3yjsHOg2P/r4d7E/eJi8cY2vEcF/dYUR56sSb3UMkbQuer0iNN5rEA0dAUKK
	jeSBhUZvmaqFSAl04WhyAEC9tty8P7buPh4lVQnWNK3YBuHHKQtmUgegGUC6yk5L
	V745H2EjlxahXW57PEKQlmPKe8aiIhPd2AI=
Received: from webmail.lagarcavilla.org (ahfbbjcaiaae.dreamhost.com
	[75.119.208.4]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a22.g.dreamhost.com (Postfix) with ESMTPA id D86071A8083; 
	Thu,  1 Dec 2011 10:27:17 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP; Thu, 1 Dec 2011 10:27:18 -0800
Message-ID: <3b11cabf069aee8a2fbb7c9a89addebe.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <CAFD0519.263F3%keir.xen@gmail.com>
References: <CAFD0519.263F3%keir.xen@gmail.com>
Date: Thu, 1 Dec 2011 10:27:18 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Keir Fraser" <keir.xen@gmail.com>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, ian.campbell@citrix.com,
	andres@gridcentric.ca, Tim Deegan <tim@xen.org>,
	jbeulich@suse.com, ian.jackson@citrix.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 2 of 5] Improve ring management for memory
 events. Do not lose guest events
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> On 01/12/2011 18:10, "Tim Deegan" <tim@xen.org> wrote:
>
>> At 16:55 -0500 on 29 Nov (1322585711), Andres Lagar-Cavilla wrote:
>>> The memevent code currently has a mechanism for reserving space in the
>>> ring
>>> before putting an event, but each caller must individually ensure that
>>> the
>>> vCPUs are correctly paused if no space is available.
>>>
>>> This fixes that issue by reversing the semantics: we ensure that enough
>>> space
>>> is always left for one event per vCPU in the ring.  If, after putting
>>> the
>>> current request, this constraint will be violated by the current vCPU
>>> when putting putting another request in the ring, we pause the vCPU.
>>
>> What about operations that touch more than one page of guest memory?
>> (E.g., pagetable walks, emulated faults and task switches).  Can't they
>> still fill up the ring?
>>
>> IIRC there are still cases where we need wait-queues anyway (when we hit
>> a paged-out page after an non-idempotent action has already been
>> taken).  Is the purpose of this change just to reduce the number of
>> wait-queue uses or do you think you can do without them entirely?
>
> It's definitely not possible to do without entirely. I'm pretty sure
> Andres
> agrees at least that far.
I do agree that far :)
Andres

>
>  -- Keir
>
>> Cheers,
>>
>> Tim.
>
>
>



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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 18:29:29 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 18:29:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWBNm-0004Ao-4u; Thu, 01 Dec 2011 18:29:18 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RWBNk-0004Aa-Sh
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 18:29:17 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1322764116!3844351!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU2Nw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2269 invoked from network); 1 Dec 2011 18:28:37 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 18:28:37 -0000
X-IronPort-AV: E=Sophos;i="4.71,279,1320624000"; 
   d="scan'208";a="9238077"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Dec 2011 18:28:36 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 1 Dec 2011 18:28:36 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RWBN6-0004HG-HQ; Thu, 01 Dec 2011 18:28:36 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RWBN6-0004wJ-Gj;
	Thu, 01 Dec 2011 18:28:36 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20183.51028.504634.590709@mariner.uk.xensource.com>
Date: Thu, 1 Dec 2011 18:28:36 +0000
To: Olaf Hering <olaf@aepfle.de>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <patchbomb.1322228345@probook.site>
References: <patchbomb.1322228345@probook.site>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 0 of 2] tools/hotplug fixes for xen-unstable
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Olaf Hering writes ("[Xen-devel] [PATCH 0 of 2] tools/hotplug fixes for xen-unstable"):
> Update xencommons to avoid error messages in non-Xen environment, and
> load required kernel drivers.

Great, thanks.

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 18:29:29 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 18:29:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWBNm-0004Ao-4u; Thu, 01 Dec 2011 18:29:18 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RWBNk-0004Aa-Sh
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 18:29:17 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1322764116!3844351!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU2Nw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2269 invoked from network); 1 Dec 2011 18:28:37 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 18:28:37 -0000
X-IronPort-AV: E=Sophos;i="4.71,279,1320624000"; 
   d="scan'208";a="9238077"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Dec 2011 18:28:36 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 1 Dec 2011 18:28:36 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RWBN6-0004HG-HQ; Thu, 01 Dec 2011 18:28:36 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RWBN6-0004wJ-Gj;
	Thu, 01 Dec 2011 18:28:36 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20183.51028.504634.590709@mariner.uk.xensource.com>
Date: Thu, 1 Dec 2011 18:28:36 +0000
To: Olaf Hering <olaf@aepfle.de>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <patchbomb.1322228345@probook.site>
References: <patchbomb.1322228345@probook.site>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 0 of 2] tools/hotplug fixes for xen-unstable
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Olaf Hering writes ("[Xen-devel] [PATCH 0 of 2] tools/hotplug fixes for xen-unstable"):
> Update xencommons to avoid error messages in non-Xen environment, and
> load required kernel drivers.

Great, thanks.

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 18:31:59 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 18:31:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWBQB-0004WG-Oz; Thu, 01 Dec 2011 18:31:47 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RWBQA-0004Sr-3m
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 18:31:46 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1322764265!5784930!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU2Nw==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26401 invoked from network); 1 Dec 2011 18:31:05 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 18:31:05 -0000
X-IronPort-AV: E=Sophos;i="4.71,279,1320624000"; 
   d="scan'208";a="9238145"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Dec 2011 18:31:05 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 1 Dec 2011 18:31:05 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RWBPU-0004I2-UW; Thu, 01 Dec 2011 18:31:04 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RWBPU-0004wm-Tm;
	Thu, 01 Dec 2011 18:31:04 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20183.51176.909813.103305@mariner.uk.xensource.com>
Date: Thu, 1 Dec 2011 18:31:04 +0000
To: Philipp Hahn <hahn@univention.de>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <201111252057.31649.hahn@univention.de>
References: <201111251721.12753.hahn@univention.de>
	<201111252057.31649.hahn@univention.de>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [BUG] insufficient quoting between "tap-ctl
	list"	and xend/server/BlktapController.py
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Philipp Hahn writes ("Re: [Xen-devel] [BUG] insufficient quoting between "tap-ctl list" and xend/server/BlktapController.py"):
> As a quick work-around, the attached patch fixes the problem for me. That is, 
> until tap-ctl changes it's output format.

Thanks, I have applied it.

> A more permanent solution would be to add proper quoting / escaping to tap-ctl 
> and un-quoting / de-escaping  to BlktapController.py

xend is pretty much obsolete now and I don't imagine we'll be doing
any rework like that soon I'm afraid.

Ian.

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 18:31:59 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 18:31:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWBQB-0004WG-Oz; Thu, 01 Dec 2011 18:31:47 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RWBQA-0004Sr-3m
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 18:31:46 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1322764265!5784930!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU2Nw==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26401 invoked from network); 1 Dec 2011 18:31:05 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 18:31:05 -0000
X-IronPort-AV: E=Sophos;i="4.71,279,1320624000"; 
   d="scan'208";a="9238145"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Dec 2011 18:31:05 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 1 Dec 2011 18:31:05 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RWBPU-0004I2-UW; Thu, 01 Dec 2011 18:31:04 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RWBPU-0004wm-Tm;
	Thu, 01 Dec 2011 18:31:04 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20183.51176.909813.103305@mariner.uk.xensource.com>
Date: Thu, 1 Dec 2011 18:31:04 +0000
To: Philipp Hahn <hahn@univention.de>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <201111252057.31649.hahn@univention.de>
References: <201111251721.12753.hahn@univention.de>
	<201111252057.31649.hahn@univention.de>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [BUG] insufficient quoting between "tap-ctl
	list"	and xend/server/BlktapController.py
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Philipp Hahn writes ("Re: [Xen-devel] [BUG] insufficient quoting between "tap-ctl list" and xend/server/BlktapController.py"):
> As a quick work-around, the attached patch fixes the problem for me. That is, 
> until tap-ctl changes it's output format.

Thanks, I have applied it.

> A more permanent solution would be to add proper quoting / escaping to tap-ctl 
> and un-quoting / de-escaping  to BlktapController.py

xend is pretty much obsolete now and I don't imagine we'll be doing
any rework like that soon I'm afraid.

Ian.

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 18:40:23 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 18:40:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWBYI-0004yN-IS; Thu, 01 Dec 2011 18:40:10 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Jean.Guyader@citrix.com>) id 1RWBYH-0004yI-8S
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 18:40:09 +0000
X-Env-Sender: Jean.Guyader@citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1322764768!3897580!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU2Nw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13604 invoked from network); 1 Dec 2011 18:39:29 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 18:39:29 -0000
X-IronPort-AV: E=Sophos;i="4.71,279,1320624000"; 
   d="scan'208";a="9238250"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Dec 2011 18:39:28 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 1 Dec 2011 18:39:28 +0000
Received: from spongy.cam.xci-test.com ([10.80.248.53])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<jean.guyader@eu.citrix.com>)	id 1RWBXc-0004L6-5W;
	Thu, 01 Dec 2011 18:39:28 +0000
Received: from jeangu by spongy.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <jean.guyader@eu.citrix.com>)	id 1RWBXM-000379-4s;
	Thu, 01 Dec 2011 18:39:12 +0000
Date: Thu, 1 Dec 2011 18:39:12 +0000
From: Jean Guyader <jean.guyader@eu.citrix.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Message-ID: <20111201183912.GA11938@spongy.cam.xci-test.com>
References: <1322411006-12629-1-git-send-email-jean.guyader@eu.citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1322411006-12629-1-git-send-email-jean.guyader@eu.citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"allen.m.kay@intel.com" <allen.m.kay@intel.com>,
	Jean Guyader <Jean.Guyader@citrix.com>
Subject: Re: [Xen-devel] [PATCH] qemu-xen: Intel GPU passthrough,
	fix OpRegion mapping.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 27/11 04:23, Jean Guyader wrote:
> 
> The OpRegion shouldn't be mapped 1:1 because the address in the host
> can't be used in the guest directly.
> 
> This patch traps read and write access to the opregion of the Intel
> GPU config space (offset 0xfc).
> 
> To work correctly this patch needs a change in hvmloader.
> 
> HVMloader will allocate 2 pages for the OpRegion and write this address
> on the config space of the Intel GPU. Qemu will trap and map the host
> OpRegion to the guest. Any write to this offset after that won't have
> any effect. Any read of this config space offset will return the address
> in the guest.
> 

Ian/Allen,

The pending change to hvmloader has been applied already to xen-unstable.
Is the change alright with you?

Jean

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 18:40:23 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 18:40:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWBYI-0004yN-IS; Thu, 01 Dec 2011 18:40:10 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Jean.Guyader@citrix.com>) id 1RWBYH-0004yI-8S
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 18:40:09 +0000
X-Env-Sender: Jean.Guyader@citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1322764768!3897580!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU2Nw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13604 invoked from network); 1 Dec 2011 18:39:29 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 18:39:29 -0000
X-IronPort-AV: E=Sophos;i="4.71,279,1320624000"; 
   d="scan'208";a="9238250"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Dec 2011 18:39:28 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 1 Dec 2011 18:39:28 +0000
Received: from spongy.cam.xci-test.com ([10.80.248.53])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<jean.guyader@eu.citrix.com>)	id 1RWBXc-0004L6-5W;
	Thu, 01 Dec 2011 18:39:28 +0000
Received: from jeangu by spongy.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <jean.guyader@eu.citrix.com>)	id 1RWBXM-000379-4s;
	Thu, 01 Dec 2011 18:39:12 +0000
Date: Thu, 1 Dec 2011 18:39:12 +0000
From: Jean Guyader <jean.guyader@eu.citrix.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Message-ID: <20111201183912.GA11938@spongy.cam.xci-test.com>
References: <1322411006-12629-1-git-send-email-jean.guyader@eu.citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1322411006-12629-1-git-send-email-jean.guyader@eu.citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"allen.m.kay@intel.com" <allen.m.kay@intel.com>,
	Jean Guyader <Jean.Guyader@citrix.com>
Subject: Re: [Xen-devel] [PATCH] qemu-xen: Intel GPU passthrough,
	fix OpRegion mapping.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 27/11 04:23, Jean Guyader wrote:
> 
> The OpRegion shouldn't be mapped 1:1 because the address in the host
> can't be used in the guest directly.
> 
> This patch traps read and write access to the opregion of the Intel
> GPU config space (offset 0xfc).
> 
> To work correctly this patch needs a change in hvmloader.
> 
> HVMloader will allocate 2 pages for the OpRegion and write this address
> on the config space of the Intel GPU. Qemu will trap and map the host
> OpRegion to the guest. Any write to this offset after that won't have
> any effect. Any read of this config space offset will return the address
> in the guest.
> 

Ian/Allen,

The pending change to hvmloader has been applied already to xen-unstable.
Is the change alright with you?

Jean

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 18:42:00 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 18:42:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWBZr-00052v-78; Thu, 01 Dec 2011 18:41:47 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RWBZp-00052Z-Mx
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 18:41:45 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1322764865!5518101!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU2Nw==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17367 invoked from network); 1 Dec 2011 18:41:05 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 18:41:05 -0000
X-IronPort-AV: E=Sophos;i="4.71,279,1320624000"; 
   d="scan'208";a="9238272"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Dec 2011 18:41:05 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 1 Dec 2011 18:41:05 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RWBZB-0004Lf-5F; Thu, 01 Dec 2011 18:41:05 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RWBZB-00056E-4R;
	Thu, 01 Dec 2011 18:41:05 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20183.51776.938690.267379@mariner.uk.xensource.com>
Date: Thu, 1 Dec 2011 18:41:04 +0000
To: Juergen Gross <juergen.gross@ts.fujitsu.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <patchbomb.1322484359@nehalem1>
References: <patchbomb.1322484359@nehalem1>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 0 of 5] v2: xl scheduler support
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Juergen Gross writes ("[Xen-devel] [PATCH 0 of 5] v2: xl scheduler support"):
> This patch series enhances scheduler support of xl.

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

Thanks,
Ian.

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 18:42:00 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 18:42:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWBZr-00052v-78; Thu, 01 Dec 2011 18:41:47 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RWBZp-00052Z-Mx
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 18:41:45 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1322764865!5518101!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU2Nw==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17367 invoked from network); 1 Dec 2011 18:41:05 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 18:41:05 -0000
X-IronPort-AV: E=Sophos;i="4.71,279,1320624000"; 
   d="scan'208";a="9238272"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Dec 2011 18:41:05 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 1 Dec 2011 18:41:05 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RWBZB-0004Lf-5F; Thu, 01 Dec 2011 18:41:05 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RWBZB-00056E-4R;
	Thu, 01 Dec 2011 18:41:05 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20183.51776.938690.267379@mariner.uk.xensource.com>
Date: Thu, 1 Dec 2011 18:41:04 +0000
To: Juergen Gross <juergen.gross@ts.fujitsu.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <patchbomb.1322484359@nehalem1>
References: <patchbomb.1322484359@nehalem1>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 0 of 5] v2: xl scheduler support
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Juergen Gross writes ("[Xen-devel] [PATCH 0 of 5] v2: xl scheduler support"):
> This patch series enhances scheduler support of xl.

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

Thanks,
Ian.

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 18:43:43 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 18:43:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWBbX-0005AL-Nw; Thu, 01 Dec 2011 18:43:31 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RWBbW-0005AD-9T
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 18:43:30 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1322764944!55054754!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU2Nw==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25410 invoked from network); 1 Dec 2011 18:42:24 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 18:42:24 -0000
X-IronPort-AV: E=Sophos;i="4.71,279,1320624000"; 
   d="scan'208";a="9238296"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Dec 2011 18:42:55 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 1 Dec 2011 18:42:55 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RWBaw-0004MR-Vq; Thu, 01 Dec 2011 18:42:55 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RWBaw-00056Q-V9;
	Thu, 01 Dec 2011 18:42:54 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20183.51886.952171.14230@mariner.uk.xensource.com>
Date: Thu, 1 Dec 2011 18:42:54 +0000
To: Jean Guyader <jean.guyader@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1322411006-12629-1-git-send-email-jean.guyader@eu.citrix.com>
References: <1322411006-12629-1-git-send-email-jean.guyader@eu.citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com, allen.m.kay@intel.com
Subject: Re: [Xen-devel] [PATCH] qemu-xen: Intel GPU passthrough,
	fix OpRegion mapping.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Jean Guyader writes ("[Xen-devel] [PATCH] qemu-xen: Intel GPU passthrough, fix OpRegion mapping."):
> The OpRegion shouldn't be mapped 1:1 because the address in the host
> can't be used in the guest directly.

I confess that I don't understand this area of the code at all.  Would
anyone like to comment on this patch ?

Ian.

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 18:43:43 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 18:43:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWBbX-0005AL-Nw; Thu, 01 Dec 2011 18:43:31 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RWBbW-0005AD-9T
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 18:43:30 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1322764944!55054754!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU2Nw==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25410 invoked from network); 1 Dec 2011 18:42:24 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 18:42:24 -0000
X-IronPort-AV: E=Sophos;i="4.71,279,1320624000"; 
   d="scan'208";a="9238296"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Dec 2011 18:42:55 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 1 Dec 2011 18:42:55 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RWBaw-0004MR-Vq; Thu, 01 Dec 2011 18:42:55 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RWBaw-00056Q-V9;
	Thu, 01 Dec 2011 18:42:54 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20183.51886.952171.14230@mariner.uk.xensource.com>
Date: Thu, 1 Dec 2011 18:42:54 +0000
To: Jean Guyader <jean.guyader@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1322411006-12629-1-git-send-email-jean.guyader@eu.citrix.com>
References: <1322411006-12629-1-git-send-email-jean.guyader@eu.citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com, allen.m.kay@intel.com
Subject: Re: [Xen-devel] [PATCH] qemu-xen: Intel GPU passthrough,
	fix OpRegion mapping.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Jean Guyader writes ("[Xen-devel] [PATCH] qemu-xen: Intel GPU passthrough, fix OpRegion mapping."):
> The OpRegion shouldn't be mapped 1:1 because the address in the host
> can't be used in the guest directly.

I confess that I don't understand this area of the code at all.  Would
anyone like to comment on this patch ?

Ian.

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 18:47:17 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 18: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.xensource.com>)
	id 1RWBew-0005QW-It; Thu, 01 Dec 2011 18:47:02 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RWBev-0005QC-JO
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 18:47:01 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-15.tower-182.messagelabs.com!1322765180!5454655!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNDUxMTM=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNDUxMTM=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19416 invoked from network); 1 Dec 2011 18:46:21 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-15.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 1 Dec 2011 18:46:21 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1322765180; l=4117;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=QHPEoTQEoD7VDabGXq3t1p2DapI=;
	b=LQimNevXN1xGTx7lKMTkAl9t2dnoNzB3YMLapBuH34mi6ue2tkRKY30srGp1vO4oybY
	/N4Jf42N3cf2Dziin8uYa8Xbh9wo6X0dli0cv0SQ0ZVa4U2ofIdQMIGdG/Rg4K4o6O2OK
	xAr5ryMgi9g3KJc6pqI4jg+3fV/4/Wh3l+E=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/ll2c7pE6jG
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-080-213.pools.arcor-ip.net [84.57.80.213])
	by smtp.strato.de (jimi mo16) (RZmta 26.10 AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id L03911nB1H1xZp ;
	Thu, 1 Dec 2011 19:46:17 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id A537618637; Thu,  1 Dec 2011 19:46:16 +0100 (CET)
Date: Thu, 1 Dec 2011 19:46:16 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20111201184616.GA17010@aepfle.de>
References: <mailman.3014.1322742146.12970.xen-devel@lists.xensource.com>
	<782967b2dc26ac23e527e33839e8336f.squirrel@webmail.lagarcavilla.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <782967b2dc26ac23e527e33839e8336f.squirrel@webmail.lagarcavilla.org>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 2 of 4] xenpaging: use wait queues
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Dec 01, Andres Lagar-Cavilla wrote:

> > +    spin_lock_init(&d->arch.hvm_domain.gfn_lock);
> Probably gfn_lock should be replaced with a name a bit more expressive.

Ok, perhaps paged_gfn_queue_lock?

> That notwithstanding, it seems this lock only gets used in the mm layer.
> If so, it should be declared as an mm_lock_t in arch/x86/mm-locks.h, and
> subject to ordering constraints.

Is that really needed? The lock is not taken recursivly. What would be
the benefit of the mm_lock_t in this context? Thats not clear to me.

> Both gfn_lock and the list of wait queues could be collapsed in a single
> struct, so as to decrease pressure on the size of struct domain.

The global lock allows to adjust the number of vcpus, but yes, maybe it
can be moved into p2m_mem_paging_queue_head.


> > +static struct p2m_mem_paging_queue *p2m_mem_paging_get_queue(struct
> > domain *d, unsigned long gfn)
> > +{
> > +    struct p2m_mem_paging_queue_head *h;
> > +    struct p2m_mem_paging_queue *q, *q_match, *q_free;
> > +
> > +    h = d->arch.hvm_domain.gfn_queue;
> > +    q_match = q_free = NULL;
> > +
> > +    spin_lock(&d->arch.hvm_domain.gfn_lock);
> > +
> > +    list_for_each_entry(q, &h->list, list) {
> "Hashing" the gfn ( i.e. gfn & ((1 << order_of_vcpus) - 1) ) and starting
> the linear scan from there would shortcut the common case of finding a
> queued gfn.

I will think about that, good point. Keeping the individual
p2m_mem_paging_queue* in a flat list could be done.

> Checking the p2m type of the gfn for paging in would make the search O(1)
> for the case in which the gfn is not queued.

What type check do you mean? These functions are only called from
within get_gfn_type_access() if p2m_is_paging.

> > +/* Returns 0 if the gfn is still paged */
> > +static int p2m_mem_paging_get_entry(mfn_t *mfn,
> > +               struct p2m_domain *p2m, unsigned long gfn,
> > +               p2m_type_t *t, p2m_access_t *a, p2m_query_t q,
> > +               unsigned int *page_order)
> > +{
> > +    *mfn = p2m->get_entry(p2m, gfn, t, a, q, page_order);
> This will be called in the wake up routine, and it will be racy against
> any concurrent p2m updates.

How is this different from the current code in get_gfn_type_access()?
Is get_gfn_type_access() protected by any lock? I thought that only
p2m_query is allowed to take the p2m_lock?

> > -        /* Evict will fail now, tag this request for pager */
> > -        if ( p2mt == p2m_ram_paging_out )
> > -            req.flags |= MEM_EVENT_FLAG_EVICT_FAIL;
> > +    /* Forward the state only if gfn is in page-out path */
> > +    if ( p2mt == p2m_ram_paging_out || p2mt == p2m_ram_paged ) {
> > +        /* Ignore foreign requests to allow mmap in pager */
> > +        if ( mfn_valid(mfn) && p2mt == p2m_ram_paging_out && v->domain ==
> > d ) {
> > +            /* Restore gfn because it is needed by guest before evict */
> > +            set_p2m_entry(p2m, gfn, mfn, PAGE_ORDER_4K,
> > +                       paging_mode_log_dirty(d) ? p2m_ram_logdirty :
> > p2m_ram_rw, a);
> No event here to tell the pager to cancel its work?

The pager is in the process of writing the gfn to disk after successful
nomination. Its next step is the eviction, which will now fail because
the p2mt is not p2m_ram_paging_out anymore. It is already prepared for
that failure.
The previous MEM_EVENT_FLAG_EVICT_FAIL was not needed in the first
place.

> You're not just adding wait queues, but also short-cutting the state
> machine of paging, which, whilst delicate, works quite well right now. You
> should definitely split that into two patches if possible.

I think that can be done, yes.

> And please keep in mind that there are pagers other than xenpaging, so
> interface churn is a big headache for everyone, if unavoidable.

There will be few changes in the interface in the near future to make it
more robust.


> >          mem_event_put_req_producers(d, &d->mem_event->paging);
> These (mem_event_put_req_producers, foreign_producers) are the kinds of
> things that are really confusing in the ring management side right now.

You are right, the names should be changed in the patched for mem_event.

Olaf

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 18:47:17 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 18: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.xensource.com>)
	id 1RWBew-0005QW-It; Thu, 01 Dec 2011 18:47:02 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RWBev-0005QC-JO
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 18:47:01 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-15.tower-182.messagelabs.com!1322765180!5454655!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNDUxMTM=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNDUxMTM=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19416 invoked from network); 1 Dec 2011 18:46:21 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-15.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 1 Dec 2011 18:46:21 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1322765180; l=4117;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=QHPEoTQEoD7VDabGXq3t1p2DapI=;
	b=LQimNevXN1xGTx7lKMTkAl9t2dnoNzB3YMLapBuH34mi6ue2tkRKY30srGp1vO4oybY
	/N4Jf42N3cf2Dziin8uYa8Xbh9wo6X0dli0cv0SQ0ZVa4U2ofIdQMIGdG/Rg4K4o6O2OK
	xAr5ryMgi9g3KJc6pqI4jg+3fV/4/Wh3l+E=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/ll2c7pE6jG
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-080-213.pools.arcor-ip.net [84.57.80.213])
	by smtp.strato.de (jimi mo16) (RZmta 26.10 AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id L03911nB1H1xZp ;
	Thu, 1 Dec 2011 19:46:17 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id A537618637; Thu,  1 Dec 2011 19:46:16 +0100 (CET)
Date: Thu, 1 Dec 2011 19:46:16 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20111201184616.GA17010@aepfle.de>
References: <mailman.3014.1322742146.12970.xen-devel@lists.xensource.com>
	<782967b2dc26ac23e527e33839e8336f.squirrel@webmail.lagarcavilla.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <782967b2dc26ac23e527e33839e8336f.squirrel@webmail.lagarcavilla.org>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 2 of 4] xenpaging: use wait queues
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Dec 01, Andres Lagar-Cavilla wrote:

> > +    spin_lock_init(&d->arch.hvm_domain.gfn_lock);
> Probably gfn_lock should be replaced with a name a bit more expressive.

Ok, perhaps paged_gfn_queue_lock?

> That notwithstanding, it seems this lock only gets used in the mm layer.
> If so, it should be declared as an mm_lock_t in arch/x86/mm-locks.h, and
> subject to ordering constraints.

Is that really needed? The lock is not taken recursivly. What would be
the benefit of the mm_lock_t in this context? Thats not clear to me.

> Both gfn_lock and the list of wait queues could be collapsed in a single
> struct, so as to decrease pressure on the size of struct domain.

The global lock allows to adjust the number of vcpus, but yes, maybe it
can be moved into p2m_mem_paging_queue_head.


> > +static struct p2m_mem_paging_queue *p2m_mem_paging_get_queue(struct
> > domain *d, unsigned long gfn)
> > +{
> > +    struct p2m_mem_paging_queue_head *h;
> > +    struct p2m_mem_paging_queue *q, *q_match, *q_free;
> > +
> > +    h = d->arch.hvm_domain.gfn_queue;
> > +    q_match = q_free = NULL;
> > +
> > +    spin_lock(&d->arch.hvm_domain.gfn_lock);
> > +
> > +    list_for_each_entry(q, &h->list, list) {
> "Hashing" the gfn ( i.e. gfn & ((1 << order_of_vcpus) - 1) ) and starting
> the linear scan from there would shortcut the common case of finding a
> queued gfn.

I will think about that, good point. Keeping the individual
p2m_mem_paging_queue* in a flat list could be done.

> Checking the p2m type of the gfn for paging in would make the search O(1)
> for the case in which the gfn is not queued.

What type check do you mean? These functions are only called from
within get_gfn_type_access() if p2m_is_paging.

> > +/* Returns 0 if the gfn is still paged */
> > +static int p2m_mem_paging_get_entry(mfn_t *mfn,
> > +               struct p2m_domain *p2m, unsigned long gfn,
> > +               p2m_type_t *t, p2m_access_t *a, p2m_query_t q,
> > +               unsigned int *page_order)
> > +{
> > +    *mfn = p2m->get_entry(p2m, gfn, t, a, q, page_order);
> This will be called in the wake up routine, and it will be racy against
> any concurrent p2m updates.

How is this different from the current code in get_gfn_type_access()?
Is get_gfn_type_access() protected by any lock? I thought that only
p2m_query is allowed to take the p2m_lock?

> > -        /* Evict will fail now, tag this request for pager */
> > -        if ( p2mt == p2m_ram_paging_out )
> > -            req.flags |= MEM_EVENT_FLAG_EVICT_FAIL;
> > +    /* Forward the state only if gfn is in page-out path */
> > +    if ( p2mt == p2m_ram_paging_out || p2mt == p2m_ram_paged ) {
> > +        /* Ignore foreign requests to allow mmap in pager */
> > +        if ( mfn_valid(mfn) && p2mt == p2m_ram_paging_out && v->domain ==
> > d ) {
> > +            /* Restore gfn because it is needed by guest before evict */
> > +            set_p2m_entry(p2m, gfn, mfn, PAGE_ORDER_4K,
> > +                       paging_mode_log_dirty(d) ? p2m_ram_logdirty :
> > p2m_ram_rw, a);
> No event here to tell the pager to cancel its work?

The pager is in the process of writing the gfn to disk after successful
nomination. Its next step is the eviction, which will now fail because
the p2mt is not p2m_ram_paging_out anymore. It is already prepared for
that failure.
The previous MEM_EVENT_FLAG_EVICT_FAIL was not needed in the first
place.

> You're not just adding wait queues, but also short-cutting the state
> machine of paging, which, whilst delicate, works quite well right now. You
> should definitely split that into two patches if possible.

I think that can be done, yes.

> And please keep in mind that there are pagers other than xenpaging, so
> interface churn is a big headache for everyone, if unavoidable.

There will be few changes in the interface in the near future to make it
more robust.


> >          mem_event_put_req_producers(d, &d->mem_event->paging);
> These (mem_event_put_req_producers, foreign_producers) are the kinds of
> things that are really confusing in the ring management side right now.

You are right, the names should be changed in the patched for mem_event.

Olaf

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 18:49:50 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 18:49:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWBhR-0005Z6-5H; Thu, 01 Dec 2011 18:49:37 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RWBhQ-0005Z0-1A
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 18:49:36 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-2.tower-174.messagelabs.com!1322765335!3868146!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMzM1OTc=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMzM1OTc=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25487 invoked from network); 1 Dec 2011 18:48:56 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-2.tower-174.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 1 Dec 2011 18:48:56 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1322765335; l=459;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=XCL9NJZ/06B5M25IOch4wnum7HA=;
	b=L4ZJ4Z+0l1DZ07MYeMmJHhKg/4H2UMwj7xmxlmi01lAAzccZ0pjsct45/LE5v2ZheKs
	p04vx6feUoxCx1og3FAtEBFgUp2FOCEidj52AnPm1ROAALBliEst8P1zvbrNc5Tz5ret8
	9L9wCzwNN8SER6tqrAMx1EByDF/JhF6FZjk=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/ll2c7pE6jG
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-080-213.pools.arcor-ip.net [84.57.80.213])
	by smtp.strato.de (klopstock mo41) (RZmta 26.10 AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id i04d82nB1IX5OE ;
	Thu, 1 Dec 2011 19:48:37 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id C192818637; Thu,  1 Dec 2011 19:48:34 +0100 (CET)
Date: Thu, 1 Dec 2011 19:48:34 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <20111201184834.GB17010@aepfle.de>
References: <patchbomb.1322228345@probook.site>
	<20183.51028.504634.590709@mariner.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20183.51028.504634.590709@mariner.uk.xensource.com>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 0 of 2] tools/hotplug fixes for xen-unstable
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Dec 01, Ian Jackson wrote:

> Olaf Hering writes ("[Xen-devel] [PATCH 0 of 2] tools/hotplug fixes for xen-unstable"):
> > Update xencommons to avoid error messages in non-Xen environment, and
> > load required kernel drivers.
> 
> Great, thanks.
> 
> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
> Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

Ian,

could the modprobe change be backported to 4.1 and maybe even 4.0?

Olaf

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 18:49:50 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 18:49:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWBhR-0005Z6-5H; Thu, 01 Dec 2011 18:49:37 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RWBhQ-0005Z0-1A
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 18:49:36 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-2.tower-174.messagelabs.com!1322765335!3868146!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMzM1OTc=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMzM1OTc=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25487 invoked from network); 1 Dec 2011 18:48:56 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-2.tower-174.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 1 Dec 2011 18:48:56 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1322765335; l=459;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=XCL9NJZ/06B5M25IOch4wnum7HA=;
	b=L4ZJ4Z+0l1DZ07MYeMmJHhKg/4H2UMwj7xmxlmi01lAAzccZ0pjsct45/LE5v2ZheKs
	p04vx6feUoxCx1og3FAtEBFgUp2FOCEidj52AnPm1ROAALBliEst8P1zvbrNc5Tz5ret8
	9L9wCzwNN8SER6tqrAMx1EByDF/JhF6FZjk=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/ll2c7pE6jG
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-080-213.pools.arcor-ip.net [84.57.80.213])
	by smtp.strato.de (klopstock mo41) (RZmta 26.10 AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id i04d82nB1IX5OE ;
	Thu, 1 Dec 2011 19:48:37 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id C192818637; Thu,  1 Dec 2011 19:48:34 +0100 (CET)
Date: Thu, 1 Dec 2011 19:48:34 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <20111201184834.GB17010@aepfle.de>
References: <patchbomb.1322228345@probook.site>
	<20183.51028.504634.590709@mariner.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20183.51028.504634.590709@mariner.uk.xensource.com>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 0 of 2] tools/hotplug fixes for xen-unstable
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Dec 01, Ian Jackson wrote:

> Olaf Hering writes ("[Xen-devel] [PATCH 0 of 2] tools/hotplug fixes for xen-unstable"):
> > Update xencommons to avoid error messages in non-Xen environment, and
> > load required kernel drivers.
> 
> Great, thanks.
> 
> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
> Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

Ian,

could the modprobe change be backported to 4.1 and maybe even 4.0?

Olaf

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 19:28:16 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 19: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.xensource.com>)
	id 1RWCIN-00061e-50; Thu, 01 Dec 2011 19:27:47 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RWCIL-00061Z-5w
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 19:27:45 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1322767609!50551238!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU2Nw==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4363 invoked from network); 1 Dec 2011 19:26:49 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 19:26:49 -0000
X-IronPort-AV: E=Sophos;i="4.71,279,1320624000"; 
   d="scan'208";a="9238909"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Dec 2011 19:27:09 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 1 Dec 2011
	19:27:09 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
In-Reply-To: <20183.49416.735231.548215@mariner.uk.xensource.com>
References: <20183.49416.735231.548215@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
Date: Thu, 1 Dec 2011 19:27:08 +0000
Message-ID: <1322767629.7376.28.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
X-Mailer: Evolution 2.32.3 
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] docs: Say in xm(1) that xm is obsolete
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2011-12-01 at 18:01 +0000, Ian Jackson wrote:
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
> 
> diff -r 3b409f65abae docs/man/xm.pod.1
> --- a/docs/man/xm.pod.1	Thu Dec 01 17:26:48 2011 +0000
> +++ b/docs/man/xm.pod.1	Thu Dec 01 18:01:35 2011 +0000
> @@ -1,6 +1,6 @@
>  =head1 NAME
>  
> -xm - Xen management user interface
> +xm - Obsolete xen management user interface
>  
>  =head1 SYNOPSIS
>  
> @@ -8,10 +8,14 @@ B<xm> I<subcommand> [I<args>]
>  
>  =head1 DESCRIPTION
>  
> -The B<xm> program is the main interface for managing Xen guest
> -domains. The program can be used to create, pause, and shutdown
> -domains. It can also be used to list current domains, enable or pin
> -VCPUs, and attach or detach virtual block devices.
> +This program is now superseded by B<xl>, which should be largely
> +backwards-compatible with B<sm>.

Typo                           ^

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

> +
> +The B<xm> program is the main interface for managing Xen guest domains
> +when the obsolete Xend toolstack is in use. The program can be used to
> +create, pause, and shutdown domains. It can also be used to list
> +current domains, enable or pin VCPUs, and attach or detach virtual
> +block devices.
>  
>  The basic structure of every B<xm> command is almost always:
>  
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 19:28:16 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 19: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.xensource.com>)
	id 1RWCIN-00061e-50; Thu, 01 Dec 2011 19:27:47 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RWCIL-00061Z-5w
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 19:27:45 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1322767609!50551238!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU2Nw==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4363 invoked from network); 1 Dec 2011 19:26:49 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 19:26:49 -0000
X-IronPort-AV: E=Sophos;i="4.71,279,1320624000"; 
   d="scan'208";a="9238909"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Dec 2011 19:27:09 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 1 Dec 2011
	19:27:09 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
In-Reply-To: <20183.49416.735231.548215@mariner.uk.xensource.com>
References: <20183.49416.735231.548215@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
Date: Thu, 1 Dec 2011 19:27:08 +0000
Message-ID: <1322767629.7376.28.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
X-Mailer: Evolution 2.32.3 
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] docs: Say in xm(1) that xm is obsolete
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2011-12-01 at 18:01 +0000, Ian Jackson wrote:
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
> 
> diff -r 3b409f65abae docs/man/xm.pod.1
> --- a/docs/man/xm.pod.1	Thu Dec 01 17:26:48 2011 +0000
> +++ b/docs/man/xm.pod.1	Thu Dec 01 18:01:35 2011 +0000
> @@ -1,6 +1,6 @@
>  =head1 NAME
>  
> -xm - Xen management user interface
> +xm - Obsolete xen management user interface
>  
>  =head1 SYNOPSIS
>  
> @@ -8,10 +8,14 @@ B<xm> I<subcommand> [I<args>]
>  
>  =head1 DESCRIPTION
>  
> -The B<xm> program is the main interface for managing Xen guest
> -domains. The program can be used to create, pause, and shutdown
> -domains. It can also be used to list current domains, enable or pin
> -VCPUs, and attach or detach virtual block devices.
> +This program is now superseded by B<xl>, which should be largely
> +backwards-compatible with B<sm>.

Typo                           ^

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

> +
> +The B<xm> program is the main interface for managing Xen guest domains
> +when the obsolete Xend toolstack is in use. The program can be used to
> +create, pause, and shutdown domains. It can also be used to list
> +current domains, enable or pin VCPUs, and attach or detach virtual
> +block devices.
>  
>  The basic structure of every B<xm> command is almost always:
>  
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 19:28:19 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 19:28:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWCIY-00062R-Uc; Thu, 01 Dec 2011 19:27:58 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RWCIX-00061t-IP
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 19:27:57 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-16.tower-174.messagelabs.com!1322767637!3723239!1
X-Originating-IP: [208.97.132.145]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNDUgPT4gMTY0NTc=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6639 invoked from network); 1 Dec 2011 19:27:17 -0000
Received: from caiajhbdcbef.dreamhost.com (HELO homiemail-a21.g.dreamhost.com)
	(208.97.132.145) by server-16.tower-174.messagelabs.com with SMTP;
	1 Dec 2011 19:27:17 -0000
Received: from homiemail-a21.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTP id 9B68C300061;
	Thu,  1 Dec 2011 11:27:16 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=WdBA+MMHGEt47HHVUw6uSaqSGGTi10liFLLxydWA0j/4
	scnwHBzVV5Df5VxM+fOf95avgNCLxKODkte0MnSTyJVTerfMdrO2KgQliqqnT+Og
	S5XpUgcATgNEV4aaMFGW8tzORhoTARhBnj7OXNPC16y7GhjM8F1LnPefbAeogvU=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=42Ng5ny3yAVOo/2I7BYQh2VpccM=; b=M9rPYc3plrW
	flEc40xYn9/8yWyXBIkZ6g/dmAblMhlml0daB3XgQ6AZkseVm4XQMxSBFRS6scFn
	NQ8LjkhjppjaR7Q2PKK4Gk/kVkGCLfm6EyY1ljHsjBkyihgZf8Cb+dzvd7v/0F9X
	CK8dnRzz0MMIi3Ri/UWS56AXdvAUzmUI=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTPSA id EF1C2300064; 
	Thu,  1 Dec 2011 11:27:15 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: d6cc661d770aa53809c5fffefb8987738d29498b
Message-Id: <d6cc661d770aa53809c5.1322767497@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1322767496@xdev.gridcentric.ca>
References: <patchbomb.1322767496@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Thu, 01 Dec 2011 14:24:57 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, keir.xen@gmail.com, tim@xen.org, JBeulich@suse.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 1 of 3] Improve handling of nested page faults
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/hvm/hvm.c |  14 +++++++++-----
 1 files changed, 9 insertions(+), 5 deletions(-)


Add checks for access type. Be less reliant on implicit semantics.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 2f8d261e3701 -r d6cc661d770a xen/arch/x86/hvm/hvm.c
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -1288,7 +1288,8 @@ int hvm_hap_nested_page_fault(unsigned l
      * If this GFN is emulated MMIO or marked as read-only, pass the fault
      * to the mmio handler.
      */
-    if ( (p2mt == p2m_mmio_dm) || (p2mt == p2m_ram_ro) )
+    if ( (p2mt == p2m_mmio_dm) || 
+         (access_w && (p2mt == p2m_ram_ro)) )
     {
         if ( !handle_mmio() )
             hvm_inject_exception(TRAP_gp_fault, 0, 0);
@@ -1302,7 +1303,7 @@ int hvm_hap_nested_page_fault(unsigned l
         p2m_mem_paging_populate(v->domain, gfn);
 
     /* Mem sharing: unshare the page and try again */
-    if ( p2mt == p2m_ram_shared )
+    if ( access_w && (p2mt == p2m_ram_shared) )
     {
         ASSERT(!p2m_is_nestedp2m(p2m));
         mem_sharing_unshare_page(p2m->domain, gfn, 0);
@@ -1319,14 +1320,17 @@ int hvm_hap_nested_page_fault(unsigned l
          * a large page, we do not change other pages type within that large
          * page.
          */
-        paging_mark_dirty(v->domain, mfn_x(mfn));
-        p2m_change_type(v->domain, gfn, p2m_ram_logdirty, p2m_ram_rw);
+        if ( access_w )
+        {
+            paging_mark_dirty(v->domain, mfn_x(mfn));
+            p2m_change_type(v->domain, gfn, p2m_ram_logdirty, p2m_ram_rw);
+        }
         rc = 1;
         goto out_put_gfn;
     }
 
     /* Shouldn't happen: Maybe the guest was writing to a r/o grant mapping? */
-    if ( p2mt == p2m_grant_map_ro )
+    if ( access_w && (p2mt == p2m_grant_map_ro) )
     {
         gdprintk(XENLOG_WARNING,
                  "trying to write to read-only grant mapping\n");

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 19:28:19 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 19:28:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWCIa-00062v-GE; Thu, 01 Dec 2011 19:28:00 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RWCIY-00061u-Dv
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 19:27:58 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-2.tower-174.messagelabs.com!1322767637!3871505!1
X-Originating-IP: [208.97.132.83]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi44MyA9PiAxNTQ4OQ==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28997 invoked from network); 1 Dec 2011 19:27:18 -0000
Received: from caiajhbdcaid.dreamhost.com (HELO homiemail-a21.g.dreamhost.com)
	(208.97.132.83) by server-2.tower-174.messagelabs.com with SMTP;
	1 Dec 2011 19:27:18 -0000
Received: from homiemail-a21.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTP id 95B20300079;
	Thu,  1 Dec 2011 11:27:17 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=cHNiO0qpj6XaDycZEhmk3f3IEHmz0I8uqIreNQHPWPoy
	8T1q2ugnsokKa2XLqrcsGxtPfs8FKYTr7D6T6ma/gS/ertd6P3TPWMqI3cBRmiW+
	3fxY+LqgRpeDFXokAJzmOyvMqa+JhZ3jsgInUMKAoLYz4HENHUBK7TFbWaJIR5A=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=7oNun7diswQpY9MMd9gLRH9z0+g=; b=BoWj6lcIsVc
	DvLeQ1xO6YYURVj0QUN0dAgUPNKpnVpgDVGG6uHGezTANUDwI6dpDDZlEJVVkGpn
	RfECQXdCm1Dm5RtmydVVlyElGGvw67ZrdYK4ArpMfBlrGvvdg/oP/OAEfCUlmzKk
	EIMmmyqXzV8WO/6WjMN+RcpxArvGN68U=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTPSA id C5E5F300064; 
	Thu,  1 Dec 2011 11:27:16 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 7213610b80031ae8d86d8df0499009569d83dd49
Message-Id: <7213610b80031ae8d86d.1322767498@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1322767496@xdev.gridcentric.ca>
References: <patchbomb.1322767496@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Thu, 01 Dec 2011 14:24:58 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, keir.xen@gmail.com, tim@xen.org, JBeulich@suse.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 2 of 3] x86/mm: When mem event automatically
 promotes access rights, let other subsystems know
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/hvm/hvm.c    |  20 +++++++++++++++-----
 xen/arch/x86/mm/p2m.c     |   8 +++++---
 xen/include/asm-x86/p2m.h |   9 +++++----
 3 files changed, 25 insertions(+), 12 deletions(-)


The mem event fault handler in the p2m can automatically promote the access
rights of a p2m entry. In those scenarios, vcpu's are not paused and they will
immediately retry the faulting instructions. This will generate a second fault
if the underlying entry type requires so (paging, unsharing, pod, etc).
Collapse the two faults into a single one.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r d6cc661d770a -r 7213610b8003 xen/arch/x86/hvm/hvm.c
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -1205,7 +1205,7 @@ int hvm_hap_nested_page_fault(unsigned l
     mfn_t mfn;
     struct vcpu *v = current;
     struct p2m_domain *p2m;
-    int rc;
+    int rc, fall_through = 0;
 
     /* On Nested Virtualization, walk the guest page table.
      * If this succeeds, all is fine.
@@ -1278,9 +1278,15 @@ int hvm_hap_nested_page_fault(unsigned l
 
         if ( violation )
         {
-            p2m_mem_access_check(gpa, gla_valid, gla, access_r, access_w, access_x);
-            rc = 1;
-            goto out_put_gfn;
+            if ( p2m_mem_access_check(gpa, gla_valid, gla, access_r, 
+                                        access_w, access_x) )
+            {
+                fall_through = 1;
+            } else {
+                /* Rights not promoted, vcpu paused, work here is done */
+                rc = 1;
+                goto out_put_gfn;
+            }
         }
     }
 
@@ -1339,7 +1345,11 @@ int hvm_hap_nested_page_fault(unsigned l
         goto out_put_gfn;
     }
 
-    rc = 0;
+    /* 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. */
+    rc = fall_through;
+
 out_put_gfn:
     put_gfn(p2m->domain, gfn);
     return rc;
diff -r d6cc661d770a -r 7213610b8003 xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -1107,7 +1107,7 @@ void p2m_mem_paging_resume(struct domain
     mem_event_unpause_vcpus(d, &d->mem_event->paging);
 }
 
-void p2m_mem_access_check(unsigned long gpa, bool_t gla_valid, unsigned long gla, 
+bool_t p2m_mem_access_check(unsigned long gpa, bool_t gla_valid, unsigned long gla, 
                           bool_t access_r, bool_t access_w, bool_t access_x)
 {
     struct vcpu *v = current;
@@ -1127,7 +1127,7 @@ void p2m_mem_access_check(unsigned long 
     {
         p2m->set_entry(p2m, gfn, mfn, PAGE_ORDER_4K, p2mt, p2m_access_rw);
         p2m_unlock(p2m);
-        return;
+        return 1;
     }
     p2m_unlock(p2m);
 
@@ -1147,9 +1147,10 @@ void p2m_mem_access_check(unsigned long 
             p2m_lock(p2m);
             p2m->set_entry(p2m, gfn, mfn, PAGE_ORDER_4K, p2mt, p2m_access_rwx);
             p2m_unlock(p2m);
+            return 1;
         }
 
-        return;
+        return 0;
     }
 
     memset(&req, 0, sizeof(req));
@@ -1173,6 +1174,7 @@ void p2m_mem_access_check(unsigned long 
 
     (void)mem_event_put_request(d, &d->mem_event->access, &req);
     /* VCPU paused */
+    return 0;
 }
 
 void p2m_mem_access_resume(struct domain *d)
diff -r d6cc661d770a -r 7213610b8003 xen/include/asm-x86/p2m.h
--- a/xen/include/asm-x86/p2m.h
+++ b/xen/include/asm-x86/p2m.h
@@ -491,8 +491,9 @@ static inline void p2m_mem_paging_popula
 
 #ifdef __x86_64__
 /* Send mem event based on the access (gla is -1ull if not available).  Handles
- * the rw2rx conversion */
-void p2m_mem_access_check(unsigned long gpa, bool_t gla_valid, unsigned long gla, 
+ * the rw2rx conversion. Boolean return value indicates if access rights have 
+ * been promoted with no underlying vcpu pause. */
+bool_t p2m_mem_access_check(unsigned long gpa, bool_t gla_valid, unsigned long gla, 
                           bool_t access_r, bool_t access_w, bool_t access_x);
 /* Resumes the running of the VCPU, restarting the last instruction */
 void p2m_mem_access_resume(struct domain *d);
@@ -508,10 +509,10 @@ int p2m_get_mem_access(struct domain *d,
                        hvmmem_access_t *access);
 
 #else
-static inline void p2m_mem_access_check(unsigned long gpa, bool_t gla_valid, 
+static inline bool_t p2m_mem_access_check(unsigned long gpa, bool_t gla_valid, 
                                         unsigned long gla, bool_t access_r, 
                                         bool_t access_w, bool_t access_x)
-{ }
+{ return 1; }
 static inline int p2m_set_mem_access(struct domain *d, 
                                      unsigned long start_pfn, 
                                      uint32_t nr, hvmmem_access_t access)

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 19:28:19 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 19:28:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWCIX-000627-ID; Thu, 01 Dec 2011 19:27:57 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RWCIW-00061o-Is
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 19:27:56 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-14.tower-182.messagelabs.com!1322767636!5518054!1
X-Originating-IP: [208.97.132.145]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNDUgPT4gMTY0NTc=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20033 invoked from network); 1 Dec 2011 19:27:16 -0000
Received: from caiajhbdcbef.dreamhost.com (HELO homiemail-a21.g.dreamhost.com)
	(208.97.132.145) by server-14.tower-182.messagelabs.com with SMTP;
	1 Dec 2011 19:27:16 -0000
Received: from homiemail-a21.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTP id BFDCA300074;
	Thu,  1 Dec 2011 11:27:15 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id:date
	:from:to:cc; q=dns; s=lagarcavilla.org; b=CDWHTeyWmm5ZlhTJFYdive
	Bz7LSYz0Q3xcpywpf3ylbRHD6NvljO5GmNJ0/NG39CSFg2pXWtiLYj0RQtLwRdDf
	RnSpwRJpN0m/NOM2a8lGIs909bljzj6bx5OvtZz/L5ZTJEDCmQMJYuyBY5DTsTPy
	DGRpJi7thh14L0P9Hm5Zk=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:date:from:to:cc; s=lagarcavilla.org; bh=GU86vGWn0AS0
	GpuwqR3qeym2bwY=; b=DKdJKfJotv6UU+1Yg5QIfOCil+2tG6qoemxYkfscqQap
	V4JRu3gOjfiAXCDwtqrslhx5N0+uMDSUuBmRAfoZz8NnLLIDsFGQcGVLq0H3J5Nf
	oWOKacveALaqqcvBUfgxMhelFmnSbIvkxvnZ3ZmKiFxQfvcnVwoH4HfSV0D5ZGE=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTPSA id 2438F300064; 
	Thu,  1 Dec 2011 11:27:15 -0800 (PST)
MIME-Version: 1.0
Message-Id: <patchbomb.1322767496@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Thu, 01 Dec 2011 14:24:56 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, keir.xen@gmail.com, tim@xen.org, JBeulich@suse.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 0 of 3] Mem access improvements and new type
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

We improve the handling of hap faults when both type and access
restrictions are present.

We also add a new p2m access type, n2rwx. It allows for implement a "log
access" mode in the hypervisor, aking to log dirty but for all types of
accesses. Faults caused by this access mode automatically promote the
access rights of the ofending p2m entry, place the event in the ring, and
let the vcpu keep on executing.

Repost after feedback from Tim Deegan.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Signed-off-by: Adin Scannell <adin@scannell.ca>

 xen/arch/x86/hvm/hvm.c          |  14 +++++++++-----
 xen/arch/x86/hvm/hvm.c          |  20 +++++++++++++++-----
 xen/arch/x86/mm/p2m.c           |   8 +++++---
 xen/include/asm-x86/p2m.h       |   9 +++++----
 xen/arch/x86/hvm/hvm.c          |   1 +
 xen/arch/x86/mm/p2m-ept.c       |   1 +
 xen/arch/x86/mm/p2m.c           |  30 +++++++++++++++++++++---------
 xen/include/asm-x86/p2m.h       |   3 +++
 xen/include/public/hvm/hvm_op.h |   3 +++
 9 files changed, 63 insertions(+), 26 deletions(-)

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 19:28:19 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 19:28:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWCIY-00062R-Uc; Thu, 01 Dec 2011 19:27:58 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RWCIX-00061t-IP
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 19:27:57 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-16.tower-174.messagelabs.com!1322767637!3723239!1
X-Originating-IP: [208.97.132.145]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNDUgPT4gMTY0NTc=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6639 invoked from network); 1 Dec 2011 19:27:17 -0000
Received: from caiajhbdcbef.dreamhost.com (HELO homiemail-a21.g.dreamhost.com)
	(208.97.132.145) by server-16.tower-174.messagelabs.com with SMTP;
	1 Dec 2011 19:27:17 -0000
Received: from homiemail-a21.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTP id 9B68C300061;
	Thu,  1 Dec 2011 11:27:16 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=WdBA+MMHGEt47HHVUw6uSaqSGGTi10liFLLxydWA0j/4
	scnwHBzVV5Df5VxM+fOf95avgNCLxKODkte0MnSTyJVTerfMdrO2KgQliqqnT+Og
	S5XpUgcATgNEV4aaMFGW8tzORhoTARhBnj7OXNPC16y7GhjM8F1LnPefbAeogvU=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=42Ng5ny3yAVOo/2I7BYQh2VpccM=; b=M9rPYc3plrW
	flEc40xYn9/8yWyXBIkZ6g/dmAblMhlml0daB3XgQ6AZkseVm4XQMxSBFRS6scFn
	NQ8LjkhjppjaR7Q2PKK4Gk/kVkGCLfm6EyY1ljHsjBkyihgZf8Cb+dzvd7v/0F9X
	CK8dnRzz0MMIi3Ri/UWS56AXdvAUzmUI=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTPSA id EF1C2300064; 
	Thu,  1 Dec 2011 11:27:15 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: d6cc661d770aa53809c5fffefb8987738d29498b
Message-Id: <d6cc661d770aa53809c5.1322767497@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1322767496@xdev.gridcentric.ca>
References: <patchbomb.1322767496@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Thu, 01 Dec 2011 14:24:57 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, keir.xen@gmail.com, tim@xen.org, JBeulich@suse.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 1 of 3] Improve handling of nested page faults
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/hvm/hvm.c |  14 +++++++++-----
 1 files changed, 9 insertions(+), 5 deletions(-)


Add checks for access type. Be less reliant on implicit semantics.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 2f8d261e3701 -r d6cc661d770a xen/arch/x86/hvm/hvm.c
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -1288,7 +1288,8 @@ int hvm_hap_nested_page_fault(unsigned l
      * If this GFN is emulated MMIO or marked as read-only, pass the fault
      * to the mmio handler.
      */
-    if ( (p2mt == p2m_mmio_dm) || (p2mt == p2m_ram_ro) )
+    if ( (p2mt == p2m_mmio_dm) || 
+         (access_w && (p2mt == p2m_ram_ro)) )
     {
         if ( !handle_mmio() )
             hvm_inject_exception(TRAP_gp_fault, 0, 0);
@@ -1302,7 +1303,7 @@ int hvm_hap_nested_page_fault(unsigned l
         p2m_mem_paging_populate(v->domain, gfn);
 
     /* Mem sharing: unshare the page and try again */
-    if ( p2mt == p2m_ram_shared )
+    if ( access_w && (p2mt == p2m_ram_shared) )
     {
         ASSERT(!p2m_is_nestedp2m(p2m));
         mem_sharing_unshare_page(p2m->domain, gfn, 0);
@@ -1319,14 +1320,17 @@ int hvm_hap_nested_page_fault(unsigned l
          * a large page, we do not change other pages type within that large
          * page.
          */
-        paging_mark_dirty(v->domain, mfn_x(mfn));
-        p2m_change_type(v->domain, gfn, p2m_ram_logdirty, p2m_ram_rw);
+        if ( access_w )
+        {
+            paging_mark_dirty(v->domain, mfn_x(mfn));
+            p2m_change_type(v->domain, gfn, p2m_ram_logdirty, p2m_ram_rw);
+        }
         rc = 1;
         goto out_put_gfn;
     }
 
     /* Shouldn't happen: Maybe the guest was writing to a r/o grant mapping? */
-    if ( p2mt == p2m_grant_map_ro )
+    if ( access_w && (p2mt == p2m_grant_map_ro) )
     {
         gdprintk(XENLOG_WARNING,
                  "trying to write to read-only grant mapping\n");

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 19:28:19 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 19:28:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWCIX-000627-ID; Thu, 01 Dec 2011 19:27:57 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RWCIW-00061o-Is
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 19:27:56 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-14.tower-182.messagelabs.com!1322767636!5518054!1
X-Originating-IP: [208.97.132.145]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNDUgPT4gMTY0NTc=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20033 invoked from network); 1 Dec 2011 19:27:16 -0000
Received: from caiajhbdcbef.dreamhost.com (HELO homiemail-a21.g.dreamhost.com)
	(208.97.132.145) by server-14.tower-182.messagelabs.com with SMTP;
	1 Dec 2011 19:27:16 -0000
Received: from homiemail-a21.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTP id BFDCA300074;
	Thu,  1 Dec 2011 11:27:15 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id:date
	:from:to:cc; q=dns; s=lagarcavilla.org; b=CDWHTeyWmm5ZlhTJFYdive
	Bz7LSYz0Q3xcpywpf3ylbRHD6NvljO5GmNJ0/NG39CSFg2pXWtiLYj0RQtLwRdDf
	RnSpwRJpN0m/NOM2a8lGIs909bljzj6bx5OvtZz/L5ZTJEDCmQMJYuyBY5DTsTPy
	DGRpJi7thh14L0P9Hm5Zk=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:date:from:to:cc; s=lagarcavilla.org; bh=GU86vGWn0AS0
	GpuwqR3qeym2bwY=; b=DKdJKfJotv6UU+1Yg5QIfOCil+2tG6qoemxYkfscqQap
	V4JRu3gOjfiAXCDwtqrslhx5N0+uMDSUuBmRAfoZz8NnLLIDsFGQcGVLq0H3J5Nf
	oWOKacveALaqqcvBUfgxMhelFmnSbIvkxvnZ3ZmKiFxQfvcnVwoH4HfSV0D5ZGE=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTPSA id 2438F300064; 
	Thu,  1 Dec 2011 11:27:15 -0800 (PST)
MIME-Version: 1.0
Message-Id: <patchbomb.1322767496@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Thu, 01 Dec 2011 14:24:56 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, keir.xen@gmail.com, tim@xen.org, JBeulich@suse.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 0 of 3] Mem access improvements and new type
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

We improve the handling of hap faults when both type and access
restrictions are present.

We also add a new p2m access type, n2rwx. It allows for implement a "log
access" mode in the hypervisor, aking to log dirty but for all types of
accesses. Faults caused by this access mode automatically promote the
access rights of the ofending p2m entry, place the event in the ring, and
let the vcpu keep on executing.

Repost after feedback from Tim Deegan.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Signed-off-by: Adin Scannell <adin@scannell.ca>

 xen/arch/x86/hvm/hvm.c          |  14 +++++++++-----
 xen/arch/x86/hvm/hvm.c          |  20 +++++++++++++++-----
 xen/arch/x86/mm/p2m.c           |   8 +++++---
 xen/include/asm-x86/p2m.h       |   9 +++++----
 xen/arch/x86/hvm/hvm.c          |   1 +
 xen/arch/x86/mm/p2m-ept.c       |   1 +
 xen/arch/x86/mm/p2m.c           |  30 +++++++++++++++++++++---------
 xen/include/asm-x86/p2m.h       |   3 +++
 xen/include/public/hvm/hvm_op.h |   3 +++
 9 files changed, 63 insertions(+), 26 deletions(-)

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 19:28:19 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 19:28:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWCIa-00062v-GE; Thu, 01 Dec 2011 19:28:00 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RWCIY-00061u-Dv
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 19:27:58 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-2.tower-174.messagelabs.com!1322767637!3871505!1
X-Originating-IP: [208.97.132.83]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi44MyA9PiAxNTQ4OQ==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28997 invoked from network); 1 Dec 2011 19:27:18 -0000
Received: from caiajhbdcaid.dreamhost.com (HELO homiemail-a21.g.dreamhost.com)
	(208.97.132.83) by server-2.tower-174.messagelabs.com with SMTP;
	1 Dec 2011 19:27:18 -0000
Received: from homiemail-a21.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTP id 95B20300079;
	Thu,  1 Dec 2011 11:27:17 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=cHNiO0qpj6XaDycZEhmk3f3IEHmz0I8uqIreNQHPWPoy
	8T1q2ugnsokKa2XLqrcsGxtPfs8FKYTr7D6T6ma/gS/ertd6P3TPWMqI3cBRmiW+
	3fxY+LqgRpeDFXokAJzmOyvMqa+JhZ3jsgInUMKAoLYz4HENHUBK7TFbWaJIR5A=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=7oNun7diswQpY9MMd9gLRH9z0+g=; b=BoWj6lcIsVc
	DvLeQ1xO6YYURVj0QUN0dAgUPNKpnVpgDVGG6uHGezTANUDwI6dpDDZlEJVVkGpn
	RfECQXdCm1Dm5RtmydVVlyElGGvw67ZrdYK4ArpMfBlrGvvdg/oP/OAEfCUlmzKk
	EIMmmyqXzV8WO/6WjMN+RcpxArvGN68U=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTPSA id C5E5F300064; 
	Thu,  1 Dec 2011 11:27:16 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 7213610b80031ae8d86d8df0499009569d83dd49
Message-Id: <7213610b80031ae8d86d.1322767498@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1322767496@xdev.gridcentric.ca>
References: <patchbomb.1322767496@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Thu, 01 Dec 2011 14:24:58 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, keir.xen@gmail.com, tim@xen.org, JBeulich@suse.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 2 of 3] x86/mm: When mem event automatically
 promotes access rights, let other subsystems know
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/hvm/hvm.c    |  20 +++++++++++++++-----
 xen/arch/x86/mm/p2m.c     |   8 +++++---
 xen/include/asm-x86/p2m.h |   9 +++++----
 3 files changed, 25 insertions(+), 12 deletions(-)


The mem event fault handler in the p2m can automatically promote the access
rights of a p2m entry. In those scenarios, vcpu's are not paused and they will
immediately retry the faulting instructions. This will generate a second fault
if the underlying entry type requires so (paging, unsharing, pod, etc).
Collapse the two faults into a single one.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r d6cc661d770a -r 7213610b8003 xen/arch/x86/hvm/hvm.c
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -1205,7 +1205,7 @@ int hvm_hap_nested_page_fault(unsigned l
     mfn_t mfn;
     struct vcpu *v = current;
     struct p2m_domain *p2m;
-    int rc;
+    int rc, fall_through = 0;
 
     /* On Nested Virtualization, walk the guest page table.
      * If this succeeds, all is fine.
@@ -1278,9 +1278,15 @@ int hvm_hap_nested_page_fault(unsigned l
 
         if ( violation )
         {
-            p2m_mem_access_check(gpa, gla_valid, gla, access_r, access_w, access_x);
-            rc = 1;
-            goto out_put_gfn;
+            if ( p2m_mem_access_check(gpa, gla_valid, gla, access_r, 
+                                        access_w, access_x) )
+            {
+                fall_through = 1;
+            } else {
+                /* Rights not promoted, vcpu paused, work here is done */
+                rc = 1;
+                goto out_put_gfn;
+            }
         }
     }
 
@@ -1339,7 +1345,11 @@ int hvm_hap_nested_page_fault(unsigned l
         goto out_put_gfn;
     }
 
-    rc = 0;
+    /* 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. */
+    rc = fall_through;
+
 out_put_gfn:
     put_gfn(p2m->domain, gfn);
     return rc;
diff -r d6cc661d770a -r 7213610b8003 xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -1107,7 +1107,7 @@ void p2m_mem_paging_resume(struct domain
     mem_event_unpause_vcpus(d, &d->mem_event->paging);
 }
 
-void p2m_mem_access_check(unsigned long gpa, bool_t gla_valid, unsigned long gla, 
+bool_t p2m_mem_access_check(unsigned long gpa, bool_t gla_valid, unsigned long gla, 
                           bool_t access_r, bool_t access_w, bool_t access_x)
 {
     struct vcpu *v = current;
@@ -1127,7 +1127,7 @@ void p2m_mem_access_check(unsigned long 
     {
         p2m->set_entry(p2m, gfn, mfn, PAGE_ORDER_4K, p2mt, p2m_access_rw);
         p2m_unlock(p2m);
-        return;
+        return 1;
     }
     p2m_unlock(p2m);
 
@@ -1147,9 +1147,10 @@ void p2m_mem_access_check(unsigned long 
             p2m_lock(p2m);
             p2m->set_entry(p2m, gfn, mfn, PAGE_ORDER_4K, p2mt, p2m_access_rwx);
             p2m_unlock(p2m);
+            return 1;
         }
 
-        return;
+        return 0;
     }
 
     memset(&req, 0, sizeof(req));
@@ -1173,6 +1174,7 @@ void p2m_mem_access_check(unsigned long 
 
     (void)mem_event_put_request(d, &d->mem_event->access, &req);
     /* VCPU paused */
+    return 0;
 }
 
 void p2m_mem_access_resume(struct domain *d)
diff -r d6cc661d770a -r 7213610b8003 xen/include/asm-x86/p2m.h
--- a/xen/include/asm-x86/p2m.h
+++ b/xen/include/asm-x86/p2m.h
@@ -491,8 +491,9 @@ static inline void p2m_mem_paging_popula
 
 #ifdef __x86_64__
 /* Send mem event based on the access (gla is -1ull if not available).  Handles
- * the rw2rx conversion */
-void p2m_mem_access_check(unsigned long gpa, bool_t gla_valid, unsigned long gla, 
+ * the rw2rx conversion. Boolean return value indicates if access rights have 
+ * been promoted with no underlying vcpu pause. */
+bool_t p2m_mem_access_check(unsigned long gpa, bool_t gla_valid, unsigned long gla, 
                           bool_t access_r, bool_t access_w, bool_t access_x);
 /* Resumes the running of the VCPU, restarting the last instruction */
 void p2m_mem_access_resume(struct domain *d);
@@ -508,10 +509,10 @@ int p2m_get_mem_access(struct domain *d,
                        hvmmem_access_t *access);
 
 #else
-static inline void p2m_mem_access_check(unsigned long gpa, bool_t gla_valid, 
+static inline bool_t p2m_mem_access_check(unsigned long gpa, bool_t gla_valid, 
                                         unsigned long gla, bool_t access_r, 
                                         bool_t access_w, bool_t access_x)
-{ }
+{ return 1; }
 static inline int p2m_set_mem_access(struct domain *d, 
                                      unsigned long start_pfn, 
                                      uint32_t nr, hvmmem_access_t access)

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 19:28:20 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 19:28:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWCIa-000636-Tn; Thu, 01 Dec 2011 19:28:00 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RWCIZ-00061w-EG
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 19:27:59 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-14.tower-21.messagelabs.com!1322767638!6611607!1
X-Originating-IP: [208.97.132.74]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi43NCA9PiAxNTcwNQ==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12636 invoked from network); 1 Dec 2011 19:27:19 -0000
Received: from caiajhbdcahe.dreamhost.com (HELO homiemail-a21.g.dreamhost.com)
	(208.97.132.74) by server-14.tower-21.messagelabs.com with SMTP;
	1 Dec 2011 19:27:19 -0000
Received: from homiemail-a21.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTP id 59679300061;
	Thu,  1 Dec 2011 11:27:18 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=AuKVlagDvSLs7kvdHCghFIUMMVAnc8Swa7V/Y6V2LG/O
	z6f6QLlg57jqoqTuXtSORuHVpX1GupvKTpAiSWhrTPNmYSA+qkqRtsp7YFkBotbu
	Ww9fc9ZT0bMl/Lse00ztlJquw2vzLNHLv/rLabrEjfiBDHHdVBobTZ6WTt/yWjA=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=BxXRPc9qAHNyuI3iBvnz1qgsAKA=; b=ZoTaGkb7t/f
	fwk9ha1cSSv1usVWB56KFVTCnWKJKVy1Ae2N920i0U0VSa+9e3G7Tjz8ap4bGfnW
	cH0N+X6ycJHd/tzVX+ybRtmcJSSqR65uRiACIGPScR0q+CC//x9SWkVKrOcDl4dA
	6t6n75oEAWH6n4JKUqtWczAbxnzM78cQ=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTPSA id B8A68300064; 
	Thu,  1 Dec 2011 11:27:17 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 92a379fcef54ff4b0f3595924455e193cfac19ca
Message-Id: <92a379fcef54ff4b0f35.1322767499@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1322767496@xdev.gridcentric.ca>
References: <patchbomb.1322767496@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Thu, 01 Dec 2011 14:24:59 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, keir.xen@gmail.com, tim@xen.org, JBeulich@suse.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 3 of 3] x86/mm: New mem access type to log access
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/hvm/hvm.c          |   1 +
 xen/arch/x86/mm/p2m-ept.c       |   1 +
 xen/arch/x86/mm/p2m.c           |  30 +++++++++++++++++++++---------
 xen/include/asm-x86/p2m.h       |   3 +++
 xen/include/public/hvm/hvm_op.h |   3 +++
 5 files changed, 29 insertions(+), 9 deletions(-)


This patch adds a new p2m access type, n2rwx. It allows for implement a "log
access" mode in the hypervisor, aking to log dirty but for all types of
accesses. Faults caused by this access mode automatically promote the
access rights of the ofending p2m entry, place the event in the ring, and
let the vcpu keep on executing.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Signed-off-by: Adin Scannell <adin@scannell.ca>

diff -r 7213610b8003 -r 92a379fcef54 xen/arch/x86/hvm/hvm.c
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -1250,6 +1250,7 @@ int hvm_hap_nested_page_fault(unsigned l
         switch (p2ma) 
         {
         case p2m_access_n:
+        case p2m_access_n2rwx:
         default:
             violation = access_r || access_w || access_x;
             break;
diff -r 7213610b8003 -r 92a379fcef54 xen/arch/x86/mm/p2m-ept.c
--- a/xen/arch/x86/mm/p2m-ept.c
+++ b/xen/arch/x86/mm/p2m-ept.c
@@ -111,6 +111,7 @@ static void ept_p2m_type_to_flags(ept_en
     switch (access) 
     {
         case p2m_access_n:
+        case p2m_access_n2rwx:
             entry->r = entry->w = entry->x = 0;
             break;
         case p2m_access_r:
diff -r 7213610b8003 -r 92a379fcef54 xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -1129,6 +1129,11 @@ bool_t p2m_mem_access_check(unsigned lon
         p2m_unlock(p2m);
         return 1;
     }
+    else if ( p2ma == p2m_access_n2rwx )
+    {
+        ASSERT(access_w || access_r || access_x);
+        p2m->set_entry(p2m, gfn, mfn, PAGE_ORDER_4K, p2mt, p2m_access_rwx);
+    }
     p2m_unlock(p2m);
 
     /* Otherwise, check if there is a memory event listener, and send the message along */
@@ -1143,10 +1148,13 @@ bool_t p2m_mem_access_check(unsigned lon
         }
         else
         {
-            /* A listener is not required, so clear the access restrictions */
-            p2m_lock(p2m);
-            p2m->set_entry(p2m, gfn, mfn, PAGE_ORDER_4K, p2mt, p2m_access_rwx);
-            p2m_unlock(p2m);
+            if ( p2ma != p2m_access_n2rwx )
+            {
+                /* A listener is not required, so clear the access restrictions */
+                p2m_lock(p2m);
+                p2m->set_entry(p2m, gfn, mfn, PAGE_ORDER_4K, p2mt, p2m_access_rwx);
+                p2m_unlock(p2m);
+            }
             return 1;
         }
 
@@ -1157,9 +1165,12 @@ bool_t p2m_mem_access_check(unsigned lon
     req.type = MEM_EVENT_TYPE_ACCESS;
     req.reason = MEM_EVENT_REASON_VIOLATION;
 
-    /* Pause the current VCPU unconditionally */
-    vcpu_pause_nosync(v);
-    req.flags |= MEM_EVENT_FLAG_VCPU_PAUSED;    
+    /* Pause the current VCPU */
+    if ( p2ma != p2m_access_n2rwx )
+    {
+        vcpu_pause_nosync(v);
+        req.flags |= MEM_EVENT_FLAG_VCPU_PAUSED;
+    } 
 
     /* Send request to mem event */
     req.gfn = gfn;
@@ -1173,8 +1184,8 @@ bool_t p2m_mem_access_check(unsigned lon
     req.vcpu_id = v->vcpu_id;
 
     (void)mem_event_put_request(d, &d->mem_event->access, &req);
-    /* VCPU paused */
-    return 0;
+    /* VCPU may be paused, return whether we promoted automatically */
+    return (p2ma == p2m_access_n2rwx);
 }
 
 void p2m_mem_access_resume(struct domain *d)
@@ -1218,6 +1229,7 @@ int p2m_set_mem_access(struct domain *d,
         p2m_access_wx,
         p2m_access_rwx,
         p2m_access_rx2rw,
+        p2m_access_n2rwx,
         p2m->default_access,
     };
 
diff -r 7213610b8003 -r 92a379fcef54 xen/include/asm-x86/p2m.h
--- a/xen/include/asm-x86/p2m.h
+++ b/xen/include/asm-x86/p2m.h
@@ -108,6 +108,9 @@ typedef enum {
     p2m_access_wx    = 6, 
     p2m_access_rwx   = 7,
     p2m_access_rx2rw = 8, /* Special: page goes from RX to RW on write */
+    p2m_access_n2rwx = 9, /* Special: page goes from N to RWX on access, *
+                           * generates an event but does not pause the
+                           * vcpu */
 
     /* NOTE: Assumed to be only 4 bits right now */
 } p2m_access_t;
diff -r 7213610b8003 -r 92a379fcef54 xen/include/public/hvm/hvm_op.h
--- a/xen/include/public/hvm/hvm_op.h
+++ b/xen/include/public/hvm/hvm_op.h
@@ -174,6 +174,9 @@ typedef enum {
     HVMMEM_access_rwx,
     HVMMEM_access_rx2rw,       /* Page starts off as r-x, but automatically
                                 * change to r-w on a write */
+    HVMMEM_access_n2rwx,       /* Log access: starts off as n, automatically 
+                                * goes to rwx, generating an event without
+                                * pausing the vcpu */
     HVMMEM_access_default      /* Take the domain default */
 } hvmmem_access_t;
 /* Notify that a region of memory is to have specific access types */

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 19:28:20 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 19:28:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWCIa-000636-Tn; Thu, 01 Dec 2011 19:28:00 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RWCIZ-00061w-EG
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 19:27:59 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-14.tower-21.messagelabs.com!1322767638!6611607!1
X-Originating-IP: [208.97.132.74]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi43NCA9PiAxNTcwNQ==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12636 invoked from network); 1 Dec 2011 19:27:19 -0000
Received: from caiajhbdcahe.dreamhost.com (HELO homiemail-a21.g.dreamhost.com)
	(208.97.132.74) by server-14.tower-21.messagelabs.com with SMTP;
	1 Dec 2011 19:27:19 -0000
Received: from homiemail-a21.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTP id 59679300061;
	Thu,  1 Dec 2011 11:27:18 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=AuKVlagDvSLs7kvdHCghFIUMMVAnc8Swa7V/Y6V2LG/O
	z6f6QLlg57jqoqTuXtSORuHVpX1GupvKTpAiSWhrTPNmYSA+qkqRtsp7YFkBotbu
	Ww9fc9ZT0bMl/Lse00ztlJquw2vzLNHLv/rLabrEjfiBDHHdVBobTZ6WTt/yWjA=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=BxXRPc9qAHNyuI3iBvnz1qgsAKA=; b=ZoTaGkb7t/f
	fwk9ha1cSSv1usVWB56KFVTCnWKJKVy1Ae2N920i0U0VSa+9e3G7Tjz8ap4bGfnW
	cH0N+X6ycJHd/tzVX+ybRtmcJSSqR65uRiACIGPScR0q+CC//x9SWkVKrOcDl4dA
	6t6n75oEAWH6n4JKUqtWczAbxnzM78cQ=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTPSA id B8A68300064; 
	Thu,  1 Dec 2011 11:27:17 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 92a379fcef54ff4b0f3595924455e193cfac19ca
Message-Id: <92a379fcef54ff4b0f35.1322767499@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1322767496@xdev.gridcentric.ca>
References: <patchbomb.1322767496@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Thu, 01 Dec 2011 14:24:59 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, keir.xen@gmail.com, tim@xen.org, JBeulich@suse.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 3 of 3] x86/mm: New mem access type to log access
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/hvm/hvm.c          |   1 +
 xen/arch/x86/mm/p2m-ept.c       |   1 +
 xen/arch/x86/mm/p2m.c           |  30 +++++++++++++++++++++---------
 xen/include/asm-x86/p2m.h       |   3 +++
 xen/include/public/hvm/hvm_op.h |   3 +++
 5 files changed, 29 insertions(+), 9 deletions(-)


This patch adds a new p2m access type, n2rwx. It allows for implement a "log
access" mode in the hypervisor, aking to log dirty but for all types of
accesses. Faults caused by this access mode automatically promote the
access rights of the ofending p2m entry, place the event in the ring, and
let the vcpu keep on executing.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Signed-off-by: Adin Scannell <adin@scannell.ca>

diff -r 7213610b8003 -r 92a379fcef54 xen/arch/x86/hvm/hvm.c
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -1250,6 +1250,7 @@ int hvm_hap_nested_page_fault(unsigned l
         switch (p2ma) 
         {
         case p2m_access_n:
+        case p2m_access_n2rwx:
         default:
             violation = access_r || access_w || access_x;
             break;
diff -r 7213610b8003 -r 92a379fcef54 xen/arch/x86/mm/p2m-ept.c
--- a/xen/arch/x86/mm/p2m-ept.c
+++ b/xen/arch/x86/mm/p2m-ept.c
@@ -111,6 +111,7 @@ static void ept_p2m_type_to_flags(ept_en
     switch (access) 
     {
         case p2m_access_n:
+        case p2m_access_n2rwx:
             entry->r = entry->w = entry->x = 0;
             break;
         case p2m_access_r:
diff -r 7213610b8003 -r 92a379fcef54 xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -1129,6 +1129,11 @@ bool_t p2m_mem_access_check(unsigned lon
         p2m_unlock(p2m);
         return 1;
     }
+    else if ( p2ma == p2m_access_n2rwx )
+    {
+        ASSERT(access_w || access_r || access_x);
+        p2m->set_entry(p2m, gfn, mfn, PAGE_ORDER_4K, p2mt, p2m_access_rwx);
+    }
     p2m_unlock(p2m);
 
     /* Otherwise, check if there is a memory event listener, and send the message along */
@@ -1143,10 +1148,13 @@ bool_t p2m_mem_access_check(unsigned lon
         }
         else
         {
-            /* A listener is not required, so clear the access restrictions */
-            p2m_lock(p2m);
-            p2m->set_entry(p2m, gfn, mfn, PAGE_ORDER_4K, p2mt, p2m_access_rwx);
-            p2m_unlock(p2m);
+            if ( p2ma != p2m_access_n2rwx )
+            {
+                /* A listener is not required, so clear the access restrictions */
+                p2m_lock(p2m);
+                p2m->set_entry(p2m, gfn, mfn, PAGE_ORDER_4K, p2mt, p2m_access_rwx);
+                p2m_unlock(p2m);
+            }
             return 1;
         }
 
@@ -1157,9 +1165,12 @@ bool_t p2m_mem_access_check(unsigned lon
     req.type = MEM_EVENT_TYPE_ACCESS;
     req.reason = MEM_EVENT_REASON_VIOLATION;
 
-    /* Pause the current VCPU unconditionally */
-    vcpu_pause_nosync(v);
-    req.flags |= MEM_EVENT_FLAG_VCPU_PAUSED;    
+    /* Pause the current VCPU */
+    if ( p2ma != p2m_access_n2rwx )
+    {
+        vcpu_pause_nosync(v);
+        req.flags |= MEM_EVENT_FLAG_VCPU_PAUSED;
+    } 
 
     /* Send request to mem event */
     req.gfn = gfn;
@@ -1173,8 +1184,8 @@ bool_t p2m_mem_access_check(unsigned lon
     req.vcpu_id = v->vcpu_id;
 
     (void)mem_event_put_request(d, &d->mem_event->access, &req);
-    /* VCPU paused */
-    return 0;
+    /* VCPU may be paused, return whether we promoted automatically */
+    return (p2ma == p2m_access_n2rwx);
 }
 
 void p2m_mem_access_resume(struct domain *d)
@@ -1218,6 +1229,7 @@ int p2m_set_mem_access(struct domain *d,
         p2m_access_wx,
         p2m_access_rwx,
         p2m_access_rx2rw,
+        p2m_access_n2rwx,
         p2m->default_access,
     };
 
diff -r 7213610b8003 -r 92a379fcef54 xen/include/asm-x86/p2m.h
--- a/xen/include/asm-x86/p2m.h
+++ b/xen/include/asm-x86/p2m.h
@@ -108,6 +108,9 @@ typedef enum {
     p2m_access_wx    = 6, 
     p2m_access_rwx   = 7,
     p2m_access_rx2rw = 8, /* Special: page goes from RX to RW on write */
+    p2m_access_n2rwx = 9, /* Special: page goes from N to RWX on access, *
+                           * generates an event but does not pause the
+                           * vcpu */
 
     /* NOTE: Assumed to be only 4 bits right now */
 } p2m_access_t;
diff -r 7213610b8003 -r 92a379fcef54 xen/include/public/hvm/hvm_op.h
--- a/xen/include/public/hvm/hvm_op.h
+++ b/xen/include/public/hvm/hvm_op.h
@@ -174,6 +174,9 @@ typedef enum {
     HVMMEM_access_rwx,
     HVMMEM_access_rx2rw,       /* Page starts off as r-x, but automatically
                                 * change to r-w on a write */
+    HVMMEM_access_n2rwx,       /* Log access: starts off as n, automatically 
+                                * goes to rwx, generating an event without
+                                * pausing the vcpu */
     HVMMEM_access_default      /* Take the domain default */
 } hvmmem_access_t;
 /* Notify that a region of memory is to have specific access types */

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 19:38:11 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 19: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.xensource.com>)
	id 1RWCSB-00072P-0n; Thu, 01 Dec 2011 19:37:55 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pasik@iki.fi>) id 1RWCS9-00072H-E9
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 19:37:53 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-2.tower-182.messagelabs.com!1322768232!5516852!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA0NTUxMDA=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2541 invoked from network); 1 Dec 2011 19:37:13 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-2.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 1 Dec 2011 19:37:13 -0000
X-Originating-Ip: [194.89.68.22]
Received: from ydin.reaktio.net (reaktio.net [194.89.68.22])
	by smtp.tele.fi (Postfix) with ESMTP id 003CD2549;
	Thu,  1 Dec 2011 21:37:11 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id C525E2009A; Thu,  1 Dec 2011 21:37:11 +0200 (EET)
Date: Thu, 1 Dec 2011 21:37:11 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <20111201193711.GK12984@reaktio.net>
References: <201111251721.12753.hahn@univention.de>
	<201111252057.31649.hahn@univention.de>
	<20183.51176.909813.103305@mariner.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20183.51176.909813.103305@mariner.uk.xensource.com>
User-Agent: Mutt/1.5.18 (2008-05-17)
Cc: xen-devel@lists.xensource.com, Philipp Hahn <hahn@univention.de>
Subject: Re: [Xen-devel] [BUG] insufficient quoting between "tap-ctl
	list"	and xend/server/BlktapController.py
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Dec 01, 2011 at 06:31:04PM +0000, Ian Jackson wrote:
> Philipp Hahn writes ("Re: [Xen-devel] [BUG] insufficient quoting between "tap-ctl list" and xend/server/BlktapController.py"):
> > As a quick work-around, the attached patch fixes the problem for me. That is, 
> > until tap-ctl changes it's output format.
> 
> Thanks, I have applied it.
> 
> > A more permanent solution would be to add proper quoting / escaping to tap-ctl 
> > and un-quoting / de-escaping  to BlktapController.py
> 
> xend is pretty much obsolete now and I don't imagine we'll be doing
> any rework like that soon I'm afraid.
> 

I realize xend doesn't get much attention anymore,
but it's still the only way to use some features,
like: pvusb, pvscsi, remus, block scripts, etc..

So it's good to apply at least bugfix patches :) 

-- Pasi


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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 19:38:11 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 19: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.xensource.com>)
	id 1RWCSB-00072P-0n; Thu, 01 Dec 2011 19:37:55 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pasik@iki.fi>) id 1RWCS9-00072H-E9
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 19:37:53 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-2.tower-182.messagelabs.com!1322768232!5516852!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA0NTUxMDA=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2541 invoked from network); 1 Dec 2011 19:37:13 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-2.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 1 Dec 2011 19:37:13 -0000
X-Originating-Ip: [194.89.68.22]
Received: from ydin.reaktio.net (reaktio.net [194.89.68.22])
	by smtp.tele.fi (Postfix) with ESMTP id 003CD2549;
	Thu,  1 Dec 2011 21:37:11 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id C525E2009A; Thu,  1 Dec 2011 21:37:11 +0200 (EET)
Date: Thu, 1 Dec 2011 21:37:11 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <20111201193711.GK12984@reaktio.net>
References: <201111251721.12753.hahn@univention.de>
	<201111252057.31649.hahn@univention.de>
	<20183.51176.909813.103305@mariner.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20183.51176.909813.103305@mariner.uk.xensource.com>
User-Agent: Mutt/1.5.18 (2008-05-17)
Cc: xen-devel@lists.xensource.com, Philipp Hahn <hahn@univention.de>
Subject: Re: [Xen-devel] [BUG] insufficient quoting between "tap-ctl
	list"	and xend/server/BlktapController.py
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Dec 01, 2011 at 06:31:04PM +0000, Ian Jackson wrote:
> Philipp Hahn writes ("Re: [Xen-devel] [BUG] insufficient quoting between "tap-ctl list" and xend/server/BlktapController.py"):
> > As a quick work-around, the attached patch fixes the problem for me. That is, 
> > until tap-ctl changes it's output format.
> 
> Thanks, I have applied it.
> 
> > A more permanent solution would be to add proper quoting / escaping to tap-ctl 
> > and un-quoting / de-escaping  to BlktapController.py
> 
> xend is pretty much obsolete now and I don't imagine we'll be doing
> any rework like that soon I'm afraid.
> 

I realize xend doesn't get much attention anymore,
but it's still the only way to use some features,
like: pvusb, pvscsi, remus, block scripts, etc..

So it's good to apply at least bugfix patches :) 

-- Pasi


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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 19:52:07 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 19:52:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWCfb-0007D8-Ds; Thu, 01 Dec 2011 19:51:47 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RWCfa-0007D3-3X
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 19:51:46 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1322769066!865515!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU2Nw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15613 invoked from network); 1 Dec 2011 19:51:06 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 19:51:06 -0000
X-IronPort-AV: E=Sophos;i="4.71,280,1320624000"; 
   d="scan'208";a="9239079"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Dec 2011 19:51:05 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 1 Dec 2011
	19:51:05 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Pasi =?ISO-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
In-Reply-To: <20111201193711.GK12984@reaktio.net>
References: <201111251721.12753.hahn@univention.de>
	<201111252057.31649.hahn@univention.de>
	<20183.51176.909813.103305@mariner.uk.xensource.com>
	<20111201193711.GK12984@reaktio.net>
Organization: Citrix Systems, Inc.
Date: Thu, 1 Dec 2011 19:51:05 +0000
Message-ID: <1322769065.7376.36.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
X-Mailer: Evolution 2.32.3 
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Philipp Hahn <hahn@univention.de>
Subject: Re: [Xen-devel] [BUG] insufficient quoting between "tap-ctl	list"
 and xend/server/BlktapController.py
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2011-12-01 at 19:37 +0000, Pasi K=E4rkk=E4inen wrote:
> On Thu, Dec 01, 2011 at 06:31:04PM +0000, Ian Jackson wrote:
> > Philipp Hahn writes ("Re: [Xen-devel] [BUG] insufficient quoting betwee=
n "tap-ctl list" and xend/server/BlktapController.py"):
> > > As a quick work-around, the attached patch fixes the problem for me. =
That is, =

> > > until tap-ctl changes it's output format.
> > =

> > Thanks, I have applied it.
> > =

> > > A more permanent solution would be to add proper quoting / escaping t=
o tap-ctl =

> > > and un-quoting / de-escaping  to BlktapController.py
> > =

> > xend is pretty much obsolete now and I don't imagine we'll be doing
> > any rework like that soon I'm afraid.
> > =

> =

> I realize xend doesn't get much attention anymore,
> but it's still the only way to use some features,

xend is deprecated. This ultimately means that xend will go away. If you
are dependent on these features then you need put effort into ensuring
that they become supported in libxl and xl. You should not assume that
xend will be around forever nor that someone else will do this work for
you before xend does go away. In other words people who need these
features need to provide patches for them. (I suppose someone could also
step up and offer to maintain xend properly, I'm not holding my breath
for that).

> like:

> remus, block scripts

AFAIK support for these in xl/libxl these are being worked on.

>  pvusb, pvscsi, =


I'm not aware of any effort to make these work with libxl.

> So it's good to apply at least bugfix patches :) =


TO some extent that just gives people a false sense that they can sit on
xend forever, which is not the case. People need to realise that xend
_is_ going away and they need to start planning accordingly.

> =

> -- Pasi
> =

> =

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



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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 19:52:07 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 19:52:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWCfb-0007D8-Ds; Thu, 01 Dec 2011 19:51:47 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RWCfa-0007D3-3X
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 19:51:46 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1322769066!865515!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU2Nw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15613 invoked from network); 1 Dec 2011 19:51:06 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 19:51:06 -0000
X-IronPort-AV: E=Sophos;i="4.71,280,1320624000"; 
   d="scan'208";a="9239079"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Dec 2011 19:51:05 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 1 Dec 2011
	19:51:05 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Pasi =?ISO-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
In-Reply-To: <20111201193711.GK12984@reaktio.net>
References: <201111251721.12753.hahn@univention.de>
	<201111252057.31649.hahn@univention.de>
	<20183.51176.909813.103305@mariner.uk.xensource.com>
	<20111201193711.GK12984@reaktio.net>
Organization: Citrix Systems, Inc.
Date: Thu, 1 Dec 2011 19:51:05 +0000
Message-ID: <1322769065.7376.36.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
X-Mailer: Evolution 2.32.3 
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Philipp Hahn <hahn@univention.de>
Subject: Re: [Xen-devel] [BUG] insufficient quoting between "tap-ctl	list"
 and xend/server/BlktapController.py
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2011-12-01 at 19:37 +0000, Pasi K=E4rkk=E4inen wrote:
> On Thu, Dec 01, 2011 at 06:31:04PM +0000, Ian Jackson wrote:
> > Philipp Hahn writes ("Re: [Xen-devel] [BUG] insufficient quoting betwee=
n "tap-ctl list" and xend/server/BlktapController.py"):
> > > As a quick work-around, the attached patch fixes the problem for me. =
That is, =

> > > until tap-ctl changes it's output format.
> > =

> > Thanks, I have applied it.
> > =

> > > A more permanent solution would be to add proper quoting / escaping t=
o tap-ctl =

> > > and un-quoting / de-escaping  to BlktapController.py
> > =

> > xend is pretty much obsolete now and I don't imagine we'll be doing
> > any rework like that soon I'm afraid.
> > =

> =

> I realize xend doesn't get much attention anymore,
> but it's still the only way to use some features,

xend is deprecated. This ultimately means that xend will go away. If you
are dependent on these features then you need put effort into ensuring
that they become supported in libxl and xl. You should not assume that
xend will be around forever nor that someone else will do this work for
you before xend does go away. In other words people who need these
features need to provide patches for them. (I suppose someone could also
step up and offer to maintain xend properly, I'm not holding my breath
for that).

> like:

> remus, block scripts

AFAIK support for these in xl/libxl these are being worked on.

>  pvusb, pvscsi, =


I'm not aware of any effort to make these work with libxl.

> So it's good to apply at least bugfix patches :) =


TO some extent that just gives people a false sense that they can sit on
xend forever, which is not the case. People need to realise that xend
_is_ going away and they need to start planning accordingly.

> =

> -- Pasi
> =

> =

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



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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 19:57:37 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 19:57:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWCkz-0007MU-9s; Thu, 01 Dec 2011 19:57:21 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RWCky-0007MO-BM
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 19:57:20 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1322769398!3897868!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU2Nw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16754 invoked from network); 1 Dec 2011 19:56:39 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 19:56:39 -0000
X-IronPort-AV: E=Sophos;i="4.71,280,1320624000"; 
   d="scan'208";a="9239124"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Dec 2011 19:56:38 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 1 Dec 2011 19:56:37 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RWCkH-0004m3-LG;
	Thu, 01 Dec 2011 19:56:37 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RWCkH-0007Of-Kj;
	Thu, 01 Dec 2011 19:56:37 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10211-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 1 Dec 2011 19:56:37 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10211: regressions - trouble:
	blocked/broken/fail/pass
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

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

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-i386-xend-winxpsp3  4 xen-install              fail REGR. vs. 10201
 test-amd64-i386-xl-win7-amd64  4 xen-install              fail REGR. vs. 10201
 test-amd64-i386-xl-winxpsp3-vcpus1  4 xen-install         fail REGR. vs. 10201
 test-amd64-i386-pv            4 xen-install               fail REGR. vs. 10201
 test-amd64-i386-xl-multivcpu  4 xen-install               fail REGR. vs. 10201
 test-amd64-i386-xl            4 xen-install               fail REGR. vs. 10201
 test-amd64-i386-pair          6 xen-install/dst_host      fail REGR. vs. 10201
 test-amd64-i386-pair          5 xen-install/src_host      fail REGR. vs. 10201
 test-amd64-amd64-xl-sedf      7 debian-install            fail REGR. vs. 10201
 test-amd64-i386-rhel6hvm-intel  4 xen-install             fail REGR. vs. 10201
 build-i386                    2 host-install(2)              broken
 test-amd64-i386-rhel6hvm-amd  4 xen-install               fail REGR. vs. 10201
 test-amd64-i386-xl-credit2    4 xen-install               fail REGR. vs. 10201
 test-amd64-i386-win-vcpus1    4 xen-install               fail REGR. vs. 10201
 test-amd64-i386-win           4 xen-install               fail REGR. vs. 10201
 test-amd64-i386-xl-win-vcpus1  4 xen-install              fail REGR. vs. 10201

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-win7-amd64  7 windows-install              fail never pass
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   never pass
 test-i386-i386-xl-winxpsp3    1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pv             1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl             1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pair           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-win            1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-win         1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-win         16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  3b409f65abae
baseline version:
 xen                  62ff6a318c5d

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Anthony PERARD <anthony.perard@citrix.com>
  Brendan Cully <brendan@cs.ubc.ca>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jonathan Davies <jonathan.davies@citrix.com>
  Keir Fraser <keir@xen.org>
  Liu, Jinsong <jinsong.liu@intel.com>
  Shriram Rajagopalan <rshriram@cs.ubc.ca>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
------------------------------------------------------------

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


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

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

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


Not pushing.

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

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 19:57:37 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 19:57:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWCkz-0007MU-9s; Thu, 01 Dec 2011 19:57:21 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RWCky-0007MO-BM
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 19:57:20 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1322769398!3897868!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU2Nw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16754 invoked from network); 1 Dec 2011 19:56:39 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 19:56:39 -0000
X-IronPort-AV: E=Sophos;i="4.71,280,1320624000"; 
   d="scan'208";a="9239124"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Dec 2011 19:56:38 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 1 Dec 2011 19:56:37 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RWCkH-0004m3-LG;
	Thu, 01 Dec 2011 19:56:37 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RWCkH-0007Of-Kj;
	Thu, 01 Dec 2011 19:56:37 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10211-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 1 Dec 2011 19:56:37 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10211: regressions - trouble:
	blocked/broken/fail/pass
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

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

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-i386-xend-winxpsp3  4 xen-install              fail REGR. vs. 10201
 test-amd64-i386-xl-win7-amd64  4 xen-install              fail REGR. vs. 10201
 test-amd64-i386-xl-winxpsp3-vcpus1  4 xen-install         fail REGR. vs. 10201
 test-amd64-i386-pv            4 xen-install               fail REGR. vs. 10201
 test-amd64-i386-xl-multivcpu  4 xen-install               fail REGR. vs. 10201
 test-amd64-i386-xl            4 xen-install               fail REGR. vs. 10201
 test-amd64-i386-pair          6 xen-install/dst_host      fail REGR. vs. 10201
 test-amd64-i386-pair          5 xen-install/src_host      fail REGR. vs. 10201
 test-amd64-amd64-xl-sedf      7 debian-install            fail REGR. vs. 10201
 test-amd64-i386-rhel6hvm-intel  4 xen-install             fail REGR. vs. 10201
 build-i386                    2 host-install(2)              broken
 test-amd64-i386-rhel6hvm-amd  4 xen-install               fail REGR. vs. 10201
 test-amd64-i386-xl-credit2    4 xen-install               fail REGR. vs. 10201
 test-amd64-i386-win-vcpus1    4 xen-install               fail REGR. vs. 10201
 test-amd64-i386-win           4 xen-install               fail REGR. vs. 10201
 test-amd64-i386-xl-win-vcpus1  4 xen-install              fail REGR. vs. 10201

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-win7-amd64  7 windows-install              fail never pass
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   never pass
 test-i386-i386-xl-winxpsp3    1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pv             1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl             1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pair           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-win            1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-win         1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-win         16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  3b409f65abae
baseline version:
 xen                  62ff6a318c5d

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Anthony PERARD <anthony.perard@citrix.com>
  Brendan Cully <brendan@cs.ubc.ca>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jonathan Davies <jonathan.davies@citrix.com>
  Keir Fraser <keir@xen.org>
  Liu, Jinsong <jinsong.liu@intel.com>
  Shriram Rajagopalan <rshriram@cs.ubc.ca>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
------------------------------------------------------------

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


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

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

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


Not pushing.

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

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 20:03:33 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 20:03:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWCqi-0007jJ-8s; Thu, 01 Dec 2011 20:03:16 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RWCqg-0007j4-UO
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 20:03:15 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-16.tower-21.messagelabs.com!1322769754!6382331!1
X-Originating-IP: [208.97.132.5]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi41ID0+IDE1MDY0\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31873 invoked from network); 1 Dec 2011 20:02:34 -0000
Received: from mailbigip.dreamhost.com (HELO homiemail-a21.g.dreamhost.com)
	(208.97.132.5) by server-16.tower-21.messagelabs.com with SMTP;
	1 Dec 2011 20:02:34 -0000
Received: from homiemail-a21.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTP id 223D3300074;
	Thu,  1 Dec 2011 12:02:33 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=aBd1VFFYXmT6u+kwqnmViBTlz8IwK0CtAvqWpEQv1F2N
	EC2CGoKuaPmrkLY6RnOXQwfCuSNiKk47qGC9flV3Q/ZWU0K23w/DoT0dApwo8Ooh
	tXrb3nVdiTVLH6/ui0JAe4r9hZTQhofAsHV1hYoem/n41GqlrbDDB7QWcxzKt+o=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=J66bIPF+zsdsT41WSR8jwVcVa1E=; b=dF7114ko
	KOCLB9RuSiCBa2trm8GcnwPR/Jw4M3ZGHjBfiuodHvV/Fy3YYpwYAtNsEwSHrEGP
	stvLwZpwm2Y3oc+nhkJ7a7NpjEUc23GSgkq5HMi5YDt0oedqCM1E1UDXVS6M6m0u
	bm5dZvGqf+LBnT1sDgAKY/5kA3/ht4Kntlg=
Received: from webmail.lagarcavilla.org (ahfbbjcaiaae.dreamhost.com
	[75.119.208.4]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTPA id 6663C300072; 
	Thu,  1 Dec 2011 12:02:32 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP; Thu, 1 Dec 2011 12:02:33 -0800
Message-ID: <4871e74106f2eea9b4a56c24e2167b99.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20111201184616.GA17010@aepfle.de>
References: <mailman.3014.1322742146.12970.xen-devel@lists.xensource.com>
	<782967b2dc26ac23e527e33839e8336f.squirrel@webmail.lagarcavilla.org>
	<20111201184616.GA17010@aepfle.de>
Date: Thu, 1 Dec 2011 12:02:33 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Olaf Hering" <olaf@aepfle.de>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>
Subject: Re: [Xen-devel] [PATCH 2 of 4] xenpaging: use wait queues
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> On Thu, Dec 01, Andres Lagar-Cavilla wrote:
>
>> > +    spin_lock_init(&d->arch.hvm_domain.gfn_lock);
>> Probably gfn_lock should be replaced with a name a bit more expressive.
>
> Ok, perhaps paged_gfn_queue_lock?
>
>> That notwithstanding, it seems this lock only gets used in the mm layer.
>> If so, it should be declared as an mm_lock_t in arch/x86/mm-locks.h, and
>> subject to ordering constraints.
>
> Is that really needed? The lock is not taken recursivly. What would be
> the benefit of the mm_lock_t in this context? Thats not clear to me.

You don't want locks intertwining and causing deadlocks, regardless of
recursive behavior. mm-locks.h has machinery to detect inversion in the
ordering. Even though your code doesn't do bad things, sanity checks
available should be used.

>
>> Both gfn_lock and the list of wait queues could be collapsed in a single
>> struct, so as to decrease pressure on the size of struct domain.
>
> The global lock allows to adjust the number of vcpus, but yes, maybe it
> can be moved into p2m_mem_paging_queue_head.
>
>
>> > +static struct p2m_mem_paging_queue *p2m_mem_paging_get_queue(struct
>> > domain *d, unsigned long gfn)
>> > +{
>> > +    struct p2m_mem_paging_queue_head *h;
>> > +    struct p2m_mem_paging_queue *q, *q_match, *q_free;
>> > +
>> > +    h = d->arch.hvm_domain.gfn_queue;
>> > +    q_match = q_free = NULL;
>> > +
>> > +    spin_lock(&d->arch.hvm_domain.gfn_lock);
>> > +
>> > +    list_for_each_entry(q, &h->list, list) {
>> "Hashing" the gfn ( i.e. gfn & ((1 << order_of_vcpus) - 1) ) and
>> starting
>> the linear scan from there would shortcut the common case of finding a
>> queued gfn.
>
> I will think about that, good point. Keeping the individual
> p2m_mem_paging_queue* in a flat list could be done.
>
>> Checking the p2m type of the gfn for paging in would make the search
>> O(1)
>> for the case in which the gfn is not queued.
>
> What type check do you mean? These functions are only called from
> within get_gfn_type_access() if p2m_is_paging.

I thought it was a more generic function that would either grab a waiter
or get the current one for that gfn. If it's only expected to grab a new
waiter, then you probably need a harsher check for a NULL return val
(crash domain?)

>
>> > +/* Returns 0 if the gfn is still paged */
>> > +static int p2m_mem_paging_get_entry(mfn_t *mfn,
>> > +               struct p2m_domain *p2m, unsigned long gfn,
>> > +               p2m_type_t *t, p2m_access_t *a, p2m_query_t q,
>> > +               unsigned int *page_order)
>> > +{
>> > +    *mfn = p2m->get_entry(p2m, gfn, t, a, q, page_order);
>> This will be called in the wake up routine, and it will be racy against
>> any concurrent p2m updates.
>
> How is this different from the current code in get_gfn_type_access()?
> Is get_gfn_type_access() protected by any lock? I thought that only
> p2m_query is allowed to take the p2m_lock?

It is not different from the current code. Which is broken and racy. So
let's not break things further :)
Wrapping it around get_gfn_type_access would make it synchronized when
locking p2m lookups finally get into the tree.

>
>> > -        /* Evict will fail now, tag this request for pager */
>> > -        if ( p2mt == p2m_ram_paging_out )
>> > -            req.flags |= MEM_EVENT_FLAG_EVICT_FAIL;
>> > +    /* Forward the state only if gfn is in page-out path */
>> > +    if ( p2mt == p2m_ram_paging_out || p2mt == p2m_ram_paged ) {
>> > +        /* Ignore foreign requests to allow mmap in pager */
>> > +        if ( mfn_valid(mfn) && p2mt == p2m_ram_paging_out &&
>> v->domain ==
>> > d ) {
>> > +            /* Restore gfn because it is needed by guest before evict
>> */
>> > +            set_p2m_entry(p2m, gfn, mfn, PAGE_ORDER_4K,
>> > +                       paging_mode_log_dirty(d) ? p2m_ram_logdirty :
>> > p2m_ram_rw, a);
>> No event here to tell the pager to cancel its work?
>
> The pager is in the process of writing the gfn to disk after successful
> nomination. Its next step is the eviction, which will now fail because
> the p2mt is not p2m_ram_paging_out anymore. It is already prepared for
> that failure.
*xenpaging* is already prepared for that failure. Now you're changing the
interface. That was my point in the previous email.

Thanks
Andres
> The previous MEM_EVENT_FLAG_EVICT_FAIL was not needed in the first
> place.
>
>> You're not just adding wait queues, but also short-cutting the state
>> machine of paging, which, whilst delicate, works quite well right now.
>> You
>> should definitely split that into two patches if possible.
>
> I think that can be done, yes.
>
>> And please keep in mind that there are pagers other than xenpaging, so
>> interface churn is a big headache for everyone, if unavoidable.
>
> There will be few changes in the interface in the near future to make it
> more robust.
>
>
>> >          mem_event_put_req_producers(d, &d->mem_event->paging);
>> These (mem_event_put_req_producers, foreign_producers) are the kinds of
>> things that are really confusing in the ring management side right now.
>
> You are right, the names should be changed in the patched for mem_event.
>
> Olaf
>



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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 20:03:33 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 20:03:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWCqi-0007jJ-8s; Thu, 01 Dec 2011 20:03:16 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RWCqg-0007j4-UO
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 20:03:15 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-16.tower-21.messagelabs.com!1322769754!6382331!1
X-Originating-IP: [208.97.132.5]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi41ID0+IDE1MDY0\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31873 invoked from network); 1 Dec 2011 20:02:34 -0000
Received: from mailbigip.dreamhost.com (HELO homiemail-a21.g.dreamhost.com)
	(208.97.132.5) by server-16.tower-21.messagelabs.com with SMTP;
	1 Dec 2011 20:02:34 -0000
Received: from homiemail-a21.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTP id 223D3300074;
	Thu,  1 Dec 2011 12:02:33 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=aBd1VFFYXmT6u+kwqnmViBTlz8IwK0CtAvqWpEQv1F2N
	EC2CGoKuaPmrkLY6RnOXQwfCuSNiKk47qGC9flV3Q/ZWU0K23w/DoT0dApwo8Ooh
	tXrb3nVdiTVLH6/ui0JAe4r9hZTQhofAsHV1hYoem/n41GqlrbDDB7QWcxzKt+o=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=J66bIPF+zsdsT41WSR8jwVcVa1E=; b=dF7114ko
	KOCLB9RuSiCBa2trm8GcnwPR/Jw4M3ZGHjBfiuodHvV/Fy3YYpwYAtNsEwSHrEGP
	stvLwZpwm2Y3oc+nhkJ7a7NpjEUc23GSgkq5HMi5YDt0oedqCM1E1UDXVS6M6m0u
	bm5dZvGqf+LBnT1sDgAKY/5kA3/ht4Kntlg=
Received: from webmail.lagarcavilla.org (ahfbbjcaiaae.dreamhost.com
	[75.119.208.4]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTPA id 6663C300072; 
	Thu,  1 Dec 2011 12:02:32 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP; Thu, 1 Dec 2011 12:02:33 -0800
Message-ID: <4871e74106f2eea9b4a56c24e2167b99.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20111201184616.GA17010@aepfle.de>
References: <mailman.3014.1322742146.12970.xen-devel@lists.xensource.com>
	<782967b2dc26ac23e527e33839e8336f.squirrel@webmail.lagarcavilla.org>
	<20111201184616.GA17010@aepfle.de>
Date: Thu, 1 Dec 2011 12:02:33 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Olaf Hering" <olaf@aepfle.de>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>
Subject: Re: [Xen-devel] [PATCH 2 of 4] xenpaging: use wait queues
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> On Thu, Dec 01, Andres Lagar-Cavilla wrote:
>
>> > +    spin_lock_init(&d->arch.hvm_domain.gfn_lock);
>> Probably gfn_lock should be replaced with a name a bit more expressive.
>
> Ok, perhaps paged_gfn_queue_lock?
>
>> That notwithstanding, it seems this lock only gets used in the mm layer.
>> If so, it should be declared as an mm_lock_t in arch/x86/mm-locks.h, and
>> subject to ordering constraints.
>
> Is that really needed? The lock is not taken recursivly. What would be
> the benefit of the mm_lock_t in this context? Thats not clear to me.

You don't want locks intertwining and causing deadlocks, regardless of
recursive behavior. mm-locks.h has machinery to detect inversion in the
ordering. Even though your code doesn't do bad things, sanity checks
available should be used.

>
>> Both gfn_lock and the list of wait queues could be collapsed in a single
>> struct, so as to decrease pressure on the size of struct domain.
>
> The global lock allows to adjust the number of vcpus, but yes, maybe it
> can be moved into p2m_mem_paging_queue_head.
>
>
>> > +static struct p2m_mem_paging_queue *p2m_mem_paging_get_queue(struct
>> > domain *d, unsigned long gfn)
>> > +{
>> > +    struct p2m_mem_paging_queue_head *h;
>> > +    struct p2m_mem_paging_queue *q, *q_match, *q_free;
>> > +
>> > +    h = d->arch.hvm_domain.gfn_queue;
>> > +    q_match = q_free = NULL;
>> > +
>> > +    spin_lock(&d->arch.hvm_domain.gfn_lock);
>> > +
>> > +    list_for_each_entry(q, &h->list, list) {
>> "Hashing" the gfn ( i.e. gfn & ((1 << order_of_vcpus) - 1) ) and
>> starting
>> the linear scan from there would shortcut the common case of finding a
>> queued gfn.
>
> I will think about that, good point. Keeping the individual
> p2m_mem_paging_queue* in a flat list could be done.
>
>> Checking the p2m type of the gfn for paging in would make the search
>> O(1)
>> for the case in which the gfn is not queued.
>
> What type check do you mean? These functions are only called from
> within get_gfn_type_access() if p2m_is_paging.

I thought it was a more generic function that would either grab a waiter
or get the current one for that gfn. If it's only expected to grab a new
waiter, then you probably need a harsher check for a NULL return val
(crash domain?)

>
>> > +/* Returns 0 if the gfn is still paged */
>> > +static int p2m_mem_paging_get_entry(mfn_t *mfn,
>> > +               struct p2m_domain *p2m, unsigned long gfn,
>> > +               p2m_type_t *t, p2m_access_t *a, p2m_query_t q,
>> > +               unsigned int *page_order)
>> > +{
>> > +    *mfn = p2m->get_entry(p2m, gfn, t, a, q, page_order);
>> This will be called in the wake up routine, and it will be racy against
>> any concurrent p2m updates.
>
> How is this different from the current code in get_gfn_type_access()?
> Is get_gfn_type_access() protected by any lock? I thought that only
> p2m_query is allowed to take the p2m_lock?

It is not different from the current code. Which is broken and racy. So
let's not break things further :)
Wrapping it around get_gfn_type_access would make it synchronized when
locking p2m lookups finally get into the tree.

>
>> > -        /* Evict will fail now, tag this request for pager */
>> > -        if ( p2mt == p2m_ram_paging_out )
>> > -            req.flags |= MEM_EVENT_FLAG_EVICT_FAIL;
>> > +    /* Forward the state only if gfn is in page-out path */
>> > +    if ( p2mt == p2m_ram_paging_out || p2mt == p2m_ram_paged ) {
>> > +        /* Ignore foreign requests to allow mmap in pager */
>> > +        if ( mfn_valid(mfn) && p2mt == p2m_ram_paging_out &&
>> v->domain ==
>> > d ) {
>> > +            /* Restore gfn because it is needed by guest before evict
>> */
>> > +            set_p2m_entry(p2m, gfn, mfn, PAGE_ORDER_4K,
>> > +                       paging_mode_log_dirty(d) ? p2m_ram_logdirty :
>> > p2m_ram_rw, a);
>> No event here to tell the pager to cancel its work?
>
> The pager is in the process of writing the gfn to disk after successful
> nomination. Its next step is the eviction, which will now fail because
> the p2mt is not p2m_ram_paging_out anymore. It is already prepared for
> that failure.
*xenpaging* is already prepared for that failure. Now you're changing the
interface. That was my point in the previous email.

Thanks
Andres
> The previous MEM_EVENT_FLAG_EVICT_FAIL was not needed in the first
> place.
>
>> You're not just adding wait queues, but also short-cutting the state
>> machine of paging, which, whilst delicate, works quite well right now.
>> You
>> should definitely split that into two patches if possible.
>
> I think that can be done, yes.
>
>> And please keep in mind that there are pagers other than xenpaging, so
>> interface churn is a big headache for everyone, if unavoidable.
>
> There will be few changes in the interface in the near future to make it
> more robust.
>
>
>> >          mem_event_put_req_producers(d, &d->mem_event->paging);
>> These (mem_event_put_req_producers, foreign_producers) are the kinds of
>> things that are really confusing in the ring management side right now.
>
> You are right, the names should be changed in the patched for mem_event.
>
> Olaf
>



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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 20:53:16 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 20:53:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWDcj-0008A7-2m; Thu, 01 Dec 2011 20:52:53 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RWDch-00089P-BM
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 20:52:51 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-10.tower-174.messagelabs.com!1322772730!3915315!1
X-Originating-IP: [208.97.132.5]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi41ID0+IDE1MDY0\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21789 invoked from network); 1 Dec 2011 20:52:10 -0000
Received: from mailbigip.dreamhost.com (HELO homiemail-a13.g.dreamhost.com)
	(208.97.132.5) by server-10.tower-174.messagelabs.com with SMTP;
	1 Dec 2011 20:52:10 -0000
Received: from homiemail-a13.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a13.g.dreamhost.com (Postfix) with ESMTP id 7B86933406B;
	Thu,  1 Dec 2011 12:52:09 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=JYxOpmf/4P22CUDakwGgt3S6yNKww3vb9f27cDUm71xN
	oBpZr5XuNQRUL3pi0TILgQoQKwngJTwJoEp72oftAkqiZw1NPDjGC4yXlQxscpHs
	yrcfQzFL8XZfuV7K3WMlDMLV5sfsX+MnIpBQSPQVPE98P/op45Jf/VZPwLRY6EE=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=6K4OxD0uuLIPi/D/IeWpgDTOZCo=; b=pGeV08HeZ2J
	PjjNuqbnIgqO8dK3oKrE6kqKhQmjL3I1YKBJHVXb4vRZ7LDBUH2ghDpPB+df/8Te
	K84nD1DoanuU45VUKqArnT85EpkDs0xcQ7sqLBqHiWPQMhlz0Muq+Vj4HeOMwmD1
	ZlpqmkygjyqniVGolKo3zEHc0awAAS20=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a13.g.dreamhost.com (Postfix) with ESMTPSA id B4B8A33406E; 
	Thu,  1 Dec 2011 12:52:08 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: df9e25a0189b1a5a94b1b7eb815bfb57cd9f7128
Message-Id: <df9e25a0189b1a5a94b1.1322772714@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1322772713@xdev.gridcentric.ca>
References: <patchbomb.1322772713@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Thu, 01 Dec 2011 15:51:54 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: mike.mcclurg@citrix.com, andres@gridcentric.ca, olaf@aepfle.de,
	jonathan.ludlam@eu.citrix.com, JBeulich@suse.com
Subject: [Xen-devel] [PATCH 1 of 2] xen/x86: make
 __direct_remap_pfn_range()'s return value meaningful
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 arch/x86/mm/ioremap-xen.c |  12 ++++--------
 1 files changed, 4 insertions(+), 8 deletions(-)


This change fixes the xc_map_foreign_bulk interface, which would
otherwise cause SIGBUS when pages are gone because -ENOENT is not
returned as expected by the IOCTL_PRIVCMD_MMAPBATCH_V2 ioctl.

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

diff -r 164cbc688ec7 -r df9e25a0189b arch/x86/mm/ioremap-xen.c
--- a/arch/x86/mm/ioremap-xen.c
+++ b/arch/x86/mm/ioremap-xen.c
@@ -48,7 +48,7 @@ static int __direct_remap_pfn_range(stru
 				    pgprot_t prot,
 				    domid_t  domid)
 {
-	int rc;
+	int rc = 0;
 	unsigned long i, start_address;
 	mmu_update_t *u, *v, *w;
 
@@ -68,8 +68,8 @@ static int __direct_remap_pfn_range(stru
 						 direct_remap_area_pte_fn, &w);
 			if (rc)
 				goto out;
-			rc = -EFAULT;
-			if (HYPERVISOR_mmu_update(u, v - u, NULL, domid) < 0)
+			rc = HYPERVISOR_mmu_update(u, v - u, NULL, domid);
+			if (rc  < 0)
 				goto out;
 			v = w = u;
 			start_address = address;
@@ -94,13 +94,9 @@ static int __direct_remap_pfn_range(stru
 					 direct_remap_area_pte_fn, &w);
 		if (rc)
 			goto out;
-		rc = -EFAULT;
-		if (unlikely(HYPERVISOR_mmu_update(u, v - u, NULL, domid) < 0))
-			goto out;
+		rc = HYPERVISOR_mmu_update(u, v - u, NULL, domid);
 	}
 
-	rc = 0;
-
  out:
 	flush_tlb_all();
 

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 20:53:16 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 20:53:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWDcj-0008A7-2m; Thu, 01 Dec 2011 20:52:53 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RWDch-00089P-BM
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 20:52:51 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-10.tower-174.messagelabs.com!1322772730!3915315!1
X-Originating-IP: [208.97.132.5]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi41ID0+IDE1MDY0\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21789 invoked from network); 1 Dec 2011 20:52:10 -0000
Received: from mailbigip.dreamhost.com (HELO homiemail-a13.g.dreamhost.com)
	(208.97.132.5) by server-10.tower-174.messagelabs.com with SMTP;
	1 Dec 2011 20:52:10 -0000
Received: from homiemail-a13.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a13.g.dreamhost.com (Postfix) with ESMTP id 7B86933406B;
	Thu,  1 Dec 2011 12:52:09 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=JYxOpmf/4P22CUDakwGgt3S6yNKww3vb9f27cDUm71xN
	oBpZr5XuNQRUL3pi0TILgQoQKwngJTwJoEp72oftAkqiZw1NPDjGC4yXlQxscpHs
	yrcfQzFL8XZfuV7K3WMlDMLV5sfsX+MnIpBQSPQVPE98P/op45Jf/VZPwLRY6EE=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=6K4OxD0uuLIPi/D/IeWpgDTOZCo=; b=pGeV08HeZ2J
	PjjNuqbnIgqO8dK3oKrE6kqKhQmjL3I1YKBJHVXb4vRZ7LDBUH2ghDpPB+df/8Te
	K84nD1DoanuU45VUKqArnT85EpkDs0xcQ7sqLBqHiWPQMhlz0Muq+Vj4HeOMwmD1
	ZlpqmkygjyqniVGolKo3zEHc0awAAS20=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a13.g.dreamhost.com (Postfix) with ESMTPSA id B4B8A33406E; 
	Thu,  1 Dec 2011 12:52:08 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: df9e25a0189b1a5a94b1b7eb815bfb57cd9f7128
Message-Id: <df9e25a0189b1a5a94b1.1322772714@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1322772713@xdev.gridcentric.ca>
References: <patchbomb.1322772713@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Thu, 01 Dec 2011 15:51:54 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: mike.mcclurg@citrix.com, andres@gridcentric.ca, olaf@aepfle.de,
	jonathan.ludlam@eu.citrix.com, JBeulich@suse.com
Subject: [Xen-devel] [PATCH 1 of 2] xen/x86: make
 __direct_remap_pfn_range()'s return value meaningful
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 arch/x86/mm/ioremap-xen.c |  12 ++++--------
 1 files changed, 4 insertions(+), 8 deletions(-)


This change fixes the xc_map_foreign_bulk interface, which would
otherwise cause SIGBUS when pages are gone because -ENOENT is not
returned as expected by the IOCTL_PRIVCMD_MMAPBATCH_V2 ioctl.

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

diff -r 164cbc688ec7 -r df9e25a0189b arch/x86/mm/ioremap-xen.c
--- a/arch/x86/mm/ioremap-xen.c
+++ b/arch/x86/mm/ioremap-xen.c
@@ -48,7 +48,7 @@ static int __direct_remap_pfn_range(stru
 				    pgprot_t prot,
 				    domid_t  domid)
 {
-	int rc;
+	int rc = 0;
 	unsigned long i, start_address;
 	mmu_update_t *u, *v, *w;
 
@@ -68,8 +68,8 @@ static int __direct_remap_pfn_range(stru
 						 direct_remap_area_pte_fn, &w);
 			if (rc)
 				goto out;
-			rc = -EFAULT;
-			if (HYPERVISOR_mmu_update(u, v - u, NULL, domid) < 0)
+			rc = HYPERVISOR_mmu_update(u, v - u, NULL, domid);
+			if (rc  < 0)
 				goto out;
 			v = w = u;
 			start_address = address;
@@ -94,13 +94,9 @@ static int __direct_remap_pfn_range(stru
 					 direct_remap_area_pte_fn, &w);
 		if (rc)
 			goto out;
-		rc = -EFAULT;
-		if (unlikely(HYPERVISOR_mmu_update(u, v - u, NULL, domid) < 0))
-			goto out;
+		rc = HYPERVISOR_mmu_update(u, v - u, NULL, domid);
 	}
 
-	rc = 0;
-
  out:
 	flush_tlb_all();
 

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 20:53:17 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 20:53:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWDcf-00089V-4b; Thu, 01 Dec 2011 20:52:49 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RWDcd-00089Q-Ju
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 20:52:48 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-8.tower-27.messagelabs.com!1322772624!54531986!1
X-Originating-IP: [208.97.132.177]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNzcgPT4gMTU3NzI=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9069 invoked from network); 1 Dec 2011 20:50:25 -0000
Received: from caiajhbdcbhh.dreamhost.com (HELO homiemail-a13.g.dreamhost.com)
	(208.97.132.177) by server-8.tower-27.messagelabs.com with SMTP;
	1 Dec 2011 20:50:25 -0000
Received: from homiemail-a13.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a13.g.dreamhost.com (Postfix) with ESMTP id AA09133406C;
	Thu,  1 Dec 2011 12:52:10 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=Z/VdK6/CqutZrhie3C3ZJrfF+qbbNgoN65lVpmb+/JEB
	R1xM3WYj6B/qxm36AKn/omRXKOytK4QdaGr9lq5eMouQWEKsF/P3UXP23zT329wq
	ayYfczJti/SbbbcCmTiTdIpUv5D8Wn5yeJ10FewAvEHRTrn9L5ZrFz7TOAyxli4=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=EUQcF0sgjHFmQw/qMOVbnoctCJU=; b=NKncQEKwxAd
	CEywBW8/WbwBCKdrIVIkL9Gdn7rOtkJuWRPINABtg2vhJp4yNtirLlGiU2EofU33
	H/yXppDWAB3QWT/0xqwBTnH6z/JUmwVmwNYCtYhT4CrB6QGq7XI3WXgbIOAoFh2a
	z3riPs9a9BlSbypOrmibEq28cwNYpflA=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a13.g.dreamhost.com (Postfix) with ESMTPSA id B5B54334063; 
	Thu,  1 Dec 2011 12:52:09 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 1170bc32db41a7ae1e95c82aeec4c993e5a7e8a6
Message-Id: <1170bc32db41a7ae1e95.1322772715@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1322772713@xdev.gridcentric.ca>
References: <patchbomb.1322772713@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Thu, 01 Dec 2011 15:51:55 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: mike.mcclurg@citrix.com, andres@gridcentric.ca, olaf@aepfle.de,
	jonathan.ludlam@eu.citrix.com, JBeulich@suse.com
Subject: [Xen-devel] [PATCH 2 of 2] xenpaging: handle GNTST_eagain in kernel
	drivers
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 drivers/xen/blkback/blkback.c              |   6 ++-
 drivers/xen/blkback/interface.c            |   9 +++-
 drivers/xen/core/gnttab.c                  |   4 +-
 drivers/xen/gntdev/gntdev.c                |  49 +++++++++++++++++------------
 drivers/xen/netback/interface.c            |   5 +-
 drivers/xen/netback/netback.c              |  16 ++++++---
 drivers/xen/scsiback/interface.c           |  10 +++---
 drivers/xen/scsiback/scsiback.c            |   4 +-
 drivers/xen/tpmback/interface.c            |   7 +--
 drivers/xen/tpmback/tpmback.c              |  20 ++++-------
 drivers/xen/usbback/interface.c            |  16 ++++----
 drivers/xen/usbback/usbback.c              |   4 +-
 drivers/xen/xenbus/xenbus_backend_client.c |  10 +++---
 include/xen/gnttab.h                       |  37 ++++++++++++++++++++++
 14 files changed, 126 insertions(+), 71 deletions(-)


Handle GNTST_eagain status from GNTTABOP_map_grant_ref and
GNTTABOP_copy operations properly to allow usage of xenpaging without
causing crashes or data corruption.

Replace all relevant HYPERVISOR_grant_table_op() calls with a retry
loop. This loop is implemented as a macro to allow different
GNTTABOP_* args. It will sleep up to 33 seconds and wait for the
page to be paged in again.

All ->status checks were updated to use the GNTST_* namespace. All
return values are converted from GNTST_* namespace to 0/-EINVAL, since
all callers did not use the actual return value.

Signed-off-by: Olaf Hering <olaf@aepfle.de>
Acked-by: Patrick Colp <pjcolp@cs.ubc.ca>

This is a port from xenlinux 2.6.18 to the 2.6.32 xcp tree
Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r df9e25a0189b -r 1170bc32db41 drivers/xen/blkback/blkback.c
--- a/drivers/xen/blkback/blkback.c
+++ b/drivers/xen/blkback/blkback.c
@@ -701,11 +701,13 @@ static void dispatch_rw_block_io(blkif_t
 	BUG_ON(ret);
 
 	for (i = 0; i < nseg; i++) {
-		if (unlikely(map[i].status != 0)) {
+		if (unlikely(map[i].status == GNTST_eagain))
+			gnttab_check_GNTST_eagain_do_while(GNTTABOP_map_grant_ref, &map[i]);
+		if (unlikely(map[i].status != GNTST_okay)) {
 			DPRINTK("grant map of dom %u gref %u failed: status %d\n",
 				blkif->domid, req->seg[i].gref, map[i].status);
 			map[i].handle = BLKBACK_INVALID_HANDLE;
-			ret |= 1;
+			ret = 1;
 			continue;
 		}
 
diff -r df9e25a0189b -r 1170bc32db41 drivers/xen/blkback/interface.c
--- a/drivers/xen/blkback/interface.c
+++ b/drivers/xen/blkback/interface.c
@@ -95,7 +95,7 @@ static int map_frontend_pages(blkif_t *b
 	struct vm_struct *area = blkif->blk_ring_area;
 	struct gnttab_map_grant_ref op[BLKIF_MAX_RING_PAGES];
 	unsigned int i;
-	int status = 0;
+	int status = GNTST_okay;
 
 	for (i = 0; i < nr_shared_pages; i++) {
 		unsigned long addr = (unsigned long)area->addr +
@@ -110,7 +110,10 @@ static int map_frontend_pages(blkif_t *b
 		BUG();
 
 	for (i = 0; i < nr_shared_pages; i++) {
-		if ((status = op[i].status) != 0) {
+		if (op[i].status == GNTST_eagain)
+			gnttab_check_GNTST_eagain_do_while(GNTTABOP_map_grant_ref, &op[i]);
+		if (op[i].status != GNTST_okay) {
+			status = op[i].status;
 			blkif->shmem_handle[i] = INVALID_GRANT_HANDLE;
 			continue;
 		}
@@ -120,7 +123,7 @@ static int map_frontend_pages(blkif_t *b
 
 	blkif->nr_shared_pages = nr_shared_pages;
 
-	if (status != 0) {
+	if (status != GNTST_okay) {
 		DPRINTK(" Grant table operation failure !\n");
 		unmap_frontend_pages(blkif);
 	}
diff -r df9e25a0189b -r 1170bc32db41 drivers/xen/core/gnttab.c
--- a/drivers/xen/core/gnttab.c
+++ b/drivers/xen/core/gnttab.c
@@ -773,7 +773,7 @@ static int gnttab_map(unsigned int start
 		return -ENOSYS;
 	}
 
-	BUG_ON(rc || setup.status);
+	BUG_ON(rc || (setup.status != GNTST_okay));
 
 	if (shared.raw == NULL)
 		shared.raw = arch_gnttab_alloc_shared(gframes);
@@ -901,7 +901,7 @@ int gnttab_copy_grant_page(grant_ref_t r
 	err = HYPERVISOR_grant_table_op(GNTTABOP_unmap_and_replace,
 					&unmap, 1);
 	BUG_ON(err);
-	BUG_ON(unmap.status);
+	BUG_ON(unmap.status != GNTST_okay);
 
 	write_sequnlock_irq(&gnttab_dma_lock);
 
diff -r df9e25a0189b -r 1170bc32db41 drivers/xen/gntdev/gntdev.c
--- a/drivers/xen/gntdev/gntdev.c
+++ b/drivers/xen/gntdev/gntdev.c
@@ -503,7 +503,7 @@ static int gntdev_mmap (struct file *fli
 	uint64_t ptep;
 	int ret;
 	int flags;
-	int i;
+	int i, exit_ret;
 	struct page *page;
 	gntdev_file_private_data_t *private_data = flip->private_data;
 
@@ -578,6 +578,7 @@ static int gntdev_mmap (struct file *fli
 	vma->vm_mm->context.has_foreign_mappings = 1;
 #endif
 
+	exit_ret = -ENOMEM;
 	for (i = 0; i < size; ++i) {
 
 		flags = GNTMAP_host_map;
@@ -598,14 +599,18 @@ static int gntdev_mmap (struct file *fli
 		ret = HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, 
 						&op, 1);
 		BUG_ON(ret);
-		if (op.status) {
-			printk(KERN_ERR "Error mapping the grant reference "
-			       "into the kernel (%d). domid = %d; ref = %d\n",
-			       op.status,
-			       private_data->grants[slot_index+i]
-			       .u.valid.domid,
-			       private_data->grants[slot_index+i]
-			       .u.valid.ref);
+		if (op.status != GNTST_okay) {
+			if (op.status != GNTST_eagain)
+				printk(KERN_ERR "Error mapping the grant reference "
+					   "into the kernel (%d). domid = %d; ref = %d\n",
+					   op.status,
+					   private_data->grants[slot_index+i]
+					   .u.valid.domid,
+					   private_data->grants[slot_index+i]
+					   .u.valid.ref);
+			else
+				/* Propagate instead of trying to fix it up */
+				exit_ret = -EAGAIN;
 			goto undo_map_out;
 		}
 
@@ -674,14 +679,17 @@ static int gntdev_mmap (struct file *fli
 			ret = HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref,
 							&op, 1);
 			BUG_ON(ret);
-			if (op.status) {
+			if (op.status != GNTST_okay) {
 				printk(KERN_ERR "Error mapping the grant "
-				       "reference into user space (%d). domid "
-				       "= %d; ref = %d\n", op.status,
-				       private_data->grants[slot_index+i].u
-				       .valid.domid,
-				       private_data->grants[slot_index+i].u
-				       .valid.ref);
+					   "reference into user space (%d). domid "
+					   "= %d; ref = %d\n", op.status,
+					   private_data->grants[slot_index+i].u
+					   .valid.domid,
+					   private_data->grants[slot_index+i].u
+					   .valid.ref);
+				/* GNTST_eagain (i.e. page paged out) sohuld never happen
+				 * once we've mapped into kernel space */
+				BUG_ON(op.status == GNTST_eagain);
 				goto undo_map_out;
 			}
 			
@@ -705,9 +713,10 @@ static int gntdev_mmap (struct file *fli
 		}
 
 	}
+	exit_ret = 0;
 
 	up_write(&private_data->grants_sem);
-	return 0;
+	return exit_ret;
 
 undo_map_out:
 	/* If we have a mapping failure, the unmapping will be taken care of
@@ -725,7 +734,7 @@ undo_map_out:
 	
 	up_write(&private_data->grants_sem);
 
-	return -ENOMEM;
+	return exit_ret;
 }
 
 static pte_t gntdev_clear_pte(struct vm_area_struct *vma, unsigned long addr,
@@ -777,7 +786,7 @@ static pte_t gntdev_clear_pte(struct vm_
 			ret = HYPERVISOR_grant_table_op(
 				GNTTABOP_unmap_grant_ref, &op, 1);
 			BUG_ON(ret);
-			if (op.status)
+			if (op.status != GNTST_okay)
 				printk("User unmap grant status = %d\n", 
 				       op.status);
 		} else {
@@ -794,7 +803,7 @@ static pte_t gntdev_clear_pte(struct vm_
 		ret = HYPERVISOR_grant_table_op(GNTTABOP_unmap_grant_ref, 
 						&op, 1);
 		BUG_ON(ret);
-		if (op.status)
+		if (op.status != GNTST_okay)
 			printk("Kernel unmap grant status = %d\n", op.status);
 
 
diff -r df9e25a0189b -r 1170bc32db41 drivers/xen/netback/interface.c
--- a/drivers/xen/netback/interface.c
+++ b/drivers/xen/netback/interface.c
@@ -381,10 +381,9 @@ static int map_frontend_pages(struct xen
 	gnttab_set_map_op(&op, (unsigned long)comms->ring_area->addr,
 			  GNTMAP_host_map, ring_ref, domid);
     
-	if (HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, &op, 1))
-		BUG();
+	gnttab_check_GNTST_eagain_do_while(GNTTABOP_map_grant_ref, &op);
 
-	if (op.status) {
+	if (op.status != GNTST_okay) {
 		DPRINTK(" Gnttab failure mapping ring_ref!\n");
 		free_vm_area(comms->ring_area);
 		return op.status;
diff -r df9e25a0189b -r 1170bc32db41 drivers/xen/netback/netback.c
--- a/drivers/xen/netback/netback.c
+++ b/drivers/xen/netback/netback.c
@@ -419,11 +419,13 @@ static int netbk_check_gop(int nr_copy_s
 
 	for (i = 0; i < nr_copy_slots; i++) {
 		copy_op = npo->copy + npo->copy_cons++;
+		if (copy_op->status == GNTST_eagain)
+			gnttab_check_GNTST_eagain_while(GNTTABOP_copy, copy_op);
 		if (copy_op->status != GNTST_okay) {
-				DPRINTK("Bad status %d from copy to DOM%d.\n",
-					copy_op->status, domid);
-				status = NETIF_RSP_ERROR;
-			}
+			DPRINTK("Bad status %d from copy to DOM%d.\n",
+				copy_op->status, domid);
+			status = NETIF_RSP_ERROR;
+		}
 	}
 
 	return status;
@@ -1020,7 +1022,11 @@ static int netbk_tx_check_mop(struct xen
 
 	/* Check status of header. */
 	err = mop->status;
-	if (unlikely(err)) {
+	if (err == GNTST_eagain) {
+		gnttab_check_GNTST_eagain_do_while(GNTTABOP_map_grant_ref, mop);
+		err = mop->status;
+	}
+	if (unlikely(err != GNTST_okay)) {
 		pending_ring_idx_t index;
 		index = pending_index(netbk->pending_prod++);
 		txp = &pending_tx_info[pending_idx].req;
diff -r df9e25a0189b -r 1170bc32db41 drivers/xen/scsiback/interface.c
--- a/drivers/xen/scsiback/interface.c
+++ b/drivers/xen/scsiback/interface.c
@@ -69,18 +69,18 @@ static int map_frontend_page( struct vsc
 				GNTMAP_host_map, ring_ref,
 				info->domid);
 
-	err = HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, &op, 1);
-	BUG_ON(err);
+	gnttab_check_GNTST_eagain_do_while(GNTTABOP_map_grant_ref, &op);
 
-	if (op.status) {
-		printk(KERN_ERR "scsiback: Grant table operation failure !\n");
+	if (op.status != GNTST_okay) {
+		printk(KERN_ERR "scsiback: Grant table operation failure %d!\n", 
+							(int) op.status);
 		return op.status;
 	}
 
 	info->shmem_ref    = ring_ref;
 	info->shmem_handle = op.handle;
 
-	return (GNTST_okay);
+	return 0;
 }
 
 static void unmap_frontend_page(struct vscsibk_info *info)
diff -r df9e25a0189b -r 1170bc32db41 drivers/xen/scsiback/scsiback.c
--- a/drivers/xen/scsiback/scsiback.c
+++ b/drivers/xen/scsiback/scsiback.c
@@ -287,7 +287,9 @@ static int scsiback_gnttab_data_map(vscs
 		for_each_sg (pending_req->sgl, sg, nr_segments, i) {
 			struct page *pg;
 
-			if (unlikely(map[i].status != 0)) {
+			if (unlikely(map[i].status == GNTST_eagain))
+				gnttab_check_GNTST_eagain_while(GNTTABOP_map_grant_ref, &map[i]);
+			if (unlikely(map[i].status != GNTST_okay)) {
 				printk(KERN_ERR "scsiback: invalid buffer -- could not remap it\n");
 				map[i].handle = SCSIBACK_INVALID_HANDLE;
 				err |= 1;
diff -r df9e25a0189b -r 1170bc32db41 drivers/xen/tpmback/interface.c
--- a/drivers/xen/tpmback/interface.c
+++ b/drivers/xen/tpmback/interface.c
@@ -86,11 +86,10 @@ static int map_frontend_page(tpmif_t *tp
 	gnttab_set_map_op(&op, (unsigned long)tpmif->tx_area->addr,
 			  GNTMAP_host_map, shared_page, tpmif->domid);
 
-	if (HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, &op, 1))
-		BUG();
+	gnttab_check_GNTST_eagain_do_while(GNTTABOP_map_grant_ref, &op);
 
-	if (op.status) {
-		DPRINTK(" Grant table operation failure !\n");
+	if (op.status != GNTST_okay) {
+		DPRINTK(" Grant table operation failure %d!\n", (int) op.status);
 		return op.status;
 	}
 
diff -r df9e25a0189b -r 1170bc32db41 drivers/xen/tpmback/tpmback.c
--- a/drivers/xen/tpmback/tpmback.c
+++ b/drivers/xen/tpmback/tpmback.c
@@ -256,15 +256,13 @@ int _packet_write(struct packet *pak,
 		gnttab_set_map_op(&map_op, idx_to_kaddr(tpmif, i),
 				  GNTMAP_host_map, tx->ref, tpmif->domid);
 
-		if (unlikely(HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref,
-						       &map_op, 1))) {
-			BUG();
-		}
+		gnttab_check_GNTST_eagain_do_while(GNTTABOP_map_grant_ref, &map_op);
 
 		handle = map_op.handle;
 
-		if (map_op.status) {
-			DPRINTK(" Grant table operation failure !\n");
+		if (map_op.status != GNTST_okay) {
+			DPRINTK(" Grant table operation failure %d!\n", 
+						(int) map_op.status);
 			return 0;
 		}
 
@@ -394,13 +392,11 @@ static int packet_read_shmem(struct pack
 		gnttab_set_map_op(&map_op, idx_to_kaddr(tpmif, i),
 				  GNTMAP_host_map, tx->ref, tpmif->domid);
 
-		if (unlikely(HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref,
-						       &map_op, 1))) {
-			BUG();
-		}
+		gnttab_check_GNTST_eagain_do_while(GNTTABOP_map_grant_ref, &map_op);
 
-		if (map_op.status) {
-			DPRINTK(" Grant table operation failure !\n");
+		if (map_op.status != GNTST_okay) {
+			DPRINTK(" Grant table operation failure %d!\n",
+						(int) map_op.status);
 			return -EFAULT;
 		}
 
diff -r df9e25a0189b -r 1170bc32db41 drivers/xen/usbback/interface.c
--- a/drivers/xen/usbback/interface.c
+++ b/drivers/xen/usbback/interface.c
@@ -109,11 +109,11 @@ static int map_frontend_pages(usbif_t *u
 	gnttab_set_map_op(&op, (unsigned long)usbif->urb_ring_area->addr,
 			  GNTMAP_host_map, urb_ring_ref, usbif->domid);
 
-	if (HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, &op, 1))
-		BUG();
+	gnttab_check_GNTST_eagain_do_while(GNTTABOP_map_grant_ref, &op);
 
-	if (op.status) {
-		printk(KERN_ERR "grant table failure mapping urb_ring_ref\n");
+	if (op.status != GNTST_okay) {
+		printk(KERN_ERR "grant table failure mapping urb_ring_ref %d\n",
+							(int) op.status);
 		return op.status;
 	}
 
@@ -123,17 +123,17 @@ static int map_frontend_pages(usbif_t *u
 	gnttab_set_map_op(&op, (unsigned long)usbif->conn_ring_area->addr,
 			  GNTMAP_host_map, conn_ring_ref, usbif->domid);
 
-	if (HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, &op, 1))
-		BUG();
+	gnttab_check_GNTST_eagain_do_while(GNTTABOP_map_grant_ref, &op);
 
-	if (op.status) {
+	if (op.status != GNTST_okay) {
 		struct gnttab_unmap_grant_ref unop;
 		gnttab_set_unmap_op(&unop,
 				(unsigned long) usbif->urb_ring_area->addr,
 				GNTMAP_host_map, usbif->urb_shmem_handle);
 		VOID(HYPERVISOR_grant_table_op(GNTTABOP_unmap_grant_ref, &unop,
 				1));
-		printk(KERN_ERR "grant table failure mapping conn_ring_ref\n");
+		printk(KERN_ERR "grant table failure mapping conn_ring_ref %d\n",
+							(int) op.status);
 		return op.status;
 	}
 
diff -r df9e25a0189b -r 1170bc32db41 drivers/xen/usbback/usbback.c
--- a/drivers/xen/usbback/usbback.c
+++ b/drivers/xen/usbback/usbback.c
@@ -428,7 +428,9 @@ static int usbbk_gnttab_map(usbif_t *usb
 		BUG_ON(ret);
 
 		for (i = 0; i < nr_segs; i++) {
-			if (unlikely(map[i].status != 0)) {
+			if (unlikely(map[i].status == GNTST_eagain))
+				gnttab_check_GNTST_eagain_while(GNTTABOP_map_grant_ref, &map[i]);
+			if (unlikely(map[i].status != GNTST_okay)) {
 				printk(KERN_ERR "usbback: invalid buffer -- could not remap it\n");
 				map[i].handle = USBBACK_INVALID_HANDLE;
 				ret |= 1;
diff -r df9e25a0189b -r 1170bc32db41 drivers/xen/xenbus/xenbus_backend_client.c
--- a/drivers/xen/xenbus/xenbus_backend_client.c
+++ b/drivers/xen/xenbus/xenbus_backend_client.c
@@ -48,8 +48,7 @@ struct vm_struct *xenbus_map_ring_valloc
 	gnttab_set_map_op(&op, (unsigned long)area->addr, GNTMAP_host_map,
 			  gnt_ref, dev->otherend_id);
 	
-	if (HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, &op, 1))
-		BUG();
+	gnttab_check_GNTST_eagain_do_while(GNTTABOP_map_grant_ref, &op);
 
 	if (op.status != GNTST_okay) {
 		free_vm_area(area);
@@ -75,15 +74,16 @@ int xenbus_map_ring(struct xenbus_device
 	
 	gnttab_set_map_op(&op, (unsigned long)vaddr, GNTMAP_host_map,
 			  gnt_ref, dev->otherend_id);
-	if (HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, &op, 1))
-		BUG();
+	gnttab_check_GNTST_eagain_do_while(GNTTABOP_map_grant_ref, &op);
 
 	if (op.status != GNTST_okay) {
 		xenbus_dev_fatal(dev, op.status,
 				 "mapping in shared page %d from domain %d",
 				 gnt_ref, dev->otherend_id);
-	} else
+	} else {
 		*handle = op.handle;
+		return 0;
+	}
 
 	return op.status;
 }
diff -r df9e25a0189b -r 1170bc32db41 include/xen/gnttab.h
--- a/include/xen/gnttab.h
+++ b/include/xen/gnttab.h
@@ -187,4 +187,41 @@ gnttab_set_replace_op(struct gnttab_unma
 	unmap->handle = handle;
 }
 
+#define gnttab_check_GNTST_eagain_while(__HCop, __HCarg_p)					\
+do {																		\
+	u8 __hc_delay = 1;														\
+	int __ret;																\
+	while (unlikely((__HCarg_p)->status == GNTST_eagain && __hc_delay)) {	\
+		msleep(__hc_delay++);												\
+		__ret = HYPERVISOR_grant_table_op(__HCop, (__HCarg_p), 1);			\
+		BUG_ON(__ret);														\
+	}																		\
+	if (__hc_delay == 0) {													\
+		printk(KERN_ERR "%s: %s gnt busy\n", __func__, current->comm);		\
+		(__HCarg_p)->status = GNTST_bad_page;								\
+	}																		\
+	if ((__HCarg_p)->status != GNTST_okay)									\
+		printk(KERN_ERR "%s: %s gnt status %x\n", 							\
+			__func__, current->comm, (__HCarg_p)->status);					\
+} while(0)
+
+#define gnttab_check_GNTST_eagain_do_while(__HCop, __HCarg_p)			\
+do {																	\
+	u8 __hc_delay = 1;													\
+	int __ret;															\
+	do {																\
+		__ret = HYPERVISOR_grant_table_op(__HCop, (__HCarg_p), 1);		\
+		BUG_ON(__ret);													\
+		if ((__HCarg_p)->status == GNTST_eagain)						\
+			msleep(__hc_delay++);										\
+	} while ((__HCarg_p)->status == GNTST_eagain && __hc_delay);		\
+	if (__hc_delay == 0) {												\
+		printk(KERN_ERR "%s: %s gnt busy\n", __func__, current->comm);	\
+		(__HCarg_p)->status = GNTST_bad_page;							\
+	}																	\
+	if ((__HCarg_p)->status != GNTST_okay)								\
+		printk(KERN_ERR "%s: %s gnt status %x\n", 						\
+			__func__, current->comm, (__HCarg_p)->status);				\
+} while(0)
+
 #endif /* __ASM_GNTTAB_H__ */

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 20:53:17 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 20:53:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWDcf-00089V-4b; Thu, 01 Dec 2011 20:52:49 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RWDcd-00089Q-Ju
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 20:52:48 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-8.tower-27.messagelabs.com!1322772624!54531986!1
X-Originating-IP: [208.97.132.177]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNzcgPT4gMTU3NzI=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9069 invoked from network); 1 Dec 2011 20:50:25 -0000
Received: from caiajhbdcbhh.dreamhost.com (HELO homiemail-a13.g.dreamhost.com)
	(208.97.132.177) by server-8.tower-27.messagelabs.com with SMTP;
	1 Dec 2011 20:50:25 -0000
Received: from homiemail-a13.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a13.g.dreamhost.com (Postfix) with ESMTP id AA09133406C;
	Thu,  1 Dec 2011 12:52:10 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=Z/VdK6/CqutZrhie3C3ZJrfF+qbbNgoN65lVpmb+/JEB
	R1xM3WYj6B/qxm36AKn/omRXKOytK4QdaGr9lq5eMouQWEKsF/P3UXP23zT329wq
	ayYfczJti/SbbbcCmTiTdIpUv5D8Wn5yeJ10FewAvEHRTrn9L5ZrFz7TOAyxli4=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=EUQcF0sgjHFmQw/qMOVbnoctCJU=; b=NKncQEKwxAd
	CEywBW8/WbwBCKdrIVIkL9Gdn7rOtkJuWRPINABtg2vhJp4yNtirLlGiU2EofU33
	H/yXppDWAB3QWT/0xqwBTnH6z/JUmwVmwNYCtYhT4CrB6QGq7XI3WXgbIOAoFh2a
	z3riPs9a9BlSbypOrmibEq28cwNYpflA=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a13.g.dreamhost.com (Postfix) with ESMTPSA id B5B54334063; 
	Thu,  1 Dec 2011 12:52:09 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 1170bc32db41a7ae1e95c82aeec4c993e5a7e8a6
Message-Id: <1170bc32db41a7ae1e95.1322772715@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1322772713@xdev.gridcentric.ca>
References: <patchbomb.1322772713@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Thu, 01 Dec 2011 15:51:55 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: mike.mcclurg@citrix.com, andres@gridcentric.ca, olaf@aepfle.de,
	jonathan.ludlam@eu.citrix.com, JBeulich@suse.com
Subject: [Xen-devel] [PATCH 2 of 2] xenpaging: handle GNTST_eagain in kernel
	drivers
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 drivers/xen/blkback/blkback.c              |   6 ++-
 drivers/xen/blkback/interface.c            |   9 +++-
 drivers/xen/core/gnttab.c                  |   4 +-
 drivers/xen/gntdev/gntdev.c                |  49 +++++++++++++++++------------
 drivers/xen/netback/interface.c            |   5 +-
 drivers/xen/netback/netback.c              |  16 ++++++---
 drivers/xen/scsiback/interface.c           |  10 +++---
 drivers/xen/scsiback/scsiback.c            |   4 +-
 drivers/xen/tpmback/interface.c            |   7 +--
 drivers/xen/tpmback/tpmback.c              |  20 ++++-------
 drivers/xen/usbback/interface.c            |  16 ++++----
 drivers/xen/usbback/usbback.c              |   4 +-
 drivers/xen/xenbus/xenbus_backend_client.c |  10 +++---
 include/xen/gnttab.h                       |  37 ++++++++++++++++++++++
 14 files changed, 126 insertions(+), 71 deletions(-)


Handle GNTST_eagain status from GNTTABOP_map_grant_ref and
GNTTABOP_copy operations properly to allow usage of xenpaging without
causing crashes or data corruption.

Replace all relevant HYPERVISOR_grant_table_op() calls with a retry
loop. This loop is implemented as a macro to allow different
GNTTABOP_* args. It will sleep up to 33 seconds and wait for the
page to be paged in again.

All ->status checks were updated to use the GNTST_* namespace. All
return values are converted from GNTST_* namespace to 0/-EINVAL, since
all callers did not use the actual return value.

Signed-off-by: Olaf Hering <olaf@aepfle.de>
Acked-by: Patrick Colp <pjcolp@cs.ubc.ca>

This is a port from xenlinux 2.6.18 to the 2.6.32 xcp tree
Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r df9e25a0189b -r 1170bc32db41 drivers/xen/blkback/blkback.c
--- a/drivers/xen/blkback/blkback.c
+++ b/drivers/xen/blkback/blkback.c
@@ -701,11 +701,13 @@ static void dispatch_rw_block_io(blkif_t
 	BUG_ON(ret);
 
 	for (i = 0; i < nseg; i++) {
-		if (unlikely(map[i].status != 0)) {
+		if (unlikely(map[i].status == GNTST_eagain))
+			gnttab_check_GNTST_eagain_do_while(GNTTABOP_map_grant_ref, &map[i]);
+		if (unlikely(map[i].status != GNTST_okay)) {
 			DPRINTK("grant map of dom %u gref %u failed: status %d\n",
 				blkif->domid, req->seg[i].gref, map[i].status);
 			map[i].handle = BLKBACK_INVALID_HANDLE;
-			ret |= 1;
+			ret = 1;
 			continue;
 		}
 
diff -r df9e25a0189b -r 1170bc32db41 drivers/xen/blkback/interface.c
--- a/drivers/xen/blkback/interface.c
+++ b/drivers/xen/blkback/interface.c
@@ -95,7 +95,7 @@ static int map_frontend_pages(blkif_t *b
 	struct vm_struct *area = blkif->blk_ring_area;
 	struct gnttab_map_grant_ref op[BLKIF_MAX_RING_PAGES];
 	unsigned int i;
-	int status = 0;
+	int status = GNTST_okay;
 
 	for (i = 0; i < nr_shared_pages; i++) {
 		unsigned long addr = (unsigned long)area->addr +
@@ -110,7 +110,10 @@ static int map_frontend_pages(blkif_t *b
 		BUG();
 
 	for (i = 0; i < nr_shared_pages; i++) {
-		if ((status = op[i].status) != 0) {
+		if (op[i].status == GNTST_eagain)
+			gnttab_check_GNTST_eagain_do_while(GNTTABOP_map_grant_ref, &op[i]);
+		if (op[i].status != GNTST_okay) {
+			status = op[i].status;
 			blkif->shmem_handle[i] = INVALID_GRANT_HANDLE;
 			continue;
 		}
@@ -120,7 +123,7 @@ static int map_frontend_pages(blkif_t *b
 
 	blkif->nr_shared_pages = nr_shared_pages;
 
-	if (status != 0) {
+	if (status != GNTST_okay) {
 		DPRINTK(" Grant table operation failure !\n");
 		unmap_frontend_pages(blkif);
 	}
diff -r df9e25a0189b -r 1170bc32db41 drivers/xen/core/gnttab.c
--- a/drivers/xen/core/gnttab.c
+++ b/drivers/xen/core/gnttab.c
@@ -773,7 +773,7 @@ static int gnttab_map(unsigned int start
 		return -ENOSYS;
 	}
 
-	BUG_ON(rc || setup.status);
+	BUG_ON(rc || (setup.status != GNTST_okay));
 
 	if (shared.raw == NULL)
 		shared.raw = arch_gnttab_alloc_shared(gframes);
@@ -901,7 +901,7 @@ int gnttab_copy_grant_page(grant_ref_t r
 	err = HYPERVISOR_grant_table_op(GNTTABOP_unmap_and_replace,
 					&unmap, 1);
 	BUG_ON(err);
-	BUG_ON(unmap.status);
+	BUG_ON(unmap.status != GNTST_okay);
 
 	write_sequnlock_irq(&gnttab_dma_lock);
 
diff -r df9e25a0189b -r 1170bc32db41 drivers/xen/gntdev/gntdev.c
--- a/drivers/xen/gntdev/gntdev.c
+++ b/drivers/xen/gntdev/gntdev.c
@@ -503,7 +503,7 @@ static int gntdev_mmap (struct file *fli
 	uint64_t ptep;
 	int ret;
 	int flags;
-	int i;
+	int i, exit_ret;
 	struct page *page;
 	gntdev_file_private_data_t *private_data = flip->private_data;
 
@@ -578,6 +578,7 @@ static int gntdev_mmap (struct file *fli
 	vma->vm_mm->context.has_foreign_mappings = 1;
 #endif
 
+	exit_ret = -ENOMEM;
 	for (i = 0; i < size; ++i) {
 
 		flags = GNTMAP_host_map;
@@ -598,14 +599,18 @@ static int gntdev_mmap (struct file *fli
 		ret = HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, 
 						&op, 1);
 		BUG_ON(ret);
-		if (op.status) {
-			printk(KERN_ERR "Error mapping the grant reference "
-			       "into the kernel (%d). domid = %d; ref = %d\n",
-			       op.status,
-			       private_data->grants[slot_index+i]
-			       .u.valid.domid,
-			       private_data->grants[slot_index+i]
-			       .u.valid.ref);
+		if (op.status != GNTST_okay) {
+			if (op.status != GNTST_eagain)
+				printk(KERN_ERR "Error mapping the grant reference "
+					   "into the kernel (%d). domid = %d; ref = %d\n",
+					   op.status,
+					   private_data->grants[slot_index+i]
+					   .u.valid.domid,
+					   private_data->grants[slot_index+i]
+					   .u.valid.ref);
+			else
+				/* Propagate instead of trying to fix it up */
+				exit_ret = -EAGAIN;
 			goto undo_map_out;
 		}
 
@@ -674,14 +679,17 @@ static int gntdev_mmap (struct file *fli
 			ret = HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref,
 							&op, 1);
 			BUG_ON(ret);
-			if (op.status) {
+			if (op.status != GNTST_okay) {
 				printk(KERN_ERR "Error mapping the grant "
-				       "reference into user space (%d). domid "
-				       "= %d; ref = %d\n", op.status,
-				       private_data->grants[slot_index+i].u
-				       .valid.domid,
-				       private_data->grants[slot_index+i].u
-				       .valid.ref);
+					   "reference into user space (%d). domid "
+					   "= %d; ref = %d\n", op.status,
+					   private_data->grants[slot_index+i].u
+					   .valid.domid,
+					   private_data->grants[slot_index+i].u
+					   .valid.ref);
+				/* GNTST_eagain (i.e. page paged out) sohuld never happen
+				 * once we've mapped into kernel space */
+				BUG_ON(op.status == GNTST_eagain);
 				goto undo_map_out;
 			}
 			
@@ -705,9 +713,10 @@ static int gntdev_mmap (struct file *fli
 		}
 
 	}
+	exit_ret = 0;
 
 	up_write(&private_data->grants_sem);
-	return 0;
+	return exit_ret;
 
 undo_map_out:
 	/* If we have a mapping failure, the unmapping will be taken care of
@@ -725,7 +734,7 @@ undo_map_out:
 	
 	up_write(&private_data->grants_sem);
 
-	return -ENOMEM;
+	return exit_ret;
 }
 
 static pte_t gntdev_clear_pte(struct vm_area_struct *vma, unsigned long addr,
@@ -777,7 +786,7 @@ static pte_t gntdev_clear_pte(struct vm_
 			ret = HYPERVISOR_grant_table_op(
 				GNTTABOP_unmap_grant_ref, &op, 1);
 			BUG_ON(ret);
-			if (op.status)
+			if (op.status != GNTST_okay)
 				printk("User unmap grant status = %d\n", 
 				       op.status);
 		} else {
@@ -794,7 +803,7 @@ static pte_t gntdev_clear_pte(struct vm_
 		ret = HYPERVISOR_grant_table_op(GNTTABOP_unmap_grant_ref, 
 						&op, 1);
 		BUG_ON(ret);
-		if (op.status)
+		if (op.status != GNTST_okay)
 			printk("Kernel unmap grant status = %d\n", op.status);
 
 
diff -r df9e25a0189b -r 1170bc32db41 drivers/xen/netback/interface.c
--- a/drivers/xen/netback/interface.c
+++ b/drivers/xen/netback/interface.c
@@ -381,10 +381,9 @@ static int map_frontend_pages(struct xen
 	gnttab_set_map_op(&op, (unsigned long)comms->ring_area->addr,
 			  GNTMAP_host_map, ring_ref, domid);
     
-	if (HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, &op, 1))
-		BUG();
+	gnttab_check_GNTST_eagain_do_while(GNTTABOP_map_grant_ref, &op);
 
-	if (op.status) {
+	if (op.status != GNTST_okay) {
 		DPRINTK(" Gnttab failure mapping ring_ref!\n");
 		free_vm_area(comms->ring_area);
 		return op.status;
diff -r df9e25a0189b -r 1170bc32db41 drivers/xen/netback/netback.c
--- a/drivers/xen/netback/netback.c
+++ b/drivers/xen/netback/netback.c
@@ -419,11 +419,13 @@ static int netbk_check_gop(int nr_copy_s
 
 	for (i = 0; i < nr_copy_slots; i++) {
 		copy_op = npo->copy + npo->copy_cons++;
+		if (copy_op->status == GNTST_eagain)
+			gnttab_check_GNTST_eagain_while(GNTTABOP_copy, copy_op);
 		if (copy_op->status != GNTST_okay) {
-				DPRINTK("Bad status %d from copy to DOM%d.\n",
-					copy_op->status, domid);
-				status = NETIF_RSP_ERROR;
-			}
+			DPRINTK("Bad status %d from copy to DOM%d.\n",
+				copy_op->status, domid);
+			status = NETIF_RSP_ERROR;
+		}
 	}
 
 	return status;
@@ -1020,7 +1022,11 @@ static int netbk_tx_check_mop(struct xen
 
 	/* Check status of header. */
 	err = mop->status;
-	if (unlikely(err)) {
+	if (err == GNTST_eagain) {
+		gnttab_check_GNTST_eagain_do_while(GNTTABOP_map_grant_ref, mop);
+		err = mop->status;
+	}
+	if (unlikely(err != GNTST_okay)) {
 		pending_ring_idx_t index;
 		index = pending_index(netbk->pending_prod++);
 		txp = &pending_tx_info[pending_idx].req;
diff -r df9e25a0189b -r 1170bc32db41 drivers/xen/scsiback/interface.c
--- a/drivers/xen/scsiback/interface.c
+++ b/drivers/xen/scsiback/interface.c
@@ -69,18 +69,18 @@ static int map_frontend_page( struct vsc
 				GNTMAP_host_map, ring_ref,
 				info->domid);
 
-	err = HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, &op, 1);
-	BUG_ON(err);
+	gnttab_check_GNTST_eagain_do_while(GNTTABOP_map_grant_ref, &op);
 
-	if (op.status) {
-		printk(KERN_ERR "scsiback: Grant table operation failure !\n");
+	if (op.status != GNTST_okay) {
+		printk(KERN_ERR "scsiback: Grant table operation failure %d!\n", 
+							(int) op.status);
 		return op.status;
 	}
 
 	info->shmem_ref    = ring_ref;
 	info->shmem_handle = op.handle;
 
-	return (GNTST_okay);
+	return 0;
 }
 
 static void unmap_frontend_page(struct vscsibk_info *info)
diff -r df9e25a0189b -r 1170bc32db41 drivers/xen/scsiback/scsiback.c
--- a/drivers/xen/scsiback/scsiback.c
+++ b/drivers/xen/scsiback/scsiback.c
@@ -287,7 +287,9 @@ static int scsiback_gnttab_data_map(vscs
 		for_each_sg (pending_req->sgl, sg, nr_segments, i) {
 			struct page *pg;
 
-			if (unlikely(map[i].status != 0)) {
+			if (unlikely(map[i].status == GNTST_eagain))
+				gnttab_check_GNTST_eagain_while(GNTTABOP_map_grant_ref, &map[i]);
+			if (unlikely(map[i].status != GNTST_okay)) {
 				printk(KERN_ERR "scsiback: invalid buffer -- could not remap it\n");
 				map[i].handle = SCSIBACK_INVALID_HANDLE;
 				err |= 1;
diff -r df9e25a0189b -r 1170bc32db41 drivers/xen/tpmback/interface.c
--- a/drivers/xen/tpmback/interface.c
+++ b/drivers/xen/tpmback/interface.c
@@ -86,11 +86,10 @@ static int map_frontend_page(tpmif_t *tp
 	gnttab_set_map_op(&op, (unsigned long)tpmif->tx_area->addr,
 			  GNTMAP_host_map, shared_page, tpmif->domid);
 
-	if (HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, &op, 1))
-		BUG();
+	gnttab_check_GNTST_eagain_do_while(GNTTABOP_map_grant_ref, &op);
 
-	if (op.status) {
-		DPRINTK(" Grant table operation failure !\n");
+	if (op.status != GNTST_okay) {
+		DPRINTK(" Grant table operation failure %d!\n", (int) op.status);
 		return op.status;
 	}
 
diff -r df9e25a0189b -r 1170bc32db41 drivers/xen/tpmback/tpmback.c
--- a/drivers/xen/tpmback/tpmback.c
+++ b/drivers/xen/tpmback/tpmback.c
@@ -256,15 +256,13 @@ int _packet_write(struct packet *pak,
 		gnttab_set_map_op(&map_op, idx_to_kaddr(tpmif, i),
 				  GNTMAP_host_map, tx->ref, tpmif->domid);
 
-		if (unlikely(HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref,
-						       &map_op, 1))) {
-			BUG();
-		}
+		gnttab_check_GNTST_eagain_do_while(GNTTABOP_map_grant_ref, &map_op);
 
 		handle = map_op.handle;
 
-		if (map_op.status) {
-			DPRINTK(" Grant table operation failure !\n");
+		if (map_op.status != GNTST_okay) {
+			DPRINTK(" Grant table operation failure %d!\n", 
+						(int) map_op.status);
 			return 0;
 		}
 
@@ -394,13 +392,11 @@ static int packet_read_shmem(struct pack
 		gnttab_set_map_op(&map_op, idx_to_kaddr(tpmif, i),
 				  GNTMAP_host_map, tx->ref, tpmif->domid);
 
-		if (unlikely(HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref,
-						       &map_op, 1))) {
-			BUG();
-		}
+		gnttab_check_GNTST_eagain_do_while(GNTTABOP_map_grant_ref, &map_op);
 
-		if (map_op.status) {
-			DPRINTK(" Grant table operation failure !\n");
+		if (map_op.status != GNTST_okay) {
+			DPRINTK(" Grant table operation failure %d!\n",
+						(int) map_op.status);
 			return -EFAULT;
 		}
 
diff -r df9e25a0189b -r 1170bc32db41 drivers/xen/usbback/interface.c
--- a/drivers/xen/usbback/interface.c
+++ b/drivers/xen/usbback/interface.c
@@ -109,11 +109,11 @@ static int map_frontend_pages(usbif_t *u
 	gnttab_set_map_op(&op, (unsigned long)usbif->urb_ring_area->addr,
 			  GNTMAP_host_map, urb_ring_ref, usbif->domid);
 
-	if (HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, &op, 1))
-		BUG();
+	gnttab_check_GNTST_eagain_do_while(GNTTABOP_map_grant_ref, &op);
 
-	if (op.status) {
-		printk(KERN_ERR "grant table failure mapping urb_ring_ref\n");
+	if (op.status != GNTST_okay) {
+		printk(KERN_ERR "grant table failure mapping urb_ring_ref %d\n",
+							(int) op.status);
 		return op.status;
 	}
 
@@ -123,17 +123,17 @@ static int map_frontend_pages(usbif_t *u
 	gnttab_set_map_op(&op, (unsigned long)usbif->conn_ring_area->addr,
 			  GNTMAP_host_map, conn_ring_ref, usbif->domid);
 
-	if (HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, &op, 1))
-		BUG();
+	gnttab_check_GNTST_eagain_do_while(GNTTABOP_map_grant_ref, &op);
 
-	if (op.status) {
+	if (op.status != GNTST_okay) {
 		struct gnttab_unmap_grant_ref unop;
 		gnttab_set_unmap_op(&unop,
 				(unsigned long) usbif->urb_ring_area->addr,
 				GNTMAP_host_map, usbif->urb_shmem_handle);
 		VOID(HYPERVISOR_grant_table_op(GNTTABOP_unmap_grant_ref, &unop,
 				1));
-		printk(KERN_ERR "grant table failure mapping conn_ring_ref\n");
+		printk(KERN_ERR "grant table failure mapping conn_ring_ref %d\n",
+							(int) op.status);
 		return op.status;
 	}
 
diff -r df9e25a0189b -r 1170bc32db41 drivers/xen/usbback/usbback.c
--- a/drivers/xen/usbback/usbback.c
+++ b/drivers/xen/usbback/usbback.c
@@ -428,7 +428,9 @@ static int usbbk_gnttab_map(usbif_t *usb
 		BUG_ON(ret);
 
 		for (i = 0; i < nr_segs; i++) {
-			if (unlikely(map[i].status != 0)) {
+			if (unlikely(map[i].status == GNTST_eagain))
+				gnttab_check_GNTST_eagain_while(GNTTABOP_map_grant_ref, &map[i]);
+			if (unlikely(map[i].status != GNTST_okay)) {
 				printk(KERN_ERR "usbback: invalid buffer -- could not remap it\n");
 				map[i].handle = USBBACK_INVALID_HANDLE;
 				ret |= 1;
diff -r df9e25a0189b -r 1170bc32db41 drivers/xen/xenbus/xenbus_backend_client.c
--- a/drivers/xen/xenbus/xenbus_backend_client.c
+++ b/drivers/xen/xenbus/xenbus_backend_client.c
@@ -48,8 +48,7 @@ struct vm_struct *xenbus_map_ring_valloc
 	gnttab_set_map_op(&op, (unsigned long)area->addr, GNTMAP_host_map,
 			  gnt_ref, dev->otherend_id);
 	
-	if (HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, &op, 1))
-		BUG();
+	gnttab_check_GNTST_eagain_do_while(GNTTABOP_map_grant_ref, &op);
 
 	if (op.status != GNTST_okay) {
 		free_vm_area(area);
@@ -75,15 +74,16 @@ int xenbus_map_ring(struct xenbus_device
 	
 	gnttab_set_map_op(&op, (unsigned long)vaddr, GNTMAP_host_map,
 			  gnt_ref, dev->otherend_id);
-	if (HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, &op, 1))
-		BUG();
+	gnttab_check_GNTST_eagain_do_while(GNTTABOP_map_grant_ref, &op);
 
 	if (op.status != GNTST_okay) {
 		xenbus_dev_fatal(dev, op.status,
 				 "mapping in shared page %d from domain %d",
 				 gnt_ref, dev->otherend_id);
-	} else
+	} else {
 		*handle = op.handle;
+		return 0;
+	}
 
 	return op.status;
 }
diff -r df9e25a0189b -r 1170bc32db41 include/xen/gnttab.h
--- a/include/xen/gnttab.h
+++ b/include/xen/gnttab.h
@@ -187,4 +187,41 @@ gnttab_set_replace_op(struct gnttab_unma
 	unmap->handle = handle;
 }
 
+#define gnttab_check_GNTST_eagain_while(__HCop, __HCarg_p)					\
+do {																		\
+	u8 __hc_delay = 1;														\
+	int __ret;																\
+	while (unlikely((__HCarg_p)->status == GNTST_eagain && __hc_delay)) {	\
+		msleep(__hc_delay++);												\
+		__ret = HYPERVISOR_grant_table_op(__HCop, (__HCarg_p), 1);			\
+		BUG_ON(__ret);														\
+	}																		\
+	if (__hc_delay == 0) {													\
+		printk(KERN_ERR "%s: %s gnt busy\n", __func__, current->comm);		\
+		(__HCarg_p)->status = GNTST_bad_page;								\
+	}																		\
+	if ((__HCarg_p)->status != GNTST_okay)									\
+		printk(KERN_ERR "%s: %s gnt status %x\n", 							\
+			__func__, current->comm, (__HCarg_p)->status);					\
+} while(0)
+
+#define gnttab_check_GNTST_eagain_do_while(__HCop, __HCarg_p)			\
+do {																	\
+	u8 __hc_delay = 1;													\
+	int __ret;															\
+	do {																\
+		__ret = HYPERVISOR_grant_table_op(__HCop, (__HCarg_p), 1);		\
+		BUG_ON(__ret);													\
+		if ((__HCarg_p)->status == GNTST_eagain)						\
+			msleep(__hc_delay++);										\
+	} while ((__HCarg_p)->status == GNTST_eagain && __hc_delay);		\
+	if (__hc_delay == 0) {												\
+		printk(KERN_ERR "%s: %s gnt busy\n", __func__, current->comm);	\
+		(__HCarg_p)->status = GNTST_bad_page;							\
+	}																	\
+	if ((__HCarg_p)->status != GNTST_okay)								\
+		printk(KERN_ERR "%s: %s gnt status %x\n", 						\
+			__func__, current->comm, (__HCarg_p)->status);				\
+} while(0)
+
 #endif /* __ASM_GNTTAB_H__ */

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 20:53:17 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 20:53:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWDch-00089j-GS; Thu, 01 Dec 2011 20:52:51 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RWDcg-00089O-2A
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 20:52:50 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-14.tower-182.messagelabs.com!1322772729!5524972!1
X-Originating-IP: [208.97.132.145]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNDUgPT4gMTY3NDc=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23913 invoked from network); 1 Dec 2011 20:52:09 -0000
Received: from caiajhbdcbef.dreamhost.com (HELO homiemail-a13.g.dreamhost.com)
	(208.97.132.145) by server-14.tower-182.messagelabs.com with SMTP;
	1 Dec 2011 20:52:09 -0000
Received: from homiemail-a13.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a13.g.dreamhost.com (Postfix) with ESMTP id 85F2F33406D;
	Thu,  1 Dec 2011 12:52:08 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id:date
	:from:to:cc; q=dns; s=lagarcavilla.org; b=jHXQLBsCkJlXTgEe+fueSI
	g3D5NY6kS5qV7O5vb5vNcIcDIEbHx6+/htdw52B4cLQPGocgWiI9BPgUNEiPD5lm
	e/lCIabjTA7Y6Ic6Cdn8RL3Osrcbql3yo6TDtSCRmSUP/cKPXJcOGQDnQWcYM7YC
	GIhuTphVOcTbepxfpMfS0=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:date:from:to:cc; s=lagarcavilla.org; bh=+iC5irlD5qnT
	GLBMa8IMY0JqZTg=; b=qpQWoYrlcjnXx0dlU9GZxtmBtXRquWcblvY4F5yA+Mwy
	4sjED30TCEim41ya+0VuKbpzpQIgBLpx+W0DwI7CIkB5yL6+rrI/SlR/oxp6zMDe
	v6MJ7EaRESeEwECQu3ExzxsIxN0qc/A6oNb0pdDS7qrQNn13Tgj22tMcWK+2xvM=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a13.g.dreamhost.com (Postfix) with ESMTPSA id BC32C33406B; 
	Thu,  1 Dec 2011 12:52:07 -0800 (PST)
MIME-Version: 1.0
Message-Id: <patchbomb.1322772713@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Thu, 01 Dec 2011 15:51:53 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: mike.mcclurg@citrix.com, andres@gridcentric.ca, olaf@aepfle.de,
	jonathan.ludlam@eu.citrix.com, JBeulich@suse.com
Subject: [Xen-devel] [PATCH 0 of 2] Paging support updates for XCP dom0
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a cherry pick of two patches that add support for guest paged out
frames in the XCP 2.6.32 dom0 patch queue.

First patch propagates the ENOENT returned by the hypervisor in the case
of a paged out page, all the way up the call chain to the MMAPBATCH_V2
ioctl. The ioctl is mainly used to harvest those return values and retry.

The second patch adds retry loops to all backend grant operations (map and
netback copy), in the case of a paged out frame.

Signed-off-by: Olaf Hering <olaf@aepfle.de>
Signed-off-by: Jan Beulich <jbeulich@novell.com>
Acked-by: Patrick Colp <pjcolp@cs.ubc.ca>
Acked-by: Andres Lagar-Cavilla <andres@lagarcavilla>
Ported and submitted by Andres Lagar-Cavilla

 arch/x86/mm/ioremap-xen.c                  |  12 ++----
 drivers/xen/blkback/blkback.c              |   6 ++-
 drivers/xen/blkback/interface.c            |   9 +++-
 drivers/xen/core/gnttab.c                  |   4 +-
 drivers/xen/gntdev/gntdev.c                |  49 +++++++++++++++++------------
 drivers/xen/netback/interface.c            |   5 +-
 drivers/xen/netback/netback.c              |  16 ++++++---
 drivers/xen/scsiback/interface.c           |  10 +++---
 drivers/xen/scsiback/scsiback.c            |   4 +-
 drivers/xen/tpmback/interface.c            |   7 +--
 drivers/xen/tpmback/tpmback.c              |  20 ++++-------
 drivers/xen/usbback/interface.c            |  16 ++++----
 drivers/xen/usbback/usbback.c              |   4 +-
 drivers/xen/xenbus/xenbus_backend_client.c |  10 +++---
 include/xen/gnttab.h                       |  37 ++++++++++++++++++++++
 15 files changed, 130 insertions(+), 79 deletions(-)

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 20:53:17 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 20:53:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWDch-00089j-GS; Thu, 01 Dec 2011 20:52:51 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RWDcg-00089O-2A
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 20:52:50 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-14.tower-182.messagelabs.com!1322772729!5524972!1
X-Originating-IP: [208.97.132.145]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNDUgPT4gMTY3NDc=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23913 invoked from network); 1 Dec 2011 20:52:09 -0000
Received: from caiajhbdcbef.dreamhost.com (HELO homiemail-a13.g.dreamhost.com)
	(208.97.132.145) by server-14.tower-182.messagelabs.com with SMTP;
	1 Dec 2011 20:52:09 -0000
Received: from homiemail-a13.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a13.g.dreamhost.com (Postfix) with ESMTP id 85F2F33406D;
	Thu,  1 Dec 2011 12:52:08 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id:date
	:from:to:cc; q=dns; s=lagarcavilla.org; b=jHXQLBsCkJlXTgEe+fueSI
	g3D5NY6kS5qV7O5vb5vNcIcDIEbHx6+/htdw52B4cLQPGocgWiI9BPgUNEiPD5lm
	e/lCIabjTA7Y6Ic6Cdn8RL3Osrcbql3yo6TDtSCRmSUP/cKPXJcOGQDnQWcYM7YC
	GIhuTphVOcTbepxfpMfS0=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:date:from:to:cc; s=lagarcavilla.org; bh=+iC5irlD5qnT
	GLBMa8IMY0JqZTg=; b=qpQWoYrlcjnXx0dlU9GZxtmBtXRquWcblvY4F5yA+Mwy
	4sjED30TCEim41ya+0VuKbpzpQIgBLpx+W0DwI7CIkB5yL6+rrI/SlR/oxp6zMDe
	v6MJ7EaRESeEwECQu3ExzxsIxN0qc/A6oNb0pdDS7qrQNn13Tgj22tMcWK+2xvM=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a13.g.dreamhost.com (Postfix) with ESMTPSA id BC32C33406B; 
	Thu,  1 Dec 2011 12:52:07 -0800 (PST)
MIME-Version: 1.0
Message-Id: <patchbomb.1322772713@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Thu, 01 Dec 2011 15:51:53 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: mike.mcclurg@citrix.com, andres@gridcentric.ca, olaf@aepfle.de,
	jonathan.ludlam@eu.citrix.com, JBeulich@suse.com
Subject: [Xen-devel] [PATCH 0 of 2] Paging support updates for XCP dom0
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a cherry pick of two patches that add support for guest paged out
frames in the XCP 2.6.32 dom0 patch queue.

First patch propagates the ENOENT returned by the hypervisor in the case
of a paged out page, all the way up the call chain to the MMAPBATCH_V2
ioctl. The ioctl is mainly used to harvest those return values and retry.

The second patch adds retry loops to all backend grant operations (map and
netback copy), in the case of a paged out frame.

Signed-off-by: Olaf Hering <olaf@aepfle.de>
Signed-off-by: Jan Beulich <jbeulich@novell.com>
Acked-by: Patrick Colp <pjcolp@cs.ubc.ca>
Acked-by: Andres Lagar-Cavilla <andres@lagarcavilla>
Ported and submitted by Andres Lagar-Cavilla

 arch/x86/mm/ioremap-xen.c                  |  12 ++----
 drivers/xen/blkback/blkback.c              |   6 ++-
 drivers/xen/blkback/interface.c            |   9 +++-
 drivers/xen/core/gnttab.c                  |   4 +-
 drivers/xen/gntdev/gntdev.c                |  49 +++++++++++++++++------------
 drivers/xen/netback/interface.c            |   5 +-
 drivers/xen/netback/netback.c              |  16 ++++++---
 drivers/xen/scsiback/interface.c           |  10 +++---
 drivers/xen/scsiback/scsiback.c            |   4 +-
 drivers/xen/tpmback/interface.c            |   7 +--
 drivers/xen/tpmback/tpmback.c              |  20 ++++-------
 drivers/xen/usbback/interface.c            |  16 ++++----
 drivers/xen/usbback/usbback.c              |   4 +-
 drivers/xen/xenbus/xenbus_backend_client.c |  10 +++---
 include/xen/gnttab.h                       |  37 ++++++++++++++++++++++
 15 files changed, 130 insertions(+), 79 deletions(-)

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 20:56:42 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 20:56:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWDg3-0008VB-PL; Thu, 01 Dec 2011 20:56:19 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RWDg2-0008Ua-Bs
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 20:56:18 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-10.tower-21.messagelabs.com!1322772937!6533663!1
X-Originating-IP: [208.97.132.83]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi44MyA9PiAxNTQ4OQ==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32651 invoked from network); 1 Dec 2011 20:55:38 -0000
Received: from caiajhbdcaid.dreamhost.com (HELO homiemail-a13.g.dreamhost.com)
	(208.97.132.83) by server-10.tower-21.messagelabs.com with SMTP;
	1 Dec 2011 20:55:38 -0000
Received: from homiemail-a13.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a13.g.dreamhost.com (Postfix) with ESMTP id DDAB9334064;
	Thu,  1 Dec 2011 12:55:36 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id:date
	:from:to:cc; q=dns; s=lagarcavilla.org; b=W3onPJ8PnC2UA/YS0RBpY2
	4Ywz7LiNQ0DwAThUAE1p1dt/bUTsj2/VwgsLPHH20NwKgmOHPkptzPtLjhFTcjRL
	qgU+Z4akeF/1Qh6msySAQTt7fXo8Gl6luffVFP6qEnYi5sC+RGM0aqtsTvpsVXM9
	iZfK45j8jJok9IlUL0HtM=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:date:from:to:cc; s=lagarcavilla.org; bh=VgdgbeXxrdXJ
	0N204ZFPNiDQzVY=; b=iQslTG/Qhu/roggmotZ+uD+HScxB1vHqieCVNEBHFC1X
	dkv8m3BMcV4i4Szmq8oxHwYp97dvaOY33+firMVeHmnMB2k9/5qKwnCyo0oN14Xz
	0C57I9BVmIV7IHDdNv2pUMilc/gtiCi4pEQBwX2gGARz4D9/pLu8Qdut57K9c9Q=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a13.g.dreamhost.com (Postfix) with ESMTPSA id B7282334069; 
	Thu,  1 Dec 2011 12:55:35 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 2a4ec2e2ae36593aa74e306bb8400db53ec1e166
Message-Id: <2a4ec2e2ae36593aa74e.1322772973@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Thu, 01 Dec 2011 15:56:13 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, keir.xen@gmail.com, tim@xen.org, olaf@aepfle.de,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH] Flag events caused by foreign domains
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/mm/mem_event.c    |  6 ++++++
 xen/include/public/mem_event.h |  1 +
 2 files changed, 7 insertions(+), 0 deletions(-)


Add a new flag for mem events, as consumers might need to discriminate
foreign domain-caused from guest-caused events. The vcpu field of an
event is bogus from a consumer p.o.v. for foreign domain-caused events.

Also assert that we shouldn't be pausing foreign vcpus.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla>

diff -r 8ad7af68e017 -r 2a4ec2e2ae36 xen/arch/x86/mm/mem_event.c
--- a/xen/arch/x86/mm/mem_event.c
+++ b/xen/arch/x86/mm/mem_event.c
@@ -143,6 +143,12 @@ void mem_event_put_request(struct domain
     front_ring = &med->front_ring;
     req_prod = front_ring->req_prod_pvt;
 
+    if ( current->domain != d )
+    {
+        req->flags |= MEM_EVENT_FLAG_FOREIGN;
+        ASSERT( !(req->flags & MEM_EVENT_FLAG_VCPU_PAUSED) );
+    }
+
     /* Copy request */
     memcpy(RING_GET_REQUEST(front_ring, req_prod), req, sizeof(*req));
     req_prod++;
diff -r 8ad7af68e017 -r 2a4ec2e2ae36 xen/include/public/mem_event.h
--- a/xen/include/public/mem_event.h
+++ b/xen/include/public/mem_event.h
@@ -39,6 +39,7 @@
 #define MEM_EVENT_FLAG_VCPU_PAUSED  (1 << 0)
 #define MEM_EVENT_FLAG_DROP_PAGE    (1 << 1)
 #define MEM_EVENT_FLAG_EVICT_FAIL   (1 << 2)
+#define MEM_EVENT_FLAG_FOREIGN      (1 << 3)
 
 /* Reasons for the memory event request */
 #define MEM_EVENT_REASON_UNKNOWN     0    /* typical reason */

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 20:56:42 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 20:56:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWDg3-0008VB-PL; Thu, 01 Dec 2011 20:56:19 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RWDg2-0008Ua-Bs
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 20:56:18 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-10.tower-21.messagelabs.com!1322772937!6533663!1
X-Originating-IP: [208.97.132.83]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi44MyA9PiAxNTQ4OQ==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32651 invoked from network); 1 Dec 2011 20:55:38 -0000
Received: from caiajhbdcaid.dreamhost.com (HELO homiemail-a13.g.dreamhost.com)
	(208.97.132.83) by server-10.tower-21.messagelabs.com with SMTP;
	1 Dec 2011 20:55:38 -0000
Received: from homiemail-a13.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a13.g.dreamhost.com (Postfix) with ESMTP id DDAB9334064;
	Thu,  1 Dec 2011 12:55:36 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id:date
	:from:to:cc; q=dns; s=lagarcavilla.org; b=W3onPJ8PnC2UA/YS0RBpY2
	4Ywz7LiNQ0DwAThUAE1p1dt/bUTsj2/VwgsLPHH20NwKgmOHPkptzPtLjhFTcjRL
	qgU+Z4akeF/1Qh6msySAQTt7fXo8Gl6luffVFP6qEnYi5sC+RGM0aqtsTvpsVXM9
	iZfK45j8jJok9IlUL0HtM=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:date:from:to:cc; s=lagarcavilla.org; bh=VgdgbeXxrdXJ
	0N204ZFPNiDQzVY=; b=iQslTG/Qhu/roggmotZ+uD+HScxB1vHqieCVNEBHFC1X
	dkv8m3BMcV4i4Szmq8oxHwYp97dvaOY33+firMVeHmnMB2k9/5qKwnCyo0oN14Xz
	0C57I9BVmIV7IHDdNv2pUMilc/gtiCi4pEQBwX2gGARz4D9/pLu8Qdut57K9c9Q=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a13.g.dreamhost.com (Postfix) with ESMTPSA id B7282334069; 
	Thu,  1 Dec 2011 12:55:35 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 2a4ec2e2ae36593aa74e306bb8400db53ec1e166
Message-Id: <2a4ec2e2ae36593aa74e.1322772973@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Thu, 01 Dec 2011 15:56:13 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, keir.xen@gmail.com, tim@xen.org, olaf@aepfle.de,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH] Flag events caused by foreign domains
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/mm/mem_event.c    |  6 ++++++
 xen/include/public/mem_event.h |  1 +
 2 files changed, 7 insertions(+), 0 deletions(-)


Add a new flag for mem events, as consumers might need to discriminate
foreign domain-caused from guest-caused events. The vcpu field of an
event is bogus from a consumer p.o.v. for foreign domain-caused events.

Also assert that we shouldn't be pausing foreign vcpus.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla>

diff -r 8ad7af68e017 -r 2a4ec2e2ae36 xen/arch/x86/mm/mem_event.c
--- a/xen/arch/x86/mm/mem_event.c
+++ b/xen/arch/x86/mm/mem_event.c
@@ -143,6 +143,12 @@ void mem_event_put_request(struct domain
     front_ring = &med->front_ring;
     req_prod = front_ring->req_prod_pvt;
 
+    if ( current->domain != d )
+    {
+        req->flags |= MEM_EVENT_FLAG_FOREIGN;
+        ASSERT( !(req->flags & MEM_EVENT_FLAG_VCPU_PAUSED) );
+    }
+
     /* Copy request */
     memcpy(RING_GET_REQUEST(front_ring, req_prod), req, sizeof(*req));
     req_prod++;
diff -r 8ad7af68e017 -r 2a4ec2e2ae36 xen/include/public/mem_event.h
--- a/xen/include/public/mem_event.h
+++ b/xen/include/public/mem_event.h
@@ -39,6 +39,7 @@
 #define MEM_EVENT_FLAG_VCPU_PAUSED  (1 << 0)
 #define MEM_EVENT_FLAG_DROP_PAGE    (1 << 1)
 #define MEM_EVENT_FLAG_EVICT_FAIL   (1 << 2)
+#define MEM_EVENT_FLAG_FOREIGN      (1 << 3)
 
 /* Reasons for the memory event request */
 #define MEM_EVENT_REASON_UNKNOWN     0    /* typical reason */

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 22:45:39 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 22:45:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWFND-00010t-6w; Thu, 01 Dec 2011 22:44:59 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RWFNB-00010o-6w
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 22:44:57 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1322779456!5535597!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU2Nw==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15868 invoked from network); 1 Dec 2011 22:44:17 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 22:44:17 -0000
X-IronPort-AV: E=Sophos;i="4.71,281,1320624000"; 
   d="scan'208";a="9240406"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Dec 2011 22:44:16 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 1 Dec 2011 22:44:16 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RWFMW-0005kJ-Gv;
	Thu, 01 Dec 2011 22:44:16 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RWFMW-00047D-GL;
	Thu, 01 Dec 2011 22:44:16 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10214-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 1 Dec 2011 22:44:16 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10214: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

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

Regressions :-(

Tests which did not succeed and are blocking:
 build-amd64-pvops             4 kernel-build              fail REGR. vs. 10201
 build-amd64-oldkern           4 xen-build                 fail REGR. vs. 10201
 test-amd64-i386-win-vcpus1    8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-i386-win           8 guest-saverestore         fail REGR. vs. 10201
 test-i386-i386-win            8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-i386-xl-win-vcpus1  8 guest-saverestore        fail REGR. vs. 10201
 test-i386-i386-xl-win         8 guest-saverestore         fail REGR. vs. 10201

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-i386-xend-winxpsp3  7 windows-install              fail  never pass
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win7-amd64  7 windows-install              fail  never pass
 test-amd64-amd64-xl-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install          fail never pass
 test-i386-i386-xl-winxpsp3    7 windows-install              fail   never pass
 test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win       1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a

version targeted for testing:
 xen                  3f815406feb2
baseline version:
 xen                  62ff6a318c5d

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Anthony PERARD <anthony.perard@citrix.com>
  Brendan Cully <brendan@cs.ubc.ca>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Jonathan Davies <jonathan.davies@citrix.com>
  juergen.gross@ts.fujitsu.com
  Keir Fraser <keir@xen.org>
  Liu, Jinsong <jinsong.liu@intel.com>
  Olaf Hering <olaf@aepfle.de>
  Philipp Hahn <hahn@univention.de>
  Shriram Rajagopalan <rshriram@cs.ubc.ca>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
------------------------------------------------------------

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


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

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

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


Not pushing.

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

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 22:45:39 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 22:45:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWFND-00010t-6w; Thu, 01 Dec 2011 22:44:59 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RWFNB-00010o-6w
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 22:44:57 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1322779456!5535597!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU2Nw==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15868 invoked from network); 1 Dec 2011 22:44:17 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 22:44:17 -0000
X-IronPort-AV: E=Sophos;i="4.71,281,1320624000"; 
   d="scan'208";a="9240406"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Dec 2011 22:44:16 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 1 Dec 2011 22:44:16 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RWFMW-0005kJ-Gv;
	Thu, 01 Dec 2011 22:44:16 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RWFMW-00047D-GL;
	Thu, 01 Dec 2011 22:44:16 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10214-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 1 Dec 2011 22:44:16 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10214: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

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

Regressions :-(

Tests which did not succeed and are blocking:
 build-amd64-pvops             4 kernel-build              fail REGR. vs. 10201
 build-amd64-oldkern           4 xen-build                 fail REGR. vs. 10201
 test-amd64-i386-win-vcpus1    8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-i386-win           8 guest-saverestore         fail REGR. vs. 10201
 test-i386-i386-win            8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-i386-xl-win-vcpus1  8 guest-saverestore        fail REGR. vs. 10201
 test-i386-i386-xl-win         8 guest-saverestore         fail REGR. vs. 10201

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-i386-xend-winxpsp3  7 windows-install              fail  never pass
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win7-amd64  7 windows-install              fail  never pass
 test-amd64-amd64-xl-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install          fail never pass
 test-i386-i386-xl-winxpsp3    7 windows-install              fail   never pass
 test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win       1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a

version targeted for testing:
 xen                  3f815406feb2
baseline version:
 xen                  62ff6a318c5d

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Anthony PERARD <anthony.perard@citrix.com>
  Brendan Cully <brendan@cs.ubc.ca>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Jonathan Davies <jonathan.davies@citrix.com>
  juergen.gross@ts.fujitsu.com
  Keir Fraser <keir@xen.org>
  Liu, Jinsong <jinsong.liu@intel.com>
  Olaf Hering <olaf@aepfle.de>
  Philipp Hahn <hahn@univention.de>
  Shriram Rajagopalan <rshriram@cs.ubc.ca>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
------------------------------------------------------------

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


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

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

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


Not pushing.

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

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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 23:20:21 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 23:20:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWFup-0001Mu-5H; Thu, 01 Dec 2011 23:19:43 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1RWFun-0001Mp-Ee
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 23:19:42 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-12.tower-27.messagelabs.com!1322781515!43247944!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30004 invoked from network); 1 Dec 2011 23:18:36 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-12.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 1 Dec 2011 23:18:36 -0000
Received: from andromeda.dapyr.net (darnok@localhost [127.0.0.1])
	by andromeda.dapyr.net (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id
	pB1NImfp007690
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Thu, 1 Dec 2011 18:18:48 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pB1NIlY4007688;
	Thu, 1 Dec 2011 18:18:47 -0500
Date: Thu, 1 Dec 2011 19:18:47 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Anthony PERARD <anthony.perard@citrix.com>
Message-ID: <20111201231847.GA636@andromeda.dapyr.net>
References: <1322156679-9441-1-git-send-email-anthony.perard@citrix.com>
	<1322156679-9441-8-git-send-email-anthony.perard@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1322156679-9441-8-git-send-email-anthony.perard@citrix.com>
User-Agent: Mutt/1.5.9i
Cc: Guy Zana <guy@neocleus.com>, Xen Devel <xen-devel@lists.xensource.com>,
	Allen Kay <allen.m.kay@intel.com>, QEMU-devel <qemu-devel@nongnu.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH V5 07/10] Introduce Xen PCI Passthrough,
	qdevice (1/3)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Nov 24, 2011 at 05:44:36PM +0000, Anthony PERARD wrote:
> From: Allen Kay <allen.m.kay@intel.com>
> 
> A more complete history can be found here:
> git://xenbits.xensource.com/qemu-xen-unstable.git
> 
> Signed-off-by: Allen Kay <allen.m.kay@intel.com>
> Signed-off-by: Guy Zana <guy@neocleus.com>
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> ---
>  Makefile.target                      |    2 +
>  hw/xen_common.h                      |    3 +
>  hw/xen_pci_passthrough.c             |  831 ++++++++++++++++++++++++++++++++++
>  hw/xen_pci_passthrough.h             |  282 ++++++++++++
>  hw/xen_pci_passthrough_config_init.c |   11 +
>  xen-all.c                            |   12 +
>  6 files changed, 1141 insertions(+), 0 deletions(-)
>  create mode 100644 hw/xen_pci_passthrough.c
>  create mode 100644 hw/xen_pci_passthrough.h
>  create mode 100644 hw/xen_pci_passthrough_config_init.c
> 
> diff --git a/Makefile.target b/Makefile.target
> index e527c1b..33435a3 100644
> --- a/Makefile.target
> +++ b/Makefile.target
> @@ -221,6 +221,8 @@ obj-i386-$(CONFIG_XEN) += xen_platform.o
>  
>  # Xen PCI Passthrough
>  obj-i386-$(CONFIG_XEN_PCI_PASSTHROUGH) += host-pci-device.o
> +obj-i386-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen_pci_passthrough.o
> +obj-i386-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen_pci_passthrough_config_init.o
>  
>  # Inter-VM PCI shared memory
>  CONFIG_IVSHMEM =
> diff --git a/hw/xen_common.h b/hw/xen_common.h
> index 0409ac7..48916fd 100644
> --- a/hw/xen_common.h
> +++ b/hw/xen_common.h
> @@ -135,4 +135,7 @@ static inline int xc_fd(xc_interface *xen_xc)
>  
>  void destroy_hvm_domain(void);
>  
> +/* shutdown/destroy current domain because of an error */
> +void xen_shutdown_fatal_error(const char *fmt, ...) GCC_FMT_ATTR(1, 2);
> +
>  #endif /* QEMU_HW_XEN_COMMON_H */
> diff --git a/hw/xen_pci_passthrough.c b/hw/xen_pci_passthrough.c
> new file mode 100644
> index 0000000..998470b
> --- /dev/null
> +++ b/hw/xen_pci_passthrough.c
> @@ -0,0 +1,831 @@
> +/*
> + * Copyright (c) 2007, Neocleus Corporation.
> + * Copyright (c) 2007, Intel Corporation.
> + *
> + * This work is licensed under the terms of the GNU GPL, version 2.  See
> + * the COPYING file in the top-level directory.
> + *
> + * Alex Novik <alex@neocleus.com>
> + * Allen Kay <allen.m.kay@intel.com>
> + * Guy Zana <guy@neocleus.com>
> + *
> + * This file implements direct PCI assignment to a HVM guest
> + */
> +
> +/*
> + * Interrupt Disable policy:
> + *
> + * INTx interrupt:
> + *   Initialize(register_real_device)
> + *     Map INTx(xc_physdev_map_pirq):
> + *       <fail>
> + *         - Set real Interrupt Disable bit to '1'.
> + *         - Set machine_irq and assigned_device->machine_irq to '0'.
> + *         * Don't bind INTx.
> + *
> + *     Bind INTx(xc_domain_bind_pt_pci_irq):
> + *       <fail>
> + *         - Set real Interrupt Disable bit to '1'.
> + *         - Unmap INTx.
> + *         - Decrement mapped_machine_irq[machine_irq]
> + *         - Set assigned_device->machine_irq to '0'.
> + *
> + *   Write to Interrupt Disable bit by guest software(pt_cmd_reg_write)
> + *     Write '0'
> + *       <ptdev->msi_trans_en is false>
> + *         - Set real bit to '0' if assigned_device->machine_irq isn't '0'.
> + *
> + *     Write '1'
> + *       <ptdev->msi_trans_en is false>
> + *         - Set real bit to '1'.
> + */
> +
> +#include <sys/ioctl.h>
> +
> +#include "pci.h"
> +#include "xen.h"
> +#include "xen_backend.h"
> +#include "xen_pci_passthrough.h"
> +
> +#define PCI_BAR_ENTRIES (6)
> +
> +#define PT_NR_IRQS          (256)
> +char mapped_machine_irq[PT_NR_IRQS] = {0};


char? Can it be made uint8_t instead?
> +
> +void pt_log(const PCIDevice *d, const char *f, ...)
> +{
> +    va_list ap;
> +
> +    va_start(ap, f);
> +    if (d) {
> +        fprintf(stderr, "[%02x:%02x.%x] ", pci_bus_num(d->bus),
> +                PCI_SLOT(d->devfn), PCI_FUNC(d->devfn));
> +    }
> +    vfprintf(stderr, f, ap);
> +    va_end(ap);
> +}
> +
> +
> +/* Config Space */
> +static int pt_pci_config_access_check(PCIDevice *d, uint32_t address, int len)
> +{
> +    /* check offset range */
> +    if (address >= 0xFF) {
> +        PT_ERR(d, "Failed to access register with offset exceeding 0xFF. "
> +               "(addr: 0x%02x, len: %d)\n", address, len);
> +        return -1;
> +    }
> +
> +    /* check read size */
> +    if ((len != 1) && (len != 2) && (len != 4)) {
> +        PT_ERR(d, "Failed to access register with invalid access length. "
> +               "(addr: 0x%02x, len: %d)\n", address, len);
> +        return -1;
> +    }
> +
> +    /* check offset alignment */
> +    if (address & (len - 1)) {
> +        PT_ERR(d, "Failed to access register with invalid access size "
> +               "alignment. (addr: 0x%02x, len: %d)\n", address, len);
> +        return -1;
> +    }
> +
> +    return 0;
> +}
> +
> +int pt_bar_offset_to_index(uint32_t offset)
> +{
> +    int index = 0;
> +
> +    /* check Exp ROM BAR */
> +    if (offset == PCI_ROM_ADDRESS) {
> +        return PCI_ROM_SLOT;
> +    }
> +
> +    /* calculate BAR index */
> +    index = (offset - PCI_BASE_ADDRESS_0) >> 2;
> +    if (index >= PCI_NUM_REGIONS) {
> +        return -1;
> +    }
> +
> +    return index;
> +}
> +
> +static uint32_t pt_pci_read_config(PCIDevice *d, uint32_t address, int len)
> +{
> +    XenPCIPassthroughState *s = DO_UPCAST(XenPCIPassthroughState, dev, d);
> +    uint32_t val = 0;
> +    XenPTRegGroup *reg_grp_entry = NULL;
> +    XenPTReg *reg_entry = NULL;
> +    int rc = 0;
> +    int emul_len = 0;
> +    uint32_t find_addr = address;
> +
> +    if (pt_pci_config_access_check(d, address, len)) {
> +        goto exit;
> +    }
> +
> +    /* check power state transition flags */
> +    if (s->pm_state != NULL && s->pm_state->flags & PT_FLAG_TRANSITING) {
> +        /* can't accept until previous power state transition is completed.
> +         * so finish previous request here.

Uh, how do we finish previous request here?

> +         */
> +        PT_WARN(d, "Guest want to write during power state transition\n");
> +        goto exit;
> +    }
> +
> +    /* find register group entry */
> +    reg_grp_entry = pt_find_reg_grp(s, address);
> +    if (reg_grp_entry) {
> +        /* check 0 Hardwired register group */

So what does that mean? 0 hardwired register group? It means
that the register is always zero?

> +        if (reg_grp_entry->reg_grp->grp_type == GRP_TYPE_HARDWIRED) {
> +            /* no need to emulate, just return 0 */
> +            val = 0;
> +            goto exit;
> +        }
> +    }
> +
> +    /* read I/O device register value */
> +    rc = host_pci_get_block(s->real_device, address, (uint8_t *)&val, len);
> +    if (rc < 0) {
> +        PT_ERR(d, "pci_read_block failed. return value: %d.\n", rc);
> +        memset(&val, 0xff, len);
> +    }
> +
> +    /* just return the I/O device register value for
> +     * passthrough type register group */

Is another way to say that: "There is no filter for the
value, so just return the raw value." ?

> +    if (reg_grp_entry == NULL) {
> +        goto exit;
> +    }
> +
> +    /* adjust the read value to appropriate CFC-CFF window */
> +    val <<= (address & 3) << 3;
> +    emul_len = len;
> +
> +    /* loop around the guest requested size */
> +    while (emul_len > 0) {
> +        /* find register entry to be emulated */
> +        reg_entry = pt_find_reg(reg_grp_entry, find_addr);
> +        if (reg_entry) {
> +            XenPTRegInfo *reg = reg_entry->reg;
> +            uint32_t real_offset = reg_grp_entry->base_offset + reg->offset;
> +            uint32_t valid_mask = 0xFFFFFFFF >> ((4 - emul_len) << 3);
> +            uint8_t *ptr_val = NULL;
> +
> +            valid_mask <<= (find_addr - real_offset) << 3;
> +            ptr_val = (uint8_t *)&val + (real_offset & 3);
> +
> +            /* do emulation based on register size */
> +            switch (reg->size) {
> +            case 1:
> +                if (reg->u.b.read) {
> +                    rc = reg->u.b.read(s, reg_entry, ptr_val, valid_mask);
> +                }
> +                break;
> +            case 2:
> +                if (reg->u.w.read) {
> +                    rc = reg->u.w.read(s, reg_entry,
> +                                       (uint16_t *)ptr_val, valid_mask);
> +                }
> +                break;
> +            case 4:
> +                if (reg->u.dw.read) {
> +                    rc = reg->u.dw.read(s, reg_entry,
> +                                        (uint32_t *)ptr_val, valid_mask);
> +                }
> +                break;
> +            }
> +
> +            if (rc < 0) {
> +                xen_shutdown_fatal_error("Internal error: Invalid read "
> +                                         "emulation. (%s, rc: %d)\n",
> +                                         __func__, rc);
> +                return 0;
> +            }
> +
> +            /* calculate next address to find */
> +            emul_len -= reg->size;
> +            if (emul_len > 0) {
> +                find_addr = real_offset + reg->size;
> +            }
> +        } else {
> +            /* nothing to do with passthrough type register,
> +             * continue to find next byte */
> +            emul_len--;
> +            find_addr++;
> +        }
> +    }
> +
> +    /* need to shift back before returning them to pci bus emulator */
> +    val >>= ((address & 3) << 3);
> +
> +exit:
> +    PT_LOG_CONFIG(d, address, val, len);
> +    return val;
> +}
> +
> +static void pt_pci_write_config(PCIDevice *d, uint32_t address,
> +                                uint32_t val, int len)
> +{
> +    XenPCIPassthroughState *s = DO_UPCAST(XenPCIPassthroughState, dev, d);
> +    int index = 0;
> +    XenPTRegGroup *reg_grp_entry = NULL;
> +    int rc = 0;
> +    uint32_t read_val = 0;
> +    int emul_len = 0;
> +    XenPTReg *reg_entry = NULL;
> +    uint32_t find_addr = address;
> +    XenPTRegInfo *reg = NULL;
> +
> +    if (pt_pci_config_access_check(d, address, len)) {
> +        return;
> +    }
> +
> +    PT_LOG_CONFIG(d, address, val, len);
> +
> +    /* check unused BAR register */
> +    index = pt_bar_offset_to_index(address);
> +    if ((index >= 0) && (val > 0 && val < PT_BAR_ALLF) &&
> +        (s->bases[index].bar_flag == PT_BAR_FLAG_UNUSED)) {
> +        PT_WARN(d, "Guest attempt to set address to unused Base Address "
> +                "Register. (addr: 0x%02x, len: %d)\n", address, len);
> +    }
> +
> +    /* check power state transition flags */
> +    if (s->pm_state != NULL && s->pm_state->flags & PT_FLAG_TRANSITING) {
> +        /* can't accept until previous power state transition is completed.
> +         * so finish previous request here.

Ditto. How do we finish the previous request here?
> +         */
> +        PT_WARN(d, "Guest want to write during power state transition\n");
> +        return;
> +    }
> +
> +    /* find register group entry */
> +    reg_grp_entry = pt_find_reg_grp(s, address);
> +    if (reg_grp_entry) {
> +        /* check 0 Hardwired register group */
> +        if (reg_grp_entry->reg_grp->grp_type == GRP_TYPE_HARDWIRED) {
> +            /* ignore silently */
> +            PT_WARN(d, "Access to 0 Hardwired register. "
> +                    "(addr: 0x%02x, len: %d)\n", address, len);
> +            return;
> +        }
> +    }
> +
> +    /* read I/O device register value */
> +    rc = host_pci_get_block(s->real_device, address,
> +                             (uint8_t *)&read_val, len);
> +    if (rc < 0) {
> +        PT_ERR(d, "pci_read_block failed. return value: %d.\n", rc);
> +        memset(&read_val, 0xff, len);
> +    }
> +
> +    /* pass directly to the real device for passthrough type register group */
> +    if (reg_grp_entry == NULL) {
> +        goto out;
> +    }
> +
> +    /* adjust the read and write value to appropriate CFC-CFF window */
> +    read_val <<= (address & 3) << 3;
> +    val <<= (address & 3) << 3;
> +    emul_len = len;
> +
> +    /* loop around the guest requested size */
> +    while (emul_len > 0) {
> +        /* find register entry to be emulated */
> +        reg_entry = pt_find_reg(reg_grp_entry, find_addr);
> +        if (reg_entry) {
> +            reg = reg_entry->reg;
> +            uint32_t real_offset = reg_grp_entry->base_offset + reg->offset;
> +            uint32_t valid_mask = 0xFFFFFFFF >> ((4 - emul_len) << 3);
> +            uint8_t *ptr_val = NULL;
> +
> +            valid_mask <<= (find_addr - real_offset) << 3;
> +            ptr_val = (uint8_t *)&val + (real_offset & 3);
> +
> +            /* do emulation based on register size */
> +            switch (reg->size) {
> +            case 1:
> +                if (reg->u.b.write) {
> +                    rc = reg->u.b.write(s, reg_entry, ptr_val,
> +                                        read_val >> ((real_offset & 3) << 3),
> +                                        valid_mask);
> +                }
> +                break;
> +            case 2:
> +                if (reg->u.w.write) {
> +                    rc = reg->u.w.write(s, reg_entry, (uint16_t *)ptr_val,
> +                                        (read_val >> ((real_offset & 3) << 3)),
> +                                        valid_mask);
> +                }
> +                break;
> +            case 4:
> +                if (reg->u.dw.write) {
> +                    rc = reg->u.dw.write(s, reg_entry, (uint32_t *)ptr_val,
> +                                         (read_val >> ((real_offset & 3) << 3)),
> +                                         valid_mask);
> +                }
> +                break;
> +            }
> +
> +            if (rc < 0) {
> +                xen_shutdown_fatal_error("Internal error: Invalid write"
> +                                         " emulation. (%s, rc: %d)\n",
> +                                         __func__, rc);
> +                return;
> +            }
> +
> +            /* calculate next address to find */
> +            emul_len -= reg->size;
> +            if (emul_len > 0) {
> +                find_addr = real_offset + reg->size;
> +            }
> +        } else {
> +            /* nothing to do with passthrough type register,
> +             * continue to find next byte */
> +            emul_len--;
> +            find_addr++;
> +        }
> +    }
> +
> +    /* need to shift back before passing them to host_pci_device */
> +    val >>= (address & 3) << 3;
> +
> +out:
> +    if (!(reg && reg->no_wb)) {
> +        /* unknown regs are passed through */
> +        rc = host_pci_set_block(s->real_device, address, (uint8_t *)&val, len);
> +
> +        if (rc < 0) {
> +            PT_ERR(d, "pci_write_block failed. return value: %d.\n", rc);
> +        }
> +    }
> +}
> +
> +/* ioport/iomem space*/
> +static void pt_iomem_map(XenPCIPassthroughState *s, int i,
> +                         pcibus_t e_phys, pcibus_t e_size, int type)
> +{
> +    PCIIORegion *r = &s->dev.io_regions[i];
> +    uint32_t old_ebase = s->bases[i].e_physbase;
> +    bool first_map = s->bases[i].e_size == 0;
> +    int ret = 0;
> +
> +    s->bases[i].e_physbase = e_phys;
> +    s->bases[i].e_size = e_size;
> +
> +    PT_LOG(&s->dev, "e_phys=%#"PRIx64" maddr=%#"PRIx64" type=%d"
> +           " len=%#"PRIx64" index=%d first_map=%d\n",
> +           e_phys, s->bases[i].access.maddr, type,
> +           e_size, i, first_map);
> +
> +    if (e_size == 0) {
> +        return;
> +    }
> +
> +    if (!first_map && old_ebase != PT_PCI_BAR_UNMAPPED) {
> +        /* Remove old mapping */
> +        memory_region_del_subregion(r->address_space,
> +                                    r->memory);
> +        ret = xc_domain_memory_mapping(xen_xc, xen_domid,
> +                               old_ebase >> XC_PAGE_SHIFT,
> +                               s->bases[i].access.maddr >> XC_PAGE_SHIFT,
> +                               (e_size + XC_PAGE_SIZE - 1) >> XC_PAGE_SHIFT,
> +                               DPCI_REMOVE_MAPPING);
> +        if (ret != 0) {
> +            PT_ERR(&s->dev, "remove old mapping failed!\n");
> +            return;
> +        }
> +    }
> +
> +    /* map only valid guest address */
> +    if (e_phys != PCI_BAR_UNMAPPED) {
> +        /* Create new mapping */
> +        memory_region_add_subregion_overlap(r->address_space,
> +                                            e_phys, r->memory, 1);
> +        ret = xc_domain_memory_mapping(xen_xc, xen_domid,
> +                                   s->bases[i].e_physbase >> XC_PAGE_SHIFT,
> +                                   s->bases[i].access.maddr >> XC_PAGE_SHIFT,
> +                                   (e_size+XC_PAGE_SIZE-1) >> XC_PAGE_SHIFT,
> +                                   DPCI_ADD_MAPPING);
> +
> +        if (ret != 0) {
> +            PT_ERR(&s->dev, "create new mapping failed!\n");
> +        }
> +    }
> +}
> +
> +static void pt_ioport_map(XenPCIPassthroughState *s, int i,
> +                          pcibus_t e_phys, pcibus_t e_size, int type)
> +{
> +    PCIIORegion *r = &s->dev.io_regions[i];
> +    uint32_t old_ebase = s->bases[i].e_physbase;
> +    bool first_map = s->bases[i].e_size == 0;
> +    int ret = 0;
> +
> +    s->bases[i].e_physbase = e_phys;
> +    s->bases[i].e_size = e_size;
> +
> +    PT_LOG(&s->dev, "e_phys=%#04"PRIx64" pio_base=%#04"PRIx64" len=%"PRId64
> +           " index=%d first_map=%d\n",
> +           e_phys, s->bases[i].access.pio_base, e_size, i, first_map);
> +
> +    if (e_size == 0) {
> +        return;
> +    }
> +
> +    if (!first_map && old_ebase != PT_PCI_BAR_UNMAPPED) {
> +        /* Remove old mapping */
> +        memory_region_del_subregion(r->address_space,
> +                                    r->memory);
> +        ret = xc_domain_ioport_mapping(xen_xc, xen_domid, old_ebase,
> +                                       s->bases[i].access.pio_base, e_size,
> +                                       DPCI_REMOVE_MAPPING);
> +        if (ret != 0) {
> +            PT_ERR(&s->dev, "remove old mapping failed!\n");
> +            return;
> +        }
> +    }
> +
> +    /* map only valid guest address (include 0) */
> +    if (e_phys != PCI_BAR_UNMAPPED) {
> +        /* Create new mapping */
> +        memory_region_add_subregion_overlap(r->address_space,
> +                                            e_phys, r->memory, 1);
> +        ret = xc_domain_ioport_mapping(xen_xc, xen_domid, e_phys,
> +                                       s->bases[i].access.pio_base, e_size,
> +                                       DPCI_ADD_MAPPING);
> +        if (ret != 0) {
> +            PT_ERR(&s->dev, "create new mapping failed!\n");
> +        }
> +    }
> +
> +}
> +
> +
> +/* mapping BAR */
> +
> +void pt_bar_mapping_one(XenPCIPassthroughState *s, int bar,
> +                        int io_enable, int mem_enable)
> +{
> +    PCIDevice *dev = &s->dev;
> +    PCIIORegion *r;
> +    XenPTRegGroup *reg_grp_entry = NULL;
> +    XenPTReg *reg_entry = NULL;
> +    XenPTRegion *base = NULL;
> +    pcibus_t r_size = 0, r_addr = PCI_BAR_UNMAPPED;
> +    int rc = 0;
> +
> +    r = &dev->io_regions[bar];
> +
> +    /* check valid region */
> +    if (!r->size) {
> +        return;
> +    }
> +
> +    base = &s->bases[bar];
> +    /* skip unused BAR or upper 64bit BAR */
> +    if ((base->bar_flag == PT_BAR_FLAG_UNUSED)
> +        || (base->bar_flag == PT_BAR_FLAG_UPPER)) {
> +           return;
> +    }
> +
> +    /* copy region address to temporary */
> +    r_addr = r->addr;
> +
> +    /* need unmapping in case I/O Space or Memory Space disable */

.. is disabled.

> +    if (((base->bar_flag == PT_BAR_FLAG_IO) && !io_enable) ||
> +        ((base->bar_flag == PT_BAR_FLAG_MEM) && !mem_enable)) {
> +        r_addr = PCI_BAR_UNMAPPED;
> +    }

Add a comment saying:
	/* or ROM address is disabled. */
> +    if ((bar == PCI_ROM_SLOT) && (r_addr != PCI_BAR_UNMAPPED)) {
> +        reg_grp_entry = pt_find_reg_grp(s, PCI_ROM_ADDRESS);
> +        if (reg_grp_entry) {
> +            reg_entry = pt_find_reg(reg_grp_entry, PCI_ROM_ADDRESS);
> +            if (reg_entry && !(reg_entry->data & PCI_ROM_ADDRESS_ENABLE)) {
> +                r_addr = PCI_BAR_UNMAPPED;
> +            }
> +        }
> +    }
> +
> +    /* prevent guest software mapping memory resource to 00000000h */
> +    if ((base->bar_flag == PT_BAR_FLAG_MEM) && (r_addr == 0)) {
> +        r_addr = PCI_BAR_UNMAPPED;
> +    }
> +
> +    r_size = pt_get_emul_size(base->bar_flag, r->size);
> +
> +    rc = pci_check_bar_overlap(dev, r_addr, r_size, r->type);
> +    if (rc) {
> +        PT_WARN(dev, "Region: %d (addr: %#"FMT_PCIBUS
> +                ", len: %#"FMT_PCIBUS") is overlapped.\n",

Is the FMT_PCIBUS for len correct?

> +                bar, r_addr, r_size);
> +    }
> +
> +    /* check whether we need to update the mapping or not */
> +    if (r_addr != s->bases[bar].e_physbase) {
> +        /* mapping BAR */
> +        if (base->bar_flag == PT_BAR_FLAG_IO) {
> +            pt_ioport_map(s, bar, r_addr, r_size, r->type);
> +        } else {
> +            pt_iomem_map(s, bar, r_addr, r_size, r->type);
> +        }
> +    }
> +}
> +
> +void pt_bar_mapping(XenPCIPassthroughState *s, int io_enable, int mem_enable)
> +{
> +    int i;
> +
> +    for (i = 0; i < PCI_NUM_REGIONS; i++) {
> +        pt_bar_mapping_one(s, i, io_enable, mem_enable);
> +    }
> +}
> +
> +static uint64_t bar_read(void *o, target_phys_addr_t addr, unsigned size)
> +{
> +    PCIDevice *d = o;
> +    PT_ERR(d, "Should not read BAR through QEMU. @0x"TARGET_FMT_plx"\n", addr);


Perhaps you can add a comment of how it should read it? Is the reading
trapped by the hypervisor? If so, you might want to include a comment
stating that, maybe even the name of the file to look in.

> +    return 0;
> +}
> +static void bar_write(void *o, target_phys_addr_t addr,
> +                      uint64_t data, unsigned size)
> +{
> +    PCIDevice* d = o;
> +    PT_ERR(d, "Should not write BAR through QEMU. @0x"TARGET_FMT_plx"\n", addr);
> +}
> +
> +static const MemoryRegionOps ops = {
> +    .endianness = DEVICE_NATIVE_ENDIAN,
> +    .read = bar_read,
> +    .write = bar_write,
> +};
> +
> +/* register regions */
> +static int pt_register_regions(XenPCIPassthroughState *s)
> +{
> +    int i = 0;
> +    uint32_t bar_data = 0;
> +    HostPCIDevice *d = s->real_device;
> +
> +    /* Register PIO/MMIO BARs */
> +    for (i = 0; i < PCI_BAR_ENTRIES; i++) {
> +        HostPCIIORegion *r = &d->io_regions[i];
> +
> +        if (r->base_addr && r->size) {
> +            s->bases[i].e_physbase = r->base_addr;
> +            s->bases[i].access.u = r->base_addr;
> +
> +            /* Register current region */
> +            if (r->flags & IORESOURCE_IO) {
> +                memory_region_init_io(&s->bar[i], &ops, &s->dev,
> +                                      "xen-pci-pt-bar-io", r->size);
> +                pci_register_bar(&s->dev, i, PCI_BASE_ADDRESS_SPACE_IO,
> +                                 &s->bar[i]);
> +            } else if (r->flags & IORESOURCE_PREFETCH) {
> +                memory_region_init_io(&s->bar[i], &ops, &s->dev,
> +                                      "xen-pci-pt-bar-mem", r->size);
> +                pci_register_bar(&s->dev, i, PCI_BASE_ADDRESS_MEM_PREFETCH,
> +                                 &s->bar[i]);
> +            } else {
> +                memory_region_init_io(&s->bar[i], &ops, &s->dev,
> +                                      "xen-pci-pt-bar-mem", r->size);
> +                pci_register_bar(&s->dev, i, PCI_BASE_ADDRESS_SPACE_MEMORY,
> +                                 &s->bar[i]);
> +            }
> +
> +            PT_LOG(&s->dev, "IO region registered (size=0x%08"PRIx64
> +                   " base_addr=0x%08"PRIx64")\n",
> +                   r->size, r->base_addr);
> +        }
> +    }
> +
> +    /* Register expansion ROM address */
> +    if (d->rom.base_addr && d->rom.size) {
> +        /* Re-set BAR reported by OS, otherwise ROM can't be read. */
> +        if (host_pci_get_long(d, PCI_ROM_ADDRESS, &bar_data)) {
> +            return 0;
> +        }
> +        if ((bar_data & PCI_ROM_ADDRESS_MASK) == 0) {
> +            bar_data |= d->rom.base_addr & PCI_ROM_ADDRESS_MASK;
> +            host_pci_set_long(d, PCI_ROM_ADDRESS, bar_data);
> +        }
> +
> +        s->bases[PCI_ROM_SLOT].e_physbase = d->rom.base_addr;
> +        s->bases[PCI_ROM_SLOT].access.maddr = d->rom.base_addr;
> +
> +        memory_region_init_rom_device(&s->rom, NULL, NULL, &s->dev.qdev,
> +                                      "xen-pci-pt-rom", d->rom.size);
> +        pci_register_bar(&s->dev, PCI_ROM_SLOT, PCI_BASE_ADDRESS_MEM_PREFETCH,
> +                         &s->rom);
> +
> +        PT_LOG(&s->dev, "Expansion ROM registered (size=0x%08"PRIx64
> +               " base_addr=0x%08"PRIx64")\n",
> +               d->rom.size, d->rom.base_addr);
> +    }
> +
> +    return 0;
> +}
> +
> +static void pt_unregister_regions(XenPCIPassthroughState *s)
> +{
> +    int i, type, rc;
> +    uint32_t e_size;
> +    PCIDevice *d = &s->dev;
> +
> +    for (i = 0; i < PCI_NUM_REGIONS; i++) {
> +        e_size = s->bases[i].e_size;
> +        if ((e_size == 0) || (s->bases[i].e_physbase == PT_PCI_BAR_UNMAPPED)) {
> +            continue;
> +        }
> +
> +        type = d->io_regions[i].type;
> +
> +        if (type == PCI_BASE_ADDRESS_SPACE_MEMORY
> +            || type == PCI_BASE_ADDRESS_MEM_PREFETCH) {
> +            rc = xc_domain_memory_mapping(xen_xc, xen_domid,
> +                    s->bases[i].e_physbase >> XC_PAGE_SHIFT,
> +                    s->bases[i].access.maddr >> XC_PAGE_SHIFT,
> +                    (e_size+XC_PAGE_SIZE-1) >> XC_PAGE_SHIFT,
> +                    DPCI_REMOVE_MAPPING);
> +            if (rc != 0) {
> +                PT_ERR(d, "remove old mem mapping failed!\n");
> +                continue;
> +            }
> +
> +        } else if (type == PCI_BASE_ADDRESS_SPACE_IO) {
> +            rc = xc_domain_ioport_mapping(xen_xc, xen_domid,
> +                        s->bases[i].e_physbase,
> +                        s->bases[i].access.pio_base,
> +                        e_size,
> +                        DPCI_REMOVE_MAPPING);
> +            if (rc != 0) {
> +                PT_ERR(d, "remove old io mapping failed!\n");
> +                continue;
> +            }
> +        }
> +    }
> +}
> +
> +static int pt_initfn(PCIDevice *pcidev)
> +{
> +    XenPCIPassthroughState *s = DO_UPCAST(XenPCIPassthroughState, dev, pcidev);
> +    int dom, bus;
> +    unsigned slot, func;

So how come bus is 'int' but slot and func are unsigned?

> +    int rc = 0;
> +    uint8_t machine_irq = 0;
> +    int pirq = PT_UNASSIGNED_PIRQ;
> +
> +    if (pci_parse_devaddr(s->hostaddr, &dom, &bus, &slot, &func) < 0) {
> +        PT_ERR(pcidev, "Failed to parse BDF: %s\n", s->hostaddr);
> +        return -1;
> +    }
> +
> +    /* register real device */
> +    PT_LOG(pcidev, "Assigning real physical device %02x:%02x.%x"
> +           " to devfn %#x\n", bus, slot, func, s->dev.devfn);
> +
> +    s->real_device = host_pci_device_get(bus, slot, func);
> +    if (!s->real_device) {
> +        return -1;
> +    }
> +
> +    s->is_virtfn = s->real_device->is_virtfn;
> +    if (s->is_virtfn) {
> +        PT_LOG(pcidev, "%04x:%02x:%02x.%x is a SR-IOV Virtual Function\n",
> +               s->real_device->domain, bus, slot, func);
> +    }
> +
> +    /* Initialize virtualized PCI configuration (Extended 256 Bytes) */
> +    if (host_pci_get_block(s->real_device, 0, pcidev->config,
> +                           PCI_CONFIG_SPACE_SIZE) == -1) {
> +        host_pci_device_put(s->real_device);
> +        return -1;
> +    }
> +
> +    /* Handle real device's MMIO/PIO BARs */
> +    pt_register_regions(s);
> +
> +    /* Bind interrupt */
> +    if (!s->dev.config[PCI_INTERRUPT_PIN]) {

Is a 'zero' value correct? I think that is the value that
SR-IOV devices export since they don't have legacy IRQs?
Or maybe they export the MSI vector values instead.

Perhaps you should do
    if (!s->dev.config[PCI_INTERRUPT_PIN] && !s->is_virtfn) {

> +        PT_LOG(pcidev, "no pin interrupt\n");
> +        goto out;
> +    }
> +
> +    host_pci_get_byte(s->real_device, PCI_INTERRUPT_LINE, &machine_irq);

Just to double check:

> lspci -s 01:10.0 -v -xx
01:10.0 Ethernet controller: Intel Corporation 82576 Virtual Function
(rev 01)
	Subsystem: Intel Corporation Device a01c
	Flags: bus master, fast devsel, latency 0
	[virtual] Memory at b8840000 (64-bit, non-prefetchable) [size=16K]
	[virtual] Memory at b8860000 (64-bit, non-prefetchable) [size=16K]
	Capabilities: [70] MSI-X: Enable+ Count=3 Masked-
	Capabilities: [a0] Express Endpoint, MSI 00
	Capabilities: [100] Advanced Error Reporting
	Capabilities: [150] Alternative Routing-ID Interpretation (ARI)
	Kernel driver in use: igbvf
	Kernel modules: igbvf
00: ff ff ff ff 04 00 10 00 01 00 00 02 00 00 00 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 86 80 1c a0
30: 00 00 00 00 70 00 00 00 00 00 00 00 00 00 00 00

And a normal USB device:

>  lspci -s 00:1a.0 -v -xx 
00:1a.0 USB Controller: Intel Corporation 82801JI (ICH10 Family) USB
UHCI Controller #4 (prog-if 00 [UHCI])
	Subsystem: Intel Corporation Device 4f53
	Flags: bus master, medium devsel, latency 0, IRQ 16
	I/O ports at 40e0 [size=32]
	Capabilities: [50] PCI Advanced Features
	Kernel driver in use: uhci_hcd
00: 86 80 37 3a 05 00 90 02 00 00 03 0c 00 00 80 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: e1 40 00 00 00 00 00 00 00 00 00 00 86 80 53 4f
30: 00 00 00 00 50 00 00 00 00 00 00 00 0b 01 00 00

The USB device has interrupt line 0xB, and pin 1.
The SR-IOV one is zero and zero.

> +    rc = xc_physdev_map_pirq(xen_xc, xen_domid, machine_irq, &pirq);

so perhaps this should be guarded by a check against devices that
have no legacy IRQs, like SR-VIO? Perhaps check against is_virtfn?

> +
> +    if (rc < 0) {
> +        PT_ERR(pcidev, "Mapping machine irq %u to pirq %i failed, (rc: %d)\n",
> +               machine_irq, pirq, rc);
> +
> +        /* Disable PCI intx assertion (turn on bit10 of devctl) */
> +        host_pci_set_word(s->real_device,
> +                          PCI_COMMAND,
> +                          pci_get_word(s->dev.config + PCI_COMMAND)
> +                          | PCI_COMMAND_INTX_DISABLE);
> +        machine_irq = 0;
> +        s->machine_irq = 0;
> +    } else {
> +        machine_irq = pirq;
> +        s->machine_irq = pirq;
> +        mapped_machine_irq[machine_irq]++;
> +    }
> +
> +    /* bind machine_irq to device */
> +    if (rc < 0 && machine_irq != 0) {
> +        uint8_t e_device = PCI_SLOT(s->dev.devfn);
> +        uint8_t e_intx = pci_intx(s);
> +
> +        rc = xc_domain_bind_pt_pci_irq(xen_xc, xen_domid, machine_irq, 0,

What is the zero at the end for? Should it have a comment?

> +                                       e_device, e_intx);
> +        if (rc < 0) {
> +            PT_ERR(pcidev, "Binding of interrupt %i failed! (rc: %d)\n",
> +                   e_intx, rc);
> +
> +            /* Disable PCI intx assertion (turn on bit10 of devctl) */
> +            host_pci_set_word(s->real_device, PCI_COMMAND,
> +                              *(uint16_t *)(&s->dev.config[PCI_COMMAND])
> +                              | PCI_COMMAND_INTX_DISABLE);
> +            mapped_machine_irq[machine_irq]--;

Is this code reentrant? What if the user wants to pass in two USB
devices where both of them share the same IRQ. And it so happens that we
fail (perhaps the device is owned by another guest). We get here, and
both of them decrement the mapped_machine_irq.. which means that
> +
> +            if (mapped_machine_irq[machine_irq] == 0) {

this might not be executed (as both of them read it as =1).?
> +                if (xc_physdev_unmap_pirq(xen_xc, xen_domid, machine_irq)) {
> +                    PT_ERR(pcidev, "Unmapping of machine interrupt %i failed!"
> +                           " (rc: %d)\n", machine_irq, rc);

Or is the code actually single-threaded so there is no danger of this?

> +                }
> +            }
> +            s->machine_irq = 0;
> +        }
> +    }
> +
> +out:
> +    PT_LOG(pcidev, "Real physical device %02x:%02x.%x registered successfuly!"
> +           "\nIRQ type = %s\n", bus, slot, func, "INTx");
> +
> +    return 0;
> +}
> +
> +static int pt_unregister_device(PCIDevice *pcidev)
> +{
> +    XenPCIPassthroughState *s = DO_UPCAST(XenPCIPassthroughState, dev, pcidev);
> +    uint8_t e_device, e_intx;
> +    uint8_t machine_irq;
> +    int rc;
> +
> +    /* Unbind interrupt */
> +    e_device = PCI_SLOT(s->dev.devfn);
> +    e_intx = pci_intx(s);
> +    machine_irq = s->machine_irq;
> +
> +    if (machine_irq) {
> +        rc = xc_domain_unbind_pt_irq(xen_xc, xen_domid, machine_irq,
> +                                     PT_IRQ_TYPE_PCI, 0, e_device, e_intx, 0);

What are the two '0' for?
Can you provide a comment within the arguments?

> +        if (rc < 0) {
> +            PT_ERR(pcidev, "Unbinding of interrupt failed! rc=%d\n", rc);

Might want to mention which interrupt (or pirq?) failed.

> +        }
> +    }
> +
> +    if (machine_irq) {

Why not continue the logic within this code? As in why
the 'if (machine_irq)' here? You would still continue going
even if xc_domain_unbind_pt_irq failed..

> +        mapped_machine_irq[machine_irq]--;
> +
> +        if (mapped_machine_irq[machine_irq] == 0) {
> +            rc = xc_physdev_unmap_pirq(xen_xc, xen_domid, machine_irq);
> +
> +            if (rc < 0) {
> +                PT_ERR(pcidev, "Unmaping of interrupt failed! rc=%d\n", rc);

And provide the interrupt (both the pirq and linux one).

You might want to mention in the erorr logs: "But bravely continuing on.."
> +            }
> +        }
> +    }
> +
> +    /* unregister real device's MMIO/PIO BARs */
> +    pt_unregister_regions(s);
> +
> +    host_pci_device_put(s->real_device);
> +
> +    return 0;
> +}
> +
> +static PCIDeviceInfo xen_pci_passthrough = {
> +    .init = pt_initfn,
> +    .exit = pt_unregister_device,
> +    .qdev.name = "xen-pci-passthrough",
> +    .qdev.desc = "Assign an host pci device with Xen",
> +    .qdev.size = sizeof(XenPCIPassthroughState),
> +    .config_read = pt_pci_read_config,
> +    .config_write = pt_pci_write_config,
> +    .is_express = 0,
> +    .qdev.props = (Property[]) {
> +        DEFINE_PROP_STRING("hostaddr", XenPCIPassthroughState, hostaddr),
> +        DEFINE_PROP_BIT("power-mgmt", XenPCIPassthroughState, power_mgmt,
> +                        0, false),
> +        DEFINE_PROP_END_OF_LIST(),
> +    }
> +};
> +
> +static void xen_passthrough_register(void)
> +{
> +    pci_qdev_register(&xen_pci_passthrough);
> +}
> +
> +device_init(xen_passthrough_register);
> diff --git a/hw/xen_pci_passthrough.h b/hw/xen_pci_passthrough.h
> new file mode 100644
> index 0000000..110325c
> --- /dev/null
> +++ b/hw/xen_pci_passthrough.h
> @@ -0,0 +1,282 @@
> +#ifndef QEMU_HW_XEN_PCI_PASSTHROUGH_H
> +#  define QEMU_HW_XEN_PCI_PASSTHROUGH_H
> +
> +#include "qemu-common.h"
> +#include "xen_common.h"
> +#include "pci.h"
> +#include "host-pci-device.h"
> +
> +/* #define PT_LOGGING_ENABLED */
> +/* #define PT_DEBUG_PCI_CONFIG_ACCESS */
> +
> +void pt_log(const PCIDevice *d, const char *f, ...) GCC_FMT_ATTR(2, 3);
> +
> +#define PT_ERR(d, _f, _a...)  pt_log(d, "%s: Error: " _f, __func__, ##_a)
> +
> +#ifdef PT_LOGGING_ENABLED
> +#  define PT_LOG(d, _f, _a...)  pt_log(d, "%s: " _f, __func__, ##_a)
> +#  define PT_WARN(d, _f, _a...) pt_log(d, "%s: Warning: " _f, __func__, ##_a)
> +#else
> +#  define PT_LOG(d, _f, _a...)
> +#  define PT_WARN(d, _f, _a...)
> +#endif
> +
> +#ifdef PT_DEBUG_PCI_CONFIG_ACCESS
> +#  define PT_LOG_CONFIG(d, addr, val, len) \
> +    pt_log(d, "%s: address=0x%04x val=0x%08x len=%d\n", \
> +           __func__, addr, val, len)
> +#else
> +#  define PT_LOG_CONFIG(d, addr, val, len)
> +#endif


Nice. Thanks!

> +
> +
> +typedef struct XenPTRegInfo XenPTRegInfo;
> +typedef struct XenPTReg XenPTReg;
> +
> +typedef struct XenPCIPassthroughState XenPCIPassthroughState;
> +
> +/* function type for config reg */
> +typedef int (*conf_reg_init)
> +    (XenPCIPassthroughState *, XenPTRegInfo *, uint32_t real_offset,
> +     uint32_t *data);
> +typedef int (*conf_dword_write)
> +    (XenPCIPassthroughState *, XenPTReg *cfg_entry,
> +     uint32_t *val, uint32_t dev_value, uint32_t valid_mask);
> +typedef int (*conf_word_write)
> +    (XenPCIPassthroughState *, XenPTReg *cfg_entry,
> +     uint16_t *val, uint16_t dev_value, uint16_t valid_mask);
> +typedef int (*conf_byte_write)
> +    (XenPCIPassthroughState *, XenPTReg *cfg_entry,
> +     uint8_t *val, uint8_t dev_value, uint8_t valid_mask);
> +typedef int (*conf_dword_read)
> +    (XenPCIPassthroughState *, XenPTReg *cfg_entry,
> +     uint32_t *val, uint32_t valid_mask);
> +typedef int (*conf_word_read)
> +    (XenPCIPassthroughState *, XenPTReg *cfg_entry,
> +     uint16_t *val, uint16_t valid_mask);
> +typedef int (*conf_byte_read)
> +    (XenPCIPassthroughState *, XenPTReg *cfg_entry,
> +     uint8_t *val, uint8_t valid_mask);
> +typedef int (*conf_dword_restore)
> +    (XenPCIPassthroughState *, XenPTReg *cfg_entry, uint32_t real_offset,
> +     uint32_t dev_value, uint32_t *val);
> +typedef int (*conf_word_restore)
> +    (XenPCIPassthroughState *, XenPTReg *cfg_entry, uint32_t real_offset,
> +     uint16_t dev_value, uint16_t *val);
> +typedef int (*conf_byte_restore)
> +    (XenPCIPassthroughState *, XenPTReg *cfg_entry, uint32_t real_offset,
> +     uint8_t dev_value, uint8_t *val);
> +
> +/* power state transition */
> +#define PT_FLAG_TRANSITING  0x0001
> +
> +#define PT_BAR_ALLF         0xFFFFFFFF  /* BAR ALLF value */
> +#define PT_PCI_BAR_UNMAPPED (-1)
> +#define PT_UNASSIGNED_PIRQ (-1)
> +
> +
> +typedef enum {
> +    GRP_TYPE_HARDWIRED = 0,                     /* 0 Hardwired reg group */
> +    GRP_TYPE_EMU,                               /* emul reg group */
> +} RegisterGroupType;
> +
> +typedef enum {
> +    PT_BAR_FLAG_MEM = 0,                        /* Memory type BAR */
> +    PT_BAR_FLAG_IO,                             /* I/O type BAR */
> +    PT_BAR_FLAG_UPPER,                          /* upper 64bit BAR */
> +    PT_BAR_FLAG_UNUSED,                         /* unused BAR */
> +} PTBarFlag;
> +
> +
> +typedef struct XenPTRegion {
> +    /* Virtual phys base & size */
> +    uint32_t e_physbase;
> +    uint32_t e_size;
> +    /* Index of region in qemu */
> +    uint32_t memory_index;
> +    /* BAR flag */
> +    PTBarFlag bar_flag;
> +    /* Translation of the emulated address */
> +    union {
> +        uint64_t maddr;
> +        uint64_t pio_base;
> +        uint64_t u;
> +    } access;
> +} XenPTRegion;
> +
> +/* XenPTRegInfo declaration
> + * - only for emulated register (either a part or whole bit).
> + * - for passthrough register that need special behavior (like interacting with
> + *   other component), set emu_mask to all 0 and specify r/w func properly.
> + * - do NOT use ALL F for init_val, otherwise the tbl will not be registered.
> + */
> +
> +/* emulated register infomation */
> +struct XenPTRegInfo {
> +    uint32_t offset;
> +    uint32_t size;
> +    uint32_t init_val;
> +    /* reg read only field mask (ON:RO/ROS, OFF:other) */
> +    uint32_t ro_mask;
> +    /* reg emulate field mask (ON:emu, OFF:passthrough) */
> +    uint32_t emu_mask;
> +    /* no write back allowed */
> +    uint32_t no_wb;
> +    conf_reg_init init;
> +    /* read/write/restore function pointer
> +     * for double_word/word/byte size */
> +    union {
> +        struct {
> +            conf_dword_write write;
> +            conf_dword_read read;
> +            conf_dword_restore restore;
> +        } dw;
> +        struct {
> +            conf_word_write write;
> +            conf_word_read read;
> +            conf_word_restore restore;
> +        } w;
> +        struct {
> +            conf_byte_write write;
> +            conf_byte_read read;
> +            conf_byte_restore restore;
> +        } b;
> +    } u;
> +};
> +
> +/* emulated register management */
> +struct XenPTReg {
> +    QLIST_ENTRY(XenPTReg) entries;
> +    XenPTRegInfo *reg;
> +    uint32_t data;
> +};
> +
> +typedef struct XenPTRegGroupInfo XenPTRegGroupInfo;
> +
> +/* emul reg group size initialize method */
> +typedef int (*pt_reg_size_init_fn)
> +    (XenPCIPassthroughState *, const XenPTRegGroupInfo *,
> +     uint32_t base_offset, uint8_t *size);
> +
> +/* emulated register group infomation */
> +struct XenPTRegGroupInfo {
> +    uint8_t grp_id;
> +    RegisterGroupType grp_type;
> +    uint8_t grp_size;
> +    pt_reg_size_init_fn size_init;
> +    XenPTRegInfo *emu_reg_tbl;
> +};
> +
> +/* emul register group management table */
> +typedef struct XenPTRegGroup {
> +    QLIST_ENTRY(XenPTRegGroup) entries;
> +    const XenPTRegGroupInfo *reg_grp;
> +    uint32_t base_offset;
> +    uint8_t size;
> +    QLIST_HEAD(, XenPTReg) reg_tbl_list;
> +} XenPTRegGroup;
> +
> +
> +typedef struct XenPTPM {
> +    QEMUTimer *pm_timer;  /* QEMUTimer struct */
> +    int no_soft_reset;    /* No Soft Reset flags */
> +    uint16_t flags;       /* power state transition flags */
> +    uint16_t pmc_field;   /* Power Management Capabilities field */
> +    int pm_delay;         /* power state transition delay */
> +    uint16_t cur_state;   /* current power state */
> +    uint16_t req_state;   /* requested power state */
> +    uint32_t pm_base;     /* Power Management Capability reg base offset */
> +    uint32_t aer_base;    /* AER Capability reg base offset */
> +} XenPTPM;
> +
> +struct XenPCIPassthroughState {
> +    PCIDevice dev;
> +
> +    char *hostaddr;
> +    bool is_virtfn;
> +    HostPCIDevice *real_device;
> +    XenPTRegion bases[PCI_NUM_REGIONS]; /* Access regions */
> +    QLIST_HEAD(, XenPTRegGroup) reg_grp_tbl;
> +
> +    uint32_t machine_irq;
> +
> +    uint32_t power_mgmt;
> +    XenPTPM *pm_state;
> +
> +    MemoryRegion bar[PCI_NUM_REGIONS - 1];
> +    MemoryRegion rom;
> +};
> +
> +int pt_config_init(XenPCIPassthroughState *s);
> +void pt_config_delete(XenPCIPassthroughState *s);
> +void pt_bar_mapping(XenPCIPassthroughState *s, int io_enable, int mem_enable);
> +void pt_bar_mapping_one(XenPCIPassthroughState *s, int bar,
> +                        int io_enable, int mem_enable);
> +XenPTRegGroup *pt_find_reg_grp(XenPCIPassthroughState *s, uint32_t address);
> +XenPTReg *pt_find_reg(XenPTRegGroup *reg_grp, uint32_t address);
> +int pt_bar_offset_to_index(uint32_t offset);
> +
> +static inline pcibus_t pt_get_emul_size(PTBarFlag flag, pcibus_t r_size)
> +{
> +    /* align resource size (memory type only) */
> +    if (flag == PT_BAR_FLAG_MEM) {
> +        return (r_size + XC_PAGE_SIZE - 1) & XC_PAGE_MASK;
> +    } else {
> +        return r_size;
> +    }
> +}
> +
> +/* INTx */
> +/* The PCI Local Bus Specification, Rev. 3.0,
> + * Section 6.2.4 Miscellaneous Registers, pp 223
> + * outlines 5 valid values for the intertupt pin (intx).
> + *  0: For devices (or device functions) that don't use an interrupt in
> + *  1: INTA#
> + *  2: INTB#
> + *  3: INTC#
> + *  4: INTD#
> + *
> + * Xen uses the following 4 values for intx
> + *  0: INTA#
> + *  1: INTB#
> + *  2: INTC#
> + *  3: INTD#
> + *
> + * Observing that these list of values are not the same, pci_read_intx()
> + * uses the following mapping from hw to xen values.

Might want to add : "(from /sys/../config contents)."
> + * This seems to reflect the current usage within Xen.
> + *
> + * PCI hardware    | Xen | Notes
> + * ----------------+-----+----------------------------------------------------
> + * 0               | 0   | No interrupt
> + * 1               | 0   | INTA#
> + * 2               | 1   | INTB#
> + * 3               | 2   | INTC#
> + * 4               | 3   | INTD#
> + * any other value | 0   | This should never happen, log error message
> + */
> +
> +static inline uint8_t pci_read_intx(XenPCIPassthroughState *s)
> +{
> +    uint8_t v = 0;
> +    host_pci_get_byte(s->real_device, PCI_INTERRUPT_PIN, &v);
> +    return v;
> +}
> +
> +static inline uint8_t pci_intx(XenPCIPassthroughState *s)
> +{
> +    uint8_t r_val = pci_read_intx(s);
> +
> +    PT_LOG(&s->dev, "intx=%i\n", r_val);
> +    if (r_val < 1 || r_val > 4) {
> +        PT_LOG(&s->dev, "Interrupt pin read from hardware is out of range:"
> +               " value=%i, acceptable range is 1 - 4\n", r_val);
> +        r_val = 0;
> +    } else {
> +        r_val -= 1;
> +    }
> +
> +    return r_val;
> +}
> +
> +#endif /* !QEMU_HW_XEN_PCI_PASSTHROUGH_H */
> diff --git a/hw/xen_pci_passthrough_config_init.c b/hw/xen_pci_passthrough_config_init.c
> new file mode 100644
> index 0000000..1e9de64
> --- /dev/null
> +++ b/hw/xen_pci_passthrough_config_init.c
> @@ -0,0 +1,11 @@
> +#include "xen_pci_passthrough.h"
> +
> +XenPTRegGroup *pt_find_reg_grp(XenPCIPassthroughState *s, uint32_t address)
> +{
> +    return NULL;
> +}
> +
> +XenPTReg *pt_find_reg(XenPTRegGroup *reg_grp, uint32_t address)
> +{
> +    return NULL;
> +}
> diff --git a/xen-all.c b/xen-all.c
> index b5e28ab..0e3bbcf 100644
> --- a/xen-all.c
> +++ b/xen-all.c
> @@ -979,3 +979,15 @@ void destroy_hvm_domain(void)
>          xc_interface_close(xc_handle);
>      }
>  }
> +
> +void xen_shutdown_fatal_error(const char *fmt, ...)
> +{
> +    va_list ap;
> +
> +    va_start(ap, fmt);
> +    vfprintf(stderr, fmt, ap);
> +    va_end(ap);
> +    fprintf(stderr, "Will destroy the domain.\n");
> +    /* destroy the domain */
> +    qemu_system_shutdown_request();
> +}
> -- 


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

From xen-devel-bounces@lists.xensource.com Thu Dec 01 23:20:21 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 01 Dec 2011 23:20:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWFup-0001Mu-5H; Thu, 01 Dec 2011 23:19:43 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1RWFun-0001Mp-Ee
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 23:19:42 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-12.tower-27.messagelabs.com!1322781515!43247944!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30004 invoked from network); 1 Dec 2011 23:18:36 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-12.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 1 Dec 2011 23:18:36 -0000
Received: from andromeda.dapyr.net (darnok@localhost [127.0.0.1])
	by andromeda.dapyr.net (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id
	pB1NImfp007690
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Thu, 1 Dec 2011 18:18:48 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pB1NIlY4007688;
	Thu, 1 Dec 2011 18:18:47 -0500
Date: Thu, 1 Dec 2011 19:18:47 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Anthony PERARD <anthony.perard@citrix.com>
Message-ID: <20111201231847.GA636@andromeda.dapyr.net>
References: <1322156679-9441-1-git-send-email-anthony.perard@citrix.com>
	<1322156679-9441-8-git-send-email-anthony.perard@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1322156679-9441-8-git-send-email-anthony.perard@citrix.com>
User-Agent: Mutt/1.5.9i
Cc: Guy Zana <guy@neocleus.com>, Xen Devel <xen-devel@lists.xensource.com>,
	Allen Kay <allen.m.kay@intel.com>, QEMU-devel <qemu-devel@nongnu.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH V5 07/10] Introduce Xen PCI Passthrough,
	qdevice (1/3)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Nov 24, 2011 at 05:44:36PM +0000, Anthony PERARD wrote:
> From: Allen Kay <allen.m.kay@intel.com>
> 
> A more complete history can be found here:
> git://xenbits.xensource.com/qemu-xen-unstable.git
> 
> Signed-off-by: Allen Kay <allen.m.kay@intel.com>
> Signed-off-by: Guy Zana <guy@neocleus.com>
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> ---
>  Makefile.target                      |    2 +
>  hw/xen_common.h                      |    3 +
>  hw/xen_pci_passthrough.c             |  831 ++++++++++++++++++++++++++++++++++
>  hw/xen_pci_passthrough.h             |  282 ++++++++++++
>  hw/xen_pci_passthrough_config_init.c |   11 +
>  xen-all.c                            |   12 +
>  6 files changed, 1141 insertions(+), 0 deletions(-)
>  create mode 100644 hw/xen_pci_passthrough.c
>  create mode 100644 hw/xen_pci_passthrough.h
>  create mode 100644 hw/xen_pci_passthrough_config_init.c
> 
> diff --git a/Makefile.target b/Makefile.target
> index e527c1b..33435a3 100644
> --- a/Makefile.target
> +++ b/Makefile.target
> @@ -221,6 +221,8 @@ obj-i386-$(CONFIG_XEN) += xen_platform.o
>  
>  # Xen PCI Passthrough
>  obj-i386-$(CONFIG_XEN_PCI_PASSTHROUGH) += host-pci-device.o
> +obj-i386-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen_pci_passthrough.o
> +obj-i386-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen_pci_passthrough_config_init.o
>  
>  # Inter-VM PCI shared memory
>  CONFIG_IVSHMEM =
> diff --git a/hw/xen_common.h b/hw/xen_common.h
> index 0409ac7..48916fd 100644
> --- a/hw/xen_common.h
> +++ b/hw/xen_common.h
> @@ -135,4 +135,7 @@ static inline int xc_fd(xc_interface *xen_xc)
>  
>  void destroy_hvm_domain(void);
>  
> +/* shutdown/destroy current domain because of an error */
> +void xen_shutdown_fatal_error(const char *fmt, ...) GCC_FMT_ATTR(1, 2);
> +
>  #endif /* QEMU_HW_XEN_COMMON_H */
> diff --git a/hw/xen_pci_passthrough.c b/hw/xen_pci_passthrough.c
> new file mode 100644
> index 0000000..998470b
> --- /dev/null
> +++ b/hw/xen_pci_passthrough.c
> @@ -0,0 +1,831 @@
> +/*
> + * Copyright (c) 2007, Neocleus Corporation.
> + * Copyright (c) 2007, Intel Corporation.
> + *
> + * This work is licensed under the terms of the GNU GPL, version 2.  See
> + * the COPYING file in the top-level directory.
> + *
> + * Alex Novik <alex@neocleus.com>
> + * Allen Kay <allen.m.kay@intel.com>
> + * Guy Zana <guy@neocleus.com>
> + *
> + * This file implements direct PCI assignment to a HVM guest
> + */
> +
> +/*
> + * Interrupt Disable policy:
> + *
> + * INTx interrupt:
> + *   Initialize(register_real_device)
> + *     Map INTx(xc_physdev_map_pirq):
> + *       <fail>
> + *         - Set real Interrupt Disable bit to '1'.
> + *         - Set machine_irq and assigned_device->machine_irq to '0'.
> + *         * Don't bind INTx.
> + *
> + *     Bind INTx(xc_domain_bind_pt_pci_irq):
> + *       <fail>
> + *         - Set real Interrupt Disable bit to '1'.
> + *         - Unmap INTx.
> + *         - Decrement mapped_machine_irq[machine_irq]
> + *         - Set assigned_device->machine_irq to '0'.
> + *
> + *   Write to Interrupt Disable bit by guest software(pt_cmd_reg_write)
> + *     Write '0'
> + *       <ptdev->msi_trans_en is false>
> + *         - Set real bit to '0' if assigned_device->machine_irq isn't '0'.
> + *
> + *     Write '1'
> + *       <ptdev->msi_trans_en is false>
> + *         - Set real bit to '1'.
> + */
> +
> +#include <sys/ioctl.h>
> +
> +#include "pci.h"
> +#include "xen.h"
> +#include "xen_backend.h"
> +#include "xen_pci_passthrough.h"
> +
> +#define PCI_BAR_ENTRIES (6)
> +
> +#define PT_NR_IRQS          (256)
> +char mapped_machine_irq[PT_NR_IRQS] = {0};


char? Can it be made uint8_t instead?
> +
> +void pt_log(const PCIDevice *d, const char *f, ...)
> +{
> +    va_list ap;
> +
> +    va_start(ap, f);
> +    if (d) {
> +        fprintf(stderr, "[%02x:%02x.%x] ", pci_bus_num(d->bus),
> +                PCI_SLOT(d->devfn), PCI_FUNC(d->devfn));
> +    }
> +    vfprintf(stderr, f, ap);
> +    va_end(ap);
> +}
> +
> +
> +/* Config Space */
> +static int pt_pci_config_access_check(PCIDevice *d, uint32_t address, int len)
> +{
> +    /* check offset range */
> +    if (address >= 0xFF) {
> +        PT_ERR(d, "Failed to access register with offset exceeding 0xFF. "
> +               "(addr: 0x%02x, len: %d)\n", address, len);
> +        return -1;
> +    }
> +
> +    /* check read size */
> +    if ((len != 1) && (len != 2) && (len != 4)) {
> +        PT_ERR(d, "Failed to access register with invalid access length. "
> +               "(addr: 0x%02x, len: %d)\n", address, len);
> +        return -1;
> +    }
> +
> +    /* check offset alignment */
> +    if (address & (len - 1)) {
> +        PT_ERR(d, "Failed to access register with invalid access size "
> +               "alignment. (addr: 0x%02x, len: %d)\n", address, len);
> +        return -1;
> +    }
> +
> +    return 0;
> +}
> +
> +int pt_bar_offset_to_index(uint32_t offset)
> +{
> +    int index = 0;
> +
> +    /* check Exp ROM BAR */
> +    if (offset == PCI_ROM_ADDRESS) {
> +        return PCI_ROM_SLOT;
> +    }
> +
> +    /* calculate BAR index */
> +    index = (offset - PCI_BASE_ADDRESS_0) >> 2;
> +    if (index >= PCI_NUM_REGIONS) {
> +        return -1;
> +    }
> +
> +    return index;
> +}
> +
> +static uint32_t pt_pci_read_config(PCIDevice *d, uint32_t address, int len)
> +{
> +    XenPCIPassthroughState *s = DO_UPCAST(XenPCIPassthroughState, dev, d);
> +    uint32_t val = 0;
> +    XenPTRegGroup *reg_grp_entry = NULL;
> +    XenPTReg *reg_entry = NULL;
> +    int rc = 0;
> +    int emul_len = 0;
> +    uint32_t find_addr = address;
> +
> +    if (pt_pci_config_access_check(d, address, len)) {
> +        goto exit;
> +    }
> +
> +    /* check power state transition flags */
> +    if (s->pm_state != NULL && s->pm_state->flags & PT_FLAG_TRANSITING) {
> +        /* can't accept until previous power state transition is completed.
> +         * so finish previous request here.

Uh, how do we finish previous request here?

> +         */
> +        PT_WARN(d, "Guest want to write during power state transition\n");
> +        goto exit;
> +    }
> +
> +    /* find register group entry */
> +    reg_grp_entry = pt_find_reg_grp(s, address);
> +    if (reg_grp_entry) {
> +        /* check 0 Hardwired register group */

So what does that mean? 0 hardwired register group? It means
that the register is always zero?

> +        if (reg_grp_entry->reg_grp->grp_type == GRP_TYPE_HARDWIRED) {
> +            /* no need to emulate, just return 0 */
> +            val = 0;
> +            goto exit;
> +        }
> +    }
> +
> +    /* read I/O device register value */
> +    rc = host_pci_get_block(s->real_device, address, (uint8_t *)&val, len);
> +    if (rc < 0) {
> +        PT_ERR(d, "pci_read_block failed. return value: %d.\n", rc);
> +        memset(&val, 0xff, len);
> +    }
> +
> +    /* just return the I/O device register value for
> +     * passthrough type register group */

Is another way to say that: "There is no filter for the
value, so just return the raw value." ?

> +    if (reg_grp_entry == NULL) {
> +        goto exit;
> +    }
> +
> +    /* adjust the read value to appropriate CFC-CFF window */
> +    val <<= (address & 3) << 3;
> +    emul_len = len;
> +
> +    /* loop around the guest requested size */
> +    while (emul_len > 0) {
> +        /* find register entry to be emulated */
> +        reg_entry = pt_find_reg(reg_grp_entry, find_addr);
> +        if (reg_entry) {
> +            XenPTRegInfo *reg = reg_entry->reg;
> +            uint32_t real_offset = reg_grp_entry->base_offset + reg->offset;
> +            uint32_t valid_mask = 0xFFFFFFFF >> ((4 - emul_len) << 3);
> +            uint8_t *ptr_val = NULL;
> +
> +            valid_mask <<= (find_addr - real_offset) << 3;
> +            ptr_val = (uint8_t *)&val + (real_offset & 3);
> +
> +            /* do emulation based on register size */
> +            switch (reg->size) {
> +            case 1:
> +                if (reg->u.b.read) {
> +                    rc = reg->u.b.read(s, reg_entry, ptr_val, valid_mask);
> +                }
> +                break;
> +            case 2:
> +                if (reg->u.w.read) {
> +                    rc = reg->u.w.read(s, reg_entry,
> +                                       (uint16_t *)ptr_val, valid_mask);
> +                }
> +                break;
> +            case 4:
> +                if (reg->u.dw.read) {
> +                    rc = reg->u.dw.read(s, reg_entry,
> +                                        (uint32_t *)ptr_val, valid_mask);
> +                }
> +                break;
> +            }
> +
> +            if (rc < 0) {
> +                xen_shutdown_fatal_error("Internal error: Invalid read "
> +                                         "emulation. (%s, rc: %d)\n",
> +                                         __func__, rc);
> +                return 0;
> +            }
> +
> +            /* calculate next address to find */
> +            emul_len -= reg->size;
> +            if (emul_len > 0) {
> +                find_addr = real_offset + reg->size;
> +            }
> +        } else {
> +            /* nothing to do with passthrough type register,
> +             * continue to find next byte */
> +            emul_len--;
> +            find_addr++;
> +        }
> +    }
> +
> +    /* need to shift back before returning them to pci bus emulator */
> +    val >>= ((address & 3) << 3);
> +
> +exit:
> +    PT_LOG_CONFIG(d, address, val, len);
> +    return val;
> +}
> +
> +static void pt_pci_write_config(PCIDevice *d, uint32_t address,
> +                                uint32_t val, int len)
> +{
> +    XenPCIPassthroughState *s = DO_UPCAST(XenPCIPassthroughState, dev, d);
> +    int index = 0;
> +    XenPTRegGroup *reg_grp_entry = NULL;
> +    int rc = 0;
> +    uint32_t read_val = 0;
> +    int emul_len = 0;
> +    XenPTReg *reg_entry = NULL;
> +    uint32_t find_addr = address;
> +    XenPTRegInfo *reg = NULL;
> +
> +    if (pt_pci_config_access_check(d, address, len)) {
> +        return;
> +    }
> +
> +    PT_LOG_CONFIG(d, address, val, len);
> +
> +    /* check unused BAR register */
> +    index = pt_bar_offset_to_index(address);
> +    if ((index >= 0) && (val > 0 && val < PT_BAR_ALLF) &&
> +        (s->bases[index].bar_flag == PT_BAR_FLAG_UNUSED)) {
> +        PT_WARN(d, "Guest attempt to set address to unused Base Address "
> +                "Register. (addr: 0x%02x, len: %d)\n", address, len);
> +    }
> +
> +    /* check power state transition flags */
> +    if (s->pm_state != NULL && s->pm_state->flags & PT_FLAG_TRANSITING) {
> +        /* can't accept until previous power state transition is completed.
> +         * so finish previous request here.

Ditto. How do we finish the previous request here?
> +         */
> +        PT_WARN(d, "Guest want to write during power state transition\n");
> +        return;
> +    }
> +
> +    /* find register group entry */
> +    reg_grp_entry = pt_find_reg_grp(s, address);
> +    if (reg_grp_entry) {
> +        /* check 0 Hardwired register group */
> +        if (reg_grp_entry->reg_grp->grp_type == GRP_TYPE_HARDWIRED) {
> +            /* ignore silently */
> +            PT_WARN(d, "Access to 0 Hardwired register. "
> +                    "(addr: 0x%02x, len: %d)\n", address, len);
> +            return;
> +        }
> +    }
> +
> +    /* read I/O device register value */
> +    rc = host_pci_get_block(s->real_device, address,
> +                             (uint8_t *)&read_val, len);
> +    if (rc < 0) {
> +        PT_ERR(d, "pci_read_block failed. return value: %d.\n", rc);
> +        memset(&read_val, 0xff, len);
> +    }
> +
> +    /* pass directly to the real device for passthrough type register group */
> +    if (reg_grp_entry == NULL) {
> +        goto out;
> +    }
> +
> +    /* adjust the read and write value to appropriate CFC-CFF window */
> +    read_val <<= (address & 3) << 3;
> +    val <<= (address & 3) << 3;
> +    emul_len = len;
> +
> +    /* loop around the guest requested size */
> +    while (emul_len > 0) {
> +        /* find register entry to be emulated */
> +        reg_entry = pt_find_reg(reg_grp_entry, find_addr);
> +        if (reg_entry) {
> +            reg = reg_entry->reg;
> +            uint32_t real_offset = reg_grp_entry->base_offset + reg->offset;
> +            uint32_t valid_mask = 0xFFFFFFFF >> ((4 - emul_len) << 3);
> +            uint8_t *ptr_val = NULL;
> +
> +            valid_mask <<= (find_addr - real_offset) << 3;
> +            ptr_val = (uint8_t *)&val + (real_offset & 3);
> +
> +            /* do emulation based on register size */
> +            switch (reg->size) {
> +            case 1:
> +                if (reg->u.b.write) {
> +                    rc = reg->u.b.write(s, reg_entry, ptr_val,
> +                                        read_val >> ((real_offset & 3) << 3),
> +                                        valid_mask);
> +                }
> +                break;
> +            case 2:
> +                if (reg->u.w.write) {
> +                    rc = reg->u.w.write(s, reg_entry, (uint16_t *)ptr_val,
> +                                        (read_val >> ((real_offset & 3) << 3)),
> +                                        valid_mask);
> +                }
> +                break;
> +            case 4:
> +                if (reg->u.dw.write) {
> +                    rc = reg->u.dw.write(s, reg_entry, (uint32_t *)ptr_val,
> +                                         (read_val >> ((real_offset & 3) << 3)),
> +                                         valid_mask);
> +                }
> +                break;
> +            }
> +
> +            if (rc < 0) {
> +                xen_shutdown_fatal_error("Internal error: Invalid write"
> +                                         " emulation. (%s, rc: %d)\n",
> +                                         __func__, rc);
> +                return;
> +            }
> +
> +            /* calculate next address to find */
> +            emul_len -= reg->size;
> +            if (emul_len > 0) {
> +                find_addr = real_offset + reg->size;
> +            }
> +        } else {
> +            /* nothing to do with passthrough type register,
> +             * continue to find next byte */
> +            emul_len--;
> +            find_addr++;
> +        }
> +    }
> +
> +    /* need to shift back before passing them to host_pci_device */
> +    val >>= (address & 3) << 3;
> +
> +out:
> +    if (!(reg && reg->no_wb)) {
> +        /* unknown regs are passed through */
> +        rc = host_pci_set_block(s->real_device, address, (uint8_t *)&val, len);
> +
> +        if (rc < 0) {
> +            PT_ERR(d, "pci_write_block failed. return value: %d.\n", rc);
> +        }
> +    }
> +}
> +
> +/* ioport/iomem space*/
> +static void pt_iomem_map(XenPCIPassthroughState *s, int i,
> +                         pcibus_t e_phys, pcibus_t e_size, int type)
> +{
> +    PCIIORegion *r = &s->dev.io_regions[i];
> +    uint32_t old_ebase = s->bases[i].e_physbase;
> +    bool first_map = s->bases[i].e_size == 0;
> +    int ret = 0;
> +
> +    s->bases[i].e_physbase = e_phys;
> +    s->bases[i].e_size = e_size;
> +
> +    PT_LOG(&s->dev, "e_phys=%#"PRIx64" maddr=%#"PRIx64" type=%d"
> +           " len=%#"PRIx64" index=%d first_map=%d\n",
> +           e_phys, s->bases[i].access.maddr, type,
> +           e_size, i, first_map);
> +
> +    if (e_size == 0) {
> +        return;
> +    }
> +
> +    if (!first_map && old_ebase != PT_PCI_BAR_UNMAPPED) {
> +        /* Remove old mapping */
> +        memory_region_del_subregion(r->address_space,
> +                                    r->memory);
> +        ret = xc_domain_memory_mapping(xen_xc, xen_domid,
> +                               old_ebase >> XC_PAGE_SHIFT,
> +                               s->bases[i].access.maddr >> XC_PAGE_SHIFT,
> +                               (e_size + XC_PAGE_SIZE - 1) >> XC_PAGE_SHIFT,
> +                               DPCI_REMOVE_MAPPING);
> +        if (ret != 0) {
> +            PT_ERR(&s->dev, "remove old mapping failed!\n");
> +            return;
> +        }
> +    }
> +
> +    /* map only valid guest address */
> +    if (e_phys != PCI_BAR_UNMAPPED) {
> +        /* Create new mapping */
> +        memory_region_add_subregion_overlap(r->address_space,
> +                                            e_phys, r->memory, 1);
> +        ret = xc_domain_memory_mapping(xen_xc, xen_domid,
> +                                   s->bases[i].e_physbase >> XC_PAGE_SHIFT,
> +                                   s->bases[i].access.maddr >> XC_PAGE_SHIFT,
> +                                   (e_size+XC_PAGE_SIZE-1) >> XC_PAGE_SHIFT,
> +                                   DPCI_ADD_MAPPING);
> +
> +        if (ret != 0) {
> +            PT_ERR(&s->dev, "create new mapping failed!\n");
> +        }
> +    }
> +}
> +
> +static void pt_ioport_map(XenPCIPassthroughState *s, int i,
> +                          pcibus_t e_phys, pcibus_t e_size, int type)
> +{
> +    PCIIORegion *r = &s->dev.io_regions[i];
> +    uint32_t old_ebase = s->bases[i].e_physbase;
> +    bool first_map = s->bases[i].e_size == 0;
> +    int ret = 0;
> +
> +    s->bases[i].e_physbase = e_phys;
> +    s->bases[i].e_size = e_size;
> +
> +    PT_LOG(&s->dev, "e_phys=%#04"PRIx64" pio_base=%#04"PRIx64" len=%"PRId64
> +           " index=%d first_map=%d\n",
> +           e_phys, s->bases[i].access.pio_base, e_size, i, first_map);
> +
> +    if (e_size == 0) {
> +        return;
> +    }
> +
> +    if (!first_map && old_ebase != PT_PCI_BAR_UNMAPPED) {
> +        /* Remove old mapping */
> +        memory_region_del_subregion(r->address_space,
> +                                    r->memory);
> +        ret = xc_domain_ioport_mapping(xen_xc, xen_domid, old_ebase,
> +                                       s->bases[i].access.pio_base, e_size,
> +                                       DPCI_REMOVE_MAPPING);
> +        if (ret != 0) {
> +            PT_ERR(&s->dev, "remove old mapping failed!\n");
> +            return;
> +        }
> +    }
> +
> +    /* map only valid guest address (include 0) */
> +    if (e_phys != PCI_BAR_UNMAPPED) {
> +        /* Create new mapping */
> +        memory_region_add_subregion_overlap(r->address_space,
> +                                            e_phys, r->memory, 1);
> +        ret = xc_domain_ioport_mapping(xen_xc, xen_domid, e_phys,
> +                                       s->bases[i].access.pio_base, e_size,
> +                                       DPCI_ADD_MAPPING);
> +        if (ret != 0) {
> +            PT_ERR(&s->dev, "create new mapping failed!\n");
> +        }
> +    }
> +
> +}
> +
> +
> +/* mapping BAR */
> +
> +void pt_bar_mapping_one(XenPCIPassthroughState *s, int bar,
> +                        int io_enable, int mem_enable)
> +{
> +    PCIDevice *dev = &s->dev;
> +    PCIIORegion *r;
> +    XenPTRegGroup *reg_grp_entry = NULL;
> +    XenPTReg *reg_entry = NULL;
> +    XenPTRegion *base = NULL;
> +    pcibus_t r_size = 0, r_addr = PCI_BAR_UNMAPPED;
> +    int rc = 0;
> +
> +    r = &dev->io_regions[bar];
> +
> +    /* check valid region */
> +    if (!r->size) {
> +        return;
> +    }
> +
> +    base = &s->bases[bar];
> +    /* skip unused BAR or upper 64bit BAR */
> +    if ((base->bar_flag == PT_BAR_FLAG_UNUSED)
> +        || (base->bar_flag == PT_BAR_FLAG_UPPER)) {
> +           return;
> +    }
> +
> +    /* copy region address to temporary */
> +    r_addr = r->addr;
> +
> +    /* need unmapping in case I/O Space or Memory Space disable */

.. is disabled.

> +    if (((base->bar_flag == PT_BAR_FLAG_IO) && !io_enable) ||
> +        ((base->bar_flag == PT_BAR_FLAG_MEM) && !mem_enable)) {
> +        r_addr = PCI_BAR_UNMAPPED;
> +    }

Add a comment saying:
	/* or ROM address is disabled. */
> +    if ((bar == PCI_ROM_SLOT) && (r_addr != PCI_BAR_UNMAPPED)) {
> +        reg_grp_entry = pt_find_reg_grp(s, PCI_ROM_ADDRESS);
> +        if (reg_grp_entry) {
> +            reg_entry = pt_find_reg(reg_grp_entry, PCI_ROM_ADDRESS);
> +            if (reg_entry && !(reg_entry->data & PCI_ROM_ADDRESS_ENABLE)) {
> +                r_addr = PCI_BAR_UNMAPPED;
> +            }
> +        }
> +    }
> +
> +    /* prevent guest software mapping memory resource to 00000000h */
> +    if ((base->bar_flag == PT_BAR_FLAG_MEM) && (r_addr == 0)) {
> +        r_addr = PCI_BAR_UNMAPPED;
> +    }
> +
> +    r_size = pt_get_emul_size(base->bar_flag, r->size);
> +
> +    rc = pci_check_bar_overlap(dev, r_addr, r_size, r->type);
> +    if (rc) {
> +        PT_WARN(dev, "Region: %d (addr: %#"FMT_PCIBUS
> +                ", len: %#"FMT_PCIBUS") is overlapped.\n",

Is the FMT_PCIBUS for len correct?

> +                bar, r_addr, r_size);
> +    }
> +
> +    /* check whether we need to update the mapping or not */
> +    if (r_addr != s->bases[bar].e_physbase) {
> +        /* mapping BAR */
> +        if (base->bar_flag == PT_BAR_FLAG_IO) {
> +            pt_ioport_map(s, bar, r_addr, r_size, r->type);
> +        } else {
> +            pt_iomem_map(s, bar, r_addr, r_size, r->type);
> +        }
> +    }
> +}
> +
> +void pt_bar_mapping(XenPCIPassthroughState *s, int io_enable, int mem_enable)
> +{
> +    int i;
> +
> +    for (i = 0; i < PCI_NUM_REGIONS; i++) {
> +        pt_bar_mapping_one(s, i, io_enable, mem_enable);
> +    }
> +}
> +
> +static uint64_t bar_read(void *o, target_phys_addr_t addr, unsigned size)
> +{
> +    PCIDevice *d = o;
> +    PT_ERR(d, "Should not read BAR through QEMU. @0x"TARGET_FMT_plx"\n", addr);


Perhaps you can add a comment of how it should read it? Is the reading
trapped by the hypervisor? If so, you might want to include a comment
stating that, maybe even the name of the file to look in.

> +    return 0;
> +}
> +static void bar_write(void *o, target_phys_addr_t addr,
> +                      uint64_t data, unsigned size)
> +{
> +    PCIDevice* d = o;
> +    PT_ERR(d, "Should not write BAR through QEMU. @0x"TARGET_FMT_plx"\n", addr);
> +}
> +
> +static const MemoryRegionOps ops = {
> +    .endianness = DEVICE_NATIVE_ENDIAN,
> +    .read = bar_read,
> +    .write = bar_write,
> +};
> +
> +/* register regions */
> +static int pt_register_regions(XenPCIPassthroughState *s)
> +{
> +    int i = 0;
> +    uint32_t bar_data = 0;
> +    HostPCIDevice *d = s->real_device;
> +
> +    /* Register PIO/MMIO BARs */
> +    for (i = 0; i < PCI_BAR_ENTRIES; i++) {
> +        HostPCIIORegion *r = &d->io_regions[i];
> +
> +        if (r->base_addr && r->size) {
> +            s->bases[i].e_physbase = r->base_addr;
> +            s->bases[i].access.u = r->base_addr;
> +
> +            /* Register current region */
> +            if (r->flags & IORESOURCE_IO) {
> +                memory_region_init_io(&s->bar[i], &ops, &s->dev,
> +                                      "xen-pci-pt-bar-io", r->size);
> +                pci_register_bar(&s->dev, i, PCI_BASE_ADDRESS_SPACE_IO,
> +                                 &s->bar[i]);
> +            } else if (r->flags & IORESOURCE_PREFETCH) {
> +                memory_region_init_io(&s->bar[i], &ops, &s->dev,
> +                                      "xen-pci-pt-bar-mem", r->size);
> +                pci_register_bar(&s->dev, i, PCI_BASE_ADDRESS_MEM_PREFETCH,
> +                                 &s->bar[i]);
> +            } else {
> +                memory_region_init_io(&s->bar[i], &ops, &s->dev,
> +                                      "xen-pci-pt-bar-mem", r->size);
> +                pci_register_bar(&s->dev, i, PCI_BASE_ADDRESS_SPACE_MEMORY,
> +                                 &s->bar[i]);
> +            }
> +
> +            PT_LOG(&s->dev, "IO region registered (size=0x%08"PRIx64
> +                   " base_addr=0x%08"PRIx64")\n",
> +                   r->size, r->base_addr);
> +        }
> +    }
> +
> +    /* Register expansion ROM address */
> +    if (d->rom.base_addr && d->rom.size) {
> +        /* Re-set BAR reported by OS, otherwise ROM can't be read. */
> +        if (host_pci_get_long(d, PCI_ROM_ADDRESS, &bar_data)) {
> +            return 0;
> +        }
> +        if ((bar_data & PCI_ROM_ADDRESS_MASK) == 0) {
> +            bar_data |= d->rom.base_addr & PCI_ROM_ADDRESS_MASK;
> +            host_pci_set_long(d, PCI_ROM_ADDRESS, bar_data);
> +        }
> +
> +        s->bases[PCI_ROM_SLOT].e_physbase = d->rom.base_addr;
> +        s->bases[PCI_ROM_SLOT].access.maddr = d->rom.base_addr;
> +
> +        memory_region_init_rom_device(&s->rom, NULL, NULL, &s->dev.qdev,
> +                                      "xen-pci-pt-rom", d->rom.size);
> +        pci_register_bar(&s->dev, PCI_ROM_SLOT, PCI_BASE_ADDRESS_MEM_PREFETCH,
> +                         &s->rom);
> +
> +        PT_LOG(&s->dev, "Expansion ROM registered (size=0x%08"PRIx64
> +               " base_addr=0x%08"PRIx64")\n",
> +               d->rom.size, d->rom.base_addr);
> +    }
> +
> +    return 0;
> +}
> +
> +static void pt_unregister_regions(XenPCIPassthroughState *s)
> +{
> +    int i, type, rc;
> +    uint32_t e_size;
> +    PCIDevice *d = &s->dev;
> +
> +    for (i = 0; i < PCI_NUM_REGIONS; i++) {
> +        e_size = s->bases[i].e_size;
> +        if ((e_size == 0) || (s->bases[i].e_physbase == PT_PCI_BAR_UNMAPPED)) {
> +            continue;
> +        }
> +
> +        type = d->io_regions[i].type;
> +
> +        if (type == PCI_BASE_ADDRESS_SPACE_MEMORY
> +            || type == PCI_BASE_ADDRESS_MEM_PREFETCH) {
> +            rc = xc_domain_memory_mapping(xen_xc, xen_domid,
> +                    s->bases[i].e_physbase >> XC_PAGE_SHIFT,
> +                    s->bases[i].access.maddr >> XC_PAGE_SHIFT,
> +                    (e_size+XC_PAGE_SIZE-1) >> XC_PAGE_SHIFT,
> +                    DPCI_REMOVE_MAPPING);
> +            if (rc != 0) {
> +                PT_ERR(d, "remove old mem mapping failed!\n");
> +                continue;
> +            }
> +
> +        } else if (type == PCI_BASE_ADDRESS_SPACE_IO) {
> +            rc = xc_domain_ioport_mapping(xen_xc, xen_domid,
> +                        s->bases[i].e_physbase,
> +                        s->bases[i].access.pio_base,
> +                        e_size,
> +                        DPCI_REMOVE_MAPPING);
> +            if (rc != 0) {
> +                PT_ERR(d, "remove old io mapping failed!\n");
> +                continue;
> +            }
> +        }
> +    }
> +}
> +
> +static int pt_initfn(PCIDevice *pcidev)
> +{
> +    XenPCIPassthroughState *s = DO_UPCAST(XenPCIPassthroughState, dev, pcidev);
> +    int dom, bus;
> +    unsigned slot, func;

So how come bus is 'int' but slot and func are unsigned?

> +    int rc = 0;
> +    uint8_t machine_irq = 0;
> +    int pirq = PT_UNASSIGNED_PIRQ;
> +
> +    if (pci_parse_devaddr(s->hostaddr, &dom, &bus, &slot, &func) < 0) {
> +        PT_ERR(pcidev, "Failed to parse BDF: %s\n", s->hostaddr);
> +        return -1;
> +    }
> +
> +    /* register real device */
> +    PT_LOG(pcidev, "Assigning real physical device %02x:%02x.%x"
> +           " to devfn %#x\n", bus, slot, func, s->dev.devfn);
> +
> +    s->real_device = host_pci_device_get(bus, slot, func);
> +    if (!s->real_device) {
> +        return -1;
> +    }
> +
> +    s->is_virtfn = s->real_device->is_virtfn;
> +    if (s->is_virtfn) {
> +        PT_LOG(pcidev, "%04x:%02x:%02x.%x is a SR-IOV Virtual Function\n",
> +               s->real_device->domain, bus, slot, func);
> +    }
> +
> +    /* Initialize virtualized PCI configuration (Extended 256 Bytes) */
> +    if (host_pci_get_block(s->real_device, 0, pcidev->config,
> +                           PCI_CONFIG_SPACE_SIZE) == -1) {
> +        host_pci_device_put(s->real_device);
> +        return -1;
> +    }
> +
> +    /* Handle real device's MMIO/PIO BARs */
> +    pt_register_regions(s);
> +
> +    /* Bind interrupt */
> +    if (!s->dev.config[PCI_INTERRUPT_PIN]) {

Is a 'zero' value correct? I think that is the value that
SR-IOV devices export since they don't have legacy IRQs?
Or maybe they export the MSI vector values instead.

Perhaps you should do
    if (!s->dev.config[PCI_INTERRUPT_PIN] && !s->is_virtfn) {

> +        PT_LOG(pcidev, "no pin interrupt\n");
> +        goto out;
> +    }
> +
> +    host_pci_get_byte(s->real_device, PCI_INTERRUPT_LINE, &machine_irq);

Just to double check:

> lspci -s 01:10.0 -v -xx
01:10.0 Ethernet controller: Intel Corporation 82576 Virtual Function
(rev 01)
	Subsystem: Intel Corporation Device a01c
	Flags: bus master, fast devsel, latency 0
	[virtual] Memory at b8840000 (64-bit, non-prefetchable) [size=16K]
	[virtual] Memory at b8860000 (64-bit, non-prefetchable) [size=16K]
	Capabilities: [70] MSI-X: Enable+ Count=3 Masked-
	Capabilities: [a0] Express Endpoint, MSI 00
	Capabilities: [100] Advanced Error Reporting
	Capabilities: [150] Alternative Routing-ID Interpretation (ARI)
	Kernel driver in use: igbvf
	Kernel modules: igbvf
00: ff ff ff ff 04 00 10 00 01 00 00 02 00 00 00 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 86 80 1c a0
30: 00 00 00 00 70 00 00 00 00 00 00 00 00 00 00 00

And a normal USB device:

>  lspci -s 00:1a.0 -v -xx 
00:1a.0 USB Controller: Intel Corporation 82801JI (ICH10 Family) USB
UHCI Controller #4 (prog-if 00 [UHCI])
	Subsystem: Intel Corporation Device 4f53
	Flags: bus master, medium devsel, latency 0, IRQ 16
	I/O ports at 40e0 [size=32]
	Capabilities: [50] PCI Advanced Features
	Kernel driver in use: uhci_hcd
00: 86 80 37 3a 05 00 90 02 00 00 03 0c 00 00 80 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: e1 40 00 00 00 00 00 00 00 00 00 00 86 80 53 4f
30: 00 00 00 00 50 00 00 00 00 00 00 00 0b 01 00 00

The USB device has interrupt line 0xB, and pin 1.
The SR-IOV one is zero and zero.

> +    rc = xc_physdev_map_pirq(xen_xc, xen_domid, machine_irq, &pirq);

so perhaps this should be guarded by a check against devices that
have no legacy IRQs, like SR-VIO? Perhaps check against is_virtfn?

> +
> +    if (rc < 0) {
> +        PT_ERR(pcidev, "Mapping machine irq %u to pirq %i failed, (rc: %d)\n",
> +               machine_irq, pirq, rc);
> +
> +        /* Disable PCI intx assertion (turn on bit10 of devctl) */
> +        host_pci_set_word(s->real_device,
> +                          PCI_COMMAND,
> +                          pci_get_word(s->dev.config + PCI_COMMAND)
> +                          | PCI_COMMAND_INTX_DISABLE);
> +        machine_irq = 0;
> +        s->machine_irq = 0;
> +    } else {
> +        machine_irq = pirq;
> +        s->machine_irq = pirq;
> +        mapped_machine_irq[machine_irq]++;
> +    }
> +
> +    /* bind machine_irq to device */
> +    if (rc < 0 && machine_irq != 0) {
> +        uint8_t e_device = PCI_SLOT(s->dev.devfn);
> +        uint8_t e_intx = pci_intx(s);
> +
> +        rc = xc_domain_bind_pt_pci_irq(xen_xc, xen_domid, machine_irq, 0,

What is the zero at the end for? Should it have a comment?

> +                                       e_device, e_intx);
> +        if (rc < 0) {
> +            PT_ERR(pcidev, "Binding of interrupt %i failed! (rc: %d)\n",
> +                   e_intx, rc);
> +
> +            /* Disable PCI intx assertion (turn on bit10 of devctl) */
> +            host_pci_set_word(s->real_device, PCI_COMMAND,
> +                              *(uint16_t *)(&s->dev.config[PCI_COMMAND])
> +                              | PCI_COMMAND_INTX_DISABLE);
> +            mapped_machine_irq[machine_irq]--;

Is this code reentrant? What if the user wants to pass in two USB
devices where both of them share the same IRQ. And it so happens that we
fail (perhaps the device is owned by another guest). We get here, and
both of them decrement the mapped_machine_irq.. which means that
> +
> +            if (mapped_machine_irq[machine_irq] == 0) {

this might not be executed (as both of them read it as =1).?
> +                if (xc_physdev_unmap_pirq(xen_xc, xen_domid, machine_irq)) {
> +                    PT_ERR(pcidev, "Unmapping of machine interrupt %i failed!"
> +                           " (rc: %d)\n", machine_irq, rc);

Or is the code actually single-threaded so there is no danger of this?

> +                }
> +            }
> +            s->machine_irq = 0;
> +        }
> +    }
> +
> +out:
> +    PT_LOG(pcidev, "Real physical device %02x:%02x.%x registered successfuly!"
> +           "\nIRQ type = %s\n", bus, slot, func, "INTx");
> +
> +    return 0;
> +}
> +
> +static int pt_unregister_device(PCIDevice *pcidev)
> +{
> +    XenPCIPassthroughState *s = DO_UPCAST(XenPCIPassthroughState, dev, pcidev);
> +    uint8_t e_device, e_intx;
> +    uint8_t machine_irq;
> +    int rc;
> +
> +    /* Unbind interrupt */
> +    e_device = PCI_SLOT(s->dev.devfn);
> +    e_intx = pci_intx(s);
> +    machine_irq = s->machine_irq;
> +
> +    if (machine_irq) {
> +        rc = xc_domain_unbind_pt_irq(xen_xc, xen_domid, machine_irq,
> +                                     PT_IRQ_TYPE_PCI, 0, e_device, e_intx, 0);

What are the two '0' for?
Can you provide a comment within the arguments?

> +        if (rc < 0) {
> +            PT_ERR(pcidev, "Unbinding of interrupt failed! rc=%d\n", rc);

Might want to mention which interrupt (or pirq?) failed.

> +        }
> +    }
> +
> +    if (machine_irq) {

Why not continue the logic within this code? As in why
the 'if (machine_irq)' here? You would still continue going
even if xc_domain_unbind_pt_irq failed..

> +        mapped_machine_irq[machine_irq]--;
> +
> +        if (mapped_machine_irq[machine_irq] == 0) {
> +            rc = xc_physdev_unmap_pirq(xen_xc, xen_domid, machine_irq);
> +
> +            if (rc < 0) {
> +                PT_ERR(pcidev, "Unmaping of interrupt failed! rc=%d\n", rc);

And provide the interrupt (both the pirq and linux one).

You might want to mention in the erorr logs: "But bravely continuing on.."
> +            }
> +        }
> +    }
> +
> +    /* unregister real device's MMIO/PIO BARs */
> +    pt_unregister_regions(s);
> +
> +    host_pci_device_put(s->real_device);
> +
> +    return 0;
> +}
> +
> +static PCIDeviceInfo xen_pci_passthrough = {
> +    .init = pt_initfn,
> +    .exit = pt_unregister_device,
> +    .qdev.name = "xen-pci-passthrough",
> +    .qdev.desc = "Assign an host pci device with Xen",
> +    .qdev.size = sizeof(XenPCIPassthroughState),
> +    .config_read = pt_pci_read_config,
> +    .config_write = pt_pci_write_config,
> +    .is_express = 0,
> +    .qdev.props = (Property[]) {
> +        DEFINE_PROP_STRING("hostaddr", XenPCIPassthroughState, hostaddr),
> +        DEFINE_PROP_BIT("power-mgmt", XenPCIPassthroughState, power_mgmt,
> +                        0, false),
> +        DEFINE_PROP_END_OF_LIST(),
> +    }
> +};
> +
> +static void xen_passthrough_register(void)
> +{
> +    pci_qdev_register(&xen_pci_passthrough);
> +}
> +
> +device_init(xen_passthrough_register);
> diff --git a/hw/xen_pci_passthrough.h b/hw/xen_pci_passthrough.h
> new file mode 100644
> index 0000000..110325c
> --- /dev/null
> +++ b/hw/xen_pci_passthrough.h
> @@ -0,0 +1,282 @@
> +#ifndef QEMU_HW_XEN_PCI_PASSTHROUGH_H
> +#  define QEMU_HW_XEN_PCI_PASSTHROUGH_H
> +
> +#include "qemu-common.h"
> +#include "xen_common.h"
> +#include "pci.h"
> +#include "host-pci-device.h"
> +
> +/* #define PT_LOGGING_ENABLED */
> +/* #define PT_DEBUG_PCI_CONFIG_ACCESS */
> +
> +void pt_log(const PCIDevice *d, const char *f, ...) GCC_FMT_ATTR(2, 3);
> +
> +#define PT_ERR(d, _f, _a...)  pt_log(d, "%s: Error: " _f, __func__, ##_a)
> +
> +#ifdef PT_LOGGING_ENABLED
> +#  define PT_LOG(d, _f, _a...)  pt_log(d, "%s: " _f, __func__, ##_a)
> +#  define PT_WARN(d, _f, _a...) pt_log(d, "%s: Warning: " _f, __func__, ##_a)
> +#else
> +#  define PT_LOG(d, _f, _a...)
> +#  define PT_WARN(d, _f, _a...)
> +#endif
> +
> +#ifdef PT_DEBUG_PCI_CONFIG_ACCESS
> +#  define PT_LOG_CONFIG(d, addr, val, len) \
> +    pt_log(d, "%s: address=0x%04x val=0x%08x len=%d\n", \
> +           __func__, addr, val, len)
> +#else
> +#  define PT_LOG_CONFIG(d, addr, val, len)
> +#endif


Nice. Thanks!

> +
> +
> +typedef struct XenPTRegInfo XenPTRegInfo;
> +typedef struct XenPTReg XenPTReg;
> +
> +typedef struct XenPCIPassthroughState XenPCIPassthroughState;
> +
> +/* function type for config reg */
> +typedef int (*conf_reg_init)
> +    (XenPCIPassthroughState *, XenPTRegInfo *, uint32_t real_offset,
> +     uint32_t *data);
> +typedef int (*conf_dword_write)
> +    (XenPCIPassthroughState *, XenPTReg *cfg_entry,
> +     uint32_t *val, uint32_t dev_value, uint32_t valid_mask);
> +typedef int (*conf_word_write)
> +    (XenPCIPassthroughState *, XenPTReg *cfg_entry,
> +     uint16_t *val, uint16_t dev_value, uint16_t valid_mask);
> +typedef int (*conf_byte_write)
> +    (XenPCIPassthroughState *, XenPTReg *cfg_entry,
> +     uint8_t *val, uint8_t dev_value, uint8_t valid_mask);
> +typedef int (*conf_dword_read)
> +    (XenPCIPassthroughState *, XenPTReg *cfg_entry,
> +     uint32_t *val, uint32_t valid_mask);
> +typedef int (*conf_word_read)
> +    (XenPCIPassthroughState *, XenPTReg *cfg_entry,
> +     uint16_t *val, uint16_t valid_mask);
> +typedef int (*conf_byte_read)
> +    (XenPCIPassthroughState *, XenPTReg *cfg_entry,
> +     uint8_t *val, uint8_t valid_mask);
> +typedef int (*conf_dword_restore)
> +    (XenPCIPassthroughState *, XenPTReg *cfg_entry, uint32_t real_offset,
> +     uint32_t dev_value, uint32_t *val);
> +typedef int (*conf_word_restore)
> +    (XenPCIPassthroughState *, XenPTReg *cfg_entry, uint32_t real_offset,
> +     uint16_t dev_value, uint16_t *val);
> +typedef int (*conf_byte_restore)
> +    (XenPCIPassthroughState *, XenPTReg *cfg_entry, uint32_t real_offset,
> +     uint8_t dev_value, uint8_t *val);
> +
> +/* power state transition */
> +#define PT_FLAG_TRANSITING  0x0001
> +
> +#define PT_BAR_ALLF         0xFFFFFFFF  /* BAR ALLF value */
> +#define PT_PCI_BAR_UNMAPPED (-1)
> +#define PT_UNASSIGNED_PIRQ (-1)
> +
> +
> +typedef enum {
> +    GRP_TYPE_HARDWIRED = 0,                     /* 0 Hardwired reg group */
> +    GRP_TYPE_EMU,                               /* emul reg group */
> +} RegisterGroupType;
> +
> +typedef enum {
> +    PT_BAR_FLAG_MEM = 0,                        /* Memory type BAR */
> +    PT_BAR_FLAG_IO,                             /* I/O type BAR */
> +    PT_BAR_FLAG_UPPER,                          /* upper 64bit BAR */
> +    PT_BAR_FLAG_UNUSED,                         /* unused BAR */
> +} PTBarFlag;
> +
> +
> +typedef struct XenPTRegion {
> +    /* Virtual phys base & size */
> +    uint32_t e_physbase;
> +    uint32_t e_size;
> +    /* Index of region in qemu */
> +    uint32_t memory_index;
> +    /* BAR flag */
> +    PTBarFlag bar_flag;
> +    /* Translation of the emulated address */
> +    union {
> +        uint64_t maddr;
> +        uint64_t pio_base;
> +        uint64_t u;
> +    } access;
> +} XenPTRegion;
> +
> +/* XenPTRegInfo declaration
> + * - only for emulated register (either a part or whole bit).
> + * - for passthrough register that need special behavior (like interacting with
> + *   other component), set emu_mask to all 0 and specify r/w func properly.
> + * - do NOT use ALL F for init_val, otherwise the tbl will not be registered.
> + */
> +
> +/* emulated register infomation */
> +struct XenPTRegInfo {
> +    uint32_t offset;
> +    uint32_t size;
> +    uint32_t init_val;
> +    /* reg read only field mask (ON:RO/ROS, OFF:other) */
> +    uint32_t ro_mask;
> +    /* reg emulate field mask (ON:emu, OFF:passthrough) */
> +    uint32_t emu_mask;
> +    /* no write back allowed */
> +    uint32_t no_wb;
> +    conf_reg_init init;
> +    /* read/write/restore function pointer
> +     * for double_word/word/byte size */
> +    union {
> +        struct {
> +            conf_dword_write write;
> +            conf_dword_read read;
> +            conf_dword_restore restore;
> +        } dw;
> +        struct {
> +            conf_word_write write;
> +            conf_word_read read;
> +            conf_word_restore restore;
> +        } w;
> +        struct {
> +            conf_byte_write write;
> +            conf_byte_read read;
> +            conf_byte_restore restore;
> +        } b;
> +    } u;
> +};
> +
> +/* emulated register management */
> +struct XenPTReg {
> +    QLIST_ENTRY(XenPTReg) entries;
> +    XenPTRegInfo *reg;
> +    uint32_t data;
> +};
> +
> +typedef struct XenPTRegGroupInfo XenPTRegGroupInfo;
> +
> +/* emul reg group size initialize method */
> +typedef int (*pt_reg_size_init_fn)
> +    (XenPCIPassthroughState *, const XenPTRegGroupInfo *,
> +     uint32_t base_offset, uint8_t *size);
> +
> +/* emulated register group infomation */
> +struct XenPTRegGroupInfo {
> +    uint8_t grp_id;
> +    RegisterGroupType grp_type;
> +    uint8_t grp_size;
> +    pt_reg_size_init_fn size_init;
> +    XenPTRegInfo *emu_reg_tbl;
> +};
> +
> +/* emul register group management table */
> +typedef struct XenPTRegGroup {
> +    QLIST_ENTRY(XenPTRegGroup) entries;
> +    const XenPTRegGroupInfo *reg_grp;
> +    uint32_t base_offset;
> +    uint8_t size;
> +    QLIST_HEAD(, XenPTReg) reg_tbl_list;
> +} XenPTRegGroup;
> +
> +
> +typedef struct XenPTPM {
> +    QEMUTimer *pm_timer;  /* QEMUTimer struct */
> +    int no_soft_reset;    /* No Soft Reset flags */
> +    uint16_t flags;       /* power state transition flags */
> +    uint16_t pmc_field;   /* Power Management Capabilities field */
> +    int pm_delay;         /* power state transition delay */
> +    uint16_t cur_state;   /* current power state */
> +    uint16_t req_state;   /* requested power state */
> +    uint32_t pm_base;     /* Power Management Capability reg base offset */
> +    uint32_t aer_base;    /* AER Capability reg base offset */
> +} XenPTPM;
> +
> +struct XenPCIPassthroughState {
> +    PCIDevice dev;
> +
> +    char *hostaddr;
> +    bool is_virtfn;
> +    HostPCIDevice *real_device;
> +    XenPTRegion bases[PCI_NUM_REGIONS]; /* Access regions */
> +    QLIST_HEAD(, XenPTRegGroup) reg_grp_tbl;
> +
> +    uint32_t machine_irq;
> +
> +    uint32_t power_mgmt;
> +    XenPTPM *pm_state;
> +
> +    MemoryRegion bar[PCI_NUM_REGIONS - 1];
> +    MemoryRegion rom;
> +};
> +
> +int pt_config_init(XenPCIPassthroughState *s);
> +void pt_config_delete(XenPCIPassthroughState *s);
> +void pt_bar_mapping(XenPCIPassthroughState *s, int io_enable, int mem_enable);
> +void pt_bar_mapping_one(XenPCIPassthroughState *s, int bar,
> +                        int io_enable, int mem_enable);
> +XenPTRegGroup *pt_find_reg_grp(XenPCIPassthroughState *s, uint32_t address);
> +XenPTReg *pt_find_reg(XenPTRegGroup *reg_grp, uint32_t address);
> +int pt_bar_offset_to_index(uint32_t offset);
> +
> +static inline pcibus_t pt_get_emul_size(PTBarFlag flag, pcibus_t r_size)
> +{
> +    /* align resource size (memory type only) */
> +    if (flag == PT_BAR_FLAG_MEM) {
> +        return (r_size + XC_PAGE_SIZE - 1) & XC_PAGE_MASK;
> +    } else {
> +        return r_size;
> +    }
> +}
> +
> +/* INTx */
> +/* The PCI Local Bus Specification, Rev. 3.0,
> + * Section 6.2.4 Miscellaneous Registers, pp 223
> + * outlines 5 valid values for the intertupt pin (intx).
> + *  0: For devices (or device functions) that don't use an interrupt in
> + *  1: INTA#
> + *  2: INTB#
> + *  3: INTC#
> + *  4: INTD#
> + *
> + * Xen uses the following 4 values for intx
> + *  0: INTA#
> + *  1: INTB#
> + *  2: INTC#
> + *  3: INTD#
> + *
> + * Observing that these list of values are not the same, pci_read_intx()
> + * uses the following mapping from hw to xen values.

Might want to add : "(from /sys/../config contents)."
> + * This seems to reflect the current usage within Xen.
> + *
> + * PCI hardware    | Xen | Notes
> + * ----------------+-----+----------------------------------------------------
> + * 0               | 0   | No interrupt
> + * 1               | 0   | INTA#
> + * 2               | 1   | INTB#
> + * 3               | 2   | INTC#
> + * 4               | 3   | INTD#
> + * any other value | 0   | This should never happen, log error message
> + */
> +
> +static inline uint8_t pci_read_intx(XenPCIPassthroughState *s)
> +{
> +    uint8_t v = 0;
> +    host_pci_get_byte(s->real_device, PCI_INTERRUPT_PIN, &v);
> +    return v;
> +}
> +
> +static inline uint8_t pci_intx(XenPCIPassthroughState *s)
> +{
> +    uint8_t r_val = pci_read_intx(s);
> +
> +    PT_LOG(&s->dev, "intx=%i\n", r_val);
> +    if (r_val < 1 || r_val > 4) {
> +        PT_LOG(&s->dev, "Interrupt pin read from hardware is out of range:"
> +               " value=%i, acceptable range is 1 - 4\n", r_val);
> +        r_val = 0;
> +    } else {
> +        r_val -= 1;
> +    }
> +
> +    return r_val;
> +}
> +
> +#endif /* !QEMU_HW_XEN_PCI_PASSTHROUGH_H */
> diff --git a/hw/xen_pci_passthrough_config_init.c b/hw/xen_pci_passthrough_config_init.c
> new file mode 100644
> index 0000000..1e9de64
> --- /dev/null
> +++ b/hw/xen_pci_passthrough_config_init.c
> @@ -0,0 +1,11 @@
> +#include "xen_pci_passthrough.h"
> +
> +XenPTRegGroup *pt_find_reg_grp(XenPCIPassthroughState *s, uint32_t address)
> +{
> +    return NULL;
> +}
> +
> +XenPTReg *pt_find_reg(XenPTRegGroup *reg_grp, uint32_t address)
> +{
> +    return NULL;
> +}
> diff --git a/xen-all.c b/xen-all.c
> index b5e28ab..0e3bbcf 100644
> --- a/xen-all.c
> +++ b/xen-all.c
> @@ -979,3 +979,15 @@ void destroy_hvm_domain(void)
>          xc_interface_close(xc_handle);
>      }
>  }
> +
> +void xen_shutdown_fatal_error(const char *fmt, ...)
> +{
> +    va_list ap;
> +
> +    va_start(ap, fmt);
> +    vfprintf(stderr, fmt, ap);
> +    va_end(ap);
> +    fprintf(stderr, "Will destroy the domain.\n");
> +    /* destroy the domain */
> +    qemu_system_shutdown_request();
> +}
> -- 


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

From xen-devel-bounces@lists.xensource.com Fri Dec 02 01:36:07 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 01: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.xensource.com>)
	id 1RWI2E-0000Ci-ID; Fri, 02 Dec 2011 01:35:30 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1RWI2C-0000Ca-7K
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 01:35:28 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-13.tower-21.messagelabs.com!1322789684!4640009!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11262 invoked from network); 2 Dec 2011 01:34:46 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-13.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 2 Dec 2011 01:34:46 -0000
Received: from andromeda.dapyr.net (darnok@localhost [127.0.0.1])
	by andromeda.dapyr.net (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id
	pB21YVn8015449
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Thu, 1 Dec 2011 20:34:31 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pB21YUa1015447;
	Thu, 1 Dec 2011 20:34:30 -0500
Date: Thu, 1 Dec 2011 21:34:30 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20111202013430.GB636@andromeda.dapyr.net>
References: <patchbomb.1322772713@xdev.gridcentric.ca>
	<1170bc32db41a7ae1e95.1322772715@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1170bc32db41a7ae1e95.1322772715@xdev.gridcentric.ca>
User-Agent: Mutt/1.5.9i
Cc: olaf@aepfle.de, xen-devel@lists.xensource.com, mike.mcclurg@citrix.com,
	jonathan.ludlam@eu.citrix.com, JBeulich@suse.com, andres@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 2 of 2] xenpaging: handle GNTST_eagain in
	kernel drivers
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Dec 01, 2011 at 03:51:55PM -0500, Andres Lagar-Cavilla wrote:
>  drivers/xen/blkback/blkback.c              |   6 ++-
>  drivers/xen/blkback/interface.c            |   9 +++-
>  drivers/xen/core/gnttab.c                  |   4 +-
>  drivers/xen/gntdev/gntdev.c                |  49 +++++++++++++++++------------
>  drivers/xen/netback/interface.c            |   5 +-
>  drivers/xen/netback/netback.c              |  16 ++++++---
>  drivers/xen/scsiback/interface.c           |  10 +++---
>  drivers/xen/scsiback/scsiback.c            |   4 +-
>  drivers/xen/tpmback/interface.c            |   7 +--
>  drivers/xen/tpmback/tpmback.c              |  20 ++++-------
>  drivers/xen/usbback/interface.c            |  16 ++++----
>  drivers/xen/usbback/usbback.c              |   4 +-
>  drivers/xen/xenbus/xenbus_backend_client.c |  10 +++---
>  include/xen/gnttab.h                       |  37 ++++++++++++++++++++++
>  14 files changed, 126 insertions(+), 71 deletions(-)
> 
> 
> Handle GNTST_eagain status from GNTTABOP_map_grant_ref and
> GNTTABOP_copy operations properly to allow usage of xenpaging without
> causing crashes or data corruption.
> 
> Replace all relevant HYPERVISOR_grant_table_op() calls with a retry
> loop. This loop is implemented as a macro to allow different
> GNTTABOP_* args. It will sleep up to 33 seconds and wait for the
> page to be paged in again.
> 
> All ->status checks were updated to use the GNTST_* namespace. All
> return values are converted from GNTST_* namespace to 0/-EINVAL, since
> all callers did not use the actual return value.

Any plans to do this for the pvops tree?

> 
> Signed-off-by: Olaf Hering <olaf@aepfle.de>
> Acked-by: Patrick Colp <pjcolp@cs.ubc.ca>
> 
> This is a port from xenlinux 2.6.18 to the 2.6.32 xcp tree
> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
> 
> diff -r df9e25a0189b -r 1170bc32db41 drivers/xen/blkback/blkback.c
> --- a/drivers/xen/blkback/blkback.c
> +++ b/drivers/xen/blkback/blkback.c
> @@ -701,11 +701,13 @@ static void dispatch_rw_block_io(blkif_t
>  	BUG_ON(ret);
>  
>  	for (i = 0; i < nseg; i++) {
> -		if (unlikely(map[i].status != 0)) {
> +		if (unlikely(map[i].status == GNTST_eagain))
> +			gnttab_check_GNTST_eagain_do_while(GNTTABOP_map_grant_ref, &map[i]);
> +		if (unlikely(map[i].status != GNTST_okay)) {
>  			DPRINTK("grant map of dom %u gref %u failed: status %d\n",
>  				blkif->domid, req->seg[i].gref, map[i].status);
>  			map[i].handle = BLKBACK_INVALID_HANDLE;
> -			ret |= 1;
> +			ret = 1;
>  			continue;
>  		}
>  
> diff -r df9e25a0189b -r 1170bc32db41 drivers/xen/blkback/interface.c
> --- a/drivers/xen/blkback/interface.c
> +++ b/drivers/xen/blkback/interface.c
> @@ -95,7 +95,7 @@ static int map_frontend_pages(blkif_t *b
>  	struct vm_struct *area = blkif->blk_ring_area;
>  	struct gnttab_map_grant_ref op[BLKIF_MAX_RING_PAGES];
>  	unsigned int i;
> -	int status = 0;
> +	int status = GNTST_okay;
>  
>  	for (i = 0; i < nr_shared_pages; i++) {
>  		unsigned long addr = (unsigned long)area->addr +
> @@ -110,7 +110,10 @@ static int map_frontend_pages(blkif_t *b
>  		BUG();
>  
>  	for (i = 0; i < nr_shared_pages; i++) {
> -		if ((status = op[i].status) != 0) {
> +		if (op[i].status == GNTST_eagain)
> +			gnttab_check_GNTST_eagain_do_while(GNTTABOP_map_grant_ref, &op[i]);
> +		if (op[i].status != GNTST_okay) {
> +			status = op[i].status;
>  			blkif->shmem_handle[i] = INVALID_GRANT_HANDLE;
>  			continue;
>  		}
> @@ -120,7 +123,7 @@ static int map_frontend_pages(blkif_t *b
>  
>  	blkif->nr_shared_pages = nr_shared_pages;
>  
> -	if (status != 0) {
> +	if (status != GNTST_okay) {
>  		DPRINTK(" Grant table operation failure !\n");
>  		unmap_frontend_pages(blkif);
>  	}
> diff -r df9e25a0189b -r 1170bc32db41 drivers/xen/core/gnttab.c
> --- a/drivers/xen/core/gnttab.c
> +++ b/drivers/xen/core/gnttab.c
> @@ -773,7 +773,7 @@ static int gnttab_map(unsigned int start
>  		return -ENOSYS;
>  	}
>  
> -	BUG_ON(rc || setup.status);
> +	BUG_ON(rc || (setup.status != GNTST_okay));
>  
>  	if (shared.raw == NULL)
>  		shared.raw = arch_gnttab_alloc_shared(gframes);
> @@ -901,7 +901,7 @@ int gnttab_copy_grant_page(grant_ref_t r
>  	err = HYPERVISOR_grant_table_op(GNTTABOP_unmap_and_replace,
>  					&unmap, 1);
>  	BUG_ON(err);
> -	BUG_ON(unmap.status);
> +	BUG_ON(unmap.status != GNTST_okay);
>  
>  	write_sequnlock_irq(&gnttab_dma_lock);
>  
> diff -r df9e25a0189b -r 1170bc32db41 drivers/xen/gntdev/gntdev.c
> --- a/drivers/xen/gntdev/gntdev.c
> +++ b/drivers/xen/gntdev/gntdev.c
> @@ -503,7 +503,7 @@ static int gntdev_mmap (struct file *fli
>  	uint64_t ptep;
>  	int ret;
>  	int flags;
> -	int i;
> +	int i, exit_ret;
>  	struct page *page;
>  	gntdev_file_private_data_t *private_data = flip->private_data;
>  
> @@ -578,6 +578,7 @@ static int gntdev_mmap (struct file *fli
>  	vma->vm_mm->context.has_foreign_mappings = 1;
>  #endif
>  
> +	exit_ret = -ENOMEM;
>  	for (i = 0; i < size; ++i) {
>  
>  		flags = GNTMAP_host_map;
> @@ -598,14 +599,18 @@ static int gntdev_mmap (struct file *fli
>  		ret = HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, 
>  						&op, 1);
>  		BUG_ON(ret);
> -		if (op.status) {
> -			printk(KERN_ERR "Error mapping the grant reference "
> -			       "into the kernel (%d). domid = %d; ref = %d\n",
> -			       op.status,
> -			       private_data->grants[slot_index+i]
> -			       .u.valid.domid,
> -			       private_data->grants[slot_index+i]
> -			       .u.valid.ref);
> +		if (op.status != GNTST_okay) {
> +			if (op.status != GNTST_eagain)
> +				printk(KERN_ERR "Error mapping the grant reference "
> +					   "into the kernel (%d). domid = %d; ref = %d\n",
> +					   op.status,
> +					   private_data->grants[slot_index+i]
> +					   .u.valid.domid,
> +					   private_data->grants[slot_index+i]
> +					   .u.valid.ref);
> +			else
> +				/* Propagate instead of trying to fix it up */
> +				exit_ret = -EAGAIN;
>  			goto undo_map_out;
>  		}
>  
> @@ -674,14 +679,17 @@ static int gntdev_mmap (struct file *fli
>  			ret = HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref,
>  							&op, 1);
>  			BUG_ON(ret);
> -			if (op.status) {
> +			if (op.status != GNTST_okay) {
>  				printk(KERN_ERR "Error mapping the grant "
> -				       "reference into user space (%d). domid "
> -				       "= %d; ref = %d\n", op.status,
> -				       private_data->grants[slot_index+i].u
> -				       .valid.domid,
> -				       private_data->grants[slot_index+i].u
> -				       .valid.ref);
> +					   "reference into user space (%d). domid "
> +					   "= %d; ref = %d\n", op.status,
> +					   private_data->grants[slot_index+i].u
> +					   .valid.domid,
> +					   private_data->grants[slot_index+i].u
> +					   .valid.ref);
> +				/* GNTST_eagain (i.e. page paged out) sohuld never happen
> +				 * once we've mapped into kernel space */
> +				BUG_ON(op.status == GNTST_eagain);
>  				goto undo_map_out;
>  			}
>  			
> @@ -705,9 +713,10 @@ static int gntdev_mmap (struct file *fli
>  		}
>  
>  	}
> +	exit_ret = 0;
>  
>  	up_write(&private_data->grants_sem);
> -	return 0;
> +	return exit_ret;
>  
>  undo_map_out:
>  	/* If we have a mapping failure, the unmapping will be taken care of
> @@ -725,7 +734,7 @@ undo_map_out:
>  	
>  	up_write(&private_data->grants_sem);
>  
> -	return -ENOMEM;
> +	return exit_ret;
>  }
>  
>  static pte_t gntdev_clear_pte(struct vm_area_struct *vma, unsigned long addr,
> @@ -777,7 +786,7 @@ static pte_t gntdev_clear_pte(struct vm_
>  			ret = HYPERVISOR_grant_table_op(
>  				GNTTABOP_unmap_grant_ref, &op, 1);
>  			BUG_ON(ret);
> -			if (op.status)
> +			if (op.status != GNTST_okay)
>  				printk("User unmap grant status = %d\n", 
>  				       op.status);
>  		} else {
> @@ -794,7 +803,7 @@ static pte_t gntdev_clear_pte(struct vm_
>  		ret = HYPERVISOR_grant_table_op(GNTTABOP_unmap_grant_ref, 
>  						&op, 1);
>  		BUG_ON(ret);
> -		if (op.status)
> +		if (op.status != GNTST_okay)
>  			printk("Kernel unmap grant status = %d\n", op.status);
>  
>  
> diff -r df9e25a0189b -r 1170bc32db41 drivers/xen/netback/interface.c
> --- a/drivers/xen/netback/interface.c
> +++ b/drivers/xen/netback/interface.c
> @@ -381,10 +381,9 @@ static int map_frontend_pages(struct xen
>  	gnttab_set_map_op(&op, (unsigned long)comms->ring_area->addr,
>  			  GNTMAP_host_map, ring_ref, domid);
>      
> -	if (HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, &op, 1))
> -		BUG();
> +	gnttab_check_GNTST_eagain_do_while(GNTTABOP_map_grant_ref, &op);
>  
> -	if (op.status) {
> +	if (op.status != GNTST_okay) {
>  		DPRINTK(" Gnttab failure mapping ring_ref!\n");
>  		free_vm_area(comms->ring_area);
>  		return op.status;
> diff -r df9e25a0189b -r 1170bc32db41 drivers/xen/netback/netback.c
> --- a/drivers/xen/netback/netback.c
> +++ b/drivers/xen/netback/netback.c
> @@ -419,11 +419,13 @@ static int netbk_check_gop(int nr_copy_s
>  
>  	for (i = 0; i < nr_copy_slots; i++) {
>  		copy_op = npo->copy + npo->copy_cons++;
> +		if (copy_op->status == GNTST_eagain)
> +			gnttab_check_GNTST_eagain_while(GNTTABOP_copy, copy_op);
>  		if (copy_op->status != GNTST_okay) {
> -				DPRINTK("Bad status %d from copy to DOM%d.\n",
> -					copy_op->status, domid);
> -				status = NETIF_RSP_ERROR;
> -			}
> +			DPRINTK("Bad status %d from copy to DOM%d.\n",
> +				copy_op->status, domid);
> +			status = NETIF_RSP_ERROR;
> +		}
>  	}
>  
>  	return status;
> @@ -1020,7 +1022,11 @@ static int netbk_tx_check_mop(struct xen
>  
>  	/* Check status of header. */
>  	err = mop->status;
> -	if (unlikely(err)) {
> +	if (err == GNTST_eagain) {
> +		gnttab_check_GNTST_eagain_do_while(GNTTABOP_map_grant_ref, mop);
> +		err = mop->status;
> +	}
> +	if (unlikely(err != GNTST_okay)) {
>  		pending_ring_idx_t index;
>  		index = pending_index(netbk->pending_prod++);
>  		txp = &pending_tx_info[pending_idx].req;
> diff -r df9e25a0189b -r 1170bc32db41 drivers/xen/scsiback/interface.c
> --- a/drivers/xen/scsiback/interface.c
> +++ b/drivers/xen/scsiback/interface.c
> @@ -69,18 +69,18 @@ static int map_frontend_page( struct vsc
>  				GNTMAP_host_map, ring_ref,
>  				info->domid);
>  
> -	err = HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, &op, 1);
> -	BUG_ON(err);
> +	gnttab_check_GNTST_eagain_do_while(GNTTABOP_map_grant_ref, &op);
>  
> -	if (op.status) {
> -		printk(KERN_ERR "scsiback: Grant table operation failure !\n");
> +	if (op.status != GNTST_okay) {
> +		printk(KERN_ERR "scsiback: Grant table operation failure %d!\n", 
> +							(int) op.status);
>  		return op.status;
>  	}
>  
>  	info->shmem_ref    = ring_ref;
>  	info->shmem_handle = op.handle;
>  
> -	return (GNTST_okay);
> +	return 0;
>  }
>  
>  static void unmap_frontend_page(struct vscsibk_info *info)
> diff -r df9e25a0189b -r 1170bc32db41 drivers/xen/scsiback/scsiback.c
> --- a/drivers/xen/scsiback/scsiback.c
> +++ b/drivers/xen/scsiback/scsiback.c
> @@ -287,7 +287,9 @@ static int scsiback_gnttab_data_map(vscs
>  		for_each_sg (pending_req->sgl, sg, nr_segments, i) {
>  			struct page *pg;
>  
> -			if (unlikely(map[i].status != 0)) {
> +			if (unlikely(map[i].status == GNTST_eagain))
> +				gnttab_check_GNTST_eagain_while(GNTTABOP_map_grant_ref, &map[i]);
> +			if (unlikely(map[i].status != GNTST_okay)) {
>  				printk(KERN_ERR "scsiback: invalid buffer -- could not remap it\n");
>  				map[i].handle = SCSIBACK_INVALID_HANDLE;
>  				err |= 1;
> diff -r df9e25a0189b -r 1170bc32db41 drivers/xen/tpmback/interface.c
> --- a/drivers/xen/tpmback/interface.c
> +++ b/drivers/xen/tpmback/interface.c
> @@ -86,11 +86,10 @@ static int map_frontend_page(tpmif_t *tp
>  	gnttab_set_map_op(&op, (unsigned long)tpmif->tx_area->addr,
>  			  GNTMAP_host_map, shared_page, tpmif->domid);
>  
> -	if (HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, &op, 1))
> -		BUG();
> +	gnttab_check_GNTST_eagain_do_while(GNTTABOP_map_grant_ref, &op);
>  
> -	if (op.status) {
> -		DPRINTK(" Grant table operation failure !\n");
> +	if (op.status != GNTST_okay) {
> +		DPRINTK(" Grant table operation failure %d!\n", (int) op.status);
>  		return op.status;
>  	}
>  
> diff -r df9e25a0189b -r 1170bc32db41 drivers/xen/tpmback/tpmback.c
> --- a/drivers/xen/tpmback/tpmback.c
> +++ b/drivers/xen/tpmback/tpmback.c
> @@ -256,15 +256,13 @@ int _packet_write(struct packet *pak,
>  		gnttab_set_map_op(&map_op, idx_to_kaddr(tpmif, i),
>  				  GNTMAP_host_map, tx->ref, tpmif->domid);
>  
> -		if (unlikely(HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref,
> -						       &map_op, 1))) {
> -			BUG();
> -		}
> +		gnttab_check_GNTST_eagain_do_while(GNTTABOP_map_grant_ref, &map_op);
>  
>  		handle = map_op.handle;
>  
> -		if (map_op.status) {
> -			DPRINTK(" Grant table operation failure !\n");
> +		if (map_op.status != GNTST_okay) {
> +			DPRINTK(" Grant table operation failure %d!\n", 
> +						(int) map_op.status);
>  			return 0;
>  		}
>  
> @@ -394,13 +392,11 @@ static int packet_read_shmem(struct pack
>  		gnttab_set_map_op(&map_op, idx_to_kaddr(tpmif, i),
>  				  GNTMAP_host_map, tx->ref, tpmif->domid);
>  
> -		if (unlikely(HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref,
> -						       &map_op, 1))) {
> -			BUG();
> -		}
> +		gnttab_check_GNTST_eagain_do_while(GNTTABOP_map_grant_ref, &map_op);
>  
> -		if (map_op.status) {
> -			DPRINTK(" Grant table operation failure !\n");
> +		if (map_op.status != GNTST_okay) {
> +			DPRINTK(" Grant table operation failure %d!\n",
> +						(int) map_op.status);
>  			return -EFAULT;
>  		}
>  
> diff -r df9e25a0189b -r 1170bc32db41 drivers/xen/usbback/interface.c
> --- a/drivers/xen/usbback/interface.c
> +++ b/drivers/xen/usbback/interface.c
> @@ -109,11 +109,11 @@ static int map_frontend_pages(usbif_t *u
>  	gnttab_set_map_op(&op, (unsigned long)usbif->urb_ring_area->addr,
>  			  GNTMAP_host_map, urb_ring_ref, usbif->domid);
>  
> -	if (HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, &op, 1))
> -		BUG();
> +	gnttab_check_GNTST_eagain_do_while(GNTTABOP_map_grant_ref, &op);
>  
> -	if (op.status) {
> -		printk(KERN_ERR "grant table failure mapping urb_ring_ref\n");
> +	if (op.status != GNTST_okay) {
> +		printk(KERN_ERR "grant table failure mapping urb_ring_ref %d\n",
> +							(int) op.status);
>  		return op.status;
>  	}
>  
> @@ -123,17 +123,17 @@ static int map_frontend_pages(usbif_t *u
>  	gnttab_set_map_op(&op, (unsigned long)usbif->conn_ring_area->addr,
>  			  GNTMAP_host_map, conn_ring_ref, usbif->domid);
>  
> -	if (HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, &op, 1))
> -		BUG();
> +	gnttab_check_GNTST_eagain_do_while(GNTTABOP_map_grant_ref, &op);
>  
> -	if (op.status) {
> +	if (op.status != GNTST_okay) {
>  		struct gnttab_unmap_grant_ref unop;
>  		gnttab_set_unmap_op(&unop,
>  				(unsigned long) usbif->urb_ring_area->addr,
>  				GNTMAP_host_map, usbif->urb_shmem_handle);
>  		VOID(HYPERVISOR_grant_table_op(GNTTABOP_unmap_grant_ref, &unop,
>  				1));
> -		printk(KERN_ERR "grant table failure mapping conn_ring_ref\n");
> +		printk(KERN_ERR "grant table failure mapping conn_ring_ref %d\n",
> +							(int) op.status);
>  		return op.status;
>  	}
>  
> diff -r df9e25a0189b -r 1170bc32db41 drivers/xen/usbback/usbback.c
> --- a/drivers/xen/usbback/usbback.c
> +++ b/drivers/xen/usbback/usbback.c
> @@ -428,7 +428,9 @@ static int usbbk_gnttab_map(usbif_t *usb
>  		BUG_ON(ret);
>  
>  		for (i = 0; i < nr_segs; i++) {
> -			if (unlikely(map[i].status != 0)) {
> +			if (unlikely(map[i].status == GNTST_eagain))
> +				gnttab_check_GNTST_eagain_while(GNTTABOP_map_grant_ref, &map[i]);
> +			if (unlikely(map[i].status != GNTST_okay)) {
>  				printk(KERN_ERR "usbback: invalid buffer -- could not remap it\n");
>  				map[i].handle = USBBACK_INVALID_HANDLE;
>  				ret |= 1;
> diff -r df9e25a0189b -r 1170bc32db41 drivers/xen/xenbus/xenbus_backend_client.c
> --- a/drivers/xen/xenbus/xenbus_backend_client.c
> +++ b/drivers/xen/xenbus/xenbus_backend_client.c
> @@ -48,8 +48,7 @@ struct vm_struct *xenbus_map_ring_valloc
>  	gnttab_set_map_op(&op, (unsigned long)area->addr, GNTMAP_host_map,
>  			  gnt_ref, dev->otherend_id);
>  	
> -	if (HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, &op, 1))
> -		BUG();
> +	gnttab_check_GNTST_eagain_do_while(GNTTABOP_map_grant_ref, &op);
>  
>  	if (op.status != GNTST_okay) {
>  		free_vm_area(area);
> @@ -75,15 +74,16 @@ int xenbus_map_ring(struct xenbus_device
>  	
>  	gnttab_set_map_op(&op, (unsigned long)vaddr, GNTMAP_host_map,
>  			  gnt_ref, dev->otherend_id);
> -	if (HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, &op, 1))
> -		BUG();
> +	gnttab_check_GNTST_eagain_do_while(GNTTABOP_map_grant_ref, &op);
>  
>  	if (op.status != GNTST_okay) {
>  		xenbus_dev_fatal(dev, op.status,
>  				 "mapping in shared page %d from domain %d",
>  				 gnt_ref, dev->otherend_id);
> -	} else
> +	} else {
>  		*handle = op.handle;
> +		return 0;
> +	}
>  
>  	return op.status;
>  }
> diff -r df9e25a0189b -r 1170bc32db41 include/xen/gnttab.h
> --- a/include/xen/gnttab.h
> +++ b/include/xen/gnttab.h
> @@ -187,4 +187,41 @@ gnttab_set_replace_op(struct gnttab_unma
>  	unmap->handle = handle;
>  }
>  
> +#define gnttab_check_GNTST_eagain_while(__HCop, __HCarg_p)					\
> +do {																		\
> +	u8 __hc_delay = 1;														\
> +	int __ret;																\
> +	while (unlikely((__HCarg_p)->status == GNTST_eagain && __hc_delay)) {	\
> +		msleep(__hc_delay++);												\
> +		__ret = HYPERVISOR_grant_table_op(__HCop, (__HCarg_p), 1);			\
> +		BUG_ON(__ret);														\
> +	}																		\
> +	if (__hc_delay == 0) {													\
> +		printk(KERN_ERR "%s: %s gnt busy\n", __func__, current->comm);		\
> +		(__HCarg_p)->status = GNTST_bad_page;								\
> +	}																		\
> +	if ((__HCarg_p)->status != GNTST_okay)									\
> +		printk(KERN_ERR "%s: %s gnt status %x\n", 							\
> +			__func__, current->comm, (__HCarg_p)->status);					\
> +} while(0)
> +
> +#define gnttab_check_GNTST_eagain_do_while(__HCop, __HCarg_p)			\
> +do {																	\
> +	u8 __hc_delay = 1;													\
> +	int __ret;															\
> +	do {																\
> +		__ret = HYPERVISOR_grant_table_op(__HCop, (__HCarg_p), 1);		\
> +		BUG_ON(__ret);													\
> +		if ((__HCarg_p)->status == GNTST_eagain)						\
> +			msleep(__hc_delay++);										\
> +	} while ((__HCarg_p)->status == GNTST_eagain && __hc_delay);		\
> +	if (__hc_delay == 0) {												\
> +		printk(KERN_ERR "%s: %s gnt busy\n", __func__, current->comm);	\
> +		(__HCarg_p)->status = GNTST_bad_page;							\
> +	}																	\
> +	if ((__HCarg_p)->status != GNTST_okay)								\
> +		printk(KERN_ERR "%s: %s gnt status %x\n", 						\
> +			__func__, current->comm, (__HCarg_p)->status);				\
> +} while(0)
> +
>  #endif /* __ASM_GNTTAB_H__ */
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

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

From xen-devel-bounces@lists.xensource.com Fri Dec 02 01:36:07 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 01: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.xensource.com>)
	id 1RWI2E-0000Ci-ID; Fri, 02 Dec 2011 01:35:30 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1RWI2C-0000Ca-7K
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 01:35:28 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-13.tower-21.messagelabs.com!1322789684!4640009!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11262 invoked from network); 2 Dec 2011 01:34:46 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-13.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 2 Dec 2011 01:34:46 -0000
Received: from andromeda.dapyr.net (darnok@localhost [127.0.0.1])
	by andromeda.dapyr.net (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id
	pB21YVn8015449
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Thu, 1 Dec 2011 20:34:31 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pB21YUa1015447;
	Thu, 1 Dec 2011 20:34:30 -0500
Date: Thu, 1 Dec 2011 21:34:30 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20111202013430.GB636@andromeda.dapyr.net>
References: <patchbomb.1322772713@xdev.gridcentric.ca>
	<1170bc32db41a7ae1e95.1322772715@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1170bc32db41a7ae1e95.1322772715@xdev.gridcentric.ca>
User-Agent: Mutt/1.5.9i
Cc: olaf@aepfle.de, xen-devel@lists.xensource.com, mike.mcclurg@citrix.com,
	jonathan.ludlam@eu.citrix.com, JBeulich@suse.com, andres@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 2 of 2] xenpaging: handle GNTST_eagain in
	kernel drivers
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Dec 01, 2011 at 03:51:55PM -0500, Andres Lagar-Cavilla wrote:
>  drivers/xen/blkback/blkback.c              |   6 ++-
>  drivers/xen/blkback/interface.c            |   9 +++-
>  drivers/xen/core/gnttab.c                  |   4 +-
>  drivers/xen/gntdev/gntdev.c                |  49 +++++++++++++++++------------
>  drivers/xen/netback/interface.c            |   5 +-
>  drivers/xen/netback/netback.c              |  16 ++++++---
>  drivers/xen/scsiback/interface.c           |  10 +++---
>  drivers/xen/scsiback/scsiback.c            |   4 +-
>  drivers/xen/tpmback/interface.c            |   7 +--
>  drivers/xen/tpmback/tpmback.c              |  20 ++++-------
>  drivers/xen/usbback/interface.c            |  16 ++++----
>  drivers/xen/usbback/usbback.c              |   4 +-
>  drivers/xen/xenbus/xenbus_backend_client.c |  10 +++---
>  include/xen/gnttab.h                       |  37 ++++++++++++++++++++++
>  14 files changed, 126 insertions(+), 71 deletions(-)
> 
> 
> Handle GNTST_eagain status from GNTTABOP_map_grant_ref and
> GNTTABOP_copy operations properly to allow usage of xenpaging without
> causing crashes or data corruption.
> 
> Replace all relevant HYPERVISOR_grant_table_op() calls with a retry
> loop. This loop is implemented as a macro to allow different
> GNTTABOP_* args. It will sleep up to 33 seconds and wait for the
> page to be paged in again.
> 
> All ->status checks were updated to use the GNTST_* namespace. All
> return values are converted from GNTST_* namespace to 0/-EINVAL, since
> all callers did not use the actual return value.

Any plans to do this for the pvops tree?

> 
> Signed-off-by: Olaf Hering <olaf@aepfle.de>
> Acked-by: Patrick Colp <pjcolp@cs.ubc.ca>
> 
> This is a port from xenlinux 2.6.18 to the 2.6.32 xcp tree
> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
> 
> diff -r df9e25a0189b -r 1170bc32db41 drivers/xen/blkback/blkback.c
> --- a/drivers/xen/blkback/blkback.c
> +++ b/drivers/xen/blkback/blkback.c
> @@ -701,11 +701,13 @@ static void dispatch_rw_block_io(blkif_t
>  	BUG_ON(ret);
>  
>  	for (i = 0; i < nseg; i++) {
> -		if (unlikely(map[i].status != 0)) {
> +		if (unlikely(map[i].status == GNTST_eagain))
> +			gnttab_check_GNTST_eagain_do_while(GNTTABOP_map_grant_ref, &map[i]);
> +		if (unlikely(map[i].status != GNTST_okay)) {
>  			DPRINTK("grant map of dom %u gref %u failed: status %d\n",
>  				blkif->domid, req->seg[i].gref, map[i].status);
>  			map[i].handle = BLKBACK_INVALID_HANDLE;
> -			ret |= 1;
> +			ret = 1;
>  			continue;
>  		}
>  
> diff -r df9e25a0189b -r 1170bc32db41 drivers/xen/blkback/interface.c
> --- a/drivers/xen/blkback/interface.c
> +++ b/drivers/xen/blkback/interface.c
> @@ -95,7 +95,7 @@ static int map_frontend_pages(blkif_t *b
>  	struct vm_struct *area = blkif->blk_ring_area;
>  	struct gnttab_map_grant_ref op[BLKIF_MAX_RING_PAGES];
>  	unsigned int i;
> -	int status = 0;
> +	int status = GNTST_okay;
>  
>  	for (i = 0; i < nr_shared_pages; i++) {
>  		unsigned long addr = (unsigned long)area->addr +
> @@ -110,7 +110,10 @@ static int map_frontend_pages(blkif_t *b
>  		BUG();
>  
>  	for (i = 0; i < nr_shared_pages; i++) {
> -		if ((status = op[i].status) != 0) {
> +		if (op[i].status == GNTST_eagain)
> +			gnttab_check_GNTST_eagain_do_while(GNTTABOP_map_grant_ref, &op[i]);
> +		if (op[i].status != GNTST_okay) {
> +			status = op[i].status;
>  			blkif->shmem_handle[i] = INVALID_GRANT_HANDLE;
>  			continue;
>  		}
> @@ -120,7 +123,7 @@ static int map_frontend_pages(blkif_t *b
>  
>  	blkif->nr_shared_pages = nr_shared_pages;
>  
> -	if (status != 0) {
> +	if (status != GNTST_okay) {
>  		DPRINTK(" Grant table operation failure !\n");
>  		unmap_frontend_pages(blkif);
>  	}
> diff -r df9e25a0189b -r 1170bc32db41 drivers/xen/core/gnttab.c
> --- a/drivers/xen/core/gnttab.c
> +++ b/drivers/xen/core/gnttab.c
> @@ -773,7 +773,7 @@ static int gnttab_map(unsigned int start
>  		return -ENOSYS;
>  	}
>  
> -	BUG_ON(rc || setup.status);
> +	BUG_ON(rc || (setup.status != GNTST_okay));
>  
>  	if (shared.raw == NULL)
>  		shared.raw = arch_gnttab_alloc_shared(gframes);
> @@ -901,7 +901,7 @@ int gnttab_copy_grant_page(grant_ref_t r
>  	err = HYPERVISOR_grant_table_op(GNTTABOP_unmap_and_replace,
>  					&unmap, 1);
>  	BUG_ON(err);
> -	BUG_ON(unmap.status);
> +	BUG_ON(unmap.status != GNTST_okay);
>  
>  	write_sequnlock_irq(&gnttab_dma_lock);
>  
> diff -r df9e25a0189b -r 1170bc32db41 drivers/xen/gntdev/gntdev.c
> --- a/drivers/xen/gntdev/gntdev.c
> +++ b/drivers/xen/gntdev/gntdev.c
> @@ -503,7 +503,7 @@ static int gntdev_mmap (struct file *fli
>  	uint64_t ptep;
>  	int ret;
>  	int flags;
> -	int i;
> +	int i, exit_ret;
>  	struct page *page;
>  	gntdev_file_private_data_t *private_data = flip->private_data;
>  
> @@ -578,6 +578,7 @@ static int gntdev_mmap (struct file *fli
>  	vma->vm_mm->context.has_foreign_mappings = 1;
>  #endif
>  
> +	exit_ret = -ENOMEM;
>  	for (i = 0; i < size; ++i) {
>  
>  		flags = GNTMAP_host_map;
> @@ -598,14 +599,18 @@ static int gntdev_mmap (struct file *fli
>  		ret = HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, 
>  						&op, 1);
>  		BUG_ON(ret);
> -		if (op.status) {
> -			printk(KERN_ERR "Error mapping the grant reference "
> -			       "into the kernel (%d). domid = %d; ref = %d\n",
> -			       op.status,
> -			       private_data->grants[slot_index+i]
> -			       .u.valid.domid,
> -			       private_data->grants[slot_index+i]
> -			       .u.valid.ref);
> +		if (op.status != GNTST_okay) {
> +			if (op.status != GNTST_eagain)
> +				printk(KERN_ERR "Error mapping the grant reference "
> +					   "into the kernel (%d). domid = %d; ref = %d\n",
> +					   op.status,
> +					   private_data->grants[slot_index+i]
> +					   .u.valid.domid,
> +					   private_data->grants[slot_index+i]
> +					   .u.valid.ref);
> +			else
> +				/* Propagate instead of trying to fix it up */
> +				exit_ret = -EAGAIN;
>  			goto undo_map_out;
>  		}
>  
> @@ -674,14 +679,17 @@ static int gntdev_mmap (struct file *fli
>  			ret = HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref,
>  							&op, 1);
>  			BUG_ON(ret);
> -			if (op.status) {
> +			if (op.status != GNTST_okay) {
>  				printk(KERN_ERR "Error mapping the grant "
> -				       "reference into user space (%d). domid "
> -				       "= %d; ref = %d\n", op.status,
> -				       private_data->grants[slot_index+i].u
> -				       .valid.domid,
> -				       private_data->grants[slot_index+i].u
> -				       .valid.ref);
> +					   "reference into user space (%d). domid "
> +					   "= %d; ref = %d\n", op.status,
> +					   private_data->grants[slot_index+i].u
> +					   .valid.domid,
> +					   private_data->grants[slot_index+i].u
> +					   .valid.ref);
> +				/* GNTST_eagain (i.e. page paged out) sohuld never happen
> +				 * once we've mapped into kernel space */
> +				BUG_ON(op.status == GNTST_eagain);
>  				goto undo_map_out;
>  			}
>  			
> @@ -705,9 +713,10 @@ static int gntdev_mmap (struct file *fli
>  		}
>  
>  	}
> +	exit_ret = 0;
>  
>  	up_write(&private_data->grants_sem);
> -	return 0;
> +	return exit_ret;
>  
>  undo_map_out:
>  	/* If we have a mapping failure, the unmapping will be taken care of
> @@ -725,7 +734,7 @@ undo_map_out:
>  	
>  	up_write(&private_data->grants_sem);
>  
> -	return -ENOMEM;
> +	return exit_ret;
>  }
>  
>  static pte_t gntdev_clear_pte(struct vm_area_struct *vma, unsigned long addr,
> @@ -777,7 +786,7 @@ static pte_t gntdev_clear_pte(struct vm_
>  			ret = HYPERVISOR_grant_table_op(
>  				GNTTABOP_unmap_grant_ref, &op, 1);
>  			BUG_ON(ret);
> -			if (op.status)
> +			if (op.status != GNTST_okay)
>  				printk("User unmap grant status = %d\n", 
>  				       op.status);
>  		} else {
> @@ -794,7 +803,7 @@ static pte_t gntdev_clear_pte(struct vm_
>  		ret = HYPERVISOR_grant_table_op(GNTTABOP_unmap_grant_ref, 
>  						&op, 1);
>  		BUG_ON(ret);
> -		if (op.status)
> +		if (op.status != GNTST_okay)
>  			printk("Kernel unmap grant status = %d\n", op.status);
>  
>  
> diff -r df9e25a0189b -r 1170bc32db41 drivers/xen/netback/interface.c
> --- a/drivers/xen/netback/interface.c
> +++ b/drivers/xen/netback/interface.c
> @@ -381,10 +381,9 @@ static int map_frontend_pages(struct xen
>  	gnttab_set_map_op(&op, (unsigned long)comms->ring_area->addr,
>  			  GNTMAP_host_map, ring_ref, domid);
>      
> -	if (HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, &op, 1))
> -		BUG();
> +	gnttab_check_GNTST_eagain_do_while(GNTTABOP_map_grant_ref, &op);
>  
> -	if (op.status) {
> +	if (op.status != GNTST_okay) {
>  		DPRINTK(" Gnttab failure mapping ring_ref!\n");
>  		free_vm_area(comms->ring_area);
>  		return op.status;
> diff -r df9e25a0189b -r 1170bc32db41 drivers/xen/netback/netback.c
> --- a/drivers/xen/netback/netback.c
> +++ b/drivers/xen/netback/netback.c
> @@ -419,11 +419,13 @@ static int netbk_check_gop(int nr_copy_s
>  
>  	for (i = 0; i < nr_copy_slots; i++) {
>  		copy_op = npo->copy + npo->copy_cons++;
> +		if (copy_op->status == GNTST_eagain)
> +			gnttab_check_GNTST_eagain_while(GNTTABOP_copy, copy_op);
>  		if (copy_op->status != GNTST_okay) {
> -				DPRINTK("Bad status %d from copy to DOM%d.\n",
> -					copy_op->status, domid);
> -				status = NETIF_RSP_ERROR;
> -			}
> +			DPRINTK("Bad status %d from copy to DOM%d.\n",
> +				copy_op->status, domid);
> +			status = NETIF_RSP_ERROR;
> +		}
>  	}
>  
>  	return status;
> @@ -1020,7 +1022,11 @@ static int netbk_tx_check_mop(struct xen
>  
>  	/* Check status of header. */
>  	err = mop->status;
> -	if (unlikely(err)) {
> +	if (err == GNTST_eagain) {
> +		gnttab_check_GNTST_eagain_do_while(GNTTABOP_map_grant_ref, mop);
> +		err = mop->status;
> +	}
> +	if (unlikely(err != GNTST_okay)) {
>  		pending_ring_idx_t index;
>  		index = pending_index(netbk->pending_prod++);
>  		txp = &pending_tx_info[pending_idx].req;
> diff -r df9e25a0189b -r 1170bc32db41 drivers/xen/scsiback/interface.c
> --- a/drivers/xen/scsiback/interface.c
> +++ b/drivers/xen/scsiback/interface.c
> @@ -69,18 +69,18 @@ static int map_frontend_page( struct vsc
>  				GNTMAP_host_map, ring_ref,
>  				info->domid);
>  
> -	err = HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, &op, 1);
> -	BUG_ON(err);
> +	gnttab_check_GNTST_eagain_do_while(GNTTABOP_map_grant_ref, &op);
>  
> -	if (op.status) {
> -		printk(KERN_ERR "scsiback: Grant table operation failure !\n");
> +	if (op.status != GNTST_okay) {
> +		printk(KERN_ERR "scsiback: Grant table operation failure %d!\n", 
> +							(int) op.status);
>  		return op.status;
>  	}
>  
>  	info->shmem_ref    = ring_ref;
>  	info->shmem_handle = op.handle;
>  
> -	return (GNTST_okay);
> +	return 0;
>  }
>  
>  static void unmap_frontend_page(struct vscsibk_info *info)
> diff -r df9e25a0189b -r 1170bc32db41 drivers/xen/scsiback/scsiback.c
> --- a/drivers/xen/scsiback/scsiback.c
> +++ b/drivers/xen/scsiback/scsiback.c
> @@ -287,7 +287,9 @@ static int scsiback_gnttab_data_map(vscs
>  		for_each_sg (pending_req->sgl, sg, nr_segments, i) {
>  			struct page *pg;
>  
> -			if (unlikely(map[i].status != 0)) {
> +			if (unlikely(map[i].status == GNTST_eagain))
> +				gnttab_check_GNTST_eagain_while(GNTTABOP_map_grant_ref, &map[i]);
> +			if (unlikely(map[i].status != GNTST_okay)) {
>  				printk(KERN_ERR "scsiback: invalid buffer -- could not remap it\n");
>  				map[i].handle = SCSIBACK_INVALID_HANDLE;
>  				err |= 1;
> diff -r df9e25a0189b -r 1170bc32db41 drivers/xen/tpmback/interface.c
> --- a/drivers/xen/tpmback/interface.c
> +++ b/drivers/xen/tpmback/interface.c
> @@ -86,11 +86,10 @@ static int map_frontend_page(tpmif_t *tp
>  	gnttab_set_map_op(&op, (unsigned long)tpmif->tx_area->addr,
>  			  GNTMAP_host_map, shared_page, tpmif->domid);
>  
> -	if (HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, &op, 1))
> -		BUG();
> +	gnttab_check_GNTST_eagain_do_while(GNTTABOP_map_grant_ref, &op);
>  
> -	if (op.status) {
> -		DPRINTK(" Grant table operation failure !\n");
> +	if (op.status != GNTST_okay) {
> +		DPRINTK(" Grant table operation failure %d!\n", (int) op.status);
>  		return op.status;
>  	}
>  
> diff -r df9e25a0189b -r 1170bc32db41 drivers/xen/tpmback/tpmback.c
> --- a/drivers/xen/tpmback/tpmback.c
> +++ b/drivers/xen/tpmback/tpmback.c
> @@ -256,15 +256,13 @@ int _packet_write(struct packet *pak,
>  		gnttab_set_map_op(&map_op, idx_to_kaddr(tpmif, i),
>  				  GNTMAP_host_map, tx->ref, tpmif->domid);
>  
> -		if (unlikely(HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref,
> -						       &map_op, 1))) {
> -			BUG();
> -		}
> +		gnttab_check_GNTST_eagain_do_while(GNTTABOP_map_grant_ref, &map_op);
>  
>  		handle = map_op.handle;
>  
> -		if (map_op.status) {
> -			DPRINTK(" Grant table operation failure !\n");
> +		if (map_op.status != GNTST_okay) {
> +			DPRINTK(" Grant table operation failure %d!\n", 
> +						(int) map_op.status);
>  			return 0;
>  		}
>  
> @@ -394,13 +392,11 @@ static int packet_read_shmem(struct pack
>  		gnttab_set_map_op(&map_op, idx_to_kaddr(tpmif, i),
>  				  GNTMAP_host_map, tx->ref, tpmif->domid);
>  
> -		if (unlikely(HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref,
> -						       &map_op, 1))) {
> -			BUG();
> -		}
> +		gnttab_check_GNTST_eagain_do_while(GNTTABOP_map_grant_ref, &map_op);
>  
> -		if (map_op.status) {
> -			DPRINTK(" Grant table operation failure !\n");
> +		if (map_op.status != GNTST_okay) {
> +			DPRINTK(" Grant table operation failure %d!\n",
> +						(int) map_op.status);
>  			return -EFAULT;
>  		}
>  
> diff -r df9e25a0189b -r 1170bc32db41 drivers/xen/usbback/interface.c
> --- a/drivers/xen/usbback/interface.c
> +++ b/drivers/xen/usbback/interface.c
> @@ -109,11 +109,11 @@ static int map_frontend_pages(usbif_t *u
>  	gnttab_set_map_op(&op, (unsigned long)usbif->urb_ring_area->addr,
>  			  GNTMAP_host_map, urb_ring_ref, usbif->domid);
>  
> -	if (HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, &op, 1))
> -		BUG();
> +	gnttab_check_GNTST_eagain_do_while(GNTTABOP_map_grant_ref, &op);
>  
> -	if (op.status) {
> -		printk(KERN_ERR "grant table failure mapping urb_ring_ref\n");
> +	if (op.status != GNTST_okay) {
> +		printk(KERN_ERR "grant table failure mapping urb_ring_ref %d\n",
> +							(int) op.status);
>  		return op.status;
>  	}
>  
> @@ -123,17 +123,17 @@ static int map_frontend_pages(usbif_t *u
>  	gnttab_set_map_op(&op, (unsigned long)usbif->conn_ring_area->addr,
>  			  GNTMAP_host_map, conn_ring_ref, usbif->domid);
>  
> -	if (HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, &op, 1))
> -		BUG();
> +	gnttab_check_GNTST_eagain_do_while(GNTTABOP_map_grant_ref, &op);
>  
> -	if (op.status) {
> +	if (op.status != GNTST_okay) {
>  		struct gnttab_unmap_grant_ref unop;
>  		gnttab_set_unmap_op(&unop,
>  				(unsigned long) usbif->urb_ring_area->addr,
>  				GNTMAP_host_map, usbif->urb_shmem_handle);
>  		VOID(HYPERVISOR_grant_table_op(GNTTABOP_unmap_grant_ref, &unop,
>  				1));
> -		printk(KERN_ERR "grant table failure mapping conn_ring_ref\n");
> +		printk(KERN_ERR "grant table failure mapping conn_ring_ref %d\n",
> +							(int) op.status);
>  		return op.status;
>  	}
>  
> diff -r df9e25a0189b -r 1170bc32db41 drivers/xen/usbback/usbback.c
> --- a/drivers/xen/usbback/usbback.c
> +++ b/drivers/xen/usbback/usbback.c
> @@ -428,7 +428,9 @@ static int usbbk_gnttab_map(usbif_t *usb
>  		BUG_ON(ret);
>  
>  		for (i = 0; i < nr_segs; i++) {
> -			if (unlikely(map[i].status != 0)) {
> +			if (unlikely(map[i].status == GNTST_eagain))
> +				gnttab_check_GNTST_eagain_while(GNTTABOP_map_grant_ref, &map[i]);
> +			if (unlikely(map[i].status != GNTST_okay)) {
>  				printk(KERN_ERR "usbback: invalid buffer -- could not remap it\n");
>  				map[i].handle = USBBACK_INVALID_HANDLE;
>  				ret |= 1;
> diff -r df9e25a0189b -r 1170bc32db41 drivers/xen/xenbus/xenbus_backend_client.c
> --- a/drivers/xen/xenbus/xenbus_backend_client.c
> +++ b/drivers/xen/xenbus/xenbus_backend_client.c
> @@ -48,8 +48,7 @@ struct vm_struct *xenbus_map_ring_valloc
>  	gnttab_set_map_op(&op, (unsigned long)area->addr, GNTMAP_host_map,
>  			  gnt_ref, dev->otherend_id);
>  	
> -	if (HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, &op, 1))
> -		BUG();
> +	gnttab_check_GNTST_eagain_do_while(GNTTABOP_map_grant_ref, &op);
>  
>  	if (op.status != GNTST_okay) {
>  		free_vm_area(area);
> @@ -75,15 +74,16 @@ int xenbus_map_ring(struct xenbus_device
>  	
>  	gnttab_set_map_op(&op, (unsigned long)vaddr, GNTMAP_host_map,
>  			  gnt_ref, dev->otherend_id);
> -	if (HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, &op, 1))
> -		BUG();
> +	gnttab_check_GNTST_eagain_do_while(GNTTABOP_map_grant_ref, &op);
>  
>  	if (op.status != GNTST_okay) {
>  		xenbus_dev_fatal(dev, op.status,
>  				 "mapping in shared page %d from domain %d",
>  				 gnt_ref, dev->otherend_id);
> -	} else
> +	} else {
>  		*handle = op.handle;
> +		return 0;
> +	}
>  
>  	return op.status;
>  }
> diff -r df9e25a0189b -r 1170bc32db41 include/xen/gnttab.h
> --- a/include/xen/gnttab.h
> +++ b/include/xen/gnttab.h
> @@ -187,4 +187,41 @@ gnttab_set_replace_op(struct gnttab_unma
>  	unmap->handle = handle;
>  }
>  
> +#define gnttab_check_GNTST_eagain_while(__HCop, __HCarg_p)					\
> +do {																		\
> +	u8 __hc_delay = 1;														\
> +	int __ret;																\
> +	while (unlikely((__HCarg_p)->status == GNTST_eagain && __hc_delay)) {	\
> +		msleep(__hc_delay++);												\
> +		__ret = HYPERVISOR_grant_table_op(__HCop, (__HCarg_p), 1);			\
> +		BUG_ON(__ret);														\
> +	}																		\
> +	if (__hc_delay == 0) {													\
> +		printk(KERN_ERR "%s: %s gnt busy\n", __func__, current->comm);		\
> +		(__HCarg_p)->status = GNTST_bad_page;								\
> +	}																		\
> +	if ((__HCarg_p)->status != GNTST_okay)									\
> +		printk(KERN_ERR "%s: %s gnt status %x\n", 							\
> +			__func__, current->comm, (__HCarg_p)->status);					\
> +} while(0)
> +
> +#define gnttab_check_GNTST_eagain_do_while(__HCop, __HCarg_p)			\
> +do {																	\
> +	u8 __hc_delay = 1;													\
> +	int __ret;															\
> +	do {																\
> +		__ret = HYPERVISOR_grant_table_op(__HCop, (__HCarg_p), 1);		\
> +		BUG_ON(__ret);													\
> +		if ((__HCarg_p)->status == GNTST_eagain)						\
> +			msleep(__hc_delay++);										\
> +	} while ((__HCarg_p)->status == GNTST_eagain && __hc_delay);		\
> +	if (__hc_delay == 0) {												\
> +		printk(KERN_ERR "%s: %s gnt busy\n", __func__, current->comm);	\
> +		(__HCarg_p)->status = GNTST_bad_page;							\
> +	}																	\
> +	if ((__HCarg_p)->status != GNTST_okay)								\
> +		printk(KERN_ERR "%s: %s gnt status %x\n", 						\
> +			__func__, current->comm, (__HCarg_p)->status);				\
> +} while(0)
> +
>  #endif /* __ASM_GNTTAB_H__ */
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

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

From xen-devel-bounces@lists.xensource.com Fri Dec 02 03:13:12 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 03: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.xensource.com>)
	id 1RWJY5-0001fQ-E5; Fri, 02 Dec 2011 03:12:29 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <haitao.shan@intel.com>) id 1RWJY3-0001fL-Jl
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 03:12:28 +0000
X-Env-Sender: haitao.shan@intel.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1322795505!5568528!1
X-Originating-IP: [134.134.136.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjQgPT4gMzIwNzky\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12490 invoked from network); 2 Dec 2011 03:11:46 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-3.tower-182.messagelabs.com with SMTP;
	2 Dec 2011 03:11:46 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga102.jf.intel.com with ESMTP; 01 Dec 2011 19:11:44 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.67,351,1309762800"; 
	d="p7s'?scan'208";a="82370361"
Received: from pgsmsx603.gar.corp.intel.com ([10.221.43.87])
	by orsmga002.jf.intel.com with ESMTP; 01 Dec 2011 19:11:43 -0800
Received: from pgsmsx103.gar.corp.intel.com (10.221.44.82) by
	pgsmsx603.gar.corp.intel.com (10.221.43.87) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Fri, 2 Dec 2011 11:11:35 +0800
Received: from shsmsx601.ccr.corp.intel.com (10.239.4.112) by
	PGSMSX103.gar.corp.intel.com (10.221.44.82) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Fri, 2 Dec 2011 11:11:34 +0800
Received: from shsmsx502.ccr.corp.intel.com ([10.239.4.96]) by
	shsmsx601.ccr.corp.intel.com ([10.239.4.112]) with mapi; Fri, 2 Dec 2011
	11:11:33 +0800
From: "Shan, Haitao" <haitao.shan@intel.com>
To: =?iso-8859-1?Q?Pasi_K=E4rkk=E4inen?= <pasik@iki.fi>
Date: Fri, 2 Dec 2011 11:11:33 +0800
Thread-Topic: [Xen-devel] [PATCH] vvmx: fix intended assignment
Thread-Index: AcywU/8uhmslOhcbQcSuT7z30TPavwATADww
Message-ID: <04F972F38B3C4E4E91C4697DA8BF9F528435894601@shsmsx502.ccr.corp.intel.com>
References: <4ED76A350200007800064ABD@nat28.tlf.novell.com>
	<04F972F38B3C4E4E91C4697DA8BF9F5284357D52A6@shsmsx502.ccr.corp.intel.com>
	<20111201180641.GG12984@reaktio.net>
In-Reply-To: <20111201180641.GG12984@reaktio.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Dong,
	Eddie" <eddie.dong@intel.com>, Tim Deegan <Tim.Deegan@citrix.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH] vvmx: fix intended assignment
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3345055476710168553=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============3345055476710168553==
Content-Language: en-US
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature";
	micalg=SHA1; boundary="----=_NextPart_000_00B9_01CCB0E3.266E0130"

------=_NextPart_000_00B9_01CCB0E3.266E0130
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

You can still contact Dong Eddie for nested virtualization topics.

Shan Haitao

> -----Original Message-----
> From: Pasi K=E4rkk=E4inen [mailto:pasik@iki.fi]
> Sent: Friday, December 02, 2011 2:07 AM
> To: Shan, Haitao
> Cc: Jan Beulich; xen-devel@lists.xensource.com; Dong, Eddie; Tim =
Deegan;
> He, Qing
> Subject: Re: [Xen-devel] [PATCH] vvmx: fix intended assignment
>=20
> On Thu, Dec 01, 2011 at 07:19:58PM +0800, Shan, Haitao wrote:
> > Hi, Jan,
> >
>=20
> Hello,
>=20
> > I think you cannot cc He Qing any more. As He Qing (who had done =
some
> > work on nested) has left Intel, while this email address is going to
> > another people who just has the same name.
> >
>=20
> Is there anyone from Intel currently working on nested virt?
>=20
> -- Pasi
>=20
> > Shan Haitao
> >
> > > -----Original Message-----
> > > From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-
> > > bounces@lists.xensource.com] On Behalf Of Jan Beulich
> > > Sent: Thursday, December 01, 2011 6:51 PM
> > > To: xen-devel@lists.xensource.com
> > > Cc: Dong, Eddie; Tim Deegan; He, Qing
> > > Subject: [Xen-devel] [PATCH] vvmx: fix intended assignment
> > >
> > > From what I can tell, this was supposed to be an assignment (not
> > > warned about by the compiler due to -Wno-unused, which is about to =
be
> removed).
> > >
> > > Signed-off-by: Jan Beulich <jbeulich@suse.com>
> > >
> > > --- a/xen/arch/x86/hvm/vmx/vvmx.c
> > > +++ b/xen/arch/x86/hvm/vmx/vvmx.c
> > > @@ -581,7 +581,7 @@ static void nvmx_purge_vvmcs(struct vcpu
> > >      __clear_current_vvmcs(v);
> > >      if ( nvcpu->nv_vvmcxaddr !=3D VMCX_EADDR )
> > >          hvm_unmap_guest_frame(nvcpu->nv_vvmcx);
> > > -    nvcpu->nv_vvmcx =3D=3D NULL;
> > > +    nvcpu->nv_vvmcx =3D NULL;
> > >      nvcpu->nv_vvmcxaddr =3D VMCX_EADDR;
> > >      for (i=3D0; i<2; i++) {
> > >          if ( nvmx->iobitmap[i] ) {
> > >
> > >
> >
>=20
>=20
>=20
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xensource.com
> > http://lists.xensource.com/xen-devel


------=_NextPart_000_00B9_01CCB0E3.266E0130
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIYUDCCAyAw
ggKJoAMCAQICBDXe9M8wDQYJKoZIhvcNAQEFBQAwTjELMAkGA1UEBhMCVVMxEDAOBgNVBAoTB0Vx
dWlmYXgxLTArBgNVBAsTJEVxdWlmYXggU2VjdXJlIENlcnRpZmljYXRlIEF1dGhvcml0eTAeFw05
ODA4MjIxNjQxNTFaFw0xODA4MjIxNjQxNTFaME4xCzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVp
ZmF4MS0wKwYDVQQLEyRFcXVpZmF4IFNlY3VyZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwgZ8wDQYJ
KoZIhvcNAQEBBQADgY0AMIGJAoGBAMFdsVhnCGLuoJotHwhtkRRomAoe/toEbxOEYiHD0XzOnwXg
uAHwTjTs4oqVBGSs8WtTXwWzy2eAv0ICjv7dAQns4QAUT/z78AzdQ7pbK+EfgHCZFVeTFvEPl2q3
wmgjHMxNWTCsUR47ryvW7mNFe8XZX1DS41APOojnvxT94Me5AgMBAAGjggEJMIIBBTBwBgNVHR8E
aTBnMGWgY6BhpF8wXTELMAkGA1UEBhMCVVMxEDAOBgNVBAoTB0VxdWlmYXgxLTArBgNVBAsTJEVx
dWlmYXggU2VjdXJlIENlcnRpZmljYXRlIEF1dGhvcml0eTENMAsGA1UEAxMEQ1JMMTAaBgNVHRAE
EzARgQ8yMDE4MDgyMjE2NDE1MVowCwYDVR0PBAQDAgEGMB8GA1UdIwQYMBaAFEjmaPkr0rKV10fY
IyAQTzOYkJ/UMB0GA1UdDgQWBBRI5mj5K9KylddH2CMgEE8zmJCf1DAMBgNVHRMEBTADAQH/MBoG
CSqGSIb2fQdBAAQNMAsbBVYzLjBjAwIGwDANBgkqhkiG9w0BAQUFAAOBgQBYzinq/Pfetc4CuRe1
hdG54+CVzCUxDQCmkm5/tpJjnlCV0Zpv5BHeY4VumO6o/1rI01WyZnFX3sAh6z0qpyNJAQSGQnv8
7n+iFlK1Z2fTQNs7JliyKHc9rhR3Ydb6KmYnoA36p3Nc6nDxlCFlRF/6/O8paKmih3nvee9PrAd3
ODCCAz0wggKmoAMCAQICAwWw/zANBgkqhkiG9w0BAQUFADBOMQswCQYDVQQGEwJVUzEQMA4GA1UE
ChMHRXF1aWZheDEtMCsGA1UECxMkRXF1aWZheCBTZWN1cmUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5
MB4XDTA2MDIxNjE4MDEzMFoXDTE2MDIxOTE4MDEzMFowUjELMAkGA1UEBhMCVVMxGjAYBgNVBAoT
EUludGVsIENvcnBvcmF0aW9uMScwJQYDVQQDEx5JbnRlbCBFeHRlcm5hbCBCYXNpYyBQb2xpY3kg
Q0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDBpd/XOb9QVqEZ8mQ1042TdOIq3ATD
IsV2xDyt30yLyMR5Wjtus0bn3B+he89BiNO/LP6+rFzEwlD55PlX+HLGIKeNNG97dqyc30FElEUj
ZzTZFq2N4e3kVJ/XAEEgANzV8v9qp7qWwxugPgfc3z9BkYot+CifozexHLb/hEZj+yISCU61kRZv
uSQ0E11yYL4dRgcglJeaHo3oX57rvIckaLsYV5/1Aj+R8DM1Ppk965XQAKsHfnyT7C4S50T4lVn4
lz36wOdNZn/zegG1zp41lnoTFfT4KuKVJH5x7YD1p6KbgJCKLovnujGuohquBNfdXKpZkvz6pGv+
iC1HawJdAgMBAAGjgaAwgZ0wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBQaxgxKxEdvqNutK/D0
Vgaj7TdUDDA6BgNVHR8EMzAxMC+gLaArhilodHRwOi8vY3JsLmdlb3RydXN0LmNvbS9jcmxzL3Nl
Y3VyZWNhLmNybDAfBgNVHSMEGDAWgBRI5mj5K9KylddH2CMgEE8zmJCf1DAPBgNVHRMBAf8EBTAD
AQH/MA0GCSqGSIb3DQEBBQUAA4GBABMQOK2kVKVIlUWwLTdywJ+e2O+PC/uQltK2F3lRyrPfBn69
tOkIP4SgDJOfsxyobIrPLe75kBLw+Dom13OBDp/EMZJZ1CglQfVV8co9mT3aZMjSGGQiMgkJLR3j
Mfr900fXZKj5XeqCJ+JP0mEhJGEdVCY+FFlksJjV86fDrq1QMIIFijCCBHKgAwIBAgIKYSCKYgAA
AAAACDANBgkqhkiG9w0BAQUFADBSMQswCQYDVQQGEwJVUzEaMBgGA1UEChMRSW50ZWwgQ29ycG9y
YXRpb24xJzAlBgNVBAMTHkludGVsIEV4dGVybmFsIEJhc2ljIFBvbGljeSBDQTAeFw0wOTA1MTUx
OTI3MjZaFw0xNTA1MTUxOTM3MjZaMFYxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFJbnRlbCBDb3Jw
b3JhdGlvbjErMCkGA1UEAxMiSW50ZWwgRXh0ZXJuYWwgQmFzaWMgSXNzdWluZyBDQSAzQjCCASIw
DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKQEM1Wn9TU9vc9C+/Tc7KB+eiYElmrcEWE32WUd
HvWG+IcQHVQsikTmMyKKojNLw2B5s6Iekc8ivDo/wCfjZzX9JyftMnc+AArc0la87Olybzm8K9jX
EfTBvTnUSFSiI9ZYefITdiUgqlAFuljFZEHYKYtLuhrRacpmQfP4mV63NKdc2bT804HRf6YptZFa
4k6YN94zlrGNrBuQQ74WFzz/jLBusbUpEkro6Mu/ZYFOFWQrV9lBhF9Ruk8yN+3N6n9fUo/qBigi
F2kEn9xVh1ykl7SCGL2jBUkXx4qgV27a6Si8lRRdgrHGtN/HWnSWlLXTH5l575H4Lq++77OFv38C
AwEAAaOCAlwwggJYMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFA7GKvdZsggQkCVvw939imYx
MCvFMAsGA1UdDwQEAwIBhjASBgkrBgEEAYI3FQEEBQIDAQABMCMGCSsGAQQBgjcVAgQWBBQ5oFY2
ekKQ/5Ktim+VdMeSWb4QWTAZBgkrBgEEAYI3FAIEDB4KAFMAdQBiAEMAQTAfBgNVHSMEGDAWgBQa
xgxKxEdvqNutK/D0Vgaj7TdUDDCBvQYDVR0fBIG1MIGyMIGvoIGsoIGphk5odHRwOi8vd3d3Lmlu
dGVsLmNvbS9yZXBvc2l0b3J5L0NSTC9JbnRlbCUyMEV4dGVybmFsJTIwQmFzaWMlMjBQb2xpY3kl
MjBDQS5jcmyGV2h0dHA6Ly9jZXJ0aWZpY2F0ZXMuaW50ZWwuY29tL3JlcG9zaXRvcnkvQ1JML0lu
dGVsJTIwRXh0ZXJuYWwlMjBCYXNpYyUyMFBvbGljeSUyMENBLmNybDCB4wYIKwYBBQUHAQEEgdYw
gdMwYwYIKwYBBQUHMAKGV2h0dHA6Ly93d3cuaW50ZWwuY29tL3JlcG9zaXRvcnkvY2VydGlmaWNh
dGVzL0ludGVsJTIwRXh0ZXJuYWwlMjBCYXNpYyUyMFBvbGljeSUyMENBLmNydDBsBggrBgEFBQcw
AoZgaHR0cDovL2NlcnRpZmljYXRlcy5pbnRlbC5jb20vcmVwb3NpdG9yeS9jZXJ0aWZpY2F0ZXMv
SW50ZWwlMjBFeHRlcm5hbCUyMEJhc2ljJTIwUG9saWN5JTIwQ0EuY3J0MA0GCSqGSIb3DQEBBQUA
A4IBAQCxtQEHchVQhXyjEqtMVUMe6gkmPsIczHxSeqNbo9dsD+6xbT65JT+oYgpIAtfEsYXeUJu1
cChqpb22U5bMAz7eaQcW5bzefufWvA6lg2048B8oczBj/q+5P5NpYrUO8jOmN4jTjfJq3ElZ7yFW
py7rB3Vm/aN6ATYqWfMbS/xfh+JCxmH3droUmMJI0/aZJHsLtjbjFnNsHDNrJZX1vxlM78Lb1hjs
kTENPmhbVbfTj5i/ZGnhv4tmI8QZPCNtcegXJrfhRl2D9bWpdTOPrWiLDUqzy1Z6KL7TcOS/PCl8
RHCJXkPau/thTQCpIoDa2+c+3XA++gRTfAQ4svTO260NMIIGBzCCBO+gAwIBAgIKEx06gQABAAB7
rTANBgkqhkiG9w0BAQUFADBWMQswCQYDVQQGEwJVUzEaMBgGA1UEChMRSW50ZWwgQ29ycG9yYXRp
b24xKzApBgNVBAMTIkludGVsIEV4dGVybmFsIEJhc2ljIElzc3VpbmcgQ0EgM0IwHhcNMTExMDEy
MDEyNDIwWhcNMTQwOTI2MDEyNDIwWjA9MRUwEwYDVQQDEwxTaGFuLCBIYWl0YW8xJDAiBgkqhkiG
9w0BCQEWFWhhaXRhby5zaGFuQGludGVsLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC
ggEBALpHYbXkMy06K6Pl9IGxbsKl0zT/OYd523Rh3CX7tHG/80ZGcPeLlzFK+l+30Fhpzf8fsFwG
l5fX2pRtWqT96BUWecXEVJhisfa1Wrq7DBC6coxEnExFADU+2UsBQ/ACKFSCiq/fADojyFWJgPKv
4PLDKJ9LU23Q+g1WRruGHfBnhCMv0KxnkE7pTk3cFRXtNUSUnYLqcvrZwt9VogQNiNNw3jMlDb8t
bJjMsXdhrwqFGW49z/gAJ2Mnr6/lNnqBdcKF2Qm28SfYXRohGrmam3KReM49ZG0+J/+JPF5drbiw
UAV++PMHA3IXIvZF2c66jQM5BzbF93SkoZXmrQZA2jMCAwEAAaOCAu4wggLqMAsGA1UdDwQEAwIH
gDA8BgkrBgEEAYI3FQcELzAtBiUrBgEEAYI3FQiGw4x1hJnlUYP9gSiFjp9TgpHACWeB3r05lfBD
AgFkAgEIMB0GA1UdDgQWBBQ/OInBCgrko9ziRWiEhjM+SyeeoDAfBgNVHSMEGDAWgBQOxir3WbII
EJAlb8Pd/YpmMTArxTCBzwYDVR0fBIHHMIHEMIHBoIG+oIG7hldodHRwOi8vd3d3LmludGVsLmNv
bS9yZXBvc2l0b3J5L0NSTC9JbnRlbCUyMEV4dGVybmFsJTIwQmFzaWMlMjBJc3N1aW5nJTIwQ0El
MjAzQigxKS5jcmyGYGh0dHA6Ly9jZXJ0aWZpY2F0ZXMuaW50ZWwuY29tL3JlcG9zaXRvcnkvQ1JM
L0ludGVsJTIwRXh0ZXJuYWwlMjBCYXNpYyUyMElzc3VpbmclMjBDQSUyMDNCKDEpLmNybDCB9QYI
KwYBBQUHAQEEgegwgeUwbAYIKwYBBQUHMAKGYGh0dHA6Ly93d3cuaW50ZWwuY29tL3JlcG9zaXRv
cnkvY2VydGlmaWNhdGVzL0ludGVsJTIwRXh0ZXJuYWwlMjBCYXNpYyUyMElzc3VpbmclMjBDQSUy
MDNCKDEpLmNydDB1BggrBgEFBQcwAoZpaHR0cDovL2NlcnRpZmljYXRlcy5pbnRlbC5jb20vcmVw
b3NpdG9yeS9jZXJ0aWZpY2F0ZXMvSW50ZWwlMjBFeHRlcm5hbCUyMEJhc2ljJTIwSXNzdWluZyUy
MENBJTIwM0IoMSkuY3J0MB8GA1UdJQQYMBYGCCsGAQUFBwMEBgorBgEEAYI3CgMMMCkGCSsGAQQB
gjcVCgQcMBowCgYIKwYBBQUHAwQwDAYKKwYBBAGCNwoDDDBHBgNVHREEQDA+oCUGCisGAQQBgjcU
AgOgFwwVaGFpdGFvLnNoYW5AaW50ZWwuY29tgRVoYWl0YW8uc2hhbkBpbnRlbC5jb20wDQYJKoZI
hvcNAQEFBQADggEBAG5Us26ruu8jKt3RhZuirjqgF61p+wZer/xV6BTABUx5++DhWXslTztavsvy
JZ5WsZ7xaijBUO3UQViWTylwmSyGwbhEwreu3XRNGlMOnRk+sH7JGiXZJIpqoD/jtRWp0ypHG2g3
nDqAQ1/j4wUgcI0b12KUJyYAeN6cwEeAqIV4mdD8GpH3DS2nZbEZjTNhkaeJuT7lO1jRqzEGOSCk
KDHPfqUtqpw+wZa6mFbzSso9swc4ypgRIl4l5i/4OwNMQazHm2O6Ov91aDJs6j3DCdALzP736hmF
QFfHWL34GFQMRdpO/OI6z/Q0VYm/6N9o4SD/s4J9Edq8zyYNQxBR03QwggZOMIIFNqADAgECAgoT
I00xAAEAAHuuMA0GCSqGSIb3DQEBBQUAMFYxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFJbnRlbCBD
b3Jwb3JhdGlvbjErMCkGA1UEAxMiSW50ZWwgRXh0ZXJuYWwgQmFzaWMgSXNzdWluZyBDQSAzQjAe
Fw0xMTEwMTIwMTMwNTZaFw0xNDA5MjYwMTMwNTZaMD0xFTATBgNVBAMTDFNoYW4sIEhhaXRhbzEk
MCIGCSqGSIb3DQEJARYVaGFpdGFvLnNoYW5AaW50ZWwuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOC
AQ8AMIIBCgKCAQEApaOcuQtYCobUiLQTadd0Hi+U/ausgzeSE59iUrc57VUzvLsLNnKRxLPm+T26
KN9fMDAS3/MZOl5tf+9mKEwrergim5GzwJpfZWPLAyK2Gs57+F+BMgtX6DT0eh4sGQLQDahPZDhy
Ubo420AiTGuTA9/L22B/qbPNuDRNMMJoreAZeSNBSVPa7Q+Y0oXcfKpAmKzHH2Y+WAzupN5jfxhJ
6yb7MpsPDqoU0Ek4VttgUIl4AQlRFMI18ScKvAG2p9kWSSgq+Z9xdQl7F/3ASkXlQMKEOHCDw8E7
XUzqy4pOoXGaI3FVI4AerPeLgz2SkNINfqLnxdhN+BQ6iuRgsOeyIwIDAQABo4IDNTCCAzEwCwYD
VR0PBAQDAgQwMD0GCSsGAQQBgjcVBwQwMC4GJisGAQQBgjcVCIbDjHWEmeVRg/2BKIWOn1OCkcAJ
Z4S52UGHhP9OAgFkAgEMMEQGCSqGSIb3DQEJDwQ3MDUwDgYIKoZIhvcNAwICAgCAMA4GCCqGSIb3
DQMEAgIAgDAHBgUrDgMCBzAKBggqhkiG9w0DBzAdBgNVHQ4EFgQU/+6IdpvPrUveCml7StYwqL40
iqMwHwYDVR0jBBgwFoAUDsYq91myCBCQJW/D3f2KZjEwK8Uwgc8GA1UdHwSBxzCBxDCBwaCBvqCB
u4ZXaHR0cDovL3d3dy5pbnRlbC5jb20vcmVwb3NpdG9yeS9DUkwvSW50ZWwlMjBFeHRlcm5hbCUy
MEJhc2ljJTIwSXNzdWluZyUyMENBJTIwM0IoMSkuY3JshmBodHRwOi8vY2VydGlmaWNhdGVzLmlu
dGVsLmNvbS9yZXBvc2l0b3J5L0NSTC9JbnRlbCUyMEV4dGVybmFsJTIwQmFzaWMlMjBJc3N1aW5n
JTIwQ0ElMjAzQigxKS5jcmwwgfUGCCsGAQUFBwEBBIHoMIHlMGwGCCsGAQUFBzAChmBodHRwOi8v
d3d3LmludGVsLmNvbS9yZXBvc2l0b3J5L2NlcnRpZmljYXRlcy9JbnRlbCUyMEV4dGVybmFsJTIw
QmFzaWMlMjBJc3N1aW5nJTIwQ0ElMjAzQigxKS5jcnQwdQYIKwYBBQUHMAKGaWh0dHA6Ly9jZXJ0
aWZpY2F0ZXMuaW50ZWwuY29tL3JlcG9zaXRvcnkvY2VydGlmaWNhdGVzL0ludGVsJTIwRXh0ZXJu
YWwlMjBCYXNpYyUyMElzc3VpbmclMjBDQSUyMDNCKDEpLmNydDAfBgNVHSUEGDAWBggrBgEFBQcD
BAYKKwYBBAGCNwoDBDApBgkrBgEEAYI3FQoEHDAaMAoGCCsGAQUFBwMEMAwGCisGAQQBgjcKAwQw
RwYDVR0RBEAwPqAlBgorBgEEAYI3FAIDoBcMFWhhaXRhby5zaGFuQGludGVsLmNvbYEVaGFpdGFv
LnNoYW5AaW50ZWwuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQAqWvSRW8jKGuWVwUKo/+QRxKvuT3cv
/975omnwo7QeOj78XruY/Wsl6/tnzI8jgf6ZE5SRoj5sSGBHmy7qHSZNWodLuJgjN+a0Fk2hy0jB
wX2UJLS3ctijemo4e4u8/YFebLVXCzy81lWa7dZcidebnslLlcQXHNzl8hhFAfQwhcCXMAiA89NO
3uJqd9Sk/PSfG90b/f+1u2xIthxQmeh7u1yuiHZrf1u/e6rJWS50iW+LWmrH0c70XN8voHpLXVDo
09C9DETzJOUrhr1BqLVSxKjNn/uhCOcQxNYM3CYsgQBwVogKsGj59xeGFA5iWPKGRj7SfUXH0m3T
kiSaWLnWMYIDhjCCA4ICAQEwZDBWMQswCQYDVQQGEwJVUzEaMBgGA1UEChMRSW50ZWwgQ29ycG9y
YXRpb24xKzApBgNVBAMTIkludGVsIEV4dGVybmFsIEJhc2ljIElzc3VpbmcgQ0EgM0ICChMdOoEA
AQAAe60wCQYFKw4DAhoFAKCCAfcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0B
CQUxDxcNMTExMjAyMDMxMTMzWjAjBgkqhkiG9w0BCQQxFgQUAqmua1PoM3GvLTq611KWFi6AeIUw
cwYJKwYBBAGCNxAEMWYwZDBWMQswCQYDVQQGEwJVUzEaMBgGA1UEChMRSW50ZWwgQ29ycG9yYXRp
b24xKzApBgNVBAMTIkludGVsIEV4dGVybmFsIEJhc2ljIElzc3VpbmcgQ0EgM0ICChMjTTEAAQAA
e64wdQYLKoZIhvcNAQkQAgsxZqBkMFYxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFJbnRlbCBDb3Jw
b3JhdGlvbjErMCkGA1UEAxMiSW50ZWwgRXh0ZXJuYWwgQmFzaWMgSXNzdWluZyBDQSAzQgIKEyNN
MQABAAB7rjCBqwYJKoZIhvcNAQkPMYGdMIGaMAoGCCqGSIb3DQMHMAsGCWCGSAFlAwQBKjALBglg
hkgBZQMEARYwCwYJYIZIAWUDBAECMA4GCCqGSIb3DQMCAgIAgDAHBgUrDgMCBzANBggqhkiG9w0D
AgIBQDANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAsG
CWCGSAFlAwQCATANBgkqhkiG9w0BAQEFAASCAQA7xP9rMz0P654/3DXd52qozlzrpesX5Si6aJ83
u9I7Xc48Mh2ZYZ0zbZkmSebHBf8FaeDqJ/L719NBvsssuaiA48M/KMfAaFWUyssCz4fCChibruIQ
pz1MtXRqLkosvo9uj/xzFhN1+Hn9P3QHK3Y4pCvnbeKhvLRKkFjM6tgG0D2dBHUTDSOKT/ze1VvY
c1k8yR4ygpn2FzsRxHGGnqtEcdqons+HULnXEfTycTk+XlY4Rt6A/GfqOpOCvK6waWPIkzuCIHx5
thk0np0vlodOg2dhqnX2FQx9yhebfYJmIVm80vI6IKBZMTQES8qPPvYWccHFzpJqDVcSg0nFXvUK
AAAAAAAA

------=_NextPart_000_00B9_01CCB0E3.266E0130--


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

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

--===============3345055476710168553==--


From xen-devel-bounces@lists.xensource.com Fri Dec 02 03:13:12 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 03: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.xensource.com>)
	id 1RWJY5-0001fQ-E5; Fri, 02 Dec 2011 03:12:29 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <haitao.shan@intel.com>) id 1RWJY3-0001fL-Jl
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 03:12:28 +0000
X-Env-Sender: haitao.shan@intel.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1322795505!5568528!1
X-Originating-IP: [134.134.136.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjQgPT4gMzIwNzky\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12490 invoked from network); 2 Dec 2011 03:11:46 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-3.tower-182.messagelabs.com with SMTP;
	2 Dec 2011 03:11:46 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga102.jf.intel.com with ESMTP; 01 Dec 2011 19:11:44 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.67,351,1309762800"; 
	d="p7s'?scan'208";a="82370361"
Received: from pgsmsx603.gar.corp.intel.com ([10.221.43.87])
	by orsmga002.jf.intel.com with ESMTP; 01 Dec 2011 19:11:43 -0800
Received: from pgsmsx103.gar.corp.intel.com (10.221.44.82) by
	pgsmsx603.gar.corp.intel.com (10.221.43.87) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Fri, 2 Dec 2011 11:11:35 +0800
Received: from shsmsx601.ccr.corp.intel.com (10.239.4.112) by
	PGSMSX103.gar.corp.intel.com (10.221.44.82) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Fri, 2 Dec 2011 11:11:34 +0800
Received: from shsmsx502.ccr.corp.intel.com ([10.239.4.96]) by
	shsmsx601.ccr.corp.intel.com ([10.239.4.112]) with mapi; Fri, 2 Dec 2011
	11:11:33 +0800
From: "Shan, Haitao" <haitao.shan@intel.com>
To: =?iso-8859-1?Q?Pasi_K=E4rkk=E4inen?= <pasik@iki.fi>
Date: Fri, 2 Dec 2011 11:11:33 +0800
Thread-Topic: [Xen-devel] [PATCH] vvmx: fix intended assignment
Thread-Index: AcywU/8uhmslOhcbQcSuT7z30TPavwATADww
Message-ID: <04F972F38B3C4E4E91C4697DA8BF9F528435894601@shsmsx502.ccr.corp.intel.com>
References: <4ED76A350200007800064ABD@nat28.tlf.novell.com>
	<04F972F38B3C4E4E91C4697DA8BF9F5284357D52A6@shsmsx502.ccr.corp.intel.com>
	<20111201180641.GG12984@reaktio.net>
In-Reply-To: <20111201180641.GG12984@reaktio.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Dong,
	Eddie" <eddie.dong@intel.com>, Tim Deegan <Tim.Deegan@citrix.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH] vvmx: fix intended assignment
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3345055476710168553=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============3345055476710168553==
Content-Language: en-US
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature";
	micalg=SHA1; boundary="----=_NextPart_000_00B9_01CCB0E3.266E0130"

------=_NextPart_000_00B9_01CCB0E3.266E0130
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

You can still contact Dong Eddie for nested virtualization topics.

Shan Haitao

> -----Original Message-----
> From: Pasi K=E4rkk=E4inen [mailto:pasik@iki.fi]
> Sent: Friday, December 02, 2011 2:07 AM
> To: Shan, Haitao
> Cc: Jan Beulich; xen-devel@lists.xensource.com; Dong, Eddie; Tim =
Deegan;
> He, Qing
> Subject: Re: [Xen-devel] [PATCH] vvmx: fix intended assignment
>=20
> On Thu, Dec 01, 2011 at 07:19:58PM +0800, Shan, Haitao wrote:
> > Hi, Jan,
> >
>=20
> Hello,
>=20
> > I think you cannot cc He Qing any more. As He Qing (who had done =
some
> > work on nested) has left Intel, while this email address is going to
> > another people who just has the same name.
> >
>=20
> Is there anyone from Intel currently working on nested virt?
>=20
> -- Pasi
>=20
> > Shan Haitao
> >
> > > -----Original Message-----
> > > From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-
> > > bounces@lists.xensource.com] On Behalf Of Jan Beulich
> > > Sent: Thursday, December 01, 2011 6:51 PM
> > > To: xen-devel@lists.xensource.com
> > > Cc: Dong, Eddie; Tim Deegan; He, Qing
> > > Subject: [Xen-devel] [PATCH] vvmx: fix intended assignment
> > >
> > > From what I can tell, this was supposed to be an assignment (not
> > > warned about by the compiler due to -Wno-unused, which is about to =
be
> removed).
> > >
> > > Signed-off-by: Jan Beulich <jbeulich@suse.com>
> > >
> > > --- a/xen/arch/x86/hvm/vmx/vvmx.c
> > > +++ b/xen/arch/x86/hvm/vmx/vvmx.c
> > > @@ -581,7 +581,7 @@ static void nvmx_purge_vvmcs(struct vcpu
> > >      __clear_current_vvmcs(v);
> > >      if ( nvcpu->nv_vvmcxaddr !=3D VMCX_EADDR )
> > >          hvm_unmap_guest_frame(nvcpu->nv_vvmcx);
> > > -    nvcpu->nv_vvmcx =3D=3D NULL;
> > > +    nvcpu->nv_vvmcx =3D NULL;
> > >      nvcpu->nv_vvmcxaddr =3D VMCX_EADDR;
> > >      for (i=3D0; i<2; i++) {
> > >          if ( nvmx->iobitmap[i] ) {
> > >
> > >
> >
>=20
>=20
>=20
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xensource.com
> > http://lists.xensource.com/xen-devel


------=_NextPart_000_00B9_01CCB0E3.266E0130
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIYUDCCAyAw
ggKJoAMCAQICBDXe9M8wDQYJKoZIhvcNAQEFBQAwTjELMAkGA1UEBhMCVVMxEDAOBgNVBAoTB0Vx
dWlmYXgxLTArBgNVBAsTJEVxdWlmYXggU2VjdXJlIENlcnRpZmljYXRlIEF1dGhvcml0eTAeFw05
ODA4MjIxNjQxNTFaFw0xODA4MjIxNjQxNTFaME4xCzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVp
ZmF4MS0wKwYDVQQLEyRFcXVpZmF4IFNlY3VyZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwgZ8wDQYJ
KoZIhvcNAQEBBQADgY0AMIGJAoGBAMFdsVhnCGLuoJotHwhtkRRomAoe/toEbxOEYiHD0XzOnwXg
uAHwTjTs4oqVBGSs8WtTXwWzy2eAv0ICjv7dAQns4QAUT/z78AzdQ7pbK+EfgHCZFVeTFvEPl2q3
wmgjHMxNWTCsUR47ryvW7mNFe8XZX1DS41APOojnvxT94Me5AgMBAAGjggEJMIIBBTBwBgNVHR8E
aTBnMGWgY6BhpF8wXTELMAkGA1UEBhMCVVMxEDAOBgNVBAoTB0VxdWlmYXgxLTArBgNVBAsTJEVx
dWlmYXggU2VjdXJlIENlcnRpZmljYXRlIEF1dGhvcml0eTENMAsGA1UEAxMEQ1JMMTAaBgNVHRAE
EzARgQ8yMDE4MDgyMjE2NDE1MVowCwYDVR0PBAQDAgEGMB8GA1UdIwQYMBaAFEjmaPkr0rKV10fY
IyAQTzOYkJ/UMB0GA1UdDgQWBBRI5mj5K9KylddH2CMgEE8zmJCf1DAMBgNVHRMEBTADAQH/MBoG
CSqGSIb2fQdBAAQNMAsbBVYzLjBjAwIGwDANBgkqhkiG9w0BAQUFAAOBgQBYzinq/Pfetc4CuRe1
hdG54+CVzCUxDQCmkm5/tpJjnlCV0Zpv5BHeY4VumO6o/1rI01WyZnFX3sAh6z0qpyNJAQSGQnv8
7n+iFlK1Z2fTQNs7JliyKHc9rhR3Ydb6KmYnoA36p3Nc6nDxlCFlRF/6/O8paKmih3nvee9PrAd3
ODCCAz0wggKmoAMCAQICAwWw/zANBgkqhkiG9w0BAQUFADBOMQswCQYDVQQGEwJVUzEQMA4GA1UE
ChMHRXF1aWZheDEtMCsGA1UECxMkRXF1aWZheCBTZWN1cmUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5
MB4XDTA2MDIxNjE4MDEzMFoXDTE2MDIxOTE4MDEzMFowUjELMAkGA1UEBhMCVVMxGjAYBgNVBAoT
EUludGVsIENvcnBvcmF0aW9uMScwJQYDVQQDEx5JbnRlbCBFeHRlcm5hbCBCYXNpYyBQb2xpY3kg
Q0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDBpd/XOb9QVqEZ8mQ1042TdOIq3ATD
IsV2xDyt30yLyMR5Wjtus0bn3B+he89BiNO/LP6+rFzEwlD55PlX+HLGIKeNNG97dqyc30FElEUj
ZzTZFq2N4e3kVJ/XAEEgANzV8v9qp7qWwxugPgfc3z9BkYot+CifozexHLb/hEZj+yISCU61kRZv
uSQ0E11yYL4dRgcglJeaHo3oX57rvIckaLsYV5/1Aj+R8DM1Ppk965XQAKsHfnyT7C4S50T4lVn4
lz36wOdNZn/zegG1zp41lnoTFfT4KuKVJH5x7YD1p6KbgJCKLovnujGuohquBNfdXKpZkvz6pGv+
iC1HawJdAgMBAAGjgaAwgZ0wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBQaxgxKxEdvqNutK/D0
Vgaj7TdUDDA6BgNVHR8EMzAxMC+gLaArhilodHRwOi8vY3JsLmdlb3RydXN0LmNvbS9jcmxzL3Nl
Y3VyZWNhLmNybDAfBgNVHSMEGDAWgBRI5mj5K9KylddH2CMgEE8zmJCf1DAPBgNVHRMBAf8EBTAD
AQH/MA0GCSqGSIb3DQEBBQUAA4GBABMQOK2kVKVIlUWwLTdywJ+e2O+PC/uQltK2F3lRyrPfBn69
tOkIP4SgDJOfsxyobIrPLe75kBLw+Dom13OBDp/EMZJZ1CglQfVV8co9mT3aZMjSGGQiMgkJLR3j
Mfr900fXZKj5XeqCJ+JP0mEhJGEdVCY+FFlksJjV86fDrq1QMIIFijCCBHKgAwIBAgIKYSCKYgAA
AAAACDANBgkqhkiG9w0BAQUFADBSMQswCQYDVQQGEwJVUzEaMBgGA1UEChMRSW50ZWwgQ29ycG9y
YXRpb24xJzAlBgNVBAMTHkludGVsIEV4dGVybmFsIEJhc2ljIFBvbGljeSBDQTAeFw0wOTA1MTUx
OTI3MjZaFw0xNTA1MTUxOTM3MjZaMFYxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFJbnRlbCBDb3Jw
b3JhdGlvbjErMCkGA1UEAxMiSW50ZWwgRXh0ZXJuYWwgQmFzaWMgSXNzdWluZyBDQSAzQjCCASIw
DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKQEM1Wn9TU9vc9C+/Tc7KB+eiYElmrcEWE32WUd
HvWG+IcQHVQsikTmMyKKojNLw2B5s6Iekc8ivDo/wCfjZzX9JyftMnc+AArc0la87Olybzm8K9jX
EfTBvTnUSFSiI9ZYefITdiUgqlAFuljFZEHYKYtLuhrRacpmQfP4mV63NKdc2bT804HRf6YptZFa
4k6YN94zlrGNrBuQQ74WFzz/jLBusbUpEkro6Mu/ZYFOFWQrV9lBhF9Ruk8yN+3N6n9fUo/qBigi
F2kEn9xVh1ykl7SCGL2jBUkXx4qgV27a6Si8lRRdgrHGtN/HWnSWlLXTH5l575H4Lq++77OFv38C
AwEAAaOCAlwwggJYMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFA7GKvdZsggQkCVvw939imYx
MCvFMAsGA1UdDwQEAwIBhjASBgkrBgEEAYI3FQEEBQIDAQABMCMGCSsGAQQBgjcVAgQWBBQ5oFY2
ekKQ/5Ktim+VdMeSWb4QWTAZBgkrBgEEAYI3FAIEDB4KAFMAdQBiAEMAQTAfBgNVHSMEGDAWgBQa
xgxKxEdvqNutK/D0Vgaj7TdUDDCBvQYDVR0fBIG1MIGyMIGvoIGsoIGphk5odHRwOi8vd3d3Lmlu
dGVsLmNvbS9yZXBvc2l0b3J5L0NSTC9JbnRlbCUyMEV4dGVybmFsJTIwQmFzaWMlMjBQb2xpY3kl
MjBDQS5jcmyGV2h0dHA6Ly9jZXJ0aWZpY2F0ZXMuaW50ZWwuY29tL3JlcG9zaXRvcnkvQ1JML0lu
dGVsJTIwRXh0ZXJuYWwlMjBCYXNpYyUyMFBvbGljeSUyMENBLmNybDCB4wYIKwYBBQUHAQEEgdYw
gdMwYwYIKwYBBQUHMAKGV2h0dHA6Ly93d3cuaW50ZWwuY29tL3JlcG9zaXRvcnkvY2VydGlmaWNh
dGVzL0ludGVsJTIwRXh0ZXJuYWwlMjBCYXNpYyUyMFBvbGljeSUyMENBLmNydDBsBggrBgEFBQcw
AoZgaHR0cDovL2NlcnRpZmljYXRlcy5pbnRlbC5jb20vcmVwb3NpdG9yeS9jZXJ0aWZpY2F0ZXMv
SW50ZWwlMjBFeHRlcm5hbCUyMEJhc2ljJTIwUG9saWN5JTIwQ0EuY3J0MA0GCSqGSIb3DQEBBQUA
A4IBAQCxtQEHchVQhXyjEqtMVUMe6gkmPsIczHxSeqNbo9dsD+6xbT65JT+oYgpIAtfEsYXeUJu1
cChqpb22U5bMAz7eaQcW5bzefufWvA6lg2048B8oczBj/q+5P5NpYrUO8jOmN4jTjfJq3ElZ7yFW
py7rB3Vm/aN6ATYqWfMbS/xfh+JCxmH3droUmMJI0/aZJHsLtjbjFnNsHDNrJZX1vxlM78Lb1hjs
kTENPmhbVbfTj5i/ZGnhv4tmI8QZPCNtcegXJrfhRl2D9bWpdTOPrWiLDUqzy1Z6KL7TcOS/PCl8
RHCJXkPau/thTQCpIoDa2+c+3XA++gRTfAQ4svTO260NMIIGBzCCBO+gAwIBAgIKEx06gQABAAB7
rTANBgkqhkiG9w0BAQUFADBWMQswCQYDVQQGEwJVUzEaMBgGA1UEChMRSW50ZWwgQ29ycG9yYXRp
b24xKzApBgNVBAMTIkludGVsIEV4dGVybmFsIEJhc2ljIElzc3VpbmcgQ0EgM0IwHhcNMTExMDEy
MDEyNDIwWhcNMTQwOTI2MDEyNDIwWjA9MRUwEwYDVQQDEwxTaGFuLCBIYWl0YW8xJDAiBgkqhkiG
9w0BCQEWFWhhaXRhby5zaGFuQGludGVsLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC
ggEBALpHYbXkMy06K6Pl9IGxbsKl0zT/OYd523Rh3CX7tHG/80ZGcPeLlzFK+l+30Fhpzf8fsFwG
l5fX2pRtWqT96BUWecXEVJhisfa1Wrq7DBC6coxEnExFADU+2UsBQ/ACKFSCiq/fADojyFWJgPKv
4PLDKJ9LU23Q+g1WRruGHfBnhCMv0KxnkE7pTk3cFRXtNUSUnYLqcvrZwt9VogQNiNNw3jMlDb8t
bJjMsXdhrwqFGW49z/gAJ2Mnr6/lNnqBdcKF2Qm28SfYXRohGrmam3KReM49ZG0+J/+JPF5drbiw
UAV++PMHA3IXIvZF2c66jQM5BzbF93SkoZXmrQZA2jMCAwEAAaOCAu4wggLqMAsGA1UdDwQEAwIH
gDA8BgkrBgEEAYI3FQcELzAtBiUrBgEEAYI3FQiGw4x1hJnlUYP9gSiFjp9TgpHACWeB3r05lfBD
AgFkAgEIMB0GA1UdDgQWBBQ/OInBCgrko9ziRWiEhjM+SyeeoDAfBgNVHSMEGDAWgBQOxir3WbII
EJAlb8Pd/YpmMTArxTCBzwYDVR0fBIHHMIHEMIHBoIG+oIG7hldodHRwOi8vd3d3LmludGVsLmNv
bS9yZXBvc2l0b3J5L0NSTC9JbnRlbCUyMEV4dGVybmFsJTIwQmFzaWMlMjBJc3N1aW5nJTIwQ0El
MjAzQigxKS5jcmyGYGh0dHA6Ly9jZXJ0aWZpY2F0ZXMuaW50ZWwuY29tL3JlcG9zaXRvcnkvQ1JM
L0ludGVsJTIwRXh0ZXJuYWwlMjBCYXNpYyUyMElzc3VpbmclMjBDQSUyMDNCKDEpLmNybDCB9QYI
KwYBBQUHAQEEgegwgeUwbAYIKwYBBQUHMAKGYGh0dHA6Ly93d3cuaW50ZWwuY29tL3JlcG9zaXRv
cnkvY2VydGlmaWNhdGVzL0ludGVsJTIwRXh0ZXJuYWwlMjBCYXNpYyUyMElzc3VpbmclMjBDQSUy
MDNCKDEpLmNydDB1BggrBgEFBQcwAoZpaHR0cDovL2NlcnRpZmljYXRlcy5pbnRlbC5jb20vcmVw
b3NpdG9yeS9jZXJ0aWZpY2F0ZXMvSW50ZWwlMjBFeHRlcm5hbCUyMEJhc2ljJTIwSXNzdWluZyUy
MENBJTIwM0IoMSkuY3J0MB8GA1UdJQQYMBYGCCsGAQUFBwMEBgorBgEEAYI3CgMMMCkGCSsGAQQB
gjcVCgQcMBowCgYIKwYBBQUHAwQwDAYKKwYBBAGCNwoDDDBHBgNVHREEQDA+oCUGCisGAQQBgjcU
AgOgFwwVaGFpdGFvLnNoYW5AaW50ZWwuY29tgRVoYWl0YW8uc2hhbkBpbnRlbC5jb20wDQYJKoZI
hvcNAQEFBQADggEBAG5Us26ruu8jKt3RhZuirjqgF61p+wZer/xV6BTABUx5++DhWXslTztavsvy
JZ5WsZ7xaijBUO3UQViWTylwmSyGwbhEwreu3XRNGlMOnRk+sH7JGiXZJIpqoD/jtRWp0ypHG2g3
nDqAQ1/j4wUgcI0b12KUJyYAeN6cwEeAqIV4mdD8GpH3DS2nZbEZjTNhkaeJuT7lO1jRqzEGOSCk
KDHPfqUtqpw+wZa6mFbzSso9swc4ypgRIl4l5i/4OwNMQazHm2O6Ov91aDJs6j3DCdALzP736hmF
QFfHWL34GFQMRdpO/OI6z/Q0VYm/6N9o4SD/s4J9Edq8zyYNQxBR03QwggZOMIIFNqADAgECAgoT
I00xAAEAAHuuMA0GCSqGSIb3DQEBBQUAMFYxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFJbnRlbCBD
b3Jwb3JhdGlvbjErMCkGA1UEAxMiSW50ZWwgRXh0ZXJuYWwgQmFzaWMgSXNzdWluZyBDQSAzQjAe
Fw0xMTEwMTIwMTMwNTZaFw0xNDA5MjYwMTMwNTZaMD0xFTATBgNVBAMTDFNoYW4sIEhhaXRhbzEk
MCIGCSqGSIb3DQEJARYVaGFpdGFvLnNoYW5AaW50ZWwuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOC
AQ8AMIIBCgKCAQEApaOcuQtYCobUiLQTadd0Hi+U/ausgzeSE59iUrc57VUzvLsLNnKRxLPm+T26
KN9fMDAS3/MZOl5tf+9mKEwrergim5GzwJpfZWPLAyK2Gs57+F+BMgtX6DT0eh4sGQLQDahPZDhy
Ubo420AiTGuTA9/L22B/qbPNuDRNMMJoreAZeSNBSVPa7Q+Y0oXcfKpAmKzHH2Y+WAzupN5jfxhJ
6yb7MpsPDqoU0Ek4VttgUIl4AQlRFMI18ScKvAG2p9kWSSgq+Z9xdQl7F/3ASkXlQMKEOHCDw8E7
XUzqy4pOoXGaI3FVI4AerPeLgz2SkNINfqLnxdhN+BQ6iuRgsOeyIwIDAQABo4IDNTCCAzEwCwYD
VR0PBAQDAgQwMD0GCSsGAQQBgjcVBwQwMC4GJisGAQQBgjcVCIbDjHWEmeVRg/2BKIWOn1OCkcAJ
Z4S52UGHhP9OAgFkAgEMMEQGCSqGSIb3DQEJDwQ3MDUwDgYIKoZIhvcNAwICAgCAMA4GCCqGSIb3
DQMEAgIAgDAHBgUrDgMCBzAKBggqhkiG9w0DBzAdBgNVHQ4EFgQU/+6IdpvPrUveCml7StYwqL40
iqMwHwYDVR0jBBgwFoAUDsYq91myCBCQJW/D3f2KZjEwK8Uwgc8GA1UdHwSBxzCBxDCBwaCBvqCB
u4ZXaHR0cDovL3d3dy5pbnRlbC5jb20vcmVwb3NpdG9yeS9DUkwvSW50ZWwlMjBFeHRlcm5hbCUy
MEJhc2ljJTIwSXNzdWluZyUyMENBJTIwM0IoMSkuY3JshmBodHRwOi8vY2VydGlmaWNhdGVzLmlu
dGVsLmNvbS9yZXBvc2l0b3J5L0NSTC9JbnRlbCUyMEV4dGVybmFsJTIwQmFzaWMlMjBJc3N1aW5n
JTIwQ0ElMjAzQigxKS5jcmwwgfUGCCsGAQUFBwEBBIHoMIHlMGwGCCsGAQUFBzAChmBodHRwOi8v
d3d3LmludGVsLmNvbS9yZXBvc2l0b3J5L2NlcnRpZmljYXRlcy9JbnRlbCUyMEV4dGVybmFsJTIw
QmFzaWMlMjBJc3N1aW5nJTIwQ0ElMjAzQigxKS5jcnQwdQYIKwYBBQUHMAKGaWh0dHA6Ly9jZXJ0
aWZpY2F0ZXMuaW50ZWwuY29tL3JlcG9zaXRvcnkvY2VydGlmaWNhdGVzL0ludGVsJTIwRXh0ZXJu
YWwlMjBCYXNpYyUyMElzc3VpbmclMjBDQSUyMDNCKDEpLmNydDAfBgNVHSUEGDAWBggrBgEFBQcD
BAYKKwYBBAGCNwoDBDApBgkrBgEEAYI3FQoEHDAaMAoGCCsGAQUFBwMEMAwGCisGAQQBgjcKAwQw
RwYDVR0RBEAwPqAlBgorBgEEAYI3FAIDoBcMFWhhaXRhby5zaGFuQGludGVsLmNvbYEVaGFpdGFv
LnNoYW5AaW50ZWwuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQAqWvSRW8jKGuWVwUKo/+QRxKvuT3cv
/975omnwo7QeOj78XruY/Wsl6/tnzI8jgf6ZE5SRoj5sSGBHmy7qHSZNWodLuJgjN+a0Fk2hy0jB
wX2UJLS3ctijemo4e4u8/YFebLVXCzy81lWa7dZcidebnslLlcQXHNzl8hhFAfQwhcCXMAiA89NO
3uJqd9Sk/PSfG90b/f+1u2xIthxQmeh7u1yuiHZrf1u/e6rJWS50iW+LWmrH0c70XN8voHpLXVDo
09C9DETzJOUrhr1BqLVSxKjNn/uhCOcQxNYM3CYsgQBwVogKsGj59xeGFA5iWPKGRj7SfUXH0m3T
kiSaWLnWMYIDhjCCA4ICAQEwZDBWMQswCQYDVQQGEwJVUzEaMBgGA1UEChMRSW50ZWwgQ29ycG9y
YXRpb24xKzApBgNVBAMTIkludGVsIEV4dGVybmFsIEJhc2ljIElzc3VpbmcgQ0EgM0ICChMdOoEA
AQAAe60wCQYFKw4DAhoFAKCCAfcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0B
CQUxDxcNMTExMjAyMDMxMTMzWjAjBgkqhkiG9w0BCQQxFgQUAqmua1PoM3GvLTq611KWFi6AeIUw
cwYJKwYBBAGCNxAEMWYwZDBWMQswCQYDVQQGEwJVUzEaMBgGA1UEChMRSW50ZWwgQ29ycG9yYXRp
b24xKzApBgNVBAMTIkludGVsIEV4dGVybmFsIEJhc2ljIElzc3VpbmcgQ0EgM0ICChMjTTEAAQAA
e64wdQYLKoZIhvcNAQkQAgsxZqBkMFYxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFJbnRlbCBDb3Jw
b3JhdGlvbjErMCkGA1UEAxMiSW50ZWwgRXh0ZXJuYWwgQmFzaWMgSXNzdWluZyBDQSAzQgIKEyNN
MQABAAB7rjCBqwYJKoZIhvcNAQkPMYGdMIGaMAoGCCqGSIb3DQMHMAsGCWCGSAFlAwQBKjALBglg
hkgBZQMEARYwCwYJYIZIAWUDBAECMA4GCCqGSIb3DQMCAgIAgDAHBgUrDgMCBzANBggqhkiG9w0D
AgIBQDANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAsG
CWCGSAFlAwQCATANBgkqhkiG9w0BAQEFAASCAQA7xP9rMz0P654/3DXd52qozlzrpesX5Si6aJ83
u9I7Xc48Mh2ZYZ0zbZkmSebHBf8FaeDqJ/L719NBvsssuaiA48M/KMfAaFWUyssCz4fCChibruIQ
pz1MtXRqLkosvo9uj/xzFhN1+Hn9P3QHK3Y4pCvnbeKhvLRKkFjM6tgG0D2dBHUTDSOKT/ze1VvY
c1k8yR4ygpn2FzsRxHGGnqtEcdqons+HULnXEfTycTk+XlY4Rt6A/GfqOpOCvK6waWPIkzuCIHx5
thk0np0vlodOg2dhqnX2FQx9yhebfYJmIVm80vI6IKBZMTQES8qPPvYWccHFzpJqDVcSg0nFXvUK
AAAAAAAA

------=_NextPart_000_00B9_01CCB0E3.266E0130--


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

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

--===============3345055476710168553==--


From xen-devel-bounces@lists.xensource.com Fri Dec 02 04:25:07 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 04:25:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWKfj-00028J-6X; Fri, 02 Dec 2011 04:24:27 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RWKfh-00028B-99
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 04:24:25 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1322799822!3935042!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTY3OQ==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31199 invoked from network); 2 Dec 2011 04:23:43 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Dec 2011 04:23:43 -0000
X-IronPort-AV: E=Sophos;i="4.71,281,1320624000"; 
   d="scan'208";a="9241728"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Dec 2011 04:23:42 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 2 Dec 2011 04:23:41 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RWKez-0007er-Iq;
	Fri, 02 Dec 2011 04:23:41 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RWKez-0007i4-AR;
	Fri, 02 Dec 2011 04:23:41 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10231-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 2 Dec 2011 04:23:41 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10231: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

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

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-amd64-xl-win       8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-i386-win-vcpus1    8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-i386-win           8 guest-saverestore         fail REGR. vs. 10201
 test-i386-i386-win            8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-i386-xl-win-vcpus1  8 guest-saverestore        fail REGR. vs. 10201
 test-i386-i386-xl-win         8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-amd64-win          8 guest-saverestore         fail REGR. vs. 10201

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-i386-xend-winxpsp3  7 windows-install              fail  never pass
 test-amd64-amd64-xl-win7-amd64  7 windows-install              fail never pass
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install          fail never pass
 test-amd64-i386-xl-win7-amd64  7 windows-install              fail  never pass
 test-i386-i386-xl-winxpsp3    7 windows-install              fail   never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass

version targeted for testing:
 xen                  3f815406feb2
baseline version:
 xen                  62ff6a318c5d

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Anthony PERARD <anthony.perard@citrix.com>
  Brendan Cully <brendan@cs.ubc.ca>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Jonathan Davies <jonathan.davies@citrix.com>
  juergen.gross@ts.fujitsu.com
  Keir Fraser <keir@xen.org>
  Liu, Jinsong <jinsong.liu@intel.com>
  Olaf Hering <olaf@aepfle.de>
  Philipp Hahn <hahn@univention.de>
  Shriram Rajagopalan <rshriram@cs.ubc.ca>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
------------------------------------------------------------

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


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

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

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


Not pushing.

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

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

From xen-devel-bounces@lists.xensource.com Fri Dec 02 04:25:07 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 04:25:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWKfj-00028J-6X; Fri, 02 Dec 2011 04:24:27 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RWKfh-00028B-99
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 04:24:25 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1322799822!3935042!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTY3OQ==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31199 invoked from network); 2 Dec 2011 04:23:43 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Dec 2011 04:23:43 -0000
X-IronPort-AV: E=Sophos;i="4.71,281,1320624000"; 
   d="scan'208";a="9241728"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Dec 2011 04:23:42 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 2 Dec 2011 04:23:41 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RWKez-0007er-Iq;
	Fri, 02 Dec 2011 04:23:41 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RWKez-0007i4-AR;
	Fri, 02 Dec 2011 04:23:41 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10231-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 2 Dec 2011 04:23:41 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10231: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

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

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-amd64-xl-win       8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-i386-win-vcpus1    8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-i386-win           8 guest-saverestore         fail REGR. vs. 10201
 test-i386-i386-win            8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-i386-xl-win-vcpus1  8 guest-saverestore        fail REGR. vs. 10201
 test-i386-i386-xl-win         8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-amd64-win          8 guest-saverestore         fail REGR. vs. 10201

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-i386-xend-winxpsp3  7 windows-install              fail  never pass
 test-amd64-amd64-xl-win7-amd64  7 windows-install              fail never pass
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install          fail never pass
 test-amd64-i386-xl-win7-amd64  7 windows-install              fail  never pass
 test-i386-i386-xl-winxpsp3    7 windows-install              fail   never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass

version targeted for testing:
 xen                  3f815406feb2
baseline version:
 xen                  62ff6a318c5d

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Anthony PERARD <anthony.perard@citrix.com>
  Brendan Cully <brendan@cs.ubc.ca>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Jonathan Davies <jonathan.davies@citrix.com>
  juergen.gross@ts.fujitsu.com
  Keir Fraser <keir@xen.org>
  Liu, Jinsong <jinsong.liu@intel.com>
  Olaf Hering <olaf@aepfle.de>
  Philipp Hahn <hahn@univention.de>
  Shriram Rajagopalan <rshriram@cs.ubc.ca>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
------------------------------------------------------------

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


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

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

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


Not pushing.

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

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

From xen-devel-bounces@lists.xensource.com Fri Dec 02 07:13:45 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 07:13:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWNIl-0003eB-ML; Fri, 02 Dec 2011 07:12:55 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RWNIj-0003dx-8m
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 07:12:53 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-9.tower-182.messagelabs.com!1322809931!5553478!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNDI3NTA=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNDI3NTA=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 440 invoked from network); 2 Dec 2011 07:12:12 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-9.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 2 Dec 2011 07:12:12 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1322809931; l=562;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=/5VQXv9Np4yJCeoEHL/sFNjCuFQ=;
	b=BI2PHrqvqgkt6TLMeg9m35tV4kDf0rhYN4W0BXS++ukTGwxENgkEtFqhdzwkTiblOX1
	u/DqwIzAnQZxR/U5DdCiWxOEyEUer5D/LHBOPkN+kcIerqfdQYYp7emtcjNP0Y/HfIPNT
	xyw1llni7q17sxZqwaC+t/IYCzqAtoqgxTU=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFJji0PG5M=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-070-018.pools.arcor-ip.net [88.65.70.18])
	by smtp.strato.de (jimi mo36) (RZmta 26.10 AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id x047d0nB269twX ;
	Fri, 2 Dec 2011 08:11:50 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 3733D18637; Fri,  2 Dec 2011 08:11:49 +0100 (CET)
Date: Fri, 2 Dec 2011 08:11:49 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20111202071148.GA23017@aepfle.de>
References: <2a4ec2e2ae36593aa74e.1322772973@xdev.gridcentric.ca>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <2a4ec2e2ae36593aa74e.1322772973@xdev.gridcentric.ca>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com, tim@xen.org,
	keir.xen@gmail.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH] Flag events caused by foreign domains
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Dec 01, Andres Lagar-Cavilla wrote:

> Add a new flag for mem events, as consumers might need to discriminate
> foreign domain-caused from guest-caused events. The vcpu field of an
> event is bogus from a consumer p.o.v. for foreign domain-caused events.

How is this supposed to be used?

If the toolstack is going to use this then I have to say that it cant
delay events much because the ring will be filled up quickly with the
result that no more events can be generated until the toolstack sends
responses back to the hypervisor.

Olaf

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

From xen-devel-bounces@lists.xensource.com Fri Dec 02 07:13:45 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 07:13:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWNIl-0003eB-ML; Fri, 02 Dec 2011 07:12:55 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RWNIj-0003dx-8m
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 07:12:53 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-9.tower-182.messagelabs.com!1322809931!5553478!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNDI3NTA=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNDI3NTA=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 440 invoked from network); 2 Dec 2011 07:12:12 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-9.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 2 Dec 2011 07:12:12 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1322809931; l=562;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=/5VQXv9Np4yJCeoEHL/sFNjCuFQ=;
	b=BI2PHrqvqgkt6TLMeg9m35tV4kDf0rhYN4W0BXS++ukTGwxENgkEtFqhdzwkTiblOX1
	u/DqwIzAnQZxR/U5DdCiWxOEyEUer5D/LHBOPkN+kcIerqfdQYYp7emtcjNP0Y/HfIPNT
	xyw1llni7q17sxZqwaC+t/IYCzqAtoqgxTU=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFJji0PG5M=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-070-018.pools.arcor-ip.net [88.65.70.18])
	by smtp.strato.de (jimi mo36) (RZmta 26.10 AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id x047d0nB269twX ;
	Fri, 2 Dec 2011 08:11:50 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 3733D18637; Fri,  2 Dec 2011 08:11:49 +0100 (CET)
Date: Fri, 2 Dec 2011 08:11:49 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20111202071148.GA23017@aepfle.de>
References: <2a4ec2e2ae36593aa74e.1322772973@xdev.gridcentric.ca>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <2a4ec2e2ae36593aa74e.1322772973@xdev.gridcentric.ca>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com, tim@xen.org,
	keir.xen@gmail.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH] Flag events caused by foreign domains
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Dec 01, Andres Lagar-Cavilla wrote:

> Add a new flag for mem events, as consumers might need to discriminate
> foreign domain-caused from guest-caused events. The vcpu field of an
> event is bogus from a consumer p.o.v. for foreign domain-caused events.

How is this supposed to be used?

If the toolstack is going to use this then I have to say that it cant
delay events much because the ring will be filled up quickly with the
result that no more events can be generated until the toolstack sends
responses back to the hypervisor.

Olaf

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

From xen-devel-bounces@lists.xensource.com Fri Dec 02 07:56:31 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 07:56:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWNyN-0003y2-0P; Fri, 02 Dec 2011 07:55:55 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <chao.zhou@intel.com>) id 1RWNyL-0003xm-AD
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 07:55:53 +0000
X-Env-Sender: chao.zhou@intel.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1322812511!5864415!1
X-Originating-IP: [143.182.124.37]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjA4MjE1\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12097 invoked from network); 2 Dec 2011 07:55:12 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37)
	by server-4.tower-216.messagelabs.com with SMTP;
	2 Dec 2011 07:55:12 -0000
Received: from azsmga002.ch.intel.com ([10.2.17.35])
	by azsmga102.ch.intel.com with ESMTP; 01 Dec 2011 23:55:10 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,282,1320652800"; d="scan'208";a="43202748"
Received: from pgsmsx602.gar.corp.intel.com ([10.221.43.81])
	by AZSMGA002.ch.intel.com with ESMTP; 01 Dec 2011 23:55:10 -0800
Received: from shsmsx601.ccr.corp.intel.com (10.239.4.112) by
	pgsmsx602.gar.corp.intel.com (10.221.43.81) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Fri, 2 Dec 2011 15:54:27 +0800
Received: from shsmsx502.ccr.corp.intel.com ([10.239.4.96]) by
	shsmsx601.ccr.corp.intel.com ([10.239.4.112]) with mapi; Fri, 2 Dec 2011
	15:54:27 +0800
From: "Zhou, Chao" <chao.zhou@intel.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Fri, 2 Dec 2011 15:54:25 +0800
Thread-Topic: VMX status report. Xen:24272 & Dom0:20a27c1e...
Thread-Index: Acywx5xVnB0eFJexRq6Tfe9f/3ZzPg==
Message-ID: <A24AE1FFE7AEC5489F83450EE98351BF4CF1E37EBE@shsmsx502.ccr.corp.intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Subject: [Xen-devel] VMX status report. Xen:24272 & Dom0:20a27c1e...
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi all,

This is the test report of xen-unstable tree. There is no new bug and no old issues fixed.

Version Info
=================================================================
xen-changeset:   24272:62ff6a318c5d
pvops git:
commit 20a27c1e25b8550066902c9d6ca91631e656dfa3
=================================================================


Old issues(6)
==============
1. [ACPI] System cann't resume after do suspend
http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1707
2.[XL]"xl vcpu-set" causes dom0 crash or panic 
http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1730
3.[VT-D]fail to detach NIC from guest
http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1736
4.Dom0 crash on power-off
http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1740
5.Sometimes Xen panic on ia32pae Sandybridge when restore guest
http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1747
6.[VT-D] device reset fail when create/destroy guest
http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1752



Thanks,
Zhou, Chao



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

From xen-devel-bounces@lists.xensource.com Fri Dec 02 07:56:31 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 07:56:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWNyN-0003y2-0P; Fri, 02 Dec 2011 07:55:55 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <chao.zhou@intel.com>) id 1RWNyL-0003xm-AD
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 07:55:53 +0000
X-Env-Sender: chao.zhou@intel.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1322812511!5864415!1
X-Originating-IP: [143.182.124.37]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjA4MjE1\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12097 invoked from network); 2 Dec 2011 07:55:12 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37)
	by server-4.tower-216.messagelabs.com with SMTP;
	2 Dec 2011 07:55:12 -0000
Received: from azsmga002.ch.intel.com ([10.2.17.35])
	by azsmga102.ch.intel.com with ESMTP; 01 Dec 2011 23:55:10 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,282,1320652800"; d="scan'208";a="43202748"
Received: from pgsmsx602.gar.corp.intel.com ([10.221.43.81])
	by AZSMGA002.ch.intel.com with ESMTP; 01 Dec 2011 23:55:10 -0800
Received: from shsmsx601.ccr.corp.intel.com (10.239.4.112) by
	pgsmsx602.gar.corp.intel.com (10.221.43.81) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Fri, 2 Dec 2011 15:54:27 +0800
Received: from shsmsx502.ccr.corp.intel.com ([10.239.4.96]) by
	shsmsx601.ccr.corp.intel.com ([10.239.4.112]) with mapi; Fri, 2 Dec 2011
	15:54:27 +0800
From: "Zhou, Chao" <chao.zhou@intel.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Fri, 2 Dec 2011 15:54:25 +0800
Thread-Topic: VMX status report. Xen:24272 & Dom0:20a27c1e...
Thread-Index: Acywx5xVnB0eFJexRq6Tfe9f/3ZzPg==
Message-ID: <A24AE1FFE7AEC5489F83450EE98351BF4CF1E37EBE@shsmsx502.ccr.corp.intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Subject: [Xen-devel] VMX status report. Xen:24272 & Dom0:20a27c1e...
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi all,

This is the test report of xen-unstable tree. There is no new bug and no old issues fixed.

Version Info
=================================================================
xen-changeset:   24272:62ff6a318c5d
pvops git:
commit 20a27c1e25b8550066902c9d6ca91631e656dfa3
=================================================================


Old issues(6)
==============
1. [ACPI] System cann't resume after do suspend
http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1707
2.[XL]"xl vcpu-set" causes dom0 crash or panic 
http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1730
3.[VT-D]fail to detach NIC from guest
http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1736
4.Dom0 crash on power-off
http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1740
5.Sometimes Xen panic on ia32pae Sandybridge when restore guest
http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1747
6.[VT-D] device reset fail when create/destroy guest
http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1752



Thanks,
Zhou, Chao



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

From xen-devel-bounces@lists.xensource.com Fri Dec 02 08:03:24 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 08:03:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWO56-0004pz-3G; Fri, 02 Dec 2011 08:02:52 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RWO54-0004pp-Kc
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 08:02:50 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1322812929!3942931!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ0MTk=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12410 invoked from network); 2 Dec 2011 08:02:10 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-8.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 2 Dec 2011 08:02:10 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 02 Dec 2011 08:02:08 +0000
Message-Id: <4ED894100200007800064FE3@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 02 Dec 2011 08:02:08 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>
References: <CAFA7027.25E35%keir.xen@gmail.com>
	<4ED62C50.7060204@citrix.com> <4ED666D5.5060603@citrix.com>
	<4ED7522E0200007800064973@nat28.tlf.novell.com>
	<4ED74DAD.1040903@citrix.com>
	<4ED75E8402000078000649E6@nat28.tlf.novell.com>
	<4ED77347.6060200@citrix.com>
	<4ED787870200007800064B6F@nat28.tlf.novell.com>
	<4ED79722.7090404@citrix.com>
	<4ED7A8110200007800064C50@nat28.tlf.novell.com>
	<4ED7B5FF.2090305@citrix.com>
In-Reply-To: <4ED7B5FF.2090305@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Keir Fraser <keir.xen@gmail.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [RFC] KEXEC: allocate crash note buffers at boot
	time v4
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 01.12.11 at 18:14, Andrew Cooper <andrew.cooper3@citrix.com> wrote:

Looks good to me now except for one minor thing (below), and the
fact that you still decided to retain the two duplicates of the size
calculation (I'll have to remember to clean this up if you don't, unless
Keir explicitly agrees with the duplication).

>+    /* Try once again to allocate room for the crash notes.  It is just possible
>+     * that more space has become available since we last tried.  If space has
>+     * already been allocated, kexec_init_cpu_notes() will return early with 0.
>+     */
>+    if ( kexec_init_cpu_notes(nr) )
>         return -EINVAL;

The function can fail only with -ENOMEM, so why not return this here?

Jan


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

From xen-devel-bounces@lists.xensource.com Fri Dec 02 08:03:24 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 08:03:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWO56-0004pz-3G; Fri, 02 Dec 2011 08:02:52 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RWO54-0004pp-Kc
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 08:02:50 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1322812929!3942931!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ0MTk=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12410 invoked from network); 2 Dec 2011 08:02:10 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-8.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 2 Dec 2011 08:02:10 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 02 Dec 2011 08:02:08 +0000
Message-Id: <4ED894100200007800064FE3@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 02 Dec 2011 08:02:08 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>
References: <CAFA7027.25E35%keir.xen@gmail.com>
	<4ED62C50.7060204@citrix.com> <4ED666D5.5060603@citrix.com>
	<4ED7522E0200007800064973@nat28.tlf.novell.com>
	<4ED74DAD.1040903@citrix.com>
	<4ED75E8402000078000649E6@nat28.tlf.novell.com>
	<4ED77347.6060200@citrix.com>
	<4ED787870200007800064B6F@nat28.tlf.novell.com>
	<4ED79722.7090404@citrix.com>
	<4ED7A8110200007800064C50@nat28.tlf.novell.com>
	<4ED7B5FF.2090305@citrix.com>
In-Reply-To: <4ED7B5FF.2090305@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Keir Fraser <keir.xen@gmail.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [RFC] KEXEC: allocate crash note buffers at boot
	time v4
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 01.12.11 at 18:14, Andrew Cooper <andrew.cooper3@citrix.com> wrote:

Looks good to me now except for one minor thing (below), and the
fact that you still decided to retain the two duplicates of the size
calculation (I'll have to remember to clean this up if you don't, unless
Keir explicitly agrees with the duplication).

>+    /* Try once again to allocate room for the crash notes.  It is just possible
>+     * that more space has become available since we last tried.  If space has
>+     * already been allocated, kexec_init_cpu_notes() will return early with 0.
>+     */
>+    if ( kexec_init_cpu_notes(nr) )
>         return -EINVAL;

The function can fail only with -ENOMEM, so why not return this here?

Jan


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

From xen-devel-bounces@lists.xensource.com Fri Dec 02 08:29:47 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 08:29:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWOUX-00058F-BQ; Fri, 02 Dec 2011 08:29:09 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RWOUW-00058A-Ps
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 08:29:09 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1322814507!5562753!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ0MTk=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23544 invoked from network); 2 Dec 2011 08:28:28 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-9.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 2 Dec 2011 08:28:28 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 02 Dec 2011 08:28:27 +0000
Message-Id: <4ED89A390200007800064FFE@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 02 Dec 2011 08:28:25 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>,
	"Tim Deegan" <tim@xen.org>
References: <patchbomb.1322598097@xdev.gridcentric.ca>
	<6626add0fef6a258388a.1322598103@xdev.gridcentric.ca>
In-Reply-To: <6626add0fef6a258388a.1322598103@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com, ian.campbell@citrix.com,
	andres@gridcentric.ca, keir.xen@gmail.com,
	ian.jackson@citrix.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 6 of 9] x86/mm: Rework stale p2m auditing
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 >>> On 29.11.11 at 21:21, Andres Lagar-Cavilla <andres@lagarcavilla.org> wrote:
> @@ -559,13 +560,15 @@ int set_p2m_entry(struct p2m_domain *p2m
>  extern void p2m_pt_init(struct p2m_domain *p2m);
>  
>  /* Debugging and auditing of the P2M code? */
> -#define P2M_AUDIT     0
> +#define P2M_AUDIT     1
>  #define P2M_DEBUGGING 0
>  
>  #if P2M_AUDIT

Was this change of the default really intended? It uncovered a problem
in 22356:cbb6b4b17024 (the code meanwhile moved elsewhere): In a
32-bit build,

        if ( gfn == 0x55555555 || gfn == 0x5555555555555555 )

causes (at least with some compiler versions, didn't check tonight's
stage tester results yet) a compiler warning (which in turn fails the
build). And a comparison like this is wrong on 64-bit too - see other
(sort of proper; "sort of" because this isn't really appropriate anyway,
especially not without at least using a manifest constant that would
force these to be in sync with the memset()-s that actually establish
these values) examples of using these magic values e.g. in
p2m_alloc_table() or guest_physmap_add_entry().

Jan


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

From xen-devel-bounces@lists.xensource.com Fri Dec 02 08:29:47 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 08:29:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWOUX-00058F-BQ; Fri, 02 Dec 2011 08:29:09 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RWOUW-00058A-Ps
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 08:29:09 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1322814507!5562753!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ0MTk=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23544 invoked from network); 2 Dec 2011 08:28:28 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-9.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 2 Dec 2011 08:28:28 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 02 Dec 2011 08:28:27 +0000
Message-Id: <4ED89A390200007800064FFE@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 02 Dec 2011 08:28:25 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>,
	"Tim Deegan" <tim@xen.org>
References: <patchbomb.1322598097@xdev.gridcentric.ca>
	<6626add0fef6a258388a.1322598103@xdev.gridcentric.ca>
In-Reply-To: <6626add0fef6a258388a.1322598103@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com, ian.campbell@citrix.com,
	andres@gridcentric.ca, keir.xen@gmail.com,
	ian.jackson@citrix.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 6 of 9] x86/mm: Rework stale p2m auditing
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 >>> On 29.11.11 at 21:21, Andres Lagar-Cavilla <andres@lagarcavilla.org> wrote:
> @@ -559,13 +560,15 @@ int set_p2m_entry(struct p2m_domain *p2m
>  extern void p2m_pt_init(struct p2m_domain *p2m);
>  
>  /* Debugging and auditing of the P2M code? */
> -#define P2M_AUDIT     0
> +#define P2M_AUDIT     1
>  #define P2M_DEBUGGING 0
>  
>  #if P2M_AUDIT

Was this change of the default really intended? It uncovered a problem
in 22356:cbb6b4b17024 (the code meanwhile moved elsewhere): In a
32-bit build,

        if ( gfn == 0x55555555 || gfn == 0x5555555555555555 )

causes (at least with some compiler versions, didn't check tonight's
stage tester results yet) a compiler warning (which in turn fails the
build). And a comparison like this is wrong on 64-bit too - see other
(sort of proper; "sort of" because this isn't really appropriate anyway,
especially not without at least using a manifest constant that would
force these to be in sync with the memset()-s that actually establish
these values) examples of using these magic values e.g. in
p2m_alloc_table() or guest_physmap_add_entry().

Jan


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

From xen-devel-bounces@lists.xensource.com Fri Dec 02 08:35:28 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 08:35:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWOaA-0005Iw-50; Fri, 02 Dec 2011 08:34:58 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RWOa8-0005In-K3
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 08:34:56 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1322814856!5510929!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTY3OQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21426 invoked from network); 2 Dec 2011 08:34:16 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Dec 2011 08:34:16 -0000
X-IronPort-AV: E=Sophos;i="4.71,282,1320624000"; 
   d="scan'208";a="9243752"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Dec 2011 08:34:15 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 2 Dec 2011
	08:34:15 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Christoph Egger <Christoph.Egger@amd.com>
Date: Fri, 2 Dec 2011 08:34:15 +0000
In-Reply-To: <4ECE7721.8010007@amd.com>
References: <4EBA7C3A.6010801@amd.com>
	<20174.28957.787602.771046@mariner.uk.xensource.com>
	<4ECE7721.8010007@amd.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322814855.31810.256.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] libxc: Refactor x86 specific code into x86
 specific files
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2011-11-24 at 16:56 +0000, Christoph Egger wrote:
> On 11/24/11 17:30, Ian Jackson wrote:
> > Christoph Egger writes ("[Xen-devel] [PATCH] libxc: Refactor x86 specific code into x86 specific files"):
> >> Move x86 specific code into x86 specific files.
> >> Eliminate arch specific PAGE constants by using common
> >> XC_PAGE_* contants.
> >
> > I'm not sure I understand the motivation for this.
> 
> Code cleanup, better readability, better code organization.

At the very least each cleanup should be presented individually so we
can judge them on their merits.

The switch to a consistent set of XC_PAGE_* constants doesn't seem like
such a bad idea.

Likewise moving the x86 PT constants out of xg_private.h doesn't seem
unreasonable.

I'm less convinced by the more general movement of interface
definitions/implementations out of #ifdef in the .c and .h files into
foo_x86.[ch]. Seems to me that this just obfuscates the interfaces by
requiring one to go and look in multiple places.

I think what you've done to union cpu_guest_context_any_t and friends is
not an improvement.

The first two hunks of change in xenctrl.h seem like pointless code
motion within the same header.

why have you moved the x86 stuff into x86.h but left the ia64 stuff
ifdef'd in the main headers. For any given construct it should be all or
nothing IMHO.

You haven't made any arrangements to install the new headers.

Ian.


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

From xen-devel-bounces@lists.xensource.com Fri Dec 02 08:35:28 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 08:35:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWOaA-0005Iw-50; Fri, 02 Dec 2011 08:34:58 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RWOa8-0005In-K3
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 08:34:56 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1322814856!5510929!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTY3OQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21426 invoked from network); 2 Dec 2011 08:34:16 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Dec 2011 08:34:16 -0000
X-IronPort-AV: E=Sophos;i="4.71,282,1320624000"; 
   d="scan'208";a="9243752"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Dec 2011 08:34:15 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 2 Dec 2011
	08:34:15 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Christoph Egger <Christoph.Egger@amd.com>
Date: Fri, 2 Dec 2011 08:34:15 +0000
In-Reply-To: <4ECE7721.8010007@amd.com>
References: <4EBA7C3A.6010801@amd.com>
	<20174.28957.787602.771046@mariner.uk.xensource.com>
	<4ECE7721.8010007@amd.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322814855.31810.256.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] libxc: Refactor x86 specific code into x86
 specific files
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2011-11-24 at 16:56 +0000, Christoph Egger wrote:
> On 11/24/11 17:30, Ian Jackson wrote:
> > Christoph Egger writes ("[Xen-devel] [PATCH] libxc: Refactor x86 specific code into x86 specific files"):
> >> Move x86 specific code into x86 specific files.
> >> Eliminate arch specific PAGE constants by using common
> >> XC_PAGE_* contants.
> >
> > I'm not sure I understand the motivation for this.
> 
> Code cleanup, better readability, better code organization.

At the very least each cleanup should be presented individually so we
can judge them on their merits.

The switch to a consistent set of XC_PAGE_* constants doesn't seem like
such a bad idea.

Likewise moving the x86 PT constants out of xg_private.h doesn't seem
unreasonable.

I'm less convinced by the more general movement of interface
definitions/implementations out of #ifdef in the .c and .h files into
foo_x86.[ch]. Seems to me that this just obfuscates the interfaces by
requiring one to go and look in multiple places.

I think what you've done to union cpu_guest_context_any_t and friends is
not an improvement.

The first two hunks of change in xenctrl.h seem like pointless code
motion within the same header.

why have you moved the x86 stuff into x86.h but left the ia64 stuff
ifdef'd in the main headers. For any given construct it should be all or
nothing IMHO.

You haven't made any arrangements to install the new headers.

Ian.


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

From xen-devel-bounces@lists.xensource.com Fri Dec 02 08:39:49 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 08: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.xensource.com>)
	id 1RWOeL-0005Ri-RH; Fri, 02 Dec 2011 08:39:17 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <xudong.hao@intel.com>) id 1RWOeK-0005RZ-RB
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 08:39:17 +0000
X-Env-Sender: xudong.hao@intel.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1322815115!1015028!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDMwMzk4NA==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9807 invoked from network); 2 Dec 2011 08:38:36 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-8.tower-182.messagelabs.com with SMTP;
	2 Dec 2011 08:38:36 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga101.fm.intel.com with ESMTP; 02 Dec 2011 00:38:34 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,282,1320652800"; d="scan'208";a="91448443"
Received: from pgsmsx603.gar.corp.intel.com ([10.221.43.87])
	by fmsmga001.fm.intel.com with ESMTP; 02 Dec 2011 00:38:34 -0800
Received: from pgsmsx104.gar.corp.intel.com (10.221.44.91) by
	pgsmsx603.gar.corp.intel.com (10.221.43.87) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Fri, 2 Dec 2011 16:38:32 +0800
Received: from shsmsx602.ccr.corp.intel.com (10.239.4.104) by
	PGSMSX104.gar.corp.intel.com (10.221.44.91) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Fri, 2 Dec 2011 16:38:32 +0800
Received: from shsmsx502.ccr.corp.intel.com ([10.239.4.96]) by
	SHSMSX602.ccr.corp.intel.com ([10.239.4.104]) with mapi; Fri, 2 Dec 2011
	16:38:30 +0800
From: "Hao, Xudong" <xudong.hao@intel.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Fri, 2 Dec 2011 16:38:30 +0800
Thread-Topic: [PATCH] tools/firmware: remove "_PS0/3" Method
Thread-Index: AcywzXyuc/E+gfMtR6Og9gMqN63saw==
Message-ID: <BC00F5384FCFC9499AF06F92E8B78A9E2870BB473F@shsmsx502.ccr.corp.intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "Tian, Kevin" <kevin.tian@intel.com>, Keir Fraser <keir.xen@gmail.com>,
	"Shan, Haitao" <haitao.shan@intel.com>
Subject: [Xen-devel] [PATCH] tools/firmware: remove "_PS0/3" Method
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

tools/firmware: remove "_PS0/3" Method

Do not expose the ACPI power management "_PS0/3" Method to guest firmware. According to section 3.4 of the APCI specification 4.0, PCI device control the device power through its own specification but not through APCI.

Qemu pushes "_PS0/3" to guest will cause a mess between ACPI PM and PCI PM as a result of incorrect ACPI table shipped with the guest BIOS, it may cause a failure of PCI device PM state transition(from PCI_UNKNOWN to PCI_D0).

Signed-off-by: Xudong Hao <xudong.hao@intel.com>
Signed-off-by: Haitao Shan <haitao.shan@intel.com>

diff -r df7cec2c6c03 tools/firmware/hvmloader/acpi/mk_dsdt.c
--- a/tools/firmware/hvmloader/acpi/mk_dsdt.c	Tue Nov 29 13:30:39 2011 -0500
+++ b/tools/firmware/hvmloader/acpi/mk_dsdt.c	Wed Nov 30 15:08:20 2011 +0800
@@ -323,8 +323,6 @@
      * the ACPI event:
      *  _EJ0: eject a device
      *  _STA: return a device's status, e.g. enabled or removed
-     * Other methods are optional: 
-     *  _PS0/3: put them here for debug purpose
      * 
      * Eject button would generate a general-purpose event, then the
      * control method for this event uses Notify() to inform OSPM which @@ -344,13 +342,6 @@
             stmt("Name", "_ADR, 0x%08x", ((slot & ~7) << 13) | (slot & 7));
             /* _SUN == dev */
             stmt("Name", "_SUN, 0x%08x", slot >> 3);
-            push_block("Method", "_PS0, 0");
-            stmt("Store", "0x%02x, \\_GPE.DPT1", slot);
-            stmt("Store", "0x80, \\_GPE.DPT2");
-            pop_block();
-            push_block("Method", "_PS3, 0");
-            stmt("Store", "0x%02x, \\_GPE.DPT1", slot);
-            stmt("Store", "0x83, \\_GPE.DPT2");
             pop_block();
             push_block("Method", "_EJ0, 1");
             stmt("Store", "0x%02x, \\_GPE.DPT1", slot)




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

From xen-devel-bounces@lists.xensource.com Fri Dec 02 08:39:49 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 08: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.xensource.com>)
	id 1RWOeL-0005Ri-RH; Fri, 02 Dec 2011 08:39:17 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <xudong.hao@intel.com>) id 1RWOeK-0005RZ-RB
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 08:39:17 +0000
X-Env-Sender: xudong.hao@intel.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1322815115!1015028!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDMwMzk4NA==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9807 invoked from network); 2 Dec 2011 08:38:36 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-8.tower-182.messagelabs.com with SMTP;
	2 Dec 2011 08:38:36 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga101.fm.intel.com with ESMTP; 02 Dec 2011 00:38:34 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,282,1320652800"; d="scan'208";a="91448443"
Received: from pgsmsx603.gar.corp.intel.com ([10.221.43.87])
	by fmsmga001.fm.intel.com with ESMTP; 02 Dec 2011 00:38:34 -0800
Received: from pgsmsx104.gar.corp.intel.com (10.221.44.91) by
	pgsmsx603.gar.corp.intel.com (10.221.43.87) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Fri, 2 Dec 2011 16:38:32 +0800
Received: from shsmsx602.ccr.corp.intel.com (10.239.4.104) by
	PGSMSX104.gar.corp.intel.com (10.221.44.91) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Fri, 2 Dec 2011 16:38:32 +0800
Received: from shsmsx502.ccr.corp.intel.com ([10.239.4.96]) by
	SHSMSX602.ccr.corp.intel.com ([10.239.4.104]) with mapi; Fri, 2 Dec 2011
	16:38:30 +0800
From: "Hao, Xudong" <xudong.hao@intel.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Fri, 2 Dec 2011 16:38:30 +0800
Thread-Topic: [PATCH] tools/firmware: remove "_PS0/3" Method
Thread-Index: AcywzXyuc/E+gfMtR6Og9gMqN63saw==
Message-ID: <BC00F5384FCFC9499AF06F92E8B78A9E2870BB473F@shsmsx502.ccr.corp.intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "Tian, Kevin" <kevin.tian@intel.com>, Keir Fraser <keir.xen@gmail.com>,
	"Shan, Haitao" <haitao.shan@intel.com>
Subject: [Xen-devel] [PATCH] tools/firmware: remove "_PS0/3" Method
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

tools/firmware: remove "_PS0/3" Method

Do not expose the ACPI power management "_PS0/3" Method to guest firmware. According to section 3.4 of the APCI specification 4.0, PCI device control the device power through its own specification but not through APCI.

Qemu pushes "_PS0/3" to guest will cause a mess between ACPI PM and PCI PM as a result of incorrect ACPI table shipped with the guest BIOS, it may cause a failure of PCI device PM state transition(from PCI_UNKNOWN to PCI_D0).

Signed-off-by: Xudong Hao <xudong.hao@intel.com>
Signed-off-by: Haitao Shan <haitao.shan@intel.com>

diff -r df7cec2c6c03 tools/firmware/hvmloader/acpi/mk_dsdt.c
--- a/tools/firmware/hvmloader/acpi/mk_dsdt.c	Tue Nov 29 13:30:39 2011 -0500
+++ b/tools/firmware/hvmloader/acpi/mk_dsdt.c	Wed Nov 30 15:08:20 2011 +0800
@@ -323,8 +323,6 @@
      * the ACPI event:
      *  _EJ0: eject a device
      *  _STA: return a device's status, e.g. enabled or removed
-     * Other methods are optional: 
-     *  _PS0/3: put them here for debug purpose
      * 
      * Eject button would generate a general-purpose event, then the
      * control method for this event uses Notify() to inform OSPM which @@ -344,13 +342,6 @@
             stmt("Name", "_ADR, 0x%08x", ((slot & ~7) << 13) | (slot & 7));
             /* _SUN == dev */
             stmt("Name", "_SUN, 0x%08x", slot >> 3);
-            push_block("Method", "_PS0, 0");
-            stmt("Store", "0x%02x, \\_GPE.DPT1", slot);
-            stmt("Store", "0x80, \\_GPE.DPT2");
-            pop_block();
-            push_block("Method", "_PS3, 0");
-            stmt("Store", "0x%02x, \\_GPE.DPT1", slot);
-            stmt("Store", "0x83, \\_GPE.DPT2");
             pop_block();
             push_block("Method", "_EJ0, 1");
             stmt("Store", "0x%02x, \\_GPE.DPT1", slot)




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

From xen-devel-bounces@lists.xensource.com Fri Dec 02 08:48:14 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 08:48:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWOmd-0005g7-15; Fri, 02 Dec 2011 08:47:51 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RWOma-0005fz-QF
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 08:47:49 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1322815626!921777!1
X-Originating-IP: [209.85.210.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 872 invoked from network); 2 Dec 2011 08:47:08 -0000
Received: from mail-pz0-f43.google.com (HELO mail-pz0-f43.google.com)
	(209.85.210.43)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Dec 2011 08:47:08 -0000
Received: by dadz13 with SMTP id z13so7706279dad.30
	for <xen-devel@lists.xensource.com>;
	Fri, 02 Dec 2011 00:47:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:date:x-google-sender-auth:message-id:subject
	:from:to:content-type;
	bh=oMCU8Cx0OzVE3LtLi/0Q8oJOGcB4ktvMSUTV0Sqy5ZU=;
	b=ufkL1rTio3S8/ZMQw4mX0v0ZxOrZkMJJn/pmBnWGmm7ilcEf2UJd8TfeXB/sU+hOdC
	S+0x+AumC56uv5KOYAVFOx7nJOH1bDogvm2H8VYYu0USZKZLgx8R7LAtiCErKvAKCZ9y
	tcHVbZltcF6IhCiZUMfzICuu9Yn1cPtcyQvdc=
MIME-Version: 1.0
Received: by 10.68.10.38 with SMTP id f6mr12344463pbb.89.1322815626034; Fri,
	02 Dec 2011 00:47:06 -0800 (PST)
Received: by 10.142.212.12 with HTTP; Fri, 2 Dec 2011 00:47:05 -0800 (PST)
Date: Fri, 2 Dec 2011 09:47:05 +0100
X-Google-Sender-Auth: PBVdOO54iwnVNeitF8gHH4cA3lE
Message-ID: <CAPLaKK5VC7YvMyvGM07f=ngOrbGbvLLDA1J8nqaxDsntux-bbQ@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] libxl: error when destroying domain on NetBSD
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hello,

When destroying a guest (xl destroy <domid>) on NetBSD I get the
following error on the log file:

Waiting for domain test (domid 1) to die [pid 11675]
Domain 1 is dead
Unknown shutdown reason code 255. Destroying domain.
Action for shutdown reason code 255 is destroy
Domain 1 needs to be cleaned up: destroying the domain
do_domctl failed: errno 3
libxl: error: libxl.c:762:libxl_domain_destroy: xc_domain_pause failed for 1
libxl: error: libxl_dom.c:658:userdata_path: unable to find domain
info for domain 1: No such file or directory
do_domctl failed: errno 3
libxl: error: libxl.c:787:libxl_domain_destroy: xc_domain_destroy failed for 1
Done. Exiting now

The domain is destroyed, but xenstore is not cleaned properly, and
hotplug scripts are not executed because the state of the devices
doesn't get to 6 until xl exits. From libxl code I guess the following
procedure is used to destroy the domain:

 * Destroy PCI devices
 * Pause domain
 * Destroy device model (not applicable here, the guest is a PV with no dm)
 * Destroy devices (here xl waits for devices to reach state '6', but
they never get there, only when xl exits the state changes to 6)
 * Clean xenstore
 * Destroy the domain

The 'pause' ctl call fails here, but I've tried to pause a domain
using 'xl pause <domid>' and it works fine. BTW, I'm using
xen-unstable, and the guest is a Debian 6.0.3 PV. Any help on what
might be happening here is welcome.

Thanks, Roger.

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

From xen-devel-bounces@lists.xensource.com Fri Dec 02 08:48:14 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 08:48:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWOmd-0005g7-15; Fri, 02 Dec 2011 08:47:51 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RWOma-0005fz-QF
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 08:47:49 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1322815626!921777!1
X-Originating-IP: [209.85.210.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 872 invoked from network); 2 Dec 2011 08:47:08 -0000
Received: from mail-pz0-f43.google.com (HELO mail-pz0-f43.google.com)
	(209.85.210.43)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Dec 2011 08:47:08 -0000
Received: by dadz13 with SMTP id z13so7706279dad.30
	for <xen-devel@lists.xensource.com>;
	Fri, 02 Dec 2011 00:47:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:date:x-google-sender-auth:message-id:subject
	:from:to:content-type;
	bh=oMCU8Cx0OzVE3LtLi/0Q8oJOGcB4ktvMSUTV0Sqy5ZU=;
	b=ufkL1rTio3S8/ZMQw4mX0v0ZxOrZkMJJn/pmBnWGmm7ilcEf2UJd8TfeXB/sU+hOdC
	S+0x+AumC56uv5KOYAVFOx7nJOH1bDogvm2H8VYYu0USZKZLgx8R7LAtiCErKvAKCZ9y
	tcHVbZltcF6IhCiZUMfzICuu9Yn1cPtcyQvdc=
MIME-Version: 1.0
Received: by 10.68.10.38 with SMTP id f6mr12344463pbb.89.1322815626034; Fri,
	02 Dec 2011 00:47:06 -0800 (PST)
Received: by 10.142.212.12 with HTTP; Fri, 2 Dec 2011 00:47:05 -0800 (PST)
Date: Fri, 2 Dec 2011 09:47:05 +0100
X-Google-Sender-Auth: PBVdOO54iwnVNeitF8gHH4cA3lE
Message-ID: <CAPLaKK5VC7YvMyvGM07f=ngOrbGbvLLDA1J8nqaxDsntux-bbQ@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] libxl: error when destroying domain on NetBSD
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hello,

When destroying a guest (xl destroy <domid>) on NetBSD I get the
following error on the log file:

Waiting for domain test (domid 1) to die [pid 11675]
Domain 1 is dead
Unknown shutdown reason code 255. Destroying domain.
Action for shutdown reason code 255 is destroy
Domain 1 needs to be cleaned up: destroying the domain
do_domctl failed: errno 3
libxl: error: libxl.c:762:libxl_domain_destroy: xc_domain_pause failed for 1
libxl: error: libxl_dom.c:658:userdata_path: unable to find domain
info for domain 1: No such file or directory
do_domctl failed: errno 3
libxl: error: libxl.c:787:libxl_domain_destroy: xc_domain_destroy failed for 1
Done. Exiting now

The domain is destroyed, but xenstore is not cleaned properly, and
hotplug scripts are not executed because the state of the devices
doesn't get to 6 until xl exits. From libxl code I guess the following
procedure is used to destroy the domain:

 * Destroy PCI devices
 * Pause domain
 * Destroy device model (not applicable here, the guest is a PV with no dm)
 * Destroy devices (here xl waits for devices to reach state '6', but
they never get there, only when xl exits the state changes to 6)
 * Clean xenstore
 * Destroy the domain

The 'pause' ctl call fails here, but I've tried to pause a domain
using 'xl pause <domid>' and it works fine. BTW, I'm using
xen-unstable, and the guest is a Debian 6.0.3 PV. Any help on what
might be happening here is welcome.

Thanks, Roger.

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

From xen-devel-bounces@lists.xensource.com Fri Dec 02 08:48:51 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 08: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.xensource.com>)
	id 1RWOnK-0005iF-FJ; Fri, 02 Dec 2011 08:48:34 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RWOnI-0005hq-Ub
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 08:48:33 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1322815671!3965031!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTY3OQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5478 invoked from network); 2 Dec 2011 08:47:52 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Dec 2011 08:47:52 -0000
X-IronPort-AV: E=Sophos;i="4.71,282,1320624000"; 
   d="scan'208";a="9243965"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Dec 2011 08:47:51 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 2 Dec 2011
	08:47:51 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "Hao, Xudong" <xudong.hao@intel.com>
Date: Fri, 2 Dec 2011 08:47:51 +0000
In-Reply-To: <BC00F5384FCFC9499AF06F92E8B78A9E2870BB473F@shsmsx502.ccr.corp.intel.com>
References: <BC00F5384FCFC9499AF06F92E8B78A9E2870BB473F@shsmsx502.ccr.corp.intel.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322815671.31810.265.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "Tian, Kevin" <kevin.tian@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Shan, 
	Haitao" <haitao.shan@intel.com>, Keir Fraser <keir.xen@gmail.com>
Subject: Re: [Xen-devel] [PATCH] tools/firmware: remove "_PS0/3" Method
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2011-12-02 at 08:38 +0000, Hao, Xudong wrote:
> tools/firmware: remove "_PS0/3" Method
> 
> Do not expose the ACPI power management "_PS0/3" Method to guest
> firmware. According to section 3.4 of the APCI specification 4.0, PCI
> device control the device power through its own specification but not
> through APCI.
> 
> Qemu pushes "_PS0/3" to guest will cause a mess between ACPI PM and
> PCI PM as a result of incorrect ACPI table shipped with the guest
> BIOS, it may cause a failure of PCI device PM state transition(from
> PCI_UNKNOWN to PCI_D0).

How have you tested this and with which guest OSes? Was there a specific
failure which you observed?

Is this a different fix for the issue fixed by Linux upstream  changeset
47e9037ac166 "PCI hotplug: acpiphp: set current_state to D0 in
register_slot"?

Ian.

> 
> Signed-off-by: Xudong Hao <xudong.hao@intel.com>
> Signed-off-by: Haitao Shan <haitao.shan@intel.com>
> 
> diff -r df7cec2c6c03 tools/firmware/hvmloader/acpi/mk_dsdt.c
> --- a/tools/firmware/hvmloader/acpi/mk_dsdt.c	Tue Nov 29 13:30:39 2011 -0500
> +++ b/tools/firmware/hvmloader/acpi/mk_dsdt.c	Wed Nov 30 15:08:20 2011 +0800
> @@ -323,8 +323,6 @@
>       * the ACPI event:
>       *  _EJ0: eject a device
>       *  _STA: return a device's status, e.g. enabled or removed
> -     * Other methods are optional: 
> -     *  _PS0/3: put them here for debug purpose
>       * 
>       * Eject button would generate a general-purpose event, then the
>       * control method for this event uses Notify() to inform OSPM which @@ -344,13 +342,6 @@
>              stmt("Name", "_ADR, 0x%08x", ((slot & ~7) << 13) | (slot & 7));
>              /* _SUN == dev */
>              stmt("Name", "_SUN, 0x%08x", slot >> 3);
> -            push_block("Method", "_PS0, 0");
> -            stmt("Store", "0x%02x, \\_GPE.DPT1", slot);
> -            stmt("Store", "0x80, \\_GPE.DPT2");
> -            pop_block();
> -            push_block("Method", "_PS3, 0");
> -            stmt("Store", "0x%02x, \\_GPE.DPT1", slot);
> -            stmt("Store", "0x83, \\_GPE.DPT2");
>              pop_block();
>              push_block("Method", "_EJ0, 1");
>              stmt("Store", "0x%02x, \\_GPE.DPT1", slot)
> 
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



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

From xen-devel-bounces@lists.xensource.com Fri Dec 02 08:48:51 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 08: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.xensource.com>)
	id 1RWOnK-0005iF-FJ; Fri, 02 Dec 2011 08:48:34 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RWOnI-0005hq-Ub
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 08:48:33 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1322815671!3965031!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTY3OQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5478 invoked from network); 2 Dec 2011 08:47:52 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Dec 2011 08:47:52 -0000
X-IronPort-AV: E=Sophos;i="4.71,282,1320624000"; 
   d="scan'208";a="9243965"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Dec 2011 08:47:51 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 2 Dec 2011
	08:47:51 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "Hao, Xudong" <xudong.hao@intel.com>
Date: Fri, 2 Dec 2011 08:47:51 +0000
In-Reply-To: <BC00F5384FCFC9499AF06F92E8B78A9E2870BB473F@shsmsx502.ccr.corp.intel.com>
References: <BC00F5384FCFC9499AF06F92E8B78A9E2870BB473F@shsmsx502.ccr.corp.intel.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322815671.31810.265.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "Tian, Kevin" <kevin.tian@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Shan, 
	Haitao" <haitao.shan@intel.com>, Keir Fraser <keir.xen@gmail.com>
Subject: Re: [Xen-devel] [PATCH] tools/firmware: remove "_PS0/3" Method
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2011-12-02 at 08:38 +0000, Hao, Xudong wrote:
> tools/firmware: remove "_PS0/3" Method
> 
> Do not expose the ACPI power management "_PS0/3" Method to guest
> firmware. According to section 3.4 of the APCI specification 4.0, PCI
> device control the device power through its own specification but not
> through APCI.
> 
> Qemu pushes "_PS0/3" to guest will cause a mess between ACPI PM and
> PCI PM as a result of incorrect ACPI table shipped with the guest
> BIOS, it may cause a failure of PCI device PM state transition(from
> PCI_UNKNOWN to PCI_D0).

How have you tested this and with which guest OSes? Was there a specific
failure which you observed?

Is this a different fix for the issue fixed by Linux upstream  changeset
47e9037ac166 "PCI hotplug: acpiphp: set current_state to D0 in
register_slot"?

Ian.

> 
> Signed-off-by: Xudong Hao <xudong.hao@intel.com>
> Signed-off-by: Haitao Shan <haitao.shan@intel.com>
> 
> diff -r df7cec2c6c03 tools/firmware/hvmloader/acpi/mk_dsdt.c
> --- a/tools/firmware/hvmloader/acpi/mk_dsdt.c	Tue Nov 29 13:30:39 2011 -0500
> +++ b/tools/firmware/hvmloader/acpi/mk_dsdt.c	Wed Nov 30 15:08:20 2011 +0800
> @@ -323,8 +323,6 @@
>       * the ACPI event:
>       *  _EJ0: eject a device
>       *  _STA: return a device's status, e.g. enabled or removed
> -     * Other methods are optional: 
> -     *  _PS0/3: put them here for debug purpose
>       * 
>       * Eject button would generate a general-purpose event, then the
>       * control method for this event uses Notify() to inform OSPM which @@ -344,13 +342,6 @@
>              stmt("Name", "_ADR, 0x%08x", ((slot & ~7) << 13) | (slot & 7));
>              /* _SUN == dev */
>              stmt("Name", "_SUN, 0x%08x", slot >> 3);
> -            push_block("Method", "_PS0, 0");
> -            stmt("Store", "0x%02x, \\_GPE.DPT1", slot);
> -            stmt("Store", "0x80, \\_GPE.DPT2");
> -            pop_block();
> -            push_block("Method", "_PS3, 0");
> -            stmt("Store", "0x%02x, \\_GPE.DPT1", slot);
> -            stmt("Store", "0x83, \\_GPE.DPT2");
>              pop_block();
>              push_block("Method", "_EJ0, 1");
>              stmt("Store", "0x%02x, \\_GPE.DPT1", slot)
> 
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



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

From xen-devel-bounces@lists.xensource.com Fri Dec 02 08:52:44 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 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.xensource.com>)
	id 1RWOr6-0005vU-4q; Fri, 02 Dec 2011 08:52:28 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <hahn@univention.de>) id 1RWOr4-0005vI-3r
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 08:52:26 +0000
X-Env-Sender: hahn@univention.de
X-Msg-Ref: server-8.tower-182.messagelabs.com!1322815905!1017246!1
X-Originating-IP: [82.198.197.8]
X-SpamReason: No, hits=0.0 required=7.0 tests=SUBJECT_EXCESS_QP
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24825 invoked from network); 2 Dec 2011 08:51:45 -0000
Received: from mail.univention.de (HELO mail.univention.de) (82.198.197.8)
	by server-8.tower-182.messagelabs.com with SMTP;
	2 Dec 2011 08:51:45 -0000
Received: from localhost (localhost [127.0.0.1])
	by slugis.knut.univention.de (Postfix) with ESMTP id 5AFF2673001;
	Fri,  2 Dec 2011 09:51:42 +0100 (CET)
Received: from localhost (localhost [127.0.0.1])
	by slugis.knut.univention.de (Postfix) with ESMTP id 4B161673010;
	Fri,  2 Dec 2011 09:51:42 +0100 (CET)
X-Virus-Scanned: by amavisd-new-2.6.1 (20080629) (Debian) at knut.univention.de
Received: from mail.univention.de ([127.0.0.1])
	by localhost (slugis.knut.univention.de [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id cxE9tA8aObAq; Fri,  2 Dec 2011 09:51:41 +0100 (CET)
Received: from stave.knut.univention.de (stave.knut.univention.de
	[192.168.0.191])
	by slugis.knut.univention.de (Postfix) with ESMTPSA id ACF9C673001;
	Fri,  2 Dec 2011 09:51:41 +0100 (CET)
From: Philipp Hahn <hahn@univention.de>
Organization: Univention.de
To: xen-devel@lists.xensource.com
Date: Fri, 2 Dec 2011 09:51:36 +0100
User-Agent: KMail/1.9.10 (enterprise35 20100903.1171286)
References: <201111251721.12753.hahn@univention.de>
	<20111201193711.GK12984@reaktio.net>
	<1322769065.7376.36.camel@dagon.hellion.org.uk>
In-Reply-To: <1322769065.7376.36.camel@dagon.hellion.org.uk>
X-KMail-QuotePrefix: > 
MIME-Version: 1.0
Message-Id: <201112020951.40156.hahn@univention.de>
Cc: libvir-list@redhat.com
Subject: Re: [Xen-devel] [BUG] insufficient quoting between
	"=?iso-8859-1?q?tap-ctl=09list?=" and
	xend/server/BlktapController.py
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3794238974083690080=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============3794238974083690080==
Content-Type: multipart/signed;
  boundary="nextPart2540906.20MGjDkx1D";
  protocol="application/pgp-signature";
  micalg=pgp-sha1
Content-Transfer-Encoding: 7bit

--nextPart2540906.20MGjDkx1D
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Hello,

On Thursday 01 December 2011 19:31:04 Ian Jackson wrote:
> Philipp Hahn writes ("Re: [Xen-devel] [BUG] insufficient quoting=20
between "tap-ctl list" and xend/server/BlktapController.py"):
> > As a quick work-around, the attached patch fixes the problem for me. Th=
at
> > is, until tap-ctl changes it's output format.
>
> Thanks, I have applied it.

Thanks for applying.

On Thursday 01 December 2011 20:51:05 Ian Campbell wrote:
> xend is deprecated. This ultimately means that xend will go away. If you
> are dependent on these features then you need put effort into ensuring
> that they become supported in libxl and xl.

=46or our forthcomming release of UCS-3.0 we really wanted to switch from X=
end=20
to xl, but be had to switch back to using Xend, because libvirt still lacks=
=20
some important features like migration; see=20
<http://libvirt.org/hvsupport.html> for a comparison matrix. Back at the=20
beginning of 2011 Univention sponsored Markus Gross to work on the xl-bindi=
ng=20
of libvirt, but after the end of his internship I have not seen that much=20
work on the xl-binding in libvirt except from Jim Fehlig.

Sincerely
Philipp Hahn
=2D-=20
Philipp Hahn           Open Source Software Engineer      hahn@univention.de
Univention GmbH        Linux for Your Business        fon: +49 421 22 232- 0
Mary-Somerville-Str.1  D-28359 Bremen                 fax: +49 421 22 232-99
                                                   http://www.univention.de/

--nextPart2540906.20MGjDkx1D
Content-Type: application/pgp-signature; name=signature.asc 
Content-Description: This is a digitally signed message part.

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

iEYEABECAAYFAk7YkZgACgkQYPlgoZpUDjmRpgCfex39IOxOzVuZFizXbFmtL8E0
B/4AniEh/AjVbSPEwIJU2mTj4E+a3tLj
=3UnA
-----END PGP SIGNATURE-----

--nextPart2540906.20MGjDkx1D--


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

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

--===============3794238974083690080==--


From xen-devel-bounces@lists.xensource.com Fri Dec 02 08:52:44 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 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.xensource.com>)
	id 1RWOr6-0005vU-4q; Fri, 02 Dec 2011 08:52:28 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <hahn@univention.de>) id 1RWOr4-0005vI-3r
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 08:52:26 +0000
X-Env-Sender: hahn@univention.de
X-Msg-Ref: server-8.tower-182.messagelabs.com!1322815905!1017246!1
X-Originating-IP: [82.198.197.8]
X-SpamReason: No, hits=0.0 required=7.0 tests=SUBJECT_EXCESS_QP
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24825 invoked from network); 2 Dec 2011 08:51:45 -0000
Received: from mail.univention.de (HELO mail.univention.de) (82.198.197.8)
	by server-8.tower-182.messagelabs.com with SMTP;
	2 Dec 2011 08:51:45 -0000
Received: from localhost (localhost [127.0.0.1])
	by slugis.knut.univention.de (Postfix) with ESMTP id 5AFF2673001;
	Fri,  2 Dec 2011 09:51:42 +0100 (CET)
Received: from localhost (localhost [127.0.0.1])
	by slugis.knut.univention.de (Postfix) with ESMTP id 4B161673010;
	Fri,  2 Dec 2011 09:51:42 +0100 (CET)
X-Virus-Scanned: by amavisd-new-2.6.1 (20080629) (Debian) at knut.univention.de
Received: from mail.univention.de ([127.0.0.1])
	by localhost (slugis.knut.univention.de [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id cxE9tA8aObAq; Fri,  2 Dec 2011 09:51:41 +0100 (CET)
Received: from stave.knut.univention.de (stave.knut.univention.de
	[192.168.0.191])
	by slugis.knut.univention.de (Postfix) with ESMTPSA id ACF9C673001;
	Fri,  2 Dec 2011 09:51:41 +0100 (CET)
From: Philipp Hahn <hahn@univention.de>
Organization: Univention.de
To: xen-devel@lists.xensource.com
Date: Fri, 2 Dec 2011 09:51:36 +0100
User-Agent: KMail/1.9.10 (enterprise35 20100903.1171286)
References: <201111251721.12753.hahn@univention.de>
	<20111201193711.GK12984@reaktio.net>
	<1322769065.7376.36.camel@dagon.hellion.org.uk>
In-Reply-To: <1322769065.7376.36.camel@dagon.hellion.org.uk>
X-KMail-QuotePrefix: > 
MIME-Version: 1.0
Message-Id: <201112020951.40156.hahn@univention.de>
Cc: libvir-list@redhat.com
Subject: Re: [Xen-devel] [BUG] insufficient quoting between
	"=?iso-8859-1?q?tap-ctl=09list?=" and
	xend/server/BlktapController.py
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3794238974083690080=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============3794238974083690080==
Content-Type: multipart/signed;
  boundary="nextPart2540906.20MGjDkx1D";
  protocol="application/pgp-signature";
  micalg=pgp-sha1
Content-Transfer-Encoding: 7bit

--nextPart2540906.20MGjDkx1D
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Hello,

On Thursday 01 December 2011 19:31:04 Ian Jackson wrote:
> Philipp Hahn writes ("Re: [Xen-devel] [BUG] insufficient quoting=20
between "tap-ctl list" and xend/server/BlktapController.py"):
> > As a quick work-around, the attached patch fixes the problem for me. Th=
at
> > is, until tap-ctl changes it's output format.
>
> Thanks, I have applied it.

Thanks for applying.

On Thursday 01 December 2011 20:51:05 Ian Campbell wrote:
> xend is deprecated. This ultimately means that xend will go away. If you
> are dependent on these features then you need put effort into ensuring
> that they become supported in libxl and xl.

=46or our forthcomming release of UCS-3.0 we really wanted to switch from X=
end=20
to xl, but be had to switch back to using Xend, because libvirt still lacks=
=20
some important features like migration; see=20
<http://libvirt.org/hvsupport.html> for a comparison matrix. Back at the=20
beginning of 2011 Univention sponsored Markus Gross to work on the xl-bindi=
ng=20
of libvirt, but after the end of his internship I have not seen that much=20
work on the xl-binding in libvirt except from Jim Fehlig.

Sincerely
Philipp Hahn
=2D-=20
Philipp Hahn           Open Source Software Engineer      hahn@univention.de
Univention GmbH        Linux for Your Business        fon: +49 421 22 232- 0
Mary-Somerville-Str.1  D-28359 Bremen                 fax: +49 421 22 232-99
                                                   http://www.univention.de/

--nextPart2540906.20MGjDkx1D
Content-Type: application/pgp-signature; name=signature.asc 
Content-Description: This is a digitally signed message part.

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

iEYEABECAAYFAk7YkZgACgkQYPlgoZpUDjmRpgCfex39IOxOzVuZFizXbFmtL8E0
B/4AniEh/AjVbSPEwIJU2mTj4E+a3tLj
=3UnA
-----END PGP SIGNATURE-----

--nextPart2540906.20MGjDkx1D--


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

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

--===============3794238974083690080==--


From xen-devel-bounces@lists.xensource.com Fri Dec 02 08:55:31 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 08:55:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWOtp-00068D-Fb; Fri, 02 Dec 2011 08:55:17 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RWOto-00067c-Ih
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 08:55:16 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1322816075!5566179!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ0MTk=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15613 invoked from network); 2 Dec 2011 08:54:35 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-11.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 2 Dec 2011 08:54:35 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 02 Dec 2011 08:54:35 +0000
Message-Id: <4ED8A05A0200007800065020@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 02 Dec 2011 08:54:34 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Keir Fraser" <keir@xen.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Olaf Hering <olaf@aepfle.de>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: [Xen-devel] tools/libxc/xc_cpuid_x86.c:cpuid()'s inline asm
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Keir,

do you recall what it was that 20976:f8692cc67d67 was supposed to fix?
The code is clearly wrong now on x86-64 - inline asm that uses push/pop
(or other stack pointer manipulation instructions) and memory accesses
that may reference the stack (even if not through %rsp) can't be
expected to work without -mno-red-zone.

The question is whether to use that command line option, or whether to
correct the inline assembly (besides the purpose of your change, I also
wonder why this isn't coded the obvious way, with rBX and rDX explicitly
named in the constraints - on 32-bit this may be to reduce register
pressure, but on 64-bit it's entirely unclear).

Thanks, Jan


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

From xen-devel-bounces@lists.xensource.com Fri Dec 02 08:55:31 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 08:55:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWOtp-00068D-Fb; Fri, 02 Dec 2011 08:55:17 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RWOto-00067c-Ih
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 08:55:16 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1322816075!5566179!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ0MTk=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15613 invoked from network); 2 Dec 2011 08:54:35 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-11.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 2 Dec 2011 08:54:35 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 02 Dec 2011 08:54:35 +0000
Message-Id: <4ED8A05A0200007800065020@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 02 Dec 2011 08:54:34 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Keir Fraser" <keir@xen.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Olaf Hering <olaf@aepfle.de>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: [Xen-devel] tools/libxc/xc_cpuid_x86.c:cpuid()'s inline asm
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Keir,

do you recall what it was that 20976:f8692cc67d67 was supposed to fix?
The code is clearly wrong now on x86-64 - inline asm that uses push/pop
(or other stack pointer manipulation instructions) and memory accesses
that may reference the stack (even if not through %rsp) can't be
expected to work without -mno-red-zone.

The question is whether to use that command line option, or whether to
correct the inline assembly (besides the purpose of your change, I also
wonder why this isn't coded the obvious way, with rBX and rDX explicitly
named in the constraints - on 32-bit this may be to reduce register
pressure, but on 64-bit it's entirely unclear).

Thanks, Jan


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

From xen-devel-bounces@lists.xensource.com Fri Dec 02 09:18:30 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 09:18:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWPFp-0006lX-TX; Fri, 02 Dec 2011 09:18:01 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <xudong.hao@intel.com>) id 1RWPFo-0006lO-Rh
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 09:18:01 +0000
X-Env-Sender: xudong.hao@intel.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1322817439!5868439!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMjkxODc0\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16129 invoked from network); 2 Dec 2011 09:17:19 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-15.tower-216.messagelabs.com with SMTP;
	2 Dec 2011 09:17:19 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga101.jf.intel.com with ESMTP; 02 Dec 2011 01:17:18 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.67,351,1309762800"; d="scan'208";a="82477069"
Received: from pgsmsx601.gar.corp.intel.com ([10.221.43.69])
	by orsmga002.jf.intel.com with ESMTP; 02 Dec 2011 01:17:17 -0800
Received: from pgsmsx104.gar.corp.intel.com (10.221.44.91) by
	pgsmsx601.gar.corp.intel.com (10.221.43.69) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Fri, 2 Dec 2011 17:16:20 +0800
Received: from shsmsx602.ccr.corp.intel.com (10.239.4.104) by
	PGSMSX104.gar.corp.intel.com (10.221.44.91) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Fri, 2 Dec 2011 17:16:20 +0800
Received: from shsmsx502.ccr.corp.intel.com ([10.239.4.96]) by
	SHSMSX602.ccr.corp.intel.com ([10.239.4.104]) with mapi; Fri, 2 Dec 2011
	17:16:18 +0800
From: "Hao, Xudong" <xudong.hao@intel.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Fri, 2 Dec 2011 17:16:17 +0800
Thread-Topic: [Xen-devel] [PATCH] tools/firmware: remove "_PS0/3" Method
Thread-Index: Acywzxb1g2WJ/NuFQaym4lfs9S0NEgAAHzEg
Message-ID: <BC00F5384FCFC9499AF06F92E8B78A9E2870BB4787@shsmsx502.ccr.corp.intel.com>
References: <BC00F5384FCFC9499AF06F92E8B78A9E2870BB473F@shsmsx502.ccr.corp.intel.com>
	<1322815671.31810.265.camel@zakaz.uk.xensource.com>
In-Reply-To: <1322815671.31810.265.camel@zakaz.uk.xensource.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "Tian, Kevin" <kevin.tian@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Shan, 
	Haitao" <haitao.shan@intel.com>, Keir Fraser <keir.xen@gmail.com>
Subject: Re: [Xen-devel] [PATCH] tools/firmware: remove "_PS0/3" Method
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


> -----Original Message-----
> From: Ian Campbell [mailto:Ian.Campbell@citrix.com]
> Sent: Friday, December 02, 2011 4:48 PM
> To: Hao, Xudong
> Cc: xen-devel@lists.xensource.com; Tian, Kevin; Keir Fraser; Shan, Haitao
> Subject: Re: [Xen-devel] [PATCH] tools/firmware: remove "_PS0/3" Method
> 
> On Fri, 2011-12-02 at 08:38 +0000, Hao, Xudong wrote:
> > tools/firmware: remove "_PS0/3" Method
> >
> > Do not expose the ACPI power management "_PS0/3" Method to guest
> > firmware. According to section 3.4 of the APCI specification 4.0, PCI
> > device control the device power through its own specification but not
> > through APCI.
> >
> > Qemu pushes "_PS0/3" to guest will cause a mess between ACPI PM and
> > PCI PM as a result of incorrect ACPI table shipped with the guest
> > BIOS, it may cause a failure of PCI device PM state transition(from
> > PCI_UNKNOWN to PCI_D0).
> 
> How have you tested this and with which guest OSes? Was there a specific
> failure which you observed?
> 
I tested it with SLES11 SP2 guest, where the assigned Kawela VF device can't transit state to D0.

> Is this a different fix for the issue fixed by Linux upstream  changeset
> 47e9037ac166 "PCI hotplug: acpiphp: set current_state to D0 in
> register_slot"?

I look at this patch, the acpiphp module set current_state to D0 as your patch. However, apciphp is used for PCI device hotplug. 
SELS11 SP2 build acpiphp as a module, my case is static assigning VF to guest when guest are creating, loading acpiphp module will workaround this failure, but the device static assignment should not be depend on hotplug mechanism.

> 
> Ian.
> 
> >
> > Signed-off-by: Xudong Hao <xudong.hao@intel.com>
> > Signed-off-by: Haitao Shan <haitao.shan@intel.com>
> >
> > diff -r df7cec2c6c03 tools/firmware/hvmloader/acpi/mk_dsdt.c
> > --- a/tools/firmware/hvmloader/acpi/mk_dsdt.c	Tue Nov 29 13:30:39
> 2011 -0500
> > +++ b/tools/firmware/hvmloader/acpi/mk_dsdt.c	Wed Nov 30 15:08:20
> 2011 +0800
> > @@ -323,8 +323,6 @@
> >       * the ACPI event:
> >       *  _EJ0: eject a device
> >       *  _STA: return a device's status, e.g. enabled or removed
> > -     * Other methods are optional:
> > -     *  _PS0/3: put them here for debug purpose
> >       *
> >       * Eject button would generate a general-purpose event, then the
> >       * control method for this event uses Notify() to inform OSPM which
> @@ -344,13 +342,6 @@
> >              stmt("Name", "_ADR, 0x%08x", ((slot & ~7) << 13) | (slot &
> 7));
> >              /* _SUN == dev */
> >              stmt("Name", "_SUN, 0x%08x", slot >> 3);
> > -            push_block("Method", "_PS0, 0");
> > -            stmt("Store", "0x%02x, \\_GPE.DPT1", slot);
> > -            stmt("Store", "0x80, \\_GPE.DPT2");
> > -            pop_block();
> > -            push_block("Method", "_PS3, 0");
> > -            stmt("Store", "0x%02x, \\_GPE.DPT1", slot);
> > -            stmt("Store", "0x83, \\_GPE.DPT2");
> >              pop_block();
> >              push_block("Method", "_EJ0, 1");
> >              stmt("Store", "0x%02x, \\_GPE.DPT1", slot)
> >
> >
> >
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xensource.com
> > http://lists.xensource.com/xen-devel
> 

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

From xen-devel-bounces@lists.xensource.com Fri Dec 02 09:18:30 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 09:18:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWPFp-0006lX-TX; Fri, 02 Dec 2011 09:18:01 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <xudong.hao@intel.com>) id 1RWPFo-0006lO-Rh
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 09:18:01 +0000
X-Env-Sender: xudong.hao@intel.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1322817439!5868439!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMjkxODc0\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16129 invoked from network); 2 Dec 2011 09:17:19 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-15.tower-216.messagelabs.com with SMTP;
	2 Dec 2011 09:17:19 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga101.jf.intel.com with ESMTP; 02 Dec 2011 01:17:18 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.67,351,1309762800"; d="scan'208";a="82477069"
Received: from pgsmsx601.gar.corp.intel.com ([10.221.43.69])
	by orsmga002.jf.intel.com with ESMTP; 02 Dec 2011 01:17:17 -0800
Received: from pgsmsx104.gar.corp.intel.com (10.221.44.91) by
	pgsmsx601.gar.corp.intel.com (10.221.43.69) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Fri, 2 Dec 2011 17:16:20 +0800
Received: from shsmsx602.ccr.corp.intel.com (10.239.4.104) by
	PGSMSX104.gar.corp.intel.com (10.221.44.91) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Fri, 2 Dec 2011 17:16:20 +0800
Received: from shsmsx502.ccr.corp.intel.com ([10.239.4.96]) by
	SHSMSX602.ccr.corp.intel.com ([10.239.4.104]) with mapi; Fri, 2 Dec 2011
	17:16:18 +0800
From: "Hao, Xudong" <xudong.hao@intel.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Fri, 2 Dec 2011 17:16:17 +0800
Thread-Topic: [Xen-devel] [PATCH] tools/firmware: remove "_PS0/3" Method
Thread-Index: Acywzxb1g2WJ/NuFQaym4lfs9S0NEgAAHzEg
Message-ID: <BC00F5384FCFC9499AF06F92E8B78A9E2870BB4787@shsmsx502.ccr.corp.intel.com>
References: <BC00F5384FCFC9499AF06F92E8B78A9E2870BB473F@shsmsx502.ccr.corp.intel.com>
	<1322815671.31810.265.camel@zakaz.uk.xensource.com>
In-Reply-To: <1322815671.31810.265.camel@zakaz.uk.xensource.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "Tian, Kevin" <kevin.tian@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Shan, 
	Haitao" <haitao.shan@intel.com>, Keir Fraser <keir.xen@gmail.com>
Subject: Re: [Xen-devel] [PATCH] tools/firmware: remove "_PS0/3" Method
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


> -----Original Message-----
> From: Ian Campbell [mailto:Ian.Campbell@citrix.com]
> Sent: Friday, December 02, 2011 4:48 PM
> To: Hao, Xudong
> Cc: xen-devel@lists.xensource.com; Tian, Kevin; Keir Fraser; Shan, Haitao
> Subject: Re: [Xen-devel] [PATCH] tools/firmware: remove "_PS0/3" Method
> 
> On Fri, 2011-12-02 at 08:38 +0000, Hao, Xudong wrote:
> > tools/firmware: remove "_PS0/3" Method
> >
> > Do not expose the ACPI power management "_PS0/3" Method to guest
> > firmware. According to section 3.4 of the APCI specification 4.0, PCI
> > device control the device power through its own specification but not
> > through APCI.
> >
> > Qemu pushes "_PS0/3" to guest will cause a mess between ACPI PM and
> > PCI PM as a result of incorrect ACPI table shipped with the guest
> > BIOS, it may cause a failure of PCI device PM state transition(from
> > PCI_UNKNOWN to PCI_D0).
> 
> How have you tested this and with which guest OSes? Was there a specific
> failure which you observed?
> 
I tested it with SLES11 SP2 guest, where the assigned Kawela VF device can't transit state to D0.

> Is this a different fix for the issue fixed by Linux upstream  changeset
> 47e9037ac166 "PCI hotplug: acpiphp: set current_state to D0 in
> register_slot"?

I look at this patch, the acpiphp module set current_state to D0 as your patch. However, apciphp is used for PCI device hotplug. 
SELS11 SP2 build acpiphp as a module, my case is static assigning VF to guest when guest are creating, loading acpiphp module will workaround this failure, but the device static assignment should not be depend on hotplug mechanism.

> 
> Ian.
> 
> >
> > Signed-off-by: Xudong Hao <xudong.hao@intel.com>
> > Signed-off-by: Haitao Shan <haitao.shan@intel.com>
> >
> > diff -r df7cec2c6c03 tools/firmware/hvmloader/acpi/mk_dsdt.c
> > --- a/tools/firmware/hvmloader/acpi/mk_dsdt.c	Tue Nov 29 13:30:39
> 2011 -0500
> > +++ b/tools/firmware/hvmloader/acpi/mk_dsdt.c	Wed Nov 30 15:08:20
> 2011 +0800
> > @@ -323,8 +323,6 @@
> >       * the ACPI event:
> >       *  _EJ0: eject a device
> >       *  _STA: return a device's status, e.g. enabled or removed
> > -     * Other methods are optional:
> > -     *  _PS0/3: put them here for debug purpose
> >       *
> >       * Eject button would generate a general-purpose event, then the
> >       * control method for this event uses Notify() to inform OSPM which
> @@ -344,13 +342,6 @@
> >              stmt("Name", "_ADR, 0x%08x", ((slot & ~7) << 13) | (slot &
> 7));
> >              /* _SUN == dev */
> >              stmt("Name", "_SUN, 0x%08x", slot >> 3);
> > -            push_block("Method", "_PS0, 0");
> > -            stmt("Store", "0x%02x, \\_GPE.DPT1", slot);
> > -            stmt("Store", "0x80, \\_GPE.DPT2");
> > -            pop_block();
> > -            push_block("Method", "_PS3, 0");
> > -            stmt("Store", "0x%02x, \\_GPE.DPT1", slot);
> > -            stmt("Store", "0x83, \\_GPE.DPT2");
> >              pop_block();
> >              push_block("Method", "_EJ0, 1");
> >              stmt("Store", "0x%02x, \\_GPE.DPT1", slot)
> >
> >
> >
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xensource.com
> > http://lists.xensource.com/xen-devel
> 

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

From xen-devel-bounces@lists.xensource.com Fri Dec 02 09:23:58 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 09:23:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWPLC-0006to-Mv; Fri, 02 Dec 2011 09:23:34 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RWPLB-0006te-8D
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 09:23:33 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1322817772!5578999!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQyOTg=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7623 invoked from network); 2 Dec 2011 09:22:52 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-10.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 2 Dec 2011 09:22:52 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 02 Dec 2011 09:22:51 +0000
Message-Id: <4ED8A6FB0200007800065039@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 02 Dec 2011 09:22:51 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@eu.citrix.com>,
	"Andres Lagar-Cavilla" <andres@lagarcavilla.org>
References: <patchbomb.1322772713@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1322772713@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com, olaf@aepfle.de, andres@gridcentric.ca,
	mike.mcclurg@citrix.com, jonathan.ludlam@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH 0 of 2] Paging support updates for XCP dom0
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 01.12.11 at 21:51, Andres Lagar-Cavilla <andres@lagarcavilla.org> wrote:
> This is a cherry pick of two patches that add support for guest paged out
> frames in the XCP 2.6.32 dom0 patch queue.

The better thing would probably be to re-base the tree to current
SLE11 SP1 sources. Not sure who would do that though (and also
not sure what state the tree is in maintenance wise). Ian?

Jan

> First patch propagates the ENOENT returned by the hypervisor in the case
> of a paged out page, all the way up the call chain to the MMAPBATCH_V2
> ioctl. The ioctl is mainly used to harvest those return values and retry.
> 
> The second patch adds retry loops to all backend grant operations (map and
> netback copy), in the case of a paged out frame.
> 
> Signed-off-by: Olaf Hering <olaf@aepfle.de>
> Signed-off-by: Jan Beulich <jbeulich@novell.com>
> Acked-by: Patrick Colp <pjcolp@cs.ubc.ca>
> Acked-by: Andres Lagar-Cavilla <andres@lagarcavilla>
> Ported and submitted by Andres Lagar-Cavilla
> 
>  arch/x86/mm/ioremap-xen.c                  |  12 ++----
>  drivers/xen/blkback/blkback.c              |   6 ++-
>  drivers/xen/blkback/interface.c            |   9 +++-
>  drivers/xen/core/gnttab.c                  |   4 +-
>  drivers/xen/gntdev/gntdev.c                |  49 +++++++++++++++++------------
>  drivers/xen/netback/interface.c            |   5 +-
>  drivers/xen/netback/netback.c              |  16 ++++++---
>  drivers/xen/scsiback/interface.c           |  10 +++---
>  drivers/xen/scsiback/scsiback.c            |   4 +-
>  drivers/xen/tpmback/interface.c            |   7 +--
>  drivers/xen/tpmback/tpmback.c              |  20 ++++-------
>  drivers/xen/usbback/interface.c            |  16 ++++----
>  drivers/xen/usbback/usbback.c              |   4 +-
>  drivers/xen/xenbus/xenbus_backend_client.c |  10 +++---
>  include/xen/gnttab.h                       |  37 ++++++++++++++++++++++
>  15 files changed, 130 insertions(+), 79 deletions(-)




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

From xen-devel-bounces@lists.xensource.com Fri Dec 02 09:23:58 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 09:23:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWPLC-0006to-Mv; Fri, 02 Dec 2011 09:23:34 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RWPLB-0006te-8D
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 09:23:33 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1322817772!5578999!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQyOTg=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7623 invoked from network); 2 Dec 2011 09:22:52 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-10.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 2 Dec 2011 09:22:52 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 02 Dec 2011 09:22:51 +0000
Message-Id: <4ED8A6FB0200007800065039@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 02 Dec 2011 09:22:51 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@eu.citrix.com>,
	"Andres Lagar-Cavilla" <andres@lagarcavilla.org>
References: <patchbomb.1322772713@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1322772713@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com, olaf@aepfle.de, andres@gridcentric.ca,
	mike.mcclurg@citrix.com, jonathan.ludlam@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH 0 of 2] Paging support updates for XCP dom0
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 01.12.11 at 21:51, Andres Lagar-Cavilla <andres@lagarcavilla.org> wrote:
> This is a cherry pick of two patches that add support for guest paged out
> frames in the XCP 2.6.32 dom0 patch queue.

The better thing would probably be to re-base the tree to current
SLE11 SP1 sources. Not sure who would do that though (and also
not sure what state the tree is in maintenance wise). Ian?

Jan

> First patch propagates the ENOENT returned by the hypervisor in the case
> of a paged out page, all the way up the call chain to the MMAPBATCH_V2
> ioctl. The ioctl is mainly used to harvest those return values and retry.
> 
> The second patch adds retry loops to all backend grant operations (map and
> netback copy), in the case of a paged out frame.
> 
> Signed-off-by: Olaf Hering <olaf@aepfle.de>
> Signed-off-by: Jan Beulich <jbeulich@novell.com>
> Acked-by: Patrick Colp <pjcolp@cs.ubc.ca>
> Acked-by: Andres Lagar-Cavilla <andres@lagarcavilla>
> Ported and submitted by Andres Lagar-Cavilla
> 
>  arch/x86/mm/ioremap-xen.c                  |  12 ++----
>  drivers/xen/blkback/blkback.c              |   6 ++-
>  drivers/xen/blkback/interface.c            |   9 +++-
>  drivers/xen/core/gnttab.c                  |   4 +-
>  drivers/xen/gntdev/gntdev.c                |  49 +++++++++++++++++------------
>  drivers/xen/netback/interface.c            |   5 +-
>  drivers/xen/netback/netback.c              |  16 ++++++---
>  drivers/xen/scsiback/interface.c           |  10 +++---
>  drivers/xen/scsiback/scsiback.c            |   4 +-
>  drivers/xen/tpmback/interface.c            |   7 +--
>  drivers/xen/tpmback/tpmback.c              |  20 ++++-------
>  drivers/xen/usbback/interface.c            |  16 ++++----
>  drivers/xen/usbback/usbback.c              |   4 +-
>  drivers/xen/xenbus/xenbus_backend_client.c |  10 +++---
>  include/xen/gnttab.h                       |  37 ++++++++++++++++++++++
>  15 files changed, 130 insertions(+), 79 deletions(-)




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

From xen-devel-bounces@lists.xensource.com Fri Dec 02 09:27:42 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 09:27:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWPOx-00076r-3o; Fri, 02 Dec 2011 09:27:27 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RWPOv-00076d-W7
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 09:27:26 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1322817974!46299669!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQyOTg=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11497 invoked from network); 2 Dec 2011 09:26:14 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-10.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 2 Dec 2011 09:26:14 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 02 Dec 2011 09:26:50 +0000
Message-Id: <4ED8A7E8020000780006503C@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 02 Dec 2011 09:26:48 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
References: <patchbomb.1322772713@xdev.gridcentric.ca>
	<df9e25a0189b1a5a94b1.1322772714@xdev.gridcentric.ca>
In-Reply-To: <df9e25a0189b1a5a94b1.1322772714@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com, olaf@aepfle.de, andres@gridcentric.ca,
	mike.mcclurg@citrix.com, jonathan.ludlam@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH 1 of 2] xen/x86: make
 __direct_remap_pfn_range()'s return value meaningful
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 >>> On 01.12.11 at 21:51, Andres Lagar-Cavilla <andres@lagarcavilla.org> wrote:
> arch/x86/mm/ioremap-xen.c |  12 ++++--------
>  1 files changed, 4 insertions(+), 8 deletions(-)
> 
> 
> This change fixes the xc_map_foreign_bulk interface, which would
> otherwise cause SIGBUS when pages are gone because -ENOENT is not
> returned as expected by the IOCTL_PRIVCMD_MMAPBATCH_V2 ioctl.
> 
> Signed-off-by: Jan Beulich <jbeulich@novell.com>

You lost authorship here.

Jan


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

From xen-devel-bounces@lists.xensource.com Fri Dec 02 09:27:42 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 09:27:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWPOx-00076r-3o; Fri, 02 Dec 2011 09:27:27 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RWPOv-00076d-W7
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 09:27:26 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1322817974!46299669!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQyOTg=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11497 invoked from network); 2 Dec 2011 09:26:14 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-10.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 2 Dec 2011 09:26:14 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 02 Dec 2011 09:26:50 +0000
Message-Id: <4ED8A7E8020000780006503C@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 02 Dec 2011 09:26:48 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
References: <patchbomb.1322772713@xdev.gridcentric.ca>
	<df9e25a0189b1a5a94b1.1322772714@xdev.gridcentric.ca>
In-Reply-To: <df9e25a0189b1a5a94b1.1322772714@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com, olaf@aepfle.de, andres@gridcentric.ca,
	mike.mcclurg@citrix.com, jonathan.ludlam@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH 1 of 2] xen/x86: make
 __direct_remap_pfn_range()'s return value meaningful
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 >>> On 01.12.11 at 21:51, Andres Lagar-Cavilla <andres@lagarcavilla.org> wrote:
> arch/x86/mm/ioremap-xen.c |  12 ++++--------
>  1 files changed, 4 insertions(+), 8 deletions(-)
> 
> 
> This change fixes the xc_map_foreign_bulk interface, which would
> otherwise cause SIGBUS when pages are gone because -ENOENT is not
> returned as expected by the IOCTL_PRIVCMD_MMAPBATCH_V2 ioctl.
> 
> Signed-off-by: Jan Beulich <jbeulich@novell.com>

You lost authorship here.

Jan


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

From xen-devel-bounces@lists.xensource.com Fri Dec 02 09:32:54 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 09: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.xensource.com>)
	id 1RWPTz-0007kS-Ts; Fri, 02 Dec 2011 09:32:39 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RWPTy-0007k1-34
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 09:32:38 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1322818317!5589151!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTg0Mw==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21727 invoked from network); 2 Dec 2011 09:31:57 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Dec 2011 09:31:57 -0000
X-IronPort-AV: E=Sophos;i="4.71,282,1320624000"; 
   d="scan'208";a="9244842"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Dec 2011 09:31:56 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 2 Dec 2011
	09:31:56 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "Hao, Xudong" <xudong.hao@intel.com>
Date: Fri, 2 Dec 2011 09:31:56 +0000
In-Reply-To: <BC00F5384FCFC9499AF06F92E8B78A9E2870BB4787@shsmsx502.ccr.corp.intel.com>
References: <BC00F5384FCFC9499AF06F92E8B78A9E2870BB473F@shsmsx502.ccr.corp.intel.com>
	<1322815671.31810.265.camel@zakaz.uk.xensource.com>
	<BC00F5384FCFC9499AF06F92E8B78A9E2870BB4787@shsmsx502.ccr.corp.intel.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322818316.31810.298.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "Tian, Kevin" <kevin.tian@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Shan, 
	Haitao" <haitao.shan@intel.com>, Allen Kay <allen.m.kay@intel.com>,
	Keir Fraser <keir.xen@gmail.com>,
	Stefano Stabellini <stefano.stabellini@citrix.com>
Subject: Re: [Xen-devel] [PATCH] tools/firmware: remove "_PS0/3" Method
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2011-12-02 at 09:16 +0000, Hao, Xudong wrote:
> > -----Original Message-----
> > From: Ian Campbell [mailto:Ian.Campbell@citrix.com]
> > Sent: Friday, December 02, 2011 4:48 PM
> > To: Hao, Xudong
> > Cc: xen-devel@lists.xensource.com; Tian, Kevin; Keir Fraser; Shan, Haitao
> > Subject: Re: [Xen-devel] [PATCH] tools/firmware: remove "_PS0/3" Method
> > 
> > On Fri, 2011-12-02 at 08:38 +0000, Hao, Xudong wrote:
> > > tools/firmware: remove "_PS0/3" Method
> > >
> > > Do not expose the ACPI power management "_PS0/3" Method to guest
> > > firmware. According to section 3.4 of the APCI specification 4.0, PCI
> > > device control the device power through its own specification but not
> > > through APCI.
> > >
> > > Qemu pushes "_PS0/3" to guest will cause a mess between ACPI PM and
> > > PCI PM as a result of incorrect ACPI table shipped with the guest
> > > BIOS, it may cause a failure of PCI device PM state transition(from
> > > PCI_UNKNOWN to PCI_D0).
> > 
> > How have you tested this and with which guest OSes? Was there a specific
> > failure which you observed?
> > 
> I tested it with SLES11 SP2 guest, where the assigned Kawela VF device can't transit state to D0.
> 
> > Is this a different fix for the issue fixed by Linux upstream  changeset
> > 47e9037ac166 "PCI hotplug: acpiphp: set current_state to D0 in
> > register_slot"?
> 
> I look at this patch, the acpiphp module set current_state to D0 as
> your patch. However, apciphp is used for PCI device hotplug. 
> SELS11 SP2 build acpiphp as a module, my case is static assigning VF
> to guest when guest are creating, loading acpiphp module will
> workaround this failure, but the device static assignment should not
> be depend on hotplug mechanism.

Have you verified that hotplug still works after your change?

Have you tested any other OSes? How does Windows for example respond to
this change in the ACPI tables?

Are there any devices which do not implement PCI PM and therefore rely
on this ACPI mechanism to function? My understanding was that
47e9037ac166 was required in part due to the lack of PCI PM support on
some VF devices. I think it was a different Intel SR-IOV NIC than the
one you are testing, an 82559 if [0] is to be believed.

Also there was a previous attempt to remove _PS0 in [1]. Allen Kay (CCd)
tested and reported that removing these values causes Windows not to
boot. It was suggested in that thread that both _PS0 and _PS3 need to be
removed (which you do) but it was also suggested that doing so breaks
Linux S3 support, have you tried this?

Ian.

[0]
http://old-list-archives.xen.org/archives/html/xen-devel/2011-03/msg00434.html
[1]
http://old-list-archives.xen.org/archives/html/xen-devel/2011-02/threads.html

> > 
> > Ian.
> > 
> > >
> > > Signed-off-by: Xudong Hao <xudong.hao@intel.com>
> > > Signed-off-by: Haitao Shan <haitao.shan@intel.com>
> > >
> > > diff -r df7cec2c6c03 tools/firmware/hvmloader/acpi/mk_dsdt.c
> > > --- a/tools/firmware/hvmloader/acpi/mk_dsdt.c	Tue Nov 29 13:30:39
> > 2011 -0500
> > > +++ b/tools/firmware/hvmloader/acpi/mk_dsdt.c	Wed Nov 30 15:08:20
> > 2011 +0800
> > > @@ -323,8 +323,6 @@
> > >       * the ACPI event:
> > >       *  _EJ0: eject a device
> > >       *  _STA: return a device's status, e.g. enabled or removed
> > > -     * Other methods are optional:
> > > -     *  _PS0/3: put them here for debug purpose
> > >       *
> > >       * Eject button would generate a general-purpose event, then the
> > >       * control method for this event uses Notify() to inform OSPM which
> > @@ -344,13 +342,6 @@
> > >              stmt("Name", "_ADR, 0x%08x", ((slot & ~7) << 13) | (slot &
> > 7));
> > >              /* _SUN == dev */
> > >              stmt("Name", "_SUN, 0x%08x", slot >> 3);
> > > -            push_block("Method", "_PS0, 0");
> > > -            stmt("Store", "0x%02x, \\_GPE.DPT1", slot);
> > > -            stmt("Store", "0x80, \\_GPE.DPT2");
> > > -            pop_block();
> > > -            push_block("Method", "_PS3, 0");
> > > -            stmt("Store", "0x%02x, \\_GPE.DPT1", slot);
> > > -            stmt("Store", "0x83, \\_GPE.DPT2");
> > >              pop_block();
> > >              push_block("Method", "_EJ0, 1");
> > >              stmt("Store", "0x%02x, \\_GPE.DPT1", slot)
> > >
> > >
> > >
> > >
> > > _______________________________________________
> > > Xen-devel mailing list
> > > Xen-devel@lists.xensource.com
> > > http://lists.xensource.com/xen-devel
> > 
> 



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

From xen-devel-bounces@lists.xensource.com Fri Dec 02 09:32:54 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 09: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.xensource.com>)
	id 1RWPTz-0007kS-Ts; Fri, 02 Dec 2011 09:32:39 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RWPTy-0007k1-34
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 09:32:38 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1322818317!5589151!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTg0Mw==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21727 invoked from network); 2 Dec 2011 09:31:57 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Dec 2011 09:31:57 -0000
X-IronPort-AV: E=Sophos;i="4.71,282,1320624000"; 
   d="scan'208";a="9244842"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Dec 2011 09:31:56 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 2 Dec 2011
	09:31:56 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "Hao, Xudong" <xudong.hao@intel.com>
Date: Fri, 2 Dec 2011 09:31:56 +0000
In-Reply-To: <BC00F5384FCFC9499AF06F92E8B78A9E2870BB4787@shsmsx502.ccr.corp.intel.com>
References: <BC00F5384FCFC9499AF06F92E8B78A9E2870BB473F@shsmsx502.ccr.corp.intel.com>
	<1322815671.31810.265.camel@zakaz.uk.xensource.com>
	<BC00F5384FCFC9499AF06F92E8B78A9E2870BB4787@shsmsx502.ccr.corp.intel.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322818316.31810.298.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "Tian, Kevin" <kevin.tian@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Shan, 
	Haitao" <haitao.shan@intel.com>, Allen Kay <allen.m.kay@intel.com>,
	Keir Fraser <keir.xen@gmail.com>,
	Stefano Stabellini <stefano.stabellini@citrix.com>
Subject: Re: [Xen-devel] [PATCH] tools/firmware: remove "_PS0/3" Method
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2011-12-02 at 09:16 +0000, Hao, Xudong wrote:
> > -----Original Message-----
> > From: Ian Campbell [mailto:Ian.Campbell@citrix.com]
> > Sent: Friday, December 02, 2011 4:48 PM
> > To: Hao, Xudong
> > Cc: xen-devel@lists.xensource.com; Tian, Kevin; Keir Fraser; Shan, Haitao
> > Subject: Re: [Xen-devel] [PATCH] tools/firmware: remove "_PS0/3" Method
> > 
> > On Fri, 2011-12-02 at 08:38 +0000, Hao, Xudong wrote:
> > > tools/firmware: remove "_PS0/3" Method
> > >
> > > Do not expose the ACPI power management "_PS0/3" Method to guest
> > > firmware. According to section 3.4 of the APCI specification 4.0, PCI
> > > device control the device power through its own specification but not
> > > through APCI.
> > >
> > > Qemu pushes "_PS0/3" to guest will cause a mess between ACPI PM and
> > > PCI PM as a result of incorrect ACPI table shipped with the guest
> > > BIOS, it may cause a failure of PCI device PM state transition(from
> > > PCI_UNKNOWN to PCI_D0).
> > 
> > How have you tested this and with which guest OSes? Was there a specific
> > failure which you observed?
> > 
> I tested it with SLES11 SP2 guest, where the assigned Kawela VF device can't transit state to D0.
> 
> > Is this a different fix for the issue fixed by Linux upstream  changeset
> > 47e9037ac166 "PCI hotplug: acpiphp: set current_state to D0 in
> > register_slot"?
> 
> I look at this patch, the acpiphp module set current_state to D0 as
> your patch. However, apciphp is used for PCI device hotplug. 
> SELS11 SP2 build acpiphp as a module, my case is static assigning VF
> to guest when guest are creating, loading acpiphp module will
> workaround this failure, but the device static assignment should not
> be depend on hotplug mechanism.

Have you verified that hotplug still works after your change?

Have you tested any other OSes? How does Windows for example respond to
this change in the ACPI tables?

Are there any devices which do not implement PCI PM and therefore rely
on this ACPI mechanism to function? My understanding was that
47e9037ac166 was required in part due to the lack of PCI PM support on
some VF devices. I think it was a different Intel SR-IOV NIC than the
one you are testing, an 82559 if [0] is to be believed.

Also there was a previous attempt to remove _PS0 in [1]. Allen Kay (CCd)
tested and reported that removing these values causes Windows not to
boot. It was suggested in that thread that both _PS0 and _PS3 need to be
removed (which you do) but it was also suggested that doing so breaks
Linux S3 support, have you tried this?

Ian.

[0]
http://old-list-archives.xen.org/archives/html/xen-devel/2011-03/msg00434.html
[1]
http://old-list-archives.xen.org/archives/html/xen-devel/2011-02/threads.html

> > 
> > Ian.
> > 
> > >
> > > Signed-off-by: Xudong Hao <xudong.hao@intel.com>
> > > Signed-off-by: Haitao Shan <haitao.shan@intel.com>
> > >
> > > diff -r df7cec2c6c03 tools/firmware/hvmloader/acpi/mk_dsdt.c
> > > --- a/tools/firmware/hvmloader/acpi/mk_dsdt.c	Tue Nov 29 13:30:39
> > 2011 -0500
> > > +++ b/tools/firmware/hvmloader/acpi/mk_dsdt.c	Wed Nov 30 15:08:20
> > 2011 +0800
> > > @@ -323,8 +323,6 @@
> > >       * the ACPI event:
> > >       *  _EJ0: eject a device
> > >       *  _STA: return a device's status, e.g. enabled or removed
> > > -     * Other methods are optional:
> > > -     *  _PS0/3: put them here for debug purpose
> > >       *
> > >       * Eject button would generate a general-purpose event, then the
> > >       * control method for this event uses Notify() to inform OSPM which
> > @@ -344,13 +342,6 @@
> > >              stmt("Name", "_ADR, 0x%08x", ((slot & ~7) << 13) | (slot &
> > 7));
> > >              /* _SUN == dev */
> > >              stmt("Name", "_SUN, 0x%08x", slot >> 3);
> > > -            push_block("Method", "_PS0, 0");
> > > -            stmt("Store", "0x%02x, \\_GPE.DPT1", slot);
> > > -            stmt("Store", "0x80, \\_GPE.DPT2");
> > > -            pop_block();
> > > -            push_block("Method", "_PS3, 0");
> > > -            stmt("Store", "0x%02x, \\_GPE.DPT1", slot);
> > > -            stmt("Store", "0x83, \\_GPE.DPT2");
> > >              pop_block();
> > >              push_block("Method", "_EJ0, 1");
> > >              stmt("Store", "0x%02x, \\_GPE.DPT1", slot)
> > >
> > >
> > >
> > >
> > > _______________________________________________
> > > Xen-devel mailing list
> > > Xen-devel@lists.xensource.com
> > > http://lists.xensource.com/xen-devel
> > 
> 



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

From xen-devel-bounces@lists.xensource.com Fri Dec 02 09:46:11 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 09:46:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWPgm-0008RQ-RB; Fri, 02 Dec 2011 09:45:52 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RWPgl-0008R9-OW
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 09:45:52 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1322819108!3981298!1
X-Originating-IP: [209.85.210.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32310 invoked from network); 2 Dec 2011 09:45:10 -0000
Received: from mail-pz0-f43.google.com (HELO mail-pz0-f43.google.com)
	(209.85.210.43)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Dec 2011 09:45:10 -0000
Received: by dadz13 with SMTP id z13so7957259dad.30
	for <xen-devel@lists.xensource.com>;
	Fri, 02 Dec 2011 01:45:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:content-type;
	bh=X3w4XadGb6eOg3vi5FQtu6oSVOO6DPsz5B/u+yWBRFI=;
	b=wuneqI1jb2NYetC/iGtAvwW8K7vat4XqS4tFPkP4DrYnMu7YpniVCK+aBPTtxjFobw
	2JJEXKKUyv/1/spD+SISPMoqH8WhUg+tQaGNGqMhwWWqiRzXlDXwv5ceXAw7160ApEuE
	Vz1ps++ESHLfZAqJa1lhJXvuwSJhAZngAEjA8=
MIME-Version: 1.0
Received: by 10.68.72.36 with SMTP id a4mr13024751pbv.4.1322819108516; Fri, 02
	Dec 2011 01:45:08 -0800 (PST)
Received: by 10.142.212.12 with HTTP; Fri, 2 Dec 2011 01:45:08 -0800 (PST)
In-Reply-To: <CAPLaKK5VC7YvMyvGM07f=ngOrbGbvLLDA1J8nqaxDsntux-bbQ@mail.gmail.com>
References: <CAPLaKK5VC7YvMyvGM07f=ngOrbGbvLLDA1J8nqaxDsntux-bbQ@mail.gmail.com>
Date: Fri, 2 Dec 2011 10:45:08 +0100
X-Google-Sender-Auth: tdf79HJRS26zbL60XsRzGUDKwpY
Message-ID: <CAPLaKK6=L4wxWv6GqDpeV_OMukFgZSWM_pik6+jQ1tA7Ahsf3A@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] libxl: error when destroying domain on NetBSD
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Also, libxl_domain_destroy is called twice, the first time it is
called from destroy_domain (xl_cmdimpl.c), and the second time it is
called from handle_domain_death, the errors shown on the log above are
from the second call, the one that comes from handle_domain_death.
Don't know if this is the normal behavior, but it seems quite strange
that libxl_domain_destroy is called twice.

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

From xen-devel-bounces@lists.xensource.com Fri Dec 02 09:46:11 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 09:46:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWPgm-0008RQ-RB; Fri, 02 Dec 2011 09:45:52 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RWPgl-0008R9-OW
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 09:45:52 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1322819108!3981298!1
X-Originating-IP: [209.85.210.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32310 invoked from network); 2 Dec 2011 09:45:10 -0000
Received: from mail-pz0-f43.google.com (HELO mail-pz0-f43.google.com)
	(209.85.210.43)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Dec 2011 09:45:10 -0000
Received: by dadz13 with SMTP id z13so7957259dad.30
	for <xen-devel@lists.xensource.com>;
	Fri, 02 Dec 2011 01:45:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:content-type;
	bh=X3w4XadGb6eOg3vi5FQtu6oSVOO6DPsz5B/u+yWBRFI=;
	b=wuneqI1jb2NYetC/iGtAvwW8K7vat4XqS4tFPkP4DrYnMu7YpniVCK+aBPTtxjFobw
	2JJEXKKUyv/1/spD+SISPMoqH8WhUg+tQaGNGqMhwWWqiRzXlDXwv5ceXAw7160ApEuE
	Vz1ps++ESHLfZAqJa1lhJXvuwSJhAZngAEjA8=
MIME-Version: 1.0
Received: by 10.68.72.36 with SMTP id a4mr13024751pbv.4.1322819108516; Fri, 02
	Dec 2011 01:45:08 -0800 (PST)
Received: by 10.142.212.12 with HTTP; Fri, 2 Dec 2011 01:45:08 -0800 (PST)
In-Reply-To: <CAPLaKK5VC7YvMyvGM07f=ngOrbGbvLLDA1J8nqaxDsntux-bbQ@mail.gmail.com>
References: <CAPLaKK5VC7YvMyvGM07f=ngOrbGbvLLDA1J8nqaxDsntux-bbQ@mail.gmail.com>
Date: Fri, 2 Dec 2011 10:45:08 +0100
X-Google-Sender-Auth: tdf79HJRS26zbL60XsRzGUDKwpY
Message-ID: <CAPLaKK6=L4wxWv6GqDpeV_OMukFgZSWM_pik6+jQ1tA7Ahsf3A@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] libxl: error when destroying domain on NetBSD
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Also, libxl_domain_destroy is called twice, the first time it is
called from destroy_domain (xl_cmdimpl.c), and the second time it is
called from handle_domain_death, the errors shown on the log above are
from the second call, the one that comes from handle_domain_death.
Don't know if this is the normal behavior, but it seems quite strange
that libxl_domain_destroy is called twice.

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

From xen-devel-bounces@lists.xensource.com Fri Dec 02 09:59:01 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 09:59:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWPsy-0000GT-58; Fri, 02 Dec 2011 09:58:28 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RWPsw-0000GO-R7
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 09:58:27 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1322819866!5590260!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTg0Mw==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14091 invoked from network); 2 Dec 2011 09:57:46 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Dec 2011 09:57:46 -0000
X-IronPort-AV: E=Sophos;i="4.71,282,1320624000"; 
   d="scan'208";a="9245572"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Dec 2011 09:57:46 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 2 Dec 2011
	09:57:46 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau =?ISO-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
Date: Fri, 2 Dec 2011 09:57:45 +0000
In-Reply-To: <CAPLaKK6=L4wxWv6GqDpeV_OMukFgZSWM_pik6+jQ1tA7Ahsf3A@mail.gmail.com>
References: <CAPLaKK5VC7YvMyvGM07f=ngOrbGbvLLDA1J8nqaxDsntux-bbQ@mail.gmail.com>
	<CAPLaKK6=L4wxWv6GqDpeV_OMukFgZSWM_pik6+jQ1tA7Ahsf3A@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322819865.31810.319.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] libxl: error when destroying domain on NetBSD
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gRnJpLCAyMDExLTEyLTAyIGF0IDA5OjQ1ICswMDAwLCBSb2dlciBQYXUgTW9ubsOpIHdyb3Rl
Ogo+IEFsc28sIGxpYnhsX2RvbWFpbl9kZXN0cm95IGlzIGNhbGxlZCB0d2ljZSwgdGhlIGZpcnN0
IHRpbWUgaXQgaXMKPiBjYWxsZWQgZnJvbSBkZXN0cm95X2RvbWFpbiAoeGxfY21kaW1wbC5jKSwg
YW5kIHRoZSBzZWNvbmQgdGltZSBpdCBpcwo+IGNhbGxlZCBmcm9tIGhhbmRsZV9kb21haW5fZGVh
dGgsIHRoZSBlcnJvcnMgc2hvd24gb24gdGhlIGxvZyBhYm92ZSBhcmUKPiBmcm9tIHRoZSBzZWNv
bmQgY2FsbCwgdGhlIG9uZSB0aGF0IGNvbWVzIGZyb20gaGFuZGxlX2RvbWFpbl9kZWF0aC4KPiBE
b24ndCBrbm93IGlmIHRoaXMgaXMgdGhlIG5vcm1hbCBiZWhhdmlvciwgYnV0IGl0IHNlZW1zIHF1
aXRlIHN0cmFuZ2UKPiB0aGF0IGxpYnhsX2RvbWFpbl9kZXN0cm95IGlzIGNhbGxlZCB0d2ljZS4K
Ckl0J3Mgbm9ybWFsIEkgdGhpbmsuIGhhbmRsZV9kb21haW5fZGVhdGgoKSBpcyB0aGVyZSB0byBk
ZWFsIHdpdGgKZ3JhY2VmdWwgc2h1dGRvd24gYW5kIHJlYm9vdCBzY2VuYXJpb3MgZS5nLiB0byBj
bGVhciB1cCBhZnRlciB0aGUgZG9tYWluCmFuZCByZXN0YXJ0IGFzIG5lY2Vzc2FyeS4KCnhsIGRl
c3Ryb3kgaXMgZXhwbGljdGx5IHRoZSBjb21tYW5kIHdoaWNoIHNob290cyB0aGUgZG9tYWluIGlu
IHRoZSBoZWFkCmFuZCBzbyBpdCBhbHNvIGNhbGxzIGRlc3Ryb3kuIElmIHlvdSB3YW50IGdyYWNl
ZnVsIHlvdSBzaG91bGQgdXNlICJ4bApzaHV0ZG93biIuCgpBbHRob3VnaCBoYW5kbGVfZG9tYWlu
X2RlYXRoIGFsc28gcGlja3MgdXAgb24gdGhlIGRlc3Ryb3kgaXQgc2hvdWxkbid0CmJlIGRvaW5n
IHRvbyBtdWNoIGluIHRoYXQgY2FzZSBzaW5jZSB0aGUgaW50ZXJlc3Rpbmcgd29yayBoYXMgYWxy
ZWFkeQpoYXBwZW5lZC4gVGhlIGludGVyZXN0aW5nIGxvZ3Mgd2lsbCBiZSB0aGUgeGwgLXZ2diBk
ZXN0cm95IG9uZXMgSSB0aGluay4KCklhbi4KCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlz
dHMueGVuc291cmNlLmNvbQpodHRwOi8vbGlzdHMueGVuc291cmNlLmNvbS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Fri Dec 02 09:59:01 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 09:59:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWPsy-0000GT-58; Fri, 02 Dec 2011 09:58:28 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RWPsw-0000GO-R7
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 09:58:27 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1322819866!5590260!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTg0Mw==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14091 invoked from network); 2 Dec 2011 09:57:46 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Dec 2011 09:57:46 -0000
X-IronPort-AV: E=Sophos;i="4.71,282,1320624000"; 
   d="scan'208";a="9245572"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Dec 2011 09:57:46 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 2 Dec 2011
	09:57:46 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau =?ISO-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
Date: Fri, 2 Dec 2011 09:57:45 +0000
In-Reply-To: <CAPLaKK6=L4wxWv6GqDpeV_OMukFgZSWM_pik6+jQ1tA7Ahsf3A@mail.gmail.com>
References: <CAPLaKK5VC7YvMyvGM07f=ngOrbGbvLLDA1J8nqaxDsntux-bbQ@mail.gmail.com>
	<CAPLaKK6=L4wxWv6GqDpeV_OMukFgZSWM_pik6+jQ1tA7Ahsf3A@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322819865.31810.319.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] libxl: error when destroying domain on NetBSD
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gRnJpLCAyMDExLTEyLTAyIGF0IDA5OjQ1ICswMDAwLCBSb2dlciBQYXUgTW9ubsOpIHdyb3Rl
Ogo+IEFsc28sIGxpYnhsX2RvbWFpbl9kZXN0cm95IGlzIGNhbGxlZCB0d2ljZSwgdGhlIGZpcnN0
IHRpbWUgaXQgaXMKPiBjYWxsZWQgZnJvbSBkZXN0cm95X2RvbWFpbiAoeGxfY21kaW1wbC5jKSwg
YW5kIHRoZSBzZWNvbmQgdGltZSBpdCBpcwo+IGNhbGxlZCBmcm9tIGhhbmRsZV9kb21haW5fZGVh
dGgsIHRoZSBlcnJvcnMgc2hvd24gb24gdGhlIGxvZyBhYm92ZSBhcmUKPiBmcm9tIHRoZSBzZWNv
bmQgY2FsbCwgdGhlIG9uZSB0aGF0IGNvbWVzIGZyb20gaGFuZGxlX2RvbWFpbl9kZWF0aC4KPiBE
b24ndCBrbm93IGlmIHRoaXMgaXMgdGhlIG5vcm1hbCBiZWhhdmlvciwgYnV0IGl0IHNlZW1zIHF1
aXRlIHN0cmFuZ2UKPiB0aGF0IGxpYnhsX2RvbWFpbl9kZXN0cm95IGlzIGNhbGxlZCB0d2ljZS4K
Ckl0J3Mgbm9ybWFsIEkgdGhpbmsuIGhhbmRsZV9kb21haW5fZGVhdGgoKSBpcyB0aGVyZSB0byBk
ZWFsIHdpdGgKZ3JhY2VmdWwgc2h1dGRvd24gYW5kIHJlYm9vdCBzY2VuYXJpb3MgZS5nLiB0byBj
bGVhciB1cCBhZnRlciB0aGUgZG9tYWluCmFuZCByZXN0YXJ0IGFzIG5lY2Vzc2FyeS4KCnhsIGRl
c3Ryb3kgaXMgZXhwbGljdGx5IHRoZSBjb21tYW5kIHdoaWNoIHNob290cyB0aGUgZG9tYWluIGlu
IHRoZSBoZWFkCmFuZCBzbyBpdCBhbHNvIGNhbGxzIGRlc3Ryb3kuIElmIHlvdSB3YW50IGdyYWNl
ZnVsIHlvdSBzaG91bGQgdXNlICJ4bApzaHV0ZG93biIuCgpBbHRob3VnaCBoYW5kbGVfZG9tYWlu
X2RlYXRoIGFsc28gcGlja3MgdXAgb24gdGhlIGRlc3Ryb3kgaXQgc2hvdWxkbid0CmJlIGRvaW5n
IHRvbyBtdWNoIGluIHRoYXQgY2FzZSBzaW5jZSB0aGUgaW50ZXJlc3Rpbmcgd29yayBoYXMgYWxy
ZWFkeQpoYXBwZW5lZC4gVGhlIGludGVyZXN0aW5nIGxvZ3Mgd2lsbCBiZSB0aGUgeGwgLXZ2diBk
ZXN0cm95IG9uZXMgSSB0aGluay4KCklhbi4KCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlz
dHMueGVuc291cmNlLmNvbQpodHRwOi8vbGlzdHMueGVuc291cmNlLmNvbS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Fri Dec 02 10:10:50 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 10: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.xensource.com>)
	id 1RWQ4U-0000XR-CN; Fri, 02 Dec 2011 10:10:22 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RWQ4S-0000XM-Tw
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 10:10:21 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1322820553!55126806!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTg0Mw==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5158 invoked from network); 2 Dec 2011 10:09:13 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Dec 2011 10:09:13 -0000
X-IronPort-AV: E=Sophos;i="4.71,282,1320624000"; 
   d="scan'208";a="9245921"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Dec 2011 10:09:45 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 2 Dec 2011
	10:09:44 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Pasi =?ISO-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
Date: Fri, 2 Dec 2011 10:09:44 +0000
In-Reply-To: <20111201180944.GH12984@reaktio.net>
References: <4ED798B2.1040309@canonical.com>
	<20111201180944.GH12984@reaktio.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322820584.31810.325.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Lars Kurth <lars.kurth@xen.org>, Stefan Bader <stefan.bader@canonical.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Xen 4.x / Linux 3.x (dom0 and HVM domU) and NIC
 handling
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gVGh1LCAyMDExLTEyLTAxIGF0IDE4OjA5ICswMDAwLCBQYXNpIEvDpHJra8OkaW5lbiB3cm90
ZToKPiBPbiBUaHUsIERlYyAwMSwgMjAxMSBhdCAwNDowOTozOFBNICswMTAwLCBTdGVmYW4gQmFk
ZXIgd3JvdGU6Cj4gPiBNb3ZpbmcgdG8gcHVibGljIGRpc2N1c3Npb24uLi4KPiA+IAo+ID4gVGhp
cyB3YXMgZm91bmQgd2l0aCBYZW4gaHlwZXJ2aXNvciB2ZXJzaW9uIHN1cHBvcnRpbmcgZGV2aWNl
IHVucGx1Z2dpbmcgYW5kIHRoZQo+ID4gZG9tVSBrZXJuZWwgaGF2aW5nIG5ldC0vYmxrZnJvbnQg
YW5kIHBjaSBwbGF0Zm9ybSBidWlsdC1pbiAob3IgYXMgbW9kdWxlKS4KPiA+IAo+ID4gVGhlIGJs
b2NrIGRldmljZSBpcyBkZWZpbmVkIGFzIGhkYSBhbmQgdGhlIE5JQyB0eXBlPWlvZW11IChzbyB0
aGVvcmV0aWNhbGx5Cj4gPiBndWVzdHMgd2l0aG91dCBwdiBzdXBwb3J0IHdvdWxkIHdvcmssIHRv
bykuCj4gPiAKPiA+IFNpbmNlIGJvdGggZHJpdmVycyBhcmUgcHJlc2VudCwgdGhlIGtlcm5lbCB0
cmllcyB0byB1bnBsdWcgdGhlIGVtdWxhdGVkIGRldmljZXMKPiA+IGFuZCBzdWNjZWVkcy4gVGhl
IGJsa2Zyb250IGRyaXZlciBkZXRlY3RzIHRoZSB4dmRhIGRldmljZSBhdmFpbGFibGUgaW4gcGFy
YWxsZWwKPiA+IGFuZCBpcyB3b3JraW5nIG9rLgo+ID4gCj4gPiBIb3dldmVyIHRoZSBuZXR3b3Jr
IGludGVyZmFjZSBkb2VzIG5vdCB3b3JrLiBUaGVyZSBhcmUgZW50cmllcyBwcmVzZW50IHVuZGVy
Cj4gPiBzeXNmcyBmb3IgdGhlIHhlbmJ1cyBidXQgdHJ5aW5nIHRvIGJyaW5nIGl0IHVwIGZhaWxz
IHdpdGggZXJyb3JzLiBBbmQgYWxzbyB0aGVyZQo+ID4gc2VlbXMgdG8gYmUgbm8gbWFjIGFkZHJl
c3Mgc2V0IChhbGwgemVyb3MgaW4gc3lzZnMpLgo+ID4gV2hlbiB0aGUgdHlwZT1pb2VtdSBpcyBy
ZW1vdmVkIGluIHRoZSBjb25maWd1cmF0aW9uLCB0aGlzIHdvcmtzLgo+ID4gCj4gPiBJIGhhdmUg
bm90IG11Y2ggbW9yZSBkZWJ1Z2dpbmcgaW5mb3JtYXRpb24gYmV5b25kIHRoYXQsIHlldC4gQnV0
IGl0IHNvdW5kcyBhIGJpdAo+ID4gbGlrZSBOSUNzIHNob3VsZCBiZWhhdmUgdGhlIHNhbWUgYXMg
YmxvY2sgZGV2aWNlcy4gU28gaWYgdGhlcmUgaXMgYW4gZW11bGF0ZWQKPiA+IGRldmljZSBkZWZp
bmVkIHRoZXJlIHdpbGwgYmUgYW4gYWx0ZXJuYXRlIHBhcmF2aXJ0IGludGVyZmFjZSBmb3IgaXQg
YW5kIGFmdGVyCj4gPiB1bnBsdWdnaW5nIHRoZSBlbXVsYXRlZCBvbmVzIHdlIGVuZCB1cCB3aXRo
IHRoZSBwdiBvbmVzLgo+ID4gSXMgdGhhdCBzb21ldGhpbmcgdGhhdCBjYW4gYmUgc2VlbiB3aXRo
IG5ld2VyIFhlbiB2ZXJzaW9ucywgdG9vIChJIGFtIHVzaW5nIDQuMS4xKT8KPiA+IAo+IAo+IEhl
eSwKPiAKPiBIYXZlIHlvdSBzZWVuPzogCj4gaHR0cDovL3dpa2kueGVuLm9yZy94ZW53aWtpL1hl
bkxpbnV4UFZvbkhWTWRyaXZlcnMKCkkgd2FzIGFib3V0IHRvIHNheSAiUGxlYXNlIHVzZSB0aGUg
bmV3IHdpa2kgVVJMcyB3aGVyZSBwb3NzaWJsZSIgYnV0IHRoZQpzZWN0aW9uIHlvdSByZWZlciB0
byBzZWVtcyB0byBiZSBtaXNzaW5nIGluIHRoZSBuZXcgd2lraSEKCmh0dHA6Ly93aWtpLnhlbi5v
cmcvd2lraS9YZW5MaW51eFBWb25IVk1kcml2ZXJzCgpJdCBpcyB0aGVyZSBpbgpodHRwOi8vd2lr
aS54ZW4ub3JnL29sZC13aWtpLWNvbnZlcnRlZC9YZW5MaW51eFBWb25IVk1kcml2ZXJzLnR4dCBi
dXQKbm90IGluIHRoZSBmaXJzdCByZXZpc2lvbiBpbiB0aGUgbmV3IHdpa2kuIExhcnMsIGRvIHlv
dSBrbm93IHdoYXQKaGFwcGVuZWQgaGVyZT8KCj4gCj4gRXNwZWNpYWxseSB0aGUgZm9sbG93aW5n
IG5vdGU6Cj4gIk5PVEUhIElmIHlvdSBoYXZlICJ0eXBlPWlvZW11IiBzcGVjaWZpZWQgZm9yIHRo
ZSAidmlmIi1saW5lLCBQVkhWTSBkcml2ZXJzIFdJTEwgTk9UIHdvcmshIERvbid0IHNwZWNpZnkg
InR5cGUiIHBhcmFtZXRlciBmb3IgdGhlIHZpZi4gKHdpdGggdHlwZT1pb2VtdSB0aGUgcHZodm0g
bmljIGluIHRoZSBWTSB3aWxsIGhhdmUgbWFjIGFkZHJlc3MgZnVsbCBvZiB6ZXJvZXMgLSBhbmQg
dGh1cyB3b24ndCB3b3JrISkuIgo+IAo+ICJ0eXBlPWlvZW11IiBpcyBub3QgbmVlZGVkLCBhdCBs
ZWFzdCB3aXRoIHhtL3hlbmQgdG9vbHN0YWNrIGJvdGggSFZNIGFuZCBQVkhWTSBndWVzdHMgd29y
ayBPSyB3aXRob3V0IGl0Lgo+IAo+IC0tIFBhc2kKPiAKCgoKX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2
ZWxAbGlzdHMueGVuc291cmNlLmNvbQpodHRwOi8vbGlzdHMueGVuc291cmNlLmNvbS94ZW4tZGV2
ZWwK

From xen-devel-bounces@lists.xensource.com Fri Dec 02 10:10:50 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 10: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.xensource.com>)
	id 1RWQ4U-0000XR-CN; Fri, 02 Dec 2011 10:10:22 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RWQ4S-0000XM-Tw
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 10:10:21 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1322820553!55126806!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTg0Mw==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5158 invoked from network); 2 Dec 2011 10:09:13 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Dec 2011 10:09:13 -0000
X-IronPort-AV: E=Sophos;i="4.71,282,1320624000"; 
   d="scan'208";a="9245921"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Dec 2011 10:09:45 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 2 Dec 2011
	10:09:44 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Pasi =?ISO-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
Date: Fri, 2 Dec 2011 10:09:44 +0000
In-Reply-To: <20111201180944.GH12984@reaktio.net>
References: <4ED798B2.1040309@canonical.com>
	<20111201180944.GH12984@reaktio.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322820584.31810.325.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Lars Kurth <lars.kurth@xen.org>, Stefan Bader <stefan.bader@canonical.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Xen 4.x / Linux 3.x (dom0 and HVM domU) and NIC
 handling
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gVGh1LCAyMDExLTEyLTAxIGF0IDE4OjA5ICswMDAwLCBQYXNpIEvDpHJra8OkaW5lbiB3cm90
ZToKPiBPbiBUaHUsIERlYyAwMSwgMjAxMSBhdCAwNDowOTozOFBNICswMTAwLCBTdGVmYW4gQmFk
ZXIgd3JvdGU6Cj4gPiBNb3ZpbmcgdG8gcHVibGljIGRpc2N1c3Npb24uLi4KPiA+IAo+ID4gVGhp
cyB3YXMgZm91bmQgd2l0aCBYZW4gaHlwZXJ2aXNvciB2ZXJzaW9uIHN1cHBvcnRpbmcgZGV2aWNl
IHVucGx1Z2dpbmcgYW5kIHRoZQo+ID4gZG9tVSBrZXJuZWwgaGF2aW5nIG5ldC0vYmxrZnJvbnQg
YW5kIHBjaSBwbGF0Zm9ybSBidWlsdC1pbiAob3IgYXMgbW9kdWxlKS4KPiA+IAo+ID4gVGhlIGJs
b2NrIGRldmljZSBpcyBkZWZpbmVkIGFzIGhkYSBhbmQgdGhlIE5JQyB0eXBlPWlvZW11IChzbyB0
aGVvcmV0aWNhbGx5Cj4gPiBndWVzdHMgd2l0aG91dCBwdiBzdXBwb3J0IHdvdWxkIHdvcmssIHRv
bykuCj4gPiAKPiA+IFNpbmNlIGJvdGggZHJpdmVycyBhcmUgcHJlc2VudCwgdGhlIGtlcm5lbCB0
cmllcyB0byB1bnBsdWcgdGhlIGVtdWxhdGVkIGRldmljZXMKPiA+IGFuZCBzdWNjZWVkcy4gVGhl
IGJsa2Zyb250IGRyaXZlciBkZXRlY3RzIHRoZSB4dmRhIGRldmljZSBhdmFpbGFibGUgaW4gcGFy
YWxsZWwKPiA+IGFuZCBpcyB3b3JraW5nIG9rLgo+ID4gCj4gPiBIb3dldmVyIHRoZSBuZXR3b3Jr
IGludGVyZmFjZSBkb2VzIG5vdCB3b3JrLiBUaGVyZSBhcmUgZW50cmllcyBwcmVzZW50IHVuZGVy
Cj4gPiBzeXNmcyBmb3IgdGhlIHhlbmJ1cyBidXQgdHJ5aW5nIHRvIGJyaW5nIGl0IHVwIGZhaWxz
IHdpdGggZXJyb3JzLiBBbmQgYWxzbyB0aGVyZQo+ID4gc2VlbXMgdG8gYmUgbm8gbWFjIGFkZHJl
c3Mgc2V0IChhbGwgemVyb3MgaW4gc3lzZnMpLgo+ID4gV2hlbiB0aGUgdHlwZT1pb2VtdSBpcyBy
ZW1vdmVkIGluIHRoZSBjb25maWd1cmF0aW9uLCB0aGlzIHdvcmtzLgo+ID4gCj4gPiBJIGhhdmUg
bm90IG11Y2ggbW9yZSBkZWJ1Z2dpbmcgaW5mb3JtYXRpb24gYmV5b25kIHRoYXQsIHlldC4gQnV0
IGl0IHNvdW5kcyBhIGJpdAo+ID4gbGlrZSBOSUNzIHNob3VsZCBiZWhhdmUgdGhlIHNhbWUgYXMg
YmxvY2sgZGV2aWNlcy4gU28gaWYgdGhlcmUgaXMgYW4gZW11bGF0ZWQKPiA+IGRldmljZSBkZWZp
bmVkIHRoZXJlIHdpbGwgYmUgYW4gYWx0ZXJuYXRlIHBhcmF2aXJ0IGludGVyZmFjZSBmb3IgaXQg
YW5kIGFmdGVyCj4gPiB1bnBsdWdnaW5nIHRoZSBlbXVsYXRlZCBvbmVzIHdlIGVuZCB1cCB3aXRo
IHRoZSBwdiBvbmVzLgo+ID4gSXMgdGhhdCBzb21ldGhpbmcgdGhhdCBjYW4gYmUgc2VlbiB3aXRo
IG5ld2VyIFhlbiB2ZXJzaW9ucywgdG9vIChJIGFtIHVzaW5nIDQuMS4xKT8KPiA+IAo+IAo+IEhl
eSwKPiAKPiBIYXZlIHlvdSBzZWVuPzogCj4gaHR0cDovL3dpa2kueGVuLm9yZy94ZW53aWtpL1hl
bkxpbnV4UFZvbkhWTWRyaXZlcnMKCkkgd2FzIGFib3V0IHRvIHNheSAiUGxlYXNlIHVzZSB0aGUg
bmV3IHdpa2kgVVJMcyB3aGVyZSBwb3NzaWJsZSIgYnV0IHRoZQpzZWN0aW9uIHlvdSByZWZlciB0
byBzZWVtcyB0byBiZSBtaXNzaW5nIGluIHRoZSBuZXcgd2lraSEKCmh0dHA6Ly93aWtpLnhlbi5v
cmcvd2lraS9YZW5MaW51eFBWb25IVk1kcml2ZXJzCgpJdCBpcyB0aGVyZSBpbgpodHRwOi8vd2lr
aS54ZW4ub3JnL29sZC13aWtpLWNvbnZlcnRlZC9YZW5MaW51eFBWb25IVk1kcml2ZXJzLnR4dCBi
dXQKbm90IGluIHRoZSBmaXJzdCByZXZpc2lvbiBpbiB0aGUgbmV3IHdpa2kuIExhcnMsIGRvIHlv
dSBrbm93IHdoYXQKaGFwcGVuZWQgaGVyZT8KCj4gCj4gRXNwZWNpYWxseSB0aGUgZm9sbG93aW5n
IG5vdGU6Cj4gIk5PVEUhIElmIHlvdSBoYXZlICJ0eXBlPWlvZW11IiBzcGVjaWZpZWQgZm9yIHRo
ZSAidmlmIi1saW5lLCBQVkhWTSBkcml2ZXJzIFdJTEwgTk9UIHdvcmshIERvbid0IHNwZWNpZnkg
InR5cGUiIHBhcmFtZXRlciBmb3IgdGhlIHZpZi4gKHdpdGggdHlwZT1pb2VtdSB0aGUgcHZodm0g
bmljIGluIHRoZSBWTSB3aWxsIGhhdmUgbWFjIGFkZHJlc3MgZnVsbCBvZiB6ZXJvZXMgLSBhbmQg
dGh1cyB3b24ndCB3b3JrISkuIgo+IAo+ICJ0eXBlPWlvZW11IiBpcyBub3QgbmVlZGVkLCBhdCBs
ZWFzdCB3aXRoIHhtL3hlbmQgdG9vbHN0YWNrIGJvdGggSFZNIGFuZCBQVkhWTSBndWVzdHMgd29y
ayBPSyB3aXRob3V0IGl0Lgo+IAo+IC0tIFBhc2kKPiAKCgoKX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2
ZWxAbGlzdHMueGVuc291cmNlLmNvbQpodHRwOi8vbGlzdHMueGVuc291cmNlLmNvbS94ZW4tZGV2
ZWwK

From xen-devel-bounces@lists.xensource.com Fri Dec 02 10:11:18 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 10: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.xensource.com>)
	id 1RWQ56-0000ZE-Qw; Fri, 02 Dec 2011 10:11:00 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RWQ56-0000Yv-1A
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 10:11:00 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1322820617!5918118!1
X-Originating-IP: [209.85.210.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25658 invoked from network); 2 Dec 2011 10:10:18 -0000
Received: from mail-pz0-f43.google.com (HELO mail-pz0-f43.google.com)
	(209.85.210.43)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Dec 2011 10:10:18 -0000
Received: by dadz13 with SMTP id z13so8063907dad.30
	for <xen-devel@lists.xensource.com>;
	Fri, 02 Dec 2011 02:10:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=AUXHTRa0s7Y6D1uV2bSFjNwajabIpHEm2Z6oXZySI5k=;
	b=RJllFflb+XDUHZFa1CBrIa8k+4HseNQMGBe06AxbTff/97tlsMf7cEh9xNow+c2RA5
	tuYf5V1UpTEITWVV2+XF12KD3dpYY78Bbk368R6JZoOJmNL7Cj4R+XvvjscP2OQFyY5P
	cyoMYXRhdqfNAKqt9PQhVHL9oPtZSBJCVYbmw=
MIME-Version: 1.0
Received: by 10.68.42.100 with SMTP id n4mr12991425pbl.38.1322820616541; Fri,
	02 Dec 2011 02:10:16 -0800 (PST)
Received: by 10.142.212.12 with HTTP; Fri, 2 Dec 2011 02:10:16 -0800 (PST)
In-Reply-To: <1322819865.31810.319.camel@zakaz.uk.xensource.com>
References: <CAPLaKK5VC7YvMyvGM07f=ngOrbGbvLLDA1J8nqaxDsntux-bbQ@mail.gmail.com>
	<CAPLaKK6=L4wxWv6GqDpeV_OMukFgZSWM_pik6+jQ1tA7Ahsf3A@mail.gmail.com>
	<1322819865.31810.319.camel@zakaz.uk.xensource.com>
Date: Fri, 2 Dec 2011 11:10:16 +0100
X-Google-Sender-Auth: tEAxRhvoPZu-NbaZOlPuFKAdfxQ
Message-ID: <CAPLaKK5dO0QoxNiTy3aSR=_ArvLdLWpHsF=2Sw+iiXU5+8qQPQ@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] libxl: error when destroying domain on NetBSD
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

2011/12/2 Ian Campbell <Ian.Campbell@citrix.com>:
> It's normal I think. handle_domain_death() is there to deal with
> graceful shutdown and reboot scenarios e.g. to clear up after the domain
> and restart as necessary.
>
> xl destroy is explictly the command which shoots the domain in the head
> and so it also calls destroy. If you want graceful you should use "xl
> shutdown".
>
> Although handle_domain_death also picks up on the destroy it shouldn't
> be doing too much in that case since the interesting work has already
> happened. The interesting logs will be the xl -vvv destroy ones I think.

Devices doesn't get disconnected, or at least they don't get to state
'6' until xl exits, maybe I should modify libxl_domain_destroy to
search xenstore and try to manually execute hotplug scripts for
devices that are still connected after calling
'libxl__devices_destroy'.  Using xl -vvv destroy <domid>' doesn't
print any debug message, only:

xc: debug: hypercall buffer: total allocations:131 total releases:131
xc: debug: hypercall buffer: current allocations:0 maximum allocations:2
xc: debug: hypercall buffer: cache current size:2
xc: debug: hypercall buffer: cache hits:128 misses:2 toobig:1

Thanks, Roger.

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

From xen-devel-bounces@lists.xensource.com Fri Dec 02 10:11:18 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 10: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.xensource.com>)
	id 1RWQ56-0000ZE-Qw; Fri, 02 Dec 2011 10:11:00 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RWQ56-0000Yv-1A
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 10:11:00 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1322820617!5918118!1
X-Originating-IP: [209.85.210.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25658 invoked from network); 2 Dec 2011 10:10:18 -0000
Received: from mail-pz0-f43.google.com (HELO mail-pz0-f43.google.com)
	(209.85.210.43)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Dec 2011 10:10:18 -0000
Received: by dadz13 with SMTP id z13so8063907dad.30
	for <xen-devel@lists.xensource.com>;
	Fri, 02 Dec 2011 02:10:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=AUXHTRa0s7Y6D1uV2bSFjNwajabIpHEm2Z6oXZySI5k=;
	b=RJllFflb+XDUHZFa1CBrIa8k+4HseNQMGBe06AxbTff/97tlsMf7cEh9xNow+c2RA5
	tuYf5V1UpTEITWVV2+XF12KD3dpYY78Bbk368R6JZoOJmNL7Cj4R+XvvjscP2OQFyY5P
	cyoMYXRhdqfNAKqt9PQhVHL9oPtZSBJCVYbmw=
MIME-Version: 1.0
Received: by 10.68.42.100 with SMTP id n4mr12991425pbl.38.1322820616541; Fri,
	02 Dec 2011 02:10:16 -0800 (PST)
Received: by 10.142.212.12 with HTTP; Fri, 2 Dec 2011 02:10:16 -0800 (PST)
In-Reply-To: <1322819865.31810.319.camel@zakaz.uk.xensource.com>
References: <CAPLaKK5VC7YvMyvGM07f=ngOrbGbvLLDA1J8nqaxDsntux-bbQ@mail.gmail.com>
	<CAPLaKK6=L4wxWv6GqDpeV_OMukFgZSWM_pik6+jQ1tA7Ahsf3A@mail.gmail.com>
	<1322819865.31810.319.camel@zakaz.uk.xensource.com>
Date: Fri, 2 Dec 2011 11:10:16 +0100
X-Google-Sender-Auth: tEAxRhvoPZu-NbaZOlPuFKAdfxQ
Message-ID: <CAPLaKK5dO0QoxNiTy3aSR=_ArvLdLWpHsF=2Sw+iiXU5+8qQPQ@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] libxl: error when destroying domain on NetBSD
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

2011/12/2 Ian Campbell <Ian.Campbell@citrix.com>:
> It's normal I think. handle_domain_death() is there to deal with
> graceful shutdown and reboot scenarios e.g. to clear up after the domain
> and restart as necessary.
>
> xl destroy is explictly the command which shoots the domain in the head
> and so it also calls destroy. If you want graceful you should use "xl
> shutdown".
>
> Although handle_domain_death also picks up on the destroy it shouldn't
> be doing too much in that case since the interesting work has already
> happened. The interesting logs will be the xl -vvv destroy ones I think.

Devices doesn't get disconnected, or at least they don't get to state
'6' until xl exits, maybe I should modify libxl_domain_destroy to
search xenstore and try to manually execute hotplug scripts for
devices that are still connected after calling
'libxl__devices_destroy'.  Using xl -vvv destroy <domid>' doesn't
print any debug message, only:

xc: debug: hypercall buffer: total allocations:131 total releases:131
xc: debug: hypercall buffer: current allocations:0 maximum allocations:2
xc: debug: hypercall buffer: cache current size:2
xc: debug: hypercall buffer: cache hits:128 misses:2 toobig:1

Thanks, Roger.

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

From xen-devel-bounces@lists.xensource.com Fri Dec 02 10:12:49 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 10: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.xensource.com>)
	id 1RWQ6R-0000fo-B7; Fri, 02 Dec 2011 10:12:23 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <stefan.bader@canonical.com>) id 1RWQ6P-0000fI-Tr
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 10:12:22 +0000
X-Env-Sender: stefan.bader@canonical.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1322820700!356999!1
X-Originating-IP: [91.189.89.112]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30914 invoked from network); 2 Dec 2011 10:11:40 -0000
Received: from youngberry.canonical.com (HELO youngberry.canonical.com)
	(91.189.89.112) by server-4.tower-21.messagelabs.com with SMTP;
	2 Dec 2011 10:11:40 -0000
Received: from p5b2e2ad5.dip.t-dialin.net ([91.46.42.213] helo=[192.168.2.5])
	by youngberry.canonical.com with esmtpsa
	(TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71)
	(envelope-from <stefan.bader@canonical.com>)
	id 1RWQ5j-0008Fp-Sr; Fri, 02 Dec 2011 10:11:39 +0000
Message-ID: <4ED8A45A.3050403@canonical.com>
Date: Fri, 02 Dec 2011 11:11:38 +0100
From: Stefan Bader <stefan.bader@canonical.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:8.0) Gecko/20111124 Thunderbird/8.0
MIME-Version: 1.0
To: =?ISO-8859-1?Q?Pasi_K=E4rkk=E4inen?= <pasik@iki.fi>
References: <4ED798B2.1040309@canonical.com>
	<20111201180944.GH12984@reaktio.net>
In-Reply-To: <20111201180944.GH12984@reaktio.net>
X-Enigmail-Version: 1.4a1pre
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Xen 4.x / Linux 3.x (dom0 and HVM domU) and NIC
	handling
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01.12.2011 19:09, Pasi K=E4rkk=E4inen wrote:
> On Thu, Dec 01, 2011 at 04:09:38PM +0100, Stefan Bader wrote:
>> Moving to public discussion...
>>
>> This was found with Xen hypervisor version supporting device unplugging =
and the
>> domU kernel having net-/blkfront and pci platform built-in (or as module=
).
>>
>> The block device is defined as hda and the NIC type=3Dioemu (so theoreti=
cally
>> guests without pv support would work, too).
>>
>> Since both drivers are present, the kernel tries to unplug the emulated =
devices
>> and succeeds. The blkfront driver detects the xvda device available in p=
arallel
>> and is working ok.
>>
>> However the network interface does not work. There are entries present u=
nder
>> sysfs for the xenbus but trying to bring it up fails with errors. And al=
so there
>> seems to be no mac address set (all zeros in sysfs).
>> When the type=3Dioemu is removed in the configuration, this works.
>>
>> I have not much more debugging information beyond that, yet. But it soun=
ds a bit
>> like NICs should behave the same as block devices. So if there is an emu=
lated
>> device defined there will be an alternate paravirt interface for it and =
after
>> unplugging the emulated ones we end up with the pv ones.
>> Is that something that can be seen with newer Xen versions, too (I am us=
ing 4.1.1)?
>>
> =

> Hey,
> =

> Have you seen?: =

> http://wiki.xen.org/xenwiki/XenLinuxPVonHVMdrivers
> =

> Especially the following note:
> "NOTE! If you have "type=3Dioemu" specified for the "vif"-line, PVHVM dri=
vers WILL NOT work! Don't specify "type" parameter for the vif. (with type=
=3Dioemu the pvhvm nic in the VM will have mac address full of zeroes - and=
 thus won't work!)."
> =

> "type=3Dioemu" is not needed, at least with xm/xend toolstack both HVM an=
d PVHVM guests work OK without it.
> =

> -- Pasi
> =

Thanks Pasi,

hmm, so it is documented actually and thus sort of expected. Still it is
confusing. For one driver it does not make a difference to use the form of =
an
emulated device in the config, for the other it does. The xl stack works, t=
he xm
stack does not.
And then, ok this is probably a quite naive approach, it seemed to make sen=
se to
go through the pain of always having potentially both interfaces available
(emulated and pv) so in theory the same guest config can accommodate a gues=
t os
supporting one or the other (or easily switch from one to the other). Other=
wise
I would expect an emulated device only when I have hd? in the config and a =
pv
device when I write xvd?.

-Stefan

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

From xen-devel-bounces@lists.xensource.com Fri Dec 02 10:12:49 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 10: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.xensource.com>)
	id 1RWQ6R-0000fo-B7; Fri, 02 Dec 2011 10:12:23 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <stefan.bader@canonical.com>) id 1RWQ6P-0000fI-Tr
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 10:12:22 +0000
X-Env-Sender: stefan.bader@canonical.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1322820700!356999!1
X-Originating-IP: [91.189.89.112]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30914 invoked from network); 2 Dec 2011 10:11:40 -0000
Received: from youngberry.canonical.com (HELO youngberry.canonical.com)
	(91.189.89.112) by server-4.tower-21.messagelabs.com with SMTP;
	2 Dec 2011 10:11:40 -0000
Received: from p5b2e2ad5.dip.t-dialin.net ([91.46.42.213] helo=[192.168.2.5])
	by youngberry.canonical.com with esmtpsa
	(TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71)
	(envelope-from <stefan.bader@canonical.com>)
	id 1RWQ5j-0008Fp-Sr; Fri, 02 Dec 2011 10:11:39 +0000
Message-ID: <4ED8A45A.3050403@canonical.com>
Date: Fri, 02 Dec 2011 11:11:38 +0100
From: Stefan Bader <stefan.bader@canonical.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:8.0) Gecko/20111124 Thunderbird/8.0
MIME-Version: 1.0
To: =?ISO-8859-1?Q?Pasi_K=E4rkk=E4inen?= <pasik@iki.fi>
References: <4ED798B2.1040309@canonical.com>
	<20111201180944.GH12984@reaktio.net>
In-Reply-To: <20111201180944.GH12984@reaktio.net>
X-Enigmail-Version: 1.4a1pre
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Xen 4.x / Linux 3.x (dom0 and HVM domU) and NIC
	handling
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01.12.2011 19:09, Pasi K=E4rkk=E4inen wrote:
> On Thu, Dec 01, 2011 at 04:09:38PM +0100, Stefan Bader wrote:
>> Moving to public discussion...
>>
>> This was found with Xen hypervisor version supporting device unplugging =
and the
>> domU kernel having net-/blkfront and pci platform built-in (or as module=
).
>>
>> The block device is defined as hda and the NIC type=3Dioemu (so theoreti=
cally
>> guests without pv support would work, too).
>>
>> Since both drivers are present, the kernel tries to unplug the emulated =
devices
>> and succeeds. The blkfront driver detects the xvda device available in p=
arallel
>> and is working ok.
>>
>> However the network interface does not work. There are entries present u=
nder
>> sysfs for the xenbus but trying to bring it up fails with errors. And al=
so there
>> seems to be no mac address set (all zeros in sysfs).
>> When the type=3Dioemu is removed in the configuration, this works.
>>
>> I have not much more debugging information beyond that, yet. But it soun=
ds a bit
>> like NICs should behave the same as block devices. So if there is an emu=
lated
>> device defined there will be an alternate paravirt interface for it and =
after
>> unplugging the emulated ones we end up with the pv ones.
>> Is that something that can be seen with newer Xen versions, too (I am us=
ing 4.1.1)?
>>
> =

> Hey,
> =

> Have you seen?: =

> http://wiki.xen.org/xenwiki/XenLinuxPVonHVMdrivers
> =

> Especially the following note:
> "NOTE! If you have "type=3Dioemu" specified for the "vif"-line, PVHVM dri=
vers WILL NOT work! Don't specify "type" parameter for the vif. (with type=
=3Dioemu the pvhvm nic in the VM will have mac address full of zeroes - and=
 thus won't work!)."
> =

> "type=3Dioemu" is not needed, at least with xm/xend toolstack both HVM an=
d PVHVM guests work OK without it.
> =

> -- Pasi
> =

Thanks Pasi,

hmm, so it is documented actually and thus sort of expected. Still it is
confusing. For one driver it does not make a difference to use the form of =
an
emulated device in the config, for the other it does. The xl stack works, t=
he xm
stack does not.
And then, ok this is probably a quite naive approach, it seemed to make sen=
se to
go through the pain of always having potentially both interfaces available
(emulated and pv) so in theory the same guest config can accommodate a gues=
t os
supporting one or the other (or easily switch from one to the other). Other=
wise
I would expect an emulated device only when I have hd? in the config and a =
pv
device when I write xvd?.

-Stefan

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

From xen-devel-bounces@lists.xensource.com Fri Dec 02 10:15:48 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 10:15:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWQ9P-0000uM-V9; Fri, 02 Dec 2011 10:15:27 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RWQ9N-0000u7-Rm
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 10:15:26 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1322820884!4688997!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTg0Mw==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25552 invoked from network); 2 Dec 2011 10:14:44 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Dec 2011 10:14:44 -0000
X-IronPort-AV: E=Sophos;i="4.71,282,1320624000"; 
   d="scan'208";a="9246049"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Dec 2011 10:14:44 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 2 Dec 2011
	10:14:44 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau =?ISO-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
Date: Fri, 2 Dec 2011 10:14:43 +0000
In-Reply-To: <CAPLaKK5dO0QoxNiTy3aSR=_ArvLdLWpHsF=2Sw+iiXU5+8qQPQ@mail.gmail.com>
References: <CAPLaKK5VC7YvMyvGM07f=ngOrbGbvLLDA1J8nqaxDsntux-bbQ@mail.gmail.com>
	<CAPLaKK6=L4wxWv6GqDpeV_OMukFgZSWM_pik6+jQ1tA7Ahsf3A@mail.gmail.com>
	<1322819865.31810.319.camel@zakaz.uk.xensource.com>
	<CAPLaKK5dO0QoxNiTy3aSR=_ArvLdLWpHsF=2Sw+iiXU5+8qQPQ@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322820883.31810.329.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] libxl: error when destroying domain on NetBSD
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gRnJpLCAyMDExLTEyLTAyIGF0IDEwOjEwICswMDAwLCBSb2dlciBQYXUgTW9ubsOpIHdyb3Rl
Ogo+IDIwMTEvMTIvMiBJYW4gQ2FtcGJlbGwgPElhbi5DYW1wYmVsbEBjaXRyaXguY29tPjoKPiA+
IEl0J3Mgbm9ybWFsIEkgdGhpbmsuIGhhbmRsZV9kb21haW5fZGVhdGgoKSBpcyB0aGVyZSB0byBk
ZWFsIHdpdGgKPiA+IGdyYWNlZnVsIHNodXRkb3duIGFuZCByZWJvb3Qgc2NlbmFyaW9zIGUuZy4g
dG8gY2xlYXIgdXAgYWZ0ZXIgdGhlIGRvbWFpbgo+ID4gYW5kIHJlc3RhcnQgYXMgbmVjZXNzYXJ5
Lgo+ID4KPiA+IHhsIGRlc3Ryb3kgaXMgZXhwbGljdGx5IHRoZSBjb21tYW5kIHdoaWNoIHNob290
cyB0aGUgZG9tYWluIGluIHRoZSBoZWFkCj4gPiBhbmQgc28gaXQgYWxzbyBjYWxscyBkZXN0cm95
LiBJZiB5b3Ugd2FudCBncmFjZWZ1bCB5b3Ugc2hvdWxkIHVzZSAieGwKPiA+IHNodXRkb3duIi4K
PiA+Cj4gPiBBbHRob3VnaCBoYW5kbGVfZG9tYWluX2RlYXRoIGFsc28gcGlja3MgdXAgb24gdGhl
IGRlc3Ryb3kgaXQgc2hvdWxkbid0Cj4gPiBiZSBkb2luZyB0b28gbXVjaCBpbiB0aGF0IGNhc2Ug
c2luY2UgdGhlIGludGVyZXN0aW5nIHdvcmsgaGFzIGFscmVhZHkKPiA+IGhhcHBlbmVkLiBUaGUg
aW50ZXJlc3RpbmcgbG9ncyB3aWxsIGJlIHRoZSB4bCAtdnZ2IGRlc3Ryb3kgb25lcyBJIHRoaW5r
Lgo+IAo+IERldmljZXMgZG9lc24ndCBnZXQgZGlzY29ubmVjdGVkLCBvciBhdCBsZWFzdCB0aGV5
IGRvbid0IGdldCB0byBzdGF0ZQo+ICc2JyB1bnRpbCB4bCBleGl0cywgbWF5YmUgSSBzaG91bGQg
bW9kaWZ5IGxpYnhsX2RvbWFpbl9kZXN0cm95IHRvCj4gc2VhcmNoIHhlbnN0b3JlIGFuZCB0cnkg
dG8gbWFudWFsbHkgZXhlY3V0ZSBob3RwbHVnIHNjcmlwdHMgZm9yCj4gZGV2aWNlcyB0aGF0IGFy
ZSBzdGlsbCBjb25uZWN0ZWQgYWZ0ZXIgY2FsbGluZwo+ICdsaWJ4bF9fZGV2aWNlc19kZXN0cm95
Jy4KCmxpYnhsX2Rlc3Ryb3lfZG9tYWluIHNob3VsZCBiZSBjYWxsZWQgd2l0aCBmb3JjZSA9IDEg
aW4gdGhlIG1haW5fZGVzdHJveQpjYXNlLCBJIHN1c3BlY3QuIERvZXMgdGhhdCBjYXVzZSB0aGUg
c2NyaXB0cyB0byBiZSBydW4/Cgo+ICAgVXNpbmcgeGwgLXZ2diBkZXN0cm95IDxkb21pZD4nIGRv
ZXNuJ3QKPiBwcmludCBhbnkgZGVidWcgbWVzc2FnZSwgb25seToKPiAKPiB4YzogZGVidWc6IGh5
cGVyY2FsbCBidWZmZXI6IHRvdGFsIGFsbG9jYXRpb25zOjEzMSB0b3RhbCByZWxlYXNlczoxMzEK
PiB4YzogZGVidWc6IGh5cGVyY2FsbCBidWZmZXI6IGN1cnJlbnQgYWxsb2NhdGlvbnM6MCBtYXhp
bXVtIGFsbG9jYXRpb25zOjIKPiB4YzogZGVidWc6IGh5cGVyY2FsbCBidWZmZXI6IGNhY2hlIGN1
cnJlbnQgc2l6ZToyCj4geGM6IGRlYnVnOiBoeXBlcmNhbGwgYnVmZmVyOiBjYWNoZSBoaXRzOjEy
OCBtaXNzZXM6MiB0b29iaWc6MQo+IAo+IFRoYW5rcywgUm9nZXIuCgoKCl9fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QK
WGVuLWRldmVsQGxpc3RzLnhlbnNvdXJjZS5jb20KaHR0cDovL2xpc3RzLnhlbnNvdXJjZS5jb20v
eGVuLWRldmVsCg==

From xen-devel-bounces@lists.xensource.com Fri Dec 02 10:15:48 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 10:15:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWQ9P-0000uM-V9; Fri, 02 Dec 2011 10:15:27 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RWQ9N-0000u7-Rm
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 10:15:26 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1322820884!4688997!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTg0Mw==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25552 invoked from network); 2 Dec 2011 10:14:44 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Dec 2011 10:14:44 -0000
X-IronPort-AV: E=Sophos;i="4.71,282,1320624000"; 
   d="scan'208";a="9246049"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Dec 2011 10:14:44 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 2 Dec 2011
	10:14:44 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau =?ISO-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
Date: Fri, 2 Dec 2011 10:14:43 +0000
In-Reply-To: <CAPLaKK5dO0QoxNiTy3aSR=_ArvLdLWpHsF=2Sw+iiXU5+8qQPQ@mail.gmail.com>
References: <CAPLaKK5VC7YvMyvGM07f=ngOrbGbvLLDA1J8nqaxDsntux-bbQ@mail.gmail.com>
	<CAPLaKK6=L4wxWv6GqDpeV_OMukFgZSWM_pik6+jQ1tA7Ahsf3A@mail.gmail.com>
	<1322819865.31810.319.camel@zakaz.uk.xensource.com>
	<CAPLaKK5dO0QoxNiTy3aSR=_ArvLdLWpHsF=2Sw+iiXU5+8qQPQ@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322820883.31810.329.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] libxl: error when destroying domain on NetBSD
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gRnJpLCAyMDExLTEyLTAyIGF0IDEwOjEwICswMDAwLCBSb2dlciBQYXUgTW9ubsOpIHdyb3Rl
Ogo+IDIwMTEvMTIvMiBJYW4gQ2FtcGJlbGwgPElhbi5DYW1wYmVsbEBjaXRyaXguY29tPjoKPiA+
IEl0J3Mgbm9ybWFsIEkgdGhpbmsuIGhhbmRsZV9kb21haW5fZGVhdGgoKSBpcyB0aGVyZSB0byBk
ZWFsIHdpdGgKPiA+IGdyYWNlZnVsIHNodXRkb3duIGFuZCByZWJvb3Qgc2NlbmFyaW9zIGUuZy4g
dG8gY2xlYXIgdXAgYWZ0ZXIgdGhlIGRvbWFpbgo+ID4gYW5kIHJlc3RhcnQgYXMgbmVjZXNzYXJ5
Lgo+ID4KPiA+IHhsIGRlc3Ryb3kgaXMgZXhwbGljdGx5IHRoZSBjb21tYW5kIHdoaWNoIHNob290
cyB0aGUgZG9tYWluIGluIHRoZSBoZWFkCj4gPiBhbmQgc28gaXQgYWxzbyBjYWxscyBkZXN0cm95
LiBJZiB5b3Ugd2FudCBncmFjZWZ1bCB5b3Ugc2hvdWxkIHVzZSAieGwKPiA+IHNodXRkb3duIi4K
PiA+Cj4gPiBBbHRob3VnaCBoYW5kbGVfZG9tYWluX2RlYXRoIGFsc28gcGlja3MgdXAgb24gdGhl
IGRlc3Ryb3kgaXQgc2hvdWxkbid0Cj4gPiBiZSBkb2luZyB0b28gbXVjaCBpbiB0aGF0IGNhc2Ug
c2luY2UgdGhlIGludGVyZXN0aW5nIHdvcmsgaGFzIGFscmVhZHkKPiA+IGhhcHBlbmVkLiBUaGUg
aW50ZXJlc3RpbmcgbG9ncyB3aWxsIGJlIHRoZSB4bCAtdnZ2IGRlc3Ryb3kgb25lcyBJIHRoaW5r
Lgo+IAo+IERldmljZXMgZG9lc24ndCBnZXQgZGlzY29ubmVjdGVkLCBvciBhdCBsZWFzdCB0aGV5
IGRvbid0IGdldCB0byBzdGF0ZQo+ICc2JyB1bnRpbCB4bCBleGl0cywgbWF5YmUgSSBzaG91bGQg
bW9kaWZ5IGxpYnhsX2RvbWFpbl9kZXN0cm95IHRvCj4gc2VhcmNoIHhlbnN0b3JlIGFuZCB0cnkg
dG8gbWFudWFsbHkgZXhlY3V0ZSBob3RwbHVnIHNjcmlwdHMgZm9yCj4gZGV2aWNlcyB0aGF0IGFy
ZSBzdGlsbCBjb25uZWN0ZWQgYWZ0ZXIgY2FsbGluZwo+ICdsaWJ4bF9fZGV2aWNlc19kZXN0cm95
Jy4KCmxpYnhsX2Rlc3Ryb3lfZG9tYWluIHNob3VsZCBiZSBjYWxsZWQgd2l0aCBmb3JjZSA9IDEg
aW4gdGhlIG1haW5fZGVzdHJveQpjYXNlLCBJIHN1c3BlY3QuIERvZXMgdGhhdCBjYXVzZSB0aGUg
c2NyaXB0cyB0byBiZSBydW4/Cgo+ICAgVXNpbmcgeGwgLXZ2diBkZXN0cm95IDxkb21pZD4nIGRv
ZXNuJ3QKPiBwcmludCBhbnkgZGVidWcgbWVzc2FnZSwgb25seToKPiAKPiB4YzogZGVidWc6IGh5
cGVyY2FsbCBidWZmZXI6IHRvdGFsIGFsbG9jYXRpb25zOjEzMSB0b3RhbCByZWxlYXNlczoxMzEK
PiB4YzogZGVidWc6IGh5cGVyY2FsbCBidWZmZXI6IGN1cnJlbnQgYWxsb2NhdGlvbnM6MCBtYXhp
bXVtIGFsbG9jYXRpb25zOjIKPiB4YzogZGVidWc6IGh5cGVyY2FsbCBidWZmZXI6IGNhY2hlIGN1
cnJlbnQgc2l6ZToyCj4geGM6IGRlYnVnOiBoeXBlcmNhbGwgYnVmZmVyOiBjYWNoZSBoaXRzOjEy
OCBtaXNzZXM6MiB0b29iaWc6MQo+IAo+IFRoYW5rcywgUm9nZXIuCgoKCl9fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QK
WGVuLWRldmVsQGxpc3RzLnhlbnNvdXJjZS5jb20KaHR0cDovL2xpc3RzLnhlbnNvdXJjZS5jb20v
eGVuLWRldmVsCg==

From xen-devel-bounces@lists.xensource.com Fri Dec 02 10:16:28 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 10:16:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWQA6-0000zZ-Jr; Fri, 02 Dec 2011 10:16:10 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RWQA4-0000yj-Um
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 10:16:09 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1322820928!937159!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTg0Mw==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8574 invoked from network); 2 Dec 2011 10:15:28 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Dec 2011 10:15:28 -0000
X-IronPort-AV: E=Sophos;i="4.71,282,1320624000"; 
   d="scan'208";a="9246065"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Dec 2011 10:15:27 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 2 Dec 2011
	10:15:27 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefan Bader <stefan.bader@canonical.com>
Date: Fri, 2 Dec 2011 10:15:27 +0000
In-Reply-To: <4ED7BDA0.8050208@canonical.com>
References: <4ED798B2.1040309@canonical.com>
	<1322755432.31810.244.camel@zakaz.uk.xensource.com>
	<4ED7BDA0.8050208@canonical.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322820927.31810.330.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Xen 4.x / Linux 3.x (dom0 and HVM domU) and NIC
	handling
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2011-12-01 at 17:47 +0000, Stefan Bader wrote:
> On 01.12.2011 17:03, Ian Campbell wrote:
> > On Thu, 2011-12-01 at 15:09 +0000, Stefan Bader wrote:
> >> Moving to public discussion...
> >>
> >> This was found with Xen hypervisor version supporting device unplugging and the
> >> domU kernel having net-/blkfront and pci platform built-in (or as module).
> >>
> >> The block device is defined as hda and the NIC type=ioemu (so theoretically
> >> guests without pv support would work, too).
> >>
> >> Since both drivers are present, the kernel tries to unplug the emulated devices
> >> and succeeds. The blkfront driver detects the xvda device available in parallel
> >> and is working ok.
> >>
> >> However the network interface does not work. There are entries present under
> >> sysfs for the xenbus but trying to bring it up fails with errors. And also there
> >> seems to be no mac address set (all zeros in sysfs).
> >> When the type=ioemu is removed in the configuration, this works.
> > 
> > Which toolstack are you using?
> > 
> xm (xl with the same config seems to work)

That's good. xm is deprecated and this seems to be a known issue with
xend. There is a workaround which is to not specify type=.

> 
> > The weird thing is that, at least with xl, type=ioemu is the default for
> > an HVM guest.
> > 
> > What vif related entries do you get in xenstore, both front and backend?
> > 
> output of xenstore-ls attached (hopefully contains all info)

FWIW the xend frontend dir looks more empty than I would have expected.
However given the above I don't think we want to spend time figuring out
why.

Ian.

> 
> > Also what does your qemu-dm command line end up looking like?
> > 
> also in the attached file.
> 
> >> I have not much more debugging information beyond that, yet. But it sounds a bit
> >> like NICs should behave the same as block devices. So if there is an emulated
> >> device defined there will be an alternate paravirt interface for it and after
> >> unplugging the emulated ones we end up with the pv ones.
> > 
> > That is certainly the expectation.
> > 
> >> Is that something that can be seen with newer Xen versions, too (I am using 4.1.1)?
> > 
> > I appear to have some other problem with xen-unstable at the moment.
> > I've never noticed a problem in that past, although I don't habitually
> > use type=XXX at all in my vif configuration.
> > 
> > Ian.
> > 
> >> -Stefan
> > 
> > 
> 



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

From xen-devel-bounces@lists.xensource.com Fri Dec 02 10:16:28 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 10:16:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWQA6-0000zZ-Jr; Fri, 02 Dec 2011 10:16:10 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RWQA4-0000yj-Um
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 10:16:09 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1322820928!937159!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTg0Mw==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8574 invoked from network); 2 Dec 2011 10:15:28 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Dec 2011 10:15:28 -0000
X-IronPort-AV: E=Sophos;i="4.71,282,1320624000"; 
   d="scan'208";a="9246065"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Dec 2011 10:15:27 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 2 Dec 2011
	10:15:27 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefan Bader <stefan.bader@canonical.com>
Date: Fri, 2 Dec 2011 10:15:27 +0000
In-Reply-To: <4ED7BDA0.8050208@canonical.com>
References: <4ED798B2.1040309@canonical.com>
	<1322755432.31810.244.camel@zakaz.uk.xensource.com>
	<4ED7BDA0.8050208@canonical.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322820927.31810.330.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Xen 4.x / Linux 3.x (dom0 and HVM domU) and NIC
	handling
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2011-12-01 at 17:47 +0000, Stefan Bader wrote:
> On 01.12.2011 17:03, Ian Campbell wrote:
> > On Thu, 2011-12-01 at 15:09 +0000, Stefan Bader wrote:
> >> Moving to public discussion...
> >>
> >> This was found with Xen hypervisor version supporting device unplugging and the
> >> domU kernel having net-/blkfront and pci platform built-in (or as module).
> >>
> >> The block device is defined as hda and the NIC type=ioemu (so theoretically
> >> guests without pv support would work, too).
> >>
> >> Since both drivers are present, the kernel tries to unplug the emulated devices
> >> and succeeds. The blkfront driver detects the xvda device available in parallel
> >> and is working ok.
> >>
> >> However the network interface does not work. There are entries present under
> >> sysfs for the xenbus but trying to bring it up fails with errors. And also there
> >> seems to be no mac address set (all zeros in sysfs).
> >> When the type=ioemu is removed in the configuration, this works.
> > 
> > Which toolstack are you using?
> > 
> xm (xl with the same config seems to work)

That's good. xm is deprecated and this seems to be a known issue with
xend. There is a workaround which is to not specify type=.

> 
> > The weird thing is that, at least with xl, type=ioemu is the default for
> > an HVM guest.
> > 
> > What vif related entries do you get in xenstore, both front and backend?
> > 
> output of xenstore-ls attached (hopefully contains all info)

FWIW the xend frontend dir looks more empty than I would have expected.
However given the above I don't think we want to spend time figuring out
why.

Ian.

> 
> > Also what does your qemu-dm command line end up looking like?
> > 
> also in the attached file.
> 
> >> I have not much more debugging information beyond that, yet. But it sounds a bit
> >> like NICs should behave the same as block devices. So if there is an emulated
> >> device defined there will be an alternate paravirt interface for it and after
> >> unplugging the emulated ones we end up with the pv ones.
> > 
> > That is certainly the expectation.
> > 
> >> Is that something that can be seen with newer Xen versions, too (I am using 4.1.1)?
> > 
> > I appear to have some other problem with xen-unstable at the moment.
> > I've never noticed a problem in that past, although I don't habitually
> > use type=XXX at all in my vif configuration.
> > 
> > Ian.
> > 
> >> -Stefan
> > 
> > 
> 



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

From xen-devel-bounces@lists.xensource.com Fri Dec 02 10:19:10 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 10:19:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWQCm-0001EP-6v; Fri, 02 Dec 2011 10:18:56 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RWQCk-0001E2-Ez
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 10:18:54 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1322821058!45151020!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTg0Mw==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14774 invoked from network); 2 Dec 2011 10:17:38 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Dec 2011 10:17:38 -0000
X-IronPort-AV: E=Sophos;i="4.71,282,1320624000"; 
   d="scan'208";a="9246143"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Dec 2011 10:18:13 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 2 Dec 2011
	10:18:13 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Philipp Hahn <hahn@univention.de>, Jim Fehlig <jfehlig@suse.com>
Date: Fri, 2 Dec 2011 10:18:13 +0000
In-Reply-To: <201112020951.40156.hahn@univention.de>
References: <201111251721.12753.hahn@univention.de>
	<20111201193711.GK12984@reaktio.net>
	<1322769065.7376.36.camel@dagon.hellion.org.uk>
	<201112020951.40156.hahn@univention.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322821093.31810.332.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "libvir-list@redhat.com" <libvir-list@redhat.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [BUG] insufficient quoting between	"tap-ctl	list"
 and	xend/server/BlktapController.py
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2011-12-02 at 08:51 +0000, Philipp Hahn wrote:
> Hello,
> 
> On Thursday 01 December 2011 19:31:04 Ian Jackson wrote:
> > Philipp Hahn writes ("Re: [Xen-devel] [BUG] insufficient quoting 
> between "tap-ctl list" and xend/server/BlktapController.py"):
> > > As a quick work-around, the attached patch fixes the problem for me. That
> > > is, until tap-ctl changes it's output format.
> >
> > Thanks, I have applied it.
> 
> Thanks for applying.
> 
> On Thursday 01 December 2011 20:51:05 Ian Campbell wrote:
> > xend is deprecated. This ultimately means that xend will go away. If you
> > are dependent on these features then you need put effort into ensuring
> > that they become supported in libxl and xl.
> 
> For our forthcomming release of UCS-3.0 we really wanted to switch from Xend 
> to xl, but be had to switch back to using Xend, because libvirt still lacks 
> some important features like migration; see 
> <http://libvirt.org/hvsupport.html> for a comparison matrix. Back at the 
> beginning of 2011 Univention sponsored Markus Gross to work on the xl-binding 
> of libvirt, 

Thank you for putting your money where your mouth is here!

> but after the end of his internship I have not seen that much 
> work on the xl-binding in libvirt except from Jim Fehlig.

AFAIK Jim is the main man working on this stuff. Last I heard he was
working on migration but I don't know the status, Jim?

Ian.



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

From xen-devel-bounces@lists.xensource.com Fri Dec 02 10:19:10 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 10:19:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWQCm-0001EP-6v; Fri, 02 Dec 2011 10:18:56 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RWQCk-0001E2-Ez
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 10:18:54 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1322821058!45151020!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTg0Mw==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14774 invoked from network); 2 Dec 2011 10:17:38 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Dec 2011 10:17:38 -0000
X-IronPort-AV: E=Sophos;i="4.71,282,1320624000"; 
   d="scan'208";a="9246143"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Dec 2011 10:18:13 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 2 Dec 2011
	10:18:13 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Philipp Hahn <hahn@univention.de>, Jim Fehlig <jfehlig@suse.com>
Date: Fri, 2 Dec 2011 10:18:13 +0000
In-Reply-To: <201112020951.40156.hahn@univention.de>
References: <201111251721.12753.hahn@univention.de>
	<20111201193711.GK12984@reaktio.net>
	<1322769065.7376.36.camel@dagon.hellion.org.uk>
	<201112020951.40156.hahn@univention.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322821093.31810.332.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "libvir-list@redhat.com" <libvir-list@redhat.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [BUG] insufficient quoting between	"tap-ctl	list"
 and	xend/server/BlktapController.py
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2011-12-02 at 08:51 +0000, Philipp Hahn wrote:
> Hello,
> 
> On Thursday 01 December 2011 19:31:04 Ian Jackson wrote:
> > Philipp Hahn writes ("Re: [Xen-devel] [BUG] insufficient quoting 
> between "tap-ctl list" and xend/server/BlktapController.py"):
> > > As a quick work-around, the attached patch fixes the problem for me. That
> > > is, until tap-ctl changes it's output format.
> >
> > Thanks, I have applied it.
> 
> Thanks for applying.
> 
> On Thursday 01 December 2011 20:51:05 Ian Campbell wrote:
> > xend is deprecated. This ultimately means that xend will go away. If you
> > are dependent on these features then you need put effort into ensuring
> > that they become supported in libxl and xl.
> 
> For our forthcomming release of UCS-3.0 we really wanted to switch from Xend 
> to xl, but be had to switch back to using Xend, because libvirt still lacks 
> some important features like migration; see 
> <http://libvirt.org/hvsupport.html> for a comparison matrix. Back at the 
> beginning of 2011 Univention sponsored Markus Gross to work on the xl-binding 
> of libvirt, 

Thank you for putting your money where your mouth is here!

> but after the end of his internship I have not seen that much 
> work on the xl-binding in libvirt except from Jim Fehlig.

AFAIK Jim is the main man working on this stuff. Last I heard he was
working on migration but I don't know the status, Jim?

Ian.



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

From xen-devel-bounces@lists.xensource.com Fri Dec 02 10:30:09 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 10:30:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWQNN-0001nw-6S; Fri, 02 Dec 2011 10:29:53 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RWQNL-0001nl-U0
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 10:29:52 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1322821749!3787487!1
X-Originating-IP: [209.85.210.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17353 invoked from network); 2 Dec 2011 10:29:11 -0000
Received: from mail-pz0-f43.google.com (HELO mail-pz0-f43.google.com)
	(209.85.210.43)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Dec 2011 10:29:11 -0000
Received: by dadz13 with SMTP id z13so8144687dad.30
	for <xen-devel@lists.xensource.com>;
	Fri, 02 Dec 2011 02:29:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=cR6J8Jhaw6Siixcm6A62UyiHihUFFvY3dIftJr4gMNo=;
	b=sa5WERdbrskvHUzqq5i1EJiA9mqMZD7yMCzqlCv3UWBjglJncLV08gCsWgw2kGwATM
	21h2ChM3A4165cKwcVsvS7ek7y88F+An3rWw9aW7dkz+0ZgEIcAqtJwmVXb58jB7w+Za
	/uZvuWYUtDn+M3Smdh1hs/LLhJw3GkQ8ET0KM=
MIME-Version: 1.0
Received: by 10.68.72.36 with SMTP id a4mr13306339pbv.4.1322821748935; Fri, 02
	Dec 2011 02:29:08 -0800 (PST)
Received: by 10.142.212.12 with HTTP; Fri, 2 Dec 2011 02:29:08 -0800 (PST)
In-Reply-To: <1322820883.31810.329.camel@zakaz.uk.xensource.com>
References: <CAPLaKK5VC7YvMyvGM07f=ngOrbGbvLLDA1J8nqaxDsntux-bbQ@mail.gmail.com>
	<CAPLaKK6=L4wxWv6GqDpeV_OMukFgZSWM_pik6+jQ1tA7Ahsf3A@mail.gmail.com>
	<1322819865.31810.319.camel@zakaz.uk.xensource.com>
	<CAPLaKK5dO0QoxNiTy3aSR=_ArvLdLWpHsF=2Sw+iiXU5+8qQPQ@mail.gmail.com>
	<1322820883.31810.329.camel@zakaz.uk.xensource.com>
Date: Fri, 2 Dec 2011 11:29:08 +0100
X-Google-Sender-Auth: 61A286VdPuTtGkllEf_q8rQomck
Message-ID: <CAPLaKK7mTUQRikLp6jKczw4RabaFycTA0LcQzm5P-wtmTHb+0A@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] libxl: error when destroying domain on NetBSD
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

2011/12/2 Ian Campbell <Ian.Campbell@citrix.com>:
> libxl_destroy_domain should be called with force = 1 in the main_destroy
> case, I suspect. Does that cause the scripts to be run?

Well, with force = 1 hotplug scripts are executed, but devices are
still busy and they cannot be disconnected (mainly vnd). Also crashed
the server, but that's NetBSD buggy vnd driver problem. Seeing the
execution order in libxl_domain_destroy, shouldn't we first destroy
the domain (xc_domain_destroy) and then remove the devices?

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

From xen-devel-bounces@lists.xensource.com Fri Dec 02 10:30:09 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 10:30:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWQNN-0001nw-6S; Fri, 02 Dec 2011 10:29:53 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RWQNL-0001nl-U0
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 10:29:52 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1322821749!3787487!1
X-Originating-IP: [209.85.210.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17353 invoked from network); 2 Dec 2011 10:29:11 -0000
Received: from mail-pz0-f43.google.com (HELO mail-pz0-f43.google.com)
	(209.85.210.43)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Dec 2011 10:29:11 -0000
Received: by dadz13 with SMTP id z13so8144687dad.30
	for <xen-devel@lists.xensource.com>;
	Fri, 02 Dec 2011 02:29:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=cR6J8Jhaw6Siixcm6A62UyiHihUFFvY3dIftJr4gMNo=;
	b=sa5WERdbrskvHUzqq5i1EJiA9mqMZD7yMCzqlCv3UWBjglJncLV08gCsWgw2kGwATM
	21h2ChM3A4165cKwcVsvS7ek7y88F+An3rWw9aW7dkz+0ZgEIcAqtJwmVXb58jB7w+Za
	/uZvuWYUtDn+M3Smdh1hs/LLhJw3GkQ8ET0KM=
MIME-Version: 1.0
Received: by 10.68.72.36 with SMTP id a4mr13306339pbv.4.1322821748935; Fri, 02
	Dec 2011 02:29:08 -0800 (PST)
Received: by 10.142.212.12 with HTTP; Fri, 2 Dec 2011 02:29:08 -0800 (PST)
In-Reply-To: <1322820883.31810.329.camel@zakaz.uk.xensource.com>
References: <CAPLaKK5VC7YvMyvGM07f=ngOrbGbvLLDA1J8nqaxDsntux-bbQ@mail.gmail.com>
	<CAPLaKK6=L4wxWv6GqDpeV_OMukFgZSWM_pik6+jQ1tA7Ahsf3A@mail.gmail.com>
	<1322819865.31810.319.camel@zakaz.uk.xensource.com>
	<CAPLaKK5dO0QoxNiTy3aSR=_ArvLdLWpHsF=2Sw+iiXU5+8qQPQ@mail.gmail.com>
	<1322820883.31810.329.camel@zakaz.uk.xensource.com>
Date: Fri, 2 Dec 2011 11:29:08 +0100
X-Google-Sender-Auth: 61A286VdPuTtGkllEf_q8rQomck
Message-ID: <CAPLaKK7mTUQRikLp6jKczw4RabaFycTA0LcQzm5P-wtmTHb+0A@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] libxl: error when destroying domain on NetBSD
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

2011/12/2 Ian Campbell <Ian.Campbell@citrix.com>:
> libxl_destroy_domain should be called with force = 1 in the main_destroy
> case, I suspect. Does that cause the scripts to be run?

Well, with force = 1 hotplug scripts are executed, but devices are
still busy and they cannot be disconnected (mainly vnd). Also crashed
the server, but that's NetBSD buggy vnd driver problem. Seeing the
execution order in libxl_domain_destroy, shouldn't we first destroy
the domain (xc_domain_destroy) and then remove the devices?

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

From xen-devel-bounces@lists.xensource.com Fri Dec 02 10:36:17 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 10:36:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWQTI-00024Y-0g; Fri, 02 Dec 2011 10:36:00 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RWQTG-00024N-E7
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 10:35:58 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-13.tower-182.messagelabs.com!1322822116!5063468!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8360 invoked from network); 2 Dec 2011 10:35:16 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-13.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 2 Dec 2011 10:35:16 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RWQQg-000MqR-Ta; Fri, 02 Dec 2011 10:33:18 +0000
Date: Fri, 2 Dec 2011 10:33:18 +0000
From: Tim Deegan <tim@xen.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20111202103318.GA86219@ocelot.phlegethon.org>
References: <patchbomb.1322598097@xdev.gridcentric.ca>
	<6626add0fef6a258388a.1322598103@xdev.gridcentric.ca>
	<4ED89A390200007800064FFE@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="gBBFr7Ir9EOA20Yy"
Content-Disposition: inline
In-Reply-To: <4ED89A390200007800064FFE@nat28.tlf.novell.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com, ian.campbell@citrix.com,
	andres@gridcentric.ca, keir.xen@gmail.com,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>,
	ian.jackson@citrix.com, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH] Re: [PATCH 6 of 9] x86/mm: Rework stale p2m
	auditing
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--gBBFr7Ir9EOA20Yy
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline

At 08:28 +0000 on 02 Dec (1322814505), Jan Beulich wrote:
>  >>> On 29.11.11 at 21:21, Andres Lagar-Cavilla <andres@lagarcavilla.org> wrote:
> > @@ -559,13 +560,15 @@ int set_p2m_entry(struct p2m_domain *p2m
> >  extern void p2m_pt_init(struct p2m_domain *p2m);
> >  
> >  /* Debugging and auditing of the P2M code? */
> > -#define P2M_AUDIT     0
> > +#define P2M_AUDIT     1
> >  #define P2M_DEBUGGING 0
> >  
> >  #if P2M_AUDIT
> 
> Was this change of the default really intended?

I think so - now that the ausdit code is not on any critical paths there's
no reason not to have it available by default.

> It uncovered a problem
> in 22356:cbb6b4b17024 (the code meanwhile moved elsewhere): In a
> 32-bit build,
> 
>         if ( gfn == 0x55555555 || gfn == 0x5555555555555555 )
> 
> causes (at least with some compiler versions, didn't check tonight's
> stage tester results yet) a compiler warning 

I don't think these debug values are serving any purpose.  How about we
just get rid of them? 

x86/mm: remove 0x55 debug pattern from M2P table

It's not really any more useful than explicitly setting new M2P entries
to the invalid value.

Signed-off-by: Tim Deegan <tim@xen.org>

diff -r 60d4e257d04b tools/libxc/xc_domain.c
--- a/tools/libxc/xc_domain.c	Fri Dec 02 09:05:26 2011 +0100
+++ b/tools/libxc/xc_domain.c	Fri Dec 02 10:19:18 2011 +0000
@@ -1474,8 +1474,7 @@ int xc_domain_debug_control(xc_interface
 
 int xc_domain_p2m_audit(xc_interface *xch, 
                         uint32_t domid,
-                        uint64_t *orphans_debug,
-                        uint64_t *orphans_invalid,
+                        uint64_t *orphans,
                         uint64_t *m2p_bad,   
                         uint64_t *p2m_bad)
 {
@@ -1486,10 +1485,9 @@ int xc_domain_p2m_audit(xc_interface *xc
     domctl.domain = domid;
     rc = do_domctl(xch, &domctl);
 
-    *orphans_debug      = domctl.u.audit_p2m.orphans_debug;
-    *orphans_invalid    = domctl.u.audit_p2m.orphans_invalid;
-    *m2p_bad            = domctl.u.audit_p2m.m2p_bad;
-    *p2m_bad            = domctl.u.audit_p2m.p2m_bad;
+    *orphans = domctl.u.audit_p2m.orphans;
+    *m2p_bad = domctl.u.audit_p2m.m2p_bad;
+    *p2m_bad = domctl.u.audit_p2m.p2m_bad;
 
     return rc;
 }
diff -r 60d4e257d04b tools/libxc/xenctrl.h
--- a/tools/libxc/xenctrl.h	Fri Dec 02 09:05:26 2011 +0100
+++ b/tools/libxc/xenctrl.h	Fri Dec 02 10:19:18 2011 +0000
@@ -718,9 +718,7 @@ int xc_domain_setdebugging(xc_interface 
  * @parm xch a handle to an open hypervisor interface
  * @parm domid the domain id whose top level p2m we 
  *       want to audit
- * @parm orphans_debug count of m2p entries for valid
- *       domain pages containing a debug value
- * @parm orphans_invalid count of m2p entries for valid
+ * @parm orphans count of m2p entries for valid
  *       domain pages containing an invalid value
  * @parm m2p_bad count of m2p entries mismatching the
  *       associated p2m entry for this domain
@@ -732,9 +730,8 @@ int xc_domain_setdebugging(xc_interface 
  *          -EFAULT: could not copy results back to guest
  */
 int xc_domain_p2m_audit(xc_interface *xch,
-				        uint32_t domid,
-                        uint64_t *orphans_debug,
-                        uint64_t *orphans_invalid,
+                        uint32_t domid,
+                        uint64_t *orphans,
                         uint64_t *m2p_bad,   
                         uint64_t *p2m_bad);
 
diff -r 60d4e257d04b xen/arch/x86/domctl.c
--- a/xen/arch/x86/domctl.c	Fri Dec 02 09:05:26 2011 +0100
+++ b/xen/arch/x86/domctl.c	Fri Dec 02 10:19:18 2011 +0000
@@ -1459,8 +1459,7 @@ long arch_do_domctl(
             break;
 
         audit_p2m(d,
-                  &domctl->u.audit_p2m.orphans_debug,
-                  &domctl->u.audit_p2m.orphans_invalid,
+                  &domctl->u.audit_p2m.orphans,
                   &domctl->u.audit_p2m.m2p_bad,
                   &domctl->u.audit_p2m.p2m_bad);
         rcu_unlock_domain(d);
diff -r 60d4e257d04b xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c	Fri Dec 02 09:05:26 2011 +0100
+++ b/xen/arch/x86/mm/p2m.c	Fri Dec 02 10:19:18 2011 +0000
@@ -307,13 +307,7 @@ int p2m_alloc_table(struct p2m_domain *p
             /* Pages should not be shared that early */
             ASSERT(gfn != SHARED_M2P_ENTRY);
             page_count++;
-            if (
-#ifdef __x86_64__
-                (gfn != 0x5555555555555555L)
-#else
-                (gfn != 0x55555555L)
-#endif
-                && gfn != INVALID_M2P_ENTRY
+            if ( gfn != INVALID_M2P_ENTRY
                 && !set_p2m_entry(p2m, gfn, mfn, PAGE_ORDER_4K, p2m_ram_rw, p2m->default_access) )
                 goto error_unlock;
         }
@@ -513,14 +507,7 @@ guest_physmap_add_entry(struct domain *d
         if ( page_get_owner(mfn_to_page(_mfn(mfn + i))) != d )
             continue;
         ogfn = mfn_to_gfn(d, _mfn(mfn+i));
-        if (
-#ifdef __x86_64__
-            (ogfn != 0x5555555555555555L)
-#else
-            (ogfn != 0x55555555L)
-#endif
-            && (ogfn != INVALID_M2P_ENTRY)
-            && (ogfn != gfn + i) )
+        if ( (ogfn != INVALID_M2P_ENTRY) && (ogfn != gfn + i) )
         {
             /* This machine frame is already mapped at another physical
              * address */
@@ -1447,8 +1434,7 @@ unsigned long paging_gva_to_gfn(struct v
 
 #if P2M_AUDIT
 void audit_p2m(struct domain *d,
-                uint64_t *orphans_debug,
-                uint64_t *orphans_invalid,
+               uint64_t *orphans,
                 uint64_t *m2p_bad,
                 uint64_t *p2m_bad)
 {
@@ -1456,7 +1442,7 @@ void audit_p2m(struct domain *d,
     struct domain *od;
     unsigned long mfn, gfn;
     mfn_t p2mfn;
-    unsigned long orphans_d = 0, orphans_i = 0, mpbad = 0, pmbad = 0;
+    unsigned long orphans_count = 0, mpbad = 0, pmbad = 0;
     p2m_access_t p2ma;
     p2m_type_t type;
     struct p2m_domain *p2m = p2m_get_hostp2m(d);
@@ -1492,20 +1478,12 @@ void audit_p2m(struct domain *d,
         gfn = get_gpfn_from_mfn(mfn);
         if ( gfn == INVALID_M2P_ENTRY )
         {
-            orphans_i++;
+            orphans_count++;
             P2M_PRINTK("orphaned guest page: mfn=%#lx has invalid gfn\n",
                            mfn);
             continue;
         }
 
-        if ( gfn == 0x55555555 || gfn == 0x5555555555555555 )
-        {
-            orphans_d++;
-            P2M_PRINTK("orphaned guest page: mfn=%#lx has debug gfn\n",
-                           mfn);
-            continue;
-        }
-
         if ( gfn == SHARED_M2P_ENTRY )
         {
             P2M_PRINTK("shared mfn (%lx) on domain page list!\n",
@@ -1538,9 +1516,8 @@ void audit_p2m(struct domain *d,
     p2m_unlock(p2m);
  
     P2M_PRINTK("p2m audit complete\n");
-    if ( orphans_i | orphans_d | mpbad | pmbad )
-        P2M_PRINTK("p2m audit found %lu orphans (%lu inval %lu debug)\n",
-                       orphans_i + orphans_d, orphans_i, orphans_d);
+    if ( orphans_count | mpbad | pmbad )
+        P2M_PRINTK("p2m audit found %lu orphans\n", orphans);
     if ( mpbad | pmbad )
     {
         P2M_PRINTK("p2m audit found %lu odd p2m, %lu bad m2p entries\n",
@@ -1549,10 +1526,9 @@ void audit_p2m(struct domain *d,
     }
 
 out_p2m_audit:
-    *orphans_debug      = (uint64_t) orphans_d;
-    *orphans_invalid    = (uint64_t) orphans_i;
-    *m2p_bad            = (uint64_t) mpbad;
-    *p2m_bad            = (uint64_t) pmbad;
+    *orphans = (uint64_t) orphans_count;
+    *m2p_bad = (uint64_t) mpbad;
+    *p2m_bad = (uint64_t) pmbad;
 }
 #endif /* P2M_AUDIT */
 
diff -r 60d4e257d04b xen/arch/x86/x86_32/mm.c
--- a/xen/arch/x86/x86_32/mm.c	Fri Dec 02 09:05:26 2011 +0100
+++ b/xen/arch/x86/x86_32/mm.c	Fri Dec 02 10:19:18 2011 +0000
@@ -114,8 +114,8 @@ void __init paging_init(void)
         l2e_write(&idle_pg_table_l2[l2_linear_offset(RO_MPT_VIRT_START) + i],
                   l2e_from_page(
                       pg, (__PAGE_HYPERVISOR | _PAGE_PSE) & ~_PAGE_RW));
-        /* Fill with an obvious debug pattern. */
-        memset((void *)(RDWR_MPT_VIRT_START + (i << L2_PAGETABLE_SHIFT)), 0x55,
+        /* Fill with INVALID_M2P_ENTRY. */
+        memset((void *)(RDWR_MPT_VIRT_START + (i << L2_PAGETABLE_SHIFT)), 0xFF,
                1UL << L2_PAGETABLE_SHIFT);
     }
 #undef CNT
diff -r 60d4e257d04b xen/arch/x86/x86_64/mm.c
--- a/xen/arch/x86/x86_64/mm.c	Fri Dec 02 09:05:26 2011 +0100
+++ b/xen/arch/x86/x86_64/mm.c	Fri Dec 02 10:19:18 2011 +0000
@@ -495,7 +495,8 @@ static int setup_compat_m2p_table(struct
                                PAGE_HYPERVISOR);
         if ( err )
             break;
-        memset((void *)rwva, 0x55, 1UL << L2_PAGETABLE_SHIFT);
+        /* Fill with INVALID_M2P_ENTRY. */
+        memset((void *)rwva, 0xFF, 1UL << L2_PAGETABLE_SHIFT);
         /* NB. Cannot be GLOBAL as the ptes get copied into per-VM space. */
         l2e_write(&l2_ro_mpt[l2_table_offset(va)], l2e_from_page(l1_pg, _PAGE_PSE|_PAGE_PRESENT));
     }
@@ -569,8 +570,9 @@ static int setup_m2p_table(struct mem_ho
                         PAGE_HYPERVISOR);
             if ( ret )
                 goto error;
+            /* Fill with INVALID_M2P_ENTRY. */
             memset((void *)(RDWR_MPT_VIRT_START + i * sizeof(unsigned long)),
-                   0x55, 1UL << L2_PAGETABLE_SHIFT);
+                   0xFF, 1UL << L2_PAGETABLE_SHIFT);
 
             ASSERT(!(l3e_get_flags(l3_ro_mpt[l3_table_offset(va)]) &
                   _PAGE_PSE));
@@ -727,8 +729,9 @@ void __init paging_init(void)
                 page_to_mfn(l1_pg),
                 1UL << PAGETABLE_ORDER,
                 PAGE_HYPERVISOR);
+            /* Fill with INVALID_M2P_ENTRY. */
             memset((void *)(RDWR_MPT_VIRT_START + (i << L2_PAGETABLE_SHIFT)),
-                   0x55, 1UL << L2_PAGETABLE_SHIFT);
+                   0xFF, 1UL << L2_PAGETABLE_SHIFT);
         }
         if ( !((unsigned long)l2_ro_mpt & ~PAGE_MASK) )
         {
diff -r 60d4e257d04b xen/include/asm-x86/p2m.h
--- a/xen/include/asm-x86/p2m.h	Fri Dec 02 09:05:26 2011 +0100
+++ b/xen/include/asm-x86/p2m.h	Fri Dec 02 10:19:18 2011 +0000
@@ -566,10 +566,9 @@ extern void p2m_pt_init(struct p2m_domai
 
 #if P2M_AUDIT
 extern void audit_p2m(struct domain *d,
-                        uint64_t *orphans_debug,
-                        uint64_t *orphans_invalid,
-                        uint64_t *m2p_bad,
-                        uint64_t *p2m_bad);
+                      uint64_t *orphans,
+                      uint64_t *m2p_bad,
+                      uint64_t *p2m_bad);
 #endif /* P2M_AUDIT */
 
 /* Printouts */
diff -r 60d4e257d04b xen/include/public/domctl.h
--- a/xen/include/public/domctl.h	Fri Dec 02 09:05:26 2011 +0100
+++ b/xen/include/public/domctl.h	Fri Dec 02 10:19:18 2011 +0000
@@ -806,8 +806,7 @@ DEFINE_XEN_GUEST_HANDLE(xen_domctl_mem_s
 
 struct xen_domctl_audit_p2m {
     /* OUT error counts */
-    uint64_t orphans_debug;
-    uint64_t orphans_invalid;
+    uint64_t orphans;
     uint64_t m2p_bad;
     uint64_t p2m_bad;
 };


--gBBFr7Ir9EOA20Yy
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: attachment; filename=x

x86/mm: remove 0x55 debug pattern from M2P table

It's not really any more useful than explicitly setting new M2P entries
to the invalid value.

Signed-off-by: Tim Deegan <tim@xen.org>

diff -r 60d4e257d04b tools/libxc/xc_domain.c
--- a/tools/libxc/xc_domain.c	Fri Dec 02 09:05:26 2011 +0100
+++ b/tools/libxc/xc_domain.c	Fri Dec 02 10:19:18 2011 +0000
@@ -1474,8 +1474,7 @@ int xc_domain_debug_control(xc_interface
 
 int xc_domain_p2m_audit(xc_interface *xch, 
                         uint32_t domid,
-                        uint64_t *orphans_debug,
-                        uint64_t *orphans_invalid,
+                        uint64_t *orphans,
                         uint64_t *m2p_bad,   
                         uint64_t *p2m_bad)
 {
@@ -1486,10 +1485,9 @@ int xc_domain_p2m_audit(xc_interface *xc
     domctl.domain = domid;
     rc = do_domctl(xch, &domctl);
 
-    *orphans_debug      = domctl.u.audit_p2m.orphans_debug;
-    *orphans_invalid    = domctl.u.audit_p2m.orphans_invalid;
-    *m2p_bad            = domctl.u.audit_p2m.m2p_bad;
-    *p2m_bad            = domctl.u.audit_p2m.p2m_bad;
+    *orphans = domctl.u.audit_p2m.orphans;
+    *m2p_bad = domctl.u.audit_p2m.m2p_bad;
+    *p2m_bad = domctl.u.audit_p2m.p2m_bad;
 
     return rc;
 }
diff -r 60d4e257d04b tools/libxc/xenctrl.h
--- a/tools/libxc/xenctrl.h	Fri Dec 02 09:05:26 2011 +0100
+++ b/tools/libxc/xenctrl.h	Fri Dec 02 10:19:18 2011 +0000
@@ -718,9 +718,7 @@ int xc_domain_setdebugging(xc_interface 
  * @parm xch a handle to an open hypervisor interface
  * @parm domid the domain id whose top level p2m we 
  *       want to audit
- * @parm orphans_debug count of m2p entries for valid
- *       domain pages containing a debug value
- * @parm orphans_invalid count of m2p entries for valid
+ * @parm orphans count of m2p entries for valid
  *       domain pages containing an invalid value
  * @parm m2p_bad count of m2p entries mismatching the
  *       associated p2m entry for this domain
@@ -732,9 +730,8 @@ int xc_domain_setdebugging(xc_interface 
  *          -EFAULT: could not copy results back to guest
  */
 int xc_domain_p2m_audit(xc_interface *xch,
-				        uint32_t domid,
-                        uint64_t *orphans_debug,
-                        uint64_t *orphans_invalid,
+                        uint32_t domid,
+                        uint64_t *orphans,
                         uint64_t *m2p_bad,   
                         uint64_t *p2m_bad);
 
diff -r 60d4e257d04b xen/arch/x86/domctl.c
--- a/xen/arch/x86/domctl.c	Fri Dec 02 09:05:26 2011 +0100
+++ b/xen/arch/x86/domctl.c	Fri Dec 02 10:19:18 2011 +0000
@@ -1459,8 +1459,7 @@ long arch_do_domctl(
             break;
 
         audit_p2m(d,
-                  &domctl->u.audit_p2m.orphans_debug,
-                  &domctl->u.audit_p2m.orphans_invalid,
+                  &domctl->u.audit_p2m.orphans,
                   &domctl->u.audit_p2m.m2p_bad,
                   &domctl->u.audit_p2m.p2m_bad);
         rcu_unlock_domain(d);
diff -r 60d4e257d04b xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c	Fri Dec 02 09:05:26 2011 +0100
+++ b/xen/arch/x86/mm/p2m.c	Fri Dec 02 10:19:18 2011 +0000
@@ -307,13 +307,7 @@ int p2m_alloc_table(struct p2m_domain *p
             /* Pages should not be shared that early */
             ASSERT(gfn != SHARED_M2P_ENTRY);
             page_count++;
-            if (
-#ifdef __x86_64__
-                (gfn != 0x5555555555555555L)
-#else
-                (gfn != 0x55555555L)
-#endif
-                && gfn != INVALID_M2P_ENTRY
+            if ( gfn != INVALID_M2P_ENTRY
                 && !set_p2m_entry(p2m, gfn, mfn, PAGE_ORDER_4K, p2m_ram_rw, p2m->default_access) )
                 goto error_unlock;
         }
@@ -513,14 +507,7 @@ guest_physmap_add_entry(struct domain *d
         if ( page_get_owner(mfn_to_page(_mfn(mfn + i))) != d )
             continue;
         ogfn = mfn_to_gfn(d, _mfn(mfn+i));
-        if (
-#ifdef __x86_64__
-            (ogfn != 0x5555555555555555L)
-#else
-            (ogfn != 0x55555555L)
-#endif
-            && (ogfn != INVALID_M2P_ENTRY)
-            && (ogfn != gfn + i) )
+        if ( (ogfn != INVALID_M2P_ENTRY) && (ogfn != gfn + i) )
         {
             /* This machine frame is already mapped at another physical
              * address */
@@ -1447,8 +1434,7 @@ unsigned long paging_gva_to_gfn(struct v
 
 #if P2M_AUDIT
 void audit_p2m(struct domain *d,
-                uint64_t *orphans_debug,
-                uint64_t *orphans_invalid,
+               uint64_t *orphans,
                 uint64_t *m2p_bad,
                 uint64_t *p2m_bad)
 {
@@ -1456,7 +1442,7 @@ void audit_p2m(struct domain *d,
     struct domain *od;
     unsigned long mfn, gfn;
     mfn_t p2mfn;
-    unsigned long orphans_d = 0, orphans_i = 0, mpbad = 0, pmbad = 0;
+    unsigned long orphans_count = 0, mpbad = 0, pmbad = 0;
     p2m_access_t p2ma;
     p2m_type_t type;
     struct p2m_domain *p2m = p2m_get_hostp2m(d);
@@ -1492,20 +1478,12 @@ void audit_p2m(struct domain *d,
         gfn = get_gpfn_from_mfn(mfn);
         if ( gfn == INVALID_M2P_ENTRY )
         {
-            orphans_i++;
+            orphans_count++;
             P2M_PRINTK("orphaned guest page: mfn=%#lx has invalid gfn\n",
                            mfn);
             continue;
         }
 
-        if ( gfn == 0x55555555 || gfn == 0x5555555555555555 )
-        {
-            orphans_d++;
-            P2M_PRINTK("orphaned guest page: mfn=%#lx has debug gfn\n",
-                           mfn);
-            continue;
-        }
-
         if ( gfn == SHARED_M2P_ENTRY )
         {
             P2M_PRINTK("shared mfn (%lx) on domain page list!\n",
@@ -1538,9 +1516,8 @@ void audit_p2m(struct domain *d,
     p2m_unlock(p2m);
  
     P2M_PRINTK("p2m audit complete\n");
-    if ( orphans_i | orphans_d | mpbad | pmbad )
-        P2M_PRINTK("p2m audit found %lu orphans (%lu inval %lu debug)\n",
-                       orphans_i + orphans_d, orphans_i, orphans_d);
+    if ( orphans_count | mpbad | pmbad )
+        P2M_PRINTK("p2m audit found %lu orphans\n", orphans);
     if ( mpbad | pmbad )
     {
         P2M_PRINTK("p2m audit found %lu odd p2m, %lu bad m2p entries\n",
@@ -1549,10 +1526,9 @@ void audit_p2m(struct domain *d,
     }
 
 out_p2m_audit:
-    *orphans_debug      = (uint64_t) orphans_d;
-    *orphans_invalid    = (uint64_t) orphans_i;
-    *m2p_bad            = (uint64_t) mpbad;
-    *p2m_bad            = (uint64_t) pmbad;
+    *orphans = (uint64_t) orphans_count;
+    *m2p_bad = (uint64_t) mpbad;
+    *p2m_bad = (uint64_t) pmbad;
 }
 #endif /* P2M_AUDIT */
 
diff -r 60d4e257d04b xen/arch/x86/x86_32/mm.c
--- a/xen/arch/x86/x86_32/mm.c	Fri Dec 02 09:05:26 2011 +0100
+++ b/xen/arch/x86/x86_32/mm.c	Fri Dec 02 10:19:18 2011 +0000
@@ -114,8 +114,8 @@ void __init paging_init(void)
         l2e_write(&idle_pg_table_l2[l2_linear_offset(RO_MPT_VIRT_START) + i],
                   l2e_from_page(
                       pg, (__PAGE_HYPERVISOR | _PAGE_PSE) & ~_PAGE_RW));
-        /* Fill with an obvious debug pattern. */
-        memset((void *)(RDWR_MPT_VIRT_START + (i << L2_PAGETABLE_SHIFT)), 0x55,
+        /* Fill with INVALID_M2P_ENTRY. */
+        memset((void *)(RDWR_MPT_VIRT_START + (i << L2_PAGETABLE_SHIFT)), 0xFF,
                1UL << L2_PAGETABLE_SHIFT);
     }
 #undef CNT
diff -r 60d4e257d04b xen/arch/x86/x86_64/mm.c
--- a/xen/arch/x86/x86_64/mm.c	Fri Dec 02 09:05:26 2011 +0100
+++ b/xen/arch/x86/x86_64/mm.c	Fri Dec 02 10:19:18 2011 +0000
@@ -495,7 +495,8 @@ static int setup_compat_m2p_table(struct
                                PAGE_HYPERVISOR);
         if ( err )
             break;
-        memset((void *)rwva, 0x55, 1UL << L2_PAGETABLE_SHIFT);
+        /* Fill with INVALID_M2P_ENTRY. */
+        memset((void *)rwva, 0xFF, 1UL << L2_PAGETABLE_SHIFT);
         /* NB. Cannot be GLOBAL as the ptes get copied into per-VM space. */
         l2e_write(&l2_ro_mpt[l2_table_offset(va)], l2e_from_page(l1_pg, _PAGE_PSE|_PAGE_PRESENT));
     }
@@ -569,8 +570,9 @@ static int setup_m2p_table(struct mem_ho
                         PAGE_HYPERVISOR);
             if ( ret )
                 goto error;
+            /* Fill with INVALID_M2P_ENTRY. */
             memset((void *)(RDWR_MPT_VIRT_START + i * sizeof(unsigned long)),
-                   0x55, 1UL << L2_PAGETABLE_SHIFT);
+                   0xFF, 1UL << L2_PAGETABLE_SHIFT);
 
             ASSERT(!(l3e_get_flags(l3_ro_mpt[l3_table_offset(va)]) &
                   _PAGE_PSE));
@@ -727,8 +729,9 @@ void __init paging_init(void)
                 page_to_mfn(l1_pg),
                 1UL << PAGETABLE_ORDER,
                 PAGE_HYPERVISOR);
+            /* Fill with INVALID_M2P_ENTRY. */
             memset((void *)(RDWR_MPT_VIRT_START + (i << L2_PAGETABLE_SHIFT)),
-                   0x55, 1UL << L2_PAGETABLE_SHIFT);
+                   0xFF, 1UL << L2_PAGETABLE_SHIFT);
         }
         if ( !((unsigned long)l2_ro_mpt & ~PAGE_MASK) )
         {
diff -r 60d4e257d04b xen/include/asm-x86/p2m.h
--- a/xen/include/asm-x86/p2m.h	Fri Dec 02 09:05:26 2011 +0100
+++ b/xen/include/asm-x86/p2m.h	Fri Dec 02 10:19:18 2011 +0000
@@ -566,10 +566,9 @@ extern void p2m_pt_init(struct p2m_domai
 
 #if P2M_AUDIT
 extern void audit_p2m(struct domain *d,
-                        uint64_t *orphans_debug,
-                        uint64_t *orphans_invalid,
-                        uint64_t *m2p_bad,
-                        uint64_t *p2m_bad);
+                      uint64_t *orphans,
+                      uint64_t *m2p_bad,
+                      uint64_t *p2m_bad);
 #endif /* P2M_AUDIT */
 
 /* Printouts */
diff -r 60d4e257d04b xen/include/public/domctl.h
--- a/xen/include/public/domctl.h	Fri Dec 02 09:05:26 2011 +0100
+++ b/xen/include/public/domctl.h	Fri Dec 02 10:19:18 2011 +0000
@@ -806,8 +806,7 @@ DEFINE_XEN_GUEST_HANDLE(xen_domctl_mem_s
 
 struct xen_domctl_audit_p2m {
     /* OUT error counts */
-    uint64_t orphans_debug;
-    uint64_t orphans_invalid;
+    uint64_t orphans;
     uint64_t m2p_bad;
     uint64_t p2m_bad;
 };

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

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

--gBBFr7Ir9EOA20Yy--


From xen-devel-bounces@lists.xensource.com Fri Dec 02 10:36:17 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 10:36:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWQTI-00024Y-0g; Fri, 02 Dec 2011 10:36:00 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RWQTG-00024N-E7
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 10:35:58 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-13.tower-182.messagelabs.com!1322822116!5063468!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8360 invoked from network); 2 Dec 2011 10:35:16 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-13.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 2 Dec 2011 10:35:16 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RWQQg-000MqR-Ta; Fri, 02 Dec 2011 10:33:18 +0000
Date: Fri, 2 Dec 2011 10:33:18 +0000
From: Tim Deegan <tim@xen.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20111202103318.GA86219@ocelot.phlegethon.org>
References: <patchbomb.1322598097@xdev.gridcentric.ca>
	<6626add0fef6a258388a.1322598103@xdev.gridcentric.ca>
	<4ED89A390200007800064FFE@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="gBBFr7Ir9EOA20Yy"
Content-Disposition: inline
In-Reply-To: <4ED89A390200007800064FFE@nat28.tlf.novell.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com, ian.campbell@citrix.com,
	andres@gridcentric.ca, keir.xen@gmail.com,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>,
	ian.jackson@citrix.com, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH] Re: [PATCH 6 of 9] x86/mm: Rework stale p2m
	auditing
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--gBBFr7Ir9EOA20Yy
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline

At 08:28 +0000 on 02 Dec (1322814505), Jan Beulich wrote:
>  >>> On 29.11.11 at 21:21, Andres Lagar-Cavilla <andres@lagarcavilla.org> wrote:
> > @@ -559,13 +560,15 @@ int set_p2m_entry(struct p2m_domain *p2m
> >  extern void p2m_pt_init(struct p2m_domain *p2m);
> >  
> >  /* Debugging and auditing of the P2M code? */
> > -#define P2M_AUDIT     0
> > +#define P2M_AUDIT     1
> >  #define P2M_DEBUGGING 0
> >  
> >  #if P2M_AUDIT
> 
> Was this change of the default really intended?

I think so - now that the ausdit code is not on any critical paths there's
no reason not to have it available by default.

> It uncovered a problem
> in 22356:cbb6b4b17024 (the code meanwhile moved elsewhere): In a
> 32-bit build,
> 
>         if ( gfn == 0x55555555 || gfn == 0x5555555555555555 )
> 
> causes (at least with some compiler versions, didn't check tonight's
> stage tester results yet) a compiler warning 

I don't think these debug values are serving any purpose.  How about we
just get rid of them? 

x86/mm: remove 0x55 debug pattern from M2P table

It's not really any more useful than explicitly setting new M2P entries
to the invalid value.

Signed-off-by: Tim Deegan <tim@xen.org>

diff -r 60d4e257d04b tools/libxc/xc_domain.c
--- a/tools/libxc/xc_domain.c	Fri Dec 02 09:05:26 2011 +0100
+++ b/tools/libxc/xc_domain.c	Fri Dec 02 10:19:18 2011 +0000
@@ -1474,8 +1474,7 @@ int xc_domain_debug_control(xc_interface
 
 int xc_domain_p2m_audit(xc_interface *xch, 
                         uint32_t domid,
-                        uint64_t *orphans_debug,
-                        uint64_t *orphans_invalid,
+                        uint64_t *orphans,
                         uint64_t *m2p_bad,   
                         uint64_t *p2m_bad)
 {
@@ -1486,10 +1485,9 @@ int xc_domain_p2m_audit(xc_interface *xc
     domctl.domain = domid;
     rc = do_domctl(xch, &domctl);
 
-    *orphans_debug      = domctl.u.audit_p2m.orphans_debug;
-    *orphans_invalid    = domctl.u.audit_p2m.orphans_invalid;
-    *m2p_bad            = domctl.u.audit_p2m.m2p_bad;
-    *p2m_bad            = domctl.u.audit_p2m.p2m_bad;
+    *orphans = domctl.u.audit_p2m.orphans;
+    *m2p_bad = domctl.u.audit_p2m.m2p_bad;
+    *p2m_bad = domctl.u.audit_p2m.p2m_bad;
 
     return rc;
 }
diff -r 60d4e257d04b tools/libxc/xenctrl.h
--- a/tools/libxc/xenctrl.h	Fri Dec 02 09:05:26 2011 +0100
+++ b/tools/libxc/xenctrl.h	Fri Dec 02 10:19:18 2011 +0000
@@ -718,9 +718,7 @@ int xc_domain_setdebugging(xc_interface 
  * @parm xch a handle to an open hypervisor interface
  * @parm domid the domain id whose top level p2m we 
  *       want to audit
- * @parm orphans_debug count of m2p entries for valid
- *       domain pages containing a debug value
- * @parm orphans_invalid count of m2p entries for valid
+ * @parm orphans count of m2p entries for valid
  *       domain pages containing an invalid value
  * @parm m2p_bad count of m2p entries mismatching the
  *       associated p2m entry for this domain
@@ -732,9 +730,8 @@ int xc_domain_setdebugging(xc_interface 
  *          -EFAULT: could not copy results back to guest
  */
 int xc_domain_p2m_audit(xc_interface *xch,
-				        uint32_t domid,
-                        uint64_t *orphans_debug,
-                        uint64_t *orphans_invalid,
+                        uint32_t domid,
+                        uint64_t *orphans,
                         uint64_t *m2p_bad,   
                         uint64_t *p2m_bad);
 
diff -r 60d4e257d04b xen/arch/x86/domctl.c
--- a/xen/arch/x86/domctl.c	Fri Dec 02 09:05:26 2011 +0100
+++ b/xen/arch/x86/domctl.c	Fri Dec 02 10:19:18 2011 +0000
@@ -1459,8 +1459,7 @@ long arch_do_domctl(
             break;
 
         audit_p2m(d,
-                  &domctl->u.audit_p2m.orphans_debug,
-                  &domctl->u.audit_p2m.orphans_invalid,
+                  &domctl->u.audit_p2m.orphans,
                   &domctl->u.audit_p2m.m2p_bad,
                   &domctl->u.audit_p2m.p2m_bad);
         rcu_unlock_domain(d);
diff -r 60d4e257d04b xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c	Fri Dec 02 09:05:26 2011 +0100
+++ b/xen/arch/x86/mm/p2m.c	Fri Dec 02 10:19:18 2011 +0000
@@ -307,13 +307,7 @@ int p2m_alloc_table(struct p2m_domain *p
             /* Pages should not be shared that early */
             ASSERT(gfn != SHARED_M2P_ENTRY);
             page_count++;
-            if (
-#ifdef __x86_64__
-                (gfn != 0x5555555555555555L)
-#else
-                (gfn != 0x55555555L)
-#endif
-                && gfn != INVALID_M2P_ENTRY
+            if ( gfn != INVALID_M2P_ENTRY
                 && !set_p2m_entry(p2m, gfn, mfn, PAGE_ORDER_4K, p2m_ram_rw, p2m->default_access) )
                 goto error_unlock;
         }
@@ -513,14 +507,7 @@ guest_physmap_add_entry(struct domain *d
         if ( page_get_owner(mfn_to_page(_mfn(mfn + i))) != d )
             continue;
         ogfn = mfn_to_gfn(d, _mfn(mfn+i));
-        if (
-#ifdef __x86_64__
-            (ogfn != 0x5555555555555555L)
-#else
-            (ogfn != 0x55555555L)
-#endif
-            && (ogfn != INVALID_M2P_ENTRY)
-            && (ogfn != gfn + i) )
+        if ( (ogfn != INVALID_M2P_ENTRY) && (ogfn != gfn + i) )
         {
             /* This machine frame is already mapped at another physical
              * address */
@@ -1447,8 +1434,7 @@ unsigned long paging_gva_to_gfn(struct v
 
 #if P2M_AUDIT
 void audit_p2m(struct domain *d,
-                uint64_t *orphans_debug,
-                uint64_t *orphans_invalid,
+               uint64_t *orphans,
                 uint64_t *m2p_bad,
                 uint64_t *p2m_bad)
 {
@@ -1456,7 +1442,7 @@ void audit_p2m(struct domain *d,
     struct domain *od;
     unsigned long mfn, gfn;
     mfn_t p2mfn;
-    unsigned long orphans_d = 0, orphans_i = 0, mpbad = 0, pmbad = 0;
+    unsigned long orphans_count = 0, mpbad = 0, pmbad = 0;
     p2m_access_t p2ma;
     p2m_type_t type;
     struct p2m_domain *p2m = p2m_get_hostp2m(d);
@@ -1492,20 +1478,12 @@ void audit_p2m(struct domain *d,
         gfn = get_gpfn_from_mfn(mfn);
         if ( gfn == INVALID_M2P_ENTRY )
         {
-            orphans_i++;
+            orphans_count++;
             P2M_PRINTK("orphaned guest page: mfn=%#lx has invalid gfn\n",
                            mfn);
             continue;
         }
 
-        if ( gfn == 0x55555555 || gfn == 0x5555555555555555 )
-        {
-            orphans_d++;
-            P2M_PRINTK("orphaned guest page: mfn=%#lx has debug gfn\n",
-                           mfn);
-            continue;
-        }
-
         if ( gfn == SHARED_M2P_ENTRY )
         {
             P2M_PRINTK("shared mfn (%lx) on domain page list!\n",
@@ -1538,9 +1516,8 @@ void audit_p2m(struct domain *d,
     p2m_unlock(p2m);
  
     P2M_PRINTK("p2m audit complete\n");
-    if ( orphans_i | orphans_d | mpbad | pmbad )
-        P2M_PRINTK("p2m audit found %lu orphans (%lu inval %lu debug)\n",
-                       orphans_i + orphans_d, orphans_i, orphans_d);
+    if ( orphans_count | mpbad | pmbad )
+        P2M_PRINTK("p2m audit found %lu orphans\n", orphans);
     if ( mpbad | pmbad )
     {
         P2M_PRINTK("p2m audit found %lu odd p2m, %lu bad m2p entries\n",
@@ -1549,10 +1526,9 @@ void audit_p2m(struct domain *d,
     }
 
 out_p2m_audit:
-    *orphans_debug      = (uint64_t) orphans_d;
-    *orphans_invalid    = (uint64_t) orphans_i;
-    *m2p_bad            = (uint64_t) mpbad;
-    *p2m_bad            = (uint64_t) pmbad;
+    *orphans = (uint64_t) orphans_count;
+    *m2p_bad = (uint64_t) mpbad;
+    *p2m_bad = (uint64_t) pmbad;
 }
 #endif /* P2M_AUDIT */
 
diff -r 60d4e257d04b xen/arch/x86/x86_32/mm.c
--- a/xen/arch/x86/x86_32/mm.c	Fri Dec 02 09:05:26 2011 +0100
+++ b/xen/arch/x86/x86_32/mm.c	Fri Dec 02 10:19:18 2011 +0000
@@ -114,8 +114,8 @@ void __init paging_init(void)
         l2e_write(&idle_pg_table_l2[l2_linear_offset(RO_MPT_VIRT_START) + i],
                   l2e_from_page(
                       pg, (__PAGE_HYPERVISOR | _PAGE_PSE) & ~_PAGE_RW));
-        /* Fill with an obvious debug pattern. */
-        memset((void *)(RDWR_MPT_VIRT_START + (i << L2_PAGETABLE_SHIFT)), 0x55,
+        /* Fill with INVALID_M2P_ENTRY. */
+        memset((void *)(RDWR_MPT_VIRT_START + (i << L2_PAGETABLE_SHIFT)), 0xFF,
                1UL << L2_PAGETABLE_SHIFT);
     }
 #undef CNT
diff -r 60d4e257d04b xen/arch/x86/x86_64/mm.c
--- a/xen/arch/x86/x86_64/mm.c	Fri Dec 02 09:05:26 2011 +0100
+++ b/xen/arch/x86/x86_64/mm.c	Fri Dec 02 10:19:18 2011 +0000
@@ -495,7 +495,8 @@ static int setup_compat_m2p_table(struct
                                PAGE_HYPERVISOR);
         if ( err )
             break;
-        memset((void *)rwva, 0x55, 1UL << L2_PAGETABLE_SHIFT);
+        /* Fill with INVALID_M2P_ENTRY. */
+        memset((void *)rwva, 0xFF, 1UL << L2_PAGETABLE_SHIFT);
         /* NB. Cannot be GLOBAL as the ptes get copied into per-VM space. */
         l2e_write(&l2_ro_mpt[l2_table_offset(va)], l2e_from_page(l1_pg, _PAGE_PSE|_PAGE_PRESENT));
     }
@@ -569,8 +570,9 @@ static int setup_m2p_table(struct mem_ho
                         PAGE_HYPERVISOR);
             if ( ret )
                 goto error;
+            /* Fill with INVALID_M2P_ENTRY. */
             memset((void *)(RDWR_MPT_VIRT_START + i * sizeof(unsigned long)),
-                   0x55, 1UL << L2_PAGETABLE_SHIFT);
+                   0xFF, 1UL << L2_PAGETABLE_SHIFT);
 
             ASSERT(!(l3e_get_flags(l3_ro_mpt[l3_table_offset(va)]) &
                   _PAGE_PSE));
@@ -727,8 +729,9 @@ void __init paging_init(void)
                 page_to_mfn(l1_pg),
                 1UL << PAGETABLE_ORDER,
                 PAGE_HYPERVISOR);
+            /* Fill with INVALID_M2P_ENTRY. */
             memset((void *)(RDWR_MPT_VIRT_START + (i << L2_PAGETABLE_SHIFT)),
-                   0x55, 1UL << L2_PAGETABLE_SHIFT);
+                   0xFF, 1UL << L2_PAGETABLE_SHIFT);
         }
         if ( !((unsigned long)l2_ro_mpt & ~PAGE_MASK) )
         {
diff -r 60d4e257d04b xen/include/asm-x86/p2m.h
--- a/xen/include/asm-x86/p2m.h	Fri Dec 02 09:05:26 2011 +0100
+++ b/xen/include/asm-x86/p2m.h	Fri Dec 02 10:19:18 2011 +0000
@@ -566,10 +566,9 @@ extern void p2m_pt_init(struct p2m_domai
 
 #if P2M_AUDIT
 extern void audit_p2m(struct domain *d,
-                        uint64_t *orphans_debug,
-                        uint64_t *orphans_invalid,
-                        uint64_t *m2p_bad,
-                        uint64_t *p2m_bad);
+                      uint64_t *orphans,
+                      uint64_t *m2p_bad,
+                      uint64_t *p2m_bad);
 #endif /* P2M_AUDIT */
 
 /* Printouts */
diff -r 60d4e257d04b xen/include/public/domctl.h
--- a/xen/include/public/domctl.h	Fri Dec 02 09:05:26 2011 +0100
+++ b/xen/include/public/domctl.h	Fri Dec 02 10:19:18 2011 +0000
@@ -806,8 +806,7 @@ DEFINE_XEN_GUEST_HANDLE(xen_domctl_mem_s
 
 struct xen_domctl_audit_p2m {
     /* OUT error counts */
-    uint64_t orphans_debug;
-    uint64_t orphans_invalid;
+    uint64_t orphans;
     uint64_t m2p_bad;
     uint64_t p2m_bad;
 };


--gBBFr7Ir9EOA20Yy
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: attachment; filename=x

x86/mm: remove 0x55 debug pattern from M2P table

It's not really any more useful than explicitly setting new M2P entries
to the invalid value.

Signed-off-by: Tim Deegan <tim@xen.org>

diff -r 60d4e257d04b tools/libxc/xc_domain.c
--- a/tools/libxc/xc_domain.c	Fri Dec 02 09:05:26 2011 +0100
+++ b/tools/libxc/xc_domain.c	Fri Dec 02 10:19:18 2011 +0000
@@ -1474,8 +1474,7 @@ int xc_domain_debug_control(xc_interface
 
 int xc_domain_p2m_audit(xc_interface *xch, 
                         uint32_t domid,
-                        uint64_t *orphans_debug,
-                        uint64_t *orphans_invalid,
+                        uint64_t *orphans,
                         uint64_t *m2p_bad,   
                         uint64_t *p2m_bad)
 {
@@ -1486,10 +1485,9 @@ int xc_domain_p2m_audit(xc_interface *xc
     domctl.domain = domid;
     rc = do_domctl(xch, &domctl);
 
-    *orphans_debug      = domctl.u.audit_p2m.orphans_debug;
-    *orphans_invalid    = domctl.u.audit_p2m.orphans_invalid;
-    *m2p_bad            = domctl.u.audit_p2m.m2p_bad;
-    *p2m_bad            = domctl.u.audit_p2m.p2m_bad;
+    *orphans = domctl.u.audit_p2m.orphans;
+    *m2p_bad = domctl.u.audit_p2m.m2p_bad;
+    *p2m_bad = domctl.u.audit_p2m.p2m_bad;
 
     return rc;
 }
diff -r 60d4e257d04b tools/libxc/xenctrl.h
--- a/tools/libxc/xenctrl.h	Fri Dec 02 09:05:26 2011 +0100
+++ b/tools/libxc/xenctrl.h	Fri Dec 02 10:19:18 2011 +0000
@@ -718,9 +718,7 @@ int xc_domain_setdebugging(xc_interface 
  * @parm xch a handle to an open hypervisor interface
  * @parm domid the domain id whose top level p2m we 
  *       want to audit
- * @parm orphans_debug count of m2p entries for valid
- *       domain pages containing a debug value
- * @parm orphans_invalid count of m2p entries for valid
+ * @parm orphans count of m2p entries for valid
  *       domain pages containing an invalid value
  * @parm m2p_bad count of m2p entries mismatching the
  *       associated p2m entry for this domain
@@ -732,9 +730,8 @@ int xc_domain_setdebugging(xc_interface 
  *          -EFAULT: could not copy results back to guest
  */
 int xc_domain_p2m_audit(xc_interface *xch,
-				        uint32_t domid,
-                        uint64_t *orphans_debug,
-                        uint64_t *orphans_invalid,
+                        uint32_t domid,
+                        uint64_t *orphans,
                         uint64_t *m2p_bad,   
                         uint64_t *p2m_bad);
 
diff -r 60d4e257d04b xen/arch/x86/domctl.c
--- a/xen/arch/x86/domctl.c	Fri Dec 02 09:05:26 2011 +0100
+++ b/xen/arch/x86/domctl.c	Fri Dec 02 10:19:18 2011 +0000
@@ -1459,8 +1459,7 @@ long arch_do_domctl(
             break;
 
         audit_p2m(d,
-                  &domctl->u.audit_p2m.orphans_debug,
-                  &domctl->u.audit_p2m.orphans_invalid,
+                  &domctl->u.audit_p2m.orphans,
                   &domctl->u.audit_p2m.m2p_bad,
                   &domctl->u.audit_p2m.p2m_bad);
         rcu_unlock_domain(d);
diff -r 60d4e257d04b xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c	Fri Dec 02 09:05:26 2011 +0100
+++ b/xen/arch/x86/mm/p2m.c	Fri Dec 02 10:19:18 2011 +0000
@@ -307,13 +307,7 @@ int p2m_alloc_table(struct p2m_domain *p
             /* Pages should not be shared that early */
             ASSERT(gfn != SHARED_M2P_ENTRY);
             page_count++;
-            if (
-#ifdef __x86_64__
-                (gfn != 0x5555555555555555L)
-#else
-                (gfn != 0x55555555L)
-#endif
-                && gfn != INVALID_M2P_ENTRY
+            if ( gfn != INVALID_M2P_ENTRY
                 && !set_p2m_entry(p2m, gfn, mfn, PAGE_ORDER_4K, p2m_ram_rw, p2m->default_access) )
                 goto error_unlock;
         }
@@ -513,14 +507,7 @@ guest_physmap_add_entry(struct domain *d
         if ( page_get_owner(mfn_to_page(_mfn(mfn + i))) != d )
             continue;
         ogfn = mfn_to_gfn(d, _mfn(mfn+i));
-        if (
-#ifdef __x86_64__
-            (ogfn != 0x5555555555555555L)
-#else
-            (ogfn != 0x55555555L)
-#endif
-            && (ogfn != INVALID_M2P_ENTRY)
-            && (ogfn != gfn + i) )
+        if ( (ogfn != INVALID_M2P_ENTRY) && (ogfn != gfn + i) )
         {
             /* This machine frame is already mapped at another physical
              * address */
@@ -1447,8 +1434,7 @@ unsigned long paging_gva_to_gfn(struct v
 
 #if P2M_AUDIT
 void audit_p2m(struct domain *d,
-                uint64_t *orphans_debug,
-                uint64_t *orphans_invalid,
+               uint64_t *orphans,
                 uint64_t *m2p_bad,
                 uint64_t *p2m_bad)
 {
@@ -1456,7 +1442,7 @@ void audit_p2m(struct domain *d,
     struct domain *od;
     unsigned long mfn, gfn;
     mfn_t p2mfn;
-    unsigned long orphans_d = 0, orphans_i = 0, mpbad = 0, pmbad = 0;
+    unsigned long orphans_count = 0, mpbad = 0, pmbad = 0;
     p2m_access_t p2ma;
     p2m_type_t type;
     struct p2m_domain *p2m = p2m_get_hostp2m(d);
@@ -1492,20 +1478,12 @@ void audit_p2m(struct domain *d,
         gfn = get_gpfn_from_mfn(mfn);
         if ( gfn == INVALID_M2P_ENTRY )
         {
-            orphans_i++;
+            orphans_count++;
             P2M_PRINTK("orphaned guest page: mfn=%#lx has invalid gfn\n",
                            mfn);
             continue;
         }
 
-        if ( gfn == 0x55555555 || gfn == 0x5555555555555555 )
-        {
-            orphans_d++;
-            P2M_PRINTK("orphaned guest page: mfn=%#lx has debug gfn\n",
-                           mfn);
-            continue;
-        }
-
         if ( gfn == SHARED_M2P_ENTRY )
         {
             P2M_PRINTK("shared mfn (%lx) on domain page list!\n",
@@ -1538,9 +1516,8 @@ void audit_p2m(struct domain *d,
     p2m_unlock(p2m);
  
     P2M_PRINTK("p2m audit complete\n");
-    if ( orphans_i | orphans_d | mpbad | pmbad )
-        P2M_PRINTK("p2m audit found %lu orphans (%lu inval %lu debug)\n",
-                       orphans_i + orphans_d, orphans_i, orphans_d);
+    if ( orphans_count | mpbad | pmbad )
+        P2M_PRINTK("p2m audit found %lu orphans\n", orphans);
     if ( mpbad | pmbad )
     {
         P2M_PRINTK("p2m audit found %lu odd p2m, %lu bad m2p entries\n",
@@ -1549,10 +1526,9 @@ void audit_p2m(struct domain *d,
     }
 
 out_p2m_audit:
-    *orphans_debug      = (uint64_t) orphans_d;
-    *orphans_invalid    = (uint64_t) orphans_i;
-    *m2p_bad            = (uint64_t) mpbad;
-    *p2m_bad            = (uint64_t) pmbad;
+    *orphans = (uint64_t) orphans_count;
+    *m2p_bad = (uint64_t) mpbad;
+    *p2m_bad = (uint64_t) pmbad;
 }
 #endif /* P2M_AUDIT */
 
diff -r 60d4e257d04b xen/arch/x86/x86_32/mm.c
--- a/xen/arch/x86/x86_32/mm.c	Fri Dec 02 09:05:26 2011 +0100
+++ b/xen/arch/x86/x86_32/mm.c	Fri Dec 02 10:19:18 2011 +0000
@@ -114,8 +114,8 @@ void __init paging_init(void)
         l2e_write(&idle_pg_table_l2[l2_linear_offset(RO_MPT_VIRT_START) + i],
                   l2e_from_page(
                       pg, (__PAGE_HYPERVISOR | _PAGE_PSE) & ~_PAGE_RW));
-        /* Fill with an obvious debug pattern. */
-        memset((void *)(RDWR_MPT_VIRT_START + (i << L2_PAGETABLE_SHIFT)), 0x55,
+        /* Fill with INVALID_M2P_ENTRY. */
+        memset((void *)(RDWR_MPT_VIRT_START + (i << L2_PAGETABLE_SHIFT)), 0xFF,
                1UL << L2_PAGETABLE_SHIFT);
     }
 #undef CNT
diff -r 60d4e257d04b xen/arch/x86/x86_64/mm.c
--- a/xen/arch/x86/x86_64/mm.c	Fri Dec 02 09:05:26 2011 +0100
+++ b/xen/arch/x86/x86_64/mm.c	Fri Dec 02 10:19:18 2011 +0000
@@ -495,7 +495,8 @@ static int setup_compat_m2p_table(struct
                                PAGE_HYPERVISOR);
         if ( err )
             break;
-        memset((void *)rwva, 0x55, 1UL << L2_PAGETABLE_SHIFT);
+        /* Fill with INVALID_M2P_ENTRY. */
+        memset((void *)rwva, 0xFF, 1UL << L2_PAGETABLE_SHIFT);
         /* NB. Cannot be GLOBAL as the ptes get copied into per-VM space. */
         l2e_write(&l2_ro_mpt[l2_table_offset(va)], l2e_from_page(l1_pg, _PAGE_PSE|_PAGE_PRESENT));
     }
@@ -569,8 +570,9 @@ static int setup_m2p_table(struct mem_ho
                         PAGE_HYPERVISOR);
             if ( ret )
                 goto error;
+            /* Fill with INVALID_M2P_ENTRY. */
             memset((void *)(RDWR_MPT_VIRT_START + i * sizeof(unsigned long)),
-                   0x55, 1UL << L2_PAGETABLE_SHIFT);
+                   0xFF, 1UL << L2_PAGETABLE_SHIFT);
 
             ASSERT(!(l3e_get_flags(l3_ro_mpt[l3_table_offset(va)]) &
                   _PAGE_PSE));
@@ -727,8 +729,9 @@ void __init paging_init(void)
                 page_to_mfn(l1_pg),
                 1UL << PAGETABLE_ORDER,
                 PAGE_HYPERVISOR);
+            /* Fill with INVALID_M2P_ENTRY. */
             memset((void *)(RDWR_MPT_VIRT_START + (i << L2_PAGETABLE_SHIFT)),
-                   0x55, 1UL << L2_PAGETABLE_SHIFT);
+                   0xFF, 1UL << L2_PAGETABLE_SHIFT);
         }
         if ( !((unsigned long)l2_ro_mpt & ~PAGE_MASK) )
         {
diff -r 60d4e257d04b xen/include/asm-x86/p2m.h
--- a/xen/include/asm-x86/p2m.h	Fri Dec 02 09:05:26 2011 +0100
+++ b/xen/include/asm-x86/p2m.h	Fri Dec 02 10:19:18 2011 +0000
@@ -566,10 +566,9 @@ extern void p2m_pt_init(struct p2m_domai
 
 #if P2M_AUDIT
 extern void audit_p2m(struct domain *d,
-                        uint64_t *orphans_debug,
-                        uint64_t *orphans_invalid,
-                        uint64_t *m2p_bad,
-                        uint64_t *p2m_bad);
+                      uint64_t *orphans,
+                      uint64_t *m2p_bad,
+                      uint64_t *p2m_bad);
 #endif /* P2M_AUDIT */
 
 /* Printouts */
diff -r 60d4e257d04b xen/include/public/domctl.h
--- a/xen/include/public/domctl.h	Fri Dec 02 09:05:26 2011 +0100
+++ b/xen/include/public/domctl.h	Fri Dec 02 10:19:18 2011 +0000
@@ -806,8 +806,7 @@ DEFINE_XEN_GUEST_HANDLE(xen_domctl_mem_s
 
 struct xen_domctl_audit_p2m {
     /* OUT error counts */
-    uint64_t orphans_debug;
-    uint64_t orphans_invalid;
+    uint64_t orphans;
     uint64_t m2p_bad;
     uint64_t p2m_bad;
 };

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

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

--gBBFr7Ir9EOA20Yy--


From xen-devel-bounces@lists.xensource.com Fri Dec 02 10:42:12 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 10:42:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWQZ0-0002Sl-Ny; Fri, 02 Dec 2011 10:41:54 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pasik@iki.fi>) id 1RWQYz-0002SQ-09
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 10:41:53 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-13.tower-174.messagelabs.com!1322822471!3977800!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA0NTQ4MTE=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14273 invoked from network); 2 Dec 2011 10:41:12 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-13.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 2 Dec 2011 10:41:12 -0000
X-Originating-Ip: [194.89.68.22]
Received: from ydin.reaktio.net (reaktio.net [194.89.68.22])
	by smtp.tele.fi (Postfix) with ESMTP id 409E91223;
	Fri,  2 Dec 2011 12:41:11 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 1A1CC2009A; Fri,  2 Dec 2011 12:41:11 +0200 (EET)
Date: Fri, 2 Dec 2011 12:41:10 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Stefan Bader <stefan.bader@canonical.com>
Message-ID: <20111202104110.GL12984@reaktio.net>
References: <4ED798B2.1040309@canonical.com>
	<20111201180944.GH12984@reaktio.net>
	<4ED8A45A.3050403@canonical.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4ED8A45A.3050403@canonical.com>
User-Agent: Mutt/1.5.18 (2008-05-17)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Xen 4.x / Linux 3.x (dom0 and HVM domU) and
	NIC	handling
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Dec 02, 2011 at 11:11:38AM +0100, Stefan Bader wrote:
> On 01.12.2011 19:09, Pasi K=E4rkk=E4inen wrote:
> > On Thu, Dec 01, 2011 at 04:09:38PM +0100, Stefan Bader wrote:
> >> Moving to public discussion...
> >>
> >> This was found with Xen hypervisor version supporting device unpluggin=
g and the
> >> domU kernel having net-/blkfront and pci platform built-in (or as modu=
le).
> >>
> >> The block device is defined as hda and the NIC type=3Dioemu (so theore=
tically
> >> guests without pv support would work, too).
> >>
> >> Since both drivers are present, the kernel tries to unplug the emulate=
d devices
> >> and succeeds. The blkfront driver detects the xvda device available in=
 parallel
> >> and is working ok.
> >>
> >> However the network interface does not work. There are entries present=
 under
> >> sysfs for the xenbus but trying to bring it up fails with errors. And =
also there
> >> seems to be no mac address set (all zeros in sysfs).
> >> When the type=3Dioemu is removed in the configuration, this works.
> >>
> >> I have not much more debugging information beyond that, yet. But it so=
unds a bit
> >> like NICs should behave the same as block devices. So if there is an e=
mulated
> >> device defined there will be an alternate paravirt interface for it an=
d after
> >> unplugging the emulated ones we end up with the pv ones.
> >> Is that something that can be seen with newer Xen versions, too (I am =
using 4.1.1)?
> >>
> > =

> > Hey,
> > =

> > Have you seen?: =

> > http://wiki.xen.org/xenwiki/XenLinuxPVonHVMdrivers
> > =

> > Especially the following note:
> > "NOTE! If you have "type=3Dioemu" specified for the "vif"-line, PVHVM d=
rivers WILL NOT work! Don't specify "type" parameter for the vif. (with typ=
e=3Dioemu the pvhvm nic in the VM will have mac address full of zeroes - an=
d thus won't work!)."
> > =

> > "type=3Dioemu" is not needed, at least with xm/xend toolstack both HVM =
and PVHVM guests work OK without it.
> > =

> > -- Pasi
> > =

> Thanks Pasi,
> =

> hmm, so it is documented actually and thus sort of expected. Still it is
> confusing. For one driver it does not make a difference to use the form o=
f an
> emulated device in the config, for the other it does. The xl stack works,=
 the xm
> stack does not.
> And then, ok this is probably a quite naive approach, it seemed to make s=
ense to
> go through the pain of always having potentially both interfaces available
> (emulated and pv) so in theory the same guest config can accommodate a gu=
est os
> supporting one or the other (or easily switch from one to the other). Oth=
erwise
> I would expect an emulated device only when I have hd? in the config and =
a pv
> device when I write xvd?.
> =


This works for both HVM and PVHVM (also mentioned on the wiki page):
vif =3D [ 'mac=3D00:16:5e:02:07:45, bridge=3Dxenbr0, model=3De1000' ]

So there's no need for "type=3Dioemu" option with xm/xend.

You can switch between HVM and PVHVM with:
xen_platform_pci=3D0|1

-- Pasi


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

From xen-devel-bounces@lists.xensource.com Fri Dec 02 10:42:12 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 10:42:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWQZ0-0002Sl-Ny; Fri, 02 Dec 2011 10:41:54 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pasik@iki.fi>) id 1RWQYz-0002SQ-09
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 10:41:53 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-13.tower-174.messagelabs.com!1322822471!3977800!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA0NTQ4MTE=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14273 invoked from network); 2 Dec 2011 10:41:12 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-13.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 2 Dec 2011 10:41:12 -0000
X-Originating-Ip: [194.89.68.22]
Received: from ydin.reaktio.net (reaktio.net [194.89.68.22])
	by smtp.tele.fi (Postfix) with ESMTP id 409E91223;
	Fri,  2 Dec 2011 12:41:11 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 1A1CC2009A; Fri,  2 Dec 2011 12:41:11 +0200 (EET)
Date: Fri, 2 Dec 2011 12:41:10 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Stefan Bader <stefan.bader@canonical.com>
Message-ID: <20111202104110.GL12984@reaktio.net>
References: <4ED798B2.1040309@canonical.com>
	<20111201180944.GH12984@reaktio.net>
	<4ED8A45A.3050403@canonical.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4ED8A45A.3050403@canonical.com>
User-Agent: Mutt/1.5.18 (2008-05-17)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Xen 4.x / Linux 3.x (dom0 and HVM domU) and
	NIC	handling
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Dec 02, 2011 at 11:11:38AM +0100, Stefan Bader wrote:
> On 01.12.2011 19:09, Pasi K=E4rkk=E4inen wrote:
> > On Thu, Dec 01, 2011 at 04:09:38PM +0100, Stefan Bader wrote:
> >> Moving to public discussion...
> >>
> >> This was found with Xen hypervisor version supporting device unpluggin=
g and the
> >> domU kernel having net-/blkfront and pci platform built-in (or as modu=
le).
> >>
> >> The block device is defined as hda and the NIC type=3Dioemu (so theore=
tically
> >> guests without pv support would work, too).
> >>
> >> Since both drivers are present, the kernel tries to unplug the emulate=
d devices
> >> and succeeds. The blkfront driver detects the xvda device available in=
 parallel
> >> and is working ok.
> >>
> >> However the network interface does not work. There are entries present=
 under
> >> sysfs for the xenbus but trying to bring it up fails with errors. And =
also there
> >> seems to be no mac address set (all zeros in sysfs).
> >> When the type=3Dioemu is removed in the configuration, this works.
> >>
> >> I have not much more debugging information beyond that, yet. But it so=
unds a bit
> >> like NICs should behave the same as block devices. So if there is an e=
mulated
> >> device defined there will be an alternate paravirt interface for it an=
d after
> >> unplugging the emulated ones we end up with the pv ones.
> >> Is that something that can be seen with newer Xen versions, too (I am =
using 4.1.1)?
> >>
> > =

> > Hey,
> > =

> > Have you seen?: =

> > http://wiki.xen.org/xenwiki/XenLinuxPVonHVMdrivers
> > =

> > Especially the following note:
> > "NOTE! If you have "type=3Dioemu" specified for the "vif"-line, PVHVM d=
rivers WILL NOT work! Don't specify "type" parameter for the vif. (with typ=
e=3Dioemu the pvhvm nic in the VM will have mac address full of zeroes - an=
d thus won't work!)."
> > =

> > "type=3Dioemu" is not needed, at least with xm/xend toolstack both HVM =
and PVHVM guests work OK without it.
> > =

> > -- Pasi
> > =

> Thanks Pasi,
> =

> hmm, so it is documented actually and thus sort of expected. Still it is
> confusing. For one driver it does not make a difference to use the form o=
f an
> emulated device in the config, for the other it does. The xl stack works,=
 the xm
> stack does not.
> And then, ok this is probably a quite naive approach, it seemed to make s=
ense to
> go through the pain of always having potentially both interfaces available
> (emulated and pv) so in theory the same guest config can accommodate a gu=
est os
> supporting one or the other (or easily switch from one to the other). Oth=
erwise
> I would expect an emulated device only when I have hd? in the config and =
a pv
> device when I write xvd?.
> =


This works for both HVM and PVHVM (also mentioned on the wiki page):
vif =3D [ 'mac=3D00:16:5e:02:07:45, bridge=3Dxenbr0, model=3De1000' ]

So there's no need for "type=3Dioemu" option with xm/xend.

You can switch between HVM and PVHVM with:
xen_platform_pci=3D0|1

-- Pasi


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

From xen-devel-bounces@lists.xensource.com Fri Dec 02 10:43:43 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 10:43:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWQaP-0002Zo-7t; Fri, 02 Dec 2011 10:43:21 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RWQaN-0002ZN-Om
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 10:43:19 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1322822558!5533160!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTg0Mw==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14196 invoked from network); 2 Dec 2011 10:42:39 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Dec 2011 10:42:39 -0000
X-IronPort-AV: E=Sophos;i="4.71,282,1320624000"; 
   d="scan'208";a="9246728"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Dec 2011 10:42:03 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 2 Dec 2011
	10:42:03 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau =?ISO-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
Date: Fri, 2 Dec 2011 10:42:03 +0000
In-Reply-To: <CAPLaKK7mTUQRikLp6jKczw4RabaFycTA0LcQzm5P-wtmTHb+0A@mail.gmail.com>
References: <CAPLaKK5VC7YvMyvGM07f=ngOrbGbvLLDA1J8nqaxDsntux-bbQ@mail.gmail.com>
	<CAPLaKK6=L4wxWv6GqDpeV_OMukFgZSWM_pik6+jQ1tA7Ahsf3A@mail.gmail.com>
	<1322819865.31810.319.camel@zakaz.uk.xensource.com>
	<CAPLaKK5dO0QoxNiTy3aSR=_ArvLdLWpHsF=2Sw+iiXU5+8qQPQ@mail.gmail.com>
	<1322820883.31810.329.camel@zakaz.uk.xensource.com>
	<CAPLaKK7mTUQRikLp6jKczw4RabaFycTA0LcQzm5P-wtmTHb+0A@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322822523.29870.14.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] libxl: error when destroying domain on NetBSD
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gRnJpLCAyMDExLTEyLTAyIGF0IDEwOjI5ICswMDAwLCBSb2dlciBQYXUgTW9ubsOpIHdyb3Rl
Ogo+IDIwMTEvMTIvMiBJYW4gQ2FtcGJlbGwgPElhbi5DYW1wYmVsbEBjaXRyaXguY29tPjoKPiA+
IGxpYnhsX2Rlc3Ryb3lfZG9tYWluIHNob3VsZCBiZSBjYWxsZWQgd2l0aCBmb3JjZSA9IDEgaW4g
dGhlIG1haW5fZGVzdHJveQo+ID4gY2FzZSwgSSBzdXNwZWN0LiBEb2VzIHRoYXQgY2F1c2UgdGhl
IHNjcmlwdHMgdG8gYmUgcnVuPwo+IAo+IFdlbGwsIHdpdGggZm9yY2UgPSAxIGhvdHBsdWcgc2Ny
aXB0cyBhcmUgZXhlY3V0ZWQsIGJ1dCBkZXZpY2VzIGFyZQo+IHN0aWxsIGJ1c3kgYW5kIHRoZXkg
Y2Fubm90IGJlIGRpc2Nvbm5lY3RlZCAobWFpbmx5IHZuZCkuIEFsc28gY3Jhc2hlZAo+IHRoZSBz
ZXJ2ZXIsIGJ1dCB0aGF0J3MgTmV0QlNEIGJ1Z2d5IHZuZCBkcml2ZXIgcHJvYmxlbS4gU2VlaW5n
IHRoZQo+IGV4ZWN1dGlvbiBvcmRlciBpbiBsaWJ4bF9kb21haW5fZGVzdHJveSwgc2hvdWxkbid0
IHdlIGZpcnN0IGRlc3Ryb3kKPiB0aGUgZG9tYWluICh4Y19kb21haW5fZGVzdHJveSkgYW5kIHRo
ZW4gcmVtb3ZlIHRoZSBkZXZpY2VzPwoKSW4gdGhlIGZvcmNlIGNhc2UsIHllcywgSSBleHBlY3Qg
c28uCgpJbiB0aGUgbm9uLWZvcmNlIGNhc2UgeW91IHdhbnQgdG8gbGV0IHRoZSBndWVzdCBzaHV0
ZG93biBpdHMgZGV2aWNlcwpncmFjZWZ1bGx5IHNvIHlvdSB3b3VsZCBkbyBkZXZpY2VzIGZpcnN0
LgoKSG93ZXZlciBJJ20gbm90IGVudGlyZWx5IHN1cmUgdGhhdCBhIG5vbi1mb3JjZWQgbGlieGxf
ZG9tYWluX2Rlc3Ryb3kKbWFrZXMgbXVjaCBzZW5zZS4gVGhlIGNhbGxzaXRlcyBhcmU6CgogICAg
ICAqIGhhbmRsZV9kb21haW5fZGVhdGg6IFRoZSBndWVzdCBoYXMgYWxyZWFkeSBzaHV0ZG93biBh
dCB0aGlzCiAgICAgICAgcG9pbnQuIE5vdGhpbmcgZ3JhY2VmdWwgY2FuIGhhcHBlbi4KICAgICAg
KiBjcmVhdGVfZG9tYWluOiBXZSBoYXZlIGZhaWxlZCB0byBzdGFydCB0aGUgZ3Vlc3QsIG5vIGNo
YW5jZSBvZgogICAgICAgIGdyYWNlZnVsIHNodXRkb3duLgogICAgICAqIGRlc3Ryb3lfZG9tYWlu
OiBTZW1hbnRpY3MgYXJlIGV4cGxpY2l0bHkgdGhlIGZvcmNlIGNhc2UuCiAgICAgICogc2F2ZV9k
b21haW46IERvbWFpbiBoYXMgYWxyZWFkeSBzdXNwZW5kZWQuIFRoZXJlJ3Mgbm90aGluZyB3aGlj
aAogICAgICAgIGNhbiBiZSBkb25lIGdyYWNlZnVsbHkuCiAgICAgICogbWlncmF0ZV9kb21haW46
IEFscmVhZHkgZm9yY2VkLCBkb21haW4gaXMgZ29uZSBhbHJlYWR5LCBubwogICAgICAgIGNoYW5j
ZSBvZiBhIGdyYWNlZnVsIHNodXRkb3duLgogICAgICAqIG1pZ3JhdGVfcmVjZWl2ZTogQWxyZWFk
eSBmb3JjZWQsIHdlIGhhdmUgZmFpbGVkIHRvIHJlY2VpdmUgdGhlCiAgICAgICAgZG9tYWluLCBu
byBwb3NzaWJpbGl0eSBvZiBhIGdyYWNlZnVsIHNodXRkb3duLgogICAgICAqIGxpYnhsX2RvbWFp
bl9jcmVhdGUsIG9uIHRoZSBmYWlsdXJlIHBhdGggc28gbm8gbmVlZCBmb3IgYQogICAgICAgIGdy
YWNlZnVsIG9wdGlvbi4KICAgICAgKiBsaWJ4bF9fZGVzdHJveV9kZXZpY2VfbW9kZWwuIE1heWJl
IHRoaXMgc2hvdWxkIGJlIGRvaW5nIGEKICAgICAgICBncmFjZWZ1bCBzaHV0ZG93biBidXQgaW4g
dGhhdCBjYXNlIGl0IHNob3VsZCBlaXRoZXIgYmUgY2FsbGluZwogICAgICAgIGxpYnhsX2RvbWFp
bl9zaHV0ZG93biBvciB3cml0aW5nIHRoZSBxZW11LWRtIGNvbnRyb2wgbm9kZSBhbmQKICAgICAg
ICB3YWl0aW5nLCBhdCB3aGljaCBwb2ludCBhZnRlciBzb21lIHRpbWVvdXQgcGVyaGFwcyBhIGZv
cmNlZAogICAgICAgIHNodXRkb3duIHdvdWxkIGJlIGFwcHJvcHJpYXRlLgoKU28gaXQgc2VlbXMg
dG8gbWUgdGhhdCB0aGUgbm9uLWZvcmNlZCBvcHRpb24gaW4gbGlieGxfZG9tYWluX2Rlc3Ryb3kg
Y2FuCmJlIHJlbW92ZWQgYW5kIHdlIHNob3VsZCBqdXN0IHNob290IHRoZSBkb21haW4gYW5kIHRo
ZW4gZm9yY2libHkKdGVhcmRvd24gdGhlIGJhY2tlbmRzLCBydW5uaW5nIHNjcmlwdCBhcyBuZWNl
c3NhcnkuCgpUaGUgb25seSB3cmlua2xlIGlzIHRoZSBzdHViIGRldmljZS1tb2RlbCBjYXNlIGJ1
dCByZWFsbHkgdGhhdCdzIGFscmVhZHkKYSBzcGVjaWFsIGRvbWFpbiBhbmQgc2hvdWxkIGJlIHRy
ZWF0ZWQgYXMgc3VjaC4KCkRvZXMgdGhhdCBtYWtlIHNlbnNlIHRvIGFueW9uZSBlbHNlPwoKSWFu
LgoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1k
ZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbnNvdXJjZS5jb20KaHR0cDovL2xp
c3RzLnhlbnNvdXJjZS5jb20veGVuLWRldmVsCg==

From xen-devel-bounces@lists.xensource.com Fri Dec 02 10:43:43 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 10:43:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWQaP-0002Zo-7t; Fri, 02 Dec 2011 10:43:21 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RWQaN-0002ZN-Om
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 10:43:19 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1322822558!5533160!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTg0Mw==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14196 invoked from network); 2 Dec 2011 10:42:39 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Dec 2011 10:42:39 -0000
X-IronPort-AV: E=Sophos;i="4.71,282,1320624000"; 
   d="scan'208";a="9246728"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Dec 2011 10:42:03 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 2 Dec 2011
	10:42:03 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau =?ISO-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
Date: Fri, 2 Dec 2011 10:42:03 +0000
In-Reply-To: <CAPLaKK7mTUQRikLp6jKczw4RabaFycTA0LcQzm5P-wtmTHb+0A@mail.gmail.com>
References: <CAPLaKK5VC7YvMyvGM07f=ngOrbGbvLLDA1J8nqaxDsntux-bbQ@mail.gmail.com>
	<CAPLaKK6=L4wxWv6GqDpeV_OMukFgZSWM_pik6+jQ1tA7Ahsf3A@mail.gmail.com>
	<1322819865.31810.319.camel@zakaz.uk.xensource.com>
	<CAPLaKK5dO0QoxNiTy3aSR=_ArvLdLWpHsF=2Sw+iiXU5+8qQPQ@mail.gmail.com>
	<1322820883.31810.329.camel@zakaz.uk.xensource.com>
	<CAPLaKK7mTUQRikLp6jKczw4RabaFycTA0LcQzm5P-wtmTHb+0A@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322822523.29870.14.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] libxl: error when destroying domain on NetBSD
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gRnJpLCAyMDExLTEyLTAyIGF0IDEwOjI5ICswMDAwLCBSb2dlciBQYXUgTW9ubsOpIHdyb3Rl
Ogo+IDIwMTEvMTIvMiBJYW4gQ2FtcGJlbGwgPElhbi5DYW1wYmVsbEBjaXRyaXguY29tPjoKPiA+
IGxpYnhsX2Rlc3Ryb3lfZG9tYWluIHNob3VsZCBiZSBjYWxsZWQgd2l0aCBmb3JjZSA9IDEgaW4g
dGhlIG1haW5fZGVzdHJveQo+ID4gY2FzZSwgSSBzdXNwZWN0LiBEb2VzIHRoYXQgY2F1c2UgdGhl
IHNjcmlwdHMgdG8gYmUgcnVuPwo+IAo+IFdlbGwsIHdpdGggZm9yY2UgPSAxIGhvdHBsdWcgc2Ny
aXB0cyBhcmUgZXhlY3V0ZWQsIGJ1dCBkZXZpY2VzIGFyZQo+IHN0aWxsIGJ1c3kgYW5kIHRoZXkg
Y2Fubm90IGJlIGRpc2Nvbm5lY3RlZCAobWFpbmx5IHZuZCkuIEFsc28gY3Jhc2hlZAo+IHRoZSBz
ZXJ2ZXIsIGJ1dCB0aGF0J3MgTmV0QlNEIGJ1Z2d5IHZuZCBkcml2ZXIgcHJvYmxlbS4gU2VlaW5n
IHRoZQo+IGV4ZWN1dGlvbiBvcmRlciBpbiBsaWJ4bF9kb21haW5fZGVzdHJveSwgc2hvdWxkbid0
IHdlIGZpcnN0IGRlc3Ryb3kKPiB0aGUgZG9tYWluICh4Y19kb21haW5fZGVzdHJveSkgYW5kIHRo
ZW4gcmVtb3ZlIHRoZSBkZXZpY2VzPwoKSW4gdGhlIGZvcmNlIGNhc2UsIHllcywgSSBleHBlY3Qg
c28uCgpJbiB0aGUgbm9uLWZvcmNlIGNhc2UgeW91IHdhbnQgdG8gbGV0IHRoZSBndWVzdCBzaHV0
ZG93biBpdHMgZGV2aWNlcwpncmFjZWZ1bGx5IHNvIHlvdSB3b3VsZCBkbyBkZXZpY2VzIGZpcnN0
LgoKSG93ZXZlciBJJ20gbm90IGVudGlyZWx5IHN1cmUgdGhhdCBhIG5vbi1mb3JjZWQgbGlieGxf
ZG9tYWluX2Rlc3Ryb3kKbWFrZXMgbXVjaCBzZW5zZS4gVGhlIGNhbGxzaXRlcyBhcmU6CgogICAg
ICAqIGhhbmRsZV9kb21haW5fZGVhdGg6IFRoZSBndWVzdCBoYXMgYWxyZWFkeSBzaHV0ZG93biBh
dCB0aGlzCiAgICAgICAgcG9pbnQuIE5vdGhpbmcgZ3JhY2VmdWwgY2FuIGhhcHBlbi4KICAgICAg
KiBjcmVhdGVfZG9tYWluOiBXZSBoYXZlIGZhaWxlZCB0byBzdGFydCB0aGUgZ3Vlc3QsIG5vIGNo
YW5jZSBvZgogICAgICAgIGdyYWNlZnVsIHNodXRkb3duLgogICAgICAqIGRlc3Ryb3lfZG9tYWlu
OiBTZW1hbnRpY3MgYXJlIGV4cGxpY2l0bHkgdGhlIGZvcmNlIGNhc2UuCiAgICAgICogc2F2ZV9k
b21haW46IERvbWFpbiBoYXMgYWxyZWFkeSBzdXNwZW5kZWQuIFRoZXJlJ3Mgbm90aGluZyB3aGlj
aAogICAgICAgIGNhbiBiZSBkb25lIGdyYWNlZnVsbHkuCiAgICAgICogbWlncmF0ZV9kb21haW46
IEFscmVhZHkgZm9yY2VkLCBkb21haW4gaXMgZ29uZSBhbHJlYWR5LCBubwogICAgICAgIGNoYW5j
ZSBvZiBhIGdyYWNlZnVsIHNodXRkb3duLgogICAgICAqIG1pZ3JhdGVfcmVjZWl2ZTogQWxyZWFk
eSBmb3JjZWQsIHdlIGhhdmUgZmFpbGVkIHRvIHJlY2VpdmUgdGhlCiAgICAgICAgZG9tYWluLCBu
byBwb3NzaWJpbGl0eSBvZiBhIGdyYWNlZnVsIHNodXRkb3duLgogICAgICAqIGxpYnhsX2RvbWFp
bl9jcmVhdGUsIG9uIHRoZSBmYWlsdXJlIHBhdGggc28gbm8gbmVlZCBmb3IgYQogICAgICAgIGdy
YWNlZnVsIG9wdGlvbi4KICAgICAgKiBsaWJ4bF9fZGVzdHJveV9kZXZpY2VfbW9kZWwuIE1heWJl
IHRoaXMgc2hvdWxkIGJlIGRvaW5nIGEKICAgICAgICBncmFjZWZ1bCBzaHV0ZG93biBidXQgaW4g
dGhhdCBjYXNlIGl0IHNob3VsZCBlaXRoZXIgYmUgY2FsbGluZwogICAgICAgIGxpYnhsX2RvbWFp
bl9zaHV0ZG93biBvciB3cml0aW5nIHRoZSBxZW11LWRtIGNvbnRyb2wgbm9kZSBhbmQKICAgICAg
ICB3YWl0aW5nLCBhdCB3aGljaCBwb2ludCBhZnRlciBzb21lIHRpbWVvdXQgcGVyaGFwcyBhIGZv
cmNlZAogICAgICAgIHNodXRkb3duIHdvdWxkIGJlIGFwcHJvcHJpYXRlLgoKU28gaXQgc2VlbXMg
dG8gbWUgdGhhdCB0aGUgbm9uLWZvcmNlZCBvcHRpb24gaW4gbGlieGxfZG9tYWluX2Rlc3Ryb3kg
Y2FuCmJlIHJlbW92ZWQgYW5kIHdlIHNob3VsZCBqdXN0IHNob290IHRoZSBkb21haW4gYW5kIHRo
ZW4gZm9yY2libHkKdGVhcmRvd24gdGhlIGJhY2tlbmRzLCBydW5uaW5nIHNjcmlwdCBhcyBuZWNl
c3NhcnkuCgpUaGUgb25seSB3cmlua2xlIGlzIHRoZSBzdHViIGRldmljZS1tb2RlbCBjYXNlIGJ1
dCByZWFsbHkgdGhhdCdzIGFscmVhZHkKYSBzcGVjaWFsIGRvbWFpbiBhbmQgc2hvdWxkIGJlIHRy
ZWF0ZWQgYXMgc3VjaC4KCkRvZXMgdGhhdCBtYWtlIHNlbnNlIHRvIGFueW9uZSBlbHNlPwoKSWFu
LgoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1k
ZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbnNvdXJjZS5jb20KaHR0cDovL2xp
c3RzLnhlbnNvdXJjZS5jb20veGVuLWRldmVsCg==

From xen-devel-bounces@lists.xensource.com Fri Dec 02 10:49:25 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 10:49:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWQfz-0002sh-4c; Fri, 02 Dec 2011 10:49:07 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RWQfx-0002sR-EJ
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 10:49:05 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1322822903!3937080!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTg0Mw==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24391 invoked from network); 2 Dec 2011 10:48:23 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Dec 2011 10:48:23 -0000
X-IronPort-AV: E=Sophos;i="4.71,282,1320624000"; 
   d="scan'208";a="9246961"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Dec 2011 10:48:23 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 2 Dec 2011
	10:48:23 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 2 Dec 2011 10:48:22 +0000
In-Reply-To: <osstest-10231-mainreport@xen.org>
References: <osstest-10231-mainreport@xen.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322822903.29870.17.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Shriram Rajagopalan <rshriram@cs.ubc.ca>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Tim Deegan <tim@xen.org>, Andres Lagar-Cavilla <andres@lagarcavilla.org>
Subject: Re: [Xen-devel] [xen-unstable test] 10231: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2011-12-02 at 04:23 +0000, xen.org wrote:
> flight 10231 xen-unstable real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/10231/
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking:
>  test-amd64-amd64-xl-win       8 guest-saverestore         fail REGR. vs. 10201
>  test-amd64-i386-win-vcpus1    8 guest-saverestore         fail REGR. vs. 10201
>  test-amd64-i386-win           8 guest-saverestore         fail REGR. vs. 10201
>  test-i386-i386-win            8 guest-saverestore         fail REGR. vs. 10201
>  test-amd64-i386-xl-win-vcpus1  8 guest-saverestore        fail REGR. vs. 10201
>  test-i386-i386-xl-win         8 guest-saverestore         fail REGR. vs. 10201
>  test-amd64-amd64-win          8 guest-saverestore         fail REGR. vs. 10201

The xl ones are all failing with:
        2011-12-02 04:17:52 Z executing ssh ... root@10.80.249.56 xl save win.guest.osstest image
        Saving to image new xl format (info 0x0/0x0/625)
        libxl: error: libxl_exec.c:257:libxl__wait_for_offspring: Device Model not ready
        
while the xm ones are failing with:
        2011-12-02 03:22:20 Z executing ssh ... root@10.80.250.28 xm save win.guest.osstest image
        Usage: xm save [-c] <Domain> <CheckpointFile>
        
        Save a domain state to restore later.
          -c, --checkpoint               Leave domain running after creating        
                                         snapshot
        
        Error: Timed out waiting for device model action
        
In the xl case the test harness doesn't appear to have noticed the
failure. Might be bad error handling in xl or a bug in the harness. (my
money would be on the former).

I can't see anything in the qemu logs for the xm case but in one xl case
there is:
Error -22 while loading savevm file '/var/lib/xen/qemu-resume.5'

In the xm case xend logs say:
011-12-02 03:22:22 2185] WARNING (image:552) domain migrating-win.guest.osstest: device model failure: pid 4278: malfunctioning (closed sentinel), killed; see /var/log/xen/qemu-dm-win.guest.osstest.log 
[2011-12-02 03:22:32 2185] INFO (XendCheckpoint:423) xc: error: Suspend request failed: Internal error
[2011-12-02 03:22:32 2185] INFO (XendCheckpoint:423) xc: error: Domain appears not to have suspended: Internal error

but as I say nothing interesting appears in qemu-dm...log
[...]
> version targeted for testing:
>  xen                  3f815406feb2
> baseline version:
>  xen                  62ff6a318c5d

changeset:   24332:6b26fb894ca0
user:        Ian Jackson <Ian.Jackson@eu.citrix.com>
date:        Thu Dec 01 18:26:45 2011 +0000
summary:     Update QEMU_TAG

is in there but appears to represent a bunch of passthrough updates.
There also a bunch of Remus compression stuff which appears to touch
non-Remus suspend/resume code in libxc too, that's a plausible candidate
for the cause, I think

There is also a bunch of paging stuff, which I guess/hope is harmless if
paging is not in use? Tim, Andreas?.

Otherwise it appears to all be docs and emulator changes which all seem
less likely. There's some libxl stuff but you wouldn't expect that to
hurt xend...

I guess the bisector is on the case.

> 
> ------------------------------------------------------------
> People who touched revisions under test:
>   Adin Scannell <adin@scannell.ca>
>   Andres Lagar-Cavilla <andres@lagarcavilla.org>
>   Anthony PERARD <anthony.perard@citrix.com>
>   Brendan Cully <brendan@cs.ubc.ca>
>   Daniel De Graaf <dgdegra@tycho.nsa.gov>
>   Ian Campbell <ian.campbell@citrix.com>
>   Ian Jackson <ian.jackson.citrix.com>
>   Ian Jackson <ian.jackson@eu.citrix.com>
>   Jan Beulich <jbeulich@suse.com>
>   Jean Guyader <jean.guyader@eu.citrix.com>
>   Jonathan Davies <jonathan.davies@citrix.com>
>   juergen.gross@ts.fujitsu.com
>   Keir Fraser <keir@xen.org>
>   Liu, Jinsong <jinsong.liu@intel.com>
>   Olaf Hering <olaf@aepfle.de>
>   Philipp Hahn <hahn@univention.de>
>   Shriram Rajagopalan <rshriram@cs.ubc.ca>
>   Stefano Stabellini <stefano.stabellini@eu.citrix.com>
>   Tim Deegan <tim@xen.org>
> ------------------------------------------------------------
> 
> jobs:
>  build-amd64                                                  pass    
>  build-i386                                                   pass    
>  build-amd64-oldkern                                          pass    
>  build-i386-oldkern                                           pass    
>  build-amd64-pvops                                            pass    
>  build-i386-pvops                                             pass    
>  test-amd64-amd64-xl                                          pass    
>  test-amd64-i386-xl                                           pass    
>  test-i386-i386-xl                                            pass    
>  test-amd64-i386-rhel6hvm-amd                                 fail    
>  test-amd64-amd64-xl-win7-amd64                               fail    
>  test-amd64-i386-xl-win7-amd64                                fail    
>  test-amd64-i386-xl-credit2                                   pass    
>  test-amd64-amd64-xl-pcipt-intel                              fail    
>  test-amd64-i386-rhel6hvm-intel                               fail    
>  test-amd64-i386-xl-multivcpu                                 pass    
>  test-amd64-amd64-pair                                        pass    
>  test-amd64-i386-pair                                         pass    
>  test-i386-i386-pair                                          pass    
>  test-amd64-amd64-pv                                          pass    
>  test-amd64-i386-pv                                           pass    
>  test-i386-i386-pv                                            pass    
>  test-amd64-amd64-xl-sedf                                     pass    
>  test-amd64-i386-win-vcpus1                                   fail    
>  test-amd64-i386-xl-win-vcpus1                                fail    
>  test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
>  test-amd64-amd64-win                                         fail    
>  test-amd64-i386-win                                          fail    
>  test-i386-i386-win                                           fail    
>  test-amd64-amd64-xl-win                                      fail    
>  test-i386-i386-xl-win                                        fail    
>  test-amd64-i386-xend-winxpsp3                                fail    
>  test-amd64-amd64-xl-winxpsp3                                 fail    
>  test-i386-i386-xl-winxpsp3                                   fail    
> 
> 
> ------------------------------------------------------------
> sg-report-flight on woking.cam.xci-test.com
> logs: /home/xc_osstest/logs
> images: /home/xc_osstest/images
> 
> Logs, config files, etc. are available at
>     http://www.chiark.greenend.org.uk/~xensrcts/logs
> 
> Test harness code can be found at
>     http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary
> 
> 
> Not pushing.
> 
> (No revision log; it would be 1073 lines long.)
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel




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

From xen-devel-bounces@lists.xensource.com Fri Dec 02 10:49:25 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 10:49:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWQfz-0002sh-4c; Fri, 02 Dec 2011 10:49:07 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RWQfx-0002sR-EJ
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 10:49:05 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1322822903!3937080!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTg0Mw==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24391 invoked from network); 2 Dec 2011 10:48:23 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Dec 2011 10:48:23 -0000
X-IronPort-AV: E=Sophos;i="4.71,282,1320624000"; 
   d="scan'208";a="9246961"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Dec 2011 10:48:23 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 2 Dec 2011
	10:48:23 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 2 Dec 2011 10:48:22 +0000
In-Reply-To: <osstest-10231-mainreport@xen.org>
References: <osstest-10231-mainreport@xen.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322822903.29870.17.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Shriram Rajagopalan <rshriram@cs.ubc.ca>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Tim Deegan <tim@xen.org>, Andres Lagar-Cavilla <andres@lagarcavilla.org>
Subject: Re: [Xen-devel] [xen-unstable test] 10231: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2011-12-02 at 04:23 +0000, xen.org wrote:
> flight 10231 xen-unstable real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/10231/
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking:
>  test-amd64-amd64-xl-win       8 guest-saverestore         fail REGR. vs. 10201
>  test-amd64-i386-win-vcpus1    8 guest-saverestore         fail REGR. vs. 10201
>  test-amd64-i386-win           8 guest-saverestore         fail REGR. vs. 10201
>  test-i386-i386-win            8 guest-saverestore         fail REGR. vs. 10201
>  test-amd64-i386-xl-win-vcpus1  8 guest-saverestore        fail REGR. vs. 10201
>  test-i386-i386-xl-win         8 guest-saverestore         fail REGR. vs. 10201
>  test-amd64-amd64-win          8 guest-saverestore         fail REGR. vs. 10201

The xl ones are all failing with:
        2011-12-02 04:17:52 Z executing ssh ... root@10.80.249.56 xl save win.guest.osstest image
        Saving to image new xl format (info 0x0/0x0/625)
        libxl: error: libxl_exec.c:257:libxl__wait_for_offspring: Device Model not ready
        
while the xm ones are failing with:
        2011-12-02 03:22:20 Z executing ssh ... root@10.80.250.28 xm save win.guest.osstest image
        Usage: xm save [-c] <Domain> <CheckpointFile>
        
        Save a domain state to restore later.
          -c, --checkpoint               Leave domain running after creating        
                                         snapshot
        
        Error: Timed out waiting for device model action
        
In the xl case the test harness doesn't appear to have noticed the
failure. Might be bad error handling in xl or a bug in the harness. (my
money would be on the former).

I can't see anything in the qemu logs for the xm case but in one xl case
there is:
Error -22 while loading savevm file '/var/lib/xen/qemu-resume.5'

In the xm case xend logs say:
011-12-02 03:22:22 2185] WARNING (image:552) domain migrating-win.guest.osstest: device model failure: pid 4278: malfunctioning (closed sentinel), killed; see /var/log/xen/qemu-dm-win.guest.osstest.log 
[2011-12-02 03:22:32 2185] INFO (XendCheckpoint:423) xc: error: Suspend request failed: Internal error
[2011-12-02 03:22:32 2185] INFO (XendCheckpoint:423) xc: error: Domain appears not to have suspended: Internal error

but as I say nothing interesting appears in qemu-dm...log
[...]
> version targeted for testing:
>  xen                  3f815406feb2
> baseline version:
>  xen                  62ff6a318c5d

changeset:   24332:6b26fb894ca0
user:        Ian Jackson <Ian.Jackson@eu.citrix.com>
date:        Thu Dec 01 18:26:45 2011 +0000
summary:     Update QEMU_TAG

is in there but appears to represent a bunch of passthrough updates.
There also a bunch of Remus compression stuff which appears to touch
non-Remus suspend/resume code in libxc too, that's a plausible candidate
for the cause, I think

There is also a bunch of paging stuff, which I guess/hope is harmless if
paging is not in use? Tim, Andreas?.

Otherwise it appears to all be docs and emulator changes which all seem
less likely. There's some libxl stuff but you wouldn't expect that to
hurt xend...

I guess the bisector is on the case.

> 
> ------------------------------------------------------------
> People who touched revisions under test:
>   Adin Scannell <adin@scannell.ca>
>   Andres Lagar-Cavilla <andres@lagarcavilla.org>
>   Anthony PERARD <anthony.perard@citrix.com>
>   Brendan Cully <brendan@cs.ubc.ca>
>   Daniel De Graaf <dgdegra@tycho.nsa.gov>
>   Ian Campbell <ian.campbell@citrix.com>
>   Ian Jackson <ian.jackson.citrix.com>
>   Ian Jackson <ian.jackson@eu.citrix.com>
>   Jan Beulich <jbeulich@suse.com>
>   Jean Guyader <jean.guyader@eu.citrix.com>
>   Jonathan Davies <jonathan.davies@citrix.com>
>   juergen.gross@ts.fujitsu.com
>   Keir Fraser <keir@xen.org>
>   Liu, Jinsong <jinsong.liu@intel.com>
>   Olaf Hering <olaf@aepfle.de>
>   Philipp Hahn <hahn@univention.de>
>   Shriram Rajagopalan <rshriram@cs.ubc.ca>
>   Stefano Stabellini <stefano.stabellini@eu.citrix.com>
>   Tim Deegan <tim@xen.org>
> ------------------------------------------------------------
> 
> jobs:
>  build-amd64                                                  pass    
>  build-i386                                                   pass    
>  build-amd64-oldkern                                          pass    
>  build-i386-oldkern                                           pass    
>  build-amd64-pvops                                            pass    
>  build-i386-pvops                                             pass    
>  test-amd64-amd64-xl                                          pass    
>  test-amd64-i386-xl                                           pass    
>  test-i386-i386-xl                                            pass    
>  test-amd64-i386-rhel6hvm-amd                                 fail    
>  test-amd64-amd64-xl-win7-amd64                               fail    
>  test-amd64-i386-xl-win7-amd64                                fail    
>  test-amd64-i386-xl-credit2                                   pass    
>  test-amd64-amd64-xl-pcipt-intel                              fail    
>  test-amd64-i386-rhel6hvm-intel                               fail    
>  test-amd64-i386-xl-multivcpu                                 pass    
>  test-amd64-amd64-pair                                        pass    
>  test-amd64-i386-pair                                         pass    
>  test-i386-i386-pair                                          pass    
>  test-amd64-amd64-pv                                          pass    
>  test-amd64-i386-pv                                           pass    
>  test-i386-i386-pv                                            pass    
>  test-amd64-amd64-xl-sedf                                     pass    
>  test-amd64-i386-win-vcpus1                                   fail    
>  test-amd64-i386-xl-win-vcpus1                                fail    
>  test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
>  test-amd64-amd64-win                                         fail    
>  test-amd64-i386-win                                          fail    
>  test-i386-i386-win                                           fail    
>  test-amd64-amd64-xl-win                                      fail    
>  test-i386-i386-xl-win                                        fail    
>  test-amd64-i386-xend-winxpsp3                                fail    
>  test-amd64-amd64-xl-winxpsp3                                 fail    
>  test-i386-i386-xl-winxpsp3                                   fail    
> 
> 
> ------------------------------------------------------------
> sg-report-flight on woking.cam.xci-test.com
> logs: /home/xc_osstest/logs
> images: /home/xc_osstest/images
> 
> Logs, config files, etc. are available at
>     http://www.chiark.greenend.org.uk/~xensrcts/logs
> 
> Test harness code can be found at
>     http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary
> 
> 
> Not pushing.
> 
> (No revision log; it would be 1073 lines long.)
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel




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

From xen-devel-bounces@lists.xensource.com Fri Dec 02 11:14:10 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 11:14:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWR3l-0003l1-K9; Fri, 02 Dec 2011 11:13:41 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RWR3k-0003ki-8n
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 11:13:40 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1322824378!3930804!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQyOTg=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16854 invoked from network); 2 Dec 2011 11:12:58 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-3.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 2 Dec 2011 11:12:58 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 02 Dec 2011 11:14:31 +0000
Message-Id: <4ED8C0C802000078000650B6@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 02 Dec 2011 11:12:56 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tim Deegan" <tim@xen.org>
References: <patchbomb.1322598097@xdev.gridcentric.ca>
	<6626add0fef6a258388a.1322598103@xdev.gridcentric.ca>
	<4ED89A390200007800064FFE@nat28.tlf.novell.com>
	<20111202103318.GA86219@ocelot.phlegethon.org>
In-Reply-To: <20111202103318.GA86219@ocelot.phlegethon.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com, ian.campbell@citrix.com,
	andres@gridcentric.ca, keir.xen@gmail.com,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>,
	ian.jackson@citrix.com, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH] Re: [PATCH 6 of 9] x86/mm: Rework stale p2m
 auditing
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 02.12.11 at 11:33, Tim Deegan <tim@xen.org> wrote:
> At 08:28 +0000 on 02 Dec (1322814505), Jan Beulich wrote:
>> It uncovered a problem
>> in 22356:cbb6b4b17024 (the code meanwhile moved elsewhere): In a
>> 32-bit build,
>> 
>>         if ( gfn == 0x55555555 || gfn == 0x5555555555555555 )
>> 
>> causes (at least with some compiler versions, didn't check tonight's
>> stage tester results yet) a compiler warning 
> 
> I don't think these debug values are serving any purpose.  How about we
> just get rid of them? 
> 
> x86/mm: remove 0x55 debug pattern from M2P table
> 
> It's not really any more useful than explicitly setting new M2P entries
> to the invalid value.

That's fine by me - I don't think I ever found a need to distinguish
never touched from invalidated entries.

Jan


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

From xen-devel-bounces@lists.xensource.com Fri Dec 02 11:14:10 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 11:14:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWR3l-0003l1-K9; Fri, 02 Dec 2011 11:13:41 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RWR3k-0003ki-8n
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 11:13:40 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1322824378!3930804!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQyOTg=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16854 invoked from network); 2 Dec 2011 11:12:58 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-3.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 2 Dec 2011 11:12:58 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 02 Dec 2011 11:14:31 +0000
Message-Id: <4ED8C0C802000078000650B6@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 02 Dec 2011 11:12:56 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tim Deegan" <tim@xen.org>
References: <patchbomb.1322598097@xdev.gridcentric.ca>
	<6626add0fef6a258388a.1322598103@xdev.gridcentric.ca>
	<4ED89A390200007800064FFE@nat28.tlf.novell.com>
	<20111202103318.GA86219@ocelot.phlegethon.org>
In-Reply-To: <20111202103318.GA86219@ocelot.phlegethon.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com, ian.campbell@citrix.com,
	andres@gridcentric.ca, keir.xen@gmail.com,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>,
	ian.jackson@citrix.com, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH] Re: [PATCH 6 of 9] x86/mm: Rework stale p2m
 auditing
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 02.12.11 at 11:33, Tim Deegan <tim@xen.org> wrote:
> At 08:28 +0000 on 02 Dec (1322814505), Jan Beulich wrote:
>> It uncovered a problem
>> in 22356:cbb6b4b17024 (the code meanwhile moved elsewhere): In a
>> 32-bit build,
>> 
>>         if ( gfn == 0x55555555 || gfn == 0x5555555555555555 )
>> 
>> causes (at least with some compiler versions, didn't check tonight's
>> stage tester results yet) a compiler warning 
> 
> I don't think these debug values are serving any purpose.  How about we
> just get rid of them? 
> 
> x86/mm: remove 0x55 debug pattern from M2P table
> 
> It's not really any more useful than explicitly setting new M2P entries
> to the invalid value.

That's fine by me - I don't think I ever found a need to distinguish
never touched from invalidated entries.

Jan


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

From xen-devel-bounces@lists.xensource.com Fri Dec 02 11:53:03 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 11: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.xensource.com>)
	id 1RWRfP-0004YF-FI; Fri, 02 Dec 2011 11:52:35 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RWRfO-0004YA-F5
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 11:52:34 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1322826711!3947669!1
X-Originating-IP: [209.85.161.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15622 invoked from network); 2 Dec 2011 11:51:53 -0000
Received: from mail-gx0-f171.google.com (HELO mail-gx0-f171.google.com)
	(209.85.161.171)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Dec 2011 11:51:53 -0000
Received: by ggnr4 with SMTP id r4so20978665ggn.30
	for <xen-devel@lists.xensource.com>;
	Fri, 02 Dec 2011 03:51:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=duAuqhmXap2An4E5ICTa7iU7jRSroWf8eJh1lvcvLIo=;
	b=ELKeKBHpXSi2IaAVNtjuQJguJV6+e+geuAHfEl+g1jhr1zGhg0UZuyDpIVHHDXZ1Ef
	qLg/8K1hjF6w+AlRPov2PCICXOjFMQMvnVz1JGGLixMzdPgF6aVXYbkQKyWU5yDmuzGl
	sStrplVkif5CKulmyoASN0xFxxMGsrQjkLP/4=
MIME-Version: 1.0
Received: by 10.68.2.138 with SMTP id 10mr13810502pbu.55.1322826710850; Fri,
	02 Dec 2011 03:51:50 -0800 (PST)
Received: by 10.142.212.12 with HTTP; Fri, 2 Dec 2011 03:51:50 -0800 (PST)
In-Reply-To: <1322822523.29870.14.camel@zakaz.uk.xensource.com>
References: <CAPLaKK5VC7YvMyvGM07f=ngOrbGbvLLDA1J8nqaxDsntux-bbQ@mail.gmail.com>
	<CAPLaKK6=L4wxWv6GqDpeV_OMukFgZSWM_pik6+jQ1tA7Ahsf3A@mail.gmail.com>
	<1322819865.31810.319.camel@zakaz.uk.xensource.com>
	<CAPLaKK5dO0QoxNiTy3aSR=_ArvLdLWpHsF=2Sw+iiXU5+8qQPQ@mail.gmail.com>
	<1322820883.31810.329.camel@zakaz.uk.xensource.com>
	<CAPLaKK7mTUQRikLp6jKczw4RabaFycTA0LcQzm5P-wtmTHb+0A@mail.gmail.com>
	<1322822523.29870.14.camel@zakaz.uk.xensource.com>
Date: Fri, 2 Dec 2011 12:51:50 +0100
X-Google-Sender-Auth: 9WJZEdzuaWAI_-6m2XefETOAAZI
Message-ID: <CAPLaKK5X=qZ2W06v1meZe_q9twn_yZb0nPAT89ER=T1AbG6s_Q@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] libxl: error when destroying domain on NetBSD
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

MjAxMS8xMi8yIElhbiBDYW1wYmVsbCA8SWFuLkNhbXBiZWxsQGNpdHJpeC5jb20+Ogo+IE9uIEZy
aSwgMjAxMS0xMi0wMiBhdCAxMDoyOSArMDAwMCwgUm9nZXIgUGF1IE1vbm7DqSB3cm90ZToKPj4g
MjAxMS8xMi8yIElhbiBDYW1wYmVsbCA8SWFuLkNhbXBiZWxsQGNpdHJpeC5jb20+Ogo+PiA+IGxp
YnhsX2Rlc3Ryb3lfZG9tYWluIHNob3VsZCBiZSBjYWxsZWQgd2l0aCBmb3JjZSA9IDEgaW4gdGhl
IG1haW5fZGVzdHJveQo+PiA+IGNhc2UsIEkgc3VzcGVjdC4gRG9lcyB0aGF0IGNhdXNlIHRoZSBz
Y3JpcHRzIHRvIGJlIHJ1bj8KPj4KPj4gV2VsbCwgd2l0aCBmb3JjZSA9IDEgaG90cGx1ZyBzY3Jp
cHRzIGFyZSBleGVjdXRlZCwgYnV0IGRldmljZXMgYXJlCj4+IHN0aWxsIGJ1c3kgYW5kIHRoZXkg
Y2Fubm90IGJlIGRpc2Nvbm5lY3RlZCAobWFpbmx5IHZuZCkuIEFsc28gY3Jhc2hlZAo+PiB0aGUg
c2VydmVyLCBidXQgdGhhdCdzIE5ldEJTRCBidWdneSB2bmQgZHJpdmVyIHByb2JsZW0uIFNlZWlu
ZyB0aGUKPj4gZXhlY3V0aW9uIG9yZGVyIGluIGxpYnhsX2RvbWFpbl9kZXN0cm95LCBzaG91bGRu
J3Qgd2UgZmlyc3QgZGVzdHJveQo+PiB0aGUgZG9tYWluICh4Y19kb21haW5fZGVzdHJveSkgYW5k
IHRoZW4gcmVtb3ZlIHRoZSBkZXZpY2VzPwo+Cj4gSW4gdGhlIGZvcmNlIGNhc2UsIHllcywgSSBl
eHBlY3Qgc28uCj4KPiBJbiB0aGUgbm9uLWZvcmNlIGNhc2UgeW91IHdhbnQgdG8gbGV0IHRoZSBn
dWVzdCBzaHV0ZG93biBpdHMgZGV2aWNlcwo+IGdyYWNlZnVsbHkgc28geW91IHdvdWxkIGRvIGRl
dmljZXMgZmlyc3QuCj4KPiBIb3dldmVyIEknbSBub3QgZW50aXJlbHkgc3VyZSB0aGF0IGEgbm9u
LWZvcmNlZCBsaWJ4bF9kb21haW5fZGVzdHJveQo+IG1ha2VzIG11Y2ggc2Vuc2UuIFRoZSBjYWxs
c2l0ZXMgYXJlOgo+Cj4gwqAgwqAgwqAqIGhhbmRsZV9kb21haW5fZGVhdGg6IFRoZSBndWVzdCBo
YXMgYWxyZWFkeSBzaHV0ZG93biBhdCB0aGlzCj4gwqAgwqAgwqAgwqBwb2ludC4gTm90aGluZyBn
cmFjZWZ1bCBjYW4gaGFwcGVuLgo+IMKgIMKgIMKgKiBjcmVhdGVfZG9tYWluOiBXZSBoYXZlIGZh
aWxlZCB0byBzdGFydCB0aGUgZ3Vlc3QsIG5vIGNoYW5jZSBvZgo+IMKgIMKgIMKgIMKgZ3JhY2Vm
dWwgc2h1dGRvd24uCj4gwqAgwqAgwqAqIGRlc3Ryb3lfZG9tYWluOiBTZW1hbnRpY3MgYXJlIGV4
cGxpY2l0bHkgdGhlIGZvcmNlIGNhc2UuCj4gwqAgwqAgwqAqIHNhdmVfZG9tYWluOiBEb21haW4g
aGFzIGFscmVhZHkgc3VzcGVuZGVkLiBUaGVyZSdzIG5vdGhpbmcgd2hpY2gKPiDCoCDCoCDCoCDC
oGNhbiBiZSBkb25lIGdyYWNlZnVsbHkuCj4gwqAgwqAgwqAqIG1pZ3JhdGVfZG9tYWluOiBBbHJl
YWR5IGZvcmNlZCwgZG9tYWluIGlzIGdvbmUgYWxyZWFkeSwgbm8KPiDCoCDCoCDCoCDCoGNoYW5j
ZSBvZiBhIGdyYWNlZnVsIHNodXRkb3duLgo+IMKgIMKgIMKgKiBtaWdyYXRlX3JlY2VpdmU6IEFs
cmVhZHkgZm9yY2VkLCB3ZSBoYXZlIGZhaWxlZCB0byByZWNlaXZlIHRoZQo+IMKgIMKgIMKgIMKg
ZG9tYWluLCBubyBwb3NzaWJpbGl0eSBvZiBhIGdyYWNlZnVsIHNodXRkb3duLgo+IMKgIMKgIMKg
KiBsaWJ4bF9kb21haW5fY3JlYXRlLCBvbiB0aGUgZmFpbHVyZSBwYXRoIHNvIG5vIG5lZWQgZm9y
IGEKPiDCoCDCoCDCoCDCoGdyYWNlZnVsIG9wdGlvbi4KPiDCoCDCoCDCoCogbGlieGxfX2Rlc3Ry
b3lfZGV2aWNlX21vZGVsLiBNYXliZSB0aGlzIHNob3VsZCBiZSBkb2luZyBhCj4gwqAgwqAgwqAg
wqBncmFjZWZ1bCBzaHV0ZG93biBidXQgaW4gdGhhdCBjYXNlIGl0IHNob3VsZCBlaXRoZXIgYmUg
Y2FsbGluZwo+IMKgIMKgIMKgIMKgbGlieGxfZG9tYWluX3NodXRkb3duIG9yIHdyaXRpbmcgdGhl
IHFlbXUtZG0gY29udHJvbCBub2RlIGFuZAo+IMKgIMKgIMKgIMKgd2FpdGluZywgYXQgd2hpY2gg
cG9pbnQgYWZ0ZXIgc29tZSB0aW1lb3V0IHBlcmhhcHMgYSBmb3JjZWQKPiDCoCDCoCDCoCDCoHNo
dXRkb3duIHdvdWxkIGJlIGFwcHJvcHJpYXRlLgo+Cj4gU28gaXQgc2VlbXMgdG8gbWUgdGhhdCB0
aGUgbm9uLWZvcmNlZCBvcHRpb24gaW4gbGlieGxfZG9tYWluX2Rlc3Ryb3kgY2FuCj4gYmUgcmVt
b3ZlZCBhbmQgd2Ugc2hvdWxkIGp1c3Qgc2hvb3QgdGhlIGRvbWFpbiBhbmQgdGhlbiBmb3JjaWJs
eQo+IHRlYXJkb3duIHRoZSBiYWNrZW5kcywgcnVubmluZyBzY3JpcHQgYXMgbmVjZXNzYXJ5Lgo+
Cj4gVGhlIG9ubHkgd3JpbmtsZSBpcyB0aGUgc3R1YiBkZXZpY2UtbW9kZWwgY2FzZSBidXQgcmVh
bGx5IHRoYXQncyBhbHJlYWR5Cj4gYSBzcGVjaWFsIGRvbWFpbiBhbmQgc2hvdWxkIGJlIHRyZWF0
ZWQgYXMgc3VjaC4KPgo+IERvZXMgdGhhdCBtYWtlIHNlbnNlIHRvIGFueW9uZSBlbHNlPwo+Cj4g
SWFuLgo+CgpXZWxsLCBJIHRoaW5rIEkgZm91bmQgdGhlIHVuZGVybHlpbmcgcHJvYmxlbSB0aGF0
IHdhcyBwcmV2ZW50aW5nCk5ldEJTRCBmcm9tIGNvcnJlY3RseSBkZXRhY2hpbmcgdm5kIGRldmlj
ZXMgd2hlbiBkZXN0cm95aW5nIGEgZG9tYWluLAp0aGUgZnJvbnRlbmQgc3RhdGUgbmVlZHMgdG8g
YmUgbWFudWFsbHkgc2V0IHRvIDYKKC9sb2NhbC9kb21haW4vPGRvbWlkPi9kZXZpY2UvdmJkLzxk
ZXZpZD4vc3RhdGUgYW5kIHRoZSBzYW1lIGZvciB2aWYKdG8gYmUgbW9yZSAiY29ycmVjdCIpIHNv
IHRoZSBrZXJuZWwgY2xvc2VzIHRoZSBkZXZpY2UgYW5kIGl0IGNhbiB0aGVuCmJlIGNvcnJlY3Rs
eSB1bm1vdW50ZWQuCgoKSSB3aWxsIHByZXBhcmUgYSBwYXRjaCAob3IgYSBzZXJpZXMpIHRvIGFk
cmVzcyB0aGlzLCBhbmQgY2hhbmdlCmxpYnhsX2RvbWFpbl9kZXN0cm95IHRvIHVzZSB0aGUgZm9y
Y2Ugd2hlbiBjYWxsZWQuCgpUaGFua3MsIFJvZ2VyLgoKX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxA
bGlzdHMueGVuc291cmNlLmNvbQpodHRwOi8vbGlzdHMueGVuc291cmNlLmNvbS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Fri Dec 02 11:53:03 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 11: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.xensource.com>)
	id 1RWRfP-0004YF-FI; Fri, 02 Dec 2011 11:52:35 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RWRfO-0004YA-F5
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 11:52:34 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1322826711!3947669!1
X-Originating-IP: [209.85.161.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15622 invoked from network); 2 Dec 2011 11:51:53 -0000
Received: from mail-gx0-f171.google.com (HELO mail-gx0-f171.google.com)
	(209.85.161.171)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Dec 2011 11:51:53 -0000
Received: by ggnr4 with SMTP id r4so20978665ggn.30
	for <xen-devel@lists.xensource.com>;
	Fri, 02 Dec 2011 03:51:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=duAuqhmXap2An4E5ICTa7iU7jRSroWf8eJh1lvcvLIo=;
	b=ELKeKBHpXSi2IaAVNtjuQJguJV6+e+geuAHfEl+g1jhr1zGhg0UZuyDpIVHHDXZ1Ef
	qLg/8K1hjF6w+AlRPov2PCICXOjFMQMvnVz1JGGLixMzdPgF6aVXYbkQKyWU5yDmuzGl
	sStrplVkif5CKulmyoASN0xFxxMGsrQjkLP/4=
MIME-Version: 1.0
Received: by 10.68.2.138 with SMTP id 10mr13810502pbu.55.1322826710850; Fri,
	02 Dec 2011 03:51:50 -0800 (PST)
Received: by 10.142.212.12 with HTTP; Fri, 2 Dec 2011 03:51:50 -0800 (PST)
In-Reply-To: <1322822523.29870.14.camel@zakaz.uk.xensource.com>
References: <CAPLaKK5VC7YvMyvGM07f=ngOrbGbvLLDA1J8nqaxDsntux-bbQ@mail.gmail.com>
	<CAPLaKK6=L4wxWv6GqDpeV_OMukFgZSWM_pik6+jQ1tA7Ahsf3A@mail.gmail.com>
	<1322819865.31810.319.camel@zakaz.uk.xensource.com>
	<CAPLaKK5dO0QoxNiTy3aSR=_ArvLdLWpHsF=2Sw+iiXU5+8qQPQ@mail.gmail.com>
	<1322820883.31810.329.camel@zakaz.uk.xensource.com>
	<CAPLaKK7mTUQRikLp6jKczw4RabaFycTA0LcQzm5P-wtmTHb+0A@mail.gmail.com>
	<1322822523.29870.14.camel@zakaz.uk.xensource.com>
Date: Fri, 2 Dec 2011 12:51:50 +0100
X-Google-Sender-Auth: 9WJZEdzuaWAI_-6m2XefETOAAZI
Message-ID: <CAPLaKK5X=qZ2W06v1meZe_q9twn_yZb0nPAT89ER=T1AbG6s_Q@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] libxl: error when destroying domain on NetBSD
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

MjAxMS8xMi8yIElhbiBDYW1wYmVsbCA8SWFuLkNhbXBiZWxsQGNpdHJpeC5jb20+Ogo+IE9uIEZy
aSwgMjAxMS0xMi0wMiBhdCAxMDoyOSArMDAwMCwgUm9nZXIgUGF1IE1vbm7DqSB3cm90ZToKPj4g
MjAxMS8xMi8yIElhbiBDYW1wYmVsbCA8SWFuLkNhbXBiZWxsQGNpdHJpeC5jb20+Ogo+PiA+IGxp
YnhsX2Rlc3Ryb3lfZG9tYWluIHNob3VsZCBiZSBjYWxsZWQgd2l0aCBmb3JjZSA9IDEgaW4gdGhl
IG1haW5fZGVzdHJveQo+PiA+IGNhc2UsIEkgc3VzcGVjdC4gRG9lcyB0aGF0IGNhdXNlIHRoZSBz
Y3JpcHRzIHRvIGJlIHJ1bj8KPj4KPj4gV2VsbCwgd2l0aCBmb3JjZSA9IDEgaG90cGx1ZyBzY3Jp
cHRzIGFyZSBleGVjdXRlZCwgYnV0IGRldmljZXMgYXJlCj4+IHN0aWxsIGJ1c3kgYW5kIHRoZXkg
Y2Fubm90IGJlIGRpc2Nvbm5lY3RlZCAobWFpbmx5IHZuZCkuIEFsc28gY3Jhc2hlZAo+PiB0aGUg
c2VydmVyLCBidXQgdGhhdCdzIE5ldEJTRCBidWdneSB2bmQgZHJpdmVyIHByb2JsZW0uIFNlZWlu
ZyB0aGUKPj4gZXhlY3V0aW9uIG9yZGVyIGluIGxpYnhsX2RvbWFpbl9kZXN0cm95LCBzaG91bGRu
J3Qgd2UgZmlyc3QgZGVzdHJveQo+PiB0aGUgZG9tYWluICh4Y19kb21haW5fZGVzdHJveSkgYW5k
IHRoZW4gcmVtb3ZlIHRoZSBkZXZpY2VzPwo+Cj4gSW4gdGhlIGZvcmNlIGNhc2UsIHllcywgSSBl
eHBlY3Qgc28uCj4KPiBJbiB0aGUgbm9uLWZvcmNlIGNhc2UgeW91IHdhbnQgdG8gbGV0IHRoZSBn
dWVzdCBzaHV0ZG93biBpdHMgZGV2aWNlcwo+IGdyYWNlZnVsbHkgc28geW91IHdvdWxkIGRvIGRl
dmljZXMgZmlyc3QuCj4KPiBIb3dldmVyIEknbSBub3QgZW50aXJlbHkgc3VyZSB0aGF0IGEgbm9u
LWZvcmNlZCBsaWJ4bF9kb21haW5fZGVzdHJveQo+IG1ha2VzIG11Y2ggc2Vuc2UuIFRoZSBjYWxs
c2l0ZXMgYXJlOgo+Cj4gwqAgwqAgwqAqIGhhbmRsZV9kb21haW5fZGVhdGg6IFRoZSBndWVzdCBo
YXMgYWxyZWFkeSBzaHV0ZG93biBhdCB0aGlzCj4gwqAgwqAgwqAgwqBwb2ludC4gTm90aGluZyBn
cmFjZWZ1bCBjYW4gaGFwcGVuLgo+IMKgIMKgIMKgKiBjcmVhdGVfZG9tYWluOiBXZSBoYXZlIGZh
aWxlZCB0byBzdGFydCB0aGUgZ3Vlc3QsIG5vIGNoYW5jZSBvZgo+IMKgIMKgIMKgIMKgZ3JhY2Vm
dWwgc2h1dGRvd24uCj4gwqAgwqAgwqAqIGRlc3Ryb3lfZG9tYWluOiBTZW1hbnRpY3MgYXJlIGV4
cGxpY2l0bHkgdGhlIGZvcmNlIGNhc2UuCj4gwqAgwqAgwqAqIHNhdmVfZG9tYWluOiBEb21haW4g
aGFzIGFscmVhZHkgc3VzcGVuZGVkLiBUaGVyZSdzIG5vdGhpbmcgd2hpY2gKPiDCoCDCoCDCoCDC
oGNhbiBiZSBkb25lIGdyYWNlZnVsbHkuCj4gwqAgwqAgwqAqIG1pZ3JhdGVfZG9tYWluOiBBbHJl
YWR5IGZvcmNlZCwgZG9tYWluIGlzIGdvbmUgYWxyZWFkeSwgbm8KPiDCoCDCoCDCoCDCoGNoYW5j
ZSBvZiBhIGdyYWNlZnVsIHNodXRkb3duLgo+IMKgIMKgIMKgKiBtaWdyYXRlX3JlY2VpdmU6IEFs
cmVhZHkgZm9yY2VkLCB3ZSBoYXZlIGZhaWxlZCB0byByZWNlaXZlIHRoZQo+IMKgIMKgIMKgIMKg
ZG9tYWluLCBubyBwb3NzaWJpbGl0eSBvZiBhIGdyYWNlZnVsIHNodXRkb3duLgo+IMKgIMKgIMKg
KiBsaWJ4bF9kb21haW5fY3JlYXRlLCBvbiB0aGUgZmFpbHVyZSBwYXRoIHNvIG5vIG5lZWQgZm9y
IGEKPiDCoCDCoCDCoCDCoGdyYWNlZnVsIG9wdGlvbi4KPiDCoCDCoCDCoCogbGlieGxfX2Rlc3Ry
b3lfZGV2aWNlX21vZGVsLiBNYXliZSB0aGlzIHNob3VsZCBiZSBkb2luZyBhCj4gwqAgwqAgwqAg
wqBncmFjZWZ1bCBzaHV0ZG93biBidXQgaW4gdGhhdCBjYXNlIGl0IHNob3VsZCBlaXRoZXIgYmUg
Y2FsbGluZwo+IMKgIMKgIMKgIMKgbGlieGxfZG9tYWluX3NodXRkb3duIG9yIHdyaXRpbmcgdGhl
IHFlbXUtZG0gY29udHJvbCBub2RlIGFuZAo+IMKgIMKgIMKgIMKgd2FpdGluZywgYXQgd2hpY2gg
cG9pbnQgYWZ0ZXIgc29tZSB0aW1lb3V0IHBlcmhhcHMgYSBmb3JjZWQKPiDCoCDCoCDCoCDCoHNo
dXRkb3duIHdvdWxkIGJlIGFwcHJvcHJpYXRlLgo+Cj4gU28gaXQgc2VlbXMgdG8gbWUgdGhhdCB0
aGUgbm9uLWZvcmNlZCBvcHRpb24gaW4gbGlieGxfZG9tYWluX2Rlc3Ryb3kgY2FuCj4gYmUgcmVt
b3ZlZCBhbmQgd2Ugc2hvdWxkIGp1c3Qgc2hvb3QgdGhlIGRvbWFpbiBhbmQgdGhlbiBmb3JjaWJs
eQo+IHRlYXJkb3duIHRoZSBiYWNrZW5kcywgcnVubmluZyBzY3JpcHQgYXMgbmVjZXNzYXJ5Lgo+
Cj4gVGhlIG9ubHkgd3JpbmtsZSBpcyB0aGUgc3R1YiBkZXZpY2UtbW9kZWwgY2FzZSBidXQgcmVh
bGx5IHRoYXQncyBhbHJlYWR5Cj4gYSBzcGVjaWFsIGRvbWFpbiBhbmQgc2hvdWxkIGJlIHRyZWF0
ZWQgYXMgc3VjaC4KPgo+IERvZXMgdGhhdCBtYWtlIHNlbnNlIHRvIGFueW9uZSBlbHNlPwo+Cj4g
SWFuLgo+CgpXZWxsLCBJIHRoaW5rIEkgZm91bmQgdGhlIHVuZGVybHlpbmcgcHJvYmxlbSB0aGF0
IHdhcyBwcmV2ZW50aW5nCk5ldEJTRCBmcm9tIGNvcnJlY3RseSBkZXRhY2hpbmcgdm5kIGRldmlj
ZXMgd2hlbiBkZXN0cm95aW5nIGEgZG9tYWluLAp0aGUgZnJvbnRlbmQgc3RhdGUgbmVlZHMgdG8g
YmUgbWFudWFsbHkgc2V0IHRvIDYKKC9sb2NhbC9kb21haW4vPGRvbWlkPi9kZXZpY2UvdmJkLzxk
ZXZpZD4vc3RhdGUgYW5kIHRoZSBzYW1lIGZvciB2aWYKdG8gYmUgbW9yZSAiY29ycmVjdCIpIHNv
IHRoZSBrZXJuZWwgY2xvc2VzIHRoZSBkZXZpY2UgYW5kIGl0IGNhbiB0aGVuCmJlIGNvcnJlY3Rs
eSB1bm1vdW50ZWQuCgoKSSB3aWxsIHByZXBhcmUgYSBwYXRjaCAob3IgYSBzZXJpZXMpIHRvIGFk
cmVzcyB0aGlzLCBhbmQgY2hhbmdlCmxpYnhsX2RvbWFpbl9kZXN0cm95IHRvIHVzZSB0aGUgZm9y
Y2Ugd2hlbiBjYWxsZWQuCgpUaGFua3MsIFJvZ2VyLgoKX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxA
bGlzdHMueGVuc291cmNlLmNvbQpodHRwOi8vbGlzdHMueGVuc291cmNlLmNvbS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Fri Dec 02 11:54:26 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 11:54:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWRgY-0004b1-Uf; Fri, 02 Dec 2011 11:53:46 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RWRgX-0004al-LF
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 11:53:45 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1322826784!5545242!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTg0Mw==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28547 invoked from network); 2 Dec 2011 11:53:04 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Dec 2011 11:53:04 -0000
X-IronPort-AV: E=Sophos;i="4.71,282,1320624000"; 
   d="scan'208";a="9248648"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Dec 2011 11:53:03 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 2 Dec 2011 11:53:00 +0000
Date: Fri, 2 Dec 2011 11:53:53 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Jean Guyader <jean.guyader@eu.citrix.com>
In-Reply-To: <1322411006-12629-1-git-send-email-jean.guyader@eu.citrix.com>
Message-ID: <alpine.DEB.2.00.1112021114010.31179@kaball-desktop>
References: <1322411006-12629-1-git-send-email-jean.guyader@eu.citrix.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "allen.m.kay@intel.com" <allen.m.kay@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Jean Guyader <Jean.Guyader@citrix.com>
Subject: Re: [Xen-devel] [PATCH] qemu-xen: Intel GPU passthrough,
 fix OpRegion mapping.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Sun, 27 Nov 2011, Jean Guyader wrote:
> The OpRegion shouldn't be mapped 1:1 because the address in the host
> can't be used in the guest directly.
> 
> This patch traps read and write access to the opregion of the Intel
> GPU config space (offset 0xfc).
> 
> To work correctly this patch needs a change in hvmloader.
> 
> HVMloader will allocate 2 pages for the OpRegion and write this address
> on the config space of the Intel GPU. Qemu will trap and map the host
> OpRegion to the guest. Any write to this offset after that won't have
> any effect. Any read of this config space offset will return the address
> in the guest.
> 
> Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
> ---
>  hw/pass-through.c |    8 ++--
>  hw/pass-through.h |    4 ++
>  hw/pt-graphics.c  |   96 ++++++++++++++++++++++++++++++++++++++++++----------
>  3 files changed, 85 insertions(+), 23 deletions(-)
> 
> diff --git a/hw/pass-through.c b/hw/pass-through.c
> index 919937f..976d28f 100644
> --- a/hw/pass-through.c
> +++ b/hw/pass-through.c
> @@ -1455,8 +1455,7 @@ out:
>      return index;
>  }
>  
> -static void pt_pci_write_config(PCIDevice *d, uint32_t address, uint32_t val,
> -                                int len)
> +void pt_pci_write_config(PCIDevice *d, uint32_t address, uint32_t val, int len)
>  {
>      struct pt_dev *assigned_device = (struct pt_dev *)d;
>      struct pci_dev *pci_dev = assigned_device->pci_dev;
> @@ -1637,7 +1636,7 @@ exit:
>      return;
>  }
>  
> -static uint32_t pt_pci_read_config(PCIDevice *d, uint32_t address, int len)
> +uint32_t pt_pci_read_config(PCIDevice *d, uint32_t address, int len)
>  {
>      struct pt_dev *assigned_device = (struct pt_dev *)d;
>      struct pci_dev *pci_dev = assigned_device->pci_dev;
> @@ -4191,7 +4190,8 @@ static struct pt_dev * register_real_device(PCIBus *e_bus,
>      /* Register device */
>      assigned_device = (struct pt_dev *) pci_register_device(e_bus, e_dev_name,
>                                  sizeof(struct pt_dev), e_devfn,
> -                                pt_pci_read_config, pt_pci_write_config);
> +                                gfx_passthru ? vgapt_pci_read_config : pt_pci_read_config,
> +                                gfx_passthru ? vgapt_pci_write_config : pt_pci_write_config);

Would it be possible to call the two vgapt_* functions from
pt_pci_read/write_config? Maybe hooking them into pt_emu_reg_grp_tbl?


>      if ( assigned_device == NULL )
>      {
>          PT_LOG("Error: couldn't register real device\n");
> diff --git a/hw/pass-through.h b/hw/pass-through.h
> index 884139c..c898c7c 100644
> --- a/hw/pass-through.h
> +++ b/hw/pass-through.h
> @@ -422,6 +422,10 @@ PCIBus *intel_pci_bridge_init(PCIBus *bus, int devfn, uint16_t vid,
>             uint16_t did, const char *name, uint16_t revision);
>  void igd_pci_write(PCIDevice *pci_dev, uint32_t config_addr, uint32_t val, int len);
>  uint32_t igd_pci_read(PCIDevice *pci_dev, uint32_t config_addr, int len);
> +void vgapt_pci_write_config(PCIDevice *pci_dev, uint32_t config_addr, uint32_t val, int len);
> +uint32_t vgapt_pci_read_config(PCIDevice *pci_dev, uint32_t config_addr, int len);
> +uint32_t pt_pci_read_config(PCIDevice *d, uint32_t address, int len);
> +void pt_pci_write_config(PCIDevice *d, uint32_t address, uint32_t val, int len);
>  
>  #endif /* __PASSTHROUGH_H__ */
>  
> diff --git a/hw/pt-graphics.c b/hw/pt-graphics.c
> index fec7390..33cbff5 100644
> --- a/hw/pt-graphics.c
> +++ b/hw/pt-graphics.c
> @@ -13,6 +13,8 @@
>  extern int gfx_passthru;
>  extern int igd_passthru;
>  
> +static uint32_t igd_guest_opregion = 0;
> +
>  static int pch_map_irq(PCIDevice *pci_dev, int irq_num)
>  {
>      PT_LOG("pch_map_irq called\n");
> @@ -37,6 +39,77 @@ void intel_pch_init(PCIBus *bus)
>                          pch_map_irq, "intel_bridge_1f");
>  }
>  
> +static void igd_write_opregion(PCIDevice *pci_dev, uint32_t val, int len)
> +{
> +    struct pt_dev *real_dev = (struct pt_dev *)pci_dev;
> +    uint32_t host_opregion = 0;
> +    int ret;
> +
> +    if ( igd_guest_opregion || len != 4 )
> +        return;

You should print a warning here.


> +    host_opregion = pt_pci_host_read(real_dev->pci_dev,
> +            PCI_INTEL_OPREGION, len);
> +    igd_guest_opregion = (val & ~0xfff) | (host_opregion & 0xfff);
> +    PT_LOG("Map OpRegion: %x -> %x\n", host_opregion, igd_guest_opregion);
> +
> +    ret = xc_domain_memory_mapping(xc_handle, domid,
> +            igd_guest_opregion >> XC_PAGE_SHIFT,
> +            host_opregion >> XC_PAGE_SHIFT,
> +            2,
> +            DPCI_ADD_MAPPING);
> +
> +    if ( ret != 0 )
> +    {
> +        PT_LOG("Error: Can't map opregion\n");
> +        igd_guest_opregion = 0;
> +    }
> +}
> +
> +void vgapt_pci_write_config(PCIDevice *pci_dev, uint32_t config_addr, uint32_t val, int len)
> +{
> +#ifdef PT_DEBUG_PCI_CONFIG_ACCESS
> +    PT_LOG("vgapt_pci_write_config: %x:%x.%x: addr=%x len=%x val=%x\n",
> +            pci_bus_num(pci_dev->bus), PCI_SLOT(pci_dev->devfn),
> +            PCI_FUNC(pci_dev->devfn), config_addr, len, val);
> +#endif
> +
> +    if ( igd_passthru )
> +    {
> +        switch ( config_addr )
> +        {
> +            case 0xfc : /* Opregion */
> +                igd_write_opregion(pci_dev, val, len);
> +                return;
> +        }
> +    }

Shouldn't you be calling igd_write_opregion only if vendor_id ==
PCI_VENDOR_ID_INTEL?


> +    pt_pci_write_config(pci_dev, config_addr, val, len);
> +}
> +
> +uint32_t vgapt_pci_read_config(PCIDevice *pci_dev, uint32_t config_addr, int len)
> +{
> +    uint32_t val;
> +
> +    val = pt_pci_read_config(pci_dev, config_addr, len);
> +
> +    if ( igd_passthru )
> +    {
> +        switch ( config_addr )
> +        {
> +            case 0xfc: /* OpRegion */
> +                if ( igd_guest_opregion )
> +                    val = igd_guest_opregion;
> +                break;
> +        }
> +    }

Shouldn't you call pt_pci_read_config only at the end, in case it is not
igd_passthru or it is not config_addr == 0xfc?


> +#ifdef PT_DEBUG_PCI_CONFIG_ACCESS
> +    PT_LOG_DEV(pci_dev, "vgapt_pci_read_config: %x:%x.%x: addr=%x len=%x val=%x\n",
> +            config_addr, len, val);
> +#endif
> +    return val;
> +}
> +
>  void igd_pci_write(PCIDevice *pci_dev, uint32_t config_addr, uint32_t val, int len)
>  {
>      struct pci_dev *pci_dev_host_bridge = pt_pci_get_dev(0, 0, 0);
> @@ -99,7 +172,6 @@ uint32_t igd_pci_read(PCIDevice *pci_dev, uint32_t config_addr, int len)
>  int register_vga_regions(struct pt_dev *real_device)
>  {
>      u16 vendor_id;
> -    int igd_opregion;
>      int ret = 0;
>  
>      if ( !gfx_passthru || real_device->pci_dev->device_class != 0x0300 )
> @@ -117,19 +189,6 @@ int register_vga_regions(struct pt_dev *real_device)
>              0x20,
>              DPCI_ADD_MAPPING);
>  
> -    /* 1:1 map ASL Storage register value */
> -    vendor_id = pt_pci_host_read(real_device->pci_dev, 0, 2);
> -    igd_opregion = pt_pci_host_read(real_device->pci_dev, PCI_INTEL_OPREGION, 4);
> -    if ( (vendor_id == PCI_VENDOR_ID_INTEL ) && igd_opregion )
> -    {
> -        ret |= xc_domain_memory_mapping(xc_handle, domid,
> -                igd_opregion >> XC_PAGE_SHIFT,
> -                igd_opregion >> XC_PAGE_SHIFT,
> -                2,
> -                DPCI_ADD_MAPPING);
> -        PT_LOG("register_vga: igd_opregion = %x\n", igd_opregion);
> -    }
> -
>      if ( ret != 0 )
>          PT_LOG("VGA region mapping failed\n");
>  
> @@ -141,7 +200,7 @@ int register_vga_regions(struct pt_dev *real_device)
>   */
>  int unregister_vga_regions(struct pt_dev *real_device)
>  {
> -    u32 vendor_id, igd_opregion;
> +    u32 vendor_id;
>      int ret = 0;
>  
>      if ( !gfx_passthru || real_device->pci_dev->device_class != 0x0300 )
> @@ -160,12 +219,11 @@ int unregister_vga_regions(struct pt_dev *real_device)
>              DPCI_REMOVE_MAPPING);
>  
>      vendor_id = pt_pci_host_read(real_device->pci_dev, PCI_VENDOR_ID, 2);
> -    igd_opregion = pt_pci_host_read(real_device->pci_dev, PCI_INTEL_OPREGION, 4);
> -    if ( (vendor_id == PCI_VENDOR_ID_INTEL) && igd_opregion )
> +    if ( (vendor_id == PCI_VENDOR_ID_INTEL) && igd_guest_opregion )
>      {
>          ret |= xc_domain_memory_mapping(xc_handle, domid,
> -                igd_opregion >> XC_PAGE_SHIFT,
> -                igd_opregion >> XC_PAGE_SHIFT,
> +                igd_guest_opregion >> XC_PAGE_SHIFT,
> +                igd_guest_opregion >> XC_PAGE_SHIFT,
>                  2,
>                  DPCI_REMOVE_MAPPING);
>      }

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

From xen-devel-bounces@lists.xensource.com Fri Dec 02 11:54:26 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 11:54:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWRgY-0004b1-Uf; Fri, 02 Dec 2011 11:53:46 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RWRgX-0004al-LF
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 11:53:45 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1322826784!5545242!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTg0Mw==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28547 invoked from network); 2 Dec 2011 11:53:04 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Dec 2011 11:53:04 -0000
X-IronPort-AV: E=Sophos;i="4.71,282,1320624000"; 
   d="scan'208";a="9248648"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Dec 2011 11:53:03 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 2 Dec 2011 11:53:00 +0000
Date: Fri, 2 Dec 2011 11:53:53 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Jean Guyader <jean.guyader@eu.citrix.com>
In-Reply-To: <1322411006-12629-1-git-send-email-jean.guyader@eu.citrix.com>
Message-ID: <alpine.DEB.2.00.1112021114010.31179@kaball-desktop>
References: <1322411006-12629-1-git-send-email-jean.guyader@eu.citrix.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "allen.m.kay@intel.com" <allen.m.kay@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Jean Guyader <Jean.Guyader@citrix.com>
Subject: Re: [Xen-devel] [PATCH] qemu-xen: Intel GPU passthrough,
 fix OpRegion mapping.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Sun, 27 Nov 2011, Jean Guyader wrote:
> The OpRegion shouldn't be mapped 1:1 because the address in the host
> can't be used in the guest directly.
> 
> This patch traps read and write access to the opregion of the Intel
> GPU config space (offset 0xfc).
> 
> To work correctly this patch needs a change in hvmloader.
> 
> HVMloader will allocate 2 pages for the OpRegion and write this address
> on the config space of the Intel GPU. Qemu will trap and map the host
> OpRegion to the guest. Any write to this offset after that won't have
> any effect. Any read of this config space offset will return the address
> in the guest.
> 
> Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
> ---
>  hw/pass-through.c |    8 ++--
>  hw/pass-through.h |    4 ++
>  hw/pt-graphics.c  |   96 ++++++++++++++++++++++++++++++++++++++++++----------
>  3 files changed, 85 insertions(+), 23 deletions(-)
> 
> diff --git a/hw/pass-through.c b/hw/pass-through.c
> index 919937f..976d28f 100644
> --- a/hw/pass-through.c
> +++ b/hw/pass-through.c
> @@ -1455,8 +1455,7 @@ out:
>      return index;
>  }
>  
> -static void pt_pci_write_config(PCIDevice *d, uint32_t address, uint32_t val,
> -                                int len)
> +void pt_pci_write_config(PCIDevice *d, uint32_t address, uint32_t val, int len)
>  {
>      struct pt_dev *assigned_device = (struct pt_dev *)d;
>      struct pci_dev *pci_dev = assigned_device->pci_dev;
> @@ -1637,7 +1636,7 @@ exit:
>      return;
>  }
>  
> -static uint32_t pt_pci_read_config(PCIDevice *d, uint32_t address, int len)
> +uint32_t pt_pci_read_config(PCIDevice *d, uint32_t address, int len)
>  {
>      struct pt_dev *assigned_device = (struct pt_dev *)d;
>      struct pci_dev *pci_dev = assigned_device->pci_dev;
> @@ -4191,7 +4190,8 @@ static struct pt_dev * register_real_device(PCIBus *e_bus,
>      /* Register device */
>      assigned_device = (struct pt_dev *) pci_register_device(e_bus, e_dev_name,
>                                  sizeof(struct pt_dev), e_devfn,
> -                                pt_pci_read_config, pt_pci_write_config);
> +                                gfx_passthru ? vgapt_pci_read_config : pt_pci_read_config,
> +                                gfx_passthru ? vgapt_pci_write_config : pt_pci_write_config);

Would it be possible to call the two vgapt_* functions from
pt_pci_read/write_config? Maybe hooking them into pt_emu_reg_grp_tbl?


>      if ( assigned_device == NULL )
>      {
>          PT_LOG("Error: couldn't register real device\n");
> diff --git a/hw/pass-through.h b/hw/pass-through.h
> index 884139c..c898c7c 100644
> --- a/hw/pass-through.h
> +++ b/hw/pass-through.h
> @@ -422,6 +422,10 @@ PCIBus *intel_pci_bridge_init(PCIBus *bus, int devfn, uint16_t vid,
>             uint16_t did, const char *name, uint16_t revision);
>  void igd_pci_write(PCIDevice *pci_dev, uint32_t config_addr, uint32_t val, int len);
>  uint32_t igd_pci_read(PCIDevice *pci_dev, uint32_t config_addr, int len);
> +void vgapt_pci_write_config(PCIDevice *pci_dev, uint32_t config_addr, uint32_t val, int len);
> +uint32_t vgapt_pci_read_config(PCIDevice *pci_dev, uint32_t config_addr, int len);
> +uint32_t pt_pci_read_config(PCIDevice *d, uint32_t address, int len);
> +void pt_pci_write_config(PCIDevice *d, uint32_t address, uint32_t val, int len);
>  
>  #endif /* __PASSTHROUGH_H__ */
>  
> diff --git a/hw/pt-graphics.c b/hw/pt-graphics.c
> index fec7390..33cbff5 100644
> --- a/hw/pt-graphics.c
> +++ b/hw/pt-graphics.c
> @@ -13,6 +13,8 @@
>  extern int gfx_passthru;
>  extern int igd_passthru;
>  
> +static uint32_t igd_guest_opregion = 0;
> +
>  static int pch_map_irq(PCIDevice *pci_dev, int irq_num)
>  {
>      PT_LOG("pch_map_irq called\n");
> @@ -37,6 +39,77 @@ void intel_pch_init(PCIBus *bus)
>                          pch_map_irq, "intel_bridge_1f");
>  }
>  
> +static void igd_write_opregion(PCIDevice *pci_dev, uint32_t val, int len)
> +{
> +    struct pt_dev *real_dev = (struct pt_dev *)pci_dev;
> +    uint32_t host_opregion = 0;
> +    int ret;
> +
> +    if ( igd_guest_opregion || len != 4 )
> +        return;

You should print a warning here.


> +    host_opregion = pt_pci_host_read(real_dev->pci_dev,
> +            PCI_INTEL_OPREGION, len);
> +    igd_guest_opregion = (val & ~0xfff) | (host_opregion & 0xfff);
> +    PT_LOG("Map OpRegion: %x -> %x\n", host_opregion, igd_guest_opregion);
> +
> +    ret = xc_domain_memory_mapping(xc_handle, domid,
> +            igd_guest_opregion >> XC_PAGE_SHIFT,
> +            host_opregion >> XC_PAGE_SHIFT,
> +            2,
> +            DPCI_ADD_MAPPING);
> +
> +    if ( ret != 0 )
> +    {
> +        PT_LOG("Error: Can't map opregion\n");
> +        igd_guest_opregion = 0;
> +    }
> +}
> +
> +void vgapt_pci_write_config(PCIDevice *pci_dev, uint32_t config_addr, uint32_t val, int len)
> +{
> +#ifdef PT_DEBUG_PCI_CONFIG_ACCESS
> +    PT_LOG("vgapt_pci_write_config: %x:%x.%x: addr=%x len=%x val=%x\n",
> +            pci_bus_num(pci_dev->bus), PCI_SLOT(pci_dev->devfn),
> +            PCI_FUNC(pci_dev->devfn), config_addr, len, val);
> +#endif
> +
> +    if ( igd_passthru )
> +    {
> +        switch ( config_addr )
> +        {
> +            case 0xfc : /* Opregion */
> +                igd_write_opregion(pci_dev, val, len);
> +                return;
> +        }
> +    }

Shouldn't you be calling igd_write_opregion only if vendor_id ==
PCI_VENDOR_ID_INTEL?


> +    pt_pci_write_config(pci_dev, config_addr, val, len);
> +}
> +
> +uint32_t vgapt_pci_read_config(PCIDevice *pci_dev, uint32_t config_addr, int len)
> +{
> +    uint32_t val;
> +
> +    val = pt_pci_read_config(pci_dev, config_addr, len);
> +
> +    if ( igd_passthru )
> +    {
> +        switch ( config_addr )
> +        {
> +            case 0xfc: /* OpRegion */
> +                if ( igd_guest_opregion )
> +                    val = igd_guest_opregion;
> +                break;
> +        }
> +    }

Shouldn't you call pt_pci_read_config only at the end, in case it is not
igd_passthru or it is not config_addr == 0xfc?


> +#ifdef PT_DEBUG_PCI_CONFIG_ACCESS
> +    PT_LOG_DEV(pci_dev, "vgapt_pci_read_config: %x:%x.%x: addr=%x len=%x val=%x\n",
> +            config_addr, len, val);
> +#endif
> +    return val;
> +}
> +
>  void igd_pci_write(PCIDevice *pci_dev, uint32_t config_addr, uint32_t val, int len)
>  {
>      struct pci_dev *pci_dev_host_bridge = pt_pci_get_dev(0, 0, 0);
> @@ -99,7 +172,6 @@ uint32_t igd_pci_read(PCIDevice *pci_dev, uint32_t config_addr, int len)
>  int register_vga_regions(struct pt_dev *real_device)
>  {
>      u16 vendor_id;
> -    int igd_opregion;
>      int ret = 0;
>  
>      if ( !gfx_passthru || real_device->pci_dev->device_class != 0x0300 )
> @@ -117,19 +189,6 @@ int register_vga_regions(struct pt_dev *real_device)
>              0x20,
>              DPCI_ADD_MAPPING);
>  
> -    /* 1:1 map ASL Storage register value */
> -    vendor_id = pt_pci_host_read(real_device->pci_dev, 0, 2);
> -    igd_opregion = pt_pci_host_read(real_device->pci_dev, PCI_INTEL_OPREGION, 4);
> -    if ( (vendor_id == PCI_VENDOR_ID_INTEL ) && igd_opregion )
> -    {
> -        ret |= xc_domain_memory_mapping(xc_handle, domid,
> -                igd_opregion >> XC_PAGE_SHIFT,
> -                igd_opregion >> XC_PAGE_SHIFT,
> -                2,
> -                DPCI_ADD_MAPPING);
> -        PT_LOG("register_vga: igd_opregion = %x\n", igd_opregion);
> -    }
> -
>      if ( ret != 0 )
>          PT_LOG("VGA region mapping failed\n");
>  
> @@ -141,7 +200,7 @@ int register_vga_regions(struct pt_dev *real_device)
>   */
>  int unregister_vga_regions(struct pt_dev *real_device)
>  {
> -    u32 vendor_id, igd_opregion;
> +    u32 vendor_id;
>      int ret = 0;
>  
>      if ( !gfx_passthru || real_device->pci_dev->device_class != 0x0300 )
> @@ -160,12 +219,11 @@ int unregister_vga_regions(struct pt_dev *real_device)
>              DPCI_REMOVE_MAPPING);
>  
>      vendor_id = pt_pci_host_read(real_device->pci_dev, PCI_VENDOR_ID, 2);
> -    igd_opregion = pt_pci_host_read(real_device->pci_dev, PCI_INTEL_OPREGION, 4);
> -    if ( (vendor_id == PCI_VENDOR_ID_INTEL) && igd_opregion )
> +    if ( (vendor_id == PCI_VENDOR_ID_INTEL) && igd_guest_opregion )
>      {
>          ret |= xc_domain_memory_mapping(xc_handle, domid,
> -                igd_opregion >> XC_PAGE_SHIFT,
> -                igd_opregion >> XC_PAGE_SHIFT,
> +                igd_guest_opregion >> XC_PAGE_SHIFT,
> +                igd_guest_opregion >> XC_PAGE_SHIFT,
>                  2,
>                  DPCI_REMOVE_MAPPING);
>      }

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

From xen-devel-bounces@lists.xensource.com Fri Dec 02 12:34:47 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 12: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.xensource.com>)
	id 1RWSJc-0005ZD-VV; Fri, 02 Dec 2011 12:34:08 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1RWSJb-0005Z1-Rq
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 12:34:08 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1322829170!45173595!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjg1NDY=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26271 invoked from network); 2 Dec 2011 12:32:51 -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;
	2 Dec 2011 12:32:51 -0000
X-IronPort-AV: E=Sophos;i="4.71,283,1320642000"; d="scan'208";a="172666351"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Dec 2011 07:33:24 -0500
Received: from [10.80.2.18] (10.80.2.18) by FTLPMAILMX02.citrite.net
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Fri, 2 Dec 2011
	07:33:23 -0500
Message-ID: <4ED8C592.3010603@citrix.com>
Date: Fri, 2 Dec 2011 12:33:22 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.23) Gecko/20110921 Lightning/1.0b2 Thunderbird/3.1.15
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <CAFA7027.25E35%keir.xen@gmail.com> <4ED62C50.7060204@citrix.com>
	<4ED666D5.5060603@citrix.com>
	<4ED7522E0200007800064973@nat28.tlf.novell.com>
	<4ED74DAD.1040903@citrix.com>
	<4ED75E8402000078000649E6@nat28.tlf.novell.com>
	<4ED77347.6060200@citrix.com>
	<4ED787870200007800064B6F@nat28.tlf.novell.com>
	<4ED79722.7090404@citrix.com>
	<4ED7A8110200007800064C50@nat28.tlf.novell.com>
	<4ED7B5FF.2090305@citrix.com>
	<4ED894100200007800064FE3@nat28.tlf.novell.com>
In-Reply-To: <4ED894100200007800064FE3@nat28.tlf.novell.com>
X-Enigmail-Version: 1.1.2
Cc: Keir Fraser <keir.xen@gmail.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [RFC] KEXEC: allocate crash note buffers at boot
	time v4
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 02/12/11 08:02, Jan Beulich wrote:
>>>> On 01.12.11 at 18:14, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
> Looks good to me now except for one minor thing (below), and the
> fact that you still decided to retain the two duplicates of the size
> calculation (I'll have to remember to clean this up if you don't, unless
> Keir explicitly agrees with the duplication).

Ok - I will turn them into a start,size pair

>> +    /* Try once again to allocate room for the crash notes.  It is just possible
>> +     * that more space has become available since we last tried.  If space has
>> +     * already been allocated, kexec_init_cpu_notes() will return early with 0.
>> +     */
>> +    if ( kexec_init_cpu_notes(nr) )
>>         return -EINVAL;
> The function can fail only with -ENOMEM, so why not return this here?
>
> Jan
>

Actually, returning -EINVAL here is counter productive.  -EINVAL is used
by dom0 to work out when it has asked for each CPU.  This in itself is a
little broken because there is nothing stopping a middle CPU from being
offline at the time these hypercalls are made.  The other thing is that
there is nothing stopping an offline cpu from having a valid notes
section.  Therefore, the test of online should be removed, so -EINVAL
only gets returned for cpu out of range, or not set up notes at all in
the first place.

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com


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

From xen-devel-bounces@lists.xensource.com Fri Dec 02 12:34:47 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 12: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.xensource.com>)
	id 1RWSJc-0005ZD-VV; Fri, 02 Dec 2011 12:34:08 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1RWSJb-0005Z1-Rq
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 12:34:08 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1322829170!45173595!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjg1NDY=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26271 invoked from network); 2 Dec 2011 12:32:51 -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;
	2 Dec 2011 12:32:51 -0000
X-IronPort-AV: E=Sophos;i="4.71,283,1320642000"; d="scan'208";a="172666351"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Dec 2011 07:33:24 -0500
Received: from [10.80.2.18] (10.80.2.18) by FTLPMAILMX02.citrite.net
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Fri, 2 Dec 2011
	07:33:23 -0500
Message-ID: <4ED8C592.3010603@citrix.com>
Date: Fri, 2 Dec 2011 12:33:22 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.23) Gecko/20110921 Lightning/1.0b2 Thunderbird/3.1.15
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <CAFA7027.25E35%keir.xen@gmail.com> <4ED62C50.7060204@citrix.com>
	<4ED666D5.5060603@citrix.com>
	<4ED7522E0200007800064973@nat28.tlf.novell.com>
	<4ED74DAD.1040903@citrix.com>
	<4ED75E8402000078000649E6@nat28.tlf.novell.com>
	<4ED77347.6060200@citrix.com>
	<4ED787870200007800064B6F@nat28.tlf.novell.com>
	<4ED79722.7090404@citrix.com>
	<4ED7A8110200007800064C50@nat28.tlf.novell.com>
	<4ED7B5FF.2090305@citrix.com>
	<4ED894100200007800064FE3@nat28.tlf.novell.com>
In-Reply-To: <4ED894100200007800064FE3@nat28.tlf.novell.com>
X-Enigmail-Version: 1.1.2
Cc: Keir Fraser <keir.xen@gmail.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [RFC] KEXEC: allocate crash note buffers at boot
	time v4
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 02/12/11 08:02, Jan Beulich wrote:
>>>> On 01.12.11 at 18:14, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
> Looks good to me now except for one minor thing (below), and the
> fact that you still decided to retain the two duplicates of the size
> calculation (I'll have to remember to clean this up if you don't, unless
> Keir explicitly agrees with the duplication).

Ok - I will turn them into a start,size pair

>> +    /* Try once again to allocate room for the crash notes.  It is just possible
>> +     * that more space has become available since we last tried.  If space has
>> +     * already been allocated, kexec_init_cpu_notes() will return early with 0.
>> +     */
>> +    if ( kexec_init_cpu_notes(nr) )
>>         return -EINVAL;
> The function can fail only with -ENOMEM, so why not return this here?
>
> Jan
>

Actually, returning -EINVAL here is counter productive.  -EINVAL is used
by dom0 to work out when it has asked for each CPU.  This in itself is a
little broken because there is nothing stopping a middle CPU from being
offline at the time these hypercalls are made.  The other thing is that
there is nothing stopping an offline cpu from having a valid notes
section.  Therefore, the test of online should be removed, so -EINVAL
only gets returned for cpu out of range, or not set up notes at all in
the first place.

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com


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

From xen-devel-bounces@lists.xensource.com Fri Dec 02 12:40:51 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 12:40:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWSPJ-0005kf-Pc; Fri, 02 Dec 2011 12:40:01 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RWSPI-0005kR-4C
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 12:40:00 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1322829559!5825504!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTg0Mw==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15605 invoked from network); 2 Dec 2011 12:39:19 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Dec 2011 12:39:19 -0000
X-IronPort-AV: E=Sophos;i="4.71,283,1320624000"; 
   d="scan'208";a="9250090"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Dec 2011 12:39:19 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 2 Dec 2011 12:39:19 +0000
Date: Fri, 2 Dec 2011 12:40:17 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Haitao Shan <maillists.shan@gmail.com>
In-Reply-To: <CAFQ2Z+fpR1UkxFEAYTD6irBUBeA3c7eJ3x1bXE0jzpdfQtH64w@mail.gmail.com>
Message-ID: <alpine.DEB.2.00.1112021223190.31179@kaball-desktop>
References: <CAFQ2Z+fpR1UkxFEAYTD6irBUBeA3c7eJ3x1bXE0jzpdfQtH64w@mail.gmail.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Keir Fraser <keir@xen.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] Qemu MSI Cleaning Up
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 22 Sep 2011, Haitao Shan wrote:
> Hi, Ian, Keir, Jan,
> 
> This patch does cleaning up of QEMU MSI handling. The fixes are:
> 1. Changes made to MSI-X table mapping handling to eliminate the small
> windows in which guest could have access to physical MSI-X table.
> 2. MSI-X table is mapped as read-only to QEMU, as masking of MSI-X is
> already in Xen now.
> 3. For registers that coexists inside the MSI-X table (this could be
> only PBA I think), value read from physical page would be returned.
> 
> Could you please have review?
> 
> Signed-off-by:  Shan Haitao <haitao.shan@intel.com>
> 
> 
> diff --git a/hw/pass-through.c b/hw/pass-through.c
> index 9c5620d..6ebed64 100644
> --- a/hw/pass-through.c
> +++ b/hw/pass-through.c
> @@ -92,6 +92,7 @@
> 
>  #include <unistd.h>
>  #include <sys/ioctl.h>
> +#include <assert.h>
> 
>  extern int gfx_passthru;
>  int igd_passthru = 0;
> @@ -1103,6 +1104,7 @@ static void pt_iomem_map(PCIDevice *d, int i,
> uint32_t e_phys, uint32_t e_size,
>  {
>      struct pt_dev *assigned_device  = (struct pt_dev *)d;
>      uint32_t old_ebase = assigned_device->bases[i].e_physbase;
> +    uint32_t msix_last_pfn = 0, bar_last_pfn = 0;
>      int first_map = ( assigned_device->bases[i].e_size == 0 );
>      int ret = 0;
> 
> @@ -1118,39 +1120,127 @@ static void pt_iomem_map(PCIDevice *d, int i,
> uint32_t e_phys, uint32_t e_size,
> 
>      if ( !first_map && old_ebase != -1 )
>      {
> -        add_msix_mapping(assigned_device, i);
> -        /* Remove old mapping */
> -        ret = xc_domain_memory_mapping(xc_handle, domid,
> +        if ( has_msix_mapping(assigned_device, i) )
> +        {
> +            msix_last_pfn = (assigned_device->msix->mmio_base_addr - 1 +
> +                  assigned_device->msix->total_entries * 16) >>  XC_PAGE_SHIFT;
> +            bar_last_pfn = (old_ebase + e_size - 1) >> XC_PAGE_SHIFT;
> +
> +            unregister_iomem(assigned_device->msix->mmio_base_addr);
> +
> +            if ( assigned_device->msix->table_off )
> +            {
> +                       ret = xc_domain_memory_mapping(xc_handle, domid,
> +                    old_ebase >> XC_PAGE_SHIFT,
> +                    assigned_device->bases[i].access.maddr >> XC_PAGE_SHIFT,
> +                    (assigned_device->msix->mmio_base_addr >> XC_PAGE_SHIFT)
> +                    - (old_ebase >> XC_PAGE_SHIFT),
> +                    DPCI_REMOVE_MAPPING);
> +                if ( ret != 0 )
> +                {
> +                    PT_LOG("Error: remove old mapping failed!\n");
> +                    return;
> +                }
> +            }
> +            if ( msix_last_pfn != bar_last_pfn )
> +            {
> +                assert(msix_last_pfn < bar_last_pfn);
> +                       ret = xc_domain_memory_mapping(xc_handle, domid,
> +                    msix_last_pfn + 1,
> +                    (assigned_device->bases[i].access.maddr +
> +                     assigned_device->msix->table_off +
> +                     assigned_device->msix->total_entries * 16 +
> +                     XC_PAGE_SIZE -1) >>  XC_PAGE_SHIFT,
> +                    bar_last_pfn - msix_last_pfn,
> +                    DPCI_REMOVE_MAPPING);
> +                if ( ret != 0 )
> +                {
> +                    PT_LOG("Error: remove old mapping failed!\n");
> +                    return;
> +                }
> +            }
> +        }
> +        else
> +        {
> +                   /* Remove old mapping */
> +                   ret = xc_domain_memory_mapping(xc_handle, domid,
>                  old_ebase >> XC_PAGE_SHIFT,
>                  assigned_device->bases[i].access.maddr >> XC_PAGE_SHIFT,
>                  (e_size+XC_PAGE_SIZE-1) >> XC_PAGE_SHIFT,
>                  DPCI_REMOVE_MAPPING);
> -        if ( ret != 0 )
> -        {
> -            PT_LOG("Error: remove old mapping failed!\n");
> -            return;
> +            if ( ret != 0 )
> +            {
> +                PT_LOG("Error: remove old mapping failed!\n");
> +                return;
> +            }
>          }
>      }
> 
>      /* map only valid guest address */
>      if (e_phys != -1)
>      {
> -        /* Create new mapping */
> -        ret = xc_domain_memory_mapping(xc_handle, domid,
> +        if ( has_msix_mapping(assigned_device, i) )
> +               {
> +            assigned_device->msix->mmio_base_addr =
> +                assigned_device->bases[i].e_physbase
> +                + assigned_device->msix->table_off;
> +
> +            msix_last_pfn = (assigned_device->msix->mmio_base_addr - 1 +
> +                  assigned_device->msix->total_entries * 16) >>  XC_PAGE_SHIFT;
> +            bar_last_pfn = (e_phys + e_size - 1) >> XC_PAGE_SHIFT;
> +
> +            cpu_register_physical_memory(assigned_device->msix->mmio_base_addr,
> +                 (assigned_device->msix->total_entries * 16 + XC_PAGE_SIZE - 1)
> +                  & XC_PAGE_MASK,
> +                 assigned_device->msix->mmio_index);
>
> +            if ( assigned_device->msix->table_off )
> +            {
> +                       ret = xc_domain_memory_mapping(xc_handle, domid,
> +                    assigned_device->bases[i].e_physbase >> XC_PAGE_SHIFT,
> +                    assigned_device->bases[i].access.maddr >> XC_PAGE_SHIFT,
> +                    (assigned_device->msix->mmio_base_addr >> XC_PAGE_SHIFT)
> +                    - (assigned_device->bases[i].e_physbase >> XC_PAGE_SHIFT),
> +                    DPCI_ADD_MAPPING);
> +                if ( ret != 0 )
> +                {
> +                    PT_LOG("Error: remove old mapping failed!\n");
> +                    return;

the log message is wrong here: we are trying to create new mappings

> +                }
> +            }
> +            if ( msix_last_pfn != bar_last_pfn )
> +            {
> +                assert(msix_last_pfn < bar_last_pfn);
> +                       ret = xc_domain_memory_mapping(xc_handle, domid,
> +                    msix_last_pfn + 1,
> +                    (assigned_device->bases[i].access.maddr +
> +                     assigned_device->msix->table_off +
> +                     assigned_device->msix->total_entries * 16 +
> +                     XC_PAGE_SIZE -1) >>  XC_PAGE_SHIFT,
> +                    bar_last_pfn - msix_last_pfn,
> +                    DPCI_ADD_MAPPING);
> +                if ( ret != 0 )
> +                {
> +                    PT_LOG("Error: remove old mapping failed!\n");
> +                    return;

same here

> +                }
> +            }
> +               }
> +               else
> +        {
> +                       /* Create new mapping */
> +                       ret = xc_domain_memory_mapping(xc_handle, domid,
>                  assigned_device->bases[i].e_physbase >> XC_PAGE_SHIFT,
>                  assigned_device->bases[i].access.maddr >> XC_PAGE_SHIFT,
>                  (e_size+XC_PAGE_SIZE-1) >> XC_PAGE_SHIFT,
>                  DPCI_ADD_MAPPING);
> 
> -        if ( ret != 0 )
> -        {
> -            PT_LOG("Error: create new mapping failed!\n");
> +            if ( ret != 0 )
> +            {
> +                PT_LOG("Error: create new mapping failed!\n");
> +            }
>          }
> 
> -        ret = remove_msix_mapping(assigned_device, i);
> -        if ( ret != 0 )
> -            PT_LOG("Error: remove MSI-X mmio mapping failed!\n");
> -
>          if ( old_ebase != e_phys && old_ebase != -1 )
>              pt_msix_update_remap(assigned_device, i);
>      }

The two mapping and unmapping big chuncks of code looks very similar
apart from the DPCI_ADD_MAPPING/DPCI_REMOVE_MAPPING parameter.
Could they be refactored into a single function called "change_msix_mappings"?
This is more or less what I have in mind:

change_msix_mappings(assigned_device, DPCI_REMOVE_MAPPING);

update mmio_base_addr

change_msix_mappings(assigned_device, DPCI_ADD_MAPPING);


The rest looks OK to me.

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

From xen-devel-bounces@lists.xensource.com Fri Dec 02 12:40:51 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 12:40:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWSPJ-0005kf-Pc; Fri, 02 Dec 2011 12:40:01 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RWSPI-0005kR-4C
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 12:40:00 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1322829559!5825504!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTg0Mw==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15605 invoked from network); 2 Dec 2011 12:39:19 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Dec 2011 12:39:19 -0000
X-IronPort-AV: E=Sophos;i="4.71,283,1320624000"; 
   d="scan'208";a="9250090"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Dec 2011 12:39:19 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 2 Dec 2011 12:39:19 +0000
Date: Fri, 2 Dec 2011 12:40:17 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Haitao Shan <maillists.shan@gmail.com>
In-Reply-To: <CAFQ2Z+fpR1UkxFEAYTD6irBUBeA3c7eJ3x1bXE0jzpdfQtH64w@mail.gmail.com>
Message-ID: <alpine.DEB.2.00.1112021223190.31179@kaball-desktop>
References: <CAFQ2Z+fpR1UkxFEAYTD6irBUBeA3c7eJ3x1bXE0jzpdfQtH64w@mail.gmail.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Keir Fraser <keir@xen.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] Qemu MSI Cleaning Up
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 22 Sep 2011, Haitao Shan wrote:
> Hi, Ian, Keir, Jan,
> 
> This patch does cleaning up of QEMU MSI handling. The fixes are:
> 1. Changes made to MSI-X table mapping handling to eliminate the small
> windows in which guest could have access to physical MSI-X table.
> 2. MSI-X table is mapped as read-only to QEMU, as masking of MSI-X is
> already in Xen now.
> 3. For registers that coexists inside the MSI-X table (this could be
> only PBA I think), value read from physical page would be returned.
> 
> Could you please have review?
> 
> Signed-off-by:  Shan Haitao <haitao.shan@intel.com>
> 
> 
> diff --git a/hw/pass-through.c b/hw/pass-through.c
> index 9c5620d..6ebed64 100644
> --- a/hw/pass-through.c
> +++ b/hw/pass-through.c
> @@ -92,6 +92,7 @@
> 
>  #include <unistd.h>
>  #include <sys/ioctl.h>
> +#include <assert.h>
> 
>  extern int gfx_passthru;
>  int igd_passthru = 0;
> @@ -1103,6 +1104,7 @@ static void pt_iomem_map(PCIDevice *d, int i,
> uint32_t e_phys, uint32_t e_size,
>  {
>      struct pt_dev *assigned_device  = (struct pt_dev *)d;
>      uint32_t old_ebase = assigned_device->bases[i].e_physbase;
> +    uint32_t msix_last_pfn = 0, bar_last_pfn = 0;
>      int first_map = ( assigned_device->bases[i].e_size == 0 );
>      int ret = 0;
> 
> @@ -1118,39 +1120,127 @@ static void pt_iomem_map(PCIDevice *d, int i,
> uint32_t e_phys, uint32_t e_size,
> 
>      if ( !first_map && old_ebase != -1 )
>      {
> -        add_msix_mapping(assigned_device, i);
> -        /* Remove old mapping */
> -        ret = xc_domain_memory_mapping(xc_handle, domid,
> +        if ( has_msix_mapping(assigned_device, i) )
> +        {
> +            msix_last_pfn = (assigned_device->msix->mmio_base_addr - 1 +
> +                  assigned_device->msix->total_entries * 16) >>  XC_PAGE_SHIFT;
> +            bar_last_pfn = (old_ebase + e_size - 1) >> XC_PAGE_SHIFT;
> +
> +            unregister_iomem(assigned_device->msix->mmio_base_addr);
> +
> +            if ( assigned_device->msix->table_off )
> +            {
> +                       ret = xc_domain_memory_mapping(xc_handle, domid,
> +                    old_ebase >> XC_PAGE_SHIFT,
> +                    assigned_device->bases[i].access.maddr >> XC_PAGE_SHIFT,
> +                    (assigned_device->msix->mmio_base_addr >> XC_PAGE_SHIFT)
> +                    - (old_ebase >> XC_PAGE_SHIFT),
> +                    DPCI_REMOVE_MAPPING);
> +                if ( ret != 0 )
> +                {
> +                    PT_LOG("Error: remove old mapping failed!\n");
> +                    return;
> +                }
> +            }
> +            if ( msix_last_pfn != bar_last_pfn )
> +            {
> +                assert(msix_last_pfn < bar_last_pfn);
> +                       ret = xc_domain_memory_mapping(xc_handle, domid,
> +                    msix_last_pfn + 1,
> +                    (assigned_device->bases[i].access.maddr +
> +                     assigned_device->msix->table_off +
> +                     assigned_device->msix->total_entries * 16 +
> +                     XC_PAGE_SIZE -1) >>  XC_PAGE_SHIFT,
> +                    bar_last_pfn - msix_last_pfn,
> +                    DPCI_REMOVE_MAPPING);
> +                if ( ret != 0 )
> +                {
> +                    PT_LOG("Error: remove old mapping failed!\n");
> +                    return;
> +                }
> +            }
> +        }
> +        else
> +        {
> +                   /* Remove old mapping */
> +                   ret = xc_domain_memory_mapping(xc_handle, domid,
>                  old_ebase >> XC_PAGE_SHIFT,
>                  assigned_device->bases[i].access.maddr >> XC_PAGE_SHIFT,
>                  (e_size+XC_PAGE_SIZE-1) >> XC_PAGE_SHIFT,
>                  DPCI_REMOVE_MAPPING);
> -        if ( ret != 0 )
> -        {
> -            PT_LOG("Error: remove old mapping failed!\n");
> -            return;
> +            if ( ret != 0 )
> +            {
> +                PT_LOG("Error: remove old mapping failed!\n");
> +                return;
> +            }
>          }
>      }
> 
>      /* map only valid guest address */
>      if (e_phys != -1)
>      {
> -        /* Create new mapping */
> -        ret = xc_domain_memory_mapping(xc_handle, domid,
> +        if ( has_msix_mapping(assigned_device, i) )
> +               {
> +            assigned_device->msix->mmio_base_addr =
> +                assigned_device->bases[i].e_physbase
> +                + assigned_device->msix->table_off;
> +
> +            msix_last_pfn = (assigned_device->msix->mmio_base_addr - 1 +
> +                  assigned_device->msix->total_entries * 16) >>  XC_PAGE_SHIFT;
> +            bar_last_pfn = (e_phys + e_size - 1) >> XC_PAGE_SHIFT;
> +
> +            cpu_register_physical_memory(assigned_device->msix->mmio_base_addr,
> +                 (assigned_device->msix->total_entries * 16 + XC_PAGE_SIZE - 1)
> +                  & XC_PAGE_MASK,
> +                 assigned_device->msix->mmio_index);
>
> +            if ( assigned_device->msix->table_off )
> +            {
> +                       ret = xc_domain_memory_mapping(xc_handle, domid,
> +                    assigned_device->bases[i].e_physbase >> XC_PAGE_SHIFT,
> +                    assigned_device->bases[i].access.maddr >> XC_PAGE_SHIFT,
> +                    (assigned_device->msix->mmio_base_addr >> XC_PAGE_SHIFT)
> +                    - (assigned_device->bases[i].e_physbase >> XC_PAGE_SHIFT),
> +                    DPCI_ADD_MAPPING);
> +                if ( ret != 0 )
> +                {
> +                    PT_LOG("Error: remove old mapping failed!\n");
> +                    return;

the log message is wrong here: we are trying to create new mappings

> +                }
> +            }
> +            if ( msix_last_pfn != bar_last_pfn )
> +            {
> +                assert(msix_last_pfn < bar_last_pfn);
> +                       ret = xc_domain_memory_mapping(xc_handle, domid,
> +                    msix_last_pfn + 1,
> +                    (assigned_device->bases[i].access.maddr +
> +                     assigned_device->msix->table_off +
> +                     assigned_device->msix->total_entries * 16 +
> +                     XC_PAGE_SIZE -1) >>  XC_PAGE_SHIFT,
> +                    bar_last_pfn - msix_last_pfn,
> +                    DPCI_ADD_MAPPING);
> +                if ( ret != 0 )
> +                {
> +                    PT_LOG("Error: remove old mapping failed!\n");
> +                    return;

same here

> +                }
> +            }
> +               }
> +               else
> +        {
> +                       /* Create new mapping */
> +                       ret = xc_domain_memory_mapping(xc_handle, domid,
>                  assigned_device->bases[i].e_physbase >> XC_PAGE_SHIFT,
>                  assigned_device->bases[i].access.maddr >> XC_PAGE_SHIFT,
>                  (e_size+XC_PAGE_SIZE-1) >> XC_PAGE_SHIFT,
>                  DPCI_ADD_MAPPING);
> 
> -        if ( ret != 0 )
> -        {
> -            PT_LOG("Error: create new mapping failed!\n");
> +            if ( ret != 0 )
> +            {
> +                PT_LOG("Error: create new mapping failed!\n");
> +            }
>          }
> 
> -        ret = remove_msix_mapping(assigned_device, i);
> -        if ( ret != 0 )
> -            PT_LOG("Error: remove MSI-X mmio mapping failed!\n");
> -
>          if ( old_ebase != e_phys && old_ebase != -1 )
>              pt_msix_update_remap(assigned_device, i);
>      }

The two mapping and unmapping big chuncks of code looks very similar
apart from the DPCI_ADD_MAPPING/DPCI_REMOVE_MAPPING parameter.
Could they be refactored into a single function called "change_msix_mappings"?
This is more or less what I have in mind:

change_msix_mappings(assigned_device, DPCI_REMOVE_MAPPING);

update mmio_base_addr

change_msix_mappings(assigned_device, DPCI_ADD_MAPPING);


The rest looks OK to me.

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

From xen-devel-bounces@lists.xensource.com Fri Dec 02 12:41:52 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 12: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.xensource.com>)
	id 1RWSQm-0005p6-9f; Fri, 02 Dec 2011 12:41:32 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RWSQk-0005oi-P1
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 12:41:31 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1322829649!3814946!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTg0Mw==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28016 invoked from network); 2 Dec 2011 12:40:49 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Dec 2011 12:40:49 -0000
X-IronPort-AV: E=Sophos;i="4.71,283,1320624000"; 
   d="scan'208";a="9250117"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Dec 2011 12:40:48 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 2 Dec 2011 12:40:48 +0000
Date: Fri, 2 Dec 2011 12:41:46 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Jan Beulich <JBeulich@suse.com>
In-Reply-To: <4ED66C3B0200007800064709@nat28.tlf.novell.com>
Message-ID: <alpine.DEB.2.00.1112021240450.31179@kaball-desktop>
References: <4ED66C3B0200007800064709@nat28.tlf.novell.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Haitao Shan <haitao.shan@intel.com>
Subject: Re: [Xen-devel] Ping: qemu MSI-X handling patch disposition
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 30 Nov 2011, Jan Beulich wrote:
> Ian,
> 
> in http://lists.xensource.com/archives/html/xen-devel/2011-09/msg01161.html 
> Haitao proposed a patch to deal with an MSI-X security issue, which you
> never commented on but which also never got committed. What's the
> situation/plan here?

Thanks for remind us about this patch. I have just posted few comments
about it, but generally looks good.
I think it should go in, once the comments are addressed.

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

From xen-devel-bounces@lists.xensource.com Fri Dec 02 12:41:52 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 12: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.xensource.com>)
	id 1RWSQm-0005p6-9f; Fri, 02 Dec 2011 12:41:32 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RWSQk-0005oi-P1
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 12:41:31 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1322829649!3814946!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTg0Mw==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28016 invoked from network); 2 Dec 2011 12:40:49 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Dec 2011 12:40:49 -0000
X-IronPort-AV: E=Sophos;i="4.71,283,1320624000"; 
   d="scan'208";a="9250117"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Dec 2011 12:40:48 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 2 Dec 2011 12:40:48 +0000
Date: Fri, 2 Dec 2011 12:41:46 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Jan Beulich <JBeulich@suse.com>
In-Reply-To: <4ED66C3B0200007800064709@nat28.tlf.novell.com>
Message-ID: <alpine.DEB.2.00.1112021240450.31179@kaball-desktop>
References: <4ED66C3B0200007800064709@nat28.tlf.novell.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Haitao Shan <haitao.shan@intel.com>
Subject: Re: [Xen-devel] Ping: qemu MSI-X handling patch disposition
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 30 Nov 2011, Jan Beulich wrote:
> Ian,
> 
> in http://lists.xensource.com/archives/html/xen-devel/2011-09/msg01161.html 
> Haitao proposed a patch to deal with an MSI-X security issue, which you
> never commented on but which also never got committed. What's the
> situation/plan here?

Thanks for remind us about this patch. I have just posted few comments
about it, but generally looks good.
I think it should go in, once the comments are addressed.

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

From xen-devel-bounces@lists.xensource.com Fri Dec 02 13:16:32 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 13:16:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWSyG-0006wl-N2; Fri, 02 Dec 2011 13:16:08 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Wang2@amd.com>) id 1RWSyF-0006wg-3N
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 13:16:07 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1322831725!4007986!1
X-Originating-IP: [213.199.154.206]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21147 invoked from network); 2 Dec 2011 13:15:25 -0000
Received: from am1ehsobe003.messaging.microsoft.com (HELO
	AM1EHSOBE003.bigfish.com) (213.199.154.206)
	by server-11.tower-174.messagelabs.com with AES128-SHA encrypted SMTP;
	2 Dec 2011 13:15:25 -0000
Received: from mail10-am1-R.bigfish.com (10.3.201.254) by
	AM1EHSOBE003.bigfish.com (10.3.204.23) with Microsoft SMTP Server id
	14.1.225.22; Fri, 2 Dec 2011 13:15:25 +0000
Received: from mail10-am1 (localhost [127.0.0.1])	by mail10-am1-R.bigfish.com
	(Postfix) with ESMTP id 05BE21C05FF;
	Fri,  2 Dec 2011 13:15:24 +0000 (UTC)
X-SpamScore: -9
X-BigFish: VPS-9(zz1432N98dKzz1202hzz8275bhz2dh668h839h93fh)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
Received: from mail10-am1 (localhost.localdomain [127.0.0.1]) by mail10-am1
	(MessageSwitch) id 1322831602126606_6124;
	Fri,  2 Dec 2011 13:13:22 +0000 (UTC)
Received: from AM1EHSMHS005.bigfish.com (unknown [10.3.201.246])	by
	mail10-am1.bigfish.com (Postfix) with ESMTP id 18A5D3E0057;
	Fri,  2 Dec 2011 13:13:22 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	AM1EHSMHS005.bigfish.com (10.3.207.105) with Microsoft SMTP Server id
	14.1.225.22; Fri, 2 Dec 2011 13:13:17 +0000
X-WSS-ID: 0LVKVE1-01-9V5-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2732C1028155;	Fri,  2 Dec 2011 07:13:13 -0600 (CST)
Received: from SAUSEXDAG03.amd.com (163.181.55.3) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Fri, 2 Dec 2011 07:13:32 -0600
Received: from storexhtp01.amd.com (172.24.4.3) by sausexdag03.amd.com
	(163.181.55.3) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Fri, 2 Dec 2011 07:13:14 -0600
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp01.amd.com
	(172.24.4.3) with Microsoft SMTP Server id 8.3.213.0; Fri, 2 Dec 2011
	08:12:46 -0500
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id B196349C0F1; Fri,  2 Dec 2011
	13:12:45 +0000 (GMT)
Received: from gran.osrc.amd.com (gran.osrc.amd.com [165.204.15.57])	by
	mail.osrc.amd.com (Postfix) with ESMTP id 9A3235940FF; Fri,  2 Dec 2011
	14:12:45 +0100 (CET)
From: Wei Wang2 <wei.wang2@amd.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Fri, 2 Dec 2011 14:15:33 +0100
User-Agent: KMail/1.9.6 (enterprise 20070904.708012)
References: <16f5f59b-7d8e-4e8f-a178-be3f2ccf338a@sausexedgep01.amd.com>
In-Reply-To: <16f5f59b-7d8e-4e8f-a178-be3f2ccf338a@sausexedgep01.amd.com>
MIME-Version: 1.0
Content-Disposition: inline
Message-ID: <201112021415.34215.wei.wang2@amd.com>
X-OriginatorOrg: amd.com
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] AMD IOMMU v2: minor cleanup
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thursday 01 December 2011 12:56:36 Jan Beulich wrote:
> Despite this array living in an __init function, having such be an
> automatic variable is rather inefficient in terms of generated code.
>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>
> --- a/xen/drivers/passthrough/amd/iommu_detect.c
> +++ b/xen/drivers/passthrough/amd/iommu_detect.c
> @@ -66,7 +66,7 @@ void __init get_iommu_features(struct am
>  {
>      u32 low, high;
>      int i = 0 ;
> -    char * feature_str[] = {
> +    static const char *__initdata feature_str[] = {
>          "- Prefetch Pages Command",
>          "- Peripheral Page Service Request",
>          "- X2APIC Supported",


Acked, thanks,
Wei


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

From xen-devel-bounces@lists.xensource.com Fri Dec 02 13:16:32 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 13:16:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWSyG-0006wl-N2; Fri, 02 Dec 2011 13:16:08 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Wang2@amd.com>) id 1RWSyF-0006wg-3N
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 13:16:07 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1322831725!4007986!1
X-Originating-IP: [213.199.154.206]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21147 invoked from network); 2 Dec 2011 13:15:25 -0000
Received: from am1ehsobe003.messaging.microsoft.com (HELO
	AM1EHSOBE003.bigfish.com) (213.199.154.206)
	by server-11.tower-174.messagelabs.com with AES128-SHA encrypted SMTP;
	2 Dec 2011 13:15:25 -0000
Received: from mail10-am1-R.bigfish.com (10.3.201.254) by
	AM1EHSOBE003.bigfish.com (10.3.204.23) with Microsoft SMTP Server id
	14.1.225.22; Fri, 2 Dec 2011 13:15:25 +0000
Received: from mail10-am1 (localhost [127.0.0.1])	by mail10-am1-R.bigfish.com
	(Postfix) with ESMTP id 05BE21C05FF;
	Fri,  2 Dec 2011 13:15:24 +0000 (UTC)
X-SpamScore: -9
X-BigFish: VPS-9(zz1432N98dKzz1202hzz8275bhz2dh668h839h93fh)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
Received: from mail10-am1 (localhost.localdomain [127.0.0.1]) by mail10-am1
	(MessageSwitch) id 1322831602126606_6124;
	Fri,  2 Dec 2011 13:13:22 +0000 (UTC)
Received: from AM1EHSMHS005.bigfish.com (unknown [10.3.201.246])	by
	mail10-am1.bigfish.com (Postfix) with ESMTP id 18A5D3E0057;
	Fri,  2 Dec 2011 13:13:22 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	AM1EHSMHS005.bigfish.com (10.3.207.105) with Microsoft SMTP Server id
	14.1.225.22; Fri, 2 Dec 2011 13:13:17 +0000
X-WSS-ID: 0LVKVE1-01-9V5-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2732C1028155;	Fri,  2 Dec 2011 07:13:13 -0600 (CST)
Received: from SAUSEXDAG03.amd.com (163.181.55.3) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Fri, 2 Dec 2011 07:13:32 -0600
Received: from storexhtp01.amd.com (172.24.4.3) by sausexdag03.amd.com
	(163.181.55.3) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Fri, 2 Dec 2011 07:13:14 -0600
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp01.amd.com
	(172.24.4.3) with Microsoft SMTP Server id 8.3.213.0; Fri, 2 Dec 2011
	08:12:46 -0500
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id B196349C0F1; Fri,  2 Dec 2011
	13:12:45 +0000 (GMT)
Received: from gran.osrc.amd.com (gran.osrc.amd.com [165.204.15.57])	by
	mail.osrc.amd.com (Postfix) with ESMTP id 9A3235940FF; Fri,  2 Dec 2011
	14:12:45 +0100 (CET)
From: Wei Wang2 <wei.wang2@amd.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Fri, 2 Dec 2011 14:15:33 +0100
User-Agent: KMail/1.9.6 (enterprise 20070904.708012)
References: <16f5f59b-7d8e-4e8f-a178-be3f2ccf338a@sausexedgep01.amd.com>
In-Reply-To: <16f5f59b-7d8e-4e8f-a178-be3f2ccf338a@sausexedgep01.amd.com>
MIME-Version: 1.0
Content-Disposition: inline
Message-ID: <201112021415.34215.wei.wang2@amd.com>
X-OriginatorOrg: amd.com
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] AMD IOMMU v2: minor cleanup
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thursday 01 December 2011 12:56:36 Jan Beulich wrote:
> Despite this array living in an __init function, having such be an
> automatic variable is rather inefficient in terms of generated code.
>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>
> --- a/xen/drivers/passthrough/amd/iommu_detect.c
> +++ b/xen/drivers/passthrough/amd/iommu_detect.c
> @@ -66,7 +66,7 @@ void __init get_iommu_features(struct am
>  {
>      u32 low, high;
>      int i = 0 ;
> -    char * feature_str[] = {
> +    static const char *__initdata feature_str[] = {
>          "- Prefetch Pages Command",
>          "- Peripheral Page Service Request",
>          "- X2APIC Supported",


Acked, thanks,
Wei


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

From xen-devel-bounces@lists.xensource.com Fri Dec 02 14:04:32 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 14:04:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWTiW-0007LB-Jz; Fri, 02 Dec 2011 14:03:56 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RWTiV-0007L3-4V
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 14:03:55 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1322834592!395569!1
X-Originating-IP: [209.85.161.171]
X-SpamReason: No, hits=1.1 required=7.0 tests=DATE_IN_PAST_06_12,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2613 invoked from network); 2 Dec 2011 14:03:14 -0000
Received: from mail-gx0-f171.google.com (HELO mail-gx0-f171.google.com)
	(209.85.161.171)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Dec 2011 14:03:14 -0000
Received: by ggnr4 with SMTP id r4so21252803ggn.30
	for <xen-devel@lists.xensource.com>;
	Fri, 02 Dec 2011 06:03:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type;
	bh=gkqVXdiwoqOGkwEa4vGu6fyNoEsiRD+HKifLYm+It1M=;
	b=riH8VaRzuwoxTjC24j7lnkHBnjCYcohsgQvGbE8QSpsvI3fOvqMiqnaU1iKX4gMbas
	KJGCnwdpXo/7cglJGN6o0/pWH0O8/HoiLaDLN7gb6UbxyaR3WMqfU0Hpdqr2bzBdw6Oq
	jFwE2gVVyBVkwSm/2azL8uOwxpnFUWzm2HkPg=
Received: by 10.182.218.100 with SMTP id pf4mr2411775obc.12.1322834592722;
	Fri, 02 Dec 2011 06:03:12 -0800 (PST)
Received: from [10.68.4.99] ([96.49.152.177])
	by mx.google.com with ESMTPS id q10sm319873obv.1.2011.12.02.06.03.03
	(version=SSLv3 cipher=OTHER); Fri, 02 Dec 2011 06:03:11 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Fri, 02 Dec 2011 06:02:59 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <CAFE1A94.26526%keir.xen@gmail.com>
Thread-Topic: tools/libxc/xc_cpuid_x86.c:cpuid()'s inline asm
Thread-Index: Acyw+xkFFSZ8JDir6kG38zuEMlMZvg==
In-Reply-To: <4ED8A05A0200007800065020@nat28.tlf.novell.com>
Mime-version: 1.0
Content-type: multipart/mixed;
	boundary="B_3405650588_8908001"
Cc: Olaf Hering <olaf@aepfle.de>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] tools/libxc/xc_cpuid_x86.c:cpuid()'s inline asm
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3405650588_8908001
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit

On 02/12/2011 08:54, "Jan Beulich" <JBeulich@suse.com> wrote:

> Keir,
> 
> do you recall what it was that 20976:f8692cc67d67 was supposed to fix?
> The code is clearly wrong now on x86-64 - inline asm that uses push/pop
> (or other stack pointer manipulation instructions) and memory accesses
> that may reference the stack (even if not through %rsp) can't be
> expected to work without -mno-red-zone.

I totally missed the red-zone constraint. :-(

> The question is whether to use that command line option, or whether to
> correct the inline assembly (besides the purpose of your change, I also
> wonder why this isn't coded the obvious way, with rBX and rDX explicitly
> named in the constraints - on 32-bit this may be to reduce register
> pressure, but on 64-bit it's entirely unclear).

I think reg constraint failures had only been reported on 32-bit. So how
about the attached patch?

 -- Keir

> Thanks, Jan
> 


--B_3405650588_8908001
Content-type: application/octet-stream; name="00-cpuid-asm"
Content-disposition: attachment;
	filename="00-cpuid-asm"
Content-transfer-encoding: base64


ZGlmZiAtciA3NzFlMmEzMDM3NTMgdG9vbHMvbGlieGMveGNfY3B1aWRfeDg2LmMKLS0tIGEv
dG9vbHMvbGlieGMveGNfY3B1aWRfeDg2LmMJRnJpIERlYyAwMiAxNDoyMjo0NyAyMDExICsw
MTAwCisrKyBiL3Rvb2xzL2xpYnhjL3hjX2NwdWlkX3g4Ni5jCUZyaSBEZWMgMDIgMDU6NTk6
NDQgMjAxMSAtMDgwMApAQCAtNDMsMjMgKzQzLDIzIEBAIHN0YXRpYyBpbnQgaHlwZXJ2aXNv
cl9pc182NGJpdCh4Y19pbnRlcmYKIHN0YXRpYyB2b2lkIGNwdWlkKGNvbnN0IHVuc2lnbmVk
IGludCAqaW5wdXQsIHVuc2lnbmVkIGludCAqcmVncykKIHsKICAgICB1bnNpZ25lZCBpbnQg
Y291bnQgPSAoaW5wdXRbMV0gPT0gWEVOX0NQVUlEX0lOUFVUX1VOVVNFRCkgPyAwIDogaW5w
dXRbMV07CisjaWZkZWYgX19pMzg2X18KKyAgICAvKiBVc2UgdGhlIHN0YWNrIHRvIGF2b2lk
IHJlZyBjb25zdHJhaW50IGZhaWx1cmVzIHdpdGggc29tZSBnY2MgZmxhZ3MgKi8KICAgICBh
c20gKAotI2lmZGVmIF9faTM4Nl9fCiAgICAgICAgICJwdXNoICUlZWJ4OyBwdXNoICUlZWR4
XG5cdCIKLSNlbHNlCi0gICAgICAgICJwdXNoICUlcmJ4OyBwdXNoICUlcmR4XG5cdCIKLSNl
bmRpZgogICAgICAgICAiY3B1aWRcblx0IgogICAgICAgICAibW92ICUlZWJ4LDQoJTQpXG5c
dCIKICAgICAgICAgIm1vdiAlJWVkeCwxMiglNClcblx0IgotI2lmZGVmIF9faTM4Nl9fCiAg
ICAgICAgICJwb3AgJSVlZHg7IHBvcCAlJWVieFxuXHQiCisgICAgICAgIDogIj1hIiAocmVn
c1swXSksICI9YyIgKHJlZ3NbMl0pCisgICAgICAgIDogIjAiIChpbnB1dFswXSksICIxIiAo
Y291bnQpLCAiUyIgKF9yZWdzKQorICAgICAgICA6ICJtZW1vcnkiICk7CiAjZWxzZQotICAg
ICAgICAicG9wICUlcmR4OyBwb3AgJSVyYnhcblx0IgorICAgIGFzbSAoCisgICAgICAgICJj
cHVpZCIKKyAgICAgICAgOiAiPWEiIChyZWdzWzBdKSwgIj1iIiAocmVnc1sxXSksICI9YyIg
KHJlZ3NbMl0pLCAiPWQiIChyZWdzWzNdKQorICAgICAgICA6ICIwIiAoaW5wdXRbMF0pLCAi
MiIgKGNvdW50KSApOwogI2VuZGlmCi0gICAgICAgIDogIj1hIiAocmVnc1swXSksICI9YyIg
KHJlZ3NbMl0pCi0gICAgICAgIDogIjAiIChpbnB1dFswXSksICIxIiAoY291bnQpLCAiUyIg
KHJlZ3MpCi0gICAgICAgIDogIm1lbW9yeSIgKTsKIH0KIAogLyogR2V0IHRoZSBtYW51ZmFj
dHVyZXIgYnJhbmQgbmFtZSBvZiB0aGUgaG9zdCBwcm9jZXNzb3IuICovCmRpZmYgLXIgNzcx
ZTJhMzAzNzUzIHRvb2xzL21pc2MveGVuLWRldGVjdC5jCi0tLSBhL3Rvb2xzL21pc2MveGVu
LWRldGVjdC5jCUZyaSBEZWMgMDIgMTQ6MjI6NDcgMjAxMSArMDEwMAorKysgYi90b29scy9t
aXNjL3hlbi1kZXRlY3QuYwlGcmkgRGVjIDAyIDA1OjU5OjQ0IDIwMTEgLTA4MDAKQEAgLTM1
LDE4ICszNSwyMSBAQAogCiBzdGF0aWMgdm9pZCBjcHVpZCh1aW50MzJfdCBpZHgsIHVpbnQz
Ml90ICpyZWdzLCBpbnQgcHZfY29udGV4dCkKIHsKKyNpZmRlZiBfX2kzODZfXworICAgIC8q
IFVzZSB0aGUgc3RhY2sgdG8gYXZvaWQgcmVnIGNvbnN0cmFpbnQgZmFpbHVyZXMgd2l0aCBz
b21lIGdjYyBmbGFncyAqLwogICAgIGFzbSB2b2xhdGlsZSAoCi0jaWZkZWYgX19pMzg2X18K
LSNkZWZpbmUgUih4KSAiJSVlIiN4IngiCi0jZWxzZQotI2RlZmluZSBSKHgpICIlJXIiI3gi
eCIKLSNlbmRpZgotICAgICAgICAicHVzaCAiUihhKSI7IHB1c2ggIlIoYikiOyBwdXNoICJS
KGMpIjsgcHVzaCAiUihkKSJcblx0IgorICAgICAgICAicHVzaCAlJWVheDsgcHVzaCAlJWVi
eDsgcHVzaCAlJWVjeDsgcHVzaCAlJWVkeFxuXHQiCiAgICAgICAgICJ0ZXN0ICUxLCUxIDsg
anogMWYgOyB1ZDJhIDsgLmFzY2lpIFwieGVuXCIgOyAxOiBjcHVpZFxuXHQiCiAgICAgICAg
ICJtb3YgJSVlYXgsKCUyKTsgbW92ICUlZWJ4LDQoJTIpXG5cdCIKICAgICAgICAgIm1vdiAl
JWVjeCw4KCUyKTsgbW92ICUlZWR4LDEyKCUyKVxuXHQiCi0gICAgICAgICJwb3AgIlIoZCki
OyBwb3AgIlIoYykiOyBwb3AgIlIoYikiOyBwb3AgIlIoYSkiXG5cdCIKKyAgICAgICAgInBv
cCAlJWVkeDsgcG9wICUlZWN4OyBwb3AgJSVlYng7IHBvcCAlJWVheFxuXHQiCiAgICAgICAg
IDogOiAiYSIgKGlkeCksICJjIiAocHZfY29udGV4dCksICJTIiAocmVncykgOiAibWVtb3J5
IiApOworI2Vsc2UKKyAgICBhc20gdm9sYXRpbGUgKAorICAgICAgICAidGVzdCAlNSwlNSA7
IGp6IDFmIDsgdWQyYSA7IC5hc2NpaSBcInhlblwiIDsgMTogY3B1aWRcblx0IgorICAgICAg
ICA6ICI9YSIgKHJlZ3NbMF0pLCAiPWIiIChyZWdzWzFdKSwgIj1jIiAocmVnc1syXSksICI9
ZCIgKHJlZ3NbM10pCisgICAgICAgIDogIjAiIChpZHgpLCAiMSIgKHB2X2NvbnRleHQpLCAi
MiIgKDApICk7CisjZW5kaWYKIH0KIAogc3RhdGljIGludCBjaGVja19mb3JfeGVuKGludCBw
dl9jb250ZXh0KQo=
--B_3405650588_8908001
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--B_3405650588_8908001--




From xen-devel-bounces@lists.xensource.com Fri Dec 02 14:04:32 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 14:04:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWTiW-0007LB-Jz; Fri, 02 Dec 2011 14:03:56 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RWTiV-0007L3-4V
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 14:03:55 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1322834592!395569!1
X-Originating-IP: [209.85.161.171]
X-SpamReason: No, hits=1.1 required=7.0 tests=DATE_IN_PAST_06_12,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2613 invoked from network); 2 Dec 2011 14:03:14 -0000
Received: from mail-gx0-f171.google.com (HELO mail-gx0-f171.google.com)
	(209.85.161.171)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Dec 2011 14:03:14 -0000
Received: by ggnr4 with SMTP id r4so21252803ggn.30
	for <xen-devel@lists.xensource.com>;
	Fri, 02 Dec 2011 06:03:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type;
	bh=gkqVXdiwoqOGkwEa4vGu6fyNoEsiRD+HKifLYm+It1M=;
	b=riH8VaRzuwoxTjC24j7lnkHBnjCYcohsgQvGbE8QSpsvI3fOvqMiqnaU1iKX4gMbas
	KJGCnwdpXo/7cglJGN6o0/pWH0O8/HoiLaDLN7gb6UbxyaR3WMqfU0Hpdqr2bzBdw6Oq
	jFwE2gVVyBVkwSm/2azL8uOwxpnFUWzm2HkPg=
Received: by 10.182.218.100 with SMTP id pf4mr2411775obc.12.1322834592722;
	Fri, 02 Dec 2011 06:03:12 -0800 (PST)
Received: from [10.68.4.99] ([96.49.152.177])
	by mx.google.com with ESMTPS id q10sm319873obv.1.2011.12.02.06.03.03
	(version=SSLv3 cipher=OTHER); Fri, 02 Dec 2011 06:03:11 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Fri, 02 Dec 2011 06:02:59 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <CAFE1A94.26526%keir.xen@gmail.com>
Thread-Topic: tools/libxc/xc_cpuid_x86.c:cpuid()'s inline asm
Thread-Index: Acyw+xkFFSZ8JDir6kG38zuEMlMZvg==
In-Reply-To: <4ED8A05A0200007800065020@nat28.tlf.novell.com>
Mime-version: 1.0
Content-type: multipart/mixed;
	boundary="B_3405650588_8908001"
Cc: Olaf Hering <olaf@aepfle.de>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] tools/libxc/xc_cpuid_x86.c:cpuid()'s inline asm
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3405650588_8908001
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit

On 02/12/2011 08:54, "Jan Beulich" <JBeulich@suse.com> wrote:

> Keir,
> 
> do you recall what it was that 20976:f8692cc67d67 was supposed to fix?
> The code is clearly wrong now on x86-64 - inline asm that uses push/pop
> (or other stack pointer manipulation instructions) and memory accesses
> that may reference the stack (even if not through %rsp) can't be
> expected to work without -mno-red-zone.

I totally missed the red-zone constraint. :-(

> The question is whether to use that command line option, or whether to
> correct the inline assembly (besides the purpose of your change, I also
> wonder why this isn't coded the obvious way, with rBX and rDX explicitly
> named in the constraints - on 32-bit this may be to reduce register
> pressure, but on 64-bit it's entirely unclear).

I think reg constraint failures had only been reported on 32-bit. So how
about the attached patch?

 -- Keir

> Thanks, Jan
> 


--B_3405650588_8908001
Content-type: application/octet-stream; name="00-cpuid-asm"
Content-disposition: attachment;
	filename="00-cpuid-asm"
Content-transfer-encoding: base64


ZGlmZiAtciA3NzFlMmEzMDM3NTMgdG9vbHMvbGlieGMveGNfY3B1aWRfeDg2LmMKLS0tIGEv
dG9vbHMvbGlieGMveGNfY3B1aWRfeDg2LmMJRnJpIERlYyAwMiAxNDoyMjo0NyAyMDExICsw
MTAwCisrKyBiL3Rvb2xzL2xpYnhjL3hjX2NwdWlkX3g4Ni5jCUZyaSBEZWMgMDIgMDU6NTk6
NDQgMjAxMSAtMDgwMApAQCAtNDMsMjMgKzQzLDIzIEBAIHN0YXRpYyBpbnQgaHlwZXJ2aXNv
cl9pc182NGJpdCh4Y19pbnRlcmYKIHN0YXRpYyB2b2lkIGNwdWlkKGNvbnN0IHVuc2lnbmVk
IGludCAqaW5wdXQsIHVuc2lnbmVkIGludCAqcmVncykKIHsKICAgICB1bnNpZ25lZCBpbnQg
Y291bnQgPSAoaW5wdXRbMV0gPT0gWEVOX0NQVUlEX0lOUFVUX1VOVVNFRCkgPyAwIDogaW5w
dXRbMV07CisjaWZkZWYgX19pMzg2X18KKyAgICAvKiBVc2UgdGhlIHN0YWNrIHRvIGF2b2lk
IHJlZyBjb25zdHJhaW50IGZhaWx1cmVzIHdpdGggc29tZSBnY2MgZmxhZ3MgKi8KICAgICBh
c20gKAotI2lmZGVmIF9faTM4Nl9fCiAgICAgICAgICJwdXNoICUlZWJ4OyBwdXNoICUlZWR4
XG5cdCIKLSNlbHNlCi0gICAgICAgICJwdXNoICUlcmJ4OyBwdXNoICUlcmR4XG5cdCIKLSNl
bmRpZgogICAgICAgICAiY3B1aWRcblx0IgogICAgICAgICAibW92ICUlZWJ4LDQoJTQpXG5c
dCIKICAgICAgICAgIm1vdiAlJWVkeCwxMiglNClcblx0IgotI2lmZGVmIF9faTM4Nl9fCiAg
ICAgICAgICJwb3AgJSVlZHg7IHBvcCAlJWVieFxuXHQiCisgICAgICAgIDogIj1hIiAocmVn
c1swXSksICI9YyIgKHJlZ3NbMl0pCisgICAgICAgIDogIjAiIChpbnB1dFswXSksICIxIiAo
Y291bnQpLCAiUyIgKF9yZWdzKQorICAgICAgICA6ICJtZW1vcnkiICk7CiAjZWxzZQotICAg
ICAgICAicG9wICUlcmR4OyBwb3AgJSVyYnhcblx0IgorICAgIGFzbSAoCisgICAgICAgICJj
cHVpZCIKKyAgICAgICAgOiAiPWEiIChyZWdzWzBdKSwgIj1iIiAocmVnc1sxXSksICI9YyIg
KHJlZ3NbMl0pLCAiPWQiIChyZWdzWzNdKQorICAgICAgICA6ICIwIiAoaW5wdXRbMF0pLCAi
MiIgKGNvdW50KSApOwogI2VuZGlmCi0gICAgICAgIDogIj1hIiAocmVnc1swXSksICI9YyIg
KHJlZ3NbMl0pCi0gICAgICAgIDogIjAiIChpbnB1dFswXSksICIxIiAoY291bnQpLCAiUyIg
KHJlZ3MpCi0gICAgICAgIDogIm1lbW9yeSIgKTsKIH0KIAogLyogR2V0IHRoZSBtYW51ZmFj
dHVyZXIgYnJhbmQgbmFtZSBvZiB0aGUgaG9zdCBwcm9jZXNzb3IuICovCmRpZmYgLXIgNzcx
ZTJhMzAzNzUzIHRvb2xzL21pc2MveGVuLWRldGVjdC5jCi0tLSBhL3Rvb2xzL21pc2MveGVu
LWRldGVjdC5jCUZyaSBEZWMgMDIgMTQ6MjI6NDcgMjAxMSArMDEwMAorKysgYi90b29scy9t
aXNjL3hlbi1kZXRlY3QuYwlGcmkgRGVjIDAyIDA1OjU5OjQ0IDIwMTEgLTA4MDAKQEAgLTM1
LDE4ICszNSwyMSBAQAogCiBzdGF0aWMgdm9pZCBjcHVpZCh1aW50MzJfdCBpZHgsIHVpbnQz
Ml90ICpyZWdzLCBpbnQgcHZfY29udGV4dCkKIHsKKyNpZmRlZiBfX2kzODZfXworICAgIC8q
IFVzZSB0aGUgc3RhY2sgdG8gYXZvaWQgcmVnIGNvbnN0cmFpbnQgZmFpbHVyZXMgd2l0aCBz
b21lIGdjYyBmbGFncyAqLwogICAgIGFzbSB2b2xhdGlsZSAoCi0jaWZkZWYgX19pMzg2X18K
LSNkZWZpbmUgUih4KSAiJSVlIiN4IngiCi0jZWxzZQotI2RlZmluZSBSKHgpICIlJXIiI3gi
eCIKLSNlbmRpZgotICAgICAgICAicHVzaCAiUihhKSI7IHB1c2ggIlIoYikiOyBwdXNoICJS
KGMpIjsgcHVzaCAiUihkKSJcblx0IgorICAgICAgICAicHVzaCAlJWVheDsgcHVzaCAlJWVi
eDsgcHVzaCAlJWVjeDsgcHVzaCAlJWVkeFxuXHQiCiAgICAgICAgICJ0ZXN0ICUxLCUxIDsg
anogMWYgOyB1ZDJhIDsgLmFzY2lpIFwieGVuXCIgOyAxOiBjcHVpZFxuXHQiCiAgICAgICAg
ICJtb3YgJSVlYXgsKCUyKTsgbW92ICUlZWJ4LDQoJTIpXG5cdCIKICAgICAgICAgIm1vdiAl
JWVjeCw4KCUyKTsgbW92ICUlZWR4LDEyKCUyKVxuXHQiCi0gICAgICAgICJwb3AgIlIoZCki
OyBwb3AgIlIoYykiOyBwb3AgIlIoYikiOyBwb3AgIlIoYSkiXG5cdCIKKyAgICAgICAgInBv
cCAlJWVkeDsgcG9wICUlZWN4OyBwb3AgJSVlYng7IHBvcCAlJWVheFxuXHQiCiAgICAgICAg
IDogOiAiYSIgKGlkeCksICJjIiAocHZfY29udGV4dCksICJTIiAocmVncykgOiAibWVtb3J5
IiApOworI2Vsc2UKKyAgICBhc20gdm9sYXRpbGUgKAorICAgICAgICAidGVzdCAlNSwlNSA7
IGp6IDFmIDsgdWQyYSA7IC5hc2NpaSBcInhlblwiIDsgMTogY3B1aWRcblx0IgorICAgICAg
ICA6ICI9YSIgKHJlZ3NbMF0pLCAiPWIiIChyZWdzWzFdKSwgIj1jIiAocmVnc1syXSksICI9
ZCIgKHJlZ3NbM10pCisgICAgICAgIDogIjAiIChpZHgpLCAiMSIgKHB2X2NvbnRleHQpLCAi
MiIgKDApICk7CisjZW5kaWYKIH0KIAogc3RhdGljIGludCBjaGVja19mb3JfeGVuKGludCBw
dl9jb250ZXh0KQo=
--B_3405650588_8908001
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--B_3405650588_8908001--




From xen-devel-bounces@lists.xensource.com Fri Dec 02 14:21:40 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 14:21:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWTz6-0007Wp-EG; Fri, 02 Dec 2011 14:21:04 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RWTz4-0007Wk-IL
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 14:21:02 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1322835609!48010414!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQyOTg=\n
X-StarScan-Version: 6.4.2; banners=-,-,lists.xensource.com
X-VirusChecked: Checked
Received: (qmail 15935 invoked from network); 2 Dec 2011 14:20:10 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-11.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 2 Dec 2011 14:20:10 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 02 Dec 2011 14:20:25 +0000
Message-Id: <4ED8ECB8020000780006514F@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 02 Dec 2011 14:20:24 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Keir Fraser" <keir.xen@gmail.com>
References: <4ED8A05A0200007800065020@nat28.tlf.novell.com>
	<CAFE1A94.26526%keir.xen@gmail.com>
In-Reply-To: <CAFE1A94.26526%keir.xen@gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Olaf Hering <olaf@aepfle.de>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] tools/libxc/xc_cpuid_x86.c:cpuid()'s inline asm
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 02.12.11 at 07:02, Keir Fraser <keir.xen@gmail.com> wrote:
> On 02/12/2011 08:54, "Jan Beulich" <JBeulich@suse.com> wrote:
>> The question is whether to use that command line option, or whether to
>> correct the inline assembly (besides the purpose of your change, I also
>> wonder why this isn't coded the obvious way, with rBX and rDX explicitly
>> named in the constraints - on 32-bit this may be to reduce register
>> pressure, but on 64-bit it's entirely unclear).
> 
> I think reg constraint failures had only been reported on 32-bit. So how
> about the attached patch?

Looks good.

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

While we only got problems with this on 4.1.2, I would suggest to also
put this back into 4.0-testing.

Thanks, Jan


E-mail confidentiality notice.  This message is intended for the addressees only.  It may be private, confidential and may be covered by legal professional privilege or other confidentiality requirements.  If you are not one of the intended recipients, please notify the sender immediately on +44 0 20-8215-3000 and delete the message from all locations in your computer network.  Do not copy this email or use it for any purpose or disclose its contents to any person:to do so maybe unlawful.

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

From xen-devel-bounces@lists.xensource.com Fri Dec 02 14:21:40 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 14:21:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWTz6-0007Wp-EG; Fri, 02 Dec 2011 14:21:04 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RWTz4-0007Wk-IL
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 14:21:02 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1322835609!48010414!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQyOTg=\n
X-StarScan-Version: 6.4.2; banners=-,-,lists.xensource.com
X-VirusChecked: Checked
Received: (qmail 15935 invoked from network); 2 Dec 2011 14:20:10 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-11.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 2 Dec 2011 14:20:10 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 02 Dec 2011 14:20:25 +0000
Message-Id: <4ED8ECB8020000780006514F@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 02 Dec 2011 14:20:24 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Keir Fraser" <keir.xen@gmail.com>
References: <4ED8A05A0200007800065020@nat28.tlf.novell.com>
	<CAFE1A94.26526%keir.xen@gmail.com>
In-Reply-To: <CAFE1A94.26526%keir.xen@gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Olaf Hering <olaf@aepfle.de>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] tools/libxc/xc_cpuid_x86.c:cpuid()'s inline asm
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 02.12.11 at 07:02, Keir Fraser <keir.xen@gmail.com> wrote:
> On 02/12/2011 08:54, "Jan Beulich" <JBeulich@suse.com> wrote:
>> The question is whether to use that command line option, or whether to
>> correct the inline assembly (besides the purpose of your change, I also
>> wonder why this isn't coded the obvious way, with rBX and rDX explicitly
>> named in the constraints - on 32-bit this may be to reduce register
>> pressure, but on 64-bit it's entirely unclear).
> 
> I think reg constraint failures had only been reported on 32-bit. So how
> about the attached patch?

Looks good.

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

While we only got problems with this on 4.1.2, I would suggest to also
put this back into 4.0-testing.

Thanks, Jan


E-mail confidentiality notice.  This message is intended for the addressees only.  It may be private, confidential and may be covered by legal professional privilege or other confidentiality requirements.  If you are not one of the intended recipients, please notify the sender immediately on +44 0 20-8215-3000 and delete the message from all locations in your computer network.  Do not copy this email or use it for any purpose or disclose its contents to any person:to do so maybe unlawful.

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

From xen-devel-bounces@lists.xensource.com Fri Dec 02 14:27:41 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 14:27:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWU50-0007hR-DH; Fri, 02 Dec 2011 14:27:10 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1RWU4y-0007hL-5j
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 14:27:08 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-13.tower-21.messagelabs.com!1322835985!4731913!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29920 invoked from network); 2 Dec 2011 14:26:27 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-13.tower-21.messagelabs.com with AES256-SHA encrypted SMTP;
	2 Dec 2011 14:26:27 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1RWU4H-0004wI-35
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 06:26:25 -0800
Date: Fri, 2 Dec 2011 06:26:25 -0800 (PST)
From: Fantu <fantonifabio@tiscali.it>
To: xen-devel@lists.xensource.com
Message-ID: <1322835985069-5041988.post@n5.nabble.com>
MIME-Version: 1.0
Subject: [Xen-devel] Nvidia SLI multi os and Xen
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

http://www.nvidia.com/object/sli_multi_os.html Nvidia SLI multi os  for
assign one Quadro graphic card to multiple domU is possible also in Xen or
only in parallels for now?
Thanks for any reply

--
View this message in context: http://xen.1045712.n5.nabble.com/Nvidia-SLI-multi-os-and-Xen-tp5041988p5041988.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

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

From xen-devel-bounces@lists.xensource.com Fri Dec 02 14:27:41 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 14:27:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWU50-0007hR-DH; Fri, 02 Dec 2011 14:27:10 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1RWU4y-0007hL-5j
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 14:27:08 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-13.tower-21.messagelabs.com!1322835985!4731913!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29920 invoked from network); 2 Dec 2011 14:26:27 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-13.tower-21.messagelabs.com with AES256-SHA encrypted SMTP;
	2 Dec 2011 14:26:27 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1RWU4H-0004wI-35
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 06:26:25 -0800
Date: Fri, 2 Dec 2011 06:26:25 -0800 (PST)
From: Fantu <fantonifabio@tiscali.it>
To: xen-devel@lists.xensource.com
Message-ID: <1322835985069-5041988.post@n5.nabble.com>
MIME-Version: 1.0
Subject: [Xen-devel] Nvidia SLI multi os and Xen
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

http://www.nvidia.com/object/sli_multi_os.html Nvidia SLI multi os  for
assign one Quadro graphic card to multiple domU is possible also in Xen or
only in parallels for now?
Thanks for any reply

--
View this message in context: http://xen.1045712.n5.nabble.com/Nvidia-SLI-multi-os-and-Xen-tp5041988p5041988.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

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

From xen-devel-bounces@lists.xensource.com Fri Dec 02 14:36:30 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 14:36:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWUDW-0007w1-Ga; Fri, 02 Dec 2011 14:35:58 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RWUDU-0007vt-W5
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 14:35:57 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1322836513!5657443!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjg1NDY=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27579 invoked from network); 2 Dec 2011 14:35:15 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Dec 2011 14:35:15 -0000
X-IronPort-AV: E=Sophos;i="4.71,283,1320642000"; d="scan'208";a="172682515"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Dec 2011 09:35:12 -0500
Received: from cosworth.uk.xensource.com (10.80.16.52) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 2 Dec 2011 09:35:12 -0500
MIME-Version: 1.0
X-Mercurial-Node: c661ed4d21fc824443237fa3e4bf88546ea92b27
Message-ID: <c661ed4d21fc82444323.1322836496@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 2 Dec 2011 14:34:56 +0000
From: Paul Durrant <paul.durrant@citrix.com>
To: xen-devel@lists.xensource.com
Cc: paul.durrant@citrix.com
Subject: [Xen-devel] [PATCH] Change VM Generation Id Device HID
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Paul Durrant <paul.durrant@citrix.com>
# Date 1322836489 0
# Node ID c661ed4d21fc824443237fa3e4bf88546ea92b27
# Parent  62ff6a318c5db7779fdbf4ddfdfc9506e86fa701
Change VM Generation Id Device HID.

Unfortunately a HID of PNP0A06 will not work for an existing client driver so
this patch aims to choose something that's pretty certain not to class with
anything else.

Signed-off-by: Paul Durrant <paul.durrant@citrix.com>

diff -r 62ff6a318c5d -r c661ed4d21fc tools/firmware/hvmloader/acpi/dsdt.asl
--- a/tools/firmware/hvmloader/acpi/dsdt.asl	Wed Nov 30 16:59:58 2011 -0800
+++ b/tools/firmware/hvmloader/acpi/dsdt.asl	Fri Dec 02 14:34:49 2011 +0000
@@ -399,7 +399,7 @@ DefinitionBlock ("DSDT.aml", "DSDT", 2, 
                 } 
 
                 Device(VGID) {
-                    Name(_HID, EisaID ("PNP0A06"))
+                    Name(_HID, EisaID ("XEN0000"))
                     Name(_UID, 0x00)
                     Name(_CID, "VM_Gen_Counter")
                     Name(_DDN, "VM_Gen_Counter")

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

From xen-devel-bounces@lists.xensource.com Fri Dec 02 14:36:30 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 14:36:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWUDW-0007w1-Ga; Fri, 02 Dec 2011 14:35:58 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RWUDU-0007vt-W5
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 14:35:57 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1322836513!5657443!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjg1NDY=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27579 invoked from network); 2 Dec 2011 14:35:15 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Dec 2011 14:35:15 -0000
X-IronPort-AV: E=Sophos;i="4.71,283,1320642000"; d="scan'208";a="172682515"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Dec 2011 09:35:12 -0500
Received: from cosworth.uk.xensource.com (10.80.16.52) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 2 Dec 2011 09:35:12 -0500
MIME-Version: 1.0
X-Mercurial-Node: c661ed4d21fc824443237fa3e4bf88546ea92b27
Message-ID: <c661ed4d21fc82444323.1322836496@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 2 Dec 2011 14:34:56 +0000
From: Paul Durrant <paul.durrant@citrix.com>
To: xen-devel@lists.xensource.com
Cc: paul.durrant@citrix.com
Subject: [Xen-devel] [PATCH] Change VM Generation Id Device HID
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Paul Durrant <paul.durrant@citrix.com>
# Date 1322836489 0
# Node ID c661ed4d21fc824443237fa3e4bf88546ea92b27
# Parent  62ff6a318c5db7779fdbf4ddfdfc9506e86fa701
Change VM Generation Id Device HID.

Unfortunately a HID of PNP0A06 will not work for an existing client driver so
this patch aims to choose something that's pretty certain not to class with
anything else.

Signed-off-by: Paul Durrant <paul.durrant@citrix.com>

diff -r 62ff6a318c5d -r c661ed4d21fc tools/firmware/hvmloader/acpi/dsdt.asl
--- a/tools/firmware/hvmloader/acpi/dsdt.asl	Wed Nov 30 16:59:58 2011 -0800
+++ b/tools/firmware/hvmloader/acpi/dsdt.asl	Fri Dec 02 14:34:49 2011 +0000
@@ -399,7 +399,7 @@ DefinitionBlock ("DSDT.aml", "DSDT", 2, 
                 } 
 
                 Device(VGID) {
-                    Name(_HID, EisaID ("PNP0A06"))
+                    Name(_HID, EisaID ("XEN0000"))
                     Name(_UID, 0x00)
                     Name(_CID, "VM_Gen_Counter")
                     Name(_DDN, "VM_Gen_Counter")

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

From xen-devel-bounces@lists.xensource.com Fri Dec 02 14:44:28 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 14:44:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWULG-000867-FJ; Fri, 02 Dec 2011 14:43:58 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RWULE-00085z-Ha
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 14:43:57 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1322836993!5946783!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjg1NDY=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26843 invoked from network); 2 Dec 2011 14:43:15 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Dec 2011 14:43:15 -0000
X-IronPort-AV: E=Sophos;i="4.71,283,1320642000"; d="scan'208";a="172683685"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Dec 2011 09:42:46 -0500
Received: from cosworth.uk.xensource.com (10.80.16.52) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 2 Dec 2011 09:42:46 -0500
MIME-Version: 1.0
X-Mercurial-Node: de5432066adc888a704bbbce9b18de3a60859cff
Message-ID: <de5432066adc888a704b.1322836943@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 2 Dec 2011 14:42:23 +0000
From: Paul Durrant <paul.durrant@citrix.com>
To: xen-devel@lists.xensource.com
Cc: paul.durrant@citrix.com
Subject: [Xen-devel] [PATCH] VM generation ID save/restore and migrate
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Paul Durrant <paul.durrant@citrix.com>
# Date 1322836937 0
# Node ID de5432066adc888a704bbbce9b18de3a60859cff
# Parent  62ff6a318c5db7779fdbf4ddfdfc9506e86fa701
VM generation ID save/restore and migrate.

Add code to track the address of the VM generation id buffer across a
save/restore or migrate and increment it as necessary.
The address of the buffer is written into xenstore by hvmloader at
boot time. It must be read from xenstore by the caller of
xc_domain_save() and then written back again by the caller of
xc_domain_restore().

Signed-off-by: Paul Durrant <paul.durrant@citrix.com>

diff -r 62ff6a318c5d -r de5432066adc tools/libxc/ia64/xc_ia64_linux_restore.c
--- a/tools/libxc/ia64/xc_ia64_linux_restore.c	Wed Nov 30 16:59:58 2011 -0800
+++ b/tools/libxc/ia64/xc_ia64_linux_restore.c	Fri Dec 02 14:42:17 2011 +0000
@@ -548,7 +548,8 @@ int
 xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
                   unsigned int store_evtchn, unsigned long *store_mfn,
                   unsigned int console_evtchn, unsigned long *console_mfn,
-                  unsigned int hvm, unsigned int pae, int superpages)
+                  unsigned int hvm, unsigned int pae, int superpages,
+                  int increment_gid, unsigned long *vm_gid_addr)
 {
     DECLARE_DOMCTL;
     int rc = 1;
diff -r 62ff6a318c5d -r de5432066adc tools/libxc/ia64/xc_ia64_linux_save.c
--- a/tools/libxc/ia64/xc_ia64_linux_save.c	Wed Nov 30 16:59:58 2011 -0800
+++ b/tools/libxc/ia64/xc_ia64_linux_save.c	Fri Dec 02 14:42:17 2011 +0000
@@ -382,7 +382,8 @@ out:
 int
 xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iters,
                uint32_t max_factor, uint32_t flags,
-               struct save_callbacks* callbacks, int hvm)
+               struct save_callbacks* callbacks, int hvm,
+               unsigned long vm_gid_addr)
 {
     DECLARE_DOMCTL;
     xc_dominfo_t info;
diff -r 62ff6a318c5d -r de5432066adc tools/libxc/xc_domain_restore.c
--- a/tools/libxc/xc_domain_restore.c	Wed Nov 30 16:59:58 2011 -0800
+++ b/tools/libxc/xc_domain_restore.c	Fri Dec 02 14:42:17 2011 +0000
@@ -676,6 +676,7 @@ typedef struct {
     uint64_t console_pfn;
     uint64_t acpi_ioport_location;
     uint64_t viridian;
+    uint64_t vm_gid_addr;
 } pagebuf_t;
 
 static int pagebuf_init(pagebuf_t* buf)
@@ -820,6 +821,17 @@ static int pagebuf_get_one(xc_interface 
         }
         return pagebuf_get_one(xch, ctx, buf, fd, dom);
 
+    case XC_SAVE_ID_HVM_GENERATION_ID_ADDR:
+        /* Skip padding 4 bytes then read the generation id buffer location. */
+        if ( RDEXACT(fd, &buf->vm_gid_addr, sizeof(uint32_t)) ||
+             RDEXACT(fd, &buf->vm_gid_addr, sizeof(uint64_t)) )
+        {
+            PERROR("error read the generation id buffer location");
+            return -1;
+        }
+        DPRINTF("read generation id buffer address");
+        return pagebuf_get_one(xch, ctx, buf, fd, dom);
+
     default:
         if ( (count > MAX_BATCH_SIZE) || (count < 0) ) {
             ERROR("Max batch size exceeded (%d). Giving up.", count);
@@ -1186,7 +1198,8 @@ static int apply_batch(xc_interface *xch
 int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
                       unsigned int store_evtchn, unsigned long *store_mfn,
                       unsigned int console_evtchn, unsigned long *console_mfn,
-                      unsigned int hvm, unsigned int pae, int superpages)
+                      unsigned int hvm, unsigned int pae, int superpages,
+                      int no_increment_gid, unsigned long *vm_gid_addr)
 {
     DECLARE_DOMCTL;
     int rc = 1, frc, i, j, n, m, pae_extended_cr3 = 0, ext_vcpucontext = 0;
@@ -1386,6 +1399,39 @@ int xc_domain_restore(xc_interface *xch,
                 xc_set_hvm_param(xch, dom, HVM_PARAM_VM86_TSS, pagebuf.vm86_tss);
             if ( pagebuf.console_pfn )
                 console_pfn = pagebuf.console_pfn;
+            if ( pagebuf.vm_gid_addr ) {
+                if ( !no_increment_gid ) {
+                    unsigned int offset;
+                    unsigned char *buf;
+                    unsigned long long gid;
+
+                    /*
+                     * Map the VM generation id buffer and inject the new value.
+                     */
+
+                    pfn = pagebuf.vm_gid_addr >> PAGE_SHIFT;
+                    offset = pagebuf.vm_gid_addr & (PAGE_SIZE - 1);
+                
+                    if ( (pfn >= dinfo->p2m_size) ||
+                         (pfn_type[pfn] != XEN_DOMCTL_PFINFO_NOTAB) )
+                    {
+                        ERROR("generation id buffer frame is bad");
+                        goto out;
+                    }
+
+                    mfn = ctx->p2m[pfn];
+                    buf = xc_map_foreign_range(xch, dom, PAGE_SIZE,
+                                               PROT_READ | PROT_WRITE, mfn);
+
+                    gid = *(unsigned long long *)(buf + offset);
+                    *(unsigned long long *)(buf + offset) = gid + 1;
+
+                    munmap(buf, PAGE_SIZE);
+                }
+
+                *vm_gid_addr = pagebuf.vm_gid_addr;
+            }
+
             break;  /* our work here is done */
         }
 
diff -r 62ff6a318c5d -r de5432066adc tools/libxc/xc_domain_save.c
--- a/tools/libxc/xc_domain_save.c	Wed Nov 30 16:59:58 2011 -0800
+++ b/tools/libxc/xc_domain_save.c	Fri Dec 02 14:42:17 2011 +0000
@@ -754,7 +754,8 @@ static int save_tsc_info(xc_interface *x
 
 int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iters,
                    uint32_t max_factor, uint32_t flags,
-                   struct save_callbacks* callbacks, int hvm)
+                   struct save_callbacks* callbacks, int hvm,
+                   unsigned long vm_gid_addr)
 {
     xc_dominfo_t info;
     DECLARE_DOMCTL;
@@ -1460,6 +1461,16 @@ int xc_domain_save(xc_interface *xch, in
             uint64_t data;
         } chunk = { 0, };
 
+        chunk.id = XC_SAVE_ID_HVM_GENERATION_ID_ADDR;
+        chunk.data = vm_gid_addr;
+
+        if ( (chunk.data != 0) &&
+             wrexact(io_fd, &chunk, sizeof(chunk)) )
+        {
+            PERROR("Error when writing the generation id buffer location for guest");
+            goto out;
+        }
+
         chunk.id = XC_SAVE_ID_HVM_IDENT_PT;
         chunk.data = 0;
         xc_get_hvm_param(xch, dom, HVM_PARAM_IDENT_PT,
diff -r 62ff6a318c5d -r de5432066adc tools/libxc/xenguest.h
--- a/tools/libxc/xenguest.h	Wed Nov 30 16:59:58 2011 -0800
+++ b/tools/libxc/xenguest.h	Fri Dec 02 14:42:17 2011 +0000
@@ -57,7 +57,8 @@ struct save_callbacks {
  */
 int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iters,
                    uint32_t max_factor, uint32_t flags /* XCFLAGS_xxx */,
-                   struct save_callbacks* callbacks, int hvm);
+                   struct save_callbacks* callbacks, int hvm,
+                   unsigned long vm_gid_addr);
 
 
 /**
@@ -71,12 +72,15 @@ int xc_domain_save(xc_interface *xch, in
  * @parm hvm non-zero if this is a HVM restore
  * @parm pae non-zero if this HVM domain has PAE support enabled
  * @parm superpages non-zero to allocate guest memory with superpages
+ * @parm gid the new generation id of the VM
+ * @parm vm_gid_addr returned with the address of the generation id buffer
  * @return 0 on success, -1 on failure
  */
 int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
                       unsigned int store_evtchn, unsigned long *store_mfn,
                       unsigned int console_evtchn, unsigned long *console_mfn,
-                      unsigned int hvm, unsigned int pae, int superpages);
+                      unsigned int hvm, unsigned int pae, int superpages,
+                      int increment_gid, unsigned long *vm_gid_addr);
 /**
  * xc_domain_restore writes a file to disk that contains the device
  * model saved state.
diff -r 62ff6a318c5d -r de5432066adc tools/libxc/xg_save_restore.h
--- a/tools/libxc/xg_save_restore.h	Wed Nov 30 16:59:58 2011 -0800
+++ b/tools/libxc/xg_save_restore.h	Fri Dec 02 14:42:17 2011 +0000
@@ -135,6 +135,7 @@
 #define XC_SAVE_ID_LAST_CHECKPOINT    -9 /* Commit to restoring after completion of current iteration. */
 #define XC_SAVE_ID_HVM_ACPI_IOPORTS_LOCATION -10
 #define XC_SAVE_ID_HVM_VIRIDIAN       -11
+#define XC_SAVE_ID_HVM_GENERATION_ID_ADDR -12
 
 /*
 ** We process save/restore/migrate in batches of pages; the below
diff -r 62ff6a318c5d -r de5432066adc tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Wed Nov 30 16:59:58 2011 -0800
+++ b/tools/libxl/libxl_create.c	Fri Dec 02 14:42:17 2011 +0000
@@ -101,6 +101,7 @@ int libxl_init_build_info(libxl_ctx *ctx
         b_info->u.hvm.vpt_align = 1;
         b_info->u.hvm.timer_mode = 1;
         b_info->u.hvm.nested_hvm = 0;
+        b_info->u.hvm.no_increment_gid = 0;
         break;
     case LIBXL_DOMAIN_TYPE_PV:
         b_info->u.pv.slack_memkb = 8 * 1024;
diff -r 62ff6a318c5d -r de5432066adc tools/libxl/libxl_dom.c
--- a/tools/libxl/libxl_dom.c	Wed Nov 30 16:59:58 2011 -0800
+++ b/tools/libxl/libxl_dom.c	Fri Dec 02 14:42:17 2011 +0000
@@ -125,7 +125,7 @@ int libxl__build_post(libxl__gc *gc, uin
     if (info->cpuid != NULL)
         libxl_cpuid_set(ctx, domid, info->cpuid);
 
-    ents = libxl__calloc(gc, 12 + (info->max_vcpus * 2) + 2, sizeof(char *));
+    ents = libxl__calloc(gc, 14 + (info->max_vcpus * 2) + 2, sizeof(char *));
     ents[0] = "memory/static-max";
     ents[1] = libxl__sprintf(gc, "%d", info->max_memkb);
     ents[2] = "memory/target";
@@ -138,9 +138,11 @@ int libxl__build_post(libxl__gc *gc, uin
     ents[9] = libxl__sprintf(gc, "%"PRIu32, state->store_port);
     ents[10] = "store/ring-ref";
     ents[11] = libxl__sprintf(gc, "%lu", state->store_mfn);
+    ents[12] = "data/generation-id";
+    ents[13] = libxl__sprintf(gc, "0x%lx", state->vm_gid_addr);
     for (i = 0; i < info->max_vcpus; i++) {
-        ents[12+(i*2)]   = libxl__sprintf(gc, "cpu/%d/availability", i);
-        ents[12+(i*2)+1] = (i && info->cur_vcpus && !(info->cur_vcpus & (1 << i)))
+        ents[14+(i*2)]   = libxl__sprintf(gc, "cpu/%d/availability", i);
+        ents[14+(i*2)+1] = (i && info->cur_vcpus && !(info->cur_vcpus & (1 << i)))
                             ? "offline" : "online";
     }
 
@@ -357,16 +359,19 @@ int libxl__domain_restore_common(libxl__
     /* read signature */
     int rc;
     int hvm, pae, superpages;
+    int no_increment_gid;
     switch (info->type) {
     case LIBXL_DOMAIN_TYPE_HVM:
         hvm = 1;
         superpages = 1;
         pae = info->u.hvm.pae;
+        no_increment_gid = info->u.hvm.no_increment_gid;
         break;
     case LIBXL_DOMAIN_TYPE_PV:
         hvm = 0;
         superpages = 0;
         pae = 1;
+        no_increment_gid = 0;
         break;
     default:
         return ERROR_INVAL;
@@ -374,7 +379,7 @@ int libxl__domain_restore_common(libxl__
     rc = xc_domain_restore(ctx->xch, fd, domid,
                            state->store_port, &state->store_mfn,
                            state->console_port, &state->console_mfn,
-                           hvm, pae, superpages);
+                           hvm, pae, superpages, no_increment_gid, &state->vm_gid_addr);
     if ( rc ) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "restoring domain");
         return ERROR_FAIL;
@@ -540,12 +545,22 @@ int libxl__domain_suspend_common(libxl__
     struct save_callbacks callbacks;
     struct suspendinfo si;
     int hvm, rc = ERROR_FAIL;
+    unsigned long vm_gid_addr;
 
     switch (type) {
-    case LIBXL_DOMAIN_TYPE_HVM:
+    case LIBXL_DOMAIN_TYPE_HVM: {
+        char *path;
+        char *addr;
+
+        path = libxl__sprintf(gc, "%s/data/generation-id", libxl__xs_get_dompath(gc, domid));
+        addr = libxl__xs_read(gc, XBT_NULL, path);
+
+        vm_gid_addr = (addr) ? strtoul(addr, NULL, 0) : 0;
         hvm = 1;
         break;
+    }
     case LIBXL_DOMAIN_TYPE_PV:
+        vm_gid_addr = 0;
         hvm = 0;
         break;
     default:
@@ -583,7 +598,8 @@ int libxl__domain_suspend_common(libxl__
     callbacks.switch_qemu_logdirty = libxl__domain_suspend_common_switch_qemu_logdirty;
     callbacks.data = &si;
 
-    rc = xc_domain_save(ctx->xch, fd, domid, 0, 0, flags, &callbacks, hvm);
+    rc = xc_domain_save(ctx->xch, fd, domid, 0, 0, flags, &callbacks,
+                        hvm, vm_gid_addr);
     if ( rc ) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "saving domain: %s",
                          si.guest_responded ?
diff -r 62ff6a318c5d -r de5432066adc tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Wed Nov 30 16:59:58 2011 -0800
+++ b/tools/libxl/libxl_internal.h	Fri Dec 02 14:42:17 2011 +0000
@@ -199,6 +199,7 @@ typedef struct {
 
     uint32_t console_port;
     unsigned long console_mfn;
+    unsigned long vm_gid_addr;
 } libxl__domain_build_state;
 
 _hidden int libxl__build_pre(libxl__gc *gc, uint32_t domid,
diff -r 62ff6a318c5d -r de5432066adc tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Wed Nov 30 16:59:58 2011 -0800
+++ b/tools/libxl/libxl_types.idl	Fri Dec 02 14:42:17 2011 +0000
@@ -183,6 +183,7 @@ libxl_domain_build_info = Struct("domain
                                        ("vpt_align", bool),
                                        ("timer_mode", integer),
                                        ("nested_hvm", bool),
+                                       ("no_increment_gid", bool),
                                        ])),
                  ("pv", Struct(None, [("kernel", libxl_file_reference),
                                       ("slack_memkb", uint32),
diff -r 62ff6a318c5d -r de5432066adc tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Wed Nov 30 16:59:58 2011 -0800
+++ b/tools/libxl/xl_cmdimpl.c	Fri Dec 02 14:42:17 2011 +0000
@@ -360,6 +360,7 @@ static void printf_info(int domid,
         printf("\t\t\t(vpt_align %d)\n", b_info->u.hvm.vpt_align);
         printf("\t\t\t(timer_mode %d)\n", b_info->u.hvm.timer_mode);
         printf("\t\t\t(nestedhvm %d)\n", b_info->u.hvm.nested_hvm);
+        printf("\t\t\t(no_increment_gid %d)\n", b_info->u.hvm.no_increment_gid);
 
         printf("\t\t\t(device_model %s)\n", dm_info->device_model ? : "default");
         printf("\t\t\t(videoram %d)\n", dm_info->videoram);
@@ -1362,6 +1363,7 @@ struct domain_create {
     const char *restore_file;
     int migrate_fd; /* -1 means none */
     char **migration_domname_r; /* from malloc */
+    int no_increment_gid;
 };
 
 static int freemem(libxl_domain_build_info *b_info, libxl_device_model_info *dm_info)
@@ -1571,6 +1573,8 @@ static int create_domain(struct domain_c
         }
     }
 
+    d_config.b_info.u.hvm.no_increment_gid = dom_info->no_increment_gid;
+
     if (debug || dom_info->dryrun)
         printf_info(-1, &d_config, &d_config.dm_info);
 
@@ -2796,6 +2800,7 @@ static void migrate_receive(int debug, i
     dom_info.restore_file = "incoming migration stream";
     dom_info.migrate_fd = 0; /* stdin */
     dom_info.migration_domname_r = &migration_domname;
+    dom_info.no_increment_gid = 1;
 
     rc = create_domain(&dom_info);
     if (rc < 0) {
diff -r 62ff6a318c5d -r de5432066adc tools/python/xen/lowlevel/checkpoint/libcheckpoint.c
--- a/tools/python/xen/lowlevel/checkpoint/libcheckpoint.c	Wed Nov 30 16:59:58 2011 -0800
+++ b/tools/python/xen/lowlevel/checkpoint/libcheckpoint.c	Fri Dec 02 14:42:17 2011 +0000
@@ -174,6 +174,7 @@ int checkpoint_start(checkpoint_state* s
 {
     int hvm, rc;
     int flags = XCFLAGS_LIVE;
+    unsigned long vm_gid_addr;
 
     if (!s->domid) {
        s->errstr = "checkpoint state not opened";
@@ -184,14 +185,25 @@ int checkpoint_start(checkpoint_state* s
 
     hvm = s->domtype > dt_pv;
     if (hvm) {
+       char path[128];
+       char *addr;
+
+       sprintf(path, "/local/domain/%u/data/generation-id", s->domid);
+       addr = xs_read(s->xsh, XBT_NULL, path, NULL);
+
+       vm_gid_addr = (addr) ? strtoul(addr, NULL, 0) : 0;
+       free(addr);
+
        flags |= XCFLAGS_HVM;
        if (switch_qemu_logdirty(s, 1))
            return -1;
+    } else {
+       vm_gid_addr = 0;
     }
 
     callbacks->switch_qemu_logdirty = noop_switch_logdirty;
 
-    rc = xc_domain_save(s->xch, fd, s->domid, 0, 0, flags, callbacks, hvm);
+    rc = xc_domain_save(s->xch, fd, s->domid, 0, 0, flags, callbacks, hvm, vm_gid_addr);
 
     if (hvm)
        switch_qemu_logdirty(s, 0);
diff -r 62ff6a318c5d -r de5432066adc tools/xcutils/xc_restore.c
--- a/tools/xcutils/xc_restore.c	Wed Nov 30 16:59:58 2011 -0800
+++ b/tools/xcutils/xc_restore.c	Fri Dec 02 14:42:17 2011 +0000
@@ -23,7 +23,8 @@ main(int argc, char **argv)
     xc_interface *xch;
     int io_fd, ret;
     int superpages;
-    unsigned long store_mfn, console_mfn;
+    unsigned long store_mfn, console_mfn, vm_gid_addr;
+    int no_increment_gid;
 
     if ( (argc != 8) && (argc != 9) )
         errx(1, "usage: %s iofd domid store_evtchn "
@@ -40,19 +41,25 @@ main(int argc, char **argv)
     hvm  = atoi(argv[5]);
     pae  = atoi(argv[6]);
     apic = atoi(argv[7]);
-    if ( argc == 9 )
+    if ( argc >= 9 )
 	    superpages = atoi(argv[8]);
     else
 	    superpages = !!hvm;
+    if ( argc >= 10 )
+	    no_increment_gid = !atoi(argv[9]);
+    else
+	    no_increment_gid = 0;
 
     ret = xc_domain_restore(xch, io_fd, domid, store_evtchn, &store_mfn,
-                            console_evtchn, &console_mfn, hvm, pae, superpages);
+                            console_evtchn, &console_mfn, hvm, pae, superpages,
+                            no_increment_gid, &vm_gid_addr);
 
     if ( ret == 0 )
     {
 	printf("store-mfn %li\n", store_mfn);
         if ( !hvm )
             printf("console-mfn %li\n", console_mfn);
+	printf("vm-gid-addr %lx\n", vm_gid_addr);
 	fflush(stdout);
     }
 
diff -r 62ff6a318c5d -r de5432066adc tools/xcutils/xc_save.c
--- a/tools/xcutils/xc_save.c	Wed Nov 30 16:59:58 2011 -0800
+++ b/tools/xcutils/xc_save.c	Fri Dec 02 14:42:17 2011 +0000
@@ -169,6 +169,10 @@ main(int argc, char **argv)
     unsigned int maxit, max_f;
     int io_fd, ret, port;
     struct save_callbacks callbacks;
+    char path[128];
+    struct xs_handle *xs;
+    char *addr;
+    unsigned long vm_gid_addr;
 
     if (argc != 6)
         errx(1, "usage: %s iofd domid maxit maxf flags", argv[0]);
@@ -207,8 +211,21 @@ main(int argc, char **argv)
     memset(&callbacks, 0, sizeof(callbacks));
     callbacks.suspend = suspend;
     callbacks.switch_qemu_logdirty = switch_qemu_logdirty;
+
+    sprintf(path, "/local/domain/%d/data/generation-id", si.domid);
+
+    if ((xs = xs_daemon_open()) == NULL)
+        errx(1, "Couldn't contact xenstore");
+
+    addr = xs_read(xs, XBT_NULL, path, NULL);
+
+    xs_daemon_close(xs);
+
+    vm_gid_addr = (addr) ? strtoul(addr, NULL, 0) : 0;
+    free(addr);
+
     ret = xc_domain_save(si.xch, io_fd, si.domid, maxit, max_f, si.flags, 
-                         &callbacks, !!(si.flags & XCFLAGS_HVM));
+                         &callbacks, !!(si.flags & XCFLAGS_HVM), vm_gid_addr);
 
     if (si.suspend_evtchn > 0)
 	 xc_suspend_evtchn_release(si.xch, si.xce, si.domid, si.suspend_evtchn);

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

From xen-devel-bounces@lists.xensource.com Fri Dec 02 14:44:28 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 14:44:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWULG-000867-FJ; Fri, 02 Dec 2011 14:43:58 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RWULE-00085z-Ha
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 14:43:57 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1322836993!5946783!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjg1NDY=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26843 invoked from network); 2 Dec 2011 14:43:15 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Dec 2011 14:43:15 -0000
X-IronPort-AV: E=Sophos;i="4.71,283,1320642000"; d="scan'208";a="172683685"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Dec 2011 09:42:46 -0500
Received: from cosworth.uk.xensource.com (10.80.16.52) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 2 Dec 2011 09:42:46 -0500
MIME-Version: 1.0
X-Mercurial-Node: de5432066adc888a704bbbce9b18de3a60859cff
Message-ID: <de5432066adc888a704b.1322836943@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 2 Dec 2011 14:42:23 +0000
From: Paul Durrant <paul.durrant@citrix.com>
To: xen-devel@lists.xensource.com
Cc: paul.durrant@citrix.com
Subject: [Xen-devel] [PATCH] VM generation ID save/restore and migrate
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Paul Durrant <paul.durrant@citrix.com>
# Date 1322836937 0
# Node ID de5432066adc888a704bbbce9b18de3a60859cff
# Parent  62ff6a318c5db7779fdbf4ddfdfc9506e86fa701
VM generation ID save/restore and migrate.

Add code to track the address of the VM generation id buffer across a
save/restore or migrate and increment it as necessary.
The address of the buffer is written into xenstore by hvmloader at
boot time. It must be read from xenstore by the caller of
xc_domain_save() and then written back again by the caller of
xc_domain_restore().

Signed-off-by: Paul Durrant <paul.durrant@citrix.com>

diff -r 62ff6a318c5d -r de5432066adc tools/libxc/ia64/xc_ia64_linux_restore.c
--- a/tools/libxc/ia64/xc_ia64_linux_restore.c	Wed Nov 30 16:59:58 2011 -0800
+++ b/tools/libxc/ia64/xc_ia64_linux_restore.c	Fri Dec 02 14:42:17 2011 +0000
@@ -548,7 +548,8 @@ int
 xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
                   unsigned int store_evtchn, unsigned long *store_mfn,
                   unsigned int console_evtchn, unsigned long *console_mfn,
-                  unsigned int hvm, unsigned int pae, int superpages)
+                  unsigned int hvm, unsigned int pae, int superpages,
+                  int increment_gid, unsigned long *vm_gid_addr)
 {
     DECLARE_DOMCTL;
     int rc = 1;
diff -r 62ff6a318c5d -r de5432066adc tools/libxc/ia64/xc_ia64_linux_save.c
--- a/tools/libxc/ia64/xc_ia64_linux_save.c	Wed Nov 30 16:59:58 2011 -0800
+++ b/tools/libxc/ia64/xc_ia64_linux_save.c	Fri Dec 02 14:42:17 2011 +0000
@@ -382,7 +382,8 @@ out:
 int
 xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iters,
                uint32_t max_factor, uint32_t flags,
-               struct save_callbacks* callbacks, int hvm)
+               struct save_callbacks* callbacks, int hvm,
+               unsigned long vm_gid_addr)
 {
     DECLARE_DOMCTL;
     xc_dominfo_t info;
diff -r 62ff6a318c5d -r de5432066adc tools/libxc/xc_domain_restore.c
--- a/tools/libxc/xc_domain_restore.c	Wed Nov 30 16:59:58 2011 -0800
+++ b/tools/libxc/xc_domain_restore.c	Fri Dec 02 14:42:17 2011 +0000
@@ -676,6 +676,7 @@ typedef struct {
     uint64_t console_pfn;
     uint64_t acpi_ioport_location;
     uint64_t viridian;
+    uint64_t vm_gid_addr;
 } pagebuf_t;
 
 static int pagebuf_init(pagebuf_t* buf)
@@ -820,6 +821,17 @@ static int pagebuf_get_one(xc_interface 
         }
         return pagebuf_get_one(xch, ctx, buf, fd, dom);
 
+    case XC_SAVE_ID_HVM_GENERATION_ID_ADDR:
+        /* Skip padding 4 bytes then read the generation id buffer location. */
+        if ( RDEXACT(fd, &buf->vm_gid_addr, sizeof(uint32_t)) ||
+             RDEXACT(fd, &buf->vm_gid_addr, sizeof(uint64_t)) )
+        {
+            PERROR("error read the generation id buffer location");
+            return -1;
+        }
+        DPRINTF("read generation id buffer address");
+        return pagebuf_get_one(xch, ctx, buf, fd, dom);
+
     default:
         if ( (count > MAX_BATCH_SIZE) || (count < 0) ) {
             ERROR("Max batch size exceeded (%d). Giving up.", count);
@@ -1186,7 +1198,8 @@ static int apply_batch(xc_interface *xch
 int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
                       unsigned int store_evtchn, unsigned long *store_mfn,
                       unsigned int console_evtchn, unsigned long *console_mfn,
-                      unsigned int hvm, unsigned int pae, int superpages)
+                      unsigned int hvm, unsigned int pae, int superpages,
+                      int no_increment_gid, unsigned long *vm_gid_addr)
 {
     DECLARE_DOMCTL;
     int rc = 1, frc, i, j, n, m, pae_extended_cr3 = 0, ext_vcpucontext = 0;
@@ -1386,6 +1399,39 @@ int xc_domain_restore(xc_interface *xch,
                 xc_set_hvm_param(xch, dom, HVM_PARAM_VM86_TSS, pagebuf.vm86_tss);
             if ( pagebuf.console_pfn )
                 console_pfn = pagebuf.console_pfn;
+            if ( pagebuf.vm_gid_addr ) {
+                if ( !no_increment_gid ) {
+                    unsigned int offset;
+                    unsigned char *buf;
+                    unsigned long long gid;
+
+                    /*
+                     * Map the VM generation id buffer and inject the new value.
+                     */
+
+                    pfn = pagebuf.vm_gid_addr >> PAGE_SHIFT;
+                    offset = pagebuf.vm_gid_addr & (PAGE_SIZE - 1);
+                
+                    if ( (pfn >= dinfo->p2m_size) ||
+                         (pfn_type[pfn] != XEN_DOMCTL_PFINFO_NOTAB) )
+                    {
+                        ERROR("generation id buffer frame is bad");
+                        goto out;
+                    }
+
+                    mfn = ctx->p2m[pfn];
+                    buf = xc_map_foreign_range(xch, dom, PAGE_SIZE,
+                                               PROT_READ | PROT_WRITE, mfn);
+
+                    gid = *(unsigned long long *)(buf + offset);
+                    *(unsigned long long *)(buf + offset) = gid + 1;
+
+                    munmap(buf, PAGE_SIZE);
+                }
+
+                *vm_gid_addr = pagebuf.vm_gid_addr;
+            }
+
             break;  /* our work here is done */
         }
 
diff -r 62ff6a318c5d -r de5432066adc tools/libxc/xc_domain_save.c
--- a/tools/libxc/xc_domain_save.c	Wed Nov 30 16:59:58 2011 -0800
+++ b/tools/libxc/xc_domain_save.c	Fri Dec 02 14:42:17 2011 +0000
@@ -754,7 +754,8 @@ static int save_tsc_info(xc_interface *x
 
 int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iters,
                    uint32_t max_factor, uint32_t flags,
-                   struct save_callbacks* callbacks, int hvm)
+                   struct save_callbacks* callbacks, int hvm,
+                   unsigned long vm_gid_addr)
 {
     xc_dominfo_t info;
     DECLARE_DOMCTL;
@@ -1460,6 +1461,16 @@ int xc_domain_save(xc_interface *xch, in
             uint64_t data;
         } chunk = { 0, };
 
+        chunk.id = XC_SAVE_ID_HVM_GENERATION_ID_ADDR;
+        chunk.data = vm_gid_addr;
+
+        if ( (chunk.data != 0) &&
+             wrexact(io_fd, &chunk, sizeof(chunk)) )
+        {
+            PERROR("Error when writing the generation id buffer location for guest");
+            goto out;
+        }
+
         chunk.id = XC_SAVE_ID_HVM_IDENT_PT;
         chunk.data = 0;
         xc_get_hvm_param(xch, dom, HVM_PARAM_IDENT_PT,
diff -r 62ff6a318c5d -r de5432066adc tools/libxc/xenguest.h
--- a/tools/libxc/xenguest.h	Wed Nov 30 16:59:58 2011 -0800
+++ b/tools/libxc/xenguest.h	Fri Dec 02 14:42:17 2011 +0000
@@ -57,7 +57,8 @@ struct save_callbacks {
  */
 int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iters,
                    uint32_t max_factor, uint32_t flags /* XCFLAGS_xxx */,
-                   struct save_callbacks* callbacks, int hvm);
+                   struct save_callbacks* callbacks, int hvm,
+                   unsigned long vm_gid_addr);
 
 
 /**
@@ -71,12 +72,15 @@ int xc_domain_save(xc_interface *xch, in
  * @parm hvm non-zero if this is a HVM restore
  * @parm pae non-zero if this HVM domain has PAE support enabled
  * @parm superpages non-zero to allocate guest memory with superpages
+ * @parm gid the new generation id of the VM
+ * @parm vm_gid_addr returned with the address of the generation id buffer
  * @return 0 on success, -1 on failure
  */
 int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
                       unsigned int store_evtchn, unsigned long *store_mfn,
                       unsigned int console_evtchn, unsigned long *console_mfn,
-                      unsigned int hvm, unsigned int pae, int superpages);
+                      unsigned int hvm, unsigned int pae, int superpages,
+                      int increment_gid, unsigned long *vm_gid_addr);
 /**
  * xc_domain_restore writes a file to disk that contains the device
  * model saved state.
diff -r 62ff6a318c5d -r de5432066adc tools/libxc/xg_save_restore.h
--- a/tools/libxc/xg_save_restore.h	Wed Nov 30 16:59:58 2011 -0800
+++ b/tools/libxc/xg_save_restore.h	Fri Dec 02 14:42:17 2011 +0000
@@ -135,6 +135,7 @@
 #define XC_SAVE_ID_LAST_CHECKPOINT    -9 /* Commit to restoring after completion of current iteration. */
 #define XC_SAVE_ID_HVM_ACPI_IOPORTS_LOCATION -10
 #define XC_SAVE_ID_HVM_VIRIDIAN       -11
+#define XC_SAVE_ID_HVM_GENERATION_ID_ADDR -12
 
 /*
 ** We process save/restore/migrate in batches of pages; the below
diff -r 62ff6a318c5d -r de5432066adc tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Wed Nov 30 16:59:58 2011 -0800
+++ b/tools/libxl/libxl_create.c	Fri Dec 02 14:42:17 2011 +0000
@@ -101,6 +101,7 @@ int libxl_init_build_info(libxl_ctx *ctx
         b_info->u.hvm.vpt_align = 1;
         b_info->u.hvm.timer_mode = 1;
         b_info->u.hvm.nested_hvm = 0;
+        b_info->u.hvm.no_increment_gid = 0;
         break;
     case LIBXL_DOMAIN_TYPE_PV:
         b_info->u.pv.slack_memkb = 8 * 1024;
diff -r 62ff6a318c5d -r de5432066adc tools/libxl/libxl_dom.c
--- a/tools/libxl/libxl_dom.c	Wed Nov 30 16:59:58 2011 -0800
+++ b/tools/libxl/libxl_dom.c	Fri Dec 02 14:42:17 2011 +0000
@@ -125,7 +125,7 @@ int libxl__build_post(libxl__gc *gc, uin
     if (info->cpuid != NULL)
         libxl_cpuid_set(ctx, domid, info->cpuid);
 
-    ents = libxl__calloc(gc, 12 + (info->max_vcpus * 2) + 2, sizeof(char *));
+    ents = libxl__calloc(gc, 14 + (info->max_vcpus * 2) + 2, sizeof(char *));
     ents[0] = "memory/static-max";
     ents[1] = libxl__sprintf(gc, "%d", info->max_memkb);
     ents[2] = "memory/target";
@@ -138,9 +138,11 @@ int libxl__build_post(libxl__gc *gc, uin
     ents[9] = libxl__sprintf(gc, "%"PRIu32, state->store_port);
     ents[10] = "store/ring-ref";
     ents[11] = libxl__sprintf(gc, "%lu", state->store_mfn);
+    ents[12] = "data/generation-id";
+    ents[13] = libxl__sprintf(gc, "0x%lx", state->vm_gid_addr);
     for (i = 0; i < info->max_vcpus; i++) {
-        ents[12+(i*2)]   = libxl__sprintf(gc, "cpu/%d/availability", i);
-        ents[12+(i*2)+1] = (i && info->cur_vcpus && !(info->cur_vcpus & (1 << i)))
+        ents[14+(i*2)]   = libxl__sprintf(gc, "cpu/%d/availability", i);
+        ents[14+(i*2)+1] = (i && info->cur_vcpus && !(info->cur_vcpus & (1 << i)))
                             ? "offline" : "online";
     }
 
@@ -357,16 +359,19 @@ int libxl__domain_restore_common(libxl__
     /* read signature */
     int rc;
     int hvm, pae, superpages;
+    int no_increment_gid;
     switch (info->type) {
     case LIBXL_DOMAIN_TYPE_HVM:
         hvm = 1;
         superpages = 1;
         pae = info->u.hvm.pae;
+        no_increment_gid = info->u.hvm.no_increment_gid;
         break;
     case LIBXL_DOMAIN_TYPE_PV:
         hvm = 0;
         superpages = 0;
         pae = 1;
+        no_increment_gid = 0;
         break;
     default:
         return ERROR_INVAL;
@@ -374,7 +379,7 @@ int libxl__domain_restore_common(libxl__
     rc = xc_domain_restore(ctx->xch, fd, domid,
                            state->store_port, &state->store_mfn,
                            state->console_port, &state->console_mfn,
-                           hvm, pae, superpages);
+                           hvm, pae, superpages, no_increment_gid, &state->vm_gid_addr);
     if ( rc ) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "restoring domain");
         return ERROR_FAIL;
@@ -540,12 +545,22 @@ int libxl__domain_suspend_common(libxl__
     struct save_callbacks callbacks;
     struct suspendinfo si;
     int hvm, rc = ERROR_FAIL;
+    unsigned long vm_gid_addr;
 
     switch (type) {
-    case LIBXL_DOMAIN_TYPE_HVM:
+    case LIBXL_DOMAIN_TYPE_HVM: {
+        char *path;
+        char *addr;
+
+        path = libxl__sprintf(gc, "%s/data/generation-id", libxl__xs_get_dompath(gc, domid));
+        addr = libxl__xs_read(gc, XBT_NULL, path);
+
+        vm_gid_addr = (addr) ? strtoul(addr, NULL, 0) : 0;
         hvm = 1;
         break;
+    }
     case LIBXL_DOMAIN_TYPE_PV:
+        vm_gid_addr = 0;
         hvm = 0;
         break;
     default:
@@ -583,7 +598,8 @@ int libxl__domain_suspend_common(libxl__
     callbacks.switch_qemu_logdirty = libxl__domain_suspend_common_switch_qemu_logdirty;
     callbacks.data = &si;
 
-    rc = xc_domain_save(ctx->xch, fd, domid, 0, 0, flags, &callbacks, hvm);
+    rc = xc_domain_save(ctx->xch, fd, domid, 0, 0, flags, &callbacks,
+                        hvm, vm_gid_addr);
     if ( rc ) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "saving domain: %s",
                          si.guest_responded ?
diff -r 62ff6a318c5d -r de5432066adc tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Wed Nov 30 16:59:58 2011 -0800
+++ b/tools/libxl/libxl_internal.h	Fri Dec 02 14:42:17 2011 +0000
@@ -199,6 +199,7 @@ typedef struct {
 
     uint32_t console_port;
     unsigned long console_mfn;
+    unsigned long vm_gid_addr;
 } libxl__domain_build_state;
 
 _hidden int libxl__build_pre(libxl__gc *gc, uint32_t domid,
diff -r 62ff6a318c5d -r de5432066adc tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Wed Nov 30 16:59:58 2011 -0800
+++ b/tools/libxl/libxl_types.idl	Fri Dec 02 14:42:17 2011 +0000
@@ -183,6 +183,7 @@ libxl_domain_build_info = Struct("domain
                                        ("vpt_align", bool),
                                        ("timer_mode", integer),
                                        ("nested_hvm", bool),
+                                       ("no_increment_gid", bool),
                                        ])),
                  ("pv", Struct(None, [("kernel", libxl_file_reference),
                                       ("slack_memkb", uint32),
diff -r 62ff6a318c5d -r de5432066adc tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Wed Nov 30 16:59:58 2011 -0800
+++ b/tools/libxl/xl_cmdimpl.c	Fri Dec 02 14:42:17 2011 +0000
@@ -360,6 +360,7 @@ static void printf_info(int domid,
         printf("\t\t\t(vpt_align %d)\n", b_info->u.hvm.vpt_align);
         printf("\t\t\t(timer_mode %d)\n", b_info->u.hvm.timer_mode);
         printf("\t\t\t(nestedhvm %d)\n", b_info->u.hvm.nested_hvm);
+        printf("\t\t\t(no_increment_gid %d)\n", b_info->u.hvm.no_increment_gid);
 
         printf("\t\t\t(device_model %s)\n", dm_info->device_model ? : "default");
         printf("\t\t\t(videoram %d)\n", dm_info->videoram);
@@ -1362,6 +1363,7 @@ struct domain_create {
     const char *restore_file;
     int migrate_fd; /* -1 means none */
     char **migration_domname_r; /* from malloc */
+    int no_increment_gid;
 };
 
 static int freemem(libxl_domain_build_info *b_info, libxl_device_model_info *dm_info)
@@ -1571,6 +1573,8 @@ static int create_domain(struct domain_c
         }
     }
 
+    d_config.b_info.u.hvm.no_increment_gid = dom_info->no_increment_gid;
+
     if (debug || dom_info->dryrun)
         printf_info(-1, &d_config, &d_config.dm_info);
 
@@ -2796,6 +2800,7 @@ static void migrate_receive(int debug, i
     dom_info.restore_file = "incoming migration stream";
     dom_info.migrate_fd = 0; /* stdin */
     dom_info.migration_domname_r = &migration_domname;
+    dom_info.no_increment_gid = 1;
 
     rc = create_domain(&dom_info);
     if (rc < 0) {
diff -r 62ff6a318c5d -r de5432066adc tools/python/xen/lowlevel/checkpoint/libcheckpoint.c
--- a/tools/python/xen/lowlevel/checkpoint/libcheckpoint.c	Wed Nov 30 16:59:58 2011 -0800
+++ b/tools/python/xen/lowlevel/checkpoint/libcheckpoint.c	Fri Dec 02 14:42:17 2011 +0000
@@ -174,6 +174,7 @@ int checkpoint_start(checkpoint_state* s
 {
     int hvm, rc;
     int flags = XCFLAGS_LIVE;
+    unsigned long vm_gid_addr;
 
     if (!s->domid) {
        s->errstr = "checkpoint state not opened";
@@ -184,14 +185,25 @@ int checkpoint_start(checkpoint_state* s
 
     hvm = s->domtype > dt_pv;
     if (hvm) {
+       char path[128];
+       char *addr;
+
+       sprintf(path, "/local/domain/%u/data/generation-id", s->domid);
+       addr = xs_read(s->xsh, XBT_NULL, path, NULL);
+
+       vm_gid_addr = (addr) ? strtoul(addr, NULL, 0) : 0;
+       free(addr);
+
        flags |= XCFLAGS_HVM;
        if (switch_qemu_logdirty(s, 1))
            return -1;
+    } else {
+       vm_gid_addr = 0;
     }
 
     callbacks->switch_qemu_logdirty = noop_switch_logdirty;
 
-    rc = xc_domain_save(s->xch, fd, s->domid, 0, 0, flags, callbacks, hvm);
+    rc = xc_domain_save(s->xch, fd, s->domid, 0, 0, flags, callbacks, hvm, vm_gid_addr);
 
     if (hvm)
        switch_qemu_logdirty(s, 0);
diff -r 62ff6a318c5d -r de5432066adc tools/xcutils/xc_restore.c
--- a/tools/xcutils/xc_restore.c	Wed Nov 30 16:59:58 2011 -0800
+++ b/tools/xcutils/xc_restore.c	Fri Dec 02 14:42:17 2011 +0000
@@ -23,7 +23,8 @@ main(int argc, char **argv)
     xc_interface *xch;
     int io_fd, ret;
     int superpages;
-    unsigned long store_mfn, console_mfn;
+    unsigned long store_mfn, console_mfn, vm_gid_addr;
+    int no_increment_gid;
 
     if ( (argc != 8) && (argc != 9) )
         errx(1, "usage: %s iofd domid store_evtchn "
@@ -40,19 +41,25 @@ main(int argc, char **argv)
     hvm  = atoi(argv[5]);
     pae  = atoi(argv[6]);
     apic = atoi(argv[7]);
-    if ( argc == 9 )
+    if ( argc >= 9 )
 	    superpages = atoi(argv[8]);
     else
 	    superpages = !!hvm;
+    if ( argc >= 10 )
+	    no_increment_gid = !atoi(argv[9]);
+    else
+	    no_increment_gid = 0;
 
     ret = xc_domain_restore(xch, io_fd, domid, store_evtchn, &store_mfn,
-                            console_evtchn, &console_mfn, hvm, pae, superpages);
+                            console_evtchn, &console_mfn, hvm, pae, superpages,
+                            no_increment_gid, &vm_gid_addr);
 
     if ( ret == 0 )
     {
 	printf("store-mfn %li\n", store_mfn);
         if ( !hvm )
             printf("console-mfn %li\n", console_mfn);
+	printf("vm-gid-addr %lx\n", vm_gid_addr);
 	fflush(stdout);
     }
 
diff -r 62ff6a318c5d -r de5432066adc tools/xcutils/xc_save.c
--- a/tools/xcutils/xc_save.c	Wed Nov 30 16:59:58 2011 -0800
+++ b/tools/xcutils/xc_save.c	Fri Dec 02 14:42:17 2011 +0000
@@ -169,6 +169,10 @@ main(int argc, char **argv)
     unsigned int maxit, max_f;
     int io_fd, ret, port;
     struct save_callbacks callbacks;
+    char path[128];
+    struct xs_handle *xs;
+    char *addr;
+    unsigned long vm_gid_addr;
 
     if (argc != 6)
         errx(1, "usage: %s iofd domid maxit maxf flags", argv[0]);
@@ -207,8 +211,21 @@ main(int argc, char **argv)
     memset(&callbacks, 0, sizeof(callbacks));
     callbacks.suspend = suspend;
     callbacks.switch_qemu_logdirty = switch_qemu_logdirty;
+
+    sprintf(path, "/local/domain/%d/data/generation-id", si.domid);
+
+    if ((xs = xs_daemon_open()) == NULL)
+        errx(1, "Couldn't contact xenstore");
+
+    addr = xs_read(xs, XBT_NULL, path, NULL);
+
+    xs_daemon_close(xs);
+
+    vm_gid_addr = (addr) ? strtoul(addr, NULL, 0) : 0;
+    free(addr);
+
     ret = xc_domain_save(si.xch, io_fd, si.domid, maxit, max_f, si.flags, 
-                         &callbacks, !!(si.flags & XCFLAGS_HVM));
+                         &callbacks, !!(si.flags & XCFLAGS_HVM), vm_gid_addr);
 
     if (si.suspend_evtchn > 0)
 	 xc_suspend_evtchn_release(si.xch, si.xce, si.domid, si.suspend_evtchn);

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

From xen-devel-bounces@lists.xensource.com Fri Dec 02 14:48:14 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 14:48:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWUOx-0008Cj-4f; Fri, 02 Dec 2011 14:47:47 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andre.Przywara@amd.com>) id 1RWUOv-0008CY-Gj
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 14:47:45 +0000
X-Env-Sender: Andre.Przywara@amd.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1322837222!1078119!1
X-Originating-IP: [65.55.88.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21914 invoked from network); 2 Dec 2011 14:47:04 -0000
Received: from tx2ehsobe005.messaging.microsoft.com (HELO
	TX2EHSOBE010.bigfish.com) (65.55.88.15)
	by server-8.tower-182.messagelabs.com with AES128-SHA encrypted SMTP;
	2 Dec 2011 14:47:04 -0000
Received: from mail77-tx2-R.bigfish.com (10.9.14.245) by
	TX2EHSOBE010.bigfish.com (10.9.40.30) with Microsoft SMTP Server id
	14.1.225.22; Fri, 2 Dec 2011 14:47:02 +0000
Received: from mail77-tx2 (localhost [127.0.0.1])	by mail77-tx2-R.bigfish.com
	(Postfix) with ESMTP id 2D5E61A0483;
	Fri,  2 Dec 2011 14:47:02 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzc85dhzz1202hzz8275bhz2dh668h839h34h61h)
X-Spam-TCS-SCL: 0:0
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
Received: from mail77-tx2 (localhost.localdomain [127.0.0.1]) by mail77-tx2
	(MessageSwitch) id 132283716865082_2126; Fri,  2 Dec 2011 14:46:08 +0000
	(UTC)
Received: from TX2EHSMHS015.bigfish.com (unknown [10.9.14.239])	by
	mail77-tx2.bigfish.com (Postfix) with ESMTP id 8EFF8640186;
	Fri,  2 Dec 2011 14:45:03 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	TX2EHSMHS015.bigfish.com (10.9.99.115) with Microsoft SMTP Server id
	14.1.225.22; Fri, 2 Dec 2011 14:45:02 +0000
X-WSS-ID: 0LVKZMZ-01-F6X-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 20DB3102814D;	Fri,  2 Dec 2011 08:44:58 -0600 (CST)
Received: from SAUSEXDAG04.amd.com (163.181.55.4) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Fri, 2 Dec 2011 08:45:17 -0600
Received: from storexhtp02.amd.com (172.24.4.4) by sausexdag04.amd.com
	(163.181.55.4) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Fri, 2 Dec 2011 08:44:58 -0600
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Fri, 2 Dec 2011
	09:45:05 -0500
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 2CE4D49C0F1; Fri,  2 Dec 2011
	14:44:57 +0000 (GMT)
Received: from [165.204.15.38] (wanderer.osrc.amd.com [165.204.15.38])	by
	mail.osrc.amd.com (Postfix) with ESMTPS id 16A615940FF; Fri,  2 Dec 2011
	15:44:57 +0100 (CET)
Message-ID: <4ED8E3BF.6050509@amd.com>
Date: Fri, 2 Dec 2011 15:42:07 +0100
From: Andre Przywara <andre.przywara@amd.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.18) Gecko/20110705 Lightning/1.0b2 Thunderbird/3.1.11
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Content-Type: multipart/mixed; boundary="------------050605000401050307090709"
X-OriginatorOrg: amd.com
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: [Xen-devel] [PATCH] xl: fix compiler warnings
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--------------050605000401050307090709
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit

Hi,

either GCC 4.6.1 or Ubuntu add -Werror=format-security to the -Wall set, 
so libxl compilation breaks:
   libxl_create.c: In function 'store_libxl_entry':
   libxl_create.c:454:9: error: format not a string literal and no 
format arguments [-Werror=format-security]
   cc1: all warnings being treated as errors

attached patch fixes this and another occurrence.

Patch from: Uwe Dannowski

Signed-off-by: Andre Przywara <andre.przywara@amd.com>

Regards,
Andre.

-- 
Andre Przywara
AMD-Operating System Research Center (OSRC), Dresden, Germany

--------------050605000401050307090709
Content-Type: text/x-patch; name="libxl_sprintf_security.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="libxl_sprintf_security.patch"
Content-Description: libxl_sprintf_security.patch

diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index ce6a55e..6486156 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -461,7 +461,7 @@ static int store_libxl_entry(libxl__gc *gc, uint32_t domid,
 
     path = libxl__xs_libxl_path(gc, domid);
     path = libxl__sprintf(gc, "%s/dm-version", path);
-    return libxl__xs_write(gc, XBT_NULL, path, libxl__strdup(gc,
+    return libxl__xs_write(gc, XBT_NULL, path, "%s", libxl__strdup(gc,
         libxl_device_model_version_to_string(dm_info->device_model_version)));
 }
 
diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c
index a53fb70..1db395c 100644
--- a/tools/libxl/libxl_device.c
+++ b/tools/libxl/libxl_device.c
@@ -516,7 +516,7 @@ int libxl__devices_destroy(libxl__gc *gc, uint32_t domid, int force)
         for (j = 0; j < num_devs; j++) {
             path = libxl__sprintf(gc, "/local/domain/%d/device/%s/%s/backend",
                                   domid, kinds[i], devs[j]);
-            path = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, path));
+            path = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s", path));
             if (path && libxl__parse_backend_path(gc, path, &dev) == 0) {
                 dev.domid = domid;
                 dev.kind = kind;

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

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

--------------050605000401050307090709--


From xen-devel-bounces@lists.xensource.com Fri Dec 02 14:48:14 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 14:48:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWUOx-0008Cj-4f; Fri, 02 Dec 2011 14:47:47 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andre.Przywara@amd.com>) id 1RWUOv-0008CY-Gj
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 14:47:45 +0000
X-Env-Sender: Andre.Przywara@amd.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1322837222!1078119!1
X-Originating-IP: [65.55.88.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21914 invoked from network); 2 Dec 2011 14:47:04 -0000
Received: from tx2ehsobe005.messaging.microsoft.com (HELO
	TX2EHSOBE010.bigfish.com) (65.55.88.15)
	by server-8.tower-182.messagelabs.com with AES128-SHA encrypted SMTP;
	2 Dec 2011 14:47:04 -0000
Received: from mail77-tx2-R.bigfish.com (10.9.14.245) by
	TX2EHSOBE010.bigfish.com (10.9.40.30) with Microsoft SMTP Server id
	14.1.225.22; Fri, 2 Dec 2011 14:47:02 +0000
Received: from mail77-tx2 (localhost [127.0.0.1])	by mail77-tx2-R.bigfish.com
	(Postfix) with ESMTP id 2D5E61A0483;
	Fri,  2 Dec 2011 14:47:02 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzc85dhzz1202hzz8275bhz2dh668h839h34h61h)
X-Spam-TCS-SCL: 0:0
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
Received: from mail77-tx2 (localhost.localdomain [127.0.0.1]) by mail77-tx2
	(MessageSwitch) id 132283716865082_2126; Fri,  2 Dec 2011 14:46:08 +0000
	(UTC)
Received: from TX2EHSMHS015.bigfish.com (unknown [10.9.14.239])	by
	mail77-tx2.bigfish.com (Postfix) with ESMTP id 8EFF8640186;
	Fri,  2 Dec 2011 14:45:03 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	TX2EHSMHS015.bigfish.com (10.9.99.115) with Microsoft SMTP Server id
	14.1.225.22; Fri, 2 Dec 2011 14:45:02 +0000
X-WSS-ID: 0LVKZMZ-01-F6X-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 20DB3102814D;	Fri,  2 Dec 2011 08:44:58 -0600 (CST)
Received: from SAUSEXDAG04.amd.com (163.181.55.4) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Fri, 2 Dec 2011 08:45:17 -0600
Received: from storexhtp02.amd.com (172.24.4.4) by sausexdag04.amd.com
	(163.181.55.4) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Fri, 2 Dec 2011 08:44:58 -0600
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Fri, 2 Dec 2011
	09:45:05 -0500
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 2CE4D49C0F1; Fri,  2 Dec 2011
	14:44:57 +0000 (GMT)
Received: from [165.204.15.38] (wanderer.osrc.amd.com [165.204.15.38])	by
	mail.osrc.amd.com (Postfix) with ESMTPS id 16A615940FF; Fri,  2 Dec 2011
	15:44:57 +0100 (CET)
Message-ID: <4ED8E3BF.6050509@amd.com>
Date: Fri, 2 Dec 2011 15:42:07 +0100
From: Andre Przywara <andre.przywara@amd.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.18) Gecko/20110705 Lightning/1.0b2 Thunderbird/3.1.11
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Content-Type: multipart/mixed; boundary="------------050605000401050307090709"
X-OriginatorOrg: amd.com
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: [Xen-devel] [PATCH] xl: fix compiler warnings
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--------------050605000401050307090709
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit

Hi,

either GCC 4.6.1 or Ubuntu add -Werror=format-security to the -Wall set, 
so libxl compilation breaks:
   libxl_create.c: In function 'store_libxl_entry':
   libxl_create.c:454:9: error: format not a string literal and no 
format arguments [-Werror=format-security]
   cc1: all warnings being treated as errors

attached patch fixes this and another occurrence.

Patch from: Uwe Dannowski

Signed-off-by: Andre Przywara <andre.przywara@amd.com>

Regards,
Andre.

-- 
Andre Przywara
AMD-Operating System Research Center (OSRC), Dresden, Germany

--------------050605000401050307090709
Content-Type: text/x-patch; name="libxl_sprintf_security.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="libxl_sprintf_security.patch"
Content-Description: libxl_sprintf_security.patch

diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index ce6a55e..6486156 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -461,7 +461,7 @@ static int store_libxl_entry(libxl__gc *gc, uint32_t domid,
 
     path = libxl__xs_libxl_path(gc, domid);
     path = libxl__sprintf(gc, "%s/dm-version", path);
-    return libxl__xs_write(gc, XBT_NULL, path, libxl__strdup(gc,
+    return libxl__xs_write(gc, XBT_NULL, path, "%s", libxl__strdup(gc,
         libxl_device_model_version_to_string(dm_info->device_model_version)));
 }
 
diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c
index a53fb70..1db395c 100644
--- a/tools/libxl/libxl_device.c
+++ b/tools/libxl/libxl_device.c
@@ -516,7 +516,7 @@ int libxl__devices_destroy(libxl__gc *gc, uint32_t domid, int force)
         for (j = 0; j < num_devs; j++) {
             path = libxl__sprintf(gc, "/local/domain/%d/device/%s/%s/backend",
                                   domid, kinds[i], devs[j]);
-            path = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, path));
+            path = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s", path));
             if (path && libxl__parse_backend_path(gc, path, &dev) == 0) {
                 dev.domid = domid;
                 dev.kind = kind;

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

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

--------------050605000401050307090709--


From xen-devel-bounces@lists.xensource.com Fri Dec 02 14:59:33 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 14:59:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWUZz-0008Sz-Gl; Fri, 02 Dec 2011 14:59:11 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <henanwxr@hotmail.com>) id 1RWUZy-0008Su-In
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 14:59:10 +0000
X-Env-Sender: henanwxr@hotmail.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1322837908!4019180!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.1 required=7.0 tests=FORGED_HOTMAIL_RCVD,
	ML_RADAR_SPEW_LINKS_14,spamassassin: 
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19892 invoked from network); 2 Dec 2011 14:58:29 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-13.tower-174.messagelabs.com with AES256-SHA encrypted SMTP;
	2 Dec 2011 14:58:29 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <henanwxr@hotmail.com>) id 1RWUZH-0007zY-Oi
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 06:58:27 -0800
Date: Fri, 2 Dec 2011 06:58:27 -0800 (PST)
From: confucius <henanwxr@hotmail.com>
To: xen-devel@lists.xensource.com
Message-ID: <1322837907759-5042107.post@n5.nabble.com>
In-Reply-To: <1322705286985-5037367.post@n5.nabble.com>
References: <1322705286985-5037367.post@n5.nabble.com>
MIME-Version: 1.0
Subject: Re: [Xen-devel] How does vmm get all mmio areas of pci devices?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Thanks for your reply,George. Now I am trying to understand what you have
explained.

1: vmm doesn't  consider where the mmio area of device placed, so it needn't
to set ept entry for   capturing mmio operation of guest os. Instead, vmm
only considers(or register) the memory areas where it can access
directly,and set corresponding ept entry. when vmm found some memory areas
it can't access(maybe the mmio area), it will send these areas to
qemu-dm.qemu-dm will process these.
Am I right?

2: I am not very clear how virtual DMA operate between vmm and qemu-dm.
Because the target physical address of DMA operation is not fixed like other
MMIO areas(for example ,vga buffer placed 0xA0000~0xC0000),it was specified
by the driver, so qemu-dm can't register callback function for these target
physical like other MMIO areas. when virtual DMA write memory in qemu
address space, what will happend? just do nothing, if so, how does virtual
DMA transfer result of writing to vmm (or guest os)?

3: I want to konw whether exist  MMIO areas that can't recognised by
qemu-dm, and how qemu-dm process it? 


--
View this message in context: http://xen.1045712.n5.nabble.com/How-does-vmm-get-all-mmio-areas-of-pci-devices-tp5037367p5042107.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

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

From xen-devel-bounces@lists.xensource.com Fri Dec 02 14:59:33 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 14:59:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWUZz-0008Sz-Gl; Fri, 02 Dec 2011 14:59:11 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <henanwxr@hotmail.com>) id 1RWUZy-0008Su-In
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 14:59:10 +0000
X-Env-Sender: henanwxr@hotmail.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1322837908!4019180!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.1 required=7.0 tests=FORGED_HOTMAIL_RCVD,
	ML_RADAR_SPEW_LINKS_14,spamassassin: 
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19892 invoked from network); 2 Dec 2011 14:58:29 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-13.tower-174.messagelabs.com with AES256-SHA encrypted SMTP;
	2 Dec 2011 14:58:29 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <henanwxr@hotmail.com>) id 1RWUZH-0007zY-Oi
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 06:58:27 -0800
Date: Fri, 2 Dec 2011 06:58:27 -0800 (PST)
From: confucius <henanwxr@hotmail.com>
To: xen-devel@lists.xensource.com
Message-ID: <1322837907759-5042107.post@n5.nabble.com>
In-Reply-To: <1322705286985-5037367.post@n5.nabble.com>
References: <1322705286985-5037367.post@n5.nabble.com>
MIME-Version: 1.0
Subject: Re: [Xen-devel] How does vmm get all mmio areas of pci devices?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Thanks for your reply,George. Now I am trying to understand what you have
explained.

1: vmm doesn't  consider where the mmio area of device placed, so it needn't
to set ept entry for   capturing mmio operation of guest os. Instead, vmm
only considers(or register) the memory areas where it can access
directly,and set corresponding ept entry. when vmm found some memory areas
it can't access(maybe the mmio area), it will send these areas to
qemu-dm.qemu-dm will process these.
Am I right?

2: I am not very clear how virtual DMA operate between vmm and qemu-dm.
Because the target physical address of DMA operation is not fixed like other
MMIO areas(for example ,vga buffer placed 0xA0000~0xC0000),it was specified
by the driver, so qemu-dm can't register callback function for these target
physical like other MMIO areas. when virtual DMA write memory in qemu
address space, what will happend? just do nothing, if so, how does virtual
DMA transfer result of writing to vmm (or guest os)?

3: I want to konw whether exist  MMIO areas that can't recognised by
qemu-dm, and how qemu-dm process it? 


--
View this message in context: http://xen.1045712.n5.nabble.com/How-does-vmm-get-all-mmio-areas-of-pci-devices-tp5037367p5042107.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

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

From xen-devel-bounces@lists.xensource.com Fri Dec 02 15:13:47 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 15:13:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWUnp-0000LJ-2B; Fri, 02 Dec 2011 15:13:29 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <sploving1@gmail.com>) id 1RW6Bc-00006P-Ib
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 12:56:24 +0000
X-Env-Sender: sploving1@gmail.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1322744141!5798189!1
X-Originating-IP: [209.85.214.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19613 invoked from network); 1 Dec 2011 12:55:42 -0000
Received: from mail-bw0-f43.google.com (HELO mail-bw0-f43.google.com)
	(209.85.214.43)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 12:55:42 -0000
Received: by bkwj4 with SMTP id j4so1498349bkw.30
	for <xen-devel@lists.xensource.com>;
	Thu, 01 Dec 2011 04:55:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	bh=Z5WOoNH3Qk49mkqtSfVjm2fMVhAYfczDjX8PNfXWpIQ=;
	b=qtzKLvToeoRK0IISGFgTGxWB0KEbGL4Vdp3l2maN/y66Has/3/ISXpdMCSNexMxEYZ
	CpwNNVa76GoQaqZ3ZcQ1P+ZUBD4vU2bB1S6nL/tDvkUop4OYgw+jyrX2EL9f6493pkoK
	Z/shdlk3u1S5HLCahKPdtRYFYhQSyyavSrXB8=
MIME-Version: 1.0
Received: by 10.204.153.195 with SMTP id l3mr7170056bkw.132.1322744140553;
	Thu, 01 Dec 2011 04:55:40 -0800 (PST)
Received: by 10.204.130.16 with HTTP; Thu, 1 Dec 2011 04:55:40 -0800 (PST)
In-Reply-To: <CAFLBxZYu4ormVzBJgakptUL6NvQSJrdQZUSVjeJtP4LCdVj3CA@mail.gmail.com>
References: <CAP=GMUEvnnOGmiM9ar+oQw4c6fwzvWa+HX98C3kV_XgMc3xg9Q@mail.gmail.com>
	<CAFLBxZYu4ormVzBJgakptUL6NvQSJrdQZUSVjeJtP4LCdVj3CA@mail.gmail.com>
Date: Thu, 1 Dec 2011 20:55:40 +0800
Message-ID: <CAP=GMUEXx9Z58srj0E4EWGwUqGpYHPFUFWB4znpco0rCY=BF1A@mail.gmail.com>
From: Baozeng <sploving1@gmail.com>
To: George Dunlap <George.Dunlap@eu.citrix.com>
X-Mailman-Approved-At: Fri, 02 Dec 2011 15:13:26 +0000
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] any exit function in xen that is similar to
	exit_kernel?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

2011/12/1 George Dunlap <George.Dunlap@eu.citrix.com>:
> On Tue, Nov 29, 2011 at 2:22 PM, Baozeng <sploving1@gmail.com> wrote:
>> Hello all,
>> I added a hypercall "do_greet" that only prints "Hello world" to do a
>> small experiment. After it prints the "hello world", I would it to
>> exit from Xen and stop current process. For instance:
>> the hypercall is like this:
>> int do_greet(){
>> =A0 pirntk("Hello world\n");
>> =A0 /*then I would it exit from Xen and stop current process that called=
 it.*/
>> =A0 exit_?? //exit(0) does not work.
>> }
>>
>> If a process at the application level calls this hypercall through
>> privcmd file, I would like it kill this process after the hypercall
>> prints "Hello world". Then how to do that?
>
> A process is a guest kernel-level construct. =A0Xen doesn't know
> anything about processes; it only knows things about VMs. =A0You can
> easily kill the guest by doing this:
> =A0domain_crash(current->domain);
>
> If you want the process only to be killed, you have to have the guest
> kernel do it.
>
Okay. I know. It need first return to the kernel address space. Then
is there any function that can return the kernel address space from
Xen after the hypercall? like this:
 int do_greet(){
    pirntk("Hello world\n");
    /*then I would it exit from Xen to the kernel.*/
    exit_??  // after that CS and EIP should pointer to the kernel
address space.
 }

if there doesnot exiest such function, how can I know which function
switches kernel into  Xen to trigger such hypercall, so that I can
return it by myself. Is it in the entry.S, when int $82 instruction
happen, then the CS and EIP begin to switch point to Xen? thanks

> =A0-George



-- =

=A0=A0=A0=A0 Best Regards,
=A0=A0=A0=A0=A0=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0=A0=A0=A0 Baozeng Ding
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 OSTG,NFS,ISCAS

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

From xen-devel-bounces@lists.xensource.com Fri Dec 02 15:13:47 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 15:13:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWUnp-0000LJ-2B; Fri, 02 Dec 2011 15:13:29 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <sploving1@gmail.com>) id 1RW6Bc-00006P-Ib
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 12:56:24 +0000
X-Env-Sender: sploving1@gmail.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1322744141!5798189!1
X-Originating-IP: [209.85.214.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19613 invoked from network); 1 Dec 2011 12:55:42 -0000
Received: from mail-bw0-f43.google.com (HELO mail-bw0-f43.google.com)
	(209.85.214.43)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 12:55:42 -0000
Received: by bkwj4 with SMTP id j4so1498349bkw.30
	for <xen-devel@lists.xensource.com>;
	Thu, 01 Dec 2011 04:55:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	bh=Z5WOoNH3Qk49mkqtSfVjm2fMVhAYfczDjX8PNfXWpIQ=;
	b=qtzKLvToeoRK0IISGFgTGxWB0KEbGL4Vdp3l2maN/y66Has/3/ISXpdMCSNexMxEYZ
	CpwNNVa76GoQaqZ3ZcQ1P+ZUBD4vU2bB1S6nL/tDvkUop4OYgw+jyrX2EL9f6493pkoK
	Z/shdlk3u1S5HLCahKPdtRYFYhQSyyavSrXB8=
MIME-Version: 1.0
Received: by 10.204.153.195 with SMTP id l3mr7170056bkw.132.1322744140553;
	Thu, 01 Dec 2011 04:55:40 -0800 (PST)
Received: by 10.204.130.16 with HTTP; Thu, 1 Dec 2011 04:55:40 -0800 (PST)
In-Reply-To: <CAFLBxZYu4ormVzBJgakptUL6NvQSJrdQZUSVjeJtP4LCdVj3CA@mail.gmail.com>
References: <CAP=GMUEvnnOGmiM9ar+oQw4c6fwzvWa+HX98C3kV_XgMc3xg9Q@mail.gmail.com>
	<CAFLBxZYu4ormVzBJgakptUL6NvQSJrdQZUSVjeJtP4LCdVj3CA@mail.gmail.com>
Date: Thu, 1 Dec 2011 20:55:40 +0800
Message-ID: <CAP=GMUEXx9Z58srj0E4EWGwUqGpYHPFUFWB4znpco0rCY=BF1A@mail.gmail.com>
From: Baozeng <sploving1@gmail.com>
To: George Dunlap <George.Dunlap@eu.citrix.com>
X-Mailman-Approved-At: Fri, 02 Dec 2011 15:13:26 +0000
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] any exit function in xen that is similar to
	exit_kernel?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

2011/12/1 George Dunlap <George.Dunlap@eu.citrix.com>:
> On Tue, Nov 29, 2011 at 2:22 PM, Baozeng <sploving1@gmail.com> wrote:
>> Hello all,
>> I added a hypercall "do_greet" that only prints "Hello world" to do a
>> small experiment. After it prints the "hello world", I would it to
>> exit from Xen and stop current process. For instance:
>> the hypercall is like this:
>> int do_greet(){
>> =A0 pirntk("Hello world\n");
>> =A0 /*then I would it exit from Xen and stop current process that called=
 it.*/
>> =A0 exit_?? //exit(0) does not work.
>> }
>>
>> If a process at the application level calls this hypercall through
>> privcmd file, I would like it kill this process after the hypercall
>> prints "Hello world". Then how to do that?
>
> A process is a guest kernel-level construct. =A0Xen doesn't know
> anything about processes; it only knows things about VMs. =A0You can
> easily kill the guest by doing this:
> =A0domain_crash(current->domain);
>
> If you want the process only to be killed, you have to have the guest
> kernel do it.
>
Okay. I know. It need first return to the kernel address space. Then
is there any function that can return the kernel address space from
Xen after the hypercall? like this:
 int do_greet(){
    pirntk("Hello world\n");
    /*then I would it exit from Xen to the kernel.*/
    exit_??  // after that CS and EIP should pointer to the kernel
address space.
 }

if there doesnot exiest such function, how can I know which function
switches kernel into  Xen to trigger such hypercall, so that I can
return it by myself. Is it in the entry.S, when int $82 instruction
happen, then the CS and EIP begin to switch point to Xen? thanks

> =A0-George



-- =

=A0=A0=A0=A0 Best Regards,
=A0=A0=A0=A0=A0=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0=A0=A0=A0 Baozeng Ding
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 OSTG,NFS,ISCAS

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

From xen-devel-bounces@lists.xensource.com Fri Dec 02 15:13:47 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 15:13:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWUnr-0000MF-4K; Fri, 02 Dec 2011 15:13:31 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raghukt@linux.vnet.ibm.com>) id 1RWCgW-0007Fv-Dw
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 19:52:44 +0000
X-Env-Sender: raghukt@linux.vnet.ibm.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1322769078!55678337!1
X-Originating-IP: [122.248.162.5]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTIyLjI0OC4xNjIuNSA9PiAxOTMzMDk=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1053 invoked from network); 1 Dec 2011 19:51:22 -0000
Received: from e28smtp05.in.ibm.com (HELO e28smtp05.in.ibm.com) (122.248.162.5)
	by server-2.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 1 Dec 2011 19:51:22 -0000
Received: from /spool/local
	by e28smtp05.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use
	Only! Violators will be prosecuted
	for <xen-devel@lists.xensource.com> from <raghukt@linux.vnet.ibm.com>; 
	Fri, 2 Dec 2011 01:22:01 +0530
Received: from d28relay03.in.ibm.com (9.184.220.60)
	by e28smtp05.in.ibm.com (192.168.1.135) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Fri, 2 Dec 2011 01:21:57 +0530
Received: from d28av01.in.ibm.com (d28av01.in.ibm.com [9.184.220.63])
	by d28relay03.in.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	pB1JoeUf3698920
	for <xen-devel@lists.xensource.com>; Fri, 2 Dec 2011 01:20:41 +0530
Received: from d28av01.in.ibm.com (loopback [127.0.0.1])
	by d28av01.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id
	pB1JocFe024170
	for <xen-devel@lists.xensource.com>; Fri, 2 Dec 2011 01:20:40 +0530
Received: from oc5400248562.ibm.com ([9.77.201.66])
	by d28av01.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	pB1JoZ5K024108; Fri, 2 Dec 2011 01:20:35 +0530
Message-ID: <4ED7DA85.5080504@linux.vnet.ibm.com>
Date: Fri, 02 Dec 2011 01:20:29 +0530
From: Raghavendra K T <raghukt@linux.vnet.ibm.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
	rv:1.9.2.24) Gecko/20111108 Fedora/3.1.16-1.fc14 Thunderbird/3.1.16
MIME-Version: 1.0
To: Avi Kivity <avi@redhat.com>
References: <20111130085921.23386.89708.sendpatchset@oc5400248562.ibm.com>
	<20111130085959.23386.69166.sendpatchset@oc5400248562.ibm.com>
	<4ED760F1.6080804@redhat.com>
In-Reply-To: <4ED760F1.6080804@redhat.com>
x-cbid: 11120119-8256-0000-0000-0000005B59B4
X-Mailman-Approved-At: Fri, 02 Dec 2011 15:13:26 +0000
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, x86@kernel.org,
	Gleb Natapov <gleb@redhat.com>, Peter Zijlstra <peterz@infradead.org>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Xen <xen-devel@lists.xensource.com>,
	Dave Jiang <dave.jiang@intel.com>, KVM <kvm@vger.kernel.org>,
	Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	Ingo Molnar <mingo@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Marcelo Tosatti <mtosatti@redhat.com>,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>,
	Sasha Levin <levinsasha928@gmail.com>, Sedat Dilek <sedat.dilek@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>, Yinghai Lu <yinghai@kernel.org>,
	Greg Kroah-Hartman <gregkh@suse.de>, LKML <linux-kernel@vger.kernel.org>,
	Dave Hansen <dave@linux.vnet.ibm.com>,
	Suzuki Poulose <suzuki@linux.vnet.ibm.com>
Subject: Re: [Xen-devel] [PATCH RFC V3 2/4] kvm hypervisor : Add a hypercall
 to KVM hypervisor to support pv-ticketlocks
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

[ CCing Jeremy's new email ID ]
Hi Avi,
Thanks for review and inputs.

On 12/01/2011 04:41 PM, Avi Kivity wrote:
> On 11/30/2011 10:59 AM, Raghavendra K T wrote:
>
> The hypercall needs to be documented in
> Documentation/virtual/kvm/hypercalls.txt.
>

Yes, Sure 'll document.  hypercalls.txt is a new file right?. also I 
have to document APIs in Documentation/virtual/kvm/api.txt.

> Have you tested it on AMD machines?  There are some differences in the
> hypercall infrastructure there.

Yes. 'll test on AMD machine and update on that.

>
>>   /* This indicates that the new set of kvmclock msrs
>>    * are available. The use of 0x11 and 0x12 is deprecated
>>    */
>>   #define KVM_FEATURE_CLOCKSOURCE2        3
>>   #define KVM_FEATURE_ASYNC_PF		4
>>   #define KVM_FEATURE_STEAL_TIME		5
>> +#define KVM_FEATURE_KICK_VCPU		6
>
> Documentation/virtual/kvm/cpuid.txt.

Yes. 'll do that.

>
>>
>>   /* The last 8 bits are used to indicate how to interpret the flags field
>>    * in pvclock structure. If no bits are set, all flags are ignored.
>> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
>> index c38efd7..6e1c8b4 100644
>> --- a/arch/x86/kvm/x86.c
>> +++ b/arch/x86/kvm/x86.c
>> @@ -2103,6 +2103,7 @@ int kvm_dev_ioctl_check_extension(long ext)
>>   	case KVM_CAP_XSAVE:
>>   	case KVM_CAP_ASYNC_PF:
>>   	case KVM_CAP_GET_TSC_KHZ:
>> +	case KVM_CAP_KICK_VCPU:
>
> This is redundant with the feature bit?  In general, KVM_CAP is for the
> host API, while KVM_FEATURE is for the guest API.
>

No its not. I have to check the flow again. I understood that this 
completes the guest querying, that checks for KVM_FEATURE availability.
Did I miss something? I need a little deep dive though.

>>
>> +/*
>> + * kvm_pv_kick_cpu_op:  Kick a vcpu.
>> + *
>> + * @cpu - vcpu to be kicked.
>> + */
>> +static void kvm_pv_kick_cpu_op(struct kvm *kvm, int cpu)
>> +{
>> +	struct kvm_vcpu *vcpu = kvm_get_vcpu(kvm, cpu);
>
> There is no guarantee that guest cpu numbers match host vcpu numbers.
> Use APIC IDs, and kvm_apic_match_dest().

Okay. I have to dig more on this.

>
>> +	struct kvm_mp_state mp_state;
>> +
>> +	mp_state.mp_state = KVM_MP_STATE_RUNNABLE;
>> +	if (vcpu) {
>> +		vcpu->kicked = 1;
>> +		/* Ensure kicked is always set before wakeup */
>> +		barrier();
>> +	}
>> +	kvm_arch_vcpu_ioctl_set_mpstate(vcpu,&mp_state);
>
> This must only be called from the vcpu thread.

Hmm. Okay. 'll check this.

>
>> +	kvm_vcpu_kick(vcpu);
>> +}
>> +
>>
>>   	struct kvm_vcpu_arch arch;
>> +
>> +	/*
>> +	 * blocked vcpu wakes up by checking this flag set by unlocker.
>> +	 */
>> +	int kicked;
>>
>
> Write only variable.

Yes 'll remove comments.

>
> An alternative approach is to use an MSR protocol like x2apic ICR.
>

'll explore on this too.


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

From xen-devel-bounces@lists.xensource.com Fri Dec 02 15:13:47 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 15:13:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWUnr-0000MF-4K; Fri, 02 Dec 2011 15:13:31 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raghukt@linux.vnet.ibm.com>) id 1RWCgW-0007Fv-Dw
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 19:52:44 +0000
X-Env-Sender: raghukt@linux.vnet.ibm.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1322769078!55678337!1
X-Originating-IP: [122.248.162.5]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTIyLjI0OC4xNjIuNSA9PiAxOTMzMDk=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1053 invoked from network); 1 Dec 2011 19:51:22 -0000
Received: from e28smtp05.in.ibm.com (HELO e28smtp05.in.ibm.com) (122.248.162.5)
	by server-2.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 1 Dec 2011 19:51:22 -0000
Received: from /spool/local
	by e28smtp05.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use
	Only! Violators will be prosecuted
	for <xen-devel@lists.xensource.com> from <raghukt@linux.vnet.ibm.com>; 
	Fri, 2 Dec 2011 01:22:01 +0530
Received: from d28relay03.in.ibm.com (9.184.220.60)
	by e28smtp05.in.ibm.com (192.168.1.135) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Fri, 2 Dec 2011 01:21:57 +0530
Received: from d28av01.in.ibm.com (d28av01.in.ibm.com [9.184.220.63])
	by d28relay03.in.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	pB1JoeUf3698920
	for <xen-devel@lists.xensource.com>; Fri, 2 Dec 2011 01:20:41 +0530
Received: from d28av01.in.ibm.com (loopback [127.0.0.1])
	by d28av01.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id
	pB1JocFe024170
	for <xen-devel@lists.xensource.com>; Fri, 2 Dec 2011 01:20:40 +0530
Received: from oc5400248562.ibm.com ([9.77.201.66])
	by d28av01.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	pB1JoZ5K024108; Fri, 2 Dec 2011 01:20:35 +0530
Message-ID: <4ED7DA85.5080504@linux.vnet.ibm.com>
Date: Fri, 02 Dec 2011 01:20:29 +0530
From: Raghavendra K T <raghukt@linux.vnet.ibm.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
	rv:1.9.2.24) Gecko/20111108 Fedora/3.1.16-1.fc14 Thunderbird/3.1.16
MIME-Version: 1.0
To: Avi Kivity <avi@redhat.com>
References: <20111130085921.23386.89708.sendpatchset@oc5400248562.ibm.com>
	<20111130085959.23386.69166.sendpatchset@oc5400248562.ibm.com>
	<4ED760F1.6080804@redhat.com>
In-Reply-To: <4ED760F1.6080804@redhat.com>
x-cbid: 11120119-8256-0000-0000-0000005B59B4
X-Mailman-Approved-At: Fri, 02 Dec 2011 15:13:26 +0000
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, x86@kernel.org,
	Gleb Natapov <gleb@redhat.com>, Peter Zijlstra <peterz@infradead.org>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Xen <xen-devel@lists.xensource.com>,
	Dave Jiang <dave.jiang@intel.com>, KVM <kvm@vger.kernel.org>,
	Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	Ingo Molnar <mingo@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Marcelo Tosatti <mtosatti@redhat.com>,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>,
	Sasha Levin <levinsasha928@gmail.com>, Sedat Dilek <sedat.dilek@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>, Yinghai Lu <yinghai@kernel.org>,
	Greg Kroah-Hartman <gregkh@suse.de>, LKML <linux-kernel@vger.kernel.org>,
	Dave Hansen <dave@linux.vnet.ibm.com>,
	Suzuki Poulose <suzuki@linux.vnet.ibm.com>
Subject: Re: [Xen-devel] [PATCH RFC V3 2/4] kvm hypervisor : Add a hypercall
 to KVM hypervisor to support pv-ticketlocks
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

[ CCing Jeremy's new email ID ]
Hi Avi,
Thanks for review and inputs.

On 12/01/2011 04:41 PM, Avi Kivity wrote:
> On 11/30/2011 10:59 AM, Raghavendra K T wrote:
>
> The hypercall needs to be documented in
> Documentation/virtual/kvm/hypercalls.txt.
>

Yes, Sure 'll document.  hypercalls.txt is a new file right?. also I 
have to document APIs in Documentation/virtual/kvm/api.txt.

> Have you tested it on AMD machines?  There are some differences in the
> hypercall infrastructure there.

Yes. 'll test on AMD machine and update on that.

>
>>   /* This indicates that the new set of kvmclock msrs
>>    * are available. The use of 0x11 and 0x12 is deprecated
>>    */
>>   #define KVM_FEATURE_CLOCKSOURCE2        3
>>   #define KVM_FEATURE_ASYNC_PF		4
>>   #define KVM_FEATURE_STEAL_TIME		5
>> +#define KVM_FEATURE_KICK_VCPU		6
>
> Documentation/virtual/kvm/cpuid.txt.

Yes. 'll do that.

>
>>
>>   /* The last 8 bits are used to indicate how to interpret the flags field
>>    * in pvclock structure. If no bits are set, all flags are ignored.
>> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
>> index c38efd7..6e1c8b4 100644
>> --- a/arch/x86/kvm/x86.c
>> +++ b/arch/x86/kvm/x86.c
>> @@ -2103,6 +2103,7 @@ int kvm_dev_ioctl_check_extension(long ext)
>>   	case KVM_CAP_XSAVE:
>>   	case KVM_CAP_ASYNC_PF:
>>   	case KVM_CAP_GET_TSC_KHZ:
>> +	case KVM_CAP_KICK_VCPU:
>
> This is redundant with the feature bit?  In general, KVM_CAP is for the
> host API, while KVM_FEATURE is for the guest API.
>

No its not. I have to check the flow again. I understood that this 
completes the guest querying, that checks for KVM_FEATURE availability.
Did I miss something? I need a little deep dive though.

>>
>> +/*
>> + * kvm_pv_kick_cpu_op:  Kick a vcpu.
>> + *
>> + * @cpu - vcpu to be kicked.
>> + */
>> +static void kvm_pv_kick_cpu_op(struct kvm *kvm, int cpu)
>> +{
>> +	struct kvm_vcpu *vcpu = kvm_get_vcpu(kvm, cpu);
>
> There is no guarantee that guest cpu numbers match host vcpu numbers.
> Use APIC IDs, and kvm_apic_match_dest().

Okay. I have to dig more on this.

>
>> +	struct kvm_mp_state mp_state;
>> +
>> +	mp_state.mp_state = KVM_MP_STATE_RUNNABLE;
>> +	if (vcpu) {
>> +		vcpu->kicked = 1;
>> +		/* Ensure kicked is always set before wakeup */
>> +		barrier();
>> +	}
>> +	kvm_arch_vcpu_ioctl_set_mpstate(vcpu,&mp_state);
>
> This must only be called from the vcpu thread.

Hmm. Okay. 'll check this.

>
>> +	kvm_vcpu_kick(vcpu);
>> +}
>> +
>>
>>   	struct kvm_vcpu_arch arch;
>> +
>> +	/*
>> +	 * blocked vcpu wakes up by checking this flag set by unlocker.
>> +	 */
>> +	int kicked;
>>
>
> Write only variable.

Yes 'll remove comments.

>
> An alternative approach is to use an MSR protocol like x2apic ICR.
>

'll explore on this too.


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

From xen-devel-bounces@lists.xensource.com Fri Dec 02 15:13:48 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 15:13:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWUnr-0000MR-I1; Fri, 02 Dec 2011 15:13:31 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raghukt@linux.vnet.ibm.com>) id 1RWSFi-0005Sj-Ag
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 12:30:06 +0000
X-Env-Sender: raghukt@linux.vnet.ibm.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1322828948!47992098!1
X-Originating-IP: [122.248.162.7]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTIyLjI0OC4xNjIuNyA9PiA0MDg3Mg==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4408 invoked from network); 2 Dec 2011 12:29:12 -0000
Received: from e28smtp07.in.ibm.com (HELO e28smtp07.in.ibm.com) (122.248.162.7)
	by server-11.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 2 Dec 2011 12:29:12 -0000
Received: from /spool/local
	by e28smtp07.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use
	Only! Violators will be prosecuted
	for <xen-devel@lists.xensource.com> from <raghukt@linux.vnet.ibm.com>; 
	Fri, 2 Dec 2011 17:59:24 +0530
Received: from d28relay03.in.ibm.com (9.184.220.60)
	by e28smtp07.in.ibm.com (192.168.1.137) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Fri, 2 Dec 2011 17:59:19 +0530
Received: from d28av01.in.ibm.com (d28av01.in.ibm.com [9.184.220.63])
	by d28relay03.in.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	pB2CTIa13305522
	for <xen-devel@lists.xensource.com>; Fri, 2 Dec 2011 17:59:18 +0530
Received: from d28av01.in.ibm.com (loopback [127.0.0.1])
	by d28av01.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id
	pB2CTGUQ030277
	for <xen-devel@lists.xensource.com>; Fri, 2 Dec 2011 17:59:18 +0530
Received: from oc5400248562.ibm.com (oc5400248562.in.ibm.com [9.124.158.226])
	by d28av01.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	pB2CTF7t030231; Fri, 2 Dec 2011 17:59:15 +0530
Message-ID: <4ED8C49C.8070306@linux.vnet.ibm.com>
Date: Fri, 02 Dec 2011 17:59:16 +0530
From: Raghavendra K T <raghukt@linux.vnet.ibm.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
	rv:1.9.2.24) Gecko/20111108 Fedora/3.1.16-1.fc14 Thunderbird/3.1.16
MIME-Version: 1.0
To: Avi Kivity <avi@redhat.com>
References: <20111130085921.23386.89708.sendpatchset@oc5400248562.ibm.com>
	<20111130085959.23386.69166.sendpatchset@oc5400248562.ibm.com>
	<4ED760F1.6080804@redhat.com> <4ED7DA85.5080504@linux.vnet.ibm.com>
In-Reply-To: <4ED7DA85.5080504@linux.vnet.ibm.com>
x-cbid: 11120212-8878-0000-0000-0000007138E8
X-Mailman-Approved-At: Fri, 02 Dec 2011 15:13:26 +0000
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, x86@kernel.org,
	Gleb Natapov <gleb@redhat.com>, Peter Zijlstra <peterz@infradead.org>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Xen <xen-devel@lists.xensource.com>,
	Dave Jiang <dave.jiang@intel.com>, KVM <kvm@vger.kernel.org>,
	Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	Ingo Molnar <mingo@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Marcelo Tosatti <mtosatti@redhat.com>,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>,
	Sasha Levin <levinsasha928@gmail.com>, Sedat Dilek <sedat.dilek@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>, Yinghai Lu <yinghai@kernel.org>,
	Greg Kroah-Hartman <gregkh@suse.de>, LKML <linux-kernel@vger.kernel.org>,
	Dave Hansen <dave@linux.vnet.ibm.com>,
	Suzuki Poulose <suzuki@linux.vnet.ibm.com>
Subject: Re: [Xen-devel] [PATCH RFC V3 2/4] kvm hypervisor : Add a hypercall
 to KVM hypervisor to support pv-ticketlocks
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 12/02/2011 01:20 AM, Raghavendra K T wrote:
>>> + struct kvm_mp_state mp_state;
>>> +
>>> + mp_state.mp_state = KVM_MP_STATE_RUNNABLE;
>>> + if (vcpu) {
>>> + vcpu->kicked = 1;
>>> + /* Ensure kicked is always set before wakeup */
>>> + barrier();
>>> + }
>>> + kvm_arch_vcpu_ioctl_set_mpstate(vcpu,&mp_state);
>>
>> This must only be called from the vcpu thread.
>
> Hmm. Okay. 'll check this.
>

Yes true. kvm_arch_vcpu_ioctl_set_mpstate itself is redundant, and will 
remove this.


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

From xen-devel-bounces@lists.xensource.com Fri Dec 02 15:13:48 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 15:13:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWUnr-0000MR-I1; Fri, 02 Dec 2011 15:13:31 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raghukt@linux.vnet.ibm.com>) id 1RWSFi-0005Sj-Ag
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 12:30:06 +0000
X-Env-Sender: raghukt@linux.vnet.ibm.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1322828948!47992098!1
X-Originating-IP: [122.248.162.7]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTIyLjI0OC4xNjIuNyA9PiA0MDg3Mg==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4408 invoked from network); 2 Dec 2011 12:29:12 -0000
Received: from e28smtp07.in.ibm.com (HELO e28smtp07.in.ibm.com) (122.248.162.7)
	by server-11.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 2 Dec 2011 12:29:12 -0000
Received: from /spool/local
	by e28smtp07.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use
	Only! Violators will be prosecuted
	for <xen-devel@lists.xensource.com> from <raghukt@linux.vnet.ibm.com>; 
	Fri, 2 Dec 2011 17:59:24 +0530
Received: from d28relay03.in.ibm.com (9.184.220.60)
	by e28smtp07.in.ibm.com (192.168.1.137) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Fri, 2 Dec 2011 17:59:19 +0530
Received: from d28av01.in.ibm.com (d28av01.in.ibm.com [9.184.220.63])
	by d28relay03.in.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	pB2CTIa13305522
	for <xen-devel@lists.xensource.com>; Fri, 2 Dec 2011 17:59:18 +0530
Received: from d28av01.in.ibm.com (loopback [127.0.0.1])
	by d28av01.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id
	pB2CTGUQ030277
	for <xen-devel@lists.xensource.com>; Fri, 2 Dec 2011 17:59:18 +0530
Received: from oc5400248562.ibm.com (oc5400248562.in.ibm.com [9.124.158.226])
	by d28av01.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	pB2CTF7t030231; Fri, 2 Dec 2011 17:59:15 +0530
Message-ID: <4ED8C49C.8070306@linux.vnet.ibm.com>
Date: Fri, 02 Dec 2011 17:59:16 +0530
From: Raghavendra K T <raghukt@linux.vnet.ibm.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
	rv:1.9.2.24) Gecko/20111108 Fedora/3.1.16-1.fc14 Thunderbird/3.1.16
MIME-Version: 1.0
To: Avi Kivity <avi@redhat.com>
References: <20111130085921.23386.89708.sendpatchset@oc5400248562.ibm.com>
	<20111130085959.23386.69166.sendpatchset@oc5400248562.ibm.com>
	<4ED760F1.6080804@redhat.com> <4ED7DA85.5080504@linux.vnet.ibm.com>
In-Reply-To: <4ED7DA85.5080504@linux.vnet.ibm.com>
x-cbid: 11120212-8878-0000-0000-0000007138E8
X-Mailman-Approved-At: Fri, 02 Dec 2011 15:13:26 +0000
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, x86@kernel.org,
	Gleb Natapov <gleb@redhat.com>, Peter Zijlstra <peterz@infradead.org>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Xen <xen-devel@lists.xensource.com>,
	Dave Jiang <dave.jiang@intel.com>, KVM <kvm@vger.kernel.org>,
	Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	Ingo Molnar <mingo@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Marcelo Tosatti <mtosatti@redhat.com>,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>,
	Sasha Levin <levinsasha928@gmail.com>, Sedat Dilek <sedat.dilek@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>, Yinghai Lu <yinghai@kernel.org>,
	Greg Kroah-Hartman <gregkh@suse.de>, LKML <linux-kernel@vger.kernel.org>,
	Dave Hansen <dave@linux.vnet.ibm.com>,
	Suzuki Poulose <suzuki@linux.vnet.ibm.com>
Subject: Re: [Xen-devel] [PATCH RFC V3 2/4] kvm hypervisor : Add a hypercall
 to KVM hypervisor to support pv-ticketlocks
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 12/02/2011 01:20 AM, Raghavendra K T wrote:
>>> + struct kvm_mp_state mp_state;
>>> +
>>> + mp_state.mp_state = KVM_MP_STATE_RUNNABLE;
>>> + if (vcpu) {
>>> + vcpu->kicked = 1;
>>> + /* Ensure kicked is always set before wakeup */
>>> + barrier();
>>> + }
>>> + kvm_arch_vcpu_ioctl_set_mpstate(vcpu,&mp_state);
>>
>> This must only be called from the vcpu thread.
>
> Hmm. Okay. 'll check this.
>

Yes true. kvm_arch_vcpu_ioctl_set_mpstate itself is redundant, and will 
remove this.


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

From xen-devel-bounces@lists.xensource.com Fri Dec 02 15:13:48 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 15:13:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWUno-0000LA-LI; Fri, 02 Dec 2011 15:13:28 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <avi@redhat.com>) id 1RW4ZK-0004Yg-Rl
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 11:12:47 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1322737904!43156855!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDU3OTQ=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15222 invoked from network); 1 Dec 2011 11:11:45 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-12.tower-27.messagelabs.com with SMTP;
	1 Dec 2011 11:11:45 -0000
Received: from int-mx02.intmail.prod.int.phx2.redhat.com
	(int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id pB1BBqD4021376
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 1 Dec 2011 06:11:52 -0500
Received: from balrog.usersys.redhat.com (dhcp-4-24.tlv.redhat.com
	[10.35.4.24])
	by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP
	id pB1BBjfK013442; Thu, 1 Dec 2011 06:11:46 -0500
Message-ID: <4ED760F1.6080804@redhat.com>
Date: Thu, 01 Dec 2011 13:11:45 +0200
From: Avi Kivity <avi@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:8.0) Gecko/20111115 Thunderbird/8.0
MIME-Version: 1.0
To: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
References: <20111130085921.23386.89708.sendpatchset@oc5400248562.ibm.com>
	<20111130085959.23386.69166.sendpatchset@oc5400248562.ibm.com>
In-Reply-To: <20111130085959.23386.69166.sendpatchset@oc5400248562.ibm.com>
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.12
X-Mailman-Approved-At: Fri, 02 Dec 2011 15:13:26 +0000
Cc: Marcelo Tosatti <mtosatti@redhat.com>, Gleb Natapov <gleb@redhat.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>,
	Dave Jiang <dave.jiang@intel.com>, KVM <kvm@vger.kernel.org>,
	x86@kernel.org, Ingo Molnar <mingo@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Xen <xen-devel@lists.xensource.com>, Sasha Levin <levinsasha928@gmail.com>,
	Sedat Dilek <sedat.dilek@gmail.com>, Thomas Gleixner <tglx@linutronix.de>,
	Yinghai Lu <yinghai@kernel.org>, Greg Kroah-Hartman <gregkh@suse.de>,
	LKML <linux-kernel@vger.kernel.org>, Dave Hansen <dave@linux.vnet.ibm.com>,
	Suzuki Poulose <suzuki@linux.vnet.ibm.com>
Subject: Re: [Xen-devel] [PATCH RFC V3 2/4] kvm hypervisor : Add a hypercall
 to KVM hypervisor to support pv-ticketlocks
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 11/30/2011 10:59 AM, Raghavendra K T wrote:
> Add a hypercall to KVM hypervisor to support pv-ticketlocks 
>
> KVM_HC_KICK_CPU allows the calling vcpu to kick another vcpu out of halt state.
>     
> The presence of these hypercalls is indicated to guest via
> KVM_FEATURE_KICK_VCPU/KVM_CAP_KICK_VCPU.
>
> Qemu needs a corresponding patch to pass up the presence of this feature to 
> guest via cpuid. Patch to qemu will be sent separately.
>
> There is no Xen/KVM hypercall interface to await kick from.

The hypercall needs to be documented in
Documentation/virtual/kvm/hypercalls.txt.

Have you tested it on AMD machines?  There are some differences in the
hypercall infrastructure there.

>  /* This indicates that the new set of kvmclock msrs
>   * are available. The use of 0x11 and 0x12 is deprecated
>   */
>  #define KVM_FEATURE_CLOCKSOURCE2        3
>  #define KVM_FEATURE_ASYNC_PF		4
>  #define KVM_FEATURE_STEAL_TIME		5
> +#define KVM_FEATURE_KICK_VCPU		6

Documentation/virtual/kvm/cpuid.txt.

>  
>  /* The last 8 bits are used to indicate how to interpret the flags field
>   * in pvclock structure. If no bits are set, all flags are ignored.
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index c38efd7..6e1c8b4 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -2103,6 +2103,7 @@ int kvm_dev_ioctl_check_extension(long ext)
>  	case KVM_CAP_XSAVE:
>  	case KVM_CAP_ASYNC_PF:
>  	case KVM_CAP_GET_TSC_KHZ:
> +	case KVM_CAP_KICK_VCPU:

This is redundant with the feature bit?  In general, KVM_CAP is for the
host API, while KVM_FEATURE is for the guest API.

>  
> +/*
> + * kvm_pv_kick_cpu_op:  Kick a vcpu.
> + *
> + * @cpu - vcpu to be kicked.
> + */
> +static void kvm_pv_kick_cpu_op(struct kvm *kvm, int cpu)
> +{
> +	struct kvm_vcpu *vcpu = kvm_get_vcpu(kvm, cpu);

There is no guarantee that guest cpu numbers match host vcpu numbers. 
Use APIC IDs, and kvm_apic_match_dest().

> +	struct kvm_mp_state mp_state;
> +
> +	mp_state.mp_state = KVM_MP_STATE_RUNNABLE;
> +	if (vcpu) {
> +		vcpu->kicked = 1;
> +		/* Ensure kicked is always set before wakeup */
> +		barrier();
> +	}
> +	kvm_arch_vcpu_ioctl_set_mpstate(vcpu, &mp_state);

This must only be called from the vcpu thread.

> +	kvm_vcpu_kick(vcpu);
> +}
> +
>  
>  	struct kvm_vcpu_arch arch;
> +
> +	/*
> +	 * blocked vcpu wakes up by checking this flag set by unlocker.
> +	 */
> +	int kicked;
>

Write only variable.

An alternative approach is to use an MSR protocol like x2apic ICR.

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


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

From xen-devel-bounces@lists.xensource.com Fri Dec 02 15:13:48 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 15:13:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWUno-0000LA-LI; Fri, 02 Dec 2011 15:13:28 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <avi@redhat.com>) id 1RW4ZK-0004Yg-Rl
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 11:12:47 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1322737904!43156855!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDU3OTQ=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15222 invoked from network); 1 Dec 2011 11:11:45 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-12.tower-27.messagelabs.com with SMTP;
	1 Dec 2011 11:11:45 -0000
Received: from int-mx02.intmail.prod.int.phx2.redhat.com
	(int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id pB1BBqD4021376
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 1 Dec 2011 06:11:52 -0500
Received: from balrog.usersys.redhat.com (dhcp-4-24.tlv.redhat.com
	[10.35.4.24])
	by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP
	id pB1BBjfK013442; Thu, 1 Dec 2011 06:11:46 -0500
Message-ID: <4ED760F1.6080804@redhat.com>
Date: Thu, 01 Dec 2011 13:11:45 +0200
From: Avi Kivity <avi@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:8.0) Gecko/20111115 Thunderbird/8.0
MIME-Version: 1.0
To: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
References: <20111130085921.23386.89708.sendpatchset@oc5400248562.ibm.com>
	<20111130085959.23386.69166.sendpatchset@oc5400248562.ibm.com>
In-Reply-To: <20111130085959.23386.69166.sendpatchset@oc5400248562.ibm.com>
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.12
X-Mailman-Approved-At: Fri, 02 Dec 2011 15:13:26 +0000
Cc: Marcelo Tosatti <mtosatti@redhat.com>, Gleb Natapov <gleb@redhat.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>,
	Dave Jiang <dave.jiang@intel.com>, KVM <kvm@vger.kernel.org>,
	x86@kernel.org, Ingo Molnar <mingo@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Xen <xen-devel@lists.xensource.com>, Sasha Levin <levinsasha928@gmail.com>,
	Sedat Dilek <sedat.dilek@gmail.com>, Thomas Gleixner <tglx@linutronix.de>,
	Yinghai Lu <yinghai@kernel.org>, Greg Kroah-Hartman <gregkh@suse.de>,
	LKML <linux-kernel@vger.kernel.org>, Dave Hansen <dave@linux.vnet.ibm.com>,
	Suzuki Poulose <suzuki@linux.vnet.ibm.com>
Subject: Re: [Xen-devel] [PATCH RFC V3 2/4] kvm hypervisor : Add a hypercall
 to KVM hypervisor to support pv-ticketlocks
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 11/30/2011 10:59 AM, Raghavendra K T wrote:
> Add a hypercall to KVM hypervisor to support pv-ticketlocks 
>
> KVM_HC_KICK_CPU allows the calling vcpu to kick another vcpu out of halt state.
>     
> The presence of these hypercalls is indicated to guest via
> KVM_FEATURE_KICK_VCPU/KVM_CAP_KICK_VCPU.
>
> Qemu needs a corresponding patch to pass up the presence of this feature to 
> guest via cpuid. Patch to qemu will be sent separately.
>
> There is no Xen/KVM hypercall interface to await kick from.

The hypercall needs to be documented in
Documentation/virtual/kvm/hypercalls.txt.

Have you tested it on AMD machines?  There are some differences in the
hypercall infrastructure there.

>  /* This indicates that the new set of kvmclock msrs
>   * are available. The use of 0x11 and 0x12 is deprecated
>   */
>  #define KVM_FEATURE_CLOCKSOURCE2        3
>  #define KVM_FEATURE_ASYNC_PF		4
>  #define KVM_FEATURE_STEAL_TIME		5
> +#define KVM_FEATURE_KICK_VCPU		6

Documentation/virtual/kvm/cpuid.txt.

>  
>  /* The last 8 bits are used to indicate how to interpret the flags field
>   * in pvclock structure. If no bits are set, all flags are ignored.
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index c38efd7..6e1c8b4 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -2103,6 +2103,7 @@ int kvm_dev_ioctl_check_extension(long ext)
>  	case KVM_CAP_XSAVE:
>  	case KVM_CAP_ASYNC_PF:
>  	case KVM_CAP_GET_TSC_KHZ:
> +	case KVM_CAP_KICK_VCPU:

This is redundant with the feature bit?  In general, KVM_CAP is for the
host API, while KVM_FEATURE is for the guest API.

>  
> +/*
> + * kvm_pv_kick_cpu_op:  Kick a vcpu.
> + *
> + * @cpu - vcpu to be kicked.
> + */
> +static void kvm_pv_kick_cpu_op(struct kvm *kvm, int cpu)
> +{
> +	struct kvm_vcpu *vcpu = kvm_get_vcpu(kvm, cpu);

There is no guarantee that guest cpu numbers match host vcpu numbers. 
Use APIC IDs, and kvm_apic_match_dest().

> +	struct kvm_mp_state mp_state;
> +
> +	mp_state.mp_state = KVM_MP_STATE_RUNNABLE;
> +	if (vcpu) {
> +		vcpu->kicked = 1;
> +		/* Ensure kicked is always set before wakeup */
> +		barrier();
> +	}
> +	kvm_arch_vcpu_ioctl_set_mpstate(vcpu, &mp_state);

This must only be called from the vcpu thread.

> +	kvm_vcpu_kick(vcpu);
> +}
> +
>  
>  	struct kvm_vcpu_arch arch;
> +
> +	/*
> +	 * blocked vcpu wakes up by checking this flag set by unlocker.
> +	 */
> +	int kicked;
>

Write only variable.

An alternative approach is to use an MSR protocol like x2apic ICR.

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


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

From xen-devel-bounces@lists.xensource.com Fri Dec 02 15:13:49 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 15: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.xensource.com>)
	id 1RWUnq-0000Lo-A8; Fri, 02 Dec 2011 15:13:30 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <catalin.marinas@arm.com>) id 1RW975-00035B-EY
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 16:03:55 +0000
X-Env-Sender: catalin.marinas@arm.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1322755395!5514600!1
X-Originating-IP: [217.140.96.50]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24712 invoked from network); 1 Dec 2011 16:03:15 -0000
Received: from cam-admin0.cambridge.arm.com (HELO
	cam-admin0.cambridge.arm.com) (217.140.96.50)
	by server-5.tower-182.messagelabs.com with SMTP;
	1 Dec 2011 16:03:15 -0000
Received: from arm.com (e102109-lin.cambridge.arm.com [10.1.69.68])
	by cam-admin0.cambridge.arm.com (8.12.6/8.12.6) with ESMTP id
	pB1G2fWJ011688; Thu, 1 Dec 2011 16:02:42 GMT
Date: Thu, 1 Dec 2011 16:02:41 +0000
From: Catalin Marinas <catalin.marinas@arm.com>
To: Arnd Bergmann <arnd@arndb.de>
Message-ID: <20111201160241.GH27394@arm.com>
References: <alpine.DEB.2.00.1111281009090.31179@kaball-desktop>
	<1322735197.31810.191.camel@zakaz.uk.xensource.com>
	<20111201151043.GG27394@arm.com> <201112011542.19377.arnd@arndb.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <201112011542.19377.arnd@arndb.de>
User-Agent: Mutt/1.5.20 (2009-06-14)
X-Mailman-Approved-At: Fri, 02 Dec 2011 15:13:26 +0000
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linaro-dev@lists.linaro.org" <linaro-dev@lists.linaro.org>,
	Ian Campbell <Ian.Campbell@citrix.com>, Pawel Moll <Pawel.Moll@arm.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"virtualization@lists.linux-foundation.org"
	<virtualization@lists.linux-foundation.org>,
	"android-virt@lists.cs.columbia.edu" <android-virt@lists.cs.columbia.edu>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	"embeddedxen-devel@lists.sourceforge.net"
	<embeddedxen-devel@lists.sourceforge.net>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [Android-virt] [Embeddedxen-devel] [ANNOUNCE] Xen
 port to Cortex-A15 / ARMv7 with virt extensions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Dec 01, 2011 at 03:42:19PM +0000, Arnd Bergmann wrote:
> On Thursday 01 December 2011, Catalin Marinas wrote:
> > Given the way register banking is done on AArch64, issuing an HVC on a
> > 32-bit guest OS doesn't require translation on a 64-bit hypervisor. We
> > have a similar implementation at the SVC level (for 32-bit user apps on
> > a 64-bit kernel), the only modification was where a 32-bit SVC takes a
> > 64-bit parameter in two separate 32-bit registers, so packing needs to
> > be done in a syscall wrapper.
> 
> How do you deal with signed integer arguments passed into SVC or HVC from
> a caller? If I understand the architecture correctly, the upper
> halves of the argument register end up zero-padded, while the callee
> expects sign-extension.

If you treat it as an "int" (32-bit) and function prototype defined
accordingly, then the generated code only accesses it as a W (rather
than X) register and the top 32-bit part is ignored (no need for
sign-extension). If it is defined as a "long" in the 32-bit world, then
it indeed needs explicit conversion given the different sizes for long
(for example sys_lseek, the second argument is a 'long' and we do
explicit sign extension in the wrapper).

-- 
Catalin

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

From xen-devel-bounces@lists.xensource.com Fri Dec 02 15:13:49 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 15: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.xensource.com>)
	id 1RWUnq-0000Lo-A8; Fri, 02 Dec 2011 15:13:30 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <catalin.marinas@arm.com>) id 1RW975-00035B-EY
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 16:03:55 +0000
X-Env-Sender: catalin.marinas@arm.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1322755395!5514600!1
X-Originating-IP: [217.140.96.50]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24712 invoked from network); 1 Dec 2011 16:03:15 -0000
Received: from cam-admin0.cambridge.arm.com (HELO
	cam-admin0.cambridge.arm.com) (217.140.96.50)
	by server-5.tower-182.messagelabs.com with SMTP;
	1 Dec 2011 16:03:15 -0000
Received: from arm.com (e102109-lin.cambridge.arm.com [10.1.69.68])
	by cam-admin0.cambridge.arm.com (8.12.6/8.12.6) with ESMTP id
	pB1G2fWJ011688; Thu, 1 Dec 2011 16:02:42 GMT
Date: Thu, 1 Dec 2011 16:02:41 +0000
From: Catalin Marinas <catalin.marinas@arm.com>
To: Arnd Bergmann <arnd@arndb.de>
Message-ID: <20111201160241.GH27394@arm.com>
References: <alpine.DEB.2.00.1111281009090.31179@kaball-desktop>
	<1322735197.31810.191.camel@zakaz.uk.xensource.com>
	<20111201151043.GG27394@arm.com> <201112011542.19377.arnd@arndb.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <201112011542.19377.arnd@arndb.de>
User-Agent: Mutt/1.5.20 (2009-06-14)
X-Mailman-Approved-At: Fri, 02 Dec 2011 15:13:26 +0000
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linaro-dev@lists.linaro.org" <linaro-dev@lists.linaro.org>,
	Ian Campbell <Ian.Campbell@citrix.com>, Pawel Moll <Pawel.Moll@arm.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"virtualization@lists.linux-foundation.org"
	<virtualization@lists.linux-foundation.org>,
	"android-virt@lists.cs.columbia.edu" <android-virt@lists.cs.columbia.edu>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	"embeddedxen-devel@lists.sourceforge.net"
	<embeddedxen-devel@lists.sourceforge.net>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [Android-virt] [Embeddedxen-devel] [ANNOUNCE] Xen
 port to Cortex-A15 / ARMv7 with virt extensions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Dec 01, 2011 at 03:42:19PM +0000, Arnd Bergmann wrote:
> On Thursday 01 December 2011, Catalin Marinas wrote:
> > Given the way register banking is done on AArch64, issuing an HVC on a
> > 32-bit guest OS doesn't require translation on a 64-bit hypervisor. We
> > have a similar implementation at the SVC level (for 32-bit user apps on
> > a 64-bit kernel), the only modification was where a 32-bit SVC takes a
> > 64-bit parameter in two separate 32-bit registers, so packing needs to
> > be done in a syscall wrapper.
> 
> How do you deal with signed integer arguments passed into SVC or HVC from
> a caller? If I understand the architecture correctly, the upper
> halves of the argument register end up zero-padded, while the callee
> expects sign-extension.

If you treat it as an "int" (32-bit) and function prototype defined
accordingly, then the generated code only accesses it as a W (rather
than X) register and the top 32-bit part is ignored (no need for
sign-extension). If it is defined as a "long" in the 32-bit world, then
it indeed needs explicit conversion given the different sizes for long
(for example sys_lseek, the second argument is a 'long' and we do
explicit sign extension in the wrapper).

-- 
Catalin

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

From xen-devel-bounces@lists.xensource.com Fri Dec 02 15:13:49 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 15: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.xensource.com>)
	id 1RWUnp-0000Lb-Sp; Fri, 02 Dec 2011 15:13:29 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <catalin.marinas@arm.com>) id 1RW8Ix-0005mb-Sk
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 15:12:08 +0000
X-Env-Sender: catalin.marinas@arm.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1322752287!3870552!1
X-Originating-IP: [217.140.96.50]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19091 invoked from network); 1 Dec 2011 15:11:27 -0000
Received: from cam-admin0.cambridge.arm.com (HELO
	cam-admin0.cambridge.arm.com) (217.140.96.50)
	by server-13.tower-174.messagelabs.com with SMTP;
	1 Dec 2011 15:11:27 -0000
Received: from arm.com (e102109-lin.cambridge.arm.com [10.1.69.68])
	by cam-admin0.cambridge.arm.com (8.12.6/8.12.6) with ESMTP id
	pB1FAkWJ002369; Thu, 1 Dec 2011 15:10:46 GMT
Date: Thu, 1 Dec 2011 15:10:43 +0000
From: Catalin Marinas <catalin.marinas@arm.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20111201151043.GG27394@arm.com>
References: <alpine.DEB.2.00.1111281009090.31179@kaball-desktop>
	<201111301432.54463.arnd@arndb.de>
	<1322670473.31810.129.camel@zakaz.uk.xensource.com>
	<201111301815.01297.arnd@arndb.de>
	<alpine.DEB.2.00.1111301820290.31179@kaball-desktop>
	<1322735197.31810.191.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1322735197.31810.191.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
X-Mailman-Approved-At: Fri, 02 Dec 2011 15:13:26 +0000
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linaro-dev@lists.linaro.org" <linaro-dev@lists.linaro.org>,
	Arnd Bergmann <arnd@arndb.de>, Pawel Moll <Pawel.Moll@arm.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"virtualization@lists.linux-foundation.org"
	<virtualization@lists.linux-foundation.org>,
	"android-virt@lists.cs.columbia.edu" <android-virt@lists.cs.columbia.edu>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	"embeddedxen-devel@lists.sourceforge.net"
	<embeddedxen-devel@lists.sourceforge.net>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [Android-virt] [Embeddedxen-devel] [ANNOUNCE] Xen
 port to Cortex-A15 / ARMv7 with virt extensions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Dec 01, 2011 at 10:26:37AM +0000, Ian Campbell wrote:
> On Wed, 2011-11-30 at 18:32 +0000, Stefano Stabellini wrote:
> > On Wed, 30 Nov 2011, Arnd Bergmann wrote:
> > > KVM and Xen at least both fall into the single-return-value category,
> > > so we should be able to agree on a calling conventions. KVM does not
> > > have an hcall API on ARM yet, and I see no reason not to use the
> > > same implementation that you have in the Xen guest.
> > > 
> > > Stefano, can you split out the generic parts of your asm/xen/hypercall.h
> > > file into a common asm/hypercall.h and submit it for review to the
> > > arm kernel list?
> > 
> > Sure, I can do that.
> > Usually the hypercall calling convention is very hypervisor specific,
> > but if it turns out that we have the same requirements I happy to design
> > a common interface.
> 
> I expect the only real decision to be made is hypercall page vs. raw hvc
> instruction.
> 
> The page was useful on x86 where there is a variety of instructions
> which could be used (at least for PV there was systenter/syscall/int, I
> think vmcall instruction differs between AMD and Intel also) and gives
> some additional flexibility. It's hard to predict but I don't think I'd
> expect that to be necessary on ARM.
> 
> Another reason for having a hypercall page instead of a raw instruction
> might be wanting to support 32 bit guests (from ~today) on a 64 bit
> hypervisor in the future and perhaps needing to do some shimming/arg
> translation. It would be better to aim for having the interface just be
> 32/64 agnostic but mistakes do happen.

Given the way register banking is done on AArch64, issuing an HVC on a
32-bit guest OS doesn't require translation on a 64-bit hypervisor. We
have a similar implementation at the SVC level (for 32-bit user apps on
a 64-bit kernel), the only modification was where a 32-bit SVC takes a
64-bit parameter in two separate 32-bit registers, so packing needs to
be done in a syscall wrapper.

I'm not closely involved with any of the Xen or KVM work but I would
vote for using HVC than a hypercall page.

-- 
Catalin

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

From xen-devel-bounces@lists.xensource.com Fri Dec 02 15:13:49 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 15: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.xensource.com>)
	id 1RWUnp-0000Lb-Sp; Fri, 02 Dec 2011 15:13:29 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <catalin.marinas@arm.com>) id 1RW8Ix-0005mb-Sk
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 15:12:08 +0000
X-Env-Sender: catalin.marinas@arm.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1322752287!3870552!1
X-Originating-IP: [217.140.96.50]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19091 invoked from network); 1 Dec 2011 15:11:27 -0000
Received: from cam-admin0.cambridge.arm.com (HELO
	cam-admin0.cambridge.arm.com) (217.140.96.50)
	by server-13.tower-174.messagelabs.com with SMTP;
	1 Dec 2011 15:11:27 -0000
Received: from arm.com (e102109-lin.cambridge.arm.com [10.1.69.68])
	by cam-admin0.cambridge.arm.com (8.12.6/8.12.6) with ESMTP id
	pB1FAkWJ002369; Thu, 1 Dec 2011 15:10:46 GMT
Date: Thu, 1 Dec 2011 15:10:43 +0000
From: Catalin Marinas <catalin.marinas@arm.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20111201151043.GG27394@arm.com>
References: <alpine.DEB.2.00.1111281009090.31179@kaball-desktop>
	<201111301432.54463.arnd@arndb.de>
	<1322670473.31810.129.camel@zakaz.uk.xensource.com>
	<201111301815.01297.arnd@arndb.de>
	<alpine.DEB.2.00.1111301820290.31179@kaball-desktop>
	<1322735197.31810.191.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1322735197.31810.191.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
X-Mailman-Approved-At: Fri, 02 Dec 2011 15:13:26 +0000
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linaro-dev@lists.linaro.org" <linaro-dev@lists.linaro.org>,
	Arnd Bergmann <arnd@arndb.de>, Pawel Moll <Pawel.Moll@arm.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"virtualization@lists.linux-foundation.org"
	<virtualization@lists.linux-foundation.org>,
	"android-virt@lists.cs.columbia.edu" <android-virt@lists.cs.columbia.edu>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	"embeddedxen-devel@lists.sourceforge.net"
	<embeddedxen-devel@lists.sourceforge.net>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [Android-virt] [Embeddedxen-devel] [ANNOUNCE] Xen
 port to Cortex-A15 / ARMv7 with virt extensions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Dec 01, 2011 at 10:26:37AM +0000, Ian Campbell wrote:
> On Wed, 2011-11-30 at 18:32 +0000, Stefano Stabellini wrote:
> > On Wed, 30 Nov 2011, Arnd Bergmann wrote:
> > > KVM and Xen at least both fall into the single-return-value category,
> > > so we should be able to agree on a calling conventions. KVM does not
> > > have an hcall API on ARM yet, and I see no reason not to use the
> > > same implementation that you have in the Xen guest.
> > > 
> > > Stefano, can you split out the generic parts of your asm/xen/hypercall.h
> > > file into a common asm/hypercall.h and submit it for review to the
> > > arm kernel list?
> > 
> > Sure, I can do that.
> > Usually the hypercall calling convention is very hypervisor specific,
> > but if it turns out that we have the same requirements I happy to design
> > a common interface.
> 
> I expect the only real decision to be made is hypercall page vs. raw hvc
> instruction.
> 
> The page was useful on x86 where there is a variety of instructions
> which could be used (at least for PV there was systenter/syscall/int, I
> think vmcall instruction differs between AMD and Intel also) and gives
> some additional flexibility. It's hard to predict but I don't think I'd
> expect that to be necessary on ARM.
> 
> Another reason for having a hypercall page instead of a raw instruction
> might be wanting to support 32 bit guests (from ~today) on a 64 bit
> hypervisor in the future and perhaps needing to do some shimming/arg
> translation. It would be better to aim for having the interface just be
> 32/64 agnostic but mistakes do happen.

Given the way register banking is done on AArch64, issuing an HVC on a
32-bit guest OS doesn't require translation on a 64-bit hypervisor. We
have a similar implementation at the SVC level (for 32-bit user apps on
a 64-bit kernel), the only modification was where a 32-bit SVC takes a
64-bit parameter in two separate 32-bit registers, so packing needs to
be done in a syscall wrapper.

I'm not closely involved with any of the Xen or KVM work but I would
vote for using HVC than a hypercall page.

-- 
Catalin

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

From xen-devel-bounces@lists.xensource.com Fri Dec 02 15:13:50 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 15: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.xensource.com>)
	id 1RWUnr-0000Mk-VM; Fri, 02 Dec 2011 15:13:31 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <admin@dotcompower.com>) id 1RWTFM-0007Ba-KL
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 13:33:48 +0000
X-Env-Sender: admin@dotcompower.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1322832765!50652777!1
X-Originating-IP: [209.85.212.43]
X-SpamReason: No, hits=2.3 required=7.0 tests=BODY_RANDOMQ,RCVD_BY_IP,
	SUBJ_ALL_CAPS
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9948 invoked from network); 2 Dec 2011 13:32:46 -0000
Received: from mail-vw0-f43.google.com (HELO mail-vw0-f43.google.com)
	(209.85.212.43)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Dec 2011 13:32:46 -0000
Received: by vbbfq11 with SMTP id fq11so13117745vbb.30
	for <xen-devel@lists.xensource.com>;
	Fri, 02 Dec 2011 05:33:06 -0800 (PST)
Received: by 10.52.36.161 with SMTP id r1mr9084290vdj.118.1322832786398;
	Fri, 02 Dec 2011 05:33:06 -0800 (PST)
Received: from COMMATRIX
	(sydnns0109w-142068200036.dhcp-dynamic.FibreOp.ns.bellaliant.net.
	[142.68.200.36])
	by mx.google.com with ESMTPS id df14sm9889033vdb.0.2011.12.02.05.33.04
	(version=SSLv3 cipher=OTHER); Fri, 02 Dec 2011 05:33:05 -0800 (PST)
From: "Admin@DotComPower.com" <admin@dotcompower.com>
To: <xen-devel@lists.xensource.com>
Date: Fri, 2 Dec 2011 09:33:06 -0400
Message-ID: <3A26C6941B57415BAC7352BF4EF8EE80@COMMATRIX>
MIME-Version: 1.0
X-Mailer: Microsoft Office Outlook 11
Thread-Index: Acyw9uw/G10ckpwYSD6tm3jV94/jCw==
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157
X-Mailman-Approved-At: Fri, 02 Dec 2011 15:13:26 +0000
Subject: [Xen-devel] XCP - SCST - SRPT
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hello,

Using XCP and Kronos with SAN connected via IB_SRP and using SCST SRPT. 

The initiator for SRP is different from iSCSI as it does not use a
traditional IQN for the target. 

Is there a workaround or way to use XCP with this setup to add storage
devices via IB_SRP as SRs?

Thus far I have only been able to get an SR setup when the device is
connected via IB_SRP as a local scsi device via SRP initiator. With this
setup it treats the target drive like another local drive though. I lose the
ability to live migrate, which is the whole point of having a SAN storage
device. Or is there a workaround for this?

Thanks,

Jonathan


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

From xen-devel-bounces@lists.xensource.com Fri Dec 02 15:13:50 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 15: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.xensource.com>)
	id 1RWUnr-0000Mk-VM; Fri, 02 Dec 2011 15:13:31 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <admin@dotcompower.com>) id 1RWTFM-0007Ba-KL
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 13:33:48 +0000
X-Env-Sender: admin@dotcompower.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1322832765!50652777!1
X-Originating-IP: [209.85.212.43]
X-SpamReason: No, hits=2.3 required=7.0 tests=BODY_RANDOMQ,RCVD_BY_IP,
	SUBJ_ALL_CAPS
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9948 invoked from network); 2 Dec 2011 13:32:46 -0000
Received: from mail-vw0-f43.google.com (HELO mail-vw0-f43.google.com)
	(209.85.212.43)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Dec 2011 13:32:46 -0000
Received: by vbbfq11 with SMTP id fq11so13117745vbb.30
	for <xen-devel@lists.xensource.com>;
	Fri, 02 Dec 2011 05:33:06 -0800 (PST)
Received: by 10.52.36.161 with SMTP id r1mr9084290vdj.118.1322832786398;
	Fri, 02 Dec 2011 05:33:06 -0800 (PST)
Received: from COMMATRIX
	(sydnns0109w-142068200036.dhcp-dynamic.FibreOp.ns.bellaliant.net.
	[142.68.200.36])
	by mx.google.com with ESMTPS id df14sm9889033vdb.0.2011.12.02.05.33.04
	(version=SSLv3 cipher=OTHER); Fri, 02 Dec 2011 05:33:05 -0800 (PST)
From: "Admin@DotComPower.com" <admin@dotcompower.com>
To: <xen-devel@lists.xensource.com>
Date: Fri, 2 Dec 2011 09:33:06 -0400
Message-ID: <3A26C6941B57415BAC7352BF4EF8EE80@COMMATRIX>
MIME-Version: 1.0
X-Mailer: Microsoft Office Outlook 11
Thread-Index: Acyw9uw/G10ckpwYSD6tm3jV94/jCw==
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157
X-Mailman-Approved-At: Fri, 02 Dec 2011 15:13:26 +0000
Subject: [Xen-devel] XCP - SCST - SRPT
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hello,

Using XCP and Kronos with SAN connected via IB_SRP and using SCST SRPT. 

The initiator for SRP is different from iSCSI as it does not use a
traditional IQN for the target. 

Is there a workaround or way to use XCP with this setup to add storage
devices via IB_SRP as SRs?

Thus far I have only been able to get an SR setup when the device is
connected via IB_SRP as a local scsi device via SRP initiator. With this
setup it treats the target drive like another local drive though. I lose the
ability to live migrate, which is the whole point of having a SAN storage
device. Or is there a workaround for this?

Thanks,

Jonathan


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

From xen-devel-bounces@lists.xensource.com Fri Dec 02 15:13:50 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 15: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.xensource.com>)
	id 1RWUnq-0000M1-N8; Fri, 02 Dec 2011 15:13:30 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <catalin.marinas@arm.com>) id 1RW9xn-0006Mb-Me
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 16:58:23 +0000
X-Env-Sender: catalin.marinas@arm.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1322758663!5504603!1
X-Originating-IP: [217.140.96.50]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30805 invoked from network); 1 Dec 2011 16:57:43 -0000
Received: from cam-admin0.cambridge.arm.com (HELO
	cam-admin0.cambridge.arm.com) (217.140.96.50)
	by server-6.tower-182.messagelabs.com with SMTP;
	1 Dec 2011 16:57:43 -0000
Received: from arm.com (e102109-lin.cambridge.arm.com [10.1.69.68])
	by cam-admin0.cambridge.arm.com (8.12.6/8.12.6) with ESMTP id
	pB1GvIWJ019872; Thu, 1 Dec 2011 16:57:18 GMT
Date: Thu, 1 Dec 2011 16:57:18 +0000
From: Catalin Marinas <catalin.marinas@arm.com>
To: Arnd Bergmann <arnd@arndb.de>
Message-ID: <20111201165718.GJ27394@arm.com>
References: <alpine.DEB.2.00.1111281009090.31179@kaball-desktop>
	<201112011542.19377.arnd@arndb.de> <20111201160241.GH27394@arm.com>
	<201112011644.41101.arnd@arndb.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <201112011644.41101.arnd@arndb.de>
User-Agent: Mutt/1.5.20 (2009-06-14)
X-Mailman-Approved-At: Fri, 02 Dec 2011 15:13:26 +0000
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linaro-dev@lists.linaro.org" <linaro-dev@lists.linaro.org>,
	Ian Campbell <Ian.Campbell@citrix.com>, Pawel Moll <Pawel.Moll@arm.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"virtualization@lists.linux-foundation.org"
	<virtualization@lists.linux-foundation.org>,
	"android-virt@lists.cs.columbia.edu" <android-virt@lists.cs.columbia.edu>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	"embeddedxen-devel@lists.sourceforge.net"
	<embeddedxen-devel@lists.sourceforge.net>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [Android-virt] [Embeddedxen-devel] [ANNOUNCE] Xen
 port to Cortex-A15 / ARMv7 with virt extensions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Dec 01, 2011 at 04:44:40PM +0000, Arnd Bergmann wrote:
> On Thursday 01 December 2011, Catalin Marinas wrote:
> > On Thu, Dec 01, 2011 at 03:42:19PM +0000, Arnd Bergmann wrote:
> > > On Thursday 01 December 2011, Catalin Marinas wrote:
> > > How do you deal with signed integer arguments passed into SVC or HVC from
> > > a caller? If I understand the architecture correctly, the upper
> > > halves of the argument register end up zero-padded, while the callee
> > > expects sign-extension.
> > 
> > If you treat it as an "int" (32-bit) and function prototype defined
> > accordingly, then the generated code only accesses it as a W (rather
> > than X) register and the top 32-bit part is ignored (no need for
> > sign-extension). If it is defined as a "long" in the 32-bit world, then
> > it indeed needs explicit conversion given the different sizes for long
> > (for example sys_lseek, the second argument is a 'long' and we do
> > explicit sign extension in the wrapper).
...
> What about unsigned long and pointer? Can we always rely on the upper
> half of the register to be zero-filled when we get an exception from 32
> bit into 64 bit state, or do we also have to zero-extend those?

They are also fine, no need for zero-extension.

-- 
Catalin

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

From xen-devel-bounces@lists.xensource.com Fri Dec 02 15:13:50 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 15: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.xensource.com>)
	id 1RWUnq-0000M1-N8; Fri, 02 Dec 2011 15:13:30 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <catalin.marinas@arm.com>) id 1RW9xn-0006Mb-Me
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 16:58:23 +0000
X-Env-Sender: catalin.marinas@arm.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1322758663!5504603!1
X-Originating-IP: [217.140.96.50]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30805 invoked from network); 1 Dec 2011 16:57:43 -0000
Received: from cam-admin0.cambridge.arm.com (HELO
	cam-admin0.cambridge.arm.com) (217.140.96.50)
	by server-6.tower-182.messagelabs.com with SMTP;
	1 Dec 2011 16:57:43 -0000
Received: from arm.com (e102109-lin.cambridge.arm.com [10.1.69.68])
	by cam-admin0.cambridge.arm.com (8.12.6/8.12.6) with ESMTP id
	pB1GvIWJ019872; Thu, 1 Dec 2011 16:57:18 GMT
Date: Thu, 1 Dec 2011 16:57:18 +0000
From: Catalin Marinas <catalin.marinas@arm.com>
To: Arnd Bergmann <arnd@arndb.de>
Message-ID: <20111201165718.GJ27394@arm.com>
References: <alpine.DEB.2.00.1111281009090.31179@kaball-desktop>
	<201112011542.19377.arnd@arndb.de> <20111201160241.GH27394@arm.com>
	<201112011644.41101.arnd@arndb.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <201112011644.41101.arnd@arndb.de>
User-Agent: Mutt/1.5.20 (2009-06-14)
X-Mailman-Approved-At: Fri, 02 Dec 2011 15:13:26 +0000
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linaro-dev@lists.linaro.org" <linaro-dev@lists.linaro.org>,
	Ian Campbell <Ian.Campbell@citrix.com>, Pawel Moll <Pawel.Moll@arm.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"virtualization@lists.linux-foundation.org"
	<virtualization@lists.linux-foundation.org>,
	"android-virt@lists.cs.columbia.edu" <android-virt@lists.cs.columbia.edu>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	"embeddedxen-devel@lists.sourceforge.net"
	<embeddedxen-devel@lists.sourceforge.net>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [Android-virt] [Embeddedxen-devel] [ANNOUNCE] Xen
 port to Cortex-A15 / ARMv7 with virt extensions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Dec 01, 2011 at 04:44:40PM +0000, Arnd Bergmann wrote:
> On Thursday 01 December 2011, Catalin Marinas wrote:
> > On Thu, Dec 01, 2011 at 03:42:19PM +0000, Arnd Bergmann wrote:
> > > On Thursday 01 December 2011, Catalin Marinas wrote:
> > > How do you deal with signed integer arguments passed into SVC or HVC from
> > > a caller? If I understand the architecture correctly, the upper
> > > halves of the argument register end up zero-padded, while the callee
> > > expects sign-extension.
> > 
> > If you treat it as an "int" (32-bit) and function prototype defined
> > accordingly, then the generated code only accesses it as a W (rather
> > than X) register and the top 32-bit part is ignored (no need for
> > sign-extension). If it is defined as a "long" in the 32-bit world, then
> > it indeed needs explicit conversion given the different sizes for long
> > (for example sys_lseek, the second argument is a 'long' and we do
> > explicit sign extension in the wrapper).
...
> What about unsigned long and pointer? Can we always rely on the upper
> half of the register to be zero-filled when we get an exception from 32
> bit into 64 bit state, or do we also have to zero-extend those?

They are also fine, no need for zero-extension.

-- 
Catalin

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

From xen-devel-bounces@lists.xensource.com Fri Dec 02 15:13:51 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 15:13:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWUno-0000Ky-9s; Fri, 02 Dec 2011 15:13:28 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72) (envelope-from <bp@amd64.org>)
	id 1RW42V-0006vt-N1
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 10:38:51 +0000
X-Env-Sender: bp@amd64.org
X-Msg-Ref: server-15.tower-27.messagelabs.com!1322735876!57263166!1
X-Originating-IP: [87.106.30.177]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20903 invoked from network); 1 Dec 2011 10:37:56 -0000
Received: from s15228384.onlinehome-server.info (HELO mail.x86-64.org)
	(87.106.30.177) by server-15.tower-27.messagelabs.com with SMTP;
	1 Dec 2011 10:37:56 -0000
Received: from localhost (localhost [127.0.0.1])
	by mail.x86-64.org (Postfix) with ESMTP id 5E9C913D02;
	Thu,  1 Dec 2011 11:38:11 +0100 (CET)
X-Virus-Scanned: Nedap ESD1 at mail.x86-64.org
Received: from mail.x86-64.org ([127.0.0.1])
	by localhost (s15228384.onlinehome-server.info [127.0.0.1])
	(amavisd-new, port 10024)
	with ESMTP id 3P48dIGwSsrr; Thu,  1 Dec 2011 11:38:10 +0100 (CET)
Received: from gwo.osrc.amd.com (gwo.osrc.amd.com [10.97.0.252])
	by mail.x86-64.org (Postfix) with ESMTP;
	Thu,  1 Dec 2011 11:38:10 +0100 (CET)
Received: from aftab (aftab.osrc.amd.com [165.204.15.109])
	by gwo.osrc.amd.com (Postfix) with ESMTP id 0AA3549C34C;
	Thu,  1 Dec 2011 10:38:10 +0000 (GMT)
Date: Thu, 1 Dec 2011 11:38:08 +0100
From: Borislav Petkov <bp@amd64.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20111201103808.GB31552@aftab>
References: <4ED6676F02000078000646BC@nat28.tlf.novell.com>
	<20111130222359.GC16651@andromeda.dapyr.net>
	<4ED7433A0200007800064903@nat28.tlf.novell.com>
	<1322733358.31810.174.camel@zakaz.uk.xensource.com>
	<4ED75EB202000078000649E9@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4ED75EB202000078000649E9@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Mailman-Approved-At: Fri, 02 Dec 2011 15:13:26 +0000
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, "hpa@zytor.com" <hpa@zytor.com>
Subject: Re: [Xen-devel] [PATCH 2/2] x86/microcode: enable boot time
 (pre-Dom0) loading
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Dec 01, 2011 at 10:02:10AM +0000, Jan Beulich wrote:
> >>> On 01.12.11 at 10:55, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > On Thu, 2011-12-01 at 08:04 +0000, Jan Beulich wrote:
> >> 
> >> > I got the impression they wanted some new .pack format or so?
> >> > Or is the format that they were talking about exactly what you
> >> picked?
> >> 
> >> I merely picked the binary formats that are already in use; I see no
> >> reason to invent another one. 
> > 
> > Adding a header/magic number so you can detect which of the blobs is
> > microcode?
> 
> This is precisely what I did *not* want to do.

Well, AFAICR, we talked about using the setup_data linked list in
the user-mode kernel header and since parse_setup_data() looks at
data->type, then probably something should state the type of the ucode
image, but I'm not sure on the details.

FWIW, hpa mentioned at KS he already has some code doing early ucode
loading so I'll let him chime in here. He's away this week though so it
could take a while.

-- 
Regards/Gruss,
Boris.

Advanced Micro Devices GmbH
Einsteinring 24, 85609 Dornach
GM: Alberto Bozzo
Reg: Dornach, Landkreis Muenchen
HRB Nr. 43632 WEEE Registernr: 129 19551

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

From xen-devel-bounces@lists.xensource.com Fri Dec 02 15:13:51 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 15:13:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWUno-0000Ky-9s; Fri, 02 Dec 2011 15:13:28 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72) (envelope-from <bp@amd64.org>)
	id 1RW42V-0006vt-N1
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 10:38:51 +0000
X-Env-Sender: bp@amd64.org
X-Msg-Ref: server-15.tower-27.messagelabs.com!1322735876!57263166!1
X-Originating-IP: [87.106.30.177]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20903 invoked from network); 1 Dec 2011 10:37:56 -0000
Received: from s15228384.onlinehome-server.info (HELO mail.x86-64.org)
	(87.106.30.177) by server-15.tower-27.messagelabs.com with SMTP;
	1 Dec 2011 10:37:56 -0000
Received: from localhost (localhost [127.0.0.1])
	by mail.x86-64.org (Postfix) with ESMTP id 5E9C913D02;
	Thu,  1 Dec 2011 11:38:11 +0100 (CET)
X-Virus-Scanned: Nedap ESD1 at mail.x86-64.org
Received: from mail.x86-64.org ([127.0.0.1])
	by localhost (s15228384.onlinehome-server.info [127.0.0.1])
	(amavisd-new, port 10024)
	with ESMTP id 3P48dIGwSsrr; Thu,  1 Dec 2011 11:38:10 +0100 (CET)
Received: from gwo.osrc.amd.com (gwo.osrc.amd.com [10.97.0.252])
	by mail.x86-64.org (Postfix) with ESMTP;
	Thu,  1 Dec 2011 11:38:10 +0100 (CET)
Received: from aftab (aftab.osrc.amd.com [165.204.15.109])
	by gwo.osrc.amd.com (Postfix) with ESMTP id 0AA3549C34C;
	Thu,  1 Dec 2011 10:38:10 +0000 (GMT)
Date: Thu, 1 Dec 2011 11:38:08 +0100
From: Borislav Petkov <bp@amd64.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20111201103808.GB31552@aftab>
References: <4ED6676F02000078000646BC@nat28.tlf.novell.com>
	<20111130222359.GC16651@andromeda.dapyr.net>
	<4ED7433A0200007800064903@nat28.tlf.novell.com>
	<1322733358.31810.174.camel@zakaz.uk.xensource.com>
	<4ED75EB202000078000649E9@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4ED75EB202000078000649E9@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Mailman-Approved-At: Fri, 02 Dec 2011 15:13:26 +0000
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, "hpa@zytor.com" <hpa@zytor.com>
Subject: Re: [Xen-devel] [PATCH 2/2] x86/microcode: enable boot time
 (pre-Dom0) loading
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Dec 01, 2011 at 10:02:10AM +0000, Jan Beulich wrote:
> >>> On 01.12.11 at 10:55, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > On Thu, 2011-12-01 at 08:04 +0000, Jan Beulich wrote:
> >> 
> >> > I got the impression they wanted some new .pack format or so?
> >> > Or is the format that they were talking about exactly what you
> >> picked?
> >> 
> >> I merely picked the binary formats that are already in use; I see no
> >> reason to invent another one. 
> > 
> > Adding a header/magic number so you can detect which of the blobs is
> > microcode?
> 
> This is precisely what I did *not* want to do.

Well, AFAICR, we talked about using the setup_data linked list in
the user-mode kernel header and since parse_setup_data() looks at
data->type, then probably something should state the type of the ucode
image, but I'm not sure on the details.

FWIW, hpa mentioned at KS he already has some code doing early ucode
loading so I'll let him chime in here. He's away this week though so it
could take a while.

-- 
Regards/Gruss,
Boris.

Advanced Micro Devices GmbH
Einsteinring 24, 85609 Dornach
GM: Alberto Bozzo
Reg: Dornach, Landkreis Muenchen
HRB Nr. 43632 WEEE Registernr: 129 19551

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

From xen-devel-bounces@lists.xensource.com Fri Dec 02 15:13:51 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 15:13:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWUnp-0000LR-FK; Fri, 02 Dec 2011 15:13:29 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <techtonik@gmail.com>) id 1RW7tm-0004rV-GJ
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 14:46:06 +0000
X-Env-Sender: techtonik@gmail.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1322750699!50750796!1
X-Originating-IP: [209.85.161.171]
X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16488 invoked from network); 1 Dec 2011 14:45:00 -0000
Received: from mail-gx0-f171.google.com (HELO mail-gx0-f171.google.com)
	(209.85.161.171)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 14:45:00 -0000
Received: by ggnr4 with SMTP id r4so13687734ggn.30
	for <xen-devel@lists.xensource.com>;
	Thu, 01 Dec 2011 06:45:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type;
	bh=q2V37tS+15awok2/IZT7lk9UG+gFrXBNoMPaspQcoEo=;
	b=KTRt/ibT2hmAGkpM16PBZaCiusBnpR7pGd6wSDaRDfwc7bCdDCBNcA94HnstA3Zb/F
	Z8qEyCaSP5LaM970tpSKEO364WX+VdI5etx2XfCTW2h9A4VlM99VwuxbXaoqgJFhQA98
	Z3YqGnf78NU3oy0mAhPUzuAYrigBXpWnatQuM=
Received: by 10.236.115.40 with SMTP id d28mr11791861yhh.37.1322750729310;
	Thu, 01 Dec 2011 06:45:29 -0800 (PST)
MIME-Version: 1.0
Received: by 10.100.42.12 with HTTP; Thu, 1 Dec 2011 06:45:08 -0800 (PST)
In-Reply-To: <1322747959.31810.207.camel@zakaz.uk.xensource.com>
References: <CAPkN8xKwAsrF_ZuXWAF2uMVDYTbGwpSsvG+YfjrLfpf-oxqwJQ@mail.gmail.com>
	<CAPkN8xLX83Uxbo4UDWG2mmYctAQbwRcw3BJWzack8JZgQAg9nw@mail.gmail.com>
	<1322747959.31810.207.camel@zakaz.uk.xensource.com>
From: anatoly techtonik <techtonik@gmail.com>
Date: Thu, 1 Dec 2011 17:45:08 +0300
Message-ID: <CAPkN8xJiCTijVoi6YcHBa0tHYc8oQCmRw=ybRuhvWmWi2OLLmw@mail.gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
X-Mailman-Approved-At: Fri, 02 Dec 2011 15:13:26 +0000
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Low memory corruption - trap invalid opcode
 ip:7f5c688028b0 sp:7ffff97af848 error:0 in ld-2.11.2.so[7f5c687ef000+1e000]
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============4877010217104936610=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============4877010217104936610==
Content-Type: multipart/alternative; boundary=20cf303ea79c58d14604b308e7c7

--20cf303ea79c58d14604b308e7c7
Content-Type: text/plain; charset=UTF-8

On Thu, Dec 1, 2011 at 4:59 PM, Ian Campbell <Ian.Campbell@citrix.com>wrote:

> On Tue, 2011-11-29 at 17:54 +0000, anatoly techtonik wrote:
> > My first message didn't get to the list, so I am trying once more.
> >
> > ---------- Forwarded message ----------
> > From: anatoly techtonik <techtonik@gmail.com>
> > Date: Mon, Nov 14, 2011 at 5:46 PM
> > Subject: Low memory corruption - trap invalid opcode ip:7f5c688028b0
> > sp:7ffff97af848 error:0 in ld-2.11.2.so[7f5c687ef000+1e000]
> > To: xen-devel@lists.xensource.com
> >
> >
> > I was redirected here from this bug report in Debian against
> > 'svn-buildpackage' after I started getting 'Illegal instruction' error
> > after running 'svn-inject' and similar command on a brand new VM
> > instance for Debian Squeeze.
> > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=646945#54
> >
> > dmesg from VM
> > 17067.210187] svn-inject[6026] trap invalid opcode ip:7f5c688028b0
> > sp:7ffff97af848 error:0 in ld-2.11.2.so[7f5c687ef000+1e000]
>
> This is more than likely the same issue as
> http://bugs.debian.org/646549.


Thanks. The processor is the same Intel Xeon E31270, so I am going to
subscribe to this bug. In the meanwhile - is it possible to disable this
AVX somehow or find another workaround until it is fixed in Squeeze?
-- 
anatoly t.

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

<div class=3D"gmail_quote">On Thu, Dec 1, 2011 at 4:59 PM, Ian Campbell <sp=
an dir=3D"ltr">&lt;<a href=3D"mailto:Ian.Campbell@citrix.com" target=3D"_bl=
ank">Ian.Campbell@citrix.com</a>&gt;</span> wrote:<br><blockquote class=3D"=
gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-=
left:1ex">


<div>On Tue, 2011-11-29 at 17:54 +0000, anatoly techtonik wrote:<br>
&gt; My first message didn&#39;t get to the list, so I am trying once more.=
<br>
&gt;<br>
&gt; ---------- Forwarded message ----------<br>
&gt; From: anatoly techtonik &lt;<a href=3D"mailto:techtonik@gmail.com" tar=
get=3D"_blank">techtonik@gmail.com</a>&gt;<br>
&gt; Date: Mon, Nov 14, 2011 at 5:46 PM<br>
&gt; Subject: Low memory corruption - trap invalid opcode ip:7f5c688028b0<b=
r>
&gt; sp:7ffff97af848 error:0 in <a href=3D"http://ld-2.11.2.so" target=3D"_=
blank">ld-2.11.2.so</a>[7f5c687ef000+1e000]<br>
&gt; To: <a href=3D"mailto:xen-devel@lists.xensource.com" target=3D"_blank"=
>xen-devel@lists.xensource.com</a><br>
&gt;<br>
&gt;<br>
&gt; I was redirected here from this bug report in Debian against<br>
&gt; &#39;svn-buildpackage&#39; after I started getting &#39;Illegal instru=
ction&#39; error<br>
&gt; after running &#39;svn-inject&#39; and similar command on a brand new =
VM<br>
&gt; instance for Debian Squeeze.<br>
&gt; <a href=3D"http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=3D646945#5=
4" target=3D"_blank">http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=3D646=
945#54</a><br>
&gt;<br>
&gt; dmesg from VM<br>
&gt; <a href=3D"tel:17067.210187" value=3D"+17067210187" target=3D"_blank">=
17067.210187</a>] svn-inject[6026] trap invalid opcode ip:7f5c688028b0<br>
&gt; sp:7ffff97af848 error:0 in <a href=3D"http://ld-2.11.2.so" target=3D"_=
blank">ld-2.11.2.so</a>[7f5c687ef000+1e000]<br>
<br>
</div>This is more than likely the same issue as<br>
<a href=3D"http://bugs.debian.org/646549" target=3D"_blank">http://bugs.deb=
ian.org/646549</a>.</blockquote><div><br></div><div>Thanks. The processor i=
s the same Intel Xeon E31270, so I am going to subscribe to this bug. In th=
e meanwhile - is it possible to disable this AVX somehow or find another wo=
rkaround until it is fixed in Squeeze?=C2=A0<br clear=3D"all">

--=C2=A0<br>anatoly t.<br></div></div>

--20cf303ea79c58d14604b308e7c7--


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

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

--===============4877010217104936610==--


From xen-devel-bounces@lists.xensource.com Fri Dec 02 15:13:51 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 15:13:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWUnp-0000LR-FK; Fri, 02 Dec 2011 15:13:29 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <techtonik@gmail.com>) id 1RW7tm-0004rV-GJ
	for xen-devel@lists.xensource.com; Thu, 01 Dec 2011 14:46:06 +0000
X-Env-Sender: techtonik@gmail.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1322750699!50750796!1
X-Originating-IP: [209.85.161.171]
X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16488 invoked from network); 1 Dec 2011 14:45:00 -0000
Received: from mail-gx0-f171.google.com (HELO mail-gx0-f171.google.com)
	(209.85.161.171)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2011 14:45:00 -0000
Received: by ggnr4 with SMTP id r4so13687734ggn.30
	for <xen-devel@lists.xensource.com>;
	Thu, 01 Dec 2011 06:45:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type;
	bh=q2V37tS+15awok2/IZT7lk9UG+gFrXBNoMPaspQcoEo=;
	b=KTRt/ibT2hmAGkpM16PBZaCiusBnpR7pGd6wSDaRDfwc7bCdDCBNcA94HnstA3Zb/F
	Z8qEyCaSP5LaM970tpSKEO364WX+VdI5etx2XfCTW2h9A4VlM99VwuxbXaoqgJFhQA98
	Z3YqGnf78NU3oy0mAhPUzuAYrigBXpWnatQuM=
Received: by 10.236.115.40 with SMTP id d28mr11791861yhh.37.1322750729310;
	Thu, 01 Dec 2011 06:45:29 -0800 (PST)
MIME-Version: 1.0
Received: by 10.100.42.12 with HTTP; Thu, 1 Dec 2011 06:45:08 -0800 (PST)
In-Reply-To: <1322747959.31810.207.camel@zakaz.uk.xensource.com>
References: <CAPkN8xKwAsrF_ZuXWAF2uMVDYTbGwpSsvG+YfjrLfpf-oxqwJQ@mail.gmail.com>
	<CAPkN8xLX83Uxbo4UDWG2mmYctAQbwRcw3BJWzack8JZgQAg9nw@mail.gmail.com>
	<1322747959.31810.207.camel@zakaz.uk.xensource.com>
From: anatoly techtonik <techtonik@gmail.com>
Date: Thu, 1 Dec 2011 17:45:08 +0300
Message-ID: <CAPkN8xJiCTijVoi6YcHBa0tHYc8oQCmRw=ybRuhvWmWi2OLLmw@mail.gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
X-Mailman-Approved-At: Fri, 02 Dec 2011 15:13:26 +0000
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Low memory corruption - trap invalid opcode
 ip:7f5c688028b0 sp:7ffff97af848 error:0 in ld-2.11.2.so[7f5c687ef000+1e000]
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============4877010217104936610=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============4877010217104936610==
Content-Type: multipart/alternative; boundary=20cf303ea79c58d14604b308e7c7

--20cf303ea79c58d14604b308e7c7
Content-Type: text/plain; charset=UTF-8

On Thu, Dec 1, 2011 at 4:59 PM, Ian Campbell <Ian.Campbell@citrix.com>wrote:

> On Tue, 2011-11-29 at 17:54 +0000, anatoly techtonik wrote:
> > My first message didn't get to the list, so I am trying once more.
> >
> > ---------- Forwarded message ----------
> > From: anatoly techtonik <techtonik@gmail.com>
> > Date: Mon, Nov 14, 2011 at 5:46 PM
> > Subject: Low memory corruption - trap invalid opcode ip:7f5c688028b0
> > sp:7ffff97af848 error:0 in ld-2.11.2.so[7f5c687ef000+1e000]
> > To: xen-devel@lists.xensource.com
> >
> >
> > I was redirected here from this bug report in Debian against
> > 'svn-buildpackage' after I started getting 'Illegal instruction' error
> > after running 'svn-inject' and similar command on a brand new VM
> > instance for Debian Squeeze.
> > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=646945#54
> >
> > dmesg from VM
> > 17067.210187] svn-inject[6026] trap invalid opcode ip:7f5c688028b0
> > sp:7ffff97af848 error:0 in ld-2.11.2.so[7f5c687ef000+1e000]
>
> This is more than likely the same issue as
> http://bugs.debian.org/646549.


Thanks. The processor is the same Intel Xeon E31270, so I am going to
subscribe to this bug. In the meanwhile - is it possible to disable this
AVX somehow or find another workaround until it is fixed in Squeeze?
-- 
anatoly t.

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

<div class=3D"gmail_quote">On Thu, Dec 1, 2011 at 4:59 PM, Ian Campbell <sp=
an dir=3D"ltr">&lt;<a href=3D"mailto:Ian.Campbell@citrix.com" target=3D"_bl=
ank">Ian.Campbell@citrix.com</a>&gt;</span> wrote:<br><blockquote class=3D"=
gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-=
left:1ex">


<div>On Tue, 2011-11-29 at 17:54 +0000, anatoly techtonik wrote:<br>
&gt; My first message didn&#39;t get to the list, so I am trying once more.=
<br>
&gt;<br>
&gt; ---------- Forwarded message ----------<br>
&gt; From: anatoly techtonik &lt;<a href=3D"mailto:techtonik@gmail.com" tar=
get=3D"_blank">techtonik@gmail.com</a>&gt;<br>
&gt; Date: Mon, Nov 14, 2011 at 5:46 PM<br>
&gt; Subject: Low memory corruption - trap invalid opcode ip:7f5c688028b0<b=
r>
&gt; sp:7ffff97af848 error:0 in <a href=3D"http://ld-2.11.2.so" target=3D"_=
blank">ld-2.11.2.so</a>[7f5c687ef000+1e000]<br>
&gt; To: <a href=3D"mailto:xen-devel@lists.xensource.com" target=3D"_blank"=
>xen-devel@lists.xensource.com</a><br>
&gt;<br>
&gt;<br>
&gt; I was redirected here from this bug report in Debian against<br>
&gt; &#39;svn-buildpackage&#39; after I started getting &#39;Illegal instru=
ction&#39; error<br>
&gt; after running &#39;svn-inject&#39; and similar command on a brand new =
VM<br>
&gt; instance for Debian Squeeze.<br>
&gt; <a href=3D"http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=3D646945#5=
4" target=3D"_blank">http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=3D646=
945#54</a><br>
&gt;<br>
&gt; dmesg from VM<br>
&gt; <a href=3D"tel:17067.210187" value=3D"+17067210187" target=3D"_blank">=
17067.210187</a>] svn-inject[6026] trap invalid opcode ip:7f5c688028b0<br>
&gt; sp:7ffff97af848 error:0 in <a href=3D"http://ld-2.11.2.so" target=3D"_=
blank">ld-2.11.2.so</a>[7f5c687ef000+1e000]<br>
<br>
</div>This is more than likely the same issue as<br>
<a href=3D"http://bugs.debian.org/646549" target=3D"_blank">http://bugs.deb=
ian.org/646549</a>.</blockquote><div><br></div><div>Thanks. The processor i=
s the same Intel Xeon E31270, so I am going to subscribe to this bug. In th=
e meanwhile - is it possible to disable this AVX somehow or find another wo=
rkaround until it is fixed in Squeeze?=C2=A0<br clear=3D"all">

--=C2=A0<br>anatoly t.<br></div></div>

--20cf303ea79c58d14604b308e7c7--


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

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

--===============4877010217104936610==--


From xen-devel-bounces@lists.xensource.com Fri Dec 02 15:21:09 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 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.xensource.com>)
	id 1RWUuj-0002Ly-33; Fri, 02 Dec 2011 15:20:37 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1RWUuh-0002Lj-CV
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 15:20:35 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1322839192!7281532!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjg1NDY=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26471 invoked from network); 2 Dec 2011 15:19:53 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Dec 2011 15:19:53 -0000
X-IronPort-AV: E=Sophos;i="4.71,284,1320642000"; d="scan'208";a="172689898"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Dec 2011 10:19:29 -0500
Received: from [10.80.2.18] (10.80.2.18) by FTLPMAILMX02.citrite.net
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Fri, 2 Dec 2011
	10:19:29 -0500
Message-ID: <4ED8EC80.9040701@citrix.com>
Date: Fri, 2 Dec 2011 15:19:28 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.23) Gecko/20110921 Lightning/1.0b2 Thunderbird/3.1.15
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <CAFA7027.25E35%keir.xen@gmail.com>
	<4ED62C50.7060204@citrix.com>	<4ED666D5.5060603@citrix.com>	<4ED7522E0200007800064973@nat28.tlf.novell.com>	<4ED74DAD.1040903@citrix.com>	<4ED75E8402000078000649E6@nat28.tlf.novell.com>	<4ED77347.6060200@citrix.com>	<4ED787870200007800064B6F@nat28.tlf.novell.com>	<4ED79722.7090404@citrix.com>	<4ED7A8110200007800064C50@nat28.tlf.novell.com>	<4ED7B5FF.2090305@citrix.com>	<4ED894100200007800064FE3@nat28.tlf.novell.com>
	<4ED8C592.3010603@citrix.com>
In-Reply-To: <4ED8C592.3010603@citrix.com>
X-Enigmail-Version: 1.1.2
Content-Type: multipart/mixed; boundary="------------060905080009020205040404"
Cc: Keir Fraser <keir.xen@gmail.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: [Xen-devel] KEXEC: allocate crash note buffers at boot time v5
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--------------060905080009020205040404
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit

Here is v5.

I have tested quite carefully the impact of changing the error
conditions in kexec_get_cpu().  dom0 is happy to accept ERANGE as well
as EINVAL, and ERANGE is a more sensible response.  Moreover, this new
scheme (ignoring for a moment ENOMEM) allows for all nr_cpu_ids to give
note ranges to dom0 whether they are up or not at the moment.   It is
better to have more notes provided with some of them potentially not
filled in, than to miss a crashed CPU register state because it was
offline when the crash kernel was loaded.

All this testing has been done via backport to 4.1.2.  Minimal changes
were necessary, such as the lack of xzalloc_array() and NR_CPUS instead
of nr_cpu_ids, but it was otherwise functionally identical.

I am not sure whether to recomend this for backport into 4.1-testing or
not.  It does make the crashkernel more likely to get crash notes,
although in reality, it was only special circumstances which caused
problems.  If you consider it worth backporting, I can provide my
already-backported patch.

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com


--------------060905080009020205040404
Content-Type: text/x-patch; name="KEXEC-setup-crash-notes-during-boot.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename="KEXEC-setup-crash-notes-during-boot.patch"

# HG changeset patch
# Parent b5ceec1ccccad6e79053a80820132303ff1e136f
KEXEC: Allocate crash notes on boot v5

Currently, the buffers for crash notes are allocated per CPU when a
KEXEC_CMD_kexec_get_range hypercall is made, referencing the CPU in
question.

Although it certainly works in general, there are a few edge case problems:

1) There appears to be no guarentee that dom0 will make this hypercall
   for each pcpu on the system.  There appears to be variable
   behaviour depending on how many cpus dom0 is compiled for, and how
   many vcpus Xen gives to dom0.

2) The allocation of these buffers occur at the whim of dom0.  While
   this is typically very early on dom0 boot, but not guarenteed.

3) It is possible (although not sensible) for a crash
   kernel to be loaded without these (or some of these) hypercalls
   being made. Under these circumstances, a crash would cause the
   crash note code path will suffer a slew of null pointer deferences.

4) If the hypercalls are made after late in the day, it is possible
   for the hypercall to return -ENOMEM.  As code tends to be more
   fragile once memory is enhausted, the likelyhood of us needing the
   crash kernel is greater.

In addition, my forthcoming code to support 32bit kdump kernels on
64bit Xen on large (>64GB) boxes will require some guarentees as to
where the crash note buffers are actually allocated in physical
memory.  This is far easier to sort out at boot time, rather than
after dom0 has been booted and potentially using the physical memory
required.

Therefore, allocate the crash note buffers at boot time.

Changes since v4:

 *  Replace the current cpu crash note scheme of using void pointers
    and hand calculating the size each time is needed, by a range
    structure containing a pointer and a size.  This removes duplicate
    times where the size is calculated.
 *  Tweak kexec_get_cpu().  Don't fail if a cpu is offline because it
    may already have crash notes, and may be up by the time a crash
    happens.  Split the error conditions up to return ERANGE for an
    out-of-range cpu request rather than EINVAL.  Finally, returning a
    range of zeros is acceptable, so do this in preference to failing.

Changes since v3:

 *  Alter the spinlocks to avoid calling xmalloc/xfree while holding
    the lock.
 *  Tidy up the coding style used.

Changes since v2:

 *  Allocate crash_notes dynamically using nr_cpu_ids at boot time,
    rather than statically using NR_CPUS.
 *  Fix the incorrect use of signed integers for cpu id.
 *  Fix collateral damage to do_crashdump_trigger() and
    crashdump_trigger_handler caused by reordering sizeof_note() and
    setup_note()
 *  Tweak the issue about returing -ENOMEM from kexec_init_cpu_note().
    No functional change.
 *  Change kexec_get_cpu() to attempt to allocate crash note buffers
    in case we have more free memory now than when the pcpu came up.
 *  Now that there are two codepaths possibly allocating crash notes,
    protect the allocation itself with a spinlock.

Changes since v1:

 *  Use cpu hotplug notifiers to handle allocating of the notes
    buffers rather than assuming the boot state of cpus will be the
    same as the crash state.
 *  Move crash_notes from being per_cpu.  This is because the kdump
    kernel elf binary put in the crash area is hard coded to physical
    addresses which the dom0 kernel typically obtains at boot time.
    If a cpu is offlined, its buffer should not be deallocated because
    the kdump kernel would read junk when trying to get the crash
    notes.  Similarly, the same problem would occur if the cpu was
    re-onlined later and its crash notes buffer was allocated elsewhere.
 *  Only attempt to allocate buffers if a crash area has been
    specified.  Else, allocating crash note buffers is a waste of
    space.  Along with this, change the test in kexec_get_cpu to
    return -EINVAL if no buffers have been allocated.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

diff -r df7cec2c6c03 xen/common/kexec.c
--- a/xen/common/kexec.c
+++ b/xen/common/kexec.c
@@ -25,13 +25,19 @@
 #include <xen/kexec.h>
 #include <public/elfnote.h>
 #include <xsm/xsm.h>
+#include <xen/cpu.h>
 #ifdef CONFIG_COMPAT
 #include <compat/kexec.h>
 #endif
 
 bool_t kexecing = FALSE;
 
-static DEFINE_PER_CPU_READ_MOSTLY(void *, crash_notes);
+/* Memory regions to store the per cpu register state etc. on a crash. */
+typedef struct { Elf_Note * start; size_t size; } crash_note_range_t;
+static crash_note_range_t * crash_notes;
+
+/* Lock to prevent race conditions when allocating the crash note buffers. */
+static DEFINE_SPINLOCK(crash_notes_lock);
 
 static Elf_Note *xen_crash_note;
 
@@ -165,13 +171,17 @@ static void one_cpu_only(void)
 void kexec_crash_save_cpu(void)
 {
     int cpu = smp_processor_id();
-    Elf_Note *note = per_cpu(crash_notes, cpu);
+    Elf_Note *note;
     ELF_Prstatus *prstatus;
     crash_xen_core_t *xencore;
 
+    BUG_ON( ! crash_notes );
+
     if ( cpumask_test_and_set_cpu(cpu, &crash_saved_cpus) )
         return;
 
+    note = crash_notes[cpu].start;
+
     prstatus = (ELF_Prstatus *)ELFNOTE_DESC(note);
 
     note = ELFNOTE_NEXT(note);
@@ -257,13 +267,6 @@ static struct keyhandler crashdump_trigg
     .desc = "trigger a crashdump"
 };
 
-static __init int register_crashdump_trigger(void)
-{
-    register_keyhandler('C', &crashdump_trigger_keyhandler);
-    return 0;
-}
-__initcall(register_crashdump_trigger);
-
 static void setup_note(Elf_Note *n, const char *name, int type, int descsz)
 {
     int l = strlen(name) + 1;
@@ -280,6 +283,129 @@ static int sizeof_note(const char *name,
             ELFNOTE_ALIGN(descsz));
 }
 
+/* Allocate a crash note buffer for a newly onlined cpu. */
+static int kexec_init_cpu_notes(const unsigned long cpu)
+{
+    Elf_Note * note;
+    int ret = 0;
+    int nr_bytes = 0;
+
+    BUG_ON( cpu >= nr_cpu_ids || ! crash_notes );
+
+    /* If already allocated, nothing to do. */
+    if ( crash_notes[cpu].start )
+        return ret;
+
+    /* All CPUs present a PRSTATUS and crash_xen_core note. */
+    nr_bytes =
+        sizeof_note("CORE", sizeof(ELF_Prstatus)) +
+        sizeof_note("Xen", sizeof(crash_xen_core_t));
+
+    /* CPU0 also presents the crash_xen_info note. */
+    if ( ! cpu )
+        nr_bytes = nr_bytes +
+            sizeof_note("Xen", sizeof(crash_xen_info_t));
+
+    note = xmalloc_bytes(nr_bytes);
+
+    /* Protect the write into crash_notes[] with a spinlock, as this function
+     * is on a hotplug path and a hypercall path. */
+    spin_lock(&crash_notes_lock);
+
+    /* If we are racing with another CPU and it has beaten us, give up
+     * gracefully. */
+    if ( crash_notes[cpu].start )
+    {
+        spin_unlock(&crash_notes_lock);
+        /* Always return ok, because whether we successfully allocated or not,
+         * another CPU has successfully allocated. */
+        if ( note )
+            xfree(note);
+    }
+    else
+    {
+        crash_notes[cpu].start = note;
+        crash_notes[cpu].size = nr_bytes;
+        spin_unlock(&crash_notes_lock);
+
+        /* If the allocation failed, and another CPU did not beat us, give
+         * up with ENOMEM. */
+        if ( ! note )
+            ret = -ENOMEM;
+        /* else all is good so lets set up the notes. */
+        else
+        {
+            /* Set up CORE note. */
+            setup_note(note, "CORE", NT_PRSTATUS, sizeof(ELF_Prstatus));
+            note = ELFNOTE_NEXT(note);
+
+            /* Set up Xen CORE note. */
+            setup_note(note, "Xen", XEN_ELFNOTE_CRASH_REGS,
+                       sizeof(crash_xen_core_t));
+
+            if ( ! cpu )
+            {
+                /* Set up Xen Crash Info note. */
+                xen_crash_note = note = ELFNOTE_NEXT(note);
+                setup_note(note, "Xen", XEN_ELFNOTE_CRASH_INFO,
+                           sizeof(crash_xen_info_t));
+            }
+        }
+    }
+
+    return ret;
+}
+
+static int cpu_callback(
+    struct notifier_block *nfb, unsigned long action, void *hcpu)
+{
+    unsigned long cpu = (unsigned long)hcpu;
+
+    /* Only hook on CPU_UP_PREPARE because once a crash_note has been reported
+     * to dom0, it must keep it around in case of a crash, as the crash kernel
+     * will be hard coded to the original physical address reported. */
+    switch ( action )
+    {
+    case CPU_UP_PREPARE:
+        /* Ignore return value.  If this boot time, -ENOMEM will cause all
+         * manner of problems elsewhere very soon, and if it is during runtime,
+         * then failing to allocate crash notes is not a good enough reason to
+         * fail the CPU_UP_PREPARE */
+        kexec_init_cpu_notes(cpu);
+        break;
+    default:
+        break;
+    }
+    return NOTIFY_DONE;
+}
+
+static struct notifier_block cpu_nfb = {
+    .notifier_call = cpu_callback
+};
+
+static int __init kexec_init(void)
+{
+    void *cpu = (void *)(unsigned long)smp_processor_id();
+
+    /* If no crash area, no need to allocate space for notes. */
+    if ( !kexec_crash_area.size )
+        return 0;
+
+    register_keyhandler('C', &crashdump_trigger_keyhandler);
+
+    crash_notes = xzalloc_array(crash_note_range_t, nr_cpu_ids);
+    if ( ! crash_notes )
+        return -ENOMEM;
+
+    cpu_callback(&cpu_nfb, CPU_UP_PREPARE, cpu);
+    register_cpu_notifier(&cpu_nfb);
+    return 0;
+}
+/* The reason for this to be a presmp_initcall as opposed to a regular
+ * __initcall is to allow the setup of the cpu hotplug handler before APs are
+ * brought up. */
+presmp_initcall(kexec_init);
+
 static int kexec_get_reserve(xen_kexec_range_t *range)
 {
     if ( kexec_crash_area.size > 0 && kexec_crash_area.start > 0) {
@@ -294,44 +420,23 @@ static int kexec_get_reserve(xen_kexec_r
 static int kexec_get_cpu(xen_kexec_range_t *range)
 {
     int nr = range->nr;
-    int nr_bytes = 0;
 
-    if ( nr < 0 || nr >= nr_cpu_ids || !cpu_online(nr) )
+    if ( nr < 0 || nr >= nr_cpu_ids )
+        return -ERANGE;
+
+    if ( ! crash_notes )
         return -EINVAL;
 
-    nr_bytes += sizeof_note("CORE", sizeof(ELF_Prstatus));
-    nr_bytes += sizeof_note("Xen", sizeof(crash_xen_core_t));
+    /* Try once again to allocate room for the crash notes.  It is just possible
+     * that more space has become available since we last tried.  If space has
+     * already been allocated, kexec_init_cpu_notes() will return early with 0.
+     */
+    kexec_init_cpu_notes(nr);
 
-    /* The Xen info note is included in CPU0's range. */
-    if ( nr == 0 )
-        nr_bytes += sizeof_note("Xen", sizeof(crash_xen_info_t));
-
-    if ( per_cpu(crash_notes, nr) == NULL )
-    {
-        Elf_Note *note;
-
-        note = per_cpu(crash_notes, nr) = xmalloc_bytes(nr_bytes);
-
-        if ( note == NULL )
-            return -ENOMEM;
-
-        /* Setup CORE note. */
-        setup_note(note, "CORE", NT_PRSTATUS, sizeof(ELF_Prstatus));
-
-        /* Setup Xen CORE note. */
-        note = ELFNOTE_NEXT(note);
-        setup_note(note, "Xen", XEN_ELFNOTE_CRASH_REGS, sizeof(crash_xen_core_t));
-
-        if (nr == 0)
-        {
-            /* Setup system wide Xen info note. */
-            xen_crash_note = note = ELFNOTE_NEXT(note);
-            setup_note(note, "Xen", XEN_ELFNOTE_CRASH_INFO, sizeof(crash_xen_info_t));
-        }
-    }
-
-    range->start = __pa((unsigned long)per_cpu(crash_notes, nr));
-    range->size = nr_bytes;
+    /* In the case of still not having enough memory to allocate buffer room,
+     * returning a range of 0,0 is still valid. */
+    range->start = __pa((unsigned long)crash_notes[nr].start);
+    range->size = crash_notes[nr].size;
     return 0;
 }
 

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

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

--------------060905080009020205040404--


From xen-devel-bounces@lists.xensource.com Fri Dec 02 15:21:09 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 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.xensource.com>)
	id 1RWUuj-0002Ly-33; Fri, 02 Dec 2011 15:20:37 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1RWUuh-0002Lj-CV
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 15:20:35 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1322839192!7281532!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjg1NDY=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26471 invoked from network); 2 Dec 2011 15:19:53 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Dec 2011 15:19:53 -0000
X-IronPort-AV: E=Sophos;i="4.71,284,1320642000"; d="scan'208";a="172689898"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Dec 2011 10:19:29 -0500
Received: from [10.80.2.18] (10.80.2.18) by FTLPMAILMX02.citrite.net
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Fri, 2 Dec 2011
	10:19:29 -0500
Message-ID: <4ED8EC80.9040701@citrix.com>
Date: Fri, 2 Dec 2011 15:19:28 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.23) Gecko/20110921 Lightning/1.0b2 Thunderbird/3.1.15
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <CAFA7027.25E35%keir.xen@gmail.com>
	<4ED62C50.7060204@citrix.com>	<4ED666D5.5060603@citrix.com>	<4ED7522E0200007800064973@nat28.tlf.novell.com>	<4ED74DAD.1040903@citrix.com>	<4ED75E8402000078000649E6@nat28.tlf.novell.com>	<4ED77347.6060200@citrix.com>	<4ED787870200007800064B6F@nat28.tlf.novell.com>	<4ED79722.7090404@citrix.com>	<4ED7A8110200007800064C50@nat28.tlf.novell.com>	<4ED7B5FF.2090305@citrix.com>	<4ED894100200007800064FE3@nat28.tlf.novell.com>
	<4ED8C592.3010603@citrix.com>
In-Reply-To: <4ED8C592.3010603@citrix.com>
X-Enigmail-Version: 1.1.2
Content-Type: multipart/mixed; boundary="------------060905080009020205040404"
Cc: Keir Fraser <keir.xen@gmail.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: [Xen-devel] KEXEC: allocate crash note buffers at boot time v5
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--------------060905080009020205040404
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit

Here is v5.

I have tested quite carefully the impact of changing the error
conditions in kexec_get_cpu().  dom0 is happy to accept ERANGE as well
as EINVAL, and ERANGE is a more sensible response.  Moreover, this new
scheme (ignoring for a moment ENOMEM) allows for all nr_cpu_ids to give
note ranges to dom0 whether they are up or not at the moment.   It is
better to have more notes provided with some of them potentially not
filled in, than to miss a crashed CPU register state because it was
offline when the crash kernel was loaded.

All this testing has been done via backport to 4.1.2.  Minimal changes
were necessary, such as the lack of xzalloc_array() and NR_CPUS instead
of nr_cpu_ids, but it was otherwise functionally identical.

I am not sure whether to recomend this for backport into 4.1-testing or
not.  It does make the crashkernel more likely to get crash notes,
although in reality, it was only special circumstances which caused
problems.  If you consider it worth backporting, I can provide my
already-backported patch.

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com


--------------060905080009020205040404
Content-Type: text/x-patch; name="KEXEC-setup-crash-notes-during-boot.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename="KEXEC-setup-crash-notes-during-boot.patch"

# HG changeset patch
# Parent b5ceec1ccccad6e79053a80820132303ff1e136f
KEXEC: Allocate crash notes on boot v5

Currently, the buffers for crash notes are allocated per CPU when a
KEXEC_CMD_kexec_get_range hypercall is made, referencing the CPU in
question.

Although it certainly works in general, there are a few edge case problems:

1) There appears to be no guarentee that dom0 will make this hypercall
   for each pcpu on the system.  There appears to be variable
   behaviour depending on how many cpus dom0 is compiled for, and how
   many vcpus Xen gives to dom0.

2) The allocation of these buffers occur at the whim of dom0.  While
   this is typically very early on dom0 boot, but not guarenteed.

3) It is possible (although not sensible) for a crash
   kernel to be loaded without these (or some of these) hypercalls
   being made. Under these circumstances, a crash would cause the
   crash note code path will suffer a slew of null pointer deferences.

4) If the hypercalls are made after late in the day, it is possible
   for the hypercall to return -ENOMEM.  As code tends to be more
   fragile once memory is enhausted, the likelyhood of us needing the
   crash kernel is greater.

In addition, my forthcoming code to support 32bit kdump kernels on
64bit Xen on large (>64GB) boxes will require some guarentees as to
where the crash note buffers are actually allocated in physical
memory.  This is far easier to sort out at boot time, rather than
after dom0 has been booted and potentially using the physical memory
required.

Therefore, allocate the crash note buffers at boot time.

Changes since v4:

 *  Replace the current cpu crash note scheme of using void pointers
    and hand calculating the size each time is needed, by a range
    structure containing a pointer and a size.  This removes duplicate
    times where the size is calculated.
 *  Tweak kexec_get_cpu().  Don't fail if a cpu is offline because it
    may already have crash notes, and may be up by the time a crash
    happens.  Split the error conditions up to return ERANGE for an
    out-of-range cpu request rather than EINVAL.  Finally, returning a
    range of zeros is acceptable, so do this in preference to failing.

Changes since v3:

 *  Alter the spinlocks to avoid calling xmalloc/xfree while holding
    the lock.
 *  Tidy up the coding style used.

Changes since v2:

 *  Allocate crash_notes dynamically using nr_cpu_ids at boot time,
    rather than statically using NR_CPUS.
 *  Fix the incorrect use of signed integers for cpu id.
 *  Fix collateral damage to do_crashdump_trigger() and
    crashdump_trigger_handler caused by reordering sizeof_note() and
    setup_note()
 *  Tweak the issue about returing -ENOMEM from kexec_init_cpu_note().
    No functional change.
 *  Change kexec_get_cpu() to attempt to allocate crash note buffers
    in case we have more free memory now than when the pcpu came up.
 *  Now that there are two codepaths possibly allocating crash notes,
    protect the allocation itself with a spinlock.

Changes since v1:

 *  Use cpu hotplug notifiers to handle allocating of the notes
    buffers rather than assuming the boot state of cpus will be the
    same as the crash state.
 *  Move crash_notes from being per_cpu.  This is because the kdump
    kernel elf binary put in the crash area is hard coded to physical
    addresses which the dom0 kernel typically obtains at boot time.
    If a cpu is offlined, its buffer should not be deallocated because
    the kdump kernel would read junk when trying to get the crash
    notes.  Similarly, the same problem would occur if the cpu was
    re-onlined later and its crash notes buffer was allocated elsewhere.
 *  Only attempt to allocate buffers if a crash area has been
    specified.  Else, allocating crash note buffers is a waste of
    space.  Along with this, change the test in kexec_get_cpu to
    return -EINVAL if no buffers have been allocated.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

diff -r df7cec2c6c03 xen/common/kexec.c
--- a/xen/common/kexec.c
+++ b/xen/common/kexec.c
@@ -25,13 +25,19 @@
 #include <xen/kexec.h>
 #include <public/elfnote.h>
 #include <xsm/xsm.h>
+#include <xen/cpu.h>
 #ifdef CONFIG_COMPAT
 #include <compat/kexec.h>
 #endif
 
 bool_t kexecing = FALSE;
 
-static DEFINE_PER_CPU_READ_MOSTLY(void *, crash_notes);
+/* Memory regions to store the per cpu register state etc. on a crash. */
+typedef struct { Elf_Note * start; size_t size; } crash_note_range_t;
+static crash_note_range_t * crash_notes;
+
+/* Lock to prevent race conditions when allocating the crash note buffers. */
+static DEFINE_SPINLOCK(crash_notes_lock);
 
 static Elf_Note *xen_crash_note;
 
@@ -165,13 +171,17 @@ static void one_cpu_only(void)
 void kexec_crash_save_cpu(void)
 {
     int cpu = smp_processor_id();
-    Elf_Note *note = per_cpu(crash_notes, cpu);
+    Elf_Note *note;
     ELF_Prstatus *prstatus;
     crash_xen_core_t *xencore;
 
+    BUG_ON( ! crash_notes );
+
     if ( cpumask_test_and_set_cpu(cpu, &crash_saved_cpus) )
         return;
 
+    note = crash_notes[cpu].start;
+
     prstatus = (ELF_Prstatus *)ELFNOTE_DESC(note);
 
     note = ELFNOTE_NEXT(note);
@@ -257,13 +267,6 @@ static struct keyhandler crashdump_trigg
     .desc = "trigger a crashdump"
 };
 
-static __init int register_crashdump_trigger(void)
-{
-    register_keyhandler('C', &crashdump_trigger_keyhandler);
-    return 0;
-}
-__initcall(register_crashdump_trigger);
-
 static void setup_note(Elf_Note *n, const char *name, int type, int descsz)
 {
     int l = strlen(name) + 1;
@@ -280,6 +283,129 @@ static int sizeof_note(const char *name,
             ELFNOTE_ALIGN(descsz));
 }
 
+/* Allocate a crash note buffer for a newly onlined cpu. */
+static int kexec_init_cpu_notes(const unsigned long cpu)
+{
+    Elf_Note * note;
+    int ret = 0;
+    int nr_bytes = 0;
+
+    BUG_ON( cpu >= nr_cpu_ids || ! crash_notes );
+
+    /* If already allocated, nothing to do. */
+    if ( crash_notes[cpu].start )
+        return ret;
+
+    /* All CPUs present a PRSTATUS and crash_xen_core note. */
+    nr_bytes =
+        sizeof_note("CORE", sizeof(ELF_Prstatus)) +
+        sizeof_note("Xen", sizeof(crash_xen_core_t));
+
+    /* CPU0 also presents the crash_xen_info note. */
+    if ( ! cpu )
+        nr_bytes = nr_bytes +
+            sizeof_note("Xen", sizeof(crash_xen_info_t));
+
+    note = xmalloc_bytes(nr_bytes);
+
+    /* Protect the write into crash_notes[] with a spinlock, as this function
+     * is on a hotplug path and a hypercall path. */
+    spin_lock(&crash_notes_lock);
+
+    /* If we are racing with another CPU and it has beaten us, give up
+     * gracefully. */
+    if ( crash_notes[cpu].start )
+    {
+        spin_unlock(&crash_notes_lock);
+        /* Always return ok, because whether we successfully allocated or not,
+         * another CPU has successfully allocated. */
+        if ( note )
+            xfree(note);
+    }
+    else
+    {
+        crash_notes[cpu].start = note;
+        crash_notes[cpu].size = nr_bytes;
+        spin_unlock(&crash_notes_lock);
+
+        /* If the allocation failed, and another CPU did not beat us, give
+         * up with ENOMEM. */
+        if ( ! note )
+            ret = -ENOMEM;
+        /* else all is good so lets set up the notes. */
+        else
+        {
+            /* Set up CORE note. */
+            setup_note(note, "CORE", NT_PRSTATUS, sizeof(ELF_Prstatus));
+            note = ELFNOTE_NEXT(note);
+
+            /* Set up Xen CORE note. */
+            setup_note(note, "Xen", XEN_ELFNOTE_CRASH_REGS,
+                       sizeof(crash_xen_core_t));
+
+            if ( ! cpu )
+            {
+                /* Set up Xen Crash Info note. */
+                xen_crash_note = note = ELFNOTE_NEXT(note);
+                setup_note(note, "Xen", XEN_ELFNOTE_CRASH_INFO,
+                           sizeof(crash_xen_info_t));
+            }
+        }
+    }
+
+    return ret;
+}
+
+static int cpu_callback(
+    struct notifier_block *nfb, unsigned long action, void *hcpu)
+{
+    unsigned long cpu = (unsigned long)hcpu;
+
+    /* Only hook on CPU_UP_PREPARE because once a crash_note has been reported
+     * to dom0, it must keep it around in case of a crash, as the crash kernel
+     * will be hard coded to the original physical address reported. */
+    switch ( action )
+    {
+    case CPU_UP_PREPARE:
+        /* Ignore return value.  If this boot time, -ENOMEM will cause all
+         * manner of problems elsewhere very soon, and if it is during runtime,
+         * then failing to allocate crash notes is not a good enough reason to
+         * fail the CPU_UP_PREPARE */
+        kexec_init_cpu_notes(cpu);
+        break;
+    default:
+        break;
+    }
+    return NOTIFY_DONE;
+}
+
+static struct notifier_block cpu_nfb = {
+    .notifier_call = cpu_callback
+};
+
+static int __init kexec_init(void)
+{
+    void *cpu = (void *)(unsigned long)smp_processor_id();
+
+    /* If no crash area, no need to allocate space for notes. */
+    if ( !kexec_crash_area.size )
+        return 0;
+
+    register_keyhandler('C', &crashdump_trigger_keyhandler);
+
+    crash_notes = xzalloc_array(crash_note_range_t, nr_cpu_ids);
+    if ( ! crash_notes )
+        return -ENOMEM;
+
+    cpu_callback(&cpu_nfb, CPU_UP_PREPARE, cpu);
+    register_cpu_notifier(&cpu_nfb);
+    return 0;
+}
+/* The reason for this to be a presmp_initcall as opposed to a regular
+ * __initcall is to allow the setup of the cpu hotplug handler before APs are
+ * brought up. */
+presmp_initcall(kexec_init);
+
 static int kexec_get_reserve(xen_kexec_range_t *range)
 {
     if ( kexec_crash_area.size > 0 && kexec_crash_area.start > 0) {
@@ -294,44 +420,23 @@ static int kexec_get_reserve(xen_kexec_r
 static int kexec_get_cpu(xen_kexec_range_t *range)
 {
     int nr = range->nr;
-    int nr_bytes = 0;
 
-    if ( nr < 0 || nr >= nr_cpu_ids || !cpu_online(nr) )
+    if ( nr < 0 || nr >= nr_cpu_ids )
+        return -ERANGE;
+
+    if ( ! crash_notes )
         return -EINVAL;
 
-    nr_bytes += sizeof_note("CORE", sizeof(ELF_Prstatus));
-    nr_bytes += sizeof_note("Xen", sizeof(crash_xen_core_t));
+    /* Try once again to allocate room for the crash notes.  It is just possible
+     * that more space has become available since we last tried.  If space has
+     * already been allocated, kexec_init_cpu_notes() will return early with 0.
+     */
+    kexec_init_cpu_notes(nr);
 
-    /* The Xen info note is included in CPU0's range. */
-    if ( nr == 0 )
-        nr_bytes += sizeof_note("Xen", sizeof(crash_xen_info_t));
-
-    if ( per_cpu(crash_notes, nr) == NULL )
-    {
-        Elf_Note *note;
-
-        note = per_cpu(crash_notes, nr) = xmalloc_bytes(nr_bytes);
-
-        if ( note == NULL )
-            return -ENOMEM;
-
-        /* Setup CORE note. */
-        setup_note(note, "CORE", NT_PRSTATUS, sizeof(ELF_Prstatus));
-
-        /* Setup Xen CORE note. */
-        note = ELFNOTE_NEXT(note);
-        setup_note(note, "Xen", XEN_ELFNOTE_CRASH_REGS, sizeof(crash_xen_core_t));
-
-        if (nr == 0)
-        {
-            /* Setup system wide Xen info note. */
-            xen_crash_note = note = ELFNOTE_NEXT(note);
-            setup_note(note, "Xen", XEN_ELFNOTE_CRASH_INFO, sizeof(crash_xen_info_t));
-        }
-    }
-
-    range->start = __pa((unsigned long)per_cpu(crash_notes, nr));
-    range->size = nr_bytes;
+    /* In the case of still not having enough memory to allocate buffer room,
+     * returning a range of 0,0 is still valid. */
+    range->start = __pa((unsigned long)crash_notes[nr].start);
+    range->size = crash_notes[nr].size;
     return 0;
 }
 

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

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

--------------060905080009020205040404--


From xen-devel-bounces@lists.xensource.com Fri Dec 02 15:24:58 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 15:24:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWUyT-0002Zp-Ts; Fri, 02 Dec 2011 15:24:29 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1RWUyS-0002Zb-IP
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 15:24:29 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-2.tower-174.messagelabs.com!1322839425!3994557!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29211 invoked from network); 2 Dec 2011 15:23:46 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-2.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 2 Dec 2011 15:23:46 -0000
Received: from andromeda.dapyr.net (darnok@localhost [127.0.0.1])
	by andromeda.dapyr.net (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id
	pB2FNgoI002814
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Fri, 2 Dec 2011 10:23:42 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pB2FNdAw002812;
	Fri, 2 Dec 2011 10:23:39 -0500
Date: Fri, 2 Dec 2011 11:23:39 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <20111202152339.GA2687@andromeda.dapyr.net>
References: <zarafa.4ece387c.6e85.6aa0c9ca21e63bd9@uhura.space.zz>
	<zarafa.4ed012ab.3c16.45021173211daab7@uhura.space.zz>
	<20111128152829.GC9655@andromeda.dapyr.net>
	<1322494816.20646.14.camel@zakaz.uk.xensource.com>
	<20111128164516.GA26664@phenom.dumpdata.com>
	<1322562199.20646.30.camel@zakaz.uk.xensource.com>
	<20111129153306.GA30908@phenom.dumpdata.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="vkogqOf2sHV7VnPd"
Content-Disposition: inline
In-Reply-To: <20111129153306.GA30908@phenom.dumpdata.com>
User-Agent: Mutt/1.5.9i
Cc: "lersek@redhat.com" <lersek@redhat.com>,
	xen-devel <xen-devel@lists.xensource.com>,
	Carsten Schiers <carsten@schiers.de>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"zhenzhong.duan@oracle.com" <zhenzhong.duan@oracle.com>
Subject: Re: [Xen-devel] Load increase after memory upgrade (part2)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--vkogqOf2sHV7VnPd
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

> > > > > That is a puzzle. It should not. The code is very much the same - both
> > > > > use the generic SWIOTLB which has not changed for years.
> > > > 
> > > > The swiotlb-xen used by classic-xen kernels (which I assume is what
> > > > Carsten means by "Xenified") isn't exactly the same as the stuff in
> > > > mainline Linux, it's been heavily refactored for one thing. It's not
> > > > impossible that mainline is bouncing something it doesn't really need
> > > > to.
> > > 
> > > The usage, at least with 'pci_alloc_coherent' is that there is no bouncing
> > > being done. The alloc_coherent will allocate a nice page, underneath the 4GB
> > > mark and give it to the driver. The driver can use it as it wishes and there
> > > is no need to bounce buffer.
> > 
> > Oh, I didn't realise dma_alloc_coherent was part of swiotlb now. Only a
> > subset of swiotlb is in use then, all the bouncing stuff _should_ be
> > idle/unused -- but has that been confirmed?
> 
> Nope. I hope that the diagnostic patch I have in mind will prove/disprove that.
> Now I just need to find a moment to write it :-)

Done!

Carsten, can you please patch your kernel with this hacky patch and
when you have booted the new kernel, just do

modprobe dump_swiotlb

it should give an idea of how many bounces are happening, coherent
allocations, syncs, and so on.. along with the last driver that
did those operations.


--vkogqOf2sHV7VnPd
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="swiotlb-debug.patch"

diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
index a59638b..d513c8d 100644
--- a/drivers/xen/Kconfig
+++ b/drivers/xen/Kconfig
@@ -105,4 +105,10 @@ config SWIOTLB_XEN
 	depends on PCI
 	select SWIOTLB
 
+config SWIOTLB_DEBUG
+	tristate "swiotlb debug facility"
+	default m
+	help
+	  Do not enable it unless you know what you are doing.
+
 endmenu
diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
index bbc1825..1dea490 100644
--- a/drivers/xen/Makefile
+++ b/drivers/xen/Makefile
@@ -16,6 +16,7 @@ obj-$(CONFIG_XENFS)			+= xenfs/
 obj-$(CONFIG_XEN_SYS_HYPERVISOR)	+= sys-hypervisor.o
 obj-$(CONFIG_XEN_PLATFORM_PCI)		+= xen-platform-pci.o
 obj-$(CONFIG_SWIOTLB_XEN)		+= swiotlb-xen.o
+obj-$(CONFIG_SWIOTLB_DEBUG)		+= dump_swiotlb.o
 obj-$(CONFIG_XEN_DOM0)			+= pci.o
 
 xen-evtchn-y				:= evtchn.o
diff --git a/drivers/xen/dump_swiotlb.c b/drivers/xen/dump_swiotlb.c
new file mode 100644
index 0000000..e0e4a0b
--- /dev/null
+++ b/drivers/xen/dump_swiotlb.c
@@ -0,0 +1,72 @@
+/*
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License v2.0 as published by
+ * the Free Software Foundation
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include <linux/module.h>
+#include <linux/string.h>
+#include <linux/types.h>
+#include <linux/init.h>
+#include <linux/stat.h>
+#include <linux/err.h>
+#include <linux/ctype.h>
+#include <linux/slab.h>
+#include <linux/limits.h>
+#include <linux/device.h>
+#include <linux/pci.h>
+#include <linux/blkdev.h>
+#include <linux/device.h>
+
+#include <linux/init.h>
+#include <linux/mm.h>
+#include <linux/fcntl.h>
+#include <linux/slab.h>
+#include <linux/kmod.h>
+#include <linux/major.h>
+#include <linux/highmem.h>
+#include <linux/blkdev.h>
+#include <linux/module.h>
+#include <linux/blkpg.h>
+#include <linux/buffer_head.h>
+#include <linux/mpage.h>
+#include <linux/mount.h>
+#include <linux/uio.h>
+#include <linux/namei.h>
+#include <asm/uaccess.h>
+
+#include <linux/pagemap.h>
+#include <linux/pagevec.h>
+
+#include <linux/swiotlb.h>
+#define DUMP_SWIOTLB_FUN  "0.1"
+
+MODULE_AUTHOR("Konrad Rzeszutek Wilk <konrad@darnok.org>");
+MODULE_DESCRIPTION("dump swiotlb");
+MODULE_LICENSE("GPL");
+MODULE_VERSION(DUMP_SWIOTLB_FUN);
+
+extern int xen_swiotlb_start_thread(void);
+extern void xen_swiotlb_stop_thread(void);
+static int __init dump_swiotlb_init(void)
+{
+	printk(KERN_INFO "Starting SWIOTLB debug thread.\n");
+	swiotlb_start_thread();
+	xen_swiotlb_start_thread();
+	return 0;
+}
+
+static void __exit dump_swiotlb_exit(void)
+{
+	swiotlb_stop_thread();
+	xen_swiotlb_stop_thread();
+}
+
+module_init(dump_swiotlb_init);
+module_exit(dump_swiotlb_exit);
diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index 6e8c15a..c833501 100644
--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -143,6 +143,63 @@ xen_swiotlb_fixup(void *buf, size_t size, unsigned long nslabs)
 	return 0;
 }
 
+#include <linux/percpu.h>
+struct xen_swiotlb_debug {
+	unsigned long alloc;
+	unsigned long dealloc;
+	char dev_name[64];
+};
+static DEFINE_PER_CPU(struct xen_swiotlb_debug, xen_tlb_debug);
+#include <linux/kthread.h>
+static int xen_swiotlb_debug_thread(void *arg)
+{
+	int cpu;
+	do {
+		set_current_state(TASK_INTERRUPTIBLE);
+		schedule_timeout_interruptible(HZ*10);
+
+		for_each_online_cpu(cpu) {
+			struct xen_swiotlb_debug *d;
+
+			d = &per_cpu(xen_tlb_debug, cpu);
+			/* Can't really happend.*/
+			if (!d)
+				continue;
+
+			if (d->dev_name[0] == 0)
+				continue;
+
+			printk(KERN_INFO "%u %s alloc coherent: %ld, free: %ld\n",
+				cpu,
+				d->dev_name ? d->dev_name : "?",
+				d->alloc, d->dealloc);
+
+			memset(d, 0, sizeof(struct xen_swiotlb_debug));
+		}
+
+	} while (!kthread_should_stop());
+	return 0;
+}
+static struct task_struct *xen_debug_thread = NULL;
+
+int xen_swiotlb_start_thread(void) {
+
+	if (xen_debug_thread)
+		return -EINVAL;
+	printk(KERN_INFO "%s: Go!\n",__func__);
+	xen_debug_thread =  kthread_run(xen_swiotlb_debug_thread, NULL, "xen_swiotlb_debug");
+	return 0;
+}
+EXPORT_SYMBOL_GPL(xen_swiotlb_start_thread);
+void xen_swiotlb_stop_thread(void) {
+
+	printk(KERN_INFO "%s: Stop!\n",__func__);
+	if (xen_debug_thread)
+		kthread_stop(xen_debug_thread);
+	xen_debug_thread = NULL;
+}
+EXPORT_SYMBOL_GPL(xen_swiotlb_stop_thread);
+
 void __init xen_swiotlb_init(int verbose)
 {
 	unsigned long bytes;
@@ -194,7 +251,14 @@ xen_swiotlb_alloc_coherent(struct device *hwdev, size_t size,
 	int order = get_order(size);
 	u64 dma_mask = DMA_BIT_MASK(32);
 	unsigned long vstart;
-
+	struct xen_swiotlb_debug *d;
+
+	preempt_disable();
+	d = &__get_cpu_var(xen_tlb_debug);
+	preempt_enable();
+	d->alloc++;
+	snprintf(d->dev_name, sizeof(d->dev_name), "%s %s",
+                dev_driver_string(hwdev), dev_name(hwdev));
 	/*
 	* Ignore region specifiers - the kernel's ideas of
 	* pseudo-phys memory layout has nothing to do with the
@@ -230,6 +294,14 @@ xen_swiotlb_free_coherent(struct device *hwdev, size_t size, void *vaddr,
 			  dma_addr_t dev_addr)
 {
 	int order = get_order(size);
+	struct xen_swiotlb_debug *d;
+
+	preempt_disable();
+	d = &__get_cpu_var(xen_tlb_debug);
+	preempt_enable();
+	d->dealloc++;
+	snprintf(d->dev_name, sizeof(d->dev_name), "%s %s",
+                dev_driver_string(hwdev), dev_name(hwdev));
 
 	if (dma_release_from_coherent(hwdev, order, vaddr))
 		return;
diff --git a/include/linux/swiotlb.h b/include/linux/swiotlb.h
index 445702c..0d2e049 100644
--- a/include/linux/swiotlb.h
+++ b/include/linux/swiotlb.h
@@ -26,6 +26,8 @@ extern void swiotlb_init(int verbose);
 extern void swiotlb_init_with_tbl(char *tlb, unsigned long nslabs, int verbose);
 extern unsigned long swioltb_nr_tbl(void);
 
+extern int swiotlb_start_thread(void);
+extern void swiotlb_stop_thread(void);
 /*
  * Enumeration for sync targets
  */
diff --git a/lib/swiotlb.c b/lib/swiotlb.c
index 99093b3..5446076 100644
--- a/lib/swiotlb.c
+++ b/lib/swiotlb.c
@@ -92,6 +92,74 @@ static DEFINE_SPINLOCK(io_tlb_lock);
 
 static int late_alloc;
 
+#include <linux/percpu.h>
+struct swiotlb_debug {
+	unsigned long bounce_to;
+	unsigned long bounce_from;
+	unsigned long bounce_slow;
+	unsigned long map;
+	unsigned long unmap;
+	unsigned long sync;
+	char dev_name[64];
+};
+static DEFINE_PER_CPU(struct swiotlb_debug, tlb_debug);
+#include <linux/kthread.h>
+static int swiotlb_debug_thread(void *arg)
+{
+	int cpu;
+	int size = io_tlb_nslabs;
+	do {
+		int i;
+		unsigned long filled = 0;
+		set_current_state(TASK_INTERRUPTIBLE);
+		schedule_timeout_interruptible(HZ*5);
+
+		for_each_online_cpu(cpu) {
+			struct swiotlb_debug *d = &per_cpu(tlb_debug, cpu);
+			/* Can't really happend.*/
+			if (!d)
+				continue;
+			if (d->dev_name[0] == 0)
+				continue;
+
+			printk(KERN_INFO "%d [%s] bounce: from:%ld(slow:%ld)to:%ld map:%ld unmap:%ld sync:%ld\n",
+				cpu,
+				d->dev_name ? d->dev_name : "?",
+				d->bounce_from,
+				d->bounce_slow,
+				d->bounce_to,
+				d->map, d->unmap, d->sync);
+			memset(d, 0, sizeof(struct swiotlb_debug));
+		}
+		/* Very crude calculation. */
+		for (i = 0; i < size; i++) {
+			if (io_tlb_list[i] == 0)
+				filled++;
+		}
+		printk(KERN_INFO "SWIOTLB is %ld%% full\n", (filled * 100) / size);
+
+	} while (!kthread_should_stop());
+	return 0;
+}
+static struct task_struct *debug_thread = NULL;
+
+int swiotlb_start_thread(void) {
+
+	if (debug_thread)
+		return -EINVAL;
+	printk(KERN_INFO "%s: Go!\n",__func__);
+	debug_thread =  kthread_run(swiotlb_debug_thread, NULL, "swiotlb_debug");
+}
+EXPORT_SYMBOL_GPL(swiotlb_start_thread);
+void swiotlb_stop_thread(void) {
+
+	printk(KERN_INFO "%s: Stop!\n",__func__);
+	if (debug_thread)
+		kthread_stop(debug_thread);
+	debug_thread = NULL;
+}
+EXPORT_SYMBOL_GPL(swiotlb_stop_thread);
+
 static int __init
 setup_io_tlb_npages(char *str)
 {
@@ -166,6 +234,7 @@ void __init swiotlb_init_with_tbl(char *tlb, unsigned long nslabs, int verbose)
 		panic("Cannot allocate SWIOTLB overflow buffer!\n");
 	if (verbose)
 		swiotlb_print_info();
+
 }
 
 /*
@@ -336,6 +405,7 @@ void swiotlb_bounce(phys_addr_t phys, char *dma_addr, size_t size,
 		    enum dma_data_direction dir)
 {
 	unsigned long pfn = PFN_DOWN(phys);
+	struct swiotlb_debug *d = &__get_cpu_var(tlb_debug);
 
 	if (PageHighMem(pfn_to_page(pfn))) {
 		/* The buffer does not have a mapping.  Map it in and copy */
@@ -362,11 +432,16 @@ void swiotlb_bounce(phys_addr_t phys, char *dma_addr, size_t size,
 			dma_addr += sz;
 			offset = 0;
 		}
+		d->bounce_slow++;
 	} else {
-		if (dir == DMA_TO_DEVICE)
+		if (dir == DMA_TO_DEVICE) {
 			memcpy(dma_addr, phys_to_virt(phys), size);
-		else
+			d->bounce_to++;
+		}
+		else {
 			memcpy(phys_to_virt(phys), dma_addr, size);
+			d->bounce_from++;
+		}
 	}
 }
 EXPORT_SYMBOL_GPL(swiotlb_bounce);
@@ -471,7 +546,15 @@ found:
 		io_tlb_orig_addr[index+i] = phys + (i << IO_TLB_SHIFT);
 	if (dir == DMA_TO_DEVICE || dir == DMA_BIDIRECTIONAL)
 		swiotlb_bounce(phys, dma_addr, size, DMA_TO_DEVICE);
-
+	{
+		struct swiotlb_debug *d;
+		preempt_disable();
+		d = &__get_cpu_var(tlb_debug);
+		preempt_enable();
+		d->map++;
+		snprintf(d->dev_name, sizeof(d->dev_name), "%s %s",
+                	dev_driver_string(hwdev), dev_name(hwdev));
+	}
 	return dma_addr;
 }
 EXPORT_SYMBOL_GPL(swiotlb_tbl_map_single);
@@ -531,6 +614,15 @@ swiotlb_tbl_unmap_single(struct device *hwdev, char *dma_addr, size_t size,
 			io_tlb_list[i] = ++count;
 	}
 	spin_unlock_irqrestore(&io_tlb_lock, flags);
+	{
+		struct swiotlb_debug *d;
+		preempt_disable();
+		d = &__get_cpu_var(tlb_debug);
+		preempt_enable();
+		d->unmap++;
+		snprintf(d->dev_name, sizeof(d->dev_name), "%s %s",
+                	dev_driver_string(hwdev), dev_name(hwdev));
+	}
 }
 EXPORT_SYMBOL_GPL(swiotlb_tbl_unmap_single);
 
@@ -541,7 +633,13 @@ swiotlb_tbl_sync_single(struct device *hwdev, char *dma_addr, size_t size,
 {
 	int index = (dma_addr - io_tlb_start) >> IO_TLB_SHIFT;
 	phys_addr_t phys = io_tlb_orig_addr[index];
-
+	struct swiotlb_debug *d;
+	preempt_disable();
+	d = &__get_cpu_var(tlb_debug);
+	preempt_enable();
+	d->sync++;
+	snprintf(d->dev_name, sizeof(d->dev_name), "%s %s",
+               	dev_driver_string(hwdev), dev_name(hwdev));
 	phys += ((unsigned long)dma_addr & ((1 << IO_TLB_SHIFT) - 1));
 
 	switch (target) {

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

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

--vkogqOf2sHV7VnPd--


From xen-devel-bounces@lists.xensource.com Fri Dec 02 15:24:58 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 15:24:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWUyT-0002Zp-Ts; Fri, 02 Dec 2011 15:24:29 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1RWUyS-0002Zb-IP
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 15:24:29 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-2.tower-174.messagelabs.com!1322839425!3994557!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29211 invoked from network); 2 Dec 2011 15:23:46 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-2.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 2 Dec 2011 15:23:46 -0000
Received: from andromeda.dapyr.net (darnok@localhost [127.0.0.1])
	by andromeda.dapyr.net (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id
	pB2FNgoI002814
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Fri, 2 Dec 2011 10:23:42 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pB2FNdAw002812;
	Fri, 2 Dec 2011 10:23:39 -0500
Date: Fri, 2 Dec 2011 11:23:39 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <20111202152339.GA2687@andromeda.dapyr.net>
References: <zarafa.4ece387c.6e85.6aa0c9ca21e63bd9@uhura.space.zz>
	<zarafa.4ed012ab.3c16.45021173211daab7@uhura.space.zz>
	<20111128152829.GC9655@andromeda.dapyr.net>
	<1322494816.20646.14.camel@zakaz.uk.xensource.com>
	<20111128164516.GA26664@phenom.dumpdata.com>
	<1322562199.20646.30.camel@zakaz.uk.xensource.com>
	<20111129153306.GA30908@phenom.dumpdata.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="vkogqOf2sHV7VnPd"
Content-Disposition: inline
In-Reply-To: <20111129153306.GA30908@phenom.dumpdata.com>
User-Agent: Mutt/1.5.9i
Cc: "lersek@redhat.com" <lersek@redhat.com>,
	xen-devel <xen-devel@lists.xensource.com>,
	Carsten Schiers <carsten@schiers.de>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"zhenzhong.duan@oracle.com" <zhenzhong.duan@oracle.com>
Subject: Re: [Xen-devel] Load increase after memory upgrade (part2)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--vkogqOf2sHV7VnPd
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

> > > > > That is a puzzle. It should not. The code is very much the same - both
> > > > > use the generic SWIOTLB which has not changed for years.
> > > > 
> > > > The swiotlb-xen used by classic-xen kernels (which I assume is what
> > > > Carsten means by "Xenified") isn't exactly the same as the stuff in
> > > > mainline Linux, it's been heavily refactored for one thing. It's not
> > > > impossible that mainline is bouncing something it doesn't really need
> > > > to.
> > > 
> > > The usage, at least with 'pci_alloc_coherent' is that there is no bouncing
> > > being done. The alloc_coherent will allocate a nice page, underneath the 4GB
> > > mark and give it to the driver. The driver can use it as it wishes and there
> > > is no need to bounce buffer.
> > 
> > Oh, I didn't realise dma_alloc_coherent was part of swiotlb now. Only a
> > subset of swiotlb is in use then, all the bouncing stuff _should_ be
> > idle/unused -- but has that been confirmed?
> 
> Nope. I hope that the diagnostic patch I have in mind will prove/disprove that.
> Now I just need to find a moment to write it :-)

Done!

Carsten, can you please patch your kernel with this hacky patch and
when you have booted the new kernel, just do

modprobe dump_swiotlb

it should give an idea of how many bounces are happening, coherent
allocations, syncs, and so on.. along with the last driver that
did those operations.


--vkogqOf2sHV7VnPd
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="swiotlb-debug.patch"

diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
index a59638b..d513c8d 100644
--- a/drivers/xen/Kconfig
+++ b/drivers/xen/Kconfig
@@ -105,4 +105,10 @@ config SWIOTLB_XEN
 	depends on PCI
 	select SWIOTLB
 
+config SWIOTLB_DEBUG
+	tristate "swiotlb debug facility"
+	default m
+	help
+	  Do not enable it unless you know what you are doing.
+
 endmenu
diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
index bbc1825..1dea490 100644
--- a/drivers/xen/Makefile
+++ b/drivers/xen/Makefile
@@ -16,6 +16,7 @@ obj-$(CONFIG_XENFS)			+= xenfs/
 obj-$(CONFIG_XEN_SYS_HYPERVISOR)	+= sys-hypervisor.o
 obj-$(CONFIG_XEN_PLATFORM_PCI)		+= xen-platform-pci.o
 obj-$(CONFIG_SWIOTLB_XEN)		+= swiotlb-xen.o
+obj-$(CONFIG_SWIOTLB_DEBUG)		+= dump_swiotlb.o
 obj-$(CONFIG_XEN_DOM0)			+= pci.o
 
 xen-evtchn-y				:= evtchn.o
diff --git a/drivers/xen/dump_swiotlb.c b/drivers/xen/dump_swiotlb.c
new file mode 100644
index 0000000..e0e4a0b
--- /dev/null
+++ b/drivers/xen/dump_swiotlb.c
@@ -0,0 +1,72 @@
+/*
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License v2.0 as published by
+ * the Free Software Foundation
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include <linux/module.h>
+#include <linux/string.h>
+#include <linux/types.h>
+#include <linux/init.h>
+#include <linux/stat.h>
+#include <linux/err.h>
+#include <linux/ctype.h>
+#include <linux/slab.h>
+#include <linux/limits.h>
+#include <linux/device.h>
+#include <linux/pci.h>
+#include <linux/blkdev.h>
+#include <linux/device.h>
+
+#include <linux/init.h>
+#include <linux/mm.h>
+#include <linux/fcntl.h>
+#include <linux/slab.h>
+#include <linux/kmod.h>
+#include <linux/major.h>
+#include <linux/highmem.h>
+#include <linux/blkdev.h>
+#include <linux/module.h>
+#include <linux/blkpg.h>
+#include <linux/buffer_head.h>
+#include <linux/mpage.h>
+#include <linux/mount.h>
+#include <linux/uio.h>
+#include <linux/namei.h>
+#include <asm/uaccess.h>
+
+#include <linux/pagemap.h>
+#include <linux/pagevec.h>
+
+#include <linux/swiotlb.h>
+#define DUMP_SWIOTLB_FUN  "0.1"
+
+MODULE_AUTHOR("Konrad Rzeszutek Wilk <konrad@darnok.org>");
+MODULE_DESCRIPTION("dump swiotlb");
+MODULE_LICENSE("GPL");
+MODULE_VERSION(DUMP_SWIOTLB_FUN);
+
+extern int xen_swiotlb_start_thread(void);
+extern void xen_swiotlb_stop_thread(void);
+static int __init dump_swiotlb_init(void)
+{
+	printk(KERN_INFO "Starting SWIOTLB debug thread.\n");
+	swiotlb_start_thread();
+	xen_swiotlb_start_thread();
+	return 0;
+}
+
+static void __exit dump_swiotlb_exit(void)
+{
+	swiotlb_stop_thread();
+	xen_swiotlb_stop_thread();
+}
+
+module_init(dump_swiotlb_init);
+module_exit(dump_swiotlb_exit);
diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index 6e8c15a..c833501 100644
--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -143,6 +143,63 @@ xen_swiotlb_fixup(void *buf, size_t size, unsigned long nslabs)
 	return 0;
 }
 
+#include <linux/percpu.h>
+struct xen_swiotlb_debug {
+	unsigned long alloc;
+	unsigned long dealloc;
+	char dev_name[64];
+};
+static DEFINE_PER_CPU(struct xen_swiotlb_debug, xen_tlb_debug);
+#include <linux/kthread.h>
+static int xen_swiotlb_debug_thread(void *arg)
+{
+	int cpu;
+	do {
+		set_current_state(TASK_INTERRUPTIBLE);
+		schedule_timeout_interruptible(HZ*10);
+
+		for_each_online_cpu(cpu) {
+			struct xen_swiotlb_debug *d;
+
+			d = &per_cpu(xen_tlb_debug, cpu);
+			/* Can't really happend.*/
+			if (!d)
+				continue;
+
+			if (d->dev_name[0] == 0)
+				continue;
+
+			printk(KERN_INFO "%u %s alloc coherent: %ld, free: %ld\n",
+				cpu,
+				d->dev_name ? d->dev_name : "?",
+				d->alloc, d->dealloc);
+
+			memset(d, 0, sizeof(struct xen_swiotlb_debug));
+		}
+
+	} while (!kthread_should_stop());
+	return 0;
+}
+static struct task_struct *xen_debug_thread = NULL;
+
+int xen_swiotlb_start_thread(void) {
+
+	if (xen_debug_thread)
+		return -EINVAL;
+	printk(KERN_INFO "%s: Go!\n",__func__);
+	xen_debug_thread =  kthread_run(xen_swiotlb_debug_thread, NULL, "xen_swiotlb_debug");
+	return 0;
+}
+EXPORT_SYMBOL_GPL(xen_swiotlb_start_thread);
+void xen_swiotlb_stop_thread(void) {
+
+	printk(KERN_INFO "%s: Stop!\n",__func__);
+	if (xen_debug_thread)
+		kthread_stop(xen_debug_thread);
+	xen_debug_thread = NULL;
+}
+EXPORT_SYMBOL_GPL(xen_swiotlb_stop_thread);
+
 void __init xen_swiotlb_init(int verbose)
 {
 	unsigned long bytes;
@@ -194,7 +251,14 @@ xen_swiotlb_alloc_coherent(struct device *hwdev, size_t size,
 	int order = get_order(size);
 	u64 dma_mask = DMA_BIT_MASK(32);
 	unsigned long vstart;
-
+	struct xen_swiotlb_debug *d;
+
+	preempt_disable();
+	d = &__get_cpu_var(xen_tlb_debug);
+	preempt_enable();
+	d->alloc++;
+	snprintf(d->dev_name, sizeof(d->dev_name), "%s %s",
+                dev_driver_string(hwdev), dev_name(hwdev));
 	/*
 	* Ignore region specifiers - the kernel's ideas of
 	* pseudo-phys memory layout has nothing to do with the
@@ -230,6 +294,14 @@ xen_swiotlb_free_coherent(struct device *hwdev, size_t size, void *vaddr,
 			  dma_addr_t dev_addr)
 {
 	int order = get_order(size);
+	struct xen_swiotlb_debug *d;
+
+	preempt_disable();
+	d = &__get_cpu_var(xen_tlb_debug);
+	preempt_enable();
+	d->dealloc++;
+	snprintf(d->dev_name, sizeof(d->dev_name), "%s %s",
+                dev_driver_string(hwdev), dev_name(hwdev));
 
 	if (dma_release_from_coherent(hwdev, order, vaddr))
 		return;
diff --git a/include/linux/swiotlb.h b/include/linux/swiotlb.h
index 445702c..0d2e049 100644
--- a/include/linux/swiotlb.h
+++ b/include/linux/swiotlb.h
@@ -26,6 +26,8 @@ extern void swiotlb_init(int verbose);
 extern void swiotlb_init_with_tbl(char *tlb, unsigned long nslabs, int verbose);
 extern unsigned long swioltb_nr_tbl(void);
 
+extern int swiotlb_start_thread(void);
+extern void swiotlb_stop_thread(void);
 /*
  * Enumeration for sync targets
  */
diff --git a/lib/swiotlb.c b/lib/swiotlb.c
index 99093b3..5446076 100644
--- a/lib/swiotlb.c
+++ b/lib/swiotlb.c
@@ -92,6 +92,74 @@ static DEFINE_SPINLOCK(io_tlb_lock);
 
 static int late_alloc;
 
+#include <linux/percpu.h>
+struct swiotlb_debug {
+	unsigned long bounce_to;
+	unsigned long bounce_from;
+	unsigned long bounce_slow;
+	unsigned long map;
+	unsigned long unmap;
+	unsigned long sync;
+	char dev_name[64];
+};
+static DEFINE_PER_CPU(struct swiotlb_debug, tlb_debug);
+#include <linux/kthread.h>
+static int swiotlb_debug_thread(void *arg)
+{
+	int cpu;
+	int size = io_tlb_nslabs;
+	do {
+		int i;
+		unsigned long filled = 0;
+		set_current_state(TASK_INTERRUPTIBLE);
+		schedule_timeout_interruptible(HZ*5);
+
+		for_each_online_cpu(cpu) {
+			struct swiotlb_debug *d = &per_cpu(tlb_debug, cpu);
+			/* Can't really happend.*/
+			if (!d)
+				continue;
+			if (d->dev_name[0] == 0)
+				continue;
+
+			printk(KERN_INFO "%d [%s] bounce: from:%ld(slow:%ld)to:%ld map:%ld unmap:%ld sync:%ld\n",
+				cpu,
+				d->dev_name ? d->dev_name : "?",
+				d->bounce_from,
+				d->bounce_slow,
+				d->bounce_to,
+				d->map, d->unmap, d->sync);
+			memset(d, 0, sizeof(struct swiotlb_debug));
+		}
+		/* Very crude calculation. */
+		for (i = 0; i < size; i++) {
+			if (io_tlb_list[i] == 0)
+				filled++;
+		}
+		printk(KERN_INFO "SWIOTLB is %ld%% full\n", (filled * 100) / size);
+
+	} while (!kthread_should_stop());
+	return 0;
+}
+static struct task_struct *debug_thread = NULL;
+
+int swiotlb_start_thread(void) {
+
+	if (debug_thread)
+		return -EINVAL;
+	printk(KERN_INFO "%s: Go!\n",__func__);
+	debug_thread =  kthread_run(swiotlb_debug_thread, NULL, "swiotlb_debug");
+}
+EXPORT_SYMBOL_GPL(swiotlb_start_thread);
+void swiotlb_stop_thread(void) {
+
+	printk(KERN_INFO "%s: Stop!\n",__func__);
+	if (debug_thread)
+		kthread_stop(debug_thread);
+	debug_thread = NULL;
+}
+EXPORT_SYMBOL_GPL(swiotlb_stop_thread);
+
 static int __init
 setup_io_tlb_npages(char *str)
 {
@@ -166,6 +234,7 @@ void __init swiotlb_init_with_tbl(char *tlb, unsigned long nslabs, int verbose)
 		panic("Cannot allocate SWIOTLB overflow buffer!\n");
 	if (verbose)
 		swiotlb_print_info();
+
 }
 
 /*
@@ -336,6 +405,7 @@ void swiotlb_bounce(phys_addr_t phys, char *dma_addr, size_t size,
 		    enum dma_data_direction dir)
 {
 	unsigned long pfn = PFN_DOWN(phys);
+	struct swiotlb_debug *d = &__get_cpu_var(tlb_debug);
 
 	if (PageHighMem(pfn_to_page(pfn))) {
 		/* The buffer does not have a mapping.  Map it in and copy */
@@ -362,11 +432,16 @@ void swiotlb_bounce(phys_addr_t phys, char *dma_addr, size_t size,
 			dma_addr += sz;
 			offset = 0;
 		}
+		d->bounce_slow++;
 	} else {
-		if (dir == DMA_TO_DEVICE)
+		if (dir == DMA_TO_DEVICE) {
 			memcpy(dma_addr, phys_to_virt(phys), size);
-		else
+			d->bounce_to++;
+		}
+		else {
 			memcpy(phys_to_virt(phys), dma_addr, size);
+			d->bounce_from++;
+		}
 	}
 }
 EXPORT_SYMBOL_GPL(swiotlb_bounce);
@@ -471,7 +546,15 @@ found:
 		io_tlb_orig_addr[index+i] = phys + (i << IO_TLB_SHIFT);
 	if (dir == DMA_TO_DEVICE || dir == DMA_BIDIRECTIONAL)
 		swiotlb_bounce(phys, dma_addr, size, DMA_TO_DEVICE);
-
+	{
+		struct swiotlb_debug *d;
+		preempt_disable();
+		d = &__get_cpu_var(tlb_debug);
+		preempt_enable();
+		d->map++;
+		snprintf(d->dev_name, sizeof(d->dev_name), "%s %s",
+                	dev_driver_string(hwdev), dev_name(hwdev));
+	}
 	return dma_addr;
 }
 EXPORT_SYMBOL_GPL(swiotlb_tbl_map_single);
@@ -531,6 +614,15 @@ swiotlb_tbl_unmap_single(struct device *hwdev, char *dma_addr, size_t size,
 			io_tlb_list[i] = ++count;
 	}
 	spin_unlock_irqrestore(&io_tlb_lock, flags);
+	{
+		struct swiotlb_debug *d;
+		preempt_disable();
+		d = &__get_cpu_var(tlb_debug);
+		preempt_enable();
+		d->unmap++;
+		snprintf(d->dev_name, sizeof(d->dev_name), "%s %s",
+                	dev_driver_string(hwdev), dev_name(hwdev));
+	}
 }
 EXPORT_SYMBOL_GPL(swiotlb_tbl_unmap_single);
 
@@ -541,7 +633,13 @@ swiotlb_tbl_sync_single(struct device *hwdev, char *dma_addr, size_t size,
 {
 	int index = (dma_addr - io_tlb_start) >> IO_TLB_SHIFT;
 	phys_addr_t phys = io_tlb_orig_addr[index];
-
+	struct swiotlb_debug *d;
+	preempt_disable();
+	d = &__get_cpu_var(tlb_debug);
+	preempt_enable();
+	d->sync++;
+	snprintf(d->dev_name, sizeof(d->dev_name), "%s %s",
+               	dev_driver_string(hwdev), dev_name(hwdev));
 	phys += ((unsigned long)dma_addr & ((1 << IO_TLB_SHIFT) - 1));
 
 	switch (target) {

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

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

--vkogqOf2sHV7VnPd--


From xen-devel-bounces@lists.xensource.com Fri Dec 02 15:28:21 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 15: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.xensource.com>)
	id 1RWV1h-0002oD-Jq; Fri, 02 Dec 2011 15:27:49 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RWV1g-0002nz-B8
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 15:27:48 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-13.tower-216.messagelabs.com!1322839627!5936092!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNDQyNzk=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNDQyNzk=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15486 invoked from network); 2 Dec 2011 15:27:07 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-13.tower-216.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 2 Dec 2011 15:27:07 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1322839626; l=259;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=sm0V2CNMzss0dCRtWBn7A+BgUzM=;
	b=NP3AMfGhHVwaJ+x7awl1cjto0i3EoBdUQtugw52OxbUCPb/7zogkWFj4HZU8cT9bGgW
	4hv0nClZYy9e+vFYQ+1kBDjfYQo2cn4oViqA9zMSUFSM8eTJWmpuyptsP8/89/+bUfQgO
	8l11+uV8kGgNI5DspIL5OddulwKODzDr24E=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFJji0PG5M=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-070-018.pools.arcor-ip.net [88.65.70.18])
	by smtp.strato.de (klopstock mo6) (RZmta 26.10 AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id z05899nB2E0PGM ;
	Fri, 2 Dec 2011 16:26:56 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 12AD918637; Fri,  2 Dec 2011 16:26:55 +0100 (CET)
Date: Fri, 2 Dec 2011 16:26:55 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Keir Fraser <keir.xen@gmail.com>
Message-ID: <20111202152655.GA28246@aepfle.de>
References: <4ED8A05A0200007800065020@nat28.tlf.novell.com>
	<CAFE1A94.26526%keir.xen@gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAFE1A94.26526%keir.xen@gmail.com>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] tools/libxc/xc_cpuid_x86.c:cpuid()'s inline asm
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Dec 02, Keir Fraser wrote:

> I think reg constraint failures had only been reported on 32-bit. So how
> about the attached patch?

+        : "0" (input[0]), "1" (count), "S" (_regs)

_regs is undeclared in 32bit, I think it should be regs.

Olaf

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

From xen-devel-bounces@lists.xensource.com Fri Dec 02 15:28:21 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 15: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.xensource.com>)
	id 1RWV1h-0002oD-Jq; Fri, 02 Dec 2011 15:27:49 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RWV1g-0002nz-B8
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 15:27:48 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-13.tower-216.messagelabs.com!1322839627!5936092!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNDQyNzk=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNDQyNzk=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15486 invoked from network); 2 Dec 2011 15:27:07 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-13.tower-216.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 2 Dec 2011 15:27:07 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1322839626; l=259;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=sm0V2CNMzss0dCRtWBn7A+BgUzM=;
	b=NP3AMfGhHVwaJ+x7awl1cjto0i3EoBdUQtugw52OxbUCPb/7zogkWFj4HZU8cT9bGgW
	4hv0nClZYy9e+vFYQ+1kBDjfYQo2cn4oViqA9zMSUFSM8eTJWmpuyptsP8/89/+bUfQgO
	8l11+uV8kGgNI5DspIL5OddulwKODzDr24E=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFJji0PG5M=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-070-018.pools.arcor-ip.net [88.65.70.18])
	by smtp.strato.de (klopstock mo6) (RZmta 26.10 AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id z05899nB2E0PGM ;
	Fri, 2 Dec 2011 16:26:56 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 12AD918637; Fri,  2 Dec 2011 16:26:55 +0100 (CET)
Date: Fri, 2 Dec 2011 16:26:55 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Keir Fraser <keir.xen@gmail.com>
Message-ID: <20111202152655.GA28246@aepfle.de>
References: <4ED8A05A0200007800065020@nat28.tlf.novell.com>
	<CAFE1A94.26526%keir.xen@gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAFE1A94.26526%keir.xen@gmail.com>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] tools/libxc/xc_cpuid_x86.c:cpuid()'s inline asm
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Dec 02, Keir Fraser wrote:

> I think reg constraint failures had only been reported on 32-bit. So how
> about the attached patch?

+        : "0" (input[0]), "1" (count), "S" (_regs)

_regs is undeclared in 32bit, I think it should be regs.

Olaf

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

From xen-devel-bounces@lists.xensource.com Fri Dec 02 15:28:50 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 15:28:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWV2J-0002qX-2a; Fri, 02 Dec 2011 15:28:27 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RWV1w-0002on-FI
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 15:28:24 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-14.tower-21.messagelabs.com!1322839641!6736161!1
X-Originating-IP: [208.97.132.66]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi42NiA9PiAxNTExMA==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17589 invoked from network); 2 Dec 2011 15:27:22 -0000
Received: from caiajhbdcagg.dreamhost.com (HELO homiemail-a12.g.dreamhost.com)
	(208.97.132.66) by server-14.tower-21.messagelabs.com with SMTP;
	2 Dec 2011 15:27:22 -0000
Received: from homiemail-a12.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a12.g.dreamhost.com (Postfix) with ESMTP id F210E714070;
	Fri,  2 Dec 2011 07:27:20 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=bfouS7nJC5NQxaZsABjRK0/6bYk7NWzNNDRVUFQycQUv
	81o6D11pAfG5Dp2Va7YT1DLAE7YSYiNcM/3e5eC6M4xhxmgzwe2NRCkcJi3GMOik
	2gcXHO529wMo+yViKPx799T09Y4fTdBGip9QVKXu3PpfKN+7VmM//U94Vsjz5j4=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=5RIFKutmMMgaO1mz3InhmRNDA/0=; b=qlwWg3AT
	We63muowNjbnuhTwySlfxxLOD0W7FFjjFKx4ABruhyM7g4WstG4QdSR3QaSmaRqK
	f33+6uhigq1nSAGmBrIEOsbkdR3WedzhR3vNgGixKtDAhmZSWoNVd0178yBL2bGk
	8IOjSBRIulgRW/EOST2TTJa2YBxd0E935ms=
Received: from webmail.lagarcavilla.org (ahfbbjcaiaae.dreamhost.com
	[75.119.208.4]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a12.g.dreamhost.com (Postfix) with ESMTPA id 4E20F71406A; 
	Fri,  2 Dec 2011 07:27:20 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP; Fri, 2 Dec 2011 07:27:20 -0800
Message-ID: <8940966a49442039be1480307f59656b.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20111202013430.GB636@andromeda.dapyr.net>
References: <patchbomb.1322772713@xdev.gridcentric.ca>
	<1170bc32db41a7ae1e95.1322772715@xdev.gridcentric.ca>
	<20111202013430.GB636@andromeda.dapyr.net>
Date: Fri, 2 Dec 2011 07:27:20 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Konrad Rzeszutek Wilk" <konrad@darnok.org>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: olaf@aepfle.de, xen-devel@lists.xensource.com, mike.mcclurg@citrix.com,
	jonathan.ludlam@eu.citrix.com, jbeulich@suse.com, andres@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 2 of 2] xenpaging: handle GNTST_eagain in
 kernel drivers
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> On Thu, Dec 01, 2011 at 03:51:55PM -0500, Andres Lagar-Cavilla wrote:
>>  drivers/xen/blkback/blkback.c              |   6 ++-
>>  drivers/xen/blkback/interface.c            |   9 +++-
>>  drivers/xen/core/gnttab.c                  |   4 +-
>>  drivers/xen/gntdev/gntdev.c                |  49
>> +++++++++++++++++------------
>>  drivers/xen/netback/interface.c            |   5 +-
>>  drivers/xen/netback/netback.c              |  16 ++++++---
>>  drivers/xen/scsiback/interface.c           |  10 +++---
>>  drivers/xen/scsiback/scsiback.c            |   4 +-
>>  drivers/xen/tpmback/interface.c            |   7 +--
>>  drivers/xen/tpmback/tpmback.c              |  20 ++++-------
>>  drivers/xen/usbback/interface.c            |  16 ++++----
>>  drivers/xen/usbback/usbback.c              |   4 +-
>>  drivers/xen/xenbus/xenbus_backend_client.c |  10 +++---
>>  include/xen/gnttab.h                       |  37 ++++++++++++++++++++++
>>  14 files changed, 126 insertions(+), 71 deletions(-)
>>
>>
>> Handle GNTST_eagain status from GNTTABOP_map_grant_ref and
>> GNTTABOP_copy operations properly to allow usage of xenpaging without
>> causing crashes or data corruption.
>>
>> Replace all relevant HYPERVISOR_grant_table_op() calls with a retry
>> loop. This loop is implemented as a macro to allow different
>> GNTTABOP_* args. It will sleep up to 33 seconds and wait for the
>> page to be paged in again.
>>
>> All ->status checks were updated to use the GNTST_* namespace. All
>> return values are converted from GNTST_* namespace to 0/-EINVAL, since
>> all callers did not use the actual return value.
>
> Any plans to do this for the pvops tree?
Slowly but surely. Working with XCP presently, so pvops is not at the top
of my stack. Do you want to get at a specific merge window?

Andres
>
>>
>> Signed-off-by: Olaf Hering <olaf@aepfle.de>
>> Acked-by: Patrick Colp <pjcolp@cs.ubc.ca>
>>
>> This is a port from xenlinux 2.6.18 to the 2.6.32 xcp tree
>> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
>>
>> diff -r df9e25a0189b -r 1170bc32db41 drivers/xen/blkback/blkback.c
>> --- a/drivers/xen/blkback/blkback.c
>> +++ b/drivers/xen/blkback/blkback.c
>> @@ -701,11 +701,13 @@ static void dispatch_rw_block_io(blkif_t
>>  	BUG_ON(ret);
>>
>>  	for (i = 0; i < nseg; i++) {
>> -		if (unlikely(map[i].status != 0)) {
>> +		if (unlikely(map[i].status == GNTST_eagain))
>> +			gnttab_check_GNTST_eagain_do_while(GNTTABOP_map_grant_ref, &map[i]);
>> +		if (unlikely(map[i].status != GNTST_okay)) {
>>  			DPRINTK("grant map of dom %u gref %u failed: status %d\n",
>>  				blkif->domid, req->seg[i].gref, map[i].status);
>>  			map[i].handle = BLKBACK_INVALID_HANDLE;
>> -			ret |= 1;
>> +			ret = 1;
>>  			continue;
>>  		}
>>
>> diff -r df9e25a0189b -r 1170bc32db41 drivers/xen/blkback/interface.c
>> --- a/drivers/xen/blkback/interface.c
>> +++ b/drivers/xen/blkback/interface.c
>> @@ -95,7 +95,7 @@ static int map_frontend_pages(blkif_t *b
>>  	struct vm_struct *area = blkif->blk_ring_area;
>>  	struct gnttab_map_grant_ref op[BLKIF_MAX_RING_PAGES];
>>  	unsigned int i;
>> -	int status = 0;
>> +	int status = GNTST_okay;
>>
>>  	for (i = 0; i < nr_shared_pages; i++) {
>>  		unsigned long addr = (unsigned long)area->addr +
>> @@ -110,7 +110,10 @@ static int map_frontend_pages(blkif_t *b
>>  		BUG();
>>
>>  	for (i = 0; i < nr_shared_pages; i++) {
>> -		if ((status = op[i].status) != 0) {
>> +		if (op[i].status == GNTST_eagain)
>> +			gnttab_check_GNTST_eagain_do_while(GNTTABOP_map_grant_ref, &op[i]);
>> +		if (op[i].status != GNTST_okay) {
>> +			status = op[i].status;
>>  			blkif->shmem_handle[i] = INVALID_GRANT_HANDLE;
>>  			continue;
>>  		}
>> @@ -120,7 +123,7 @@ static int map_frontend_pages(blkif_t *b
>>
>>  	blkif->nr_shared_pages = nr_shared_pages;
>>
>> -	if (status != 0) {
>> +	if (status != GNTST_okay) {
>>  		DPRINTK(" Grant table operation failure !\n");
>>  		unmap_frontend_pages(blkif);
>>  	}
>> diff -r df9e25a0189b -r 1170bc32db41 drivers/xen/core/gnttab.c
>> --- a/drivers/xen/core/gnttab.c
>> +++ b/drivers/xen/core/gnttab.c
>> @@ -773,7 +773,7 @@ static int gnttab_map(unsigned int start
>>  		return -ENOSYS;
>>  	}
>>
>> -	BUG_ON(rc || setup.status);
>> +	BUG_ON(rc || (setup.status != GNTST_okay));
>>
>>  	if (shared.raw == NULL)
>>  		shared.raw = arch_gnttab_alloc_shared(gframes);
>> @@ -901,7 +901,7 @@ int gnttab_copy_grant_page(grant_ref_t r
>>  	err = HYPERVISOR_grant_table_op(GNTTABOP_unmap_and_replace,
>>  					&unmap, 1);
>>  	BUG_ON(err);
>> -	BUG_ON(unmap.status);
>> +	BUG_ON(unmap.status != GNTST_okay);
>>
>>  	write_sequnlock_irq(&gnttab_dma_lock);
>>
>> diff -r df9e25a0189b -r 1170bc32db41 drivers/xen/gntdev/gntdev.c
>> --- a/drivers/xen/gntdev/gntdev.c
>> +++ b/drivers/xen/gntdev/gntdev.c
>> @@ -503,7 +503,7 @@ static int gntdev_mmap (struct file *fli
>>  	uint64_t ptep;
>>  	int ret;
>>  	int flags;
>> -	int i;
>> +	int i, exit_ret;
>>  	struct page *page;
>>  	gntdev_file_private_data_t *private_data = flip->private_data;
>>
>> @@ -578,6 +578,7 @@ static int gntdev_mmap (struct file *fli
>>  	vma->vm_mm->context.has_foreign_mappings = 1;
>>  #endif
>>
>> +	exit_ret = -ENOMEM;
>>  	for (i = 0; i < size; ++i) {
>>
>>  		flags = GNTMAP_host_map;
>> @@ -598,14 +599,18 @@ static int gntdev_mmap (struct file *fli
>>  		ret = HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref,
>>  						&op, 1);
>>  		BUG_ON(ret);
>> -		if (op.status) {
>> -			printk(KERN_ERR "Error mapping the grant reference "
>> -			       "into the kernel (%d). domid = %d; ref = %d\n",
>> -			       op.status,
>> -			       private_data->grants[slot_index+i]
>> -			       .u.valid.domid,
>> -			       private_data->grants[slot_index+i]
>> -			       .u.valid.ref);
>> +		if (op.status != GNTST_okay) {
>> +			if (op.status != GNTST_eagain)
>> +				printk(KERN_ERR "Error mapping the grant reference "
>> +					   "into the kernel (%d). domid = %d; ref = %d\n",
>> +					   op.status,
>> +					   private_data->grants[slot_index+i]
>> +					   .u.valid.domid,
>> +					   private_data->grants[slot_index+i]
>> +					   .u.valid.ref);
>> +			else
>> +				/* Propagate instead of trying to fix it up */
>> +				exit_ret = -EAGAIN;
>>  			goto undo_map_out;
>>  		}
>>
>> @@ -674,14 +679,17 @@ static int gntdev_mmap (struct file *fli
>>  			ret = HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref,
>>  							&op, 1);
>>  			BUG_ON(ret);
>> -			if (op.status) {
>> +			if (op.status != GNTST_okay) {
>>  				printk(KERN_ERR "Error mapping the grant "
>> -				       "reference into user space (%d). domid "
>> -				       "= %d; ref = %d\n", op.status,
>> -				       private_data->grants[slot_index+i].u
>> -				       .valid.domid,
>> -				       private_data->grants[slot_index+i].u
>> -				       .valid.ref);
>> +					   "reference into user space (%d). domid "
>> +					   "= %d; ref = %d\n", op.status,
>> +					   private_data->grants[slot_index+i].u
>> +					   .valid.domid,
>> +					   private_data->grants[slot_index+i].u
>> +					   .valid.ref);
>> +				/* GNTST_eagain (i.e. page paged out) sohuld never happen
>> +				 * once we've mapped into kernel space */
>> +				BUG_ON(op.status == GNTST_eagain);
>>  				goto undo_map_out;
>>  			}
>>
>> @@ -705,9 +713,10 @@ static int gntdev_mmap (struct file *fli
>>  		}
>>
>>  	}
>> +	exit_ret = 0;
>>
>>  	up_write(&private_data->grants_sem);
>> -	return 0;
>> +	return exit_ret;
>>
>>  undo_map_out:
>>  	/* If we have a mapping failure, the unmapping will be taken care of
>> @@ -725,7 +734,7 @@ undo_map_out:
>>
>>  	up_write(&private_data->grants_sem);
>>
>> -	return -ENOMEM;
>> +	return exit_ret;
>>  }
>>
>>  static pte_t gntdev_clear_pte(struct vm_area_struct *vma, unsigned long
>> addr,
>> @@ -777,7 +786,7 @@ static pte_t gntdev_clear_pte(struct vm_
>>  			ret = HYPERVISOR_grant_table_op(
>>  				GNTTABOP_unmap_grant_ref, &op, 1);
>>  			BUG_ON(ret);
>> -			if (op.status)
>> +			if (op.status != GNTST_okay)
>>  				printk("User unmap grant status = %d\n",
>>  				       op.status);
>>  		} else {
>> @@ -794,7 +803,7 @@ static pte_t gntdev_clear_pte(struct vm_
>>  		ret = HYPERVISOR_grant_table_op(GNTTABOP_unmap_grant_ref,
>>  						&op, 1);
>>  		BUG_ON(ret);
>> -		if (op.status)
>> +		if (op.status != GNTST_okay)
>>  			printk("Kernel unmap grant status = %d\n", op.status);
>>
>>
>> diff -r df9e25a0189b -r 1170bc32db41 drivers/xen/netback/interface.c
>> --- a/drivers/xen/netback/interface.c
>> +++ b/drivers/xen/netback/interface.c
>> @@ -381,10 +381,9 @@ static int map_frontend_pages(struct xen
>>  	gnttab_set_map_op(&op, (unsigned long)comms->ring_area->addr,
>>  			  GNTMAP_host_map, ring_ref, domid);
>>
>> -	if (HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, &op, 1))
>> -		BUG();
>> +	gnttab_check_GNTST_eagain_do_while(GNTTABOP_map_grant_ref, &op);
>>
>> -	if (op.status) {
>> +	if (op.status != GNTST_okay) {
>>  		DPRINTK(" Gnttab failure mapping ring_ref!\n");
>>  		free_vm_area(comms->ring_area);
>>  		return op.status;
>> diff -r df9e25a0189b -r 1170bc32db41 drivers/xen/netback/netback.c
>> --- a/drivers/xen/netback/netback.c
>> +++ b/drivers/xen/netback/netback.c
>> @@ -419,11 +419,13 @@ static int netbk_check_gop(int nr_copy_s
>>
>>  	for (i = 0; i < nr_copy_slots; i++) {
>>  		copy_op = npo->copy + npo->copy_cons++;
>> +		if (copy_op->status == GNTST_eagain)
>> +			gnttab_check_GNTST_eagain_while(GNTTABOP_copy, copy_op);
>>  		if (copy_op->status != GNTST_okay) {
>> -				DPRINTK("Bad status %d from copy to DOM%d.\n",
>> -					copy_op->status, domid);
>> -				status = NETIF_RSP_ERROR;
>> -			}
>> +			DPRINTK("Bad status %d from copy to DOM%d.\n",
>> +				copy_op->status, domid);
>> +			status = NETIF_RSP_ERROR;
>> +		}
>>  	}
>>
>>  	return status;
>> @@ -1020,7 +1022,11 @@ static int netbk_tx_check_mop(struct xen
>>
>>  	/* Check status of header. */
>>  	err = mop->status;
>> -	if (unlikely(err)) {
>> +	if (err == GNTST_eagain) {
>> +		gnttab_check_GNTST_eagain_do_while(GNTTABOP_map_grant_ref, mop);
>> +		err = mop->status;
>> +	}
>> +	if (unlikely(err != GNTST_okay)) {
>>  		pending_ring_idx_t index;
>>  		index = pending_index(netbk->pending_prod++);
>>  		txp = &pending_tx_info[pending_idx].req;
>> diff -r df9e25a0189b -r 1170bc32db41 drivers/xen/scsiback/interface.c
>> --- a/drivers/xen/scsiback/interface.c
>> +++ b/drivers/xen/scsiback/interface.c
>> @@ -69,18 +69,18 @@ static int map_frontend_page( struct vsc
>>  				GNTMAP_host_map, ring_ref,
>>  				info->domid);
>>
>> -	err = HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, &op, 1);
>> -	BUG_ON(err);
>> +	gnttab_check_GNTST_eagain_do_while(GNTTABOP_map_grant_ref, &op);
>>
>> -	if (op.status) {
>> -		printk(KERN_ERR "scsiback: Grant table operation failure !\n");
>> +	if (op.status != GNTST_okay) {
>> +		printk(KERN_ERR "scsiback: Grant table operation failure %d!\n",
>> +							(int) op.status);
>>  		return op.status;
>>  	}
>>
>>  	info->shmem_ref    = ring_ref;
>>  	info->shmem_handle = op.handle;
>>
>> -	return (GNTST_okay);
>> +	return 0;
>>  }
>>
>>  static void unmap_frontend_page(struct vscsibk_info *info)
>> diff -r df9e25a0189b -r 1170bc32db41 drivers/xen/scsiback/scsiback.c
>> --- a/drivers/xen/scsiback/scsiback.c
>> +++ b/drivers/xen/scsiback/scsiback.c
>> @@ -287,7 +287,9 @@ static int scsiback_gnttab_data_map(vscs
>>  		for_each_sg (pending_req->sgl, sg, nr_segments, i) {
>>  			struct page *pg;
>>
>> -			if (unlikely(map[i].status != 0)) {
>> +			if (unlikely(map[i].status == GNTST_eagain))
>> +				gnttab_check_GNTST_eagain_while(GNTTABOP_map_grant_ref, &map[i]);
>> +			if (unlikely(map[i].status != GNTST_okay)) {
>>  				printk(KERN_ERR "scsiback: invalid buffer -- could not remap
>> it\n");
>>  				map[i].handle = SCSIBACK_INVALID_HANDLE;
>>  				err |= 1;
>> diff -r df9e25a0189b -r 1170bc32db41 drivers/xen/tpmback/interface.c
>> --- a/drivers/xen/tpmback/interface.c
>> +++ b/drivers/xen/tpmback/interface.c
>> @@ -86,11 +86,10 @@ static int map_frontend_page(tpmif_t *tp
>>  	gnttab_set_map_op(&op, (unsigned long)tpmif->tx_area->addr,
>>  			  GNTMAP_host_map, shared_page, tpmif->domid);
>>
>> -	if (HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, &op, 1))
>> -		BUG();
>> +	gnttab_check_GNTST_eagain_do_while(GNTTABOP_map_grant_ref, &op);
>>
>> -	if (op.status) {
>> -		DPRINTK(" Grant table operation failure !\n");
>> +	if (op.status != GNTST_okay) {
>> +		DPRINTK(" Grant table operation failure %d!\n", (int) op.status);
>>  		return op.status;
>>  	}
>>
>> diff -r df9e25a0189b -r 1170bc32db41 drivers/xen/tpmback/tpmback.c
>> --- a/drivers/xen/tpmback/tpmback.c
>> +++ b/drivers/xen/tpmback/tpmback.c
>> @@ -256,15 +256,13 @@ int _packet_write(struct packet *pak,
>>  		gnttab_set_map_op(&map_op, idx_to_kaddr(tpmif, i),
>>  				  GNTMAP_host_map, tx->ref, tpmif->domid);
>>
>> -		if (unlikely(HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref,
>> -						       &map_op, 1))) {
>> -			BUG();
>> -		}
>> +		gnttab_check_GNTST_eagain_do_while(GNTTABOP_map_grant_ref, &map_op);
>>
>>  		handle = map_op.handle;
>>
>> -		if (map_op.status) {
>> -			DPRINTK(" Grant table operation failure !\n");
>> +		if (map_op.status != GNTST_okay) {
>> +			DPRINTK(" Grant table operation failure %d!\n",
>> +						(int) map_op.status);
>>  			return 0;
>>  		}
>>
>> @@ -394,13 +392,11 @@ static int packet_read_shmem(struct pack
>>  		gnttab_set_map_op(&map_op, idx_to_kaddr(tpmif, i),
>>  				  GNTMAP_host_map, tx->ref, tpmif->domid);
>>
>> -		if (unlikely(HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref,
>> -						       &map_op, 1))) {
>> -			BUG();
>> -		}
>> +		gnttab_check_GNTST_eagain_do_while(GNTTABOP_map_grant_ref, &map_op);
>>
>> -		if (map_op.status) {
>> -			DPRINTK(" Grant table operation failure !\n");
>> +		if (map_op.status != GNTST_okay) {
>> +			DPRINTK(" Grant table operation failure %d!\n",
>> +						(int) map_op.status);
>>  			return -EFAULT;
>>  		}
>>
>> diff -r df9e25a0189b -r 1170bc32db41 drivers/xen/usbback/interface.c
>> --- a/drivers/xen/usbback/interface.c
>> +++ b/drivers/xen/usbback/interface.c
>> @@ -109,11 +109,11 @@ static int map_frontend_pages(usbif_t *u
>>  	gnttab_set_map_op(&op, (unsigned long)usbif->urb_ring_area->addr,
>>  			  GNTMAP_host_map, urb_ring_ref, usbif->domid);
>>
>> -	if (HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, &op, 1))
>> -		BUG();
>> +	gnttab_check_GNTST_eagain_do_while(GNTTABOP_map_grant_ref, &op);
>>
>> -	if (op.status) {
>> -		printk(KERN_ERR "grant table failure mapping urb_ring_ref\n");
>> +	if (op.status != GNTST_okay) {
>> +		printk(KERN_ERR "grant table failure mapping urb_ring_ref %d\n",
>> +							(int) op.status);
>>  		return op.status;
>>  	}
>>
>> @@ -123,17 +123,17 @@ static int map_frontend_pages(usbif_t *u
>>  	gnttab_set_map_op(&op, (unsigned long)usbif->conn_ring_area->addr,
>>  			  GNTMAP_host_map, conn_ring_ref, usbif->domid);
>>
>> -	if (HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, &op, 1))
>> -		BUG();
>> +	gnttab_check_GNTST_eagain_do_while(GNTTABOP_map_grant_ref, &op);
>>
>> -	if (op.status) {
>> +	if (op.status != GNTST_okay) {
>>  		struct gnttab_unmap_grant_ref unop;
>>  		gnttab_set_unmap_op(&unop,
>>  				(unsigned long) usbif->urb_ring_area->addr,
>>  				GNTMAP_host_map, usbif->urb_shmem_handle);
>>  		VOID(HYPERVISOR_grant_table_op(GNTTABOP_unmap_grant_ref, &unop,
>>  				1));
>> -		printk(KERN_ERR "grant table failure mapping conn_ring_ref\n");
>> +		printk(KERN_ERR "grant table failure mapping conn_ring_ref %d\n",
>> +							(int) op.status);
>>  		return op.status;
>>  	}
>>
>> diff -r df9e25a0189b -r 1170bc32db41 drivers/xen/usbback/usbback.c
>> --- a/drivers/xen/usbback/usbback.c
>> +++ b/drivers/xen/usbback/usbback.c
>> @@ -428,7 +428,9 @@ static int usbbk_gnttab_map(usbif_t *usb
>>  		BUG_ON(ret);
>>
>>  		for (i = 0; i < nr_segs; i++) {
>> -			if (unlikely(map[i].status != 0)) {
>> +			if (unlikely(map[i].status == GNTST_eagain))
>> +				gnttab_check_GNTST_eagain_while(GNTTABOP_map_grant_ref, &map[i]);
>> +			if (unlikely(map[i].status != GNTST_okay)) {
>>  				printk(KERN_ERR "usbback: invalid buffer -- could not remap it\n");
>>  				map[i].handle = USBBACK_INVALID_HANDLE;
>>  				ret |= 1;
>> diff -r df9e25a0189b -r 1170bc32db41
>> drivers/xen/xenbus/xenbus_backend_client.c
>> --- a/drivers/xen/xenbus/xenbus_backend_client.c
>> +++ b/drivers/xen/xenbus/xenbus_backend_client.c
>> @@ -48,8 +48,7 @@ struct vm_struct *xenbus_map_ring_valloc
>>  	gnttab_set_map_op(&op, (unsigned long)area->addr, GNTMAP_host_map,
>>  			  gnt_ref, dev->otherend_id);
>>
>> -	if (HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, &op, 1))
>> -		BUG();
>> +	gnttab_check_GNTST_eagain_do_while(GNTTABOP_map_grant_ref, &op);
>>
>>  	if (op.status != GNTST_okay) {
>>  		free_vm_area(area);
>> @@ -75,15 +74,16 @@ int xenbus_map_ring(struct xenbus_device
>>
>>  	gnttab_set_map_op(&op, (unsigned long)vaddr, GNTMAP_host_map,
>>  			  gnt_ref, dev->otherend_id);
>> -	if (HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, &op, 1))
>> -		BUG();
>> +	gnttab_check_GNTST_eagain_do_while(GNTTABOP_map_grant_ref, &op);
>>
>>  	if (op.status != GNTST_okay) {
>>  		xenbus_dev_fatal(dev, op.status,
>>  				 "mapping in shared page %d from domain %d",
>>  				 gnt_ref, dev->otherend_id);
>> -	} else
>> +	} else {
>>  		*handle = op.handle;
>> +		return 0;
>> +	}
>>
>>  	return op.status;
>>  }
>> diff -r df9e25a0189b -r 1170bc32db41 include/xen/gnttab.h
>> --- a/include/xen/gnttab.h
>> +++ b/include/xen/gnttab.h
>> @@ -187,4 +187,41 @@ gnttab_set_replace_op(struct gnttab_unma
>>  	unmap->handle = handle;
>>  }
>>
>> +#define gnttab_check_GNTST_eagain_while(__HCop, __HCarg_p)					\
>> +do {																		\
>> +	u8 __hc_delay = 1;														\
>> +	int __ret;																\
>> +	while (unlikely((__HCarg_p)->status == GNTST_eagain && __hc_delay))
>> {	\
>> +		msleep(__hc_delay++);												\
>> +		__ret = HYPERVISOR_grant_table_op(__HCop, (__HCarg_p), 1);			\
>> +		BUG_ON(__ret);														\
>> +	}																		\
>> +	if (__hc_delay == 0) {													\
>> +		printk(KERN_ERR "%s: %s gnt busy\n", __func__, current->comm);		\
>> +		(__HCarg_p)->status = GNTST_bad_page;								\
>> +	}																		\
>> +	if ((__HCarg_p)->status != GNTST_okay)									\
>> +		printk(KERN_ERR "%s: %s gnt status %x\n", 							\
>> +			__func__, current->comm, (__HCarg_p)->status);					\
>> +} while(0)
>> +
>> +#define gnttab_check_GNTST_eagain_do_while(__HCop, __HCarg_p)			\
>> +do {																	\
>> +	u8 __hc_delay = 1;													\
>> +	int __ret;															\
>> +	do {																\
>> +		__ret = HYPERVISOR_grant_table_op(__HCop, (__HCarg_p), 1);		\
>> +		BUG_ON(__ret);													\
>> +		if ((__HCarg_p)->status == GNTST_eagain)						\
>> +			msleep(__hc_delay++);										\
>> +	} while ((__HCarg_p)->status == GNTST_eagain && __hc_delay);		\
>> +	if (__hc_delay == 0) {												\
>> +		printk(KERN_ERR "%s: %s gnt busy\n", __func__, current->comm);	\
>> +		(__HCarg_p)->status = GNTST_bad_page;							\
>> +	}																	\
>> +	if ((__HCarg_p)->status != GNTST_okay)								\
>> +		printk(KERN_ERR "%s: %s gnt status %x\n", 						\
>> +			__func__, current->comm, (__HCarg_p)->status);				\
>> +} while(0)
>> +
>>  #endif /* __ASM_GNTTAB_H__ */
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel
>



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

From xen-devel-bounces@lists.xensource.com Fri Dec 02 15:28:50 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 15:28:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWV2J-0002qX-2a; Fri, 02 Dec 2011 15:28:27 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RWV1w-0002on-FI
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 15:28:24 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-14.tower-21.messagelabs.com!1322839641!6736161!1
X-Originating-IP: [208.97.132.66]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi42NiA9PiAxNTExMA==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17589 invoked from network); 2 Dec 2011 15:27:22 -0000
Received: from caiajhbdcagg.dreamhost.com (HELO homiemail-a12.g.dreamhost.com)
	(208.97.132.66) by server-14.tower-21.messagelabs.com with SMTP;
	2 Dec 2011 15:27:22 -0000
Received: from homiemail-a12.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a12.g.dreamhost.com (Postfix) with ESMTP id F210E714070;
	Fri,  2 Dec 2011 07:27:20 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=bfouS7nJC5NQxaZsABjRK0/6bYk7NWzNNDRVUFQycQUv
	81o6D11pAfG5Dp2Va7YT1DLAE7YSYiNcM/3e5eC6M4xhxmgzwe2NRCkcJi3GMOik
	2gcXHO529wMo+yViKPx799T09Y4fTdBGip9QVKXu3PpfKN+7VmM//U94Vsjz5j4=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=5RIFKutmMMgaO1mz3InhmRNDA/0=; b=qlwWg3AT
	We63muowNjbnuhTwySlfxxLOD0W7FFjjFKx4ABruhyM7g4WstG4QdSR3QaSmaRqK
	f33+6uhigq1nSAGmBrIEOsbkdR3WedzhR3vNgGixKtDAhmZSWoNVd0178yBL2bGk
	8IOjSBRIulgRW/EOST2TTJa2YBxd0E935ms=
Received: from webmail.lagarcavilla.org (ahfbbjcaiaae.dreamhost.com
	[75.119.208.4]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a12.g.dreamhost.com (Postfix) with ESMTPA id 4E20F71406A; 
	Fri,  2 Dec 2011 07:27:20 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP; Fri, 2 Dec 2011 07:27:20 -0800
Message-ID: <8940966a49442039be1480307f59656b.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20111202013430.GB636@andromeda.dapyr.net>
References: <patchbomb.1322772713@xdev.gridcentric.ca>
	<1170bc32db41a7ae1e95.1322772715@xdev.gridcentric.ca>
	<20111202013430.GB636@andromeda.dapyr.net>
Date: Fri, 2 Dec 2011 07:27:20 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Konrad Rzeszutek Wilk" <konrad@darnok.org>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: olaf@aepfle.de, xen-devel@lists.xensource.com, mike.mcclurg@citrix.com,
	jonathan.ludlam@eu.citrix.com, jbeulich@suse.com, andres@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 2 of 2] xenpaging: handle GNTST_eagain in
 kernel drivers
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> On Thu, Dec 01, 2011 at 03:51:55PM -0500, Andres Lagar-Cavilla wrote:
>>  drivers/xen/blkback/blkback.c              |   6 ++-
>>  drivers/xen/blkback/interface.c            |   9 +++-
>>  drivers/xen/core/gnttab.c                  |   4 +-
>>  drivers/xen/gntdev/gntdev.c                |  49
>> +++++++++++++++++------------
>>  drivers/xen/netback/interface.c            |   5 +-
>>  drivers/xen/netback/netback.c              |  16 ++++++---
>>  drivers/xen/scsiback/interface.c           |  10 +++---
>>  drivers/xen/scsiback/scsiback.c            |   4 +-
>>  drivers/xen/tpmback/interface.c            |   7 +--
>>  drivers/xen/tpmback/tpmback.c              |  20 ++++-------
>>  drivers/xen/usbback/interface.c            |  16 ++++----
>>  drivers/xen/usbback/usbback.c              |   4 +-
>>  drivers/xen/xenbus/xenbus_backend_client.c |  10 +++---
>>  include/xen/gnttab.h                       |  37 ++++++++++++++++++++++
>>  14 files changed, 126 insertions(+), 71 deletions(-)
>>
>>
>> Handle GNTST_eagain status from GNTTABOP_map_grant_ref and
>> GNTTABOP_copy operations properly to allow usage of xenpaging without
>> causing crashes or data corruption.
>>
>> Replace all relevant HYPERVISOR_grant_table_op() calls with a retry
>> loop. This loop is implemented as a macro to allow different
>> GNTTABOP_* args. It will sleep up to 33 seconds and wait for the
>> page to be paged in again.
>>
>> All ->status checks were updated to use the GNTST_* namespace. All
>> return values are converted from GNTST_* namespace to 0/-EINVAL, since
>> all callers did not use the actual return value.
>
> Any plans to do this for the pvops tree?
Slowly but surely. Working with XCP presently, so pvops is not at the top
of my stack. Do you want to get at a specific merge window?

Andres
>
>>
>> Signed-off-by: Olaf Hering <olaf@aepfle.de>
>> Acked-by: Patrick Colp <pjcolp@cs.ubc.ca>
>>
>> This is a port from xenlinux 2.6.18 to the 2.6.32 xcp tree
>> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
>>
>> diff -r df9e25a0189b -r 1170bc32db41 drivers/xen/blkback/blkback.c
>> --- a/drivers/xen/blkback/blkback.c
>> +++ b/drivers/xen/blkback/blkback.c
>> @@ -701,11 +701,13 @@ static void dispatch_rw_block_io(blkif_t
>>  	BUG_ON(ret);
>>
>>  	for (i = 0; i < nseg; i++) {
>> -		if (unlikely(map[i].status != 0)) {
>> +		if (unlikely(map[i].status == GNTST_eagain))
>> +			gnttab_check_GNTST_eagain_do_while(GNTTABOP_map_grant_ref, &map[i]);
>> +		if (unlikely(map[i].status != GNTST_okay)) {
>>  			DPRINTK("grant map of dom %u gref %u failed: status %d\n",
>>  				blkif->domid, req->seg[i].gref, map[i].status);
>>  			map[i].handle = BLKBACK_INVALID_HANDLE;
>> -			ret |= 1;
>> +			ret = 1;
>>  			continue;
>>  		}
>>
>> diff -r df9e25a0189b -r 1170bc32db41 drivers/xen/blkback/interface.c
>> --- a/drivers/xen/blkback/interface.c
>> +++ b/drivers/xen/blkback/interface.c
>> @@ -95,7 +95,7 @@ static int map_frontend_pages(blkif_t *b
>>  	struct vm_struct *area = blkif->blk_ring_area;
>>  	struct gnttab_map_grant_ref op[BLKIF_MAX_RING_PAGES];
>>  	unsigned int i;
>> -	int status = 0;
>> +	int status = GNTST_okay;
>>
>>  	for (i = 0; i < nr_shared_pages; i++) {
>>  		unsigned long addr = (unsigned long)area->addr +
>> @@ -110,7 +110,10 @@ static int map_frontend_pages(blkif_t *b
>>  		BUG();
>>
>>  	for (i = 0; i < nr_shared_pages; i++) {
>> -		if ((status = op[i].status) != 0) {
>> +		if (op[i].status == GNTST_eagain)
>> +			gnttab_check_GNTST_eagain_do_while(GNTTABOP_map_grant_ref, &op[i]);
>> +		if (op[i].status != GNTST_okay) {
>> +			status = op[i].status;
>>  			blkif->shmem_handle[i] = INVALID_GRANT_HANDLE;
>>  			continue;
>>  		}
>> @@ -120,7 +123,7 @@ static int map_frontend_pages(blkif_t *b
>>
>>  	blkif->nr_shared_pages = nr_shared_pages;
>>
>> -	if (status != 0) {
>> +	if (status != GNTST_okay) {
>>  		DPRINTK(" Grant table operation failure !\n");
>>  		unmap_frontend_pages(blkif);
>>  	}
>> diff -r df9e25a0189b -r 1170bc32db41 drivers/xen/core/gnttab.c
>> --- a/drivers/xen/core/gnttab.c
>> +++ b/drivers/xen/core/gnttab.c
>> @@ -773,7 +773,7 @@ static int gnttab_map(unsigned int start
>>  		return -ENOSYS;
>>  	}
>>
>> -	BUG_ON(rc || setup.status);
>> +	BUG_ON(rc || (setup.status != GNTST_okay));
>>
>>  	if (shared.raw == NULL)
>>  		shared.raw = arch_gnttab_alloc_shared(gframes);
>> @@ -901,7 +901,7 @@ int gnttab_copy_grant_page(grant_ref_t r
>>  	err = HYPERVISOR_grant_table_op(GNTTABOP_unmap_and_replace,
>>  					&unmap, 1);
>>  	BUG_ON(err);
>> -	BUG_ON(unmap.status);
>> +	BUG_ON(unmap.status != GNTST_okay);
>>
>>  	write_sequnlock_irq(&gnttab_dma_lock);
>>
>> diff -r df9e25a0189b -r 1170bc32db41 drivers/xen/gntdev/gntdev.c
>> --- a/drivers/xen/gntdev/gntdev.c
>> +++ b/drivers/xen/gntdev/gntdev.c
>> @@ -503,7 +503,7 @@ static int gntdev_mmap (struct file *fli
>>  	uint64_t ptep;
>>  	int ret;
>>  	int flags;
>> -	int i;
>> +	int i, exit_ret;
>>  	struct page *page;
>>  	gntdev_file_private_data_t *private_data = flip->private_data;
>>
>> @@ -578,6 +578,7 @@ static int gntdev_mmap (struct file *fli
>>  	vma->vm_mm->context.has_foreign_mappings = 1;
>>  #endif
>>
>> +	exit_ret = -ENOMEM;
>>  	for (i = 0; i < size; ++i) {
>>
>>  		flags = GNTMAP_host_map;
>> @@ -598,14 +599,18 @@ static int gntdev_mmap (struct file *fli
>>  		ret = HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref,
>>  						&op, 1);
>>  		BUG_ON(ret);
>> -		if (op.status) {
>> -			printk(KERN_ERR "Error mapping the grant reference "
>> -			       "into the kernel (%d). domid = %d; ref = %d\n",
>> -			       op.status,
>> -			       private_data->grants[slot_index+i]
>> -			       .u.valid.domid,
>> -			       private_data->grants[slot_index+i]
>> -			       .u.valid.ref);
>> +		if (op.status != GNTST_okay) {
>> +			if (op.status != GNTST_eagain)
>> +				printk(KERN_ERR "Error mapping the grant reference "
>> +					   "into the kernel (%d). domid = %d; ref = %d\n",
>> +					   op.status,
>> +					   private_data->grants[slot_index+i]
>> +					   .u.valid.domid,
>> +					   private_data->grants[slot_index+i]
>> +					   .u.valid.ref);
>> +			else
>> +				/* Propagate instead of trying to fix it up */
>> +				exit_ret = -EAGAIN;
>>  			goto undo_map_out;
>>  		}
>>
>> @@ -674,14 +679,17 @@ static int gntdev_mmap (struct file *fli
>>  			ret = HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref,
>>  							&op, 1);
>>  			BUG_ON(ret);
>> -			if (op.status) {
>> +			if (op.status != GNTST_okay) {
>>  				printk(KERN_ERR "Error mapping the grant "
>> -				       "reference into user space (%d). domid "
>> -				       "= %d; ref = %d\n", op.status,
>> -				       private_data->grants[slot_index+i].u
>> -				       .valid.domid,
>> -				       private_data->grants[slot_index+i].u
>> -				       .valid.ref);
>> +					   "reference into user space (%d). domid "
>> +					   "= %d; ref = %d\n", op.status,
>> +					   private_data->grants[slot_index+i].u
>> +					   .valid.domid,
>> +					   private_data->grants[slot_index+i].u
>> +					   .valid.ref);
>> +				/* GNTST_eagain (i.e. page paged out) sohuld never happen
>> +				 * once we've mapped into kernel space */
>> +				BUG_ON(op.status == GNTST_eagain);
>>  				goto undo_map_out;
>>  			}
>>
>> @@ -705,9 +713,10 @@ static int gntdev_mmap (struct file *fli
>>  		}
>>
>>  	}
>> +	exit_ret = 0;
>>
>>  	up_write(&private_data->grants_sem);
>> -	return 0;
>> +	return exit_ret;
>>
>>  undo_map_out:
>>  	/* If we have a mapping failure, the unmapping will be taken care of
>> @@ -725,7 +734,7 @@ undo_map_out:
>>
>>  	up_write(&private_data->grants_sem);
>>
>> -	return -ENOMEM;
>> +	return exit_ret;
>>  }
>>
>>  static pte_t gntdev_clear_pte(struct vm_area_struct *vma, unsigned long
>> addr,
>> @@ -777,7 +786,7 @@ static pte_t gntdev_clear_pte(struct vm_
>>  			ret = HYPERVISOR_grant_table_op(
>>  				GNTTABOP_unmap_grant_ref, &op, 1);
>>  			BUG_ON(ret);
>> -			if (op.status)
>> +			if (op.status != GNTST_okay)
>>  				printk("User unmap grant status = %d\n",
>>  				       op.status);
>>  		} else {
>> @@ -794,7 +803,7 @@ static pte_t gntdev_clear_pte(struct vm_
>>  		ret = HYPERVISOR_grant_table_op(GNTTABOP_unmap_grant_ref,
>>  						&op, 1);
>>  		BUG_ON(ret);
>> -		if (op.status)
>> +		if (op.status != GNTST_okay)
>>  			printk("Kernel unmap grant status = %d\n", op.status);
>>
>>
>> diff -r df9e25a0189b -r 1170bc32db41 drivers/xen/netback/interface.c
>> --- a/drivers/xen/netback/interface.c
>> +++ b/drivers/xen/netback/interface.c
>> @@ -381,10 +381,9 @@ static int map_frontend_pages(struct xen
>>  	gnttab_set_map_op(&op, (unsigned long)comms->ring_area->addr,
>>  			  GNTMAP_host_map, ring_ref, domid);
>>
>> -	if (HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, &op, 1))
>> -		BUG();
>> +	gnttab_check_GNTST_eagain_do_while(GNTTABOP_map_grant_ref, &op);
>>
>> -	if (op.status) {
>> +	if (op.status != GNTST_okay) {
>>  		DPRINTK(" Gnttab failure mapping ring_ref!\n");
>>  		free_vm_area(comms->ring_area);
>>  		return op.status;
>> diff -r df9e25a0189b -r 1170bc32db41 drivers/xen/netback/netback.c
>> --- a/drivers/xen/netback/netback.c
>> +++ b/drivers/xen/netback/netback.c
>> @@ -419,11 +419,13 @@ static int netbk_check_gop(int nr_copy_s
>>
>>  	for (i = 0; i < nr_copy_slots; i++) {
>>  		copy_op = npo->copy + npo->copy_cons++;
>> +		if (copy_op->status == GNTST_eagain)
>> +			gnttab_check_GNTST_eagain_while(GNTTABOP_copy, copy_op);
>>  		if (copy_op->status != GNTST_okay) {
>> -				DPRINTK("Bad status %d from copy to DOM%d.\n",
>> -					copy_op->status, domid);
>> -				status = NETIF_RSP_ERROR;
>> -			}
>> +			DPRINTK("Bad status %d from copy to DOM%d.\n",
>> +				copy_op->status, domid);
>> +			status = NETIF_RSP_ERROR;
>> +		}
>>  	}
>>
>>  	return status;
>> @@ -1020,7 +1022,11 @@ static int netbk_tx_check_mop(struct xen
>>
>>  	/* Check status of header. */
>>  	err = mop->status;
>> -	if (unlikely(err)) {
>> +	if (err == GNTST_eagain) {
>> +		gnttab_check_GNTST_eagain_do_while(GNTTABOP_map_grant_ref, mop);
>> +		err = mop->status;
>> +	}
>> +	if (unlikely(err != GNTST_okay)) {
>>  		pending_ring_idx_t index;
>>  		index = pending_index(netbk->pending_prod++);
>>  		txp = &pending_tx_info[pending_idx].req;
>> diff -r df9e25a0189b -r 1170bc32db41 drivers/xen/scsiback/interface.c
>> --- a/drivers/xen/scsiback/interface.c
>> +++ b/drivers/xen/scsiback/interface.c
>> @@ -69,18 +69,18 @@ static int map_frontend_page( struct vsc
>>  				GNTMAP_host_map, ring_ref,
>>  				info->domid);
>>
>> -	err = HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, &op, 1);
>> -	BUG_ON(err);
>> +	gnttab_check_GNTST_eagain_do_while(GNTTABOP_map_grant_ref, &op);
>>
>> -	if (op.status) {
>> -		printk(KERN_ERR "scsiback: Grant table operation failure !\n");
>> +	if (op.status != GNTST_okay) {
>> +		printk(KERN_ERR "scsiback: Grant table operation failure %d!\n",
>> +							(int) op.status);
>>  		return op.status;
>>  	}
>>
>>  	info->shmem_ref    = ring_ref;
>>  	info->shmem_handle = op.handle;
>>
>> -	return (GNTST_okay);
>> +	return 0;
>>  }
>>
>>  static void unmap_frontend_page(struct vscsibk_info *info)
>> diff -r df9e25a0189b -r 1170bc32db41 drivers/xen/scsiback/scsiback.c
>> --- a/drivers/xen/scsiback/scsiback.c
>> +++ b/drivers/xen/scsiback/scsiback.c
>> @@ -287,7 +287,9 @@ static int scsiback_gnttab_data_map(vscs
>>  		for_each_sg (pending_req->sgl, sg, nr_segments, i) {
>>  			struct page *pg;
>>
>> -			if (unlikely(map[i].status != 0)) {
>> +			if (unlikely(map[i].status == GNTST_eagain))
>> +				gnttab_check_GNTST_eagain_while(GNTTABOP_map_grant_ref, &map[i]);
>> +			if (unlikely(map[i].status != GNTST_okay)) {
>>  				printk(KERN_ERR "scsiback: invalid buffer -- could not remap
>> it\n");
>>  				map[i].handle = SCSIBACK_INVALID_HANDLE;
>>  				err |= 1;
>> diff -r df9e25a0189b -r 1170bc32db41 drivers/xen/tpmback/interface.c
>> --- a/drivers/xen/tpmback/interface.c
>> +++ b/drivers/xen/tpmback/interface.c
>> @@ -86,11 +86,10 @@ static int map_frontend_page(tpmif_t *tp
>>  	gnttab_set_map_op(&op, (unsigned long)tpmif->tx_area->addr,
>>  			  GNTMAP_host_map, shared_page, tpmif->domid);
>>
>> -	if (HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, &op, 1))
>> -		BUG();
>> +	gnttab_check_GNTST_eagain_do_while(GNTTABOP_map_grant_ref, &op);
>>
>> -	if (op.status) {
>> -		DPRINTK(" Grant table operation failure !\n");
>> +	if (op.status != GNTST_okay) {
>> +		DPRINTK(" Grant table operation failure %d!\n", (int) op.status);
>>  		return op.status;
>>  	}
>>
>> diff -r df9e25a0189b -r 1170bc32db41 drivers/xen/tpmback/tpmback.c
>> --- a/drivers/xen/tpmback/tpmback.c
>> +++ b/drivers/xen/tpmback/tpmback.c
>> @@ -256,15 +256,13 @@ int _packet_write(struct packet *pak,
>>  		gnttab_set_map_op(&map_op, idx_to_kaddr(tpmif, i),
>>  				  GNTMAP_host_map, tx->ref, tpmif->domid);
>>
>> -		if (unlikely(HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref,
>> -						       &map_op, 1))) {
>> -			BUG();
>> -		}
>> +		gnttab_check_GNTST_eagain_do_while(GNTTABOP_map_grant_ref, &map_op);
>>
>>  		handle = map_op.handle;
>>
>> -		if (map_op.status) {
>> -			DPRINTK(" Grant table operation failure !\n");
>> +		if (map_op.status != GNTST_okay) {
>> +			DPRINTK(" Grant table operation failure %d!\n",
>> +						(int) map_op.status);
>>  			return 0;
>>  		}
>>
>> @@ -394,13 +392,11 @@ static int packet_read_shmem(struct pack
>>  		gnttab_set_map_op(&map_op, idx_to_kaddr(tpmif, i),
>>  				  GNTMAP_host_map, tx->ref, tpmif->domid);
>>
>> -		if (unlikely(HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref,
>> -						       &map_op, 1))) {
>> -			BUG();
>> -		}
>> +		gnttab_check_GNTST_eagain_do_while(GNTTABOP_map_grant_ref, &map_op);
>>
>> -		if (map_op.status) {
>> -			DPRINTK(" Grant table operation failure !\n");
>> +		if (map_op.status != GNTST_okay) {
>> +			DPRINTK(" Grant table operation failure %d!\n",
>> +						(int) map_op.status);
>>  			return -EFAULT;
>>  		}
>>
>> diff -r df9e25a0189b -r 1170bc32db41 drivers/xen/usbback/interface.c
>> --- a/drivers/xen/usbback/interface.c
>> +++ b/drivers/xen/usbback/interface.c
>> @@ -109,11 +109,11 @@ static int map_frontend_pages(usbif_t *u
>>  	gnttab_set_map_op(&op, (unsigned long)usbif->urb_ring_area->addr,
>>  			  GNTMAP_host_map, urb_ring_ref, usbif->domid);
>>
>> -	if (HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, &op, 1))
>> -		BUG();
>> +	gnttab_check_GNTST_eagain_do_while(GNTTABOP_map_grant_ref, &op);
>>
>> -	if (op.status) {
>> -		printk(KERN_ERR "grant table failure mapping urb_ring_ref\n");
>> +	if (op.status != GNTST_okay) {
>> +		printk(KERN_ERR "grant table failure mapping urb_ring_ref %d\n",
>> +							(int) op.status);
>>  		return op.status;
>>  	}
>>
>> @@ -123,17 +123,17 @@ static int map_frontend_pages(usbif_t *u
>>  	gnttab_set_map_op(&op, (unsigned long)usbif->conn_ring_area->addr,
>>  			  GNTMAP_host_map, conn_ring_ref, usbif->domid);
>>
>> -	if (HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, &op, 1))
>> -		BUG();
>> +	gnttab_check_GNTST_eagain_do_while(GNTTABOP_map_grant_ref, &op);
>>
>> -	if (op.status) {
>> +	if (op.status != GNTST_okay) {
>>  		struct gnttab_unmap_grant_ref unop;
>>  		gnttab_set_unmap_op(&unop,
>>  				(unsigned long) usbif->urb_ring_area->addr,
>>  				GNTMAP_host_map, usbif->urb_shmem_handle);
>>  		VOID(HYPERVISOR_grant_table_op(GNTTABOP_unmap_grant_ref, &unop,
>>  				1));
>> -		printk(KERN_ERR "grant table failure mapping conn_ring_ref\n");
>> +		printk(KERN_ERR "grant table failure mapping conn_ring_ref %d\n",
>> +							(int) op.status);
>>  		return op.status;
>>  	}
>>
>> diff -r df9e25a0189b -r 1170bc32db41 drivers/xen/usbback/usbback.c
>> --- a/drivers/xen/usbback/usbback.c
>> +++ b/drivers/xen/usbback/usbback.c
>> @@ -428,7 +428,9 @@ static int usbbk_gnttab_map(usbif_t *usb
>>  		BUG_ON(ret);
>>
>>  		for (i = 0; i < nr_segs; i++) {
>> -			if (unlikely(map[i].status != 0)) {
>> +			if (unlikely(map[i].status == GNTST_eagain))
>> +				gnttab_check_GNTST_eagain_while(GNTTABOP_map_grant_ref, &map[i]);
>> +			if (unlikely(map[i].status != GNTST_okay)) {
>>  				printk(KERN_ERR "usbback: invalid buffer -- could not remap it\n");
>>  				map[i].handle = USBBACK_INVALID_HANDLE;
>>  				ret |= 1;
>> diff -r df9e25a0189b -r 1170bc32db41
>> drivers/xen/xenbus/xenbus_backend_client.c
>> --- a/drivers/xen/xenbus/xenbus_backend_client.c
>> +++ b/drivers/xen/xenbus/xenbus_backend_client.c
>> @@ -48,8 +48,7 @@ struct vm_struct *xenbus_map_ring_valloc
>>  	gnttab_set_map_op(&op, (unsigned long)area->addr, GNTMAP_host_map,
>>  			  gnt_ref, dev->otherend_id);
>>
>> -	if (HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, &op, 1))
>> -		BUG();
>> +	gnttab_check_GNTST_eagain_do_while(GNTTABOP_map_grant_ref, &op);
>>
>>  	if (op.status != GNTST_okay) {
>>  		free_vm_area(area);
>> @@ -75,15 +74,16 @@ int xenbus_map_ring(struct xenbus_device
>>
>>  	gnttab_set_map_op(&op, (unsigned long)vaddr, GNTMAP_host_map,
>>  			  gnt_ref, dev->otherend_id);
>> -	if (HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, &op, 1))
>> -		BUG();
>> +	gnttab_check_GNTST_eagain_do_while(GNTTABOP_map_grant_ref, &op);
>>
>>  	if (op.status != GNTST_okay) {
>>  		xenbus_dev_fatal(dev, op.status,
>>  				 "mapping in shared page %d from domain %d",
>>  				 gnt_ref, dev->otherend_id);
>> -	} else
>> +	} else {
>>  		*handle = op.handle;
>> +		return 0;
>> +	}
>>
>>  	return op.status;
>>  }
>> diff -r df9e25a0189b -r 1170bc32db41 include/xen/gnttab.h
>> --- a/include/xen/gnttab.h
>> +++ b/include/xen/gnttab.h
>> @@ -187,4 +187,41 @@ gnttab_set_replace_op(struct gnttab_unma
>>  	unmap->handle = handle;
>>  }
>>
>> +#define gnttab_check_GNTST_eagain_while(__HCop, __HCarg_p)					\
>> +do {																		\
>> +	u8 __hc_delay = 1;														\
>> +	int __ret;																\
>> +	while (unlikely((__HCarg_p)->status == GNTST_eagain && __hc_delay))
>> {	\
>> +		msleep(__hc_delay++);												\
>> +		__ret = HYPERVISOR_grant_table_op(__HCop, (__HCarg_p), 1);			\
>> +		BUG_ON(__ret);														\
>> +	}																		\
>> +	if (__hc_delay == 0) {													\
>> +		printk(KERN_ERR "%s: %s gnt busy\n", __func__, current->comm);		\
>> +		(__HCarg_p)->status = GNTST_bad_page;								\
>> +	}																		\
>> +	if ((__HCarg_p)->status != GNTST_okay)									\
>> +		printk(KERN_ERR "%s: %s gnt status %x\n", 							\
>> +			__func__, current->comm, (__HCarg_p)->status);					\
>> +} while(0)
>> +
>> +#define gnttab_check_GNTST_eagain_do_while(__HCop, __HCarg_p)			\
>> +do {																	\
>> +	u8 __hc_delay = 1;													\
>> +	int __ret;															\
>> +	do {																\
>> +		__ret = HYPERVISOR_grant_table_op(__HCop, (__HCarg_p), 1);		\
>> +		BUG_ON(__ret);													\
>> +		if ((__HCarg_p)->status == GNTST_eagain)						\
>> +			msleep(__hc_delay++);										\
>> +	} while ((__HCarg_p)->status == GNTST_eagain && __hc_delay);		\
>> +	if (__hc_delay == 0) {												\
>> +		printk(KERN_ERR "%s: %s gnt busy\n", __func__, current->comm);	\
>> +		(__HCarg_p)->status = GNTST_bad_page;							\
>> +	}																	\
>> +	if ((__HCarg_p)->status != GNTST_okay)								\
>> +		printk(KERN_ERR "%s: %s gnt status %x\n", 						\
>> +			__func__, current->comm, (__HCarg_p)->status);				\
>> +} while(0)
>> +
>>  #endif /* __ASM_GNTTAB_H__ */
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel
>



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

From xen-devel-bounces@lists.xensource.com Fri Dec 02 15:30:39 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 15:30:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWV4C-00034c-TT; Fri, 02 Dec 2011 15:30:24 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RWV4A-00033p-Uo
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 15:30:23 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-15.tower-174.messagelabs.com!1322839781!3841097!1
X-Originating-IP: [208.97.132.202]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4yMDIgPT4gMTYzOTU=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2630 invoked from network); 2 Dec 2011 15:29:41 -0000
Received: from caiajhbdccac.dreamhost.com (HELO homiemail-a12.g.dreamhost.com)
	(208.97.132.202) by server-15.tower-174.messagelabs.com with SMTP;
	2 Dec 2011 15:29:41 -0000
Received: from homiemail-a12.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a12.g.dreamhost.com (Postfix) with ESMTP id 7AE0F714088;
	Fri,  2 Dec 2011 07:29:40 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=vFPUzRMr/l6w5QL0L6yUglNGPkJ8VqzbZwvrou45fczK
	u8ZeWFNBNw0Tejw6nntkrrQx1p3gsvdgzrE0JQVlpxcbbi6BhGOZiUnHnwsNJpmU
	Di2Znp56rOcJtWJ+NghXKc/j63ZhO5GPDM9NPpZnWLS71aRVgtAdDWIwu2Njcn4=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=b7AdEDPknkOJ1E2DEA7b1fyIhFw=; b=H19XCPME
	MfI3qpf3jmWE9c5Y/kPkH4tl3QYWLgjWyXhBBCN3QIrezIEwfMUvUB1CK4GKvZlE
	iFCkZf390bWZZfSzR9bfQNE5Wa5+rwAB/QCUKfLqcq6Azk8wjjhjddNsA/dvQCFV
	lw8H6J+ZEwEYu+MKWC7HqrSASV6gvoAAPMs=
Received: from webmail.lagarcavilla.org (ahfbbjcaiaae.dreamhost.com
	[75.119.208.4]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a12.g.dreamhost.com (Postfix) with ESMTPA id A2FC4714085; 
	Fri,  2 Dec 2011 07:29:39 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP; Fri, 2 Dec 2011 07:29:40 -0800
Message-ID: <7ba95535823dd32cc2a73d78646059bc.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20111202071148.GA23017@aepfle.de>
References: <2a4ec2e2ae36593aa74e.1322772973@xdev.gridcentric.ca>
	<20111202071148.GA23017@aepfle.de>
Date: Fri, 2 Dec 2011 07:29:40 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Olaf Hering" <olaf@aepfle.de>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com, tim@xen.org,
	keir.xen@gmail.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH] Flag events caused by foreign domains
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> On Thu, Dec 01, Andres Lagar-Cavilla wrote:
>
>> Add a new flag for mem events, as consumers might need to discriminate
>> foreign domain-caused from guest-caused events. The vcpu field of an
>> event is bogus from a consumer p.o.v. for foreign domain-caused events.
>
> How is this supposed to be used?
We're just OR'ing an extra flag on existing events. Toolstacks can ignore
it, or use it to handle foreign events differently, or whatever. No new
events are generated, timings don't change etc.

Is that your concern?
Andres
>
> If the toolstack is going to use this then I have to say that it cant
> delay events much because the ring will be filled up quickly with the
> result that no more events can be generated until the toolstack sends
> responses back to the hypervisor.
>
> Olaf
>



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

From xen-devel-bounces@lists.xensource.com Fri Dec 02 15:30:39 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 15:30:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWV4C-00034c-TT; Fri, 02 Dec 2011 15:30:24 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RWV4A-00033p-Uo
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 15:30:23 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-15.tower-174.messagelabs.com!1322839781!3841097!1
X-Originating-IP: [208.97.132.202]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4yMDIgPT4gMTYzOTU=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2630 invoked from network); 2 Dec 2011 15:29:41 -0000
Received: from caiajhbdccac.dreamhost.com (HELO homiemail-a12.g.dreamhost.com)
	(208.97.132.202) by server-15.tower-174.messagelabs.com with SMTP;
	2 Dec 2011 15:29:41 -0000
Received: from homiemail-a12.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a12.g.dreamhost.com (Postfix) with ESMTP id 7AE0F714088;
	Fri,  2 Dec 2011 07:29:40 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=vFPUzRMr/l6w5QL0L6yUglNGPkJ8VqzbZwvrou45fczK
	u8ZeWFNBNw0Tejw6nntkrrQx1p3gsvdgzrE0JQVlpxcbbi6BhGOZiUnHnwsNJpmU
	Di2Znp56rOcJtWJ+NghXKc/j63ZhO5GPDM9NPpZnWLS71aRVgtAdDWIwu2Njcn4=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=b7AdEDPknkOJ1E2DEA7b1fyIhFw=; b=H19XCPME
	MfI3qpf3jmWE9c5Y/kPkH4tl3QYWLgjWyXhBBCN3QIrezIEwfMUvUB1CK4GKvZlE
	iFCkZf390bWZZfSzR9bfQNE5Wa5+rwAB/QCUKfLqcq6Azk8wjjhjddNsA/dvQCFV
	lw8H6J+ZEwEYu+MKWC7HqrSASV6gvoAAPMs=
Received: from webmail.lagarcavilla.org (ahfbbjcaiaae.dreamhost.com
	[75.119.208.4]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a12.g.dreamhost.com (Postfix) with ESMTPA id A2FC4714085; 
	Fri,  2 Dec 2011 07:29:39 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP; Fri, 2 Dec 2011 07:29:40 -0800
Message-ID: <7ba95535823dd32cc2a73d78646059bc.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20111202071148.GA23017@aepfle.de>
References: <2a4ec2e2ae36593aa74e.1322772973@xdev.gridcentric.ca>
	<20111202071148.GA23017@aepfle.de>
Date: Fri, 2 Dec 2011 07:29:40 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Olaf Hering" <olaf@aepfle.de>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com, tim@xen.org,
	keir.xen@gmail.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH] Flag events caused by foreign domains
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> On Thu, Dec 01, Andres Lagar-Cavilla wrote:
>
>> Add a new flag for mem events, as consumers might need to discriminate
>> foreign domain-caused from guest-caused events. The vcpu field of an
>> event is bogus from a consumer p.o.v. for foreign domain-caused events.
>
> How is this supposed to be used?
We're just OR'ing an extra flag on existing events. Toolstacks can ignore
it, or use it to handle foreign events differently, or whatever. No new
events are generated, timings don't change etc.

Is that your concern?
Andres
>
> If the toolstack is going to use this then I have to say that it cant
> delay events much because the ring will be filled up quickly with the
> result that no more events can be generated until the toolstack sends
> responses back to the hypervisor.
>
> Olaf
>



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

From xen-devel-bounces@lists.xensource.com Fri Dec 02 15:32:40 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 15:32:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWV6B-0003Kb-Er; Fri, 02 Dec 2011 15:32:27 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RWV6A-0003Jy-2g
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 15:32:26 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-13.tower-182.messagelabs.com!1322839904!5112058!1
X-Originating-IP: [208.97.132.207]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4yMDcgPT4gMTYwMTU=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29950 invoked from network); 2 Dec 2011 15:31:44 -0000
Received: from caiajhbdccah.dreamhost.com (HELO homiemail-a76.g.dreamhost.com)
	(208.97.132.207) by server-13.tower-182.messagelabs.com with SMTP;
	2 Dec 2011 15:31:44 -0000
Received: from homiemail-a76.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTP id 437C3458081;
	Fri,  2 Dec 2011 07:31:43 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=fny0jYg2UvgkcmDVMAYSNf4VXGOzJ4RtjNabqcNVcv7u
	jxyzVnqRu5Jo8HcsU1I6qt81WJz4aoAwqP4Sx9TiRhthC7RPRolQC8UtdyyqVQHf
	xS8mKOIkSXH3lwtepOJKcU0gwHvhbw4+iH8Wu+lw2O5JtUTeoRbk6pqlZHVgT5U=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=OuUbdJ28C0B5vfHyxGU/g/q6Pbk=; b=vcQbdvw8
	TBQdTia13fR+jVtxrwzCPeDOYKKaysQ5ctHhoKTyoy71ngk++X3VPibsay9X5Jow
	mvg1BWvyzLmgVjl4xo9AT4tmtUhUZcKoSgCVWrQl5ABr73iLIbESqEoZOWZaT9Bx
	jkZ7Eif1mqGAgXUPLPqad5j33c07I78IGdo=
Received: from webmail.lagarcavilla.org (ahfbbjcaiaae.dreamhost.com
	[75.119.208.4]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTPA id 9D3F0458083; 
	Fri,  2 Dec 2011 07:31:42 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP; Fri, 2 Dec 2011 07:31:43 -0800
Message-ID: <2635982a39e7ab9434c11bff92879705.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <4ED8A7E8020000780006503C@nat28.tlf.novell.com>
References: <patchbomb.1322772713@xdev.gridcentric.ca>
	<df9e25a0189b1a5a94b1.1322772714@xdev.gridcentric.ca>
	<4ED8A7E8020000780006503C@nat28.tlf.novell.com>
Date: Fri, 2 Dec 2011 07:31:43 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Jan Beulich" <JBeulich@suse.com>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, olaf@aepfle.de, andres@gridcentric.ca,
	mike.mcclurg@citrix.com, jonathan.ludlam@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH 1 of 2] xen/x86: make
 __direct_remap_pfn_range()'s return value meaningful
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>  >>> On 01.12.11 at 21:51, Andres Lagar-Cavilla <andres@lagarcavilla.org>
> wrote:
>> arch/x86/mm/ioremap-xen.c |  12 ++++--------
>>  1 files changed, 4 insertions(+), 8 deletions(-)
>>
>>
>> This change fixes the xc_map_foreign_bulk interface, which would
>> otherwise cause SIGBUS when pages are gone because -ENOENT is not
>> returned as expected by the IOCTL_PRIVCMD_MMAPBATCH_V2 ioctl.
>>
>> Signed-off-by: Jan Beulich <jbeulich@novell.com>
>
> You lost authorship here.
I used this:
http://xenbits.xen.org/hg/linux-2.6.18-xen.hg/rev/0051d294bb60
Andres
>
> Jan
>
>



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

From xen-devel-bounces@lists.xensource.com Fri Dec 02 15:32:40 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 15:32:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWV6B-0003Kb-Er; Fri, 02 Dec 2011 15:32:27 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RWV6A-0003Jy-2g
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 15:32:26 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-13.tower-182.messagelabs.com!1322839904!5112058!1
X-Originating-IP: [208.97.132.207]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4yMDcgPT4gMTYwMTU=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29950 invoked from network); 2 Dec 2011 15:31:44 -0000
Received: from caiajhbdccah.dreamhost.com (HELO homiemail-a76.g.dreamhost.com)
	(208.97.132.207) by server-13.tower-182.messagelabs.com with SMTP;
	2 Dec 2011 15:31:44 -0000
Received: from homiemail-a76.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTP id 437C3458081;
	Fri,  2 Dec 2011 07:31:43 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=fny0jYg2UvgkcmDVMAYSNf4VXGOzJ4RtjNabqcNVcv7u
	jxyzVnqRu5Jo8HcsU1I6qt81WJz4aoAwqP4Sx9TiRhthC7RPRolQC8UtdyyqVQHf
	xS8mKOIkSXH3lwtepOJKcU0gwHvhbw4+iH8Wu+lw2O5JtUTeoRbk6pqlZHVgT5U=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=OuUbdJ28C0B5vfHyxGU/g/q6Pbk=; b=vcQbdvw8
	TBQdTia13fR+jVtxrwzCPeDOYKKaysQ5ctHhoKTyoy71ngk++X3VPibsay9X5Jow
	mvg1BWvyzLmgVjl4xo9AT4tmtUhUZcKoSgCVWrQl5ABr73iLIbESqEoZOWZaT9Bx
	jkZ7Eif1mqGAgXUPLPqad5j33c07I78IGdo=
Received: from webmail.lagarcavilla.org (ahfbbjcaiaae.dreamhost.com
	[75.119.208.4]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTPA id 9D3F0458083; 
	Fri,  2 Dec 2011 07:31:42 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP; Fri, 2 Dec 2011 07:31:43 -0800
Message-ID: <2635982a39e7ab9434c11bff92879705.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <4ED8A7E8020000780006503C@nat28.tlf.novell.com>
References: <patchbomb.1322772713@xdev.gridcentric.ca>
	<df9e25a0189b1a5a94b1.1322772714@xdev.gridcentric.ca>
	<4ED8A7E8020000780006503C@nat28.tlf.novell.com>
Date: Fri, 2 Dec 2011 07:31:43 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Jan Beulich" <JBeulich@suse.com>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, olaf@aepfle.de, andres@gridcentric.ca,
	mike.mcclurg@citrix.com, jonathan.ludlam@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH 1 of 2] xen/x86: make
 __direct_remap_pfn_range()'s return value meaningful
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>  >>> On 01.12.11 at 21:51, Andres Lagar-Cavilla <andres@lagarcavilla.org>
> wrote:
>> arch/x86/mm/ioremap-xen.c |  12 ++++--------
>>  1 files changed, 4 insertions(+), 8 deletions(-)
>>
>>
>> This change fixes the xc_map_foreign_bulk interface, which would
>> otherwise cause SIGBUS when pages are gone because -ENOENT is not
>> returned as expected by the IOCTL_PRIVCMD_MMAPBATCH_V2 ioctl.
>>
>> Signed-off-by: Jan Beulich <jbeulich@novell.com>
>
> You lost authorship here.
I used this:
http://xenbits.xen.org/hg/linux-2.6.18-xen.hg/rev/0051d294bb60
Andres
>
> Jan
>
>



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

From xen-devel-bounces@lists.xensource.com Fri Dec 02 15:33:10 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 15:33:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWV6g-0003Q0-Sm; Fri, 02 Dec 2011 15:32:58 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1RWV6f-0003OP-Om
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 15:32:57 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1322839935!5647318!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=1.3 required=7.0 tests=BODY_RANDOMQ,RCVD_BY_IP
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6302 invoked from network); 2 Dec 2011 15:32:16 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Dec 2011 15:32:16 -0000
Received: by iaen33 with SMTP id n33so6977422iae.30
	for <xen-devel@lists.xensource.com>;
	Fri, 02 Dec 2011 07:32:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=EDCzvO3m9BSYpY+5trvqBRhnFWlbilA0IHnxGzEfUEg=;
	b=bNaPNopNO/j0PfwiOr6JG4/niPB7QjnEKjb2IWIpYYb4DZF2D25lLLy/YYBXBZWbJO
	MLy38IvlZ0Pdc8JmMpG7RgDqzsOAMCFvy+hCR1pxjK1COsQSwKHNKbMcNrs9YT58bC3t
	FDmv0HPzAY7nrSMmM/0MfVnUlPlL7th2K2cA8=
MIME-Version: 1.0
Received: by 10.231.6.135 with SMTP id 7mr3211722ibz.60.1322839934518; Fri, 02
	Dec 2011 07:32:14 -0800 (PST)
Received: by 10.231.223.5 with HTTP; Fri, 2 Dec 2011 07:32:14 -0800 (PST)
In-Reply-To: <3A26C6941B57415BAC7352BF4EF8EE80@COMMATRIX>
References: <3A26C6941B57415BAC7352BF4EF8EE80@COMMATRIX>
Date: Fri, 2 Dec 2011 15:32:14 +0000
X-Google-Sender-Auth: 1mNe4-2Mw9rvdqw7xRftfyoJ_wg
Message-ID: <CAFLBxZZFQfSkZR7vwsebjvuCJsd8MCSjhdXg29yiRf0oJVp9QQ@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: "Admin@DotComPower.com" <admin@dotcompower.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] XCP - SCST - SRPT
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

The list you want for XCP and Kronos-related questions is actually
xen-api@lists.xensource.com.

Yes, the naming is not obvious. :-)

 -George

On Fri, Dec 2, 2011 at 1:33 PM, Admin@DotComPower.com
<admin@dotcompower.com> wrote:
> Hello,
>
> Using XCP and Kronos with SAN connected via IB_SRP and using SCST SRPT.
>
> The initiator for SRP is different from iSCSI as it does not use a
> traditional IQN for the target.
>
> Is there a workaround or way to use XCP with this setup to add storage
> devices via IB_SRP as SRs?
>
> Thus far I have only been able to get an SR setup when the device is
> connected via IB_SRP as a local scsi device via SRP initiator. With this
> setup it treats the target drive like another local drive though. I lose the
> ability to live migrate, which is the whole point of having a SAN storage
> device. Or is there a workaround for this?
>
> Thanks,
>
> Jonathan
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

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

From xen-devel-bounces@lists.xensource.com Fri Dec 02 15:33:10 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 15:33:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWV6g-0003Q0-Sm; Fri, 02 Dec 2011 15:32:58 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1RWV6f-0003OP-Om
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 15:32:57 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1322839935!5647318!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=1.3 required=7.0 tests=BODY_RANDOMQ,RCVD_BY_IP
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6302 invoked from network); 2 Dec 2011 15:32:16 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Dec 2011 15:32:16 -0000
Received: by iaen33 with SMTP id n33so6977422iae.30
	for <xen-devel@lists.xensource.com>;
	Fri, 02 Dec 2011 07:32:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=EDCzvO3m9BSYpY+5trvqBRhnFWlbilA0IHnxGzEfUEg=;
	b=bNaPNopNO/j0PfwiOr6JG4/niPB7QjnEKjb2IWIpYYb4DZF2D25lLLy/YYBXBZWbJO
	MLy38IvlZ0Pdc8JmMpG7RgDqzsOAMCFvy+hCR1pxjK1COsQSwKHNKbMcNrs9YT58bC3t
	FDmv0HPzAY7nrSMmM/0MfVnUlPlL7th2K2cA8=
MIME-Version: 1.0
Received: by 10.231.6.135 with SMTP id 7mr3211722ibz.60.1322839934518; Fri, 02
	Dec 2011 07:32:14 -0800 (PST)
Received: by 10.231.223.5 with HTTP; Fri, 2 Dec 2011 07:32:14 -0800 (PST)
In-Reply-To: <3A26C6941B57415BAC7352BF4EF8EE80@COMMATRIX>
References: <3A26C6941B57415BAC7352BF4EF8EE80@COMMATRIX>
Date: Fri, 2 Dec 2011 15:32:14 +0000
X-Google-Sender-Auth: 1mNe4-2Mw9rvdqw7xRftfyoJ_wg
Message-ID: <CAFLBxZZFQfSkZR7vwsebjvuCJsd8MCSjhdXg29yiRf0oJVp9QQ@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: "Admin@DotComPower.com" <admin@dotcompower.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] XCP - SCST - SRPT
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

The list you want for XCP and Kronos-related questions is actually
xen-api@lists.xensource.com.

Yes, the naming is not obvious. :-)

 -George

On Fri, Dec 2, 2011 at 1:33 PM, Admin@DotComPower.com
<admin@dotcompower.com> wrote:
> Hello,
>
> Using XCP and Kronos with SAN connected via IB_SRP and using SCST SRPT.
>
> The initiator for SRP is different from iSCSI as it does not use a
> traditional IQN for the target.
>
> Is there a workaround or way to use XCP with this setup to add storage
> devices via IB_SRP as SRs?
>
> Thus far I have only been able to get an SR setup when the device is
> connected via IB_SRP as a local scsi device via SRP initiator. With this
> setup it treats the target drive like another local drive though. I lose the
> ability to live migrate, which is the whole point of having a SAN storage
> device. Or is there a workaround for this?
>
> Thanks,
>
> Jonathan
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

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

From xen-devel-bounces@lists.xensource.com Fri Dec 02 15:42:32 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 15:42:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWVFg-0003qf-5D; Fri, 02 Dec 2011 15:42:16 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RWVFf-0003qa-4E
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 15:42:15 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1322840493!5964055!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTg0Mw==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20201 invoked from network); 2 Dec 2011 15:41:33 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Dec 2011 15:41:33 -0000
X-IronPort-AV: E=Sophos;i="4.71,284,1320624000"; 
   d="scan'208";a="9254929"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Dec 2011 15:41:32 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 2 Dec 2011 15:41:32 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RWV1S-0002zJ-JF;
	Fri, 02 Dec 2011 15:27:34 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RWV1S-0006tf-I1;
	Fri, 02 Dec 2011 15:27:34 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10239-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 2 Dec 2011 15:27:34 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10239: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

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

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-amd64-xl-win       8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-i386-win-vcpus1    8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-i386-win           8 guest-saverestore         fail REGR. vs. 10201
 test-i386-i386-win            8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-i386-xl-win-vcpus1  8 guest-saverestore        fail REGR. vs. 10201
 test-i386-i386-xl-win         8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-amd64-win          8 guest-saverestore         fail REGR. vs. 10201

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-i386-xend-winxpsp3  7 windows-install              fail  never pass
 test-amd64-amd64-xl-win7-amd64  7 windows-install              fail never pass
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install          fail never pass
 test-amd64-i386-xl-win7-amd64  7 windows-install              fail  never pass
 test-i386-i386-xl-winxpsp3    7 windows-install              fail   never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass

version targeted for testing:
 xen                  60d4e257d04b
baseline version:
 xen                  62ff6a318c5d

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Anthony PERARD <anthony.perard@citrix.com>
  Brendan Cully <brendan@cs.ubc.ca>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Jonathan Davies <jonathan.davies@citrix.com>
  juergen.gross@ts.fujitsu.com
  Keir Fraser <keir@xen.org>
  Liu, Jinsong <jinsong.liu@intel.com>
  Olaf Hering <olaf@aepfle.de>
  Philipp Hahn <hahn@univention.de>
  Shriram Rajagopalan <rshriram@cs.ubc.ca>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
------------------------------------------------------------

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


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

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

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


Not pushing.

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

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

From xen-devel-bounces@lists.xensource.com Fri Dec 02 15:42:32 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 15:42:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWVFg-0003qf-5D; Fri, 02 Dec 2011 15:42:16 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RWVFf-0003qa-4E
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 15:42:15 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1322840493!5964055!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTg0Mw==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20201 invoked from network); 2 Dec 2011 15:41:33 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Dec 2011 15:41:33 -0000
X-IronPort-AV: E=Sophos;i="4.71,284,1320624000"; 
   d="scan'208";a="9254929"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Dec 2011 15:41:32 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 2 Dec 2011 15:41:32 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RWV1S-0002zJ-JF;
	Fri, 02 Dec 2011 15:27:34 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RWV1S-0006tf-I1;
	Fri, 02 Dec 2011 15:27:34 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10239-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 2 Dec 2011 15:27:34 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10239: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

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

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-amd64-xl-win       8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-i386-win-vcpus1    8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-i386-win           8 guest-saverestore         fail REGR. vs. 10201
 test-i386-i386-win            8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-i386-xl-win-vcpus1  8 guest-saverestore        fail REGR. vs. 10201
 test-i386-i386-xl-win         8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-amd64-win          8 guest-saverestore         fail REGR. vs. 10201

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-i386-xend-winxpsp3  7 windows-install              fail  never pass
 test-amd64-amd64-xl-win7-amd64  7 windows-install              fail never pass
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install          fail never pass
 test-amd64-i386-xl-win7-amd64  7 windows-install              fail  never pass
 test-i386-i386-xl-winxpsp3    7 windows-install              fail   never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass

version targeted for testing:
 xen                  60d4e257d04b
baseline version:
 xen                  62ff6a318c5d

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Anthony PERARD <anthony.perard@citrix.com>
  Brendan Cully <brendan@cs.ubc.ca>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Jonathan Davies <jonathan.davies@citrix.com>
  juergen.gross@ts.fujitsu.com
  Keir Fraser <keir@xen.org>
  Liu, Jinsong <jinsong.liu@intel.com>
  Olaf Hering <olaf@aepfle.de>
  Philipp Hahn <hahn@univention.de>
  Shriram Rajagopalan <rshriram@cs.ubc.ca>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
------------------------------------------------------------

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


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

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

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


Not pushing.

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

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

From xen-devel-bounces@lists.xensource.com Fri Dec 02 15:45:57 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 15:45:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWVIy-0003zK-Po; Fri, 02 Dec 2011 15:45:40 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RWVIx-0003yy-8J
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 15:45:39 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1322840698!5964518!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQyOTg=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30162 invoked from network); 2 Dec 2011 15:44:58 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-12.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 2 Dec 2011 15:44:58 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 02 Dec 2011 15:44:57 +0000
Message-Id: <4ED900870200007800065206@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 02 Dec 2011 15:44:55 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: <andres@lagarcavilla.org>
References: <patchbomb.1322772713@xdev.gridcentric.ca>
	<df9e25a0189b1a5a94b1.1322772714@xdev.gridcentric.ca>
	<4ED8A7E8020000780006503C@nat28.tlf.novell.com>
	<2635982a39e7ab9434c11bff92879705.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <2635982a39e7ab9434c11bff92879705.squirrel@webmail.lagarcavilla.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com, olaf@aepfle.de, andres@gridcentric.ca,
	mike.mcclurg@citrix.com, jonathan.ludlam@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH 1 of 2] xen/x86: make
 __direct_remap_pfn_range()'s return value meaningful
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 02.12.11 at 16:31, "Andres Lagar-Cavilla" <andres@lagarcavilla.org> wrote:
>>   >>> On 01.12.11 at 21:51, Andres Lagar-Cavilla <andres@lagarcavilla.org>
>> wrote:
>>> arch/x86/mm/ioremap-xen.c |  12 ++++--------
>>>  1 files changed, 4 insertions(+), 8 deletions(-)
>>>
>>>
>>> This change fixes the xc_map_foreign_bulk interface, which would
>>> otherwise cause SIGBUS when pages are gone because -ENOENT is not
>>> returned as expected by the IOCTL_PRIVCMD_MMAPBATCH_V2 ioctl.
>>>
>>> Signed-off-by: Jan Beulich <jbeulich@novell.com>
>>
>> You lost authorship here.
> I used this:
> http://xenbits.xen.org/hg/linux-2.6.18-xen.hg/rev/0051d294bb60 

And you dropped the "From: Olaf Hering <ohering@novell.com>" line.

Jan


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

From xen-devel-bounces@lists.xensource.com Fri Dec 02 15:45:57 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 15:45:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWVIy-0003zK-Po; Fri, 02 Dec 2011 15:45:40 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RWVIx-0003yy-8J
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 15:45:39 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1322840698!5964518!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQyOTg=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30162 invoked from network); 2 Dec 2011 15:44:58 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-12.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 2 Dec 2011 15:44:58 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 02 Dec 2011 15:44:57 +0000
Message-Id: <4ED900870200007800065206@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 02 Dec 2011 15:44:55 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: <andres@lagarcavilla.org>
References: <patchbomb.1322772713@xdev.gridcentric.ca>
	<df9e25a0189b1a5a94b1.1322772714@xdev.gridcentric.ca>
	<4ED8A7E8020000780006503C@nat28.tlf.novell.com>
	<2635982a39e7ab9434c11bff92879705.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <2635982a39e7ab9434c11bff92879705.squirrel@webmail.lagarcavilla.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com, olaf@aepfle.de, andres@gridcentric.ca,
	mike.mcclurg@citrix.com, jonathan.ludlam@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH 1 of 2] xen/x86: make
 __direct_remap_pfn_range()'s return value meaningful
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 02.12.11 at 16:31, "Andres Lagar-Cavilla" <andres@lagarcavilla.org> wrote:
>>   >>> On 01.12.11 at 21:51, Andres Lagar-Cavilla <andres@lagarcavilla.org>
>> wrote:
>>> arch/x86/mm/ioremap-xen.c |  12 ++++--------
>>>  1 files changed, 4 insertions(+), 8 deletions(-)
>>>
>>>
>>> This change fixes the xc_map_foreign_bulk interface, which would
>>> otherwise cause SIGBUS when pages are gone because -ENOENT is not
>>> returned as expected by the IOCTL_PRIVCMD_MMAPBATCH_V2 ioctl.
>>>
>>> Signed-off-by: Jan Beulich <jbeulich@novell.com>
>>
>> You lost authorship here.
> I used this:
> http://xenbits.xen.org/hg/linux-2.6.18-xen.hg/rev/0051d294bb60 

And you dropped the "From: Olaf Hering <ohering@novell.com>" line.

Jan


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

From xen-devel-bounces@lists.xensource.com Fri Dec 02 15:46:18 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 15:46:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWVJO-00041w-6e; Fri, 02 Dec 2011 15:46:06 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RWVJL-00041K-Ri
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 15:46:04 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-5.tower-174.messagelabs.com!1322840721!4043084!1
X-Originating-IP: [208.97.132.207]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4yMDcgPT4gMTYwMTU=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22679 invoked from network); 2 Dec 2011 15:45:21 -0000
Received: from caiajhbdccah.dreamhost.com (HELO homiemail-a12.g.dreamhost.com)
	(208.97.132.207) by server-5.tower-174.messagelabs.com with SMTP;
	2 Dec 2011 15:45:21 -0000
Received: from homiemail-a12.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a12.g.dreamhost.com (Postfix) with ESMTP id 739D9714075;
	Fri,  2 Dec 2011 07:40:20 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=dwkqFuxrzYE1wrte5Kk5vGSMejO5TQcEzLJj/r/YKh//
	j0ZZPSmj/unTa0i9hIm/dmpasupF0upFT7d5Td9mtR9EPiQ1pNllk+a29+yayHiF
	ShE8Tqf2cMDrJbgov/AZMsUNQCQnAFQLe1N8Bd+cWnkpBPXluWB4oXq6VXanqdM=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=jLRzTN8iz0YUDPBHjXRKMB6mjm4=; b=Z8aC33r6
	i5FZuaCO/Csf2y5OvP7p8YnyNS2VYRIQmgenG6cMuOZmvbry2YRhzgkJ5Au8P+SV
	xJdUyG7RAUMymNMIgLGWLCbbXkO2/KmnhkERwTdI+L4FEV/EqZ+wDK+F607iMnt4
	m5f9gzShgL81Cs1IXriRyv0+EYaUi9SaQf0=
Received: from webmail.lagarcavilla.org (ahfbbjcaiaae.dreamhost.com
	[75.119.208.4]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a12.g.dreamhost.com (Postfix) with ESMTPA id 2F902714070; 
	Fri,  2 Dec 2011 07:40:20 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP; Fri, 2 Dec 2011 07:40:20 -0800
Message-ID: <692994dd45838eb34dd70edc9f887eb3.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <1322822903.29870.17.camel@zakaz.uk.xensource.com>
References: <osstest-10231-mainreport@xen.org>
	<1322822903.29870.17.camel@zakaz.uk.xensource.com>
Date: Fri, 2 Dec 2011 07:40:20 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: Shriram Rajagopalan <rshriram@cs.ubc.ca>, Tim Deegan <tim@xen.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"xen.org" <ian.jackson@eu.citrix.com>,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>
Subject: Re: [Xen-devel] [xen-unstable test] 10231: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> On Fri, 2011-12-02 at 04:23 +0000, xen.org wrote:
>> flight 10231 xen-unstable real [real]
>> http://www.chiark.greenend.org.uk/~xensrcts/logs/10231/
>>
>> Regressions :-(
>>
>> Tests which did not succeed and are blocking:
>>  test-amd64-amd64-xl-win       8 guest-saverestore         fail REGR.
>> vs. 10201
>>  test-amd64-i386-win-vcpus1    8 guest-saverestore         fail REGR.
>> vs. 10201
>>  test-amd64-i386-win           8 guest-saverestore         fail REGR.
>> vs. 10201
>>  test-i386-i386-win            8 guest-saverestore         fail REGR.
>> vs. 10201
>>  test-amd64-i386-xl-win-vcpus1  8 guest-saverestore        fail REGR.
>> vs. 10201
>>  test-i386-i386-xl-win         8 guest-saverestore         fail REGR.
>> vs. 10201
>>  test-amd64-amd64-win          8 guest-saverestore         fail REGR.
>> vs. 10201
>
> The xl ones are all failing with:
>         2011-12-02 04:17:52 Z executing ssh ... root@10.80.249.56 xl save
> win.guest.osstest image
>         Saving to image new xl format (info 0x0/0x0/625)
>         libxl: error: libxl_exec.c:257:libxl__wait_for_offspring: Device
> Model not ready
>
> while the xm ones are failing with:
>         2011-12-02 03:22:20 Z executing ssh ... root@10.80.250.28 xm save
> win.guest.osstest image
>         Usage: xm save [-c] <Domain> <CheckpointFile>
>
>         Save a domain state to restore later.
>           -c, --checkpoint               Leave domain running after
> creating
>                                          snapshot
>
>         Error: Timed out waiting for device model action
>
> In the xl case the test harness doesn't appear to have noticed the
> failure. Might be bad error handling in xl or a bug in the harness. (my
> money would be on the former).
>
> I can't see anything in the qemu logs for the xm case but in one xl case
> there is:
> Error -22 while loading savevm file '/var/lib/xen/qemu-resume.5'
>
> In the xm case xend logs say:
> 011-12-02 03:22:22 2185] WARNING (image:552) domain
> migrating-win.guest.osstest: device model failure: pid 4278:
> malfunctioning (closed sentinel), killed; see
> /var/log/xen/qemu-dm-win.guest.osstest.log
> [2011-12-02 03:22:32 2185] INFO (XendCheckpoint:423) xc: error: Suspend
> request failed: Internal error
> [2011-12-02 03:22:32 2185] INFO (XendCheckpoint:423) xc: error: Domain
> appears not to have suspended: Internal error
>
> but as I say nothing interesting appears in qemu-dm...log
> [...]
>> version targeted for testing:
>>  xen                  3f815406feb2
>> baseline version:
>>  xen                  62ff6a318c5d
>
> changeset:   24332:6b26fb894ca0
> user:        Ian Jackson <Ian.Jackson@eu.citrix.com>
> date:        Thu Dec 01 18:26:45 2011 +0000
> summary:     Update QEMU_TAG
>
> is in there but appears to represent a bunch of passthrough updates.
> There also a bunch of Remus compression stuff which appears to touch
> non-Remus suspend/resume code in libxc too, that's a plausible candidate
> for the cause, I think
>
> There is also a bunch of paging stuff, which I guess/hope is harmless if
> paging is not in use? Tim, Andreas?.
I'd be surprised. Afaict, the only realistic possibilities from my side are
f71ecec8be2e "x86/mm: Ensure maps used by nested hvm code cannot be paged
out"
and
75f4e4d9f039 "x86/mm: Don't trigger unnecessary shadow scans on p2m entry
update"

Andres

>
> Otherwise it appears to all be docs and emulator changes which all seem
> less likely. There's some libxl stuff but you wouldn't expect that to
> hurt xend...
>
> I guess the bisector is on the case.
>
>>
>> ------------------------------------------------------------
>> People who touched revisions under test:
>>   Adin Scannell <adin@scannell.ca>
>>   Andres Lagar-Cavilla <andres@lagarcavilla.org>
>>   Anthony PERARD <anthony.perard@citrix.com>
>>   Brendan Cully <brendan@cs.ubc.ca>
>>   Daniel De Graaf <dgdegra@tycho.nsa.gov>
>>   Ian Campbell <ian.campbell@citrix.com>
>>   Ian Jackson <ian.jackson.citrix.com>
>>   Ian Jackson <ian.jackson@eu.citrix.com>
>>   Jan Beulich <jbeulich@suse.com>
>>   Jean Guyader <jean.guyader@eu.citrix.com>
>>   Jonathan Davies <jonathan.davies@citrix.com>
>>   juergen.gross@ts.fujitsu.com
>>   Keir Fraser <keir@xen.org>
>>   Liu, Jinsong <jinsong.liu@intel.com>
>>   Olaf Hering <olaf@aepfle.de>
>>   Philipp Hahn <hahn@univention.de>
>>   Shriram Rajagopalan <rshriram@cs.ubc.ca>
>>   Stefano Stabellini <stefano.stabellini@eu.citrix.com>
>>   Tim Deegan <tim@xen.org>
>> ------------------------------------------------------------
>>
>> jobs:
>>  build-amd64                                                  pass
>>  build-i386                                                   pass
>>  build-amd64-oldkern                                          pass
>>  build-i386-oldkern                                           pass
>>  build-amd64-pvops                                            pass
>>  build-i386-pvops                                             pass
>>  test-amd64-amd64-xl                                          pass
>>  test-amd64-i386-xl                                           pass
>>  test-i386-i386-xl                                            pass
>>  test-amd64-i386-rhel6hvm-amd                                 fail
>>  test-amd64-amd64-xl-win7-amd64                               fail
>>  test-amd64-i386-xl-win7-amd64                                fail
>>  test-amd64-i386-xl-credit2                                   pass
>>  test-amd64-amd64-xl-pcipt-intel                              fail
>>  test-amd64-i386-rhel6hvm-intel                               fail
>>  test-amd64-i386-xl-multivcpu                                 pass
>>  test-amd64-amd64-pair                                        pass
>>  test-amd64-i386-pair                                         pass
>>  test-i386-i386-pair                                          pass
>>  test-amd64-amd64-pv                                          pass
>>  test-amd64-i386-pv                                           pass
>>  test-i386-i386-pv                                            pass
>>  test-amd64-amd64-xl-sedf                                     pass
>>  test-amd64-i386-win-vcpus1                                   fail
>>  test-amd64-i386-xl-win-vcpus1                                fail
>>  test-amd64-i386-xl-winxpsp3-vcpus1                           fail
>>  test-amd64-amd64-win                                         fail
>>  test-amd64-i386-win                                          fail
>>  test-i386-i386-win                                           fail
>>  test-amd64-amd64-xl-win                                      fail
>>  test-i386-i386-xl-win                                        fail
>>  test-amd64-i386-xend-winxpsp3                                fail
>>  test-amd64-amd64-xl-winxpsp3                                 fail
>>  test-i386-i386-xl-winxpsp3                                   fail
>>
>>
>> ------------------------------------------------------------
>> sg-report-flight on woking.cam.xci-test.com
>> logs: /home/xc_osstest/logs
>> images: /home/xc_osstest/images
>>
>> Logs, config files, etc. are available at
>>     http://www.chiark.greenend.org.uk/~xensrcts/logs
>>
>> Test harness code can be found at
>>     http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary
>>
>>
>> Not pushing.
>>
>> (No revision log; it would be 1073 lines long.)
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel
>
>
>
>



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

From xen-devel-bounces@lists.xensource.com Fri Dec 02 15:46:18 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 15:46:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWVJO-00041w-6e; Fri, 02 Dec 2011 15:46:06 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RWVJL-00041K-Ri
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 15:46:04 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-5.tower-174.messagelabs.com!1322840721!4043084!1
X-Originating-IP: [208.97.132.207]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4yMDcgPT4gMTYwMTU=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22679 invoked from network); 2 Dec 2011 15:45:21 -0000
Received: from caiajhbdccah.dreamhost.com (HELO homiemail-a12.g.dreamhost.com)
	(208.97.132.207) by server-5.tower-174.messagelabs.com with SMTP;
	2 Dec 2011 15:45:21 -0000
Received: from homiemail-a12.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a12.g.dreamhost.com (Postfix) with ESMTP id 739D9714075;
	Fri,  2 Dec 2011 07:40:20 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=dwkqFuxrzYE1wrte5Kk5vGSMejO5TQcEzLJj/r/YKh//
	j0ZZPSmj/unTa0i9hIm/dmpasupF0upFT7d5Td9mtR9EPiQ1pNllk+a29+yayHiF
	ShE8Tqf2cMDrJbgov/AZMsUNQCQnAFQLe1N8Bd+cWnkpBPXluWB4oXq6VXanqdM=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=jLRzTN8iz0YUDPBHjXRKMB6mjm4=; b=Z8aC33r6
	i5FZuaCO/Csf2y5OvP7p8YnyNS2VYRIQmgenG6cMuOZmvbry2YRhzgkJ5Au8P+SV
	xJdUyG7RAUMymNMIgLGWLCbbXkO2/KmnhkERwTdI+L4FEV/EqZ+wDK+F607iMnt4
	m5f9gzShgL81Cs1IXriRyv0+EYaUi9SaQf0=
Received: from webmail.lagarcavilla.org (ahfbbjcaiaae.dreamhost.com
	[75.119.208.4]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a12.g.dreamhost.com (Postfix) with ESMTPA id 2F902714070; 
	Fri,  2 Dec 2011 07:40:20 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP; Fri, 2 Dec 2011 07:40:20 -0800
Message-ID: <692994dd45838eb34dd70edc9f887eb3.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <1322822903.29870.17.camel@zakaz.uk.xensource.com>
References: <osstest-10231-mainreport@xen.org>
	<1322822903.29870.17.camel@zakaz.uk.xensource.com>
Date: Fri, 2 Dec 2011 07:40:20 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: Shriram Rajagopalan <rshriram@cs.ubc.ca>, Tim Deegan <tim@xen.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"xen.org" <ian.jackson@eu.citrix.com>,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>
Subject: Re: [Xen-devel] [xen-unstable test] 10231: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> On Fri, 2011-12-02 at 04:23 +0000, xen.org wrote:
>> flight 10231 xen-unstable real [real]
>> http://www.chiark.greenend.org.uk/~xensrcts/logs/10231/
>>
>> Regressions :-(
>>
>> Tests which did not succeed and are blocking:
>>  test-amd64-amd64-xl-win       8 guest-saverestore         fail REGR.
>> vs. 10201
>>  test-amd64-i386-win-vcpus1    8 guest-saverestore         fail REGR.
>> vs. 10201
>>  test-amd64-i386-win           8 guest-saverestore         fail REGR.
>> vs. 10201
>>  test-i386-i386-win            8 guest-saverestore         fail REGR.
>> vs. 10201
>>  test-amd64-i386-xl-win-vcpus1  8 guest-saverestore        fail REGR.
>> vs. 10201
>>  test-i386-i386-xl-win         8 guest-saverestore         fail REGR.
>> vs. 10201
>>  test-amd64-amd64-win          8 guest-saverestore         fail REGR.
>> vs. 10201
>
> The xl ones are all failing with:
>         2011-12-02 04:17:52 Z executing ssh ... root@10.80.249.56 xl save
> win.guest.osstest image
>         Saving to image new xl format (info 0x0/0x0/625)
>         libxl: error: libxl_exec.c:257:libxl__wait_for_offspring: Device
> Model not ready
>
> while the xm ones are failing with:
>         2011-12-02 03:22:20 Z executing ssh ... root@10.80.250.28 xm save
> win.guest.osstest image
>         Usage: xm save [-c] <Domain> <CheckpointFile>
>
>         Save a domain state to restore later.
>           -c, --checkpoint               Leave domain running after
> creating
>                                          snapshot
>
>         Error: Timed out waiting for device model action
>
> In the xl case the test harness doesn't appear to have noticed the
> failure. Might be bad error handling in xl or a bug in the harness. (my
> money would be on the former).
>
> I can't see anything in the qemu logs for the xm case but in one xl case
> there is:
> Error -22 while loading savevm file '/var/lib/xen/qemu-resume.5'
>
> In the xm case xend logs say:
> 011-12-02 03:22:22 2185] WARNING (image:552) domain
> migrating-win.guest.osstest: device model failure: pid 4278:
> malfunctioning (closed sentinel), killed; see
> /var/log/xen/qemu-dm-win.guest.osstest.log
> [2011-12-02 03:22:32 2185] INFO (XendCheckpoint:423) xc: error: Suspend
> request failed: Internal error
> [2011-12-02 03:22:32 2185] INFO (XendCheckpoint:423) xc: error: Domain
> appears not to have suspended: Internal error
>
> but as I say nothing interesting appears in qemu-dm...log
> [...]
>> version targeted for testing:
>>  xen                  3f815406feb2
>> baseline version:
>>  xen                  62ff6a318c5d
>
> changeset:   24332:6b26fb894ca0
> user:        Ian Jackson <Ian.Jackson@eu.citrix.com>
> date:        Thu Dec 01 18:26:45 2011 +0000
> summary:     Update QEMU_TAG
>
> is in there but appears to represent a bunch of passthrough updates.
> There also a bunch of Remus compression stuff which appears to touch
> non-Remus suspend/resume code in libxc too, that's a plausible candidate
> for the cause, I think
>
> There is also a bunch of paging stuff, which I guess/hope is harmless if
> paging is not in use? Tim, Andreas?.
I'd be surprised. Afaict, the only realistic possibilities from my side are
f71ecec8be2e "x86/mm: Ensure maps used by nested hvm code cannot be paged
out"
and
75f4e4d9f039 "x86/mm: Don't trigger unnecessary shadow scans on p2m entry
update"

Andres

>
> Otherwise it appears to all be docs and emulator changes which all seem
> less likely. There's some libxl stuff but you wouldn't expect that to
> hurt xend...
>
> I guess the bisector is on the case.
>
>>
>> ------------------------------------------------------------
>> People who touched revisions under test:
>>   Adin Scannell <adin@scannell.ca>
>>   Andres Lagar-Cavilla <andres@lagarcavilla.org>
>>   Anthony PERARD <anthony.perard@citrix.com>
>>   Brendan Cully <brendan@cs.ubc.ca>
>>   Daniel De Graaf <dgdegra@tycho.nsa.gov>
>>   Ian Campbell <ian.campbell@citrix.com>
>>   Ian Jackson <ian.jackson.citrix.com>
>>   Ian Jackson <ian.jackson@eu.citrix.com>
>>   Jan Beulich <jbeulich@suse.com>
>>   Jean Guyader <jean.guyader@eu.citrix.com>
>>   Jonathan Davies <jonathan.davies@citrix.com>
>>   juergen.gross@ts.fujitsu.com
>>   Keir Fraser <keir@xen.org>
>>   Liu, Jinsong <jinsong.liu@intel.com>
>>   Olaf Hering <olaf@aepfle.de>
>>   Philipp Hahn <hahn@univention.de>
>>   Shriram Rajagopalan <rshriram@cs.ubc.ca>
>>   Stefano Stabellini <stefano.stabellini@eu.citrix.com>
>>   Tim Deegan <tim@xen.org>
>> ------------------------------------------------------------
>>
>> jobs:
>>  build-amd64                                                  pass
>>  build-i386                                                   pass
>>  build-amd64-oldkern                                          pass
>>  build-i386-oldkern                                           pass
>>  build-amd64-pvops                                            pass
>>  build-i386-pvops                                             pass
>>  test-amd64-amd64-xl                                          pass
>>  test-amd64-i386-xl                                           pass
>>  test-i386-i386-xl                                            pass
>>  test-amd64-i386-rhel6hvm-amd                                 fail
>>  test-amd64-amd64-xl-win7-amd64                               fail
>>  test-amd64-i386-xl-win7-amd64                                fail
>>  test-amd64-i386-xl-credit2                                   pass
>>  test-amd64-amd64-xl-pcipt-intel                              fail
>>  test-amd64-i386-rhel6hvm-intel                               fail
>>  test-amd64-i386-xl-multivcpu                                 pass
>>  test-amd64-amd64-pair                                        pass
>>  test-amd64-i386-pair                                         pass
>>  test-i386-i386-pair                                          pass
>>  test-amd64-amd64-pv                                          pass
>>  test-amd64-i386-pv                                           pass
>>  test-i386-i386-pv                                            pass
>>  test-amd64-amd64-xl-sedf                                     pass
>>  test-amd64-i386-win-vcpus1                                   fail
>>  test-amd64-i386-xl-win-vcpus1                                fail
>>  test-amd64-i386-xl-winxpsp3-vcpus1                           fail
>>  test-amd64-amd64-win                                         fail
>>  test-amd64-i386-win                                          fail
>>  test-i386-i386-win                                           fail
>>  test-amd64-amd64-xl-win                                      fail
>>  test-i386-i386-xl-win                                        fail
>>  test-amd64-i386-xend-winxpsp3                                fail
>>  test-amd64-amd64-xl-winxpsp3                                 fail
>>  test-i386-i386-xl-winxpsp3                                   fail
>>
>>
>> ------------------------------------------------------------
>> sg-report-flight on woking.cam.xci-test.com
>> logs: /home/xc_osstest/logs
>> images: /home/xc_osstest/images
>>
>> Logs, config files, etc. are available at
>>     http://www.chiark.greenend.org.uk/~xensrcts/logs
>>
>> Test harness code can be found at
>>     http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary
>>
>>
>> Not pushing.
>>
>> (No revision log; it would be 1073 lines long.)
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel
>
>
>
>



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

From xen-devel-bounces@lists.xensource.com Fri Dec 02 15:52:16 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 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.xensource.com>)
	id 1RWVP8-0004tX-Gf; Fri, 02 Dec 2011 15:52:02 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RWVP7-0004tL-A9
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 15:52:01 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-5.tower-182.messagelabs.com!1322841076!5670386!1
X-Originating-IP: [208.97.132.66]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi42NiA9PiAxNTExMA==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16781 invoked from network); 2 Dec 2011 15:51:17 -0000
Received: from caiajhbdcagg.dreamhost.com (HELO homiemail-a21.g.dreamhost.com)
	(208.97.132.66) by server-5.tower-182.messagelabs.com with SMTP;
	2 Dec 2011 15:51:17 -0000
Received: from homiemail-a21.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTP id C65E5300064;
	Fri,  2 Dec 2011 07:51:15 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=kpr6f7rqiMoJpPbNNrO6FQoH0ckspGEF5LuI6uS5DUPm
	lktP4+2L5kpFUXUhu6B7fKMAyenYCsaKcIen9XVACAB4CrqTeI7YTFYXYAJ5jHv5
	9peiFM4AUGrfw1+GXg/+5kaxNUvNdy3BISqctkKAZOIaFLcotBKJKB0FLlYko68=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=ESKT2O7SVF4q5Cgol+IDc/3zmpo=; b=iFJhmctb
	fkF9c9EkBlSFHYAgMrIe0Gp0E3kIJGJX+M5a7aQfKM7/wUJI+Yy5uDxax2rcpwHi
	iXTDQr9GV+bg8itN4CHgx7O5GNEsenoeiFkDi0CQ2TofGU+qNXY4jBCeG85eZWki
	0wFTcmcYA+xLyBBnISWAkAR3iXAb/Y0Tu14=
Received: from webmail.lagarcavilla.org (ahfbbjcaiaae.dreamhost.com
	[75.119.208.4]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTPA id 43593300061; 
	Fri,  2 Dec 2011 07:51:15 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP; Fri, 2 Dec 2011 07:51:15 -0800
Message-ID: <304e15fa3a741f8b73bc6c04ba3720ed.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <4ED900870200007800065206@nat28.tlf.novell.com>
References: <patchbomb.1322772713@xdev.gridcentric.ca>
	<df9e25a0189b1a5a94b1.1322772714@xdev.gridcentric.ca>
	<4ED8A7E8020000780006503C@nat28.tlf.novell.com>
	<2635982a39e7ab9434c11bff92879705.squirrel@webmail.lagarcavilla.org>
	<4ED900870200007800065206@nat28.tlf.novell.com>
Date: Fri, 2 Dec 2011 07:51:15 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Jan Beulich" <JBeulich@suse.com>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, olaf@aepfle.de, andres@gridcentric.ca,
	mike.mcclurg@citrix.com, jonathan.ludlam@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH 1 of 2] xen/x86: make
 __direct_remap_pfn_range()'s return value meaningful
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>>> On 02.12.11 at 16:31, "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
>>>> wrote:
>>>   >>> On 01.12.11 at 21:51, Andres Lagar-Cavilla
>>> <andres@lagarcavilla.org>
>>> wrote:
>>>> arch/x86/mm/ioremap-xen.c |  12 ++++--------
>>>>  1 files changed, 4 insertions(+), 8 deletions(-)
>>>>
>>>>
>>>> This change fixes the xc_map_foreign_bulk interface, which would
>>>> otherwise cause SIGBUS when pages are gone because -ENOENT is not
>>>> returned as expected by the IOCTL_PRIVCMD_MMAPBATCH_V2 ioctl.
>>>>
>>>> Signed-off-by: Jan Beulich <jbeulich@novell.com>
>>>
>>> You lost authorship here.
>> I used this:
>> http://xenbits.xen.org/hg/linux-2.6.18-xen.hg/rev/0051d294bb60
>
> And you dropped the "From: Olaf Hering <ohering@novell.com>" line.
Righto ... very sorry. I can resend ... if this gets traction.
Andres
>
> Jan
>
>



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

From xen-devel-bounces@lists.xensource.com Fri Dec 02 15:52:16 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 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.xensource.com>)
	id 1RWVP8-0004tX-Gf; Fri, 02 Dec 2011 15:52:02 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RWVP7-0004tL-A9
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 15:52:01 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-5.tower-182.messagelabs.com!1322841076!5670386!1
X-Originating-IP: [208.97.132.66]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi42NiA9PiAxNTExMA==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16781 invoked from network); 2 Dec 2011 15:51:17 -0000
Received: from caiajhbdcagg.dreamhost.com (HELO homiemail-a21.g.dreamhost.com)
	(208.97.132.66) by server-5.tower-182.messagelabs.com with SMTP;
	2 Dec 2011 15:51:17 -0000
Received: from homiemail-a21.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTP id C65E5300064;
	Fri,  2 Dec 2011 07:51:15 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=kpr6f7rqiMoJpPbNNrO6FQoH0ckspGEF5LuI6uS5DUPm
	lktP4+2L5kpFUXUhu6B7fKMAyenYCsaKcIen9XVACAB4CrqTeI7YTFYXYAJ5jHv5
	9peiFM4AUGrfw1+GXg/+5kaxNUvNdy3BISqctkKAZOIaFLcotBKJKB0FLlYko68=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=ESKT2O7SVF4q5Cgol+IDc/3zmpo=; b=iFJhmctb
	fkF9c9EkBlSFHYAgMrIe0Gp0E3kIJGJX+M5a7aQfKM7/wUJI+Yy5uDxax2rcpwHi
	iXTDQr9GV+bg8itN4CHgx7O5GNEsenoeiFkDi0CQ2TofGU+qNXY4jBCeG85eZWki
	0wFTcmcYA+xLyBBnISWAkAR3iXAb/Y0Tu14=
Received: from webmail.lagarcavilla.org (ahfbbjcaiaae.dreamhost.com
	[75.119.208.4]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTPA id 43593300061; 
	Fri,  2 Dec 2011 07:51:15 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP; Fri, 2 Dec 2011 07:51:15 -0800
Message-ID: <304e15fa3a741f8b73bc6c04ba3720ed.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <4ED900870200007800065206@nat28.tlf.novell.com>
References: <patchbomb.1322772713@xdev.gridcentric.ca>
	<df9e25a0189b1a5a94b1.1322772714@xdev.gridcentric.ca>
	<4ED8A7E8020000780006503C@nat28.tlf.novell.com>
	<2635982a39e7ab9434c11bff92879705.squirrel@webmail.lagarcavilla.org>
	<4ED900870200007800065206@nat28.tlf.novell.com>
Date: Fri, 2 Dec 2011 07:51:15 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Jan Beulich" <JBeulich@suse.com>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, olaf@aepfle.de, andres@gridcentric.ca,
	mike.mcclurg@citrix.com, jonathan.ludlam@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH 1 of 2] xen/x86: make
 __direct_remap_pfn_range()'s return value meaningful
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>>> On 02.12.11 at 16:31, "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
>>>> wrote:
>>>   >>> On 01.12.11 at 21:51, Andres Lagar-Cavilla
>>> <andres@lagarcavilla.org>
>>> wrote:
>>>> arch/x86/mm/ioremap-xen.c |  12 ++++--------
>>>>  1 files changed, 4 insertions(+), 8 deletions(-)
>>>>
>>>>
>>>> This change fixes the xc_map_foreign_bulk interface, which would
>>>> otherwise cause SIGBUS when pages are gone because -ENOENT is not
>>>> returned as expected by the IOCTL_PRIVCMD_MMAPBATCH_V2 ioctl.
>>>>
>>>> Signed-off-by: Jan Beulich <jbeulich@novell.com>
>>>
>>> You lost authorship here.
>> I used this:
>> http://xenbits.xen.org/hg/linux-2.6.18-xen.hg/rev/0051d294bb60
>
> And you dropped the "From: Olaf Hering <ohering@novell.com>" line.
Righto ... very sorry. I can resend ... if this gets traction.
Andres
>
> Jan
>
>



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

From xen-devel-bounces@lists.xensource.com Fri Dec 02 15:55:43 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 15:55:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWVSX-00055F-51; Fri, 02 Dec 2011 15:55:33 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1RWVSU-00054x-Vw
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 15:55:31 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1322841246!59240138!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDMwNDMyOQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10637 invoked from network); 2 Dec 2011 15:54:07 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-7.tower-27.messagelabs.com with SMTP;
	2 Dec 2011 15:54:07 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga101.fm.intel.com with ESMTP; 02 Dec 2011 07:54:53 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,284,1320652800"; d="scan'208,217";a="91588917"
Received: from pgsmsx601.gar.corp.intel.com ([10.221.43.69])
	by fmsmga001.fm.intel.com with ESMTP; 02 Dec 2011 07:54:52 -0800
Received: from pgsmsx102.gar.corp.intel.com (10.221.44.80) by
	pgsmsx601.gar.corp.intel.com (10.221.43.69) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Fri, 2 Dec 2011 23:54:51 +0800
Received: from shsmsx601.ccr.corp.intel.com (10.239.4.112) by
	PGSMSX102.gar.corp.intel.com (10.221.44.80) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Fri, 2 Dec 2011 23:54:51 +0800
Received: from shsmsx502.ccr.corp.intel.com ([10.239.4.96]) by
	shsmsx601.ccr.corp.intel.com ([10.239.4.112]) with mapi; Fri, 2 Dec 2011
	23:54:50 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: "jbeulich@suse.com" <jbeulich@suse.com>
Date: Fri, 2 Dec 2011 23:54:48 +0800
Thread-Topic: [PATCH] X86 MCE: Add more strict sanity check of one SRAR case
Thread-Index: AcyxCrgiOHzcBq2lS5+rjRWdHHGmkQ==
Message-ID: <BC00F5384FCFC9499AF06F92E8B78A9E2870BB484D@shsmsx502.ccr.corp.intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "keir.xen@gmail.com" <keir.xen@gmail.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Jiang, Yunhong" <yunhong.jiang@intel.com>
Subject: [Xen-devel] [PATCH] X86 MCE: Add more strict sanity check of one
	SRAR case
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============5699344207312266240=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============5699344207312266240==
Content-Language: en-US
Content-Type: multipart/alternative;
	boundary="_000_BC00F5384FCFC9499AF06F92E8B78A9E2870BB484Dshsmsx502ccrc_"

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

Jan,

I cannot access my remote office desktop today (network maintain), so canno=
t reply the SRAR patch email we discussed last month.

At the last email we basically agree that the SRAR patch itself looks fine,=
 only with 1 concern about 'guest_mode' (in fact the SRAR patch itself didn=
't involved guest_mode), and the SRAR patch not in xen unstable tree yet.
Currently I still don't find out an alternative way to solve the guest_mode=
 issue, so in order to be safe I add this patch.
I think although it may be some overkilled, it's OK to keep it safe here, a=
fter all the SRAR case which RIPV =3D EIPV =3D 0 occur rarely.

Thanks,
Jinsong

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

X86 MCE: Add more strict sanity check of one SRAR case

When RIPV =3D EIPV =3D 0, it's a little bit tricky. It may be an asynchroni=
c error, currently we have no way to precisely locate whether the error occ=
ur at guest or hypervisor.
To avoid handling error in wrong way, we treat it as unrecovered.

Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>

# HG changeset patch
# Parent e758b1d928e3d663602741ddc7f55461e2187829

diff -r e758b1d928e3 xen/arch/x86/cpu/mcheck/mce_intel.c
--- a/xen/arch/x86/cpu/mcheck/mce_intel.c       Sun Oct 30 17:50:53 2011 -0=
800
+++ b/xen/arch/x86/cpu/mcheck/mce_intel.c       Fri Dec 02 15:16:52 2011 -0=
800
@@ -367,8 +367,18 @@
         return 0;

     gstatus =3D mca_rdmsr(MSR_IA32_MCG_STATUS);
-    /* Xen is not pre-emptible */
-    if ( !(gstatus & MCG_STATUS_RIPV) && !guest_mode(regs))
+
+    /*
+     * FIXME: When RIPV =3D EIPV =3D 0, it's a little bit tricky. It may b=
e an
+     * asynchronic error, currently we have no way to precisely locate
+     * whether the error occur at guest or hypervisor.
+     * To avoid handling error in wrong way, we treat it as unrecovered.
+     *
+     * Another unrecovered case is RIPV =3D 0 while in hypervisor
+     * since Xen is not pre-emptible.
+     */
+    if ( !(gstatus & MCG_STATUS_RIPV) &&
+        (!(gstatus & MCG_STATUS_EIPV) || !guest_mode(regs)) )
         return -1;

     return mce_action(regs, mctc) =3D=3D MCER_RESET ? -1 : 0;


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

<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3D"Generator" content=3D"Microsoft Exchange Server">
<!-- converted from rtf -->
<style><!-- .EmailQuote { margin-left: 1pt; padding-left: 4pt; border-left:=
 #800000 2px solid; } --></style>
</head>
<body>
<font face=3D"Calibri, sans-serif" size=3D"2">
<div style=3D"text-align: justify; ">Jan,</div>
<div style=3D"text-align: justify; "><font face=3D"Times New Roman, serif">=
&nbsp;</font></div>
<div style=3D"text-align: justify; ">I cannot access my remote office deskt=
op today (network maintain), so cannot reply the SRAR patch email we discus=
sed last month.</div>
<div style=3D"text-align: justify; "><font face=3D"Times New Roman, serif">=
&nbsp;</font></div>
<div style=3D"text-align: justify; ">At the last email we basically agree t=
hat the SRAR patch itself looks fine, only with 1 concern about &#8216;gues=
t_mode&#8217; (in fact the SRAR patch itself didn&#8217;t involved guest_mo=
de), and the SRAR patch not in xen unstable tree yet.</div>
<div style=3D"text-align: justify; ">Currently I still don&#8217;t find out=
 an alternative way to solve the guest_mode issue, so in order to be safe I=
 add this patch.</div>
<div style=3D"text-align: justify; ">I think although it may be some overki=
lled, it&#8217;s OK to keep it safe here, after all the SRAR case which RIP=
V =3D EIPV =3D 0 occur rarely.</div>
<div style=3D"text-align: justify; ">&nbsp;</div>
<div style=3D"text-align: justify; ">Thanks,</div>
<div style=3D"text-align: justify; ">Jinsong</div>
<div style=3D"text-align: justify; ">&nbsp;</div>
<div style=3D"text-align: justify; ">=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=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 style=3D"text-align: justify; "><font face=3D"Times New Roman, serif">=
&nbsp;</font></div>
<div style=3D"text-align: justify; ">X86 MCE: Add more strict sanity check =
of one SRAR case</div>
<div style=3D"text-align: justify; ">&nbsp;</div>
<div style=3D"text-align: justify; ">When RIPV =3D EIPV =3D 0, it's a littl=
e bit tricky. It may be an asynchronic error, currently we have no way to p=
recisely locate whether the error occur at guest or hypervisor.</div>
<div style=3D"text-align: justify; ">To avoid handling error in wrong way, =
we treat it as unrecovered.</div>
<div style=3D"text-align: justify; ">&nbsp;</div>
<div style=3D"text-align: justify; ">Signed-off-by: Liu, Jinsong &lt;jinson=
g.liu@intel.com&gt;</div>
<div style=3D"text-align: justify; ">Signed-off-by: Jan Beulich &lt;jbeulic=
h@suse.com&gt;</div>
<div style=3D"text-align: justify; ">&nbsp;</div>
<div style=3D"text-align: justify; "># HG changeset patch</div>
<div style=3D"text-align: justify; "># Parent e758b1d928e3d663602741ddc7f55=
461e2187829</div>
<div style=3D"text-align: justify; ">&nbsp;</div>
<div style=3D"text-align: justify; ">diff -r e758b1d928e3 xen/arch/x86/cpu/=
mcheck/mce_intel.c</div>
<div style=3D"text-align: justify; ">--- a/xen/arch/x86/cpu/mcheck/mce_inte=
l.c&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Sun Oct 30 17:50:53 2011 -0800</div=
>
<div style=3D"text-align: justify; ">&#43;&#43;&#43; b/xen/arch/x86/cpu/mch=
eck/mce_intel.c&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Fri Dec 02 15:16:52 201=
1 -0800</div>
<div style=3D"text-align: justify; ">@@ -367,8 &#43;367,18 @@</div>
<div style=3D"text-align: justify; ">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp; return 0;</div>
<div style=3D"text-align: justify; ">&nbsp;</div>
<div style=3D"text-align: justify; ">&nbsp;&nbsp;&nbsp;&nbsp; gstatus =3D m=
ca_rdmsr(MSR_IA32_MCG_STATUS);</div>
<div style=3D"text-align: justify; ">-&nbsp;&nbsp;&nbsp; /* Xen is not pre-=
emptible */</div>
<div style=3D"text-align: justify; ">-&nbsp;&nbsp;&nbsp; if ( !(gstatus &am=
p; MCG_STATUS_RIPV) &amp;&amp; !guest_mode(regs))</div>
<div style=3D"text-align: justify; ">&#43;</div>
<div style=3D"text-align: justify; ">&#43;&nbsp;&nbsp;&nbsp; /*</div>
<div style=3D"text-align: justify; ">&#43;&nbsp;&nbsp;&nbsp;&nbsp; * FIXME:=
 When RIPV =3D EIPV =3D 0, it's a little bit tricky. It may be an</div>
<div style=3D"text-align: justify; ">&#43;&nbsp;&nbsp;&nbsp;&nbsp; * asynch=
ronic error, currently we have no way to precisely locate</div>
<div style=3D"text-align: justify; ">&#43;&nbsp;&nbsp;&nbsp;&nbsp; * whethe=
r the error occur at guest or hypervisor.</div>
<div style=3D"text-align: justify; ">&#43;&nbsp;&nbsp;&nbsp;&nbsp; * To avo=
id handling error in wrong way, we treat it as unrecovered.</div>
<div style=3D"text-align: justify; ">&#43;&nbsp;&nbsp;&nbsp;&nbsp; *</div>
<div style=3D"text-align: justify; ">&#43;&nbsp;&nbsp;&nbsp;&nbsp; * Anothe=
r unrecovered case is RIPV =3D 0 while in hypervisor</div>
<div style=3D"text-align: justify; ">&#43;&nbsp;&nbsp;&nbsp;&nbsp; * since =
Xen is not pre-emptible.</div>
<div style=3D"text-align: justify; ">&#43;&nbsp;&nbsp;&nbsp;&nbsp; */</div>
<div style=3D"text-align: justify; ">&#43;&nbsp;&nbsp;&nbsp; if ( !(gstatus=
 &amp; MCG_STATUS_RIPV) &amp;&amp;</div>
<div style=3D"text-align: justify; ">&#43;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp; (!(gstatus &amp; MCG_STATUS_EIPV) || !guest_mode(regs)) )</div>
<div style=3D"text-align: justify; ">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp; return -1;</div>
<div style=3D"text-align: justify; ">&nbsp;</div>
<div style=3D"text-align: justify; ">&nbsp;&nbsp;&nbsp;&nbsp; return mce_ac=
tion(regs, mctc) =3D=3D MCER_RESET ? -1 : 0;</div>
<div style=3D"text-align: justify; "><font face=3D"Times New Roman, serif">=
&nbsp;</font></div>
</font>
</body>
</html>

--_000_BC00F5384FCFC9499AF06F92E8B78A9E2870BB484Dshsmsx502ccrc_--


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

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

--===============5699344207312266240==--


From xen-devel-bounces@lists.xensource.com Fri Dec 02 15:55:43 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 15:55:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWVSX-00055F-51; Fri, 02 Dec 2011 15:55:33 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1RWVSU-00054x-Vw
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 15:55:31 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1322841246!59240138!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDMwNDMyOQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10637 invoked from network); 2 Dec 2011 15:54:07 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-7.tower-27.messagelabs.com with SMTP;
	2 Dec 2011 15:54:07 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga101.fm.intel.com with ESMTP; 02 Dec 2011 07:54:53 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,284,1320652800"; d="scan'208,217";a="91588917"
Received: from pgsmsx601.gar.corp.intel.com ([10.221.43.69])
	by fmsmga001.fm.intel.com with ESMTP; 02 Dec 2011 07:54:52 -0800
Received: from pgsmsx102.gar.corp.intel.com (10.221.44.80) by
	pgsmsx601.gar.corp.intel.com (10.221.43.69) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Fri, 2 Dec 2011 23:54:51 +0800
Received: from shsmsx601.ccr.corp.intel.com (10.239.4.112) by
	PGSMSX102.gar.corp.intel.com (10.221.44.80) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Fri, 2 Dec 2011 23:54:51 +0800
Received: from shsmsx502.ccr.corp.intel.com ([10.239.4.96]) by
	shsmsx601.ccr.corp.intel.com ([10.239.4.112]) with mapi; Fri, 2 Dec 2011
	23:54:50 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: "jbeulich@suse.com" <jbeulich@suse.com>
Date: Fri, 2 Dec 2011 23:54:48 +0800
Thread-Topic: [PATCH] X86 MCE: Add more strict sanity check of one SRAR case
Thread-Index: AcyxCrgiOHzcBq2lS5+rjRWdHHGmkQ==
Message-ID: <BC00F5384FCFC9499AF06F92E8B78A9E2870BB484D@shsmsx502.ccr.corp.intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "keir.xen@gmail.com" <keir.xen@gmail.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Jiang, Yunhong" <yunhong.jiang@intel.com>
Subject: [Xen-devel] [PATCH] X86 MCE: Add more strict sanity check of one
	SRAR case
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============5699344207312266240=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============5699344207312266240==
Content-Language: en-US
Content-Type: multipart/alternative;
	boundary="_000_BC00F5384FCFC9499AF06F92E8B78A9E2870BB484Dshsmsx502ccrc_"

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

Jan,

I cannot access my remote office desktop today (network maintain), so canno=
t reply the SRAR patch email we discussed last month.

At the last email we basically agree that the SRAR patch itself looks fine,=
 only with 1 concern about 'guest_mode' (in fact the SRAR patch itself didn=
't involved guest_mode), and the SRAR patch not in xen unstable tree yet.
Currently I still don't find out an alternative way to solve the guest_mode=
 issue, so in order to be safe I add this patch.
I think although it may be some overkilled, it's OK to keep it safe here, a=
fter all the SRAR case which RIPV =3D EIPV =3D 0 occur rarely.

Thanks,
Jinsong

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

X86 MCE: Add more strict sanity check of one SRAR case

When RIPV =3D EIPV =3D 0, it's a little bit tricky. It may be an asynchroni=
c error, currently we have no way to precisely locate whether the error occ=
ur at guest or hypervisor.
To avoid handling error in wrong way, we treat it as unrecovered.

Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>

# HG changeset patch
# Parent e758b1d928e3d663602741ddc7f55461e2187829

diff -r e758b1d928e3 xen/arch/x86/cpu/mcheck/mce_intel.c
--- a/xen/arch/x86/cpu/mcheck/mce_intel.c       Sun Oct 30 17:50:53 2011 -0=
800
+++ b/xen/arch/x86/cpu/mcheck/mce_intel.c       Fri Dec 02 15:16:52 2011 -0=
800
@@ -367,8 +367,18 @@
         return 0;

     gstatus =3D mca_rdmsr(MSR_IA32_MCG_STATUS);
-    /* Xen is not pre-emptible */
-    if ( !(gstatus & MCG_STATUS_RIPV) && !guest_mode(regs))
+
+    /*
+     * FIXME: When RIPV =3D EIPV =3D 0, it's a little bit tricky. It may b=
e an
+     * asynchronic error, currently we have no way to precisely locate
+     * whether the error occur at guest or hypervisor.
+     * To avoid handling error in wrong way, we treat it as unrecovered.
+     *
+     * Another unrecovered case is RIPV =3D 0 while in hypervisor
+     * since Xen is not pre-emptible.
+     */
+    if ( !(gstatus & MCG_STATUS_RIPV) &&
+        (!(gstatus & MCG_STATUS_EIPV) || !guest_mode(regs)) )
         return -1;

     return mce_action(regs, mctc) =3D=3D MCER_RESET ? -1 : 0;


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

<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3D"Generator" content=3D"Microsoft Exchange Server">
<!-- converted from rtf -->
<style><!-- .EmailQuote { margin-left: 1pt; padding-left: 4pt; border-left:=
 #800000 2px solid; } --></style>
</head>
<body>
<font face=3D"Calibri, sans-serif" size=3D"2">
<div style=3D"text-align: justify; ">Jan,</div>
<div style=3D"text-align: justify; "><font face=3D"Times New Roman, serif">=
&nbsp;</font></div>
<div style=3D"text-align: justify; ">I cannot access my remote office deskt=
op today (network maintain), so cannot reply the SRAR patch email we discus=
sed last month.</div>
<div style=3D"text-align: justify; "><font face=3D"Times New Roman, serif">=
&nbsp;</font></div>
<div style=3D"text-align: justify; ">At the last email we basically agree t=
hat the SRAR patch itself looks fine, only with 1 concern about &#8216;gues=
t_mode&#8217; (in fact the SRAR patch itself didn&#8217;t involved guest_mo=
de), and the SRAR patch not in xen unstable tree yet.</div>
<div style=3D"text-align: justify; ">Currently I still don&#8217;t find out=
 an alternative way to solve the guest_mode issue, so in order to be safe I=
 add this patch.</div>
<div style=3D"text-align: justify; ">I think although it may be some overki=
lled, it&#8217;s OK to keep it safe here, after all the SRAR case which RIP=
V =3D EIPV =3D 0 occur rarely.</div>
<div style=3D"text-align: justify; ">&nbsp;</div>
<div style=3D"text-align: justify; ">Thanks,</div>
<div style=3D"text-align: justify; ">Jinsong</div>
<div style=3D"text-align: justify; ">&nbsp;</div>
<div style=3D"text-align: justify; ">=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=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 style=3D"text-align: justify; "><font face=3D"Times New Roman, serif">=
&nbsp;</font></div>
<div style=3D"text-align: justify; ">X86 MCE: Add more strict sanity check =
of one SRAR case</div>
<div style=3D"text-align: justify; ">&nbsp;</div>
<div style=3D"text-align: justify; ">When RIPV =3D EIPV =3D 0, it's a littl=
e bit tricky. It may be an asynchronic error, currently we have no way to p=
recisely locate whether the error occur at guest or hypervisor.</div>
<div style=3D"text-align: justify; ">To avoid handling error in wrong way, =
we treat it as unrecovered.</div>
<div style=3D"text-align: justify; ">&nbsp;</div>
<div style=3D"text-align: justify; ">Signed-off-by: Liu, Jinsong &lt;jinson=
g.liu@intel.com&gt;</div>
<div style=3D"text-align: justify; ">Signed-off-by: Jan Beulich &lt;jbeulic=
h@suse.com&gt;</div>
<div style=3D"text-align: justify; ">&nbsp;</div>
<div style=3D"text-align: justify; "># HG changeset patch</div>
<div style=3D"text-align: justify; "># Parent e758b1d928e3d663602741ddc7f55=
461e2187829</div>
<div style=3D"text-align: justify; ">&nbsp;</div>
<div style=3D"text-align: justify; ">diff -r e758b1d928e3 xen/arch/x86/cpu/=
mcheck/mce_intel.c</div>
<div style=3D"text-align: justify; ">--- a/xen/arch/x86/cpu/mcheck/mce_inte=
l.c&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Sun Oct 30 17:50:53 2011 -0800</div=
>
<div style=3D"text-align: justify; ">&#43;&#43;&#43; b/xen/arch/x86/cpu/mch=
eck/mce_intel.c&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Fri Dec 02 15:16:52 201=
1 -0800</div>
<div style=3D"text-align: justify; ">@@ -367,8 &#43;367,18 @@</div>
<div style=3D"text-align: justify; ">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp; return 0;</div>
<div style=3D"text-align: justify; ">&nbsp;</div>
<div style=3D"text-align: justify; ">&nbsp;&nbsp;&nbsp;&nbsp; gstatus =3D m=
ca_rdmsr(MSR_IA32_MCG_STATUS);</div>
<div style=3D"text-align: justify; ">-&nbsp;&nbsp;&nbsp; /* Xen is not pre-=
emptible */</div>
<div style=3D"text-align: justify; ">-&nbsp;&nbsp;&nbsp; if ( !(gstatus &am=
p; MCG_STATUS_RIPV) &amp;&amp; !guest_mode(regs))</div>
<div style=3D"text-align: justify; ">&#43;</div>
<div style=3D"text-align: justify; ">&#43;&nbsp;&nbsp;&nbsp; /*</div>
<div style=3D"text-align: justify; ">&#43;&nbsp;&nbsp;&nbsp;&nbsp; * FIXME:=
 When RIPV =3D EIPV =3D 0, it's a little bit tricky. It may be an</div>
<div style=3D"text-align: justify; ">&#43;&nbsp;&nbsp;&nbsp;&nbsp; * asynch=
ronic error, currently we have no way to precisely locate</div>
<div style=3D"text-align: justify; ">&#43;&nbsp;&nbsp;&nbsp;&nbsp; * whethe=
r the error occur at guest or hypervisor.</div>
<div style=3D"text-align: justify; ">&#43;&nbsp;&nbsp;&nbsp;&nbsp; * To avo=
id handling error in wrong way, we treat it as unrecovered.</div>
<div style=3D"text-align: justify; ">&#43;&nbsp;&nbsp;&nbsp;&nbsp; *</div>
<div style=3D"text-align: justify; ">&#43;&nbsp;&nbsp;&nbsp;&nbsp; * Anothe=
r unrecovered case is RIPV =3D 0 while in hypervisor</div>
<div style=3D"text-align: justify; ">&#43;&nbsp;&nbsp;&nbsp;&nbsp; * since =
Xen is not pre-emptible.</div>
<div style=3D"text-align: justify; ">&#43;&nbsp;&nbsp;&nbsp;&nbsp; */</div>
<div style=3D"text-align: justify; ">&#43;&nbsp;&nbsp;&nbsp; if ( !(gstatus=
 &amp; MCG_STATUS_RIPV) &amp;&amp;</div>
<div style=3D"text-align: justify; ">&#43;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp; (!(gstatus &amp; MCG_STATUS_EIPV) || !guest_mode(regs)) )</div>
<div style=3D"text-align: justify; ">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp; return -1;</div>
<div style=3D"text-align: justify; ">&nbsp;</div>
<div style=3D"text-align: justify; ">&nbsp;&nbsp;&nbsp;&nbsp; return mce_ac=
tion(regs, mctc) =3D=3D MCER_RESET ? -1 : 0;</div>
<div style=3D"text-align: justify; "><font face=3D"Times New Roman, serif">=
&nbsp;</font></div>
</font>
</body>
</html>

--_000_BC00F5384FCFC9499AF06F92E8B78A9E2870BB484Dshsmsx502ccrc_--


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

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

--===============5699344207312266240==--


From xen-devel-bounces@lists.xensource.com Fri Dec 02 16:05:47 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 16:05:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWVcA-0005tD-AQ; Fri, 02 Dec 2011 16:05:30 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RWVc8-0005t4-GM
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 16:05:28 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1322841886!3845245!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQyOTg=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13892 invoked from network); 2 Dec 2011 16:04:46 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-15.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 2 Dec 2011 16:04:46 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 02 Dec 2011 16:04:45 +0000
Message-Id: <4ED9052B0200007800065233@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 02 Dec 2011 16:04:43 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>
References: <CAFA7027.25E35%keir.xen@gmail.com>
	<4ED62C50.7060204@citrix.com> <4ED666D5.5060603@citrix.com>
	<4ED7522E0200007800064973@nat28.tlf.novell.com>
	<4ED74DAD.1040903@citrix.com>
	<4ED75E8402000078000649E6@nat28.tlf.novell.com>
	<4ED77347.6060200@citrix.com>
	<4ED787870200007800064B6F@nat28.tlf.novell.com>
	<4ED79722.7090404@citrix.com>
	<4ED7A8110200007800064C50@nat28.tlf.novell.com>
	<4ED7B5FF.2090305@citrix.com>
	<4ED894100200007800064FE3@nat28.tlf.novell.com>
	<4ED8C592.3010603@citrix.com> <4ED8EC80.9040701@citrix.com>
In-Reply-To: <4ED8EC80.9040701@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Keir Fraser <keir.xen@gmail.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] KEXEC: allocate crash note buffers at boot time v5
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

(Andrew, my previous reply dropped all Cc-s, but I'm re-sending not only
because of that - I also adjusted the first part of the response.)

>>> On 02.12.11 at 16:19, Andrew Cooper <andrew.cooper3@citrix.com> wrote:

I just had another look at the Dom0 side of things, and I fail to see why
you think moving this out of per-CPU data is necessary: All Dom0 does
with the provided info is set up the resource tree. The data doesn't get
stored for any post-boot use. What am I overlooking?

>+    /* In the case of still not having enough memory to allocate buffer room,
>+     * returning a range of 0,0 is still valid. */
>+    range->start = __pa((unsigned long)crash_notes[nr].start);
>+    range->size = crash_notes[nr].size;

Comment and implementation don't match - __pa(NULL) is not zero
(and the cast to 'unsigned long' is pointless afaict).

Jan



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

From xen-devel-bounces@lists.xensource.com Fri Dec 02 16:05:47 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 16:05:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWVcA-0005tD-AQ; Fri, 02 Dec 2011 16:05:30 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RWVc8-0005t4-GM
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 16:05:28 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1322841886!3845245!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQyOTg=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13892 invoked from network); 2 Dec 2011 16:04:46 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-15.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 2 Dec 2011 16:04:46 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 02 Dec 2011 16:04:45 +0000
Message-Id: <4ED9052B0200007800065233@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 02 Dec 2011 16:04:43 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>
References: <CAFA7027.25E35%keir.xen@gmail.com>
	<4ED62C50.7060204@citrix.com> <4ED666D5.5060603@citrix.com>
	<4ED7522E0200007800064973@nat28.tlf.novell.com>
	<4ED74DAD.1040903@citrix.com>
	<4ED75E8402000078000649E6@nat28.tlf.novell.com>
	<4ED77347.6060200@citrix.com>
	<4ED787870200007800064B6F@nat28.tlf.novell.com>
	<4ED79722.7090404@citrix.com>
	<4ED7A8110200007800064C50@nat28.tlf.novell.com>
	<4ED7B5FF.2090305@citrix.com>
	<4ED894100200007800064FE3@nat28.tlf.novell.com>
	<4ED8C592.3010603@citrix.com> <4ED8EC80.9040701@citrix.com>
In-Reply-To: <4ED8EC80.9040701@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Keir Fraser <keir.xen@gmail.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] KEXEC: allocate crash note buffers at boot time v5
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

(Andrew, my previous reply dropped all Cc-s, but I'm re-sending not only
because of that - I also adjusted the first part of the response.)

>>> On 02.12.11 at 16:19, Andrew Cooper <andrew.cooper3@citrix.com> wrote:

I just had another look at the Dom0 side of things, and I fail to see why
you think moving this out of per-CPU data is necessary: All Dom0 does
with the provided info is set up the resource tree. The data doesn't get
stored for any post-boot use. What am I overlooking?

>+    /* In the case of still not having enough memory to allocate buffer room,
>+     * returning a range of 0,0 is still valid. */
>+    range->start = __pa((unsigned long)crash_notes[nr].start);
>+    range->size = crash_notes[nr].size;

Comment and implementation don't match - __pa(NULL) is not zero
(and the cast to 'unsigned long' is pointless afaict).

Jan



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

From xen-devel-bounces@lists.xensource.com Fri Dec 02 16:11:52 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 16:11:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWVi4-00066j-41; Fri, 02 Dec 2011 16:11:36 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1RWVi2-00066X-Ss
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 16:11:35 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1322842251!5592061!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjg1NDY=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10742 invoked from network); 2 Dec 2011 16:10:53 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Dec 2011 16:10:53 -0000
X-IronPort-AV: E=Sophos;i="4.71,284,1320642000"; d="scan'208";a="172698722"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Dec 2011 11:10:51 -0500
Received: from [10.80.2.18] (10.80.2.18) by FTLPMAILMX01.citrite.net
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Fri, 2 Dec 2011
	11:10:51 -0500
Message-ID: <4ED8F88A.1080303@citrix.com>
Date: Fri, 2 Dec 2011 16:10:50 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.23) Gecko/20110921 Lightning/1.0b2 Thunderbird/3.1.15
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <CAFA7027.25E35%keir.xen@gmail.com> <4ED62C50.7060204@citrix.com>
	<4ED666D5.5060603@citrix.com>
	<4ED7522E0200007800064973@nat28.tlf.novell.com>
	<4ED74DAD.1040903@citrix.com>
	<4ED75E8402000078000649E6@nat28.tlf.novell.com>
	<4ED77347.6060200@citrix.com>
	<4ED787870200007800064B6F@nat28.tlf.novell.com>
	<4ED79722.7090404@citrix.com>
	<4ED7A8110200007800064C50@nat28.tlf.novell.com>
	<4ED7B5FF.2090305@citrix.com>
	<4ED894100200007800064FE3@nat28.tlf.novell.com>
	<4ED8C592.3010603@citrix.com> <4ED8EC80.9040701@citrix.com>
	<4ED9052B0200007800065233@nat28.tlf.novell.com>
In-Reply-To: <4ED9052B0200007800065233@nat28.tlf.novell.com>
X-Enigmail-Version: 1.1.2
Content-Type: multipart/mixed; boundary="------------000300070409050104000200"
Cc: Keir Fraser <keir.xen@gmail.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] KEXEC: allocate crash note buffers at boot time v
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--------------000300070409050104000200
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit

On 02/12/11 16:04, Jan Beulich wrote:
> (Andrew, my previous reply dropped all Cc-s, but I'm re-sending not only
> because of that - I also adjusted the first part of the response.)
>
>>>> On 02.12.11 at 16:19, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
> I just had another look at the Dom0 side of things, and I fail to see why
> you think moving this out of per-CPU data is necessary: All Dom0 does
> with the provided info is set up the resource tree. The data doesn't get
> stored for any post-boot use. What am I overlooking?

(for the benifit of the list)

/sbin/kexec opens /proc/iomem and parses the strings looking for "Crash
Note" and pulls the ranges out that way.  (It also assumes that the
lowest crash note is pcpu0 and so on, which is also something I will
work around in later notes changes).

>> +    /* In the case of still not having enough memory to allocate buffer room,
>> +     * returning a range of 0,0 is still valid. */
>> +    range->start = __pa((unsigned long)crash_notes[nr].start);
>> +    range->size = crash_notes[nr].size;
> Comment and implementation don't match - __pa(NULL) is not zero
> (and the cast to 'unsigned long' is pointless afaict).
> Jan

Very silly mistake on my behalf.  v6 is attached with that fixed.

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com


--------------000300070409050104000200
Content-Type: text/x-patch; name="KEXEC-setup-crash-notes-during-boot.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename="KEXEC-setup-crash-notes-during-boot.patch"

# HG changeset patch
# Parent b5ceec1ccccad6e79053a80820132303ff1e136f
KEXEC: Allocate crash notes on boot v6

Currently, the buffers for crash notes are allocated per CPU when a
KEXEC_CMD_kexec_get_range hypercall is made, referencing the CPU in
question.

Although it certainly works in general, there are a few edge case problems:

1) There appears to be no guarentee that dom0 will make this hypercall
   for each pcpu on the system.  There appears to be variable
   behaviour depending on how many cpus dom0 is compiled for, and how
   many vcpus Xen gives to dom0.

2) The allocation of these buffers occur at the whim of dom0.  While
   this is typically very early on dom0 boot, but not guarenteed.

3) It is possible (although not sensible) for a crash
   kernel to be loaded without these (or some of these) hypercalls
   being made. Under these circumstances, a crash would cause the
   crash note code path will suffer a slew of null pointer deferences.

4) If the hypercalls are made after late in the day, it is possible
   for the hypercall to return -ENOMEM.  As code tends to be more
   fragile once memory is enhausted, the likelyhood of us needing the
   crash kernel is greater.

In addition, my forthcoming code to support 32bit kdump kernels on
64bit Xen on large (>64GB) boxes will require some guarentees as to
where the crash note buffers are actually allocated in physical
memory.  This is far easier to sort out at boot time, rather than
after dom0 has been booted and potentially using the physical memory
required.

Therefore, allocate the crash note buffers at boot time.

Changes since v5:
 *  Fix silly mistake about returning a 0 range in kexec_get_cpu()

Changes since v4:

 *  Replace the current cpu crash note scheme of using void pointers
    and hand calculating the size each time is needed, by a range
    structure containing a pointer and a size.  This removes duplicate
    times where the size is calculated.
 *  Tweak kexec_get_cpu().  Don't fail if a cpu is offline because it
    may already have crash notes, and may be up by the time a crash
    happens.  Split the error conditions up to return ERANGE for an
    out-of-range cpu request rather than EINVAL.  Finally, returning a
    range of zeros is acceptable, so do this in preference to failing.

Changes since v3:

 *  Alter the spinlocks to avoid calling xmalloc/xfree while holding
    the lock.
 *  Tidy up the coding style used.

Changes since v2:

 *  Allocate crash_notes dynamically using nr_cpu_ids at boot time,
    rather than statically using NR_CPUS.
 *  Fix the incorrect use of signed integers for cpu id.
 *  Fix collateral damage to do_crashdump_trigger() and
    crashdump_trigger_handler caused by reordering sizeof_note() and
    setup_note()
 *  Tweak the issue about returing -ENOMEM from kexec_init_cpu_note().
    No functional change.
 *  Change kexec_get_cpu() to attempt to allocate crash note buffers
    in case we have more free memory now than when the pcpu came up.
 *  Now that there are two codepaths possibly allocating crash notes,
    protect the allocation itself with a spinlock.

Changes since v1:

 *  Use cpu hotplug notifiers to handle allocating of the notes
    buffers rather than assuming the boot state of cpus will be the
    same as the crash state.
 *  Move crash_notes from being per_cpu.  This is because the kdump
    kernel elf binary put in the crash area is hard coded to physical
    addresses which the dom0 kernel typically obtains at boot time.
    If a cpu is offlined, its buffer should not be deallocated because
    the kdump kernel would read junk when trying to get the crash
    notes.  Similarly, the same problem would occur if the cpu was
    re-onlined later and its crash notes buffer was allocated elsewhere.
 *  Only attempt to allocate buffers if a crash area has been
    specified.  Else, allocating crash note buffers is a waste of
    space.  Along with this, change the test in kexec_get_cpu to
    return -EINVAL if no buffers have been allocated.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

diff -r df7cec2c6c03 xen/common/kexec.c
--- a/xen/common/kexec.c
+++ b/xen/common/kexec.c
@@ -25,13 +25,19 @@
 #include <xen/kexec.h>
 #include <public/elfnote.h>
 #include <xsm/xsm.h>
+#include <xen/cpu.h>
 #ifdef CONFIG_COMPAT
 #include <compat/kexec.h>
 #endif
 
 bool_t kexecing = FALSE;
 
-static DEFINE_PER_CPU_READ_MOSTLY(void *, crash_notes);
+/* Memory regions to store the per cpu register state etc. on a crash. */
+typedef struct { Elf_Note * start; size_t size; } crash_note_range_t;
+static crash_note_range_t * crash_notes;
+
+/* Lock to prevent race conditions when allocating the crash note buffers. */
+static DEFINE_SPINLOCK(crash_notes_lock);
 
 static Elf_Note *xen_crash_note;
 
@@ -165,13 +171,17 @@ static void one_cpu_only(void)
 void kexec_crash_save_cpu(void)
 {
     int cpu = smp_processor_id();
-    Elf_Note *note = per_cpu(crash_notes, cpu);
+    Elf_Note *note;
     ELF_Prstatus *prstatus;
     crash_xen_core_t *xencore;
 
+    BUG_ON( ! crash_notes );
+
     if ( cpumask_test_and_set_cpu(cpu, &crash_saved_cpus) )
         return;
 
+    note = crash_notes[cpu].start;
+
     prstatus = (ELF_Prstatus *)ELFNOTE_DESC(note);
 
     note = ELFNOTE_NEXT(note);
@@ -257,13 +267,6 @@ static struct keyhandler crashdump_trigg
     .desc = "trigger a crashdump"
 };
 
-static __init int register_crashdump_trigger(void)
-{
-    register_keyhandler('C', &crashdump_trigger_keyhandler);
-    return 0;
-}
-__initcall(register_crashdump_trigger);
-
 static void setup_note(Elf_Note *n, const char *name, int type, int descsz)
 {
     int l = strlen(name) + 1;
@@ -280,6 +283,129 @@ static int sizeof_note(const char *name,
             ELFNOTE_ALIGN(descsz));
 }
 
+/* Allocate a crash note buffer for a newly onlined cpu. */
+static int kexec_init_cpu_notes(const unsigned long cpu)
+{
+    Elf_Note * note;
+    int ret = 0;
+    int nr_bytes = 0;
+
+    BUG_ON( cpu >= nr_cpu_ids || ! crash_notes );
+
+    /* If already allocated, nothing to do. */
+    if ( crash_notes[cpu].start )
+        return ret;
+
+    /* All CPUs present a PRSTATUS and crash_xen_core note. */
+    nr_bytes =
+        sizeof_note("CORE", sizeof(ELF_Prstatus)) +
+        sizeof_note("Xen", sizeof(crash_xen_core_t));
+
+    /* CPU0 also presents the crash_xen_info note. */
+    if ( ! cpu )
+        nr_bytes = nr_bytes +
+            sizeof_note("Xen", sizeof(crash_xen_info_t));
+
+    note = xmalloc_bytes(nr_bytes);
+
+    /* Protect the write into crash_notes[] with a spinlock, as this function
+     * is on a hotplug path and a hypercall path. */
+    spin_lock(&crash_notes_lock);
+
+    /* If we are racing with another CPU and it has beaten us, give up
+     * gracefully. */
+    if ( crash_notes[cpu].start )
+    {
+        spin_unlock(&crash_notes_lock);
+        /* Always return ok, because whether we successfully allocated or not,
+         * another CPU has successfully allocated. */
+        if ( note )
+            xfree(note);
+    }
+    else
+    {
+        crash_notes[cpu].start = note;
+        crash_notes[cpu].size = nr_bytes;
+        spin_unlock(&crash_notes_lock);
+
+        /* If the allocation failed, and another CPU did not beat us, give
+         * up with ENOMEM. */
+        if ( ! note )
+            ret = -ENOMEM;
+        /* else all is good so lets set up the notes. */
+        else
+        {
+            /* Set up CORE note. */
+            setup_note(note, "CORE", NT_PRSTATUS, sizeof(ELF_Prstatus));
+            note = ELFNOTE_NEXT(note);
+
+            /* Set up Xen CORE note. */
+            setup_note(note, "Xen", XEN_ELFNOTE_CRASH_REGS,
+                       sizeof(crash_xen_core_t));
+
+            if ( ! cpu )
+            {
+                /* Set up Xen Crash Info note. */
+                xen_crash_note = note = ELFNOTE_NEXT(note);
+                setup_note(note, "Xen", XEN_ELFNOTE_CRASH_INFO,
+                           sizeof(crash_xen_info_t));
+            }
+        }
+    }
+
+    return ret;
+}
+
+static int cpu_callback(
+    struct notifier_block *nfb, unsigned long action, void *hcpu)
+{
+    unsigned long cpu = (unsigned long)hcpu;
+
+    /* Only hook on CPU_UP_PREPARE because once a crash_note has been reported
+     * to dom0, it must keep it around in case of a crash, as the crash kernel
+     * will be hard coded to the original physical address reported. */
+    switch ( action )
+    {
+    case CPU_UP_PREPARE:
+        /* Ignore return value.  If this boot time, -ENOMEM will cause all
+         * manner of problems elsewhere very soon, and if it is during runtime,
+         * then failing to allocate crash notes is not a good enough reason to
+         * fail the CPU_UP_PREPARE */
+        kexec_init_cpu_notes(cpu);
+        break;
+    default:
+        break;
+    }
+    return NOTIFY_DONE;
+}
+
+static struct notifier_block cpu_nfb = {
+    .notifier_call = cpu_callback
+};
+
+static int __init kexec_init(void)
+{
+    void *cpu = (void *)(unsigned long)smp_processor_id();
+
+    /* If no crash area, no need to allocate space for notes. */
+    if ( !kexec_crash_area.size )
+        return 0;
+
+    register_keyhandler('C', &crashdump_trigger_keyhandler);
+
+    crash_notes = xzalloc_array(crash_note_range_t, nr_cpu_ids);
+    if ( ! crash_notes )
+        return -ENOMEM;
+
+    cpu_callback(&cpu_nfb, CPU_UP_PREPARE, cpu);
+    register_cpu_notifier(&cpu_nfb);
+    return 0;
+}
+/* The reason for this to be a presmp_initcall as opposed to a regular
+ * __initcall is to allow the setup of the cpu hotplug handler before APs are
+ * brought up. */
+presmp_initcall(kexec_init);
+
 static int kexec_get_reserve(xen_kexec_range_t *range)
 {
     if ( kexec_crash_area.size > 0 && kexec_crash_area.start > 0) {
@@ -294,44 +420,29 @@ static int kexec_get_reserve(xen_kexec_r
 static int kexec_get_cpu(xen_kexec_range_t *range)
 {
     int nr = range->nr;
-    int nr_bytes = 0;
 
-    if ( nr < 0 || nr >= nr_cpu_ids || !cpu_online(nr) )
+    if ( nr < 0 || nr >= nr_cpu_ids )
+        return -ERANGE;
+
+    if ( ! crash_notes )
         return -EINVAL;
 
-    nr_bytes += sizeof_note("CORE", sizeof(ELF_Prstatus));
-    nr_bytes += sizeof_note("Xen", sizeof(crash_xen_core_t));
+    /* Try once again to allocate room for the crash notes.  It is just possible
+     * that more space has become available since we last tried.  If space has
+     * already been allocated, kexec_init_cpu_notes() will return early with 0.
+     */
+    kexec_init_cpu_notes(nr);
 
-    /* The Xen info note is included in CPU0's range. */
-    if ( nr == 0 )
-        nr_bytes += sizeof_note("Xen", sizeof(crash_xen_info_t));
+    /* In the case of still not having enough memory to allocate buffer room,
+     * returning a range of 0,0 is still valid. */
+    if ( crash_notes[nr].start )
+    {
+        range->start = __pa(crash_notes[nr].start);
+        range->size = crash_notes[nr].size;
+    }
+    else
+        range->start = range->size = 0;
 
-    if ( per_cpu(crash_notes, nr) == NULL )
-    {
-        Elf_Note *note;
-
-        note = per_cpu(crash_notes, nr) = xmalloc_bytes(nr_bytes);
-
-        if ( note == NULL )
-            return -ENOMEM;
-
-        /* Setup CORE note. */
-        setup_note(note, "CORE", NT_PRSTATUS, sizeof(ELF_Prstatus));
-
-        /* Setup Xen CORE note. */
-        note = ELFNOTE_NEXT(note);
-        setup_note(note, "Xen", XEN_ELFNOTE_CRASH_REGS, sizeof(crash_xen_core_t));
-
-        if (nr == 0)
-        {
-            /* Setup system wide Xen info note. */
-            xen_crash_note = note = ELFNOTE_NEXT(note);
-            setup_note(note, "Xen", XEN_ELFNOTE_CRASH_INFO, sizeof(crash_xen_info_t));
-        }
-    }
-
-    range->start = __pa((unsigned long)per_cpu(crash_notes, nr));
-    range->size = nr_bytes;
     return 0;
 }
 

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

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

--------------000300070409050104000200--


From xen-devel-bounces@lists.xensource.com Fri Dec 02 16:11:52 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 16:11:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWVi4-00066j-41; Fri, 02 Dec 2011 16:11:36 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1RWVi2-00066X-Ss
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 16:11:35 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1322842251!5592061!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjg1NDY=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10742 invoked from network); 2 Dec 2011 16:10:53 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Dec 2011 16:10:53 -0000
X-IronPort-AV: E=Sophos;i="4.71,284,1320642000"; d="scan'208";a="172698722"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Dec 2011 11:10:51 -0500
Received: from [10.80.2.18] (10.80.2.18) by FTLPMAILMX01.citrite.net
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Fri, 2 Dec 2011
	11:10:51 -0500
Message-ID: <4ED8F88A.1080303@citrix.com>
Date: Fri, 2 Dec 2011 16:10:50 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.23) Gecko/20110921 Lightning/1.0b2 Thunderbird/3.1.15
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <CAFA7027.25E35%keir.xen@gmail.com> <4ED62C50.7060204@citrix.com>
	<4ED666D5.5060603@citrix.com>
	<4ED7522E0200007800064973@nat28.tlf.novell.com>
	<4ED74DAD.1040903@citrix.com>
	<4ED75E8402000078000649E6@nat28.tlf.novell.com>
	<4ED77347.6060200@citrix.com>
	<4ED787870200007800064B6F@nat28.tlf.novell.com>
	<4ED79722.7090404@citrix.com>
	<4ED7A8110200007800064C50@nat28.tlf.novell.com>
	<4ED7B5FF.2090305@citrix.com>
	<4ED894100200007800064FE3@nat28.tlf.novell.com>
	<4ED8C592.3010603@citrix.com> <4ED8EC80.9040701@citrix.com>
	<4ED9052B0200007800065233@nat28.tlf.novell.com>
In-Reply-To: <4ED9052B0200007800065233@nat28.tlf.novell.com>
X-Enigmail-Version: 1.1.2
Content-Type: multipart/mixed; boundary="------------000300070409050104000200"
Cc: Keir Fraser <keir.xen@gmail.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] KEXEC: allocate crash note buffers at boot time v
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--------------000300070409050104000200
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit

On 02/12/11 16:04, Jan Beulich wrote:
> (Andrew, my previous reply dropped all Cc-s, but I'm re-sending not only
> because of that - I also adjusted the first part of the response.)
>
>>>> On 02.12.11 at 16:19, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
> I just had another look at the Dom0 side of things, and I fail to see why
> you think moving this out of per-CPU data is necessary: All Dom0 does
> with the provided info is set up the resource tree. The data doesn't get
> stored for any post-boot use. What am I overlooking?

(for the benifit of the list)

/sbin/kexec opens /proc/iomem and parses the strings looking for "Crash
Note" and pulls the ranges out that way.  (It also assumes that the
lowest crash note is pcpu0 and so on, which is also something I will
work around in later notes changes).

>> +    /* In the case of still not having enough memory to allocate buffer room,
>> +     * returning a range of 0,0 is still valid. */
>> +    range->start = __pa((unsigned long)crash_notes[nr].start);
>> +    range->size = crash_notes[nr].size;
> Comment and implementation don't match - __pa(NULL) is not zero
> (and the cast to 'unsigned long' is pointless afaict).
> Jan

Very silly mistake on my behalf.  v6 is attached with that fixed.

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com


--------------000300070409050104000200
Content-Type: text/x-patch; name="KEXEC-setup-crash-notes-during-boot.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename="KEXEC-setup-crash-notes-during-boot.patch"

# HG changeset patch
# Parent b5ceec1ccccad6e79053a80820132303ff1e136f
KEXEC: Allocate crash notes on boot v6

Currently, the buffers for crash notes are allocated per CPU when a
KEXEC_CMD_kexec_get_range hypercall is made, referencing the CPU in
question.

Although it certainly works in general, there are a few edge case problems:

1) There appears to be no guarentee that dom0 will make this hypercall
   for each pcpu on the system.  There appears to be variable
   behaviour depending on how many cpus dom0 is compiled for, and how
   many vcpus Xen gives to dom0.

2) The allocation of these buffers occur at the whim of dom0.  While
   this is typically very early on dom0 boot, but not guarenteed.

3) It is possible (although not sensible) for a crash
   kernel to be loaded without these (or some of these) hypercalls
   being made. Under these circumstances, a crash would cause the
   crash note code path will suffer a slew of null pointer deferences.

4) If the hypercalls are made after late in the day, it is possible
   for the hypercall to return -ENOMEM.  As code tends to be more
   fragile once memory is enhausted, the likelyhood of us needing the
   crash kernel is greater.

In addition, my forthcoming code to support 32bit kdump kernels on
64bit Xen on large (>64GB) boxes will require some guarentees as to
where the crash note buffers are actually allocated in physical
memory.  This is far easier to sort out at boot time, rather than
after dom0 has been booted and potentially using the physical memory
required.

Therefore, allocate the crash note buffers at boot time.

Changes since v5:
 *  Fix silly mistake about returning a 0 range in kexec_get_cpu()

Changes since v4:

 *  Replace the current cpu crash note scheme of using void pointers
    and hand calculating the size each time is needed, by a range
    structure containing a pointer and a size.  This removes duplicate
    times where the size is calculated.
 *  Tweak kexec_get_cpu().  Don't fail if a cpu is offline because it
    may already have crash notes, and may be up by the time a crash
    happens.  Split the error conditions up to return ERANGE for an
    out-of-range cpu request rather than EINVAL.  Finally, returning a
    range of zeros is acceptable, so do this in preference to failing.

Changes since v3:

 *  Alter the spinlocks to avoid calling xmalloc/xfree while holding
    the lock.
 *  Tidy up the coding style used.

Changes since v2:

 *  Allocate crash_notes dynamically using nr_cpu_ids at boot time,
    rather than statically using NR_CPUS.
 *  Fix the incorrect use of signed integers for cpu id.
 *  Fix collateral damage to do_crashdump_trigger() and
    crashdump_trigger_handler caused by reordering sizeof_note() and
    setup_note()
 *  Tweak the issue about returing -ENOMEM from kexec_init_cpu_note().
    No functional change.
 *  Change kexec_get_cpu() to attempt to allocate crash note buffers
    in case we have more free memory now than when the pcpu came up.
 *  Now that there are two codepaths possibly allocating crash notes,
    protect the allocation itself with a spinlock.

Changes since v1:

 *  Use cpu hotplug notifiers to handle allocating of the notes
    buffers rather than assuming the boot state of cpus will be the
    same as the crash state.
 *  Move crash_notes from being per_cpu.  This is because the kdump
    kernel elf binary put in the crash area is hard coded to physical
    addresses which the dom0 kernel typically obtains at boot time.
    If a cpu is offlined, its buffer should not be deallocated because
    the kdump kernel would read junk when trying to get the crash
    notes.  Similarly, the same problem would occur if the cpu was
    re-onlined later and its crash notes buffer was allocated elsewhere.
 *  Only attempt to allocate buffers if a crash area has been
    specified.  Else, allocating crash note buffers is a waste of
    space.  Along with this, change the test in kexec_get_cpu to
    return -EINVAL if no buffers have been allocated.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

diff -r df7cec2c6c03 xen/common/kexec.c
--- a/xen/common/kexec.c
+++ b/xen/common/kexec.c
@@ -25,13 +25,19 @@
 #include <xen/kexec.h>
 #include <public/elfnote.h>
 #include <xsm/xsm.h>
+#include <xen/cpu.h>
 #ifdef CONFIG_COMPAT
 #include <compat/kexec.h>
 #endif
 
 bool_t kexecing = FALSE;
 
-static DEFINE_PER_CPU_READ_MOSTLY(void *, crash_notes);
+/* Memory regions to store the per cpu register state etc. on a crash. */
+typedef struct { Elf_Note * start; size_t size; } crash_note_range_t;
+static crash_note_range_t * crash_notes;
+
+/* Lock to prevent race conditions when allocating the crash note buffers. */
+static DEFINE_SPINLOCK(crash_notes_lock);
 
 static Elf_Note *xen_crash_note;
 
@@ -165,13 +171,17 @@ static void one_cpu_only(void)
 void kexec_crash_save_cpu(void)
 {
     int cpu = smp_processor_id();
-    Elf_Note *note = per_cpu(crash_notes, cpu);
+    Elf_Note *note;
     ELF_Prstatus *prstatus;
     crash_xen_core_t *xencore;
 
+    BUG_ON( ! crash_notes );
+
     if ( cpumask_test_and_set_cpu(cpu, &crash_saved_cpus) )
         return;
 
+    note = crash_notes[cpu].start;
+
     prstatus = (ELF_Prstatus *)ELFNOTE_DESC(note);
 
     note = ELFNOTE_NEXT(note);
@@ -257,13 +267,6 @@ static struct keyhandler crashdump_trigg
     .desc = "trigger a crashdump"
 };
 
-static __init int register_crashdump_trigger(void)
-{
-    register_keyhandler('C', &crashdump_trigger_keyhandler);
-    return 0;
-}
-__initcall(register_crashdump_trigger);
-
 static void setup_note(Elf_Note *n, const char *name, int type, int descsz)
 {
     int l = strlen(name) + 1;
@@ -280,6 +283,129 @@ static int sizeof_note(const char *name,
             ELFNOTE_ALIGN(descsz));
 }
 
+/* Allocate a crash note buffer for a newly onlined cpu. */
+static int kexec_init_cpu_notes(const unsigned long cpu)
+{
+    Elf_Note * note;
+    int ret = 0;
+    int nr_bytes = 0;
+
+    BUG_ON( cpu >= nr_cpu_ids || ! crash_notes );
+
+    /* If already allocated, nothing to do. */
+    if ( crash_notes[cpu].start )
+        return ret;
+
+    /* All CPUs present a PRSTATUS and crash_xen_core note. */
+    nr_bytes =
+        sizeof_note("CORE", sizeof(ELF_Prstatus)) +
+        sizeof_note("Xen", sizeof(crash_xen_core_t));
+
+    /* CPU0 also presents the crash_xen_info note. */
+    if ( ! cpu )
+        nr_bytes = nr_bytes +
+            sizeof_note("Xen", sizeof(crash_xen_info_t));
+
+    note = xmalloc_bytes(nr_bytes);
+
+    /* Protect the write into crash_notes[] with a spinlock, as this function
+     * is on a hotplug path and a hypercall path. */
+    spin_lock(&crash_notes_lock);
+
+    /* If we are racing with another CPU and it has beaten us, give up
+     * gracefully. */
+    if ( crash_notes[cpu].start )
+    {
+        spin_unlock(&crash_notes_lock);
+        /* Always return ok, because whether we successfully allocated or not,
+         * another CPU has successfully allocated. */
+        if ( note )
+            xfree(note);
+    }
+    else
+    {
+        crash_notes[cpu].start = note;
+        crash_notes[cpu].size = nr_bytes;
+        spin_unlock(&crash_notes_lock);
+
+        /* If the allocation failed, and another CPU did not beat us, give
+         * up with ENOMEM. */
+        if ( ! note )
+            ret = -ENOMEM;
+        /* else all is good so lets set up the notes. */
+        else
+        {
+            /* Set up CORE note. */
+            setup_note(note, "CORE", NT_PRSTATUS, sizeof(ELF_Prstatus));
+            note = ELFNOTE_NEXT(note);
+
+            /* Set up Xen CORE note. */
+            setup_note(note, "Xen", XEN_ELFNOTE_CRASH_REGS,
+                       sizeof(crash_xen_core_t));
+
+            if ( ! cpu )
+            {
+                /* Set up Xen Crash Info note. */
+                xen_crash_note = note = ELFNOTE_NEXT(note);
+                setup_note(note, "Xen", XEN_ELFNOTE_CRASH_INFO,
+                           sizeof(crash_xen_info_t));
+            }
+        }
+    }
+
+    return ret;
+}
+
+static int cpu_callback(
+    struct notifier_block *nfb, unsigned long action, void *hcpu)
+{
+    unsigned long cpu = (unsigned long)hcpu;
+
+    /* Only hook on CPU_UP_PREPARE because once a crash_note has been reported
+     * to dom0, it must keep it around in case of a crash, as the crash kernel
+     * will be hard coded to the original physical address reported. */
+    switch ( action )
+    {
+    case CPU_UP_PREPARE:
+        /* Ignore return value.  If this boot time, -ENOMEM will cause all
+         * manner of problems elsewhere very soon, and if it is during runtime,
+         * then failing to allocate crash notes is not a good enough reason to
+         * fail the CPU_UP_PREPARE */
+        kexec_init_cpu_notes(cpu);
+        break;
+    default:
+        break;
+    }
+    return NOTIFY_DONE;
+}
+
+static struct notifier_block cpu_nfb = {
+    .notifier_call = cpu_callback
+};
+
+static int __init kexec_init(void)
+{
+    void *cpu = (void *)(unsigned long)smp_processor_id();
+
+    /* If no crash area, no need to allocate space for notes. */
+    if ( !kexec_crash_area.size )
+        return 0;
+
+    register_keyhandler('C', &crashdump_trigger_keyhandler);
+
+    crash_notes = xzalloc_array(crash_note_range_t, nr_cpu_ids);
+    if ( ! crash_notes )
+        return -ENOMEM;
+
+    cpu_callback(&cpu_nfb, CPU_UP_PREPARE, cpu);
+    register_cpu_notifier(&cpu_nfb);
+    return 0;
+}
+/* The reason for this to be a presmp_initcall as opposed to a regular
+ * __initcall is to allow the setup of the cpu hotplug handler before APs are
+ * brought up. */
+presmp_initcall(kexec_init);
+
 static int kexec_get_reserve(xen_kexec_range_t *range)
 {
     if ( kexec_crash_area.size > 0 && kexec_crash_area.start > 0) {
@@ -294,44 +420,29 @@ static int kexec_get_reserve(xen_kexec_r
 static int kexec_get_cpu(xen_kexec_range_t *range)
 {
     int nr = range->nr;
-    int nr_bytes = 0;
 
-    if ( nr < 0 || nr >= nr_cpu_ids || !cpu_online(nr) )
+    if ( nr < 0 || nr >= nr_cpu_ids )
+        return -ERANGE;
+
+    if ( ! crash_notes )
         return -EINVAL;
 
-    nr_bytes += sizeof_note("CORE", sizeof(ELF_Prstatus));
-    nr_bytes += sizeof_note("Xen", sizeof(crash_xen_core_t));
+    /* Try once again to allocate room for the crash notes.  It is just possible
+     * that more space has become available since we last tried.  If space has
+     * already been allocated, kexec_init_cpu_notes() will return early with 0.
+     */
+    kexec_init_cpu_notes(nr);
 
-    /* The Xen info note is included in CPU0's range. */
-    if ( nr == 0 )
-        nr_bytes += sizeof_note("Xen", sizeof(crash_xen_info_t));
+    /* In the case of still not having enough memory to allocate buffer room,
+     * returning a range of 0,0 is still valid. */
+    if ( crash_notes[nr].start )
+    {
+        range->start = __pa(crash_notes[nr].start);
+        range->size = crash_notes[nr].size;
+    }
+    else
+        range->start = range->size = 0;
 
-    if ( per_cpu(crash_notes, nr) == NULL )
-    {
-        Elf_Note *note;
-
-        note = per_cpu(crash_notes, nr) = xmalloc_bytes(nr_bytes);
-
-        if ( note == NULL )
-            return -ENOMEM;
-
-        /* Setup CORE note. */
-        setup_note(note, "CORE", NT_PRSTATUS, sizeof(ELF_Prstatus));
-
-        /* Setup Xen CORE note. */
-        note = ELFNOTE_NEXT(note);
-        setup_note(note, "Xen", XEN_ELFNOTE_CRASH_REGS, sizeof(crash_xen_core_t));
-
-        if (nr == 0)
-        {
-            /* Setup system wide Xen info note. */
-            xen_crash_note = note = ELFNOTE_NEXT(note);
-            setup_note(note, "Xen", XEN_ELFNOTE_CRASH_INFO, sizeof(crash_xen_info_t));
-        }
-    }
-
-    range->start = __pa((unsigned long)per_cpu(crash_notes, nr));
-    range->size = nr_bytes;
     return 0;
 }
 

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

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

--------------000300070409050104000200--


From xen-devel-bounces@lists.xensource.com Fri Dec 02 16:12:24 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 16:12:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWViZ-00069T-9l; Fri, 02 Dec 2011 16:12:07 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RWViY-000698-5J
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 16:12:06 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1322842285!7287702!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQyOTg=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13876 invoked from network); 2 Dec 2011 16:11:25 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-2.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 2 Dec 2011 16:11:25 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 02 Dec 2011 16:11:24 +0000
Message-Id: <4ED906BA020000780006523E@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 02 Dec 2011 16:11:22 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Keir Fraser <keir.xen@gmail.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] KEXEC: allocate crash note buffers at boot time v5
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 02.12.11 at 16:59, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
> On 02/12/11 15:43, Jan Beulich wrote:
>> I just had another look at the Dom0 side of things, and I fail to see why
>> you think boot time allocation is necessary: All Dom0 does with the
>> provided info is set up the resource tree. The data doesn't get stored
>> for any post-boot use. What am I overlooking?
> 
> /sbin/kexec opens /proc/iomem and looks for "Crash note" and interprets
> the range values.  This is how it grabs the locations to pack into its
> magic binary package.

So how does the hotplug scenario then get handled on native? I can't
imagine they expect things to remain stable across CPU unplug and
re-activation.

Jan


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

From xen-devel-bounces@lists.xensource.com Fri Dec 02 16:12:24 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 16:12:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWViZ-00069T-9l; Fri, 02 Dec 2011 16:12:07 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RWViY-000698-5J
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 16:12:06 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1322842285!7287702!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQyOTg=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13876 invoked from network); 2 Dec 2011 16:11:25 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-2.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 2 Dec 2011 16:11:25 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 02 Dec 2011 16:11:24 +0000
Message-Id: <4ED906BA020000780006523E@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 02 Dec 2011 16:11:22 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Keir Fraser <keir.xen@gmail.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] KEXEC: allocate crash note buffers at boot time v5
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 02.12.11 at 16:59, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
> On 02/12/11 15:43, Jan Beulich wrote:
>> I just had another look at the Dom0 side of things, and I fail to see why
>> you think boot time allocation is necessary: All Dom0 does with the
>> provided info is set up the resource tree. The data doesn't get stored
>> for any post-boot use. What am I overlooking?
> 
> /sbin/kexec opens /proc/iomem and looks for "Crash note" and interprets
> the range values.  This is how it grabs the locations to pack into its
> magic binary package.

So how does the hotplug scenario then get handled on native? I can't
imagine they expect things to remain stable across CPU unplug and
re-activation.

Jan


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

From xen-devel-bounces@lists.xensource.com Fri Dec 02 16:18:43 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 16:18:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWVof-0006Ss-4H; Fri, 02 Dec 2011 16:18:25 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RWVoe-0006Sl-0J
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 16:18:24 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1322842662!5118831!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTg0Mw==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6481 invoked from network); 2 Dec 2011 16:17:42 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Dec 2011 16:17:42 -0000
X-IronPort-AV: E=Sophos;i="4.71,284,1320624000"; 
   d="scan'208";a="9255675"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Dec 2011 16:17:22 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 2 Dec 2011 16:17:22 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RWVne-0003GT-3I;
	Fri, 02 Dec 2011 16:17:22 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RWVnd-0006lO-Tb;
	Fri, 02 Dec 2011 16:17:22 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10244-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 2 Dec 2011 16:17:21 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10244: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

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

Regressions :-(

Tests which did not succeed and are blocking:
 build-amd64                   4 xen-build                 fail REGR. vs. 10201
 build-i386-oldkern            4 xen-build                 fail REGR. vs. 10201
 build-i386                    4 xen-build                 fail REGR. vs. 10201
 build-amd64-oldkern           4 xen-build                 fail REGR. vs. 10201

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-winxpsp3    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pv             1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl             1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pair           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win       1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-i386-i386-win            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-win         1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a

version targeted for testing:
 xen                  72f4e4cb7440
baseline version:
 xen                  62ff6a318c5d

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Anthony PERARD <anthony.perard@citrix.com>
  Brendan Cully <brendan@cs.ubc.ca>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@novell.com>
  Jan Beulich <jbeulich@suse.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Jonathan Davies <jonathan.davies@citrix.com>
  juergen.gross@ts.fujitsu.com
  Keir Fraser <keir@xen.org>
  Liu, Jinsong <jinsong.liu@intel.com>
  Olaf Hering <olaf@aepfle.de>
  Philipp Hahn <hahn@univention.de>
  Shriram Rajagopalan <rshriram@cs.ubc.ca>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang2 <wei.wang2@amd.com>
------------------------------------------------------------

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


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

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

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


Not pushing.

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

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

From xen-devel-bounces@lists.xensource.com Fri Dec 02 16:18:43 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 16:18:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWVof-0006Ss-4H; Fri, 02 Dec 2011 16:18:25 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RWVoe-0006Sl-0J
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 16:18:24 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1322842662!5118831!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTg0Mw==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6481 invoked from network); 2 Dec 2011 16:17:42 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Dec 2011 16:17:42 -0000
X-IronPort-AV: E=Sophos;i="4.71,284,1320624000"; 
   d="scan'208";a="9255675"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Dec 2011 16:17:22 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 2 Dec 2011 16:17:22 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RWVne-0003GT-3I;
	Fri, 02 Dec 2011 16:17:22 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RWVnd-0006lO-Tb;
	Fri, 02 Dec 2011 16:17:22 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10244-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 2 Dec 2011 16:17:21 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10244: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

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

Regressions :-(

Tests which did not succeed and are blocking:
 build-amd64                   4 xen-build                 fail REGR. vs. 10201
 build-i386-oldkern            4 xen-build                 fail REGR. vs. 10201
 build-i386                    4 xen-build                 fail REGR. vs. 10201
 build-amd64-oldkern           4 xen-build                 fail REGR. vs. 10201

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-winxpsp3    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pv             1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl             1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pair           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win       1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-i386-i386-win            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-win         1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a

version targeted for testing:
 xen                  72f4e4cb7440
baseline version:
 xen                  62ff6a318c5d

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Anthony PERARD <anthony.perard@citrix.com>
  Brendan Cully <brendan@cs.ubc.ca>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@novell.com>
  Jan Beulich <jbeulich@suse.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Jonathan Davies <jonathan.davies@citrix.com>
  juergen.gross@ts.fujitsu.com
  Keir Fraser <keir@xen.org>
  Liu, Jinsong <jinsong.liu@intel.com>
  Olaf Hering <olaf@aepfle.de>
  Philipp Hahn <hahn@univention.de>
  Shriram Rajagopalan <rshriram@cs.ubc.ca>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang2 <wei.wang2@amd.com>
------------------------------------------------------------

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


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

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

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


Not pushing.

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

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

From xen-devel-bounces@lists.xensource.com Fri Dec 02 16:30:15 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 16:30:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWVzp-0006e8-CP; Fri, 02 Dec 2011 16:29:57 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1RWVzn-0006e0-RP
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 16:29:56 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1322843352!6744714!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjg1NDY=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31108 invoked from network); 2 Dec 2011 16:29:14 -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 2011 16:29:14 -0000
X-IronPort-AV: E=Sophos;i="4.71,284,1320642000"; d="scan'208";a="172701767"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Dec 2011 11:27:56 -0500
Received: from [10.80.2.18] (10.80.2.18) by FTLPMAILMX01.citrite.net
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Fri, 2 Dec 2011
	11:27:55 -0500
Message-ID: <4ED8FC8A.7040002@citrix.com>
Date: Fri, 2 Dec 2011 16:27:54 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.23) Gecko/20110921 Lightning/1.0b2 Thunderbird/3.1.15
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <4ED906BA020000780006523E@nat28.tlf.novell.com>
In-Reply-To: <4ED906BA020000780006523E@nat28.tlf.novell.com>
X-Enigmail-Version: 1.1.2
Cc: Keir Fraser <keir.xen@gmail.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] KEXEC: allocate crash note buffers at boot time v5
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 02/12/11 16:11, Jan Beulich wrote:
>>>> On 02.12.11 at 16:59, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>> On 02/12/11 15:43, Jan Beulich wrote:
>>> I just had another look at the Dom0 side of things, and I fail to see why
>>> you think boot time allocation is necessary: All Dom0 does with the
>>> provided info is set up the resource tree. The data doesn't get stored
>>> for any post-boot use. What am I overlooking?
>> /sbin/kexec opens /proc/iomem and looks for "Crash note" and interprets
>> the range values.  This is how it grabs the locations to pack into its
>> magic binary package.
> So how does the hotplug scenario then get handled on native? I can't
> imagine they expect things to remain stable across CPU unplug and
> re-activation.
>
> Jan

I am not how (or even if) the hotplug condition is handled on native.  I
guess it depends on what is put into the resource tree on boot.  With my
patch, Xen will give crash areas for all pcpus up to nr_cpu_ids, which
covers all the cases.  The worst that will happen is that some crash
notes do not get written if certain cpus are offline at the time of a crash.

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com


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

From xen-devel-bounces@lists.xensource.com Fri Dec 02 16:30:15 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 16:30:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWVzp-0006e8-CP; Fri, 02 Dec 2011 16:29:57 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1RWVzn-0006e0-RP
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 16:29:56 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1322843352!6744714!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjg1NDY=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31108 invoked from network); 2 Dec 2011 16:29:14 -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 2011 16:29:14 -0000
X-IronPort-AV: E=Sophos;i="4.71,284,1320642000"; d="scan'208";a="172701767"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Dec 2011 11:27:56 -0500
Received: from [10.80.2.18] (10.80.2.18) by FTLPMAILMX01.citrite.net
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Fri, 2 Dec 2011
	11:27:55 -0500
Message-ID: <4ED8FC8A.7040002@citrix.com>
Date: Fri, 2 Dec 2011 16:27:54 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.23) Gecko/20110921 Lightning/1.0b2 Thunderbird/3.1.15
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <4ED906BA020000780006523E@nat28.tlf.novell.com>
In-Reply-To: <4ED906BA020000780006523E@nat28.tlf.novell.com>
X-Enigmail-Version: 1.1.2
Cc: Keir Fraser <keir.xen@gmail.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] KEXEC: allocate crash note buffers at boot time v5
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 02/12/11 16:11, Jan Beulich wrote:
>>>> On 02.12.11 at 16:59, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>> On 02/12/11 15:43, Jan Beulich wrote:
>>> I just had another look at the Dom0 side of things, and I fail to see why
>>> you think boot time allocation is necessary: All Dom0 does with the
>>> provided info is set up the resource tree. The data doesn't get stored
>>> for any post-boot use. What am I overlooking?
>> /sbin/kexec opens /proc/iomem and looks for "Crash note" and interprets
>> the range values.  This is how it grabs the locations to pack into its
>> magic binary package.
> So how does the hotplug scenario then get handled on native? I can't
> imagine they expect things to remain stable across CPU unplug and
> re-activation.
>
> Jan

I am not how (or even if) the hotplug condition is handled on native.  I
guess it depends on what is put into the resource tree on boot.  With my
patch, Xen will give crash areas for all pcpus up to nr_cpu_ids, which
covers all the cases.  The worst that will happen is that some crash
notes do not get written if certain cpus are offline at the time of a crash.

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com


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

From xen-devel-bounces@lists.xensource.com Fri Dec 02 16:31:19 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 16: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.xensource.com>)
	id 1RWW0t-0006iC-RH; Fri, 02 Dec 2011 16:31:03 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RWW0s-0006hS-8p
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 16:31:02 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-4.tower-174.messagelabs.com!1322843419!4026985!1
X-Originating-IP: [208.97.132.74]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi43NCA9PiAxNTg3NA==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12610 invoked from network); 2 Dec 2011 16:30:20 -0000
Received: from caiajhbdcahe.dreamhost.com (HELO homiemail-a19.g.dreamhost.com)
	(208.97.132.74) by server-4.tower-174.messagelabs.com with SMTP;
	2 Dec 2011 16:30:20 -0000
Received: from homiemail-a19.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTP id 321AC604061;
	Fri,  2 Dec 2011 08:30:19 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=JsPsCz4YxLqn6LN72L5PpiRO7owiAWaVIZh5KFs25sRG
	5ihzopdyWis25M0zBt5pf9Pep0pW2Gb5NyeKikUdwSmFd8LYbgB5Er6d/dvVpSAM
	WjpxWEQULxklokDIyVgNaXi6/yMn3NSW8OtIiz2oQwHsHb3worSzPXwnMZ7e6CM=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=8x/ytQ1JYsDSjITttiWVEECQMkY=; b=u9U8wMkV
	jcCcgjQFpg0xkro8Q8p94l71ogbKA206Bsd3VwOH2G3YKWhu+WtsfG91ZYSk5yPe
	nXli+tqe3T/0+SgnHXRlYSqvbFh8Iv1MwIOZBm3IaUCVqSgwl77HGT414MpaqM25
	2kgJDr6LllC4gI/CWG8vOWY1ztg+y3OI+jE=
Received: from webmail.lagarcavilla.org (ahfbbjcaiaae.dreamhost.com
	[75.119.208.4]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTPA id B12E5604078; 
	Fri,  2 Dec 2011 08:30:18 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP; Fri, 2 Dec 2011 08:30:19 -0800
Message-ID: <fa38d847359784f92a266c98b7855924.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20111201184616.GA17010@aepfle.de>
References: <mailman.3014.1322742146.12970.xen-devel@lists.xensource.com>
	<782967b2dc26ac23e527e33839e8336f.squirrel@webmail.lagarcavilla.org>
	<20111201184616.GA17010@aepfle.de>
Date: Fri, 2 Dec 2011 08:30:19 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Olaf Hering" <olaf@aepfle.de>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 2 of 4] xenpaging: use wait queues
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> On Thu, Dec 01, Andres Lagar-Cavilla wrote:
>
>> > +    spin_lock_init(&d->arch.hvm_domain.gfn_lock);
>> Probably gfn_lock should be replaced with a name a bit more expressive.
>
> Ok, perhaps paged_gfn_queue_lock?
>
>> That notwithstanding, it seems this lock only gets used in the mm layer.
>> If so, it should be declared as an mm_lock_t in arch/x86/mm-locks.h, and
>> subject to ordering constraints.
>
> Is that really needed? The lock is not taken recursivly. What would be
> the benefit of the mm_lock_t in this context? Thats not clear to me.
>
>> Both gfn_lock and the list of wait queues could be collapsed in a single
>> struct, so as to decrease pressure on the size of struct domain.
>
> The global lock allows to adjust the number of vcpus, but yes, maybe it
> can be moved into p2m_mem_paging_queue_head.
>
>
>> > +static struct p2m_mem_paging_queue *p2m_mem_paging_get_queue(struct
>> > domain *d, unsigned long gfn)
>> > +{
>> > +    struct p2m_mem_paging_queue_head *h;
>> > +    struct p2m_mem_paging_queue *q, *q_match, *q_free;
>> > +
>> > +    h = d->arch.hvm_domain.gfn_queue;
>> > +    q_match = q_free = NULL;
>> > +
>> > +    spin_lock(&d->arch.hvm_domain.gfn_lock);
>> > +
>> > +    list_for_each_entry(q, &h->list, list) {
>> "Hashing" the gfn ( i.e. gfn & ((1 << order_of_vcpus) - 1) ) and
>> starting
>> the linear scan from there would shortcut the common case of finding a
>> queued gfn.
>
> I will think about that, good point. Keeping the individual
> p2m_mem_paging_queue* in a flat list could be done.
>
>> Checking the p2m type of the gfn for paging in would make the search
>> O(1)
>> for the case in which the gfn is not queued.
>
> What type check do you mean? These functions are only called from
> within get_gfn_type_access() if p2m_is_paging.
>
>> > +/* Returns 0 if the gfn is still paged */
>> > +static int p2m_mem_paging_get_entry(mfn_t *mfn,
>> > +               struct p2m_domain *p2m, unsigned long gfn,
>> > +               p2m_type_t *t, p2m_access_t *a, p2m_query_t q,
>> > +               unsigned int *page_order)
>> > +{
>> > +    *mfn = p2m->get_entry(p2m, gfn, t, a, q, page_order);
>> This will be called in the wake up routine, and it will be racy against
>> any concurrent p2m updates.
>
> How is this different from the current code in get_gfn_type_access()?
> Is get_gfn_type_access() protected by any lock? I thought that only
> p2m_query is allowed to take the p2m_lock?
I proposed using get_gfn* not realizing that that would walk again into
the wait code, my bad. Points i, if you don't perform a lock-protected
access here then it'll have to be updated later.

And ...
>
>> > -        /* Evict will fail now, tag this request for pager */
>> > -        if ( p2mt == p2m_ram_paging_out )
>> > -            req.flags |= MEM_EVENT_FLAG_EVICT_FAIL;
>> > +    /* Forward the state only if gfn is in page-out path */
>> > +    if ( p2mt == p2m_ram_paging_out || p2mt == p2m_ram_paged ) {
>> > +        /* Ignore foreign requests to allow mmap in pager */
>> > +        if ( mfn_valid(mfn) && p2mt == p2m_ram_paging_out &&
>> v->domain ==
>> > d ) {
>> > +            /* Restore gfn because it is needed by guest before evict
>> */
>> > +            set_p2m_entry(p2m, gfn, mfn, PAGE_ORDER_4K,
>> > +                       paging_mode_log_dirty(d) ? p2m_ram_logdirty :
>> > p2m_ram_rw, a);
>> No event here to tell the pager to cancel its work?
>
> The pager is in the process of writing the gfn to disk after successful
> nomination. Its next step is the eviction, which will now fail because
> the p2mt is not p2m_ram_paging_out anymore. It is already prepared for
> that failure.
> The previous MEM_EVENT_FLAG_EVICT_FAIL was not needed in the first
> place.
Yes it was! The biggest source of overhead is I/O. Tell the pager to stop
I/O early. Otherwise, you've done the paging out I/O pointlessly, to find
out only when you try to finalize the eviction.

Andres

>
>> You're not just adding wait queues, but also short-cutting the state
>> machine of paging, which, whilst delicate, works quite well right now.
>> You
>> should definitely split that into two patches if possible.
>
> I think that can be done, yes.
>
>> And please keep in mind that there are pagers other than xenpaging, so
>> interface churn is a big headache for everyone, if unavoidable.
>
> There will be few changes in the interface in the near future to make it
> more robust.
>
>
>> >          mem_event_put_req_producers(d, &d->mem_event->paging);
>> These (mem_event_put_req_producers, foreign_producers) are the kinds of
>> things that are really confusing in the ring management side right now.
>
> You are right, the names should be changed in the patched for mem_event.
>
> Olaf
>



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

From xen-devel-bounces@lists.xensource.com Fri Dec 02 16:31:19 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 16: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.xensource.com>)
	id 1RWW0t-0006iC-RH; Fri, 02 Dec 2011 16:31:03 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RWW0s-0006hS-8p
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 16:31:02 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-4.tower-174.messagelabs.com!1322843419!4026985!1
X-Originating-IP: [208.97.132.74]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi43NCA9PiAxNTg3NA==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12610 invoked from network); 2 Dec 2011 16:30:20 -0000
Received: from caiajhbdcahe.dreamhost.com (HELO homiemail-a19.g.dreamhost.com)
	(208.97.132.74) by server-4.tower-174.messagelabs.com with SMTP;
	2 Dec 2011 16:30:20 -0000
Received: from homiemail-a19.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTP id 321AC604061;
	Fri,  2 Dec 2011 08:30:19 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=JsPsCz4YxLqn6LN72L5PpiRO7owiAWaVIZh5KFs25sRG
	5ihzopdyWis25M0zBt5pf9Pep0pW2Gb5NyeKikUdwSmFd8LYbgB5Er6d/dvVpSAM
	WjpxWEQULxklokDIyVgNaXi6/yMn3NSW8OtIiz2oQwHsHb3worSzPXwnMZ7e6CM=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=8x/ytQ1JYsDSjITttiWVEECQMkY=; b=u9U8wMkV
	jcCcgjQFpg0xkro8Q8p94l71ogbKA206Bsd3VwOH2G3YKWhu+WtsfG91ZYSk5yPe
	nXli+tqe3T/0+SgnHXRlYSqvbFh8Iv1MwIOZBm3IaUCVqSgwl77HGT414MpaqM25
	2kgJDr6LllC4gI/CWG8vOWY1ztg+y3OI+jE=
Received: from webmail.lagarcavilla.org (ahfbbjcaiaae.dreamhost.com
	[75.119.208.4]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTPA id B12E5604078; 
	Fri,  2 Dec 2011 08:30:18 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP; Fri, 2 Dec 2011 08:30:19 -0800
Message-ID: <fa38d847359784f92a266c98b7855924.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20111201184616.GA17010@aepfle.de>
References: <mailman.3014.1322742146.12970.xen-devel@lists.xensource.com>
	<782967b2dc26ac23e527e33839e8336f.squirrel@webmail.lagarcavilla.org>
	<20111201184616.GA17010@aepfle.de>
Date: Fri, 2 Dec 2011 08:30:19 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Olaf Hering" <olaf@aepfle.de>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 2 of 4] xenpaging: use wait queues
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> On Thu, Dec 01, Andres Lagar-Cavilla wrote:
>
>> > +    spin_lock_init(&d->arch.hvm_domain.gfn_lock);
>> Probably gfn_lock should be replaced with a name a bit more expressive.
>
> Ok, perhaps paged_gfn_queue_lock?
>
>> That notwithstanding, it seems this lock only gets used in the mm layer.
>> If so, it should be declared as an mm_lock_t in arch/x86/mm-locks.h, and
>> subject to ordering constraints.
>
> Is that really needed? The lock is not taken recursivly. What would be
> the benefit of the mm_lock_t in this context? Thats not clear to me.
>
>> Both gfn_lock and the list of wait queues could be collapsed in a single
>> struct, so as to decrease pressure on the size of struct domain.
>
> The global lock allows to adjust the number of vcpus, but yes, maybe it
> can be moved into p2m_mem_paging_queue_head.
>
>
>> > +static struct p2m_mem_paging_queue *p2m_mem_paging_get_queue(struct
>> > domain *d, unsigned long gfn)
>> > +{
>> > +    struct p2m_mem_paging_queue_head *h;
>> > +    struct p2m_mem_paging_queue *q, *q_match, *q_free;
>> > +
>> > +    h = d->arch.hvm_domain.gfn_queue;
>> > +    q_match = q_free = NULL;
>> > +
>> > +    spin_lock(&d->arch.hvm_domain.gfn_lock);
>> > +
>> > +    list_for_each_entry(q, &h->list, list) {
>> "Hashing" the gfn ( i.e. gfn & ((1 << order_of_vcpus) - 1) ) and
>> starting
>> the linear scan from there would shortcut the common case of finding a
>> queued gfn.
>
> I will think about that, good point. Keeping the individual
> p2m_mem_paging_queue* in a flat list could be done.
>
>> Checking the p2m type of the gfn for paging in would make the search
>> O(1)
>> for the case in which the gfn is not queued.
>
> What type check do you mean? These functions are only called from
> within get_gfn_type_access() if p2m_is_paging.
>
>> > +/* Returns 0 if the gfn is still paged */
>> > +static int p2m_mem_paging_get_entry(mfn_t *mfn,
>> > +               struct p2m_domain *p2m, unsigned long gfn,
>> > +               p2m_type_t *t, p2m_access_t *a, p2m_query_t q,
>> > +               unsigned int *page_order)
>> > +{
>> > +    *mfn = p2m->get_entry(p2m, gfn, t, a, q, page_order);
>> This will be called in the wake up routine, and it will be racy against
>> any concurrent p2m updates.
>
> How is this different from the current code in get_gfn_type_access()?
> Is get_gfn_type_access() protected by any lock? I thought that only
> p2m_query is allowed to take the p2m_lock?
I proposed using get_gfn* not realizing that that would walk again into
the wait code, my bad. Points i, if you don't perform a lock-protected
access here then it'll have to be updated later.

And ...
>
>> > -        /* Evict will fail now, tag this request for pager */
>> > -        if ( p2mt == p2m_ram_paging_out )
>> > -            req.flags |= MEM_EVENT_FLAG_EVICT_FAIL;
>> > +    /* Forward the state only if gfn is in page-out path */
>> > +    if ( p2mt == p2m_ram_paging_out || p2mt == p2m_ram_paged ) {
>> > +        /* Ignore foreign requests to allow mmap in pager */
>> > +        if ( mfn_valid(mfn) && p2mt == p2m_ram_paging_out &&
>> v->domain ==
>> > d ) {
>> > +            /* Restore gfn because it is needed by guest before evict
>> */
>> > +            set_p2m_entry(p2m, gfn, mfn, PAGE_ORDER_4K,
>> > +                       paging_mode_log_dirty(d) ? p2m_ram_logdirty :
>> > p2m_ram_rw, a);
>> No event here to tell the pager to cancel its work?
>
> The pager is in the process of writing the gfn to disk after successful
> nomination. Its next step is the eviction, which will now fail because
> the p2mt is not p2m_ram_paging_out anymore. It is already prepared for
> that failure.
> The previous MEM_EVENT_FLAG_EVICT_FAIL was not needed in the first
> place.
Yes it was! The biggest source of overhead is I/O. Tell the pager to stop
I/O early. Otherwise, you've done the paging out I/O pointlessly, to find
out only when you try to finalize the eviction.

Andres

>
>> You're not just adding wait queues, but also short-cutting the state
>> machine of paging, which, whilst delicate, works quite well right now.
>> You
>> should definitely split that into two patches if possible.
>
> I think that can be done, yes.
>
>> And please keep in mind that there are pagers other than xenpaging, so
>> interface churn is a big headache for everyone, if unavoidable.
>
> There will be few changes in the interface in the near future to make it
> more robust.
>
>
>> >          mem_event_put_req_producers(d, &d->mem_event->paging);
>> These (mem_event_put_req_producers, foreign_producers) are the kinds of
>> things that are really confusing in the ring management side right now.
>
> You are right, the names should be changed in the patched for mem_event.
>
> Olaf
>



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

From xen-devel-bounces@lists.xensource.com Fri Dec 02 16:34:13 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 16:34:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWW3g-0006xK-Dw; Fri, 02 Dec 2011 16:33:56 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RWW3f-0006xA-84
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 16:33:55 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-10.tower-27.messagelabs.com!1322843562!46370677!1
X-Originating-IP: [208.97.132.177]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNzcgPT4gMTYwOTQ=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26737 invoked from network); 2 Dec 2011 16:32:43 -0000
Received: from caiajhbdcbhh.dreamhost.com (HELO homiemail-a75.g.dreamhost.com)
	(208.97.132.177) by server-10.tower-27.messagelabs.com with SMTP;
	2 Dec 2011 16:32:43 -0000
Received: from homiemail-a75.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a75.g.dreamhost.com (Postfix) with ESMTP id 358EB5EC079;
	Fri,  2 Dec 2011 08:33:18 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=n/djBPItaDT7lxNhrnNS6HPVHvzXy+zgjSONwAkyb+mN
	5CQY0WDELLobA7CmPIxzmnEZjDThiEun1+TCe70ChGWz63iG8u/5vsrPcGL0kusU
	YY0PIrPrhDp6tGokkweuzcv5FEYbgvU2fOu4Fqu8jR+H9PC6NN2EElXszjXg8gU=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=iVSMMgBUvrjvHux5xkeW6yVjzI0=; b=UDkhA4Ck
	hPzWfDDNZFNqe5Oj0zDOsfRUyL0Z3wuSFgunqkwWhvWXmmU67PiDp4yoNqgyNM9Q
	kiSsbZypPSPkRaI894Qtc8Yrct6xMruFlRCgiC0xkoY1Ilrpeszr9gMlenDx48Q6
	IJ57wKXVHB/ih1ykfEqEsYhQBHHsltWZ8oI=
Received: from webmail.lagarcavilla.org (ahfbbjcaiaae.dreamhost.com
	[75.119.208.4]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a75.g.dreamhost.com (Postfix) with ESMTPA id 5EBB65EC07E; 
	Fri,  2 Dec 2011 08:33:17 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP; Fri, 2 Dec 2011 08:33:18 -0800
Message-ID: <69fe17d8abdcb35630a0709166c85026.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20111201135916.GB61203@ocelot.phlegethon.org>
References: <patchbomb.1320788543@xdev.gridcentric.ca>
	<6203a0549d8a1a21753b.1320788545@xdev.gridcentric.ca>
	<20111110125342.GG62117@ocelot.phlegethon.org>
	<4cb5acd8fa013dc40d5063d61296a319.squirrel@webmail.lagarcavilla.org>
	<20111124113507.GA77868@ocelot.phlegethon.org>
	<180057def2be9bc8eb519865f17aca96.squirrel@webmail.lagarcavilla.org>
	<20111201135916.GB61203@ocelot.phlegethon.org>
Date: Fri, 2 Dec 2011 08:33:18 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Tim Deegan" <tim@xen.org>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: olaf@aepfle.de, xen-devel@lists.xensource.com, george.dunlap@eu.citrix.com,
	andres@gridcentric.ca, keir.xen@gmail.com,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 2 of 3] Make p2m lookups fully synchronized
 wrt modifications
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> At 08:41 -0800 on 24 Nov (1322124101), Andres Lagar-Cavilla wrote:
>> Here is one solution to consider: do not lock the p2m on lookups in
>> shadow
>> mode. Shadow mode does not support paging out and sharing of pages,
>> which
>> are primary reasons why we want synchronized p2m lookups. The hap cases
>> where there is an inversion of the p2m_lock -> paging_lock order are
>> reasonably simple to handle.
>>
>> The other option is to invert the order and place paging_lock ->
>> p2m_lock,
>> but that will raise another set of potential inversions. I think this is
>> a
>> no go.
>
> Is there scope for having the p2m lock split out into the overall one
> (needed for allocations &c) and the per-record ones, and have them at
> different levels in the lock hierarchy?
I think it's saner to go with one big lock and then shard it if we run
into performance problems. Your proposal, actually :)

Now, I'm thinking of splitting ... the paging lock. It covers way too much
ground right now, and many of these inversions would become more
tractable. Thinking of paging_alloc_lock, paging_logdirty_lock,
paging_lock.

Thanks,
Andres
>
> Tim.
>



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

From xen-devel-bounces@lists.xensource.com Fri Dec 02 16:34:13 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 16:34:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWW3g-0006xK-Dw; Fri, 02 Dec 2011 16:33:56 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RWW3f-0006xA-84
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 16:33:55 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-10.tower-27.messagelabs.com!1322843562!46370677!1
X-Originating-IP: [208.97.132.177]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNzcgPT4gMTYwOTQ=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26737 invoked from network); 2 Dec 2011 16:32:43 -0000
Received: from caiajhbdcbhh.dreamhost.com (HELO homiemail-a75.g.dreamhost.com)
	(208.97.132.177) by server-10.tower-27.messagelabs.com with SMTP;
	2 Dec 2011 16:32:43 -0000
Received: from homiemail-a75.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a75.g.dreamhost.com (Postfix) with ESMTP id 358EB5EC079;
	Fri,  2 Dec 2011 08:33:18 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=n/djBPItaDT7lxNhrnNS6HPVHvzXy+zgjSONwAkyb+mN
	5CQY0WDELLobA7CmPIxzmnEZjDThiEun1+TCe70ChGWz63iG8u/5vsrPcGL0kusU
	YY0PIrPrhDp6tGokkweuzcv5FEYbgvU2fOu4Fqu8jR+H9PC6NN2EElXszjXg8gU=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=iVSMMgBUvrjvHux5xkeW6yVjzI0=; b=UDkhA4Ck
	hPzWfDDNZFNqe5Oj0zDOsfRUyL0Z3wuSFgunqkwWhvWXmmU67PiDp4yoNqgyNM9Q
	kiSsbZypPSPkRaI894Qtc8Yrct6xMruFlRCgiC0xkoY1Ilrpeszr9gMlenDx48Q6
	IJ57wKXVHB/ih1ykfEqEsYhQBHHsltWZ8oI=
Received: from webmail.lagarcavilla.org (ahfbbjcaiaae.dreamhost.com
	[75.119.208.4]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a75.g.dreamhost.com (Postfix) with ESMTPA id 5EBB65EC07E; 
	Fri,  2 Dec 2011 08:33:17 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP; Fri, 2 Dec 2011 08:33:18 -0800
Message-ID: <69fe17d8abdcb35630a0709166c85026.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20111201135916.GB61203@ocelot.phlegethon.org>
References: <patchbomb.1320788543@xdev.gridcentric.ca>
	<6203a0549d8a1a21753b.1320788545@xdev.gridcentric.ca>
	<20111110125342.GG62117@ocelot.phlegethon.org>
	<4cb5acd8fa013dc40d5063d61296a319.squirrel@webmail.lagarcavilla.org>
	<20111124113507.GA77868@ocelot.phlegethon.org>
	<180057def2be9bc8eb519865f17aca96.squirrel@webmail.lagarcavilla.org>
	<20111201135916.GB61203@ocelot.phlegethon.org>
Date: Fri, 2 Dec 2011 08:33:18 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Tim Deegan" <tim@xen.org>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: olaf@aepfle.de, xen-devel@lists.xensource.com, george.dunlap@eu.citrix.com,
	andres@gridcentric.ca, keir.xen@gmail.com,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 2 of 3] Make p2m lookups fully synchronized
 wrt modifications
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> At 08:41 -0800 on 24 Nov (1322124101), Andres Lagar-Cavilla wrote:
>> Here is one solution to consider: do not lock the p2m on lookups in
>> shadow
>> mode. Shadow mode does not support paging out and sharing of pages,
>> which
>> are primary reasons why we want synchronized p2m lookups. The hap cases
>> where there is an inversion of the p2m_lock -> paging_lock order are
>> reasonably simple to handle.
>>
>> The other option is to invert the order and place paging_lock ->
>> p2m_lock,
>> but that will raise another set of potential inversions. I think this is
>> a
>> no go.
>
> Is there scope for having the p2m lock split out into the overall one
> (needed for allocations &c) and the per-record ones, and have them at
> different levels in the lock hierarchy?
I think it's saner to go with one big lock and then shard it if we run
into performance problems. Your proposal, actually :)

Now, I'm thinking of splitting ... the paging lock. It covers way too much
ground right now, and many of these inversions would become more
tractable. Thinking of paging_alloc_lock, paging_logdirty_lock,
paging_lock.

Thanks,
Andres
>
> Tim.
>



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

From xen-devel-bounces@lists.xensource.com Fri Dec 02 16:37:57 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 16:37:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWW7K-0007BE-3L; Fri, 02 Dec 2011 16:37:42 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <alex@alex.org.uk>) id 1RWW7I-0007B1-AV
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 16:37:40 +0000
X-Env-Sender: alex@alex.org.uk
X-Msg-Ref: server-8.tower-21.messagelabs.com!1322843819!6687824!1
X-Originating-IP: [89.16.176.221]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12025 invoked from network); 2 Dec 2011 16:36:59 -0000
Received: from mail.avalus.com (HELO mail.avalus.com) (89.16.176.221)
	by server-8.tower-21.messagelabs.com with SMTP;
	2 Dec 2011 16:36:59 -0000
Received: from [192.168.100.15] (87-194-71-186.bethere.co.uk [87.194.71.186])
	by mail.avalus.com (Postfix) with ESMTPSA id 95404C560FE;
	Fri,  2 Dec 2011 16:36:57 +0000 (GMT)
Date: Fri, 02 Dec 2011 16:36:56 +0000
From: Alex Bligh <alex@alex.org.uk>
To: =?UTF-8?Q?Pasi_K=C3=A4rkk=C3=A4inen?= <pasik@iki.fi>,
	Stefan Bader <stefan.bader@canonical.com>
Message-ID: <BA1B675D85BDD87795D1666C@Ximines.local>
In-Reply-To: <20111202104110.GL12984@reaktio.net>
References: <4ED798B2.1040309@canonical.com>
	<20111201180944.GH12984@reaktio.net>	<4ED8A45A.3050403@canonical.com>
	<20111202104110.GL12984@reaktio.net>
X-Mailer: Mulberry/4.0.8 (Mac OS X)
MIME-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com, Ian Campbell <ian.campbell@citrix.com>,
	Alex Bligh <alex@alex.org.uk>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Xen 4.x / Linux 3.x (dom0 and HVM domU)
 and	NIC	handling
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Alex Bligh <alex@alex.org.uk>
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: base64
Content-Type: text/plain; charset="utf-8"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

CgotLU9uIDIgRGVjZW1iZXIgMjAxMSAxMjo0MToxMCArMDIwMCBQYXNpIEvDpHJra8OkaW5lbiA8
cGFzaWtAaWtpLmZpPiB3cm90ZToKCj4+IEFuZCB0aGVuLCBvayB0aGlzIGlzIHByb2JhYmx5IGEg
cXVpdGUgbmFpdmUgYXBwcm9hY2gsIGl0IHNlZW1lZCB0byBtYWtlCj4+IHNlbnNlIHRvIGdvIHRo
cm91Z2ggdGhlIHBhaW4gb2YgYWx3YXlzIGhhdmluZyBwb3RlbnRpYWxseSBib3RoCj4+IGludGVy
ZmFjZXMgYXZhaWxhYmxlIChlbXVsYXRlZCBhbmQgcHYpIHNvIGluIHRoZW9yeSB0aGUgc2FtZSBn
dWVzdAo+PiBjb25maWcgY2FuIGFjY29tbW9kYXRlIGEgZ3Vlc3Qgb3Mgc3VwcG9ydGluZyBvbmUg
b3IgdGhlIG90aGVyIChvciBlYXNpbHkKPj4gc3dpdGNoIGZyb20gb25lIHRvIHRoZSBvdGhlciku
IE90aGVyd2lzZSBJIHdvdWxkIGV4cGVjdCBhbiBlbXVsYXRlZAo+PiBkZXZpY2Ugb25seSB3aGVu
IEkgaGF2ZSBoZD8gaW4gdGhlIGNvbmZpZyBhbmQgYSBwdiBkZXZpY2Ugd2hlbiBJIHdyaXRlCj4+
IHh2ZD8uCj4+Cj4KPiBUaGlzIHdvcmtzIGZvciBib3RoIEhWTSBhbmQgUFZIVk0gKGFsc28gbWVu
dGlvbmVkIG9uIHRoZSB3aWtpIHBhZ2UpOgo+IHZpZiA9IFsgJ21hYz0wMDoxNjo1ZTowMjowNzo0
NSwgYnJpZGdlPXhlbmJyMCwgbW9kZWw9ZTEwMDAnIF0KPgo+IFNvIHRoZXJlJ3Mgbm8gbmVlZCBm
b3IgInR5cGU9aW9lbXUiIG9wdGlvbiB3aXRoIHhtL3hlbmQuCj4KPiBZb3UgY2FuIHN3aXRjaCBi
ZXR3ZWVuIEhWTSBhbmQgUFZIVk0gd2l0aDoKPiB4ZW5fcGxhdGZvcm1fcGNpPTB8MQoKQUZBSUsg
Y2hhbmdpbmcgeGVuX3BsYXRmb3JtX3BjaT0wfDEgd2lsbCBzd2l0Y2ggcmF0aGVyIG1vcmUgdGhh
biBqdXN0CnRoZSBOSUMuIEl0IHdpbGwgc3dpdGNoIHlvdXIgZGlzayB0b28sIGluc3RhbnRseSBj
YXVzaW5nIHlvdXIgcHJldmlvdXNseQpoYXBwaWx5IGJvb3RpbmcgT1MgdG8gZmFpbCB0byBib290
IGFzIHRoZSByb290IGRldmljZSBuYW1lIGNoYW5nZXMuCgotLSAKQWxleCBCbGlnaAoKX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxp
bmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuc291cmNlLmNvbQpodHRwOi8vbGlzdHMueGVuc291
cmNlLmNvbS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Fri Dec 02 16:37:57 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 16:37:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWW7K-0007BE-3L; Fri, 02 Dec 2011 16:37:42 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <alex@alex.org.uk>) id 1RWW7I-0007B1-AV
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 16:37:40 +0000
X-Env-Sender: alex@alex.org.uk
X-Msg-Ref: server-8.tower-21.messagelabs.com!1322843819!6687824!1
X-Originating-IP: [89.16.176.221]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12025 invoked from network); 2 Dec 2011 16:36:59 -0000
Received: from mail.avalus.com (HELO mail.avalus.com) (89.16.176.221)
	by server-8.tower-21.messagelabs.com with SMTP;
	2 Dec 2011 16:36:59 -0000
Received: from [192.168.100.15] (87-194-71-186.bethere.co.uk [87.194.71.186])
	by mail.avalus.com (Postfix) with ESMTPSA id 95404C560FE;
	Fri,  2 Dec 2011 16:36:57 +0000 (GMT)
Date: Fri, 02 Dec 2011 16:36:56 +0000
From: Alex Bligh <alex@alex.org.uk>
To: =?UTF-8?Q?Pasi_K=C3=A4rkk=C3=A4inen?= <pasik@iki.fi>,
	Stefan Bader <stefan.bader@canonical.com>
Message-ID: <BA1B675D85BDD87795D1666C@Ximines.local>
In-Reply-To: <20111202104110.GL12984@reaktio.net>
References: <4ED798B2.1040309@canonical.com>
	<20111201180944.GH12984@reaktio.net>	<4ED8A45A.3050403@canonical.com>
	<20111202104110.GL12984@reaktio.net>
X-Mailer: Mulberry/4.0.8 (Mac OS X)
MIME-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com, Ian Campbell <ian.campbell@citrix.com>,
	Alex Bligh <alex@alex.org.uk>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Xen 4.x / Linux 3.x (dom0 and HVM domU)
 and	NIC	handling
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Alex Bligh <alex@alex.org.uk>
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: base64
Content-Type: text/plain; charset="utf-8"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

CgotLU9uIDIgRGVjZW1iZXIgMjAxMSAxMjo0MToxMCArMDIwMCBQYXNpIEvDpHJra8OkaW5lbiA8
cGFzaWtAaWtpLmZpPiB3cm90ZToKCj4+IEFuZCB0aGVuLCBvayB0aGlzIGlzIHByb2JhYmx5IGEg
cXVpdGUgbmFpdmUgYXBwcm9hY2gsIGl0IHNlZW1lZCB0byBtYWtlCj4+IHNlbnNlIHRvIGdvIHRo
cm91Z2ggdGhlIHBhaW4gb2YgYWx3YXlzIGhhdmluZyBwb3RlbnRpYWxseSBib3RoCj4+IGludGVy
ZmFjZXMgYXZhaWxhYmxlIChlbXVsYXRlZCBhbmQgcHYpIHNvIGluIHRoZW9yeSB0aGUgc2FtZSBn
dWVzdAo+PiBjb25maWcgY2FuIGFjY29tbW9kYXRlIGEgZ3Vlc3Qgb3Mgc3VwcG9ydGluZyBvbmUg
b3IgdGhlIG90aGVyIChvciBlYXNpbHkKPj4gc3dpdGNoIGZyb20gb25lIHRvIHRoZSBvdGhlciku
IE90aGVyd2lzZSBJIHdvdWxkIGV4cGVjdCBhbiBlbXVsYXRlZAo+PiBkZXZpY2Ugb25seSB3aGVu
IEkgaGF2ZSBoZD8gaW4gdGhlIGNvbmZpZyBhbmQgYSBwdiBkZXZpY2Ugd2hlbiBJIHdyaXRlCj4+
IHh2ZD8uCj4+Cj4KPiBUaGlzIHdvcmtzIGZvciBib3RoIEhWTSBhbmQgUFZIVk0gKGFsc28gbWVu
dGlvbmVkIG9uIHRoZSB3aWtpIHBhZ2UpOgo+IHZpZiA9IFsgJ21hYz0wMDoxNjo1ZTowMjowNzo0
NSwgYnJpZGdlPXhlbmJyMCwgbW9kZWw9ZTEwMDAnIF0KPgo+IFNvIHRoZXJlJ3Mgbm8gbmVlZCBm
b3IgInR5cGU9aW9lbXUiIG9wdGlvbiB3aXRoIHhtL3hlbmQuCj4KPiBZb3UgY2FuIHN3aXRjaCBi
ZXR3ZWVuIEhWTSBhbmQgUFZIVk0gd2l0aDoKPiB4ZW5fcGxhdGZvcm1fcGNpPTB8MQoKQUZBSUsg
Y2hhbmdpbmcgeGVuX3BsYXRmb3JtX3BjaT0wfDEgd2lsbCBzd2l0Y2ggcmF0aGVyIG1vcmUgdGhh
biBqdXN0CnRoZSBOSUMuIEl0IHdpbGwgc3dpdGNoIHlvdXIgZGlzayB0b28sIGluc3RhbnRseSBj
YXVzaW5nIHlvdXIgcHJldmlvdXNseQpoYXBwaWx5IGJvb3RpbmcgT1MgdG8gZmFpbCB0byBib290
IGFzIHRoZSByb290IGRldmljZSBuYW1lIGNoYW5nZXMuCgotLSAKQWxleCBCbGlnaAoKX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxp
bmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuc291cmNlLmNvbQpodHRwOi8vbGlzdHMueGVuc291
cmNlLmNvbS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Fri Dec 02 16:41:51 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 16:41:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWWB4-0007Mg-A9; Fri, 02 Dec 2011 16:41:34 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RWWB2-0007MM-Sh
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 16:41:33 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1322844050!4037491!1
X-Originating-IP: [209.85.161.171]
X-SpamReason: No, hits=1.1 required=7.0 tests=DATE_IN_PAST_06_12,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23947 invoked from network); 2 Dec 2011 16:40:51 -0000
Received: from mail-gx0-f171.google.com (HELO mail-gx0-f171.google.com)
	(209.85.161.171)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Dec 2011 16:40:51 -0000
Received: by ggnr4 with SMTP id r4so21607771ggn.30
	for <xen-devel@lists.xensource.com>;
	Fri, 02 Dec 2011 08:40:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=WHHxdhToIoXzMsMGOIdKSCL8mJyFUjKDrm8WGv15ZTI=;
	b=DX2JkLxPTCcV+Gq0bK+F+hTwHxmNi85/GiMQxrBudHmLvJwFga6zaPivCRwRWxErKl
	YYOO0D6TMBuSJVJgqXCsomqRhHyov7o6S/jsrO7YPyq0WER9zjK9UeaPSAQqeYC/U7B1
	8wAi6rxcF6wrY1Yw5NUpp9NKjHmpRl4Xbx+qY=
Received: by 10.182.115.5 with SMTP id jk5mr2486121obb.6.1322844050150;
	Fri, 02 Dec 2011 08:40:50 -0800 (PST)
Received: from [192.168.1.151] ([198.162.52.244])
	by mx.google.com with ESMTPS id e4sm996216obd.11.2011.12.02.08.40.45
	(version=SSLv3 cipher=OTHER); Fri, 02 Dec 2011 08:40:49 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Fri, 02 Dec 2011 08:40:43 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Olaf Hering <olaf@aepfle.de>
Message-ID: <CAFE3F8B.26613%keir.xen@gmail.com>
Thread-Topic: tools/libxc/xc_cpuid_x86.c:cpuid()'s inline asm
Thread-Index: AcyxESIBuupQcVvJ+02Ocerwkw92Lg==
In-Reply-To: <20111202152655.GA28246@aepfle.de>
Mime-version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] tools/libxc/xc_cpuid_x86.c:cpuid()'s inline asm
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 02/12/2011 15:26, "Olaf Hering" <olaf@aepfle.de> wrote:

> On Fri, Dec 02, Keir Fraser wrote:
> 
>> I think reg constraint failures had only been reported on 32-bit. So how
>> about the attached patch?
> 
> +        : "0" (input[0]), "1" (count), "S" (_regs)
> 
> _regs is undeclared in 32bit, I think it should be regs.

Oops! Fixed!

 Thanks,
 Keir

> Olaf



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

From xen-devel-bounces@lists.xensource.com Fri Dec 02 16:41:51 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 16:41:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWWB4-0007Mg-A9; Fri, 02 Dec 2011 16:41:34 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RWWB2-0007MM-Sh
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 16:41:33 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1322844050!4037491!1
X-Originating-IP: [209.85.161.171]
X-SpamReason: No, hits=1.1 required=7.0 tests=DATE_IN_PAST_06_12,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23947 invoked from network); 2 Dec 2011 16:40:51 -0000
Received: from mail-gx0-f171.google.com (HELO mail-gx0-f171.google.com)
	(209.85.161.171)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Dec 2011 16:40:51 -0000
Received: by ggnr4 with SMTP id r4so21607771ggn.30
	for <xen-devel@lists.xensource.com>;
	Fri, 02 Dec 2011 08:40:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=WHHxdhToIoXzMsMGOIdKSCL8mJyFUjKDrm8WGv15ZTI=;
	b=DX2JkLxPTCcV+Gq0bK+F+hTwHxmNi85/GiMQxrBudHmLvJwFga6zaPivCRwRWxErKl
	YYOO0D6TMBuSJVJgqXCsomqRhHyov7o6S/jsrO7YPyq0WER9zjK9UeaPSAQqeYC/U7B1
	8wAi6rxcF6wrY1Yw5NUpp9NKjHmpRl4Xbx+qY=
Received: by 10.182.115.5 with SMTP id jk5mr2486121obb.6.1322844050150;
	Fri, 02 Dec 2011 08:40:50 -0800 (PST)
Received: from [192.168.1.151] ([198.162.52.244])
	by mx.google.com with ESMTPS id e4sm996216obd.11.2011.12.02.08.40.45
	(version=SSLv3 cipher=OTHER); Fri, 02 Dec 2011 08:40:49 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Fri, 02 Dec 2011 08:40:43 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Olaf Hering <olaf@aepfle.de>
Message-ID: <CAFE3F8B.26613%keir.xen@gmail.com>
Thread-Topic: tools/libxc/xc_cpuid_x86.c:cpuid()'s inline asm
Thread-Index: AcyxESIBuupQcVvJ+02Ocerwkw92Lg==
In-Reply-To: <20111202152655.GA28246@aepfle.de>
Mime-version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] tools/libxc/xc_cpuid_x86.c:cpuid()'s inline asm
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 02/12/2011 15:26, "Olaf Hering" <olaf@aepfle.de> wrote:

> On Fri, Dec 02, Keir Fraser wrote:
> 
>> I think reg constraint failures had only been reported on 32-bit. So how
>> about the attached patch?
> 
> +        : "0" (input[0]), "1" (count), "S" (_regs)
> 
> _regs is undeclared in 32bit, I think it should be regs.

Oops! Fixed!

 Thanks,
 Keir

> Olaf



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

From xen-devel-bounces@lists.xensource.com Fri Dec 02 16:41:53 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 16:41:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWWB1-0007MT-TS; Fri, 02 Dec 2011 16:41:31 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RWWB0-0007MK-Qp
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 16:41:31 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1322844049!3990661!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTg0Mw==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8671 invoked from network); 2 Dec 2011 16:40:49 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Dec 2011 16:40:49 -0000
X-IronPort-AV: E=Sophos;i="4.71,284,1320624000"; 
   d="scan'208";a="9256166"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Dec 2011 16:40:49 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 2 Dec 2011
	16:40:49 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Alex Bligh <alex@alex.org.uk>
Date: Fri, 2 Dec 2011 16:40:48 +0000
In-Reply-To: <BA1B675D85BDD87795D1666C@Ximines.local>
References: <4ED798B2.1040309@canonical.com>
	<20111201180944.GH12984@reaktio.net>	<4ED8A45A.3050403@canonical.com>
	<20111202104110.GL12984@reaktio.net>
	<BA1B675D85BDD87795D1666C@Ximines.local>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322844048.29870.155.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefan Bader <stefan.bader@canonical.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Xen 4.x / Linux 3.x (dom0 and HVM domU) and	NIC
 handling
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gRnJpLCAyMDExLTEyLTAyIGF0IDE2OjM2ICswMDAwLCBBbGV4IEJsaWdoIHdyb3RlOgo+IAo+
IC0tT24gMiBEZWNlbWJlciAyMDExIDEyOjQxOjEwICswMjAwIFBhc2kgS8Okcmtrw6RpbmVuIDxw
YXNpa0Bpa2kuZmk+IHdyb3RlOgo+IAo+ID4+IEFuZCB0aGVuLCBvayB0aGlzIGlzIHByb2JhYmx5
IGEgcXVpdGUgbmFpdmUgYXBwcm9hY2gsIGl0IHNlZW1lZCB0byBtYWtlCj4gPj4gc2Vuc2UgdG8g
Z28gdGhyb3VnaCB0aGUgcGFpbiBvZiBhbHdheXMgaGF2aW5nIHBvdGVudGlhbGx5IGJvdGgKPiA+
PiBpbnRlcmZhY2VzIGF2YWlsYWJsZSAoZW11bGF0ZWQgYW5kIHB2KSBzbyBpbiB0aGVvcnkgdGhl
IHNhbWUgZ3Vlc3QKPiA+PiBjb25maWcgY2FuIGFjY29tbW9kYXRlIGEgZ3Vlc3Qgb3Mgc3VwcG9y
dGluZyBvbmUgb3IgdGhlIG90aGVyIChvciBlYXNpbHkKPiA+PiBzd2l0Y2ggZnJvbSBvbmUgdG8g
dGhlIG90aGVyKS4gT3RoZXJ3aXNlIEkgd291bGQgZXhwZWN0IGFuIGVtdWxhdGVkCj4gPj4gZGV2
aWNlIG9ubHkgd2hlbiBJIGhhdmUgaGQ/IGluIHRoZSBjb25maWcgYW5kIGEgcHYgZGV2aWNlIHdo
ZW4gSSB3cml0ZQo+ID4+IHh2ZD8uCj4gPj4KPiA+Cj4gPiBUaGlzIHdvcmtzIGZvciBib3RoIEhW
TSBhbmQgUFZIVk0gKGFsc28gbWVudGlvbmVkIG9uIHRoZSB3aWtpIHBhZ2UpOgo+ID4gdmlmID0g
WyAnbWFjPTAwOjE2OjVlOjAyOjA3OjQ1LCBicmlkZ2U9eGVuYnIwLCBtb2RlbD1lMTAwMCcgXQo+
ID4KPiA+IFNvIHRoZXJlJ3Mgbm8gbmVlZCBmb3IgInR5cGU9aW9lbXUiIG9wdGlvbiB3aXRoIHht
L3hlbmQuCj4gPgo+ID4gWW91IGNhbiBzd2l0Y2ggYmV0d2VlbiBIVk0gYW5kIFBWSFZNIHdpdGg6
Cj4gPiB4ZW5fcGxhdGZvcm1fcGNpPTB8MQo+IAo+IEFGQUlLIGNoYW5naW5nIHhlbl9wbGF0Zm9y
bV9wY2k9MHwxIHdpbGwgc3dpdGNoIHJhdGhlciBtb3JlIHRoYW4ganVzdAo+IHRoZSBOSUMuIEl0
IHdpbGwgc3dpdGNoIHlvdXIgZGlzayB0b28sIGluc3RhbnRseSBjYXVzaW5nIHlvdXIgcHJldmlv
dXNseQo+IGhhcHBpbHkgYm9vdGluZyBPUyB0byBmYWlsIHRvIGJvb3QgYXMgdGhlIHJvb3QgZGV2
aWNlIG5hbWUgY2hhbmdlcy4KCldlIHJlY29tbWVuZCB5b3UgdXNlICJyb290PUxBQkVMPWZvbyIg
cmF0aGVyIHRoYW4gInJvb3Q9L2Rldi9ibGFoIiBmb3IKdGhpcyByZWFzb24uIEZvcnR1bmF0ZWx5
IG1vc3QgZGlzdHJvcyB1c2UgdGhhdCBzY2hlbWUgYnkgZGVmYXVsdCB0aGVzZQpkYXlzLgoKSWFu
LgoKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4t
ZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tCmh0dHA6Ly9s
aXN0cy54ZW5zb3VyY2UuY29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Fri Dec 02 16:41:53 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 16:41:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWWB1-0007MT-TS; Fri, 02 Dec 2011 16:41:31 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RWWB0-0007MK-Qp
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 16:41:31 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1322844049!3990661!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTg0Mw==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8671 invoked from network); 2 Dec 2011 16:40:49 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Dec 2011 16:40:49 -0000
X-IronPort-AV: E=Sophos;i="4.71,284,1320624000"; 
   d="scan'208";a="9256166"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Dec 2011 16:40:49 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 2 Dec 2011
	16:40:49 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Alex Bligh <alex@alex.org.uk>
Date: Fri, 2 Dec 2011 16:40:48 +0000
In-Reply-To: <BA1B675D85BDD87795D1666C@Ximines.local>
References: <4ED798B2.1040309@canonical.com>
	<20111201180944.GH12984@reaktio.net>	<4ED8A45A.3050403@canonical.com>
	<20111202104110.GL12984@reaktio.net>
	<BA1B675D85BDD87795D1666C@Ximines.local>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322844048.29870.155.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefan Bader <stefan.bader@canonical.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Xen 4.x / Linux 3.x (dom0 and HVM domU) and	NIC
 handling
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gRnJpLCAyMDExLTEyLTAyIGF0IDE2OjM2ICswMDAwLCBBbGV4IEJsaWdoIHdyb3RlOgo+IAo+
IC0tT24gMiBEZWNlbWJlciAyMDExIDEyOjQxOjEwICswMjAwIFBhc2kgS8Okcmtrw6RpbmVuIDxw
YXNpa0Bpa2kuZmk+IHdyb3RlOgo+IAo+ID4+IEFuZCB0aGVuLCBvayB0aGlzIGlzIHByb2JhYmx5
IGEgcXVpdGUgbmFpdmUgYXBwcm9hY2gsIGl0IHNlZW1lZCB0byBtYWtlCj4gPj4gc2Vuc2UgdG8g
Z28gdGhyb3VnaCB0aGUgcGFpbiBvZiBhbHdheXMgaGF2aW5nIHBvdGVudGlhbGx5IGJvdGgKPiA+
PiBpbnRlcmZhY2VzIGF2YWlsYWJsZSAoZW11bGF0ZWQgYW5kIHB2KSBzbyBpbiB0aGVvcnkgdGhl
IHNhbWUgZ3Vlc3QKPiA+PiBjb25maWcgY2FuIGFjY29tbW9kYXRlIGEgZ3Vlc3Qgb3Mgc3VwcG9y
dGluZyBvbmUgb3IgdGhlIG90aGVyIChvciBlYXNpbHkKPiA+PiBzd2l0Y2ggZnJvbSBvbmUgdG8g
dGhlIG90aGVyKS4gT3RoZXJ3aXNlIEkgd291bGQgZXhwZWN0IGFuIGVtdWxhdGVkCj4gPj4gZGV2
aWNlIG9ubHkgd2hlbiBJIGhhdmUgaGQ/IGluIHRoZSBjb25maWcgYW5kIGEgcHYgZGV2aWNlIHdo
ZW4gSSB3cml0ZQo+ID4+IHh2ZD8uCj4gPj4KPiA+Cj4gPiBUaGlzIHdvcmtzIGZvciBib3RoIEhW
TSBhbmQgUFZIVk0gKGFsc28gbWVudGlvbmVkIG9uIHRoZSB3aWtpIHBhZ2UpOgo+ID4gdmlmID0g
WyAnbWFjPTAwOjE2OjVlOjAyOjA3OjQ1LCBicmlkZ2U9eGVuYnIwLCBtb2RlbD1lMTAwMCcgXQo+
ID4KPiA+IFNvIHRoZXJlJ3Mgbm8gbmVlZCBmb3IgInR5cGU9aW9lbXUiIG9wdGlvbiB3aXRoIHht
L3hlbmQuCj4gPgo+ID4gWW91IGNhbiBzd2l0Y2ggYmV0d2VlbiBIVk0gYW5kIFBWSFZNIHdpdGg6
Cj4gPiB4ZW5fcGxhdGZvcm1fcGNpPTB8MQo+IAo+IEFGQUlLIGNoYW5naW5nIHhlbl9wbGF0Zm9y
bV9wY2k9MHwxIHdpbGwgc3dpdGNoIHJhdGhlciBtb3JlIHRoYW4ganVzdAo+IHRoZSBOSUMuIEl0
IHdpbGwgc3dpdGNoIHlvdXIgZGlzayB0b28sIGluc3RhbnRseSBjYXVzaW5nIHlvdXIgcHJldmlv
dXNseQo+IGhhcHBpbHkgYm9vdGluZyBPUyB0byBmYWlsIHRvIGJvb3QgYXMgdGhlIHJvb3QgZGV2
aWNlIG5hbWUgY2hhbmdlcy4KCldlIHJlY29tbWVuZCB5b3UgdXNlICJyb290PUxBQkVMPWZvbyIg
cmF0aGVyIHRoYW4gInJvb3Q9L2Rldi9ibGFoIiBmb3IKdGhpcyByZWFzb24uIEZvcnR1bmF0ZWx5
IG1vc3QgZGlzdHJvcyB1c2UgdGhhdCBzY2hlbWUgYnkgZGVmYXVsdCB0aGVzZQpkYXlzLgoKSWFu
LgoKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4t
ZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tCmh0dHA6Ly9s
aXN0cy54ZW5zb3VyY2UuY29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Fri Dec 02 16:42:02 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 16:42:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWWBK-0007P0-O2; Fri, 02 Dec 2011 16:41:50 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RWWBI-0007Ns-Vr
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 16:41:49 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1322844050!4037491!2
X-Originating-IP: [209.85.161.171]
X-SpamReason: No, hits=1.1 required=7.0 tests=DATE_IN_PAST_06_12,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24554 invoked from network); 2 Dec 2011 16:41:06 -0000
Received: from mail-gx0-f171.google.com (HELO mail-gx0-f171.google.com)
	(209.85.161.171)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Dec 2011 16:41:06 -0000
Received: by mail-gx0-f171.google.com with SMTP id r4so21607771ggn.30
	for <xen-devel@lists.xensource.com>;
	Fri, 02 Dec 2011 08:41:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=D4urxQVmM+L959L1w8uFGKHD1ce9vClCIA62PDolk6c=;
	b=XuV4ZIoJLhFVLO8Rp/q1uacxlFKu9xq6rO11YJB4MWBsNlGfGe4BTpffGQ+FqO9Vnq
	hDa95QkTl2mvvJAe7dtm5y/kyBIhoQ+JgYNe1Ab6Gzdx/jJUspBi4ffxfmB0x4G9NJ+2
	vyN71bbQZAtZYMy7zMfEgNgC4IiOuEzLRivew=
Received: by 10.182.216.105 with SMTP id op9mr2466464obc.57.1322844066483;
	Fri, 02 Dec 2011 08:41:06 -0800 (PST)
Received: from [192.168.1.151] ([198.162.52.244])
	by mx.google.com with ESMTPS id r2sm2441638obn.8.2011.12.02.08.41.03
	(version=SSLv3 cipher=OTHER); Fri, 02 Dec 2011 08:41:05 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Fri, 02 Dec 2011 08:40:59 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	<xen-devel@lists.xensource.com>
Message-ID: <CAFE3F9B.26614%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [xen-unstable test] 10244: regressions - FAIL
Thread-Index: AcyxESuLnDH6DXuuTUaaJJOF0Uh6og==
In-Reply-To: <osstest-10244-mainreport@xen.org>
Mime-version: 1.0
Subject: Re: [Xen-devel] [xen-unstable test] 10244: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 02/12/2011 16:17, "Ian Jackson" <Ian.Jackson@eu.citrix.com> wrote:

> flight 10244 xen-unstable real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/10244/
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking:
>  build-amd64                   4 xen-build                 fail REGR. vs.
> 10201
>  build-i386-oldkern            4 xen-build                 fail REGR. vs.
> 10201
>  build-i386                    4 xen-build                 fail REGR. vs.
> 10201
>  build-amd64-oldkern           4 xen-build                 fail REGR. vs.
> 10201

My fault. Should be fixed now.

 -- Keir

> Tests which did not succeed, but are not blocking,
> including regressions (tests previously passed) regarded as allowable:
>  test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
>  test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
>  test-amd64-amd64-xl-winxpsp3  1 xen-build-check(1)           blocked  n/a
>  test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked
> n/a
>  test-amd64-i386-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
>  test-i386-i386-xl-winxpsp3    1 xen-build-check(1)           blocked  n/a
>  test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
>  test-i386-i386-pv             1 xen-build-check(1)           blocked  n/a
>  test-i386-i386-xl             1 xen-build-check(1)           blocked  n/a
>  test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
>  test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
>  test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
>  test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
>  test-i386-i386-pair           1 xen-build-check(1)           blocked  n/a
>  test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
>  test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
>  test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
>  test-amd64-amd64-pv           1 xen-build-check(1)           blocked  n/a
>  test-amd64-amd64-xl           1 xen-build-check(1)           blocked  n/a
>  test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
>  test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
>  test-amd64-amd64-xl-win       1 xen-build-check(1)           blocked  n/a
>  test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
>  test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
>  test-i386-i386-win            1 xen-build-check(1)           blocked  n/a
>  test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
>  test-i386-i386-xl-win         1 xen-build-check(1)           blocked  n/a
>  test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a
> 
> version targeted for testing:
>  xen                  72f4e4cb7440
> baseline version:
>  xen                  62ff6a318c5d
> 
> ------------------------------------------------------------
> People who touched revisions under test:
>   Adin Scannell <adin@scannell.ca>
>   Andres Lagar-Cavilla <andres@lagarcavilla.org>
>   Anthony PERARD <anthony.perard@citrix.com>
>   Brendan Cully <brendan@cs.ubc.ca>
>   Daniel De Graaf <dgdegra@tycho.nsa.gov>
>   Ian Campbell <ian.campbell@citrix.com>
>   Ian Jackson <ian.jackson.citrix.com>
>   Ian Jackson <ian.jackson@eu.citrix.com>
>   Jan Beulich <jbeulich@novell.com>
>   Jan Beulich <jbeulich@suse.com>
>   Jean Guyader <jean.guyader@eu.citrix.com>
>   Jonathan Davies <jonathan.davies@citrix.com>
>   juergen.gross@ts.fujitsu.com
>   Keir Fraser <keir@xen.org>
>   Liu, Jinsong <jinsong.liu@intel.com>
>   Olaf Hering <olaf@aepfle.de>
>   Philipp Hahn <hahn@univention.de>
>   Shriram Rajagopalan <rshriram@cs.ubc.ca>
>   Stefano Stabellini <stefano.stabellini@eu.citrix.com>
>   Tim Deegan <tim@xen.org>
>   Wei Wang2 <wei.wang2@amd.com>
> ------------------------------------------------------------
> 
> jobs:
>  build-amd64                                                  fail
>  build-i386                                                   fail
>  build-amd64-oldkern                                          fail
>  build-i386-oldkern                                           fail
>  build-amd64-pvops                                            pass
>  build-i386-pvops                                             pass
>  test-amd64-amd64-xl                                          blocked
>  test-amd64-i386-xl                                           blocked
>  test-i386-i386-xl                                            blocked
>  test-amd64-i386-rhel6hvm-amd                                 blocked
>  test-amd64-amd64-xl-win7-amd64                               blocked
>  test-amd64-i386-xl-win7-amd64                                blocked
>  test-amd64-i386-xl-credit2                                   blocked
>  test-amd64-amd64-xl-pcipt-intel                              blocked
>  test-amd64-i386-rhel6hvm-intel                               blocked
>  test-amd64-i386-xl-multivcpu                                 blocked
>  test-amd64-amd64-pair                                        blocked
>  test-amd64-i386-pair                                         blocked
>  test-i386-i386-pair                                          blocked
>  test-amd64-amd64-pv                                          blocked
>  test-amd64-i386-pv                                           blocked
>  test-i386-i386-pv                                            blocked
>  test-amd64-amd64-xl-sedf                                     blocked
>  test-amd64-i386-win-vcpus1                                   blocked
>  test-amd64-i386-xl-win-vcpus1                                blocked
>  test-amd64-i386-xl-winxpsp3-vcpus1                           blocked
>  test-amd64-amd64-win                                         blocked
>  test-amd64-i386-win                                          blocked
>  test-i386-i386-win                                           blocked
>  test-amd64-amd64-xl-win                                      blocked
>  test-i386-i386-xl-win                                        blocked
>  test-amd64-i386-xend-winxpsp3                                blocked
>  test-amd64-amd64-xl-winxpsp3                                 blocked
>  test-i386-i386-xl-winxpsp3                                   blocked
> 
> 
> ------------------------------------------------------------
> sg-report-flight on woking.cam.xci-test.com
> logs: /home/xc_osstest/logs
> images: /home/xc_osstest/images
> 
> Logs, config files, etc. are available at
>     http://www.chiark.greenend.org.uk/~xensrcts/logs
> 
> Test harness code can be found at
>     http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary
> 
> 
> Not pushing.
> 
> (No revision log; it would be 1123 lines long.)
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



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

From xen-devel-bounces@lists.xensource.com Fri Dec 02 16:42:02 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 16:42:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWWBK-0007P0-O2; Fri, 02 Dec 2011 16:41:50 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RWWBI-0007Ns-Vr
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 16:41:49 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1322844050!4037491!2
X-Originating-IP: [209.85.161.171]
X-SpamReason: No, hits=1.1 required=7.0 tests=DATE_IN_PAST_06_12,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24554 invoked from network); 2 Dec 2011 16:41:06 -0000
Received: from mail-gx0-f171.google.com (HELO mail-gx0-f171.google.com)
	(209.85.161.171)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Dec 2011 16:41:06 -0000
Received: by mail-gx0-f171.google.com with SMTP id r4so21607771ggn.30
	for <xen-devel@lists.xensource.com>;
	Fri, 02 Dec 2011 08:41:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=D4urxQVmM+L959L1w8uFGKHD1ce9vClCIA62PDolk6c=;
	b=XuV4ZIoJLhFVLO8Rp/q1uacxlFKu9xq6rO11YJB4MWBsNlGfGe4BTpffGQ+FqO9Vnq
	hDa95QkTl2mvvJAe7dtm5y/kyBIhoQ+JgYNe1Ab6Gzdx/jJUspBi4ffxfmB0x4G9NJ+2
	vyN71bbQZAtZYMy7zMfEgNgC4IiOuEzLRivew=
Received: by 10.182.216.105 with SMTP id op9mr2466464obc.57.1322844066483;
	Fri, 02 Dec 2011 08:41:06 -0800 (PST)
Received: from [192.168.1.151] ([198.162.52.244])
	by mx.google.com with ESMTPS id r2sm2441638obn.8.2011.12.02.08.41.03
	(version=SSLv3 cipher=OTHER); Fri, 02 Dec 2011 08:41:05 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Fri, 02 Dec 2011 08:40:59 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	<xen-devel@lists.xensource.com>
Message-ID: <CAFE3F9B.26614%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [xen-unstable test] 10244: regressions - FAIL
Thread-Index: AcyxESuLnDH6DXuuTUaaJJOF0Uh6og==
In-Reply-To: <osstest-10244-mainreport@xen.org>
Mime-version: 1.0
Subject: Re: [Xen-devel] [xen-unstable test] 10244: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 02/12/2011 16:17, "Ian Jackson" <Ian.Jackson@eu.citrix.com> wrote:

> flight 10244 xen-unstable real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/10244/
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking:
>  build-amd64                   4 xen-build                 fail REGR. vs.
> 10201
>  build-i386-oldkern            4 xen-build                 fail REGR. vs.
> 10201
>  build-i386                    4 xen-build                 fail REGR. vs.
> 10201
>  build-amd64-oldkern           4 xen-build                 fail REGR. vs.
> 10201

My fault. Should be fixed now.

 -- Keir

> Tests which did not succeed, but are not blocking,
> including regressions (tests previously passed) regarded as allowable:
>  test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
>  test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
>  test-amd64-amd64-xl-winxpsp3  1 xen-build-check(1)           blocked  n/a
>  test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked
> n/a
>  test-amd64-i386-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
>  test-i386-i386-xl-winxpsp3    1 xen-build-check(1)           blocked  n/a
>  test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
>  test-i386-i386-pv             1 xen-build-check(1)           blocked  n/a
>  test-i386-i386-xl             1 xen-build-check(1)           blocked  n/a
>  test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
>  test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
>  test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
>  test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
>  test-i386-i386-pair           1 xen-build-check(1)           blocked  n/a
>  test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
>  test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
>  test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
>  test-amd64-amd64-pv           1 xen-build-check(1)           blocked  n/a
>  test-amd64-amd64-xl           1 xen-build-check(1)           blocked  n/a
>  test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
>  test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
>  test-amd64-amd64-xl-win       1 xen-build-check(1)           blocked  n/a
>  test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
>  test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
>  test-i386-i386-win            1 xen-build-check(1)           blocked  n/a
>  test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
>  test-i386-i386-xl-win         1 xen-build-check(1)           blocked  n/a
>  test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a
> 
> version targeted for testing:
>  xen                  72f4e4cb7440
> baseline version:
>  xen                  62ff6a318c5d
> 
> ------------------------------------------------------------
> People who touched revisions under test:
>   Adin Scannell <adin@scannell.ca>
>   Andres Lagar-Cavilla <andres@lagarcavilla.org>
>   Anthony PERARD <anthony.perard@citrix.com>
>   Brendan Cully <brendan@cs.ubc.ca>
>   Daniel De Graaf <dgdegra@tycho.nsa.gov>
>   Ian Campbell <ian.campbell@citrix.com>
>   Ian Jackson <ian.jackson.citrix.com>
>   Ian Jackson <ian.jackson@eu.citrix.com>
>   Jan Beulich <jbeulich@novell.com>
>   Jan Beulich <jbeulich@suse.com>
>   Jean Guyader <jean.guyader@eu.citrix.com>
>   Jonathan Davies <jonathan.davies@citrix.com>
>   juergen.gross@ts.fujitsu.com
>   Keir Fraser <keir@xen.org>
>   Liu, Jinsong <jinsong.liu@intel.com>
>   Olaf Hering <olaf@aepfle.de>
>   Philipp Hahn <hahn@univention.de>
>   Shriram Rajagopalan <rshriram@cs.ubc.ca>
>   Stefano Stabellini <stefano.stabellini@eu.citrix.com>
>   Tim Deegan <tim@xen.org>
>   Wei Wang2 <wei.wang2@amd.com>
> ------------------------------------------------------------
> 
> jobs:
>  build-amd64                                                  fail
>  build-i386                                                   fail
>  build-amd64-oldkern                                          fail
>  build-i386-oldkern                                           fail
>  build-amd64-pvops                                            pass
>  build-i386-pvops                                             pass
>  test-amd64-amd64-xl                                          blocked
>  test-amd64-i386-xl                                           blocked
>  test-i386-i386-xl                                            blocked
>  test-amd64-i386-rhel6hvm-amd                                 blocked
>  test-amd64-amd64-xl-win7-amd64                               blocked
>  test-amd64-i386-xl-win7-amd64                                blocked
>  test-amd64-i386-xl-credit2                                   blocked
>  test-amd64-amd64-xl-pcipt-intel                              blocked
>  test-amd64-i386-rhel6hvm-intel                               blocked
>  test-amd64-i386-xl-multivcpu                                 blocked
>  test-amd64-amd64-pair                                        blocked
>  test-amd64-i386-pair                                         blocked
>  test-i386-i386-pair                                          blocked
>  test-amd64-amd64-pv                                          blocked
>  test-amd64-i386-pv                                           blocked
>  test-i386-i386-pv                                            blocked
>  test-amd64-amd64-xl-sedf                                     blocked
>  test-amd64-i386-win-vcpus1                                   blocked
>  test-amd64-i386-xl-win-vcpus1                                blocked
>  test-amd64-i386-xl-winxpsp3-vcpus1                           blocked
>  test-amd64-amd64-win                                         blocked
>  test-amd64-i386-win                                          blocked
>  test-i386-i386-win                                           blocked
>  test-amd64-amd64-xl-win                                      blocked
>  test-i386-i386-xl-win                                        blocked
>  test-amd64-i386-xend-winxpsp3                                blocked
>  test-amd64-amd64-xl-winxpsp3                                 blocked
>  test-i386-i386-xl-winxpsp3                                   blocked
> 
> 
> ------------------------------------------------------------
> sg-report-flight on woking.cam.xci-test.com
> logs: /home/xc_osstest/logs
> images: /home/xc_osstest/images
> 
> Logs, config files, etc. are available at
>     http://www.chiark.greenend.org.uk/~xensrcts/logs
> 
> Test harness code can be found at
>     http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary
> 
> 
> Not pushing.
> 
> (No revision log; it would be 1123 lines long.)
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



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

From xen-devel-bounces@lists.xensource.com Fri Dec 02 16:45:18 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 16:45:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWWEQ-0007kv-Cr; Fri, 02 Dec 2011 16:45:02 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RWWEO-0007ju-Oe
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 16:45:01 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-9.tower-182.messagelabs.com!1322844259!5643333!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMzU3NDM=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMzU3NDM=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2968 invoked from network); 2 Dec 2011 16:44:19 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-9.tower-182.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 2 Dec 2011 16:44:19 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1322844259; l=780;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=j1ZcZd1Kd7Cd8wVdgwWXi2DAyuU=;
	b=HnTPauug26Eom/tqXQokgqeKl5sFTty1Q/TqKKRl/ymXqYdb4uCwjH+C7ltt3asAPm+
	axcG6FEFYqY2JfB4Ahu5T23k9FcQ3zIEnxGqrq6Xv2d0kb6wv+3ycCqJSsuDzggns+iXO
	w6N4z2F1c6qEq+VgW49U+mE63UEu2dtr81I=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFJji0PG5M=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-070-018.pools.arcor-ip.net [88.65.70.18])
	by post.strato.de (mrclete mo57) (RZmta 26.10 AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id w031c7nB2ErizQ ;
	Fri, 2 Dec 2011 17:43:58 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 17B7218637; Fri,  2 Dec 2011 17:43:58 +0100 (CET)
Date: Fri, 2 Dec 2011 17:43:57 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20111202164357.GA29226@aepfle.de>
References: <mailman.3014.1322742146.12970.xen-devel@lists.xensource.com>
	<782967b2dc26ac23e527e33839e8336f.squirrel@webmail.lagarcavilla.org>
	<20111201184616.GA17010@aepfle.de>
	<fa38d847359784f92a266c98b7855924.squirrel@webmail.lagarcavilla.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <fa38d847359784f92a266c98b7855924.squirrel@webmail.lagarcavilla.org>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 2 of 4] xenpaging: use wait queues
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Dec 02, Andres Lagar-Cavilla wrote:

> > The pager is in the process of writing the gfn to disk after successful
> > nomination. Its next step is the eviction, which will now fail because
> > the p2mt is not p2m_ram_paging_out anymore. It is already prepared for
> > that failure.
> > The previous MEM_EVENT_FLAG_EVICT_FAIL was not needed in the first
> > place.
> Yes it was! The biggest source of overhead is I/O. Tell the pager to stop
> I/O early. Otherwise, you've done the paging out I/O pointlessly, to find
> out only when you try to finalize the eviction.

I'm not sure how to inform the pager, its most likely in the middle of
write(). Since such an event is rare (in my testing at least) I wonder
wether its worth to make it complicated?

Olaf

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

From xen-devel-bounces@lists.xensource.com Fri Dec 02 16:45:18 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 16:45:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWWEQ-0007kv-Cr; Fri, 02 Dec 2011 16:45:02 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RWWEO-0007ju-Oe
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 16:45:01 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-9.tower-182.messagelabs.com!1322844259!5643333!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMzU3NDM=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMzU3NDM=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2968 invoked from network); 2 Dec 2011 16:44:19 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-9.tower-182.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 2 Dec 2011 16:44:19 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1322844259; l=780;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=j1ZcZd1Kd7Cd8wVdgwWXi2DAyuU=;
	b=HnTPauug26Eom/tqXQokgqeKl5sFTty1Q/TqKKRl/ymXqYdb4uCwjH+C7ltt3asAPm+
	axcG6FEFYqY2JfB4Ahu5T23k9FcQ3zIEnxGqrq6Xv2d0kb6wv+3ycCqJSsuDzggns+iXO
	w6N4z2F1c6qEq+VgW49U+mE63UEu2dtr81I=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFJji0PG5M=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-070-018.pools.arcor-ip.net [88.65.70.18])
	by post.strato.de (mrclete mo57) (RZmta 26.10 AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id w031c7nB2ErizQ ;
	Fri, 2 Dec 2011 17:43:58 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 17B7218637; Fri,  2 Dec 2011 17:43:58 +0100 (CET)
Date: Fri, 2 Dec 2011 17:43:57 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20111202164357.GA29226@aepfle.de>
References: <mailman.3014.1322742146.12970.xen-devel@lists.xensource.com>
	<782967b2dc26ac23e527e33839e8336f.squirrel@webmail.lagarcavilla.org>
	<20111201184616.GA17010@aepfle.de>
	<fa38d847359784f92a266c98b7855924.squirrel@webmail.lagarcavilla.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <fa38d847359784f92a266c98b7855924.squirrel@webmail.lagarcavilla.org>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 2 of 4] xenpaging: use wait queues
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Dec 02, Andres Lagar-Cavilla wrote:

> > The pager is in the process of writing the gfn to disk after successful
> > nomination. Its next step is the eviction, which will now fail because
> > the p2mt is not p2m_ram_paging_out anymore. It is already prepared for
> > that failure.
> > The previous MEM_EVENT_FLAG_EVICT_FAIL was not needed in the first
> > place.
> Yes it was! The biggest source of overhead is I/O. Tell the pager to stop
> I/O early. Otherwise, you've done the paging out I/O pointlessly, to find
> out only when you try to finalize the eviction.

I'm not sure how to inform the pager, its most likely in the middle of
write(). Since such an event is rare (in my testing at least) I wonder
wether its worth to make it complicated?

Olaf

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

From xen-devel-bounces@lists.xensource.com Fri Dec 02 16:48:33 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 16: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.xensource.com>)
	id 1RWWHc-0007xf-0s; Fri, 02 Dec 2011 16:48:20 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RWWHa-0007xK-5Y
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 16:48:18 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-13.tower-174.messagelabs.com!1322844456!4034080!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMzU3NDM=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMzU3NDM=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26982 invoked from network); 2 Dec 2011 16:47:37 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-13.tower-174.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 2 Dec 2011 16:47:37 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1322844456; l=242;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=Ou5/pLn5o7qax1/d9lNFcvs0Q50=;
	b=mt9KZxiDc1nKWsbvivsnKUXj0tt+klf9DXlaNFp1pFLVKh0IH+La428WdpA2Uw6LBgV
	/OAUvk0h5vEcaN7/PjoPx01KG20yQP+8MJL60Z3hMAG6ADMtLOYCTDkTtgPGaW857nU6i
	2pZOV0/jaJe8cM6TrNhbJn5soPoDRYIF4l0=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFJji0PG5M=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-070-018.pools.arcor-ip.net [88.65.70.18])
	by smtp.strato.de (klopstock mo27) (RZmta 26.10 AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id k04537nB2F9bbh ;
	Fri, 2 Dec 2011 17:47:15 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id A596318637; Fri,  2 Dec 2011 17:47:14 +0100 (CET)
Date: Fri, 2 Dec 2011 17:47:14 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Keir Fraser <keir.xen@gmail.com>
Message-ID: <20111202164714.GB29226@aepfle.de>
References: <4ED8A05A0200007800065020@nat28.tlf.novell.com>
	<CAFE1A94.26526%keir.xen@gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAFE1A94.26526%keir.xen@gmail.com>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] tools/libxc/xc_cpuid_x86.c:cpuid()'s inline asm
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Dec 02, Keir Fraser wrote:

> I think reg constraint failures had only been reported on 32-bit. So how
> about the attached patch?

So finally I was able to test this change, and it fixes the reported segfault.
Thanks!

Olaf

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

From xen-devel-bounces@lists.xensource.com Fri Dec 02 16:48:33 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 16: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.xensource.com>)
	id 1RWWHc-0007xf-0s; Fri, 02 Dec 2011 16:48:20 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RWWHa-0007xK-5Y
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 16:48:18 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-13.tower-174.messagelabs.com!1322844456!4034080!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMzU3NDM=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMzU3NDM=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26982 invoked from network); 2 Dec 2011 16:47:37 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-13.tower-174.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 2 Dec 2011 16:47:37 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1322844456; l=242;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=Ou5/pLn5o7qax1/d9lNFcvs0Q50=;
	b=mt9KZxiDc1nKWsbvivsnKUXj0tt+klf9DXlaNFp1pFLVKh0IH+La428WdpA2Uw6LBgV
	/OAUvk0h5vEcaN7/PjoPx01KG20yQP+8MJL60Z3hMAG6ADMtLOYCTDkTtgPGaW857nU6i
	2pZOV0/jaJe8cM6TrNhbJn5soPoDRYIF4l0=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFJji0PG5M=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-070-018.pools.arcor-ip.net [88.65.70.18])
	by smtp.strato.de (klopstock mo27) (RZmta 26.10 AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id k04537nB2F9bbh ;
	Fri, 2 Dec 2011 17:47:15 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id A596318637; Fri,  2 Dec 2011 17:47:14 +0100 (CET)
Date: Fri, 2 Dec 2011 17:47:14 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Keir Fraser <keir.xen@gmail.com>
Message-ID: <20111202164714.GB29226@aepfle.de>
References: <4ED8A05A0200007800065020@nat28.tlf.novell.com>
	<CAFE1A94.26526%keir.xen@gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAFE1A94.26526%keir.xen@gmail.com>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] tools/libxc/xc_cpuid_x86.c:cpuid()'s inline asm
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Dec 02, Keir Fraser wrote:

> I think reg constraint failures had only been reported on 32-bit. So how
> about the attached patch?

So finally I was able to test this change, and it fixes the reported segfault.
Thanks!

Olaf

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

From xen-devel-bounces@lists.xensource.com Fri Dec 02 16:48:42 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 16: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.xensource.com>)
	id 1RWWHn-0007yz-Dk; Fri, 02 Dec 2011 16:48:31 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Jean.Guyader@citrix.com>) id 1RWWHm-0007y7-06
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 16:48:30 +0000
X-Env-Sender: Jean.Guyader@citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1322844468!5940582!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTg0Mw==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4864 invoked from network); 2 Dec 2011 16:47:48 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Dec 2011 16:47:48 -0000
X-IronPort-AV: E=Sophos;i="4.71,284,1320624000"; 
   d="scan'208";a="9256287"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Dec 2011 16:47:42 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 2 Dec 2011 16:47:42 +0000
Received: from spongy.cam.xci-test.com ([10.80.248.53])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<jean.guyader@eu.citrix.com>)	id 1RWWGz-0003RO-L6;
	Fri, 02 Dec 2011 16:47:41 +0000
Received: from jeangu by spongy.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <jean.guyader@eu.citrix.com>)	id 1RWWGj-00019v-Ap;
	Fri, 02 Dec 2011 16:47:25 +0000
From: Jean Guyader <jean.guyader@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Fri, 2 Dec 2011 16:47:23 +0000
Message-ID: <1322844443-4427-1-git-send-email-jean.guyader@eu.citrix.com>
X-Mailer: git-send-email 1.6.3.3
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="------------true"
Cc: Ian.Jackson@eu.citrix.com, allen.m.kay@intel.com,
	Jean Guyader <jean.guyader@eu.citrix.com>, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH] qemu-xen: Intel GPU passthrough,
	fix OpRegion mapping. (v2)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--------------true
Content-Type: text/plain; charset="UTF-8"; format=fixed
Content-Transfer-Encoding: 8bit


The OpRegion shouldn't be mapped 1:1 because the address in the host
can't be used in the guest directly.

This patch traps read and write access to the opregion of the Intel
GPU config space (offset 0xfc).

To work correctly this patch needs a change in hvmloader.

HVMloader will allocate 2 pages for the OpRegion and write this address
on the config space of the Intel GPU. Qemu will trap and map the host
OpRegion to the guest. Any write to this offset after that won't have
any effect. Any read of this config space offset will return the address
in the guest.

Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
---
 hw/pass-through.c |   52 ++++++++++++++++++++++++++++++++++---
 hw/pass-through.h |    4 +++
 hw/pt-graphics.c  |   73 +++++++++++++++++++++++++++++++++++++++--------------
 3 files changed, 105 insertions(+), 24 deletions(-)


--------------true
Content-Type: text/x-patch;
	name="0001-qemu-xen-Intel-GPU-passthrough-fix-OpRegion-mapping..patch"
Content-Transfer-Encoding: 8bit
Content-Disposition: attachment;
	filename="0001-qemu-xen-Intel-GPU-passthrough-fix-OpRegion-mapping..patch"

diff --git a/hw/pass-through.c b/hw/pass-through.c
index 919937f..1378022 100644
--- a/hw/pass-through.c
+++ b/hw/pass-through.c
@@ -237,6 +237,14 @@ static int pt_bar_reg_restore(struct pt_dev *ptdev,
 static int pt_exp_rom_bar_reg_restore(struct pt_dev *ptdev,
     struct pt_reg_tbl *cfg_entry,
     uint32_t real_offset, uint32_t dev_value, uint32_t *value);
+static int pt_intel_opregion_read(struct pt_dev *ptdev,
+        struct pt_reg_tbl *cfg_entry,
+        uint32_t *value, uint32_t valid_mask);
+static int pt_intel_opregion_write(struct pt_dev *ptdev,
+        struct pt_reg_tbl *cfg_entry,
+        uint32_t *value, uint32_t dev_value, uint32_t valid_mask);
+static uint8_t pt_reg_grp_header0_size_init(struct pt_dev *ptdev,
+        struct pt_reg_grp_info_tbl *grp_reg, uint32_t base_offset);
 
 /* pt_reg_info_tbl declaration
  * - only for emulated register (either a part or whole bit).
@@ -443,6 +451,18 @@ static struct pt_reg_info_tbl pt_emu_reg_header0_tbl[] = {
         .u.dw.write = pt_exp_rom_bar_reg_write,
         .u.dw.restore = pt_exp_rom_bar_reg_restore,
     },
+    /* Vendor ID reg */
+    {
+        .offset     = PCI_INTEL_OPREGION,
+        .size       = 4,
+        .init_val   = 0x0000,
+        .ro_mask    = 0xFFFFFFFF,
+        .emu_mask   = 0xFFFFFFFF,
+        .init       = pt_common_reg_init,
+        .u.dw.read   = pt_intel_opregion_read,
+        .u.dw.write  = pt_intel_opregion_write,
+        .u.dw.restore  = NULL,
+    },
     {
         .size = 0,
     },
@@ -736,7 +756,7 @@ static const struct pt_reg_grp_info_tbl pt_emu_reg_grp_tbl[] = {
         .grp_id     = 0xFF,
         .grp_type   = GRP_TYPE_EMU,
         .grp_size   = 0x40,
-        .size_init  = pt_reg_grp_size_init,
+        .size_init  = pt_reg_grp_header0_size_init,
         .emu_reg_tbl= pt_emu_reg_header0_tbl,
     },
     /* PCI PowerManagement Capability reg group */
@@ -1400,7 +1420,7 @@ static struct pt_reg_grp_tbl* pt_find_reg_grp(struct pt_dev *ptdev,
     {
         /* check address */
         if ((reg_grp_entry->base_offset <= address) &&
-            ((reg_grp_entry->base_offset + reg_grp_entry->size) > address))
+            ((reg_grp_entry->base_offset + reg_grp_entry->size) >= address))
             goto out;
     }
     /* group entry not found */
@@ -1455,8 +1475,7 @@ out:
     return index;
 }
 
-static void pt_pci_write_config(PCIDevice *d, uint32_t address, uint32_t val,
-                                int len)
+void pt_pci_write_config(PCIDevice *d, uint32_t address, uint32_t val, int len)
 {
     struct pt_dev *assigned_device = (struct pt_dev *)d;
     struct pci_dev *pci_dev = assigned_device->pci_dev;
@@ -1637,7 +1656,7 @@ exit:
     return;
 }
 
-static uint32_t pt_pci_read_config(PCIDevice *d, uint32_t address, int len)
+uint32_t pt_pci_read_config(PCIDevice *d, uint32_t address, int len)
 {
     struct pt_dev *assigned_device = (struct pt_dev *)d;
     struct pci_dev *pci_dev = assigned_device->pci_dev;
@@ -2965,6 +2984,14 @@ static uint32_t pt_msixctrl_reg_init(struct pt_dev *ptdev,
     return reg->init_val;
 }
 
+static uint8_t pt_reg_grp_header0_size_init(struct pt_dev *ptdev,
+        struct pt_reg_grp_info_tbl *grp_reg, uint32_t base_offset)
+{
+    if (igd_passthru)
+        return 0xFF;
+    return grp_reg->grp_size;
+}
+
 /* get register group size */
 static uint8_t pt_reg_grp_size_init(struct pt_dev *ptdev,
         struct pt_reg_grp_info_tbl *grp_reg, uint32_t base_offset)
@@ -4113,6 +4140,21 @@ static int pt_pmcsr_reg_restore(struct pt_dev *ptdev,
     return 0;
 }
 
+static int pt_intel_opregion_read(struct pt_dev *ptdev,
+        struct pt_reg_tbl *cfg_entry,
+        uint32_t *value, uint32_t valid_mask)
+{
+    *value = igd_read_opregion(ptdev);
+    return 0;
+}
+
+static int pt_intel_opregion_write(struct pt_dev *ptdev,
+        struct pt_reg_tbl *cfg_entry,
+        uint32_t *value, uint32_t dev_value, uint32_t valid_mask)
+{
+    igd_write_opregion(ptdev, *value);
+    return 0;
+}
 static struct pt_dev * register_real_device(PCIBus *e_bus,
         const char *e_dev_name, int e_devfn, uint8_t r_bus, uint8_t r_dev,
         uint8_t r_func, uint32_t machine_irq, struct pci_access *pci_access,
diff --git a/hw/pass-through.h b/hw/pass-through.h
index 884139c..9ab9638 100644
--- a/hw/pass-through.h
+++ b/hw/pass-through.h
@@ -422,6 +422,10 @@ PCIBus *intel_pci_bridge_init(PCIBus *bus, int devfn, uint16_t vid,
            uint16_t did, const char *name, uint16_t revision);
 void igd_pci_write(PCIDevice *pci_dev, uint32_t config_addr, uint32_t val, int len);
 uint32_t igd_pci_read(PCIDevice *pci_dev, uint32_t config_addr, int len);
+uint32_t igd_read_opregion(struct pt_dev *pci_dev);
+void igd_write_opregion(struct pt_dev *real_dev, uint32_t val);
+uint32_t pt_pci_read_config(PCIDevice *d, uint32_t address, int len);
+void pt_pci_write_config(PCIDevice *d, uint32_t address, uint32_t val, int len);
 
 #endif /* __PASSTHROUGH_H__ */
 
diff --git a/hw/pt-graphics.c b/hw/pt-graphics.c
index fec7390..2e1dc44 100644
--- a/hw/pt-graphics.c
+++ b/hw/pt-graphics.c
@@ -13,6 +13,8 @@
 extern int gfx_passthru;
 extern int igd_passthru;
 
+static uint32_t igd_guest_opregion = 0;
+
 static int pch_map_irq(PCIDevice *pci_dev, int irq_num)
 {
     PT_LOG("pch_map_irq called\n");
@@ -37,6 +39,54 @@ void intel_pch_init(PCIBus *bus)
                         pch_map_irq, "intel_bridge_1f");
 }
 
+uint32_t igd_read_opregion(struct pt_dev *pci_dev)
+{
+    uint32_t val = -1;
+
+    if ( igd_guest_opregion )
+        val = pt_pci_read_config((PCIDevice*)pci_dev, PCI_INTEL_OPREGION, 4);
+
+#ifdef PT_DEBUG_PCI_CONFIG_ACCESS
+    PT_LOG_DEV((PCIDevice*)pci_dev, "addr=%x len=%x val=%x\n",
+            PCI_INTEL_OPREGION, 4, val);
+#endif
+    return val;
+}
+
+void igd_write_opregion(struct pt_dev *real_dev, uint32_t val)
+{
+    uint32_t host_opregion = 0;
+    int ret;
+
+    if ( igd_guest_opregion )
+    {
+        PT_LOG("opregion register already been set, ignoring %x\n", val);
+        return;
+    }
+
+    host_opregion = pt_pci_host_read(real_dev->pci_dev,
+            PCI_INTEL_OPREGION, 4);
+    igd_guest_opregion = (val & ~0xfff) | (host_opregion & 0xfff);
+    PT_LOG("Map OpRegion: %x -> %x\n", host_opregion, igd_guest_opregion);
+
+    ret = xc_domain_memory_mapping(xc_handle, domid,
+            igd_guest_opregion >> XC_PAGE_SHIFT,
+            host_opregion >> XC_PAGE_SHIFT,
+            2,
+            DPCI_ADD_MAPPING);
+
+    if ( ret != 0 )
+    {
+        PT_LOG("Error: Can't map opregion\n");
+        igd_guest_opregion = 0;
+    }
+#ifdef PT_DEBUG_PCI_CONFIG_ACCESS
+    PT_LOG_DEV((PCIDevice*)real_dev, "addr=%x len=%lx val=%x\n",
+            PCI_INTEL_OPREGION, len, val);
+#endif
+
+}
+
 void igd_pci_write(PCIDevice *pci_dev, uint32_t config_addr, uint32_t val, int len)
 {
     struct pci_dev *pci_dev_host_bridge = pt_pci_get_dev(0, 0, 0);
@@ -99,7 +149,6 @@ uint32_t igd_pci_read(PCIDevice *pci_dev, uint32_t config_addr, int len)
 int register_vga_regions(struct pt_dev *real_device)
 {
     u16 vendor_id;
-    int igd_opregion;
     int ret = 0;
 
     if ( !gfx_passthru || real_device->pci_dev->device_class != 0x0300 )
@@ -117,19 +166,6 @@ int register_vga_regions(struct pt_dev *real_device)
             0x20,
             DPCI_ADD_MAPPING);
 
-    /* 1:1 map ASL Storage register value */
-    vendor_id = pt_pci_host_read(real_device->pci_dev, 0, 2);
-    igd_opregion = pt_pci_host_read(real_device->pci_dev, PCI_INTEL_OPREGION, 4);
-    if ( (vendor_id == PCI_VENDOR_ID_INTEL ) && igd_opregion )
-    {
-        ret |= xc_domain_memory_mapping(xc_handle, domid,
-                igd_opregion >> XC_PAGE_SHIFT,
-                igd_opregion >> XC_PAGE_SHIFT,
-                2,
-                DPCI_ADD_MAPPING);
-        PT_LOG("register_vga: igd_opregion = %x\n", igd_opregion);
-    }
-
     if ( ret != 0 )
         PT_LOG("VGA region mapping failed\n");
 
@@ -141,7 +177,7 @@ int register_vga_regions(struct pt_dev *real_device)
  */
 int unregister_vga_regions(struct pt_dev *real_device)
 {
-    u32 vendor_id, igd_opregion;
+    u32 vendor_id;
     int ret = 0;
 
     if ( !gfx_passthru || real_device->pci_dev->device_class != 0x0300 )
@@ -160,12 +196,11 @@ int unregister_vga_regions(struct pt_dev *real_device)
             DPCI_REMOVE_MAPPING);
 
     vendor_id = pt_pci_host_read(real_device->pci_dev, PCI_VENDOR_ID, 2);
-    igd_opregion = pt_pci_host_read(real_device->pci_dev, PCI_INTEL_OPREGION, 4);
-    if ( (vendor_id == PCI_VENDOR_ID_INTEL) && igd_opregion )
+    if ( (vendor_id == PCI_VENDOR_ID_INTEL) && igd_guest_opregion )
     {
         ret |= xc_domain_memory_mapping(xc_handle, domid,
-                igd_opregion >> XC_PAGE_SHIFT,
-                igd_opregion >> XC_PAGE_SHIFT,
+                igd_guest_opregion >> XC_PAGE_SHIFT,
+                igd_guest_opregion >> XC_PAGE_SHIFT,
                 2,
                 DPCI_REMOVE_MAPPING);
     }

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

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

--------------true--


From xen-devel-bounces@lists.xensource.com Fri Dec 02 16:48:42 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 16: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.xensource.com>)
	id 1RWWHn-0007yz-Dk; Fri, 02 Dec 2011 16:48:31 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Jean.Guyader@citrix.com>) id 1RWWHm-0007y7-06
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 16:48:30 +0000
X-Env-Sender: Jean.Guyader@citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1322844468!5940582!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTg0Mw==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4864 invoked from network); 2 Dec 2011 16:47:48 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Dec 2011 16:47:48 -0000
X-IronPort-AV: E=Sophos;i="4.71,284,1320624000"; 
   d="scan'208";a="9256287"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Dec 2011 16:47:42 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 2 Dec 2011 16:47:42 +0000
Received: from spongy.cam.xci-test.com ([10.80.248.53])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<jean.guyader@eu.citrix.com>)	id 1RWWGz-0003RO-L6;
	Fri, 02 Dec 2011 16:47:41 +0000
Received: from jeangu by spongy.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <jean.guyader@eu.citrix.com>)	id 1RWWGj-00019v-Ap;
	Fri, 02 Dec 2011 16:47:25 +0000
From: Jean Guyader <jean.guyader@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Fri, 2 Dec 2011 16:47:23 +0000
Message-ID: <1322844443-4427-1-git-send-email-jean.guyader@eu.citrix.com>
X-Mailer: git-send-email 1.6.3.3
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="------------true"
Cc: Ian.Jackson@eu.citrix.com, allen.m.kay@intel.com,
	Jean Guyader <jean.guyader@eu.citrix.com>, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH] qemu-xen: Intel GPU passthrough,
	fix OpRegion mapping. (v2)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--------------true
Content-Type: text/plain; charset="UTF-8"; format=fixed
Content-Transfer-Encoding: 8bit


The OpRegion shouldn't be mapped 1:1 because the address in the host
can't be used in the guest directly.

This patch traps read and write access to the opregion of the Intel
GPU config space (offset 0xfc).

To work correctly this patch needs a change in hvmloader.

HVMloader will allocate 2 pages for the OpRegion and write this address
on the config space of the Intel GPU. Qemu will trap and map the host
OpRegion to the guest. Any write to this offset after that won't have
any effect. Any read of this config space offset will return the address
in the guest.

Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
---
 hw/pass-through.c |   52 ++++++++++++++++++++++++++++++++++---
 hw/pass-through.h |    4 +++
 hw/pt-graphics.c  |   73 +++++++++++++++++++++++++++++++++++++++--------------
 3 files changed, 105 insertions(+), 24 deletions(-)


--------------true
Content-Type: text/x-patch;
	name="0001-qemu-xen-Intel-GPU-passthrough-fix-OpRegion-mapping..patch"
Content-Transfer-Encoding: 8bit
Content-Disposition: attachment;
	filename="0001-qemu-xen-Intel-GPU-passthrough-fix-OpRegion-mapping..patch"

diff --git a/hw/pass-through.c b/hw/pass-through.c
index 919937f..1378022 100644
--- a/hw/pass-through.c
+++ b/hw/pass-through.c
@@ -237,6 +237,14 @@ static int pt_bar_reg_restore(struct pt_dev *ptdev,
 static int pt_exp_rom_bar_reg_restore(struct pt_dev *ptdev,
     struct pt_reg_tbl *cfg_entry,
     uint32_t real_offset, uint32_t dev_value, uint32_t *value);
+static int pt_intel_opregion_read(struct pt_dev *ptdev,
+        struct pt_reg_tbl *cfg_entry,
+        uint32_t *value, uint32_t valid_mask);
+static int pt_intel_opregion_write(struct pt_dev *ptdev,
+        struct pt_reg_tbl *cfg_entry,
+        uint32_t *value, uint32_t dev_value, uint32_t valid_mask);
+static uint8_t pt_reg_grp_header0_size_init(struct pt_dev *ptdev,
+        struct pt_reg_grp_info_tbl *grp_reg, uint32_t base_offset);
 
 /* pt_reg_info_tbl declaration
  * - only for emulated register (either a part or whole bit).
@@ -443,6 +451,18 @@ static struct pt_reg_info_tbl pt_emu_reg_header0_tbl[] = {
         .u.dw.write = pt_exp_rom_bar_reg_write,
         .u.dw.restore = pt_exp_rom_bar_reg_restore,
     },
+    /* Vendor ID reg */
+    {
+        .offset     = PCI_INTEL_OPREGION,
+        .size       = 4,
+        .init_val   = 0x0000,
+        .ro_mask    = 0xFFFFFFFF,
+        .emu_mask   = 0xFFFFFFFF,
+        .init       = pt_common_reg_init,
+        .u.dw.read   = pt_intel_opregion_read,
+        .u.dw.write  = pt_intel_opregion_write,
+        .u.dw.restore  = NULL,
+    },
     {
         .size = 0,
     },
@@ -736,7 +756,7 @@ static const struct pt_reg_grp_info_tbl pt_emu_reg_grp_tbl[] = {
         .grp_id     = 0xFF,
         .grp_type   = GRP_TYPE_EMU,
         .grp_size   = 0x40,
-        .size_init  = pt_reg_grp_size_init,
+        .size_init  = pt_reg_grp_header0_size_init,
         .emu_reg_tbl= pt_emu_reg_header0_tbl,
     },
     /* PCI PowerManagement Capability reg group */
@@ -1400,7 +1420,7 @@ static struct pt_reg_grp_tbl* pt_find_reg_grp(struct pt_dev *ptdev,
     {
         /* check address */
         if ((reg_grp_entry->base_offset <= address) &&
-            ((reg_grp_entry->base_offset + reg_grp_entry->size) > address))
+            ((reg_grp_entry->base_offset + reg_grp_entry->size) >= address))
             goto out;
     }
     /* group entry not found */
@@ -1455,8 +1475,7 @@ out:
     return index;
 }
 
-static void pt_pci_write_config(PCIDevice *d, uint32_t address, uint32_t val,
-                                int len)
+void pt_pci_write_config(PCIDevice *d, uint32_t address, uint32_t val, int len)
 {
     struct pt_dev *assigned_device = (struct pt_dev *)d;
     struct pci_dev *pci_dev = assigned_device->pci_dev;
@@ -1637,7 +1656,7 @@ exit:
     return;
 }
 
-static uint32_t pt_pci_read_config(PCIDevice *d, uint32_t address, int len)
+uint32_t pt_pci_read_config(PCIDevice *d, uint32_t address, int len)
 {
     struct pt_dev *assigned_device = (struct pt_dev *)d;
     struct pci_dev *pci_dev = assigned_device->pci_dev;
@@ -2965,6 +2984,14 @@ static uint32_t pt_msixctrl_reg_init(struct pt_dev *ptdev,
     return reg->init_val;
 }
 
+static uint8_t pt_reg_grp_header0_size_init(struct pt_dev *ptdev,
+        struct pt_reg_grp_info_tbl *grp_reg, uint32_t base_offset)
+{
+    if (igd_passthru)
+        return 0xFF;
+    return grp_reg->grp_size;
+}
+
 /* get register group size */
 static uint8_t pt_reg_grp_size_init(struct pt_dev *ptdev,
         struct pt_reg_grp_info_tbl *grp_reg, uint32_t base_offset)
@@ -4113,6 +4140,21 @@ static int pt_pmcsr_reg_restore(struct pt_dev *ptdev,
     return 0;
 }
 
+static int pt_intel_opregion_read(struct pt_dev *ptdev,
+        struct pt_reg_tbl *cfg_entry,
+        uint32_t *value, uint32_t valid_mask)
+{
+    *value = igd_read_opregion(ptdev);
+    return 0;
+}
+
+static int pt_intel_opregion_write(struct pt_dev *ptdev,
+        struct pt_reg_tbl *cfg_entry,
+        uint32_t *value, uint32_t dev_value, uint32_t valid_mask)
+{
+    igd_write_opregion(ptdev, *value);
+    return 0;
+}
 static struct pt_dev * register_real_device(PCIBus *e_bus,
         const char *e_dev_name, int e_devfn, uint8_t r_bus, uint8_t r_dev,
         uint8_t r_func, uint32_t machine_irq, struct pci_access *pci_access,
diff --git a/hw/pass-through.h b/hw/pass-through.h
index 884139c..9ab9638 100644
--- a/hw/pass-through.h
+++ b/hw/pass-through.h
@@ -422,6 +422,10 @@ PCIBus *intel_pci_bridge_init(PCIBus *bus, int devfn, uint16_t vid,
            uint16_t did, const char *name, uint16_t revision);
 void igd_pci_write(PCIDevice *pci_dev, uint32_t config_addr, uint32_t val, int len);
 uint32_t igd_pci_read(PCIDevice *pci_dev, uint32_t config_addr, int len);
+uint32_t igd_read_opregion(struct pt_dev *pci_dev);
+void igd_write_opregion(struct pt_dev *real_dev, uint32_t val);
+uint32_t pt_pci_read_config(PCIDevice *d, uint32_t address, int len);
+void pt_pci_write_config(PCIDevice *d, uint32_t address, uint32_t val, int len);
 
 #endif /* __PASSTHROUGH_H__ */
 
diff --git a/hw/pt-graphics.c b/hw/pt-graphics.c
index fec7390..2e1dc44 100644
--- a/hw/pt-graphics.c
+++ b/hw/pt-graphics.c
@@ -13,6 +13,8 @@
 extern int gfx_passthru;
 extern int igd_passthru;
 
+static uint32_t igd_guest_opregion = 0;
+
 static int pch_map_irq(PCIDevice *pci_dev, int irq_num)
 {
     PT_LOG("pch_map_irq called\n");
@@ -37,6 +39,54 @@ void intel_pch_init(PCIBus *bus)
                         pch_map_irq, "intel_bridge_1f");
 }
 
+uint32_t igd_read_opregion(struct pt_dev *pci_dev)
+{
+    uint32_t val = -1;
+
+    if ( igd_guest_opregion )
+        val = pt_pci_read_config((PCIDevice*)pci_dev, PCI_INTEL_OPREGION, 4);
+
+#ifdef PT_DEBUG_PCI_CONFIG_ACCESS
+    PT_LOG_DEV((PCIDevice*)pci_dev, "addr=%x len=%x val=%x\n",
+            PCI_INTEL_OPREGION, 4, val);
+#endif
+    return val;
+}
+
+void igd_write_opregion(struct pt_dev *real_dev, uint32_t val)
+{
+    uint32_t host_opregion = 0;
+    int ret;
+
+    if ( igd_guest_opregion )
+    {
+        PT_LOG("opregion register already been set, ignoring %x\n", val);
+        return;
+    }
+
+    host_opregion = pt_pci_host_read(real_dev->pci_dev,
+            PCI_INTEL_OPREGION, 4);
+    igd_guest_opregion = (val & ~0xfff) | (host_opregion & 0xfff);
+    PT_LOG("Map OpRegion: %x -> %x\n", host_opregion, igd_guest_opregion);
+
+    ret = xc_domain_memory_mapping(xc_handle, domid,
+            igd_guest_opregion >> XC_PAGE_SHIFT,
+            host_opregion >> XC_PAGE_SHIFT,
+            2,
+            DPCI_ADD_MAPPING);
+
+    if ( ret != 0 )
+    {
+        PT_LOG("Error: Can't map opregion\n");
+        igd_guest_opregion = 0;
+    }
+#ifdef PT_DEBUG_PCI_CONFIG_ACCESS
+    PT_LOG_DEV((PCIDevice*)real_dev, "addr=%x len=%lx val=%x\n",
+            PCI_INTEL_OPREGION, len, val);
+#endif
+
+}
+
 void igd_pci_write(PCIDevice *pci_dev, uint32_t config_addr, uint32_t val, int len)
 {
     struct pci_dev *pci_dev_host_bridge = pt_pci_get_dev(0, 0, 0);
@@ -99,7 +149,6 @@ uint32_t igd_pci_read(PCIDevice *pci_dev, uint32_t config_addr, int len)
 int register_vga_regions(struct pt_dev *real_device)
 {
     u16 vendor_id;
-    int igd_opregion;
     int ret = 0;
 
     if ( !gfx_passthru || real_device->pci_dev->device_class != 0x0300 )
@@ -117,19 +166,6 @@ int register_vga_regions(struct pt_dev *real_device)
             0x20,
             DPCI_ADD_MAPPING);
 
-    /* 1:1 map ASL Storage register value */
-    vendor_id = pt_pci_host_read(real_device->pci_dev, 0, 2);
-    igd_opregion = pt_pci_host_read(real_device->pci_dev, PCI_INTEL_OPREGION, 4);
-    if ( (vendor_id == PCI_VENDOR_ID_INTEL ) && igd_opregion )
-    {
-        ret |= xc_domain_memory_mapping(xc_handle, domid,
-                igd_opregion >> XC_PAGE_SHIFT,
-                igd_opregion >> XC_PAGE_SHIFT,
-                2,
-                DPCI_ADD_MAPPING);
-        PT_LOG("register_vga: igd_opregion = %x\n", igd_opregion);
-    }
-
     if ( ret != 0 )
         PT_LOG("VGA region mapping failed\n");
 
@@ -141,7 +177,7 @@ int register_vga_regions(struct pt_dev *real_device)
  */
 int unregister_vga_regions(struct pt_dev *real_device)
 {
-    u32 vendor_id, igd_opregion;
+    u32 vendor_id;
     int ret = 0;
 
     if ( !gfx_passthru || real_device->pci_dev->device_class != 0x0300 )
@@ -160,12 +196,11 @@ int unregister_vga_regions(struct pt_dev *real_device)
             DPCI_REMOVE_MAPPING);
 
     vendor_id = pt_pci_host_read(real_device->pci_dev, PCI_VENDOR_ID, 2);
-    igd_opregion = pt_pci_host_read(real_device->pci_dev, PCI_INTEL_OPREGION, 4);
-    if ( (vendor_id == PCI_VENDOR_ID_INTEL) && igd_opregion )
+    if ( (vendor_id == PCI_VENDOR_ID_INTEL) && igd_guest_opregion )
     {
         ret |= xc_domain_memory_mapping(xc_handle, domid,
-                igd_opregion >> XC_PAGE_SHIFT,
-                igd_opregion >> XC_PAGE_SHIFT,
+                igd_guest_opregion >> XC_PAGE_SHIFT,
+                igd_guest_opregion >> XC_PAGE_SHIFT,
                 2,
                 DPCI_REMOVE_MAPPING);
     }

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

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

--------------true--


From xen-devel-bounces@lists.xensource.com Fri Dec 02 16:51:17 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 16: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.xensource.com>)
	id 1RWWKI-0008FM-6U; Fri, 02 Dec 2011 16:51:06 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1RWWKH-0008F9-6h
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 16:51:05 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-11.tower-21.messagelabs.com!1322844616!6561654!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23590 invoked from network); 2 Dec 2011 16:50:17 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-11.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 2 Dec 2011 16:50:17 -0000
Received: from andromeda.dapyr.net (darnok@localhost [127.0.0.1])
	by andromeda.dapyr.net (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id
	pB2Go40j008087
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Fri, 2 Dec 2011 11:50:04 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pB2Go3CW008085;
	Fri, 2 Dec 2011 11:50:03 -0500
Date: Fri, 2 Dec 2011 12:50:03 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20111202165003.GA7807@andromeda.dapyr.net>
References: <patchbomb.1322772713@xdev.gridcentric.ca>
	<1170bc32db41a7ae1e95.1322772715@xdev.gridcentric.ca>
	<20111202013430.GB636@andromeda.dapyr.net>
	<8940966a49442039be1480307f59656b.squirrel@webmail.lagarcavilla.org>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <8940966a49442039be1480307f59656b.squirrel@webmail.lagarcavilla.org>
User-Agent: Mutt/1.5.9i
Cc: olaf@aepfle.de, xen-devel@lists.xensource.com, andres@gridcentric.ca,
	jonathan.ludlam@eu.citrix.com, jbeulich@suse.com, mike.mcclurg@citrix.com
Subject: Re: [Xen-devel] [PATCH 2 of 2] xenpaging: handle GNTST_eagain in
	kernel drivers
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Dec 02, 2011 at 07:27:20AM -0800, Andres Lagar-Cavilla wrote:
> > On Thu, Dec 01, 2011 at 03:51:55PM -0500, Andres Lagar-Cavilla wrote:
> >>  drivers/xen/blkback/blkback.c              |   6 ++-
> >>  drivers/xen/blkback/interface.c            |   9 +++-
> >>  drivers/xen/core/gnttab.c                  |   4 +-
> >>  drivers/xen/gntdev/gntdev.c                |  49
> >> +++++++++++++++++------------
> >>  drivers/xen/netback/interface.c            |   5 +-
> >>  drivers/xen/netback/netback.c              |  16 ++++++---
> >>  drivers/xen/scsiback/interface.c           |  10 +++---
> >>  drivers/xen/scsiback/scsiback.c            |   4 +-
> >>  drivers/xen/tpmback/interface.c            |   7 +--
> >>  drivers/xen/tpmback/tpmback.c              |  20 ++++-------
> >>  drivers/xen/usbback/interface.c            |  16 ++++----
> >>  drivers/xen/usbback/usbback.c              |   4 +-
> >>  drivers/xen/xenbus/xenbus_backend_client.c |  10 +++---
> >>  include/xen/gnttab.h                       |  37 ++++++++++++++++++++++
> >>  14 files changed, 126 insertions(+), 71 deletions(-)
> >>
> >>
> >> Handle GNTST_eagain status from GNTTABOP_map_grant_ref and
> >> GNTTABOP_copy operations properly to allow usage of xenpaging without
> >> causing crashes or data corruption.
> >>
> >> Replace all relevant HYPERVISOR_grant_table_op() calls with a retry
> >> loop. This loop is implemented as a macro to allow different
> >> GNTTABOP_* args. It will sleep up to 33 seconds and wait for the
> >> page to be paged in again.
> >>
> >> All ->status checks were updated to use the GNTST_* namespace. All
> >> return values are converted from GNTST_* namespace to 0/-EINVAL, since
> >> all callers did not use the actual return value.
> >
> > Any plans to do this for the pvops tree?
> Slowly but surely. Working with XCP presently, so pvops is not at the top
> of my stack. Do you want to get at a specific merge window?

Its more of a review concern. Meaning that if you send for the upstream
kernel lots of folks are going to be looking at it. So the patches
will change - which means that the version upstream can be very
different from the one that you have for XCP - so in the end you will
have to deal with two different code-bases to maintain.

That can get a bit difficult to manage.

Granted not all of those drivers are in the upstream kernel so might not
make any difference.

> 
> Andres
> >
> >>
> >> Signed-off-by: Olaf Hering <olaf@aepfle.de>
> >> Acked-by: Patrick Colp <pjcolp@cs.ubc.ca>
> >>
> >> This is a port from xenlinux 2.6.18 to the 2.6.32 xcp tree
> >> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
> >>
> >> diff -r df9e25a0189b -r 1170bc32db41 drivers/xen/blkback/blkback.c
> >> --- a/drivers/xen/blkback/blkback.c
> >> +++ b/drivers/xen/blkback/blkback.c
> >> @@ -701,11 +701,13 @@ static void dispatch_rw_block_io(blkif_t
> >>  	BUG_ON(ret);
> >>
> >>  	for (i = 0; i < nseg; i++) {
> >> -		if (unlikely(map[i].status != 0)) {
> >> +		if (unlikely(map[i].status == GNTST_eagain))
> >> +			gnttab_check_GNTST_eagain_do_while(GNTTABOP_map_grant_ref, &map[i]);
> >> +		if (unlikely(map[i].status != GNTST_okay)) {
> >>  			DPRINTK("grant map of dom %u gref %u failed: status %d\n",
> >>  				blkif->domid, req->seg[i].gref, map[i].status);
> >>  			map[i].handle = BLKBACK_INVALID_HANDLE;
> >> -			ret |= 1;
> >> +			ret = 1;
> >>  			continue;
> >>  		}
> >>
> >> diff -r df9e25a0189b -r 1170bc32db41 drivers/xen/blkback/interface.c
> >> --- a/drivers/xen/blkback/interface.c
> >> +++ b/drivers/xen/blkback/interface.c
> >> @@ -95,7 +95,7 @@ static int map_frontend_pages(blkif_t *b
> >>  	struct vm_struct *area = blkif->blk_ring_area;
> >>  	struct gnttab_map_grant_ref op[BLKIF_MAX_RING_PAGES];
> >>  	unsigned int i;
> >> -	int status = 0;
> >> +	int status = GNTST_okay;
> >>
> >>  	for (i = 0; i < nr_shared_pages; i++) {
> >>  		unsigned long addr = (unsigned long)area->addr +
> >> @@ -110,7 +110,10 @@ static int map_frontend_pages(blkif_t *b
> >>  		BUG();
> >>
> >>  	for (i = 0; i < nr_shared_pages; i++) {
> >> -		if ((status = op[i].status) != 0) {
> >> +		if (op[i].status == GNTST_eagain)
> >> +			gnttab_check_GNTST_eagain_do_while(GNTTABOP_map_grant_ref, &op[i]);
> >> +		if (op[i].status != GNTST_okay) {
> >> +			status = op[i].status;
> >>  			blkif->shmem_handle[i] = INVALID_GRANT_HANDLE;
> >>  			continue;
> >>  		}
> >> @@ -120,7 +123,7 @@ static int map_frontend_pages(blkif_t *b
> >>
> >>  	blkif->nr_shared_pages = nr_shared_pages;
> >>
> >> -	if (status != 0) {
> >> +	if (status != GNTST_okay) {
> >>  		DPRINTK(" Grant table operation failure !\n");
> >>  		unmap_frontend_pages(blkif);
> >>  	}
> >> diff -r df9e25a0189b -r 1170bc32db41 drivers/xen/core/gnttab.c
> >> --- a/drivers/xen/core/gnttab.c
> >> +++ b/drivers/xen/core/gnttab.c
> >> @@ -773,7 +773,7 @@ static int gnttab_map(unsigned int start
> >>  		return -ENOSYS;
> >>  	}
> >>
> >> -	BUG_ON(rc || setup.status);
> >> +	BUG_ON(rc || (setup.status != GNTST_okay));
> >>
> >>  	if (shared.raw == NULL)
> >>  		shared.raw = arch_gnttab_alloc_shared(gframes);
> >> @@ -901,7 +901,7 @@ int gnttab_copy_grant_page(grant_ref_t r
> >>  	err = HYPERVISOR_grant_table_op(GNTTABOP_unmap_and_replace,
> >>  					&unmap, 1);
> >>  	BUG_ON(err);
> >> -	BUG_ON(unmap.status);
> >> +	BUG_ON(unmap.status != GNTST_okay);
> >>
> >>  	write_sequnlock_irq(&gnttab_dma_lock);
> >>
> >> diff -r df9e25a0189b -r 1170bc32db41 drivers/xen/gntdev/gntdev.c
> >> --- a/drivers/xen/gntdev/gntdev.c
> >> +++ b/drivers/xen/gntdev/gntdev.c
> >> @@ -503,7 +503,7 @@ static int gntdev_mmap (struct file *fli
> >>  	uint64_t ptep;
> >>  	int ret;
> >>  	int flags;
> >> -	int i;
> >> +	int i, exit_ret;
> >>  	struct page *page;
> >>  	gntdev_file_private_data_t *private_data = flip->private_data;
> >>
> >> @@ -578,6 +578,7 @@ static int gntdev_mmap (struct file *fli
> >>  	vma->vm_mm->context.has_foreign_mappings = 1;
> >>  #endif
> >>
> >> +	exit_ret = -ENOMEM;
> >>  	for (i = 0; i < size; ++i) {
> >>
> >>  		flags = GNTMAP_host_map;
> >> @@ -598,14 +599,18 @@ static int gntdev_mmap (struct file *fli
> >>  		ret = HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref,
> >>  						&op, 1);
> >>  		BUG_ON(ret);
> >> -		if (op.status) {
> >> -			printk(KERN_ERR "Error mapping the grant reference "
> >> -			       "into the kernel (%d). domid = %d; ref = %d\n",
> >> -			       op.status,
> >> -			       private_data->grants[slot_index+i]
> >> -			       .u.valid.domid,
> >> -			       private_data->grants[slot_index+i]
> >> -			       .u.valid.ref);
> >> +		if (op.status != GNTST_okay) {
> >> +			if (op.status != GNTST_eagain)
> >> +				printk(KERN_ERR "Error mapping the grant reference "
> >> +					   "into the kernel (%d). domid = %d; ref = %d\n",
> >> +					   op.status,
> >> +					   private_data->grants[slot_index+i]
> >> +					   .u.valid.domid,
> >> +					   private_data->grants[slot_index+i]
> >> +					   .u.valid.ref);
> >> +			else
> >> +				/* Propagate instead of trying to fix it up */
> >> +				exit_ret = -EAGAIN;
> >>  			goto undo_map_out;
> >>  		}
> >>
> >> @@ -674,14 +679,17 @@ static int gntdev_mmap (struct file *fli
> >>  			ret = HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref,
> >>  							&op, 1);
> >>  			BUG_ON(ret);
> >> -			if (op.status) {
> >> +			if (op.status != GNTST_okay) {
> >>  				printk(KERN_ERR "Error mapping the grant "
> >> -				       "reference into user space (%d). domid "
> >> -				       "= %d; ref = %d\n", op.status,
> >> -				       private_data->grants[slot_index+i].u
> >> -				       .valid.domid,
> >> -				       private_data->grants[slot_index+i].u
> >> -				       .valid.ref);
> >> +					   "reference into user space (%d). domid "
> >> +					   "= %d; ref = %d\n", op.status,
> >> +					   private_data->grants[slot_index+i].u
> >> +					   .valid.domid,
> >> +					   private_data->grants[slot_index+i].u
> >> +					   .valid.ref);
> >> +				/* GNTST_eagain (i.e. page paged out) sohuld never happen
> >> +				 * once we've mapped into kernel space */
> >> +				BUG_ON(op.status == GNTST_eagain);
> >>  				goto undo_map_out;
> >>  			}
> >>
> >> @@ -705,9 +713,10 @@ static int gntdev_mmap (struct file *fli
> >>  		}
> >>
> >>  	}
> >> +	exit_ret = 0;
> >>
> >>  	up_write(&private_data->grants_sem);
> >> -	return 0;
> >> +	return exit_ret;
> >>
> >>  undo_map_out:
> >>  	/* If we have a mapping failure, the unmapping will be taken care of
> >> @@ -725,7 +734,7 @@ undo_map_out:
> >>
> >>  	up_write(&private_data->grants_sem);
> >>
> >> -	return -ENOMEM;
> >> +	return exit_ret;
> >>  }
> >>
> >>  static pte_t gntdev_clear_pte(struct vm_area_struct *vma, unsigned long
> >> addr,
> >> @@ -777,7 +786,7 @@ static pte_t gntdev_clear_pte(struct vm_
> >>  			ret = HYPERVISOR_grant_table_op(
> >>  				GNTTABOP_unmap_grant_ref, &op, 1);
> >>  			BUG_ON(ret);
> >> -			if (op.status)
> >> +			if (op.status != GNTST_okay)
> >>  				printk("User unmap grant status = %d\n",
> >>  				       op.status);
> >>  		} else {
> >> @@ -794,7 +803,7 @@ static pte_t gntdev_clear_pte(struct vm_
> >>  		ret = HYPERVISOR_grant_table_op(GNTTABOP_unmap_grant_ref,
> >>  						&op, 1);
> >>  		BUG_ON(ret);
> >> -		if (op.status)
> >> +		if (op.status != GNTST_okay)
> >>  			printk("Kernel unmap grant status = %d\n", op.status);
> >>
> >>
> >> diff -r df9e25a0189b -r 1170bc32db41 drivers/xen/netback/interface.c
> >> --- a/drivers/xen/netback/interface.c
> >> +++ b/drivers/xen/netback/interface.c
> >> @@ -381,10 +381,9 @@ static int map_frontend_pages(struct xen
> >>  	gnttab_set_map_op(&op, (unsigned long)comms->ring_area->addr,
> >>  			  GNTMAP_host_map, ring_ref, domid);
> >>
> >> -	if (HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, &op, 1))
> >> -		BUG();
> >> +	gnttab_check_GNTST_eagain_do_while(GNTTABOP_map_grant_ref, &op);
> >>
> >> -	if (op.status) {
> >> +	if (op.status != GNTST_okay) {
> >>  		DPRINTK(" Gnttab failure mapping ring_ref!\n");
> >>  		free_vm_area(comms->ring_area);
> >>  		return op.status;
> >> diff -r df9e25a0189b -r 1170bc32db41 drivers/xen/netback/netback.c
> >> --- a/drivers/xen/netback/netback.c
> >> +++ b/drivers/xen/netback/netback.c
> >> @@ -419,11 +419,13 @@ static int netbk_check_gop(int nr_copy_s
> >>
> >>  	for (i = 0; i < nr_copy_slots; i++) {
> >>  		copy_op = npo->copy + npo->copy_cons++;
> >> +		if (copy_op->status == GNTST_eagain)
> >> +			gnttab_check_GNTST_eagain_while(GNTTABOP_copy, copy_op);
> >>  		if (copy_op->status != GNTST_okay) {
> >> -				DPRINTK("Bad status %d from copy to DOM%d.\n",
> >> -					copy_op->status, domid);
> >> -				status = NETIF_RSP_ERROR;
> >> -			}
> >> +			DPRINTK("Bad status %d from copy to DOM%d.\n",
> >> +				copy_op->status, domid);
> >> +			status = NETIF_RSP_ERROR;
> >> +		}
> >>  	}
> >>
> >>  	return status;
> >> @@ -1020,7 +1022,11 @@ static int netbk_tx_check_mop(struct xen
> >>
> >>  	/* Check status of header. */
> >>  	err = mop->status;
> >> -	if (unlikely(err)) {
> >> +	if (err == GNTST_eagain) {
> >> +		gnttab_check_GNTST_eagain_do_while(GNTTABOP_map_grant_ref, mop);
> >> +		err = mop->status;
> >> +	}
> >> +	if (unlikely(err != GNTST_okay)) {
> >>  		pending_ring_idx_t index;
> >>  		index = pending_index(netbk->pending_prod++);
> >>  		txp = &pending_tx_info[pending_idx].req;
> >> diff -r df9e25a0189b -r 1170bc32db41 drivers/xen/scsiback/interface.c
> >> --- a/drivers/xen/scsiback/interface.c
> >> +++ b/drivers/xen/scsiback/interface.c
> >> @@ -69,18 +69,18 @@ static int map_frontend_page( struct vsc
> >>  				GNTMAP_host_map, ring_ref,
> >>  				info->domid);
> >>
> >> -	err = HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, &op, 1);
> >> -	BUG_ON(err);
> >> +	gnttab_check_GNTST_eagain_do_while(GNTTABOP_map_grant_ref, &op);
> >>
> >> -	if (op.status) {
> >> -		printk(KERN_ERR "scsiback: Grant table operation failure !\n");
> >> +	if (op.status != GNTST_okay) {
> >> +		printk(KERN_ERR "scsiback: Grant table operation failure %d!\n",
> >> +							(int) op.status);
> >>  		return op.status;
> >>  	}
> >>
> >>  	info->shmem_ref    = ring_ref;
> >>  	info->shmem_handle = op.handle;
> >>
> >> -	return (GNTST_okay);
> >> +	return 0;
> >>  }
> >>
> >>  static void unmap_frontend_page(struct vscsibk_info *info)
> >> diff -r df9e25a0189b -r 1170bc32db41 drivers/xen/scsiback/scsiback.c
> >> --- a/drivers/xen/scsiback/scsiback.c
> >> +++ b/drivers/xen/scsiback/scsiback.c
> >> @@ -287,7 +287,9 @@ static int scsiback_gnttab_data_map(vscs
> >>  		for_each_sg (pending_req->sgl, sg, nr_segments, i) {
> >>  			struct page *pg;
> >>
> >> -			if (unlikely(map[i].status != 0)) {
> >> +			if (unlikely(map[i].status == GNTST_eagain))
> >> +				gnttab_check_GNTST_eagain_while(GNTTABOP_map_grant_ref, &map[i]);
> >> +			if (unlikely(map[i].status != GNTST_okay)) {
> >>  				printk(KERN_ERR "scsiback: invalid buffer -- could not remap
> >> it\n");
> >>  				map[i].handle = SCSIBACK_INVALID_HANDLE;
> >>  				err |= 1;
> >> diff -r df9e25a0189b -r 1170bc32db41 drivers/xen/tpmback/interface.c
> >> --- a/drivers/xen/tpmback/interface.c
> >> +++ b/drivers/xen/tpmback/interface.c
> >> @@ -86,11 +86,10 @@ static int map_frontend_page(tpmif_t *tp
> >>  	gnttab_set_map_op(&op, (unsigned long)tpmif->tx_area->addr,
> >>  			  GNTMAP_host_map, shared_page, tpmif->domid);
> >>
> >> -	if (HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, &op, 1))
> >> -		BUG();
> >> +	gnttab_check_GNTST_eagain_do_while(GNTTABOP_map_grant_ref, &op);
> >>
> >> -	if (op.status) {
> >> -		DPRINTK(" Grant table operation failure !\n");
> >> +	if (op.status != GNTST_okay) {
> >> +		DPRINTK(" Grant table operation failure %d!\n", (int) op.status);
> >>  		return op.status;
> >>  	}
> >>
> >> diff -r df9e25a0189b -r 1170bc32db41 drivers/xen/tpmback/tpmback.c
> >> --- a/drivers/xen/tpmback/tpmback.c
> >> +++ b/drivers/xen/tpmback/tpmback.c
> >> @@ -256,15 +256,13 @@ int _packet_write(struct packet *pak,
> >>  		gnttab_set_map_op(&map_op, idx_to_kaddr(tpmif, i),
> >>  				  GNTMAP_host_map, tx->ref, tpmif->domid);
> >>
> >> -		if (unlikely(HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref,
> >> -						       &map_op, 1))) {
> >> -			BUG();
> >> -		}
> >> +		gnttab_check_GNTST_eagain_do_while(GNTTABOP_map_grant_ref, &map_op);
> >>
> >>  		handle = map_op.handle;
> >>
> >> -		if (map_op.status) {
> >> -			DPRINTK(" Grant table operation failure !\n");
> >> +		if (map_op.status != GNTST_okay) {
> >> +			DPRINTK(" Grant table operation failure %d!\n",
> >> +						(int) map_op.status);
> >>  			return 0;
> >>  		}
> >>
> >> @@ -394,13 +392,11 @@ static int packet_read_shmem(struct pack
> >>  		gnttab_set_map_op(&map_op, idx_to_kaddr(tpmif, i),
> >>  				  GNTMAP_host_map, tx->ref, tpmif->domid);
> >>
> >> -		if (unlikely(HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref,
> >> -						       &map_op, 1))) {
> >> -			BUG();
> >> -		}
> >> +		gnttab_check_GNTST_eagain_do_while(GNTTABOP_map_grant_ref, &map_op);
> >>
> >> -		if (map_op.status) {
> >> -			DPRINTK(" Grant table operation failure !\n");
> >> +		if (map_op.status != GNTST_okay) {
> >> +			DPRINTK(" Grant table operation failure %d!\n",
> >> +						(int) map_op.status);
> >>  			return -EFAULT;
> >>  		}
> >>
> >> diff -r df9e25a0189b -r 1170bc32db41 drivers/xen/usbback/interface.c
> >> --- a/drivers/xen/usbback/interface.c
> >> +++ b/drivers/xen/usbback/interface.c
> >> @@ -109,11 +109,11 @@ static int map_frontend_pages(usbif_t *u
> >>  	gnttab_set_map_op(&op, (unsigned long)usbif->urb_ring_area->addr,
> >>  			  GNTMAP_host_map, urb_ring_ref, usbif->domid);
> >>
> >> -	if (HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, &op, 1))
> >> -		BUG();
> >> +	gnttab_check_GNTST_eagain_do_while(GNTTABOP_map_grant_ref, &op);
> >>
> >> -	if (op.status) {
> >> -		printk(KERN_ERR "grant table failure mapping urb_ring_ref\n");
> >> +	if (op.status != GNTST_okay) {
> >> +		printk(KERN_ERR "grant table failure mapping urb_ring_ref %d\n",
> >> +							(int) op.status);
> >>  		return op.status;
> >>  	}
> >>
> >> @@ -123,17 +123,17 @@ static int map_frontend_pages(usbif_t *u
> >>  	gnttab_set_map_op(&op, (unsigned long)usbif->conn_ring_area->addr,
> >>  			  GNTMAP_host_map, conn_ring_ref, usbif->domid);
> >>
> >> -	if (HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, &op, 1))
> >> -		BUG();
> >> +	gnttab_check_GNTST_eagain_do_while(GNTTABOP_map_grant_ref, &op);
> >>
> >> -	if (op.status) {
> >> +	if (op.status != GNTST_okay) {
> >>  		struct gnttab_unmap_grant_ref unop;
> >>  		gnttab_set_unmap_op(&unop,
> >>  				(unsigned long) usbif->urb_ring_area->addr,
> >>  				GNTMAP_host_map, usbif->urb_shmem_handle);
> >>  		VOID(HYPERVISOR_grant_table_op(GNTTABOP_unmap_grant_ref, &unop,
> >>  				1));
> >> -		printk(KERN_ERR "grant table failure mapping conn_ring_ref\n");
> >> +		printk(KERN_ERR "grant table failure mapping conn_ring_ref %d\n",
> >> +							(int) op.status);
> >>  		return op.status;
> >>  	}
> >>
> >> diff -r df9e25a0189b -r 1170bc32db41 drivers/xen/usbback/usbback.c
> >> --- a/drivers/xen/usbback/usbback.c
> >> +++ b/drivers/xen/usbback/usbback.c
> >> @@ -428,7 +428,9 @@ static int usbbk_gnttab_map(usbif_t *usb
> >>  		BUG_ON(ret);
> >>
> >>  		for (i = 0; i < nr_segs; i++) {
> >> -			if (unlikely(map[i].status != 0)) {
> >> +			if (unlikely(map[i].status == GNTST_eagain))
> >> +				gnttab_check_GNTST_eagain_while(GNTTABOP_map_grant_ref, &map[i]);
> >> +			if (unlikely(map[i].status != GNTST_okay)) {
> >>  				printk(KERN_ERR "usbback: invalid buffer -- could not remap it\n");
> >>  				map[i].handle = USBBACK_INVALID_HANDLE;
> >>  				ret |= 1;
> >> diff -r df9e25a0189b -r 1170bc32db41
> >> drivers/xen/xenbus/xenbus_backend_client.c
> >> --- a/drivers/xen/xenbus/xenbus_backend_client.c
> >> +++ b/drivers/xen/xenbus/xenbus_backend_client.c
> >> @@ -48,8 +48,7 @@ struct vm_struct *xenbus_map_ring_valloc
> >>  	gnttab_set_map_op(&op, (unsigned long)area->addr, GNTMAP_host_map,
> >>  			  gnt_ref, dev->otherend_id);
> >>
> >> -	if (HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, &op, 1))
> >> -		BUG();
> >> +	gnttab_check_GNTST_eagain_do_while(GNTTABOP_map_grant_ref, &op);
> >>
> >>  	if (op.status != GNTST_okay) {
> >>  		free_vm_area(area);
> >> @@ -75,15 +74,16 @@ int xenbus_map_ring(struct xenbus_device
> >>
> >>  	gnttab_set_map_op(&op, (unsigned long)vaddr, GNTMAP_host_map,
> >>  			  gnt_ref, dev->otherend_id);
> >> -	if (HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, &op, 1))
> >> -		BUG();
> >> +	gnttab_check_GNTST_eagain_do_while(GNTTABOP_map_grant_ref, &op);
> >>
> >>  	if (op.status != GNTST_okay) {
> >>  		xenbus_dev_fatal(dev, op.status,
> >>  				 "mapping in shared page %d from domain %d",
> >>  				 gnt_ref, dev->otherend_id);
> >> -	} else
> >> +	} else {
> >>  		*handle = op.handle;
> >> +		return 0;
> >> +	}
> >>
> >>  	return op.status;
> >>  }
> >> diff -r df9e25a0189b -r 1170bc32db41 include/xen/gnttab.h
> >> --- a/include/xen/gnttab.h
> >> +++ b/include/xen/gnttab.h
> >> @@ -187,4 +187,41 @@ gnttab_set_replace_op(struct gnttab_unma
> >>  	unmap->handle = handle;
> >>  }
> >>
> >> +#define gnttab_check_GNTST_eagain_while(__HCop, __HCarg_p)					\
> >> +do {																		\
> >> +	u8 __hc_delay = 1;														\
> >> +	int __ret;																\
> >> +	while (unlikely((__HCarg_p)->status == GNTST_eagain && __hc_delay))
> >> {	\
> >> +		msleep(__hc_delay++);												\
> >> +		__ret = HYPERVISOR_grant_table_op(__HCop, (__HCarg_p), 1);			\
> >> +		BUG_ON(__ret);														\
> >> +	}																		\
> >> +	if (__hc_delay == 0) {													\
> >> +		printk(KERN_ERR "%s: %s gnt busy\n", __func__, current->comm);		\
> >> +		(__HCarg_p)->status = GNTST_bad_page;								\
> >> +	}																		\
> >> +	if ((__HCarg_p)->status != GNTST_okay)									\
> >> +		printk(KERN_ERR "%s: %s gnt status %x\n", 							\
> >> +			__func__, current->comm, (__HCarg_p)->status);					\
> >> +} while(0)
> >> +
> >> +#define gnttab_check_GNTST_eagain_do_while(__HCop, __HCarg_p)			\
> >> +do {																	\
> >> +	u8 __hc_delay = 1;													\
> >> +	int __ret;															\
> >> +	do {																\
> >> +		__ret = HYPERVISOR_grant_table_op(__HCop, (__HCarg_p), 1);		\
> >> +		BUG_ON(__ret);													\
> >> +		if ((__HCarg_p)->status == GNTST_eagain)						\
> >> +			msleep(__hc_delay++);										\
> >> +	} while ((__HCarg_p)->status == GNTST_eagain && __hc_delay);		\
> >> +	if (__hc_delay == 0) {												\
> >> +		printk(KERN_ERR "%s: %s gnt busy\n", __func__, current->comm);	\
> >> +		(__HCarg_p)->status = GNTST_bad_page;							\
> >> +	}																	\
> >> +	if ((__HCarg_p)->status != GNTST_okay)								\
> >> +		printk(KERN_ERR "%s: %s gnt status %x\n", 						\
> >> +			__func__, current->comm, (__HCarg_p)->status);				\
> >> +} while(0)
> >> +
> >>  #endif /* __ASM_GNTTAB_H__ */
> >>
> >> _______________________________________________
> >> Xen-devel mailing list
> >> Xen-devel@lists.xensource.com
> >> http://lists.xensource.com/xen-devel
> >
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

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

From xen-devel-bounces@lists.xensource.com Fri Dec 02 16:51:17 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 16: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.xensource.com>)
	id 1RWWKI-0008FM-6U; Fri, 02 Dec 2011 16:51:06 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1RWWKH-0008F9-6h
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 16:51:05 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-11.tower-21.messagelabs.com!1322844616!6561654!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23590 invoked from network); 2 Dec 2011 16:50:17 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-11.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 2 Dec 2011 16:50:17 -0000
Received: from andromeda.dapyr.net (darnok@localhost [127.0.0.1])
	by andromeda.dapyr.net (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id
	pB2Go40j008087
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Fri, 2 Dec 2011 11:50:04 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pB2Go3CW008085;
	Fri, 2 Dec 2011 11:50:03 -0500
Date: Fri, 2 Dec 2011 12:50:03 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20111202165003.GA7807@andromeda.dapyr.net>
References: <patchbomb.1322772713@xdev.gridcentric.ca>
	<1170bc32db41a7ae1e95.1322772715@xdev.gridcentric.ca>
	<20111202013430.GB636@andromeda.dapyr.net>
	<8940966a49442039be1480307f59656b.squirrel@webmail.lagarcavilla.org>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <8940966a49442039be1480307f59656b.squirrel@webmail.lagarcavilla.org>
User-Agent: Mutt/1.5.9i
Cc: olaf@aepfle.de, xen-devel@lists.xensource.com, andres@gridcentric.ca,
	jonathan.ludlam@eu.citrix.com, jbeulich@suse.com, mike.mcclurg@citrix.com
Subject: Re: [Xen-devel] [PATCH 2 of 2] xenpaging: handle GNTST_eagain in
	kernel drivers
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Dec 02, 2011 at 07:27:20AM -0800, Andres Lagar-Cavilla wrote:
> > On Thu, Dec 01, 2011 at 03:51:55PM -0500, Andres Lagar-Cavilla wrote:
> >>  drivers/xen/blkback/blkback.c              |   6 ++-
> >>  drivers/xen/blkback/interface.c            |   9 +++-
> >>  drivers/xen/core/gnttab.c                  |   4 +-
> >>  drivers/xen/gntdev/gntdev.c                |  49
> >> +++++++++++++++++------------
> >>  drivers/xen/netback/interface.c            |   5 +-
> >>  drivers/xen/netback/netback.c              |  16 ++++++---
> >>  drivers/xen/scsiback/interface.c           |  10 +++---
> >>  drivers/xen/scsiback/scsiback.c            |   4 +-
> >>  drivers/xen/tpmback/interface.c            |   7 +--
> >>  drivers/xen/tpmback/tpmback.c              |  20 ++++-------
> >>  drivers/xen/usbback/interface.c            |  16 ++++----
> >>  drivers/xen/usbback/usbback.c              |   4 +-
> >>  drivers/xen/xenbus/xenbus_backend_client.c |  10 +++---
> >>  include/xen/gnttab.h                       |  37 ++++++++++++++++++++++
> >>  14 files changed, 126 insertions(+), 71 deletions(-)
> >>
> >>
> >> Handle GNTST_eagain status from GNTTABOP_map_grant_ref and
> >> GNTTABOP_copy operations properly to allow usage of xenpaging without
> >> causing crashes or data corruption.
> >>
> >> Replace all relevant HYPERVISOR_grant_table_op() calls with a retry
> >> loop. This loop is implemented as a macro to allow different
> >> GNTTABOP_* args. It will sleep up to 33 seconds and wait for the
> >> page to be paged in again.
> >>
> >> All ->status checks were updated to use the GNTST_* namespace. All
> >> return values are converted from GNTST_* namespace to 0/-EINVAL, since
> >> all callers did not use the actual return value.
> >
> > Any plans to do this for the pvops tree?
> Slowly but surely. Working with XCP presently, so pvops is not at the top
> of my stack. Do you want to get at a specific merge window?

Its more of a review concern. Meaning that if you send for the upstream
kernel lots of folks are going to be looking at it. So the patches
will change - which means that the version upstream can be very
different from the one that you have for XCP - so in the end you will
have to deal with two different code-bases to maintain.

That can get a bit difficult to manage.

Granted not all of those drivers are in the upstream kernel so might not
make any difference.

> 
> Andres
> >
> >>
> >> Signed-off-by: Olaf Hering <olaf@aepfle.de>
> >> Acked-by: Patrick Colp <pjcolp@cs.ubc.ca>
> >>
> >> This is a port from xenlinux 2.6.18 to the 2.6.32 xcp tree
> >> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
> >>
> >> diff -r df9e25a0189b -r 1170bc32db41 drivers/xen/blkback/blkback.c
> >> --- a/drivers/xen/blkback/blkback.c
> >> +++ b/drivers/xen/blkback/blkback.c
> >> @@ -701,11 +701,13 @@ static void dispatch_rw_block_io(blkif_t
> >>  	BUG_ON(ret);
> >>
> >>  	for (i = 0; i < nseg; i++) {
> >> -		if (unlikely(map[i].status != 0)) {
> >> +		if (unlikely(map[i].status == GNTST_eagain))
> >> +			gnttab_check_GNTST_eagain_do_while(GNTTABOP_map_grant_ref, &map[i]);
> >> +		if (unlikely(map[i].status != GNTST_okay)) {
> >>  			DPRINTK("grant map of dom %u gref %u failed: status %d\n",
> >>  				blkif->domid, req->seg[i].gref, map[i].status);
> >>  			map[i].handle = BLKBACK_INVALID_HANDLE;
> >> -			ret |= 1;
> >> +			ret = 1;
> >>  			continue;
> >>  		}
> >>
> >> diff -r df9e25a0189b -r 1170bc32db41 drivers/xen/blkback/interface.c
> >> --- a/drivers/xen/blkback/interface.c
> >> +++ b/drivers/xen/blkback/interface.c
> >> @@ -95,7 +95,7 @@ static int map_frontend_pages(blkif_t *b
> >>  	struct vm_struct *area = blkif->blk_ring_area;
> >>  	struct gnttab_map_grant_ref op[BLKIF_MAX_RING_PAGES];
> >>  	unsigned int i;
> >> -	int status = 0;
> >> +	int status = GNTST_okay;
> >>
> >>  	for (i = 0; i < nr_shared_pages; i++) {
> >>  		unsigned long addr = (unsigned long)area->addr +
> >> @@ -110,7 +110,10 @@ static int map_frontend_pages(blkif_t *b
> >>  		BUG();
> >>
> >>  	for (i = 0; i < nr_shared_pages; i++) {
> >> -		if ((status = op[i].status) != 0) {
> >> +		if (op[i].status == GNTST_eagain)
> >> +			gnttab_check_GNTST_eagain_do_while(GNTTABOP_map_grant_ref, &op[i]);
> >> +		if (op[i].status != GNTST_okay) {
> >> +			status = op[i].status;
> >>  			blkif->shmem_handle[i] = INVALID_GRANT_HANDLE;
> >>  			continue;
> >>  		}
> >> @@ -120,7 +123,7 @@ static int map_frontend_pages(blkif_t *b
> >>
> >>  	blkif->nr_shared_pages = nr_shared_pages;
> >>
> >> -	if (status != 0) {
> >> +	if (status != GNTST_okay) {
> >>  		DPRINTK(" Grant table operation failure !\n");
> >>  		unmap_frontend_pages(blkif);
> >>  	}
> >> diff -r df9e25a0189b -r 1170bc32db41 drivers/xen/core/gnttab.c
> >> --- a/drivers/xen/core/gnttab.c
> >> +++ b/drivers/xen/core/gnttab.c
> >> @@ -773,7 +773,7 @@ static int gnttab_map(unsigned int start
> >>  		return -ENOSYS;
> >>  	}
> >>
> >> -	BUG_ON(rc || setup.status);
> >> +	BUG_ON(rc || (setup.status != GNTST_okay));
> >>
> >>  	if (shared.raw == NULL)
> >>  		shared.raw = arch_gnttab_alloc_shared(gframes);
> >> @@ -901,7 +901,7 @@ int gnttab_copy_grant_page(grant_ref_t r
> >>  	err = HYPERVISOR_grant_table_op(GNTTABOP_unmap_and_replace,
> >>  					&unmap, 1);
> >>  	BUG_ON(err);
> >> -	BUG_ON(unmap.status);
> >> +	BUG_ON(unmap.status != GNTST_okay);
> >>
> >>  	write_sequnlock_irq(&gnttab_dma_lock);
> >>
> >> diff -r df9e25a0189b -r 1170bc32db41 drivers/xen/gntdev/gntdev.c
> >> --- a/drivers/xen/gntdev/gntdev.c
> >> +++ b/drivers/xen/gntdev/gntdev.c
> >> @@ -503,7 +503,7 @@ static int gntdev_mmap (struct file *fli
> >>  	uint64_t ptep;
> >>  	int ret;
> >>  	int flags;
> >> -	int i;
> >> +	int i, exit_ret;
> >>  	struct page *page;
> >>  	gntdev_file_private_data_t *private_data = flip->private_data;
> >>
> >> @@ -578,6 +578,7 @@ static int gntdev_mmap (struct file *fli
> >>  	vma->vm_mm->context.has_foreign_mappings = 1;
> >>  #endif
> >>
> >> +	exit_ret = -ENOMEM;
> >>  	for (i = 0; i < size; ++i) {
> >>
> >>  		flags = GNTMAP_host_map;
> >> @@ -598,14 +599,18 @@ static int gntdev_mmap (struct file *fli
> >>  		ret = HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref,
> >>  						&op, 1);
> >>  		BUG_ON(ret);
> >> -		if (op.status) {
> >> -			printk(KERN_ERR "Error mapping the grant reference "
> >> -			       "into the kernel (%d). domid = %d; ref = %d\n",
> >> -			       op.status,
> >> -			       private_data->grants[slot_index+i]
> >> -			       .u.valid.domid,
> >> -			       private_data->grants[slot_index+i]
> >> -			       .u.valid.ref);
> >> +		if (op.status != GNTST_okay) {
> >> +			if (op.status != GNTST_eagain)
> >> +				printk(KERN_ERR "Error mapping the grant reference "
> >> +					   "into the kernel (%d). domid = %d; ref = %d\n",
> >> +					   op.status,
> >> +					   private_data->grants[slot_index+i]
> >> +					   .u.valid.domid,
> >> +					   private_data->grants[slot_index+i]
> >> +					   .u.valid.ref);
> >> +			else
> >> +				/* Propagate instead of trying to fix it up */
> >> +				exit_ret = -EAGAIN;
> >>  			goto undo_map_out;
> >>  		}
> >>
> >> @@ -674,14 +679,17 @@ static int gntdev_mmap (struct file *fli
> >>  			ret = HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref,
> >>  							&op, 1);
> >>  			BUG_ON(ret);
> >> -			if (op.status) {
> >> +			if (op.status != GNTST_okay) {
> >>  				printk(KERN_ERR "Error mapping the grant "
> >> -				       "reference into user space (%d). domid "
> >> -				       "= %d; ref = %d\n", op.status,
> >> -				       private_data->grants[slot_index+i].u
> >> -				       .valid.domid,
> >> -				       private_data->grants[slot_index+i].u
> >> -				       .valid.ref);
> >> +					   "reference into user space (%d). domid "
> >> +					   "= %d; ref = %d\n", op.status,
> >> +					   private_data->grants[slot_index+i].u
> >> +					   .valid.domid,
> >> +					   private_data->grants[slot_index+i].u
> >> +					   .valid.ref);
> >> +				/* GNTST_eagain (i.e. page paged out) sohuld never happen
> >> +				 * once we've mapped into kernel space */
> >> +				BUG_ON(op.status == GNTST_eagain);
> >>  				goto undo_map_out;
> >>  			}
> >>
> >> @@ -705,9 +713,10 @@ static int gntdev_mmap (struct file *fli
> >>  		}
> >>
> >>  	}
> >> +	exit_ret = 0;
> >>
> >>  	up_write(&private_data->grants_sem);
> >> -	return 0;
> >> +	return exit_ret;
> >>
> >>  undo_map_out:
> >>  	/* If we have a mapping failure, the unmapping will be taken care of
> >> @@ -725,7 +734,7 @@ undo_map_out:
> >>
> >>  	up_write(&private_data->grants_sem);
> >>
> >> -	return -ENOMEM;
> >> +	return exit_ret;
> >>  }
> >>
> >>  static pte_t gntdev_clear_pte(struct vm_area_struct *vma, unsigned long
> >> addr,
> >> @@ -777,7 +786,7 @@ static pte_t gntdev_clear_pte(struct vm_
> >>  			ret = HYPERVISOR_grant_table_op(
> >>  				GNTTABOP_unmap_grant_ref, &op, 1);
> >>  			BUG_ON(ret);
> >> -			if (op.status)
> >> +			if (op.status != GNTST_okay)
> >>  				printk("User unmap grant status = %d\n",
> >>  				       op.status);
> >>  		} else {
> >> @@ -794,7 +803,7 @@ static pte_t gntdev_clear_pte(struct vm_
> >>  		ret = HYPERVISOR_grant_table_op(GNTTABOP_unmap_grant_ref,
> >>  						&op, 1);
> >>  		BUG_ON(ret);
> >> -		if (op.status)
> >> +		if (op.status != GNTST_okay)
> >>  			printk("Kernel unmap grant status = %d\n", op.status);
> >>
> >>
> >> diff -r df9e25a0189b -r 1170bc32db41 drivers/xen/netback/interface.c
> >> --- a/drivers/xen/netback/interface.c
> >> +++ b/drivers/xen/netback/interface.c
> >> @@ -381,10 +381,9 @@ static int map_frontend_pages(struct xen
> >>  	gnttab_set_map_op(&op, (unsigned long)comms->ring_area->addr,
> >>  			  GNTMAP_host_map, ring_ref, domid);
> >>
> >> -	if (HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, &op, 1))
> >> -		BUG();
> >> +	gnttab_check_GNTST_eagain_do_while(GNTTABOP_map_grant_ref, &op);
> >>
> >> -	if (op.status) {
> >> +	if (op.status != GNTST_okay) {
> >>  		DPRINTK(" Gnttab failure mapping ring_ref!\n");
> >>  		free_vm_area(comms->ring_area);
> >>  		return op.status;
> >> diff -r df9e25a0189b -r 1170bc32db41 drivers/xen/netback/netback.c
> >> --- a/drivers/xen/netback/netback.c
> >> +++ b/drivers/xen/netback/netback.c
> >> @@ -419,11 +419,13 @@ static int netbk_check_gop(int nr_copy_s
> >>
> >>  	for (i = 0; i < nr_copy_slots; i++) {
> >>  		copy_op = npo->copy + npo->copy_cons++;
> >> +		if (copy_op->status == GNTST_eagain)
> >> +			gnttab_check_GNTST_eagain_while(GNTTABOP_copy, copy_op);
> >>  		if (copy_op->status != GNTST_okay) {
> >> -				DPRINTK("Bad status %d from copy to DOM%d.\n",
> >> -					copy_op->status, domid);
> >> -				status = NETIF_RSP_ERROR;
> >> -			}
> >> +			DPRINTK("Bad status %d from copy to DOM%d.\n",
> >> +				copy_op->status, domid);
> >> +			status = NETIF_RSP_ERROR;
> >> +		}
> >>  	}
> >>
> >>  	return status;
> >> @@ -1020,7 +1022,11 @@ static int netbk_tx_check_mop(struct xen
> >>
> >>  	/* Check status of header. */
> >>  	err = mop->status;
> >> -	if (unlikely(err)) {
> >> +	if (err == GNTST_eagain) {
> >> +		gnttab_check_GNTST_eagain_do_while(GNTTABOP_map_grant_ref, mop);
> >> +		err = mop->status;
> >> +	}
> >> +	if (unlikely(err != GNTST_okay)) {
> >>  		pending_ring_idx_t index;
> >>  		index = pending_index(netbk->pending_prod++);
> >>  		txp = &pending_tx_info[pending_idx].req;
> >> diff -r df9e25a0189b -r 1170bc32db41 drivers/xen/scsiback/interface.c
> >> --- a/drivers/xen/scsiback/interface.c
> >> +++ b/drivers/xen/scsiback/interface.c
> >> @@ -69,18 +69,18 @@ static int map_frontend_page( struct vsc
> >>  				GNTMAP_host_map, ring_ref,
> >>  				info->domid);
> >>
> >> -	err = HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, &op, 1);
> >> -	BUG_ON(err);
> >> +	gnttab_check_GNTST_eagain_do_while(GNTTABOP_map_grant_ref, &op);
> >>
> >> -	if (op.status) {
> >> -		printk(KERN_ERR "scsiback: Grant table operation failure !\n");
> >> +	if (op.status != GNTST_okay) {
> >> +		printk(KERN_ERR "scsiback: Grant table operation failure %d!\n",
> >> +							(int) op.status);
> >>  		return op.status;
> >>  	}
> >>
> >>  	info->shmem_ref    = ring_ref;
> >>  	info->shmem_handle = op.handle;
> >>
> >> -	return (GNTST_okay);
> >> +	return 0;
> >>  }
> >>
> >>  static void unmap_frontend_page(struct vscsibk_info *info)
> >> diff -r df9e25a0189b -r 1170bc32db41 drivers/xen/scsiback/scsiback.c
> >> --- a/drivers/xen/scsiback/scsiback.c
> >> +++ b/drivers/xen/scsiback/scsiback.c
> >> @@ -287,7 +287,9 @@ static int scsiback_gnttab_data_map(vscs
> >>  		for_each_sg (pending_req->sgl, sg, nr_segments, i) {
> >>  			struct page *pg;
> >>
> >> -			if (unlikely(map[i].status != 0)) {
> >> +			if (unlikely(map[i].status == GNTST_eagain))
> >> +				gnttab_check_GNTST_eagain_while(GNTTABOP_map_grant_ref, &map[i]);
> >> +			if (unlikely(map[i].status != GNTST_okay)) {
> >>  				printk(KERN_ERR "scsiback: invalid buffer -- could not remap
> >> it\n");
> >>  				map[i].handle = SCSIBACK_INVALID_HANDLE;
> >>  				err |= 1;
> >> diff -r df9e25a0189b -r 1170bc32db41 drivers/xen/tpmback/interface.c
> >> --- a/drivers/xen/tpmback/interface.c
> >> +++ b/drivers/xen/tpmback/interface.c
> >> @@ -86,11 +86,10 @@ static int map_frontend_page(tpmif_t *tp
> >>  	gnttab_set_map_op(&op, (unsigned long)tpmif->tx_area->addr,
> >>  			  GNTMAP_host_map, shared_page, tpmif->domid);
> >>
> >> -	if (HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, &op, 1))
> >> -		BUG();
> >> +	gnttab_check_GNTST_eagain_do_while(GNTTABOP_map_grant_ref, &op);
> >>
> >> -	if (op.status) {
> >> -		DPRINTK(" Grant table operation failure !\n");
> >> +	if (op.status != GNTST_okay) {
> >> +		DPRINTK(" Grant table operation failure %d!\n", (int) op.status);
> >>  		return op.status;
> >>  	}
> >>
> >> diff -r df9e25a0189b -r 1170bc32db41 drivers/xen/tpmback/tpmback.c
> >> --- a/drivers/xen/tpmback/tpmback.c
> >> +++ b/drivers/xen/tpmback/tpmback.c
> >> @@ -256,15 +256,13 @@ int _packet_write(struct packet *pak,
> >>  		gnttab_set_map_op(&map_op, idx_to_kaddr(tpmif, i),
> >>  				  GNTMAP_host_map, tx->ref, tpmif->domid);
> >>
> >> -		if (unlikely(HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref,
> >> -						       &map_op, 1))) {
> >> -			BUG();
> >> -		}
> >> +		gnttab_check_GNTST_eagain_do_while(GNTTABOP_map_grant_ref, &map_op);
> >>
> >>  		handle = map_op.handle;
> >>
> >> -		if (map_op.status) {
> >> -			DPRINTK(" Grant table operation failure !\n");
> >> +		if (map_op.status != GNTST_okay) {
> >> +			DPRINTK(" Grant table operation failure %d!\n",
> >> +						(int) map_op.status);
> >>  			return 0;
> >>  		}
> >>
> >> @@ -394,13 +392,11 @@ static int packet_read_shmem(struct pack
> >>  		gnttab_set_map_op(&map_op, idx_to_kaddr(tpmif, i),
> >>  				  GNTMAP_host_map, tx->ref, tpmif->domid);
> >>
> >> -		if (unlikely(HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref,
> >> -						       &map_op, 1))) {
> >> -			BUG();
> >> -		}
> >> +		gnttab_check_GNTST_eagain_do_while(GNTTABOP_map_grant_ref, &map_op);
> >>
> >> -		if (map_op.status) {
> >> -			DPRINTK(" Grant table operation failure !\n");
> >> +		if (map_op.status != GNTST_okay) {
> >> +			DPRINTK(" Grant table operation failure %d!\n",
> >> +						(int) map_op.status);
> >>  			return -EFAULT;
> >>  		}
> >>
> >> diff -r df9e25a0189b -r 1170bc32db41 drivers/xen/usbback/interface.c
> >> --- a/drivers/xen/usbback/interface.c
> >> +++ b/drivers/xen/usbback/interface.c
> >> @@ -109,11 +109,11 @@ static int map_frontend_pages(usbif_t *u
> >>  	gnttab_set_map_op(&op, (unsigned long)usbif->urb_ring_area->addr,
> >>  			  GNTMAP_host_map, urb_ring_ref, usbif->domid);
> >>
> >> -	if (HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, &op, 1))
> >> -		BUG();
> >> +	gnttab_check_GNTST_eagain_do_while(GNTTABOP_map_grant_ref, &op);
> >>
> >> -	if (op.status) {
> >> -		printk(KERN_ERR "grant table failure mapping urb_ring_ref\n");
> >> +	if (op.status != GNTST_okay) {
> >> +		printk(KERN_ERR "grant table failure mapping urb_ring_ref %d\n",
> >> +							(int) op.status);
> >>  		return op.status;
> >>  	}
> >>
> >> @@ -123,17 +123,17 @@ static int map_frontend_pages(usbif_t *u
> >>  	gnttab_set_map_op(&op, (unsigned long)usbif->conn_ring_area->addr,
> >>  			  GNTMAP_host_map, conn_ring_ref, usbif->domid);
> >>
> >> -	if (HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, &op, 1))
> >> -		BUG();
> >> +	gnttab_check_GNTST_eagain_do_while(GNTTABOP_map_grant_ref, &op);
> >>
> >> -	if (op.status) {
> >> +	if (op.status != GNTST_okay) {
> >>  		struct gnttab_unmap_grant_ref unop;
> >>  		gnttab_set_unmap_op(&unop,
> >>  				(unsigned long) usbif->urb_ring_area->addr,
> >>  				GNTMAP_host_map, usbif->urb_shmem_handle);
> >>  		VOID(HYPERVISOR_grant_table_op(GNTTABOP_unmap_grant_ref, &unop,
> >>  				1));
> >> -		printk(KERN_ERR "grant table failure mapping conn_ring_ref\n");
> >> +		printk(KERN_ERR "grant table failure mapping conn_ring_ref %d\n",
> >> +							(int) op.status);
> >>  		return op.status;
> >>  	}
> >>
> >> diff -r df9e25a0189b -r 1170bc32db41 drivers/xen/usbback/usbback.c
> >> --- a/drivers/xen/usbback/usbback.c
> >> +++ b/drivers/xen/usbback/usbback.c
> >> @@ -428,7 +428,9 @@ static int usbbk_gnttab_map(usbif_t *usb
> >>  		BUG_ON(ret);
> >>
> >>  		for (i = 0; i < nr_segs; i++) {
> >> -			if (unlikely(map[i].status != 0)) {
> >> +			if (unlikely(map[i].status == GNTST_eagain))
> >> +				gnttab_check_GNTST_eagain_while(GNTTABOP_map_grant_ref, &map[i]);
> >> +			if (unlikely(map[i].status != GNTST_okay)) {
> >>  				printk(KERN_ERR "usbback: invalid buffer -- could not remap it\n");
> >>  				map[i].handle = USBBACK_INVALID_HANDLE;
> >>  				ret |= 1;
> >> diff -r df9e25a0189b -r 1170bc32db41
> >> drivers/xen/xenbus/xenbus_backend_client.c
> >> --- a/drivers/xen/xenbus/xenbus_backend_client.c
> >> +++ b/drivers/xen/xenbus/xenbus_backend_client.c
> >> @@ -48,8 +48,7 @@ struct vm_struct *xenbus_map_ring_valloc
> >>  	gnttab_set_map_op(&op, (unsigned long)area->addr, GNTMAP_host_map,
> >>  			  gnt_ref, dev->otherend_id);
> >>
> >> -	if (HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, &op, 1))
> >> -		BUG();
> >> +	gnttab_check_GNTST_eagain_do_while(GNTTABOP_map_grant_ref, &op);
> >>
> >>  	if (op.status != GNTST_okay) {
> >>  		free_vm_area(area);
> >> @@ -75,15 +74,16 @@ int xenbus_map_ring(struct xenbus_device
> >>
> >>  	gnttab_set_map_op(&op, (unsigned long)vaddr, GNTMAP_host_map,
> >>  			  gnt_ref, dev->otherend_id);
> >> -	if (HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, &op, 1))
> >> -		BUG();
> >> +	gnttab_check_GNTST_eagain_do_while(GNTTABOP_map_grant_ref, &op);
> >>
> >>  	if (op.status != GNTST_okay) {
> >>  		xenbus_dev_fatal(dev, op.status,
> >>  				 "mapping in shared page %d from domain %d",
> >>  				 gnt_ref, dev->otherend_id);
> >> -	} else
> >> +	} else {
> >>  		*handle = op.handle;
> >> +		return 0;
> >> +	}
> >>
> >>  	return op.status;
> >>  }
> >> diff -r df9e25a0189b -r 1170bc32db41 include/xen/gnttab.h
> >> --- a/include/xen/gnttab.h
> >> +++ b/include/xen/gnttab.h
> >> @@ -187,4 +187,41 @@ gnttab_set_replace_op(struct gnttab_unma
> >>  	unmap->handle = handle;
> >>  }
> >>
> >> +#define gnttab_check_GNTST_eagain_while(__HCop, __HCarg_p)					\
> >> +do {																		\
> >> +	u8 __hc_delay = 1;														\
> >> +	int __ret;																\
> >> +	while (unlikely((__HCarg_p)->status == GNTST_eagain && __hc_delay))
> >> {	\
> >> +		msleep(__hc_delay++);												\
> >> +		__ret = HYPERVISOR_grant_table_op(__HCop, (__HCarg_p), 1);			\
> >> +		BUG_ON(__ret);														\
> >> +	}																		\
> >> +	if (__hc_delay == 0) {													\
> >> +		printk(KERN_ERR "%s: %s gnt busy\n", __func__, current->comm);		\
> >> +		(__HCarg_p)->status = GNTST_bad_page;								\
> >> +	}																		\
> >> +	if ((__HCarg_p)->status != GNTST_okay)									\
> >> +		printk(KERN_ERR "%s: %s gnt status %x\n", 							\
> >> +			__func__, current->comm, (__HCarg_p)->status);					\
> >> +} while(0)
> >> +
> >> +#define gnttab_check_GNTST_eagain_do_while(__HCop, __HCarg_p)			\
> >> +do {																	\
> >> +	u8 __hc_delay = 1;													\
> >> +	int __ret;															\
> >> +	do {																\
> >> +		__ret = HYPERVISOR_grant_table_op(__HCop, (__HCarg_p), 1);		\
> >> +		BUG_ON(__ret);													\
> >> +		if ((__HCarg_p)->status == GNTST_eagain)						\
> >> +			msleep(__hc_delay++);										\
> >> +	} while ((__HCarg_p)->status == GNTST_eagain && __hc_delay);		\
> >> +	if (__hc_delay == 0) {												\
> >> +		printk(KERN_ERR "%s: %s gnt busy\n", __func__, current->comm);	\
> >> +		(__HCarg_p)->status = GNTST_bad_page;							\
> >> +	}																	\
> >> +	if ((__HCarg_p)->status != GNTST_okay)								\
> >> +		printk(KERN_ERR "%s: %s gnt status %x\n", 						\
> >> +			__func__, current->comm, (__HCarg_p)->status);				\
> >> +} while(0)
> >> +
> >>  #endif /* __ASM_GNTTAB_H__ */
> >>
> >> _______________________________________________
> >> Xen-devel mailing list
> >> Xen-devel@lists.xensource.com
> >> http://lists.xensource.com/xen-devel
> >
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

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

From xen-devel-bounces@lists.xensource.com Fri Dec 02 16:56:46 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 16:56:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWWPa-0008VY-42; Fri, 02 Dec 2011 16:56:34 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1RWWPY-0008VN-Sl
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 16:56:33 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1322844950!6689729!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDUxMDY=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21813 invoked from network); 2 Dec 2011 16:55:51 -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;
	2 Dec 2011 16:55:51 -0000
X-IronPort-AV: E=Sophos;i="4.71,284,1320642000"; d="scan'208";a="19603167"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Dec 2011 11:55:37 -0500
Received: from [10.80.2.18] (10.80.2.18) by FTLPMAILMX01.citrite.net
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Fri, 2 Dec 2011
	11:55:37 -0500
Message-ID: <4ED90308.8010508@citrix.com>
Date: Fri, 2 Dec 2011 16:55:36 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.23) Gecko/20110921 Lightning/1.0b2 Thunderbird/3.1.15
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <4ED906BA020000780006523E@nat28.tlf.novell.com>
	<4ED8FC8A.7040002@citrix.com>
	<4ED90D130200007800065290@nat28.tlf.novell.com>
In-Reply-To: <4ED90D130200007800065290@nat28.tlf.novell.com>
X-Enigmail-Version: 1.1.2
Cc: Keir Fraser <keir.xen@gmail.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] KEXEC: allocate crash note buffers at boot time v5
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 02/12/11 16:38, Jan Beulich wrote:
>> patch, Xen will give crash areas for all pcpus up to nr_cpu_ids, which
>> covers all the cases.  The worst that will happen is that some crash
>> notes do not get written if certain cpus are offline at the time of a crash.
> And did you check that nothing in the producer or consumer chain gets
> confused by this new behavior?
>
> Jan
>

/proc/vmcore reported by the kdump kernel is fine, even with extra notes
which have 0 contents (after I deliberately caused kexec_get_cpu to
report 1 more cpu than was present for testing exactly this)

The producer/consumer chain will not change.  There was a case
previously where a CPU which was present at boot and subsequently
offlined would leave crash notes with 0's in them.  Therefore, if a tool
couldn't deal with that case, it wont be able to deal with this case. 
If a tool could deal with that case, it can deal with the new case.

I would hazard a guess that most of the time, we will boot on all CPUs
and crash with all of those CPUs still up, so it is more likely that
there will be no 0'd notes.

(When I say a 0'd note, I mean a note with correct header, type and
name, but 0's in the desc)

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com


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

From xen-devel-bounces@lists.xensource.com Fri Dec 02 16:56:46 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 16:56:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWWPa-0008VY-42; Fri, 02 Dec 2011 16:56:34 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1RWWPY-0008VN-Sl
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 16:56:33 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1322844950!6689729!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDUxMDY=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21813 invoked from network); 2 Dec 2011 16:55:51 -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;
	2 Dec 2011 16:55:51 -0000
X-IronPort-AV: E=Sophos;i="4.71,284,1320642000"; d="scan'208";a="19603167"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Dec 2011 11:55:37 -0500
Received: from [10.80.2.18] (10.80.2.18) by FTLPMAILMX01.citrite.net
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Fri, 2 Dec 2011
	11:55:37 -0500
Message-ID: <4ED90308.8010508@citrix.com>
Date: Fri, 2 Dec 2011 16:55:36 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.23) Gecko/20110921 Lightning/1.0b2 Thunderbird/3.1.15
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <4ED906BA020000780006523E@nat28.tlf.novell.com>
	<4ED8FC8A.7040002@citrix.com>
	<4ED90D130200007800065290@nat28.tlf.novell.com>
In-Reply-To: <4ED90D130200007800065290@nat28.tlf.novell.com>
X-Enigmail-Version: 1.1.2
Cc: Keir Fraser <keir.xen@gmail.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] KEXEC: allocate crash note buffers at boot time v5
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 02/12/11 16:38, Jan Beulich wrote:
>> patch, Xen will give crash areas for all pcpus up to nr_cpu_ids, which
>> covers all the cases.  The worst that will happen is that some crash
>> notes do not get written if certain cpus are offline at the time of a crash.
> And did you check that nothing in the producer or consumer chain gets
> confused by this new behavior?
>
> Jan
>

/proc/vmcore reported by the kdump kernel is fine, even with extra notes
which have 0 contents (after I deliberately caused kexec_get_cpu to
report 1 more cpu than was present for testing exactly this)

The producer/consumer chain will not change.  There was a case
previously where a CPU which was present at boot and subsequently
offlined would leave crash notes with 0's in them.  Therefore, if a tool
couldn't deal with that case, it wont be able to deal with this case. 
If a tool could deal with that case, it can deal with the new case.

I would hazard a guess that most of the time, we will boot on all CPUs
and crash with all of those CPUs still up, so it is more likely that
there will be no 0'd notes.

(When I say a 0'd note, I mean a note with correct header, type and
name, but 0's in the desc)

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com


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

From xen-devel-bounces@lists.xensource.com Fri Dec 02 16:59:54 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 16:59:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWWSd-0000Bj-QE; Fri, 02 Dec 2011 16:59:43 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RWWSb-0000BZ-Ng
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 16:59:41 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1322845118!43367449!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQyOTg=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17398 invoked from network); 2 Dec 2011 16:58:38 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-12.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 2 Dec 2011 16:58:38 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 02 Dec 2011 16:38:28 +0000
Message-Id: <4ED90D130200007800065290@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 02 Dec 2011 16:38:27 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>
References: <4ED906BA020000780006523E@nat28.tlf.novell.com>
	<4ED8FC8A.7040002@citrix.com>
In-Reply-To: <4ED8FC8A.7040002@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Keir Fraser <keir.xen@gmail.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] KEXEC: allocate crash note buffers at boot time v5
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 02.12.11 at 17:27, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
> On 02/12/11 16:11, Jan Beulich wrote:
>>>>> On 02.12.11 at 16:59, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>>> On 02/12/11 15:43, Jan Beulich wrote:
>>>> I just had another look at the Dom0 side of things, and I fail to see why
>>>> you think boot time allocation is necessary: All Dom0 does with the
>>>> provided info is set up the resource tree. The data doesn't get stored
>>>> for any post-boot use. What am I overlooking?
>>> /sbin/kexec opens /proc/iomem and looks for "Crash note" and interprets
>>> the range values.  This is how it grabs the locations to pack into its
>>> magic binary package.
>> So how does the hotplug scenario then get handled on native? I can't
>> imagine they expect things to remain stable across CPU unplug and
>> re-activation.
> 
> I am not how (or even if) the hotplug condition is handled on native.  I
> guess it depends on what is put into the resource tree on boot.  With my

I don't think native kexec depends on stuff being made visible in
/proc/iomem - grep-ing for "Crash note" in 2.6.18 as well as a current
tree hits exclusively the Xen instance.

Native uses a per-CPU allocation (i.e. address and contents can't be
expected to survive offlining of a CPU).

> patch, Xen will give crash areas for all pcpus up to nr_cpu_ids, which
> covers all the cases.  The worst that will happen is that some crash
> notes do not get written if certain cpus are offline at the time of a crash.

And did you check that nothing in the producer or consumer chain gets
confused by this new behavior?

Jan


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

From xen-devel-bounces@lists.xensource.com Fri Dec 02 16:59:54 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 16:59:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWWSd-0000Bj-QE; Fri, 02 Dec 2011 16:59:43 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RWWSb-0000BZ-Ng
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 16:59:41 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1322845118!43367449!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQyOTg=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17398 invoked from network); 2 Dec 2011 16:58:38 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-12.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 2 Dec 2011 16:58:38 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 02 Dec 2011 16:38:28 +0000
Message-Id: <4ED90D130200007800065290@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 02 Dec 2011 16:38:27 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>
References: <4ED906BA020000780006523E@nat28.tlf.novell.com>
	<4ED8FC8A.7040002@citrix.com>
In-Reply-To: <4ED8FC8A.7040002@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Keir Fraser <keir.xen@gmail.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] KEXEC: allocate crash note buffers at boot time v5
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 02.12.11 at 17:27, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
> On 02/12/11 16:11, Jan Beulich wrote:
>>>>> On 02.12.11 at 16:59, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>>> On 02/12/11 15:43, Jan Beulich wrote:
>>>> I just had another look at the Dom0 side of things, and I fail to see why
>>>> you think boot time allocation is necessary: All Dom0 does with the
>>>> provided info is set up the resource tree. The data doesn't get stored
>>>> for any post-boot use. What am I overlooking?
>>> /sbin/kexec opens /proc/iomem and looks for "Crash note" and interprets
>>> the range values.  This is how it grabs the locations to pack into its
>>> magic binary package.
>> So how does the hotplug scenario then get handled on native? I can't
>> imagine they expect things to remain stable across CPU unplug and
>> re-activation.
> 
> I am not how (or even if) the hotplug condition is handled on native.  I
> guess it depends on what is put into the resource tree on boot.  With my

I don't think native kexec depends on stuff being made visible in
/proc/iomem - grep-ing for "Crash note" in 2.6.18 as well as a current
tree hits exclusively the Xen instance.

Native uses a per-CPU allocation (i.e. address and contents can't be
expected to survive offlining of a CPU).

> patch, Xen will give crash areas for all pcpus up to nr_cpu_ids, which
> covers all the cases.  The worst that will happen is that some crash
> notes do not get written if certain cpus are offline at the time of a crash.

And did you check that nothing in the producer or consumer chain gets
confused by this new behavior?

Jan


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

From xen-devel-bounces@lists.xensource.com Fri Dec 02 17:17:54 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 17:17:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWWjx-0000j3-Nv; Fri, 02 Dec 2011 17:17:37 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <alex@alex.org.uk>) id 1RWWjx-0000iy-4h
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 17:17:37 +0000
X-Env-Sender: alex@alex.org.uk
X-Msg-Ref: server-15.tower-27.messagelabs.com!1322846204!57483140!1
X-Originating-IP: [89.16.176.221]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7602 invoked from network); 2 Dec 2011 17:16:45 -0000
Received: from mail.avalus.com (HELO mail.avalus.com) (89.16.176.221)
	by server-15.tower-27.messagelabs.com with SMTP;
	2 Dec 2011 17:16:45 -0000
Received: from [192.168.100.15] (87-194-71-186.bethere.co.uk [87.194.71.186])
	by mail.avalus.com (Postfix) with ESMTPSA id BE411C56120;
	Fri,  2 Dec 2011 17:16:59 +0000 (GMT)
Date: Fri, 02 Dec 2011 17:16:59 +0000
From: Alex Bligh <alex@alex.org.uk>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <8D88C4D6C31A598129A942AD@Ximines.local>
In-Reply-To: <1322844048.29870.155.camel@zakaz.uk.xensource.com>
References: <4ED798B2.1040309@canonical.com>
	<20111201180944.GH12984@reaktio.net>	<4ED8A45A.3050403@canonical.com>
	<20111202104110.GL12984@reaktio.net>
	<BA1B675D85BDD87795D1666C@Ximines.local>
	<1322844048.29870.155.camel@zakaz.uk.xensource.com>
X-Mailer: Mulberry/4.0.8 (Mac OS X)
MIME-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com, Alex Bligh <alex@alex.org.uk>,
	Stefan Bader <stefan.bader@canonical.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Xen 4.x / Linux 3.x (dom0 and HVM domU) and	NIC
 handling
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Alex Bligh <alex@alex.org.uk>
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com



--On 2 December 2011 16:40:48 +0000 Ian Campbell <Ian.Campbell@citrix.com> 
wrote:

>> AFAIK changing xen_platform_pci=0|1 will switch rather more than just
>> the NIC. It will switch your disk too, instantly causing your previously
>> happily booting OS to fail to boot as the root device name changes.
>
> We recommend you use "root=LABEL=foo" rather than "root=/dev/blah" for
> this reason. Fortunately most distros use that scheme by default these
> days.

Yes; and /etc/fstab. UUID= works too.

FWIW my experience is that various built-for-cloud type distros don't use
that scheme, mainly because they use grub1 which IIRC does not support
this, and building images in a non-root environment that have grub1
in is rather easier than grub2. So, for instance, all the vm-builder
stuff in debian/ubuntu used grub1 and did not work this way.

However, my point was that xen_platform_pci does not only change
whether your net driver is emulated or PVHVM, but also whether your
disk, and indeed everything else is emulated or PVHVM.

-- 
Alex Bligh

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

From xen-devel-bounces@lists.xensource.com Fri Dec 02 17:17:54 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 17:17:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWWjx-0000j3-Nv; Fri, 02 Dec 2011 17:17:37 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <alex@alex.org.uk>) id 1RWWjx-0000iy-4h
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 17:17:37 +0000
X-Env-Sender: alex@alex.org.uk
X-Msg-Ref: server-15.tower-27.messagelabs.com!1322846204!57483140!1
X-Originating-IP: [89.16.176.221]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7602 invoked from network); 2 Dec 2011 17:16:45 -0000
Received: from mail.avalus.com (HELO mail.avalus.com) (89.16.176.221)
	by server-15.tower-27.messagelabs.com with SMTP;
	2 Dec 2011 17:16:45 -0000
Received: from [192.168.100.15] (87-194-71-186.bethere.co.uk [87.194.71.186])
	by mail.avalus.com (Postfix) with ESMTPSA id BE411C56120;
	Fri,  2 Dec 2011 17:16:59 +0000 (GMT)
Date: Fri, 02 Dec 2011 17:16:59 +0000
From: Alex Bligh <alex@alex.org.uk>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <8D88C4D6C31A598129A942AD@Ximines.local>
In-Reply-To: <1322844048.29870.155.camel@zakaz.uk.xensource.com>
References: <4ED798B2.1040309@canonical.com>
	<20111201180944.GH12984@reaktio.net>	<4ED8A45A.3050403@canonical.com>
	<20111202104110.GL12984@reaktio.net>
	<BA1B675D85BDD87795D1666C@Ximines.local>
	<1322844048.29870.155.camel@zakaz.uk.xensource.com>
X-Mailer: Mulberry/4.0.8 (Mac OS X)
MIME-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com, Alex Bligh <alex@alex.org.uk>,
	Stefan Bader <stefan.bader@canonical.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Xen 4.x / Linux 3.x (dom0 and HVM domU) and	NIC
 handling
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Alex Bligh <alex@alex.org.uk>
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com



--On 2 December 2011 16:40:48 +0000 Ian Campbell <Ian.Campbell@citrix.com> 
wrote:

>> AFAIK changing xen_platform_pci=0|1 will switch rather more than just
>> the NIC. It will switch your disk too, instantly causing your previously
>> happily booting OS to fail to boot as the root device name changes.
>
> We recommend you use "root=LABEL=foo" rather than "root=/dev/blah" for
> this reason. Fortunately most distros use that scheme by default these
> days.

Yes; and /etc/fstab. UUID= works too.

FWIW my experience is that various built-for-cloud type distros don't use
that scheme, mainly because they use grub1 which IIRC does not support
this, and building images in a non-root environment that have grub1
in is rather easier than grub2. So, for instance, all the vm-builder
stuff in debian/ubuntu used grub1 and did not work this way.

However, my point was that xen_platform_pci does not only change
whether your net driver is emulated or PVHVM, but also whether your
disk, and indeed everything else is emulated or PVHVM.

-- 
Alex Bligh

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

From xen-devel-bounces@lists.xensource.com Fri Dec 02 17:24:35 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 17:24:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWWqR-0000tX-Jh; Fri, 02 Dec 2011 17:24:19 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RWWqP-0000tQ-TS
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 17:24:18 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-4.tower-216.messagelabs.com!1322846615!5949504!1
X-Originating-IP: [208.97.132.145]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNDUgPT4gMTczMjQ=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1607 invoked from network); 2 Dec 2011 17:23:35 -0000
Received: from caiajhbdcbef.dreamhost.com (HELO homiemail-a15.g.dreamhost.com)
	(208.97.132.145) by server-4.tower-216.messagelabs.com with SMTP;
	2 Dec 2011 17:23:35 -0000
Received: from homiemail-a15.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a15.g.dreamhost.com (Postfix) with ESMTP id AC28576C069;
	Fri,  2 Dec 2011 09:23:34 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=VMgpN9Yac26Jwoe8IjnrV94x3VobsySwUzP3XUbjRTPt
	xyIPDQyXRNJPFpvzlbMjlVoht1I+EOhy3RgrqpNGo57klXZZ6eAyecsh/2ZBxI5T
	w89ilrVaKP0YyqaRNBBI3VK2sLYZKvdgqwUuwruK5qFOSrnNzVjMDn1RK05oc6c=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=CFBUcIPiA5DSs4uRc9cm7qLbMZ4=; b=iGsN4XAa
	yqDDlpjyOJJdOoYq62FuEOrqqJBfdWYFTk0Q98P4lFpSEVyR72KdT0VfDEKxoFYt
	wzXND0GOx7qq5NpcxTKh7zLoa9zuJiKCbN/U66kl7NS5hoKIx9OQyJcX8O1WvQLO
	RXPRjvOk8bMIl0r43nNYwdntnRrXikhcE8s=
Received: from webmail.lagarcavilla.org (ahfbbjcaiaae.dreamhost.com
	[75.119.208.4]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a15.g.dreamhost.com (Postfix) with ESMTPA id 5B9E276C065; 
	Fri,  2 Dec 2011 09:23:34 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP; Fri, 2 Dec 2011 09:23:34 -0800
Message-ID: <188ac55da1f6e5f257ae01204118281c.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20111202164357.GA29226@aepfle.de>
References: <mailman.3014.1322742146.12970.xen-devel@lists.xensource.com>
	<782967b2dc26ac23e527e33839e8336f.squirrel@webmail.lagarcavilla.org>
	<20111201184616.GA17010@aepfle.de>
	<fa38d847359784f92a266c98b7855924.squirrel@webmail.lagarcavilla.org>
	<20111202164357.GA29226@aepfle.de>
Date: Fri, 2 Dec 2011 09:23:34 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Olaf Hering" <olaf@aepfle.de>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>
Subject: Re: [Xen-devel] [PATCH 2 of 4] xenpaging: use wait queues
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> On Fri, Dec 02, Andres Lagar-Cavilla wrote:
>
>> > The pager is in the process of writing the gfn to disk after
>> successful
>> > nomination. Its next step is the eviction, which will now fail because
>> > the p2mt is not p2m_ram_paging_out anymore. It is already prepared for
>> > that failure.
>> > The previous MEM_EVENT_FLAG_EVICT_FAIL was not needed in the first
>> > place.
>> Yes it was! The biggest source of overhead is I/O. Tell the pager to
>> stop
>> I/O early. Otherwise, you've done the paging out I/O pointlessly, to
>> find
>> out only when you try to finalize the eviction.
>
> I'm not sure how to inform the pager, its most likely in the middle of
> write(). Since such an event is rare (in my testing at least) I wonder
> wether its worth to make it complicated?

The way it is right now with the current ABI does better handling
vis-a-vis this problem (than short-cutting states and not sending an
EVICT_FAIL message).

A pager could nominate gfn's in batches, write them out in batches, evict
them in batches. It's a bit of a longshot, but exemplifies the kinds of
problems we need to think about when tinkering with the paging ABI.

On that topic. Is there a reason why a page cannot be proactively paged in
without attempting to map it first? I.e. move from p2m_ram_paging_out
straight into p2m_ram_paging_in with paging_prep/_load? It would eliminate
xenpaging's use of a page-in thread...

Andres

Andres
>
> Olaf
>



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

From xen-devel-bounces@lists.xensource.com Fri Dec 02 17:24:35 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 17:24:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWWqR-0000tX-Jh; Fri, 02 Dec 2011 17:24:19 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RWWqP-0000tQ-TS
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 17:24:18 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-4.tower-216.messagelabs.com!1322846615!5949504!1
X-Originating-IP: [208.97.132.145]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNDUgPT4gMTczMjQ=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1607 invoked from network); 2 Dec 2011 17:23:35 -0000
Received: from caiajhbdcbef.dreamhost.com (HELO homiemail-a15.g.dreamhost.com)
	(208.97.132.145) by server-4.tower-216.messagelabs.com with SMTP;
	2 Dec 2011 17:23:35 -0000
Received: from homiemail-a15.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a15.g.dreamhost.com (Postfix) with ESMTP id AC28576C069;
	Fri,  2 Dec 2011 09:23:34 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=VMgpN9Yac26Jwoe8IjnrV94x3VobsySwUzP3XUbjRTPt
	xyIPDQyXRNJPFpvzlbMjlVoht1I+EOhy3RgrqpNGo57klXZZ6eAyecsh/2ZBxI5T
	w89ilrVaKP0YyqaRNBBI3VK2sLYZKvdgqwUuwruK5qFOSrnNzVjMDn1RK05oc6c=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=CFBUcIPiA5DSs4uRc9cm7qLbMZ4=; b=iGsN4XAa
	yqDDlpjyOJJdOoYq62FuEOrqqJBfdWYFTk0Q98P4lFpSEVyR72KdT0VfDEKxoFYt
	wzXND0GOx7qq5NpcxTKh7zLoa9zuJiKCbN/U66kl7NS5hoKIx9OQyJcX8O1WvQLO
	RXPRjvOk8bMIl0r43nNYwdntnRrXikhcE8s=
Received: from webmail.lagarcavilla.org (ahfbbjcaiaae.dreamhost.com
	[75.119.208.4]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a15.g.dreamhost.com (Postfix) with ESMTPA id 5B9E276C065; 
	Fri,  2 Dec 2011 09:23:34 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP; Fri, 2 Dec 2011 09:23:34 -0800
Message-ID: <188ac55da1f6e5f257ae01204118281c.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20111202164357.GA29226@aepfle.de>
References: <mailman.3014.1322742146.12970.xen-devel@lists.xensource.com>
	<782967b2dc26ac23e527e33839e8336f.squirrel@webmail.lagarcavilla.org>
	<20111201184616.GA17010@aepfle.de>
	<fa38d847359784f92a266c98b7855924.squirrel@webmail.lagarcavilla.org>
	<20111202164357.GA29226@aepfle.de>
Date: Fri, 2 Dec 2011 09:23:34 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Olaf Hering" <olaf@aepfle.de>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>
Subject: Re: [Xen-devel] [PATCH 2 of 4] xenpaging: use wait queues
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> On Fri, Dec 02, Andres Lagar-Cavilla wrote:
>
>> > The pager is in the process of writing the gfn to disk after
>> successful
>> > nomination. Its next step is the eviction, which will now fail because
>> > the p2mt is not p2m_ram_paging_out anymore. It is already prepared for
>> > that failure.
>> > The previous MEM_EVENT_FLAG_EVICT_FAIL was not needed in the first
>> > place.
>> Yes it was! The biggest source of overhead is I/O. Tell the pager to
>> stop
>> I/O early. Otherwise, you've done the paging out I/O pointlessly, to
>> find
>> out only when you try to finalize the eviction.
>
> I'm not sure how to inform the pager, its most likely in the middle of
> write(). Since such an event is rare (in my testing at least) I wonder
> wether its worth to make it complicated?

The way it is right now with the current ABI does better handling
vis-a-vis this problem (than short-cutting states and not sending an
EVICT_FAIL message).

A pager could nominate gfn's in batches, write them out in batches, evict
them in batches. It's a bit of a longshot, but exemplifies the kinds of
problems we need to think about when tinkering with the paging ABI.

On that topic. Is there a reason why a page cannot be proactively paged in
without attempting to map it first? I.e. move from p2m_ram_paging_out
straight into p2m_ram_paging_in with paging_prep/_load? It would eliminate
xenpaging's use of a page-in thread...

Andres

Andres
>
> Olaf
>



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

From xen-devel-bounces@lists.xensource.com Fri Dec 02 17:35:23 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 17:35:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWX0j-00019r-PD; Fri, 02 Dec 2011 17:34:57 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RWX0h-00019m-FM
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 17:34:55 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-3.tower-182.messagelabs.com!1322847253!5682584!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMjMxNzc=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMjMxNzc=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8986 invoked from network); 2 Dec 2011 17:34:14 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-3.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 2 Dec 2011 17:34:14 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1322847253; l=941;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=ynLkGXAyfu/7Lp9K1gUi6GvNRSg=;
	b=jVRKLZfjjzzZ5i82MjfpDTiULg40fgl/JWIGbDviaHba4qVhQrGb1OSPgVMM0Lmk9V7
	ndKkrR28eU5n2P7migGzuiKME3bNPeymFUWScvvdVI7IYail1TBlR2eq1ej4dmqg69Gf/
	mJ3J9tFU+gYQDWwC3fi/GLES+h4gCNGsCDg=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFJji0PG5M=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-070-018.pools.arcor-ip.net [88.65.70.18])
	by smtp.strato.de (cohen mo30) (RZmta 26.10 AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id n04b34nB2GbFo6 ;
	Fri, 2 Dec 2011 18:34:12 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 23E3D18637; Fri,  2 Dec 2011 18:34:12 +0100 (CET)
Date: Fri, 2 Dec 2011 18:34:12 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20111202173411.GA30126@aepfle.de>
References: <mailman.3014.1322742146.12970.xen-devel@lists.xensource.com>
	<782967b2dc26ac23e527e33839e8336f.squirrel@webmail.lagarcavilla.org>
	<20111201184616.GA17010@aepfle.de>
	<fa38d847359784f92a266c98b7855924.squirrel@webmail.lagarcavilla.org>
	<20111202164357.GA29226@aepfle.de>
	<188ac55da1f6e5f257ae01204118281c.squirrel@webmail.lagarcavilla.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <188ac55da1f6e5f257ae01204118281c.squirrel@webmail.lagarcavilla.org>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 2 of 4] xenpaging: use wait queues
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Dec 02, Andres Lagar-Cavilla wrote:

> A pager could nominate gfn's in batches, write them out in batches, evict
> them in batches. It's a bit of a longshot, but exemplifies the kinds of
> problems we need to think about when tinkering with the paging ABI.

I want to do something like that, using a separate ring instead of
individual domctls. However, its more an optimization than a bugfix so
its not a top priority for me. I see you already submitted changes to
simplify event channel handling.

> On that topic. Is there a reason why a page cannot be proactively paged in
> without attempting to map it first? I.e. move from p2m_ram_paging_out
> straight into p2m_ram_paging_in with paging_prep/_load? It would eliminate
> xenpaging's use of a page-in thread...

Maybe there are different ways to do that. The way ring buffers are
implemented now its not possible to send one-way events with the ring.

Olaf

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

From xen-devel-bounces@lists.xensource.com Fri Dec 02 17:35:23 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 17:35:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWX0j-00019r-PD; Fri, 02 Dec 2011 17:34:57 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RWX0h-00019m-FM
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 17:34:55 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-3.tower-182.messagelabs.com!1322847253!5682584!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMjMxNzc=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMjMxNzc=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8986 invoked from network); 2 Dec 2011 17:34:14 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-3.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 2 Dec 2011 17:34:14 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1322847253; l=941;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=ynLkGXAyfu/7Lp9K1gUi6GvNRSg=;
	b=jVRKLZfjjzzZ5i82MjfpDTiULg40fgl/JWIGbDviaHba4qVhQrGb1OSPgVMM0Lmk9V7
	ndKkrR28eU5n2P7migGzuiKME3bNPeymFUWScvvdVI7IYail1TBlR2eq1ej4dmqg69Gf/
	mJ3J9tFU+gYQDWwC3fi/GLES+h4gCNGsCDg=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFJji0PG5M=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-070-018.pools.arcor-ip.net [88.65.70.18])
	by smtp.strato.de (cohen mo30) (RZmta 26.10 AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id n04b34nB2GbFo6 ;
	Fri, 2 Dec 2011 18:34:12 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 23E3D18637; Fri,  2 Dec 2011 18:34:12 +0100 (CET)
Date: Fri, 2 Dec 2011 18:34:12 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20111202173411.GA30126@aepfle.de>
References: <mailman.3014.1322742146.12970.xen-devel@lists.xensource.com>
	<782967b2dc26ac23e527e33839e8336f.squirrel@webmail.lagarcavilla.org>
	<20111201184616.GA17010@aepfle.de>
	<fa38d847359784f92a266c98b7855924.squirrel@webmail.lagarcavilla.org>
	<20111202164357.GA29226@aepfle.de>
	<188ac55da1f6e5f257ae01204118281c.squirrel@webmail.lagarcavilla.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <188ac55da1f6e5f257ae01204118281c.squirrel@webmail.lagarcavilla.org>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 2 of 4] xenpaging: use wait queues
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Dec 02, Andres Lagar-Cavilla wrote:

> A pager could nominate gfn's in batches, write them out in batches, evict
> them in batches. It's a bit of a longshot, but exemplifies the kinds of
> problems we need to think about when tinkering with the paging ABI.

I want to do something like that, using a separate ring instead of
individual domctls. However, its more an optimization than a bugfix so
its not a top priority for me. I see you already submitted changes to
simplify event channel handling.

> On that topic. Is there a reason why a page cannot be proactively paged in
> without attempting to map it first? I.e. move from p2m_ram_paging_out
> straight into p2m_ram_paging_in with paging_prep/_load? It would eliminate
> xenpaging's use of a page-in thread...

Maybe there are different ways to do that. The way ring buffers are
implemented now its not possible to send one-way events with the ring.

Olaf

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

From xen-devel-bounces@lists.xensource.com Fri Dec 02 17:39:17 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 17:39:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWX4Y-0001Ha-Dv; Fri, 02 Dec 2011 17:38:54 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RWX4X-0001HR-Ky
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 17:38:53 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-7.tower-27.messagelabs.com!1322847450!59252162!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25403 invoked from network); 2 Dec 2011 17:37:30 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-7.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 2 Dec 2011 17:37:30 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RWX3u-000NwG-Eu; Fri, 02 Dec 2011 17:38:14 +0000
Date: Fri, 2 Dec 2011 17:38:14 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20111202173814.GB86219@ocelot.phlegethon.org>
References: <patchbomb.1320788543@xdev.gridcentric.ca>
	<6203a0549d8a1a21753b.1320788545@xdev.gridcentric.ca>
	<20111110125342.GG62117@ocelot.phlegethon.org>
	<4cb5acd8fa013dc40d5063d61296a319.squirrel@webmail.lagarcavilla.org>
	<20111124113507.GA77868@ocelot.phlegethon.org>
	<180057def2be9bc8eb519865f17aca96.squirrel@webmail.lagarcavilla.org>
	<20111201135916.GB61203@ocelot.phlegethon.org>
	<69fe17d8abdcb35630a0709166c85026.squirrel@webmail.lagarcavilla.org>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <69fe17d8abdcb35630a0709166c85026.squirrel@webmail.lagarcavilla.org>
User-Agent: Mutt/1.4.2.1i
Cc: olaf@aepfle.de, xen-devel@lists.xensource.com, george.dunlap@eu.citrix.com,
	andres@gridcentric.ca, keir.xen@gmail.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 2 of 3] Make p2m lookups fully synchronized
	wrt modifications
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 08:33 -0800 on 02 Dec (1322814798), Andres Lagar-Cavilla wrote:
> > At 08:41 -0800 on 24 Nov (1322124101), Andres Lagar-Cavilla wrote:
> >> Here is one solution to consider: do not lock the p2m on lookups in
> >> shadow
> >> mode. Shadow mode does not support paging out and sharing of pages,
> >> which
> >> are primary reasons why we want synchronized p2m lookups. The hap cases
> >> where there is an inversion of the p2m_lock -> paging_lock order are
> >> reasonably simple to handle.
> >>
> >> The other option is to invert the order and place paging_lock ->
> >> p2m_lock,
> >> but that will raise another set of potential inversions. I think this is
> >> a
> >> no go.
> >
> > Is there scope for having the p2m lock split out into the overall one
> > (needed for allocations &c) and the per-record ones, and have them at
> > different levels in the lock hierarchy?
> I think it's saner to go with one big lock and then shard it if we run
> into performance problems. Your proposal, actually :)
> 
> Now, I'm thinking of splitting ... the paging lock. It covers way too much
> ground right now, and many of these inversions would become more
> tractable. Thinking of paging_alloc_lock, paging_logdirty_lock,
> paging_lock.

...almost exactly six months after I merged the shadow, hap and
log-dirty locks into one lock, to avoid the deadlocks that were caused
by those sections of code calling in to each other. :)

http://xenbits.xen.org/hg/staging/xen-unstable.hg/log?rev=2bbed

Tim.

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

From xen-devel-bounces@lists.xensource.com Fri Dec 02 17:39:17 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 17:39:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWX4Y-0001Ha-Dv; Fri, 02 Dec 2011 17:38:54 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RWX4X-0001HR-Ky
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 17:38:53 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-7.tower-27.messagelabs.com!1322847450!59252162!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25403 invoked from network); 2 Dec 2011 17:37:30 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-7.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 2 Dec 2011 17:37:30 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RWX3u-000NwG-Eu; Fri, 02 Dec 2011 17:38:14 +0000
Date: Fri, 2 Dec 2011 17:38:14 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20111202173814.GB86219@ocelot.phlegethon.org>
References: <patchbomb.1320788543@xdev.gridcentric.ca>
	<6203a0549d8a1a21753b.1320788545@xdev.gridcentric.ca>
	<20111110125342.GG62117@ocelot.phlegethon.org>
	<4cb5acd8fa013dc40d5063d61296a319.squirrel@webmail.lagarcavilla.org>
	<20111124113507.GA77868@ocelot.phlegethon.org>
	<180057def2be9bc8eb519865f17aca96.squirrel@webmail.lagarcavilla.org>
	<20111201135916.GB61203@ocelot.phlegethon.org>
	<69fe17d8abdcb35630a0709166c85026.squirrel@webmail.lagarcavilla.org>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <69fe17d8abdcb35630a0709166c85026.squirrel@webmail.lagarcavilla.org>
User-Agent: Mutt/1.4.2.1i
Cc: olaf@aepfle.de, xen-devel@lists.xensource.com, george.dunlap@eu.citrix.com,
	andres@gridcentric.ca, keir.xen@gmail.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 2 of 3] Make p2m lookups fully synchronized
	wrt modifications
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 08:33 -0800 on 02 Dec (1322814798), Andres Lagar-Cavilla wrote:
> > At 08:41 -0800 on 24 Nov (1322124101), Andres Lagar-Cavilla wrote:
> >> Here is one solution to consider: do not lock the p2m on lookups in
> >> shadow
> >> mode. Shadow mode does not support paging out and sharing of pages,
> >> which
> >> are primary reasons why we want synchronized p2m lookups. The hap cases
> >> where there is an inversion of the p2m_lock -> paging_lock order are
> >> reasonably simple to handle.
> >>
> >> The other option is to invert the order and place paging_lock ->
> >> p2m_lock,
> >> but that will raise another set of potential inversions. I think this is
> >> a
> >> no go.
> >
> > Is there scope for having the p2m lock split out into the overall one
> > (needed for allocations &c) and the per-record ones, and have them at
> > different levels in the lock hierarchy?
> I think it's saner to go with one big lock and then shard it if we run
> into performance problems. Your proposal, actually :)
> 
> Now, I'm thinking of splitting ... the paging lock. It covers way too much
> ground right now, and many of these inversions would become more
> tractable. Thinking of paging_alloc_lock, paging_logdirty_lock,
> paging_lock.

...almost exactly six months after I merged the shadow, hap and
log-dirty locks into one lock, to avoid the deadlocks that were caused
by those sections of code calling in to each other. :)

http://xenbits.xen.org/hg/staging/xen-unstable.hg/log?rev=2bbed

Tim.

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

From xen-devel-bounces@lists.xensource.com Fri Dec 02 17:43:41 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 17:43:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWX8p-0001SR-4I; Fri, 02 Dec 2011 17:43:19 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RWX8o-0001SM-92
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 17:43:18 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1322847756!5946453!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTg0Mw==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22495 invoked from network); 2 Dec 2011 17:42:37 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Dec 2011 17:42:37 -0000
X-IronPort-AV: E=Sophos;i="4.71,284,1320624000"; 
   d="scan'208";a="9257261"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Dec 2011 17:42:36 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 2 Dec 2011
	17:42:36 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Alex Bligh <alex@alex.org.uk>
In-Reply-To: <8D88C4D6C31A598129A942AD@Ximines.local>
References: <4ED798B2.1040309@canonical.com>
	<20111201180944.GH12984@reaktio.net>	<4ED8A45A.3050403@canonical.com>
	<20111202104110.GL12984@reaktio.net>
	<BA1B675D85BDD87795D1666C@Ximines.local>
	<1322844048.29870.155.camel@zakaz.uk.xensource.com>
	<8D88C4D6C31A598129A942AD@Ximines.local>
Organization: Citrix Systems, Inc.
Date: Fri, 2 Dec 2011 17:42:35 +0000
Message-ID: <1322847755.7376.45.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
X-Mailer: Evolution 2.32.3 
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefan Bader <stefan.bader@canonical.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Xen 4.x / Linux 3.x (dom0 and HVM domU) and	NIC
 handling
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2011-12-02 at 17:16 +0000, Alex Bligh wrote:
> 
> --On 2 December 2011 16:40:48 +0000 Ian Campbell <Ian.Campbell@citrix.com> 
> wrote:
> 
> >> AFAIK changing xen_platform_pci=0|1 will switch rather more than just
> >> the NIC. It will switch your disk too, instantly causing your previously
> >> happily booting OS to fail to boot as the root device name changes.
> >
> > We recommend you use "root=LABEL=foo" rather than "root=/dev/blah" for
> > this reason. Fortunately most distros use that scheme by default these
> > days.
> 
> Yes; and /etc/fstab. UUID= works too.

Right.

> FWIW my experience is that various built-for-cloud type distros don't use
> that scheme, mainly because they use grub1 which IIRC does not support
> this, and building images in a non-root environment that have grub1
> in is rather easier than grub2.

UUID= and LABEL= are functions of your initrd (actually udev) and not
the bootloader. They work with both grub1 and grub2.

> So, for instance, all the vm-builder stuff in debian/ubuntu used grub1
> and did not work this way.

Which ones are these?

The Debian installer uses UUID where it can AFAIK. Ubuntu's installer is
derived from Debian's so I'd expect it to be the same.

> However, my point was that xen_platform_pci does not only change
> whether your net driver is emulated or PVHVM, but also whether your
> disk, and indeed everything else is emulated or PVHVM.

That is indeed worth highlighting.

Ian.




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

From xen-devel-bounces@lists.xensource.com Fri Dec 02 17:43:41 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 17:43:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWX8p-0001SR-4I; Fri, 02 Dec 2011 17:43:19 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RWX8o-0001SM-92
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 17:43:18 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1322847756!5946453!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTg0Mw==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22495 invoked from network); 2 Dec 2011 17:42:37 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Dec 2011 17:42:37 -0000
X-IronPort-AV: E=Sophos;i="4.71,284,1320624000"; 
   d="scan'208";a="9257261"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Dec 2011 17:42:36 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 2 Dec 2011
	17:42:36 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Alex Bligh <alex@alex.org.uk>
In-Reply-To: <8D88C4D6C31A598129A942AD@Ximines.local>
References: <4ED798B2.1040309@canonical.com>
	<20111201180944.GH12984@reaktio.net>	<4ED8A45A.3050403@canonical.com>
	<20111202104110.GL12984@reaktio.net>
	<BA1B675D85BDD87795D1666C@Ximines.local>
	<1322844048.29870.155.camel@zakaz.uk.xensource.com>
	<8D88C4D6C31A598129A942AD@Ximines.local>
Organization: Citrix Systems, Inc.
Date: Fri, 2 Dec 2011 17:42:35 +0000
Message-ID: <1322847755.7376.45.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
X-Mailer: Evolution 2.32.3 
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefan Bader <stefan.bader@canonical.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Xen 4.x / Linux 3.x (dom0 and HVM domU) and	NIC
 handling
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2011-12-02 at 17:16 +0000, Alex Bligh wrote:
> 
> --On 2 December 2011 16:40:48 +0000 Ian Campbell <Ian.Campbell@citrix.com> 
> wrote:
> 
> >> AFAIK changing xen_platform_pci=0|1 will switch rather more than just
> >> the NIC. It will switch your disk too, instantly causing your previously
> >> happily booting OS to fail to boot as the root device name changes.
> >
> > We recommend you use "root=LABEL=foo" rather than "root=/dev/blah" for
> > this reason. Fortunately most distros use that scheme by default these
> > days.
> 
> Yes; and /etc/fstab. UUID= works too.

Right.

> FWIW my experience is that various built-for-cloud type distros don't use
> that scheme, mainly because they use grub1 which IIRC does not support
> this, and building images in a non-root environment that have grub1
> in is rather easier than grub2.

UUID= and LABEL= are functions of your initrd (actually udev) and not
the bootloader. They work with both grub1 and grub2.

> So, for instance, all the vm-builder stuff in debian/ubuntu used grub1
> and did not work this way.

Which ones are these?

The Debian installer uses UUID where it can AFAIK. Ubuntu's installer is
derived from Debian's so I'd expect it to be the same.

> However, my point was that xen_platform_pci does not only change
> whether your net driver is emulated or PVHVM, but also whether your
> disk, and indeed everything else is emulated or PVHVM.

That is indeed worth highlighting.

Ian.




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

From xen-devel-bounces@lists.xensource.com Fri Dec 02 18:02:18 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 18:02:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWXQp-0001ls-QX; Fri, 02 Dec 2011 18:01:55 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andrew.pounce@citrix.com>) id 1RWXQo-0001ln-68
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 18:01:54 +0000
X-Env-Sender: andrew.pounce@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1322848830!59254103!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTg0Mw==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28836 invoked from network); 2 Dec 2011 18:00:31 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Dec 2011 18:00:31 -0000
X-IronPort-AV: E=Sophos;i="4.71,285,1320624000"; 
   d="scan'208";a="9257504"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Dec 2011 18:01:17 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 2 Dec 2011 18:01:17 +0000
Received: from dust.cam.xci-test.com ([10.80.248.95] helo=dust)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<andrew.pounce@citrix.com>)	id 1RWXQD-0003rF-KH;
	Fri, 02 Dec 2011 18:01:17 +0000
Received: from andrewpou by dust with local (Exim 4.76)	(envelope-from
	<andrew.pounce@citrix.com>)	id 1RWXQD-0003e4-G7;
	Fri, 02 Dec 2011 18:01:17 +0000
Date: Fri, 2 Dec 2011 18:01:17 +0000
From: Andrew Pounce <andrew.pounce@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20111202180117.GD6331@citrix.com>
References: <CANrAofX3ARD8CN8HtoBnetfMZvBUS5RSC89ExuGoVSzqmE2V9A@mail.gmail.com>
	<1322736422.31810.197.camel@zakaz.uk.xensource.com>
	<20183.46573.894123.974575@mariner.uk.xensource.com>
	<1322762470.7376.27.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1322762470.7376.27.camel@dagon.hellion.org.uk>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] Compile error with Ubuntu 11.10
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

IanC - I have tried the two patches that you provided and this appears to fix this problem in that I can now compile on my ubuntu 11.10 desktop.


libxl: Fix format string problem resulting in compile warning 
libxl: build with -Wformat-nonliteral 


 -Andrew


The combined patch is (against http://xenbits.xen.org/xen-unstable.hg ):-

diff -r 62ff6a318c5d tools/libxl/Makefile
--- a/tools/libxl/Makefile      Wed Nov 30 16:59:58 2011 -0800
+++ b/tools/libxl/Makefile      Fri Dec 02 17:49:57 2011 +0000
@@ -11,7 +11,7 @@
 XLUMAJOR = 1.0
 XLUMINOR = 0
 
-CFLAGS += -Werror -Wno-format-zero-length -Wmissing-declarations
+CFLAGS += -Werror -Wno-format-zero-length -Wmissing-declarations -Wformat-nonliteral
 CFLAGS += -I. -fPIC
 
 ifeq ($(CONFIG_Linux),y)
diff -r 62ff6a318c5d tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c        Wed Nov 30 16:59:58 2011 -0800
+++ b/tools/libxl/libxl_create.c        Fri Dec 02 17:49:57 2011 +0000
@@ -461,8 +461,8 @@
 
     path = libxl__xs_libxl_path(gc, domid);
     path = libxl__sprintf(gc, "%s/dm-version", path);
-    return libxl__xs_write(gc, XBT_NULL, path, libxl__strdup(gc,
-        libxl_device_model_version_to_string(dm_info->device_model_version)));
+    return libxl__xs_write(gc, XBT_NULL, path, "%s",
+        libxl_device_model_version_to_string(dm_info->device_model_version));
 }
 
 static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
diff -r 62ff6a318c5d tools/libxl/libxl_device.c
--- a/tools/libxl/libxl_device.c        Wed Nov 30 16:59:58 2011 -0800
+++ b/tools/libxl/libxl_device.c        Fri Dec 02 17:49:57 2011 +0000
@@ -516,7 +516,7 @@
         for (j = 0; j < num_devs; j++) {
             path = libxl__sprintf(gc, "/local/domain/%d/device/%s/%s/backend",
                                   domid, kinds[i], devs[j]);
-            path = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, path));
+            path = libxl__xs_read(gc, XBT_NULL, path);
             if (path && libxl__parse_backend_path(gc, path, &dev) == 0) {
                 dev.domid = domid;
                 dev.kind = kind;





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

From xen-devel-bounces@lists.xensource.com Fri Dec 02 18:02:18 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 18:02:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWXQp-0001ls-QX; Fri, 02 Dec 2011 18:01:55 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andrew.pounce@citrix.com>) id 1RWXQo-0001ln-68
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 18:01:54 +0000
X-Env-Sender: andrew.pounce@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1322848830!59254103!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTg0Mw==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28836 invoked from network); 2 Dec 2011 18:00:31 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Dec 2011 18:00:31 -0000
X-IronPort-AV: E=Sophos;i="4.71,285,1320624000"; 
   d="scan'208";a="9257504"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Dec 2011 18:01:17 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 2 Dec 2011 18:01:17 +0000
Received: from dust.cam.xci-test.com ([10.80.248.95] helo=dust)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<andrew.pounce@citrix.com>)	id 1RWXQD-0003rF-KH;
	Fri, 02 Dec 2011 18:01:17 +0000
Received: from andrewpou by dust with local (Exim 4.76)	(envelope-from
	<andrew.pounce@citrix.com>)	id 1RWXQD-0003e4-G7;
	Fri, 02 Dec 2011 18:01:17 +0000
Date: Fri, 2 Dec 2011 18:01:17 +0000
From: Andrew Pounce <andrew.pounce@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20111202180117.GD6331@citrix.com>
References: <CANrAofX3ARD8CN8HtoBnetfMZvBUS5RSC89ExuGoVSzqmE2V9A@mail.gmail.com>
	<1322736422.31810.197.camel@zakaz.uk.xensource.com>
	<20183.46573.894123.974575@mariner.uk.xensource.com>
	<1322762470.7376.27.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1322762470.7376.27.camel@dagon.hellion.org.uk>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] Compile error with Ubuntu 11.10
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

IanC - I have tried the two patches that you provided and this appears to fix this problem in that I can now compile on my ubuntu 11.10 desktop.


libxl: Fix format string problem resulting in compile warning 
libxl: build with -Wformat-nonliteral 


 -Andrew


The combined patch is (against http://xenbits.xen.org/xen-unstable.hg ):-

diff -r 62ff6a318c5d tools/libxl/Makefile
--- a/tools/libxl/Makefile      Wed Nov 30 16:59:58 2011 -0800
+++ b/tools/libxl/Makefile      Fri Dec 02 17:49:57 2011 +0000
@@ -11,7 +11,7 @@
 XLUMAJOR = 1.0
 XLUMINOR = 0
 
-CFLAGS += -Werror -Wno-format-zero-length -Wmissing-declarations
+CFLAGS += -Werror -Wno-format-zero-length -Wmissing-declarations -Wformat-nonliteral
 CFLAGS += -I. -fPIC
 
 ifeq ($(CONFIG_Linux),y)
diff -r 62ff6a318c5d tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c        Wed Nov 30 16:59:58 2011 -0800
+++ b/tools/libxl/libxl_create.c        Fri Dec 02 17:49:57 2011 +0000
@@ -461,8 +461,8 @@
 
     path = libxl__xs_libxl_path(gc, domid);
     path = libxl__sprintf(gc, "%s/dm-version", path);
-    return libxl__xs_write(gc, XBT_NULL, path, libxl__strdup(gc,
-        libxl_device_model_version_to_string(dm_info->device_model_version)));
+    return libxl__xs_write(gc, XBT_NULL, path, "%s",
+        libxl_device_model_version_to_string(dm_info->device_model_version));
 }
 
 static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
diff -r 62ff6a318c5d tools/libxl/libxl_device.c
--- a/tools/libxl/libxl_device.c        Wed Nov 30 16:59:58 2011 -0800
+++ b/tools/libxl/libxl_device.c        Fri Dec 02 17:49:57 2011 +0000
@@ -516,7 +516,7 @@
         for (j = 0; j < num_devs; j++) {
             path = libxl__sprintf(gc, "/local/domain/%d/device/%s/%s/backend",
                                   domid, kinds[i], devs[j]);
-            path = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, path));
+            path = libxl__xs_read(gc, XBT_NULL, path);
             if (path && libxl__parse_backend_path(gc, path, &dev) == 0) {
                 dev.domid = domid;
                 dev.kind = kind;





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

From xen-devel-bounces@lists.xensource.com Fri Dec 02 18:09:41 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 18:09:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWXY0-0001w9-Nn; Fri, 02 Dec 2011 18:09:20 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RWXXy-0001vz-Ke
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 18:09:18 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1322849316!4054857!1
X-Originating-IP: [209.85.161.171]
X-SpamReason: No, hits=1.1 required=7.0 tests=DATE_IN_PAST_06_12,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6525 invoked from network); 2 Dec 2011 18:08:37 -0000
Received: from mail-gx0-f171.google.com (HELO mail-gx0-f171.google.com)
	(209.85.161.171)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Dec 2011 18:08:37 -0000
Received: by ggnr4 with SMTP id r4so21795468ggn.30
	for <xen-devel@lists.xensource.com>;
	Fri, 02 Dec 2011 10:08:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=5pvYA/8fWcTU3U1lsFY3oX15+hfGAxuwBrGar9aJ4As=;
	b=baaEuUgdMtKO6DoZ8ePYrxQLZywkH7I9TvXZ6tHmhOpg4+AFwEdPOBQRb7q6TU81yV
	5rLKnsJFz2wPLx8KtApQEs5EqIx/q9PMBsWubxA7brbjYxWjzzLzZ4HJTPxRsJ3rbqol
	d7t1ePFhneFjAPS6UxUEe/Dhr3lpQUNSjSc7w=
Received: by 10.182.59.49 with SMTP id w17mr2513287obq.37.1322849316116;
	Fri, 02 Dec 2011 10:08:36 -0800 (PST)
Received: from [192.168.0.132] ([142.103.56.220])
	by mx.google.com with ESMTPS id k8sm545911obi.3.2011.12.02.10.08.33
	(version=SSLv3 cipher=OTHER); Fri, 02 Dec 2011 10:08:35 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Fri, 02 Dec 2011 10:08:32 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Olaf Hering <olaf@aepfle.de>
Message-ID: <CAFE5420.2665C%keir.xen@gmail.com>
Thread-Topic: tools/libxc/xc_cpuid_x86.c:cpuid()'s inline asm
Thread-Index: AcyxHWaTVV6uSs/nc0SO6C7S3DlFUA==
In-Reply-To: <20111202164714.GB29226@aepfle.de>
Mime-version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] tools/libxc/xc_cpuid_x86.c:cpuid()'s inline asm
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 02/12/2011 16:47, "Olaf Hering" <olaf@aepfle.de> wrote:

> On Fri, Dec 02, Keir Fraser wrote:
> 
>> I think reg constraint failures had only been reported on 32-bit. So how
>> about the attached patch?
> 
> So finally I was able to test this change, and it fixes the reported segfault.
> Thanks!

I will sweep this through into 4.0/4.1 as part of a general backport sweep
next week.

 -- Keir

> Olaf



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

From xen-devel-bounces@lists.xensource.com Fri Dec 02 18:09:41 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 18:09:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWXY0-0001w9-Nn; Fri, 02 Dec 2011 18:09:20 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RWXXy-0001vz-Ke
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 18:09:18 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1322849316!4054857!1
X-Originating-IP: [209.85.161.171]
X-SpamReason: No, hits=1.1 required=7.0 tests=DATE_IN_PAST_06_12,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6525 invoked from network); 2 Dec 2011 18:08:37 -0000
Received: from mail-gx0-f171.google.com (HELO mail-gx0-f171.google.com)
	(209.85.161.171)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Dec 2011 18:08:37 -0000
Received: by ggnr4 with SMTP id r4so21795468ggn.30
	for <xen-devel@lists.xensource.com>;
	Fri, 02 Dec 2011 10:08:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=5pvYA/8fWcTU3U1lsFY3oX15+hfGAxuwBrGar9aJ4As=;
	b=baaEuUgdMtKO6DoZ8ePYrxQLZywkH7I9TvXZ6tHmhOpg4+AFwEdPOBQRb7q6TU81yV
	5rLKnsJFz2wPLx8KtApQEs5EqIx/q9PMBsWubxA7brbjYxWjzzLzZ4HJTPxRsJ3rbqol
	d7t1ePFhneFjAPS6UxUEe/Dhr3lpQUNSjSc7w=
Received: by 10.182.59.49 with SMTP id w17mr2513287obq.37.1322849316116;
	Fri, 02 Dec 2011 10:08:36 -0800 (PST)
Received: from [192.168.0.132] ([142.103.56.220])
	by mx.google.com with ESMTPS id k8sm545911obi.3.2011.12.02.10.08.33
	(version=SSLv3 cipher=OTHER); Fri, 02 Dec 2011 10:08:35 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Fri, 02 Dec 2011 10:08:32 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Olaf Hering <olaf@aepfle.de>
Message-ID: <CAFE5420.2665C%keir.xen@gmail.com>
Thread-Topic: tools/libxc/xc_cpuid_x86.c:cpuid()'s inline asm
Thread-Index: AcyxHWaTVV6uSs/nc0SO6C7S3DlFUA==
In-Reply-To: <20111202164714.GB29226@aepfle.de>
Mime-version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] tools/libxc/xc_cpuid_x86.c:cpuid()'s inline asm
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 02/12/2011 16:47, "Olaf Hering" <olaf@aepfle.de> wrote:

> On Fri, Dec 02, Keir Fraser wrote:
> 
>> I think reg constraint failures had only been reported on 32-bit. So how
>> about the attached patch?
> 
> So finally I was able to test this change, and it fixes the reported segfault.
> Thanks!

I will sweep this through into 4.0/4.1 as part of a general backport sweep
next week.

 -- Keir

> Olaf



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

From xen-devel-bounces@lists.xensource.com Fri Dec 02 18:33:32 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 18:33:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWXuw-0002Bv-2b; Fri, 02 Dec 2011 18:33:02 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <quartex73@gmail.com>) id 1RWXuu-0002Bh-Co
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 18:33:00 +0000
X-Env-Sender: quartex73@gmail.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1322850736!3992533!1
X-Originating-IP: [209.85.213.171]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18020 invoked from network); 2 Dec 2011 18:32:17 -0000
Received: from mail-yx0-f171.google.com (HELO mail-yx0-f171.google.com)
	(209.85.213.171)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Dec 2011 18:32:17 -0000
Received: by yenr9 with SMTP id r9so30933053yen.30
	for <xen-devel@lists.xensource.com>;
	Fri, 02 Dec 2011 10:32:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:date:message-id:subject:from:to:content-type
	:content-transfer-encoding;
	bh=7Wo8RAkcuMD/rYdA2/wVa7ozzneR0+SfJsYFl39DoqE=;
	b=KYUT/Y+xXDt5tsbulOezndW3N+55tVGiPRaJxktJ9DmAT0gDRf1HZr6tF1kGcq9Y2J
	nvYihhgYgKfq0usxXL5HrcckdnMqxphD2ujQZZWkCHijM0PW1sMFKgp2zbEQdMQ2LtyJ
	qP4ki8deU6ZNxDMe+oM+PpvaF5npTHiN9RRSg=
MIME-Version: 1.0
Received: by 10.236.197.72 with SMTP id s48mr20979339yhn.81.1322850736103;
	Fri, 02 Dec 2011 10:32:16 -0800 (PST)
Received: by 10.147.146.14 with HTTP; Fri, 2 Dec 2011 10:32:15 -0800 (PST)
Date: Fri, 2 Dec 2011 19:32:15 +0100
Message-ID: <CAMhBqqiLc1994GUKtA7UY52pR29nktmFy+XiwTwpZb_E+fwFRQ@mail.gmail.com>
From: Quartexx <quartex73@gmail.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] xen 4.0.1 w/2.6.32.47 hangs at boot
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi,
xen 4.0.1 (issue with 4.0.3 too)
kernel 2.6.32.47 (it happens with 2.6.32.46 too)

system hangs at boot (it doesnt' happen always, usually at poweron
it'sok, then after two or three reboot it happens)

(XEN) Xen version 4.0.1 (root@foo-net.private) (gcc version 4.4.5
(Debian 4.4.5-8) ) Fri Dec  2 16:56:12 CET 2011
(XEN) Latest ChangeSet: unavailable
(XEN) Bootloader: GNU GRUB 0.97
(XEN) Command line: dom0_mem=3D1024M loglvl=3Dall guest_loglvl=3Dall
com1=3D38400,8n1 console=3Dcom1
(XEN) Video information:
(XEN)  VGA is text mode 80x25, font 8x16
(XEN)  VBE/DDC methods: none; EDID transfer time: 0 seconds
(XEN)  EDID info not retrieved because no DDC retrieval method detected
(XEN) Disc information:
(XEN)  Found 1 MBR signatures
(XEN)  Found 1 EDD information structures
(XEN) Xen-e820 RAM map:
(XEN)  0000000000000000 - 000000000009b800 (usable)
(XEN)  000000000009b800 - 00000000000a0000 (reserved)
(XEN)  00000000000e0000 - 0000000000100000 (reserved)
(XEN)  0000000000100000 - 000000009dade000 (usable)
(XEN)  000000009dade000 - 000000009dbb0000 (ACPI NVS)
(XEN)  000000009dbb0000 - 000000009f6a4000 (ACPI data)
(XEN)  000000009f6a4000 - 000000009f6df000 (reserved)
(XEN)  000000009f6df000 - 000000009f78a000 (ACPI data)
(XEN)  000000009f78a000 - 000000009f7df000 (ACPI NVS)
(XEN)  000000009f7df000 - 000000009f800000 (ACPI data)
(XEN)  000000009f800000 - 00000000b0000000 (reserved)
(XEN)  00000000fed1c000 - 00000000fed20000 (reserved)
(XEN)  00000000ff800000 - 0000000100000000 (reserved)
(XEN)  0000000100000000 - 0000000460000000 (usable)
(XEN) ACPI: RSDP 000F0410, 0024 (r2 INTEL )
(XEN) ACPI: XSDT 9F7FD120, 008C (r1 INTEL  S3420GPC        0       1000013)
(XEN) ACPI: FACP 9F7FB000, 00F4 (r4 INTEL  S3420GPC        0 MSFT  100000D)
(XEN) ACPI: DSDT 9F7F6000, 4E22 (r2 INTEL  S3420GPC        3 MSFT  100000D)
(XEN) ACPI: FACS 9F78A000, 0040
(XEN) ACPI: APIC 9F7F5000, 00BC (r2 INTEL  S3420GPC        0 MSFT  100000D)
(XEN) ACPI: MCFG 9F7F4000, 003C (r1 INTEL  S3420GPC        1 MSFT  100000D)
(XEN) ACPI: HPET 9F7F3000, 0038 (r1 INTEL  S3420GPC        1 MSFT  100000D)
(XEN) ACPI: SLIT 9F7F2000, 0030 (r1 INTEL  S3420GPC        1 MSFT  100000D)
(XEN) ACPI: SPCR 9F7F1000, 0050 (r1 INTEL  S3420GPC        0 MSFT  100000D)
(XEN) ACPI: WDDT 9F7F0000, 0040 (r1 INTEL  S3420GPC        0 MSFT  100000D)
(XEN) ACPI: SSDT 9F7E5000, AEF4 (r2  INTEL SSDT  PM     4000 INTL 20061109)
(XEN) ACPI: SSDT 9F7E4000, 01D8 (r2  INTEL IPMI         4000 INTL 20061109)
(XEN) ACPI: HEST 9F7E3000, 00A8 (r1 INTEL  S3420GPC        1 INTL        1)
(XEN) ACPI: BERT 9F7E2000, 0030 (r1 INTEL  S3420GPC        1 INTL        1)
(XEN) ACPI: ERST 9F7E1000, 0230 (r1 INTEL  S3420GPC        1 INTL        1)
(XEN) ACPI: EINJ 9F7E0000, 0130 (r1 INTEL  S3420GPC        1 INTL        1)
(XEN) System RAM: 16346MB (16738788kB)
(XEN) No NUMA configuration found
(XEN) Faking a node at 0000000000000000-0000000460000000
(XEN) Domain heap initialised
(XEN) found SMP MP-table at 000fd9a0
(XEN) DMI 2.5 present.
(XEN) Using APIC driver default
(XEN) ACPI: PM-Timer IO Port: 0x408
(XEN) ACPI: ACPI SLEEP INFO: pm1x_cnt[404,0], pm1x_evt[400,0]
(XEN) ACPI:                  wakeup_vec[9f78a00c], vec_size[20]
(XEN) ACPI: Local APIC address 0xfee00000
(XEN) ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
(XEN) Processor #0 7:14 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x02] enabled)
(XEN) Processor #2 7:14 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x02] lapic_id[0x04] enabled)
(XEN) Processor #4 7:14 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x03] lapic_id[0x06] enabled)
(XEN) Processor #6 7:14 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x04] lapic_id[0x01] disabled)
(XEN) ACPI: LAPIC (acpi_id[0x05] lapic_id[0x03] disabled)
(XEN) ACPI: LAPIC (acpi_id[0x06] lapic_id[0x05] disabled)
(XEN) ACPI: LAPIC (acpi_id[0x07] lapic_id[0x07] disabled)
(XEN) ACPI: LAPIC_NMI (acpi_id[0x00] high level lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x01] high level lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x02] high level lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x03] high level lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x04] high level lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x05] high level lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x06] high level lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x07] high level 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: 0x8086a801 base: 0xfed00000
(XEN) PCI: MCFG configuration 0: base a0000000 segment 0 buses 0 - 255
(XEN) PCI: MCFG area at a0000000 reserved in E820
(XEN) Using ACPI (MADT) for SMP configuration information
(XEN) Using scheduler: SMP Credit Scheduler (credit)
(XEN) Detected 2400.057 MHz processor.
(XEN) Initing memory sharing.
(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) EPT supports 2MB super page.
(XEN) HVM: ASIDs enabled.
(XEN) HVM: VMX enabled
(XEN) HVM: Hardware Assisted Paging detected.
(XEN) Intel machine check reporting enabled
(XEN) I/O virtualisation disabled
(XEN) Total of 4 processors activated.
(XEN) ENABLING IO-APIC IRQs
(XEN)  -> Using new ACK method
(XEN) ..TIMER: vector=3D0xF0 apic1=3D0 pin1=3D2 apic2=3D-1 pin2=3D-1
(XEN) TSC is reliable, synchronization unnecessary
(XEN) Platform timer appears to have unexpectedly wrapped 1 times.
(XEN) Platform timer is 14.318MHz HPET
=FF(XEN) Allocated console ring of 32 KiB.
(XEN) microcode.c:73:d32767 microcode: CPU1 resumed
(XEN) microcode.c:73:d32767 microcode: CPU2 resumed
(XEN) Brought up 4 CPUs
(XEN) microcode.c:73:d32767 microcode: CPU3 resumed
(XEN) Turbo Mode detected!
(XEN) HPET: 8 timers in total, 8 timers will be used for broadcast
(XEN) ACPI sleep modes: S3
(XEN) mcheck_poll: Machine check polling timer started.
(XEN) *** LOADING DOMAIN 0 ***
(XEN)  Xen  kernel: 64-bit, lsb, compat32
(XEN)  Dom0 kernel: 64-bit, PAE, lsb, paddr 0x1000000 -> 0x1bfc000
(XEN) PHYSICAL MEMORY ARRANGEMENT:
(XEN)  Dom0 alloc.:   0000000450000000->0000000454000000 (245760 pages
to be allocated)
(XEN) VIRTUAL MEMORY ARRANGEMENT:
(XEN)  Loaded kernel: ffffffff81000000->ffffffff81bfc000
(XEN)  Init. ramdisk: ffffffff81bfc000->ffffffff820c8600
(XEN)  Phys-Mach map: ffffffff820c9000->ffffffff822c9000
(XEN)  Start info:    ffffffff822c9000->ffffffff822c94b4
(XEN)  Page tables:   ffffffff822ca000->ffffffff822df000
(XEN)  Boot stack:    ffffffff822df000->ffffffff822e0000
(XEN)  TOTAL:         ffffffff80000000->ffffffff82400000
(XEN)  ENTRY ADDRESS: ffffffff81976200
(XEN) Dom0 has maximum 4 VCPUs
(XEN) Scrubbing Free RAM:
...........................................................................=
...........................................................................=
..done.
(XEN) trace.c:89:d32767 calc_tinfo_first_offset: NR_CPUs 128,
offset_in_bytes 258, t_info_first_offset 65
(XEN) Xen trace buffers: disabled
(XEN) Std. Loglevel: All
(XEN) Guest Loglevel: All
(XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch
input to Xen)
(XEN) Freed 176kB init memory.
mapping kernel into physical memory
Xen: setup ISA identity maps
about to get started...
[    0.000000] Initializing cgroup subsys cpuset
[    0.000000] Initializing cgroup subsys cpu
[    0.000000] Linux version 2.6.32.46 (root@xenhost-rack2) (gcc
version 4.4.5 (Debian 4.4.5-8) ) #1 SMP Wed Oct 12 16:48:53 CEST 2011
[    0.000000] Command line:
root=3DUUID=3D5563bc26-6e98-4768-abee-5ca053e2795c ro nomodeset
max_loop=3D255 console=3Dhvc0 earlyprintk=3Dxen
[    0.000000] KERNEL supported cpus:
[    0.000000]   Intel GenuineIntel
[    0.000000]   AMD AuthenticAMD
[    0.000000]   Centaur CentaurHauls
[    0.000000] released 0 pages of unused memory
[    0.000000] BIOS-provided physical RAM map:
[    0.000000]  Xen: 0000000000000000 - 000000000009b000 (usable)
[    0.000000]  Xen: 000000000009b800 - 0000000000100000 (reserved)
[    0.000000]  Xen: 0000000000100000 - 0000000040000000 (usable)
[    0.000000]  Xen: 0000000040000000 - 000000009dade000 (unusable)
[    0.000000]  Xen: 000000009dade000 - 000000009dbb0000 (ACPI NVS)
[    0.000000]  Xen: 000000009dbb0000 - 000000009f6a4000 (ACPI data)
[    0.000000]  Xen: 000000009f6a4000 - 000000009f6df000 (reserved)
[    0.000000]  Xen: 000000009f6df000 - 000000009f78a000 (ACPI data)
[    0.000000]  Xen: 000000009f78a000 - 000000009f7df000 (ACPI NVS)
[    0.000000]  Xen: 000000009f7df000 - 000000009f800000 (ACPI data)
[    0.000000]  Xen: 000000009f800000 - 00000000b0000000 (reserved)
[    0.000000]  Xen: 00000000fec00000 - 00000000fec01000 (reserved)
[    0.000000]  Xen: 00000000fed1c000 - 00000000fed20000 (reserved)
[    0.000000]  Xen: 00000000fee00000 - 00000000fee01000 (reserved)
[    0.000000]  Xen: 00000000ff800000 - 0000000100000000 (reserved)
[    0.000000]  Xen: 0000000100000000 - 0000000340000000 (usable)
[    0.000000] bootconsole [xenboot0] enabled
[    0.000000] DMI 2.5 present.
[    0.000000] last_pfn =3D 0x340000 max_arch_pfn =3D 0x400000000
[    0.000000] x86 PAT enabled: cpu 0, old 0x50100070406, new 0x70106000701=
06
[    0.000000] last_pfn =3D 0x40000 max_arch_pfn =3D 0x400000000
[    0.000000] Scanning 1 areas for low memory corruption
[    0.000000] modified physical RAM map:
[    0.000000]  modified: 0000000000000000 - 0000000000001000 (usable)
[    0.000000]  modified: 0000000000001000 - 0000000000006000 (reserved)
[    0.000000]  modified: 0000000000006000 - 000000000009b000 (usable)
[    0.000000]  modified: 000000000009b800 - 0000000000100000 (reserved)
[    0.000000]  modified: 0000000000100000 - 0000000040000000 (usable)
[    0.000000]  modified: 0000000040000000 - 000000009dade000 (unusable)
[    0.000000]  modified: 000000009dade000 - 000000009dbb0000 (ACPI NVS)
[    0.000000]  modified: 000000009dbb0000 - 000000009f6a4000 (ACPI data)
[    0.000000]  modified: 000000009f6a4000 - 000000009f6df000 (reserved)
[    0.000000]  modified: 000000009f6df000 - 000000009f78a000 (ACPI data)
[    0.000000]  modified: 000000009f78a000 - 000000009f7df000 (ACPI NVS)
[    0.000000]  modified: 000000009f7df000 - 000000009f800000 (ACPI data)
[    0.000000]  modified: 000000009f800000 - 00000000b0000000 (reserved)
[    0.000000]  modified: 00000000fec00000 - 00000000fec01000 (reserved)
[    0.000000]  modified: 00000000fed1c000 - 00000000fed20000 (reserved)
[    0.000000]  modified: 00000000fee00000 - 00000000fee01000 (reserved)
[    0.000000]  modified: 00000000ff800000 - 0000000100000000 (reserved)
[    0.000000]  modified: 0000000100000000 - 0000000340000000 (usable)
[    0.000000] init_memory_mapping: 0000000000000000-0000000040000000
[    0.000000] init_memory_mapping: 0000000100000000-0000000340000000
[    0.000000] RAMDISK: 01bfc000 - 020c8600
[    0.000000] ACPI: RSDP 00000000000f0410 00024 (v02 INTEL )
[    0.000000] ACPI: XSDT 000000009f7fd120 0008C (v01 INTEL  S3420GPC
00000000      01000013)
[    0.000000] ACPI: FACP 000000009f7fb000 000F4 (v04 INTEL  S3420GPC
00000000 MSFT 0100000D)
[    0.000000] ACPI: DSDT 000000009f7f6000 04E22 (v02 INTEL  S3420GPC
00000003 MSFT 0100000D)
[    0.000000] ACPI: FACS 000000009f78a000 00040
[    0.000000] ACPI: APIC 000000009f7f5000 000BC (v02 INTEL  S3420GPC
00000000 MSFT 0100000D)
[    0.000000] ACPI: MCFG 000000009f7f4000 0003C (v01 INTEL  S3420GPC
00000001 MSFT 0100000D)
[    0.000000] ACPI: HPET 000000009f7f3000 00038 (v01 INTEL  S3420GPC
00000001 MSFT 0100000D)
[    0.000000] ACPI: SLIT 000000009f7f2000 00030 (v01 INTEL  S3420GPC
00000001 MSFT 0100000D)
[    0.000000] ACPI: SPCR 000000009f7f1000 00050 (v01 INTEL  S3420GPC
00000000 MSFT 0100000D)
[    0.000000] ACPI: WDDT 000000009f7f0000 00040 (v01 INTEL  S3420GPC
00000000 MSFT 0100000D)
[    0.000000] ACPI: SSDT 000000009f7e5000 0AEF4 (v02  INTEL SSDT  PM
00004000 INTL 20061109)
[    0.000000] ACPI: SSDT 000000009f7e4000 001D8 (v02  INTEL IPMI
00004000 INTL 20061109)
[    0.000000] ACPI: HEST 000000009f7e3000 000A8 (v01 INTEL  S3420GPC
00000001 INTL 00000001)
[    0.000000] ACPI: BERT 000000009f7e2000 00030 (v01 INTEL  S3420GPC
00000001 INTL 00000001)
[    0.000000] ACPI: ERST 000000009f7e1000 00230 (v01 INTEL  S3420GPC
00000001 INTL 00000001)
[    0.000000] ACPI: EINJ 000000009f7e0000 00130 (v01 INTEL  S3420GPC
00000001 INTL 00000001)
[    0.000000] (10 early reservations) =3D=3D> bootmem [0000000000 - 034000=
0000]
[    0.000000]   #0 [0000000000 - 0000001000]   BIOS data page =3D=3D>
[0000000000 - 0000001000]
[    0.000000]   #1 [00022ca000 - 00022df000]   XEN PAGETABLES =3D=3D>
[00022ca000 - 00022df000]
[    0.000000]   #2 [0000006000 - 0000008000]       TRAMPOLINE =3D=3D>
[0000006000 - 0000008000]
[    0.000000]   #3 [0001000000 - 0001ad1474]    TEXT DATA BSS =3D=3D>
[0001000000 - 0001ad1474]
[    0.000000]   #4 [0001bfc000 - 00020c8600]          RAMDISK =3D=3D>
[0001bfc000 - 00020c8600]
[    0.000000]   #5 [00020c9000 - 00022ca000]   XEN START INFO =3D=3D>
[00020c9000 - 00022ca000]
[    0.000000]   #6 [0100000000 - 0340000000]        XEN EXTRA =3D=3D>
[0100000000 - 0340000000]
[    0.000000]   #7 [0001ad2000 - 0001ade36c]              BRK =3D=3D>
[0001ad2000 - 0001ade36c]
[    0.000000]   #8 [0000100000 - 00002ea000]          PGTABLE =3D=3D>
[0000100000 - 00002ea000]
[    0.000000]   #9 [00022df000 - 00034e8000]          PGTABLE =3D=3D>
[00022df000 - 00034e8000]
[    0.000000] found SMP MP-table at [ffff8800000fd9a0] fd9a0
[    0.000000] Zone PFN ranges:
[    0.000000]   DMA      0x00000000 -> 0x00001000
[    0.000000]   DMA32    0x00001000 -> 0x00100000
[    0.000000]   Normal   0x00100000 -> 0x00340000
[    0.000000] Movable zone start PFN for each node
[    0.000000] early_node_map[4] active PFN ranges
[    0.000000]     0: 0x00000000 -> 0x00000001
[    0.000000]     0: 0x00000006 -> 0x0000009b
[    0.000000]     0: 0x00000100 -> 0x00040000
[    0.000000]     0: 0x00100000 -> 0x00340000
[    0.000000] ACPI: PM-Timer IO Port: 0x408
[    0.000000] ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x02] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x04] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x03] lapic_id[0x06] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x04] lapic_id[0x01] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x05] lapic_id[0x03] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x06] lapic_id[0x05] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x07] lapic_id[0x07] disabled)
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x00] high level lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x01] high level lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x02] high level lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x03] high level lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x04] high level lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x05] high level lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x06] high level lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x07] high level lint[0x1])
[    0.000000] ACPI: IOAPIC (id[0x08] address[0xfec00000] gsi_base[0])
[    0.000000] IOAPIC[0]: apic_id 8, version 0, address 0xfec00000, GSI 0-0
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
[    0.000000] ERROR: Unable to locate IOAPIC for GSI 2
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
[    0.000000] ERROR: Unable to locate IOAPIC for GSI 9
[    0.000000] Using ACPI (MADT) for SMP configuration information
[    0.000000] ACPI: HPET id: 0x8086a801 base: 0xfed00000
[    0.000000] SMP: Allowing 4 CPUs, 0 hotplug CPUs
[    0.000000] PM: Registered nosave memory: 0000000000001000 - 00000000000=
06000
[    0.000000] PM: Registered nosave memory: 000000000009b000 - 00000000000=
9c000
[    0.000000] PM: Registered nosave memory: 000000000009c000 - 00000000001=
00000
[    0.000000] PM: Registered nosave memory: 0000000040000000 - 000000009da=
de000
[    0.000000] PM: Registered nosave memory: 000000009dade000 - 000000009db=
b0000
[    0.000000] PM: Registered nosave memory: 000000009dbb0000 - 000000009f6=
a4000
[    0.000000] PM: Registered nosave memory: 000000009f6a4000 - 000000009f6=
df000
[    0.000000] PM: Registered nosave memory: 000000009f6df000 - 000000009f7=
8a000
[    0.000000] PM: Registered nosave memory: 000000009f78a000 - 000000009f7=
df000
[    0.000000] PM: Registered nosave memory: 000000009f7df000 - 000000009f8=
00000
[    0.000000] PM: Registered nosave memory: 000000009f800000 - 00000000b00=
00000
[    0.000000] PM: Registered nosave memory: 00000000b0000000 - 00000000fec=
00000
[    0.000000] PM: Registered nosave memory: 00000000fec00000 - 00000000fec=
01000
[    0.000000] PM: Registered nosave memory: 00000000fec01000 - 00000000fed=
1c000
[    0.000000] PM: Registered nosave memory: 00000000fed1c000 - 00000000fed=
20000
[    0.000000] PM: Registered nosave memory: 00000000fed20000 - 00000000fee=
00000
[    0.000000] PM: Registered nosave memory: 00000000fee00000 - 00000000fee=
01000
[    0.000000] PM: Registered nosave memory: 00000000fee01000 - 00000000ff8=
00000
[    0.000000] PM: Registered nosave memory: 00000000ff800000 - 00000001000=
00000
[    0.000000] Allocating PCI resources starting at b0000000 (gap:
b0000000:4ec00000)
[    0.000000] Booting paravirtualized kernel on Xen
[    0.000000] Xen version: 4.0.1 (preserve-AD) (dom0)
[    0.000000] NR_CPUS:8 nr_cpumask_bits:8 nr_cpu_ids:4 nr_node_ids:1
[    0.000000] PERCPU: Embedded 29 pages/cpu @ffff880028038000 s88536
r8192 d22056 u118784
[    0.000000] pcpu-alloc: s88536 r8192 d22056 u118784 alloc=3D29*4096
[    0.000000] pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3
[    2.710494] Built 1 zonelists in Zone order, mobility grouping on.
Total pages: 2574249
[    2.710498] Kernel command line:
root=3DUUID=3D5563bc26-6e98-4768-abee-5ca053e2795c ro nomodeset
max_loop=3D255 console=3Dhvc0 earlyprintk=3Dxen
[    2.710547] PID hash table entries: 4096 (order: 3, 32768 bytes)
[    2.712182] Dentry cache hash table entries: 2097152 (order: 12,
16777216 bytes)
[    2.716022] Inode-cache hash table entries: 1048576 (order: 11,
8388608 bytes)
[    2.717879] Initializing CPU#0
[    2.724732] DMA: Placing 64MB software IO TLB between
ffff880020000000 - ffff880024000000
[    2.724738] DMA: software IO TLB at phys 0x20000000 - 0x24000000
[    2.724741] xen_swiotlb_fixup: buf=3Dffff880020000000 size=3D67108864
[    2.742551] xen_swiotlb_fixup: buf=3Dffff880024060000 size=3D32768
[    2.745990] Memory: 774160k/13631488k available (5876k kernel code,
3146152k absent, 9710444k reserved, 3718k data, 568k init)
[    2.746017] SLUB: Genslabs=3D13, HWalign=3D64, Order=3D0-3, MinObjects=
=3D0,
CPUs=3D4, Nodes=3D1
[    2.746036] Hierarchical RCU implementation.
[    2.746041] NR_IRQS:4352 nr_irqs:1280
[    2.746192] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
[    2.746196] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
[    2.746200] xen: sci override: source_irq=3D9 global_irq=3D9 trigger=3Dc=
 polarity=3D1
[    2.746205] xen_allocate_pirq: returning irq 9 for gsi 9
[    2.746213] xen: acpi sci 9
[    2.757067] Console: colour VGA+ 80x25
[    2.757072] console [hvc0] enabled, bootconsole disabled
[    2.757072] console [hvc0] enabled, bootconsole disabled
[    2.757090] installing Xen timer for CPU 0
[    2.757119] Detected 2400.056 MHz processor.
[    2.757126] Calibrating delay loop (skipped), value calculated
using timer frequency.. 4800.11 BogoMIPS (lpj=3D2400056)
[    2.757143] Security Framework initialized
[    2.757148] SELinux:  Initializing.
[    2.757162] Mount-cache hash table entries: 256
[    2.757288] Initializing cgroup subsys ns
[    2.757294] Initializing cgroup subsys cpuacct
[    2.757299] Initializing cgroup subsys freezer
[    2.757332] CPU: L1 I cache: 32K, L1 D cache: 32K
[    2.757336] CPU: L2 cache: 256K
[    2.757339] CPU: L3 cache: 8192K
[    2.757343] CPU: Unsupported number of siblings 16
[    2.757348] mce: CPU supports 9 MCE banks
[    2.757371] Performance Events: unsupported p6 CPU model 30 no PMU
driver, software events only.
[    2.757387] SMP alternatives: switching to UP code
[    2.794584] ACPI: Core revision 20090903
[    2.815504] installing Xen timer for CPU 1
[    2.815533] SMP alternatives: switching to SMP code
[    2.851777] Initializing CPU#1
[    2.851813] CPU: L1 I cache: 32K, L1 D cache: 32K
[    2.851815] CPU: L2 cache: 256K
[    2.851816] CPU: L3 cache: 8192K
[    2.851820] CPU: Unsupported number of siblings 16
[    2.851896] installing Xen timer for CPU 2
[    2.851961] Initializing CPU#2
[    2.851995] CPU: L1 I cache: 32K, L1 D cache: 32K
[    2.851997] CPU: L2 cache: 256K
[    2.851998] CPU: L3 cache: 8192K
[    2.852002] CPU: Unsupported number of siblings 16
[    2.852070] installing Xen timer for CPU 3
[    2.852132] Initializing CPU#3
[    2.852165] CPU: L1 I cache: 32K, L1 D cache: 32K
[    2.852168] CPU: L2 cache: 256K
[    2.852169] CPU: L3 cache: 8192K
[    2.852173] CPU: Unsupported number of siblings 16
[    2.852205] Brought up 4 CPUs
[    2.853032] Grant table initialized
[    2.853065] Time: 16:22:10  Date: 12/02/11
[    2.853112] NET: Registered protocol family 16
[    2.853696] ACPI FADT declares the system doesn't support PCIe
ASPM, so disable it
[    2.853701] ACPI: bus type pci registered
[    2.854119] PCI: MCFG configuration 0: base a0000000 segment 0 buses 0 -=
 255
[    2.854124] PCI: MCFG area at a0000000 reserved in E820
[    2.878058] PCI: Using MMCONFIG at a0000000 - afffffff
[    2.878063] PCI: Using configuration type 1 for base access
[    2.890548] bio: create slab <bio-0> at 0
[    2.891518] ERROR: Unable to locate IOAPIC for GSI 9
[    2.893192] ACPI Error: Field [CPB3] at 96 exceeds Buffer [NULL]
size 64 (bits) (20090903/dsopcode-596)
[    2.893203] ACPI Error (psparse-0537): Method parse/execution
failed [\_SB_._OSC] (Node ffff88003fc187c0), AE_AML_BUFFER_LIMIT
[    2.917957] ACPI: Interpreter enabled
[    2.917962] ACPI: (supports S0 S1 S5)
[    2.917987] ACPI: Using IOAPIC for interrupt routing
[    2.931854] ACPI: No dock devices found.
[    2.932646] ACPI: PCI Root Bridge [PCI0] (0000:00)
[    2.932931] pci 0000:00:05.0: PME# supported from D0 D3hot D3cold
[    2.932939] pci 0000:00:05.0: PME# disabled
[    2.933685] pci 0000:00:19.0: PME# supported from D0 D3hot D3cold
[    2.933692] pci 0000:00:19.0: PME# disabled
[    2.933874] pci 0000:00:1a.0: PME# supported from D0 D3hot D3cold
[    2.933882] pci 0000:00:1a.0: PME# disabled
[    2.934001] pci 0000:00:1c.0: PME# supported from D0 D3hot D3cold
[    2.934008] pci 0000:00:1c.0: PME# disabled
[    2.934131] pci 0000:00:1c.4: PME# supported from D0 D3hot D3cold
[    2.934138] pci 0000:00:1c.4: PME# disabled
[    2.934257] pci 0000:00:1c.6: PME# supported from D0 D3hot D3cold
[    2.934264] pci 0000:00:1c.6: PME# disabled
[    2.934381] pci 0000:00:1c.7: PME# supported from D0 D3hot D3cold
[    2.934389] pci 0000:00:1c.7: PME# disabled
[    2.934635] pci 0000:00:1d.0: PME# supported from D0 D3hot D3cold
[    2.934643] pci 0000:00:1d.0: PME# disabled
[    2.935817] pci 0000:03:00.0: PME# supported from D0 D3hot D3cold
[    2.935827] pci 0000:03:00.0: PME# disabled
[    2.936372] pci 0000:00:1e.0: transparent bridge
(XEN) PCI add device 00:00.0
(XEN) PCI add device 00:05.0
(XEN) PCI add device 00:08.0
(XEN) PCI add device 00:08.1
(XEN) PCI add device 00:08.2
(XEN) PCI add device 00:08.3
(XEN) PCI add device 00:10.0
(XEN) PCI add device 00:10.1
(XEN) PCI add device 00:19.0
(XEN) PCI add device 00:1a.0
(XEN) PCI add device 00:1c.0
(XEN) PCI add device 00:1c.4
(XEN) PCI add device 00:1c.6
(XEN) PCI add device 00:1c.7
(XEN) PCI add device 00:1d.0
(XEN) PCI add device 00:1e.0
(XEN) PCI add device 00:1f.0
(XEN) PCI add device 00:1f.2
(XEN) PCI add device 00:1f.3
(XEN) PCI add device 00:1f.5
(XEN) PCI add device 01:00.0
(XEN) PCI add device 03:00.0
(XEN) PCI add device 04:00.0
[    2.947993] ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 9 *10
11 12 14 15)
[    2.948136] ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 9 10
*11 12 14 15)
[    2.948276] ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 *5 6 7 9 10
11 12 14 15)
[    2.948415] ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 7 9 10
*11 12 14 15)
[    2.948554] ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 7 9 10 11
12 14 15) *0, disabled.
[    2.948695] ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 6 7 *9 10
11 12 14 15)
[    2.948890] ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 6 7 *9 10
11 12 14 15)
[    2.949032] ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 6 7 9 *10
11 12 14 15)
[    2.949290] xen_balloon: Initialising balloon driver with page order 0.
[    2.949389] last_pfn =3D 0x340000 max_arch_pfn =3D 0x __  __
_  _    ___   _


then it hangs

xend-config.sxp relevant directives:

(xend-relocation-server yes)
(dom0-min-mem 1024)
(enable-dom0-ballooning no)
(dom0-cpus 0)

grub:
title           Xen 4.0.1 / Debian GNU/Linux, kernel 2.6.32.47
root            (hd0,0)
kernel          /boot/xen-4.0.1.gz dom0_mem=3D1024M max_cstate=3D1
module          /boot/vmlinuz-2.6.32.47
root=3DUUID=3D5563bc26-6e98-4768-abee-5ca053e2795c ro nomodeset
max_loop=3D255
module          /boot/initrd.img-2.6.32.47


Thanks for your help

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

From xen-devel-bounces@lists.xensource.com Fri Dec 02 18:33:32 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 18:33:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWXuw-0002Bv-2b; Fri, 02 Dec 2011 18:33:02 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <quartex73@gmail.com>) id 1RWXuu-0002Bh-Co
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 18:33:00 +0000
X-Env-Sender: quartex73@gmail.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1322850736!3992533!1
X-Originating-IP: [209.85.213.171]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18020 invoked from network); 2 Dec 2011 18:32:17 -0000
Received: from mail-yx0-f171.google.com (HELO mail-yx0-f171.google.com)
	(209.85.213.171)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Dec 2011 18:32:17 -0000
Received: by yenr9 with SMTP id r9so30933053yen.30
	for <xen-devel@lists.xensource.com>;
	Fri, 02 Dec 2011 10:32:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:date:message-id:subject:from:to:content-type
	:content-transfer-encoding;
	bh=7Wo8RAkcuMD/rYdA2/wVa7ozzneR0+SfJsYFl39DoqE=;
	b=KYUT/Y+xXDt5tsbulOezndW3N+55tVGiPRaJxktJ9DmAT0gDRf1HZr6tF1kGcq9Y2J
	nvYihhgYgKfq0usxXL5HrcckdnMqxphD2ujQZZWkCHijM0PW1sMFKgp2zbEQdMQ2LtyJ
	qP4ki8deU6ZNxDMe+oM+PpvaF5npTHiN9RRSg=
MIME-Version: 1.0
Received: by 10.236.197.72 with SMTP id s48mr20979339yhn.81.1322850736103;
	Fri, 02 Dec 2011 10:32:16 -0800 (PST)
Received: by 10.147.146.14 with HTTP; Fri, 2 Dec 2011 10:32:15 -0800 (PST)
Date: Fri, 2 Dec 2011 19:32:15 +0100
Message-ID: <CAMhBqqiLc1994GUKtA7UY52pR29nktmFy+XiwTwpZb_E+fwFRQ@mail.gmail.com>
From: Quartexx <quartex73@gmail.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] xen 4.0.1 w/2.6.32.47 hangs at boot
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi,
xen 4.0.1 (issue with 4.0.3 too)
kernel 2.6.32.47 (it happens with 2.6.32.46 too)

system hangs at boot (it doesnt' happen always, usually at poweron
it'sok, then after two or three reboot it happens)

(XEN) Xen version 4.0.1 (root@foo-net.private) (gcc version 4.4.5
(Debian 4.4.5-8) ) Fri Dec  2 16:56:12 CET 2011
(XEN) Latest ChangeSet: unavailable
(XEN) Bootloader: GNU GRUB 0.97
(XEN) Command line: dom0_mem=3D1024M loglvl=3Dall guest_loglvl=3Dall
com1=3D38400,8n1 console=3Dcom1
(XEN) Video information:
(XEN)  VGA is text mode 80x25, font 8x16
(XEN)  VBE/DDC methods: none; EDID transfer time: 0 seconds
(XEN)  EDID info not retrieved because no DDC retrieval method detected
(XEN) Disc information:
(XEN)  Found 1 MBR signatures
(XEN)  Found 1 EDD information structures
(XEN) Xen-e820 RAM map:
(XEN)  0000000000000000 - 000000000009b800 (usable)
(XEN)  000000000009b800 - 00000000000a0000 (reserved)
(XEN)  00000000000e0000 - 0000000000100000 (reserved)
(XEN)  0000000000100000 - 000000009dade000 (usable)
(XEN)  000000009dade000 - 000000009dbb0000 (ACPI NVS)
(XEN)  000000009dbb0000 - 000000009f6a4000 (ACPI data)
(XEN)  000000009f6a4000 - 000000009f6df000 (reserved)
(XEN)  000000009f6df000 - 000000009f78a000 (ACPI data)
(XEN)  000000009f78a000 - 000000009f7df000 (ACPI NVS)
(XEN)  000000009f7df000 - 000000009f800000 (ACPI data)
(XEN)  000000009f800000 - 00000000b0000000 (reserved)
(XEN)  00000000fed1c000 - 00000000fed20000 (reserved)
(XEN)  00000000ff800000 - 0000000100000000 (reserved)
(XEN)  0000000100000000 - 0000000460000000 (usable)
(XEN) ACPI: RSDP 000F0410, 0024 (r2 INTEL )
(XEN) ACPI: XSDT 9F7FD120, 008C (r1 INTEL  S3420GPC        0       1000013)
(XEN) ACPI: FACP 9F7FB000, 00F4 (r4 INTEL  S3420GPC        0 MSFT  100000D)
(XEN) ACPI: DSDT 9F7F6000, 4E22 (r2 INTEL  S3420GPC        3 MSFT  100000D)
(XEN) ACPI: FACS 9F78A000, 0040
(XEN) ACPI: APIC 9F7F5000, 00BC (r2 INTEL  S3420GPC        0 MSFT  100000D)
(XEN) ACPI: MCFG 9F7F4000, 003C (r1 INTEL  S3420GPC        1 MSFT  100000D)
(XEN) ACPI: HPET 9F7F3000, 0038 (r1 INTEL  S3420GPC        1 MSFT  100000D)
(XEN) ACPI: SLIT 9F7F2000, 0030 (r1 INTEL  S3420GPC        1 MSFT  100000D)
(XEN) ACPI: SPCR 9F7F1000, 0050 (r1 INTEL  S3420GPC        0 MSFT  100000D)
(XEN) ACPI: WDDT 9F7F0000, 0040 (r1 INTEL  S3420GPC        0 MSFT  100000D)
(XEN) ACPI: SSDT 9F7E5000, AEF4 (r2  INTEL SSDT  PM     4000 INTL 20061109)
(XEN) ACPI: SSDT 9F7E4000, 01D8 (r2  INTEL IPMI         4000 INTL 20061109)
(XEN) ACPI: HEST 9F7E3000, 00A8 (r1 INTEL  S3420GPC        1 INTL        1)
(XEN) ACPI: BERT 9F7E2000, 0030 (r1 INTEL  S3420GPC        1 INTL        1)
(XEN) ACPI: ERST 9F7E1000, 0230 (r1 INTEL  S3420GPC        1 INTL        1)
(XEN) ACPI: EINJ 9F7E0000, 0130 (r1 INTEL  S3420GPC        1 INTL        1)
(XEN) System RAM: 16346MB (16738788kB)
(XEN) No NUMA configuration found
(XEN) Faking a node at 0000000000000000-0000000460000000
(XEN) Domain heap initialised
(XEN) found SMP MP-table at 000fd9a0
(XEN) DMI 2.5 present.
(XEN) Using APIC driver default
(XEN) ACPI: PM-Timer IO Port: 0x408
(XEN) ACPI: ACPI SLEEP INFO: pm1x_cnt[404,0], pm1x_evt[400,0]
(XEN) ACPI:                  wakeup_vec[9f78a00c], vec_size[20]
(XEN) ACPI: Local APIC address 0xfee00000
(XEN) ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
(XEN) Processor #0 7:14 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x02] enabled)
(XEN) Processor #2 7:14 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x02] lapic_id[0x04] enabled)
(XEN) Processor #4 7:14 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x03] lapic_id[0x06] enabled)
(XEN) Processor #6 7:14 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x04] lapic_id[0x01] disabled)
(XEN) ACPI: LAPIC (acpi_id[0x05] lapic_id[0x03] disabled)
(XEN) ACPI: LAPIC (acpi_id[0x06] lapic_id[0x05] disabled)
(XEN) ACPI: LAPIC (acpi_id[0x07] lapic_id[0x07] disabled)
(XEN) ACPI: LAPIC_NMI (acpi_id[0x00] high level lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x01] high level lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x02] high level lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x03] high level lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x04] high level lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x05] high level lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x06] high level lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x07] high level 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: 0x8086a801 base: 0xfed00000
(XEN) PCI: MCFG configuration 0: base a0000000 segment 0 buses 0 - 255
(XEN) PCI: MCFG area at a0000000 reserved in E820
(XEN) Using ACPI (MADT) for SMP configuration information
(XEN) Using scheduler: SMP Credit Scheduler (credit)
(XEN) Detected 2400.057 MHz processor.
(XEN) Initing memory sharing.
(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) EPT supports 2MB super page.
(XEN) HVM: ASIDs enabled.
(XEN) HVM: VMX enabled
(XEN) HVM: Hardware Assisted Paging detected.
(XEN) Intel machine check reporting enabled
(XEN) I/O virtualisation disabled
(XEN) Total of 4 processors activated.
(XEN) ENABLING IO-APIC IRQs
(XEN)  -> Using new ACK method
(XEN) ..TIMER: vector=3D0xF0 apic1=3D0 pin1=3D2 apic2=3D-1 pin2=3D-1
(XEN) TSC is reliable, synchronization unnecessary
(XEN) Platform timer appears to have unexpectedly wrapped 1 times.
(XEN) Platform timer is 14.318MHz HPET
=FF(XEN) Allocated console ring of 32 KiB.
(XEN) microcode.c:73:d32767 microcode: CPU1 resumed
(XEN) microcode.c:73:d32767 microcode: CPU2 resumed
(XEN) Brought up 4 CPUs
(XEN) microcode.c:73:d32767 microcode: CPU3 resumed
(XEN) Turbo Mode detected!
(XEN) HPET: 8 timers in total, 8 timers will be used for broadcast
(XEN) ACPI sleep modes: S3
(XEN) mcheck_poll: Machine check polling timer started.
(XEN) *** LOADING DOMAIN 0 ***
(XEN)  Xen  kernel: 64-bit, lsb, compat32
(XEN)  Dom0 kernel: 64-bit, PAE, lsb, paddr 0x1000000 -> 0x1bfc000
(XEN) PHYSICAL MEMORY ARRANGEMENT:
(XEN)  Dom0 alloc.:   0000000450000000->0000000454000000 (245760 pages
to be allocated)
(XEN) VIRTUAL MEMORY ARRANGEMENT:
(XEN)  Loaded kernel: ffffffff81000000->ffffffff81bfc000
(XEN)  Init. ramdisk: ffffffff81bfc000->ffffffff820c8600
(XEN)  Phys-Mach map: ffffffff820c9000->ffffffff822c9000
(XEN)  Start info:    ffffffff822c9000->ffffffff822c94b4
(XEN)  Page tables:   ffffffff822ca000->ffffffff822df000
(XEN)  Boot stack:    ffffffff822df000->ffffffff822e0000
(XEN)  TOTAL:         ffffffff80000000->ffffffff82400000
(XEN)  ENTRY ADDRESS: ffffffff81976200
(XEN) Dom0 has maximum 4 VCPUs
(XEN) Scrubbing Free RAM:
...........................................................................=
...........................................................................=
..done.
(XEN) trace.c:89:d32767 calc_tinfo_first_offset: NR_CPUs 128,
offset_in_bytes 258, t_info_first_offset 65
(XEN) Xen trace buffers: disabled
(XEN) Std. Loglevel: All
(XEN) Guest Loglevel: All
(XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch
input to Xen)
(XEN) Freed 176kB init memory.
mapping kernel into physical memory
Xen: setup ISA identity maps
about to get started...
[    0.000000] Initializing cgroup subsys cpuset
[    0.000000] Initializing cgroup subsys cpu
[    0.000000] Linux version 2.6.32.46 (root@xenhost-rack2) (gcc
version 4.4.5 (Debian 4.4.5-8) ) #1 SMP Wed Oct 12 16:48:53 CEST 2011
[    0.000000] Command line:
root=3DUUID=3D5563bc26-6e98-4768-abee-5ca053e2795c ro nomodeset
max_loop=3D255 console=3Dhvc0 earlyprintk=3Dxen
[    0.000000] KERNEL supported cpus:
[    0.000000]   Intel GenuineIntel
[    0.000000]   AMD AuthenticAMD
[    0.000000]   Centaur CentaurHauls
[    0.000000] released 0 pages of unused memory
[    0.000000] BIOS-provided physical RAM map:
[    0.000000]  Xen: 0000000000000000 - 000000000009b000 (usable)
[    0.000000]  Xen: 000000000009b800 - 0000000000100000 (reserved)
[    0.000000]  Xen: 0000000000100000 - 0000000040000000 (usable)
[    0.000000]  Xen: 0000000040000000 - 000000009dade000 (unusable)
[    0.000000]  Xen: 000000009dade000 - 000000009dbb0000 (ACPI NVS)
[    0.000000]  Xen: 000000009dbb0000 - 000000009f6a4000 (ACPI data)
[    0.000000]  Xen: 000000009f6a4000 - 000000009f6df000 (reserved)
[    0.000000]  Xen: 000000009f6df000 - 000000009f78a000 (ACPI data)
[    0.000000]  Xen: 000000009f78a000 - 000000009f7df000 (ACPI NVS)
[    0.000000]  Xen: 000000009f7df000 - 000000009f800000 (ACPI data)
[    0.000000]  Xen: 000000009f800000 - 00000000b0000000 (reserved)
[    0.000000]  Xen: 00000000fec00000 - 00000000fec01000 (reserved)
[    0.000000]  Xen: 00000000fed1c000 - 00000000fed20000 (reserved)
[    0.000000]  Xen: 00000000fee00000 - 00000000fee01000 (reserved)
[    0.000000]  Xen: 00000000ff800000 - 0000000100000000 (reserved)
[    0.000000]  Xen: 0000000100000000 - 0000000340000000 (usable)
[    0.000000] bootconsole [xenboot0] enabled
[    0.000000] DMI 2.5 present.
[    0.000000] last_pfn =3D 0x340000 max_arch_pfn =3D 0x400000000
[    0.000000] x86 PAT enabled: cpu 0, old 0x50100070406, new 0x70106000701=
06
[    0.000000] last_pfn =3D 0x40000 max_arch_pfn =3D 0x400000000
[    0.000000] Scanning 1 areas for low memory corruption
[    0.000000] modified physical RAM map:
[    0.000000]  modified: 0000000000000000 - 0000000000001000 (usable)
[    0.000000]  modified: 0000000000001000 - 0000000000006000 (reserved)
[    0.000000]  modified: 0000000000006000 - 000000000009b000 (usable)
[    0.000000]  modified: 000000000009b800 - 0000000000100000 (reserved)
[    0.000000]  modified: 0000000000100000 - 0000000040000000 (usable)
[    0.000000]  modified: 0000000040000000 - 000000009dade000 (unusable)
[    0.000000]  modified: 000000009dade000 - 000000009dbb0000 (ACPI NVS)
[    0.000000]  modified: 000000009dbb0000 - 000000009f6a4000 (ACPI data)
[    0.000000]  modified: 000000009f6a4000 - 000000009f6df000 (reserved)
[    0.000000]  modified: 000000009f6df000 - 000000009f78a000 (ACPI data)
[    0.000000]  modified: 000000009f78a000 - 000000009f7df000 (ACPI NVS)
[    0.000000]  modified: 000000009f7df000 - 000000009f800000 (ACPI data)
[    0.000000]  modified: 000000009f800000 - 00000000b0000000 (reserved)
[    0.000000]  modified: 00000000fec00000 - 00000000fec01000 (reserved)
[    0.000000]  modified: 00000000fed1c000 - 00000000fed20000 (reserved)
[    0.000000]  modified: 00000000fee00000 - 00000000fee01000 (reserved)
[    0.000000]  modified: 00000000ff800000 - 0000000100000000 (reserved)
[    0.000000]  modified: 0000000100000000 - 0000000340000000 (usable)
[    0.000000] init_memory_mapping: 0000000000000000-0000000040000000
[    0.000000] init_memory_mapping: 0000000100000000-0000000340000000
[    0.000000] RAMDISK: 01bfc000 - 020c8600
[    0.000000] ACPI: RSDP 00000000000f0410 00024 (v02 INTEL )
[    0.000000] ACPI: XSDT 000000009f7fd120 0008C (v01 INTEL  S3420GPC
00000000      01000013)
[    0.000000] ACPI: FACP 000000009f7fb000 000F4 (v04 INTEL  S3420GPC
00000000 MSFT 0100000D)
[    0.000000] ACPI: DSDT 000000009f7f6000 04E22 (v02 INTEL  S3420GPC
00000003 MSFT 0100000D)
[    0.000000] ACPI: FACS 000000009f78a000 00040
[    0.000000] ACPI: APIC 000000009f7f5000 000BC (v02 INTEL  S3420GPC
00000000 MSFT 0100000D)
[    0.000000] ACPI: MCFG 000000009f7f4000 0003C (v01 INTEL  S3420GPC
00000001 MSFT 0100000D)
[    0.000000] ACPI: HPET 000000009f7f3000 00038 (v01 INTEL  S3420GPC
00000001 MSFT 0100000D)
[    0.000000] ACPI: SLIT 000000009f7f2000 00030 (v01 INTEL  S3420GPC
00000001 MSFT 0100000D)
[    0.000000] ACPI: SPCR 000000009f7f1000 00050 (v01 INTEL  S3420GPC
00000000 MSFT 0100000D)
[    0.000000] ACPI: WDDT 000000009f7f0000 00040 (v01 INTEL  S3420GPC
00000000 MSFT 0100000D)
[    0.000000] ACPI: SSDT 000000009f7e5000 0AEF4 (v02  INTEL SSDT  PM
00004000 INTL 20061109)
[    0.000000] ACPI: SSDT 000000009f7e4000 001D8 (v02  INTEL IPMI
00004000 INTL 20061109)
[    0.000000] ACPI: HEST 000000009f7e3000 000A8 (v01 INTEL  S3420GPC
00000001 INTL 00000001)
[    0.000000] ACPI: BERT 000000009f7e2000 00030 (v01 INTEL  S3420GPC
00000001 INTL 00000001)
[    0.000000] ACPI: ERST 000000009f7e1000 00230 (v01 INTEL  S3420GPC
00000001 INTL 00000001)
[    0.000000] ACPI: EINJ 000000009f7e0000 00130 (v01 INTEL  S3420GPC
00000001 INTL 00000001)
[    0.000000] (10 early reservations) =3D=3D> bootmem [0000000000 - 034000=
0000]
[    0.000000]   #0 [0000000000 - 0000001000]   BIOS data page =3D=3D>
[0000000000 - 0000001000]
[    0.000000]   #1 [00022ca000 - 00022df000]   XEN PAGETABLES =3D=3D>
[00022ca000 - 00022df000]
[    0.000000]   #2 [0000006000 - 0000008000]       TRAMPOLINE =3D=3D>
[0000006000 - 0000008000]
[    0.000000]   #3 [0001000000 - 0001ad1474]    TEXT DATA BSS =3D=3D>
[0001000000 - 0001ad1474]
[    0.000000]   #4 [0001bfc000 - 00020c8600]          RAMDISK =3D=3D>
[0001bfc000 - 00020c8600]
[    0.000000]   #5 [00020c9000 - 00022ca000]   XEN START INFO =3D=3D>
[00020c9000 - 00022ca000]
[    0.000000]   #6 [0100000000 - 0340000000]        XEN EXTRA =3D=3D>
[0100000000 - 0340000000]
[    0.000000]   #7 [0001ad2000 - 0001ade36c]              BRK =3D=3D>
[0001ad2000 - 0001ade36c]
[    0.000000]   #8 [0000100000 - 00002ea000]          PGTABLE =3D=3D>
[0000100000 - 00002ea000]
[    0.000000]   #9 [00022df000 - 00034e8000]          PGTABLE =3D=3D>
[00022df000 - 00034e8000]
[    0.000000] found SMP MP-table at [ffff8800000fd9a0] fd9a0
[    0.000000] Zone PFN ranges:
[    0.000000]   DMA      0x00000000 -> 0x00001000
[    0.000000]   DMA32    0x00001000 -> 0x00100000
[    0.000000]   Normal   0x00100000 -> 0x00340000
[    0.000000] Movable zone start PFN for each node
[    0.000000] early_node_map[4] active PFN ranges
[    0.000000]     0: 0x00000000 -> 0x00000001
[    0.000000]     0: 0x00000006 -> 0x0000009b
[    0.000000]     0: 0x00000100 -> 0x00040000
[    0.000000]     0: 0x00100000 -> 0x00340000
[    0.000000] ACPI: PM-Timer IO Port: 0x408
[    0.000000] ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x02] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x04] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x03] lapic_id[0x06] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x04] lapic_id[0x01] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x05] lapic_id[0x03] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x06] lapic_id[0x05] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x07] lapic_id[0x07] disabled)
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x00] high level lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x01] high level lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x02] high level lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x03] high level lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x04] high level lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x05] high level lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x06] high level lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x07] high level lint[0x1])
[    0.000000] ACPI: IOAPIC (id[0x08] address[0xfec00000] gsi_base[0])
[    0.000000] IOAPIC[0]: apic_id 8, version 0, address 0xfec00000, GSI 0-0
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
[    0.000000] ERROR: Unable to locate IOAPIC for GSI 2
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
[    0.000000] ERROR: Unable to locate IOAPIC for GSI 9
[    0.000000] Using ACPI (MADT) for SMP configuration information
[    0.000000] ACPI: HPET id: 0x8086a801 base: 0xfed00000
[    0.000000] SMP: Allowing 4 CPUs, 0 hotplug CPUs
[    0.000000] PM: Registered nosave memory: 0000000000001000 - 00000000000=
06000
[    0.000000] PM: Registered nosave memory: 000000000009b000 - 00000000000=
9c000
[    0.000000] PM: Registered nosave memory: 000000000009c000 - 00000000001=
00000
[    0.000000] PM: Registered nosave memory: 0000000040000000 - 000000009da=
de000
[    0.000000] PM: Registered nosave memory: 000000009dade000 - 000000009db=
b0000
[    0.000000] PM: Registered nosave memory: 000000009dbb0000 - 000000009f6=
a4000
[    0.000000] PM: Registered nosave memory: 000000009f6a4000 - 000000009f6=
df000
[    0.000000] PM: Registered nosave memory: 000000009f6df000 - 000000009f7=
8a000
[    0.000000] PM: Registered nosave memory: 000000009f78a000 - 000000009f7=
df000
[    0.000000] PM: Registered nosave memory: 000000009f7df000 - 000000009f8=
00000
[    0.000000] PM: Registered nosave memory: 000000009f800000 - 00000000b00=
00000
[    0.000000] PM: Registered nosave memory: 00000000b0000000 - 00000000fec=
00000
[    0.000000] PM: Registered nosave memory: 00000000fec00000 - 00000000fec=
01000
[    0.000000] PM: Registered nosave memory: 00000000fec01000 - 00000000fed=
1c000
[    0.000000] PM: Registered nosave memory: 00000000fed1c000 - 00000000fed=
20000
[    0.000000] PM: Registered nosave memory: 00000000fed20000 - 00000000fee=
00000
[    0.000000] PM: Registered nosave memory: 00000000fee00000 - 00000000fee=
01000
[    0.000000] PM: Registered nosave memory: 00000000fee01000 - 00000000ff8=
00000
[    0.000000] PM: Registered nosave memory: 00000000ff800000 - 00000001000=
00000
[    0.000000] Allocating PCI resources starting at b0000000 (gap:
b0000000:4ec00000)
[    0.000000] Booting paravirtualized kernel on Xen
[    0.000000] Xen version: 4.0.1 (preserve-AD) (dom0)
[    0.000000] NR_CPUS:8 nr_cpumask_bits:8 nr_cpu_ids:4 nr_node_ids:1
[    0.000000] PERCPU: Embedded 29 pages/cpu @ffff880028038000 s88536
r8192 d22056 u118784
[    0.000000] pcpu-alloc: s88536 r8192 d22056 u118784 alloc=3D29*4096
[    0.000000] pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3
[    2.710494] Built 1 zonelists in Zone order, mobility grouping on.
Total pages: 2574249
[    2.710498] Kernel command line:
root=3DUUID=3D5563bc26-6e98-4768-abee-5ca053e2795c ro nomodeset
max_loop=3D255 console=3Dhvc0 earlyprintk=3Dxen
[    2.710547] PID hash table entries: 4096 (order: 3, 32768 bytes)
[    2.712182] Dentry cache hash table entries: 2097152 (order: 12,
16777216 bytes)
[    2.716022] Inode-cache hash table entries: 1048576 (order: 11,
8388608 bytes)
[    2.717879] Initializing CPU#0
[    2.724732] DMA: Placing 64MB software IO TLB between
ffff880020000000 - ffff880024000000
[    2.724738] DMA: software IO TLB at phys 0x20000000 - 0x24000000
[    2.724741] xen_swiotlb_fixup: buf=3Dffff880020000000 size=3D67108864
[    2.742551] xen_swiotlb_fixup: buf=3Dffff880024060000 size=3D32768
[    2.745990] Memory: 774160k/13631488k available (5876k kernel code,
3146152k absent, 9710444k reserved, 3718k data, 568k init)
[    2.746017] SLUB: Genslabs=3D13, HWalign=3D64, Order=3D0-3, MinObjects=
=3D0,
CPUs=3D4, Nodes=3D1
[    2.746036] Hierarchical RCU implementation.
[    2.746041] NR_IRQS:4352 nr_irqs:1280
[    2.746192] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
[    2.746196] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
[    2.746200] xen: sci override: source_irq=3D9 global_irq=3D9 trigger=3Dc=
 polarity=3D1
[    2.746205] xen_allocate_pirq: returning irq 9 for gsi 9
[    2.746213] xen: acpi sci 9
[    2.757067] Console: colour VGA+ 80x25
[    2.757072] console [hvc0] enabled, bootconsole disabled
[    2.757072] console [hvc0] enabled, bootconsole disabled
[    2.757090] installing Xen timer for CPU 0
[    2.757119] Detected 2400.056 MHz processor.
[    2.757126] Calibrating delay loop (skipped), value calculated
using timer frequency.. 4800.11 BogoMIPS (lpj=3D2400056)
[    2.757143] Security Framework initialized
[    2.757148] SELinux:  Initializing.
[    2.757162] Mount-cache hash table entries: 256
[    2.757288] Initializing cgroup subsys ns
[    2.757294] Initializing cgroup subsys cpuacct
[    2.757299] Initializing cgroup subsys freezer
[    2.757332] CPU: L1 I cache: 32K, L1 D cache: 32K
[    2.757336] CPU: L2 cache: 256K
[    2.757339] CPU: L3 cache: 8192K
[    2.757343] CPU: Unsupported number of siblings 16
[    2.757348] mce: CPU supports 9 MCE banks
[    2.757371] Performance Events: unsupported p6 CPU model 30 no PMU
driver, software events only.
[    2.757387] SMP alternatives: switching to UP code
[    2.794584] ACPI: Core revision 20090903
[    2.815504] installing Xen timer for CPU 1
[    2.815533] SMP alternatives: switching to SMP code
[    2.851777] Initializing CPU#1
[    2.851813] CPU: L1 I cache: 32K, L1 D cache: 32K
[    2.851815] CPU: L2 cache: 256K
[    2.851816] CPU: L3 cache: 8192K
[    2.851820] CPU: Unsupported number of siblings 16
[    2.851896] installing Xen timer for CPU 2
[    2.851961] Initializing CPU#2
[    2.851995] CPU: L1 I cache: 32K, L1 D cache: 32K
[    2.851997] CPU: L2 cache: 256K
[    2.851998] CPU: L3 cache: 8192K
[    2.852002] CPU: Unsupported number of siblings 16
[    2.852070] installing Xen timer for CPU 3
[    2.852132] Initializing CPU#3
[    2.852165] CPU: L1 I cache: 32K, L1 D cache: 32K
[    2.852168] CPU: L2 cache: 256K
[    2.852169] CPU: L3 cache: 8192K
[    2.852173] CPU: Unsupported number of siblings 16
[    2.852205] Brought up 4 CPUs
[    2.853032] Grant table initialized
[    2.853065] Time: 16:22:10  Date: 12/02/11
[    2.853112] NET: Registered protocol family 16
[    2.853696] ACPI FADT declares the system doesn't support PCIe
ASPM, so disable it
[    2.853701] ACPI: bus type pci registered
[    2.854119] PCI: MCFG configuration 0: base a0000000 segment 0 buses 0 -=
 255
[    2.854124] PCI: MCFG area at a0000000 reserved in E820
[    2.878058] PCI: Using MMCONFIG at a0000000 - afffffff
[    2.878063] PCI: Using configuration type 1 for base access
[    2.890548] bio: create slab <bio-0> at 0
[    2.891518] ERROR: Unable to locate IOAPIC for GSI 9
[    2.893192] ACPI Error: Field [CPB3] at 96 exceeds Buffer [NULL]
size 64 (bits) (20090903/dsopcode-596)
[    2.893203] ACPI Error (psparse-0537): Method parse/execution
failed [\_SB_._OSC] (Node ffff88003fc187c0), AE_AML_BUFFER_LIMIT
[    2.917957] ACPI: Interpreter enabled
[    2.917962] ACPI: (supports S0 S1 S5)
[    2.917987] ACPI: Using IOAPIC for interrupt routing
[    2.931854] ACPI: No dock devices found.
[    2.932646] ACPI: PCI Root Bridge [PCI0] (0000:00)
[    2.932931] pci 0000:00:05.0: PME# supported from D0 D3hot D3cold
[    2.932939] pci 0000:00:05.0: PME# disabled
[    2.933685] pci 0000:00:19.0: PME# supported from D0 D3hot D3cold
[    2.933692] pci 0000:00:19.0: PME# disabled
[    2.933874] pci 0000:00:1a.0: PME# supported from D0 D3hot D3cold
[    2.933882] pci 0000:00:1a.0: PME# disabled
[    2.934001] pci 0000:00:1c.0: PME# supported from D0 D3hot D3cold
[    2.934008] pci 0000:00:1c.0: PME# disabled
[    2.934131] pci 0000:00:1c.4: PME# supported from D0 D3hot D3cold
[    2.934138] pci 0000:00:1c.4: PME# disabled
[    2.934257] pci 0000:00:1c.6: PME# supported from D0 D3hot D3cold
[    2.934264] pci 0000:00:1c.6: PME# disabled
[    2.934381] pci 0000:00:1c.7: PME# supported from D0 D3hot D3cold
[    2.934389] pci 0000:00:1c.7: PME# disabled
[    2.934635] pci 0000:00:1d.0: PME# supported from D0 D3hot D3cold
[    2.934643] pci 0000:00:1d.0: PME# disabled
[    2.935817] pci 0000:03:00.0: PME# supported from D0 D3hot D3cold
[    2.935827] pci 0000:03:00.0: PME# disabled
[    2.936372] pci 0000:00:1e.0: transparent bridge
(XEN) PCI add device 00:00.0
(XEN) PCI add device 00:05.0
(XEN) PCI add device 00:08.0
(XEN) PCI add device 00:08.1
(XEN) PCI add device 00:08.2
(XEN) PCI add device 00:08.3
(XEN) PCI add device 00:10.0
(XEN) PCI add device 00:10.1
(XEN) PCI add device 00:19.0
(XEN) PCI add device 00:1a.0
(XEN) PCI add device 00:1c.0
(XEN) PCI add device 00:1c.4
(XEN) PCI add device 00:1c.6
(XEN) PCI add device 00:1c.7
(XEN) PCI add device 00:1d.0
(XEN) PCI add device 00:1e.0
(XEN) PCI add device 00:1f.0
(XEN) PCI add device 00:1f.2
(XEN) PCI add device 00:1f.3
(XEN) PCI add device 00:1f.5
(XEN) PCI add device 01:00.0
(XEN) PCI add device 03:00.0
(XEN) PCI add device 04:00.0
[    2.947993] ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 9 *10
11 12 14 15)
[    2.948136] ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 9 10
*11 12 14 15)
[    2.948276] ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 *5 6 7 9 10
11 12 14 15)
[    2.948415] ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 7 9 10
*11 12 14 15)
[    2.948554] ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 7 9 10 11
12 14 15) *0, disabled.
[    2.948695] ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 6 7 *9 10
11 12 14 15)
[    2.948890] ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 6 7 *9 10
11 12 14 15)
[    2.949032] ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 6 7 9 *10
11 12 14 15)
[    2.949290] xen_balloon: Initialising balloon driver with page order 0.
[    2.949389] last_pfn =3D 0x340000 max_arch_pfn =3D 0x __  __
_  _    ___   _


then it hangs

xend-config.sxp relevant directives:

(xend-relocation-server yes)
(dom0-min-mem 1024)
(enable-dom0-ballooning no)
(dom0-cpus 0)

grub:
title           Xen 4.0.1 / Debian GNU/Linux, kernel 2.6.32.47
root            (hd0,0)
kernel          /boot/xen-4.0.1.gz dom0_mem=3D1024M max_cstate=3D1
module          /boot/vmlinuz-2.6.32.47
root=3DUUID=3D5563bc26-6e98-4768-abee-5ca053e2795c ro nomodeset
max_loop=3D255
module          /boot/initrd.img-2.6.32.47


Thanks for your help

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

From xen-devel-bounces@lists.xensource.com Fri Dec 02 18:33:56 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 18:33:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWXvS-0002ET-NK; Fri, 02 Dec 2011 18:33:34 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <alex@alex.org.uk>) id 1RWXvR-0002Dl-EH
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 18:33:33 +0000
X-Env-Sender: alex@alex.org.uk
X-Msg-Ref: server-12.tower-216.messagelabs.com!1322850772!5981500!1
X-Originating-IP: [89.16.176.221]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9649 invoked from network); 2 Dec 2011 18:32:52 -0000
Received: from mail.avalus.com (HELO mail.avalus.com) (89.16.176.221)
	by server-12.tower-216.messagelabs.com with SMTP;
	2 Dec 2011 18:32:52 -0000
Received: from [192.168.100.15] (87-194-71-186.bethere.co.uk [87.194.71.186])
	by mail.avalus.com (Postfix) with ESMTPSA id E82F4C56116;
	Fri,  2 Dec 2011 18:32:49 +0000 (GMT)
Date: Fri, 02 Dec 2011 18:32:49 +0000
From: Alex Bligh <alex@alex.org.uk>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <12E319EEAA44FEB965D8F001@Ximines.local>
In-Reply-To: <1322847755.7376.45.camel@dagon.hellion.org.uk>
References: <4ED798B2.1040309@canonical.com>	
	<20111201180944.GH12984@reaktio.net>	<4ED8A45A.3050403@canonical.com>	
	<20111202104110.GL12984@reaktio.net>	
	<BA1B675D85BDD87795D1666C@Ximines.local>	
	<1322844048.29870.155.camel@zakaz.uk.xensource.com>	
	<8D88C4D6C31A598129A942AD@Ximines.local>
	<1322847755.7376.45.camel@dagon.hellion.org.uk>
X-Mailer: Mulberry/4.0.8 (Mac OS X)
MIME-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com, Alex Bligh <alex@alex.org.uk>,
	Stefan Bader <stefan.bader@canonical.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Xen 4.x / Linux 3.x (dom0 and HVM domU) and	NIC
 handling
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Alex Bligh <alex@alex.org.uk>
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian,

--On 2 December 2011 17:42:35 +0000 Ian Campbell <Ian.Campbell@citrix.com> 
wrote:

> Right.
>
>> FWIW my experience is that various built-for-cloud type distros don't use
>> that scheme, mainly because they use grub1 which IIRC does not support
>> this, and building images in a non-root environment that have grub1
>> in is rather easier than grub2.
>
> UUID= and LABEL= are functions of your initrd (actually udev) and not
> the bootloader. They work with both grub1 and grub2.

I /think/ we might be slightly at cross purposes.

At least when I was busy making images for Xen for PVHVM a couple of
years ago, the problem is roughly as follows:

The boot loader needs to know what device to load the kernel and initrd 
from. To do this (roughly speaking) it needs to know what BIOS device to 
use. Of course it does not matter whether the boot loader uses the PV 
device or the emulated device, save that this requires the emulated device 
be present (at least whilst the boot loader doesn't support drivers for the 
pv device). The problem is that the device the boot loader accesses is in 
general specified in the boot loader configuration file not as a bios 
device number, but as a device name. Equally, it needs to know the device 
so that it can write the boot sector in order to reinstall the boot loader, 
set options etc. The problem we ran into here was that this needs to be set 
to xvda in order to to write the boot sector etc., because the sda device 
is unplugged. However, it only recognised a BIOS mapping for sda. So 
neither worked, without fiddling with mappings, but that wasn't possible on 
a straight install. For some reason, grub1 was far more forgiving.

>> So, for instance, all the vm-builder stuff in debian/ubuntu used grub1
>> and did not work this way.
>
> Which ones are these?

EG:
 http://packages.ubuntu.com/search?keywords=ubuntu-vm-builder
 http://wiki.debian.org/VMBuilder

> The Debian installer uses UUID where it can AFAIK. Ubuntu's installer is
> derived from Debian's so I'd expect it to be the same.

There is more than one method of generating debian/ubuntu images
(debootstrap, multistrap, vmbuilder to name but 3). Some of these
run an installer, some just generate a working image for a particular
environment (and it's the latter which are problematic).

FWIW my understanding is that though Ubuntu and Debian's installers both 
use the same underlying d-i stuff (or used to), they are now reasonably 
different (not that this has much bearing on the argument, as the main 
difference between the two is the kernel which has led to rather different 
results between the two); certainly which boot loader they use is
independent of the install architecture, their partitioning schemes
have been substantially different, and I would expect use of UUID/LABEL
not necessarily to correspond.

-- 
Alex Bligh

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

From xen-devel-bounces@lists.xensource.com Fri Dec 02 18:33:56 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 18:33:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWXvS-0002ET-NK; Fri, 02 Dec 2011 18:33:34 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <alex@alex.org.uk>) id 1RWXvR-0002Dl-EH
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 18:33:33 +0000
X-Env-Sender: alex@alex.org.uk
X-Msg-Ref: server-12.tower-216.messagelabs.com!1322850772!5981500!1
X-Originating-IP: [89.16.176.221]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9649 invoked from network); 2 Dec 2011 18:32:52 -0000
Received: from mail.avalus.com (HELO mail.avalus.com) (89.16.176.221)
	by server-12.tower-216.messagelabs.com with SMTP;
	2 Dec 2011 18:32:52 -0000
Received: from [192.168.100.15] (87-194-71-186.bethere.co.uk [87.194.71.186])
	by mail.avalus.com (Postfix) with ESMTPSA id E82F4C56116;
	Fri,  2 Dec 2011 18:32:49 +0000 (GMT)
Date: Fri, 02 Dec 2011 18:32:49 +0000
From: Alex Bligh <alex@alex.org.uk>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <12E319EEAA44FEB965D8F001@Ximines.local>
In-Reply-To: <1322847755.7376.45.camel@dagon.hellion.org.uk>
References: <4ED798B2.1040309@canonical.com>	
	<20111201180944.GH12984@reaktio.net>	<4ED8A45A.3050403@canonical.com>	
	<20111202104110.GL12984@reaktio.net>	
	<BA1B675D85BDD87795D1666C@Ximines.local>	
	<1322844048.29870.155.camel@zakaz.uk.xensource.com>	
	<8D88C4D6C31A598129A942AD@Ximines.local>
	<1322847755.7376.45.camel@dagon.hellion.org.uk>
X-Mailer: Mulberry/4.0.8 (Mac OS X)
MIME-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com, Alex Bligh <alex@alex.org.uk>,
	Stefan Bader <stefan.bader@canonical.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Xen 4.x / Linux 3.x (dom0 and HVM domU) and	NIC
 handling
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Alex Bligh <alex@alex.org.uk>
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian,

--On 2 December 2011 17:42:35 +0000 Ian Campbell <Ian.Campbell@citrix.com> 
wrote:

> Right.
>
>> FWIW my experience is that various built-for-cloud type distros don't use
>> that scheme, mainly because they use grub1 which IIRC does not support
>> this, and building images in a non-root environment that have grub1
>> in is rather easier than grub2.
>
> UUID= and LABEL= are functions of your initrd (actually udev) and not
> the bootloader. They work with both grub1 and grub2.

I /think/ we might be slightly at cross purposes.

At least when I was busy making images for Xen for PVHVM a couple of
years ago, the problem is roughly as follows:

The boot loader needs to know what device to load the kernel and initrd 
from. To do this (roughly speaking) it needs to know what BIOS device to 
use. Of course it does not matter whether the boot loader uses the PV 
device or the emulated device, save that this requires the emulated device 
be present (at least whilst the boot loader doesn't support drivers for the 
pv device). The problem is that the device the boot loader accesses is in 
general specified in the boot loader configuration file not as a bios 
device number, but as a device name. Equally, it needs to know the device 
so that it can write the boot sector in order to reinstall the boot loader, 
set options etc. The problem we ran into here was that this needs to be set 
to xvda in order to to write the boot sector etc., because the sda device 
is unplugged. However, it only recognised a BIOS mapping for sda. So 
neither worked, without fiddling with mappings, but that wasn't possible on 
a straight install. For some reason, grub1 was far more forgiving.

>> So, for instance, all the vm-builder stuff in debian/ubuntu used grub1
>> and did not work this way.
>
> Which ones are these?

EG:
 http://packages.ubuntu.com/search?keywords=ubuntu-vm-builder
 http://wiki.debian.org/VMBuilder

> The Debian installer uses UUID where it can AFAIK. Ubuntu's installer is
> derived from Debian's so I'd expect it to be the same.

There is more than one method of generating debian/ubuntu images
(debootstrap, multistrap, vmbuilder to name but 3). Some of these
run an installer, some just generate a working image for a particular
environment (and it's the latter which are problematic).

FWIW my understanding is that though Ubuntu and Debian's installers both 
use the same underlying d-i stuff (or used to), they are now reasonably 
different (not that this has much bearing on the argument, as the main 
difference between the two is the kernel which has led to rather different 
results between the two); certainly which boot loader they use is
independent of the install architecture, their partitioning schemes
have been substantially different, and I would expect use of UUID/LABEL
not necessarily to correspond.

-- 
Alex Bligh

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

From xen-devel-bounces@lists.xensource.com Fri Dec 02 18:48:42 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 18: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.xensource.com>)
	id 1RWY9b-0002ax-5w; Fri, 02 Dec 2011 18:48:11 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1RWY9Z-0002as-1f
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 18:48:09 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-2.tower-27.messagelabs.com!1322851604!55820716!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25026 invoked from network); 2 Dec 2011 18:46:45 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-2.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 2 Dec 2011 18:46:45 -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
	pB2IlRVl014681
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Fri, 2 Dec 2011 13:47:27 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pB2IlRHi014679;
	Fri, 2 Dec 2011 13:47:27 -0500
Date: Fri, 2 Dec 2011 14:47:27 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Quartexx <quartex73@gmail.com>
Message-ID: <20111202184727.GA14449@andromeda.dapyr.net>
References: <CAMhBqqiLc1994GUKtA7UY52pR29nktmFy+XiwTwpZb_E+fwFRQ@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAMhBqqiLc1994GUKtA7UY52pR29nktmFy+XiwTwpZb_E+fwFRQ@mail.gmail.com>
User-Agent: Mutt/1.5.9i
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] xen 4.0.1 w/2.6.32.47 hangs at boot
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Dec 02, 2011 at 07:32:15PM +0100, Quartexx wrote:
> Hi,
> xen 4.0.1 (issue with 4.0.3 too)
> kernel 2.6.32.47 (it happens with 2.6.32.46 too)
> 
> system hangs at boot (it doesnt' happen always, usually at poweron
> it'sok, then after two or three reboot it happens)

Please take a look at the PVOPS Wiki - especially the "Help! I am
having troubles section"
http://wiki.xen.org/xenwiki/XenParavirtOps

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

From xen-devel-bounces@lists.xensource.com Fri Dec 02 18:48:42 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 18: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.xensource.com>)
	id 1RWY9b-0002ax-5w; Fri, 02 Dec 2011 18:48:11 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1RWY9Z-0002as-1f
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 18:48:09 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-2.tower-27.messagelabs.com!1322851604!55820716!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25026 invoked from network); 2 Dec 2011 18:46:45 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-2.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 2 Dec 2011 18:46:45 -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
	pB2IlRVl014681
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Fri, 2 Dec 2011 13:47:27 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pB2IlRHi014679;
	Fri, 2 Dec 2011 13:47:27 -0500
Date: Fri, 2 Dec 2011 14:47:27 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Quartexx <quartex73@gmail.com>
Message-ID: <20111202184727.GA14449@andromeda.dapyr.net>
References: <CAMhBqqiLc1994GUKtA7UY52pR29nktmFy+XiwTwpZb_E+fwFRQ@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAMhBqqiLc1994GUKtA7UY52pR29nktmFy+XiwTwpZb_E+fwFRQ@mail.gmail.com>
User-Agent: Mutt/1.5.9i
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] xen 4.0.1 w/2.6.32.47 hangs at boot
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Dec 02, 2011 at 07:32:15PM +0100, Quartexx wrote:
> Hi,
> xen 4.0.1 (issue with 4.0.3 too)
> kernel 2.6.32.47 (it happens with 2.6.32.46 too)
> 
> system hangs at boot (it doesnt' happen always, usually at poweron
> it'sok, then after two or three reboot it happens)

Please take a look at the PVOPS Wiki - especially the "Help! I am
having troubles section"
http://wiki.xen.org/xenwiki/XenParavirtOps

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

From xen-devel-bounces@lists.xensource.com Fri Dec 02 19:24:15 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 19:24:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWYhr-0002t0-9c; Fri, 02 Dec 2011 19:23:35 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <quartex73@gmail.com>) id 1RWYhp-0002sv-3q
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 19:23:33 +0000
X-Env-Sender: quartex73@gmail.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1322853731!45227328!1
X-Originating-IP: [209.85.213.171]
X-SpamReason: No, hits=1.0 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,UPPERCASE_50_75,spamassassin: 
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7471 invoked from network); 2 Dec 2011 19:22:12 -0000
Received: from mail-yx0-f171.google.com (HELO mail-yx0-f171.google.com)
	(209.85.213.171)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Dec 2011 19:22:12 -0000
Received: by yenr9 with SMTP id r9so31546431yen.30
	for <xen-devel@lists.xensource.com>;
	Fri, 02 Dec 2011 11:22:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:content-type; bh=RXNxx1PvvwnAfefquqmNx1XFfkd44871k5B5/yYWNEg=;
	b=ga5j0DLFosYLDK7Nb405pm62KELlVzEoxdyAkdHr/77Nq5KK/J8DbQye6MTuLUOnZm
	+sei2jmQ7jrO2WQC2rl2eqB5UB6t1tGT6MXVX92M5x6CScbXXsy7VtYyzq/68S/EVskS
	bmR8QBvka8h7gwKXwlYj2PFAClGrXBbGK86Fw=
MIME-Version: 1.0
Received: by 10.236.190.40 with SMTP id d28mr21366128yhn.92.1322853767052;
	Fri, 02 Dec 2011 11:22:47 -0800 (PST)
Received: by 10.147.146.14 with HTTP; Fri, 2 Dec 2011 11:22:46 -0800 (PST)
In-Reply-To: <CAMhBqqiLc1994GUKtA7UY52pR29nktmFy+XiwTwpZb_E+fwFRQ@mail.gmail.com>
References: <CAMhBqqiLc1994GUKtA7UY52pR29nktmFy+XiwTwpZb_E+fwFRQ@mail.gmail.com>
Date: Fri, 2 Dec 2011 20:22:46 +0100
Message-ID: <CAMhBqqgu6v8NB-X0dNdfrzd12=Y2i==fYCCC2Z+MkDupqqKAOg@mail.gmail.com>
From: Quartexx <quartex73@gmail.com>
To: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] xen 4.0.1 w/2.6.32.47 hangs at boot
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

### lspci

00:00.0 Host bridge: Intel Corporation Core Processor DMI (rev 11)
	Subsystem: Intel Corporation Device 0000
	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-
	Capabilities: [40] #00 [0000]

00:05.0 PCI bridge: Intel Corporation Core Processor PCI Express Root
Port 3 (rev 11) (prog-if 00 [Normal decode])
	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
	Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
	I/O behind bridge: 00002000-00002fff
	Memory behind bridge: b3a00000-b3afffff
	Prefetchable memory behind bridge: 00000000b0000000-00000000b1ffffff
	Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- <SERR- <PERR-
	BridgeCtl: Parity+ SERR+ NoISA- VGA- MAbort- >Reset- FastB2B-
		PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
	Capabilities: [40] Subsystem: Intel Corporation Device 0000
	Capabilities: [60] MSI: Enable+ Count=1/2 Maskable+ 64bit-
		Address: fee0100c  Data: 4139
		Masking: 00000002  Pending: 00000000
	Capabilities: [90] Express (v2) Root Port (Slot+), MSI 00
		DevCap:	MaxPayload 256 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us
			ExtTag+ RBE+ FLReset-
		DevCtl:	Report errors: Correctable+ Non-Fatal+ Fatal+ Unsupported+
			RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
			MaxPayload 128 bytes, MaxReadReq 128 bytes
		DevSta:	CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend-
		LnkCap:	Port #5, Speed 5GT/s, Width x8, ASPM unknown, Latency L0
<512ns, L1 <4us
			ClockPM- Surprise+ LLActRep+ BwNot+
		LnkCtl:	ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk-
			ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
		LnkSta:	Speed 2.5GT/s, Width x8, TrErr- Train- SlotClk+ DLActive+
BWMgmt- ABWMgmt-
		SltCap:	AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug- Surprise-
			Slot #21, PowerLimit 0.000W; Interlock- NoCompl-
		SltCtl:	Enable: AttnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq- LinkChg-
			Control: AttnInd Off, PwrInd Off, Power- Interlock-
		SltSta:	Status: AttnBtn- PowerFlt- MRL- CmdCplt- PresDet- Interlock-
			Changed: MRL- PresDet- LinkState-
		RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna- CRSVisible-
		RootCap: CRSVisible-
		RootSta: PME ReqID 0000, PMEStatus- PMEPending-
		DevCap2: Completion Timeout: Range BCD, TimeoutDis+ ARIFwd+
		DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis- ARIFwd-
		LnkCtl2: Target Link Speed: 5GT/s, EnterCompliance- SpeedDis-,
Selectable De-emphasis: -3.5dB
			 Transmit Margin: Normal Operating Range, EnterModifiedCompliance-
ComplianceSOS-
			 Compliance De-emphasis: -6dB
		LnkSta2: Current De-emphasis Level: -6dB
	Capabilities: [e0] Power Management version 3
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
		Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
	Capabilities: [100 v1] Advanced Error Reporting
		UESta:	DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF-
MalfTLP- ECRC- UnsupReq- ACSViol-
		UEMsk:	DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF-
MalfTLP- ECRC- UnsupReq+ ACSViol-
		UESvrt:	DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+
MalfTLP+ ECRC- UnsupReq- ACSViol-
		CESta:	RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr-
		CEMsk:	RxErr+ BadTLP+ BadDLLP+ Rollover+ Timeout+ NonFatalErr+
		AERCap:	First Error Pointer: 00, GenCap- CGenEn- ChkCap- ChkEn-
	Capabilities: [150 v1] Access Control Services
		ACSCap:	SrcValid+ TransBlk+ ReqRedir+ CmpltRedir+ UpstreamFwd+
EgressCtrl- DirectTrans-
		ACSCtl:	SrcValid- TransBlk- ReqRedir- CmpltRedir- UpstreamFwd-
EgressCtrl- DirectTrans-
	Kernel driver in use: pcieport

00:08.0 System peripheral: Intel Corporation Core Processor System
Management Registers (rev 11)
	Subsystem: Device 0086:00ec
	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-
	Capabilities: [40] Express (v2) Root Complex Integrated Endpoint, MSI 00
		DevCap:	MaxPayload 128 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us
			ExtTag- RBE+ FLReset-
		DevCtl:	Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
			RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
			MaxPayload 128 bytes, MaxReadReq 128 bytes
		DevSta:	CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend-
		LnkCap:	Port #0, Speed unknown, Width x0, ASPM L0s, Latency L0
unlimited, L1 unlimited
			ClockPM- Surprise+ LLActRep+ BwNot+
		LnkCtl:	ASPM Disabled; Disabled- Retrain- CommClk-
			ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
		LnkSta:	Speed unknown, Width x0, TrErr- Train- SlotClk+ DLActive-
BWMgmt- ABWMgmt-
		DevCap2: Completion Timeout: Not Supported, TimeoutDis-
		DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-
		LnkCtl2: Target Link Speed: 2.5GT/s, EnterCompliance- SpeedDis-,
Selectable De-emphasis: -6dB
			 Transmit Margin: Normal Operating Range, EnterModifiedCompliance-
ComplianceSOS-
			 Compliance De-emphasis: -6dB
		LnkSta2: Current De-emphasis Level: -6dB
	Capabilities: [100 v0] Vendor Specific Information: ID=0000 Rev=0 Len=000 <?>

00:08.1 System peripheral: Intel Corporation Core Processor Semaphore
and Scratchpad Registers (rev 11)
	Subsystem: Device 0086:00ec
	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-
	Capabilities: [40] Express (v2) Root Complex Integrated Endpoint, MSI 00
		DevCap:	MaxPayload 128 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us
			ExtTag- RBE+ FLReset-
		DevCtl:	Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
			RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
			MaxPayload 128 bytes, MaxReadReq 128 bytes
		DevSta:	CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend-
		LnkCap:	Port #0, Speed unknown, Width x0, ASPM L0s, Latency L0
unlimited, L1 unlimited
			ClockPM- Surprise+ LLActRep+ BwNot+
		LnkCtl:	ASPM Disabled; Disabled- Retrain- CommClk-
			ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
		LnkSta:	Speed unknown, Width x0, TrErr- Train- SlotClk+ DLActive-
BWMgmt- ABWMgmt-
		DevCap2: Completion Timeout: Not Supported, TimeoutDis-
		DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-
		LnkCtl2: Target Link Speed: 2.5GT/s, EnterCompliance- SpeedDis-,
Selectable De-emphasis: -6dB
			 Transmit Margin: Normal Operating Range, EnterModifiedCompliance-
ComplianceSOS-
			 Compliance De-emphasis: -6dB
		LnkSta2: Current De-emphasis Level: -6dB
	Capabilities: [100 v0] Vendor Specific Information: ID=0000 Rev=0 Len=000 <?>

00:08.2 System peripheral: Intel Corporation Core Processor System
Control and Status Registers (rev 11)
	Subsystem: Device 0086:00ec
	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-
	Capabilities: [40] Express (v2) Root Complex Integrated Endpoint, MSI 00
		DevCap:	MaxPayload 128 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us
			ExtTag- RBE+ FLReset-
		DevCtl:	Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
			RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
			MaxPayload 128 bytes, MaxReadReq 128 bytes
		DevSta:	CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend-
		LnkCap:	Port #0, Speed unknown, Width x0, ASPM L0s, Latency L0
unlimited, L1 unlimited
			ClockPM- Surprise+ LLActRep+ BwNot+
		LnkCtl:	ASPM Disabled; Disabled- Retrain- CommClk-
			ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
		LnkSta:	Speed unknown, Width x0, TrErr- Train- SlotClk+ DLActive-
BWMgmt- ABWMgmt-
		DevCap2: Completion Timeout: Not Supported, TimeoutDis-
		DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-
		LnkCtl2: Target Link Speed: 2.5GT/s, EnterCompliance- SpeedDis-,
Selectable De-emphasis: -6dB
			 Transmit Margin: Normal Operating Range, EnterModifiedCompliance-
ComplianceSOS-
			 Compliance De-emphasis: -6dB
		LnkSta2: Current De-emphasis Level: -6dB
	Capabilities: [100 v0] Vendor Specific Information: ID=0000 Rev=0 Len=000 <?>

00:08.3 System peripheral: Intel Corporation Core Processor
Miscellaneous Registers (rev 11)
	Subsystem: Device 0086:00ec
	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-

00:10.0 System peripheral: Intel Corporation Core Processor QPI Link (rev 11)
	Subsystem: Device 0086:00ec
	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-

00:10.1 System peripheral: Intel Corporation Core Processor QPI
Routing and Protocol Registers (rev 11)
	Subsystem: Device 0086:00ec
	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-

00:19.0 Ethernet controller: Intel Corporation 82578DM Gigabit Network
Connection (rev 05)
	Subsystem: Intel Corporation Device 34ec
	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 1251
	Region 0: Memory at b3b00000 (32-bit, non-prefetchable) [size=128K]
	Region 1: Memory at b3b24000 (32-bit, non-prefetchable) [size=4K]
	Region 2: I/O ports at 3020 [size=32]
	Capabilities: [c8] Power Management version 2
		Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
		Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=1 PME-
	Capabilities: [d0] MSI: Enable+ Count=1/1 Maskable- 64bit+
		Address: 00000000fee0100c  Data: 41b1
	Capabilities: [e0] PCI Advanced Features
		AFCap: TP+ FLR+
		AFCtrl: FLR-
		AFStatus: TP-
	Kernel driver in use: e1000e

00:1a.0 USB Controller: Intel Corporation 5 Series/3400 Series Chipset
USB2 Enhanced Host Controller (rev 05) (prog-if 20 [EHCI])
	Subsystem: Intel Corporation Device 34ec
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+
Stepping- SERR+ FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0
	Interrupt: pin A routed to IRQ 21
	Region 0: Memory at b3b21000 (32-bit, non-prefetchable) [size=1K]
	Capabilities: [50] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
		Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
	Capabilities: [58] Debug port: BAR=1 offset=00a0
	Capabilities: [98] PCI Advanced Features
		AFCap: TP+ FLR+
		AFCtrl: FLR-
		AFStatus: TP-
	Kernel driver in use: ehci_hcd

00:1c.0 PCI bridge: Intel Corporation 5 Series/3400 Series Chipset PCI
Express Root Port 1 (rev 05) (prog-if 00 [Normal decode])
	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
	Bus: primary=00, secondary=02, subordinate=02, sec-latency=0
	I/O behind bridge: 0000f000-00000fff
	Memory behind bridge: fff00000-000fffff
	Prefetchable memory behind bridge: 00000000fff00000-00000000000fffff
	Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort+ <SERR- <PERR-
	BridgeCtl: Parity+ SERR+ NoISA- VGA- MAbort- >Reset- FastB2B-
		PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
	Capabilities: [40] Express (v2) Root Port (Slot+), MSI 00
		DevCap:	MaxPayload 128 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us
			ExtTag- RBE+ FLReset-
		DevCtl:	Report errors: Correctable+ Non-Fatal+ Fatal+ Unsupported-
			RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
			MaxPayload 128 bytes, MaxReadReq 128 bytes
		DevSta:	CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend-
		LnkCap:	Port #1, Speed 2.5GT/s, Width x4, ASPM L0s L1, Latency L0
<1us, L1 <4us
			ClockPM- Surprise- LLActRep+ BwNot-
		LnkCtl:	ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk-
			ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
		LnkSta:	Speed 2.5GT/s, Width x0, TrErr- Train- SlotClk+ DLActive-
BWMgmt- ABWMgmt-
		SltCap:	AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug- Surprise+
			Slot #0, PowerLimit 25.000W; Interlock- NoCompl+
		SltCtl:	Enable: AttnBtn- PwrFlt- MRL- PresDet+ CmdCplt- HPIrq- LinkChg-
			Control: AttnInd Unknown, PwrInd Unknown, Power- Interlock-
		SltSta:	Status: AttnBtn- PowerFlt- MRL- CmdCplt- PresDet+ Interlock-
			Changed: MRL- PresDet- LinkState-
		RootCtl: ErrCorrectable+ ErrNon-Fatal+ ErrFatal+ PMEIntEna- CRSVisible-
		RootCap: CRSVisible-
		RootSta: PME ReqID 0000, PMEStatus- PMEPending-
		DevCap2: Completion Timeout: Range BC, TimeoutDis+ ARIFwd-
		DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis- ARIFwd-
		LnkCtl2: Target Link Speed: 2.5GT/s, EnterCompliance- SpeedDis-,
Selectable De-emphasis: -6dB
			 Transmit Margin: Normal Operating Range, EnterModifiedCompliance-
ComplianceSOS-
			 Compliance De-emphasis: -6dB
		LnkSta2: Current De-emphasis Level: -6dB
	Capabilities: [80] MSI: Enable+ Count=1/1 Maskable- 64bit-
		Address: fee0100c  Data: 4141
	Capabilities: [90] Subsystem: Intel Corporation Device 34ec
	Capabilities: [a0] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
		Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
	Kernel driver in use: pcieport

00:1c.4 PCI bridge: Intel Corporation 5 Series/3400 Series Chipset PCI
Express Root Port 5 (rev 05) (prog-if 00 [Normal decode])
	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
	Bus: primary=00, secondary=03, subordinate=03, sec-latency=0
	I/O behind bridge: 00001000-00001fff
	Memory behind bridge: b3900000-b39fffff
	Prefetchable memory behind bridge: 00000000fff00000-00000000000fffff
	Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- <SERR- <PERR-
	BridgeCtl: Parity+ SERR+ NoISA- VGA- MAbort- >Reset- FastB2B-
		PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
	Capabilities: [40] Express (v2) Root Port (Slot-), MSI 00
		DevCap:	MaxPayload 128 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us
			ExtTag- RBE+ FLReset-
		DevCtl:	Report errors: Correctable+ Non-Fatal+ Fatal+ Unsupported-
			RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
			MaxPayload 128 bytes, MaxReadReq 128 bytes
		DevSta:	CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend-
		LnkCap:	Port #5, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency L0
<256ns, L1 <4us
			ClockPM- Surprise- LLActRep+ BwNot-
		LnkCtl:	ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+
			ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
		LnkSta:	Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive+
BWMgmt- ABWMgmt-
		RootCtl: ErrCorrectable+ ErrNon-Fatal+ ErrFatal+ PMEIntEna- CRSVisible-
		RootCap: CRSVisible-
		RootSta: PME ReqID 0000, PMEStatus- PMEPending-
		DevCap2: Completion Timeout: Range BC, TimeoutDis+ ARIFwd-
		DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis- ARIFwd-
		LnkCtl2: Target Link Speed: 2.5GT/s, EnterCompliance- SpeedDis-,
Selectable De-emphasis: -6dB
			 Transmit Margin: Normal Operating Range, EnterModifiedCompliance-
ComplianceSOS-
			 Compliance De-emphasis: -6dB
		LnkSta2: Current De-emphasis Level: -6dB
	Capabilities: [80] MSI: Enable+ Count=1/1 Maskable- 64bit-
		Address: fee0100c  Data: 4149
	Capabilities: [90] Subsystem: Intel Corporation Device 34ec
	Capabilities: [a0] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
		Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
	Kernel driver in use: pcieport

00:1c.6 PCI bridge: Intel Corporation 5 Series/3400 Series Chipset PCI
Express Root Port 7 (rev 05) (prog-if 00 [Normal decode])
	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
	Bus: primary=00, secondary=04, subordinate=04, sec-latency=0
	I/O behind bridge: 0000f000-00000fff
	Memory behind bridge: b3000000-b38fffff
	Prefetchable memory behind bridge: 00000000b2000000-00000000b2ffffff
	Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort+ <MAbort- <SERR- <PERR-
	BridgeCtl: Parity- SERR- NoISA- VGA+ MAbort- >Reset- FastB2B-
		PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
	Capabilities: [40] Express (v2) Root Port (Slot-), MSI 00
		DevCap:	MaxPayload 128 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us
			ExtTag- RBE+ FLReset-
		DevCtl:	Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
			RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
			MaxPayload 128 bytes, MaxReadReq 128 bytes
		DevSta:	CorrErr- UncorrErr+ FatalErr- UnsuppReq- AuxPwr+ TransPend-
		LnkCap:	Port #7, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency L0
<256ns, L1 <4us
			ClockPM- Surprise- LLActRep+ BwNot-
		LnkCtl:	ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+
			ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
		LnkSta:	Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive+
BWMgmt- ABWMgmt-
		RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna- CRSVisible-
		RootCap: CRSVisible-
		RootSta: PME ReqID 0000, PMEStatus- PMEPending-
		DevCap2: Completion Timeout: Range BC, TimeoutDis+ ARIFwd-
		DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis- ARIFwd-
		LnkCtl2: Target Link Speed: 2.5GT/s, EnterCompliance- SpeedDis-,
Selectable De-emphasis: -6dB
			 Transmit Margin: Normal Operating Range, EnterModifiedCompliance-
ComplianceSOS-
			 Compliance De-emphasis: -6dB
		LnkSta2: Current De-emphasis Level: -6dB
	Capabilities: [80] MSI: Enable+ Count=1/1 Maskable- 64bit-
		Address: fee0100c  Data: 4151
	Capabilities: [90] Subsystem: Intel Corporation Device 34ec
	Capabilities: [a0] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
		Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
	Kernel driver in use: pcieport

00:1c.7 PCI bridge: Intel Corporation 5 Series/3400 Series Chipset PCI
Express Root Port 8 (rev 05) (prog-if 00 [Normal decode])
	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
	Bus: primary=00, secondary=05, subordinate=05, sec-latency=0
	I/O behind bridge: 0000f000-00000fff
	Memory behind bridge: fff00000-000fffff
	Prefetchable memory behind bridge: 00000000fff00000-00000000000fffff
	Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort+ <SERR- <PERR-
	BridgeCtl: Parity+ SERR+ NoISA- VGA- MAbort- >Reset- FastB2B-
		PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
	Capabilities: [40] Express (v2) Root Port (Slot+), MSI 00
		DevCap:	MaxPayload 128 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us
			ExtTag- RBE+ FLReset-
		DevCtl:	Report errors: Correctable+ Non-Fatal+ Fatal+ Unsupported-
			RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
			MaxPayload 128 bytes, MaxReadReq 128 bytes
		DevSta:	CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend-
		LnkCap:	Port #8, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency L0
<1us, L1 <4us
			ClockPM- Surprise- LLActRep+ BwNot-
		LnkCtl:	ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk-
			ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
		LnkSta:	Speed 2.5GT/s, Width x0, TrErr- Train- SlotClk+ DLActive-
BWMgmt- ABWMgmt-
		SltCap:	AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug- Surprise+
			Slot #7, PowerLimit 10.000W; Interlock- NoCompl+
		SltCtl:	Enable: AttnBtn- PwrFlt- MRL- PresDet+ CmdCplt- HPIrq- LinkChg-
			Control: AttnInd Unknown, PwrInd Unknown, Power- Interlock-
		SltSta:	Status: AttnBtn- PowerFlt- MRL- CmdCplt- PresDet+ Interlock-
			Changed: MRL- PresDet- LinkState-
		RootCtl: ErrCorrectable+ ErrNon-Fatal+ ErrFatal+ PMEIntEna- CRSVisible-
		RootCap: CRSVisible-
		RootSta: PME ReqID 0000, PMEStatus- PMEPending-
		DevCap2: Completion Timeout: Range BC, TimeoutDis+ ARIFwd-
		DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis- ARIFwd-
		LnkCtl2: Target Link Speed: 2.5GT/s, EnterCompliance- SpeedDis-,
Selectable De-emphasis: -6dB
			 Transmit Margin: Normal Operating Range, EnterModifiedCompliance-
ComplianceSOS-
			 Compliance De-emphasis: -6dB
		LnkSta2: Current De-emphasis Level: -6dB
	Capabilities: [80] MSI: Enable+ Count=1/1 Maskable- 64bit-
		Address: fee0100c  Data: 4159
	Capabilities: [90] Subsystem: Intel Corporation Device 34ec
	Capabilities: [a0] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
		Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
	Kernel driver in use: pcieport

00:1d.0 USB Controller: Intel Corporation 5 Series/3400 Series Chipset
USB2 Enhanced Host Controller (rev 05) (prog-if 20 [EHCI])
	Subsystem: Intel Corporation Device 34ec
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+
Stepping- SERR+ FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0
	Interrupt: pin A routed to IRQ 23
	Region 0: Memory at b3b20000 (32-bit, non-prefetchable) [size=1K]
	Capabilities: [50] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
		Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
	Capabilities: [58] Debug port: BAR=1 offset=00a0
	Capabilities: [98] PCI Advanced Features
		AFCap: TP+ FLR+
		AFCtrl: FLR-
		AFStatus: TP-
	Kernel driver in use: ehci_hcd

00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev a5)
(prog-if 01 [Subtractive decode])
	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
	Bus: primary=00, secondary=06, subordinate=06, sec-latency=32
	I/O behind bridge: 0000f000-00000fff
	Memory behind bridge: fff00000-000fffff
	Prefetchable memory behind bridge: 00000000fff00000-00000000000fffff
	Secondary status: 66MHz- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort+ <SERR- <PERR-
	BridgeCtl: Parity+ SERR+ NoISA- VGA- MAbort- >Reset- FastB2B-
		PriDiscTmr- SecDiscTmr+ DiscTmrStat- DiscTmrSERREn+
	Capabilities: [50] Subsystem: Intel Corporation Device 34ec

00:1f.0 ISA bridge: Intel Corporation 3400 Series Chipset LPC
Interface Controller (rev 05)
	Subsystem: Intel Corporation Device 34ec
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+
Stepping- SERR+ FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0
	Capabilities: [e0] Vendor Specific Information: Len=10 <?>

00:1f.2 IDE interface: Intel Corporation 5 Series/3400 Series Chipset
4 port SATA IDE Controller (rev 05) (prog-if 8f [Master SecP SecO PriP
PriO])
	Subsystem: Intel Corporation Device 34ec
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0
	Interrupt: pin B routed to IRQ 18
	Region 0: I/O ports at 3098 [size=8]
	Region 1: I/O ports at 30ac [size=4]
	Region 2: I/O ports at 3090 [size=8]
	Region 3: I/O ports at 30a8 [size=4]
	Region 4: I/O ports at 3070 [size=16]
	Region 5: I/O ports at 3060 [size=16]
	Capabilities: [70] Power Management version 3
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
	Capabilities: [b0] PCI Advanced Features
		AFCap: TP+ FLR+
		AFCtrl: FLR-
		AFStatus: TP-
	Kernel driver in use: ata_piix

00:1f.3 SMBus: Intel Corporation 5 Series/3400 Series Chipset SMBus
Controller (rev 05)
	Subsystem: Intel Corporation Device 34ec
	Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx-
	Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR- INTx-
	Interrupt: pin B routed to IRQ 18
	Region 0: Memory at b3b22000 (64-bit, non-prefetchable) [size=256]
	Region 4: I/O ports at 3000 [size=32]
	Kernel driver in use: i801_smbus

00:1f.5 IDE interface: Intel Corporation 5 Series/3400 Series Chipset
2 port SATA IDE Controller (rev 05) (prog-if 85 [Master SecO PriO])
	Subsystem: Intel Corporation Device 34ec
	Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+
Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0
	Interrupt: pin D routed to IRQ 22
	Region 0: I/O ports at 3088 [size=8]
	Region 1: I/O ports at 30a4 [size=4]
	Region 2: I/O ports at 3080 [size=8]
	Region 3: I/O ports at 30a0 [size=4]
	Region 4: I/O ports at 3050 [size=16]
	Region 5: I/O ports at 3040 [size=16]
	Capabilities: [70] Power Management version 3
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
	Capabilities: [b0] PCI Advanced Features
		AFCap: TP+ FLR+
		AFCtrl: FLR-
		AFStatus: TP-
	Kernel driver in use: ata_piix

01:00.0 RAID bus controller: 3ware Inc 9690SA SAS/SATA-II RAID PCIe (rev 01)
	Subsystem: 3ware Inc 9690SA SAS/SATA-II RAID PCIe
	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, Cache Line Size: 64 bytes
	Interrupt: pin A routed to IRQ 16
	Region 0: Memory at b0000000 (64-bit, prefetchable) [size=32M]
	Region 2: Memory at b3a00000 (64-bit, non-prefetchable) [size=4K]
	Region 4: I/O ports at 2000 [size=256]
	Expansion ROM at b3a20000 [disabled] [size=128K]
	Capabilities: [40] Power Management version 2
		Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
	Capabilities: [50] MSI: Enable- Count=1/32 Maskable- 64bit+
		Address: 0000000000000000  Data: 0000
	Capabilities: [70] Express (v1) Legacy Endpoint, MSI 00
		DevCap:	MaxPayload 512 bytes, PhantFunc 0, Latency L0s <128ns, L1 <2us
			ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
		DevCtl:	Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
			RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
			MaxPayload 128 bytes, MaxReadReq 512 bytes
		DevSta:	CorrErr+ UncorrErr- FatalErr- UnsuppReq+ AuxPwr- TransPend-
		LnkCap:	Port #0, Speed 2.5GT/s, Width x8, ASPM L0s L1, Latency L0
<512ns, L1 <64us
			ClockPM- Surprise- LLActRep+ BwNot-
		LnkCtl:	ASPM Disabled; RCB 128 bytes Disabled- Retrain- CommClk-
			ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
		LnkSta:	Speed 2.5GT/s, Width x8, TrErr- Train- SlotClk- DLActive+
BWMgmt- ABWMgmt-
	Capabilities: [100 v1] Advanced Error Reporting
		UESta:	DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF-
MalfTLP- ECRC- UnsupReq+ ACSViol-
		UEMsk:	DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF-
MalfTLP- ECRC- UnsupReq- ACSViol-
		UESvrt:	DLP+ SDES- TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+
MalfTLP+ ECRC- UnsupReq- ACSViol-
		CESta:	RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
		CEMsk:	RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
		AERCap:	First Error Pointer: 00, GenCap+ CGenEn- ChkCap+ ChkEn-
	Kernel driver in use: 3w-9xxx

03:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network Connection
	Subsystem: Intel Corporation Device 34ec
	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, Cache Line Size: 64 bytes
	Interrupt: pin A routed to IRQ 16
	Region 0: Memory at b3900000 (32-bit, non-prefetchable) [size=128K]
	Region 2: I/O ports at 1000 [size=32]
	Region 3: Memory at b3920000 (32-bit, non-prefetchable) [size=16K]
	Capabilities: [c8] Power Management version 2
		Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
		Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=1 PME-
	Capabilities: [d0] MSI: Enable- Count=1/1 Maskable- 64bit+
		Address: 0000000000000000  Data: 0000
	Capabilities: [e0] Express (v1) Endpoint, MSI 00
		DevCap:	MaxPayload 256 bytes, PhantFunc 0, Latency L0s <512ns, L1 <64us
			ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
		DevCtl:	Report errors: Correctable+ Non-Fatal+ Fatal+ Unsupported+
			RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
			MaxPayload 128 bytes, MaxReadReq 512 bytes
		DevSta:	CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend-
		LnkCap:	Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency L0
<128ns, L1 <64us
			ClockPM- Surprise- LLActRep- BwNot-
		LnkCtl:	ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+
			ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
		LnkSta:	Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive-
BWMgmt- ABWMgmt-
	Capabilities: [a0] MSI-X: Enable+ Count=5 Masked-
		Vector table: BAR=3 offset=00000000
		PBA: BAR=3 offset=00002000
	Capabilities: [100 v1] Advanced Error Reporting
		UESta:	DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF-
MalfTLP- ECRC- UnsupReq- ACSViol-
		UEMsk:	DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF-
MalfTLP- ECRC- UnsupReq- ACSViol-
		UESvrt:	DLP+ SDES- TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+
MalfTLP+ ECRC- UnsupReq- ACSViol-
		CESta:	RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr-
		CEMsk:	RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
		AERCap:	First Error Pointer: 00, GenCap- CGenEn- ChkCap- ChkEn-
	Capabilities: [140 v1] Device Serial Number 00-1e-67-ff-ff-02-c2-ca
	Kernel driver in use: e1000e

04:00.0 VGA compatible controller: Matrox Graphics, Inc. MGA G200e
[Pilot] ServerEngines (SEP1) (rev 02) (prog-if 00 [VGA controller])
	Subsystem: Intel Corporation Device 0101
	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, Cache Line Size: 64 bytes
	Interrupt: pin A routed to IRQ 11
	Region 0: Memory at b2000000 (32-bit, prefetchable) [size=16M]
	Region 1: Memory at b3800000 (32-bit, non-prefetchable) [size=16K]
	Region 2: Memory at b3000000 (32-bit, non-prefetchable) [size=8M]
	Expansion ROM at b3810000 [disabled] [size=64K]
	Capabilities: [dc] Power Management version 2
		Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
	Capabilities: [e4] Express (v1) Legacy Endpoint, MSI 00
		DevCap:	MaxPayload 128 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us
			ExtTag- AttnBtn- AttnInd- PwrInd- RBE- FLReset-
		DevCtl:	Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
			RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
			MaxPayload 128 bytes, MaxReadReq 128 bytes
		DevSta:	CorrErr+ UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend-
		LnkCap:	Port #0, Speed 2.5GT/s, Width x1, ASPM L0s, Latency L0 <64ns, L1 <1us
			ClockPM- Surprise- LLActRep- BwNot-
		LnkCtl:	ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+
			ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
		LnkSta:	Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive-
BWMgmt- ABWMgmt-
	Capabilities: [54] MSI: Enable- Count=1/1 Maskable- 64bit-
		Address: 00000000  Data: 0000



### dmidecode

# dmidecode 2.9
SMBIOS 2.5 present.
64 structures occupying 2689 bytes.
Table at 0x9F6A4000.

Handle 0x0001, DMI type 38, 20 bytes
IPMI Device Information
	Interface Type: KCS (Keyboard Control Style)
	Specification Version: 2.0
	I2C Slave Address: 0x10
	NV Storage Device: Not Present
	Base Address: 0x0000000000000CA2 (I/O)
	Register Spacing: Successive Byte Boundaries

Handle 0x0002, DMI type 1, 27 bytes
System Information
	Manufacturer: Intel Corporation
	Product Name: S3420GP
	Version: ....................
	Serial Number: ............
	UUID: 0FD8E440-1952-11E0-B578-001E6702C2CA
	Wake-up Type: Power Switch
	SKU Number: Not Specified
	Family: Not Specified

Handle 0x0003, DMI type 2, 16 bytes
Base Board Information
	Manufacturer: Intel Corporation
	Product Name: S3420GP
	Version: E51976-406
	Serial Number: AZGP10200424
	Asset Tag: ....................
	Features:
		Board is a hosting board
		Board is replaceable
	Location In Chassis: Not Specified
	Chassis Handle: 0x0004
	Type: Motherboard
	Contained Object Handles: 0

Handle 0x0004, DMI type 3, 22 bytes
Chassis Information
	Manufacturer: ..............................
	Type: Main Server Chassis
	Lock: Not Present
	Version: ..................
	Serial Number: ..................
	Asset Tag: ....................
	Boot-up State: Safe
	Power Supply State: Safe
	Thermal State: Safe
	Security Status: Unknown
	OEM Information: 0x01000181
	Height: 1 U
	Number Of Power Cords: 1
	Contained Elements: 0

Handle 0x0005, DMI type 0, 24 bytes
BIOS Information
	Vendor: Intel Corp.
	Version: S3420GP.86B.01.00.0046.092920101143
	Release Date: 09/29/2010
	Address: 0xF0000
	Runtime Size: 64 kB
	ROM Size: 8192 kB
	Characteristics:
		PCI is supported
		PNP is supported
		BIOS is upgradeable
		BIOS shadowing is allowed
		Boot from CD is supported
		Selectable boot is supported
		EDD is supported
		3.5"/2.88 MB floppy services are supported (int 13h)
		Print screen service is supported (int 5h)
		8042 keyboard services are supported (int 9h)
		Serial services are supported (int 14h)
		CGA/mono video services are supported (int 10h)
		ACPI is supported
		USB legacy is supported
		LS-120 boot is supported
		ATAPI Zip drive boot is supported
		Function key-initiated network boot is supported
		Targeted content distribution is supported
	BIOS Revision: 17.18
	Firmware Revision: 0.0

Handle 0x0006, DMI type 8, 9 bytes
Port Connector Information
	Internal Reference Designator: J8A1 - SERIAL A
	Internal Connector Type: Other
	External Reference Designator: SERIAL A
	External Connector Type: DB-9 male
	Port Type: Serial Port 16550A Compatible

Handle 0x0007, DMI type 8, 9 bytes
Port Connector Information
	Internal Reference Designator: J1B2 - SERIAL B
	Internal Connector Type: 9 Pin Dual Inline (pin 10 cut)
	External Reference Designator: SERIAL B
	External Connector Type: None
	Port Type: Serial Port 16550A Compatible

Handle 0x0008, DMI type 8, 9 bytes
Port Connector Information
	Internal Reference Designator: J7A1 - VGA
	Internal Connector Type: None
	External Reference Designator: VGA
	External Connector Type: DB-15 female
	Port Type: Video Port

Handle 0x0009, DMI type 8, 9 bytes
Port Connector Information
	Internal Reference Designator: J6A1 - USB 0
	Internal Connector Type: None
	External Reference Designator: USB 0
	External Connector Type: Access Bus (USB)
	Port Type: USB

Handle 0x000A, DMI type 8, 9 bytes
Port Connector Information
	Internal Reference Designator: J6A1 - USB 1
	Internal Connector Type: None
	External Reference Designator: USB 1
	External Connector Type: Access Bus (USB)
	Port Type: USB

Handle 0x000B, DMI type 8, 9 bytes
Port Connector Information
	Internal Reference Designator: J5A1 - USB 2
	Internal Connector Type: None
	External Reference Designator: USB 2
	External Connector Type: Access Bus (USB)
	Port Type: USB

Handle 0x000C, DMI type 8, 9 bytes
Port Connector Information
	Internal Reference Designator: J5A1 - USB 3
	Internal Connector Type: None
	External Reference Designator: USB 3
	External Connector Type: Access Bus (USB)
	Port Type: USB

Handle 0x000D, DMI type 8, 9 bytes
Port Connector Information
	Internal Reference Designator: J3F2 - USB SSD
	Internal Connector Type: None
	External Reference Designator: USB SSD
	External Connector Type: Access Bus (USB)
	Port Type: USB

Handle 0x000E, DMI type 8, 9 bytes
Port Connector Information
	Internal Reference Designator: J1J2 - USB 5 FLOPPY
	Internal Connector Type: None
	External Reference Designator: USB 5 FLOPPY
	External Connector Type: Access Bus (USB)
	Port Type: USB

Handle 0x000F, DMI type 8, 9 bytes
Port Connector Information
	Internal Reference Designator: J1D1 - USB 6
	Internal Connector Type: None
	External Reference Designator: USB 6
	External Connector Type: Access Bus (USB)
	Port Type: USB

Handle 0x0010, DMI type 8, 9 bytes
Port Connector Information
	Internal Reference Designator: J1D1 - USB 7
	Internal Connector Type: None
	External Reference Designator: USB 7
	External Connector Type: Access Bus (USB)
	Port Type: USB

Handle 0x0011, DMI type 8, 9 bytes
Port Connector Information
	Internal Reference Designator: J1E1 - USB 8
	Internal Connector Type: None
	External Reference Designator: USB 8
	External Connector Type: Access Bus (USB)
	Port Type: USB

Handle 0x0012, DMI type 8, 9 bytes
Port Connector Information
	Internal Reference Designator: J1E1 - USB 9
	Internal Connector Type: None
	External Reference Designator: USB 9
	External Connector Type: Access Bus (USB)
	Port Type: USB

Handle 0x0013, DMI type 8, 9 bytes
Port Connector Information
	Internal Reference Designator: J6A1 - NIC 1
	Internal Connector Type: None
	External Reference Designator: NIC 1
	External Connector Type: RJ-45
	Port Type: Network Port

Handle 0x0014, DMI type 8, 9 bytes
Port Connector Information
	Internal Reference Designator: J5A1 - NIC 2
	Internal Connector Type: None
	External Reference Designator: NIC 2
	External Connector Type: RJ-45
	Port Type: Network Port

Handle 0x0015, DMI type 8, 9 bytes
Port Connector Information
	Internal Reference Designator: J1H4 - 1x7 Pin SATA 0
	Internal Connector Type: Other
	External Reference Designator: SATA 0
	External Connector Type: None
	Port Type: Other

Handle 0x0016, DMI type 8, 9 bytes
Port Connector Information
	Internal Reference Designator: J1H1 - 1x7 Pin SATA 1
	Internal Connector Type: Other
	External Reference Designator: SATA 1
	External Connector Type: None
	Port Type: Other

Handle 0x0017, DMI type 8, 9 bytes
Port Connector Information
	Internal Reference Designator: J1G1 - 1x7 Pin SATA 2
	Internal Connector Type: Other
	External Reference Designator: SATA 2
	External Connector Type: None
	Port Type: Other

Handle 0x0018, DMI type 8, 9 bytes
Port Connector Information
	Internal Reference Designator: J1H3 - 1x7 Pin SATA 3
	Internal Connector Type: Other
	External Reference Designator: SATA 3
	External Connector Type: None
	Port Type: Other

Handle 0x0019, DMI type 8, 9 bytes
Port Connector Information
	Internal Reference Designator: J1G3 - 1x7 Pin SATA 4
	Internal Connector Type: Other
	External Reference Designator: SATA 4
	External Connector Type: None
	Port Type: Other

Handle 0x001A, DMI type 8, 9 bytes
Port Connector Information
	Internal Reference Designator: J1F4 - 1x7 Pin SATA 5
	Internal Connector Type: Other
	External Reference Designator: SATA 5
	External Connector Type: None
	Port Type: Other

Handle 0x001B, DMI type 8, 9 bytes
Port Connector Information
	Internal Reference Designator: J1C1 - 24-Pin Male Front Panel
	Internal Connector Type: Other
	External Reference Designator: Front Panel
	External Connector Type: None
	Port Type: Other

Handle 0x001C, DMI type 8, 9 bytes
Port Connector Information
	Internal Reference Designator: J1H2 4-Pin Male IPMB
	Internal Connector Type: Other
	External Reference Designator: IPMB
	External Connector Type: None
	Port Type: Other

Handle 0x001D, DMI type 9, 13 bytes
System Slot Information
	Designation: PCI SLOT1
	Type: 32-bit PCI
	Current Usage: Available
	Length: Long
	ID: 1
	Characteristics:
		3.3 V is provided
		PME signal is supported

Handle 0x001E, DMI type 9, 13 bytes
System Slot Information
	Designation: PCI-E SLOT3
	Type: x4 PCI Express
	Current Usage: Available
	Length: Long
	ID: 3
	Characteristics:
		3.3 V is provided
		PME signal is supported

Handle 0x001F, DMI type 9, 13 bytes
System Slot Information
	Designation: PCI-E SLOT5
	Type: x8 PCI Express
	Current Usage: Available
	Length: Long
	ID: 5
	Characteristics:
		3.3 V is provided
		PME signal is supported

Handle 0x0020, DMI type 9, 13 bytes
System Slot Information
	Designation: PCI-E SLOT6
	Type: x16 PCI Express
	Current Usage: In Use
	Length: Long
	ID: 6
	Characteristics:
		3.3 V is provided
		PME signal is supported

Handle 0x0021, DMI type 10, 6 bytes
On Board Device Information
	Type: Video
	Status: Enabled
	Description: ServerEngines Pilot II

Handle 0x0022, DMI type 10, 6 bytes
On Board Device Information
	Type: Ethernet
	Status: Enabled
	Description: Intel 82574L

Handle 0x0023, DMI type 10, 6 bytes
On Board Device Information
	Type: Ethernet
	Status: Enabled
	Description: Intel 82578DM

Handle 0x0024, DMI type 10, 6 bytes
On Board Device Information
	Type: SATA Controller
	Status: Enabled
	Description: PCH Integrated SATA Controller

Handle 0x0025, DMI type 12, 5 bytes
System Configuration Options
	Option 1: J1F2 2-3: Close to clear Password

Handle 0x0026, DMI type 12, 5 bytes
System Configuration Options
	Option 1: J1F5 2-3: Close to clear CMOS

Handle 0x0027, DMI type 12, 5 bytes
System Configuration Options
	Option 1: J1F3 2-3: Close for BIOS Recovery

Handle 0x0028, DMI type 12, 5 bytes
System Configuration Options
	Option 1: J1A2 2-3: Close to Force BMC Update Mode

Handle 0x0029, DMI type 12, 5 bytes
System Configuration Options
	Option 1: J1F1 2-3: Close to Force ME Update Mode

Handle 0x002A, DMI type 24, 5 bytes
Hardware Security
	Power-On Password Status: Disabled
	Keyboard Password Status: Disabled
	Administrator Password Status: Disabled
	Front Panel Reset Status: Disabled

Handle 0x002B, DMI type 13, 22 bytes
BIOS Language Information
	Installable Languages: 1
		en|US|iso8859-1
	Currently Installed Language: en|US|iso8859-1

Handle 0x002C, DMI type 11, 5 bytes
OEM Strings
	String 1:
	String 2:
	String 3:
	String 4:
	String 5:

Handle 0x002D, DMI type 32, 20 bytes
System Boot Information
	Status: No errors detected

Handle 0x002E, DMI type 16, 15 bytes
Physical Memory Array
	Location: System Board Or Motherboard
	Use: System Memory
	Error Correction Type: Multi-bit ECC
	Maximum Capacity: 32 GB
	Error Information Handle: Not Provided
	Number Of Devices: 6

Handle 0x002F, DMI type 19, 15 bytes
Memory Array Mapped Address
	Starting Address: 0x00000000000
	Ending Address: 0x003FFFFFFFF
	Range Size: 16 GB
	Physical Array Handle: 0x002E
	Partition Width: 0

Handle 0x0030, DMI type 17, 27 bytes
Memory Device
	Array Handle: 0x002E
	Error Information Handle: Not Provided
	Total Width: 72 bits
	Data Width: 64 bits
	Size: 4096 MB
	Form Factor: DIMM
	Set: 1
	Locator: DIMM_A1
	Bank Locator: NODE 0 CHANNEL 0 DIMM 0
	Type: Other
	Type Detail: Synchronous
	Speed: 1333 MHz (0.8 ns)
	Manufacturer: 0x0198
	Serial Number: 0x40247588
	Asset Tag: Unknown
	Part Number: 9965413-002.A00LF

Handle 0x0031, DMI type 20, 19 bytes
Memory Device Mapped Address
	Starting Address: 0x00000000000
	Ending Address: 0x000FFFFFFFF
	Range Size: 4 GB
	Physical Device Handle: 0x0030
	Memory Array Mapped Address Handle: 0x002F
	Partition Row Position: 1
	Interleave Position: 1
	Interleaved Data Depth: 1

Handle 0x0032, DMI type 17, 27 bytes
Memory Device
	Array Handle: 0x002E
	Error Information Handle: Not Provided
	Total Width: 72 bits
	Data Width: 64 bits
	Size: 4096 MB
	Form Factor: DIMM
	Set: 2
	Locator: DIMM_A2
	Bank Locator: NODE 0 CHANNEL 0 DIMM 1
	Type: Other
	Type Detail: Synchronous
	Speed: 1333 MHz (0.8 ns)
	Manufacturer: 0x0198
	Serial Number: 0x4324FA41
	Asset Tag: Unknown
	Part Number: 9965413-002.A00LF

Handle 0x0033, DMI type 20, 19 bytes
Memory Device Mapped Address
	Starting Address: 0x00100000000
	Ending Address: 0x001FFFFFFFF
	Range Size: 4 GB
	Physical Device Handle: 0x0032
	Memory Array Mapped Address Handle: 0x002F
	Partition Row Position: 1
	Interleave Position: 1
	Interleaved Data Depth: 1

Handle 0x0034, DMI type 17, 27 bytes
Memory Device
	Array Handle: 0x002E
	Error Information Handle: Not Provided
	Total Width: Unknown
	Data Width: Unknown
	Size: No Module Installed
	Form Factor: DIMM
	Set: 3
	Locator: DIMM_A3
	Bank Locator: NODE 0 CHANNEL 0 DIMM 2
	Type: Other
	Type Detail: Synchronous
	Speed: 1333 MHz (0.8 ns)
	Manufacturer: NO DIMM
	Serial Number: NO DIMM
	Asset Tag: NO DIMM
	Part Number: NO DIMM

Handle 0x0035, DMI type 17, 27 bytes
Memory Device
	Array Handle: 0x002E
	Error Information Handle: Not Provided
	Total Width: 72 bits
	Data Width: 64 bits
	Size: 4096 MB
	Form Factor: DIMM
	Set: 1
	Locator: DIMM_B1
	Bank Locator: NODE 0 CHANNEL 1 DIMM 0
	Type: Other
	Type Detail: Synchronous
	Speed: 1333 MHz (0.8 ns)
	Manufacturer: 0x0198
	Serial Number: 0x4524FB41
	Asset Tag: Unknown
	Part Number: 9965413-002.A00LF

Handle 0x0036, DMI type 20, 19 bytes
Memory Device Mapped Address
	Starting Address: 0x00200000000
	Ending Address: 0x002FFFFFFFF
	Range Size: 4 GB
	Physical Device Handle: 0x0035
	Memory Array Mapped Address Handle: 0x002F
	Partition Row Position: 1
	Interleave Position: 1
	Interleaved Data Depth: 1

Handle 0x0037, DMI type 17, 27 bytes
Memory Device
	Array Handle: 0x002E
	Error Information Handle: Not Provided
	Total Width: 72 bits
	Data Width: 64 bits
	Size: 4096 MB
	Form Factor: DIMM
	Set: 2
	Locator: DIMM_B2
	Bank Locator: NODE 0 CHANNEL 1 DIMM 1
	Type: Other
	Type Detail: Synchronous
	Speed: 1333 MHz (0.8 ns)
	Manufacturer: 0x0198
	Serial Number: 0x4524F841
	Asset Tag: Unknown
	Part Number: 9965413-002.A00LF

Handle 0x0038, DMI type 20, 19 bytes
Memory Device Mapped Address
	Starting Address: 0x00300000000
	Ending Address: 0x003FFFFFFFF
	Range Size: 4 GB
	Physical Device Handle: 0x0037
	Memory Array Mapped Address Handle: 0x002F
	Partition Row Position: 1
	Interleave Position: 1
	Interleaved Data Depth: 1

Handle 0x0039, DMI type 17, 27 bytes
Memory Device
	Array Handle: 0x002E
	Error Information Handle: Not Provided
	Total Width: Unknown
	Data Width: Unknown
	Size: No Module Installed
	Form Factor: DIMM
	Set: 3
	Locator: DIMM_B3
	Bank Locator: NODE 0 CHANNEL 1 DIMM 2
	Type: Other
	Type Detail: Synchronous
	Speed: 1333 MHz (0.8 ns)
	Manufacturer: NO DIMM
	Serial Number: NO DIMM
	Asset Tag: NO DIMM
	Part Number: NO DIMM

Handle 0x003A, DMI type 131, 45 bytes
OEM-specific Type
	Header and Data:
		83 2D 3A 00 01 77 00 00 00 00 00 00 00 33 00 00
		00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
		00 00 00 00 00 00 00 00 00 00 00 00 00

Handle 0x003B, DMI type 4, 40 bytes
Processor Information
	Socket Designation: CPU1
	Type: Central Processor
	Family: Xeon
	Manufacturer: Intel(R) Corporation
	ID: E5 06 01 00 FF FB EB BF
	Signature: Type 0, Family 6, Model 30, Stepping 5
	Flags:
		FPU (Floating-point unit on-chip)
		VME (Virtual mode extension)
		DE (Debugging extension)
		PSE (Page size extension)
		TSC (Time stamp counter)
		MSR (Model specific registers)
		PAE (Physical address extension)
		MCE (Machine check exception)
		CX8 (CMPXCHG8 instruction supported)
		APIC (On-chip APIC hardware supported)
		SEP (Fast system call)
		MTRR (Memory type range registers)
		PGE (Page global enable)
		MCA (Machine check architecture)
		CMOV (Conditional move instruction supported)
		PAT (Page attribute table)
		PSE-36 (36-bit page size extension)
		CLFSH (CLFLUSH instruction supported)
		DS (Debug store)
		ACPI (ACPI supported)
		MMX (MMX technology supported)
		FXSR (Fast floating-point save and restore)
		SSE (Streaming SIMD extensions)
		SSE2 (Streaming SIMD extensions 2)
		SS (Self-snoop)
		HTT (Hyper-threading technology)
		TM (Thermal monitor supported)
		PBE (Pending break enabled)
	Version: Intel(R) Xeon(R) CPU           X3430  @ 2.40GHz
	Voltage: 0.0 V
	External Clock: 133 MHz
	Max Speed: 4000 MHz
	Current Speed: 2400 MHz
	Status: Populated, Enabled
	Upgrade: Other
	L1 Cache Handle: 0x003F
	L2 Cache Handle: 0x003E
	L3 Cache Handle: 0x003C
	Serial Number: Not Specified
	Asset Tag: Not Specified
	Part Number: Not Specified
	Core Count: 4
	Core Enabled: 4
	Thread Count: 8
	Characteristics:
		64-bit capable

Handle 0x003C, DMI type 7, 19 bytes
Cache Information
	Socket Designation: L3-Cache
	Configuration: Enabled, Not Socketed, Level 3
	Operational Mode: Write Back
	Location: Internal
	Installed Size: 8192 KB
	Maximum Size: 8192 KB
	Supported SRAM Types:
		Asynchronous
	Installed SRAM Type: Asynchronous
	Speed: Unknown
	Error Correction Type: Single-bit ECC
	System Type: Unified
	Associativity: 16-way Set-associative

Handle 0x003D, DMI type 7, 19 bytes
Cache Information
	Socket Designation: L1-Cache
	Configuration: Enabled, Not Socketed, Level 1
	Operational Mode: Write Back
	Location: Internal
	Installed Size: 128 KB
	Maximum Size: 128 KB
	Supported SRAM Types:
		Asynchronous
	Installed SRAM Type: Asynchronous
	Speed: Unknown
	Error Correction Type: Single-bit ECC
	System Type: Data
	Associativity: 8-way Set-associative

Handle 0x003E, DMI type 7, 19 bytes
Cache Information
	Socket Designation: L2-Cache
	Configuration: Enabled, Not Socketed, Level 2
	Operational Mode: Write Back
	Location: Internal
	Installed Size: 1024 KB
	Maximum Size: 1024 KB
	Supported SRAM Types:
		Asynchronous
	Installed SRAM Type: Asynchronous
	Speed: Unknown
	Error Correction Type: Single-bit ECC
	System Type: Unified
	Associativity: 8-way Set-associative

Handle 0x003F, DMI type 7, 19 bytes
Cache Information
	Socket Designation: L1-Cache
	Configuration: Enabled, Not Socketed, Level 1
	Operational Mode: Write Back
	Location: Internal
	Installed Size: 128 KB
	Maximum Size: 128 KB
	Supported SRAM Types:
		Asynchronous
	Installed SRAM Type: Asynchronous
	Speed: Unknown
	Error Correction Type: Single-bit ECC
	System Type: Instruction
	Associativity: 4-way Set-associative

Handle 0xFEFF, DMI type 127, 4 bytes
End Of Table



#### .config

#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.32.47
# Fri Dec  2 13:02:03 2011
#
CONFIG_64BIT=y
# CONFIG_X86_32 is not set
CONFIG_X86_64=y
CONFIG_X86=y
CONFIG_OUTPUT_FORMAT="elf64-x86-64"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig"
CONFIG_GENERIC_TIME=y
CONFIG_GENERIC_CMOS_UPDATE=y
CONFIG_CLOCKSOURCE_WATCHDOG=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_HAVE_LATENCYTOP_SUPPORT=y
CONFIG_MMU=y
CONFIG_ZONE_DMA=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_IOMAP=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
# CONFIG_RWSEM_GENERIC_SPINLOCK is not set
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_ARCH_HAS_CPU_IDLE_WAIT=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_GENERIC_TIME_VSYSCALL=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_DEFAULT_IDLE=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_HAVE_CPUMASK_OF_CPU_MAP=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ZONE_DMA32=y
CONFIG_ARCH_POPULATES_NODE_MAP=y
CONFIG_AUDIT_ARCH=y
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_GENERIC_HARDIRQS=y
CONFIG_GENERIC_HARDIRQS_NO__DO_IRQ=y
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_PENDING_IRQ=y
CONFIG_USE_GENERIC_SMP_HELPERS=y
CONFIG_X86_64_SMP=y
CONFIG_X86_HT=y
CONFIG_X86_TRAMPOLINE=y
# CONFIG_KTIME_SCALAR is not set
CONFIG_ARCH_CPU_PROBE_RELEASE=y
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_CONSTRUCTORS=y

#
# General setup
#
CONFIG_EXPERIMENTAL=y
CONFIG_LOCK_KERNEL=y
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_LOCALVERSION=""
# CONFIG_LOCALVERSION_AUTO is not set
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_KERNEL_GZIP=y
# CONFIG_KERNEL_BZIP2 is not set
# CONFIG_KERNEL_LZMA is not set
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
CONFIG_POSIX_MQUEUE=y
CONFIG_POSIX_MQUEUE_SYSCTL=y
CONFIG_BSD_PROCESS_ACCT=y
# CONFIG_BSD_PROCESS_ACCT_V3 is not set
CONFIG_TASKSTATS=y
CONFIG_TASK_DELAY_ACCT=y
CONFIG_TASK_XACCT=y
CONFIG_TASK_IO_ACCOUNTING=y
CONFIG_AUDIT=y
CONFIG_AUDITSYSCALL=y
CONFIG_AUDIT_TREE=y

#
# RCU Subsystem
#
CONFIG_TREE_RCU=y
# CONFIG_TREE_PREEMPT_RCU is not set
# CONFIG_RCU_TRACE is not set
CONFIG_RCU_FANOUT=32
# CONFIG_RCU_FANOUT_EXACT is not set
# CONFIG_TREE_RCU_TRACE is not set
# CONFIG_IKCONFIG is not set
CONFIG_LOG_BUF_SHIFT=18
CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y
CONFIG_CGROUPS=y
# CONFIG_CGROUP_DEBUG is not set
CONFIG_CGROUP_NS=y
CONFIG_CGROUP_FREEZER=y
# CONFIG_CGROUP_DEVICE is not set
CONFIG_CPUSETS=y
CONFIG_PROC_PID_CPUSET=y
CONFIG_CGROUP_CPUACCT=y
CONFIG_RESOURCE_COUNTERS=y
# CONFIG_CGROUP_MEM_RES_CTLR is not set
CONFIG_CGROUP_SCHED=y
CONFIG_FAIR_GROUP_SCHED=y
# CONFIG_RT_GROUP_SCHED is not set
# CONFIG_SYSFS_DEPRECATED_V2 is not set
CONFIG_RELAY=y
CONFIG_NAMESPACES=y
CONFIG_UTS_NS=y
CONFIG_IPC_NS=y
CONFIG_USER_NS=y
CONFIG_PID_NS=y
CONFIG_NET_NS=y
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=""
CONFIG_RD_GZIP=y
CONFIG_RD_BZIP2=y
CONFIG_RD_LZMA=y
CONFIG_CC_OPTIMIZE_FOR_SIZE=y
CONFIG_SYSCTL=y
CONFIG_ANON_INODES=y
# CONFIG_EMBEDDED is not set
CONFIG_UID16=y
CONFIG_SYSCTL_SYSCALL=y
CONFIG_KALLSYMS=y
CONFIG_KALLSYMS_ALL=y
CONFIG_KALLSYMS_EXTRA_PASS=y
CONFIG_HOTPLUG=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_PCSPKR_PLATFORM=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_SIGNALFD=y
CONFIG_TIMERFD=y
CONFIG_EVENTFD=y
CONFIG_SHMEM=y
CONFIG_AIO=y
CONFIG_HAVE_PERF_EVENTS=y

#
# Kernel Performance Events And Counters
#
CONFIG_PERF_EVENTS=y
CONFIG_EVENT_PROFILE=y
# CONFIG_PERF_COUNTERS is not set
# CONFIG_DEBUG_PERF_USE_VMALLOC is not set
CONFIG_VM_EVENT_COUNTERS=y
CONFIG_PCI_QUIRKS=y
CONFIG_SLUB_DEBUG=y
# CONFIG_COMPAT_BRK is not set
# CONFIG_SLAB is not set
CONFIG_SLUB=y
# CONFIG_SLOB is not set
CONFIG_PROFILING=y
CONFIG_TRACEPOINTS=y
# CONFIG_OPROFILE is not set
CONFIG_HAVE_OPROFILE=y
CONFIG_KPROBES=y
CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS=y
CONFIG_KRETPROBES=y
CONFIG_HAVE_IOREMAP_PROT=y
CONFIG_HAVE_KPROBES=y
CONFIG_HAVE_KRETPROBES=y
CONFIG_HAVE_ARCH_TRACEHOOK=y
CONFIG_HAVE_DMA_ATTRS=y
CONFIG_HAVE_DMA_API_DEBUG=y

#
# GCOV-based kernel profiling
#
# CONFIG_GCOV_KERNEL is not set
CONFIG_SLOW_WORK=y
# CONFIG_SLOW_WORK_DEBUG is not set
# CONFIG_HAVE_GENERIC_DMA_COHERENT is not set
CONFIG_SLABINFO=y
CONFIG_RT_MUTEXES=y
CONFIG_BASE_SMALL=0
CONFIG_MODULES=y
# CONFIG_MODULE_FORCE_LOAD is not set
CONFIG_MODULE_UNLOAD=y
CONFIG_MODULE_FORCE_UNLOAD=y
# CONFIG_MODVERSIONS is not set
# CONFIG_MODULE_SRCVERSION_ALL is not set
CONFIG_STOP_MACHINE=y
CONFIG_BLOCK=y
CONFIG_BLK_DEV_BSG=y
# CONFIG_BLK_DEV_INTEGRITY is not set
CONFIG_BLOCK_COMPAT=y

#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_AS=y
CONFIG_IOSCHED_DEADLINE=y
CONFIG_IOSCHED_CFQ=y
# CONFIG_DEFAULT_AS is not set
# CONFIG_DEFAULT_DEADLINE is not set
CONFIG_DEFAULT_CFQ=y
# CONFIG_DEFAULT_NOOP is not set
CONFIG_DEFAULT_IOSCHED="cfq"
CONFIG_PREEMPT_NOTIFIERS=y
CONFIG_FREEZER=y

#
# Processor type and features
#
CONFIG_TICK_ONESHOT=y
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y
CONFIG_GENERIC_CLOCKEVENTS_BUILD=y
CONFIG_SMP=y
CONFIG_SPARSE_IRQ=y
CONFIG_X86_MPPARSE=y
CONFIG_X86_EXTENDED_PLATFORM=y
# CONFIG_X86_VSMP is not set
CONFIG_X86_SUPPORTS_MEMORY_FAILURE=y
CONFIG_SCHED_OMIT_FRAME_POINTER=y
CONFIG_PARAVIRT_GUEST=y
CONFIG_XEN=y
CONFIG_XEN_PVHVM=y
CONFIG_XEN_MAX_DOMAIN_MEMORY=128
CONFIG_XEN_SAVE_RESTORE=y
CONFIG_XEN_DEBUG_FS=y
CONFIG_SWIOTLB_XEN=y
CONFIG_MICROCODE_XEN=y
CONFIG_XEN_DOM0=y
CONFIG_XEN_PRIVILEGED_GUEST=y
CONFIG_XEN_DOM0_PCI=y
# CONFIG_XEN_PCI_PASSTHROUGH is not set
CONFIG_KVM_CLOCK=y
# CONFIG_KVM_GUEST is not set
CONFIG_PARAVIRT=y
# CONFIG_PARAVIRT_SPINLOCKS is not set
CONFIG_PARAVIRT_CLOCK=y
CONFIG_PARAVIRT_DEBUG=y
# CONFIG_MEMTEST is not set
# CONFIG_M386 is not set
# CONFIG_M486 is not set
# CONFIG_M586 is not set
# CONFIG_M586TSC is not set
# CONFIG_M586MMX is not set
# CONFIG_M686 is not set
# CONFIG_MPENTIUMII is not set
# CONFIG_MPENTIUMIII is not set
# CONFIG_MPENTIUMM is not set
# CONFIG_MPENTIUM4 is not set
# CONFIG_MK6 is not set
# CONFIG_MK7 is not set
# CONFIG_MK8 is not set
# CONFIG_MCRUSOE is not set
# CONFIG_MEFFICEON is not set
# CONFIG_MWINCHIPC6 is not set
# CONFIG_MWINCHIP3D is not set
# CONFIG_MGEODEGX1 is not set
# CONFIG_MGEODE_LX is not set
# CONFIG_MCYRIXIII is not set
# CONFIG_MVIAC3_2 is not set
# CONFIG_MVIAC7 is not set
# CONFIG_MPSC is not set
# CONFIG_MCORE2 is not set
# CONFIG_MATOM is not set
CONFIG_GENERIC_CPU=y
CONFIG_X86_CPU=y
CONFIG_X86_L1_CACHE_BYTES=64
CONFIG_X86_INTERNODE_CACHE_BYTES=64
CONFIG_X86_CMPXCHG=y
CONFIG_X86_L1_CACHE_SHIFT=6
CONFIG_X86_XADD=y
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_TSC=y
CONFIG_X86_CMPXCHG64=y
CONFIG_X86_CMOV=y
CONFIG_X86_MINIMUM_CPU_FAMILY=64
CONFIG_X86_DEBUGCTLMSR=y
CONFIG_CPU_SUP_INTEL=y
CONFIG_CPU_SUP_AMD=y
CONFIG_CPU_SUP_CENTAUR=y
# CONFIG_X86_DS is not set
CONFIG_HPET_TIMER=y
CONFIG_HPET_EMULATE_RTC=y
CONFIG_DMI=y
CONFIG_GART_IOMMU=y
# CONFIG_CALGARY_IOMMU is not set
# CONFIG_AMD_IOMMU is not set
CONFIG_SWIOTLB=y
CONFIG_IOMMU_HELPER=y
# CONFIG_IOMMU_API is not set
# CONFIG_MAXSMP is not set
CONFIG_NR_CPUS=8
CONFIG_SCHED_SMT=y
CONFIG_SCHED_MC=y
# CONFIG_IRQ_TIME_ACCOUNTING is not set
# CONFIG_PREEMPT_NONE is not set
CONFIG_PREEMPT_VOLUNTARY=y
# CONFIG_PREEMPT is not set
CONFIG_X86_LOCAL_APIC=y
CONFIG_X86_IO_APIC=y
CONFIG_X86_REROUTE_FOR_BROKEN_BOOT_IRQS=y
CONFIG_X86_MCE=y
# CONFIG_X86_MCE_INTEL is not set
# CONFIG_X86_MCE_AMD is not set
# CONFIG_X86_MCE_INJECT is not set
# CONFIG_I8K is not set
CONFIG_MICROCODE=y
CONFIG_MICROCODE_INTEL=y
CONFIG_MICROCODE_AMD=y
CONFIG_MICROCODE_OLD_INTERFACE=y
CONFIG_X86_MSR=y
CONFIG_X86_CPUID=y
CONFIG_ARCH_PHYS_ADDR_T_64BIT=y
CONFIG_DIRECT_GBPAGES=y
# CONFIG_NUMA is not set
CONFIG_ARCH_PROC_KCORE_TEXT=y
CONFIG_ARCH_SPARSEMEM_DEFAULT=y
CONFIG_ARCH_SPARSEMEM_ENABLE=y
CONFIG_ARCH_SELECT_MEMORY_MODEL=y
CONFIG_ILLEGAL_POINTER_VALUE=0xdead000000000000
CONFIG_SELECT_MEMORY_MODEL=y
# CONFIG_FLATMEM_MANUAL is not set
# CONFIG_DISCONTIGMEM_MANUAL is not set
CONFIG_SPARSEMEM_MANUAL=y
CONFIG_SPARSEMEM=y
CONFIG_HAVE_MEMORY_PRESENT=y
CONFIG_SPARSEMEM_EXTREME=y
CONFIG_SPARSEMEM_VMEMMAP_ENABLE=y
# CONFIG_SPARSEMEM_VMEMMAP is not set
# CONFIG_MEMORY_HOTPLUG is not set
CONFIG_PAGEFLAGS_EXTENDED=y
CONFIG_SPLIT_PTLOCK_CPUS=4
CONFIG_PHYS_ADDR_T_64BIT=y
CONFIG_ZONE_DMA_FLAG=1
CONFIG_BOUNCE=y
CONFIG_VIRT_TO_BUS=y
CONFIG_HAVE_MLOCK=y
CONFIG_HAVE_MLOCKED_PAGE_BIT=y
CONFIG_MMU_NOTIFIER=y
# CONFIG_KSM is not set
CONFIG_DEFAULT_MMAP_MIN_ADDR=4096
CONFIG_ARCH_SUPPORTS_MEMORY_FAILURE=y
# CONFIG_MEMORY_FAILURE is not set
CONFIG_X86_CHECK_BIOS_CORRUPTION=y
CONFIG_X86_BOOTPARAM_MEMORY_CORRUPTION_CHECK=y
CONFIG_X86_RESERVE_LOW_64K=y
CONFIG_MTRR=y
# CONFIG_MTRR_SANITIZER is not set
CONFIG_X86_PAT=y
CONFIG_ARCH_USES_PG_UNCACHED=y
CONFIG_EFI=y
CONFIG_SECCOMP=y
# CONFIG_CC_STACKPROTECTOR is not set
# CONFIG_HZ_100 is not set
# CONFIG_HZ_250 is not set
# CONFIG_HZ_300 is not set
CONFIG_HZ_1000=y
CONFIG_HZ=1000
CONFIG_SCHED_HRTICK=y
CONFIG_KEXEC=y
CONFIG_CRASH_DUMP=y
# CONFIG_KEXEC_JUMP is not set
CONFIG_PHYSICAL_START=0x1000000
CONFIG_RELOCATABLE=y
CONFIG_PHYSICAL_ALIGN=0x1000000
CONFIG_HOTPLUG_CPU=y
# CONFIG_COMPAT_VDSO is not set
# CONFIG_CMDLINE_BOOL is not set
CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y

#
# Power management and ACPI options
#
CONFIG_ARCH_HIBERNATION_HEADER=y
CONFIG_PM=y
CONFIG_PM_DEBUG=y
# CONFIG_PM_VERBOSE is not set
CONFIG_CAN_PM_TRACE=y
CONFIG_PM_TRACE=y
CONFIG_PM_TRACE_RTC=y
CONFIG_PM_SLEEP_SMP=y
CONFIG_PM_SLEEP=y
CONFIG_SUSPEND=y
# CONFIG_PM_TEST_SUSPEND is not set
CONFIG_SUSPEND_FREEZER=y
CONFIG_HIBERNATION_NVS=y
CONFIG_HIBERNATION=y
CONFIG_PM_STD_PARTITION=""
# CONFIG_PM_RUNTIME is not set
CONFIG_ACPI=y
CONFIG_ACPI_SLEEP=y
CONFIG_ACPI_PROCFS=y
CONFIG_ACPI_PROCFS_POWER=y
# CONFIG_ACPI_POWER_METER is not set
CONFIG_ACPI_SYSFS_POWER=y
CONFIG_ACPI_PROC_EVENT=y
CONFIG_ACPI_AC=y
CONFIG_ACPI_BATTERY=y
CONFIG_ACPI_BUTTON=y
CONFIG_ACPI_VIDEO=y
CONFIG_ACPI_FAN=y
CONFIG_ACPI_DOCK=y
CONFIG_ACPI_PROCESSOR=y
CONFIG_ACPI_HOTPLUG_CPU=y
# CONFIG_ACPI_PROCESSOR_AGGREGATOR is not set
CONFIG_ACPI_THERMAL=y
# CONFIG_ACPI_CUSTOM_DSDT is not set
CONFIG_ACPI_BLACKLIST_YEAR=0
# CONFIG_ACPI_DEBUG is not set
# CONFIG_ACPI_PCI_SLOT is not set
CONFIG_X86_PM_TIMER=y
CONFIG_ACPI_CONTAINER=y
# CONFIG_ACPI_SBS is not set
# CONFIG_SFI is not set

#
# CPU Frequency scaling
#
CONFIG_CPU_FREQ=y
CONFIG_CPU_FREQ_TABLE=y
CONFIG_CPU_FREQ_DEBUG=y
# CONFIG_CPU_FREQ_STAT is not set
# CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE is not set
# CONFIG_CPU_FREQ_DEFAULT_GOV_POWERSAVE is not set
CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE=y
# CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND is not set
# CONFIG_CPU_FREQ_DEFAULT_GOV_CONSERVATIVE is not set
CONFIG_CPU_FREQ_GOV_PERFORMANCE=y
# CONFIG_CPU_FREQ_GOV_POWERSAVE is not set
CONFIG_CPU_FREQ_GOV_USERSPACE=y
CONFIG_CPU_FREQ_GOV_ONDEMAND=y
# CONFIG_CPU_FREQ_GOV_CONSERVATIVE is not set

#
# CPUFreq processor drivers
#
CONFIG_X86_ACPI_CPUFREQ=y
# CONFIG_X86_POWERNOW_K8 is not set
# CONFIG_X86_SPEEDSTEP_CENTRINO is not set
# CONFIG_X86_P4_CLOCKMOD is not set

#
# shared options
#
# CONFIG_X86_SPEEDSTEP_LIB is not set
CONFIG_CPU_IDLE=y
CONFIG_CPU_IDLE_GOV_LADDER=y
CONFIG_CPU_IDLE_GOV_MENU=y

#
# Memory power savings
#
# CONFIG_I7300_IDLE is not set

#
# Bus options (PCI etc.)
#
CONFIG_PCI=y
CONFIG_PCI_DIRECT=y
CONFIG_PCI_MMCONFIG=y
CONFIG_PCI_XEN=y
CONFIG_PCI_DOMAINS=y
# CONFIG_DMAR is not set
# CONFIG_INTR_REMAP is not set
CONFIG_PCIEPORTBUS=y
# CONFIG_HOTPLUG_PCI_PCIE is not set
CONFIG_PCIEAER=y
# CONFIG_PCIE_ECRC is not set
# CONFIG_PCIEAER_INJECT is not set
# CONFIG_PCIEASPM is not set
CONFIG_ARCH_SUPPORTS_MSI=y
CONFIG_PCI_MSI=y
# CONFIG_PCI_LEGACY is not set
# CONFIG_PCI_DEBUG is not set
# CONFIG_PCI_STUB is not set
CONFIG_XEN_PCIDEV_FRONTEND=y
CONFIG_HT_IRQ=y
# CONFIG_PCI_IOV is not set
CONFIG_ISA_DMA_API=y
CONFIG_K8_NB=y
CONFIG_PCCARD=y
# CONFIG_PCMCIA_DEBUG is not set
CONFIG_PCMCIA=y
CONFIG_PCMCIA_LOAD_CIS=y
CONFIG_PCMCIA_IOCTL=y
CONFIG_CARDBUS=y

#
# PC-card bridges
#
CONFIG_YENTA=y
CONFIG_YENTA_O2=y
CONFIG_YENTA_RICOH=y
CONFIG_YENTA_TI=y
CONFIG_YENTA_ENE_TUNE=y
CONFIG_YENTA_TOSHIBA=y
# CONFIG_PD6729 is not set
# CONFIG_I82092 is not set
CONFIG_PCCARD_NONSTATIC=y
CONFIG_HOTPLUG_PCI=y
# CONFIG_HOTPLUG_PCI_FAKE is not set
# CONFIG_HOTPLUG_PCI_ACPI is not set
# CONFIG_HOTPLUG_PCI_CPCI is not set
# CONFIG_HOTPLUG_PCI_SHPC is not set

#
# Executable file formats / Emulations
#
CONFIG_BINFMT_ELF=y
CONFIG_COMPAT_BINFMT_ELF=y
CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS=y
# CONFIG_HAVE_AOUT is not set
CONFIG_BINFMT_MISC=y
CONFIG_IA32_EMULATION=y
# CONFIG_IA32_AOUT is not set
CONFIG_COMPAT=y
CONFIG_COMPAT_FOR_U64_ALIGNMENT=y
CONFIG_SYSVIPC_COMPAT=y
CONFIG_NET=y
CONFIG_COMPAT_NETLINK_MESSAGES=y

#
# Networking options
#
CONFIG_PACKET=y
CONFIG_PACKET_MMAP=y
CONFIG_UNIX=y
CONFIG_XFRM=y
CONFIG_XFRM_USER=y
# CONFIG_XFRM_SUB_POLICY is not set
# CONFIG_XFRM_MIGRATE is not set
# CONFIG_XFRM_STATISTICS is not set
CONFIG_XFRM_IPCOMP=y
CONFIG_NET_KEY=y
# CONFIG_NET_KEY_MIGRATE is not set
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
CONFIG_IP_ADVANCED_ROUTER=y
CONFIG_ASK_IP_FIB_HASH=y
# CONFIG_IP_FIB_TRIE is not set
CONFIG_IP_FIB_HASH=y
CONFIG_IP_MULTIPLE_TABLES=y
CONFIG_IP_ROUTE_MULTIPATH=y
CONFIG_IP_ROUTE_VERBOSE=y
CONFIG_IP_PNP=y
CONFIG_IP_PNP_DHCP=y
CONFIG_IP_PNP_BOOTP=y
CONFIG_IP_PNP_RARP=y
# CONFIG_NET_IPIP is not set
# CONFIG_NET_IPGRE is not set
CONFIG_IP_MROUTE=y
CONFIG_IP_PIMSM_V1=y
CONFIG_IP_PIMSM_V2=y
# CONFIG_ARPD is not set
CONFIG_SYN_COOKIES=y
CONFIG_INET_AH=y
CONFIG_INET_ESP=y
CONFIG_INET_IPCOMP=y
CONFIG_INET_XFRM_TUNNEL=y
CONFIG_INET_TUNNEL=y
CONFIG_INET_XFRM_MODE_TRANSPORT=y
CONFIG_INET_XFRM_MODE_TUNNEL=y
# CONFIG_INET_XFRM_MODE_BEET is not set
CONFIG_INET_LRO=y
# CONFIG_INET_DIAG is not set
CONFIG_TCP_CONG_ADVANCED=y
# CONFIG_TCP_CONG_BIC is not set
CONFIG_TCP_CONG_CUBIC=y
# CONFIG_TCP_CONG_WESTWOOD is not set
# CONFIG_TCP_CONG_HTCP is not set
# CONFIG_TCP_CONG_HSTCP is not set
# CONFIG_TCP_CONG_HYBLA is not set
# CONFIG_TCP_CONG_VEGAS is not set
# CONFIG_TCP_CONG_SCALABLE is not set
# CONFIG_TCP_CONG_LP is not set
# CONFIG_TCP_CONG_VENO is not set
# CONFIG_TCP_CONG_YEAH is not set
# CONFIG_TCP_CONG_ILLINOIS is not set
# CONFIG_DEFAULT_BIC is not set
CONFIG_DEFAULT_CUBIC=y
# CONFIG_DEFAULT_HTCP is not set
# CONFIG_DEFAULT_VEGAS is not set
# CONFIG_DEFAULT_WESTWOOD is not set
# CONFIG_DEFAULT_RENO is not set
CONFIG_DEFAULT_TCP_CONG="cubic"
CONFIG_TCP_MD5SIG=y
CONFIG_IPV6=y
# CONFIG_IPV6_PRIVACY is not set
# CONFIG_IPV6_ROUTER_PREF is not set
# CONFIG_IPV6_OPTIMISTIC_DAD is not set
CONFIG_INET6_AH=y
CONFIG_INET6_ESP=y
# CONFIG_INET6_IPCOMP is not set
# CONFIG_IPV6_MIP6 is not set
# CONFIG_INET6_XFRM_TUNNEL is not set
# CONFIG_INET6_TUNNEL is not set
CONFIG_INET6_XFRM_MODE_TRANSPORT=y
CONFIG_INET6_XFRM_MODE_TUNNEL=y
CONFIG_INET6_XFRM_MODE_BEET=y
# CONFIG_INET6_XFRM_MODE_ROUTEOPTIMIZATION is not set
CONFIG_IPV6_SIT=y
CONFIG_IPV6_NDISC_NODETYPE=y
# CONFIG_IPV6_TUNNEL is not set
# CONFIG_IPV6_MULTIPLE_TABLES is not set
# CONFIG_IPV6_MROUTE is not set
CONFIG_NETLABEL=y
CONFIG_NETWORK_SECMARK=y
CONFIG_NETFILTER=y
# CONFIG_NETFILTER_DEBUG is not set
CONFIG_NETFILTER_ADVANCED=y
CONFIG_BRIDGE_NETFILTER=y

#
# Core Netfilter Configuration
#
CONFIG_NETFILTER_NETLINK=y
# CONFIG_NETFILTER_NETLINK_QUEUE is not set
CONFIG_NETFILTER_NETLINK_LOG=y
CONFIG_NF_CONNTRACK=y
# CONFIG_NF_CT_ACCT is not set
CONFIG_NF_CONNTRACK_MARK=y
CONFIG_NF_CONNTRACK_SECMARK=y
# CONFIG_NF_CONNTRACK_EVENTS is not set
# CONFIG_NF_CT_PROTO_DCCP is not set
CONFIG_NF_CT_PROTO_GRE=y
# CONFIG_NF_CT_PROTO_SCTP is not set
# CONFIG_NF_CT_PROTO_UDPLITE is not set
# CONFIG_NF_CONNTRACK_AMANDA is not set
CONFIG_NF_CONNTRACK_FTP=y
CONFIG_NF_CONNTRACK_H323=y
CONFIG_NF_CONNTRACK_IRC=y
CONFIG_NF_CONNTRACK_NETBIOS_NS=y
CONFIG_NF_CONNTRACK_PPTP=y
# CONFIG_NF_CONNTRACK_SANE is not set
CONFIG_NF_CONNTRACK_SIP=y
CONFIG_NF_CONNTRACK_TFTP=y
CONFIG_NF_CT_NETLINK=y
# CONFIG_NETFILTER_TPROXY is not set
CONFIG_NETFILTER_XTABLES=y
CONFIG_NETFILTER_XT_TARGET_CLASSIFY=y
CONFIG_NETFILTER_XT_TARGET_CONNMARK=y
CONFIG_NETFILTER_XT_TARGET_CONNSECMARK=y
# CONFIG_NETFILTER_XT_TARGET_DSCP is not set
# CONFIG_NETFILTER_XT_TARGET_HL is not set
# CONFIG_NETFILTER_XT_TARGET_LED is not set
CONFIG_NETFILTER_XT_TARGET_MARK=y
CONFIG_NETFILTER_XT_TARGET_NFLOG=y
# CONFIG_NETFILTER_XT_TARGET_NFQUEUE is not set
# CONFIG_NETFILTER_XT_TARGET_RATEEST is not set
CONFIG_NETFILTER_XT_TARGET_SECMARK=y
CONFIG_NETFILTER_XT_TARGET_TCPMSS=y
# CONFIG_NETFILTER_XT_TARGET_TCPOPTSTRIP is not set
# CONFIG_NETFILTER_XT_MATCH_CLUSTER is not set
# CONFIG_NETFILTER_XT_MATCH_COMMENT is not set
# CONFIG_NETFILTER_XT_MATCH_CONNBYTES is not set
CONFIG_NETFILTER_XT_MATCH_CONNLIMIT=y
CONFIG_NETFILTER_XT_MATCH_CONNMARK=y
CONFIG_NETFILTER_XT_MATCH_CONNTRACK=y
# CONFIG_NETFILTER_XT_MATCH_DCCP is not set
# CONFIG_NETFILTER_XT_MATCH_DSCP is not set
CONFIG_NETFILTER_XT_MATCH_ESP=y
# CONFIG_NETFILTER_XT_MATCH_HASHLIMIT is not set
CONFIG_NETFILTER_XT_MATCH_HELPER=y
# CONFIG_NETFILTER_XT_MATCH_HL is not set
CONFIG_NETFILTER_XT_MATCH_IPRANGE=y
# CONFIG_NETFILTER_XT_MATCH_LENGTH is not set
CONFIG_NETFILTER_XT_MATCH_LIMIT=y
CONFIG_NETFILTER_XT_MATCH_MAC=y
CONFIG_NETFILTER_XT_MATCH_MARK=y
CONFIG_NETFILTER_XT_MATCH_MULTIPORT=y
# CONFIG_NETFILTER_XT_MATCH_OWNER is not set
CONFIG_NETFILTER_XT_MATCH_POLICY=y
# CONFIG_NETFILTER_XT_MATCH_PHYSDEV is not set
# CONFIG_NETFILTER_XT_MATCH_PKTTYPE is not set
# CONFIG_NETFILTER_XT_MATCH_QUOTA is not set
# CONFIG_NETFILTER_XT_MATCH_RATEEST is not set
# CONFIG_NETFILTER_XT_MATCH_REALM is not set
CONFIG_NETFILTER_XT_MATCH_RECENT=y
# CONFIG_NETFILTER_XT_MATCH_RECENT_PROC_COMPAT is not set
# CONFIG_NETFILTER_XT_MATCH_SCTP is not set
CONFIG_NETFILTER_XT_MATCH_STATE=y
# CONFIG_NETFILTER_XT_MATCH_STATISTIC is not set
CONFIG_NETFILTER_XT_MATCH_STRING=y
CONFIG_NETFILTER_XT_MATCH_TCPMSS=y
CONFIG_NETFILTER_XT_MATCH_TIME=y
# CONFIG_NETFILTER_XT_MATCH_U32 is not set
# CONFIG_NETFILTER_XT_MATCH_OSF is not set
# CONFIG_IP_VS is not set

#
# IP: Netfilter Configuration
#
CONFIG_NF_DEFRAG_IPV4=y
CONFIG_NF_CONNTRACK_IPV4=y
CONFIG_NF_CONNTRACK_PROC_COMPAT=y
# CONFIG_IP_NF_QUEUE is not set
CONFIG_IP_NF_IPTABLES=y
# CONFIG_IP_NF_MATCH_ADDRTYPE is not set
# CONFIG_IP_NF_MATCH_AH is not set
# CONFIG_IP_NF_MATCH_ECN is not set
# CONFIG_IP_NF_MATCH_TTL is not set
CONFIG_IP_NF_FILTER=y
CONFIG_IP_NF_TARGET_REJECT=y
CONFIG_IP_NF_TARGET_LOG=y
CONFIG_IP_NF_TARGET_ULOG=y
CONFIG_NF_NAT=y
CONFIG_NF_NAT_NEEDED=y
CONFIG_IP_NF_TARGET_MASQUERADE=y
CONFIG_IP_NF_TARGET_NETMAP=y
CONFIG_IP_NF_TARGET_REDIRECT=y
# CONFIG_NF_NAT_SNMP_BASIC is not set
CONFIG_NF_NAT_PROTO_GRE=y
CONFIG_NF_NAT_FTP=y
CONFIG_NF_NAT_IRC=y
CONFIG_NF_NAT_TFTP=y
# CONFIG_NF_NAT_AMANDA is not set
CONFIG_NF_NAT_PPTP=y
CONFIG_NF_NAT_H323=y
CONFIG_NF_NAT_SIP=y
CONFIG_IP_NF_MANGLE=y
# CONFIG_IP_NF_TARGET_CLUSTERIP is not set
# CONFIG_IP_NF_TARGET_ECN is not set
# CONFIG_IP_NF_TARGET_TTL is not set
# CONFIG_IP_NF_RAW is not set
# CONFIG_IP_NF_SECURITY is not set
# CONFIG_IP_NF_ARPTABLES is not set

#
# IPv6: Netfilter Configuration
#
CONFIG_NF_CONNTRACK_IPV6=y
# CONFIG_IP6_NF_QUEUE is not set
CONFIG_IP6_NF_IPTABLES=y
# CONFIG_IP6_NF_MATCH_AH is not set
# CONFIG_IP6_NF_MATCH_EUI64 is not set
# CONFIG_IP6_NF_MATCH_FRAG is not set
# CONFIG_IP6_NF_MATCH_OPTS is not set
# CONFIG_IP6_NF_MATCH_HL is not set
CONFIG_IP6_NF_MATCH_IPV6HEADER=y
# CONFIG_IP6_NF_MATCH_MH is not set
# CONFIG_IP6_NF_MATCH_RT is not set
# CONFIG_IP6_NF_TARGET_HL is not set
CONFIG_IP6_NF_TARGET_LOG=y
CONFIG_IP6_NF_FILTER=y
CONFIG_IP6_NF_TARGET_REJECT=y
CONFIG_IP6_NF_MANGLE=y
# CONFIG_IP6_NF_RAW is not set
# CONFIG_IP6_NF_SECURITY is not set
# CONFIG_BRIDGE_NF_EBTABLES is not set
# CONFIG_IP_DCCP is not set
# CONFIG_IP_SCTP is not set
# CONFIG_RDS is not set
# CONFIG_TIPC is not set
# CONFIG_ATM is not set
CONFIG_STP=y
CONFIG_BRIDGE=y
# CONFIG_NET_DSA is not set
# CONFIG_VLAN_8021Q is not set
# CONFIG_DECNET is not set
CONFIG_LLC=y
# CONFIG_LLC2 is not set
# CONFIG_IPX is not set
# CONFIG_ATALK is not set
# CONFIG_X25 is not set
# CONFIG_LAPB is not set
# CONFIG_ECONET is not set
# CONFIG_WAN_ROUTER is not set
# CONFIG_PHONET is not set
# CONFIG_IEEE802154 is not set
CONFIG_NET_SCHED=y

#
# Queueing/Scheduling
#
# CONFIG_NET_SCH_CBQ is not set
# CONFIG_NET_SCH_HTB is not set
# CONFIG_NET_SCH_HFSC is not set
# CONFIG_NET_SCH_PRIO is not set
# CONFIG_NET_SCH_MULTIQ is not set
# CONFIG_NET_SCH_RED is not set
# CONFIG_NET_SCH_SFQ is not set
# CONFIG_NET_SCH_TEQL is not set
# CONFIG_NET_SCH_TBF is not set
# CONFIG_NET_SCH_GRED is not set
# CONFIG_NET_SCH_DSMARK is not set
# CONFIG_NET_SCH_NETEM is not set
# CONFIG_NET_SCH_DRR is not set
# CONFIG_NET_SCH_INGRESS is not set
# CONFIG_NET_SCH_PLUG is not set

#
# Classification
#
CONFIG_NET_CLS=y
# CONFIG_NET_CLS_BASIC is not set
# CONFIG_NET_CLS_TCINDEX is not set
# CONFIG_NET_CLS_ROUTE4 is not set
# CONFIG_NET_CLS_FW is not set
# CONFIG_NET_CLS_U32 is not set
# CONFIG_NET_CLS_RSVP is not set
# CONFIG_NET_CLS_RSVP6 is not set
# CONFIG_NET_CLS_FLOW is not set
# CONFIG_NET_CLS_CGROUP is not set
CONFIG_NET_EMATCH=y
CONFIG_NET_EMATCH_STACK=32
# CONFIG_NET_EMATCH_CMP is not set
# CONFIG_NET_EMATCH_NBYTE is not set
# CONFIG_NET_EMATCH_U32 is not set
# CONFIG_NET_EMATCH_META is not set
# CONFIG_NET_EMATCH_TEXT is not set
CONFIG_NET_CLS_ACT=y
# CONFIG_NET_ACT_POLICE is not set
# CONFIG_NET_ACT_GACT is not set
# CONFIG_NET_ACT_MIRRED is not set
# CONFIG_NET_ACT_IPT is not set
# CONFIG_NET_ACT_NAT is not set
# CONFIG_NET_ACT_PEDIT is not set
# CONFIG_NET_ACT_SIMP is not set
# CONFIG_NET_ACT_SKBEDIT is not set
CONFIG_NET_SCH_FIFO=y
# CONFIG_DCB is not set

#
# Network testing
#
# CONFIG_NET_PKTGEN is not set
# CONFIG_NET_TCPPROBE is not set
# CONFIG_NET_DROP_MONITOR is not set
CONFIG_HAMRADIO=y

#
# Packet Radio protocols
#
# CONFIG_AX25 is not set
# CONFIG_CAN is not set
# CONFIG_IRDA is not set
# CONFIG_BT is not set
# CONFIG_AF_RXRPC is not set
CONFIG_FIB_RULES=y
CONFIG_WIRELESS=y
CONFIG_CFG80211=y
# CONFIG_NL80211_TESTMODE is not set
# CONFIG_CFG80211_DEVELOPER_WARNINGS is not set
# CONFIG_CFG80211_REG_DEBUG is not set
CONFIG_CFG80211_DEFAULT_PS=y
CONFIG_CFG80211_DEFAULT_PS_VALUE=1
# CONFIG_CFG80211_DEBUGFS is not set
CONFIG_WIRELESS_OLD_REGULATORY=y
CONFIG_WIRELESS_EXT=y
CONFIG_WIRELESS_EXT_SYSFS=y
# CONFIG_LIB80211 is not set
CONFIG_MAC80211=y
CONFIG_MAC80211_HAS_RC=y
CONFIG_MAC80211_RC_MINSTREL=y
# CONFIG_MAC80211_RC_DEFAULT_PID is not set
CONFIG_MAC80211_RC_DEFAULT_MINSTREL=y
CONFIG_MAC80211_RC_DEFAULT="minstrel"
# CONFIG_MAC80211_MESH is not set
CONFIG_MAC80211_LEDS=y
# CONFIG_MAC80211_DEBUGFS is not set
# CONFIG_MAC80211_DEBUG_MENU is not set
# CONFIG_WIMAX is not set
CONFIG_RFKILL=y
CONFIG_RFKILL_LEDS=y
CONFIG_RFKILL_INPUT=y
# CONFIG_NET_9P is not set

#
# Device Drivers
#

#
# Generic Driver Options
#
CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
# CONFIG_DEVTMPFS is not set
CONFIG_STANDALONE=y
CONFIG_PREVENT_FIRMWARE_BUILD=y
CONFIG_FW_LOADER=y
CONFIG_FIRMWARE_IN_KERNEL=y
CONFIG_EXTRA_FIRMWARE=""
# CONFIG_DEBUG_DRIVER is not set
CONFIG_DEBUG_DEVRES=y
CONFIG_SYS_HYPERVISOR=y
CONFIG_CONNECTOR=y
CONFIG_PROC_EVENTS=y
# CONFIG_MTD is not set
# CONFIG_PARPORT is not set
CONFIG_PNP=y
CONFIG_PNP_DEBUG_MESSAGES=y

#
# Protocols
#
CONFIG_PNPACPI=y
CONFIG_BLK_DEV=y
# CONFIG_BLK_DEV_FD is not set
# CONFIG_BLK_CPQ_DA is not set
CONFIG_BLK_CPQ_CISS_DA=m
# CONFIG_CISS_SCSI_TAPE is not set
# CONFIG_BLK_DEV_DAC960 is not set
# CONFIG_BLK_DEV_UMEM is not set
# CONFIG_BLK_DEV_COW_COMMON is not set
CONFIG_BLK_DEV_LOOP=y
# CONFIG_BLK_DEV_CRYPTOLOOP is not set
# CONFIG_BLK_DEV_NBD is not set
# CONFIG_BLK_DEV_SX8 is not set
# CONFIG_BLK_DEV_UB is not set
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_COUNT=16
CONFIG_BLK_DEV_RAM_SIZE=16384
# CONFIG_BLK_DEV_XIP is not set
# CONFIG_CDROM_PKTCDVD is not set
# CONFIG_ATA_OVER_ETH is not set
CONFIG_XEN_BLKDEV_FRONTEND=y
# CONFIG_BLK_DEV_HD is not set
CONFIG_MISC_DEVICES=y
# CONFIG_IBM_ASM is not set
# CONFIG_PHANTOM is not set
# CONFIG_SGI_IOC4 is not set
# CONFIG_TIFM_CORE is not set
# CONFIG_ICS932S401 is not set
# CONFIG_ENCLOSURE_SERVICES is not set
# CONFIG_HP_ILO is not set
# CONFIG_ISL29003 is not set
# CONFIG_C2PORT is not set

#
# EEPROM support
#
# CONFIG_EEPROM_AT24 is not set
# CONFIG_EEPROM_LEGACY is not set
# CONFIG_EEPROM_MAX6875 is not set
# CONFIG_EEPROM_93CX6 is not set
# CONFIG_CB710_CORE is not set
CONFIG_HAVE_IDE=y
# CONFIG_IDE is not set

#
# SCSI device support
#
# CONFIG_RAID_ATTRS is not set
CONFIG_SCSI=y
CONFIG_SCSI_DMA=y
# CONFIG_SCSI_TGT is not set
# CONFIG_SCSI_NETLINK is not set
CONFIG_SCSI_PROC_FS=y

#
# SCSI support type (disk, tape, CD-ROM)
#
CONFIG_BLK_DEV_SD=y
# CONFIG_CHR_DEV_ST is not set
# CONFIG_CHR_DEV_OSST is not set
CONFIG_BLK_DEV_SR=y
CONFIG_BLK_DEV_SR_VENDOR=y
CONFIG_CHR_DEV_SG=y
# CONFIG_CHR_DEV_SCH is not set
# CONFIG_SCSI_MULTI_LUN is not set
CONFIG_SCSI_CONSTANTS=y
# CONFIG_SCSI_LOGGING is not set
# CONFIG_SCSI_SCAN_ASYNC is not set
CONFIG_SCSI_WAIT_SCAN=m

#
# SCSI Transports
#
CONFIG_SCSI_SPI_ATTRS=y
# CONFIG_SCSI_FC_ATTRS is not set
CONFIG_SCSI_ISCSI_ATTRS=m
CONFIG_SCSI_SAS_ATTRS=m
# CONFIG_SCSI_SAS_LIBSAS is not set
# CONFIG_SCSI_SRP_ATTRS is not set
CONFIG_SCSI_LOWLEVEL=y
CONFIG_ISCSI_TCP=m
# CONFIG_SCSI_CXGB3_ISCSI is not set
# CONFIG_SCSI_BNX2_ISCSI is not set
# CONFIG_BE2ISCSI is not set
# CONFIG_BLK_DEV_3W_XXXX_RAID is not set
CONFIG_SCSI_3W_9XXX=y
# CONFIG_SCSI_ACARD is not set
# CONFIG_SCSI_AACRAID is not set
# CONFIG_SCSI_AIC7XXX is not set
# CONFIG_SCSI_AIC7XXX_OLD is not set
# CONFIG_SCSI_AIC79XX is not set
# CONFIG_SCSI_AIC94XX is not set
# CONFIG_SCSI_MVSAS is not set
# CONFIG_SCSI_DPT_I2O is not set
# CONFIG_SCSI_ADVANSYS is not set
# CONFIG_SCSI_ARCMSR is not set
# CONFIG_MEGARAID_NEWGEN is not set
# CONFIG_MEGARAID_LEGACY is not set
# CONFIG_MEGARAID_SAS is not set
# CONFIG_SCSI_MPT2SAS is not set
# CONFIG_SCSI_HPTIOP is not set
# CONFIG_SCSI_BUSLOGIC is not set
# CONFIG_LIBFC is not set
# CONFIG_LIBFCOE is not set
# CONFIG_FCOE is not set
# CONFIG_FCOE_FNIC is not set
# CONFIG_SCSI_DMX3191D is not set
# CONFIG_SCSI_EATA is not set
# CONFIG_SCSI_FUTURE_DOMAIN is not set
# CONFIG_SCSI_GDTH is not set
# CONFIG_SCSI_IPS is not set
# CONFIG_SCSI_INITIO is not set
# CONFIG_SCSI_INIA100 is not set
# CONFIG_SCSI_STEX is not set
# CONFIG_SCSI_SYM53C8XX_2 is not set
# CONFIG_SCSI_IPR is not set
# CONFIG_SCSI_QLOGIC_1280 is not set
# CONFIG_SCSI_QLA_FC is not set
# CONFIG_SCSI_QLA_ISCSI is not set
# CONFIG_SCSI_LPFC is not set
# CONFIG_SCSI_DC395x is not set
# CONFIG_SCSI_DC390T is not set
# CONFIG_SCSI_DEBUG is not set
# CONFIG_SCSI_PMCRAID is not set
# CONFIG_SCSI_SRP is not set
# CONFIG_SCSI_BFA_FC is not set
# CONFIG_SCSI_LOWLEVEL_PCMCIA is not set
# CONFIG_SCSI_DH is not set
# CONFIG_SCSI_OSD_INITIATOR is not set
CONFIG_ATA=y
# CONFIG_ATA_NONSTANDARD is not set
CONFIG_ATA_VERBOSE_ERROR=y
CONFIG_ATA_ACPI=y
CONFIG_SATA_PMP=y
CONFIG_SATA_AHCI=y
# CONFIG_SATA_SIL24 is not set
CONFIG_ATA_SFF=y
# CONFIG_SATA_SVW is not set
CONFIG_ATA_PIIX=y
# CONFIG_SATA_MV is not set
# CONFIG_SATA_NV is not set
# CONFIG_PDC_ADMA is not set
# CONFIG_SATA_QSTOR is not set
# CONFIG_SATA_PROMISE is not set
# CONFIG_SATA_SX4 is not set
# CONFIG_SATA_SIL is not set
# CONFIG_SATA_SIS is not set
# CONFIG_SATA_ULI is not set
# CONFIG_SATA_VIA is not set
# CONFIG_SATA_VITESSE is not set
# CONFIG_SATA_INIC162X is not set
# CONFIG_PATA_ACPI is not set
# CONFIG_PATA_ALI is not set
CONFIG_PATA_AMD=y
# CONFIG_PATA_ARTOP is not set
# CONFIG_PATA_ATP867X is not set
# CONFIG_PATA_ATIIXP is not set
# CONFIG_PATA_CMD640_PCI is not set
# CONFIG_PATA_CMD64X is not set
# CONFIG_PATA_CS5520 is not set
# CONFIG_PATA_CS5530 is not set
# CONFIG_PATA_CYPRESS is not set
# CONFIG_PATA_EFAR is not set
CONFIG_ATA_GENERIC=y
# CONFIG_PATA_HPT366 is not set
# CONFIG_PATA_HPT37X is not set
# CONFIG_PATA_HPT3X2N is not set
# CONFIG_PATA_HPT3X3 is not set
# CONFIG_PATA_IT821X is not set
# CONFIG_PATA_IT8213 is not set
# CONFIG_PATA_JMICRON is not set
# CONFIG_PATA_TRIFLEX is not set
# CONFIG_PATA_MARVELL is not set
CONFIG_PATA_MPIIX=y
CONFIG_PATA_OLDPIIX=y
# CONFIG_PATA_NETCELL is not set
# CONFIG_PATA_NINJA32 is not set
# CONFIG_PATA_NS87410 is not set
# CONFIG_PATA_NS87415 is not set
# CONFIG_PATA_OPTI is not set
# CONFIG_PATA_OPTIDMA is not set
# CONFIG_PATA_PCMCIA is not set
# CONFIG_PATA_PDC_OLD is not set
# CONFIG_PATA_RADISYS is not set
# CONFIG_PATA_RDC is not set
# CONFIG_PATA_RZ1000 is not set
# CONFIG_PATA_SC1200 is not set
# CONFIG_PATA_SERVERWORKS is not set
# CONFIG_PATA_PDC2027X is not set
# CONFIG_PATA_SIL680 is not set
# CONFIG_PATA_SIS is not set
# CONFIG_PATA_VIA is not set
# CONFIG_PATA_WINBOND is not set
CONFIG_PATA_SCH=y
CONFIG_MD=y
CONFIG_BLK_DEV_MD=y
CONFIG_MD_AUTODETECT=y
# CONFIG_MD_LINEAR is not set
# CONFIG_MD_RAID0 is not set
CONFIG_MD_RAID1=m
# CONFIG_MD_RAID10 is not set
# CONFIG_MD_RAID456 is not set
# CONFIG_MD_MULTIPATH is not set
# CONFIG_MD_FAULTY is not set
CONFIG_BLK_DEV_DM=y
# CONFIG_DM_DEBUG is not set
# CONFIG_DM_CRYPT is not set
# CONFIG_DM_SNAPSHOT is not set
CONFIG_DM_MIRROR=y
# CONFIG_DM_LOG_USERSPACE is not set
CONFIG_DM_ZERO=y
# CONFIG_DM_MULTIPATH is not set
# CONFIG_DM_DELAY is not set
# CONFIG_DM_UEVENT is not set
CONFIG_FUSION=y
CONFIG_FUSION_SPI=m
# CONFIG_FUSION_FC is not set
CONFIG_FUSION_SAS=m
CONFIG_FUSION_MAX_SGE=128
# CONFIG_FUSION_CTL is not set
# CONFIG_FUSION_LOGGING is not set

#
# IEEE 1394 (FireWire) support
#

#
# You can enable one or both FireWire driver stacks.
#

#
# See the help texts for more information.
#
# CONFIG_FIREWIRE is not set
# CONFIG_IEEE1394 is not set
# CONFIG_I2O is not set
CONFIG_MACINTOSH_DRIVERS=y
CONFIG_MAC_EMUMOUSEBTN=y
CONFIG_NETDEVICES=y
# CONFIG_IFB is not set
# CONFIG_DUMMY is not set
# CONFIG_BONDING is not set
# CONFIG_MACVLAN is not set
# CONFIG_EQUALIZER is not set
CONFIG_TUN=y
# CONFIG_VETH is not set
# CONFIG_NET_SB1000 is not set
# CONFIG_ARCNET is not set
CONFIG_PHYLIB=y

#
# MII PHY device drivers
#
# CONFIG_MARVELL_PHY is not set
# CONFIG_DAVICOM_PHY is not set
# CONFIG_QSEMI_PHY is not set
# CONFIG_LXT_PHY is not set
# CONFIG_CICADA_PHY is not set
# CONFIG_VITESSE_PHY is not set
# CONFIG_SMSC_PHY is not set
# CONFIG_BROADCOM_PHY is not set
# CONFIG_ICPLUS_PHY is not set
# CONFIG_REALTEK_PHY is not set
# CONFIG_NATIONAL_PHY is not set
# CONFIG_STE10XP is not set
# CONFIG_LSI_ET1011C_PHY is not set
# CONFIG_FIXED_PHY is not set
# CONFIG_MDIO_BITBANG is not set
CONFIG_NET_ETHERNET=y
CONFIG_MII=y
# CONFIG_HAPPYMEAL is not set
# CONFIG_SUNGEM is not set
# CONFIG_CASSINI is not set
CONFIG_NET_VENDOR_3COM=y
# CONFIG_VORTEX is not set
# CONFIG_TYPHOON is not set
# CONFIG_ETHOC is not set
# CONFIG_DNET is not set
CONFIG_NET_TULIP=y
# CONFIG_DE2104X is not set
# CONFIG_TULIP is not set
# CONFIG_DE4X5 is not set
# CONFIG_WINBOND_840 is not set
# CONFIG_DM9102 is not set
# CONFIG_ULI526X is not set
# CONFIG_PCMCIA_XIRCOM is not set
# CONFIG_HP100 is not set
# CONFIG_IBM_NEW_EMAC_ZMII is not set
# CONFIG_IBM_NEW_EMAC_RGMII is not set
# CONFIG_IBM_NEW_EMAC_TAH is not set
# CONFIG_IBM_NEW_EMAC_EMAC4 is not set
# CONFIG_IBM_NEW_EMAC_NO_FLOW_CTRL is not set
# CONFIG_IBM_NEW_EMAC_MAL_CLR_ICINTSTAT is not set
# CONFIG_IBM_NEW_EMAC_MAL_COMMON_ERR is not set
CONFIG_NET_PCI=y
# CONFIG_PCNET32 is not set
# CONFIG_AMD8111_ETH is not set
# CONFIG_ADAPTEC_STARFIRE is not set
# CONFIG_B44 is not set
CONFIG_FORCEDETH=y
# CONFIG_FORCEDETH_NAPI is not set
CONFIG_E100=y
# CONFIG_FEALNX is not set
# CONFIG_NATSEMI is not set
CONFIG_NE2K_PCI=y
# CONFIG_8139CP is not set
CONFIG_8139TOO=y
# CONFIG_8139TOO_PIO is not set
# CONFIG_8139TOO_TUNE_TWISTER is not set
# CONFIG_8139TOO_8129 is not set
# CONFIG_8139_OLD_RX_RESET is not set
# CONFIG_R6040 is not set
# CONFIG_SIS900 is not set
# CONFIG_EPIC100 is not set
# CONFIG_SMSC9420 is not set
# CONFIG_SUNDANCE is not set
# CONFIG_TLAN is not set
# CONFIG_KS8842 is not set
# CONFIG_KS8851_MLL is not set
# CONFIG_VIA_RHINE is not set
# CONFIG_SC92031 is not set
# CONFIG_ATL2 is not set
CONFIG_NETDEV_1000=y
# CONFIG_ACENIC is not set
# CONFIG_DL2K is not set
CONFIG_E1000=y
CONFIG_E1000E=y
# CONFIG_IP1000 is not set
# CONFIG_IGB is not set
# CONFIG_IGBVF is not set
# CONFIG_NS83820 is not set
# CONFIG_HAMACHI is not set
# CONFIG_YELLOWFIN is not set
CONFIG_R8169=y
# CONFIG_SIS190 is not set
# CONFIG_SKGE is not set
CONFIG_SKY2=y
# CONFIG_SKY2_DEBUG is not set
# CONFIG_VIA_VELOCITY is not set
CONFIG_TIGON3=y
CONFIG_BNX2=y
# CONFIG_CNIC is not set
# CONFIG_QLA3XXX is not set
# CONFIG_ATL1 is not set
# CONFIG_ATL1E is not set
# CONFIG_ATL1C is not set
# CONFIG_JME is not set
CONFIG_NETDEV_10000=y
# CONFIG_CHELSIO_T1 is not set
CONFIG_CHELSIO_T3_DEPENDS=y
# CONFIG_CHELSIO_T3 is not set
# CONFIG_ENIC is not set
# CONFIG_IXGBE is not set
# CONFIG_IXGB is not set
# CONFIG_S2IO is not set
# CONFIG_VXGE is not set
# CONFIG_MYRI10GE is not set
# CONFIG_NETXEN_NIC is not set
# CONFIG_NIU is not set
# CONFIG_MLX4_EN is not set
# CONFIG_MLX4_CORE is not set
# CONFIG_TEHUTI is not set
# CONFIG_BNX2X is not set
# CONFIG_QLGE is not set
# CONFIG_SFC is not set
# CONFIG_BE2NET is not set
CONFIG_TR=y
# CONFIG_IBMOL is not set
# CONFIG_3C359 is not set
# CONFIG_TMS380TR is not set
CONFIG_WLAN=y
# CONFIG_WLAN_PRE80211 is not set
CONFIG_WLAN_80211=y
# CONFIG_PCMCIA_RAYCS is not set
# CONFIG_LIBERTAS is not set
# CONFIG_LIBERTAS_THINFIRM is not set
# CONFIG_AIRO is not set
# CONFIG_ATMEL is not set
# CONFIG_AT76C50X_USB is not set
# CONFIG_AIRO_CS is not set
# CONFIG_PCMCIA_WL3501 is not set
# CONFIG_PRISM54 is not set
# CONFIG_USB_ZD1201 is not set
# CONFIG_USB_NET_RNDIS_WLAN is not set
# CONFIG_RTL8180 is not set
# CONFIG_RTL8187 is not set
# CONFIG_ADM8211 is not set
# CONFIG_MAC80211_HWSIM is not set
# CONFIG_MWL8K is not set
# CONFIG_P54_COMMON is not set
# CONFIG_ATH_COMMON is not set
# CONFIG_IPW2100 is not set
# CONFIG_IPW2200 is not set
# CONFIG_IWLWIFI is not set
# CONFIG_HOSTAP is not set
# CONFIG_B43 is not set
# CONFIG_B43LEGACY is not set
# CONFIG_ZD1211RW is not set
# CONFIG_RT2X00 is not set
# CONFIG_HERMES is not set
# CONFIG_WL12XX is not set

#
# Enable WiMAX (Networking options) to see the WiMAX drivers
#

#
# USB Network Adapters
#
# CONFIG_USB_CATC is not set
# CONFIG_USB_KAWETH is not set
# CONFIG_USB_PEGASUS is not set
# CONFIG_USB_RTL8150 is not set
# CONFIG_USB_USBNET is not set
# CONFIG_USB_HSO is not set
CONFIG_NET_PCMCIA=y
# CONFIG_PCMCIA_3C589 is not set
# CONFIG_PCMCIA_3C574 is not set
# CONFIG_PCMCIA_FMVJ18X is not set
# CONFIG_PCMCIA_PCNET is not set
# CONFIG_PCMCIA_NMCLAN is not set
# CONFIG_PCMCIA_SMC91C92 is not set
# CONFIG_PCMCIA_XIRC2PS is not set
# CONFIG_PCMCIA_AXNET is not set
# CONFIG_PCMCIA_IBMTR is not set
# CONFIG_WAN is not set
CONFIG_XEN_NETDEV_FRONTEND=y
CONFIG_FDDI=y
# CONFIG_DEFXX is not set
# CONFIG_SKFP is not set
# CONFIG_HIPPI is not set
CONFIG_PPP=y
# CONFIG_PPP_MULTILINK is not set
# CONFIG_PPP_FILTER is not set
CONFIG_PPP_ASYNC=y
CONFIG_PPP_SYNC_TTY=y
CONFIG_PPP_DEFLATE=y
CONFIG_PPP_BSDCOMP=y
# CONFIG_PPP_MPPE is not set
CONFIG_PPPOE=y
CONFIG_PPPOL2TP=y
# CONFIG_SLIP is not set
CONFIG_SLHC=y
# CONFIG_NET_FC is not set
CONFIG_NETCONSOLE=m
# CONFIG_NETCONSOLE_DYNAMIC is not set
CONFIG_NETPOLL=y
# CONFIG_NETPOLL_TRAP is not set
CONFIG_NET_POLL_CONTROLLER=y
# CONFIG_VMXNET3 is not set
# CONFIG_ISDN is not set
# CONFIG_PHONE is not set

#
# Input device support
#
CONFIG_INPUT=y
CONFIG_INPUT_FF_MEMLESS=y
CONFIG_INPUT_POLLDEV=y

#
# Userland interfaces
#
CONFIG_INPUT_MOUSEDEV=y
# CONFIG_INPUT_MOUSEDEV_PSAUX is not set
CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024
CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768
# CONFIG_INPUT_JOYDEV is not set
CONFIG_INPUT_EVDEV=y
# CONFIG_INPUT_EVBUG is not set
CONFIG_XEN_KBDDEV_FRONTEND=y

#
# Input Device Drivers
#
CONFIG_INPUT_KEYBOARD=y
# CONFIG_KEYBOARD_ADP5588 is not set
CONFIG_KEYBOARD_ATKBD=y
# CONFIG_QT2160 is not set
# CONFIG_KEYBOARD_LKKBD is not set
# CONFIG_KEYBOARD_LM8323 is not set
# CONFIG_KEYBOARD_MAX7359 is not set
# CONFIG_KEYBOARD_NEWTON is not set
# CONFIG_KEYBOARD_OPENCORES is not set
# CONFIG_KEYBOARD_STOWAWAY is not set
# CONFIG_KEYBOARD_SUNKBD is not set
# CONFIG_KEYBOARD_XTKBD is not set
CONFIG_INPUT_MOUSE=y
CONFIG_MOUSE_PS2=y
CONFIG_MOUSE_PS2_ALPS=y
CONFIG_MOUSE_PS2_LOGIPS2PP=y
CONFIG_MOUSE_PS2_SYNAPTICS=y
CONFIG_MOUSE_PS2_LIFEBOOK=y
CONFIG_MOUSE_PS2_TRACKPOINT=y
# CONFIG_MOUSE_PS2_ELANTECH is not set
# CONFIG_MOUSE_PS2_SENTELIC is not set
# CONFIG_MOUSE_PS2_TOUCHKIT is not set
# CONFIG_MOUSE_SERIAL is not set
# CONFIG_MOUSE_APPLETOUCH is not set
# CONFIG_MOUSE_BCM5974 is not set
# CONFIG_MOUSE_VSXXXAA is not set
# CONFIG_MOUSE_SYNAPTICS_I2C is not set
CONFIG_INPUT_JOYSTICK=y
# CONFIG_JOYSTICK_ANALOG is not set
# CONFIG_JOYSTICK_A3D is not set
# CONFIG_JOYSTICK_ADI is not set
# CONFIG_JOYSTICK_COBRA is not set
# CONFIG_JOYSTICK_GF2K is not set
# CONFIG_JOYSTICK_GRIP is not set
# CONFIG_JOYSTICK_GRIP_MP is not set
# CONFIG_JOYSTICK_GUILLEMOT is not set
# CONFIG_JOYSTICK_INTERACT is not set
# CONFIG_JOYSTICK_SIDEWINDER is not set
# CONFIG_JOYSTICK_TMDC is not set
# CONFIG_JOYSTICK_IFORCE is not set
# CONFIG_JOYSTICK_WARRIOR is not set
# CONFIG_JOYSTICK_MAGELLAN is not set
# CONFIG_JOYSTICK_SPACEORB is not set
# CONFIG_JOYSTICK_SPACEBALL is not set
# CONFIG_JOYSTICK_STINGER is not set
# CONFIG_JOYSTICK_TWIDJOY is not set
# CONFIG_JOYSTICK_ZHENHUA is not set
# CONFIG_JOYSTICK_JOYDUMP is not set
# CONFIG_JOYSTICK_XPAD is not set
CONFIG_INPUT_TABLET=y
# CONFIG_TABLET_USB_ACECAD is not set
# CONFIG_TABLET_USB_AIPTEK is not set
# CONFIG_TABLET_USB_GTCO is not set
# CONFIG_TABLET_USB_KBTAB is not set
# CONFIG_TABLET_USB_WACOM is not set
CONFIG_INPUT_TOUCHSCREEN=y
# CONFIG_TOUCHSCREEN_AD7879_I2C is not set
# CONFIG_TOUCHSCREEN_AD7879 is not set
# CONFIG_TOUCHSCREEN_EETI is not set
# CONFIG_TOUCHSCREEN_FUJITSU is not set
# CONFIG_TOUCHSCREEN_GUNZE is not set
# CONFIG_TOUCHSCREEN_ELO is not set
# CONFIG_TOUCHSCREEN_WACOM_W8001 is not set
# CONFIG_TOUCHSCREEN_MCS5000 is not set
# CONFIG_TOUCHSCREEN_MTOUCH is not set
# CONFIG_TOUCHSCREEN_INEXIO is not set
# CONFIG_TOUCHSCREEN_MK712 is not set
# CONFIG_TOUCHSCREEN_PENMOUNT is not set
# CONFIG_TOUCHSCREEN_TOUCHRIGHT is not set
# CONFIG_TOUCHSCREEN_TOUCHWIN is not set
# CONFIG_TOUCHSCREEN_USB_COMPOSITE is not set
# CONFIG_TOUCHSCREEN_TOUCHIT213 is not set
# CONFIG_TOUCHSCREEN_TSC2007 is not set
CONFIG_INPUT_MISC=y
# CONFIG_INPUT_PCSPKR is not set
# CONFIG_INPUT_APANEL is not set
# CONFIG_INPUT_ATLAS_BTNS is not set
# CONFIG_INPUT_ATI_REMOTE is not set
# CONFIG_INPUT_ATI_REMOTE2 is not set
# CONFIG_INPUT_KEYSPAN_REMOTE is not set
# CONFIG_INPUT_POWERMATE is not set
# CONFIG_INPUT_YEALINK is not set
# CONFIG_INPUT_CM109 is not set
# CONFIG_INPUT_UINPUT is not set
# CONFIG_INPUT_WINBOND_CIR is not set

#
# Hardware I/O ports
#
CONFIG_SERIO=y
CONFIG_SERIO_I8042=y
CONFIG_SERIO_SERPORT=y
# CONFIG_SERIO_CT82C710 is not set
# CONFIG_SERIO_PCIPS2 is not set
CONFIG_SERIO_LIBPS2=y
# CONFIG_SERIO_RAW is not set
# CONFIG_GAMEPORT is not set

#
# Character devices
#
CONFIG_VT=y
CONFIG_CONSOLE_TRANSLATIONS=y
CONFIG_VT_CONSOLE=y
CONFIG_HW_CONSOLE=y
CONFIG_VT_HW_CONSOLE_BINDING=y
CONFIG_DEVKMEM=y
CONFIG_SERIAL_NONSTANDARD=y
# CONFIG_COMPUTONE is not set
# CONFIG_ROCKETPORT is not set
# CONFIG_CYCLADES is not set
# CONFIG_DIGIEPCA is not set
# CONFIG_MOXA_INTELLIO is not set
# CONFIG_MOXA_SMARTIO is not set
# CONFIG_ISI is not set
# CONFIG_SYNCLINK is not set
# CONFIG_SYNCLINKMP is not set
# CONFIG_SYNCLINK_GT is not set
# CONFIG_N_HDLC is not set
# CONFIG_RISCOM8 is not set
# CONFIG_SPECIALIX is not set
# CONFIG_STALDRV is not set
# CONFIG_NOZOMI is not set

#
# Serial drivers
#
CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_CONSOLE=y
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_SERIAL_8250_PCI=y
CONFIG_SERIAL_8250_PNP=y
# CONFIG_SERIAL_8250_CS is not set
CONFIG_SERIAL_8250_NR_UARTS=32
CONFIG_SERIAL_8250_RUNTIME_UARTS=4
CONFIG_SERIAL_8250_EXTENDED=y
CONFIG_SERIAL_8250_MANY_PORTS=y
CONFIG_SERIAL_8250_SHARE_IRQ=y
CONFIG_SERIAL_8250_DETECT_IRQ=y
CONFIG_SERIAL_8250_RSA=y

#
# Non-8250 serial port support
#
CONFIG_SERIAL_CORE=y
CONFIG_SERIAL_CORE_CONSOLE=y
# CONFIG_SERIAL_JSM is not set
CONFIG_UNIX98_PTYS=y
# CONFIG_DEVPTS_MULTIPLE_INSTANCES is not set
# CONFIG_LEGACY_PTYS is not set
CONFIG_HVC_DRIVER=y
CONFIG_HVC_IRQ=y
CONFIG_HVC_XEN=y
# CONFIG_IPMI_HANDLER is not set
CONFIG_HW_RANDOM=y
# CONFIG_HW_RANDOM_TIMERIOMEM is not set
CONFIG_HW_RANDOM_INTEL=y
CONFIG_HW_RANDOM_AMD=y
CONFIG_HW_RANDOM_VIA=y
CONFIG_NVRAM=y
# CONFIG_R3964 is not set
# CONFIG_APPLICOM is not set

#
# PCMCIA character devices
#
# CONFIG_SYNCLINK_CS is not set
# CONFIG_CARDMAN_4000 is not set
# CONFIG_CARDMAN_4040 is not set
# CONFIG_IPWIRELESS is not set
# CONFIG_MWAVE is not set
# CONFIG_PC8736x_GPIO is not set
# CONFIG_RAW_DRIVER is not set
CONFIG_HPET=y
# CONFIG_HPET_MMAP is not set
# CONFIG_HANGCHECK_TIMER is not set
# CONFIG_TCG_TPM is not set
# CONFIG_TELCLOCK is not set
CONFIG_DEVPORT=y
CONFIG_I2C=y
CONFIG_I2C_BOARDINFO=y
CONFIG_I2C_COMPAT=y
CONFIG_I2C_CHARDEV=m
CONFIG_I2C_HELPER_AUTO=y
CONFIG_I2C_ALGOBIT=y
CONFIG_I2C_ALGOPCA=m

#
# I2C Hardware Bus support
#

#
# PC SMBus host controller drivers
#
CONFIG_I2C_ALI1535=m
CONFIG_I2C_ALI1563=m
CONFIG_I2C_ALI15X3=m
CONFIG_I2C_AMD756=m
CONFIG_I2C_AMD756_S4882=m
CONFIG_I2C_AMD8111=m
CONFIG_I2C_I801=y
CONFIG_I2C_ISCH=m
CONFIG_I2C_PIIX4=m
CONFIG_I2C_NFORCE2=m
CONFIG_I2C_NFORCE2_S4985=m
CONFIG_I2C_SIS5595=m
CONFIG_I2C_SIS630=m
CONFIG_I2C_SIS96X=m
CONFIG_I2C_VIA=m
CONFIG_I2C_VIAPRO=m

#
# ACPI drivers
#
CONFIG_I2C_SCMI=m

#
# I2C system bus drivers (mostly embedded / system-on-chip)
#
CONFIG_I2C_OCORES=m
CONFIG_I2C_SIMTEC=m

#
# External I2C/SMBus adapter drivers
#
CONFIG_I2C_PARPORT_LIGHT=m
CONFIG_I2C_TAOS_EVM=m
CONFIG_I2C_TINY_USB=m

#
# Graphics adapter I2C/DDC channel drivers
#
CONFIG_I2C_VOODOO3=m

#
# Other I2C/SMBus bus drivers
#
CONFIG_I2C_PCA_PLATFORM=m
CONFIG_I2C_STUB=m

#
# Miscellaneous I2C Chip support
#
CONFIG_DS1682=m
CONFIG_SENSORS_TSL2550=m
# CONFIG_I2C_DEBUG_CORE is not set
# CONFIG_I2C_DEBUG_ALGO is not set
# CONFIG_I2C_DEBUG_BUS is not set
# CONFIG_I2C_DEBUG_CHIP is not set
# CONFIG_SPI is not set

#
# PPS support
#
# CONFIG_PPS is not set
CONFIG_ARCH_WANT_OPTIONAL_GPIOLIB=y
# CONFIG_GPIOLIB is not set
# CONFIG_W1 is not set
CONFIG_POWER_SUPPLY=y
# CONFIG_POWER_SUPPLY_DEBUG is not set
# CONFIG_PDA_POWER is not set
# CONFIG_BATTERY_DS2760 is not set
# CONFIG_BATTERY_DS2782 is not set
# CONFIG_BATTERY_BQ27x00 is not set
# CONFIG_BATTERY_MAX17040 is not set
CONFIG_HWMON=y
# CONFIG_HWMON_VID is not set
# CONFIG_HWMON_DEBUG_CHIP is not set

#
# Native drivers
#
# CONFIG_SENSORS_ABITUGURU is not set
# CONFIG_SENSORS_ABITUGURU3 is not set
# CONFIG_SENSORS_AD7414 is not set
# CONFIG_SENSORS_AD7418 is not set
# CONFIG_SENSORS_ADM1021 is not set
# CONFIG_SENSORS_ADM1025 is not set
# CONFIG_SENSORS_ADM1026 is not set
# CONFIG_SENSORS_ADM1029 is not set
# CONFIG_SENSORS_ADM1031 is not set
# CONFIG_SENSORS_ADM9240 is not set
# CONFIG_SENSORS_ADT7462 is not set
# CONFIG_SENSORS_ADT7470 is not set
# CONFIG_SENSORS_ADT7473 is not set
# CONFIG_SENSORS_ADT7475 is not set
# CONFIG_SENSORS_K8TEMP is not set
# CONFIG_SENSORS_ASB100 is not set
# CONFIG_SENSORS_ATXP1 is not set
# CONFIG_SENSORS_DS1621 is not set
# CONFIG_SENSORS_I5K_AMB is not set
# CONFIG_SENSORS_F71805F is not set
# CONFIG_SENSORS_F71882FG is not set
# CONFIG_SENSORS_F75375S is not set
# CONFIG_SENSORS_FSCHMD is not set
# CONFIG_SENSORS_G760A is not set
# CONFIG_SENSORS_GL518SM is not set
# CONFIG_SENSORS_GL520SM is not set
# CONFIG_SENSORS_CORETEMP is not set
# CONFIG_SENSORS_IT87 is not set
# CONFIG_SENSORS_LM63 is not set
# CONFIG_SENSORS_LM75 is not set
# CONFIG_SENSORS_LM77 is not set
# CONFIG_SENSORS_LM78 is not set
# CONFIG_SENSORS_LM80 is not set
# CONFIG_SENSORS_LM83 is not set
# CONFIG_SENSORS_LM85 is not set
# CONFIG_SENSORS_LM87 is not set
# CONFIG_SENSORS_LM90 is not set
# CONFIG_SENSORS_LM92 is not set
# CONFIG_SENSORS_LM93 is not set
# CONFIG_SENSORS_LTC4215 is not set
# CONFIG_SENSORS_LTC4245 is not set
# CONFIG_SENSORS_LM95241 is not set
# CONFIG_SENSORS_MAX1619 is not set
# CONFIG_SENSORS_MAX6650 is not set
# CONFIG_SENSORS_PC87360 is not set
# CONFIG_SENSORS_PC87427 is not set
# CONFIG_SENSORS_PCF8591 is not set
# CONFIG_SENSORS_SIS5595 is not set
# CONFIG_SENSORS_DME1737 is not set
# CONFIG_SENSORS_SMSC47M1 is not set
# CONFIG_SENSORS_SMSC47M192 is not set
# CONFIG_SENSORS_SMSC47B397 is not set
# CONFIG_SENSORS_ADS7828 is not set
# CONFIG_SENSORS_THMC50 is not set
# CONFIG_SENSORS_TMP401 is not set
# CONFIG_SENSORS_TMP421 is not set
# CONFIG_SENSORS_VIA686A is not set
# CONFIG_SENSORS_VT1211 is not set
# CONFIG_SENSORS_VT8231 is not set
# CONFIG_SENSORS_W83781D is not set
# CONFIG_SENSORS_W83791D is not set
# CONFIG_SENSORS_W83792D is not set
# CONFIG_SENSORS_W83793 is not set
# CONFIG_SENSORS_W83L785TS is not set
# CONFIG_SENSORS_W83L786NG is not set
# CONFIG_SENSORS_W83627HF is not set
# CONFIG_SENSORS_W83627EHF is not set
# CONFIG_SENSORS_HDAPS is not set
# CONFIG_SENSORS_APPLESMC is not set

#
# ACPI drivers
#
# CONFIG_SENSORS_ATK0110 is not set
# CONFIG_SENSORS_LIS3LV02D is not set
CONFIG_THERMAL=y
# CONFIG_THERMAL_HWMON is not set
CONFIG_WATCHDOG=y
# CONFIG_WATCHDOG_NOWAYOUT is not set

#
# Watchdog Device Drivers
#
# CONFIG_SOFT_WATCHDOG is not set
# CONFIG_ACQUIRE_WDT is not set
# CONFIG_ADVANTECH_WDT is not set
# CONFIG_ALIM1535_WDT is not set
# CONFIG_ALIM7101_WDT is not set
# CONFIG_SC520_WDT is not set
# CONFIG_SBC_FITPC2_WATCHDOG is not set
# CONFIG_EUROTECH_WDT is not set
# CONFIG_IB700_WDT is not set
# CONFIG_IBMASR is not set
# CONFIG_WAFER_WDT is not set
# CONFIG_I6300ESB_WDT is not set
# CONFIG_ITCO_WDT is not set
# CONFIG_IT8712F_WDT is not set
# CONFIG_IT87_WDT is not set
# CONFIG_HP_WATCHDOG is not set
# CONFIG_SC1200_WDT is not set
# CONFIG_PC87413_WDT is not set
# CONFIG_60XX_WDT is not set
# CONFIG_SBC8360_WDT is not set
# CONFIG_CPU5_WDT is not set
# CONFIG_SMSC_SCH311X_WDT is not set
# CONFIG_SMSC37B787_WDT is not set
# CONFIG_W83627HF_WDT is not set
# CONFIG_W83697HF_WDT is not set
# CONFIG_W83697UG_WDT is not set
# CONFIG_W83877F_WDT is not set
# CONFIG_W83977F_WDT is not set
# CONFIG_MACHZ_WDT is not set
# CONFIG_SBC_EPX_C3_WATCHDOG is not set
# CONFIG_XEN_WDT is not set

#
# PCI-based Watchdog Cards
#
# CONFIG_PCIPCWATCHDOG is not set
# CONFIG_WDTPCI is not set

#
# USB-based Watchdog Cards
#
# CONFIG_USBPCWATCHDOG is not set
CONFIG_SSB_POSSIBLE=y

#
# Sonics Silicon Backplane
#
# CONFIG_SSB is not set

#
# Multifunction device drivers
#
# CONFIG_MFD_CORE is not set
# CONFIG_MFD_SM501 is not set
# CONFIG_HTC_PASIC3 is not set
# CONFIG_TWL4030_CORE is not set
# CONFIG_MFD_TMIO is not set
# CONFIG_PMIC_DA903X is not set
# CONFIG_MFD_WM8400 is not set
# CONFIG_MFD_WM831X is not set
# CONFIG_MFD_WM8350_I2C is not set
# CONFIG_MFD_PCF50633 is not set
# CONFIG_AB3100_CORE is not set
# CONFIG_REGULATOR is not set
# CONFIG_MEDIA_SUPPORT is not set

#
# Graphics support
#
CONFIG_AGP=y
CONFIG_AGP_AMD64=y
CONFIG_AGP_INTEL=y
# CONFIG_AGP_SIS is not set
# CONFIG_AGP_VIA is not set
CONFIG_VGA_ARB=y
CONFIG_DRM=y
CONFIG_DRM_KMS_HELPER=y
# CONFIG_DRM_TDFX is not set
# CONFIG_DRM_R128 is not set
# CONFIG_DRM_RADEON is not set
# CONFIG_DRM_I810 is not set
# CONFIG_DRM_I830 is not set
CONFIG_DRM_I915=y
# CONFIG_DRM_I915_KMS is not set
# CONFIG_DRM_MGA is not set
# CONFIG_DRM_SIS is not set
# CONFIG_DRM_VIA is not set
# CONFIG_DRM_SAVAGE is not set
# CONFIG_VGASTATE is not set
CONFIG_VIDEO_OUTPUT_CONTROL=y
CONFIG_FB=y
# CONFIG_FIRMWARE_EDID is not set
# CONFIG_FB_DDC is not set
# CONFIG_FB_BOOT_VESA_SUPPORT is not set
CONFIG_FB_CFB_FILLRECT=y
CONFIG_FB_CFB_COPYAREA=y
CONFIG_FB_CFB_IMAGEBLIT=y
# CONFIG_FB_CFB_REV_PIXELS_IN_BYTE is not set
CONFIG_FB_SYS_FILLRECT=y
CONFIG_FB_SYS_COPYAREA=y
CONFIG_FB_SYS_IMAGEBLIT=y
# CONFIG_FB_FOREIGN_ENDIAN is not set
CONFIG_FB_SYS_FOPS=y
CONFIG_FB_DEFERRED_IO=y
# CONFIG_FB_SVGALIB is not set
# CONFIG_FB_MACMODES is not set
# CONFIG_FB_BACKLIGHT is not set
CONFIG_FB_MODE_HELPERS=y
CONFIG_FB_TILEBLITTING=y

#
# Frame buffer hardware drivers
#
# CONFIG_FB_CIRRUS is not set
# CONFIG_FB_PM2 is not set
# CONFIG_FB_CYBER2000 is not set
# CONFIG_FB_ARC is not set
# CONFIG_FB_ASILIANT is not set
# CONFIG_FB_IMSTT is not set
# CONFIG_FB_VGA16 is not set
# CONFIG_FB_UVESA is not set
# CONFIG_FB_VESA is not set
CONFIG_FB_EFI=y
# CONFIG_FB_N411 is not set
# CONFIG_FB_HGA is not set
# CONFIG_FB_S1D13XXX is not set
# CONFIG_FB_NVIDIA is not set
# CONFIG_FB_RIVA is not set
# CONFIG_FB_LE80578 is not set
# CONFIG_FB_MATROX is not set
# CONFIG_FB_RADEON is not set
# CONFIG_FB_ATY128 is not set
# CONFIG_FB_ATY is not set
# CONFIG_FB_S3 is not set
# CONFIG_FB_SAVAGE is not set
# CONFIG_FB_SIS is not set
# CONFIG_FB_VIA is not set
# CONFIG_FB_NEOMAGIC is not set
# CONFIG_FB_KYRO is not set
# CONFIG_FB_3DFX is not set
# CONFIG_FB_VOODOO1 is not set
# CONFIG_FB_VT8623 is not set
# CONFIG_FB_TRIDENT is not set
# CONFIG_FB_ARK is not set
# CONFIG_FB_PM3 is not set
# CONFIG_FB_CARMINE is not set
# CONFIG_FB_GEODE is not set
# CONFIG_FB_VIRTUAL is not set
CONFIG_XEN_FBDEV_FRONTEND=y
# CONFIG_FB_METRONOME is not set
# CONFIG_FB_MB862XX is not set
# CONFIG_FB_BROADSHEET is not set
CONFIG_BACKLIGHT_LCD_SUPPORT=y
# CONFIG_LCD_CLASS_DEVICE is not set
CONFIG_BACKLIGHT_CLASS_DEVICE=y
CONFIG_BACKLIGHT_GENERIC=y
# CONFIG_BACKLIGHT_PROGEAR is not set
# CONFIG_BACKLIGHT_MBP_NVIDIA is not set
# CONFIG_BACKLIGHT_SAHARA is not set

#
# Display device support
#
# CONFIG_DISPLAY_SUPPORT is not set

#
# Console display driver support
#
CONFIG_VGA_CONSOLE=y
CONFIG_VGACON_SOFT_SCROLLBACK=y
CONFIG_VGACON_SOFT_SCROLLBACK_SIZE=64
CONFIG_DUMMY_CONSOLE=y
CONFIG_FRAMEBUFFER_CONSOLE=y
# CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY is not set
# CONFIG_FRAMEBUFFER_CONSOLE_ROTATION is not set
# CONFIG_FONTS is not set
CONFIG_FONT_8x8=y
CONFIG_FONT_8x16=y
CONFIG_LOGO=y
# CONFIG_LOGO_LINUX_MONO is not set
# CONFIG_LOGO_LINUX_VGA16 is not set
CONFIG_LOGO_LINUX_CLUT224=y
CONFIG_SOUND=y
CONFIG_SOUND_OSS_CORE=y
CONFIG_SOUND_OSS_CORE_PRECLAIM=y
CONFIG_SND=y
CONFIG_SND_TIMER=y
CONFIG_SND_PCM=y
CONFIG_SND_HWDEP=y
CONFIG_SND_SEQUENCER=y
CONFIG_SND_SEQ_DUMMY=y
CONFIG_SND_OSSEMUL=y
CONFIG_SND_MIXER_OSS=y
CONFIG_SND_PCM_OSS=y
CONFIG_SND_PCM_OSS_PLUGINS=y
CONFIG_SND_SEQUENCER_OSS=y
CONFIG_SND_HRTIMER=y
CONFIG_SND_SEQ_HRTIMER_DEFAULT=y
CONFIG_SND_DYNAMIC_MINORS=y
CONFIG_SND_SUPPORT_OLD_API=y
CONFIG_SND_VERBOSE_PROCFS=y
# CONFIG_SND_VERBOSE_PRINTK is not set
# CONFIG_SND_DEBUG is not set
CONFIG_SND_VMASTER=y
CONFIG_SND_DMA_SGBUF=y
# CONFIG_SND_RAWMIDI_SEQ is not set
# CONFIG_SND_OPL3_LIB_SEQ is not set
# CONFIG_SND_OPL4_LIB_SEQ is not set
# CONFIG_SND_SBAWE_SEQ is not set
# CONFIG_SND_EMU10K1_SEQ is not set
CONFIG_SND_DRIVERS=y
# CONFIG_SND_PCSP is not set
# CONFIG_SND_DUMMY is not set
# CONFIG_SND_VIRMIDI is not set
# CONFIG_SND_MTPAV is not set
# CONFIG_SND_SERIAL_U16550 is not set
# CONFIG_SND_MPU401 is not set
CONFIG_SND_PCI=y
# CONFIG_SND_AD1889 is not set
# CONFIG_SND_ALS300 is not set
# CONFIG_SND_ALS4000 is not set
# CONFIG_SND_ALI5451 is not set
# CONFIG_SND_ATIIXP is not set
# CONFIG_SND_ATIIXP_MODEM is not set
# CONFIG_SND_AU8810 is not set
# CONFIG_SND_AU8820 is not set
# CONFIG_SND_AU8830 is not set
# CONFIG_SND_AW2 is not set
# CONFIG_SND_AZT3328 is not set
# CONFIG_SND_BT87X is not set
# CONFIG_SND_CA0106 is not set
# CONFIG_SND_CMIPCI is not set
# CONFIG_SND_OXYGEN is not set
# CONFIG_SND_CS4281 is not set
# CONFIG_SND_CS46XX is not set
# CONFIG_SND_CS5530 is not set
# CONFIG_SND_CS5535AUDIO is not set
# CONFIG_SND_CTXFI is not set
# CONFIG_SND_DARLA20 is not set
# CONFIG_SND_GINA20 is not set
# CONFIG_SND_LAYLA20 is not set
# CONFIG_SND_DARLA24 is not set
# CONFIG_SND_GINA24 is not set
# CONFIG_SND_LAYLA24 is not set
# CONFIG_SND_MONA is not set
# CONFIG_SND_MIA is not set
# CONFIG_SND_ECHO3G is not set
# CONFIG_SND_INDIGO is not set
# CONFIG_SND_INDIGOIO is not set
# CONFIG_SND_INDIGODJ is not set
# CONFIG_SND_INDIGOIOX is not set
# CONFIG_SND_INDIGODJX is not set
# CONFIG_SND_EMU10K1 is not set
# CONFIG_SND_EMU10K1X is not set
# CONFIG_SND_ENS1370 is not set
# CONFIG_SND_ENS1371 is not set
# CONFIG_SND_ES1938 is not set
# CONFIG_SND_ES1968 is not set
# CONFIG_SND_FM801 is not set
CONFIG_SND_HDA_INTEL=y
CONFIG_SND_HDA_HWDEP=y
# CONFIG_SND_HDA_RECONFIG is not set
# CONFIG_SND_HDA_INPUT_BEEP is not set
# CONFIG_SND_HDA_INPUT_JACK is not set
# CONFIG_SND_HDA_PATCH_LOADER is not set
CONFIG_SND_HDA_CODEC_REALTEK=y
CONFIG_SND_HDA_CODEC_ANALOG=y
CONFIG_SND_HDA_CODEC_SIGMATEL=y
CONFIG_SND_HDA_CODEC_VIA=y
CONFIG_SND_HDA_CODEC_ATIHDMI=y
CONFIG_SND_HDA_CODEC_NVHDMI=y
CONFIG_SND_HDA_CODEC_INTELHDMI=y
CONFIG_SND_HDA_ELD=y
CONFIG_SND_HDA_CODEC_CIRRUS=y
CONFIG_SND_HDA_CODEC_CONEXANT=y
CONFIG_SND_HDA_CODEC_CA0110=y
CONFIG_SND_HDA_CODEC_CMEDIA=y
CONFIG_SND_HDA_CODEC_SI3054=y
CONFIG_SND_HDA_GENERIC=y
# CONFIG_SND_HDA_POWER_SAVE is not set
# CONFIG_SND_HDSP is not set
# CONFIG_SND_HDSPM is not set
# CONFIG_SND_HIFIER is not set
# CONFIG_SND_ICE1712 is not set
# CONFIG_SND_ICE1724 is not set
# CONFIG_SND_INTEL8X0 is not set
# CONFIG_SND_INTEL8X0M is not set
# CONFIG_SND_KORG1212 is not set
# CONFIG_SND_LX6464ES is not set
# CONFIG_SND_MAESTRO3 is not set
# CONFIG_SND_MIXART is not set
# CONFIG_SND_NM256 is not set
# CONFIG_SND_PCXHR is not set
# CONFIG_SND_RIPTIDE is not set
# CONFIG_SND_RME32 is not set
# CONFIG_SND_RME96 is not set
# CONFIG_SND_RME9652 is not set
# CONFIG_SND_SONICVIBES is not set
# CONFIG_SND_TRIDENT is not set
# CONFIG_SND_VIA82XX is not set
# CONFIG_SND_VIA82XX_MODEM is not set
# CONFIG_SND_VIRTUOSO is not set
# CONFIG_SND_VX222 is not set
# CONFIG_SND_YMFPCI is not set
CONFIG_SND_USB=y
# CONFIG_SND_USB_AUDIO is not set
# CONFIG_SND_USB_USX2Y is not set
# CONFIG_SND_USB_CAIAQ is not set
# CONFIG_SND_USB_US122L is not set
CONFIG_SND_PCMCIA=y
# CONFIG_SND_VXPOCKET is not set
# CONFIG_SND_PDAUDIOCF is not set
# CONFIG_SND_SOC is not set
# CONFIG_SOUND_PRIME is not set
CONFIG_HID_SUPPORT=y
CONFIG_HID=y
CONFIG_HIDRAW=y

#
# USB Input Devices
#
CONFIG_USB_HID=y
CONFIG_HID_PID=y
CONFIG_USB_HIDDEV=y

#
# Special HID drivers
#
CONFIG_HID_A4TECH=y
CONFIG_HID_APPLE=y
CONFIG_HID_BELKIN=y
CONFIG_HID_CHERRY=y
CONFIG_HID_CHICONY=y
CONFIG_HID_CYPRESS=y
CONFIG_HID_DRAGONRISE=y
# CONFIG_DRAGONRISE_FF is not set
CONFIG_HID_EZKEY=y
CONFIG_HID_KYE=y
CONFIG_HID_GYRATION=y
CONFIG_HID_TWINHAN=y
CONFIG_HID_KENSINGTON=y
CONFIG_HID_LOGITECH=y
CONFIG_LOGITECH_FF=y
# CONFIG_LOGIRUMBLEPAD2_FF is not set
CONFIG_HID_MICROSOFT=y
CONFIG_HID_MONTEREY=y
CONFIG_HID_NTRIG=y
CONFIG_HID_PANTHERLORD=y
CONFIG_PANTHERLORD_FF=y
CONFIG_HID_PETALYNX=y
CONFIG_HID_SAMSUNG=y
CONFIG_HID_SONY=y
CONFIG_HID_SUNPLUS=y
CONFIG_HID_GREENASIA=y
# CONFIG_GREENASIA_FF is not set
CONFIG_HID_SMARTJOYPLUS=y
# CONFIG_SMARTJOYPLUS_FF is not set
CONFIG_HID_TOPSEED=y
CONFIG_HID_THRUSTMASTER=y
CONFIG_THRUSTMASTER_FF=y
CONFIG_HID_ZEROPLUS=y
CONFIG_ZEROPLUS_FF=y
CONFIG_USB_SUPPORT=y
CONFIG_USB_ARCH_HAS_HCD=y
CONFIG_USB_ARCH_HAS_OHCI=y
CONFIG_USB_ARCH_HAS_EHCI=y
CONFIG_USB=y
CONFIG_USB_DEBUG=y
CONFIG_USB_ANNOUNCE_NEW_DEVICES=y

#
# Miscellaneous USB options
#
CONFIG_USB_DEVICEFS=y
# CONFIG_USB_DEVICE_CLASS is not set
# CONFIG_USB_DYNAMIC_MINORS is not set
CONFIG_USB_SUSPEND=y
# CONFIG_USB_OTG is not set
CONFIG_USB_MON=y
# CONFIG_USB_WUSB is not set
# CONFIG_USB_WUSB_CBAF is not set

#
# USB Host Controller Drivers
#
# CONFIG_USB_C67X00_HCD is not set
# CONFIG_USB_XHCI_HCD is not set
CONFIG_USB_EHCI_HCD=y
# CONFIG_USB_EHCI_ROOT_HUB_TT is not set
# CONFIG_USB_EHCI_TT_NEWSCHED is not set
# CONFIG_USB_OXU210HP_HCD is not set
# CONFIG_USB_ISP116X_HCD is not set
# CONFIG_USB_ISP1760_HCD is not set
# CONFIG_USB_ISP1362_HCD is not set
CONFIG_USB_OHCI_HCD=y
# CONFIG_USB_OHCI_BIG_ENDIAN_DESC is not set
# CONFIG_USB_OHCI_BIG_ENDIAN_MMIO is not set
CONFIG_USB_OHCI_LITTLE_ENDIAN=y
CONFIG_USB_UHCI_HCD=y
# CONFIG_USB_SL811_HCD is not set
# CONFIG_USB_R8A66597_HCD is not set
# CONFIG_USB_WHCI_HCD is not set
# CONFIG_USB_HWA_HCD is not set

#
# USB Device Class drivers
#
# CONFIG_USB_ACM is not set
CONFIG_USB_PRINTER=y
# CONFIG_USB_WDM is not set
# CONFIG_USB_TMC is not set

#
# NOTE: USB_STORAGE depends on SCSI but BLK_DEV_SD may
#

#
# also be needed; see USB_STORAGE Help for more info
#
CONFIG_USB_STORAGE=y
# CONFIG_USB_STORAGE_DEBUG is not set
# CONFIG_USB_STORAGE_DATAFAB is not set
# CONFIG_USB_STORAGE_FREECOM is not set
# CONFIG_USB_STORAGE_ISD200 is not set
# CONFIG_USB_STORAGE_USBAT is not set
# CONFIG_USB_STORAGE_SDDR09 is not set
# CONFIG_USB_STORAGE_SDDR55 is not set
# CONFIG_USB_STORAGE_JUMPSHOT is not set
# CONFIG_USB_STORAGE_ALAUDA is not set
# CONFIG_USB_STORAGE_ONETOUCH is not set
# CONFIG_USB_STORAGE_KARMA is not set
# CONFIG_USB_STORAGE_CYPRESS_ATACB is not set
CONFIG_USB_LIBUSUAL=y

#
# USB Imaging devices
#
# CONFIG_USB_MDC800 is not set
# CONFIG_USB_MICROTEK is not set

#
# USB port drivers
#
# CONFIG_USB_SERIAL is not set

#
# USB Miscellaneous drivers
#
# CONFIG_USB_EMI62 is not set
# CONFIG_USB_EMI26 is not set
# CONFIG_USB_ADUTUX is not set
# CONFIG_USB_SEVSEG is not set
# CONFIG_USB_RIO500 is not set
# CONFIG_USB_LEGOTOWER is not set
# CONFIG_USB_LCD is not set
# CONFIG_USB_BERRY_CHARGE is not set
# CONFIG_USB_LED is not set
# CONFIG_USB_CYPRESS_CY7C63 is not set
# CONFIG_USB_CYTHERM is not set
# CONFIG_USB_IDMOUSE is not set
# CONFIG_USB_FTDI_ELAN is not set
# CONFIG_USB_APPLEDISPLAY is not set
# CONFIG_USB_SISUSBVGA is not set
# CONFIG_USB_LD is not set
# CONFIG_USB_TRANCEVIBRATOR is not set
# CONFIG_USB_IOWARRIOR is not set
# CONFIG_USB_TEST is not set
# CONFIG_USB_ISIGHTFW is not set
# CONFIG_USB_VST is not set
# CONFIG_USB_GADGET is not set

#
# OTG and related infrastructure
#
# CONFIG_NOP_USB_XCEIV is not set
# CONFIG_UWB is not set
# CONFIG_MMC is not set
# CONFIG_MEMSTICK is not set
CONFIG_NEW_LEDS=y
CONFIG_LEDS_CLASS=y

#
# LED drivers
#
# CONFIG_LEDS_ALIX2 is not set
# CONFIG_LEDS_PCA9532 is not set
# CONFIG_LEDS_LP3944 is not set
# CONFIG_LEDS_CLEVO_MAIL is not set
# CONFIG_LEDS_PCA955X is not set
# CONFIG_LEDS_BD2802 is not set

#
# LED Triggers
#
CONFIG_LEDS_TRIGGERS=y
# CONFIG_LEDS_TRIGGER_TIMER is not set
# CONFIG_LEDS_TRIGGER_HEARTBEAT is not set
# CONFIG_LEDS_TRIGGER_BACKLIGHT is not set
# CONFIG_LEDS_TRIGGER_DEFAULT_ON is not set

#
# iptables trigger is under Netfilter config (LED target)
#
# CONFIG_ACCESSIBILITY is not set
# CONFIG_INFINIBAND is not set
CONFIG_EDAC=y

#
# Reporting subsystems
#
# CONFIG_EDAC_DEBUG is not set
CONFIG_EDAC_DECODE_MCE=y
# CONFIG_EDAC_MM_EDAC is not set
CONFIG_RTC_LIB=y
CONFIG_RTC_CLASS=y
# CONFIG_RTC_HCTOSYS is not set
# CONFIG_RTC_DEBUG is not set

#
# RTC interfaces
#
CONFIG_RTC_INTF_SYSFS=y
CONFIG_RTC_INTF_PROC=y
CONFIG_RTC_INTF_DEV=y
# CONFIG_RTC_INTF_DEV_UIE_EMUL is not set
# CONFIG_RTC_DRV_TEST is not set

#
# I2C RTC drivers
#
# CONFIG_RTC_DRV_DS1307 is not set
# CONFIG_RTC_DRV_DS1374 is not set
# CONFIG_RTC_DRV_DS1672 is not set
# CONFIG_RTC_DRV_MAX6900 is not set
# CONFIG_RTC_DRV_RS5C372 is not set
# CONFIG_RTC_DRV_ISL1208 is not set
# CONFIG_RTC_DRV_X1205 is not set
# CONFIG_RTC_DRV_PCF8563 is not set
# CONFIG_RTC_DRV_PCF8583 is not set
# CONFIG_RTC_DRV_M41T80 is not set
# CONFIG_RTC_DRV_S35390A is not set
# CONFIG_RTC_DRV_FM3130 is not set
# CONFIG_RTC_DRV_RX8581 is not set
# CONFIG_RTC_DRV_RX8025 is not set

#
# SPI RTC drivers
#

#
# Platform RTC drivers
#
CONFIG_RTC_DRV_CMOS=y
# CONFIG_RTC_DRV_DS1286 is not set
# CONFIG_RTC_DRV_DS1511 is not set
# CONFIG_RTC_DRV_DS1553 is not set
# CONFIG_RTC_DRV_DS1742 is not set
# CONFIG_RTC_DRV_STK17TA8 is not set
# CONFIG_RTC_DRV_M48T86 is not set
# CONFIG_RTC_DRV_M48T35 is not set
# CONFIG_RTC_DRV_M48T59 is not set
# CONFIG_RTC_DRV_BQ4802 is not set
# CONFIG_RTC_DRV_V3020 is not set

#
# on-CPU RTC drivers
#
CONFIG_DMADEVICES=y

#
# DMA Devices
#
# CONFIG_INTEL_IOATDMA is not set
# CONFIG_AUXDISPLAY is not set
# CONFIG_UIO is not set

#
# TI VLYNQ
#
CONFIG_XEN_BALLOON=y
CONFIG_XEN_SCRUB_PAGES=y
CONFIG_XEN_DEV_EVTCHN=y
CONFIG_XEN_BACKEND=y
CONFIG_XEN_NETDEV_BACKEND=y
CONFIG_XEN_BLKDEV_BACKEND=y
CONFIG_XEN_BLKDEV_TAP=y
CONFIG_XEN_BLKBACK_PAGEMAP=y
CONFIG_XEN_PCIDEV_BACKEND=y
CONFIG_XEN_PCIDEV_BACKEND_VPCI=y
# CONFIG_XEN_PCIDEV_BACKEND_PASS is not set
# CONFIG_XEN_PCIDEV_BACKEND_SLOT is not set
# CONFIG_XEN_PCIDEV_BACKEND_CONTROLLER is not set
# CONFIG_XEN_PCIDEV_BE_DEBUG is not set
CONFIG_XENFS=y
CONFIG_XEN_COMPAT_XENFS=y
CONFIG_XEN_SYS_HYPERVISOR=y
CONFIG_XEN_XENBUS_FRONTEND=y
CONFIG_XEN_GNTDEV=y
CONFIG_XEN_S3=y
CONFIG_ACPI_PROCESSOR_XEN=y
CONFIG_XEN_PLATFORM_PCI=m
# CONFIG_STAGING is not set
CONFIG_X86_PLATFORM_DEVICES=y
# CONFIG_ACER_WMI is not set
# CONFIG_ASUS_LAPTOP is not set
# CONFIG_FUJITSU_LAPTOP is not set
# CONFIG_MSI_LAPTOP is not set
# CONFIG_PANASONIC_LAPTOP is not set
# CONFIG_COMPAL_LAPTOP is not set
# CONFIG_SONY_LAPTOP is not set
# CONFIG_THINKPAD_ACPI is not set
# CONFIG_INTEL_MENLOW is not set
CONFIG_EEEPC_LAPTOP=y
# CONFIG_ACPI_WMI is not set
# CONFIG_ACPI_ASUS is not set
# CONFIG_TOPSTAR_LAPTOP is not set
# CONFIG_ACPI_TOSHIBA is not set

#
# Firmware Drivers
#
# CONFIG_EDD is not set
CONFIG_FIRMWARE_MEMMAP=y
CONFIG_EFI_VARS=y
# CONFIG_DELL_RBU is not set
# CONFIG_DCDBAS is not set
CONFIG_DMIID=y
# CONFIG_ISCSI_IBFT_FIND is not set

#
# File systems
#
# CONFIG_EXT2_FS is not set
CONFIG_EXT3_FS=y
# CONFIG_EXT3_DEFAULTS_TO_ORDERED is not set
CONFIG_EXT3_FS_XATTR=y
CONFIG_EXT3_FS_POSIX_ACL=y
CONFIG_EXT3_FS_SECURITY=y
# CONFIG_EXT4_FS is not set
CONFIG_JBD=y
# CONFIG_JBD_DEBUG is not set
CONFIG_FS_MBCACHE=y
# CONFIG_REISERFS_FS is not set
# CONFIG_JFS_FS is not set
CONFIG_FS_POSIX_ACL=y
# CONFIG_XFS_FS is not set
# CONFIG_GFS2_FS is not set
# CONFIG_OCFS2_FS is not set
# CONFIG_BTRFS_FS is not set
# CONFIG_NILFS2_FS is not set
CONFIG_FILE_LOCKING=y
CONFIG_FSNOTIFY=y
CONFIG_DNOTIFY=y
CONFIG_INOTIFY=y
CONFIG_INOTIFY_USER=y
CONFIG_QUOTA=y
CONFIG_QUOTA_NETLINK_INTERFACE=y
# CONFIG_PRINT_QUOTA_WARNING is not set
CONFIG_QUOTA_TREE=y
# CONFIG_QFMT_V1 is not set
CONFIG_QFMT_V2=y
CONFIG_QUOTACTL=y
# CONFIG_AUTOFS_FS is not set
CONFIG_AUTOFS4_FS=y
# CONFIG_FUSE_FS is not set
CONFIG_GENERIC_ACL=y

#
# Caches
#
# CONFIG_FSCACHE is not set

#
# CD-ROM/DVD Filesystems
#
CONFIG_ISO9660_FS=y
CONFIG_JOLIET=y
CONFIG_ZISOFS=y
# CONFIG_UDF_FS is not set

#
# DOS/FAT/NT Filesystems
#
CONFIG_FAT_FS=y
CONFIG_MSDOS_FS=y
CONFIG_VFAT_FS=y
CONFIG_FAT_DEFAULT_CODEPAGE=437
CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1"
# CONFIG_NTFS_FS is not set

#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
CONFIG_PROC_KCORE=y
CONFIG_PROC_VMCORE=y
CONFIG_PROC_SYSCTL=y
CONFIG_PROC_PAGE_MONITOR=y
CONFIG_SYSFS=y
CONFIG_TMPFS=y
CONFIG_TMPFS_POSIX_ACL=y
CONFIG_HUGETLBFS=y
CONFIG_HUGETLB_PAGE=y
# CONFIG_CONFIGFS_FS is not set
CONFIG_MISC_FILESYSTEMS=y
# CONFIG_ADFS_FS is not set
# CONFIG_AFFS_FS is not set
# CONFIG_ECRYPT_FS is not set
# CONFIG_HFS_FS is not set
# CONFIG_HFSPLUS_FS is not set
# CONFIG_BEFS_FS is not set
# CONFIG_BFS_FS is not set
# CONFIG_EFS_FS is not set
# CONFIG_CRAMFS is not set
# CONFIG_SQUASHFS is not set
# CONFIG_VXFS_FS is not set
# CONFIG_MINIX_FS is not set
# CONFIG_OMFS_FS is not set
# CONFIG_HPFS_FS is not set
# CONFIG_QNX4FS_FS is not set
# CONFIG_ROMFS_FS is not set
# CONFIG_SYSV_FS is not set
# CONFIG_UFS_FS is not set
CONFIG_NETWORK_FILESYSTEMS=y
CONFIG_NFS_FS=y
CONFIG_NFS_V3=y
CONFIG_NFS_V3_ACL=y
CONFIG_NFS_V4=y
# CONFIG_NFS_V4_1 is not set
CONFIG_ROOT_NFS=y
CONFIG_NFSD=m
CONFIG_NFSD_V2_ACL=y
CONFIG_NFSD_V3=y
CONFIG_NFSD_V3_ACL=y
CONFIG_NFSD_V4=y
CONFIG_LOCKD=y
CONFIG_LOCKD_V4=y
CONFIG_EXPORTFS=m
CONFIG_NFS_ACL_SUPPORT=y
CONFIG_NFS_COMMON=y
CONFIG_SUNRPC=y
CONFIG_SUNRPC_GSS=y
CONFIG_RPCSEC_GSS_KRB5=y
# CONFIG_RPCSEC_GSS_SPKM3 is not set
# CONFIG_SMB_FS is not set
CONFIG_CIFS=m
# CONFIG_CIFS_STATS is not set
CONFIG_CIFS_WEAK_PW_HASH=y
CONFIG_CIFS_UPCALL=y
CONFIG_CIFS_XATTR=y
CONFIG_CIFS_POSIX=y
# CONFIG_CIFS_DEBUG2 is not set
# CONFIG_CIFS_DFS_UPCALL is not set
# CONFIG_CIFS_EXPERIMENTAL is not set
# CONFIG_NCP_FS is not set
# CONFIG_CODA_FS is not set
# CONFIG_AFS_FS is not set

#
# Partition Types
#
CONFIG_PARTITION_ADVANCED=y
# CONFIG_ACORN_PARTITION is not set
CONFIG_OSF_PARTITION=y
CONFIG_AMIGA_PARTITION=y
# CONFIG_ATARI_PARTITION is not set
CONFIG_MAC_PARTITION=y
CONFIG_MSDOS_PARTITION=y
CONFIG_BSD_DISKLABEL=y
CONFIG_MINIX_SUBPARTITION=y
CONFIG_SOLARIS_X86_PARTITION=y
CONFIG_UNIXWARE_DISKLABEL=y
# CONFIG_LDM_PARTITION is not set
CONFIG_SGI_PARTITION=y
# CONFIG_ULTRIX_PARTITION is not set
CONFIG_SUN_PARTITION=y
CONFIG_KARMA_PARTITION=y
CONFIG_EFI_PARTITION=y
# CONFIG_SYSV68_PARTITION is not set
CONFIG_NLS=y
CONFIG_NLS_DEFAULT="utf8"
CONFIG_NLS_CODEPAGE_437=y
# CONFIG_NLS_CODEPAGE_737 is not set
# CONFIG_NLS_CODEPAGE_775 is not set
# CONFIG_NLS_CODEPAGE_850 is not set
# CONFIG_NLS_CODEPAGE_852 is not set
# CONFIG_NLS_CODEPAGE_855 is not set
# CONFIG_NLS_CODEPAGE_857 is not set
# CONFIG_NLS_CODEPAGE_860 is not set
# CONFIG_NLS_CODEPAGE_861 is not set
# CONFIG_NLS_CODEPAGE_862 is not set
# CONFIG_NLS_CODEPAGE_863 is not set
# CONFIG_NLS_CODEPAGE_864 is not set
# CONFIG_NLS_CODEPAGE_865 is not set
# CONFIG_NLS_CODEPAGE_866 is not set
# CONFIG_NLS_CODEPAGE_869 is not set
# CONFIG_NLS_CODEPAGE_936 is not set
# CONFIG_NLS_CODEPAGE_950 is not set
# CONFIG_NLS_CODEPAGE_932 is not set
# CONFIG_NLS_CODEPAGE_949 is not set
# CONFIG_NLS_CODEPAGE_874 is not set
# CONFIG_NLS_ISO8859_8 is not set
# CONFIG_NLS_CODEPAGE_1250 is not set
# CONFIG_NLS_CODEPAGE_1251 is not set
CONFIG_NLS_ASCII=y
CONFIG_NLS_ISO8859_1=y
# CONFIG_NLS_ISO8859_2 is not set
# CONFIG_NLS_ISO8859_3 is not set
# CONFIG_NLS_ISO8859_4 is not set
# CONFIG_NLS_ISO8859_5 is not set
# CONFIG_NLS_ISO8859_6 is not set
# CONFIG_NLS_ISO8859_7 is not set
# CONFIG_NLS_ISO8859_9 is not set
# CONFIG_NLS_ISO8859_13 is not set
# CONFIG_NLS_ISO8859_14 is not set
# CONFIG_NLS_ISO8859_15 is not set
# CONFIG_NLS_KOI8_R is not set
# CONFIG_NLS_KOI8_U is not set
CONFIG_NLS_UTF8=y
# CONFIG_DLM is not set

#
# Kernel hacking
#
CONFIG_TRACE_IRQFLAGS_SUPPORT=y
CONFIG_PRINTK_TIME=y
# CONFIG_ENABLE_WARN_DEPRECATED is not set
CONFIG_ENABLE_MUST_CHECK=y
CONFIG_FRAME_WARN=2048
CONFIG_MAGIC_SYSRQ=y
# CONFIG_STRIP_ASM_SYMS is not set
# CONFIG_UNUSED_SYMBOLS is not set
CONFIG_DEBUG_FS=y
# CONFIG_HEADERS_CHECK is not set
CONFIG_DEBUG_KERNEL=y
# CONFIG_DEBUG_SHIRQ is not set
# CONFIG_DETECT_SOFTLOCKUP is not set
# CONFIG_DETECT_HUNG_TASK is not set
# CONFIG_SCHED_DEBUG is not set
CONFIG_SCHEDSTATS=y
CONFIG_TIMER_STATS=y
# CONFIG_DEBUG_OBJECTS is not set
# CONFIG_SLUB_DEBUG_ON is not set
# CONFIG_SLUB_STATS is not set
# CONFIG_DEBUG_KMEMLEAK is not set
# CONFIG_DEBUG_RT_MUTEXES is not set
# CONFIG_RT_MUTEX_TESTER is not set
# CONFIG_DEBUG_SPINLOCK is not set
# CONFIG_DEBUG_MUTEXES is not set
# CONFIG_DEBUG_LOCK_ALLOC is not set
# CONFIG_PROVE_LOCKING is not set
# CONFIG_LOCK_STAT is not set
# CONFIG_DEBUG_SPINLOCK_SLEEP is not set
# CONFIG_DEBUG_LOCKING_API_SELFTESTS is not set
CONFIG_STACKTRACE=y
# CONFIG_DEBUG_KOBJECT is not set
CONFIG_DEBUG_BUGVERBOSE=y
# CONFIG_DEBUG_INFO is not set
# CONFIG_DEBUG_VM is not set
# CONFIG_DEBUG_VIRTUAL is not set
# CONFIG_DEBUG_WRITECOUNT is not set
CONFIG_DEBUG_MEMORY_INIT=y
# CONFIG_DEBUG_LIST is not set
# CONFIG_DEBUG_SG is not set
# CONFIG_DEBUG_NOTIFIERS is not set
# CONFIG_DEBUG_CREDENTIALS is not set
CONFIG_ARCH_WANT_FRAME_POINTERS=y
CONFIG_FRAME_POINTER=y
# CONFIG_BOOT_PRINTK_DELAY is not set
# CONFIG_RCU_TORTURE_TEST is not set
# CONFIG_RCU_CPU_STALL_DETECTOR is not set
# CONFIG_KPROBES_SANITY_TEST is not set
# CONFIG_BACKTRACE_SELF_TEST is not set
# CONFIG_DEBUG_BLOCK_EXT_DEVT is not set
# CONFIG_DEBUG_FORCE_WEAK_PER_CPU is not set
# CONFIG_LKDTM is not set
# CONFIG_FAULT_INJECTION is not set
# CONFIG_LATENCYTOP is not set
CONFIG_SYSCTL_SYSCALL_CHECK=y
# CONFIG_DEBUG_PAGEALLOC is not set
CONFIG_USER_STACKTRACE_SUPPORT=y
CONFIG_NOP_TRACER=y
CONFIG_HAVE_FUNCTION_TRACER=y
CONFIG_HAVE_FUNCTION_GRAPH_TRACER=y
CONFIG_HAVE_FUNCTION_GRAPH_FP_TEST=y
CONFIG_HAVE_FUNCTION_TRACE_MCOUNT_TEST=y
CONFIG_HAVE_DYNAMIC_FTRACE=y
CONFIG_HAVE_FTRACE_MCOUNT_RECORD=y
CONFIG_HAVE_SYSCALL_TRACEPOINTS=y
CONFIG_RING_BUFFER=y
CONFIG_EVENT_TRACING=y
CONFIG_CONTEXT_SWITCH_TRACER=y
CONFIG_TRACING=y
CONFIG_GENERIC_TRACER=y
CONFIG_TRACING_SUPPORT=y
CONFIG_FTRACE=y
# CONFIG_FUNCTION_TRACER is not set
# CONFIG_IRQSOFF_TRACER is not set
# CONFIG_SYSPROF_TRACER is not set
# CONFIG_SCHED_TRACER is not set
# CONFIG_FTRACE_SYSCALLS is not set
# CONFIG_BOOT_TRACER is not set
CONFIG_BRANCH_PROFILE_NONE=y
# CONFIG_PROFILE_ANNOTATED_BRANCHES is not set
# CONFIG_PROFILE_ALL_BRANCHES is not set
# CONFIG_POWER_TRACER is not set
# CONFIG_STACK_TRACER is not set
# CONFIG_KMEMTRACE is not set
# CONFIG_WORKQUEUE_TRACER is not set
CONFIG_BLK_DEV_IO_TRACE=y
# CONFIG_FTRACE_STARTUP_TEST is not set
# CONFIG_MMIOTRACE is not set
# CONFIG_RING_BUFFER_BENCHMARK is not set
CONFIG_PROVIDE_OHCI1394_DMA_INIT=y
# CONFIG_DYNAMIC_DEBUG is not set
# CONFIG_DMA_API_DEBUG is not set
# CONFIG_SAMPLES is not set
CONFIG_HAVE_ARCH_KGDB=y
# CONFIG_KGDB is not set
CONFIG_HAVE_ARCH_KMEMCHECK=y
# CONFIG_STRICT_DEVMEM is not set
CONFIG_X86_VERBOSE_BOOTUP=y
CONFIG_EARLY_PRINTK=y
CONFIG_EARLY_PRINTK_DBGP=y
CONFIG_DEBUG_STACKOVERFLOW=y
# CONFIG_DEBUG_STACK_USAGE is not set
# CONFIG_DEBUG_PER_CPU_MAPS is not set
# CONFIG_X86_PTDUMP is not set
CONFIG_DEBUG_RODATA=y
# CONFIG_DEBUG_RODATA_TEST is not set
CONFIG_DEBUG_NX_TEST=m
# CONFIG_IOMMU_DEBUG is not set
# CONFIG_IOMMU_STRESS is not set
CONFIG_HAVE_MMIOTRACE_SUPPORT=y
CONFIG_IO_DELAY_TYPE_0X80=0
CONFIG_IO_DELAY_TYPE_0XED=1
CONFIG_IO_DELAY_TYPE_UDELAY=2
CONFIG_IO_DELAY_TYPE_NONE=3
CONFIG_IO_DELAY_0X80=y
# CONFIG_IO_DELAY_0XED is not set
# CONFIG_IO_DELAY_UDELAY is not set
# CONFIG_IO_DELAY_NONE is not set
CONFIG_DEFAULT_IO_DELAY_TYPE=0
CONFIG_DEBUG_BOOT_PARAMS=y
# CONFIG_CPA_DEBUG is not set
CONFIG_OPTIMIZE_INLINING=y

#
# Security options
#
CONFIG_KEYS=y
CONFIG_KEYS_DEBUG_PROC_KEYS=y
CONFIG_SECURITY=y
# CONFIG_SECURITYFS is not set
CONFIG_SECURITY_NETWORK=y
# CONFIG_SECURITY_NETWORK_XFRM is not set
# CONFIG_SECURITY_PATH is not set
CONFIG_SECURITY_FILE_CAPABILITIES=y
# CONFIG_SECURITY_ROOTPLUG is not set
CONFIG_LSM_MMAP_MIN_ADDR=65536
CONFIG_SECURITY_SELINUX=y
CONFIG_SECURITY_SELINUX_BOOTPARAM=y
CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE=1
CONFIG_SECURITY_SELINUX_DISABLE=y
CONFIG_SECURITY_SELINUX_DEVELOP=y
CONFIG_SECURITY_SELINUX_AVC_STATS=y
CONFIG_SECURITY_SELINUX_CHECKREQPROT_VALUE=1
# CONFIG_SECURITY_SELINUX_POLICYDB_VERSION_MAX is not set
# CONFIG_SECURITY_SMACK is not set
# CONFIG_SECURITY_TOMOYO is not set
# CONFIG_IMA is not set
CONFIG_CRYPTO=y

#
# Crypto core or helper
#
CONFIG_CRYPTO_ALGAPI=y
CONFIG_CRYPTO_ALGAPI2=y
CONFIG_CRYPTO_AEAD=y
CONFIG_CRYPTO_AEAD2=y
CONFIG_CRYPTO_BLKCIPHER=y
CONFIG_CRYPTO_BLKCIPHER2=y
CONFIG_CRYPTO_HASH=y
CONFIG_CRYPTO_HASH2=y
CONFIG_CRYPTO_RNG2=y
CONFIG_CRYPTO_PCOMP=y
CONFIG_CRYPTO_MANAGER=y
CONFIG_CRYPTO_MANAGER2=y
# CONFIG_CRYPTO_GF128MUL is not set
CONFIG_CRYPTO_NULL=y
CONFIG_CRYPTO_WORKQUEUE=y
# CONFIG_CRYPTO_CRYPTD is not set
CONFIG_CRYPTO_AUTHENC=y
# CONFIG_CRYPTO_TEST is not set

#
# Authenticated Encryption with Associated Data
#
# CONFIG_CRYPTO_CCM is not set
# CONFIG_CRYPTO_GCM is not set
# CONFIG_CRYPTO_SEQIV is not set

#
# Block modes
#
CONFIG_CRYPTO_CBC=y
# CONFIG_CRYPTO_CTR is not set
# CONFIG_CRYPTO_CTS is not set
CONFIG_CRYPTO_ECB=y
# CONFIG_CRYPTO_LRW is not set
# CONFIG_CRYPTO_PCBC is not set
# CONFIG_CRYPTO_XTS is not set

#
# Hash modes
#
CONFIG_CRYPTO_HMAC=y
# CONFIG_CRYPTO_XCBC is not set
# CONFIG_CRYPTO_VMAC is not set

#
# Digest
#
CONFIG_CRYPTO_CRC32C=y
# CONFIG_CRYPTO_CRC32C_INTEL is not set
# CONFIG_CRYPTO_GHASH is not set
# CONFIG_CRYPTO_MD4 is not set
CONFIG_CRYPTO_MD5=y
# CONFIG_CRYPTO_MICHAEL_MIC is not set
# CONFIG_CRYPTO_RMD128 is not set
# CONFIG_CRYPTO_RMD160 is not set
# CONFIG_CRYPTO_RMD256 is not set
# CONFIG_CRYPTO_RMD320 is not set
CONFIG_CRYPTO_SHA1=y
# CONFIG_CRYPTO_SHA256 is not set
# CONFIG_CRYPTO_SHA512 is not set
# CONFIG_CRYPTO_TGR192 is not set
# CONFIG_CRYPTO_WP512 is not set

#
# Ciphers
#
CONFIG_CRYPTO_AES=y
# CONFIG_CRYPTO_AES_X86_64 is not set
# CONFIG_CRYPTO_AES_NI_INTEL is not set
# CONFIG_CRYPTO_ANUBIS is not set
CONFIG_CRYPTO_ARC4=y
# CONFIG_CRYPTO_BLOWFISH is not set
# CONFIG_CRYPTO_CAMELLIA is not set
# CONFIG_CRYPTO_CAST5 is not set
# CONFIG_CRYPTO_CAST6 is not set
CONFIG_CRYPTO_DES=y
# CONFIG_CRYPTO_FCRYPT is not set
# CONFIG_CRYPTO_KHAZAD is not set
# CONFIG_CRYPTO_SALSA20 is not set
# CONFIG_CRYPTO_SALSA20_X86_64 is not set
# CONFIG_CRYPTO_SEED is not set
# CONFIG_CRYPTO_SERPENT is not set
# CONFIG_CRYPTO_TEA is not set
# CONFIG_CRYPTO_TWOFISH is not set
# CONFIG_CRYPTO_TWOFISH_X86_64 is not set

#
# Compression
#
CONFIG_CRYPTO_DEFLATE=y
CONFIG_CRYPTO_ZLIB=y
CONFIG_CRYPTO_LZO=y

#
# Random Number Generation
#
# CONFIG_CRYPTO_ANSI_CPRNG is not set
CONFIG_CRYPTO_HW=y
# CONFIG_CRYPTO_DEV_PADLOCK is not set
# CONFIG_CRYPTO_DEV_HIFN_795X is not set
CONFIG_HAVE_KVM=y
CONFIG_HAVE_KVM_IRQCHIP=y
CONFIG_HAVE_KVM_EVENTFD=y
CONFIG_KVM_APIC_ARCHITECTURE=y
CONFIG_VIRTUALIZATION=y
CONFIG_KVM=y
CONFIG_KVM_INTEL=y
CONFIG_KVM_AMD=y
# CONFIG_VIRTIO_PCI is not set
# CONFIG_VIRTIO_BALLOON is not set
CONFIG_BINARY_PRINTF=y

#
# Library routines
#
CONFIG_BITREVERSE=y
CONFIG_GENERIC_FIND_FIRST_BIT=y
CONFIG_GENERIC_FIND_NEXT_BIT=y
CONFIG_GENERIC_FIND_LAST_BIT=y
CONFIG_CRC_CCITT=y
# CONFIG_CRC16 is not set
CONFIG_CRC_T10DIF=y
# CONFIG_CRC_ITU_T is not set
CONFIG_CRC32=y
# CONFIG_CRC7 is not set
# CONFIG_LIBCRC32C is not set
CONFIG_ZLIB_INFLATE=y
CONFIG_ZLIB_DEFLATE=y
CONFIG_LZO_COMPRESS=y
CONFIG_LZO_DECOMPRESS=y
CONFIG_DECOMPRESS_GZIP=y
CONFIG_DECOMPRESS_BZIP2=y
CONFIG_DECOMPRESS_LZMA=y
CONFIG_TEXTSEARCH=y
CONFIG_TEXTSEARCH_KMP=y
CONFIG_TEXTSEARCH_BM=y
CONFIG_TEXTSEARCH_FSM=y
CONFIG_HAS_IOMEM=y
CONFIG_HAS_IOPORT=y
CONFIG_HAS_DMA=y
CONFIG_NLATTR=y

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

From xen-devel-bounces@lists.xensource.com Fri Dec 02 19:24:15 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 19:24:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWYhr-0002t0-9c; Fri, 02 Dec 2011 19:23:35 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <quartex73@gmail.com>) id 1RWYhp-0002sv-3q
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 19:23:33 +0000
X-Env-Sender: quartex73@gmail.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1322853731!45227328!1
X-Originating-IP: [209.85.213.171]
X-SpamReason: No, hits=1.0 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,UPPERCASE_50_75,spamassassin: 
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7471 invoked from network); 2 Dec 2011 19:22:12 -0000
Received: from mail-yx0-f171.google.com (HELO mail-yx0-f171.google.com)
	(209.85.213.171)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Dec 2011 19:22:12 -0000
Received: by yenr9 with SMTP id r9so31546431yen.30
	for <xen-devel@lists.xensource.com>;
	Fri, 02 Dec 2011 11:22:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:content-type; bh=RXNxx1PvvwnAfefquqmNx1XFfkd44871k5B5/yYWNEg=;
	b=ga5j0DLFosYLDK7Nb405pm62KELlVzEoxdyAkdHr/77Nq5KK/J8DbQye6MTuLUOnZm
	+sei2jmQ7jrO2WQC2rl2eqB5UB6t1tGT6MXVX92M5x6CScbXXsy7VtYyzq/68S/EVskS
	bmR8QBvka8h7gwKXwlYj2PFAClGrXBbGK86Fw=
MIME-Version: 1.0
Received: by 10.236.190.40 with SMTP id d28mr21366128yhn.92.1322853767052;
	Fri, 02 Dec 2011 11:22:47 -0800 (PST)
Received: by 10.147.146.14 with HTTP; Fri, 2 Dec 2011 11:22:46 -0800 (PST)
In-Reply-To: <CAMhBqqiLc1994GUKtA7UY52pR29nktmFy+XiwTwpZb_E+fwFRQ@mail.gmail.com>
References: <CAMhBqqiLc1994GUKtA7UY52pR29nktmFy+XiwTwpZb_E+fwFRQ@mail.gmail.com>
Date: Fri, 2 Dec 2011 20:22:46 +0100
Message-ID: <CAMhBqqgu6v8NB-X0dNdfrzd12=Y2i==fYCCC2Z+MkDupqqKAOg@mail.gmail.com>
From: Quartexx <quartex73@gmail.com>
To: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] xen 4.0.1 w/2.6.32.47 hangs at boot
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

### lspci

00:00.0 Host bridge: Intel Corporation Core Processor DMI (rev 11)
	Subsystem: Intel Corporation Device 0000
	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-
	Capabilities: [40] #00 [0000]

00:05.0 PCI bridge: Intel Corporation Core Processor PCI Express Root
Port 3 (rev 11) (prog-if 00 [Normal decode])
	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
	Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
	I/O behind bridge: 00002000-00002fff
	Memory behind bridge: b3a00000-b3afffff
	Prefetchable memory behind bridge: 00000000b0000000-00000000b1ffffff
	Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- <SERR- <PERR-
	BridgeCtl: Parity+ SERR+ NoISA- VGA- MAbort- >Reset- FastB2B-
		PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
	Capabilities: [40] Subsystem: Intel Corporation Device 0000
	Capabilities: [60] MSI: Enable+ Count=1/2 Maskable+ 64bit-
		Address: fee0100c  Data: 4139
		Masking: 00000002  Pending: 00000000
	Capabilities: [90] Express (v2) Root Port (Slot+), MSI 00
		DevCap:	MaxPayload 256 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us
			ExtTag+ RBE+ FLReset-
		DevCtl:	Report errors: Correctable+ Non-Fatal+ Fatal+ Unsupported+
			RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
			MaxPayload 128 bytes, MaxReadReq 128 bytes
		DevSta:	CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend-
		LnkCap:	Port #5, Speed 5GT/s, Width x8, ASPM unknown, Latency L0
<512ns, L1 <4us
			ClockPM- Surprise+ LLActRep+ BwNot+
		LnkCtl:	ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk-
			ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
		LnkSta:	Speed 2.5GT/s, Width x8, TrErr- Train- SlotClk+ DLActive+
BWMgmt- ABWMgmt-
		SltCap:	AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug- Surprise-
			Slot #21, PowerLimit 0.000W; Interlock- NoCompl-
		SltCtl:	Enable: AttnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq- LinkChg-
			Control: AttnInd Off, PwrInd Off, Power- Interlock-
		SltSta:	Status: AttnBtn- PowerFlt- MRL- CmdCplt- PresDet- Interlock-
			Changed: MRL- PresDet- LinkState-
		RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna- CRSVisible-
		RootCap: CRSVisible-
		RootSta: PME ReqID 0000, PMEStatus- PMEPending-
		DevCap2: Completion Timeout: Range BCD, TimeoutDis+ ARIFwd+
		DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis- ARIFwd-
		LnkCtl2: Target Link Speed: 5GT/s, EnterCompliance- SpeedDis-,
Selectable De-emphasis: -3.5dB
			 Transmit Margin: Normal Operating Range, EnterModifiedCompliance-
ComplianceSOS-
			 Compliance De-emphasis: -6dB
		LnkSta2: Current De-emphasis Level: -6dB
	Capabilities: [e0] Power Management version 3
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
		Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
	Capabilities: [100 v1] Advanced Error Reporting
		UESta:	DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF-
MalfTLP- ECRC- UnsupReq- ACSViol-
		UEMsk:	DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF-
MalfTLP- ECRC- UnsupReq+ ACSViol-
		UESvrt:	DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+
MalfTLP+ ECRC- UnsupReq- ACSViol-
		CESta:	RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr-
		CEMsk:	RxErr+ BadTLP+ BadDLLP+ Rollover+ Timeout+ NonFatalErr+
		AERCap:	First Error Pointer: 00, GenCap- CGenEn- ChkCap- ChkEn-
	Capabilities: [150 v1] Access Control Services
		ACSCap:	SrcValid+ TransBlk+ ReqRedir+ CmpltRedir+ UpstreamFwd+
EgressCtrl- DirectTrans-
		ACSCtl:	SrcValid- TransBlk- ReqRedir- CmpltRedir- UpstreamFwd-
EgressCtrl- DirectTrans-
	Kernel driver in use: pcieport

00:08.0 System peripheral: Intel Corporation Core Processor System
Management Registers (rev 11)
	Subsystem: Device 0086:00ec
	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-
	Capabilities: [40] Express (v2) Root Complex Integrated Endpoint, MSI 00
		DevCap:	MaxPayload 128 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us
			ExtTag- RBE+ FLReset-
		DevCtl:	Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
			RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
			MaxPayload 128 bytes, MaxReadReq 128 bytes
		DevSta:	CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend-
		LnkCap:	Port #0, Speed unknown, Width x0, ASPM L0s, Latency L0
unlimited, L1 unlimited
			ClockPM- Surprise+ LLActRep+ BwNot+
		LnkCtl:	ASPM Disabled; Disabled- Retrain- CommClk-
			ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
		LnkSta:	Speed unknown, Width x0, TrErr- Train- SlotClk+ DLActive-
BWMgmt- ABWMgmt-
		DevCap2: Completion Timeout: Not Supported, TimeoutDis-
		DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-
		LnkCtl2: Target Link Speed: 2.5GT/s, EnterCompliance- SpeedDis-,
Selectable De-emphasis: -6dB
			 Transmit Margin: Normal Operating Range, EnterModifiedCompliance-
ComplianceSOS-
			 Compliance De-emphasis: -6dB
		LnkSta2: Current De-emphasis Level: -6dB
	Capabilities: [100 v0] Vendor Specific Information: ID=0000 Rev=0 Len=000 <?>

00:08.1 System peripheral: Intel Corporation Core Processor Semaphore
and Scratchpad Registers (rev 11)
	Subsystem: Device 0086:00ec
	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-
	Capabilities: [40] Express (v2) Root Complex Integrated Endpoint, MSI 00
		DevCap:	MaxPayload 128 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us
			ExtTag- RBE+ FLReset-
		DevCtl:	Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
			RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
			MaxPayload 128 bytes, MaxReadReq 128 bytes
		DevSta:	CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend-
		LnkCap:	Port #0, Speed unknown, Width x0, ASPM L0s, Latency L0
unlimited, L1 unlimited
			ClockPM- Surprise+ LLActRep+ BwNot+
		LnkCtl:	ASPM Disabled; Disabled- Retrain- CommClk-
			ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
		LnkSta:	Speed unknown, Width x0, TrErr- Train- SlotClk+ DLActive-
BWMgmt- ABWMgmt-
		DevCap2: Completion Timeout: Not Supported, TimeoutDis-
		DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-
		LnkCtl2: Target Link Speed: 2.5GT/s, EnterCompliance- SpeedDis-,
Selectable De-emphasis: -6dB
			 Transmit Margin: Normal Operating Range, EnterModifiedCompliance-
ComplianceSOS-
			 Compliance De-emphasis: -6dB
		LnkSta2: Current De-emphasis Level: -6dB
	Capabilities: [100 v0] Vendor Specific Information: ID=0000 Rev=0 Len=000 <?>

00:08.2 System peripheral: Intel Corporation Core Processor System
Control and Status Registers (rev 11)
	Subsystem: Device 0086:00ec
	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-
	Capabilities: [40] Express (v2) Root Complex Integrated Endpoint, MSI 00
		DevCap:	MaxPayload 128 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us
			ExtTag- RBE+ FLReset-
		DevCtl:	Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
			RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
			MaxPayload 128 bytes, MaxReadReq 128 bytes
		DevSta:	CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend-
		LnkCap:	Port #0, Speed unknown, Width x0, ASPM L0s, Latency L0
unlimited, L1 unlimited
			ClockPM- Surprise+ LLActRep+ BwNot+
		LnkCtl:	ASPM Disabled; Disabled- Retrain- CommClk-
			ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
		LnkSta:	Speed unknown, Width x0, TrErr- Train- SlotClk+ DLActive-
BWMgmt- ABWMgmt-
		DevCap2: Completion Timeout: Not Supported, TimeoutDis-
		DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-
		LnkCtl2: Target Link Speed: 2.5GT/s, EnterCompliance- SpeedDis-,
Selectable De-emphasis: -6dB
			 Transmit Margin: Normal Operating Range, EnterModifiedCompliance-
ComplianceSOS-
			 Compliance De-emphasis: -6dB
		LnkSta2: Current De-emphasis Level: -6dB
	Capabilities: [100 v0] Vendor Specific Information: ID=0000 Rev=0 Len=000 <?>

00:08.3 System peripheral: Intel Corporation Core Processor
Miscellaneous Registers (rev 11)
	Subsystem: Device 0086:00ec
	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-

00:10.0 System peripheral: Intel Corporation Core Processor QPI Link (rev 11)
	Subsystem: Device 0086:00ec
	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-

00:10.1 System peripheral: Intel Corporation Core Processor QPI
Routing and Protocol Registers (rev 11)
	Subsystem: Device 0086:00ec
	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-

00:19.0 Ethernet controller: Intel Corporation 82578DM Gigabit Network
Connection (rev 05)
	Subsystem: Intel Corporation Device 34ec
	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 1251
	Region 0: Memory at b3b00000 (32-bit, non-prefetchable) [size=128K]
	Region 1: Memory at b3b24000 (32-bit, non-prefetchable) [size=4K]
	Region 2: I/O ports at 3020 [size=32]
	Capabilities: [c8] Power Management version 2
		Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
		Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=1 PME-
	Capabilities: [d0] MSI: Enable+ Count=1/1 Maskable- 64bit+
		Address: 00000000fee0100c  Data: 41b1
	Capabilities: [e0] PCI Advanced Features
		AFCap: TP+ FLR+
		AFCtrl: FLR-
		AFStatus: TP-
	Kernel driver in use: e1000e

00:1a.0 USB Controller: Intel Corporation 5 Series/3400 Series Chipset
USB2 Enhanced Host Controller (rev 05) (prog-if 20 [EHCI])
	Subsystem: Intel Corporation Device 34ec
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+
Stepping- SERR+ FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0
	Interrupt: pin A routed to IRQ 21
	Region 0: Memory at b3b21000 (32-bit, non-prefetchable) [size=1K]
	Capabilities: [50] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
		Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
	Capabilities: [58] Debug port: BAR=1 offset=00a0
	Capabilities: [98] PCI Advanced Features
		AFCap: TP+ FLR+
		AFCtrl: FLR-
		AFStatus: TP-
	Kernel driver in use: ehci_hcd

00:1c.0 PCI bridge: Intel Corporation 5 Series/3400 Series Chipset PCI
Express Root Port 1 (rev 05) (prog-if 00 [Normal decode])
	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
	Bus: primary=00, secondary=02, subordinate=02, sec-latency=0
	I/O behind bridge: 0000f000-00000fff
	Memory behind bridge: fff00000-000fffff
	Prefetchable memory behind bridge: 00000000fff00000-00000000000fffff
	Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort+ <SERR- <PERR-
	BridgeCtl: Parity+ SERR+ NoISA- VGA- MAbort- >Reset- FastB2B-
		PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
	Capabilities: [40] Express (v2) Root Port (Slot+), MSI 00
		DevCap:	MaxPayload 128 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us
			ExtTag- RBE+ FLReset-
		DevCtl:	Report errors: Correctable+ Non-Fatal+ Fatal+ Unsupported-
			RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
			MaxPayload 128 bytes, MaxReadReq 128 bytes
		DevSta:	CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend-
		LnkCap:	Port #1, Speed 2.5GT/s, Width x4, ASPM L0s L1, Latency L0
<1us, L1 <4us
			ClockPM- Surprise- LLActRep+ BwNot-
		LnkCtl:	ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk-
			ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
		LnkSta:	Speed 2.5GT/s, Width x0, TrErr- Train- SlotClk+ DLActive-
BWMgmt- ABWMgmt-
		SltCap:	AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug- Surprise+
			Slot #0, PowerLimit 25.000W; Interlock- NoCompl+
		SltCtl:	Enable: AttnBtn- PwrFlt- MRL- PresDet+ CmdCplt- HPIrq- LinkChg-
			Control: AttnInd Unknown, PwrInd Unknown, Power- Interlock-
		SltSta:	Status: AttnBtn- PowerFlt- MRL- CmdCplt- PresDet+ Interlock-
			Changed: MRL- PresDet- LinkState-
		RootCtl: ErrCorrectable+ ErrNon-Fatal+ ErrFatal+ PMEIntEna- CRSVisible-
		RootCap: CRSVisible-
		RootSta: PME ReqID 0000, PMEStatus- PMEPending-
		DevCap2: Completion Timeout: Range BC, TimeoutDis+ ARIFwd-
		DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis- ARIFwd-
		LnkCtl2: Target Link Speed: 2.5GT/s, EnterCompliance- SpeedDis-,
Selectable De-emphasis: -6dB
			 Transmit Margin: Normal Operating Range, EnterModifiedCompliance-
ComplianceSOS-
			 Compliance De-emphasis: -6dB
		LnkSta2: Current De-emphasis Level: -6dB
	Capabilities: [80] MSI: Enable+ Count=1/1 Maskable- 64bit-
		Address: fee0100c  Data: 4141
	Capabilities: [90] Subsystem: Intel Corporation Device 34ec
	Capabilities: [a0] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
		Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
	Kernel driver in use: pcieport

00:1c.4 PCI bridge: Intel Corporation 5 Series/3400 Series Chipset PCI
Express Root Port 5 (rev 05) (prog-if 00 [Normal decode])
	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
	Bus: primary=00, secondary=03, subordinate=03, sec-latency=0
	I/O behind bridge: 00001000-00001fff
	Memory behind bridge: b3900000-b39fffff
	Prefetchable memory behind bridge: 00000000fff00000-00000000000fffff
	Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- <SERR- <PERR-
	BridgeCtl: Parity+ SERR+ NoISA- VGA- MAbort- >Reset- FastB2B-
		PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
	Capabilities: [40] Express (v2) Root Port (Slot-), MSI 00
		DevCap:	MaxPayload 128 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us
			ExtTag- RBE+ FLReset-
		DevCtl:	Report errors: Correctable+ Non-Fatal+ Fatal+ Unsupported-
			RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
			MaxPayload 128 bytes, MaxReadReq 128 bytes
		DevSta:	CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend-
		LnkCap:	Port #5, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency L0
<256ns, L1 <4us
			ClockPM- Surprise- LLActRep+ BwNot-
		LnkCtl:	ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+
			ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
		LnkSta:	Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive+
BWMgmt- ABWMgmt-
		RootCtl: ErrCorrectable+ ErrNon-Fatal+ ErrFatal+ PMEIntEna- CRSVisible-
		RootCap: CRSVisible-
		RootSta: PME ReqID 0000, PMEStatus- PMEPending-
		DevCap2: Completion Timeout: Range BC, TimeoutDis+ ARIFwd-
		DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis- ARIFwd-
		LnkCtl2: Target Link Speed: 2.5GT/s, EnterCompliance- SpeedDis-,
Selectable De-emphasis: -6dB
			 Transmit Margin: Normal Operating Range, EnterModifiedCompliance-
ComplianceSOS-
			 Compliance De-emphasis: -6dB
		LnkSta2: Current De-emphasis Level: -6dB
	Capabilities: [80] MSI: Enable+ Count=1/1 Maskable- 64bit-
		Address: fee0100c  Data: 4149
	Capabilities: [90] Subsystem: Intel Corporation Device 34ec
	Capabilities: [a0] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
		Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
	Kernel driver in use: pcieport

00:1c.6 PCI bridge: Intel Corporation 5 Series/3400 Series Chipset PCI
Express Root Port 7 (rev 05) (prog-if 00 [Normal decode])
	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
	Bus: primary=00, secondary=04, subordinate=04, sec-latency=0
	I/O behind bridge: 0000f000-00000fff
	Memory behind bridge: b3000000-b38fffff
	Prefetchable memory behind bridge: 00000000b2000000-00000000b2ffffff
	Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort+ <MAbort- <SERR- <PERR-
	BridgeCtl: Parity- SERR- NoISA- VGA+ MAbort- >Reset- FastB2B-
		PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
	Capabilities: [40] Express (v2) Root Port (Slot-), MSI 00
		DevCap:	MaxPayload 128 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us
			ExtTag- RBE+ FLReset-
		DevCtl:	Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
			RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
			MaxPayload 128 bytes, MaxReadReq 128 bytes
		DevSta:	CorrErr- UncorrErr+ FatalErr- UnsuppReq- AuxPwr+ TransPend-
		LnkCap:	Port #7, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency L0
<256ns, L1 <4us
			ClockPM- Surprise- LLActRep+ BwNot-
		LnkCtl:	ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+
			ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
		LnkSta:	Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive+
BWMgmt- ABWMgmt-
		RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna- CRSVisible-
		RootCap: CRSVisible-
		RootSta: PME ReqID 0000, PMEStatus- PMEPending-
		DevCap2: Completion Timeout: Range BC, TimeoutDis+ ARIFwd-
		DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis- ARIFwd-
		LnkCtl2: Target Link Speed: 2.5GT/s, EnterCompliance- SpeedDis-,
Selectable De-emphasis: -6dB
			 Transmit Margin: Normal Operating Range, EnterModifiedCompliance-
ComplianceSOS-
			 Compliance De-emphasis: -6dB
		LnkSta2: Current De-emphasis Level: -6dB
	Capabilities: [80] MSI: Enable+ Count=1/1 Maskable- 64bit-
		Address: fee0100c  Data: 4151
	Capabilities: [90] Subsystem: Intel Corporation Device 34ec
	Capabilities: [a0] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
		Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
	Kernel driver in use: pcieport

00:1c.7 PCI bridge: Intel Corporation 5 Series/3400 Series Chipset PCI
Express Root Port 8 (rev 05) (prog-if 00 [Normal decode])
	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
	Bus: primary=00, secondary=05, subordinate=05, sec-latency=0
	I/O behind bridge: 0000f000-00000fff
	Memory behind bridge: fff00000-000fffff
	Prefetchable memory behind bridge: 00000000fff00000-00000000000fffff
	Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort+ <SERR- <PERR-
	BridgeCtl: Parity+ SERR+ NoISA- VGA- MAbort- >Reset- FastB2B-
		PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
	Capabilities: [40] Express (v2) Root Port (Slot+), MSI 00
		DevCap:	MaxPayload 128 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us
			ExtTag- RBE+ FLReset-
		DevCtl:	Report errors: Correctable+ Non-Fatal+ Fatal+ Unsupported-
			RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
			MaxPayload 128 bytes, MaxReadReq 128 bytes
		DevSta:	CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend-
		LnkCap:	Port #8, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency L0
<1us, L1 <4us
			ClockPM- Surprise- LLActRep+ BwNot-
		LnkCtl:	ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk-
			ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
		LnkSta:	Speed 2.5GT/s, Width x0, TrErr- Train- SlotClk+ DLActive-
BWMgmt- ABWMgmt-
		SltCap:	AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug- Surprise+
			Slot #7, PowerLimit 10.000W; Interlock- NoCompl+
		SltCtl:	Enable: AttnBtn- PwrFlt- MRL- PresDet+ CmdCplt- HPIrq- LinkChg-
			Control: AttnInd Unknown, PwrInd Unknown, Power- Interlock-
		SltSta:	Status: AttnBtn- PowerFlt- MRL- CmdCplt- PresDet+ Interlock-
			Changed: MRL- PresDet- LinkState-
		RootCtl: ErrCorrectable+ ErrNon-Fatal+ ErrFatal+ PMEIntEna- CRSVisible-
		RootCap: CRSVisible-
		RootSta: PME ReqID 0000, PMEStatus- PMEPending-
		DevCap2: Completion Timeout: Range BC, TimeoutDis+ ARIFwd-
		DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis- ARIFwd-
		LnkCtl2: Target Link Speed: 2.5GT/s, EnterCompliance- SpeedDis-,
Selectable De-emphasis: -6dB
			 Transmit Margin: Normal Operating Range, EnterModifiedCompliance-
ComplianceSOS-
			 Compliance De-emphasis: -6dB
		LnkSta2: Current De-emphasis Level: -6dB
	Capabilities: [80] MSI: Enable+ Count=1/1 Maskable- 64bit-
		Address: fee0100c  Data: 4159
	Capabilities: [90] Subsystem: Intel Corporation Device 34ec
	Capabilities: [a0] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
		Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
	Kernel driver in use: pcieport

00:1d.0 USB Controller: Intel Corporation 5 Series/3400 Series Chipset
USB2 Enhanced Host Controller (rev 05) (prog-if 20 [EHCI])
	Subsystem: Intel Corporation Device 34ec
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+
Stepping- SERR+ FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0
	Interrupt: pin A routed to IRQ 23
	Region 0: Memory at b3b20000 (32-bit, non-prefetchable) [size=1K]
	Capabilities: [50] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
		Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
	Capabilities: [58] Debug port: BAR=1 offset=00a0
	Capabilities: [98] PCI Advanced Features
		AFCap: TP+ FLR+
		AFCtrl: FLR-
		AFStatus: TP-
	Kernel driver in use: ehci_hcd

00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev a5)
(prog-if 01 [Subtractive decode])
	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
	Bus: primary=00, secondary=06, subordinate=06, sec-latency=32
	I/O behind bridge: 0000f000-00000fff
	Memory behind bridge: fff00000-000fffff
	Prefetchable memory behind bridge: 00000000fff00000-00000000000fffff
	Secondary status: 66MHz- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort+ <SERR- <PERR-
	BridgeCtl: Parity+ SERR+ NoISA- VGA- MAbort- >Reset- FastB2B-
		PriDiscTmr- SecDiscTmr+ DiscTmrStat- DiscTmrSERREn+
	Capabilities: [50] Subsystem: Intel Corporation Device 34ec

00:1f.0 ISA bridge: Intel Corporation 3400 Series Chipset LPC
Interface Controller (rev 05)
	Subsystem: Intel Corporation Device 34ec
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+
Stepping- SERR+ FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0
	Capabilities: [e0] Vendor Specific Information: Len=10 <?>

00:1f.2 IDE interface: Intel Corporation 5 Series/3400 Series Chipset
4 port SATA IDE Controller (rev 05) (prog-if 8f [Master SecP SecO PriP
PriO])
	Subsystem: Intel Corporation Device 34ec
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0
	Interrupt: pin B routed to IRQ 18
	Region 0: I/O ports at 3098 [size=8]
	Region 1: I/O ports at 30ac [size=4]
	Region 2: I/O ports at 3090 [size=8]
	Region 3: I/O ports at 30a8 [size=4]
	Region 4: I/O ports at 3070 [size=16]
	Region 5: I/O ports at 3060 [size=16]
	Capabilities: [70] Power Management version 3
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
	Capabilities: [b0] PCI Advanced Features
		AFCap: TP+ FLR+
		AFCtrl: FLR-
		AFStatus: TP-
	Kernel driver in use: ata_piix

00:1f.3 SMBus: Intel Corporation 5 Series/3400 Series Chipset SMBus
Controller (rev 05)
	Subsystem: Intel Corporation Device 34ec
	Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx-
	Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR- INTx-
	Interrupt: pin B routed to IRQ 18
	Region 0: Memory at b3b22000 (64-bit, non-prefetchable) [size=256]
	Region 4: I/O ports at 3000 [size=32]
	Kernel driver in use: i801_smbus

00:1f.5 IDE interface: Intel Corporation 5 Series/3400 Series Chipset
2 port SATA IDE Controller (rev 05) (prog-if 85 [Master SecO PriO])
	Subsystem: Intel Corporation Device 34ec
	Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+
Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0
	Interrupt: pin D routed to IRQ 22
	Region 0: I/O ports at 3088 [size=8]
	Region 1: I/O ports at 30a4 [size=4]
	Region 2: I/O ports at 3080 [size=8]
	Region 3: I/O ports at 30a0 [size=4]
	Region 4: I/O ports at 3050 [size=16]
	Region 5: I/O ports at 3040 [size=16]
	Capabilities: [70] Power Management version 3
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
	Capabilities: [b0] PCI Advanced Features
		AFCap: TP+ FLR+
		AFCtrl: FLR-
		AFStatus: TP-
	Kernel driver in use: ata_piix

01:00.0 RAID bus controller: 3ware Inc 9690SA SAS/SATA-II RAID PCIe (rev 01)
	Subsystem: 3ware Inc 9690SA SAS/SATA-II RAID PCIe
	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, Cache Line Size: 64 bytes
	Interrupt: pin A routed to IRQ 16
	Region 0: Memory at b0000000 (64-bit, prefetchable) [size=32M]
	Region 2: Memory at b3a00000 (64-bit, non-prefetchable) [size=4K]
	Region 4: I/O ports at 2000 [size=256]
	Expansion ROM at b3a20000 [disabled] [size=128K]
	Capabilities: [40] Power Management version 2
		Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
	Capabilities: [50] MSI: Enable- Count=1/32 Maskable- 64bit+
		Address: 0000000000000000  Data: 0000
	Capabilities: [70] Express (v1) Legacy Endpoint, MSI 00
		DevCap:	MaxPayload 512 bytes, PhantFunc 0, Latency L0s <128ns, L1 <2us
			ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
		DevCtl:	Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
			RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
			MaxPayload 128 bytes, MaxReadReq 512 bytes
		DevSta:	CorrErr+ UncorrErr- FatalErr- UnsuppReq+ AuxPwr- TransPend-
		LnkCap:	Port #0, Speed 2.5GT/s, Width x8, ASPM L0s L1, Latency L0
<512ns, L1 <64us
			ClockPM- Surprise- LLActRep+ BwNot-
		LnkCtl:	ASPM Disabled; RCB 128 bytes Disabled- Retrain- CommClk-
			ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
		LnkSta:	Speed 2.5GT/s, Width x8, TrErr- Train- SlotClk- DLActive+
BWMgmt- ABWMgmt-
	Capabilities: [100 v1] Advanced Error Reporting
		UESta:	DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF-
MalfTLP- ECRC- UnsupReq+ ACSViol-
		UEMsk:	DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF-
MalfTLP- ECRC- UnsupReq- ACSViol-
		UESvrt:	DLP+ SDES- TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+
MalfTLP+ ECRC- UnsupReq- ACSViol-
		CESta:	RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
		CEMsk:	RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
		AERCap:	First Error Pointer: 00, GenCap+ CGenEn- ChkCap+ ChkEn-
	Kernel driver in use: 3w-9xxx

03:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network Connection
	Subsystem: Intel Corporation Device 34ec
	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, Cache Line Size: 64 bytes
	Interrupt: pin A routed to IRQ 16
	Region 0: Memory at b3900000 (32-bit, non-prefetchable) [size=128K]
	Region 2: I/O ports at 1000 [size=32]
	Region 3: Memory at b3920000 (32-bit, non-prefetchable) [size=16K]
	Capabilities: [c8] Power Management version 2
		Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
		Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=1 PME-
	Capabilities: [d0] MSI: Enable- Count=1/1 Maskable- 64bit+
		Address: 0000000000000000  Data: 0000
	Capabilities: [e0] Express (v1) Endpoint, MSI 00
		DevCap:	MaxPayload 256 bytes, PhantFunc 0, Latency L0s <512ns, L1 <64us
			ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
		DevCtl:	Report errors: Correctable+ Non-Fatal+ Fatal+ Unsupported+
			RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
			MaxPayload 128 bytes, MaxReadReq 512 bytes
		DevSta:	CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend-
		LnkCap:	Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency L0
<128ns, L1 <64us
			ClockPM- Surprise- LLActRep- BwNot-
		LnkCtl:	ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+
			ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
		LnkSta:	Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive-
BWMgmt- ABWMgmt-
	Capabilities: [a0] MSI-X: Enable+ Count=5 Masked-
		Vector table: BAR=3 offset=00000000
		PBA: BAR=3 offset=00002000
	Capabilities: [100 v1] Advanced Error Reporting
		UESta:	DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF-
MalfTLP- ECRC- UnsupReq- ACSViol-
		UEMsk:	DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF-
MalfTLP- ECRC- UnsupReq- ACSViol-
		UESvrt:	DLP+ SDES- TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+
MalfTLP+ ECRC- UnsupReq- ACSViol-
		CESta:	RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr-
		CEMsk:	RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
		AERCap:	First Error Pointer: 00, GenCap- CGenEn- ChkCap- ChkEn-
	Capabilities: [140 v1] Device Serial Number 00-1e-67-ff-ff-02-c2-ca
	Kernel driver in use: e1000e

04:00.0 VGA compatible controller: Matrox Graphics, Inc. MGA G200e
[Pilot] ServerEngines (SEP1) (rev 02) (prog-if 00 [VGA controller])
	Subsystem: Intel Corporation Device 0101
	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, Cache Line Size: 64 bytes
	Interrupt: pin A routed to IRQ 11
	Region 0: Memory at b2000000 (32-bit, prefetchable) [size=16M]
	Region 1: Memory at b3800000 (32-bit, non-prefetchable) [size=16K]
	Region 2: Memory at b3000000 (32-bit, non-prefetchable) [size=8M]
	Expansion ROM at b3810000 [disabled] [size=64K]
	Capabilities: [dc] Power Management version 2
		Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
	Capabilities: [e4] Express (v1) Legacy Endpoint, MSI 00
		DevCap:	MaxPayload 128 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us
			ExtTag- AttnBtn- AttnInd- PwrInd- RBE- FLReset-
		DevCtl:	Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
			RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
			MaxPayload 128 bytes, MaxReadReq 128 bytes
		DevSta:	CorrErr+ UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend-
		LnkCap:	Port #0, Speed 2.5GT/s, Width x1, ASPM L0s, Latency L0 <64ns, L1 <1us
			ClockPM- Surprise- LLActRep- BwNot-
		LnkCtl:	ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+
			ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
		LnkSta:	Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive-
BWMgmt- ABWMgmt-
	Capabilities: [54] MSI: Enable- Count=1/1 Maskable- 64bit-
		Address: 00000000  Data: 0000



### dmidecode

# dmidecode 2.9
SMBIOS 2.5 present.
64 structures occupying 2689 bytes.
Table at 0x9F6A4000.

Handle 0x0001, DMI type 38, 20 bytes
IPMI Device Information
	Interface Type: KCS (Keyboard Control Style)
	Specification Version: 2.0
	I2C Slave Address: 0x10
	NV Storage Device: Not Present
	Base Address: 0x0000000000000CA2 (I/O)
	Register Spacing: Successive Byte Boundaries

Handle 0x0002, DMI type 1, 27 bytes
System Information
	Manufacturer: Intel Corporation
	Product Name: S3420GP
	Version: ....................
	Serial Number: ............
	UUID: 0FD8E440-1952-11E0-B578-001E6702C2CA
	Wake-up Type: Power Switch
	SKU Number: Not Specified
	Family: Not Specified

Handle 0x0003, DMI type 2, 16 bytes
Base Board Information
	Manufacturer: Intel Corporation
	Product Name: S3420GP
	Version: E51976-406
	Serial Number: AZGP10200424
	Asset Tag: ....................
	Features:
		Board is a hosting board
		Board is replaceable
	Location In Chassis: Not Specified
	Chassis Handle: 0x0004
	Type: Motherboard
	Contained Object Handles: 0

Handle 0x0004, DMI type 3, 22 bytes
Chassis Information
	Manufacturer: ..............................
	Type: Main Server Chassis
	Lock: Not Present
	Version: ..................
	Serial Number: ..................
	Asset Tag: ....................
	Boot-up State: Safe
	Power Supply State: Safe
	Thermal State: Safe
	Security Status: Unknown
	OEM Information: 0x01000181
	Height: 1 U
	Number Of Power Cords: 1
	Contained Elements: 0

Handle 0x0005, DMI type 0, 24 bytes
BIOS Information
	Vendor: Intel Corp.
	Version: S3420GP.86B.01.00.0046.092920101143
	Release Date: 09/29/2010
	Address: 0xF0000
	Runtime Size: 64 kB
	ROM Size: 8192 kB
	Characteristics:
		PCI is supported
		PNP is supported
		BIOS is upgradeable
		BIOS shadowing is allowed
		Boot from CD is supported
		Selectable boot is supported
		EDD is supported
		3.5"/2.88 MB floppy services are supported (int 13h)
		Print screen service is supported (int 5h)
		8042 keyboard services are supported (int 9h)
		Serial services are supported (int 14h)
		CGA/mono video services are supported (int 10h)
		ACPI is supported
		USB legacy is supported
		LS-120 boot is supported
		ATAPI Zip drive boot is supported
		Function key-initiated network boot is supported
		Targeted content distribution is supported
	BIOS Revision: 17.18
	Firmware Revision: 0.0

Handle 0x0006, DMI type 8, 9 bytes
Port Connector Information
	Internal Reference Designator: J8A1 - SERIAL A
	Internal Connector Type: Other
	External Reference Designator: SERIAL A
	External Connector Type: DB-9 male
	Port Type: Serial Port 16550A Compatible

Handle 0x0007, DMI type 8, 9 bytes
Port Connector Information
	Internal Reference Designator: J1B2 - SERIAL B
	Internal Connector Type: 9 Pin Dual Inline (pin 10 cut)
	External Reference Designator: SERIAL B
	External Connector Type: None
	Port Type: Serial Port 16550A Compatible

Handle 0x0008, DMI type 8, 9 bytes
Port Connector Information
	Internal Reference Designator: J7A1 - VGA
	Internal Connector Type: None
	External Reference Designator: VGA
	External Connector Type: DB-15 female
	Port Type: Video Port

Handle 0x0009, DMI type 8, 9 bytes
Port Connector Information
	Internal Reference Designator: J6A1 - USB 0
	Internal Connector Type: None
	External Reference Designator: USB 0
	External Connector Type: Access Bus (USB)
	Port Type: USB

Handle 0x000A, DMI type 8, 9 bytes
Port Connector Information
	Internal Reference Designator: J6A1 - USB 1
	Internal Connector Type: None
	External Reference Designator: USB 1
	External Connector Type: Access Bus (USB)
	Port Type: USB

Handle 0x000B, DMI type 8, 9 bytes
Port Connector Information
	Internal Reference Designator: J5A1 - USB 2
	Internal Connector Type: None
	External Reference Designator: USB 2
	External Connector Type: Access Bus (USB)
	Port Type: USB

Handle 0x000C, DMI type 8, 9 bytes
Port Connector Information
	Internal Reference Designator: J5A1 - USB 3
	Internal Connector Type: None
	External Reference Designator: USB 3
	External Connector Type: Access Bus (USB)
	Port Type: USB

Handle 0x000D, DMI type 8, 9 bytes
Port Connector Information
	Internal Reference Designator: J3F2 - USB SSD
	Internal Connector Type: None
	External Reference Designator: USB SSD
	External Connector Type: Access Bus (USB)
	Port Type: USB

Handle 0x000E, DMI type 8, 9 bytes
Port Connector Information
	Internal Reference Designator: J1J2 - USB 5 FLOPPY
	Internal Connector Type: None
	External Reference Designator: USB 5 FLOPPY
	External Connector Type: Access Bus (USB)
	Port Type: USB

Handle 0x000F, DMI type 8, 9 bytes
Port Connector Information
	Internal Reference Designator: J1D1 - USB 6
	Internal Connector Type: None
	External Reference Designator: USB 6
	External Connector Type: Access Bus (USB)
	Port Type: USB

Handle 0x0010, DMI type 8, 9 bytes
Port Connector Information
	Internal Reference Designator: J1D1 - USB 7
	Internal Connector Type: None
	External Reference Designator: USB 7
	External Connector Type: Access Bus (USB)
	Port Type: USB

Handle 0x0011, DMI type 8, 9 bytes
Port Connector Information
	Internal Reference Designator: J1E1 - USB 8
	Internal Connector Type: None
	External Reference Designator: USB 8
	External Connector Type: Access Bus (USB)
	Port Type: USB

Handle 0x0012, DMI type 8, 9 bytes
Port Connector Information
	Internal Reference Designator: J1E1 - USB 9
	Internal Connector Type: None
	External Reference Designator: USB 9
	External Connector Type: Access Bus (USB)
	Port Type: USB

Handle 0x0013, DMI type 8, 9 bytes
Port Connector Information
	Internal Reference Designator: J6A1 - NIC 1
	Internal Connector Type: None
	External Reference Designator: NIC 1
	External Connector Type: RJ-45
	Port Type: Network Port

Handle 0x0014, DMI type 8, 9 bytes
Port Connector Information
	Internal Reference Designator: J5A1 - NIC 2
	Internal Connector Type: None
	External Reference Designator: NIC 2
	External Connector Type: RJ-45
	Port Type: Network Port

Handle 0x0015, DMI type 8, 9 bytes
Port Connector Information
	Internal Reference Designator: J1H4 - 1x7 Pin SATA 0
	Internal Connector Type: Other
	External Reference Designator: SATA 0
	External Connector Type: None
	Port Type: Other

Handle 0x0016, DMI type 8, 9 bytes
Port Connector Information
	Internal Reference Designator: J1H1 - 1x7 Pin SATA 1
	Internal Connector Type: Other
	External Reference Designator: SATA 1
	External Connector Type: None
	Port Type: Other

Handle 0x0017, DMI type 8, 9 bytes
Port Connector Information
	Internal Reference Designator: J1G1 - 1x7 Pin SATA 2
	Internal Connector Type: Other
	External Reference Designator: SATA 2
	External Connector Type: None
	Port Type: Other

Handle 0x0018, DMI type 8, 9 bytes
Port Connector Information
	Internal Reference Designator: J1H3 - 1x7 Pin SATA 3
	Internal Connector Type: Other
	External Reference Designator: SATA 3
	External Connector Type: None
	Port Type: Other

Handle 0x0019, DMI type 8, 9 bytes
Port Connector Information
	Internal Reference Designator: J1G3 - 1x7 Pin SATA 4
	Internal Connector Type: Other
	External Reference Designator: SATA 4
	External Connector Type: None
	Port Type: Other

Handle 0x001A, DMI type 8, 9 bytes
Port Connector Information
	Internal Reference Designator: J1F4 - 1x7 Pin SATA 5
	Internal Connector Type: Other
	External Reference Designator: SATA 5
	External Connector Type: None
	Port Type: Other

Handle 0x001B, DMI type 8, 9 bytes
Port Connector Information
	Internal Reference Designator: J1C1 - 24-Pin Male Front Panel
	Internal Connector Type: Other
	External Reference Designator: Front Panel
	External Connector Type: None
	Port Type: Other

Handle 0x001C, DMI type 8, 9 bytes
Port Connector Information
	Internal Reference Designator: J1H2 4-Pin Male IPMB
	Internal Connector Type: Other
	External Reference Designator: IPMB
	External Connector Type: None
	Port Type: Other

Handle 0x001D, DMI type 9, 13 bytes
System Slot Information
	Designation: PCI SLOT1
	Type: 32-bit PCI
	Current Usage: Available
	Length: Long
	ID: 1
	Characteristics:
		3.3 V is provided
		PME signal is supported

Handle 0x001E, DMI type 9, 13 bytes
System Slot Information
	Designation: PCI-E SLOT3
	Type: x4 PCI Express
	Current Usage: Available
	Length: Long
	ID: 3
	Characteristics:
		3.3 V is provided
		PME signal is supported

Handle 0x001F, DMI type 9, 13 bytes
System Slot Information
	Designation: PCI-E SLOT5
	Type: x8 PCI Express
	Current Usage: Available
	Length: Long
	ID: 5
	Characteristics:
		3.3 V is provided
		PME signal is supported

Handle 0x0020, DMI type 9, 13 bytes
System Slot Information
	Designation: PCI-E SLOT6
	Type: x16 PCI Express
	Current Usage: In Use
	Length: Long
	ID: 6
	Characteristics:
		3.3 V is provided
		PME signal is supported

Handle 0x0021, DMI type 10, 6 bytes
On Board Device Information
	Type: Video
	Status: Enabled
	Description: ServerEngines Pilot II

Handle 0x0022, DMI type 10, 6 bytes
On Board Device Information
	Type: Ethernet
	Status: Enabled
	Description: Intel 82574L

Handle 0x0023, DMI type 10, 6 bytes
On Board Device Information
	Type: Ethernet
	Status: Enabled
	Description: Intel 82578DM

Handle 0x0024, DMI type 10, 6 bytes
On Board Device Information
	Type: SATA Controller
	Status: Enabled
	Description: PCH Integrated SATA Controller

Handle 0x0025, DMI type 12, 5 bytes
System Configuration Options
	Option 1: J1F2 2-3: Close to clear Password

Handle 0x0026, DMI type 12, 5 bytes
System Configuration Options
	Option 1: J1F5 2-3: Close to clear CMOS

Handle 0x0027, DMI type 12, 5 bytes
System Configuration Options
	Option 1: J1F3 2-3: Close for BIOS Recovery

Handle 0x0028, DMI type 12, 5 bytes
System Configuration Options
	Option 1: J1A2 2-3: Close to Force BMC Update Mode

Handle 0x0029, DMI type 12, 5 bytes
System Configuration Options
	Option 1: J1F1 2-3: Close to Force ME Update Mode

Handle 0x002A, DMI type 24, 5 bytes
Hardware Security
	Power-On Password Status: Disabled
	Keyboard Password Status: Disabled
	Administrator Password Status: Disabled
	Front Panel Reset Status: Disabled

Handle 0x002B, DMI type 13, 22 bytes
BIOS Language Information
	Installable Languages: 1
		en|US|iso8859-1
	Currently Installed Language: en|US|iso8859-1

Handle 0x002C, DMI type 11, 5 bytes
OEM Strings
	String 1:
	String 2:
	String 3:
	String 4:
	String 5:

Handle 0x002D, DMI type 32, 20 bytes
System Boot Information
	Status: No errors detected

Handle 0x002E, DMI type 16, 15 bytes
Physical Memory Array
	Location: System Board Or Motherboard
	Use: System Memory
	Error Correction Type: Multi-bit ECC
	Maximum Capacity: 32 GB
	Error Information Handle: Not Provided
	Number Of Devices: 6

Handle 0x002F, DMI type 19, 15 bytes
Memory Array Mapped Address
	Starting Address: 0x00000000000
	Ending Address: 0x003FFFFFFFF
	Range Size: 16 GB
	Physical Array Handle: 0x002E
	Partition Width: 0

Handle 0x0030, DMI type 17, 27 bytes
Memory Device
	Array Handle: 0x002E
	Error Information Handle: Not Provided
	Total Width: 72 bits
	Data Width: 64 bits
	Size: 4096 MB
	Form Factor: DIMM
	Set: 1
	Locator: DIMM_A1
	Bank Locator: NODE 0 CHANNEL 0 DIMM 0
	Type: Other
	Type Detail: Synchronous
	Speed: 1333 MHz (0.8 ns)
	Manufacturer: 0x0198
	Serial Number: 0x40247588
	Asset Tag: Unknown
	Part Number: 9965413-002.A00LF

Handle 0x0031, DMI type 20, 19 bytes
Memory Device Mapped Address
	Starting Address: 0x00000000000
	Ending Address: 0x000FFFFFFFF
	Range Size: 4 GB
	Physical Device Handle: 0x0030
	Memory Array Mapped Address Handle: 0x002F
	Partition Row Position: 1
	Interleave Position: 1
	Interleaved Data Depth: 1

Handle 0x0032, DMI type 17, 27 bytes
Memory Device
	Array Handle: 0x002E
	Error Information Handle: Not Provided
	Total Width: 72 bits
	Data Width: 64 bits
	Size: 4096 MB
	Form Factor: DIMM
	Set: 2
	Locator: DIMM_A2
	Bank Locator: NODE 0 CHANNEL 0 DIMM 1
	Type: Other
	Type Detail: Synchronous
	Speed: 1333 MHz (0.8 ns)
	Manufacturer: 0x0198
	Serial Number: 0x4324FA41
	Asset Tag: Unknown
	Part Number: 9965413-002.A00LF

Handle 0x0033, DMI type 20, 19 bytes
Memory Device Mapped Address
	Starting Address: 0x00100000000
	Ending Address: 0x001FFFFFFFF
	Range Size: 4 GB
	Physical Device Handle: 0x0032
	Memory Array Mapped Address Handle: 0x002F
	Partition Row Position: 1
	Interleave Position: 1
	Interleaved Data Depth: 1

Handle 0x0034, DMI type 17, 27 bytes
Memory Device
	Array Handle: 0x002E
	Error Information Handle: Not Provided
	Total Width: Unknown
	Data Width: Unknown
	Size: No Module Installed
	Form Factor: DIMM
	Set: 3
	Locator: DIMM_A3
	Bank Locator: NODE 0 CHANNEL 0 DIMM 2
	Type: Other
	Type Detail: Synchronous
	Speed: 1333 MHz (0.8 ns)
	Manufacturer: NO DIMM
	Serial Number: NO DIMM
	Asset Tag: NO DIMM
	Part Number: NO DIMM

Handle 0x0035, DMI type 17, 27 bytes
Memory Device
	Array Handle: 0x002E
	Error Information Handle: Not Provided
	Total Width: 72 bits
	Data Width: 64 bits
	Size: 4096 MB
	Form Factor: DIMM
	Set: 1
	Locator: DIMM_B1
	Bank Locator: NODE 0 CHANNEL 1 DIMM 0
	Type: Other
	Type Detail: Synchronous
	Speed: 1333 MHz (0.8 ns)
	Manufacturer: 0x0198
	Serial Number: 0x4524FB41
	Asset Tag: Unknown
	Part Number: 9965413-002.A00LF

Handle 0x0036, DMI type 20, 19 bytes
Memory Device Mapped Address
	Starting Address: 0x00200000000
	Ending Address: 0x002FFFFFFFF
	Range Size: 4 GB
	Physical Device Handle: 0x0035
	Memory Array Mapped Address Handle: 0x002F
	Partition Row Position: 1
	Interleave Position: 1
	Interleaved Data Depth: 1

Handle 0x0037, DMI type 17, 27 bytes
Memory Device
	Array Handle: 0x002E
	Error Information Handle: Not Provided
	Total Width: 72 bits
	Data Width: 64 bits
	Size: 4096 MB
	Form Factor: DIMM
	Set: 2
	Locator: DIMM_B2
	Bank Locator: NODE 0 CHANNEL 1 DIMM 1
	Type: Other
	Type Detail: Synchronous
	Speed: 1333 MHz (0.8 ns)
	Manufacturer: 0x0198
	Serial Number: 0x4524F841
	Asset Tag: Unknown
	Part Number: 9965413-002.A00LF

Handle 0x0038, DMI type 20, 19 bytes
Memory Device Mapped Address
	Starting Address: 0x00300000000
	Ending Address: 0x003FFFFFFFF
	Range Size: 4 GB
	Physical Device Handle: 0x0037
	Memory Array Mapped Address Handle: 0x002F
	Partition Row Position: 1
	Interleave Position: 1
	Interleaved Data Depth: 1

Handle 0x0039, DMI type 17, 27 bytes
Memory Device
	Array Handle: 0x002E
	Error Information Handle: Not Provided
	Total Width: Unknown
	Data Width: Unknown
	Size: No Module Installed
	Form Factor: DIMM
	Set: 3
	Locator: DIMM_B3
	Bank Locator: NODE 0 CHANNEL 1 DIMM 2
	Type: Other
	Type Detail: Synchronous
	Speed: 1333 MHz (0.8 ns)
	Manufacturer: NO DIMM
	Serial Number: NO DIMM
	Asset Tag: NO DIMM
	Part Number: NO DIMM

Handle 0x003A, DMI type 131, 45 bytes
OEM-specific Type
	Header and Data:
		83 2D 3A 00 01 77 00 00 00 00 00 00 00 33 00 00
		00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
		00 00 00 00 00 00 00 00 00 00 00 00 00

Handle 0x003B, DMI type 4, 40 bytes
Processor Information
	Socket Designation: CPU1
	Type: Central Processor
	Family: Xeon
	Manufacturer: Intel(R) Corporation
	ID: E5 06 01 00 FF FB EB BF
	Signature: Type 0, Family 6, Model 30, Stepping 5
	Flags:
		FPU (Floating-point unit on-chip)
		VME (Virtual mode extension)
		DE (Debugging extension)
		PSE (Page size extension)
		TSC (Time stamp counter)
		MSR (Model specific registers)
		PAE (Physical address extension)
		MCE (Machine check exception)
		CX8 (CMPXCHG8 instruction supported)
		APIC (On-chip APIC hardware supported)
		SEP (Fast system call)
		MTRR (Memory type range registers)
		PGE (Page global enable)
		MCA (Machine check architecture)
		CMOV (Conditional move instruction supported)
		PAT (Page attribute table)
		PSE-36 (36-bit page size extension)
		CLFSH (CLFLUSH instruction supported)
		DS (Debug store)
		ACPI (ACPI supported)
		MMX (MMX technology supported)
		FXSR (Fast floating-point save and restore)
		SSE (Streaming SIMD extensions)
		SSE2 (Streaming SIMD extensions 2)
		SS (Self-snoop)
		HTT (Hyper-threading technology)
		TM (Thermal monitor supported)
		PBE (Pending break enabled)
	Version: Intel(R) Xeon(R) CPU           X3430  @ 2.40GHz
	Voltage: 0.0 V
	External Clock: 133 MHz
	Max Speed: 4000 MHz
	Current Speed: 2400 MHz
	Status: Populated, Enabled
	Upgrade: Other
	L1 Cache Handle: 0x003F
	L2 Cache Handle: 0x003E
	L3 Cache Handle: 0x003C
	Serial Number: Not Specified
	Asset Tag: Not Specified
	Part Number: Not Specified
	Core Count: 4
	Core Enabled: 4
	Thread Count: 8
	Characteristics:
		64-bit capable

Handle 0x003C, DMI type 7, 19 bytes
Cache Information
	Socket Designation: L3-Cache
	Configuration: Enabled, Not Socketed, Level 3
	Operational Mode: Write Back
	Location: Internal
	Installed Size: 8192 KB
	Maximum Size: 8192 KB
	Supported SRAM Types:
		Asynchronous
	Installed SRAM Type: Asynchronous
	Speed: Unknown
	Error Correction Type: Single-bit ECC
	System Type: Unified
	Associativity: 16-way Set-associative

Handle 0x003D, DMI type 7, 19 bytes
Cache Information
	Socket Designation: L1-Cache
	Configuration: Enabled, Not Socketed, Level 1
	Operational Mode: Write Back
	Location: Internal
	Installed Size: 128 KB
	Maximum Size: 128 KB
	Supported SRAM Types:
		Asynchronous
	Installed SRAM Type: Asynchronous
	Speed: Unknown
	Error Correction Type: Single-bit ECC
	System Type: Data
	Associativity: 8-way Set-associative

Handle 0x003E, DMI type 7, 19 bytes
Cache Information
	Socket Designation: L2-Cache
	Configuration: Enabled, Not Socketed, Level 2
	Operational Mode: Write Back
	Location: Internal
	Installed Size: 1024 KB
	Maximum Size: 1024 KB
	Supported SRAM Types:
		Asynchronous
	Installed SRAM Type: Asynchronous
	Speed: Unknown
	Error Correction Type: Single-bit ECC
	System Type: Unified
	Associativity: 8-way Set-associative

Handle 0x003F, DMI type 7, 19 bytes
Cache Information
	Socket Designation: L1-Cache
	Configuration: Enabled, Not Socketed, Level 1
	Operational Mode: Write Back
	Location: Internal
	Installed Size: 128 KB
	Maximum Size: 128 KB
	Supported SRAM Types:
		Asynchronous
	Installed SRAM Type: Asynchronous
	Speed: Unknown
	Error Correction Type: Single-bit ECC
	System Type: Instruction
	Associativity: 4-way Set-associative

Handle 0xFEFF, DMI type 127, 4 bytes
End Of Table



#### .config

#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.32.47
# Fri Dec  2 13:02:03 2011
#
CONFIG_64BIT=y
# CONFIG_X86_32 is not set
CONFIG_X86_64=y
CONFIG_X86=y
CONFIG_OUTPUT_FORMAT="elf64-x86-64"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig"
CONFIG_GENERIC_TIME=y
CONFIG_GENERIC_CMOS_UPDATE=y
CONFIG_CLOCKSOURCE_WATCHDOG=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_HAVE_LATENCYTOP_SUPPORT=y
CONFIG_MMU=y
CONFIG_ZONE_DMA=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_IOMAP=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
# CONFIG_RWSEM_GENERIC_SPINLOCK is not set
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_ARCH_HAS_CPU_IDLE_WAIT=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_GENERIC_TIME_VSYSCALL=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_DEFAULT_IDLE=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_HAVE_CPUMASK_OF_CPU_MAP=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ZONE_DMA32=y
CONFIG_ARCH_POPULATES_NODE_MAP=y
CONFIG_AUDIT_ARCH=y
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_GENERIC_HARDIRQS=y
CONFIG_GENERIC_HARDIRQS_NO__DO_IRQ=y
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_PENDING_IRQ=y
CONFIG_USE_GENERIC_SMP_HELPERS=y
CONFIG_X86_64_SMP=y
CONFIG_X86_HT=y
CONFIG_X86_TRAMPOLINE=y
# CONFIG_KTIME_SCALAR is not set
CONFIG_ARCH_CPU_PROBE_RELEASE=y
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_CONSTRUCTORS=y

#
# General setup
#
CONFIG_EXPERIMENTAL=y
CONFIG_LOCK_KERNEL=y
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_LOCALVERSION=""
# CONFIG_LOCALVERSION_AUTO is not set
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_KERNEL_GZIP=y
# CONFIG_KERNEL_BZIP2 is not set
# CONFIG_KERNEL_LZMA is not set
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
CONFIG_POSIX_MQUEUE=y
CONFIG_POSIX_MQUEUE_SYSCTL=y
CONFIG_BSD_PROCESS_ACCT=y
# CONFIG_BSD_PROCESS_ACCT_V3 is not set
CONFIG_TASKSTATS=y
CONFIG_TASK_DELAY_ACCT=y
CONFIG_TASK_XACCT=y
CONFIG_TASK_IO_ACCOUNTING=y
CONFIG_AUDIT=y
CONFIG_AUDITSYSCALL=y
CONFIG_AUDIT_TREE=y

#
# RCU Subsystem
#
CONFIG_TREE_RCU=y
# CONFIG_TREE_PREEMPT_RCU is not set
# CONFIG_RCU_TRACE is not set
CONFIG_RCU_FANOUT=32
# CONFIG_RCU_FANOUT_EXACT is not set
# CONFIG_TREE_RCU_TRACE is not set
# CONFIG_IKCONFIG is not set
CONFIG_LOG_BUF_SHIFT=18
CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y
CONFIG_CGROUPS=y
# CONFIG_CGROUP_DEBUG is not set
CONFIG_CGROUP_NS=y
CONFIG_CGROUP_FREEZER=y
# CONFIG_CGROUP_DEVICE is not set
CONFIG_CPUSETS=y
CONFIG_PROC_PID_CPUSET=y
CONFIG_CGROUP_CPUACCT=y
CONFIG_RESOURCE_COUNTERS=y
# CONFIG_CGROUP_MEM_RES_CTLR is not set
CONFIG_CGROUP_SCHED=y
CONFIG_FAIR_GROUP_SCHED=y
# CONFIG_RT_GROUP_SCHED is not set
# CONFIG_SYSFS_DEPRECATED_V2 is not set
CONFIG_RELAY=y
CONFIG_NAMESPACES=y
CONFIG_UTS_NS=y
CONFIG_IPC_NS=y
CONFIG_USER_NS=y
CONFIG_PID_NS=y
CONFIG_NET_NS=y
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=""
CONFIG_RD_GZIP=y
CONFIG_RD_BZIP2=y
CONFIG_RD_LZMA=y
CONFIG_CC_OPTIMIZE_FOR_SIZE=y
CONFIG_SYSCTL=y
CONFIG_ANON_INODES=y
# CONFIG_EMBEDDED is not set
CONFIG_UID16=y
CONFIG_SYSCTL_SYSCALL=y
CONFIG_KALLSYMS=y
CONFIG_KALLSYMS_ALL=y
CONFIG_KALLSYMS_EXTRA_PASS=y
CONFIG_HOTPLUG=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_PCSPKR_PLATFORM=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_SIGNALFD=y
CONFIG_TIMERFD=y
CONFIG_EVENTFD=y
CONFIG_SHMEM=y
CONFIG_AIO=y
CONFIG_HAVE_PERF_EVENTS=y

#
# Kernel Performance Events And Counters
#
CONFIG_PERF_EVENTS=y
CONFIG_EVENT_PROFILE=y
# CONFIG_PERF_COUNTERS is not set
# CONFIG_DEBUG_PERF_USE_VMALLOC is not set
CONFIG_VM_EVENT_COUNTERS=y
CONFIG_PCI_QUIRKS=y
CONFIG_SLUB_DEBUG=y
# CONFIG_COMPAT_BRK is not set
# CONFIG_SLAB is not set
CONFIG_SLUB=y
# CONFIG_SLOB is not set
CONFIG_PROFILING=y
CONFIG_TRACEPOINTS=y
# CONFIG_OPROFILE is not set
CONFIG_HAVE_OPROFILE=y
CONFIG_KPROBES=y
CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS=y
CONFIG_KRETPROBES=y
CONFIG_HAVE_IOREMAP_PROT=y
CONFIG_HAVE_KPROBES=y
CONFIG_HAVE_KRETPROBES=y
CONFIG_HAVE_ARCH_TRACEHOOK=y
CONFIG_HAVE_DMA_ATTRS=y
CONFIG_HAVE_DMA_API_DEBUG=y

#
# GCOV-based kernel profiling
#
# CONFIG_GCOV_KERNEL is not set
CONFIG_SLOW_WORK=y
# CONFIG_SLOW_WORK_DEBUG is not set
# CONFIG_HAVE_GENERIC_DMA_COHERENT is not set
CONFIG_SLABINFO=y
CONFIG_RT_MUTEXES=y
CONFIG_BASE_SMALL=0
CONFIG_MODULES=y
# CONFIG_MODULE_FORCE_LOAD is not set
CONFIG_MODULE_UNLOAD=y
CONFIG_MODULE_FORCE_UNLOAD=y
# CONFIG_MODVERSIONS is not set
# CONFIG_MODULE_SRCVERSION_ALL is not set
CONFIG_STOP_MACHINE=y
CONFIG_BLOCK=y
CONFIG_BLK_DEV_BSG=y
# CONFIG_BLK_DEV_INTEGRITY is not set
CONFIG_BLOCK_COMPAT=y

#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_AS=y
CONFIG_IOSCHED_DEADLINE=y
CONFIG_IOSCHED_CFQ=y
# CONFIG_DEFAULT_AS is not set
# CONFIG_DEFAULT_DEADLINE is not set
CONFIG_DEFAULT_CFQ=y
# CONFIG_DEFAULT_NOOP is not set
CONFIG_DEFAULT_IOSCHED="cfq"
CONFIG_PREEMPT_NOTIFIERS=y
CONFIG_FREEZER=y

#
# Processor type and features
#
CONFIG_TICK_ONESHOT=y
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y
CONFIG_GENERIC_CLOCKEVENTS_BUILD=y
CONFIG_SMP=y
CONFIG_SPARSE_IRQ=y
CONFIG_X86_MPPARSE=y
CONFIG_X86_EXTENDED_PLATFORM=y
# CONFIG_X86_VSMP is not set
CONFIG_X86_SUPPORTS_MEMORY_FAILURE=y
CONFIG_SCHED_OMIT_FRAME_POINTER=y
CONFIG_PARAVIRT_GUEST=y
CONFIG_XEN=y
CONFIG_XEN_PVHVM=y
CONFIG_XEN_MAX_DOMAIN_MEMORY=128
CONFIG_XEN_SAVE_RESTORE=y
CONFIG_XEN_DEBUG_FS=y
CONFIG_SWIOTLB_XEN=y
CONFIG_MICROCODE_XEN=y
CONFIG_XEN_DOM0=y
CONFIG_XEN_PRIVILEGED_GUEST=y
CONFIG_XEN_DOM0_PCI=y
# CONFIG_XEN_PCI_PASSTHROUGH is not set
CONFIG_KVM_CLOCK=y
# CONFIG_KVM_GUEST is not set
CONFIG_PARAVIRT=y
# CONFIG_PARAVIRT_SPINLOCKS is not set
CONFIG_PARAVIRT_CLOCK=y
CONFIG_PARAVIRT_DEBUG=y
# CONFIG_MEMTEST is not set
# CONFIG_M386 is not set
# CONFIG_M486 is not set
# CONFIG_M586 is not set
# CONFIG_M586TSC is not set
# CONFIG_M586MMX is not set
# CONFIG_M686 is not set
# CONFIG_MPENTIUMII is not set
# CONFIG_MPENTIUMIII is not set
# CONFIG_MPENTIUMM is not set
# CONFIG_MPENTIUM4 is not set
# CONFIG_MK6 is not set
# CONFIG_MK7 is not set
# CONFIG_MK8 is not set
# CONFIG_MCRUSOE is not set
# CONFIG_MEFFICEON is not set
# CONFIG_MWINCHIPC6 is not set
# CONFIG_MWINCHIP3D is not set
# CONFIG_MGEODEGX1 is not set
# CONFIG_MGEODE_LX is not set
# CONFIG_MCYRIXIII is not set
# CONFIG_MVIAC3_2 is not set
# CONFIG_MVIAC7 is not set
# CONFIG_MPSC is not set
# CONFIG_MCORE2 is not set
# CONFIG_MATOM is not set
CONFIG_GENERIC_CPU=y
CONFIG_X86_CPU=y
CONFIG_X86_L1_CACHE_BYTES=64
CONFIG_X86_INTERNODE_CACHE_BYTES=64
CONFIG_X86_CMPXCHG=y
CONFIG_X86_L1_CACHE_SHIFT=6
CONFIG_X86_XADD=y
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_TSC=y
CONFIG_X86_CMPXCHG64=y
CONFIG_X86_CMOV=y
CONFIG_X86_MINIMUM_CPU_FAMILY=64
CONFIG_X86_DEBUGCTLMSR=y
CONFIG_CPU_SUP_INTEL=y
CONFIG_CPU_SUP_AMD=y
CONFIG_CPU_SUP_CENTAUR=y
# CONFIG_X86_DS is not set
CONFIG_HPET_TIMER=y
CONFIG_HPET_EMULATE_RTC=y
CONFIG_DMI=y
CONFIG_GART_IOMMU=y
# CONFIG_CALGARY_IOMMU is not set
# CONFIG_AMD_IOMMU is not set
CONFIG_SWIOTLB=y
CONFIG_IOMMU_HELPER=y
# CONFIG_IOMMU_API is not set
# CONFIG_MAXSMP is not set
CONFIG_NR_CPUS=8
CONFIG_SCHED_SMT=y
CONFIG_SCHED_MC=y
# CONFIG_IRQ_TIME_ACCOUNTING is not set
# CONFIG_PREEMPT_NONE is not set
CONFIG_PREEMPT_VOLUNTARY=y
# CONFIG_PREEMPT is not set
CONFIG_X86_LOCAL_APIC=y
CONFIG_X86_IO_APIC=y
CONFIG_X86_REROUTE_FOR_BROKEN_BOOT_IRQS=y
CONFIG_X86_MCE=y
# CONFIG_X86_MCE_INTEL is not set
# CONFIG_X86_MCE_AMD is not set
# CONFIG_X86_MCE_INJECT is not set
# CONFIG_I8K is not set
CONFIG_MICROCODE=y
CONFIG_MICROCODE_INTEL=y
CONFIG_MICROCODE_AMD=y
CONFIG_MICROCODE_OLD_INTERFACE=y
CONFIG_X86_MSR=y
CONFIG_X86_CPUID=y
CONFIG_ARCH_PHYS_ADDR_T_64BIT=y
CONFIG_DIRECT_GBPAGES=y
# CONFIG_NUMA is not set
CONFIG_ARCH_PROC_KCORE_TEXT=y
CONFIG_ARCH_SPARSEMEM_DEFAULT=y
CONFIG_ARCH_SPARSEMEM_ENABLE=y
CONFIG_ARCH_SELECT_MEMORY_MODEL=y
CONFIG_ILLEGAL_POINTER_VALUE=0xdead000000000000
CONFIG_SELECT_MEMORY_MODEL=y
# CONFIG_FLATMEM_MANUAL is not set
# CONFIG_DISCONTIGMEM_MANUAL is not set
CONFIG_SPARSEMEM_MANUAL=y
CONFIG_SPARSEMEM=y
CONFIG_HAVE_MEMORY_PRESENT=y
CONFIG_SPARSEMEM_EXTREME=y
CONFIG_SPARSEMEM_VMEMMAP_ENABLE=y
# CONFIG_SPARSEMEM_VMEMMAP is not set
# CONFIG_MEMORY_HOTPLUG is not set
CONFIG_PAGEFLAGS_EXTENDED=y
CONFIG_SPLIT_PTLOCK_CPUS=4
CONFIG_PHYS_ADDR_T_64BIT=y
CONFIG_ZONE_DMA_FLAG=1
CONFIG_BOUNCE=y
CONFIG_VIRT_TO_BUS=y
CONFIG_HAVE_MLOCK=y
CONFIG_HAVE_MLOCKED_PAGE_BIT=y
CONFIG_MMU_NOTIFIER=y
# CONFIG_KSM is not set
CONFIG_DEFAULT_MMAP_MIN_ADDR=4096
CONFIG_ARCH_SUPPORTS_MEMORY_FAILURE=y
# CONFIG_MEMORY_FAILURE is not set
CONFIG_X86_CHECK_BIOS_CORRUPTION=y
CONFIG_X86_BOOTPARAM_MEMORY_CORRUPTION_CHECK=y
CONFIG_X86_RESERVE_LOW_64K=y
CONFIG_MTRR=y
# CONFIG_MTRR_SANITIZER is not set
CONFIG_X86_PAT=y
CONFIG_ARCH_USES_PG_UNCACHED=y
CONFIG_EFI=y
CONFIG_SECCOMP=y
# CONFIG_CC_STACKPROTECTOR is not set
# CONFIG_HZ_100 is not set
# CONFIG_HZ_250 is not set
# CONFIG_HZ_300 is not set
CONFIG_HZ_1000=y
CONFIG_HZ=1000
CONFIG_SCHED_HRTICK=y
CONFIG_KEXEC=y
CONFIG_CRASH_DUMP=y
# CONFIG_KEXEC_JUMP is not set
CONFIG_PHYSICAL_START=0x1000000
CONFIG_RELOCATABLE=y
CONFIG_PHYSICAL_ALIGN=0x1000000
CONFIG_HOTPLUG_CPU=y
# CONFIG_COMPAT_VDSO is not set
# CONFIG_CMDLINE_BOOL is not set
CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y

#
# Power management and ACPI options
#
CONFIG_ARCH_HIBERNATION_HEADER=y
CONFIG_PM=y
CONFIG_PM_DEBUG=y
# CONFIG_PM_VERBOSE is not set
CONFIG_CAN_PM_TRACE=y
CONFIG_PM_TRACE=y
CONFIG_PM_TRACE_RTC=y
CONFIG_PM_SLEEP_SMP=y
CONFIG_PM_SLEEP=y
CONFIG_SUSPEND=y
# CONFIG_PM_TEST_SUSPEND is not set
CONFIG_SUSPEND_FREEZER=y
CONFIG_HIBERNATION_NVS=y
CONFIG_HIBERNATION=y
CONFIG_PM_STD_PARTITION=""
# CONFIG_PM_RUNTIME is not set
CONFIG_ACPI=y
CONFIG_ACPI_SLEEP=y
CONFIG_ACPI_PROCFS=y
CONFIG_ACPI_PROCFS_POWER=y
# CONFIG_ACPI_POWER_METER is not set
CONFIG_ACPI_SYSFS_POWER=y
CONFIG_ACPI_PROC_EVENT=y
CONFIG_ACPI_AC=y
CONFIG_ACPI_BATTERY=y
CONFIG_ACPI_BUTTON=y
CONFIG_ACPI_VIDEO=y
CONFIG_ACPI_FAN=y
CONFIG_ACPI_DOCK=y
CONFIG_ACPI_PROCESSOR=y
CONFIG_ACPI_HOTPLUG_CPU=y
# CONFIG_ACPI_PROCESSOR_AGGREGATOR is not set
CONFIG_ACPI_THERMAL=y
# CONFIG_ACPI_CUSTOM_DSDT is not set
CONFIG_ACPI_BLACKLIST_YEAR=0
# CONFIG_ACPI_DEBUG is not set
# CONFIG_ACPI_PCI_SLOT is not set
CONFIG_X86_PM_TIMER=y
CONFIG_ACPI_CONTAINER=y
# CONFIG_ACPI_SBS is not set
# CONFIG_SFI is not set

#
# CPU Frequency scaling
#
CONFIG_CPU_FREQ=y
CONFIG_CPU_FREQ_TABLE=y
CONFIG_CPU_FREQ_DEBUG=y
# CONFIG_CPU_FREQ_STAT is not set
# CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE is not set
# CONFIG_CPU_FREQ_DEFAULT_GOV_POWERSAVE is not set
CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE=y
# CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND is not set
# CONFIG_CPU_FREQ_DEFAULT_GOV_CONSERVATIVE is not set
CONFIG_CPU_FREQ_GOV_PERFORMANCE=y
# CONFIG_CPU_FREQ_GOV_POWERSAVE is not set
CONFIG_CPU_FREQ_GOV_USERSPACE=y
CONFIG_CPU_FREQ_GOV_ONDEMAND=y
# CONFIG_CPU_FREQ_GOV_CONSERVATIVE is not set

#
# CPUFreq processor drivers
#
CONFIG_X86_ACPI_CPUFREQ=y
# CONFIG_X86_POWERNOW_K8 is not set
# CONFIG_X86_SPEEDSTEP_CENTRINO is not set
# CONFIG_X86_P4_CLOCKMOD is not set

#
# shared options
#
# CONFIG_X86_SPEEDSTEP_LIB is not set
CONFIG_CPU_IDLE=y
CONFIG_CPU_IDLE_GOV_LADDER=y
CONFIG_CPU_IDLE_GOV_MENU=y

#
# Memory power savings
#
# CONFIG_I7300_IDLE is not set

#
# Bus options (PCI etc.)
#
CONFIG_PCI=y
CONFIG_PCI_DIRECT=y
CONFIG_PCI_MMCONFIG=y
CONFIG_PCI_XEN=y
CONFIG_PCI_DOMAINS=y
# CONFIG_DMAR is not set
# CONFIG_INTR_REMAP is not set
CONFIG_PCIEPORTBUS=y
# CONFIG_HOTPLUG_PCI_PCIE is not set
CONFIG_PCIEAER=y
# CONFIG_PCIE_ECRC is not set
# CONFIG_PCIEAER_INJECT is not set
# CONFIG_PCIEASPM is not set
CONFIG_ARCH_SUPPORTS_MSI=y
CONFIG_PCI_MSI=y
# CONFIG_PCI_LEGACY is not set
# CONFIG_PCI_DEBUG is not set
# CONFIG_PCI_STUB is not set
CONFIG_XEN_PCIDEV_FRONTEND=y
CONFIG_HT_IRQ=y
# CONFIG_PCI_IOV is not set
CONFIG_ISA_DMA_API=y
CONFIG_K8_NB=y
CONFIG_PCCARD=y
# CONFIG_PCMCIA_DEBUG is not set
CONFIG_PCMCIA=y
CONFIG_PCMCIA_LOAD_CIS=y
CONFIG_PCMCIA_IOCTL=y
CONFIG_CARDBUS=y

#
# PC-card bridges
#
CONFIG_YENTA=y
CONFIG_YENTA_O2=y
CONFIG_YENTA_RICOH=y
CONFIG_YENTA_TI=y
CONFIG_YENTA_ENE_TUNE=y
CONFIG_YENTA_TOSHIBA=y
# CONFIG_PD6729 is not set
# CONFIG_I82092 is not set
CONFIG_PCCARD_NONSTATIC=y
CONFIG_HOTPLUG_PCI=y
# CONFIG_HOTPLUG_PCI_FAKE is not set
# CONFIG_HOTPLUG_PCI_ACPI is not set
# CONFIG_HOTPLUG_PCI_CPCI is not set
# CONFIG_HOTPLUG_PCI_SHPC is not set

#
# Executable file formats / Emulations
#
CONFIG_BINFMT_ELF=y
CONFIG_COMPAT_BINFMT_ELF=y
CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS=y
# CONFIG_HAVE_AOUT is not set
CONFIG_BINFMT_MISC=y
CONFIG_IA32_EMULATION=y
# CONFIG_IA32_AOUT is not set
CONFIG_COMPAT=y
CONFIG_COMPAT_FOR_U64_ALIGNMENT=y
CONFIG_SYSVIPC_COMPAT=y
CONFIG_NET=y
CONFIG_COMPAT_NETLINK_MESSAGES=y

#
# Networking options
#
CONFIG_PACKET=y
CONFIG_PACKET_MMAP=y
CONFIG_UNIX=y
CONFIG_XFRM=y
CONFIG_XFRM_USER=y
# CONFIG_XFRM_SUB_POLICY is not set
# CONFIG_XFRM_MIGRATE is not set
# CONFIG_XFRM_STATISTICS is not set
CONFIG_XFRM_IPCOMP=y
CONFIG_NET_KEY=y
# CONFIG_NET_KEY_MIGRATE is not set
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
CONFIG_IP_ADVANCED_ROUTER=y
CONFIG_ASK_IP_FIB_HASH=y
# CONFIG_IP_FIB_TRIE is not set
CONFIG_IP_FIB_HASH=y
CONFIG_IP_MULTIPLE_TABLES=y
CONFIG_IP_ROUTE_MULTIPATH=y
CONFIG_IP_ROUTE_VERBOSE=y
CONFIG_IP_PNP=y
CONFIG_IP_PNP_DHCP=y
CONFIG_IP_PNP_BOOTP=y
CONFIG_IP_PNP_RARP=y
# CONFIG_NET_IPIP is not set
# CONFIG_NET_IPGRE is not set
CONFIG_IP_MROUTE=y
CONFIG_IP_PIMSM_V1=y
CONFIG_IP_PIMSM_V2=y
# CONFIG_ARPD is not set
CONFIG_SYN_COOKIES=y
CONFIG_INET_AH=y
CONFIG_INET_ESP=y
CONFIG_INET_IPCOMP=y
CONFIG_INET_XFRM_TUNNEL=y
CONFIG_INET_TUNNEL=y
CONFIG_INET_XFRM_MODE_TRANSPORT=y
CONFIG_INET_XFRM_MODE_TUNNEL=y
# CONFIG_INET_XFRM_MODE_BEET is not set
CONFIG_INET_LRO=y
# CONFIG_INET_DIAG is not set
CONFIG_TCP_CONG_ADVANCED=y
# CONFIG_TCP_CONG_BIC is not set
CONFIG_TCP_CONG_CUBIC=y
# CONFIG_TCP_CONG_WESTWOOD is not set
# CONFIG_TCP_CONG_HTCP is not set
# CONFIG_TCP_CONG_HSTCP is not set
# CONFIG_TCP_CONG_HYBLA is not set
# CONFIG_TCP_CONG_VEGAS is not set
# CONFIG_TCP_CONG_SCALABLE is not set
# CONFIG_TCP_CONG_LP is not set
# CONFIG_TCP_CONG_VENO is not set
# CONFIG_TCP_CONG_YEAH is not set
# CONFIG_TCP_CONG_ILLINOIS is not set
# CONFIG_DEFAULT_BIC is not set
CONFIG_DEFAULT_CUBIC=y
# CONFIG_DEFAULT_HTCP is not set
# CONFIG_DEFAULT_VEGAS is not set
# CONFIG_DEFAULT_WESTWOOD is not set
# CONFIG_DEFAULT_RENO is not set
CONFIG_DEFAULT_TCP_CONG="cubic"
CONFIG_TCP_MD5SIG=y
CONFIG_IPV6=y
# CONFIG_IPV6_PRIVACY is not set
# CONFIG_IPV6_ROUTER_PREF is not set
# CONFIG_IPV6_OPTIMISTIC_DAD is not set
CONFIG_INET6_AH=y
CONFIG_INET6_ESP=y
# CONFIG_INET6_IPCOMP is not set
# CONFIG_IPV6_MIP6 is not set
# CONFIG_INET6_XFRM_TUNNEL is not set
# CONFIG_INET6_TUNNEL is not set
CONFIG_INET6_XFRM_MODE_TRANSPORT=y
CONFIG_INET6_XFRM_MODE_TUNNEL=y
CONFIG_INET6_XFRM_MODE_BEET=y
# CONFIG_INET6_XFRM_MODE_ROUTEOPTIMIZATION is not set
CONFIG_IPV6_SIT=y
CONFIG_IPV6_NDISC_NODETYPE=y
# CONFIG_IPV6_TUNNEL is not set
# CONFIG_IPV6_MULTIPLE_TABLES is not set
# CONFIG_IPV6_MROUTE is not set
CONFIG_NETLABEL=y
CONFIG_NETWORK_SECMARK=y
CONFIG_NETFILTER=y
# CONFIG_NETFILTER_DEBUG is not set
CONFIG_NETFILTER_ADVANCED=y
CONFIG_BRIDGE_NETFILTER=y

#
# Core Netfilter Configuration
#
CONFIG_NETFILTER_NETLINK=y
# CONFIG_NETFILTER_NETLINK_QUEUE is not set
CONFIG_NETFILTER_NETLINK_LOG=y
CONFIG_NF_CONNTRACK=y
# CONFIG_NF_CT_ACCT is not set
CONFIG_NF_CONNTRACK_MARK=y
CONFIG_NF_CONNTRACK_SECMARK=y
# CONFIG_NF_CONNTRACK_EVENTS is not set
# CONFIG_NF_CT_PROTO_DCCP is not set
CONFIG_NF_CT_PROTO_GRE=y
# CONFIG_NF_CT_PROTO_SCTP is not set
# CONFIG_NF_CT_PROTO_UDPLITE is not set
# CONFIG_NF_CONNTRACK_AMANDA is not set
CONFIG_NF_CONNTRACK_FTP=y
CONFIG_NF_CONNTRACK_H323=y
CONFIG_NF_CONNTRACK_IRC=y
CONFIG_NF_CONNTRACK_NETBIOS_NS=y
CONFIG_NF_CONNTRACK_PPTP=y
# CONFIG_NF_CONNTRACK_SANE is not set
CONFIG_NF_CONNTRACK_SIP=y
CONFIG_NF_CONNTRACK_TFTP=y
CONFIG_NF_CT_NETLINK=y
# CONFIG_NETFILTER_TPROXY is not set
CONFIG_NETFILTER_XTABLES=y
CONFIG_NETFILTER_XT_TARGET_CLASSIFY=y
CONFIG_NETFILTER_XT_TARGET_CONNMARK=y
CONFIG_NETFILTER_XT_TARGET_CONNSECMARK=y
# CONFIG_NETFILTER_XT_TARGET_DSCP is not set
# CONFIG_NETFILTER_XT_TARGET_HL is not set
# CONFIG_NETFILTER_XT_TARGET_LED is not set
CONFIG_NETFILTER_XT_TARGET_MARK=y
CONFIG_NETFILTER_XT_TARGET_NFLOG=y
# CONFIG_NETFILTER_XT_TARGET_NFQUEUE is not set
# CONFIG_NETFILTER_XT_TARGET_RATEEST is not set
CONFIG_NETFILTER_XT_TARGET_SECMARK=y
CONFIG_NETFILTER_XT_TARGET_TCPMSS=y
# CONFIG_NETFILTER_XT_TARGET_TCPOPTSTRIP is not set
# CONFIG_NETFILTER_XT_MATCH_CLUSTER is not set
# CONFIG_NETFILTER_XT_MATCH_COMMENT is not set
# CONFIG_NETFILTER_XT_MATCH_CONNBYTES is not set
CONFIG_NETFILTER_XT_MATCH_CONNLIMIT=y
CONFIG_NETFILTER_XT_MATCH_CONNMARK=y
CONFIG_NETFILTER_XT_MATCH_CONNTRACK=y
# CONFIG_NETFILTER_XT_MATCH_DCCP is not set
# CONFIG_NETFILTER_XT_MATCH_DSCP is not set
CONFIG_NETFILTER_XT_MATCH_ESP=y
# CONFIG_NETFILTER_XT_MATCH_HASHLIMIT is not set
CONFIG_NETFILTER_XT_MATCH_HELPER=y
# CONFIG_NETFILTER_XT_MATCH_HL is not set
CONFIG_NETFILTER_XT_MATCH_IPRANGE=y
# CONFIG_NETFILTER_XT_MATCH_LENGTH is not set
CONFIG_NETFILTER_XT_MATCH_LIMIT=y
CONFIG_NETFILTER_XT_MATCH_MAC=y
CONFIG_NETFILTER_XT_MATCH_MARK=y
CONFIG_NETFILTER_XT_MATCH_MULTIPORT=y
# CONFIG_NETFILTER_XT_MATCH_OWNER is not set
CONFIG_NETFILTER_XT_MATCH_POLICY=y
# CONFIG_NETFILTER_XT_MATCH_PHYSDEV is not set
# CONFIG_NETFILTER_XT_MATCH_PKTTYPE is not set
# CONFIG_NETFILTER_XT_MATCH_QUOTA is not set
# CONFIG_NETFILTER_XT_MATCH_RATEEST is not set
# CONFIG_NETFILTER_XT_MATCH_REALM is not set
CONFIG_NETFILTER_XT_MATCH_RECENT=y
# CONFIG_NETFILTER_XT_MATCH_RECENT_PROC_COMPAT is not set
# CONFIG_NETFILTER_XT_MATCH_SCTP is not set
CONFIG_NETFILTER_XT_MATCH_STATE=y
# CONFIG_NETFILTER_XT_MATCH_STATISTIC is not set
CONFIG_NETFILTER_XT_MATCH_STRING=y
CONFIG_NETFILTER_XT_MATCH_TCPMSS=y
CONFIG_NETFILTER_XT_MATCH_TIME=y
# CONFIG_NETFILTER_XT_MATCH_U32 is not set
# CONFIG_NETFILTER_XT_MATCH_OSF is not set
# CONFIG_IP_VS is not set

#
# IP: Netfilter Configuration
#
CONFIG_NF_DEFRAG_IPV4=y
CONFIG_NF_CONNTRACK_IPV4=y
CONFIG_NF_CONNTRACK_PROC_COMPAT=y
# CONFIG_IP_NF_QUEUE is not set
CONFIG_IP_NF_IPTABLES=y
# CONFIG_IP_NF_MATCH_ADDRTYPE is not set
# CONFIG_IP_NF_MATCH_AH is not set
# CONFIG_IP_NF_MATCH_ECN is not set
# CONFIG_IP_NF_MATCH_TTL is not set
CONFIG_IP_NF_FILTER=y
CONFIG_IP_NF_TARGET_REJECT=y
CONFIG_IP_NF_TARGET_LOG=y
CONFIG_IP_NF_TARGET_ULOG=y
CONFIG_NF_NAT=y
CONFIG_NF_NAT_NEEDED=y
CONFIG_IP_NF_TARGET_MASQUERADE=y
CONFIG_IP_NF_TARGET_NETMAP=y
CONFIG_IP_NF_TARGET_REDIRECT=y
# CONFIG_NF_NAT_SNMP_BASIC is not set
CONFIG_NF_NAT_PROTO_GRE=y
CONFIG_NF_NAT_FTP=y
CONFIG_NF_NAT_IRC=y
CONFIG_NF_NAT_TFTP=y
# CONFIG_NF_NAT_AMANDA is not set
CONFIG_NF_NAT_PPTP=y
CONFIG_NF_NAT_H323=y
CONFIG_NF_NAT_SIP=y
CONFIG_IP_NF_MANGLE=y
# CONFIG_IP_NF_TARGET_CLUSTERIP is not set
# CONFIG_IP_NF_TARGET_ECN is not set
# CONFIG_IP_NF_TARGET_TTL is not set
# CONFIG_IP_NF_RAW is not set
# CONFIG_IP_NF_SECURITY is not set
# CONFIG_IP_NF_ARPTABLES is not set

#
# IPv6: Netfilter Configuration
#
CONFIG_NF_CONNTRACK_IPV6=y
# CONFIG_IP6_NF_QUEUE is not set
CONFIG_IP6_NF_IPTABLES=y
# CONFIG_IP6_NF_MATCH_AH is not set
# CONFIG_IP6_NF_MATCH_EUI64 is not set
# CONFIG_IP6_NF_MATCH_FRAG is not set
# CONFIG_IP6_NF_MATCH_OPTS is not set
# CONFIG_IP6_NF_MATCH_HL is not set
CONFIG_IP6_NF_MATCH_IPV6HEADER=y
# CONFIG_IP6_NF_MATCH_MH is not set
# CONFIG_IP6_NF_MATCH_RT is not set
# CONFIG_IP6_NF_TARGET_HL is not set
CONFIG_IP6_NF_TARGET_LOG=y
CONFIG_IP6_NF_FILTER=y
CONFIG_IP6_NF_TARGET_REJECT=y
CONFIG_IP6_NF_MANGLE=y
# CONFIG_IP6_NF_RAW is not set
# CONFIG_IP6_NF_SECURITY is not set
# CONFIG_BRIDGE_NF_EBTABLES is not set
# CONFIG_IP_DCCP is not set
# CONFIG_IP_SCTP is not set
# CONFIG_RDS is not set
# CONFIG_TIPC is not set
# CONFIG_ATM is not set
CONFIG_STP=y
CONFIG_BRIDGE=y
# CONFIG_NET_DSA is not set
# CONFIG_VLAN_8021Q is not set
# CONFIG_DECNET is not set
CONFIG_LLC=y
# CONFIG_LLC2 is not set
# CONFIG_IPX is not set
# CONFIG_ATALK is not set
# CONFIG_X25 is not set
# CONFIG_LAPB is not set
# CONFIG_ECONET is not set
# CONFIG_WAN_ROUTER is not set
# CONFIG_PHONET is not set
# CONFIG_IEEE802154 is not set
CONFIG_NET_SCHED=y

#
# Queueing/Scheduling
#
# CONFIG_NET_SCH_CBQ is not set
# CONFIG_NET_SCH_HTB is not set
# CONFIG_NET_SCH_HFSC is not set
# CONFIG_NET_SCH_PRIO is not set
# CONFIG_NET_SCH_MULTIQ is not set
# CONFIG_NET_SCH_RED is not set
# CONFIG_NET_SCH_SFQ is not set
# CONFIG_NET_SCH_TEQL is not set
# CONFIG_NET_SCH_TBF is not set
# CONFIG_NET_SCH_GRED is not set
# CONFIG_NET_SCH_DSMARK is not set
# CONFIG_NET_SCH_NETEM is not set
# CONFIG_NET_SCH_DRR is not set
# CONFIG_NET_SCH_INGRESS is not set
# CONFIG_NET_SCH_PLUG is not set

#
# Classification
#
CONFIG_NET_CLS=y
# CONFIG_NET_CLS_BASIC is not set
# CONFIG_NET_CLS_TCINDEX is not set
# CONFIG_NET_CLS_ROUTE4 is not set
# CONFIG_NET_CLS_FW is not set
# CONFIG_NET_CLS_U32 is not set
# CONFIG_NET_CLS_RSVP is not set
# CONFIG_NET_CLS_RSVP6 is not set
# CONFIG_NET_CLS_FLOW is not set
# CONFIG_NET_CLS_CGROUP is not set
CONFIG_NET_EMATCH=y
CONFIG_NET_EMATCH_STACK=32
# CONFIG_NET_EMATCH_CMP is not set
# CONFIG_NET_EMATCH_NBYTE is not set
# CONFIG_NET_EMATCH_U32 is not set
# CONFIG_NET_EMATCH_META is not set
# CONFIG_NET_EMATCH_TEXT is not set
CONFIG_NET_CLS_ACT=y
# CONFIG_NET_ACT_POLICE is not set
# CONFIG_NET_ACT_GACT is not set
# CONFIG_NET_ACT_MIRRED is not set
# CONFIG_NET_ACT_IPT is not set
# CONFIG_NET_ACT_NAT is not set
# CONFIG_NET_ACT_PEDIT is not set
# CONFIG_NET_ACT_SIMP is not set
# CONFIG_NET_ACT_SKBEDIT is not set
CONFIG_NET_SCH_FIFO=y
# CONFIG_DCB is not set

#
# Network testing
#
# CONFIG_NET_PKTGEN is not set
# CONFIG_NET_TCPPROBE is not set
# CONFIG_NET_DROP_MONITOR is not set
CONFIG_HAMRADIO=y

#
# Packet Radio protocols
#
# CONFIG_AX25 is not set
# CONFIG_CAN is not set
# CONFIG_IRDA is not set
# CONFIG_BT is not set
# CONFIG_AF_RXRPC is not set
CONFIG_FIB_RULES=y
CONFIG_WIRELESS=y
CONFIG_CFG80211=y
# CONFIG_NL80211_TESTMODE is not set
# CONFIG_CFG80211_DEVELOPER_WARNINGS is not set
# CONFIG_CFG80211_REG_DEBUG is not set
CONFIG_CFG80211_DEFAULT_PS=y
CONFIG_CFG80211_DEFAULT_PS_VALUE=1
# CONFIG_CFG80211_DEBUGFS is not set
CONFIG_WIRELESS_OLD_REGULATORY=y
CONFIG_WIRELESS_EXT=y
CONFIG_WIRELESS_EXT_SYSFS=y
# CONFIG_LIB80211 is not set
CONFIG_MAC80211=y
CONFIG_MAC80211_HAS_RC=y
CONFIG_MAC80211_RC_MINSTREL=y
# CONFIG_MAC80211_RC_DEFAULT_PID is not set
CONFIG_MAC80211_RC_DEFAULT_MINSTREL=y
CONFIG_MAC80211_RC_DEFAULT="minstrel"
# CONFIG_MAC80211_MESH is not set
CONFIG_MAC80211_LEDS=y
# CONFIG_MAC80211_DEBUGFS is not set
# CONFIG_MAC80211_DEBUG_MENU is not set
# CONFIG_WIMAX is not set
CONFIG_RFKILL=y
CONFIG_RFKILL_LEDS=y
CONFIG_RFKILL_INPUT=y
# CONFIG_NET_9P is not set

#
# Device Drivers
#

#
# Generic Driver Options
#
CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
# CONFIG_DEVTMPFS is not set
CONFIG_STANDALONE=y
CONFIG_PREVENT_FIRMWARE_BUILD=y
CONFIG_FW_LOADER=y
CONFIG_FIRMWARE_IN_KERNEL=y
CONFIG_EXTRA_FIRMWARE=""
# CONFIG_DEBUG_DRIVER is not set
CONFIG_DEBUG_DEVRES=y
CONFIG_SYS_HYPERVISOR=y
CONFIG_CONNECTOR=y
CONFIG_PROC_EVENTS=y
# CONFIG_MTD is not set
# CONFIG_PARPORT is not set
CONFIG_PNP=y
CONFIG_PNP_DEBUG_MESSAGES=y

#
# Protocols
#
CONFIG_PNPACPI=y
CONFIG_BLK_DEV=y
# CONFIG_BLK_DEV_FD is not set
# CONFIG_BLK_CPQ_DA is not set
CONFIG_BLK_CPQ_CISS_DA=m
# CONFIG_CISS_SCSI_TAPE is not set
# CONFIG_BLK_DEV_DAC960 is not set
# CONFIG_BLK_DEV_UMEM is not set
# CONFIG_BLK_DEV_COW_COMMON is not set
CONFIG_BLK_DEV_LOOP=y
# CONFIG_BLK_DEV_CRYPTOLOOP is not set
# CONFIG_BLK_DEV_NBD is not set
# CONFIG_BLK_DEV_SX8 is not set
# CONFIG_BLK_DEV_UB is not set
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_COUNT=16
CONFIG_BLK_DEV_RAM_SIZE=16384
# CONFIG_BLK_DEV_XIP is not set
# CONFIG_CDROM_PKTCDVD is not set
# CONFIG_ATA_OVER_ETH is not set
CONFIG_XEN_BLKDEV_FRONTEND=y
# CONFIG_BLK_DEV_HD is not set
CONFIG_MISC_DEVICES=y
# CONFIG_IBM_ASM is not set
# CONFIG_PHANTOM is not set
# CONFIG_SGI_IOC4 is not set
# CONFIG_TIFM_CORE is not set
# CONFIG_ICS932S401 is not set
# CONFIG_ENCLOSURE_SERVICES is not set
# CONFIG_HP_ILO is not set
# CONFIG_ISL29003 is not set
# CONFIG_C2PORT is not set

#
# EEPROM support
#
# CONFIG_EEPROM_AT24 is not set
# CONFIG_EEPROM_LEGACY is not set
# CONFIG_EEPROM_MAX6875 is not set
# CONFIG_EEPROM_93CX6 is not set
# CONFIG_CB710_CORE is not set
CONFIG_HAVE_IDE=y
# CONFIG_IDE is not set

#
# SCSI device support
#
# CONFIG_RAID_ATTRS is not set
CONFIG_SCSI=y
CONFIG_SCSI_DMA=y
# CONFIG_SCSI_TGT is not set
# CONFIG_SCSI_NETLINK is not set
CONFIG_SCSI_PROC_FS=y

#
# SCSI support type (disk, tape, CD-ROM)
#
CONFIG_BLK_DEV_SD=y
# CONFIG_CHR_DEV_ST is not set
# CONFIG_CHR_DEV_OSST is not set
CONFIG_BLK_DEV_SR=y
CONFIG_BLK_DEV_SR_VENDOR=y
CONFIG_CHR_DEV_SG=y
# CONFIG_CHR_DEV_SCH is not set
# CONFIG_SCSI_MULTI_LUN is not set
CONFIG_SCSI_CONSTANTS=y
# CONFIG_SCSI_LOGGING is not set
# CONFIG_SCSI_SCAN_ASYNC is not set
CONFIG_SCSI_WAIT_SCAN=m

#
# SCSI Transports
#
CONFIG_SCSI_SPI_ATTRS=y
# CONFIG_SCSI_FC_ATTRS is not set
CONFIG_SCSI_ISCSI_ATTRS=m
CONFIG_SCSI_SAS_ATTRS=m
# CONFIG_SCSI_SAS_LIBSAS is not set
# CONFIG_SCSI_SRP_ATTRS is not set
CONFIG_SCSI_LOWLEVEL=y
CONFIG_ISCSI_TCP=m
# CONFIG_SCSI_CXGB3_ISCSI is not set
# CONFIG_SCSI_BNX2_ISCSI is not set
# CONFIG_BE2ISCSI is not set
# CONFIG_BLK_DEV_3W_XXXX_RAID is not set
CONFIG_SCSI_3W_9XXX=y
# CONFIG_SCSI_ACARD is not set
# CONFIG_SCSI_AACRAID is not set
# CONFIG_SCSI_AIC7XXX is not set
# CONFIG_SCSI_AIC7XXX_OLD is not set
# CONFIG_SCSI_AIC79XX is not set
# CONFIG_SCSI_AIC94XX is not set
# CONFIG_SCSI_MVSAS is not set
# CONFIG_SCSI_DPT_I2O is not set
# CONFIG_SCSI_ADVANSYS is not set
# CONFIG_SCSI_ARCMSR is not set
# CONFIG_MEGARAID_NEWGEN is not set
# CONFIG_MEGARAID_LEGACY is not set
# CONFIG_MEGARAID_SAS is not set
# CONFIG_SCSI_MPT2SAS is not set
# CONFIG_SCSI_HPTIOP is not set
# CONFIG_SCSI_BUSLOGIC is not set
# CONFIG_LIBFC is not set
# CONFIG_LIBFCOE is not set
# CONFIG_FCOE is not set
# CONFIG_FCOE_FNIC is not set
# CONFIG_SCSI_DMX3191D is not set
# CONFIG_SCSI_EATA is not set
# CONFIG_SCSI_FUTURE_DOMAIN is not set
# CONFIG_SCSI_GDTH is not set
# CONFIG_SCSI_IPS is not set
# CONFIG_SCSI_INITIO is not set
# CONFIG_SCSI_INIA100 is not set
# CONFIG_SCSI_STEX is not set
# CONFIG_SCSI_SYM53C8XX_2 is not set
# CONFIG_SCSI_IPR is not set
# CONFIG_SCSI_QLOGIC_1280 is not set
# CONFIG_SCSI_QLA_FC is not set
# CONFIG_SCSI_QLA_ISCSI is not set
# CONFIG_SCSI_LPFC is not set
# CONFIG_SCSI_DC395x is not set
# CONFIG_SCSI_DC390T is not set
# CONFIG_SCSI_DEBUG is not set
# CONFIG_SCSI_PMCRAID is not set
# CONFIG_SCSI_SRP is not set
# CONFIG_SCSI_BFA_FC is not set
# CONFIG_SCSI_LOWLEVEL_PCMCIA is not set
# CONFIG_SCSI_DH is not set
# CONFIG_SCSI_OSD_INITIATOR is not set
CONFIG_ATA=y
# CONFIG_ATA_NONSTANDARD is not set
CONFIG_ATA_VERBOSE_ERROR=y
CONFIG_ATA_ACPI=y
CONFIG_SATA_PMP=y
CONFIG_SATA_AHCI=y
# CONFIG_SATA_SIL24 is not set
CONFIG_ATA_SFF=y
# CONFIG_SATA_SVW is not set
CONFIG_ATA_PIIX=y
# CONFIG_SATA_MV is not set
# CONFIG_SATA_NV is not set
# CONFIG_PDC_ADMA is not set
# CONFIG_SATA_QSTOR is not set
# CONFIG_SATA_PROMISE is not set
# CONFIG_SATA_SX4 is not set
# CONFIG_SATA_SIL is not set
# CONFIG_SATA_SIS is not set
# CONFIG_SATA_ULI is not set
# CONFIG_SATA_VIA is not set
# CONFIG_SATA_VITESSE is not set
# CONFIG_SATA_INIC162X is not set
# CONFIG_PATA_ACPI is not set
# CONFIG_PATA_ALI is not set
CONFIG_PATA_AMD=y
# CONFIG_PATA_ARTOP is not set
# CONFIG_PATA_ATP867X is not set
# CONFIG_PATA_ATIIXP is not set
# CONFIG_PATA_CMD640_PCI is not set
# CONFIG_PATA_CMD64X is not set
# CONFIG_PATA_CS5520 is not set
# CONFIG_PATA_CS5530 is not set
# CONFIG_PATA_CYPRESS is not set
# CONFIG_PATA_EFAR is not set
CONFIG_ATA_GENERIC=y
# CONFIG_PATA_HPT366 is not set
# CONFIG_PATA_HPT37X is not set
# CONFIG_PATA_HPT3X2N is not set
# CONFIG_PATA_HPT3X3 is not set
# CONFIG_PATA_IT821X is not set
# CONFIG_PATA_IT8213 is not set
# CONFIG_PATA_JMICRON is not set
# CONFIG_PATA_TRIFLEX is not set
# CONFIG_PATA_MARVELL is not set
CONFIG_PATA_MPIIX=y
CONFIG_PATA_OLDPIIX=y
# CONFIG_PATA_NETCELL is not set
# CONFIG_PATA_NINJA32 is not set
# CONFIG_PATA_NS87410 is not set
# CONFIG_PATA_NS87415 is not set
# CONFIG_PATA_OPTI is not set
# CONFIG_PATA_OPTIDMA is not set
# CONFIG_PATA_PCMCIA is not set
# CONFIG_PATA_PDC_OLD is not set
# CONFIG_PATA_RADISYS is not set
# CONFIG_PATA_RDC is not set
# CONFIG_PATA_RZ1000 is not set
# CONFIG_PATA_SC1200 is not set
# CONFIG_PATA_SERVERWORKS is not set
# CONFIG_PATA_PDC2027X is not set
# CONFIG_PATA_SIL680 is not set
# CONFIG_PATA_SIS is not set
# CONFIG_PATA_VIA is not set
# CONFIG_PATA_WINBOND is not set
CONFIG_PATA_SCH=y
CONFIG_MD=y
CONFIG_BLK_DEV_MD=y
CONFIG_MD_AUTODETECT=y
# CONFIG_MD_LINEAR is not set
# CONFIG_MD_RAID0 is not set
CONFIG_MD_RAID1=m
# CONFIG_MD_RAID10 is not set
# CONFIG_MD_RAID456 is not set
# CONFIG_MD_MULTIPATH is not set
# CONFIG_MD_FAULTY is not set
CONFIG_BLK_DEV_DM=y
# CONFIG_DM_DEBUG is not set
# CONFIG_DM_CRYPT is not set
# CONFIG_DM_SNAPSHOT is not set
CONFIG_DM_MIRROR=y
# CONFIG_DM_LOG_USERSPACE is not set
CONFIG_DM_ZERO=y
# CONFIG_DM_MULTIPATH is not set
# CONFIG_DM_DELAY is not set
# CONFIG_DM_UEVENT is not set
CONFIG_FUSION=y
CONFIG_FUSION_SPI=m
# CONFIG_FUSION_FC is not set
CONFIG_FUSION_SAS=m
CONFIG_FUSION_MAX_SGE=128
# CONFIG_FUSION_CTL is not set
# CONFIG_FUSION_LOGGING is not set

#
# IEEE 1394 (FireWire) support
#

#
# You can enable one or both FireWire driver stacks.
#

#
# See the help texts for more information.
#
# CONFIG_FIREWIRE is not set
# CONFIG_IEEE1394 is not set
# CONFIG_I2O is not set
CONFIG_MACINTOSH_DRIVERS=y
CONFIG_MAC_EMUMOUSEBTN=y
CONFIG_NETDEVICES=y
# CONFIG_IFB is not set
# CONFIG_DUMMY is not set
# CONFIG_BONDING is not set
# CONFIG_MACVLAN is not set
# CONFIG_EQUALIZER is not set
CONFIG_TUN=y
# CONFIG_VETH is not set
# CONFIG_NET_SB1000 is not set
# CONFIG_ARCNET is not set
CONFIG_PHYLIB=y

#
# MII PHY device drivers
#
# CONFIG_MARVELL_PHY is not set
# CONFIG_DAVICOM_PHY is not set
# CONFIG_QSEMI_PHY is not set
# CONFIG_LXT_PHY is not set
# CONFIG_CICADA_PHY is not set
# CONFIG_VITESSE_PHY is not set
# CONFIG_SMSC_PHY is not set
# CONFIG_BROADCOM_PHY is not set
# CONFIG_ICPLUS_PHY is not set
# CONFIG_REALTEK_PHY is not set
# CONFIG_NATIONAL_PHY is not set
# CONFIG_STE10XP is not set
# CONFIG_LSI_ET1011C_PHY is not set
# CONFIG_FIXED_PHY is not set
# CONFIG_MDIO_BITBANG is not set
CONFIG_NET_ETHERNET=y
CONFIG_MII=y
# CONFIG_HAPPYMEAL is not set
# CONFIG_SUNGEM is not set
# CONFIG_CASSINI is not set
CONFIG_NET_VENDOR_3COM=y
# CONFIG_VORTEX is not set
# CONFIG_TYPHOON is not set
# CONFIG_ETHOC is not set
# CONFIG_DNET is not set
CONFIG_NET_TULIP=y
# CONFIG_DE2104X is not set
# CONFIG_TULIP is not set
# CONFIG_DE4X5 is not set
# CONFIG_WINBOND_840 is not set
# CONFIG_DM9102 is not set
# CONFIG_ULI526X is not set
# CONFIG_PCMCIA_XIRCOM is not set
# CONFIG_HP100 is not set
# CONFIG_IBM_NEW_EMAC_ZMII is not set
# CONFIG_IBM_NEW_EMAC_RGMII is not set
# CONFIG_IBM_NEW_EMAC_TAH is not set
# CONFIG_IBM_NEW_EMAC_EMAC4 is not set
# CONFIG_IBM_NEW_EMAC_NO_FLOW_CTRL is not set
# CONFIG_IBM_NEW_EMAC_MAL_CLR_ICINTSTAT is not set
# CONFIG_IBM_NEW_EMAC_MAL_COMMON_ERR is not set
CONFIG_NET_PCI=y
# CONFIG_PCNET32 is not set
# CONFIG_AMD8111_ETH is not set
# CONFIG_ADAPTEC_STARFIRE is not set
# CONFIG_B44 is not set
CONFIG_FORCEDETH=y
# CONFIG_FORCEDETH_NAPI is not set
CONFIG_E100=y
# CONFIG_FEALNX is not set
# CONFIG_NATSEMI is not set
CONFIG_NE2K_PCI=y
# CONFIG_8139CP is not set
CONFIG_8139TOO=y
# CONFIG_8139TOO_PIO is not set
# CONFIG_8139TOO_TUNE_TWISTER is not set
# CONFIG_8139TOO_8129 is not set
# CONFIG_8139_OLD_RX_RESET is not set
# CONFIG_R6040 is not set
# CONFIG_SIS900 is not set
# CONFIG_EPIC100 is not set
# CONFIG_SMSC9420 is not set
# CONFIG_SUNDANCE is not set
# CONFIG_TLAN is not set
# CONFIG_KS8842 is not set
# CONFIG_KS8851_MLL is not set
# CONFIG_VIA_RHINE is not set
# CONFIG_SC92031 is not set
# CONFIG_ATL2 is not set
CONFIG_NETDEV_1000=y
# CONFIG_ACENIC is not set
# CONFIG_DL2K is not set
CONFIG_E1000=y
CONFIG_E1000E=y
# CONFIG_IP1000 is not set
# CONFIG_IGB is not set
# CONFIG_IGBVF is not set
# CONFIG_NS83820 is not set
# CONFIG_HAMACHI is not set
# CONFIG_YELLOWFIN is not set
CONFIG_R8169=y
# CONFIG_SIS190 is not set
# CONFIG_SKGE is not set
CONFIG_SKY2=y
# CONFIG_SKY2_DEBUG is not set
# CONFIG_VIA_VELOCITY is not set
CONFIG_TIGON3=y
CONFIG_BNX2=y
# CONFIG_CNIC is not set
# CONFIG_QLA3XXX is not set
# CONFIG_ATL1 is not set
# CONFIG_ATL1E is not set
# CONFIG_ATL1C is not set
# CONFIG_JME is not set
CONFIG_NETDEV_10000=y
# CONFIG_CHELSIO_T1 is not set
CONFIG_CHELSIO_T3_DEPENDS=y
# CONFIG_CHELSIO_T3 is not set
# CONFIG_ENIC is not set
# CONFIG_IXGBE is not set
# CONFIG_IXGB is not set
# CONFIG_S2IO is not set
# CONFIG_VXGE is not set
# CONFIG_MYRI10GE is not set
# CONFIG_NETXEN_NIC is not set
# CONFIG_NIU is not set
# CONFIG_MLX4_EN is not set
# CONFIG_MLX4_CORE is not set
# CONFIG_TEHUTI is not set
# CONFIG_BNX2X is not set
# CONFIG_QLGE is not set
# CONFIG_SFC is not set
# CONFIG_BE2NET is not set
CONFIG_TR=y
# CONFIG_IBMOL is not set
# CONFIG_3C359 is not set
# CONFIG_TMS380TR is not set
CONFIG_WLAN=y
# CONFIG_WLAN_PRE80211 is not set
CONFIG_WLAN_80211=y
# CONFIG_PCMCIA_RAYCS is not set
# CONFIG_LIBERTAS is not set
# CONFIG_LIBERTAS_THINFIRM is not set
# CONFIG_AIRO is not set
# CONFIG_ATMEL is not set
# CONFIG_AT76C50X_USB is not set
# CONFIG_AIRO_CS is not set
# CONFIG_PCMCIA_WL3501 is not set
# CONFIG_PRISM54 is not set
# CONFIG_USB_ZD1201 is not set
# CONFIG_USB_NET_RNDIS_WLAN is not set
# CONFIG_RTL8180 is not set
# CONFIG_RTL8187 is not set
# CONFIG_ADM8211 is not set
# CONFIG_MAC80211_HWSIM is not set
# CONFIG_MWL8K is not set
# CONFIG_P54_COMMON is not set
# CONFIG_ATH_COMMON is not set
# CONFIG_IPW2100 is not set
# CONFIG_IPW2200 is not set
# CONFIG_IWLWIFI is not set
# CONFIG_HOSTAP is not set
# CONFIG_B43 is not set
# CONFIG_B43LEGACY is not set
# CONFIG_ZD1211RW is not set
# CONFIG_RT2X00 is not set
# CONFIG_HERMES is not set
# CONFIG_WL12XX is not set

#
# Enable WiMAX (Networking options) to see the WiMAX drivers
#

#
# USB Network Adapters
#
# CONFIG_USB_CATC is not set
# CONFIG_USB_KAWETH is not set
# CONFIG_USB_PEGASUS is not set
# CONFIG_USB_RTL8150 is not set
# CONFIG_USB_USBNET is not set
# CONFIG_USB_HSO is not set
CONFIG_NET_PCMCIA=y
# CONFIG_PCMCIA_3C589 is not set
# CONFIG_PCMCIA_3C574 is not set
# CONFIG_PCMCIA_FMVJ18X is not set
# CONFIG_PCMCIA_PCNET is not set
# CONFIG_PCMCIA_NMCLAN is not set
# CONFIG_PCMCIA_SMC91C92 is not set
# CONFIG_PCMCIA_XIRC2PS is not set
# CONFIG_PCMCIA_AXNET is not set
# CONFIG_PCMCIA_IBMTR is not set
# CONFIG_WAN is not set
CONFIG_XEN_NETDEV_FRONTEND=y
CONFIG_FDDI=y
# CONFIG_DEFXX is not set
# CONFIG_SKFP is not set
# CONFIG_HIPPI is not set
CONFIG_PPP=y
# CONFIG_PPP_MULTILINK is not set
# CONFIG_PPP_FILTER is not set
CONFIG_PPP_ASYNC=y
CONFIG_PPP_SYNC_TTY=y
CONFIG_PPP_DEFLATE=y
CONFIG_PPP_BSDCOMP=y
# CONFIG_PPP_MPPE is not set
CONFIG_PPPOE=y
CONFIG_PPPOL2TP=y
# CONFIG_SLIP is not set
CONFIG_SLHC=y
# CONFIG_NET_FC is not set
CONFIG_NETCONSOLE=m
# CONFIG_NETCONSOLE_DYNAMIC is not set
CONFIG_NETPOLL=y
# CONFIG_NETPOLL_TRAP is not set
CONFIG_NET_POLL_CONTROLLER=y
# CONFIG_VMXNET3 is not set
# CONFIG_ISDN is not set
# CONFIG_PHONE is not set

#
# Input device support
#
CONFIG_INPUT=y
CONFIG_INPUT_FF_MEMLESS=y
CONFIG_INPUT_POLLDEV=y

#
# Userland interfaces
#
CONFIG_INPUT_MOUSEDEV=y
# CONFIG_INPUT_MOUSEDEV_PSAUX is not set
CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024
CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768
# CONFIG_INPUT_JOYDEV is not set
CONFIG_INPUT_EVDEV=y
# CONFIG_INPUT_EVBUG is not set
CONFIG_XEN_KBDDEV_FRONTEND=y

#
# Input Device Drivers
#
CONFIG_INPUT_KEYBOARD=y
# CONFIG_KEYBOARD_ADP5588 is not set
CONFIG_KEYBOARD_ATKBD=y
# CONFIG_QT2160 is not set
# CONFIG_KEYBOARD_LKKBD is not set
# CONFIG_KEYBOARD_LM8323 is not set
# CONFIG_KEYBOARD_MAX7359 is not set
# CONFIG_KEYBOARD_NEWTON is not set
# CONFIG_KEYBOARD_OPENCORES is not set
# CONFIG_KEYBOARD_STOWAWAY is not set
# CONFIG_KEYBOARD_SUNKBD is not set
# CONFIG_KEYBOARD_XTKBD is not set
CONFIG_INPUT_MOUSE=y
CONFIG_MOUSE_PS2=y
CONFIG_MOUSE_PS2_ALPS=y
CONFIG_MOUSE_PS2_LOGIPS2PP=y
CONFIG_MOUSE_PS2_SYNAPTICS=y
CONFIG_MOUSE_PS2_LIFEBOOK=y
CONFIG_MOUSE_PS2_TRACKPOINT=y
# CONFIG_MOUSE_PS2_ELANTECH is not set
# CONFIG_MOUSE_PS2_SENTELIC is not set
# CONFIG_MOUSE_PS2_TOUCHKIT is not set
# CONFIG_MOUSE_SERIAL is not set
# CONFIG_MOUSE_APPLETOUCH is not set
# CONFIG_MOUSE_BCM5974 is not set
# CONFIG_MOUSE_VSXXXAA is not set
# CONFIG_MOUSE_SYNAPTICS_I2C is not set
CONFIG_INPUT_JOYSTICK=y
# CONFIG_JOYSTICK_ANALOG is not set
# CONFIG_JOYSTICK_A3D is not set
# CONFIG_JOYSTICK_ADI is not set
# CONFIG_JOYSTICK_COBRA is not set
# CONFIG_JOYSTICK_GF2K is not set
# CONFIG_JOYSTICK_GRIP is not set
# CONFIG_JOYSTICK_GRIP_MP is not set
# CONFIG_JOYSTICK_GUILLEMOT is not set
# CONFIG_JOYSTICK_INTERACT is not set
# CONFIG_JOYSTICK_SIDEWINDER is not set
# CONFIG_JOYSTICK_TMDC is not set
# CONFIG_JOYSTICK_IFORCE is not set
# CONFIG_JOYSTICK_WARRIOR is not set
# CONFIG_JOYSTICK_MAGELLAN is not set
# CONFIG_JOYSTICK_SPACEORB is not set
# CONFIG_JOYSTICK_SPACEBALL is not set
# CONFIG_JOYSTICK_STINGER is not set
# CONFIG_JOYSTICK_TWIDJOY is not set
# CONFIG_JOYSTICK_ZHENHUA is not set
# CONFIG_JOYSTICK_JOYDUMP is not set
# CONFIG_JOYSTICK_XPAD is not set
CONFIG_INPUT_TABLET=y
# CONFIG_TABLET_USB_ACECAD is not set
# CONFIG_TABLET_USB_AIPTEK is not set
# CONFIG_TABLET_USB_GTCO is not set
# CONFIG_TABLET_USB_KBTAB is not set
# CONFIG_TABLET_USB_WACOM is not set
CONFIG_INPUT_TOUCHSCREEN=y
# CONFIG_TOUCHSCREEN_AD7879_I2C is not set
# CONFIG_TOUCHSCREEN_AD7879 is not set
# CONFIG_TOUCHSCREEN_EETI is not set
# CONFIG_TOUCHSCREEN_FUJITSU is not set
# CONFIG_TOUCHSCREEN_GUNZE is not set
# CONFIG_TOUCHSCREEN_ELO is not set
# CONFIG_TOUCHSCREEN_WACOM_W8001 is not set
# CONFIG_TOUCHSCREEN_MCS5000 is not set
# CONFIG_TOUCHSCREEN_MTOUCH is not set
# CONFIG_TOUCHSCREEN_INEXIO is not set
# CONFIG_TOUCHSCREEN_MK712 is not set
# CONFIG_TOUCHSCREEN_PENMOUNT is not set
# CONFIG_TOUCHSCREEN_TOUCHRIGHT is not set
# CONFIG_TOUCHSCREEN_TOUCHWIN is not set
# CONFIG_TOUCHSCREEN_USB_COMPOSITE is not set
# CONFIG_TOUCHSCREEN_TOUCHIT213 is not set
# CONFIG_TOUCHSCREEN_TSC2007 is not set
CONFIG_INPUT_MISC=y
# CONFIG_INPUT_PCSPKR is not set
# CONFIG_INPUT_APANEL is not set
# CONFIG_INPUT_ATLAS_BTNS is not set
# CONFIG_INPUT_ATI_REMOTE is not set
# CONFIG_INPUT_ATI_REMOTE2 is not set
# CONFIG_INPUT_KEYSPAN_REMOTE is not set
# CONFIG_INPUT_POWERMATE is not set
# CONFIG_INPUT_YEALINK is not set
# CONFIG_INPUT_CM109 is not set
# CONFIG_INPUT_UINPUT is not set
# CONFIG_INPUT_WINBOND_CIR is not set

#
# Hardware I/O ports
#
CONFIG_SERIO=y
CONFIG_SERIO_I8042=y
CONFIG_SERIO_SERPORT=y
# CONFIG_SERIO_CT82C710 is not set
# CONFIG_SERIO_PCIPS2 is not set
CONFIG_SERIO_LIBPS2=y
# CONFIG_SERIO_RAW is not set
# CONFIG_GAMEPORT is not set

#
# Character devices
#
CONFIG_VT=y
CONFIG_CONSOLE_TRANSLATIONS=y
CONFIG_VT_CONSOLE=y
CONFIG_HW_CONSOLE=y
CONFIG_VT_HW_CONSOLE_BINDING=y
CONFIG_DEVKMEM=y
CONFIG_SERIAL_NONSTANDARD=y
# CONFIG_COMPUTONE is not set
# CONFIG_ROCKETPORT is not set
# CONFIG_CYCLADES is not set
# CONFIG_DIGIEPCA is not set
# CONFIG_MOXA_INTELLIO is not set
# CONFIG_MOXA_SMARTIO is not set
# CONFIG_ISI is not set
# CONFIG_SYNCLINK is not set
# CONFIG_SYNCLINKMP is not set
# CONFIG_SYNCLINK_GT is not set
# CONFIG_N_HDLC is not set
# CONFIG_RISCOM8 is not set
# CONFIG_SPECIALIX is not set
# CONFIG_STALDRV is not set
# CONFIG_NOZOMI is not set

#
# Serial drivers
#
CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_CONSOLE=y
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_SERIAL_8250_PCI=y
CONFIG_SERIAL_8250_PNP=y
# CONFIG_SERIAL_8250_CS is not set
CONFIG_SERIAL_8250_NR_UARTS=32
CONFIG_SERIAL_8250_RUNTIME_UARTS=4
CONFIG_SERIAL_8250_EXTENDED=y
CONFIG_SERIAL_8250_MANY_PORTS=y
CONFIG_SERIAL_8250_SHARE_IRQ=y
CONFIG_SERIAL_8250_DETECT_IRQ=y
CONFIG_SERIAL_8250_RSA=y

#
# Non-8250 serial port support
#
CONFIG_SERIAL_CORE=y
CONFIG_SERIAL_CORE_CONSOLE=y
# CONFIG_SERIAL_JSM is not set
CONFIG_UNIX98_PTYS=y
# CONFIG_DEVPTS_MULTIPLE_INSTANCES is not set
# CONFIG_LEGACY_PTYS is not set
CONFIG_HVC_DRIVER=y
CONFIG_HVC_IRQ=y
CONFIG_HVC_XEN=y
# CONFIG_IPMI_HANDLER is not set
CONFIG_HW_RANDOM=y
# CONFIG_HW_RANDOM_TIMERIOMEM is not set
CONFIG_HW_RANDOM_INTEL=y
CONFIG_HW_RANDOM_AMD=y
CONFIG_HW_RANDOM_VIA=y
CONFIG_NVRAM=y
# CONFIG_R3964 is not set
# CONFIG_APPLICOM is not set

#
# PCMCIA character devices
#
# CONFIG_SYNCLINK_CS is not set
# CONFIG_CARDMAN_4000 is not set
# CONFIG_CARDMAN_4040 is not set
# CONFIG_IPWIRELESS is not set
# CONFIG_MWAVE is not set
# CONFIG_PC8736x_GPIO is not set
# CONFIG_RAW_DRIVER is not set
CONFIG_HPET=y
# CONFIG_HPET_MMAP is not set
# CONFIG_HANGCHECK_TIMER is not set
# CONFIG_TCG_TPM is not set
# CONFIG_TELCLOCK is not set
CONFIG_DEVPORT=y
CONFIG_I2C=y
CONFIG_I2C_BOARDINFO=y
CONFIG_I2C_COMPAT=y
CONFIG_I2C_CHARDEV=m
CONFIG_I2C_HELPER_AUTO=y
CONFIG_I2C_ALGOBIT=y
CONFIG_I2C_ALGOPCA=m

#
# I2C Hardware Bus support
#

#
# PC SMBus host controller drivers
#
CONFIG_I2C_ALI1535=m
CONFIG_I2C_ALI1563=m
CONFIG_I2C_ALI15X3=m
CONFIG_I2C_AMD756=m
CONFIG_I2C_AMD756_S4882=m
CONFIG_I2C_AMD8111=m
CONFIG_I2C_I801=y
CONFIG_I2C_ISCH=m
CONFIG_I2C_PIIX4=m
CONFIG_I2C_NFORCE2=m
CONFIG_I2C_NFORCE2_S4985=m
CONFIG_I2C_SIS5595=m
CONFIG_I2C_SIS630=m
CONFIG_I2C_SIS96X=m
CONFIG_I2C_VIA=m
CONFIG_I2C_VIAPRO=m

#
# ACPI drivers
#
CONFIG_I2C_SCMI=m

#
# I2C system bus drivers (mostly embedded / system-on-chip)
#
CONFIG_I2C_OCORES=m
CONFIG_I2C_SIMTEC=m

#
# External I2C/SMBus adapter drivers
#
CONFIG_I2C_PARPORT_LIGHT=m
CONFIG_I2C_TAOS_EVM=m
CONFIG_I2C_TINY_USB=m

#
# Graphics adapter I2C/DDC channel drivers
#
CONFIG_I2C_VOODOO3=m

#
# Other I2C/SMBus bus drivers
#
CONFIG_I2C_PCA_PLATFORM=m
CONFIG_I2C_STUB=m

#
# Miscellaneous I2C Chip support
#
CONFIG_DS1682=m
CONFIG_SENSORS_TSL2550=m
# CONFIG_I2C_DEBUG_CORE is not set
# CONFIG_I2C_DEBUG_ALGO is not set
# CONFIG_I2C_DEBUG_BUS is not set
# CONFIG_I2C_DEBUG_CHIP is not set
# CONFIG_SPI is not set

#
# PPS support
#
# CONFIG_PPS is not set
CONFIG_ARCH_WANT_OPTIONAL_GPIOLIB=y
# CONFIG_GPIOLIB is not set
# CONFIG_W1 is not set
CONFIG_POWER_SUPPLY=y
# CONFIG_POWER_SUPPLY_DEBUG is not set
# CONFIG_PDA_POWER is not set
# CONFIG_BATTERY_DS2760 is not set
# CONFIG_BATTERY_DS2782 is not set
# CONFIG_BATTERY_BQ27x00 is not set
# CONFIG_BATTERY_MAX17040 is not set
CONFIG_HWMON=y
# CONFIG_HWMON_VID is not set
# CONFIG_HWMON_DEBUG_CHIP is not set

#
# Native drivers
#
# CONFIG_SENSORS_ABITUGURU is not set
# CONFIG_SENSORS_ABITUGURU3 is not set
# CONFIG_SENSORS_AD7414 is not set
# CONFIG_SENSORS_AD7418 is not set
# CONFIG_SENSORS_ADM1021 is not set
# CONFIG_SENSORS_ADM1025 is not set
# CONFIG_SENSORS_ADM1026 is not set
# CONFIG_SENSORS_ADM1029 is not set
# CONFIG_SENSORS_ADM1031 is not set
# CONFIG_SENSORS_ADM9240 is not set
# CONFIG_SENSORS_ADT7462 is not set
# CONFIG_SENSORS_ADT7470 is not set
# CONFIG_SENSORS_ADT7473 is not set
# CONFIG_SENSORS_ADT7475 is not set
# CONFIG_SENSORS_K8TEMP is not set
# CONFIG_SENSORS_ASB100 is not set
# CONFIG_SENSORS_ATXP1 is not set
# CONFIG_SENSORS_DS1621 is not set
# CONFIG_SENSORS_I5K_AMB is not set
# CONFIG_SENSORS_F71805F is not set
# CONFIG_SENSORS_F71882FG is not set
# CONFIG_SENSORS_F75375S is not set
# CONFIG_SENSORS_FSCHMD is not set
# CONFIG_SENSORS_G760A is not set
# CONFIG_SENSORS_GL518SM is not set
# CONFIG_SENSORS_GL520SM is not set
# CONFIG_SENSORS_CORETEMP is not set
# CONFIG_SENSORS_IT87 is not set
# CONFIG_SENSORS_LM63 is not set
# CONFIG_SENSORS_LM75 is not set
# CONFIG_SENSORS_LM77 is not set
# CONFIG_SENSORS_LM78 is not set
# CONFIG_SENSORS_LM80 is not set
# CONFIG_SENSORS_LM83 is not set
# CONFIG_SENSORS_LM85 is not set
# CONFIG_SENSORS_LM87 is not set
# CONFIG_SENSORS_LM90 is not set
# CONFIG_SENSORS_LM92 is not set
# CONFIG_SENSORS_LM93 is not set
# CONFIG_SENSORS_LTC4215 is not set
# CONFIG_SENSORS_LTC4245 is not set
# CONFIG_SENSORS_LM95241 is not set
# CONFIG_SENSORS_MAX1619 is not set
# CONFIG_SENSORS_MAX6650 is not set
# CONFIG_SENSORS_PC87360 is not set
# CONFIG_SENSORS_PC87427 is not set
# CONFIG_SENSORS_PCF8591 is not set
# CONFIG_SENSORS_SIS5595 is not set
# CONFIG_SENSORS_DME1737 is not set
# CONFIG_SENSORS_SMSC47M1 is not set
# CONFIG_SENSORS_SMSC47M192 is not set
# CONFIG_SENSORS_SMSC47B397 is not set
# CONFIG_SENSORS_ADS7828 is not set
# CONFIG_SENSORS_THMC50 is not set
# CONFIG_SENSORS_TMP401 is not set
# CONFIG_SENSORS_TMP421 is not set
# CONFIG_SENSORS_VIA686A is not set
# CONFIG_SENSORS_VT1211 is not set
# CONFIG_SENSORS_VT8231 is not set
# CONFIG_SENSORS_W83781D is not set
# CONFIG_SENSORS_W83791D is not set
# CONFIG_SENSORS_W83792D is not set
# CONFIG_SENSORS_W83793 is not set
# CONFIG_SENSORS_W83L785TS is not set
# CONFIG_SENSORS_W83L786NG is not set
# CONFIG_SENSORS_W83627HF is not set
# CONFIG_SENSORS_W83627EHF is not set
# CONFIG_SENSORS_HDAPS is not set
# CONFIG_SENSORS_APPLESMC is not set

#
# ACPI drivers
#
# CONFIG_SENSORS_ATK0110 is not set
# CONFIG_SENSORS_LIS3LV02D is not set
CONFIG_THERMAL=y
# CONFIG_THERMAL_HWMON is not set
CONFIG_WATCHDOG=y
# CONFIG_WATCHDOG_NOWAYOUT is not set

#
# Watchdog Device Drivers
#
# CONFIG_SOFT_WATCHDOG is not set
# CONFIG_ACQUIRE_WDT is not set
# CONFIG_ADVANTECH_WDT is not set
# CONFIG_ALIM1535_WDT is not set
# CONFIG_ALIM7101_WDT is not set
# CONFIG_SC520_WDT is not set
# CONFIG_SBC_FITPC2_WATCHDOG is not set
# CONFIG_EUROTECH_WDT is not set
# CONFIG_IB700_WDT is not set
# CONFIG_IBMASR is not set
# CONFIG_WAFER_WDT is not set
# CONFIG_I6300ESB_WDT is not set
# CONFIG_ITCO_WDT is not set
# CONFIG_IT8712F_WDT is not set
# CONFIG_IT87_WDT is not set
# CONFIG_HP_WATCHDOG is not set
# CONFIG_SC1200_WDT is not set
# CONFIG_PC87413_WDT is not set
# CONFIG_60XX_WDT is not set
# CONFIG_SBC8360_WDT is not set
# CONFIG_CPU5_WDT is not set
# CONFIG_SMSC_SCH311X_WDT is not set
# CONFIG_SMSC37B787_WDT is not set
# CONFIG_W83627HF_WDT is not set
# CONFIG_W83697HF_WDT is not set
# CONFIG_W83697UG_WDT is not set
# CONFIG_W83877F_WDT is not set
# CONFIG_W83977F_WDT is not set
# CONFIG_MACHZ_WDT is not set
# CONFIG_SBC_EPX_C3_WATCHDOG is not set
# CONFIG_XEN_WDT is not set

#
# PCI-based Watchdog Cards
#
# CONFIG_PCIPCWATCHDOG is not set
# CONFIG_WDTPCI is not set

#
# USB-based Watchdog Cards
#
# CONFIG_USBPCWATCHDOG is not set
CONFIG_SSB_POSSIBLE=y

#
# Sonics Silicon Backplane
#
# CONFIG_SSB is not set

#
# Multifunction device drivers
#
# CONFIG_MFD_CORE is not set
# CONFIG_MFD_SM501 is not set
# CONFIG_HTC_PASIC3 is not set
# CONFIG_TWL4030_CORE is not set
# CONFIG_MFD_TMIO is not set
# CONFIG_PMIC_DA903X is not set
# CONFIG_MFD_WM8400 is not set
# CONFIG_MFD_WM831X is not set
# CONFIG_MFD_WM8350_I2C is not set
# CONFIG_MFD_PCF50633 is not set
# CONFIG_AB3100_CORE is not set
# CONFIG_REGULATOR is not set
# CONFIG_MEDIA_SUPPORT is not set

#
# Graphics support
#
CONFIG_AGP=y
CONFIG_AGP_AMD64=y
CONFIG_AGP_INTEL=y
# CONFIG_AGP_SIS is not set
# CONFIG_AGP_VIA is not set
CONFIG_VGA_ARB=y
CONFIG_DRM=y
CONFIG_DRM_KMS_HELPER=y
# CONFIG_DRM_TDFX is not set
# CONFIG_DRM_R128 is not set
# CONFIG_DRM_RADEON is not set
# CONFIG_DRM_I810 is not set
# CONFIG_DRM_I830 is not set
CONFIG_DRM_I915=y
# CONFIG_DRM_I915_KMS is not set
# CONFIG_DRM_MGA is not set
# CONFIG_DRM_SIS is not set
# CONFIG_DRM_VIA is not set
# CONFIG_DRM_SAVAGE is not set
# CONFIG_VGASTATE is not set
CONFIG_VIDEO_OUTPUT_CONTROL=y
CONFIG_FB=y
# CONFIG_FIRMWARE_EDID is not set
# CONFIG_FB_DDC is not set
# CONFIG_FB_BOOT_VESA_SUPPORT is not set
CONFIG_FB_CFB_FILLRECT=y
CONFIG_FB_CFB_COPYAREA=y
CONFIG_FB_CFB_IMAGEBLIT=y
# CONFIG_FB_CFB_REV_PIXELS_IN_BYTE is not set
CONFIG_FB_SYS_FILLRECT=y
CONFIG_FB_SYS_COPYAREA=y
CONFIG_FB_SYS_IMAGEBLIT=y
# CONFIG_FB_FOREIGN_ENDIAN is not set
CONFIG_FB_SYS_FOPS=y
CONFIG_FB_DEFERRED_IO=y
# CONFIG_FB_SVGALIB is not set
# CONFIG_FB_MACMODES is not set
# CONFIG_FB_BACKLIGHT is not set
CONFIG_FB_MODE_HELPERS=y
CONFIG_FB_TILEBLITTING=y

#
# Frame buffer hardware drivers
#
# CONFIG_FB_CIRRUS is not set
# CONFIG_FB_PM2 is not set
# CONFIG_FB_CYBER2000 is not set
# CONFIG_FB_ARC is not set
# CONFIG_FB_ASILIANT is not set
# CONFIG_FB_IMSTT is not set
# CONFIG_FB_VGA16 is not set
# CONFIG_FB_UVESA is not set
# CONFIG_FB_VESA is not set
CONFIG_FB_EFI=y
# CONFIG_FB_N411 is not set
# CONFIG_FB_HGA is not set
# CONFIG_FB_S1D13XXX is not set
# CONFIG_FB_NVIDIA is not set
# CONFIG_FB_RIVA is not set
# CONFIG_FB_LE80578 is not set
# CONFIG_FB_MATROX is not set
# CONFIG_FB_RADEON is not set
# CONFIG_FB_ATY128 is not set
# CONFIG_FB_ATY is not set
# CONFIG_FB_S3 is not set
# CONFIG_FB_SAVAGE is not set
# CONFIG_FB_SIS is not set
# CONFIG_FB_VIA is not set
# CONFIG_FB_NEOMAGIC is not set
# CONFIG_FB_KYRO is not set
# CONFIG_FB_3DFX is not set
# CONFIG_FB_VOODOO1 is not set
# CONFIG_FB_VT8623 is not set
# CONFIG_FB_TRIDENT is not set
# CONFIG_FB_ARK is not set
# CONFIG_FB_PM3 is not set
# CONFIG_FB_CARMINE is not set
# CONFIG_FB_GEODE is not set
# CONFIG_FB_VIRTUAL is not set
CONFIG_XEN_FBDEV_FRONTEND=y
# CONFIG_FB_METRONOME is not set
# CONFIG_FB_MB862XX is not set
# CONFIG_FB_BROADSHEET is not set
CONFIG_BACKLIGHT_LCD_SUPPORT=y
# CONFIG_LCD_CLASS_DEVICE is not set
CONFIG_BACKLIGHT_CLASS_DEVICE=y
CONFIG_BACKLIGHT_GENERIC=y
# CONFIG_BACKLIGHT_PROGEAR is not set
# CONFIG_BACKLIGHT_MBP_NVIDIA is not set
# CONFIG_BACKLIGHT_SAHARA is not set

#
# Display device support
#
# CONFIG_DISPLAY_SUPPORT is not set

#
# Console display driver support
#
CONFIG_VGA_CONSOLE=y
CONFIG_VGACON_SOFT_SCROLLBACK=y
CONFIG_VGACON_SOFT_SCROLLBACK_SIZE=64
CONFIG_DUMMY_CONSOLE=y
CONFIG_FRAMEBUFFER_CONSOLE=y
# CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY is not set
# CONFIG_FRAMEBUFFER_CONSOLE_ROTATION is not set
# CONFIG_FONTS is not set
CONFIG_FONT_8x8=y
CONFIG_FONT_8x16=y
CONFIG_LOGO=y
# CONFIG_LOGO_LINUX_MONO is not set
# CONFIG_LOGO_LINUX_VGA16 is not set
CONFIG_LOGO_LINUX_CLUT224=y
CONFIG_SOUND=y
CONFIG_SOUND_OSS_CORE=y
CONFIG_SOUND_OSS_CORE_PRECLAIM=y
CONFIG_SND=y
CONFIG_SND_TIMER=y
CONFIG_SND_PCM=y
CONFIG_SND_HWDEP=y
CONFIG_SND_SEQUENCER=y
CONFIG_SND_SEQ_DUMMY=y
CONFIG_SND_OSSEMUL=y
CONFIG_SND_MIXER_OSS=y
CONFIG_SND_PCM_OSS=y
CONFIG_SND_PCM_OSS_PLUGINS=y
CONFIG_SND_SEQUENCER_OSS=y
CONFIG_SND_HRTIMER=y
CONFIG_SND_SEQ_HRTIMER_DEFAULT=y
CONFIG_SND_DYNAMIC_MINORS=y
CONFIG_SND_SUPPORT_OLD_API=y
CONFIG_SND_VERBOSE_PROCFS=y
# CONFIG_SND_VERBOSE_PRINTK is not set
# CONFIG_SND_DEBUG is not set
CONFIG_SND_VMASTER=y
CONFIG_SND_DMA_SGBUF=y
# CONFIG_SND_RAWMIDI_SEQ is not set
# CONFIG_SND_OPL3_LIB_SEQ is not set
# CONFIG_SND_OPL4_LIB_SEQ is not set
# CONFIG_SND_SBAWE_SEQ is not set
# CONFIG_SND_EMU10K1_SEQ is not set
CONFIG_SND_DRIVERS=y
# CONFIG_SND_PCSP is not set
# CONFIG_SND_DUMMY is not set
# CONFIG_SND_VIRMIDI is not set
# CONFIG_SND_MTPAV is not set
# CONFIG_SND_SERIAL_U16550 is not set
# CONFIG_SND_MPU401 is not set
CONFIG_SND_PCI=y
# CONFIG_SND_AD1889 is not set
# CONFIG_SND_ALS300 is not set
# CONFIG_SND_ALS4000 is not set
# CONFIG_SND_ALI5451 is not set
# CONFIG_SND_ATIIXP is not set
# CONFIG_SND_ATIIXP_MODEM is not set
# CONFIG_SND_AU8810 is not set
# CONFIG_SND_AU8820 is not set
# CONFIG_SND_AU8830 is not set
# CONFIG_SND_AW2 is not set
# CONFIG_SND_AZT3328 is not set
# CONFIG_SND_BT87X is not set
# CONFIG_SND_CA0106 is not set
# CONFIG_SND_CMIPCI is not set
# CONFIG_SND_OXYGEN is not set
# CONFIG_SND_CS4281 is not set
# CONFIG_SND_CS46XX is not set
# CONFIG_SND_CS5530 is not set
# CONFIG_SND_CS5535AUDIO is not set
# CONFIG_SND_CTXFI is not set
# CONFIG_SND_DARLA20 is not set
# CONFIG_SND_GINA20 is not set
# CONFIG_SND_LAYLA20 is not set
# CONFIG_SND_DARLA24 is not set
# CONFIG_SND_GINA24 is not set
# CONFIG_SND_LAYLA24 is not set
# CONFIG_SND_MONA is not set
# CONFIG_SND_MIA is not set
# CONFIG_SND_ECHO3G is not set
# CONFIG_SND_INDIGO is not set
# CONFIG_SND_INDIGOIO is not set
# CONFIG_SND_INDIGODJ is not set
# CONFIG_SND_INDIGOIOX is not set
# CONFIG_SND_INDIGODJX is not set
# CONFIG_SND_EMU10K1 is not set
# CONFIG_SND_EMU10K1X is not set
# CONFIG_SND_ENS1370 is not set
# CONFIG_SND_ENS1371 is not set
# CONFIG_SND_ES1938 is not set
# CONFIG_SND_ES1968 is not set
# CONFIG_SND_FM801 is not set
CONFIG_SND_HDA_INTEL=y
CONFIG_SND_HDA_HWDEP=y
# CONFIG_SND_HDA_RECONFIG is not set
# CONFIG_SND_HDA_INPUT_BEEP is not set
# CONFIG_SND_HDA_INPUT_JACK is not set
# CONFIG_SND_HDA_PATCH_LOADER is not set
CONFIG_SND_HDA_CODEC_REALTEK=y
CONFIG_SND_HDA_CODEC_ANALOG=y
CONFIG_SND_HDA_CODEC_SIGMATEL=y
CONFIG_SND_HDA_CODEC_VIA=y
CONFIG_SND_HDA_CODEC_ATIHDMI=y
CONFIG_SND_HDA_CODEC_NVHDMI=y
CONFIG_SND_HDA_CODEC_INTELHDMI=y
CONFIG_SND_HDA_ELD=y
CONFIG_SND_HDA_CODEC_CIRRUS=y
CONFIG_SND_HDA_CODEC_CONEXANT=y
CONFIG_SND_HDA_CODEC_CA0110=y
CONFIG_SND_HDA_CODEC_CMEDIA=y
CONFIG_SND_HDA_CODEC_SI3054=y
CONFIG_SND_HDA_GENERIC=y
# CONFIG_SND_HDA_POWER_SAVE is not set
# CONFIG_SND_HDSP is not set
# CONFIG_SND_HDSPM is not set
# CONFIG_SND_HIFIER is not set
# CONFIG_SND_ICE1712 is not set
# CONFIG_SND_ICE1724 is not set
# CONFIG_SND_INTEL8X0 is not set
# CONFIG_SND_INTEL8X0M is not set
# CONFIG_SND_KORG1212 is not set
# CONFIG_SND_LX6464ES is not set
# CONFIG_SND_MAESTRO3 is not set
# CONFIG_SND_MIXART is not set
# CONFIG_SND_NM256 is not set
# CONFIG_SND_PCXHR is not set
# CONFIG_SND_RIPTIDE is not set
# CONFIG_SND_RME32 is not set
# CONFIG_SND_RME96 is not set
# CONFIG_SND_RME9652 is not set
# CONFIG_SND_SONICVIBES is not set
# CONFIG_SND_TRIDENT is not set
# CONFIG_SND_VIA82XX is not set
# CONFIG_SND_VIA82XX_MODEM is not set
# CONFIG_SND_VIRTUOSO is not set
# CONFIG_SND_VX222 is not set
# CONFIG_SND_YMFPCI is not set
CONFIG_SND_USB=y
# CONFIG_SND_USB_AUDIO is not set
# CONFIG_SND_USB_USX2Y is not set
# CONFIG_SND_USB_CAIAQ is not set
# CONFIG_SND_USB_US122L is not set
CONFIG_SND_PCMCIA=y
# CONFIG_SND_VXPOCKET is not set
# CONFIG_SND_PDAUDIOCF is not set
# CONFIG_SND_SOC is not set
# CONFIG_SOUND_PRIME is not set
CONFIG_HID_SUPPORT=y
CONFIG_HID=y
CONFIG_HIDRAW=y

#
# USB Input Devices
#
CONFIG_USB_HID=y
CONFIG_HID_PID=y
CONFIG_USB_HIDDEV=y

#
# Special HID drivers
#
CONFIG_HID_A4TECH=y
CONFIG_HID_APPLE=y
CONFIG_HID_BELKIN=y
CONFIG_HID_CHERRY=y
CONFIG_HID_CHICONY=y
CONFIG_HID_CYPRESS=y
CONFIG_HID_DRAGONRISE=y
# CONFIG_DRAGONRISE_FF is not set
CONFIG_HID_EZKEY=y
CONFIG_HID_KYE=y
CONFIG_HID_GYRATION=y
CONFIG_HID_TWINHAN=y
CONFIG_HID_KENSINGTON=y
CONFIG_HID_LOGITECH=y
CONFIG_LOGITECH_FF=y
# CONFIG_LOGIRUMBLEPAD2_FF is not set
CONFIG_HID_MICROSOFT=y
CONFIG_HID_MONTEREY=y
CONFIG_HID_NTRIG=y
CONFIG_HID_PANTHERLORD=y
CONFIG_PANTHERLORD_FF=y
CONFIG_HID_PETALYNX=y
CONFIG_HID_SAMSUNG=y
CONFIG_HID_SONY=y
CONFIG_HID_SUNPLUS=y
CONFIG_HID_GREENASIA=y
# CONFIG_GREENASIA_FF is not set
CONFIG_HID_SMARTJOYPLUS=y
# CONFIG_SMARTJOYPLUS_FF is not set
CONFIG_HID_TOPSEED=y
CONFIG_HID_THRUSTMASTER=y
CONFIG_THRUSTMASTER_FF=y
CONFIG_HID_ZEROPLUS=y
CONFIG_ZEROPLUS_FF=y
CONFIG_USB_SUPPORT=y
CONFIG_USB_ARCH_HAS_HCD=y
CONFIG_USB_ARCH_HAS_OHCI=y
CONFIG_USB_ARCH_HAS_EHCI=y
CONFIG_USB=y
CONFIG_USB_DEBUG=y
CONFIG_USB_ANNOUNCE_NEW_DEVICES=y

#
# Miscellaneous USB options
#
CONFIG_USB_DEVICEFS=y
# CONFIG_USB_DEVICE_CLASS is not set
# CONFIG_USB_DYNAMIC_MINORS is not set
CONFIG_USB_SUSPEND=y
# CONFIG_USB_OTG is not set
CONFIG_USB_MON=y
# CONFIG_USB_WUSB is not set
# CONFIG_USB_WUSB_CBAF is not set

#
# USB Host Controller Drivers
#
# CONFIG_USB_C67X00_HCD is not set
# CONFIG_USB_XHCI_HCD is not set
CONFIG_USB_EHCI_HCD=y
# CONFIG_USB_EHCI_ROOT_HUB_TT is not set
# CONFIG_USB_EHCI_TT_NEWSCHED is not set
# CONFIG_USB_OXU210HP_HCD is not set
# CONFIG_USB_ISP116X_HCD is not set
# CONFIG_USB_ISP1760_HCD is not set
# CONFIG_USB_ISP1362_HCD is not set
CONFIG_USB_OHCI_HCD=y
# CONFIG_USB_OHCI_BIG_ENDIAN_DESC is not set
# CONFIG_USB_OHCI_BIG_ENDIAN_MMIO is not set
CONFIG_USB_OHCI_LITTLE_ENDIAN=y
CONFIG_USB_UHCI_HCD=y
# CONFIG_USB_SL811_HCD is not set
# CONFIG_USB_R8A66597_HCD is not set
# CONFIG_USB_WHCI_HCD is not set
# CONFIG_USB_HWA_HCD is not set

#
# USB Device Class drivers
#
# CONFIG_USB_ACM is not set
CONFIG_USB_PRINTER=y
# CONFIG_USB_WDM is not set
# CONFIG_USB_TMC is not set

#
# NOTE: USB_STORAGE depends on SCSI but BLK_DEV_SD may
#

#
# also be needed; see USB_STORAGE Help for more info
#
CONFIG_USB_STORAGE=y
# CONFIG_USB_STORAGE_DEBUG is not set
# CONFIG_USB_STORAGE_DATAFAB is not set
# CONFIG_USB_STORAGE_FREECOM is not set
# CONFIG_USB_STORAGE_ISD200 is not set
# CONFIG_USB_STORAGE_USBAT is not set
# CONFIG_USB_STORAGE_SDDR09 is not set
# CONFIG_USB_STORAGE_SDDR55 is not set
# CONFIG_USB_STORAGE_JUMPSHOT is not set
# CONFIG_USB_STORAGE_ALAUDA is not set
# CONFIG_USB_STORAGE_ONETOUCH is not set
# CONFIG_USB_STORAGE_KARMA is not set
# CONFIG_USB_STORAGE_CYPRESS_ATACB is not set
CONFIG_USB_LIBUSUAL=y

#
# USB Imaging devices
#
# CONFIG_USB_MDC800 is not set
# CONFIG_USB_MICROTEK is not set

#
# USB port drivers
#
# CONFIG_USB_SERIAL is not set

#
# USB Miscellaneous drivers
#
# CONFIG_USB_EMI62 is not set
# CONFIG_USB_EMI26 is not set
# CONFIG_USB_ADUTUX is not set
# CONFIG_USB_SEVSEG is not set
# CONFIG_USB_RIO500 is not set
# CONFIG_USB_LEGOTOWER is not set
# CONFIG_USB_LCD is not set
# CONFIG_USB_BERRY_CHARGE is not set
# CONFIG_USB_LED is not set
# CONFIG_USB_CYPRESS_CY7C63 is not set
# CONFIG_USB_CYTHERM is not set
# CONFIG_USB_IDMOUSE is not set
# CONFIG_USB_FTDI_ELAN is not set
# CONFIG_USB_APPLEDISPLAY is not set
# CONFIG_USB_SISUSBVGA is not set
# CONFIG_USB_LD is not set
# CONFIG_USB_TRANCEVIBRATOR is not set
# CONFIG_USB_IOWARRIOR is not set
# CONFIG_USB_TEST is not set
# CONFIG_USB_ISIGHTFW is not set
# CONFIG_USB_VST is not set
# CONFIG_USB_GADGET is not set

#
# OTG and related infrastructure
#
# CONFIG_NOP_USB_XCEIV is not set
# CONFIG_UWB is not set
# CONFIG_MMC is not set
# CONFIG_MEMSTICK is not set
CONFIG_NEW_LEDS=y
CONFIG_LEDS_CLASS=y

#
# LED drivers
#
# CONFIG_LEDS_ALIX2 is not set
# CONFIG_LEDS_PCA9532 is not set
# CONFIG_LEDS_LP3944 is not set
# CONFIG_LEDS_CLEVO_MAIL is not set
# CONFIG_LEDS_PCA955X is not set
# CONFIG_LEDS_BD2802 is not set

#
# LED Triggers
#
CONFIG_LEDS_TRIGGERS=y
# CONFIG_LEDS_TRIGGER_TIMER is not set
# CONFIG_LEDS_TRIGGER_HEARTBEAT is not set
# CONFIG_LEDS_TRIGGER_BACKLIGHT is not set
# CONFIG_LEDS_TRIGGER_DEFAULT_ON is not set

#
# iptables trigger is under Netfilter config (LED target)
#
# CONFIG_ACCESSIBILITY is not set
# CONFIG_INFINIBAND is not set
CONFIG_EDAC=y

#
# Reporting subsystems
#
# CONFIG_EDAC_DEBUG is not set
CONFIG_EDAC_DECODE_MCE=y
# CONFIG_EDAC_MM_EDAC is not set
CONFIG_RTC_LIB=y
CONFIG_RTC_CLASS=y
# CONFIG_RTC_HCTOSYS is not set
# CONFIG_RTC_DEBUG is not set

#
# RTC interfaces
#
CONFIG_RTC_INTF_SYSFS=y
CONFIG_RTC_INTF_PROC=y
CONFIG_RTC_INTF_DEV=y
# CONFIG_RTC_INTF_DEV_UIE_EMUL is not set
# CONFIG_RTC_DRV_TEST is not set

#
# I2C RTC drivers
#
# CONFIG_RTC_DRV_DS1307 is not set
# CONFIG_RTC_DRV_DS1374 is not set
# CONFIG_RTC_DRV_DS1672 is not set
# CONFIG_RTC_DRV_MAX6900 is not set
# CONFIG_RTC_DRV_RS5C372 is not set
# CONFIG_RTC_DRV_ISL1208 is not set
# CONFIG_RTC_DRV_X1205 is not set
# CONFIG_RTC_DRV_PCF8563 is not set
# CONFIG_RTC_DRV_PCF8583 is not set
# CONFIG_RTC_DRV_M41T80 is not set
# CONFIG_RTC_DRV_S35390A is not set
# CONFIG_RTC_DRV_FM3130 is not set
# CONFIG_RTC_DRV_RX8581 is not set
# CONFIG_RTC_DRV_RX8025 is not set

#
# SPI RTC drivers
#

#
# Platform RTC drivers
#
CONFIG_RTC_DRV_CMOS=y
# CONFIG_RTC_DRV_DS1286 is not set
# CONFIG_RTC_DRV_DS1511 is not set
# CONFIG_RTC_DRV_DS1553 is not set
# CONFIG_RTC_DRV_DS1742 is not set
# CONFIG_RTC_DRV_STK17TA8 is not set
# CONFIG_RTC_DRV_M48T86 is not set
# CONFIG_RTC_DRV_M48T35 is not set
# CONFIG_RTC_DRV_M48T59 is not set
# CONFIG_RTC_DRV_BQ4802 is not set
# CONFIG_RTC_DRV_V3020 is not set

#
# on-CPU RTC drivers
#
CONFIG_DMADEVICES=y

#
# DMA Devices
#
# CONFIG_INTEL_IOATDMA is not set
# CONFIG_AUXDISPLAY is not set
# CONFIG_UIO is not set

#
# TI VLYNQ
#
CONFIG_XEN_BALLOON=y
CONFIG_XEN_SCRUB_PAGES=y
CONFIG_XEN_DEV_EVTCHN=y
CONFIG_XEN_BACKEND=y
CONFIG_XEN_NETDEV_BACKEND=y
CONFIG_XEN_BLKDEV_BACKEND=y
CONFIG_XEN_BLKDEV_TAP=y
CONFIG_XEN_BLKBACK_PAGEMAP=y
CONFIG_XEN_PCIDEV_BACKEND=y
CONFIG_XEN_PCIDEV_BACKEND_VPCI=y
# CONFIG_XEN_PCIDEV_BACKEND_PASS is not set
# CONFIG_XEN_PCIDEV_BACKEND_SLOT is not set
# CONFIG_XEN_PCIDEV_BACKEND_CONTROLLER is not set
# CONFIG_XEN_PCIDEV_BE_DEBUG is not set
CONFIG_XENFS=y
CONFIG_XEN_COMPAT_XENFS=y
CONFIG_XEN_SYS_HYPERVISOR=y
CONFIG_XEN_XENBUS_FRONTEND=y
CONFIG_XEN_GNTDEV=y
CONFIG_XEN_S3=y
CONFIG_ACPI_PROCESSOR_XEN=y
CONFIG_XEN_PLATFORM_PCI=m
# CONFIG_STAGING is not set
CONFIG_X86_PLATFORM_DEVICES=y
# CONFIG_ACER_WMI is not set
# CONFIG_ASUS_LAPTOP is not set
# CONFIG_FUJITSU_LAPTOP is not set
# CONFIG_MSI_LAPTOP is not set
# CONFIG_PANASONIC_LAPTOP is not set
# CONFIG_COMPAL_LAPTOP is not set
# CONFIG_SONY_LAPTOP is not set
# CONFIG_THINKPAD_ACPI is not set
# CONFIG_INTEL_MENLOW is not set
CONFIG_EEEPC_LAPTOP=y
# CONFIG_ACPI_WMI is not set
# CONFIG_ACPI_ASUS is not set
# CONFIG_TOPSTAR_LAPTOP is not set
# CONFIG_ACPI_TOSHIBA is not set

#
# Firmware Drivers
#
# CONFIG_EDD is not set
CONFIG_FIRMWARE_MEMMAP=y
CONFIG_EFI_VARS=y
# CONFIG_DELL_RBU is not set
# CONFIG_DCDBAS is not set
CONFIG_DMIID=y
# CONFIG_ISCSI_IBFT_FIND is not set

#
# File systems
#
# CONFIG_EXT2_FS is not set
CONFIG_EXT3_FS=y
# CONFIG_EXT3_DEFAULTS_TO_ORDERED is not set
CONFIG_EXT3_FS_XATTR=y
CONFIG_EXT3_FS_POSIX_ACL=y
CONFIG_EXT3_FS_SECURITY=y
# CONFIG_EXT4_FS is not set
CONFIG_JBD=y
# CONFIG_JBD_DEBUG is not set
CONFIG_FS_MBCACHE=y
# CONFIG_REISERFS_FS is not set
# CONFIG_JFS_FS is not set
CONFIG_FS_POSIX_ACL=y
# CONFIG_XFS_FS is not set
# CONFIG_GFS2_FS is not set
# CONFIG_OCFS2_FS is not set
# CONFIG_BTRFS_FS is not set
# CONFIG_NILFS2_FS is not set
CONFIG_FILE_LOCKING=y
CONFIG_FSNOTIFY=y
CONFIG_DNOTIFY=y
CONFIG_INOTIFY=y
CONFIG_INOTIFY_USER=y
CONFIG_QUOTA=y
CONFIG_QUOTA_NETLINK_INTERFACE=y
# CONFIG_PRINT_QUOTA_WARNING is not set
CONFIG_QUOTA_TREE=y
# CONFIG_QFMT_V1 is not set
CONFIG_QFMT_V2=y
CONFIG_QUOTACTL=y
# CONFIG_AUTOFS_FS is not set
CONFIG_AUTOFS4_FS=y
# CONFIG_FUSE_FS is not set
CONFIG_GENERIC_ACL=y

#
# Caches
#
# CONFIG_FSCACHE is not set

#
# CD-ROM/DVD Filesystems
#
CONFIG_ISO9660_FS=y
CONFIG_JOLIET=y
CONFIG_ZISOFS=y
# CONFIG_UDF_FS is not set

#
# DOS/FAT/NT Filesystems
#
CONFIG_FAT_FS=y
CONFIG_MSDOS_FS=y
CONFIG_VFAT_FS=y
CONFIG_FAT_DEFAULT_CODEPAGE=437
CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1"
# CONFIG_NTFS_FS is not set

#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
CONFIG_PROC_KCORE=y
CONFIG_PROC_VMCORE=y
CONFIG_PROC_SYSCTL=y
CONFIG_PROC_PAGE_MONITOR=y
CONFIG_SYSFS=y
CONFIG_TMPFS=y
CONFIG_TMPFS_POSIX_ACL=y
CONFIG_HUGETLBFS=y
CONFIG_HUGETLB_PAGE=y
# CONFIG_CONFIGFS_FS is not set
CONFIG_MISC_FILESYSTEMS=y
# CONFIG_ADFS_FS is not set
# CONFIG_AFFS_FS is not set
# CONFIG_ECRYPT_FS is not set
# CONFIG_HFS_FS is not set
# CONFIG_HFSPLUS_FS is not set
# CONFIG_BEFS_FS is not set
# CONFIG_BFS_FS is not set
# CONFIG_EFS_FS is not set
# CONFIG_CRAMFS is not set
# CONFIG_SQUASHFS is not set
# CONFIG_VXFS_FS is not set
# CONFIG_MINIX_FS is not set
# CONFIG_OMFS_FS is not set
# CONFIG_HPFS_FS is not set
# CONFIG_QNX4FS_FS is not set
# CONFIG_ROMFS_FS is not set
# CONFIG_SYSV_FS is not set
# CONFIG_UFS_FS is not set
CONFIG_NETWORK_FILESYSTEMS=y
CONFIG_NFS_FS=y
CONFIG_NFS_V3=y
CONFIG_NFS_V3_ACL=y
CONFIG_NFS_V4=y
# CONFIG_NFS_V4_1 is not set
CONFIG_ROOT_NFS=y
CONFIG_NFSD=m
CONFIG_NFSD_V2_ACL=y
CONFIG_NFSD_V3=y
CONFIG_NFSD_V3_ACL=y
CONFIG_NFSD_V4=y
CONFIG_LOCKD=y
CONFIG_LOCKD_V4=y
CONFIG_EXPORTFS=m
CONFIG_NFS_ACL_SUPPORT=y
CONFIG_NFS_COMMON=y
CONFIG_SUNRPC=y
CONFIG_SUNRPC_GSS=y
CONFIG_RPCSEC_GSS_KRB5=y
# CONFIG_RPCSEC_GSS_SPKM3 is not set
# CONFIG_SMB_FS is not set
CONFIG_CIFS=m
# CONFIG_CIFS_STATS is not set
CONFIG_CIFS_WEAK_PW_HASH=y
CONFIG_CIFS_UPCALL=y
CONFIG_CIFS_XATTR=y
CONFIG_CIFS_POSIX=y
# CONFIG_CIFS_DEBUG2 is not set
# CONFIG_CIFS_DFS_UPCALL is not set
# CONFIG_CIFS_EXPERIMENTAL is not set
# CONFIG_NCP_FS is not set
# CONFIG_CODA_FS is not set
# CONFIG_AFS_FS is not set

#
# Partition Types
#
CONFIG_PARTITION_ADVANCED=y
# CONFIG_ACORN_PARTITION is not set
CONFIG_OSF_PARTITION=y
CONFIG_AMIGA_PARTITION=y
# CONFIG_ATARI_PARTITION is not set
CONFIG_MAC_PARTITION=y
CONFIG_MSDOS_PARTITION=y
CONFIG_BSD_DISKLABEL=y
CONFIG_MINIX_SUBPARTITION=y
CONFIG_SOLARIS_X86_PARTITION=y
CONFIG_UNIXWARE_DISKLABEL=y
# CONFIG_LDM_PARTITION is not set
CONFIG_SGI_PARTITION=y
# CONFIG_ULTRIX_PARTITION is not set
CONFIG_SUN_PARTITION=y
CONFIG_KARMA_PARTITION=y
CONFIG_EFI_PARTITION=y
# CONFIG_SYSV68_PARTITION is not set
CONFIG_NLS=y
CONFIG_NLS_DEFAULT="utf8"
CONFIG_NLS_CODEPAGE_437=y
# CONFIG_NLS_CODEPAGE_737 is not set
# CONFIG_NLS_CODEPAGE_775 is not set
# CONFIG_NLS_CODEPAGE_850 is not set
# CONFIG_NLS_CODEPAGE_852 is not set
# CONFIG_NLS_CODEPAGE_855 is not set
# CONFIG_NLS_CODEPAGE_857 is not set
# CONFIG_NLS_CODEPAGE_860 is not set
# CONFIG_NLS_CODEPAGE_861 is not set
# CONFIG_NLS_CODEPAGE_862 is not set
# CONFIG_NLS_CODEPAGE_863 is not set
# CONFIG_NLS_CODEPAGE_864 is not set
# CONFIG_NLS_CODEPAGE_865 is not set
# CONFIG_NLS_CODEPAGE_866 is not set
# CONFIG_NLS_CODEPAGE_869 is not set
# CONFIG_NLS_CODEPAGE_936 is not set
# CONFIG_NLS_CODEPAGE_950 is not set
# CONFIG_NLS_CODEPAGE_932 is not set
# CONFIG_NLS_CODEPAGE_949 is not set
# CONFIG_NLS_CODEPAGE_874 is not set
# CONFIG_NLS_ISO8859_8 is not set
# CONFIG_NLS_CODEPAGE_1250 is not set
# CONFIG_NLS_CODEPAGE_1251 is not set
CONFIG_NLS_ASCII=y
CONFIG_NLS_ISO8859_1=y
# CONFIG_NLS_ISO8859_2 is not set
# CONFIG_NLS_ISO8859_3 is not set
# CONFIG_NLS_ISO8859_4 is not set
# CONFIG_NLS_ISO8859_5 is not set
# CONFIG_NLS_ISO8859_6 is not set
# CONFIG_NLS_ISO8859_7 is not set
# CONFIG_NLS_ISO8859_9 is not set
# CONFIG_NLS_ISO8859_13 is not set
# CONFIG_NLS_ISO8859_14 is not set
# CONFIG_NLS_ISO8859_15 is not set
# CONFIG_NLS_KOI8_R is not set
# CONFIG_NLS_KOI8_U is not set
CONFIG_NLS_UTF8=y
# CONFIG_DLM is not set

#
# Kernel hacking
#
CONFIG_TRACE_IRQFLAGS_SUPPORT=y
CONFIG_PRINTK_TIME=y
# CONFIG_ENABLE_WARN_DEPRECATED is not set
CONFIG_ENABLE_MUST_CHECK=y
CONFIG_FRAME_WARN=2048
CONFIG_MAGIC_SYSRQ=y
# CONFIG_STRIP_ASM_SYMS is not set
# CONFIG_UNUSED_SYMBOLS is not set
CONFIG_DEBUG_FS=y
# CONFIG_HEADERS_CHECK is not set
CONFIG_DEBUG_KERNEL=y
# CONFIG_DEBUG_SHIRQ is not set
# CONFIG_DETECT_SOFTLOCKUP is not set
# CONFIG_DETECT_HUNG_TASK is not set
# CONFIG_SCHED_DEBUG is not set
CONFIG_SCHEDSTATS=y
CONFIG_TIMER_STATS=y
# CONFIG_DEBUG_OBJECTS is not set
# CONFIG_SLUB_DEBUG_ON is not set
# CONFIG_SLUB_STATS is not set
# CONFIG_DEBUG_KMEMLEAK is not set
# CONFIG_DEBUG_RT_MUTEXES is not set
# CONFIG_RT_MUTEX_TESTER is not set
# CONFIG_DEBUG_SPINLOCK is not set
# CONFIG_DEBUG_MUTEXES is not set
# CONFIG_DEBUG_LOCK_ALLOC is not set
# CONFIG_PROVE_LOCKING is not set
# CONFIG_LOCK_STAT is not set
# CONFIG_DEBUG_SPINLOCK_SLEEP is not set
# CONFIG_DEBUG_LOCKING_API_SELFTESTS is not set
CONFIG_STACKTRACE=y
# CONFIG_DEBUG_KOBJECT is not set
CONFIG_DEBUG_BUGVERBOSE=y
# CONFIG_DEBUG_INFO is not set
# CONFIG_DEBUG_VM is not set
# CONFIG_DEBUG_VIRTUAL is not set
# CONFIG_DEBUG_WRITECOUNT is not set
CONFIG_DEBUG_MEMORY_INIT=y
# CONFIG_DEBUG_LIST is not set
# CONFIG_DEBUG_SG is not set
# CONFIG_DEBUG_NOTIFIERS is not set
# CONFIG_DEBUG_CREDENTIALS is not set
CONFIG_ARCH_WANT_FRAME_POINTERS=y
CONFIG_FRAME_POINTER=y
# CONFIG_BOOT_PRINTK_DELAY is not set
# CONFIG_RCU_TORTURE_TEST is not set
# CONFIG_RCU_CPU_STALL_DETECTOR is not set
# CONFIG_KPROBES_SANITY_TEST is not set
# CONFIG_BACKTRACE_SELF_TEST is not set
# CONFIG_DEBUG_BLOCK_EXT_DEVT is not set
# CONFIG_DEBUG_FORCE_WEAK_PER_CPU is not set
# CONFIG_LKDTM is not set
# CONFIG_FAULT_INJECTION is not set
# CONFIG_LATENCYTOP is not set
CONFIG_SYSCTL_SYSCALL_CHECK=y
# CONFIG_DEBUG_PAGEALLOC is not set
CONFIG_USER_STACKTRACE_SUPPORT=y
CONFIG_NOP_TRACER=y
CONFIG_HAVE_FUNCTION_TRACER=y
CONFIG_HAVE_FUNCTION_GRAPH_TRACER=y
CONFIG_HAVE_FUNCTION_GRAPH_FP_TEST=y
CONFIG_HAVE_FUNCTION_TRACE_MCOUNT_TEST=y
CONFIG_HAVE_DYNAMIC_FTRACE=y
CONFIG_HAVE_FTRACE_MCOUNT_RECORD=y
CONFIG_HAVE_SYSCALL_TRACEPOINTS=y
CONFIG_RING_BUFFER=y
CONFIG_EVENT_TRACING=y
CONFIG_CONTEXT_SWITCH_TRACER=y
CONFIG_TRACING=y
CONFIG_GENERIC_TRACER=y
CONFIG_TRACING_SUPPORT=y
CONFIG_FTRACE=y
# CONFIG_FUNCTION_TRACER is not set
# CONFIG_IRQSOFF_TRACER is not set
# CONFIG_SYSPROF_TRACER is not set
# CONFIG_SCHED_TRACER is not set
# CONFIG_FTRACE_SYSCALLS is not set
# CONFIG_BOOT_TRACER is not set
CONFIG_BRANCH_PROFILE_NONE=y
# CONFIG_PROFILE_ANNOTATED_BRANCHES is not set
# CONFIG_PROFILE_ALL_BRANCHES is not set
# CONFIG_POWER_TRACER is not set
# CONFIG_STACK_TRACER is not set
# CONFIG_KMEMTRACE is not set
# CONFIG_WORKQUEUE_TRACER is not set
CONFIG_BLK_DEV_IO_TRACE=y
# CONFIG_FTRACE_STARTUP_TEST is not set
# CONFIG_MMIOTRACE is not set
# CONFIG_RING_BUFFER_BENCHMARK is not set
CONFIG_PROVIDE_OHCI1394_DMA_INIT=y
# CONFIG_DYNAMIC_DEBUG is not set
# CONFIG_DMA_API_DEBUG is not set
# CONFIG_SAMPLES is not set
CONFIG_HAVE_ARCH_KGDB=y
# CONFIG_KGDB is not set
CONFIG_HAVE_ARCH_KMEMCHECK=y
# CONFIG_STRICT_DEVMEM is not set
CONFIG_X86_VERBOSE_BOOTUP=y
CONFIG_EARLY_PRINTK=y
CONFIG_EARLY_PRINTK_DBGP=y
CONFIG_DEBUG_STACKOVERFLOW=y
# CONFIG_DEBUG_STACK_USAGE is not set
# CONFIG_DEBUG_PER_CPU_MAPS is not set
# CONFIG_X86_PTDUMP is not set
CONFIG_DEBUG_RODATA=y
# CONFIG_DEBUG_RODATA_TEST is not set
CONFIG_DEBUG_NX_TEST=m
# CONFIG_IOMMU_DEBUG is not set
# CONFIG_IOMMU_STRESS is not set
CONFIG_HAVE_MMIOTRACE_SUPPORT=y
CONFIG_IO_DELAY_TYPE_0X80=0
CONFIG_IO_DELAY_TYPE_0XED=1
CONFIG_IO_DELAY_TYPE_UDELAY=2
CONFIG_IO_DELAY_TYPE_NONE=3
CONFIG_IO_DELAY_0X80=y
# CONFIG_IO_DELAY_0XED is not set
# CONFIG_IO_DELAY_UDELAY is not set
# CONFIG_IO_DELAY_NONE is not set
CONFIG_DEFAULT_IO_DELAY_TYPE=0
CONFIG_DEBUG_BOOT_PARAMS=y
# CONFIG_CPA_DEBUG is not set
CONFIG_OPTIMIZE_INLINING=y

#
# Security options
#
CONFIG_KEYS=y
CONFIG_KEYS_DEBUG_PROC_KEYS=y
CONFIG_SECURITY=y
# CONFIG_SECURITYFS is not set
CONFIG_SECURITY_NETWORK=y
# CONFIG_SECURITY_NETWORK_XFRM is not set
# CONFIG_SECURITY_PATH is not set
CONFIG_SECURITY_FILE_CAPABILITIES=y
# CONFIG_SECURITY_ROOTPLUG is not set
CONFIG_LSM_MMAP_MIN_ADDR=65536
CONFIG_SECURITY_SELINUX=y
CONFIG_SECURITY_SELINUX_BOOTPARAM=y
CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE=1
CONFIG_SECURITY_SELINUX_DISABLE=y
CONFIG_SECURITY_SELINUX_DEVELOP=y
CONFIG_SECURITY_SELINUX_AVC_STATS=y
CONFIG_SECURITY_SELINUX_CHECKREQPROT_VALUE=1
# CONFIG_SECURITY_SELINUX_POLICYDB_VERSION_MAX is not set
# CONFIG_SECURITY_SMACK is not set
# CONFIG_SECURITY_TOMOYO is not set
# CONFIG_IMA is not set
CONFIG_CRYPTO=y

#
# Crypto core or helper
#
CONFIG_CRYPTO_ALGAPI=y
CONFIG_CRYPTO_ALGAPI2=y
CONFIG_CRYPTO_AEAD=y
CONFIG_CRYPTO_AEAD2=y
CONFIG_CRYPTO_BLKCIPHER=y
CONFIG_CRYPTO_BLKCIPHER2=y
CONFIG_CRYPTO_HASH=y
CONFIG_CRYPTO_HASH2=y
CONFIG_CRYPTO_RNG2=y
CONFIG_CRYPTO_PCOMP=y
CONFIG_CRYPTO_MANAGER=y
CONFIG_CRYPTO_MANAGER2=y
# CONFIG_CRYPTO_GF128MUL is not set
CONFIG_CRYPTO_NULL=y
CONFIG_CRYPTO_WORKQUEUE=y
# CONFIG_CRYPTO_CRYPTD is not set
CONFIG_CRYPTO_AUTHENC=y
# CONFIG_CRYPTO_TEST is not set

#
# Authenticated Encryption with Associated Data
#
# CONFIG_CRYPTO_CCM is not set
# CONFIG_CRYPTO_GCM is not set
# CONFIG_CRYPTO_SEQIV is not set

#
# Block modes
#
CONFIG_CRYPTO_CBC=y
# CONFIG_CRYPTO_CTR is not set
# CONFIG_CRYPTO_CTS is not set
CONFIG_CRYPTO_ECB=y
# CONFIG_CRYPTO_LRW is not set
# CONFIG_CRYPTO_PCBC is not set
# CONFIG_CRYPTO_XTS is not set

#
# Hash modes
#
CONFIG_CRYPTO_HMAC=y
# CONFIG_CRYPTO_XCBC is not set
# CONFIG_CRYPTO_VMAC is not set

#
# Digest
#
CONFIG_CRYPTO_CRC32C=y
# CONFIG_CRYPTO_CRC32C_INTEL is not set
# CONFIG_CRYPTO_GHASH is not set
# CONFIG_CRYPTO_MD4 is not set
CONFIG_CRYPTO_MD5=y
# CONFIG_CRYPTO_MICHAEL_MIC is not set
# CONFIG_CRYPTO_RMD128 is not set
# CONFIG_CRYPTO_RMD160 is not set
# CONFIG_CRYPTO_RMD256 is not set
# CONFIG_CRYPTO_RMD320 is not set
CONFIG_CRYPTO_SHA1=y
# CONFIG_CRYPTO_SHA256 is not set
# CONFIG_CRYPTO_SHA512 is not set
# CONFIG_CRYPTO_TGR192 is not set
# CONFIG_CRYPTO_WP512 is not set

#
# Ciphers
#
CONFIG_CRYPTO_AES=y
# CONFIG_CRYPTO_AES_X86_64 is not set
# CONFIG_CRYPTO_AES_NI_INTEL is not set
# CONFIG_CRYPTO_ANUBIS is not set
CONFIG_CRYPTO_ARC4=y
# CONFIG_CRYPTO_BLOWFISH is not set
# CONFIG_CRYPTO_CAMELLIA is not set
# CONFIG_CRYPTO_CAST5 is not set
# CONFIG_CRYPTO_CAST6 is not set
CONFIG_CRYPTO_DES=y
# CONFIG_CRYPTO_FCRYPT is not set
# CONFIG_CRYPTO_KHAZAD is not set
# CONFIG_CRYPTO_SALSA20 is not set
# CONFIG_CRYPTO_SALSA20_X86_64 is not set
# CONFIG_CRYPTO_SEED is not set
# CONFIG_CRYPTO_SERPENT is not set
# CONFIG_CRYPTO_TEA is not set
# CONFIG_CRYPTO_TWOFISH is not set
# CONFIG_CRYPTO_TWOFISH_X86_64 is not set

#
# Compression
#
CONFIG_CRYPTO_DEFLATE=y
CONFIG_CRYPTO_ZLIB=y
CONFIG_CRYPTO_LZO=y

#
# Random Number Generation
#
# CONFIG_CRYPTO_ANSI_CPRNG is not set
CONFIG_CRYPTO_HW=y
# CONFIG_CRYPTO_DEV_PADLOCK is not set
# CONFIG_CRYPTO_DEV_HIFN_795X is not set
CONFIG_HAVE_KVM=y
CONFIG_HAVE_KVM_IRQCHIP=y
CONFIG_HAVE_KVM_EVENTFD=y
CONFIG_KVM_APIC_ARCHITECTURE=y
CONFIG_VIRTUALIZATION=y
CONFIG_KVM=y
CONFIG_KVM_INTEL=y
CONFIG_KVM_AMD=y
# CONFIG_VIRTIO_PCI is not set
# CONFIG_VIRTIO_BALLOON is not set
CONFIG_BINARY_PRINTF=y

#
# Library routines
#
CONFIG_BITREVERSE=y
CONFIG_GENERIC_FIND_FIRST_BIT=y
CONFIG_GENERIC_FIND_NEXT_BIT=y
CONFIG_GENERIC_FIND_LAST_BIT=y
CONFIG_CRC_CCITT=y
# CONFIG_CRC16 is not set
CONFIG_CRC_T10DIF=y
# CONFIG_CRC_ITU_T is not set
CONFIG_CRC32=y
# CONFIG_CRC7 is not set
# CONFIG_LIBCRC32C is not set
CONFIG_ZLIB_INFLATE=y
CONFIG_ZLIB_DEFLATE=y
CONFIG_LZO_COMPRESS=y
CONFIG_LZO_DECOMPRESS=y
CONFIG_DECOMPRESS_GZIP=y
CONFIG_DECOMPRESS_BZIP2=y
CONFIG_DECOMPRESS_LZMA=y
CONFIG_TEXTSEARCH=y
CONFIG_TEXTSEARCH_KMP=y
CONFIG_TEXTSEARCH_BM=y
CONFIG_TEXTSEARCH_FSM=y
CONFIG_HAS_IOMEM=y
CONFIG_HAS_IOPORT=y
CONFIG_HAS_DMA=y
CONFIG_NLATTR=y

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

From xen-devel-bounces@lists.xensource.com Fri Dec 02 19:45:08 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 19:45:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWZ2E-0003AP-Kk; Fri, 02 Dec 2011 19:44:38 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RWZ2D-0003AK-5Q
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 19:44:37 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-6.tower-216.messagelabs.com!1322855035!5951090!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMjMxNzc=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMjMxNzc=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28578 invoked from network); 2 Dec 2011 19:43:55 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-6.tower-216.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 2 Dec 2011 19:43:55 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1322855034; l=722;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=7s/arGkBAmMf/IyV+Ala2kKOwHw=;
	b=veLiKjEBoegjBW5VjTHIq4Rmc9ZIbSYIQE7C+yjFqa4RcVAsbXmh1zT1XBhVC19yKxA
	IdtaZ49fJsRPV45a0yCytIBxmwk93F1G5p9Z7U5DXWZTza5j0+LkPYSVtQjvaBmYHIpzn
	mci5P1FzEqIuJDl4M3K0eZbhkQE64msAaMI=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFJji0PG5M=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-070-018.pools.arcor-ip.net [88.65.70.18])
	by smtp.strato.de (klopstock mo27) (RZmta 26.10 AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id k04537nB2HvFOZ ;
	Fri, 2 Dec 2011 20:43:45 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 863B618637; Fri,  2 Dec 2011 20:43:44 +0100 (CET)
Date: Fri, 2 Dec 2011 20:43:44 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20111202194344.GA1773@aepfle.de>
References: <2a4ec2e2ae36593aa74e.1322772973@xdev.gridcentric.ca>
	<20111202071148.GA23017@aepfle.de>
	<7ba95535823dd32cc2a73d78646059bc.squirrel@webmail.lagarcavilla.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <7ba95535823dd32cc2a73d78646059bc.squirrel@webmail.lagarcavilla.org>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com, tim@xen.org,
	keir.xen@gmail.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH] Flag events caused by foreign domains
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Dec 02, Andres Lagar-Cavilla wrote:

> > On Thu, Dec 01, Andres Lagar-Cavilla wrote:
> >
> >> Add a new flag for mem events, as consumers might need to discriminate
> >> foreign domain-caused from guest-caused events. The vcpu field of an
> >> event is bogus from a consumer p.o.v. for foreign domain-caused events.
> >
> > How is this supposed to be used?
> We're just OR'ing an extra flag on existing events. Toolstacks can ignore
> it, or use it to handle foreign events differently, or whatever. No new
> events are generated, timings don't change etc.

Thats obvious.

> Is that your concern?

I'm wondering wether it really achieves what you want, no stall in the
ring buffer etc.

Olaf

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

From xen-devel-bounces@lists.xensource.com Fri Dec 02 19:45:08 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 19:45:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWZ2E-0003AP-Kk; Fri, 02 Dec 2011 19:44:38 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RWZ2D-0003AK-5Q
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 19:44:37 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-6.tower-216.messagelabs.com!1322855035!5951090!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMjMxNzc=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMjMxNzc=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28578 invoked from network); 2 Dec 2011 19:43:55 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-6.tower-216.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 2 Dec 2011 19:43:55 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1322855034; l=722;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=7s/arGkBAmMf/IyV+Ala2kKOwHw=;
	b=veLiKjEBoegjBW5VjTHIq4Rmc9ZIbSYIQE7C+yjFqa4RcVAsbXmh1zT1XBhVC19yKxA
	IdtaZ49fJsRPV45a0yCytIBxmwk93F1G5p9Z7U5DXWZTza5j0+LkPYSVtQjvaBmYHIpzn
	mci5P1FzEqIuJDl4M3K0eZbhkQE64msAaMI=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFJji0PG5M=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-070-018.pools.arcor-ip.net [88.65.70.18])
	by smtp.strato.de (klopstock mo27) (RZmta 26.10 AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id k04537nB2HvFOZ ;
	Fri, 2 Dec 2011 20:43:45 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 863B618637; Fri,  2 Dec 2011 20:43:44 +0100 (CET)
Date: Fri, 2 Dec 2011 20:43:44 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20111202194344.GA1773@aepfle.de>
References: <2a4ec2e2ae36593aa74e.1322772973@xdev.gridcentric.ca>
	<20111202071148.GA23017@aepfle.de>
	<7ba95535823dd32cc2a73d78646059bc.squirrel@webmail.lagarcavilla.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <7ba95535823dd32cc2a73d78646059bc.squirrel@webmail.lagarcavilla.org>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com, tim@xen.org,
	keir.xen@gmail.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH] Flag events caused by foreign domains
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Dec 02, Andres Lagar-Cavilla wrote:

> > On Thu, Dec 01, Andres Lagar-Cavilla wrote:
> >
> >> Add a new flag for mem events, as consumers might need to discriminate
> >> foreign domain-caused from guest-caused events. The vcpu field of an
> >> event is bogus from a consumer p.o.v. for foreign domain-caused events.
> >
> > How is this supposed to be used?
> We're just OR'ing an extra flag on existing events. Toolstacks can ignore
> it, or use it to handle foreign events differently, or whatever. No new
> events are generated, timings don't change etc.

Thats obvious.

> Is that your concern?

I'm wondering wether it really achieves what you want, no stall in the
ring buffer etc.

Olaf

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

From xen-devel-bounces@lists.xensource.com Fri Dec 02 19:54:19 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 19:54:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWZBC-0003Kc-Mb; Fri, 02 Dec 2011 19:53:54 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <ml-xen-devel@hfp.de>) id 1RWZBB-0003KU-LJ
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 19:53:53 +0000
X-Env-Sender: ml-xen-devel@hfp.de
X-Msg-Ref: server-9.tower-216.messagelabs.com!1322855591!5993998!1
X-Originating-IP: [88.205.101.6]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3695 invoked from network); 2 Dec 2011 19:53:12 -0000
Received: from rootsrv.hfp.de (HELO rootsrv.hfp.de) (88.205.101.6)
	by server-9.tower-216.messagelabs.com with SMTP;
	2 Dec 2011 19:53:12 -0000
Received: from localhost (localhost [127.0.0.1])
	by rootsrv.hfp.de (Postfix) with ESMTP id C80881AAFA1;
	Fri,  2 Dec 2011 20:53:10 +0100 (CET)
X-Virus-Scanned: amavisd-new/ClamAV at rootsrv.hfp.de
Received: from rootsrv.hfp.de ([127.0.0.1])
	by localhost (rootsrv.hfp.de [127.0.0.1]) (amavisd-new, port 10026)
	with ESMTP id 8lh2HS0mc8OG; Fri,  2 Dec 2011 20:53:10 +0100 (CET)
Received: from [10.0.0.1] (p5DCB7ABE.dip.t-dialin.net [93.203.122.190])
	by rootsrv.hfp.de (Postfix) with ESMTPA;
	Fri,  2 Dec 2011 20:53:10 +0100 (CET)
Message-ID: <4ED92CAA.2040008@hfp.de>
Date: Fri, 02 Dec 2011 20:53:14 +0100
From: Andreas Kinzler <ml-xen-devel@hfp.de>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: xen-devel@lists.xensource.com
References: <4E9D94A0.10102@hfp.de>
	<FF93AF260AC2BB499A119CC65B092CF7311817E2@sg000713.corproot.net>
	<F1CD4AC5B4A5024AAB60E28A82A8450A046CE5EE@winexch1.office.turtle-entertainment.de>
	<CABx4GKqodU4FLmX3adiCi3U-eKe5cDMVtNV2ZhzFAMsKL_1uTg@mail.gmail.com>
	<FF93AF260AC2BB499A119CC65B092CF7311EE626@sg000713.corproot.net>
	<CABx4GKo7CBCW6cn49Kr2O+NTm78ms7Xnh_ub1EZ7pdt+Cmp=Lg@mail.gmail.com>
In-Reply-To: <CABx4GKo7CBCW6cn49Kr2O+NTm78ms7Xnh_ub1EZ7pdt+Cmp=Lg@mail.gmail.com>
Cc: tp@turtle-entertainment.de, Olivier Hanesse <olivier.hanesse@gmail.com>,
	Philippe.Simonet@swisscom.com
Subject: Re: [Xen-devel] Possible hint for "Clocksource tsc unstable" problem
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="windows-1252"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01.12.2011 08:49, Olivier Hanesse wrote:
> good news !
> Is your "test system" the same hardware as before ?
> For example, I don't have time issue with processor having the
> 'nonstop_tsc' flag.
> I got only time issue on older processor (Xeon L5420 for example)

Sorry, but my report was on a machine with Xeon E5620 (has nonstop_tsc). =

I did some tests to reproduce the behavior by blocking NTP traffic via =

iptables but the problem did not reproduce in a lab setting.

Regards Andreas

>     *From:*Olivier Hanesse [mailto:olivier.hanesse@gmail.com
>     <mailto:olivier.hanesse@gmail.com>]
>     *Sent:* Wednesday, October 19, 2011 2:48 PM
>     *To:* Thomas P=F6hler
>     *Cc:* Simonet Philippe, ITS-SDL-EIS-CNV-DLE-TLC; ml-xen-devel@hfp.de
>     <mailto:ml-xen-devel@hfp.de>
>     *Subject:* Re: [Xen-devel] Possible hint for "Clocksource tsc
>     unstable" problem____
>
>     __ __
>
>     Hi,____
>
>     __ __
>
>     Same here.____
>
>     I am using ntpd in dom0 too (lenny version so 4.2.4)____
>
>     __ __
>
>     Regards____
>
>     __ __
>
>     Olivier____
>
>     __ __
>
>     2011/10/19 Thomas P=F6hler <tp@turtle-entertainment.de
>     <mailto:tp@turtle-entertainment.de>>____
>
>     Hi Philippe,
>
>     we are using ntpd in Dom0 too. (also ntpd - NTP daemon program -
>     Ver. 4.2.6p2).
>     We are monitoring ntp over a nagios plugin, check_ntp
>
>     Regards
>     Thomas
>
>     -----Urspr=FCngliche Nachricht-----
>     Von: Philippe.Simonet@swisscom.com
>     <mailto:Philippe.Simonet@swisscom.com>
>     [mailto:Philippe.Simonet@swisscom.com
>     <mailto:Philippe.Simonet@swisscom.com>]
>     Gesendet: Mittwoch, 19. Oktober 2011 14:40
>     An: olivier.hanesse@gmail.com <mailto:olivier.hanesse@gmail.com>;
>     Thomas P=F6hler
>     Cc: ml-xen-devel@hfp.de <mailto:ml-xen-devel@hfp.de>
>     Betreff: RE: [Xen-devel] Possible hint for "Clocksource tsc
>     unstable" problem____
>
>
>     Hi Olivier and Thomas
>
>     andreas ist using ntpd in DOM0, myself too (ntpd - NTP daemon
>     program - Ver. 4.2.6p2)
>
>     and you ?
>
>     @andreas : how do you turn on your ntp logging ?
>
>     Philippe
>
>
>      > -----Original Message-----
>      > From: xen-devel-bounces@lists.xensource.com
>     <mailto:xen-devel-bounces@lists.xensource.com> [mailto:xen-devel-
>     <mailto:xen-devel->
>      > bounces@lists.xensource.com <mailto:bounces@lists.xensource.com>]
>     On Behalf Of Andreas Kinzler
>      > Sent: Tuesday, October 18, 2011 5:01 PM
>      > To: xen-devel@lists.xensource.com
>     <mailto:xen-devel@lists.xensource.com>
>      > Subject: [Xen-devel] Possible hint for "Clocksource tsc unstable"
>     problem
>      >
>      > Hello,
>      >
>      > I made an interesting observation related to the "Clocksource tsc
>      > unstable (delta =3D -2999660320319 ns)" problem. In the log of ntpd
>     I found:
>      >
>      > Oct  5 03:46:35 greenville-dom0 ntpd[4020]: kernel time sync status
>      > change 6001
>      > Oct  5 04:03:41 greenville-dom0 ntpd[4020]: kernel time sync status
>      > change 2001
>      > Oct  5 05:29:03 greenville-dom0 ntpd[4020]: kernel time sync status
>      > change 6001
>      > Oct  5 05:46:09 greenville-dom0 ntpd[4020]: kernel time sync status
>      > change 2001
>      > Oct  5 06:54:30 greenville-dom0 ntpd[4020]: synchronized to
>      > 192.53.103.104 <tel:192.53.103.104>, stratum 1
>      > Oct  5 06:54:30 greenville-dom0 ntpd[4020]: kernel time sync status
>      > change 6001
>      > Oct  5 07:28:22 greenville-dom0 ntpd[4020]: kernel time sync status
>      > change 2001
>      > Oct  5 08:19:35 greenville-dom0 ntpd[4020]: synchronized to
>      > 192.53.103.108 <tel:192.53.103.108>, stratum 1
>      > Oct  5 10:53:26 greenville-dom0 ntpd[4020]: kernel time sync status
>      > change 6001
>      > Oct  5 11:27:32 greenville-dom0 ntpd[4020]: kernel time sync status
>      > change 2001
>      > Oct  5 12:01:41 greenville-dom0 ntpd[4020]: kernel time sync status
>      > change 6001
>      > Oct  5 12:18:44 greenville-dom0 ntpd[4020]: kernel time sync status
>      > change 2001
>      > Oct  5 13:09:58 greenville-dom0 ntpd[4020]: kernel time sync status
>      > change 6001
>      > Oct  5 13:27:04 greenville-dom0 ntpd[4020]: kernel time sync status
>      > change 2001
>      > Oct  5 15:26:37 greenville-dom0 ntpd[4020]: kernel time sync status
>      > change 6001
>      > Oct  5 15:43:41 greenville-dom0 ntpd[4020]: kernel time sync status
>      > change 2001
>      > Oct  5 17:43:11 greenville-dom0 ntpd[4020]: kernel time sync status
>      > change 6001
>      > Oct  5 19:08:31 greenville-dom0 ntpd[4020]: synchronized to
>      > 192.53.103.104 <tel:192.53.103.104>, stratum 1
>      > Oct  5 19:08:31 greenville-dom0 ntpd[4020]: kernel time sync status
>      > change 2001
>      > Oct  5 21:23:58 greenville-dom0 ntpd[4020]: no servers reachable
>      > Oct  5 21:40:58 greenville-dom0 ntpd[4020]: synchronized to
>      > 192.53.103.104 <tel:192.53.103.104>, stratum 1
>      > Oct  5 21:40:58 greenville-dom0 ntpd[4020]: time correction of -30=
00
>      > seconds exceeds sanity limit (1000); set clock manually to the
>     correct
>      > UTC time.
>      >
>      > I had the problem twice on different machines but everytime I saw =
the
>      > line "no servers reachable". Could ntpd and/or linux kernel make s=
ome
>      > stupid stuff when ntp upstream servers are unreachable?
>      >
>      > Regards Andreas
>      >
>      >
>      > _______________________________________________
>      > Xen-devel mailing list
>      > Xen-devel@lists.xensource.com <mailto:Xen-devel@lists.xensource.co=
m>
>      > http://lists.xensource.com/xen-devel____
>
>     __ __
>
>

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

From xen-devel-bounces@lists.xensource.com Fri Dec 02 19:54:19 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 19:54:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWZBC-0003Kc-Mb; Fri, 02 Dec 2011 19:53:54 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <ml-xen-devel@hfp.de>) id 1RWZBB-0003KU-LJ
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 19:53:53 +0000
X-Env-Sender: ml-xen-devel@hfp.de
X-Msg-Ref: server-9.tower-216.messagelabs.com!1322855591!5993998!1
X-Originating-IP: [88.205.101.6]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3695 invoked from network); 2 Dec 2011 19:53:12 -0000
Received: from rootsrv.hfp.de (HELO rootsrv.hfp.de) (88.205.101.6)
	by server-9.tower-216.messagelabs.com with SMTP;
	2 Dec 2011 19:53:12 -0000
Received: from localhost (localhost [127.0.0.1])
	by rootsrv.hfp.de (Postfix) with ESMTP id C80881AAFA1;
	Fri,  2 Dec 2011 20:53:10 +0100 (CET)
X-Virus-Scanned: amavisd-new/ClamAV at rootsrv.hfp.de
Received: from rootsrv.hfp.de ([127.0.0.1])
	by localhost (rootsrv.hfp.de [127.0.0.1]) (amavisd-new, port 10026)
	with ESMTP id 8lh2HS0mc8OG; Fri,  2 Dec 2011 20:53:10 +0100 (CET)
Received: from [10.0.0.1] (p5DCB7ABE.dip.t-dialin.net [93.203.122.190])
	by rootsrv.hfp.de (Postfix) with ESMTPA;
	Fri,  2 Dec 2011 20:53:10 +0100 (CET)
Message-ID: <4ED92CAA.2040008@hfp.de>
Date: Fri, 02 Dec 2011 20:53:14 +0100
From: Andreas Kinzler <ml-xen-devel@hfp.de>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: xen-devel@lists.xensource.com
References: <4E9D94A0.10102@hfp.de>
	<FF93AF260AC2BB499A119CC65B092CF7311817E2@sg000713.corproot.net>
	<F1CD4AC5B4A5024AAB60E28A82A8450A046CE5EE@winexch1.office.turtle-entertainment.de>
	<CABx4GKqodU4FLmX3adiCi3U-eKe5cDMVtNV2ZhzFAMsKL_1uTg@mail.gmail.com>
	<FF93AF260AC2BB499A119CC65B092CF7311EE626@sg000713.corproot.net>
	<CABx4GKo7CBCW6cn49Kr2O+NTm78ms7Xnh_ub1EZ7pdt+Cmp=Lg@mail.gmail.com>
In-Reply-To: <CABx4GKo7CBCW6cn49Kr2O+NTm78ms7Xnh_ub1EZ7pdt+Cmp=Lg@mail.gmail.com>
Cc: tp@turtle-entertainment.de, Olivier Hanesse <olivier.hanesse@gmail.com>,
	Philippe.Simonet@swisscom.com
Subject: Re: [Xen-devel] Possible hint for "Clocksource tsc unstable" problem
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="windows-1252"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01.12.2011 08:49, Olivier Hanesse wrote:
> good news !
> Is your "test system" the same hardware as before ?
> For example, I don't have time issue with processor having the
> 'nonstop_tsc' flag.
> I got only time issue on older processor (Xeon L5420 for example)

Sorry, but my report was on a machine with Xeon E5620 (has nonstop_tsc). =

I did some tests to reproduce the behavior by blocking NTP traffic via =

iptables but the problem did not reproduce in a lab setting.

Regards Andreas

>     *From:*Olivier Hanesse [mailto:olivier.hanesse@gmail.com
>     <mailto:olivier.hanesse@gmail.com>]
>     *Sent:* Wednesday, October 19, 2011 2:48 PM
>     *To:* Thomas P=F6hler
>     *Cc:* Simonet Philippe, ITS-SDL-EIS-CNV-DLE-TLC; ml-xen-devel@hfp.de
>     <mailto:ml-xen-devel@hfp.de>
>     *Subject:* Re: [Xen-devel] Possible hint for "Clocksource tsc
>     unstable" problem____
>
>     __ __
>
>     Hi,____
>
>     __ __
>
>     Same here.____
>
>     I am using ntpd in dom0 too (lenny version so 4.2.4)____
>
>     __ __
>
>     Regards____
>
>     __ __
>
>     Olivier____
>
>     __ __
>
>     2011/10/19 Thomas P=F6hler <tp@turtle-entertainment.de
>     <mailto:tp@turtle-entertainment.de>>____
>
>     Hi Philippe,
>
>     we are using ntpd in Dom0 too. (also ntpd - NTP daemon program -
>     Ver. 4.2.6p2).
>     We are monitoring ntp over a nagios plugin, check_ntp
>
>     Regards
>     Thomas
>
>     -----Urspr=FCngliche Nachricht-----
>     Von: Philippe.Simonet@swisscom.com
>     <mailto:Philippe.Simonet@swisscom.com>
>     [mailto:Philippe.Simonet@swisscom.com
>     <mailto:Philippe.Simonet@swisscom.com>]
>     Gesendet: Mittwoch, 19. Oktober 2011 14:40
>     An: olivier.hanesse@gmail.com <mailto:olivier.hanesse@gmail.com>;
>     Thomas P=F6hler
>     Cc: ml-xen-devel@hfp.de <mailto:ml-xen-devel@hfp.de>
>     Betreff: RE: [Xen-devel] Possible hint for "Clocksource tsc
>     unstable" problem____
>
>
>     Hi Olivier and Thomas
>
>     andreas ist using ntpd in DOM0, myself too (ntpd - NTP daemon
>     program - Ver. 4.2.6p2)
>
>     and you ?
>
>     @andreas : how do you turn on your ntp logging ?
>
>     Philippe
>
>
>      > -----Original Message-----
>      > From: xen-devel-bounces@lists.xensource.com
>     <mailto:xen-devel-bounces@lists.xensource.com> [mailto:xen-devel-
>     <mailto:xen-devel->
>      > bounces@lists.xensource.com <mailto:bounces@lists.xensource.com>]
>     On Behalf Of Andreas Kinzler
>      > Sent: Tuesday, October 18, 2011 5:01 PM
>      > To: xen-devel@lists.xensource.com
>     <mailto:xen-devel@lists.xensource.com>
>      > Subject: [Xen-devel] Possible hint for "Clocksource tsc unstable"
>     problem
>      >
>      > Hello,
>      >
>      > I made an interesting observation related to the "Clocksource tsc
>      > unstable (delta =3D -2999660320319 ns)" problem. In the log of ntpd
>     I found:
>      >
>      > Oct  5 03:46:35 greenville-dom0 ntpd[4020]: kernel time sync status
>      > change 6001
>      > Oct  5 04:03:41 greenville-dom0 ntpd[4020]: kernel time sync status
>      > change 2001
>      > Oct  5 05:29:03 greenville-dom0 ntpd[4020]: kernel time sync status
>      > change 6001
>      > Oct  5 05:46:09 greenville-dom0 ntpd[4020]: kernel time sync status
>      > change 2001
>      > Oct  5 06:54:30 greenville-dom0 ntpd[4020]: synchronized to
>      > 192.53.103.104 <tel:192.53.103.104>, stratum 1
>      > Oct  5 06:54:30 greenville-dom0 ntpd[4020]: kernel time sync status
>      > change 6001
>      > Oct  5 07:28:22 greenville-dom0 ntpd[4020]: kernel time sync status
>      > change 2001
>      > Oct  5 08:19:35 greenville-dom0 ntpd[4020]: synchronized to
>      > 192.53.103.108 <tel:192.53.103.108>, stratum 1
>      > Oct  5 10:53:26 greenville-dom0 ntpd[4020]: kernel time sync status
>      > change 6001
>      > Oct  5 11:27:32 greenville-dom0 ntpd[4020]: kernel time sync status
>      > change 2001
>      > Oct  5 12:01:41 greenville-dom0 ntpd[4020]: kernel time sync status
>      > change 6001
>      > Oct  5 12:18:44 greenville-dom0 ntpd[4020]: kernel time sync status
>      > change 2001
>      > Oct  5 13:09:58 greenville-dom0 ntpd[4020]: kernel time sync status
>      > change 6001
>      > Oct  5 13:27:04 greenville-dom0 ntpd[4020]: kernel time sync status
>      > change 2001
>      > Oct  5 15:26:37 greenville-dom0 ntpd[4020]: kernel time sync status
>      > change 6001
>      > Oct  5 15:43:41 greenville-dom0 ntpd[4020]: kernel time sync status
>      > change 2001
>      > Oct  5 17:43:11 greenville-dom0 ntpd[4020]: kernel time sync status
>      > change 6001
>      > Oct  5 19:08:31 greenville-dom0 ntpd[4020]: synchronized to
>      > 192.53.103.104 <tel:192.53.103.104>, stratum 1
>      > Oct  5 19:08:31 greenville-dom0 ntpd[4020]: kernel time sync status
>      > change 2001
>      > Oct  5 21:23:58 greenville-dom0 ntpd[4020]: no servers reachable
>      > Oct  5 21:40:58 greenville-dom0 ntpd[4020]: synchronized to
>      > 192.53.103.104 <tel:192.53.103.104>, stratum 1
>      > Oct  5 21:40:58 greenville-dom0 ntpd[4020]: time correction of -30=
00
>      > seconds exceeds sanity limit (1000); set clock manually to the
>     correct
>      > UTC time.
>      >
>      > I had the problem twice on different machines but everytime I saw =
the
>      > line "no servers reachable". Could ntpd and/or linux kernel make s=
ome
>      > stupid stuff when ntp upstream servers are unreachable?
>      >
>      > Regards Andreas
>      >
>      >
>      > _______________________________________________
>      > Xen-devel mailing list
>      > Xen-devel@lists.xensource.com <mailto:Xen-devel@lists.xensource.co=
m>
>      > http://lists.xensource.com/xen-devel____
>
>     __ __
>
>

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

From xen-devel-bounces@lists.xensource.com Fri Dec 02 19:57:58 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 19: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.xensource.com>)
	id 1RWZEe-0003Re-Ac; Fri, 02 Dec 2011 19:57:28 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RWZEc-0003RY-Ug
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 19:57:27 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-10.tower-27.messagelabs.com!1322855774!46387934!1
X-Originating-IP: [208.97.132.5]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi41ID0+IDE1NjUx\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2953 invoked from network); 2 Dec 2011 19:56:14 -0000
Received: from mailbigip.dreamhost.com (HELO homiemail-a76.g.dreamhost.com)
	(208.97.132.5) by server-10.tower-27.messagelabs.com with SMTP;
	2 Dec 2011 19:56:14 -0000
Received: from homiemail-a76.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTP id 96EF2458084;
	Fri,  2 Dec 2011 11:56:49 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=C2SGHhWyMuy3U1JuebFKVFOHsaCuSF4/sMbYCcNvNOgh
	jd8x5+49/gffLc6NPlVY/PJa4vkpzljZt0Wwc/WEhf5bHZ75OgKPNddX92hEaYBu
	+IzugoblN7si8zEYEAblPTQw7AUqV7A4nhs+WGoats732tkyqBcB/sKfxRuWOP4=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=snUUOdrBErZ5RBHJnb98JBTs8M8=; b=dgcciHur
	5Nj2d69Xio2WB9gAhjkEbZp4/m++RlJWMwOS7MTezizVe446ijWP781ycmpf8ryq
	Dq8ac84pu9TXiRqed5Hf9xjV23WT7IDqahlcPqwX5wutsPl05pUmLCEfokNJipaw
	bewWrVL7loZX8xVeBv4ynlyMb54/VHgAI9k=
Received: from webmail.lagarcavilla.org (ahfbbjcaiaae.dreamhost.com
	[75.119.208.4]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTPA id E9691458080; 
	Fri,  2 Dec 2011 11:56:48 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP; Fri, 2 Dec 2011 11:56:49 -0800
Message-ID: <19affb017f36029502c4b0af8eca2d74.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20111202194344.GA1773@aepfle.de>
References: <2a4ec2e2ae36593aa74e.1322772973@xdev.gridcentric.ca>
	<20111202071148.GA23017@aepfle.de>
	<7ba95535823dd32cc2a73d78646059bc.squirrel@webmail.lagarcavilla.org>
	<20111202194344.GA1773@aepfle.de>
Date: Fri, 2 Dec 2011 11:56:49 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Olaf Hering" <olaf@aepfle.de>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com, tim@xen.org,
	keir.xen@gmail.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH] Flag events caused by foreign domains
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> On Fri, Dec 02, Andres Lagar-Cavilla wrote:
>
>> > On Thu, Dec 01, Andres Lagar-Cavilla wrote:
>> >
>> >> Add a new flag for mem events, as consumers might need to
>> discriminate
>> >> foreign domain-caused from guest-caused events. The vcpu field of an
>> >> event is bogus from a consumer p.o.v. for foreign domain-caused
>> events.
>> >
>> > How is this supposed to be used?
>> We're just OR'ing an extra flag on existing events. Toolstacks can
>> ignore
>> it, or use it to handle foreign events differently, or whatever. No new
>> events are generated, timings don't change etc.
>
> Thats obvious.
>
>> Is that your concern?
>
> I'm wondering wether it really achieves what you want, no stall in the
> ring buffer etc.
That's not what I want with this patch...
Andres
>
> Olaf
>



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

From xen-devel-bounces@lists.xensource.com Fri Dec 02 19:57:58 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 19: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.xensource.com>)
	id 1RWZEe-0003Re-Ac; Fri, 02 Dec 2011 19:57:28 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RWZEc-0003RY-Ug
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 19:57:27 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-10.tower-27.messagelabs.com!1322855774!46387934!1
X-Originating-IP: [208.97.132.5]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi41ID0+IDE1NjUx\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2953 invoked from network); 2 Dec 2011 19:56:14 -0000
Received: from mailbigip.dreamhost.com (HELO homiemail-a76.g.dreamhost.com)
	(208.97.132.5) by server-10.tower-27.messagelabs.com with SMTP;
	2 Dec 2011 19:56:14 -0000
Received: from homiemail-a76.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTP id 96EF2458084;
	Fri,  2 Dec 2011 11:56:49 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=C2SGHhWyMuy3U1JuebFKVFOHsaCuSF4/sMbYCcNvNOgh
	jd8x5+49/gffLc6NPlVY/PJa4vkpzljZt0Wwc/WEhf5bHZ75OgKPNddX92hEaYBu
	+IzugoblN7si8zEYEAblPTQw7AUqV7A4nhs+WGoats732tkyqBcB/sKfxRuWOP4=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=snUUOdrBErZ5RBHJnb98JBTs8M8=; b=dgcciHur
	5Nj2d69Xio2WB9gAhjkEbZp4/m++RlJWMwOS7MTezizVe446ijWP781ycmpf8ryq
	Dq8ac84pu9TXiRqed5Hf9xjV23WT7IDqahlcPqwX5wutsPl05pUmLCEfokNJipaw
	bewWrVL7loZX8xVeBv4ynlyMb54/VHgAI9k=
Received: from webmail.lagarcavilla.org (ahfbbjcaiaae.dreamhost.com
	[75.119.208.4]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTPA id E9691458080; 
	Fri,  2 Dec 2011 11:56:48 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP; Fri, 2 Dec 2011 11:56:49 -0800
Message-ID: <19affb017f36029502c4b0af8eca2d74.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20111202194344.GA1773@aepfle.de>
References: <2a4ec2e2ae36593aa74e.1322772973@xdev.gridcentric.ca>
	<20111202071148.GA23017@aepfle.de>
	<7ba95535823dd32cc2a73d78646059bc.squirrel@webmail.lagarcavilla.org>
	<20111202194344.GA1773@aepfle.de>
Date: Fri, 2 Dec 2011 11:56:49 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Olaf Hering" <olaf@aepfle.de>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com, tim@xen.org,
	keir.xen@gmail.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH] Flag events caused by foreign domains
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> On Fri, Dec 02, Andres Lagar-Cavilla wrote:
>
>> > On Thu, Dec 01, Andres Lagar-Cavilla wrote:
>> >
>> >> Add a new flag for mem events, as consumers might need to
>> discriminate
>> >> foreign domain-caused from guest-caused events. The vcpu field of an
>> >> event is bogus from a consumer p.o.v. for foreign domain-caused
>> events.
>> >
>> > How is this supposed to be used?
>> We're just OR'ing an extra flag on existing events. Toolstacks can
>> ignore
>> it, or use it to handle foreign events differently, or whatever. No new
>> events are generated, timings don't change etc.
>
> Thats obvious.
>
>> Is that your concern?
>
> I'm wondering wether it really achieves what you want, no stall in the
> ring buffer etc.
That's not what I want with this patch...
Andres
>
> Olaf
>



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

From xen-devel-bounces@lists.xensource.com Fri Dec 02 19:58:35 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 19:58:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWZFO-0003UZ-P8; Fri, 02 Dec 2011 19:58:14 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1RWZFN-0003U5-Dk
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 19:58:13 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-2.tower-174.messagelabs.com!1322855850!4022036!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26928 invoked from network); 2 Dec 2011 19:57:32 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-2.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 2 Dec 2011 19:57:32 -0000
Received: from andromeda.dapyr.net (darnok@localhost [127.0.0.1])
	by andromeda.dapyr.net (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id
	pB2JvRDB018845
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Fri, 2 Dec 2011 14:57:27 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pB2JvRXN018843;
	Fri, 2 Dec 2011 14:57:27 -0500
Date: Fri, 2 Dec 2011 15:57:27 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Quartexx <quartex73@gmail.com>
Message-ID: <20111202195727.GA18758@andromeda.dapyr.net>
References: <CAMhBqqiLc1994GUKtA7UY52pR29nktmFy+XiwTwpZb_E+fwFRQ@mail.gmail.com>
	<CAMhBqqgu6v8NB-X0dNdfrzd12=Y2i==fYCCC2Z+MkDupqqKAOg@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAMhBqqgu6v8NB-X0dNdfrzd12=Y2i==fYCCC2Z+MkDupqqKAOg@mail.gmail.com>
User-Agent: Mutt/1.5.9i
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] xen 4.0.1 w/2.6.32.47 hangs at boot
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Dec 02, 2011 at 08:22:46PM +0100, Quartexx wrote:
> ### lspci

<sigh> You seem to be missing the most important - that is the serial
console output with 'sync_console' enabled.

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

From xen-devel-bounces@lists.xensource.com Fri Dec 02 19:58:35 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 19:58:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWZFO-0003UZ-P8; Fri, 02 Dec 2011 19:58:14 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1RWZFN-0003U5-Dk
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 19:58:13 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-2.tower-174.messagelabs.com!1322855850!4022036!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26928 invoked from network); 2 Dec 2011 19:57:32 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-2.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 2 Dec 2011 19:57:32 -0000
Received: from andromeda.dapyr.net (darnok@localhost [127.0.0.1])
	by andromeda.dapyr.net (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id
	pB2JvRDB018845
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Fri, 2 Dec 2011 14:57:27 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pB2JvRXN018843;
	Fri, 2 Dec 2011 14:57:27 -0500
Date: Fri, 2 Dec 2011 15:57:27 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Quartexx <quartex73@gmail.com>
Message-ID: <20111202195727.GA18758@andromeda.dapyr.net>
References: <CAMhBqqiLc1994GUKtA7UY52pR29nktmFy+XiwTwpZb_E+fwFRQ@mail.gmail.com>
	<CAMhBqqgu6v8NB-X0dNdfrzd12=Y2i==fYCCC2Z+MkDupqqKAOg@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAMhBqqgu6v8NB-X0dNdfrzd12=Y2i==fYCCC2Z+MkDupqqKAOg@mail.gmail.com>
User-Agent: Mutt/1.5.9i
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] xen 4.0.1 w/2.6.32.47 hangs at boot
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Dec 02, 2011 at 08:22:46PM +0100, Quartexx wrote:
> ### lspci

<sigh> You seem to be missing the most important - that is the serial
console output with 'sync_console' enabled.

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

From xen-devel-bounces@lists.xensource.com Fri Dec 02 20:36:57 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 20: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.xensource.com>)
	id 1RWZqS-0003zf-Sl; Fri, 02 Dec 2011 20:36:32 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RWZqR-0003zV-3V
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 20:36:31 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1322858135!57496414!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTg0Mw==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9825 invoked from network); 2 Dec 2011 20:35:35 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Dec 2011 20:35:35 -0000
X-IronPort-AV: E=Sophos;i="4.71,285,1320624000"; 
   d="scan'208";a="9258845"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Dec 2011 20:35:51 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 2 Dec 2011 20:35:51 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RWZpm-0004kD-MR;
	Fri, 02 Dec 2011 20:35:50 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RWZpm-0007kw-AX;
	Fri, 02 Dec 2011 20:35:50 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <E1RWZpm-0007kw-AX@woking.xci-test.com>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 2 Dec 2011 20:35:50 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com, keir@xen.org, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [xen-unstable bisection] complete build-amd64
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

branch xen-unstable
xen branch xen-unstable
job build-amd64
test xen-build

Tree: qemu git://hg.uk.xensource.com/HG/qemu-xen-unstable.git
Tree: xen http://xenbits.xen.org/staging/xen-unstable.hg

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen http://xenbits.xen.org/staging/xen-unstable.hg
  Bug introduced:  72f4e4cb7440
  Bug not present: 109b99239b21


  changeset:   24344:72f4e4cb7440
  user:        Keir Fraser <keir@xen.org>
  date:        Fri Dec 02 06:31:14 2011 -0800
      
      tools/x86_64: Fix cpuid() inline asm to not clobber stack's red zone
      
      Pushing stuff onto the stack on x86-64 when we do not specify
      -mno-red-zone is unsafe. Since the complicated asm is due to register
      pressure on i386, we simply implement an all-new simpler alternative
      for x86-64.
      
      Signed-off-by: Keir Fraser <keir@xen.org>
      Acked-by: Jan Beulich <jbeulich@novell.com>
      
      


For bisection revision-tuple graph see:
   http://www.chiark.greenend.org.uk/~xensrcts/results/bisect.xen-unstable.build-amd64.xen-build.html
Revision IDs in each graph node refer, respectively, to the Trees above.

----------------------------------------
Searching for failure / basis pass:
 10244 fail [host=moss-bug] / 10239 ok.
Failure / basis pass flights: 10244 / 10239
Tree: qemu git://hg.uk.xensource.com/HG/qemu-xen-unstable.git
Tree: xen http://xenbits.xen.org/staging/xen-unstable.hg
Latest 65b27b1dd6f205835aa8174031eea057c75f8afb 72f4e4cb7440
Basis pass 65b27b1dd6f205835aa8174031eea057c75f8afb 60d4e257d04b
Generating revisions with ./adhoc-revtuple-generator  git://hg.uk.xensource.com/HG/qemu-xen-unstable.git#65b27b1dd6f205835aa8174031eea057c75f8afb-65b27b1dd6f205835aa8174031eea057c75f8afb http://xenbits.xen.org/staging/xen-unstable.hg#60d4e257d04b-72f4e4cb7440
pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
searching for changes
no changes found
pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
searching for changes
no changes found
Loaded 13 nodes in revision graph
Searching for test results:
 10244 fail 65b27b1dd6f205835aa8174031eea057c75f8afb 72f4e4cb7440
 10242 pass irrelevant
 10252 pass 65b27b1dd6f205835aa8174031eea057c75f8afb 109b99239b21
 10245 pass 65b27b1dd6f205835aa8174031eea057c75f8afb 60d4e257d04b
 10237 [host=potato-beetle]
 10253 fail 65b27b1dd6f205835aa8174031eea057c75f8afb 72f4e4cb7440
 10238 [host=potato-beetle]
 10247 fail 65b27b1dd6f205835aa8174031eea057c75f8afb 72f4e4cb7440
 10240 [host=itch-mite]
 10239 pass 65b27b1dd6f205835aa8174031eea057c75f8afb 60d4e257d04b
 10254 pass 65b27b1dd6f205835aa8174031eea057c75f8afb 109b99239b21
 10249 pass 65b27b1dd6f205835aa8174031eea057c75f8afb 771e2a303753
 10250 pass 65b27b1dd6f205835aa8174031eea057c75f8afb 109b99239b21
 10255 fail 65b27b1dd6f205835aa8174031eea057c75f8afb 72f4e4cb7440
 10251 fail 65b27b1dd6f205835aa8174031eea057c75f8afb 72f4e4cb7440
Searching for interesting versions
 Result found: flight 10239 (pass), for basis pass
 Result found: flight 10244 (fail), for basis failure
 Repro found: flight 10245 (pass), for basis pass
 Repro found: flight 10247 (fail), for basis failure
 0 revisions at 65b27b1dd6f205835aa8174031eea057c75f8afb 109b99239b21
No revisions left to test, checking graph state.
 Result found: flight 10250 (pass), for last pass
 Result found: flight 10251 (fail), for first failure
 Repro found: flight 10252 (pass), for last pass
 Repro found: flight 10253 (fail), for first failure
 Repro found: flight 10254 (pass), for last pass
 Repro found: flight 10255 (fail), for first failure

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen http://xenbits.xen.org/staging/xen-unstable.hg
  Bug introduced:  72f4e4cb7440
  Bug not present: 109b99239b21

pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
searching for changes
no changes found

  changeset:   24344:72f4e4cb7440
  user:        Keir Fraser <keir@xen.org>
  date:        Fri Dec 02 06:31:14 2011 -0800
      
      tools/x86_64: Fix cpuid() inline asm to not clobber stack's red zone
      
      Pushing stuff onto the stack on x86-64 when we do not specify
      -mno-red-zone is unsafe. Since the complicated asm is due to register
      pressure on i386, we simply implement an all-new simpler alternative
      for x86-64.
      
      Signed-off-by: Keir Fraser <keir@xen.org>
      Acked-by: Jan Beulich <jbeulich@novell.com>
      
      

Revision graph left in /home/xc_osstest/results/bisect.xen-unstable.build-amd64.xen-build.{dot,ps,png,html}.
----------------------------------------
10255: ALL FAIL

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


jobs:
 build-amd64                                                  fail    


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

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

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


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

From xen-devel-bounces@lists.xensource.com Fri Dec 02 20:36:57 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 20: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.xensource.com>)
	id 1RWZqS-0003zf-Sl; Fri, 02 Dec 2011 20:36:32 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RWZqR-0003zV-3V
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 20:36:31 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1322858135!57496414!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTg0Mw==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9825 invoked from network); 2 Dec 2011 20:35:35 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Dec 2011 20:35:35 -0000
X-IronPort-AV: E=Sophos;i="4.71,285,1320624000"; 
   d="scan'208";a="9258845"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Dec 2011 20:35:51 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 2 Dec 2011 20:35:51 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RWZpm-0004kD-MR;
	Fri, 02 Dec 2011 20:35:50 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RWZpm-0007kw-AX;
	Fri, 02 Dec 2011 20:35:50 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <E1RWZpm-0007kw-AX@woking.xci-test.com>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 2 Dec 2011 20:35:50 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com, keir@xen.org, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [xen-unstable bisection] complete build-amd64
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

branch xen-unstable
xen branch xen-unstable
job build-amd64
test xen-build

Tree: qemu git://hg.uk.xensource.com/HG/qemu-xen-unstable.git
Tree: xen http://xenbits.xen.org/staging/xen-unstable.hg

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen http://xenbits.xen.org/staging/xen-unstable.hg
  Bug introduced:  72f4e4cb7440
  Bug not present: 109b99239b21


  changeset:   24344:72f4e4cb7440
  user:        Keir Fraser <keir@xen.org>
  date:        Fri Dec 02 06:31:14 2011 -0800
      
      tools/x86_64: Fix cpuid() inline asm to not clobber stack's red zone
      
      Pushing stuff onto the stack on x86-64 when we do not specify
      -mno-red-zone is unsafe. Since the complicated asm is due to register
      pressure on i386, we simply implement an all-new simpler alternative
      for x86-64.
      
      Signed-off-by: Keir Fraser <keir@xen.org>
      Acked-by: Jan Beulich <jbeulich@novell.com>
      
      


For bisection revision-tuple graph see:
   http://www.chiark.greenend.org.uk/~xensrcts/results/bisect.xen-unstable.build-amd64.xen-build.html
Revision IDs in each graph node refer, respectively, to the Trees above.

----------------------------------------
Searching for failure / basis pass:
 10244 fail [host=moss-bug] / 10239 ok.
Failure / basis pass flights: 10244 / 10239
Tree: qemu git://hg.uk.xensource.com/HG/qemu-xen-unstable.git
Tree: xen http://xenbits.xen.org/staging/xen-unstable.hg
Latest 65b27b1dd6f205835aa8174031eea057c75f8afb 72f4e4cb7440
Basis pass 65b27b1dd6f205835aa8174031eea057c75f8afb 60d4e257d04b
Generating revisions with ./adhoc-revtuple-generator  git://hg.uk.xensource.com/HG/qemu-xen-unstable.git#65b27b1dd6f205835aa8174031eea057c75f8afb-65b27b1dd6f205835aa8174031eea057c75f8afb http://xenbits.xen.org/staging/xen-unstable.hg#60d4e257d04b-72f4e4cb7440
pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
searching for changes
no changes found
pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
searching for changes
no changes found
Loaded 13 nodes in revision graph
Searching for test results:
 10244 fail 65b27b1dd6f205835aa8174031eea057c75f8afb 72f4e4cb7440
 10242 pass irrelevant
 10252 pass 65b27b1dd6f205835aa8174031eea057c75f8afb 109b99239b21
 10245 pass 65b27b1dd6f205835aa8174031eea057c75f8afb 60d4e257d04b
 10237 [host=potato-beetle]
 10253 fail 65b27b1dd6f205835aa8174031eea057c75f8afb 72f4e4cb7440
 10238 [host=potato-beetle]
 10247 fail 65b27b1dd6f205835aa8174031eea057c75f8afb 72f4e4cb7440
 10240 [host=itch-mite]
 10239 pass 65b27b1dd6f205835aa8174031eea057c75f8afb 60d4e257d04b
 10254 pass 65b27b1dd6f205835aa8174031eea057c75f8afb 109b99239b21
 10249 pass 65b27b1dd6f205835aa8174031eea057c75f8afb 771e2a303753
 10250 pass 65b27b1dd6f205835aa8174031eea057c75f8afb 109b99239b21
 10255 fail 65b27b1dd6f205835aa8174031eea057c75f8afb 72f4e4cb7440
 10251 fail 65b27b1dd6f205835aa8174031eea057c75f8afb 72f4e4cb7440
Searching for interesting versions
 Result found: flight 10239 (pass), for basis pass
 Result found: flight 10244 (fail), for basis failure
 Repro found: flight 10245 (pass), for basis pass
 Repro found: flight 10247 (fail), for basis failure
 0 revisions at 65b27b1dd6f205835aa8174031eea057c75f8afb 109b99239b21
No revisions left to test, checking graph state.
 Result found: flight 10250 (pass), for last pass
 Result found: flight 10251 (fail), for first failure
 Repro found: flight 10252 (pass), for last pass
 Repro found: flight 10253 (fail), for first failure
 Repro found: flight 10254 (pass), for last pass
 Repro found: flight 10255 (fail), for first failure

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen http://xenbits.xen.org/staging/xen-unstable.hg
  Bug introduced:  72f4e4cb7440
  Bug not present: 109b99239b21

pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
searching for changes
no changes found

  changeset:   24344:72f4e4cb7440
  user:        Keir Fraser <keir@xen.org>
  date:        Fri Dec 02 06:31:14 2011 -0800
      
      tools/x86_64: Fix cpuid() inline asm to not clobber stack's red zone
      
      Pushing stuff onto the stack on x86-64 when we do not specify
      -mno-red-zone is unsafe. Since the complicated asm is due to register
      pressure on i386, we simply implement an all-new simpler alternative
      for x86-64.
      
      Signed-off-by: Keir Fraser <keir@xen.org>
      Acked-by: Jan Beulich <jbeulich@novell.com>
      
      

Revision graph left in /home/xc_osstest/results/bisect.xen-unstable.build-amd64.xen-build.{dot,ps,png,html}.
----------------------------------------
10255: ALL FAIL

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


jobs:
 build-amd64                                                  fail    


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

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

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


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

From xen-devel-bounces@lists.xensource.com Fri Dec 02 20:53:20 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 20:53:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWa6H-0004JI-F0; Fri, 02 Dec 2011 20:52:53 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ksrujandas@gmail.com>) id 1RWa6G-0004J6-3P
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 20:52:52 +0000
X-Env-Sender: ksrujandas@gmail.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1322859126!6752147!1
X-Originating-IP: [209.85.214.43]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23790 invoked from network); 2 Dec 2011 20:52:10 -0000
Received: from mail-bw0-f43.google.com (HELO mail-bw0-f43.google.com)
	(209.85.214.43)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Dec 2011 20:52:10 -0000
Received: by bkbzu17 with SMTP id zu17so5998663bkb.30
	for <xen-devel@lists.xensource.com>;
	Fri, 02 Dec 2011 12:52:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=CzN4qL/GcXPPFq/K33/ABcao3VYeb0+w99EyH5SmtmU=;
	b=q6Eqp1Ybk0OMAsC9rW6p+7/mpzWZ3dBPHrot1z+yvbvamX4TzAh9QnT2Egkp8JED18
	BGSo86Uo+Qxs2x8/+OFDyNdTiEE2vMY6x3HpH38EAjtjvZTlZ5LVYKndO7OAq4KIN2R/
	gWXQrVt6WzU3NNhuGOjHIkcSAn++zMGSNfPNg=
MIME-Version: 1.0
Received: by 10.204.10.77 with SMTP id o13mr12287359bko.12.1322859125860; Fri,
	02 Dec 2011 12:52:05 -0800 (PST)
Received: by 10.204.66.77 with HTTP; Fri, 2 Dec 2011 12:52:05 -0800 (PST)
Date: Fri, 2 Dec 2011 14:52:05 -0600
Message-ID: <CAKLFbfwYyKM=feBXQdj00XAvy+YWdBddLBWCv0CVROwA3bTGJg@mail.gmail.com>
From: Srujan Kotikela <ksrujandas@gmail.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] Ring3 Hypercalls from HVM DomU
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============2663830038745577097=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============2663830038745577097==
Content-Type: multipart/alternative; boundary=00151747903248e8f704b32224ef

--00151747903248e8f704b32224ef
Content-Type: text/plain; charset=ISO-8859-1

Hi,

I have created hypercalls that can be invoked from ring-3 by setting the
ring-3 gate in xen. This works fine when I invoke the hypercall from Dom0.
I want to invoke the same from a HVM DomU. But I keep getting the
segmentation fault when I invoke the ring3_hyperacall from HVM DomU. Any
ideas?

*The setting up gate is as follows:*
_set_gate(idt_table+0x92, 14, 3, &hypercall);
*
The hypercall invoking code looks like this:*
int ring3_hypercall(unsigned long va, int command)
{
    int ret;

    asm("int $0x92" : "=a"(ret) : "a"(40), "b"(va), "c"(command));

    return ret;
}

~ SDK

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

Hi,<div><br></div><div>I have created hypercalls that can be invoked from r=
ing-3 by setting the ring-3 gate in xen. This works fine when I invoke the =
hypercall from Dom0. I want to invoke the same from a HVM DomU. But I keep =
getting the segmentation fault when I invoke the ring3_hyperacall from HVM =
DomU. Any ideas?<br>
<br><b>The setting up gate is as follows:</b><br>_set_gate(idt_table+0x92, =
14, 3, &amp;hypercall);<br></div>
<div><b><br>The hypercall invoking code looks like this:</b><br>
int ring3_hypercall(unsigned long va, int command)<br>
{<br>
=A0=A0=A0 int ret;<br>
<br>
=A0=A0=A0 asm(&quot;int $0x92&quot; : &quot;=3Da&quot;(ret) : &quot;a&quot;=
(40), &quot;b&quot;(va), &quot;c&quot;(command));<br>
=A0=A0=A0 <br>
=A0=A0=A0 return ret;<br>
}<br>
<br clear=3D"all">~ SDK<br><br>
</div>

--00151747903248e8f704b32224ef--


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

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

--===============2663830038745577097==--


From xen-devel-bounces@lists.xensource.com Fri Dec 02 20:53:20 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 20:53:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWa6H-0004JI-F0; Fri, 02 Dec 2011 20:52:53 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ksrujandas@gmail.com>) id 1RWa6G-0004J6-3P
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 20:52:52 +0000
X-Env-Sender: ksrujandas@gmail.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1322859126!6752147!1
X-Originating-IP: [209.85.214.43]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23790 invoked from network); 2 Dec 2011 20:52:10 -0000
Received: from mail-bw0-f43.google.com (HELO mail-bw0-f43.google.com)
	(209.85.214.43)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Dec 2011 20:52:10 -0000
Received: by bkbzu17 with SMTP id zu17so5998663bkb.30
	for <xen-devel@lists.xensource.com>;
	Fri, 02 Dec 2011 12:52:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=CzN4qL/GcXPPFq/K33/ABcao3VYeb0+w99EyH5SmtmU=;
	b=q6Eqp1Ybk0OMAsC9rW6p+7/mpzWZ3dBPHrot1z+yvbvamX4TzAh9QnT2Egkp8JED18
	BGSo86Uo+Qxs2x8/+OFDyNdTiEE2vMY6x3HpH38EAjtjvZTlZ5LVYKndO7OAq4KIN2R/
	gWXQrVt6WzU3NNhuGOjHIkcSAn++zMGSNfPNg=
MIME-Version: 1.0
Received: by 10.204.10.77 with SMTP id o13mr12287359bko.12.1322859125860; Fri,
	02 Dec 2011 12:52:05 -0800 (PST)
Received: by 10.204.66.77 with HTTP; Fri, 2 Dec 2011 12:52:05 -0800 (PST)
Date: Fri, 2 Dec 2011 14:52:05 -0600
Message-ID: <CAKLFbfwYyKM=feBXQdj00XAvy+YWdBddLBWCv0CVROwA3bTGJg@mail.gmail.com>
From: Srujan Kotikela <ksrujandas@gmail.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] Ring3 Hypercalls from HVM DomU
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============2663830038745577097=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============2663830038745577097==
Content-Type: multipart/alternative; boundary=00151747903248e8f704b32224ef

--00151747903248e8f704b32224ef
Content-Type: text/plain; charset=ISO-8859-1

Hi,

I have created hypercalls that can be invoked from ring-3 by setting the
ring-3 gate in xen. This works fine when I invoke the hypercall from Dom0.
I want to invoke the same from a HVM DomU. But I keep getting the
segmentation fault when I invoke the ring3_hyperacall from HVM DomU. Any
ideas?

*The setting up gate is as follows:*
_set_gate(idt_table+0x92, 14, 3, &hypercall);
*
The hypercall invoking code looks like this:*
int ring3_hypercall(unsigned long va, int command)
{
    int ret;

    asm("int $0x92" : "=a"(ret) : "a"(40), "b"(va), "c"(command));

    return ret;
}

~ SDK

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

Hi,<div><br></div><div>I have created hypercalls that can be invoked from r=
ing-3 by setting the ring-3 gate in xen. This works fine when I invoke the =
hypercall from Dom0. I want to invoke the same from a HVM DomU. But I keep =
getting the segmentation fault when I invoke the ring3_hyperacall from HVM =
DomU. Any ideas?<br>
<br><b>The setting up gate is as follows:</b><br>_set_gate(idt_table+0x92, =
14, 3, &amp;hypercall);<br></div>
<div><b><br>The hypercall invoking code looks like this:</b><br>
int ring3_hypercall(unsigned long va, int command)<br>
{<br>
=A0=A0=A0 int ret;<br>
<br>
=A0=A0=A0 asm(&quot;int $0x92&quot; : &quot;=3Da&quot;(ret) : &quot;a&quot;=
(40), &quot;b&quot;(va), &quot;c&quot;(command));<br>
=A0=A0=A0 <br>
=A0=A0=A0 return ret;<br>
}<br>
<br clear=3D"all">~ SDK<br><br>
</div>

--00151747903248e8f704b32224ef--


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

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

--===============2663830038745577097==--


From xen-devel-bounces@lists.xensource.com Fri Dec 02 21:17:18 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 21:17:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWaTM-0004nz-Na; Fri, 02 Dec 2011 21:16:44 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RWaTL-0004nq-6Z
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 21:16:43 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1322860560!5700340!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTg0Mw==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18156 invoked from network); 2 Dec 2011 21:16:01 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Dec 2011 21:16:01 -0000
X-IronPort-AV: E=Sophos;i="4.71,286,1320624000"; 
   d="scan'208";a="9259066"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Dec 2011 21:16:00 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 2 Dec 2011 21:16:00 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RWaSe-0004xI-3Z;
	Fri, 02 Dec 2011 21:16:00 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RWaSd-0006GJ-UZ;
	Fri, 02 Dec 2011 21:15:59 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10246-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 2 Dec 2011 21:15:59 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10246: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

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

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-amd64-xl-win       8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-i386-win-vcpus1    8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-i386-win           8 guest-saverestore         fail REGR. vs. 10201
 test-i386-i386-win            8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-i386-xl-win-vcpus1  8 guest-saverestore        fail REGR. vs. 10201
 test-i386-i386-xl-win         8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-amd64-win          8 guest-saverestore         fail REGR. vs. 10201

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-win7-amd64  7 windows-install              fail never pass
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install          fail never pass
 test-amd64-i386-xl-win7-amd64  7 windows-install              fail  never pass
 test-i386-i386-xl-winxpsp3    7 windows-install              fail   never pass
 test-amd64-i386-xend-winxpsp3  7 windows-install              fail  never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass

version targeted for testing:
 xen                  491c3ebf1d37
baseline version:
 xen                  62ff6a318c5d

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Anthony PERARD <anthony.perard@citrix.com>
  Brendan Cully <brendan@cs.ubc.ca>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@novell.com>
  Jan Beulich <jbeulich@suse.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Jonathan Davies <jonathan.davies@citrix.com>
  juergen.gross@ts.fujitsu.com
  Keir Fraser <keir@xen.org>
  Liu, Jinsong <jinsong.liu@intel.com>
  Olaf Hering <olaf@aepfle.de>
  Philipp Hahn <hahn@univention.de>
  Shriram Rajagopalan <rshriram@cs.ubc.ca>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang2 <wei.wang2@amd.com>
------------------------------------------------------------

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


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

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

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


Not pushing.

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

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

From xen-devel-bounces@lists.xensource.com Fri Dec 02 21:17:18 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 21:17:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWaTM-0004nz-Na; Fri, 02 Dec 2011 21:16:44 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RWaTL-0004nq-6Z
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 21:16:43 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1322860560!5700340!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTg0Mw==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18156 invoked from network); 2 Dec 2011 21:16:01 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Dec 2011 21:16:01 -0000
X-IronPort-AV: E=Sophos;i="4.71,286,1320624000"; 
   d="scan'208";a="9259066"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Dec 2011 21:16:00 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 2 Dec 2011 21:16:00 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RWaSe-0004xI-3Z;
	Fri, 02 Dec 2011 21:16:00 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RWaSd-0006GJ-UZ;
	Fri, 02 Dec 2011 21:15:59 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10246-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 2 Dec 2011 21:15:59 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10246: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

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

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-amd64-xl-win       8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-i386-win-vcpus1    8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-i386-win           8 guest-saverestore         fail REGR. vs. 10201
 test-i386-i386-win            8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-i386-xl-win-vcpus1  8 guest-saverestore        fail REGR. vs. 10201
 test-i386-i386-xl-win         8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-amd64-win          8 guest-saverestore         fail REGR. vs. 10201

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-win7-amd64  7 windows-install              fail never pass
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install          fail never pass
 test-amd64-i386-xl-win7-amd64  7 windows-install              fail  never pass
 test-i386-i386-xl-winxpsp3    7 windows-install              fail   never pass
 test-amd64-i386-xend-winxpsp3  7 windows-install              fail  never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass

version targeted for testing:
 xen                  491c3ebf1d37
baseline version:
 xen                  62ff6a318c5d

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Anthony PERARD <anthony.perard@citrix.com>
  Brendan Cully <brendan@cs.ubc.ca>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@novell.com>
  Jan Beulich <jbeulich@suse.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Jonathan Davies <jonathan.davies@citrix.com>
  juergen.gross@ts.fujitsu.com
  Keir Fraser <keir@xen.org>
  Liu, Jinsong <jinsong.liu@intel.com>
  Olaf Hering <olaf@aepfle.de>
  Philipp Hahn <hahn@univention.de>
  Shriram Rajagopalan <rshriram@cs.ubc.ca>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang2 <wei.wang2@amd.com>
------------------------------------------------------------

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


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

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

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


Not pushing.

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

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

From xen-devel-bounces@lists.xensource.com Fri Dec 02 21:51:11 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 21:51:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWb0B-0005LA-KU; Fri, 02 Dec 2011 21:50:39 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pasik@iki.fi>) id 1RWb09-0005Kw-PP
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 21:50:38 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-13.tower-174.messagelabs.com!1322862595!4057523!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA0NTQ4MTE=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17783 invoked from network); 2 Dec 2011 21:49:56 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-13.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 2 Dec 2011 21:49:56 -0000
X-Originating-Ip: [194.89.68.22]
Received: from ydin.reaktio.net (reaktio.net [194.89.68.22])
	by smtp.tele.fi (Postfix) with ESMTP id 3AEA62643;
	Fri,  2 Dec 2011 23:49:54 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id EDF612009A; Fri,  2 Dec 2011 23:49:53 +0200 (EET)
Date: Fri, 2 Dec 2011 23:49:53 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20111202214953.GM12984@reaktio.net>
References: <4ED798B2.1040309@canonical.com>
	<20111201180944.GH12984@reaktio.net>
	<4ED8A45A.3050403@canonical.com>
	<20111202104110.GL12984@reaktio.net>
	<BA1B675D85BDD87795D1666C@Ximines.local>
	<1322844048.29870.155.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1322844048.29870.155.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.18 (2008-05-17)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefan Bader <stefan.bader@canonical.com>, Alex Bligh <alex@alex.org.uk>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Xen 4.x / Linux 3.x (dom0 and HVM domU) and
	NIC	handling
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Dec 02, 2011 at 04:40:48PM +0000, Ian Campbell wrote:
> On Fri, 2011-12-02 at 16:36 +0000, Alex Bligh wrote:
> > =

> > --On 2 December 2011 12:41:10 +0200 Pasi K=E4rkk=E4inen <pasik@iki.fi> =
wrote:
> > =

> > >> And then, ok this is probably a quite naive approach, it seemed to m=
ake
> > >> sense to go through the pain of always having potentially both
> > >> interfaces available (emulated and pv) so in theory the same guest
> > >> config can accommodate a guest os supporting one or the other (or ea=
sily
> > >> switch from one to the other). Otherwise I would expect an emulated
> > >> device only when I have hd? in the config and a pv device when I wri=
te
> > >> xvd?.
> > >>
> > >
> > > This works for both HVM and PVHVM (also mentioned on the wiki page):
> > > vif =3D [ 'mac=3D00:16:5e:02:07:45, bridge=3Dxenbr0, model=3De1000' ]
> > >
> > > So there's no need for "type=3Dioemu" option with xm/xend.
> > >
> > > You can switch between HVM and PVHVM with:
> > > xen_platform_pci=3D0|1
> > =

> > AFAIK changing xen_platform_pci=3D0|1 will switch rather more than just
> > the NIC. It will switch your disk too, instantly causing your previously
> > happily booting OS to fail to boot as the root device name changes.
> =

> We recommend you use "root=3DLABEL=3Dfoo" rather than "root=3D/dev/blah" =
for
> this reason. Fortunately most distros use that scheme by default these
> days.
> =


Yep, for example Fedora works out-of-the-box with both HVM and PVHVM..

-- Pasi


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

From xen-devel-bounces@lists.xensource.com Fri Dec 02 21:51:11 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 02 Dec 2011 21:51:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWb0B-0005LA-KU; Fri, 02 Dec 2011 21:50:39 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pasik@iki.fi>) id 1RWb09-0005Kw-PP
	for xen-devel@lists.xensource.com; Fri, 02 Dec 2011 21:50:38 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-13.tower-174.messagelabs.com!1322862595!4057523!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA0NTQ4MTE=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17783 invoked from network); 2 Dec 2011 21:49:56 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-13.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 2 Dec 2011 21:49:56 -0000
X-Originating-Ip: [194.89.68.22]
Received: from ydin.reaktio.net (reaktio.net [194.89.68.22])
	by smtp.tele.fi (Postfix) with ESMTP id 3AEA62643;
	Fri,  2 Dec 2011 23:49:54 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id EDF612009A; Fri,  2 Dec 2011 23:49:53 +0200 (EET)
Date: Fri, 2 Dec 2011 23:49:53 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20111202214953.GM12984@reaktio.net>
References: <4ED798B2.1040309@canonical.com>
	<20111201180944.GH12984@reaktio.net>
	<4ED8A45A.3050403@canonical.com>
	<20111202104110.GL12984@reaktio.net>
	<BA1B675D85BDD87795D1666C@Ximines.local>
	<1322844048.29870.155.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1322844048.29870.155.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.18 (2008-05-17)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefan Bader <stefan.bader@canonical.com>, Alex Bligh <alex@alex.org.uk>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Xen 4.x / Linux 3.x (dom0 and HVM domU) and
	NIC	handling
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Dec 02, 2011 at 04:40:48PM +0000, Ian Campbell wrote:
> On Fri, 2011-12-02 at 16:36 +0000, Alex Bligh wrote:
> > =

> > --On 2 December 2011 12:41:10 +0200 Pasi K=E4rkk=E4inen <pasik@iki.fi> =
wrote:
> > =

> > >> And then, ok this is probably a quite naive approach, it seemed to m=
ake
> > >> sense to go through the pain of always having potentially both
> > >> interfaces available (emulated and pv) so in theory the same guest
> > >> config can accommodate a guest os supporting one or the other (or ea=
sily
> > >> switch from one to the other). Otherwise I would expect an emulated
> > >> device only when I have hd? in the config and a pv device when I wri=
te
> > >> xvd?.
> > >>
> > >
> > > This works for both HVM and PVHVM (also mentioned on the wiki page):
> > > vif =3D [ 'mac=3D00:16:5e:02:07:45, bridge=3Dxenbr0, model=3De1000' ]
> > >
> > > So there's no need for "type=3Dioemu" option with xm/xend.
> > >
> > > You can switch between HVM and PVHVM with:
> > > xen_platform_pci=3D0|1
> > =

> > AFAIK changing xen_platform_pci=3D0|1 will switch rather more than just
> > the NIC. It will switch your disk too, instantly causing your previously
> > happily booting OS to fail to boot as the root device name changes.
> =

> We recommend you use "root=3DLABEL=3Dfoo" rather than "root=3D/dev/blah" =
for
> this reason. Fortunately most distros use that scheme by default these
> days.
> =


Yep, for example Fedora works out-of-the-box with both HVM and PVHVM..

-- Pasi


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

From xen-devel-bounces@lists.xensource.com Sat Dec 03 00:34:49 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 03 Dec 2011 00:34:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWdYP-0008Mx-Cg; Sat, 03 Dec 2011 00:34:09 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RWdYO-0008Mp-9h
	for xen-devel@lists.xensource.com; Sat, 03 Dec 2011 00:34:08 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1322872404!4083322!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTg0Mw==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32569 invoked from network); 3 Dec 2011 00:33:25 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Dec 2011 00:33:25 -0000
X-IronPort-AV: E=Sophos;i="4.71,286,1320624000"; 
   d="scan'208";a="9260259"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Dec 2011 00:33:23 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sat, 3 Dec 2011 00:33:23 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RWdXe-000659-W0;
	Sat, 03 Dec 2011 00:33:23 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RWdXe-0000Ur-Va;
	Sat, 03 Dec 2011 00:33:22 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10257-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 3 Dec 2011 00:33:22 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10257: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

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

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-amd64-win          8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-amd64-xl-win       8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-i386-win-vcpus1    8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-i386-win           8 guest-saverestore         fail REGR. vs. 10201
 test-i386-i386-win            8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-i386-xl-win-vcpus1  8 guest-saverestore        fail REGR. vs. 10201
 test-i386-i386-xl-win         8 guest-saverestore         fail REGR. vs. 10201

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf     14 guest-localmigrate/x10      fail pass in 10246

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-win7-amd64  7 windows-install              fail never pass
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install          fail never pass
 test-amd64-i386-xl-win7-amd64  7 windows-install              fail  never pass
 test-i386-i386-xl-winxpsp3    7 windows-install              fail   never pass
 test-amd64-i386-xend-winxpsp3  7 windows-install              fail  never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass

version targeted for testing:
 xen                  491c3ebf1d37
baseline version:
 xen                  62ff6a318c5d

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Anthony PERARD <anthony.perard@citrix.com>
  Brendan Cully <brendan@cs.ubc.ca>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@novell.com>
  Jan Beulich <jbeulich@suse.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Jonathan Davies <jonathan.davies@citrix.com>
  juergen.gross@ts.fujitsu.com
  Keir Fraser <keir@xen.org>
  Liu, Jinsong <jinsong.liu@intel.com>
  Olaf Hering <olaf@aepfle.de>
  Philipp Hahn <hahn@univention.de>
  Shriram Rajagopalan <rshriram@cs.ubc.ca>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang2 <wei.wang2@amd.com>
------------------------------------------------------------

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


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 1132 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Dec 03 00:34:49 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 03 Dec 2011 00:34:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWdYP-0008Mx-Cg; Sat, 03 Dec 2011 00:34:09 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RWdYO-0008Mp-9h
	for xen-devel@lists.xensource.com; Sat, 03 Dec 2011 00:34:08 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1322872404!4083322!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTg0Mw==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32569 invoked from network); 3 Dec 2011 00:33:25 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Dec 2011 00:33:25 -0000
X-IronPort-AV: E=Sophos;i="4.71,286,1320624000"; 
   d="scan'208";a="9260259"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Dec 2011 00:33:23 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sat, 3 Dec 2011 00:33:23 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RWdXe-000659-W0;
	Sat, 03 Dec 2011 00:33:23 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RWdXe-0000Ur-Va;
	Sat, 03 Dec 2011 00:33:22 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10257-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 3 Dec 2011 00:33:22 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10257: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10257 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10257/

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-amd64-win          8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-amd64-xl-win       8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-i386-win-vcpus1    8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-i386-win           8 guest-saverestore         fail REGR. vs. 10201
 test-i386-i386-win            8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-i386-xl-win-vcpus1  8 guest-saverestore        fail REGR. vs. 10201
 test-i386-i386-xl-win         8 guest-saverestore         fail REGR. vs. 10201

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf     14 guest-localmigrate/x10      fail pass in 10246

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-win7-amd64  7 windows-install              fail never pass
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install          fail never pass
 test-amd64-i386-xl-win7-amd64  7 windows-install              fail  never pass
 test-i386-i386-xl-winxpsp3    7 windows-install              fail   never pass
 test-amd64-i386-xend-winxpsp3  7 windows-install              fail  never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass

version targeted for testing:
 xen                  491c3ebf1d37
baseline version:
 xen                  62ff6a318c5d

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Anthony PERARD <anthony.perard@citrix.com>
  Brendan Cully <brendan@cs.ubc.ca>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@novell.com>
  Jan Beulich <jbeulich@suse.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Jonathan Davies <jonathan.davies@citrix.com>
  juergen.gross@ts.fujitsu.com
  Keir Fraser <keir@xen.org>
  Liu, Jinsong <jinsong.liu@intel.com>
  Olaf Hering <olaf@aepfle.de>
  Philipp Hahn <hahn@univention.de>
  Shriram Rajagopalan <rshriram@cs.ubc.ca>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang2 <wei.wang2@amd.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 1132 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Dec 03 04:07:50 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 03 Dec 2011 04:07:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWgsT-0005Ee-Nh; Sat, 03 Dec 2011 04:07:05 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RWgsS-0005EZ-Ca
	for xen-devel@lists.xensource.com; Sat, 03 Dec 2011 04:07:04 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1322885181!6769481!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTkwMw==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23814 invoked from network); 3 Dec 2011 04:06:21 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Dec 2011 04:06:21 -0000
X-IronPort-AV: E=Sophos;i="4.71,287,1320624000"; 
   d="scan'208";a="9262320"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Dec 2011 04:06:20 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sat, 3 Dec 2011 04:06:20 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RWgrk-0007IB-I1;
	Sat, 03 Dec 2011 04:06:20 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RWgrk-0003lq-HX;
	Sat, 03 Dec 2011 04:06:20 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10264-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 3 Dec 2011 04:06:20 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10264: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10264 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10264/

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-i386-xl-winxpsp3-vcpus1  4 xen-install         fail REGR. vs. 10201
 test-amd64-i386-xl-win7-amd64  4 xen-install              fail REGR. vs. 10201
 test-amd64-i386-xend-winxpsp3  4 xen-install              fail REGR. vs. 10201
 test-amd64-i386-pv            4 xen-install               fail REGR. vs. 10201
 test-amd64-i386-xl-multivcpu  4 xen-install               fail REGR. vs. 10201
 test-amd64-i386-xl            4 xen-install               fail REGR. vs. 10201
 test-amd64-i386-pair          6 xen-install/dst_host      fail REGR. vs. 10201
 test-amd64-i386-pair          5 xen-install/src_host      fail REGR. vs. 10201
 build-i386                    4 xen-build                 fail REGR. vs. 10201
 build-i386-oldkern            4 xen-build                 fail REGR. vs. 10201
 test-amd64-i386-rhel6hvm-intel  4 xen-install             fail REGR. vs. 10201
 test-amd64-i386-rhel6hvm-amd  4 xen-install               fail REGR. vs. 10201
 test-amd64-i386-xl-credit2    4 xen-install               fail REGR. vs. 10201
 test-amd64-amd64-win          8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-amd64-xl-win       8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-i386-win-vcpus1    4 xen-install               fail REGR. vs. 10201
 test-amd64-i386-win           4 xen-install               fail REGR. vs. 10201
 test-amd64-i386-xl-win-vcpus1  4 xen-install              fail REGR. vs. 10201

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-win7-amd64  7 windows-install              fail never pass
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   never pass
 test-i386-i386-xl-winxpsp3    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-i386-i386-pv             1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl             1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pair           1 xen-build-check(1)           blocked  n/a
 test-i386-i386-win            1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-win         1 xen-build-check(1)           blocked  n/a

version targeted for testing:
 xen                  a4d7c27ec1f1
baseline version:
 xen                  62ff6a318c5d

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Anthony PERARD <anthony.perard@citrix.com>
  Brendan Cully <brendan@cs.ubc.ca>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@novell.com>
  Jan Beulich <jbeulich@suse.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Jonathan Davies <jonathan.davies@citrix.com>
  juergen.gross@ts.fujitsu.com
  Keir Fraser <keir@xen.org>
  Liu, Jinsong <jinsong.liu@intel.com>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
  Philipp Hahn <hahn@univention.de>
  Shriram Rajagopalan <rshriram@cs.ubc.ca>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang2 <wei.wang2@amd.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   fail    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           fail    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           fail    
 test-i386-i386-xl                                            blocked 
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-i386-i386-pair                                          blocked 
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           fail    
 test-i386-i386-pv                                            blocked 
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           blocked 
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        blocked 
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   blocked 


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 1262 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Dec 03 04:07:50 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 03 Dec 2011 04:07:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWgsT-0005Ee-Nh; Sat, 03 Dec 2011 04:07:05 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RWgsS-0005EZ-Ca
	for xen-devel@lists.xensource.com; Sat, 03 Dec 2011 04:07:04 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1322885181!6769481!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTkwMw==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23814 invoked from network); 3 Dec 2011 04:06:21 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Dec 2011 04:06:21 -0000
X-IronPort-AV: E=Sophos;i="4.71,287,1320624000"; 
   d="scan'208";a="9262320"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Dec 2011 04:06:20 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sat, 3 Dec 2011 04:06:20 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RWgrk-0007IB-I1;
	Sat, 03 Dec 2011 04:06:20 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RWgrk-0003lq-HX;
	Sat, 03 Dec 2011 04:06:20 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10264-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 3 Dec 2011 04:06:20 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10264: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10264 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10264/

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-i386-xl-winxpsp3-vcpus1  4 xen-install         fail REGR. vs. 10201
 test-amd64-i386-xl-win7-amd64  4 xen-install              fail REGR. vs. 10201
 test-amd64-i386-xend-winxpsp3  4 xen-install              fail REGR. vs. 10201
 test-amd64-i386-pv            4 xen-install               fail REGR. vs. 10201
 test-amd64-i386-xl-multivcpu  4 xen-install               fail REGR. vs. 10201
 test-amd64-i386-xl            4 xen-install               fail REGR. vs. 10201
 test-amd64-i386-pair          6 xen-install/dst_host      fail REGR. vs. 10201
 test-amd64-i386-pair          5 xen-install/src_host      fail REGR. vs. 10201
 build-i386                    4 xen-build                 fail REGR. vs. 10201
 build-i386-oldkern            4 xen-build                 fail REGR. vs. 10201
 test-amd64-i386-rhel6hvm-intel  4 xen-install             fail REGR. vs. 10201
 test-amd64-i386-rhel6hvm-amd  4 xen-install               fail REGR. vs. 10201
 test-amd64-i386-xl-credit2    4 xen-install               fail REGR. vs. 10201
 test-amd64-amd64-win          8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-amd64-xl-win       8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-i386-win-vcpus1    4 xen-install               fail REGR. vs. 10201
 test-amd64-i386-win           4 xen-install               fail REGR. vs. 10201
 test-amd64-i386-xl-win-vcpus1  4 xen-install              fail REGR. vs. 10201

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-win7-amd64  7 windows-install              fail never pass
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   never pass
 test-i386-i386-xl-winxpsp3    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-i386-i386-pv             1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl             1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pair           1 xen-build-check(1)           blocked  n/a
 test-i386-i386-win            1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-win         1 xen-build-check(1)           blocked  n/a

version targeted for testing:
 xen                  a4d7c27ec1f1
baseline version:
 xen                  62ff6a318c5d

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Anthony PERARD <anthony.perard@citrix.com>
  Brendan Cully <brendan@cs.ubc.ca>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@novell.com>
  Jan Beulich <jbeulich@suse.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Jonathan Davies <jonathan.davies@citrix.com>
  juergen.gross@ts.fujitsu.com
  Keir Fraser <keir@xen.org>
  Liu, Jinsong <jinsong.liu@intel.com>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
  Philipp Hahn <hahn@univention.de>
  Shriram Rajagopalan <rshriram@cs.ubc.ca>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang2 <wei.wang2@amd.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   fail    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           fail    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           fail    
 test-i386-i386-xl                                            blocked 
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-i386-i386-pair                                          blocked 
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           fail    
 test-i386-i386-pv                                            blocked 
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           blocked 
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        blocked 
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   blocked 


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 1262 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Dec 03 05:49:46 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 03 Dec 2011 05:49:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWiT7-0005rH-LO; Sat, 03 Dec 2011 05:49:01 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RWiT6-0005rC-IC
	for xen-devel@lists.xensource.com; Sat, 03 Dec 2011 05:49:00 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1322891297!4071453!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTkwMw==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21696 invoked from network); 3 Dec 2011 05:48:17 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Dec 2011 05:48:17 -0000
X-IronPort-AV: E=Sophos;i="4.71,288,1320624000"; 
   d="scan'208";a="9264504"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Dec 2011 05:48:16 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sat, 3 Dec 2011 05:48:16 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RWiSO-0007re-5l;
	Sat, 03 Dec 2011 05:48:16 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RWiSO-0000Jn-4c;
	Sat, 03 Dec 2011 05:48:16 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <E1RWiSO-0000Jn-4c@woking.xci-test.com>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 3 Dec 2011 05:48:16 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com, keir@xen.org, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [xen-unstable bisection] complete build-i386
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

branch xen-unstable
xen branch xen-unstable
job build-i386
test xen-build

Tree: qemu git://hg.uk.xensource.com/HG/qemu-xen-unstable.git
Tree: xen http://xenbits.xen.org/staging/xen-unstable.hg

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen http://xenbits.xen.org/staging/xen-unstable.hg
  Bug introduced:  72f4e4cb7440
  Bug not present: 109b99239b21


  changeset:   24344:72f4e4cb7440
  user:        Keir Fraser <keir@xen.org>
  date:        Fri Dec 02 06:31:14 2011 -0800
      
      tools/x86_64: Fix cpuid() inline asm to not clobber stack's red zone
      
      Pushing stuff onto the stack on x86-64 when we do not specify
      -mno-red-zone is unsafe. Since the complicated asm is due to register
      pressure on i386, we simply implement an all-new simpler alternative
      for x86-64.
      
      Signed-off-by: Keir Fraser <keir@xen.org>
      Acked-by: Jan Beulich <jbeulich@novell.com>
      
      


For bisection revision-tuple graph see:
   http://www.chiark.greenend.org.uk/~xensrcts/results/bisect.xen-unstable.build-i386.xen-build.html
Revision IDs in each graph node refer, respectively, to the Trees above.

----------------------------------------
Searching for failure / basis pass:
 10264 fail [host=itch-mite] / 10257 [host=woodlouse] 10246 [host=gall-mite] 10239 ok.
Failure / basis pass flights: 10264 / 10239
Tree: qemu git://hg.uk.xensource.com/HG/qemu-xen-unstable.git
Tree: xen http://xenbits.xen.org/staging/xen-unstable.hg
Latest 65b27b1dd6f205835aa8174031eea057c75f8afb a4d7c27ec1f1
Basis pass 65b27b1dd6f205835aa8174031eea057c75f8afb 60d4e257d04b
Generating revisions with ./adhoc-revtuple-generator  git://hg.uk.xensource.com/HG/qemu-xen-unstable.git#65b27b1dd6f205835aa8174031eea057c75f8afb-65b27b1dd6f205835aa8174031eea057c75f8afb http://xenbits.xen.org/staging/xen-unstable.hg#60d4e257d04b-a4d7c27ec1f1
pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
searching for changes
no changes found
pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
searching for changes
no changes found
Loaded 23 nodes in revision graph
Searching for test results:
 10244 fail 65b27b1dd6f205835aa8174031eea057c75f8afb 72f4e4cb7440
 10257 [host=woodlouse]
 10239 pass 65b27b1dd6f205835aa8174031eea057c75f8afb 60d4e257d04b
 10266 pass 65b27b1dd6f205835aa8174031eea057c75f8afb 60d4e257d04b
 10246 [host=gall-mite]
 10264 fail 65b27b1dd6f205835aa8174031eea057c75f8afb a4d7c27ec1f1
 10269 pass 65b27b1dd6f205835aa8174031eea057c75f8afb 109b99239b21
 10268 pass 65b27b1dd6f205835aa8174031eea057c75f8afb 771e2a303753
 10267 fail 65b27b1dd6f205835aa8174031eea057c75f8afb a4d7c27ec1f1
 10271 pass 65b27b1dd6f205835aa8174031eea057c75f8afb 109b99239b21
 10270 fail 65b27b1dd6f205835aa8174031eea057c75f8afb 72f4e4cb7440
 10272 fail 65b27b1dd6f205835aa8174031eea057c75f8afb 72f4e4cb7440
 10273 pass 65b27b1dd6f205835aa8174031eea057c75f8afb 109b99239b21
 10274 fail 65b27b1dd6f205835aa8174031eea057c75f8afb 72f4e4cb7440
Searching for interesting versions
 Result found: flight 10239 (pass), for basis pass
 Result found: flight 10264 (fail), for basis failure
 Repro found: flight 10266 (pass), for basis pass
 Repro found: flight 10267 (fail), for basis failure
 0 revisions at 65b27b1dd6f205835aa8174031eea057c75f8afb 109b99239b21
No revisions left to test, checking graph state.
 Result found: flight 10269 (pass), for last pass
 Result found: flight 10270 (fail), for first failure
 Repro found: flight 10271 (pass), for last pass
 Repro found: flight 10272 (fail), for first failure
 Repro found: flight 10273 (pass), for last pass
 Repro found: flight 10274 (fail), for first failure

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen http://xenbits.xen.org/staging/xen-unstable.hg
  Bug introduced:  72f4e4cb7440
  Bug not present: 109b99239b21

pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
searching for changes
no changes found

  changeset:   24344:72f4e4cb7440
  user:        Keir Fraser <keir@xen.org>
  date:        Fri Dec 02 06:31:14 2011 -0800
      
      tools/x86_64: Fix cpuid() inline asm to not clobber stack's red zone
      
      Pushing stuff onto the stack on x86-64 when we do not specify
      -mno-red-zone is unsafe. Since the complicated asm is due to register
      pressure on i386, we simply implement an all-new simpler alternative
      for x86-64.
      
      Signed-off-by: Keir Fraser <keir@xen.org>
      Acked-by: Jan Beulich <jbeulich@novell.com>
      
      

Revision graph left in /home/xc_osstest/results/bisect.xen-unstable.build-i386.xen-build.{dot,ps,png,html}.
----------------------------------------
10274: ALL FAIL

flight 10274 xen-unstable real-bisect [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10274/


jobs:
 build-i386                                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Dec 03 05:49:46 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 03 Dec 2011 05:49:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWiT7-0005rH-LO; Sat, 03 Dec 2011 05:49:01 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RWiT6-0005rC-IC
	for xen-devel@lists.xensource.com; Sat, 03 Dec 2011 05:49:00 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1322891297!4071453!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTkwMw==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21696 invoked from network); 3 Dec 2011 05:48:17 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Dec 2011 05:48:17 -0000
X-IronPort-AV: E=Sophos;i="4.71,288,1320624000"; 
   d="scan'208";a="9264504"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Dec 2011 05:48:16 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sat, 3 Dec 2011 05:48:16 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RWiSO-0007re-5l;
	Sat, 03 Dec 2011 05:48:16 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RWiSO-0000Jn-4c;
	Sat, 03 Dec 2011 05:48:16 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <E1RWiSO-0000Jn-4c@woking.xci-test.com>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 3 Dec 2011 05:48:16 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com, keir@xen.org, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [xen-unstable bisection] complete build-i386
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

branch xen-unstable
xen branch xen-unstable
job build-i386
test xen-build

Tree: qemu git://hg.uk.xensource.com/HG/qemu-xen-unstable.git
Tree: xen http://xenbits.xen.org/staging/xen-unstable.hg

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen http://xenbits.xen.org/staging/xen-unstable.hg
  Bug introduced:  72f4e4cb7440
  Bug not present: 109b99239b21


  changeset:   24344:72f4e4cb7440
  user:        Keir Fraser <keir@xen.org>
  date:        Fri Dec 02 06:31:14 2011 -0800
      
      tools/x86_64: Fix cpuid() inline asm to not clobber stack's red zone
      
      Pushing stuff onto the stack on x86-64 when we do not specify
      -mno-red-zone is unsafe. Since the complicated asm is due to register
      pressure on i386, we simply implement an all-new simpler alternative
      for x86-64.
      
      Signed-off-by: Keir Fraser <keir@xen.org>
      Acked-by: Jan Beulich <jbeulich@novell.com>
      
      


For bisection revision-tuple graph see:
   http://www.chiark.greenend.org.uk/~xensrcts/results/bisect.xen-unstable.build-i386.xen-build.html
Revision IDs in each graph node refer, respectively, to the Trees above.

----------------------------------------
Searching for failure / basis pass:
 10264 fail [host=itch-mite] / 10257 [host=woodlouse] 10246 [host=gall-mite] 10239 ok.
Failure / basis pass flights: 10264 / 10239
Tree: qemu git://hg.uk.xensource.com/HG/qemu-xen-unstable.git
Tree: xen http://xenbits.xen.org/staging/xen-unstable.hg
Latest 65b27b1dd6f205835aa8174031eea057c75f8afb a4d7c27ec1f1
Basis pass 65b27b1dd6f205835aa8174031eea057c75f8afb 60d4e257d04b
Generating revisions with ./adhoc-revtuple-generator  git://hg.uk.xensource.com/HG/qemu-xen-unstable.git#65b27b1dd6f205835aa8174031eea057c75f8afb-65b27b1dd6f205835aa8174031eea057c75f8afb http://xenbits.xen.org/staging/xen-unstable.hg#60d4e257d04b-a4d7c27ec1f1
pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
searching for changes
no changes found
pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
searching for changes
no changes found
Loaded 23 nodes in revision graph
Searching for test results:
 10244 fail 65b27b1dd6f205835aa8174031eea057c75f8afb 72f4e4cb7440
 10257 [host=woodlouse]
 10239 pass 65b27b1dd6f205835aa8174031eea057c75f8afb 60d4e257d04b
 10266 pass 65b27b1dd6f205835aa8174031eea057c75f8afb 60d4e257d04b
 10246 [host=gall-mite]
 10264 fail 65b27b1dd6f205835aa8174031eea057c75f8afb a4d7c27ec1f1
 10269 pass 65b27b1dd6f205835aa8174031eea057c75f8afb 109b99239b21
 10268 pass 65b27b1dd6f205835aa8174031eea057c75f8afb 771e2a303753
 10267 fail 65b27b1dd6f205835aa8174031eea057c75f8afb a4d7c27ec1f1
 10271 pass 65b27b1dd6f205835aa8174031eea057c75f8afb 109b99239b21
 10270 fail 65b27b1dd6f205835aa8174031eea057c75f8afb 72f4e4cb7440
 10272 fail 65b27b1dd6f205835aa8174031eea057c75f8afb 72f4e4cb7440
 10273 pass 65b27b1dd6f205835aa8174031eea057c75f8afb 109b99239b21
 10274 fail 65b27b1dd6f205835aa8174031eea057c75f8afb 72f4e4cb7440
Searching for interesting versions
 Result found: flight 10239 (pass), for basis pass
 Result found: flight 10264 (fail), for basis failure
 Repro found: flight 10266 (pass), for basis pass
 Repro found: flight 10267 (fail), for basis failure
 0 revisions at 65b27b1dd6f205835aa8174031eea057c75f8afb 109b99239b21
No revisions left to test, checking graph state.
 Result found: flight 10269 (pass), for last pass
 Result found: flight 10270 (fail), for first failure
 Repro found: flight 10271 (pass), for last pass
 Repro found: flight 10272 (fail), for first failure
 Repro found: flight 10273 (pass), for last pass
 Repro found: flight 10274 (fail), for first failure

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen http://xenbits.xen.org/staging/xen-unstable.hg
  Bug introduced:  72f4e4cb7440
  Bug not present: 109b99239b21

pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
searching for changes
no changes found

  changeset:   24344:72f4e4cb7440
  user:        Keir Fraser <keir@xen.org>
  date:        Fri Dec 02 06:31:14 2011 -0800
      
      tools/x86_64: Fix cpuid() inline asm to not clobber stack's red zone
      
      Pushing stuff onto the stack on x86-64 when we do not specify
      -mno-red-zone is unsafe. Since the complicated asm is due to register
      pressure on i386, we simply implement an all-new simpler alternative
      for x86-64.
      
      Signed-off-by: Keir Fraser <keir@xen.org>
      Acked-by: Jan Beulich <jbeulich@novell.com>
      
      

Revision graph left in /home/xc_osstest/results/bisect.xen-unstable.build-i386.xen-build.{dot,ps,png,html}.
----------------------------------------
10274: ALL FAIL

flight 10274 xen-unstable real-bisect [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10274/


jobs:
 build-i386                                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Dec 03 07:15:32 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 03 Dec 2011 07: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.xensource.com>)
	id 1RWjnA-0006RE-Hj; Sat, 03 Dec 2011 07:13:48 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@cs.ubc.ca>) id 1RWjn7-0006R9-SY
	for xen-devel@lists.xensource.com; Sat, 03 Dec 2011 07:13:46 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-7.tower-174.messagelabs.com!1322896379!4090046!1
X-Originating-IP: [142.103.6.52]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10896 invoked from network); 3 Dec 2011 07:13:01 -0000
Received: from smtp.cs.ubc.ca (HELO smtp.cs.ubc.ca) (142.103.6.52)
	by server-7.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Dec 2011 07:13:01 -0000
Received: from mail-bw0-f43.google.com (mail-bw0-f43.google.com
	[209.85.214.43]) (authenticated bits=0)
	by smtp.cs.ubc.ca (8.14.3/8.13.6) with ESMTP id pB37Ctur030543
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL)
	for <xen-devel@lists.xensource.com>; Fri, 2 Dec 2011 23:12:56 -0800
Received: by bkbzu17 with SMTP id zu17so8380492bkb.30
	for <xen-devel@lists.xensource.com>;
	Fri, 02 Dec 2011 23:12:53 -0800 (PST)
Received: by 10.205.132.146 with SMTP id hu18mr608977bkc.123.1322896373464;
	Fri, 02 Dec 2011 23:12:53 -0800 (PST)
MIME-Version: 1.0
Received: by 10.204.179.10 with HTTP; Fri, 2 Dec 2011 23:12:12 -0800 (PST)
In-Reply-To: <de5432066adc888a704b.1322836943@cosworth.uk.xensource.com>
References: <de5432066adc888a704b.1322836943@cosworth.uk.xensource.com>
From: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Date: Fri, 2 Dec 2011 23:12:12 -0800
Message-ID: <CAP8mzPPZr_SBkneoO9UzWQ30mHxn+GjrCaHKUYPxkg4WHjz-aA@mail.gmail.com>
To: Paul Durrant <paul.durrant@citrix.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] VM generation ID save/restore and migrate
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: rshriram@cs.ubc.ca
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============5984604066976982491=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============5984604066976982491==
Content-Type: multipart/alternative; boundary=000e0ce02ace6a457804b32ad04f

--000e0ce02ace6a457804b32ad04f
Content-Type: text/plain; charset=ISO-8859-1

On Fri, Dec 2, 2011 at 6:42 AM, Paul Durrant <paul.durrant@citrix.com>wrote:

> # HG changeset patch
> # User Paul Durrant <paul.durrant@citrix.com>
> # Date 1322836937 0
> # Node ID de5432066adc888a704bbbce9b18de3a60859cff
> # Parent  62ff6a318c5db7779fdbf4ddfdfc9506e86fa701
> VM generation ID save/restore and migrate.
>
> Add code to track the address of the VM generation id buffer across a
> save/restore or migrate and increment it as necessary.
> The address of the buffer is written into xenstore by hvmloader at
> boot time. It must be read from xenstore by the caller of
> xc_domain_save() and then written back again by the caller of
> xc_domain_restore().
>
> Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
>
> diff -r 62ff6a318c5d -r de5432066adc
> tools/libxc/ia64/xc_ia64_linux_restore.c
> --- a/tools/libxc/ia64/xc_ia64_linux_restore.c  Wed Nov 30 16:59:58 2011
> -0800
> +++ b/tools/libxc/ia64/xc_ia64_linux_restore.c  Fri Dec 02 14:42:17 2011
> +0000
> @@ -548,7 +548,8 @@ int
>  xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
>                   unsigned int store_evtchn, unsigned long *store_mfn,
>                   unsigned int console_evtchn, unsigned long *console_mfn,
> -                  unsigned int hvm, unsigned int pae, int superpages)
> +                  unsigned int hvm, unsigned int pae, int superpages,
> +                  int increment_gid, unsigned long *vm_gid_addr)
>  {
>     DECLARE_DOMCTL;
>     int rc = 1;
> diff -r 62ff6a318c5d -r de5432066adc tools/libxc/ia64/xc_ia64_linux_save.c
> --- a/tools/libxc/ia64/xc_ia64_linux_save.c     Wed Nov 30 16:59:58 2011
> -0800
> +++ b/tools/libxc/ia64/xc_ia64_linux_save.c     Fri Dec 02 14:42:17 2011
> +0000
> @@ -382,7 +382,8 @@ out:
>  int
>  xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t
> max_iters,
>                uint32_t max_factor, uint32_t flags,
> -               struct save_callbacks* callbacks, int hvm)
> +               struct save_callbacks* callbacks, int hvm,
> +               unsigned long vm_gid_addr)
>  {
>     DECLARE_DOMCTL;
>     xc_dominfo_t info;
> diff -r 62ff6a318c5d -r de5432066adc tools/libxc/xc_domain_restore.c
> --- a/tools/libxc/xc_domain_restore.c   Wed Nov 30 16:59:58 2011 -0800
> +++ b/tools/libxc/xc_domain_restore.c   Fri Dec 02 14:42:17 2011 +0000
> @@ -676,6 +676,7 @@ typedef struct {
>     uint64_t console_pfn;
>     uint64_t acpi_ioport_location;
>     uint64_t viridian;
> +    uint64_t vm_gid_addr;
>  } pagebuf_t;
>
>  static int pagebuf_init(pagebuf_t* buf)
> @@ -820,6 +821,17 @@ static int pagebuf_get_one(xc_interface
>         }
>         return pagebuf_get_one(xch, ctx, buf, fd, dom);
>
> +    case XC_SAVE_ID_HVM_GENERATION_ID_ADDR:
> +        /* Skip padding 4 bytes then read the generation id buffer
> location. */
> +        if ( RDEXACT(fd, &buf->vm_gid_addr, sizeof(uint32_t)) ||
> +             RDEXACT(fd, &buf->vm_gid_addr, sizeof(uint64_t)) )
> +        {
> +            PERROR("error read the generation id buffer location");
> +            return -1;
> +        }
> +        DPRINTF("read generation id buffer address");
> +        return pagebuf_get_one(xch, ctx, buf, fd, dom);
> +
>     default:
>         if ( (count > MAX_BATCH_SIZE) || (count < 0) ) {
>             ERROR("Max batch size exceeded (%d). Giving up.", count);
> @@ -1186,7 +1198,8 @@ static int apply_batch(xc_interface *xch
>  int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
>                       unsigned int store_evtchn, unsigned long *store_mfn,
>                       unsigned int console_evtchn, unsigned long
> *console_mfn,
> -                      unsigned int hvm, unsigned int pae, int superpages)
> +                      unsigned int hvm, unsigned int pae, int superpages,
> +                      int no_increment_gid, unsigned long *vm_gid_addr)
>  {
>     DECLARE_DOMCTL;
>     int rc = 1, frc, i, j, n, m, pae_extended_cr3 = 0, ext_vcpucontext = 0;
> @@ -1386,6 +1399,39 @@ int xc_domain_restore(xc_interface *xch,
>                 xc_set_hvm_param(xch, dom, HVM_PARAM_VM86_TSS,
> pagebuf.vm86_tss);
>             if ( pagebuf.console_pfn )
>                 console_pfn = pagebuf.console_pfn;
> +            if ( pagebuf.vm_gid_addr ) {
> +                if ( !no_increment_gid ) {
> +                    unsigned int offset;
> +                    unsigned char *buf;
> +                    unsigned long long gid;
> +
> +                    /*
> +                     * Map the VM generation id buffer and inject the new
> value.
> +                     */
> +
> +                    pfn = pagebuf.vm_gid_addr >> PAGE_SHIFT;
> +                    offset = pagebuf.vm_gid_addr & (PAGE_SIZE - 1);
> +
> +                    if ( (pfn >= dinfo->p2m_size) ||
> +                         (pfn_type[pfn] != XEN_DOMCTL_PFINFO_NOTAB) )
> +                    {
> +                        ERROR("generation id buffer frame is bad");
> +                        goto out;
> +                    }
> +
> +                    mfn = ctx->p2m[pfn];
> +                    buf = xc_map_foreign_range(xch, dom, PAGE_SIZE,
> +                                               PROT_READ | PROT_WRITE,
> mfn);
> +
> +                    gid = *(unsigned long long *)(buf + offset);
> +                    *(unsigned long long *)(buf + offset) = gid + 1;
> +
> +                    munmap(buf, PAGE_SIZE);
> +                }
> +
> +                *vm_gid_addr = pagebuf.vm_gid_addr;
> +            }
> +
>             break;  /* our work here is done */
>         }
>
> diff -r 62ff6a318c5d -r de5432066adc tools/libxc/xc_domain_save.c
> --- a/tools/libxc/xc_domain_save.c      Wed Nov 30 16:59:58 2011 -0800
> +++ b/tools/libxc/xc_domain_save.c      Fri Dec 02 14:42:17 2011 +0000
> @@ -754,7 +754,8 @@ static int save_tsc_info(xc_interface *x
>
>  int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t
> max_iters,
>                    uint32_t max_factor, uint32_t flags,
> -                   struct save_callbacks* callbacks, int hvm)
> +                   struct save_callbacks* callbacks, int hvm,
> +                   unsigned long vm_gid_addr)
>  {
>     xc_dominfo_t info;
>     DECLARE_DOMCTL;
> @@ -1460,6 +1461,16 @@ int xc_domain_save(xc_interface *xch, in
>             uint64_t data;
>         } chunk = { 0, };
>
> +        chunk.id = XC_SAVE_ID_HVM_GENERATION_ID_ADDR;
> +        chunk.data = vm_gid_addr;
> +
> +        if ( (chunk.data != 0) &&
> +             wrexact(io_fd, &chunk, sizeof(chunk)) )
> +        {
> +            PERROR("Error when writing the generation id buffer location
> for guest");
> +            goto out;
> +        }
> +
>         chunk.id = XC_SAVE_ID_HVM_IDENT_PT;
>         chunk.data = 0;
>         xc_get_hvm_param(xch, dom, HVM_PARAM_IDENT_PT,
> diff -r 62ff6a318c5d -r de5432066adc tools/libxc/xenguest.h
> --- a/tools/libxc/xenguest.h    Wed Nov 30 16:59:58 2011 -0800
> +++ b/tools/libxc/xenguest.h    Fri Dec 02 14:42:17 2011 +0000
> @@ -57,7 +57,8 @@ struct save_callbacks {
>  */
>  int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t
> max_iters,
>                    uint32_t max_factor, uint32_t flags /* XCFLAGS_xxx */,
> -                   struct save_callbacks* callbacks, int hvm);
> +                   struct save_callbacks* callbacks, int hvm,
> +                   unsigned long vm_gid_addr);
>
>
>  /**
> @@ -71,12 +72,15 @@ int xc_domain_save(xc_interface *xch, in
>  * @parm hvm non-zero if this is a HVM restore
>  * @parm pae non-zero if this HVM domain has PAE support enabled
>  * @parm superpages non-zero to allocate guest memory with superpages
> + * @parm gid the new generation id of the VM
> + * @parm vm_gid_addr returned with the address of the generation id buffer
>  * @return 0 on success, -1 on failure
>  */
>  int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
>                       unsigned int store_evtchn, unsigned long *store_mfn,
>                       unsigned int console_evtchn, unsigned long
> *console_mfn,
> -                      unsigned int hvm, unsigned int pae, int superpages);
> +                      unsigned int hvm, unsigned int pae, int superpages,
> +                      int increment_gid, unsigned long *vm_gid_addr);
>  /**
>  * xc_domain_restore writes a file to disk that contains the device
>  * model saved state.
> diff -r 62ff6a318c5d -r de5432066adc tools/libxc/xg_save_restore.h
> --- a/tools/libxc/xg_save_restore.h     Wed Nov 30 16:59:58 2011 -0800
> +++ b/tools/libxc/xg_save_restore.h     Fri Dec 02 14:42:17 2011 +0000
> @@ -135,6 +135,7 @@
>  #define XC_SAVE_ID_LAST_CHECKPOINT    -9 /* Commit to restoring after
> completion of current iteration. */
>  #define XC_SAVE_ID_HVM_ACPI_IOPORTS_LOCATION -10
>  #define XC_SAVE_ID_HVM_VIRIDIAN       -11
> +#define XC_SAVE_ID_HVM_GENERATION_ID_ADDR -12
>
>  /*
>  ** We process save/restore/migrate in batches of pages; the below
> diff -r 62ff6a318c5d -r de5432066adc tools/libxl/libxl_create.c
> --- a/tools/libxl/libxl_create.c        Wed Nov 30 16:59:58 2011 -0800
> +++ b/tools/libxl/libxl_create.c        Fri Dec 02 14:42:17 2011 +0000
> @@ -101,6 +101,7 @@ int libxl_init_build_info(libxl_ctx *ctx
>         b_info->u.hvm.vpt_align = 1;
>         b_info->u.hvm.timer_mode = 1;
>         b_info->u.hvm.nested_hvm = 0;
> +        b_info->u.hvm.no_increment_gid = 0;
>         break;
>     case LIBXL_DOMAIN_TYPE_PV:
>         b_info->u.pv.slack_memkb = 8 * 1024;
> diff -r 62ff6a318c5d -r de5432066adc tools/libxl/libxl_dom.c
> --- a/tools/libxl/libxl_dom.c   Wed Nov 30 16:59:58 2011 -0800
> +++ b/tools/libxl/libxl_dom.c   Fri Dec 02 14:42:17 2011 +0000
> @@ -125,7 +125,7 @@ int libxl__build_post(libxl__gc *gc, uin
>     if (info->cpuid != NULL)
>         libxl_cpuid_set(ctx, domid, info->cpuid);
>
> -    ents = libxl__calloc(gc, 12 + (info->max_vcpus * 2) + 2, sizeof(char
> *));
> +    ents = libxl__calloc(gc, 14 + (info->max_vcpus * 2) + 2, sizeof(char
> *));
>     ents[0] = "memory/static-max";
>     ents[1] = libxl__sprintf(gc, "%d", info->max_memkb);
>     ents[2] = "memory/target";
> @@ -138,9 +138,11 @@ int libxl__build_post(libxl__gc *gc, uin
>     ents[9] = libxl__sprintf(gc, "%"PRIu32, state->store_port);
>     ents[10] = "store/ring-ref";
>     ents[11] = libxl__sprintf(gc, "%lu", state->store_mfn);
> +    ents[12] = "data/generation-id";
> +    ents[13] = libxl__sprintf(gc, "0x%lx", state->vm_gid_addr);
>     for (i = 0; i < info->max_vcpus; i++) {
> -        ents[12+(i*2)]   = libxl__sprintf(gc, "cpu/%d/availability", i);
> -        ents[12+(i*2)+1] = (i && info->cur_vcpus && !(info->cur_vcpus &
> (1 << i)))
> +        ents[14+(i*2)]   = libxl__sprintf(gc, "cpu/%d/availability", i);
> +        ents[14+(i*2)+1] = (i && info->cur_vcpus && !(info->cur_vcpus &
> (1 << i)))
>                             ? "offline" : "online";
>     }
>
> @@ -357,16 +359,19 @@ int libxl__domain_restore_common(libxl__
>     /* read signature */
>     int rc;
>     int hvm, pae, superpages;
> +    int no_increment_gid;
>     switch (info->type) {
>     case LIBXL_DOMAIN_TYPE_HVM:
>         hvm = 1;
>         superpages = 1;
>         pae = info->u.hvm.pae;
> +        no_increment_gid = info->u.hvm.no_increment_gid;
>         break;
>     case LIBXL_DOMAIN_TYPE_PV:
>         hvm = 0;
>         superpages = 0;
>         pae = 1;
> +        no_increment_gid = 0;
>         break;
>     default:
>         return ERROR_INVAL;
> @@ -374,7 +379,7 @@ int libxl__domain_restore_common(libxl__
>     rc = xc_domain_restore(ctx->xch, fd, domid,
>                            state->store_port, &state->store_mfn,
>                            state->console_port, &state->console_mfn,
> -                           hvm, pae, superpages);
> +                           hvm, pae, superpages, no_increment_gid,
> &state->vm_gid_addr);
>     if ( rc ) {
>         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "restoring domain");
>         return ERROR_FAIL;
> @@ -540,12 +545,22 @@ int libxl__domain_suspend_common(libxl__
>     struct save_callbacks callbacks;
>     struct suspendinfo si;
>     int hvm, rc = ERROR_FAIL;
> +    unsigned long vm_gid_addr;
>
>     switch (type) {
> -    case LIBXL_DOMAIN_TYPE_HVM:
> +    case LIBXL_DOMAIN_TYPE_HVM: {
> +        char *path;
> +        char *addr;
> +
> +        path = libxl__sprintf(gc, "%s/data/generation-id",
> libxl__xs_get_dompath(gc, domid));
> +        addr = libxl__xs_read(gc, XBT_NULL, path);
> +
> +        vm_gid_addr = (addr) ? strtoul(addr, NULL, 0) : 0;
>         hvm = 1;
>         break;
> +    }
>     case LIBXL_DOMAIN_TYPE_PV:
> +        vm_gid_addr = 0;
>         hvm = 0;
>         break;
>     default:
> @@ -583,7 +598,8 @@ int libxl__domain_suspend_common(libxl__
>     callbacks.switch_qemu_logdirty =
> libxl__domain_suspend_common_switch_qemu_logdirty;
>     callbacks.data = &si;
>
> -    rc = xc_domain_save(ctx->xch, fd, domid, 0, 0, flags, &callbacks,
> hvm);
> +    rc = xc_domain_save(ctx->xch, fd, domid, 0, 0, flags, &callbacks,
> +                        hvm, vm_gid_addr);
>     if ( rc ) {
>         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "saving domain: %s",
>                          si.guest_responded ?
> diff -r 62ff6a318c5d -r de5432066adc tools/libxl/libxl_internal.h
> --- a/tools/libxl/libxl_internal.h      Wed Nov 30 16:59:58 2011 -0800
> +++ b/tools/libxl/libxl_internal.h      Fri Dec 02 14:42:17 2011 +0000
> @@ -199,6 +199,7 @@ typedef struct {
>
>     uint32_t console_port;
>     unsigned long console_mfn;
> +    unsigned long vm_gid_addr;
>  } libxl__domain_build_state;
>
>  _hidden int libxl__build_pre(libxl__gc *gc, uint32_t domid,
> diff -r 62ff6a318c5d -r de5432066adc tools/libxl/libxl_types.idl
> --- a/tools/libxl/libxl_types.idl       Wed Nov 30 16:59:58 2011 -0800
> +++ b/tools/libxl/libxl_types.idl       Fri Dec 02 14:42:17 2011 +0000
> @@ -183,6 +183,7 @@ libxl_domain_build_info = Struct("domain
>                                        ("vpt_align", bool),
>                                        ("timer_mode", integer),
>                                        ("nested_hvm", bool),
> +                                       ("no_increment_gid", bool),
>                                        ])),
>                  ("pv", Struct(None, [("kernel", libxl_file_reference),
>                                       ("slack_memkb", uint32),
> diff -r 62ff6a318c5d -r de5432066adc tools/libxl/xl_cmdimpl.c
> --- a/tools/libxl/xl_cmdimpl.c  Wed Nov 30 16:59:58 2011 -0800
> +++ b/tools/libxl/xl_cmdimpl.c  Fri Dec 02 14:42:17 2011 +0000
> @@ -360,6 +360,7 @@ static void printf_info(int domid,
>         printf("\t\t\t(vpt_align %d)\n", b_info->u.hvm.vpt_align);
>         printf("\t\t\t(timer_mode %d)\n", b_info->u.hvm.timer_mode);
>         printf("\t\t\t(nestedhvm %d)\n", b_info->u.hvm.nested_hvm);
> +        printf("\t\t\t(no_increment_gid %d)\n",
> b_info->u.hvm.no_increment_gid);
>
>         printf("\t\t\t(device_model %s)\n", dm_info->device_model ? :
> "default");
>         printf("\t\t\t(videoram %d)\n", dm_info->videoram);
> @@ -1362,6 +1363,7 @@ struct domain_create {
>     const char *restore_file;
>     int migrate_fd; /* -1 means none */
>     char **migration_domname_r; /* from malloc */
> +    int no_increment_gid;
>  };
>
>  static int freemem(libxl_domain_build_info *b_info,
> libxl_device_model_info *dm_info)
> @@ -1571,6 +1573,8 @@ static int create_domain(struct domain_c
>         }
>     }
>
> +    d_config.b_info.u.hvm.no_increment_gid = dom_info->no_increment_gid;
> +
>     if (debug || dom_info->dryrun)
>         printf_info(-1, &d_config, &d_config.dm_info);
>
> @@ -2796,6 +2800,7 @@ static void migrate_receive(int debug, i
>     dom_info.restore_file = "incoming migration stream";
>     dom_info.migrate_fd = 0; /* stdin */
>     dom_info.migration_domname_r = &migration_domname;
> +    dom_info.no_increment_gid = 1;
>
>     rc = create_domain(&dom_info);
>     if (rc < 0) {
> diff -r 62ff6a318c5d -r de5432066adc
> tools/python/xen/lowlevel/checkpoint/libcheckpoint.c
> --- a/tools/python/xen/lowlevel/checkpoint/libcheckpoint.c      Wed Nov 30
> 16:59:58 2011 -0800
> +++ b/tools/python/xen/lowlevel/checkpoint/libcheckpoint.c      Fri Dec 02
> 14:42:17 2011 +0000
> @@ -174,6 +174,7 @@ int checkpoint_start(checkpoint_state* s
>  {
>     int hvm, rc;
>     int flags = XCFLAGS_LIVE;
> +    unsigned long vm_gid_addr;
>
>     if (!s->domid) {
>        s->errstr = "checkpoint state not opened";
> @@ -184,14 +185,25 @@ int checkpoint_start(checkpoint_state* s
>
>     hvm = s->domtype > dt_pv;
>     if (hvm) {
> +       char path[128];
> +       char *addr;
> +
> +       sprintf(path, "/local/domain/%u/data/generation-id", s->domid);
> +       addr = xs_read(s->xsh, XBT_NULL, path, NULL);
> +
> +       vm_gid_addr = (addr) ? strtoul(addr, NULL, 0) : 0;
> +       free(addr);
> +
>        flags |= XCFLAGS_HVM;
>        if (switch_qemu_logdirty(s, 1))
>            return -1;
> +    } else {
> +       vm_gid_addr = 0;
>     }
>
>     callbacks->switch_qemu_logdirty = noop_switch_logdirty;
>
> -    rc = xc_domain_save(s->xch, fd, s->domid, 0, 0, flags, callbacks,
> hvm);
> +    rc = xc_domain_save(s->xch, fd, s->domid, 0, 0, flags, callbacks,
> hvm, vm_gid_addr);
>
>     if (hvm)
>        switch_qemu_logdirty(s, 0);
> diff -r 62ff6a318c5d -r de5432066adc tools/xcutils/xc_restore.c
> --- a/tools/xcutils/xc_restore.c        Wed Nov 30 16:59:58 2011 -0800
> +++ b/tools/xcutils/xc_restore.c        Fri Dec 02 14:42:17 2011 +0000
> @@ -23,7 +23,8 @@ main(int argc, char **argv)
>     xc_interface *xch;
>     int io_fd, ret;
>     int superpages;
> -    unsigned long store_mfn, console_mfn;
> +    unsigned long store_mfn, console_mfn, vm_gid_addr;
> +    int no_increment_gid;
>
>     if ( (argc != 8) && (argc != 9) )
>         errx(1, "usage: %s iofd domid store_evtchn "
> @@ -40,19 +41,25 @@ main(int argc, char **argv)
>     hvm  = atoi(argv[5]);
>     pae  = atoi(argv[6]);
>     apic = atoi(argv[7]);
> -    if ( argc == 9 )
> +    if ( argc >= 9 )
>            superpages = atoi(argv[8]);
>     else
>            superpages = !!hvm;
> +    if ( argc >= 10 )
> +           no_increment_gid = !atoi(argv[9]);
> +    else
> +           no_increment_gid = 0;
>
>     ret = xc_domain_restore(xch, io_fd, domid, store_evtchn, &store_mfn,
> -                            console_evtchn, &console_mfn, hvm, pae,
> superpages);
> +                            console_evtchn, &console_mfn, hvm, pae,
> superpages,
> +                            no_increment_gid, &vm_gid_addr);
>
>     if ( ret == 0 )
>     {
>        printf("store-mfn %li\n", store_mfn);
>         if ( !hvm )
>             printf("console-mfn %li\n", console_mfn);
> +       printf("vm-gid-addr %lx\n", vm_gid_addr);
>        fflush(stdout);
>     }
>
> diff -r 62ff6a318c5d -r de5432066adc tools/xcutils/xc_save.c
> --- a/tools/xcutils/xc_save.c   Wed Nov 30 16:59:58 2011 -0800
> +++ b/tools/xcutils/xc_save.c   Fri Dec 02 14:42:17 2011 +0000
> @@ -169,6 +169,10 @@ main(int argc, char **argv)
>     unsigned int maxit, max_f;
>     int io_fd, ret, port;
>     struct save_callbacks callbacks;
> +    char path[128];
> +    struct xs_handle *xs;
> +    char *addr;
> +    unsigned long vm_gid_addr;
>
>     if (argc != 6)
>         errx(1, "usage: %s iofd domid maxit maxf flags", argv[0]);
> @@ -207,8 +211,21 @@ main(int argc, char **argv)
>     memset(&callbacks, 0, sizeof(callbacks));
>     callbacks.suspend = suspend;
>     callbacks.switch_qemu_logdirty = switch_qemu_logdirty;
> +
> +    sprintf(path, "/local/domain/%d/data/generation-id", si.domid);
> +
> +    if ((xs = xs_daemon_open()) == NULL)
> +        errx(1, "Couldn't contact xenstore");
> +
> +    addr = xs_read(xs, XBT_NULL, path, NULL);
> +
> +    xs_daemon_close(xs);
> +
> +    vm_gid_addr = (addr) ? strtoul(addr, NULL, 0) : 0;
> +    free(addr);
> +
>     ret = xc_domain_save(si.xch, io_fd, si.domid, maxit, max_f, si.flags,
> -                         &callbacks, !!(si.flags & XCFLAGS_HVM));
> +                         &callbacks, !!(si.flags & XCFLAGS_HVM),
> vm_gid_addr);
>
>     if (si.suspend_evtchn > 0)
>         xc_suspend_evtchn_release(si.xch, si.xce, si.domid,
> si.suspend_evtchn);
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>

You might have to rebase the entire patch.
The compression patch (pushed into staging just before you sent this one)
touches the same diff context that this code does (esp. the SAVE_IDs,
code in xc_domain_restore, in
tools/python/xen/lowlevel/checkpoint/checkpoint.c, etc.)

Assuming that the latest regression in staging/xen-unstable is resolved, I
think
most of this code wont apply cleanly.

shriram

--000e0ce02ace6a457804b32ad04f
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote">On Fri, Dec 2, 2011 at 6:42 AM, Paul Durrant <sp=
an dir=3D"ltr">&lt;<a href=3D"mailto:paul.durrant@citrix.com">paul.durrant@=
citrix.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

# HG changeset patch<br>
# User Paul Durrant &lt;<a href=3D"mailto:paul.durrant@citrix.com">paul.dur=
rant@citrix.com</a>&gt;<br>
# Date 1322836937 0<br>
# Node ID de5432066adc888a704bbbce9b18de3a60859cff<br>
# Parent =A062ff6a318c5db7779fdbf4ddfdfc9506e86fa701<br>
VM generation ID save/restore and migrate.<br>
<br>
Add code to track the address of the VM generation id buffer across a<br>
save/restore or migrate and increment it as necessary.<br>
The address of the buffer is written into xenstore by hvmloader at<br>
boot time. It must be read from xenstore by the caller of<br>
xc_domain_save() and then written back again by the caller of<br>
xc_domain_restore().<br>
<br>
Signed-off-by: Paul Durrant &lt;<a href=3D"mailto:paul.durrant@citrix.com">=
paul.durrant@citrix.com</a>&gt;<br>
<br>
diff -r 62ff6a318c5d -r de5432066adc tools/libxc/ia64/xc_ia64_linux_restore=
.c<br>
--- a/tools/libxc/ia64/xc_ia64_linux_restore.c =A0Wed Nov 30 16:59:58 2011 =
-0800<br>
+++ b/tools/libxc/ia64/xc_ia64_linux_restore.c =A0Fri Dec 02 14:42:17 2011 =
+0000<br>
@@ -548,7 +548,8 @@ int<br>
=A0xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,<br>
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 unsigned int store_evtchn, unsigned lo=
ng *store_mfn,<br>
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 unsigned int console_evtchn, unsigned =
long *console_mfn,<br>
- =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0unsigned int hvm, unsigned int pae, in=
t superpages)<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0unsigned int hvm, unsigned int pae, in=
t superpages,<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0int increment_gid, unsigned long *vm_g=
id_addr)<br>
=A0{<br>
 =A0 =A0 DECLARE_DOMCTL;<br>
 =A0 =A0 int rc =3D 1;<br>
diff -r 62ff6a318c5d -r de5432066adc tools/libxc/ia64/xc_ia64_linux_save.c<=
br>
--- a/tools/libxc/ia64/xc_ia64_linux_save.c =A0 =A0 Wed Nov 30 16:59:58 201=
1 -0800<br>
+++ b/tools/libxc/ia64/xc_ia64_linux_save.c =A0 =A0 Fri Dec 02 14:42:17 201=
1 +0000<br>
@@ -382,7 +382,8 @@ out:<br>
=A0int<br>
=A0xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_=
iters,<br>
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0uint32_t max_factor, uint32_t flags,<br>
- =A0 =A0 =A0 =A0 =A0 =A0 =A0 struct save_callbacks* callbacks, int hvm)<br=
>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 struct save_callbacks* callbacks, int hvm,<br=
>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 unsigned long vm_gid_addr)<br>
=A0{<br>
 =A0 =A0 DECLARE_DOMCTL;<br>
 =A0 =A0 xc_dominfo_t info;<br>
diff -r 62ff6a318c5d -r de5432066adc tools/libxc/xc_domain_restore.c<br>
--- a/tools/libxc/xc_domain_restore.c =A0 Wed Nov 30 16:59:58 2011 -0800<br=
>
+++ b/tools/libxc/xc_domain_restore.c =A0 Fri Dec 02 14:42:17 2011 +0000<br=
>
@@ -676,6 +676,7 @@ typedef struct {<br>
 =A0 =A0 uint64_t console_pfn;<br>
 =A0 =A0 uint64_t acpi_ioport_location;<br>
 =A0 =A0 uint64_t viridian;<br>
+ =A0 =A0uint64_t vm_gid_addr;<br>
=A0} pagebuf_t;<br>
<br>
=A0static int pagebuf_init(pagebuf_t* buf)<br>
@@ -820,6 +821,17 @@ static int pagebuf_get_one(xc_interface<br>
 =A0 =A0 =A0 =A0 }<br>
 =A0 =A0 =A0 =A0 return pagebuf_get_one(xch, ctx, buf, fd, dom);<br>
<br>
+ =A0 =A0case XC_SAVE_ID_HVM_GENERATION_ID_ADDR:<br>
+ =A0 =A0 =A0 =A0/* Skip padding 4 bytes then read the generation id buffer=
 location. */<br>
+ =A0 =A0 =A0 =A0if ( RDEXACT(fd, &amp;buf-&gt;vm_gid_addr, sizeof(uint32_t=
)) ||<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 RDEXACT(fd, &amp;buf-&gt;vm_gid_addr, sizeof(uint=
64_t)) )<br>
+ =A0 =A0 =A0 =A0{<br>
+ =A0 =A0 =A0 =A0 =A0 =A0PERROR(&quot;error read the generation id buffer l=
ocation&quot;);<br>
+ =A0 =A0 =A0 =A0 =A0 =A0return -1;<br>
+ =A0 =A0 =A0 =A0}<br>
+ =A0 =A0 =A0 =A0DPRINTF(&quot;read generation id buffer address&quot;);<br=
>
+ =A0 =A0 =A0 =A0return pagebuf_get_one(xch, ctx, buf, fd, dom);<br>
+<br>
 =A0 =A0 default:<br>
 =A0 =A0 =A0 =A0 if ( (count &gt; MAX_BATCH_SIZE) || (count &lt; 0) ) {<br>
 =A0 =A0 =A0 =A0 =A0 =A0 ERROR(&quot;Max batch size exceeded (%d). Giving u=
p.&quot;, count);<br>
@@ -1186,7 +1198,8 @@ static int apply_batch(xc_interface *xch<br>
=A0int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,<br>
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 unsigned int store_evtchn, uns=
igned long *store_mfn,<br>
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 unsigned int console_evtchn, u=
nsigned long *console_mfn,<br>
- =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0unsigned int hvm, unsigned int=
 pae, int superpages)<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0unsigned int hvm, unsigned int=
 pae, int superpages,<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0int no_increment_gid, unsigned=
 long *vm_gid_addr)<br>
=A0{<br>
 =A0 =A0 DECLARE_DOMCTL;<br>
 =A0 =A0 int rc =3D 1, frc, i, j, n, m, pae_extended_cr3 =3D 0, ext_vcpucon=
text =3D 0;<br>
@@ -1386,6 +1399,39 @@ int xc_domain_restore(xc_interface *xch,<br>
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 xc_set_hvm_param(xch, dom, HVM_PARAM_VM86_=
TSS, pagebuf.vm86_tss);<br>
 =A0 =A0 =A0 =A0 =A0 =A0 if ( pagebuf.console_pfn )<br>
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 console_pfn =3D pagebuf.console_pfn;<br>
+ =A0 =A0 =A0 =A0 =A0 =A0if ( pagebuf.vm_gid_addr ) {<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if ( !no_increment_gid ) {<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0unsigned int offset;<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0unsigned char *buf;<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0unsigned long long gid;<br>
+<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/*<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 * Map the VM generation id buffer=
 and inject the new value.<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 */<br>
+<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0pfn =3D pagebuf.vm_gid_addr &gt;&g=
t; PAGE_SHIFT;<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0offset =3D pagebuf.vm_gid_addr &am=
p; (PAGE_SIZE - 1);<br>
+<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if ( (pfn &gt;=3D dinfo-&gt;p2m_si=
ze) ||<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (pfn_type[pfn] !=3D XEN_D=
OMCTL_PFINFO_NOTAB) )<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0{<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ERROR(&quot;generation id =
buffer frame is bad&quot;);<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0goto out;<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0}<br>
+<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0mfn =3D ctx-&gt;p2m[pfn];<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0buf =3D xc_map_foreign_range(xch, =
dom, PAGE_SIZE,<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 PROT_READ | PROT_WRITE, mfn);<br>
+<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0gid =3D *(unsigned long long *)(bu=
f + offset);<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0*(unsigned long long *)(buf + offs=
et) =3D gid + 1;<br>
+<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0munmap(buf, PAGE_SIZE);<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0}<br>
+<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0*vm_gid_addr =3D pagebuf.vm_gid_addr;<br>
+ =A0 =A0 =A0 =A0 =A0 =A0}<br>
+<br>
 =A0 =A0 =A0 =A0 =A0 =A0 break; =A0/* our work here is done */<br>
 =A0 =A0 =A0 =A0 }<br>
<br>
diff -r 62ff6a318c5d -r de5432066adc tools/libxc/xc_domain_save.c<br>
--- a/tools/libxc/xc_domain_save.c =A0 =A0 =A0Wed Nov 30 16:59:58 2011 -080=
0<br>
+++ b/tools/libxc/xc_domain_save.c =A0 =A0 =A0Fri Dec 02 14:42:17 2011 +000=
0<br>
@@ -754,7 +754,8 @@ static int save_tsc_info(xc_interface *x<br>
<br>
=A0int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t =
max_iters,<br>
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0uint32_t max_factor, uint32_t flags=
,<br>
- =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 struct save_callbacks* callbacks, int=
 hvm)<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 struct save_callbacks* callbacks, int=
 hvm,<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 unsigned long vm_gid_addr)<br>
=A0{<br>
 =A0 =A0 xc_dominfo_t info;<br>
 =A0 =A0 DECLARE_DOMCTL;<br>
@@ -1460,6 +1461,16 @@ int xc_domain_save(xc_interface *xch, in<br>
 =A0 =A0 =A0 =A0 =A0 =A0 uint64_t data;<br>
 =A0 =A0 =A0 =A0 } chunk =3D { 0, };<br>
<br>
+ =A0 =A0 =A0 =A0<a href=3D"http://chunk.id" target=3D"_blank">chunk.id</a>=
 =3D XC_SAVE_ID_HVM_GENERATION_ID_ADDR;<br>
+ =A0 =A0 =A0 =A0chunk.data =3D vm_gid_addr;<br>
+<br>
+ =A0 =A0 =A0 =A0if ( (chunk.data !=3D 0) &amp;&amp;<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 wrexact(io_fd, &amp;chunk, sizeof(chunk)) )<br>
+ =A0 =A0 =A0 =A0{<br>
+ =A0 =A0 =A0 =A0 =A0 =A0PERROR(&quot;Error when writing the generation id =
buffer location for guest&quot;);<br>
+ =A0 =A0 =A0 =A0 =A0 =A0goto out;<br>
+ =A0 =A0 =A0 =A0}<br>
+<br>
 =A0 =A0 =A0 =A0 <a href=3D"http://chunk.id" target=3D"_blank">chunk.id</a>=
 =3D XC_SAVE_ID_HVM_IDENT_PT;<br>
 =A0 =A0 =A0 =A0 chunk.data =3D 0;<br>
 =A0 =A0 =A0 =A0 xc_get_hvm_param(xch, dom, HVM_PARAM_IDENT_PT,<br>
diff -r 62ff6a318c5d -r de5432066adc tools/libxc/xenguest.h<br>
--- a/tools/libxc/xenguest.h =A0 =A0Wed Nov 30 16:59:58 2011 -0800<br>
+++ b/tools/libxc/xenguest.h =A0 =A0Fri Dec 02 14:42:17 2011 +0000<br>
@@ -57,7 +57,8 @@ struct save_callbacks {<br>
 =A0*/<br>
=A0int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t =
max_iters,<br>
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0uint32_t max_factor, uint32_t flags=
 /* XCFLAGS_xxx */,<br>
- =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 struct save_callbacks* callbacks, int=
 hvm);<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 struct save_callbacks* callbacks, int=
 hvm,<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 unsigned long vm_gid_addr);<br>
<br>
<br>
=A0/**<br>
@@ -71,12 +72,15 @@ int xc_domain_save(xc_interface *xch, in<br>
 =A0* @parm hvm non-zero if this is a HVM restore<br>
 =A0* @parm pae non-zero if this HVM domain has PAE support enabled<br>
 =A0* @parm superpages non-zero to allocate guest memory with superpages<br=
>
+ * @parm gid the new generation id of the VM<br>
+ * @parm vm_gid_addr returned with the address of the generation id buffer=
<br>
 =A0* @return 0 on success, -1 on failure<br>
 =A0*/<br>
=A0int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,<br>
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 unsigned int store_evtchn, uns=
igned long *store_mfn,<br>
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 unsigned int console_evtchn, u=
nsigned long *console_mfn,<br>
- =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0unsigned int hvm, unsigned int=
 pae, int superpages);<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0unsigned int hvm, unsigned int=
 pae, int superpages,<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0int increment_gid, unsigned lo=
ng *vm_gid_addr);<br>
=A0/**<br>
 =A0* xc_domain_restore writes a file to disk that contains the device<br>
 =A0* model saved state.<br>
diff -r 62ff6a318c5d -r de5432066adc tools/libxc/xg_save_restore.h<br>
--- a/tools/libxc/xg_save_restore.h =A0 =A0 Wed Nov 30 16:59:58 2011 -0800<=
br>
+++ b/tools/libxc/xg_save_restore.h =A0 =A0 Fri Dec 02 14:42:17 2011 +0000<=
br>
@@ -135,6 +135,7 @@<br>
=A0#define XC_SAVE_ID_LAST_CHECKPOINT =A0 =A0-9 /* Commit to restoring afte=
r completion of current iteration. */<br>
=A0#define XC_SAVE_ID_HVM_ACPI_IOPORTS_LOCATION -10<br>
=A0#define XC_SAVE_ID_HVM_VIRIDIAN =A0 =A0 =A0 -11<br>
+#define XC_SAVE_ID_HVM_GENERATION_ID_ADDR -12<br>
<br>
=A0/*<br>
=A0** We process save/restore/migrate in batches of pages; the below<br>
diff -r 62ff6a318c5d -r de5432066adc tools/libxl/libxl_create.c<br>
--- a/tools/libxl/libxl_create.c =A0 =A0 =A0 =A0Wed Nov 30 16:59:58 2011 -0=
800<br>
+++ b/tools/libxl/libxl_create.c =A0 =A0 =A0 =A0Fri Dec 02 14:42:17 2011 +0=
000<br>
@@ -101,6 +101,7 @@ int libxl_init_build_info(libxl_ctx *ctx<br>
 =A0 =A0 =A0 =A0 b_info-&gt;u.hvm.vpt_align =3D 1;<br>
 =A0 =A0 =A0 =A0 b_info-&gt;u.hvm.timer_mode =3D 1;<br>
 =A0 =A0 =A0 =A0 b_info-&gt;u.hvm.nested_hvm =3D 0;<br>
+ =A0 =A0 =A0 =A0b_info-&gt;u.hvm.no_increment_gid =3D 0;<br>
 =A0 =A0 =A0 =A0 break;<br>
 =A0 =A0 case LIBXL_DOMAIN_TYPE_PV:<br>
 =A0 =A0 =A0 =A0 b_info-&gt;u.pv.slack_memkb =3D 8 * 1024;<br>
diff -r 62ff6a318c5d -r de5432066adc tools/libxl/libxl_dom.c<br>
--- a/tools/libxl/libxl_dom.c =A0 Wed Nov 30 16:59:58 2011 -0800<br>
+++ b/tools/libxl/libxl_dom.c =A0 Fri Dec 02 14:42:17 2011 +0000<br>
@@ -125,7 +125,7 @@ int libxl__build_post(libxl__gc *gc, uin<br>
 =A0 =A0 if (info-&gt;cpuid !=3D NULL)<br>
 =A0 =A0 =A0 =A0 libxl_cpuid_set(ctx, domid, info-&gt;cpuid);<br>
<br>
- =A0 =A0ents =3D libxl__calloc(gc, 12 + (info-&gt;max_vcpus * 2) + 2, size=
of(char *));<br>
+ =A0 =A0ents =3D libxl__calloc(gc, 14 + (info-&gt;max_vcpus * 2) + 2, size=
of(char *));<br>
 =A0 =A0 ents[0] =3D &quot;memory/static-max&quot;;<br>
 =A0 =A0 ents[1] =3D libxl__sprintf(gc, &quot;%d&quot;, info-&gt;max_memkb)=
;<br>
 =A0 =A0 ents[2] =3D &quot;memory/target&quot;;<br>
@@ -138,9 +138,11 @@ int libxl__build_post(libxl__gc *gc, uin<br>
 =A0 =A0 ents[9] =3D libxl__sprintf(gc, &quot;%&quot;PRIu32, state-&gt;stor=
e_port);<br>
 =A0 =A0 ents[10] =3D &quot;store/ring-ref&quot;;<br>
 =A0 =A0 ents[11] =3D libxl__sprintf(gc, &quot;%lu&quot;, state-&gt;store_m=
fn);<br>
+ =A0 =A0ents[12] =3D &quot;data/generation-id&quot;;<br>
+ =A0 =A0ents[13] =3D libxl__sprintf(gc, &quot;0x%lx&quot;, state-&gt;vm_gi=
d_addr);<br>
 =A0 =A0 for (i =3D 0; i &lt; info-&gt;max_vcpus; i++) {<br>
- =A0 =A0 =A0 =A0ents[12+(i*2)] =A0 =3D libxl__sprintf(gc, &quot;cpu/%d/ava=
ilability&quot;, i);<br>
- =A0 =A0 =A0 =A0ents[12+(i*2)+1] =3D (i &amp;&amp; info-&gt;cur_vcpus &amp=
;&amp; !(info-&gt;cur_vcpus &amp; (1 &lt;&lt; i)))<br>
+ =A0 =A0 =A0 =A0ents[14+(i*2)] =A0 =3D libxl__sprintf(gc, &quot;cpu/%d/ava=
ilability&quot;, i);<br>
+ =A0 =A0 =A0 =A0ents[14+(i*2)+1] =3D (i &amp;&amp; info-&gt;cur_vcpus &amp=
;&amp; !(info-&gt;cur_vcpus &amp; (1 &lt;&lt; i)))<br>
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ? &quot;offline&qu=
ot; : &quot;online&quot;;<br>
 =A0 =A0 }<br>
<br>
@@ -357,16 +359,19 @@ int libxl__domain_restore_common(libxl__<br>
 =A0 =A0 /* read signature */<br>
 =A0 =A0 int rc;<br>
 =A0 =A0 int hvm, pae, superpages;<br>
+ =A0 =A0int no_increment_gid;<br>
 =A0 =A0 switch (info-&gt;type) {<br>
 =A0 =A0 case LIBXL_DOMAIN_TYPE_HVM:<br>
 =A0 =A0 =A0 =A0 hvm =3D 1;<br>
 =A0 =A0 =A0 =A0 superpages =3D 1;<br>
 =A0 =A0 =A0 =A0 pae =3D info-&gt;u.hvm.pae;<br>
+ =A0 =A0 =A0 =A0no_increment_gid =3D info-&gt;u.hvm.no_increment_gid;<br>
 =A0 =A0 =A0 =A0 break;<br>
 =A0 =A0 case LIBXL_DOMAIN_TYPE_PV:<br>
 =A0 =A0 =A0 =A0 hvm =3D 0;<br>
 =A0 =A0 =A0 =A0 superpages =3D 0;<br>
 =A0 =A0 =A0 =A0 pae =3D 1;<br>
+ =A0 =A0 =A0 =A0no_increment_gid =3D 0;<br>
 =A0 =A0 =A0 =A0 break;<br>
 =A0 =A0 default:<br>
 =A0 =A0 =A0 =A0 return ERROR_INVAL;<br>
@@ -374,7 +379,7 @@ int libxl__domain_restore_common(libxl__<br>
 =A0 =A0 rc =3D xc_domain_restore(ctx-&gt;xch, fd, domid,<br>
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0state-&gt;store_por=
t, &amp;state-&gt;store_mfn,<br>
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0state-&gt;console_p=
ort, &amp;state-&gt;console_mfn,<br>
- =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 hvm, pae, superpages)=
;<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 hvm, pae, superpages,=
 no_increment_gid, &amp;state-&gt;vm_gid_addr);<br>
 =A0 =A0 if ( rc ) {<br>
 =A0 =A0 =A0 =A0 LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, &quot;restoring do=
main&quot;);<br>
 =A0 =A0 =A0 =A0 return ERROR_FAIL;<br>
@@ -540,12 +545,22 @@ int libxl__domain_suspend_common(libxl__<br>
 =A0 =A0 struct save_callbacks callbacks;<br>
 =A0 =A0 struct suspendinfo si;<br>
 =A0 =A0 int hvm, rc =3D ERROR_FAIL;<br>
+ =A0 =A0unsigned long vm_gid_addr;<br>
<br>
 =A0 =A0 switch (type) {<br>
- =A0 =A0case LIBXL_DOMAIN_TYPE_HVM:<br>
+ =A0 =A0case LIBXL_DOMAIN_TYPE_HVM: {<br>
+ =A0 =A0 =A0 =A0char *path;<br>
+ =A0 =A0 =A0 =A0char *addr;<br>
+<br>
+ =A0 =A0 =A0 =A0path =3D libxl__sprintf(gc, &quot;%s/data/generation-id&qu=
ot;, libxl__xs_get_dompath(gc, domid));<br>
+ =A0 =A0 =A0 =A0addr =3D libxl__xs_read(gc, XBT_NULL, path);<br>
+<br>
+ =A0 =A0 =A0 =A0vm_gid_addr =3D (addr) ? strtoul(addr, NULL, 0) : 0;<br>
 =A0 =A0 =A0 =A0 hvm =3D 1;<br>
 =A0 =A0 =A0 =A0 break;<br>
+ =A0 =A0}<br>
 =A0 =A0 case LIBXL_DOMAIN_TYPE_PV:<br>
+ =A0 =A0 =A0 =A0vm_gid_addr =3D 0;<br>
 =A0 =A0 =A0 =A0 hvm =3D 0;<br>
 =A0 =A0 =A0 =A0 break;<br>
 =A0 =A0 default:<br>
@@ -583,7 +598,8 @@ int libxl__domain_suspend_common(libxl__<br>
 =A0 =A0 callbacks.switch_qemu_logdirty =3D libxl__domain_suspend_common_sw=
itch_qemu_logdirty;<br>
 =A0 =A0 callbacks.data =3D &amp;si;<br>
<br>
- =A0 =A0rc =3D xc_domain_save(ctx-&gt;xch, fd, domid, 0, 0, flags, &amp;ca=
llbacks, hvm);<br>
+ =A0 =A0rc =3D xc_domain_save(ctx-&gt;xch, fd, domid, 0, 0, flags, &amp;ca=
llbacks,<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0hvm, vm_gid_addr);<br>
 =A0 =A0 if ( rc ) {<br>
 =A0 =A0 =A0 =A0 LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, &quot;saving domai=
n: %s&quot;,<br>
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0si.guest_responded ?<br=
>
diff -r 62ff6a318c5d -r de5432066adc tools/libxl/libxl_internal.h<br>
--- a/tools/libxl/libxl_internal.h =A0 =A0 =A0Wed Nov 30 16:59:58 2011 -080=
0<br>
+++ b/tools/libxl/libxl_internal.h =A0 =A0 =A0Fri Dec 02 14:42:17 2011 +000=
0<br>
@@ -199,6 +199,7 @@ typedef struct {<br>
<br>
 =A0 =A0 uint32_t console_port;<br>
 =A0 =A0 unsigned long console_mfn;<br>
+ =A0 =A0unsigned long vm_gid_addr;<br>
=A0} libxl__domain_build_state;<br>
<br>
=A0_hidden int libxl__build_pre(libxl__gc *gc, uint32_t domid,<br>
diff -r 62ff6a318c5d -r de5432066adc tools/libxl/libxl_types.idl<br>
--- a/tools/libxl/libxl_types.idl =A0 =A0 =A0 Wed Nov 30 16:59:58 2011 -080=
0<br>
+++ b/tools/libxl/libxl_types.idl =A0 =A0 =A0 Fri Dec 02 14:42:17 2011 +000=
0<br>
@@ -183,6 +183,7 @@ libxl_domain_build_info =3D Struct(&quot;domain<br>
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0(&quot;vpt_align&quot;, bool),<br>
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0(&quot;timer_mode&quot;, integer),<br>
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0(&quot;nested_hvm&quot;, bool),<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 (&quot;no_increment_gid&quot;, bool),<br>
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0])),<br>
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(&quot;pv&quot;, Struct(None, [(&quot;k=
ernel&quot;, libxl_file_reference),<br>
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 (&quot;slack_memkb&quot;, uint32),<br>
diff -r 62ff6a318c5d -r de5432066adc tools/libxl/xl_cmdimpl.c<br>
--- a/tools/libxl/xl_cmdimpl.c =A0Wed Nov 30 16:59:58 2011 -0800<br>
+++ b/tools/libxl/xl_cmdimpl.c =A0Fri Dec 02 14:42:17 2011 +0000<br>
@@ -360,6 +360,7 @@ static void printf_info(int domid,<br>
 =A0 =A0 =A0 =A0 printf(&quot;\t\t\t(vpt_align %d)\n&quot;, b_info-&gt;u.hv=
m.vpt_align);<br>
 =A0 =A0 =A0 =A0 printf(&quot;\t\t\t(timer_mode %d)\n&quot;, b_info-&gt;u.h=
vm.timer_mode);<br>
 =A0 =A0 =A0 =A0 printf(&quot;\t\t\t(nestedhvm %d)\n&quot;, b_info-&gt;u.hv=
m.nested_hvm);<br>
+ =A0 =A0 =A0 =A0printf(&quot;\t\t\t(no_increment_gid %d)\n&quot;, b_info-&=
gt;u.hvm.no_increment_gid);<br>
<br>
 =A0 =A0 =A0 =A0 printf(&quot;\t\t\t(device_model %s)\n&quot;, dm_info-&gt;=
device_model ? : &quot;default&quot;);<br>
 =A0 =A0 =A0 =A0 printf(&quot;\t\t\t(videoram %d)\n&quot;, dm_info-&gt;vide=
oram);<br>
@@ -1362,6 +1363,7 @@ struct domain_create {<br>
 =A0 =A0 const char *restore_file;<br>
 =A0 =A0 int migrate_fd; /* -1 means none */<br>
 =A0 =A0 char **migration_domname_r; /* from malloc */<br>
+ =A0 =A0int no_increment_gid;<br>
=A0};<br>
<br>
=A0static int freemem(libxl_domain_build_info *b_info, libxl_device_model_i=
nfo *dm_info)<br>
@@ -1571,6 +1573,8 @@ static int create_domain(struct domain_c<br>
 =A0 =A0 =A0 =A0 }<br>
 =A0 =A0 }<br>
<br>
+ =A0 =A0d_config.b_info.u.hvm.no_increment_gid =3D dom_info-&gt;no_increme=
nt_gid;<br>
+<br>
 =A0 =A0 if (debug || dom_info-&gt;dryrun)<br>
 =A0 =A0 =A0 =A0 printf_info(-1, &amp;d_config, &amp;d_config.dm_info);<br>
<br>
@@ -2796,6 +2800,7 @@ static void migrate_receive(int debug, i<br>
 =A0 =A0 dom_info.restore_file =3D &quot;incoming migration stream&quot;;<b=
r>
 =A0 =A0 dom_info.migrate_fd =3D 0; /* stdin */<br>
 =A0 =A0 dom_info.migration_domname_r =3D &amp;migration_domname;<br>
+ =A0 =A0dom_info.no_increment_gid =3D 1;<br>
<br>
 =A0 =A0 rc =3D create_domain(&amp;dom_info);<br>
 =A0 =A0 if (rc &lt; 0) {<br>
diff -r 62ff6a318c5d -r de5432066adc tools/python/xen/lowlevel/checkpoint/l=
ibcheckpoint.c<br>
--- a/tools/python/xen/lowlevel/checkpoint/libcheckpoint.c =A0 =A0 =A0Wed N=
ov 30 16:59:58 2011 -0800<br>
+++ b/tools/python/xen/lowlevel/checkpoint/libcheckpoint.c =A0 =A0 =A0Fri D=
ec 02 14:42:17 2011 +0000<br>
@@ -174,6 +174,7 @@ int checkpoint_start(checkpoint_state* s<br>
=A0{<br>
 =A0 =A0 int hvm, rc;<br>
 =A0 =A0 int flags =3D XCFLAGS_LIVE;<br>
+ =A0 =A0unsigned long vm_gid_addr;<br>
<br>
 =A0 =A0 if (!s-&gt;domid) {<br>
 =A0 =A0 =A0 =A0s-&gt;errstr =3D &quot;checkpoint state not opened&quot;;<b=
r>
@@ -184,14 +185,25 @@ int checkpoint_start(checkpoint_state* s<br>
<br>
 =A0 =A0 hvm =3D s-&gt;domtype &gt; dt_pv;<br>
 =A0 =A0 if (hvm) {<br>
+ =A0 =A0 =A0 char path[128];<br>
+ =A0 =A0 =A0 char *addr;<br>
+<br>
+ =A0 =A0 =A0 sprintf(path, &quot;/local/domain/%u/data/generation-id&quot;=
, s-&gt;domid);<br>
+ =A0 =A0 =A0 addr =3D xs_read(s-&gt;xsh, XBT_NULL, path, NULL);<br>
+<br>
+ =A0 =A0 =A0 vm_gid_addr =3D (addr) ? strtoul(addr, NULL, 0) : 0;<br>
+ =A0 =A0 =A0 free(addr);<br>
+<br>
 =A0 =A0 =A0 =A0flags |=3D XCFLAGS_HVM;<br>
 =A0 =A0 =A0 =A0if (switch_qemu_logdirty(s, 1))<br>
 =A0 =A0 =A0 =A0 =A0 =A0return -1;<br>
+ =A0 =A0} else {<br>
+ =A0 =A0 =A0 vm_gid_addr =3D 0;<br>
 =A0 =A0 }<br>
<br>
 =A0 =A0 callbacks-&gt;switch_qemu_logdirty =3D noop_switch_logdirty;<br>
<br>
- =A0 =A0rc =3D xc_domain_save(s-&gt;xch, fd, s-&gt;domid, 0, 0, flags, cal=
lbacks, hvm);<br>
+ =A0 =A0rc =3D xc_domain_save(s-&gt;xch, fd, s-&gt;domid, 0, 0, flags, cal=
lbacks, hvm, vm_gid_addr);<br>
<br>
 =A0 =A0 if (hvm)<br>
 =A0 =A0 =A0 =A0switch_qemu_logdirty(s, 0);<br>
diff -r 62ff6a318c5d -r de5432066adc tools/xcutils/xc_restore.c<br>
--- a/tools/xcutils/xc_restore.c =A0 =A0 =A0 =A0Wed Nov 30 16:59:58 2011 -0=
800<br>
+++ b/tools/xcutils/xc_restore.c =A0 =A0 =A0 =A0Fri Dec 02 14:42:17 2011 +0=
000<br>
@@ -23,7 +23,8 @@ main(int argc, char **argv)<br>
 =A0 =A0 xc_interface *xch;<br>
 =A0 =A0 int io_fd, ret;<br>
 =A0 =A0 int superpages;<br>
- =A0 =A0unsigned long store_mfn, console_mfn;<br>
+ =A0 =A0unsigned long store_mfn, console_mfn, vm_gid_addr;<br>
+ =A0 =A0int no_increment_gid;<br>
<br>
 =A0 =A0 if ( (argc !=3D 8) &amp;&amp; (argc !=3D 9) )<br>
 =A0 =A0 =A0 =A0 errx(1, &quot;usage: %s iofd domid store_evtchn &quot;<br>
@@ -40,19 +41,25 @@ main(int argc, char **argv)<br>
 =A0 =A0 hvm =A0=3D atoi(argv[5]);<br>
 =A0 =A0 pae =A0=3D atoi(argv[6]);<br>
 =A0 =A0 apic =3D atoi(argv[7]);<br>
- =A0 =A0if ( argc =3D=3D 9 )<br>
+ =A0 =A0if ( argc &gt;=3D 9 )<br>
 =A0 =A0 =A0 =A0 =A0 =A0superpages =3D atoi(argv[8]);<br>
 =A0 =A0 else<br>
 =A0 =A0 =A0 =A0 =A0 =A0superpages =3D !!hvm;<br>
+ =A0 =A0if ( argc &gt;=3D 10 )<br>
+ =A0 =A0 =A0 =A0 =A0 no_increment_gid =3D !atoi(argv[9]);<br>
+ =A0 =A0else<br>
+ =A0 =A0 =A0 =A0 =A0 no_increment_gid =3D 0;<br>
<br>
 =A0 =A0 ret =3D xc_domain_restore(xch, io_fd, domid, store_evtchn, &amp;st=
ore_mfn,<br>
- =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0console_evtchn, &a=
mp;console_mfn, hvm, pae, superpages);<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0console_evtchn, &a=
mp;console_mfn, hvm, pae, superpages,<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0no_increment_gid, =
&amp;vm_gid_addr);<br>
<br>
 =A0 =A0 if ( ret =3D=3D 0 )<br>
 =A0 =A0 {<br>
 =A0 =A0 =A0 =A0printf(&quot;store-mfn %li\n&quot;, store_mfn);<br>
 =A0 =A0 =A0 =A0 if ( !hvm )<br>
 =A0 =A0 =A0 =A0 =A0 =A0 printf(&quot;console-mfn %li\n&quot;, console_mfn)=
;<br>
+ =A0 =A0 =A0 printf(&quot;vm-gid-addr %lx\n&quot;, vm_gid_addr);<br>
 =A0 =A0 =A0 =A0fflush(stdout);<br>
 =A0 =A0 }<br>
<br>
diff -r 62ff6a318c5d -r de5432066adc tools/xcutils/xc_save.c<br>
--- a/tools/xcutils/xc_save.c =A0 Wed Nov 30 16:59:58 2011 -0800<br>
+++ b/tools/xcutils/xc_save.c =A0 Fri Dec 02 14:42:17 2011 +0000<br>
@@ -169,6 +169,10 @@ main(int argc, char **argv)<br>
 =A0 =A0 unsigned int maxit, max_f;<br>
 =A0 =A0 int io_fd, ret, port;<br>
 =A0 =A0 struct save_callbacks callbacks;<br>
+ =A0 =A0char path[128];<br>
+ =A0 =A0struct xs_handle *xs;<br>
+ =A0 =A0char *addr;<br>
+ =A0 =A0unsigned long vm_gid_addr;<br>
<br>
 =A0 =A0 if (argc !=3D 6)<br>
 =A0 =A0 =A0 =A0 errx(1, &quot;usage: %s iofd domid maxit maxf flags&quot;,=
 argv[0]);<br>
@@ -207,8 +211,21 @@ main(int argc, char **argv)<br>
 =A0 =A0 memset(&amp;callbacks, 0, sizeof(callbacks));<br>
 =A0 =A0 callbacks.suspend =3D suspend;<br>
 =A0 =A0 callbacks.switch_qemu_logdirty =3D switch_qemu_logdirty;<br>
+<br>
+ =A0 =A0sprintf(path, &quot;/local/domain/%d/data/generation-id&quot;, si.=
domid);<br>
+<br>
+ =A0 =A0if ((xs =3D xs_daemon_open()) =3D=3D NULL)<br>
+ =A0 =A0 =A0 =A0errx(1, &quot;Couldn&#39;t contact xenstore&quot;);<br>
+<br>
+ =A0 =A0addr =3D xs_read(xs, XBT_NULL, path, NULL);<br>
+<br>
+ =A0 =A0xs_daemon_close(xs);<br>
+<br>
+ =A0 =A0vm_gid_addr =3D (addr) ? strtoul(addr, NULL, 0) : 0;<br>
+ =A0 =A0free(addr);<br>
+<br>
 =A0 =A0 ret =3D xc_domain_save(si.xch, io_fd, si.domid, maxit, max_f, si.f=
lags,<br>
- =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 &amp;callbacks, !!(si.fla=
gs &amp; XCFLAGS_HVM));<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 &amp;callbacks, !!(si.fla=
gs &amp; XCFLAGS_HVM), vm_gid_addr);<br>
<br>
 =A0 =A0 if (si.suspend_evtchn &gt; 0)<br>
 =A0 =A0 =A0 =A0 xc_suspend_evtchn_release(si.xch, si.xce, si.domid, si.sus=
pend_evtchn);<br>
<br>
_______________________________________________<br>
Xen-devel mailing list<br>
<a href=3D"mailto:Xen-devel@lists.xensource.com">Xen-devel@lists.xensource.=
com</a><br>
<a href=3D"http://lists.xensource.com/xen-devel" target=3D"_blank">http://l=
ists.xensource.com/xen-devel</a><br>
</blockquote></div><br>You might have to rebase the entire patch. <br>The c=
ompression patch (pushed
into staging just before you sent this one)<br>touches the same diff contex=
t that this=20
code does (esp. the SAVE_IDs, <br>code in xc_domain_restore, in tools/pytho=
n/xen/lowlevel/checkpoint/checkpoint.c, etc.)<br>
<br>Assuming that the latest regression in staging/xen-unstable is resolved=
, I think<br>most of this code wont apply cleanly.<br><br>shriram<br>

--000e0ce02ace6a457804b32ad04f--


--===============5984604066976982491==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============5984604066976982491==--


From xen-devel-bounces@lists.xensource.com Sat Dec 03 07:15:32 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 03 Dec 2011 07: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.xensource.com>)
	id 1RWjnA-0006RE-Hj; Sat, 03 Dec 2011 07:13:48 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@cs.ubc.ca>) id 1RWjn7-0006R9-SY
	for xen-devel@lists.xensource.com; Sat, 03 Dec 2011 07:13:46 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-7.tower-174.messagelabs.com!1322896379!4090046!1
X-Originating-IP: [142.103.6.52]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10896 invoked from network); 3 Dec 2011 07:13:01 -0000
Received: from smtp.cs.ubc.ca (HELO smtp.cs.ubc.ca) (142.103.6.52)
	by server-7.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Dec 2011 07:13:01 -0000
Received: from mail-bw0-f43.google.com (mail-bw0-f43.google.com
	[209.85.214.43]) (authenticated bits=0)
	by smtp.cs.ubc.ca (8.14.3/8.13.6) with ESMTP id pB37Ctur030543
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL)
	for <xen-devel@lists.xensource.com>; Fri, 2 Dec 2011 23:12:56 -0800
Received: by bkbzu17 with SMTP id zu17so8380492bkb.30
	for <xen-devel@lists.xensource.com>;
	Fri, 02 Dec 2011 23:12:53 -0800 (PST)
Received: by 10.205.132.146 with SMTP id hu18mr608977bkc.123.1322896373464;
	Fri, 02 Dec 2011 23:12:53 -0800 (PST)
MIME-Version: 1.0
Received: by 10.204.179.10 with HTTP; Fri, 2 Dec 2011 23:12:12 -0800 (PST)
In-Reply-To: <de5432066adc888a704b.1322836943@cosworth.uk.xensource.com>
References: <de5432066adc888a704b.1322836943@cosworth.uk.xensource.com>
From: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Date: Fri, 2 Dec 2011 23:12:12 -0800
Message-ID: <CAP8mzPPZr_SBkneoO9UzWQ30mHxn+GjrCaHKUYPxkg4WHjz-aA@mail.gmail.com>
To: Paul Durrant <paul.durrant@citrix.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] VM generation ID save/restore and migrate
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: rshriram@cs.ubc.ca
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============5984604066976982491=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============5984604066976982491==
Content-Type: multipart/alternative; boundary=000e0ce02ace6a457804b32ad04f

--000e0ce02ace6a457804b32ad04f
Content-Type: text/plain; charset=ISO-8859-1

On Fri, Dec 2, 2011 at 6:42 AM, Paul Durrant <paul.durrant@citrix.com>wrote:

> # HG changeset patch
> # User Paul Durrant <paul.durrant@citrix.com>
> # Date 1322836937 0
> # Node ID de5432066adc888a704bbbce9b18de3a60859cff
> # Parent  62ff6a318c5db7779fdbf4ddfdfc9506e86fa701
> VM generation ID save/restore and migrate.
>
> Add code to track the address of the VM generation id buffer across a
> save/restore or migrate and increment it as necessary.
> The address of the buffer is written into xenstore by hvmloader at
> boot time. It must be read from xenstore by the caller of
> xc_domain_save() and then written back again by the caller of
> xc_domain_restore().
>
> Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
>
> diff -r 62ff6a318c5d -r de5432066adc
> tools/libxc/ia64/xc_ia64_linux_restore.c
> --- a/tools/libxc/ia64/xc_ia64_linux_restore.c  Wed Nov 30 16:59:58 2011
> -0800
> +++ b/tools/libxc/ia64/xc_ia64_linux_restore.c  Fri Dec 02 14:42:17 2011
> +0000
> @@ -548,7 +548,8 @@ int
>  xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
>                   unsigned int store_evtchn, unsigned long *store_mfn,
>                   unsigned int console_evtchn, unsigned long *console_mfn,
> -                  unsigned int hvm, unsigned int pae, int superpages)
> +                  unsigned int hvm, unsigned int pae, int superpages,
> +                  int increment_gid, unsigned long *vm_gid_addr)
>  {
>     DECLARE_DOMCTL;
>     int rc = 1;
> diff -r 62ff6a318c5d -r de5432066adc tools/libxc/ia64/xc_ia64_linux_save.c
> --- a/tools/libxc/ia64/xc_ia64_linux_save.c     Wed Nov 30 16:59:58 2011
> -0800
> +++ b/tools/libxc/ia64/xc_ia64_linux_save.c     Fri Dec 02 14:42:17 2011
> +0000
> @@ -382,7 +382,8 @@ out:
>  int
>  xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t
> max_iters,
>                uint32_t max_factor, uint32_t flags,
> -               struct save_callbacks* callbacks, int hvm)
> +               struct save_callbacks* callbacks, int hvm,
> +               unsigned long vm_gid_addr)
>  {
>     DECLARE_DOMCTL;
>     xc_dominfo_t info;
> diff -r 62ff6a318c5d -r de5432066adc tools/libxc/xc_domain_restore.c
> --- a/tools/libxc/xc_domain_restore.c   Wed Nov 30 16:59:58 2011 -0800
> +++ b/tools/libxc/xc_domain_restore.c   Fri Dec 02 14:42:17 2011 +0000
> @@ -676,6 +676,7 @@ typedef struct {
>     uint64_t console_pfn;
>     uint64_t acpi_ioport_location;
>     uint64_t viridian;
> +    uint64_t vm_gid_addr;
>  } pagebuf_t;
>
>  static int pagebuf_init(pagebuf_t* buf)
> @@ -820,6 +821,17 @@ static int pagebuf_get_one(xc_interface
>         }
>         return pagebuf_get_one(xch, ctx, buf, fd, dom);
>
> +    case XC_SAVE_ID_HVM_GENERATION_ID_ADDR:
> +        /* Skip padding 4 bytes then read the generation id buffer
> location. */
> +        if ( RDEXACT(fd, &buf->vm_gid_addr, sizeof(uint32_t)) ||
> +             RDEXACT(fd, &buf->vm_gid_addr, sizeof(uint64_t)) )
> +        {
> +            PERROR("error read the generation id buffer location");
> +            return -1;
> +        }
> +        DPRINTF("read generation id buffer address");
> +        return pagebuf_get_one(xch, ctx, buf, fd, dom);
> +
>     default:
>         if ( (count > MAX_BATCH_SIZE) || (count < 0) ) {
>             ERROR("Max batch size exceeded (%d). Giving up.", count);
> @@ -1186,7 +1198,8 @@ static int apply_batch(xc_interface *xch
>  int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
>                       unsigned int store_evtchn, unsigned long *store_mfn,
>                       unsigned int console_evtchn, unsigned long
> *console_mfn,
> -                      unsigned int hvm, unsigned int pae, int superpages)
> +                      unsigned int hvm, unsigned int pae, int superpages,
> +                      int no_increment_gid, unsigned long *vm_gid_addr)
>  {
>     DECLARE_DOMCTL;
>     int rc = 1, frc, i, j, n, m, pae_extended_cr3 = 0, ext_vcpucontext = 0;
> @@ -1386,6 +1399,39 @@ int xc_domain_restore(xc_interface *xch,
>                 xc_set_hvm_param(xch, dom, HVM_PARAM_VM86_TSS,
> pagebuf.vm86_tss);
>             if ( pagebuf.console_pfn )
>                 console_pfn = pagebuf.console_pfn;
> +            if ( pagebuf.vm_gid_addr ) {
> +                if ( !no_increment_gid ) {
> +                    unsigned int offset;
> +                    unsigned char *buf;
> +                    unsigned long long gid;
> +
> +                    /*
> +                     * Map the VM generation id buffer and inject the new
> value.
> +                     */
> +
> +                    pfn = pagebuf.vm_gid_addr >> PAGE_SHIFT;
> +                    offset = pagebuf.vm_gid_addr & (PAGE_SIZE - 1);
> +
> +                    if ( (pfn >= dinfo->p2m_size) ||
> +                         (pfn_type[pfn] != XEN_DOMCTL_PFINFO_NOTAB) )
> +                    {
> +                        ERROR("generation id buffer frame is bad");
> +                        goto out;
> +                    }
> +
> +                    mfn = ctx->p2m[pfn];
> +                    buf = xc_map_foreign_range(xch, dom, PAGE_SIZE,
> +                                               PROT_READ | PROT_WRITE,
> mfn);
> +
> +                    gid = *(unsigned long long *)(buf + offset);
> +                    *(unsigned long long *)(buf + offset) = gid + 1;
> +
> +                    munmap(buf, PAGE_SIZE);
> +                }
> +
> +                *vm_gid_addr = pagebuf.vm_gid_addr;
> +            }
> +
>             break;  /* our work here is done */
>         }
>
> diff -r 62ff6a318c5d -r de5432066adc tools/libxc/xc_domain_save.c
> --- a/tools/libxc/xc_domain_save.c      Wed Nov 30 16:59:58 2011 -0800
> +++ b/tools/libxc/xc_domain_save.c      Fri Dec 02 14:42:17 2011 +0000
> @@ -754,7 +754,8 @@ static int save_tsc_info(xc_interface *x
>
>  int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t
> max_iters,
>                    uint32_t max_factor, uint32_t flags,
> -                   struct save_callbacks* callbacks, int hvm)
> +                   struct save_callbacks* callbacks, int hvm,
> +                   unsigned long vm_gid_addr)
>  {
>     xc_dominfo_t info;
>     DECLARE_DOMCTL;
> @@ -1460,6 +1461,16 @@ int xc_domain_save(xc_interface *xch, in
>             uint64_t data;
>         } chunk = { 0, };
>
> +        chunk.id = XC_SAVE_ID_HVM_GENERATION_ID_ADDR;
> +        chunk.data = vm_gid_addr;
> +
> +        if ( (chunk.data != 0) &&
> +             wrexact(io_fd, &chunk, sizeof(chunk)) )
> +        {
> +            PERROR("Error when writing the generation id buffer location
> for guest");
> +            goto out;
> +        }
> +
>         chunk.id = XC_SAVE_ID_HVM_IDENT_PT;
>         chunk.data = 0;
>         xc_get_hvm_param(xch, dom, HVM_PARAM_IDENT_PT,
> diff -r 62ff6a318c5d -r de5432066adc tools/libxc/xenguest.h
> --- a/tools/libxc/xenguest.h    Wed Nov 30 16:59:58 2011 -0800
> +++ b/tools/libxc/xenguest.h    Fri Dec 02 14:42:17 2011 +0000
> @@ -57,7 +57,8 @@ struct save_callbacks {
>  */
>  int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t
> max_iters,
>                    uint32_t max_factor, uint32_t flags /* XCFLAGS_xxx */,
> -                   struct save_callbacks* callbacks, int hvm);
> +                   struct save_callbacks* callbacks, int hvm,
> +                   unsigned long vm_gid_addr);
>
>
>  /**
> @@ -71,12 +72,15 @@ int xc_domain_save(xc_interface *xch, in
>  * @parm hvm non-zero if this is a HVM restore
>  * @parm pae non-zero if this HVM domain has PAE support enabled
>  * @parm superpages non-zero to allocate guest memory with superpages
> + * @parm gid the new generation id of the VM
> + * @parm vm_gid_addr returned with the address of the generation id buffer
>  * @return 0 on success, -1 on failure
>  */
>  int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
>                       unsigned int store_evtchn, unsigned long *store_mfn,
>                       unsigned int console_evtchn, unsigned long
> *console_mfn,
> -                      unsigned int hvm, unsigned int pae, int superpages);
> +                      unsigned int hvm, unsigned int pae, int superpages,
> +                      int increment_gid, unsigned long *vm_gid_addr);
>  /**
>  * xc_domain_restore writes a file to disk that contains the device
>  * model saved state.
> diff -r 62ff6a318c5d -r de5432066adc tools/libxc/xg_save_restore.h
> --- a/tools/libxc/xg_save_restore.h     Wed Nov 30 16:59:58 2011 -0800
> +++ b/tools/libxc/xg_save_restore.h     Fri Dec 02 14:42:17 2011 +0000
> @@ -135,6 +135,7 @@
>  #define XC_SAVE_ID_LAST_CHECKPOINT    -9 /* Commit to restoring after
> completion of current iteration. */
>  #define XC_SAVE_ID_HVM_ACPI_IOPORTS_LOCATION -10
>  #define XC_SAVE_ID_HVM_VIRIDIAN       -11
> +#define XC_SAVE_ID_HVM_GENERATION_ID_ADDR -12
>
>  /*
>  ** We process save/restore/migrate in batches of pages; the below
> diff -r 62ff6a318c5d -r de5432066adc tools/libxl/libxl_create.c
> --- a/tools/libxl/libxl_create.c        Wed Nov 30 16:59:58 2011 -0800
> +++ b/tools/libxl/libxl_create.c        Fri Dec 02 14:42:17 2011 +0000
> @@ -101,6 +101,7 @@ int libxl_init_build_info(libxl_ctx *ctx
>         b_info->u.hvm.vpt_align = 1;
>         b_info->u.hvm.timer_mode = 1;
>         b_info->u.hvm.nested_hvm = 0;
> +        b_info->u.hvm.no_increment_gid = 0;
>         break;
>     case LIBXL_DOMAIN_TYPE_PV:
>         b_info->u.pv.slack_memkb = 8 * 1024;
> diff -r 62ff6a318c5d -r de5432066adc tools/libxl/libxl_dom.c
> --- a/tools/libxl/libxl_dom.c   Wed Nov 30 16:59:58 2011 -0800
> +++ b/tools/libxl/libxl_dom.c   Fri Dec 02 14:42:17 2011 +0000
> @@ -125,7 +125,7 @@ int libxl__build_post(libxl__gc *gc, uin
>     if (info->cpuid != NULL)
>         libxl_cpuid_set(ctx, domid, info->cpuid);
>
> -    ents = libxl__calloc(gc, 12 + (info->max_vcpus * 2) + 2, sizeof(char
> *));
> +    ents = libxl__calloc(gc, 14 + (info->max_vcpus * 2) + 2, sizeof(char
> *));
>     ents[0] = "memory/static-max";
>     ents[1] = libxl__sprintf(gc, "%d", info->max_memkb);
>     ents[2] = "memory/target";
> @@ -138,9 +138,11 @@ int libxl__build_post(libxl__gc *gc, uin
>     ents[9] = libxl__sprintf(gc, "%"PRIu32, state->store_port);
>     ents[10] = "store/ring-ref";
>     ents[11] = libxl__sprintf(gc, "%lu", state->store_mfn);
> +    ents[12] = "data/generation-id";
> +    ents[13] = libxl__sprintf(gc, "0x%lx", state->vm_gid_addr);
>     for (i = 0; i < info->max_vcpus; i++) {
> -        ents[12+(i*2)]   = libxl__sprintf(gc, "cpu/%d/availability", i);
> -        ents[12+(i*2)+1] = (i && info->cur_vcpus && !(info->cur_vcpus &
> (1 << i)))
> +        ents[14+(i*2)]   = libxl__sprintf(gc, "cpu/%d/availability", i);
> +        ents[14+(i*2)+1] = (i && info->cur_vcpus && !(info->cur_vcpus &
> (1 << i)))
>                             ? "offline" : "online";
>     }
>
> @@ -357,16 +359,19 @@ int libxl__domain_restore_common(libxl__
>     /* read signature */
>     int rc;
>     int hvm, pae, superpages;
> +    int no_increment_gid;
>     switch (info->type) {
>     case LIBXL_DOMAIN_TYPE_HVM:
>         hvm = 1;
>         superpages = 1;
>         pae = info->u.hvm.pae;
> +        no_increment_gid = info->u.hvm.no_increment_gid;
>         break;
>     case LIBXL_DOMAIN_TYPE_PV:
>         hvm = 0;
>         superpages = 0;
>         pae = 1;
> +        no_increment_gid = 0;
>         break;
>     default:
>         return ERROR_INVAL;
> @@ -374,7 +379,7 @@ int libxl__domain_restore_common(libxl__
>     rc = xc_domain_restore(ctx->xch, fd, domid,
>                            state->store_port, &state->store_mfn,
>                            state->console_port, &state->console_mfn,
> -                           hvm, pae, superpages);
> +                           hvm, pae, superpages, no_increment_gid,
> &state->vm_gid_addr);
>     if ( rc ) {
>         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "restoring domain");
>         return ERROR_FAIL;
> @@ -540,12 +545,22 @@ int libxl__domain_suspend_common(libxl__
>     struct save_callbacks callbacks;
>     struct suspendinfo si;
>     int hvm, rc = ERROR_FAIL;
> +    unsigned long vm_gid_addr;
>
>     switch (type) {
> -    case LIBXL_DOMAIN_TYPE_HVM:
> +    case LIBXL_DOMAIN_TYPE_HVM: {
> +        char *path;
> +        char *addr;
> +
> +        path = libxl__sprintf(gc, "%s/data/generation-id",
> libxl__xs_get_dompath(gc, domid));
> +        addr = libxl__xs_read(gc, XBT_NULL, path);
> +
> +        vm_gid_addr = (addr) ? strtoul(addr, NULL, 0) : 0;
>         hvm = 1;
>         break;
> +    }
>     case LIBXL_DOMAIN_TYPE_PV:
> +        vm_gid_addr = 0;
>         hvm = 0;
>         break;
>     default:
> @@ -583,7 +598,8 @@ int libxl__domain_suspend_common(libxl__
>     callbacks.switch_qemu_logdirty =
> libxl__domain_suspend_common_switch_qemu_logdirty;
>     callbacks.data = &si;
>
> -    rc = xc_domain_save(ctx->xch, fd, domid, 0, 0, flags, &callbacks,
> hvm);
> +    rc = xc_domain_save(ctx->xch, fd, domid, 0, 0, flags, &callbacks,
> +                        hvm, vm_gid_addr);
>     if ( rc ) {
>         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "saving domain: %s",
>                          si.guest_responded ?
> diff -r 62ff6a318c5d -r de5432066adc tools/libxl/libxl_internal.h
> --- a/tools/libxl/libxl_internal.h      Wed Nov 30 16:59:58 2011 -0800
> +++ b/tools/libxl/libxl_internal.h      Fri Dec 02 14:42:17 2011 +0000
> @@ -199,6 +199,7 @@ typedef struct {
>
>     uint32_t console_port;
>     unsigned long console_mfn;
> +    unsigned long vm_gid_addr;
>  } libxl__domain_build_state;
>
>  _hidden int libxl__build_pre(libxl__gc *gc, uint32_t domid,
> diff -r 62ff6a318c5d -r de5432066adc tools/libxl/libxl_types.idl
> --- a/tools/libxl/libxl_types.idl       Wed Nov 30 16:59:58 2011 -0800
> +++ b/tools/libxl/libxl_types.idl       Fri Dec 02 14:42:17 2011 +0000
> @@ -183,6 +183,7 @@ libxl_domain_build_info = Struct("domain
>                                        ("vpt_align", bool),
>                                        ("timer_mode", integer),
>                                        ("nested_hvm", bool),
> +                                       ("no_increment_gid", bool),
>                                        ])),
>                  ("pv", Struct(None, [("kernel", libxl_file_reference),
>                                       ("slack_memkb", uint32),
> diff -r 62ff6a318c5d -r de5432066adc tools/libxl/xl_cmdimpl.c
> --- a/tools/libxl/xl_cmdimpl.c  Wed Nov 30 16:59:58 2011 -0800
> +++ b/tools/libxl/xl_cmdimpl.c  Fri Dec 02 14:42:17 2011 +0000
> @@ -360,6 +360,7 @@ static void printf_info(int domid,
>         printf("\t\t\t(vpt_align %d)\n", b_info->u.hvm.vpt_align);
>         printf("\t\t\t(timer_mode %d)\n", b_info->u.hvm.timer_mode);
>         printf("\t\t\t(nestedhvm %d)\n", b_info->u.hvm.nested_hvm);
> +        printf("\t\t\t(no_increment_gid %d)\n",
> b_info->u.hvm.no_increment_gid);
>
>         printf("\t\t\t(device_model %s)\n", dm_info->device_model ? :
> "default");
>         printf("\t\t\t(videoram %d)\n", dm_info->videoram);
> @@ -1362,6 +1363,7 @@ struct domain_create {
>     const char *restore_file;
>     int migrate_fd; /* -1 means none */
>     char **migration_domname_r; /* from malloc */
> +    int no_increment_gid;
>  };
>
>  static int freemem(libxl_domain_build_info *b_info,
> libxl_device_model_info *dm_info)
> @@ -1571,6 +1573,8 @@ static int create_domain(struct domain_c
>         }
>     }
>
> +    d_config.b_info.u.hvm.no_increment_gid = dom_info->no_increment_gid;
> +
>     if (debug || dom_info->dryrun)
>         printf_info(-1, &d_config, &d_config.dm_info);
>
> @@ -2796,6 +2800,7 @@ static void migrate_receive(int debug, i
>     dom_info.restore_file = "incoming migration stream";
>     dom_info.migrate_fd = 0; /* stdin */
>     dom_info.migration_domname_r = &migration_domname;
> +    dom_info.no_increment_gid = 1;
>
>     rc = create_domain(&dom_info);
>     if (rc < 0) {
> diff -r 62ff6a318c5d -r de5432066adc
> tools/python/xen/lowlevel/checkpoint/libcheckpoint.c
> --- a/tools/python/xen/lowlevel/checkpoint/libcheckpoint.c      Wed Nov 30
> 16:59:58 2011 -0800
> +++ b/tools/python/xen/lowlevel/checkpoint/libcheckpoint.c      Fri Dec 02
> 14:42:17 2011 +0000
> @@ -174,6 +174,7 @@ int checkpoint_start(checkpoint_state* s
>  {
>     int hvm, rc;
>     int flags = XCFLAGS_LIVE;
> +    unsigned long vm_gid_addr;
>
>     if (!s->domid) {
>        s->errstr = "checkpoint state not opened";
> @@ -184,14 +185,25 @@ int checkpoint_start(checkpoint_state* s
>
>     hvm = s->domtype > dt_pv;
>     if (hvm) {
> +       char path[128];
> +       char *addr;
> +
> +       sprintf(path, "/local/domain/%u/data/generation-id", s->domid);
> +       addr = xs_read(s->xsh, XBT_NULL, path, NULL);
> +
> +       vm_gid_addr = (addr) ? strtoul(addr, NULL, 0) : 0;
> +       free(addr);
> +
>        flags |= XCFLAGS_HVM;
>        if (switch_qemu_logdirty(s, 1))
>            return -1;
> +    } else {
> +       vm_gid_addr = 0;
>     }
>
>     callbacks->switch_qemu_logdirty = noop_switch_logdirty;
>
> -    rc = xc_domain_save(s->xch, fd, s->domid, 0, 0, flags, callbacks,
> hvm);
> +    rc = xc_domain_save(s->xch, fd, s->domid, 0, 0, flags, callbacks,
> hvm, vm_gid_addr);
>
>     if (hvm)
>        switch_qemu_logdirty(s, 0);
> diff -r 62ff6a318c5d -r de5432066adc tools/xcutils/xc_restore.c
> --- a/tools/xcutils/xc_restore.c        Wed Nov 30 16:59:58 2011 -0800
> +++ b/tools/xcutils/xc_restore.c        Fri Dec 02 14:42:17 2011 +0000
> @@ -23,7 +23,8 @@ main(int argc, char **argv)
>     xc_interface *xch;
>     int io_fd, ret;
>     int superpages;
> -    unsigned long store_mfn, console_mfn;
> +    unsigned long store_mfn, console_mfn, vm_gid_addr;
> +    int no_increment_gid;
>
>     if ( (argc != 8) && (argc != 9) )
>         errx(1, "usage: %s iofd domid store_evtchn "
> @@ -40,19 +41,25 @@ main(int argc, char **argv)
>     hvm  = atoi(argv[5]);
>     pae  = atoi(argv[6]);
>     apic = atoi(argv[7]);
> -    if ( argc == 9 )
> +    if ( argc >= 9 )
>            superpages = atoi(argv[8]);
>     else
>            superpages = !!hvm;
> +    if ( argc >= 10 )
> +           no_increment_gid = !atoi(argv[9]);
> +    else
> +           no_increment_gid = 0;
>
>     ret = xc_domain_restore(xch, io_fd, domid, store_evtchn, &store_mfn,
> -                            console_evtchn, &console_mfn, hvm, pae,
> superpages);
> +                            console_evtchn, &console_mfn, hvm, pae,
> superpages,
> +                            no_increment_gid, &vm_gid_addr);
>
>     if ( ret == 0 )
>     {
>        printf("store-mfn %li\n", store_mfn);
>         if ( !hvm )
>             printf("console-mfn %li\n", console_mfn);
> +       printf("vm-gid-addr %lx\n", vm_gid_addr);
>        fflush(stdout);
>     }
>
> diff -r 62ff6a318c5d -r de5432066adc tools/xcutils/xc_save.c
> --- a/tools/xcutils/xc_save.c   Wed Nov 30 16:59:58 2011 -0800
> +++ b/tools/xcutils/xc_save.c   Fri Dec 02 14:42:17 2011 +0000
> @@ -169,6 +169,10 @@ main(int argc, char **argv)
>     unsigned int maxit, max_f;
>     int io_fd, ret, port;
>     struct save_callbacks callbacks;
> +    char path[128];
> +    struct xs_handle *xs;
> +    char *addr;
> +    unsigned long vm_gid_addr;
>
>     if (argc != 6)
>         errx(1, "usage: %s iofd domid maxit maxf flags", argv[0]);
> @@ -207,8 +211,21 @@ main(int argc, char **argv)
>     memset(&callbacks, 0, sizeof(callbacks));
>     callbacks.suspend = suspend;
>     callbacks.switch_qemu_logdirty = switch_qemu_logdirty;
> +
> +    sprintf(path, "/local/domain/%d/data/generation-id", si.domid);
> +
> +    if ((xs = xs_daemon_open()) == NULL)
> +        errx(1, "Couldn't contact xenstore");
> +
> +    addr = xs_read(xs, XBT_NULL, path, NULL);
> +
> +    xs_daemon_close(xs);
> +
> +    vm_gid_addr = (addr) ? strtoul(addr, NULL, 0) : 0;
> +    free(addr);
> +
>     ret = xc_domain_save(si.xch, io_fd, si.domid, maxit, max_f, si.flags,
> -                         &callbacks, !!(si.flags & XCFLAGS_HVM));
> +                         &callbacks, !!(si.flags & XCFLAGS_HVM),
> vm_gid_addr);
>
>     if (si.suspend_evtchn > 0)
>         xc_suspend_evtchn_release(si.xch, si.xce, si.domid,
> si.suspend_evtchn);
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>

You might have to rebase the entire patch.
The compression patch (pushed into staging just before you sent this one)
touches the same diff context that this code does (esp. the SAVE_IDs,
code in xc_domain_restore, in
tools/python/xen/lowlevel/checkpoint/checkpoint.c, etc.)

Assuming that the latest regression in staging/xen-unstable is resolved, I
think
most of this code wont apply cleanly.

shriram

--000e0ce02ace6a457804b32ad04f
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote">On Fri, Dec 2, 2011 at 6:42 AM, Paul Durrant <sp=
an dir=3D"ltr">&lt;<a href=3D"mailto:paul.durrant@citrix.com">paul.durrant@=
citrix.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

# HG changeset patch<br>
# User Paul Durrant &lt;<a href=3D"mailto:paul.durrant@citrix.com">paul.dur=
rant@citrix.com</a>&gt;<br>
# Date 1322836937 0<br>
# Node ID de5432066adc888a704bbbce9b18de3a60859cff<br>
# Parent =A062ff6a318c5db7779fdbf4ddfdfc9506e86fa701<br>
VM generation ID save/restore and migrate.<br>
<br>
Add code to track the address of the VM generation id buffer across a<br>
save/restore or migrate and increment it as necessary.<br>
The address of the buffer is written into xenstore by hvmloader at<br>
boot time. It must be read from xenstore by the caller of<br>
xc_domain_save() and then written back again by the caller of<br>
xc_domain_restore().<br>
<br>
Signed-off-by: Paul Durrant &lt;<a href=3D"mailto:paul.durrant@citrix.com">=
paul.durrant@citrix.com</a>&gt;<br>
<br>
diff -r 62ff6a318c5d -r de5432066adc tools/libxc/ia64/xc_ia64_linux_restore=
.c<br>
--- a/tools/libxc/ia64/xc_ia64_linux_restore.c =A0Wed Nov 30 16:59:58 2011 =
-0800<br>
+++ b/tools/libxc/ia64/xc_ia64_linux_restore.c =A0Fri Dec 02 14:42:17 2011 =
+0000<br>
@@ -548,7 +548,8 @@ int<br>
=A0xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,<br>
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 unsigned int store_evtchn, unsigned lo=
ng *store_mfn,<br>
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 unsigned int console_evtchn, unsigned =
long *console_mfn,<br>
- =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0unsigned int hvm, unsigned int pae, in=
t superpages)<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0unsigned int hvm, unsigned int pae, in=
t superpages,<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0int increment_gid, unsigned long *vm_g=
id_addr)<br>
=A0{<br>
 =A0 =A0 DECLARE_DOMCTL;<br>
 =A0 =A0 int rc =3D 1;<br>
diff -r 62ff6a318c5d -r de5432066adc tools/libxc/ia64/xc_ia64_linux_save.c<=
br>
--- a/tools/libxc/ia64/xc_ia64_linux_save.c =A0 =A0 Wed Nov 30 16:59:58 201=
1 -0800<br>
+++ b/tools/libxc/ia64/xc_ia64_linux_save.c =A0 =A0 Fri Dec 02 14:42:17 201=
1 +0000<br>
@@ -382,7 +382,8 @@ out:<br>
=A0int<br>
=A0xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_=
iters,<br>
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0uint32_t max_factor, uint32_t flags,<br>
- =A0 =A0 =A0 =A0 =A0 =A0 =A0 struct save_callbacks* callbacks, int hvm)<br=
>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 struct save_callbacks* callbacks, int hvm,<br=
>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 unsigned long vm_gid_addr)<br>
=A0{<br>
 =A0 =A0 DECLARE_DOMCTL;<br>
 =A0 =A0 xc_dominfo_t info;<br>
diff -r 62ff6a318c5d -r de5432066adc tools/libxc/xc_domain_restore.c<br>
--- a/tools/libxc/xc_domain_restore.c =A0 Wed Nov 30 16:59:58 2011 -0800<br=
>
+++ b/tools/libxc/xc_domain_restore.c =A0 Fri Dec 02 14:42:17 2011 +0000<br=
>
@@ -676,6 +676,7 @@ typedef struct {<br>
 =A0 =A0 uint64_t console_pfn;<br>
 =A0 =A0 uint64_t acpi_ioport_location;<br>
 =A0 =A0 uint64_t viridian;<br>
+ =A0 =A0uint64_t vm_gid_addr;<br>
=A0} pagebuf_t;<br>
<br>
=A0static int pagebuf_init(pagebuf_t* buf)<br>
@@ -820,6 +821,17 @@ static int pagebuf_get_one(xc_interface<br>
 =A0 =A0 =A0 =A0 }<br>
 =A0 =A0 =A0 =A0 return pagebuf_get_one(xch, ctx, buf, fd, dom);<br>
<br>
+ =A0 =A0case XC_SAVE_ID_HVM_GENERATION_ID_ADDR:<br>
+ =A0 =A0 =A0 =A0/* Skip padding 4 bytes then read the generation id buffer=
 location. */<br>
+ =A0 =A0 =A0 =A0if ( RDEXACT(fd, &amp;buf-&gt;vm_gid_addr, sizeof(uint32_t=
)) ||<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 RDEXACT(fd, &amp;buf-&gt;vm_gid_addr, sizeof(uint=
64_t)) )<br>
+ =A0 =A0 =A0 =A0{<br>
+ =A0 =A0 =A0 =A0 =A0 =A0PERROR(&quot;error read the generation id buffer l=
ocation&quot;);<br>
+ =A0 =A0 =A0 =A0 =A0 =A0return -1;<br>
+ =A0 =A0 =A0 =A0}<br>
+ =A0 =A0 =A0 =A0DPRINTF(&quot;read generation id buffer address&quot;);<br=
>
+ =A0 =A0 =A0 =A0return pagebuf_get_one(xch, ctx, buf, fd, dom);<br>
+<br>
 =A0 =A0 default:<br>
 =A0 =A0 =A0 =A0 if ( (count &gt; MAX_BATCH_SIZE) || (count &lt; 0) ) {<br>
 =A0 =A0 =A0 =A0 =A0 =A0 ERROR(&quot;Max batch size exceeded (%d). Giving u=
p.&quot;, count);<br>
@@ -1186,7 +1198,8 @@ static int apply_batch(xc_interface *xch<br>
=A0int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,<br>
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 unsigned int store_evtchn, uns=
igned long *store_mfn,<br>
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 unsigned int console_evtchn, u=
nsigned long *console_mfn,<br>
- =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0unsigned int hvm, unsigned int=
 pae, int superpages)<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0unsigned int hvm, unsigned int=
 pae, int superpages,<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0int no_increment_gid, unsigned=
 long *vm_gid_addr)<br>
=A0{<br>
 =A0 =A0 DECLARE_DOMCTL;<br>
 =A0 =A0 int rc =3D 1, frc, i, j, n, m, pae_extended_cr3 =3D 0, ext_vcpucon=
text =3D 0;<br>
@@ -1386,6 +1399,39 @@ int xc_domain_restore(xc_interface *xch,<br>
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 xc_set_hvm_param(xch, dom, HVM_PARAM_VM86_=
TSS, pagebuf.vm86_tss);<br>
 =A0 =A0 =A0 =A0 =A0 =A0 if ( pagebuf.console_pfn )<br>
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 console_pfn =3D pagebuf.console_pfn;<br>
+ =A0 =A0 =A0 =A0 =A0 =A0if ( pagebuf.vm_gid_addr ) {<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if ( !no_increment_gid ) {<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0unsigned int offset;<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0unsigned char *buf;<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0unsigned long long gid;<br>
+<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/*<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 * Map the VM generation id buffer=
 and inject the new value.<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 */<br>
+<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0pfn =3D pagebuf.vm_gid_addr &gt;&g=
t; PAGE_SHIFT;<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0offset =3D pagebuf.vm_gid_addr &am=
p; (PAGE_SIZE - 1);<br>
+<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if ( (pfn &gt;=3D dinfo-&gt;p2m_si=
ze) ||<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (pfn_type[pfn] !=3D XEN_D=
OMCTL_PFINFO_NOTAB) )<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0{<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ERROR(&quot;generation id =
buffer frame is bad&quot;);<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0goto out;<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0}<br>
+<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0mfn =3D ctx-&gt;p2m[pfn];<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0buf =3D xc_map_foreign_range(xch, =
dom, PAGE_SIZE,<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 PROT_READ | PROT_WRITE, mfn);<br>
+<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0gid =3D *(unsigned long long *)(bu=
f + offset);<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0*(unsigned long long *)(buf + offs=
et) =3D gid + 1;<br>
+<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0munmap(buf, PAGE_SIZE);<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0}<br>
+<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0*vm_gid_addr =3D pagebuf.vm_gid_addr;<br>
+ =A0 =A0 =A0 =A0 =A0 =A0}<br>
+<br>
 =A0 =A0 =A0 =A0 =A0 =A0 break; =A0/* our work here is done */<br>
 =A0 =A0 =A0 =A0 }<br>
<br>
diff -r 62ff6a318c5d -r de5432066adc tools/libxc/xc_domain_save.c<br>
--- a/tools/libxc/xc_domain_save.c =A0 =A0 =A0Wed Nov 30 16:59:58 2011 -080=
0<br>
+++ b/tools/libxc/xc_domain_save.c =A0 =A0 =A0Fri Dec 02 14:42:17 2011 +000=
0<br>
@@ -754,7 +754,8 @@ static int save_tsc_info(xc_interface *x<br>
<br>
=A0int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t =
max_iters,<br>
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0uint32_t max_factor, uint32_t flags=
,<br>
- =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 struct save_callbacks* callbacks, int=
 hvm)<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 struct save_callbacks* callbacks, int=
 hvm,<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 unsigned long vm_gid_addr)<br>
=A0{<br>
 =A0 =A0 xc_dominfo_t info;<br>
 =A0 =A0 DECLARE_DOMCTL;<br>
@@ -1460,6 +1461,16 @@ int xc_domain_save(xc_interface *xch, in<br>
 =A0 =A0 =A0 =A0 =A0 =A0 uint64_t data;<br>
 =A0 =A0 =A0 =A0 } chunk =3D { 0, };<br>
<br>
+ =A0 =A0 =A0 =A0<a href=3D"http://chunk.id" target=3D"_blank">chunk.id</a>=
 =3D XC_SAVE_ID_HVM_GENERATION_ID_ADDR;<br>
+ =A0 =A0 =A0 =A0chunk.data =3D vm_gid_addr;<br>
+<br>
+ =A0 =A0 =A0 =A0if ( (chunk.data !=3D 0) &amp;&amp;<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 wrexact(io_fd, &amp;chunk, sizeof(chunk)) )<br>
+ =A0 =A0 =A0 =A0{<br>
+ =A0 =A0 =A0 =A0 =A0 =A0PERROR(&quot;Error when writing the generation id =
buffer location for guest&quot;);<br>
+ =A0 =A0 =A0 =A0 =A0 =A0goto out;<br>
+ =A0 =A0 =A0 =A0}<br>
+<br>
 =A0 =A0 =A0 =A0 <a href=3D"http://chunk.id" target=3D"_blank">chunk.id</a>=
 =3D XC_SAVE_ID_HVM_IDENT_PT;<br>
 =A0 =A0 =A0 =A0 chunk.data =3D 0;<br>
 =A0 =A0 =A0 =A0 xc_get_hvm_param(xch, dom, HVM_PARAM_IDENT_PT,<br>
diff -r 62ff6a318c5d -r de5432066adc tools/libxc/xenguest.h<br>
--- a/tools/libxc/xenguest.h =A0 =A0Wed Nov 30 16:59:58 2011 -0800<br>
+++ b/tools/libxc/xenguest.h =A0 =A0Fri Dec 02 14:42:17 2011 +0000<br>
@@ -57,7 +57,8 @@ struct save_callbacks {<br>
 =A0*/<br>
=A0int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t =
max_iters,<br>
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0uint32_t max_factor, uint32_t flags=
 /* XCFLAGS_xxx */,<br>
- =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 struct save_callbacks* callbacks, int=
 hvm);<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 struct save_callbacks* callbacks, int=
 hvm,<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 unsigned long vm_gid_addr);<br>
<br>
<br>
=A0/**<br>
@@ -71,12 +72,15 @@ int xc_domain_save(xc_interface *xch, in<br>
 =A0* @parm hvm non-zero if this is a HVM restore<br>
 =A0* @parm pae non-zero if this HVM domain has PAE support enabled<br>
 =A0* @parm superpages non-zero to allocate guest memory with superpages<br=
>
+ * @parm gid the new generation id of the VM<br>
+ * @parm vm_gid_addr returned with the address of the generation id buffer=
<br>
 =A0* @return 0 on success, -1 on failure<br>
 =A0*/<br>
=A0int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,<br>
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 unsigned int store_evtchn, uns=
igned long *store_mfn,<br>
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 unsigned int console_evtchn, u=
nsigned long *console_mfn,<br>
- =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0unsigned int hvm, unsigned int=
 pae, int superpages);<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0unsigned int hvm, unsigned int=
 pae, int superpages,<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0int increment_gid, unsigned lo=
ng *vm_gid_addr);<br>
=A0/**<br>
 =A0* xc_domain_restore writes a file to disk that contains the device<br>
 =A0* model saved state.<br>
diff -r 62ff6a318c5d -r de5432066adc tools/libxc/xg_save_restore.h<br>
--- a/tools/libxc/xg_save_restore.h =A0 =A0 Wed Nov 30 16:59:58 2011 -0800<=
br>
+++ b/tools/libxc/xg_save_restore.h =A0 =A0 Fri Dec 02 14:42:17 2011 +0000<=
br>
@@ -135,6 +135,7 @@<br>
=A0#define XC_SAVE_ID_LAST_CHECKPOINT =A0 =A0-9 /* Commit to restoring afte=
r completion of current iteration. */<br>
=A0#define XC_SAVE_ID_HVM_ACPI_IOPORTS_LOCATION -10<br>
=A0#define XC_SAVE_ID_HVM_VIRIDIAN =A0 =A0 =A0 -11<br>
+#define XC_SAVE_ID_HVM_GENERATION_ID_ADDR -12<br>
<br>
=A0/*<br>
=A0** We process save/restore/migrate in batches of pages; the below<br>
diff -r 62ff6a318c5d -r de5432066adc tools/libxl/libxl_create.c<br>
--- a/tools/libxl/libxl_create.c =A0 =A0 =A0 =A0Wed Nov 30 16:59:58 2011 -0=
800<br>
+++ b/tools/libxl/libxl_create.c =A0 =A0 =A0 =A0Fri Dec 02 14:42:17 2011 +0=
000<br>
@@ -101,6 +101,7 @@ int libxl_init_build_info(libxl_ctx *ctx<br>
 =A0 =A0 =A0 =A0 b_info-&gt;u.hvm.vpt_align =3D 1;<br>
 =A0 =A0 =A0 =A0 b_info-&gt;u.hvm.timer_mode =3D 1;<br>
 =A0 =A0 =A0 =A0 b_info-&gt;u.hvm.nested_hvm =3D 0;<br>
+ =A0 =A0 =A0 =A0b_info-&gt;u.hvm.no_increment_gid =3D 0;<br>
 =A0 =A0 =A0 =A0 break;<br>
 =A0 =A0 case LIBXL_DOMAIN_TYPE_PV:<br>
 =A0 =A0 =A0 =A0 b_info-&gt;u.pv.slack_memkb =3D 8 * 1024;<br>
diff -r 62ff6a318c5d -r de5432066adc tools/libxl/libxl_dom.c<br>
--- a/tools/libxl/libxl_dom.c =A0 Wed Nov 30 16:59:58 2011 -0800<br>
+++ b/tools/libxl/libxl_dom.c =A0 Fri Dec 02 14:42:17 2011 +0000<br>
@@ -125,7 +125,7 @@ int libxl__build_post(libxl__gc *gc, uin<br>
 =A0 =A0 if (info-&gt;cpuid !=3D NULL)<br>
 =A0 =A0 =A0 =A0 libxl_cpuid_set(ctx, domid, info-&gt;cpuid);<br>
<br>
- =A0 =A0ents =3D libxl__calloc(gc, 12 + (info-&gt;max_vcpus * 2) + 2, size=
of(char *));<br>
+ =A0 =A0ents =3D libxl__calloc(gc, 14 + (info-&gt;max_vcpus * 2) + 2, size=
of(char *));<br>
 =A0 =A0 ents[0] =3D &quot;memory/static-max&quot;;<br>
 =A0 =A0 ents[1] =3D libxl__sprintf(gc, &quot;%d&quot;, info-&gt;max_memkb)=
;<br>
 =A0 =A0 ents[2] =3D &quot;memory/target&quot;;<br>
@@ -138,9 +138,11 @@ int libxl__build_post(libxl__gc *gc, uin<br>
 =A0 =A0 ents[9] =3D libxl__sprintf(gc, &quot;%&quot;PRIu32, state-&gt;stor=
e_port);<br>
 =A0 =A0 ents[10] =3D &quot;store/ring-ref&quot;;<br>
 =A0 =A0 ents[11] =3D libxl__sprintf(gc, &quot;%lu&quot;, state-&gt;store_m=
fn);<br>
+ =A0 =A0ents[12] =3D &quot;data/generation-id&quot;;<br>
+ =A0 =A0ents[13] =3D libxl__sprintf(gc, &quot;0x%lx&quot;, state-&gt;vm_gi=
d_addr);<br>
 =A0 =A0 for (i =3D 0; i &lt; info-&gt;max_vcpus; i++) {<br>
- =A0 =A0 =A0 =A0ents[12+(i*2)] =A0 =3D libxl__sprintf(gc, &quot;cpu/%d/ava=
ilability&quot;, i);<br>
- =A0 =A0 =A0 =A0ents[12+(i*2)+1] =3D (i &amp;&amp; info-&gt;cur_vcpus &amp=
;&amp; !(info-&gt;cur_vcpus &amp; (1 &lt;&lt; i)))<br>
+ =A0 =A0 =A0 =A0ents[14+(i*2)] =A0 =3D libxl__sprintf(gc, &quot;cpu/%d/ava=
ilability&quot;, i);<br>
+ =A0 =A0 =A0 =A0ents[14+(i*2)+1] =3D (i &amp;&amp; info-&gt;cur_vcpus &amp=
;&amp; !(info-&gt;cur_vcpus &amp; (1 &lt;&lt; i)))<br>
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ? &quot;offline&qu=
ot; : &quot;online&quot;;<br>
 =A0 =A0 }<br>
<br>
@@ -357,16 +359,19 @@ int libxl__domain_restore_common(libxl__<br>
 =A0 =A0 /* read signature */<br>
 =A0 =A0 int rc;<br>
 =A0 =A0 int hvm, pae, superpages;<br>
+ =A0 =A0int no_increment_gid;<br>
 =A0 =A0 switch (info-&gt;type) {<br>
 =A0 =A0 case LIBXL_DOMAIN_TYPE_HVM:<br>
 =A0 =A0 =A0 =A0 hvm =3D 1;<br>
 =A0 =A0 =A0 =A0 superpages =3D 1;<br>
 =A0 =A0 =A0 =A0 pae =3D info-&gt;u.hvm.pae;<br>
+ =A0 =A0 =A0 =A0no_increment_gid =3D info-&gt;u.hvm.no_increment_gid;<br>
 =A0 =A0 =A0 =A0 break;<br>
 =A0 =A0 case LIBXL_DOMAIN_TYPE_PV:<br>
 =A0 =A0 =A0 =A0 hvm =3D 0;<br>
 =A0 =A0 =A0 =A0 superpages =3D 0;<br>
 =A0 =A0 =A0 =A0 pae =3D 1;<br>
+ =A0 =A0 =A0 =A0no_increment_gid =3D 0;<br>
 =A0 =A0 =A0 =A0 break;<br>
 =A0 =A0 default:<br>
 =A0 =A0 =A0 =A0 return ERROR_INVAL;<br>
@@ -374,7 +379,7 @@ int libxl__domain_restore_common(libxl__<br>
 =A0 =A0 rc =3D xc_domain_restore(ctx-&gt;xch, fd, domid,<br>
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0state-&gt;store_por=
t, &amp;state-&gt;store_mfn,<br>
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0state-&gt;console_p=
ort, &amp;state-&gt;console_mfn,<br>
- =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 hvm, pae, superpages)=
;<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 hvm, pae, superpages,=
 no_increment_gid, &amp;state-&gt;vm_gid_addr);<br>
 =A0 =A0 if ( rc ) {<br>
 =A0 =A0 =A0 =A0 LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, &quot;restoring do=
main&quot;);<br>
 =A0 =A0 =A0 =A0 return ERROR_FAIL;<br>
@@ -540,12 +545,22 @@ int libxl__domain_suspend_common(libxl__<br>
 =A0 =A0 struct save_callbacks callbacks;<br>
 =A0 =A0 struct suspendinfo si;<br>
 =A0 =A0 int hvm, rc =3D ERROR_FAIL;<br>
+ =A0 =A0unsigned long vm_gid_addr;<br>
<br>
 =A0 =A0 switch (type) {<br>
- =A0 =A0case LIBXL_DOMAIN_TYPE_HVM:<br>
+ =A0 =A0case LIBXL_DOMAIN_TYPE_HVM: {<br>
+ =A0 =A0 =A0 =A0char *path;<br>
+ =A0 =A0 =A0 =A0char *addr;<br>
+<br>
+ =A0 =A0 =A0 =A0path =3D libxl__sprintf(gc, &quot;%s/data/generation-id&qu=
ot;, libxl__xs_get_dompath(gc, domid));<br>
+ =A0 =A0 =A0 =A0addr =3D libxl__xs_read(gc, XBT_NULL, path);<br>
+<br>
+ =A0 =A0 =A0 =A0vm_gid_addr =3D (addr) ? strtoul(addr, NULL, 0) : 0;<br>
 =A0 =A0 =A0 =A0 hvm =3D 1;<br>
 =A0 =A0 =A0 =A0 break;<br>
+ =A0 =A0}<br>
 =A0 =A0 case LIBXL_DOMAIN_TYPE_PV:<br>
+ =A0 =A0 =A0 =A0vm_gid_addr =3D 0;<br>
 =A0 =A0 =A0 =A0 hvm =3D 0;<br>
 =A0 =A0 =A0 =A0 break;<br>
 =A0 =A0 default:<br>
@@ -583,7 +598,8 @@ int libxl__domain_suspend_common(libxl__<br>
 =A0 =A0 callbacks.switch_qemu_logdirty =3D libxl__domain_suspend_common_sw=
itch_qemu_logdirty;<br>
 =A0 =A0 callbacks.data =3D &amp;si;<br>
<br>
- =A0 =A0rc =3D xc_domain_save(ctx-&gt;xch, fd, domid, 0, 0, flags, &amp;ca=
llbacks, hvm);<br>
+ =A0 =A0rc =3D xc_domain_save(ctx-&gt;xch, fd, domid, 0, 0, flags, &amp;ca=
llbacks,<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0hvm, vm_gid_addr);<br>
 =A0 =A0 if ( rc ) {<br>
 =A0 =A0 =A0 =A0 LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, &quot;saving domai=
n: %s&quot;,<br>
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0si.guest_responded ?<br=
>
diff -r 62ff6a318c5d -r de5432066adc tools/libxl/libxl_internal.h<br>
--- a/tools/libxl/libxl_internal.h =A0 =A0 =A0Wed Nov 30 16:59:58 2011 -080=
0<br>
+++ b/tools/libxl/libxl_internal.h =A0 =A0 =A0Fri Dec 02 14:42:17 2011 +000=
0<br>
@@ -199,6 +199,7 @@ typedef struct {<br>
<br>
 =A0 =A0 uint32_t console_port;<br>
 =A0 =A0 unsigned long console_mfn;<br>
+ =A0 =A0unsigned long vm_gid_addr;<br>
=A0} libxl__domain_build_state;<br>
<br>
=A0_hidden int libxl__build_pre(libxl__gc *gc, uint32_t domid,<br>
diff -r 62ff6a318c5d -r de5432066adc tools/libxl/libxl_types.idl<br>
--- a/tools/libxl/libxl_types.idl =A0 =A0 =A0 Wed Nov 30 16:59:58 2011 -080=
0<br>
+++ b/tools/libxl/libxl_types.idl =A0 =A0 =A0 Fri Dec 02 14:42:17 2011 +000=
0<br>
@@ -183,6 +183,7 @@ libxl_domain_build_info =3D Struct(&quot;domain<br>
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0(&quot;vpt_align&quot;, bool),<br>
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0(&quot;timer_mode&quot;, integer),<br>
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0(&quot;nested_hvm&quot;, bool),<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 (&quot;no_increment_gid&quot;, bool),<br>
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0])),<br>
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(&quot;pv&quot;, Struct(None, [(&quot;k=
ernel&quot;, libxl_file_reference),<br>
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 (&quot;slack_memkb&quot;, uint32),<br>
diff -r 62ff6a318c5d -r de5432066adc tools/libxl/xl_cmdimpl.c<br>
--- a/tools/libxl/xl_cmdimpl.c =A0Wed Nov 30 16:59:58 2011 -0800<br>
+++ b/tools/libxl/xl_cmdimpl.c =A0Fri Dec 02 14:42:17 2011 +0000<br>
@@ -360,6 +360,7 @@ static void printf_info(int domid,<br>
 =A0 =A0 =A0 =A0 printf(&quot;\t\t\t(vpt_align %d)\n&quot;, b_info-&gt;u.hv=
m.vpt_align);<br>
 =A0 =A0 =A0 =A0 printf(&quot;\t\t\t(timer_mode %d)\n&quot;, b_info-&gt;u.h=
vm.timer_mode);<br>
 =A0 =A0 =A0 =A0 printf(&quot;\t\t\t(nestedhvm %d)\n&quot;, b_info-&gt;u.hv=
m.nested_hvm);<br>
+ =A0 =A0 =A0 =A0printf(&quot;\t\t\t(no_increment_gid %d)\n&quot;, b_info-&=
gt;u.hvm.no_increment_gid);<br>
<br>
 =A0 =A0 =A0 =A0 printf(&quot;\t\t\t(device_model %s)\n&quot;, dm_info-&gt;=
device_model ? : &quot;default&quot;);<br>
 =A0 =A0 =A0 =A0 printf(&quot;\t\t\t(videoram %d)\n&quot;, dm_info-&gt;vide=
oram);<br>
@@ -1362,6 +1363,7 @@ struct domain_create {<br>
 =A0 =A0 const char *restore_file;<br>
 =A0 =A0 int migrate_fd; /* -1 means none */<br>
 =A0 =A0 char **migration_domname_r; /* from malloc */<br>
+ =A0 =A0int no_increment_gid;<br>
=A0};<br>
<br>
=A0static int freemem(libxl_domain_build_info *b_info, libxl_device_model_i=
nfo *dm_info)<br>
@@ -1571,6 +1573,8 @@ static int create_domain(struct domain_c<br>
 =A0 =A0 =A0 =A0 }<br>
 =A0 =A0 }<br>
<br>
+ =A0 =A0d_config.b_info.u.hvm.no_increment_gid =3D dom_info-&gt;no_increme=
nt_gid;<br>
+<br>
 =A0 =A0 if (debug || dom_info-&gt;dryrun)<br>
 =A0 =A0 =A0 =A0 printf_info(-1, &amp;d_config, &amp;d_config.dm_info);<br>
<br>
@@ -2796,6 +2800,7 @@ static void migrate_receive(int debug, i<br>
 =A0 =A0 dom_info.restore_file =3D &quot;incoming migration stream&quot;;<b=
r>
 =A0 =A0 dom_info.migrate_fd =3D 0; /* stdin */<br>
 =A0 =A0 dom_info.migration_domname_r =3D &amp;migration_domname;<br>
+ =A0 =A0dom_info.no_increment_gid =3D 1;<br>
<br>
 =A0 =A0 rc =3D create_domain(&amp;dom_info);<br>
 =A0 =A0 if (rc &lt; 0) {<br>
diff -r 62ff6a318c5d -r de5432066adc tools/python/xen/lowlevel/checkpoint/l=
ibcheckpoint.c<br>
--- a/tools/python/xen/lowlevel/checkpoint/libcheckpoint.c =A0 =A0 =A0Wed N=
ov 30 16:59:58 2011 -0800<br>
+++ b/tools/python/xen/lowlevel/checkpoint/libcheckpoint.c =A0 =A0 =A0Fri D=
ec 02 14:42:17 2011 +0000<br>
@@ -174,6 +174,7 @@ int checkpoint_start(checkpoint_state* s<br>
=A0{<br>
 =A0 =A0 int hvm, rc;<br>
 =A0 =A0 int flags =3D XCFLAGS_LIVE;<br>
+ =A0 =A0unsigned long vm_gid_addr;<br>
<br>
 =A0 =A0 if (!s-&gt;domid) {<br>
 =A0 =A0 =A0 =A0s-&gt;errstr =3D &quot;checkpoint state not opened&quot;;<b=
r>
@@ -184,14 +185,25 @@ int checkpoint_start(checkpoint_state* s<br>
<br>
 =A0 =A0 hvm =3D s-&gt;domtype &gt; dt_pv;<br>
 =A0 =A0 if (hvm) {<br>
+ =A0 =A0 =A0 char path[128];<br>
+ =A0 =A0 =A0 char *addr;<br>
+<br>
+ =A0 =A0 =A0 sprintf(path, &quot;/local/domain/%u/data/generation-id&quot;=
, s-&gt;domid);<br>
+ =A0 =A0 =A0 addr =3D xs_read(s-&gt;xsh, XBT_NULL, path, NULL);<br>
+<br>
+ =A0 =A0 =A0 vm_gid_addr =3D (addr) ? strtoul(addr, NULL, 0) : 0;<br>
+ =A0 =A0 =A0 free(addr);<br>
+<br>
 =A0 =A0 =A0 =A0flags |=3D XCFLAGS_HVM;<br>
 =A0 =A0 =A0 =A0if (switch_qemu_logdirty(s, 1))<br>
 =A0 =A0 =A0 =A0 =A0 =A0return -1;<br>
+ =A0 =A0} else {<br>
+ =A0 =A0 =A0 vm_gid_addr =3D 0;<br>
 =A0 =A0 }<br>
<br>
 =A0 =A0 callbacks-&gt;switch_qemu_logdirty =3D noop_switch_logdirty;<br>
<br>
- =A0 =A0rc =3D xc_domain_save(s-&gt;xch, fd, s-&gt;domid, 0, 0, flags, cal=
lbacks, hvm);<br>
+ =A0 =A0rc =3D xc_domain_save(s-&gt;xch, fd, s-&gt;domid, 0, 0, flags, cal=
lbacks, hvm, vm_gid_addr);<br>
<br>
 =A0 =A0 if (hvm)<br>
 =A0 =A0 =A0 =A0switch_qemu_logdirty(s, 0);<br>
diff -r 62ff6a318c5d -r de5432066adc tools/xcutils/xc_restore.c<br>
--- a/tools/xcutils/xc_restore.c =A0 =A0 =A0 =A0Wed Nov 30 16:59:58 2011 -0=
800<br>
+++ b/tools/xcutils/xc_restore.c =A0 =A0 =A0 =A0Fri Dec 02 14:42:17 2011 +0=
000<br>
@@ -23,7 +23,8 @@ main(int argc, char **argv)<br>
 =A0 =A0 xc_interface *xch;<br>
 =A0 =A0 int io_fd, ret;<br>
 =A0 =A0 int superpages;<br>
- =A0 =A0unsigned long store_mfn, console_mfn;<br>
+ =A0 =A0unsigned long store_mfn, console_mfn, vm_gid_addr;<br>
+ =A0 =A0int no_increment_gid;<br>
<br>
 =A0 =A0 if ( (argc !=3D 8) &amp;&amp; (argc !=3D 9) )<br>
 =A0 =A0 =A0 =A0 errx(1, &quot;usage: %s iofd domid store_evtchn &quot;<br>
@@ -40,19 +41,25 @@ main(int argc, char **argv)<br>
 =A0 =A0 hvm =A0=3D atoi(argv[5]);<br>
 =A0 =A0 pae =A0=3D atoi(argv[6]);<br>
 =A0 =A0 apic =3D atoi(argv[7]);<br>
- =A0 =A0if ( argc =3D=3D 9 )<br>
+ =A0 =A0if ( argc &gt;=3D 9 )<br>
 =A0 =A0 =A0 =A0 =A0 =A0superpages =3D atoi(argv[8]);<br>
 =A0 =A0 else<br>
 =A0 =A0 =A0 =A0 =A0 =A0superpages =3D !!hvm;<br>
+ =A0 =A0if ( argc &gt;=3D 10 )<br>
+ =A0 =A0 =A0 =A0 =A0 no_increment_gid =3D !atoi(argv[9]);<br>
+ =A0 =A0else<br>
+ =A0 =A0 =A0 =A0 =A0 no_increment_gid =3D 0;<br>
<br>
 =A0 =A0 ret =3D xc_domain_restore(xch, io_fd, domid, store_evtchn, &amp;st=
ore_mfn,<br>
- =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0console_evtchn, &a=
mp;console_mfn, hvm, pae, superpages);<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0console_evtchn, &a=
mp;console_mfn, hvm, pae, superpages,<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0no_increment_gid, =
&amp;vm_gid_addr);<br>
<br>
 =A0 =A0 if ( ret =3D=3D 0 )<br>
 =A0 =A0 {<br>
 =A0 =A0 =A0 =A0printf(&quot;store-mfn %li\n&quot;, store_mfn);<br>
 =A0 =A0 =A0 =A0 if ( !hvm )<br>
 =A0 =A0 =A0 =A0 =A0 =A0 printf(&quot;console-mfn %li\n&quot;, console_mfn)=
;<br>
+ =A0 =A0 =A0 printf(&quot;vm-gid-addr %lx\n&quot;, vm_gid_addr);<br>
 =A0 =A0 =A0 =A0fflush(stdout);<br>
 =A0 =A0 }<br>
<br>
diff -r 62ff6a318c5d -r de5432066adc tools/xcutils/xc_save.c<br>
--- a/tools/xcutils/xc_save.c =A0 Wed Nov 30 16:59:58 2011 -0800<br>
+++ b/tools/xcutils/xc_save.c =A0 Fri Dec 02 14:42:17 2011 +0000<br>
@@ -169,6 +169,10 @@ main(int argc, char **argv)<br>
 =A0 =A0 unsigned int maxit, max_f;<br>
 =A0 =A0 int io_fd, ret, port;<br>
 =A0 =A0 struct save_callbacks callbacks;<br>
+ =A0 =A0char path[128];<br>
+ =A0 =A0struct xs_handle *xs;<br>
+ =A0 =A0char *addr;<br>
+ =A0 =A0unsigned long vm_gid_addr;<br>
<br>
 =A0 =A0 if (argc !=3D 6)<br>
 =A0 =A0 =A0 =A0 errx(1, &quot;usage: %s iofd domid maxit maxf flags&quot;,=
 argv[0]);<br>
@@ -207,8 +211,21 @@ main(int argc, char **argv)<br>
 =A0 =A0 memset(&amp;callbacks, 0, sizeof(callbacks));<br>
 =A0 =A0 callbacks.suspend =3D suspend;<br>
 =A0 =A0 callbacks.switch_qemu_logdirty =3D switch_qemu_logdirty;<br>
+<br>
+ =A0 =A0sprintf(path, &quot;/local/domain/%d/data/generation-id&quot;, si.=
domid);<br>
+<br>
+ =A0 =A0if ((xs =3D xs_daemon_open()) =3D=3D NULL)<br>
+ =A0 =A0 =A0 =A0errx(1, &quot;Couldn&#39;t contact xenstore&quot;);<br>
+<br>
+ =A0 =A0addr =3D xs_read(xs, XBT_NULL, path, NULL);<br>
+<br>
+ =A0 =A0xs_daemon_close(xs);<br>
+<br>
+ =A0 =A0vm_gid_addr =3D (addr) ? strtoul(addr, NULL, 0) : 0;<br>
+ =A0 =A0free(addr);<br>
+<br>
 =A0 =A0 ret =3D xc_domain_save(si.xch, io_fd, si.domid, maxit, max_f, si.f=
lags,<br>
- =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 &amp;callbacks, !!(si.fla=
gs &amp; XCFLAGS_HVM));<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 &amp;callbacks, !!(si.fla=
gs &amp; XCFLAGS_HVM), vm_gid_addr);<br>
<br>
 =A0 =A0 if (si.suspend_evtchn &gt; 0)<br>
 =A0 =A0 =A0 =A0 xc_suspend_evtchn_release(si.xch, si.xce, si.domid, si.sus=
pend_evtchn);<br>
<br>
_______________________________________________<br>
Xen-devel mailing list<br>
<a href=3D"mailto:Xen-devel@lists.xensource.com">Xen-devel@lists.xensource.=
com</a><br>
<a href=3D"http://lists.xensource.com/xen-devel" target=3D"_blank">http://l=
ists.xensource.com/xen-devel</a><br>
</blockquote></div><br>You might have to rebase the entire patch. <br>The c=
ompression patch (pushed
into staging just before you sent this one)<br>touches the same diff contex=
t that this=20
code does (esp. the SAVE_IDs, <br>code in xc_domain_restore, in tools/pytho=
n/xen/lowlevel/checkpoint/checkpoint.c, etc.)<br>
<br>Assuming that the latest regression in staging/xen-unstable is resolved=
, I think<br>most of this code wont apply cleanly.<br><br>shriram<br>

--000e0ce02ace6a457804b32ad04f--


--===============5984604066976982491==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============5984604066976982491==--


From xen-devel-bounces@lists.xensource.com Sat Dec 03 08:22:27 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 03 Dec 2011 08:22:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWkqn-0007ES-R5; Sat, 03 Dec 2011 08:21:37 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <thomas@m3y3r.de>) id 1RWkqm-0007EN-DG
	for xen-devel@lists.xensource.com; Sat, 03 Dec 2011 08:21:36 +0000
X-Env-Sender: thomas@m3y3r.de
X-Msg-Ref: server-10.tower-27.messagelabs.com!1322900422!46421602!1
X-Originating-IP: [213.133.104.17]
X-SpamReason: No, hits=0.9 required=7.0 tests=BODY_RANDOM_LONG,
	DATE_IN_PAST_48_96
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17141 invoked from network); 3 Dec 2011 08:20:23 -0000
Received: from www17.your-server.de (HELO www17.your-server.de)
	(213.133.104.17)
	by server-10.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Dec 2011 08:20:23 -0000
Received: from [84.59.33.154] (helo=[192.168.2.108])
	by www17.your-server.de with esmtpsa (SSLv3:AES256-SHA:256)
	(Exim 4.72) (envelope-from <thomas@m3y3r.de>)
	id 1RWkq6-0007IL-2B; Sat, 03 Dec 2011 09:20:54 +0100
From: Thomas Meyer <thomas@m3y3r.de>
To: xen-devel@lists.xensource.com,
	virtualization@lists.linux-foundation.org, linux-kernel@vger.kernel.org
Mime-Version: 1.0
Date: Tue, 29 Nov 2011 22:08:00 +0100
Message-ID: <1322600880.1534.293.camel@localhost.localdomain>
X-Mailer: Evolution 3.2.2 (3.2.2-1.fc16) 
X-Authenticated-Sender: thomas@m3y3r.de
X-Virus-Scanned: Clear (ClamAV 0.97.3/13904/Tue Nov  8 04:31:35 2011)
Subject: [Xen-devel] [PATCH] xen-blkfront: Use kcalloc instead of kzalloc to
 allocate array
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

The advantage of kcalloc is, that will prevent integer overflows which could
result from the multiplication of number of elements and size and it is also
a bit nicer to read.

The semantic patch that makes this change is available
in https://lkml.org/lkml/2011/11/25/107

Signed-off-by: Thomas Meyer <thomas@m3y3r.de>
---

diff -u -p a/drivers/block/cciss_scsi.c b/drivers/block/cciss_scsi.c
--- a/drivers/block/cciss_scsi.c 2011-11-28 19:36:47.343430551 +0100
+++ b/drivers/block/cciss_scsi.c 2011-11-28 19:49:24.922716381 +0100
@@ -534,10 +534,10 @@ adjust_cciss_scsi_table(ctlr_info_t *h,
 	int nadded, nremoved;
 	struct Scsi_Host *sh = NULL;
 
-	added = kzalloc(sizeof(*added) * CCISS_MAX_SCSI_DEVS_PER_HBA,
-			GFP_KERNEL);
-	removed = kzalloc(sizeof(*removed) * CCISS_MAX_SCSI_DEVS_PER_HBA,
+	added = kcalloc(CCISS_MAX_SCSI_DEVS_PER_HBA, sizeof(*added),
 			GFP_KERNEL);
+	removed = kcalloc(CCISS_MAX_SCSI_DEVS_PER_HBA, sizeof(*removed),
+			  GFP_KERNEL);
 
 	if (!added || !removed) {
 		dev_warn(&h->pdev->dev,
@@ -1191,8 +1191,8 @@ cciss_update_non_disk_devices(ctlr_info_
 
 	ld_buff = kzalloc(reportlunsize, GFP_KERNEL);
 	inq_buff = kmalloc(OBDR_TAPE_INQ_SIZE, GFP_KERNEL);
-	currentsd = kzalloc(sizeof(*currentsd) *
-			(CCISS_MAX_SCSI_DEVS_PER_HBA+1), GFP_KERNEL);
+	currentsd = kcalloc(CCISS_MAX_SCSI_DEVS_PER_HBA + 1,
+			    sizeof(*currentsd), GFP_KERNEL);
 	if (ld_buff == NULL || inq_buff == NULL || currentsd == NULL) {
 		printk(KERN_ERR "cciss: out of memory\n");
 		goto out;
diff -u -p a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
--- a/drivers/block/xen-blkfront.c 2011-11-13 11:07:22.680095573 +0100
+++ b/drivers/block/xen-blkfront.c 2011-11-28 19:49:29.109460410 +0100
@@ -156,7 +156,7 @@ static int xlbd_reserve_minors(unsigned
 	if (end > nr_minors) {
 		unsigned long *bitmap, *old;
 
-		bitmap = kzalloc(BITS_TO_LONGS(end) * sizeof(*bitmap),
+		bitmap = kcalloc(BITS_TO_LONGS(end), sizeof(*bitmap),
 				 GFP_KERNEL);
 		if (bitmap == NULL)
 			return -ENOMEM;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Dec 03 08:22:27 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 03 Dec 2011 08:22:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWkqn-0007ES-R5; Sat, 03 Dec 2011 08:21:37 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <thomas@m3y3r.de>) id 1RWkqm-0007EN-DG
	for xen-devel@lists.xensource.com; Sat, 03 Dec 2011 08:21:36 +0000
X-Env-Sender: thomas@m3y3r.de
X-Msg-Ref: server-10.tower-27.messagelabs.com!1322900422!46421602!1
X-Originating-IP: [213.133.104.17]
X-SpamReason: No, hits=0.9 required=7.0 tests=BODY_RANDOM_LONG,
	DATE_IN_PAST_48_96
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17141 invoked from network); 3 Dec 2011 08:20:23 -0000
Received: from www17.your-server.de (HELO www17.your-server.de)
	(213.133.104.17)
	by server-10.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Dec 2011 08:20:23 -0000
Received: from [84.59.33.154] (helo=[192.168.2.108])
	by www17.your-server.de with esmtpsa (SSLv3:AES256-SHA:256)
	(Exim 4.72) (envelope-from <thomas@m3y3r.de>)
	id 1RWkq6-0007IL-2B; Sat, 03 Dec 2011 09:20:54 +0100
From: Thomas Meyer <thomas@m3y3r.de>
To: xen-devel@lists.xensource.com,
	virtualization@lists.linux-foundation.org, linux-kernel@vger.kernel.org
Mime-Version: 1.0
Date: Tue, 29 Nov 2011 22:08:00 +0100
Message-ID: <1322600880.1534.293.camel@localhost.localdomain>
X-Mailer: Evolution 3.2.2 (3.2.2-1.fc16) 
X-Authenticated-Sender: thomas@m3y3r.de
X-Virus-Scanned: Clear (ClamAV 0.97.3/13904/Tue Nov  8 04:31:35 2011)
Subject: [Xen-devel] [PATCH] xen-blkfront: Use kcalloc instead of kzalloc to
 allocate array
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

The advantage of kcalloc is, that will prevent integer overflows which could
result from the multiplication of number of elements and size and it is also
a bit nicer to read.

The semantic patch that makes this change is available
in https://lkml.org/lkml/2011/11/25/107

Signed-off-by: Thomas Meyer <thomas@m3y3r.de>
---

diff -u -p a/drivers/block/cciss_scsi.c b/drivers/block/cciss_scsi.c
--- a/drivers/block/cciss_scsi.c 2011-11-28 19:36:47.343430551 +0100
+++ b/drivers/block/cciss_scsi.c 2011-11-28 19:49:24.922716381 +0100
@@ -534,10 +534,10 @@ adjust_cciss_scsi_table(ctlr_info_t *h,
 	int nadded, nremoved;
 	struct Scsi_Host *sh = NULL;
 
-	added = kzalloc(sizeof(*added) * CCISS_MAX_SCSI_DEVS_PER_HBA,
-			GFP_KERNEL);
-	removed = kzalloc(sizeof(*removed) * CCISS_MAX_SCSI_DEVS_PER_HBA,
+	added = kcalloc(CCISS_MAX_SCSI_DEVS_PER_HBA, sizeof(*added),
 			GFP_KERNEL);
+	removed = kcalloc(CCISS_MAX_SCSI_DEVS_PER_HBA, sizeof(*removed),
+			  GFP_KERNEL);
 
 	if (!added || !removed) {
 		dev_warn(&h->pdev->dev,
@@ -1191,8 +1191,8 @@ cciss_update_non_disk_devices(ctlr_info_
 
 	ld_buff = kzalloc(reportlunsize, GFP_KERNEL);
 	inq_buff = kmalloc(OBDR_TAPE_INQ_SIZE, GFP_KERNEL);
-	currentsd = kzalloc(sizeof(*currentsd) *
-			(CCISS_MAX_SCSI_DEVS_PER_HBA+1), GFP_KERNEL);
+	currentsd = kcalloc(CCISS_MAX_SCSI_DEVS_PER_HBA + 1,
+			    sizeof(*currentsd), GFP_KERNEL);
 	if (ld_buff == NULL || inq_buff == NULL || currentsd == NULL) {
 		printk(KERN_ERR "cciss: out of memory\n");
 		goto out;
diff -u -p a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
--- a/drivers/block/xen-blkfront.c 2011-11-13 11:07:22.680095573 +0100
+++ b/drivers/block/xen-blkfront.c 2011-11-28 19:49:29.109460410 +0100
@@ -156,7 +156,7 @@ static int xlbd_reserve_minors(unsigned
 	if (end > nr_minors) {
 		unsigned long *bitmap, *old;
 
-		bitmap = kzalloc(BITS_TO_LONGS(end) * sizeof(*bitmap),
+		bitmap = kcalloc(BITS_TO_LONGS(end), sizeof(*bitmap),
 				 GFP_KERNEL);
 		if (bitmap == NULL)
 			return -ENOMEM;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Dec 03 10:45:51 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 03 Dec 2011 10:45:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWn5Z-0007qk-V0; Sat, 03 Dec 2011 10:45:01 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RWn5X-0007qf-NK
	for xen-devel@lists.xensource.com; Sat, 03 Dec 2011 10:44:59 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1322909057!4069833!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjAxMw==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29883 invoked from network); 3 Dec 2011 10:44:17 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Dec 2011 10:44:17 -0000
X-IronPort-AV: E=Sophos;i="4.71,289,1320624000"; 
   d="scan'208";a="9266275"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Dec 2011 10:44:16 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Sat, 3 Dec 2011
	10:44:16 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Alex Bligh <alex@alex.org.uk>
In-Reply-To: <12E319EEAA44FEB965D8F001@Ximines.local>
References: <4ED798B2.1040309@canonical.com>
	<20111201180944.GH12984@reaktio.net>	<4ED8A45A.3050403@canonical.com>
	<20111202104110.GL12984@reaktio.net>
	<BA1B675D85BDD87795D1666C@Ximines.local>
	<1322844048.29870.155.camel@zakaz.uk.xensource.com>
	<8D88C4D6C31A598129A942AD@Ximines.local>
	<1322847755.7376.45.camel@dagon.hellion.org.uk>
	<12E319EEAA44FEB965D8F001@Ximines.local>
Organization: Citrix Systems, Inc.
Date: Sat, 3 Dec 2011 10:44:15 +0000
Message-ID: <1322909055.7376.56.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
X-Mailer: Evolution 2.32.3 
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefan Bader <stefan.bader@canonical.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Xen 4.x / Linux 3.x (dom0 and HVM domU) and	NIC
 handling
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2011-12-02 at 18:32 +0000, Alex Bligh wrote:
> Ian,
> 
> --On 2 December 2011 17:42:35 +0000 Ian Campbell <Ian.Campbell@citrix.com> 
> wrote:
> 
> > Right.
> >
> >> FWIW my experience is that various built-for-cloud type distros don't use
> >> that scheme, mainly because they use grub1 which IIRC does not support
> >> this, and building images in a non-root environment that have grub1
> >> in is rather easier than grub2.
> >
> > UUID= and LABEL= are functions of your initrd (actually udev) and not
> > the bootloader. They work with both grub1 and grub2.
> 
> I /think/ we might be slightly at cross purposes.
> 
> At least when I was busy making images for Xen for PVHVM a couple of
> years ago, the problem is roughly as follows:
> 
> The boot loader needs to know what device to load the kernel and initrd 
> from. To do this (roughly speaking) it needs to know what BIOS device to 
> use. Of course it does not matter whether the boot loader uses the PV 
> device or the emulated device, save that this requires the emulated device 
> be present (at least whilst the boot loader doesn't support drivers for the 
> pv device). The problem is that the device the boot loader accesses is in 
> general specified in the boot loader configuration file not as a bios 
> device number, but as a device name. Equally, it needs to know the device 
> so that it can write the boot sector in order to reinstall the boot loader, 
> set options etc. The problem we ran into here was that this needs to be set 
> to xvda in order to to write the boot sector etc., because the sda device 
> is unplugged. However, it only recognised a BIOS mapping for sda. So 
> neither worked, without fiddling with mappings, but that wasn't possible on 
> a straight install. For some reason, grub1 was far more forgiving.

grub-install /dev/xvdX is supposed to work just as well as
grub-install /dev/sdX depending on which is currently active. If it does
not then you have found a bug and this should be reported against the
grub package in the distro you are using.

This was fixed in grub 1 in Debian Lenny (#456776) and grub2 in Debian
Squeeze (#456777). The grub2 fixes are upstream however grub1 doesn't
have an upstream so other distros may be missing this fix. If you find
this please report it to them. Likewise if you find that this support
has regressed in Debian (or Ubuntu) then please report those bugs to
them.

Please don't just assume that because something is broken for you that
this is the way it must be. Report bugs to the appropriate place and
there is some chance that they will get fixed. Likewise if something was
broken for you "years ago" please don't assume that it has remained so.

> >> So, for instance, all the vm-builder stuff in debian/ubuntu used grub1
> >> and did not work this way.
> >
> > Which ones are these?
> 
> EG:
>  http://packages.ubuntu.com/search?keywords=ubuntu-vm-builder
>  http://wiki.debian.org/VMBuilder
> 
> > The Debian installer uses UUID where it can AFAIK. Ubuntu's installer is
> > derived from Debian's so I'd expect it to be the same.
> 
> There is more than one method of generating debian/ubuntu images
> (debootstrap, multistrap, vmbuilder to name but 3). Some of these
> run an installer, some just generate a working image for a particular
> environment (and it's the latter which are problematic).

If a tools such as these are not correctly generating a PVHVM capable
configuration when possible then IMHO that is a bug in those tools.
Please report it to the tool authors as such.

If you cannot flip between PVHVM and emulated HVM easily then IMHO this
is also a bug (although perhaps less serious) and should be reported as
such, perhaps as a wishlist bug.

> FWIW my understanding is that though Ubuntu and Debian's installers both 
> use the same underlying d-i stuff (or used to), they are now reasonably 
> different (not that this has much bearing on the argument, as the main 
> difference between the two is the kernel which has led to rather different 
> results between the two); certainly which boot loader they use is
> independent of the install architecture, their partitioning schemes
> have been substantially different, and I would expect use of UUID/LABEL
> not necessarily to correspond.

The Ubuntu installer folks are closely involved in Debian installer and
in particular the folks who deal with bootloader type things on both
sides are the same people.

Ian.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Dec 03 10:45:51 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 03 Dec 2011 10:45:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWn5Z-0007qk-V0; Sat, 03 Dec 2011 10:45:01 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RWn5X-0007qf-NK
	for xen-devel@lists.xensource.com; Sat, 03 Dec 2011 10:44:59 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1322909057!4069833!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjAxMw==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29883 invoked from network); 3 Dec 2011 10:44:17 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Dec 2011 10:44:17 -0000
X-IronPort-AV: E=Sophos;i="4.71,289,1320624000"; 
   d="scan'208";a="9266275"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Dec 2011 10:44:16 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Sat, 3 Dec 2011
	10:44:16 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Alex Bligh <alex@alex.org.uk>
In-Reply-To: <12E319EEAA44FEB965D8F001@Ximines.local>
References: <4ED798B2.1040309@canonical.com>
	<20111201180944.GH12984@reaktio.net>	<4ED8A45A.3050403@canonical.com>
	<20111202104110.GL12984@reaktio.net>
	<BA1B675D85BDD87795D1666C@Ximines.local>
	<1322844048.29870.155.camel@zakaz.uk.xensource.com>
	<8D88C4D6C31A598129A942AD@Ximines.local>
	<1322847755.7376.45.camel@dagon.hellion.org.uk>
	<12E319EEAA44FEB965D8F001@Ximines.local>
Organization: Citrix Systems, Inc.
Date: Sat, 3 Dec 2011 10:44:15 +0000
Message-ID: <1322909055.7376.56.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
X-Mailer: Evolution 2.32.3 
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefan Bader <stefan.bader@canonical.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Xen 4.x / Linux 3.x (dom0 and HVM domU) and	NIC
 handling
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2011-12-02 at 18:32 +0000, Alex Bligh wrote:
> Ian,
> 
> --On 2 December 2011 17:42:35 +0000 Ian Campbell <Ian.Campbell@citrix.com> 
> wrote:
> 
> > Right.
> >
> >> FWIW my experience is that various built-for-cloud type distros don't use
> >> that scheme, mainly because they use grub1 which IIRC does not support
> >> this, and building images in a non-root environment that have grub1
> >> in is rather easier than grub2.
> >
> > UUID= and LABEL= are functions of your initrd (actually udev) and not
> > the bootloader. They work with both grub1 and grub2.
> 
> I /think/ we might be slightly at cross purposes.
> 
> At least when I was busy making images for Xen for PVHVM a couple of
> years ago, the problem is roughly as follows:
> 
> The boot loader needs to know what device to load the kernel and initrd 
> from. To do this (roughly speaking) it needs to know what BIOS device to 
> use. Of course it does not matter whether the boot loader uses the PV 
> device or the emulated device, save that this requires the emulated device 
> be present (at least whilst the boot loader doesn't support drivers for the 
> pv device). The problem is that the device the boot loader accesses is in 
> general specified in the boot loader configuration file not as a bios 
> device number, but as a device name. Equally, it needs to know the device 
> so that it can write the boot sector in order to reinstall the boot loader, 
> set options etc. The problem we ran into here was that this needs to be set 
> to xvda in order to to write the boot sector etc., because the sda device 
> is unplugged. However, it only recognised a BIOS mapping for sda. So 
> neither worked, without fiddling with mappings, but that wasn't possible on 
> a straight install. For some reason, grub1 was far more forgiving.

grub-install /dev/xvdX is supposed to work just as well as
grub-install /dev/sdX depending on which is currently active. If it does
not then you have found a bug and this should be reported against the
grub package in the distro you are using.

This was fixed in grub 1 in Debian Lenny (#456776) and grub2 in Debian
Squeeze (#456777). The grub2 fixes are upstream however grub1 doesn't
have an upstream so other distros may be missing this fix. If you find
this please report it to them. Likewise if you find that this support
has regressed in Debian (or Ubuntu) then please report those bugs to
them.

Please don't just assume that because something is broken for you that
this is the way it must be. Report bugs to the appropriate place and
there is some chance that they will get fixed. Likewise if something was
broken for you "years ago" please don't assume that it has remained so.

> >> So, for instance, all the vm-builder stuff in debian/ubuntu used grub1
> >> and did not work this way.
> >
> > Which ones are these?
> 
> EG:
>  http://packages.ubuntu.com/search?keywords=ubuntu-vm-builder
>  http://wiki.debian.org/VMBuilder
> 
> > The Debian installer uses UUID where it can AFAIK. Ubuntu's installer is
> > derived from Debian's so I'd expect it to be the same.
> 
> There is more than one method of generating debian/ubuntu images
> (debootstrap, multistrap, vmbuilder to name but 3). Some of these
> run an installer, some just generate a working image for a particular
> environment (and it's the latter which are problematic).

If a tools such as these are not correctly generating a PVHVM capable
configuration when possible then IMHO that is a bug in those tools.
Please report it to the tool authors as such.

If you cannot flip between PVHVM and emulated HVM easily then IMHO this
is also a bug (although perhaps less serious) and should be reported as
such, perhaps as a wishlist bug.

> FWIW my understanding is that though Ubuntu and Debian's installers both 
> use the same underlying d-i stuff (or used to), they are now reasonably 
> different (not that this has much bearing on the argument, as the main 
> difference between the two is the kernel which has led to rather different 
> results between the two); certainly which boot loader they use is
> independent of the install architecture, their partitioning schemes
> have been substantially different, and I would expect use of UUID/LABEL
> not necessarily to correspond.

The Ubuntu installer folks are closely involved in Debian installer and
in particular the folks who deal with bootloader type things on both
sides are the same people.

Ian.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Dec 03 13:53:48 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 03 Dec 2011 13:53:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWq1O-0000Lf-Ku; Sat, 03 Dec 2011 13:52:54 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RWq1N-0000La-3R
	for xen-devel@lists.xensource.com; Sat, 03 Dec 2011 13:52:53 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1322920329!6035187!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjAxMw==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13373 invoked from network); 3 Dec 2011 13:52:09 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Dec 2011 13:52:09 -0000
X-IronPort-AV: E=Sophos;i="4.71,289,1320624000"; 
   d="scan'208";a="9267072"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Dec 2011 13:52:08 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sat, 3 Dec 2011 13:52:08 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RWq0d-0002Hy-UD;
	Sat, 03 Dec 2011 13:52:07 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RWq0d-0000d9-TS;
	Sat, 03 Dec 2011 13:52:07 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10289-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 3 Dec 2011 13:52:07 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10289: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10289 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10289/

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-i386-xl-winxpsp3-vcpus1  4 xen-install         fail REGR. vs. 10201
 test-amd64-i386-xl-win7-amd64  4 xen-install              fail REGR. vs. 10201
 test-amd64-i386-xend-winxpsp3  4 xen-install              fail REGR. vs. 10201
 test-amd64-i386-pv            4 xen-install               fail REGR. vs. 10201
 test-amd64-i386-xl-multivcpu  4 xen-install               fail REGR. vs. 10201
 test-amd64-i386-xl            4 xen-install               fail REGR. vs. 10201
 test-amd64-i386-pair          6 xen-install/dst_host      fail REGR. vs. 10201
 test-amd64-i386-pair          5 xen-install/src_host      fail REGR. vs. 10201
 build-i386                    4 xen-build                 fail REGR. vs. 10201
 build-i386-oldkern            4 xen-build                 fail REGR. vs. 10201
 test-amd64-i386-rhel6hvm-intel  4 xen-install             fail REGR. vs. 10201
 test-amd64-i386-rhel6hvm-amd  4 xen-install               fail REGR. vs. 10201
 test-amd64-i386-xl-credit2    4 xen-install               fail REGR. vs. 10201
 test-amd64-amd64-win          8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-amd64-xl-win       8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-i386-win-vcpus1    4 xen-install               fail REGR. vs. 10201
 test-amd64-i386-win           4 xen-install               fail REGR. vs. 10201
 test-amd64-i386-xl-win-vcpus1  4 xen-install              fail REGR. vs. 10201

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf     14 guest-localmigrate/x10      fail pass in 10264

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-win7-amd64  7 windows-install              fail never pass
 test-i386-i386-xl-winxpsp3    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-i386-i386-pv             1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl             1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pair           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   never pass
 test-i386-i386-win            1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-win         1 xen-build-check(1)           blocked  n/a

version targeted for testing:
 xen                  a4d7c27ec1f1
baseline version:
 xen                  62ff6a318c5d

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Anthony PERARD <anthony.perard@citrix.com>
  Brendan Cully <brendan@cs.ubc.ca>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@novell.com>
  Jan Beulich <jbeulich@suse.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Jonathan Davies <jonathan.davies@citrix.com>
  juergen.gross@ts.fujitsu.com
  Keir Fraser <keir@xen.org>
  Liu, Jinsong <jinsong.liu@intel.com>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
  Philipp Hahn <hahn@univention.de>
  Shriram Rajagopalan <rshriram@cs.ubc.ca>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang2 <wei.wang2@amd.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   fail    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           fail    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           fail    
 test-i386-i386-xl                                            blocked 
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-i386-i386-pair                                          blocked 
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           fail    
 test-i386-i386-pv                                            blocked 
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           blocked 
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        blocked 
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   blocked 


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 1262 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Dec 03 13:53:48 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 03 Dec 2011 13:53:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWq1O-0000Lf-Ku; Sat, 03 Dec 2011 13:52:54 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RWq1N-0000La-3R
	for xen-devel@lists.xensource.com; Sat, 03 Dec 2011 13:52:53 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1322920329!6035187!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjAxMw==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13373 invoked from network); 3 Dec 2011 13:52:09 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Dec 2011 13:52:09 -0000
X-IronPort-AV: E=Sophos;i="4.71,289,1320624000"; 
   d="scan'208";a="9267072"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Dec 2011 13:52:08 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sat, 3 Dec 2011 13:52:08 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RWq0d-0002Hy-UD;
	Sat, 03 Dec 2011 13:52:07 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RWq0d-0000d9-TS;
	Sat, 03 Dec 2011 13:52:07 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10289-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 3 Dec 2011 13:52:07 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10289: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10289 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10289/

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-i386-xl-winxpsp3-vcpus1  4 xen-install         fail REGR. vs. 10201
 test-amd64-i386-xl-win7-amd64  4 xen-install              fail REGR. vs. 10201
 test-amd64-i386-xend-winxpsp3  4 xen-install              fail REGR. vs. 10201
 test-amd64-i386-pv            4 xen-install               fail REGR. vs. 10201
 test-amd64-i386-xl-multivcpu  4 xen-install               fail REGR. vs. 10201
 test-amd64-i386-xl            4 xen-install               fail REGR. vs. 10201
 test-amd64-i386-pair          6 xen-install/dst_host      fail REGR. vs. 10201
 test-amd64-i386-pair          5 xen-install/src_host      fail REGR. vs. 10201
 build-i386                    4 xen-build                 fail REGR. vs. 10201
 build-i386-oldkern            4 xen-build                 fail REGR. vs. 10201
 test-amd64-i386-rhel6hvm-intel  4 xen-install             fail REGR. vs. 10201
 test-amd64-i386-rhel6hvm-amd  4 xen-install               fail REGR. vs. 10201
 test-amd64-i386-xl-credit2    4 xen-install               fail REGR. vs. 10201
 test-amd64-amd64-win          8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-amd64-xl-win       8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-i386-win-vcpus1    4 xen-install               fail REGR. vs. 10201
 test-amd64-i386-win           4 xen-install               fail REGR. vs. 10201
 test-amd64-i386-xl-win-vcpus1  4 xen-install              fail REGR. vs. 10201

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf     14 guest-localmigrate/x10      fail pass in 10264

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-win7-amd64  7 windows-install              fail never pass
 test-i386-i386-xl-winxpsp3    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-i386-i386-pv             1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl             1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pair           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   never pass
 test-i386-i386-win            1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-win         1 xen-build-check(1)           blocked  n/a

version targeted for testing:
 xen                  a4d7c27ec1f1
baseline version:
 xen                  62ff6a318c5d

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Anthony PERARD <anthony.perard@citrix.com>
  Brendan Cully <brendan@cs.ubc.ca>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@novell.com>
  Jan Beulich <jbeulich@suse.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Jonathan Davies <jonathan.davies@citrix.com>
  juergen.gross@ts.fujitsu.com
  Keir Fraser <keir@xen.org>
  Liu, Jinsong <jinsong.liu@intel.com>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
  Philipp Hahn <hahn@univention.de>
  Shriram Rajagopalan <rshriram@cs.ubc.ca>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang2 <wei.wang2@amd.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   fail    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           fail    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           fail    
 test-i386-i386-xl                                            blocked 
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-i386-i386-pair                                          blocked 
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           fail    
 test-i386-i386-pv                                            blocked 
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           blocked 
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        blocked 
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   blocked 


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 1262 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Dec 03 14:43:25 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 03 Dec 2011 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.xensource.com>)
	id 1RWqn2-0000ic-CQ; Sat, 03 Dec 2011 14:42:08 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RWqn0-0000i7-M8
	for xen-devel@lists.xensource.com; Sat, 03 Dec 2011 14:42:06 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1322923282!6013409!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDMxMjEy\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3367 invoked from network); 3 Dec 2011 14:41:24 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-6.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Dec 2011 14:41:24 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pB3EfLYA030945
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sat, 3 Dec 2011 14:41:21 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pB3EfKtS009029
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Sat, 3 Dec 2011 14:41:20 GMT
Received: from abhmt116.oracle.com (abhmt116.oracle.com [141.146.116.68])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pB3EfEMj030871; Sat, 3 Dec 2011 08:41:14 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Sat, 03 Dec 2011 06:41:14 -0800
Received: from phenom.dumpdata.com (localhost.localdomain [127.0.0.1])
	by phenom.dumpdata.com (Postfix) with ESMTP id 0C9D541C3D;
	Thu,  1 Dec 2011 14:10:32 -0500 (EST)
Received: (from konrad@localhost)
	by phenom.dumpdata.com (8.14.5/8.14.5/Submit) id pB1JAV1o010851;
	Thu, 1 Dec 2011 14:10:31 -0500
Date: Thu, 1 Dec 2011 14:10:31 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "Christopher S. Aker" <caker@theshore.net>
Message-ID: <20111201191031.GB10824@phenom.dumpdata.com>
References: <4EA71270.2050303@theshore.net>
	<20111025201239.GA13747@phenom.dumpdata.com>
	<BCD23F9B-BB0B-429B-882C-80077B1D234F@theshore.net>
	<20111025211512.GA2561@phenom.dumpdata.com>
	<4EA86D00.1080906@theshore.net>
	<20111026203652.GA10737@phenom.dumpdata.com>
	<4EA87A5C.6060100@theshore.net>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4EA87A5C.6060100@theshore.net>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090207.4EDA3512.0009,ss=1,re=0.000,fgs=0
Cc: xen devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Linux 3.1 domU + ext3 = WARNING: at fs/ext3/inode.c
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Oct 26, 2011 at 05:23:40PM -0400, Christopher S. Aker wrote:
> On 10/26/11 4:36 PM, Konrad Rzeszutek Wilk wrote:
> > I am going to bet that if you compile 3.0.4 or 3.0.6 with that
> > fancy new config option that turns EXT3_ORDERED_something you will
> > see the same exact problem.
> 
> Switching that back to match my 3.0 config is the first thing I
> tried, with no joy.
> 
> I'll reset and try a few more ideas...

I think I know what the problem is. I believe you need the patch below
in your hosts that are using the older dom0. AT least that solved the problem
for me when I tried to use a 2.6.18 based dom0 with a 3.0 kernel
with barriers. If you are using the linux-2.6.18.hg tree you might want
to just pull it and rebuild it - it has this patch already.

# HG changeset patch
From: Jan Beulich <jbeulich@novell.com>
# Date 1306409621 -3600
# Node ID 876a5aaac0264cf38cae6581e5714b93ec380aaa
# Parent  aedb712c05cf065e943e15d0f38597c2e80f7982
Subject: xen/blkback: don't fail empty barrier requests

The sector number on empty barrier requests may (will?) be
uninitialized (neither bio_init() nor rq_init() set the respective
fields), which allows for exceeding the actual (virtual) disk's size.

Inspired by Konrad's "When writting barriers set the sector number to
zero...", but instead of zapping the sector number (which is wrong for
non-empty ones) just ignore the sector number when the sector count is
zero.

While at it also add overflow checking to the math in vbd_translate().

Signed-off-by: Jan Beulich <jbeulich@novell.com>

diff -r aedb712c05cf -r 876a5aaac026 drivers/xen/blkback/vbd.c
--- a/drivers/xen/blkback/vbd.c	Thu May 26 08:09:04 2011 +0100
+++ b/drivers/xen/blkback/vbd.c	Thu May 26 12:33:41 2011 +0100
@@ -108,8 +108,14 @@ int vbd_translate(struct phys_req *req, 
 	if ((operation != READ) && vbd->readonly)
 		goto out;
 
-	if (unlikely((req->sector_number + req->nr_sects) > vbd_sz(vbd)))
-		goto out;
+	if (likely(req->nr_sects)) {
+		blkif_sector_t end = req->sector_number + req->nr_sects;
+
+		if (unlikely(end < req->sector_number))
+			goto out;
+		if (unlikely(end > vbd_sz(vbd)))
+			goto out;
+	}
 
 	req->dev  = vbd->pdevice;
 	req->bdev = vbd->bdev;
> 
> -Chris

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Dec 03 14:43:25 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 03 Dec 2011 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.xensource.com>)
	id 1RWqn2-0000ic-CQ; Sat, 03 Dec 2011 14:42:08 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RWqn0-0000i7-M8
	for xen-devel@lists.xensource.com; Sat, 03 Dec 2011 14:42:06 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1322923282!6013409!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDMxMjEy\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3367 invoked from network); 3 Dec 2011 14:41:24 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-6.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Dec 2011 14:41:24 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pB3EfLYA030945
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sat, 3 Dec 2011 14:41:21 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pB3EfKtS009029
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Sat, 3 Dec 2011 14:41:20 GMT
Received: from abhmt116.oracle.com (abhmt116.oracle.com [141.146.116.68])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pB3EfEMj030871; Sat, 3 Dec 2011 08:41:14 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Sat, 03 Dec 2011 06:41:14 -0800
Received: from phenom.dumpdata.com (localhost.localdomain [127.0.0.1])
	by phenom.dumpdata.com (Postfix) with ESMTP id 0C9D541C3D;
	Thu,  1 Dec 2011 14:10:32 -0500 (EST)
Received: (from konrad@localhost)
	by phenom.dumpdata.com (8.14.5/8.14.5/Submit) id pB1JAV1o010851;
	Thu, 1 Dec 2011 14:10:31 -0500
Date: Thu, 1 Dec 2011 14:10:31 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "Christopher S. Aker" <caker@theshore.net>
Message-ID: <20111201191031.GB10824@phenom.dumpdata.com>
References: <4EA71270.2050303@theshore.net>
	<20111025201239.GA13747@phenom.dumpdata.com>
	<BCD23F9B-BB0B-429B-882C-80077B1D234F@theshore.net>
	<20111025211512.GA2561@phenom.dumpdata.com>
	<4EA86D00.1080906@theshore.net>
	<20111026203652.GA10737@phenom.dumpdata.com>
	<4EA87A5C.6060100@theshore.net>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4EA87A5C.6060100@theshore.net>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090207.4EDA3512.0009,ss=1,re=0.000,fgs=0
Cc: xen devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Linux 3.1 domU + ext3 = WARNING: at fs/ext3/inode.c
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Oct 26, 2011 at 05:23:40PM -0400, Christopher S. Aker wrote:
> On 10/26/11 4:36 PM, Konrad Rzeszutek Wilk wrote:
> > I am going to bet that if you compile 3.0.4 or 3.0.6 with that
> > fancy new config option that turns EXT3_ORDERED_something you will
> > see the same exact problem.
> 
> Switching that back to match my 3.0 config is the first thing I
> tried, with no joy.
> 
> I'll reset and try a few more ideas...

I think I know what the problem is. I believe you need the patch below
in your hosts that are using the older dom0. AT least that solved the problem
for me when I tried to use a 2.6.18 based dom0 with a 3.0 kernel
with barriers. If you are using the linux-2.6.18.hg tree you might want
to just pull it and rebuild it - it has this patch already.

# HG changeset patch
From: Jan Beulich <jbeulich@novell.com>
# Date 1306409621 -3600
# Node ID 876a5aaac0264cf38cae6581e5714b93ec380aaa
# Parent  aedb712c05cf065e943e15d0f38597c2e80f7982
Subject: xen/blkback: don't fail empty barrier requests

The sector number on empty barrier requests may (will?) be
uninitialized (neither bio_init() nor rq_init() set the respective
fields), which allows for exceeding the actual (virtual) disk's size.

Inspired by Konrad's "When writting barriers set the sector number to
zero...", but instead of zapping the sector number (which is wrong for
non-empty ones) just ignore the sector number when the sector count is
zero.

While at it also add overflow checking to the math in vbd_translate().

Signed-off-by: Jan Beulich <jbeulich@novell.com>

diff -r aedb712c05cf -r 876a5aaac026 drivers/xen/blkback/vbd.c
--- a/drivers/xen/blkback/vbd.c	Thu May 26 08:09:04 2011 +0100
+++ b/drivers/xen/blkback/vbd.c	Thu May 26 12:33:41 2011 +0100
@@ -108,8 +108,14 @@ int vbd_translate(struct phys_req *req, 
 	if ((operation != READ) && vbd->readonly)
 		goto out;
 
-	if (unlikely((req->sector_number + req->nr_sects) > vbd_sz(vbd)))
-		goto out;
+	if (likely(req->nr_sects)) {
+		blkif_sector_t end = req->sector_number + req->nr_sects;
+
+		if (unlikely(end < req->sector_number))
+			goto out;
+		if (unlikely(end > vbd_sz(vbd)))
+			goto out;
+	}
 
 	req->dev  = vbd->pdevice;
 	req->bdev = vbd->bdev;
> 
> -Chris

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Dec 03 14:43:46 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 03 Dec 2011 14:43:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWqmz-0000iD-K1; Sat, 03 Dec 2011 14:42:05 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RWqmy-0000i6-TG
	for xen-devel@lists.xensource.com; Sat, 03 Dec 2011 14:42:05 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1322923281!4117323!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQyNzM2Mw==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13745 invoked from network); 3 Dec 2011 14:41:22 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-11.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 3 Dec 2011 14:41:22 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pB3EfI5S013434
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sat, 3 Dec 2011 14:41:19 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pB3EfHJ0006111
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Sat, 3 Dec 2011 14:41:18 GMT
Received: from abhmt112.oracle.com (abhmt112.oracle.com [141.146.116.64])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pB3EfCTB030865; Sat, 3 Dec 2011 08:41:12 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Sat, 03 Dec 2011 06:41:12 -0800
Received: from phenom.dumpdata.com (localhost.localdomain [127.0.0.1])
	by phenom.dumpdata.com (Postfix) with ESMTP id DD40841C3C;
	Thu,  1 Dec 2011 14:08:13 -0500 (EST)
Received: (from konrad@localhost)
	by phenom.dumpdata.com (8.14.5/8.14.5/Submit) id pB1J8DA3010836;
	Thu, 1 Dec 2011 14:08:13 -0500
Date: Thu, 1 Dec 2011 14:08:13 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Marek Marczykowski <marmarek@mimuw.edu.pl>
Message-ID: <20111201190813.GA10824@phenom.dumpdata.com>
References: <4E6357C6.6050101@mimuw.edu.pl>
	<20110906163213.GC5264@dumpdata.com>
	<4E665572.7080009@mimuw.edu.pl>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4E665572.7080009@mimuw.edu.pl>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090205.4EDA3510.0011,ss=1,re=0.000,fgs=0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] blkfront problem in pvops kernel when barriers
 enabled
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Sep 06, 2011 at 07:16:34PM +0200, Marek Marczykowski wrote:
> On 06.09.2011 18:32, Konrad Rzeszutek Wilk wrote:
> > On Sun, Sep 04, 2011 at 12:49:42PM +0200, Marek Marczykowski wrote:
> >> Hello,
> >>
> >> Pvops block frontend (tested vanilla 3.0.3, 3.1rc2, Konrad's testing
> >> branch) produces a lot of I/O errors when barriers are enabled but
> >> cannot be used.
> >>
> >> On xenlinux I've got message:
> >> [   15.036921] blkfront: xvdb: empty write barrier op failed
> >> [   15.036936] blkfront: xvdb: barriers disabled
> >>
> >> and after that, everything works fine. On pvops - I/O errors.
> >> As backend I've used 2.6.38.3 xenlinux (based on SUSE package) and
> >> 3.1rc2 with same result.
> > 
> > Hm, and the 'feature-barrier' was enabled on in those backends?
> > That is really bizzare considering that those backends don't actually
> > support WRITE_BARRIER anymore.
> 
> At least in 2.6.38.3 xenlinux  (SUSE). Now I'm not sure if 3.1rc2 also
> needed this modification (can't find it now).

I think this is resolved now? This patch below should fix the issue
(at least it did for me when I tried 3.0 with a 2.6.32 older backend
with DEBUG enabled):


# HG changeset patch
From: Jan Beulich <jbeulich@novell.com>
# Date 1306409621 -3600
# Node ID 876a5aaac0264cf38cae6581e5714b93ec380aaa
# Parent  aedb712c05cf065e943e15d0f38597c2e80f7982
Subject: xen/blkback: don't fail empty barrier requests

The sector number on empty barrier requests may (will?) be
uninitialized (neither bio_init() nor rq_init() set the respective
fields), which allows for exceeding the actual (virtual) disk's size.

Inspired by Konrad's "When writting barriers set the sector number to
zero...", but instead of zapping the sector number (which is wrong for
non-empty ones) just ignore the sector number when the sector count is
zero.

While at it also add overflow checking to the math in vbd_translate().

Signed-off-by: Jan Beulich <jbeulich@novell.com>

diff -r aedb712c05cf -r 876a5aaac026 drivers/xen/blkback/vbd.c
--- a/drivers/xen/blkback/vbd.c	Thu May 26 08:09:04 2011 +0100
+++ b/drivers/xen/blkback/vbd.c	Thu May 26 12:33:41 2011 +0100
@@ -108,8 +108,14 @@ int vbd_translate(struct phys_req *req, 
 	if ((operation != READ) && vbd->readonly)
 		goto out;
 
-	if (unlikely((req->sector_number + req->nr_sects) > vbd_sz(vbd)))
-		goto out;
+	if (likely(req->nr_sects)) {
+		blkif_sector_t end = req->sector_number + req->nr_sects;
+
+		if (unlikely(end < req->sector_number))
+			goto out;
+		if (unlikely(end > vbd_sz(vbd)))
+			goto out;
+	}
 
 	req->dev  = vbd->pdevice;
 	req->bdev = vbd->bdev;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Dec 03 14:43:46 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 03 Dec 2011 14:43:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWqmz-0000iD-K1; Sat, 03 Dec 2011 14:42:05 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RWqmy-0000i6-TG
	for xen-devel@lists.xensource.com; Sat, 03 Dec 2011 14:42:05 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1322923281!4117323!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQyNzM2Mw==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13745 invoked from network); 3 Dec 2011 14:41:22 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-11.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 3 Dec 2011 14:41:22 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pB3EfI5S013434
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sat, 3 Dec 2011 14:41:19 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pB3EfHJ0006111
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Sat, 3 Dec 2011 14:41:18 GMT
Received: from abhmt112.oracle.com (abhmt112.oracle.com [141.146.116.64])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pB3EfCTB030865; Sat, 3 Dec 2011 08:41:12 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Sat, 03 Dec 2011 06:41:12 -0800
Received: from phenom.dumpdata.com (localhost.localdomain [127.0.0.1])
	by phenom.dumpdata.com (Postfix) with ESMTP id DD40841C3C;
	Thu,  1 Dec 2011 14:08:13 -0500 (EST)
Received: (from konrad@localhost)
	by phenom.dumpdata.com (8.14.5/8.14.5/Submit) id pB1J8DA3010836;
	Thu, 1 Dec 2011 14:08:13 -0500
Date: Thu, 1 Dec 2011 14:08:13 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Marek Marczykowski <marmarek@mimuw.edu.pl>
Message-ID: <20111201190813.GA10824@phenom.dumpdata.com>
References: <4E6357C6.6050101@mimuw.edu.pl>
	<20110906163213.GC5264@dumpdata.com>
	<4E665572.7080009@mimuw.edu.pl>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4E665572.7080009@mimuw.edu.pl>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090205.4EDA3510.0011,ss=1,re=0.000,fgs=0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] blkfront problem in pvops kernel when barriers
 enabled
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Sep 06, 2011 at 07:16:34PM +0200, Marek Marczykowski wrote:
> On 06.09.2011 18:32, Konrad Rzeszutek Wilk wrote:
> > On Sun, Sep 04, 2011 at 12:49:42PM +0200, Marek Marczykowski wrote:
> >> Hello,
> >>
> >> Pvops block frontend (tested vanilla 3.0.3, 3.1rc2, Konrad's testing
> >> branch) produces a lot of I/O errors when barriers are enabled but
> >> cannot be used.
> >>
> >> On xenlinux I've got message:
> >> [   15.036921] blkfront: xvdb: empty write barrier op failed
> >> [   15.036936] blkfront: xvdb: barriers disabled
> >>
> >> and after that, everything works fine. On pvops - I/O errors.
> >> As backend I've used 2.6.38.3 xenlinux (based on SUSE package) and
> >> 3.1rc2 with same result.
> > 
> > Hm, and the 'feature-barrier' was enabled on in those backends?
> > That is really bizzare considering that those backends don't actually
> > support WRITE_BARRIER anymore.
> 
> At least in 2.6.38.3 xenlinux  (SUSE). Now I'm not sure if 3.1rc2 also
> needed this modification (can't find it now).

I think this is resolved now? This patch below should fix the issue
(at least it did for me when I tried 3.0 with a 2.6.32 older backend
with DEBUG enabled):


# HG changeset patch
From: Jan Beulich <jbeulich@novell.com>
# Date 1306409621 -3600
# Node ID 876a5aaac0264cf38cae6581e5714b93ec380aaa
# Parent  aedb712c05cf065e943e15d0f38597c2e80f7982
Subject: xen/blkback: don't fail empty barrier requests

The sector number on empty barrier requests may (will?) be
uninitialized (neither bio_init() nor rq_init() set the respective
fields), which allows for exceeding the actual (virtual) disk's size.

Inspired by Konrad's "When writting barriers set the sector number to
zero...", but instead of zapping the sector number (which is wrong for
non-empty ones) just ignore the sector number when the sector count is
zero.

While at it also add overflow checking to the math in vbd_translate().

Signed-off-by: Jan Beulich <jbeulich@novell.com>

diff -r aedb712c05cf -r 876a5aaac026 drivers/xen/blkback/vbd.c
--- a/drivers/xen/blkback/vbd.c	Thu May 26 08:09:04 2011 +0100
+++ b/drivers/xen/blkback/vbd.c	Thu May 26 12:33:41 2011 +0100
@@ -108,8 +108,14 @@ int vbd_translate(struct phys_req *req, 
 	if ((operation != READ) && vbd->readonly)
 		goto out;
 
-	if (unlikely((req->sector_number + req->nr_sects) > vbd_sz(vbd)))
-		goto out;
+	if (likely(req->nr_sects)) {
+		blkif_sector_t end = req->sector_number + req->nr_sects;
+
+		if (unlikely(end < req->sector_number))
+			goto out;
+		if (unlikely(end > vbd_sz(vbd)))
+			goto out;
+	}
 
 	req->dev  = vbd->pdevice;
 	req->bdev = vbd->bdev;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Dec 03 14:44:09 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 03 Dec 2011 14:44:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWqnW-0000lT-Q4; Sat, 03 Dec 2011 14:42:38 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RWqnV-0000k5-2d
	for xen-devel@lists.xensource.com; Sat, 03 Dec 2011 14:42:37 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1322923312!5723754!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDMxMjEy\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12251 invoked from network); 3 Dec 2011 14:41:53 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-9.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Dec 2011 14:41:53 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pB3EfOOI030957
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sat, 3 Dec 2011 14:41:24 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pB3EfLGa029790
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Sat, 3 Dec 2011 14:41:22 GMT
Received: from abhmt108.oracle.com (abhmt108.oracle.com [141.146.116.60])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pB3EfDlF027292; Sat, 3 Dec 2011 08:41:13 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Sat, 03 Dec 2011 06:41:12 -0800
Received: from phenom.dumpdata.com (localhost.localdomain [127.0.0.1])
	by phenom.dumpdata.com (Postfix) with ESMTP id 6AEA440189;
	Fri,  2 Dec 2011 18:31:25 -0500 (EST)
Received: (from konrad@localhost)
	by phenom.dumpdata.com (8.14.5/8.14.5/Submit) id pB2NVMn0012956;
	Fri, 2 Dec 2011 18:31:22 -0500
Date: Fri, 2 Dec 2011 18:31:22 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: linux-kernel@vger.kernel.org, x86@kernel.org, len.brown@intel.com,
	tglx@linutronix.de, jeremy@goop.org, hpa@zytor.com, bp@alien8.de,
	tj@kernel.org, trenn@suse.de
Message-ID: <20111202233122.GA12556@phenom.dumpdata.com>
References: <1320786914-10541-1-git-send-email-konrad.wilk@oracle.com>
	<1320786914-10541-3-git-send-email-konrad.wilk@oracle.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="YiEDa0DAkWCtVeE4"
Content-Disposition: inline
In-Reply-To: <1320786914-10541-3-git-send-email-konrad.wilk@oracle.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090207.4EDA3515.006A,ss=1,re=-2.300,fgs=0
Cc: mingo@redhat.com, xen-devel@lists.xensource.com, stable@kernel.org
Subject: Re: [Xen-devel] [PATCH 2/3] x86/cpa: Use pte_attrs instead of
 pte_flags on CPA/set_p.._wb/wc operations.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--YiEDa0DAkWCtVeE4
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

> The fix, which this patch proposes, is to wrap the pte_pgprot in the CPA
> code with newly introduced pte_attrs which can go through the pvops interface
> to get the "emulated" value instead of the raw. Naturally if CONFIG_PARAVIRT is
> not set, it would end calling native_pte_val.
> 
> The other way to fix this is by wrapping pte_flags and go through the pvops
> interface and it really is the Right Thing to do.  The problem is, that past
> experience with mprotect stuff demonstrates that it be really expensive in inner
> loops, and pte_flags() is used in some very perf-critical areas.

I did not get to verify the mprotect stuff as I need to chase down the details of it,
but I did run some benchmarks using kernbench on three different boxes:

 AMD A8-3850 (8GB) - tst005
 Intel i3-2100 (8GB) - tst007
 Nehelem EX (32logical cpus) (32GB) - tst010

I've put all the kernebench results in https://www.dumpdata.com/results/baseline_pte_flags_pte_attrs/
(and the chart for the AMD is attached).

The boxes have a fresh install of F16, with a 3.2-rc3 variant kernel using the
.config that F16 came with. I just hit Enter when oldconfig asked me to choose.

The baseline is virgin v3.2-rc3. The pte_attrs is the patch that this email is
replaying too (on top of v3.2-rc3). The pte_flags are two patches that wrap pte_flags
in paravirt and use alternative_asm to patch the code (on top of v3.2-rc3).

The patches are in the URL mentioned or in my git branch as
devel/pte_attrs.v1 ( git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git).
I am also attaching them in this email.

The summary is that I could only get the numbers to show some difference when
the maximum load was run - and _only_ on the AMD machine. The small SandyBridge
and the big SandyBridge had no trouble with. The AMD machine the difference was
13% worst if pte_flags (so alternative_asm) was used instead of pte_attrs.

The way I did these tests is to bootup with 'init=/bin/bash', remount / as rw, activate
swap disk and run kernbench on the v3.2-rc3 linux tree. Then unplug the machine for a tea
break and then repeat the cycle with a different kernel.

--YiEDa0DAkWCtVeE4
Content-Type: image/png
Content-Disposition: attachment; filename="AMD-A8-3850.png"
Content-Transfer-Encoding: base64

iVBORw0KGgoAAAANSUhEUgAAAlgAAAFzCAIAAABth+DjAAAlZElEQVR42u2dC1BU1/3HTZN2
mqR51DSd6WP6IDwWRmJAEFfSglMBVyQhUK0g465W8VEznUYlShkIE7XNtE3DqOlAZEQjGLSJ
bYogsalaJcWMYhyhlEdHMWR88FbeC/j/xfvPne3u3XVBWIH9fOYMc/bsvWfvft1zPp69l8uU
WwAAAG7MFCIAAABECAAAgAgBAAAQIQAAACIEAABAhAAAAIgQAAAAEQIAACBCAAAARAgAAIAI
AQAAECEAAAAiBAAAQIQAAACIEAAAABECAAAgQgAAAEQIAACACAEAABAhAAAAIgQAAECEAAAA
iBAAAAARAgAAIEIAAABECAAAgAgBAAAQIQAAACIEAABAhAAAAIgQAAAAEQIAACBCAAAARAgA
AIAIAQAAECEAAAAiBAAAQIQAAACIEAAAABECAAAgwvGX7Bc0NjbKw48++khtGUE/d3kY9p6t
qalRj+rf//63M0eu1u+//36dTldYWOhkt5cuXTIYDA899NDDDz8cHR19+fJlq70++eSTuXPn
yrNf/epXw8PDz507Z28vObAp/4s0Xr9+fcmSJY/eJikpqampSfMt2zuMsrKykJAQeenHHnss
NjZWabd8CXkqNDS0urqazzYAIoThiTA/P18e/v73vx+ZCEflMOw9m5ubqx7VW2+95cyRq5X2
9vaIiIj77rvv2LFjznQ7e/ZseVhUVPT+++9L5dlnn7Xaa8GCBY888sjx48fPnz8vG3z3u9+1
t9e7774rddnecvfk5GRplJfOycmRyqpVqzTfsmaHYmvx3Lx58+RN7d+/X9pnzpxp+WYHBwcP
Hz4s9eDgYD7bAIgQhmEgDw8PmaDlYVxc3FNPPaVOrLKw+PGPf/zggw9++ctf9vPzKykpOXv2
rKyxnnnmGZlz+/v7p02bJg+l0cpAe/fulbl46tSpW7du3blz55NPPvn973+/uLhYs887inD5
8uXyrF6vl58mk8mZI7fs8MSJE7ZCstetmEYe9vX19fb2SkWOU/OQZANFRbI+s7fXyy+/LPXX
X3/dckdvb29plIXg1atXpSIPNfvX7HDhwoVSl7Wvg/9GyC5Sl3Ukn20ARAjDEOHSpUt9fHzk
4be+9S2j0ahOrIGBgfv27TObzYrqvv3tb0vj+vXrpf7mm29u27ZNKhs3brSci5XKL3/5y3Pn
zin1devWnT59Wirf+9737PXpWISKPP785z/LTy8vL2eO3LLDzs5OqYuMnek2ISFBHsq66q9/
/atUpE/NQ/rBD34gz4rdr1y5Ym+v8PBwqT/xxBOi/J/85CfKlqI0aZS3L/+NkMpDDz2k2b9m
h9/4xjekLm/HngiHhoaUt7Np0yY+2wCIEIYhwrfeekt+/utf/5Kfu3btsrTIxx9/vGHDBn9/
f2m57777pKWrq+uHP/yhrPZkTpcFmTy0FWFLS4ssGZW6rH6UurK7Zp8ORHj9+nV56vHHH5dO
5EWlfu3atTseuWWHogepP/DAA850297e7unpqez+6KOP2juHJ+9a+TJ2yZIl9vYS+X3nO9+p
qqr605/+JO2xsbHSKO9XlZZUvvSlL2n2r9mhvAV5KAd8y+Kb4Vv/e45QmDFjxn/+8x8+2wCI
EIYhwurqavkZExMjP2UOVWfYP/7xj0q7sqRT1ZKenq48/NWvfmW1KLHcTLOu2acDER46dEie
ioqKkvr8+fOlLi13PHLLDkVaUv/617/uTLc/+9nPpP6Xv/xFWYr99Kc/tRfdjRs31C8hHe+l
LEmVxZ/8dGZFqNmhrJ6lLo60l/nAwEB+fr7Un3rqKT7bAIgQhiFCqTz55JOyWPnmN79p2fi1
r31NKjdvozbK6kSkIpPyY489JvP4p59+OiwRavbpQISydrRa8UjLHY/cskPFuJGRkc50q5yc
672NchGm1fLLSoTKN66ae1kuH1UT+/n5SV3Wo8o5QuV7XVs0O5TVp9RPnDhx6/Z1MZpvVjlH
+JWvfIXPNgAihOGJMDY2ViovvPCCZaOyBDl+/Pgf/vAHtXHFihVSycvLy8rKUr8bdF6Emn06
MOKsWbOUtZHUCwoKlMtb7njkaqW7u3vRokViyqNHjzrT7bPPPiv1d999929/+5tUwsLCrBL7
0Y9+9OCDD4qNdu/eLRu8/PLL9vaSRhHYsWPH9u7dq5wrVQWcexv1qlHbd63ZYWVlpXQoRpdF
oXKC1urNDg0NKVeNzp49m882ACKE4YlQ0ZL8tGw8cODAE0888fjjj//85z9XGj/++GORSmBg
oMy5AwMDTz/9tDwsLy93XoS2fVoJ7P7771cPr6enRxY30qj8wlx9fb2y3JF2x0euruEeeOCB
adOmieos37WDbj/77LO4uLiHH35YbLdgwQLllxQt+eSTT8LDw0VI8hZeeukls9ksjZp7yZYi
MGXLtWvXytpOWUcuXrxYlsWPPPJIQkKCLA1t37W9DoVTp06JwuVQH330UTkMkbHlm5V/C1mj
i0Q5RwiACGGi8o9//EO9gJN3DQCACN2OiIgI2998510DACBCAABAhAAAAIgQAAAAEQIAACBC
AAAARAgAAIAIAQAAECEAAAAiBAAAQIQAAACIEAAAABECAAAgQgAAAEQIAACACAEAABAhAAAA
IgQAAECEAAAAiBAAAAARujEzZswgBFvOnDlDCGRCLGOayYzkM3cshIkIESGzG5kQCyL8Hzw8
PEb9gNU+x6JzRIgImd3IhFjIZMKIkBUhIgRmNzIhlgkgwqqqqsjIyMTExObmZqXx/Pnzzz//
vI+Pz6xZsw4cOKA0lpaWent7e3l5RUdHl5eXK43t7e0mk0mn0xmNxo6ODnsrQqlkZ2eHhoZK
D9KPg30RISJkdiMTYiEWV4tw8+bNvb29J06c2Lhxo9IoXiwqKurr63vvvfcCAgKURnFYfn7+
wMCAmCwsLExpTE1NrampMZvNJSUlGRkZDkSYmZnZ1dWl2NTBvogQETK7kQmxEIurRXjlyhWp
iPaCg4OtnhXtqTJLSkpavXp1WVlZT0+PukFISIhsI5XBwUG9Xu9AhG1tbVaNmvsiQkTI7EYm
xEIsrhahYqOhoSEvLy+lsbm5OSsra9WqVeHh4aq3WlpaEhMTdTqdv79/ZWWl0ii7eHyBurum
CC1f0cG+iBARMruRCbEQi6tFeO7cOanIOk9dlsXExLzxxhvHjh2rq6uzuvKlt7e3sLBQFnPK
w6CgILPZbNunMyLU3BcRThIROvNxdHFhdmPGJxZEaE+ECxcuFL0dPXo0PT1daZw2bdqFCxdu
3LghLaq3lBOHyjlC9TxfSkpKdXW1NIod4+PjhyVCzX0RISJEhMxuxEIsrhZhTU1NRESEyWQS
8ymNhw8fnjt3rkxmubm5qrcqKipkM09PT8srP9va2oxGo7QYDIba2tphiVBzX0SICBEhsxux
EItLRejOIEJEyOxGJsSCCBEhIEJmNzIhFjJBhIAIGclkQixkgggBETKSyYRYyAQRjgYeNqjt
rnljVi/kocWYHg+/R8hIJhNiIRN3F+Gw2iffAYgI6/VTx1VhJDO7EQuZwDgSoeZNzeXZoqKi
6dOnL1y4sKmpSWl0/k7nra2tS5Ysefrpp9955x0nRWi5VM3Pzw8KChKBHTly5OTJk3q9/m7u
j44IGclkQixkgggdtWve1Fye3bRpU09PT0FBQUpKitLo/J3OZd/CwsLe3l55dgQiTE9P7+zs
LC4uNhgMO3fuvMv7oyNCRjKZEAuZuLsInTxHaHlTc6k0NjZK5ebNm+ot7Jy/07ksLsVkUvns
s89GIELlT3Apx6P0c+su7o+OCBnJZEIs9ySTUZwN+vv7R+XI1X5Gq8NJsiLUvKm5VEQzimzU
pZjzdzqXytDQkJVcnRehsu+tUbo/OiJkdiMTYpnoIoyMjByVI1f7Ga0OJ4kINW9qLhXl1GB7
e3toaKjljs7c6VwWasot8q5fvz4CEWpuM+L7oyNCZjcyIZaJLsLRurrQ9b84MDFEqHlTc6ls
2bKlr69v7969mZmZ6v8gnLzTuXSVn58vu8u+oy7C4d4fHREyu5EJsUwgEdpeq2h5Ysv5qwVt
L4S096trO3bsiIqKumXnishJIkLH5wg1b2oulV27dvn7+ycnJ6tn6Zy/07loVf6pZOkmOhx1
EQ73/uj8HiGzG5kQy8QSoe21iuoE6PzVgvYuhLStyKKiq6vrlp0rIieDCEd3HTkR+VyE2VMm
RmF2Y8YnFkSoda3iiK8WvGVzIaRtRVaZSl3zikhEiAgRIbMbsRCLq0Voe63iCK4WtHchpL3K
LTtXRLqvCCcTiJDZjUyIZWKJ0PZaxRFcLWjvQkgHIlSwuiISESJCRMjsRizE4moR2l6rKIu/
1tbWW8O5WlDzQki1H7ViKULNKyIRISJEhMxuxEIsrhah7bWKUtfpdLeGc7Wg5oWQaj9qxVKE
mldEIkJEiAiZ3YiFWFwtQrcNFhEiQkTIjE8siHDYIrT3t+0QIfyvCIHZjUyIhUwQISIERjKZ
EAuZIEJECIxkMiEWMkGEiBAYyWRCLGSCCBEhI5kQyIRYyAQRIkJGMpAJsZAJIkSEjGQgE2Ih
E0SICBnJQCbEMsqZjN5vD/f39yNCQITMbmRCLO4rwsjIyOEeZGlpqY+Pz7Zt2ybQ79cjQkTI
7EYmxIIItRmBzJT7hQ4NDSFCQITMbmRCLBNJhOKtoqKi6dOnL1y4UPl7TJY3TmtvbzeZTDqd
zmg0dnR0OBCnuosqwvPnzz///POyTJw1a9aBAweUxpaWlsWLF8s8uXv3bnVL5a9PeHl5RUdH
l5eXI0JEyOxGJsQCLhXhpk2benp6CgoKUlJSrFaEqampNTU1ZrO5pKQkIyPDmUWkWlH+ylJf
X997770XEBCgdpiTkyMvJxV1S7Fgfn6+8veYwsLCECEiZHYjE2IBl4qwsbFRKjdv3lT/Oq6q
KGkRP926/ffr9Xr9sESoIj2ojdKJrDKlcuXKFbUxKSlp9erVZWVlIkhXBosIESGzG5kQCyL8
3FsiOUV16l/HtfzLuurXnlIflgibm5uzsrJWrVoVHh5u2eHQ0JCVHVtaWhITE3U6nb+/f2Vl
JSJEhMxuZEIs4FIRKqcGZaEWGhpqJbOgoCCz2ezMi9uKMCYm5o033jh27FhdXZ3lElNZEV69
etVq7djb21tYWKiuShHhxBbhjOQzFMvC7MaMTyzjWYRbtmzp6+vbu3dvZmamum5rbW2VSkpK
SnV1tazeRFHx8fHDEuG0adMuXLhw48aN9PR0tfHXv/71rl275OVeeeUVq7OJyjlCdVWKCBEh
ImR2IxZwkQjFTP7+/snJyZ2dnUqj1HU6nVTa2tqMRqPIyWAw1NbWDkuEhw8fnjt3rsyIubm5
aqN0mJCQ8Mwzz+Tk5IgplcaKioqIiAhPT0/ldzAQISJEhMxuxAIuFaHr35HZbN6/f39iYuK9
DRYRIkJEyIxPLIhw2CL00ML53devXx8QEODj47No0aJLly4hQkSICJndgFjIBBEiQkTI7AbE
QiaIEBEiQmY3IBYycXcR2n7LPCqncO19nT1254f5PUJGMpkQC5kgwnEkwjHqzbEI6/VTKZaF
kczsRixkggjvSoSaNybXvCe67LJjx46oqKg79m/5Ky/5+flBQUEisCNHjpw8eVKv11v+LouT
N19HhIiQ2Y1YyAQRjpUINW9MrnlPdNmlsLCwq6trWCJMT0/v7OwsLi42GAw7d+6U3S3vbuD8
zdcRISJkdiMWMkGEYyJCzRuTa94TXXZR7mI3LBE2Nzff+uIOsOqNFUZw83VEiAiZ3YiFTBDh
yJEVmOIbBan7+Pgodc0bk2veE93BiUAHIlRuhW61zQhuvo4IESGzG7GQCSIcOc8995zlXQbq
6uri4uIsN7C6MbnmPdFHJkLNbUZw83VEiAiZ3YiFTBDhyDlx4oTJZLp48aKsBRsaGlasWHH6
9GnlKc0bk2veE30sROj8zdcRISJkdiMWMkGEd8WhQ4dCQ0M9PT1nz54t5lPbNW9MrnlP9LEQ
ofM3X1dFyMeLkUwmxEImiNB9+VyEztz61q0KI5nZjVjIBBEiQkTIZ4PZjVjIBBEiQkQIzG7E
QiaIEBEiQmB2IxYyQYSIEBECmRALmSBCRIgImd2AWMgEESJCRMjsBsRCJohwsokQGMlkQixk
gggRITCSyYRYyAQRIkJgJJMJsZAJIkSEwEgmE2IhE0SICBnJhEAmxEImiBARMpKBTIiFTBAh
ImQkA5kQC5kgQkTISAYyIRYyQYSIkJFMJkAsZIIIESEjmUyAWMgEESJCRjKZALGQCSJEhIxk
MgFiIRNEiAgZyWRCLEAmiBARMpLJhFiATBAhImQkkwmxAJkgwokpwhnJZ0alMJKZ3YgFyAQR
IkJGMrMbsZAJmSBCRMhIZnYjFjIBRIgIGcnMbsRCJoAIESEjmUyIhUwAESJCRjKZEAuZgDuI
sL+/HxEykpndiAXIZGKLsKGhwWQy+fn5BQYGpqamdnV1Ob9vZGTk3R+AhxZK+9iJkI8XI5lM
iIVMEOH/ExcXl5ub29PT09bWtnXr1rS0tGE5bBSPZOzMZyvCev3UUSmMZGY3YgEymfAi9PX1
VVeBAwMDQUFBUpk7d+7ly5elcvHixYiICKmUlpZ6e3t7eXlFR0eXl5dbruSk3t7eLstKnU5n
NBo7OjpUseXn50uHIp4jR46cPHlSr9dLJ9KVMyJUH96xH81XR4SMZDIhFjJBhE6xdu3ajIyM
gwcP1tfXq42//e1v8/LypCI/ZZkoFRGP2EhMKfoJCwuzclVqampNTY3ZbC4pKZHe1GfT09M7
OzuLi4sNBsPOnTvFuIpQhytCx/1ovjoiZCSTCbGQCSJ0ira2trS0tNjYWFntyeKvqqpKGs+e
Pbt06VKpyErr1KlTUklKSlq9enVZWVlPT4+tq0JCQsSRUhkcHJTlmvpsc3OzstCUuphMU3jO
iNBxP5qvjggZyWRCLGSCCIfHzZs3s7OzZcmlGGX27NlNTU3iDOXS0JaWlsTERJ1O5+/vX1lZ
aaUikaj6TanU1WeHhoZsJTcCETruR/PVESEjmUyIhUwQoVMEBASo5wj7+vp8fX2V+qZNm2Sl
mJycbLlxb29vYWGhrMCsVBQUFGQ2mx2I7S5F6LgfzVdHhIxkMiEWMkGETrF58+asrCxZ/HV3
d2/fvt1kMintf//735XzgsrDyMjIoqIi5RyhenJOll+tra1SSUlJqa6ulmdFk/Hx8S4Woear
I0JGMpkQC5kgQqfo7OwUkQQGBvr5+a1cufLatWtKe0dHh5imsbFReVhRUREREeHp6Wl5uaas
F3U63a3bJxqNRqM8ZTAYamtrXSxCzVd3LEI+XoxkMiEWMkGEd+Cjjz6KiYmZlMl+LsLsKaNT
GMnMbsQCZDJZRejv73/kyBFEiAiZ3YBYyMRNRTiJQYSMZDIhFjJBhIgQETKSyYRYyAQRIkJE
yEgmE2IhE0SICBEhI5lMiIVMECEiRISMZDIhFjJBhG4lQmAkkwmxkAkiRITASCYTYiETRIgI
gZFMJsRCJogQEQIjmUyIhUwQISJkJBMCmRALmSBCRMhIBjIhFjJBhIiQkQxkQixkgggRISMZ
yIRYyAQRIkJGMpkAsZAJIkSEjGQyAWIhE0SICBnJZALEQiaIEBEykskEiIVMECEiZCSTCbEA
mSBCRMhIJhNiATJBhIiQkUwmxAJkgggnpghnJJ+hjLfC7MakTyaACBEhImR2Y9InE0CEiBAR
Mrsx6ZMJIEJEiAiZ3Zj0yQQQISJEhMxuTPpkgggBESJCZjdiIRNEOCnp7+9HhBREyKRPJjAu
ROjxBd7e3gsWLDh//rwLXjQyMtK2saKiIiEhwc/PLzU1tbGx8Y5HKC2278UZEfLxYiSTCbGQ
CSLUkMfAwMC+ffvmz5/vyhdVqaqqCg4OLi4u7urqunjxYlJS0p49exwf4YhFWK+fShlvhdmN
SZ9M4N6LUOju7pZVl1Jvb283mUw6nc5oNHZ0dKgb79ixIyoqSuqiq3nz5gUEBHzwwQeOd8nO
zg4NDZWeS0tLLVd4lofx4osvFhQUqA8vX768YcMGx0eICBEhsxuxkAkiHE0R9vb25uTkvPDC
C8rD1NTUmpoas9lcUlKSkZGhblxYWCiLNqmvWbMmLy9PPgFhYWGOd8nMzJRdxIIOHDZz5sxr
164N6wgRISJkdiMWMkGEoyNCBVnJxcfHi8mU9pCQkIGBAakMDg7q9Xp1Y1n2qUZpa2uz7Mre
LupmqqhsjSWOVPZ1/ggRISJkdiMWMkGEo/zVqCVeXl6qgaRuu7E0Dg0NDWsXByKcNWuW5YpQ
elaNa+8IrdwpdR8fH0SICJndiIVMEOHoiDAoKMhsNjvYOCAgQD0R6OQuDkS4bt26AwcOqA/P
nj07Z84cx0f43HPPXbp0SX1YV1cXFxeHCBEhsxuxkAkiHB0RpqSkVFdXyzKrsLAwPj7eduMV
K1bIUxUVFaqx7riLWpf1Ymtrq+XLST/BwcEffvhhb2+vdBIVFbVv3z7HR3jixAmTyXTx4kV5
xYaGBjme06dPI0JEyOxGLGSCCEdHhG1tbUaj0dvb22Aw1NbW2m4sKzBRYGBg4PHjx53cRa0n
JyfrdDqrVzx69Oj8+fPFkXq9Picn545HKBw6dCg0NNTT03P27NlFRUXOvF9+j5CRTCbEQiaI
0K35XITZUyjjojC7MemTCSBCRIgImd2Y9MkEECEiRITMbkz6ZAKIEBEiQmY3Jn0yAUSICBEh
sxuxkAkgQkSICJndiIVMABEiQkTI7EYsZIIIYaxECIxkMiEWMkGEiBAYyWRCLGSCCBEhMJLJ
hFjIBBEiQmAkkwmxkAkiRISMZEIgE2IhE0SICBnJQCbEQiaIEBEykoFMiIVMECEiZCQDmRAL
mSBCRMhIJhMgFjJBhIiQkUwmQCxkgggRISOZTIBYyAQRIkJGMpkAsZAJIkSEjGQyIRYgE0SI
CBnJZEIsQCaIEBEyksmEWIBMEOHEFOGM5DMUCmViFUSICAERUiiIEBEiQkCEFAoiRISIEBAh
hYIIESEiBERIoSBCRIgIARFSKIgQESLCu6e/v3+MNnZxb4iQQkGEiNAdRVhRUZGQkODn55ea
mtrY2DiCV4qMjLybjRsaGkwmkxxAYGCgHENXV9cdO/Hw8LjjS6vbjIUI+XgxksmEWMhkkoiw
qqoqODi4uLhY9HPx4sWkpKQ9e/YM95WGpRzbjePi4nJzc3t6etra2rZu3ZqWljYqLz2mIqzX
T6VQKBOuIEJEqMGLL75YUFCgPrx8+fKGDRuUelNTU2Jioo+Pz9KlS0VRql2ys7NDQ0O9vb1L
S0uVFgWpt7e3y9pOp9MZjcaOjg5pWbZs2alTp6Ry/PjxlStXWm6s4uvrq64CBwYGgoKCpDJn
zhw5GEXVsr0sW5W1Y3h4uCo5y97E4vPmzQsICPjggw/UQ33//fdllakequYRCvKsbOPl5RUd
HV1eXo4IKRREiAjdSIQzZ868du2a5lMvvfTS/v37zWbzvn37Nm7cqNolMzNTvKXIw2rtlZqa
WlNTI7uUlJRkZGRIS11d3YIFC3p7e+fPny+u0lyorV27VjY+ePBgfX292vjKK6/Iq0slJyfH
z89vx44dUn/77bfT09MtO1Era9asycvLkw9TWFiY+tRrr73W3d1teai2RyjIs/n5+eJg2VLd
HRFSKIgQEbqFCMUBIgDNp2Rl1tnZKZUbN24oqzTFLparQ6tKSEiI0tvg4KBer1eVtmjRoi1b
ttj7xlI6TEtLi42NlTVZRESELAGVFeQvfvELZU35u9/9bsmSJVJPTk4+evSo5kuLnNQDU5+S
9Z8zR5iUlLR69eqysrKenh6+GqVQECEidC8Rzpo1y3JFODQ0pMpDtKRUxBmenp62GrO1keyi
fl2p7i4LQXn46aef3vHU3c2bN7Ozsw0Gg9TFSSKqvr4+OUIx8fTp08XKgYGBips1X1oO3t45
QsdH2NLSkpiYqNPp/P39KysrESGFgggRoRuJcN26dQcOHFAfnj17ds6cOeqKsLu723ZF6ECE
spnZbLZ6CWVF+Oqrr9oTYUBAgHqOUMzn6+ur1E0m0+7du1euXCn1hISE119/XX7ae2npRD3n
5+BQNY9Qobe3t7CwUJaMiJBCQYSI0I1EWFFRERwc/OGHH4oGqquro6Ki9u3bpzy1fv36oqKi
gYGB/fv3q1fQ2Ftmtba2SiUlJUU6kV3EKPHx8co5wpiYGNHb/Pnz//vf/1purLJ58+asrKym
pibx7vbt28V/SnteXp546+2335b6jh07pk2b9uabb9p76RUrVsiLyttRRa55qLZHeOv272Ao
79TybCIipFAQISJ0CxEKR48eFUuJUfR6fU5Ojtre3NwsKzCdTidmsj0vaFlPTk6WzZSzfUaj
UVxiMBhqa2strxr95z//uXz5csuNVTo7O8VPgYGBfn5+sv5Tv6pVvlNtaGhQhC31Cxcu2Htp
Ma4oUDo5fvy4g0O1PUKl84iICE9PT8vrSx2LkI8XI5lMiIVMJo8IYbh8LsLsKRQKZYIVRIgI
ARFSKIgQESJCQIQUCiJEhIgQECGFgggRISIEREihIEJEiAgBEVIoiBARIkJAhBQKIkSEiBCG
J0JgJJMJsZAJIkSEwEgmE2IhE0SICIGRTCbEQiaIEBECI5lMiIVMECEiZCQTApkQC5kgQkTI
SAYyIRYyQYSIkJEMZEIsZIIIESEjGciEWMgEESJCRjKZALGQCSJEhIxkMgFiIRNEiAgZyWQC
xEImiBARMpLJBIiFTBAhImQkkwmxAJkgQkTISCYTYgEyQYSIkJFMJsQCZIIIJ6YIZySfoVAo
riyIEBAhIqRQECEiBESICCkURIgIAREiQgoFESJCQISIkEJBhIgQECEipFAQISIERIgIKRRE
iAhhkouwoaHBZDL5+fkFBgampqZ2dXUp7R4eHvdKhHy8GMlkQixkgghdR1xcXG5ubk9PT1tb
29atW9PS0u65COv1UykUissKIgR3F6Gvr6+6ChwYGAgKCrISYXt7uywZdTqd0Wjs6Ohw0Ci7
FBUVTZ8+feHChU1NTUpjaWmpt7e3l5dXdHR0eXk5IqRQECEiRITji7Vr12ZkZBw8eLC+vt6y
XRVhampqTU2N2WwuKSmRLR00yi6bNm2SxWVBQUFKSorSKBbMz88XxYoRw8LCECGFgggRISIc
X7S1taWlpcXGxsqiLSIioqqqykqEISEhojGpDA4O6vV6B42yS2Njo1Ru3rwpGyiNSUlJq1ev
LisrE0Hy1SiFgggRISIcv4i9srOzDQaDlQhFkB5fIHUHjVIXLyp2lIWg0tjS0pKYmKjT6fz9
/SsrKxEhhYIIESEiHF8EBASo5wj7+vp8fX2tRBgUFGQ2m6320myUXZRTg+3t7aGhoZZP9fb2
FhYWqstEREihIEJEiAjHC5s3b87KyhKBdXd3b9++3WQyWYkwJSWlurp6YGBATBYfH++gUXbZ
smWL2HTv3r2ZmZlKY2RkZFFRkXKOUF0mIkIKBREiQkQ4Xujs7BSrBQYG+vn5rVy58tq1a1Yi
bGtrMxqN4jCDwVBbW+ugUXbZtWuXv79/cnKydKs0VlRUREREeHp6ysbiQmdEyMeLkUwmxEIm
iHBCMiq/evi5CLOnUCgUlxZECIgQEVIoiBARAiIcFyBCCgURIkJEiAiZmCgURIgIESEipFAo
iBARIkJESKFQECEiRISIkEKhIEJEiAjdSoTASCYTYiETRIgIgZFMJsRCJogQEQIjmUyIhUwQ
ISIERjKZEAuZIEJEyEgmBDIhFjJBhIiQkQxkQixkgggRISMZyIRYyAQRIkJGMpAJsZAJIgQA
AECEAAAAiBAAAAARAgAAIEIAAABECAAAgAgBAAAQIQAAACIc/9y4cWPx4sWWLfX19SaTad68
eWvWrKmsrCQKqyjcIZ+7iWKS5TPqUUzcfFwThdvOP4jwnnH9+nX5tM2dO9ey8Te/+c0777zT
19eXl5f36quvEoVVFJM+n7uMYjLlMxZRTNB8XBaFe84/iPBesmjRosOHD1t9uJctW9be3i6V
q1evLl++nCisopj0+dxlFJMpn7GIYoLm47Io3HP+QYT3kpaWFvlp9eGOiYkZGBiQSn9/f3R0
NFFYRTHp87nLKCZTPmMRxQTNx2VRuOf8gwjvPVYf7oiICKUyNDSk1olCrbtJPiOOYvLlM7pR
TOh8XBCFO88/iHAcfbjlf2Fms1kq8lP+d0YUVlG4ST4jjmLy5TO6UUzofFwQhTvPP4hwHH24
ly1b1tTUdOv26XGpE4VVFG6Sz4ijmHz5jG4UEzofF0ThzvMPIhxHH+7XXnttz5493d3d8nPb
tm1EYRWFm+Qz4igmXz6jG8WEzscFUbjz/IMIx9GHu6qqymg0zps3T37W1dURhVUUbpLPiKOY
fPmMbhQTOh8XROHO8w8iBAAAQIQAAACIEAAAABECAAAgQgAAAEQIAACACAEAABAhAAAAIgQA
AECEAACACAEAABAhAAAAIgQAAECEAAAAiBAAAAARAgAAIEIAAABECAAAgAgBAAAQIQAAACIE
AABAhAAAAIgQAAAAEQIAACBCAAAARAgAAIAIAQAAECEAAAAiBAAAQIQAAACIEAAAABECAAAg
QgAAAEQIAACACAEAABAhAAAAIgQAAECEAAAAiBAAAAARAgAAIEIAAABECAAAgAgBAAAQIQAA
ACIEAABAhAAAAIgQAAAAEQIAACBCAAAARAgAAIAIAQAAECEAAAAiBAAAQIQAAAB35P8AX8gY
XW/o2AIAAAAASUVORK5CYII=

--YiEDa0DAkWCtVeE4
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="0001-x86-paravirt-xen-Introduce-pte_flags.patch"

>From 6f30ff305df4d36160641ad7232c39f58afc5c4a Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Mon, 28 Nov 2011 17:33:47 -0500
Subject: x86/paravirt/xen: Introduce pte_flags.

We are providing a version of pte_flags where the processing
under Xen goes couple of extra steps (if pat is enabled).

The baremetal version looks quite identical to the pte_val
one and the idea is to piggyback on the DEF_NATIVE/PTE_IDENT
mechanism that pte_val uses for baremetal.

Specifically we move the logical processing of "& PTE_FLAGS_MASK"
out of the functions to minimize the amount of operations
the paravirt operations have to do. This benefits us greatly
as this way we don't have do that logical operations in the function:
(native_pte_flags):

	pushq	%rbp
	movq	%rdi, %rax
	movabsq	$-70368744173569, %rdx
	andq	%rdx, %rax
	movq	%rsp, %rbp
	popq	%rbp
	ret

but instead the paravirt function ends up being:

	pushq	%rbp
	movq	%rdi, %rax
	movq	%rsp, %rbp
	popq	%rbp
	ret

and the logical "and" operation is done outside the call.

This means that the only real operation that native_pte_flags
is "movq %rdi, %rax" we can take advantage of the PTE_IDENT
functionality introduced in patch:
"x86/paravirt/xen: Optimize pte_flags by marking it as paravirt_ident_[32|64] type."

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 arch/x86/include/asm/paravirt.h       |    5 +++++
 arch/x86/include/asm/paravirt_types.h |    1 +
 arch/x86/include/asm/pgtable.h        |    1 +
 arch/x86/include/asm/pgtable_types.h  |    4 ++--
 arch/x86/kernel/paravirt.c            |    1 +
 arch/x86/xen/mmu.c                    |   13 +++++++++++++
 6 files changed, 23 insertions(+), 2 deletions(-)

diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h
index a7d2db9..6533409 100644
--- a/arch/x86/include/asm/paravirt.h
+++ b/arch/x86/include/asm/paravirt.h
@@ -462,6 +462,11 @@ static inline void pmd_update_defer(struct mm_struct *mm, unsigned long addr,
 	PVOP_VCALL3(pv_mmu_ops.pmd_update_defer, mm, addr, pmdp);
 }
 
+static inline pteval_t pte_flags(pte_t pte)
+{
+	return pv_mmu_ops.pte_flags(pte) & PTE_FLAGS_MASK;
+}
+
 static inline pte_t __pte(pteval_t val)
 {
 	pteval_t ret;
diff --git a/arch/x86/include/asm/paravirt_types.h b/arch/x86/include/asm/paravirt_types.h
index 8e8b9a4..86bce9d 100644
--- a/arch/x86/include/asm/paravirt_types.h
+++ b/arch/x86/include/asm/paravirt_types.h
@@ -288,6 +288,7 @@ struct pv_mmu_ops {
 	void (*ptep_modify_prot_commit)(struct mm_struct *mm, unsigned long addr,
 					pte_t *ptep, pte_t pte);
 
+	pteval_t (*pte_flags)(pte_t pte);
 	struct paravirt_callee_save pte_val;
 	struct paravirt_callee_save make_pte;
 
diff --git a/arch/x86/include/asm/pgtable.h b/arch/x86/include/asm/pgtable.h
index 18601c8..eebf625 100644
--- a/arch/x86/include/asm/pgtable.h
+++ b/arch/x86/include/asm/pgtable.h
@@ -76,6 +76,7 @@ extern struct mm_struct *pgd_page_get_mm(struct page *page);
 #define __pmd(x)	native_make_pmd(x)
 #endif
 
+#define pte_flags(x)	(native_pte_val(x) & PTE_FLAGS_MASK)
 #define pte_val(x)	native_pte_val(x)
 #define __pte(x)	native_make_pte(x)
 
diff --git a/arch/x86/include/asm/pgtable_types.h b/arch/x86/include/asm/pgtable_types.h
index 013286a..4c957e8 100644
--- a/arch/x86/include/asm/pgtable_types.h
+++ b/arch/x86/include/asm/pgtable_types.h
@@ -270,9 +270,9 @@ static inline pteval_t native_pte_val(pte_t pte)
 	return pte.pte;
 }
 
-static inline pteval_t pte_flags(pte_t pte)
+static inline pteval_t native_pte_flags(pte_t pte)
 {
-	return native_pte_val(pte) & PTE_FLAGS_MASK;
+	return pte.pte;
 }
 
 #define pgprot_val(x)	((x).pgprot)
diff --git a/arch/x86/kernel/paravirt.c b/arch/x86/kernel/paravirt.c
index d90272e..4780367 100644
--- a/arch/x86/kernel/paravirt.c
+++ b/arch/x86/kernel/paravirt.c
@@ -462,6 +462,7 @@ struct pv_mmu_ops pv_mmu_ops = {
 #endif
 #endif /* PAGETABLE_LEVELS >= 3 */
 
+	.pte_flags = native_pte_flags,
 	.pte_val = PTE_IDENT,
 	.pgd_val = PTE_IDENT,
 
diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index 87f6673..5b79048 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -412,6 +412,16 @@ static pteval_t iomap_pte(pteval_t val)
 	return val;
 }
 
+static pteval_t xen_pte_flags(pte_t pte)
+{
+	pteval_t pteval = pte.pte;
+
+	/* If this is a WC pte, convert back from Xen WC to Linux WC */
+	if ((pteval & (_PAGE_PAT | _PAGE_PCD | _PAGE_PWT)) == _PAGE_PAT)
+		pteval = (pteval & ~_PAGE_PAT) | _PAGE_PWT;
+	return pteval;
+}
+
 static pteval_t xen_pte_val(pte_t pte)
 {
 	pteval_t pteval = pte.pte;
@@ -1975,6 +1985,8 @@ static void __init xen_post_allocator_init(void)
 	pv_mmu_ops.release_pud = xen_release_pud;
 #endif
 
+	if (!pat_enabled)
+		pv_mmu_ops.pte_flags = native_pte_flags;
 #ifdef CONFIG_X86_64
 	SetPagePinned(virt_to_page(level3_user_vsyscall));
 #endif
@@ -2023,6 +2035,7 @@ static const struct pv_mmu_ops xen_mmu_ops __initconst = {
 	.ptep_modify_prot_start = __ptep_modify_prot_start,
 	.ptep_modify_prot_commit = __ptep_modify_prot_commit,
 
+	.pte_flags = xen_pte_flags,
 	.pte_val = PV_CALLEE_SAVE(xen_pte_val),
 	.pgd_val = PV_CALLEE_SAVE(xen_pgd_val),
 
-- 
1.7.7.3


--YiEDa0DAkWCtVeE4
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="0002-x86-paravirt-xen-Optimize-pte_flags-by-marking-it-as.patch"

>From 7e218b96dc908362afb501755f3f4b8ec530b700 Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Mon, 28 Nov 2011 17:58:38 -0500
Subject: x86/paravirt/xen: Optimize pte_flags by marking it as
 paravirt_ident_[32|64] type.

Which means that we have to use:
 __PV_IS_CALLEE_SAVE(_paravirt_ident_64)
which requires that the pte_flags on the 'pv_mmu_ops' structure
be defined as struct paravirt_callee_save. We end up using the
_paravirt_ident_64 function for both baremetal and for Xen guests
that have PAT disabled. For those that have pat_enabled, we end
up calling xen_pte_flags.

The big benefit of making the .pte_flags as struct paravirt_callee_save
and making it PTE_IDENT is that while the code looks as so when compiled:

  ff 14 25 e8 52 c1 81 	callq  *0xffffffff81c152e8

That however, on baremetal and under Xen when !pat_enable ends up
being patched over (by using the DEF_NATIVE macro) to be:

   48 89 f8             	mov    %rdi,%rax
   66 66 66 90          	data32 data32 xchg %ax,%ax

(the 32-bit version is of course different).
For details refer to 'paravirt_patch_ident_64' function.

The Xen version which requires pat_enable==1, ends up patched
to be:

	call xen_pte_flags;

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 arch/x86/include/asm/paravirt.h       |   11 ++++++++++-
 arch/x86/include/asm/paravirt_types.h |    2 +-
 arch/x86/kernel/paravirt.c            |    2 +-
 arch/x86/xen/mmu.c                    |   11 +++++++++--
 4 files changed, 21 insertions(+), 5 deletions(-)

diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h
index 6533409..b113feb 100644
--- a/arch/x86/include/asm/paravirt.h
+++ b/arch/x86/include/asm/paravirt.h
@@ -464,7 +464,16 @@ static inline void pmd_update_defer(struct mm_struct *mm, unsigned long addr,
 
 static inline pteval_t pte_flags(pte_t pte)
 {
-	return pv_mmu_ops.pte_flags(pte) & PTE_FLAGS_MASK;
+	pteval_t ret;
+
+	if (sizeof(pteval_t) > sizeof(long))
+		ret =  PVOP_CALLEE2(pteval_t, pv_mmu_ops.pte_flags,
+				    pte.pte, (u64)pte.pte >> 32);
+	else
+		ret =  PVOP_CALLEE1(pteval_t, pv_mmu_ops.pte_flags,
+				    pte.pte);
+
+	return ret & PTE_FLAGS_MASK;
 }
 
 static inline pte_t __pte(pteval_t val)
diff --git a/arch/x86/include/asm/paravirt_types.h b/arch/x86/include/asm/paravirt_types.h
index 86bce9d..5890cd7c 100644
--- a/arch/x86/include/asm/paravirt_types.h
+++ b/arch/x86/include/asm/paravirt_types.h
@@ -288,7 +288,7 @@ struct pv_mmu_ops {
 	void (*ptep_modify_prot_commit)(struct mm_struct *mm, unsigned long addr,
 					pte_t *ptep, pte_t pte);
 
-	pteval_t (*pte_flags)(pte_t pte);
+	struct paravirt_callee_save pte_flags;
 	struct paravirt_callee_save pte_val;
 	struct paravirt_callee_save make_pte;
 
diff --git a/arch/x86/kernel/paravirt.c b/arch/x86/kernel/paravirt.c
index 4780367..ba22188 100644
--- a/arch/x86/kernel/paravirt.c
+++ b/arch/x86/kernel/paravirt.c
@@ -462,7 +462,7 @@ struct pv_mmu_ops pv_mmu_ops = {
 #endif
 #endif /* PAGETABLE_LEVELS >= 3 */
 
-	.pte_flags = native_pte_flags,
+	.pte_flags = PTE_IDENT,
 	.pte_val = PTE_IDENT,
 	.pgd_val = PTE_IDENT,
 
diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index 5b79048..24e275a 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -1965,6 +1965,13 @@ void __init xen_ident_map_ISA(void)
 	xen_flush_tlb();
 }
 
+#if defined(CONFIG_X86_32) && !defined(CONFIG_X86_PAE)
+/* 32-bit pagetable entries */
+#define PTE_IDENT	__PV_IS_CALLEE_SAVE(_paravirt_ident_32)
+#else
+/* 64-bit pagetable entries */
+#define PTE_IDENT	__PV_IS_CALLEE_SAVE(_paravirt_ident_64)
+#endif
 static void __init xen_post_allocator_init(void)
 {
 	pv_mmu_ops.set_pte = xen_set_pte;
@@ -1986,7 +1993,7 @@ static void __init xen_post_allocator_init(void)
 #endif
 
 	if (!pat_enabled)
-		pv_mmu_ops.pte_flags = native_pte_flags;
+		pv_mmu_ops.pte_flags = PTE_IDENT;
 #ifdef CONFIG_X86_64
 	SetPagePinned(virt_to_page(level3_user_vsyscall));
 #endif
@@ -2035,7 +2042,7 @@ static const struct pv_mmu_ops xen_mmu_ops __initconst = {
 	.ptep_modify_prot_start = __ptep_modify_prot_start,
 	.ptep_modify_prot_commit = __ptep_modify_prot_commit,
 
-	.pte_flags = xen_pte_flags,
+	.pte_flags = __PV_IS_CALLEE_SAVE(xen_pte_flags),
 	.pte_val = PV_CALLEE_SAVE(xen_pte_val),
 	.pgd_val = PV_CALLEE_SAVE(xen_pgd_val),
 
-- 
1.7.7.3


--YiEDa0DAkWCtVeE4
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--YiEDa0DAkWCtVeE4--


From xen-devel-bounces@lists.xensource.com Sat Dec 03 14:44:09 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 03 Dec 2011 14:44:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWqnW-0000lT-Q4; Sat, 03 Dec 2011 14:42:38 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RWqnV-0000k5-2d
	for xen-devel@lists.xensource.com; Sat, 03 Dec 2011 14:42:37 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1322923312!5723754!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDMxMjEy\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12251 invoked from network); 3 Dec 2011 14:41:53 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-9.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Dec 2011 14:41:53 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pB3EfOOI030957
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sat, 3 Dec 2011 14:41:24 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pB3EfLGa029790
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Sat, 3 Dec 2011 14:41:22 GMT
Received: from abhmt108.oracle.com (abhmt108.oracle.com [141.146.116.60])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pB3EfDlF027292; Sat, 3 Dec 2011 08:41:13 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Sat, 03 Dec 2011 06:41:12 -0800
Received: from phenom.dumpdata.com (localhost.localdomain [127.0.0.1])
	by phenom.dumpdata.com (Postfix) with ESMTP id 6AEA440189;
	Fri,  2 Dec 2011 18:31:25 -0500 (EST)
Received: (from konrad@localhost)
	by phenom.dumpdata.com (8.14.5/8.14.5/Submit) id pB2NVMn0012956;
	Fri, 2 Dec 2011 18:31:22 -0500
Date: Fri, 2 Dec 2011 18:31:22 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: linux-kernel@vger.kernel.org, x86@kernel.org, len.brown@intel.com,
	tglx@linutronix.de, jeremy@goop.org, hpa@zytor.com, bp@alien8.de,
	tj@kernel.org, trenn@suse.de
Message-ID: <20111202233122.GA12556@phenom.dumpdata.com>
References: <1320786914-10541-1-git-send-email-konrad.wilk@oracle.com>
	<1320786914-10541-3-git-send-email-konrad.wilk@oracle.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="YiEDa0DAkWCtVeE4"
Content-Disposition: inline
In-Reply-To: <1320786914-10541-3-git-send-email-konrad.wilk@oracle.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090207.4EDA3515.006A,ss=1,re=-2.300,fgs=0
Cc: mingo@redhat.com, xen-devel@lists.xensource.com, stable@kernel.org
Subject: Re: [Xen-devel] [PATCH 2/3] x86/cpa: Use pte_attrs instead of
 pte_flags on CPA/set_p.._wb/wc operations.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--YiEDa0DAkWCtVeE4
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

> The fix, which this patch proposes, is to wrap the pte_pgprot in the CPA
> code with newly introduced pte_attrs which can go through the pvops interface
> to get the "emulated" value instead of the raw. Naturally if CONFIG_PARAVIRT is
> not set, it would end calling native_pte_val.
> 
> The other way to fix this is by wrapping pte_flags and go through the pvops
> interface and it really is the Right Thing to do.  The problem is, that past
> experience with mprotect stuff demonstrates that it be really expensive in inner
> loops, and pte_flags() is used in some very perf-critical areas.

I did not get to verify the mprotect stuff as I need to chase down the details of it,
but I did run some benchmarks using kernbench on three different boxes:

 AMD A8-3850 (8GB) - tst005
 Intel i3-2100 (8GB) - tst007
 Nehelem EX (32logical cpus) (32GB) - tst010

I've put all the kernebench results in https://www.dumpdata.com/results/baseline_pte_flags_pte_attrs/
(and the chart for the AMD is attached).

The boxes have a fresh install of F16, with a 3.2-rc3 variant kernel using the
.config that F16 came with. I just hit Enter when oldconfig asked me to choose.

The baseline is virgin v3.2-rc3. The pte_attrs is the patch that this email is
replaying too (on top of v3.2-rc3). The pte_flags are two patches that wrap pte_flags
in paravirt and use alternative_asm to patch the code (on top of v3.2-rc3).

The patches are in the URL mentioned or in my git branch as
devel/pte_attrs.v1 ( git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git).
I am also attaching them in this email.

The summary is that I could only get the numbers to show some difference when
the maximum load was run - and _only_ on the AMD machine. The small SandyBridge
and the big SandyBridge had no trouble with. The AMD machine the difference was
13% worst if pte_flags (so alternative_asm) was used instead of pte_attrs.

The way I did these tests is to bootup with 'init=/bin/bash', remount / as rw, activate
swap disk and run kernbench on the v3.2-rc3 linux tree. Then unplug the machine for a tea
break and then repeat the cycle with a different kernel.

--YiEDa0DAkWCtVeE4
Content-Type: image/png
Content-Disposition: attachment; filename="AMD-A8-3850.png"
Content-Transfer-Encoding: base64

iVBORw0KGgoAAAANSUhEUgAAAlgAAAFzCAIAAABth+DjAAAlZElEQVR42u2dC1BU1/3HTZN2
mqR51DSd6WP6IDwWRmJAEFfSglMBVyQhUK0g465W8VEznUYlShkIE7XNtE3DqOlAZEQjGLSJ
bYogsalaJcWMYhyhlEdHMWR88FbeC/j/xfvPne3u3XVBWIH9fOYMc/bsvWfvft1zPp69l8uU
WwAAAG7MFCIAAABECAAAgAgBAAAQIQAAACIEAABAhAAAAIgQAAAAEQIAACBCAAAARAgAAIAI
AQAAECEAAAAiBAAAQIQAAACIEAAAABECAAAgQgAAAEQIAACACAEAABAhAAAAIgQAAECEAAAA
iBAAAAARAgAAIEIAAABECAAAgAgBAAAQIQAAACIEAABAhAAAAIgQAAAAEQIAACBCAAAARAgA
AIAIAQAAECEAAAAiBAAAQIQAAACIEAAAABECAAAgwvGX7Bc0NjbKw48++khtGUE/d3kY9p6t
qalRj+rf//63M0eu1u+//36dTldYWOhkt5cuXTIYDA899NDDDz8cHR19+fJlq70++eSTuXPn
yrNf/epXw8PDz507Z28vObAp/4s0Xr9+fcmSJY/eJikpqampSfMt2zuMsrKykJAQeenHHnss
NjZWabd8CXkqNDS0urqazzYAIoThiTA/P18e/v73vx+ZCEflMOw9m5ubqx7VW2+95cyRq5X2
9vaIiIj77rvv2LFjznQ7e/ZseVhUVPT+++9L5dlnn7Xaa8GCBY888sjx48fPnz8vG3z3u9+1
t9e7774rddnecvfk5GRplJfOycmRyqpVqzTfsmaHYmvx3Lx58+RN7d+/X9pnzpxp+WYHBwcP
Hz4s9eDgYD7bAIgQhmEgDw8PmaDlYVxc3FNPPaVOrLKw+PGPf/zggw9++ctf9vPzKykpOXv2
rKyxnnnmGZlz+/v7p02bJg+l0cpAe/fulbl46tSpW7du3blz55NPPvn973+/uLhYs887inD5
8uXyrF6vl58mk8mZI7fs8MSJE7ZCstetmEYe9vX19fb2SkWOU/OQZANFRbI+s7fXyy+/LPXX
X3/dckdvb29plIXg1atXpSIPNfvX7HDhwoVSl7Wvg/9GyC5Sl3Ukn20ARAjDEOHSpUt9fHzk
4be+9S2j0ahOrIGBgfv27TObzYrqvv3tb0vj+vXrpf7mm29u27ZNKhs3brSci5XKL3/5y3Pn
zin1devWnT59Wirf+9737PXpWISKPP785z/LTy8vL2eO3LLDzs5OqYuMnek2ISFBHsq66q9/
/atUpE/NQ/rBD34gz4rdr1y5Ym+v8PBwqT/xxBOi/J/85CfKlqI0aZS3L/+NkMpDDz2k2b9m
h9/4xjekLm/HngiHhoaUt7Np0yY+2wCIEIYhwrfeekt+/utf/5Kfu3btsrTIxx9/vGHDBn9/
f2m57777pKWrq+uHP/yhrPZkTpcFmTy0FWFLS4ssGZW6rH6UurK7Zp8ORHj9+nV56vHHH5dO
5EWlfu3atTseuWWHogepP/DAA850297e7unpqez+6KOP2juHJ+9a+TJ2yZIl9vYS+X3nO9+p
qqr605/+JO2xsbHSKO9XlZZUvvSlL2n2r9mhvAV5KAd8y+Kb4Vv/e45QmDFjxn/+8x8+2wCI
EIYhwurqavkZExMjP2UOVWfYP/7xj0q7sqRT1ZKenq48/NWvfmW1KLHcTLOu2acDER46dEie
ioqKkvr8+fOlLi13PHLLDkVaUv/617/uTLc/+9nPpP6Xv/xFWYr99Kc/tRfdjRs31C8hHe+l
LEmVxZ/8dGZFqNmhrJ6lLo60l/nAwEB+fr7Un3rqKT7bAIgQhiFCqTz55JOyWPnmN79p2fi1
r31NKjdvozbK6kSkIpPyY489JvP4p59+OiwRavbpQISydrRa8UjLHY/cskPFuJGRkc50q5yc
672NchGm1fLLSoTKN66ae1kuH1UT+/n5SV3Wo8o5QuV7XVs0O5TVp9RPnDhx6/Z1MZpvVjlH
+JWvfIXPNgAihOGJMDY2ViovvPCCZaOyBDl+/Pgf/vAHtXHFihVSycvLy8rKUr8bdF6Emn06
MOKsWbOUtZHUCwoKlMtb7njkaqW7u3vRokViyqNHjzrT7bPPPiv1d999929/+5tUwsLCrBL7
0Y9+9OCDD4qNdu/eLRu8/PLL9vaSRhHYsWPH9u7dq5wrVQWcexv1qlHbd63ZYWVlpXQoRpdF
oXKC1urNDg0NKVeNzp49m882ACKE4YlQ0ZL8tGw8cODAE0888fjjj//85z9XGj/++GORSmBg
oMy5AwMDTz/9tDwsLy93XoS2fVoJ7P7771cPr6enRxY30qj8wlx9fb2y3JF2x0euruEeeOCB
adOmieos37WDbj/77LO4uLiHH35YbLdgwQLllxQt+eSTT8LDw0VI8hZeeukls9ksjZp7yZYi
MGXLtWvXytpOWUcuXrxYlsWPPPJIQkKCLA1t37W9DoVTp06JwuVQH330UTkMkbHlm5V/C1mj
i0Q5RwiACGGi8o9//EO9gJN3DQCACN2OiIgI2998510DACBCAABAhAAAAIgQAAAAEQIAACBC
AAAARAgAAIAIAQAAECEAAAAiBAAAQIQAAACIEAAAABECAAAgQgAAAEQIAACACAEAABAhAAAA
IgQAAECEAAAAiBAAAAARujEzZswgBFvOnDlDCGRCLGOayYzkM3cshIkIESGzG5kQCyL8Hzw8
PEb9gNU+x6JzRIgImd3IhFjIZMKIkBUhIgRmNzIhlgkgwqqqqsjIyMTExObmZqXx/Pnzzz//
vI+Pz6xZsw4cOKA0lpaWent7e3l5RUdHl5eXK43t7e0mk0mn0xmNxo6ODnsrQqlkZ2eHhoZK
D9KPg30RISJkdiMTYiEWV4tw8+bNvb29J06c2Lhxo9IoXiwqKurr63vvvfcCAgKURnFYfn7+
wMCAmCwsLExpTE1NrampMZvNJSUlGRkZDkSYmZnZ1dWl2NTBvogQETK7kQmxEIurRXjlyhWp
iPaCg4OtnhXtqTJLSkpavXp1WVlZT0+PukFISIhsI5XBwUG9Xu9AhG1tbVaNmvsiQkTI7EYm
xEIsrhahYqOhoSEvLy+lsbm5OSsra9WqVeHh4aq3WlpaEhMTdTqdv79/ZWWl0ii7eHyBurum
CC1f0cG+iBARMruRCbEQi6tFeO7cOanIOk9dlsXExLzxxhvHjh2rq6uzuvKlt7e3sLBQFnPK
w6CgILPZbNunMyLU3BcRThIROvNxdHFhdmPGJxZEaE+ECxcuFL0dPXo0PT1daZw2bdqFCxdu
3LghLaq3lBOHyjlC9TxfSkpKdXW1NIod4+PjhyVCzX0RISJEhMxuxEIsrhZhTU1NRESEyWQS
8ymNhw8fnjt3rkxmubm5qrcqKipkM09PT8srP9va2oxGo7QYDIba2tphiVBzX0SICBEhsxux
EItLRejOIEJEyOxGJsSCCBEhIEJmNzIhFjJBhIAIGclkQixkgggBETKSyYRYyAQRjgYeNqjt
rnljVi/kocWYHg+/R8hIJhNiIRN3F+Gw2iffAYgI6/VTx1VhJDO7EQuZwDgSoeZNzeXZoqKi
6dOnL1y4sKmpSWl0/k7nra2tS5Ysefrpp9955x0nRWi5VM3Pzw8KChKBHTly5OTJk3q9/m7u
j44IGclkQixkgggdtWve1Fye3bRpU09PT0FBQUpKitLo/J3OZd/CwsLe3l55dgQiTE9P7+zs
LC4uNhgMO3fuvMv7oyNCRjKZEAuZuLsInTxHaHlTc6k0NjZK5ebNm+ot7Jy/07ksLsVkUvns
s89GIELlT3Apx6P0c+su7o+OCBnJZEIs9ySTUZwN+vv7R+XI1X5Gq8NJsiLUvKm5VEQzimzU
pZjzdzqXytDQkJVcnRehsu+tUbo/OiJkdiMTYpnoIoyMjByVI1f7Ga0OJ4kINW9qLhXl1GB7
e3toaKjljs7c6VwWasot8q5fvz4CEWpuM+L7oyNCZjcyIZaJLsLRurrQ9b84MDFEqHlTc6ls
2bKlr69v7969mZmZ6v8gnLzTuXSVn58vu8u+oy7C4d4fHREyu5EJsUwgEdpeq2h5Ysv5qwVt
L4S096trO3bsiIqKumXnishJIkLH5wg1b2oulV27dvn7+ycnJ6tn6Zy/07loVf6pZOkmOhx1
EQ73/uj8HiGzG5kQy8QSoe21iuoE6PzVgvYuhLStyKKiq6vrlp0rIieDCEd3HTkR+VyE2VMm
RmF2Y8YnFkSoda3iiK8WvGVzIaRtRVaZSl3zikhEiAgRIbMbsRCLq0Voe63iCK4WtHchpL3K
LTtXRLqvCCcTiJDZjUyIZWKJ0PZaxRFcLWjvQkgHIlSwuiISESJCRMjsRizE4moR2l6rKIu/
1tbWW8O5WlDzQki1H7ViKULNKyIRISJEhMxuxEIsrhah7bWKUtfpdLeGc7Wg5oWQaj9qxVKE
mldEIkJEiAiZ3YiFWFwtQrcNFhEiQkTIjE8siHDYIrT3t+0QIfyvCIHZjUyIhUwQISIERjKZ
EAuZIEJECIxkMiEWMkGEiBAYyWRCLGSCCBEhI5kQyIRYyAQRIkJGMpAJsZAJIkSEjGQgE2Ih
E0SICBnJQCbEMsqZjN5vD/f39yNCQITMbmRCLO4rwsjIyOEeZGlpqY+Pz7Zt2ybQ79cjQkTI
7EYmxIIItRmBzJT7hQ4NDSFCQITMbmRCLBNJhOKtoqKi6dOnL1y4UPl7TJY3TmtvbzeZTDqd
zmg0dnR0OBCnuosqwvPnzz///POyTJw1a9aBAweUxpaWlsWLF8s8uXv3bnVL5a9PeHl5RUdH
l5eXI0JEyOxGJsQCLhXhpk2benp6CgoKUlJSrFaEqampNTU1ZrO5pKQkIyPDmUWkWlH+ylJf
X997770XEBCgdpiTkyMvJxV1S7Fgfn6+8veYwsLCECEiZHYjE2IBl4qwsbFRKjdv3lT/Oq6q
KGkRP926/ffr9Xr9sESoIj2ojdKJrDKlcuXKFbUxKSlp9erVZWVlIkhXBosIESGzG5kQCyL8
3FsiOUV16l/HtfzLuurXnlIflgibm5uzsrJWrVoVHh5u2eHQ0JCVHVtaWhITE3U6nb+/f2Vl
JSJEhMxuZEIs4FIRKqcGZaEWGhpqJbOgoCCz2ezMi9uKMCYm5o033jh27FhdXZ3lElNZEV69
etVq7djb21tYWKiuShHhxBbhjOQzFMvC7MaMTyzjWYRbtmzp6+vbu3dvZmamum5rbW2VSkpK
SnV1tazeRFHx8fHDEuG0adMuXLhw48aN9PR0tfHXv/71rl275OVeeeUVq7OJyjlCdVWKCBEh
ImR2IxZwkQjFTP7+/snJyZ2dnUqj1HU6nVTa2tqMRqPIyWAw1NbWDkuEhw8fnjt3rsyIubm5
aqN0mJCQ8Mwzz+Tk5IgplcaKioqIiAhPT0/ldzAQISJEhMxuxAIuFaHr35HZbN6/f39iYuK9
DRYRIkJEyIxPLIhw2CL00ML53devXx8QEODj47No0aJLly4hQkSICJndgFjIBBEiQkTI7AbE
QiaIEBEiQmY3IBYycXcR2n7LPCqncO19nT1254f5PUJGMpkQC5kgwnEkwjHqzbEI6/VTKZaF
kczsRixkggjvSoSaNybXvCe67LJjx46oqKg79m/5Ky/5+flBQUEisCNHjpw8eVKv11v+LouT
N19HhIiQ2Y1YyAQRjpUINW9MrnlPdNmlsLCwq6trWCJMT0/v7OwsLi42GAw7d+6U3S3vbuD8
zdcRISJkdiMWMkGEYyJCzRuTa94TXXZR7mI3LBE2Nzff+uIOsOqNFUZw83VEiAiZ3YiFTBDh
yJEVmOIbBan7+Pgodc0bk2veE93BiUAHIlRuhW61zQhuvo4IESGzG7GQCSIcOc8995zlXQbq
6uri4uIsN7C6MbnmPdFHJkLNbUZw83VEiAiZ3YiFTBDhyDlx4oTJZLp48aKsBRsaGlasWHH6
9GnlKc0bk2veE30sROj8zdcRISJkdiMWMkGEd8WhQ4dCQ0M9PT1nz54t5lPbNW9MrnlP9LEQ
ofM3X1dFyMeLkUwmxEImiNB9+VyEztz61q0KI5nZjVjIBBEiQkTIZ4PZjVjIBBEiQkQIzG7E
QiaIEBEiQmB2IxYyQYSIEBECmRALmSBCRIgImd2AWMgEESJCRMjsBsRCJohwsokQGMlkQixk
gggRITCSyYRYyAQRIkJgJJMJsZAJIkSEwEgmE2IhE0SICBnJhEAmxEImiBARMpKBTIiFTBAh
ImQkA5kQC5kgQkTISAYyIRYyQYSIkJFMJkAsZIIIESEjmUyAWMgEESJCRjKZALGQCSJEhIxk
MgFiIRNEiAgZyWRCLEAmiBARMpLJhFiATBAhImQkkwmxAJkgwokpwhnJZ0alMJKZ3YgFyAQR
IkJGMrMbsZAJmSBCRMhIZnYjFjIBRIgIGcnMbsRCJoAIESEjmUyIhUwAESJCRjKZEAuZgDuI
sL+/HxEykpndiAXIZGKLsKGhwWQy+fn5BQYGpqamdnV1Ob9vZGTk3R+AhxZK+9iJkI8XI5lM
iIVMEOH/ExcXl5ub29PT09bWtnXr1rS0tGE5bBSPZOzMZyvCev3UUSmMZGY3YgEymfAi9PX1
VVeBAwMDQUFBUpk7d+7ly5elcvHixYiICKmUlpZ6e3t7eXlFR0eXl5dbruSk3t7eLstKnU5n
NBo7OjpUseXn50uHIp4jR46cPHlSr9dLJ9KVMyJUH96xH81XR4SMZDIhFjJBhE6xdu3ajIyM
gwcP1tfXq42//e1v8/LypCI/ZZkoFRGP2EhMKfoJCwuzclVqampNTY3ZbC4pKZHe1GfT09M7
OzuLi4sNBsPOnTvFuIpQhytCx/1ovjoiZCSTCbGQCSJ0ira2trS0tNjYWFntyeKvqqpKGs+e
Pbt06VKpyErr1KlTUklKSlq9enVZWVlPT4+tq0JCQsSRUhkcHJTlmvpsc3OzstCUuphMU3jO
iNBxP5qvjggZyWRCLGSCCIfHzZs3s7OzZcmlGGX27NlNTU3iDOXS0JaWlsTERJ1O5+/vX1lZ
aaUikaj6TanU1WeHhoZsJTcCETruR/PVESEjmUyIhUwQoVMEBASo5wj7+vp8fX2V+qZNm2Sl
mJycbLlxb29vYWGhrMCsVBQUFGQ2mx2I7S5F6LgfzVdHhIxkMiEWMkGETrF58+asrCxZ/HV3
d2/fvt1kMintf//735XzgsrDyMjIoqIi5RyhenJOll+tra1SSUlJqa6ulmdFk/Hx8S4Woear
I0JGMpkQC5kgQqfo7OwUkQQGBvr5+a1cufLatWtKe0dHh5imsbFReVhRUREREeHp6Wl5uaas
F3U63a3bJxqNRqM8ZTAYamtrXSxCzVd3LEI+XoxkMiEWMkGEd+Cjjz6KiYmZlMl+LsLsKaNT
GMnMbsQCZDJZRejv73/kyBFEiAiZ3YBYyMRNRTiJQYSMZDIhFjJBhIgQETKSyYRYyAQRIkJE
yEgmE2IhE0SICBEhI5lMiIVMECEiRISMZDIhFjJBhG4lQmAkkwmxkAkiRITASCYTYiETRIgI
gZFMJsRCJogQEQIjmUyIhUwQISJkJBMCmRALmSBCRMhIBjIhFjJBhIiQkQxkQixkgggRISMZ
yIRYyAQRIkJGMpkAsZAJIkSEjGQyAWIhE0SICBnJZALEQiaIEBEykskEiIVMECEiZCSTCbEA
mSBCRMhIJhNiATJBhIiQkUwmxAJkgggnpghnJJ+hjLfC7MakTyaACBEhImR2Y9InE0CEiBAR
Mrsx6ZMJIEJEiAiZ3Zj0yQQQISJEhMxuTPpkgggBESJCZjdiIRNEOCnp7+9HhBREyKRPJjAu
ROjxBd7e3gsWLDh//rwLXjQyMtK2saKiIiEhwc/PLzU1tbGx8Y5HKC2278UZEfLxYiSTCbGQ
CSLUkMfAwMC+ffvmz5/vyhdVqaqqCg4OLi4u7urqunjxYlJS0p49exwf4YhFWK+fShlvhdmN
SZ9M4N6LUOju7pZVl1Jvb283mUw6nc5oNHZ0dKgb79ixIyoqSuqiq3nz5gUEBHzwwQeOd8nO
zg4NDZWeS0tLLVd4lofx4osvFhQUqA8vX768YcMGx0eICBEhsxuxkAkiHE0R9vb25uTkvPDC
C8rD1NTUmpoas9lcUlKSkZGhblxYWCiLNqmvWbMmLy9PPgFhYWGOd8nMzJRdxIIOHDZz5sxr
164N6wgRISJkdiMWMkGEoyNCBVnJxcfHi8mU9pCQkIGBAakMDg7q9Xp1Y1n2qUZpa2uz7Mre
LupmqqhsjSWOVPZ1/ggRISJkdiMWMkGEo/zVqCVeXl6qgaRuu7E0Dg0NDWsXByKcNWuW5YpQ
elaNa+8IrdwpdR8fH0SICJndiIVMEOHoiDAoKMhsNjvYOCAgQD0R6OQuDkS4bt26AwcOqA/P
nj07Z84cx0f43HPPXbp0SX1YV1cXFxeHCBEhsxuxkAkiHB0RpqSkVFdXyzKrsLAwPj7eduMV
K1bIUxUVFaqx7riLWpf1Ymtrq+XLST/BwcEffvhhb2+vdBIVFbVv3z7HR3jixAmTyXTx4kV5
xYaGBjme06dPI0JEyOxGLGSCCEdHhG1tbUaj0dvb22Aw1NbW2m4sKzBRYGBg4PHjx53cRa0n
JyfrdDqrVzx69Oj8+fPFkXq9Picn545HKBw6dCg0NNTT03P27NlFRUXOvF9+j5CRTCbEQiaI
0K35XITZUyjjojC7MemTCSBCRIgImd2Y9MkEECEiRITMbkz6ZAKIEBEiQmY3Jn0yAUSICBEh
sxuxkAkgQkSICJndiIVMABEiQkTI7EYsZIIIYaxECIxkMiEWMkGEiBAYyWRCLGSCCBEhMJLJ
hFjIBBEiQmAkkwmxkAkiRISMZEIgE2IhE0SICBnJQCbEQiaIEBEykoFMiIVMECEiZCQDmRAL
mSBCRMhIJhMgFjJBhIiQkUwmQCxkgggRISOZTIBYyAQRIkJGMpkAsZAJIkSEjGQyIRYgE0SI
CBnJZEIsQCaIEBEyksmEWIBMEOHEFOGM5DMUCmViFUSICAERUiiIEBEiQkCEFAoiRISIEBAh
hYIIESEiBERIoSBCRIgIARFSKIgQESLCu6e/v3+MNnZxb4iQQkGEiNAdRVhRUZGQkODn55ea
mtrY2DiCV4qMjLybjRsaGkwmkxxAYGCgHENXV9cdO/Hw8LjjS6vbjIUI+XgxksmEWMhkkoiw
qqoqODi4uLhY9HPx4sWkpKQ9e/YM95WGpRzbjePi4nJzc3t6etra2rZu3ZqWljYqLz2mIqzX
T6VQKBOuIEJEqMGLL75YUFCgPrx8+fKGDRuUelNTU2Jioo+Pz9KlS0VRql2ys7NDQ0O9vb1L
S0uVFgWpt7e3y9pOp9MZjcaOjg5pWbZs2alTp6Ry/PjxlStXWm6s4uvrq64CBwYGgoKCpDJn
zhw5GEXVsr0sW5W1Y3h4uCo5y97E4vPmzQsICPjggw/UQ33//fdllakequYRCvKsbOPl5RUd
HV1eXo4IKRREiAjdSIQzZ868du2a5lMvvfTS/v37zWbzvn37Nm7cqNolMzNTvKXIw2rtlZqa
WlNTI7uUlJRkZGRIS11d3YIFC3p7e+fPny+u0lyorV27VjY+ePBgfX292vjKK6/Iq0slJyfH
z89vx44dUn/77bfT09MtO1Era9asycvLkw9TWFiY+tRrr73W3d1teai2RyjIs/n5+eJg2VLd
HRFSKIgQEbqFCMUBIgDNp2Rl1tnZKZUbN24oqzTFLparQ6tKSEiI0tvg4KBer1eVtmjRoi1b
ttj7xlI6TEtLi42NlTVZRESELAGVFeQvfvELZU35u9/9bsmSJVJPTk4+evSo5kuLnNQDU5+S
9Z8zR5iUlLR69eqysrKenh6+GqVQECEidC8Rzpo1y3JFODQ0pMpDtKRUxBmenp62GrO1keyi
fl2p7i4LQXn46aef3vHU3c2bN7Ozsw0Gg9TFSSKqvr4+OUIx8fTp08XKgYGBips1X1oO3t45
QsdH2NLSkpiYqNPp/P39KysrESGFgggRoRuJcN26dQcOHFAfnj17ds6cOeqKsLu723ZF6ECE
spnZbLZ6CWVF+Oqrr9oTYUBAgHqOUMzn6+ur1E0m0+7du1euXCn1hISE119/XX7ae2npRD3n
5+BQNY9Qobe3t7CwUJaMiJBCQYSI0I1EWFFRERwc/OGHH4oGqquro6Ki9u3bpzy1fv36oqKi
gYGB/fv3q1fQ2Ftmtba2SiUlJUU6kV3EKPHx8co5wpiYGNHb/Pnz//vf/1purLJ58+asrKym
pibx7vbt28V/SnteXp546+2335b6jh07pk2b9uabb9p76RUrVsiLyttRRa55qLZHeOv272Ao
79TybCIipFAQISJ0CxEKR48eFUuJUfR6fU5Ojtre3NwsKzCdTidmsj0vaFlPTk6WzZSzfUaj
UVxiMBhqa2strxr95z//uXz5csuNVTo7O8VPgYGBfn5+sv5Tv6pVvlNtaGhQhC31Cxcu2Htp
Ma4oUDo5fvy4g0O1PUKl84iICE9PT8vrSx2LkI8XI5lMiIVMJo8IYbh8LsLsKRQKZYIVRIgI
ARFSKIgQESJCQIQUCiJEhIgQECGFgggRISIEREihIEJEiAgBEVIoiBARIkJAhBQKIkSEiBCG
J0JgJJMJsZAJIkSEwEgmE2IhE0SICIGRTCbEQiaIEBECI5lMiIVMECEiZCQTApkQC5kgQkTI
SAYyIRYyQYSIkJEMZEIsZIIIESEjGciEWMgEESJCRjKZALGQCSJEhIxkMgFiIRNEiAgZyWQC
xEImiBARMpLJBIiFTBAhImQkkwmxAJkgQkTISCYTYgEyQYSIkJFMJsQCZIIIJ6YIZySfoVAo
riyIEBAhIqRQECEiBESICCkURIgIAREiQgoFESJCQISIkEJBhIgQECEipFAQISIERIgIKRRE
iAhhkouwoaHBZDL5+fkFBgampqZ2dXUp7R4eHvdKhHy8GMlkQixkgghdR1xcXG5ubk9PT1tb
29atW9PS0u65COv1UykUissKIgR3F6Gvr6+6ChwYGAgKCrISYXt7uywZdTqd0Wjs6Ohw0Ci7
FBUVTZ8+feHChU1NTUpjaWmpt7e3l5dXdHR0eXk5IqRQECEiRITji7Vr12ZkZBw8eLC+vt6y
XRVhampqTU2N2WwuKSmRLR00yi6bNm2SxWVBQUFKSorSKBbMz88XxYoRw8LCECGFgggRISIc
X7S1taWlpcXGxsqiLSIioqqqykqEISEhojGpDA4O6vV6B42yS2Njo1Ru3rwpGyiNSUlJq1ev
LisrE0Hy1SiFgggRISIcv4i9srOzDQaDlQhFkB5fIHUHjVIXLyp2lIWg0tjS0pKYmKjT6fz9
/SsrKxEhhYIIESEiHF8EBASo5wj7+vp8fX2tRBgUFGQ2m6320myUXZRTg+3t7aGhoZZP9fb2
FhYWqstEREihIEJEiAjHC5s3b87KyhKBdXd3b9++3WQyWYkwJSWlurp6YGBATBYfH++gUXbZ
smWL2HTv3r2ZmZlKY2RkZFFRkXKOUF0mIkIKBREiQkQ4Xujs7BSrBQYG+vn5rVy58tq1a1Yi
bGtrMxqN4jCDwVBbW+ugUXbZtWuXv79/cnKydKs0VlRUREREeHp6ysbiQmdEyMeLkUwmxEIm
iHBCMiq/evi5CLOnUCgUlxZECIgQEVIoiBARAiIcFyBCCgURIkJEiAiZmCgURIgIESEipFAo
iBARIkJESKFQECEiRISIkEKhIEJEiAjdSoTASCYTYiETRIgIgZFMJsRCJogQEQIjmUyIhUwQ
ISIERjKZEAuZIEJEyEgmBDIhFjJBhIiQkQxkQixkgggRISMZyIRYyAQRIkJGMpAJsZAJIgQA
AECEAAAAiBAAAAARAgAAIEIAAABECAAAgAgBAAAQIQAAACIc/9y4cWPx4sWWLfX19SaTad68
eWvWrKmsrCQKqyjcIZ+7iWKS5TPqUUzcfFwThdvOP4jwnnH9+nX5tM2dO9ey8Te/+c0777zT
19eXl5f36quvEoVVFJM+n7uMYjLlMxZRTNB8XBaFe84/iPBesmjRosOHD1t9uJctW9be3i6V
q1evLl++nCisopj0+dxlFJMpn7GIYoLm47Io3HP+QYT3kpaWFvlp9eGOiYkZGBiQSn9/f3R0
NFFYRTHp87nLKCZTPmMRxQTNx2VRuOf8gwjvPVYf7oiICKUyNDSk1olCrbtJPiOOYvLlM7pR
TOh8XBCFO88/iHAcfbjlf2Fms1kq8lP+d0YUVlG4ST4jjmLy5TO6UUzofFwQhTvPP4hwHH24
ly1b1tTUdOv26XGpE4VVFG6Sz4ijmHz5jG4UEzofF0ThzvMPIhxHH+7XXnttz5493d3d8nPb
tm1EYRWFm+Qz4igmXz6jG8WEzscFUbjz/IMIx9GHu6qqymg0zps3T37W1dURhVUUbpLPiKOY
fPmMbhQTOh8XROHO8w8iBAAAQIQAAACIEAAAABECAAAgQgAAAEQIAACACAEAABAhAAAAIgQA
AECEAACACAEAABAhAAAAIgQAAECEAAAAiBAAAAARAgAAIEIAAABECAAAgAgBAAAQIQAAACIE
AABAhAAAAIgQAAAAEQIAACBCAAAARAgAAIAIAQAAECEAAAAiBAAAQIQAAACIEAAAABECAAAg
QgAAAEQIAACACAEAABAhAAAAIgQAAECEAAAAiBAAAAARAgAAIEIAAABECAAAgAgBAAAQIQAA
ACIEAABAhAAAAIgQAAAAEQIAACBCAAAARAgAAIAIAQAAECEAAAAiBAAAQIQAAAB35P8AX8gY
XW/o2AIAAAAASUVORK5CYII=

--YiEDa0DAkWCtVeE4
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="0001-x86-paravirt-xen-Introduce-pte_flags.patch"

>From 6f30ff305df4d36160641ad7232c39f58afc5c4a Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Mon, 28 Nov 2011 17:33:47 -0500
Subject: x86/paravirt/xen: Introduce pte_flags.

We are providing a version of pte_flags where the processing
under Xen goes couple of extra steps (if pat is enabled).

The baremetal version looks quite identical to the pte_val
one and the idea is to piggyback on the DEF_NATIVE/PTE_IDENT
mechanism that pte_val uses for baremetal.

Specifically we move the logical processing of "& PTE_FLAGS_MASK"
out of the functions to minimize the amount of operations
the paravirt operations have to do. This benefits us greatly
as this way we don't have do that logical operations in the function:
(native_pte_flags):

	pushq	%rbp
	movq	%rdi, %rax
	movabsq	$-70368744173569, %rdx
	andq	%rdx, %rax
	movq	%rsp, %rbp
	popq	%rbp
	ret

but instead the paravirt function ends up being:

	pushq	%rbp
	movq	%rdi, %rax
	movq	%rsp, %rbp
	popq	%rbp
	ret

and the logical "and" operation is done outside the call.

This means that the only real operation that native_pte_flags
is "movq %rdi, %rax" we can take advantage of the PTE_IDENT
functionality introduced in patch:
"x86/paravirt/xen: Optimize pte_flags by marking it as paravirt_ident_[32|64] type."

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 arch/x86/include/asm/paravirt.h       |    5 +++++
 arch/x86/include/asm/paravirt_types.h |    1 +
 arch/x86/include/asm/pgtable.h        |    1 +
 arch/x86/include/asm/pgtable_types.h  |    4 ++--
 arch/x86/kernel/paravirt.c            |    1 +
 arch/x86/xen/mmu.c                    |   13 +++++++++++++
 6 files changed, 23 insertions(+), 2 deletions(-)

diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h
index a7d2db9..6533409 100644
--- a/arch/x86/include/asm/paravirt.h
+++ b/arch/x86/include/asm/paravirt.h
@@ -462,6 +462,11 @@ static inline void pmd_update_defer(struct mm_struct *mm, unsigned long addr,
 	PVOP_VCALL3(pv_mmu_ops.pmd_update_defer, mm, addr, pmdp);
 }
 
+static inline pteval_t pte_flags(pte_t pte)
+{
+	return pv_mmu_ops.pte_flags(pte) & PTE_FLAGS_MASK;
+}
+
 static inline pte_t __pte(pteval_t val)
 {
 	pteval_t ret;
diff --git a/arch/x86/include/asm/paravirt_types.h b/arch/x86/include/asm/paravirt_types.h
index 8e8b9a4..86bce9d 100644
--- a/arch/x86/include/asm/paravirt_types.h
+++ b/arch/x86/include/asm/paravirt_types.h
@@ -288,6 +288,7 @@ struct pv_mmu_ops {
 	void (*ptep_modify_prot_commit)(struct mm_struct *mm, unsigned long addr,
 					pte_t *ptep, pte_t pte);
 
+	pteval_t (*pte_flags)(pte_t pte);
 	struct paravirt_callee_save pte_val;
 	struct paravirt_callee_save make_pte;
 
diff --git a/arch/x86/include/asm/pgtable.h b/arch/x86/include/asm/pgtable.h
index 18601c8..eebf625 100644
--- a/arch/x86/include/asm/pgtable.h
+++ b/arch/x86/include/asm/pgtable.h
@@ -76,6 +76,7 @@ extern struct mm_struct *pgd_page_get_mm(struct page *page);
 #define __pmd(x)	native_make_pmd(x)
 #endif
 
+#define pte_flags(x)	(native_pte_val(x) & PTE_FLAGS_MASK)
 #define pte_val(x)	native_pte_val(x)
 #define __pte(x)	native_make_pte(x)
 
diff --git a/arch/x86/include/asm/pgtable_types.h b/arch/x86/include/asm/pgtable_types.h
index 013286a..4c957e8 100644
--- a/arch/x86/include/asm/pgtable_types.h
+++ b/arch/x86/include/asm/pgtable_types.h
@@ -270,9 +270,9 @@ static inline pteval_t native_pte_val(pte_t pte)
 	return pte.pte;
 }
 
-static inline pteval_t pte_flags(pte_t pte)
+static inline pteval_t native_pte_flags(pte_t pte)
 {
-	return native_pte_val(pte) & PTE_FLAGS_MASK;
+	return pte.pte;
 }
 
 #define pgprot_val(x)	((x).pgprot)
diff --git a/arch/x86/kernel/paravirt.c b/arch/x86/kernel/paravirt.c
index d90272e..4780367 100644
--- a/arch/x86/kernel/paravirt.c
+++ b/arch/x86/kernel/paravirt.c
@@ -462,6 +462,7 @@ struct pv_mmu_ops pv_mmu_ops = {
 #endif
 #endif /* PAGETABLE_LEVELS >= 3 */
 
+	.pte_flags = native_pte_flags,
 	.pte_val = PTE_IDENT,
 	.pgd_val = PTE_IDENT,
 
diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index 87f6673..5b79048 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -412,6 +412,16 @@ static pteval_t iomap_pte(pteval_t val)
 	return val;
 }
 
+static pteval_t xen_pte_flags(pte_t pte)
+{
+	pteval_t pteval = pte.pte;
+
+	/* If this is a WC pte, convert back from Xen WC to Linux WC */
+	if ((pteval & (_PAGE_PAT | _PAGE_PCD | _PAGE_PWT)) == _PAGE_PAT)
+		pteval = (pteval & ~_PAGE_PAT) | _PAGE_PWT;
+	return pteval;
+}
+
 static pteval_t xen_pte_val(pte_t pte)
 {
 	pteval_t pteval = pte.pte;
@@ -1975,6 +1985,8 @@ static void __init xen_post_allocator_init(void)
 	pv_mmu_ops.release_pud = xen_release_pud;
 #endif
 
+	if (!pat_enabled)
+		pv_mmu_ops.pte_flags = native_pte_flags;
 #ifdef CONFIG_X86_64
 	SetPagePinned(virt_to_page(level3_user_vsyscall));
 #endif
@@ -2023,6 +2035,7 @@ static const struct pv_mmu_ops xen_mmu_ops __initconst = {
 	.ptep_modify_prot_start = __ptep_modify_prot_start,
 	.ptep_modify_prot_commit = __ptep_modify_prot_commit,
 
+	.pte_flags = xen_pte_flags,
 	.pte_val = PV_CALLEE_SAVE(xen_pte_val),
 	.pgd_val = PV_CALLEE_SAVE(xen_pgd_val),
 
-- 
1.7.7.3


--YiEDa0DAkWCtVeE4
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="0002-x86-paravirt-xen-Optimize-pte_flags-by-marking-it-as.patch"

>From 7e218b96dc908362afb501755f3f4b8ec530b700 Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Mon, 28 Nov 2011 17:58:38 -0500
Subject: x86/paravirt/xen: Optimize pte_flags by marking it as
 paravirt_ident_[32|64] type.

Which means that we have to use:
 __PV_IS_CALLEE_SAVE(_paravirt_ident_64)
which requires that the pte_flags on the 'pv_mmu_ops' structure
be defined as struct paravirt_callee_save. We end up using the
_paravirt_ident_64 function for both baremetal and for Xen guests
that have PAT disabled. For those that have pat_enabled, we end
up calling xen_pte_flags.

The big benefit of making the .pte_flags as struct paravirt_callee_save
and making it PTE_IDENT is that while the code looks as so when compiled:

  ff 14 25 e8 52 c1 81 	callq  *0xffffffff81c152e8

That however, on baremetal and under Xen when !pat_enable ends up
being patched over (by using the DEF_NATIVE macro) to be:

   48 89 f8             	mov    %rdi,%rax
   66 66 66 90          	data32 data32 xchg %ax,%ax

(the 32-bit version is of course different).
For details refer to 'paravirt_patch_ident_64' function.

The Xen version which requires pat_enable==1, ends up patched
to be:

	call xen_pte_flags;

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 arch/x86/include/asm/paravirt.h       |   11 ++++++++++-
 arch/x86/include/asm/paravirt_types.h |    2 +-
 arch/x86/kernel/paravirt.c            |    2 +-
 arch/x86/xen/mmu.c                    |   11 +++++++++--
 4 files changed, 21 insertions(+), 5 deletions(-)

diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h
index 6533409..b113feb 100644
--- a/arch/x86/include/asm/paravirt.h
+++ b/arch/x86/include/asm/paravirt.h
@@ -464,7 +464,16 @@ static inline void pmd_update_defer(struct mm_struct *mm, unsigned long addr,
 
 static inline pteval_t pte_flags(pte_t pte)
 {
-	return pv_mmu_ops.pte_flags(pte) & PTE_FLAGS_MASK;
+	pteval_t ret;
+
+	if (sizeof(pteval_t) > sizeof(long))
+		ret =  PVOP_CALLEE2(pteval_t, pv_mmu_ops.pte_flags,
+				    pte.pte, (u64)pte.pte >> 32);
+	else
+		ret =  PVOP_CALLEE1(pteval_t, pv_mmu_ops.pte_flags,
+				    pte.pte);
+
+	return ret & PTE_FLAGS_MASK;
 }
 
 static inline pte_t __pte(pteval_t val)
diff --git a/arch/x86/include/asm/paravirt_types.h b/arch/x86/include/asm/paravirt_types.h
index 86bce9d..5890cd7c 100644
--- a/arch/x86/include/asm/paravirt_types.h
+++ b/arch/x86/include/asm/paravirt_types.h
@@ -288,7 +288,7 @@ struct pv_mmu_ops {
 	void (*ptep_modify_prot_commit)(struct mm_struct *mm, unsigned long addr,
 					pte_t *ptep, pte_t pte);
 
-	pteval_t (*pte_flags)(pte_t pte);
+	struct paravirt_callee_save pte_flags;
 	struct paravirt_callee_save pte_val;
 	struct paravirt_callee_save make_pte;
 
diff --git a/arch/x86/kernel/paravirt.c b/arch/x86/kernel/paravirt.c
index 4780367..ba22188 100644
--- a/arch/x86/kernel/paravirt.c
+++ b/arch/x86/kernel/paravirt.c
@@ -462,7 +462,7 @@ struct pv_mmu_ops pv_mmu_ops = {
 #endif
 #endif /* PAGETABLE_LEVELS >= 3 */
 
-	.pte_flags = native_pte_flags,
+	.pte_flags = PTE_IDENT,
 	.pte_val = PTE_IDENT,
 	.pgd_val = PTE_IDENT,
 
diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index 5b79048..24e275a 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -1965,6 +1965,13 @@ void __init xen_ident_map_ISA(void)
 	xen_flush_tlb();
 }
 
+#if defined(CONFIG_X86_32) && !defined(CONFIG_X86_PAE)
+/* 32-bit pagetable entries */
+#define PTE_IDENT	__PV_IS_CALLEE_SAVE(_paravirt_ident_32)
+#else
+/* 64-bit pagetable entries */
+#define PTE_IDENT	__PV_IS_CALLEE_SAVE(_paravirt_ident_64)
+#endif
 static void __init xen_post_allocator_init(void)
 {
 	pv_mmu_ops.set_pte = xen_set_pte;
@@ -1986,7 +1993,7 @@ static void __init xen_post_allocator_init(void)
 #endif
 
 	if (!pat_enabled)
-		pv_mmu_ops.pte_flags = native_pte_flags;
+		pv_mmu_ops.pte_flags = PTE_IDENT;
 #ifdef CONFIG_X86_64
 	SetPagePinned(virt_to_page(level3_user_vsyscall));
 #endif
@@ -2035,7 +2042,7 @@ static const struct pv_mmu_ops xen_mmu_ops __initconst = {
 	.ptep_modify_prot_start = __ptep_modify_prot_start,
 	.ptep_modify_prot_commit = __ptep_modify_prot_commit,
 
-	.pte_flags = xen_pte_flags,
+	.pte_flags = __PV_IS_CALLEE_SAVE(xen_pte_flags),
 	.pte_val = PV_CALLEE_SAVE(xen_pte_val),
 	.pgd_val = PV_CALLEE_SAVE(xen_pgd_val),
 
-- 
1.7.7.3


--YiEDa0DAkWCtVeE4
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--YiEDa0DAkWCtVeE4--


From xen-devel-bounces@lists.xensource.com Sat Dec 03 14:44:13 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 03 Dec 2011 14:44:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWqn2-0000iV-0C; Sat, 03 Dec 2011 14:42:08 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RWqn0-0000i8-JY
	for xen-devel@lists.xensource.com; Sat, 03 Dec 2011 14:42:06 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1322923282!6013410!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQyNzM2Mw==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3374 invoked from network); 3 Dec 2011 14:41:24 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-6.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Dec 2011 14:41:24 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pB3EfKqS013448
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sat, 3 Dec 2011 14:41:20 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pB3EfJxW029759
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Sat, 3 Dec 2011 14:41:19 GMT
Received: from abhmt116.oracle.com (abhmt116.oracle.com [141.146.116.68])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pB3EfDt9027293; Sat, 3 Dec 2011 08:41:13 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Sat, 03 Dec 2011 06:41:13 -0800
Received: from phenom.dumpdata.com (localhost.localdomain [127.0.0.1])
	by phenom.dumpdata.com (Postfix) with ESMTP id 6686841C2D;
	Wed, 30 Nov 2011 13:39:01 -0500 (EST)
Received: (from konrad@localhost)
	by phenom.dumpdata.com (8.14.5/8.14.5/Submit) id pAUId1LU016110;
	Wed, 30 Nov 2011 13:39:01 -0500
Date: Wed, 30 Nov 2011 13:39:00 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "Luck, Tony" <tony.luck@intel.com>
Message-ID: <20111130183900.GA15847@phenom.dumpdata.com>
References: <4ed6746d25537aefd2@agluck-desktop.sc.intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4ed6746d25537aefd2@agluck-desktop.sc.intel.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090205.4EDA3510.0089,ss=1,re=0.000,fgs=0
Cc: Annie Li <annie.li@oracle.com>, xen-devel@lists.xensource.com,
	Ian Campbell <ian.campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH] ia64: fix build breakage because of
 conflicting u64 guest handles
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gV2VkLCBOb3YgMzAsIDIwMTEgYXQgMTA6MjI6MzdBTSAtMDgwMCwgTHVjaywgVG9ueSB3cm90
ZToKPiBpbmNsdWRlL3hlbi9pbnRlcmZhY2UveGVuLmg6NTI2OiBlcnJvcjogY29uZmxpY3Rpbmcg
dHlwZXMgZm9yIOKAmF9fZ3Vlc3RfaGFuZGxlX3U2NOKAmQo+IGFyY2gvaWE2NC9pbmNsdWRlL2Fz
bS94ZW4vaW50ZXJmYWNlLmg6NzQ6IGVycm9yOiBwcmV2aW91cyBkZWNsYXJhdGlvbiBvZiDigJhf
X2d1ZXN0X2hhbmRsZV91NjTigJkgd2FzIGhlcmUKPiAKPiBQcm9ibGVtIGludHJvZHVjZWQgYnkg
Inhlbi9ncmFudHRhYmxlOiBJbnRyb2R1Y2luZyBncmFudCB0YWJsZSBWMiBzdHVjdHVyZSIKPiAK
PiB3aGljaCBhZGRlZCBhIG5ldyBkZWZpbml0aW9uIHRvIGluY2x1ZGUveGVuL2ludGVyZmFjZS94
ZW4uaCBmb3IgInU2NCIuCj4gCj4gRml4OiBkZWxldGUgdGhlIGlhNjQgYXJjaCBzcGVjaWZpYyBk
ZWZpbml0aW9uLgo+IAo+IFNpZ25lZC1vZmYtYnk6IFRvbnkgTHVjayA8dG9ueS5sdWNrQGludGVs
LmNvbT4KPiAtLS0KPiAKPiBDYW4gc29tZW9uZSBlaXRoZXIgZm9sZCB0aGlzIGludG8gdGhlIGFi
b3ZlIHBhdGNoLCBvciBhZGQgaXQgdG8gdGhlCj4gc2FtZSB0cmVlIHRoYXQgaXMgZmVlZGluZyBp
bnRvIGxpbnV4LW5leHQgLSBJIHNhdyB0aGUgYnJlYWthZ2UgaW4KPiB0b2RheSdzICJuZXh0LTIw
MTExMTMwIiB0YWcuICBUaGFua3MuCgpBaCwgSSBjYW4gZm9sZCBpdCBpbi4gVGhhbmtzIQoKPiAK
PiAgYXJjaC9pYTY0L2luY2x1ZGUvYXNtL3hlbi9pbnRlcmZhY2UuaCB8ICAgIDIgKy0KPiAgMSBm
aWxlcyBjaGFuZ2VkLCAxIGluc2VydGlvbnMoKyksIDEgZGVsZXRpb25zKC0pCj4gCj4gZGlmZiAt
LWdpdCBhL2FyY2gvaWE2NC9pbmNsdWRlL2FzbS94ZW4vaW50ZXJmYWNlLmggYi9hcmNoL2lhNjQv
aW5jbHVkZS9hc20veGVuL2ludGVyZmFjZS5oCj4gaW5kZXggMWQyNDI3ZC4uZmJiNTE5OCAxMDA2
NDQKPiAtLS0gYS9hcmNoL2lhNjQvaW5jbHVkZS9hc20veGVuL2ludGVyZmFjZS5oCj4gKysrIGIv
YXJjaC9pYTY0L2luY2x1ZGUvYXNtL3hlbi9pbnRlcmZhY2UuaAo+IEBAIC03MSw3ICs3MSw3IEBA
Cj4gIF9fREVGSU5FX0dVRVNUX0hBTkRMRSh1Y2hhciwgdW5zaWduZWQgY2hhcik7Cj4gIF9fREVG
SU5FX0dVRVNUX0hBTkRMRSh1aW50LCB1bnNpZ25lZCBpbnQpOwo+ICBfX0RFRklORV9HVUVTVF9I
QU5ETEUodWxvbmcsIHVuc2lnbmVkIGxvbmcpOwo+IC1fX0RFRklORV9HVUVTVF9IQU5ETEUodTY0
LCB1bnNpZ25lZCBsb25nKTsKPiArCj4gIERFRklORV9HVUVTVF9IQU5ETEUoY2hhcik7Cj4gIERF
RklORV9HVUVTVF9IQU5ETEUoaW50KTsKPiAgREVGSU5FX0dVRVNUX0hBTkRMRShsb25nKTsKPiAt
LSAKPiAxLjcuMy4xCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29t
Cmh0dHA6Ly9saXN0cy54ZW5zb3VyY2UuY29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Sat Dec 03 14:44:13 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 03 Dec 2011 14:44:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWqn2-0000iV-0C; Sat, 03 Dec 2011 14:42:08 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RWqn0-0000i8-JY
	for xen-devel@lists.xensource.com; Sat, 03 Dec 2011 14:42:06 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1322923282!6013410!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQyNzM2Mw==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3374 invoked from network); 3 Dec 2011 14:41:24 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-6.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Dec 2011 14:41:24 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pB3EfKqS013448
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sat, 3 Dec 2011 14:41:20 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pB3EfJxW029759
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Sat, 3 Dec 2011 14:41:19 GMT
Received: from abhmt116.oracle.com (abhmt116.oracle.com [141.146.116.68])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pB3EfDt9027293; Sat, 3 Dec 2011 08:41:13 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Sat, 03 Dec 2011 06:41:13 -0800
Received: from phenom.dumpdata.com (localhost.localdomain [127.0.0.1])
	by phenom.dumpdata.com (Postfix) with ESMTP id 6686841C2D;
	Wed, 30 Nov 2011 13:39:01 -0500 (EST)
Received: (from konrad@localhost)
	by phenom.dumpdata.com (8.14.5/8.14.5/Submit) id pAUId1LU016110;
	Wed, 30 Nov 2011 13:39:01 -0500
Date: Wed, 30 Nov 2011 13:39:00 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "Luck, Tony" <tony.luck@intel.com>
Message-ID: <20111130183900.GA15847@phenom.dumpdata.com>
References: <4ed6746d25537aefd2@agluck-desktop.sc.intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4ed6746d25537aefd2@agluck-desktop.sc.intel.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090205.4EDA3510.0089,ss=1,re=0.000,fgs=0
Cc: Annie Li <annie.li@oracle.com>, xen-devel@lists.xensource.com,
	Ian Campbell <ian.campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH] ia64: fix build breakage because of
 conflicting u64 guest handles
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gV2VkLCBOb3YgMzAsIDIwMTEgYXQgMTA6MjI6MzdBTSAtMDgwMCwgTHVjaywgVG9ueSB3cm90
ZToKPiBpbmNsdWRlL3hlbi9pbnRlcmZhY2UveGVuLmg6NTI2OiBlcnJvcjogY29uZmxpY3Rpbmcg
dHlwZXMgZm9yIOKAmF9fZ3Vlc3RfaGFuZGxlX3U2NOKAmQo+IGFyY2gvaWE2NC9pbmNsdWRlL2Fz
bS94ZW4vaW50ZXJmYWNlLmg6NzQ6IGVycm9yOiBwcmV2aW91cyBkZWNsYXJhdGlvbiBvZiDigJhf
X2d1ZXN0X2hhbmRsZV91NjTigJkgd2FzIGhlcmUKPiAKPiBQcm9ibGVtIGludHJvZHVjZWQgYnkg
Inhlbi9ncmFudHRhYmxlOiBJbnRyb2R1Y2luZyBncmFudCB0YWJsZSBWMiBzdHVjdHVyZSIKPiAK
PiB3aGljaCBhZGRlZCBhIG5ldyBkZWZpbml0aW9uIHRvIGluY2x1ZGUveGVuL2ludGVyZmFjZS94
ZW4uaCBmb3IgInU2NCIuCj4gCj4gRml4OiBkZWxldGUgdGhlIGlhNjQgYXJjaCBzcGVjaWZpYyBk
ZWZpbml0aW9uLgo+IAo+IFNpZ25lZC1vZmYtYnk6IFRvbnkgTHVjayA8dG9ueS5sdWNrQGludGVs
LmNvbT4KPiAtLS0KPiAKPiBDYW4gc29tZW9uZSBlaXRoZXIgZm9sZCB0aGlzIGludG8gdGhlIGFi
b3ZlIHBhdGNoLCBvciBhZGQgaXQgdG8gdGhlCj4gc2FtZSB0cmVlIHRoYXQgaXMgZmVlZGluZyBp
bnRvIGxpbnV4LW5leHQgLSBJIHNhdyB0aGUgYnJlYWthZ2UgaW4KPiB0b2RheSdzICJuZXh0LTIw
MTExMTMwIiB0YWcuICBUaGFua3MuCgpBaCwgSSBjYW4gZm9sZCBpdCBpbi4gVGhhbmtzIQoKPiAK
PiAgYXJjaC9pYTY0L2luY2x1ZGUvYXNtL3hlbi9pbnRlcmZhY2UuaCB8ICAgIDIgKy0KPiAgMSBm
aWxlcyBjaGFuZ2VkLCAxIGluc2VydGlvbnMoKyksIDEgZGVsZXRpb25zKC0pCj4gCj4gZGlmZiAt
LWdpdCBhL2FyY2gvaWE2NC9pbmNsdWRlL2FzbS94ZW4vaW50ZXJmYWNlLmggYi9hcmNoL2lhNjQv
aW5jbHVkZS9hc20veGVuL2ludGVyZmFjZS5oCj4gaW5kZXggMWQyNDI3ZC4uZmJiNTE5OCAxMDA2
NDQKPiAtLS0gYS9hcmNoL2lhNjQvaW5jbHVkZS9hc20veGVuL2ludGVyZmFjZS5oCj4gKysrIGIv
YXJjaC9pYTY0L2luY2x1ZGUvYXNtL3hlbi9pbnRlcmZhY2UuaAo+IEBAIC03MSw3ICs3MSw3IEBA
Cj4gIF9fREVGSU5FX0dVRVNUX0hBTkRMRSh1Y2hhciwgdW5zaWduZWQgY2hhcik7Cj4gIF9fREVG
SU5FX0dVRVNUX0hBTkRMRSh1aW50LCB1bnNpZ25lZCBpbnQpOwo+ICBfX0RFRklORV9HVUVTVF9I
QU5ETEUodWxvbmcsIHVuc2lnbmVkIGxvbmcpOwo+IC1fX0RFRklORV9HVUVTVF9IQU5ETEUodTY0
LCB1bnNpZ25lZCBsb25nKTsKPiArCj4gIERFRklORV9HVUVTVF9IQU5ETEUoY2hhcik7Cj4gIERF
RklORV9HVUVTVF9IQU5ETEUoaW50KTsKPiAgREVGSU5FX0dVRVNUX0hBTkRMRShsb25nKTsKPiAt
LSAKPiAxLjcuMy4xCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29t
Cmh0dHA6Ly9saXN0cy54ZW5zb3VyY2UuY29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Sat Dec 03 16:57:01 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 03 Dec 2011 16:57:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWssk-0002Ab-2R; Sat, 03 Dec 2011 16:56:10 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RWssi-0002AW-Tg
	for xen-devel@lists.xensource.com; Sat, 03 Dec 2011 16:56:09 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1322931325!5740095!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjAxMw==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12013 invoked from network); 3 Dec 2011 16:55:25 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Dec 2011 16:55:25 -0000
X-IronPort-AV: E=Sophos;i="4.71,290,1320624000"; 
   d="scan'208";a="9267843"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Dec 2011 16:55:24 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sat, 3 Dec 2011 16:55:24 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RWss0-0003Jg-Bp;
	Sat, 03 Dec 2011 16:55:24 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RWss0-0004Iw-Aq;
	Sat, 03 Dec 2011 16:55:24 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10294-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 3 Dec 2011 16:55:24 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10294: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10294 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10294/

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-i386-xl-winxpsp3-vcpus1  4 xen-install         fail REGR. vs. 10201
 test-amd64-i386-xl-win7-amd64  4 xen-install              fail REGR. vs. 10201
 test-amd64-i386-xend-winxpsp3  4 xen-install              fail REGR. vs. 10201
 test-amd64-i386-pv            4 xen-install               fail REGR. vs. 10201
 test-amd64-i386-xl-multivcpu  4 xen-install               fail REGR. vs. 10201
 test-amd64-i386-xl            4 xen-install               fail REGR. vs. 10201
 test-amd64-i386-pair          6 xen-install/dst_host      fail REGR. vs. 10201
 test-amd64-i386-pair          5 xen-install/src_host      fail REGR. vs. 10201
 build-i386                    4 xen-build                 fail REGR. vs. 10201
 build-i386-oldkern            4 xen-build                 fail REGR. vs. 10201
 test-amd64-i386-rhel6hvm-intel  4 xen-install             fail REGR. vs. 10201
 test-amd64-i386-rhel6hvm-amd  4 xen-install               fail REGR. vs. 10201
 test-amd64-i386-xl-credit2    4 xen-install               fail REGR. vs. 10201
 test-amd64-amd64-win          8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-amd64-xl-win       8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-i386-win-vcpus1    4 xen-install               fail REGR. vs. 10201
 test-amd64-i386-win           4 xen-install               fail REGR. vs. 10201
 test-amd64-i386-xl-win-vcpus1  4 xen-install              fail REGR. vs. 10201

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-win7-amd64  7 windows-install              fail never pass
 test-i386-i386-xl-winxpsp3    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-i386-i386-pv             1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl             1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pair           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   never pass
 test-i386-i386-win            1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-win         1 xen-build-check(1)           blocked  n/a

version targeted for testing:
 xen                  a4d7c27ec1f1
baseline version:
 xen                  62ff6a318c5d

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Anthony PERARD <anthony.perard@citrix.com>
  Brendan Cully <brendan@cs.ubc.ca>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@novell.com>
  Jan Beulich <jbeulich@suse.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Jonathan Davies <jonathan.davies@citrix.com>
  juergen.gross@ts.fujitsu.com
  Keir Fraser <keir@xen.org>
  Liu, Jinsong <jinsong.liu@intel.com>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
  Philipp Hahn <hahn@univention.de>
  Shriram Rajagopalan <rshriram@cs.ubc.ca>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang2 <wei.wang2@amd.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   fail    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           fail    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           fail    
 test-i386-i386-xl                                            blocked 
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-i386-i386-pair                                          blocked 
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           fail    
 test-i386-i386-pv                                            blocked 
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           blocked 
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        blocked 
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   blocked 


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 1262 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Dec 03 16:57:01 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 03 Dec 2011 16:57:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWssk-0002Ab-2R; Sat, 03 Dec 2011 16:56:10 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RWssi-0002AW-Tg
	for xen-devel@lists.xensource.com; Sat, 03 Dec 2011 16:56:09 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1322931325!5740095!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjAxMw==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12013 invoked from network); 3 Dec 2011 16:55:25 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Dec 2011 16:55:25 -0000
X-IronPort-AV: E=Sophos;i="4.71,290,1320624000"; 
   d="scan'208";a="9267843"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Dec 2011 16:55:24 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sat, 3 Dec 2011 16:55:24 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RWss0-0003Jg-Bp;
	Sat, 03 Dec 2011 16:55:24 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RWss0-0004Iw-Aq;
	Sat, 03 Dec 2011 16:55:24 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10294-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 3 Dec 2011 16:55:24 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10294: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10294 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10294/

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-i386-xl-winxpsp3-vcpus1  4 xen-install         fail REGR. vs. 10201
 test-amd64-i386-xl-win7-amd64  4 xen-install              fail REGR. vs. 10201
 test-amd64-i386-xend-winxpsp3  4 xen-install              fail REGR. vs. 10201
 test-amd64-i386-pv            4 xen-install               fail REGR. vs. 10201
 test-amd64-i386-xl-multivcpu  4 xen-install               fail REGR. vs. 10201
 test-amd64-i386-xl            4 xen-install               fail REGR. vs. 10201
 test-amd64-i386-pair          6 xen-install/dst_host      fail REGR. vs. 10201
 test-amd64-i386-pair          5 xen-install/src_host      fail REGR. vs. 10201
 build-i386                    4 xen-build                 fail REGR. vs. 10201
 build-i386-oldkern            4 xen-build                 fail REGR. vs. 10201
 test-amd64-i386-rhel6hvm-intel  4 xen-install             fail REGR. vs. 10201
 test-amd64-i386-rhel6hvm-amd  4 xen-install               fail REGR. vs. 10201
 test-amd64-i386-xl-credit2    4 xen-install               fail REGR. vs. 10201
 test-amd64-amd64-win          8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-amd64-xl-win       8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-i386-win-vcpus1    4 xen-install               fail REGR. vs. 10201
 test-amd64-i386-win           4 xen-install               fail REGR. vs. 10201
 test-amd64-i386-xl-win-vcpus1  4 xen-install              fail REGR. vs. 10201

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-win7-amd64  7 windows-install              fail never pass
 test-i386-i386-xl-winxpsp3    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-i386-i386-pv             1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl             1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pair           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   never pass
 test-i386-i386-win            1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-win         1 xen-build-check(1)           blocked  n/a

version targeted for testing:
 xen                  a4d7c27ec1f1
baseline version:
 xen                  62ff6a318c5d

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Anthony PERARD <anthony.perard@citrix.com>
  Brendan Cully <brendan@cs.ubc.ca>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@novell.com>
  Jan Beulich <jbeulich@suse.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Jonathan Davies <jonathan.davies@citrix.com>
  juergen.gross@ts.fujitsu.com
  Keir Fraser <keir@xen.org>
  Liu, Jinsong <jinsong.liu@intel.com>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
  Philipp Hahn <hahn@univention.de>
  Shriram Rajagopalan <rshriram@cs.ubc.ca>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang2 <wei.wang2@amd.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   fail    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           fail    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           fail    
 test-i386-i386-xl                                            blocked 
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-i386-i386-pair                                          blocked 
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           fail    
 test-i386-i386-pv                                            blocked 
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           blocked 
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        blocked 
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   blocked 


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 1262 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Dec 03 20:01:55 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 03 Dec 2011 20: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.xensource.com>)
	id 1RWvle-000352-SM; Sat, 03 Dec 2011 20:01:02 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RWvld-00034x-LJ
	for xen-devel@lists.xensource.com; Sat, 03 Dec 2011 20:01:01 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1322942418!4076419!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjAxMw==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4114 invoked from network); 3 Dec 2011 20:00:18 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Dec 2011 20:00:18 -0000
X-IronPort-AV: E=Sophos;i="4.71,290,1320624000"; 
   d="scan'208";a="9268507"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Dec 2011 20:00:17 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sat, 3 Dec 2011 20:00:17 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RWvku-0004LO-PV;
	Sat, 03 Dec 2011 20:00:16 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RWvku-0008WV-I7;
	Sat, 03 Dec 2011 20:00:16 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10298-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 3 Dec 2011 20:00:16 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10298: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10298 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10298/

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-i386-xl-winxpsp3-vcpus1  4 xen-install         fail REGR. vs. 10201
 test-amd64-i386-xl-win7-amd64  4 xen-install              fail REGR. vs. 10201
 test-amd64-i386-xend-winxpsp3  4 xen-install              fail REGR. vs. 10201
 test-amd64-i386-pv            4 xen-install               fail REGR. vs. 10201
 test-amd64-i386-xl-multivcpu  4 xen-install               fail REGR. vs. 10201
 test-amd64-i386-xl            4 xen-install               fail REGR. vs. 10201
 test-amd64-i386-pair          6 xen-install/dst_host      fail REGR. vs. 10201
 test-amd64-i386-pair          5 xen-install/src_host      fail REGR. vs. 10201
 build-i386                    4 xen-build                 fail REGR. vs. 10201
 build-i386-oldkern            4 xen-build                 fail REGR. vs. 10201
 test-amd64-i386-rhel6hvm-intel  4 xen-install             fail REGR. vs. 10201
 test-amd64-i386-rhel6hvm-amd  4 xen-install               fail REGR. vs. 10201
 test-amd64-i386-xl-credit2    4 xen-install               fail REGR. vs. 10201
 test-amd64-amd64-win          8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-i386-win-vcpus1    4 xen-install               fail REGR. vs. 10201
 test-amd64-amd64-xl-win       8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-i386-win           4 xen-install               fail REGR. vs. 10201
 test-amd64-i386-xl-win-vcpus1  4 xen-install              fail REGR. vs. 10201

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-win7-amd64  7 windows-install              fail never pass
 test-i386-i386-xl-winxpsp3    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-i386-i386-pv             1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl             1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pair           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   never pass
 test-i386-i386-win            1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-win         1 xen-build-check(1)           blocked  n/a

version targeted for testing:
 xen                  a4d7c27ec1f1
baseline version:
 xen                  62ff6a318c5d

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Anthony PERARD <anthony.perard@citrix.com>
  Brendan Cully <brendan@cs.ubc.ca>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@novell.com>
  Jan Beulich <jbeulich@suse.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Jonathan Davies <jonathan.davies@citrix.com>
  juergen.gross@ts.fujitsu.com
  Keir Fraser <keir@xen.org>
  Liu, Jinsong <jinsong.liu@intel.com>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
  Philipp Hahn <hahn@univention.de>
  Shriram Rajagopalan <rshriram@cs.ubc.ca>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang2 <wei.wang2@amd.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   fail    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           fail    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           fail    
 test-i386-i386-xl                                            blocked 
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-i386-i386-pair                                          blocked 
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           fail    
 test-i386-i386-pv                                            blocked 
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           blocked 
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        blocked 
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   blocked 


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 1262 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Dec 03 20:01:55 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 03 Dec 2011 20: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.xensource.com>)
	id 1RWvle-000352-SM; Sat, 03 Dec 2011 20:01:02 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RWvld-00034x-LJ
	for xen-devel@lists.xensource.com; Sat, 03 Dec 2011 20:01:01 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1322942418!4076419!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjAxMw==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4114 invoked from network); 3 Dec 2011 20:00:18 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Dec 2011 20:00:18 -0000
X-IronPort-AV: E=Sophos;i="4.71,290,1320624000"; 
   d="scan'208";a="9268507"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Dec 2011 20:00:17 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sat, 3 Dec 2011 20:00:17 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RWvku-0004LO-PV;
	Sat, 03 Dec 2011 20:00:16 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RWvku-0008WV-I7;
	Sat, 03 Dec 2011 20:00:16 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10298-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 3 Dec 2011 20:00:16 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10298: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10298 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10298/

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-i386-xl-winxpsp3-vcpus1  4 xen-install         fail REGR. vs. 10201
 test-amd64-i386-xl-win7-amd64  4 xen-install              fail REGR. vs. 10201
 test-amd64-i386-xend-winxpsp3  4 xen-install              fail REGR. vs. 10201
 test-amd64-i386-pv            4 xen-install               fail REGR. vs. 10201
 test-amd64-i386-xl-multivcpu  4 xen-install               fail REGR. vs. 10201
 test-amd64-i386-xl            4 xen-install               fail REGR. vs. 10201
 test-amd64-i386-pair          6 xen-install/dst_host      fail REGR. vs. 10201
 test-amd64-i386-pair          5 xen-install/src_host      fail REGR. vs. 10201
 build-i386                    4 xen-build                 fail REGR. vs. 10201
 build-i386-oldkern            4 xen-build                 fail REGR. vs. 10201
 test-amd64-i386-rhel6hvm-intel  4 xen-install             fail REGR. vs. 10201
 test-amd64-i386-rhel6hvm-amd  4 xen-install               fail REGR. vs. 10201
 test-amd64-i386-xl-credit2    4 xen-install               fail REGR. vs. 10201
 test-amd64-amd64-win          8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-i386-win-vcpus1    4 xen-install               fail REGR. vs. 10201
 test-amd64-amd64-xl-win       8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-i386-win           4 xen-install               fail REGR. vs. 10201
 test-amd64-i386-xl-win-vcpus1  4 xen-install              fail REGR. vs. 10201

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-win7-amd64  7 windows-install              fail never pass
 test-i386-i386-xl-winxpsp3    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-i386-i386-pv             1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl             1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pair           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   never pass
 test-i386-i386-win            1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-win         1 xen-build-check(1)           blocked  n/a

version targeted for testing:
 xen                  a4d7c27ec1f1
baseline version:
 xen                  62ff6a318c5d

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Anthony PERARD <anthony.perard@citrix.com>
  Brendan Cully <brendan@cs.ubc.ca>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@novell.com>
  Jan Beulich <jbeulich@suse.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Jonathan Davies <jonathan.davies@citrix.com>
  juergen.gross@ts.fujitsu.com
  Keir Fraser <keir@xen.org>
  Liu, Jinsong <jinsong.liu@intel.com>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
  Philipp Hahn <hahn@univention.de>
  Shriram Rajagopalan <rshriram@cs.ubc.ca>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang2 <wei.wang2@amd.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   fail    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           fail    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           fail    
 test-i386-i386-xl                                            blocked 
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-i386-i386-pair                                          blocked 
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           fail    
 test-i386-i386-pv                                            blocked 
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           blocked 
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        blocked 
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   blocked 


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 1262 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Dec 03 20:46:22 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 03 Dec 2011 20:46:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWwSi-0003L2-F4; Sat, 03 Dec 2011 20:45:32 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <hahn@univention.de>) id 1RWwSh-0003Ku-0Z
	for xen-devel@lists.xensource.com; Sat, 03 Dec 2011 20:45:31 +0000
X-Env-Sender: hahn@univention.de
X-Msg-Ref: server-10.tower-216.messagelabs.com!1322945087!5958273!1
X-Originating-IP: [82.198.197.8]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13924 invoked from network); 3 Dec 2011 20:44:47 -0000
Received: from mail.univention.de (HELO mail.univention.de) (82.198.197.8)
	by server-10.tower-216.messagelabs.com with SMTP;
	3 Dec 2011 20:44:47 -0000
Received: from localhost (localhost [127.0.0.1])
	by slugis.knut.univention.de (Postfix) with ESMTP id 31A4F6EA18E;
	Sat,  3 Dec 2011 21:44:35 +0100 (CET)
Received: from localhost (localhost [127.0.0.1])
	by slugis.knut.univention.de (Postfix) with ESMTP id B74AB164B103;
	Sat,  3 Dec 2011 21:44:22 +0100 (CET)
X-Virus-Scanned: by amavisd-new-2.6.1 (20080629) (Debian) at knut.univention.de
Received: from mail.univention.de ([127.0.0.1])
	by localhost (slugis.knut.univention.de [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id un-1yzZaD3W9; Sat,  3 Dec 2011 21:44:20 +0100 (CET)
Received: from [10.205.1.98] (unknown [10.205.1.98])
	by slugis.knut.univention.de (Postfix) with ESMTPSA id CF8116EA18E;
	Sat,  3 Dec 2011 21:44:19 +0100 (CET)
From: Philipp Hahn <hahn@univention.de>
Organization: Univention.de
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Sat, 3 Dec 2011 21:42:51 +0100
User-Agent: KMail/1.9.10 (enterprise35 20100903.1171286)
References: <201111251721.12753.hahn@univention.de>
	<201111252057.31649.hahn@univention.de>
	<20183.51176.909813.103305@mariner.uk.xensource.com>
In-Reply-To: <20183.51176.909813.103305@mariner.uk.xensource.com>
X-KMail-QuotePrefix: > 
MIME-Version: 1.0
Message-Id: <201112032142.56295.hahn@univention.de>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCHv2] insufficient quoting between "tap-ctl
	list" and xend/server/BlktapController.py
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============8160156230039480396=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============8160156230039480396==
Content-Type: multipart/signed;
  boundary="nextPart6805590.KM9JBeCDoc";
  protocol="application/pgp-signature";
  micalg=pgp-sha1
Content-Transfer-Encoding: 7bit

--nextPart6805590.KM9JBeCDoc
Content-Type: multipart/mixed;
  boundary="Boundary-01=_Lno2Oln0JD/AQPI"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

--Boundary-01=_Lno2Oln0JD/AQPI
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Hello Ian,

On Thursday 01 December 2011 19:31:04 you wrote:
> Philipp Hahn writes ("Re: [Xen-devel] [BUG] insufficient quoting=20
between "tap-ctl list" and xend/server/BlktapController.py"):
> > As a quick work-around, the attached patch fixes the problem for me. Th=
at
> > is, until tap-ctl changes it's output format.
>
> Thanks, I have applied it.

Argh, I submitted the wrong patch. The "line.split(None, 4)" needs to be=20
a "3", because 3 splits needs to be done to get the 4 parts.

0004 is the correct full patch, 0005 is the inter-diff.

Sorry for the mixup.

Sincerely
Philipp
=2D-=20
Philipp Hahn           Open Source Software Engineer      hahn@univention.de
Univention GmbH        Linux for Your Business        fon: +49 421 22 232- 0
Mary-Somerville-Str.1  D-28359 Bremen                 fax: +49 421 22 232-99
                                                   http://www.univention.de/

--Boundary-01=_Lno2Oln0JD/AQPI
Content-Type: text/x-diff;
  charset="utf-8";
  name="0004-tap-ctl.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="0004-tap-ctl.patch"

Bug #18357: Fix tap-ctl parsing.

Shutting down a domU with xen-4.1.2 doesn't terminate the corresponding blk=
tap2
process, since one (other) VM uses a image file, which contains spaces in i=
ts
file name.  /var/log/xen/xend-debug.log has the following information:

Unhandled exception in thread started by
Traceback (most recent call last):
=C2=A0 File "/usr/lib/python2.6/dist-packages/xen/xend/server/BlktapControl=
ler.py", line 199, in finishDeviceCleanup
=C2=A0 =C2=A0 TapdiskController.destroy(path)
=C2=A0 File "/usr/lib/python2.6/dist-packages/xen/xend/server/BlktapControl=
ler.py", line 289, in destroy
=C2=A0 =C2=A0 tapdisk =3D TapdiskController.fromDevice(device)
=C2=A0 File "/usr/lib/python2.6/dist-packages/xen/xend/server/BlktapControl=
ler.py", line 278, in fromDevice
=C2=A0 =C2=A0 TapdiskController.list())
=C2=A0 File "/usr/lib/python2.6/dist-packages/xen/xend/server/BlktapControl=
ler.py", line 256, in list
=C2=A0 =C2=A0 key, value =3D pair.split('=3D')
ValueError: need more than 1 value to unpack

BlktapController calls "tap-ctl list", which outputs one line for each proc=
ess.
Each line contains key=3Dvalue pairs without any quoting.

# tap-ctl list | grep 'args=3D.*:.* '
pid=3D10145 minor=3D18 state=3D0 args=3Daio:/var/lib/libvirt/images/Xen Win=
dows drivers (gplpv 308).iso

(passing the output of tap-ctl through a pipe is important, since it switch=
es
to a different list-format when STDOUT is a tty.)

BlktapController splits the output into lines using \n, then each line at e=
ach
space, and finally each of these 'words' at the '=3D', which fails for the
filename.


Limit the number of splits as a fast work-around.
=2D-- a/tools/python/xen/xend/server/BlktapController.py
+++ b/tools/python/xen/xend/server/BlktapController.py
@@ -249,11 +249,12 @@ class TapdiskController(object):
         _list =3D TapdiskController.exc('list')
         if not _list: return []
=20
=2D        for line in _list.split('\n'):
+        for line in _list.splitlines():
             tapdisk =3D TapdiskController.Tapdisk()
=20
=2D            for pair in line.split():
=2D                key, value =3D pair.split('=3D')
+            # Since 'tap-ctl list' does not escape blanks in the path, har=
d-code the current format using 4 pairs to prevent splitting the path
+            for pair in line.split(None, 3):
+                key, value =3D pair.split('=3D', 1)
                 if key =3D=3D 'pid':
                     tapdisk.pid =3D value
                 elif key =3D=3D 'minor':
@@ -264,7 +265,7 @@ class TapdiskController(object):
                 elif key =3D=3D 'state':
                     tapdisk.state =3D value
                 elif key =3D=3D 'args' and value.find(':') !=3D -1:
=2D                    tapdisk.dtype, tapdisk.image =3D value.split(':')
+                    tapdisk.dtype, tapdisk.image =3D value.split(':', 1)
=20
             tapdisks.append(tapdisk)
=20

--Boundary-01=_Lno2Oln0JD/AQPI
Content-Type: text/x-diff;
  charset="iso-8859-15";
  name="0005-tap-ctl.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="0005-tap-ctl.patch"

Bug #18357: Fix tap-ctl parsing.

The previous patch was still wrong: Pythons split() expects the number of
splits, not the number of results.

Do 3 splits to get pid, minor, state and args.
=2D-- a/tools/python/xen/xend/server/BlktapController.py
+++ b/tools/python/xen/xend/server/BlktapController.py
@@ -252,7 +252,7 @@ class TapdiskController(object):
             tapdisk =3D TapdiskController.Tapdisk()
=20
             # Since 'tap-ctl list' does not escape blanks in the path, har=
d-code the current format using 4 pairs to prevent splitting the path
=2D            for pair in line.split(None, 4):
+            for pair in line.split(None, 3):
                 key, value =3D pair.split('=3D', 1)
                 if key =3D=3D 'pid':
                     tapdisk.pid =3D value

--Boundary-01=_Lno2Oln0JD/AQPI--

--nextPart6805590.KM9JBeCDoc
Content-Type: application/pgp-signature; name=signature.asc 
Content-Description: This is a digitally signed message part.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEABECAAYFAk7aicsACgkQYPlgoZpUDjlLzwCfUqzK00qj39sY2AgN0OQQtc0T
S1QAnj+kzIKZAY1UyifVBaF0JOiqWEK4
=EeRp
-----END PGP SIGNATURE-----

--nextPart6805590.KM9JBeCDoc--


--===============8160156230039480396==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============8160156230039480396==--


From xen-devel-bounces@lists.xensource.com Sat Dec 03 20:46:22 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 03 Dec 2011 20:46:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWwSi-0003L2-F4; Sat, 03 Dec 2011 20:45:32 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <hahn@univention.de>) id 1RWwSh-0003Ku-0Z
	for xen-devel@lists.xensource.com; Sat, 03 Dec 2011 20:45:31 +0000
X-Env-Sender: hahn@univention.de
X-Msg-Ref: server-10.tower-216.messagelabs.com!1322945087!5958273!1
X-Originating-IP: [82.198.197.8]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13924 invoked from network); 3 Dec 2011 20:44:47 -0000
Received: from mail.univention.de (HELO mail.univention.de) (82.198.197.8)
	by server-10.tower-216.messagelabs.com with SMTP;
	3 Dec 2011 20:44:47 -0000
Received: from localhost (localhost [127.0.0.1])
	by slugis.knut.univention.de (Postfix) with ESMTP id 31A4F6EA18E;
	Sat,  3 Dec 2011 21:44:35 +0100 (CET)
Received: from localhost (localhost [127.0.0.1])
	by slugis.knut.univention.de (Postfix) with ESMTP id B74AB164B103;
	Sat,  3 Dec 2011 21:44:22 +0100 (CET)
X-Virus-Scanned: by amavisd-new-2.6.1 (20080629) (Debian) at knut.univention.de
Received: from mail.univention.de ([127.0.0.1])
	by localhost (slugis.knut.univention.de [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id un-1yzZaD3W9; Sat,  3 Dec 2011 21:44:20 +0100 (CET)
Received: from [10.205.1.98] (unknown [10.205.1.98])
	by slugis.knut.univention.de (Postfix) with ESMTPSA id CF8116EA18E;
	Sat,  3 Dec 2011 21:44:19 +0100 (CET)
From: Philipp Hahn <hahn@univention.de>
Organization: Univention.de
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Sat, 3 Dec 2011 21:42:51 +0100
User-Agent: KMail/1.9.10 (enterprise35 20100903.1171286)
References: <201111251721.12753.hahn@univention.de>
	<201111252057.31649.hahn@univention.de>
	<20183.51176.909813.103305@mariner.uk.xensource.com>
In-Reply-To: <20183.51176.909813.103305@mariner.uk.xensource.com>
X-KMail-QuotePrefix: > 
MIME-Version: 1.0
Message-Id: <201112032142.56295.hahn@univention.de>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCHv2] insufficient quoting between "tap-ctl
	list" and xend/server/BlktapController.py
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============8160156230039480396=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============8160156230039480396==
Content-Type: multipart/signed;
  boundary="nextPart6805590.KM9JBeCDoc";
  protocol="application/pgp-signature";
  micalg=pgp-sha1
Content-Transfer-Encoding: 7bit

--nextPart6805590.KM9JBeCDoc
Content-Type: multipart/mixed;
  boundary="Boundary-01=_Lno2Oln0JD/AQPI"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

--Boundary-01=_Lno2Oln0JD/AQPI
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Hello Ian,

On Thursday 01 December 2011 19:31:04 you wrote:
> Philipp Hahn writes ("Re: [Xen-devel] [BUG] insufficient quoting=20
between "tap-ctl list" and xend/server/BlktapController.py"):
> > As a quick work-around, the attached patch fixes the problem for me. Th=
at
> > is, until tap-ctl changes it's output format.
>
> Thanks, I have applied it.

Argh, I submitted the wrong patch. The "line.split(None, 4)" needs to be=20
a "3", because 3 splits needs to be done to get the 4 parts.

0004 is the correct full patch, 0005 is the inter-diff.

Sorry for the mixup.

Sincerely
Philipp
=2D-=20
Philipp Hahn           Open Source Software Engineer      hahn@univention.de
Univention GmbH        Linux for Your Business        fon: +49 421 22 232- 0
Mary-Somerville-Str.1  D-28359 Bremen                 fax: +49 421 22 232-99
                                                   http://www.univention.de/

--Boundary-01=_Lno2Oln0JD/AQPI
Content-Type: text/x-diff;
  charset="utf-8";
  name="0004-tap-ctl.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="0004-tap-ctl.patch"

Bug #18357: Fix tap-ctl parsing.

Shutting down a domU with xen-4.1.2 doesn't terminate the corresponding blk=
tap2
process, since one (other) VM uses a image file, which contains spaces in i=
ts
file name.  /var/log/xen/xend-debug.log has the following information:

Unhandled exception in thread started by
Traceback (most recent call last):
=C2=A0 File "/usr/lib/python2.6/dist-packages/xen/xend/server/BlktapControl=
ler.py", line 199, in finishDeviceCleanup
=C2=A0 =C2=A0 TapdiskController.destroy(path)
=C2=A0 File "/usr/lib/python2.6/dist-packages/xen/xend/server/BlktapControl=
ler.py", line 289, in destroy
=C2=A0 =C2=A0 tapdisk =3D TapdiskController.fromDevice(device)
=C2=A0 File "/usr/lib/python2.6/dist-packages/xen/xend/server/BlktapControl=
ler.py", line 278, in fromDevice
=C2=A0 =C2=A0 TapdiskController.list())
=C2=A0 File "/usr/lib/python2.6/dist-packages/xen/xend/server/BlktapControl=
ler.py", line 256, in list
=C2=A0 =C2=A0 key, value =3D pair.split('=3D')
ValueError: need more than 1 value to unpack

BlktapController calls "tap-ctl list", which outputs one line for each proc=
ess.
Each line contains key=3Dvalue pairs without any quoting.

# tap-ctl list | grep 'args=3D.*:.* '
pid=3D10145 minor=3D18 state=3D0 args=3Daio:/var/lib/libvirt/images/Xen Win=
dows drivers (gplpv 308).iso

(passing the output of tap-ctl through a pipe is important, since it switch=
es
to a different list-format when STDOUT is a tty.)

BlktapController splits the output into lines using \n, then each line at e=
ach
space, and finally each of these 'words' at the '=3D', which fails for the
filename.


Limit the number of splits as a fast work-around.
=2D-- a/tools/python/xen/xend/server/BlktapController.py
+++ b/tools/python/xen/xend/server/BlktapController.py
@@ -249,11 +249,12 @@ class TapdiskController(object):
         _list =3D TapdiskController.exc('list')
         if not _list: return []
=20
=2D        for line in _list.split('\n'):
+        for line in _list.splitlines():
             tapdisk =3D TapdiskController.Tapdisk()
=20
=2D            for pair in line.split():
=2D                key, value =3D pair.split('=3D')
+            # Since 'tap-ctl list' does not escape blanks in the path, har=
d-code the current format using 4 pairs to prevent splitting the path
+            for pair in line.split(None, 3):
+                key, value =3D pair.split('=3D', 1)
                 if key =3D=3D 'pid':
                     tapdisk.pid =3D value
                 elif key =3D=3D 'minor':
@@ -264,7 +265,7 @@ class TapdiskController(object):
                 elif key =3D=3D 'state':
                     tapdisk.state =3D value
                 elif key =3D=3D 'args' and value.find(':') !=3D -1:
=2D                    tapdisk.dtype, tapdisk.image =3D value.split(':')
+                    tapdisk.dtype, tapdisk.image =3D value.split(':', 1)
=20
             tapdisks.append(tapdisk)
=20

--Boundary-01=_Lno2Oln0JD/AQPI
Content-Type: text/x-diff;
  charset="iso-8859-15";
  name="0005-tap-ctl.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="0005-tap-ctl.patch"

Bug #18357: Fix tap-ctl parsing.

The previous patch was still wrong: Pythons split() expects the number of
splits, not the number of results.

Do 3 splits to get pid, minor, state and args.
=2D-- a/tools/python/xen/xend/server/BlktapController.py
+++ b/tools/python/xen/xend/server/BlktapController.py
@@ -252,7 +252,7 @@ class TapdiskController(object):
             tapdisk =3D TapdiskController.Tapdisk()
=20
             # Since 'tap-ctl list' does not escape blanks in the path, har=
d-code the current format using 4 pairs to prevent splitting the path
=2D            for pair in line.split(None, 4):
+            for pair in line.split(None, 3):
                 key, value =3D pair.split('=3D', 1)
                 if key =3D=3D 'pid':
                     tapdisk.pid =3D value

--Boundary-01=_Lno2Oln0JD/AQPI--

--nextPart6805590.KM9JBeCDoc
Content-Type: application/pgp-signature; name=signature.asc 
Content-Description: This is a digitally signed message part.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEABECAAYFAk7aicsACgkQYPlgoZpUDjlLzwCfUqzK00qj39sY2AgN0OQQtc0T
S1QAnj+kzIKZAY1UyifVBaF0JOiqWEK4
=EeRp
-----END PGP SIGNATURE-----

--nextPart6805590.KM9JBeCDoc--


--===============8160156230039480396==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============8160156230039480396==--


From xen-devel-bounces@lists.xensource.com Sat Dec 03 22:46:16 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 03 Dec 2011 22:46:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWyKq-0003yP-0S; Sat, 03 Dec 2011 22:45:32 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RWyKp-0003yH-4s
	for xen-devel@lists.xensource.com; Sat, 03 Dec 2011 22:45:31 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1322952288!1101209!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjAxNA==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18527 invoked from network); 3 Dec 2011 22:44:48 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Dec 2011 22:44:48 -0000
X-IronPort-AV: E=Sophos;i="4.71,291,1320624000"; 
   d="scan'208";a="9268946"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Dec 2011 22:44:47 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sat, 3 Dec 2011 22:44:47 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RWyK7-0005FR-9j;
	Sat, 03 Dec 2011 22:44:47 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RWyK7-00018c-9L;
	Sat, 03 Dec 2011 22:44:47 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10300-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 3 Dec 2011 22:44:47 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10300: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10300 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10300/

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-i386-xl-winxpsp3-vcpus1  4 xen-install         fail REGR. vs. 10201
 test-amd64-i386-xl-win7-amd64  4 xen-install              fail REGR. vs. 10201
 test-amd64-i386-xend-winxpsp3  4 xen-install              fail REGR. vs. 10201
 test-amd64-i386-pv            4 xen-install               fail REGR. vs. 10201
 test-amd64-i386-xl-multivcpu  4 xen-install               fail REGR. vs. 10201
 test-amd64-i386-xl            4 xen-install               fail REGR. vs. 10201
 test-amd64-i386-pair          6 xen-install/dst_host      fail REGR. vs. 10201
 test-amd64-i386-pair          5 xen-install/src_host      fail REGR. vs. 10201
 build-i386                    4 xen-build                 fail REGR. vs. 10201
 build-i386-oldkern            4 xen-build                 fail REGR. vs. 10201
 test-amd64-i386-rhel6hvm-intel  4 xen-install             fail REGR. vs. 10201
 test-amd64-i386-rhel6hvm-amd  4 xen-install               fail REGR. vs. 10201
 test-amd64-i386-xl-credit2    4 xen-install               fail REGR. vs. 10201
 test-amd64-amd64-win          8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-i386-win-vcpus1    4 xen-install               fail REGR. vs. 10201
 test-amd64-amd64-xl-win       8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-i386-win           4 xen-install               fail REGR. vs. 10201
 test-amd64-i386-xl-win-vcpus1  4 xen-install              fail REGR. vs. 10201

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-win7-amd64  7 windows-install              fail never pass
 test-i386-i386-xl-winxpsp3    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-i386-i386-pv             1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl             1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pair           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   never pass
 test-i386-i386-win            1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-win         1 xen-build-check(1)           blocked  n/a

version targeted for testing:
 xen                  a4d7c27ec1f1
baseline version:
 xen                  62ff6a318c5d

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Anthony PERARD <anthony.perard@citrix.com>
  Brendan Cully <brendan@cs.ubc.ca>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@novell.com>
  Jan Beulich <jbeulich@suse.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Jonathan Davies <jonathan.davies@citrix.com>
  juergen.gross@ts.fujitsu.com
  Keir Fraser <keir@xen.org>
  Liu, Jinsong <jinsong.liu@intel.com>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
  Philipp Hahn <hahn@univention.de>
  Shriram Rajagopalan <rshriram@cs.ubc.ca>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang2 <wei.wang2@amd.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   fail    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           fail    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           fail    
 test-i386-i386-xl                                            blocked 
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-i386-i386-pair                                          blocked 
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           fail    
 test-i386-i386-pv                                            blocked 
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           blocked 
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        blocked 
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   blocked 


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 1262 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Dec 03 22:46:16 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 03 Dec 2011 22:46:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RWyKq-0003yP-0S; Sat, 03 Dec 2011 22:45:32 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RWyKp-0003yH-4s
	for xen-devel@lists.xensource.com; Sat, 03 Dec 2011 22:45:31 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1322952288!1101209!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjAxNA==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18527 invoked from network); 3 Dec 2011 22:44:48 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Dec 2011 22:44:48 -0000
X-IronPort-AV: E=Sophos;i="4.71,291,1320624000"; 
   d="scan'208";a="9268946"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Dec 2011 22:44:47 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sat, 3 Dec 2011 22:44:47 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RWyK7-0005FR-9j;
	Sat, 03 Dec 2011 22:44:47 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RWyK7-00018c-9L;
	Sat, 03 Dec 2011 22:44:47 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10300-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 3 Dec 2011 22:44:47 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10300: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10300 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10300/

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-i386-xl-winxpsp3-vcpus1  4 xen-install         fail REGR. vs. 10201
 test-amd64-i386-xl-win7-amd64  4 xen-install              fail REGR. vs. 10201
 test-amd64-i386-xend-winxpsp3  4 xen-install              fail REGR. vs. 10201
 test-amd64-i386-pv            4 xen-install               fail REGR. vs. 10201
 test-amd64-i386-xl-multivcpu  4 xen-install               fail REGR. vs. 10201
 test-amd64-i386-xl            4 xen-install               fail REGR. vs. 10201
 test-amd64-i386-pair          6 xen-install/dst_host      fail REGR. vs. 10201
 test-amd64-i386-pair          5 xen-install/src_host      fail REGR. vs. 10201
 build-i386                    4 xen-build                 fail REGR. vs. 10201
 build-i386-oldkern            4 xen-build                 fail REGR. vs. 10201
 test-amd64-i386-rhel6hvm-intel  4 xen-install             fail REGR. vs. 10201
 test-amd64-i386-rhel6hvm-amd  4 xen-install               fail REGR. vs. 10201
 test-amd64-i386-xl-credit2    4 xen-install               fail REGR. vs. 10201
 test-amd64-amd64-win          8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-i386-win-vcpus1    4 xen-install               fail REGR. vs. 10201
 test-amd64-amd64-xl-win       8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-i386-win           4 xen-install               fail REGR. vs. 10201
 test-amd64-i386-xl-win-vcpus1  4 xen-install              fail REGR. vs. 10201

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-win7-amd64  7 windows-install              fail never pass
 test-i386-i386-xl-winxpsp3    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-i386-i386-pv             1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl             1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pair           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   never pass
 test-i386-i386-win            1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-win         1 xen-build-check(1)           blocked  n/a

version targeted for testing:
 xen                  a4d7c27ec1f1
baseline version:
 xen                  62ff6a318c5d

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Anthony PERARD <anthony.perard@citrix.com>
  Brendan Cully <brendan@cs.ubc.ca>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@novell.com>
  Jan Beulich <jbeulich@suse.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Jonathan Davies <jonathan.davies@citrix.com>
  juergen.gross@ts.fujitsu.com
  Keir Fraser <keir@xen.org>
  Liu, Jinsong <jinsong.liu@intel.com>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
  Philipp Hahn <hahn@univention.de>
  Shriram Rajagopalan <rshriram@cs.ubc.ca>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang2 <wei.wang2@amd.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   fail    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           fail    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           fail    
 test-i386-i386-xl                                            blocked 
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-i386-i386-pair                                          blocked 
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           fail    
 test-i386-i386-pv                                            blocked 
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           blocked 
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        blocked 
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   blocked 


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 1262 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Dec 04 04:20:28 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 04 Dec 2011 04:20:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RX3Y3-00019Z-Oe; Sun, 04 Dec 2011 04:19:31 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RX3Y2-00019R-6Q
	for xen-devel@lists.xensource.com; Sun, 04 Dec 2011 04:19:30 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1322972327!3962311!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjAxNA==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16087 invoked from network); 4 Dec 2011 04:18:47 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Dec 2011 04:18:47 -0000
X-IronPort-AV: E=Sophos;i="4.71,292,1320624000"; 
   d="scan'208";a="9269510"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Dec 2011 04:18:46 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sun, 4 Dec 2011 04:18:46 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RX3XJ-00078A-Rh;
	Sun, 04 Dec 2011 04:18:46 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RX3XJ-0008A6-R5;
	Sun, 04 Dec 2011 04:18:45 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10305-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 4 Dec 2011 04:18:45 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10305: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10305 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10305/

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-i386-xl-winxpsp3-vcpus1  4 xen-install         fail REGR. vs. 10201
 test-amd64-i386-xl-win7-amd64  4 xen-install              fail REGR. vs. 10201
 test-amd64-i386-xend-winxpsp3  4 xen-install              fail REGR. vs. 10201
 test-amd64-i386-pv            4 xen-install               fail REGR. vs. 10201
 test-amd64-i386-xl-multivcpu  4 xen-install               fail REGR. vs. 10201
 test-amd64-i386-xl            4 xen-install               fail REGR. vs. 10201
 test-amd64-i386-pair          6 xen-install/dst_host      fail REGR. vs. 10201
 test-amd64-i386-pair          5 xen-install/src_host      fail REGR. vs. 10201
 build-i386                    4 xen-build                 fail REGR. vs. 10201
 build-i386-oldkern            4 xen-build                 fail REGR. vs. 10201
 test-amd64-i386-rhel6hvm-intel  4 xen-install             fail REGR. vs. 10201
 test-amd64-i386-rhel6hvm-amd  4 xen-install               fail REGR. vs. 10201
 test-amd64-i386-xl-credit2    4 xen-install               fail REGR. vs. 10201
 test-amd64-amd64-win          8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-i386-win-vcpus1    4 xen-install               fail REGR. vs. 10201
 test-amd64-amd64-xl-win       8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-i386-win           4 xen-install               fail REGR. vs. 10201
 test-amd64-i386-xl-win-vcpus1  4 xen-install              fail REGR. vs. 10201

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-win7-amd64  7 windows-install              fail never pass
 test-i386-i386-xl-winxpsp3    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-i386-i386-pv             1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl             1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pair           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   never pass
 test-i386-i386-win            1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-win         1 xen-build-check(1)           blocked  n/a

version targeted for testing:
 xen                  a4d7c27ec1f1
baseline version:
 xen                  62ff6a318c5d

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Anthony PERARD <anthony.perard@citrix.com>
  Brendan Cully <brendan@cs.ubc.ca>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@novell.com>
  Jan Beulich <jbeulich@suse.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Jonathan Davies <jonathan.davies@citrix.com>
  juergen.gross@ts.fujitsu.com
  Keir Fraser <keir@xen.org>
  Liu, Jinsong <jinsong.liu@intel.com>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
  Philipp Hahn <hahn@univention.de>
  Shriram Rajagopalan <rshriram@cs.ubc.ca>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang2 <wei.wang2@amd.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   fail    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           fail    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           fail    
 test-i386-i386-xl                                            blocked 
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-i386-i386-pair                                          blocked 
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           fail    
 test-i386-i386-pv                                            blocked 
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           blocked 
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        blocked 
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   blocked 


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 1262 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Dec 04 04:20:28 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 04 Dec 2011 04:20:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RX3Y3-00019Z-Oe; Sun, 04 Dec 2011 04:19:31 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RX3Y2-00019R-6Q
	for xen-devel@lists.xensource.com; Sun, 04 Dec 2011 04:19:30 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1322972327!3962311!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjAxNA==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16087 invoked from network); 4 Dec 2011 04:18:47 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Dec 2011 04:18:47 -0000
X-IronPort-AV: E=Sophos;i="4.71,292,1320624000"; 
   d="scan'208";a="9269510"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Dec 2011 04:18:46 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sun, 4 Dec 2011 04:18:46 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RX3XJ-00078A-Rh;
	Sun, 04 Dec 2011 04:18:46 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RX3XJ-0008A6-R5;
	Sun, 04 Dec 2011 04:18:45 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10305-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 4 Dec 2011 04:18:45 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10305: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10305 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10305/

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-i386-xl-winxpsp3-vcpus1  4 xen-install         fail REGR. vs. 10201
 test-amd64-i386-xl-win7-amd64  4 xen-install              fail REGR. vs. 10201
 test-amd64-i386-xend-winxpsp3  4 xen-install              fail REGR. vs. 10201
 test-amd64-i386-pv            4 xen-install               fail REGR. vs. 10201
 test-amd64-i386-xl-multivcpu  4 xen-install               fail REGR. vs. 10201
 test-amd64-i386-xl            4 xen-install               fail REGR. vs. 10201
 test-amd64-i386-pair          6 xen-install/dst_host      fail REGR. vs. 10201
 test-amd64-i386-pair          5 xen-install/src_host      fail REGR. vs. 10201
 build-i386                    4 xen-build                 fail REGR. vs. 10201
 build-i386-oldkern            4 xen-build                 fail REGR. vs. 10201
 test-amd64-i386-rhel6hvm-intel  4 xen-install             fail REGR. vs. 10201
 test-amd64-i386-rhel6hvm-amd  4 xen-install               fail REGR. vs. 10201
 test-amd64-i386-xl-credit2    4 xen-install               fail REGR. vs. 10201
 test-amd64-amd64-win          8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-i386-win-vcpus1    4 xen-install               fail REGR. vs. 10201
 test-amd64-amd64-xl-win       8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-i386-win           4 xen-install               fail REGR. vs. 10201
 test-amd64-i386-xl-win-vcpus1  4 xen-install              fail REGR. vs. 10201

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-win7-amd64  7 windows-install              fail never pass
 test-i386-i386-xl-winxpsp3    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-i386-i386-pv             1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl             1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pair           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   never pass
 test-i386-i386-win            1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-win         1 xen-build-check(1)           blocked  n/a

version targeted for testing:
 xen                  a4d7c27ec1f1
baseline version:
 xen                  62ff6a318c5d

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Anthony PERARD <anthony.perard@citrix.com>
  Brendan Cully <brendan@cs.ubc.ca>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@novell.com>
  Jan Beulich <jbeulich@suse.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Jonathan Davies <jonathan.davies@citrix.com>
  juergen.gross@ts.fujitsu.com
  Keir Fraser <keir@xen.org>
  Liu, Jinsong <jinsong.liu@intel.com>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
  Philipp Hahn <hahn@univention.de>
  Shriram Rajagopalan <rshriram@cs.ubc.ca>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang2 <wei.wang2@amd.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   fail    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           fail    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           fail    
 test-i386-i386-xl                                            blocked 
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-i386-i386-pair                                          blocked 
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           fail    
 test-i386-i386-pv                                            blocked 
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           blocked 
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        blocked 
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   blocked 


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 1262 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Dec 04 04:40:14 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 04 Dec 2011 04:40:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RX3rL-0001Kq-Gc; Sun, 04 Dec 2011 04:39:27 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <xudong.hao@intel.com>) id 1RX3rK-0001Kl-QI
	for xen-devel@lists.xensource.com; Sun, 04 Dec 2011 04:39:27 +0000
X-Env-Sender: xudong.hao@intel.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1322973522!4123949!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDMwMzE4MA==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22809 invoked from network); 4 Dec 2011 04:38:43 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-2.tower-174.messagelabs.com with SMTP;
	4 Dec 2011 04:38:43 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga102.fm.intel.com with ESMTP; 03 Dec 2011 20:38:42 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,292,1320652800"; d="scan'208";a="98358726"
Received: from pgsmsx602.gar.corp.intel.com ([10.221.43.81])
	by fmsmga002.fm.intel.com with ESMTP; 03 Dec 2011 20:38:40 -0800
Received: from shsmsx601.ccr.corp.intel.com (10.239.4.112) by
	pgsmsx602.gar.corp.intel.com (10.221.43.81) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Sun, 4 Dec 2011 12:38:39 +0800
Received: from shsmsx502.ccr.corp.intel.com ([10.239.4.96]) by
	shsmsx601.ccr.corp.intel.com ([10.239.4.112]) with mapi; Sun, 4 Dec 2011
	12:38:37 +0800
From: "Hao, Xudong" <xudong.hao@intel.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Sun, 4 Dec 2011 12:38:36 +0800
Thread-Topic: [Xen-devel] [PATCH] tools/firmware: remove "_PS0/3" Method
Thread-Index: Acyw1Ujo/3Zw+AL0RgWhC90sXAXkjgBY7rOA
Message-ID: <BC00F5384FCFC9499AF06F92E8B78A9E2870CA733E@shsmsx502.ccr.corp.intel.com>
References: <BC00F5384FCFC9499AF06F92E8B78A9E2870BB473F@shsmsx502.ccr.corp.intel.com>
	<1322815671.31810.265.camel@zakaz.uk.xensource.com>
	<BC00F5384FCFC9499AF06F92E8B78A9E2870BB4787@shsmsx502.ccr.corp.intel.com>
	<1322818316.31810.298.camel@zakaz.uk.xensource.com>
In-Reply-To: <1322818316.31810.298.camel@zakaz.uk.xensource.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "Tian, Kevin" <kevin.tian@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Shan, 
	Haitao" <haitao.shan@intel.com>, "Kay, Allen M" <allen.m.kay@intel.com>,
	Keir Fraser <keir.xen@gmail.com>,
	Stefano Stabellini <stefano.stabellini@citrix.com>
Subject: Re: [Xen-devel] [PATCH] tools/firmware: remove "_PS0/3" Method
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> Have you tested any other OSes? How does Windows for example respond to
> this change in the ACPI tables?
> 

Yes, I did some test with this patch, till now, all result shows patch works well with PCI device assign and hotplug, as well as HVM S3.

Pass cases:
RHEL6.1, SLES11 SP1, Win2008 VF device assign and hotplug.
RHEL6.1, Winxp, Win7 e1000e NIC device assign and hotplug
RHEL6.1, RHEL5.1 Guest S3

> Are there any devices which do not implement PCI PM and therefore rely on
> this ACPI mechanism to function? My understanding was that
> 47e9037ac166 was required in part due to the lack of PCI PM support on some
> VF devices. I think it was a different Intel SR-IOV NIC than the one you are
> testing, an 82559 if [0] is to be believed.
> 
VF is such device which do not have PCI PM capability, these device will be set PCI_D0 directly in function pci_platform_power_transition().

static int pci_platform_power_transition(struct pci_dev *dev, pci_power_t state)
{
    int error;
    if (platform_pci_power_manageable(dev)) {
        error = platform_pci_set_power_state(dev, state);
        ...
    } else {
        error = -ENODEV;
        /* Fall back to PCI_D0 if native PM is not supported */
        if (!dev->pm_cap)
            dev->current_state = PCI_D0;

> Also there was a previous attempt to remove _PS0 in [1]. Allen Kay (CCd) tested
> and reported that removing these values causes Windows not to boot. It was
> suggested in that thread that both _PS0 and _PS3 need to be removed (which
> you do) but it was also suggested that doing so breaks Linux S3 support, have
> you tried this?
> 
Windows does not to boot only happen when remove _PS0, however Windows guest can boot up with removing _PS0 and _PS3.

According to the annotate of "_PS0/3", it's for debug purpose. I do not know whether it's required for other purpose, comments of others?

Thanks,
-Xudong

> Ian.
> 
> [0]
> http://old-list-archives.xen.org/archives/html/xen-devel/2011-03/msg00434.ht
> ml
> [1]
> http://old-list-archives.xen.org/archives/html/xen-devel/2011-02/threads.html
> 
> > >
> > > Ian.
> > >
> > > >
> > > > Signed-off-by: Xudong Hao <xudong.hao@intel.com>
> > > > Signed-off-by: Haitao Shan <haitao.shan@intel.com>
> > > >
> > > > diff -r df7cec2c6c03 tools/firmware/hvmloader/acpi/mk_dsdt.c
> > > > --- a/tools/firmware/hvmloader/acpi/mk_dsdt.c	Tue Nov 29 13:30:39
> > > 2011 -0500
> > > > +++ b/tools/firmware/hvmloader/acpi/mk_dsdt.c	Wed Nov 30
> 15:08:20
> > > 2011 +0800
> > > > @@ -323,8 +323,6 @@
> > > >       * the ACPI event:
> > > >       *  _EJ0: eject a device
> > > >       *  _STA: return a device's status, e.g. enabled or removed
> > > > -     * Other methods are optional:
> > > > -     *  _PS0/3: put them here for debug purpose
> > > >       *
> > > >       * Eject button would generate a general-purpose event, then the
> > > >       * control method for this event uses Notify() to inform OSPM
> > > > which
> > > @@ -344,13 +342,6 @@
> > > >              stmt("Name", "_ADR, 0x%08x", ((slot & ~7) << 13) |
> > > > (slot &
> > > 7));
> > > >              /* _SUN == dev */
> > > >              stmt("Name", "_SUN, 0x%08x", slot >> 3);
> > > > -            push_block("Method", "_PS0, 0");
> > > > -            stmt("Store", "0x%02x, \\_GPE.DPT1", slot);
> > > > -            stmt("Store", "0x80, \\_GPE.DPT2");
> > > > -            pop_block();
> > > > -            push_block("Method", "_PS3, 0");
> > > > -            stmt("Store", "0x%02x, \\_GPE.DPT1", slot);
> > > > -            stmt("Store", "0x83, \\_GPE.DPT2");
> > > >              pop_block();
> > > >              push_block("Method", "_EJ0, 1");
> > > >              stmt("Store", "0x%02x, \\_GPE.DPT1", slot)
> > > >
> > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > Xen-devel mailing list
> > > > Xen-devel@lists.xensource.com
> > > > http://lists.xensource.com/xen-devel
> > >
> >
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Dec 04 04:40:14 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 04 Dec 2011 04:40:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RX3rL-0001Kq-Gc; Sun, 04 Dec 2011 04:39:27 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <xudong.hao@intel.com>) id 1RX3rK-0001Kl-QI
	for xen-devel@lists.xensource.com; Sun, 04 Dec 2011 04:39:27 +0000
X-Env-Sender: xudong.hao@intel.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1322973522!4123949!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDMwMzE4MA==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22809 invoked from network); 4 Dec 2011 04:38:43 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-2.tower-174.messagelabs.com with SMTP;
	4 Dec 2011 04:38:43 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga102.fm.intel.com with ESMTP; 03 Dec 2011 20:38:42 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,292,1320652800"; d="scan'208";a="98358726"
Received: from pgsmsx602.gar.corp.intel.com ([10.221.43.81])
	by fmsmga002.fm.intel.com with ESMTP; 03 Dec 2011 20:38:40 -0800
Received: from shsmsx601.ccr.corp.intel.com (10.239.4.112) by
	pgsmsx602.gar.corp.intel.com (10.221.43.81) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Sun, 4 Dec 2011 12:38:39 +0800
Received: from shsmsx502.ccr.corp.intel.com ([10.239.4.96]) by
	shsmsx601.ccr.corp.intel.com ([10.239.4.112]) with mapi; Sun, 4 Dec 2011
	12:38:37 +0800
From: "Hao, Xudong" <xudong.hao@intel.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Sun, 4 Dec 2011 12:38:36 +0800
Thread-Topic: [Xen-devel] [PATCH] tools/firmware: remove "_PS0/3" Method
Thread-Index: Acyw1Ujo/3Zw+AL0RgWhC90sXAXkjgBY7rOA
Message-ID: <BC00F5384FCFC9499AF06F92E8B78A9E2870CA733E@shsmsx502.ccr.corp.intel.com>
References: <BC00F5384FCFC9499AF06F92E8B78A9E2870BB473F@shsmsx502.ccr.corp.intel.com>
	<1322815671.31810.265.camel@zakaz.uk.xensource.com>
	<BC00F5384FCFC9499AF06F92E8B78A9E2870BB4787@shsmsx502.ccr.corp.intel.com>
	<1322818316.31810.298.camel@zakaz.uk.xensource.com>
In-Reply-To: <1322818316.31810.298.camel@zakaz.uk.xensource.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "Tian, Kevin" <kevin.tian@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Shan, 
	Haitao" <haitao.shan@intel.com>, "Kay, Allen M" <allen.m.kay@intel.com>,
	Keir Fraser <keir.xen@gmail.com>,
	Stefano Stabellini <stefano.stabellini@citrix.com>
Subject: Re: [Xen-devel] [PATCH] tools/firmware: remove "_PS0/3" Method
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> Have you tested any other OSes? How does Windows for example respond to
> this change in the ACPI tables?
> 

Yes, I did some test with this patch, till now, all result shows patch works well with PCI device assign and hotplug, as well as HVM S3.

Pass cases:
RHEL6.1, SLES11 SP1, Win2008 VF device assign and hotplug.
RHEL6.1, Winxp, Win7 e1000e NIC device assign and hotplug
RHEL6.1, RHEL5.1 Guest S3

> Are there any devices which do not implement PCI PM and therefore rely on
> this ACPI mechanism to function? My understanding was that
> 47e9037ac166 was required in part due to the lack of PCI PM support on some
> VF devices. I think it was a different Intel SR-IOV NIC than the one you are
> testing, an 82559 if [0] is to be believed.
> 
VF is such device which do not have PCI PM capability, these device will be set PCI_D0 directly in function pci_platform_power_transition().

static int pci_platform_power_transition(struct pci_dev *dev, pci_power_t state)
{
    int error;
    if (platform_pci_power_manageable(dev)) {
        error = platform_pci_set_power_state(dev, state);
        ...
    } else {
        error = -ENODEV;
        /* Fall back to PCI_D0 if native PM is not supported */
        if (!dev->pm_cap)
            dev->current_state = PCI_D0;

> Also there was a previous attempt to remove _PS0 in [1]. Allen Kay (CCd) tested
> and reported that removing these values causes Windows not to boot. It was
> suggested in that thread that both _PS0 and _PS3 need to be removed (which
> you do) but it was also suggested that doing so breaks Linux S3 support, have
> you tried this?
> 
Windows does not to boot only happen when remove _PS0, however Windows guest can boot up with removing _PS0 and _PS3.

According to the annotate of "_PS0/3", it's for debug purpose. I do not know whether it's required for other purpose, comments of others?

Thanks,
-Xudong

> Ian.
> 
> [0]
> http://old-list-archives.xen.org/archives/html/xen-devel/2011-03/msg00434.ht
> ml
> [1]
> http://old-list-archives.xen.org/archives/html/xen-devel/2011-02/threads.html
> 
> > >
> > > Ian.
> > >
> > > >
> > > > Signed-off-by: Xudong Hao <xudong.hao@intel.com>
> > > > Signed-off-by: Haitao Shan <haitao.shan@intel.com>
> > > >
> > > > diff -r df7cec2c6c03 tools/firmware/hvmloader/acpi/mk_dsdt.c
> > > > --- a/tools/firmware/hvmloader/acpi/mk_dsdt.c	Tue Nov 29 13:30:39
> > > 2011 -0500
> > > > +++ b/tools/firmware/hvmloader/acpi/mk_dsdt.c	Wed Nov 30
> 15:08:20
> > > 2011 +0800
> > > > @@ -323,8 +323,6 @@
> > > >       * the ACPI event:
> > > >       *  _EJ0: eject a device
> > > >       *  _STA: return a device's status, e.g. enabled or removed
> > > > -     * Other methods are optional:
> > > > -     *  _PS0/3: put them here for debug purpose
> > > >       *
> > > >       * Eject button would generate a general-purpose event, then the
> > > >       * control method for this event uses Notify() to inform OSPM
> > > > which
> > > @@ -344,13 +342,6 @@
> > > >              stmt("Name", "_ADR, 0x%08x", ((slot & ~7) << 13) |
> > > > (slot &
> > > 7));
> > > >              /* _SUN == dev */
> > > >              stmt("Name", "_SUN, 0x%08x", slot >> 3);
> > > > -            push_block("Method", "_PS0, 0");
> > > > -            stmt("Store", "0x%02x, \\_GPE.DPT1", slot);
> > > > -            stmt("Store", "0x80, \\_GPE.DPT2");
> > > > -            pop_block();
> > > > -            push_block("Method", "_PS3, 0");
> > > > -            stmt("Store", "0x%02x, \\_GPE.DPT1", slot);
> > > > -            stmt("Store", "0x83, \\_GPE.DPT2");
> > > >              pop_block();
> > > >              push_block("Method", "_EJ0, 1");
> > > >              stmt("Store", "0x%02x, \\_GPE.DPT1", slot)
> > > >
> > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > Xen-devel mailing list
> > > > Xen-devel@lists.xensource.com
> > > > http://lists.xensource.com/xen-devel
> > >
> >
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Dec 04 04:46:30 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 04 Dec 2011 04:46:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RX3xU-0001TU-Bm; Sun, 04 Dec 2011 04:45:48 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <xudong.hao@intel.com>) id 1RX3xS-0001TM-Om
	for xen-devel@lists.xensource.com; Sun, 04 Dec 2011 04:45:47 +0000
X-Env-Sender: xudong.hao@intel.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1322973900!6847304!1
X-Originating-IP: [143.182.124.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjA5NTM4\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23105 invoked from network); 4 Dec 2011 04:45:01 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-3.tower-21.messagelabs.com with SMTP;
	4 Dec 2011 04:45:01 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga101.ch.intel.com with ESMTP; 03 Dec 2011 20:44:59 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,292,1320652800"; d="scan'208";a="81984179"
Received: from pgsmsx603.gar.corp.intel.com ([10.221.43.87])
	by azsmga001.ch.intel.com with ESMTP; 03 Dec 2011 20:44:58 -0800
Received: from pgsmsx103.gar.corp.intel.com (10.221.44.82) by
	pgsmsx603.gar.corp.intel.com (10.221.43.87) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Sun, 4 Dec 2011 12:44:57 +0800
Received: from shsmsx602.ccr.corp.intel.com (10.239.4.104) by
	PGSMSX103.gar.corp.intel.com (10.221.44.82) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Sun, 4 Dec 2011 12:44:57 +0800
Received: from shsmsx502.ccr.corp.intel.com ([10.239.4.96]) by
	SHSMSX602.ccr.corp.intel.com ([10.239.4.104]) with mapi; Sun, 4 Dec 2011
	12:44:55 +0800
From: "Hao, Xudong" <xudong.hao@intel.com>
To: "Hao, Xudong" <xudong.hao@intel.com>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>
Date: Sun, 4 Dec 2011 12:44:54 +0800
Thread-Topic: [PATCH] tools/firmware: remove "_PS0/3" Method
Thread-Index: AcywzXyuc/E+gfMtR6Og9gMqN63sawBcRy3A
Message-ID: <BC00F5384FCFC9499AF06F92E8B78A9E2870CA7340@shsmsx502.ccr.corp.intel.com>
References: <BC00F5384FCFC9499AF06F92E8B78A9E2870BB473F@shsmsx502.ccr.corp.intel.com>
In-Reply-To: <BC00F5384FCFC9499AF06F92E8B78A9E2870BB473F@shsmsx502.ccr.corp.intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/mixed;
	boundary="_002_BC00F5384FCFC9499AF06F92E8B78A9E2870CA7340shsmsx502ccrc_"
MIME-Version: 1.0
Cc: "Tian, Kevin" <kevin.tian@intel.com>, Keir Fraser <keir.xen@gmail.com>,
	"Shan, Haitao" <haitao.shan@intel.com>
Subject: Re: [Xen-devel] [PATCH] tools/firmware: remove "_PS0/3" Method
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--_002_BC00F5384FCFC9499AF06F92E8B78A9E2870CA7340shsmsx502ccrc_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

(Resend patch because the previous patch loss to remove one line code.)

tools/firmware: remove "_PS0/3" Method

Do not expose the ACPI power management "_PS0/3" Method to guest firmware. =
According to section 3.4 of the APCI specification 4.0, PCI device control =
the device power through its own specification but not through APCI.

Qemu pushes "_PS0/3" to guest will cause a mess between ACPI PM and PCI PM =
as a result of incorrect ACPI table shipped with the guest BIOS, it may cau=
se a failure of PCI device PM state transition(from PCI_UNKNOWN to PCI_D0).

Signed-off-by: Xudong Hao <xudong.hao@intel.com>
Signed-off-by: Haitao Shan <haitao.shan@intel.com>

diff -r df7cec2c6c03 tools/firmware/hvmloader/acpi/mk_dsdt.c
--- a/tools/firmware/hvmloader/acpi/mk_dsdt.c	Tue Nov 29 13:30:39 2011 -050=
0
+++ b/tools/firmware/hvmloader/acpi/mk_dsdt.c	Fri Dec 02 21:56:14 2011 +080=
0
@@ -323,8 +323,6 @@
      * the ACPI event:
      *  _EJ0: eject a device
      *  _STA: return a device's status, e.g. enabled or removed
-     * Other methods are optional:=20
-     *  _PS0/3: put them here for debug purpose
      *=20
      * Eject button would generate a general-purpose event, then the
      * control method for this event uses Notify() to inform OSPM which
@@ -344,14 +342,6 @@
             stmt("Name", "_ADR, 0x%08x", ((slot & ~7) << 13) | (slot & 7))=
;
             /* _SUN =3D=3D dev */
             stmt("Name", "_SUN, 0x%08x", slot >> 3);
-            push_block("Method", "_PS0, 0");
-            stmt("Store", "0x%02x, \\_GPE.DPT1", slot);
-            stmt("Store", "0x80, \\_GPE.DPT2");
-            pop_block();
-            push_block("Method", "_PS3, 0");
-            stmt("Store", "0x%02x, \\_GPE.DPT1", slot);
-            stmt("Store", "0x83, \\_GPE.DPT2");
-            pop_block();
             push_block("Method", "_EJ0, 1");
             stmt("Store", "0x%02x, \\_GPE.DPT1", slot);
             stmt("Store", "0x88, \\_GPE.DPT2");



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Thanks,
-Xudong


> -----Original Message-----
> From: xen-devel-bounces@lists.xensource.com
> [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Hao, Xudong
> Sent: Friday, December 02, 2011 4:39 PM
> To: xen-devel@lists.xensource.com
> Cc: Tian, Kevin; Keir Fraser; Shan, Haitao
> Subject: [Xen-devel] [PATCH] tools/firmware: remove "_PS0/3" Method
>=20
> tools/firmware: remove "_PS0/3" Method
>=20
> Do not expose the ACPI power management "_PS0/3" Method to guest
> firmware. According to section 3.4 of the APCI specification 4.0, PCI dev=
ice
> control the device power through its own specification but not through AP=
CI.
>=20
> Qemu pushes "_PS0/3" to guest will cause a mess between ACPI PM and PCI
> PM as a result of incorrect ACPI table shipped with the guest BIOS, it ma=
y
> cause a failure of PCI device PM state transition(from PCI_UNKNOWN to
> PCI_D0).
>=20
> Signed-off-by: Xudong Hao <xudong.hao@intel.com>
> Signed-off-by: Haitao Shan <haitao.shan@intel.com>
>=20
> diff -r df7cec2c6c03 tools/firmware/hvmloader/acpi/mk_dsdt.c
> --- a/tools/firmware/hvmloader/acpi/mk_dsdt.c	Tue Nov 29 13:30:39 2011
> -0500
> +++ b/tools/firmware/hvmloader/acpi/mk_dsdt.c	Wed Nov 30 15:08:20 2011
> +0800
> @@ -323,8 +323,6 @@
>       * the ACPI event:
>       *  _EJ0: eject a device
>       *  _STA: return a device's status, e.g. enabled or removed
> -     * Other methods are optional:
> -     *  _PS0/3: put them here for debug purpose
>       *
>       * Eject button would generate a general-purpose event, then the
>       * control method for this event uses Notify() to inform OSPM which =
@@
> -344,13 +342,6 @@
>              stmt("Name", "_ADR, 0x%08x", ((slot & ~7) << 13) | (slot & 7=
));
>              /* _SUN =3D=3D dev */
>              stmt("Name", "_SUN, 0x%08x", slot >> 3);
> -            push_block("Method", "_PS0, 0");
> -            stmt("Store", "0x%02x, \\_GPE.DPT1", slot);
> -            stmt("Store", "0x80, \\_GPE.DPT2");
> -            pop_block();
> -            push_block("Method", "_PS3, 0");
> -            stmt("Store", "0x%02x, \\_GPE.DPT1", slot);
> -            stmt("Store", "0x83, \\_GPE.DPT2");
>              pop_block();
>              push_block("Method", "_EJ0, 1");
>              stmt("Store", "0x%02x, \\_GPE.DPT1", slot)
>=20
>=20
>=20
>=20
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

--_002_BC00F5384FCFC9499AF06F92E8B78A9E2870CA7340shsmsx502ccrc_
Content-Type: application/octet-stream; name="remove_PS0_method.patch"
Content-Description: remove_PS0_method.patch
Content-Disposition: attachment; filename="remove_PS0_method.patch";
	size=1871; creation-date="Wed, 30 Nov 2011 16:24:20 GMT";
	modification-date="Sun, 04 Dec 2011 12:42:31 GMT"
Content-Transfer-Encoding: base64

dG9vbHMvZmlybXdhcmU6IHJlbW92ZSAiX1BTMC8zIiBNZXRob2QKCkRvIG5vdCBleHBvc2UgdGhl
IEFDUEkgcG93ZXIgbWFuYWdlbWVudCAiX1BTMC8zIiBNZXRob2QgdG8gZ3Vlc3QgZmlybXdhcmUu
IEFjY29yZGluZyB0byBzZWN0aW9uIDMuNCBvZiB0aGUgQVBDSSBzcGVjaWZpY2F0aW9uIDQuMCwg
UENJIGRldmljZSBjb250cm9sIHRoZSBkZXZpY2UgcG93ZXIgdGhyb3VnaCBpdHMgb3duIHNwZWNp
ZmljYXRpb24gYnV0IG5vdCB0aHJvdWdoIEFQQ0kuCgpRZW11IHB1c2hlcyAiX1BTMC8zIiB0byBn
dWVzdCB3aWxsIGNhdXNlIGEgbWVzcyBiZXR3ZWVuIEFDUEkgUE0gYW5kIFBDSSBQTSBhcyBhIHJl
c3VsdCBvZiBpbmNvcnJlY3QgQUNQSSB0YWJsZSBzaGlwcGVkIHdpdGggdGhlIGd1ZXN0IEJJT1Ms
IGl0IG1heSBjYXVzZSBhIGZhaWx1cmUgb2YgUENJIGRldmljZSBQTSBzdGF0ZSB0cmFuc2l0aW9u
KGZyb20gUENJX1VOS05PV04gdG8gUENJX0QwKS4KClNpZ25lZC1vZmYtYnk6IFh1ZG9uZyBIYW8g
PHh1ZG9uZy5oYW9AaW50ZWwuY29tPgpTaWduZWQtb2ZmLWJ5OiBIYWl0YW8gU2hhbiA8aGFpdGFv
LnNoYW5AaW50ZWwuY29tPgoKZGlmZiAtciBkZjdjZWMyYzZjMDMgdG9vbHMvZmlybXdhcmUvaHZt
bG9hZGVyL2FjcGkvbWtfZHNkdC5jCi0tLSBhL3Rvb2xzL2Zpcm13YXJlL2h2bWxvYWRlci9hY3Bp
L21rX2RzZHQuYwlUdWUgTm92IDI5IDEzOjMwOjM5IDIwMTEgLTA1MDAKKysrIGIvdG9vbHMvZmly
bXdhcmUvaHZtbG9hZGVyL2FjcGkvbWtfZHNkdC5jCUZyaSBEZWMgMDIgMjE6NTY6MTQgMjAxMSAr
MDgwMApAQCAtMzIzLDggKzMyMyw2IEBACiAgICAgICogdGhlIEFDUEkgZXZlbnQ6CiAgICAgICog
IF9FSjA6IGVqZWN0IGEgZGV2aWNlCiAgICAgICogIF9TVEE6IHJldHVybiBhIGRldmljZSdzIHN0
YXR1cywgZS5nLiBlbmFibGVkIG9yIHJlbW92ZWQKLSAgICAgKiBPdGhlciBtZXRob2RzIGFyZSBv
cHRpb25hbDogCi0gICAgICogIF9QUzAvMzogcHV0IHRoZW0gaGVyZSBmb3IgZGVidWcgcHVycG9z
ZQogICAgICAqIAogICAgICAqIEVqZWN0IGJ1dHRvbiB3b3VsZCBnZW5lcmF0ZSBhIGdlbmVyYWwt
cHVycG9zZSBldmVudCwgdGhlbiB0aGUKICAgICAgKiBjb250cm9sIG1ldGhvZCBmb3IgdGhpcyBl
dmVudCB1c2VzIE5vdGlmeSgpIHRvIGluZm9ybSBPU1BNIHdoaWNoCkBAIC0zNDQsMTQgKzM0Miw2
IEBACiAgICAgICAgICAgICBzdG10KCJOYW1lIiwgIl9BRFIsIDB4JTA4eCIsICgoc2xvdCAmIH43
KSA8PCAxMykgfCAoc2xvdCAmIDcpKTsKICAgICAgICAgICAgIC8qIF9TVU4gPT0gZGV2ICovCiAg
ICAgICAgICAgICBzdG10KCJOYW1lIiwgIl9TVU4sIDB4JTA4eCIsIHNsb3QgPj4gMyk7Ci0gICAg
ICAgICAgICBwdXNoX2Jsb2NrKCJNZXRob2QiLCAiX1BTMCwgMCIpOwotICAgICAgICAgICAgc3Rt
dCgiU3RvcmUiLCAiMHglMDJ4LCBcXF9HUEUuRFBUMSIsIHNsb3QpOwotICAgICAgICAgICAgc3Rt
dCgiU3RvcmUiLCAiMHg4MCwgXFxfR1BFLkRQVDIiKTsKLSAgICAgICAgICAgIHBvcF9ibG9jaygp
OwotICAgICAgICAgICAgcHVzaF9ibG9jaygiTWV0aG9kIiwgIl9QUzMsIDAiKTsKLSAgICAgICAg
ICAgIHN0bXQoIlN0b3JlIiwgIjB4JTAyeCwgXFxfR1BFLkRQVDEiLCBzbG90KTsKLSAgICAgICAg
ICAgIHN0bXQoIlN0b3JlIiwgIjB4ODMsIFxcX0dQRS5EUFQyIik7Ci0gICAgICAgICAgICBwb3Bf
YmxvY2soKTsKICAgICAgICAgICAgIHB1c2hfYmxvY2soIk1ldGhvZCIsICJfRUowLCAxIik7CiAg
ICAgICAgICAgICBzdG10KCJTdG9yZSIsICIweCUwMngsIFxcX0dQRS5EUFQxIiwgc2xvdCk7CiAg
ICAgICAgICAgICBzdG10KCJTdG9yZSIsICIweDg4LCBcXF9HUEUuRFBUMiIpOwo=

--_002_BC00F5384FCFC9499AF06F92E8B78A9E2870CA7340shsmsx502ccrc_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--_002_BC00F5384FCFC9499AF06F92E8B78A9E2870CA7340shsmsx502ccrc_--


From xen-devel-bounces@lists.xensource.com Sun Dec 04 04:46:30 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 04 Dec 2011 04:46:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RX3xU-0001TU-Bm; Sun, 04 Dec 2011 04:45:48 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <xudong.hao@intel.com>) id 1RX3xS-0001TM-Om
	for xen-devel@lists.xensource.com; Sun, 04 Dec 2011 04:45:47 +0000
X-Env-Sender: xudong.hao@intel.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1322973900!6847304!1
X-Originating-IP: [143.182.124.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjA5NTM4\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23105 invoked from network); 4 Dec 2011 04:45:01 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-3.tower-21.messagelabs.com with SMTP;
	4 Dec 2011 04:45:01 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga101.ch.intel.com with ESMTP; 03 Dec 2011 20:44:59 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,292,1320652800"; d="scan'208";a="81984179"
Received: from pgsmsx603.gar.corp.intel.com ([10.221.43.87])
	by azsmga001.ch.intel.com with ESMTP; 03 Dec 2011 20:44:58 -0800
Received: from pgsmsx103.gar.corp.intel.com (10.221.44.82) by
	pgsmsx603.gar.corp.intel.com (10.221.43.87) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Sun, 4 Dec 2011 12:44:57 +0800
Received: from shsmsx602.ccr.corp.intel.com (10.239.4.104) by
	PGSMSX103.gar.corp.intel.com (10.221.44.82) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Sun, 4 Dec 2011 12:44:57 +0800
Received: from shsmsx502.ccr.corp.intel.com ([10.239.4.96]) by
	SHSMSX602.ccr.corp.intel.com ([10.239.4.104]) with mapi; Sun, 4 Dec 2011
	12:44:55 +0800
From: "Hao, Xudong" <xudong.hao@intel.com>
To: "Hao, Xudong" <xudong.hao@intel.com>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>
Date: Sun, 4 Dec 2011 12:44:54 +0800
Thread-Topic: [PATCH] tools/firmware: remove "_PS0/3" Method
Thread-Index: AcywzXyuc/E+gfMtR6Og9gMqN63sawBcRy3A
Message-ID: <BC00F5384FCFC9499AF06F92E8B78A9E2870CA7340@shsmsx502.ccr.corp.intel.com>
References: <BC00F5384FCFC9499AF06F92E8B78A9E2870BB473F@shsmsx502.ccr.corp.intel.com>
In-Reply-To: <BC00F5384FCFC9499AF06F92E8B78A9E2870BB473F@shsmsx502.ccr.corp.intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/mixed;
	boundary="_002_BC00F5384FCFC9499AF06F92E8B78A9E2870CA7340shsmsx502ccrc_"
MIME-Version: 1.0
Cc: "Tian, Kevin" <kevin.tian@intel.com>, Keir Fraser <keir.xen@gmail.com>,
	"Shan, Haitao" <haitao.shan@intel.com>
Subject: Re: [Xen-devel] [PATCH] tools/firmware: remove "_PS0/3" Method
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--_002_BC00F5384FCFC9499AF06F92E8B78A9E2870CA7340shsmsx502ccrc_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

(Resend patch because the previous patch loss to remove one line code.)

tools/firmware: remove "_PS0/3" Method

Do not expose the ACPI power management "_PS0/3" Method to guest firmware. =
According to section 3.4 of the APCI specification 4.0, PCI device control =
the device power through its own specification but not through APCI.

Qemu pushes "_PS0/3" to guest will cause a mess between ACPI PM and PCI PM =
as a result of incorrect ACPI table shipped with the guest BIOS, it may cau=
se a failure of PCI device PM state transition(from PCI_UNKNOWN to PCI_D0).

Signed-off-by: Xudong Hao <xudong.hao@intel.com>
Signed-off-by: Haitao Shan <haitao.shan@intel.com>

diff -r df7cec2c6c03 tools/firmware/hvmloader/acpi/mk_dsdt.c
--- a/tools/firmware/hvmloader/acpi/mk_dsdt.c	Tue Nov 29 13:30:39 2011 -050=
0
+++ b/tools/firmware/hvmloader/acpi/mk_dsdt.c	Fri Dec 02 21:56:14 2011 +080=
0
@@ -323,8 +323,6 @@
      * the ACPI event:
      *  _EJ0: eject a device
      *  _STA: return a device's status, e.g. enabled or removed
-     * Other methods are optional:=20
-     *  _PS0/3: put them here for debug purpose
      *=20
      * Eject button would generate a general-purpose event, then the
      * control method for this event uses Notify() to inform OSPM which
@@ -344,14 +342,6 @@
             stmt("Name", "_ADR, 0x%08x", ((slot & ~7) << 13) | (slot & 7))=
;
             /* _SUN =3D=3D dev */
             stmt("Name", "_SUN, 0x%08x", slot >> 3);
-            push_block("Method", "_PS0, 0");
-            stmt("Store", "0x%02x, \\_GPE.DPT1", slot);
-            stmt("Store", "0x80, \\_GPE.DPT2");
-            pop_block();
-            push_block("Method", "_PS3, 0");
-            stmt("Store", "0x%02x, \\_GPE.DPT1", slot);
-            stmt("Store", "0x83, \\_GPE.DPT2");
-            pop_block();
             push_block("Method", "_EJ0, 1");
             stmt("Store", "0x%02x, \\_GPE.DPT1", slot);
             stmt("Store", "0x88, \\_GPE.DPT2");



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Thanks,
-Xudong


> -----Original Message-----
> From: xen-devel-bounces@lists.xensource.com
> [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Hao, Xudong
> Sent: Friday, December 02, 2011 4:39 PM
> To: xen-devel@lists.xensource.com
> Cc: Tian, Kevin; Keir Fraser; Shan, Haitao
> Subject: [Xen-devel] [PATCH] tools/firmware: remove "_PS0/3" Method
>=20
> tools/firmware: remove "_PS0/3" Method
>=20
> Do not expose the ACPI power management "_PS0/3" Method to guest
> firmware. According to section 3.4 of the APCI specification 4.0, PCI dev=
ice
> control the device power through its own specification but not through AP=
CI.
>=20
> Qemu pushes "_PS0/3" to guest will cause a mess between ACPI PM and PCI
> PM as a result of incorrect ACPI table shipped with the guest BIOS, it ma=
y
> cause a failure of PCI device PM state transition(from PCI_UNKNOWN to
> PCI_D0).
>=20
> Signed-off-by: Xudong Hao <xudong.hao@intel.com>
> Signed-off-by: Haitao Shan <haitao.shan@intel.com>
>=20
> diff -r df7cec2c6c03 tools/firmware/hvmloader/acpi/mk_dsdt.c
> --- a/tools/firmware/hvmloader/acpi/mk_dsdt.c	Tue Nov 29 13:30:39 2011
> -0500
> +++ b/tools/firmware/hvmloader/acpi/mk_dsdt.c	Wed Nov 30 15:08:20 2011
> +0800
> @@ -323,8 +323,6 @@
>       * the ACPI event:
>       *  _EJ0: eject a device
>       *  _STA: return a device's status, e.g. enabled or removed
> -     * Other methods are optional:
> -     *  _PS0/3: put them here for debug purpose
>       *
>       * Eject button would generate a general-purpose event, then the
>       * control method for this event uses Notify() to inform OSPM which =
@@
> -344,13 +342,6 @@
>              stmt("Name", "_ADR, 0x%08x", ((slot & ~7) << 13) | (slot & 7=
));
>              /* _SUN =3D=3D dev */
>              stmt("Name", "_SUN, 0x%08x", slot >> 3);
> -            push_block("Method", "_PS0, 0");
> -            stmt("Store", "0x%02x, \\_GPE.DPT1", slot);
> -            stmt("Store", "0x80, \\_GPE.DPT2");
> -            pop_block();
> -            push_block("Method", "_PS3, 0");
> -            stmt("Store", "0x%02x, \\_GPE.DPT1", slot);
> -            stmt("Store", "0x83, \\_GPE.DPT2");
>              pop_block();
>              push_block("Method", "_EJ0, 1");
>              stmt("Store", "0x%02x, \\_GPE.DPT1", slot)
>=20
>=20
>=20
>=20
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

--_002_BC00F5384FCFC9499AF06F92E8B78A9E2870CA7340shsmsx502ccrc_
Content-Type: application/octet-stream; name="remove_PS0_method.patch"
Content-Description: remove_PS0_method.patch
Content-Disposition: attachment; filename="remove_PS0_method.patch";
	size=1871; creation-date="Wed, 30 Nov 2011 16:24:20 GMT";
	modification-date="Sun, 04 Dec 2011 12:42:31 GMT"
Content-Transfer-Encoding: base64

dG9vbHMvZmlybXdhcmU6IHJlbW92ZSAiX1BTMC8zIiBNZXRob2QKCkRvIG5vdCBleHBvc2UgdGhl
IEFDUEkgcG93ZXIgbWFuYWdlbWVudCAiX1BTMC8zIiBNZXRob2QgdG8gZ3Vlc3QgZmlybXdhcmUu
IEFjY29yZGluZyB0byBzZWN0aW9uIDMuNCBvZiB0aGUgQVBDSSBzcGVjaWZpY2F0aW9uIDQuMCwg
UENJIGRldmljZSBjb250cm9sIHRoZSBkZXZpY2UgcG93ZXIgdGhyb3VnaCBpdHMgb3duIHNwZWNp
ZmljYXRpb24gYnV0IG5vdCB0aHJvdWdoIEFQQ0kuCgpRZW11IHB1c2hlcyAiX1BTMC8zIiB0byBn
dWVzdCB3aWxsIGNhdXNlIGEgbWVzcyBiZXR3ZWVuIEFDUEkgUE0gYW5kIFBDSSBQTSBhcyBhIHJl
c3VsdCBvZiBpbmNvcnJlY3QgQUNQSSB0YWJsZSBzaGlwcGVkIHdpdGggdGhlIGd1ZXN0IEJJT1Ms
IGl0IG1heSBjYXVzZSBhIGZhaWx1cmUgb2YgUENJIGRldmljZSBQTSBzdGF0ZSB0cmFuc2l0aW9u
KGZyb20gUENJX1VOS05PV04gdG8gUENJX0QwKS4KClNpZ25lZC1vZmYtYnk6IFh1ZG9uZyBIYW8g
PHh1ZG9uZy5oYW9AaW50ZWwuY29tPgpTaWduZWQtb2ZmLWJ5OiBIYWl0YW8gU2hhbiA8aGFpdGFv
LnNoYW5AaW50ZWwuY29tPgoKZGlmZiAtciBkZjdjZWMyYzZjMDMgdG9vbHMvZmlybXdhcmUvaHZt
bG9hZGVyL2FjcGkvbWtfZHNkdC5jCi0tLSBhL3Rvb2xzL2Zpcm13YXJlL2h2bWxvYWRlci9hY3Bp
L21rX2RzZHQuYwlUdWUgTm92IDI5IDEzOjMwOjM5IDIwMTEgLTA1MDAKKysrIGIvdG9vbHMvZmly
bXdhcmUvaHZtbG9hZGVyL2FjcGkvbWtfZHNkdC5jCUZyaSBEZWMgMDIgMjE6NTY6MTQgMjAxMSAr
MDgwMApAQCAtMzIzLDggKzMyMyw2IEBACiAgICAgICogdGhlIEFDUEkgZXZlbnQ6CiAgICAgICog
IF9FSjA6IGVqZWN0IGEgZGV2aWNlCiAgICAgICogIF9TVEE6IHJldHVybiBhIGRldmljZSdzIHN0
YXR1cywgZS5nLiBlbmFibGVkIG9yIHJlbW92ZWQKLSAgICAgKiBPdGhlciBtZXRob2RzIGFyZSBv
cHRpb25hbDogCi0gICAgICogIF9QUzAvMzogcHV0IHRoZW0gaGVyZSBmb3IgZGVidWcgcHVycG9z
ZQogICAgICAqIAogICAgICAqIEVqZWN0IGJ1dHRvbiB3b3VsZCBnZW5lcmF0ZSBhIGdlbmVyYWwt
cHVycG9zZSBldmVudCwgdGhlbiB0aGUKICAgICAgKiBjb250cm9sIG1ldGhvZCBmb3IgdGhpcyBl
dmVudCB1c2VzIE5vdGlmeSgpIHRvIGluZm9ybSBPU1BNIHdoaWNoCkBAIC0zNDQsMTQgKzM0Miw2
IEBACiAgICAgICAgICAgICBzdG10KCJOYW1lIiwgIl9BRFIsIDB4JTA4eCIsICgoc2xvdCAmIH43
KSA8PCAxMykgfCAoc2xvdCAmIDcpKTsKICAgICAgICAgICAgIC8qIF9TVU4gPT0gZGV2ICovCiAg
ICAgICAgICAgICBzdG10KCJOYW1lIiwgIl9TVU4sIDB4JTA4eCIsIHNsb3QgPj4gMyk7Ci0gICAg
ICAgICAgICBwdXNoX2Jsb2NrKCJNZXRob2QiLCAiX1BTMCwgMCIpOwotICAgICAgICAgICAgc3Rt
dCgiU3RvcmUiLCAiMHglMDJ4LCBcXF9HUEUuRFBUMSIsIHNsb3QpOwotICAgICAgICAgICAgc3Rt
dCgiU3RvcmUiLCAiMHg4MCwgXFxfR1BFLkRQVDIiKTsKLSAgICAgICAgICAgIHBvcF9ibG9jaygp
OwotICAgICAgICAgICAgcHVzaF9ibG9jaygiTWV0aG9kIiwgIl9QUzMsIDAiKTsKLSAgICAgICAg
ICAgIHN0bXQoIlN0b3JlIiwgIjB4JTAyeCwgXFxfR1BFLkRQVDEiLCBzbG90KTsKLSAgICAgICAg
ICAgIHN0bXQoIlN0b3JlIiwgIjB4ODMsIFxcX0dQRS5EUFQyIik7Ci0gICAgICAgICAgICBwb3Bf
YmxvY2soKTsKICAgICAgICAgICAgIHB1c2hfYmxvY2soIk1ldGhvZCIsICJfRUowLCAxIik7CiAg
ICAgICAgICAgICBzdG10KCJTdG9yZSIsICIweCUwMngsIFxcX0dQRS5EUFQxIiwgc2xvdCk7CiAg
ICAgICAgICAgICBzdG10KCJTdG9yZSIsICIweDg4LCBcXF9HUEUuRFBUMiIpOwo=

--_002_BC00F5384FCFC9499AF06F92E8B78A9E2870CA7340shsmsx502ccrc_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--_002_BC00F5384FCFC9499AF06F92E8B78A9E2870CA7340shsmsx502ccrc_--


From xen-devel-bounces@lists.xensource.com Sun Dec 04 12:00:54 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 04 Dec 2011 12:00:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXAje-0003Tz-D3; Sun, 04 Dec 2011 11:59:58 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <carsten@schiers.de>) id 1RXAjc-0003Tu-Ph
	for xen-devel@lists.xensource.com; Sun, 04 Dec 2011 11:59:57 +0000
X-Env-Sender: carsten@schiers.de
X-Msg-Ref: server-12.tower-21.messagelabs.com!1322999952!6728997!1
X-Originating-IP: [194.117.254.36]
X-SpamReason: No, hits=0.2 required=7.0 tests=FROM_EXCESS_QP,
	MIME_QP_LONG_LINE,SUBJECT_EXCESS_QP
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5216 invoked from network); 4 Dec 2011 11:59:12 -0000
Received: from www.zeus06.de (HELO mail.zeus06.de) (194.117.254.36)
	by server-12.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Dec 2011 11:59:12 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=mail.zeus06.de; h=subject
	:from:to:cc:date:mime-version:content-type
	:content-transfer-encoding:in-reply-to:references:message-id; s=
	beta; bh=/tfxBXXDAyvXZ7Zd0eDe6qUuX6JiXLUeam1G8Vuigwg=; b=Xo0TLGl
	iE31w/yacMYcrfg9gyzeXBMKNWoNzdKmVBAK0F8x6gQeuA/gBUCQRhcVjWghxXRf
	B8HxvYmn7ucR+/VoqyCi3z1oxW+wXjC5PAYLHm7wFaj/cJNH6yfGIbjbBCj4YbxZ
	BrChopN2kJDGYxtyohl5zNfiVbFK4ipEZz6g=
Received: (qmail 4275 invoked from network); 4 Dec 2011 12:59:11 +0100
Received: from unknown (HELO uhura.zz) (l3s6271p1@46.59.207.4)
	by mail.zeus06.de with ESMTPA; 4 Dec 2011 12:59:11 +0100
Received: from localhost (localhost [127.0.0.1])
	by uhura.zz (Postfix) with ESMTP id 08FED2C520;
	Sun,  4 Dec 2011 12:59:11 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at schiers.de
Received: from uhura.zz ([127.0.0.1])
	by localhost (uhura.space.zz [127.0.0.1]) (amavisd-new, port 10024)
	with LMTP id SowEhdkxalCa; Sun,  4 Dec 2011 12:59:08 +0100 (CET)
Received: from uhura.space.zz (localhost [127.0.0.1])
	by uhura.zz (Postfix) with ESMTP id 5E6102C51F;
	Sun,  4 Dec 2011 12:59:08 +0100 (CET)
From: =?iso-8859-1?Q?Carsten_Schiers?= <carsten@schiers.de>
To: =?iso-8859-1?Q?Konrad_Rzeszutek_Wilk?= <konrad@darnok.org>, 
	=?iso-8859-1?Q?Konrad_Rzeszutek_Wilk?= <konrad.wilk@oracle.com>
Date: Sun, 4 Dec 2011 12:59:08 +0100
Mime-Version: 1.0
In-Reply-To: <20111202152339.GA2687@andromeda.dapyr.net>
References: <zarafa.4ece387c.6e85.6aa0c9ca21e63bd9@uhura.space.zz>
X-Priority: 3 (Normal)
X-Mailer: Zarafa 7.0.2-29470
Thread-Index: AcyyfB6v2iSoe+q+SEGqBqr1e66fJQ==
Message-Id: <zarafa.4edb608c.6213.773ddc8955d249af@uhura.space.zz>
Cc: =?iso-8859-1?Q?xen-devel?= <xen-devel@lists.xensource.com>,
	=?iso-8859-1?Q?lersek=40redhat=2Ecom?= <lersek@redhat.com>,
	=?iso-8859-1?Q?Ian_Campbell?= <Ian.Campbell@citrix.com>,
	=?iso-8859-1?Q?zhenzhong=2Eduan=40oracle=2Ecom?=
	<zhenzhong.duan@oracle.com>
Subject: Re: [Xen-devel]
 =?iso-8859-1?q?Load_increase_after_memory_upgrade_=28?=
 =?iso-8859-1?q?part2=29?=
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Thank you, Konrad.

I applied the patch to 3.1.2. In order to have a clear picture, I only enab=
led one PCI card.
The result is:

[   28.028032] Starting SWIOTLB debug thread.
[   28.028076] swiotlb_start_thread: Go!
[   28.028622] xen_swiotlb_start_thread: Go!
[   33.028153] 0 [budget_av 0000:00:00.0] bounce: from:555352(slow:0)to:0 m=
ap:329 unmap:0 sync:555352
[   33.028294] SWIOTLB is 2% full
[   38.028178] 0 budget_av 0000:00:00.0 alloc coherent: 4, free: 0
[   38.028230] 0 [budget_av 0000:00:00.0] bounce: from:127981(slow:0)to:0 m=
ap:0 unmap:0 sync:127981
[   38.028352] SWIOTLB is 2% full
[   43.028170] 0 [budget_av 0000:00:00.0] bounce: from:128310(slow:0)to:0 m=
ap:0 unmap:0 sync:128310
[   43.028310] SWIOTLB is 2% full
[   48.028199] 0 [budget_av 0000:00:00.0] bounce: from:127981(slow:0)to:0 m=
ap:0 unmap:0 sync:127981
[   48.028334] SWIOTLB is 2% full
[   53.028170] 0 [budget_av 0000:00:00.0] bounce: from:128310(slow:0)to:0 m=
ap:0 unmap:0 sync:128310
[   53.028309] SWIOTLB is 2% full
[   58.028138] 0 [budget_av 0000:00:00.0] bounce: from:126994(slow:0)to:0 m=
ap:0 unmap:0 sync:126994
[   58.028195] SWIOTLB is 2% full
[   63.028170] 0 [budget_av 0000:00:00.0] bounce: from:121401(slow:0)to:0 m=
ap:0 unmap:0 sync:121401
[   63.029560] SWIOTLB is 2% full
[   68.028193] 0 [budget_av 0000:00:00.0] bounce: from:127981(slow:0)to:0 m=
ap:0 unmap:0 sync:127981
[   68.028329] SWIOTLB is 2% full
[   73.028104] 0 [budget_av 0000:00:00.0] bounce: from:122717(slow:0)to:0 m=
ap:0 unmap:0 sync:122717
[   73.028244] SWIOTLB is 2% full
[   78.028191] 0 [budget_av 0000:00:00.0] bounce: from:127981(slow:0)to:0 m=
ap:0 unmap:0 sync:127981
[   78.028331] SWIOTLB is 2% full
[   83.028112] 0 [budget_av 0000:00:00.0] bounce: from:128310(slow:0)to:0 m=
ap:0 unmap:0 sync:128310
[   83.028171] SWIOTLB is 2% full

Was that long enough? I hope this helps.

Carsten.

-----Urspr=FCngliche Nachricht-----
Von: Konrad Rzeszutek Wilk [mailto:konrad@darnok.org] =

Gesendet: Freitag, 2. Dezember 2011 16:24
An: Konrad Rzeszutek Wilk
Cc: Ian Campbell; xen-devel; Carsten Schiers; zhenzhong.duan@oracle.com; le=
rsek@redhat.com
Betreff: Re: [Xen-devel] Load increase after memory upgrade (part2)

> > > > > That is a puzzle. It should not. The code is very much the same -=
 both
> > > > > use the generic SWIOTLB which has not changed for years.
> > > > =

> > > > The swiotlb-xen used by classic-xen kernels (which I assume is what
> > > > Carsten means by "Xenified") isn't exactly the same as the stuff in
> > > > mainline Linux, it's been heavily refactored for one thing. It's not
> > > > impossible that mainline is bouncing something it doesn't really ne=
ed
> > > > to.
> > > =

> > > The usage, at least with 'pci_alloc_coherent' is that there is no bou=
ncing
> > > being done. The alloc_coherent will allocate a nice page, underneath =
the 4GB
> > > mark and give it to the driver. The driver can use it as it wishes an=
d there
> > > is no need to bounce buffer.
> > =

> > Oh, I didn't realise dma_alloc_coherent was part of swiotlb now. Only a
> > subset of swiotlb is in use then, all the bouncing stuff _should_ be
> > idle/unused -- but has that been confirmed?
> =

> Nope. I hope that the diagnostic patch I have in mind will prove/disprove=
 that.
> Now I just need to find a moment to write it :-)

Done!

Carsten, can you please patch your kernel with this hacky patch and
when you have booted the new kernel, just do

modprobe dump_swiotlb

it should give an idea of how many bounces are happening, coherent
allocations, syncs, and so on.. along with the last driver that
did those operations.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Dec 04 12:00:54 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 04 Dec 2011 12:00:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXAje-0003Tz-D3; Sun, 04 Dec 2011 11:59:58 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <carsten@schiers.de>) id 1RXAjc-0003Tu-Ph
	for xen-devel@lists.xensource.com; Sun, 04 Dec 2011 11:59:57 +0000
X-Env-Sender: carsten@schiers.de
X-Msg-Ref: server-12.tower-21.messagelabs.com!1322999952!6728997!1
X-Originating-IP: [194.117.254.36]
X-SpamReason: No, hits=0.2 required=7.0 tests=FROM_EXCESS_QP,
	MIME_QP_LONG_LINE,SUBJECT_EXCESS_QP
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5216 invoked from network); 4 Dec 2011 11:59:12 -0000
Received: from www.zeus06.de (HELO mail.zeus06.de) (194.117.254.36)
	by server-12.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Dec 2011 11:59:12 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=mail.zeus06.de; h=subject
	:from:to:cc:date:mime-version:content-type
	:content-transfer-encoding:in-reply-to:references:message-id; s=
	beta; bh=/tfxBXXDAyvXZ7Zd0eDe6qUuX6JiXLUeam1G8Vuigwg=; b=Xo0TLGl
	iE31w/yacMYcrfg9gyzeXBMKNWoNzdKmVBAK0F8x6gQeuA/gBUCQRhcVjWghxXRf
	B8HxvYmn7ucR+/VoqyCi3z1oxW+wXjC5PAYLHm7wFaj/cJNH6yfGIbjbBCj4YbxZ
	BrChopN2kJDGYxtyohl5zNfiVbFK4ipEZz6g=
Received: (qmail 4275 invoked from network); 4 Dec 2011 12:59:11 +0100
Received: from unknown (HELO uhura.zz) (l3s6271p1@46.59.207.4)
	by mail.zeus06.de with ESMTPA; 4 Dec 2011 12:59:11 +0100
Received: from localhost (localhost [127.0.0.1])
	by uhura.zz (Postfix) with ESMTP id 08FED2C520;
	Sun,  4 Dec 2011 12:59:11 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at schiers.de
Received: from uhura.zz ([127.0.0.1])
	by localhost (uhura.space.zz [127.0.0.1]) (amavisd-new, port 10024)
	with LMTP id SowEhdkxalCa; Sun,  4 Dec 2011 12:59:08 +0100 (CET)
Received: from uhura.space.zz (localhost [127.0.0.1])
	by uhura.zz (Postfix) with ESMTP id 5E6102C51F;
	Sun,  4 Dec 2011 12:59:08 +0100 (CET)
From: =?iso-8859-1?Q?Carsten_Schiers?= <carsten@schiers.de>
To: =?iso-8859-1?Q?Konrad_Rzeszutek_Wilk?= <konrad@darnok.org>, 
	=?iso-8859-1?Q?Konrad_Rzeszutek_Wilk?= <konrad.wilk@oracle.com>
Date: Sun, 4 Dec 2011 12:59:08 +0100
Mime-Version: 1.0
In-Reply-To: <20111202152339.GA2687@andromeda.dapyr.net>
References: <zarafa.4ece387c.6e85.6aa0c9ca21e63bd9@uhura.space.zz>
X-Priority: 3 (Normal)
X-Mailer: Zarafa 7.0.2-29470
Thread-Index: AcyyfB6v2iSoe+q+SEGqBqr1e66fJQ==
Message-Id: <zarafa.4edb608c.6213.773ddc8955d249af@uhura.space.zz>
Cc: =?iso-8859-1?Q?xen-devel?= <xen-devel@lists.xensource.com>,
	=?iso-8859-1?Q?lersek=40redhat=2Ecom?= <lersek@redhat.com>,
	=?iso-8859-1?Q?Ian_Campbell?= <Ian.Campbell@citrix.com>,
	=?iso-8859-1?Q?zhenzhong=2Eduan=40oracle=2Ecom?=
	<zhenzhong.duan@oracle.com>
Subject: Re: [Xen-devel]
 =?iso-8859-1?q?Load_increase_after_memory_upgrade_=28?=
 =?iso-8859-1?q?part2=29?=
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Thank you, Konrad.

I applied the patch to 3.1.2. In order to have a clear picture, I only enab=
led one PCI card.
The result is:

[   28.028032] Starting SWIOTLB debug thread.
[   28.028076] swiotlb_start_thread: Go!
[   28.028622] xen_swiotlb_start_thread: Go!
[   33.028153] 0 [budget_av 0000:00:00.0] bounce: from:555352(slow:0)to:0 m=
ap:329 unmap:0 sync:555352
[   33.028294] SWIOTLB is 2% full
[   38.028178] 0 budget_av 0000:00:00.0 alloc coherent: 4, free: 0
[   38.028230] 0 [budget_av 0000:00:00.0] bounce: from:127981(slow:0)to:0 m=
ap:0 unmap:0 sync:127981
[   38.028352] SWIOTLB is 2% full
[   43.028170] 0 [budget_av 0000:00:00.0] bounce: from:128310(slow:0)to:0 m=
ap:0 unmap:0 sync:128310
[   43.028310] SWIOTLB is 2% full
[   48.028199] 0 [budget_av 0000:00:00.0] bounce: from:127981(slow:0)to:0 m=
ap:0 unmap:0 sync:127981
[   48.028334] SWIOTLB is 2% full
[   53.028170] 0 [budget_av 0000:00:00.0] bounce: from:128310(slow:0)to:0 m=
ap:0 unmap:0 sync:128310
[   53.028309] SWIOTLB is 2% full
[   58.028138] 0 [budget_av 0000:00:00.0] bounce: from:126994(slow:0)to:0 m=
ap:0 unmap:0 sync:126994
[   58.028195] SWIOTLB is 2% full
[   63.028170] 0 [budget_av 0000:00:00.0] bounce: from:121401(slow:0)to:0 m=
ap:0 unmap:0 sync:121401
[   63.029560] SWIOTLB is 2% full
[   68.028193] 0 [budget_av 0000:00:00.0] bounce: from:127981(slow:0)to:0 m=
ap:0 unmap:0 sync:127981
[   68.028329] SWIOTLB is 2% full
[   73.028104] 0 [budget_av 0000:00:00.0] bounce: from:122717(slow:0)to:0 m=
ap:0 unmap:0 sync:122717
[   73.028244] SWIOTLB is 2% full
[   78.028191] 0 [budget_av 0000:00:00.0] bounce: from:127981(slow:0)to:0 m=
ap:0 unmap:0 sync:127981
[   78.028331] SWIOTLB is 2% full
[   83.028112] 0 [budget_av 0000:00:00.0] bounce: from:128310(slow:0)to:0 m=
ap:0 unmap:0 sync:128310
[   83.028171] SWIOTLB is 2% full

Was that long enough? I hope this helps.

Carsten.

-----Urspr=FCngliche Nachricht-----
Von: Konrad Rzeszutek Wilk [mailto:konrad@darnok.org] =

Gesendet: Freitag, 2. Dezember 2011 16:24
An: Konrad Rzeszutek Wilk
Cc: Ian Campbell; xen-devel; Carsten Schiers; zhenzhong.duan@oracle.com; le=
rsek@redhat.com
Betreff: Re: [Xen-devel] Load increase after memory upgrade (part2)

> > > > > That is a puzzle. It should not. The code is very much the same -=
 both
> > > > > use the generic SWIOTLB which has not changed for years.
> > > > =

> > > > The swiotlb-xen used by classic-xen kernels (which I assume is what
> > > > Carsten means by "Xenified") isn't exactly the same as the stuff in
> > > > mainline Linux, it's been heavily refactored for one thing. It's not
> > > > impossible that mainline is bouncing something it doesn't really ne=
ed
> > > > to.
> > > =

> > > The usage, at least with 'pci_alloc_coherent' is that there is no bou=
ncing
> > > being done. The alloc_coherent will allocate a nice page, underneath =
the 4GB
> > > mark and give it to the driver. The driver can use it as it wishes an=
d there
> > > is no need to bounce buffer.
> > =

> > Oh, I didn't realise dma_alloc_coherent was part of swiotlb now. Only a
> > subset of swiotlb is in use then, all the bouncing stuff _should_ be
> > idle/unused -- but has that been confirmed?
> =

> Nope. I hope that the diagnostic patch I have in mind will prove/disprove=
 that.
> Now I just need to find a moment to write it :-)

Done!

Carsten, can you please patch your kernel with this hacky patch and
when you have booted the new kernel, just do

modprobe dump_swiotlb

it should give an idea of how many bounces are happening, coherent
allocations, syncs, and so on.. along with the last driver that
did those operations.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Dec 04 12:11:07 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 04 Dec 2011 12:11:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXAtd-0003jk-Qn; Sun, 04 Dec 2011 12:10:17 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <carsten@schiers.de>) id 1RXAtb-0003jb-Pe
	for xen-devel@lists.xensource.com; Sun, 04 Dec 2011 12:10:16 +0000
X-Env-Sender: carsten@schiers.de
X-Msg-Ref: server-8.tower-21.messagelabs.com!1323000571!6833018!1
X-Originating-IP: [194.117.254.36]
X-SpamReason: No, hits=0.2 required=7.0 tests=FROM_EXCESS_QP,
	MIME_QP_LONG_LINE,SUBJECT_EXCESS_QP
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31252 invoked from network); 4 Dec 2011 12:09:32 -0000
Received: from www.zeus06.de (HELO mail.zeus06.de) (194.117.254.36)
	by server-8.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Dec 2011 12:09:32 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=mail.zeus06.de; h=subject
	:from:to:cc:date:mime-version:content-type
	:content-transfer-encoding:in-reply-to:references:message-id; s=
	beta; bh=bAGSWfvjlAj0a3tjzGIvOesny2h84yVK8nhKzqzcD+o=; b=CS76vIh
	D/i2AcOln4QV1qlZqD7Uf32yEzQujW1WYSABYdvZCk4DIw51aZ2y8cEWURXi/f5c
	r2dZZeI5g8ridlBBIJhWRJstPLh/WK1odVKpyDxbwiWXG/yTLpNG3grMOZX1HwnE
	Izevb18gqcNvqkDDnuBRXyw87wByDXQxeTBA=
Received: (qmail 5690 invoked from network); 4 Dec 2011 13:09:31 +0100
Received: from unknown (HELO uhura.zz) (l3s6271p1@46.59.207.4)
	by mail.zeus06.de with ESMTPA; 4 Dec 2011 13:09:31 +0100
Received: from localhost (localhost [127.0.0.1])
	by uhura.zz (Postfix) with ESMTP id 779262C520;
	Sun,  4 Dec 2011 13:09:31 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at schiers.de
Received: from uhura.zz ([127.0.0.1])
	by localhost (uhura.space.zz [127.0.0.1]) (amavisd-new, port 10024)
	with LMTP id tCm4AwTgs7Sk; Sun,  4 Dec 2011 13:09:28 +0100 (CET)
Received: from uhura.space.zz (localhost [127.0.0.1])
	by uhura.zz (Postfix) with ESMTP id DEB302C51F;
	Sun,  4 Dec 2011 13:09:28 +0100 (CET)
From: =?iso-8859-1?Q?Carsten_Schiers?= <carsten@schiers.de>
To: =?iso-8859-1?Q?Konrad_Rzeszutek_Wilk?= <konrad@darnok.org>, 
	=?iso-8859-1?Q?Konrad_Rzeszutek_Wilk?= <konrad.wilk@oracle.com>
Date: Sun, 4 Dec 2011 13:09:28 +0100
Mime-Version: 1.0
In-Reply-To: <20111202152339.GA2687@andromeda.dapyr.net>
References: <zarafa.4ece387c.6e85.6aa0c9ca21e63bd9@uhura.space.zz>
X-Priority: 3 (Normal)
X-Mailer: Zarafa 7.0.2-29470
Thread-Index: AcyyfZDQ+t5YEFT5QrOGNz7W8Ga9CA==
Message-Id: <zarafa.4edb62f8.6417.1a54a5c25b8f0fd7@uhura.space.zz>
Cc: =?iso-8859-1?Q?xen-devel?= <xen-devel@lists.xensource.com>,
	=?iso-8859-1?Q?lersek=40redhat=2Ecom?= <lersek@redhat.com>,
	=?iso-8859-1?Q?Ian_Campbell?= <Ian.Campbell@citrix.com>,
	=?iso-8859-1?Q?zhenzhong=2Eduan=40oracle=2Ecom?=
	<zhenzhong.duan@oracle.com>
Subject: Re: [Xen-devel]
 =?iso-8859-1?q?Load_increase_after_memory_upgrade_=28?=
 =?iso-8859-1?q?part2=29?=
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Here with two cards enabled and creating a bit "work" by watching TV with o=
ne oft hem:

[   23.842720] Starting SWIOTLB debug thread.
[   23.842750] swiotlb_start_thread: Go!
[   23.842838] xen_swiotlb_start_thread: Go!
[   28.841451] 0 [budget_av 0000:00:01.0] bounce: from:435596(slow:0)to:0 m=
ap:658 unmap:0 sync:435596
[   28.841592] SWIOTLB is 4% full
[   33.840147] 0 [budget_av 0000:00:01.0] bounce: from:127652(slow:0)to:0 m=
ap:0 unmap:0 sync:127652
[   33.840283] SWIOTLB is 4% full
[   33.844222] 0 budget_av 0000:00:01.0 alloc coherent: 8, free: 0
[   38.840227] 0 [budget_av 0000:00:01.0] bounce: from:128310(slow:0)to:0 m=
ap:0 unmap:0 sync:128310
[   38.840361] SWIOTLB is 4% full
[   43.840182] 0 [budget_av 0000:00:01.0] bounce: from:128310(slow:0)to:0 m=
ap:0 unmap:0 sync:128310
[   43.840323] SWIOTLB is 4% full
[   48.840094] 0 [budget_av 0000:00:01.0] bounce: from:127652(slow:0)to:0 m=
ap:0 unmap:0 sync:127652
[   48.840154] SWIOTLB is 4% full
[   53.840160] 0 [budget_av 0000:00:01.0] bounce: from:119756(slow:0)to:0 m=
ap:0 unmap:0 sync:119756
[   53.840301] SWIOTLB is 4% full
[   58.840202] 0 [budget_av 0000:00:01.0] bounce: from:128310(slow:0)to:0 m=
ap:0 unmap:0 sync:128310
[   58.840339] SWIOTLB is 4% full
[   63.840626] 0 [budget_av 0000:00:01.0] bounce: from:128310(slow:0)to:0 m=
ap:0 unmap:0 sync:128310
[   63.840686] SWIOTLB is 4% full
[   68.840122] 0 [budget_av 0000:00:01.0] bounce: from:127323(slow:0)to:0 m=
ap:0 unmap:0 sync:127323
[   68.840180] SWIOTLB is 4% full
[   73.840647] 0 [budget_av 0000:00:01.0] bounce: from:211547(slow:0)to:0 m=
ap:0 unmap:0 sync:211547
[   73.840784] SWIOTLB is 4% full
[   78.840204] 0 [budget_av 0000:00:01.0] bounce: from:255962(slow:0)to:0 m=
ap:0 unmap:0 sync:255962
[   78.840344] SWIOTLB is 4% full
[   83.840114] 0 [budget_av 0000:00:01.0] bounce: from:255304(slow:0)to:0 m=
ap:0 unmap:0 sync:255304
[   83.840178] SWIOTLB is 4% full
[   88.840158] 0 [budget_av 0000:00:01.0] bounce: from:256620(slow:0)to:0 m=
ap:0 unmap:0 sync:256620
[   88.840302] SWIOTLB is 4% full
[   93.840185] 0 [budget_av 0000:00:00.0] bounce: from:250040(slow:0)to:0 m=
ap:0 unmap:0 sync:250040
[   93.840319] SWIOTLB is 4% full
[   98.840181] 0 [budget_av 0000:00:00.0] bounce: from:255962(slow:0)to:0 m=
ap:0 unmap:0 sync:255962
[   98.841563] SWIOTLB is 4% full
[  103.841221] 0 [budget_av 0000:00:00.0] bounce: from:255962(slow:0)to:0 m=
ap:0 unmap:0 sync:255962
[  103.841361] SWIOTLB is 4% full
[  108.840247] 0 [budget_av 0000:00:00.0] bounce: from:255962(slow:0)to:0 m=
ap:0 unmap:0 sync:255962
[  108.840389] SWIOTLB is 4% full
[  113.840157] 0 [budget_av 0000:00:00.0] bounce: from:261555(slow:0)to:0 m=
ap:0 unmap:0 sync:261555
[  113.840298] SWIOTLB is 4% full
[  118.840119] 0 [budget_av 0000:00:00.0] bounce: from:295442(slow:0)to:0 m=
ap:0 unmap:0 sync:295442
[  118.840259] SWIOTLB is 4% full
[  123.841025] 0 [budget_av 0000:00:00.0] bounce: from:295113(slow:0)to:0 m=
ap:0 unmap:0 sync:295113
[  123.841164] SWIOTLB is 4% full
[  128.840175] 0 [budget_av 0000:00:00.0] bounce: from:294784(slow:0)to:0 m=
ap:0 unmap:0 sync:294784
[  128.840310] SWIOTLB is 4% full
[  133.840194] 0 [budget_av 0000:00:00.0] bounce: from:293797(slow:0)to:0 m=
ap:0 unmap:0 sync:293797
[  133.840330] SWIOTLB is 4% full
[  138.840498] 0 [budget_av 0000:00:00.0] bounce: from:341502(slow:0)to:0 m=
ap:0 unmap:0 sync:341502
[  138.840637] SWIOTLB is 4% full
[  143.840173] 0 [budget_av 0000:00:00.0] bounce: from:341502(slow:0)to:0 m=
ap:0 unmap:0 sync:341502
[  143.840313] SWIOTLB is 4% full
[  148.840215] 0 [budget_av 0000:00:00.0] bounce: from:341831(slow:0)to:0 m=
ap:0 unmap:0 sync:341831
[  148.840355] SWIOTLB is 4% full
[  153.840205] 0 [budget_av 0000:00:01.0] bounce: from:329658(slow:0)to:0 m=
ap:0 unmap:0 sync:329658
[  153.840341] SWIOTLB is 4% full
[  158.840137] 0 [budget_av 0000:00:00.0] bounce: from:342160(slow:0)to:0 m=
ap:0 unmap:0 sync:342160
[  158.840277] SWIOTLB is 4% full
[  163.841288] 0 [budget_av 0000:00:00.0] bounce: from:341502(slow:0)to:0 m=
ap:0 unmap:0 sync:341502
[  163.841424] SWIOTLB is 4% full
[  168.840198] 0 [budget_av 0000:00:00.0] bounce: from:341502(slow:0)to:0 m=
ap:0 unmap:0 sync:341502
[  168.840339] SWIOTLB is 4% full
[  173.840167] 0 [budget_av 0000:00:00.0] bounce: from:341502(slow:0)to:0 m=
ap:0 unmap:0 sync:341502
[  173.840304] SWIOTLB is 4% full
[  178.840184] 0 [budget_av 0000:00:00.0] bounce: from:328013(slow:0)to:0 m=
ap:0 unmap:0 sync:328013
[  178.840324] SWIOTLB is 4% full
[  183.840129] 0 [budget_av 0000:00:00.0] bounce: from:341831(slow:0)to:0 m=
ap:0 unmap:0 sync:341831
[  183.840269] SWIOTLB is 4% full
[  188.840123] 0 [budget_av 0000:00:01.0] bounce: from:340515(slow:0)to:0 m=
ap:0 unmap:0 sync:340515
[  188.841647] SWIOTLB is 4% full
[  193.840192] 0 [budget_av 0000:00:00.0] bounce: from:338541(slow:0)to:0 m=
ap:0 unmap:0 sync:338541
[  193.840329] SWIOTLB is 4% full
[  198.840148] 0 [budget_av 0000:00:01.0] bounce: from:330316(slow:0)to:0 m=
ap:0 unmap:0 sync:330316
[  198.840230] SWIOTLB is 4% full
[  203.840860] 0 [budget_av 0000:00:00.0] bounce: from:341831(slow:0)to:0 m=
ap:0 unmap:0 sync:341831
[  203.841000] SWIOTLB is 4% full
[  208.840562] 0 [budget_av 0000:00:01.0] bounce: from:337883(slow:0)to:0 m=
ap:0 unmap:0 sync:337883
[  208.840698] SWIOTLB is 4% full
[  213.840171] 0 [budget_av 0000:00:00.0] bounce: from:341502(slow:0)to:0 m=
ap:0 unmap:0 sync:341502
[  213.840311] SWIOTLB is 4% full
[  218.840214] 0 [budget_av 0000:00:01.0] bounce: from:320117(slow:0)to:0 m=
ap:0 unmap:0 sync:320117
[  218.840354] SWIOTLB is 4% full
[  223.840238] 0 [budget_av 0000:00:01.0] bounce: from:299390(slow:0)to:0 m=
ap:0 unmap:0 sync:299390
[  223.840373] SWIOTLB is 4% full
[  228.841415] 0 [budget_av 0000:00:01.0] bounce: from:298732(slow:0)to:0 m=
ap:0 unmap:0 sync:298732
[  228.841560] SWIOTLB is 4% full
[  233.840705] 0 [budget_av 0000:00:00.0] bounce: from:299061(slow:0)to:0 m=
ap:0 unmap:0 sync:299061
[  233.840844] SWIOTLB is 4% full
[  238.840145] 0 [budget_av 0000:00:01.0] bounce: from:293468(slow:0)to:0 m=
ap:0 unmap:0 sync:293468
[  238.840280] SWIOTLB is 4% full

-----Urspr=FCngliche Nachricht-----
Von: Konrad Rzeszutek Wilk [mailto:konrad@darnok.org] =

Gesendet: Freitag, 2. Dezember 2011 16:24
An: Konrad Rzeszutek Wilk
Cc: Ian Campbell; xen-devel; Carsten Schiers; zhenzhong.duan@oracle.com; le=
rsek@redhat.com
Betreff: Re: [Xen-devel] Load increase after memory upgrade (part2)

> > > > > That is a puzzle. It should not. The code is very much the same -=
 both
> > > > > use the generic SWIOTLB which has not changed for years.
> > > > =

> > > > The swiotlb-xen used by classic-xen kernels (which I assume is what
> > > > Carsten means by "Xenified") isn't exactly the same as the stuff in
> > > > mainline Linux, it's been heavily refactored for one thing. It's not
> > > > impossible that mainline is bouncing something it doesn't really ne=
ed
> > > > to.
> > > =

> > > The usage, at least with 'pci_alloc_coherent' is that there is no bou=
ncing
> > > being done. The alloc_coherent will allocate a nice page, underneath =
the 4GB
> > > mark and give it to the driver. The driver can use it as it wishes an=
d there
> > > is no need to bounce buffer.
> > =

> > Oh, I didn't realise dma_alloc_coherent was part of swiotlb now. Only a
> > subset of swiotlb is in use then, all the bouncing stuff _should_ be
> > idle/unused -- but has that been confirmed?
> =

> Nope. I hope that the diagnostic patch I have in mind will prove/disprove=
 that.
> Now I just need to find a moment to write it :-)

Done!

Carsten, can you please patch your kernel with this hacky patch and
when you have booted the new kernel, just do

modprobe dump_swiotlb

it should give an idea of how many bounces are happening, coherent
allocations, syncs, and so on.. along with the last driver that
did those operations.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Dec 04 12:11:07 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 04 Dec 2011 12:11:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXAtd-0003jk-Qn; Sun, 04 Dec 2011 12:10:17 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <carsten@schiers.de>) id 1RXAtb-0003jb-Pe
	for xen-devel@lists.xensource.com; Sun, 04 Dec 2011 12:10:16 +0000
X-Env-Sender: carsten@schiers.de
X-Msg-Ref: server-8.tower-21.messagelabs.com!1323000571!6833018!1
X-Originating-IP: [194.117.254.36]
X-SpamReason: No, hits=0.2 required=7.0 tests=FROM_EXCESS_QP,
	MIME_QP_LONG_LINE,SUBJECT_EXCESS_QP
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31252 invoked from network); 4 Dec 2011 12:09:32 -0000
Received: from www.zeus06.de (HELO mail.zeus06.de) (194.117.254.36)
	by server-8.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Dec 2011 12:09:32 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=mail.zeus06.de; h=subject
	:from:to:cc:date:mime-version:content-type
	:content-transfer-encoding:in-reply-to:references:message-id; s=
	beta; bh=bAGSWfvjlAj0a3tjzGIvOesny2h84yVK8nhKzqzcD+o=; b=CS76vIh
	D/i2AcOln4QV1qlZqD7Uf32yEzQujW1WYSABYdvZCk4DIw51aZ2y8cEWURXi/f5c
	r2dZZeI5g8ridlBBIJhWRJstPLh/WK1odVKpyDxbwiWXG/yTLpNG3grMOZX1HwnE
	Izevb18gqcNvqkDDnuBRXyw87wByDXQxeTBA=
Received: (qmail 5690 invoked from network); 4 Dec 2011 13:09:31 +0100
Received: from unknown (HELO uhura.zz) (l3s6271p1@46.59.207.4)
	by mail.zeus06.de with ESMTPA; 4 Dec 2011 13:09:31 +0100
Received: from localhost (localhost [127.0.0.1])
	by uhura.zz (Postfix) with ESMTP id 779262C520;
	Sun,  4 Dec 2011 13:09:31 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at schiers.de
Received: from uhura.zz ([127.0.0.1])
	by localhost (uhura.space.zz [127.0.0.1]) (amavisd-new, port 10024)
	with LMTP id tCm4AwTgs7Sk; Sun,  4 Dec 2011 13:09:28 +0100 (CET)
Received: from uhura.space.zz (localhost [127.0.0.1])
	by uhura.zz (Postfix) with ESMTP id DEB302C51F;
	Sun,  4 Dec 2011 13:09:28 +0100 (CET)
From: =?iso-8859-1?Q?Carsten_Schiers?= <carsten@schiers.de>
To: =?iso-8859-1?Q?Konrad_Rzeszutek_Wilk?= <konrad@darnok.org>, 
	=?iso-8859-1?Q?Konrad_Rzeszutek_Wilk?= <konrad.wilk@oracle.com>
Date: Sun, 4 Dec 2011 13:09:28 +0100
Mime-Version: 1.0
In-Reply-To: <20111202152339.GA2687@andromeda.dapyr.net>
References: <zarafa.4ece387c.6e85.6aa0c9ca21e63bd9@uhura.space.zz>
X-Priority: 3 (Normal)
X-Mailer: Zarafa 7.0.2-29470
Thread-Index: AcyyfZDQ+t5YEFT5QrOGNz7W8Ga9CA==
Message-Id: <zarafa.4edb62f8.6417.1a54a5c25b8f0fd7@uhura.space.zz>
Cc: =?iso-8859-1?Q?xen-devel?= <xen-devel@lists.xensource.com>,
	=?iso-8859-1?Q?lersek=40redhat=2Ecom?= <lersek@redhat.com>,
	=?iso-8859-1?Q?Ian_Campbell?= <Ian.Campbell@citrix.com>,
	=?iso-8859-1?Q?zhenzhong=2Eduan=40oracle=2Ecom?=
	<zhenzhong.duan@oracle.com>
Subject: Re: [Xen-devel]
 =?iso-8859-1?q?Load_increase_after_memory_upgrade_=28?=
 =?iso-8859-1?q?part2=29?=
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Here with two cards enabled and creating a bit "work" by watching TV with o=
ne oft hem:

[   23.842720] Starting SWIOTLB debug thread.
[   23.842750] swiotlb_start_thread: Go!
[   23.842838] xen_swiotlb_start_thread: Go!
[   28.841451] 0 [budget_av 0000:00:01.0] bounce: from:435596(slow:0)to:0 m=
ap:658 unmap:0 sync:435596
[   28.841592] SWIOTLB is 4% full
[   33.840147] 0 [budget_av 0000:00:01.0] bounce: from:127652(slow:0)to:0 m=
ap:0 unmap:0 sync:127652
[   33.840283] SWIOTLB is 4% full
[   33.844222] 0 budget_av 0000:00:01.0 alloc coherent: 8, free: 0
[   38.840227] 0 [budget_av 0000:00:01.0] bounce: from:128310(slow:0)to:0 m=
ap:0 unmap:0 sync:128310
[   38.840361] SWIOTLB is 4% full
[   43.840182] 0 [budget_av 0000:00:01.0] bounce: from:128310(slow:0)to:0 m=
ap:0 unmap:0 sync:128310
[   43.840323] SWIOTLB is 4% full
[   48.840094] 0 [budget_av 0000:00:01.0] bounce: from:127652(slow:0)to:0 m=
ap:0 unmap:0 sync:127652
[   48.840154] SWIOTLB is 4% full
[   53.840160] 0 [budget_av 0000:00:01.0] bounce: from:119756(slow:0)to:0 m=
ap:0 unmap:0 sync:119756
[   53.840301] SWIOTLB is 4% full
[   58.840202] 0 [budget_av 0000:00:01.0] bounce: from:128310(slow:0)to:0 m=
ap:0 unmap:0 sync:128310
[   58.840339] SWIOTLB is 4% full
[   63.840626] 0 [budget_av 0000:00:01.0] bounce: from:128310(slow:0)to:0 m=
ap:0 unmap:0 sync:128310
[   63.840686] SWIOTLB is 4% full
[   68.840122] 0 [budget_av 0000:00:01.0] bounce: from:127323(slow:0)to:0 m=
ap:0 unmap:0 sync:127323
[   68.840180] SWIOTLB is 4% full
[   73.840647] 0 [budget_av 0000:00:01.0] bounce: from:211547(slow:0)to:0 m=
ap:0 unmap:0 sync:211547
[   73.840784] SWIOTLB is 4% full
[   78.840204] 0 [budget_av 0000:00:01.0] bounce: from:255962(slow:0)to:0 m=
ap:0 unmap:0 sync:255962
[   78.840344] SWIOTLB is 4% full
[   83.840114] 0 [budget_av 0000:00:01.0] bounce: from:255304(slow:0)to:0 m=
ap:0 unmap:0 sync:255304
[   83.840178] SWIOTLB is 4% full
[   88.840158] 0 [budget_av 0000:00:01.0] bounce: from:256620(slow:0)to:0 m=
ap:0 unmap:0 sync:256620
[   88.840302] SWIOTLB is 4% full
[   93.840185] 0 [budget_av 0000:00:00.0] bounce: from:250040(slow:0)to:0 m=
ap:0 unmap:0 sync:250040
[   93.840319] SWIOTLB is 4% full
[   98.840181] 0 [budget_av 0000:00:00.0] bounce: from:255962(slow:0)to:0 m=
ap:0 unmap:0 sync:255962
[   98.841563] SWIOTLB is 4% full
[  103.841221] 0 [budget_av 0000:00:00.0] bounce: from:255962(slow:0)to:0 m=
ap:0 unmap:0 sync:255962
[  103.841361] SWIOTLB is 4% full
[  108.840247] 0 [budget_av 0000:00:00.0] bounce: from:255962(slow:0)to:0 m=
ap:0 unmap:0 sync:255962
[  108.840389] SWIOTLB is 4% full
[  113.840157] 0 [budget_av 0000:00:00.0] bounce: from:261555(slow:0)to:0 m=
ap:0 unmap:0 sync:261555
[  113.840298] SWIOTLB is 4% full
[  118.840119] 0 [budget_av 0000:00:00.0] bounce: from:295442(slow:0)to:0 m=
ap:0 unmap:0 sync:295442
[  118.840259] SWIOTLB is 4% full
[  123.841025] 0 [budget_av 0000:00:00.0] bounce: from:295113(slow:0)to:0 m=
ap:0 unmap:0 sync:295113
[  123.841164] SWIOTLB is 4% full
[  128.840175] 0 [budget_av 0000:00:00.0] bounce: from:294784(slow:0)to:0 m=
ap:0 unmap:0 sync:294784
[  128.840310] SWIOTLB is 4% full
[  133.840194] 0 [budget_av 0000:00:00.0] bounce: from:293797(slow:0)to:0 m=
ap:0 unmap:0 sync:293797
[  133.840330] SWIOTLB is 4% full
[  138.840498] 0 [budget_av 0000:00:00.0] bounce: from:341502(slow:0)to:0 m=
ap:0 unmap:0 sync:341502
[  138.840637] SWIOTLB is 4% full
[  143.840173] 0 [budget_av 0000:00:00.0] bounce: from:341502(slow:0)to:0 m=
ap:0 unmap:0 sync:341502
[  143.840313] SWIOTLB is 4% full
[  148.840215] 0 [budget_av 0000:00:00.0] bounce: from:341831(slow:0)to:0 m=
ap:0 unmap:0 sync:341831
[  148.840355] SWIOTLB is 4% full
[  153.840205] 0 [budget_av 0000:00:01.0] bounce: from:329658(slow:0)to:0 m=
ap:0 unmap:0 sync:329658
[  153.840341] SWIOTLB is 4% full
[  158.840137] 0 [budget_av 0000:00:00.0] bounce: from:342160(slow:0)to:0 m=
ap:0 unmap:0 sync:342160
[  158.840277] SWIOTLB is 4% full
[  163.841288] 0 [budget_av 0000:00:00.0] bounce: from:341502(slow:0)to:0 m=
ap:0 unmap:0 sync:341502
[  163.841424] SWIOTLB is 4% full
[  168.840198] 0 [budget_av 0000:00:00.0] bounce: from:341502(slow:0)to:0 m=
ap:0 unmap:0 sync:341502
[  168.840339] SWIOTLB is 4% full
[  173.840167] 0 [budget_av 0000:00:00.0] bounce: from:341502(slow:0)to:0 m=
ap:0 unmap:0 sync:341502
[  173.840304] SWIOTLB is 4% full
[  178.840184] 0 [budget_av 0000:00:00.0] bounce: from:328013(slow:0)to:0 m=
ap:0 unmap:0 sync:328013
[  178.840324] SWIOTLB is 4% full
[  183.840129] 0 [budget_av 0000:00:00.0] bounce: from:341831(slow:0)to:0 m=
ap:0 unmap:0 sync:341831
[  183.840269] SWIOTLB is 4% full
[  188.840123] 0 [budget_av 0000:00:01.0] bounce: from:340515(slow:0)to:0 m=
ap:0 unmap:0 sync:340515
[  188.841647] SWIOTLB is 4% full
[  193.840192] 0 [budget_av 0000:00:00.0] bounce: from:338541(slow:0)to:0 m=
ap:0 unmap:0 sync:338541
[  193.840329] SWIOTLB is 4% full
[  198.840148] 0 [budget_av 0000:00:01.0] bounce: from:330316(slow:0)to:0 m=
ap:0 unmap:0 sync:330316
[  198.840230] SWIOTLB is 4% full
[  203.840860] 0 [budget_av 0000:00:00.0] bounce: from:341831(slow:0)to:0 m=
ap:0 unmap:0 sync:341831
[  203.841000] SWIOTLB is 4% full
[  208.840562] 0 [budget_av 0000:00:01.0] bounce: from:337883(slow:0)to:0 m=
ap:0 unmap:0 sync:337883
[  208.840698] SWIOTLB is 4% full
[  213.840171] 0 [budget_av 0000:00:00.0] bounce: from:341502(slow:0)to:0 m=
ap:0 unmap:0 sync:341502
[  213.840311] SWIOTLB is 4% full
[  218.840214] 0 [budget_av 0000:00:01.0] bounce: from:320117(slow:0)to:0 m=
ap:0 unmap:0 sync:320117
[  218.840354] SWIOTLB is 4% full
[  223.840238] 0 [budget_av 0000:00:01.0] bounce: from:299390(slow:0)to:0 m=
ap:0 unmap:0 sync:299390
[  223.840373] SWIOTLB is 4% full
[  228.841415] 0 [budget_av 0000:00:01.0] bounce: from:298732(slow:0)to:0 m=
ap:0 unmap:0 sync:298732
[  228.841560] SWIOTLB is 4% full
[  233.840705] 0 [budget_av 0000:00:00.0] bounce: from:299061(slow:0)to:0 m=
ap:0 unmap:0 sync:299061
[  233.840844] SWIOTLB is 4% full
[  238.840145] 0 [budget_av 0000:00:01.0] bounce: from:293468(slow:0)to:0 m=
ap:0 unmap:0 sync:293468
[  238.840280] SWIOTLB is 4% full

-----Urspr=FCngliche Nachricht-----
Von: Konrad Rzeszutek Wilk [mailto:konrad@darnok.org] =

Gesendet: Freitag, 2. Dezember 2011 16:24
An: Konrad Rzeszutek Wilk
Cc: Ian Campbell; xen-devel; Carsten Schiers; zhenzhong.duan@oracle.com; le=
rsek@redhat.com
Betreff: Re: [Xen-devel] Load increase after memory upgrade (part2)

> > > > > That is a puzzle. It should not. The code is very much the same -=
 both
> > > > > use the generic SWIOTLB which has not changed for years.
> > > > =

> > > > The swiotlb-xen used by classic-xen kernels (which I assume is what
> > > > Carsten means by "Xenified") isn't exactly the same as the stuff in
> > > > mainline Linux, it's been heavily refactored for one thing. It's not
> > > > impossible that mainline is bouncing something it doesn't really ne=
ed
> > > > to.
> > > =

> > > The usage, at least with 'pci_alloc_coherent' is that there is no bou=
ncing
> > > being done. The alloc_coherent will allocate a nice page, underneath =
the 4GB
> > > mark and give it to the driver. The driver can use it as it wishes an=
d there
> > > is no need to bounce buffer.
> > =

> > Oh, I didn't realise dma_alloc_coherent was part of swiotlb now. Only a
> > subset of swiotlb is in use then, all the bouncing stuff _should_ be
> > idle/unused -- but has that been confirmed?
> =

> Nope. I hope that the diagnostic patch I have in mind will prove/disprove=
 that.
> Now I just need to find a moment to write it :-)

Done!

Carsten, can you please patch your kernel with this hacky patch and
when you have booted the new kernel, just do

modprobe dump_swiotlb

it should give an idea of how many bounces are happening, coherent
allocations, syncs, and so on.. along with the last driver that
did those operations.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Dec 04 12:19:45 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 04 Dec 2011 12:19:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXB2E-0003u5-V6; Sun, 04 Dec 2011 12:19:10 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <carsten@schiers.de>) id 1RXB2C-0003tz-OZ
	for xen-devel@lists.xensource.com; Sun, 04 Dec 2011 12:19:08 +0000
X-Env-Sender: carsten@schiers.de
X-Msg-Ref: server-8.tower-21.messagelabs.com!1323001104!6833555!1
X-Originating-IP: [194.117.254.36]
X-SpamReason: No, hits=0.2 required=7.0 tests=FROM_EXCESS_QP,
	MIME_QP_LONG_LINE,SUBJECT_EXCESS_QP
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6562 invoked from network); 4 Dec 2011 12:18:24 -0000
Received: from www.zeus06.de (HELO mail.zeus06.de) (194.117.254.36)
	by server-8.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Dec 2011 12:18:24 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=mail.zeus06.de; h=subject
	:from:to:cc:date:mime-version:content-type
	:content-transfer-encoding:in-reply-to:references:message-id; s=
	beta; bh=ooS6ymOV09ZejYAgm5pQSEynp2L+5O9zlW7f4aQ82QU=; b=Ab0k+11
	FELxOb0oXlICeK5KNv+m7St3zyoFJ+bRfdW+wesyh682tafNXQFTaSZ2hMRudwR7
	Wh5qE9Yj1ZS0h9p6LQX83Ol0xI/mf6/FiSEOA2Eyx9ztrMkoFCndjB9jgulpinG1
	ZsF3aqjojc/haROHuTqLISJFoGjXnWZggx2o=
Received: (qmail 7361 invoked from network); 4 Dec 2011 13:18:24 +0100
Received: from unknown (HELO uhura.zz) (l3s6271p1@46.59.207.4)
	by mail.zeus06.de with ESMTPA; 4 Dec 2011 13:18:24 +0100
Received: from localhost (localhost [127.0.0.1])
	by uhura.zz (Postfix) with ESMTP id 0CC622C520;
	Sun,  4 Dec 2011 13:18:24 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at schiers.de
Received: from uhura.zz ([127.0.0.1])
	by localhost (uhura.space.zz [127.0.0.1]) (amavisd-new, port 10024)
	with LMTP id 4tj+m7Dp+Jko; Sun,  4 Dec 2011 13:18:22 +0100 (CET)
Received: from uhura.space.zz (localhost [127.0.0.1])
	by uhura.zz (Postfix) with ESMTP id 12EF32C51F;
	Sun,  4 Dec 2011 13:18:22 +0100 (CET)
From: =?iso-8859-1?Q?Carsten_Schiers?= <carsten@schiers.de>
To: =?iso-8859-1?Q?Konrad_Rzeszutek_Wilk?= <konrad@darnok.org>, 
	=?iso-8859-1?Q?Konrad_Rzeszutek_Wilk?= <konrad.wilk@oracle.com>
Date: Sun, 4 Dec 2011 13:18:22 +0100
Mime-Version: 1.0
In-Reply-To: <20111202152339.GA2687@andromeda.dapyr.net>
References: <zarafa.4ece387c.6e85.6aa0c9ca21e63bd9@uhura.space.zz>
X-Priority: 3 (Normal)
X-Mailer: Zarafa 7.0.2-29470
Thread-Index: Acyyfs6oNkm+7EBhSLei+wl3zCCBMg==
Message-Id: <zarafa.4edb650e.662e.612f45bd445ddd64@uhura.space.zz>
Cc: =?iso-8859-1?Q?xen-devel?= <xen-devel@lists.xensource.com>,
	=?iso-8859-1?Q?lersek=40redhat=2Ecom?= <lersek@redhat.com>,
	=?iso-8859-1?Q?Ian_Campbell?= <Ian.Campbell@citrix.com>,
	=?iso-8859-1?Q?zhenzhong=2Eduan=40oracle=2Ecom?=
	<zhenzhong.duan@oracle.com>
Subject: Re: [Xen-devel]
 =?iso-8859-1?q?Load_increase_after_memory_upgrade_=28?=
 =?iso-8859-1?q?part2=29?=
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Should eventually mention that I create the DomU with only the parameter io=
mmu=3Dsoft. I hope
Nothing more is required. For Xenified, it's swiotlb=3D32,force.

Carsten.

-----Urspr=FCngliche Nachricht-----
Von: Konrad Rzeszutek Wilk [mailto:konrad@darnok.org] =

Gesendet: Freitag, 2. Dezember 2011 16:24
An: Konrad Rzeszutek Wilk
Cc: Ian Campbell; xen-devel; Carsten Schiers; zhenzhong.duan@oracle.com; le=
rsek@redhat.com
Betreff: Re: [Xen-devel] Load increase after memory upgrade (part2)

> > > > > That is a puzzle. It should not. The code is very much the same -=
 both
> > > > > use the generic SWIOTLB which has not changed for years.
> > > > =

> > > > The swiotlb-xen used by classic-xen kernels (which I assume is what
> > > > Carsten means by "Xenified") isn't exactly the same as the stuff in
> > > > mainline Linux, it's been heavily refactored for one thing. It's not
> > > > impossible that mainline is bouncing something it doesn't really ne=
ed
> > > > to.
> > > =

> > > The usage, at least with 'pci_alloc_coherent' is that there is no bou=
ncing
> > > being done. The alloc_coherent will allocate a nice page, underneath =
the 4GB
> > > mark and give it to the driver. The driver can use it as it wishes an=
d there
> > > is no need to bounce buffer.
> > =

> > Oh, I didn't realise dma_alloc_coherent was part of swiotlb now. Only a
> > subset of swiotlb is in use then, all the bouncing stuff _should_ be
> > idle/unused -- but has that been confirmed?
> =

> Nope. I hope that the diagnostic patch I have in mind will prove/disprove=
 that.
> Now I just need to find a moment to write it :-)

Done!

Carsten, can you please patch your kernel with this hacky patch and
when you have booted the new kernel, just do

modprobe dump_swiotlb

it should give an idea of how many bounces are happening, coherent
allocations, syncs, and so on.. along with the last driver that
did those operations.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Dec 04 12:19:45 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 04 Dec 2011 12:19:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXB2E-0003u5-V6; Sun, 04 Dec 2011 12:19:10 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <carsten@schiers.de>) id 1RXB2C-0003tz-OZ
	for xen-devel@lists.xensource.com; Sun, 04 Dec 2011 12:19:08 +0000
X-Env-Sender: carsten@schiers.de
X-Msg-Ref: server-8.tower-21.messagelabs.com!1323001104!6833555!1
X-Originating-IP: [194.117.254.36]
X-SpamReason: No, hits=0.2 required=7.0 tests=FROM_EXCESS_QP,
	MIME_QP_LONG_LINE,SUBJECT_EXCESS_QP
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6562 invoked from network); 4 Dec 2011 12:18:24 -0000
Received: from www.zeus06.de (HELO mail.zeus06.de) (194.117.254.36)
	by server-8.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Dec 2011 12:18:24 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=mail.zeus06.de; h=subject
	:from:to:cc:date:mime-version:content-type
	:content-transfer-encoding:in-reply-to:references:message-id; s=
	beta; bh=ooS6ymOV09ZejYAgm5pQSEynp2L+5O9zlW7f4aQ82QU=; b=Ab0k+11
	FELxOb0oXlICeK5KNv+m7St3zyoFJ+bRfdW+wesyh682tafNXQFTaSZ2hMRudwR7
	Wh5qE9Yj1ZS0h9p6LQX83Ol0xI/mf6/FiSEOA2Eyx9ztrMkoFCndjB9jgulpinG1
	ZsF3aqjojc/haROHuTqLISJFoGjXnWZggx2o=
Received: (qmail 7361 invoked from network); 4 Dec 2011 13:18:24 +0100
Received: from unknown (HELO uhura.zz) (l3s6271p1@46.59.207.4)
	by mail.zeus06.de with ESMTPA; 4 Dec 2011 13:18:24 +0100
Received: from localhost (localhost [127.0.0.1])
	by uhura.zz (Postfix) with ESMTP id 0CC622C520;
	Sun,  4 Dec 2011 13:18:24 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at schiers.de
Received: from uhura.zz ([127.0.0.1])
	by localhost (uhura.space.zz [127.0.0.1]) (amavisd-new, port 10024)
	with LMTP id 4tj+m7Dp+Jko; Sun,  4 Dec 2011 13:18:22 +0100 (CET)
Received: from uhura.space.zz (localhost [127.0.0.1])
	by uhura.zz (Postfix) with ESMTP id 12EF32C51F;
	Sun,  4 Dec 2011 13:18:22 +0100 (CET)
From: =?iso-8859-1?Q?Carsten_Schiers?= <carsten@schiers.de>
To: =?iso-8859-1?Q?Konrad_Rzeszutek_Wilk?= <konrad@darnok.org>, 
	=?iso-8859-1?Q?Konrad_Rzeszutek_Wilk?= <konrad.wilk@oracle.com>
Date: Sun, 4 Dec 2011 13:18:22 +0100
Mime-Version: 1.0
In-Reply-To: <20111202152339.GA2687@andromeda.dapyr.net>
References: <zarafa.4ece387c.6e85.6aa0c9ca21e63bd9@uhura.space.zz>
X-Priority: 3 (Normal)
X-Mailer: Zarafa 7.0.2-29470
Thread-Index: Acyyfs6oNkm+7EBhSLei+wl3zCCBMg==
Message-Id: <zarafa.4edb650e.662e.612f45bd445ddd64@uhura.space.zz>
Cc: =?iso-8859-1?Q?xen-devel?= <xen-devel@lists.xensource.com>,
	=?iso-8859-1?Q?lersek=40redhat=2Ecom?= <lersek@redhat.com>,
	=?iso-8859-1?Q?Ian_Campbell?= <Ian.Campbell@citrix.com>,
	=?iso-8859-1?Q?zhenzhong=2Eduan=40oracle=2Ecom?=
	<zhenzhong.duan@oracle.com>
Subject: Re: [Xen-devel]
 =?iso-8859-1?q?Load_increase_after_memory_upgrade_=28?=
 =?iso-8859-1?q?part2=29?=
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Should eventually mention that I create the DomU with only the parameter io=
mmu=3Dsoft. I hope
Nothing more is required. For Xenified, it's swiotlb=3D32,force.

Carsten.

-----Urspr=FCngliche Nachricht-----
Von: Konrad Rzeszutek Wilk [mailto:konrad@darnok.org] =

Gesendet: Freitag, 2. Dezember 2011 16:24
An: Konrad Rzeszutek Wilk
Cc: Ian Campbell; xen-devel; Carsten Schiers; zhenzhong.duan@oracle.com; le=
rsek@redhat.com
Betreff: Re: [Xen-devel] Load increase after memory upgrade (part2)

> > > > > That is a puzzle. It should not. The code is very much the same -=
 both
> > > > > use the generic SWIOTLB which has not changed for years.
> > > > =

> > > > The swiotlb-xen used by classic-xen kernels (which I assume is what
> > > > Carsten means by "Xenified") isn't exactly the same as the stuff in
> > > > mainline Linux, it's been heavily refactored for one thing. It's not
> > > > impossible that mainline is bouncing something it doesn't really ne=
ed
> > > > to.
> > > =

> > > The usage, at least with 'pci_alloc_coherent' is that there is no bou=
ncing
> > > being done. The alloc_coherent will allocate a nice page, underneath =
the 4GB
> > > mark and give it to the driver. The driver can use it as it wishes an=
d there
> > > is no need to bounce buffer.
> > =

> > Oh, I didn't realise dma_alloc_coherent was part of swiotlb now. Only a
> > subset of swiotlb is in use then, all the bouncing stuff _should_ be
> > idle/unused -- but has that been confirmed?
> =

> Nope. I hope that the diagnostic patch I have in mind will prove/disprove=
 that.
> Now I just need to find a moment to write it :-)

Done!

Carsten, can you please patch your kernel with this hacky patch and
when you have booted the new kernel, just do

modprobe dump_swiotlb

it should give an idea of how many bounces are happening, coherent
allocations, syncs, and so on.. along with the last driver that
did those operations.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Dec 04 13:45:54 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 04 Dec 2011 13:45:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXCNV-0004HH-GX; Sun, 04 Dec 2011 13:45:13 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RXCNT-0004HC-Ri
	for xen-devel@lists.xensource.com; Sun, 04 Dec 2011 13:45:12 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1323006266!4182180!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjAxOQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3121 invoked from network); 4 Dec 2011 13:44:26 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Dec 2011 13:44:26 -0000
X-IronPort-AV: E=Sophos;i="4.71,293,1320624000"; 
   d="scan'208";a="9271834"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Dec 2011 13:44:25 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sun, 4 Dec 2011 13:44:25 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RXCMj-0001zm-4m;
	Sun, 04 Dec 2011 13:44:25 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RXCMj-0001qq-4B;
	Sun, 04 Dec 2011 13:44:25 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10313-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 4 Dec 2011 13:44:25 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10313: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10313 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10313/

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-i386-xl-winxpsp3-vcpus1  4 xen-install         fail REGR. vs. 10201
 test-amd64-i386-xl-win7-amd64  4 xen-install              fail REGR. vs. 10201
 test-amd64-i386-xend-winxpsp3  4 xen-install              fail REGR. vs. 10201
 test-amd64-i386-pv            4 xen-install               fail REGR. vs. 10201
 test-amd64-i386-xl-credit2    4 xen-install               fail REGR. vs. 10201
 test-amd64-i386-xl-multivcpu  4 xen-install               fail REGR. vs. 10201
 test-amd64-i386-xl            4 xen-install               fail REGR. vs. 10201
 test-amd64-i386-pair          6 xen-install/dst_host      fail REGR. vs. 10201
 test-amd64-i386-pair          5 xen-install/src_host      fail REGR. vs. 10201
 build-i386                    4 xen-build                 fail REGR. vs. 10201
 build-i386-oldkern            4 xen-build                 fail REGR. vs. 10201
 test-amd64-i386-rhel6hvm-intel  4 xen-install             fail REGR. vs. 10201
 test-amd64-i386-rhel6hvm-amd  4 xen-install               fail REGR. vs. 10201
 test-amd64-amd64-win          8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-i386-win-vcpus1    4 xen-install               fail REGR. vs. 10201
 test-amd64-amd64-xl-win       8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-i386-win           4 xen-install               fail REGR. vs. 10201
 test-amd64-i386-xl-win-vcpus1  4 xen-install              fail REGR. vs. 10201

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-win7-amd64  7 windows-install              fail never pass
 test-i386-i386-xl-winxpsp3    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-i386-i386-pv             1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl             1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pair           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   never pass
 test-i386-i386-win            1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-win         1 xen-build-check(1)           blocked  n/a

version targeted for testing:
 xen                  a4d7c27ec1f1
baseline version:
 xen                  62ff6a318c5d

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Anthony PERARD <anthony.perard@citrix.com>
  Brendan Cully <brendan@cs.ubc.ca>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@novell.com>
  Jan Beulich <jbeulich@suse.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Jonathan Davies <jonathan.davies@citrix.com>
  juergen.gross@ts.fujitsu.com
  Keir Fraser <keir@xen.org>
  Liu, Jinsong <jinsong.liu@intel.com>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
  Philipp Hahn <hahn@univention.de>
  Shriram Rajagopalan <rshriram@cs.ubc.ca>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang2 <wei.wang2@amd.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   fail    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           fail    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           fail    
 test-i386-i386-xl                                            blocked 
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-i386-i386-pair                                          blocked 
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           fail    
 test-i386-i386-pv                                            blocked 
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           blocked 
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        blocked 
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   blocked 


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 1262 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Dec 04 13:45:54 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 04 Dec 2011 13:45:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXCNV-0004HH-GX; Sun, 04 Dec 2011 13:45:13 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RXCNT-0004HC-Ri
	for xen-devel@lists.xensource.com; Sun, 04 Dec 2011 13:45:12 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1323006266!4182180!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjAxOQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3121 invoked from network); 4 Dec 2011 13:44:26 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Dec 2011 13:44:26 -0000
X-IronPort-AV: E=Sophos;i="4.71,293,1320624000"; 
   d="scan'208";a="9271834"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Dec 2011 13:44:25 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sun, 4 Dec 2011 13:44:25 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RXCMj-0001zm-4m;
	Sun, 04 Dec 2011 13:44:25 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RXCMj-0001qq-4B;
	Sun, 04 Dec 2011 13:44:25 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10313-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 4 Dec 2011 13:44:25 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10313: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10313 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10313/

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-i386-xl-winxpsp3-vcpus1  4 xen-install         fail REGR. vs. 10201
 test-amd64-i386-xl-win7-amd64  4 xen-install              fail REGR. vs. 10201
 test-amd64-i386-xend-winxpsp3  4 xen-install              fail REGR. vs. 10201
 test-amd64-i386-pv            4 xen-install               fail REGR. vs. 10201
 test-amd64-i386-xl-credit2    4 xen-install               fail REGR. vs. 10201
 test-amd64-i386-xl-multivcpu  4 xen-install               fail REGR. vs. 10201
 test-amd64-i386-xl            4 xen-install               fail REGR. vs. 10201
 test-amd64-i386-pair          6 xen-install/dst_host      fail REGR. vs. 10201
 test-amd64-i386-pair          5 xen-install/src_host      fail REGR. vs. 10201
 build-i386                    4 xen-build                 fail REGR. vs. 10201
 build-i386-oldkern            4 xen-build                 fail REGR. vs. 10201
 test-amd64-i386-rhel6hvm-intel  4 xen-install             fail REGR. vs. 10201
 test-amd64-i386-rhel6hvm-amd  4 xen-install               fail REGR. vs. 10201
 test-amd64-amd64-win          8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-i386-win-vcpus1    4 xen-install               fail REGR. vs. 10201
 test-amd64-amd64-xl-win       8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-i386-win           4 xen-install               fail REGR. vs. 10201
 test-amd64-i386-xl-win-vcpus1  4 xen-install              fail REGR. vs. 10201

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-win7-amd64  7 windows-install              fail never pass
 test-i386-i386-xl-winxpsp3    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-i386-i386-pv             1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl             1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pair           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   never pass
 test-i386-i386-win            1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-win         1 xen-build-check(1)           blocked  n/a

version targeted for testing:
 xen                  a4d7c27ec1f1
baseline version:
 xen                  62ff6a318c5d

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Anthony PERARD <anthony.perard@citrix.com>
  Brendan Cully <brendan@cs.ubc.ca>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@novell.com>
  Jan Beulich <jbeulich@suse.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Jonathan Davies <jonathan.davies@citrix.com>
  juergen.gross@ts.fujitsu.com
  Keir Fraser <keir@xen.org>
  Liu, Jinsong <jinsong.liu@intel.com>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
  Philipp Hahn <hahn@univention.de>
  Shriram Rajagopalan <rshriram@cs.ubc.ca>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang2 <wei.wang2@amd.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   fail    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           fail    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           fail    
 test-i386-i386-xl                                            blocked 
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-i386-i386-pair                                          blocked 
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           fail    
 test-i386-i386-pv                                            blocked 
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           blocked 
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        blocked 
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   blocked 


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 1262 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Dec 04 17:31:11 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 04 Dec 2011 17:31:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXFtF-00063K-5h; Sun, 04 Dec 2011 17:30:13 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RXFtC-00063B-W6
	for xen-devel@lists.xensource.com; Sun, 04 Dec 2011 17:30:11 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1323019767!6130862!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjAxOQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22451 invoked from network); 4 Dec 2011 17:29:27 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Dec 2011 17:29:27 -0000
X-IronPort-AV: E=Sophos;i="4.71,294,1320624000"; 
   d="scan'208";a="9272720"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Dec 2011 17:29:26 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sun, 4 Dec 2011 17:29:26 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RXFsU-0003GV-7v;
	Sun, 04 Dec 2011 17:29:26 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RXFsU-0002tW-24;
	Sun, 04 Dec 2011 17:29:26 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10317-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 4 Dec 2011 17:29:26 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10317: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10317 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10317/

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-i386-xl-winxpsp3-vcpus1  4 xen-install         fail REGR. vs. 10201
 test-amd64-i386-xl-win7-amd64  4 xen-install              fail REGR. vs. 10201
 test-amd64-i386-xend-winxpsp3  4 xen-install              fail REGR. vs. 10201
 test-amd64-i386-pv            4 xen-install               fail REGR. vs. 10201
 test-amd64-i386-xl-credit2    4 xen-install               fail REGR. vs. 10201
 test-amd64-i386-xl-multivcpu  4 xen-install               fail REGR. vs. 10201
 test-amd64-i386-xl            4 xen-install               fail REGR. vs. 10201
 test-amd64-i386-pair          6 xen-install/dst_host      fail REGR. vs. 10201
 test-amd64-i386-pair          5 xen-install/src_host      fail REGR. vs. 10201
 build-i386                    4 xen-build                 fail REGR. vs. 10201
 build-i386-oldkern            4 xen-build                 fail REGR. vs. 10201
 test-amd64-i386-rhel6hvm-intel  4 xen-install             fail REGR. vs. 10201
 test-amd64-i386-rhel6hvm-amd  4 xen-install               fail REGR. vs. 10201
 test-amd64-amd64-win          8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-i386-win-vcpus1    4 xen-install               fail REGR. vs. 10201
 test-amd64-amd64-xl-win       8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-i386-win           4 xen-install               fail REGR. vs. 10201
 test-amd64-i386-xl-win-vcpus1  4 xen-install              fail REGR. vs. 10201

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf     14 guest-localmigrate/x10      fail pass in 10313

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-win7-amd64  7 windows-install              fail never pass
 test-i386-i386-xl-winxpsp3    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-i386-i386-pv             1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl             1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf-pin 14 guest-localmigrate/x10   fail blocked in 10201
 test-i386-i386-pair           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   never pass
 test-i386-i386-win            1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-win         1 xen-build-check(1)           blocked  n/a

version targeted for testing:
 xen                  a4d7c27ec1f1
baseline version:
 xen                  62ff6a318c5d

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Anthony PERARD <anthony.perard@citrix.com>
  Brendan Cully <brendan@cs.ubc.ca>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@novell.com>
  Jan Beulich <jbeulich@suse.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Jonathan Davies <jonathan.davies@citrix.com>
  juergen.gross@ts.fujitsu.com
  Keir Fraser <keir@xen.org>
  Liu, Jinsong <jinsong.liu@intel.com>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
  Philipp Hahn <hahn@univention.de>
  Shriram Rajagopalan <rshriram@cs.ubc.ca>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang2 <wei.wang2@amd.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   fail    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           fail    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           fail    
 test-i386-i386-xl                                            blocked 
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-i386-i386-pair                                          blocked 
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           fail    
 test-i386-i386-pv                                            blocked 
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           blocked 
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        blocked 
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   blocked 


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 1262 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Dec 04 17:31:11 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 04 Dec 2011 17:31:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXFtF-00063K-5h; Sun, 04 Dec 2011 17:30:13 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RXFtC-00063B-W6
	for xen-devel@lists.xensource.com; Sun, 04 Dec 2011 17:30:11 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1323019767!6130862!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjAxOQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22451 invoked from network); 4 Dec 2011 17:29:27 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Dec 2011 17:29:27 -0000
X-IronPort-AV: E=Sophos;i="4.71,294,1320624000"; 
   d="scan'208";a="9272720"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Dec 2011 17:29:26 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sun, 4 Dec 2011 17:29:26 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RXFsU-0003GV-7v;
	Sun, 04 Dec 2011 17:29:26 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RXFsU-0002tW-24;
	Sun, 04 Dec 2011 17:29:26 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10317-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 4 Dec 2011 17:29:26 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10317: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10317 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10317/

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-i386-xl-winxpsp3-vcpus1  4 xen-install         fail REGR. vs. 10201
 test-amd64-i386-xl-win7-amd64  4 xen-install              fail REGR. vs. 10201
 test-amd64-i386-xend-winxpsp3  4 xen-install              fail REGR. vs. 10201
 test-amd64-i386-pv            4 xen-install               fail REGR. vs. 10201
 test-amd64-i386-xl-credit2    4 xen-install               fail REGR. vs. 10201
 test-amd64-i386-xl-multivcpu  4 xen-install               fail REGR. vs. 10201
 test-amd64-i386-xl            4 xen-install               fail REGR. vs. 10201
 test-amd64-i386-pair          6 xen-install/dst_host      fail REGR. vs. 10201
 test-amd64-i386-pair          5 xen-install/src_host      fail REGR. vs. 10201
 build-i386                    4 xen-build                 fail REGR. vs. 10201
 build-i386-oldkern            4 xen-build                 fail REGR. vs. 10201
 test-amd64-i386-rhel6hvm-intel  4 xen-install             fail REGR. vs. 10201
 test-amd64-i386-rhel6hvm-amd  4 xen-install               fail REGR. vs. 10201
 test-amd64-amd64-win          8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-i386-win-vcpus1    4 xen-install               fail REGR. vs. 10201
 test-amd64-amd64-xl-win       8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-i386-win           4 xen-install               fail REGR. vs. 10201
 test-amd64-i386-xl-win-vcpus1  4 xen-install              fail REGR. vs. 10201

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf     14 guest-localmigrate/x10      fail pass in 10313

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-win7-amd64  7 windows-install              fail never pass
 test-i386-i386-xl-winxpsp3    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-i386-i386-pv             1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl             1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf-pin 14 guest-localmigrate/x10   fail blocked in 10201
 test-i386-i386-pair           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   never pass
 test-i386-i386-win            1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-win         1 xen-build-check(1)           blocked  n/a

version targeted for testing:
 xen                  a4d7c27ec1f1
baseline version:
 xen                  62ff6a318c5d

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Anthony PERARD <anthony.perard@citrix.com>
  Brendan Cully <brendan@cs.ubc.ca>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@novell.com>
  Jan Beulich <jbeulich@suse.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Jonathan Davies <jonathan.davies@citrix.com>
  juergen.gross@ts.fujitsu.com
  Keir Fraser <keir@xen.org>
  Liu, Jinsong <jinsong.liu@intel.com>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
  Philipp Hahn <hahn@univention.de>
  Shriram Rajagopalan <rshriram@cs.ubc.ca>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang2 <wei.wang2@amd.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   fail    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           fail    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           fail    
 test-i386-i386-xl                                            blocked 
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-i386-i386-pair                                          blocked 
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           fail    
 test-i386-i386-pv                                            blocked 
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           blocked 
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        blocked 
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   blocked 


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 1262 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Dec 04 19:57:09 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 04 Dec 2011 19:57:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXIAZ-0006bD-GX; Sun, 04 Dec 2011 19:56:15 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RXIAX-0006b5-9p
	for xen-devel@lists.xensource.com; Sun, 04 Dec 2011 19:56:13 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1323028527!4214826!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjAxOQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31650 invoked from network); 4 Dec 2011 19:55:27 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Dec 2011 19:55:27 -0000
X-IronPort-AV: E=Sophos;i="4.71,294,1320624000"; 
   d="scan'208";a="9274133"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Dec 2011 19:55:26 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sun, 4 Dec 2011 19:55:25 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RXI9l-00044a-Q0;
	Sun, 04 Dec 2011 19:55:25 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RXI9l-0001a3-Mz;
	Sun, 04 Dec 2011 19:55:25 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10322-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 4 Dec 2011 19:55:25 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10322: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10322 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10322/

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-i386-xl-winxpsp3-vcpus1  4 xen-install         fail REGR. vs. 10201
 test-amd64-i386-xl-win7-amd64  4 xen-install              fail REGR. vs. 10201
 test-amd64-i386-xend-winxpsp3  4 xen-install              fail REGR. vs. 10201
 test-amd64-i386-pv            4 xen-install               fail REGR. vs. 10201
 test-amd64-i386-xl-credit2    4 xen-install               fail REGR. vs. 10201
 test-amd64-i386-xl-multivcpu  4 xen-install               fail REGR. vs. 10201
 test-amd64-i386-xl            4 xen-install               fail REGR. vs. 10201
 test-amd64-i386-pair          6 xen-install/dst_host      fail REGR. vs. 10201
 test-amd64-i386-pair          5 xen-install/src_host      fail REGR. vs. 10201
 build-i386                    4 xen-build                 fail REGR. vs. 10201
 build-i386-oldkern            4 xen-build                 fail REGR. vs. 10201
 test-amd64-i386-rhel6hvm-intel  4 xen-install             fail REGR. vs. 10201
 test-amd64-i386-rhel6hvm-amd  4 xen-install               fail REGR. vs. 10201
 test-amd64-amd64-win          8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-i386-win-vcpus1    4 xen-install               fail REGR. vs. 10201
 test-amd64-amd64-xl-win       8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-i386-win           4 xen-install               fail REGR. vs. 10201
 test-amd64-i386-xl-win-vcpus1  4 xen-install              fail REGR. vs. 10201

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf      5 xen-boot                    fail pass in 10317
 test-amd64-amd64-xl-sedf 14 guest-localmigrate/x10 fail in 10317 pass in 10313

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-win7-amd64  7 windows-install              fail never pass
 test-i386-i386-xl-winxpsp3    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-i386-i386-pv             1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl             1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pair           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   never pass
 test-i386-i386-win            1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-win         1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf-pin 14 guest-localmigrate/x10 fail in 10317 blocked in 10201

version targeted for testing:
 xen                  a4d7c27ec1f1
baseline version:
 xen                  62ff6a318c5d

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Anthony PERARD <anthony.perard@citrix.com>
  Brendan Cully <brendan@cs.ubc.ca>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@novell.com>
  Jan Beulich <jbeulich@suse.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Jonathan Davies <jonathan.davies@citrix.com>
  juergen.gross@ts.fujitsu.com
  Keir Fraser <keir@xen.org>
  Liu, Jinsong <jinsong.liu@intel.com>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
  Philipp Hahn <hahn@univention.de>
  Shriram Rajagopalan <rshriram@cs.ubc.ca>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang2 <wei.wang2@amd.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   fail    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           fail    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           fail    
 test-i386-i386-xl                                            blocked 
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-i386-i386-pair                                          blocked 
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           fail    
 test-i386-i386-pv                                            blocked 
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           blocked 
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        blocked 
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   blocked 


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 1262 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Dec 04 19:57:09 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 04 Dec 2011 19:57:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXIAZ-0006bD-GX; Sun, 04 Dec 2011 19:56:15 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RXIAX-0006b5-9p
	for xen-devel@lists.xensource.com; Sun, 04 Dec 2011 19:56:13 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1323028527!4214826!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjAxOQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31650 invoked from network); 4 Dec 2011 19:55:27 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Dec 2011 19:55:27 -0000
X-IronPort-AV: E=Sophos;i="4.71,294,1320624000"; 
   d="scan'208";a="9274133"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Dec 2011 19:55:26 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sun, 4 Dec 2011 19:55:25 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RXI9l-00044a-Q0;
	Sun, 04 Dec 2011 19:55:25 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RXI9l-0001a3-Mz;
	Sun, 04 Dec 2011 19:55:25 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10322-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 4 Dec 2011 19:55:25 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10322: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10322 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10322/

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-i386-xl-winxpsp3-vcpus1  4 xen-install         fail REGR. vs. 10201
 test-amd64-i386-xl-win7-amd64  4 xen-install              fail REGR. vs. 10201
 test-amd64-i386-xend-winxpsp3  4 xen-install              fail REGR. vs. 10201
 test-amd64-i386-pv            4 xen-install               fail REGR. vs. 10201
 test-amd64-i386-xl-credit2    4 xen-install               fail REGR. vs. 10201
 test-amd64-i386-xl-multivcpu  4 xen-install               fail REGR. vs. 10201
 test-amd64-i386-xl            4 xen-install               fail REGR. vs. 10201
 test-amd64-i386-pair          6 xen-install/dst_host      fail REGR. vs. 10201
 test-amd64-i386-pair          5 xen-install/src_host      fail REGR. vs. 10201
 build-i386                    4 xen-build                 fail REGR. vs. 10201
 build-i386-oldkern            4 xen-build                 fail REGR. vs. 10201
 test-amd64-i386-rhel6hvm-intel  4 xen-install             fail REGR. vs. 10201
 test-amd64-i386-rhel6hvm-amd  4 xen-install               fail REGR. vs. 10201
 test-amd64-amd64-win          8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-i386-win-vcpus1    4 xen-install               fail REGR. vs. 10201
 test-amd64-amd64-xl-win       8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-i386-win           4 xen-install               fail REGR. vs. 10201
 test-amd64-i386-xl-win-vcpus1  4 xen-install              fail REGR. vs. 10201

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf      5 xen-boot                    fail pass in 10317
 test-amd64-amd64-xl-sedf 14 guest-localmigrate/x10 fail in 10317 pass in 10313

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-win7-amd64  7 windows-install              fail never pass
 test-i386-i386-xl-winxpsp3    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-i386-i386-pv             1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl             1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pair           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   never pass
 test-i386-i386-win            1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-win         1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf-pin 14 guest-localmigrate/x10 fail in 10317 blocked in 10201

version targeted for testing:
 xen                  a4d7c27ec1f1
baseline version:
 xen                  62ff6a318c5d

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Anthony PERARD <anthony.perard@citrix.com>
  Brendan Cully <brendan@cs.ubc.ca>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@novell.com>
  Jan Beulich <jbeulich@suse.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Jonathan Davies <jonathan.davies@citrix.com>
  juergen.gross@ts.fujitsu.com
  Keir Fraser <keir@xen.org>
  Liu, Jinsong <jinsong.liu@intel.com>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
  Philipp Hahn <hahn@univention.de>
  Shriram Rajagopalan <rshriram@cs.ubc.ca>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang2 <wei.wang2@amd.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   fail    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           fail    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           fail    
 test-i386-i386-xl                                            blocked 
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-i386-i386-pair                                          blocked 
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           fail    
 test-i386-i386-pv                                            blocked 
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           blocked 
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        blocked 
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   blocked 


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 1262 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Dec 04 21:41:14 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 04 Dec 2011 21:41:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXJnG-00071X-6H; Sun, 04 Dec 2011 21:40:18 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RXJnE-00071S-BW
	for xen-devel@lists.xensource.com; Sun, 04 Dec 2011 21:40:16 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1323034769!6864741!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjAxOQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28699 invoked from network); 4 Dec 2011 21:39:30 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Dec 2011 21:39:30 -0000
X-IronPort-AV: E=Sophos;i="4.71,295,1320624000"; 
   d="scan'208";a="9275218"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Dec 2011 21:39:28 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sun, 4 Dec 2011 21:39:28 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RXJmR-0004eR-Qj;
	Sun, 04 Dec 2011 21:39:27 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RXJmR-00026L-Ps;
	Sun, 04 Dec 2011 21:39:27 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10325-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 4 Dec 2011 21:39:27 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10325: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10325 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10325/

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-i386-xl-winxpsp3-vcpus1  4 xen-install         fail REGR. vs. 10201
 test-amd64-i386-xl-win7-amd64  4 xen-install              fail REGR. vs. 10201
 test-amd64-i386-xend-winxpsp3  4 xen-install              fail REGR. vs. 10201
 test-amd64-i386-pv            4 xen-install               fail REGR. vs. 10201
 test-amd64-i386-xl-credit2    4 xen-install               fail REGR. vs. 10201
 test-amd64-i386-xl-multivcpu  4 xen-install               fail REGR. vs. 10201
 test-amd64-i386-xl            4 xen-install               fail REGR. vs. 10201
 test-amd64-i386-pair          6 xen-install/dst_host      fail REGR. vs. 10201
 test-amd64-i386-pair          5 xen-install/src_host      fail REGR. vs. 10201
 build-i386                    4 xen-build                 fail REGR. vs. 10201
 build-i386-oldkern            4 xen-build                 fail REGR. vs. 10201
 test-amd64-i386-rhel6hvm-intel  4 xen-install             fail REGR. vs. 10201
 test-amd64-i386-rhel6hvm-amd  4 xen-install               fail REGR. vs. 10201
 test-amd64-amd64-win          8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-i386-win-vcpus1    4 xen-install               fail REGR. vs. 10201
 test-amd64-amd64-xl-win       8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-i386-win           4 xen-install               fail REGR. vs. 10201
 test-amd64-i386-xl-win-vcpus1  4 xen-install              fail REGR. vs. 10201

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf      5 xen-boot                    fail pass in 10317
 test-amd64-amd64-xl-sedf 14 guest-localmigrate/x10 fail in 10317 pass in 10313

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-win7-amd64  7 windows-install              fail never pass
 test-i386-i386-xl-winxpsp3    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-i386-i386-pv             1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl             1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pair           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   never pass
 test-i386-i386-win            1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-win         1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf-pin 14 guest-localmigrate/x10 fail in 10317 blocked in 10201

version targeted for testing:
 xen                  a4d7c27ec1f1
baseline version:
 xen                  62ff6a318c5d

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Anthony PERARD <anthony.perard@citrix.com>
  Brendan Cully <brendan@cs.ubc.ca>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@novell.com>
  Jan Beulich <jbeulich@suse.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Jonathan Davies <jonathan.davies@citrix.com>
  juergen.gross@ts.fujitsu.com
  Keir Fraser <keir@xen.org>
  Liu, Jinsong <jinsong.liu@intel.com>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
  Philipp Hahn <hahn@univention.de>
  Shriram Rajagopalan <rshriram@cs.ubc.ca>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang2 <wei.wang2@amd.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   fail    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           fail    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           fail    
 test-i386-i386-xl                                            blocked 
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-i386-i386-pair                                          blocked 
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           fail    
 test-i386-i386-pv                                            blocked 
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           blocked 
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        blocked 
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   blocked 


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 1262 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Dec 04 21:41:14 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 04 Dec 2011 21:41:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXJnG-00071X-6H; Sun, 04 Dec 2011 21:40:18 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RXJnE-00071S-BW
	for xen-devel@lists.xensource.com; Sun, 04 Dec 2011 21:40:16 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1323034769!6864741!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjAxOQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28699 invoked from network); 4 Dec 2011 21:39:30 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Dec 2011 21:39:30 -0000
X-IronPort-AV: E=Sophos;i="4.71,295,1320624000"; 
   d="scan'208";a="9275218"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Dec 2011 21:39:28 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sun, 4 Dec 2011 21:39:28 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RXJmR-0004eR-Qj;
	Sun, 04 Dec 2011 21:39:27 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RXJmR-00026L-Ps;
	Sun, 04 Dec 2011 21:39:27 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10325-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 4 Dec 2011 21:39:27 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10325: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10325 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10325/

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-i386-xl-winxpsp3-vcpus1  4 xen-install         fail REGR. vs. 10201
 test-amd64-i386-xl-win7-amd64  4 xen-install              fail REGR. vs. 10201
 test-amd64-i386-xend-winxpsp3  4 xen-install              fail REGR. vs. 10201
 test-amd64-i386-pv            4 xen-install               fail REGR. vs. 10201
 test-amd64-i386-xl-credit2    4 xen-install               fail REGR. vs. 10201
 test-amd64-i386-xl-multivcpu  4 xen-install               fail REGR. vs. 10201
 test-amd64-i386-xl            4 xen-install               fail REGR. vs. 10201
 test-amd64-i386-pair          6 xen-install/dst_host      fail REGR. vs. 10201
 test-amd64-i386-pair          5 xen-install/src_host      fail REGR. vs. 10201
 build-i386                    4 xen-build                 fail REGR. vs. 10201
 build-i386-oldkern            4 xen-build                 fail REGR. vs. 10201
 test-amd64-i386-rhel6hvm-intel  4 xen-install             fail REGR. vs. 10201
 test-amd64-i386-rhel6hvm-amd  4 xen-install               fail REGR. vs. 10201
 test-amd64-amd64-win          8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-i386-win-vcpus1    4 xen-install               fail REGR. vs. 10201
 test-amd64-amd64-xl-win       8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-i386-win           4 xen-install               fail REGR. vs. 10201
 test-amd64-i386-xl-win-vcpus1  4 xen-install              fail REGR. vs. 10201

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf      5 xen-boot                    fail pass in 10317
 test-amd64-amd64-xl-sedf 14 guest-localmigrate/x10 fail in 10317 pass in 10313

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-win7-amd64  7 windows-install              fail never pass
 test-i386-i386-xl-winxpsp3    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-i386-i386-pv             1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl             1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pair           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   never pass
 test-i386-i386-win            1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-win         1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf-pin 14 guest-localmigrate/x10 fail in 10317 blocked in 10201

version targeted for testing:
 xen                  a4d7c27ec1f1
baseline version:
 xen                  62ff6a318c5d

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Anthony PERARD <anthony.perard@citrix.com>
  Brendan Cully <brendan@cs.ubc.ca>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@novell.com>
  Jan Beulich <jbeulich@suse.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Jonathan Davies <jonathan.davies@citrix.com>
  juergen.gross@ts.fujitsu.com
  Keir Fraser <keir@xen.org>
  Liu, Jinsong <jinsong.liu@intel.com>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
  Philipp Hahn <hahn@univention.de>
  Shriram Rajagopalan <rshriram@cs.ubc.ca>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang2 <wei.wang2@amd.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   fail    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           fail    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           fail    
 test-i386-i386-xl                                            blocked 
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-i386-i386-pair                                          blocked 
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           fail    
 test-i386-i386-pv                                            blocked 
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           blocked 
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        blocked 
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   blocked 


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 1262 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Dec 04 21:49:18 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 04 Dec 2011 21:49:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXJvH-0007Ar-5v; Sun, 04 Dec 2011 21:48:35 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RXJvG-0007Ah-9V
	for xen-devel@lists.xensource.com; Sun, 04 Dec 2011 21:48:34 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1323035270!4928635!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjAxOQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8861 invoked from network); 4 Dec 2011 21:47:50 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Dec 2011 21:47:50 -0000
X-IronPort-AV: E=Sophos;i="4.71,295,1320624000"; 
   d="scan'208";a="9275236"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Dec 2011 21:47:47 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sun, 4 Dec 2011 21:47:46 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RXJuU-0004h3-O3;
	Sun, 04 Dec 2011 21:47:46 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RXJuU-0005D7-Nc;
	Sun, 04 Dec 2011 21:47:46 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <E1RXJuU-0005D7-Nc@woking.xci-test.com>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 4 Dec 2011 21:47:46 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com, keir@xen.org, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [xen-unstable bisection] complete test-amd64-amd64-win
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

branch xen-unstable
xen branch xen-unstable
job test-amd64-amd64-win
test guest-saverestore

Tree: linux git://github.com/jsgf/linux-xen.git
Tree: qemu git://hg.uk.xensource.com/HG/qemu-xen-unstable.git
Tree: xen http://xenbits.xen.org/staging/xen-unstable.hg

*** Found and reproduced problem changeset ***

  Bug is in tree:  qemu git://hg.uk.xensource.com/HG/qemu-xen-unstable.git
  Bug introduced:  13b06e700528b1c4258ce5d768d69b0d499f75ca
  Bug not present: 89daacab7035d408f32f2cb1acf68c96d6cbefed


  commit 13b06e700528b1c4258ce5d768d69b0d499f75ca
  Author: Sefano Stabellini <stefano.stabellini@eu.citrix.com>
  Date:   Thu Dec 1 17:52:01 2011 +0000
  
      xen: don't initialize the RTC timers if xen is available
      
      Xen doesn't need full RTC emulation in Qemu because the RTC is already
      emulated by the hypervisor. Hence don't initialize the RTC timers when Xen is
      available so that Qemu doesn't need to wake up needlessly.
      
      Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>


For bisection revision-tuple graph see:
   http://www.chiark.greenend.org.uk/~xensrcts/results/bisect.xen-unstable.test-amd64-amd64-win.guest-saverestore.html
Revision IDs in each graph node refer, respectively, to the Trees above.

----------------------------------------
Searching for failure / basis pass:
 10325 fail [host=gall-mite] / 10202 [host=lace-bug] 10201 [host=potato-beetle] 10195 [host=moss-bug] 10192 [host=bush-cricket] 10191 [host=leaf-beetle] 10190 [host=lace-bug] 10189 [host=itch-mite] 10185 [host=bush-cricket] 10183 [host=moss-bug] 10182 [host=leaf-beetle] 10176 [host=potato-beetle] 10168 [host=potato-beetle] 10157 [host=moss-bug] 10145 [host=itch-mite] 10138 [host=field-cricket] 10135 [host=bush-cricket] 10132 [host=potato-beetle] 10129 [host=lace-bug] 10117 [host=itch-mite] 10112 [host=moss-bug] 10105 [host=leaf-beetle] 10098 [host=field-cricket] 10092 [host=lace-bug] 10062 [host=field-cricket] 10056 [host=leaf-beetle] 10051 [host=potato-beetle] 10045 [host=moss-bug] 10032 ok.
Failure / basis pass flights: 10325 / 10032
Tree: linux git://github.com/jsgf/linux-xen.git
Tree: qemu git://hg.uk.xensource.com/HG/qemu-xen-unstable.git
Tree: xen http://xenbits.xen.org/staging/xen-unstable.hg
Latest 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 65b27b1dd6f205835aa8174031eea057c75f8afb a4d7c27ec1f1
Basis pass 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 9b33a3e5603ecd3ceca482a72c6ff8e951afb6d2 1027e7d13d02
Generating revisions with ./adhoc-revtuple-generator  git://github.com/jsgf/linux-xen.git#6bec8b4a4c14095d0b7ce424db9d583c3decae6c-6bec8b4a4c14095d0b7ce424db9d583c3decae6c git://hg.uk.xensource.com/HG/qemu-xen-unstable.git#9b33a3e5603ecd3ceca482a72c6ff8e951afb6d2-65b27b1dd6f205835aa8174031eea057c75f8afb http://xenbits.xen.org/staging/xen-unstable.hg#1027e7d13d02-a4d7c27ec1f1
using cache /export/home/osstest/repos/git-cache...
using cache /export/home/osstest/repos/git-cache...
locked cache /export/home/osstest/repos/git-cache...
processing ./cacheing-git clone --bare git://hg.uk.xensource.com/HG/qemu-xen-unstable.git /export/home/osstest/repos/qemu-xen-unstable...
Initialized empty Git repository in /export/home/osstest/repos/qemu-xen-unstable/
updating cache /export/home/osstest/repos/git-cache qemu-xen-unstable...
pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
searching for changes
no changes found
using cache /export/home/osstest/repos/git-cache...
using cache /export/home/osstest/repos/git-cache...
locked cache /export/home/osstest/repos/git-cache...
processing ./cacheing-git clone --bare git://hg.uk.xensource.com/HG/qemu-xen-unstable.git /export/home/osstest/repos/qemu-xen-unstable...
Initialized empty Git repository in /export/home/osstest/repos/qemu-xen-unstable/
updating cache /export/home/osstest/repos/git-cache qemu-xen-unstable...
pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
searching for changes
no changes found
Loaded 1017 nodes in revision graph
Searching for test results:
 9959 []
 9978 []
 9962 []
 10022 [host=leaf-beetle]
 10013 []
 10016 []
 10008 []
 10017 []
 10018 []
 10019 []
 10020 []
 10023 [host=itch-mite]
 10032 pass 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 9b33a3e5603ecd3ceca482a72c6ff8e951afb6d2 1027e7d13d02
 10045 [host=moss-bug]
 10051 [host=potato-beetle]
 10056 [host=leaf-beetle]
 10098 [host=field-cricket]
 10062 [host=field-cricket]
 10069 []
 10092 [host=lace-bug]
 10105 [host=leaf-beetle]
 10117 [host=itch-mite]
 10135 [host=bush-cricket]
 10112 [host=moss-bug]
 10129 [host=lace-bug]
 10132 [host=potato-beetle]
 10145 [host=itch-mite]
 10138 [host=field-cricket]
 10157 [host=moss-bug]
 10231 [host=bush-cricket]
 10244 []
 10168 [host=potato-beetle]
 10195 [host=moss-bug]
 10263 fail 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 65b27b1dd6f205835aa8174031eea057c75f8afb 491c3ebf1d37
 10201 [host=potato-beetle]
 10202 [host=lace-bug]
 10176 [host=potato-beetle]
 10182 [host=leaf-beetle]
 10183 [host=moss-bug]
 10185 [host=bush-cricket]
 10189 [host=itch-mite]
 10190 [host=lace-bug]
 10191 [host=leaf-beetle]
 10192 [host=bush-cricket]
 10214 []
 10257 fail 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 65b27b1dd6f205835aa8174031eea057c75f8afb 491c3ebf1d37
 10239 [host=potato-beetle]
 10246 [host=field-cricket]
 10262 pass 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 9b33a3e5603ecd3ceca482a72c6ff8e951afb6d2 1027e7d13d02
 10264 [host=itch-mite]
 10265 fail 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 9fa2794d45ba915b42b77d4762dfa607d5587dfc b776fcd4a15c
 10275 [host=itch-mite]
 10276 [host=itch-mite]
 10284 [host=itch-mite]
 10285 [host=itch-mite]
 10286 [host=itch-mite]
 10312 fail 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 13b06e700528b1c4258ce5d768d69b0d499f75ca ad5941e51c87
 10287 [host=itch-mite]
 10288 [host=itch-mite]
 10314 pass 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 89daacab7035d408f32f2cb1acf68c96d6cbefed ad5941e51c87
 10290 [host=itch-mite]
 10313 [host=field-cricket]
 10315 fail 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 13b06e700528b1c4258ce5d768d69b0d499f75ca ad5941e51c87
 10291 [host=itch-mite]
 10289 fail 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 65b27b1dd6f205835aa8174031eea057c75f8afb a4d7c27ec1f1
 10292 [host=itch-mite]
 10293 pass 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 9b33a3e5603ecd3ceca482a72c6ff8e951afb6d2 1027e7d13d02
 10316 [host=field-cricket]
 10295 fail 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 65b27b1dd6f205835aa8174031eea057c75f8afb a4d7c27ec1f1
 10294 [host=lace-bug]
 10296 pass 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 89daacab7035d408f32f2cb1acf68c96d6cbefed 3e5683b6b37f
 10318 [host=field-cricket]
 10297 [host=lace-bug]
 10319 [host=field-cricket]
 10298 [host=potato-beetle]
 10299 [host=lace-bug]
 10320 [host=field-cricket]
 10301 [host=potato-beetle]
 10300 fail 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 65b27b1dd6f205835aa8174031eea057c75f8afb a4d7c27ec1f1
 10302 [host=potato-beetle]
 10317 fail 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 65b27b1dd6f205835aa8174031eea057c75f8afb a4d7c27ec1f1
 10303 pass 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 89daacab7035d408f32f2cb1acf68c96d6cbefed d1b9700fa239
 10321 [host=field-cricket]
 10304 pass 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 89daacab7035d408f32f2cb1acf68c96d6cbefed 295337e5d4e0
 10305 fail 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 65b27b1dd6f205835aa8174031eea057c75f8afb a4d7c27ec1f1
 10306 pass 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 89daacab7035d408f32f2cb1acf68c96d6cbefed acfd86abd08b
 10323 pass 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 89daacab7035d408f32f2cb1acf68c96d6cbefed ad5941e51c87
 10307 pass 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 89daacab7035d408f32f2cb1acf68c96d6cbefed b6962c4b0dfd
 10308 pass 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 89daacab7035d408f32f2cb1acf68c96d6cbefed 3b409f65abae
 10322 [host=lace-bug]
 10309 fail 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 13b06e700528b1c4258ce5d768d69b0d499f75ca ad5941e51c87
 10310 pass 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 89daacab7035d408f32f2cb1acf68c96d6cbefed 6bac46816504
 10324 fail 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 13b06e700528b1c4258ce5d768d69b0d499f75ca ad5941e51c87
 10311 pass 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 89daacab7035d408f32f2cb1acf68c96d6cbefed ad5941e51c87
 10325 fail 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 65b27b1dd6f205835aa8174031eea057c75f8afb a4d7c27ec1f1
 10326 [host=lace-bug]
Searching for interesting versions
 Result found: flight 10032 (pass), for basis pass
 Result found: flight 10289 (fail), for basis failure
 Repro found: flight 10293 (pass), for basis pass
 Repro found: flight 10295 (fail), for basis failure
 0 revisions at 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 89daacab7035d408f32f2cb1acf68c96d6cbefed ad5941e51c87
No revisions left to test, checking graph state.
 Result found: flight 10311 (pass), for last pass
 Result found: flight 10312 (fail), for first failure
 Repro found: flight 10314 (pass), for last pass
 Repro found: flight 10315 (fail), for first failure
 Repro found: flight 10323 (pass), for last pass
 Repro found: flight 10324 (fail), for first failure

*** Found and reproduced problem changeset ***

  Bug is in tree:  qemu git://hg.uk.xensource.com/HG/qemu-xen-unstable.git
  Bug introduced:  13b06e700528b1c4258ce5d768d69b0d499f75ca
  Bug not present: 89daacab7035d408f32f2cb1acf68c96d6cbefed

using cache /export/home/osstest/repos/git-cache...
using cache /export/home/osstest/repos/git-cache...
locked cache /export/home/osstest/repos/git-cache...
processing ./cacheing-git clone --bare git://hg.uk.xensource.com/HG/qemu-xen-unstable.git /export/home/osstest/repos/qemu-xen-unstable...
Initialized empty Git repository in /export/home/osstest/repos/qemu-xen-unstable/
updating cache /export/home/osstest/repos/git-cache qemu-xen-unstable...

  commit 13b06e700528b1c4258ce5d768d69b0d499f75ca
  Author: Sefano Stabellini <stefano.stabellini@eu.citrix.com>
  Date:   Thu Dec 1 17:52:01 2011 +0000
  
      xen: don't initialize the RTC timers if xen is available
      
      Xen doesn't need full RTC emulation in Qemu because the RTC is already
      emulated by the hypervisor. Hence don't initialize the RTC timers when Xen is
      available so that Qemu doesn't need to wake up needlessly.
      
      Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Revision graph left in /home/xc_osstest/results/bisect.xen-unstable.test-amd64-amd64-win.guest-saverestore.{dot,ps,png,html}.
----------------------------------------
10326: ALL FAIL

flight 10326 xen-unstable real-bisect [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10326/


jobs:
 test-amd64-amd64-win                                         fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Dec 04 21:49:18 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 04 Dec 2011 21:49:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXJvH-0007Ar-5v; Sun, 04 Dec 2011 21:48:35 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RXJvG-0007Ah-9V
	for xen-devel@lists.xensource.com; Sun, 04 Dec 2011 21:48:34 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1323035270!4928635!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjAxOQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8861 invoked from network); 4 Dec 2011 21:47:50 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Dec 2011 21:47:50 -0000
X-IronPort-AV: E=Sophos;i="4.71,295,1320624000"; 
   d="scan'208";a="9275236"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Dec 2011 21:47:47 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sun, 4 Dec 2011 21:47:46 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RXJuU-0004h3-O3;
	Sun, 04 Dec 2011 21:47:46 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RXJuU-0005D7-Nc;
	Sun, 04 Dec 2011 21:47:46 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <E1RXJuU-0005D7-Nc@woking.xci-test.com>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 4 Dec 2011 21:47:46 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com, keir@xen.org, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [xen-unstable bisection] complete test-amd64-amd64-win
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

branch xen-unstable
xen branch xen-unstable
job test-amd64-amd64-win
test guest-saverestore

Tree: linux git://github.com/jsgf/linux-xen.git
Tree: qemu git://hg.uk.xensource.com/HG/qemu-xen-unstable.git
Tree: xen http://xenbits.xen.org/staging/xen-unstable.hg

*** Found and reproduced problem changeset ***

  Bug is in tree:  qemu git://hg.uk.xensource.com/HG/qemu-xen-unstable.git
  Bug introduced:  13b06e700528b1c4258ce5d768d69b0d499f75ca
  Bug not present: 89daacab7035d408f32f2cb1acf68c96d6cbefed


  commit 13b06e700528b1c4258ce5d768d69b0d499f75ca
  Author: Sefano Stabellini <stefano.stabellini@eu.citrix.com>
  Date:   Thu Dec 1 17:52:01 2011 +0000
  
      xen: don't initialize the RTC timers if xen is available
      
      Xen doesn't need full RTC emulation in Qemu because the RTC is already
      emulated by the hypervisor. Hence don't initialize the RTC timers when Xen is
      available so that Qemu doesn't need to wake up needlessly.
      
      Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>


For bisection revision-tuple graph see:
   http://www.chiark.greenend.org.uk/~xensrcts/results/bisect.xen-unstable.test-amd64-amd64-win.guest-saverestore.html
Revision IDs in each graph node refer, respectively, to the Trees above.

----------------------------------------
Searching for failure / basis pass:
 10325 fail [host=gall-mite] / 10202 [host=lace-bug] 10201 [host=potato-beetle] 10195 [host=moss-bug] 10192 [host=bush-cricket] 10191 [host=leaf-beetle] 10190 [host=lace-bug] 10189 [host=itch-mite] 10185 [host=bush-cricket] 10183 [host=moss-bug] 10182 [host=leaf-beetle] 10176 [host=potato-beetle] 10168 [host=potato-beetle] 10157 [host=moss-bug] 10145 [host=itch-mite] 10138 [host=field-cricket] 10135 [host=bush-cricket] 10132 [host=potato-beetle] 10129 [host=lace-bug] 10117 [host=itch-mite] 10112 [host=moss-bug] 10105 [host=leaf-beetle] 10098 [host=field-cricket] 10092 [host=lace-bug] 10062 [host=field-cricket] 10056 [host=leaf-beetle] 10051 [host=potato-beetle] 10045 [host=moss-bug] 10032 ok.
Failure / basis pass flights: 10325 / 10032
Tree: linux git://github.com/jsgf/linux-xen.git
Tree: qemu git://hg.uk.xensource.com/HG/qemu-xen-unstable.git
Tree: xen http://xenbits.xen.org/staging/xen-unstable.hg
Latest 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 65b27b1dd6f205835aa8174031eea057c75f8afb a4d7c27ec1f1
Basis pass 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 9b33a3e5603ecd3ceca482a72c6ff8e951afb6d2 1027e7d13d02
Generating revisions with ./adhoc-revtuple-generator  git://github.com/jsgf/linux-xen.git#6bec8b4a4c14095d0b7ce424db9d583c3decae6c-6bec8b4a4c14095d0b7ce424db9d583c3decae6c git://hg.uk.xensource.com/HG/qemu-xen-unstable.git#9b33a3e5603ecd3ceca482a72c6ff8e951afb6d2-65b27b1dd6f205835aa8174031eea057c75f8afb http://xenbits.xen.org/staging/xen-unstable.hg#1027e7d13d02-a4d7c27ec1f1
using cache /export/home/osstest/repos/git-cache...
using cache /export/home/osstest/repos/git-cache...
locked cache /export/home/osstest/repos/git-cache...
processing ./cacheing-git clone --bare git://hg.uk.xensource.com/HG/qemu-xen-unstable.git /export/home/osstest/repos/qemu-xen-unstable...
Initialized empty Git repository in /export/home/osstest/repos/qemu-xen-unstable/
updating cache /export/home/osstest/repos/git-cache qemu-xen-unstable...
pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
searching for changes
no changes found
using cache /export/home/osstest/repos/git-cache...
using cache /export/home/osstest/repos/git-cache...
locked cache /export/home/osstest/repos/git-cache...
processing ./cacheing-git clone --bare git://hg.uk.xensource.com/HG/qemu-xen-unstable.git /export/home/osstest/repos/qemu-xen-unstable...
Initialized empty Git repository in /export/home/osstest/repos/qemu-xen-unstable/
updating cache /export/home/osstest/repos/git-cache qemu-xen-unstable...
pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
searching for changes
no changes found
Loaded 1017 nodes in revision graph
Searching for test results:
 9959 []
 9978 []
 9962 []
 10022 [host=leaf-beetle]
 10013 []
 10016 []
 10008 []
 10017 []
 10018 []
 10019 []
 10020 []
 10023 [host=itch-mite]
 10032 pass 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 9b33a3e5603ecd3ceca482a72c6ff8e951afb6d2 1027e7d13d02
 10045 [host=moss-bug]
 10051 [host=potato-beetle]
 10056 [host=leaf-beetle]
 10098 [host=field-cricket]
 10062 [host=field-cricket]
 10069 []
 10092 [host=lace-bug]
 10105 [host=leaf-beetle]
 10117 [host=itch-mite]
 10135 [host=bush-cricket]
 10112 [host=moss-bug]
 10129 [host=lace-bug]
 10132 [host=potato-beetle]
 10145 [host=itch-mite]
 10138 [host=field-cricket]
 10157 [host=moss-bug]
 10231 [host=bush-cricket]
 10244 []
 10168 [host=potato-beetle]
 10195 [host=moss-bug]
 10263 fail 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 65b27b1dd6f205835aa8174031eea057c75f8afb 491c3ebf1d37
 10201 [host=potato-beetle]
 10202 [host=lace-bug]
 10176 [host=potato-beetle]
 10182 [host=leaf-beetle]
 10183 [host=moss-bug]
 10185 [host=bush-cricket]
 10189 [host=itch-mite]
 10190 [host=lace-bug]
 10191 [host=leaf-beetle]
 10192 [host=bush-cricket]
 10214 []
 10257 fail 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 65b27b1dd6f205835aa8174031eea057c75f8afb 491c3ebf1d37
 10239 [host=potato-beetle]
 10246 [host=field-cricket]
 10262 pass 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 9b33a3e5603ecd3ceca482a72c6ff8e951afb6d2 1027e7d13d02
 10264 [host=itch-mite]
 10265 fail 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 9fa2794d45ba915b42b77d4762dfa607d5587dfc b776fcd4a15c
 10275 [host=itch-mite]
 10276 [host=itch-mite]
 10284 [host=itch-mite]
 10285 [host=itch-mite]
 10286 [host=itch-mite]
 10312 fail 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 13b06e700528b1c4258ce5d768d69b0d499f75ca ad5941e51c87
 10287 [host=itch-mite]
 10288 [host=itch-mite]
 10314 pass 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 89daacab7035d408f32f2cb1acf68c96d6cbefed ad5941e51c87
 10290 [host=itch-mite]
 10313 [host=field-cricket]
 10315 fail 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 13b06e700528b1c4258ce5d768d69b0d499f75ca ad5941e51c87
 10291 [host=itch-mite]
 10289 fail 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 65b27b1dd6f205835aa8174031eea057c75f8afb a4d7c27ec1f1
 10292 [host=itch-mite]
 10293 pass 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 9b33a3e5603ecd3ceca482a72c6ff8e951afb6d2 1027e7d13d02
 10316 [host=field-cricket]
 10295 fail 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 65b27b1dd6f205835aa8174031eea057c75f8afb a4d7c27ec1f1
 10294 [host=lace-bug]
 10296 pass 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 89daacab7035d408f32f2cb1acf68c96d6cbefed 3e5683b6b37f
 10318 [host=field-cricket]
 10297 [host=lace-bug]
 10319 [host=field-cricket]
 10298 [host=potato-beetle]
 10299 [host=lace-bug]
 10320 [host=field-cricket]
 10301 [host=potato-beetle]
 10300 fail 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 65b27b1dd6f205835aa8174031eea057c75f8afb a4d7c27ec1f1
 10302 [host=potato-beetle]
 10317 fail 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 65b27b1dd6f205835aa8174031eea057c75f8afb a4d7c27ec1f1
 10303 pass 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 89daacab7035d408f32f2cb1acf68c96d6cbefed d1b9700fa239
 10321 [host=field-cricket]
 10304 pass 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 89daacab7035d408f32f2cb1acf68c96d6cbefed 295337e5d4e0
 10305 fail 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 65b27b1dd6f205835aa8174031eea057c75f8afb a4d7c27ec1f1
 10306 pass 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 89daacab7035d408f32f2cb1acf68c96d6cbefed acfd86abd08b
 10323 pass 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 89daacab7035d408f32f2cb1acf68c96d6cbefed ad5941e51c87
 10307 pass 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 89daacab7035d408f32f2cb1acf68c96d6cbefed b6962c4b0dfd
 10308 pass 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 89daacab7035d408f32f2cb1acf68c96d6cbefed 3b409f65abae
 10322 [host=lace-bug]
 10309 fail 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 13b06e700528b1c4258ce5d768d69b0d499f75ca ad5941e51c87
 10310 pass 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 89daacab7035d408f32f2cb1acf68c96d6cbefed 6bac46816504
 10324 fail 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 13b06e700528b1c4258ce5d768d69b0d499f75ca ad5941e51c87
 10311 pass 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 89daacab7035d408f32f2cb1acf68c96d6cbefed ad5941e51c87
 10325 fail 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 65b27b1dd6f205835aa8174031eea057c75f8afb a4d7c27ec1f1
 10326 [host=lace-bug]
Searching for interesting versions
 Result found: flight 10032 (pass), for basis pass
 Result found: flight 10289 (fail), for basis failure
 Repro found: flight 10293 (pass), for basis pass
 Repro found: flight 10295 (fail), for basis failure
 0 revisions at 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 89daacab7035d408f32f2cb1acf68c96d6cbefed ad5941e51c87
No revisions left to test, checking graph state.
 Result found: flight 10311 (pass), for last pass
 Result found: flight 10312 (fail), for first failure
 Repro found: flight 10314 (pass), for last pass
 Repro found: flight 10315 (fail), for first failure
 Repro found: flight 10323 (pass), for last pass
 Repro found: flight 10324 (fail), for first failure

*** Found and reproduced problem changeset ***

  Bug is in tree:  qemu git://hg.uk.xensource.com/HG/qemu-xen-unstable.git
  Bug introduced:  13b06e700528b1c4258ce5d768d69b0d499f75ca
  Bug not present: 89daacab7035d408f32f2cb1acf68c96d6cbefed

using cache /export/home/osstest/repos/git-cache...
using cache /export/home/osstest/repos/git-cache...
locked cache /export/home/osstest/repos/git-cache...
processing ./cacheing-git clone --bare git://hg.uk.xensource.com/HG/qemu-xen-unstable.git /export/home/osstest/repos/qemu-xen-unstable...
Initialized empty Git repository in /export/home/osstest/repos/qemu-xen-unstable/
updating cache /export/home/osstest/repos/git-cache qemu-xen-unstable...

  commit 13b06e700528b1c4258ce5d768d69b0d499f75ca
  Author: Sefano Stabellini <stefano.stabellini@eu.citrix.com>
  Date:   Thu Dec 1 17:52:01 2011 +0000
  
      xen: don't initialize the RTC timers if xen is available
      
      Xen doesn't need full RTC emulation in Qemu because the RTC is already
      emulated by the hypervisor. Hence don't initialize the RTC timers when Xen is
      available so that Qemu doesn't need to wake up needlessly.
      
      Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Revision graph left in /home/xc_osstest/results/bisect.xen-unstable.test-amd64-amd64-win.guest-saverestore.{dot,ps,png,html}.
----------------------------------------
10326: ALL FAIL

flight 10326 xen-unstable real-bisect [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10326/


jobs:
 test-amd64-amd64-win                                         fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 04:14:27 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 04:14:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXPul-0004ve-Um; Mon, 05 Dec 2011 04:12:27 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RXPuj-0004vZ-L9
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 04:12:25 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1323058262!48505633!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjAyMA==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6394 invoked from network); 5 Dec 2011 04:11:02 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Dec 2011 04:11:02 -0000
X-IronPort-AV: E=Sophos;i="4.71,297,1320624000"; 
   d="scan'208";a="9279862"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Dec 2011 04:11:42 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 5 Dec 2011 04:11:42 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RXPu2-0007EI-C2;
	Mon, 05 Dec 2011 04:11:42 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RXPu2-00059w-B0;
	Mon, 05 Dec 2011 04:11:42 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10332-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 5 Dec 2011 04:11:42 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10332: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10332 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10332/

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-i386-xl-winxpsp3-vcpus1  4 xen-install         fail REGR. vs. 10201
 test-amd64-i386-xl-win7-amd64  4 xen-install              fail REGR. vs. 10201
 test-amd64-i386-xend-winxpsp3  4 xen-install              fail REGR. vs. 10201
 test-amd64-i386-pv            4 xen-install               fail REGR. vs. 10201
 test-amd64-i386-xl-credit2    4 xen-install               fail REGR. vs. 10201
 test-amd64-i386-xl-multivcpu  4 xen-install               fail REGR. vs. 10201
 test-amd64-i386-xl            4 xen-install               fail REGR. vs. 10201
 test-amd64-i386-pair          6 xen-install/dst_host      fail REGR. vs. 10201
 test-amd64-i386-pair          5 xen-install/src_host      fail REGR. vs. 10201
 build-i386                    4 xen-build                 fail REGR. vs. 10201
 build-i386-oldkern            4 xen-build                 fail REGR. vs. 10201
 test-amd64-i386-rhel6hvm-intel  4 xen-install             fail REGR. vs. 10201
 test-amd64-i386-rhel6hvm-amd  4 xen-install               fail REGR. vs. 10201
 test-amd64-i386-win-vcpus1    4 xen-install               fail REGR. vs. 10201
 test-amd64-amd64-win          8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-amd64-xl-win       8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-i386-win           4 xen-install               fail REGR. vs. 10201
 test-amd64-i386-xl-win-vcpus1  4 xen-install              fail REGR. vs. 10201

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf     13 guest-localmigrate.2        fail pass in 10317
 test-amd64-amd64-xl-sedf 14 guest-localmigrate/x10 fail in 10317 pass in 10313

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-win7-amd64  7 windows-install              fail never pass
 test-i386-i386-xl-winxpsp3    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-i386-i386-pv             1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl             1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pair           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   never pass
 test-i386-i386-win            1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-win         1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf-pin 14 guest-localmigrate/x10 fail in 10317 blocked in 10201

version targeted for testing:
 xen                  a4d7c27ec1f1
baseline version:
 xen                  62ff6a318c5d

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Anthony PERARD <anthony.perard@citrix.com>
  Brendan Cully <brendan@cs.ubc.ca>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@novell.com>
  Jan Beulich <jbeulich@suse.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Jonathan Davies <jonathan.davies@citrix.com>
  juergen.gross@ts.fujitsu.com
  Keir Fraser <keir@xen.org>
  Liu, Jinsong <jinsong.liu@intel.com>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
  Philipp Hahn <hahn@univention.de>
  Shriram Rajagopalan <rshriram@cs.ubc.ca>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang2 <wei.wang2@amd.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   fail    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           fail    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           fail    
 test-i386-i386-xl                                            blocked 
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-i386-i386-pair                                          blocked 
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           fail    
 test-i386-i386-pv                                            blocked 
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           blocked 
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        blocked 
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   blocked 


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 1262 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 04:14:27 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 04:14:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXPul-0004ve-Um; Mon, 05 Dec 2011 04:12:27 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RXPuj-0004vZ-L9
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 04:12:25 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1323058262!48505633!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjAyMA==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6394 invoked from network); 5 Dec 2011 04:11:02 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Dec 2011 04:11:02 -0000
X-IronPort-AV: E=Sophos;i="4.71,297,1320624000"; 
   d="scan'208";a="9279862"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Dec 2011 04:11:42 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 5 Dec 2011 04:11:42 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RXPu2-0007EI-C2;
	Mon, 05 Dec 2011 04:11:42 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RXPu2-00059w-B0;
	Mon, 05 Dec 2011 04:11:42 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10332-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 5 Dec 2011 04:11:42 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10332: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10332 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10332/

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-i386-xl-winxpsp3-vcpus1  4 xen-install         fail REGR. vs. 10201
 test-amd64-i386-xl-win7-amd64  4 xen-install              fail REGR. vs. 10201
 test-amd64-i386-xend-winxpsp3  4 xen-install              fail REGR. vs. 10201
 test-amd64-i386-pv            4 xen-install               fail REGR. vs. 10201
 test-amd64-i386-xl-credit2    4 xen-install               fail REGR. vs. 10201
 test-amd64-i386-xl-multivcpu  4 xen-install               fail REGR. vs. 10201
 test-amd64-i386-xl            4 xen-install               fail REGR. vs. 10201
 test-amd64-i386-pair          6 xen-install/dst_host      fail REGR. vs. 10201
 test-amd64-i386-pair          5 xen-install/src_host      fail REGR. vs. 10201
 build-i386                    4 xen-build                 fail REGR. vs. 10201
 build-i386-oldkern            4 xen-build                 fail REGR. vs. 10201
 test-amd64-i386-rhel6hvm-intel  4 xen-install             fail REGR. vs. 10201
 test-amd64-i386-rhel6hvm-amd  4 xen-install               fail REGR. vs. 10201
 test-amd64-i386-win-vcpus1    4 xen-install               fail REGR. vs. 10201
 test-amd64-amd64-win          8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-amd64-xl-win       8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-i386-win           4 xen-install               fail REGR. vs. 10201
 test-amd64-i386-xl-win-vcpus1  4 xen-install              fail REGR. vs. 10201

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf     13 guest-localmigrate.2        fail pass in 10317
 test-amd64-amd64-xl-sedf 14 guest-localmigrate/x10 fail in 10317 pass in 10313

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-win7-amd64  7 windows-install              fail never pass
 test-i386-i386-xl-winxpsp3    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-i386-i386-pv             1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl             1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pair           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   never pass
 test-i386-i386-win            1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-win         1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf-pin 14 guest-localmigrate/x10 fail in 10317 blocked in 10201

version targeted for testing:
 xen                  a4d7c27ec1f1
baseline version:
 xen                  62ff6a318c5d

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Anthony PERARD <anthony.perard@citrix.com>
  Brendan Cully <brendan@cs.ubc.ca>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@novell.com>
  Jan Beulich <jbeulich@suse.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Jonathan Davies <jonathan.davies@citrix.com>
  juergen.gross@ts.fujitsu.com
  Keir Fraser <keir@xen.org>
  Liu, Jinsong <jinsong.liu@intel.com>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
  Philipp Hahn <hahn@univention.de>
  Shriram Rajagopalan <rshriram@cs.ubc.ca>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang2 <wei.wang2@amd.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   fail    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           fail    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           fail    
 test-i386-i386-xl                                            blocked 
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-i386-i386-pair                                          blocked 
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           fail    
 test-i386-i386-pv                                            blocked 
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           blocked 
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        blocked 
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   blocked 


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 1262 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 06:26:02 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 06: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.xensource.com>)
	id 1RXRyy-0005YB-2g; Mon, 05 Dec 2011 06:24:56 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <xiantao.zhang@intel.com>) id 1RXRyw-0005Y6-PQ
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 06:24:55 +0000
X-Env-Sender: xiantao.zhang@intel.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1323066248!4225322!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMjkyODM5\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31943 invoked from network); 5 Dec 2011 06:24:09 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-8.tower-174.messagelabs.com with SMTP;
	5 Dec 2011 06:24:09 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga101.jf.intel.com with ESMTP; 04 Dec 2011 22:24:07 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.67,352,1309762800"; d="scan'208,217";a="82879019"
Received: from pgsmsx602.gar.corp.intel.com ([10.221.43.81])
	by orsmga001.jf.intel.com with ESMTP; 04 Dec 2011 22:24:07 -0800
Received: from shsmsx602.ccr.corp.intel.com (10.239.4.104) by
	pgsmsx602.gar.corp.intel.com (10.221.43.81) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Mon, 5 Dec 2011 14:23:41 +0800
Received: from shsmsx502.ccr.corp.intel.com ([10.239.4.96]) by
	SHSMSX602.ccr.corp.intel.com ([10.239.4.104]) with mapi; Mon, 5 Dec 2011
	14:23:39 +0800
From: "Zhang, Xiantao" <xiantao.zhang@intel.com>
To: Srujan Kotikela <ksrujandas@gmail.com>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>
Date: Mon, 5 Dec 2011 14:23:39 +0800
Thread-Topic: [Xen-devel] Ring3 Hypercalls from HVM DomU
Thread-Index: AcyxNKg+2YaY530pR1eSr4u6DbdbEQB4Losg
Message-ID: <BC00F5384FCFC9499AF06F92E8B78A9E2870CA7799@shsmsx502.ccr.corp.intel.com>
References: <CAKLFbfwYyKM=feBXQdj00XAvy+YWdBddLBWCv0CVROwA3bTGJg@mail.gmail.com>
In-Reply-To: <CAKLFbfwYyKM=feBXQdj00XAvy+YWdBddLBWCv0CVROwA3bTGJg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Subject: Re: [Xen-devel] Ring3 Hypercalls from HVM DomU
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6983207029249808043=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============6983207029249808043==
Content-Language: en-US
Content-Type: multipart/alternative;
	boundary="_000_BC00F5384FCFC9499AF06F92E8B78A9E2870CA7799shsmsx502ccrc_"

--_000_BC00F5384FCFC9499AF06F92E8B78A9E2870CA7799shsmsx502ccrc_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

That is because "int $0x92" only switch the context to guest's IDT instead =
of hypervisor's IDT by default.
Xiantao

From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-bounces@lists=
.xensource.com] On Behalf Of Srujan Kotikela
Sent: Saturday, December 03, 2011 4:52 AM
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] Ring3 Hypercalls from HVM DomU

Hi,

I have created hypercalls that can be invoked from ring-3 by setting the ri=
ng-3 gate in xen. This works fine when I invoke the hypercall from Dom0. I =
want to invoke the same from a HVM DomU. But I keep getting the segmentatio=
n fault when I invoke the ring3_hyperacall from HVM DomU. Any ideas?

The setting up gate is as follows:
_set_gate(idt_table+0x92, 14, 3, &hypercall);

The hypercall invoking code looks like this:
int ring3_hypercall(unsigned long va, int command)
{
    int ret;

    asm("int $0x92" : "=3Da"(ret) : "a"(40), "b"(va), "c"(command));

    return ret;
}

~ SDK

--_000_BC00F5384FCFC9499AF06F92E8B78A9E2870CA7799shsmsx502ccrc_
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=3DContent-Type content=
=3D"text/html; charset=3Dus-ascii"><meta name=3DGenerator content=3D"Micros=
oft Word 14 (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:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
@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:"\@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:12.0pt;
	font-family:"Times New Roman","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-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.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=3DEN-US link=3Dblue vli=
nk=3Dpurple><div class=3DWordSection1><p class=3DMsoNormal><span style=3D'f=
ont-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>That is b=
ecause &#8220;int $0x92&#8221; only switch the context to guest&#8217;s IDT=
 instead of hypervisor&#8217;s IDT by default.<o:p></o:p></span></p><p clas=
s=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri","sans-s=
erif";color:#1F497D'>Xiantao<o:p></o:p></span></p><p class=3DMsoNormal><spa=
n style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497=
D'><o:p>&nbsp;</o:p></span></p><p class=3DMsoNormal><b><span style=3D'font-=
size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span style=
=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'> xen-devel-bounces@=
lists.xensource.com [mailto:xen-devel-bounces@lists.xensource.com] <b>On Be=
half Of </b>Srujan Kotikela<br><b>Sent:</b> Saturday, December 03, 2011 4:5=
2 AM<br><b>To:</b> xen-devel@lists.xensource.com<br><b>Subject:</b> [Xen-de=
vel] Ring3 Hypercalls from HVM DomU<o:p></o:p></span></p><p class=3DMsoNorm=
al><o:p>&nbsp;</o:p></p><p class=3DMsoNormal>Hi,<o:p></o:p></p><div><p clas=
s=3DMsoNormal><o:p>&nbsp;</o:p></p></div><div><p class=3DMsoNormal>I have c=
reated hypercalls that can be invoked from ring-3 by setting the ring-3 gat=
e in xen. This works fine when I invoke the hypercall from Dom0. I want to =
invoke the same from a HVM DomU. But I keep getting the segmentation fault =
when I invoke the ring3_hyperacall from HVM DomU. Any ideas?<br><br><b>The =
setting up gate is as follows:</b><br>_set_gate(idt_table+0x92, 14, 3, &amp=
;hypercall);<o:p></o:p></p></div><div><p class=3DMsoNormal style=3D'margin-=
bottom:12.0pt'><b><br>The hypercall invoking code looks like this:</b><br>i=
nt ring3_hypercall(unsigned long va, int command)<br>{<br>&nbsp;&nbsp;&nbsp=
; int ret;<br><br>&nbsp;&nbsp;&nbsp; asm(&quot;int $0x92&quot; : &quot;=3Da=
&quot;(ret) : &quot;a&quot;(40), &quot;b&quot;(va), &quot;c&quot;(command))=
;<br>&nbsp;&nbsp;&nbsp; <br>&nbsp;&nbsp;&nbsp; return ret;<br>}<br><br clea=
r=3Dall>~ SDK<o:p></o:p></p></div></div></body></html>=

--_000_BC00F5384FCFC9499AF06F92E8B78A9E2870CA7799shsmsx502ccrc_--


--===============6983207029249808043==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============6983207029249808043==--


From xen-devel-bounces@lists.xensource.com Mon Dec 05 06:26:02 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 06: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.xensource.com>)
	id 1RXRyy-0005YB-2g; Mon, 05 Dec 2011 06:24:56 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <xiantao.zhang@intel.com>) id 1RXRyw-0005Y6-PQ
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 06:24:55 +0000
X-Env-Sender: xiantao.zhang@intel.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1323066248!4225322!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMjkyODM5\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31943 invoked from network); 5 Dec 2011 06:24:09 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-8.tower-174.messagelabs.com with SMTP;
	5 Dec 2011 06:24:09 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga101.jf.intel.com with ESMTP; 04 Dec 2011 22:24:07 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.67,352,1309762800"; d="scan'208,217";a="82879019"
Received: from pgsmsx602.gar.corp.intel.com ([10.221.43.81])
	by orsmga001.jf.intel.com with ESMTP; 04 Dec 2011 22:24:07 -0800
Received: from shsmsx602.ccr.corp.intel.com (10.239.4.104) by
	pgsmsx602.gar.corp.intel.com (10.221.43.81) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Mon, 5 Dec 2011 14:23:41 +0800
Received: from shsmsx502.ccr.corp.intel.com ([10.239.4.96]) by
	SHSMSX602.ccr.corp.intel.com ([10.239.4.104]) with mapi; Mon, 5 Dec 2011
	14:23:39 +0800
From: "Zhang, Xiantao" <xiantao.zhang@intel.com>
To: Srujan Kotikela <ksrujandas@gmail.com>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>
Date: Mon, 5 Dec 2011 14:23:39 +0800
Thread-Topic: [Xen-devel] Ring3 Hypercalls from HVM DomU
Thread-Index: AcyxNKg+2YaY530pR1eSr4u6DbdbEQB4Losg
Message-ID: <BC00F5384FCFC9499AF06F92E8B78A9E2870CA7799@shsmsx502.ccr.corp.intel.com>
References: <CAKLFbfwYyKM=feBXQdj00XAvy+YWdBddLBWCv0CVROwA3bTGJg@mail.gmail.com>
In-Reply-To: <CAKLFbfwYyKM=feBXQdj00XAvy+YWdBddLBWCv0CVROwA3bTGJg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Subject: Re: [Xen-devel] Ring3 Hypercalls from HVM DomU
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6983207029249808043=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============6983207029249808043==
Content-Language: en-US
Content-Type: multipart/alternative;
	boundary="_000_BC00F5384FCFC9499AF06F92E8B78A9E2870CA7799shsmsx502ccrc_"

--_000_BC00F5384FCFC9499AF06F92E8B78A9E2870CA7799shsmsx502ccrc_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

That is because "int $0x92" only switch the context to guest's IDT instead =
of hypervisor's IDT by default.
Xiantao

From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-bounces@lists=
.xensource.com] On Behalf Of Srujan Kotikela
Sent: Saturday, December 03, 2011 4:52 AM
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] Ring3 Hypercalls from HVM DomU

Hi,

I have created hypercalls that can be invoked from ring-3 by setting the ri=
ng-3 gate in xen. This works fine when I invoke the hypercall from Dom0. I =
want to invoke the same from a HVM DomU. But I keep getting the segmentatio=
n fault when I invoke the ring3_hyperacall from HVM DomU. Any ideas?

The setting up gate is as follows:
_set_gate(idt_table+0x92, 14, 3, &hypercall);

The hypercall invoking code looks like this:
int ring3_hypercall(unsigned long va, int command)
{
    int ret;

    asm("int $0x92" : "=3Da"(ret) : "a"(40), "b"(va), "c"(command));

    return ret;
}

~ SDK

--_000_BC00F5384FCFC9499AF06F92E8B78A9E2870CA7799shsmsx502ccrc_
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=3DContent-Type content=
=3D"text/html; charset=3Dus-ascii"><meta name=3DGenerator content=3D"Micros=
oft Word 14 (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:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
@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:"\@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:12.0pt;
	font-family:"Times New Roman","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-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.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=3DEN-US link=3Dblue vli=
nk=3Dpurple><div class=3DWordSection1><p class=3DMsoNormal><span style=3D'f=
ont-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>That is b=
ecause &#8220;int $0x92&#8221; only switch the context to guest&#8217;s IDT=
 instead of hypervisor&#8217;s IDT by default.<o:p></o:p></span></p><p clas=
s=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri","sans-s=
erif";color:#1F497D'>Xiantao<o:p></o:p></span></p><p class=3DMsoNormal><spa=
n style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497=
D'><o:p>&nbsp;</o:p></span></p><p class=3DMsoNormal><b><span style=3D'font-=
size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span style=
=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'> xen-devel-bounces@=
lists.xensource.com [mailto:xen-devel-bounces@lists.xensource.com] <b>On Be=
half Of </b>Srujan Kotikela<br><b>Sent:</b> Saturday, December 03, 2011 4:5=
2 AM<br><b>To:</b> xen-devel@lists.xensource.com<br><b>Subject:</b> [Xen-de=
vel] Ring3 Hypercalls from HVM DomU<o:p></o:p></span></p><p class=3DMsoNorm=
al><o:p>&nbsp;</o:p></p><p class=3DMsoNormal>Hi,<o:p></o:p></p><div><p clas=
s=3DMsoNormal><o:p>&nbsp;</o:p></p></div><div><p class=3DMsoNormal>I have c=
reated hypercalls that can be invoked from ring-3 by setting the ring-3 gat=
e in xen. This works fine when I invoke the hypercall from Dom0. I want to =
invoke the same from a HVM DomU. But I keep getting the segmentation fault =
when I invoke the ring3_hyperacall from HVM DomU. Any ideas?<br><br><b>The =
setting up gate is as follows:</b><br>_set_gate(idt_table+0x92, 14, 3, &amp=
;hypercall);<o:p></o:p></p></div><div><p class=3DMsoNormal style=3D'margin-=
bottom:12.0pt'><b><br>The hypercall invoking code looks like this:</b><br>i=
nt ring3_hypercall(unsigned long va, int command)<br>{<br>&nbsp;&nbsp;&nbsp=
; int ret;<br><br>&nbsp;&nbsp;&nbsp; asm(&quot;int $0x92&quot; : &quot;=3Da=
&quot;(ret) : &quot;a&quot;(40), &quot;b&quot;(va), &quot;c&quot;(command))=
;<br>&nbsp;&nbsp;&nbsp; <br>&nbsp;&nbsp;&nbsp; return ret;<br>}<br><br clea=
r=3Dall>~ SDK<o:p></o:p></p></div></div></body></html>=

--_000_BC00F5384FCFC9499AF06F92E8B78A9E2870CA7799shsmsx502ccrc_--


--===============6983207029249808043==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============6983207029249808043==--


From xen-devel-bounces@lists.xensource.com Mon Dec 05 09:08:13 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 09:08:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXUVq-0007TN-T7; Mon, 05 Dec 2011 09:07:02 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RXUVq-0007TI-4q
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 09:07:02 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-14.tower-27.messagelabs.com!1323075860!46980210!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11383 invoked from network); 5 Dec 2011 09:04:20 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-14.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 5 Dec 2011 09:04:20 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RXUVA-000OK6-IM; Mon, 05 Dec 2011 09:06:20 +0000
Date: Mon, 5 Dec 2011 09:06:19 +0000
From: Tim Deegan <tim@xen.org>
To: Srujan Kotikela <ksrujandas@gmail.com>
Message-ID: <20111205090619.GA93116@ocelot.phlegethon.org>
References: <CAKLFbfwYyKM=feBXQdj00XAvy+YWdBddLBWCv0CVROwA3bTGJg@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAKLFbfwYyKM=feBXQdj00XAvy+YWdBddLBWCv0CVROwA3bTGJg@mail.gmail.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Ring3 Hypercalls from HVM DomU
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 14:52 -0600 on 02 Dec (1322837525), Srujan Kotikela wrote:
> Hi,
> 
> I have created hypercalls that can be invoked from ring-3 by setting the
> ring-3 gate in xen. This works fine when I invoke the hypercall from Dom0.
> I want to invoke the same from a HVM DomU. But I keep getting the
> segmentation fault when I invoke the ring3_hyperacall from HVM DomU. Any
> ideas?
> 
> *The setting up gate is as follows:*
> _set_gate(idt_table+0x92, 14, 3, &hypercall);
> *
> The hypercall invoking code looks like this:*
> int ring3_hypercall(unsigned long va, int command)
> {
>     int ret;
> 
>     asm("int $0x92" : "=a"(ret) : "a"(40), "b"(va), "c"(command));

In a HVM guest this won't trap to the hypervisor.  You'll need to
replace it with something that causes a VMEXIT. 

The obvious candidate is VMCALL but that will just raise #UD from ring 3.  
You could try piggybacking on the CPUID intercept or something like that.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 09:08:13 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 09:08:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXUVq-0007TN-T7; Mon, 05 Dec 2011 09:07:02 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RXUVq-0007TI-4q
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 09:07:02 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-14.tower-27.messagelabs.com!1323075860!46980210!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11383 invoked from network); 5 Dec 2011 09:04:20 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-14.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 5 Dec 2011 09:04:20 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RXUVA-000OK6-IM; Mon, 05 Dec 2011 09:06:20 +0000
Date: Mon, 5 Dec 2011 09:06:19 +0000
From: Tim Deegan <tim@xen.org>
To: Srujan Kotikela <ksrujandas@gmail.com>
Message-ID: <20111205090619.GA93116@ocelot.phlegethon.org>
References: <CAKLFbfwYyKM=feBXQdj00XAvy+YWdBddLBWCv0CVROwA3bTGJg@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAKLFbfwYyKM=feBXQdj00XAvy+YWdBddLBWCv0CVROwA3bTGJg@mail.gmail.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Ring3 Hypercalls from HVM DomU
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 14:52 -0600 on 02 Dec (1322837525), Srujan Kotikela wrote:
> Hi,
> 
> I have created hypercalls that can be invoked from ring-3 by setting the
> ring-3 gate in xen. This works fine when I invoke the hypercall from Dom0.
> I want to invoke the same from a HVM DomU. But I keep getting the
> segmentation fault when I invoke the ring3_hyperacall from HVM DomU. Any
> ideas?
> 
> *The setting up gate is as follows:*
> _set_gate(idt_table+0x92, 14, 3, &hypercall);
> *
> The hypercall invoking code looks like this:*
> int ring3_hypercall(unsigned long va, int command)
> {
>     int ret;
> 
>     asm("int $0x92" : "=a"(ret) : "a"(40), "b"(va), "c"(command));

In a HVM guest this won't trap to the hypervisor.  You'll need to
replace it with something that causes a VMEXIT. 

The obvious candidate is VMCALL but that will just raise #UD from ring 3.  
You could try piggybacking on the CPUID intercept or something like that.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 09:24:01 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 09:24:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXUla-0007eG-Et; Mon, 05 Dec 2011 09:23:18 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <annie.li@oracle.com>) id 1RXUlZ-0007eB-E4
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 09:23:17 +0000
X-Env-Sender: annie.li@oracle.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1323076951!6197049!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQyODAzMw==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10363 invoked from network); 5 Dec 2011 09:22:33 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-8.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Dec 2011 09:22:33 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pB59MOsh003943
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 5 Dec 2011 09:22:24 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pB59MNZ7027022
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 5 Dec 2011 09:22:23 GMT
Received: from abhmt106.oracle.com (abhmt106.oracle.com [141.146.116.58])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pB59MHwx002002; Mon, 5 Dec 2011 03:22:17 -0600
Received: from [10.182.39.81] (/10.182.39.81)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 05 Dec 2011 01:22:17 -0800
Message-ID: <4EDC8D57.6050900@oracle.com>
Date: Mon, 05 Dec 2011 17:22:31 +0800
From: ANNIE LI <annie.li@oracle.com>
Organization: Oracle Corporation
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.9.2.23) Gecko/20110920 Thunderbird/3.1.15
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <4ed6746d25537aefd2@agluck-desktop.sc.intel.com>
	<20111130183900.GA15847@phenom.dumpdata.com>
In-Reply-To: <20111130183900.GA15847@phenom.dumpdata.com>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090205.4EDC8D50.00D0,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com, "Luck, Tony" <tony.luck@intel.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH] ia64: fix build breakage because of
 conflicting u64 guest handles
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: base64
Content-Type: text/plain; charset="utf-8"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

CgpPbiAyMDExLTEyLTEgMjozOSwgS29ucmFkIFJ6ZXN6dXRlayBXaWxrIHdyb3RlOgo+IE9uIFdl
ZCwgTm92IDMwLCAyMDExIGF0IDEwOjIyOjM3QU0gLTA4MDAsIEx1Y2ssIFRvbnkgd3JvdGU6Cj4+
IGluY2x1ZGUveGVuL2ludGVyZmFjZS94ZW4uaDo1MjY6IGVycm9yOiBjb25mbGljdGluZyB0eXBl
cyBmb3Ig4oCYX19ndWVzdF9oYW5kbGVfdTY04oCZCj4+IGFyY2gvaWE2NC9pbmNsdWRlL2FzbS94
ZW4vaW50ZXJmYWNlLmg6NzQ6IGVycm9yOiBwcmV2aW91cyBkZWNsYXJhdGlvbiBvZiDigJhfX2d1
ZXN0X2hhbmRsZV91NjTigJkgd2FzIGhlcmUKPj4KPj4gUHJvYmxlbSBpbnRyb2R1Y2VkIGJ5ICJ4
ZW4vZ3JhbnR0YWJsZTogSW50cm9kdWNpbmcgZ3JhbnQgdGFibGUgVjIgc3R1Y3R1cmUiCj4+Cj4+
IHdoaWNoIGFkZGVkIGEgbmV3IGRlZmluaXRpb24gdG8gaW5jbHVkZS94ZW4vaW50ZXJmYWNlL3hl
bi5oIGZvciAidTY0Ii4KPj4KPj4gRml4OiBkZWxldGUgdGhlIGlhNjQgYXJjaCBzcGVjaWZpYyBk
ZWZpbml0aW9uLgo+Pgo+PiBTaWduZWQtb2ZmLWJ5OiBUb255IEx1Y2s8dG9ueS5sdWNrQGludGVs
LmNvbT4KPj4gLS0tCj4+Cj4+IENhbiBzb21lb25lIGVpdGhlciBmb2xkIHRoaXMgaW50byB0aGUg
YWJvdmUgcGF0Y2gsIG9yIGFkZCBpdCB0byB0aGUKPj4gc2FtZSB0cmVlIHRoYXQgaXMgZmVlZGlu
ZyBpbnRvIGxpbnV4LW5leHQgLSBJIHNhdyB0aGUgYnJlYWthZ2UgaW4KPj4gdG9kYXkncyAibmV4
dC0yMDExMTEzMCIgdGFnLiAgVGhhbmtzLgo+IEFoLCBJIGNhbiBmb2xkIGl0IGluLiBUaGFua3Mh
CkEgZGVmaW5pdGlvbiBmb3IgdWludDY0X3QgYWxyZWFkeSBleGlzdGluZyBpbiAKYXJjaC94ODYv
aW5jbHVkZS9hc20veGVuL2ludGVyZmFjZS5oLCA1OCBsaW5lOiAKREVGSU5FX0dVRVNUX0hBTkRM
RSh1aW50NjRfdCk7Ck1heWJlIGl0IGlzIGJldHRlciB0byByZW1vdmUgdGhlIGRlZmluaXRpb24g
aW4gCmluY2x1ZGUveGVuL2ludGVyZmFjZS94ZW4uaCBvZiBncmFudCB0YWJsZSB2MiBwYXRjaCwg
YW5kIG5vdCBjaGFuZ2UgY29kZSAKb2YgYXJjaC9pYTY0L2luY2x1ZGUvYXNtL3hlbi9pbnRlcmZh
Y2UuaC4KCktvbnJhZCwgZGlkIHlvdSBmb2xkIGl0IGFscmVhZHk/IG9yIEkgcmV2ZXJ0IHRoZSBk
ZWZpbml0aW9uIGluIG15IApmb2xsb3dpbmcgc3ViLXBhZ2UgYW5kIHRyYW5zaXRpdmUgcGF0Y2hl
cz8KClRoYW5rcwpBbm5pZQo+PiAgIGFyY2gvaWE2NC9pbmNsdWRlL2FzbS94ZW4vaW50ZXJmYWNl
LmggfCAgICAyICstCj4+ICAgMSBmaWxlcyBjaGFuZ2VkLCAxIGluc2VydGlvbnMoKyksIDEgZGVs
ZXRpb25zKC0pCj4+Cj4+IGRpZmYgLS1naXQgYS9hcmNoL2lhNjQvaW5jbHVkZS9hc20veGVuL2lu
dGVyZmFjZS5oIGIvYXJjaC9pYTY0L2luY2x1ZGUvYXNtL3hlbi9pbnRlcmZhY2UuaAo+PiBpbmRl
eCAxZDI0MjdkLi5mYmI1MTk4IDEwMDY0NAo+PiAtLS0gYS9hcmNoL2lhNjQvaW5jbHVkZS9hc20v
eGVuL2ludGVyZmFjZS5oCj4+ICsrKyBiL2FyY2gvaWE2NC9pbmNsdWRlL2FzbS94ZW4vaW50ZXJm
YWNlLmgKPj4gQEAgLTcxLDcgKzcxLDcgQEAKPj4gICBfX0RFRklORV9HVUVTVF9IQU5ETEUodWNo
YXIsIHVuc2lnbmVkIGNoYXIpOwo+PiAgIF9fREVGSU5FX0dVRVNUX0hBTkRMRSh1aW50LCB1bnNp
Z25lZCBpbnQpOwo+PiAgIF9fREVGSU5FX0dVRVNUX0hBTkRMRSh1bG9uZywgdW5zaWduZWQgbG9u
Zyk7Cj4+IC1fX0RFRklORV9HVUVTVF9IQU5ETEUodTY0LCB1bnNpZ25lZCBsb25nKTsKPj4gKwo+
PiAgIERFRklORV9HVUVTVF9IQU5ETEUoY2hhcik7Cj4+ICAgREVGSU5FX0dVRVNUX0hBTkRMRShp
bnQpOwo+PiAgIERFRklORV9HVUVTVF9IQU5ETEUobG9uZyk7Cj4+IC0tIAo+PiAxLjcuMy4xCgpf
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwg
bWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tCmh0dHA6Ly9saXN0cy54
ZW5zb3VyY2UuY29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Mon Dec 05 09:24:01 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 09:24:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXUla-0007eG-Et; Mon, 05 Dec 2011 09:23:18 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <annie.li@oracle.com>) id 1RXUlZ-0007eB-E4
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 09:23:17 +0000
X-Env-Sender: annie.li@oracle.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1323076951!6197049!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQyODAzMw==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10363 invoked from network); 5 Dec 2011 09:22:33 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-8.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Dec 2011 09:22:33 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pB59MOsh003943
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 5 Dec 2011 09:22:24 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pB59MNZ7027022
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 5 Dec 2011 09:22:23 GMT
Received: from abhmt106.oracle.com (abhmt106.oracle.com [141.146.116.58])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pB59MHwx002002; Mon, 5 Dec 2011 03:22:17 -0600
Received: from [10.182.39.81] (/10.182.39.81)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 05 Dec 2011 01:22:17 -0800
Message-ID: <4EDC8D57.6050900@oracle.com>
Date: Mon, 05 Dec 2011 17:22:31 +0800
From: ANNIE LI <annie.li@oracle.com>
Organization: Oracle Corporation
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.9.2.23) Gecko/20110920 Thunderbird/3.1.15
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <4ed6746d25537aefd2@agluck-desktop.sc.intel.com>
	<20111130183900.GA15847@phenom.dumpdata.com>
In-Reply-To: <20111130183900.GA15847@phenom.dumpdata.com>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090205.4EDC8D50.00D0,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com, "Luck, Tony" <tony.luck@intel.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH] ia64: fix build breakage because of
 conflicting u64 guest handles
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: base64
Content-Type: text/plain; charset="utf-8"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

CgpPbiAyMDExLTEyLTEgMjozOSwgS29ucmFkIFJ6ZXN6dXRlayBXaWxrIHdyb3RlOgo+IE9uIFdl
ZCwgTm92IDMwLCAyMDExIGF0IDEwOjIyOjM3QU0gLTA4MDAsIEx1Y2ssIFRvbnkgd3JvdGU6Cj4+
IGluY2x1ZGUveGVuL2ludGVyZmFjZS94ZW4uaDo1MjY6IGVycm9yOiBjb25mbGljdGluZyB0eXBl
cyBmb3Ig4oCYX19ndWVzdF9oYW5kbGVfdTY04oCZCj4+IGFyY2gvaWE2NC9pbmNsdWRlL2FzbS94
ZW4vaW50ZXJmYWNlLmg6NzQ6IGVycm9yOiBwcmV2aW91cyBkZWNsYXJhdGlvbiBvZiDigJhfX2d1
ZXN0X2hhbmRsZV91NjTigJkgd2FzIGhlcmUKPj4KPj4gUHJvYmxlbSBpbnRyb2R1Y2VkIGJ5ICJ4
ZW4vZ3JhbnR0YWJsZTogSW50cm9kdWNpbmcgZ3JhbnQgdGFibGUgVjIgc3R1Y3R1cmUiCj4+Cj4+
IHdoaWNoIGFkZGVkIGEgbmV3IGRlZmluaXRpb24gdG8gaW5jbHVkZS94ZW4vaW50ZXJmYWNlL3hl
bi5oIGZvciAidTY0Ii4KPj4KPj4gRml4OiBkZWxldGUgdGhlIGlhNjQgYXJjaCBzcGVjaWZpYyBk
ZWZpbml0aW9uLgo+Pgo+PiBTaWduZWQtb2ZmLWJ5OiBUb255IEx1Y2s8dG9ueS5sdWNrQGludGVs
LmNvbT4KPj4gLS0tCj4+Cj4+IENhbiBzb21lb25lIGVpdGhlciBmb2xkIHRoaXMgaW50byB0aGUg
YWJvdmUgcGF0Y2gsIG9yIGFkZCBpdCB0byB0aGUKPj4gc2FtZSB0cmVlIHRoYXQgaXMgZmVlZGlu
ZyBpbnRvIGxpbnV4LW5leHQgLSBJIHNhdyB0aGUgYnJlYWthZ2UgaW4KPj4gdG9kYXkncyAibmV4
dC0yMDExMTEzMCIgdGFnLiAgVGhhbmtzLgo+IEFoLCBJIGNhbiBmb2xkIGl0IGluLiBUaGFua3Mh
CkEgZGVmaW5pdGlvbiBmb3IgdWludDY0X3QgYWxyZWFkeSBleGlzdGluZyBpbiAKYXJjaC94ODYv
aW5jbHVkZS9hc20veGVuL2ludGVyZmFjZS5oLCA1OCBsaW5lOiAKREVGSU5FX0dVRVNUX0hBTkRM
RSh1aW50NjRfdCk7Ck1heWJlIGl0IGlzIGJldHRlciB0byByZW1vdmUgdGhlIGRlZmluaXRpb24g
aW4gCmluY2x1ZGUveGVuL2ludGVyZmFjZS94ZW4uaCBvZiBncmFudCB0YWJsZSB2MiBwYXRjaCwg
YW5kIG5vdCBjaGFuZ2UgY29kZSAKb2YgYXJjaC9pYTY0L2luY2x1ZGUvYXNtL3hlbi9pbnRlcmZh
Y2UuaC4KCktvbnJhZCwgZGlkIHlvdSBmb2xkIGl0IGFscmVhZHk/IG9yIEkgcmV2ZXJ0IHRoZSBk
ZWZpbml0aW9uIGluIG15IApmb2xsb3dpbmcgc3ViLXBhZ2UgYW5kIHRyYW5zaXRpdmUgcGF0Y2hl
cz8KClRoYW5rcwpBbm5pZQo+PiAgIGFyY2gvaWE2NC9pbmNsdWRlL2FzbS94ZW4vaW50ZXJmYWNl
LmggfCAgICAyICstCj4+ICAgMSBmaWxlcyBjaGFuZ2VkLCAxIGluc2VydGlvbnMoKyksIDEgZGVs
ZXRpb25zKC0pCj4+Cj4+IGRpZmYgLS1naXQgYS9hcmNoL2lhNjQvaW5jbHVkZS9hc20veGVuL2lu
dGVyZmFjZS5oIGIvYXJjaC9pYTY0L2luY2x1ZGUvYXNtL3hlbi9pbnRlcmZhY2UuaAo+PiBpbmRl
eCAxZDI0MjdkLi5mYmI1MTk4IDEwMDY0NAo+PiAtLS0gYS9hcmNoL2lhNjQvaW5jbHVkZS9hc20v
eGVuL2ludGVyZmFjZS5oCj4+ICsrKyBiL2FyY2gvaWE2NC9pbmNsdWRlL2FzbS94ZW4vaW50ZXJm
YWNlLmgKPj4gQEAgLTcxLDcgKzcxLDcgQEAKPj4gICBfX0RFRklORV9HVUVTVF9IQU5ETEUodWNo
YXIsIHVuc2lnbmVkIGNoYXIpOwo+PiAgIF9fREVGSU5FX0dVRVNUX0hBTkRMRSh1aW50LCB1bnNp
Z25lZCBpbnQpOwo+PiAgIF9fREVGSU5FX0dVRVNUX0hBTkRMRSh1bG9uZywgdW5zaWduZWQgbG9u
Zyk7Cj4+IC1fX0RFRklORV9HVUVTVF9IQU5ETEUodTY0LCB1bnNpZ25lZCBsb25nKTsKPj4gKwo+
PiAgIERFRklORV9HVUVTVF9IQU5ETEUoY2hhcik7Cj4+ICAgREVGSU5FX0dVRVNUX0hBTkRMRShp
bnQpOwo+PiAgIERFRklORV9HVUVTVF9IQU5ETEUobG9uZyk7Cj4+IC0tIAo+PiAxLjcuMy4xCgpf
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwg
bWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tCmh0dHA6Ly9saXN0cy54
ZW5zb3VyY2UuY29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Mon Dec 05 09:27:15 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 09:27:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXUot-0007kO-Jl; Mon, 05 Dec 2011 09:26:43 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RXUoo-0007kA-4C
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 09:26:38 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1323077152!5891907!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4ODk=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7254 invoked from network); 5 Dec 2011 09:25:53 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-12.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 5 Dec 2011 09:25:53 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 05 Dec 2011 09:25:52 +0000
Message-Id: <4EDC9C2D02000078000655D1@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 05 Dec 2011 09:25:49 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: <dgdegra@tycho.nsa.gov>
References: <osstest-10332-mainreport@xen.org>
In-Reply-To: <osstest-10332-mainreport@xen.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [xen-unstable test] 10332: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 05.12.11 at 05:11, xen.org <ian.jackson@eu.citrix.com> wrote:
>  build-i386                    4 xen-build                 fail REGR. vs. 10201

cc1: warnings being treated as errors
label-pci.c: In function 'main':
label-pci.c:79: error: format '%lx' expects type 'long unsigned int *', but argument 3 has type 'uint64_t *'
label-pci.c:79: error: format '%lx' expects type 'long unsigned int *', but argument 4 has type 'uint64_t *'
label-pci.c:79: error: format '%lx' expects type 'long unsigned int *', but argument 5 has type 'uint64_t *'
label-pci.c:85: error: format '%lx' expects type 'long unsigned int', but argument 3 has type 'uint64_t'
label-pci.c:85: error: format '%lx' expects type 'long unsigned int', but argument 4 has type 'uint64_t'
label-pci.c:95: error: format '%lx' expects type 'long unsigned int', but argument 3 has type 'uint64_t'
label-pci.c:95: error: format '%lx' expects type 'long unsigned int', but argument 4 has type 'uint64_t'
label-pci.c:108: error: format '%ld' expects type 'long int *', but argument 3 has type 'uint64_t *'
label-pci.c:113: error: format '%ld' expects type 'long int', but argument 3 has type 'uint64_t'
make[5]: *** [label-pci.o] Error 1

This is due to entirely non-portable code in tools/flask/utils/label-pci.c: If
you use C99 types, you also need to use C99 format macros for calls to
the printf and scanf function families.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 09:27:15 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 09:27:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXUot-0007kO-Jl; Mon, 05 Dec 2011 09:26:43 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RXUoo-0007kA-4C
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 09:26:38 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1323077152!5891907!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4ODk=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7254 invoked from network); 5 Dec 2011 09:25:53 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-12.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 5 Dec 2011 09:25:53 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 05 Dec 2011 09:25:52 +0000
Message-Id: <4EDC9C2D02000078000655D1@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 05 Dec 2011 09:25:49 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: <dgdegra@tycho.nsa.gov>
References: <osstest-10332-mainreport@xen.org>
In-Reply-To: <osstest-10332-mainreport@xen.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [xen-unstable test] 10332: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 05.12.11 at 05:11, xen.org <ian.jackson@eu.citrix.com> wrote:
>  build-i386                    4 xen-build                 fail REGR. vs. 10201

cc1: warnings being treated as errors
label-pci.c: In function 'main':
label-pci.c:79: error: format '%lx' expects type 'long unsigned int *', but argument 3 has type 'uint64_t *'
label-pci.c:79: error: format '%lx' expects type 'long unsigned int *', but argument 4 has type 'uint64_t *'
label-pci.c:79: error: format '%lx' expects type 'long unsigned int *', but argument 5 has type 'uint64_t *'
label-pci.c:85: error: format '%lx' expects type 'long unsigned int', but argument 3 has type 'uint64_t'
label-pci.c:85: error: format '%lx' expects type 'long unsigned int', but argument 4 has type 'uint64_t'
label-pci.c:95: error: format '%lx' expects type 'long unsigned int', but argument 3 has type 'uint64_t'
label-pci.c:95: error: format '%lx' expects type 'long unsigned int', but argument 4 has type 'uint64_t'
label-pci.c:108: error: format '%ld' expects type 'long int *', but argument 3 has type 'uint64_t *'
label-pci.c:113: error: format '%ld' expects type 'long int', but argument 3 has type 'uint64_t'
make[5]: *** [label-pci.o] Error 1

This is due to entirely non-portable code in tools/flask/utils/label-pci.c: If
you use C99 types, you also need to use C99 format macros for calls to
the printf and scanf function families.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 09:36:37 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 09:36:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXUxu-0007yX-LO; Mon, 05 Dec 2011 09:36:02 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RXUxs-0007yP-Q5
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 09:36:01 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1323077715!660768!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjAyNg==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28286 invoked from network); 5 Dec 2011 09:35:16 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Dec 2011 09:35:16 -0000
X-IronPort-AV: E=Sophos;i="4.71,298,1320624000"; 
   d="scan'208";a="9283403"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Dec 2011 09:35:15 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Mon, 5 Dec 2011
	09:35:15 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "Hao, Xudong" <xudong.hao@intel.com>
Date: Mon, 5 Dec 2011 09:35:14 +0000
In-Reply-To: <BC00F5384FCFC9499AF06F92E8B78A9E2870CA733E@shsmsx502.ccr.corp.intel.com>
References: <BC00F5384FCFC9499AF06F92E8B78A9E2870BB473F@shsmsx502.ccr.corp.intel.com>
	<1322815671.31810.265.camel@zakaz.uk.xensource.com>
	<BC00F5384FCFC9499AF06F92E8B78A9E2870BB4787@shsmsx502.ccr.corp.intel.com>
	<1322818316.31810.298.camel@zakaz.uk.xensource.com>
	<BC00F5384FCFC9499AF06F92E8B78A9E2870CA733E@shsmsx502.ccr.corp.intel.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323077715.29870.157.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "Tian, Kevin" <kevin.tian@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>, "Shan, 
	Haitao" <haitao.shan@intel.com>, "Kay, Allen M" <allen.m.kay@intel.com>,
	Keir Fraser <keir.xen@gmail.com>
Subject: Re: [Xen-devel] [PATCH] tools/firmware: remove "_PS0/3" Method
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Sun, 2011-12-04 at 04:38 +0000, Hao, Xudong wrote:
> > Have you tested any other OSes? How does Windows for example respond to
> > this change in the ACPI tables?
> > 
> 
> Yes, I did some test with this patch, till now, all result shows patch
> works well with PCI device assign and hotplug, as well as HVM S3.
> 
> Pass cases:
> RHEL6.1, SLES11 SP1, Win2008 VF device assign and hotplug.
> RHEL6.1, Winxp, Win7 e1000e NIC device assign and hotplug
> RHEL6.1, RHEL5.1 Guest S3
> 
> > Are there any devices which do not implement PCI PM and therefore rely on
> > this ACPI mechanism to function? My understanding was that
> > 47e9037ac166 was required in part due to the lack of PCI PM support on some
> > VF devices. I think it was a different Intel SR-IOV NIC than the one you are
> > testing, an 82559 if [0] is to be believed.
> > 
> VF is such device which do not have PCI PM capability, these device
> will be set PCI_D0 directly in function
> pci_platform_power_transition().
> 
> static int pci_platform_power_transition(struct pci_dev *dev, pci_power_t state)
> {
>     int error;
>     if (platform_pci_power_manageable(dev)) {
>         error = platform_pci_set_power_state(dev, state);
>         ...
>     } else {
>         error = -ENODEV;
>         /* Fall back to PCI_D0 if native PM is not supported */
>         if (!dev->pm_cap)
>             dev->current_state = PCI_D0;
> 
> > Also there was a previous attempt to remove _PS0 in [1]. Allen Kay (CCd) tested
> > and reported that removing these values causes Windows not to boot. It was
> > suggested in that thread that both _PS0 and _PS3 need to be removed (which
> > you do) but it was also suggested that doing so breaks Linux S3 support, have
> > you tried this?
> > 
> Windows does not to boot only happen when remove _PS0, however Windows
> guest can boot up with removing _PS0 and _PS3.
> 
> According to the annotate of "_PS0/3", it's for debug purpose. I do
> not know whether it's required for other purpose, comments of others?

Your explanation / results are good enough for me.

Thanks, Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 09:36:37 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 09:36:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXUxu-0007yX-LO; Mon, 05 Dec 2011 09:36:02 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RXUxs-0007yP-Q5
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 09:36:01 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1323077715!660768!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjAyNg==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28286 invoked from network); 5 Dec 2011 09:35:16 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Dec 2011 09:35:16 -0000
X-IronPort-AV: E=Sophos;i="4.71,298,1320624000"; 
   d="scan'208";a="9283403"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Dec 2011 09:35:15 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Mon, 5 Dec 2011
	09:35:15 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "Hao, Xudong" <xudong.hao@intel.com>
Date: Mon, 5 Dec 2011 09:35:14 +0000
In-Reply-To: <BC00F5384FCFC9499AF06F92E8B78A9E2870CA733E@shsmsx502.ccr.corp.intel.com>
References: <BC00F5384FCFC9499AF06F92E8B78A9E2870BB473F@shsmsx502.ccr.corp.intel.com>
	<1322815671.31810.265.camel@zakaz.uk.xensource.com>
	<BC00F5384FCFC9499AF06F92E8B78A9E2870BB4787@shsmsx502.ccr.corp.intel.com>
	<1322818316.31810.298.camel@zakaz.uk.xensource.com>
	<BC00F5384FCFC9499AF06F92E8B78A9E2870CA733E@shsmsx502.ccr.corp.intel.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323077715.29870.157.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "Tian, Kevin" <kevin.tian@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>, "Shan, 
	Haitao" <haitao.shan@intel.com>, "Kay, Allen M" <allen.m.kay@intel.com>,
	Keir Fraser <keir.xen@gmail.com>
Subject: Re: [Xen-devel] [PATCH] tools/firmware: remove "_PS0/3" Method
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Sun, 2011-12-04 at 04:38 +0000, Hao, Xudong wrote:
> > Have you tested any other OSes? How does Windows for example respond to
> > this change in the ACPI tables?
> > 
> 
> Yes, I did some test with this patch, till now, all result shows patch
> works well with PCI device assign and hotplug, as well as HVM S3.
> 
> Pass cases:
> RHEL6.1, SLES11 SP1, Win2008 VF device assign and hotplug.
> RHEL6.1, Winxp, Win7 e1000e NIC device assign and hotplug
> RHEL6.1, RHEL5.1 Guest S3
> 
> > Are there any devices which do not implement PCI PM and therefore rely on
> > this ACPI mechanism to function? My understanding was that
> > 47e9037ac166 was required in part due to the lack of PCI PM support on some
> > VF devices. I think it was a different Intel SR-IOV NIC than the one you are
> > testing, an 82559 if [0] is to be believed.
> > 
> VF is such device which do not have PCI PM capability, these device
> will be set PCI_D0 directly in function
> pci_platform_power_transition().
> 
> static int pci_platform_power_transition(struct pci_dev *dev, pci_power_t state)
> {
>     int error;
>     if (platform_pci_power_manageable(dev)) {
>         error = platform_pci_set_power_state(dev, state);
>         ...
>     } else {
>         error = -ENODEV;
>         /* Fall back to PCI_D0 if native PM is not supported */
>         if (!dev->pm_cap)
>             dev->current_state = PCI_D0;
> 
> > Also there was a previous attempt to remove _PS0 in [1]. Allen Kay (CCd) tested
> > and reported that removing these values causes Windows not to boot. It was
> > suggested in that thread that both _PS0 and _PS3 need to be removed (which
> > you do) but it was also suggested that doing so breaks Linux S3 support, have
> > you tried this?
> > 
> Windows does not to boot only happen when remove _PS0, however Windows
> guest can boot up with removing _PS0 and _PS3.
> 
> According to the annotate of "_PS0/3", it's for debug purpose. I do
> not know whether it's required for other purpose, comments of others?

Your explanation / results are good enough for me.

Thanks, Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 09:54:14 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 09:54:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXVF9-0008L3-5R; Mon, 05 Dec 2011 09:53:51 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RXVF7-0008Kh-Vs
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 09:53:50 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1323078785!6919462!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjAyNg==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4480 invoked from network); 5 Dec 2011 09:53:05 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Dec 2011 09:53:05 -0000
X-IronPort-AV: E=Sophos;i="4.71,298,1320624000"; 
   d="scan'208";a="9283935"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Dec 2011 09:53:00 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Mon, 5 Dec 2011
	09:53:00 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Mon, 5 Dec 2011 09:53:00 +0000
In-Reply-To: <BC00F5384FCFC9499AF06F92E8B78A9E2870CA7799@shsmsx502.ccr.corp.intel.com>
References: <CAKLFbfwYyKM=feBXQdj00XAvy+YWdBddLBWCv0CVROwA3bTGJg@mail.gmail.com>
	<BC00F5384FCFC9499AF06F92E8B78A9E2870CA7799@shsmsx502.ccr.corp.intel.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323078780.29870.163.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Subject: Re: [Xen-devel] Ring3 Hypercalls from HVM DomU
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gTW9uLCAyMDExLTEyLTA1IGF0IDA2OjIzICswMDAwLCBaaGFuZywgWGlhbnRhbyB3cm90ZToK
PiBUaGF0IGlzIGJlY2F1c2Ug4oCcaW50ICQweDky4oCdIG9ubHkgc3dpdGNoIHRoZSBjb250ZXh0
IHRvIGd1ZXN04oCZcyBJRFQKPiBpbnN0ZWFkIG9mIGh5cGVydmlzb3LigJlzIElEVCBieSBkZWZh
dWx0LgoKImJ5IGRlZmF1bHQiPyBJcyB0aGVyZSBzb21lIG1lY2hhbmlzbSBieSB3aGljaCBhbiBp
bnQgaW5zdHJ1Y3Rpb24gaW4Kbm9uLXJvb3QgbW9kZSBjYW4gY2F1c2UgYSB2bWV4aXQgdG8gYSBo
b3N0IElEVCBlbnRyeSBpbnN0ZWFkIG9mIHRoZQpndWVzdCBJRFQ/IEkgZGlkbid0IHNlZSBpdCBi
YXNlZCBvbiBhIHF1aWNrIHNraW0gb2YgcmVsZXZhbnQgY2hhcHRlcnMgb2YKdGhlIFNETS4KCklh
bi4KCj4gCj4gWGlhbnRhbwo+IAo+ICAKPiAKPiBGcm9tOiB4ZW4tZGV2ZWwtYm91bmNlc0BsaXN0
cy54ZW5zb3VyY2UuY29tCj4gW21haWx0bzp4ZW4tZGV2ZWwtYm91bmNlc0BsaXN0cy54ZW5zb3Vy
Y2UuY29tXSBPbiBCZWhhbGYgT2YgU3J1amFuCj4gS290aWtlbGEKPiBTZW50OiBTYXR1cmRheSwg
RGVjZW1iZXIgMDMsIDIwMTEgNDo1MiBBTQo+IFRvOiB4ZW4tZGV2ZWxAbGlzdHMueGVuc291cmNl
LmNvbQo+IFN1YmplY3Q6IFtYZW4tZGV2ZWxdIFJpbmczIEh5cGVyY2FsbHMgZnJvbSBIVk0gRG9t
VQo+IAo+ICAKPiAKPiBIaSwKPiAKPiAgCj4gCj4gCj4gSSBoYXZlIGNyZWF0ZWQgaHlwZXJjYWxs
cyB0aGF0IGNhbiBiZSBpbnZva2VkIGZyb20gcmluZy0zIGJ5IHNldHRpbmcKPiB0aGUgcmluZy0z
IGdhdGUgaW4geGVuLiBUaGlzIHdvcmtzIGZpbmUgd2hlbiBJIGludm9rZSB0aGUgaHlwZXJjYWxs
Cj4gZnJvbSBEb20wLiBJIHdhbnQgdG8gaW52b2tlIHRoZSBzYW1lIGZyb20gYSBIVk0gRG9tVS4g
QnV0IEkga2VlcAo+IGdldHRpbmcgdGhlIHNlZ21lbnRhdGlvbiBmYXVsdCB3aGVuIEkgaW52b2tl
IHRoZSByaW5nM19oeXBlcmFjYWxsIGZyb20KPiBIVk0gRG9tVS4gQW55IGlkZWFzPwo+IAo+IFRo
ZSBzZXR0aW5nIHVwIGdhdGUgaXMgYXMgZm9sbG93czoKPiBfc2V0X2dhdGUoaWR0X3RhYmxlKzB4
OTIsIDE0LCAzLCAmaHlwZXJjYWxsKTsKPiAKPiAKPiAKPiBUaGUgaHlwZXJjYWxsIGludm9raW5n
IGNvZGUgbG9va3MgbGlrZSB0aGlzOgo+IGludCByaW5nM19oeXBlcmNhbGwodW5zaWduZWQgbG9u
ZyB2YSwgaW50IGNvbW1hbmQpCj4gewo+ICAgICBpbnQgcmV0Owo+IAo+ICAgICBhc20oImludCAk
MHg5MiIgOiAiPWEiKHJldCkgOiAiYSIoNDApLCAiYiIodmEpLCAiYyIoY29tbWFuZCkpOwo+ICAg
ICAKPiAgICAgcmV0dXJuIHJldDsKPiB9Cj4gCj4gfiBTREsKPiAKPiAKCgoKX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlz
dApYZW4tZGV2ZWxAbGlzdHMueGVuc291cmNlLmNvbQpodHRwOi8vbGlzdHMueGVuc291cmNlLmNv
bS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Mon Dec 05 09:54:14 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 09:54:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXVF9-0008L3-5R; Mon, 05 Dec 2011 09:53:51 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RXVF7-0008Kh-Vs
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 09:53:50 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1323078785!6919462!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjAyNg==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4480 invoked from network); 5 Dec 2011 09:53:05 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Dec 2011 09:53:05 -0000
X-IronPort-AV: E=Sophos;i="4.71,298,1320624000"; 
   d="scan'208";a="9283935"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Dec 2011 09:53:00 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Mon, 5 Dec 2011
	09:53:00 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Mon, 5 Dec 2011 09:53:00 +0000
In-Reply-To: <BC00F5384FCFC9499AF06F92E8B78A9E2870CA7799@shsmsx502.ccr.corp.intel.com>
References: <CAKLFbfwYyKM=feBXQdj00XAvy+YWdBddLBWCv0CVROwA3bTGJg@mail.gmail.com>
	<BC00F5384FCFC9499AF06F92E8B78A9E2870CA7799@shsmsx502.ccr.corp.intel.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323078780.29870.163.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Subject: Re: [Xen-devel] Ring3 Hypercalls from HVM DomU
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gTW9uLCAyMDExLTEyLTA1IGF0IDA2OjIzICswMDAwLCBaaGFuZywgWGlhbnRhbyB3cm90ZToK
PiBUaGF0IGlzIGJlY2F1c2Ug4oCcaW50ICQweDky4oCdIG9ubHkgc3dpdGNoIHRoZSBjb250ZXh0
IHRvIGd1ZXN04oCZcyBJRFQKPiBpbnN0ZWFkIG9mIGh5cGVydmlzb3LigJlzIElEVCBieSBkZWZh
dWx0LgoKImJ5IGRlZmF1bHQiPyBJcyB0aGVyZSBzb21lIG1lY2hhbmlzbSBieSB3aGljaCBhbiBp
bnQgaW5zdHJ1Y3Rpb24gaW4Kbm9uLXJvb3QgbW9kZSBjYW4gY2F1c2UgYSB2bWV4aXQgdG8gYSBo
b3N0IElEVCBlbnRyeSBpbnN0ZWFkIG9mIHRoZQpndWVzdCBJRFQ/IEkgZGlkbid0IHNlZSBpdCBi
YXNlZCBvbiBhIHF1aWNrIHNraW0gb2YgcmVsZXZhbnQgY2hhcHRlcnMgb2YKdGhlIFNETS4KCklh
bi4KCj4gCj4gWGlhbnRhbwo+IAo+ICAKPiAKPiBGcm9tOiB4ZW4tZGV2ZWwtYm91bmNlc0BsaXN0
cy54ZW5zb3VyY2UuY29tCj4gW21haWx0bzp4ZW4tZGV2ZWwtYm91bmNlc0BsaXN0cy54ZW5zb3Vy
Y2UuY29tXSBPbiBCZWhhbGYgT2YgU3J1amFuCj4gS290aWtlbGEKPiBTZW50OiBTYXR1cmRheSwg
RGVjZW1iZXIgMDMsIDIwMTEgNDo1MiBBTQo+IFRvOiB4ZW4tZGV2ZWxAbGlzdHMueGVuc291cmNl
LmNvbQo+IFN1YmplY3Q6IFtYZW4tZGV2ZWxdIFJpbmczIEh5cGVyY2FsbHMgZnJvbSBIVk0gRG9t
VQo+IAo+ICAKPiAKPiBIaSwKPiAKPiAgCj4gCj4gCj4gSSBoYXZlIGNyZWF0ZWQgaHlwZXJjYWxs
cyB0aGF0IGNhbiBiZSBpbnZva2VkIGZyb20gcmluZy0zIGJ5IHNldHRpbmcKPiB0aGUgcmluZy0z
IGdhdGUgaW4geGVuLiBUaGlzIHdvcmtzIGZpbmUgd2hlbiBJIGludm9rZSB0aGUgaHlwZXJjYWxs
Cj4gZnJvbSBEb20wLiBJIHdhbnQgdG8gaW52b2tlIHRoZSBzYW1lIGZyb20gYSBIVk0gRG9tVS4g
QnV0IEkga2VlcAo+IGdldHRpbmcgdGhlIHNlZ21lbnRhdGlvbiBmYXVsdCB3aGVuIEkgaW52b2tl
IHRoZSByaW5nM19oeXBlcmFjYWxsIGZyb20KPiBIVk0gRG9tVS4gQW55IGlkZWFzPwo+IAo+IFRo
ZSBzZXR0aW5nIHVwIGdhdGUgaXMgYXMgZm9sbG93czoKPiBfc2V0X2dhdGUoaWR0X3RhYmxlKzB4
OTIsIDE0LCAzLCAmaHlwZXJjYWxsKTsKPiAKPiAKPiAKPiBUaGUgaHlwZXJjYWxsIGludm9raW5n
IGNvZGUgbG9va3MgbGlrZSB0aGlzOgo+IGludCByaW5nM19oeXBlcmNhbGwodW5zaWduZWQgbG9u
ZyB2YSwgaW50IGNvbW1hbmQpCj4gewo+ICAgICBpbnQgcmV0Owo+IAo+ICAgICBhc20oImludCAk
MHg5MiIgOiAiPWEiKHJldCkgOiAiYSIoNDApLCAiYiIodmEpLCAiYyIoY29tbWFuZCkpOwo+ICAg
ICAKPiAgICAgcmV0dXJuIHJldDsKPiB9Cj4gCj4gfiBTREsKPiAKPiAKCgoKX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlz
dApYZW4tZGV2ZWxAbGlzdHMueGVuc291cmNlLmNvbQpodHRwOi8vbGlzdHMueGVuc291cmNlLmNv
bS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Mon Dec 05 09:54:50 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 09:54:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXVFi-0008O1-Jn; Mon, 05 Dec 2011 09:54:26 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RXVFh-0008NS-12
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 09:54:25 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1323078820!6116992!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjAyNg==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5807 invoked from network); 5 Dec 2011 09:53:40 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Dec 2011 09:53:40 -0000
X-IronPort-AV: E=Sophos;i="4.71,298,1320624000"; 
   d="scan'208";a="9283953"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Dec 2011 09:53:40 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Mon, 5 Dec 2011
	09:53:40 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Baozeng <sploving1@gmail.com>
Date: Mon, 5 Dec 2011 09:53:39 +0000
In-Reply-To: <CAP=GMUEXx9Z58srj0E4EWGwUqGpYHPFUFWB4znpco0rCY=BF1A@mail.gmail.com>
References: <CAP=GMUEvnnOGmiM9ar+oQw4c6fwzvWa+HX98C3kV_XgMc3xg9Q@mail.gmail.com>
	<CAFLBxZYu4ormVzBJgakptUL6NvQSJrdQZUSVjeJtP4LCdVj3CA@mail.gmail.com>
	<CAP=GMUEXx9Z58srj0E4EWGwUqGpYHPFUFWB4znpco0rCY=BF1A@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323078819.29870.164.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] any exit function in xen that is similar to
 exit_kernel?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2011-12-01 at 12:55 +0000, Baozeng wrote:
> 2011/12/1 George Dunlap <George.Dunlap@eu.citrix.com>:
> > On Tue, Nov 29, 2011 at 2:22 PM, Baozeng <sploving1@gmail.com> wrote:
> >> Hello all,
> >> I added a hypercall "do_greet" that only prints "Hello world" to do a
> >> small experiment. After it prints the "hello world", I would it to
> >> exit from Xen and stop current process. For instance:
> >> the hypercall is like this:
> >> int do_greet(){
> >>   pirntk("Hello world\n");
> >>   /*then I would it exit from Xen and stop current process that called it.*/
> >>   exit_?? //exit(0) does not work.
> >> }
> >>
> >> If a process at the application level calls this hypercall through
> >> privcmd file, I would like it kill this process after the hypercall
> >> prints "Hello world". Then how to do that?
> >
> > A process is a guest kernel-level construct.  Xen doesn't know
> > anything about processes; it only knows things about VMs.  You can
> > easily kill the guest by doing this:
> >  domain_crash(current->domain);
> >
> > If you want the process only to be killed, you have to have the guest
> > kernel do it.
> >
> Okay. I know. It need first return to the kernel address space. Then
> is there any function that can return the kernel address space from
> Xen after the hypercall? like this:
>  int do_greet(){
>     pirntk("Hello world\n");
>     /*then I would it exit from Xen to the kernel.*/
>     exit_??  // after that CS and EIP should pointer to the kernel
> address space.
>  }
> 
> if there doesnot exiest such function, how can I know which function
> switches kernel into  Xen to trigger such hypercall, so that I can
> return it by myself. Is it in the entry.S, when int $82 instruction
> happen, then the CS and EIP begin to switch point to Xen? thanks

This is a quite strange thing to want to do. Please can you explain your
end goal (i.e. what problem are you trying to solve with this)? Perhaps
there is a better way.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 09:54:50 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 09:54:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXVFi-0008O1-Jn; Mon, 05 Dec 2011 09:54:26 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RXVFh-0008NS-12
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 09:54:25 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1323078820!6116992!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjAyNg==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5807 invoked from network); 5 Dec 2011 09:53:40 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Dec 2011 09:53:40 -0000
X-IronPort-AV: E=Sophos;i="4.71,298,1320624000"; 
   d="scan'208";a="9283953"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Dec 2011 09:53:40 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Mon, 5 Dec 2011
	09:53:40 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Baozeng <sploving1@gmail.com>
Date: Mon, 5 Dec 2011 09:53:39 +0000
In-Reply-To: <CAP=GMUEXx9Z58srj0E4EWGwUqGpYHPFUFWB4znpco0rCY=BF1A@mail.gmail.com>
References: <CAP=GMUEvnnOGmiM9ar+oQw4c6fwzvWa+HX98C3kV_XgMc3xg9Q@mail.gmail.com>
	<CAFLBxZYu4ormVzBJgakptUL6NvQSJrdQZUSVjeJtP4LCdVj3CA@mail.gmail.com>
	<CAP=GMUEXx9Z58srj0E4EWGwUqGpYHPFUFWB4znpco0rCY=BF1A@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323078819.29870.164.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] any exit function in xen that is similar to
 exit_kernel?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2011-12-01 at 12:55 +0000, Baozeng wrote:
> 2011/12/1 George Dunlap <George.Dunlap@eu.citrix.com>:
> > On Tue, Nov 29, 2011 at 2:22 PM, Baozeng <sploving1@gmail.com> wrote:
> >> Hello all,
> >> I added a hypercall "do_greet" that only prints "Hello world" to do a
> >> small experiment. After it prints the "hello world", I would it to
> >> exit from Xen and stop current process. For instance:
> >> the hypercall is like this:
> >> int do_greet(){
> >>   pirntk("Hello world\n");
> >>   /*then I would it exit from Xen and stop current process that called it.*/
> >>   exit_?? //exit(0) does not work.
> >> }
> >>
> >> If a process at the application level calls this hypercall through
> >> privcmd file, I would like it kill this process after the hypercall
> >> prints "Hello world". Then how to do that?
> >
> > A process is a guest kernel-level construct.  Xen doesn't know
> > anything about processes; it only knows things about VMs.  You can
> > easily kill the guest by doing this:
> >  domain_crash(current->domain);
> >
> > If you want the process only to be killed, you have to have the guest
> > kernel do it.
> >
> Okay. I know. It need first return to the kernel address space. Then
> is there any function that can return the kernel address space from
> Xen after the hypercall? like this:
>  int do_greet(){
>     pirntk("Hello world\n");
>     /*then I would it exit from Xen to the kernel.*/
>     exit_??  // after that CS and EIP should pointer to the kernel
> address space.
>  }
> 
> if there doesnot exiest such function, how can I know which function
> switches kernel into  Xen to trigger such hypercall, so that I can
> return it by myself. Is it in the entry.S, when int $82 instruction
> happen, then the CS and EIP begin to switch point to Xen? thanks

This is a quite strange thing to want to do. Please can you explain your
end goal (i.e. what problem are you trying to solve with this)? Perhaps
there is a better way.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 09:56:34 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 09:56:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXVHU-000089-3U; Mon, 05 Dec 2011 09:56:16 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RXVHS-00007D-M5
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 09:56:14 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1323078926!6188002!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjAyNg==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28812 invoked from network); 5 Dec 2011 09:55:30 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Dec 2011 09:55:30 -0000
X-IronPort-AV: E=Sophos;i="4.71,298,1320624000"; 
   d="scan'208";a="9284000"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Dec 2011 09:55:26 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.161]) by
	LONPMAILMX01.citrite.net ([10.30.203.162]) with mapi; Mon, 5 Dec 2011
	09:55:26 +0000
From: Paul Durrant <Paul.Durrant@citrix.com>
To: "rshriram@cs.ubc.ca" <rshriram@cs.ubc.ca>
Date: Mon, 5 Dec 2011 09:55:31 +0000
Thread-Topic: [Xen-devel] [PATCH] VM generation ID save/restore and migrate
Thread-Index: AcyxiwgG8m5dpy06R8utwMYQDJkD3wBqJFDw
Message-ID: <291EDFCB1E9E224A99088639C4762022B5988E5297@LONPMAILBOX01.citrite.net>
References: <de5432066adc888a704b.1322836943@cosworth.uk.xensource.com>
	<CAP8mzPPZr_SBkneoO9UzWQ30mHxn+GjrCaHKUYPxkg4WHjz-aA@mail.gmail.com>
In-Reply-To: <CAP8mzPPZr_SBkneoO9UzWQ30mHxn+GjrCaHKUYPxkg4WHjz-aA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] VM generation ID save/restore and migrate
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

De-html-ing to avoid outlook forcing me into a top-post...

-----
From: Shriram Rajagopalan [mailto:rshriram@cs.ubc.ca] 
Sent: 03 December 2011 07:12
To: Paul Durrant
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] VM generation ID save/restore and migrate
[snip]

You might have to rebase the entire patch. 
The compression patch (pushed into staging just before you sent this one)
touches the same diff context that this code does (esp. the SAVE_IDs, 
code in xc_domain_restore, in tools/python/xen/lowlevel/checkpoint/checkpoint.c, etc.)

Assuming that the latest regression in staging/xen-unstable is resolved, I think
most of this code wont apply cleanly.

Shriram
-----

Ok, thanks for the heads-up. I'll sync with staging and re-spin the patch (again).

  Paul

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 09:56:34 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 09:56:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXVHU-000089-3U; Mon, 05 Dec 2011 09:56:16 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RXVHS-00007D-M5
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 09:56:14 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1323078926!6188002!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjAyNg==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28812 invoked from network); 5 Dec 2011 09:55:30 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Dec 2011 09:55:30 -0000
X-IronPort-AV: E=Sophos;i="4.71,298,1320624000"; 
   d="scan'208";a="9284000"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Dec 2011 09:55:26 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.161]) by
	LONPMAILMX01.citrite.net ([10.30.203.162]) with mapi; Mon, 5 Dec 2011
	09:55:26 +0000
From: Paul Durrant <Paul.Durrant@citrix.com>
To: "rshriram@cs.ubc.ca" <rshriram@cs.ubc.ca>
Date: Mon, 5 Dec 2011 09:55:31 +0000
Thread-Topic: [Xen-devel] [PATCH] VM generation ID save/restore and migrate
Thread-Index: AcyxiwgG8m5dpy06R8utwMYQDJkD3wBqJFDw
Message-ID: <291EDFCB1E9E224A99088639C4762022B5988E5297@LONPMAILBOX01.citrite.net>
References: <de5432066adc888a704b.1322836943@cosworth.uk.xensource.com>
	<CAP8mzPPZr_SBkneoO9UzWQ30mHxn+GjrCaHKUYPxkg4WHjz-aA@mail.gmail.com>
In-Reply-To: <CAP8mzPPZr_SBkneoO9UzWQ30mHxn+GjrCaHKUYPxkg4WHjz-aA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] VM generation ID save/restore and migrate
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

De-html-ing to avoid outlook forcing me into a top-post...

-----
From: Shriram Rajagopalan [mailto:rshriram@cs.ubc.ca] 
Sent: 03 December 2011 07:12
To: Paul Durrant
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] VM generation ID save/restore and migrate
[snip]

You might have to rebase the entire patch. 
The compression patch (pushed into staging just before you sent this one)
touches the same diff context that this code does (esp. the SAVE_IDs, 
code in xc_domain_restore, in tools/python/xen/lowlevel/checkpoint/checkpoint.c, etc.)

Assuming that the latest regression in staging/xen-unstable is resolved, I think
most of this code wont apply cleanly.

Shriram
-----

Ok, thanks for the heads-up. I'll sync with staging and re-spin the patch (again).

  Paul

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 09:59:51 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 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.xensource.com>)
	id 1RXVKd-0000NR-Ng; Mon, 05 Dec 2011 09:59:31 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mingo@elte.hu>) id 1RXVKc-0000Mx-Ob
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 09:59:30 +0000
X-Env-Sender: mingo@elte.hu
X-Msg-Ref: server-14.tower-21.messagelabs.com!1323079125!6978425!1
X-Originating-IP: [157.181.1.138]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6700 invoked from network); 5 Dec 2011 09:58:46 -0000
Received: from mx3.mail.elte.hu (HELO mx3.mail.elte.hu) (157.181.1.138)
	by server-14.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Dec 2011 09:58:46 -0000
Received: from elvis.elte.hu ([157.181.1.14])
	by mx3.mail.elte.hu with esmtp (Exim) id 1RXVJg-0001QX-Vl
	from <mingo@elte.hu>; Mon, 05 Dec 2011 10:58:42 +0100
Received: by elvis.elte.hu (Postfix, from userid 1004)
	id 302EE3E25BF; Mon,  5 Dec 2011 10:58:22 +0100 (CET)
Date: Mon, 5 Dec 2011 10:56:39 +0100
From: Ingo Molnar <mingo@elte.hu>
To: Jeremy Fitzhardinge <jeremy@goop.org>
Message-ID: <20111205095639.GC9614@elte.hu>
References: <4EB9D48F.5010201@goop.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4EB9D48F.5010201@goop.org>
User-Agent: Mutt/1.5.21 (2010-09-15)
Received-SPF: neutral (mx3: 157.181.1.14 is neither permitted nor denied by
	domain of elte.hu) client-ip=157.181.1.14;
	envelope-from=mingo@elte.hu; helo=elvis.elte.hu; 
X-ELTE-SpamScore: -2.0
X-ELTE-SpamLevel: 
X-ELTE-SpamCheck: no
X-ELTE-SpamVersion: ELTE 2.0 
X-ELTE-SpamCheck-Details: score=-2.0 required=5.9 tests=AWL,
	BAYES_00 autolearn=no SpamAssassin version=3.3.1
	-2.0 BAYES_00               BODY: Bayes spam probability is 0 to 1%
	[score: 0.0000]
	0.0 AWL AWL: From: address is in the auto white-list
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	the arch/x86 maintainers <x86@kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"H. Peter Anvin" <hpa@zytor.com>
Subject: Re: [Xen-devel] [GIT PULL] More cleanups for atomic memory
	operations/spinlocks
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


* Jeremy Fitzhardinge <jeremy@goop.org> wrote:

> I forgot to push these for the just-closed merge window, but they're
> fine for the next one.  Could you find them a home in tip.git?
> 
> Thanks,
>     J
> 
> The following changes since commit 1ea6b8f48918282bdca0b32a34095504ee65bab5:
> 
>   Linux 3.2-rc1 (2011-11-07 16:16:02 -0800)
> 
> are available in the git repository at:
>   git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git upstream/ticketlock-cleanup
> 
> Jeremy Fitzhardinge (2):
>       x86/cmpxchg: add a locked add() helper
>       x86: consolidate xchg and xadd macros
> 
>  arch/x86/include/asm/cmpxchg.h  |  140 +++++++++++++++++++-------------------
>  arch/x86/include/asm/spinlock.h |   15 +----
>  2 files changed, 71 insertions(+), 84 deletions(-)

Pulled it into x86/asm for testing, thanks Jeremy.

Peter, any objections?

Thanks,

	Ingo

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 09:59:51 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 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.xensource.com>)
	id 1RXVKd-0000NR-Ng; Mon, 05 Dec 2011 09:59:31 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mingo@elte.hu>) id 1RXVKc-0000Mx-Ob
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 09:59:30 +0000
X-Env-Sender: mingo@elte.hu
X-Msg-Ref: server-14.tower-21.messagelabs.com!1323079125!6978425!1
X-Originating-IP: [157.181.1.138]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6700 invoked from network); 5 Dec 2011 09:58:46 -0000
Received: from mx3.mail.elte.hu (HELO mx3.mail.elte.hu) (157.181.1.138)
	by server-14.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Dec 2011 09:58:46 -0000
Received: from elvis.elte.hu ([157.181.1.14])
	by mx3.mail.elte.hu with esmtp (Exim) id 1RXVJg-0001QX-Vl
	from <mingo@elte.hu>; Mon, 05 Dec 2011 10:58:42 +0100
Received: by elvis.elte.hu (Postfix, from userid 1004)
	id 302EE3E25BF; Mon,  5 Dec 2011 10:58:22 +0100 (CET)
Date: Mon, 5 Dec 2011 10:56:39 +0100
From: Ingo Molnar <mingo@elte.hu>
To: Jeremy Fitzhardinge <jeremy@goop.org>
Message-ID: <20111205095639.GC9614@elte.hu>
References: <4EB9D48F.5010201@goop.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4EB9D48F.5010201@goop.org>
User-Agent: Mutt/1.5.21 (2010-09-15)
Received-SPF: neutral (mx3: 157.181.1.14 is neither permitted nor denied by
	domain of elte.hu) client-ip=157.181.1.14;
	envelope-from=mingo@elte.hu; helo=elvis.elte.hu; 
X-ELTE-SpamScore: -2.0
X-ELTE-SpamLevel: 
X-ELTE-SpamCheck: no
X-ELTE-SpamVersion: ELTE 2.0 
X-ELTE-SpamCheck-Details: score=-2.0 required=5.9 tests=AWL,
	BAYES_00 autolearn=no SpamAssassin version=3.3.1
	-2.0 BAYES_00               BODY: Bayes spam probability is 0 to 1%
	[score: 0.0000]
	0.0 AWL AWL: From: address is in the auto white-list
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	the arch/x86 maintainers <x86@kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"H. Peter Anvin" <hpa@zytor.com>
Subject: Re: [Xen-devel] [GIT PULL] More cleanups for atomic memory
	operations/spinlocks
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


* Jeremy Fitzhardinge <jeremy@goop.org> wrote:

> I forgot to push these for the just-closed merge window, but they're
> fine for the next one.  Could you find them a home in tip.git?
> 
> Thanks,
>     J
> 
> The following changes since commit 1ea6b8f48918282bdca0b32a34095504ee65bab5:
> 
>   Linux 3.2-rc1 (2011-11-07 16:16:02 -0800)
> 
> are available in the git repository at:
>   git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git upstream/ticketlock-cleanup
> 
> Jeremy Fitzhardinge (2):
>       x86/cmpxchg: add a locked add() helper
>       x86: consolidate xchg and xadd macros
> 
>  arch/x86/include/asm/cmpxchg.h  |  140 +++++++++++++++++++-------------------
>  arch/x86/include/asm/spinlock.h |   15 +----
>  2 files changed, 71 insertions(+), 84 deletions(-)

Pulled it into x86/asm for testing, thanks Jeremy.

Peter, any objections?

Thanks,

	Ingo

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 10:02:17 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 10: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.xensource.com>)
	id 1RXVN3-0000ba-AB; Mon, 05 Dec 2011 10:02:01 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <hpa@zytor.com>) id 1RXVN1-0000b6-EG
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 10:01:59 +0000
X-Env-Sender: hpa@zytor.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1323079273!5882582!1
X-Originating-IP: [198.137.202.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18339 invoked from network); 5 Dec 2011 10:01:14 -0000
Received: from terminus.zytor.com (HELO mail.zytor.com) (198.137.202.10)
	by server-11.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 5 Dec 2011 10:01:14 -0000
Received: from tazenda.hos.anvin.org ([IPv6:2001:470:861f::feed:face:f00d])
	(authenticated bits=0)
	by mail.zytor.com (8.14.5/8.14.5) with ESMTP id pB5A0oW3010534
	(version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=OK);
	Mon, 5 Dec 2011 02:00:53 -0800
Message-ID: <4EDC964D.1060407@zytor.com>
Date: Mon, 05 Dec 2011 02:00:45 -0800
From: "H. Peter Anvin" <hpa@zytor.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:8.0) Gecko/20111115 Thunderbird/8.0
MIME-Version: 1.0
To: Ingo Molnar <mingo@elte.hu>
References: <4EB9D48F.5010201@goop.org> <20111205095639.GC9614@elte.hu>
In-Reply-To: <20111205095639.GC9614@elte.hu>
X-Enigmail-Version: 1.3.3
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jeremy Fitzhardinge <jeremy@goop.org>,
	the arch/x86 maintainers <x86@kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [GIT PULL] More cleanups for atomic memory
	operations/spinlocks
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 12/05/2011 01:56 AM, Ingo Molnar wrote:
> 
> Pulled it into x86/asm for testing, thanks Jeremy.
> 
> Peter, any objections?
> 

No.  Thank you!

	-hpa


-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 10:02:17 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 10: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.xensource.com>)
	id 1RXVN3-0000ba-AB; Mon, 05 Dec 2011 10:02:01 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <hpa@zytor.com>) id 1RXVN1-0000b6-EG
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 10:01:59 +0000
X-Env-Sender: hpa@zytor.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1323079273!5882582!1
X-Originating-IP: [198.137.202.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18339 invoked from network); 5 Dec 2011 10:01:14 -0000
Received: from terminus.zytor.com (HELO mail.zytor.com) (198.137.202.10)
	by server-11.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 5 Dec 2011 10:01:14 -0000
Received: from tazenda.hos.anvin.org ([IPv6:2001:470:861f::feed:face:f00d])
	(authenticated bits=0)
	by mail.zytor.com (8.14.5/8.14.5) with ESMTP id pB5A0oW3010534
	(version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=OK);
	Mon, 5 Dec 2011 02:00:53 -0800
Message-ID: <4EDC964D.1060407@zytor.com>
Date: Mon, 05 Dec 2011 02:00:45 -0800
From: "H. Peter Anvin" <hpa@zytor.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:8.0) Gecko/20111115 Thunderbird/8.0
MIME-Version: 1.0
To: Ingo Molnar <mingo@elte.hu>
References: <4EB9D48F.5010201@goop.org> <20111205095639.GC9614@elte.hu>
In-Reply-To: <20111205095639.GC9614@elte.hu>
X-Enigmail-Version: 1.3.3
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jeremy Fitzhardinge <jeremy@goop.org>,
	the arch/x86 maintainers <x86@kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [GIT PULL] More cleanups for atomic memory
	operations/spinlocks
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 12/05/2011 01:56 AM, Ingo Molnar wrote:
> 
> Pulled it into x86/asm for testing, thanks Jeremy.
> 
> Peter, any objections?
> 

No.  Thank you!

	-hpa


-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 10:08:36 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 10: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.xensource.com>)
	id 1RXVT4-0000tW-4m; Mon, 05 Dec 2011 10:08:14 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RXVT1-0000tI-OB
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 10:08:12 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1323079645!5883947!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDY0NzA=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14952 invoked from network); 5 Dec 2011 10:07:26 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Dec 2011 10:07:26 -0000
X-IronPort-AV: E=Sophos;i="4.71,298,1320642000"; d="scan'208";a="19656617"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Dec 2011 05:07:24 -0500
Received: from cosworth.uk.xensource.com (10.80.16.52) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 5 Dec 2011 05:07:24 -0500
MIME-Version: 1.0
X-Mercurial-Node: 152a79fbe918d8a6c63ab15a03aebb9d7d305843
Message-ID: <152a79fbe918d8a6c63a.1323079622@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 5 Dec 2011 10:07:02 +0000
From: Paul Durrant <paul.durrant@citrix.com>
To: xen-devel@lists.xensource.com
Cc: paul.durrant@citrix.com
Subject: [Xen-devel] [PATCH] VM generation ID save/restore and migrate
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Paul Durrant <paul.durrant@citrix.com>
# Date 1323079290 0
# Node ID 152a79fbe918d8a6c63ab15a03aebb9d7d305843
# Parent  a4d7c27ec1f190ecbb9a909609f6ef0eca250c00
VM generation ID save/restore and migrate.

Add code to track the address of the VM generation id buffer across a
save/restore or migrate and increment it as necessary.
The address of the buffer is written into xenstore by hvmloader at
boot time. It must be read from xenstore by the caller of
xc_domain_save() and then written back again by the caller of
xc_domain_restore().

Signed-off-by: Paul Durrant <paul.durrant@citrix.com>

diff -r a4d7c27ec1f1 -r 152a79fbe918 tools/libxc/ia64/xc_ia64_linux_restore.c
--- a/tools/libxc/ia64/xc_ia64_linux_restore.c	Fri Dec 02 13:51:17 2011 -0800
+++ b/tools/libxc/ia64/xc_ia64_linux_restore.c	Mon Dec 05 10:01:30 2011 +0000
@@ -548,7 +548,8 @@ int
 xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
                   unsigned int store_evtchn, unsigned long *store_mfn,
                   unsigned int console_evtchn, unsigned long *console_mfn,
-                  unsigned int hvm, unsigned int pae, int superpages)
+                  unsigned int hvm, unsigned int pae, int superpages,
+                  int increment_gid, unsigned long *vm_gid_addr)
 {
     DECLARE_DOMCTL;
     int rc = 1;
diff -r a4d7c27ec1f1 -r 152a79fbe918 tools/libxc/ia64/xc_ia64_linux_save.c
--- a/tools/libxc/ia64/xc_ia64_linux_save.c	Fri Dec 02 13:51:17 2011 -0800
+++ b/tools/libxc/ia64/xc_ia64_linux_save.c	Mon Dec 05 10:01:30 2011 +0000
@@ -382,7 +382,8 @@ out:
 int
 xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iters,
                uint32_t max_factor, uint32_t flags,
-               struct save_callbacks* callbacks, int hvm)
+               struct save_callbacks* callbacks, int hvm,
+               unsigned long vm_gid_addr)
 {
     DECLARE_DOMCTL;
     xc_dominfo_t info;
diff -r a4d7c27ec1f1 -r 152a79fbe918 tools/libxc/xc_domain_restore.c
--- a/tools/libxc/xc_domain_restore.c	Fri Dec 02 13:51:17 2011 -0800
+++ b/tools/libxc/xc_domain_restore.c	Mon Dec 05 10:01:30 2011 +0000
@@ -681,6 +681,7 @@ typedef struct {
     uint64_t console_pfn;
     uint64_t acpi_ioport_location;
     uint64_t viridian;
+    uint64_t vm_gid_addr;
 } pagebuf_t;
 
 static int pagebuf_init(pagebuf_t* buf)
@@ -860,6 +861,17 @@ static int pagebuf_get_one(xc_interface 
         }
         return compbuf_size;
 
+    case XC_SAVE_ID_HVM_GENERATION_ID_ADDR:
+        /* Skip padding 4 bytes then read the generation id buffer location. */
+        if ( RDEXACT(fd, &buf->vm_gid_addr, sizeof(uint32_t)) ||
+             RDEXACT(fd, &buf->vm_gid_addr, sizeof(uint64_t)) )
+        {
+            PERROR("error read the generation id buffer location");
+            return -1;
+        }
+        DPRINTF("read generation id buffer address");
+        return pagebuf_get_one(xch, ctx, buf, fd, dom);
+
     default:
         if ( (count > MAX_BATCH_SIZE) || (count < 0) ) {
             ERROR("Max batch size exceeded (%d). Giving up.", count);
@@ -1248,7 +1260,8 @@ static int apply_batch(xc_interface *xch
 int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
                       unsigned int store_evtchn, unsigned long *store_mfn,
                       unsigned int console_evtchn, unsigned long *console_mfn,
-                      unsigned int hvm, unsigned int pae, int superpages)
+                      unsigned int hvm, unsigned int pae, int superpages,
+                      int no_increment_gid, unsigned long *vm_gid_addr)
 {
     DECLARE_DOMCTL;
     int rc = 1, frc, i, j, n, m, pae_extended_cr3 = 0, ext_vcpucontext = 0;
@@ -1449,6 +1462,39 @@ int xc_domain_restore(xc_interface *xch,
                 xc_set_hvm_param(xch, dom, HVM_PARAM_VM86_TSS, pagebuf.vm86_tss);
             if ( pagebuf.console_pfn )
                 console_pfn = pagebuf.console_pfn;
+            if ( pagebuf.vm_gid_addr ) {
+                if ( !no_increment_gid ) {
+                    unsigned int offset;
+                    unsigned char *buf;
+                    unsigned long long gid;
+
+                    /*
+                     * Map the VM generation id buffer and inject the new value.
+                     */
+
+                    pfn = pagebuf.vm_gid_addr >> PAGE_SHIFT;
+                    offset = pagebuf.vm_gid_addr & (PAGE_SIZE - 1);
+                
+                    if ( (pfn >= dinfo->p2m_size) ||
+                         (pfn_type[pfn] != XEN_DOMCTL_PFINFO_NOTAB) )
+                    {
+                        ERROR("generation id buffer frame is bad");
+                        goto out;
+                    }
+
+                    mfn = ctx->p2m[pfn];
+                    buf = xc_map_foreign_range(xch, dom, PAGE_SIZE,
+                                               PROT_READ | PROT_WRITE, mfn);
+
+                    gid = *(unsigned long long *)(buf + offset);
+                    *(unsigned long long *)(buf + offset) = gid + 1;
+
+                    munmap(buf, PAGE_SIZE);
+                }
+
+                *vm_gid_addr = pagebuf.vm_gid_addr;
+            }
+
             break;  /* our work here is done */
         }
 
diff -r a4d7c27ec1f1 -r 152a79fbe918 tools/libxc/xc_domain_save.c
--- a/tools/libxc/xc_domain_save.c	Fri Dec 02 13:51:17 2011 -0800
+++ b/tools/libxc/xc_domain_save.c	Mon Dec 05 10:01:30 2011 +0000
@@ -804,7 +804,8 @@ static int save_tsc_info(xc_interface *x
 
 int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iters,
                    uint32_t max_factor, uint32_t flags,
-                   struct save_callbacks* callbacks, int hvm)
+                   struct save_callbacks* callbacks, int hvm,
+                   unsigned long vm_gid_addr)
 {
     xc_dominfo_t info;
     DECLARE_DOMCTL;
@@ -1616,6 +1617,16 @@ int xc_domain_save(xc_interface *xch, in
             uint64_t data;
         } chunk = { 0, };
 
+        chunk.id = XC_SAVE_ID_HVM_GENERATION_ID_ADDR;
+        chunk.data = vm_gid_addr;
+
+        if ( (chunk.data != 0) &&
+             wrexact(io_fd, &chunk, sizeof(chunk)) )
+        {
+            PERROR("Error when writing the generation id buffer location for guest");
+            goto out;
+        }
+
         chunk.id = XC_SAVE_ID_HVM_IDENT_PT;
         chunk.data = 0;
         xc_get_hvm_param(xch, dom, HVM_PARAM_IDENT_PT,
diff -r a4d7c27ec1f1 -r 152a79fbe918 tools/libxc/xenguest.h
--- a/tools/libxc/xenguest.h	Fri Dec 02 13:51:17 2011 -0800
+++ b/tools/libxc/xenguest.h	Mon Dec 05 10:01:30 2011 +0000
@@ -58,7 +58,8 @@ struct save_callbacks {
  */
 int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iters,
                    uint32_t max_factor, uint32_t flags /* XCFLAGS_xxx */,
-                   struct save_callbacks* callbacks, int hvm);
+                   struct save_callbacks* callbacks, int hvm,
+                   unsigned long vm_gid_addr);
 
 
 /**
@@ -72,12 +73,15 @@ int xc_domain_save(xc_interface *xch, in
  * @parm hvm non-zero if this is a HVM restore
  * @parm pae non-zero if this HVM domain has PAE support enabled
  * @parm superpages non-zero to allocate guest memory with superpages
+ * @parm gid the new generation id of the VM
+ * @parm vm_gid_addr returned with the address of the generation id buffer
  * @return 0 on success, -1 on failure
  */
 int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
                       unsigned int store_evtchn, unsigned long *store_mfn,
                       unsigned int console_evtchn, unsigned long *console_mfn,
-                      unsigned int hvm, unsigned int pae, int superpages);
+                      unsigned int hvm, unsigned int pae, int superpages,
+                      int increment_gid, unsigned long *vm_gid_addr);
 /**
  * xc_domain_restore writes a file to disk that contains the device
  * model saved state.
diff -r a4d7c27ec1f1 -r 152a79fbe918 tools/libxc/xg_save_restore.h
--- a/tools/libxc/xg_save_restore.h	Fri Dec 02 13:51:17 2011 -0800
+++ b/tools/libxc/xg_save_restore.h	Mon Dec 05 10:01:30 2011 +0000
@@ -253,6 +253,7 @@
 #define XC_SAVE_ID_HVM_VIRIDIAN       -11
 #define XC_SAVE_ID_COMPRESSED_DATA    -12 /* Marker to indicate arrival of compressed data */
 #define XC_SAVE_ID_ENABLE_COMPRESSION -13 /* Marker to enable compression logic at receiver side */
+#define XC_SAVE_ID_HVM_GENERATION_ID_ADDR -14
 
 /*
 ** We process save/restore/migrate in batches of pages; the below
diff -r a4d7c27ec1f1 -r 152a79fbe918 tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Fri Dec 02 13:51:17 2011 -0800
+++ b/tools/libxl/libxl_create.c	Mon Dec 05 10:01:30 2011 +0000
@@ -101,6 +101,7 @@ int libxl_init_build_info(libxl_ctx *ctx
         b_info->u.hvm.vpt_align = 1;
         b_info->u.hvm.timer_mode = 1;
         b_info->u.hvm.nested_hvm = 0;
+        b_info->u.hvm.no_increment_gid = 0;
         break;
     case LIBXL_DOMAIN_TYPE_PV:
         b_info->u.pv.slack_memkb = 8 * 1024;
diff -r a4d7c27ec1f1 -r 152a79fbe918 tools/libxl/libxl_dom.c
--- a/tools/libxl/libxl_dom.c	Fri Dec 02 13:51:17 2011 -0800
+++ b/tools/libxl/libxl_dom.c	Mon Dec 05 10:01:30 2011 +0000
@@ -125,7 +125,7 @@ int libxl__build_post(libxl__gc *gc, uin
     if (info->cpuid != NULL)
         libxl_cpuid_set(ctx, domid, info->cpuid);
 
-    ents = libxl__calloc(gc, 12 + (info->max_vcpus * 2) + 2, sizeof(char *));
+    ents = libxl__calloc(gc, 14 + (info->max_vcpus * 2) + 2, sizeof(char *));
     ents[0] = "memory/static-max";
     ents[1] = libxl__sprintf(gc, "%d", info->max_memkb);
     ents[2] = "memory/target";
@@ -138,9 +138,11 @@ int libxl__build_post(libxl__gc *gc, uin
     ents[9] = libxl__sprintf(gc, "%"PRIu32, state->store_port);
     ents[10] = "store/ring-ref";
     ents[11] = libxl__sprintf(gc, "%lu", state->store_mfn);
+    ents[12] = "data/generation-id";
+    ents[13] = libxl__sprintf(gc, "0x%lx", state->vm_gid_addr);
     for (i = 0; i < info->max_vcpus; i++) {
-        ents[12+(i*2)]   = libxl__sprintf(gc, "cpu/%d/availability", i);
-        ents[12+(i*2)+1] = (i && info->cur_vcpus && !(info->cur_vcpus & (1 << i)))
+        ents[14+(i*2)]   = libxl__sprintf(gc, "cpu/%d/availability", i);
+        ents[14+(i*2)+1] = (i && info->cur_vcpus && !(info->cur_vcpus & (1 << i)))
                             ? "offline" : "online";
     }
 
@@ -357,16 +359,19 @@ int libxl__domain_restore_common(libxl__
     /* read signature */
     int rc;
     int hvm, pae, superpages;
+    int no_increment_gid;
     switch (info->type) {
     case LIBXL_DOMAIN_TYPE_HVM:
         hvm = 1;
         superpages = 1;
         pae = info->u.hvm.pae;
+        no_increment_gid = info->u.hvm.no_increment_gid;
         break;
     case LIBXL_DOMAIN_TYPE_PV:
         hvm = 0;
         superpages = 0;
         pae = 1;
+        no_increment_gid = 0;
         break;
     default:
         return ERROR_INVAL;
@@ -374,7 +379,7 @@ int libxl__domain_restore_common(libxl__
     rc = xc_domain_restore(ctx->xch, fd, domid,
                            state->store_port, &state->store_mfn,
                            state->console_port, &state->console_mfn,
-                           hvm, pae, superpages);
+                           hvm, pae, superpages, no_increment_gid, &state->vm_gid_addr);
     if ( rc ) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "restoring domain");
         return ERROR_FAIL;
@@ -540,12 +545,22 @@ int libxl__domain_suspend_common(libxl__
     struct save_callbacks callbacks;
     struct suspendinfo si;
     int hvm, rc = ERROR_FAIL;
+    unsigned long vm_gid_addr;
 
     switch (type) {
-    case LIBXL_DOMAIN_TYPE_HVM:
+    case LIBXL_DOMAIN_TYPE_HVM: {
+        char *path;
+        char *addr;
+
+        path = libxl__sprintf(gc, "%s/data/generation-id", libxl__xs_get_dompath(gc, domid));
+        addr = libxl__xs_read(gc, XBT_NULL, path);
+
+        vm_gid_addr = (addr) ? strtoul(addr, NULL, 0) : 0;
         hvm = 1;
         break;
+    }
     case LIBXL_DOMAIN_TYPE_PV:
+        vm_gid_addr = 0;
         hvm = 0;
         break;
     default:
@@ -583,7 +598,8 @@ int libxl__domain_suspend_common(libxl__
     callbacks.switch_qemu_logdirty = libxl__domain_suspend_common_switch_qemu_logdirty;
     callbacks.data = &si;
 
-    rc = xc_domain_save(ctx->xch, fd, domid, 0, 0, flags, &callbacks, hvm);
+    rc = xc_domain_save(ctx->xch, fd, domid, 0, 0, flags, &callbacks,
+                        hvm, vm_gid_addr);
     if ( rc ) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "saving domain: %s",
                          si.guest_responded ?
diff -r a4d7c27ec1f1 -r 152a79fbe918 tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Fri Dec 02 13:51:17 2011 -0800
+++ b/tools/libxl/libxl_internal.h	Mon Dec 05 10:01:30 2011 +0000
@@ -199,6 +199,7 @@ typedef struct {
 
     uint32_t console_port;
     unsigned long console_mfn;
+    unsigned long vm_gid_addr;
 } libxl__domain_build_state;
 
 _hidden int libxl__build_pre(libxl__gc *gc, uint32_t domid,
diff -r a4d7c27ec1f1 -r 152a79fbe918 tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Fri Dec 02 13:51:17 2011 -0800
+++ b/tools/libxl/libxl_types.idl	Mon Dec 05 10:01:30 2011 +0000
@@ -184,6 +184,7 @@ libxl_domain_build_info = Struct("domain
                                        ("vpt_align", bool),
                                        ("timer_mode", integer),
                                        ("nested_hvm", bool),
+                                       ("no_increment_gid", bool),
                                        ])),
                  ("pv", Struct(None, [("kernel", libxl_file_reference),
                                       ("slack_memkb", uint32),
diff -r a4d7c27ec1f1 -r 152a79fbe918 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Fri Dec 02 13:51:17 2011 -0800
+++ b/tools/libxl/xl_cmdimpl.c	Mon Dec 05 10:01:30 2011 +0000
@@ -360,6 +360,7 @@ static void printf_info(int domid,
         printf("\t\t\t(vpt_align %d)\n", b_info->u.hvm.vpt_align);
         printf("\t\t\t(timer_mode %d)\n", b_info->u.hvm.timer_mode);
         printf("\t\t\t(nestedhvm %d)\n", b_info->u.hvm.nested_hvm);
+        printf("\t\t\t(no_increment_gid %d)\n", b_info->u.hvm.no_increment_gid);
 
         printf("\t\t\t(device_model %s)\n", dm_info->device_model ? : "default");
         printf("\t\t\t(videoram %d)\n", dm_info->videoram);
@@ -1362,6 +1363,7 @@ struct domain_create {
     const char *restore_file;
     int migrate_fd; /* -1 means none */
     char **migration_domname_r; /* from malloc */
+    int no_increment_gid;
 };
 
 static int freemem(libxl_domain_build_info *b_info, libxl_device_model_info *dm_info)
@@ -1575,6 +1577,8 @@ static int create_domain(struct domain_c
         }
     }
 
+    d_config.b_info.u.hvm.no_increment_gid = dom_info->no_increment_gid;
+
     if (debug || dom_info->dryrun)
         printf_info(-1, &d_config, &d_config.dm_info);
 
@@ -2800,6 +2804,7 @@ static void migrate_receive(int debug, i
     dom_info.restore_file = "incoming migration stream";
     dom_info.migrate_fd = 0; /* stdin */
     dom_info.migration_domname_r = &migration_domname;
+    dom_info.no_increment_gid = 1;
 
     rc = create_domain(&dom_info);
     if (rc < 0) {
diff -r a4d7c27ec1f1 -r 152a79fbe918 tools/python/xen/lowlevel/checkpoint/libcheckpoint.c
--- a/tools/python/xen/lowlevel/checkpoint/libcheckpoint.c	Fri Dec 02 13:51:17 2011 -0800
+++ b/tools/python/xen/lowlevel/checkpoint/libcheckpoint.c	Mon Dec 05 10:01:30 2011 +0000
@@ -175,6 +175,7 @@ int checkpoint_start(checkpoint_state* s
 {
     int hvm, rc;
     int flags = XCFLAGS_LIVE;
+    unsigned long vm_gid_addr;
 
     if (!s->domid) {
        s->errstr = "checkpoint state not opened";
@@ -185,16 +186,27 @@ int checkpoint_start(checkpoint_state* s
 
     hvm = s->domtype > dt_pv;
     if (hvm) {
+       char path[128];
+       char *addr;
+
+       sprintf(path, "/local/domain/%u/data/generation-id", s->domid);
+       addr = xs_read(s->xsh, XBT_NULL, path, NULL);
+
+       vm_gid_addr = (addr) ? strtoul(addr, NULL, 0) : 0;
+       free(addr);
+
        flags |= XCFLAGS_HVM;
        if (switch_qemu_logdirty(s, 1))
            return -1;
+    } else {
+       vm_gid_addr = 0;
     }
     if (remus_flags & CHECKPOINT_FLAGS_COMPRESSION)
       flags |= XCFLAGS_CHECKPOINT_COMPRESS;
 
     callbacks->switch_qemu_logdirty = noop_switch_logdirty;
 
-    rc = xc_domain_save(s->xch, fd, s->domid, 0, 0, flags, callbacks, hvm);
+    rc = xc_domain_save(s->xch, fd, s->domid, 0, 0, flags, callbacks, hvm, vm_gid_addr);
 
     if (hvm)
        switch_qemu_logdirty(s, 0);
diff -r a4d7c27ec1f1 -r 152a79fbe918 tools/xcutils/xc_restore.c
--- a/tools/xcutils/xc_restore.c	Fri Dec 02 13:51:17 2011 -0800
+++ b/tools/xcutils/xc_restore.c	Mon Dec 05 10:01:30 2011 +0000
@@ -23,7 +23,8 @@ main(int argc, char **argv)
     xc_interface *xch;
     int io_fd, ret;
     int superpages;
-    unsigned long store_mfn, console_mfn;
+    unsigned long store_mfn, console_mfn, vm_gid_addr;
+    int no_increment_gid;
 
     if ( (argc != 8) && (argc != 9) )
         errx(1, "usage: %s iofd domid store_evtchn "
@@ -40,19 +41,25 @@ main(int argc, char **argv)
     hvm  = atoi(argv[5]);
     pae  = atoi(argv[6]);
     apic = atoi(argv[7]);
-    if ( argc == 9 )
+    if ( argc >= 9 )
 	    superpages = atoi(argv[8]);
     else
 	    superpages = !!hvm;
+    if ( argc >= 10 )
+	    no_increment_gid = !atoi(argv[9]);
+    else
+	    no_increment_gid = 0;
 
     ret = xc_domain_restore(xch, io_fd, domid, store_evtchn, &store_mfn,
-                            console_evtchn, &console_mfn, hvm, pae, superpages);
+                            console_evtchn, &console_mfn, hvm, pae, superpages,
+                            no_increment_gid, &vm_gid_addr);
 
     if ( ret == 0 )
     {
 	printf("store-mfn %li\n", store_mfn);
         if ( !hvm )
             printf("console-mfn %li\n", console_mfn);
+	printf("vm-gid-addr %lx\n", vm_gid_addr);
 	fflush(stdout);
     }
 
diff -r a4d7c27ec1f1 -r 152a79fbe918 tools/xcutils/xc_save.c
--- a/tools/xcutils/xc_save.c	Fri Dec 02 13:51:17 2011 -0800
+++ b/tools/xcutils/xc_save.c	Mon Dec 05 10:01:30 2011 +0000
@@ -169,6 +169,10 @@ main(int argc, char **argv)
     unsigned int maxit, max_f;
     int io_fd, ret, port;
     struct save_callbacks callbacks;
+    char path[128];
+    struct xs_handle *xs;
+    char *addr;
+    unsigned long vm_gid_addr;
 
     if (argc != 6)
         errx(1, "usage: %s iofd domid maxit maxf flags", argv[0]);
@@ -207,8 +211,21 @@ main(int argc, char **argv)
     memset(&callbacks, 0, sizeof(callbacks));
     callbacks.suspend = suspend;
     callbacks.switch_qemu_logdirty = switch_qemu_logdirty;
+
+    sprintf(path, "/local/domain/%d/data/generation-id", si.domid);
+
+    if ((xs = xs_daemon_open()) == NULL)
+        errx(1, "Couldn't contact xenstore");
+
+    addr = xs_read(xs, XBT_NULL, path, NULL);
+
+    xs_daemon_close(xs);
+
+    vm_gid_addr = (addr) ? strtoul(addr, NULL, 0) : 0;
+    free(addr);
+
     ret = xc_domain_save(si.xch, io_fd, si.domid, maxit, max_f, si.flags, 
-                         &callbacks, !!(si.flags & XCFLAGS_HVM));
+                         &callbacks, !!(si.flags & XCFLAGS_HVM), vm_gid_addr);
 
     if (si.suspend_evtchn > 0)
 	 xc_suspend_evtchn_release(si.xch, si.xce, si.domid, si.suspend_evtchn);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 10:08:36 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 10: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.xensource.com>)
	id 1RXVT4-0000tW-4m; Mon, 05 Dec 2011 10:08:14 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RXVT1-0000tI-OB
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 10:08:12 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1323079645!5883947!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDY0NzA=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14952 invoked from network); 5 Dec 2011 10:07:26 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Dec 2011 10:07:26 -0000
X-IronPort-AV: E=Sophos;i="4.71,298,1320642000"; d="scan'208";a="19656617"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Dec 2011 05:07:24 -0500
Received: from cosworth.uk.xensource.com (10.80.16.52) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 5 Dec 2011 05:07:24 -0500
MIME-Version: 1.0
X-Mercurial-Node: 152a79fbe918d8a6c63ab15a03aebb9d7d305843
Message-ID: <152a79fbe918d8a6c63a.1323079622@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 5 Dec 2011 10:07:02 +0000
From: Paul Durrant <paul.durrant@citrix.com>
To: xen-devel@lists.xensource.com
Cc: paul.durrant@citrix.com
Subject: [Xen-devel] [PATCH] VM generation ID save/restore and migrate
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Paul Durrant <paul.durrant@citrix.com>
# Date 1323079290 0
# Node ID 152a79fbe918d8a6c63ab15a03aebb9d7d305843
# Parent  a4d7c27ec1f190ecbb9a909609f6ef0eca250c00
VM generation ID save/restore and migrate.

Add code to track the address of the VM generation id buffer across a
save/restore or migrate and increment it as necessary.
The address of the buffer is written into xenstore by hvmloader at
boot time. It must be read from xenstore by the caller of
xc_domain_save() and then written back again by the caller of
xc_domain_restore().

Signed-off-by: Paul Durrant <paul.durrant@citrix.com>

diff -r a4d7c27ec1f1 -r 152a79fbe918 tools/libxc/ia64/xc_ia64_linux_restore.c
--- a/tools/libxc/ia64/xc_ia64_linux_restore.c	Fri Dec 02 13:51:17 2011 -0800
+++ b/tools/libxc/ia64/xc_ia64_linux_restore.c	Mon Dec 05 10:01:30 2011 +0000
@@ -548,7 +548,8 @@ int
 xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
                   unsigned int store_evtchn, unsigned long *store_mfn,
                   unsigned int console_evtchn, unsigned long *console_mfn,
-                  unsigned int hvm, unsigned int pae, int superpages)
+                  unsigned int hvm, unsigned int pae, int superpages,
+                  int increment_gid, unsigned long *vm_gid_addr)
 {
     DECLARE_DOMCTL;
     int rc = 1;
diff -r a4d7c27ec1f1 -r 152a79fbe918 tools/libxc/ia64/xc_ia64_linux_save.c
--- a/tools/libxc/ia64/xc_ia64_linux_save.c	Fri Dec 02 13:51:17 2011 -0800
+++ b/tools/libxc/ia64/xc_ia64_linux_save.c	Mon Dec 05 10:01:30 2011 +0000
@@ -382,7 +382,8 @@ out:
 int
 xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iters,
                uint32_t max_factor, uint32_t flags,
-               struct save_callbacks* callbacks, int hvm)
+               struct save_callbacks* callbacks, int hvm,
+               unsigned long vm_gid_addr)
 {
     DECLARE_DOMCTL;
     xc_dominfo_t info;
diff -r a4d7c27ec1f1 -r 152a79fbe918 tools/libxc/xc_domain_restore.c
--- a/tools/libxc/xc_domain_restore.c	Fri Dec 02 13:51:17 2011 -0800
+++ b/tools/libxc/xc_domain_restore.c	Mon Dec 05 10:01:30 2011 +0000
@@ -681,6 +681,7 @@ typedef struct {
     uint64_t console_pfn;
     uint64_t acpi_ioport_location;
     uint64_t viridian;
+    uint64_t vm_gid_addr;
 } pagebuf_t;
 
 static int pagebuf_init(pagebuf_t* buf)
@@ -860,6 +861,17 @@ static int pagebuf_get_one(xc_interface 
         }
         return compbuf_size;
 
+    case XC_SAVE_ID_HVM_GENERATION_ID_ADDR:
+        /* Skip padding 4 bytes then read the generation id buffer location. */
+        if ( RDEXACT(fd, &buf->vm_gid_addr, sizeof(uint32_t)) ||
+             RDEXACT(fd, &buf->vm_gid_addr, sizeof(uint64_t)) )
+        {
+            PERROR("error read the generation id buffer location");
+            return -1;
+        }
+        DPRINTF("read generation id buffer address");
+        return pagebuf_get_one(xch, ctx, buf, fd, dom);
+
     default:
         if ( (count > MAX_BATCH_SIZE) || (count < 0) ) {
             ERROR("Max batch size exceeded (%d). Giving up.", count);
@@ -1248,7 +1260,8 @@ static int apply_batch(xc_interface *xch
 int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
                       unsigned int store_evtchn, unsigned long *store_mfn,
                       unsigned int console_evtchn, unsigned long *console_mfn,
-                      unsigned int hvm, unsigned int pae, int superpages)
+                      unsigned int hvm, unsigned int pae, int superpages,
+                      int no_increment_gid, unsigned long *vm_gid_addr)
 {
     DECLARE_DOMCTL;
     int rc = 1, frc, i, j, n, m, pae_extended_cr3 = 0, ext_vcpucontext = 0;
@@ -1449,6 +1462,39 @@ int xc_domain_restore(xc_interface *xch,
                 xc_set_hvm_param(xch, dom, HVM_PARAM_VM86_TSS, pagebuf.vm86_tss);
             if ( pagebuf.console_pfn )
                 console_pfn = pagebuf.console_pfn;
+            if ( pagebuf.vm_gid_addr ) {
+                if ( !no_increment_gid ) {
+                    unsigned int offset;
+                    unsigned char *buf;
+                    unsigned long long gid;
+
+                    /*
+                     * Map the VM generation id buffer and inject the new value.
+                     */
+
+                    pfn = pagebuf.vm_gid_addr >> PAGE_SHIFT;
+                    offset = pagebuf.vm_gid_addr & (PAGE_SIZE - 1);
+                
+                    if ( (pfn >= dinfo->p2m_size) ||
+                         (pfn_type[pfn] != XEN_DOMCTL_PFINFO_NOTAB) )
+                    {
+                        ERROR("generation id buffer frame is bad");
+                        goto out;
+                    }
+
+                    mfn = ctx->p2m[pfn];
+                    buf = xc_map_foreign_range(xch, dom, PAGE_SIZE,
+                                               PROT_READ | PROT_WRITE, mfn);
+
+                    gid = *(unsigned long long *)(buf + offset);
+                    *(unsigned long long *)(buf + offset) = gid + 1;
+
+                    munmap(buf, PAGE_SIZE);
+                }
+
+                *vm_gid_addr = pagebuf.vm_gid_addr;
+            }
+
             break;  /* our work here is done */
         }
 
diff -r a4d7c27ec1f1 -r 152a79fbe918 tools/libxc/xc_domain_save.c
--- a/tools/libxc/xc_domain_save.c	Fri Dec 02 13:51:17 2011 -0800
+++ b/tools/libxc/xc_domain_save.c	Mon Dec 05 10:01:30 2011 +0000
@@ -804,7 +804,8 @@ static int save_tsc_info(xc_interface *x
 
 int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iters,
                    uint32_t max_factor, uint32_t flags,
-                   struct save_callbacks* callbacks, int hvm)
+                   struct save_callbacks* callbacks, int hvm,
+                   unsigned long vm_gid_addr)
 {
     xc_dominfo_t info;
     DECLARE_DOMCTL;
@@ -1616,6 +1617,16 @@ int xc_domain_save(xc_interface *xch, in
             uint64_t data;
         } chunk = { 0, };
 
+        chunk.id = XC_SAVE_ID_HVM_GENERATION_ID_ADDR;
+        chunk.data = vm_gid_addr;
+
+        if ( (chunk.data != 0) &&
+             wrexact(io_fd, &chunk, sizeof(chunk)) )
+        {
+            PERROR("Error when writing the generation id buffer location for guest");
+            goto out;
+        }
+
         chunk.id = XC_SAVE_ID_HVM_IDENT_PT;
         chunk.data = 0;
         xc_get_hvm_param(xch, dom, HVM_PARAM_IDENT_PT,
diff -r a4d7c27ec1f1 -r 152a79fbe918 tools/libxc/xenguest.h
--- a/tools/libxc/xenguest.h	Fri Dec 02 13:51:17 2011 -0800
+++ b/tools/libxc/xenguest.h	Mon Dec 05 10:01:30 2011 +0000
@@ -58,7 +58,8 @@ struct save_callbacks {
  */
 int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iters,
                    uint32_t max_factor, uint32_t flags /* XCFLAGS_xxx */,
-                   struct save_callbacks* callbacks, int hvm);
+                   struct save_callbacks* callbacks, int hvm,
+                   unsigned long vm_gid_addr);
 
 
 /**
@@ -72,12 +73,15 @@ int xc_domain_save(xc_interface *xch, in
  * @parm hvm non-zero if this is a HVM restore
  * @parm pae non-zero if this HVM domain has PAE support enabled
  * @parm superpages non-zero to allocate guest memory with superpages
+ * @parm gid the new generation id of the VM
+ * @parm vm_gid_addr returned with the address of the generation id buffer
  * @return 0 on success, -1 on failure
  */
 int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
                       unsigned int store_evtchn, unsigned long *store_mfn,
                       unsigned int console_evtchn, unsigned long *console_mfn,
-                      unsigned int hvm, unsigned int pae, int superpages);
+                      unsigned int hvm, unsigned int pae, int superpages,
+                      int increment_gid, unsigned long *vm_gid_addr);
 /**
  * xc_domain_restore writes a file to disk that contains the device
  * model saved state.
diff -r a4d7c27ec1f1 -r 152a79fbe918 tools/libxc/xg_save_restore.h
--- a/tools/libxc/xg_save_restore.h	Fri Dec 02 13:51:17 2011 -0800
+++ b/tools/libxc/xg_save_restore.h	Mon Dec 05 10:01:30 2011 +0000
@@ -253,6 +253,7 @@
 #define XC_SAVE_ID_HVM_VIRIDIAN       -11
 #define XC_SAVE_ID_COMPRESSED_DATA    -12 /* Marker to indicate arrival of compressed data */
 #define XC_SAVE_ID_ENABLE_COMPRESSION -13 /* Marker to enable compression logic at receiver side */
+#define XC_SAVE_ID_HVM_GENERATION_ID_ADDR -14
 
 /*
 ** We process save/restore/migrate in batches of pages; the below
diff -r a4d7c27ec1f1 -r 152a79fbe918 tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Fri Dec 02 13:51:17 2011 -0800
+++ b/tools/libxl/libxl_create.c	Mon Dec 05 10:01:30 2011 +0000
@@ -101,6 +101,7 @@ int libxl_init_build_info(libxl_ctx *ctx
         b_info->u.hvm.vpt_align = 1;
         b_info->u.hvm.timer_mode = 1;
         b_info->u.hvm.nested_hvm = 0;
+        b_info->u.hvm.no_increment_gid = 0;
         break;
     case LIBXL_DOMAIN_TYPE_PV:
         b_info->u.pv.slack_memkb = 8 * 1024;
diff -r a4d7c27ec1f1 -r 152a79fbe918 tools/libxl/libxl_dom.c
--- a/tools/libxl/libxl_dom.c	Fri Dec 02 13:51:17 2011 -0800
+++ b/tools/libxl/libxl_dom.c	Mon Dec 05 10:01:30 2011 +0000
@@ -125,7 +125,7 @@ int libxl__build_post(libxl__gc *gc, uin
     if (info->cpuid != NULL)
         libxl_cpuid_set(ctx, domid, info->cpuid);
 
-    ents = libxl__calloc(gc, 12 + (info->max_vcpus * 2) + 2, sizeof(char *));
+    ents = libxl__calloc(gc, 14 + (info->max_vcpus * 2) + 2, sizeof(char *));
     ents[0] = "memory/static-max";
     ents[1] = libxl__sprintf(gc, "%d", info->max_memkb);
     ents[2] = "memory/target";
@@ -138,9 +138,11 @@ int libxl__build_post(libxl__gc *gc, uin
     ents[9] = libxl__sprintf(gc, "%"PRIu32, state->store_port);
     ents[10] = "store/ring-ref";
     ents[11] = libxl__sprintf(gc, "%lu", state->store_mfn);
+    ents[12] = "data/generation-id";
+    ents[13] = libxl__sprintf(gc, "0x%lx", state->vm_gid_addr);
     for (i = 0; i < info->max_vcpus; i++) {
-        ents[12+(i*2)]   = libxl__sprintf(gc, "cpu/%d/availability", i);
-        ents[12+(i*2)+1] = (i && info->cur_vcpus && !(info->cur_vcpus & (1 << i)))
+        ents[14+(i*2)]   = libxl__sprintf(gc, "cpu/%d/availability", i);
+        ents[14+(i*2)+1] = (i && info->cur_vcpus && !(info->cur_vcpus & (1 << i)))
                             ? "offline" : "online";
     }
 
@@ -357,16 +359,19 @@ int libxl__domain_restore_common(libxl__
     /* read signature */
     int rc;
     int hvm, pae, superpages;
+    int no_increment_gid;
     switch (info->type) {
     case LIBXL_DOMAIN_TYPE_HVM:
         hvm = 1;
         superpages = 1;
         pae = info->u.hvm.pae;
+        no_increment_gid = info->u.hvm.no_increment_gid;
         break;
     case LIBXL_DOMAIN_TYPE_PV:
         hvm = 0;
         superpages = 0;
         pae = 1;
+        no_increment_gid = 0;
         break;
     default:
         return ERROR_INVAL;
@@ -374,7 +379,7 @@ int libxl__domain_restore_common(libxl__
     rc = xc_domain_restore(ctx->xch, fd, domid,
                            state->store_port, &state->store_mfn,
                            state->console_port, &state->console_mfn,
-                           hvm, pae, superpages);
+                           hvm, pae, superpages, no_increment_gid, &state->vm_gid_addr);
     if ( rc ) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "restoring domain");
         return ERROR_FAIL;
@@ -540,12 +545,22 @@ int libxl__domain_suspend_common(libxl__
     struct save_callbacks callbacks;
     struct suspendinfo si;
     int hvm, rc = ERROR_FAIL;
+    unsigned long vm_gid_addr;
 
     switch (type) {
-    case LIBXL_DOMAIN_TYPE_HVM:
+    case LIBXL_DOMAIN_TYPE_HVM: {
+        char *path;
+        char *addr;
+
+        path = libxl__sprintf(gc, "%s/data/generation-id", libxl__xs_get_dompath(gc, domid));
+        addr = libxl__xs_read(gc, XBT_NULL, path);
+
+        vm_gid_addr = (addr) ? strtoul(addr, NULL, 0) : 0;
         hvm = 1;
         break;
+    }
     case LIBXL_DOMAIN_TYPE_PV:
+        vm_gid_addr = 0;
         hvm = 0;
         break;
     default:
@@ -583,7 +598,8 @@ int libxl__domain_suspend_common(libxl__
     callbacks.switch_qemu_logdirty = libxl__domain_suspend_common_switch_qemu_logdirty;
     callbacks.data = &si;
 
-    rc = xc_domain_save(ctx->xch, fd, domid, 0, 0, flags, &callbacks, hvm);
+    rc = xc_domain_save(ctx->xch, fd, domid, 0, 0, flags, &callbacks,
+                        hvm, vm_gid_addr);
     if ( rc ) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "saving domain: %s",
                          si.guest_responded ?
diff -r a4d7c27ec1f1 -r 152a79fbe918 tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Fri Dec 02 13:51:17 2011 -0800
+++ b/tools/libxl/libxl_internal.h	Mon Dec 05 10:01:30 2011 +0000
@@ -199,6 +199,7 @@ typedef struct {
 
     uint32_t console_port;
     unsigned long console_mfn;
+    unsigned long vm_gid_addr;
 } libxl__domain_build_state;
 
 _hidden int libxl__build_pre(libxl__gc *gc, uint32_t domid,
diff -r a4d7c27ec1f1 -r 152a79fbe918 tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Fri Dec 02 13:51:17 2011 -0800
+++ b/tools/libxl/libxl_types.idl	Mon Dec 05 10:01:30 2011 +0000
@@ -184,6 +184,7 @@ libxl_domain_build_info = Struct("domain
                                        ("vpt_align", bool),
                                        ("timer_mode", integer),
                                        ("nested_hvm", bool),
+                                       ("no_increment_gid", bool),
                                        ])),
                  ("pv", Struct(None, [("kernel", libxl_file_reference),
                                       ("slack_memkb", uint32),
diff -r a4d7c27ec1f1 -r 152a79fbe918 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Fri Dec 02 13:51:17 2011 -0800
+++ b/tools/libxl/xl_cmdimpl.c	Mon Dec 05 10:01:30 2011 +0000
@@ -360,6 +360,7 @@ static void printf_info(int domid,
         printf("\t\t\t(vpt_align %d)\n", b_info->u.hvm.vpt_align);
         printf("\t\t\t(timer_mode %d)\n", b_info->u.hvm.timer_mode);
         printf("\t\t\t(nestedhvm %d)\n", b_info->u.hvm.nested_hvm);
+        printf("\t\t\t(no_increment_gid %d)\n", b_info->u.hvm.no_increment_gid);
 
         printf("\t\t\t(device_model %s)\n", dm_info->device_model ? : "default");
         printf("\t\t\t(videoram %d)\n", dm_info->videoram);
@@ -1362,6 +1363,7 @@ struct domain_create {
     const char *restore_file;
     int migrate_fd; /* -1 means none */
     char **migration_domname_r; /* from malloc */
+    int no_increment_gid;
 };
 
 static int freemem(libxl_domain_build_info *b_info, libxl_device_model_info *dm_info)
@@ -1575,6 +1577,8 @@ static int create_domain(struct domain_c
         }
     }
 
+    d_config.b_info.u.hvm.no_increment_gid = dom_info->no_increment_gid;
+
     if (debug || dom_info->dryrun)
         printf_info(-1, &d_config, &d_config.dm_info);
 
@@ -2800,6 +2804,7 @@ static void migrate_receive(int debug, i
     dom_info.restore_file = "incoming migration stream";
     dom_info.migrate_fd = 0; /* stdin */
     dom_info.migration_domname_r = &migration_domname;
+    dom_info.no_increment_gid = 1;
 
     rc = create_domain(&dom_info);
     if (rc < 0) {
diff -r a4d7c27ec1f1 -r 152a79fbe918 tools/python/xen/lowlevel/checkpoint/libcheckpoint.c
--- a/tools/python/xen/lowlevel/checkpoint/libcheckpoint.c	Fri Dec 02 13:51:17 2011 -0800
+++ b/tools/python/xen/lowlevel/checkpoint/libcheckpoint.c	Mon Dec 05 10:01:30 2011 +0000
@@ -175,6 +175,7 @@ int checkpoint_start(checkpoint_state* s
 {
     int hvm, rc;
     int flags = XCFLAGS_LIVE;
+    unsigned long vm_gid_addr;
 
     if (!s->domid) {
        s->errstr = "checkpoint state not opened";
@@ -185,16 +186,27 @@ int checkpoint_start(checkpoint_state* s
 
     hvm = s->domtype > dt_pv;
     if (hvm) {
+       char path[128];
+       char *addr;
+
+       sprintf(path, "/local/domain/%u/data/generation-id", s->domid);
+       addr = xs_read(s->xsh, XBT_NULL, path, NULL);
+
+       vm_gid_addr = (addr) ? strtoul(addr, NULL, 0) : 0;
+       free(addr);
+
        flags |= XCFLAGS_HVM;
        if (switch_qemu_logdirty(s, 1))
            return -1;
+    } else {
+       vm_gid_addr = 0;
     }
     if (remus_flags & CHECKPOINT_FLAGS_COMPRESSION)
       flags |= XCFLAGS_CHECKPOINT_COMPRESS;
 
     callbacks->switch_qemu_logdirty = noop_switch_logdirty;
 
-    rc = xc_domain_save(s->xch, fd, s->domid, 0, 0, flags, callbacks, hvm);
+    rc = xc_domain_save(s->xch, fd, s->domid, 0, 0, flags, callbacks, hvm, vm_gid_addr);
 
     if (hvm)
        switch_qemu_logdirty(s, 0);
diff -r a4d7c27ec1f1 -r 152a79fbe918 tools/xcutils/xc_restore.c
--- a/tools/xcutils/xc_restore.c	Fri Dec 02 13:51:17 2011 -0800
+++ b/tools/xcutils/xc_restore.c	Mon Dec 05 10:01:30 2011 +0000
@@ -23,7 +23,8 @@ main(int argc, char **argv)
     xc_interface *xch;
     int io_fd, ret;
     int superpages;
-    unsigned long store_mfn, console_mfn;
+    unsigned long store_mfn, console_mfn, vm_gid_addr;
+    int no_increment_gid;
 
     if ( (argc != 8) && (argc != 9) )
         errx(1, "usage: %s iofd domid store_evtchn "
@@ -40,19 +41,25 @@ main(int argc, char **argv)
     hvm  = atoi(argv[5]);
     pae  = atoi(argv[6]);
     apic = atoi(argv[7]);
-    if ( argc == 9 )
+    if ( argc >= 9 )
 	    superpages = atoi(argv[8]);
     else
 	    superpages = !!hvm;
+    if ( argc >= 10 )
+	    no_increment_gid = !atoi(argv[9]);
+    else
+	    no_increment_gid = 0;
 
     ret = xc_domain_restore(xch, io_fd, domid, store_evtchn, &store_mfn,
-                            console_evtchn, &console_mfn, hvm, pae, superpages);
+                            console_evtchn, &console_mfn, hvm, pae, superpages,
+                            no_increment_gid, &vm_gid_addr);
 
     if ( ret == 0 )
     {
 	printf("store-mfn %li\n", store_mfn);
         if ( !hvm )
             printf("console-mfn %li\n", console_mfn);
+	printf("vm-gid-addr %lx\n", vm_gid_addr);
 	fflush(stdout);
     }
 
diff -r a4d7c27ec1f1 -r 152a79fbe918 tools/xcutils/xc_save.c
--- a/tools/xcutils/xc_save.c	Fri Dec 02 13:51:17 2011 -0800
+++ b/tools/xcutils/xc_save.c	Mon Dec 05 10:01:30 2011 +0000
@@ -169,6 +169,10 @@ main(int argc, char **argv)
     unsigned int maxit, max_f;
     int io_fd, ret, port;
     struct save_callbacks callbacks;
+    char path[128];
+    struct xs_handle *xs;
+    char *addr;
+    unsigned long vm_gid_addr;
 
     if (argc != 6)
         errx(1, "usage: %s iofd domid maxit maxf flags", argv[0]);
@@ -207,8 +211,21 @@ main(int argc, char **argv)
     memset(&callbacks, 0, sizeof(callbacks));
     callbacks.suspend = suspend;
     callbacks.switch_qemu_logdirty = switch_qemu_logdirty;
+
+    sprintf(path, "/local/domain/%d/data/generation-id", si.domid);
+
+    if ((xs = xs_daemon_open()) == NULL)
+        errx(1, "Couldn't contact xenstore");
+
+    addr = xs_read(xs, XBT_NULL, path, NULL);
+
+    xs_daemon_close(xs);
+
+    vm_gid_addr = (addr) ? strtoul(addr, NULL, 0) : 0;
+    free(addr);
+
     ret = xc_domain_save(si.xch, io_fd, si.domid, maxit, max_f, si.flags, 
-                         &callbacks, !!(si.flags & XCFLAGS_HVM));
+                         &callbacks, !!(si.flags & XCFLAGS_HVM), vm_gid_addr);
 
     if (si.suspend_evtchn > 0)
 	 xc_suspend_evtchn_release(si.xch, si.xce, si.domid, si.suspend_evtchn);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 10:15:32 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 10:15:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXVZl-00017I-9U; Mon, 05 Dec 2011 10:15:09 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RXVZj-000173-Sc
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 10:15:08 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1323080061!4082757!1
X-Originating-IP: [209.85.216.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23188 invoked from network); 5 Dec 2011 10:14:23 -0000
Received: from mail-qy0-f171.google.com (HELO mail-qy0-f171.google.com)
	(209.85.216.171)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Dec 2011 10:14:23 -0000
Received: by qcsc20 with SMTP id c20so15518717qcs.30
	for <xen-devel@lists.xensource.com>;
	Mon, 05 Dec 2011 02:14:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=gMeQJnu56LB2IdidJsPcuYct/MiVjmBIi1eMbxRt0Fo=;
	b=bnd0bxWLrp6aBSXc1yTWxk/fe9wkWpHtSCYmEnVCtMSAmgq1HKd9iBx35HatqyYVFh
	/JvvwTt2MgVO2VhxWqAG2nWva9zfxB+ACHbdwNvItPZfAEt+NjFJmLoTwezbZEUVdhpQ
	aFVpV4eITlvhcWYrNQOxXg75nCKFZnxwN1u3Q=
Received: by 10.229.66.199 with SMTP id o7mr1830076qci.17.1323080061600;
	Mon, 05 Dec 2011 02:14:21 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id ff9sm24709394qab.16.2011.12.05.02.14.19
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 05 Dec 2011 02:14:20 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: c0d51df66b829995c4eb3902b5b9914c710a6c01
Message-Id: <c0d51df66b829995c4eb.1323079806@loki.upc.es>
In-Reply-To: <patchbomb.1323079804@loki.upc.es>
References: <patchbomb.1323079804@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Mon, 05 Dec 2011 11:10:06 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 2 of 2] libxl: remove force parameter from
	libxl_domain_destroy
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1323079605 -3600
# Node ID c0d51df66b829995c4eb3902b5b9914c710a6c01
# Parent  bc90cfd8dd220d69d09cf94a3d39ff3cef76d021
libxl: remove force parameter from libxl_domain_destroy

Since a destroy is considered a forced shutdown, there's no point in
passing a force parameter. All the occurences of this function have
been replaced with the proper syntax.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r bc90cfd8dd22 -r c0d51df66b82 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Mon Dec 05 11:06:23 2011 +0100
+++ b/tools/libxl/libxl.c	Mon Dec 05 11:06:45 2011 +0100
@@ -718,7 +718,7 @@ int libxl_event_get_disk_eject_info(libx
     return 1;
 }
 
-int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid, int force)
+int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid)
 {
     libxl__gc gc = LIBXL_INIT_GC(ctx);
     libxl_dominfo dominfo;
@@ -767,7 +767,7 @@ int libxl_domain_destroy(libxl_ctx *ctx,
 
         libxl__qmp_cleanup(&gc, domid);
     }
-    if (libxl__devices_destroy(&gc, domid, force) < 0)
+    if (libxl__devices_destroy(&gc, domid, 1) < 0)
         LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "libxl__devices_destroy failed for %d", domid);
 
     vm_path = libxl__xs_read(&gc, XBT_NULL, libxl__sprintf(&gc, "%s/vm", dom_path));
diff -r bc90cfd8dd22 -r c0d51df66b82 tools/libxl/libxl.h
--- a/tools/libxl/libxl.h	Mon Dec 05 11:06:23 2011 +0100
+++ b/tools/libxl/libxl.h	Mon Dec 05 11:06:45 2011 +0100
@@ -269,7 +269,7 @@ int libxl_domain_suspend(libxl_ctx *ctx,
                           uint32_t domid, int fd);
 int libxl_domain_resume(libxl_ctx *ctx, uint32_t domid);
 int libxl_domain_shutdown(libxl_ctx *ctx, uint32_t domid, int req);
-int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid, int force);
+int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid);
 int libxl_domain_preserve(libxl_ctx *ctx, uint32_t domid, libxl_domain_create_info *info, const char *name_suffix, libxl_uuid new_uuid);
 
 /* get max. number of cpus supported by hypervisor */
diff -r bc90cfd8dd22 -r c0d51df66b82 tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Mon Dec 05 11:06:23 2011 +0100
+++ b/tools/libxl/libxl_create.c	Mon Dec 05 11:06:45 2011 +0100
@@ -646,7 +646,7 @@ static int do_domain_create(libxl__gc *g
 
 error_out:
     if (domid)
-        libxl_domain_destroy(ctx, domid, 0);
+        libxl_domain_destroy(ctx, domid);
 
     return ret;
 }
diff -r bc90cfd8dd22 -r c0d51df66b82 tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Mon Dec 05 11:06:23 2011 +0100
+++ b/tools/libxl/libxl_dm.c	Mon Dec 05 11:06:45 2011 +0100
@@ -917,7 +917,7 @@ int libxl__destroy_device_model(libxl__g
             goto out;
         }
         LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Device model is a stubdom, domid=%d", stubdomid);
-        ret = libxl_domain_destroy(ctx, stubdomid, 0);
+        ret = libxl_domain_destroy(ctx, stubdomid);
         if (ret)
             goto out;
     } else {
diff -r bc90cfd8dd22 -r c0d51df66b82 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Mon Dec 05 11:06:23 2011 +0100
+++ b/tools/libxl/xl_cmdimpl.c	Mon Dec 05 11:06:45 2011 +0100
@@ -1200,7 +1200,7 @@ static int handle_domain_death(libxl_ctx
         /* fall-through */
     case LIBXL_ACTION_ON_SHUTDOWN_DESTROY:
         LOG("Domain %d needs to be cleaned up: destroying the domain", domid);
-        libxl_domain_destroy(ctx, domid, 0);
+        libxl_domain_destroy(ctx, domid);
         break;
 
     case LIBXL_ACTION_ON_SHUTDOWN_COREDUMP_DESTROY:
@@ -1698,7 +1698,7 @@ start:
 error_out:
     release_lock();
     if (libxl_domid_valid_guest(domid))
-        libxl_domain_destroy(ctx, domid, 0);
+        libxl_domain_destroy(ctx, domid);
 
 out:
     if (logfile != 2)
@@ -2168,7 +2168,7 @@ static void destroy_domain(const char *p
         fprintf(stderr, "Cannot destroy privileged domain 0.\n\n");
         exit(-1);
     }
-    rc = libxl_domain_destroy(ctx, domid, 0);
+    rc = libxl_domain_destroy(ctx, domid);
     if (rc) { fprintf(stderr,"destroy failed (rc=%d)\n",rc); exit(-1); }
 }
 
@@ -2414,7 +2414,7 @@ static int save_domain(const char *p, co
     if (checkpoint)
         libxl_domain_unpause(ctx, domid);
     else
-        libxl_domain_destroy(ctx, domid, 0);
+        libxl_domain_destroy(ctx, domid);
 
     exit(0);
 }
@@ -2647,7 +2647,7 @@ static void migrate_domain(const char *d
     }
 
     fprintf(stderr, "migration sender: Target reports successful startup.\n");
-    libxl_domain_destroy(ctx, domid, 1); /* bang! */
+    libxl_domain_destroy(ctx, domid); /* bang! */
     fprintf(stderr, "Migration successful.\n");
     exit(0);
 
@@ -2764,7 +2764,7 @@ static void migrate_receive(int debug, i
     if (rc) {
         fprintf(stderr, "migration target: Failure, destroying our copy.\n");
 
-        rc2 = libxl_domain_destroy(ctx, domid, 1);
+        rc2 = libxl_domain_destroy(ctx, domid);
         if (rc2) {
             fprintf(stderr, "migration target: Failed to destroy our copy"
                     " (code %d).\n", rc2);
diff -r bc90cfd8dd22 -r c0d51df66b82 tools/python/xen/lowlevel/xl/xl.c
--- a/tools/python/xen/lowlevel/xl/xl.c	Mon Dec 05 11:06:23 2011 +0100
+++ b/tools/python/xen/lowlevel/xl/xl.c	Mon Dec 05 11:06:45 2011 +0100
@@ -437,10 +437,10 @@ static PyObject *pyxl_domain_shutdown(Xl
 
 static PyObject *pyxl_domain_destroy(XlObject *self, PyObject *args)
 {
-    int domid, force = 1;
-    if ( !PyArg_ParseTuple(args, "i|i", &domid, &force) )
+    int domid;
+    if ( !PyArg_ParseTuple(args, "i", &domid) )
         return NULL;
-    if ( libxl_domain_destroy(self->ctx, domid, force) ) {
+    if ( libxl_domain_destroy(self->ctx, domid) ) {
         PyErr_SetString(xl_error_obj, "cannot destroy domain");
         return NULL;
     }

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 10:15:32 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 10:15:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXVZl-00017I-9U; Mon, 05 Dec 2011 10:15:09 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RXVZj-000173-Sc
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 10:15:08 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1323080061!4082757!1
X-Originating-IP: [209.85.216.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23188 invoked from network); 5 Dec 2011 10:14:23 -0000
Received: from mail-qy0-f171.google.com (HELO mail-qy0-f171.google.com)
	(209.85.216.171)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Dec 2011 10:14:23 -0000
Received: by qcsc20 with SMTP id c20so15518717qcs.30
	for <xen-devel@lists.xensource.com>;
	Mon, 05 Dec 2011 02:14:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=gMeQJnu56LB2IdidJsPcuYct/MiVjmBIi1eMbxRt0Fo=;
	b=bnd0bxWLrp6aBSXc1yTWxk/fe9wkWpHtSCYmEnVCtMSAmgq1HKd9iBx35HatqyYVFh
	/JvvwTt2MgVO2VhxWqAG2nWva9zfxB+ACHbdwNvItPZfAEt+NjFJmLoTwezbZEUVdhpQ
	aFVpV4eITlvhcWYrNQOxXg75nCKFZnxwN1u3Q=
Received: by 10.229.66.199 with SMTP id o7mr1830076qci.17.1323080061600;
	Mon, 05 Dec 2011 02:14:21 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id ff9sm24709394qab.16.2011.12.05.02.14.19
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 05 Dec 2011 02:14:20 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: c0d51df66b829995c4eb3902b5b9914c710a6c01
Message-Id: <c0d51df66b829995c4eb.1323079806@loki.upc.es>
In-Reply-To: <patchbomb.1323079804@loki.upc.es>
References: <patchbomb.1323079804@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Mon, 05 Dec 2011 11:10:06 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 2 of 2] libxl: remove force parameter from
	libxl_domain_destroy
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1323079605 -3600
# Node ID c0d51df66b829995c4eb3902b5b9914c710a6c01
# Parent  bc90cfd8dd220d69d09cf94a3d39ff3cef76d021
libxl: remove force parameter from libxl_domain_destroy

Since a destroy is considered a forced shutdown, there's no point in
passing a force parameter. All the occurences of this function have
been replaced with the proper syntax.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r bc90cfd8dd22 -r c0d51df66b82 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Mon Dec 05 11:06:23 2011 +0100
+++ b/tools/libxl/libxl.c	Mon Dec 05 11:06:45 2011 +0100
@@ -718,7 +718,7 @@ int libxl_event_get_disk_eject_info(libx
     return 1;
 }
 
-int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid, int force)
+int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid)
 {
     libxl__gc gc = LIBXL_INIT_GC(ctx);
     libxl_dominfo dominfo;
@@ -767,7 +767,7 @@ int libxl_domain_destroy(libxl_ctx *ctx,
 
         libxl__qmp_cleanup(&gc, domid);
     }
-    if (libxl__devices_destroy(&gc, domid, force) < 0)
+    if (libxl__devices_destroy(&gc, domid, 1) < 0)
         LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "libxl__devices_destroy failed for %d", domid);
 
     vm_path = libxl__xs_read(&gc, XBT_NULL, libxl__sprintf(&gc, "%s/vm", dom_path));
diff -r bc90cfd8dd22 -r c0d51df66b82 tools/libxl/libxl.h
--- a/tools/libxl/libxl.h	Mon Dec 05 11:06:23 2011 +0100
+++ b/tools/libxl/libxl.h	Mon Dec 05 11:06:45 2011 +0100
@@ -269,7 +269,7 @@ int libxl_domain_suspend(libxl_ctx *ctx,
                           uint32_t domid, int fd);
 int libxl_domain_resume(libxl_ctx *ctx, uint32_t domid);
 int libxl_domain_shutdown(libxl_ctx *ctx, uint32_t domid, int req);
-int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid, int force);
+int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid);
 int libxl_domain_preserve(libxl_ctx *ctx, uint32_t domid, libxl_domain_create_info *info, const char *name_suffix, libxl_uuid new_uuid);
 
 /* get max. number of cpus supported by hypervisor */
diff -r bc90cfd8dd22 -r c0d51df66b82 tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Mon Dec 05 11:06:23 2011 +0100
+++ b/tools/libxl/libxl_create.c	Mon Dec 05 11:06:45 2011 +0100
@@ -646,7 +646,7 @@ static int do_domain_create(libxl__gc *g
 
 error_out:
     if (domid)
-        libxl_domain_destroy(ctx, domid, 0);
+        libxl_domain_destroy(ctx, domid);
 
     return ret;
 }
diff -r bc90cfd8dd22 -r c0d51df66b82 tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Mon Dec 05 11:06:23 2011 +0100
+++ b/tools/libxl/libxl_dm.c	Mon Dec 05 11:06:45 2011 +0100
@@ -917,7 +917,7 @@ int libxl__destroy_device_model(libxl__g
             goto out;
         }
         LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Device model is a stubdom, domid=%d", stubdomid);
-        ret = libxl_domain_destroy(ctx, stubdomid, 0);
+        ret = libxl_domain_destroy(ctx, stubdomid);
         if (ret)
             goto out;
     } else {
diff -r bc90cfd8dd22 -r c0d51df66b82 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Mon Dec 05 11:06:23 2011 +0100
+++ b/tools/libxl/xl_cmdimpl.c	Mon Dec 05 11:06:45 2011 +0100
@@ -1200,7 +1200,7 @@ static int handle_domain_death(libxl_ctx
         /* fall-through */
     case LIBXL_ACTION_ON_SHUTDOWN_DESTROY:
         LOG("Domain %d needs to be cleaned up: destroying the domain", domid);
-        libxl_domain_destroy(ctx, domid, 0);
+        libxl_domain_destroy(ctx, domid);
         break;
 
     case LIBXL_ACTION_ON_SHUTDOWN_COREDUMP_DESTROY:
@@ -1698,7 +1698,7 @@ start:
 error_out:
     release_lock();
     if (libxl_domid_valid_guest(domid))
-        libxl_domain_destroy(ctx, domid, 0);
+        libxl_domain_destroy(ctx, domid);
 
 out:
     if (logfile != 2)
@@ -2168,7 +2168,7 @@ static void destroy_domain(const char *p
         fprintf(stderr, "Cannot destroy privileged domain 0.\n\n");
         exit(-1);
     }
-    rc = libxl_domain_destroy(ctx, domid, 0);
+    rc = libxl_domain_destroy(ctx, domid);
     if (rc) { fprintf(stderr,"destroy failed (rc=%d)\n",rc); exit(-1); }
 }
 
@@ -2414,7 +2414,7 @@ static int save_domain(const char *p, co
     if (checkpoint)
         libxl_domain_unpause(ctx, domid);
     else
-        libxl_domain_destroy(ctx, domid, 0);
+        libxl_domain_destroy(ctx, domid);
 
     exit(0);
 }
@@ -2647,7 +2647,7 @@ static void migrate_domain(const char *d
     }
 
     fprintf(stderr, "migration sender: Target reports successful startup.\n");
-    libxl_domain_destroy(ctx, domid, 1); /* bang! */
+    libxl_domain_destroy(ctx, domid); /* bang! */
     fprintf(stderr, "Migration successful.\n");
     exit(0);
 
@@ -2764,7 +2764,7 @@ static void migrate_receive(int debug, i
     if (rc) {
         fprintf(stderr, "migration target: Failure, destroying our copy.\n");
 
-        rc2 = libxl_domain_destroy(ctx, domid, 1);
+        rc2 = libxl_domain_destroy(ctx, domid);
         if (rc2) {
             fprintf(stderr, "migration target: Failed to destroy our copy"
                     " (code %d).\n", rc2);
diff -r bc90cfd8dd22 -r c0d51df66b82 tools/python/xen/lowlevel/xl/xl.c
--- a/tools/python/xen/lowlevel/xl/xl.c	Mon Dec 05 11:06:23 2011 +0100
+++ b/tools/python/xen/lowlevel/xl/xl.c	Mon Dec 05 11:06:45 2011 +0100
@@ -437,10 +437,10 @@ static PyObject *pyxl_domain_shutdown(Xl
 
 static PyObject *pyxl_domain_destroy(XlObject *self, PyObject *args)
 {
-    int domid, force = 1;
-    if ( !PyArg_ParseTuple(args, "i|i", &domid, &force) )
+    int domid;
+    if ( !PyArg_ParseTuple(args, "i", &domid) )
         return NULL;
-    if ( libxl_domain_destroy(self->ctx, domid, force) ) {
+    if ( libxl_domain_destroy(self->ctx, domid) ) {
         PyErr_SetString(xl_error_obj, "cannot destroy domain");
         return NULL;
     }

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 10:22:21 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 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.xensource.com>)
	id 1RXVgP-0001HX-7E; Mon, 05 Dec 2011 10:22:01 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RXVgN-0001HM-3X
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 10:21:59 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1323080057!6103168!2
X-Originating-IP: [209.85.216.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26813 invoked from network); 5 Dec 2011 10:14:20 -0000
Received: from mail-qw0-f43.google.com (HELO mail-qw0-f43.google.com)
	(209.85.216.43)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Dec 2011 10:14:20 -0000
Received: by mail-qw0-f43.google.com with SMTP id g27so334739qab.9
	for <xen-devel@lists.xensource.com>;
	Mon, 05 Dec 2011 02:14:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=O72rYREckCHH3aYvbom3j0Ct9fXJCK9fI6Dk0YYaREw=;
	b=pZWzSQPO2YrDvCl25WoafG7dUdciFGa5tkKtyfzowEWtJTdivCbQfksiFil1CxjViJ
	A8qvf+EyrNw/M0tbj4wDCbusb9uwj5Ge2fjLq8bIpcPWBVjV6YVlnJmjYk0Z1eR1dpNl
	NjjlhH45wGc/seV1HvUEQoKK9WJHOgpzB9Bh0=
Received: by 10.224.77.13 with SMTP id e13mr742280qak.51.1323080059808;
	Mon, 05 Dec 2011 02:14:19 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id ff9sm24709394qab.16.2011.12.05.02.14.17
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 05 Dec 2011 02:14:18 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: bc90cfd8dd220d69d09cf94a3d39ff3cef76d021
Message-Id: <bc90cfd8dd220d69d09c.1323079805@loki.upc.es>
In-Reply-To: <patchbomb.1323079804@loki.upc.es>
References: <patchbomb.1323079804@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Mon, 05 Dec 2011 11:10:05 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 1 of 2] libxl: set frontend status to 6 on
	domain destroy
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1323079583 -3600
# Node ID bc90cfd8dd220d69d09cf94a3d39ff3cef76d021
# Parent  274fa4aea2a30fb82228513f969d7cb807813bb8
libxl: set frontend status to 6 on domain destroy

Set frontend status to 6 on domain destruction and wait for devices to
be disconnected before executing hotplug scripts.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 274fa4aea2a3 -r bc90cfd8dd22 tools/libxl/libxl_device.c
--- a/tools/libxl/libxl_device.c	Thu Dec 01 16:01:31 2011 +0100
+++ b/tools/libxl/libxl_device.c	Mon Dec 05 11:06:23 2011 +0100
@@ -513,10 +513,7 @@ int libxl__device_destroy(libxl__gc *gc,
     char *be_path = libxl__device_backend_path(gc, dev);
     char *fe_path = libxl__device_frontend_path(gc, dev);
 
-    /* 
-     * Run hotplug scripts, which will probably not be able to
-     * execute successfully since the device may still be plugged
-     */
+    libxl__xs_write(gc, XBT_NULL, libxl__sprintf(gc, "%s/%s", fe_path, "state"), "6");
     libxl__device_execute_hotplug(gc, dev, DISCONNECT);
 
     xs_rm(ctx->xsh, XBT_NULL, be_path);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 10:22:21 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 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.xensource.com>)
	id 1RXVgP-0001HX-7E; Mon, 05 Dec 2011 10:22:01 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RXVgN-0001HM-3X
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 10:21:59 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1323080057!6103168!2
X-Originating-IP: [209.85.216.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26813 invoked from network); 5 Dec 2011 10:14:20 -0000
Received: from mail-qw0-f43.google.com (HELO mail-qw0-f43.google.com)
	(209.85.216.43)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Dec 2011 10:14:20 -0000
Received: by mail-qw0-f43.google.com with SMTP id g27so334739qab.9
	for <xen-devel@lists.xensource.com>;
	Mon, 05 Dec 2011 02:14:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=O72rYREckCHH3aYvbom3j0Ct9fXJCK9fI6Dk0YYaREw=;
	b=pZWzSQPO2YrDvCl25WoafG7dUdciFGa5tkKtyfzowEWtJTdivCbQfksiFil1CxjViJ
	A8qvf+EyrNw/M0tbj4wDCbusb9uwj5Ge2fjLq8bIpcPWBVjV6YVlnJmjYk0Z1eR1dpNl
	NjjlhH45wGc/seV1HvUEQoKK9WJHOgpzB9Bh0=
Received: by 10.224.77.13 with SMTP id e13mr742280qak.51.1323080059808;
	Mon, 05 Dec 2011 02:14:19 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id ff9sm24709394qab.16.2011.12.05.02.14.17
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 05 Dec 2011 02:14:18 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: bc90cfd8dd220d69d09cf94a3d39ff3cef76d021
Message-Id: <bc90cfd8dd220d69d09c.1323079805@loki.upc.es>
In-Reply-To: <patchbomb.1323079804@loki.upc.es>
References: <patchbomb.1323079804@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Mon, 05 Dec 2011 11:10:05 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 1 of 2] libxl: set frontend status to 6 on
	domain destroy
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1323079583 -3600
# Node ID bc90cfd8dd220d69d09cf94a3d39ff3cef76d021
# Parent  274fa4aea2a30fb82228513f969d7cb807813bb8
libxl: set frontend status to 6 on domain destroy

Set frontend status to 6 on domain destruction and wait for devices to
be disconnected before executing hotplug scripts.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 274fa4aea2a3 -r bc90cfd8dd22 tools/libxl/libxl_device.c
--- a/tools/libxl/libxl_device.c	Thu Dec 01 16:01:31 2011 +0100
+++ b/tools/libxl/libxl_device.c	Mon Dec 05 11:06:23 2011 +0100
@@ -513,10 +513,7 @@ int libxl__device_destroy(libxl__gc *gc,
     char *be_path = libxl__device_backend_path(gc, dev);
     char *fe_path = libxl__device_frontend_path(gc, dev);
 
-    /* 
-     * Run hotplug scripts, which will probably not be able to
-     * execute successfully since the device may still be plugged
-     */
+    libxl__xs_write(gc, XBT_NULL, libxl__sprintf(gc, "%s/%s", fe_path, "state"), "6");
     libxl__device_execute_hotplug(gc, dev, DISCONNECT);
 
     xs_rm(ctx->xsh, XBT_NULL, be_path);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 10:25:06 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 10:25:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXVj8-0001O7-PR; Mon, 05 Dec 2011 10:24:50 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RXVj8-0001O2-32
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 10:24:50 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1323080619!51126427!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjAyNg==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13394 invoked from network); 5 Dec 2011 10:23:39 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Dec 2011 10:23:39 -0000
X-IronPort-AV: E=Sophos;i="4.71,298,1320624000"; 
   d="scan'208";a="9284820"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Dec 2011 10:24:10 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Mon, 5 Dec 2011
	10:24:10 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau Monne <roger.pau@entel.upc.edu>
Date: Mon, 5 Dec 2011 10:24:10 +0000
In-Reply-To: <c0d51df66b829995c4eb.1323079806@loki.upc.es>
References: <patchbomb.1323079804@loki.upc.es>
	<c0d51df66b829995c4eb.1323079806@loki.upc.es>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323080650.29870.170.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 2 of 2] libxl: remove force parameter from
 libxl_domain_destroy
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Did patch 1/2 get stuck somewhere? I've not seen it yet.

On Mon, 2011-12-05 at 10:10 +0000, Roger Pau Monne wrote:
> # HG changeset patch
> # User Roger Pau Monne <roger.pau@entel.upc.edu>
> # Date 1323079605 -3600
> # Node ID c0d51df66b829995c4eb3902b5b9914c710a6c01
> # Parent  bc90cfd8dd220d69d09cf94a3d39ff3cef76d021
> libxl: remove force parameter from libxl_domain_destroy
> 
> Since a destroy is considered a forced shutdown, there's no point in
> passing a force parameter. All the occurences of this function have
> been replaced with the proper syntax.

I'm a little concerned with the change in libxl__destroy_device_model,
mostly because I don';t know what the expected semantics of a stub dom
shutdown are. Perhaps it is fine to shoot such a domain in the head
without previously giving an opportunity to shutdown?

> 
> Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>
> 
> diff -r bc90cfd8dd22 -r c0d51df66b82 tools/libxl/libxl.c
> --- a/tools/libxl/libxl.c	Mon Dec 05 11:06:23 2011 +0100
> +++ b/tools/libxl/libxl.c	Mon Dec 05 11:06:45 2011 +0100
> @@ -718,7 +718,7 @@ int libxl_event_get_disk_eject_info(libx
>      return 1;
>  }
>  
> -int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid, int force)
> +int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid)
>  {
>      libxl__gc gc = LIBXL_INIT_GC(ctx);
>      libxl_dominfo dominfo;
> @@ -767,7 +767,7 @@ int libxl_domain_destroy(libxl_ctx *ctx,
>  
>          libxl__qmp_cleanup(&gc, domid);
>      }
> -    if (libxl__devices_destroy(&gc, domid, force) < 0)
> +    if (libxl__devices_destroy(&gc, domid, 1) < 0)

If I'm not missing something this seems to be the only caller of
libxl__device_destroy. We could keep pushing this change down and remove
the force param here too which in turns removes a bunch of code from
libxl__devices_destroy and makes it behave like its name suggests.

>          LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "libxl__devices_destroy failed for %d", domid);
>  
>      vm_path = libxl__xs_read(&gc, XBT_NULL, libxl__sprintf(&gc, "%s/vm", dom_path));
> diff -r bc90cfd8dd22 -r c0d51df66b82 tools/libxl/libxl.h
> --- a/tools/libxl/libxl.h	Mon Dec 05 11:06:23 2011 +0100
> +++ b/tools/libxl/libxl.h	Mon Dec 05 11:06:45 2011 +0100
> @@ -269,7 +269,7 @@ int libxl_domain_suspend(libxl_ctx *ctx,
>                            uint32_t domid, int fd);
>  int libxl_domain_resume(libxl_ctx *ctx, uint32_t domid);
>  int libxl_domain_shutdown(libxl_ctx *ctx, uint32_t domid, int req);
> -int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid, int force);
> +int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid);
>  int libxl_domain_preserve(libxl_ctx *ctx, uint32_t domid, libxl_domain_create_info *info, const char *name_suffix, libxl_uuid new_uuid);
>  
>  /* get max. number of cpus supported by hypervisor */
> diff -r bc90cfd8dd22 -r c0d51df66b82 tools/libxl/libxl_create.c
> --- a/tools/libxl/libxl_create.c	Mon Dec 05 11:06:23 2011 +0100
> +++ b/tools/libxl/libxl_create.c	Mon Dec 05 11:06:45 2011 +0100
> @@ -646,7 +646,7 @@ static int do_domain_create(libxl__gc *g
>  
>  error_out:
>      if (domid)
> -        libxl_domain_destroy(ctx, domid, 0);
> +        libxl_domain_destroy(ctx, domid);
>  
>      return ret;
>  }
> diff -r bc90cfd8dd22 -r c0d51df66b82 tools/libxl/libxl_dm.c
> --- a/tools/libxl/libxl_dm.c	Mon Dec 05 11:06:23 2011 +0100
> +++ b/tools/libxl/libxl_dm.c	Mon Dec 05 11:06:45 2011 +0100
> @@ -917,7 +917,7 @@ int libxl__destroy_device_model(libxl__g
>              goto out;
>          }
>          LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Device model is a stubdom, domid=%d", stubdomid);
> -        ret = libxl_domain_destroy(ctx, stubdomid, 0);
> +        ret = libxl_domain_destroy(ctx, stubdomid);
>          if (ret)
>              goto out;
>      } else {
> diff -r bc90cfd8dd22 -r c0d51df66b82 tools/libxl/xl_cmdimpl.c
> --- a/tools/libxl/xl_cmdimpl.c	Mon Dec 05 11:06:23 2011 +0100
> +++ b/tools/libxl/xl_cmdimpl.c	Mon Dec 05 11:06:45 2011 +0100
> @@ -1200,7 +1200,7 @@ static int handle_domain_death(libxl_ctx
>          /* fall-through */
>      case LIBXL_ACTION_ON_SHUTDOWN_DESTROY:
>          LOG("Domain %d needs to be cleaned up: destroying the domain", domid);
> -        libxl_domain_destroy(ctx, domid, 0);
> +        libxl_domain_destroy(ctx, domid);
>          break;
>  
>      case LIBXL_ACTION_ON_SHUTDOWN_COREDUMP_DESTROY:
> @@ -1698,7 +1698,7 @@ start:
>  error_out:
>      release_lock();
>      if (libxl_domid_valid_guest(domid))
> -        libxl_domain_destroy(ctx, domid, 0);
> +        libxl_domain_destroy(ctx, domid);
>  
>  out:
>      if (logfile != 2)
> @@ -2168,7 +2168,7 @@ static void destroy_domain(const char *p
>          fprintf(stderr, "Cannot destroy privileged domain 0.\n\n");
>          exit(-1);
>      }
> -    rc = libxl_domain_destroy(ctx, domid, 0);
> +    rc = libxl_domain_destroy(ctx, domid);
>      if (rc) { fprintf(stderr,"destroy failed (rc=%d)\n",rc); exit(-1); }
>  }
>  
> @@ -2414,7 +2414,7 @@ static int save_domain(const char *p, co
>      if (checkpoint)
>          libxl_domain_unpause(ctx, domid);
>      else
> -        libxl_domain_destroy(ctx, domid, 0);
> +        libxl_domain_destroy(ctx, domid);
>  
>      exit(0);
>  }
> @@ -2647,7 +2647,7 @@ static void migrate_domain(const char *d
>      }
>  
>      fprintf(stderr, "migration sender: Target reports successful startup.\n");
> -    libxl_domain_destroy(ctx, domid, 1); /* bang! */
> +    libxl_domain_destroy(ctx, domid); /* bang! */
>      fprintf(stderr, "Migration successful.\n");
>      exit(0);
>  
> @@ -2764,7 +2764,7 @@ static void migrate_receive(int debug, i
>      if (rc) {
>          fprintf(stderr, "migration target: Failure, destroying our copy.\n");
>  
> -        rc2 = libxl_domain_destroy(ctx, domid, 1);
> +        rc2 = libxl_domain_destroy(ctx, domid);
>          if (rc2) {
>              fprintf(stderr, "migration target: Failed to destroy our copy"
>                      " (code %d).\n", rc2);
> diff -r bc90cfd8dd22 -r c0d51df66b82 tools/python/xen/lowlevel/xl/xl.c
> --- a/tools/python/xen/lowlevel/xl/xl.c	Mon Dec 05 11:06:23 2011 +0100
> +++ b/tools/python/xen/lowlevel/xl/xl.c	Mon Dec 05 11:06:45 2011 +0100
> @@ -437,10 +437,10 @@ static PyObject *pyxl_domain_shutdown(Xl
>  
>  static PyObject *pyxl_domain_destroy(XlObject *self, PyObject *args)
>  {
> -    int domid, force = 1;
> -    if ( !PyArg_ParseTuple(args, "i|i", &domid, &force) )
> +    int domid;
> +    if ( !PyArg_ParseTuple(args, "i", &domid) )
>          return NULL;
> -    if ( libxl_domain_destroy(self->ctx, domid, force) ) {
> +    if ( libxl_domain_destroy(self->ctx, domid) ) {
>          PyErr_SetString(xl_error_obj, "cannot destroy domain");
>          return NULL;
>      }
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 10:25:06 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 10:25:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXVj8-0001O7-PR; Mon, 05 Dec 2011 10:24:50 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RXVj8-0001O2-32
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 10:24:50 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1323080619!51126427!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjAyNg==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13394 invoked from network); 5 Dec 2011 10:23:39 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Dec 2011 10:23:39 -0000
X-IronPort-AV: E=Sophos;i="4.71,298,1320624000"; 
   d="scan'208";a="9284820"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Dec 2011 10:24:10 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Mon, 5 Dec 2011
	10:24:10 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau Monne <roger.pau@entel.upc.edu>
Date: Mon, 5 Dec 2011 10:24:10 +0000
In-Reply-To: <c0d51df66b829995c4eb.1323079806@loki.upc.es>
References: <patchbomb.1323079804@loki.upc.es>
	<c0d51df66b829995c4eb.1323079806@loki.upc.es>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323080650.29870.170.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 2 of 2] libxl: remove force parameter from
 libxl_domain_destroy
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Did patch 1/2 get stuck somewhere? I've not seen it yet.

On Mon, 2011-12-05 at 10:10 +0000, Roger Pau Monne wrote:
> # HG changeset patch
> # User Roger Pau Monne <roger.pau@entel.upc.edu>
> # Date 1323079605 -3600
> # Node ID c0d51df66b829995c4eb3902b5b9914c710a6c01
> # Parent  bc90cfd8dd220d69d09cf94a3d39ff3cef76d021
> libxl: remove force parameter from libxl_domain_destroy
> 
> Since a destroy is considered a forced shutdown, there's no point in
> passing a force parameter. All the occurences of this function have
> been replaced with the proper syntax.

I'm a little concerned with the change in libxl__destroy_device_model,
mostly because I don';t know what the expected semantics of a stub dom
shutdown are. Perhaps it is fine to shoot such a domain in the head
without previously giving an opportunity to shutdown?

> 
> Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>
> 
> diff -r bc90cfd8dd22 -r c0d51df66b82 tools/libxl/libxl.c
> --- a/tools/libxl/libxl.c	Mon Dec 05 11:06:23 2011 +0100
> +++ b/tools/libxl/libxl.c	Mon Dec 05 11:06:45 2011 +0100
> @@ -718,7 +718,7 @@ int libxl_event_get_disk_eject_info(libx
>      return 1;
>  }
>  
> -int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid, int force)
> +int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid)
>  {
>      libxl__gc gc = LIBXL_INIT_GC(ctx);
>      libxl_dominfo dominfo;
> @@ -767,7 +767,7 @@ int libxl_domain_destroy(libxl_ctx *ctx,
>  
>          libxl__qmp_cleanup(&gc, domid);
>      }
> -    if (libxl__devices_destroy(&gc, domid, force) < 0)
> +    if (libxl__devices_destroy(&gc, domid, 1) < 0)

If I'm not missing something this seems to be the only caller of
libxl__device_destroy. We could keep pushing this change down and remove
the force param here too which in turns removes a bunch of code from
libxl__devices_destroy and makes it behave like its name suggests.

>          LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "libxl__devices_destroy failed for %d", domid);
>  
>      vm_path = libxl__xs_read(&gc, XBT_NULL, libxl__sprintf(&gc, "%s/vm", dom_path));
> diff -r bc90cfd8dd22 -r c0d51df66b82 tools/libxl/libxl.h
> --- a/tools/libxl/libxl.h	Mon Dec 05 11:06:23 2011 +0100
> +++ b/tools/libxl/libxl.h	Mon Dec 05 11:06:45 2011 +0100
> @@ -269,7 +269,7 @@ int libxl_domain_suspend(libxl_ctx *ctx,
>                            uint32_t domid, int fd);
>  int libxl_domain_resume(libxl_ctx *ctx, uint32_t domid);
>  int libxl_domain_shutdown(libxl_ctx *ctx, uint32_t domid, int req);
> -int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid, int force);
> +int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid);
>  int libxl_domain_preserve(libxl_ctx *ctx, uint32_t domid, libxl_domain_create_info *info, const char *name_suffix, libxl_uuid new_uuid);
>  
>  /* get max. number of cpus supported by hypervisor */
> diff -r bc90cfd8dd22 -r c0d51df66b82 tools/libxl/libxl_create.c
> --- a/tools/libxl/libxl_create.c	Mon Dec 05 11:06:23 2011 +0100
> +++ b/tools/libxl/libxl_create.c	Mon Dec 05 11:06:45 2011 +0100
> @@ -646,7 +646,7 @@ static int do_domain_create(libxl__gc *g
>  
>  error_out:
>      if (domid)
> -        libxl_domain_destroy(ctx, domid, 0);
> +        libxl_domain_destroy(ctx, domid);
>  
>      return ret;
>  }
> diff -r bc90cfd8dd22 -r c0d51df66b82 tools/libxl/libxl_dm.c
> --- a/tools/libxl/libxl_dm.c	Mon Dec 05 11:06:23 2011 +0100
> +++ b/tools/libxl/libxl_dm.c	Mon Dec 05 11:06:45 2011 +0100
> @@ -917,7 +917,7 @@ int libxl__destroy_device_model(libxl__g
>              goto out;
>          }
>          LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Device model is a stubdom, domid=%d", stubdomid);
> -        ret = libxl_domain_destroy(ctx, stubdomid, 0);
> +        ret = libxl_domain_destroy(ctx, stubdomid);
>          if (ret)
>              goto out;
>      } else {
> diff -r bc90cfd8dd22 -r c0d51df66b82 tools/libxl/xl_cmdimpl.c
> --- a/tools/libxl/xl_cmdimpl.c	Mon Dec 05 11:06:23 2011 +0100
> +++ b/tools/libxl/xl_cmdimpl.c	Mon Dec 05 11:06:45 2011 +0100
> @@ -1200,7 +1200,7 @@ static int handle_domain_death(libxl_ctx
>          /* fall-through */
>      case LIBXL_ACTION_ON_SHUTDOWN_DESTROY:
>          LOG("Domain %d needs to be cleaned up: destroying the domain", domid);
> -        libxl_domain_destroy(ctx, domid, 0);
> +        libxl_domain_destroy(ctx, domid);
>          break;
>  
>      case LIBXL_ACTION_ON_SHUTDOWN_COREDUMP_DESTROY:
> @@ -1698,7 +1698,7 @@ start:
>  error_out:
>      release_lock();
>      if (libxl_domid_valid_guest(domid))
> -        libxl_domain_destroy(ctx, domid, 0);
> +        libxl_domain_destroy(ctx, domid);
>  
>  out:
>      if (logfile != 2)
> @@ -2168,7 +2168,7 @@ static void destroy_domain(const char *p
>          fprintf(stderr, "Cannot destroy privileged domain 0.\n\n");
>          exit(-1);
>      }
> -    rc = libxl_domain_destroy(ctx, domid, 0);
> +    rc = libxl_domain_destroy(ctx, domid);
>      if (rc) { fprintf(stderr,"destroy failed (rc=%d)\n",rc); exit(-1); }
>  }
>  
> @@ -2414,7 +2414,7 @@ static int save_domain(const char *p, co
>      if (checkpoint)
>          libxl_domain_unpause(ctx, domid);
>      else
> -        libxl_domain_destroy(ctx, domid, 0);
> +        libxl_domain_destroy(ctx, domid);
>  
>      exit(0);
>  }
> @@ -2647,7 +2647,7 @@ static void migrate_domain(const char *d
>      }
>  
>      fprintf(stderr, "migration sender: Target reports successful startup.\n");
> -    libxl_domain_destroy(ctx, domid, 1); /* bang! */
> +    libxl_domain_destroy(ctx, domid); /* bang! */
>      fprintf(stderr, "Migration successful.\n");
>      exit(0);
>  
> @@ -2764,7 +2764,7 @@ static void migrate_receive(int debug, i
>      if (rc) {
>          fprintf(stderr, "migration target: Failure, destroying our copy.\n");
>  
> -        rc2 = libxl_domain_destroy(ctx, domid, 1);
> +        rc2 = libxl_domain_destroy(ctx, domid);
>          if (rc2) {
>              fprintf(stderr, "migration target: Failed to destroy our copy"
>                      " (code %d).\n", rc2);
> diff -r bc90cfd8dd22 -r c0d51df66b82 tools/python/xen/lowlevel/xl/xl.c
> --- a/tools/python/xen/lowlevel/xl/xl.c	Mon Dec 05 11:06:23 2011 +0100
> +++ b/tools/python/xen/lowlevel/xl/xl.c	Mon Dec 05 11:06:45 2011 +0100
> @@ -437,10 +437,10 @@ static PyObject *pyxl_domain_shutdown(Xl
>  
>  static PyObject *pyxl_domain_destroy(XlObject *self, PyObject *args)
>  {
> -    int domid, force = 1;
> -    if ( !PyArg_ParseTuple(args, "i|i", &domid, &force) )
> +    int domid;
> +    if ( !PyArg_ParseTuple(args, "i", &domid) )
>          return NULL;
> -    if ( libxl_domain_destroy(self->ctx, domid, force) ) {
> +    if ( libxl_domain_destroy(self->ctx, domid) ) {
>          PyErr_SetString(xl_error_obj, "cannot destroy domain");
>          return NULL;
>      }
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 10:25:57 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 10:25:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXVjx-0001RQ-7Z; Mon, 05 Dec 2011 10:25:41 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RXVjv-0001R3-LF
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 10:25:40 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1323080057!6103168!1
X-Originating-IP: [209.85.216.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26730 invoked from network); 5 Dec 2011 10:14:18 -0000
Received: from mail-qw0-f43.google.com (HELO mail-qw0-f43.google.com)
	(209.85.216.43)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Dec 2011 10:14:18 -0000
Received: by qabg27 with SMTP id g27so334739qab.9
	for <xen-devel@lists.xensource.com>;
	Mon, 05 Dec 2011 02:14:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:message-id:user-agent:date:from:to;
	bh=GrVSrVpOYMkxXI5F/2r4BITbPvIXiDncoeCZU83eKI8=;
	b=neXSG4vJuKAuDl0Kxg+qzbH08h+SkS9oZUplU4c4JtsMB/Te+aliONaoFHqsrrndfB
	6rRBv3+pouIzeTRn6JK0x0k2rk0kDV1Z5lVLadxibCqlLpJ3xbuenpBSVpRoJZgYzYkd
	p2fFWPjXlQuRhHXg78Ki8PhGUUEJlpxajXoZA=
Received: by 10.224.33.202 with SMTP id i10mr7351877qad.91.1323080057778;
	Mon, 05 Dec 2011 02:14:17 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id ff9sm24709394qab.16.2011.12.05.02.14.15
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 05 Dec 2011 02:14:16 -0800 (PST)
MIME-Version: 1.0
Message-Id: <patchbomb.1323079804@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Mon, 05 Dec 2011 11:10:04 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 0 of 2] libxl: fix domain destruction with libxl
 hotplug script calling
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

When calling hotplug scripts from libxl we have to make sure the 
device is disconnected before attepmting to execute hotplug scripts.

This patch series sets frontend status to 6 when a domain is 
destroyed, so the devices are disconnected and then execute hotplug 
scripts.

Also the syntax of the libxl_domain_destroy has been changed to always 
force the destruction.

This series should be applied after "libxl: add support for hotplug 
script calling from libxl".

Please review, Roger.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 10:25:57 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 10:25:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXVjx-0001RQ-7Z; Mon, 05 Dec 2011 10:25:41 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RXVjv-0001R3-LF
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 10:25:40 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1323080057!6103168!1
X-Originating-IP: [209.85.216.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26730 invoked from network); 5 Dec 2011 10:14:18 -0000
Received: from mail-qw0-f43.google.com (HELO mail-qw0-f43.google.com)
	(209.85.216.43)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Dec 2011 10:14:18 -0000
Received: by qabg27 with SMTP id g27so334739qab.9
	for <xen-devel@lists.xensource.com>;
	Mon, 05 Dec 2011 02:14:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:message-id:user-agent:date:from:to;
	bh=GrVSrVpOYMkxXI5F/2r4BITbPvIXiDncoeCZU83eKI8=;
	b=neXSG4vJuKAuDl0Kxg+qzbH08h+SkS9oZUplU4c4JtsMB/Te+aliONaoFHqsrrndfB
	6rRBv3+pouIzeTRn6JK0x0k2rk0kDV1Z5lVLadxibCqlLpJ3xbuenpBSVpRoJZgYzYkd
	p2fFWPjXlQuRhHXg78Ki8PhGUUEJlpxajXoZA=
Received: by 10.224.33.202 with SMTP id i10mr7351877qad.91.1323080057778;
	Mon, 05 Dec 2011 02:14:17 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id ff9sm24709394qab.16.2011.12.05.02.14.15
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 05 Dec 2011 02:14:16 -0800 (PST)
MIME-Version: 1.0
Message-Id: <patchbomb.1323079804@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Mon, 05 Dec 2011 11:10:04 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 0 of 2] libxl: fix domain destruction with libxl
 hotplug script calling
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

When calling hotplug scripts from libxl we have to make sure the 
device is disconnected before attepmting to execute hotplug scripts.

This patch series sets frontend status to 6 when a domain is 
destroyed, so the devices are disconnected and then execute hotplug 
scripts.

Also the syntax of the libxl_domain_destroy has been changed to always 
force the destruction.

This series should be applied after "libxl: add support for hotplug 
script calling from libxl".

Please review, Roger.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 10:49:12 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 10:49:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXW6M-0001vo-Me; Mon, 05 Dec 2011 10:48:50 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RXW6L-0001vj-Gl
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 10:48:49 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1323082051!46582505!1
X-Originating-IP: [209.85.210.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4852 invoked from network); 5 Dec 2011 10:47:32 -0000
Received: from mail-pz0-f43.google.com (HELO mail-pz0-f43.google.com)
	(209.85.210.43)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Dec 2011 10:47:32 -0000
Received: by dadz13 with SMTP id z13so23959281dad.30
	for <xen-devel@lists.xensource.com>;
	Mon, 05 Dec 2011 02:48:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=S5GowHl/l61wkdsmwnTsq53swx2LbNilPklcggLS3Ew=;
	b=xvTetQLO5P65+q0tfc6FjalZmJqYMTXD3Ni8hbz/MpIHvc31wm7bKdh2Hoc0nX6E8B
	t+ri4ns70eCui7uIPeMvLxBiZaxjoPsbz8psWFmnnG4Cf8gpK9feFcQRIH1sc/oxNSgg
	sBd9jrs5Vn/t/aqgzdclvAa2il4roHB8ZR+1Y=
MIME-Version: 1.0
Received: by 10.68.73.65 with SMTP id j1mr22134129pbv.98.1323082087715; Mon,
	05 Dec 2011 02:48:07 -0800 (PST)
Received: by 10.142.43.18 with HTTP; Mon, 5 Dec 2011 02:48:07 -0800 (PST)
In-Reply-To: <1323080650.29870.170.camel@zakaz.uk.xensource.com>
References: <patchbomb.1323079804@loki.upc.es>
	<c0d51df66b829995c4eb.1323079806@loki.upc.es>
	<1323080650.29870.170.camel@zakaz.uk.xensource.com>
Date: Mon, 5 Dec 2011 11:48:07 +0100
X-Google-Sender-Auth: EwtktR6_-aKOqO3NIgzXrPlyw8k
Message-ID: <CAPLaKK60aWMgzai0PEO8AyLQL+jXJXd9iUyMt40Q8eih14a78A@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 2 of 2] libxl: remove force parameter from
	libxl_domain_destroy
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

MjAxMS8xMi81IElhbiBDYW1wYmVsbCA8SWFuLkNhbXBiZWxsQGNpdHJpeC5jb20+Ogo+IERpZCBw
YXRjaCAxLzIgZ2V0IHN0dWNrIHNvbWV3aGVyZT8gSSd2ZSBub3Qgc2VlbiBpdCB5ZXQuCj4KPiBP
biBNb24sIDIwMTEtMTItMDUgYXQgMTA6MTAgKzAwMDAsIFJvZ2VyIFBhdSBNb25uZSB3cm90ZToK
Pj4gIyBIRyBjaGFuZ2VzZXQgcGF0Y2gKPj4gIyBVc2VyIFJvZ2VyIFBhdSBNb25uZSA8cm9nZXIu
cGF1QGVudGVsLnVwYy5lZHU+Cj4+ICMgRGF0ZSAxMzIzMDc5NjA1IC0zNjAwCj4+ICMgTm9kZSBJ
RCBjMGQ1MWRmNjZiODI5OTk1YzRlYjM5MDJiNWI5OTE0YzcxMGE2YzAxCj4+ICMgUGFyZW50IMKg
YmM5MGNmZDhkZDIyMGQ2OWQwOWNmOTRhM2QzOWZmM2NlZjc2ZDAyMQo+PiBsaWJ4bDogcmVtb3Zl
IGZvcmNlIHBhcmFtZXRlciBmcm9tIGxpYnhsX2RvbWFpbl9kZXN0cm95Cj4+Cj4+IFNpbmNlIGEg
ZGVzdHJveSBpcyBjb25zaWRlcmVkIGEgZm9yY2VkIHNodXRkb3duLCB0aGVyZSdzIG5vIHBvaW50
IGluCj4+IHBhc3NpbmcgYSBmb3JjZSBwYXJhbWV0ZXIuIEFsbCB0aGUgb2NjdXJlbmNlcyBvZiB0
aGlzIGZ1bmN0aW9uIGhhdmUKPj4gYmVlbiByZXBsYWNlZCB3aXRoIHRoZSBwcm9wZXIgc3ludGF4
Lgo+Cj4gSSdtIGEgbGl0dGxlIGNvbmNlcm5lZCB3aXRoIHRoZSBjaGFuZ2UgaW4gbGlieGxfX2Rl
c3Ryb3lfZGV2aWNlX21vZGVsLAo+IG1vc3RseSBiZWNhdXNlIEkgZG9uJzt0IGtub3cgd2hhdCB0
aGUgZXhwZWN0ZWQgc2VtYW50aWNzIG9mIGEgc3R1YiBkb20KPiBzaHV0ZG93biBhcmUuIFBlcmhh
cHMgaXQgaXMgZmluZSB0byBzaG9vdCBzdWNoIGEgZG9tYWluIGluIHRoZSBoZWFkCj4gd2l0aG91
dCBwcmV2aW91c2x5IGdpdmluZyBhbiBvcHBvcnR1bml0eSB0byBzaHV0ZG93bj8KCkknbSBzb3Jy
eSwgYnV0IEkgZG9uJ3Qga25vdyBhYm91dCBzdHViZG9tcywgdGhleSBhcmUgbm90IHdvcmtpbmcg
dW5kZXIKTmV0QlNEICp5ZXQqLCBJIHdpbGwgcHJvYmFibHkgZ2V0IHdpdGggdGhpcyBvbmNlIEkg
ZmluaXNoIHBvcnRpbmcKbGlieGwgKG9yIGEgdXNlcnNwYWNlIGJsa3RhcCBpbXBsZW1lbnRhdGlv
biwgdGhhdCdzIGFsc28gcXVpdGUKb3V0c3RhbmRpbmcpLgoKPj4KPj4gU2lnbmVkLW9mZi1ieTog
Um9nZXIgUGF1IE1vbm5lIDxyb2dlci5wYXVAZW50ZWwudXBjLmVkdT4KPj4KPj4gZGlmZiAtciBi
YzkwY2ZkOGRkMjIgLXIgYzBkNTFkZjY2YjgyIHRvb2xzL2xpYnhsL2xpYnhsLmMKPj4gLS0tIGEv
dG9vbHMvbGlieGwvbGlieGwuYyDCoCDCoCBNb24gRGVjIDA1IDExOjA2OjIzIDIwMTEgKzAxMDAK
Pj4gKysrIGIvdG9vbHMvbGlieGwvbGlieGwuYyDCoCDCoCBNb24gRGVjIDA1IDExOjA2OjQ1IDIw
MTEgKzAxMDAKPj4gQEAgLTcxOCw3ICs3MTgsNyBAQCBpbnQgbGlieGxfZXZlbnRfZ2V0X2Rpc2tf
ZWplY3RfaW5mbyhsaWJ4Cj4+IMKgIMKgIMKgcmV0dXJuIDE7Cj4+IMKgfQo+Pgo+PiAtaW50IGxp
YnhsX2RvbWFpbl9kZXN0cm95KGxpYnhsX2N0eCAqY3R4LCB1aW50MzJfdCBkb21pZCwgaW50IGZv
cmNlKQo+PiAraW50IGxpYnhsX2RvbWFpbl9kZXN0cm95KGxpYnhsX2N0eCAqY3R4LCB1aW50MzJf
dCBkb21pZCkKPj4gwqB7Cj4+IMKgIMKgIMKgbGlieGxfX2djIGdjID0gTElCWExfSU5JVF9HQyhj
dHgpOwo+PiDCoCDCoCDCoGxpYnhsX2RvbWluZm8gZG9taW5mbzsKPj4gQEAgLTc2Nyw3ICs3Njcs
NyBAQCBpbnQgbGlieGxfZG9tYWluX2Rlc3Ryb3kobGlieGxfY3R4ICpjdHgsCj4+Cj4+IMKgIMKg
IMKgIMKgIMKgbGlieGxfX3FtcF9jbGVhbnVwKCZnYywgZG9taWQpOwo+PiDCoCDCoCDCoH0KPj4g
LSDCoCDCoGlmIChsaWJ4bF9fZGV2aWNlc19kZXN0cm95KCZnYywgZG9taWQsIGZvcmNlKSA8IDAp
Cj4+ICsgwqAgwqBpZiAobGlieGxfX2RldmljZXNfZGVzdHJveSgmZ2MsIGRvbWlkLCAxKSA8IDAp
Cj4KPiBJZiBJJ20gbm90IG1pc3Npbmcgc29tZXRoaW5nIHRoaXMgc2VlbXMgdG8gYmUgdGhlIG9u
bHkgY2FsbGVyIG9mCj4gbGlieGxfX2RldmljZV9kZXN0cm95LiBXZSBjb3VsZCBrZWVwIHB1c2hp
bmcgdGhpcyBjaGFuZ2UgZG93biBhbmQgcmVtb3ZlCj4gdGhlIGZvcmNlIHBhcmFtIGhlcmUgdG9v
IHdoaWNoIGluIHR1cm5zIHJlbW92ZXMgYSBidW5jaCBvZiBjb2RlIGZyb20KPiBsaWJ4bF9fZGV2
aWNlc19kZXN0cm95IGFuZCBtYWtlcyBpdCBiZWhhdmUgbGlrZSBpdHMgbmFtZSBzdWdnZXN0cy4K
CkkndmUgYWxyZWFkeSBjcmVhdGVkIGFub3RoZXIgcGF0Y2ggdGhhdCBjaGFuZ2VzIHRoZSBzZW1h
bnRpY3Mgb2YKbGlieGxfX2RldmljZV9kZXN0cm95IGFuZCByZW1vdmVzIHRoZSBmb3JjZSBmbGFn
IGFuZCBhbGwgdGhlCnVubmVjZXNzYXJ5IGNvZGUuIElmIG5vIG9uZSBoYXMgYW4gb2JqZWN0aW9u
IGFib3V0IHRoaXMgY2hhbmdlIEkgd2lsbApyZXNlbmQgdGhlIHNlcmllcyBsYXRlciB3aXRoIHRo
aXMgcGF0Y2guCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
XwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tCmh0
dHA6Ly9saXN0cy54ZW5zb3VyY2UuY29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Mon Dec 05 10:49:12 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 10:49:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXW6M-0001vo-Me; Mon, 05 Dec 2011 10:48:50 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RXW6L-0001vj-Gl
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 10:48:49 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1323082051!46582505!1
X-Originating-IP: [209.85.210.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4852 invoked from network); 5 Dec 2011 10:47:32 -0000
Received: from mail-pz0-f43.google.com (HELO mail-pz0-f43.google.com)
	(209.85.210.43)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Dec 2011 10:47:32 -0000
Received: by dadz13 with SMTP id z13so23959281dad.30
	for <xen-devel@lists.xensource.com>;
	Mon, 05 Dec 2011 02:48:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=S5GowHl/l61wkdsmwnTsq53swx2LbNilPklcggLS3Ew=;
	b=xvTetQLO5P65+q0tfc6FjalZmJqYMTXD3Ni8hbz/MpIHvc31wm7bKdh2Hoc0nX6E8B
	t+ri4ns70eCui7uIPeMvLxBiZaxjoPsbz8psWFmnnG4Cf8gpK9feFcQRIH1sc/oxNSgg
	sBd9jrs5Vn/t/aqgzdclvAa2il4roHB8ZR+1Y=
MIME-Version: 1.0
Received: by 10.68.73.65 with SMTP id j1mr22134129pbv.98.1323082087715; Mon,
	05 Dec 2011 02:48:07 -0800 (PST)
Received: by 10.142.43.18 with HTTP; Mon, 5 Dec 2011 02:48:07 -0800 (PST)
In-Reply-To: <1323080650.29870.170.camel@zakaz.uk.xensource.com>
References: <patchbomb.1323079804@loki.upc.es>
	<c0d51df66b829995c4eb.1323079806@loki.upc.es>
	<1323080650.29870.170.camel@zakaz.uk.xensource.com>
Date: Mon, 5 Dec 2011 11:48:07 +0100
X-Google-Sender-Auth: EwtktR6_-aKOqO3NIgzXrPlyw8k
Message-ID: <CAPLaKK60aWMgzai0PEO8AyLQL+jXJXd9iUyMt40Q8eih14a78A@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 2 of 2] libxl: remove force parameter from
	libxl_domain_destroy
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

MjAxMS8xMi81IElhbiBDYW1wYmVsbCA8SWFuLkNhbXBiZWxsQGNpdHJpeC5jb20+Ogo+IERpZCBw
YXRjaCAxLzIgZ2V0IHN0dWNrIHNvbWV3aGVyZT8gSSd2ZSBub3Qgc2VlbiBpdCB5ZXQuCj4KPiBP
biBNb24sIDIwMTEtMTItMDUgYXQgMTA6MTAgKzAwMDAsIFJvZ2VyIFBhdSBNb25uZSB3cm90ZToK
Pj4gIyBIRyBjaGFuZ2VzZXQgcGF0Y2gKPj4gIyBVc2VyIFJvZ2VyIFBhdSBNb25uZSA8cm9nZXIu
cGF1QGVudGVsLnVwYy5lZHU+Cj4+ICMgRGF0ZSAxMzIzMDc5NjA1IC0zNjAwCj4+ICMgTm9kZSBJ
RCBjMGQ1MWRmNjZiODI5OTk1YzRlYjM5MDJiNWI5OTE0YzcxMGE2YzAxCj4+ICMgUGFyZW50IMKg
YmM5MGNmZDhkZDIyMGQ2OWQwOWNmOTRhM2QzOWZmM2NlZjc2ZDAyMQo+PiBsaWJ4bDogcmVtb3Zl
IGZvcmNlIHBhcmFtZXRlciBmcm9tIGxpYnhsX2RvbWFpbl9kZXN0cm95Cj4+Cj4+IFNpbmNlIGEg
ZGVzdHJveSBpcyBjb25zaWRlcmVkIGEgZm9yY2VkIHNodXRkb3duLCB0aGVyZSdzIG5vIHBvaW50
IGluCj4+IHBhc3NpbmcgYSBmb3JjZSBwYXJhbWV0ZXIuIEFsbCB0aGUgb2NjdXJlbmNlcyBvZiB0
aGlzIGZ1bmN0aW9uIGhhdmUKPj4gYmVlbiByZXBsYWNlZCB3aXRoIHRoZSBwcm9wZXIgc3ludGF4
Lgo+Cj4gSSdtIGEgbGl0dGxlIGNvbmNlcm5lZCB3aXRoIHRoZSBjaGFuZ2UgaW4gbGlieGxfX2Rl
c3Ryb3lfZGV2aWNlX21vZGVsLAo+IG1vc3RseSBiZWNhdXNlIEkgZG9uJzt0IGtub3cgd2hhdCB0
aGUgZXhwZWN0ZWQgc2VtYW50aWNzIG9mIGEgc3R1YiBkb20KPiBzaHV0ZG93biBhcmUuIFBlcmhh
cHMgaXQgaXMgZmluZSB0byBzaG9vdCBzdWNoIGEgZG9tYWluIGluIHRoZSBoZWFkCj4gd2l0aG91
dCBwcmV2aW91c2x5IGdpdmluZyBhbiBvcHBvcnR1bml0eSB0byBzaHV0ZG93bj8KCkknbSBzb3Jy
eSwgYnV0IEkgZG9uJ3Qga25vdyBhYm91dCBzdHViZG9tcywgdGhleSBhcmUgbm90IHdvcmtpbmcg
dW5kZXIKTmV0QlNEICp5ZXQqLCBJIHdpbGwgcHJvYmFibHkgZ2V0IHdpdGggdGhpcyBvbmNlIEkg
ZmluaXNoIHBvcnRpbmcKbGlieGwgKG9yIGEgdXNlcnNwYWNlIGJsa3RhcCBpbXBsZW1lbnRhdGlv
biwgdGhhdCdzIGFsc28gcXVpdGUKb3V0c3RhbmRpbmcpLgoKPj4KPj4gU2lnbmVkLW9mZi1ieTog
Um9nZXIgUGF1IE1vbm5lIDxyb2dlci5wYXVAZW50ZWwudXBjLmVkdT4KPj4KPj4gZGlmZiAtciBi
YzkwY2ZkOGRkMjIgLXIgYzBkNTFkZjY2YjgyIHRvb2xzL2xpYnhsL2xpYnhsLmMKPj4gLS0tIGEv
dG9vbHMvbGlieGwvbGlieGwuYyDCoCDCoCBNb24gRGVjIDA1IDExOjA2OjIzIDIwMTEgKzAxMDAK
Pj4gKysrIGIvdG9vbHMvbGlieGwvbGlieGwuYyDCoCDCoCBNb24gRGVjIDA1IDExOjA2OjQ1IDIw
MTEgKzAxMDAKPj4gQEAgLTcxOCw3ICs3MTgsNyBAQCBpbnQgbGlieGxfZXZlbnRfZ2V0X2Rpc2tf
ZWplY3RfaW5mbyhsaWJ4Cj4+IMKgIMKgIMKgcmV0dXJuIDE7Cj4+IMKgfQo+Pgo+PiAtaW50IGxp
YnhsX2RvbWFpbl9kZXN0cm95KGxpYnhsX2N0eCAqY3R4LCB1aW50MzJfdCBkb21pZCwgaW50IGZv
cmNlKQo+PiAraW50IGxpYnhsX2RvbWFpbl9kZXN0cm95KGxpYnhsX2N0eCAqY3R4LCB1aW50MzJf
dCBkb21pZCkKPj4gwqB7Cj4+IMKgIMKgIMKgbGlieGxfX2djIGdjID0gTElCWExfSU5JVF9HQyhj
dHgpOwo+PiDCoCDCoCDCoGxpYnhsX2RvbWluZm8gZG9taW5mbzsKPj4gQEAgLTc2Nyw3ICs3Njcs
NyBAQCBpbnQgbGlieGxfZG9tYWluX2Rlc3Ryb3kobGlieGxfY3R4ICpjdHgsCj4+Cj4+IMKgIMKg
IMKgIMKgIMKgbGlieGxfX3FtcF9jbGVhbnVwKCZnYywgZG9taWQpOwo+PiDCoCDCoCDCoH0KPj4g
LSDCoCDCoGlmIChsaWJ4bF9fZGV2aWNlc19kZXN0cm95KCZnYywgZG9taWQsIGZvcmNlKSA8IDAp
Cj4+ICsgwqAgwqBpZiAobGlieGxfX2RldmljZXNfZGVzdHJveSgmZ2MsIGRvbWlkLCAxKSA8IDAp
Cj4KPiBJZiBJJ20gbm90IG1pc3Npbmcgc29tZXRoaW5nIHRoaXMgc2VlbXMgdG8gYmUgdGhlIG9u
bHkgY2FsbGVyIG9mCj4gbGlieGxfX2RldmljZV9kZXN0cm95LiBXZSBjb3VsZCBrZWVwIHB1c2hp
bmcgdGhpcyBjaGFuZ2UgZG93biBhbmQgcmVtb3ZlCj4gdGhlIGZvcmNlIHBhcmFtIGhlcmUgdG9v
IHdoaWNoIGluIHR1cm5zIHJlbW92ZXMgYSBidW5jaCBvZiBjb2RlIGZyb20KPiBsaWJ4bF9fZGV2
aWNlc19kZXN0cm95IGFuZCBtYWtlcyBpdCBiZWhhdmUgbGlrZSBpdHMgbmFtZSBzdWdnZXN0cy4K
CkkndmUgYWxyZWFkeSBjcmVhdGVkIGFub3RoZXIgcGF0Y2ggdGhhdCBjaGFuZ2VzIHRoZSBzZW1h
bnRpY3Mgb2YKbGlieGxfX2RldmljZV9kZXN0cm95IGFuZCByZW1vdmVzIHRoZSBmb3JjZSBmbGFn
IGFuZCBhbGwgdGhlCnVubmVjZXNzYXJ5IGNvZGUuIElmIG5vIG9uZSBoYXMgYW4gb2JqZWN0aW9u
IGFib3V0IHRoaXMgY2hhbmdlIEkgd2lsbApyZXNlbmQgdGhlIHNlcmllcyBsYXRlciB3aXRoIHRo
aXMgcGF0Y2guCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
XwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tCmh0
dHA6Ly9saXN0cy54ZW5zb3VyY2UuY29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Mon Dec 05 10:50:28 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 10:50:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXW7X-0001yv-5M; Mon, 05 Dec 2011 10:50:03 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RXW7V-0001yi-U3
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 10:50:02 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1323081398!6107260!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjAyNg==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24400 invoked from network); 5 Dec 2011 10:36:38 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Dec 2011 10:36:38 -0000
X-IronPort-AV: E=Sophos;i="4.71,298,1320624000"; 
   d="scan'208";a="9285167"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Dec 2011 10:36:36 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Mon, 5 Dec 2011
	10:36:36 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau Monne <roger.pau@entel.upc.edu>
Date: Mon, 5 Dec 2011 10:36:36 +0000
In-Reply-To: <1323080650.29870.170.camel@zakaz.uk.xensource.com>
References: <patchbomb.1323079804@loki.upc.es>
	<c0d51df66b829995c4eb.1323079806@loki.upc.es>
	<1323080650.29870.170.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323081396.29870.171.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 2 of 2] libxl: remove force parameter from
 libxl_domain_destroy
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2011-12-05 at 10:24 +0000, Ian Campbell wrote:
> Did patch 1/2 get stuck somewhere? I've not seen it yet.

NM. Got it now, thanks.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 10:50:28 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 10:50:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXW7X-0001yv-5M; Mon, 05 Dec 2011 10:50:03 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RXW7V-0001yi-U3
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 10:50:02 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1323081398!6107260!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjAyNg==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24400 invoked from network); 5 Dec 2011 10:36:38 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Dec 2011 10:36:38 -0000
X-IronPort-AV: E=Sophos;i="4.71,298,1320624000"; 
   d="scan'208";a="9285167"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Dec 2011 10:36:36 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Mon, 5 Dec 2011
	10:36:36 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau Monne <roger.pau@entel.upc.edu>
Date: Mon, 5 Dec 2011 10:36:36 +0000
In-Reply-To: <1323080650.29870.170.camel@zakaz.uk.xensource.com>
References: <patchbomb.1323079804@loki.upc.es>
	<c0d51df66b829995c4eb.1323079806@loki.upc.es>
	<1323080650.29870.170.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323081396.29870.171.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 2 of 2] libxl: remove force parameter from
 libxl_domain_destroy
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2011-12-05 at 10:24 +0000, Ian Campbell wrote:
> Did patch 1/2 get stuck somewhere? I've not seen it yet.

NM. Got it now, thanks.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 10:52:56 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 10:52:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXWA5-0002Au-35; Mon, 05 Dec 2011 10:52:41 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RXWA4-0002AS-46
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 10:52:40 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1323082315!4276526!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjAyNg==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19922 invoked from network); 5 Dec 2011 10:51:55 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Dec 2011 10:51:55 -0000
X-IronPort-AV: E=Sophos;i="4.71,298,1320624000"; 
   d="scan'208";a="9285654"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Dec 2011 10:51:55 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 5 Dec 2011 10:51:55 +0000
Date: Mon, 5 Dec 2011 10:52:56 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: xen.org <ian.jackson@eu.citrix.com>
In-Reply-To: <E1RXJuU-0005D7-Nc@woking.xci-test.com>
Message-ID: <alpine.DEB.2.00.1112051049260.31179@kaball-desktop>
References: <E1RXJuU-0005D7-Nc@woking.xci-test.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Keir
	\(Xen.org\)" <keir@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [xen-unstable bisection] complete
	test-amd64-amd64-win
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Sun, 4 Dec 2011, xen.org wrote:
> branch xen-unstable
> xen branch xen-unstable
> job test-amd64-amd64-win
> test guest-saverestore
> 
> Tree: linux git://github.com/jsgf/linux-xen.git
> Tree: qemu git://hg.uk.xensource.com/HG/qemu-xen-unstable.git
> Tree: xen http://xenbits.xen.org/staging/xen-unstable.hg
> 
> *** Found and reproduced problem changeset ***
> 
>   Bug is in tree:  qemu git://hg.uk.xensource.com/HG/qemu-xen-unstable.git
>   Bug introduced:  13b06e700528b1c4258ce5d768d69b0d499f75ca
>   Bug not present: 89daacab7035d408f32f2cb1acf68c96d6cbefed
> 
> 
>   commit 13b06e700528b1c4258ce5d768d69b0d499f75ca
>   Author: Sefano Stabellini <stefano.stabellini@eu.citrix.com>
>   Date:   Thu Dec 1 17:52:01 2011 +0000
>   
>       xen: don't initialize the RTC timers if xen is available
>       
>       Xen doesn't need full RTC emulation in Qemu because the RTC is already
>       emulated by the hypervisor. Hence don't initialize the RTC timers when Xen is
>       available so that Qemu doesn't need to wake up needlessly.
>       
>       Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> 

the patch above broke save/restore, I am about the send out another
patch to fix it

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 10:52:56 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 10:52:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXWA5-0002Au-35; Mon, 05 Dec 2011 10:52:41 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RXWA4-0002AS-46
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 10:52:40 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1323082315!4276526!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjAyNg==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19922 invoked from network); 5 Dec 2011 10:51:55 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Dec 2011 10:51:55 -0000
X-IronPort-AV: E=Sophos;i="4.71,298,1320624000"; 
   d="scan'208";a="9285654"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Dec 2011 10:51:55 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 5 Dec 2011 10:51:55 +0000
Date: Mon, 5 Dec 2011 10:52:56 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: xen.org <ian.jackson@eu.citrix.com>
In-Reply-To: <E1RXJuU-0005D7-Nc@woking.xci-test.com>
Message-ID: <alpine.DEB.2.00.1112051049260.31179@kaball-desktop>
References: <E1RXJuU-0005D7-Nc@woking.xci-test.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Keir
	\(Xen.org\)" <keir@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [xen-unstable bisection] complete
	test-amd64-amd64-win
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Sun, 4 Dec 2011, xen.org wrote:
> branch xen-unstable
> xen branch xen-unstable
> job test-amd64-amd64-win
> test guest-saverestore
> 
> Tree: linux git://github.com/jsgf/linux-xen.git
> Tree: qemu git://hg.uk.xensource.com/HG/qemu-xen-unstable.git
> Tree: xen http://xenbits.xen.org/staging/xen-unstable.hg
> 
> *** Found and reproduced problem changeset ***
> 
>   Bug is in tree:  qemu git://hg.uk.xensource.com/HG/qemu-xen-unstable.git
>   Bug introduced:  13b06e700528b1c4258ce5d768d69b0d499f75ca
>   Bug not present: 89daacab7035d408f32f2cb1acf68c96d6cbefed
> 
> 
>   commit 13b06e700528b1c4258ce5d768d69b0d499f75ca
>   Author: Sefano Stabellini <stefano.stabellini@eu.citrix.com>
>   Date:   Thu Dec 1 17:52:01 2011 +0000
>   
>       xen: don't initialize the RTC timers if xen is available
>       
>       Xen doesn't need full RTC emulation in Qemu because the RTC is already
>       emulated by the hypervisor. Hence don't initialize the RTC timers when Xen is
>       available so that Qemu doesn't need to wake up needlessly.
>       
>       Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> 

the patch above broke save/restore, I am about the send out another
patch to fix it

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 10:54:16 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 10:54:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXWBM-0002HS-Iq; Mon, 05 Dec 2011 10:54:00 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RXWBL-0002HA-Ir
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 10:53:59 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1323082395!4221245!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjAyNg==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21912 invoked from network); 5 Dec 2011 10:53:15 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Dec 2011 10:53:15 -0000
X-IronPort-AV: E=Sophos;i="4.71,298,1320624000"; 
   d="scan'208";a="9285717"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Dec 2011 10:53:14 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 5 Dec 2011 10:53:14 +0000
Date: Mon, 5 Dec 2011 10:54:26 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: <xen-devel@lists.xensource.com>
Message-ID: <alpine.DEB.2.00.1112051053180.31179@kaball-desktop>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] qemu_timer_pending/qemu_get_timer: cope with NULL timers
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

qemu_timer_pending and qemu_get_timer: don't crash if the timer passed
as an argument is NULL.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

diff --git a/vl.c b/vl.c
index f07a659..f3b3d02 100644
--- a/vl.c
+++ b/vl.c
@@ -1201,6 +1201,10 @@ void qemu_mod_timer(QEMUTimer *ts, int64_t expire_time)
 int qemu_timer_pending(QEMUTimer *ts)
 {
     QEMUTimer *t;
+
+    if (ts == NULL)
+        return 0;
+
     for(t = active_timers[ts->clock->type]; t != NULL; t = t->next) {
         if (t == ts)
             return 1;
@@ -1272,6 +1276,9 @@ void qemu_get_timer(QEMUFile *f, QEMUTimer *ts)
 {
     uint64_t expire_time;
 
+    if (ts == NULL)
+        return;
+
     expire_time = qemu_get_be64(f);
     if (expire_time != -1) {
         qemu_mod_timer(ts, expire_time);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 10:54:16 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 10:54:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXWBM-0002HS-Iq; Mon, 05 Dec 2011 10:54:00 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RXWBL-0002HA-Ir
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 10:53:59 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1323082395!4221245!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjAyNg==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21912 invoked from network); 5 Dec 2011 10:53:15 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Dec 2011 10:53:15 -0000
X-IronPort-AV: E=Sophos;i="4.71,298,1320624000"; 
   d="scan'208";a="9285717"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Dec 2011 10:53:14 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 5 Dec 2011 10:53:14 +0000
Date: Mon, 5 Dec 2011 10:54:26 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: <xen-devel@lists.xensource.com>
Message-ID: <alpine.DEB.2.00.1112051053180.31179@kaball-desktop>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] qemu_timer_pending/qemu_get_timer: cope with NULL timers
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

qemu_timer_pending and qemu_get_timer: don't crash if the timer passed
as an argument is NULL.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

diff --git a/vl.c b/vl.c
index f07a659..f3b3d02 100644
--- a/vl.c
+++ b/vl.c
@@ -1201,6 +1201,10 @@ void qemu_mod_timer(QEMUTimer *ts, int64_t expire_time)
 int qemu_timer_pending(QEMUTimer *ts)
 {
     QEMUTimer *t;
+
+    if (ts == NULL)
+        return 0;
+
     for(t = active_timers[ts->clock->type]; t != NULL; t = t->next) {
         if (t == ts)
             return 1;
@@ -1272,6 +1276,9 @@ void qemu_get_timer(QEMUFile *f, QEMUTimer *ts)
 {
     uint64_t expire_time;
 
+    if (ts == NULL)
+        return;
+
     expire_time = qemu_get_be64(f);
     if (expire_time != -1) {
         qemu_mod_timer(ts, expire_time);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 10:59:09 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 10: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.xensource.com>)
	id 1RXWG5-0002aq-AY; Mon, 05 Dec 2011 10:58:53 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <svenvan.van@gmail.com>) id 1RXWG2-0002aU-OA
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 10:58:51 +0000
X-Env-Sender: svenvan.van@gmail.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1323082685!4222114!1
X-Originating-IP: [209.85.161.43]
X-SpamReason: No, hits=2.0 required=7.0 tests=BODY_RANDOM_LONG,
	HTML_00_10, HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,
	spamassassin: 
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9032 invoked from network); 5 Dec 2011 10:58:05 -0000
Received: from mail-fx0-f43.google.com (HELO mail-fx0-f43.google.com)
	(209.85.161.43)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Dec 2011 10:58:05 -0000
Received: by fagn18 with SMTP id n18so6285820fag.30
	for <xen-devel@lists.xensource.com>;
	Mon, 05 Dec 2011 02:58:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=C8h490p655aH7WuEIgbPip12fZRAvVEt6vR7MntTD1w=;
	b=NMxY2tbpSe/UPO2xeKGI817H/JIXZlhim2j2uhSSaKuijNv918VLrBBPgZcpcNblRh
	h1SxsmZrqwNouap8+Kczz7wEOAoUDflP1XB70R4lGDKAAUkDT/CT8/Lz4jFzejlD1ULn
	RA8VPBJSz0MtWZpAWFWQ1S5qIR1KrJThP4bYo=
MIME-Version: 1.0
Received: by 10.180.0.39 with SMTP id 7mr7442290wib.37.1323082684889; Mon, 05
	Dec 2011 02:58:04 -0800 (PST)
Received: by 10.223.119.80 with HTTP; Mon, 5 Dec 2011 02:58:04 -0800 (PST)
Date: Mon, 5 Dec 2011 11:58:04 +0100
Message-ID: <CAJmQyTik==F8PuR+j3SVRjxQQ_aVLjHeBZdboekD3iOVRR9Y0A@mail.gmail.com>
From: svenvan svenvan <svenvan.van@gmail.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] xen 4.0.1/w 2.6.32 swapper: page allocation failure
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============5941742178561443624=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============5941742178561443624==
Content-Type: multipart/alternative; boundary=bcaec52c5f3970fb7604b3563182

--bcaec52c5f3970fb7604b3563182
Content-Type: text/plain; charset=ISO-8859-1

hi
xen 4.0.1 w/2.6.32.41

Last week dom0 experienced an hard crash and box need to be restarted
manually (despite kernel.panic=20).
Serial console was not setup, only netconsole.  No relevant entries through
netconsole, but analyzing logs I see some crashes twenty minutes before
fatal hang.

Dec  2 01:29:39 xenhost-rack1 kernel: [4437064.011963] Call Trace:
Dec  2 01:29:39 xenhost-rack1 kernel: [4437064.011964]  <IRQ>
[<ffffffff810e5f8e>] __alloc_pages_nodemask+0x586/0x600
Dec  2 01:29:39 xenhost-rack1 kernel: [4437064.011976]
[<ffffffff8110dd6e>] alloc_slab_page+0x19/0x1b
Dec  2 01:29:39 xenhost-rack1 kernel: [4437064.011980]
[<ffffffff8110f632>] __slab_alloc+0x167/0x4b4
Dec  2 01:29:39 xenhost-rack1 kernel: [4437064.011983]
[<ffffffff81038d75>] ? xen_force_evtchn_callback+0xd/0xf
Dec  2 01:29:39 xenhost-rack1 kernel: [4437064.011987]
[<ffffffff8149064d>] ? find_skb+0x32/0x7d
Dec  2 01:29:39 xenhost-rack1 kernel: [4437064.011991]
[<ffffffff811113db>] __kmalloc_track_caller+0xfd/0x17e
Dec  2 01:29:39 xenhost-rack1 kernel: [4437064.011994]
[<ffffffff8103947f>] ? xen_restore_fl_direct_end+0x0/0x1
Dec  2 01:29:39 xenhost-rack1 kernel: [4437064.011997]
[<ffffffff8149064d>] ? find_skb+0x32/0x7d
Dec  2 01:29:39 xenhost-rack1 kernel: [4437064.011999]
[<ffffffff81039492>] ? check_events+0x12/0x20
Dec  2 01:29:39 xenhost-rack1 kernel: [4437064.012003]
[<ffffffff81479851>] __alloc_skb+0x69/0x155
Dec  2 01:29:39 xenhost-rack1 kernel: [4437064.012005]
[<ffffffff8103947f>] ? xen_restore_fl_direct_end+0x0/0x1
Dec  2 01:29:39 xenhost-rack1 kernel: [4437064.012045]
[<ffffffff81039492>] ? check_events+0x12/0x20
Dec  2 01:29:39 xenhost-rack1 kernel: [4437064.012050]
[<ffffffff815b3fb0>] printk+0x3c/0x3e
Dec  2 01:29:39 xenhost-rack1 kernel: [4437064.012052]
[<ffffffff810775c6>] ? release_console_sem+0x1b1/0x1e2
Dec  2 01:29:39 xenhost-rack1 kernel: [4437064.012057]
[<ffffffff8103007f>] ? vmx_set_cr0+0x313/0x4bc
Dec  2 01:29:39 xenhost-rack1 kernel: [4437064.012061]
[<ffffffff814f8de0>] dump_packet+0x310/0x794
Dec  2 01:29:39 xenhost-rack1 kernel: [4437064.012065]
[<ffffffff811d8b90>] ? selinux_ip_postroute+0x2e/0x1d6
Dec  2 01:29:39 xenhost-rack1 kernel: [4437064.012068]
[<ffffffff815b6005>] ? _spin_unlock_irqrestore+0x37/0x39
Dec  2 01:29:39 xenhost-rack1 kernel: [4437064.012071]
[<ffffffff815b3fb0>] ? printk+0x3c/0x3e
Dec  2 01:29:39 xenhost-rack1 kernel: [4437064.012074]
[<ffffffff814f93c3>] ipt_log_packet+0x15f/0x185
Dec  2 01:29:39 xenhost-rack1 kernel: [4437064.012077]
[<ffffffff814f942e>] log_tg+0x45/0x4b
Dec  2 01:29:39 xenhost-rack1 kernel: [4437064.012080]
[<ffffffff814b3067>] ? conntrack_mt_v2+0x1b/0x1d
Dec  2 01:29:39 xenhost-rack1 kernel: [4437064.012121]
[<ffffffff81543be2>] ? br_forward_finish+0x0/0x53
Dec  2 01:29:39 xenhost-rack1 kernel: [4437064.012124]
[<ffffffff81543c35>] ? __br_forward+0x0/0x9c
Dec  2 01:29:39 xenhost-rack1 kernel: [4437064.012127]
[<ffffffff81543cbe>] __br_forward+0x89/0x9c
Dec  2 01:29:39 xenhost-rack1 kernel: [4437064.012129]
[<ffffffff814792e6>] ? skb_clone+0x58/0x5d
Dec  2 01:29:39 xenhost-rack1 kernel: [4437064.012132]
[<ffffffff81543b22>] br_flood+0xa2/0xbb
Dec  2 01:29:39 xenhost-rack1 kernel: [4437064.012135]
[<ffffffff81543b4b>] br_flood_forward+0x10/0x12
Dec  2 01:29:39 xenhost-rack1 kernel: [4437064.012137]
[<ffffffff81544872>] br_handle_frame_finish+0x13a/0x151
Dec  2 01:29:39 xenhost-rack1 kernel: [4437064.012141]
[<ffffffff81548616>] br_nf_pre_routing_finish+0x249/0x258
Dec  2 01:29:39 xenhost-rack1 kernel: [4437064.012144]
[<ffffffff815492d3>] br_nf_pre_routing+0x55d/0x57e
Dec  2 01:29:39 xenhost-rack1 kernel: [4437064.012147]
[<ffffffff8149fe3e>] nf_iterate+0x41/0x84
Dec  2 01:29:39 xenhost-rack1 kernel: [4437064.012150]
[<ffffffff81544738>] ? br_handle_frame_finish+0x0/0x151
Dec  2 01:29:39 xenhost-rack1 kernel: [4437064.012155]
[<ffffffff81544738>] ? br_handle_frame_finish+0x0/0x151
Dec  2 01:29:39 xenhost-rack1 kernel: [4437064.012158]
[<ffffffff81544a51>] br_handle_frame+0x1c8/0x1ef
Dec  2 01:29:39 xenhost-rack1 kernel: [4437064.012163]
[<ffffffff81482270>] netif_receive_skb+0x330/0x3fc
Dec  2 01:29:39 xenhost-rack1 kernel: [4437064.012165]
[<ffffffff81479ec5>] ? __netdev_alloc_skb+0x1d/0x3a
Dec  2 01:29:39 xenhost-rack1 kernel: [4437064.012169]
[<ffffffff814824bc>] napi_skb_finish+0x24/0x38
Dec  2 01:29:39 xenhost-rack1 kernel: [4437064.012172]
[<ffffffff81482900>] napi_gro_receive+0x2a/0x2f
Dec  2 01:29:39 xenhost-rack1 kernel: [4437064.012175]
[<ffffffff8135aa86>] e1000_receive_skb+0x43/0x4b
Dec  2 01:29:39 xenhost-rack1 kernel: [4437064.012178]
[<ffffffff8135c557>] e1000_clean_rx_irq+0x212/0x2b7
Dec  2 01:29:39 xenhost-rack1 kernel: [4437064.012181]
[<ffffffff8135b11f>] e1000_clean+0x75/0x21f
Dec  2 01:29:39 xenhost-rack1 kernel: [4437064.012185]
[<ffffffff8127e67c>] ? HYPERVISOR_physdev_op+0x16/0x4c
Dec  2 01:29:39 xenhost-rack1 kernel: [4437064.012194]
[<ffffffff8107d4ca>] __do_softirq+0xee/0x1c4
Dec  2 01:29:39 xenhost-rack1 kernel: [4437064.012199]
[<ffffffff8103de2c>] call_softirq+0x1c/0x30
Dec  2 01:29:39 xenhost-rack1 kernel: [4437064.012202]
[<ffffffff8103f4bd>] do_softirq+0x61/0xc2
Dec  2 01:29:39 xenhost-rack1 kernel: [4437064.012206]
[<ffffffff8107d311>] irq_exit+0x36/0x78
Dec  2 01:29:39 xenhost-rack1 kernel: [4437064.012208]
[<ffffffff8127f297>] xen_evtchn_do_upcall+0x37/0x47
Dec  2 01:29:39 xenhost-rack1 kernel: [4437064.012212]
[<ffffffff8103de7e>] xen_do_hypervisor_callback+0x1e/0x30
Dec  2 01:29:39 xenhost-rack1 kernel: [4437064.012213]  <EOI>
[<ffffffff810093aa>] ? hypercall_page+0x3aa/0x1000
Dec  2 01:29:39 xenhost-rack1 kernel: [4437064.012221]
[<ffffffff810093aa>] ? hypercall_page+0x3aa/0x1000
Dec  2 01:29:39 xenhost-rack1 kernel: [4437064.012224]
[<ffffffff810093aa>] ? hypercall_page+0x3aa/0x1000
Dec  2 01:29:39 xenhost-rack1 kernel: [4437064.012226]
[<ffffffff81038dbb>] ? xen_safe_halt+0x10/0x1a
Dec  2 01:29:39 xenhost-rack1 kernel: [4437064.012232]
[<ffffffff8103bde6>] ? cpu_idle+0x66/0xa4
Dec  2 01:29:39 xenhost-rack1 kernel: [4437064.012237]
[<ffffffff81594359>] ? rest_init+0x6d/0x6f
Dec  2 01:29:40 xenhost-rack1 kernel: [4437064.012241]
[<ffffffff81976dd5>] ? start_kernel+0x43c/0x447
Dec  2 01:29:40 xenhost-rack1 kernel: [4437064.012245]
[<ffffffff819762c1>] ? x86_64_start_reservations+0xac/0xb0
Dec  2 01:29:40 xenhost-rack1 kernel: [4437064.012248]
[<ffffffff8197ab24>] ? xen_start_kernel+0x5ea/0x5f1
Dec  2 01:29:40 xenhost-rack1 kernel: [4437064.012250] Mem-Info:
Dec  2 01:29:40 xenhost-rack1 kernel: [4437064.012251] DMA per-cpu:
Dec  2 01:29:40 xenhost-rack1 kernel: [4437064.012253] CPU    0: hi:    0,
btch:   1 usd:   0
Dec  2 01:29:40 xenhost-rack1 kernel: [4437064.012255] CPU    1: hi:    0,
btch:   1 usd:   0
Dec  2 01:29:40 xenhost-rack1 kernel: [4437064.012257] CPU    2: hi:    0,
btch:   1 usd:   0
Dec  2 01:29:40 xenhost-rack1 kernel: [4437064.012258] CPU    3: hi:    0,
btch:   1 usd:   0
Dec  2 01:29:40 xenhost-rack1 kernel: [4437064.012260] DMA32 per-cpu:
Dec  2 01:29:40 xenhost-rack1 kernel: [4437064.012261] CPU    0: hi:  186,
btch:  31 usd:  61
Dec  2 01:29:40 xenhost-rack1 kernel: [4437064.012263] CPU    1: hi:  186,
btch:  31 usd:  58
Dec  2 01:29:40 xenhost-rack1 kernel: [4437064.012265] CPU    2: hi:  186,
btch:  31 usd:  66
Dec  2 01:29:40 xenhost-rack1 kernel: [4437064.012267] CPU    3: hi:  186,
btch:  31 usd: 128
Dec  2 01:29:40 xenhost-rack1 kernel: [4437064.012268] Normal per-cpu:
Dec  2 01:29:40 xenhost-rack1 kernel: [4437064.012269] CPU    0: hi:  186,
btch:  31 usd:   0
Dec  2 01:29:40 xenhost-rack1 kernel: [4437064.012271] CPU    1: hi:  186,
btch:  31 usd:   0
Dec  2 01:29:40 xenhost-rack1 kernel: [4437064.012273] CPU    2: hi:  186,
btch:  31 usd:   0
Dec  2 01:29:40 xenhost-rack1 kernel: [4437064.012275] CPU    3: hi:  186,
btch:  31 usd:   0
Dec  2 01:29:40 xenhost-rack1 kernel: [4437064.012279] active_anon:3388
inactive_anon:14639 isolated_anon:0
Dec  2 01:29:40 xenhost-rack1 kernel: [4437064.012280]  active_file:70965
inactive_file:66104 isolated_file:0
Dec  2 01:29:40 xenhost-rack1 kernel: [4437064.012281]  unevictable:3570
dirty:1 writeback:148 unstable:0
Dec  2 01:29:40 xenhost-rack1 kernel: [4437064.012282]  free:13738
slab_reclaimable:10452 slab_unreclaimable:5582
Dec  2 01:29:40 xenhost-rack1 kernel: [4437064.012283]  mapped:1948
shmem:325 pagetables:1309 bounce:0
Dec  2 01:29:40 xenhost-rack1 kernel: [4437064.012288] DMA free:13972kB
min:16kB low:20kB high:24kB active_anon:0kB inactive_anon:0kB
active_file:0kB inactive_file:0kB unevictable:0kB isolated(anon):0kB
isolated(file):0kB present:13764kB mlocked:0kB dirty:0kB writeback:0kB
mapped:0kB shmem:0kB slab_reclaimable:0kB slab_unreclaimable:0kB
kernel_stack:0kB pagetables:0kB unstable:0kB bounce:0kB writeback_tmp:0kB
pages_scanned:0 all_unreclaimable? yes
Dec  2 01:29:40 xenhost-rack1 kernel: [4437064.012292] lowmem_reserve[]: 0
952 10042 10042
Dec  2 01:29:40 xenhost-rack1 kernel: [4437064.012300] DMA32 free:36792kB
min:1212kB low:1512kB high:1816kB active_anon:13552kB inactive_anon:58556kB
active_file:283860kB inactive_file:264416kB unevictable:14280kB
isolated(anon):0kB isolated(file):0kB present:975072kB mlocked:14280kB
dirty:4kB writeback:592kB mapped:7792kB shmem:1300kB
slab_reclaimable:41808kB slab_unreclaimable:19604kB kernel_stack:1208kB
pagetables:5236kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0
all_unreclaimable? no
Dec  2 01:29:40 xenhost-rack1 kernel: [4437064.012304] lowmem_reserve[]: 0
0 9090 9090
Dec  2 01:29:40 xenhost-rack1 kernel: [4437064.012311] Normal free:4188kB
min:11596kB low:14492kB high:17392kB active_anon:0kB inactive_anon:0kB
active_file:0kB inactive_file:0kB unevictable:0kB isolated(anon):0kB
isolated(file):0kB present:9308160kB mlocked:0kB dirty:0kB writeback:0kB
mapped:0kB shmem:0kB slab_reclaimable:0kB slab_unreclaimable:2724kB
kernel_stack:0kB pagetables:0kB unstable:0kB bounce:0kB writeback_tmp:0kB
pages_scanned:0 all_unreclaimable? no
Dec  2 01:29:40 xenhost-rack1 kernel: [4437064.012316] lowmem_reserve[]: 0
0 0 0
Dec  2 01:29:40 xenhost-rack1 kernel: [4437064.012318] DMA: 1*4kB 2*8kB
2*16kB 3*32kB 4*64kB 2*128kB 0*256kB 0*512kB 1*1024kB 0*2048kB 3*4096kB =
13972kB
Dec  2 01:29:40 xenhost-rack1 kernel: [4437064.012326] DMA32: 8114*4kB
535*8kB 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB
0*4096kB = 36736kB
Dec  2 01:29:40 xenhost-rack1 kernel: [4437064.012333] Normal: 1*4kB 1*8kB
1*16kB 0*32kB 1*64kB 0*128kB 2*256kB 1*512kB 1*1024kB 1*2048kB 0*4096kB =
4188kB
Dec  2 01:29:40 xenhost-rack1 kernel: [4437064.012340] 138450 total
pagecache pages
Dec  2 01:29:40 xenhost-rack1 kernel: [4437064.012342] 13 pages in swap
cache
Dec  2 01:29:40 xenhost-rack1 kernel: [4437064.012344] Swap cache stats:
add 21, delete 8, find 123000/123002
Dec  2 01:29:40 xenhost-rack1 kernel: [4437064.012345] Free swap  =
3905476kB
Dec  2 01:29:40 xenhost-rack1 kernel: [4437064.012347] Total swap =
3905528kB
Dec  2 01:29:40 xenhost-rack1 kernel: [4437064.035564] 2621440 pages RAM
Dec  2 01:29:40 xenhost-rack1 kernel: [4437064.035566] 2425336 pages
reserved
Dec  2 01:29:40 xenhost-rack1 kernel: [4437064.035568] 154640 pages shared
Dec  2 01:29:40 xenhost-rack1 kernel: [4437064.035569] 45402 pages
non-shared
Dec  2 01:29:40 xenhost-rack1 kernel: [4437064.035572] SLUB: Unable to
allocate memory on node -1 (gfp=0x20)
Dec  2 01:29:40 xenhost-rack1 kernel: [4437064.035574]   cache:
kmalloc-1024, object size: 1024, buffer size: 1024, default order: 2, min
order: 0
Dec  2 01:29:40 xenhost-rack1 kernel: [4437064.035577]   node 0: slabs:
870, objs: 6900, free: 0
Dec  2 01:29:40 xenhost-rack1 kernel: [4437064.035919] swapper: page
allocation failure. order:0, mode:0x4020
Dec  2 01:29:40 xenhost-rack1 kernel: [4437064.035923] Pid: 0, comm:
swapper Not tainted 2.6.32.41 #2
.....

it looks like an out of memory isn't it?
Not sure it this could be a xen bug, network driver issue or something else?

At the moment I have upgrade to 2.6.32.47.   Any help would be greatly
appreciated
thanks in advance

--bcaec52c5f3970fb7604b3563182
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

hi<br>xen 4.0.1 w/<a href=3D"http://2.6.32.41">2.6.32.41</a><br><br>Last we=
ek dom0 experienced an hard crash and box need to be restarted manually (de=
spite kernel.panic=3D20).<br>Serial console was not setup, only netconsole.=
=A0 No relevant entries through netconsole, but analyzing logs I see some c=
rashes twenty minutes before fatal hang.<br>
<br>Dec=A0 2 01:29:39 xenhost-rack1 kernel: [4437064.011963] Call Trace:<br=
>Dec=A0 2 01:29:39 xenhost-rack1 kernel: [4437064.011964]=A0 &lt;IRQ&gt;=A0=
 [&lt;ffffffff810e5f8e&gt;] __alloc_pages_nodemask+0x586/0x600<br>Dec=A0 2 =
01:29:39 xenhost-rack1 kernel: [4437064.011976]=A0 [&lt;ffffffff8110dd6e&gt=
;] alloc_slab_page+0x19/0x1b<br>
Dec=A0 2 01:29:39 xenhost-rack1 kernel: [4437064.011980]=A0 [&lt;ffffffff81=
10f632&gt;] __slab_alloc+0x167/0x4b4<br>Dec=A0 2 01:29:39 xenhost-rack1 ker=
nel: [4437064.011983]=A0 [&lt;ffffffff81038d75&gt;] ? xen_force_evtchn_call=
back+0xd/0xf<br>
Dec=A0 2 01:29:39 xenhost-rack1 kernel: [4437064.011987]=A0 [&lt;ffffffff81=
49064d&gt;] ? find_skb+0x32/0x7d<br>Dec=A0 2 01:29:39 xenhost-rack1 kernel:=
 [4437064.011991]=A0 [&lt;ffffffff811113db&gt;] __kmalloc_track_caller+0xfd=
/0x17e<br>
Dec=A0 2 01:29:39 xenhost-rack1 kernel: [4437064.011994]=A0 [&lt;ffffffff81=
03947f&gt;] ? xen_restore_fl_direct_end+0x0/0x1<br>Dec=A0 2 01:29:39 xenhos=
t-rack1 kernel: [4437064.011997]=A0 [&lt;ffffffff8149064d&gt;] ? find_skb+0=
x32/0x7d<br>
Dec=A0 2 01:29:39 xenhost-rack1 kernel: [4437064.011999]=A0 [&lt;ffffffff81=
039492&gt;] ? check_events+0x12/0x20<br>Dec=A0 2 01:29:39 xenhost-rack1 ker=
nel: [4437064.012003]=A0 [&lt;ffffffff81479851&gt;] __alloc_skb+0x69/0x155<=
br>Dec=A0 2 01:29:39 xenhost-rack1 kernel: [4437064.012005]=A0 [&lt;fffffff=
f8103947f&gt;] ? xen_restore_fl_direct_end+0x0/0x1<br>
Dec=A0 2 01:29:39 xenhost-rack1 kernel: [4437064.012045]=A0 [&lt;ffffffff81=
039492&gt;] ? check_events+0x12/0x20<br>Dec=A0 2 01:29:39 xenhost-rack1 ker=
nel: [4437064.012050]=A0 [&lt;ffffffff815b3fb0&gt;] printk+0x3c/0x3e<br>Dec=
=A0 2 01:29:39 xenhost-rack1 kernel: [4437064.012052]=A0 [&lt;ffffffff81077=
5c6&gt;] ? release_console_sem+0x1b1/0x1e2<br>
Dec=A0 2 01:29:39 xenhost-rack1 kernel: [4437064.012057]=A0 [&lt;ffffffff81=
03007f&gt;] ? vmx_set_cr0+0x313/0x4bc<br>Dec=A0 2 01:29:39 xenhost-rack1 ke=
rnel: [4437064.012061]=A0 [&lt;ffffffff814f8de0&gt;] dump_packet+0x310/0x79=
4<br>
Dec=A0 2 01:29:39 xenhost-rack1 kernel: [4437064.012065]=A0 [&lt;ffffffff81=
1d8b90&gt;] ? selinux_ip_postroute+0x2e/0x1d6<br>Dec=A0 2 01:29:39 xenhost-=
rack1 kernel: [4437064.012068]=A0 [&lt;ffffffff815b6005&gt;] ? _spin_unlock=
_irqrestore+0x37/0x39<br>
Dec=A0 2 01:29:39 xenhost-rack1 kernel: [4437064.012071]=A0 [&lt;ffffffff81=
5b3fb0&gt;] ? printk+0x3c/0x3e<br>Dec=A0 2 01:29:39 xenhost-rack1 kernel: [=
4437064.012074]=A0 [&lt;ffffffff814f93c3&gt;] ipt_log_packet+0x15f/0x185<br=
>Dec=A0 2 01:29:39 xenhost-rack1 kernel: [4437064.012077]=A0 [&lt;ffffffff8=
14f942e&gt;] log_tg+0x45/0x4b<br>
Dec=A0 2 01:29:39 xenhost-rack1 kernel: [4437064.012080]=A0 [&lt;ffffffff81=
4b3067&gt;] ? conntrack_mt_v2+0x1b/0x1d<br>Dec=A0 2 01:29:39 xenhost-rack1 =
kernel: [4437064.012121]=A0 [&lt;ffffffff81543be2&gt;] ? br_forward_finish+=
0x0/0x53<br>
Dec=A0 2 01:29:39 xenhost-rack1 kernel: [4437064.012124]=A0 [&lt;ffffffff81=
543c35&gt;] ? __br_forward+0x0/0x9c<br>Dec=A0 2 01:29:39 xenhost-rack1 kern=
el: [4437064.012127]=A0 [&lt;ffffffff81543cbe&gt;] __br_forward+0x89/0x9c<b=
r>Dec=A0 2 01:29:39 xenhost-rack1 kernel: [4437064.012129]=A0 [&lt;ffffffff=
814792e6&gt;] ? skb_clone+0x58/0x5d<br>
Dec=A0 2 01:29:39 xenhost-rack1 kernel: [4437064.012132]=A0 [&lt;ffffffff81=
543b22&gt;] br_flood+0xa2/0xbb<br>Dec=A0 2 01:29:39 xenhost-rack1 kernel: [=
4437064.012135]=A0 [&lt;ffffffff81543b4b&gt;] br_flood_forward+0x10/0x12<br=
>Dec=A0 2 01:29:39 xenhost-rack1 kernel: [4437064.012137]=A0 [&lt;ffffffff8=
1544872&gt;] br_handle_frame_finish+0x13a/0x151<br>
Dec=A0 2 01:29:39 xenhost-rack1 kernel: [4437064.012141]=A0 [&lt;ffffffff81=
548616&gt;] br_nf_pre_routing_finish+0x249/0x258<br>Dec=A0 2 01:29:39 xenho=
st-rack1 kernel: [4437064.012144]=A0 [&lt;ffffffff815492d3&gt;] br_nf_pre_r=
outing+0x55d/0x57e<br>
Dec=A0 2 01:29:39 xenhost-rack1 kernel: [4437064.012147]=A0 [&lt;ffffffff81=
49fe3e&gt;] nf_iterate+0x41/0x84<br>Dec=A0 2 01:29:39 xenhost-rack1 kernel:=
 [4437064.012150]=A0 [&lt;ffffffff81544738&gt;] ? br_handle_frame_finish+0x=
0/0x151<br>
Dec=A0 2 01:29:39 xenhost-rack1 kernel: [4437064.012155]=A0 [&lt;ffffffff81=
544738&gt;] ? br_handle_frame_finish+0x0/0x151<br>Dec=A0 2 01:29:39 xenhost=
-rack1 kernel: [4437064.012158]=A0 [&lt;ffffffff81544a51&gt;] br_handle_fra=
me+0x1c8/0x1ef<br>
Dec=A0 2 01:29:39 xenhost-rack1 kernel: [4437064.012163]=A0 [&lt;ffffffff81=
482270&gt;] netif_receive_skb+0x330/0x3fc<br>Dec=A0 2 01:29:39 xenhost-rack=
1 kernel: [4437064.012165]=A0 [&lt;ffffffff81479ec5&gt;] ? __netdev_alloc_s=
kb+0x1d/0x3a<br>
Dec=A0 2 01:29:39 xenhost-rack1 kernel: [4437064.012169]=A0 [&lt;ffffffff81=
4824bc&gt;] napi_skb_finish+0x24/0x38<br>Dec=A0 2 01:29:39 xenhost-rack1 ke=
rnel: [4437064.012172]=A0 [&lt;ffffffff81482900&gt;] napi_gro_receive+0x2a/=
0x2f<br>
Dec=A0 2 01:29:39 xenhost-rack1 kernel: [4437064.012175]=A0 [&lt;ffffffff81=
35aa86&gt;] e1000_receive_skb+0x43/0x4b<br>Dec=A0 2 01:29:39 xenhost-rack1 =
kernel: [4437064.012178]=A0 [&lt;ffffffff8135c557&gt;] e1000_clean_rx_irq+0=
x212/0x2b7<br>
Dec=A0 2 01:29:39 xenhost-rack1 kernel: [4437064.012181]=A0 [&lt;ffffffff81=
35b11f&gt;] e1000_clean+0x75/0x21f<br>Dec=A0 2 01:29:39 xenhost-rack1 kerne=
l: [4437064.012185]=A0 [&lt;ffffffff8127e67c&gt;] ? HYPERVISOR_physdev_op+0=
x16/0x4c<br>
Dec=A0 2 01:29:39 xenhost-rack1 kernel: [4437064.012194]=A0 [&lt;ffffffff81=
07d4ca&gt;] __do_softirq+0xee/0x1c4<br>Dec=A0 2 01:29:39 xenhost-rack1 kern=
el: [4437064.012199]=A0 [&lt;ffffffff8103de2c&gt;] call_softirq+0x1c/0x30<b=
r>Dec=A0 2 01:29:39 xenhost-rack1 kernel: [4437064.012202]=A0 [&lt;ffffffff=
8103f4bd&gt;] do_softirq+0x61/0xc2<br>
Dec=A0 2 01:29:39 xenhost-rack1 kernel: [4437064.012206]=A0 [&lt;ffffffff81=
07d311&gt;] irq_exit+0x36/0x78<br>Dec=A0 2 01:29:39 xenhost-rack1 kernel: [=
4437064.012208]=A0 [&lt;ffffffff8127f297&gt;] xen_evtchn_do_upcall+0x37/0x4=
7<br>
Dec=A0 2 01:29:39 xenhost-rack1 kernel: [4437064.012212]=A0 [&lt;ffffffff81=
03de7e&gt;] xen_do_hypervisor_callback+0x1e/0x30<br>Dec=A0 2 01:29:39 xenho=
st-rack1 kernel: [4437064.012213]=A0 &lt;EOI&gt;=A0 [&lt;ffffffff810093aa&g=
t;] ? hypercall_page+0x3aa/0x1000<br>
Dec=A0 2 01:29:39 xenhost-rack1 kernel: [4437064.012221]=A0 [&lt;ffffffff81=
0093aa&gt;] ? hypercall_page+0x3aa/0x1000<br>Dec=A0 2 01:29:39 xenhost-rack=
1 kernel: [4437064.012224]=A0 [&lt;ffffffff810093aa&gt;] ? hypercall_page+0=
x3aa/0x1000<br>
Dec=A0 2 01:29:39 xenhost-rack1 kernel: [4437064.012226]=A0 [&lt;ffffffff81=
038dbb&gt;] ? xen_safe_halt+0x10/0x1a<br>Dec=A0 2 01:29:39 xenhost-rack1 ke=
rnel: [4437064.012232]=A0 [&lt;ffffffff8103bde6&gt;] ? cpu_idle+0x66/0xa4<b=
r>Dec=A0 2 01:29:39 xenhost-rack1 kernel: [4437064.012237]=A0 [&lt;ffffffff=
81594359&gt;] ? rest_init+0x6d/0x6f<br>
Dec=A0 2 01:29:40 xenhost-rack1 kernel: [4437064.012241]=A0 [&lt;ffffffff81=
976dd5&gt;] ? start_kernel+0x43c/0x447<br>Dec=A0 2 01:29:40 xenhost-rack1 k=
ernel: [4437064.012245]=A0 [&lt;ffffffff819762c1&gt;] ? x86_64_start_reserv=
ations+0xac/0xb0<br>
Dec=A0 2 01:29:40 xenhost-rack1 kernel: [4437064.012248]=A0 [&lt;ffffffff81=
97ab24&gt;] ? xen_start_kernel+0x5ea/0x5f1<br>Dec=A0 2 01:29:40 xenhost-rac=
k1 kernel: [4437064.012250] Mem-Info:<br>Dec=A0 2 01:29:40 xenhost-rack1 ke=
rnel: [4437064.012251] DMA per-cpu:<br>
Dec=A0 2 01:29:40 xenhost-rack1 kernel: [4437064.012253] CPU=A0=A0=A0 0: hi=
:=A0=A0=A0 0, btch:=A0=A0 1 usd:=A0=A0 0<br>Dec=A0 2 01:29:40 xenhost-rack1=
 kernel: [4437064.012255] CPU=A0=A0=A0 1: hi:=A0=A0=A0 0, btch:=A0=A0 1 usd=
:=A0=A0 0<br>Dec=A0 2 01:29:40 xenhost-rack1 kernel: [4437064.012257] CPU=
=A0=A0=A0 2: hi:=A0=A0=A0 0, btch:=A0=A0 1 usd:=A0=A0 0<br>
Dec=A0 2 01:29:40 xenhost-rack1 kernel: [4437064.012258] CPU=A0=A0=A0 3: hi=
:=A0=A0=A0 0, btch:=A0=A0 1 usd:=A0=A0 0<br>Dec=A0 2 01:29:40 xenhost-rack1=
 kernel: [4437064.012260] DMA32 per-cpu:<br>Dec=A0 2 01:29:40 xenhost-rack1=
 kernel: [4437064.012261] CPU=A0=A0=A0 0: hi:=A0 186, btch:=A0 31 usd:=A0 6=
1<br>
Dec=A0 2 01:29:40 xenhost-rack1 kernel: [4437064.012263] CPU=A0=A0=A0 1: hi=
:=A0 186, btch:=A0 31 usd:=A0 58<br>Dec=A0 2 01:29:40 xenhost-rack1 kernel:=
 [4437064.012265] CPU=A0=A0=A0 2: hi:=A0 186, btch:=A0 31 usd:=A0 66<br>Dec=
=A0 2 01:29:40 xenhost-rack1 kernel: [4437064.012267] CPU=A0=A0=A0 3: hi:=
=A0 186, btch:=A0 31 usd: 128<br>
Dec=A0 2 01:29:40 xenhost-rack1 kernel: [4437064.012268] Normal per-cpu:<br=
>Dec=A0 2 01:29:40 xenhost-rack1 kernel: [4437064.012269] CPU=A0=A0=A0 0: h=
i:=A0 186, btch:=A0 31 usd:=A0=A0 0<br>Dec=A0 2 01:29:40 xenhost-rack1 kern=
el: [4437064.012271] CPU=A0=A0=A0 1: hi:=A0 186, btch:=A0 31 usd:=A0=A0 0<b=
r>
Dec=A0 2 01:29:40 xenhost-rack1 kernel: [4437064.012273] CPU=A0=A0=A0 2: hi=
:=A0 186, btch:=A0 31 usd:=A0=A0 0<br>Dec=A0 2 01:29:40 xenhost-rack1 kerne=
l: [4437064.012275] CPU=A0=A0=A0 3: hi:=A0 186, btch:=A0 31 usd:=A0=A0 0<br=
>Dec=A0 2 01:29:40 xenhost-rack1 kernel: [4437064.012279] active_anon:3388 =
inactive_anon:14639 isolated_anon:0<br>
Dec=A0 2 01:29:40 xenhost-rack1 kernel: [4437064.012280]=A0 active_file:709=
65 inactive_file:66104 isolated_file:0<br>Dec=A0 2 01:29:40 xenhost-rack1 k=
ernel: [4437064.012281]=A0 unevictable:3570 dirty:1 writeback:148 unstable:=
0<br>
Dec=A0 2 01:29:40 xenhost-rack1 kernel: [4437064.012282]=A0 free:13738 slab=
_reclaimable:10452 slab_unreclaimable:5582<br>Dec=A0 2 01:29:40 xenhost-rac=
k1 kernel: [4437064.012283]=A0 mapped:1948 shmem:325 pagetables:1309 bounce=
:0<br>
Dec=A0 2 01:29:40 xenhost-rack1 kernel: [4437064.012288] DMA free:13972kB m=
in:16kB low:20kB high:24kB active_anon:0kB inactive_anon:0kB active_file:0k=
B inactive_file:0kB unevictable:0kB isolated(anon):0kB isolated(file):0kB p=
resent:13764kB mlocked:0kB dirty:0kB writeback:0kB mapped:0kB shmem:0kB sla=
b_reclaimable:0kB slab_unreclaimable:0kB kernel_stack:0kB pagetables:0kB un=
stable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? =
yes<br>
Dec=A0 2 01:29:40 xenhost-rack1 kernel: [4437064.012292] lowmem_reserve[]: =
0 952 10042 10042<br>Dec=A0 2 01:29:40 xenhost-rack1 kernel: [4437064.01230=
0] DMA32 free:36792kB min:1212kB low:1512kB high:1816kB active_anon:13552kB=
 inactive_anon:58556kB active_file:283860kB inactive_file:264416kB unevicta=
ble:14280kB isolated(anon):0kB isolated(file):0kB present:975072kB mlocked:=
14280kB dirty:4kB writeback:592kB mapped:7792kB shmem:1300kB slab_reclaimab=
le:41808kB slab_unreclaimable:19604kB kernel_stack:1208kB pagetables:5236kB=
 unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimabl=
e? no<br>
Dec=A0 2 01:29:40 xenhost-rack1 kernel: [4437064.012304] lowmem_reserve[]: =
0 0 9090 9090<br>Dec=A0 2 01:29:40 xenhost-rack1 kernel: [4437064.012311] N=
ormal free:4188kB min:11596kB low:14492kB high:17392kB active_anon:0kB inac=
tive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB isolated(an=
on):0kB isolated(file):0kB present:9308160kB mlocked:0kB dirty:0kB writebac=
k:0kB mapped:0kB shmem:0kB slab_reclaimable:0kB slab_unreclaimable:2724kB k=
ernel_stack:0kB pagetables:0kB unstable:0kB bounce:0kB writeback_tmp:0kB pa=
ges_scanned:0 all_unreclaimable? no<br>
Dec=A0 2 01:29:40 xenhost-rack1 kernel: [4437064.012316] lowmem_reserve[]: =
0 0 0 0<br>Dec=A0 2 01:29:40 xenhost-rack1 kernel: [4437064.012318] DMA: 1*=
4kB 2*8kB 2*16kB 3*32kB 4*64kB 2*128kB 0*256kB 0*512kB 1*1024kB 0*2048kB 3*=
4096kB =3D 13972kB<br>
Dec=A0 2 01:29:40 xenhost-rack1 kernel: [4437064.012326] DMA32: 8114*4kB 53=
5*8kB 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096=
kB =3D 36736kB<br>Dec=A0 2 01:29:40 xenhost-rack1 kernel: [4437064.012333] =
Normal: 1*4kB 1*8kB 1*16kB 0*32kB 1*64kB 0*128kB 2*256kB 1*512kB 1*1024kB 1=
*2048kB 0*4096kB =3D 4188kB<br>
Dec=A0 2 01:29:40 xenhost-rack1 kernel: [4437064.012340] 138450 total pagec=
ache pages<br>Dec=A0 2 01:29:40 xenhost-rack1 kernel: [4437064.012342] 13 p=
ages in swap cache<br>Dec=A0 2 01:29:40 xenhost-rack1 kernel: [4437064.0123=
44] Swap cache stats: add 21, delete 8, find 123000/123002<br>
Dec=A0 2 01:29:40 xenhost-rack1 kernel: [4437064.012345] Free swap=A0 =3D 3=
905476kB<br>Dec=A0 2 01:29:40 xenhost-rack1 kernel: [4437064.012347] Total =
swap =3D 3905528kB<br>Dec=A0 2 01:29:40 xenhost-rack1 kernel: [4437064.0355=
64] 2621440 pages RAM<br>
Dec=A0 2 01:29:40 xenhost-rack1 kernel: [4437064.035566] 2425336 pages rese=
rved<br>Dec=A0 2 01:29:40 xenhost-rack1 kernel: [4437064.035568] 154640 pag=
es shared<br>Dec=A0 2 01:29:40 xenhost-rack1 kernel: [4437064.035569] 45402=
 pages non-shared<br>
Dec=A0 2 01:29:40 xenhost-rack1 kernel: [4437064.035572] SLUB: Unable to al=
locate memory on node -1 (gfp=3D0x20)<br>Dec=A0 2 01:29:40 xenhost-rack1 ke=
rnel: [4437064.035574]=A0=A0 cache: kmalloc-1024, object size: 1024, buffer=
 size: 1024, default order: 2, min order: 0<br>
Dec=A0 2 01:29:40 xenhost-rack1 kernel: [4437064.035577]=A0=A0 node 0: slab=
s: 870, objs: 6900, free: 0<br>Dec=A0 2 01:29:40 xenhost-rack1 kernel: [443=
7064.035919] swapper: page allocation failure. order:0, mode:0x4020<br>Dec=
=A0 2 01:29:40 xenhost-rack1 kernel: [4437064.035923] Pid: 0, comm: swapper=
 Not tainted 2.6.32.41 #2<br>
.....<br><br>it looks like an out of memory isn&#39;t it?=A0 <br>Not sure i=
t this could be a xen bug, network driver issue or something else?<br><br>A=
t the moment I have upgrade to 2.6.32.47.=A0=A0 Any help would be greatly a=
ppreciated<br>
thanks in advance<br><br>

--bcaec52c5f3970fb7604b3563182--


--===============5941742178561443624==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============5941742178561443624==--


From xen-devel-bounces@lists.xensource.com Mon Dec 05 10:59:09 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 10: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.xensource.com>)
	id 1RXWG5-0002aq-AY; Mon, 05 Dec 2011 10:58:53 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <svenvan.van@gmail.com>) id 1RXWG2-0002aU-OA
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 10:58:51 +0000
X-Env-Sender: svenvan.van@gmail.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1323082685!4222114!1
X-Originating-IP: [209.85.161.43]
X-SpamReason: No, hits=2.0 required=7.0 tests=BODY_RANDOM_LONG,
	HTML_00_10, HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,
	spamassassin: 
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9032 invoked from network); 5 Dec 2011 10:58:05 -0000
Received: from mail-fx0-f43.google.com (HELO mail-fx0-f43.google.com)
	(209.85.161.43)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Dec 2011 10:58:05 -0000
Received: by fagn18 with SMTP id n18so6285820fag.30
	for <xen-devel@lists.xensource.com>;
	Mon, 05 Dec 2011 02:58:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=C8h490p655aH7WuEIgbPip12fZRAvVEt6vR7MntTD1w=;
	b=NMxY2tbpSe/UPO2xeKGI817H/JIXZlhim2j2uhSSaKuijNv918VLrBBPgZcpcNblRh
	h1SxsmZrqwNouap8+Kczz7wEOAoUDflP1XB70R4lGDKAAUkDT/CT8/Lz4jFzejlD1ULn
	RA8VPBJSz0MtWZpAWFWQ1S5qIR1KrJThP4bYo=
MIME-Version: 1.0
Received: by 10.180.0.39 with SMTP id 7mr7442290wib.37.1323082684889; Mon, 05
	Dec 2011 02:58:04 -0800 (PST)
Received: by 10.223.119.80 with HTTP; Mon, 5 Dec 2011 02:58:04 -0800 (PST)
Date: Mon, 5 Dec 2011 11:58:04 +0100
Message-ID: <CAJmQyTik==F8PuR+j3SVRjxQQ_aVLjHeBZdboekD3iOVRR9Y0A@mail.gmail.com>
From: svenvan svenvan <svenvan.van@gmail.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] xen 4.0.1/w 2.6.32 swapper: page allocation failure
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============5941742178561443624=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============5941742178561443624==
Content-Type: multipart/alternative; boundary=bcaec52c5f3970fb7604b3563182

--bcaec52c5f3970fb7604b3563182
Content-Type: text/plain; charset=ISO-8859-1

hi
xen 4.0.1 w/2.6.32.41

Last week dom0 experienced an hard crash and box need to be restarted
manually (despite kernel.panic=20).
Serial console was not setup, only netconsole.  No relevant entries through
netconsole, but analyzing logs I see some crashes twenty minutes before
fatal hang.

Dec  2 01:29:39 xenhost-rack1 kernel: [4437064.011963] Call Trace:
Dec  2 01:29:39 xenhost-rack1 kernel: [4437064.011964]  <IRQ>
[<ffffffff810e5f8e>] __alloc_pages_nodemask+0x586/0x600
Dec  2 01:29:39 xenhost-rack1 kernel: [4437064.011976]
[<ffffffff8110dd6e>] alloc_slab_page+0x19/0x1b
Dec  2 01:29:39 xenhost-rack1 kernel: [4437064.011980]
[<ffffffff8110f632>] __slab_alloc+0x167/0x4b4
Dec  2 01:29:39 xenhost-rack1 kernel: [4437064.011983]
[<ffffffff81038d75>] ? xen_force_evtchn_callback+0xd/0xf
Dec  2 01:29:39 xenhost-rack1 kernel: [4437064.011987]
[<ffffffff8149064d>] ? find_skb+0x32/0x7d
Dec  2 01:29:39 xenhost-rack1 kernel: [4437064.011991]
[<ffffffff811113db>] __kmalloc_track_caller+0xfd/0x17e
Dec  2 01:29:39 xenhost-rack1 kernel: [4437064.011994]
[<ffffffff8103947f>] ? xen_restore_fl_direct_end+0x0/0x1
Dec  2 01:29:39 xenhost-rack1 kernel: [4437064.011997]
[<ffffffff8149064d>] ? find_skb+0x32/0x7d
Dec  2 01:29:39 xenhost-rack1 kernel: [4437064.011999]
[<ffffffff81039492>] ? check_events+0x12/0x20
Dec  2 01:29:39 xenhost-rack1 kernel: [4437064.012003]
[<ffffffff81479851>] __alloc_skb+0x69/0x155
Dec  2 01:29:39 xenhost-rack1 kernel: [4437064.012005]
[<ffffffff8103947f>] ? xen_restore_fl_direct_end+0x0/0x1
Dec  2 01:29:39 xenhost-rack1 kernel: [4437064.012045]
[<ffffffff81039492>] ? check_events+0x12/0x20
Dec  2 01:29:39 xenhost-rack1 kernel: [4437064.012050]
[<ffffffff815b3fb0>] printk+0x3c/0x3e
Dec  2 01:29:39 xenhost-rack1 kernel: [4437064.012052]
[<ffffffff810775c6>] ? release_console_sem+0x1b1/0x1e2
Dec  2 01:29:39 xenhost-rack1 kernel: [4437064.012057]
[<ffffffff8103007f>] ? vmx_set_cr0+0x313/0x4bc
Dec  2 01:29:39 xenhost-rack1 kernel: [4437064.012061]
[<ffffffff814f8de0>] dump_packet+0x310/0x794
Dec  2 01:29:39 xenhost-rack1 kernel: [4437064.012065]
[<ffffffff811d8b90>] ? selinux_ip_postroute+0x2e/0x1d6
Dec  2 01:29:39 xenhost-rack1 kernel: [4437064.012068]
[<ffffffff815b6005>] ? _spin_unlock_irqrestore+0x37/0x39
Dec  2 01:29:39 xenhost-rack1 kernel: [4437064.012071]
[<ffffffff815b3fb0>] ? printk+0x3c/0x3e
Dec  2 01:29:39 xenhost-rack1 kernel: [4437064.012074]
[<ffffffff814f93c3>] ipt_log_packet+0x15f/0x185
Dec  2 01:29:39 xenhost-rack1 kernel: [4437064.012077]
[<ffffffff814f942e>] log_tg+0x45/0x4b
Dec  2 01:29:39 xenhost-rack1 kernel: [4437064.012080]
[<ffffffff814b3067>] ? conntrack_mt_v2+0x1b/0x1d
Dec  2 01:29:39 xenhost-rack1 kernel: [4437064.012121]
[<ffffffff81543be2>] ? br_forward_finish+0x0/0x53
Dec  2 01:29:39 xenhost-rack1 kernel: [4437064.012124]
[<ffffffff81543c35>] ? __br_forward+0x0/0x9c
Dec  2 01:29:39 xenhost-rack1 kernel: [4437064.012127]
[<ffffffff81543cbe>] __br_forward+0x89/0x9c
Dec  2 01:29:39 xenhost-rack1 kernel: [4437064.012129]
[<ffffffff814792e6>] ? skb_clone+0x58/0x5d
Dec  2 01:29:39 xenhost-rack1 kernel: [4437064.012132]
[<ffffffff81543b22>] br_flood+0xa2/0xbb
Dec  2 01:29:39 xenhost-rack1 kernel: [4437064.012135]
[<ffffffff81543b4b>] br_flood_forward+0x10/0x12
Dec  2 01:29:39 xenhost-rack1 kernel: [4437064.012137]
[<ffffffff81544872>] br_handle_frame_finish+0x13a/0x151
Dec  2 01:29:39 xenhost-rack1 kernel: [4437064.012141]
[<ffffffff81548616>] br_nf_pre_routing_finish+0x249/0x258
Dec  2 01:29:39 xenhost-rack1 kernel: [4437064.012144]
[<ffffffff815492d3>] br_nf_pre_routing+0x55d/0x57e
Dec  2 01:29:39 xenhost-rack1 kernel: [4437064.012147]
[<ffffffff8149fe3e>] nf_iterate+0x41/0x84
Dec  2 01:29:39 xenhost-rack1 kernel: [4437064.012150]
[<ffffffff81544738>] ? br_handle_frame_finish+0x0/0x151
Dec  2 01:29:39 xenhost-rack1 kernel: [4437064.012155]
[<ffffffff81544738>] ? br_handle_frame_finish+0x0/0x151
Dec  2 01:29:39 xenhost-rack1 kernel: [4437064.012158]
[<ffffffff81544a51>] br_handle_frame+0x1c8/0x1ef
Dec  2 01:29:39 xenhost-rack1 kernel: [4437064.012163]
[<ffffffff81482270>] netif_receive_skb+0x330/0x3fc
Dec  2 01:29:39 xenhost-rack1 kernel: [4437064.012165]
[<ffffffff81479ec5>] ? __netdev_alloc_skb+0x1d/0x3a
Dec  2 01:29:39 xenhost-rack1 kernel: [4437064.012169]
[<ffffffff814824bc>] napi_skb_finish+0x24/0x38
Dec  2 01:29:39 xenhost-rack1 kernel: [4437064.012172]
[<ffffffff81482900>] napi_gro_receive+0x2a/0x2f
Dec  2 01:29:39 xenhost-rack1 kernel: [4437064.012175]
[<ffffffff8135aa86>] e1000_receive_skb+0x43/0x4b
Dec  2 01:29:39 xenhost-rack1 kernel: [4437064.012178]
[<ffffffff8135c557>] e1000_clean_rx_irq+0x212/0x2b7
Dec  2 01:29:39 xenhost-rack1 kernel: [4437064.012181]
[<ffffffff8135b11f>] e1000_clean+0x75/0x21f
Dec  2 01:29:39 xenhost-rack1 kernel: [4437064.012185]
[<ffffffff8127e67c>] ? HYPERVISOR_physdev_op+0x16/0x4c
Dec  2 01:29:39 xenhost-rack1 kernel: [4437064.012194]
[<ffffffff8107d4ca>] __do_softirq+0xee/0x1c4
Dec  2 01:29:39 xenhost-rack1 kernel: [4437064.012199]
[<ffffffff8103de2c>] call_softirq+0x1c/0x30
Dec  2 01:29:39 xenhost-rack1 kernel: [4437064.012202]
[<ffffffff8103f4bd>] do_softirq+0x61/0xc2
Dec  2 01:29:39 xenhost-rack1 kernel: [4437064.012206]
[<ffffffff8107d311>] irq_exit+0x36/0x78
Dec  2 01:29:39 xenhost-rack1 kernel: [4437064.012208]
[<ffffffff8127f297>] xen_evtchn_do_upcall+0x37/0x47
Dec  2 01:29:39 xenhost-rack1 kernel: [4437064.012212]
[<ffffffff8103de7e>] xen_do_hypervisor_callback+0x1e/0x30
Dec  2 01:29:39 xenhost-rack1 kernel: [4437064.012213]  <EOI>
[<ffffffff810093aa>] ? hypercall_page+0x3aa/0x1000
Dec  2 01:29:39 xenhost-rack1 kernel: [4437064.012221]
[<ffffffff810093aa>] ? hypercall_page+0x3aa/0x1000
Dec  2 01:29:39 xenhost-rack1 kernel: [4437064.012224]
[<ffffffff810093aa>] ? hypercall_page+0x3aa/0x1000
Dec  2 01:29:39 xenhost-rack1 kernel: [4437064.012226]
[<ffffffff81038dbb>] ? xen_safe_halt+0x10/0x1a
Dec  2 01:29:39 xenhost-rack1 kernel: [4437064.012232]
[<ffffffff8103bde6>] ? cpu_idle+0x66/0xa4
Dec  2 01:29:39 xenhost-rack1 kernel: [4437064.012237]
[<ffffffff81594359>] ? rest_init+0x6d/0x6f
Dec  2 01:29:40 xenhost-rack1 kernel: [4437064.012241]
[<ffffffff81976dd5>] ? start_kernel+0x43c/0x447
Dec  2 01:29:40 xenhost-rack1 kernel: [4437064.012245]
[<ffffffff819762c1>] ? x86_64_start_reservations+0xac/0xb0
Dec  2 01:29:40 xenhost-rack1 kernel: [4437064.012248]
[<ffffffff8197ab24>] ? xen_start_kernel+0x5ea/0x5f1
Dec  2 01:29:40 xenhost-rack1 kernel: [4437064.012250] Mem-Info:
Dec  2 01:29:40 xenhost-rack1 kernel: [4437064.012251] DMA per-cpu:
Dec  2 01:29:40 xenhost-rack1 kernel: [4437064.012253] CPU    0: hi:    0,
btch:   1 usd:   0
Dec  2 01:29:40 xenhost-rack1 kernel: [4437064.012255] CPU    1: hi:    0,
btch:   1 usd:   0
Dec  2 01:29:40 xenhost-rack1 kernel: [4437064.012257] CPU    2: hi:    0,
btch:   1 usd:   0
Dec  2 01:29:40 xenhost-rack1 kernel: [4437064.012258] CPU    3: hi:    0,
btch:   1 usd:   0
Dec  2 01:29:40 xenhost-rack1 kernel: [4437064.012260] DMA32 per-cpu:
Dec  2 01:29:40 xenhost-rack1 kernel: [4437064.012261] CPU    0: hi:  186,
btch:  31 usd:  61
Dec  2 01:29:40 xenhost-rack1 kernel: [4437064.012263] CPU    1: hi:  186,
btch:  31 usd:  58
Dec  2 01:29:40 xenhost-rack1 kernel: [4437064.012265] CPU    2: hi:  186,
btch:  31 usd:  66
Dec  2 01:29:40 xenhost-rack1 kernel: [4437064.012267] CPU    3: hi:  186,
btch:  31 usd: 128
Dec  2 01:29:40 xenhost-rack1 kernel: [4437064.012268] Normal per-cpu:
Dec  2 01:29:40 xenhost-rack1 kernel: [4437064.012269] CPU    0: hi:  186,
btch:  31 usd:   0
Dec  2 01:29:40 xenhost-rack1 kernel: [4437064.012271] CPU    1: hi:  186,
btch:  31 usd:   0
Dec  2 01:29:40 xenhost-rack1 kernel: [4437064.012273] CPU    2: hi:  186,
btch:  31 usd:   0
Dec  2 01:29:40 xenhost-rack1 kernel: [4437064.012275] CPU    3: hi:  186,
btch:  31 usd:   0
Dec  2 01:29:40 xenhost-rack1 kernel: [4437064.012279] active_anon:3388
inactive_anon:14639 isolated_anon:0
Dec  2 01:29:40 xenhost-rack1 kernel: [4437064.012280]  active_file:70965
inactive_file:66104 isolated_file:0
Dec  2 01:29:40 xenhost-rack1 kernel: [4437064.012281]  unevictable:3570
dirty:1 writeback:148 unstable:0
Dec  2 01:29:40 xenhost-rack1 kernel: [4437064.012282]  free:13738
slab_reclaimable:10452 slab_unreclaimable:5582
Dec  2 01:29:40 xenhost-rack1 kernel: [4437064.012283]  mapped:1948
shmem:325 pagetables:1309 bounce:0
Dec  2 01:29:40 xenhost-rack1 kernel: [4437064.012288] DMA free:13972kB
min:16kB low:20kB high:24kB active_anon:0kB inactive_anon:0kB
active_file:0kB inactive_file:0kB unevictable:0kB isolated(anon):0kB
isolated(file):0kB present:13764kB mlocked:0kB dirty:0kB writeback:0kB
mapped:0kB shmem:0kB slab_reclaimable:0kB slab_unreclaimable:0kB
kernel_stack:0kB pagetables:0kB unstable:0kB bounce:0kB writeback_tmp:0kB
pages_scanned:0 all_unreclaimable? yes
Dec  2 01:29:40 xenhost-rack1 kernel: [4437064.012292] lowmem_reserve[]: 0
952 10042 10042
Dec  2 01:29:40 xenhost-rack1 kernel: [4437064.012300] DMA32 free:36792kB
min:1212kB low:1512kB high:1816kB active_anon:13552kB inactive_anon:58556kB
active_file:283860kB inactive_file:264416kB unevictable:14280kB
isolated(anon):0kB isolated(file):0kB present:975072kB mlocked:14280kB
dirty:4kB writeback:592kB mapped:7792kB shmem:1300kB
slab_reclaimable:41808kB slab_unreclaimable:19604kB kernel_stack:1208kB
pagetables:5236kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0
all_unreclaimable? no
Dec  2 01:29:40 xenhost-rack1 kernel: [4437064.012304] lowmem_reserve[]: 0
0 9090 9090
Dec  2 01:29:40 xenhost-rack1 kernel: [4437064.012311] Normal free:4188kB
min:11596kB low:14492kB high:17392kB active_anon:0kB inactive_anon:0kB
active_file:0kB inactive_file:0kB unevictable:0kB isolated(anon):0kB
isolated(file):0kB present:9308160kB mlocked:0kB dirty:0kB writeback:0kB
mapped:0kB shmem:0kB slab_reclaimable:0kB slab_unreclaimable:2724kB
kernel_stack:0kB pagetables:0kB unstable:0kB bounce:0kB writeback_tmp:0kB
pages_scanned:0 all_unreclaimable? no
Dec  2 01:29:40 xenhost-rack1 kernel: [4437064.012316] lowmem_reserve[]: 0
0 0 0
Dec  2 01:29:40 xenhost-rack1 kernel: [4437064.012318] DMA: 1*4kB 2*8kB
2*16kB 3*32kB 4*64kB 2*128kB 0*256kB 0*512kB 1*1024kB 0*2048kB 3*4096kB =
13972kB
Dec  2 01:29:40 xenhost-rack1 kernel: [4437064.012326] DMA32: 8114*4kB
535*8kB 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB
0*4096kB = 36736kB
Dec  2 01:29:40 xenhost-rack1 kernel: [4437064.012333] Normal: 1*4kB 1*8kB
1*16kB 0*32kB 1*64kB 0*128kB 2*256kB 1*512kB 1*1024kB 1*2048kB 0*4096kB =
4188kB
Dec  2 01:29:40 xenhost-rack1 kernel: [4437064.012340] 138450 total
pagecache pages
Dec  2 01:29:40 xenhost-rack1 kernel: [4437064.012342] 13 pages in swap
cache
Dec  2 01:29:40 xenhost-rack1 kernel: [4437064.012344] Swap cache stats:
add 21, delete 8, find 123000/123002
Dec  2 01:29:40 xenhost-rack1 kernel: [4437064.012345] Free swap  =
3905476kB
Dec  2 01:29:40 xenhost-rack1 kernel: [4437064.012347] Total swap =
3905528kB
Dec  2 01:29:40 xenhost-rack1 kernel: [4437064.035564] 2621440 pages RAM
Dec  2 01:29:40 xenhost-rack1 kernel: [4437064.035566] 2425336 pages
reserved
Dec  2 01:29:40 xenhost-rack1 kernel: [4437064.035568] 154640 pages shared
Dec  2 01:29:40 xenhost-rack1 kernel: [4437064.035569] 45402 pages
non-shared
Dec  2 01:29:40 xenhost-rack1 kernel: [4437064.035572] SLUB: Unable to
allocate memory on node -1 (gfp=0x20)
Dec  2 01:29:40 xenhost-rack1 kernel: [4437064.035574]   cache:
kmalloc-1024, object size: 1024, buffer size: 1024, default order: 2, min
order: 0
Dec  2 01:29:40 xenhost-rack1 kernel: [4437064.035577]   node 0: slabs:
870, objs: 6900, free: 0
Dec  2 01:29:40 xenhost-rack1 kernel: [4437064.035919] swapper: page
allocation failure. order:0, mode:0x4020
Dec  2 01:29:40 xenhost-rack1 kernel: [4437064.035923] Pid: 0, comm:
swapper Not tainted 2.6.32.41 #2
.....

it looks like an out of memory isn't it?
Not sure it this could be a xen bug, network driver issue or something else?

At the moment I have upgrade to 2.6.32.47.   Any help would be greatly
appreciated
thanks in advance

--bcaec52c5f3970fb7604b3563182
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

hi<br>xen 4.0.1 w/<a href=3D"http://2.6.32.41">2.6.32.41</a><br><br>Last we=
ek dom0 experienced an hard crash and box need to be restarted manually (de=
spite kernel.panic=3D20).<br>Serial console was not setup, only netconsole.=
=A0 No relevant entries through netconsole, but analyzing logs I see some c=
rashes twenty minutes before fatal hang.<br>
<br>Dec=A0 2 01:29:39 xenhost-rack1 kernel: [4437064.011963] Call Trace:<br=
>Dec=A0 2 01:29:39 xenhost-rack1 kernel: [4437064.011964]=A0 &lt;IRQ&gt;=A0=
 [&lt;ffffffff810e5f8e&gt;] __alloc_pages_nodemask+0x586/0x600<br>Dec=A0 2 =
01:29:39 xenhost-rack1 kernel: [4437064.011976]=A0 [&lt;ffffffff8110dd6e&gt=
;] alloc_slab_page+0x19/0x1b<br>
Dec=A0 2 01:29:39 xenhost-rack1 kernel: [4437064.011980]=A0 [&lt;ffffffff81=
10f632&gt;] __slab_alloc+0x167/0x4b4<br>Dec=A0 2 01:29:39 xenhost-rack1 ker=
nel: [4437064.011983]=A0 [&lt;ffffffff81038d75&gt;] ? xen_force_evtchn_call=
back+0xd/0xf<br>
Dec=A0 2 01:29:39 xenhost-rack1 kernel: [4437064.011987]=A0 [&lt;ffffffff81=
49064d&gt;] ? find_skb+0x32/0x7d<br>Dec=A0 2 01:29:39 xenhost-rack1 kernel:=
 [4437064.011991]=A0 [&lt;ffffffff811113db&gt;] __kmalloc_track_caller+0xfd=
/0x17e<br>
Dec=A0 2 01:29:39 xenhost-rack1 kernel: [4437064.011994]=A0 [&lt;ffffffff81=
03947f&gt;] ? xen_restore_fl_direct_end+0x0/0x1<br>Dec=A0 2 01:29:39 xenhos=
t-rack1 kernel: [4437064.011997]=A0 [&lt;ffffffff8149064d&gt;] ? find_skb+0=
x32/0x7d<br>
Dec=A0 2 01:29:39 xenhost-rack1 kernel: [4437064.011999]=A0 [&lt;ffffffff81=
039492&gt;] ? check_events+0x12/0x20<br>Dec=A0 2 01:29:39 xenhost-rack1 ker=
nel: [4437064.012003]=A0 [&lt;ffffffff81479851&gt;] __alloc_skb+0x69/0x155<=
br>Dec=A0 2 01:29:39 xenhost-rack1 kernel: [4437064.012005]=A0 [&lt;fffffff=
f8103947f&gt;] ? xen_restore_fl_direct_end+0x0/0x1<br>
Dec=A0 2 01:29:39 xenhost-rack1 kernel: [4437064.012045]=A0 [&lt;ffffffff81=
039492&gt;] ? check_events+0x12/0x20<br>Dec=A0 2 01:29:39 xenhost-rack1 ker=
nel: [4437064.012050]=A0 [&lt;ffffffff815b3fb0&gt;] printk+0x3c/0x3e<br>Dec=
=A0 2 01:29:39 xenhost-rack1 kernel: [4437064.012052]=A0 [&lt;ffffffff81077=
5c6&gt;] ? release_console_sem+0x1b1/0x1e2<br>
Dec=A0 2 01:29:39 xenhost-rack1 kernel: [4437064.012057]=A0 [&lt;ffffffff81=
03007f&gt;] ? vmx_set_cr0+0x313/0x4bc<br>Dec=A0 2 01:29:39 xenhost-rack1 ke=
rnel: [4437064.012061]=A0 [&lt;ffffffff814f8de0&gt;] dump_packet+0x310/0x79=
4<br>
Dec=A0 2 01:29:39 xenhost-rack1 kernel: [4437064.012065]=A0 [&lt;ffffffff81=
1d8b90&gt;] ? selinux_ip_postroute+0x2e/0x1d6<br>Dec=A0 2 01:29:39 xenhost-=
rack1 kernel: [4437064.012068]=A0 [&lt;ffffffff815b6005&gt;] ? _spin_unlock=
_irqrestore+0x37/0x39<br>
Dec=A0 2 01:29:39 xenhost-rack1 kernel: [4437064.012071]=A0 [&lt;ffffffff81=
5b3fb0&gt;] ? printk+0x3c/0x3e<br>Dec=A0 2 01:29:39 xenhost-rack1 kernel: [=
4437064.012074]=A0 [&lt;ffffffff814f93c3&gt;] ipt_log_packet+0x15f/0x185<br=
>Dec=A0 2 01:29:39 xenhost-rack1 kernel: [4437064.012077]=A0 [&lt;ffffffff8=
14f942e&gt;] log_tg+0x45/0x4b<br>
Dec=A0 2 01:29:39 xenhost-rack1 kernel: [4437064.012080]=A0 [&lt;ffffffff81=
4b3067&gt;] ? conntrack_mt_v2+0x1b/0x1d<br>Dec=A0 2 01:29:39 xenhost-rack1 =
kernel: [4437064.012121]=A0 [&lt;ffffffff81543be2&gt;] ? br_forward_finish+=
0x0/0x53<br>
Dec=A0 2 01:29:39 xenhost-rack1 kernel: [4437064.012124]=A0 [&lt;ffffffff81=
543c35&gt;] ? __br_forward+0x0/0x9c<br>Dec=A0 2 01:29:39 xenhost-rack1 kern=
el: [4437064.012127]=A0 [&lt;ffffffff81543cbe&gt;] __br_forward+0x89/0x9c<b=
r>Dec=A0 2 01:29:39 xenhost-rack1 kernel: [4437064.012129]=A0 [&lt;ffffffff=
814792e6&gt;] ? skb_clone+0x58/0x5d<br>
Dec=A0 2 01:29:39 xenhost-rack1 kernel: [4437064.012132]=A0 [&lt;ffffffff81=
543b22&gt;] br_flood+0xa2/0xbb<br>Dec=A0 2 01:29:39 xenhost-rack1 kernel: [=
4437064.012135]=A0 [&lt;ffffffff81543b4b&gt;] br_flood_forward+0x10/0x12<br=
>Dec=A0 2 01:29:39 xenhost-rack1 kernel: [4437064.012137]=A0 [&lt;ffffffff8=
1544872&gt;] br_handle_frame_finish+0x13a/0x151<br>
Dec=A0 2 01:29:39 xenhost-rack1 kernel: [4437064.012141]=A0 [&lt;ffffffff81=
548616&gt;] br_nf_pre_routing_finish+0x249/0x258<br>Dec=A0 2 01:29:39 xenho=
st-rack1 kernel: [4437064.012144]=A0 [&lt;ffffffff815492d3&gt;] br_nf_pre_r=
outing+0x55d/0x57e<br>
Dec=A0 2 01:29:39 xenhost-rack1 kernel: [4437064.012147]=A0 [&lt;ffffffff81=
49fe3e&gt;] nf_iterate+0x41/0x84<br>Dec=A0 2 01:29:39 xenhost-rack1 kernel:=
 [4437064.012150]=A0 [&lt;ffffffff81544738&gt;] ? br_handle_frame_finish+0x=
0/0x151<br>
Dec=A0 2 01:29:39 xenhost-rack1 kernel: [4437064.012155]=A0 [&lt;ffffffff81=
544738&gt;] ? br_handle_frame_finish+0x0/0x151<br>Dec=A0 2 01:29:39 xenhost=
-rack1 kernel: [4437064.012158]=A0 [&lt;ffffffff81544a51&gt;] br_handle_fra=
me+0x1c8/0x1ef<br>
Dec=A0 2 01:29:39 xenhost-rack1 kernel: [4437064.012163]=A0 [&lt;ffffffff81=
482270&gt;] netif_receive_skb+0x330/0x3fc<br>Dec=A0 2 01:29:39 xenhost-rack=
1 kernel: [4437064.012165]=A0 [&lt;ffffffff81479ec5&gt;] ? __netdev_alloc_s=
kb+0x1d/0x3a<br>
Dec=A0 2 01:29:39 xenhost-rack1 kernel: [4437064.012169]=A0 [&lt;ffffffff81=
4824bc&gt;] napi_skb_finish+0x24/0x38<br>Dec=A0 2 01:29:39 xenhost-rack1 ke=
rnel: [4437064.012172]=A0 [&lt;ffffffff81482900&gt;] napi_gro_receive+0x2a/=
0x2f<br>
Dec=A0 2 01:29:39 xenhost-rack1 kernel: [4437064.012175]=A0 [&lt;ffffffff81=
35aa86&gt;] e1000_receive_skb+0x43/0x4b<br>Dec=A0 2 01:29:39 xenhost-rack1 =
kernel: [4437064.012178]=A0 [&lt;ffffffff8135c557&gt;] e1000_clean_rx_irq+0=
x212/0x2b7<br>
Dec=A0 2 01:29:39 xenhost-rack1 kernel: [4437064.012181]=A0 [&lt;ffffffff81=
35b11f&gt;] e1000_clean+0x75/0x21f<br>Dec=A0 2 01:29:39 xenhost-rack1 kerne=
l: [4437064.012185]=A0 [&lt;ffffffff8127e67c&gt;] ? HYPERVISOR_physdev_op+0=
x16/0x4c<br>
Dec=A0 2 01:29:39 xenhost-rack1 kernel: [4437064.012194]=A0 [&lt;ffffffff81=
07d4ca&gt;] __do_softirq+0xee/0x1c4<br>Dec=A0 2 01:29:39 xenhost-rack1 kern=
el: [4437064.012199]=A0 [&lt;ffffffff8103de2c&gt;] call_softirq+0x1c/0x30<b=
r>Dec=A0 2 01:29:39 xenhost-rack1 kernel: [4437064.012202]=A0 [&lt;ffffffff=
8103f4bd&gt;] do_softirq+0x61/0xc2<br>
Dec=A0 2 01:29:39 xenhost-rack1 kernel: [4437064.012206]=A0 [&lt;ffffffff81=
07d311&gt;] irq_exit+0x36/0x78<br>Dec=A0 2 01:29:39 xenhost-rack1 kernel: [=
4437064.012208]=A0 [&lt;ffffffff8127f297&gt;] xen_evtchn_do_upcall+0x37/0x4=
7<br>
Dec=A0 2 01:29:39 xenhost-rack1 kernel: [4437064.012212]=A0 [&lt;ffffffff81=
03de7e&gt;] xen_do_hypervisor_callback+0x1e/0x30<br>Dec=A0 2 01:29:39 xenho=
st-rack1 kernel: [4437064.012213]=A0 &lt;EOI&gt;=A0 [&lt;ffffffff810093aa&g=
t;] ? hypercall_page+0x3aa/0x1000<br>
Dec=A0 2 01:29:39 xenhost-rack1 kernel: [4437064.012221]=A0 [&lt;ffffffff81=
0093aa&gt;] ? hypercall_page+0x3aa/0x1000<br>Dec=A0 2 01:29:39 xenhost-rack=
1 kernel: [4437064.012224]=A0 [&lt;ffffffff810093aa&gt;] ? hypercall_page+0=
x3aa/0x1000<br>
Dec=A0 2 01:29:39 xenhost-rack1 kernel: [4437064.012226]=A0 [&lt;ffffffff81=
038dbb&gt;] ? xen_safe_halt+0x10/0x1a<br>Dec=A0 2 01:29:39 xenhost-rack1 ke=
rnel: [4437064.012232]=A0 [&lt;ffffffff8103bde6&gt;] ? cpu_idle+0x66/0xa4<b=
r>Dec=A0 2 01:29:39 xenhost-rack1 kernel: [4437064.012237]=A0 [&lt;ffffffff=
81594359&gt;] ? rest_init+0x6d/0x6f<br>
Dec=A0 2 01:29:40 xenhost-rack1 kernel: [4437064.012241]=A0 [&lt;ffffffff81=
976dd5&gt;] ? start_kernel+0x43c/0x447<br>Dec=A0 2 01:29:40 xenhost-rack1 k=
ernel: [4437064.012245]=A0 [&lt;ffffffff819762c1&gt;] ? x86_64_start_reserv=
ations+0xac/0xb0<br>
Dec=A0 2 01:29:40 xenhost-rack1 kernel: [4437064.012248]=A0 [&lt;ffffffff81=
97ab24&gt;] ? xen_start_kernel+0x5ea/0x5f1<br>Dec=A0 2 01:29:40 xenhost-rac=
k1 kernel: [4437064.012250] Mem-Info:<br>Dec=A0 2 01:29:40 xenhost-rack1 ke=
rnel: [4437064.012251] DMA per-cpu:<br>
Dec=A0 2 01:29:40 xenhost-rack1 kernel: [4437064.012253] CPU=A0=A0=A0 0: hi=
:=A0=A0=A0 0, btch:=A0=A0 1 usd:=A0=A0 0<br>Dec=A0 2 01:29:40 xenhost-rack1=
 kernel: [4437064.012255] CPU=A0=A0=A0 1: hi:=A0=A0=A0 0, btch:=A0=A0 1 usd=
:=A0=A0 0<br>Dec=A0 2 01:29:40 xenhost-rack1 kernel: [4437064.012257] CPU=
=A0=A0=A0 2: hi:=A0=A0=A0 0, btch:=A0=A0 1 usd:=A0=A0 0<br>
Dec=A0 2 01:29:40 xenhost-rack1 kernel: [4437064.012258] CPU=A0=A0=A0 3: hi=
:=A0=A0=A0 0, btch:=A0=A0 1 usd:=A0=A0 0<br>Dec=A0 2 01:29:40 xenhost-rack1=
 kernel: [4437064.012260] DMA32 per-cpu:<br>Dec=A0 2 01:29:40 xenhost-rack1=
 kernel: [4437064.012261] CPU=A0=A0=A0 0: hi:=A0 186, btch:=A0 31 usd:=A0 6=
1<br>
Dec=A0 2 01:29:40 xenhost-rack1 kernel: [4437064.012263] CPU=A0=A0=A0 1: hi=
:=A0 186, btch:=A0 31 usd:=A0 58<br>Dec=A0 2 01:29:40 xenhost-rack1 kernel:=
 [4437064.012265] CPU=A0=A0=A0 2: hi:=A0 186, btch:=A0 31 usd:=A0 66<br>Dec=
=A0 2 01:29:40 xenhost-rack1 kernel: [4437064.012267] CPU=A0=A0=A0 3: hi:=
=A0 186, btch:=A0 31 usd: 128<br>
Dec=A0 2 01:29:40 xenhost-rack1 kernel: [4437064.012268] Normal per-cpu:<br=
>Dec=A0 2 01:29:40 xenhost-rack1 kernel: [4437064.012269] CPU=A0=A0=A0 0: h=
i:=A0 186, btch:=A0 31 usd:=A0=A0 0<br>Dec=A0 2 01:29:40 xenhost-rack1 kern=
el: [4437064.012271] CPU=A0=A0=A0 1: hi:=A0 186, btch:=A0 31 usd:=A0=A0 0<b=
r>
Dec=A0 2 01:29:40 xenhost-rack1 kernel: [4437064.012273] CPU=A0=A0=A0 2: hi=
:=A0 186, btch:=A0 31 usd:=A0=A0 0<br>Dec=A0 2 01:29:40 xenhost-rack1 kerne=
l: [4437064.012275] CPU=A0=A0=A0 3: hi:=A0 186, btch:=A0 31 usd:=A0=A0 0<br=
>Dec=A0 2 01:29:40 xenhost-rack1 kernel: [4437064.012279] active_anon:3388 =
inactive_anon:14639 isolated_anon:0<br>
Dec=A0 2 01:29:40 xenhost-rack1 kernel: [4437064.012280]=A0 active_file:709=
65 inactive_file:66104 isolated_file:0<br>Dec=A0 2 01:29:40 xenhost-rack1 k=
ernel: [4437064.012281]=A0 unevictable:3570 dirty:1 writeback:148 unstable:=
0<br>
Dec=A0 2 01:29:40 xenhost-rack1 kernel: [4437064.012282]=A0 free:13738 slab=
_reclaimable:10452 slab_unreclaimable:5582<br>Dec=A0 2 01:29:40 xenhost-rac=
k1 kernel: [4437064.012283]=A0 mapped:1948 shmem:325 pagetables:1309 bounce=
:0<br>
Dec=A0 2 01:29:40 xenhost-rack1 kernel: [4437064.012288] DMA free:13972kB m=
in:16kB low:20kB high:24kB active_anon:0kB inactive_anon:0kB active_file:0k=
B inactive_file:0kB unevictable:0kB isolated(anon):0kB isolated(file):0kB p=
resent:13764kB mlocked:0kB dirty:0kB writeback:0kB mapped:0kB shmem:0kB sla=
b_reclaimable:0kB slab_unreclaimable:0kB kernel_stack:0kB pagetables:0kB un=
stable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? =
yes<br>
Dec=A0 2 01:29:40 xenhost-rack1 kernel: [4437064.012292] lowmem_reserve[]: =
0 952 10042 10042<br>Dec=A0 2 01:29:40 xenhost-rack1 kernel: [4437064.01230=
0] DMA32 free:36792kB min:1212kB low:1512kB high:1816kB active_anon:13552kB=
 inactive_anon:58556kB active_file:283860kB inactive_file:264416kB unevicta=
ble:14280kB isolated(anon):0kB isolated(file):0kB present:975072kB mlocked:=
14280kB dirty:4kB writeback:592kB mapped:7792kB shmem:1300kB slab_reclaimab=
le:41808kB slab_unreclaimable:19604kB kernel_stack:1208kB pagetables:5236kB=
 unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimabl=
e? no<br>
Dec=A0 2 01:29:40 xenhost-rack1 kernel: [4437064.012304] lowmem_reserve[]: =
0 0 9090 9090<br>Dec=A0 2 01:29:40 xenhost-rack1 kernel: [4437064.012311] N=
ormal free:4188kB min:11596kB low:14492kB high:17392kB active_anon:0kB inac=
tive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB isolated(an=
on):0kB isolated(file):0kB present:9308160kB mlocked:0kB dirty:0kB writebac=
k:0kB mapped:0kB shmem:0kB slab_reclaimable:0kB slab_unreclaimable:2724kB k=
ernel_stack:0kB pagetables:0kB unstable:0kB bounce:0kB writeback_tmp:0kB pa=
ges_scanned:0 all_unreclaimable? no<br>
Dec=A0 2 01:29:40 xenhost-rack1 kernel: [4437064.012316] lowmem_reserve[]: =
0 0 0 0<br>Dec=A0 2 01:29:40 xenhost-rack1 kernel: [4437064.012318] DMA: 1*=
4kB 2*8kB 2*16kB 3*32kB 4*64kB 2*128kB 0*256kB 0*512kB 1*1024kB 0*2048kB 3*=
4096kB =3D 13972kB<br>
Dec=A0 2 01:29:40 xenhost-rack1 kernel: [4437064.012326] DMA32: 8114*4kB 53=
5*8kB 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096=
kB =3D 36736kB<br>Dec=A0 2 01:29:40 xenhost-rack1 kernel: [4437064.012333] =
Normal: 1*4kB 1*8kB 1*16kB 0*32kB 1*64kB 0*128kB 2*256kB 1*512kB 1*1024kB 1=
*2048kB 0*4096kB =3D 4188kB<br>
Dec=A0 2 01:29:40 xenhost-rack1 kernel: [4437064.012340] 138450 total pagec=
ache pages<br>Dec=A0 2 01:29:40 xenhost-rack1 kernel: [4437064.012342] 13 p=
ages in swap cache<br>Dec=A0 2 01:29:40 xenhost-rack1 kernel: [4437064.0123=
44] Swap cache stats: add 21, delete 8, find 123000/123002<br>
Dec=A0 2 01:29:40 xenhost-rack1 kernel: [4437064.012345] Free swap=A0 =3D 3=
905476kB<br>Dec=A0 2 01:29:40 xenhost-rack1 kernel: [4437064.012347] Total =
swap =3D 3905528kB<br>Dec=A0 2 01:29:40 xenhost-rack1 kernel: [4437064.0355=
64] 2621440 pages RAM<br>
Dec=A0 2 01:29:40 xenhost-rack1 kernel: [4437064.035566] 2425336 pages rese=
rved<br>Dec=A0 2 01:29:40 xenhost-rack1 kernel: [4437064.035568] 154640 pag=
es shared<br>Dec=A0 2 01:29:40 xenhost-rack1 kernel: [4437064.035569] 45402=
 pages non-shared<br>
Dec=A0 2 01:29:40 xenhost-rack1 kernel: [4437064.035572] SLUB: Unable to al=
locate memory on node -1 (gfp=3D0x20)<br>Dec=A0 2 01:29:40 xenhost-rack1 ke=
rnel: [4437064.035574]=A0=A0 cache: kmalloc-1024, object size: 1024, buffer=
 size: 1024, default order: 2, min order: 0<br>
Dec=A0 2 01:29:40 xenhost-rack1 kernel: [4437064.035577]=A0=A0 node 0: slab=
s: 870, objs: 6900, free: 0<br>Dec=A0 2 01:29:40 xenhost-rack1 kernel: [443=
7064.035919] swapper: page allocation failure. order:0, mode:0x4020<br>Dec=
=A0 2 01:29:40 xenhost-rack1 kernel: [4437064.035923] Pid: 0, comm: swapper=
 Not tainted 2.6.32.41 #2<br>
.....<br><br>it looks like an out of memory isn&#39;t it?=A0 <br>Not sure i=
t this could be a xen bug, network driver issue or something else?<br><br>A=
t the moment I have upgrade to 2.6.32.47.=A0=A0 Any help would be greatly a=
ppreciated<br>
thanks in advance<br><br>

--bcaec52c5f3970fb7604b3563182--


--===============5941742178561443624==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============5941742178561443624==--


From xen-devel-bounces@lists.xensource.com Mon Dec 05 11:05:31 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 11:05:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXWMD-0002qK-F0; Mon, 05 Dec 2011 11:05:13 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <amit.shah@redhat.com>) id 1RXWMC-0002qF-GI
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 11:05:12 +0000
X-Env-Sender: amit.shah@redhat.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1323083066!5371189!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDYxODY=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9182 invoked from network); 5 Dec 2011 11:04:27 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-13.tower-182.messagelabs.com with SMTP;
	5 Dec 2011 11:04:27 -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 pB5AsvL7020957
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 5 Dec 2011 05:54:57 -0500
Received: from localhost (ovpn-113-36.phx2.redhat.com [10.3.113.36])
	by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id pB5Asr90007743; Mon, 5 Dec 2011 05:54:55 -0500
Date: Mon, 5 Dec 2011 16:24:52 +0530
From: Amit Shah <amit.shah@redhat.com>
To: Miche Baker-Harvey <miche@google.com>
Message-ID: <20111205105452.GB27683@amit-x200.redhat.com>
References: <20111108214452.28884.14840.stgit@miche.sea.corp.google.com>
	<20111108214504.28884.61814.stgit@miche.sea.corp.google.com>
	<874nybqo0o.fsf@rustcorp.com.au>
	<CAB8RdapbaueyWLJuJDE_ZdvLkRNM4sQHTxgmgO=jrnXZ6YPSmA@mail.gmail.com>
	<20111123103852.GG16665@amit-x200.redhat.com>
	<CAB8RdaoDxMCgTjuGP70bGrsrtgh=USYtU3Spo5OPtVMYAM5EzQ@mail.gmail.com>
	<20111129142149.GE2822@amit-x200.redhat.com>
	<CAB8RdapuPRym2dH_9mgmGdzpCxnP1KpS+hS8JJ-geVkga5fMcw@mail.gmail.com>
	<CAB8Rdapfuf5XH+X9gsUL+CJ9gTQcSNfq4Dj9DoYWQeFgD04ODQ@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAB8Rdapfuf5XH+X9gsUL+CJ9gTQcSNfq4Dj9DoYWQeFgD04ODQ@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
Cc: Stephen Rothwell <sfr@canb.auug.org.au>, xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Rusty Russell <rusty@rustcorp.com.au>, linux-kernel@vger.kernel.org,
	virtualization@lists.linux-foundation.org,
	Anton Blanchard <anton@samba.org>, Mike Waychison <mikew@google.com>,
	ppc-dev <linuxppc-dev@lists.ozlabs.org>,
	Greg Kroah-Hartman <gregkh@suse.de>, Eric Northrup <digitaleric@google.com>
Subject: Re: [Xen-devel] [PATCH v3 2/3] hvc_init(): Enforce one-time
	initialization.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On (Tue) 29 Nov 2011 [09:50:41], Miche Baker-Harvey wrote:
> Good grief!  Sorry for the spacing mess-up!  Here's a resend with reformatting.
> 
> Amit,
> We aren't using either QEMU or kvmtool, but we are using KVM.  All

So it's a different userspace?  Any chance this different userspace is
causing these problems to appear?  Esp. since I couldn't reproduce
with qemu.

> the issues we are seeing happen when we try to establish multiple
> virtioconsoles at boot time.  The command line isn't relevant, but I
> can tell you the protocol that's passing between the host (kvm) and
> the guest (see the end of this message).
> 
> We do go through the control_work_handler(), but it's not
> providing synchronization.  Here's a trace of the
> control_work_handler() and handle_control_message() calls; note that
> there are two concurrent calls to control_work_handler().

Ah; how does that happen?  control_work_handler() should just be
invoked once, and if there are any more pending work items to be
consumed, they should be done within the loop inside
control_work_handler().

> I decorated control_work_handler() with a "lifetime" marker, and
> passed this value to handle_control_message(), so we can see which
> control messages are being handled from which instance of
> the control_work_handler() thread.
> 
> Notice that we enter control_work_handler() a second time before
> the handling of the second PORT_ADD message is complete. The
> first CONSOLE_PORT message is handled by the second
> control_work_handler() call, but the second is handled by the first
> control_work_handler() call.
> 
> root@myubuntu:~# dmesg | grep MBH
> [3371055.808738] control_work_handler #1
> [3371055.809372] + #1 handle_control_message PORT_ADD
> [3371055.810169] - handle_control_message PORT_ADD
> [3371055.810170] + #1 handle_control_message PORT_ADD
> [3371055.810244]  control_work_handler #2
> [3371055.810245] + #2 handle_control_message CONSOLE_PORT
> [3371055.810246]  got hvc_ports_mutex
> [3371055.810578] - handle_control_message PORT_ADD
> [3371055.810579] + #1 handle_control_message CONSOLE_PORT
> [3371055.810580]  trylock of hvc_ports_mutex failed
> [3371055.811352]  got hvc_ports_mutex
> [3371055.811370] - handle_control_message CONSOLE_PORT
> [3371055.816609] - handle_control_message CONSOLE_PORT
> 
> So, I'm guessing the bug is that there shouldn't be two instances of
> control_work_handler() running simultaneously?

Yep, I assumed we did that but apparently not.  Do you plan to chase
this one down?

		Amit

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 11:05:31 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 11:05:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXWMD-0002qK-F0; Mon, 05 Dec 2011 11:05:13 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <amit.shah@redhat.com>) id 1RXWMC-0002qF-GI
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 11:05:12 +0000
X-Env-Sender: amit.shah@redhat.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1323083066!5371189!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDYxODY=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9182 invoked from network); 5 Dec 2011 11:04:27 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-13.tower-182.messagelabs.com with SMTP;
	5 Dec 2011 11:04:27 -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 pB5AsvL7020957
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 5 Dec 2011 05:54:57 -0500
Received: from localhost (ovpn-113-36.phx2.redhat.com [10.3.113.36])
	by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id pB5Asr90007743; Mon, 5 Dec 2011 05:54:55 -0500
Date: Mon, 5 Dec 2011 16:24:52 +0530
From: Amit Shah <amit.shah@redhat.com>
To: Miche Baker-Harvey <miche@google.com>
Message-ID: <20111205105452.GB27683@amit-x200.redhat.com>
References: <20111108214452.28884.14840.stgit@miche.sea.corp.google.com>
	<20111108214504.28884.61814.stgit@miche.sea.corp.google.com>
	<874nybqo0o.fsf@rustcorp.com.au>
	<CAB8RdapbaueyWLJuJDE_ZdvLkRNM4sQHTxgmgO=jrnXZ6YPSmA@mail.gmail.com>
	<20111123103852.GG16665@amit-x200.redhat.com>
	<CAB8RdaoDxMCgTjuGP70bGrsrtgh=USYtU3Spo5OPtVMYAM5EzQ@mail.gmail.com>
	<20111129142149.GE2822@amit-x200.redhat.com>
	<CAB8RdapuPRym2dH_9mgmGdzpCxnP1KpS+hS8JJ-geVkga5fMcw@mail.gmail.com>
	<CAB8Rdapfuf5XH+X9gsUL+CJ9gTQcSNfq4Dj9DoYWQeFgD04ODQ@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAB8Rdapfuf5XH+X9gsUL+CJ9gTQcSNfq4Dj9DoYWQeFgD04ODQ@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
Cc: Stephen Rothwell <sfr@canb.auug.org.au>, xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Rusty Russell <rusty@rustcorp.com.au>, linux-kernel@vger.kernel.org,
	virtualization@lists.linux-foundation.org,
	Anton Blanchard <anton@samba.org>, Mike Waychison <mikew@google.com>,
	ppc-dev <linuxppc-dev@lists.ozlabs.org>,
	Greg Kroah-Hartman <gregkh@suse.de>, Eric Northrup <digitaleric@google.com>
Subject: Re: [Xen-devel] [PATCH v3 2/3] hvc_init(): Enforce one-time
	initialization.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On (Tue) 29 Nov 2011 [09:50:41], Miche Baker-Harvey wrote:
> Good grief!  Sorry for the spacing mess-up!  Here's a resend with reformatting.
> 
> Amit,
> We aren't using either QEMU or kvmtool, but we are using KVM.  All

So it's a different userspace?  Any chance this different userspace is
causing these problems to appear?  Esp. since I couldn't reproduce
with qemu.

> the issues we are seeing happen when we try to establish multiple
> virtioconsoles at boot time.  The command line isn't relevant, but I
> can tell you the protocol that's passing between the host (kvm) and
> the guest (see the end of this message).
> 
> We do go through the control_work_handler(), but it's not
> providing synchronization.  Here's a trace of the
> control_work_handler() and handle_control_message() calls; note that
> there are two concurrent calls to control_work_handler().

Ah; how does that happen?  control_work_handler() should just be
invoked once, and if there are any more pending work items to be
consumed, they should be done within the loop inside
control_work_handler().

> I decorated control_work_handler() with a "lifetime" marker, and
> passed this value to handle_control_message(), so we can see which
> control messages are being handled from which instance of
> the control_work_handler() thread.
> 
> Notice that we enter control_work_handler() a second time before
> the handling of the second PORT_ADD message is complete. The
> first CONSOLE_PORT message is handled by the second
> control_work_handler() call, but the second is handled by the first
> control_work_handler() call.
> 
> root@myubuntu:~# dmesg | grep MBH
> [3371055.808738] control_work_handler #1
> [3371055.809372] + #1 handle_control_message PORT_ADD
> [3371055.810169] - handle_control_message PORT_ADD
> [3371055.810170] + #1 handle_control_message PORT_ADD
> [3371055.810244]  control_work_handler #2
> [3371055.810245] + #2 handle_control_message CONSOLE_PORT
> [3371055.810246]  got hvc_ports_mutex
> [3371055.810578] - handle_control_message PORT_ADD
> [3371055.810579] + #1 handle_control_message CONSOLE_PORT
> [3371055.810580]  trylock of hvc_ports_mutex failed
> [3371055.811352]  got hvc_ports_mutex
> [3371055.811370] - handle_control_message CONSOLE_PORT
> [3371055.816609] - handle_control_message CONSOLE_PORT
> 
> So, I'm guessing the bug is that there shouldn't be two instances of
> control_work_handler() running simultaneously?

Yep, I assumed we did that but apparently not.  Do you plan to chase
this one down?

		Amit

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 11:17:08 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 11:17:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXWXQ-000329-Nv; Mon, 05 Dec 2011 11:16:48 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RXWXP-000322-KZ
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 11:16:47 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1323083762!1242820!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjAyNg==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25911 invoked from network); 5 Dec 2011 11:16:02 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Dec 2011 11:16:02 -0000
X-IronPort-AV: E=Sophos;i="4.71,298,1320624000"; 
   d="scan'208";a="9286464"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Dec 2011 11:16:01 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 5 Dec 2011 11:16:01 +0000
Date: Mon, 5 Dec 2011 11:17:03 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Jean Guyader <jean.guyader@eu.citrix.com>
In-Reply-To: <1322844443-4427-1-git-send-email-jean.guyader@eu.citrix.com>
Message-ID: <alpine.DEB.2.00.1112051108400.31179@kaball-desktop>
References: <1322844443-4427-1-git-send-email-jean.guyader@eu.citrix.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"allen.m.kay@intel.com" <allen.m.kay@intel.com>,
	Jean Guyader <Jean.Guyader@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] qemu-xen: Intel GPU passthrough,
 fix OpRegion mapping. (v2)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2 Dec 2011, Jean Guyader wrote:
> The OpRegion shouldn't be mapped 1:1 because the address in the host
> can't be used in the guest directly.
> 
> This patch traps read and write access to the opregion of the Intel
> GPU config space (offset 0xfc).
> 
> To work correctly this patch needs a change in hvmloader.
> 
> HVMloader will allocate 2 pages for the OpRegion and write this address
> on the config space of the Intel GPU. Qemu will trap and map the host
> OpRegion to the guest. Any write to this offset after that won't have
> any effect. Any read of this config space offset will return the address
> in the guest.
> 
> Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
> ---
>  hw/pass-through.c |   52 ++++++++++++++++++++++++++++++++++---
>  hw/pass-through.h |    4 +++
>  hw/pt-graphics.c  |   73 +++++++++++++++++++++++++++++++++++++++--------------
>  3 files changed, 105 insertions(+), 24 deletions(-)
>
> diff --git a/hw/pass-through.c b/hw/pass-through.c
> index 919937f..1378022 100644
> --- a/hw/pass-through.c
> +++ b/hw/pass-through.c
> @@ -237,6 +237,14 @@ static int pt_bar_reg_restore(struct pt_dev *ptdev,
>  static int pt_exp_rom_bar_reg_restore(struct pt_dev *ptdev,
>      struct pt_reg_tbl *cfg_entry,
>      uint32_t real_offset, uint32_t dev_value, uint32_t *value);
> +static int pt_intel_opregion_read(struct pt_dev *ptdev,
> +        struct pt_reg_tbl *cfg_entry,
> +        uint32_t *value, uint32_t valid_mask);
> +static int pt_intel_opregion_write(struct pt_dev *ptdev,
> +        struct pt_reg_tbl *cfg_entry,
> +        uint32_t *value, uint32_t dev_value, uint32_t valid_mask);
> +static uint8_t pt_reg_grp_header0_size_init(struct pt_dev *ptdev,
> +        struct pt_reg_grp_info_tbl *grp_reg, uint32_t base_offset);
>  
>  /* pt_reg_info_tbl declaration
>   * - only for emulated register (either a part or whole bit).
> @@ -443,6 +451,18 @@ static struct pt_reg_info_tbl pt_emu_reg_header0_tbl[] = {
>          .u.dw.write = pt_exp_rom_bar_reg_write,
>          .u.dw.restore = pt_exp_rom_bar_reg_restore,
>      },
> +    /* Vendor ID reg */
> +    {
> +        .offset     = PCI_INTEL_OPREGION,
> +        .size       = 4,
> +        .init_val   = 0x0000,
> +        .ro_mask    = 0xFFFFFFFF,
> +        .emu_mask   = 0xFFFFFFFF,
> +        .init       = pt_common_reg_init,
> +        .u.dw.read   = pt_intel_opregion_read,
> +        .u.dw.write  = pt_intel_opregion_write,
> +        .u.dw.restore  = NULL,
> +    },
>      {
>          .size = 0,
>      },
> @@ -736,7 +756,7 @@ static const struct pt_reg_grp_info_tbl pt_emu_reg_grp_tbl[] = {
>          .grp_id     = 0xFF,
>          .grp_type   = GRP_TYPE_EMU,
>          .grp_size   = 0x40,
> -        .size_init  = pt_reg_grp_size_init,
> +        .size_init  = pt_reg_grp_header0_size_init,
>          .emu_reg_tbl= pt_emu_reg_header0_tbl,
>      },
>      /* PCI PowerManagement Capability reg group */
> @@ -1400,7 +1420,7 @@ static struct pt_reg_grp_tbl* pt_find_reg_grp(struct pt_dev *ptdev,
>      {
>          /* check address */
>          if ((reg_grp_entry->base_offset <= address) &&
> -            ((reg_grp_entry->base_offset + reg_grp_entry->size) > address))
> +            ((reg_grp_entry->base_offset + reg_grp_entry->size) >= address))
>              goto out;
>      }
>      /* group entry not found */

I think that this change is wrong


> @@ -1455,8 +1475,7 @@ out:
>      return index;
>  }
>  
> -static void pt_pci_write_config(PCIDevice *d, uint32_t address, uint32_t val,
> -                                int len)
> +void pt_pci_write_config(PCIDevice *d, uint32_t address, uint32_t val, int len)
>  {
>      struct pt_dev *assigned_device = (struct pt_dev *)d;
>      struct pci_dev *pci_dev = assigned_device->pci_dev;

why are you removing static here?


> @@ -1637,7 +1656,7 @@ exit:
>      return;
>  }
>  
> -static uint32_t pt_pci_read_config(PCIDevice *d, uint32_t address, int len)
> +uint32_t pt_pci_read_config(PCIDevice *d, uint32_t address, int len)
>  {
>      struct pt_dev *assigned_device = (struct pt_dev *)d;
>      struct pci_dev *pci_dev = assigned_device->pci_dev;

I think you probably can get away without making this function
externally visible too, see below


> @@ -2965,6 +2984,14 @@ static uint32_t pt_msixctrl_reg_init(struct pt_dev *ptdev,
>      return reg->init_val;
>  }
>  
> +static uint8_t pt_reg_grp_header0_size_init(struct pt_dev *ptdev,
> +        struct pt_reg_grp_info_tbl *grp_reg, uint32_t base_offset)
> +{
> +    if (igd_passthru)
> +        return 0xFF;
> +    return grp_reg->grp_size;
> +}

Can you please add a comment on why you need to do that?


>  /* get register group size */
>  static uint8_t pt_reg_grp_size_init(struct pt_dev *ptdev,
>          struct pt_reg_grp_info_tbl *grp_reg, uint32_t base_offset)
> @@ -4113,6 +4140,21 @@ static int pt_pmcsr_reg_restore(struct pt_dev *ptdev,
>      return 0;
>  }
>  
> +static int pt_intel_opregion_read(struct pt_dev *ptdev,
> +        struct pt_reg_tbl *cfg_entry,
> +        uint32_t *value, uint32_t valid_mask)
> +{
> +    *value = igd_read_opregion(ptdev);
> +    return 0;
> +}
> +
> +static int pt_intel_opregion_write(struct pt_dev *ptdev,
> +        struct pt_reg_tbl *cfg_entry,
> +        uint32_t *value, uint32_t dev_value, uint32_t valid_mask)
> +{
> +    igd_write_opregion(ptdev, *value);
> +    return 0;
> +}
>  static struct pt_dev * register_real_device(PCIBus *e_bus,
>          const char *e_dev_name, int e_devfn, uint8_t r_bus, uint8_t r_dev,
>          uint8_t r_func, uint32_t machine_irq, struct pci_access *pci_access,
> diff --git a/hw/pass-through.h b/hw/pass-through.h
> index 884139c..9ab9638 100644
> --- a/hw/pass-through.h
> +++ b/hw/pass-through.h
> @@ -422,6 +422,10 @@ PCIBus *intel_pci_bridge_init(PCIBus *bus, int devfn, uint16_t vid,
>             uint16_t did, const char *name, uint16_t revision);
>  void igd_pci_write(PCIDevice *pci_dev, uint32_t config_addr, uint32_t val, int len);
>  uint32_t igd_pci_read(PCIDevice *pci_dev, uint32_t config_addr, int len);
> +uint32_t igd_read_opregion(struct pt_dev *pci_dev);
> +void igd_write_opregion(struct pt_dev *real_dev, uint32_t val);
> +uint32_t pt_pci_read_config(PCIDevice *d, uint32_t address, int len);
> +void pt_pci_write_config(PCIDevice *d, uint32_t address, uint32_t val, int len);
>  
>  #endif /* __PASSTHROUGH_H__ */
>  
> diff --git a/hw/pt-graphics.c b/hw/pt-graphics.c
> index fec7390..2e1dc44 100644
> --- a/hw/pt-graphics.c
> +++ b/hw/pt-graphics.c
> @@ -13,6 +13,8 @@
>  extern int gfx_passthru;
>  extern int igd_passthru;
>  
> +static uint32_t igd_guest_opregion = 0;
> +
>  static int pch_map_irq(PCIDevice *pci_dev, int irq_num)
>  {
>      PT_LOG("pch_map_irq called\n");
> @@ -37,6 +39,54 @@ void intel_pch_init(PCIBus *bus)
>                          pch_map_irq, "intel_bridge_1f");
>  }
>  
> +uint32_t igd_read_opregion(struct pt_dev *pci_dev)
> +{
> +    uint32_t val = -1;
> +
> +    if ( igd_guest_opregion )
> +        val = pt_pci_read_config((PCIDevice*)pci_dev, PCI_INTEL_OPREGION, 4);
> +
> +#ifdef PT_DEBUG_PCI_CONFIG_ACCESS
> +    PT_LOG_DEV((PCIDevice*)pci_dev, "addr=%x len=%x val=%x\n",
> +            PCI_INTEL_OPREGION, 4, val);
> +#endif
> +    return val;
> +}

Can you rearrange this function is a way that you perform the
pt_pci_read_config directly in pt_intel_opregion_read?



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 11:17:08 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 11:17:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXWXQ-000329-Nv; Mon, 05 Dec 2011 11:16:48 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RXWXP-000322-KZ
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 11:16:47 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1323083762!1242820!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjAyNg==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25911 invoked from network); 5 Dec 2011 11:16:02 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Dec 2011 11:16:02 -0000
X-IronPort-AV: E=Sophos;i="4.71,298,1320624000"; 
   d="scan'208";a="9286464"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Dec 2011 11:16:01 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 5 Dec 2011 11:16:01 +0000
Date: Mon, 5 Dec 2011 11:17:03 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Jean Guyader <jean.guyader@eu.citrix.com>
In-Reply-To: <1322844443-4427-1-git-send-email-jean.guyader@eu.citrix.com>
Message-ID: <alpine.DEB.2.00.1112051108400.31179@kaball-desktop>
References: <1322844443-4427-1-git-send-email-jean.guyader@eu.citrix.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"allen.m.kay@intel.com" <allen.m.kay@intel.com>,
	Jean Guyader <Jean.Guyader@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] qemu-xen: Intel GPU passthrough,
 fix OpRegion mapping. (v2)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2 Dec 2011, Jean Guyader wrote:
> The OpRegion shouldn't be mapped 1:1 because the address in the host
> can't be used in the guest directly.
> 
> This patch traps read and write access to the opregion of the Intel
> GPU config space (offset 0xfc).
> 
> To work correctly this patch needs a change in hvmloader.
> 
> HVMloader will allocate 2 pages for the OpRegion and write this address
> on the config space of the Intel GPU. Qemu will trap and map the host
> OpRegion to the guest. Any write to this offset after that won't have
> any effect. Any read of this config space offset will return the address
> in the guest.
> 
> Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
> ---
>  hw/pass-through.c |   52 ++++++++++++++++++++++++++++++++++---
>  hw/pass-through.h |    4 +++
>  hw/pt-graphics.c  |   73 +++++++++++++++++++++++++++++++++++++++--------------
>  3 files changed, 105 insertions(+), 24 deletions(-)
>
> diff --git a/hw/pass-through.c b/hw/pass-through.c
> index 919937f..1378022 100644
> --- a/hw/pass-through.c
> +++ b/hw/pass-through.c
> @@ -237,6 +237,14 @@ static int pt_bar_reg_restore(struct pt_dev *ptdev,
>  static int pt_exp_rom_bar_reg_restore(struct pt_dev *ptdev,
>      struct pt_reg_tbl *cfg_entry,
>      uint32_t real_offset, uint32_t dev_value, uint32_t *value);
> +static int pt_intel_opregion_read(struct pt_dev *ptdev,
> +        struct pt_reg_tbl *cfg_entry,
> +        uint32_t *value, uint32_t valid_mask);
> +static int pt_intel_opregion_write(struct pt_dev *ptdev,
> +        struct pt_reg_tbl *cfg_entry,
> +        uint32_t *value, uint32_t dev_value, uint32_t valid_mask);
> +static uint8_t pt_reg_grp_header0_size_init(struct pt_dev *ptdev,
> +        struct pt_reg_grp_info_tbl *grp_reg, uint32_t base_offset);
>  
>  /* pt_reg_info_tbl declaration
>   * - only for emulated register (either a part or whole bit).
> @@ -443,6 +451,18 @@ static struct pt_reg_info_tbl pt_emu_reg_header0_tbl[] = {
>          .u.dw.write = pt_exp_rom_bar_reg_write,
>          .u.dw.restore = pt_exp_rom_bar_reg_restore,
>      },
> +    /* Vendor ID reg */
> +    {
> +        .offset     = PCI_INTEL_OPREGION,
> +        .size       = 4,
> +        .init_val   = 0x0000,
> +        .ro_mask    = 0xFFFFFFFF,
> +        .emu_mask   = 0xFFFFFFFF,
> +        .init       = pt_common_reg_init,
> +        .u.dw.read   = pt_intel_opregion_read,
> +        .u.dw.write  = pt_intel_opregion_write,
> +        .u.dw.restore  = NULL,
> +    },
>      {
>          .size = 0,
>      },
> @@ -736,7 +756,7 @@ static const struct pt_reg_grp_info_tbl pt_emu_reg_grp_tbl[] = {
>          .grp_id     = 0xFF,
>          .grp_type   = GRP_TYPE_EMU,
>          .grp_size   = 0x40,
> -        .size_init  = pt_reg_grp_size_init,
> +        .size_init  = pt_reg_grp_header0_size_init,
>          .emu_reg_tbl= pt_emu_reg_header0_tbl,
>      },
>      /* PCI PowerManagement Capability reg group */
> @@ -1400,7 +1420,7 @@ static struct pt_reg_grp_tbl* pt_find_reg_grp(struct pt_dev *ptdev,
>      {
>          /* check address */
>          if ((reg_grp_entry->base_offset <= address) &&
> -            ((reg_grp_entry->base_offset + reg_grp_entry->size) > address))
> +            ((reg_grp_entry->base_offset + reg_grp_entry->size) >= address))
>              goto out;
>      }
>      /* group entry not found */

I think that this change is wrong


> @@ -1455,8 +1475,7 @@ out:
>      return index;
>  }
>  
> -static void pt_pci_write_config(PCIDevice *d, uint32_t address, uint32_t val,
> -                                int len)
> +void pt_pci_write_config(PCIDevice *d, uint32_t address, uint32_t val, int len)
>  {
>      struct pt_dev *assigned_device = (struct pt_dev *)d;
>      struct pci_dev *pci_dev = assigned_device->pci_dev;

why are you removing static here?


> @@ -1637,7 +1656,7 @@ exit:
>      return;
>  }
>  
> -static uint32_t pt_pci_read_config(PCIDevice *d, uint32_t address, int len)
> +uint32_t pt_pci_read_config(PCIDevice *d, uint32_t address, int len)
>  {
>      struct pt_dev *assigned_device = (struct pt_dev *)d;
>      struct pci_dev *pci_dev = assigned_device->pci_dev;

I think you probably can get away without making this function
externally visible too, see below


> @@ -2965,6 +2984,14 @@ static uint32_t pt_msixctrl_reg_init(struct pt_dev *ptdev,
>      return reg->init_val;
>  }
>  
> +static uint8_t pt_reg_grp_header0_size_init(struct pt_dev *ptdev,
> +        struct pt_reg_grp_info_tbl *grp_reg, uint32_t base_offset)
> +{
> +    if (igd_passthru)
> +        return 0xFF;
> +    return grp_reg->grp_size;
> +}

Can you please add a comment on why you need to do that?


>  /* get register group size */
>  static uint8_t pt_reg_grp_size_init(struct pt_dev *ptdev,
>          struct pt_reg_grp_info_tbl *grp_reg, uint32_t base_offset)
> @@ -4113,6 +4140,21 @@ static int pt_pmcsr_reg_restore(struct pt_dev *ptdev,
>      return 0;
>  }
>  
> +static int pt_intel_opregion_read(struct pt_dev *ptdev,
> +        struct pt_reg_tbl *cfg_entry,
> +        uint32_t *value, uint32_t valid_mask)
> +{
> +    *value = igd_read_opregion(ptdev);
> +    return 0;
> +}
> +
> +static int pt_intel_opregion_write(struct pt_dev *ptdev,
> +        struct pt_reg_tbl *cfg_entry,
> +        uint32_t *value, uint32_t dev_value, uint32_t valid_mask)
> +{
> +    igd_write_opregion(ptdev, *value);
> +    return 0;
> +}
>  static struct pt_dev * register_real_device(PCIBus *e_bus,
>          const char *e_dev_name, int e_devfn, uint8_t r_bus, uint8_t r_dev,
>          uint8_t r_func, uint32_t machine_irq, struct pci_access *pci_access,
> diff --git a/hw/pass-through.h b/hw/pass-through.h
> index 884139c..9ab9638 100644
> --- a/hw/pass-through.h
> +++ b/hw/pass-through.h
> @@ -422,6 +422,10 @@ PCIBus *intel_pci_bridge_init(PCIBus *bus, int devfn, uint16_t vid,
>             uint16_t did, const char *name, uint16_t revision);
>  void igd_pci_write(PCIDevice *pci_dev, uint32_t config_addr, uint32_t val, int len);
>  uint32_t igd_pci_read(PCIDevice *pci_dev, uint32_t config_addr, int len);
> +uint32_t igd_read_opregion(struct pt_dev *pci_dev);
> +void igd_write_opregion(struct pt_dev *real_dev, uint32_t val);
> +uint32_t pt_pci_read_config(PCIDevice *d, uint32_t address, int len);
> +void pt_pci_write_config(PCIDevice *d, uint32_t address, uint32_t val, int len);
>  
>  #endif /* __PASSTHROUGH_H__ */
>  
> diff --git a/hw/pt-graphics.c b/hw/pt-graphics.c
> index fec7390..2e1dc44 100644
> --- a/hw/pt-graphics.c
> +++ b/hw/pt-graphics.c
> @@ -13,6 +13,8 @@
>  extern int gfx_passthru;
>  extern int igd_passthru;
>  
> +static uint32_t igd_guest_opregion = 0;
> +
>  static int pch_map_irq(PCIDevice *pci_dev, int irq_num)
>  {
>      PT_LOG("pch_map_irq called\n");
> @@ -37,6 +39,54 @@ void intel_pch_init(PCIBus *bus)
>                          pch_map_irq, "intel_bridge_1f");
>  }
>  
> +uint32_t igd_read_opregion(struct pt_dev *pci_dev)
> +{
> +    uint32_t val = -1;
> +
> +    if ( igd_guest_opregion )
> +        val = pt_pci_read_config((PCIDevice*)pci_dev, PCI_INTEL_OPREGION, 4);
> +
> +#ifdef PT_DEBUG_PCI_CONFIG_ACCESS
> +    PT_LOG_DEV((PCIDevice*)pci_dev, "addr=%x len=%x val=%x\n",
> +            PCI_INTEL_OPREGION, 4, val);
> +#endif
> +    return val;
> +}

Can you rearrange this function is a way that you perform the
pt_pci_read_config directly in pt_intel_opregion_read?



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 11:20:10 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 11: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.xensource.com>)
	id 1RXWaS-00038P-BT; Mon, 05 Dec 2011 11:19:56 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RXWaQ-00038B-Ir
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 11:19:55 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-6.tower-182.messagelabs.com!1323083948!5909752!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNDI4NTE=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNDI4NTE=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23706 invoked from network); 5 Dec 2011 11:19:09 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-6.tower-182.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 5 Dec 2011 11:19:09 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1323083948; l=17100;
	s=domk; d=aepfle.de;
	h=To:From:Date:Subject:Content-Transfer-Encoding:MIME-Version:
	Content-Type:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=Lye6d3wuaxdUT1G5JwpyFHWsAZY=;
	b=E0//+EvcpWMdv3KQ1q4NDu+OHe/l4Fw0X2jZbjBCrcAuNkh3HlvRsZ040UeQ3cBHVXq
	yVs6hgJRQWOTjpHZLuGqGuJ59ts9uvT0KH2huwxECM7kTaxt3oUETtFYEuTqWlJqYhhwN
	EDcFSQM5qL5qSkSa5SC6IbXGLtefOidfhao=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFPjDcQG9ZE
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-124-085.pools.arcor-ip.net [88.65.124.85])
	by smtp.strato.de (klopstock mo32) (RZmta 26.10 AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id V048dcnB5AYGLF
	for <xen-devel@lists.xensource.com>;
	Mon, 5 Dec 2011 12:19:05 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id AE09C18636
	for <xen-devel@lists.xensource.com>;
	Mon,  5 Dec 2011 12:19:04 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: cd163bcd0f066e52ee74e42090188d632f0086bf
Message-Id: <cd163bcd0f066e52ee74.1323083943@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Mon, 05 Dec 2011 12:19:03 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH] mem_event: use wait queue when ring is full
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1323083831 -3600
# Node ID cd163bcd0f066e52ee74e42090188d632f0086bf
# Parent  a4d7c27ec1f190ecbb9a909609f6ef0eca250c00
mem_event: use wait queue when ring is full

This change is based on an idea/patch from Adin Scannell.

If the ring is full, put the current vcpu to sleep if it belongs to the
target domain. The wakeup happens in the p2m_*_resume functions. Wakeup
will take the number of free slots into account.

A request from foreign domain has to succeed once a slot was claimed
because such vcpus can not sleep.

This change fixes also a bug in p2m_mem_paging_drop_page(). Up to now a
full ring will lead to harmless inconsistency in the pager.


v5:
  - rename mem_event_check_ring() to mem_event_claim_slot()
  - rename mem_event_put_req_producers() to mem_event_release_slot()
  - add local/foreign request accounting
  - keep room for at least one guest request

v4:
 - fix off-by-one bug in _mem_event_put_request
 - add mem_event_wake_requesters() and use wake_up_nr()
 - rename mem_event_mark_and_pause() and mem_event_mark_and_pause() functions
 - req_producers counts foreign request producers, rename member

v3:
 - rename ->mem_event_bit to ->bit
 - remove me_ from new VPF_ defines

v2:
 - p2m_mem_paging_populate: move vcpu_pause after put_request, otherwise the
   vcpu will not wake_up after a wait_event because the pause_count was
   increased twice. Fixes guest hangs.
 - update free space check in _mem_event_put_request()
 - simplify mem_event_put_request()

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r a4d7c27ec1f1 -r cd163bcd0f06 xen/arch/x86/hvm/hvm.c
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -4156,8 +4156,8 @@ static int hvm_memory_event_traps(long p
     if ( (p & HVMPME_onchangeonly) && (value == old) )
         return 1;
     
-    rc = mem_event_check_ring(d, &d->mem_event->access);
-    if ( rc )
+    rc = mem_event_claim_slot(d, &d->mem_event->access);
+    if ( rc < 0 )
         return rc;
     
     memset(&req, 0, sizeof(req));
diff -r a4d7c27ec1f1 -r cd163bcd0f06 xen/arch/x86/mm/mem_event.c
--- a/xen/arch/x86/mm/mem_event.c
+++ b/xen/arch/x86/mm/mem_event.c
@@ -23,6 +23,7 @@
 
 #include <asm/domain.h>
 #include <xen/event.h>
+#include <xen/wait.h>
 #include <asm/p2m.h>
 #include <asm/mem_event.h>
 #include <asm/mem_paging.h>
@@ -39,6 +40,7 @@
 
 static int mem_event_enable(struct domain *d,
                             xen_domctl_mem_event_op_t *mec,
+                            int bit,
                             struct mem_event_domain *med)
 {
     int rc;
@@ -107,8 +109,12 @@ static int mem_event_enable(struct domai
 
     mem_event_ring_lock_init(med);
 
+    med->bit = bit;
+
+    init_waitqueue_head(&med->wq);
+
     /* Wake any VCPUs paused for memory events */
-    mem_event_unpause_vcpus(d);
+    mem_event_wake_waiters(d, med);
 
     return 0;
 
@@ -124,6 +130,9 @@ static int mem_event_enable(struct domai
 
 static int mem_event_disable(struct mem_event_domain *med)
 {
+    if (!list_empty(&med->wq.list))
+        return -EBUSY;
+
     unmap_domain_page(med->ring_page);
     med->ring_page = NULL;
 
@@ -133,13 +142,24 @@ static int mem_event_disable(struct mem_
     return 0;
 }
 
-void mem_event_put_request(struct domain *d, struct mem_event_domain *med, mem_event_request_t *req)
+static int _mem_event_put_request(struct domain *d,
+                                  struct mem_event_domain *med,
+                                  mem_event_request_t *req)
 {
     mem_event_front_ring_t *front_ring;
+    int free_req, claimed_req;
     RING_IDX req_prod;
 
     mem_event_ring_lock(med);
 
+    free_req = RING_FREE_REQUESTS(&med->front_ring);
+    /* Foreign requests must succeed because their vcpus can not sleep */
+    claimed_req = med->foreign_producers;
+    if ( !free_req || ( current->domain == d && free_req <= claimed_req ) ) {
+        mem_event_ring_unlock(med);
+        return 0;
+    }
+
     front_ring = &med->front_ring;
     req_prod = front_ring->req_prod_pvt;
 
@@ -147,14 +167,35 @@ void mem_event_put_request(struct domain
     memcpy(RING_GET_REQUEST(front_ring, req_prod), req, sizeof(*req));
     req_prod++;
 
+    /* Update accounting */
+    if ( current->domain == d )
+        med->target_producers--;
+    else
+        med->foreign_producers--;
+
     /* Update ring */
-    med->req_producers--;
     front_ring->req_prod_pvt = req_prod;
     RING_PUSH_REQUESTS(front_ring);
 
     mem_event_ring_unlock(med);
 
     notify_via_xen_event_channel(d, med->xen_port);
+
+    return 1;
+}
+
+void mem_event_put_request(struct domain *d, struct mem_event_domain *med,
+                           mem_event_request_t *req)
+{
+    /* Go to sleep if request came from guest */
+    if (current->domain == d) {
+        wait_event(med->wq, _mem_event_put_request(d, med, req));
+        return;
+    }
+    /* Ring was full anyway, unable to sleep in non-guest context */
+    if (!_mem_event_put_request(d, med, req))
+        printk("Failed to put memreq: d %u t %x f %x gfn %lx\n", d->domain_id,
+                req->type, req->flags, (unsigned long)req->gfn);
 }
 
 void mem_event_get_response(struct mem_event_domain *med, mem_event_response_t *rsp)
@@ -178,32 +219,97 @@ void mem_event_get_response(struct mem_e
     mem_event_ring_unlock(med);
 }
 
-void mem_event_unpause_vcpus(struct domain *d)
+/**
+ * mem_event_wake_requesters - Wake vcpus waiting for room in the ring
+ * @d: guest domain
+ * @med: mem_event ring
+ *
+ * mem_event_wake_requesters() will wakeup vcpus waiting for room in the
+ * ring. Only as many as can place another request in the ring will
+ * resume execution.
+ */
+void mem_event_wake_requesters(struct mem_event_domain *med)
+{
+    int free_req;
+
+    mem_event_ring_lock(med);
+
+    free_req = RING_FREE_REQUESTS(&med->front_ring);
+    if ( free_req )
+        wake_up_nr(&med->wq, free_req);
+
+    mem_event_ring_unlock(med);
+}
+
+/**
+ * mem_event_wake_waiters - Wake all vcpus waiting for the ring
+ * @d: guest domain
+ * @med: mem_event ring
+ *
+ * mem_event_wake_waiters() will wakeup all vcpus waiting for the ring to 
+ * become available.
+ */
+void mem_event_wake_waiters(struct domain *d, struct mem_event_domain *med)
 {
     struct vcpu *v;
 
     for_each_vcpu ( d, v )
-        if ( test_and_clear_bit(_VPF_mem_event, &v->pause_flags) )
+        if ( test_and_clear_bit(med->bit, &v->pause_flags) )
             vcpu_wake(v);
 }
 
-void mem_event_mark_and_pause(struct vcpu *v)
+/**
+ * mem_event_mark_and_sleep - Put vcpu to sleep
+ * @v: guest vcpu
+ * @med: mem_event ring
+ *
+ * mem_event_mark_and_sleep() tags vcpu and put it to sleep.
+ * The vcpu will resume execution in mem_event_wake_waiters().
+ */
+void mem_event_mark_and_sleep(struct vcpu *v, struct mem_event_domain *med)
 {
-    set_bit(_VPF_mem_event, &v->pause_flags);
+    set_bit(med->bit, &v->pause_flags);
     vcpu_sleep_nosync(v);
 }
 
-void mem_event_put_req_producers(struct mem_event_domain *med)
+/**
+ * mem_event_release_slot - Release a claimed slot
+ * @med: mem_event ring
+ *
+ * mem_event_release_slot() releases a claimed slot in the mem_event ring.
+ */
+void mem_event_release_slot(struct domain *d, struct mem_event_domain *med)
 {
     mem_event_ring_lock(med);
-    med->req_producers--;
+    if ( current->domain == d )
+        med->target_producers--;
+    else
+        med->foreign_producers--;
     mem_event_ring_unlock(med);
 }
 
-int mem_event_check_ring(struct domain *d, struct mem_event_domain *med)
+/**
+ * mem_event_claim_slot - Check state of a mem_event ring
+ * @d: guest domain
+ * @med: mem_event ring
+ *
+ * Return codes: < 0: the ring is not yet configured
+ *                 0: the ring has some room
+ *               > 0: the ring is full
+ *
+ * mem_event_claim_slot() checks the state of the given mem_event ring.
+ * If the current vcpu belongs to the guest domain, the function assumes that
+ * mem_event_put_request() will sleep until the ring has room again.
+ * A guest can always place at least one request.
+ *
+ * If the current vcpu does not belong to the target domain the caller must try
+ * again until there is room. A slot is claimed and the caller can place a
+ * request. If the caller does not need to send a request, the claimed slot has
+ * to be released with mem_event_release_slot().
+ */
+int mem_event_claim_slot(struct domain *d, struct mem_event_domain *med)
 {
-    struct vcpu *curr = current;
-    int free_requests;
+    int free_req;
     int ring_full = 1;
 
     if ( !med->ring_page )
@@ -211,16 +317,17 @@ int mem_event_check_ring(struct domain *
 
     mem_event_ring_lock(med);
 
-    free_requests = RING_FREE_REQUESTS(&med->front_ring);
-    if ( med->req_producers < free_requests )
+    free_req = RING_FREE_REQUESTS(&med->front_ring);
+
+    if ( current->domain == d ) {
+        med->target_producers++;
+        ring_full = 0;
+    } else if ( med->foreign_producers + med->target_producers + 1 < free_req )
     {
-        med->req_producers++;
+        med->foreign_producers++;
         ring_full = 0;
     }
 
-    if ( ring_full && (curr->domain == d) )
-        mem_event_mark_and_pause(curr);
-
     mem_event_ring_unlock(med);
 
     return ring_full;
@@ -287,7 +394,7 @@ int mem_event_domctl(struct domain *d, x
             if ( p2m->pod.entry_count )
                 break;
 
-            rc = mem_event_enable(d, mec, med);
+            rc = mem_event_enable(d, mec, _VPF_mem_paging, med);
         }
         break;
 
@@ -326,7 +433,7 @@ int mem_event_domctl(struct domain *d, x
             if ( boot_cpu_data.x86_vendor != X86_VENDOR_INTEL )
                 break;
 
-            rc = mem_event_enable(d, mec, med);
+            rc = mem_event_enable(d, mec, _VPF_mem_access, med);
         }
         break;
 
diff -r a4d7c27ec1f1 -r cd163bcd0f06 xen/arch/x86/mm/mem_sharing.c
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -253,18 +253,10 @@ static void mem_sharing_audit(void)
 #endif
 
 
-static struct page_info* mem_sharing_alloc_page(struct domain *d, 
-                                                unsigned long gfn)
+static void mem_sharing_notify_helper(struct domain *d, unsigned long gfn)
 {
-    struct page_info* page;
     struct vcpu *v = current;
-    mem_event_request_t req;
-
-    page = alloc_domheap_page(d, 0); 
-    if(page != NULL) return page;
-
-    memset(&req, 0, sizeof(req));
-    req.type = MEM_EVENT_TYPE_SHARED;
+    mem_event_request_t req = { .type = MEM_EVENT_TYPE_SHARED };
 
     if ( v->domain != d )
     {
@@ -275,20 +267,18 @@ static struct page_info* mem_sharing_all
         gdprintk(XENLOG_ERR, 
                  "Failed alloc on unshare path for foreign (%d) lookup\n",
                  d->domain_id);
-        return page;
+        return;
     }
 
-    vcpu_pause_nosync(v);
-    req.flags |= MEM_EVENT_FLAG_VCPU_PAUSED;
+    if (mem_event_claim_slot(d, &d->mem_event->share) < 0)
+        return;
 
-    if(mem_event_check_ring(d, &d->mem_event->share)) return page;
-
+    req.flags = MEM_EVENT_FLAG_VCPU_PAUSED;
     req.gfn = gfn;
     req.p2mt = p2m_ram_shared;
     req.vcpu_id = v->vcpu_id;
     mem_event_put_request(d, &d->mem_event->share, &req);
-
-    return page;
+    vcpu_pause_nosync(v);
 }
 
 unsigned int mem_sharing_get_nr_saved_mfns(void)
@@ -653,7 +643,7 @@ gfn_found:
     if(ret == 0) goto private_page_found;
         
     old_page = page;
-    page = mem_sharing_alloc_page(d, gfn);
+    page = alloc_domheap_page(d, 0); 
     if(!page) 
     {
         /* We've failed to obtain memory for private page. Need to re-add the
@@ -661,6 +651,7 @@ gfn_found:
         list_add(&gfn_info->list, &hash_entry->gfns);
         put_gfn(d, gfn);
         shr_unlock();
+        mem_sharing_notify_helper(d, gfn);
         return -ENOMEM;
     }
 
diff -r a4d7c27ec1f1 -r cd163bcd0f06 xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -861,20 +861,12 @@ int p2m_mem_paging_evict(struct domain *
  */
 void p2m_mem_paging_drop_page(struct domain *d, unsigned long gfn)
 {
-    struct vcpu *v = current;
-    mem_event_request_t req;
+    mem_event_request_t req = { .type = MEM_EVENT_TYPE_PAGING, .gfn = gfn };
 
-    /* Check that there's space on the ring for this request */
-    if ( mem_event_check_ring(d, &d->mem_event->paging) == 0)
-    {
-        /* Send release notification to pager */
-        memset(&req, 0, sizeof(req));
-        req.flags |= MEM_EVENT_FLAG_DROP_PAGE;
-        req.gfn = gfn;
-        req.vcpu_id = v->vcpu_id;
+    /* Send release notification to pager */
+    req.flags = MEM_EVENT_FLAG_DROP_PAGE;
 
-        mem_event_put_request(d, &d->mem_event->paging, &req);
-    }
+    mem_event_put_request(d, &d->mem_event->paging, &req);
 }
 
 /**
@@ -908,7 +900,7 @@ void p2m_mem_paging_populate(struct doma
     struct p2m_domain *p2m = p2m_get_hostp2m(d);
 
     /* Check that there's space on the ring for this request */
-    if ( mem_event_check_ring(d, &d->mem_event->paging) )
+    if ( mem_event_claim_slot(d, &d->mem_event->paging) )
         return;
 
     memset(&req, 0, sizeof(req));
@@ -938,7 +930,7 @@ void p2m_mem_paging_populate(struct doma
     else if ( p2mt != p2m_ram_paging_out && p2mt != p2m_ram_paged )
     {
         /* gfn is already on its way back and vcpu is not paused */
-        mem_event_put_req_producers(&d->mem_event->paging);
+        mem_event_release_slot(d, &d->mem_event->paging);
         return;
     }
 
@@ -1078,8 +1070,8 @@ void p2m_mem_paging_resume(struct domain
     if ( rsp.flags & MEM_EVENT_FLAG_VCPU_PAUSED )
         vcpu_unpause(d->vcpu[rsp.vcpu_id]);
 
-    /* Unpause any domains that were paused because the ring was full */
-    mem_event_unpause_vcpus(d);
+    /* Wake vcpus waiting for room in the ring */
+    mem_event_wake_requesters(&d->mem_event->paging);
 }
 
 void p2m_mem_access_check(unsigned long gpa, bool_t gla_valid, unsigned long gla, 
@@ -1108,7 +1100,7 @@ void p2m_mem_access_check(unsigned long 
     p2m_unlock(p2m);
 
     /* Otherwise, check if there is a memory event listener, and send the message along */
-    res = mem_event_check_ring(d, &d->mem_event->access);
+    res = mem_event_claim_slot(d, &d->mem_event->access);
     if ( res < 0 ) 
     {
         /* No listener */
@@ -1118,7 +1110,7 @@ void p2m_mem_access_check(unsigned long 
                    "Memory access permissions failure, no mem_event listener: pausing VCPU %d, dom %d\n",
                    v->vcpu_id, d->domain_id);
 
-            mem_event_mark_and_pause(v);
+            mem_event_mark_and_sleep(v, &d->mem_event->access);
         }
         else
         {
@@ -1167,9 +1159,11 @@ void p2m_mem_access_resume(struct domain
     if ( rsp.flags & MEM_EVENT_FLAG_VCPU_PAUSED )
         vcpu_unpause(d->vcpu[rsp.vcpu_id]);
 
-    /* Unpause any domains that were paused because the ring was full or no listener 
-     * was available */
-    mem_event_unpause_vcpus(d);
+    /* Wake vcpus waiting for room in the ring */
+    mem_event_wake_requesters(&d->mem_event->access);
+
+    /* Unpause all vcpus that were paused because no listener was available */
+    mem_event_wake_waiters(d, &d->mem_event->access);
 }
 
 
diff -r a4d7c27ec1f1 -r cd163bcd0f06 xen/include/asm-x86/mem_event.h
--- a/xen/include/asm-x86/mem_event.h
+++ b/xen/include/asm-x86/mem_event.h
@@ -24,13 +24,13 @@
 #ifndef __MEM_EVENT_H__
 #define __MEM_EVENT_H__
 
-/* Pauses VCPU while marking pause flag for mem event */
-void mem_event_mark_and_pause(struct vcpu *v);
-int mem_event_check_ring(struct domain *d, struct mem_event_domain *med);
-void mem_event_put_req_producers(struct mem_event_domain *med);
+int mem_event_claim_slot(struct domain *d, struct mem_event_domain *med);
+void mem_event_release_slot(struct domain *d, struct mem_event_domain *med);
 void mem_event_put_request(struct domain *d, struct mem_event_domain *med, mem_event_request_t *req);
 void mem_event_get_response(struct mem_event_domain *med, mem_event_response_t *rsp);
-void mem_event_unpause_vcpus(struct domain *d);
+void mem_event_wake_requesters(struct mem_event_domain *med);
+void mem_event_wake_waiters(struct domain *d, struct mem_event_domain *med);
+void mem_event_mark_and_sleep(struct vcpu *v, struct mem_event_domain *med);
 
 int mem_event_domctl(struct domain *d, xen_domctl_mem_event_op_t *mec,
                      XEN_GUEST_HANDLE(void) u_domctl);
diff -r a4d7c27ec1f1 -r cd163bcd0f06 xen/include/xen/sched.h
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -14,6 +14,7 @@
 #include <xen/nodemask.h>
 #include <xen/radix-tree.h>
 #include <xen/multicall.h>
+#include <xen/wait.h>
 #include <public/xen.h>
 #include <public/domctl.h>
 #include <public/sysctl.h>
@@ -183,7 +184,8 @@ struct mem_event_domain
 {
     /* ring lock */
     spinlock_t ring_lock;
-    unsigned int req_producers;
+    unsigned short foreign_producers;
+    unsigned short target_producers;
     /* shared page */
     mem_event_shared_page_t *shared_page;
     /* shared ring page */
@@ -192,6 +194,10 @@ struct mem_event_domain
     mem_event_front_ring_t front_ring;
     /* event channel port (vcpu0 only) */
     int xen_port;
+    /* mem_event bit for vcpu->pause_flags */
+    int bit;
+    /* list of vcpus waiting for room in the ring */
+    struct waitqueue_head wq;
 };
 
 struct mem_event_per_domain
@@ -615,9 +621,12 @@ static inline struct domain *next_domain
  /* VCPU affinity has changed: migrating to a new CPU. */
 #define _VPF_migrating       3
 #define VPF_migrating        (1UL<<_VPF_migrating)
- /* VCPU is blocked on memory-event ring. */
-#define _VPF_mem_event       4
-#define VPF_mem_event        (1UL<<_VPF_mem_event)
+ /* VCPU is blocked due to missing mem_paging ring. */
+#define _VPF_mem_paging      4
+#define VPF_mem_paging       (1UL<<_VPF_mem_paging)
+ /* VCPU is blocked due to missing mem_access ring. */
+#define _VPF_mem_access      5
+#define VPF_mem_access       (1UL<<_VPF_mem_access)
 
 static inline int vcpu_runnable(struct vcpu *v)
 {

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 11:20:10 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 11: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.xensource.com>)
	id 1RXWaS-00038P-BT; Mon, 05 Dec 2011 11:19:56 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RXWaQ-00038B-Ir
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 11:19:55 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-6.tower-182.messagelabs.com!1323083948!5909752!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNDI4NTE=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNDI4NTE=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23706 invoked from network); 5 Dec 2011 11:19:09 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-6.tower-182.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 5 Dec 2011 11:19:09 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1323083948; l=17100;
	s=domk; d=aepfle.de;
	h=To:From:Date:Subject:Content-Transfer-Encoding:MIME-Version:
	Content-Type:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=Lye6d3wuaxdUT1G5JwpyFHWsAZY=;
	b=E0//+EvcpWMdv3KQ1q4NDu+OHe/l4Fw0X2jZbjBCrcAuNkh3HlvRsZ040UeQ3cBHVXq
	yVs6hgJRQWOTjpHZLuGqGuJ59ts9uvT0KH2huwxECM7kTaxt3oUETtFYEuTqWlJqYhhwN
	EDcFSQM5qL5qSkSa5SC6IbXGLtefOidfhao=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFPjDcQG9ZE
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-124-085.pools.arcor-ip.net [88.65.124.85])
	by smtp.strato.de (klopstock mo32) (RZmta 26.10 AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id V048dcnB5AYGLF
	for <xen-devel@lists.xensource.com>;
	Mon, 5 Dec 2011 12:19:05 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id AE09C18636
	for <xen-devel@lists.xensource.com>;
	Mon,  5 Dec 2011 12:19:04 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: cd163bcd0f066e52ee74e42090188d632f0086bf
Message-Id: <cd163bcd0f066e52ee74.1323083943@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Mon, 05 Dec 2011 12:19:03 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH] mem_event: use wait queue when ring is full
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1323083831 -3600
# Node ID cd163bcd0f066e52ee74e42090188d632f0086bf
# Parent  a4d7c27ec1f190ecbb9a909609f6ef0eca250c00
mem_event: use wait queue when ring is full

This change is based on an idea/patch from Adin Scannell.

If the ring is full, put the current vcpu to sleep if it belongs to the
target domain. The wakeup happens in the p2m_*_resume functions. Wakeup
will take the number of free slots into account.

A request from foreign domain has to succeed once a slot was claimed
because such vcpus can not sleep.

This change fixes also a bug in p2m_mem_paging_drop_page(). Up to now a
full ring will lead to harmless inconsistency in the pager.


v5:
  - rename mem_event_check_ring() to mem_event_claim_slot()
  - rename mem_event_put_req_producers() to mem_event_release_slot()
  - add local/foreign request accounting
  - keep room for at least one guest request

v4:
 - fix off-by-one bug in _mem_event_put_request
 - add mem_event_wake_requesters() and use wake_up_nr()
 - rename mem_event_mark_and_pause() and mem_event_mark_and_pause() functions
 - req_producers counts foreign request producers, rename member

v3:
 - rename ->mem_event_bit to ->bit
 - remove me_ from new VPF_ defines

v2:
 - p2m_mem_paging_populate: move vcpu_pause after put_request, otherwise the
   vcpu will not wake_up after a wait_event because the pause_count was
   increased twice. Fixes guest hangs.
 - update free space check in _mem_event_put_request()
 - simplify mem_event_put_request()

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r a4d7c27ec1f1 -r cd163bcd0f06 xen/arch/x86/hvm/hvm.c
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -4156,8 +4156,8 @@ static int hvm_memory_event_traps(long p
     if ( (p & HVMPME_onchangeonly) && (value == old) )
         return 1;
     
-    rc = mem_event_check_ring(d, &d->mem_event->access);
-    if ( rc )
+    rc = mem_event_claim_slot(d, &d->mem_event->access);
+    if ( rc < 0 )
         return rc;
     
     memset(&req, 0, sizeof(req));
diff -r a4d7c27ec1f1 -r cd163bcd0f06 xen/arch/x86/mm/mem_event.c
--- a/xen/arch/x86/mm/mem_event.c
+++ b/xen/arch/x86/mm/mem_event.c
@@ -23,6 +23,7 @@
 
 #include <asm/domain.h>
 #include <xen/event.h>
+#include <xen/wait.h>
 #include <asm/p2m.h>
 #include <asm/mem_event.h>
 #include <asm/mem_paging.h>
@@ -39,6 +40,7 @@
 
 static int mem_event_enable(struct domain *d,
                             xen_domctl_mem_event_op_t *mec,
+                            int bit,
                             struct mem_event_domain *med)
 {
     int rc;
@@ -107,8 +109,12 @@ static int mem_event_enable(struct domai
 
     mem_event_ring_lock_init(med);
 
+    med->bit = bit;
+
+    init_waitqueue_head(&med->wq);
+
     /* Wake any VCPUs paused for memory events */
-    mem_event_unpause_vcpus(d);
+    mem_event_wake_waiters(d, med);
 
     return 0;
 
@@ -124,6 +130,9 @@ static int mem_event_enable(struct domai
 
 static int mem_event_disable(struct mem_event_domain *med)
 {
+    if (!list_empty(&med->wq.list))
+        return -EBUSY;
+
     unmap_domain_page(med->ring_page);
     med->ring_page = NULL;
 
@@ -133,13 +142,24 @@ static int mem_event_disable(struct mem_
     return 0;
 }
 
-void mem_event_put_request(struct domain *d, struct mem_event_domain *med, mem_event_request_t *req)
+static int _mem_event_put_request(struct domain *d,
+                                  struct mem_event_domain *med,
+                                  mem_event_request_t *req)
 {
     mem_event_front_ring_t *front_ring;
+    int free_req, claimed_req;
     RING_IDX req_prod;
 
     mem_event_ring_lock(med);
 
+    free_req = RING_FREE_REQUESTS(&med->front_ring);
+    /* Foreign requests must succeed because their vcpus can not sleep */
+    claimed_req = med->foreign_producers;
+    if ( !free_req || ( current->domain == d && free_req <= claimed_req ) ) {
+        mem_event_ring_unlock(med);
+        return 0;
+    }
+
     front_ring = &med->front_ring;
     req_prod = front_ring->req_prod_pvt;
 
@@ -147,14 +167,35 @@ void mem_event_put_request(struct domain
     memcpy(RING_GET_REQUEST(front_ring, req_prod), req, sizeof(*req));
     req_prod++;
 
+    /* Update accounting */
+    if ( current->domain == d )
+        med->target_producers--;
+    else
+        med->foreign_producers--;
+
     /* Update ring */
-    med->req_producers--;
     front_ring->req_prod_pvt = req_prod;
     RING_PUSH_REQUESTS(front_ring);
 
     mem_event_ring_unlock(med);
 
     notify_via_xen_event_channel(d, med->xen_port);
+
+    return 1;
+}
+
+void mem_event_put_request(struct domain *d, struct mem_event_domain *med,
+                           mem_event_request_t *req)
+{
+    /* Go to sleep if request came from guest */
+    if (current->domain == d) {
+        wait_event(med->wq, _mem_event_put_request(d, med, req));
+        return;
+    }
+    /* Ring was full anyway, unable to sleep in non-guest context */
+    if (!_mem_event_put_request(d, med, req))
+        printk("Failed to put memreq: d %u t %x f %x gfn %lx\n", d->domain_id,
+                req->type, req->flags, (unsigned long)req->gfn);
 }
 
 void mem_event_get_response(struct mem_event_domain *med, mem_event_response_t *rsp)
@@ -178,32 +219,97 @@ void mem_event_get_response(struct mem_e
     mem_event_ring_unlock(med);
 }
 
-void mem_event_unpause_vcpus(struct domain *d)
+/**
+ * mem_event_wake_requesters - Wake vcpus waiting for room in the ring
+ * @d: guest domain
+ * @med: mem_event ring
+ *
+ * mem_event_wake_requesters() will wakeup vcpus waiting for room in the
+ * ring. Only as many as can place another request in the ring will
+ * resume execution.
+ */
+void mem_event_wake_requesters(struct mem_event_domain *med)
+{
+    int free_req;
+
+    mem_event_ring_lock(med);
+
+    free_req = RING_FREE_REQUESTS(&med->front_ring);
+    if ( free_req )
+        wake_up_nr(&med->wq, free_req);
+
+    mem_event_ring_unlock(med);
+}
+
+/**
+ * mem_event_wake_waiters - Wake all vcpus waiting for the ring
+ * @d: guest domain
+ * @med: mem_event ring
+ *
+ * mem_event_wake_waiters() will wakeup all vcpus waiting for the ring to 
+ * become available.
+ */
+void mem_event_wake_waiters(struct domain *d, struct mem_event_domain *med)
 {
     struct vcpu *v;
 
     for_each_vcpu ( d, v )
-        if ( test_and_clear_bit(_VPF_mem_event, &v->pause_flags) )
+        if ( test_and_clear_bit(med->bit, &v->pause_flags) )
             vcpu_wake(v);
 }
 
-void mem_event_mark_and_pause(struct vcpu *v)
+/**
+ * mem_event_mark_and_sleep - Put vcpu to sleep
+ * @v: guest vcpu
+ * @med: mem_event ring
+ *
+ * mem_event_mark_and_sleep() tags vcpu and put it to sleep.
+ * The vcpu will resume execution in mem_event_wake_waiters().
+ */
+void mem_event_mark_and_sleep(struct vcpu *v, struct mem_event_domain *med)
 {
-    set_bit(_VPF_mem_event, &v->pause_flags);
+    set_bit(med->bit, &v->pause_flags);
     vcpu_sleep_nosync(v);
 }
 
-void mem_event_put_req_producers(struct mem_event_domain *med)
+/**
+ * mem_event_release_slot - Release a claimed slot
+ * @med: mem_event ring
+ *
+ * mem_event_release_slot() releases a claimed slot in the mem_event ring.
+ */
+void mem_event_release_slot(struct domain *d, struct mem_event_domain *med)
 {
     mem_event_ring_lock(med);
-    med->req_producers--;
+    if ( current->domain == d )
+        med->target_producers--;
+    else
+        med->foreign_producers--;
     mem_event_ring_unlock(med);
 }
 
-int mem_event_check_ring(struct domain *d, struct mem_event_domain *med)
+/**
+ * mem_event_claim_slot - Check state of a mem_event ring
+ * @d: guest domain
+ * @med: mem_event ring
+ *
+ * Return codes: < 0: the ring is not yet configured
+ *                 0: the ring has some room
+ *               > 0: the ring is full
+ *
+ * mem_event_claim_slot() checks the state of the given mem_event ring.
+ * If the current vcpu belongs to the guest domain, the function assumes that
+ * mem_event_put_request() will sleep until the ring has room again.
+ * A guest can always place at least one request.
+ *
+ * If the current vcpu does not belong to the target domain the caller must try
+ * again until there is room. A slot is claimed and the caller can place a
+ * request. If the caller does not need to send a request, the claimed slot has
+ * to be released with mem_event_release_slot().
+ */
+int mem_event_claim_slot(struct domain *d, struct mem_event_domain *med)
 {
-    struct vcpu *curr = current;
-    int free_requests;
+    int free_req;
     int ring_full = 1;
 
     if ( !med->ring_page )
@@ -211,16 +317,17 @@ int mem_event_check_ring(struct domain *
 
     mem_event_ring_lock(med);
 
-    free_requests = RING_FREE_REQUESTS(&med->front_ring);
-    if ( med->req_producers < free_requests )
+    free_req = RING_FREE_REQUESTS(&med->front_ring);
+
+    if ( current->domain == d ) {
+        med->target_producers++;
+        ring_full = 0;
+    } else if ( med->foreign_producers + med->target_producers + 1 < free_req )
     {
-        med->req_producers++;
+        med->foreign_producers++;
         ring_full = 0;
     }
 
-    if ( ring_full && (curr->domain == d) )
-        mem_event_mark_and_pause(curr);
-
     mem_event_ring_unlock(med);
 
     return ring_full;
@@ -287,7 +394,7 @@ int mem_event_domctl(struct domain *d, x
             if ( p2m->pod.entry_count )
                 break;
 
-            rc = mem_event_enable(d, mec, med);
+            rc = mem_event_enable(d, mec, _VPF_mem_paging, med);
         }
         break;
 
@@ -326,7 +433,7 @@ int mem_event_domctl(struct domain *d, x
             if ( boot_cpu_data.x86_vendor != X86_VENDOR_INTEL )
                 break;
 
-            rc = mem_event_enable(d, mec, med);
+            rc = mem_event_enable(d, mec, _VPF_mem_access, med);
         }
         break;
 
diff -r a4d7c27ec1f1 -r cd163bcd0f06 xen/arch/x86/mm/mem_sharing.c
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -253,18 +253,10 @@ static void mem_sharing_audit(void)
 #endif
 
 
-static struct page_info* mem_sharing_alloc_page(struct domain *d, 
-                                                unsigned long gfn)
+static void mem_sharing_notify_helper(struct domain *d, unsigned long gfn)
 {
-    struct page_info* page;
     struct vcpu *v = current;
-    mem_event_request_t req;
-
-    page = alloc_domheap_page(d, 0); 
-    if(page != NULL) return page;
-
-    memset(&req, 0, sizeof(req));
-    req.type = MEM_EVENT_TYPE_SHARED;
+    mem_event_request_t req = { .type = MEM_EVENT_TYPE_SHARED };
 
     if ( v->domain != d )
     {
@@ -275,20 +267,18 @@ static struct page_info* mem_sharing_all
         gdprintk(XENLOG_ERR, 
                  "Failed alloc on unshare path for foreign (%d) lookup\n",
                  d->domain_id);
-        return page;
+        return;
     }
 
-    vcpu_pause_nosync(v);
-    req.flags |= MEM_EVENT_FLAG_VCPU_PAUSED;
+    if (mem_event_claim_slot(d, &d->mem_event->share) < 0)
+        return;
 
-    if(mem_event_check_ring(d, &d->mem_event->share)) return page;
-
+    req.flags = MEM_EVENT_FLAG_VCPU_PAUSED;
     req.gfn = gfn;
     req.p2mt = p2m_ram_shared;
     req.vcpu_id = v->vcpu_id;
     mem_event_put_request(d, &d->mem_event->share, &req);
-
-    return page;
+    vcpu_pause_nosync(v);
 }
 
 unsigned int mem_sharing_get_nr_saved_mfns(void)
@@ -653,7 +643,7 @@ gfn_found:
     if(ret == 0) goto private_page_found;
         
     old_page = page;
-    page = mem_sharing_alloc_page(d, gfn);
+    page = alloc_domheap_page(d, 0); 
     if(!page) 
     {
         /* We've failed to obtain memory for private page. Need to re-add the
@@ -661,6 +651,7 @@ gfn_found:
         list_add(&gfn_info->list, &hash_entry->gfns);
         put_gfn(d, gfn);
         shr_unlock();
+        mem_sharing_notify_helper(d, gfn);
         return -ENOMEM;
     }
 
diff -r a4d7c27ec1f1 -r cd163bcd0f06 xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -861,20 +861,12 @@ int p2m_mem_paging_evict(struct domain *
  */
 void p2m_mem_paging_drop_page(struct domain *d, unsigned long gfn)
 {
-    struct vcpu *v = current;
-    mem_event_request_t req;
+    mem_event_request_t req = { .type = MEM_EVENT_TYPE_PAGING, .gfn = gfn };
 
-    /* Check that there's space on the ring for this request */
-    if ( mem_event_check_ring(d, &d->mem_event->paging) == 0)
-    {
-        /* Send release notification to pager */
-        memset(&req, 0, sizeof(req));
-        req.flags |= MEM_EVENT_FLAG_DROP_PAGE;
-        req.gfn = gfn;
-        req.vcpu_id = v->vcpu_id;
+    /* Send release notification to pager */
+    req.flags = MEM_EVENT_FLAG_DROP_PAGE;
 
-        mem_event_put_request(d, &d->mem_event->paging, &req);
-    }
+    mem_event_put_request(d, &d->mem_event->paging, &req);
 }
 
 /**
@@ -908,7 +900,7 @@ void p2m_mem_paging_populate(struct doma
     struct p2m_domain *p2m = p2m_get_hostp2m(d);
 
     /* Check that there's space on the ring for this request */
-    if ( mem_event_check_ring(d, &d->mem_event->paging) )
+    if ( mem_event_claim_slot(d, &d->mem_event->paging) )
         return;
 
     memset(&req, 0, sizeof(req));
@@ -938,7 +930,7 @@ void p2m_mem_paging_populate(struct doma
     else if ( p2mt != p2m_ram_paging_out && p2mt != p2m_ram_paged )
     {
         /* gfn is already on its way back and vcpu is not paused */
-        mem_event_put_req_producers(&d->mem_event->paging);
+        mem_event_release_slot(d, &d->mem_event->paging);
         return;
     }
 
@@ -1078,8 +1070,8 @@ void p2m_mem_paging_resume(struct domain
     if ( rsp.flags & MEM_EVENT_FLAG_VCPU_PAUSED )
         vcpu_unpause(d->vcpu[rsp.vcpu_id]);
 
-    /* Unpause any domains that were paused because the ring was full */
-    mem_event_unpause_vcpus(d);
+    /* Wake vcpus waiting for room in the ring */
+    mem_event_wake_requesters(&d->mem_event->paging);
 }
 
 void p2m_mem_access_check(unsigned long gpa, bool_t gla_valid, unsigned long gla, 
@@ -1108,7 +1100,7 @@ void p2m_mem_access_check(unsigned long 
     p2m_unlock(p2m);
 
     /* Otherwise, check if there is a memory event listener, and send the message along */
-    res = mem_event_check_ring(d, &d->mem_event->access);
+    res = mem_event_claim_slot(d, &d->mem_event->access);
     if ( res < 0 ) 
     {
         /* No listener */
@@ -1118,7 +1110,7 @@ void p2m_mem_access_check(unsigned long 
                    "Memory access permissions failure, no mem_event listener: pausing VCPU %d, dom %d\n",
                    v->vcpu_id, d->domain_id);
 
-            mem_event_mark_and_pause(v);
+            mem_event_mark_and_sleep(v, &d->mem_event->access);
         }
         else
         {
@@ -1167,9 +1159,11 @@ void p2m_mem_access_resume(struct domain
     if ( rsp.flags & MEM_EVENT_FLAG_VCPU_PAUSED )
         vcpu_unpause(d->vcpu[rsp.vcpu_id]);
 
-    /* Unpause any domains that were paused because the ring was full or no listener 
-     * was available */
-    mem_event_unpause_vcpus(d);
+    /* Wake vcpus waiting for room in the ring */
+    mem_event_wake_requesters(&d->mem_event->access);
+
+    /* Unpause all vcpus that were paused because no listener was available */
+    mem_event_wake_waiters(d, &d->mem_event->access);
 }
 
 
diff -r a4d7c27ec1f1 -r cd163bcd0f06 xen/include/asm-x86/mem_event.h
--- a/xen/include/asm-x86/mem_event.h
+++ b/xen/include/asm-x86/mem_event.h
@@ -24,13 +24,13 @@
 #ifndef __MEM_EVENT_H__
 #define __MEM_EVENT_H__
 
-/* Pauses VCPU while marking pause flag for mem event */
-void mem_event_mark_and_pause(struct vcpu *v);
-int mem_event_check_ring(struct domain *d, struct mem_event_domain *med);
-void mem_event_put_req_producers(struct mem_event_domain *med);
+int mem_event_claim_slot(struct domain *d, struct mem_event_domain *med);
+void mem_event_release_slot(struct domain *d, struct mem_event_domain *med);
 void mem_event_put_request(struct domain *d, struct mem_event_domain *med, mem_event_request_t *req);
 void mem_event_get_response(struct mem_event_domain *med, mem_event_response_t *rsp);
-void mem_event_unpause_vcpus(struct domain *d);
+void mem_event_wake_requesters(struct mem_event_domain *med);
+void mem_event_wake_waiters(struct domain *d, struct mem_event_domain *med);
+void mem_event_mark_and_sleep(struct vcpu *v, struct mem_event_domain *med);
 
 int mem_event_domctl(struct domain *d, xen_domctl_mem_event_op_t *mec,
                      XEN_GUEST_HANDLE(void) u_domctl);
diff -r a4d7c27ec1f1 -r cd163bcd0f06 xen/include/xen/sched.h
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -14,6 +14,7 @@
 #include <xen/nodemask.h>
 #include <xen/radix-tree.h>
 #include <xen/multicall.h>
+#include <xen/wait.h>
 #include <public/xen.h>
 #include <public/domctl.h>
 #include <public/sysctl.h>
@@ -183,7 +184,8 @@ struct mem_event_domain
 {
     /* ring lock */
     spinlock_t ring_lock;
-    unsigned int req_producers;
+    unsigned short foreign_producers;
+    unsigned short target_producers;
     /* shared page */
     mem_event_shared_page_t *shared_page;
     /* shared ring page */
@@ -192,6 +194,10 @@ struct mem_event_domain
     mem_event_front_ring_t front_ring;
     /* event channel port (vcpu0 only) */
     int xen_port;
+    /* mem_event bit for vcpu->pause_flags */
+    int bit;
+    /* list of vcpus waiting for room in the ring */
+    struct waitqueue_head wq;
 };
 
 struct mem_event_per_domain
@@ -615,9 +621,12 @@ static inline struct domain *next_domain
  /* VCPU affinity has changed: migrating to a new CPU. */
 #define _VPF_migrating       3
 #define VPF_migrating        (1UL<<_VPF_migrating)
- /* VCPU is blocked on memory-event ring. */
-#define _VPF_mem_event       4
-#define VPF_mem_event        (1UL<<_VPF_mem_event)
+ /* VCPU is blocked due to missing mem_paging ring. */
+#define _VPF_mem_paging      4
+#define VPF_mem_paging       (1UL<<_VPF_mem_paging)
+ /* VCPU is blocked due to missing mem_access ring. */
+#define _VPF_mem_access      5
+#define VPF_mem_access       (1UL<<_VPF_mem_access)
 
 static inline int vcpu_runnable(struct vcpu *v)
 {

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 11:21:29 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 11:21:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXWbf-0003EV-26; Mon, 05 Dec 2011 11:21:11 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RXWbd-0003EA-Cy
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 11:21:09 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-16.tower-21.messagelabs.com!1323084016!264901!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMTg4NDY=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMTg4NDY=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8872 invoked from network); 5 Dec 2011 11:20:20 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-16.tower-21.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 5 Dec 2011 11:20:20 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1323084016; l=245;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=WPuoo0GY8PU0veTF4GE4F6pxpZc=;
	b=wf+lRTDz+OpPrXbVoNPahstCNyr0HLKUlEtR4bbTxRQ5YtomPE/nN/RapN7M5MHnLxo
	jfPfKH2fQScnybbC9KoYvg6e1y2FFWjEvRAeIv9GNwLUBjvQHuZHvKNAIjSwIqSJHPc1j
	vpx0sDO3DnEXBgO01+MZmgBEm7zBJ3/GswE=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFPjDcQG9ZE
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-124-085.pools.arcor-ip.net [88.65.124.85])
	by smtp.strato.de (klopstock mo53) (RZmta 26.10 AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id 2054ffnB5AE8FZ ;
	Mon, 5 Dec 2011 12:19:58 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 9D4C218637; Mon,  5 Dec 2011 12:19:57 +0100 (CET)
Date: Mon, 5 Dec 2011 12:19:57 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20111205111957.GA28908@aepfle.de>
References: <2a4ec2e2ae36593aa74e.1322772973@xdev.gridcentric.ca>
	<20111202071148.GA23017@aepfle.de>
	<7ba95535823dd32cc2a73d78646059bc.squirrel@webmail.lagarcavilla.org>
	<20111202194344.GA1773@aepfle.de>
	<19affb017f36029502c4b0af8eca2d74.squirrel@webmail.lagarcavilla.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <19affb017f36029502c4b0af8eca2d74.squirrel@webmail.lagarcavilla.org>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com, tim@xen.org,
	keir.xen@gmail.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH] Flag events caused by foreign domains
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Dec 02, Andres Lagar-Cavilla wrote:

> > I'm wondering wether it really achieves what you want, no stall in the
> > ring buffer etc.
> That's not what I want with this patch...

Sure. 
Anyway, I'm not against this change.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 11:21:29 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 11:21:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXWbf-0003EV-26; Mon, 05 Dec 2011 11:21:11 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RXWbd-0003EA-Cy
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 11:21:09 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-16.tower-21.messagelabs.com!1323084016!264901!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMTg4NDY=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMTg4NDY=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8872 invoked from network); 5 Dec 2011 11:20:20 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-16.tower-21.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 5 Dec 2011 11:20:20 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1323084016; l=245;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=WPuoo0GY8PU0veTF4GE4F6pxpZc=;
	b=wf+lRTDz+OpPrXbVoNPahstCNyr0HLKUlEtR4bbTxRQ5YtomPE/nN/RapN7M5MHnLxo
	jfPfKH2fQScnybbC9KoYvg6e1y2FFWjEvRAeIv9GNwLUBjvQHuZHvKNAIjSwIqSJHPc1j
	vpx0sDO3DnEXBgO01+MZmgBEm7zBJ3/GswE=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFPjDcQG9ZE
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-124-085.pools.arcor-ip.net [88.65.124.85])
	by smtp.strato.de (klopstock mo53) (RZmta 26.10 AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id 2054ffnB5AE8FZ ;
	Mon, 5 Dec 2011 12:19:58 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 9D4C218637; Mon,  5 Dec 2011 12:19:57 +0100 (CET)
Date: Mon, 5 Dec 2011 12:19:57 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20111205111957.GA28908@aepfle.de>
References: <2a4ec2e2ae36593aa74e.1322772973@xdev.gridcentric.ca>
	<20111202071148.GA23017@aepfle.de>
	<7ba95535823dd32cc2a73d78646059bc.squirrel@webmail.lagarcavilla.org>
	<20111202194344.GA1773@aepfle.de>
	<19affb017f36029502c4b0af8eca2d74.squirrel@webmail.lagarcavilla.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <19affb017f36029502c4b0af8eca2d74.squirrel@webmail.lagarcavilla.org>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com, tim@xen.org,
	keir.xen@gmail.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH] Flag events caused by foreign domains
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Dec 02, Andres Lagar-Cavilla wrote:

> > I'm wondering wether it really achieves what you want, no stall in the
> > ring buffer etc.
> That's not what I want with this patch...

Sure. 
Anyway, I'm not against this change.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 11:25:28 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 11:25:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXWfa-0003UL-Rq; Mon, 05 Dec 2011 11:25:14 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RXWfZ-0003U1-6W
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 11:25:13 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-10.tower-27.messagelabs.com!1323084231!46589313!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNDI4NTE=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNDI4NTE=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21197 invoked from network); 5 Dec 2011 11:23:52 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-10.tower-27.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 5 Dec 2011 11:23:52 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1323084268; l=760;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=Q5y8gLr+YetzeYuHFFAJvy/J+6c=;
	b=Hk9T9us3azca0pgJHM28n+votn1P9oNtdkfzV4Fy/Dmp2HGKMdcKqRPKWCFQ2GD+r9O
	QDoCYP++nxZqXFKTbZJ5T1HbhacCBImUQE4lyiA2rM+MDp25yhhY6HEjbNsMP3q+KC5aJ
	UNKLScFGt1BGwTLXV32kOtwXZK/8a0GkDpo=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFPjDcQG9ZE
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-124-085.pools.arcor-ip.net [88.65.124.85])
	by smtp.strato.de (klopstock mo43) (RZmta 26.10 AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id Q04ef6nB59omU1 ;
	Mon, 5 Dec 2011 12:23:59 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 1B97718637; Mon,  5 Dec 2011 12:23:59 +0100 (CET)
Date: Mon, 5 Dec 2011 12:23:59 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20111205112358.GB28908@aepfle.de>
References: <patchbomb.1322603709@xdev.gridcentric.ca>
	<43dc614d543cdf84189d.1322603711@xdev.gridcentric.ca>
	<20111201145103.GA13045@aepfle.de>
	<457bf805a9709501746d2073fcd9082d.squirrel@webmail.lagarcavilla.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <457bf805a9709501746d2073fcd9082d.squirrel@webmail.lagarcavilla.org>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: xen-devel@lists.xensource.com, ian.campbell@citrix.com,
	andres@gridcentric.ca, tim@xen.org, keir.xen@gmail.com,
	jbeulich@suse.com, ian.jackson@citrix.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 2 of 5] Improve ring management for memory
 events. Do not lose guest events
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Dec 01, Andres Lagar-Cavilla wrote:

> MAX_HVM_VCPUS sits at 128 right now. Haven't compile checked, but that
> probably means we would need a two page ring. And then, when 1024-cpu
> hosts arrive and we grow MAX_HVM_VCPUS, we grow the ring size again.

The ring has 64 entries.

> Or, we could limit the constraint to the number of online vcpus, which
> would get somewhat tricky for vcpu hot-plugging.
> 
> I can fix that separately, once there is a decision on which way to go re
> ring management.


I just sent "[PATCH] mem_event: use wait queue when ring is full" to the
list. This version ought to work, it takes the request from both target
and foreign cpus into account and leaves at lease one slot for the
target.


Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 11:25:28 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 11:25:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXWfa-0003UL-Rq; Mon, 05 Dec 2011 11:25:14 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RXWfZ-0003U1-6W
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 11:25:13 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-10.tower-27.messagelabs.com!1323084231!46589313!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNDI4NTE=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNDI4NTE=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21197 invoked from network); 5 Dec 2011 11:23:52 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-10.tower-27.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 5 Dec 2011 11:23:52 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1323084268; l=760;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=Q5y8gLr+YetzeYuHFFAJvy/J+6c=;
	b=Hk9T9us3azca0pgJHM28n+votn1P9oNtdkfzV4Fy/Dmp2HGKMdcKqRPKWCFQ2GD+r9O
	QDoCYP++nxZqXFKTbZJ5T1HbhacCBImUQE4lyiA2rM+MDp25yhhY6HEjbNsMP3q+KC5aJ
	UNKLScFGt1BGwTLXV32kOtwXZK/8a0GkDpo=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFPjDcQG9ZE
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-124-085.pools.arcor-ip.net [88.65.124.85])
	by smtp.strato.de (klopstock mo43) (RZmta 26.10 AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id Q04ef6nB59omU1 ;
	Mon, 5 Dec 2011 12:23:59 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 1B97718637; Mon,  5 Dec 2011 12:23:59 +0100 (CET)
Date: Mon, 5 Dec 2011 12:23:59 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20111205112358.GB28908@aepfle.de>
References: <patchbomb.1322603709@xdev.gridcentric.ca>
	<43dc614d543cdf84189d.1322603711@xdev.gridcentric.ca>
	<20111201145103.GA13045@aepfle.de>
	<457bf805a9709501746d2073fcd9082d.squirrel@webmail.lagarcavilla.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <457bf805a9709501746d2073fcd9082d.squirrel@webmail.lagarcavilla.org>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: xen-devel@lists.xensource.com, ian.campbell@citrix.com,
	andres@gridcentric.ca, tim@xen.org, keir.xen@gmail.com,
	jbeulich@suse.com, ian.jackson@citrix.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 2 of 5] Improve ring management for memory
 events. Do not lose guest events
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Dec 01, Andres Lagar-Cavilla wrote:

> MAX_HVM_VCPUS sits at 128 right now. Haven't compile checked, but that
> probably means we would need a two page ring. And then, when 1024-cpu
> hosts arrive and we grow MAX_HVM_VCPUS, we grow the ring size again.

The ring has 64 entries.

> Or, we could limit the constraint to the number of online vcpus, which
> would get somewhat tricky for vcpu hot-plugging.
> 
> I can fix that separately, once there is a decision on which way to go re
> ring management.


I just sent "[PATCH] mem_event: use wait queue when ring is full" to the
list. This version ought to work, it takes the request from both target
and foreign cpus into account and leaves at lease one slot for the
target.


Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 11:33:13 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 11: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.xensource.com>)
	id 1RXWmz-0003kH-SF; Mon, 05 Dec 2011 11:32:53 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RXWmz-0003k9-3M
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 11:32:53 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-14.tower-174.messagelabs.com!1323084728!4090078!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27673 invoked from network); 5 Dec 2011 11:32:08 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-14.tower-174.messagelabs.com with SMTP;
	5 Dec 2011 11:32:08 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea01.nsa.gov (8.12.10/8.12.10) with ESMTP id
	pB5BT4Zp010620; Mon, 5 Dec 2011 11:29:05 GMT
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id pB5BT4OD001240; 
	Mon, 5 Dec 2011 06:29:04 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: Keir Fraser <keir@xen.org>
Date: Mon,  5 Dec 2011 06:29:24 -0500
Message-Id: <1323084564-19100-1-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.3
In-Reply-To: <4EDC9C2D02000078000655D1@nat28.tlf.novell.com>
References: <4EDC9C2D02000078000655D1@nat28.tlf.novell.com>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>, xen-devel@lists.xensource.com,
	JBeulich@suse.com
Subject: [Xen-devel] [PATCH] flask: Fix 32-bit compilation of label-pci tool
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

The 32-bit tools need to support 64-bit addresses, so use the correct
printf/scanf formats.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 tools/flask/utils/label-pci.c |   15 ++++++++-------
 1 files changed, 8 insertions(+), 7 deletions(-)

diff --git a/tools/flask/utils/label-pci.c b/tools/flask/utils/label-pci.c
index 839ad61..ca53ea8 100644
--- a/tools/flask/utils/label-pci.c
+++ b/tools/flask/utils/label-pci.c
@@ -15,6 +15,7 @@
 #include <sys/stat.h>
 #include <string.h>
 #include <unistd.h>
+#include <inttypes.h>
 #include <libflask.h>
 
 /* Pulled from linux/include/linux/ioport.h */
@@ -76,22 +77,22 @@ int main (int argCnt, char *argv[])
 		goto done;
 	}
 
-	while (fscanf(f, "0x%lx 0x%lx 0x%lx\n", &start, &end, &flags) == 3) {
+	while (fscanf(f, "0x%"PRIx64" 0x%"PRIx64" 0x%"PRIx64"\n", &start, &end, &flags) == 3) {
 		if (flags & IORESOURCE_IO) {
-			// printf("Port %lx-%lx\n", start, end);
+			// printf("Port %"PRIx64"-%"PRIx64"\n", start, end);
 			ret = flask_add_ioport(xch, start, end, argv[2]);
 			if (ret) {
-				fprintf(stderr, "flask_add_ioport %lx-%lx failed: %d\n",
+				fprintf(stderr, "flask_add_ioport %"PRIx64"-%"PRIx64" failed: %d\n",
 						start, end, ret);
 				err = 2;
 			}
 		} else if (flags & IORESOURCE_MEM) {
 			start >>= 12;
 			end >>= 12;
-			// printf("IOMEM %lx-%lx\n", start, end);
+			// printf("IOMEM %"PRIx64"-%"PRIx64"\n", start, end);
 			ret = flask_add_iomem(xch, start, end, argv[2]);
 			if (ret) {
-				fprintf(stderr, "flask_add_iomem %lx-%lx failed: %d\n",
+				fprintf(stderr, "flask_add_iomem %"PRIx64"-%"PRIx64" failed: %d\n",
 						start, end, ret);
 				err = 2;
 			}
@@ -105,11 +106,11 @@ int main (int argCnt, char *argv[])
 	if (!f)
 		goto done;
 	start = 0;
-	fscanf(f, "%ld", &start);
+	fscanf(f, "%" PRIu64, &start);
 	if (start) {
 		ret = flask_add_pirq(xch, start, argv[2]);
 		if (ret) {
-			fprintf(stderr, "flask_add_pirq %ld failed: %d\n",
+			fprintf(stderr, "flask_add_pirq %"PRIu64" failed: %d\n",
 					start, ret);
 			err = 2;
 		}
-- 
1.7.7.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 11:33:13 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 11: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.xensource.com>)
	id 1RXWmz-0003kH-SF; Mon, 05 Dec 2011 11:32:53 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RXWmz-0003k9-3M
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 11:32:53 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-14.tower-174.messagelabs.com!1323084728!4090078!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27673 invoked from network); 5 Dec 2011 11:32:08 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-14.tower-174.messagelabs.com with SMTP;
	5 Dec 2011 11:32:08 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea01.nsa.gov (8.12.10/8.12.10) with ESMTP id
	pB5BT4Zp010620; Mon, 5 Dec 2011 11:29:05 GMT
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id pB5BT4OD001240; 
	Mon, 5 Dec 2011 06:29:04 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: Keir Fraser <keir@xen.org>
Date: Mon,  5 Dec 2011 06:29:24 -0500
Message-Id: <1323084564-19100-1-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.3
In-Reply-To: <4EDC9C2D02000078000655D1@nat28.tlf.novell.com>
References: <4EDC9C2D02000078000655D1@nat28.tlf.novell.com>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>, xen-devel@lists.xensource.com,
	JBeulich@suse.com
Subject: [Xen-devel] [PATCH] flask: Fix 32-bit compilation of label-pci tool
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

The 32-bit tools need to support 64-bit addresses, so use the correct
printf/scanf formats.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 tools/flask/utils/label-pci.c |   15 ++++++++-------
 1 files changed, 8 insertions(+), 7 deletions(-)

diff --git a/tools/flask/utils/label-pci.c b/tools/flask/utils/label-pci.c
index 839ad61..ca53ea8 100644
--- a/tools/flask/utils/label-pci.c
+++ b/tools/flask/utils/label-pci.c
@@ -15,6 +15,7 @@
 #include <sys/stat.h>
 #include <string.h>
 #include <unistd.h>
+#include <inttypes.h>
 #include <libflask.h>
 
 /* Pulled from linux/include/linux/ioport.h */
@@ -76,22 +77,22 @@ int main (int argCnt, char *argv[])
 		goto done;
 	}
 
-	while (fscanf(f, "0x%lx 0x%lx 0x%lx\n", &start, &end, &flags) == 3) {
+	while (fscanf(f, "0x%"PRIx64" 0x%"PRIx64" 0x%"PRIx64"\n", &start, &end, &flags) == 3) {
 		if (flags & IORESOURCE_IO) {
-			// printf("Port %lx-%lx\n", start, end);
+			// printf("Port %"PRIx64"-%"PRIx64"\n", start, end);
 			ret = flask_add_ioport(xch, start, end, argv[2]);
 			if (ret) {
-				fprintf(stderr, "flask_add_ioport %lx-%lx failed: %d\n",
+				fprintf(stderr, "flask_add_ioport %"PRIx64"-%"PRIx64" failed: %d\n",
 						start, end, ret);
 				err = 2;
 			}
 		} else if (flags & IORESOURCE_MEM) {
 			start >>= 12;
 			end >>= 12;
-			// printf("IOMEM %lx-%lx\n", start, end);
+			// printf("IOMEM %"PRIx64"-%"PRIx64"\n", start, end);
 			ret = flask_add_iomem(xch, start, end, argv[2]);
 			if (ret) {
-				fprintf(stderr, "flask_add_iomem %lx-%lx failed: %d\n",
+				fprintf(stderr, "flask_add_iomem %"PRIx64"-%"PRIx64" failed: %d\n",
 						start, end, ret);
 				err = 2;
 			}
@@ -105,11 +106,11 @@ int main (int argCnt, char *argv[])
 	if (!f)
 		goto done;
 	start = 0;
-	fscanf(f, "%ld", &start);
+	fscanf(f, "%" PRIu64, &start);
 	if (start) {
 		ret = flask_add_pirq(xch, start, argv[2]);
 		if (ret) {
-			fprintf(stderr, "flask_add_pirq %ld failed: %d\n",
+			fprintf(stderr, "flask_add_pirq %"PRIu64" failed: %d\n",
 					start, ret);
 			err = 2;
 		}
-- 
1.7.7.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 11:34:23 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 11:34:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXWoB-0003nV-Cw; Mon, 05 Dec 2011 11:34:07 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RXWoA-0003n4-0l
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 11:34:06 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-11.tower-174.messagelabs.com!1323084800!4285207!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNDI4NTE=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNDI4NTE=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15461 invoked from network); 5 Dec 2011 11:33:21 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-11.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 5 Dec 2011 11:33:21 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1323084800; l=599;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=KtjFj1ufj8IG/w48Ul9NM3sjukw=;
	b=otLgfWYvSDK7IZz1uPapSRnxOfGtG6no7vBfc7o/YdUrFzj/pCpxK4/V4GhAshcfnrf
	hXN1ryP9kvitJC3eAO3FgJncwvl7CIfdAYLtQEdj9Cr8OHC1C5zdIW/tj4Yziz0C/PZPM
	Ko6nbCL/IwYSrmPMtGcH0bH/r6OSayYZbdo=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFPjDcQG9ZE
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-124-085.pools.arcor-ip.net [88.65.124.85])
	by smtp.strato.de (cohen mo55) (RZmta 26.10 AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id y05de0nB5AHx1v
	for <xen-devel@lists.xensource.com>;
	Mon, 5 Dec 2011 12:33:16 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 569DE18637; Mon,  5 Dec 2011 12:33:16 +0100 (CET)
Date: Mon, 5 Dec 2011 12:33:16 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Message-ID: <20111205113316.GA29024@aepfle.de>
References: <cd163bcd0f066e52ee74.1323083943@probook.site>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <cd163bcd0f066e52ee74.1323083943@probook.site>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Subject: Re: [Xen-devel] [PATCH] mem_event: use wait queue when ring is full
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Dec 05, Olaf Hering wrote:

> Wakeup will take the number of free slots into account.

This is not entirely tree unless this additional change is applied:

diff -r cd163bcd0f06 xen/arch/x86/mm/mem_event.c
--- a/xen/arch/x86/mm/mem_event.c
+++ b/xen/arch/x86/mm/mem_event.c
@@ -235,6 +235,7 @@ void mem_event_wake_requesters(struct me
     mem_event_ring_lock(med);
 
     free_req = RING_FREE_REQUESTS(&med->front_ring);
+    free_req -= med->foreign_producers;
     if ( free_req )
         wake_up_nr(&med->wq, free_req);
 

And perhaps the wake_up should be done outside the ring lock?

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 11:34:23 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 11:34:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXWoB-0003nV-Cw; Mon, 05 Dec 2011 11:34:07 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RXWoA-0003n4-0l
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 11:34:06 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-11.tower-174.messagelabs.com!1323084800!4285207!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNDI4NTE=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNDI4NTE=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15461 invoked from network); 5 Dec 2011 11:33:21 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-11.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 5 Dec 2011 11:33:21 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1323084800; l=599;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=KtjFj1ufj8IG/w48Ul9NM3sjukw=;
	b=otLgfWYvSDK7IZz1uPapSRnxOfGtG6no7vBfc7o/YdUrFzj/pCpxK4/V4GhAshcfnrf
	hXN1ryP9kvitJC3eAO3FgJncwvl7CIfdAYLtQEdj9Cr8OHC1C5zdIW/tj4Yziz0C/PZPM
	Ko6nbCL/IwYSrmPMtGcH0bH/r6OSayYZbdo=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFPjDcQG9ZE
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-124-085.pools.arcor-ip.net [88.65.124.85])
	by smtp.strato.de (cohen mo55) (RZmta 26.10 AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id y05de0nB5AHx1v
	for <xen-devel@lists.xensource.com>;
	Mon, 5 Dec 2011 12:33:16 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 569DE18637; Mon,  5 Dec 2011 12:33:16 +0100 (CET)
Date: Mon, 5 Dec 2011 12:33:16 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Message-ID: <20111205113316.GA29024@aepfle.de>
References: <cd163bcd0f066e52ee74.1323083943@probook.site>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <cd163bcd0f066e52ee74.1323083943@probook.site>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Subject: Re: [Xen-devel] [PATCH] mem_event: use wait queue when ring is full
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Dec 05, Olaf Hering wrote:

> Wakeup will take the number of free slots into account.

This is not entirely tree unless this additional change is applied:

diff -r cd163bcd0f06 xen/arch/x86/mm/mem_event.c
--- a/xen/arch/x86/mm/mem_event.c
+++ b/xen/arch/x86/mm/mem_event.c
@@ -235,6 +235,7 @@ void mem_event_wake_requesters(struct me
     mem_event_ring_lock(med);
 
     free_req = RING_FREE_REQUESTS(&med->front_ring);
+    free_req -= med->foreign_producers;
     if ( free_req )
         wake_up_nr(&med->wq, free_req);
 

And perhaps the wake_up should be done outside the ring lock?

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 11:35:24 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 11:35:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXWpE-0003tK-Vk; Mon, 05 Dec 2011 11:35:12 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RXWpD-0003sw-HM
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 11:35:11 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-9.tower-216.messagelabs.com!1323084866!6220629!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1915 invoked from network); 5 Dec 2011 11:34:26 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-9.tower-216.messagelabs.com with SMTP;
	5 Dec 2011 11:34:26 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea01.nsa.gov (8.12.10/8.12.10) with ESMTP id
	pB5BYPZp011404; Mon, 5 Dec 2011 11:34:25 GMT
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id pB5BYPPD001487; 
	Mon, 5 Dec 2011 06:34:25 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: Keir Fraser <keir@xen.org>
Date: Mon,  5 Dec 2011 06:34:45 -0500
Message-Id: <1323084885-7531-1-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.3
In-Reply-To: <4EDC9C2D02000078000655D1@nat28.tlf.novell.com>
References: <4EDC9C2D02000078000655D1@nat28.tlf.novell.com>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>, xen-devel@lists.xensource.com,
	JBeulich@suse.com
Subject: [Xen-devel] [PATCH v2] flask: Fix 32-bit compilation of label-pci
	tool
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

The 32-bit tools need to support 64-bit addresses, so use the correct
printf/scanf formats.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 tools/flask/utils/label-pci.c |   15 ++++++++-------
 1 files changed, 8 insertions(+), 7 deletions(-)

diff --git a/tools/flask/utils/label-pci.c b/tools/flask/utils/label-pci.c
index 839ad61..009a733 100644
--- a/tools/flask/utils/label-pci.c
+++ b/tools/flask/utils/label-pci.c
@@ -15,6 +15,7 @@
 #include <sys/stat.h>
 #include <string.h>
 #include <unistd.h>
+#include <inttypes.h>
 #include <libflask.h>
 
 /* Pulled from linux/include/linux/ioport.h */
@@ -76,22 +77,22 @@ int main (int argCnt, char *argv[])
 		goto done;
 	}
 
-	while (fscanf(f, "0x%lx 0x%lx 0x%lx\n", &start, &end, &flags) == 3) {
+	while (fscanf(f, "0x%"SCNx64" 0x%"SCNx64" 0x%"SCNx64"\n", &start, &end, &flags) == 3) {
 		if (flags & IORESOURCE_IO) {
-			// printf("Port %lx-%lx\n", start, end);
+			// printf("Port %"PRIx64"-%"PRIx64"\n", start, end);
 			ret = flask_add_ioport(xch, start, end, argv[2]);
 			if (ret) {
-				fprintf(stderr, "flask_add_ioport %lx-%lx failed: %d\n",
+				fprintf(stderr, "flask_add_ioport %"PRIx64"-%"PRIx64" failed: %d\n",
 						start, end, ret);
 				err = 2;
 			}
 		} else if (flags & IORESOURCE_MEM) {
 			start >>= 12;
 			end >>= 12;
-			// printf("IOMEM %lx-%lx\n", start, end);
+			// printf("IOMEM %"PRIx64"-%"PRIx64"\n", start, end);
 			ret = flask_add_iomem(xch, start, end, argv[2]);
 			if (ret) {
-				fprintf(stderr, "flask_add_iomem %lx-%lx failed: %d\n",
+				fprintf(stderr, "flask_add_iomem %"PRIx64"-%"PRIx64" failed: %d\n",
 						start, end, ret);
 				err = 2;
 			}
@@ -105,11 +106,11 @@ int main (int argCnt, char *argv[])
 	if (!f)
 		goto done;
 	start = 0;
-	fscanf(f, "%ld", &start);
+	fscanf(f, "%" SCNu64, &start);
 	if (start) {
 		ret = flask_add_pirq(xch, start, argv[2]);
 		if (ret) {
-			fprintf(stderr, "flask_add_pirq %ld failed: %d\n",
+			fprintf(stderr, "flask_add_pirq %"PRIu64" failed: %d\n",
 					start, ret);
 			err = 2;
 		}
-- 
1.7.7.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 11:35:24 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 11:35:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXWpE-0003tK-Vk; Mon, 05 Dec 2011 11:35:12 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RXWpD-0003sw-HM
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 11:35:11 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-9.tower-216.messagelabs.com!1323084866!6220629!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1915 invoked from network); 5 Dec 2011 11:34:26 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-9.tower-216.messagelabs.com with SMTP;
	5 Dec 2011 11:34:26 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea01.nsa.gov (8.12.10/8.12.10) with ESMTP id
	pB5BYPZp011404; Mon, 5 Dec 2011 11:34:25 GMT
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id pB5BYPPD001487; 
	Mon, 5 Dec 2011 06:34:25 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: Keir Fraser <keir@xen.org>
Date: Mon,  5 Dec 2011 06:34:45 -0500
Message-Id: <1323084885-7531-1-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.3
In-Reply-To: <4EDC9C2D02000078000655D1@nat28.tlf.novell.com>
References: <4EDC9C2D02000078000655D1@nat28.tlf.novell.com>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>, xen-devel@lists.xensource.com,
	JBeulich@suse.com
Subject: [Xen-devel] [PATCH v2] flask: Fix 32-bit compilation of label-pci
	tool
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

The 32-bit tools need to support 64-bit addresses, so use the correct
printf/scanf formats.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 tools/flask/utils/label-pci.c |   15 ++++++++-------
 1 files changed, 8 insertions(+), 7 deletions(-)

diff --git a/tools/flask/utils/label-pci.c b/tools/flask/utils/label-pci.c
index 839ad61..009a733 100644
--- a/tools/flask/utils/label-pci.c
+++ b/tools/flask/utils/label-pci.c
@@ -15,6 +15,7 @@
 #include <sys/stat.h>
 #include <string.h>
 #include <unistd.h>
+#include <inttypes.h>
 #include <libflask.h>
 
 /* Pulled from linux/include/linux/ioport.h */
@@ -76,22 +77,22 @@ int main (int argCnt, char *argv[])
 		goto done;
 	}
 
-	while (fscanf(f, "0x%lx 0x%lx 0x%lx\n", &start, &end, &flags) == 3) {
+	while (fscanf(f, "0x%"SCNx64" 0x%"SCNx64" 0x%"SCNx64"\n", &start, &end, &flags) == 3) {
 		if (flags & IORESOURCE_IO) {
-			// printf("Port %lx-%lx\n", start, end);
+			// printf("Port %"PRIx64"-%"PRIx64"\n", start, end);
 			ret = flask_add_ioport(xch, start, end, argv[2]);
 			if (ret) {
-				fprintf(stderr, "flask_add_ioport %lx-%lx failed: %d\n",
+				fprintf(stderr, "flask_add_ioport %"PRIx64"-%"PRIx64" failed: %d\n",
 						start, end, ret);
 				err = 2;
 			}
 		} else if (flags & IORESOURCE_MEM) {
 			start >>= 12;
 			end >>= 12;
-			// printf("IOMEM %lx-%lx\n", start, end);
+			// printf("IOMEM %"PRIx64"-%"PRIx64"\n", start, end);
 			ret = flask_add_iomem(xch, start, end, argv[2]);
 			if (ret) {
-				fprintf(stderr, "flask_add_iomem %lx-%lx failed: %d\n",
+				fprintf(stderr, "flask_add_iomem %"PRIx64"-%"PRIx64" failed: %d\n",
 						start, end, ret);
 				err = 2;
 			}
@@ -105,11 +106,11 @@ int main (int argCnt, char *argv[])
 	if (!f)
 		goto done;
 	start = 0;
-	fscanf(f, "%ld", &start);
+	fscanf(f, "%" SCNu64, &start);
 	if (start) {
 		ret = flask_add_pirq(xch, start, argv[2]);
 		if (ret) {
-			fprintf(stderr, "flask_add_pirq %ld failed: %d\n",
+			fprintf(stderr, "flask_add_pirq %"PRIu64" failed: %d\n",
 					start, ret);
 			err = 2;
 		}
-- 
1.7.7.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 11:36:05 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 11:36:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXWpu-0003y1-EU; Mon, 05 Dec 2011 11:35:54 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1RXWps-0003xA-7G
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 11:35:52 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1323084906!6206005!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjk1OTY=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28445 invoked from network); 5 Dec 2011 11:35:07 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Dec 2011 11:35:07 -0000
X-IronPort-AV: E=Sophos;i="4.71,298,1320642000"; d="scan'208";a="172884090"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Dec 2011 06:35:05 -0500
Received: from [10.80.2.18] (10.80.2.18) by FTLPMAILMX01.citrite.net
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Mon, 5 Dec 2011
	06:35:05 -0500
Message-ID: <4EDCAC68.8060303@citrix.com>
Date: Mon, 5 Dec 2011 11:35:04 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.23) Gecko/20110921 Lightning/1.0b2 Thunderbird/3.1.15
MIME-Version: 1.0
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
X-Enigmail-Version: 1.1.2
Content-Type: multipart/mixed; boundary="------------060006030804030101050103"
Subject: [Xen-devel] KEXEC: fix kexec_get_range_compat to fail vocally
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--------------060006030804030101050103
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit

I am not sure that this is the only instance, but it is really not
acceptable to hand truncated pointers or sizes for physical memory to dom0.

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com


--------------060006030804030101050103
Content-Type: text/x-patch; name="KEXEC-fix-kexec_get_range_compat.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename="KEXEC-fix-kexec_get_range_compat.patch"

KEXEC: fix kexec_get_range_compat to fail vocally.

Fail with -ERANGE rather than silently truncating 64bit values (a
physical address and size) into 32bit integers for dom0 to consume.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

diff -r df7cec2c6c03 xen/common/kexec.c
--- a/xen/common/kexec.c
+++ b/xen/common/kexec.c
@@ -395,6 +395,12 @@ static int kexec_get_range_compat(XEN_GU
 
     ret = kexec_get_range_internal(&range);
 
+#define RANGE_MASK (((unsigned long)-1) & ~((unsigned int)-1))
+    /* Dont silently truncate physical addresses or sizes. */
+    if ( range.start & RANGE_MASK || range.size & RANGE_MASK )
+        return -ERANGE;
+#undef RANGE_MASK
+
     if ( ret == 0 ) {
         XLAT_kexec_range(&compat_range, &range);
         if ( unlikely(copy_to_guest(uarg, &compat_range, 1)) )

--------------060006030804030101050103
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--------------060006030804030101050103--


From xen-devel-bounces@lists.xensource.com Mon Dec 05 11:36:05 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 11:36:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXWpu-0003y1-EU; Mon, 05 Dec 2011 11:35:54 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1RXWps-0003xA-7G
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 11:35:52 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1323084906!6206005!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjk1OTY=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28445 invoked from network); 5 Dec 2011 11:35:07 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Dec 2011 11:35:07 -0000
X-IronPort-AV: E=Sophos;i="4.71,298,1320642000"; d="scan'208";a="172884090"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Dec 2011 06:35:05 -0500
Received: from [10.80.2.18] (10.80.2.18) by FTLPMAILMX01.citrite.net
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Mon, 5 Dec 2011
	06:35:05 -0500
Message-ID: <4EDCAC68.8060303@citrix.com>
Date: Mon, 5 Dec 2011 11:35:04 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.23) Gecko/20110921 Lightning/1.0b2 Thunderbird/3.1.15
MIME-Version: 1.0
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
X-Enigmail-Version: 1.1.2
Content-Type: multipart/mixed; boundary="------------060006030804030101050103"
Subject: [Xen-devel] KEXEC: fix kexec_get_range_compat to fail vocally
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--------------060006030804030101050103
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit

I am not sure that this is the only instance, but it is really not
acceptable to hand truncated pointers or sizes for physical memory to dom0.

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com


--------------060006030804030101050103
Content-Type: text/x-patch; name="KEXEC-fix-kexec_get_range_compat.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename="KEXEC-fix-kexec_get_range_compat.patch"

KEXEC: fix kexec_get_range_compat to fail vocally.

Fail with -ERANGE rather than silently truncating 64bit values (a
physical address and size) into 32bit integers for dom0 to consume.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

diff -r df7cec2c6c03 xen/common/kexec.c
--- a/xen/common/kexec.c
+++ b/xen/common/kexec.c
@@ -395,6 +395,12 @@ static int kexec_get_range_compat(XEN_GU
 
     ret = kexec_get_range_internal(&range);
 
+#define RANGE_MASK (((unsigned long)-1) & ~((unsigned int)-1))
+    /* Dont silently truncate physical addresses or sizes. */
+    if ( range.start & RANGE_MASK || range.size & RANGE_MASK )
+        return -ERANGE;
+#undef RANGE_MASK
+
     if ( ret == 0 ) {
         XLAT_kexec_range(&compat_range, &range);
         if ( unlikely(copy_to_guest(uarg, &compat_range, 1)) )

--------------060006030804030101050103
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--------------060006030804030101050103--


From xen-devel-bounces@lists.xensource.com Mon Dec 05 12:46:41 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 12:46:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXXvs-00053w-9Q; Mon, 05 Dec 2011 12:46:08 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1RXXvr-00053r-E8
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 12:46:07 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1323089121!5912317!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMjkyOTA3\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23199 invoked from network); 5 Dec 2011 12:45:22 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-9.tower-182.messagelabs.com with SMTP;
	5 Dec 2011 12:45:22 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga101.jf.intel.com with ESMTP; 05 Dec 2011 04:45:21 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.67,351,1309762800"; d="scan'208";a="83523692"
Received: from pgsmsx601.gar.corp.intel.com ([10.221.43.69])
	by orsmga002.jf.intel.com with ESMTP; 05 Dec 2011 04:45:20 -0800
Received: from pgsmsx101.gar.corp.intel.com (10.221.44.78) by
	pgsmsx601.gar.corp.intel.com (10.221.43.69) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Mon, 5 Dec 2011 20:45:19 +0800
Received: from shsmsx601.ccr.corp.intel.com (10.239.4.112) by
	PGSMSX101.gar.corp.intel.com (10.221.44.78) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Mon, 5 Dec 2011 20:45:19 +0800
Received: from shsmsx502.ccr.corp.intel.com ([10.239.4.96]) by
	shsmsx601.ccr.corp.intel.com ([10.239.4.112]) with mapi; Mon, 5 Dec 2011
	20:45:17 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Keir Fraser <keir.xen@gmail.com>, Jan Beulich <JBeulich@suse.com>
Date: Mon, 5 Dec 2011 20:45:16 +0800
Thread-Topic: [PATCH 3/6] X86: Disable PCID/INVPCID for dom0
Thread-Index: AcywK9H87r5cemygrE6Pva5Wvk+d3wDH9UUg
Message-ID: <BC00F5384FCFC9499AF06F92E8B78A9E2870CA7A00@shsmsx502.ccr.corp.intel.com>
References: <4ED761060200007800064A09@nat28.tlf.novell.com>
	<CAFCBED2.262CA%keir.xen@gmail.com>
In-Reply-To: <CAFCBED2.262CA%keir.xen@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 3/6] X86: Disable PCID/INVPCID for dom0
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Keir Fraser wrote:
> On 01/12/2011 10:12, "Jan Beulich" <JBeulich@suse.com> wrote:
> 
>>>> 
>>>> For pv, if expose PCID to pv, the PCIDs of different pv domain may
>>>> conflict, which make processor confused at TLB.
>>>> To make PCID work at pv, it need
>>>> 1, either a coordinated PCID allocation algorithm, so that the
>>>> local PCID of pv domain can be changed to a global unique PCID; 2,
>>>> or, a 'clean' vcpu context switch logic to flush all TLB;
>>>> method 1 make things complex w/o obvious benefit;
>>>> method 2 need change current vcpu context switch logic (i.e, mov
>>>> cr3 only flush TLB entries of specific PCID if PCID enabled), and
>>>> if flush *all* TLB is required at context switch, we lose the
>>>> change to optimize context switch by partly flush TLB case by
>>>> case, which may result in performance regression;
>>>> 
>>>> Thanks,
>>>> Jinsong
>>> 
>>> Jan, any comments? Thanks, Jinsong
>> 
>> No, no further comments (just don't have the time right now to think
>> through the possible alternatives). So for the moment I think things
>> could go in as posted by you. It's not immediately clear though
>> whether the series needs to be applied in order (it would seem that's
>> not a requirement, but I'd like your confirmation), as I could at
>> most take care of patches 2, 3, and 6.
> 
> I'm happy for you to apply the whole lot.
> 
> Acked-by: Keir Fraser <keir@xen.org>
> 
>> Jan

Any comments about patches 1/4/5?

Thanks,
Jinsong
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 12:46:41 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 12:46:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXXvs-00053w-9Q; Mon, 05 Dec 2011 12:46:08 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1RXXvr-00053r-E8
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 12:46:07 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1323089121!5912317!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMjkyOTA3\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23199 invoked from network); 5 Dec 2011 12:45:22 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-9.tower-182.messagelabs.com with SMTP;
	5 Dec 2011 12:45:22 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga101.jf.intel.com with ESMTP; 05 Dec 2011 04:45:21 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.67,351,1309762800"; d="scan'208";a="83523692"
Received: from pgsmsx601.gar.corp.intel.com ([10.221.43.69])
	by orsmga002.jf.intel.com with ESMTP; 05 Dec 2011 04:45:20 -0800
Received: from pgsmsx101.gar.corp.intel.com (10.221.44.78) by
	pgsmsx601.gar.corp.intel.com (10.221.43.69) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Mon, 5 Dec 2011 20:45:19 +0800
Received: from shsmsx601.ccr.corp.intel.com (10.239.4.112) by
	PGSMSX101.gar.corp.intel.com (10.221.44.78) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Mon, 5 Dec 2011 20:45:19 +0800
Received: from shsmsx502.ccr.corp.intel.com ([10.239.4.96]) by
	shsmsx601.ccr.corp.intel.com ([10.239.4.112]) with mapi; Mon, 5 Dec 2011
	20:45:17 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Keir Fraser <keir.xen@gmail.com>, Jan Beulich <JBeulich@suse.com>
Date: Mon, 5 Dec 2011 20:45:16 +0800
Thread-Topic: [PATCH 3/6] X86: Disable PCID/INVPCID for dom0
Thread-Index: AcywK9H87r5cemygrE6Pva5Wvk+d3wDH9UUg
Message-ID: <BC00F5384FCFC9499AF06F92E8B78A9E2870CA7A00@shsmsx502.ccr.corp.intel.com>
References: <4ED761060200007800064A09@nat28.tlf.novell.com>
	<CAFCBED2.262CA%keir.xen@gmail.com>
In-Reply-To: <CAFCBED2.262CA%keir.xen@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 3/6] X86: Disable PCID/INVPCID for dom0
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Keir Fraser wrote:
> On 01/12/2011 10:12, "Jan Beulich" <JBeulich@suse.com> wrote:
> 
>>>> 
>>>> For pv, if expose PCID to pv, the PCIDs of different pv domain may
>>>> conflict, which make processor confused at TLB.
>>>> To make PCID work at pv, it need
>>>> 1, either a coordinated PCID allocation algorithm, so that the
>>>> local PCID of pv domain can be changed to a global unique PCID; 2,
>>>> or, a 'clean' vcpu context switch logic to flush all TLB;
>>>> method 1 make things complex w/o obvious benefit;
>>>> method 2 need change current vcpu context switch logic (i.e, mov
>>>> cr3 only flush TLB entries of specific PCID if PCID enabled), and
>>>> if flush *all* TLB is required at context switch, we lose the
>>>> change to optimize context switch by partly flush TLB case by
>>>> case, which may result in performance regression;
>>>> 
>>>> Thanks,
>>>> Jinsong
>>> 
>>> Jan, any comments? Thanks, Jinsong
>> 
>> No, no further comments (just don't have the time right now to think
>> through the possible alternatives). So for the moment I think things
>> could go in as posted by you. It's not immediately clear though
>> whether the series needs to be applied in order (it would seem that's
>> not a requirement, but I'd like your confirmation), as I could at
>> most take care of patches 2, 3, and 6.
> 
> I'm happy for you to apply the whole lot.
> 
> Acked-by: Keir Fraser <keir@xen.org>
> 
>> Jan

Any comments about patches 1/4/5?

Thanks,
Jinsong
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 12:59:15 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 12:59:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXY83-0005Ei-Ri; Mon, 05 Dec 2011 12:58:43 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RXY81-0005Ed-Lk
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 12:58:41 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1323089860!50917299!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4OTE=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32337 invoked from network); 5 Dec 2011 12:57:40 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-13.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 5 Dec 2011 12:57:40 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 05 Dec 2011 12:58:01 +0000
Message-Id: <4EDCCDE802000078000656A1@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 05 Dec 2011 12:58:00 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>
References: <4EDCAC68.8060303@citrix.com>
In-Reply-To: <4EDCAC68.8060303@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] KEXEC: fix kexec_get_range_compat to fail vocally
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 05.12.11 at 12:35, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
> I am not sure that this is the only instance, but it is really not
> acceptable to hand truncated pointers or sizes for physical memory to dom0.

While I agree to the change, I think we also ought to add a new flavor
of KEXEC_CMD_kexec_get_range that is 64-bit capable even for a
32-bit Dom0.

Both under the assumption that apart from the truncation nothing
prevents addresses above the 4G boundary from being usable with
a 32-bit kernel for at least one of the ranges (probably only
KEXEC_RANGE_MA_CPU and KEXEC_RANGE_MA_VMCOREINFO are
candidates for this on x86).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 12:59:15 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 12:59:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXY83-0005Ei-Ri; Mon, 05 Dec 2011 12:58:43 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RXY81-0005Ed-Lk
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 12:58:41 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1323089860!50917299!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4OTE=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32337 invoked from network); 5 Dec 2011 12:57:40 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-13.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 5 Dec 2011 12:57:40 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 05 Dec 2011 12:58:01 +0000
Message-Id: <4EDCCDE802000078000656A1@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 05 Dec 2011 12:58:00 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>
References: <4EDCAC68.8060303@citrix.com>
In-Reply-To: <4EDCAC68.8060303@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] KEXEC: fix kexec_get_range_compat to fail vocally
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 05.12.11 at 12:35, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
> I am not sure that this is the only instance, but it is really not
> acceptable to hand truncated pointers or sizes for physical memory to dom0.

While I agree to the change, I think we also ought to add a new flavor
of KEXEC_CMD_kexec_get_range that is 64-bit capable even for a
32-bit Dom0.

Both under the assumption that apart from the truncation nothing
prevents addresses above the 4G boundary from being usable with
a 32-bit kernel for at least one of the ranges (probably only
KEXEC_RANGE_MA_CPU and KEXEC_RANGE_MA_VMCOREINFO are
candidates for this on x86).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 13:02:59 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 13:02:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXYBc-0005O4-GH; Mon, 05 Dec 2011 13:02:24 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1RXYBa-0005No-Ea
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 13:02:22 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1323090096!7550154!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDY0NzA=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2718 invoked from network); 5 Dec 2011 13:01:37 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Dec 2011 13:01:37 -0000
X-IronPort-AV: E=Sophos;i="4.71,299,1320642000"; d="scan'208";a="19660106"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Dec 2011 08:01:35 -0500
Received: from [10.80.2.18] (10.80.2.18) by FTLPMAILMX02.citrite.net
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Mon, 5 Dec 2011
	08:01:35 -0500
Message-ID: <4EDCC0AE.1030100@citrix.com>
Date: Mon, 5 Dec 2011 13:01:34 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.23) Gecko/20110921 Lightning/1.0b2 Thunderbird/3.1.15
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <4EDCAC68.8060303@citrix.com>
	<4EDCCDE802000078000656A1@nat28.tlf.novell.com>
In-Reply-To: <4EDCCDE802000078000656A1@nat28.tlf.novell.com>
X-Enigmail-Version: 1.1.2
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] KEXEC: fix kexec_get_range_compat to fail vocally
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 05/12/11 12:58, Jan Beulich wrote:
>>>> On 05.12.11 at 12:35, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>> I am not sure that this is the only instance, but it is really not
>> acceptable to hand truncated pointers or sizes for physical memory to dom0.
> While I agree to the change, I think we also ought to add a new flavor
> of KEXEC_CMD_kexec_get_range that is 64-bit capable even for a
> 32-bit Dom0.

Agreed - I am working on introducing a new hypercall right now.

> Both under the assumption that apart from the truncation nothing
> prevents addresses above the 4G boundary from being usable with
> a 32-bit kernel for at least one of the ranges (probably only
> KEXEC_RANGE_MA_CPU and KEXEC_RANGE_MA_VMCOREINFO are
> candidates for this on x86).

Will those ranges not be covered by my patch?

> Jan
>

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 13:02:59 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 13:02:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXYBc-0005O4-GH; Mon, 05 Dec 2011 13:02:24 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1RXYBa-0005No-Ea
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 13:02:22 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1323090096!7550154!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDY0NzA=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2718 invoked from network); 5 Dec 2011 13:01:37 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Dec 2011 13:01:37 -0000
X-IronPort-AV: E=Sophos;i="4.71,299,1320642000"; d="scan'208";a="19660106"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Dec 2011 08:01:35 -0500
Received: from [10.80.2.18] (10.80.2.18) by FTLPMAILMX02.citrite.net
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Mon, 5 Dec 2011
	08:01:35 -0500
Message-ID: <4EDCC0AE.1030100@citrix.com>
Date: Mon, 5 Dec 2011 13:01:34 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.23) Gecko/20110921 Lightning/1.0b2 Thunderbird/3.1.15
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <4EDCAC68.8060303@citrix.com>
	<4EDCCDE802000078000656A1@nat28.tlf.novell.com>
In-Reply-To: <4EDCCDE802000078000656A1@nat28.tlf.novell.com>
X-Enigmail-Version: 1.1.2
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] KEXEC: fix kexec_get_range_compat to fail vocally
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 05/12/11 12:58, Jan Beulich wrote:
>>>> On 05.12.11 at 12:35, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>> I am not sure that this is the only instance, but it is really not
>> acceptable to hand truncated pointers or sizes for physical memory to dom0.
> While I agree to the change, I think we also ought to add a new flavor
> of KEXEC_CMD_kexec_get_range that is 64-bit capable even for a
> 32-bit Dom0.

Agreed - I am working on introducing a new hypercall right now.

> Both under the assumption that apart from the truncation nothing
> prevents addresses above the 4G boundary from being usable with
> a 32-bit kernel for at least one of the ranges (probably only
> KEXEC_RANGE_MA_CPU and KEXEC_RANGE_MA_VMCOREINFO are
> candidates for this on x86).

Will those ranges not be covered by my patch?

> Jan
>

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 13:11:05 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 13:11:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXYJb-0005bN-Fa; Mon, 05 Dec 2011 13:10:39 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1RXYJa-0005bI-4U
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 13:10:38 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1323090591!5923469!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMjkyOTA3\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28902 invoked from network); 5 Dec 2011 13:09:52 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-10.tower-182.messagelabs.com with SMTP;
	5 Dec 2011 13:09:52 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga101.jf.intel.com with ESMTP; 05 Dec 2011 05:09:51 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.67,351,1309762800"; d="scan'208";a="83530244"
Received: from pgsmsx603.gar.corp.intel.com ([10.221.43.87])
	by orsmga002.jf.intel.com with ESMTP; 05 Dec 2011 05:09:50 -0800
Received: from pgsmsx102.gar.corp.intel.com (10.221.44.80) by
	pgsmsx603.gar.corp.intel.com (10.221.43.87) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Mon, 5 Dec 2011 21:09:48 +0800
Received: from shsmsx602.ccr.corp.intel.com (10.239.4.104) by
	PGSMSX102.gar.corp.intel.com (10.221.44.80) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Mon, 5 Dec 2011 21:09:47 +0800
Received: from shsmsx502.ccr.corp.intel.com ([10.239.4.96]) by
	SHSMSX602.ccr.corp.intel.com ([10.239.4.104]) with mapi; Mon, 5 Dec 2011
	21:09:45 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: "jbeulich@suse.com" <jbeulich@suse.com>
Date: Mon, 5 Dec 2011 21:09:43 +0800
Thread-Topic: [Xen-devel] [PATCH] X86 MCE: Add more strict sanity check of
	one	SRAR case
Thread-Index: AcyxCrgiOHzcBq2lS5+rjRWdHHGmkQCQvVqA
Message-ID: <BC00F5384FCFC9499AF06F92E8B78A9E2870CA7A13@shsmsx502.ccr.corp.intel.com>
References: <BC00F5384FCFC9499AF06F92E8B78A9E2870BB484D@shsmsx502.ccr.corp.intel.com>
In-Reply-To: <BC00F5384FCFC9499AF06F92E8B78A9E2870BB484D@shsmsx502.ccr.corp.intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/mixed;
	boundary="_004_BC00F5384FCFC9499AF06F92E8B78A9E2870CA7A13shsmsx502ccrc_"
MIME-Version: 1.0
Cc: "keir.xen@gmail.com" <keir.xen@gmail.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Jiang, Yunhong" <yunhong.jiang@intel.com>
Subject: Re: [Xen-devel] [PATCH] X86 MCE: Add more strict sanity check of
 one	SRAR case
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--_004_BC00F5384FCFC9499AF06F92E8B78A9E2870CA7A13shsmsx502ccrc_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Jan,

Attached is the email we discuss last month, and 2 mce patches:
srar-1.patch is the patch we discussed before,
srar-guest-mode.patch is an additional patch w/ more strict sanity checkof =
RIPV =3D EIPV =3D 0.
Any comments please let me know.

Thanks,
Jinsong

________________________________

From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-bounces@lists=
.xensource.com] On Behalf Of Liu, Jinsong
Sent: Friday, December 02, 2011 11:55 PM
To: jbeulich@suse.com
Cc: keir.xen@gmail.com; xen-devel@lists.xensource.com; Jiang, Yunhong
Subject: [Xen-devel] [PATCH] X86 MCE: Add more strict sanity check of one S=
RAR case


Jan,
=20
I cannot access my remote office desktop today (network maintain), so canno=
t reply the SRAR patch email we discussed last month.
=20
At the last email we basically agree that the SRAR patch itself looks fine,=
 only with 1 concern about 'guest_mode' (in fact the SRAR patch itself didn=
't involved guest_mode), and the SRAR patch not in xen unstable tree yet.
Currently I still don't find out an alternative way to solve the guest_mode=
 issue, so in order to be safe I add this patch.
I think although it may be some overkilled, it's OK to keep it safe here, a=
fter all the SRAR case which RIPV =3D EIPV =3D 0 occur rarely.
=20
Thanks,
Jinsong
=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=20
X86 MCE: Add more strict sanity check of one SRAR case
=20
When RIPV =3D EIPV =3D 0, it's a little bit tricky. It may be an asynchroni=
c error, currently we have no way to precisely locate whether the error occ=
ur at guest or hypervisor.
To avoid handling error in wrong way, we treat it as unrecovered.
=20
Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
=20
# HG changeset patch
# Parent e758b1d928e3d663602741ddc7f55461e2187829
=20
diff -r e758b1d928e3 xen/arch/x86/cpu/mcheck/mce_intel.c
--- a/xen/arch/x86/cpu/mcheck/mce_intel.c       Sun Oct 30 17:50:53 2011 -0=
800
+++ b/xen/arch/x86/cpu/mcheck/mce_intel.c       Fri Dec 02 15:16:52 2011 -0=
800
@@ -367,8 +367,18 @@
         return 0;
=20
     gstatus =3D mca_rdmsr(MSR_IA32_MCG_STATUS);
-    /* Xen is not pre-emptible */
-    if ( !(gstatus & MCG_STATUS_RIPV) && !guest_mode(regs))
+
+    /*
+     * FIXME: When RIPV =3D EIPV =3D 0, it's a little bit tricky. It may b=
e an
+     * asynchronic error, currently we have no way to precisely locate
+     * whether the error occur at guest or hypervisor.
+     * To avoid handling error in wrong way, we treat it as unrecovered.
+     *
+     * Another unrecovered case is RIPV =3D 0 while in hypervisor
+     * since Xen is not pre-emptible.
+     */
+    if ( !(gstatus & MCG_STATUS_RIPV) &&
+        (!(gstatus & MCG_STATUS_EIPV) || !guest_mode(regs)) )
         return -1;
=20
     return mce_action(regs, mctc) =3D=3D MCER_RESET ? -1 : 0;

--_004_BC00F5384FCFC9499AF06F92E8B78A9E2870CA7A13shsmsx502ccrc_
Content-Type: message/rfc822

Received: from rrsmsx603.amr.corp.intel.com (10.31.0.57) by
 SHSMSX602.ccr.corp.intel.com (10.239.4.104) with Microsoft SMTP Server (TLS)
 id 8.2.255.0; Wed, 2 Nov 2011 17:57:43 +0800
Received: from azsmga001.ch.intel.com (10.2.17.19) by rrmsx603-1.rr.intel.com
 (10.31.0.57) with Microsoft SMTP Server id 8.2.255.0; Wed, 2 Nov 2011
 03:57:41 -0600
Received: from azsmga102.ch.intel.com ([10.2.16.52])  by
 azsmga001-1.ch.intel.com with ESMTP; 02 Nov 2011 02:57:41 -0700
Received: from nat28.tlf.novell.com ([130.57.49.28])  by mga14.intel.com with
 ESMTP; 02 Nov 2011 02:57:39 -0700
Received: from EMEA1-MTA by nat28.tlf.novell.com	with Novell_GroupWise; Wed,
 02 Nov 2011 09:57:37 +0000
From: Jan Beulich <JBeulich@suse.com>
To: "Liu, Jinsong" <jinsong.liu@intel.com>
CC: "tim.deegan@citrix.com" <tim.deegan@citrix.com>, "keir.xen@gmail.com"
	<keir.xen@gmail.com>, "Shan, Haitao" <haitao.shan@intel.com>, "Jiang,
 Yunhong" <yunhong.jiang@intel.com>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>
Date: Wed, 2 Nov 2011 17:57:35 +0800
Subject: Re: [PATCH] X86 MCE: Add SRAR handler
Thread-Topic: [PATCH] X86 MCE: Add SRAR handler
Thread-Index: AcyZRd2aeVDAGxj0SBmEkzjrHvmBIw==
Message-ID: <4EB1221F020000780005E635@nat28.tlf.novell.com>
References: <BC00F5384FCFC9499AF06F92E8B78A9E26A4F3C1DA@shsmsx502.ccr.corp.intel.com>
In-Reply-To: <BC00F5384FCFC9499AF06F92E8B78A9E26A4F3C1DA@shsmsx502.ccr.corp.intel.com>
X-MS-Exchange-Organization-AuthAs: Anonymous
X-MS-Exchange-Organization-AuthSource: rrsmsx603.amr.corp.intel.com
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ironport-av: E=Sophos;i="4.69,443,1315206000";
    d="scan'208";a="769935611"
x-ironport-anti-spam-filtered: true
x-ironport-anti-spam-result: AkcBANkPsU6COTEcmWdsb2JhbAAtFqlIIgEBAQEBCAsLBxQlgXIBAQQBJxM/BQsLGBMJElcGE4gCtSSFWIJXYQSUFJFl
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

>>> On 21.10.11 at 22:25, "Liu, Jinsong" <jinsong.liu@intel.com> wrote:
> I update a little for my former patch, as attached.
> For my former patch, you mainly have 2 concerns (list below). I double ch=
eck=20
> xen mce code, w/ my opinion append:

Those concerns were really just triggered by the patch, not directly
related to it. The patch itself looks okay to me.

> Concern 1: for SRAR IFU error, since RIPV=3DEIPV=3D0, it maybe an async e=
rror=20
> which occur at guest but root from hypervisor.
> [Jinsong]:=20
>     Yes, but EIPV didn't tell us where the error root from (it's just a=20
> hint, warning us async possibility).=20
>     It no need to overkill xen at mce isr, instead, at mce softirq we can=
=20
> find out error root location and then handle accordingly:
>     * at mce isr:
>             /* a total insurance */
>             /* if error is async, we delay handle it at mce softirq */
>             if ( !(gstatus & MCG_STATUS_RIPV) && !guest_mode(regs))
>                 return -1;

I continue to think that guest_mode() must not be used without
EIPV, no matter what the purpose of the use.

>     * at mce softirq:
>             /* detect error location by bank->mc_addr */
>             /* handle different page OWNER cases at intel_memerr_dhandler=
()=20
> and offline_page() */
>             /* who own, who take */
>             if (error page owner is guest)
>                 trigger vmce to guest;
>             else
>                 panic xen;

That part is certainly fine.

> Concern 2: If a guest accesses the hypervisor part of the GDT or page=20
> tables, or some other shared data structure owned by the hypervisor (like=
 the=20
> M2P table), its handler may get utterly confused by being presented an=20
> address it doesn't own and knows nothing about.
> [Jinsong]: for such cases, page owner would be dom_xen/dom_cow or NULL, b=
ut=20
> not guest --> it would be handled at hypervisor, not triggering vmce to g=
uest -->=20
> who own, who take.

That latter part of your explanation is fine too, but with the caveat that
the bogus use of guest_mode() above may have an overall effect on the
behavior.

Jan


--_004_BC00F5384FCFC9499AF06F92E8B78A9E2870CA7A13shsmsx502ccrc_
Content-Type: application/octet-stream; name="srar-1.patch"
Content-Description: srar-1.patch
Content-Disposition: attachment; filename="srar-1.patch"; size=5680;
	creation-date="Sat, 03 Dec 2011 16:02:18 GMT";
	modification-date="Sat, 22 Oct 2011 01:40:42 GMT"
Content-Transfer-Encoding: base64

WDg2IE1DRTogQWRkIFNSQVIgaGFuZGxlcgoKQ3VycmVudGx5IEludGVsIFNETSBhZGQgMiBraW5k
cyBvZiBNQ0UgU1JBUiBlcnJvcnM6CjEpLiBEYXRhIExvYWQgZXJyb3IsIGVycm9yIGNvZGUgPSAw
eDEzNAoyKS4gSW5zdHJ1Y3Rpb24gRmV0Y2ggZXJyb3IsIGVycm9yIGNvZGUgPSAweDE1MApUaGlz
IHBhdGNoIGFkZCBoYW5kbGVyIHRvIHRoZXNlIG5ldyBTUkFSIGVycm9ycy4KSXQgYmFzZWQgb24g
ZXhpc3RlZCBtY2UgaW5mcmFzdHJ1Y3R1cmUsIGFkZCBjb2RlIHRvIGhhbmRsZSBTUkFSIHNwZWNp
ZmljIGVycm9yLgoKU2lnbmVkLW9mZi1ieTogTGl1LCBKaW5zb25nIDxqaW5zb25nLmxpdUBpbnRl
bC5jb20+CgpkaWZmIC1yIDE1MTU0ODQzNTNjNiB4ZW4vYXJjaC94ODYvY3B1L21jaGVjay9tY2Vf
aW50ZWwuYwotLS0gYS94ZW4vYXJjaC94ODYvY3B1L21jaGVjay9tY2VfaW50ZWwuYwlUaHUgT2N0
IDEzIDEwOjA5OjI4IDIwMTEgKzAyMDAKKysrIGIveGVuL2FyY2gveDg2L2NwdS9tY2hlY2svbWNl
X2ludGVsLmMJU2F0IE9jdCAyMiAwMTo0MDo0MSAyMDExICswODAwCkBAIC0zNyw2ICszNywxNCBA
QCBzdGF0aWMgaW50IF9fcmVhZF9tb3N0bHkgbnJfaW50ZWxfZXh0X21zCiAgKi8KICNkZWZpbmUg
SU5URUxfU1JBT19NRU1fU0NSVUIgMHhDMCAuLi4gMHhDRgogI2RlZmluZSBJTlRFTF9TUkFPX0wz
X0VXQiAgICAweDE3QQorCisvKiAKKyAqIEN1cnJlbnRseSBJbnRlbCBTRE0gZGVmaW5lIDIga2lu
ZHMgb2Ygc3JhciBlcnJvcnM6CisgKiAxKS4gRGF0YSBMb2FkIGVycm9yLCBlcnJvciBjb2RlID0g
MHgxMzQKKyAqIDIpLiBJbnN0cnVjdGlvbiBGZXRjaCBlcnJvciwgZXJyb3IgY29kZSA9IDB4MTUw
CisgKi8KKyNkZWZpbmUgSU5URUxfU1JBUl9EQVRBX0xPQUQJMHgxMzQKKyNkZWZpbmUgSU5URUxf
U1JBUl9JTlNUUl9GRVRDSAkweDE1MAogCiAvKiBUaGVybWFsIEhhbmxkaW5nICovCiAjaWZkZWYg
Q09ORklHX1g4Nl9NQ0VfVEhFUk1BTApAQCAtMjU2LDcgKzI2NCw3IEBAIHN0YXRpYyBlbnVtIG1j
ZV9yZXN1bHQgbWNlX2FjdGlvbihzdHJ1Y3QKICAgICAgICAgZm9yICggaSA9IDA7IGkgPCBoYW5k
bGVyX251bTsgaSsrICkgewogICAgICAgICAgICAgaWYgKGhhbmRsZXJzW2ldLm93bmVkX2Vycm9y
KGJpbmZvLm1pYi0+bWNfc3RhdHVzKSkKICAgICAgICAgICAgIHsKLSAgICAgICAgICAgICAgICBo
YW5kbGVyc1tpXS5yZWNvdmVyeV9oYW5kbGVyKCZiaW5mbywgJmJhbmtfcmVzdWx0KTsKKyAgICAg
ICAgICAgICAgICBoYW5kbGVyc1tpXS5yZWNvdmVyeV9oYW5kbGVyKCZiaW5mbywgJmJhbmtfcmVz
dWx0LCByZWdzKTsKICAgICAgICAgICAgICAgICBpZiAod29yc3RfcmVzdWx0IDwgYmFua19yZXN1
bHQpCiAgICAgICAgICAgICAgICAgICAgIHdvcnN0X3Jlc3VsdCA9IGJhbmtfcmVzdWx0OwogICAg
ICAgICAgICAgICAgIGJyZWFrOwpAQCAtNjIyLDcgKzYzMCw4IEBAIHN0cnVjdCBtY2luZm9fcmVj
b3ZlcnkgKm1jaV9hZGRfcGFnZW9mZl8KIAogc3RhdGljIHZvaWQgaW50ZWxfbWVtZXJyX2RoYW5k
bGVyKAogICAgICAgICAgICAgIHN0cnVjdCBtY2FfYmluZm8gKmJpbmZvLAotICAgICAgICAgICAg
IGVudW0gbWNlX3Jlc3VsdCAqcmVzdWx0KQorICAgICAgICAgICAgIGVudW0gbWNlX3Jlc3VsdCAq
cmVzdWx0LAorICAgICAgICAgICAgIHN0cnVjdCBjcHVfdXNlcl9yZWdzICpyZWdzKQogewogICAg
IHN0cnVjdCBtY2luZm9fYmFuayAqYmFuayA9IGJpbmZvLT5taWI7CiAgICAgc3RydWN0IG1jaW5m
b19nbG9iYWwgKmdsb2JhbCA9IGJpbmZvLT5taWc7CkBAIC03MjEsNiArNzMwLDMyIEBAIHZtY2Vf
ZmFpbGVkOgogICAgIH0KIH0KIAorc3RhdGljIGludCBpbnRlbF9zcmFyX2NoZWNrKHVpbnQ2NF90
IHN0YXR1cykKK3sKKyAgICByZXR1cm4gKCBpbnRlbF9jaGVja19tY2VfdHlwZShzdGF0dXMpID09
IGludGVsX21jZV91Y3Jfc3JhciApOworfQorCitzdGF0aWMgdm9pZCBpbnRlbF9zcmFyX2RoYW5k
bGVyKAorICAgICAgICAgICAgIHN0cnVjdCBtY2FfYmluZm8gKmJpbmZvLAorICAgICAgICAgICAg
IGVudW0gbWNlX3Jlc3VsdCAqcmVzdWx0LAorICAgICAgICAgICAgIHN0cnVjdCBjcHVfdXNlcl9y
ZWdzICpyZWdzKQoreworICAgIHVpbnQ2NF90IHN0YXR1cyA9IGJpbmZvLT5taWItPm1jX3N0YXR1
czsKKworICAgIC8qIEZvciB1bmtub3duIHNyYXIgZXJyb3IgY29kZSwgcmVzZXQgc3lzdGVtICov
CisgICAgKnJlc3VsdCA9IE1DRVJfUkVTRVQ7CisKKyAgICBzd2l0Y2ggKCBzdGF0dXMgJiBJTlRF
TF9NQ0NPRF9NQVNLICkKKyAgICB7CisgICAgY2FzZSBJTlRFTF9TUkFSX0RBVEFfTE9BRDoKKyAg
ICBjYXNlIElOVEVMX1NSQVJfSU5TVFJfRkVUQ0g6CisgICAgICAgIGludGVsX21lbWVycl9kaGFu
ZGxlcihiaW5mbywgcmVzdWx0LCByZWdzKTsKKyAgICAgICAgYnJlYWs7CisgICAgZGVmYXVsdDoK
KyAgICAgICAgYnJlYWs7CisgICAgfQorfQorCiBzdGF0aWMgaW50IGludGVsX3NyYW9fY2hlY2so
dWludDY0X3Qgc3RhdHVzKQogewogICAgIHJldHVybiAoIGludGVsX2NoZWNrX21jZV90eXBlKHN0
YXR1cykgPT0gaW50ZWxfbWNlX3Vjcl9zcmFvICk7CkBAIC03MjgsNyArNzYzLDggQEAgc3RhdGlj
IGludCBpbnRlbF9zcmFvX2NoZWNrKHVpbnQ2NF90IHN0YQogCiBzdGF0aWMgdm9pZCBpbnRlbF9z
cmFvX2RoYW5kbGVyKAogICAgICAgICAgICAgIHN0cnVjdCBtY2FfYmluZm8gKmJpbmZvLAotICAg
ICAgICAgICAgIGVudW0gbWNlX3Jlc3VsdCAqcmVzdWx0KQorICAgICAgICAgICAgIGVudW0gbWNl
X3Jlc3VsdCAqcmVzdWx0LAorICAgICAgICAgICAgIHN0cnVjdCBjcHVfdXNlcl9yZWdzICpyZWdz
KQogewogICAgIHVpbnQ2NF90IHN0YXR1cyA9IGJpbmZvLT5taWItPm1jX3N0YXR1czsKIApAQCAt
NzQxLDcgKzc3Nyw3IEBAIHN0YXRpYyB2b2lkIGludGVsX3NyYW9fZGhhbmRsZXIoCiAgICAgICAg
IHsKICAgICAgICAgY2FzZSBJTlRFTF9TUkFPX01FTV9TQ1JVQjoKICAgICAgICAgY2FzZSBJTlRF
TF9TUkFPX0wzX0VXQjoKLSAgICAgICAgICAgIGludGVsX21lbWVycl9kaGFuZGxlcihiaW5mbywg
cmVzdWx0KTsKKyAgICAgICAgICAgIGludGVsX21lbWVycl9kaGFuZGxlcihiaW5mbywgcmVzdWx0
LCByZWdzKTsKICAgICAgICAgICAgIGJyZWFrOwogICAgICAgICBkZWZhdWx0OgogICAgICAgICAg
ICAgYnJlYWs7CkBAIC03NTYsMTQgKzc5MiwxNSBAQCBzdGF0aWMgaW50IGludGVsX2RlZmF1bHRf
Y2hlY2sodWludDY0X3QgCiAKIHN0YXRpYyB2b2lkIGludGVsX2RlZmF1bHRfbWNlX2RoYW5kbGVy
KAogICAgICAgICAgICAgIHN0cnVjdCBtY2FfYmluZm8gKmJpbmZvLAotICAgICAgICAgICAgIGVu
dW0gbWNlX3Jlc3VsdCAqcmVzdWx0KQorICAgICAgICAgICAgIGVudW0gbWNlX3Jlc3VsdCAqcmVz
dWx0LAorICAgICAgICAgICAgIHN0cnVjdCBjcHVfdXNlcl9yZWdzICogcmVncykKIHsKICAgICB1
aW50NjRfdCBzdGF0dXMgPSBiaW5mby0+bWliLT5tY19zdGF0dXM7CiAgICAgZW51bSBpbnRlbF9t
Y2VfdHlwZSB0eXBlOwogCiAgICAgdHlwZSA9IGludGVsX2NoZWNrX21jZV90eXBlKHN0YXR1cyk7
CiAKLSAgICBpZiAodHlwZSA9PSBpbnRlbF9tY2VfZmF0YWwgfHwgdHlwZSA9PSBpbnRlbF9tY2Vf
dWNyX3NyYXIpCisgICAgaWYgKHR5cGUgPT0gaW50ZWxfbWNlX2ZhdGFsKQogICAgICAgICAqcmVz
dWx0ID0gTUNFUl9SRVNFVDsKICAgICBlbHNlCiAgICAgICAgICpyZXN1bHQgPSBNQ0VSX0NPTlRJ
TlVFOwpAQCAtNzcxLDEyICs4MDgsMTQgQEAgc3RhdGljIHZvaWQgaW50ZWxfZGVmYXVsdF9tY2Vf
ZGhhbmRsZXIoCiAKIHN0YXRpYyBjb25zdCBzdHJ1Y3QgbWNhX2Vycm9yX2hhbmRsZXIgaW50ZWxf
bWNlX2RoYW5kbGVyc1tdID0gewogICAgIHtpbnRlbF9zcmFvX2NoZWNrLCBpbnRlbF9zcmFvX2Ro
YW5kbGVyfSwKKyAgICB7aW50ZWxfc3Jhcl9jaGVjaywgaW50ZWxfc3Jhcl9kaGFuZGxlcn0sCiAg
ICAge2ludGVsX2RlZmF1bHRfY2hlY2ssIGludGVsX2RlZmF1bHRfbWNlX2RoYW5kbGVyfQogfTsK
IAogc3RhdGljIHZvaWQgaW50ZWxfZGVmYXVsdF9tY2VfdWhhbmRsZXIoCiAgICAgICAgICAgICAg
c3RydWN0IG1jYV9iaW5mbyAqYmluZm8sCi0gICAgICAgICAgICAgZW51bSBtY2VfcmVzdWx0ICpy
ZXN1bHQpCisgICAgICAgICAgICAgZW51bSBtY2VfcmVzdWx0ICpyZXN1bHQsCisgICAgICAgICAg
ICAgc3RydWN0IGNwdV91c2VyX3JlZ3MgKnJlZ3MpCiB7CiAgICAgdWludDY0X3Qgc3RhdHVzID0g
YmluZm8tPm1pYi0+bWNfc3RhdHVzOwogICAgIGVudW0gaW50ZWxfbWNlX3R5cGUgdHlwZTsKQEAg
LTc4NSw4ICs4MjQsNiBAQCBzdGF0aWMgdm9pZCBpbnRlbF9kZWZhdWx0X21jZV91aGFuZGxlcigK
IAogICAgIHN3aXRjaCAodHlwZSkKICAgICB7Ci0gICAgLyogUGFuaWMgaWYgbm8gaGFuZGxlciBm
b3IgU1JBUiBlcnJvciAqLwotICAgIGNhc2UgaW50ZWxfbWNlX3Vjcl9zcmFyOgogICAgIGNhc2Ug
aW50ZWxfbWNlX2ZhdGFsOgogICAgICAgICAqcmVzdWx0ID0gTUNFUl9SRVNFVDsKICAgICAgICAg
YnJlYWs7CkBAIC05NjEsMTAgKzk5OCw4IEBAIHN0YXRpYyBpbnQgaW50ZWxfcmVjb3ZlcmFibGVf
c2Nhbih1NjQgc3QKICAgICAvKiBTUkFSIGVycm9yICovCiAgICAgZWxzZSBpZiAoIHNlcl9zdXBw
b3J0ICYmICEoc3RhdHVzICYgTUNpX1NUQVRVU19PVkVSKSAKICAgICAgICAgICAgICAgICAmJiAh
KHN0YXR1cyAmIE1DaV9TVEFUVVNfUENDKSAmJiAoc3RhdHVzICYgTUNpX1NUQVRVU19TKQotICAg
ICAgICAgICAgICAgICYmIChzdGF0dXMgJiBNQ2lfU1RBVFVTX0FSKSApIHsKLSAgICAgICAgbWNl
X3ByaW50ayhNQ0VfVkVSQk9TRSwgIk1DRTogTm8gU1JBUiBlcnJvciBkZWZpbmVkIGN1cnJlbnRs
eS5cbiIpOwotICAgICAgICByZXR1cm4gMDsKLSAgICB9CisgICAgICAgICAgICAgICAgJiYgKHN0
YXR1cyAmIE1DaV9TVEFUVVNfQVIpICYmIChzdGF0dXMgJiBNQ2lfU1RBVFVTX0VOKSApCisgICAg
ICAgIHJldHVybiAxOwogICAgIC8qIFNSQU8gZXJyb3IgKi8KICAgICBlbHNlIGlmIChzZXJfc3Vw
cG9ydCAmJiAhKHN0YXR1cyAmIE1DaV9TVEFUVVNfUENDKQogICAgICAgICAgICAgICAgICYmIChz
dGF0dXMgJiBNQ2lfU1RBVFVTX1MpICYmICEoc3RhdHVzICYgTUNpX1NUQVRVU19BUikKZGlmZiAt
ciAxNTE1NDg0MzUzYzYgeGVuL2FyY2gveDg2L2NwdS9tY2hlY2sveDg2X21jYS5oCi0tLSBhL3hl
bi9hcmNoL3g4Ni9jcHUvbWNoZWNrL3g4Nl9tY2EuaAlUaHUgT2N0IDEzIDEwOjA5OjI4IDIwMTEg
KzAyMDAKKysrIGIveGVuL2FyY2gveDg2L2NwdS9tY2hlY2sveDg2X21jYS5oCVNhdCBPY3QgMjIg
MDE6NDA6NDEgMjAxMSArMDgwMApAQCAtMTUxLDcgKzE1MSw3IEBAIHN0cnVjdCBtY2FfZXJyb3Jf
aGFuZGxlcgogICAgICovCiAgICAgaW50ICgqb3duZWRfZXJyb3IpKHVpbnQ2NF90IHN0YXR1cyk7
CiAgICAgdm9pZCAoKnJlY292ZXJ5X2hhbmRsZXIpKHN0cnVjdCBtY2FfYmluZm8gKmJpbmZvLAot
ICAgICAgICAgICAgICAgICAgICBlbnVtIG1jZV9yZXN1bHQgKnJlc3VsdCk7CisgICAgICAgICAg
ICAgICAgICAgIGVudW0gbWNlX3Jlc3VsdCAqcmVzdWx0LCBzdHJ1Y3QgY3B1X3VzZXJfcmVncyAq
cmVncyk7CiB9OwogCiAvKiBHbG9iYWwgdmFyaWFibGVzICovCg==

--_004_BC00F5384FCFC9499AF06F92E8B78A9E2870CA7A13shsmsx502ccrc_
Content-Type: application/octet-stream; name="srar-guest-mode.patch"
Content-Description: srar-guest-mode.patch
Content-Disposition: attachment; filename="srar-guest-mode.patch"; size=1448;
	creation-date="Sat, 03 Dec 2011 16:01:36 GMT";
	modification-date="Sat, 03 Dec 2011 07:27:08 GMT"
Content-Transfer-Encoding: base64

WDg2OiBBZGQgbW9yZSBzdHJpY3Qgc2FuaXR5IGNoZWNrIG9mIG9uZSBTUkFSIGNhc2UKCldoZW4g
UklQViA9IEVJUFYgPSAwLCBpdCdzIGEgbGl0dGxlIGJpdCB0cmlja3kuIEl0IG1heSBiZSBhbiBh
c3luY2hyb25pYyBlcnJvciwgY3VycmVudGx5IHdlIGhhdmUgbm8gd2F5IHRvIHByZWNpc2VseSBs
b2NhdGUgd2hldGhlciB0aGUgZXJyb3Igb2NjdXIgYXQgZ3Vlc3Qgb3IgaHlwZXJ2aXNvci4gClRv
IGF2b2lkIGhhbmRsaW5nIGVycm9yIGluIHdyb25nIHdheSwgd2UgdHJlYXQgaXQgYXMgdW5yZWNv
dmVyZWQuCgpTaWduZWQtb2ZmLWJ5OiBMaXUsIEppbnNvbmcgPGppbnNvbmcubGl1QGludGVsLmNv
bT4KU2lnbmVkLW9mZi1ieTogSmFuIEJldWxpY2ggPGpiZXVsaWNoQHN1c2UuY29tPgoKIyBIRyBj
aGFuZ2VzZXQgcGF0Y2gKIyBQYXJlbnQgZTc1OGIxZDkyOGUzZDY2MzYwMjc0MWRkYzdmNTU0NjFl
MjE4NzgyOQoKZGlmZiAtciBlNzU4YjFkOTI4ZTMgeGVuL2FyY2gveDg2L2NwdS9tY2hlY2svbWNl
X2ludGVsLmMKLS0tIGEveGVuL2FyY2gveDg2L2NwdS9tY2hlY2svbWNlX2ludGVsLmMJU3VuIE9j
dCAzMCAxNzo1MDo1MyAyMDExIC0wODAwCisrKyBiL3hlbi9hcmNoL3g4Ni9jcHUvbWNoZWNrL21j
ZV9pbnRlbC5jCUZyaSBEZWMgMDIgMTU6MTY6NTIgMjAxMSAtMDgwMApAQCAtMzY3LDggKzM2Nywx
OCBAQAogICAgICAgICByZXR1cm4gMDsKIAogICAgIGdzdGF0dXMgPSBtY2FfcmRtc3IoTVNSX0lB
MzJfTUNHX1NUQVRVUyk7Ci0gICAgLyogWGVuIGlzIG5vdCBwcmUtZW1wdGlibGUgKi8KLSAgICBp
ZiAoICEoZ3N0YXR1cyAmIE1DR19TVEFUVVNfUklQVikgJiYgIWd1ZXN0X21vZGUocmVncykpCisK
KyAgICAvKgorICAgICAqIEZJWE1FOiBXaGVuIFJJUFYgPSBFSVBWID0gMCwgaXQncyBhIGxpdHRs
ZSBiaXQgdHJpY2t5LiBJdCBtYXkgYmUgYW4KKyAgICAgKiBhc3luY2hyb25pYyBlcnJvciwgY3Vy
cmVudGx5IHdlIGhhdmUgbm8gd2F5IHRvIHByZWNpc2VseSBsb2NhdGUKKyAgICAgKiB3aGV0aGVy
IHRoZSBlcnJvciBvY2N1ciBhdCBndWVzdCBvciBoeXBlcnZpc29yLgorICAgICAqIFRvIGF2b2lk
IGhhbmRsaW5nIGVycm9yIGluIHdyb25nIHdheSwgd2UgdHJlYXQgaXQgYXMgdW5yZWNvdmVyZWQu
CisgICAgICoKKyAgICAgKiBBbm90aGVyIHVucmVjb3ZlcmVkIGNhc2UgaXMgUklQViA9IDAgd2hp
bGUgaW4gaHlwZXJ2aXNvcgorICAgICAqIHNpbmNlIFhlbiBpcyBub3QgcHJlLWVtcHRpYmxlLgor
ICAgICAqLworICAgIGlmICggIShnc3RhdHVzICYgTUNHX1NUQVRVU19SSVBWKSAmJgorICAgICAg
ICAoIShnc3RhdHVzICYgTUNHX1NUQVRVU19FSVBWKSB8fCAhZ3Vlc3RfbW9kZShyZWdzKSkgKQog
ICAgICAgICByZXR1cm4gLTE7CiAKICAgICByZXR1cm4gbWNlX2FjdGlvbihyZWdzLCBtY3RjKSA9
PSBNQ0VSX1JFU0VUID8gLTEgOiAwOwo=

--_004_BC00F5384FCFC9499AF06F92E8B78A9E2870CA7A13shsmsx502ccrc_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--_004_BC00F5384FCFC9499AF06F92E8B78A9E2870CA7A13shsmsx502ccrc_--


From xen-devel-bounces@lists.xensource.com Mon Dec 05 13:11:05 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 13:11:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXYJb-0005bN-Fa; Mon, 05 Dec 2011 13:10:39 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1RXYJa-0005bI-4U
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 13:10:38 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1323090591!5923469!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMjkyOTA3\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28902 invoked from network); 5 Dec 2011 13:09:52 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-10.tower-182.messagelabs.com with SMTP;
	5 Dec 2011 13:09:52 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga101.jf.intel.com with ESMTP; 05 Dec 2011 05:09:51 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.67,351,1309762800"; d="scan'208";a="83530244"
Received: from pgsmsx603.gar.corp.intel.com ([10.221.43.87])
	by orsmga002.jf.intel.com with ESMTP; 05 Dec 2011 05:09:50 -0800
Received: from pgsmsx102.gar.corp.intel.com (10.221.44.80) by
	pgsmsx603.gar.corp.intel.com (10.221.43.87) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Mon, 5 Dec 2011 21:09:48 +0800
Received: from shsmsx602.ccr.corp.intel.com (10.239.4.104) by
	PGSMSX102.gar.corp.intel.com (10.221.44.80) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Mon, 5 Dec 2011 21:09:47 +0800
Received: from shsmsx502.ccr.corp.intel.com ([10.239.4.96]) by
	SHSMSX602.ccr.corp.intel.com ([10.239.4.104]) with mapi; Mon, 5 Dec 2011
	21:09:45 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: "jbeulich@suse.com" <jbeulich@suse.com>
Date: Mon, 5 Dec 2011 21:09:43 +0800
Thread-Topic: [Xen-devel] [PATCH] X86 MCE: Add more strict sanity check of
	one	SRAR case
Thread-Index: AcyxCrgiOHzcBq2lS5+rjRWdHHGmkQCQvVqA
Message-ID: <BC00F5384FCFC9499AF06F92E8B78A9E2870CA7A13@shsmsx502.ccr.corp.intel.com>
References: <BC00F5384FCFC9499AF06F92E8B78A9E2870BB484D@shsmsx502.ccr.corp.intel.com>
In-Reply-To: <BC00F5384FCFC9499AF06F92E8B78A9E2870BB484D@shsmsx502.ccr.corp.intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/mixed;
	boundary="_004_BC00F5384FCFC9499AF06F92E8B78A9E2870CA7A13shsmsx502ccrc_"
MIME-Version: 1.0
Cc: "keir.xen@gmail.com" <keir.xen@gmail.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Jiang, Yunhong" <yunhong.jiang@intel.com>
Subject: Re: [Xen-devel] [PATCH] X86 MCE: Add more strict sanity check of
 one	SRAR case
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--_004_BC00F5384FCFC9499AF06F92E8B78A9E2870CA7A13shsmsx502ccrc_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Jan,

Attached is the email we discuss last month, and 2 mce patches:
srar-1.patch is the patch we discussed before,
srar-guest-mode.patch is an additional patch w/ more strict sanity checkof =
RIPV =3D EIPV =3D 0.
Any comments please let me know.

Thanks,
Jinsong

________________________________

From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-bounces@lists=
.xensource.com] On Behalf Of Liu, Jinsong
Sent: Friday, December 02, 2011 11:55 PM
To: jbeulich@suse.com
Cc: keir.xen@gmail.com; xen-devel@lists.xensource.com; Jiang, Yunhong
Subject: [Xen-devel] [PATCH] X86 MCE: Add more strict sanity check of one S=
RAR case


Jan,
=20
I cannot access my remote office desktop today (network maintain), so canno=
t reply the SRAR patch email we discussed last month.
=20
At the last email we basically agree that the SRAR patch itself looks fine,=
 only with 1 concern about 'guest_mode' (in fact the SRAR patch itself didn=
't involved guest_mode), and the SRAR patch not in xen unstable tree yet.
Currently I still don't find out an alternative way to solve the guest_mode=
 issue, so in order to be safe I add this patch.
I think although it may be some overkilled, it's OK to keep it safe here, a=
fter all the SRAR case which RIPV =3D EIPV =3D 0 occur rarely.
=20
Thanks,
Jinsong
=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=20
X86 MCE: Add more strict sanity check of one SRAR case
=20
When RIPV =3D EIPV =3D 0, it's a little bit tricky. It may be an asynchroni=
c error, currently we have no way to precisely locate whether the error occ=
ur at guest or hypervisor.
To avoid handling error in wrong way, we treat it as unrecovered.
=20
Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
=20
# HG changeset patch
# Parent e758b1d928e3d663602741ddc7f55461e2187829
=20
diff -r e758b1d928e3 xen/arch/x86/cpu/mcheck/mce_intel.c
--- a/xen/arch/x86/cpu/mcheck/mce_intel.c       Sun Oct 30 17:50:53 2011 -0=
800
+++ b/xen/arch/x86/cpu/mcheck/mce_intel.c       Fri Dec 02 15:16:52 2011 -0=
800
@@ -367,8 +367,18 @@
         return 0;
=20
     gstatus =3D mca_rdmsr(MSR_IA32_MCG_STATUS);
-    /* Xen is not pre-emptible */
-    if ( !(gstatus & MCG_STATUS_RIPV) && !guest_mode(regs))
+
+    /*
+     * FIXME: When RIPV =3D EIPV =3D 0, it's a little bit tricky. It may b=
e an
+     * asynchronic error, currently we have no way to precisely locate
+     * whether the error occur at guest or hypervisor.
+     * To avoid handling error in wrong way, we treat it as unrecovered.
+     *
+     * Another unrecovered case is RIPV =3D 0 while in hypervisor
+     * since Xen is not pre-emptible.
+     */
+    if ( !(gstatus & MCG_STATUS_RIPV) &&
+        (!(gstatus & MCG_STATUS_EIPV) || !guest_mode(regs)) )
         return -1;
=20
     return mce_action(regs, mctc) =3D=3D MCER_RESET ? -1 : 0;

--_004_BC00F5384FCFC9499AF06F92E8B78A9E2870CA7A13shsmsx502ccrc_
Content-Type: message/rfc822

Received: from rrsmsx603.amr.corp.intel.com (10.31.0.57) by
 SHSMSX602.ccr.corp.intel.com (10.239.4.104) with Microsoft SMTP Server (TLS)
 id 8.2.255.0; Wed, 2 Nov 2011 17:57:43 +0800
Received: from azsmga001.ch.intel.com (10.2.17.19) by rrmsx603-1.rr.intel.com
 (10.31.0.57) with Microsoft SMTP Server id 8.2.255.0; Wed, 2 Nov 2011
 03:57:41 -0600
Received: from azsmga102.ch.intel.com ([10.2.16.52])  by
 azsmga001-1.ch.intel.com with ESMTP; 02 Nov 2011 02:57:41 -0700
Received: from nat28.tlf.novell.com ([130.57.49.28])  by mga14.intel.com with
 ESMTP; 02 Nov 2011 02:57:39 -0700
Received: from EMEA1-MTA by nat28.tlf.novell.com	with Novell_GroupWise; Wed,
 02 Nov 2011 09:57:37 +0000
From: Jan Beulich <JBeulich@suse.com>
To: "Liu, Jinsong" <jinsong.liu@intel.com>
CC: "tim.deegan@citrix.com" <tim.deegan@citrix.com>, "keir.xen@gmail.com"
	<keir.xen@gmail.com>, "Shan, Haitao" <haitao.shan@intel.com>, "Jiang,
 Yunhong" <yunhong.jiang@intel.com>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>
Date: Wed, 2 Nov 2011 17:57:35 +0800
Subject: Re: [PATCH] X86 MCE: Add SRAR handler
Thread-Topic: [PATCH] X86 MCE: Add SRAR handler
Thread-Index: AcyZRd2aeVDAGxj0SBmEkzjrHvmBIw==
Message-ID: <4EB1221F020000780005E635@nat28.tlf.novell.com>
References: <BC00F5384FCFC9499AF06F92E8B78A9E26A4F3C1DA@shsmsx502.ccr.corp.intel.com>
In-Reply-To: <BC00F5384FCFC9499AF06F92E8B78A9E26A4F3C1DA@shsmsx502.ccr.corp.intel.com>
X-MS-Exchange-Organization-AuthAs: Anonymous
X-MS-Exchange-Organization-AuthSource: rrsmsx603.amr.corp.intel.com
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ironport-av: E=Sophos;i="4.69,443,1315206000";
    d="scan'208";a="769935611"
x-ironport-anti-spam-filtered: true
x-ironport-anti-spam-result: AkcBANkPsU6COTEcmWdsb2JhbAAtFqlIIgEBAQEBCAsLBxQlgXIBAQQBJxM/BQsLGBMJElcGE4gCtSSFWIJXYQSUFJFl
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

>>> On 21.10.11 at 22:25, "Liu, Jinsong" <jinsong.liu@intel.com> wrote:
> I update a little for my former patch, as attached.
> For my former patch, you mainly have 2 concerns (list below). I double ch=
eck=20
> xen mce code, w/ my opinion append:

Those concerns were really just triggered by the patch, not directly
related to it. The patch itself looks okay to me.

> Concern 1: for SRAR IFU error, since RIPV=3DEIPV=3D0, it maybe an async e=
rror=20
> which occur at guest but root from hypervisor.
> [Jinsong]:=20
>     Yes, but EIPV didn't tell us where the error root from (it's just a=20
> hint, warning us async possibility).=20
>     It no need to overkill xen at mce isr, instead, at mce softirq we can=
=20
> find out error root location and then handle accordingly:
>     * at mce isr:
>             /* a total insurance */
>             /* if error is async, we delay handle it at mce softirq */
>             if ( !(gstatus & MCG_STATUS_RIPV) && !guest_mode(regs))
>                 return -1;

I continue to think that guest_mode() must not be used without
EIPV, no matter what the purpose of the use.

>     * at mce softirq:
>             /* detect error location by bank->mc_addr */
>             /* handle different page OWNER cases at intel_memerr_dhandler=
()=20
> and offline_page() */
>             /* who own, who take */
>             if (error page owner is guest)
>                 trigger vmce to guest;
>             else
>                 panic xen;

That part is certainly fine.

> Concern 2: If a guest accesses the hypervisor part of the GDT or page=20
> tables, or some other shared data structure owned by the hypervisor (like=
 the=20
> M2P table), its handler may get utterly confused by being presented an=20
> address it doesn't own and knows nothing about.
> [Jinsong]: for such cases, page owner would be dom_xen/dom_cow or NULL, b=
ut=20
> not guest --> it would be handled at hypervisor, not triggering vmce to g=
uest -->=20
> who own, who take.

That latter part of your explanation is fine too, but with the caveat that
the bogus use of guest_mode() above may have an overall effect on the
behavior.

Jan


--_004_BC00F5384FCFC9499AF06F92E8B78A9E2870CA7A13shsmsx502ccrc_
Content-Type: application/octet-stream; name="srar-1.patch"
Content-Description: srar-1.patch
Content-Disposition: attachment; filename="srar-1.patch"; size=5680;
	creation-date="Sat, 03 Dec 2011 16:02:18 GMT";
	modification-date="Sat, 22 Oct 2011 01:40:42 GMT"
Content-Transfer-Encoding: base64

WDg2IE1DRTogQWRkIFNSQVIgaGFuZGxlcgoKQ3VycmVudGx5IEludGVsIFNETSBhZGQgMiBraW5k
cyBvZiBNQ0UgU1JBUiBlcnJvcnM6CjEpLiBEYXRhIExvYWQgZXJyb3IsIGVycm9yIGNvZGUgPSAw
eDEzNAoyKS4gSW5zdHJ1Y3Rpb24gRmV0Y2ggZXJyb3IsIGVycm9yIGNvZGUgPSAweDE1MApUaGlz
IHBhdGNoIGFkZCBoYW5kbGVyIHRvIHRoZXNlIG5ldyBTUkFSIGVycm9ycy4KSXQgYmFzZWQgb24g
ZXhpc3RlZCBtY2UgaW5mcmFzdHJ1Y3R1cmUsIGFkZCBjb2RlIHRvIGhhbmRsZSBTUkFSIHNwZWNp
ZmljIGVycm9yLgoKU2lnbmVkLW9mZi1ieTogTGl1LCBKaW5zb25nIDxqaW5zb25nLmxpdUBpbnRl
bC5jb20+CgpkaWZmIC1yIDE1MTU0ODQzNTNjNiB4ZW4vYXJjaC94ODYvY3B1L21jaGVjay9tY2Vf
aW50ZWwuYwotLS0gYS94ZW4vYXJjaC94ODYvY3B1L21jaGVjay9tY2VfaW50ZWwuYwlUaHUgT2N0
IDEzIDEwOjA5OjI4IDIwMTEgKzAyMDAKKysrIGIveGVuL2FyY2gveDg2L2NwdS9tY2hlY2svbWNl
X2ludGVsLmMJU2F0IE9jdCAyMiAwMTo0MDo0MSAyMDExICswODAwCkBAIC0zNyw2ICszNywxNCBA
QCBzdGF0aWMgaW50IF9fcmVhZF9tb3N0bHkgbnJfaW50ZWxfZXh0X21zCiAgKi8KICNkZWZpbmUg
SU5URUxfU1JBT19NRU1fU0NSVUIgMHhDMCAuLi4gMHhDRgogI2RlZmluZSBJTlRFTF9TUkFPX0wz
X0VXQiAgICAweDE3QQorCisvKiAKKyAqIEN1cnJlbnRseSBJbnRlbCBTRE0gZGVmaW5lIDIga2lu
ZHMgb2Ygc3JhciBlcnJvcnM6CisgKiAxKS4gRGF0YSBMb2FkIGVycm9yLCBlcnJvciBjb2RlID0g
MHgxMzQKKyAqIDIpLiBJbnN0cnVjdGlvbiBGZXRjaCBlcnJvciwgZXJyb3IgY29kZSA9IDB4MTUw
CisgKi8KKyNkZWZpbmUgSU5URUxfU1JBUl9EQVRBX0xPQUQJMHgxMzQKKyNkZWZpbmUgSU5URUxf
U1JBUl9JTlNUUl9GRVRDSAkweDE1MAogCiAvKiBUaGVybWFsIEhhbmxkaW5nICovCiAjaWZkZWYg
Q09ORklHX1g4Nl9NQ0VfVEhFUk1BTApAQCAtMjU2LDcgKzI2NCw3IEBAIHN0YXRpYyBlbnVtIG1j
ZV9yZXN1bHQgbWNlX2FjdGlvbihzdHJ1Y3QKICAgICAgICAgZm9yICggaSA9IDA7IGkgPCBoYW5k
bGVyX251bTsgaSsrICkgewogICAgICAgICAgICAgaWYgKGhhbmRsZXJzW2ldLm93bmVkX2Vycm9y
KGJpbmZvLm1pYi0+bWNfc3RhdHVzKSkKICAgICAgICAgICAgIHsKLSAgICAgICAgICAgICAgICBo
YW5kbGVyc1tpXS5yZWNvdmVyeV9oYW5kbGVyKCZiaW5mbywgJmJhbmtfcmVzdWx0KTsKKyAgICAg
ICAgICAgICAgICBoYW5kbGVyc1tpXS5yZWNvdmVyeV9oYW5kbGVyKCZiaW5mbywgJmJhbmtfcmVz
dWx0LCByZWdzKTsKICAgICAgICAgICAgICAgICBpZiAod29yc3RfcmVzdWx0IDwgYmFua19yZXN1
bHQpCiAgICAgICAgICAgICAgICAgICAgIHdvcnN0X3Jlc3VsdCA9IGJhbmtfcmVzdWx0OwogICAg
ICAgICAgICAgICAgIGJyZWFrOwpAQCAtNjIyLDcgKzYzMCw4IEBAIHN0cnVjdCBtY2luZm9fcmVj
b3ZlcnkgKm1jaV9hZGRfcGFnZW9mZl8KIAogc3RhdGljIHZvaWQgaW50ZWxfbWVtZXJyX2RoYW5k
bGVyKAogICAgICAgICAgICAgIHN0cnVjdCBtY2FfYmluZm8gKmJpbmZvLAotICAgICAgICAgICAg
IGVudW0gbWNlX3Jlc3VsdCAqcmVzdWx0KQorICAgICAgICAgICAgIGVudW0gbWNlX3Jlc3VsdCAq
cmVzdWx0LAorICAgICAgICAgICAgIHN0cnVjdCBjcHVfdXNlcl9yZWdzICpyZWdzKQogewogICAg
IHN0cnVjdCBtY2luZm9fYmFuayAqYmFuayA9IGJpbmZvLT5taWI7CiAgICAgc3RydWN0IG1jaW5m
b19nbG9iYWwgKmdsb2JhbCA9IGJpbmZvLT5taWc7CkBAIC03MjEsNiArNzMwLDMyIEBAIHZtY2Vf
ZmFpbGVkOgogICAgIH0KIH0KIAorc3RhdGljIGludCBpbnRlbF9zcmFyX2NoZWNrKHVpbnQ2NF90
IHN0YXR1cykKK3sKKyAgICByZXR1cm4gKCBpbnRlbF9jaGVja19tY2VfdHlwZShzdGF0dXMpID09
IGludGVsX21jZV91Y3Jfc3JhciApOworfQorCitzdGF0aWMgdm9pZCBpbnRlbF9zcmFyX2RoYW5k
bGVyKAorICAgICAgICAgICAgIHN0cnVjdCBtY2FfYmluZm8gKmJpbmZvLAorICAgICAgICAgICAg
IGVudW0gbWNlX3Jlc3VsdCAqcmVzdWx0LAorICAgICAgICAgICAgIHN0cnVjdCBjcHVfdXNlcl9y
ZWdzICpyZWdzKQoreworICAgIHVpbnQ2NF90IHN0YXR1cyA9IGJpbmZvLT5taWItPm1jX3N0YXR1
czsKKworICAgIC8qIEZvciB1bmtub3duIHNyYXIgZXJyb3IgY29kZSwgcmVzZXQgc3lzdGVtICov
CisgICAgKnJlc3VsdCA9IE1DRVJfUkVTRVQ7CisKKyAgICBzd2l0Y2ggKCBzdGF0dXMgJiBJTlRF
TF9NQ0NPRF9NQVNLICkKKyAgICB7CisgICAgY2FzZSBJTlRFTF9TUkFSX0RBVEFfTE9BRDoKKyAg
ICBjYXNlIElOVEVMX1NSQVJfSU5TVFJfRkVUQ0g6CisgICAgICAgIGludGVsX21lbWVycl9kaGFu
ZGxlcihiaW5mbywgcmVzdWx0LCByZWdzKTsKKyAgICAgICAgYnJlYWs7CisgICAgZGVmYXVsdDoK
KyAgICAgICAgYnJlYWs7CisgICAgfQorfQorCiBzdGF0aWMgaW50IGludGVsX3NyYW9fY2hlY2so
dWludDY0X3Qgc3RhdHVzKQogewogICAgIHJldHVybiAoIGludGVsX2NoZWNrX21jZV90eXBlKHN0
YXR1cykgPT0gaW50ZWxfbWNlX3Vjcl9zcmFvICk7CkBAIC03MjgsNyArNzYzLDggQEAgc3RhdGlj
IGludCBpbnRlbF9zcmFvX2NoZWNrKHVpbnQ2NF90IHN0YQogCiBzdGF0aWMgdm9pZCBpbnRlbF9z
cmFvX2RoYW5kbGVyKAogICAgICAgICAgICAgIHN0cnVjdCBtY2FfYmluZm8gKmJpbmZvLAotICAg
ICAgICAgICAgIGVudW0gbWNlX3Jlc3VsdCAqcmVzdWx0KQorICAgICAgICAgICAgIGVudW0gbWNl
X3Jlc3VsdCAqcmVzdWx0LAorICAgICAgICAgICAgIHN0cnVjdCBjcHVfdXNlcl9yZWdzICpyZWdz
KQogewogICAgIHVpbnQ2NF90IHN0YXR1cyA9IGJpbmZvLT5taWItPm1jX3N0YXR1czsKIApAQCAt
NzQxLDcgKzc3Nyw3IEBAIHN0YXRpYyB2b2lkIGludGVsX3NyYW9fZGhhbmRsZXIoCiAgICAgICAg
IHsKICAgICAgICAgY2FzZSBJTlRFTF9TUkFPX01FTV9TQ1JVQjoKICAgICAgICAgY2FzZSBJTlRF
TF9TUkFPX0wzX0VXQjoKLSAgICAgICAgICAgIGludGVsX21lbWVycl9kaGFuZGxlcihiaW5mbywg
cmVzdWx0KTsKKyAgICAgICAgICAgIGludGVsX21lbWVycl9kaGFuZGxlcihiaW5mbywgcmVzdWx0
LCByZWdzKTsKICAgICAgICAgICAgIGJyZWFrOwogICAgICAgICBkZWZhdWx0OgogICAgICAgICAg
ICAgYnJlYWs7CkBAIC03NTYsMTQgKzc5MiwxNSBAQCBzdGF0aWMgaW50IGludGVsX2RlZmF1bHRf
Y2hlY2sodWludDY0X3QgCiAKIHN0YXRpYyB2b2lkIGludGVsX2RlZmF1bHRfbWNlX2RoYW5kbGVy
KAogICAgICAgICAgICAgIHN0cnVjdCBtY2FfYmluZm8gKmJpbmZvLAotICAgICAgICAgICAgIGVu
dW0gbWNlX3Jlc3VsdCAqcmVzdWx0KQorICAgICAgICAgICAgIGVudW0gbWNlX3Jlc3VsdCAqcmVz
dWx0LAorICAgICAgICAgICAgIHN0cnVjdCBjcHVfdXNlcl9yZWdzICogcmVncykKIHsKICAgICB1
aW50NjRfdCBzdGF0dXMgPSBiaW5mby0+bWliLT5tY19zdGF0dXM7CiAgICAgZW51bSBpbnRlbF9t
Y2VfdHlwZSB0eXBlOwogCiAgICAgdHlwZSA9IGludGVsX2NoZWNrX21jZV90eXBlKHN0YXR1cyk7
CiAKLSAgICBpZiAodHlwZSA9PSBpbnRlbF9tY2VfZmF0YWwgfHwgdHlwZSA9PSBpbnRlbF9tY2Vf
dWNyX3NyYXIpCisgICAgaWYgKHR5cGUgPT0gaW50ZWxfbWNlX2ZhdGFsKQogICAgICAgICAqcmVz
dWx0ID0gTUNFUl9SRVNFVDsKICAgICBlbHNlCiAgICAgICAgICpyZXN1bHQgPSBNQ0VSX0NPTlRJ
TlVFOwpAQCAtNzcxLDEyICs4MDgsMTQgQEAgc3RhdGljIHZvaWQgaW50ZWxfZGVmYXVsdF9tY2Vf
ZGhhbmRsZXIoCiAKIHN0YXRpYyBjb25zdCBzdHJ1Y3QgbWNhX2Vycm9yX2hhbmRsZXIgaW50ZWxf
bWNlX2RoYW5kbGVyc1tdID0gewogICAgIHtpbnRlbF9zcmFvX2NoZWNrLCBpbnRlbF9zcmFvX2Ro
YW5kbGVyfSwKKyAgICB7aW50ZWxfc3Jhcl9jaGVjaywgaW50ZWxfc3Jhcl9kaGFuZGxlcn0sCiAg
ICAge2ludGVsX2RlZmF1bHRfY2hlY2ssIGludGVsX2RlZmF1bHRfbWNlX2RoYW5kbGVyfQogfTsK
IAogc3RhdGljIHZvaWQgaW50ZWxfZGVmYXVsdF9tY2VfdWhhbmRsZXIoCiAgICAgICAgICAgICAg
c3RydWN0IG1jYV9iaW5mbyAqYmluZm8sCi0gICAgICAgICAgICAgZW51bSBtY2VfcmVzdWx0ICpy
ZXN1bHQpCisgICAgICAgICAgICAgZW51bSBtY2VfcmVzdWx0ICpyZXN1bHQsCisgICAgICAgICAg
ICAgc3RydWN0IGNwdV91c2VyX3JlZ3MgKnJlZ3MpCiB7CiAgICAgdWludDY0X3Qgc3RhdHVzID0g
YmluZm8tPm1pYi0+bWNfc3RhdHVzOwogICAgIGVudW0gaW50ZWxfbWNlX3R5cGUgdHlwZTsKQEAg
LTc4NSw4ICs4MjQsNiBAQCBzdGF0aWMgdm9pZCBpbnRlbF9kZWZhdWx0X21jZV91aGFuZGxlcigK
IAogICAgIHN3aXRjaCAodHlwZSkKICAgICB7Ci0gICAgLyogUGFuaWMgaWYgbm8gaGFuZGxlciBm
b3IgU1JBUiBlcnJvciAqLwotICAgIGNhc2UgaW50ZWxfbWNlX3Vjcl9zcmFyOgogICAgIGNhc2Ug
aW50ZWxfbWNlX2ZhdGFsOgogICAgICAgICAqcmVzdWx0ID0gTUNFUl9SRVNFVDsKICAgICAgICAg
YnJlYWs7CkBAIC05NjEsMTAgKzk5OCw4IEBAIHN0YXRpYyBpbnQgaW50ZWxfcmVjb3ZlcmFibGVf
c2Nhbih1NjQgc3QKICAgICAvKiBTUkFSIGVycm9yICovCiAgICAgZWxzZSBpZiAoIHNlcl9zdXBw
b3J0ICYmICEoc3RhdHVzICYgTUNpX1NUQVRVU19PVkVSKSAKICAgICAgICAgICAgICAgICAmJiAh
KHN0YXR1cyAmIE1DaV9TVEFUVVNfUENDKSAmJiAoc3RhdHVzICYgTUNpX1NUQVRVU19TKQotICAg
ICAgICAgICAgICAgICYmIChzdGF0dXMgJiBNQ2lfU1RBVFVTX0FSKSApIHsKLSAgICAgICAgbWNl
X3ByaW50ayhNQ0VfVkVSQk9TRSwgIk1DRTogTm8gU1JBUiBlcnJvciBkZWZpbmVkIGN1cnJlbnRs
eS5cbiIpOwotICAgICAgICByZXR1cm4gMDsKLSAgICB9CisgICAgICAgICAgICAgICAgJiYgKHN0
YXR1cyAmIE1DaV9TVEFUVVNfQVIpICYmIChzdGF0dXMgJiBNQ2lfU1RBVFVTX0VOKSApCisgICAg
ICAgIHJldHVybiAxOwogICAgIC8qIFNSQU8gZXJyb3IgKi8KICAgICBlbHNlIGlmIChzZXJfc3Vw
cG9ydCAmJiAhKHN0YXR1cyAmIE1DaV9TVEFUVVNfUENDKQogICAgICAgICAgICAgICAgICYmIChz
dGF0dXMgJiBNQ2lfU1RBVFVTX1MpICYmICEoc3RhdHVzICYgTUNpX1NUQVRVU19BUikKZGlmZiAt
ciAxNTE1NDg0MzUzYzYgeGVuL2FyY2gveDg2L2NwdS9tY2hlY2sveDg2X21jYS5oCi0tLSBhL3hl
bi9hcmNoL3g4Ni9jcHUvbWNoZWNrL3g4Nl9tY2EuaAlUaHUgT2N0IDEzIDEwOjA5OjI4IDIwMTEg
KzAyMDAKKysrIGIveGVuL2FyY2gveDg2L2NwdS9tY2hlY2sveDg2X21jYS5oCVNhdCBPY3QgMjIg
MDE6NDA6NDEgMjAxMSArMDgwMApAQCAtMTUxLDcgKzE1MSw3IEBAIHN0cnVjdCBtY2FfZXJyb3Jf
aGFuZGxlcgogICAgICovCiAgICAgaW50ICgqb3duZWRfZXJyb3IpKHVpbnQ2NF90IHN0YXR1cyk7
CiAgICAgdm9pZCAoKnJlY292ZXJ5X2hhbmRsZXIpKHN0cnVjdCBtY2FfYmluZm8gKmJpbmZvLAot
ICAgICAgICAgICAgICAgICAgICBlbnVtIG1jZV9yZXN1bHQgKnJlc3VsdCk7CisgICAgICAgICAg
ICAgICAgICAgIGVudW0gbWNlX3Jlc3VsdCAqcmVzdWx0LCBzdHJ1Y3QgY3B1X3VzZXJfcmVncyAq
cmVncyk7CiB9OwogCiAvKiBHbG9iYWwgdmFyaWFibGVzICovCg==

--_004_BC00F5384FCFC9499AF06F92E8B78A9E2870CA7A13shsmsx502ccrc_
Content-Type: application/octet-stream; name="srar-guest-mode.patch"
Content-Description: srar-guest-mode.patch
Content-Disposition: attachment; filename="srar-guest-mode.patch"; size=1448;
	creation-date="Sat, 03 Dec 2011 16:01:36 GMT";
	modification-date="Sat, 03 Dec 2011 07:27:08 GMT"
Content-Transfer-Encoding: base64

WDg2OiBBZGQgbW9yZSBzdHJpY3Qgc2FuaXR5IGNoZWNrIG9mIG9uZSBTUkFSIGNhc2UKCldoZW4g
UklQViA9IEVJUFYgPSAwLCBpdCdzIGEgbGl0dGxlIGJpdCB0cmlja3kuIEl0IG1heSBiZSBhbiBh
c3luY2hyb25pYyBlcnJvciwgY3VycmVudGx5IHdlIGhhdmUgbm8gd2F5IHRvIHByZWNpc2VseSBs
b2NhdGUgd2hldGhlciB0aGUgZXJyb3Igb2NjdXIgYXQgZ3Vlc3Qgb3IgaHlwZXJ2aXNvci4gClRv
IGF2b2lkIGhhbmRsaW5nIGVycm9yIGluIHdyb25nIHdheSwgd2UgdHJlYXQgaXQgYXMgdW5yZWNv
dmVyZWQuCgpTaWduZWQtb2ZmLWJ5OiBMaXUsIEppbnNvbmcgPGppbnNvbmcubGl1QGludGVsLmNv
bT4KU2lnbmVkLW9mZi1ieTogSmFuIEJldWxpY2ggPGpiZXVsaWNoQHN1c2UuY29tPgoKIyBIRyBj
aGFuZ2VzZXQgcGF0Y2gKIyBQYXJlbnQgZTc1OGIxZDkyOGUzZDY2MzYwMjc0MWRkYzdmNTU0NjFl
MjE4NzgyOQoKZGlmZiAtciBlNzU4YjFkOTI4ZTMgeGVuL2FyY2gveDg2L2NwdS9tY2hlY2svbWNl
X2ludGVsLmMKLS0tIGEveGVuL2FyY2gveDg2L2NwdS9tY2hlY2svbWNlX2ludGVsLmMJU3VuIE9j
dCAzMCAxNzo1MDo1MyAyMDExIC0wODAwCisrKyBiL3hlbi9hcmNoL3g4Ni9jcHUvbWNoZWNrL21j
ZV9pbnRlbC5jCUZyaSBEZWMgMDIgMTU6MTY6NTIgMjAxMSAtMDgwMApAQCAtMzY3LDggKzM2Nywx
OCBAQAogICAgICAgICByZXR1cm4gMDsKIAogICAgIGdzdGF0dXMgPSBtY2FfcmRtc3IoTVNSX0lB
MzJfTUNHX1NUQVRVUyk7Ci0gICAgLyogWGVuIGlzIG5vdCBwcmUtZW1wdGlibGUgKi8KLSAgICBp
ZiAoICEoZ3N0YXR1cyAmIE1DR19TVEFUVVNfUklQVikgJiYgIWd1ZXN0X21vZGUocmVncykpCisK
KyAgICAvKgorICAgICAqIEZJWE1FOiBXaGVuIFJJUFYgPSBFSVBWID0gMCwgaXQncyBhIGxpdHRs
ZSBiaXQgdHJpY2t5LiBJdCBtYXkgYmUgYW4KKyAgICAgKiBhc3luY2hyb25pYyBlcnJvciwgY3Vy
cmVudGx5IHdlIGhhdmUgbm8gd2F5IHRvIHByZWNpc2VseSBsb2NhdGUKKyAgICAgKiB3aGV0aGVy
IHRoZSBlcnJvciBvY2N1ciBhdCBndWVzdCBvciBoeXBlcnZpc29yLgorICAgICAqIFRvIGF2b2lk
IGhhbmRsaW5nIGVycm9yIGluIHdyb25nIHdheSwgd2UgdHJlYXQgaXQgYXMgdW5yZWNvdmVyZWQu
CisgICAgICoKKyAgICAgKiBBbm90aGVyIHVucmVjb3ZlcmVkIGNhc2UgaXMgUklQViA9IDAgd2hp
bGUgaW4gaHlwZXJ2aXNvcgorICAgICAqIHNpbmNlIFhlbiBpcyBub3QgcHJlLWVtcHRpYmxlLgor
ICAgICAqLworICAgIGlmICggIShnc3RhdHVzICYgTUNHX1NUQVRVU19SSVBWKSAmJgorICAgICAg
ICAoIShnc3RhdHVzICYgTUNHX1NUQVRVU19FSVBWKSB8fCAhZ3Vlc3RfbW9kZShyZWdzKSkgKQog
ICAgICAgICByZXR1cm4gLTE7CiAKICAgICByZXR1cm4gbWNlX2FjdGlvbihyZWdzLCBtY3RjKSA9
PSBNQ0VSX1JFU0VUID8gLTEgOiAwOwo=

--_004_BC00F5384FCFC9499AF06F92E8B78A9E2870CA7A13shsmsx502ccrc_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--_004_BC00F5384FCFC9499AF06F92E8B78A9E2870CA7A13shsmsx502ccrc_--


From xen-devel-bounces@lists.xensource.com Mon Dec 05 13:19:25 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 13:19:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXYRh-0005nF-Lf; Mon, 05 Dec 2011 13:19:01 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RXYRf-0005nA-IS
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 13:18:59 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1323091094!682008!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4OTE=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7569 invoked from network); 5 Dec 2011 13:18:15 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-4.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 5 Dec 2011 13:18:15 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 05 Dec 2011 13:18:09 +0000
Message-Id: <4EDCD29F02000078000656D5@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 05 Dec 2011 13:18:07 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>
References: <4EDCAC68.8060303@citrix.com>
	<4EDCCDE802000078000656A1@nat28.tlf.novell.com>
	<4EDCC0AE.1030100@citrix.com>
In-Reply-To: <4EDCC0AE.1030100@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] KEXEC: fix kexec_get_range_compat to fail vocally
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 05.12.11 at 14:01, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
> On 05/12/11 12:58, Jan Beulich wrote:
>> Both under the assumption that apart from the truncation nothing
>> prevents addresses above the 4G boundary from being usable with
>> a 32-bit kernel for at least one of the ranges (probably only
>> KEXEC_RANGE_MA_CPU and KEXEC_RANGE_MA_VMCOREINFO are
>> candidates for this on x86).
> 
> Will those ranges not be covered by my patch?

That wasn't the question. My point was that your change and the new
sub-hypercall are useful only if any of these ranges can validly live
above 4G (i.e. if we don't need to instead constrain the allocations).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 13:19:25 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 13:19:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXYRh-0005nF-Lf; Mon, 05 Dec 2011 13:19:01 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RXYRf-0005nA-IS
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 13:18:59 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1323091094!682008!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4OTE=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7569 invoked from network); 5 Dec 2011 13:18:15 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-4.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 5 Dec 2011 13:18:15 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 05 Dec 2011 13:18:09 +0000
Message-Id: <4EDCD29F02000078000656D5@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 05 Dec 2011 13:18:07 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>
References: <4EDCAC68.8060303@citrix.com>
	<4EDCCDE802000078000656A1@nat28.tlf.novell.com>
	<4EDCC0AE.1030100@citrix.com>
In-Reply-To: <4EDCC0AE.1030100@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] KEXEC: fix kexec_get_range_compat to fail vocally
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 05.12.11 at 14:01, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
> On 05/12/11 12:58, Jan Beulich wrote:
>> Both under the assumption that apart from the truncation nothing
>> prevents addresses above the 4G boundary from being usable with
>> a 32-bit kernel for at least one of the ranges (probably only
>> KEXEC_RANGE_MA_CPU and KEXEC_RANGE_MA_VMCOREINFO are
>> candidates for this on x86).
> 
> Will those ranges not be covered by my patch?

That wasn't the question. My point was that your change and the new
sub-hypercall are useful only if any of these ranges can validly live
above 4G (i.e. if we don't need to instead constrain the allocations).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 13:22:32 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 13: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.xensource.com>)
	id 1RXYUk-0005tY-8v; Mon, 05 Dec 2011 13:22:10 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RXYUj-0005tO-DV
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 13:22:09 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1323091284!6953584!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4OTE=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5092 invoked from network); 5 Dec 2011 13:21:24 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-8.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 5 Dec 2011 13:21:24 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 05 Dec 2011 13:21:24 +0000
Message-Id: <4EDCD36302000078000656E7@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 05 Dec 2011 13:21:23 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Jinsong Liu" <jinsong.liu@intel.com>
References: <BC00F5384FCFC9499AF06F92E8B78A9E2870BB484D@shsmsx502.ccr.corp.intel.com>
	<BC00F5384FCFC9499AF06F92E8B78A9E2870CA7A13@shsmsx502.ccr.corp.intel.com>
In-Reply-To: <BC00F5384FCFC9499AF06F92E8B78A9E2870CA7A13@shsmsx502.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "keir.xen@gmail.com" <keir.xen@gmail.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Yunhong Jiang <yunhong.jiang@intel.com>
Subject: Re: [Xen-devel] [PATCH] X86 MCE: Add more strict sanity check of
 one SRAR case
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 05.12.11 at 14:09, "Liu, Jinsong" <jinsong.liu@intel.com> wrote:
> Attached is the email we discuss last month, and 2 mce patches:
> srar-1.patch is the patch we discussed before,
> srar-guest-mode.patch is an additional patch w/ more strict sanity checkof 
> RIPV = EIPV = 0.
> Any comments please let me know.

I'll get to commit these once the current set of regressions cleared.

Thanks for sending the original patch again (saves me from having to
dig it out of the list archives).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 13:22:32 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 13: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.xensource.com>)
	id 1RXYUk-0005tY-8v; Mon, 05 Dec 2011 13:22:10 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RXYUj-0005tO-DV
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 13:22:09 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1323091284!6953584!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4OTE=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5092 invoked from network); 5 Dec 2011 13:21:24 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-8.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 5 Dec 2011 13:21:24 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 05 Dec 2011 13:21:24 +0000
Message-Id: <4EDCD36302000078000656E7@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 05 Dec 2011 13:21:23 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Jinsong Liu" <jinsong.liu@intel.com>
References: <BC00F5384FCFC9499AF06F92E8B78A9E2870BB484D@shsmsx502.ccr.corp.intel.com>
	<BC00F5384FCFC9499AF06F92E8B78A9E2870CA7A13@shsmsx502.ccr.corp.intel.com>
In-Reply-To: <BC00F5384FCFC9499AF06F92E8B78A9E2870CA7A13@shsmsx502.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "keir.xen@gmail.com" <keir.xen@gmail.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Yunhong Jiang <yunhong.jiang@intel.com>
Subject: Re: [Xen-devel] [PATCH] X86 MCE: Add more strict sanity check of
 one SRAR case
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 05.12.11 at 14:09, "Liu, Jinsong" <jinsong.liu@intel.com> wrote:
> Attached is the email we discuss last month, and 2 mce patches:
> srar-1.patch is the patch we discussed before,
> srar-guest-mode.patch is an additional patch w/ more strict sanity checkof 
> RIPV = EIPV = 0.
> Any comments please let me know.

I'll get to commit these once the current set of regressions cleared.

Thanks for sending the original patch again (saves me from having to
dig it out of the list archives).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 13:40:49 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 13:40:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXYmQ-0006AQ-1p; Mon, 05 Dec 2011 13:40:26 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1RXYmP-0006AL-6J
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 13:40:25 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1323092343!48579372!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjk1OTY=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17689 invoked from network); 5 Dec 2011 13:39:05 -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;
	5 Dec 2011 13:39:05 -0000
X-IronPort-AV: E=Sophos;i="4.71,299,1320642000"; d="scan'208";a="172896358"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Dec 2011 08:39:44 -0500
Received: from [10.80.2.18] (10.80.2.18) by FTLPMAILMX01.citrite.net
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Mon, 5 Dec 2011
	08:39:43 -0500
Message-ID: <4EDCC99E.4010401@citrix.com>
Date: Mon, 5 Dec 2011 13:39:42 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.23) Gecko/20110921 Lightning/1.0b2 Thunderbird/3.1.15
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <4EDCAC68.8060303@citrix.com>
	<4EDCCDE802000078000656A1@nat28.tlf.novell.com>
	<4EDCC0AE.1030100@citrix.com>
	<4EDCD29F02000078000656D5@nat28.tlf.novell.com>
In-Reply-To: <4EDCD29F02000078000656D5@nat28.tlf.novell.com>
X-Enigmail-Version: 1.1.2
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] KEXEC: fix kexec_get_range_compat to fail vocally
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 05/12/11 13:18, Jan Beulich wrote:
>>>> On 05.12.11 at 14:01, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>> On 05/12/11 12:58, Jan Beulich wrote:
>>> Both under the assumption that apart from the truncation nothing
>>> prevents addresses above the 4G boundary from being usable with
>>> a 32-bit kernel for at least one of the ranges (probably only
>>> KEXEC_RANGE_MA_CPU and KEXEC_RANGE_MA_VMCOREINFO are
>>> candidates for this on x86).
>> Will those ranges not be covered by my patch?
> That wasn't the question. My point was that your change and the new
> sub-hypercall are useful only if any of these ranges can validly live
> above 4G (i.e. if we don't need to instead constrain the allocations).
>
> Jan

Ah ok - I misunderstood.  As part of my planned changes to the kexec
path, there will be a command line parameter to request all kexec
related allocs are below a specified address.  My intention is that this
would typically be set to either 64GB if you use a 32bit PAE crash
kernel, or 4G for using a 32bit non-PAE kernel.  Certain other
allocations which would be covered by this parameter would be the
console ring, so the crash kernel can pull it out of memory and dump it
to disk.

We need this functionality for XenServer as we use a 32bit PAE crash
kernel, but it does have an impact on how many 32bit PV guests you can
boot on a large memory machine.  At the moment, there is a hack^H "fix"
from before my time in the XS patch queue to allocate crash notes in
Xen's BSS so it falls into the Xen mapped region of dom0 memory, but has
the problem of needing all the notes to be compile time constant
lengths, which reduces flexibility.  (It was also to work around an old
bug in kexec tools where it would consider the "Crash Notes" invalid if
they were not explicitly in a System Ram section - this appears fixed now.)

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 13:40:49 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 13:40:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXYmQ-0006AQ-1p; Mon, 05 Dec 2011 13:40:26 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1RXYmP-0006AL-6J
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 13:40:25 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1323092343!48579372!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjk1OTY=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17689 invoked from network); 5 Dec 2011 13:39:05 -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;
	5 Dec 2011 13:39:05 -0000
X-IronPort-AV: E=Sophos;i="4.71,299,1320642000"; d="scan'208";a="172896358"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Dec 2011 08:39:44 -0500
Received: from [10.80.2.18] (10.80.2.18) by FTLPMAILMX01.citrite.net
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Mon, 5 Dec 2011
	08:39:43 -0500
Message-ID: <4EDCC99E.4010401@citrix.com>
Date: Mon, 5 Dec 2011 13:39:42 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.23) Gecko/20110921 Lightning/1.0b2 Thunderbird/3.1.15
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <4EDCAC68.8060303@citrix.com>
	<4EDCCDE802000078000656A1@nat28.tlf.novell.com>
	<4EDCC0AE.1030100@citrix.com>
	<4EDCD29F02000078000656D5@nat28.tlf.novell.com>
In-Reply-To: <4EDCD29F02000078000656D5@nat28.tlf.novell.com>
X-Enigmail-Version: 1.1.2
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] KEXEC: fix kexec_get_range_compat to fail vocally
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 05/12/11 13:18, Jan Beulich wrote:
>>>> On 05.12.11 at 14:01, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>> On 05/12/11 12:58, Jan Beulich wrote:
>>> Both under the assumption that apart from the truncation nothing
>>> prevents addresses above the 4G boundary from being usable with
>>> a 32-bit kernel for at least one of the ranges (probably only
>>> KEXEC_RANGE_MA_CPU and KEXEC_RANGE_MA_VMCOREINFO are
>>> candidates for this on x86).
>> Will those ranges not be covered by my patch?
> That wasn't the question. My point was that your change and the new
> sub-hypercall are useful only if any of these ranges can validly live
> above 4G (i.e. if we don't need to instead constrain the allocations).
>
> Jan

Ah ok - I misunderstood.  As part of my planned changes to the kexec
path, there will be a command line parameter to request all kexec
related allocs are below a specified address.  My intention is that this
would typically be set to either 64GB if you use a 32bit PAE crash
kernel, or 4G for using a 32bit non-PAE kernel.  Certain other
allocations which would be covered by this parameter would be the
console ring, so the crash kernel can pull it out of memory and dump it
to disk.

We need this functionality for XenServer as we use a 32bit PAE crash
kernel, but it does have an impact on how many 32bit PV guests you can
boot on a large memory machine.  At the moment, there is a hack^H "fix"
from before my time in the XS patch queue to allocate crash notes in
Xen's BSS so it falls into the Xen mapped region of dom0 memory, but has
the problem of needing all the notes to be compile time constant
lengths, which reduces flexibility.  (It was also to work around an old
bug in kexec tools where it would consider the "Crash Notes" invalid if
they were not explicitly in a System Ram section - this appears fixed now.)

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 13:46:02 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 13:46:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXYrS-0006IO-Pq; Mon, 05 Dec 2011 13:45:38 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RXYrQ-0006IC-TJ
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 13:45:37 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1323092692!5922985!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjAyNg==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11498 invoked from network); 5 Dec 2011 13:44:52 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Dec 2011 13:44:52 -0000
X-IronPort-AV: E=Sophos;i="4.71,299,1320624000"; 
   d="scan'208";a="9290595"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Dec 2011 13:44:52 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 5 Dec 2011 13:44:51 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RXYqh-0002Eg-Ro; Mon, 05 Dec 2011 13:44:51 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RXYqh-0000zP-P1;
	Mon, 05 Dec 2011 13:44:51 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20188.51923.650562.536652@mariner.uk.xensource.com>
Date: Mon, 5 Dec 2011 13:44:51 +0000
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
In-Reply-To: <alpine.DEB.2.00.1112051053180.31179@kaball-desktop>
References: <alpine.DEB.2.00.1112051053180.31179@kaball-desktop>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] qemu_timer_pending/qemu_get_timer: cope with NULL
	timers
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Stefano Stabellini writes ("qemu_timer_pending/qemu_get_timer: cope with NULL timers"):
> qemu_timer_pending and qemu_get_timer: don't crash if the timer passed
> as an argument is NULL.
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 13:46:02 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 13:46:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXYrS-0006IO-Pq; Mon, 05 Dec 2011 13:45:38 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RXYrQ-0006IC-TJ
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 13:45:37 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1323092692!5922985!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjAyNg==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11498 invoked from network); 5 Dec 2011 13:44:52 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Dec 2011 13:44:52 -0000
X-IronPort-AV: E=Sophos;i="4.71,299,1320624000"; 
   d="scan'208";a="9290595"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Dec 2011 13:44:52 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 5 Dec 2011 13:44:51 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RXYqh-0002Eg-Ro; Mon, 05 Dec 2011 13:44:51 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RXYqh-0000zP-P1;
	Mon, 05 Dec 2011 13:44:51 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20188.51923.650562.536652@mariner.uk.xensource.com>
Date: Mon, 5 Dec 2011 13:44:51 +0000
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
In-Reply-To: <alpine.DEB.2.00.1112051053180.31179@kaball-desktop>
References: <alpine.DEB.2.00.1112051053180.31179@kaball-desktop>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] qemu_timer_pending/qemu_get_timer: cope with NULL
	timers
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Stefano Stabellini writes ("qemu_timer_pending/qemu_get_timer: cope with NULL timers"):
> qemu_timer_pending and qemu_get_timer: don't crash if the timer passed
> as an argument is NULL.
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 14:01:00 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 14:01:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXZ5s-0006az-CS; Mon, 05 Dec 2011 14:00:32 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RXZ5q-0006ag-4G
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 14:00:30 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1323093585!1374794!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjAyNg==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16242 invoked from network); 5 Dec 2011 13:59:45 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Dec 2011 13:59:45 -0000
X-IronPort-AV: E=Sophos;i="4.71,299,1320624000"; 
   d="scan'208";a="9291057"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Dec 2011 13:59:45 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Mon, 5 Dec 2011
	13:59:45 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Mon, 5 Dec 2011 13:59:44 +0000
In-Reply-To: <alpine.DEB.2.00.1112051053180.31179@kaball-desktop>
References: <alpine.DEB.2.00.1112051053180.31179@kaball-desktop>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323093585.29870.192.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Ian
	Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] qemu_timer_pending/qemu_get_timer: cope with NULL
 timers
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2011-12-05 at 10:54 +0000, Stefano Stabellini wrote:
> qemu_timer_pending and qemu_get_timer: don't crash if the timer passed
> as an argument is NULL.

It would have been useful to mention why a NULL timer is valid here.
Apart from just being good changelog practice to explain the actual
reason for a change this would also help tell us why this issue isn't
being solved further up the stack. One the face of it this seem like
this ought to be a bug in the caller of qemu_mod_timer.

Ian.
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> 
> diff --git a/vl.c b/vl.c
> index f07a659..f3b3d02 100644
> --- a/vl.c
> +++ b/vl.c
> @@ -1201,6 +1201,10 @@ void qemu_mod_timer(QEMUTimer *ts, int64_t expire_time)
>  int qemu_timer_pending(QEMUTimer *ts)
>  {
>      QEMUTimer *t;
> +
> +    if (ts == NULL)
> +        return 0;
> +
>      for(t = active_timers[ts->clock->type]; t != NULL; t = t->next) {
>          if (t == ts)
>              return 1;
> @@ -1272,6 +1276,9 @@ void qemu_get_timer(QEMUFile *f, QEMUTimer *ts)
>  {
>      uint64_t expire_time;
>  
> +    if (ts == NULL)
> +        return;
> +
>      expire_time = qemu_get_be64(f);
>      if (expire_time != -1) {
>          qemu_mod_timer(ts, expire_time);
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 14:01:00 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 14:01:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXZ5s-0006az-CS; Mon, 05 Dec 2011 14:00:32 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RXZ5q-0006ag-4G
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 14:00:30 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1323093585!1374794!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjAyNg==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16242 invoked from network); 5 Dec 2011 13:59:45 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Dec 2011 13:59:45 -0000
X-IronPort-AV: E=Sophos;i="4.71,299,1320624000"; 
   d="scan'208";a="9291057"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Dec 2011 13:59:45 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Mon, 5 Dec 2011
	13:59:45 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Mon, 5 Dec 2011 13:59:44 +0000
In-Reply-To: <alpine.DEB.2.00.1112051053180.31179@kaball-desktop>
References: <alpine.DEB.2.00.1112051053180.31179@kaball-desktop>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323093585.29870.192.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Ian
	Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] qemu_timer_pending/qemu_get_timer: cope with NULL
 timers
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2011-12-05 at 10:54 +0000, Stefano Stabellini wrote:
> qemu_timer_pending and qemu_get_timer: don't crash if the timer passed
> as an argument is NULL.

It would have been useful to mention why a NULL timer is valid here.
Apart from just being good changelog practice to explain the actual
reason for a change this would also help tell us why this issue isn't
being solved further up the stack. One the face of it this seem like
this ought to be a bug in the caller of qemu_mod_timer.

Ian.
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> 
> diff --git a/vl.c b/vl.c
> index f07a659..f3b3d02 100644
> --- a/vl.c
> +++ b/vl.c
> @@ -1201,6 +1201,10 @@ void qemu_mod_timer(QEMUTimer *ts, int64_t expire_time)
>  int qemu_timer_pending(QEMUTimer *ts)
>  {
>      QEMUTimer *t;
> +
> +    if (ts == NULL)
> +        return 0;
> +
>      for(t = active_timers[ts->clock->type]; t != NULL; t = t->next) {
>          if (t == ts)
>              return 1;
> @@ -1272,6 +1276,9 @@ void qemu_get_timer(QEMUFile *f, QEMUTimer *ts)
>  {
>      uint64_t expire_time;
>  
> +    if (ts == NULL)
> +        return;
> +
>      expire_time = qemu_get_be64(f);
>      if (expire_time != -1) {
>          qemu_mod_timer(ts, expire_time);
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 14:07:15 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 14:07:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXZBn-0006kC-9p; Mon, 05 Dec 2011 14:06:39 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RXZBl-0006k4-RN
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 14:06:38 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1323093951!4316400!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjAyNg==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26291 invoked from network); 5 Dec 2011 14:05:52 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Dec 2011 14:05:52 -0000
X-IronPort-AV: E=Sophos;i="4.71,299,1320624000"; 
   d="scan'208";a="9291238"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Dec 2011 14:05:51 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 5 Dec 2011 14:05:51 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RXZB1-0002MV-Av;
	Mon, 05 Dec 2011 14:05:51 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RXZB1-0004nD-AO;
	Mon, 05 Dec 2011 14:05:51 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10344-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 5 Dec 2011 14:05:51 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10344: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10344 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10344/

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-i386-xl-winxpsp3-vcpus1  4 xen-install         fail REGR. vs. 10201
 test-amd64-i386-xl-win7-amd64  4 xen-install              fail REGR. vs. 10201
 test-amd64-i386-xend-winxpsp3  4 xen-install              fail REGR. vs. 10201
 test-amd64-i386-pv            4 xen-install               fail REGR. vs. 10201
 test-amd64-i386-xl-credit2    4 xen-install               fail REGR. vs. 10201
 test-amd64-i386-xl-multivcpu  4 xen-install               fail REGR. vs. 10201
 test-amd64-i386-xl            4 xen-install               fail REGR. vs. 10201
 test-amd64-i386-pair          6 xen-install/dst_host      fail REGR. vs. 10201
 test-amd64-i386-pair          5 xen-install/src_host      fail REGR. vs. 10201
 build-i386                    4 xen-build                 fail REGR. vs. 10201
 build-i386-oldkern            4 xen-build                 fail REGR. vs. 10201
 test-amd64-i386-rhel6hvm-intel  4 xen-install             fail REGR. vs. 10201
 test-amd64-i386-rhel6hvm-amd  4 xen-install               fail REGR. vs. 10201
 test-amd64-i386-win-vcpus1    4 xen-install               fail REGR. vs. 10201
 test-amd64-i386-win           4 xen-install               fail REGR. vs. 10201
 test-amd64-amd64-win          8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-amd64-xl-win       8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-i386-xl-win-vcpus1  4 xen-install              fail REGR. vs. 10201

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf     14 guest-localmigrate/x10      fail pass in 10313

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-win7-amd64  7 windows-install              fail never pass
 test-i386-i386-xl-winxpsp3    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-i386-i386-pv             1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl             1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pair           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   never pass
 test-i386-i386-win            1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-win         1 xen-build-check(1)           blocked  n/a

version targeted for testing:
 xen                  a4d7c27ec1f1
baseline version:
 xen                  62ff6a318c5d

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Anthony PERARD <anthony.perard@citrix.com>
  Brendan Cully <brendan@cs.ubc.ca>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@novell.com>
  Jan Beulich <jbeulich@suse.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Jonathan Davies <jonathan.davies@citrix.com>
  juergen.gross@ts.fujitsu.com
  Keir Fraser <keir@xen.org>
  Liu, Jinsong <jinsong.liu@intel.com>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
  Philipp Hahn <hahn@univention.de>
  Shriram Rajagopalan <rshriram@cs.ubc.ca>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang2 <wei.wang2@amd.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   fail    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           fail    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           fail    
 test-i386-i386-xl                                            blocked 
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-i386-i386-pair                                          blocked 
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           fail    
 test-i386-i386-pv                                            blocked 
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           blocked 
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        blocked 
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   blocked 


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 1262 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 14:07:15 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 14:07:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXZBn-0006kC-9p; Mon, 05 Dec 2011 14:06:39 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RXZBl-0006k4-RN
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 14:06:38 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1323093951!4316400!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjAyNg==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26291 invoked from network); 5 Dec 2011 14:05:52 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Dec 2011 14:05:52 -0000
X-IronPort-AV: E=Sophos;i="4.71,299,1320624000"; 
   d="scan'208";a="9291238"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Dec 2011 14:05:51 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 5 Dec 2011 14:05:51 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RXZB1-0002MV-Av;
	Mon, 05 Dec 2011 14:05:51 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RXZB1-0004nD-AO;
	Mon, 05 Dec 2011 14:05:51 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10344-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 5 Dec 2011 14:05:51 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10344: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10344 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10344/

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-i386-xl-winxpsp3-vcpus1  4 xen-install         fail REGR. vs. 10201
 test-amd64-i386-xl-win7-amd64  4 xen-install              fail REGR. vs. 10201
 test-amd64-i386-xend-winxpsp3  4 xen-install              fail REGR. vs. 10201
 test-amd64-i386-pv            4 xen-install               fail REGR. vs. 10201
 test-amd64-i386-xl-credit2    4 xen-install               fail REGR. vs. 10201
 test-amd64-i386-xl-multivcpu  4 xen-install               fail REGR. vs. 10201
 test-amd64-i386-xl            4 xen-install               fail REGR. vs. 10201
 test-amd64-i386-pair          6 xen-install/dst_host      fail REGR. vs. 10201
 test-amd64-i386-pair          5 xen-install/src_host      fail REGR. vs. 10201
 build-i386                    4 xen-build                 fail REGR. vs. 10201
 build-i386-oldkern            4 xen-build                 fail REGR. vs. 10201
 test-amd64-i386-rhel6hvm-intel  4 xen-install             fail REGR. vs. 10201
 test-amd64-i386-rhel6hvm-amd  4 xen-install               fail REGR. vs. 10201
 test-amd64-i386-win-vcpus1    4 xen-install               fail REGR. vs. 10201
 test-amd64-i386-win           4 xen-install               fail REGR. vs. 10201
 test-amd64-amd64-win          8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-amd64-xl-win       8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-i386-xl-win-vcpus1  4 xen-install              fail REGR. vs. 10201

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf     14 guest-localmigrate/x10      fail pass in 10313

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-win7-amd64  7 windows-install              fail never pass
 test-i386-i386-xl-winxpsp3    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-i386-i386-pv             1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl             1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pair           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   never pass
 test-i386-i386-win            1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-win         1 xen-build-check(1)           blocked  n/a

version targeted for testing:
 xen                  a4d7c27ec1f1
baseline version:
 xen                  62ff6a318c5d

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Anthony PERARD <anthony.perard@citrix.com>
  Brendan Cully <brendan@cs.ubc.ca>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@novell.com>
  Jan Beulich <jbeulich@suse.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Jonathan Davies <jonathan.davies@citrix.com>
  juergen.gross@ts.fujitsu.com
  Keir Fraser <keir@xen.org>
  Liu, Jinsong <jinsong.liu@intel.com>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
  Philipp Hahn <hahn@univention.de>
  Shriram Rajagopalan <rshriram@cs.ubc.ca>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang2 <wei.wang2@amd.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   fail    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           fail    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           fail    
 test-i386-i386-xl                                            blocked 
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-i386-i386-pair                                          blocked 
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           fail    
 test-i386-i386-pv                                            blocked 
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           blocked 
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        blocked 
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   blocked 


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 1262 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 14:35:05 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 14:35:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXZcn-0006z8-NJ; Mon, 05 Dec 2011 14:34:33 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <stefan.bader@canonical.com>) id 1RXZcm-0006z0-JA
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 14:34:32 +0000
X-Env-Sender: stefan.bader@canonical.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1323095628!1277138!1
X-Originating-IP: [91.189.89.112]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23869 invoked from network); 5 Dec 2011 14:33:48 -0000
Received: from youngberry.canonical.com (HELO youngberry.canonical.com)
	(91.189.89.112) by server-2.tower-21.messagelabs.com with SMTP;
	5 Dec 2011 14:33:48 -0000
Received: from p5b2e58f2.dip.t-dialin.net ([91.46.88.242] helo=[192.168.2.5])
	by youngberry.canonical.com with esmtpsa
	(TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71)
	(envelope-from <stefan.bader@canonical.com>)
	id 1RXZc2-0002Uu-VP; Mon, 05 Dec 2011 14:33:47 +0000
Message-ID: <4EDCD649.8050108@canonical.com>
Date: Mon, 05 Dec 2011 15:33:45 +0100
From: Stefan Bader <stefan.bader@canonical.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:8.0) Gecko/20111124 Thunderbird/8.0
MIME-Version: 1.0
To: =?ISO-8859-1?Q?Pasi_K=E4rkk=E4inen?= <pasik@iki.fi>
References: <4ED798B2.1040309@canonical.com>
	<20111201180944.GH12984@reaktio.net>
	<4ED8A45A.3050403@canonical.com>
	<20111202104110.GL12984@reaktio.net>
In-Reply-To: <20111202104110.GL12984@reaktio.net>
X-Enigmail-Version: 1.4a1pre
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Xen 4.x / Linux 3.x (dom0 and HVM domU) and NIC
	handling
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 02.12.2011 11:41, Pasi K=E4rkk=E4inen wrote:
> On Fri, Dec 02, 2011 at 11:11:38AM +0100, Stefan Bader wrote:
>> On 01.12.2011 19:09, Pasi K=E4rkk=E4inen wrote:
>>> On Thu, Dec 01, 2011 at 04:09:38PM +0100, Stefan Bader wrote:
>>>> Moving to public discussion...
>>>>
>>>> This was found with Xen hypervisor version supporting device unpluggin=
g and the
>>>> domU kernel having net-/blkfront and pci platform built-in (or as modu=
le).
>>>>
>>>> The block device is defined as hda and the NIC type=3Dioemu (so theore=
tically
>>>> guests without pv support would work, too).
>>>>
>>>> Since both drivers are present, the kernel tries to unplug the emulate=
d devices
>>>> and succeeds. The blkfront driver detects the xvda device available in=
 parallel
>>>> and is working ok.
>>>>
>>>> However the network interface does not work. There are entries present=
 under
>>>> sysfs for the xenbus but trying to bring it up fails with errors. And =
also there
>>>> seems to be no mac address set (all zeros in sysfs).
>>>> When the type=3Dioemu is removed in the configuration, this works.
>>>>
>>>> I have not much more debugging information beyond that, yet. But it so=
unds a bit
>>>> like NICs should behave the same as block devices. So if there is an e=
mulated
>>>> device defined there will be an alternate paravirt interface for it an=
d after
>>>> unplugging the emulated ones we end up with the pv ones.
>>>> Is that something that can be seen with newer Xen versions, too (I am =
using 4.1.1)?
>>>>
>>>
>>> Hey,
>>>
>>> Have you seen?: =

>>> http://wiki.xen.org/xenwiki/XenLinuxPVonHVMdrivers
>>>
>>> Especially the following note:
>>> "NOTE! If you have "type=3Dioemu" specified for the "vif"-line, PVHVM d=
rivers WILL NOT work! Don't specify "type" parameter for the vif. (with typ=
e=3Dioemu the pvhvm nic in the VM will have mac address full of zeroes - an=
d thus won't work!)."
>>>
>>> "type=3Dioemu" is not needed, at least with xm/xend toolstack both HVM =
and PVHVM guests work OK without it.
>>>
>>> -- Pasi
>>>
>> Thanks Pasi,
>>
>> hmm, so it is documented actually and thus sort of expected. Still it is
>> confusing. For one driver it does not make a difference to use the form =
of an
>> emulated device in the config, for the other it does. The xl stack works=
, the xm
>> stack does not.
>> And then, ok this is probably a quite naive approach, it seemed to make =
sense to
>> go through the pain of always having potentially both interfaces availab=
le
>> (emulated and pv) so in theory the same guest config can accommodate a g=
uest os
>> supporting one or the other (or easily switch from one to the other). Ot=
herwise
>> I would expect an emulated device only when I have hd? in the config and=
 a pv
>> device when I write xvd?.
>>
> =

> This works for both HVM and PVHVM (also mentioned on the wiki page):
> vif =3D [ 'mac=3D00:16:5e:02:07:45, bridge=3Dxenbr0, model=3De1000' ]
> =

> So there's no need for "type=3Dioemu" option with xm/xend.
> =

> You can switch between HVM and PVHVM with:
> xen_platform_pci=3D0|1
> =

> -- Pasi
> =


It seems that this works (without the model, too) for xm and xl. So even wi=
thout
explicitly saying type=3Dioemu, there is an emulated device created. And if=
 the
platform device is enabled, the emulated devices are unplugged by default.
So it sounds like "type=3Dioemu" is not only not needed but hurts in the on=
e case
of xm. Would it make sense to completely remove it from the example configs?

-Stefan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 14:35:05 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 14:35:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXZcn-0006z8-NJ; Mon, 05 Dec 2011 14:34:33 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <stefan.bader@canonical.com>) id 1RXZcm-0006z0-JA
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 14:34:32 +0000
X-Env-Sender: stefan.bader@canonical.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1323095628!1277138!1
X-Originating-IP: [91.189.89.112]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23869 invoked from network); 5 Dec 2011 14:33:48 -0000
Received: from youngberry.canonical.com (HELO youngberry.canonical.com)
	(91.189.89.112) by server-2.tower-21.messagelabs.com with SMTP;
	5 Dec 2011 14:33:48 -0000
Received: from p5b2e58f2.dip.t-dialin.net ([91.46.88.242] helo=[192.168.2.5])
	by youngberry.canonical.com with esmtpsa
	(TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71)
	(envelope-from <stefan.bader@canonical.com>)
	id 1RXZc2-0002Uu-VP; Mon, 05 Dec 2011 14:33:47 +0000
Message-ID: <4EDCD649.8050108@canonical.com>
Date: Mon, 05 Dec 2011 15:33:45 +0100
From: Stefan Bader <stefan.bader@canonical.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:8.0) Gecko/20111124 Thunderbird/8.0
MIME-Version: 1.0
To: =?ISO-8859-1?Q?Pasi_K=E4rkk=E4inen?= <pasik@iki.fi>
References: <4ED798B2.1040309@canonical.com>
	<20111201180944.GH12984@reaktio.net>
	<4ED8A45A.3050403@canonical.com>
	<20111202104110.GL12984@reaktio.net>
In-Reply-To: <20111202104110.GL12984@reaktio.net>
X-Enigmail-Version: 1.4a1pre
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Xen 4.x / Linux 3.x (dom0 and HVM domU) and NIC
	handling
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 02.12.2011 11:41, Pasi K=E4rkk=E4inen wrote:
> On Fri, Dec 02, 2011 at 11:11:38AM +0100, Stefan Bader wrote:
>> On 01.12.2011 19:09, Pasi K=E4rkk=E4inen wrote:
>>> On Thu, Dec 01, 2011 at 04:09:38PM +0100, Stefan Bader wrote:
>>>> Moving to public discussion...
>>>>
>>>> This was found with Xen hypervisor version supporting device unpluggin=
g and the
>>>> domU kernel having net-/blkfront and pci platform built-in (or as modu=
le).
>>>>
>>>> The block device is defined as hda and the NIC type=3Dioemu (so theore=
tically
>>>> guests without pv support would work, too).
>>>>
>>>> Since both drivers are present, the kernel tries to unplug the emulate=
d devices
>>>> and succeeds. The blkfront driver detects the xvda device available in=
 parallel
>>>> and is working ok.
>>>>
>>>> However the network interface does not work. There are entries present=
 under
>>>> sysfs for the xenbus but trying to bring it up fails with errors. And =
also there
>>>> seems to be no mac address set (all zeros in sysfs).
>>>> When the type=3Dioemu is removed in the configuration, this works.
>>>>
>>>> I have not much more debugging information beyond that, yet. But it so=
unds a bit
>>>> like NICs should behave the same as block devices. So if there is an e=
mulated
>>>> device defined there will be an alternate paravirt interface for it an=
d after
>>>> unplugging the emulated ones we end up with the pv ones.
>>>> Is that something that can be seen with newer Xen versions, too (I am =
using 4.1.1)?
>>>>
>>>
>>> Hey,
>>>
>>> Have you seen?: =

>>> http://wiki.xen.org/xenwiki/XenLinuxPVonHVMdrivers
>>>
>>> Especially the following note:
>>> "NOTE! If you have "type=3Dioemu" specified for the "vif"-line, PVHVM d=
rivers WILL NOT work! Don't specify "type" parameter for the vif. (with typ=
e=3Dioemu the pvhvm nic in the VM will have mac address full of zeroes - an=
d thus won't work!)."
>>>
>>> "type=3Dioemu" is not needed, at least with xm/xend toolstack both HVM =
and PVHVM guests work OK without it.
>>>
>>> -- Pasi
>>>
>> Thanks Pasi,
>>
>> hmm, so it is documented actually and thus sort of expected. Still it is
>> confusing. For one driver it does not make a difference to use the form =
of an
>> emulated device in the config, for the other it does. The xl stack works=
, the xm
>> stack does not.
>> And then, ok this is probably a quite naive approach, it seemed to make =
sense to
>> go through the pain of always having potentially both interfaces availab=
le
>> (emulated and pv) so in theory the same guest config can accommodate a g=
uest os
>> supporting one or the other (or easily switch from one to the other). Ot=
herwise
>> I would expect an emulated device only when I have hd? in the config and=
 a pv
>> device when I write xvd?.
>>
> =

> This works for both HVM and PVHVM (also mentioned on the wiki page):
> vif =3D [ 'mac=3D00:16:5e:02:07:45, bridge=3Dxenbr0, model=3De1000' ]
> =

> So there's no need for "type=3Dioemu" option with xm/xend.
> =

> You can switch between HVM and PVHVM with:
> xen_platform_pci=3D0|1
> =

> -- Pasi
> =


It seems that this works (without the model, too) for xm and xl. So even wi=
thout
explicitly saying type=3Dioemu, there is an emulated device created. And if=
 the
platform device is enabled, the emulated devices are unplugged by default.
So it sounds like "type=3Dioemu" is not only not needed but hurts in the on=
e case
of xm. Would it make sense to completely remove it from the example configs?

-Stefan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 14:40:01 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 14:40:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXZhj-00078m-Ko; Mon, 05 Dec 2011 14:39:39 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RXZhi-00078b-3H
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 14:39:38 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1323095933!4299835!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjAyNg==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27621 invoked from network); 5 Dec 2011 14:38:53 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Dec 2011 14:38:53 -0000
X-IronPort-AV: E=Sophos;i="4.71,299,1320624000"; 
   d="scan'208";a="9292360"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Dec 2011 14:38:52 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 5 Dec 2011 14:38:52 +0000
Date: Mon, 5 Dec 2011 14:39:54 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Stefan Bader <stefan.bader@canonical.com>
In-Reply-To: <4EDCD649.8050108@canonical.com>
Message-ID: <alpine.DEB.2.00.1112051439450.31179@kaball-desktop>
References: <4ED798B2.1040309@canonical.com>
	<20111201180944.GH12984@reaktio.net>
	<4ED8A45A.3050403@canonical.com>
	<20111202104110.GL12984@reaktio.net>
	<4EDCD649.8050108@canonical.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Xen 4.x / Linux 3.x (dom0 and HVM domU) and NIC
 handling
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 5 Dec 2011, Stefan Bader wrote:
> It seems that this works (without the model, too) for xm and xl. So even without
> explicitly saying type=ioemu, there is an emulated device created. And if the
> platform device is enabled, the emulated devices are unplugged by default.
> So it sounds like "type=ioemu" is not only not needed but hurts in the one case
> of xm. Would it make sense to completely remove it from the example configs?

I think it would

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 14:40:01 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 14:40:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXZhj-00078m-Ko; Mon, 05 Dec 2011 14:39:39 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RXZhi-00078b-3H
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 14:39:38 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1323095933!4299835!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjAyNg==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27621 invoked from network); 5 Dec 2011 14:38:53 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Dec 2011 14:38:53 -0000
X-IronPort-AV: E=Sophos;i="4.71,299,1320624000"; 
   d="scan'208";a="9292360"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Dec 2011 14:38:52 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 5 Dec 2011 14:38:52 +0000
Date: Mon, 5 Dec 2011 14:39:54 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Stefan Bader <stefan.bader@canonical.com>
In-Reply-To: <4EDCD649.8050108@canonical.com>
Message-ID: <alpine.DEB.2.00.1112051439450.31179@kaball-desktop>
References: <4ED798B2.1040309@canonical.com>
	<20111201180944.GH12984@reaktio.net>
	<4ED8A45A.3050403@canonical.com>
	<20111202104110.GL12984@reaktio.net>
	<4EDCD649.8050108@canonical.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Xen 4.x / Linux 3.x (dom0 and HVM domU) and NIC
 handling
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 5 Dec 2011, Stefan Bader wrote:
> It seems that this works (without the model, too) for xm and xl. So even without
> explicitly saying type=ioemu, there is an emulated device created. And if the
> platform device is enabled, the emulated devices are unplugged by default.
> So it sounds like "type=ioemu" is not only not needed but hurts in the one case
> of xm. Would it make sense to completely remove it from the example configs?

I think it would

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 14:51:00 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 14:51:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXZs8-0007LF-RW; Mon, 05 Dec 2011 14:50:24 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1RXZs7-0007LA-TU
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 14:50:24 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1323096578!4286129!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMjkyOTA3\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26546 invoked from network); 5 Dec 2011 14:49:39 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-2.tower-174.messagelabs.com with SMTP;
	5 Dec 2011 14:49:39 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga101.jf.intel.com with ESMTP; 05 Dec 2011 06:49:38 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.67,352,1309762800"; d="scan'208";a="83005019"
Received: from pgsmsx601.gar.corp.intel.com ([10.221.43.69])
	by orsmga001.jf.intel.com with ESMTP; 05 Dec 2011 06:49:37 -0800
Received: from shsmsx601.ccr.corp.intel.com (10.239.4.112) by
	pgsmsx601.gar.corp.intel.com (10.221.43.69) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Mon, 5 Dec 2011 22:49:36 +0800
Received: from shsmsx502.ccr.corp.intel.com ([10.239.4.96]) by
	shsmsx601.ccr.corp.intel.com ([10.239.4.112]) with mapi; Mon, 5 Dec 2011
	22:49:34 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Mon, 5 Dec 2011 22:49:33 +0800
Thread-Topic: [Xen-devel] [PATCH] X86 MCE: Add more strict sanity check of
	one SRAR case
Thread-Index: AcyzUM/17giQjmmcTLi944f0aRXI0wADDxXg
Message-ID: <BC00F5384FCFC9499AF06F92E8B78A9E2870CA7A68@shsmsx502.ccr.corp.intel.com>
References: <BC00F5384FCFC9499AF06F92E8B78A9E2870BB484D@shsmsx502.ccr.corp.intel.com>
	<BC00F5384FCFC9499AF06F92E8B78A9E2870CA7A13@shsmsx502.ccr.corp.intel.com>
	<4EDCD36302000078000656E7@nat28.tlf.novell.com>
In-Reply-To: <4EDCD36302000078000656E7@nat28.tlf.novell.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "keir.xen@gmail.com" <keir.xen@gmail.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Jiang, Yunhong" <yunhong.jiang@intel.com>
Subject: Re: [Xen-devel] [PATCH] X86 MCE: Add more strict sanity check of
 one SRAR case
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Jan Beulich wrote:
>>>> On 05.12.11 at 14:09, "Liu, Jinsong" <jinsong.liu@intel.com> wrote:
>> Attached is the email we discuss last month, and 2 mce patches:
>> srar-1.patch is the patch we discussed before,
>> srar-guest-mode.patch is an additional patch w/ more strict sanity
>> checkof RIPV = EIPV = 0. Any comments please let me know.
> 
> I'll get to commit these once the current set of regressions cleared.
> 
> Thanks for sending the original patch again (saves me from having to
> dig it out of the list archives).
> 
> Jan

Thanks, Jan :)
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 14:51:00 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 14:51:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXZs8-0007LF-RW; Mon, 05 Dec 2011 14:50:24 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1RXZs7-0007LA-TU
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 14:50:24 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1323096578!4286129!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMjkyOTA3\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26546 invoked from network); 5 Dec 2011 14:49:39 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-2.tower-174.messagelabs.com with SMTP;
	5 Dec 2011 14:49:39 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga101.jf.intel.com with ESMTP; 05 Dec 2011 06:49:38 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.67,352,1309762800"; d="scan'208";a="83005019"
Received: from pgsmsx601.gar.corp.intel.com ([10.221.43.69])
	by orsmga001.jf.intel.com with ESMTP; 05 Dec 2011 06:49:37 -0800
Received: from shsmsx601.ccr.corp.intel.com (10.239.4.112) by
	pgsmsx601.gar.corp.intel.com (10.221.43.69) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Mon, 5 Dec 2011 22:49:36 +0800
Received: from shsmsx502.ccr.corp.intel.com ([10.239.4.96]) by
	shsmsx601.ccr.corp.intel.com ([10.239.4.112]) with mapi; Mon, 5 Dec 2011
	22:49:34 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Mon, 5 Dec 2011 22:49:33 +0800
Thread-Topic: [Xen-devel] [PATCH] X86 MCE: Add more strict sanity check of
	one SRAR case
Thread-Index: AcyzUM/17giQjmmcTLi944f0aRXI0wADDxXg
Message-ID: <BC00F5384FCFC9499AF06F92E8B78A9E2870CA7A68@shsmsx502.ccr.corp.intel.com>
References: <BC00F5384FCFC9499AF06F92E8B78A9E2870BB484D@shsmsx502.ccr.corp.intel.com>
	<BC00F5384FCFC9499AF06F92E8B78A9E2870CA7A13@shsmsx502.ccr.corp.intel.com>
	<4EDCD36302000078000656E7@nat28.tlf.novell.com>
In-Reply-To: <4EDCD36302000078000656E7@nat28.tlf.novell.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "keir.xen@gmail.com" <keir.xen@gmail.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Jiang, Yunhong" <yunhong.jiang@intel.com>
Subject: Re: [Xen-devel] [PATCH] X86 MCE: Add more strict sanity check of
 one SRAR case
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Jan Beulich wrote:
>>>> On 05.12.11 at 14:09, "Liu, Jinsong" <jinsong.liu@intel.com> wrote:
>> Attached is the email we discuss last month, and 2 mce patches:
>> srar-1.patch is the patch we discussed before,
>> srar-guest-mode.patch is an additional patch w/ more strict sanity
>> checkof RIPV = EIPV = 0. Any comments please let me know.
> 
> I'll get to commit these once the current set of regressions cleared.
> 
> Thanks for sending the original patch again (saves me from having to
> dig it out of the list archives).
> 
> Jan

Thanks, Jan :)
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 14:54:06 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 14:54:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXZvO-0007RX-Fa; Mon, 05 Dec 2011 14:53:46 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RXZvM-0007RL-M0
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 14:53:44 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1323096779!4271187!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjAyNg==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3549 invoked from network); 5 Dec 2011 14:53:00 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Dec 2011 14:53:00 -0000
X-IronPort-AV: E=Sophos;i="4.71,299,1320624000"; 
   d="scan'208";a="9292757"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Dec 2011 14:52:36 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 5 Dec 2011 14:52:36 +0000
Date: Mon, 5 Dec 2011 14:53:47 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1323093585.29870.192.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1112051440170.31179@kaball-desktop>
References: <alpine.DEB.2.00.1112051053180.31179@kaball-desktop>
	<1323093585.29870.192.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] qemu_timer_pending/qemu_get_timer: cope with NULL
 timers
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 5 Dec 2011, Ian Campbell wrote:
> On Mon, 2011-12-05 at 10:54 +0000, Stefano Stabellini wrote:
> > qemu_timer_pending and qemu_get_timer: don't crash if the timer passed
> > as an argument is NULL.
> 
> It would have been useful to mention why a NULL timer is valid here.
> Apart from just being good changelog practice to explain the actual
> reason for a change this would also help tell us why this issue isn't
> being solved further up the stack. One the face of it this seem like
> this ought to be a bug in the caller of qemu_mod_timer.

Yes, I have been a little bit too concise.

qemu_mod_timer is not the only caller of
qemu_timer_pending/qemu_get_timer: they are also called by some qemu
save/restore related functions, where the timer being saved and restored
can actually be NULL.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 14:54:06 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 14:54:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXZvO-0007RX-Fa; Mon, 05 Dec 2011 14:53:46 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RXZvM-0007RL-M0
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 14:53:44 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1323096779!4271187!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjAyNg==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3549 invoked from network); 5 Dec 2011 14:53:00 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Dec 2011 14:53:00 -0000
X-IronPort-AV: E=Sophos;i="4.71,299,1320624000"; 
   d="scan'208";a="9292757"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Dec 2011 14:52:36 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 5 Dec 2011 14:52:36 +0000
Date: Mon, 5 Dec 2011 14:53:47 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1323093585.29870.192.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1112051440170.31179@kaball-desktop>
References: <alpine.DEB.2.00.1112051053180.31179@kaball-desktop>
	<1323093585.29870.192.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] qemu_timer_pending/qemu_get_timer: cope with NULL
 timers
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 5 Dec 2011, Ian Campbell wrote:
> On Mon, 2011-12-05 at 10:54 +0000, Stefano Stabellini wrote:
> > qemu_timer_pending and qemu_get_timer: don't crash if the timer passed
> > as an argument is NULL.
> 
> It would have been useful to mention why a NULL timer is valid here.
> Apart from just being good changelog practice to explain the actual
> reason for a change this would also help tell us why this issue isn't
> being solved further up the stack. One the face of it this seem like
> this ought to be a bug in the caller of qemu_mod_timer.

Yes, I have been a little bit too concise.

qemu_mod_timer is not the only caller of
qemu_timer_pending/qemu_get_timer: they are also called by some qemu
save/restore related functions, where the timer being saved and restored
can actually be NULL.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 14:57:18 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 14: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.xensource.com>)
	id 1RXZyB-0007aE-2b; Mon, 05 Dec 2011 14:56:39 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <stefan.bader@canonical.com>) id 1RXZy8-0007Zx-VR
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 14:56:37 +0000
X-Env-Sender: stefan.bader@canonical.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1323096952!5412432!1
X-Originating-IP: [91.189.89.112]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4521 invoked from network); 5 Dec 2011 14:55:52 -0000
Received: from youngberry.canonical.com (HELO youngberry.canonical.com)
	(91.189.89.112) by server-13.tower-182.messagelabs.com with SMTP;
	5 Dec 2011 14:55:52 -0000
Received: from p5b2e58f2.dip.t-dialin.net ([91.46.88.242] helo=[192.168.2.5])
	by youngberry.canonical.com with esmtpsa
	(TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71)
	(envelope-from <stefan.bader@canonical.com>)
	id 1RXZxO-0003LQ-Tp; Mon, 05 Dec 2011 14:55:50 +0000
Message-ID: <4EDCDB75.6010403@canonical.com>
Date: Mon, 05 Dec 2011 15:55:49 +0100
From: Stefan Bader <stefan.bader@canonical.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:8.0) Gecko/20111124 Thunderbird/8.0
MIME-Version: 1.0
To: Alex Bligh <alex@alex.org.uk>
References: <4ED798B2.1040309@canonical.com>
	<20111201180944.GH12984@reaktio.net>	<4ED8A45A.3050403@canonical.com>
	<20111202104110.GL12984@reaktio.net>
	<BA1B675D85BDD87795D1666C@Ximines.local>
	<1322844048.29870.155.camel@zakaz.uk.xensource.com>
	<8D88C4D6C31A598129A942AD@Ximines.local>
In-Reply-To: <8D88C4D6C31A598129A942AD@Ximines.local>
X-Enigmail-Version: 1.4a1pre
Cc: xen-devel@lists.xensource.com, Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Xen 4.x / Linux 3.x (dom0 and HVM domU) and	NIC
	handling
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 02.12.2011 18:16, Alex Bligh wrote:
> 
> 
> --On 2 December 2011 16:40:48 +0000 Ian Campbell <Ian.Campbell@citrix.com> wrote:
> 
>>> AFAIK changing xen_platform_pci=0|1 will switch rather more than just
>>> the NIC. It will switch your disk too, instantly causing your previously
>>> happily booting OS to fail to boot as the root device name changes.
>>
>> We recommend you use "root=LABEL=foo" rather than "root=/dev/blah" for
>> this reason. Fortunately most distros use that scheme by default these
>> days.
> 
> Yes; and /etc/fstab. UUID= works too.
> 
> FWIW my experience is that various built-for-cloud type distros don't use
> that scheme, mainly because they use grub1 which IIRC does not support
> this, and building images in a non-root environment that have grub1
> in is rather easier than grub2. So, for instance, all the vm-builder
> stuff in debian/ubuntu used grub1 and did not work this way.
> 
> However, my point was that xen_platform_pci does not only change
> whether your net driver is emulated or PVHVM, but also whether your
> disk, and indeed everything else is emulated or PVHVM.
> 
I can understand a policy of using the pv devices whenever it is possible. The
change of the device name is there but as pointed out most distro installations
try to avoid those anyway since there is a similar problem with usb keys or
drives potentially moving around. Same for network devices that get mapped based
on mac address.
Not sure how real the need for a mixed setup is. If, then I can see that it gets
a bit weird. While you can use xen_emul_unplug with other keywords to prevent
unplugging disks or nics. But that would not remove the related pv devices. And
I am not sure whether this would be a desired behavior or actually be feasible
in a clean layered way. Personally I would think nobody could want both
interfaces at the same time but I would not assume I know all of the use cases.

-Stefan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 14:57:18 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 14: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.xensource.com>)
	id 1RXZyB-0007aE-2b; Mon, 05 Dec 2011 14:56:39 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <stefan.bader@canonical.com>) id 1RXZy8-0007Zx-VR
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 14:56:37 +0000
X-Env-Sender: stefan.bader@canonical.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1323096952!5412432!1
X-Originating-IP: [91.189.89.112]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4521 invoked from network); 5 Dec 2011 14:55:52 -0000
Received: from youngberry.canonical.com (HELO youngberry.canonical.com)
	(91.189.89.112) by server-13.tower-182.messagelabs.com with SMTP;
	5 Dec 2011 14:55:52 -0000
Received: from p5b2e58f2.dip.t-dialin.net ([91.46.88.242] helo=[192.168.2.5])
	by youngberry.canonical.com with esmtpsa
	(TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71)
	(envelope-from <stefan.bader@canonical.com>)
	id 1RXZxO-0003LQ-Tp; Mon, 05 Dec 2011 14:55:50 +0000
Message-ID: <4EDCDB75.6010403@canonical.com>
Date: Mon, 05 Dec 2011 15:55:49 +0100
From: Stefan Bader <stefan.bader@canonical.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:8.0) Gecko/20111124 Thunderbird/8.0
MIME-Version: 1.0
To: Alex Bligh <alex@alex.org.uk>
References: <4ED798B2.1040309@canonical.com>
	<20111201180944.GH12984@reaktio.net>	<4ED8A45A.3050403@canonical.com>
	<20111202104110.GL12984@reaktio.net>
	<BA1B675D85BDD87795D1666C@Ximines.local>
	<1322844048.29870.155.camel@zakaz.uk.xensource.com>
	<8D88C4D6C31A598129A942AD@Ximines.local>
In-Reply-To: <8D88C4D6C31A598129A942AD@Ximines.local>
X-Enigmail-Version: 1.4a1pre
Cc: xen-devel@lists.xensource.com, Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Xen 4.x / Linux 3.x (dom0 and HVM domU) and	NIC
	handling
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 02.12.2011 18:16, Alex Bligh wrote:
> 
> 
> --On 2 December 2011 16:40:48 +0000 Ian Campbell <Ian.Campbell@citrix.com> wrote:
> 
>>> AFAIK changing xen_platform_pci=0|1 will switch rather more than just
>>> the NIC. It will switch your disk too, instantly causing your previously
>>> happily booting OS to fail to boot as the root device name changes.
>>
>> We recommend you use "root=LABEL=foo" rather than "root=/dev/blah" for
>> this reason. Fortunately most distros use that scheme by default these
>> days.
> 
> Yes; and /etc/fstab. UUID= works too.
> 
> FWIW my experience is that various built-for-cloud type distros don't use
> that scheme, mainly because they use grub1 which IIRC does not support
> this, and building images in a non-root environment that have grub1
> in is rather easier than grub2. So, for instance, all the vm-builder
> stuff in debian/ubuntu used grub1 and did not work this way.
> 
> However, my point was that xen_platform_pci does not only change
> whether your net driver is emulated or PVHVM, but also whether your
> disk, and indeed everything else is emulated or PVHVM.
> 
I can understand a policy of using the pv devices whenever it is possible. The
change of the device name is there but as pointed out most distro installations
try to avoid those anyway since there is a similar problem with usb keys or
drives potentially moving around. Same for network devices that get mapped based
on mac address.
Not sure how real the need for a mixed setup is. If, then I can see that it gets
a bit weird. While you can use xen_emul_unplug with other keywords to prevent
unplugging disks or nics. But that would not remove the related pv devices. And
I am not sure whether this would be a desired behavior or actually be feasible
in a clean layered way. Personally I would think nobody could want both
interfaces at the same time but I would not assume I know all of the use cases.

-Stefan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 15:04:39 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 15:04:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXa5b-0007rY-0j; Mon, 05 Dec 2011 15:04:19 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <stefan.bader@canonical.com>) id 1RXa5Z-0007rS-Ix
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 15:04:17 +0000
X-Env-Sender: stefan.bader@canonical.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1323097412!4139274!1
X-Originating-IP: [91.189.89.112]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3248 invoked from network); 5 Dec 2011 15:03:32 -0000
Received: from youngberry.canonical.com (HELO youngberry.canonical.com)
	(91.189.89.112) by server-16.tower-174.messagelabs.com with SMTP;
	5 Dec 2011 15:03:32 -0000
Received: from p5b2e58f2.dip.t-dialin.net ([91.46.88.242] helo=[192.168.2.5])
	by youngberry.canonical.com with esmtpsa
	(TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71)
	(envelope-from <stefan.bader@canonical.com>)
	id 1RXa4p-0003jd-NT; Mon, 05 Dec 2011 15:03:31 +0000
Message-ID: <4EDCDD42.3050104@canonical.com>
Date: Mon, 05 Dec 2011 16:03:30 +0100
From: Stefan Bader <stefan.bader@canonical.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:8.0) Gecko/20111124 Thunderbird/8.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <4ED798B2.1040309@canonical.com>
	<20111201180944.GH12984@reaktio.net>	<4ED8A45A.3050403@canonical.com>
	<20111202104110.GL12984@reaktio.net>
	<BA1B675D85BDD87795D1666C@Ximines.local>
	<1322844048.29870.155.camel@zakaz.uk.xensource.com>
	<8D88C4D6C31A598129A942AD@Ximines.local>
	<1322847755.7376.45.camel@dagon.hellion.org.uk>
	<12E319EEAA44FEB965D8F001@Ximines.local>
	<1322909055.7376.56.camel@dagon.hellion.org.uk>
In-Reply-To: <1322909055.7376.56.camel@dagon.hellion.org.uk>
X-Enigmail-Version: 1.4a1pre
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Alex Bligh <alex@alex.org.uk>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Xen 4.x / Linux 3.x (dom0 and HVM domU) and	NIC
	handling
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 03.12.2011 11:44, Ian Campbell wrote:
> On Fri, 2011-12-02 at 18:32 +0000, Alex Bligh wrote:
>> Ian,
>>
>> --On 2 December 2011 17:42:35 +0000 Ian Campbell <Ian.Campbell@citrix.com> 
>> wrote:
>>
>>> Right.
>>>
>>>> FWIW my experience is that various built-for-cloud type distros don't use
>>>> that scheme, mainly because they use grub1 which IIRC does not support
>>>> this, and building images in a non-root environment that have grub1
>>>> in is rather easier than grub2.
>>>
>>> UUID= and LABEL= are functions of your initrd (actually udev) and not
>>> the bootloader. They work with both grub1 and grub2.
>>
>> I /think/ we might be slightly at cross purposes.
>>
>> At least when I was busy making images for Xen for PVHVM a couple of
>> years ago, the problem is roughly as follows:
>>
>> The boot loader needs to know what device to load the kernel and initrd 
>> from. To do this (roughly speaking) it needs to know what BIOS device to 
>> use. Of course it does not matter whether the boot loader uses the PV 
>> device or the emulated device, save that this requires the emulated device 
>> be present (at least whilst the boot loader doesn't support drivers for the 
>> pv device). The problem is that the device the boot loader accesses is in 
>> general specified in the boot loader configuration file not as a bios 
>> device number, but as a device name. Equally, it needs to know the device 
>> so that it can write the boot sector in order to reinstall the boot loader, 
>> set options etc. The problem we ran into here was that this needs to be set 
>> to xvda in order to to write the boot sector etc., because the sda device 
>> is unplugged. However, it only recognised a BIOS mapping for sda. So 
>> neither worked, without fiddling with mappings, but that wasn't possible on 
>> a straight install. For some reason, grub1 was far more forgiving.
> 
> grub-install /dev/xvdX is supposed to work just as well as
> grub-install /dev/sdX depending on which is currently active. If it does
> not then you have found a bug and this should be reported against the
> grub package in the distro you are using.
> 
> This was fixed in grub 1 in Debian Lenny (#456776) and grub2 in Debian
> Squeeze (#456777). The grub2 fixes are upstream however grub1 doesn't
> have an upstream so other distros may be missing this fix. If you find
> this please report it to them. Likewise if you find that this support
> has regressed in Debian (or Ubuntu) then please report those bugs to
> them.
> 
> Please don't just assume that because something is broken for you that
> this is the way it must be. Report bugs to the appropriate place and
> there is some chance that they will get fixed. Likewise if something was
> broken for you "years ago" please don't assume that it has remained so.
> 
>>>> So, for instance, all the vm-builder stuff in debian/ubuntu used grub1
>>>> and did not work this way.
>>>
>>> Which ones are these?
>>
>> EG:
>>  http://packages.ubuntu.com/search?keywords=ubuntu-vm-builder
>>  http://wiki.debian.org/VMBuilder
>>
>>> The Debian installer uses UUID where it can AFAIK. Ubuntu's installer is
>>> derived from Debian's so I'd expect it to be the same.
>>
>> There is more than one method of generating debian/ubuntu images
>> (debootstrap, multistrap, vmbuilder to name but 3). Some of these
>> run an installer, some just generate a working image for a particular
>> environment (and it's the latter which are problematic).
> 
> If a tools such as these are not correctly generating a PVHVM capable
> configuration when possible then IMHO that is a bug in those tools.
> Please report it to the tool authors as such.
> 
> If you cannot flip between PVHVM and emulated HVM easily then IMHO this
> is also a bug (although perhaps less serious) and should be reported as
> such, perhaps as a wishlist bug.
> 
>> FWIW my understanding is that though Ubuntu and Debian's installers both 
>> use the same underlying d-i stuff (or used to), they are now reasonably 
>> different (not that this has much bearing on the argument, as the main 
>> difference between the two is the kernel which has led to rather different 
>> results between the two); certainly which boot loader they use is
>> independent of the install architecture, their partitioning schemes
>> have been substantially different, and I would expect use of UUID/LABEL
>> not necessarily to correspond.
> 
> The Ubuntu installer folks are closely involved in Debian installer and
> in particular the folks who deal with bootloader type things on both
> sides are the same people.
> 
At least in my limited experiments, this was not any issue. Though any newer
installation uses grub2 and uuids. The grub stage was working most of the time
(beside initial interrupt related problems). It was more the missing pv modules
and the default to unplug emulated devices, that caused later stages to go not
so smoothly. And finding that there is a way to configure NICs that seems to
work in any combination of pci platform and tool stack sounds like a good way
forward. It just seems that sometimes there are a bit too many knobs to frob and
twiddle. ;)

-Stefan
> Ian.
> 
> 
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 15:04:39 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 15:04:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXa5b-0007rY-0j; Mon, 05 Dec 2011 15:04:19 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <stefan.bader@canonical.com>) id 1RXa5Z-0007rS-Ix
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 15:04:17 +0000
X-Env-Sender: stefan.bader@canonical.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1323097412!4139274!1
X-Originating-IP: [91.189.89.112]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3248 invoked from network); 5 Dec 2011 15:03:32 -0000
Received: from youngberry.canonical.com (HELO youngberry.canonical.com)
	(91.189.89.112) by server-16.tower-174.messagelabs.com with SMTP;
	5 Dec 2011 15:03:32 -0000
Received: from p5b2e58f2.dip.t-dialin.net ([91.46.88.242] helo=[192.168.2.5])
	by youngberry.canonical.com with esmtpsa
	(TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71)
	(envelope-from <stefan.bader@canonical.com>)
	id 1RXa4p-0003jd-NT; Mon, 05 Dec 2011 15:03:31 +0000
Message-ID: <4EDCDD42.3050104@canonical.com>
Date: Mon, 05 Dec 2011 16:03:30 +0100
From: Stefan Bader <stefan.bader@canonical.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:8.0) Gecko/20111124 Thunderbird/8.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <4ED798B2.1040309@canonical.com>
	<20111201180944.GH12984@reaktio.net>	<4ED8A45A.3050403@canonical.com>
	<20111202104110.GL12984@reaktio.net>
	<BA1B675D85BDD87795D1666C@Ximines.local>
	<1322844048.29870.155.camel@zakaz.uk.xensource.com>
	<8D88C4D6C31A598129A942AD@Ximines.local>
	<1322847755.7376.45.camel@dagon.hellion.org.uk>
	<12E319EEAA44FEB965D8F001@Ximines.local>
	<1322909055.7376.56.camel@dagon.hellion.org.uk>
In-Reply-To: <1322909055.7376.56.camel@dagon.hellion.org.uk>
X-Enigmail-Version: 1.4a1pre
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Alex Bligh <alex@alex.org.uk>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Xen 4.x / Linux 3.x (dom0 and HVM domU) and	NIC
	handling
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 03.12.2011 11:44, Ian Campbell wrote:
> On Fri, 2011-12-02 at 18:32 +0000, Alex Bligh wrote:
>> Ian,
>>
>> --On 2 December 2011 17:42:35 +0000 Ian Campbell <Ian.Campbell@citrix.com> 
>> wrote:
>>
>>> Right.
>>>
>>>> FWIW my experience is that various built-for-cloud type distros don't use
>>>> that scheme, mainly because they use grub1 which IIRC does not support
>>>> this, and building images in a non-root environment that have grub1
>>>> in is rather easier than grub2.
>>>
>>> UUID= and LABEL= are functions of your initrd (actually udev) and not
>>> the bootloader. They work with both grub1 and grub2.
>>
>> I /think/ we might be slightly at cross purposes.
>>
>> At least when I was busy making images for Xen for PVHVM a couple of
>> years ago, the problem is roughly as follows:
>>
>> The boot loader needs to know what device to load the kernel and initrd 
>> from. To do this (roughly speaking) it needs to know what BIOS device to 
>> use. Of course it does not matter whether the boot loader uses the PV 
>> device or the emulated device, save that this requires the emulated device 
>> be present (at least whilst the boot loader doesn't support drivers for the 
>> pv device). The problem is that the device the boot loader accesses is in 
>> general specified in the boot loader configuration file not as a bios 
>> device number, but as a device name. Equally, it needs to know the device 
>> so that it can write the boot sector in order to reinstall the boot loader, 
>> set options etc. The problem we ran into here was that this needs to be set 
>> to xvda in order to to write the boot sector etc., because the sda device 
>> is unplugged. However, it only recognised a BIOS mapping for sda. So 
>> neither worked, without fiddling with mappings, but that wasn't possible on 
>> a straight install. For some reason, grub1 was far more forgiving.
> 
> grub-install /dev/xvdX is supposed to work just as well as
> grub-install /dev/sdX depending on which is currently active. If it does
> not then you have found a bug and this should be reported against the
> grub package in the distro you are using.
> 
> This was fixed in grub 1 in Debian Lenny (#456776) and grub2 in Debian
> Squeeze (#456777). The grub2 fixes are upstream however grub1 doesn't
> have an upstream so other distros may be missing this fix. If you find
> this please report it to them. Likewise if you find that this support
> has regressed in Debian (or Ubuntu) then please report those bugs to
> them.
> 
> Please don't just assume that because something is broken for you that
> this is the way it must be. Report bugs to the appropriate place and
> there is some chance that they will get fixed. Likewise if something was
> broken for you "years ago" please don't assume that it has remained so.
> 
>>>> So, for instance, all the vm-builder stuff in debian/ubuntu used grub1
>>>> and did not work this way.
>>>
>>> Which ones are these?
>>
>> EG:
>>  http://packages.ubuntu.com/search?keywords=ubuntu-vm-builder
>>  http://wiki.debian.org/VMBuilder
>>
>>> The Debian installer uses UUID where it can AFAIK. Ubuntu's installer is
>>> derived from Debian's so I'd expect it to be the same.
>>
>> There is more than one method of generating debian/ubuntu images
>> (debootstrap, multistrap, vmbuilder to name but 3). Some of these
>> run an installer, some just generate a working image for a particular
>> environment (and it's the latter which are problematic).
> 
> If a tools such as these are not correctly generating a PVHVM capable
> configuration when possible then IMHO that is a bug in those tools.
> Please report it to the tool authors as such.
> 
> If you cannot flip between PVHVM and emulated HVM easily then IMHO this
> is also a bug (although perhaps less serious) and should be reported as
> such, perhaps as a wishlist bug.
> 
>> FWIW my understanding is that though Ubuntu and Debian's installers both 
>> use the same underlying d-i stuff (or used to), they are now reasonably 
>> different (not that this has much bearing on the argument, as the main 
>> difference between the two is the kernel which has led to rather different 
>> results between the two); certainly which boot loader they use is
>> independent of the install architecture, their partitioning schemes
>> have been substantially different, and I would expect use of UUID/LABEL
>> not necessarily to correspond.
> 
> The Ubuntu installer folks are closely involved in Debian installer and
> in particular the folks who deal with bootloader type things on both
> sides are the same people.
> 
At least in my limited experiments, this was not any issue. Though any newer
installation uses grub2 and uuids. The grub stage was working most of the time
(beside initial interrupt related problems). It was more the missing pv modules
and the default to unplug emulated devices, that caused later stages to go not
so smoothly. And finding that there is a way to configure NICs that seems to
work in any combination of pci platform and tool stack sounds like a good way
forward. It just seems that sometimes there are a bit too many knobs to frob and
twiddle. ;)

-Stefan
> Ian.
> 
> 
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 15:13:14 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 15:13:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXaDz-00083B-RI; Mon, 05 Dec 2011 15:12:59 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RXaDd-00081W-EO
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 15:12:57 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-3.tower-216.messagelabs.com!1323097911!6198049!1
X-Originating-IP: [208.97.132.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMDguOTcuMTMyLjgxID0+IDE4MTA4\n,sa_preprocessor: 
	QmFkIElQOiAyMDguOTcuMTMyLjgxID0+IDE4MTA4\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2894 invoked from network); 5 Dec 2011 15:11:52 -0000
Received: from caiajhbdcaib.dreamhost.com (HELO homiemail-a75.g.dreamhost.com)
	(208.97.132.81) by server-3.tower-216.messagelabs.com with SMTP;
	5 Dec 2011 15:11:52 -0000
Received: from homiemail-a75.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a75.g.dreamhost.com (Postfix) with ESMTP id 5165B5EC08C;
	Mon,  5 Dec 2011 07:11:51 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=mkkB6bheKZhUvihpKhiL8n3k2aVmltvzTYWbGUvuYGq0
	1kcnd4tLWfQ8WpyGsFF9bIa0RES8YWvKIcj5J5zVDy0EZ6F/uzuq/S0Y5d9Aukzs
	V5WMp+XS8H1inNpmOpXJyKXSqtdnemSWDApE9FexGe2X2Xbfi2qp5VNyXGe4uIY=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=f3sk50b69Bs23qQn2huLeda5I1Q=; b=IAiGusqsfCE
	75PMYpVdEWLZP0FqRanZJDSoZV7+dyz6uSDLC0by1jFw9bqARkaRn6w+nL5vS2Mh
	TzowZ+Ov7O1l3XCrlIBJjlzZQHJmK76NTy3ehlKREFZx0E2hO25mMx7RK+cZ4kgj
	4YqFw7Y1nbZ7iDQ88l/eIZcXJk6s8MXs=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a75.g.dreamhost.com (Postfix) with ESMTPSA id 97E3D5EC07C; 
	Mon,  5 Dec 2011 07:11:50 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 4c19931b40d5a0df6311af7a4d233c06650188d0
Message-Id: <4c19931b40d5a0df6311.1323097921@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1323097919@xdev.gridcentric.ca>
References: <patchbomb.1323097919@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Mon, 05 Dec 2011 10:12:01 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, keir.xen@gmail.com, tim@xen.org, olaf@aepfle.de,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 2 of 5] Create a generic callback mechanism for
 Xen-bound event channels
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/ia64/vmx/vmx_init.c |   2 +-
 xen/arch/x86/hvm/hvm.c       |   7 ++-
 xen/arch/x86/mm/mem_event.c  |   3 +-
 xen/common/event_channel.c   |  75 ++++++++++++++++++++++++++++++++++---------
 xen/include/xen/event.h      |   5 ++-
 xen/include/xen/sched.h      |   2 +-
 6 files changed, 70 insertions(+), 24 deletions(-)


For event channels for which Xen is the consumer, there currently is
a single action. With this patch, we allow event channel creators to
specify a generic callback (or no callback). Because the expectation
is that there will be few callbacks, they are stored in a small table.

Signed-off-by: Adin Scannell <adin@scannell.ca>
Signed-off-by: Keir Fraser <keir@xen.org>
Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 2a4ec2e2ae36 -r 4c19931b40d5 xen/arch/ia64/vmx/vmx_init.c
--- a/xen/arch/ia64/vmx/vmx_init.c
+++ b/xen/arch/ia64/vmx/vmx_init.c
@@ -377,7 +377,7 @@ vmx_vcpu_initialise(struct vcpu *v)
 {
 	struct vmx_ioreq_page *iorp = &v->domain->arch.hvm_domain.ioreq;
 
-	int rc = alloc_unbound_xen_event_channel(v, 0);
+	int rc = alloc_unbound_xen_event_channel(v, 0, NULL);
 	if (rc < 0)
 		return rc;
 	v->arch.arch_vmx.xen_port = rc;
diff -r 2a4ec2e2ae36 -r 4c19931b40d5 xen/arch/x86/hvm/hvm.c
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -979,7 +979,7 @@ int hvm_vcpu_initialise(struct vcpu *v)
         goto fail3;
 
     /* Create ioreq event channel. */
-    rc = alloc_unbound_xen_event_channel(v, 0);
+    rc = alloc_unbound_xen_event_channel(v, 0, NULL);
     if ( rc < 0 )
         goto fail4;
 
@@ -989,7 +989,7 @@ int hvm_vcpu_initialise(struct vcpu *v)
     if ( v->vcpu_id == 0 )
     {
         /* Create bufioreq event channel. */
-        rc = alloc_unbound_xen_event_channel(v, 0);
+        rc = alloc_unbound_xen_event_channel(v, 0, NULL);
         if ( rc < 0 )
             goto fail2;
         v->domain->arch.hvm_domain.params[HVM_PARAM_BUFIOREQ_EVTCHN] = rc;
@@ -3561,7 +3561,8 @@ long do_hvm_op(unsigned long op, XEN_GUE
                 for_each_vcpu ( d, v )
                 {
                     int old_port, new_port;
-                    new_port = alloc_unbound_xen_event_channel(v, a.value);
+                    new_port = alloc_unbound_xen_event_channel(
+                        v, a.value, NULL);
                     if ( new_port < 0 )
                     {
                         rc = new_port;
diff -r 2a4ec2e2ae36 -r 4c19931b40d5 xen/arch/x86/mm/mem_event.c
--- a/xen/arch/x86/mm/mem_event.c
+++ b/xen/arch/x86/mm/mem_event.c
@@ -93,7 +93,8 @@ static int mem_event_enable(struct domai
 
     /* Allocate event channel */
     rc = alloc_unbound_xen_event_channel(d->vcpu[0],
-                                         current->domain->domain_id);
+                                         current->domain->domain_id,
+                                         NULL);
     if ( rc < 0 )
         goto err;
 
diff -r 2a4ec2e2ae36 -r 4c19931b40d5 xen/common/event_channel.c
--- a/xen/common/event_channel.c
+++ b/xen/common/event_channel.c
@@ -57,6 +57,51 @@
         goto out;                                                   \
     } while ( 0 )
 
+#define consumer_is_xen(e) (!!(e)->xen_consumer)
+
+/*
+ * The function alloc_unbound_xen_event_channel() allows an arbitrary
+ * notifier function to be specified. However, very few unique functions
+ * are specified in practice, so to prevent bloating the evtchn structure
+ * with a pointer, we stash them dynamically in a small lookup array which
+ * can be indexed by a small integer.
+ */
+static xen_event_channel_notification_t xen_consumers[8];
+
+/* Default notification action: wake up from wait_on_xen_event_channel(). */
+static void default_xen_notification_fn(struct vcpu *v, unsigned int port)
+{
+    /* Consumer needs notification only if blocked. */
+    if ( test_and_clear_bit(_VPF_blocked_in_xen, &v->pause_flags) )
+        vcpu_wake(v);
+}
+
+/*
+ * Given a notification function, return the value to stash in
+ * the evtchn->xen_consumer field.
+ */
+static uint8_t get_xen_consumer(xen_event_channel_notification_t fn)
+{
+    unsigned int i;
+
+    if ( fn == NULL )
+        fn = default_xen_notification_fn;
+
+    for ( i = 0; i < ARRAY_SIZE(xen_consumers); i++ )
+    {
+        if ( xen_consumers[i] == NULL )
+            xen_consumers[i] = fn;
+        if ( xen_consumers[i] == fn )
+            break;
+    }
+
+    BUG_ON(i >= ARRAY_SIZE(xen_consumers));
+    return i+1;
+}
+
+/* Get the notification function for a given Xen-bound event channel. */
+#define xen_notification_fn(e) (xen_consumers[(e)->xen_consumer-1])
+
 static int evtchn_set_pending(struct vcpu *v, int port);
 
 static int virq_is_global(int virq)
@@ -397,7 +442,7 @@ static long __evtchn_close(struct domain
     chn1 = evtchn_from_port(d1, port1);
 
     /* Guest cannot close a Xen-attached event channel. */
-    if ( unlikely(chn1->consumer_is_xen) )
+    if ( unlikely(consumer_is_xen(chn1)) )
     {
         rc = -EINVAL;
         goto out;
@@ -537,7 +582,7 @@ int evtchn_send(struct domain *d, unsign
     lchn = evtchn_from_port(ld, lport);
 
     /* Guest cannot send via a Xen-attached event channel. */
-    if ( unlikely(lchn->consumer_is_xen) )
+    if ( unlikely(consumer_is_xen(lchn)) )
     {
         spin_unlock(&ld->event_lock);
         return -EINVAL;
@@ -554,13 +599,8 @@ int evtchn_send(struct domain *d, unsign
         rport = lchn->u.interdomain.remote_port;
         rchn  = evtchn_from_port(rd, rport);
         rvcpu = rd->vcpu[rchn->notify_vcpu_id];
-        if ( rchn->consumer_is_xen )
-        {
-            /* Xen consumers need notification only if they are blocked. */
-            if ( test_and_clear_bit(_VPF_blocked_in_xen,
-                                    &rvcpu->pause_flags) )
-                vcpu_wake(rvcpu);
-        }
+        if ( consumer_is_xen(rchn) )
+            (*xen_notification_fn(rchn))(rvcpu, rport);
         else
         {
             evtchn_set_pending(rvcpu, rport);
@@ -787,7 +827,7 @@ long evtchn_bind_vcpu(unsigned int port,
     chn = evtchn_from_port(d, port);
 
     /* Guest cannot re-bind a Xen-attached event channel. */
-    if ( unlikely(chn->consumer_is_xen) )
+    if ( unlikely(consumer_is_xen(chn)) )
     {
         rc = -EINVAL;
         goto out;
@@ -998,7 +1038,8 @@ long do_event_channel_op(int cmd, XEN_GU
 
 
 int alloc_unbound_xen_event_channel(
-    struct vcpu *local_vcpu, domid_t remote_domid)
+    struct vcpu *local_vcpu, domid_t remote_domid,
+    xen_event_channel_notification_t notification_fn)
 {
     struct evtchn *chn;
     struct domain *d = local_vcpu->domain;
@@ -1011,7 +1052,7 @@ int alloc_unbound_xen_event_channel(
     chn = evtchn_from_port(d, port);
 
     chn->state = ECS_UNBOUND;
-    chn->consumer_is_xen = 1;
+    chn->xen_consumer = get_xen_consumer(notification_fn);
     chn->notify_vcpu_id = local_vcpu->vcpu_id;
     chn->u.unbound.remote_domid = remote_domid;
 
@@ -1038,8 +1079,8 @@ void free_xen_event_channel(
 
     BUG_ON(!port_is_valid(d, port));
     chn = evtchn_from_port(d, port);
-    BUG_ON(!chn->consumer_is_xen);
-    chn->consumer_is_xen = 0;
+    BUG_ON(!consumer_is_xen(chn));
+    chn->xen_consumer = 0;
 
     spin_unlock(&d->event_lock);
 
@@ -1063,7 +1104,7 @@ void notify_via_xen_event_channel(struct
 
     ASSERT(port_is_valid(ld, lport));
     lchn = evtchn_from_port(ld, lport);
-    ASSERT(lchn->consumer_is_xen);
+    ASSERT(consumer_is_xen(lchn));
 
     if ( likely(lchn->state == ECS_INTERDOMAIN) )
     {
@@ -1106,7 +1147,7 @@ void evtchn_destroy(struct domain *d)
     /* Close all existing event channels. */
     for ( i = 0; port_is_valid(d, i); i++ )
     {
-        evtchn_from_port(d, i)->consumer_is_xen = 0;
+        evtchn_from_port(d, i)->xen_consumer = 0;
         (void)__evtchn_close(d, i);
     }
 
@@ -1192,7 +1233,7 @@ static void domain_dump_evtchn_info(stru
             printk(" v=%d", chn->u.virq);
             break;
         }
-        printk(" x=%d\n", chn->consumer_is_xen);
+        printk(" x=%d\n", chn->xen_consumer);
     }
 
     spin_unlock(&d->event_lock);
diff -r 2a4ec2e2ae36 -r 4c19931b40d5 xen/include/xen/event.h
--- a/xen/include/xen/event.h
+++ b/xen/include/xen/event.h
@@ -51,8 +51,11 @@ int evtchn_unmask(unsigned int port);
 void evtchn_move_pirqs(struct vcpu *v);
 
 /* Allocate/free a Xen-attached event channel port. */
+typedef void (*xen_event_channel_notification_t)(
+    struct vcpu *v, unsigned int port);
 int alloc_unbound_xen_event_channel(
-    struct vcpu *local_vcpu, domid_t remote_domid);
+    struct vcpu *local_vcpu, domid_t remote_domid,
+    xen_event_channel_notification_t notification_fn);
 void free_xen_event_channel(
     struct vcpu *local_vcpu, int port);
 
diff -r 2a4ec2e2ae36 -r 4c19931b40d5 xen/include/xen/sched.h
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -47,7 +47,7 @@ struct evtchn
 #define ECS_VIRQ         5 /* Channel is bound to a virtual IRQ line.        */
 #define ECS_IPI          6 /* Channel is bound to a virtual IPI line.        */
     u8  state;             /* ECS_* */
-    u8  consumer_is_xen;   /* Consumed by Xen or by guest? */
+    u8  xen_consumer;      /* Consumer in Xen, if any? (0 = send to guest) */
     u16 notify_vcpu_id;    /* VCPU for local delivery notification */
     union {
         struct {

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 15:13:14 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 15:13:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXaDz-00083B-RI; Mon, 05 Dec 2011 15:12:59 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RXaDd-00081W-EO
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 15:12:57 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-3.tower-216.messagelabs.com!1323097911!6198049!1
X-Originating-IP: [208.97.132.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMDguOTcuMTMyLjgxID0+IDE4MTA4\n,sa_preprocessor: 
	QmFkIElQOiAyMDguOTcuMTMyLjgxID0+IDE4MTA4\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2894 invoked from network); 5 Dec 2011 15:11:52 -0000
Received: from caiajhbdcaib.dreamhost.com (HELO homiemail-a75.g.dreamhost.com)
	(208.97.132.81) by server-3.tower-216.messagelabs.com with SMTP;
	5 Dec 2011 15:11:52 -0000
Received: from homiemail-a75.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a75.g.dreamhost.com (Postfix) with ESMTP id 5165B5EC08C;
	Mon,  5 Dec 2011 07:11:51 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=mkkB6bheKZhUvihpKhiL8n3k2aVmltvzTYWbGUvuYGq0
	1kcnd4tLWfQ8WpyGsFF9bIa0RES8YWvKIcj5J5zVDy0EZ6F/uzuq/S0Y5d9Aukzs
	V5WMp+XS8H1inNpmOpXJyKXSqtdnemSWDApE9FexGe2X2Xbfi2qp5VNyXGe4uIY=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=f3sk50b69Bs23qQn2huLeda5I1Q=; b=IAiGusqsfCE
	75PMYpVdEWLZP0FqRanZJDSoZV7+dyz6uSDLC0by1jFw9bqARkaRn6w+nL5vS2Mh
	TzowZ+Ov7O1l3XCrlIBJjlzZQHJmK76NTy3ehlKREFZx0E2hO25mMx7RK+cZ4kgj
	4YqFw7Y1nbZ7iDQ88l/eIZcXJk6s8MXs=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a75.g.dreamhost.com (Postfix) with ESMTPSA id 97E3D5EC07C; 
	Mon,  5 Dec 2011 07:11:50 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 4c19931b40d5a0df6311af7a4d233c06650188d0
Message-Id: <4c19931b40d5a0df6311.1323097921@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1323097919@xdev.gridcentric.ca>
References: <patchbomb.1323097919@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Mon, 05 Dec 2011 10:12:01 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, keir.xen@gmail.com, tim@xen.org, olaf@aepfle.de,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 2 of 5] Create a generic callback mechanism for
 Xen-bound event channels
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/ia64/vmx/vmx_init.c |   2 +-
 xen/arch/x86/hvm/hvm.c       |   7 ++-
 xen/arch/x86/mm/mem_event.c  |   3 +-
 xen/common/event_channel.c   |  75 ++++++++++++++++++++++++++++++++++---------
 xen/include/xen/event.h      |   5 ++-
 xen/include/xen/sched.h      |   2 +-
 6 files changed, 70 insertions(+), 24 deletions(-)


For event channels for which Xen is the consumer, there currently is
a single action. With this patch, we allow event channel creators to
specify a generic callback (or no callback). Because the expectation
is that there will be few callbacks, they are stored in a small table.

Signed-off-by: Adin Scannell <adin@scannell.ca>
Signed-off-by: Keir Fraser <keir@xen.org>
Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 2a4ec2e2ae36 -r 4c19931b40d5 xen/arch/ia64/vmx/vmx_init.c
--- a/xen/arch/ia64/vmx/vmx_init.c
+++ b/xen/arch/ia64/vmx/vmx_init.c
@@ -377,7 +377,7 @@ vmx_vcpu_initialise(struct vcpu *v)
 {
 	struct vmx_ioreq_page *iorp = &v->domain->arch.hvm_domain.ioreq;
 
-	int rc = alloc_unbound_xen_event_channel(v, 0);
+	int rc = alloc_unbound_xen_event_channel(v, 0, NULL);
 	if (rc < 0)
 		return rc;
 	v->arch.arch_vmx.xen_port = rc;
diff -r 2a4ec2e2ae36 -r 4c19931b40d5 xen/arch/x86/hvm/hvm.c
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -979,7 +979,7 @@ int hvm_vcpu_initialise(struct vcpu *v)
         goto fail3;
 
     /* Create ioreq event channel. */
-    rc = alloc_unbound_xen_event_channel(v, 0);
+    rc = alloc_unbound_xen_event_channel(v, 0, NULL);
     if ( rc < 0 )
         goto fail4;
 
@@ -989,7 +989,7 @@ int hvm_vcpu_initialise(struct vcpu *v)
     if ( v->vcpu_id == 0 )
     {
         /* Create bufioreq event channel. */
-        rc = alloc_unbound_xen_event_channel(v, 0);
+        rc = alloc_unbound_xen_event_channel(v, 0, NULL);
         if ( rc < 0 )
             goto fail2;
         v->domain->arch.hvm_domain.params[HVM_PARAM_BUFIOREQ_EVTCHN] = rc;
@@ -3561,7 +3561,8 @@ long do_hvm_op(unsigned long op, XEN_GUE
                 for_each_vcpu ( d, v )
                 {
                     int old_port, new_port;
-                    new_port = alloc_unbound_xen_event_channel(v, a.value);
+                    new_port = alloc_unbound_xen_event_channel(
+                        v, a.value, NULL);
                     if ( new_port < 0 )
                     {
                         rc = new_port;
diff -r 2a4ec2e2ae36 -r 4c19931b40d5 xen/arch/x86/mm/mem_event.c
--- a/xen/arch/x86/mm/mem_event.c
+++ b/xen/arch/x86/mm/mem_event.c
@@ -93,7 +93,8 @@ static int mem_event_enable(struct domai
 
     /* Allocate event channel */
     rc = alloc_unbound_xen_event_channel(d->vcpu[0],
-                                         current->domain->domain_id);
+                                         current->domain->domain_id,
+                                         NULL);
     if ( rc < 0 )
         goto err;
 
diff -r 2a4ec2e2ae36 -r 4c19931b40d5 xen/common/event_channel.c
--- a/xen/common/event_channel.c
+++ b/xen/common/event_channel.c
@@ -57,6 +57,51 @@
         goto out;                                                   \
     } while ( 0 )
 
+#define consumer_is_xen(e) (!!(e)->xen_consumer)
+
+/*
+ * The function alloc_unbound_xen_event_channel() allows an arbitrary
+ * notifier function to be specified. However, very few unique functions
+ * are specified in practice, so to prevent bloating the evtchn structure
+ * with a pointer, we stash them dynamically in a small lookup array which
+ * can be indexed by a small integer.
+ */
+static xen_event_channel_notification_t xen_consumers[8];
+
+/* Default notification action: wake up from wait_on_xen_event_channel(). */
+static void default_xen_notification_fn(struct vcpu *v, unsigned int port)
+{
+    /* Consumer needs notification only if blocked. */
+    if ( test_and_clear_bit(_VPF_blocked_in_xen, &v->pause_flags) )
+        vcpu_wake(v);
+}
+
+/*
+ * Given a notification function, return the value to stash in
+ * the evtchn->xen_consumer field.
+ */
+static uint8_t get_xen_consumer(xen_event_channel_notification_t fn)
+{
+    unsigned int i;
+
+    if ( fn == NULL )
+        fn = default_xen_notification_fn;
+
+    for ( i = 0; i < ARRAY_SIZE(xen_consumers); i++ )
+    {
+        if ( xen_consumers[i] == NULL )
+            xen_consumers[i] = fn;
+        if ( xen_consumers[i] == fn )
+            break;
+    }
+
+    BUG_ON(i >= ARRAY_SIZE(xen_consumers));
+    return i+1;
+}
+
+/* Get the notification function for a given Xen-bound event channel. */
+#define xen_notification_fn(e) (xen_consumers[(e)->xen_consumer-1])
+
 static int evtchn_set_pending(struct vcpu *v, int port);
 
 static int virq_is_global(int virq)
@@ -397,7 +442,7 @@ static long __evtchn_close(struct domain
     chn1 = evtchn_from_port(d1, port1);
 
     /* Guest cannot close a Xen-attached event channel. */
-    if ( unlikely(chn1->consumer_is_xen) )
+    if ( unlikely(consumer_is_xen(chn1)) )
     {
         rc = -EINVAL;
         goto out;
@@ -537,7 +582,7 @@ int evtchn_send(struct domain *d, unsign
     lchn = evtchn_from_port(ld, lport);
 
     /* Guest cannot send via a Xen-attached event channel. */
-    if ( unlikely(lchn->consumer_is_xen) )
+    if ( unlikely(consumer_is_xen(lchn)) )
     {
         spin_unlock(&ld->event_lock);
         return -EINVAL;
@@ -554,13 +599,8 @@ int evtchn_send(struct domain *d, unsign
         rport = lchn->u.interdomain.remote_port;
         rchn  = evtchn_from_port(rd, rport);
         rvcpu = rd->vcpu[rchn->notify_vcpu_id];
-        if ( rchn->consumer_is_xen )
-        {
-            /* Xen consumers need notification only if they are blocked. */
-            if ( test_and_clear_bit(_VPF_blocked_in_xen,
-                                    &rvcpu->pause_flags) )
-                vcpu_wake(rvcpu);
-        }
+        if ( consumer_is_xen(rchn) )
+            (*xen_notification_fn(rchn))(rvcpu, rport);
         else
         {
             evtchn_set_pending(rvcpu, rport);
@@ -787,7 +827,7 @@ long evtchn_bind_vcpu(unsigned int port,
     chn = evtchn_from_port(d, port);
 
     /* Guest cannot re-bind a Xen-attached event channel. */
-    if ( unlikely(chn->consumer_is_xen) )
+    if ( unlikely(consumer_is_xen(chn)) )
     {
         rc = -EINVAL;
         goto out;
@@ -998,7 +1038,8 @@ long do_event_channel_op(int cmd, XEN_GU
 
 
 int alloc_unbound_xen_event_channel(
-    struct vcpu *local_vcpu, domid_t remote_domid)
+    struct vcpu *local_vcpu, domid_t remote_domid,
+    xen_event_channel_notification_t notification_fn)
 {
     struct evtchn *chn;
     struct domain *d = local_vcpu->domain;
@@ -1011,7 +1052,7 @@ int alloc_unbound_xen_event_channel(
     chn = evtchn_from_port(d, port);
 
     chn->state = ECS_UNBOUND;
-    chn->consumer_is_xen = 1;
+    chn->xen_consumer = get_xen_consumer(notification_fn);
     chn->notify_vcpu_id = local_vcpu->vcpu_id;
     chn->u.unbound.remote_domid = remote_domid;
 
@@ -1038,8 +1079,8 @@ void free_xen_event_channel(
 
     BUG_ON(!port_is_valid(d, port));
     chn = evtchn_from_port(d, port);
-    BUG_ON(!chn->consumer_is_xen);
-    chn->consumer_is_xen = 0;
+    BUG_ON(!consumer_is_xen(chn));
+    chn->xen_consumer = 0;
 
     spin_unlock(&d->event_lock);
 
@@ -1063,7 +1104,7 @@ void notify_via_xen_event_channel(struct
 
     ASSERT(port_is_valid(ld, lport));
     lchn = evtchn_from_port(ld, lport);
-    ASSERT(lchn->consumer_is_xen);
+    ASSERT(consumer_is_xen(lchn));
 
     if ( likely(lchn->state == ECS_INTERDOMAIN) )
     {
@@ -1106,7 +1147,7 @@ void evtchn_destroy(struct domain *d)
     /* Close all existing event channels. */
     for ( i = 0; port_is_valid(d, i); i++ )
     {
-        evtchn_from_port(d, i)->consumer_is_xen = 0;
+        evtchn_from_port(d, i)->xen_consumer = 0;
         (void)__evtchn_close(d, i);
     }
 
@@ -1192,7 +1233,7 @@ static void domain_dump_evtchn_info(stru
             printk(" v=%d", chn->u.virq);
             break;
         }
-        printk(" x=%d\n", chn->consumer_is_xen);
+        printk(" x=%d\n", chn->xen_consumer);
     }
 
     spin_unlock(&d->event_lock);
diff -r 2a4ec2e2ae36 -r 4c19931b40d5 xen/include/xen/event.h
--- a/xen/include/xen/event.h
+++ b/xen/include/xen/event.h
@@ -51,8 +51,11 @@ int evtchn_unmask(unsigned int port);
 void evtchn_move_pirqs(struct vcpu *v);
 
 /* Allocate/free a Xen-attached event channel port. */
+typedef void (*xen_event_channel_notification_t)(
+    struct vcpu *v, unsigned int port);
 int alloc_unbound_xen_event_channel(
-    struct vcpu *local_vcpu, domid_t remote_domid);
+    struct vcpu *local_vcpu, domid_t remote_domid,
+    xen_event_channel_notification_t notification_fn);
 void free_xen_event_channel(
     struct vcpu *local_vcpu, int port);
 
diff -r 2a4ec2e2ae36 -r 4c19931b40d5 xen/include/xen/sched.h
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -47,7 +47,7 @@ struct evtchn
 #define ECS_VIRQ         5 /* Channel is bound to a virtual IRQ line.        */
 #define ECS_IPI          6 /* Channel is bound to a virtual IPI line.        */
     u8  state;             /* ECS_* */
-    u8  consumer_is_xen;   /* Consumed by Xen or by guest? */
+    u8  xen_consumer;      /* Consumer in Xen, if any? (0 = send to guest) */
     u16 notify_vcpu_id;    /* VCPU for local delivery notification */
     union {
         struct {

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 15:13:14 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 15:13:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXaDq-00081j-1T; Mon, 05 Dec 2011 15:12:50 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RXaDb-00081V-P9
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 15:12:48 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-6.tower-216.messagelabs.com!1323097910!6214585!1
X-Originating-IP: [208.97.132.145]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNDUgPT4gMTczMTg=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3251 invoked from network); 5 Dec 2011 15:11:51 -0000
Received: from caiajhbdcbef.dreamhost.com (HELO homiemail-a75.g.dreamhost.com)
	(208.97.132.145) by server-6.tower-216.messagelabs.com with SMTP;
	5 Dec 2011 15:11:51 -0000
Received: from homiemail-a75.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a75.g.dreamhost.com (Postfix) with ESMTP id 6688E5EC08B;
	Mon,  5 Dec 2011 07:11:50 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=NE1xDyISHUvxvlNKkFjMFRz0R2bwWh3hLyDTchc3dxxg
	tzAOjhG9kI47YmQBYqULZn9reqJeJ/c9+0dzA3wDWKAUSc8Ewz7WoKam8Cee8cey
	yDolIt/EVIGLNr2ZU8BoNjuptdGkRo+FEe2ULxGL2bS537Gau8iHizkes+RO31U=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=VgdgbeXxrdXJ0N204ZFPNiDQzVY=; b=AmIcioCjYIv
	fNm3SI2EIpFXy9TfTXwhfIV/8/3trIaYHV5vEv9lJyNIUPnF3tSmmiL5kCM/pigW
	17x6EkFU1SG+borSPL/f4j8nYM1fjvlGu3QwgwakkALrClvTY6AVmxSE9zzZzURj
	IaHS3Nc/6qCR/K6xMKL+TD1BAQ8McQ5g=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a75.g.dreamhost.com (Postfix) with ESMTPSA id A3FCE5EC07C; 
	Mon,  5 Dec 2011 07:11:49 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 2a4ec2e2ae36593aa74e306bb8400db53ec1e166
Message-Id: <2a4ec2e2ae36593aa74e.1323097920@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1323097919@xdev.gridcentric.ca>
References: <patchbomb.1323097919@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Mon, 05 Dec 2011 10:12:00 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, keir.xen@gmail.com, tim@xen.org, olaf@aepfle.de,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 1 of 5] Flag events caused by foreign domains
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/mm/mem_event.c    |  6 ++++++
 xen/include/public/mem_event.h |  1 +
 2 files changed, 7 insertions(+), 0 deletions(-)


Add a new flag for mem events, as consumers might need to discriminate
foreign domain-caused from guest-caused events. The vcpu field of an
event is bogus from a consumer p.o.v. for foreign domain-caused events.

Also assert that we shouldn't be pausing foreign vcpus.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla>

diff -r 8ad7af68e017 -r 2a4ec2e2ae36 xen/arch/x86/mm/mem_event.c
--- a/xen/arch/x86/mm/mem_event.c
+++ b/xen/arch/x86/mm/mem_event.c
@@ -143,6 +143,12 @@ void mem_event_put_request(struct domain
     front_ring = &med->front_ring;
     req_prod = front_ring->req_prod_pvt;
 
+    if ( current->domain != d )
+    {
+        req->flags |= MEM_EVENT_FLAG_FOREIGN;
+        ASSERT( !(req->flags & MEM_EVENT_FLAG_VCPU_PAUSED) );
+    }
+
     /* Copy request */
     memcpy(RING_GET_REQUEST(front_ring, req_prod), req, sizeof(*req));
     req_prod++;
diff -r 8ad7af68e017 -r 2a4ec2e2ae36 xen/include/public/mem_event.h
--- a/xen/include/public/mem_event.h
+++ b/xen/include/public/mem_event.h
@@ -39,6 +39,7 @@
 #define MEM_EVENT_FLAG_VCPU_PAUSED  (1 << 0)
 #define MEM_EVENT_FLAG_DROP_PAGE    (1 << 1)
 #define MEM_EVENT_FLAG_EVICT_FAIL   (1 << 2)
+#define MEM_EVENT_FLAG_FOREIGN      (1 << 3)
 
 /* Reasons for the memory event request */
 #define MEM_EVENT_REASON_UNKNOWN     0    /* typical reason */

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 15:13:14 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 15:13:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXaDq-00081j-1T; Mon, 05 Dec 2011 15:12:50 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RXaDb-00081V-P9
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 15:12:48 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-6.tower-216.messagelabs.com!1323097910!6214585!1
X-Originating-IP: [208.97.132.145]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNDUgPT4gMTczMTg=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3251 invoked from network); 5 Dec 2011 15:11:51 -0000
Received: from caiajhbdcbef.dreamhost.com (HELO homiemail-a75.g.dreamhost.com)
	(208.97.132.145) by server-6.tower-216.messagelabs.com with SMTP;
	5 Dec 2011 15:11:51 -0000
Received: from homiemail-a75.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a75.g.dreamhost.com (Postfix) with ESMTP id 6688E5EC08B;
	Mon,  5 Dec 2011 07:11:50 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=NE1xDyISHUvxvlNKkFjMFRz0R2bwWh3hLyDTchc3dxxg
	tzAOjhG9kI47YmQBYqULZn9reqJeJ/c9+0dzA3wDWKAUSc8Ewz7WoKam8Cee8cey
	yDolIt/EVIGLNr2ZU8BoNjuptdGkRo+FEe2ULxGL2bS537Gau8iHizkes+RO31U=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=VgdgbeXxrdXJ0N204ZFPNiDQzVY=; b=AmIcioCjYIv
	fNm3SI2EIpFXy9TfTXwhfIV/8/3trIaYHV5vEv9lJyNIUPnF3tSmmiL5kCM/pigW
	17x6EkFU1SG+borSPL/f4j8nYM1fjvlGu3QwgwakkALrClvTY6AVmxSE9zzZzURj
	IaHS3Nc/6qCR/K6xMKL+TD1BAQ8McQ5g=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a75.g.dreamhost.com (Postfix) with ESMTPSA id A3FCE5EC07C; 
	Mon,  5 Dec 2011 07:11:49 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 2a4ec2e2ae36593aa74e306bb8400db53ec1e166
Message-Id: <2a4ec2e2ae36593aa74e.1323097920@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1323097919@xdev.gridcentric.ca>
References: <patchbomb.1323097919@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Mon, 05 Dec 2011 10:12:00 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, keir.xen@gmail.com, tim@xen.org, olaf@aepfle.de,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 1 of 5] Flag events caused by foreign domains
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/mm/mem_event.c    |  6 ++++++
 xen/include/public/mem_event.h |  1 +
 2 files changed, 7 insertions(+), 0 deletions(-)


Add a new flag for mem events, as consumers might need to discriminate
foreign domain-caused from guest-caused events. The vcpu field of an
event is bogus from a consumer p.o.v. for foreign domain-caused events.

Also assert that we shouldn't be pausing foreign vcpus.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla>

diff -r 8ad7af68e017 -r 2a4ec2e2ae36 xen/arch/x86/mm/mem_event.c
--- a/xen/arch/x86/mm/mem_event.c
+++ b/xen/arch/x86/mm/mem_event.c
@@ -143,6 +143,12 @@ void mem_event_put_request(struct domain
     front_ring = &med->front_ring;
     req_prod = front_ring->req_prod_pvt;
 
+    if ( current->domain != d )
+    {
+        req->flags |= MEM_EVENT_FLAG_FOREIGN;
+        ASSERT( !(req->flags & MEM_EVENT_FLAG_VCPU_PAUSED) );
+    }
+
     /* Copy request */
     memcpy(RING_GET_REQUEST(front_ring, req_prod), req, sizeof(*req));
     req_prod++;
diff -r 8ad7af68e017 -r 2a4ec2e2ae36 xen/include/public/mem_event.h
--- a/xen/include/public/mem_event.h
+++ b/xen/include/public/mem_event.h
@@ -39,6 +39,7 @@
 #define MEM_EVENT_FLAG_VCPU_PAUSED  (1 << 0)
 #define MEM_EVENT_FLAG_DROP_PAGE    (1 << 1)
 #define MEM_EVENT_FLAG_EVICT_FAIL   (1 << 2)
+#define MEM_EVENT_FLAG_FOREIGN      (1 << 3)
 
 /* Reasons for the memory event request */
 #define MEM_EVENT_REASON_UNKNOWN     0    /* typical reason */

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 15:13:14 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 15:13:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXaE0-00083K-9d; Mon, 05 Dec 2011 15:13:00 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RXaDe-00081Y-JO
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 15:12:58 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-3.tower-216.messagelabs.com!1323097911!6198049!2
X-Originating-IP: [208.97.132.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMDguOTcuMTMyLjgxID0+IDE4MTA4\n,sa_preprocessor: 
	QmFkIElQOiAyMDguOTcuMTMyLjgxID0+IDE4MTA4\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2978 invoked from network); 5 Dec 2011 15:11:53 -0000
Received: from caiajhbdcaib.dreamhost.com (HELO homiemail-a75.g.dreamhost.com)
	(208.97.132.81) by server-3.tower-216.messagelabs.com with SMTP;
	5 Dec 2011 15:11:53 -0000
Received: from homiemail-a75.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a75.g.dreamhost.com (Postfix) with ESMTP id 00B715EC091;
	Mon,  5 Dec 2011 07:11:53 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=SF2fX5ojXGlsv5oSdDBegcToSn2Ra8B76JicqJ1LRBCr
	d7yfQSjRrJ7QqA5U8D1HxuEN8EfwmskqrfU6XXxx7jInmt6Bb/O1SZaZK+BtcPZc
	oOtki4go+Rsh/X0V+yuNhvRfmCcabj4mpmAkgj2QV9kpTbl+dPBWOVMBUnWmO/w=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=StTIN7znGBzPO6ECiBDIqatSMl0=; b=hbDSE97QfKh
	TaTUt8CFJlqZR1H0bvN/nZJMagPFLUk4jLoVpJBUMrEaNt4AChvn2eRv+aQoUv58
	JQWp+ZcDCvXiY1UrAnSOjr/8O0viwiFIN2sbxWgZ3gSeg8/sFTpDdzybWKKiHf7C
	qVFDx9dOBoRMu4RMTujUf4MJBJoPAJ6M=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a75.g.dreamhost.com (Postfix) with ESMTPSA id 5C0E85EC07C; 
	Mon,  5 Dec 2011 07:11:52 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: c71f4c5b42f0c7cc04e4ae758c8ab775305f2c6a
Message-Id: <c71f4c5b42f0c7cc04e4.1323097923@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1323097919@xdev.gridcentric.ca>
References: <patchbomb.1323097919@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Mon, 05 Dec 2011 10:12:03 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, keir.xen@gmail.com, tim@xen.org, olaf@aepfle.de,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 4 of 5] Consume multiple mem event responses off
	the ring
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/mm/mem_event.c     |  10 +++++++-
 xen/arch/x86/mm/mem_sharing.c   |  13 +++++----
 xen/arch/x86/mm/p2m.c           |  52 +++++++++++++++++++++-------------------
 xen/include/asm-x86/mem_event.h |   2 +-
 4 files changed, 44 insertions(+), 33 deletions(-)


Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Signed-off-by: Adin Scannell <adin@scanneel.ca>

diff -r 22b05954f754 -r c71f4c5b42f0 xen/arch/x86/mm/mem_event.c
--- a/xen/arch/x86/mm/mem_event.c
+++ b/xen/arch/x86/mm/mem_event.c
@@ -166,7 +166,7 @@ void mem_event_put_request(struct domain
     notify_via_xen_event_channel(d, med->xen_port);
 }
 
-void mem_event_get_response(struct mem_event_domain *med, mem_event_response_t *rsp)
+int mem_event_get_response(struct mem_event_domain *med, mem_event_response_t *rsp)
 {
     mem_event_front_ring_t *front_ring;
     RING_IDX rsp_cons;
@@ -176,6 +176,12 @@ void mem_event_get_response(struct mem_e
     front_ring = &med->front_ring;
     rsp_cons = front_ring->rsp_cons;
 
+    if ( !RING_HAS_UNCONSUMED_RESPONSES(front_ring) )
+    {
+        mem_event_ring_unlock(med);
+        return 0;
+    }
+
     /* Copy response */
     memcpy(rsp, RING_GET_RESPONSE(front_ring, rsp_cons), sizeof(*rsp));
     rsp_cons++;
@@ -185,6 +191,8 @@ void mem_event_get_response(struct mem_e
     front_ring->sring->rsp_event = rsp_cons + 1;
 
     mem_event_ring_unlock(med);
+
+    return 1;
 }
 
 void mem_event_unpause_vcpus(struct domain *d)
diff -r 22b05954f754 -r c71f4c5b42f0 xen/arch/x86/mm/mem_sharing.c
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -300,12 +300,13 @@ int mem_sharing_sharing_resume(struct do
 {
     mem_event_response_t rsp;
 
-    /* Get request off the ring */
-    mem_event_get_response(&d->mem_event->share, &rsp);
-
-    /* Unpause domain/vcpu */
-    if( rsp.flags & MEM_EVENT_FLAG_VCPU_PAUSED )
-        vcpu_unpause(d->vcpu[rsp.vcpu_id]);
+    /* Get all requests off the ring */
+    while ( mem_event_get_response(&d->mem_event->share, &rsp) )
+    {
+        /* Unpause domain/vcpu */
+        if ( rsp.flags & MEM_EVENT_FLAG_VCPU_PAUSED )
+            vcpu_unpause(d->vcpu[rsp.vcpu_id]);
+    }
 
     return 0;
 }
diff -r 22b05954f754 -r c71f4c5b42f0 xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -1066,31 +1066,31 @@ void p2m_mem_paging_resume(struct domain
     p2m_access_t a;
     mfn_t mfn;
 
-    /* Pull the response off the ring */
-    mem_event_get_response(&d->mem_event->paging, &rsp);
-
-    /* Fix p2m entry if the page was not dropped */
-    if ( !(rsp.flags & MEM_EVENT_FLAG_DROP_PAGE) )
+    /* Pull all responses off the ring */
+    while( mem_event_get_response(&d->mem_event->paging, &rsp) )
     {
-        p2m_lock(p2m);
-        mfn = p2m->get_entry(p2m, rsp.gfn, &p2mt, &a, p2m_query, NULL);
-        /* Allow only pages which were prepared properly, or pages which
-         * were nominated but not evicted */
-        if ( mfn_valid(mfn) && 
-             (p2mt == p2m_ram_paging_in || p2mt == p2m_ram_paging_in_start) )
+        /* Fix p2m entry if the page was not dropped */
+        if ( !(rsp.flags & MEM_EVENT_FLAG_DROP_PAGE) )
         {
-            set_p2m_entry(p2m, rsp.gfn, mfn, PAGE_ORDER_4K, 
-                            paging_mode_log_dirty(d) ? p2m_ram_logdirty : p2m_ram_rw, 
-                            a);
-            set_gpfn_from_mfn(mfn_x(mfn), rsp.gfn);
+            p2m_lock(p2m);
+            mfn = p2m->get_entry(p2m, rsp.gfn, &p2mt, &a, p2m_query, NULL);
+            /* Allow only pages which were prepared properly, or pages which
+             * were nominated but not evicted */
+            if ( mfn_valid(mfn) && 
+                 (p2mt == p2m_ram_paging_in || p2mt == p2m_ram_paging_in_start) )
+            {
+                set_p2m_entry(p2m, rsp.gfn, mfn, PAGE_ORDER_4K, 
+                                paging_mode_log_dirty(d) ? p2m_ram_logdirty : 
+                                p2m_ram_rw, a);
+                set_gpfn_from_mfn(mfn_x(mfn), rsp.gfn);
+            }
+            p2m_unlock(p2m);
         }
-        p2m_unlock(p2m);
+        /* Unpause domain */
+        if ( rsp.flags & MEM_EVENT_FLAG_VCPU_PAUSED )
+            vcpu_unpause(d->vcpu[rsp.vcpu_id]);
     }
 
-    /* Unpause domain */
-    if ( rsp.flags & MEM_EVENT_FLAG_VCPU_PAUSED )
-        vcpu_unpause(d->vcpu[rsp.vcpu_id]);
-
     /* Unpause any domains that were paused because the ring was full */
     mem_event_unpause_vcpus(d);
 }
@@ -1174,11 +1174,13 @@ void p2m_mem_access_resume(struct domain
 {
     mem_event_response_t rsp;
 
-    mem_event_get_response(&d->mem_event->access, &rsp);
-
-    /* Unpause domain */
-    if ( rsp.flags & MEM_EVENT_FLAG_VCPU_PAUSED )
-        vcpu_unpause(d->vcpu[rsp.vcpu_id]);
+    /* Pull all responses off the ring */
+    while( mem_event_get_response(&d->mem_event->access, &rsp) )
+    {
+        /* Unpause domain */
+        if ( rsp.flags & MEM_EVENT_FLAG_VCPU_PAUSED )
+            vcpu_unpause(d->vcpu[rsp.vcpu_id]);
+    }
 
     /* Unpause any domains that were paused because the ring was full or no listener 
      * was available */
diff -r 22b05954f754 -r c71f4c5b42f0 xen/include/asm-x86/mem_event.h
--- a/xen/include/asm-x86/mem_event.h
+++ b/xen/include/asm-x86/mem_event.h
@@ -29,7 +29,7 @@ void mem_event_mark_and_pause(struct vcp
 int mem_event_check_ring(struct domain *d, struct mem_event_domain *med);
 void mem_event_put_req_producers(struct mem_event_domain *med);
 void mem_event_put_request(struct domain *d, struct mem_event_domain *med, mem_event_request_t *req);
-void mem_event_get_response(struct mem_event_domain *med, mem_event_response_t *rsp);
+int mem_event_get_response(struct mem_event_domain *med, mem_event_response_t *rsp);
 void mem_event_unpause_vcpus(struct domain *d);
 
 int mem_event_domctl(struct domain *d, xen_domctl_mem_event_op_t *mec,

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 15:13:14 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 15:13:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXaE0-00083K-9d; Mon, 05 Dec 2011 15:13:00 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RXaDe-00081Y-JO
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 15:12:58 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-3.tower-216.messagelabs.com!1323097911!6198049!2
X-Originating-IP: [208.97.132.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMDguOTcuMTMyLjgxID0+IDE4MTA4\n,sa_preprocessor: 
	QmFkIElQOiAyMDguOTcuMTMyLjgxID0+IDE4MTA4\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2978 invoked from network); 5 Dec 2011 15:11:53 -0000
Received: from caiajhbdcaib.dreamhost.com (HELO homiemail-a75.g.dreamhost.com)
	(208.97.132.81) by server-3.tower-216.messagelabs.com with SMTP;
	5 Dec 2011 15:11:53 -0000
Received: from homiemail-a75.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a75.g.dreamhost.com (Postfix) with ESMTP id 00B715EC091;
	Mon,  5 Dec 2011 07:11:53 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=SF2fX5ojXGlsv5oSdDBegcToSn2Ra8B76JicqJ1LRBCr
	d7yfQSjRrJ7QqA5U8D1HxuEN8EfwmskqrfU6XXxx7jInmt6Bb/O1SZaZK+BtcPZc
	oOtki4go+Rsh/X0V+yuNhvRfmCcabj4mpmAkgj2QV9kpTbl+dPBWOVMBUnWmO/w=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=StTIN7znGBzPO6ECiBDIqatSMl0=; b=hbDSE97QfKh
	TaTUt8CFJlqZR1H0bvN/nZJMagPFLUk4jLoVpJBUMrEaNt4AChvn2eRv+aQoUv58
	JQWp+ZcDCvXiY1UrAnSOjr/8O0viwiFIN2sbxWgZ3gSeg8/sFTpDdzybWKKiHf7C
	qVFDx9dOBoRMu4RMTujUf4MJBJoPAJ6M=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a75.g.dreamhost.com (Postfix) with ESMTPSA id 5C0E85EC07C; 
	Mon,  5 Dec 2011 07:11:52 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: c71f4c5b42f0c7cc04e4ae758c8ab775305f2c6a
Message-Id: <c71f4c5b42f0c7cc04e4.1323097923@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1323097919@xdev.gridcentric.ca>
References: <patchbomb.1323097919@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Mon, 05 Dec 2011 10:12:03 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, keir.xen@gmail.com, tim@xen.org, olaf@aepfle.de,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 4 of 5] Consume multiple mem event responses off
	the ring
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/mm/mem_event.c     |  10 +++++++-
 xen/arch/x86/mm/mem_sharing.c   |  13 +++++----
 xen/arch/x86/mm/p2m.c           |  52 +++++++++++++++++++++-------------------
 xen/include/asm-x86/mem_event.h |   2 +-
 4 files changed, 44 insertions(+), 33 deletions(-)


Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Signed-off-by: Adin Scannell <adin@scanneel.ca>

diff -r 22b05954f754 -r c71f4c5b42f0 xen/arch/x86/mm/mem_event.c
--- a/xen/arch/x86/mm/mem_event.c
+++ b/xen/arch/x86/mm/mem_event.c
@@ -166,7 +166,7 @@ void mem_event_put_request(struct domain
     notify_via_xen_event_channel(d, med->xen_port);
 }
 
-void mem_event_get_response(struct mem_event_domain *med, mem_event_response_t *rsp)
+int mem_event_get_response(struct mem_event_domain *med, mem_event_response_t *rsp)
 {
     mem_event_front_ring_t *front_ring;
     RING_IDX rsp_cons;
@@ -176,6 +176,12 @@ void mem_event_get_response(struct mem_e
     front_ring = &med->front_ring;
     rsp_cons = front_ring->rsp_cons;
 
+    if ( !RING_HAS_UNCONSUMED_RESPONSES(front_ring) )
+    {
+        mem_event_ring_unlock(med);
+        return 0;
+    }
+
     /* Copy response */
     memcpy(rsp, RING_GET_RESPONSE(front_ring, rsp_cons), sizeof(*rsp));
     rsp_cons++;
@@ -185,6 +191,8 @@ void mem_event_get_response(struct mem_e
     front_ring->sring->rsp_event = rsp_cons + 1;
 
     mem_event_ring_unlock(med);
+
+    return 1;
 }
 
 void mem_event_unpause_vcpus(struct domain *d)
diff -r 22b05954f754 -r c71f4c5b42f0 xen/arch/x86/mm/mem_sharing.c
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -300,12 +300,13 @@ int mem_sharing_sharing_resume(struct do
 {
     mem_event_response_t rsp;
 
-    /* Get request off the ring */
-    mem_event_get_response(&d->mem_event->share, &rsp);
-
-    /* Unpause domain/vcpu */
-    if( rsp.flags & MEM_EVENT_FLAG_VCPU_PAUSED )
-        vcpu_unpause(d->vcpu[rsp.vcpu_id]);
+    /* Get all requests off the ring */
+    while ( mem_event_get_response(&d->mem_event->share, &rsp) )
+    {
+        /* Unpause domain/vcpu */
+        if ( rsp.flags & MEM_EVENT_FLAG_VCPU_PAUSED )
+            vcpu_unpause(d->vcpu[rsp.vcpu_id]);
+    }
 
     return 0;
 }
diff -r 22b05954f754 -r c71f4c5b42f0 xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -1066,31 +1066,31 @@ void p2m_mem_paging_resume(struct domain
     p2m_access_t a;
     mfn_t mfn;
 
-    /* Pull the response off the ring */
-    mem_event_get_response(&d->mem_event->paging, &rsp);
-
-    /* Fix p2m entry if the page was not dropped */
-    if ( !(rsp.flags & MEM_EVENT_FLAG_DROP_PAGE) )
+    /* Pull all responses off the ring */
+    while( mem_event_get_response(&d->mem_event->paging, &rsp) )
     {
-        p2m_lock(p2m);
-        mfn = p2m->get_entry(p2m, rsp.gfn, &p2mt, &a, p2m_query, NULL);
-        /* Allow only pages which were prepared properly, or pages which
-         * were nominated but not evicted */
-        if ( mfn_valid(mfn) && 
-             (p2mt == p2m_ram_paging_in || p2mt == p2m_ram_paging_in_start) )
+        /* Fix p2m entry if the page was not dropped */
+        if ( !(rsp.flags & MEM_EVENT_FLAG_DROP_PAGE) )
         {
-            set_p2m_entry(p2m, rsp.gfn, mfn, PAGE_ORDER_4K, 
-                            paging_mode_log_dirty(d) ? p2m_ram_logdirty : p2m_ram_rw, 
-                            a);
-            set_gpfn_from_mfn(mfn_x(mfn), rsp.gfn);
+            p2m_lock(p2m);
+            mfn = p2m->get_entry(p2m, rsp.gfn, &p2mt, &a, p2m_query, NULL);
+            /* Allow only pages which were prepared properly, or pages which
+             * were nominated but not evicted */
+            if ( mfn_valid(mfn) && 
+                 (p2mt == p2m_ram_paging_in || p2mt == p2m_ram_paging_in_start) )
+            {
+                set_p2m_entry(p2m, rsp.gfn, mfn, PAGE_ORDER_4K, 
+                                paging_mode_log_dirty(d) ? p2m_ram_logdirty : 
+                                p2m_ram_rw, a);
+                set_gpfn_from_mfn(mfn_x(mfn), rsp.gfn);
+            }
+            p2m_unlock(p2m);
         }
-        p2m_unlock(p2m);
+        /* Unpause domain */
+        if ( rsp.flags & MEM_EVENT_FLAG_VCPU_PAUSED )
+            vcpu_unpause(d->vcpu[rsp.vcpu_id]);
     }
 
-    /* Unpause domain */
-    if ( rsp.flags & MEM_EVENT_FLAG_VCPU_PAUSED )
-        vcpu_unpause(d->vcpu[rsp.vcpu_id]);
-
     /* Unpause any domains that were paused because the ring was full */
     mem_event_unpause_vcpus(d);
 }
@@ -1174,11 +1174,13 @@ void p2m_mem_access_resume(struct domain
 {
     mem_event_response_t rsp;
 
-    mem_event_get_response(&d->mem_event->access, &rsp);
-
-    /* Unpause domain */
-    if ( rsp.flags & MEM_EVENT_FLAG_VCPU_PAUSED )
-        vcpu_unpause(d->vcpu[rsp.vcpu_id]);
+    /* Pull all responses off the ring */
+    while( mem_event_get_response(&d->mem_event->access, &rsp) )
+    {
+        /* Unpause domain */
+        if ( rsp.flags & MEM_EVENT_FLAG_VCPU_PAUSED )
+            vcpu_unpause(d->vcpu[rsp.vcpu_id]);
+    }
 
     /* Unpause any domains that were paused because the ring was full or no listener 
      * was available */
diff -r 22b05954f754 -r c71f4c5b42f0 xen/include/asm-x86/mem_event.h
--- a/xen/include/asm-x86/mem_event.h
+++ b/xen/include/asm-x86/mem_event.h
@@ -29,7 +29,7 @@ void mem_event_mark_and_pause(struct vcp
 int mem_event_check_ring(struct domain *d, struct mem_event_domain *med);
 void mem_event_put_req_producers(struct mem_event_domain *med);
 void mem_event_put_request(struct domain *d, struct mem_event_domain *med, mem_event_request_t *req);
-void mem_event_get_response(struct mem_event_domain *med, mem_event_response_t *rsp);
+int mem_event_get_response(struct mem_event_domain *med, mem_event_response_t *rsp);
 void mem_event_unpause_vcpus(struct domain *d);
 
 int mem_event_domctl(struct domain *d, xen_domctl_mem_event_op_t *mec,

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 15:13:19 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 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.xensource.com>)
	id 1RXaDz-000832-Ej; Mon, 05 Dec 2011 15:12:59 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RXaDd-00081X-H3
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 15:12:57 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-6.tower-216.messagelabs.com!1323097912!6214590!1
X-Originating-IP: [208.97.132.119]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xMTkgPT4gMTU4ODE=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3351 invoked from network); 5 Dec 2011 15:11:52 -0000
Received: from caiajhbdcbbj.dreamhost.com (HELO homiemail-a75.g.dreamhost.com)
	(208.97.132.119) by server-6.tower-216.messagelabs.com with SMTP;
	5 Dec 2011 15:11:52 -0000
Received: from homiemail-a75.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a75.g.dreamhost.com (Postfix) with ESMTP id 296D45EC08D;
	Mon,  5 Dec 2011 07:11:52 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=kCoHTUHKnE3QmY13vQPDG5QMFM9G2rYj8jL4ic46ooq5
	60ZpUynI3xIFBTTgiD5WhWtOhynkorTuZe9OAByBFU82qcAaczYuC5NkKyowmfyb
	fet/hlsOBZMWxqPNkxGiZeRaXJ77ToW2wAHvg6loampWzH2Gk0Nuuhp9Nx9w/vM=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=RoCGenuWH4i0Ihr9denLbnFwm/U=; b=UTartlPIk8h
	52xbYOQNgRykXsDRwH1S6VS9lO9LfboM0OeKLjpNASe3+KoeF+OFt/mjS7yZHXIH
	2CVg8xjcj37vDweZzboel5eeIiaBspuO76dYl1391EU/clWg5LKRyJJv7sX06qIy
	QJvtFovHA288XMSnwAXNN8GNUwDGTWZ8=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a75.g.dreamhost.com (Postfix) with ESMTPSA id 7F43E5EC07C; 
	Mon,  5 Dec 2011 07:11:51 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 22b05954f754c472001a7c105e1c35c0a61f7d0f
Message-Id: <22b05954f754c472001a.1323097922@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1323097919@xdev.gridcentric.ca>
References: <patchbomb.1323097919@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Mon, 05 Dec 2011 10:12:02 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, keir.xen@gmail.com, tim@xen.org, olaf@aepfle.de,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 3 of 5] Allow memevent responses to be signaled
 via the event channel
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/mm/mem_event.c |  26 ++++++++++++++++++++------
 1 files changed, 20 insertions(+), 6 deletions(-)


Don't require a separate domctl to notify the memevent interface that an event
has occured.  This domctl can be taxing, particularly when you are scaling
events and paging to many domains across a single system.  Instead, we use the
existing event channel to signal when we place something in the ring (as per
normal ring operation).

Signed-off-by: Adin Scannell <adin@scannell.ca>
Signed-off-by: Keir Fraser <keir@xen.org>
Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 4c19931b40d5 -r 22b05954f754 xen/arch/x86/mm/mem_event.c
--- a/xen/arch/x86/mm/mem_event.c
+++ b/xen/arch/x86/mm/mem_event.c
@@ -37,9 +37,11 @@
 #define mem_event_ring_lock(_med)       spin_lock(&(_med)->ring_lock)
 #define mem_event_ring_unlock(_med)     spin_unlock(&(_med)->ring_lock)
 
-static int mem_event_enable(struct domain *d,
-                            xen_domctl_mem_event_op_t *mec,
-                            struct mem_event_domain *med)
+static int mem_event_enable(
+    struct domain *d,
+    xen_domctl_mem_event_op_t *mec,
+    struct mem_event_domain *med,
+    xen_event_channel_notification_t notification_fn)
 {
     int rc;
     struct domain *dom_mem_event = current->domain;
@@ -94,7 +96,7 @@ static int mem_event_enable(struct domai
     /* Allocate event channel */
     rc = alloc_unbound_xen_event_channel(d->vcpu[0],
                                          current->domain->domain_id,
-                                         NULL);
+                                         notification_fn);
     if ( rc < 0 )
         goto err;
 
@@ -233,6 +235,18 @@ int mem_event_check_ring(struct domain *
     return ring_full;
 }
 
+/* Registered with Xen-bound event channel for incoming notifications. */
+static void mem_paging_notification(struct vcpu *v, unsigned int port)
+{
+    p2m_mem_paging_resume(v->domain);
+}
+
+/* Registered with Xen-bound event channel for incoming notifications. */
+static void mem_access_notification(struct vcpu *v, unsigned int port)
+{
+    p2m_mem_access_resume(v->domain);
+}
+
 int mem_event_domctl(struct domain *d, xen_domctl_mem_event_op_t *mec,
                      XEN_GUEST_HANDLE(void) u_domctl)
 {
@@ -294,7 +308,7 @@ int mem_event_domctl(struct domain *d, x
             if ( p2m->pod.entry_count )
                 break;
 
-            rc = mem_event_enable(d, mec, med);
+            rc = mem_event_enable(d, mec, med, mem_paging_notification);
         }
         break;
 
@@ -333,7 +347,7 @@ int mem_event_domctl(struct domain *d, x
             if ( boot_cpu_data.x86_vendor != X86_VENDOR_INTEL )
                 break;
 
-            rc = mem_event_enable(d, mec, med);
+            rc = mem_event_enable(d, mec, med, mem_access_notification);
         }
         break;
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 15:13:19 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 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.xensource.com>)
	id 1RXaDz-000832-Ej; Mon, 05 Dec 2011 15:12:59 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RXaDd-00081X-H3
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 15:12:57 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-6.tower-216.messagelabs.com!1323097912!6214590!1
X-Originating-IP: [208.97.132.119]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xMTkgPT4gMTU4ODE=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3351 invoked from network); 5 Dec 2011 15:11:52 -0000
Received: from caiajhbdcbbj.dreamhost.com (HELO homiemail-a75.g.dreamhost.com)
	(208.97.132.119) by server-6.tower-216.messagelabs.com with SMTP;
	5 Dec 2011 15:11:52 -0000
Received: from homiemail-a75.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a75.g.dreamhost.com (Postfix) with ESMTP id 296D45EC08D;
	Mon,  5 Dec 2011 07:11:52 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=kCoHTUHKnE3QmY13vQPDG5QMFM9G2rYj8jL4ic46ooq5
	60ZpUynI3xIFBTTgiD5WhWtOhynkorTuZe9OAByBFU82qcAaczYuC5NkKyowmfyb
	fet/hlsOBZMWxqPNkxGiZeRaXJ77ToW2wAHvg6loampWzH2Gk0Nuuhp9Nx9w/vM=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=RoCGenuWH4i0Ihr9denLbnFwm/U=; b=UTartlPIk8h
	52xbYOQNgRykXsDRwH1S6VS9lO9LfboM0OeKLjpNASe3+KoeF+OFt/mjS7yZHXIH
	2CVg8xjcj37vDweZzboel5eeIiaBspuO76dYl1391EU/clWg5LKRyJJv7sX06qIy
	QJvtFovHA288XMSnwAXNN8GNUwDGTWZ8=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a75.g.dreamhost.com (Postfix) with ESMTPSA id 7F43E5EC07C; 
	Mon,  5 Dec 2011 07:11:51 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 22b05954f754c472001a7c105e1c35c0a61f7d0f
Message-Id: <22b05954f754c472001a.1323097922@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1323097919@xdev.gridcentric.ca>
References: <patchbomb.1323097919@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Mon, 05 Dec 2011 10:12:02 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, keir.xen@gmail.com, tim@xen.org, olaf@aepfle.de,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 3 of 5] Allow memevent responses to be signaled
 via the event channel
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/mm/mem_event.c |  26 ++++++++++++++++++++------
 1 files changed, 20 insertions(+), 6 deletions(-)


Don't require a separate domctl to notify the memevent interface that an event
has occured.  This domctl can be taxing, particularly when you are scaling
events and paging to many domains across a single system.  Instead, we use the
existing event channel to signal when we place something in the ring (as per
normal ring operation).

Signed-off-by: Adin Scannell <adin@scannell.ca>
Signed-off-by: Keir Fraser <keir@xen.org>
Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 4c19931b40d5 -r 22b05954f754 xen/arch/x86/mm/mem_event.c
--- a/xen/arch/x86/mm/mem_event.c
+++ b/xen/arch/x86/mm/mem_event.c
@@ -37,9 +37,11 @@
 #define mem_event_ring_lock(_med)       spin_lock(&(_med)->ring_lock)
 #define mem_event_ring_unlock(_med)     spin_unlock(&(_med)->ring_lock)
 
-static int mem_event_enable(struct domain *d,
-                            xen_domctl_mem_event_op_t *mec,
-                            struct mem_event_domain *med)
+static int mem_event_enable(
+    struct domain *d,
+    xen_domctl_mem_event_op_t *mec,
+    struct mem_event_domain *med,
+    xen_event_channel_notification_t notification_fn)
 {
     int rc;
     struct domain *dom_mem_event = current->domain;
@@ -94,7 +96,7 @@ static int mem_event_enable(struct domai
     /* Allocate event channel */
     rc = alloc_unbound_xen_event_channel(d->vcpu[0],
                                          current->domain->domain_id,
-                                         NULL);
+                                         notification_fn);
     if ( rc < 0 )
         goto err;
 
@@ -233,6 +235,18 @@ int mem_event_check_ring(struct domain *
     return ring_full;
 }
 
+/* Registered with Xen-bound event channel for incoming notifications. */
+static void mem_paging_notification(struct vcpu *v, unsigned int port)
+{
+    p2m_mem_paging_resume(v->domain);
+}
+
+/* Registered with Xen-bound event channel for incoming notifications. */
+static void mem_access_notification(struct vcpu *v, unsigned int port)
+{
+    p2m_mem_access_resume(v->domain);
+}
+
 int mem_event_domctl(struct domain *d, xen_domctl_mem_event_op_t *mec,
                      XEN_GUEST_HANDLE(void) u_domctl)
 {
@@ -294,7 +308,7 @@ int mem_event_domctl(struct domain *d, x
             if ( p2m->pod.entry_count )
                 break;
 
-            rc = mem_event_enable(d, mec, med);
+            rc = mem_event_enable(d, mec, med, mem_paging_notification);
         }
         break;
 
@@ -333,7 +347,7 @@ int mem_event_domctl(struct domain *d, x
             if ( boot_cpu_data.x86_vendor != X86_VENDOR_INTEL )
                 break;
 
-            rc = mem_event_enable(d, mec, med);
+            rc = mem_event_enable(d, mec, med, mem_access_notification);
         }
         break;
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 15:13:19 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 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.xensource.com>)
	id 1RXaDr-00081u-EM; Mon, 05 Dec 2011 15:12:51 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RXaDf-00081a-G3
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 15:12:49 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-9.tower-174.messagelabs.com!1323097914!4333940!1
X-Originating-IP: [208.97.132.207]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4yMDcgPT4gMTU4NTI=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16442 invoked from network); 5 Dec 2011 15:11:54 -0000
Received: from caiajhbdccah.dreamhost.com (HELO homiemail-a75.g.dreamhost.com)
	(208.97.132.207) by server-9.tower-174.messagelabs.com with SMTP;
	5 Dec 2011 15:11:54 -0000
Received: from homiemail-a75.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a75.g.dreamhost.com (Postfix) with ESMTP id E70F15EC090;
	Mon,  5 Dec 2011 07:11:53 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=BLrXgRats0D5+8Lt+XDCf1tH0cm/hmeawOv5Dqt3V3EW
	Y4RfAO1y7iMtsVF5vt1MC/a+4aYPKOlcJgDrdwqh7njHgX4XNYYs37+BDeaZi24C
	uO/AfvPEAol6uEaCpS7YIQjMVDFVzNC2lGtaebnkQRJBZVomp5qaI7roTN24/Es=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=APSatIYKhh7/oMo4wxoHW/VqUeE=; b=tRNJ2qVJWJ6
	dkFIgxj4ohGLJnQtosR+JvOeG8A1nRd3iEteHVyxrAFMXsVa/OBicdj3EgzdNdQh
	BGib+lhRbYwR2qM+Oe1unTDbt5Q51vjmaxwxSv6AToNZtqSrjp8EkGbLQn4125Kg
	wML0NckoH5go3z6+D5Ek1Tk/VxA97BjY=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a75.g.dreamhost.com (Postfix) with ESMTPSA id 32D755EC07C; 
	Mon,  5 Dec 2011 07:11:53 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 790cd814bee86c717fe427b80e185c067d1097d4
Message-Id: <790cd814bee86c717fe4.1323097924@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1323097919@xdev.gridcentric.ca>
References: <patchbomb.1323097919@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Mon, 05 Dec 2011 10:12:04 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, keir.xen@gmail.com, tim@xen.org, olaf@aepfle.de,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 5 of 5] Ignore memory events with an obviously
	invalid gfn
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/mm/mem_sharing.c  |  2 ++
 xen/arch/x86/mm/p2m.c          |  4 ++++
 xen/include/public/mem_event.h |  7 +++++++
 3 files changed, 13 insertions(+), 0 deletions(-)


Ring semantics require that for every request, a response be put. This
allows consumer to place a dummy response if need be.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r c71f4c5b42f0 -r 790cd814bee8 xen/arch/x86/mm/mem_sharing.c
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -303,6 +303,8 @@ int mem_sharing_sharing_resume(struct do
     /* Get all requests off the ring */
     while ( mem_event_get_response(&d->mem_event->share, &rsp) )
     {
+        if ( DUMMY_MEM_EVENT_RSP(&rsp) )
+            continue;
         /* Unpause domain/vcpu */
         if ( rsp.flags & MEM_EVENT_FLAG_VCPU_PAUSED )
             vcpu_unpause(d->vcpu[rsp.vcpu_id]);
diff -r c71f4c5b42f0 -r 790cd814bee8 xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -1069,6 +1069,8 @@ void p2m_mem_paging_resume(struct domain
     /* Pull all responses off the ring */
     while( mem_event_get_response(&d->mem_event->paging, &rsp) )
     {
+        if ( DUMMY_MEM_EVENT_RSP(&rsp) )
+            continue;
         /* Fix p2m entry if the page was not dropped */
         if ( !(rsp.flags & MEM_EVENT_FLAG_DROP_PAGE) )
         {
@@ -1177,6 +1179,8 @@ void p2m_mem_access_resume(struct domain
     /* Pull all responses off the ring */
     while( mem_event_get_response(&d->mem_event->access, &rsp) )
     {
+        if ( DUMMY_MEM_EVENT_RSP(&rsp) )
+            continue;
         /* Unpause domain */
         if ( rsp.flags & MEM_EVENT_FLAG_VCPU_PAUSED )
             vcpu_unpause(d->vcpu[rsp.vcpu_id]);
diff -r c71f4c5b42f0 -r 790cd814bee8 xen/include/public/mem_event.h
--- a/xen/include/public/mem_event.h
+++ b/xen/include/public/mem_event.h
@@ -76,6 +76,13 @@ typedef struct mem_event_st {
 
 DEFINE_RING_TYPES(mem_event, mem_event_request_t, mem_event_response_t);
 
+#define INVALID_RSP_GFN -1UL
+
+#define DUMMY_MEM_EVENT_RSP(_r)         ((_r)->gfn == INVALID_RSP_GFN)
+#define MAKE_MEM_EVENT_RSP_DUMMY(_r)    ((_r)->gfn = INVALID_RSP_GFN)
+#define DECLARE_DUMMY_MEM_EVENT_RSP(_name) \
+    mem_event_response_t _name = { .gfn = INVALID_RSP_GFN }
+
 #endif
 
 /*

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 15:13:19 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 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.xensource.com>)
	id 1RXaDr-00081u-EM; Mon, 05 Dec 2011 15:12:51 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RXaDf-00081a-G3
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 15:12:49 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-9.tower-174.messagelabs.com!1323097914!4333940!1
X-Originating-IP: [208.97.132.207]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4yMDcgPT4gMTU4NTI=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16442 invoked from network); 5 Dec 2011 15:11:54 -0000
Received: from caiajhbdccah.dreamhost.com (HELO homiemail-a75.g.dreamhost.com)
	(208.97.132.207) by server-9.tower-174.messagelabs.com with SMTP;
	5 Dec 2011 15:11:54 -0000
Received: from homiemail-a75.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a75.g.dreamhost.com (Postfix) with ESMTP id E70F15EC090;
	Mon,  5 Dec 2011 07:11:53 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=BLrXgRats0D5+8Lt+XDCf1tH0cm/hmeawOv5Dqt3V3EW
	Y4RfAO1y7iMtsVF5vt1MC/a+4aYPKOlcJgDrdwqh7njHgX4XNYYs37+BDeaZi24C
	uO/AfvPEAol6uEaCpS7YIQjMVDFVzNC2lGtaebnkQRJBZVomp5qaI7roTN24/Es=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=APSatIYKhh7/oMo4wxoHW/VqUeE=; b=tRNJ2qVJWJ6
	dkFIgxj4ohGLJnQtosR+JvOeG8A1nRd3iEteHVyxrAFMXsVa/OBicdj3EgzdNdQh
	BGib+lhRbYwR2qM+Oe1unTDbt5Q51vjmaxwxSv6AToNZtqSrjp8EkGbLQn4125Kg
	wML0NckoH5go3z6+D5Ek1Tk/VxA97BjY=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a75.g.dreamhost.com (Postfix) with ESMTPSA id 32D755EC07C; 
	Mon,  5 Dec 2011 07:11:53 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 790cd814bee86c717fe427b80e185c067d1097d4
Message-Id: <790cd814bee86c717fe4.1323097924@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1323097919@xdev.gridcentric.ca>
References: <patchbomb.1323097919@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Mon, 05 Dec 2011 10:12:04 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, keir.xen@gmail.com, tim@xen.org, olaf@aepfle.de,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 5 of 5] Ignore memory events with an obviously
	invalid gfn
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/mm/mem_sharing.c  |  2 ++
 xen/arch/x86/mm/p2m.c          |  4 ++++
 xen/include/public/mem_event.h |  7 +++++++
 3 files changed, 13 insertions(+), 0 deletions(-)


Ring semantics require that for every request, a response be put. This
allows consumer to place a dummy response if need be.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r c71f4c5b42f0 -r 790cd814bee8 xen/arch/x86/mm/mem_sharing.c
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -303,6 +303,8 @@ int mem_sharing_sharing_resume(struct do
     /* Get all requests off the ring */
     while ( mem_event_get_response(&d->mem_event->share, &rsp) )
     {
+        if ( DUMMY_MEM_EVENT_RSP(&rsp) )
+            continue;
         /* Unpause domain/vcpu */
         if ( rsp.flags & MEM_EVENT_FLAG_VCPU_PAUSED )
             vcpu_unpause(d->vcpu[rsp.vcpu_id]);
diff -r c71f4c5b42f0 -r 790cd814bee8 xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -1069,6 +1069,8 @@ void p2m_mem_paging_resume(struct domain
     /* Pull all responses off the ring */
     while( mem_event_get_response(&d->mem_event->paging, &rsp) )
     {
+        if ( DUMMY_MEM_EVENT_RSP(&rsp) )
+            continue;
         /* Fix p2m entry if the page was not dropped */
         if ( !(rsp.flags & MEM_EVENT_FLAG_DROP_PAGE) )
         {
@@ -1177,6 +1179,8 @@ void p2m_mem_access_resume(struct domain
     /* Pull all responses off the ring */
     while( mem_event_get_response(&d->mem_event->access, &rsp) )
     {
+        if ( DUMMY_MEM_EVENT_RSP(&rsp) )
+            continue;
         /* Unpause domain */
         if ( rsp.flags & MEM_EVENT_FLAG_VCPU_PAUSED )
             vcpu_unpause(d->vcpu[rsp.vcpu_id]);
diff -r c71f4c5b42f0 -r 790cd814bee8 xen/include/public/mem_event.h
--- a/xen/include/public/mem_event.h
+++ b/xen/include/public/mem_event.h
@@ -76,6 +76,13 @@ typedef struct mem_event_st {
 
 DEFINE_RING_TYPES(mem_event, mem_event_request_t, mem_event_response_t);
 
+#define INVALID_RSP_GFN -1UL
+
+#define DUMMY_MEM_EVENT_RSP(_r)         ((_r)->gfn == INVALID_RSP_GFN)
+#define MAKE_MEM_EVENT_RSP_DUMMY(_r)    ((_r)->gfn = INVALID_RSP_GFN)
+#define DECLARE_DUMMY_MEM_EVENT_RSP(_name) \
+    mem_event_response_t _name = { .gfn = INVALID_RSP_GFN }
+
 #endif
 
 /*

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 15:13:29 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 15:13:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXaDs-00082B-10; Mon, 05 Dec 2011 15:12:52 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RXaDb-00081S-FY
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 15:12:50 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-9.tower-216.messagelabs.com!1323097910!6257672!1
X-Originating-IP: [208.97.132.177]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNzcgPT4gMTQ2OTc=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23829 invoked from network); 5 Dec 2011 15:11:50 -0000
Received: from caiajhbdcbhh.dreamhost.com (HELO homiemail-a75.g.dreamhost.com)
	(208.97.132.177) by server-9.tower-216.messagelabs.com with SMTP;
	5 Dec 2011 15:11:50 -0000
Received: from homiemail-a75.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a75.g.dreamhost.com (Postfix) with ESMTP id 75AD05EC07E;
	Mon,  5 Dec 2011 07:11:49 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id:date
	:from:to:cc; q=dns; s=lagarcavilla.org; b=kEn8drJ7O3Ya+EJT3yh8Ns
	kod65fZInBtypE8EokrWa1PMbnGaJKcDZda4G9tYNYFWv2WPGOy558mVMVH0CEkF
	2lAprVUQeJV/tBJ+7X2NurK+RJmogqF9OGiqGYOhJEBWdLzgw82AF8UGR9sgyP1o
	nH4CUyzzaPT08ia/iv3AU=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:date:from:to:cc; s=lagarcavilla.org; bh=tgCPi1v6JXFh
	Dhik3Yp4kVSgWjE=; b=LdHCPrm54UnFqi4groTr/bfuJ7wbRhExsy+uanYLfBr3
	EU/i71NGPSBxyZ+t2Fwnh+z5R8RajK6etgEBon6y9/ELWhZI1NjrCuvCZuYOae1v
	8GL62U+Ked5mM9fxL2xpEZUdr6nnu2ZoXTWDk5/BGDtqfS3I0pEyN94I+SN9XRc=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a75.g.dreamhost.com (Postfix) with ESMTPSA id B836A5EC07C; 
	Mon,  5 Dec 2011 07:11:48 -0800 (PST)
MIME-Version: 1.0
Message-Id: <patchbomb.1323097919@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Mon, 05 Dec 2011 10:11:59 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, keir.xen@gmail.com, tim@xen.org, olaf@aepfle.de,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 0 of 5] Mem event interface improvements
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

In this patch series we add a series of improevements to the memory
event interface. Namely:
- Allow batched consumption of multiple outstanding responses
- Signal Xen to consume responses solely with an event channel kick
- Extra flag to tag events generated byforeign-domains
- Allow placing dummy domains in the ring, to keep it in sync if
 a state transition does not require an explicit response.

All these changes are orthogonal to the outstanding proposals for 
enhancing ring management.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Signed-off-by: Adin Scannell <adin@scannell.ca>
Signed-off-by: Keir Fraser <keir@xen.org>

 xen/arch/x86/mm/mem_event.c     |   6 +++
 xen/include/public/mem_event.h  |   1 +
 xen/arch/ia64/vmx/vmx_init.c    |   2 +-
 xen/arch/x86/hvm/hvm.c          |   7 ++-
 xen/arch/x86/mm/mem_event.c     |   3 +-
 xen/common/event_channel.c      |  75 +++++++++++++++++++++++++++++++---------
 xen/include/xen/event.h         |   5 ++-
 xen/include/xen/sched.h         |   2 +-
 xen/arch/x86/mm/mem_event.c     |  26 ++++++++++---
 xen/arch/x86/mm/mem_event.c     |  10 ++++-
 xen/arch/x86/mm/mem_sharing.c   |  13 +++---
 xen/arch/x86/mm/p2m.c           |  52 ++++++++++++++-------------
 xen/include/asm-x86/mem_event.h |   2 +-
 xen/arch/x86/mm/mem_sharing.c   |   2 +
 xen/arch/x86/mm/p2m.c           |   4 ++
 xen/include/public/mem_event.h  |   7 +++
 16 files changed, 154 insertions(+), 63 deletions(-)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 15:13:29 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 15:13:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXaDs-00082B-10; Mon, 05 Dec 2011 15:12:52 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RXaDb-00081S-FY
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 15:12:50 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-9.tower-216.messagelabs.com!1323097910!6257672!1
X-Originating-IP: [208.97.132.177]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNzcgPT4gMTQ2OTc=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23829 invoked from network); 5 Dec 2011 15:11:50 -0000
Received: from caiajhbdcbhh.dreamhost.com (HELO homiemail-a75.g.dreamhost.com)
	(208.97.132.177) by server-9.tower-216.messagelabs.com with SMTP;
	5 Dec 2011 15:11:50 -0000
Received: from homiemail-a75.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a75.g.dreamhost.com (Postfix) with ESMTP id 75AD05EC07E;
	Mon,  5 Dec 2011 07:11:49 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id:date
	:from:to:cc; q=dns; s=lagarcavilla.org; b=kEn8drJ7O3Ya+EJT3yh8Ns
	kod65fZInBtypE8EokrWa1PMbnGaJKcDZda4G9tYNYFWv2WPGOy558mVMVH0CEkF
	2lAprVUQeJV/tBJ+7X2NurK+RJmogqF9OGiqGYOhJEBWdLzgw82AF8UGR9sgyP1o
	nH4CUyzzaPT08ia/iv3AU=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:date:from:to:cc; s=lagarcavilla.org; bh=tgCPi1v6JXFh
	Dhik3Yp4kVSgWjE=; b=LdHCPrm54UnFqi4groTr/bfuJ7wbRhExsy+uanYLfBr3
	EU/i71NGPSBxyZ+t2Fwnh+z5R8RajK6etgEBon6y9/ELWhZI1NjrCuvCZuYOae1v
	8GL62U+Ked5mM9fxL2xpEZUdr6nnu2ZoXTWDk5/BGDtqfS3I0pEyN94I+SN9XRc=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a75.g.dreamhost.com (Postfix) with ESMTPSA id B836A5EC07C; 
	Mon,  5 Dec 2011 07:11:48 -0800 (PST)
MIME-Version: 1.0
Message-Id: <patchbomb.1323097919@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Mon, 05 Dec 2011 10:11:59 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, keir.xen@gmail.com, tim@xen.org, olaf@aepfle.de,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 0 of 5] Mem event interface improvements
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

In this patch series we add a series of improevements to the memory
event interface. Namely:
- Allow batched consumption of multiple outstanding responses
- Signal Xen to consume responses solely with an event channel kick
- Extra flag to tag events generated byforeign-domains
- Allow placing dummy domains in the ring, to keep it in sync if
 a state transition does not require an explicit response.

All these changes are orthogonal to the outstanding proposals for 
enhancing ring management.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Signed-off-by: Adin Scannell <adin@scannell.ca>
Signed-off-by: Keir Fraser <keir@xen.org>

 xen/arch/x86/mm/mem_event.c     |   6 +++
 xen/include/public/mem_event.h  |   1 +
 xen/arch/ia64/vmx/vmx_init.c    |   2 +-
 xen/arch/x86/hvm/hvm.c          |   7 ++-
 xen/arch/x86/mm/mem_event.c     |   3 +-
 xen/common/event_channel.c      |  75 +++++++++++++++++++++++++++++++---------
 xen/include/xen/event.h         |   5 ++-
 xen/include/xen/sched.h         |   2 +-
 xen/arch/x86/mm/mem_event.c     |  26 ++++++++++---
 xen/arch/x86/mm/mem_event.c     |  10 ++++-
 xen/arch/x86/mm/mem_sharing.c   |  13 +++---
 xen/arch/x86/mm/p2m.c           |  52 ++++++++++++++-------------
 xen/include/asm-x86/mem_event.h |   2 +-
 xen/arch/x86/mm/mem_sharing.c   |   2 +
 xen/arch/x86/mm/p2m.c           |   4 ++
 xen/include/public/mem_event.h  |   7 +++
 16 files changed, 154 insertions(+), 63 deletions(-)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 15:24:18 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 15: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.xensource.com>)
	id 1RXaOj-0000ZH-PA; Mon, 05 Dec 2011 15:24:05 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RXaOh-0000ZA-QE
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 15:24:04 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-5.tower-27.messagelabs.com!1323098567!45474791!1
X-Originating-IP: [208.97.132.177]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNzcgPT4gMTQ2OTc=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10991 invoked from network); 5 Dec 2011 15:22:47 -0000
Received: from caiajhbdcbhh.dreamhost.com (HELO homiemail-a21.g.dreamhost.com)
	(208.97.132.177) by server-5.tower-27.messagelabs.com with SMTP;
	5 Dec 2011 15:22:47 -0000
Received: from homiemail-a21.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTP id F2013300072;
	Mon,  5 Dec 2011 07:23:22 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id:date
	:from:to:cc; q=dns; s=lagarcavilla.org; b=f7G68TJvZ4WAbMH+dLj5O8
	O4BdEEP8qPrSUOFk0lMul0NbfGxLTIXrfUcYOX5/WUzZAM9BNkON5kJzyt6iL2T3
	rmoIvTN58Z+x903Z8AREfvr11K8279ow2I7ZZWY+3jauQE4PXf6wpGmYpxbPVZAG
	I8qagMHOQd+jWv2L0JcSE=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:date:from:to:cc; s=lagarcavilla.org; bh=zzrqj0uCi15x
	1DTfHUJIWO3UD1w=; b=b5V6BLCI1T6MjBPJ0L0DDgmPdE5OnxuOpnNm0WBoxwkc
	OnfzQaBqgP1yjNZvgniDbmnVZLgY/M9Cm6SJc+yIMorbsvze8Em0nbGEAHT+Lypu
	sfM8antZsAek9iqJeo8a4lzs1aaDwAdR0YiuPp2OopYJufFmCL3+P0m9X3PJV4M=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTPSA id 28B8B300064; 
	Mon,  5 Dec 2011 07:23:22 -0800 (PST)
MIME-Version: 1.0
Message-Id: <patchbomb.1323098647@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Mon, 05 Dec 2011 10:24:07 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, keir.xen@gmail.com, tim@xen.org, olaf@aepfle.de,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 0 of 2] Mem event ring management overhaul
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ensure no guest events are ever lost in the mem event ring.

This is one of two outstanding proposals to solve this issue. One
key difference between them being that ours does not necessitate wait 
queues.

Instead, we rely on foreign domain retry (already in place), preempting
hypercalls that may cause unbounded guest events (such as 
decrease_reservation), and ensuring there is always space left in the 
ring for each guest vcpu to place at least one event.
 
The patch has been refreshed to apply on top of 62ff6a318c5d, and untangled
from other mem event modifications that are essentially orthogonal and can 
go in independently. 

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Signed-off-by: Adin Scannell <adin@scannell.ca>
 

 xen/common/memory.c             |   29 +++++-
 xen/arch/x86/hvm/hvm.c          |   21 ++-
 xen/arch/x86/mm/mem_event.c     |  203 +++++++++++++++++++++++++++++----------
 xen/arch/x86/mm/mem_sharing.c   |   17 ++-
 xen/arch/x86/mm/p2m.c           |   47 +++++----
 xen/common/memory.c             |    7 +-
 xen/include/asm-x86/mem_event.h |   16 ++-
 xen/include/asm-x86/p2m.h       |    6 +-
 xen/include/xen/mm.h            |    2 +
 xen/include/xen/sched.h         |    5 +-
 10 files changed, 257 insertions(+), 96 deletions(-)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 15:24:18 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 15: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.xensource.com>)
	id 1RXaOj-0000ZH-PA; Mon, 05 Dec 2011 15:24:05 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RXaOh-0000ZA-QE
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 15:24:04 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-5.tower-27.messagelabs.com!1323098567!45474791!1
X-Originating-IP: [208.97.132.177]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNzcgPT4gMTQ2OTc=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10991 invoked from network); 5 Dec 2011 15:22:47 -0000
Received: from caiajhbdcbhh.dreamhost.com (HELO homiemail-a21.g.dreamhost.com)
	(208.97.132.177) by server-5.tower-27.messagelabs.com with SMTP;
	5 Dec 2011 15:22:47 -0000
Received: from homiemail-a21.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTP id F2013300072;
	Mon,  5 Dec 2011 07:23:22 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id:date
	:from:to:cc; q=dns; s=lagarcavilla.org; b=f7G68TJvZ4WAbMH+dLj5O8
	O4BdEEP8qPrSUOFk0lMul0NbfGxLTIXrfUcYOX5/WUzZAM9BNkON5kJzyt6iL2T3
	rmoIvTN58Z+x903Z8AREfvr11K8279ow2I7ZZWY+3jauQE4PXf6wpGmYpxbPVZAG
	I8qagMHOQd+jWv2L0JcSE=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:date:from:to:cc; s=lagarcavilla.org; bh=zzrqj0uCi15x
	1DTfHUJIWO3UD1w=; b=b5V6BLCI1T6MjBPJ0L0DDgmPdE5OnxuOpnNm0WBoxwkc
	OnfzQaBqgP1yjNZvgniDbmnVZLgY/M9Cm6SJc+yIMorbsvze8Em0nbGEAHT+Lypu
	sfM8antZsAek9iqJeo8a4lzs1aaDwAdR0YiuPp2OopYJufFmCL3+P0m9X3PJV4M=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTPSA id 28B8B300064; 
	Mon,  5 Dec 2011 07:23:22 -0800 (PST)
MIME-Version: 1.0
Message-Id: <patchbomb.1323098647@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Mon, 05 Dec 2011 10:24:07 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, keir.xen@gmail.com, tim@xen.org, olaf@aepfle.de,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 0 of 2] Mem event ring management overhaul
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ensure no guest events are ever lost in the mem event ring.

This is one of two outstanding proposals to solve this issue. One
key difference between them being that ours does not necessitate wait 
queues.

Instead, we rely on foreign domain retry (already in place), preempting
hypercalls that may cause unbounded guest events (such as 
decrease_reservation), and ensuring there is always space left in the 
ring for each guest vcpu to place at least one event.
 
The patch has been refreshed to apply on top of 62ff6a318c5d, and untangled
from other mem event modifications that are essentially orthogonal and can 
go in independently. 

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Signed-off-by: Adin Scannell <adin@scannell.ca>
 

 xen/common/memory.c             |   29 +++++-
 xen/arch/x86/hvm/hvm.c          |   21 ++-
 xen/arch/x86/mm/mem_event.c     |  203 +++++++++++++++++++++++++++++----------
 xen/arch/x86/mm/mem_sharing.c   |   17 ++-
 xen/arch/x86/mm/p2m.c           |   47 +++++----
 xen/common/memory.c             |    7 +-
 xen/include/asm-x86/mem_event.h |   16 ++-
 xen/include/asm-x86/p2m.h       |    6 +-
 xen/include/xen/mm.h            |    2 +
 xen/include/xen/sched.h         |    5 +-
 10 files changed, 257 insertions(+), 96 deletions(-)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 15:24:23 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 15:24:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXaOp-0000Zb-A9; Mon, 05 Dec 2011 15:24:11 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RXaOn-0000ZF-LO
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 15:24:09 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-16.tower-21.messagelabs.com!1323098604!306002!1
X-Originating-IP: [208.97.132.202]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4yMDIgPT4gMTYyNDk=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8626 invoked from network); 5 Dec 2011 15:23:24 -0000
Received: from caiajhbdccac.dreamhost.com (HELO homiemail-a21.g.dreamhost.com)
	(208.97.132.202) by server-16.tower-21.messagelabs.com with SMTP;
	5 Dec 2011 15:23:24 -0000
Received: from homiemail-a21.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTP id 0F50A30007B;
	Mon,  5 Dec 2011 07:23:24 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=ZZcrEsAjfPmhAKgm30MTZ2k0ag/kX19s9sT8Ir/y96/X
	qp08vv12IbZuW1T2bxqEONDxMQHIi66nxrXF36DVyup/YnB10BZzzCBrT0/+9GWw
	byF1Wm0hPMVcEuHHkZIBKFEc+WD7OO39N+rE/ACgY61SpROxASGzmRaH7H+pkyc=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=7Ye2PJ7+WcJrq/PX6qMLpvFtZeo=; b=YErsjw3g6Zg
	FyGb7x/jDM+D05WAvAO02Bbel0y6Yf9KEbTfPqbTV0Lhqc/2ak6bbU5Cw9cU0UQG
	9H7lXRF1H3rc8ncmDALe/6PIlXWW2CI2zNg/WEZNdEsxmbJMaM7lLBRkcyX6eJvg
	giV3g9xnYg20NF4/CDuENg4dylhwWpgc=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTPSA id 29FBB300064; 
	Mon,  5 Dec 2011 07:23:23 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 4c4a9ed0728c7ba34b099ca80b0d82470cf4b114
Message-Id: <4c4a9ed0728c7ba34b09.1323098648@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1323098647@xdev.gridcentric.ca>
References: <patchbomb.1323098647@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Mon, 05 Dec 2011 10:24:08 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, keir.xen@gmail.com, tim@xen.org, olaf@aepfle.de,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 1 of 2] Allow decrease_reservation to be
 preempted if remove_page returns negative
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/common/memory.c |  29 ++++++++++++++++++++++++++++-
 1 files changed, 28 insertions(+), 1 deletions(-)


This will allow for handling of full paging rings in a more graceful manner.
ATM, remove_page does not return negative values, so this code is not yet
exercised.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 790cd814bee8 -r 4c4a9ed0728c xen/common/memory.c
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -226,6 +226,8 @@ static void decrease_reservation(struct 
 
     for ( i = a->nr_done; i < a->nr_extents; i++ )
     {
+        int one_remove_succeeded = 0;
+
         if ( hypercall_preempt_check() )
         {
             a->preempted = 1;
@@ -255,8 +257,33 @@ static void decrease_reservation(struct 
             continue;
 
         for ( j = 0; j < (1 << a->extent_order); j++ )
-            if ( !guest_remove_page(a->domain, gmfn + j) )
+        {
+            int rv = guest_remove_page(a->domain, gmfn + j);
+            /* negative rv is a result of a mem event ring full
+             * in the presence of paging. We preempt the hypercall */
+            if ( rv < 0 )
+            {
+                /* Indicate we're done with this extent */
+                if ((j+1) == (1 << a->extent_order))
+                    i++;
+                a->preempted = 1;
+                raise_softirq(SCHEDULE_SOFTIRQ);
                 goto out;
+            }
+            /* rv of zero means we tried to remove a gfn with no backing
+             * mfn. It can be a bad argument, or, a continuation in the midst
+             * of an extent. Heuristically determine second case. */
+            if ( !rv )
+            {
+                /* Has to be first extent */
+                if ( i != a->nr_done )
+                    goto out;
+                /* No previous remove in this extent must have succeeded */
+                if ( one_remove_succeeded )
+                    goto out;
+            } else
+                one_remove_succeeded = 1;
+        }
     }
 
  out:

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 15:24:23 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 15:24:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXaOp-0000Zb-A9; Mon, 05 Dec 2011 15:24:11 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RXaOn-0000ZF-LO
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 15:24:09 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-16.tower-21.messagelabs.com!1323098604!306002!1
X-Originating-IP: [208.97.132.202]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4yMDIgPT4gMTYyNDk=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8626 invoked from network); 5 Dec 2011 15:23:24 -0000
Received: from caiajhbdccac.dreamhost.com (HELO homiemail-a21.g.dreamhost.com)
	(208.97.132.202) by server-16.tower-21.messagelabs.com with SMTP;
	5 Dec 2011 15:23:24 -0000
Received: from homiemail-a21.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTP id 0F50A30007B;
	Mon,  5 Dec 2011 07:23:24 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=ZZcrEsAjfPmhAKgm30MTZ2k0ag/kX19s9sT8Ir/y96/X
	qp08vv12IbZuW1T2bxqEONDxMQHIi66nxrXF36DVyup/YnB10BZzzCBrT0/+9GWw
	byF1Wm0hPMVcEuHHkZIBKFEc+WD7OO39N+rE/ACgY61SpROxASGzmRaH7H+pkyc=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=7Ye2PJ7+WcJrq/PX6qMLpvFtZeo=; b=YErsjw3g6Zg
	FyGb7x/jDM+D05WAvAO02Bbel0y6Yf9KEbTfPqbTV0Lhqc/2ak6bbU5Cw9cU0UQG
	9H7lXRF1H3rc8ncmDALe/6PIlXWW2CI2zNg/WEZNdEsxmbJMaM7lLBRkcyX6eJvg
	giV3g9xnYg20NF4/CDuENg4dylhwWpgc=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTPSA id 29FBB300064; 
	Mon,  5 Dec 2011 07:23:23 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 4c4a9ed0728c7ba34b099ca80b0d82470cf4b114
Message-Id: <4c4a9ed0728c7ba34b09.1323098648@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1323098647@xdev.gridcentric.ca>
References: <patchbomb.1323098647@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Mon, 05 Dec 2011 10:24:08 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, keir.xen@gmail.com, tim@xen.org, olaf@aepfle.de,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 1 of 2] Allow decrease_reservation to be
 preempted if remove_page returns negative
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/common/memory.c |  29 ++++++++++++++++++++++++++++-
 1 files changed, 28 insertions(+), 1 deletions(-)


This will allow for handling of full paging rings in a more graceful manner.
ATM, remove_page does not return negative values, so this code is not yet
exercised.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 790cd814bee8 -r 4c4a9ed0728c xen/common/memory.c
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -226,6 +226,8 @@ static void decrease_reservation(struct 
 
     for ( i = a->nr_done; i < a->nr_extents; i++ )
     {
+        int one_remove_succeeded = 0;
+
         if ( hypercall_preempt_check() )
         {
             a->preempted = 1;
@@ -255,8 +257,33 @@ static void decrease_reservation(struct 
             continue;
 
         for ( j = 0; j < (1 << a->extent_order); j++ )
-            if ( !guest_remove_page(a->domain, gmfn + j) )
+        {
+            int rv = guest_remove_page(a->domain, gmfn + j);
+            /* negative rv is a result of a mem event ring full
+             * in the presence of paging. We preempt the hypercall */
+            if ( rv < 0 )
+            {
+                /* Indicate we're done with this extent */
+                if ((j+1) == (1 << a->extent_order))
+                    i++;
+                a->preempted = 1;
+                raise_softirq(SCHEDULE_SOFTIRQ);
                 goto out;
+            }
+            /* rv of zero means we tried to remove a gfn with no backing
+             * mfn. It can be a bad argument, or, a continuation in the midst
+             * of an extent. Heuristically determine second case. */
+            if ( !rv )
+            {
+                /* Has to be first extent */
+                if ( i != a->nr_done )
+                    goto out;
+                /* No previous remove in this extent must have succeeded */
+                if ( one_remove_succeeded )
+                    goto out;
+            } else
+                one_remove_succeeded = 1;
+        }
     }
 
  out:

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 15:24:29 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 15:24:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXaOr-0000Zs-4J; Mon, 05 Dec 2011 15:24:13 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RXaOo-0000ZG-VN
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 15:24:11 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-7.tower-216.messagelabs.com!1323098605!6244129!1
X-Originating-IP: [208.97.132.207]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4yMDcgPT4gMTU4NTI=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1866 invoked from network); 5 Dec 2011 15:23:26 -0000
Received: from caiajhbdccah.dreamhost.com (HELO homiemail-a21.g.dreamhost.com)
	(208.97.132.207) by server-7.tower-216.messagelabs.com with SMTP;
	5 Dec 2011 15:23:26 -0000
Received: from homiemail-a21.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTP id 529EF300072;
	Mon,  5 Dec 2011 07:23:25 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=Jfccmdj1soeJqw50C+OSHMpzx0iElATB4wgzN5xakkv7
	4bI9Y5Or3prwAKvnz4H463w8Zlda3x4jistSo+12+nfrxwsKZxiwRQ0NVkEOup5n
	uDWq7dI03JpLnz1n6X7g/K+Sdv19x34DkoollBrq+NCwQ900rYZChBBjHYAem6k=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=3RxLt78l4VSCNH6sFIlw7s6rdrA=; b=rLB9WqZXvcn
	R/zJs1UCl/BDvMs8Yt+zKWPvRNY/UszHebBHOtfiQeAyZIC6p9lhgb6taUz3HhIf
	zINhfXuWAP1dXvM53PBrP/z39gcpgzilqg4m3WfK2f9UbuZ1cKtGSEwPh81GzFWc
	Os+8TI9CI3tSU5hsKfGCOwFLFGvNCqDI=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTPSA id 40092300064; 
	Mon,  5 Dec 2011 07:23:24 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: d1d238616c0c20bc808d28d9fe173c1e06d7a788
Message-Id: <d1d238616c0c20bc808d.1323098649@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1323098647@xdev.gridcentric.ca>
References: <patchbomb.1323098647@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Mon, 05 Dec 2011 10:24:09 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, keir.xen@gmail.com, tim@xen.org, olaf@aepfle.de,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 2 of 2] Improve ring management for memory
 events. Do not lose guest events
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/hvm/hvm.c          |   21 ++-
 xen/arch/x86/mm/mem_event.c     |  203 +++++++++++++++++++++++++++++----------
 xen/arch/x86/mm/mem_sharing.c   |   17 ++-
 xen/arch/x86/mm/p2m.c           |   47 +++++----
 xen/common/memory.c             |    7 +-
 xen/include/asm-x86/mem_event.h |   16 ++-
 xen/include/asm-x86/p2m.h       |    6 +-
 xen/include/xen/mm.h            |    2 +
 xen/include/xen/sched.h         |    5 +-
 9 files changed, 229 insertions(+), 95 deletions(-)


The memevent code currently has a mechanism for reserving space in the ring
before putting an event, but each caller must individually ensure that the
vCPUs are correctly paused if no space is available.

This fixes that issue by reversing the semantics: we ensure that enough space
is always left for one event per vCPU in the ring.  If, after putting the
current request, this constraint will be violated by the current vCPU
when putting putting another request in the ring, we pause the vCPU.

For mem events caused by foreign vcpus, we simply drop the event if the
space constraint will be violated. Foreign vcpus are expected to retry
mapping operations (and thus the associated paging populate mem events
will be re issued).

Finally, guests can cause an unbound number of paging drop events via the
balloon -> decrease_reservation hypercall. Thus, notify the hypercall
there is no more space in the ring so a continuation is scheduled.

With all these mechanisms, no guest events are lost and there is no need
for wait-queues. Our testing includes 1. ballooning down 512 MiBs; 2. a
mem event mode in which every page access in a four-vCPU guest results in
an event, with no vCPU pausing, and the four vCPUs touching all RAM. No
guest events were lost in either case, and qemu-dm had no mapping problems.

Finally, mark_and_pause_vcpus was misleading, beacause it wasn't strictly
pausing the vcpu's, rather sending them to sleep. Change to actual
vcpu_pause, which protects wakeups via an atomic count. This is useful when
an event pauses a vcpu and the vcpu gets mark and paused due to ring congestion.

Signed-off-by: Adin Scannell <adin@scannell.ca>
Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 4c4a9ed0728c -r d1d238616c0c xen/arch/x86/hvm/hvm.c
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -4119,7 +4119,6 @@ static int hvm_memory_event_traps(long p
     struct vcpu* v = current;
     struct domain *d = v->domain;
     mem_event_request_t req;
-    int rc;
 
     if ( !(p & HVMPME_MODE_MASK) ) 
         return 0;
@@ -4127,10 +4126,7 @@ static int hvm_memory_event_traps(long p
     if ( (p & HVMPME_onchangeonly) && (value == old) )
         return 1;
     
-    rc = mem_event_check_ring(d, &d->mem_event->access);
-    if ( rc )
-        return rc;
-    
+  
     memset(&req, 0, sizeof(req));
     req.type = MEM_EVENT_TYPE_ACCESS;
     req.reason = reason;
@@ -4150,7 +4146,20 @@ static int hvm_memory_event_traps(long p
         req.gla_valid = 1;
     }
     
-    mem_event_put_request(d, &d->mem_event->access, &req);
+    if ( mem_event_put_request(d, &d->mem_event->access, &req) == -ENOSYS )
+    {
+        /* rc == -ENOSYS
+         * If there was no ring to send the event, then simply unpause the
+         * vcpu (if we had previously paused it). It will retry the 
+         * instruction (with the exception "handled") and go on */
+        if ( req.flags & MEM_EVENT_FLAG_VCPU_PAUSED ) 
+            vcpu_unpause(v);
+        /* rc == -EBUSY
+         * If the ring is full, the vcpu has been marked and paused,
+         * and the exception has been communicated to the consumer.
+         * Once there is room in the ring, the vcpu will be woken up 
+         * and will retry. */
+    }
     
     return 1;
 }
diff -r 4c4a9ed0728c -r d1d238616c0c xen/arch/x86/mm/mem_event.c
--- a/xen/arch/x86/mm/mem_event.c
+++ b/xen/arch/x86/mm/mem_event.c
@@ -93,6 +93,9 @@ static int mem_event_enable(
     put_gfn(dom_mem_event, ring_gfn);
     put_gfn(dom_mem_event, shared_gfn); 
 
+    /* Set the number of currently blocked vCPUs to 0. */
+    med->blocked = 0;
+
     /* Allocate event channel */
     rc = alloc_unbound_xen_event_channel(d->vcpu[0],
                                          current->domain->domain_id,
@@ -111,7 +114,7 @@ static int mem_event_enable(
     mem_event_ring_lock_init(med);
 
     /* Wake any VCPUs paused for memory events */
-    mem_event_unpause_vcpus(d);
+    mem_event_unpause_vcpus(d, med);
 
     return 0;
 
@@ -125,8 +128,57 @@ static int mem_event_enable(
     return rc;
 }
 
-static int mem_event_disable(struct mem_event_domain *med)
+static void __mem_event_unpause_vcpus(struct domain *d, 
+                                        struct mem_event_domain *med, int free)
 {
+    struct vcpu *v;
+    int i, j, k;
+    int online = d->max_vcpus;
+
+    /*
+     * We ensure that we only have vCPUs online if there are enough free slots
+     * for their memory events to be processed.  This will ensure that no
+     * memory events are lost (due to the fact that certain types of events
+     * cannot be replayed, we need to ensure that there is space in the ring
+     * for when they are hit). 
+     * See comment below in mem_event_put_request().
+     */
+    for_each_vcpu ( d, v )
+        if ( test_bit(_VPF_mem_event, &v->pause_flags) )
+            online--;
+
+    /* We remember which vcpu last woke up to avoid scanning always linearly
+     * from zero and starving higher-numbered vcpus under high load */
+    if ( d->vcpu )
+    {
+        for (i = med->last_vcpu_wake_up + 1, j = 0; j < d->max_vcpus; i++, j++)
+        {
+            k = i % d->max_vcpus;
+            v = d->vcpu[k];
+            if ( !v ) continue;
+
+            if ( !(med->blocked) || online >= free )
+                break;
+            if ( test_and_clear_bit(_VPF_mem_event, &v->pause_flags) )
+            {
+                vcpu_unpause(v);
+                online++;
+                med->blocked--;
+                med->last_vcpu_wake_up = k;
+            }
+        }
+    }
+}
+
+static int mem_event_disable(struct domain *d, struct mem_event_domain *med)
+{
+    if ( !med )
+        return 0;
+
+    /* Wake up everybody, regardless */
+    med->last_vcpu_wake_up = 0;
+    __mem_event_unpause_vcpus(d, med, d->max_vcpus);
+
     unmap_domain_page(med->ring_page);
     med->ring_page = NULL;
 
@@ -136,34 +188,98 @@ static int mem_event_disable(struct mem_
     return 0;
 }
 
-void mem_event_put_request(struct domain *d, struct mem_event_domain *med, mem_event_request_t *req)
+static inline int mem_event_ring_free(struct domain *d, struct mem_event_domain *med)
 {
+    int free_requests;
+
+    free_requests = RING_FREE_REQUESTS(&med->front_ring);
+    if ( unlikely(free_requests < d->max_vcpus) )
+    {
+        /* This may happen during normal operation (hopefully not often). */
+        gdprintk(XENLOG_INFO, "mem_event request slots for domain %d: %d\n",
+                               d->domain_id, free_requests);
+    }
+
+    return free_requests;
+}
+
+/* Return values
+ * zero: success
+ * -ENOSYS: no ring
+ * -EAGAIN: ring is full and the event has not been transmitted.
+ *          Only foreign vcpu's get EAGAIN
+ * -EBUSY: guest vcpu has been paused due to ring congestion
+ */ 
+int mem_event_put_request(struct domain *d, struct mem_event_domain *med, mem_event_request_t *req)
+{
+    int ret = 0;
+    int foreign = (d != current->domain);
     mem_event_front_ring_t *front_ring;
     RING_IDX req_prod;
 
+    if ( mem_event_check_ring(d, med) )
+        return -ENOSYS;
+
     mem_event_ring_lock(med);
 
-    front_ring = &med->front_ring;
-    req_prod = front_ring->req_prod_pvt;
-
-    if ( current->domain != d )
+    if ( foreign &&
+        (mem_event_ring_free(d, med) <= (d->max_vcpus - med->blocked)) )
     {
-        req->flags |= MEM_EVENT_FLAG_FOREIGN;
-        ASSERT( !(req->flags & MEM_EVENT_FLAG_VCPU_PAUSED) );
+        /* This is an event caused by a foreign mapper. Putting the event
+         * in the ring could preclude a guest vcpu from putting an event.
+         * The foreign mapper has to retry. */
+        gdprintk(XENLOG_DEBUG, "Foreign-caused (%u) event will not be put"
+                 " in ring with %d slots %d sleepers", current->domain->domain_id, 
+                 mem_event_ring_free(d, med), med->blocked);
+        mem_event_ring_unlock(med);
+        return -EAGAIN;
     }
 
-    /* Copy request */
-    memcpy(RING_GET_REQUEST(front_ring, req_prod), req, sizeof(*req));
-    req_prod++;
+    if ( mem_event_ring_free(d, med) == 0 )
+    {
+        /* This *should* never happen */
+        gdprintk(XENLOG_WARNING, "possible lost mem_event for domain %d\n",
+                                 d->domain_id);
+        ret = -EBUSY;
+    }
+    else
+    {
+        front_ring = &med->front_ring;
+        req_prod = front_ring->req_prod_pvt;
 
-    /* Update ring */
-    med->req_producers--;
-    front_ring->req_prod_pvt = req_prod;
-    RING_PUSH_REQUESTS(front_ring);
+        if ( foreign )
+        {
+            req->flags |= MEM_EVENT_FLAG_FOREIGN;
+            ASSERT( !(req->flags & MEM_EVENT_FLAG_VCPU_PAUSED) );
+        }
+
+        /* Copy request */
+        memcpy(RING_GET_REQUEST(front_ring, req_prod), req, sizeof(*req));
+        req_prod++;
+
+        /* Update ring */
+        front_ring->req_prod_pvt = req_prod;
+        RING_PUSH_REQUESTS(front_ring);
+    }
+
+    /*
+     * We ensure that each vcpu can put at least *one* event -- because some
+     * events are not repeatable, such as dropping a page.  This will ensure no
+     * vCPU is left with an event that they must place on the ring, but cannot.
+     * They will be paused after the event is placed.
+     * See comment above in __mem_event_unpause_vcpus().
+     */
+    if ( !foreign && mem_event_ring_free(d, med) < d->max_vcpus )
+    {
+        mem_event_mark_and_pause(current, med);
+        ret = -EBUSY;
+    }
 
     mem_event_ring_unlock(med);
 
     notify_via_xen_event_channel(d, med->xen_port);
+
+    return ret;
 }
 
 int mem_event_get_response(struct mem_event_domain *med, mem_event_response_t *rsp)
@@ -195,52 +311,31 @@ int mem_event_get_response(struct mem_ev
     return 1;
 }
 
-void mem_event_unpause_vcpus(struct domain *d)
+void mem_event_unpause_vcpus(struct domain *d, struct mem_event_domain *med)
 {
-    struct vcpu *v;
+    mem_event_ring_lock(med);
 
-    for_each_vcpu ( d, v )
-        if ( test_and_clear_bit(_VPF_mem_event, &v->pause_flags) )
-            vcpu_wake(v);
+    if ( med->blocked )
+        __mem_event_unpause_vcpus(d, med, mem_event_ring_free(d, med));
+
+    mem_event_ring_unlock(med);
 }
 
-void mem_event_mark_and_pause(struct vcpu *v)
+void mem_event_mark_and_pause(struct vcpu *v, struct mem_event_domain *med)
 {
-    set_bit(_VPF_mem_event, &v->pause_flags);
-    vcpu_sleep_nosync(v);
-}
-
-void mem_event_put_req_producers(struct mem_event_domain *med)
-{
-    mem_event_ring_lock(med);
-    med->req_producers--;
-    mem_event_ring_unlock(med);
+    if ( !test_and_set_bit(_VPF_mem_event, &v->pause_flags) )
+    {
+        vcpu_pause_nosync(v);
+        med->blocked++;
+    }
 }
 
 int mem_event_check_ring(struct domain *d, struct mem_event_domain *med)
 {
-    struct vcpu *curr = current;
-    int free_requests;
-    int ring_full = 1;
+    if ( !med->ring_page )
+        return -ENOSYS;
 
-    if ( !med->ring_page )
-        return -1;
-
-    mem_event_ring_lock(med);
-
-    free_requests = RING_FREE_REQUESTS(&med->front_ring);
-    if ( med->req_producers < free_requests )
-    {
-        med->req_producers++;
-        ring_full = 0;
-    }
-
-    if ( ring_full && (curr->domain == d) )
-        mem_event_mark_and_pause(curr);
-
-    mem_event_ring_unlock(med);
-
-    return ring_full;
+    return 0;
 }
 
 /* Registered with Xen-bound event channel for incoming notifications. */
@@ -323,7 +418,7 @@ int mem_event_domctl(struct domain *d, x
         case XEN_DOMCTL_MEM_EVENT_OP_PAGING_DISABLE:
         {
             if ( med->ring_page )
-                rc = mem_event_disable(med);
+                rc = mem_event_disable(d, med);
         }
         break;
 
@@ -362,7 +457,7 @@ int mem_event_domctl(struct domain *d, x
         case XEN_DOMCTL_MEM_EVENT_OP_ACCESS_DISABLE:
         {
             if ( med->ring_page )
-                rc = mem_event_disable(med);
+                rc = mem_event_disable(d, med);
         }
         break;
 
diff -r 4c4a9ed0728c -r d1d238616c0c xen/arch/x86/mm/mem_sharing.c
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -281,12 +281,20 @@ static struct page_info* mem_sharing_all
     vcpu_pause_nosync(v);
     req.flags |= MEM_EVENT_FLAG_VCPU_PAUSED;
 
-    if(mem_event_check_ring(d, &d->mem_event->share)) return page;
-
     req.gfn = gfn;
     req.p2mt = p2m_ram_shared;
     req.vcpu_id = v->vcpu_id;
-    mem_event_put_request(d, &d->mem_event->share, &req);
+
+    /* If there is no ring, and we're out of memory, then
+     * there is no way out. */
+    if ( mem_event_put_request(d, &d->mem_event->share, 
+                                &req) == -ENOSYS )
+    {
+        gdprintk(XENLOG_ERR, 
+                 "Failed alloc on unshare path for %hu and no ring "
+                 "to upcall\n", d->domain_id);
+        domain_crash(d);
+    }
 
     return page;
 }
@@ -310,6 +318,9 @@ int mem_sharing_sharing_resume(struct do
             vcpu_unpause(d->vcpu[rsp.vcpu_id]);
     }
 
+    /* Unpause any domains that were paused because the ring was full */
+    mem_event_unpause_vcpus(d, &d->mem_event->paging);
+
     return 0;
 }
 
diff -r 4c4a9ed0728c -r d1d238616c0c xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -871,13 +871,15 @@ int p2m_mem_paging_evict(struct domain *
  * p2m_mem_paging_drop_page() will notify the pager that a paged-out gfn was
  * released by the guest. The pager is supposed to drop its reference of the
  * gfn.
+ * Returns zero on success, EAGAIN for foreign mappers and EBUSY for guest 
+ * vcpus if the ring is congested.
  */
-void p2m_mem_paging_drop_page(struct domain *d, unsigned long gfn)
+int p2m_mem_paging_drop_page(struct domain *d, unsigned long gfn)
 {
     struct vcpu *v = current;
     mem_event_request_t req;
 
-    /* Check that there's space on the ring for this request */
+    /* Check that there's a paging listener who cares about this */
     if ( mem_event_check_ring(d, &d->mem_event->paging) == 0)
     {
         /* Send release notification to pager */
@@ -886,8 +888,11 @@ void p2m_mem_paging_drop_page(struct dom
         req.gfn = gfn;
         req.vcpu_id = v->vcpu_id;
 
-        mem_event_put_request(d, &d->mem_event->paging, &req);
+        /* rc cannot be ENOSYS, as we checked before */
+        return mem_event_put_request(d, &d->mem_event->paging, &req);
     }
+
+    return 0;
 }
 
 /**
@@ -920,9 +925,14 @@ void p2m_mem_paging_populate(struct doma
     mfn_t mfn;
     struct p2m_domain *p2m = p2m_get_hostp2m(d);
 
-    /* Check that there's space on the ring for this request */
+    /* We're paging. There should be a ring */
     if ( mem_event_check_ring(d, &d->mem_event->paging) )
+    {
+        gdprintk(XENLOG_ERR, "Domain %hu paging gfn %lx yet no ring "
+                    "in place\n", d->domain_id, gfn);
+        domain_crash(d);
         return;
+    }
 
     memset(&req, 0, sizeof(req));
     req.type = MEM_EVENT_TYPE_PAGING;
@@ -951,7 +961,6 @@ void p2m_mem_paging_populate(struct doma
     else if ( p2mt != p2m_ram_paging_out && p2mt != p2m_ram_paged )
     {
         /* gfn is already on its way back and vcpu is not paused */
-        mem_event_put_req_producers(&d->mem_event->paging);
         return;
     }
 
@@ -960,7 +969,10 @@ void p2m_mem_paging_populate(struct doma
     req.p2mt = p2mt;
     req.vcpu_id = v->vcpu_id;
 
-    mem_event_put_request(d, &d->mem_event->paging, &req);
+    (void)mem_event_put_request(d, &d->mem_event->paging, &req);
+    /* If the ring is full, foreign mappers will retry, and guest
+     * vcpus remain paused. Guest vcpu will wake up and retry once
+     * the consumer has made some space in the ring. */
 }
 
 /**
@@ -1094,7 +1106,7 @@ void p2m_mem_paging_resume(struct domain
     }
 
     /* Unpause any domains that were paused because the ring was full */
-    mem_event_unpause_vcpus(d);
+    mem_event_unpause_vcpus(d, &d->mem_event->paging);
 }
 
 void p2m_mem_access_check(unsigned long gpa, bool_t gla_valid, unsigned long gla, 
@@ -1105,7 +1117,6 @@ void p2m_mem_access_check(unsigned long 
     unsigned long gfn = gpa >> PAGE_SHIFT;
     struct domain *d = v->domain;    
     struct p2m_domain* p2m = p2m_get_hostp2m(d);
-    int res;
     mfn_t mfn;
     p2m_type_t p2mt;
     p2m_access_t p2ma;
@@ -1123,17 +1134,14 @@ void p2m_mem_access_check(unsigned long 
     p2m_unlock(p2m);
 
     /* Otherwise, check if there is a memory event listener, and send the message along */
-    res = mem_event_check_ring(d, &d->mem_event->access);
-    if ( res < 0 ) 
+    if ( mem_event_check_ring(d, &d->mem_event->access) == -ENOSYS ) 
     {
         /* No listener */
         if ( p2m->access_required ) 
         {
-            printk(XENLOG_INFO 
-                   "Memory access permissions failure, no mem_event listener: pausing VCPU %d, dom %d\n",
-                   v->vcpu_id, d->domain_id);
-
-            mem_event_mark_and_pause(v);
+            gdprintk(XENLOG_INFO, "Memory access permissions failure, no mem_event "
+                     "listener VCPU %d, dom %d\n", v->vcpu_id, d->domain_id);
+            domain_crash(v->domain);
         }
         else
         {
@@ -1145,8 +1153,6 @@ void p2m_mem_access_check(unsigned long 
 
         return;
     }
-    else if ( res > 0 )
-        return;  /* No space in buffer; VCPU paused */
 
     memset(&req, 0, sizeof(req));
     req.type = MEM_EVENT_TYPE_ACCESS;
@@ -1167,9 +1173,8 @@ void p2m_mem_access_check(unsigned long 
     
     req.vcpu_id = v->vcpu_id;
 
-    mem_event_put_request(d, &d->mem_event->access, &req);
-
-    /* VCPU paused, mem event request sent */
+    (void)mem_event_put_request(d, &d->mem_event->access, &req);
+    /* VCPU paused */
 }
 
 void p2m_mem_access_resume(struct domain *d)
@@ -1188,7 +1193,7 @@ void p2m_mem_access_resume(struct domain
 
     /* Unpause any domains that were paused because the ring was full or no listener 
      * was available */
-    mem_event_unpause_vcpus(d);
+    mem_event_unpause_vcpus(d, &d->mem_event->access);
 }
 
 
diff -r 4c4a9ed0728c -r d1d238616c0c xen/common/memory.c
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -165,10 +165,13 @@ int guest_remove_page(struct domain *d, 
     mfn = mfn_x(get_gfn(d, gmfn, &p2mt)); 
     if ( unlikely(p2m_is_paging(p2mt)) )
     {
+        int rc; 
         guest_physmap_remove_page(d, gmfn, mfn, 0);
-        p2m_mem_paging_drop_page(d, gmfn);
+        rc = p2m_mem_paging_drop_page(d, gmfn);
         put_gfn(d, gmfn);
-        return 1;
+        /* drop_page returns zero on success, we return 1 on success.
+         * drop_page returns negative on error, never returns 1. */
+        return rc ? rc : 1;
     }
 #else
     mfn = gmfn_to_mfn(d, gmfn);
diff -r 4c4a9ed0728c -r d1d238616c0c xen/include/asm-x86/mem_event.h
--- a/xen/include/asm-x86/mem_event.h
+++ b/xen/include/asm-x86/mem_event.h
@@ -25,12 +25,18 @@
 #define __MEM_EVENT_H__
 
 /* Pauses VCPU while marking pause flag for mem event */
-void mem_event_mark_and_pause(struct vcpu *v);
+void mem_event_mark_and_pause(struct vcpu *v, struct mem_event_domain *med);
 int mem_event_check_ring(struct domain *d, struct mem_event_domain *med);
-void mem_event_put_req_producers(struct mem_event_domain *med);
-void mem_event_put_request(struct domain *d, struct mem_event_domain *med, mem_event_request_t *req);
-int mem_event_get_response(struct mem_event_domain *med, mem_event_response_t *rsp);
-void mem_event_unpause_vcpus(struct domain *d);
+void mem_event_unpause_vcpus(struct domain *d, struct mem_event_domain *med);
+
+/* Returns 0 on success, -ENOSYS if there is no ring, -EBUSY if there is 
+ * a ring or no space. FOr success or -EBUSY. the vCPU is left blocked to 
+ * ensure that the ring does not lose events.  In general, put_request should 
+ * not fail, as it attempts to ensure that each vCPU can put at least one req. */
+int mem_event_put_request(struct domain *d, struct mem_event_domain *med,
+                            mem_event_request_t *req);
+int mem_event_get_response(struct mem_event_domain *med,
+                            mem_event_response_t *rsp);
 
 int mem_event_domctl(struct domain *d, xen_domctl_mem_event_op_t *mec,
                      XEN_GUEST_HANDLE(void) u_domctl);
diff -r 4c4a9ed0728c -r d1d238616c0c xen/include/asm-x86/p2m.h
--- a/xen/include/asm-x86/p2m.h
+++ b/xen/include/asm-x86/p2m.h
@@ -475,7 +475,7 @@ int p2m_mem_paging_nominate(struct domai
 /* Evict a frame */
 int p2m_mem_paging_evict(struct domain *d, unsigned long gfn);
 /* Tell xenpaging to drop a paged out frame */
-void p2m_mem_paging_drop_page(struct domain *d, unsigned long gfn);
+int p2m_mem_paging_drop_page(struct domain *d, unsigned long gfn);
 /* Start populating a paged out frame */
 void p2m_mem_paging_populate(struct domain *d, unsigned long gfn);
 /* Prepare the p2m for paging a frame in */
@@ -483,8 +483,8 @@ int p2m_mem_paging_prep(struct domain *d
 /* Resume normal operation (in case a domain was paused) */
 void p2m_mem_paging_resume(struct domain *d);
 #else
-static inline void p2m_mem_paging_drop_page(struct domain *d, unsigned long gfn)
-{ }
+static inline int p2m_mem_paging_drop_page(struct domain *d, unsigned long gfn)
+{ return 0; }
 static inline void p2m_mem_paging_populate(struct domain *d, unsigned long gfn)
 { }
 #endif
diff -r 4c4a9ed0728c -r d1d238616c0c xen/include/xen/mm.h
--- a/xen/include/xen/mm.h
+++ b/xen/include/xen/mm.h
@@ -318,6 +318,8 @@ page_list_splice(struct page_list_head *
 
 void scrub_one_page(struct page_info *);
 
+/* Returns 1 on success, 0 on error, negative if the ring
+ * for event propagation is full in the presence of paging */
 int guest_remove_page(struct domain *d, unsigned long gmfn);
 
 #define RAM_TYPE_CONVENTIONAL 0x00000001
diff -r 4c4a9ed0728c -r d1d238616c0c xen/include/xen/sched.h
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -183,13 +183,16 @@ struct mem_event_domain
 {
     /* ring lock */
     spinlock_t ring_lock;
-    unsigned int req_producers;
     /* shared page */
     mem_event_shared_page_t *shared_page;
     /* shared ring page */
     void *ring_page;
     /* front-end ring */
     mem_event_front_ring_t front_ring;
+    /* the number of vCPUs blocked */
+    unsigned int blocked;
+    /* The last vcpu woken up */
+    unsigned int last_vcpu_wake_up;
     /* event channel port (vcpu0 only) */
     int xen_port;
 };

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 15:24:29 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 15:24:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXaOr-0000Zs-4J; Mon, 05 Dec 2011 15:24:13 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RXaOo-0000ZG-VN
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 15:24:11 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-7.tower-216.messagelabs.com!1323098605!6244129!1
X-Originating-IP: [208.97.132.207]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4yMDcgPT4gMTU4NTI=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1866 invoked from network); 5 Dec 2011 15:23:26 -0000
Received: from caiajhbdccah.dreamhost.com (HELO homiemail-a21.g.dreamhost.com)
	(208.97.132.207) by server-7.tower-216.messagelabs.com with SMTP;
	5 Dec 2011 15:23:26 -0000
Received: from homiemail-a21.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTP id 529EF300072;
	Mon,  5 Dec 2011 07:23:25 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=Jfccmdj1soeJqw50C+OSHMpzx0iElATB4wgzN5xakkv7
	4bI9Y5Or3prwAKvnz4H463w8Zlda3x4jistSo+12+nfrxwsKZxiwRQ0NVkEOup5n
	uDWq7dI03JpLnz1n6X7g/K+Sdv19x34DkoollBrq+NCwQ900rYZChBBjHYAem6k=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=3RxLt78l4VSCNH6sFIlw7s6rdrA=; b=rLB9WqZXvcn
	R/zJs1UCl/BDvMs8Yt+zKWPvRNY/UszHebBHOtfiQeAyZIC6p9lhgb6taUz3HhIf
	zINhfXuWAP1dXvM53PBrP/z39gcpgzilqg4m3WfK2f9UbuZ1cKtGSEwPh81GzFWc
	Os+8TI9CI3tSU5hsKfGCOwFLFGvNCqDI=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTPSA id 40092300064; 
	Mon,  5 Dec 2011 07:23:24 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: d1d238616c0c20bc808d28d9fe173c1e06d7a788
Message-Id: <d1d238616c0c20bc808d.1323098649@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1323098647@xdev.gridcentric.ca>
References: <patchbomb.1323098647@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Mon, 05 Dec 2011 10:24:09 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, keir.xen@gmail.com, tim@xen.org, olaf@aepfle.de,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 2 of 2] Improve ring management for memory
 events. Do not lose guest events
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/hvm/hvm.c          |   21 ++-
 xen/arch/x86/mm/mem_event.c     |  203 +++++++++++++++++++++++++++++----------
 xen/arch/x86/mm/mem_sharing.c   |   17 ++-
 xen/arch/x86/mm/p2m.c           |   47 +++++----
 xen/common/memory.c             |    7 +-
 xen/include/asm-x86/mem_event.h |   16 ++-
 xen/include/asm-x86/p2m.h       |    6 +-
 xen/include/xen/mm.h            |    2 +
 xen/include/xen/sched.h         |    5 +-
 9 files changed, 229 insertions(+), 95 deletions(-)


The memevent code currently has a mechanism for reserving space in the ring
before putting an event, but each caller must individually ensure that the
vCPUs are correctly paused if no space is available.

This fixes that issue by reversing the semantics: we ensure that enough space
is always left for one event per vCPU in the ring.  If, after putting the
current request, this constraint will be violated by the current vCPU
when putting putting another request in the ring, we pause the vCPU.

For mem events caused by foreign vcpus, we simply drop the event if the
space constraint will be violated. Foreign vcpus are expected to retry
mapping operations (and thus the associated paging populate mem events
will be re issued).

Finally, guests can cause an unbound number of paging drop events via the
balloon -> decrease_reservation hypercall. Thus, notify the hypercall
there is no more space in the ring so a continuation is scheduled.

With all these mechanisms, no guest events are lost and there is no need
for wait-queues. Our testing includes 1. ballooning down 512 MiBs; 2. a
mem event mode in which every page access in a four-vCPU guest results in
an event, with no vCPU pausing, and the four vCPUs touching all RAM. No
guest events were lost in either case, and qemu-dm had no mapping problems.

Finally, mark_and_pause_vcpus was misleading, beacause it wasn't strictly
pausing the vcpu's, rather sending them to sleep. Change to actual
vcpu_pause, which protects wakeups via an atomic count. This is useful when
an event pauses a vcpu and the vcpu gets mark and paused due to ring congestion.

Signed-off-by: Adin Scannell <adin@scannell.ca>
Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 4c4a9ed0728c -r d1d238616c0c xen/arch/x86/hvm/hvm.c
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -4119,7 +4119,6 @@ static int hvm_memory_event_traps(long p
     struct vcpu* v = current;
     struct domain *d = v->domain;
     mem_event_request_t req;
-    int rc;
 
     if ( !(p & HVMPME_MODE_MASK) ) 
         return 0;
@@ -4127,10 +4126,7 @@ static int hvm_memory_event_traps(long p
     if ( (p & HVMPME_onchangeonly) && (value == old) )
         return 1;
     
-    rc = mem_event_check_ring(d, &d->mem_event->access);
-    if ( rc )
-        return rc;
-    
+  
     memset(&req, 0, sizeof(req));
     req.type = MEM_EVENT_TYPE_ACCESS;
     req.reason = reason;
@@ -4150,7 +4146,20 @@ static int hvm_memory_event_traps(long p
         req.gla_valid = 1;
     }
     
-    mem_event_put_request(d, &d->mem_event->access, &req);
+    if ( mem_event_put_request(d, &d->mem_event->access, &req) == -ENOSYS )
+    {
+        /* rc == -ENOSYS
+         * If there was no ring to send the event, then simply unpause the
+         * vcpu (if we had previously paused it). It will retry the 
+         * instruction (with the exception "handled") and go on */
+        if ( req.flags & MEM_EVENT_FLAG_VCPU_PAUSED ) 
+            vcpu_unpause(v);
+        /* rc == -EBUSY
+         * If the ring is full, the vcpu has been marked and paused,
+         * and the exception has been communicated to the consumer.
+         * Once there is room in the ring, the vcpu will be woken up 
+         * and will retry. */
+    }
     
     return 1;
 }
diff -r 4c4a9ed0728c -r d1d238616c0c xen/arch/x86/mm/mem_event.c
--- a/xen/arch/x86/mm/mem_event.c
+++ b/xen/arch/x86/mm/mem_event.c
@@ -93,6 +93,9 @@ static int mem_event_enable(
     put_gfn(dom_mem_event, ring_gfn);
     put_gfn(dom_mem_event, shared_gfn); 
 
+    /* Set the number of currently blocked vCPUs to 0. */
+    med->blocked = 0;
+
     /* Allocate event channel */
     rc = alloc_unbound_xen_event_channel(d->vcpu[0],
                                          current->domain->domain_id,
@@ -111,7 +114,7 @@ static int mem_event_enable(
     mem_event_ring_lock_init(med);
 
     /* Wake any VCPUs paused for memory events */
-    mem_event_unpause_vcpus(d);
+    mem_event_unpause_vcpus(d, med);
 
     return 0;
 
@@ -125,8 +128,57 @@ static int mem_event_enable(
     return rc;
 }
 
-static int mem_event_disable(struct mem_event_domain *med)
+static void __mem_event_unpause_vcpus(struct domain *d, 
+                                        struct mem_event_domain *med, int free)
 {
+    struct vcpu *v;
+    int i, j, k;
+    int online = d->max_vcpus;
+
+    /*
+     * We ensure that we only have vCPUs online if there are enough free slots
+     * for their memory events to be processed.  This will ensure that no
+     * memory events are lost (due to the fact that certain types of events
+     * cannot be replayed, we need to ensure that there is space in the ring
+     * for when they are hit). 
+     * See comment below in mem_event_put_request().
+     */
+    for_each_vcpu ( d, v )
+        if ( test_bit(_VPF_mem_event, &v->pause_flags) )
+            online--;
+
+    /* We remember which vcpu last woke up to avoid scanning always linearly
+     * from zero and starving higher-numbered vcpus under high load */
+    if ( d->vcpu )
+    {
+        for (i = med->last_vcpu_wake_up + 1, j = 0; j < d->max_vcpus; i++, j++)
+        {
+            k = i % d->max_vcpus;
+            v = d->vcpu[k];
+            if ( !v ) continue;
+
+            if ( !(med->blocked) || online >= free )
+                break;
+            if ( test_and_clear_bit(_VPF_mem_event, &v->pause_flags) )
+            {
+                vcpu_unpause(v);
+                online++;
+                med->blocked--;
+                med->last_vcpu_wake_up = k;
+            }
+        }
+    }
+}
+
+static int mem_event_disable(struct domain *d, struct mem_event_domain *med)
+{
+    if ( !med )
+        return 0;
+
+    /* Wake up everybody, regardless */
+    med->last_vcpu_wake_up = 0;
+    __mem_event_unpause_vcpus(d, med, d->max_vcpus);
+
     unmap_domain_page(med->ring_page);
     med->ring_page = NULL;
 
@@ -136,34 +188,98 @@ static int mem_event_disable(struct mem_
     return 0;
 }
 
-void mem_event_put_request(struct domain *d, struct mem_event_domain *med, mem_event_request_t *req)
+static inline int mem_event_ring_free(struct domain *d, struct mem_event_domain *med)
 {
+    int free_requests;
+
+    free_requests = RING_FREE_REQUESTS(&med->front_ring);
+    if ( unlikely(free_requests < d->max_vcpus) )
+    {
+        /* This may happen during normal operation (hopefully not often). */
+        gdprintk(XENLOG_INFO, "mem_event request slots for domain %d: %d\n",
+                               d->domain_id, free_requests);
+    }
+
+    return free_requests;
+}
+
+/* Return values
+ * zero: success
+ * -ENOSYS: no ring
+ * -EAGAIN: ring is full and the event has not been transmitted.
+ *          Only foreign vcpu's get EAGAIN
+ * -EBUSY: guest vcpu has been paused due to ring congestion
+ */ 
+int mem_event_put_request(struct domain *d, struct mem_event_domain *med, mem_event_request_t *req)
+{
+    int ret = 0;
+    int foreign = (d != current->domain);
     mem_event_front_ring_t *front_ring;
     RING_IDX req_prod;
 
+    if ( mem_event_check_ring(d, med) )
+        return -ENOSYS;
+
     mem_event_ring_lock(med);
 
-    front_ring = &med->front_ring;
-    req_prod = front_ring->req_prod_pvt;
-
-    if ( current->domain != d )
+    if ( foreign &&
+        (mem_event_ring_free(d, med) <= (d->max_vcpus - med->blocked)) )
     {
-        req->flags |= MEM_EVENT_FLAG_FOREIGN;
-        ASSERT( !(req->flags & MEM_EVENT_FLAG_VCPU_PAUSED) );
+        /* This is an event caused by a foreign mapper. Putting the event
+         * in the ring could preclude a guest vcpu from putting an event.
+         * The foreign mapper has to retry. */
+        gdprintk(XENLOG_DEBUG, "Foreign-caused (%u) event will not be put"
+                 " in ring with %d slots %d sleepers", current->domain->domain_id, 
+                 mem_event_ring_free(d, med), med->blocked);
+        mem_event_ring_unlock(med);
+        return -EAGAIN;
     }
 
-    /* Copy request */
-    memcpy(RING_GET_REQUEST(front_ring, req_prod), req, sizeof(*req));
-    req_prod++;
+    if ( mem_event_ring_free(d, med) == 0 )
+    {
+        /* This *should* never happen */
+        gdprintk(XENLOG_WARNING, "possible lost mem_event for domain %d\n",
+                                 d->domain_id);
+        ret = -EBUSY;
+    }
+    else
+    {
+        front_ring = &med->front_ring;
+        req_prod = front_ring->req_prod_pvt;
 
-    /* Update ring */
-    med->req_producers--;
-    front_ring->req_prod_pvt = req_prod;
-    RING_PUSH_REQUESTS(front_ring);
+        if ( foreign )
+        {
+            req->flags |= MEM_EVENT_FLAG_FOREIGN;
+            ASSERT( !(req->flags & MEM_EVENT_FLAG_VCPU_PAUSED) );
+        }
+
+        /* Copy request */
+        memcpy(RING_GET_REQUEST(front_ring, req_prod), req, sizeof(*req));
+        req_prod++;
+
+        /* Update ring */
+        front_ring->req_prod_pvt = req_prod;
+        RING_PUSH_REQUESTS(front_ring);
+    }
+
+    /*
+     * We ensure that each vcpu can put at least *one* event -- because some
+     * events are not repeatable, such as dropping a page.  This will ensure no
+     * vCPU is left with an event that they must place on the ring, but cannot.
+     * They will be paused after the event is placed.
+     * See comment above in __mem_event_unpause_vcpus().
+     */
+    if ( !foreign && mem_event_ring_free(d, med) < d->max_vcpus )
+    {
+        mem_event_mark_and_pause(current, med);
+        ret = -EBUSY;
+    }
 
     mem_event_ring_unlock(med);
 
     notify_via_xen_event_channel(d, med->xen_port);
+
+    return ret;
 }
 
 int mem_event_get_response(struct mem_event_domain *med, mem_event_response_t *rsp)
@@ -195,52 +311,31 @@ int mem_event_get_response(struct mem_ev
     return 1;
 }
 
-void mem_event_unpause_vcpus(struct domain *d)
+void mem_event_unpause_vcpus(struct domain *d, struct mem_event_domain *med)
 {
-    struct vcpu *v;
+    mem_event_ring_lock(med);
 
-    for_each_vcpu ( d, v )
-        if ( test_and_clear_bit(_VPF_mem_event, &v->pause_flags) )
-            vcpu_wake(v);
+    if ( med->blocked )
+        __mem_event_unpause_vcpus(d, med, mem_event_ring_free(d, med));
+
+    mem_event_ring_unlock(med);
 }
 
-void mem_event_mark_and_pause(struct vcpu *v)
+void mem_event_mark_and_pause(struct vcpu *v, struct mem_event_domain *med)
 {
-    set_bit(_VPF_mem_event, &v->pause_flags);
-    vcpu_sleep_nosync(v);
-}
-
-void mem_event_put_req_producers(struct mem_event_domain *med)
-{
-    mem_event_ring_lock(med);
-    med->req_producers--;
-    mem_event_ring_unlock(med);
+    if ( !test_and_set_bit(_VPF_mem_event, &v->pause_flags) )
+    {
+        vcpu_pause_nosync(v);
+        med->blocked++;
+    }
 }
 
 int mem_event_check_ring(struct domain *d, struct mem_event_domain *med)
 {
-    struct vcpu *curr = current;
-    int free_requests;
-    int ring_full = 1;
+    if ( !med->ring_page )
+        return -ENOSYS;
 
-    if ( !med->ring_page )
-        return -1;
-
-    mem_event_ring_lock(med);
-
-    free_requests = RING_FREE_REQUESTS(&med->front_ring);
-    if ( med->req_producers < free_requests )
-    {
-        med->req_producers++;
-        ring_full = 0;
-    }
-
-    if ( ring_full && (curr->domain == d) )
-        mem_event_mark_and_pause(curr);
-
-    mem_event_ring_unlock(med);
-
-    return ring_full;
+    return 0;
 }
 
 /* Registered with Xen-bound event channel for incoming notifications. */
@@ -323,7 +418,7 @@ int mem_event_domctl(struct domain *d, x
         case XEN_DOMCTL_MEM_EVENT_OP_PAGING_DISABLE:
         {
             if ( med->ring_page )
-                rc = mem_event_disable(med);
+                rc = mem_event_disable(d, med);
         }
         break;
 
@@ -362,7 +457,7 @@ int mem_event_domctl(struct domain *d, x
         case XEN_DOMCTL_MEM_EVENT_OP_ACCESS_DISABLE:
         {
             if ( med->ring_page )
-                rc = mem_event_disable(med);
+                rc = mem_event_disable(d, med);
         }
         break;
 
diff -r 4c4a9ed0728c -r d1d238616c0c xen/arch/x86/mm/mem_sharing.c
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -281,12 +281,20 @@ static struct page_info* mem_sharing_all
     vcpu_pause_nosync(v);
     req.flags |= MEM_EVENT_FLAG_VCPU_PAUSED;
 
-    if(mem_event_check_ring(d, &d->mem_event->share)) return page;
-
     req.gfn = gfn;
     req.p2mt = p2m_ram_shared;
     req.vcpu_id = v->vcpu_id;
-    mem_event_put_request(d, &d->mem_event->share, &req);
+
+    /* If there is no ring, and we're out of memory, then
+     * there is no way out. */
+    if ( mem_event_put_request(d, &d->mem_event->share, 
+                                &req) == -ENOSYS )
+    {
+        gdprintk(XENLOG_ERR, 
+                 "Failed alloc on unshare path for %hu and no ring "
+                 "to upcall\n", d->domain_id);
+        domain_crash(d);
+    }
 
     return page;
 }
@@ -310,6 +318,9 @@ int mem_sharing_sharing_resume(struct do
             vcpu_unpause(d->vcpu[rsp.vcpu_id]);
     }
 
+    /* Unpause any domains that were paused because the ring was full */
+    mem_event_unpause_vcpus(d, &d->mem_event->paging);
+
     return 0;
 }
 
diff -r 4c4a9ed0728c -r d1d238616c0c xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -871,13 +871,15 @@ int p2m_mem_paging_evict(struct domain *
  * p2m_mem_paging_drop_page() will notify the pager that a paged-out gfn was
  * released by the guest. The pager is supposed to drop its reference of the
  * gfn.
+ * Returns zero on success, EAGAIN for foreign mappers and EBUSY for guest 
+ * vcpus if the ring is congested.
  */
-void p2m_mem_paging_drop_page(struct domain *d, unsigned long gfn)
+int p2m_mem_paging_drop_page(struct domain *d, unsigned long gfn)
 {
     struct vcpu *v = current;
     mem_event_request_t req;
 
-    /* Check that there's space on the ring for this request */
+    /* Check that there's a paging listener who cares about this */
     if ( mem_event_check_ring(d, &d->mem_event->paging) == 0)
     {
         /* Send release notification to pager */
@@ -886,8 +888,11 @@ void p2m_mem_paging_drop_page(struct dom
         req.gfn = gfn;
         req.vcpu_id = v->vcpu_id;
 
-        mem_event_put_request(d, &d->mem_event->paging, &req);
+        /* rc cannot be ENOSYS, as we checked before */
+        return mem_event_put_request(d, &d->mem_event->paging, &req);
     }
+
+    return 0;
 }
 
 /**
@@ -920,9 +925,14 @@ void p2m_mem_paging_populate(struct doma
     mfn_t mfn;
     struct p2m_domain *p2m = p2m_get_hostp2m(d);
 
-    /* Check that there's space on the ring for this request */
+    /* We're paging. There should be a ring */
     if ( mem_event_check_ring(d, &d->mem_event->paging) )
+    {
+        gdprintk(XENLOG_ERR, "Domain %hu paging gfn %lx yet no ring "
+                    "in place\n", d->domain_id, gfn);
+        domain_crash(d);
         return;
+    }
 
     memset(&req, 0, sizeof(req));
     req.type = MEM_EVENT_TYPE_PAGING;
@@ -951,7 +961,6 @@ void p2m_mem_paging_populate(struct doma
     else if ( p2mt != p2m_ram_paging_out && p2mt != p2m_ram_paged )
     {
         /* gfn is already on its way back and vcpu is not paused */
-        mem_event_put_req_producers(&d->mem_event->paging);
         return;
     }
 
@@ -960,7 +969,10 @@ void p2m_mem_paging_populate(struct doma
     req.p2mt = p2mt;
     req.vcpu_id = v->vcpu_id;
 
-    mem_event_put_request(d, &d->mem_event->paging, &req);
+    (void)mem_event_put_request(d, &d->mem_event->paging, &req);
+    /* If the ring is full, foreign mappers will retry, and guest
+     * vcpus remain paused. Guest vcpu will wake up and retry once
+     * the consumer has made some space in the ring. */
 }
 
 /**
@@ -1094,7 +1106,7 @@ void p2m_mem_paging_resume(struct domain
     }
 
     /* Unpause any domains that were paused because the ring was full */
-    mem_event_unpause_vcpus(d);
+    mem_event_unpause_vcpus(d, &d->mem_event->paging);
 }
 
 void p2m_mem_access_check(unsigned long gpa, bool_t gla_valid, unsigned long gla, 
@@ -1105,7 +1117,6 @@ void p2m_mem_access_check(unsigned long 
     unsigned long gfn = gpa >> PAGE_SHIFT;
     struct domain *d = v->domain;    
     struct p2m_domain* p2m = p2m_get_hostp2m(d);
-    int res;
     mfn_t mfn;
     p2m_type_t p2mt;
     p2m_access_t p2ma;
@@ -1123,17 +1134,14 @@ void p2m_mem_access_check(unsigned long 
     p2m_unlock(p2m);
 
     /* Otherwise, check if there is a memory event listener, and send the message along */
-    res = mem_event_check_ring(d, &d->mem_event->access);
-    if ( res < 0 ) 
+    if ( mem_event_check_ring(d, &d->mem_event->access) == -ENOSYS ) 
     {
         /* No listener */
         if ( p2m->access_required ) 
         {
-            printk(XENLOG_INFO 
-                   "Memory access permissions failure, no mem_event listener: pausing VCPU %d, dom %d\n",
-                   v->vcpu_id, d->domain_id);
-
-            mem_event_mark_and_pause(v);
+            gdprintk(XENLOG_INFO, "Memory access permissions failure, no mem_event "
+                     "listener VCPU %d, dom %d\n", v->vcpu_id, d->domain_id);
+            domain_crash(v->domain);
         }
         else
         {
@@ -1145,8 +1153,6 @@ void p2m_mem_access_check(unsigned long 
 
         return;
     }
-    else if ( res > 0 )
-        return;  /* No space in buffer; VCPU paused */
 
     memset(&req, 0, sizeof(req));
     req.type = MEM_EVENT_TYPE_ACCESS;
@@ -1167,9 +1173,8 @@ void p2m_mem_access_check(unsigned long 
     
     req.vcpu_id = v->vcpu_id;
 
-    mem_event_put_request(d, &d->mem_event->access, &req);
-
-    /* VCPU paused, mem event request sent */
+    (void)mem_event_put_request(d, &d->mem_event->access, &req);
+    /* VCPU paused */
 }
 
 void p2m_mem_access_resume(struct domain *d)
@@ -1188,7 +1193,7 @@ void p2m_mem_access_resume(struct domain
 
     /* Unpause any domains that were paused because the ring was full or no listener 
      * was available */
-    mem_event_unpause_vcpus(d);
+    mem_event_unpause_vcpus(d, &d->mem_event->access);
 }
 
 
diff -r 4c4a9ed0728c -r d1d238616c0c xen/common/memory.c
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -165,10 +165,13 @@ int guest_remove_page(struct domain *d, 
     mfn = mfn_x(get_gfn(d, gmfn, &p2mt)); 
     if ( unlikely(p2m_is_paging(p2mt)) )
     {
+        int rc; 
         guest_physmap_remove_page(d, gmfn, mfn, 0);
-        p2m_mem_paging_drop_page(d, gmfn);
+        rc = p2m_mem_paging_drop_page(d, gmfn);
         put_gfn(d, gmfn);
-        return 1;
+        /* drop_page returns zero on success, we return 1 on success.
+         * drop_page returns negative on error, never returns 1. */
+        return rc ? rc : 1;
     }
 #else
     mfn = gmfn_to_mfn(d, gmfn);
diff -r 4c4a9ed0728c -r d1d238616c0c xen/include/asm-x86/mem_event.h
--- a/xen/include/asm-x86/mem_event.h
+++ b/xen/include/asm-x86/mem_event.h
@@ -25,12 +25,18 @@
 #define __MEM_EVENT_H__
 
 /* Pauses VCPU while marking pause flag for mem event */
-void mem_event_mark_and_pause(struct vcpu *v);
+void mem_event_mark_and_pause(struct vcpu *v, struct mem_event_domain *med);
 int mem_event_check_ring(struct domain *d, struct mem_event_domain *med);
-void mem_event_put_req_producers(struct mem_event_domain *med);
-void mem_event_put_request(struct domain *d, struct mem_event_domain *med, mem_event_request_t *req);
-int mem_event_get_response(struct mem_event_domain *med, mem_event_response_t *rsp);
-void mem_event_unpause_vcpus(struct domain *d);
+void mem_event_unpause_vcpus(struct domain *d, struct mem_event_domain *med);
+
+/* Returns 0 on success, -ENOSYS if there is no ring, -EBUSY if there is 
+ * a ring or no space. FOr success or -EBUSY. the vCPU is left blocked to 
+ * ensure that the ring does not lose events.  In general, put_request should 
+ * not fail, as it attempts to ensure that each vCPU can put at least one req. */
+int mem_event_put_request(struct domain *d, struct mem_event_domain *med,
+                            mem_event_request_t *req);
+int mem_event_get_response(struct mem_event_domain *med,
+                            mem_event_response_t *rsp);
 
 int mem_event_domctl(struct domain *d, xen_domctl_mem_event_op_t *mec,
                      XEN_GUEST_HANDLE(void) u_domctl);
diff -r 4c4a9ed0728c -r d1d238616c0c xen/include/asm-x86/p2m.h
--- a/xen/include/asm-x86/p2m.h
+++ b/xen/include/asm-x86/p2m.h
@@ -475,7 +475,7 @@ int p2m_mem_paging_nominate(struct domai
 /* Evict a frame */
 int p2m_mem_paging_evict(struct domain *d, unsigned long gfn);
 /* Tell xenpaging to drop a paged out frame */
-void p2m_mem_paging_drop_page(struct domain *d, unsigned long gfn);
+int p2m_mem_paging_drop_page(struct domain *d, unsigned long gfn);
 /* Start populating a paged out frame */
 void p2m_mem_paging_populate(struct domain *d, unsigned long gfn);
 /* Prepare the p2m for paging a frame in */
@@ -483,8 +483,8 @@ int p2m_mem_paging_prep(struct domain *d
 /* Resume normal operation (in case a domain was paused) */
 void p2m_mem_paging_resume(struct domain *d);
 #else
-static inline void p2m_mem_paging_drop_page(struct domain *d, unsigned long gfn)
-{ }
+static inline int p2m_mem_paging_drop_page(struct domain *d, unsigned long gfn)
+{ return 0; }
 static inline void p2m_mem_paging_populate(struct domain *d, unsigned long gfn)
 { }
 #endif
diff -r 4c4a9ed0728c -r d1d238616c0c xen/include/xen/mm.h
--- a/xen/include/xen/mm.h
+++ b/xen/include/xen/mm.h
@@ -318,6 +318,8 @@ page_list_splice(struct page_list_head *
 
 void scrub_one_page(struct page_info *);
 
+/* Returns 1 on success, 0 on error, negative if the ring
+ * for event propagation is full in the presence of paging */
 int guest_remove_page(struct domain *d, unsigned long gmfn);
 
 #define RAM_TYPE_CONVENTIONAL 0x00000001
diff -r 4c4a9ed0728c -r d1d238616c0c xen/include/xen/sched.h
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -183,13 +183,16 @@ struct mem_event_domain
 {
     /* ring lock */
     spinlock_t ring_lock;
-    unsigned int req_producers;
     /* shared page */
     mem_event_shared_page_t *shared_page;
     /* shared ring page */
     void *ring_page;
     /* front-end ring */
     mem_event_front_ring_t front_ring;
+    /* the number of vCPUs blocked */
+    unsigned int blocked;
+    /* The last vcpu woken up */
+    unsigned int last_vcpu_wake_up;
     /* event channel port (vcpu0 only) */
     int xen_port;
 };

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 15:28:19 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 15:28:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXaSe-0000z9-5g; Mon, 05 Dec 2011 15:28:08 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RXaSc-0000ys-VS
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 15:28:07 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-4.tower-182.messagelabs.com!1323098841!5959243!1
X-Originating-IP: [208.97.132.5]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi41ID0+IDE1MzI4\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17771 invoked from network); 5 Dec 2011 15:27:21 -0000
Received: from mailbigip.dreamhost.com (HELO homiemail-a22.g.dreamhost.com)
	(208.97.132.5) by server-4.tower-182.messagelabs.com with SMTP;
	5 Dec 2011 15:27:21 -0000
Received: from homiemail-a22.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a22.g.dreamhost.com (Postfix) with ESMTP id 0E6001A8076;
	Mon,  5 Dec 2011 07:27:21 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=rIs8BQ1dzOayGo93cs7+iPDrCTWlr3fItMONDueuZC8Z
	1jatpbEt1/JR9pvNMmDt66WBweCJyL1Ys0X+KIXX8V7T844Od/kuMIb+sNPQDIUC
	gXiN29ASjgbESVyK+jKGuIk4cdjdZiGHURCFp7Jj8haLfOTzTkh09FIwo6zue8I=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=BFD1XETdD45g2On45hqX1ndoDkU=; b=jq48VIJG
	bLOOj4RuR1+knb+HSpjRFUw1BQHRFbqY5bsXrd3THJ/OnPyOuya/CfcDNdbM1wFm
	hewgiwt+iJ4B3/tXnN6JSygRtywJay3RxeAPWahXra4I1mtrhQzBlKb1Oj0ab8hP
	IZyIqakS4yhFKjdR3gMnCS52RB60+PM3v0g=
Received: from webmail.lagarcavilla.org (ahfbbjcaiaae.dreamhost.com
	[75.119.208.4]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a22.g.dreamhost.com (Postfix) with ESMTPA id 811F81A8063; 
	Mon,  5 Dec 2011 07:27:20 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP; Mon, 5 Dec 2011 07:27:20 -0800
Message-ID: <948be09e0d7d9eba003dc9e105c2746e.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20111205112358.GB28908@aepfle.de>
References: <patchbomb.1322603709@xdev.gridcentric.ca>
	<43dc614d543cdf84189d.1322603711@xdev.gridcentric.ca>
	<20111201145103.GA13045@aepfle.de>
	<457bf805a9709501746d2073fcd9082d.squirrel@webmail.lagarcavilla.org>
	<20111205112358.GB28908@aepfle.de>
Date: Mon, 5 Dec 2011 07:27:20 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Olaf Hering" <olaf@aepfle.de>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, ian.campbell@citrix.com,
	andres@gridcentric.ca, tim@xen.org, keir.xen@gmail.com,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>,
	jbeulich@suse.com, ian.jackson@citrix.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 2 of 5] Improve ring management for memory
 events. Do not lose guest events
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

I just pushed all that I had on mem event. I split it into two series. One
that adds features that are independent on how we choose to manage the
ring.

Hopefully we'll concur these features are useful (such as kicking Xen to
consume batched responses directly with an event channel, no domctl
needed). And that they should go in the tree. I've been using them for a
month already.

The second series is a refreshed post of our version of ring management,
sans wait queues. With both up to date version in hand, we should be able
to reach a consensus on which to use.

Thanks
Andres

> On Thu, Dec 01, Andres Lagar-Cavilla wrote:
>
>> MAX_HVM_VCPUS sits at 128 right now. Haven't compile checked, but that
>> probably means we would need a two page ring. And then, when 1024-cpu
>> hosts arrive and we grow MAX_HVM_VCPUS, we grow the ring size again.
>
> The ring has 64 entries.
>
>> Or, we could limit the constraint to the number of online vcpus, which
>> would get somewhat tricky for vcpu hot-plugging.
>>
>> I can fix that separately, once there is a decision on which way to go
>> re
>> ring management.
>
>
> I just sent "[PATCH] mem_event: use wait queue when ring is full" to the
> list. This version ought to work, it takes the request from both target
> and foreign cpus into account and leaves at lease one slot for the
> target.
>
>
> Olaf
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 15:28:19 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 15:28:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXaSe-0000z9-5g; Mon, 05 Dec 2011 15:28:08 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RXaSc-0000ys-VS
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 15:28:07 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-4.tower-182.messagelabs.com!1323098841!5959243!1
X-Originating-IP: [208.97.132.5]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi41ID0+IDE1MzI4\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17771 invoked from network); 5 Dec 2011 15:27:21 -0000
Received: from mailbigip.dreamhost.com (HELO homiemail-a22.g.dreamhost.com)
	(208.97.132.5) by server-4.tower-182.messagelabs.com with SMTP;
	5 Dec 2011 15:27:21 -0000
Received: from homiemail-a22.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a22.g.dreamhost.com (Postfix) with ESMTP id 0E6001A8076;
	Mon,  5 Dec 2011 07:27:21 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=rIs8BQ1dzOayGo93cs7+iPDrCTWlr3fItMONDueuZC8Z
	1jatpbEt1/JR9pvNMmDt66WBweCJyL1Ys0X+KIXX8V7T844Od/kuMIb+sNPQDIUC
	gXiN29ASjgbESVyK+jKGuIk4cdjdZiGHURCFp7Jj8haLfOTzTkh09FIwo6zue8I=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=BFD1XETdD45g2On45hqX1ndoDkU=; b=jq48VIJG
	bLOOj4RuR1+knb+HSpjRFUw1BQHRFbqY5bsXrd3THJ/OnPyOuya/CfcDNdbM1wFm
	hewgiwt+iJ4B3/tXnN6JSygRtywJay3RxeAPWahXra4I1mtrhQzBlKb1Oj0ab8hP
	IZyIqakS4yhFKjdR3gMnCS52RB60+PM3v0g=
Received: from webmail.lagarcavilla.org (ahfbbjcaiaae.dreamhost.com
	[75.119.208.4]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a22.g.dreamhost.com (Postfix) with ESMTPA id 811F81A8063; 
	Mon,  5 Dec 2011 07:27:20 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP; Mon, 5 Dec 2011 07:27:20 -0800
Message-ID: <948be09e0d7d9eba003dc9e105c2746e.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20111205112358.GB28908@aepfle.de>
References: <patchbomb.1322603709@xdev.gridcentric.ca>
	<43dc614d543cdf84189d.1322603711@xdev.gridcentric.ca>
	<20111201145103.GA13045@aepfle.de>
	<457bf805a9709501746d2073fcd9082d.squirrel@webmail.lagarcavilla.org>
	<20111205112358.GB28908@aepfle.de>
Date: Mon, 5 Dec 2011 07:27:20 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Olaf Hering" <olaf@aepfle.de>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, ian.campbell@citrix.com,
	andres@gridcentric.ca, tim@xen.org, keir.xen@gmail.com,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>,
	jbeulich@suse.com, ian.jackson@citrix.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 2 of 5] Improve ring management for memory
 events. Do not lose guest events
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

I just pushed all that I had on mem event. I split it into two series. One
that adds features that are independent on how we choose to manage the
ring.

Hopefully we'll concur these features are useful (such as kicking Xen to
consume batched responses directly with an event channel, no domctl
needed). And that they should go in the tree. I've been using them for a
month already.

The second series is a refreshed post of our version of ring management,
sans wait queues. With both up to date version in hand, we should be able
to reach a consensus on which to use.

Thanks
Andres

> On Thu, Dec 01, Andres Lagar-Cavilla wrote:
>
>> MAX_HVM_VCPUS sits at 128 right now. Haven't compile checked, but that
>> probably means we would need a two page ring. And then, when 1024-cpu
>> hosts arrive and we grow MAX_HVM_VCPUS, we grow the ring size again.
>
> The ring has 64 entries.
>
>> Or, we could limit the constraint to the number of online vcpus, which
>> would get somewhat tricky for vcpu hot-plugging.
>>
>> I can fix that separately, once there is a decision on which way to go
>> re
>> ring management.
>
>
> I just sent "[PATCH] mem_event: use wait queue when ring is full" to the
> list. This version ought to work, it takes the request from both target
> and foreign cpus into account and leaves at lease one slot for the
> target.
>
>
> Olaf
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 15:46:22 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 15:46:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXajy-0001KM-V8; Mon, 05 Dec 2011 15:46:02 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RXajx-0001KE-40
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 15:46:01 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-4.tower-27.messagelabs.com!1323099883!51184762!1
X-Originating-IP: [208.97.132.5]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi41ID0+IDE1MzI4\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29351 invoked from network); 5 Dec 2011 15:44:44 -0000
Received: from mailbigip.dreamhost.com (HELO homiemail-a15.g.dreamhost.com)
	(208.97.132.5) by server-4.tower-27.messagelabs.com with SMTP;
	5 Dec 2011 15:44:44 -0000
Received: from homiemail-a15.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a15.g.dreamhost.com (Postfix) with ESMTP id 059B576C06E;
	Mon,  5 Dec 2011 07:45:15 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=lVA8lB9cVD3L78AYbTGiZsyqLEplrc1qyBVPsk1/vSin
	EamVMhttht7I/6UrQ+29xrg3HOsYBgzt3iKv5y5RdSaFUb0k0miBKUpWDZHpChUk
	twJ0fx45fUDiTtGIIpz8BbnKW8S1V1D29iUczZe36vrIe6jXC2mJf3yAMU7j5MQ=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=2QTkRThkEeM2zbkxmBSentdV2LI=; b=UOuQcwa3
	sOEdiBeDijGqaescr1sU7H+1gsiq842YqKaHX9yU43q5GVFrotK+lMjaDwQz55SP
	W9A0KdeVzuppUK1I+eBRgKHzE0NbfHRywHh5AA4SMtQDLiwf8xx3gEGJagZ6Hega
	ul+B4fEH/iESRMk7Eh8boA6Sy3FGveJg5Rk=
Received: from webmail.lagarcavilla.org (ahfbbjcaiaae.dreamhost.com
	[75.119.208.4]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a15.g.dreamhost.com (Postfix) with ESMTPA id 9056E76C065; 
	Mon,  5 Dec 2011 07:45:14 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP; Mon, 5 Dec 2011 07:45:14 -0800
Message-ID: <f5cf6ad4704fe70f3130b832e530e8b0.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <mailman.3332.1323083995.12970.xen-devel@lists.xensource.com>
References: <mailman.3332.1323083995.12970.xen-devel@lists.xensource.com>
Date: Mon, 5 Dec 2011 07:45:14 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: olaf@aepfle.de
Subject: Re: [Xen-devel] [PATCH] mem_event: use wait queue when ring is full
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> Date: Mon, 05 Dec 2011 12:19:03 +0100
> From: Olaf Hering <olaf@aepfle.de>
> To: xen-devel@lists.xensource.com
> Subject: [Xen-devel] [PATCH] mem_event: use wait queue when ring is
> 	full
> Message-ID: <cd163bcd0f066e52ee74.1323083943@probook.site>
> Content-Type: text/plain; charset="us-ascii"
>
> # HG changeset patch
> # User Olaf Hering <olaf@aepfle.de>
> # Date 1323083831 -3600
> # Node ID cd163bcd0f066e52ee74e42090188d632f0086bf
> # Parent  a4d7c27ec1f190ecbb9a909609f6ef0eca250c00
> mem_event: use wait queue when ring is full
>
> This change is based on an idea/patch from Adin Scannell.
>
> If the ring is full, put the current vcpu to sleep if it belongs to the
> target domain. The wakeup happens in the p2m_*_resume functions. Wakeup
> will take the number of free slots into account.
>
> A request from foreign domain has to succeed once a slot was claimed
> because such vcpus can not sleep.
>
> This change fixes also a bug in p2m_mem_paging_drop_page(). Up to now a
> full ring will lead to harmless inconsistency in the pager.
>
>
> v5:
>   - rename mem_event_check_ring() to mem_event_claim_slot()
>   - rename mem_event_put_req_producers() to mem_event_release_slot()
>   - add local/foreign request accounting
>   - keep room for at least one guest request
>
> v4:
>  - fix off-by-one bug in _mem_event_put_request
>  - add mem_event_wake_requesters() and use wake_up_nr()
>  - rename mem_event_mark_and_pause() and mem_event_mark_and_pause()
> functions
>  - req_producers counts foreign request producers, rename member
>
> v3:
>  - rename ->mem_event_bit to ->bit
>  - remove me_ from new VPF_ defines
>
> v2:
>  - p2m_mem_paging_populate: move vcpu_pause after put_request, otherwise
> the
>    vcpu will not wake_up after a wait_event because the pause_count was
>    increased twice. Fixes guest hangs.
>  - update free space check in _mem_event_put_request()
>  - simplify mem_event_put_request()
>
> Signed-off-by: Olaf Hering <olaf@aepfle.de>
>
> diff -r a4d7c27ec1f1 -r cd163bcd0f06 xen/arch/x86/hvm/hvm.c
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -4156,8 +4156,8 @@ static int hvm_memory_event_traps(long p
>      if ( (p & HVMPME_onchangeonly) && (value == old) )
>          return 1;
>
> -    rc = mem_event_check_ring(d, &d->mem_event->access);
> -    if ( rc )
> +    rc = mem_event_claim_slot(d, &d->mem_event->access);
> +    if ( rc < 0 )
>          return rc;
>
>      memset(&req, 0, sizeof(req));
> diff -r a4d7c27ec1f1 -r cd163bcd0f06 xen/arch/x86/mm/mem_event.c
> --- a/xen/arch/x86/mm/mem_event.c
> +++ b/xen/arch/x86/mm/mem_event.c
> @@ -23,6 +23,7 @@
>
>  #include <asm/domain.h>
>  #include <xen/event.h>
> +#include <xen/wait.h>
>  #include <asm/p2m.h>
>  #include <asm/mem_event.h>
>  #include <asm/mem_paging.h>
> @@ -39,6 +40,7 @@
>
>  static int mem_event_enable(struct domain *d,
>                              xen_domctl_mem_event_op_t *mec,
> +                            int bit,
>                              struct mem_event_domain *med)
>  {
>      int rc;
> @@ -107,8 +109,12 @@ static int mem_event_enable(struct domai
>
>      mem_event_ring_lock_init(med);
>
> +    med->bit = bit;
I think it's been asked before for this to have a more expressive name.

> +
> +    init_waitqueue_head(&med->wq);
> +
>      /* Wake any VCPUs paused for memory events */
> -    mem_event_unpause_vcpus(d);
> +    mem_event_wake_waiters(d, med);
>
>      return 0;
>
> @@ -124,6 +130,9 @@ static int mem_event_enable(struct domai
>
>  static int mem_event_disable(struct mem_event_domain *med)
>  {
> +    if (!list_empty(&med->wq.list))
> +        return -EBUSY;
> +
What does the caller do with EBUSY? Retry?

>      unmap_domain_page(med->ring_page);
>      med->ring_page = NULL;
>
> @@ -133,13 +142,24 @@ static int mem_event_disable(struct mem_
>      return 0;
>  }
>
> -void mem_event_put_request(struct domain *d, struct mem_event_domain
> *med, mem_event_request_t *req)
> +static int _mem_event_put_request(struct domain *d,
> +                                  struct mem_event_domain *med,
> +                                  mem_event_request_t *req)
>  {
>      mem_event_front_ring_t *front_ring;
> +    int free_req, claimed_req;
>      RING_IDX req_prod;
>
>      mem_event_ring_lock(med);
>
> +    free_req = RING_FREE_REQUESTS(&med->front_ring);
> +    /* Foreign requests must succeed because their vcpus can not sleep */
> +    claimed_req = med->foreign_producers;
> +    if ( !free_req || ( current->domain == d && free_req <= claimed_req )
> ) {
> +        mem_event_ring_unlock(med);
> +        return 0;
> +    }
> +
>      front_ring = &med->front_ring;
>      req_prod = front_ring->req_prod_pvt;
>
> @@ -147,14 +167,35 @@ void mem_event_put_request(struct domain
>      memcpy(RING_GET_REQUEST(front_ring, req_prod), req, sizeof(*req));
>      req_prod++;
>
> +    /* Update accounting */
> +    if ( current->domain == d )
> +        med->target_producers--;
> +    else
> +        med->foreign_producers--;
> +
>      /* Update ring */
> -    med->req_producers--;
>      front_ring->req_prod_pvt = req_prod;
>      RING_PUSH_REQUESTS(front_ring);
>
>      mem_event_ring_unlock(med);
>
>      notify_via_xen_event_channel(d, med->xen_port);
> +
> +    return 1;
> +}
> +
> +void mem_event_put_request(struct domain *d, struct mem_event_domain
> *med,
> +                           mem_event_request_t *req)
> +{
> +    /* Go to sleep if request came from guest */
> +    if (current->domain == d) {
> +        wait_event(med->wq, _mem_event_put_request(d, med, req));
> +        return;
> +    }
> +    /* Ring was full anyway, unable to sleep in non-guest context */
> +    if (!_mem_event_put_request(d, med, req))
> +        printk("Failed to put memreq: d %u t %x f %x gfn %lx\n",
> d->domain_id,
> +                req->type, req->flags, (unsigned long)req->gfn);
>  }
>
>  void mem_event_get_response(struct mem_event_domain *med,
> mem_event_response_t *rsp)
> @@ -178,32 +219,97 @@ void mem_event_get_response(struct mem_e
>      mem_event_ring_unlock(med);
>  }
>
> -void mem_event_unpause_vcpus(struct domain *d)
> +/**
> + * mem_event_wake_requesters - Wake vcpus waiting for room in the ring
> + * @d: guest domain
> + * @med: mem_event ring
> + *
> + * mem_event_wake_requesters() will wakeup vcpus waiting for room in the
> + * ring. Only as many as can place another request in the ring will
> + * resume execution.
> + */
> +void mem_event_wake_requesters(struct mem_event_domain *med)
> +{
> +    int free_req;
> +
> +    mem_event_ring_lock(med);
> +
> +    free_req = RING_FREE_REQUESTS(&med->front_ring);
> +    if ( free_req )
> +        wake_up_nr(&med->wq, free_req);
> +
> +    mem_event_ring_unlock(med);
> +}
> +
> +/**
> + * mem_event_wake_waiters - Wake all vcpus waiting for the ring
> + * @d: guest domain
> + * @med: mem_event ring
> + *
> + * mem_event_wake_waiters() will wakeup all vcpus waiting for the ring to
> + * become available.
> + */
> +void mem_event_wake_waiters(struct domain *d, struct mem_event_domain
> *med)
>  {
>      struct vcpu *v;
>
>      for_each_vcpu ( d, v )
> -        if ( test_and_clear_bit(_VPF_mem_event, &v->pause_flags) )
> +        if ( test_and_clear_bit(med->bit, &v->pause_flags) )
>              vcpu_wake(v);
>  }
>
> -void mem_event_mark_and_pause(struct vcpu *v)
> +/**
> + * mem_event_mark_and_sleep - Put vcpu to sleep
> + * @v: guest vcpu
> + * @med: mem_event ring
> + *
> + * mem_event_mark_and_sleep() tags vcpu and put it to sleep.
> + * The vcpu will resume execution in mem_event_wake_waiters().
> + */
> +void mem_event_mark_and_sleep(struct vcpu *v, struct mem_event_domain
> *med)
>  {
> -    set_bit(_VPF_mem_event, &v->pause_flags);
> +    set_bit(med->bit, &v->pause_flags);
>      vcpu_sleep_nosync(v);
>  }
>
> -void mem_event_put_req_producers(struct mem_event_domain *med)
> +/**
> + * mem_event_release_slot - Release a claimed slot
> + * @med: mem_event ring
> + *
> + * mem_event_release_slot() releases a claimed slot in the mem_event
> ring.
> + */
> +void mem_event_release_slot(struct domain *d, struct mem_event_domain
> *med)
>  {
>      mem_event_ring_lock(med);
> -    med->req_producers--;
> +    if ( current->domain == d )
> +        med->target_producers--;
> +    else
> +        med->foreign_producers--;
>      mem_event_ring_unlock(med);
>  }
>
> -int mem_event_check_ring(struct domain *d, struct mem_event_domain *med)
> +/**
> + * mem_event_claim_slot - Check state of a mem_event ring
> + * @d: guest domain
> + * @med: mem_event ring
> + *
> + * Return codes: < 0: the ring is not yet configured
> + *                 0: the ring has some room
> + *               > 0: the ring is full
> + *
> + * mem_event_claim_slot() checks the state of the given mem_event ring.
> + * If the current vcpu belongs to the guest domain, the function assumes
> that
> + * mem_event_put_request() will sleep until the ring has room again.
> + * A guest can always place at least one request.
> + *
> + * If the current vcpu does not belong to the target domain the caller
> must try
> + * again until there is room. A slot is claimed and the caller can place
> a
> + * request. If the caller does not need to send a request, the claimed
> slot has
> + * to be released with mem_event_release_slot().
> + */
> +int mem_event_claim_slot(struct domain *d, struct mem_event_domain *med)
>  {
> -    struct vcpu *curr = current;
> -    int free_requests;
> +    int free_req;
>      int ring_full = 1;
>
>      if ( !med->ring_page )
> @@ -211,16 +317,17 @@ int mem_event_check_ring(struct domain *
>
>      mem_event_ring_lock(med);
>
> -    free_requests = RING_FREE_REQUESTS(&med->front_ring);
> -    if ( med->req_producers < free_requests )
> +    free_req = RING_FREE_REQUESTS(&med->front_ring);
> +
> +    if ( current->domain == d ) {
> +        med->target_producers++;
> +        ring_full = 0;
> +    } else if ( med->foreign_producers + med->target_producers + 1 <
> free_req )
>      {
> -        med->req_producers++;
> +        med->foreign_producers++;
>          ring_full = 0;
>      }
>
> -    if ( ring_full && (curr->domain == d) )
> -        mem_event_mark_and_pause(curr);
> -
>      mem_event_ring_unlock(med);
>
>      return ring_full;
> @@ -287,7 +394,7 @@ int mem_event_domctl(struct domain *d, x
>              if ( p2m->pod.entry_count )
>                  break;
>
> -            rc = mem_event_enable(d, mec, med);
> +            rc = mem_event_enable(d, mec, _VPF_mem_paging, med);
>          }
>          break;
>
> @@ -326,7 +433,7 @@ int mem_event_domctl(struct domain *d, x
>              if ( boot_cpu_data.x86_vendor != X86_VENDOR_INTEL )
>                  break;
>
> -            rc = mem_event_enable(d, mec, med);
> +            rc = mem_event_enable(d, mec, _VPF_mem_access, med);
Ok, the idea of bit is that different vcpus will sleep with different
pause flags, depending on the ring they're sleeping on. But this is only
used in wake_waiters, which is not used by all rings. In fact, why do we
need wake_waiters with wait queues?

>          }
>          break;
>
> diff -r a4d7c27ec1f1 -r cd163bcd0f06 xen/arch/x86/mm/mem_sharing.c
> --- a/xen/arch/x86/mm/mem_sharing.c
> +++ b/xen/arch/x86/mm/mem_sharing.c
> @@ -253,18 +253,10 @@ static void mem_sharing_audit(void)
>  #endif
>
>
> -static struct page_info* mem_sharing_alloc_page(struct domain *d,
> -                                                unsigned long gfn)
> +static void mem_sharing_notify_helper(struct domain *d, unsigned long
> gfn)
>  {
> -    struct page_info* page;
>      struct vcpu *v = current;
> -    mem_event_request_t req;
> -
> -    page = alloc_domheap_page(d, 0);
> -    if(page != NULL) return page;
> -
> -    memset(&req, 0, sizeof(req));
> -    req.type = MEM_EVENT_TYPE_SHARED;
> +    mem_event_request_t req = { .type = MEM_EVENT_TYPE_SHARED };
>
>      if ( v->domain != d )
>      {
> @@ -275,20 +267,18 @@ static struct page_info* mem_sharing_all
>          gdprintk(XENLOG_ERR,
>                   "Failed alloc on unshare path for foreign (%d)
> lookup\n",
>                   d->domain_id);
> -        return page;
> +        return;
>      }
>
> -    vcpu_pause_nosync(v);
> -    req.flags |= MEM_EVENT_FLAG_VCPU_PAUSED;
> +    if (mem_event_claim_slot(d, &d->mem_event->share) < 0)
> +        return;
>
> -    if(mem_event_check_ring(d, &d->mem_event->share)) return page;
> -
> +    req.flags = MEM_EVENT_FLAG_VCPU_PAUSED;
>      req.gfn = gfn;
>      req.p2mt = p2m_ram_shared;
>      req.vcpu_id = v->vcpu_id;
>      mem_event_put_request(d, &d->mem_event->share, &req);
> -
> -    return page;
> +    vcpu_pause_nosync(v);
>  }
>
>  unsigned int mem_sharing_get_nr_saved_mfns(void)
> @@ -653,7 +643,7 @@ gfn_found:
>      if(ret == 0) goto private_page_found;
>
>      old_page = page;
> -    page = mem_sharing_alloc_page(d, gfn);
> +    page = alloc_domheap_page(d, 0);
>      if(!page)
>      {
>          /* We've failed to obtain memory for private page. Need to re-add
> the
> @@ -661,6 +651,7 @@ gfn_found:
>          list_add(&gfn_info->list, &hash_entry->gfns);
>          put_gfn(d, gfn);
>          shr_unlock();
> +        mem_sharing_notify_helper(d, gfn);
This is nice. Do you think PoD could use this, should it ever run into a
ENOMEM situation? And what about mem_paging_prep? Perhaps, rather than a
sharing ring (which is bit rotted) we could have an ENOMEM ring with a
utility launched by xencommons listening. The problem, again, is what if
ENOMEM is itself caused by dom0 (e.g. writable mapping of a shared page)

>          return -ENOMEM;
>      }
>
> diff -r a4d7c27ec1f1 -r cd163bcd0f06 xen/arch/x86/mm/p2m.c
> --- a/xen/arch/x86/mm/p2m.c
> +++ b/xen/arch/x86/mm/p2m.c
> @@ -861,20 +861,12 @@ int p2m_mem_paging_evict(struct domain *
>   */
>  void p2m_mem_paging_drop_page(struct domain *d, unsigned long gfn)
>  {
> -    struct vcpu *v = current;
> -    mem_event_request_t req;
> +    mem_event_request_t req = { .type = MEM_EVENT_TYPE_PAGING, .gfn = gfn
> };
>
> -    /* Check that there's space on the ring for this request */
> -    if ( mem_event_check_ring(d, &d->mem_event->paging) == 0)
> -    {
> -        /* Send release notification to pager */
> -        memset(&req, 0, sizeof(req));
> -        req.flags |= MEM_EVENT_FLAG_DROP_PAGE;
> -        req.gfn = gfn;
> -        req.vcpu_id = v->vcpu_id;
> +    /* Send release notification to pager */
> +    req.flags = MEM_EVENT_FLAG_DROP_PAGE;
>
> -        mem_event_put_request(d, &d->mem_event->paging, &req);
> -    }
> +    mem_event_put_request(d, &d->mem_event->paging, &req);
>  }
>
>  /**
> @@ -908,7 +900,7 @@ void p2m_mem_paging_populate(struct doma
>      struct p2m_domain *p2m = p2m_get_hostp2m(d);
>
>      /* Check that there's space on the ring for this request */
> -    if ( mem_event_check_ring(d, &d->mem_event->paging) )
> +    if ( mem_event_claim_slot(d, &d->mem_event->paging) )
>          return;
>
>      memset(&req, 0, sizeof(req));
> @@ -938,7 +930,7 @@ void p2m_mem_paging_populate(struct doma
>      else if ( p2mt != p2m_ram_paging_out && p2mt != p2m_ram_paged )
>      {
>          /* gfn is already on its way back and vcpu is not paused */
> -        mem_event_put_req_producers(&d->mem_event->paging);
> +        mem_event_release_slot(d, &d->mem_event->paging);
>          return;
>      }
>
> @@ -1078,8 +1070,8 @@ void p2m_mem_paging_resume(struct domain
>      if ( rsp.flags & MEM_EVENT_FLAG_VCPU_PAUSED )
>          vcpu_unpause(d->vcpu[rsp.vcpu_id]);
>
> -    /* Unpause any domains that were paused because the ring was full */
> -    mem_event_unpause_vcpus(d);
> +    /* Wake vcpus waiting for room in the ring */
> +    mem_event_wake_requesters(&d->mem_event->paging);
>  }
>
>  void p2m_mem_access_check(unsigned long gpa, bool_t gla_valid, unsigned
> long gla,
> @@ -1108,7 +1100,7 @@ void p2m_mem_access_check(unsigned long
>      p2m_unlock(p2m);
>
>      /* Otherwise, check if there is a memory event listener, and send the
> message along */
> -    res = mem_event_check_ring(d, &d->mem_event->access);
> +    res = mem_event_claim_slot(d, &d->mem_event->access);
>      if ( res < 0 )
>      {
>          /* No listener */
> @@ -1118,7 +1110,7 @@ void p2m_mem_access_check(unsigned long
>                     "Memory access permissions failure, no mem_event
> listener: pausing VCPU %d, dom %d\n",
>                     v->vcpu_id, d->domain_id);
>
> -            mem_event_mark_and_pause(v);
> +            mem_event_mark_and_sleep(v, &d->mem_event->access);
>          }
>          else
>          {
> @@ -1167,9 +1159,11 @@ void p2m_mem_access_resume(struct domain
>      if ( rsp.flags & MEM_EVENT_FLAG_VCPU_PAUSED )
>          vcpu_unpause(d->vcpu[rsp.vcpu_id]);
>
> -    /* Unpause any domains that were paused because the ring was full or
> no listener
> -     * was available */
> -    mem_event_unpause_vcpus(d);
> +    /* Wake vcpus waiting for room in the ring */
> +    mem_event_wake_requesters(&d->mem_event->access);
> +
> +    /* Unpause all vcpus that were paused because no listener was
> available */
> +    mem_event_wake_waiters(d, &d->mem_event->access);
Is this not used in p2m_mem_paging_resume? Why the difference? Why are two
mechanisms needed (wake_requesters, wake_sleepers)?

Thanks
Andres

>  }
>
>
> diff -r a4d7c27ec1f1 -r cd163bcd0f06 xen/include/asm-x86/mem_event.h
> --- a/xen/include/asm-x86/mem_event.h
> +++ b/xen/include/asm-x86/mem_event.h
> @@ -24,13 +24,13 @@
>  #ifndef __MEM_EVENT_H__
>  #define __MEM_EVENT_H__
>
> -/* Pauses VCPU while marking pause flag for mem event */
> -void mem_event_mark_and_pause(struct vcpu *v);
> -int mem_event_check_ring(struct domain *d, struct mem_event_domain *med);
> -void mem_event_put_req_producers(struct mem_event_domain *med);
> +int mem_event_claim_slot(struct domain *d, struct mem_event_domain *med);
> +void mem_event_release_slot(struct domain *d, struct mem_event_domain
> *med);
>  void mem_event_put_request(struct domain *d, struct mem_event_domain
> *med, mem_event_request_t *req);
>  void mem_event_get_response(struct mem_event_domain *med,
> mem_event_response_t *rsp);
> -void mem_event_unpause_vcpus(struct domain *d);
> +void mem_event_wake_requesters(struct mem_event_domain *med);
> +void mem_event_wake_waiters(struct domain *d, struct mem_event_domain
> *med);
> +void mem_event_mark_and_sleep(struct vcpu *v, struct mem_event_domain
> *med);
>
>  int mem_event_domctl(struct domain *d, xen_domctl_mem_event_op_t *mec,
>                       XEN_GUEST_HANDLE(void) u_domctl);
> diff -r a4d7c27ec1f1 -r cd163bcd0f06 xen/include/xen/sched.h
> --- a/xen/include/xen/sched.h
> +++ b/xen/include/xen/sched.h
> @@ -14,6 +14,7 @@
>  #include <xen/nodemask.h>
>  #include <xen/radix-tree.h>
>  #include <xen/multicall.h>
> +#include <xen/wait.h>
>  #include <public/xen.h>
>  #include <public/domctl.h>
>  #include <public/sysctl.h>
> @@ -183,7 +184,8 @@ struct mem_event_domain
>  {
>      /* ring lock */
>      spinlock_t ring_lock;
> -    unsigned int req_producers;
> +    unsigned short foreign_producers;
> +    unsigned short target_producers;
>      /* shared page */
>      mem_event_shared_page_t *shared_page;
>      /* shared ring page */
> @@ -192,6 +194,10 @@ struct mem_event_domain
>      mem_event_front_ring_t front_ring;
>      /* event channel port (vcpu0 only) */
>      int xen_port;
> +    /* mem_event bit for vcpu->pause_flags */
> +    int bit;
> +    /* list of vcpus waiting for room in the ring */
> +    struct waitqueue_head wq;
>  };
>
>  struct mem_event_per_domain
> @@ -615,9 +621,12 @@ static inline struct domain *next_domain
>   /* VCPU affinity has changed: migrating to a new CPU. */
>  #define _VPF_migrating       3
>  #define VPF_migrating        (1UL<<_VPF_migrating)
> - /* VCPU is blocked on memory-event ring. */
> -#define _VPF_mem_event       4
> -#define VPF_mem_event        (1UL<<_VPF_mem_event)
> + /* VCPU is blocked due to missing mem_paging ring. */
> +#define _VPF_mem_paging      4
> +#define VPF_mem_paging       (1UL<<_VPF_mem_paging)
> + /* VCPU is blocked due to missing mem_access ring. */
> +#define _VPF_mem_access      5
> +#define VPF_mem_access       (1UL<<_VPF_mem_access)
>
>  static inline int vcpu_runnable(struct vcpu *v)
>  {
>
>
>
> ------------------------------
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>
>
> End of Xen-devel Digest, Vol 82, Issue 66
> *****************************************
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 15:46:22 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 15:46:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXajy-0001KM-V8; Mon, 05 Dec 2011 15:46:02 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RXajx-0001KE-40
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 15:46:01 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-4.tower-27.messagelabs.com!1323099883!51184762!1
X-Originating-IP: [208.97.132.5]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi41ID0+IDE1MzI4\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29351 invoked from network); 5 Dec 2011 15:44:44 -0000
Received: from mailbigip.dreamhost.com (HELO homiemail-a15.g.dreamhost.com)
	(208.97.132.5) by server-4.tower-27.messagelabs.com with SMTP;
	5 Dec 2011 15:44:44 -0000
Received: from homiemail-a15.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a15.g.dreamhost.com (Postfix) with ESMTP id 059B576C06E;
	Mon,  5 Dec 2011 07:45:15 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=lVA8lB9cVD3L78AYbTGiZsyqLEplrc1qyBVPsk1/vSin
	EamVMhttht7I/6UrQ+29xrg3HOsYBgzt3iKv5y5RdSaFUb0k0miBKUpWDZHpChUk
	twJ0fx45fUDiTtGIIpz8BbnKW8S1V1D29iUczZe36vrIe6jXC2mJf3yAMU7j5MQ=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=2QTkRThkEeM2zbkxmBSentdV2LI=; b=UOuQcwa3
	sOEdiBeDijGqaescr1sU7H+1gsiq842YqKaHX9yU43q5GVFrotK+lMjaDwQz55SP
	W9A0KdeVzuppUK1I+eBRgKHzE0NbfHRywHh5AA4SMtQDLiwf8xx3gEGJagZ6Hega
	ul+B4fEH/iESRMk7Eh8boA6Sy3FGveJg5Rk=
Received: from webmail.lagarcavilla.org (ahfbbjcaiaae.dreamhost.com
	[75.119.208.4]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a15.g.dreamhost.com (Postfix) with ESMTPA id 9056E76C065; 
	Mon,  5 Dec 2011 07:45:14 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP; Mon, 5 Dec 2011 07:45:14 -0800
Message-ID: <f5cf6ad4704fe70f3130b832e530e8b0.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <mailman.3332.1323083995.12970.xen-devel@lists.xensource.com>
References: <mailman.3332.1323083995.12970.xen-devel@lists.xensource.com>
Date: Mon, 5 Dec 2011 07:45:14 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: olaf@aepfle.de
Subject: Re: [Xen-devel] [PATCH] mem_event: use wait queue when ring is full
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> Date: Mon, 05 Dec 2011 12:19:03 +0100
> From: Olaf Hering <olaf@aepfle.de>
> To: xen-devel@lists.xensource.com
> Subject: [Xen-devel] [PATCH] mem_event: use wait queue when ring is
> 	full
> Message-ID: <cd163bcd0f066e52ee74.1323083943@probook.site>
> Content-Type: text/plain; charset="us-ascii"
>
> # HG changeset patch
> # User Olaf Hering <olaf@aepfle.de>
> # Date 1323083831 -3600
> # Node ID cd163bcd0f066e52ee74e42090188d632f0086bf
> # Parent  a4d7c27ec1f190ecbb9a909609f6ef0eca250c00
> mem_event: use wait queue when ring is full
>
> This change is based on an idea/patch from Adin Scannell.
>
> If the ring is full, put the current vcpu to sleep if it belongs to the
> target domain. The wakeup happens in the p2m_*_resume functions. Wakeup
> will take the number of free slots into account.
>
> A request from foreign domain has to succeed once a slot was claimed
> because such vcpus can not sleep.
>
> This change fixes also a bug in p2m_mem_paging_drop_page(). Up to now a
> full ring will lead to harmless inconsistency in the pager.
>
>
> v5:
>   - rename mem_event_check_ring() to mem_event_claim_slot()
>   - rename mem_event_put_req_producers() to mem_event_release_slot()
>   - add local/foreign request accounting
>   - keep room for at least one guest request
>
> v4:
>  - fix off-by-one bug in _mem_event_put_request
>  - add mem_event_wake_requesters() and use wake_up_nr()
>  - rename mem_event_mark_and_pause() and mem_event_mark_and_pause()
> functions
>  - req_producers counts foreign request producers, rename member
>
> v3:
>  - rename ->mem_event_bit to ->bit
>  - remove me_ from new VPF_ defines
>
> v2:
>  - p2m_mem_paging_populate: move vcpu_pause after put_request, otherwise
> the
>    vcpu will not wake_up after a wait_event because the pause_count was
>    increased twice. Fixes guest hangs.
>  - update free space check in _mem_event_put_request()
>  - simplify mem_event_put_request()
>
> Signed-off-by: Olaf Hering <olaf@aepfle.de>
>
> diff -r a4d7c27ec1f1 -r cd163bcd0f06 xen/arch/x86/hvm/hvm.c
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -4156,8 +4156,8 @@ static int hvm_memory_event_traps(long p
>      if ( (p & HVMPME_onchangeonly) && (value == old) )
>          return 1;
>
> -    rc = mem_event_check_ring(d, &d->mem_event->access);
> -    if ( rc )
> +    rc = mem_event_claim_slot(d, &d->mem_event->access);
> +    if ( rc < 0 )
>          return rc;
>
>      memset(&req, 0, sizeof(req));
> diff -r a4d7c27ec1f1 -r cd163bcd0f06 xen/arch/x86/mm/mem_event.c
> --- a/xen/arch/x86/mm/mem_event.c
> +++ b/xen/arch/x86/mm/mem_event.c
> @@ -23,6 +23,7 @@
>
>  #include <asm/domain.h>
>  #include <xen/event.h>
> +#include <xen/wait.h>
>  #include <asm/p2m.h>
>  #include <asm/mem_event.h>
>  #include <asm/mem_paging.h>
> @@ -39,6 +40,7 @@
>
>  static int mem_event_enable(struct domain *d,
>                              xen_domctl_mem_event_op_t *mec,
> +                            int bit,
>                              struct mem_event_domain *med)
>  {
>      int rc;
> @@ -107,8 +109,12 @@ static int mem_event_enable(struct domai
>
>      mem_event_ring_lock_init(med);
>
> +    med->bit = bit;
I think it's been asked before for this to have a more expressive name.

> +
> +    init_waitqueue_head(&med->wq);
> +
>      /* Wake any VCPUs paused for memory events */
> -    mem_event_unpause_vcpus(d);
> +    mem_event_wake_waiters(d, med);
>
>      return 0;
>
> @@ -124,6 +130,9 @@ static int mem_event_enable(struct domai
>
>  static int mem_event_disable(struct mem_event_domain *med)
>  {
> +    if (!list_empty(&med->wq.list))
> +        return -EBUSY;
> +
What does the caller do with EBUSY? Retry?

>      unmap_domain_page(med->ring_page);
>      med->ring_page = NULL;
>
> @@ -133,13 +142,24 @@ static int mem_event_disable(struct mem_
>      return 0;
>  }
>
> -void mem_event_put_request(struct domain *d, struct mem_event_domain
> *med, mem_event_request_t *req)
> +static int _mem_event_put_request(struct domain *d,
> +                                  struct mem_event_domain *med,
> +                                  mem_event_request_t *req)
>  {
>      mem_event_front_ring_t *front_ring;
> +    int free_req, claimed_req;
>      RING_IDX req_prod;
>
>      mem_event_ring_lock(med);
>
> +    free_req = RING_FREE_REQUESTS(&med->front_ring);
> +    /* Foreign requests must succeed because their vcpus can not sleep */
> +    claimed_req = med->foreign_producers;
> +    if ( !free_req || ( current->domain == d && free_req <= claimed_req )
> ) {
> +        mem_event_ring_unlock(med);
> +        return 0;
> +    }
> +
>      front_ring = &med->front_ring;
>      req_prod = front_ring->req_prod_pvt;
>
> @@ -147,14 +167,35 @@ void mem_event_put_request(struct domain
>      memcpy(RING_GET_REQUEST(front_ring, req_prod), req, sizeof(*req));
>      req_prod++;
>
> +    /* Update accounting */
> +    if ( current->domain == d )
> +        med->target_producers--;
> +    else
> +        med->foreign_producers--;
> +
>      /* Update ring */
> -    med->req_producers--;
>      front_ring->req_prod_pvt = req_prod;
>      RING_PUSH_REQUESTS(front_ring);
>
>      mem_event_ring_unlock(med);
>
>      notify_via_xen_event_channel(d, med->xen_port);
> +
> +    return 1;
> +}
> +
> +void mem_event_put_request(struct domain *d, struct mem_event_domain
> *med,
> +                           mem_event_request_t *req)
> +{
> +    /* Go to sleep if request came from guest */
> +    if (current->domain == d) {
> +        wait_event(med->wq, _mem_event_put_request(d, med, req));
> +        return;
> +    }
> +    /* Ring was full anyway, unable to sleep in non-guest context */
> +    if (!_mem_event_put_request(d, med, req))
> +        printk("Failed to put memreq: d %u t %x f %x gfn %lx\n",
> d->domain_id,
> +                req->type, req->flags, (unsigned long)req->gfn);
>  }
>
>  void mem_event_get_response(struct mem_event_domain *med,
> mem_event_response_t *rsp)
> @@ -178,32 +219,97 @@ void mem_event_get_response(struct mem_e
>      mem_event_ring_unlock(med);
>  }
>
> -void mem_event_unpause_vcpus(struct domain *d)
> +/**
> + * mem_event_wake_requesters - Wake vcpus waiting for room in the ring
> + * @d: guest domain
> + * @med: mem_event ring
> + *
> + * mem_event_wake_requesters() will wakeup vcpus waiting for room in the
> + * ring. Only as many as can place another request in the ring will
> + * resume execution.
> + */
> +void mem_event_wake_requesters(struct mem_event_domain *med)
> +{
> +    int free_req;
> +
> +    mem_event_ring_lock(med);
> +
> +    free_req = RING_FREE_REQUESTS(&med->front_ring);
> +    if ( free_req )
> +        wake_up_nr(&med->wq, free_req);
> +
> +    mem_event_ring_unlock(med);
> +}
> +
> +/**
> + * mem_event_wake_waiters - Wake all vcpus waiting for the ring
> + * @d: guest domain
> + * @med: mem_event ring
> + *
> + * mem_event_wake_waiters() will wakeup all vcpus waiting for the ring to
> + * become available.
> + */
> +void mem_event_wake_waiters(struct domain *d, struct mem_event_domain
> *med)
>  {
>      struct vcpu *v;
>
>      for_each_vcpu ( d, v )
> -        if ( test_and_clear_bit(_VPF_mem_event, &v->pause_flags) )
> +        if ( test_and_clear_bit(med->bit, &v->pause_flags) )
>              vcpu_wake(v);
>  }
>
> -void mem_event_mark_and_pause(struct vcpu *v)
> +/**
> + * mem_event_mark_and_sleep - Put vcpu to sleep
> + * @v: guest vcpu
> + * @med: mem_event ring
> + *
> + * mem_event_mark_and_sleep() tags vcpu and put it to sleep.
> + * The vcpu will resume execution in mem_event_wake_waiters().
> + */
> +void mem_event_mark_and_sleep(struct vcpu *v, struct mem_event_domain
> *med)
>  {
> -    set_bit(_VPF_mem_event, &v->pause_flags);
> +    set_bit(med->bit, &v->pause_flags);
>      vcpu_sleep_nosync(v);
>  }
>
> -void mem_event_put_req_producers(struct mem_event_domain *med)
> +/**
> + * mem_event_release_slot - Release a claimed slot
> + * @med: mem_event ring
> + *
> + * mem_event_release_slot() releases a claimed slot in the mem_event
> ring.
> + */
> +void mem_event_release_slot(struct domain *d, struct mem_event_domain
> *med)
>  {
>      mem_event_ring_lock(med);
> -    med->req_producers--;
> +    if ( current->domain == d )
> +        med->target_producers--;
> +    else
> +        med->foreign_producers--;
>      mem_event_ring_unlock(med);
>  }
>
> -int mem_event_check_ring(struct domain *d, struct mem_event_domain *med)
> +/**
> + * mem_event_claim_slot - Check state of a mem_event ring
> + * @d: guest domain
> + * @med: mem_event ring
> + *
> + * Return codes: < 0: the ring is not yet configured
> + *                 0: the ring has some room
> + *               > 0: the ring is full
> + *
> + * mem_event_claim_slot() checks the state of the given mem_event ring.
> + * If the current vcpu belongs to the guest domain, the function assumes
> that
> + * mem_event_put_request() will sleep until the ring has room again.
> + * A guest can always place at least one request.
> + *
> + * If the current vcpu does not belong to the target domain the caller
> must try
> + * again until there is room. A slot is claimed and the caller can place
> a
> + * request. If the caller does not need to send a request, the claimed
> slot has
> + * to be released with mem_event_release_slot().
> + */
> +int mem_event_claim_slot(struct domain *d, struct mem_event_domain *med)
>  {
> -    struct vcpu *curr = current;
> -    int free_requests;
> +    int free_req;
>      int ring_full = 1;
>
>      if ( !med->ring_page )
> @@ -211,16 +317,17 @@ int mem_event_check_ring(struct domain *
>
>      mem_event_ring_lock(med);
>
> -    free_requests = RING_FREE_REQUESTS(&med->front_ring);
> -    if ( med->req_producers < free_requests )
> +    free_req = RING_FREE_REQUESTS(&med->front_ring);
> +
> +    if ( current->domain == d ) {
> +        med->target_producers++;
> +        ring_full = 0;
> +    } else if ( med->foreign_producers + med->target_producers + 1 <
> free_req )
>      {
> -        med->req_producers++;
> +        med->foreign_producers++;
>          ring_full = 0;
>      }
>
> -    if ( ring_full && (curr->domain == d) )
> -        mem_event_mark_and_pause(curr);
> -
>      mem_event_ring_unlock(med);
>
>      return ring_full;
> @@ -287,7 +394,7 @@ int mem_event_domctl(struct domain *d, x
>              if ( p2m->pod.entry_count )
>                  break;
>
> -            rc = mem_event_enable(d, mec, med);
> +            rc = mem_event_enable(d, mec, _VPF_mem_paging, med);
>          }
>          break;
>
> @@ -326,7 +433,7 @@ int mem_event_domctl(struct domain *d, x
>              if ( boot_cpu_data.x86_vendor != X86_VENDOR_INTEL )
>                  break;
>
> -            rc = mem_event_enable(d, mec, med);
> +            rc = mem_event_enable(d, mec, _VPF_mem_access, med);
Ok, the idea of bit is that different vcpus will sleep with different
pause flags, depending on the ring they're sleeping on. But this is only
used in wake_waiters, which is not used by all rings. In fact, why do we
need wake_waiters with wait queues?

>          }
>          break;
>
> diff -r a4d7c27ec1f1 -r cd163bcd0f06 xen/arch/x86/mm/mem_sharing.c
> --- a/xen/arch/x86/mm/mem_sharing.c
> +++ b/xen/arch/x86/mm/mem_sharing.c
> @@ -253,18 +253,10 @@ static void mem_sharing_audit(void)
>  #endif
>
>
> -static struct page_info* mem_sharing_alloc_page(struct domain *d,
> -                                                unsigned long gfn)
> +static void mem_sharing_notify_helper(struct domain *d, unsigned long
> gfn)
>  {
> -    struct page_info* page;
>      struct vcpu *v = current;
> -    mem_event_request_t req;
> -
> -    page = alloc_domheap_page(d, 0);
> -    if(page != NULL) return page;
> -
> -    memset(&req, 0, sizeof(req));
> -    req.type = MEM_EVENT_TYPE_SHARED;
> +    mem_event_request_t req = { .type = MEM_EVENT_TYPE_SHARED };
>
>      if ( v->domain != d )
>      {
> @@ -275,20 +267,18 @@ static struct page_info* mem_sharing_all
>          gdprintk(XENLOG_ERR,
>                   "Failed alloc on unshare path for foreign (%d)
> lookup\n",
>                   d->domain_id);
> -        return page;
> +        return;
>      }
>
> -    vcpu_pause_nosync(v);
> -    req.flags |= MEM_EVENT_FLAG_VCPU_PAUSED;
> +    if (mem_event_claim_slot(d, &d->mem_event->share) < 0)
> +        return;
>
> -    if(mem_event_check_ring(d, &d->mem_event->share)) return page;
> -
> +    req.flags = MEM_EVENT_FLAG_VCPU_PAUSED;
>      req.gfn = gfn;
>      req.p2mt = p2m_ram_shared;
>      req.vcpu_id = v->vcpu_id;
>      mem_event_put_request(d, &d->mem_event->share, &req);
> -
> -    return page;
> +    vcpu_pause_nosync(v);
>  }
>
>  unsigned int mem_sharing_get_nr_saved_mfns(void)
> @@ -653,7 +643,7 @@ gfn_found:
>      if(ret == 0) goto private_page_found;
>
>      old_page = page;
> -    page = mem_sharing_alloc_page(d, gfn);
> +    page = alloc_domheap_page(d, 0);
>      if(!page)
>      {
>          /* We've failed to obtain memory for private page. Need to re-add
> the
> @@ -661,6 +651,7 @@ gfn_found:
>          list_add(&gfn_info->list, &hash_entry->gfns);
>          put_gfn(d, gfn);
>          shr_unlock();
> +        mem_sharing_notify_helper(d, gfn);
This is nice. Do you think PoD could use this, should it ever run into a
ENOMEM situation? And what about mem_paging_prep? Perhaps, rather than a
sharing ring (which is bit rotted) we could have an ENOMEM ring with a
utility launched by xencommons listening. The problem, again, is what if
ENOMEM is itself caused by dom0 (e.g. writable mapping of a shared page)

>          return -ENOMEM;
>      }
>
> diff -r a4d7c27ec1f1 -r cd163bcd0f06 xen/arch/x86/mm/p2m.c
> --- a/xen/arch/x86/mm/p2m.c
> +++ b/xen/arch/x86/mm/p2m.c
> @@ -861,20 +861,12 @@ int p2m_mem_paging_evict(struct domain *
>   */
>  void p2m_mem_paging_drop_page(struct domain *d, unsigned long gfn)
>  {
> -    struct vcpu *v = current;
> -    mem_event_request_t req;
> +    mem_event_request_t req = { .type = MEM_EVENT_TYPE_PAGING, .gfn = gfn
> };
>
> -    /* Check that there's space on the ring for this request */
> -    if ( mem_event_check_ring(d, &d->mem_event->paging) == 0)
> -    {
> -        /* Send release notification to pager */
> -        memset(&req, 0, sizeof(req));
> -        req.flags |= MEM_EVENT_FLAG_DROP_PAGE;
> -        req.gfn = gfn;
> -        req.vcpu_id = v->vcpu_id;
> +    /* Send release notification to pager */
> +    req.flags = MEM_EVENT_FLAG_DROP_PAGE;
>
> -        mem_event_put_request(d, &d->mem_event->paging, &req);
> -    }
> +    mem_event_put_request(d, &d->mem_event->paging, &req);
>  }
>
>  /**
> @@ -908,7 +900,7 @@ void p2m_mem_paging_populate(struct doma
>      struct p2m_domain *p2m = p2m_get_hostp2m(d);
>
>      /* Check that there's space on the ring for this request */
> -    if ( mem_event_check_ring(d, &d->mem_event->paging) )
> +    if ( mem_event_claim_slot(d, &d->mem_event->paging) )
>          return;
>
>      memset(&req, 0, sizeof(req));
> @@ -938,7 +930,7 @@ void p2m_mem_paging_populate(struct doma
>      else if ( p2mt != p2m_ram_paging_out && p2mt != p2m_ram_paged )
>      {
>          /* gfn is already on its way back and vcpu is not paused */
> -        mem_event_put_req_producers(&d->mem_event->paging);
> +        mem_event_release_slot(d, &d->mem_event->paging);
>          return;
>      }
>
> @@ -1078,8 +1070,8 @@ void p2m_mem_paging_resume(struct domain
>      if ( rsp.flags & MEM_EVENT_FLAG_VCPU_PAUSED )
>          vcpu_unpause(d->vcpu[rsp.vcpu_id]);
>
> -    /* Unpause any domains that were paused because the ring was full */
> -    mem_event_unpause_vcpus(d);
> +    /* Wake vcpus waiting for room in the ring */
> +    mem_event_wake_requesters(&d->mem_event->paging);
>  }
>
>  void p2m_mem_access_check(unsigned long gpa, bool_t gla_valid, unsigned
> long gla,
> @@ -1108,7 +1100,7 @@ void p2m_mem_access_check(unsigned long
>      p2m_unlock(p2m);
>
>      /* Otherwise, check if there is a memory event listener, and send the
> message along */
> -    res = mem_event_check_ring(d, &d->mem_event->access);
> +    res = mem_event_claim_slot(d, &d->mem_event->access);
>      if ( res < 0 )
>      {
>          /* No listener */
> @@ -1118,7 +1110,7 @@ void p2m_mem_access_check(unsigned long
>                     "Memory access permissions failure, no mem_event
> listener: pausing VCPU %d, dom %d\n",
>                     v->vcpu_id, d->domain_id);
>
> -            mem_event_mark_and_pause(v);
> +            mem_event_mark_and_sleep(v, &d->mem_event->access);
>          }
>          else
>          {
> @@ -1167,9 +1159,11 @@ void p2m_mem_access_resume(struct domain
>      if ( rsp.flags & MEM_EVENT_FLAG_VCPU_PAUSED )
>          vcpu_unpause(d->vcpu[rsp.vcpu_id]);
>
> -    /* Unpause any domains that were paused because the ring was full or
> no listener
> -     * was available */
> -    mem_event_unpause_vcpus(d);
> +    /* Wake vcpus waiting for room in the ring */
> +    mem_event_wake_requesters(&d->mem_event->access);
> +
> +    /* Unpause all vcpus that were paused because no listener was
> available */
> +    mem_event_wake_waiters(d, &d->mem_event->access);
Is this not used in p2m_mem_paging_resume? Why the difference? Why are two
mechanisms needed (wake_requesters, wake_sleepers)?

Thanks
Andres

>  }
>
>
> diff -r a4d7c27ec1f1 -r cd163bcd0f06 xen/include/asm-x86/mem_event.h
> --- a/xen/include/asm-x86/mem_event.h
> +++ b/xen/include/asm-x86/mem_event.h
> @@ -24,13 +24,13 @@
>  #ifndef __MEM_EVENT_H__
>  #define __MEM_EVENT_H__
>
> -/* Pauses VCPU while marking pause flag for mem event */
> -void mem_event_mark_and_pause(struct vcpu *v);
> -int mem_event_check_ring(struct domain *d, struct mem_event_domain *med);
> -void mem_event_put_req_producers(struct mem_event_domain *med);
> +int mem_event_claim_slot(struct domain *d, struct mem_event_domain *med);
> +void mem_event_release_slot(struct domain *d, struct mem_event_domain
> *med);
>  void mem_event_put_request(struct domain *d, struct mem_event_domain
> *med, mem_event_request_t *req);
>  void mem_event_get_response(struct mem_event_domain *med,
> mem_event_response_t *rsp);
> -void mem_event_unpause_vcpus(struct domain *d);
> +void mem_event_wake_requesters(struct mem_event_domain *med);
> +void mem_event_wake_waiters(struct domain *d, struct mem_event_domain
> *med);
> +void mem_event_mark_and_sleep(struct vcpu *v, struct mem_event_domain
> *med);
>
>  int mem_event_domctl(struct domain *d, xen_domctl_mem_event_op_t *mec,
>                       XEN_GUEST_HANDLE(void) u_domctl);
> diff -r a4d7c27ec1f1 -r cd163bcd0f06 xen/include/xen/sched.h
> --- a/xen/include/xen/sched.h
> +++ b/xen/include/xen/sched.h
> @@ -14,6 +14,7 @@
>  #include <xen/nodemask.h>
>  #include <xen/radix-tree.h>
>  #include <xen/multicall.h>
> +#include <xen/wait.h>
>  #include <public/xen.h>
>  #include <public/domctl.h>
>  #include <public/sysctl.h>
> @@ -183,7 +184,8 @@ struct mem_event_domain
>  {
>      /* ring lock */
>      spinlock_t ring_lock;
> -    unsigned int req_producers;
> +    unsigned short foreign_producers;
> +    unsigned short target_producers;
>      /* shared page */
>      mem_event_shared_page_t *shared_page;
>      /* shared ring page */
> @@ -192,6 +194,10 @@ struct mem_event_domain
>      mem_event_front_ring_t front_ring;
>      /* event channel port (vcpu0 only) */
>      int xen_port;
> +    /* mem_event bit for vcpu->pause_flags */
> +    int bit;
> +    /* list of vcpus waiting for room in the ring */
> +    struct waitqueue_head wq;
>  };
>
>  struct mem_event_per_domain
> @@ -615,9 +621,12 @@ static inline struct domain *next_domain
>   /* VCPU affinity has changed: migrating to a new CPU. */
>  #define _VPF_migrating       3
>  #define VPF_migrating        (1UL<<_VPF_migrating)
> - /* VCPU is blocked on memory-event ring. */
> -#define _VPF_mem_event       4
> -#define VPF_mem_event        (1UL<<_VPF_mem_event)
> + /* VCPU is blocked due to missing mem_paging ring. */
> +#define _VPF_mem_paging      4
> +#define VPF_mem_paging       (1UL<<_VPF_mem_paging)
> + /* VCPU is blocked due to missing mem_access ring. */
> +#define _VPF_mem_access      5
> +#define VPF_mem_access       (1UL<<_VPF_mem_access)
>
>  static inline int vcpu_runnable(struct vcpu *v)
>  {
>
>
>
> ------------------------------
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>
>
> End of Xen-devel Digest, Vol 82, Issue 66
> *****************************************
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 15:58:58 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 15:58:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXawA-0001Uy-8S; Mon, 05 Dec 2011 15:58:38 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RXaw8-0001Ut-9A
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 15:58:36 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1323100640!49552685!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjAyNg==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25722 invoked from network); 5 Dec 2011 15:57:20 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Dec 2011 15:57:20 -0000
X-IronPort-AV: E=Sophos;i="4.71,299,1320624000"; 
   d="scan'208";a="9294429"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Dec 2011 15:57:52 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Mon, 5 Dec 2011
	15:57:52 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Mon, 5 Dec 2011 15:57:48 +0000
In-Reply-To: <alpine.DEB.2.00.1112051440170.31179@kaball-desktop>
References: <alpine.DEB.2.00.1112051053180.31179@kaball-desktop>
	<1323093585.29870.192.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1112051440170.31179@kaball-desktop>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323100671.23681.3.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Ian
	Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] qemu_timer_pending/qemu_get_timer: cope with NULL
 timers
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2011-12-05 at 14:53 +0000, Stefano Stabellini wrote:
> On Mon, 5 Dec 2011, Ian Campbell wrote:
> > On Mon, 2011-12-05 at 10:54 +0000, Stefano Stabellini wrote:
> > > qemu_timer_pending and qemu_get_timer: don't crash if the timer passed
> > > as an argument is NULL.
> > 
> > It would have been useful to mention why a NULL timer is valid here.
> > Apart from just being good changelog practice to explain the actual
> > reason for a change this would also help tell us why this issue isn't
> > being solved further up the stack. One the face of it this seem like
> > this ought to be a bug in the caller of qemu_mod_timer.
> 
> Yes, I have been a little bit too concise.
> 
> qemu_mod_timer is not the only caller of
> qemu_timer_pending/qemu_get_timer: they are also called by some qemu
> save/restore related functions, where the timer being saved and restored
> can actually be NULL.

Thanks.

It sounds to me like the NULL check should have been in the save/restore
code but the patch is in so lets not worry about it.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 15:58:58 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 15:58:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXawA-0001Uy-8S; Mon, 05 Dec 2011 15:58:38 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RXaw8-0001Ut-9A
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 15:58:36 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1323100640!49552685!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjAyNg==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25722 invoked from network); 5 Dec 2011 15:57:20 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Dec 2011 15:57:20 -0000
X-IronPort-AV: E=Sophos;i="4.71,299,1320624000"; 
   d="scan'208";a="9294429"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Dec 2011 15:57:52 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Mon, 5 Dec 2011
	15:57:52 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Mon, 5 Dec 2011 15:57:48 +0000
In-Reply-To: <alpine.DEB.2.00.1112051440170.31179@kaball-desktop>
References: <alpine.DEB.2.00.1112051053180.31179@kaball-desktop>
	<1323093585.29870.192.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1112051440170.31179@kaball-desktop>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323100671.23681.3.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Ian
	Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] qemu_timer_pending/qemu_get_timer: cope with NULL
 timers
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2011-12-05 at 14:53 +0000, Stefano Stabellini wrote:
> On Mon, 5 Dec 2011, Ian Campbell wrote:
> > On Mon, 2011-12-05 at 10:54 +0000, Stefano Stabellini wrote:
> > > qemu_timer_pending and qemu_get_timer: don't crash if the timer passed
> > > as an argument is NULL.
> > 
> > It would have been useful to mention why a NULL timer is valid here.
> > Apart from just being good changelog practice to explain the actual
> > reason for a change this would also help tell us why this issue isn't
> > being solved further up the stack. One the face of it this seem like
> > this ought to be a bug in the caller of qemu_mod_timer.
> 
> Yes, I have been a little bit too concise.
> 
> qemu_mod_timer is not the only caller of
> qemu_timer_pending/qemu_get_timer: they are also called by some qemu
> save/restore related functions, where the timer being saved and restored
> can actually be NULL.

Thanks.

It sounds to me like the NULL check should have been in the save/restore
code but the patch is in so lets not worry about it.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 16:02:19 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 16:02:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXazP-00023b-3I; Mon, 05 Dec 2011 16:01:59 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RXazO-00023M-B0
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 16:01:58 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-7.tower-174.messagelabs.com!1323100873!4329035!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4041 invoked from network); 5 Dec 2011 16:01:13 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-7.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 5 Dec 2011 16:01:13 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RXaye-000Pdb-5q; Mon, 05 Dec 2011 16:01:12 +0000
Date: Mon, 5 Dec 2011 16:01:12 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20111205160112.GB93116@ocelot.phlegethon.org>
References: <patchbomb.1323097919@xdev.gridcentric.ca>
	<790cd814bee86c717fe4.1323097924@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <790cd814bee86c717fe4.1323097924@xdev.gridcentric.ca>
User-Agent: Mutt/1.4.2.1i
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com, olaf@aepfle.de,
	keir.xen@gmail.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 5 of 5] Ignore memory events with an
	obviously invalid gfn
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 10:12 -0500 on 05 Dec (1323079924), Andres Lagar-Cavilla wrote:
>  xen/arch/x86/mm/mem_sharing.c  |  2 ++
>  xen/arch/x86/mm/p2m.c          |  4 ++++
>  xen/include/public/mem_event.h |  7 +++++++
>  3 files changed, 13 insertions(+), 0 deletions(-)
> 
> 
> Ring semantics require that for every request, a response be put. This
> allows consumer to place a dummy response if need be.
> 
> diff -r c71f4c5b42f0 -r 790cd814bee8 xen/include/public/mem_event.h
> --- a/xen/include/public/mem_event.h
> +++ b/xen/include/public/mem_event.h
> @@ -76,6 +76,13 @@ typedef struct mem_event_st {
>  
>  DEFINE_RING_TYPES(mem_event, mem_event_request_t, mem_event_response_t);
>  
> +#define INVALID_RSP_GFN -1UL
> +

On a 32-bit system this doesn't do what you want.

Actually, can you use a flag for this, please?  Wedging it into the gfn
field seems a bit of a hack, and we have plenty of flag bits left.

Tim.

> +#define DUMMY_MEM_EVENT_RSP(_r)         ((_r)->gfn == INVALID_RSP_GFN)
> +#define MAKE_MEM_EVENT_RSP_DUMMY(_r)    ((_r)->gfn = INVALID_RSP_GFN)
> +#define DECLARE_DUMMY_MEM_EVENT_RSP(_name) \
> +    mem_event_response_t _name = { .gfn = INVALID_RSP_GFN }
> +
>  #endif
>  
>  /*
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 16:02:19 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 16:02:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXazP-00023b-3I; Mon, 05 Dec 2011 16:01:59 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RXazO-00023M-B0
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 16:01:58 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-7.tower-174.messagelabs.com!1323100873!4329035!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4041 invoked from network); 5 Dec 2011 16:01:13 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-7.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 5 Dec 2011 16:01:13 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RXaye-000Pdb-5q; Mon, 05 Dec 2011 16:01:12 +0000
Date: Mon, 5 Dec 2011 16:01:12 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20111205160112.GB93116@ocelot.phlegethon.org>
References: <patchbomb.1323097919@xdev.gridcentric.ca>
	<790cd814bee86c717fe4.1323097924@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <790cd814bee86c717fe4.1323097924@xdev.gridcentric.ca>
User-Agent: Mutt/1.4.2.1i
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com, olaf@aepfle.de,
	keir.xen@gmail.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 5 of 5] Ignore memory events with an
	obviously invalid gfn
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 10:12 -0500 on 05 Dec (1323079924), Andres Lagar-Cavilla wrote:
>  xen/arch/x86/mm/mem_sharing.c  |  2 ++
>  xen/arch/x86/mm/p2m.c          |  4 ++++
>  xen/include/public/mem_event.h |  7 +++++++
>  3 files changed, 13 insertions(+), 0 deletions(-)
> 
> 
> Ring semantics require that for every request, a response be put. This
> allows consumer to place a dummy response if need be.
> 
> diff -r c71f4c5b42f0 -r 790cd814bee8 xen/include/public/mem_event.h
> --- a/xen/include/public/mem_event.h
> +++ b/xen/include/public/mem_event.h
> @@ -76,6 +76,13 @@ typedef struct mem_event_st {
>  
>  DEFINE_RING_TYPES(mem_event, mem_event_request_t, mem_event_response_t);
>  
> +#define INVALID_RSP_GFN -1UL
> +

On a 32-bit system this doesn't do what you want.

Actually, can you use a flag for this, please?  Wedging it into the gfn
field seems a bit of a hack, and we have plenty of flag bits left.

Tim.

> +#define DUMMY_MEM_EVENT_RSP(_r)         ((_r)->gfn == INVALID_RSP_GFN)
> +#define MAKE_MEM_EVENT_RSP_DUMMY(_r)    ((_r)->gfn = INVALID_RSP_GFN)
> +#define DECLARE_DUMMY_MEM_EVENT_RSP(_name) \
> +    mem_event_response_t _name = { .gfn = INVALID_RSP_GFN }
> +
>  #endif
>  
>  /*
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 16:11:50 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 16: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.xensource.com>)
	id 1RXb8b-0002I7-5B; Mon, 05 Dec 2011 16:11:29 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Neal.Taylor@ca.com>) id 1RXb8Z-0002I2-Rw
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 16:11:28 +0000
X-Env-Sender: Neal.Taylor@ca.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1323101392!59514325!1
X-Originating-IP: [74.125.149.73]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8987 invoked from network); 5 Dec 2011 16:09:54 -0000
Received: from na3sys009aog104.obsmtp.com (HELO na3sys009aog104.obsmtp.com)
	(74.125.149.73)
	by server-7.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Dec 2011 16:09:54 -0000
Received: from USILMS191.ca.com ([141.202.246.45]) (using TLSv1) by
	na3sys009aob104.postini.com ([74.125.148.12]) with SMTP
	ID DSNKTtztAHbv3Ou1ZKLeqC9UWySeR3r/culi@postini.com;
	Mon, 05 Dec 2011 08:10:42 PST
Received: from USILMS171.ca.com (141.202.6.21) by USILMS191.ca.com
	(141.202.246.45) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Mon, 5 Dec 2011 11:10:39 -0500
Received: from USILMS110A.ca.com ([169.254.1.109]) by USILMS171.ca.com
	([141.202.6.21]) with mapi id 14.01.0289.001;
	Mon, 5 Dec 2011 11:10:39 -0500
From: "Taylor, Neal E" <Neal.Taylor@ca.com>
To: Ian Campbell <Ian.Campbell@citrix.com>, Andy Burns <xen.lists@burns.me.uk>
Thread-Topic: [Xen-devel] Re: PCI passthrough stopped working, brainache!
Thread-Index: AQHMk7YgpF9M35vM3k2JP30JnOFauZXNqUEw
Date: Mon, 5 Dec 2011 16:10:39 +0000
Message-ID: <3E243B26F475504B9BB0BCC9728B0DA629E14CDE@USILMS110A.ca.com>
References: <CAE1-PReH55X375oSb_gx4K_2iTTo67xpFfS8r7zv3KPtiOxj_A@mail.gmail.com>
	<CAE1-PRc9LqO07TjH3TnfSnEB8gLkBhw2211syeA04XPWts62Xg@mail.gmail.com>
	<CAE1-PRfg3fkMMSQyPO+y8dqxcE-KNJc--6bx84aouaQorOF27w@mail.gmail.com>
	<20111012035032.GB26092@phenom.oracle.com>
	<CAE1-PRfuo10T2iKJUNoY=Aj4S_TjUbiPT1jARv+iD7g+1qWuNg@mail.gmail.com>
	<CAE1-PRd9Kicm=dRtDmPKGXM8-fp62NyvDdpww38jA3Afwrt8+g@mail.gmail.com>
	<20111013181543.GF15499@phenom.oracle.com>
	<CAE1-PRfGTxeQ59jmHfB6bKKk2+B5bNnKhAvXoV-5P__+nkhgKQ@mail.gmail.com>
	<1318674976.11016.24.camel@dagon.hellion.org.uk>
	<CAE1-PRe3FZknxdCLkhkGbzd-i=y5eGMAwY+yoa36j61oHNcRSw@mail.gmail.com>
	<CAE1-PRcUkuBexHrCnCCNEA4m=yoC8qWjmtfsaSq0h9NUA6r2cw@mail.gmail.com>
	<1319616286.9436.1.camel@zakaz.uk.xensource.com>
In-Reply-To: <1319616286.9436.1.camel@zakaz.uk.xensource.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [138.42.46.108]
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] PCI passthrough stopped working, brainache!
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Andy,

Did I mess the solution for this or are you still working with 'mem=3.99999G'?

Neal Taylor
CA Technologies

-----Original Message-----
From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Ian Campbell
Sent: Wednesday, October 26, 2011 1:05 AM
To: Andy Burns
Cc: xen-devel
Subject: Re: [Xen-devel] Re: PCI passthrough stopped working, brainache!

On Mon, 2011-10-24 at 12:30 +0100, Andy Burns wrote:
> On 15 October 2011 12:27, Andy Burns <xen.lists@burns.me.uk> wrote:
> 
> > On 15 October 2011 11:36, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> >
> >> I think you've got 8G of RAM so one thing which might be worth trying is
> >> to give "mem=2G"
> >
> > A coconut for the gentleman!
> 
> I can see that the devs have been busy getting their ducks in a row
> for when the 3.2 merge window opens (3.1 is released now) so not
> wanted to pester about this as it's OK for now with the workarounds.
> 
> Initially I tried mem=2G, with dom0_mem=512M and two domUs of 512M and
> 1G respectively, I presume this caused a bit of ballooning in dom0 as
> I caught it with 400M'ish at one point and I had a little instability.
> 
> I pushed it up to mem=3G and at the same time added irqpoll for dom0
> and the pci domU (because I was seeing a few "nobody cared" messages
> in the domU at bootup and in the dom0 after shutting down the domU)
> those changes so far have resulted in a stable setup.
> 
> Not wanting to reboot the dom0 just yet (would like to see how stable
> it really is) but want to think about things to try when I *do* reboot
> it,
> I'm assuming the DMA problem will rear its head again if I try mem >=
> 4G, I haven't tried anything with dma_bits yet either, anything other
> suggestions or logging that might help?

Konrad had some suggestions in
<20111020034000.GA2401@phenom.dumpdata.com> which would be worth trying.
(that mail was sent on Thursday but appears to have sat in a queue
somewhere until after you sent this mail so just checking you've seen
it).

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 16:11:50 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 16: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.xensource.com>)
	id 1RXb8b-0002I7-5B; Mon, 05 Dec 2011 16:11:29 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Neal.Taylor@ca.com>) id 1RXb8Z-0002I2-Rw
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 16:11:28 +0000
X-Env-Sender: Neal.Taylor@ca.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1323101392!59514325!1
X-Originating-IP: [74.125.149.73]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8987 invoked from network); 5 Dec 2011 16:09:54 -0000
Received: from na3sys009aog104.obsmtp.com (HELO na3sys009aog104.obsmtp.com)
	(74.125.149.73)
	by server-7.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Dec 2011 16:09:54 -0000
Received: from USILMS191.ca.com ([141.202.246.45]) (using TLSv1) by
	na3sys009aob104.postini.com ([74.125.148.12]) with SMTP
	ID DSNKTtztAHbv3Ou1ZKLeqC9UWySeR3r/culi@postini.com;
	Mon, 05 Dec 2011 08:10:42 PST
Received: from USILMS171.ca.com (141.202.6.21) by USILMS191.ca.com
	(141.202.246.45) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Mon, 5 Dec 2011 11:10:39 -0500
Received: from USILMS110A.ca.com ([169.254.1.109]) by USILMS171.ca.com
	([141.202.6.21]) with mapi id 14.01.0289.001;
	Mon, 5 Dec 2011 11:10:39 -0500
From: "Taylor, Neal E" <Neal.Taylor@ca.com>
To: Ian Campbell <Ian.Campbell@citrix.com>, Andy Burns <xen.lists@burns.me.uk>
Thread-Topic: [Xen-devel] Re: PCI passthrough stopped working, brainache!
Thread-Index: AQHMk7YgpF9M35vM3k2JP30JnOFauZXNqUEw
Date: Mon, 5 Dec 2011 16:10:39 +0000
Message-ID: <3E243B26F475504B9BB0BCC9728B0DA629E14CDE@USILMS110A.ca.com>
References: <CAE1-PReH55X375oSb_gx4K_2iTTo67xpFfS8r7zv3KPtiOxj_A@mail.gmail.com>
	<CAE1-PRc9LqO07TjH3TnfSnEB8gLkBhw2211syeA04XPWts62Xg@mail.gmail.com>
	<CAE1-PRfg3fkMMSQyPO+y8dqxcE-KNJc--6bx84aouaQorOF27w@mail.gmail.com>
	<20111012035032.GB26092@phenom.oracle.com>
	<CAE1-PRfuo10T2iKJUNoY=Aj4S_TjUbiPT1jARv+iD7g+1qWuNg@mail.gmail.com>
	<CAE1-PRd9Kicm=dRtDmPKGXM8-fp62NyvDdpww38jA3Afwrt8+g@mail.gmail.com>
	<20111013181543.GF15499@phenom.oracle.com>
	<CAE1-PRfGTxeQ59jmHfB6bKKk2+B5bNnKhAvXoV-5P__+nkhgKQ@mail.gmail.com>
	<1318674976.11016.24.camel@dagon.hellion.org.uk>
	<CAE1-PRe3FZknxdCLkhkGbzd-i=y5eGMAwY+yoa36j61oHNcRSw@mail.gmail.com>
	<CAE1-PRcUkuBexHrCnCCNEA4m=yoC8qWjmtfsaSq0h9NUA6r2cw@mail.gmail.com>
	<1319616286.9436.1.camel@zakaz.uk.xensource.com>
In-Reply-To: <1319616286.9436.1.camel@zakaz.uk.xensource.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [138.42.46.108]
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] PCI passthrough stopped working, brainache!
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Andy,

Did I mess the solution for this or are you still working with 'mem=3.99999G'?

Neal Taylor
CA Technologies

-----Original Message-----
From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Ian Campbell
Sent: Wednesday, October 26, 2011 1:05 AM
To: Andy Burns
Cc: xen-devel
Subject: Re: [Xen-devel] Re: PCI passthrough stopped working, brainache!

On Mon, 2011-10-24 at 12:30 +0100, Andy Burns wrote:
> On 15 October 2011 12:27, Andy Burns <xen.lists@burns.me.uk> wrote:
> 
> > On 15 October 2011 11:36, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> >
> >> I think you've got 8G of RAM so one thing which might be worth trying is
> >> to give "mem=2G"
> >
> > A coconut for the gentleman!
> 
> I can see that the devs have been busy getting their ducks in a row
> for when the 3.2 merge window opens (3.1 is released now) so not
> wanted to pester about this as it's OK for now with the workarounds.
> 
> Initially I tried mem=2G, with dom0_mem=512M and two domUs of 512M and
> 1G respectively, I presume this caused a bit of ballooning in dom0 as
> I caught it with 400M'ish at one point and I had a little instability.
> 
> I pushed it up to mem=3G and at the same time added irqpoll for dom0
> and the pci domU (because I was seeing a few "nobody cared" messages
> in the domU at bootup and in the dom0 after shutting down the domU)
> those changes so far have resulted in a stable setup.
> 
> Not wanting to reboot the dom0 just yet (would like to see how stable
> it really is) but want to think about things to try when I *do* reboot
> it,
> I'm assuming the DMA problem will rear its head again if I try mem >=
> 4G, I haven't tried anything with dma_bits yet either, anything other
> suggestions or logging that might help?

Konrad had some suggestions in
<20111020034000.GA2401@phenom.dumpdata.com> which would be worth trying.
(that mail was sent on Thursday but appears to have sat in a queue
somewhere until after you sent this mail so just checking you've seen
it).

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 16:11:58 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 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.xensource.com>)
	id 1RXb8o-0002JY-ID; Mon, 05 Dec 2011 16:11:42 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RXb8m-0002IK-4e
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 16:11:41 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1323101455!1399569!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjAyNg==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10203 invoked from network); 5 Dec 2011 16:10:55 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Dec 2011 16:10:55 -0000
X-IronPort-AV: E=Sophos;i="4.71,299,1320624000"; 
   d="scan'208";a="9294812"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Dec 2011 16:10:54 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Mon, 5 Dec 2011
	16:10:54 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefan Bader <stefan.bader@canonical.com>
Date: Mon, 5 Dec 2011 16:10:54 +0000
In-Reply-To: <4EDCDB75.6010403@canonical.com>
References: <4ED798B2.1040309@canonical.com>
	<20111201180944.GH12984@reaktio.net>	<4ED8A45A.3050403@canonical.com>
	<20111202104110.GL12984@reaktio.net>
	<BA1B675D85BDD87795D1666C@Ximines.local>
	<1322844048.29870.155.camel@zakaz.uk.xensource.com>
	<8D88C4D6C31A598129A942AD@Ximines.local>
	<4EDCDB75.6010403@canonical.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323101454.23681.7.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Alex Bligh <alex@alex.org.uk>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Xen 4.x / Linux 3.x (dom0 and HVM domU) and	NIC
 handling
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2011-12-05 at 14:55 +0000, Stefan Bader wrote:
> On 02.12.2011 18:16, Alex Bligh wrote:
> > 
> > 
> > --On 2 December 2011 16:40:48 +0000 Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > 
> >>> AFAIK changing xen_platform_pci=0|1 will switch rather more than just
> >>> the NIC. It will switch your disk too, instantly causing your previously
> >>> happily booting OS to fail to boot as the root device name changes.
> >>
> >> We recommend you use "root=LABEL=foo" rather than "root=/dev/blah" for
> >> this reason. Fortunately most distros use that scheme by default these
> >> days.
> > 
> > Yes; and /etc/fstab. UUID= works too.
> > 
> > FWIW my experience is that various built-for-cloud type distros don't use
> > that scheme, mainly because they use grub1 which IIRC does not support
> > this, and building images in a non-root environment that have grub1
> > in is rather easier than grub2. So, for instance, all the vm-builder
> > stuff in debian/ubuntu used grub1 and did not work this way.
> > 
> > However, my point was that xen_platform_pci does not only change
> > whether your net driver is emulated or PVHVM, but also whether your
> > disk, and indeed everything else is emulated or PVHVM.
> > 
> I can understand a policy of using the pv devices whenever it is possible. The
> change of the device name is there but as pointed out most distro installations
> try to avoid those anyway since there is a similar problem with usb keys or
> drives potentially moving around. Same for network devices that get mapped based
> on mac address.
> Not sure how real the need for a mixed setup is.

Basically non-existent IMHO. The option to not use pv devices is more
for debugging or recovering in the case that you can't boot from the pv
device for some reason (e.g. because you aren't using LABEL/UUID= ;-)).

> If, then I can see that it gets
> a bit weird. While you can use xen_emul_unplug with other keywords to prevent
> unplugging disks or nics. But that would not remove the related pv devices.

It does (at least in upstream Linux) prevent the PV driver from
initialising, which isn't quite the same but serves the same end
purpose.

Ian.

>  And
> I am not sure whether this would be a desired behavior or actually be feasible
> in a clean layered way. Personally I would think nobody could want both
> interfaces at the same time but I would not assume I know all of the use cases.
> 
> -Stefan



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 16:11:58 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 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.xensource.com>)
	id 1RXb8o-0002JY-ID; Mon, 05 Dec 2011 16:11:42 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RXb8m-0002IK-4e
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 16:11:41 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1323101455!1399569!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjAyNg==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10203 invoked from network); 5 Dec 2011 16:10:55 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Dec 2011 16:10:55 -0000
X-IronPort-AV: E=Sophos;i="4.71,299,1320624000"; 
   d="scan'208";a="9294812"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Dec 2011 16:10:54 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Mon, 5 Dec 2011
	16:10:54 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefan Bader <stefan.bader@canonical.com>
Date: Mon, 5 Dec 2011 16:10:54 +0000
In-Reply-To: <4EDCDB75.6010403@canonical.com>
References: <4ED798B2.1040309@canonical.com>
	<20111201180944.GH12984@reaktio.net>	<4ED8A45A.3050403@canonical.com>
	<20111202104110.GL12984@reaktio.net>
	<BA1B675D85BDD87795D1666C@Ximines.local>
	<1322844048.29870.155.camel@zakaz.uk.xensource.com>
	<8D88C4D6C31A598129A942AD@Ximines.local>
	<4EDCDB75.6010403@canonical.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323101454.23681.7.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Alex Bligh <alex@alex.org.uk>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Xen 4.x / Linux 3.x (dom0 and HVM domU) and	NIC
 handling
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2011-12-05 at 14:55 +0000, Stefan Bader wrote:
> On 02.12.2011 18:16, Alex Bligh wrote:
> > 
> > 
> > --On 2 December 2011 16:40:48 +0000 Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > 
> >>> AFAIK changing xen_platform_pci=0|1 will switch rather more than just
> >>> the NIC. It will switch your disk too, instantly causing your previously
> >>> happily booting OS to fail to boot as the root device name changes.
> >>
> >> We recommend you use "root=LABEL=foo" rather than "root=/dev/blah" for
> >> this reason. Fortunately most distros use that scheme by default these
> >> days.
> > 
> > Yes; and /etc/fstab. UUID= works too.
> > 
> > FWIW my experience is that various built-for-cloud type distros don't use
> > that scheme, mainly because they use grub1 which IIRC does not support
> > this, and building images in a non-root environment that have grub1
> > in is rather easier than grub2. So, for instance, all the vm-builder
> > stuff in debian/ubuntu used grub1 and did not work this way.
> > 
> > However, my point was that xen_platform_pci does not only change
> > whether your net driver is emulated or PVHVM, but also whether your
> > disk, and indeed everything else is emulated or PVHVM.
> > 
> I can understand a policy of using the pv devices whenever it is possible. The
> change of the device name is there but as pointed out most distro installations
> try to avoid those anyway since there is a similar problem with usb keys or
> drives potentially moving around. Same for network devices that get mapped based
> on mac address.
> Not sure how real the need for a mixed setup is.

Basically non-existent IMHO. The option to not use pv devices is more
for debugging or recovering in the case that you can't boot from the pv
device for some reason (e.g. because you aren't using LABEL/UUID= ;-)).

> If, then I can see that it gets
> a bit weird. While you can use xen_emul_unplug with other keywords to prevent
> unplugging disks or nics. But that would not remove the related pv devices.

It does (at least in upstream Linux) prevent the PV driver from
initialising, which isn't quite the same but serves the same end
purpose.

Ian.

>  And
> I am not sure whether this would be a desired behavior or actually be feasible
> in a clean layered way. Personally I would think nobody could want both
> interfaces at the same time but I would not assume I know all of the use cases.
> 
> -Stefan



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 16:21:41 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 16:21:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXbIB-0002gA-C3; Mon, 05 Dec 2011 16:21:23 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RXbI9-0002ff-MA
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 16:21:22 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-6.tower-174.messagelabs.com!1323102036!4338675!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.5 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMzgzMTM=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMzgzMTM=\n,BODY_RANDOM_LONG
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5864 invoked from network); 5 Dec 2011 16:20:36 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-6.tower-174.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 5 Dec 2011 16:20:36 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1323102036; l=3983;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=jmlSyWlpPIcQOwa1nwVMYScXNew=;
	b=i0Yi0cVz/QKQoUP74AfjQcRgyNR4nlwe9J+TXntXZFe7B7enaJ5eBAoB77BNI1NE/2M
	8UQBBeOqH/P+hHyR0ELbHHa/NuTddQzwBhHKzSDOhg8pA8rwhRa6HOVBKlCHkqZofF0t8
	AZt352GjbTKAQS6stEDpWta79AdoXkht4sc=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFJjS0NG7Q=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-073-038.pools.arcor-ip.net [88.65.73.38])
	by smtp.strato.de (fruni mo17) (RZmta 26.10 AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id w057ddnB5FMjme ;
	Mon, 5 Dec 2011 17:20:17 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 07B6C18637; Mon,  5 Dec 2011 17:20:16 +0100 (CET)
Date: Mon, 5 Dec 2011 17:20:16 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20111205162016.GA13352@aepfle.de>
References: <mailman.3332.1323083995.12970.xen-devel@lists.xensource.com>
	<f5cf6ad4704fe70f3130b832e530e8b0.squirrel@webmail.lagarcavilla.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <f5cf6ad4704fe70f3130b832e530e8b0.squirrel@webmail.lagarcavilla.org>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] mem_event: use wait queue when ring is full
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Dec 05, Andres Lagar-Cavilla wrote:

> > +    med->bit = bit;
> I think it's been asked before for this to have a more expressive name.

I have to recheck, AFAIK it was the mem_bit where mem_ is redundant.

> >  static int mem_event_disable(struct mem_event_domain *med)
> >  {
> > +    if (!list_empty(&med->wq.list))
> > +        return -EBUSY;
> > +
> What does the caller do with EBUSY? Retry?

Yes, and mail the devs at xen-devel that something isn't right ;-)

At least the pager uses this just in the exit path. I dont know about
access and sharing, wether these tools enable/disable more than once at
guest runtime.

> > @@ -287,7 +394,7 @@ int mem_event_domctl(struct domain *d, x
> >              if ( p2m->pod.entry_count )
> >                  break;
> >
> > -            rc = mem_event_enable(d, mec, med);
> > +            rc = mem_event_enable(d, mec, _VPF_mem_paging, med);
> >          }
> >          break;
> >
> > @@ -326,7 +433,7 @@ int mem_event_domctl(struct domain *d, x
> >              if ( boot_cpu_data.x86_vendor != X86_VENDOR_INTEL )
> >                  break;
> >
> > -            rc = mem_event_enable(d, mec, med);
> > +            rc = mem_event_enable(d, mec, _VPF_mem_access, med);

> Ok, the idea of bit is that different vcpus will sleep with different
> pause flags, depending on the ring they're sleeping on. But this is only
> used in wake_waiters, which is not used by all rings. In fact, why do we
> need wake_waiters with wait queues?

Before this patch, mem_event_unpause_vcpus() was used to resume waiters
for the ring itself and for room in the ring.
Now there is mem_event_wake_waiters(), which indicates the ring is
active, and there is mem_event_wake_requesters() which indicates the
ring has room to place guest requests.

I agree that only _VPF_mem_access is really needed, and _VPF_mem_paging
could be removed because paging without having a ring first is not
possible.


> > @@ -653,7 +643,7 @@ gfn_found:
> >      if(ret == 0) goto private_page_found;
> >
> >      old_page = page;
> > -    page = mem_sharing_alloc_page(d, gfn);
> > +    page = alloc_domheap_page(d, 0);
> >      if(!page)
> >      {
> >          /* We've failed to obtain memory for private page. Need to re-add
> > the
> > @@ -661,6 +651,7 @@ gfn_found:
> >          list_add(&gfn_info->list, &hash_entry->gfns);
> >          put_gfn(d, gfn);
> >          shr_unlock();
> > +        mem_sharing_notify_helper(d, gfn);
> This is nice. Do you think PoD could use this, should it ever run into a
> ENOMEM situation? And what about mem_paging_prep? Perhaps, rather than a
> sharing ring (which is bit rotted) we could have an ENOMEM ring with a
> utility launched by xencommons listening. The problem, again, is what if
> ENOMEM is itself caused by dom0 (e.g. writable mapping of a shared page)

I have no idea about mem_sharing. I just move the existing code outside
the lock so that mem_event_put_request() is (hopefully) called without
any locks from mem_sharing_get_nr_saved_mfns().
Since there is appearently no user of a sharing ring, this whole new
mem_sharing_notify_helper() is a big no-op.

> > @@ -1167,9 +1159,11 @@ void p2m_mem_access_resume(struct domain
> >      if ( rsp.flags & MEM_EVENT_FLAG_VCPU_PAUSED )
> >          vcpu_unpause(d->vcpu[rsp.vcpu_id]);
> >
> > -    /* Unpause any domains that were paused because the ring was full or
> > no listener
> > -     * was available */
> > -    mem_event_unpause_vcpus(d);
> > +    /* Wake vcpus waiting for room in the ring */
> > +    mem_event_wake_requesters(&d->mem_event->access);
> > +
> > +    /* Unpause all vcpus that were paused because no listener was
> > available */
> > +    mem_event_wake_waiters(d, &d->mem_event->access);
> Is this not used in p2m_mem_paging_resume? Why the difference? Why are two
> mechanisms needed (wake_requesters, wake_sleepers)?

As said above, wake_sleepers is for those who wait for the ring itself,
and wake_requesters is for room in the ring.
p2m_mem_paging_resume() always has a ring, so it does not need to call
wake_sleepers.


Do you have a suggestion for a better name?

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 16:21:41 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 16:21:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXbIB-0002gA-C3; Mon, 05 Dec 2011 16:21:23 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RXbI9-0002ff-MA
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 16:21:22 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-6.tower-174.messagelabs.com!1323102036!4338675!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.5 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMzgzMTM=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMzgzMTM=\n,BODY_RANDOM_LONG
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5864 invoked from network); 5 Dec 2011 16:20:36 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-6.tower-174.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 5 Dec 2011 16:20:36 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1323102036; l=3983;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=jmlSyWlpPIcQOwa1nwVMYScXNew=;
	b=i0Yi0cVz/QKQoUP74AfjQcRgyNR4nlwe9J+TXntXZFe7B7enaJ5eBAoB77BNI1NE/2M
	8UQBBeOqH/P+hHyR0ELbHHa/NuTddQzwBhHKzSDOhg8pA8rwhRa6HOVBKlCHkqZofF0t8
	AZt352GjbTKAQS6stEDpWta79AdoXkht4sc=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFJjS0NG7Q=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-073-038.pools.arcor-ip.net [88.65.73.38])
	by smtp.strato.de (fruni mo17) (RZmta 26.10 AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id w057ddnB5FMjme ;
	Mon, 5 Dec 2011 17:20:17 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 07B6C18637; Mon,  5 Dec 2011 17:20:16 +0100 (CET)
Date: Mon, 5 Dec 2011 17:20:16 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20111205162016.GA13352@aepfle.de>
References: <mailman.3332.1323083995.12970.xen-devel@lists.xensource.com>
	<f5cf6ad4704fe70f3130b832e530e8b0.squirrel@webmail.lagarcavilla.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <f5cf6ad4704fe70f3130b832e530e8b0.squirrel@webmail.lagarcavilla.org>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] mem_event: use wait queue when ring is full
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Dec 05, Andres Lagar-Cavilla wrote:

> > +    med->bit = bit;
> I think it's been asked before for this to have a more expressive name.

I have to recheck, AFAIK it was the mem_bit where mem_ is redundant.

> >  static int mem_event_disable(struct mem_event_domain *med)
> >  {
> > +    if (!list_empty(&med->wq.list))
> > +        return -EBUSY;
> > +
> What does the caller do with EBUSY? Retry?

Yes, and mail the devs at xen-devel that something isn't right ;-)

At least the pager uses this just in the exit path. I dont know about
access and sharing, wether these tools enable/disable more than once at
guest runtime.

> > @@ -287,7 +394,7 @@ int mem_event_domctl(struct domain *d, x
> >              if ( p2m->pod.entry_count )
> >                  break;
> >
> > -            rc = mem_event_enable(d, mec, med);
> > +            rc = mem_event_enable(d, mec, _VPF_mem_paging, med);
> >          }
> >          break;
> >
> > @@ -326,7 +433,7 @@ int mem_event_domctl(struct domain *d, x
> >              if ( boot_cpu_data.x86_vendor != X86_VENDOR_INTEL )
> >                  break;
> >
> > -            rc = mem_event_enable(d, mec, med);
> > +            rc = mem_event_enable(d, mec, _VPF_mem_access, med);

> Ok, the idea of bit is that different vcpus will sleep with different
> pause flags, depending on the ring they're sleeping on. But this is only
> used in wake_waiters, which is not used by all rings. In fact, why do we
> need wake_waiters with wait queues?

Before this patch, mem_event_unpause_vcpus() was used to resume waiters
for the ring itself and for room in the ring.
Now there is mem_event_wake_waiters(), which indicates the ring is
active, and there is mem_event_wake_requesters() which indicates the
ring has room to place guest requests.

I agree that only _VPF_mem_access is really needed, and _VPF_mem_paging
could be removed because paging without having a ring first is not
possible.


> > @@ -653,7 +643,7 @@ gfn_found:
> >      if(ret == 0) goto private_page_found;
> >
> >      old_page = page;
> > -    page = mem_sharing_alloc_page(d, gfn);
> > +    page = alloc_domheap_page(d, 0);
> >      if(!page)
> >      {
> >          /* We've failed to obtain memory for private page. Need to re-add
> > the
> > @@ -661,6 +651,7 @@ gfn_found:
> >          list_add(&gfn_info->list, &hash_entry->gfns);
> >          put_gfn(d, gfn);
> >          shr_unlock();
> > +        mem_sharing_notify_helper(d, gfn);
> This is nice. Do you think PoD could use this, should it ever run into a
> ENOMEM situation? And what about mem_paging_prep? Perhaps, rather than a
> sharing ring (which is bit rotted) we could have an ENOMEM ring with a
> utility launched by xencommons listening. The problem, again, is what if
> ENOMEM is itself caused by dom0 (e.g. writable mapping of a shared page)

I have no idea about mem_sharing. I just move the existing code outside
the lock so that mem_event_put_request() is (hopefully) called without
any locks from mem_sharing_get_nr_saved_mfns().
Since there is appearently no user of a sharing ring, this whole new
mem_sharing_notify_helper() is a big no-op.

> > @@ -1167,9 +1159,11 @@ void p2m_mem_access_resume(struct domain
> >      if ( rsp.flags & MEM_EVENT_FLAG_VCPU_PAUSED )
> >          vcpu_unpause(d->vcpu[rsp.vcpu_id]);
> >
> > -    /* Unpause any domains that were paused because the ring was full or
> > no listener
> > -     * was available */
> > -    mem_event_unpause_vcpus(d);
> > +    /* Wake vcpus waiting for room in the ring */
> > +    mem_event_wake_requesters(&d->mem_event->access);
> > +
> > +    /* Unpause all vcpus that were paused because no listener was
> > available */
> > +    mem_event_wake_waiters(d, &d->mem_event->access);
> Is this not used in p2m_mem_paging_resume? Why the difference? Why are two
> mechanisms needed (wake_requesters, wake_sleepers)?

As said above, wake_sleepers is for those who wait for the ring itself,
and wake_requesters is for room in the ring.
p2m_mem_paging_resume() always has a ring, so it does not need to call
wake_sleepers.


Do you have a suggestion for a better name?

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 16:21:42 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 16: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.xensource.com>)
	id 1RXbID-0002ga-P8; Mon, 05 Dec 2011 16:21:25 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RXbIC-0002fm-1j
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 16:21:24 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-16.tower-174.messagelabs.com!1323102038!4151071!1
X-Originating-IP: [208.97.132.145]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNDUgPT4gMTczMTg=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24369 invoked from network); 5 Dec 2011 16:20:38 -0000
Received: from caiajhbdcbef.dreamhost.com (HELO homiemail-a76.g.dreamhost.com)
	(208.97.132.145) by server-16.tower-174.messagelabs.com with SMTP;
	5 Dec 2011 16:20:38 -0000
Received: from homiemail-a76.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTP id 01C3945807C;
	Mon,  5 Dec 2011 08:20:38 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=TKnUsaEOhqK8nc8NCzJZggNV5mfB3/nMZ24uopxQho7Z
	Kg+u1Z83RH4joVI9pBCXVHDYeGXpwWzk2A09j0fUgCvsQGk8tSVZOSSKWk7l7KP7
	psUmxu62utnhzSzisR8Lsushzry9mxYUyVpMCoZTQOKmBQO36HV49I4K8SUnm+Q=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=haei4sVpePVoLtNXkwnYQ/qSwbc=; b=XKuOOufp
	HWAsKxaJOjXLUFudRd04dvvflpSw+sPscUtJwwFAvSrKpn1/4149UKOBzAiSe3Zk
	U5dfzLPhW+IEDdud7eA4EQsfgB9y9u7XBS0T/xoTReZ/tUhzeaQg6WO64LGy+kil
	diJr1zD8W9yBEfrbatOk+f6AAll5sZpcnOY=
Received: from webmail.lagarcavilla.org (ahfbbjcaiaae.dreamhost.com
	[75.119.208.4]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTPA id 9D4B045807B; 
	Mon,  5 Dec 2011 08:20:37 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP; Mon, 5 Dec 2011 08:20:37 -0800
Message-ID: <919029815d192d72dbd13796573e3ba8.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20111205160112.GB93116@ocelot.phlegethon.org>
References: <patchbomb.1323097919@xdev.gridcentric.ca>
	<790cd814bee86c717fe4.1323097924@xdev.gridcentric.ca>
	<20111205160112.GB93116@ocelot.phlegethon.org>
Date: Mon, 5 Dec 2011 08:20:37 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Tim Deegan" <tim@xen.org>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com, olaf@aepfle.de,
	keir.xen@gmail.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 5 of 5] Ignore memory events with an
 obviously invalid gfn
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> At 10:12 -0500 on 05 Dec (1323079924), Andres Lagar-Cavilla wrote:
>>  xen/arch/x86/mm/mem_sharing.c  |  2 ++
>>  xen/arch/x86/mm/p2m.c          |  4 ++++
>>  xen/include/public/mem_event.h |  7 +++++++
>>  3 files changed, 13 insertions(+), 0 deletions(-)
>>
>>
>> Ring semantics require that for every request, a response be put. This
>> allows consumer to place a dummy response if need be.
>>
>> diff -r c71f4c5b42f0 -r 790cd814bee8 xen/include/public/mem_event.h
>> --- a/xen/include/public/mem_event.h
>> +++ b/xen/include/public/mem_event.h
>> @@ -76,6 +76,13 @@ typedef struct mem_event_st {
>>
>>  DEFINE_RING_TYPES(mem_event, mem_event_request_t,
>> mem_event_response_t);
>>
>> +#define INVALID_RSP_GFN -1UL
>> +
>
> On a 32-bit system this doesn't do what you want.
>
> Actually, can you use a flag for this, please?  Wedging it into the gfn
> field seems a bit of a hack, and we have plenty of flag bits left.
>
> Tim.

Good point, here it is:

# HG changeset patch
# Parent c71f4c5b42f0c7cc04e4ae758c8ab775305f2c6a
Ignore memory events with an obviously invalid gfn.

Ring semantics require that for every request, a response be put. This
allows consumer to place a dummy response if need be.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r c71f4c5b42f0 xen/arch/x86/mm/mem_sharing.c
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -303,6 +303,8 @@ int mem_sharing_sharing_resume(struct do
     /* Get all requests off the ring */
     while ( mem_event_get_response(&d->mem_event->share, &rsp) )
     {
+        if ( DUMMY_MEM_EVENT_RSP(&rsp) )
+            continue;
         /* Unpause domain/vcpu */
         if ( rsp.flags & MEM_EVENT_FLAG_VCPU_PAUSED )
             vcpu_unpause(d->vcpu[rsp.vcpu_id]);
diff -r c71f4c5b42f0 xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -1069,6 +1069,8 @@ void p2m_mem_paging_resume(struct domain
     /* Pull all responses off the ring */
     while( mem_event_get_response(&d->mem_event->paging, &rsp) )
     {
+        if ( DUMMY_MEM_EVENT_RSP(&rsp) )
+            continue;
         /* Fix p2m entry if the page was not dropped */
         if ( !(rsp.flags & MEM_EVENT_FLAG_DROP_PAGE) )
         {
@@ -1177,6 +1179,8 @@ void p2m_mem_access_resume(struct domain
     /* Pull all responses off the ring */
     while( mem_event_get_response(&d->mem_event->access, &rsp) )
     {
+        if ( DUMMY_MEM_EVENT_RSP(&rsp) )
+            continue;
         /* Unpause domain */
         if ( rsp.flags & MEM_EVENT_FLAG_VCPU_PAUSED )
             vcpu_unpause(d->vcpu[rsp.vcpu_id]);
diff -r c71f4c5b42f0 xen/include/public/mem_event.h
--- a/xen/include/public/mem_event.h
+++ b/xen/include/public/mem_event.h
@@ -40,6 +40,7 @@
 #define MEM_EVENT_FLAG_DROP_PAGE    (1 << 1)
 #define MEM_EVENT_FLAG_EVICT_FAIL   (1 << 2)
 #define MEM_EVENT_FLAG_FOREIGN      (1 << 3)
+#define MEM_EVENT_FLAG_DUMMY        (1 << 4)

 /* Reasons for the memory event request */
 #define MEM_EVENT_REASON_UNKNOWN     0    /* typical reason */
@@ -76,6 +77,13 @@ typedef struct mem_event_st {

 DEFINE_RING_TYPES(mem_event, mem_event_request_t, mem_event_response_t);

+#define DUMMY_MEM_EVENT_RSP(_r)             \
+        ((_r)->flags & MEM_EVENT_FLAG_DUMMY)
+#define MAKE_MEM_EVENT_RSP_DUMMY(_r)        \
+        ((_r)->flags |= MEM_EVENT_FLAG_DUMMY)
+#define DECLARE_DUMMY_MEM_EVENT_RSP(_name)  \
+    mem_event_response_t _name = { .flags = MEM_EVENT_FLAG_DUMMY }
+
 #endif

 /*



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 16:21:42 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 16: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.xensource.com>)
	id 1RXbID-0002ga-P8; Mon, 05 Dec 2011 16:21:25 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RXbIC-0002fm-1j
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 16:21:24 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-16.tower-174.messagelabs.com!1323102038!4151071!1
X-Originating-IP: [208.97.132.145]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNDUgPT4gMTczMTg=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24369 invoked from network); 5 Dec 2011 16:20:38 -0000
Received: from caiajhbdcbef.dreamhost.com (HELO homiemail-a76.g.dreamhost.com)
	(208.97.132.145) by server-16.tower-174.messagelabs.com with SMTP;
	5 Dec 2011 16:20:38 -0000
Received: from homiemail-a76.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTP id 01C3945807C;
	Mon,  5 Dec 2011 08:20:38 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=TKnUsaEOhqK8nc8NCzJZggNV5mfB3/nMZ24uopxQho7Z
	Kg+u1Z83RH4joVI9pBCXVHDYeGXpwWzk2A09j0fUgCvsQGk8tSVZOSSKWk7l7KP7
	psUmxu62utnhzSzisR8Lsushzry9mxYUyVpMCoZTQOKmBQO36HV49I4K8SUnm+Q=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=haei4sVpePVoLtNXkwnYQ/qSwbc=; b=XKuOOufp
	HWAsKxaJOjXLUFudRd04dvvflpSw+sPscUtJwwFAvSrKpn1/4149UKOBzAiSe3Zk
	U5dfzLPhW+IEDdud7eA4EQsfgB9y9u7XBS0T/xoTReZ/tUhzeaQg6WO64LGy+kil
	diJr1zD8W9yBEfrbatOk+f6AAll5sZpcnOY=
Received: from webmail.lagarcavilla.org (ahfbbjcaiaae.dreamhost.com
	[75.119.208.4]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTPA id 9D4B045807B; 
	Mon,  5 Dec 2011 08:20:37 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP; Mon, 5 Dec 2011 08:20:37 -0800
Message-ID: <919029815d192d72dbd13796573e3ba8.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20111205160112.GB93116@ocelot.phlegethon.org>
References: <patchbomb.1323097919@xdev.gridcentric.ca>
	<790cd814bee86c717fe4.1323097924@xdev.gridcentric.ca>
	<20111205160112.GB93116@ocelot.phlegethon.org>
Date: Mon, 5 Dec 2011 08:20:37 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Tim Deegan" <tim@xen.org>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com, olaf@aepfle.de,
	keir.xen@gmail.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 5 of 5] Ignore memory events with an
 obviously invalid gfn
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> At 10:12 -0500 on 05 Dec (1323079924), Andres Lagar-Cavilla wrote:
>>  xen/arch/x86/mm/mem_sharing.c  |  2 ++
>>  xen/arch/x86/mm/p2m.c          |  4 ++++
>>  xen/include/public/mem_event.h |  7 +++++++
>>  3 files changed, 13 insertions(+), 0 deletions(-)
>>
>>
>> Ring semantics require that for every request, a response be put. This
>> allows consumer to place a dummy response if need be.
>>
>> diff -r c71f4c5b42f0 -r 790cd814bee8 xen/include/public/mem_event.h
>> --- a/xen/include/public/mem_event.h
>> +++ b/xen/include/public/mem_event.h
>> @@ -76,6 +76,13 @@ typedef struct mem_event_st {
>>
>>  DEFINE_RING_TYPES(mem_event, mem_event_request_t,
>> mem_event_response_t);
>>
>> +#define INVALID_RSP_GFN -1UL
>> +
>
> On a 32-bit system this doesn't do what you want.
>
> Actually, can you use a flag for this, please?  Wedging it into the gfn
> field seems a bit of a hack, and we have plenty of flag bits left.
>
> Tim.

Good point, here it is:

# HG changeset patch
# Parent c71f4c5b42f0c7cc04e4ae758c8ab775305f2c6a
Ignore memory events with an obviously invalid gfn.

Ring semantics require that for every request, a response be put. This
allows consumer to place a dummy response if need be.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r c71f4c5b42f0 xen/arch/x86/mm/mem_sharing.c
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -303,6 +303,8 @@ int mem_sharing_sharing_resume(struct do
     /* Get all requests off the ring */
     while ( mem_event_get_response(&d->mem_event->share, &rsp) )
     {
+        if ( DUMMY_MEM_EVENT_RSP(&rsp) )
+            continue;
         /* Unpause domain/vcpu */
         if ( rsp.flags & MEM_EVENT_FLAG_VCPU_PAUSED )
             vcpu_unpause(d->vcpu[rsp.vcpu_id]);
diff -r c71f4c5b42f0 xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -1069,6 +1069,8 @@ void p2m_mem_paging_resume(struct domain
     /* Pull all responses off the ring */
     while( mem_event_get_response(&d->mem_event->paging, &rsp) )
     {
+        if ( DUMMY_MEM_EVENT_RSP(&rsp) )
+            continue;
         /* Fix p2m entry if the page was not dropped */
         if ( !(rsp.flags & MEM_EVENT_FLAG_DROP_PAGE) )
         {
@@ -1177,6 +1179,8 @@ void p2m_mem_access_resume(struct domain
     /* Pull all responses off the ring */
     while( mem_event_get_response(&d->mem_event->access, &rsp) )
     {
+        if ( DUMMY_MEM_EVENT_RSP(&rsp) )
+            continue;
         /* Unpause domain */
         if ( rsp.flags & MEM_EVENT_FLAG_VCPU_PAUSED )
             vcpu_unpause(d->vcpu[rsp.vcpu_id]);
diff -r c71f4c5b42f0 xen/include/public/mem_event.h
--- a/xen/include/public/mem_event.h
+++ b/xen/include/public/mem_event.h
@@ -40,6 +40,7 @@
 #define MEM_EVENT_FLAG_DROP_PAGE    (1 << 1)
 #define MEM_EVENT_FLAG_EVICT_FAIL   (1 << 2)
 #define MEM_EVENT_FLAG_FOREIGN      (1 << 3)
+#define MEM_EVENT_FLAG_DUMMY        (1 << 4)

 /* Reasons for the memory event request */
 #define MEM_EVENT_REASON_UNKNOWN     0    /* typical reason */
@@ -76,6 +77,13 @@ typedef struct mem_event_st {

 DEFINE_RING_TYPES(mem_event, mem_event_request_t, mem_event_response_t);

+#define DUMMY_MEM_EVENT_RSP(_r)             \
+        ((_r)->flags & MEM_EVENT_FLAG_DUMMY)
+#define MAKE_MEM_EVENT_RSP_DUMMY(_r)        \
+        ((_r)->flags |= MEM_EVENT_FLAG_DUMMY)
+#define DECLARE_DUMMY_MEM_EVENT_RSP(_name)  \
+    mem_event_response_t _name = { .flags = MEM_EVENT_FLAG_DUMMY }
+
 #endif

 /*



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 16:31:59 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 16:31:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXbS4-0003Gc-TS; Mon, 05 Dec 2011 16:31:36 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RXbS3-0003GR-4P
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 16:31:35 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1323102637!48306455!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4OTE=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25013 invoked from network); 5 Dec 2011 16:30:37 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-11.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 5 Dec 2011 16:30:37 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 05 Dec 2011 16:30:54 +0000
Message-Id: <4EDCFFF702000078000657EF@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 05 Dec 2011 16:31:35 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartFCD363F7.0__="
Subject: [Xen-devel] [PATCH] linux-2.6.18: kexec adjustments
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__PartFCD363F7.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

- fix error path after retrieving vmcoreinfo (must no directly return,
  special casing -EINVAL should only happen if absolutely needed)
- improve detection of number of CPUs (utilize platform hypercall)
- clean up in error path as far as possible (only after possibly having
  inserted some or all resources it would be problematic to free the
  allocated space)
- leverage the fact that alloc_bootmem() already clears the memory

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/drivers/xen/core/machine_kexec.c
+++ b/drivers/xen/core/machine_kexec.c
@@ -5,6 +5,7 @@
=20
 #include <linux/kexec.h>
 #include <xen/interface/kexec.h>
+#include <xen/interface/platform.h>
 #include <linux/mm.h>
 #include <linux/bootmem.h>
=20
@@ -17,7 +18,7 @@ extern void machine_kexec_register_resou
=20
 static int __initdata xen_max_nr_phys_cpus;
 static struct resource xen_hypervisor_res;
-static struct resource *xen_phys_cpus;
+static struct resource *__initdata xen_phys_cpus;
=20
 size_t vmcoreinfo_size_xen;
 unsigned long paddr_vmcoreinfo_xen;
@@ -25,16 +26,21 @@ unsigned long paddr_vmcoreinfo_xen;
 void __init xen_machine_kexec_setup_resources(void)
 {
 	xen_kexec_range_t range;
+	xen_platform_op_t op;
 	struct resource *res;
-	int k =3D 0;
+	unsigned int k =3D 0, nr =3D 0;
 	int rc;
=20
 	if (!is_initial_xendomain())
 		return;
=20
 	/* determine maximum number of physical cpus */
-
-	while (1) {
+	op.cmd =3D XENPF_get_cpuinfo;
+	op.u.pcpu_info.xen_cpuid =3D 0;
+	if (HYPERVISOR_platform_op(&op) =3D=3D 0)
+		k =3D op.u.pcpu_info.max_present + 1;
+#if CONFIG_XEN_COMPAT < 0x040000
+	else while (1) {
 		memset(&range, 0, sizeof(range));
 		range.range =3D KEXEC_RANGE_MA_CPU;
 		range.nr =3D k;
@@ -44,6 +50,7 @@ void __init xen_machine_kexec_setup_reso
=20
 		k++;
 	}
+#endif
=20
 	if (k =3D=3D 0)
 		return;
@@ -62,25 +69,27 @@ void __init xen_machine_kexec_setup_reso
 		range.range =3D KEXEC_RANGE_MA_CPU;
 		range.nr =3D k;
=20
-		if (HYPERVISOR_kexec_op(KEXEC_CMD_kexec_get_range, =
&range))
-			goto err;
-
-		res =3D xen_phys_cpus + k;
+		if (HYPERVISOR_kexec_op(KEXEC_CMD_kexec_get_range, &range)
+		    || range.size =3D=3D 0)
+			continue;
=20
-		memset(res, 0, sizeof(*res));
+		res =3D xen_phys_cpus + nr++;
 		res->name =3D "Crash note";
 		res->start =3D range.start;
 		res->end =3D range.start + range.size - 1;
 		res->flags =3D IORESOURCE_BUSY | IORESOURCE_MEM;
 	}
=20
+	if (nr =3D=3D 0)
+		goto free;
+
 	/* fill in xen_hypervisor_res with hypervisor machine address =
range */
=20
 	memset(&range, 0, sizeof(range));
 	range.range =3D KEXEC_RANGE_MA_XEN;
=20
 	if (HYPERVISOR_kexec_op(KEXEC_CMD_kexec_get_range, &range))
-		goto err;
+		goto free;
=20
 	xen_hypervisor_res.name =3D "Hypervisor code and data";
 	xen_hypervisor_res.start =3D range.start;
@@ -93,7 +102,7 @@ void __init xen_machine_kexec_setup_reso
 	range.range =3D KEXEC_RANGE_MA_CRASH;
=20
 	if (HYPERVISOR_kexec_op(KEXEC_CMD_kexec_get_range, &range))
-		goto err;
+		goto free;
=20
 	if (range.size) {
 		crashk_res.start =3D range.start;
@@ -118,28 +127,35 @@ void __init xen_machine_kexec_setup_reso
 		vmcoreinfo_size_xen =3D 0;
 		paddr_vmcoreinfo_xen =3D 0;
 	=09
+#if CONFIG_XEN_COMPAT < 0x030300
 		/* The KEXEC_CMD_kexec_get_range hypercall did not =
implement
 		 * KEXEC_RANGE_MA_VMCOREINFO until Xen 3.3.
 		 * Do not bail out if it fails for this reason.
 		 */
 		if (rc !=3D -EINVAL)
-			return;
+#endif
+			goto free;
 	}
=20
 	if (machine_kexec_setup_resources(&xen_hypervisor_res, xen_phys_cpu=
s,
-					  xen_max_nr_phys_cpus))
+					  nr)) {
+		/*
+		 * It's too cumbersome to properly free xen_phys_cpus =
here.
+		 * Failure at this stage is unexpected and the amount of
+		 * memory is small therefore we tolerate the potential =
leak.
+		 */
 		goto err;
+	}
+
+	xen_max_nr_phys_cpus =3D nr;
=20
 	return;
=20
+ free:
+	free_bootmem(__pa(xen_phys_cpus),
+		     xen_max_nr_phys_cpus * sizeof(*xen_phys_cpus));
  err:
-	/*
-	 * It isn't possible to free xen_phys_cpus this early in the
-	 * boot. Failure at this stage is unexpected and the amount of
-	 * memory is small therefore we tolerate the potential leak.
-         */
 	xen_max_nr_phys_cpus =3D 0;
-	return;
 }
=20
 void __init xen_machine_kexec_register_resources(struct resource *res)



--=__PartFCD363F7.0__=
Content-Type: text/plain; name="xen-kexec-cleanup.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="xen-kexec-cleanup.patch"

kexec adjustments=0A=0A- fix error path after retrieving vmcoreinfo (must =
no directly return,=0A  special casing -EINVAL should only happen if =
absolutely needed)=0A- improve detection of number of CPUs (utilize =
platform hypercall)=0A- clean up in error path as far as possible (only =
after possibly having=0A  inserted some or all resources it would be =
problematic to free the=0A  allocated space)=0A- leverage the fact that =
alloc_bootmem() already clears the memory=0A=0ASigned-off-by: Jan Beulich =
<jbeulich@suse.com>=0A=0A--- a/drivers/xen/core/machine_kexec.c=0A+++ =
b/drivers/xen/core/machine_kexec.c=0A@@ -5,6 +5,7 @@=0A =0A #include =
<linux/kexec.h>=0A #include <xen/interface/kexec.h>=0A+#include <xen/interf=
ace/platform.h>=0A #include <linux/mm.h>=0A #include <linux/bootmem.h>=0A =
=0A@@ -17,7 +18,7 @@ extern void machine_kexec_register_resou=0A =0A =
static int __initdata xen_max_nr_phys_cpus;=0A static struct resource =
xen_hypervisor_res;=0A-static struct resource *xen_phys_cpus;=0A+static =
struct resource *__initdata xen_phys_cpus;=0A =0A size_t vmcoreinfo_size_xe=
n;=0A unsigned long paddr_vmcoreinfo_xen;=0A@@ -25,16 +26,21 @@ unsigned =
long paddr_vmcoreinfo_xen;=0A void __init xen_machine_kexec_setup_resources=
(void)=0A {=0A 	xen_kexec_range_t range;=0A+	xen_platform_op_t op;=0A 	=
struct resource *res;=0A-	int k =3D 0;=0A+	unsigned int k =3D =
0, nr =3D 0;=0A 	int rc;=0A =0A 	if (!is_initial_xendomain())=0A 	=
	return;=0A =0A 	/* determine maximum number of physical cpus =
*/=0A-=0A-	while (1) {=0A+	op.cmd =3D XENPF_get_cpuinfo;=0A+	=
op.u.pcpu_info.xen_cpuid =3D 0;=0A+	if (HYPERVISOR_platform_op(&op) =
=3D=3D 0)=0A+		k =3D op.u.pcpu_info.max_present + 1;=0A+#if =
CONFIG_XEN_COMPAT < 0x040000=0A+	else while (1) {=0A 		=
memset(&range, 0, sizeof(range));=0A 		range.range =3D KEXEC_RANGE=
_MA_CPU;=0A 		range.nr =3D k;=0A@@ -44,6 +50,7 @@ void __init =
xen_machine_kexec_setup_reso=0A =0A 		k++;=0A 	}=0A+#endif=
=0A =0A 	if (k =3D=3D 0)=0A 		return;=0A@@ -62,25 +69,27 =
@@ void __init xen_machine_kexec_setup_reso=0A 		range.range =3D =
KEXEC_RANGE_MA_CPU;=0A 		range.nr =3D k;=0A =0A-		if =
(HYPERVISOR_kexec_op(KEXEC_CMD_kexec_get_range, &range))=0A-			=
goto err;=0A-=0A-		res =3D xen_phys_cpus + k;=0A+		if =
(HYPERVISOR_kexec_op(KEXEC_CMD_kexec_get_range, &range)=0A+		   =
 || range.size =3D=3D 0)=0A+			continue;=0A =0A-		=
memset(res, 0, sizeof(*res));=0A+		res =3D xen_phys_cpus + =
nr++;=0A 		res->name =3D "Crash note";=0A 		res->start =
=3D range.start;=0A 		res->end =3D range.start + range.size - =
1;=0A 		res->flags =3D IORESOURCE_BUSY | IORESOURCE_MEM;=0A 	=
}=0A =0A+	if (nr =3D=3D 0)=0A+		goto free;=0A+=0A 	/* =
fill in xen_hypervisor_res with hypervisor machine address range */=0A =0A =
	memset(&range, 0, sizeof(range));=0A 	range.range =3D KEXEC_RANGE=
_MA_XEN;=0A =0A 	if (HYPERVISOR_kexec_op(KEXEC_CMD_kexec_get_range, =
&range))=0A-		goto err;=0A+		goto free;=0A =0A 	=
xen_hypervisor_res.name =3D "Hypervisor code and data";=0A 	xen_hypervi=
sor_res.start =3D range.start;=0A@@ -93,7 +102,7 @@ void __init xen_machine=
_kexec_setup_reso=0A 	range.range =3D KEXEC_RANGE_MA_CRASH;=0A =0A 	if =
(HYPERVISOR_kexec_op(KEXEC_CMD_kexec_get_range, &range))=0A-		=
goto err;=0A+		goto free;=0A =0A 	if (range.size) {=0A 		=
crashk_res.start =3D range.start;=0A@@ -118,28 +127,35 @@ void __init =
xen_machine_kexec_setup_reso=0A 		vmcoreinfo_size_xen =3D =
0;=0A 		paddr_vmcoreinfo_xen =3D 0;=0A 		=0A+#if CONFIG_XEN_=
COMPAT < 0x030300=0A 		/* The KEXEC_CMD_kexec_get_range hypercall =
did not implement=0A 		 * KEXEC_RANGE_MA_VMCOREINFO until Xen =
3.3.=0A 		 * Do not bail out if it fails for this reason.=0A =
		 */=0A 		if (rc !=3D -EINVAL)=0A-			=
return;=0A+#endif=0A+			goto free;=0A 	}=0A =0A 	if =
(machine_kexec_setup_resources(&xen_hypervisor_res, xen_phys_cpus,=0A-		=
			  xen_max_nr_phys_cpus))=0A+				=
	  nr)) {=0A+		/*=0A+		 * It's too cumbersome to =
properly free xen_phys_cpus here.=0A+		 * Failure at this stage =
is unexpected and the amount of=0A+		 * memory is small =
therefore we tolerate the potential leak.=0A+		 */=0A 		=
goto err;=0A+	}=0A+=0A+	xen_max_nr_phys_cpus =3D nr;=0A =0A 	=
return;=0A =0A+ free:=0A+	free_bootmem(__pa(xen_phys_cpus),=0A+		=
     xen_max_nr_phys_cpus * sizeof(*xen_phys_cpus));=0A  err:=0A-	=
/*=0A-	 * It isn't possible to free xen_phys_cpus this early in the=0A-	=
 * boot. Failure at this stage is unexpected and the amount of=0A-	 * =
memory is small therefore we tolerate the potential leak.=0A-         =
*/=0A 	xen_max_nr_phys_cpus =3D 0;=0A-	return;=0A }=0A =0A void __init =
xen_machine_kexec_register_resources(struct resource *res)=0A
--=__PartFCD363F7.0__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--=__PartFCD363F7.0__=--


From xen-devel-bounces@lists.xensource.com Mon Dec 05 16:31:59 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 16:31:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXbS4-0003Gc-TS; Mon, 05 Dec 2011 16:31:36 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RXbS3-0003GR-4P
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 16:31:35 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1323102637!48306455!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4OTE=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25013 invoked from network); 5 Dec 2011 16:30:37 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-11.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 5 Dec 2011 16:30:37 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 05 Dec 2011 16:30:54 +0000
Message-Id: <4EDCFFF702000078000657EF@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 05 Dec 2011 16:31:35 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartFCD363F7.0__="
Subject: [Xen-devel] [PATCH] linux-2.6.18: kexec adjustments
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__PartFCD363F7.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

- fix error path after retrieving vmcoreinfo (must no directly return,
  special casing -EINVAL should only happen if absolutely needed)
- improve detection of number of CPUs (utilize platform hypercall)
- clean up in error path as far as possible (only after possibly having
  inserted some or all resources it would be problematic to free the
  allocated space)
- leverage the fact that alloc_bootmem() already clears the memory

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/drivers/xen/core/machine_kexec.c
+++ b/drivers/xen/core/machine_kexec.c
@@ -5,6 +5,7 @@
=20
 #include <linux/kexec.h>
 #include <xen/interface/kexec.h>
+#include <xen/interface/platform.h>
 #include <linux/mm.h>
 #include <linux/bootmem.h>
=20
@@ -17,7 +18,7 @@ extern void machine_kexec_register_resou
=20
 static int __initdata xen_max_nr_phys_cpus;
 static struct resource xen_hypervisor_res;
-static struct resource *xen_phys_cpus;
+static struct resource *__initdata xen_phys_cpus;
=20
 size_t vmcoreinfo_size_xen;
 unsigned long paddr_vmcoreinfo_xen;
@@ -25,16 +26,21 @@ unsigned long paddr_vmcoreinfo_xen;
 void __init xen_machine_kexec_setup_resources(void)
 {
 	xen_kexec_range_t range;
+	xen_platform_op_t op;
 	struct resource *res;
-	int k =3D 0;
+	unsigned int k =3D 0, nr =3D 0;
 	int rc;
=20
 	if (!is_initial_xendomain())
 		return;
=20
 	/* determine maximum number of physical cpus */
-
-	while (1) {
+	op.cmd =3D XENPF_get_cpuinfo;
+	op.u.pcpu_info.xen_cpuid =3D 0;
+	if (HYPERVISOR_platform_op(&op) =3D=3D 0)
+		k =3D op.u.pcpu_info.max_present + 1;
+#if CONFIG_XEN_COMPAT < 0x040000
+	else while (1) {
 		memset(&range, 0, sizeof(range));
 		range.range =3D KEXEC_RANGE_MA_CPU;
 		range.nr =3D k;
@@ -44,6 +50,7 @@ void __init xen_machine_kexec_setup_reso
=20
 		k++;
 	}
+#endif
=20
 	if (k =3D=3D 0)
 		return;
@@ -62,25 +69,27 @@ void __init xen_machine_kexec_setup_reso
 		range.range =3D KEXEC_RANGE_MA_CPU;
 		range.nr =3D k;
=20
-		if (HYPERVISOR_kexec_op(KEXEC_CMD_kexec_get_range, =
&range))
-			goto err;
-
-		res =3D xen_phys_cpus + k;
+		if (HYPERVISOR_kexec_op(KEXEC_CMD_kexec_get_range, &range)
+		    || range.size =3D=3D 0)
+			continue;
=20
-		memset(res, 0, sizeof(*res));
+		res =3D xen_phys_cpus + nr++;
 		res->name =3D "Crash note";
 		res->start =3D range.start;
 		res->end =3D range.start + range.size - 1;
 		res->flags =3D IORESOURCE_BUSY | IORESOURCE_MEM;
 	}
=20
+	if (nr =3D=3D 0)
+		goto free;
+
 	/* fill in xen_hypervisor_res with hypervisor machine address =
range */
=20
 	memset(&range, 0, sizeof(range));
 	range.range =3D KEXEC_RANGE_MA_XEN;
=20
 	if (HYPERVISOR_kexec_op(KEXEC_CMD_kexec_get_range, &range))
-		goto err;
+		goto free;
=20
 	xen_hypervisor_res.name =3D "Hypervisor code and data";
 	xen_hypervisor_res.start =3D range.start;
@@ -93,7 +102,7 @@ void __init xen_machine_kexec_setup_reso
 	range.range =3D KEXEC_RANGE_MA_CRASH;
=20
 	if (HYPERVISOR_kexec_op(KEXEC_CMD_kexec_get_range, &range))
-		goto err;
+		goto free;
=20
 	if (range.size) {
 		crashk_res.start =3D range.start;
@@ -118,28 +127,35 @@ void __init xen_machine_kexec_setup_reso
 		vmcoreinfo_size_xen =3D 0;
 		paddr_vmcoreinfo_xen =3D 0;
 	=09
+#if CONFIG_XEN_COMPAT < 0x030300
 		/* The KEXEC_CMD_kexec_get_range hypercall did not =
implement
 		 * KEXEC_RANGE_MA_VMCOREINFO until Xen 3.3.
 		 * Do not bail out if it fails for this reason.
 		 */
 		if (rc !=3D -EINVAL)
-			return;
+#endif
+			goto free;
 	}
=20
 	if (machine_kexec_setup_resources(&xen_hypervisor_res, xen_phys_cpu=
s,
-					  xen_max_nr_phys_cpus))
+					  nr)) {
+		/*
+		 * It's too cumbersome to properly free xen_phys_cpus =
here.
+		 * Failure at this stage is unexpected and the amount of
+		 * memory is small therefore we tolerate the potential =
leak.
+		 */
 		goto err;
+	}
+
+	xen_max_nr_phys_cpus =3D nr;
=20
 	return;
=20
+ free:
+	free_bootmem(__pa(xen_phys_cpus),
+		     xen_max_nr_phys_cpus * sizeof(*xen_phys_cpus));
  err:
-	/*
-	 * It isn't possible to free xen_phys_cpus this early in the
-	 * boot. Failure at this stage is unexpected and the amount of
-	 * memory is small therefore we tolerate the potential leak.
-         */
 	xen_max_nr_phys_cpus =3D 0;
-	return;
 }
=20
 void __init xen_machine_kexec_register_resources(struct resource *res)



--=__PartFCD363F7.0__=
Content-Type: text/plain; name="xen-kexec-cleanup.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="xen-kexec-cleanup.patch"

kexec adjustments=0A=0A- fix error path after retrieving vmcoreinfo (must =
no directly return,=0A  special casing -EINVAL should only happen if =
absolutely needed)=0A- improve detection of number of CPUs (utilize =
platform hypercall)=0A- clean up in error path as far as possible (only =
after possibly having=0A  inserted some or all resources it would be =
problematic to free the=0A  allocated space)=0A- leverage the fact that =
alloc_bootmem() already clears the memory=0A=0ASigned-off-by: Jan Beulich =
<jbeulich@suse.com>=0A=0A--- a/drivers/xen/core/machine_kexec.c=0A+++ =
b/drivers/xen/core/machine_kexec.c=0A@@ -5,6 +5,7 @@=0A =0A #include =
<linux/kexec.h>=0A #include <xen/interface/kexec.h>=0A+#include <xen/interf=
ace/platform.h>=0A #include <linux/mm.h>=0A #include <linux/bootmem.h>=0A =
=0A@@ -17,7 +18,7 @@ extern void machine_kexec_register_resou=0A =0A =
static int __initdata xen_max_nr_phys_cpus;=0A static struct resource =
xen_hypervisor_res;=0A-static struct resource *xen_phys_cpus;=0A+static =
struct resource *__initdata xen_phys_cpus;=0A =0A size_t vmcoreinfo_size_xe=
n;=0A unsigned long paddr_vmcoreinfo_xen;=0A@@ -25,16 +26,21 @@ unsigned =
long paddr_vmcoreinfo_xen;=0A void __init xen_machine_kexec_setup_resources=
(void)=0A {=0A 	xen_kexec_range_t range;=0A+	xen_platform_op_t op;=0A 	=
struct resource *res;=0A-	int k =3D 0;=0A+	unsigned int k =3D =
0, nr =3D 0;=0A 	int rc;=0A =0A 	if (!is_initial_xendomain())=0A 	=
	return;=0A =0A 	/* determine maximum number of physical cpus =
*/=0A-=0A-	while (1) {=0A+	op.cmd =3D XENPF_get_cpuinfo;=0A+	=
op.u.pcpu_info.xen_cpuid =3D 0;=0A+	if (HYPERVISOR_platform_op(&op) =
=3D=3D 0)=0A+		k =3D op.u.pcpu_info.max_present + 1;=0A+#if =
CONFIG_XEN_COMPAT < 0x040000=0A+	else while (1) {=0A 		=
memset(&range, 0, sizeof(range));=0A 		range.range =3D KEXEC_RANGE=
_MA_CPU;=0A 		range.nr =3D k;=0A@@ -44,6 +50,7 @@ void __init =
xen_machine_kexec_setup_reso=0A =0A 		k++;=0A 	}=0A+#endif=
=0A =0A 	if (k =3D=3D 0)=0A 		return;=0A@@ -62,25 +69,27 =
@@ void __init xen_machine_kexec_setup_reso=0A 		range.range =3D =
KEXEC_RANGE_MA_CPU;=0A 		range.nr =3D k;=0A =0A-		if =
(HYPERVISOR_kexec_op(KEXEC_CMD_kexec_get_range, &range))=0A-			=
goto err;=0A-=0A-		res =3D xen_phys_cpus + k;=0A+		if =
(HYPERVISOR_kexec_op(KEXEC_CMD_kexec_get_range, &range)=0A+		   =
 || range.size =3D=3D 0)=0A+			continue;=0A =0A-		=
memset(res, 0, sizeof(*res));=0A+		res =3D xen_phys_cpus + =
nr++;=0A 		res->name =3D "Crash note";=0A 		res->start =
=3D range.start;=0A 		res->end =3D range.start + range.size - =
1;=0A 		res->flags =3D IORESOURCE_BUSY | IORESOURCE_MEM;=0A 	=
}=0A =0A+	if (nr =3D=3D 0)=0A+		goto free;=0A+=0A 	/* =
fill in xen_hypervisor_res with hypervisor machine address range */=0A =0A =
	memset(&range, 0, sizeof(range));=0A 	range.range =3D KEXEC_RANGE=
_MA_XEN;=0A =0A 	if (HYPERVISOR_kexec_op(KEXEC_CMD_kexec_get_range, =
&range))=0A-		goto err;=0A+		goto free;=0A =0A 	=
xen_hypervisor_res.name =3D "Hypervisor code and data";=0A 	xen_hypervi=
sor_res.start =3D range.start;=0A@@ -93,7 +102,7 @@ void __init xen_machine=
_kexec_setup_reso=0A 	range.range =3D KEXEC_RANGE_MA_CRASH;=0A =0A 	if =
(HYPERVISOR_kexec_op(KEXEC_CMD_kexec_get_range, &range))=0A-		=
goto err;=0A+		goto free;=0A =0A 	if (range.size) {=0A 		=
crashk_res.start =3D range.start;=0A@@ -118,28 +127,35 @@ void __init =
xen_machine_kexec_setup_reso=0A 		vmcoreinfo_size_xen =3D =
0;=0A 		paddr_vmcoreinfo_xen =3D 0;=0A 		=0A+#if CONFIG_XEN_=
COMPAT < 0x030300=0A 		/* The KEXEC_CMD_kexec_get_range hypercall =
did not implement=0A 		 * KEXEC_RANGE_MA_VMCOREINFO until Xen =
3.3.=0A 		 * Do not bail out if it fails for this reason.=0A =
		 */=0A 		if (rc !=3D -EINVAL)=0A-			=
return;=0A+#endif=0A+			goto free;=0A 	}=0A =0A 	if =
(machine_kexec_setup_resources(&xen_hypervisor_res, xen_phys_cpus,=0A-		=
			  xen_max_nr_phys_cpus))=0A+				=
	  nr)) {=0A+		/*=0A+		 * It's too cumbersome to =
properly free xen_phys_cpus here.=0A+		 * Failure at this stage =
is unexpected and the amount of=0A+		 * memory is small =
therefore we tolerate the potential leak.=0A+		 */=0A 		=
goto err;=0A+	}=0A+=0A+	xen_max_nr_phys_cpus =3D nr;=0A =0A 	=
return;=0A =0A+ free:=0A+	free_bootmem(__pa(xen_phys_cpus),=0A+		=
     xen_max_nr_phys_cpus * sizeof(*xen_phys_cpus));=0A  err:=0A-	=
/*=0A-	 * It isn't possible to free xen_phys_cpus this early in the=0A-	=
 * boot. Failure at this stage is unexpected and the amount of=0A-	 * =
memory is small therefore we tolerate the potential leak.=0A-         =
*/=0A 	xen_max_nr_phys_cpus =3D 0;=0A-	return;=0A }=0A =0A void __init =
xen_machine_kexec_register_resources(struct resource *res)=0A
--=__PartFCD363F7.0__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--=__PartFCD363F7.0__=--


From xen-devel-bounces@lists.xensource.com Mon Dec 05 16:35:21 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 16:35:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXbVS-0003d3-Fr; Mon, 05 Dec 2011 16:35:06 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RXbVR-0003cZ-7a
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 16:35:05 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-4.tower-182.messagelabs.com!1323102860!5969843!1
X-Originating-IP: [208.97.132.119]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xMTkgPT4gMTU4ODE=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3880 invoked from network); 5 Dec 2011 16:34:20 -0000
Received: from caiajhbdcbbj.dreamhost.com (HELO homiemail-a15.g.dreamhost.com)
	(208.97.132.119) by server-4.tower-182.messagelabs.com with SMTP;
	5 Dec 2011 16:34:20 -0000
Received: from homiemail-a15.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a15.g.dreamhost.com (Postfix) with ESMTP id C620076C07D;
	Mon,  5 Dec 2011 08:34:19 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=lMMcaWsHbAqaZS+DBG8nTOteC3HGoCYd0RXMtp1TSvdE
	4JzIpYcl5JTZR8VDljBHNoD9UIqPcAKeNWN0O16Qa/7EfbGXYyZrcMaIQzrrUxHM
	pktI/zjF9KUKo03vmwH2T0lRUC89DwzMft3Gcqr8gDQZuFyKByr+1aZRHK0q0ck=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=Xl8eXh95CzuUBkGoysQ6HUw0CHM=; b=EKL+SLvx
	5K9yH2biCNqxWSe953arx9TaP4vn77od+LNxI/KjLwflmz5UGL/56KCVkMeQjtQv
	yUMp0e3YWvHO3RBz+Pk1/LJNxAr74bD34K5HBxfiidw+iWiYAGJh7fp9uUST/fhm
	hTqOnnnqLh3RAJp4GqEAdWXyS1+qRxcvp38=
Received: from webmail.lagarcavilla.org (ahfbbjcaiaae.dreamhost.com
	[75.119.208.4]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a15.g.dreamhost.com (Postfix) with ESMTPA id 8B0AF76C069; 
	Mon,  5 Dec 2011 08:34:19 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP; Mon, 5 Dec 2011 08:34:19 -0800
Message-ID: <c9d4c394e8c6806edd1b735a43d60ab7.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20111205162016.GA13352@aepfle.de>
References: <mailman.3332.1323083995.12970.xen-devel@lists.xensource.com>
	<f5cf6ad4704fe70f3130b832e530e8b0.squirrel@webmail.lagarcavilla.org>
	<20111205162016.GA13352@aepfle.de>
Date: Mon, 5 Dec 2011 08:34:19 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Olaf Hering" <olaf@aepfle.de>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] mem_event: use wait queue when ring is full
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> On Mon, Dec 05, Andres Lagar-Cavilla wrote:
>
>> > +    med->bit = bit;
>> I think it's been asked before for this to have a more expressive name.
>
> I have to recheck, AFAIK it was the mem_bit where mem_ is redundant.
how about pause_flag?

>
>> >  static int mem_event_disable(struct mem_event_domain *med)
>> >  {
>> > +    if (!list_empty(&med->wq.list))
>> > +        return -EBUSY;
>> > +
>> What does the caller do with EBUSY? Retry?
>
> Yes, and mail the devs at xen-devel that something isn't right ;-)
Heh, good one :)

>
> At least the pager uses this just in the exit path. I dont know about
> access and sharing, wether these tools enable/disable more than once at
> guest runtime.
>
>> > @@ -287,7 +394,7 @@ int mem_event_domctl(struct domain *d, x
>> >              if ( p2m->pod.entry_count )
>> >                  break;
>> >
>> > -            rc = mem_event_enable(d, mec, med);
>> > +            rc = mem_event_enable(d, mec, _VPF_mem_paging, med);
>> >          }
>> >          break;
>> >
>> > @@ -326,7 +433,7 @@ int mem_event_domctl(struct domain *d, x
>> >              if ( boot_cpu_data.x86_vendor != X86_VENDOR_INTEL )
>> >                  break;
>> >
>> > -            rc = mem_event_enable(d, mec, med);
>> > +            rc = mem_event_enable(d, mec, _VPF_mem_access, med);
>
>> Ok, the idea of bit is that different vcpus will sleep with different
>> pause flags, depending on the ring they're sleeping on. But this is only
>> used in wake_waiters, which is not used by all rings. In fact, why do we
>> need wake_waiters with wait queues?
>
> Before this patch, mem_event_unpause_vcpus() was used to resume waiters
> for the ring itself and for room in the ring.
> Now there is mem_event_wake_waiters(), which indicates the ring is
> active, and there is mem_event_wake_requesters() which indicates the
> ring has room to place guest requests.

I think that if there is no ring where one is expected, harsher actions
should happen. That is what we do in our patch. e.g.
p2m_mem_paging_populate -> no ring -> crash domain, or
p2m_mem_access_check -> access_required -> no ring -> crash domain.

That would eliminate wake_waiters, methinks?

>
> I agree that only _VPF_mem_access is really needed, and _VPF_mem_paging
> could be removed because paging without having a ring first is not
> possible.
>
>
>> > @@ -653,7 +643,7 @@ gfn_found:
>> >      if(ret == 0) goto private_page_found;
>> >
>> >      old_page = page;
>> > -    page = mem_sharing_alloc_page(d, gfn);
>> > +    page = alloc_domheap_page(d, 0);
>> >      if(!page)
>> >      {
>> >          /* We've failed to obtain memory for private page. Need to
>> re-add
>> > the
>> > @@ -661,6 +651,7 @@ gfn_found:
>> >          list_add(&gfn_info->list, &hash_entry->gfns);
>> >          put_gfn(d, gfn);
>> >          shr_unlock();
>> > +        mem_sharing_notify_helper(d, gfn);
>> This is nice. Do you think PoD could use this, should it ever run into a
>> ENOMEM situation? And what about mem_paging_prep? Perhaps, rather than a
>> sharing ring (which is bit rotted) we could have an ENOMEM ring with a
>> utility launched by xencommons listening. The problem, again, is what if
>> ENOMEM is itself caused by dom0 (e.g. writable mapping of a shared page)
>
> I have no idea about mem_sharing. I just move the existing code outside
> the lock so that mem_event_put_request() is (hopefully) called without
> any locks from mem_sharing_get_nr_saved_mfns().
> Since there is appearently no user of a sharing ring, this whole new
> mem_sharing_notify_helper() is a big no-op.
Fair enough. I do think that generally, for x86/mm, an ENOMEM mem_event
ring is a good idea. Later...

>
>> > @@ -1167,9 +1159,11 @@ void p2m_mem_access_resume(struct domain
>> >      if ( rsp.flags & MEM_EVENT_FLAG_VCPU_PAUSED )
>> >          vcpu_unpause(d->vcpu[rsp.vcpu_id]);
>> >
>> > -    /* Unpause any domains that were paused because the ring was full
>> or
>> > no listener
>> > -     * was available */
>> > -    mem_event_unpause_vcpus(d);
>> > +    /* Wake vcpus waiting for room in the ring */
>> > +    mem_event_wake_requesters(&d->mem_event->access);
>> > +
>> > +    /* Unpause all vcpus that were paused because no listener was
>> > available */
>> > +    mem_event_wake_waiters(d, &d->mem_event->access);
>> Is this not used in p2m_mem_paging_resume? Why the difference? Why are
>> two
>> mechanisms needed (wake_requesters, wake_sleepers)?
>
> As said above, wake_sleepers is for those who wait for the ring itself,
> and wake_requesters is for room in the ring.
> p2m_mem_paging_resume() always has a ring, so it does not need to call
> wake_sleepers.
>
>
> Do you have a suggestion for a better name?
>
> Olaf
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 16:35:21 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 16:35:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXbVS-0003d3-Fr; Mon, 05 Dec 2011 16:35:06 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RXbVR-0003cZ-7a
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 16:35:05 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-4.tower-182.messagelabs.com!1323102860!5969843!1
X-Originating-IP: [208.97.132.119]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xMTkgPT4gMTU4ODE=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3880 invoked from network); 5 Dec 2011 16:34:20 -0000
Received: from caiajhbdcbbj.dreamhost.com (HELO homiemail-a15.g.dreamhost.com)
	(208.97.132.119) by server-4.tower-182.messagelabs.com with SMTP;
	5 Dec 2011 16:34:20 -0000
Received: from homiemail-a15.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a15.g.dreamhost.com (Postfix) with ESMTP id C620076C07D;
	Mon,  5 Dec 2011 08:34:19 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=lMMcaWsHbAqaZS+DBG8nTOteC3HGoCYd0RXMtp1TSvdE
	4JzIpYcl5JTZR8VDljBHNoD9UIqPcAKeNWN0O16Qa/7EfbGXYyZrcMaIQzrrUxHM
	pktI/zjF9KUKo03vmwH2T0lRUC89DwzMft3Gcqr8gDQZuFyKByr+1aZRHK0q0ck=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=Xl8eXh95CzuUBkGoysQ6HUw0CHM=; b=EKL+SLvx
	5K9yH2biCNqxWSe953arx9TaP4vn77od+LNxI/KjLwflmz5UGL/56KCVkMeQjtQv
	yUMp0e3YWvHO3RBz+Pk1/LJNxAr74bD34K5HBxfiidw+iWiYAGJh7fp9uUST/fhm
	hTqOnnnqLh3RAJp4GqEAdWXyS1+qRxcvp38=
Received: from webmail.lagarcavilla.org (ahfbbjcaiaae.dreamhost.com
	[75.119.208.4]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a15.g.dreamhost.com (Postfix) with ESMTPA id 8B0AF76C069; 
	Mon,  5 Dec 2011 08:34:19 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP; Mon, 5 Dec 2011 08:34:19 -0800
Message-ID: <c9d4c394e8c6806edd1b735a43d60ab7.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20111205162016.GA13352@aepfle.de>
References: <mailman.3332.1323083995.12970.xen-devel@lists.xensource.com>
	<f5cf6ad4704fe70f3130b832e530e8b0.squirrel@webmail.lagarcavilla.org>
	<20111205162016.GA13352@aepfle.de>
Date: Mon, 5 Dec 2011 08:34:19 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Olaf Hering" <olaf@aepfle.de>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] mem_event: use wait queue when ring is full
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> On Mon, Dec 05, Andres Lagar-Cavilla wrote:
>
>> > +    med->bit = bit;
>> I think it's been asked before for this to have a more expressive name.
>
> I have to recheck, AFAIK it was the mem_bit where mem_ is redundant.
how about pause_flag?

>
>> >  static int mem_event_disable(struct mem_event_domain *med)
>> >  {
>> > +    if (!list_empty(&med->wq.list))
>> > +        return -EBUSY;
>> > +
>> What does the caller do with EBUSY? Retry?
>
> Yes, and mail the devs at xen-devel that something isn't right ;-)
Heh, good one :)

>
> At least the pager uses this just in the exit path. I dont know about
> access and sharing, wether these tools enable/disable more than once at
> guest runtime.
>
>> > @@ -287,7 +394,7 @@ int mem_event_domctl(struct domain *d, x
>> >              if ( p2m->pod.entry_count )
>> >                  break;
>> >
>> > -            rc = mem_event_enable(d, mec, med);
>> > +            rc = mem_event_enable(d, mec, _VPF_mem_paging, med);
>> >          }
>> >          break;
>> >
>> > @@ -326,7 +433,7 @@ int mem_event_domctl(struct domain *d, x
>> >              if ( boot_cpu_data.x86_vendor != X86_VENDOR_INTEL )
>> >                  break;
>> >
>> > -            rc = mem_event_enable(d, mec, med);
>> > +            rc = mem_event_enable(d, mec, _VPF_mem_access, med);
>
>> Ok, the idea of bit is that different vcpus will sleep with different
>> pause flags, depending on the ring they're sleeping on. But this is only
>> used in wake_waiters, which is not used by all rings. In fact, why do we
>> need wake_waiters with wait queues?
>
> Before this patch, mem_event_unpause_vcpus() was used to resume waiters
> for the ring itself and for room in the ring.
> Now there is mem_event_wake_waiters(), which indicates the ring is
> active, and there is mem_event_wake_requesters() which indicates the
> ring has room to place guest requests.

I think that if there is no ring where one is expected, harsher actions
should happen. That is what we do in our patch. e.g.
p2m_mem_paging_populate -> no ring -> crash domain, or
p2m_mem_access_check -> access_required -> no ring -> crash domain.

That would eliminate wake_waiters, methinks?

>
> I agree that only _VPF_mem_access is really needed, and _VPF_mem_paging
> could be removed because paging without having a ring first is not
> possible.
>
>
>> > @@ -653,7 +643,7 @@ gfn_found:
>> >      if(ret == 0) goto private_page_found;
>> >
>> >      old_page = page;
>> > -    page = mem_sharing_alloc_page(d, gfn);
>> > +    page = alloc_domheap_page(d, 0);
>> >      if(!page)
>> >      {
>> >          /* We've failed to obtain memory for private page. Need to
>> re-add
>> > the
>> > @@ -661,6 +651,7 @@ gfn_found:
>> >          list_add(&gfn_info->list, &hash_entry->gfns);
>> >          put_gfn(d, gfn);
>> >          shr_unlock();
>> > +        mem_sharing_notify_helper(d, gfn);
>> This is nice. Do you think PoD could use this, should it ever run into a
>> ENOMEM situation? And what about mem_paging_prep? Perhaps, rather than a
>> sharing ring (which is bit rotted) we could have an ENOMEM ring with a
>> utility launched by xencommons listening. The problem, again, is what if
>> ENOMEM is itself caused by dom0 (e.g. writable mapping of a shared page)
>
> I have no idea about mem_sharing. I just move the existing code outside
> the lock so that mem_event_put_request() is (hopefully) called without
> any locks from mem_sharing_get_nr_saved_mfns().
> Since there is appearently no user of a sharing ring, this whole new
> mem_sharing_notify_helper() is a big no-op.
Fair enough. I do think that generally, for x86/mm, an ENOMEM mem_event
ring is a good idea. Later...

>
>> > @@ -1167,9 +1159,11 @@ void p2m_mem_access_resume(struct domain
>> >      if ( rsp.flags & MEM_EVENT_FLAG_VCPU_PAUSED )
>> >          vcpu_unpause(d->vcpu[rsp.vcpu_id]);
>> >
>> > -    /* Unpause any domains that were paused because the ring was full
>> or
>> > no listener
>> > -     * was available */
>> > -    mem_event_unpause_vcpus(d);
>> > +    /* Wake vcpus waiting for room in the ring */
>> > +    mem_event_wake_requesters(&d->mem_event->access);
>> > +
>> > +    /* Unpause all vcpus that were paused because no listener was
>> > available */
>> > +    mem_event_wake_waiters(d, &d->mem_event->access);
>> Is this not used in p2m_mem_paging_resume? Why the difference? Why are
>> two
>> mechanisms needed (wake_requesters, wake_sleepers)?
>
> As said above, wake_sleepers is for those who wait for the ring itself,
> and wake_requesters is for room in the ring.
> p2m_mem_paging_resume() always has a ring, so it does not need to call
> wake_sleepers.
>
>
> Do you have a suggestion for a better name?
>
> Olaf
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 16:43:05 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 16:43:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXbcu-0003zO-ED; Mon, 05 Dec 2011 16:42:48 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RXbct-0003z5-5r
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 16:42:47 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1323103285!45488690!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjAyNg==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31616 invoked from network); 5 Dec 2011 16:41:25 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Dec 2011 16:41:25 -0000
X-IronPort-AV: E=Sophos;i="4.71,299,1320624000"; 
   d="scan'208";a="9295772"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Dec 2011 16:42:02 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 5 Dec 2011 16:42:01 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RXbc9-0003F9-Kc;
	Mon, 05 Dec 2011 16:42:01 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RXbc9-0003RN-Bp;
	Mon, 05 Dec 2011 16:42:01 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10347-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 5 Dec 2011 16:42:01 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10347: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10347 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10347/

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-i386-xl-winxpsp3-vcpus1  4 xen-install         fail REGR. vs. 10201
 test-amd64-i386-xl-win7-amd64  4 xen-install              fail REGR. vs. 10201
 test-amd64-i386-xend-winxpsp3  4 xen-install              fail REGR. vs. 10201
 test-amd64-i386-pv            4 xen-install               fail REGR. vs. 10201
 test-amd64-i386-xl-credit2    4 xen-install               fail REGR. vs. 10201
 test-amd64-i386-xl-multivcpu  4 xen-install               fail REGR. vs. 10201
 test-amd64-i386-xl            4 xen-install               fail REGR. vs. 10201
 test-amd64-i386-pair          6 xen-install/dst_host      fail REGR. vs. 10201
 test-amd64-i386-pair          5 xen-install/src_host      fail REGR. vs. 10201
 build-i386                    4 xen-build                 fail REGR. vs. 10201
 build-i386-oldkern            4 xen-build                 fail REGR. vs. 10201
 test-amd64-i386-rhel6hvm-intel  4 xen-install             fail REGR. vs. 10201
 test-amd64-i386-rhel6hvm-amd  4 xen-install               fail REGR. vs. 10201
 test-amd64-i386-win-vcpus1    4 xen-install               fail REGR. vs. 10201
 test-amd64-i386-win           4 xen-install               fail REGR. vs. 10201
 test-amd64-amd64-win          8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-amd64-xl-win       8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-i386-xl-win-vcpus1  4 xen-install              fail REGR. vs. 10201

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-win7-amd64  7 windows-install              fail never pass
 test-i386-i386-xl-winxpsp3    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-i386-i386-pv             1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl             1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pair           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   never pass
 test-i386-i386-win            1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-win         1 xen-build-check(1)           blocked  n/a

version targeted for testing:
 xen                  af099b66c109
baseline version:
 xen                  62ff6a318c5d

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Anthony PERARD <anthony.perard@citrix.com>
  Brendan Cully <brendan@cs.ubc.ca>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@novell.com>
  Jan Beulich <jbeulich@suse.com>
  Jonathan Davies <jonathan.davies@citrix.com>
  juergen.gross@ts.fujitsu.com
  Keir Fraser <keir@xen.org>
  Liu, Jinsong <jinsong.liu@intel.com>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
  Philipp Hahn <hahn@univention.de>
  Shriram Rajagopalan <rshriram@cs.ubc.ca>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang2 <wei.wang2@amd.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   fail    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           fail    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           fail    
 test-i386-i386-xl                                            blocked 
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-i386-i386-pair                                          blocked 
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           fail    
 test-i386-i386-pv                                            blocked 
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           blocked 
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        blocked 
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   blocked 


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 1272 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 16:43:05 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 16:43:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXbcu-0003zO-ED; Mon, 05 Dec 2011 16:42:48 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RXbct-0003z5-5r
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 16:42:47 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1323103285!45488690!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjAyNg==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31616 invoked from network); 5 Dec 2011 16:41:25 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Dec 2011 16:41:25 -0000
X-IronPort-AV: E=Sophos;i="4.71,299,1320624000"; 
   d="scan'208";a="9295772"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Dec 2011 16:42:02 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 5 Dec 2011 16:42:01 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RXbc9-0003F9-Kc;
	Mon, 05 Dec 2011 16:42:01 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RXbc9-0003RN-Bp;
	Mon, 05 Dec 2011 16:42:01 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10347-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 5 Dec 2011 16:42:01 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10347: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10347 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10347/

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-i386-xl-winxpsp3-vcpus1  4 xen-install         fail REGR. vs. 10201
 test-amd64-i386-xl-win7-amd64  4 xen-install              fail REGR. vs. 10201
 test-amd64-i386-xend-winxpsp3  4 xen-install              fail REGR. vs. 10201
 test-amd64-i386-pv            4 xen-install               fail REGR. vs. 10201
 test-amd64-i386-xl-credit2    4 xen-install               fail REGR. vs. 10201
 test-amd64-i386-xl-multivcpu  4 xen-install               fail REGR. vs. 10201
 test-amd64-i386-xl            4 xen-install               fail REGR. vs. 10201
 test-amd64-i386-pair          6 xen-install/dst_host      fail REGR. vs. 10201
 test-amd64-i386-pair          5 xen-install/src_host      fail REGR. vs. 10201
 build-i386                    4 xen-build                 fail REGR. vs. 10201
 build-i386-oldkern            4 xen-build                 fail REGR. vs. 10201
 test-amd64-i386-rhel6hvm-intel  4 xen-install             fail REGR. vs. 10201
 test-amd64-i386-rhel6hvm-amd  4 xen-install               fail REGR. vs. 10201
 test-amd64-i386-win-vcpus1    4 xen-install               fail REGR. vs. 10201
 test-amd64-i386-win           4 xen-install               fail REGR. vs. 10201
 test-amd64-amd64-win          8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-amd64-xl-win       8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-i386-xl-win-vcpus1  4 xen-install              fail REGR. vs. 10201

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-win7-amd64  7 windows-install              fail never pass
 test-i386-i386-xl-winxpsp3    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-i386-i386-pv             1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl             1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pair           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   never pass
 test-i386-i386-win            1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-win         1 xen-build-check(1)           blocked  n/a

version targeted for testing:
 xen                  af099b66c109
baseline version:
 xen                  62ff6a318c5d

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Anthony PERARD <anthony.perard@citrix.com>
  Brendan Cully <brendan@cs.ubc.ca>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@novell.com>
  Jan Beulich <jbeulich@suse.com>
  Jonathan Davies <jonathan.davies@citrix.com>
  juergen.gross@ts.fujitsu.com
  Keir Fraser <keir@xen.org>
  Liu, Jinsong <jinsong.liu@intel.com>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
  Philipp Hahn <hahn@univention.de>
  Shriram Rajagopalan <rshriram@cs.ubc.ca>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang2 <wei.wang2@amd.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   fail    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           fail    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           fail    
 test-i386-i386-xl                                            blocked 
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-i386-i386-pair                                          blocked 
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           fail    
 test-i386-i386-pv                                            blocked 
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           blocked 
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        blocked 
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   blocked 


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 1272 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 16:58:49 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 16: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.xensource.com>)
	id 1RXbs6-0004FK-2G; Mon, 05 Dec 2011 16:58:30 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1RXbs4-0004FF-FZ
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 16:58:28 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1323104262!5902627!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDY0NzA=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25171 invoked from network); 5 Dec 2011 16:57:43 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Dec 2011 16:57:43 -0000
X-IronPort-AV: E=Sophos;i="4.71,299,1320642000"; d="scan'208";a="19670007"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Dec 2011 11:57:41 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 5 Dec 2011 11:57:41 -0500
Received: from testbox64.uk.xensource.com ([10.80.237.153])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pB5GvdT6014983;
	Mon, 5 Dec 2011 08:57:40 -0800
From: Wei Liu <wei.liu2@citrix.com>
To: xen-devel@lists.xensource.com, netdev@vger.kernel.org
Date: Mon, 5 Dec 2011 16:57:44 +0000
Message-ID: <1323104264-3601-1-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com
Subject: [Xen-devel] [PATCH] netback: Fix alert message.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

The original message in netback_init was 'kthread_run() fails', which should be
'kthread_create() fails'.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 drivers/net/xen-netback/netback.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
index 1ae270e..15e332d 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -1668,7 +1668,7 @@ static int __init netback_init(void)
 					     "netback/%u", group);
 
 		if (IS_ERR(netbk->task)) {
-			printk(KERN_ALERT "kthread_run() fails at netback\n");
+			printk(KERN_ALERT "kthread_create() fails at netback\n");
 			del_timer(&netbk->net_timer);
 			rc = PTR_ERR(netbk->task);
 			goto failed_init;
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 16:58:49 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 16: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.xensource.com>)
	id 1RXbs6-0004FK-2G; Mon, 05 Dec 2011 16:58:30 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1RXbs4-0004FF-FZ
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 16:58:28 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1323104262!5902627!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDY0NzA=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25171 invoked from network); 5 Dec 2011 16:57:43 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Dec 2011 16:57:43 -0000
X-IronPort-AV: E=Sophos;i="4.71,299,1320642000"; d="scan'208";a="19670007"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Dec 2011 11:57:41 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 5 Dec 2011 11:57:41 -0500
Received: from testbox64.uk.xensource.com ([10.80.237.153])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pB5GvdT6014983;
	Mon, 5 Dec 2011 08:57:40 -0800
From: Wei Liu <wei.liu2@citrix.com>
To: xen-devel@lists.xensource.com, netdev@vger.kernel.org
Date: Mon, 5 Dec 2011 16:57:44 +0000
Message-ID: <1323104264-3601-1-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com
Subject: [Xen-devel] [PATCH] netback: Fix alert message.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

The original message in netback_init was 'kthread_run() fails', which should be
'kthread_create() fails'.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 drivers/net/xen-netback/netback.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
index 1ae270e..15e332d 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -1668,7 +1668,7 @@ static int __init netback_init(void)
 					     "netback/%u", group);
 
 		if (IS_ERR(netbk->task)) {
-			printk(KERN_ALERT "kthread_run() fails at netback\n");
+			printk(KERN_ALERT "kthread_create() fails at netback\n");
 			del_timer(&netbk->net_timer);
 			rc = PTR_ERR(netbk->task);
 			goto failed_init;
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 16:59:53 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 16:59:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXbt6-0004IG-HE; Mon, 05 Dec 2011 16:59:32 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RXbt5-0004Hz-5V
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 16:59:31 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1323104326!4349784!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjAyNg==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9411 invoked from network); 5 Dec 2011 16:58:46 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Dec 2011 16:58:46 -0000
X-IronPort-AV: E=Sophos;i="4.71,299,1320624000"; 
   d="scan'208";a="9296157"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Dec 2011 16:58:46 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Mon, 5 Dec 2011
	16:58:45 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>
Date: Mon, 5 Dec 2011 16:58:45 +0000
In-Reply-To: <1323104264-3601-1-git-send-email-wei.liu2@citrix.com>
References: <1323104264-3601-1-git-send-email-wei.liu2@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323104325.23681.22.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] netback: Fix alert message.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2011-12-05 at 16:57 +0000, Wei Liu wrote:
> The original message in netback_init was 'kthread_run() fails', which should be
> 'kthread_create() fails'.
> 
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>

Thanks!

Ian.

> ---
>  drivers/net/xen-netback/netback.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
> index 1ae270e..15e332d 100644
> --- a/drivers/net/xen-netback/netback.c
> +++ b/drivers/net/xen-netback/netback.c
> @@ -1668,7 +1668,7 @@ static int __init netback_init(void)
>  					     "netback/%u", group);
>  
>  		if (IS_ERR(netbk->task)) {
> -			printk(KERN_ALERT "kthread_run() fails at netback\n");
> +			printk(KERN_ALERT "kthread_create() fails at netback\n");
>  			del_timer(&netbk->net_timer);
>  			rc = PTR_ERR(netbk->task);
>  			goto failed_init;



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 16:59:53 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 16:59:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXbt6-0004IG-HE; Mon, 05 Dec 2011 16:59:32 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RXbt5-0004Hz-5V
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 16:59:31 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1323104326!4349784!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjAyNg==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9411 invoked from network); 5 Dec 2011 16:58:46 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Dec 2011 16:58:46 -0000
X-IronPort-AV: E=Sophos;i="4.71,299,1320624000"; 
   d="scan'208";a="9296157"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Dec 2011 16:58:46 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Mon, 5 Dec 2011
	16:58:45 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>
Date: Mon, 5 Dec 2011 16:58:45 +0000
In-Reply-To: <1323104264-3601-1-git-send-email-wei.liu2@citrix.com>
References: <1323104264-3601-1-git-send-email-wei.liu2@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323104325.23681.22.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] netback: Fix alert message.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2011-12-05 at 16:57 +0000, Wei Liu wrote:
> The original message in netback_init was 'kthread_run() fails', which should be
> 'kthread_create() fails'.
> 
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>

Thanks!

Ian.

> ---
>  drivers/net/xen-netback/netback.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
> index 1ae270e..15e332d 100644
> --- a/drivers/net/xen-netback/netback.c
> +++ b/drivers/net/xen-netback/netback.c
> @@ -1668,7 +1668,7 @@ static int __init netback_init(void)
>  					     "netback/%u", group);
>  
>  		if (IS_ERR(netbk->task)) {
> -			printk(KERN_ALERT "kthread_run() fails at netback\n");
> +			printk(KERN_ALERT "kthread_create() fails at netback\n");
>  			del_timer(&netbk->net_timer);
>  			rc = PTR_ERR(netbk->task);
>  			goto failed_init;



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 18:07:26 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 18:07:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXcwB-0005wq-TS; Mon, 05 Dec 2011 18:06:47 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RXcwA-0005wl-6J
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 18:06:46 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-16.tower-216.messagelabs.com!1323108359!6172746!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNDI4NTE=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNDI4NTE=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30541 invoked from network); 5 Dec 2011 18:06:00 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-16.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 5 Dec 2011 18:06:00 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1323108359; l=224;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=MMxjvyRgqVLSlGZvAVhjTEd3Rhs=;
	b=ZyztyhNmzs8Mv26xIbYHOc2y+XEStR+OTsfv68WGNODf7X+fgmLTVl607k61vP6UqbE
	hzROIMCeKage3JbAykXhf29AMh6n7rlidmDhXJMx+bpzQE4TdvbCwj4YXLyEnaS8ou/DV
	oT5iTKY5wN9GpUltQqgPCv8ey/T+xSwf/iA=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFJjS0NG7Q=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-073-038.pools.arcor-ip.net [88.65.73.38])
	by smtp.strato.de (jimi mo45) (RZmta 26.10 AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id 604e3dnB5Gc9rY ;
	Mon, 5 Dec 2011 19:05:39 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 5AFB718637; Mon,  5 Dec 2011 19:05:38 +0100 (CET)
Date: Mon, 5 Dec 2011 19:05:38 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Message-ID: <20111205180538.GA31722@aepfle.de>
References: <4EDC9C2D02000078000655D1@nat28.tlf.novell.com>
	<1323084885-7531-1-git-send-email-dgdegra@tycho.nsa.gov>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1323084885-7531-1-git-send-email-dgdegra@tycho.nsa.gov>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: xen-devel@lists.xensource.com, Keir Fraser <keir@xen.org>,
	JBeulich@suse.com
Subject: Re: [Xen-devel] [PATCH v2] flask: Fix 32-bit compilation of
 label-pci tool
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Dec 05, Daniel De Graaf wrote:

> +	fscanf(f, "%" SCNu64, &start);

label-pci.c:108: error: ignoring return value of 'fscanf', declared with attribute warn_unused_result

This still leads to an error.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 18:07:26 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 18:07:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXcwB-0005wq-TS; Mon, 05 Dec 2011 18:06:47 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RXcwA-0005wl-6J
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 18:06:46 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-16.tower-216.messagelabs.com!1323108359!6172746!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNDI4NTE=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNDI4NTE=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30541 invoked from network); 5 Dec 2011 18:06:00 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-16.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 5 Dec 2011 18:06:00 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1323108359; l=224;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=MMxjvyRgqVLSlGZvAVhjTEd3Rhs=;
	b=ZyztyhNmzs8Mv26xIbYHOc2y+XEStR+OTsfv68WGNODf7X+fgmLTVl607k61vP6UqbE
	hzROIMCeKage3JbAykXhf29AMh6n7rlidmDhXJMx+bpzQE4TdvbCwj4YXLyEnaS8ou/DV
	oT5iTKY5wN9GpUltQqgPCv8ey/T+xSwf/iA=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFJjS0NG7Q=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-073-038.pools.arcor-ip.net [88.65.73.38])
	by smtp.strato.de (jimi mo45) (RZmta 26.10 AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id 604e3dnB5Gc9rY ;
	Mon, 5 Dec 2011 19:05:39 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 5AFB718637; Mon,  5 Dec 2011 19:05:38 +0100 (CET)
Date: Mon, 5 Dec 2011 19:05:38 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Message-ID: <20111205180538.GA31722@aepfle.de>
References: <4EDC9C2D02000078000655D1@nat28.tlf.novell.com>
	<1323084885-7531-1-git-send-email-dgdegra@tycho.nsa.gov>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1323084885-7531-1-git-send-email-dgdegra@tycho.nsa.gov>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: xen-devel@lists.xensource.com, Keir Fraser <keir@xen.org>,
	JBeulich@suse.com
Subject: Re: [Xen-devel] [PATCH v2] flask: Fix 32-bit compilation of
 label-pci tool
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Dec 05, Daniel De Graaf wrote:

> +	fscanf(f, "%" SCNu64, &start);

label-pci.c:108: error: ignoring return value of 'fscanf', declared with attribute warn_unused_result

This still leads to an error.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 18:11:31 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 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.xensource.com>)
	id 1RXd0Z-0006Ao-Cv; Mon, 05 Dec 2011 18:11:19 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RXd0V-000666-NR
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 18:11:16 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1323108629!5440616!5
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjAyNg==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14126 invoked from network); 5 Dec 2011 18:10:31 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Dec 2011 18:10:31 -0000
X-IronPort-AV: E=Sophos;i="4.71,300,1320624000"; 
   d="scan'208";a="9297534"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Dec 2011 18:10:30 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 5 Dec 2011 18:10:30 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RXczm-0003kb-ER; Mon, 05 Dec 2011 18:10:30 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RXczm-0006Wn-DU;
	Mon, 05 Dec 2011 18:10:30 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Mon, 5 Dec 2011 18:10:21 +0000
Message-ID: <1323108621-22654-16-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1323108621-22654-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1323108621-22654-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 15/15] libxl: New event generation API
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Replace the existing API for retrieving high-level events (events
about domains, etc.) from libxl with a new one.

This changes the definition and semantics of the `libxl_event'
structure, and replaces the calls for obtaining information about
domain death and disk eject events.

This is an incompatible change, sorry.  The alternative was to try to
provide both the previous horrid API and the new one, and would also
involve never using the name `libxl_event' for the new interface.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl.c          |  302 ++++++++++++++++++++++++++++++------------
 tools/libxl/libxl.h          |   55 ++-------
 tools/libxl/libxl_event.c    |  188 ++++++++++++++++++++++++---
 tools/libxl/libxl_event.h    |  180 ++++++++++++++++++++++++-
 tools/libxl/libxl_internal.c |    6 +
 tools/libxl/libxl_internal.h |   81 +++++++++++-
 tools/libxl/libxl_types.idl  |   35 ++++-
 tools/libxl/xl_cmdimpl.c     |  270 ++++++++++++++++++++++----------------
 8 files changed, 839 insertions(+), 278 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 58f280c..ba9293b 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -60,8 +60,11 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
      * only as an initialiser, not as an expression. */
     memcpy(&ctx->lock, &mutex_value, sizeof(ctx->lock));
 
+    LIBXL_TAILQ_INIT(&ctx->occurred);
+
     ctx->osevent_hooks = 0;
 
+    ctx->fd_polls = 0;
     ctx->fd_beforepolled = 0;
     LIBXL_LIST_INIT(&ctx->efds);
     LIBXL_TAILQ_INIT(&ctx->etimes);
@@ -70,6 +73,9 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
     LIBXL_SLIST_INIT(&ctx->watch_freeslots);
     libxl__ev_fd_init(&ctx->watch_efd);
 
+    LIBXL_TAILQ_INIT(&ctx->death_list);
+    libxl__ev_xswatch_init(&ctx->death_watch);
+
     if ( stat(XENSTORE_PID_FILE, &stat_buf) != 0 ) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "Is xenstore daemon running?\n"
                      "failed to stat %s", XENSTORE_PID_FILE);
@@ -97,6 +103,13 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
     return 0;
 }
 
+static void free_disable_deaths(libxl__gc *gc,
+                                struct libxl__evgen_domain_death_list *l) {
+    libxl_evgen_domain_death *death;
+    while ((death = LIBXL_TAILQ_FIRST(l)))
+        libxl__evdisable_domain_death(gc, death);
+}
+
 int libxl_ctx_free(libxl_ctx *ctx)
 {
     int i;
@@ -104,6 +117,9 @@ int libxl_ctx_free(libxl_ctx *ctx)
 
     if (!ctx) return 0;
 
+    free_disable_deaths(gc, &CTX->death_list);
+    free_disable_deaths(gc, &CTX->death_reported);
+
     for (i = 0; i < ctx->watch_nslots; i++)
         assert(!libxl__watch_slot_contents(gc, i));
     libxl__ev_fd_deregister(gc, &ctx->watch_efd);
@@ -115,6 +131,7 @@ int libxl_ctx_free(libxl_ctx *ctx)
     libxl_version_info_dispose(&ctx->version_info);
     if (ctx->xsh) xs_daemon_close(ctx->xsh);
 
+    free(ctx->fd_polls);
     free(ctx->fd_beforepolled);
     free(ctx->watch_slots);
 
@@ -614,117 +631,173 @@ int libxl_domain_shutdown(libxl_ctx *ctx, uint32_t domid, int req)
     return 0;
 }
 
-int libxl_get_wait_fd(libxl_ctx *ctx, int *fd)
-{
-    *fd = xs_fileno(ctx->xsh);
-    return 0;
-}
+static void domain_death_xswatch_callback(libxl__gc *gc, libxl__ev_xswatch *w,
+                                        const char *wpath, const char *epath) {
+    libxl_evgen_domain_death *evg;
+    uint32_t domid;
+    int rc;
 
-int libxl_wait_for_domain_death(libxl_ctx *ctx, uint32_t domid, libxl_waiter *waiter)
-{
-    waiter->path = strdup("@releaseDomain");
-    if (asprintf(&(waiter->token), "%d", LIBXL_EVENT_TYPE_DOMAIN_DEATH) < 0)
-        return -1;
-    if (!xs_watch(ctx->xsh, waiter->path, waiter->token))
-        return -1;
-    return 0;
-}
+    CTX_LOCK;
 
-int libxl_wait_for_disk_ejects(libxl_ctx *ctx, uint32_t guest_domid, libxl_device_disk *disks, int num_disks, libxl_waiter *waiter)
-{
-    GC_INIT(ctx);
-    int i, rc = -1;
-    uint32_t domid = libxl_get_stubdom_id(ctx, guest_domid);
+    evg = LIBXL_TAILQ_FIRST(&CTX->death_list);
+    if (!evg) goto out;
 
-    if (!domid)
-        domid = guest_domid;
+    domid = evg->domid;
 
-    for (i = 0; i < num_disks; i++) {
-        if (asprintf(&(waiter[i].path), "%s/device/vbd/%d/eject",
-                     libxl__xs_get_dompath(gc, domid),
-                     libxl__device_disk_dev_number(disks[i].vdev,
-                                                   NULL, NULL)) < 0)
-            goto out;
-        if (asprintf(&(waiter[i].token), "%d", LIBXL_EVENT_TYPE_DISK_EJECT) < 0)
+    for (;;) {
+        int nentries = LIBXL_TAILQ_NEXT(evg, entry) ? 200 : 1;
+        xc_domaininfo_t domaininfos[nentries];
+        const xc_domaininfo_t *got = domaininfos, *gotend;
+
+        rc = xc_domain_getinfolist(CTX->xch, domid, nentries, domaininfos);
+        if (rc == -1) {
+            LIBXL__EVENT_DISASTER(gc, "xc_domain_getinfolist failed while"
+                                  " processing @releaseDomain watch event",
+                                  errno, 0);
             goto out;
-        xs_watch(ctx->xsh, waiter[i].path, waiter[i].token);
+        }
+        gotend = &domaininfos[rc];
+
+        for (;;) {
+            if (!evg)
+                goto all_reported;
+
+            if (!rc || got->domain > evg->domid) {
+                /* ie, the list doesn't contain evg->domid any more so
+                 * the domain has been destroyed */
+                libxl_evgen_domain_death *evg_next;
+
+                libxl_event *ev = NEW_EVENT(gc, DOMAIN_DESTROY, evg->domid);
+                if (!ev) goto out;
+
+                libxl__event_occurred(gc, ev);
+
+                evg->death_reported = 1;
+                evg_next = LIBXL_TAILQ_NEXT(evg, entry);
+                LIBXL_TAILQ_REMOVE(&CTX->death_list, evg, entry);
+                LIBXL_TAILQ_INSERT_HEAD(&CTX->death_reported, evg, entry);
+                evg = evg_next;
+
+                continue;
+            }
+            
+            if (got == gotend)
+                break;
+
+            if (got->domain < evg->domid) {
+                got++;
+                continue;
+            }
+
+            assert(evg->domid == got->domain);
+
+            if (!evg->shutdown_reported &&
+                (got->flags & XEN_DOMINF_shutdown)) {
+                libxl_event *ev = NEW_EVENT(gc, DOMAIN_SHUTDOWN, got->domain);
+                if (!ev) goto out;
+                
+                ev->u.domain_shutdown.shutdown_reason =
+                    (got->flags >> XEN_DOMINF_shutdownshift) &
+                    XEN_DOMINF_shutdownmask;
+                libxl__event_occurred(gc, ev);
+
+                evg->shutdown_reported = 1;
+            }
+            evg = LIBXL_TAILQ_NEXT(evg, entry);
+        }
+
+        assert(rc); /* rc==0 results in us eating all evgs and quitting */
+        domid = gotend[-1].domain;
     }
-    rc = 0;
-out:
-    GC_FREE;
-    return rc;
+ all_reported:
+ out:
+
+    CTX_UNLOCK;
 }
 
-int libxl_get_event(libxl_ctx *ctx, libxl_event *event)
-{
-    unsigned int num;
-    char **events = xs_read_watch(ctx->xsh, &num);
-    if (num != 2) {
-        free(events);
-        return ERROR_FAIL;
+int libxl_evenable_domain_death(libxl_ctx *ctx, uint32_t domid,
+                libxl_ev_user user, libxl_evgen_domain_death **evgen_out) {
+    GC_INIT(ctx);
+    libxl_evgen_domain_death *evg, *evg_search;
+    int rc;
+    
+    CTX_LOCK;
+
+    evg = malloc(sizeof(*evg));  if (!evg) { rc = ERROR_NOMEM; goto out; }
+    memset(evg, 0, sizeof(*evg));
+    evg->domid = domid;
+    evg->user = user;
+
+    LIBXL_TAILQ_INSERT_SORTED(&ctx->death_list, entry, evg, evg_search, ,
+                              evg->domid > evg_search->domid);
+
+    if (!libxl__ev_xswatch_isregistered(&ctx->death_watch)) {
+        rc = libxl__ev_xswatch_register(gc, &ctx->death_watch,
+                        domain_death_xswatch_callback, "@releaseDomain");
+        if (rc) { libxl__evdisable_domain_death(gc, evg); goto out; }
     }
-    event->path = strdup(events[XS_WATCH_PATH]);
-    event->token = strdup(events[XS_WATCH_TOKEN]);
-    event->type = atoi(event->token);
-    free(events);
-    return 0;
-}
 
-int libxl_stop_waiting(libxl_ctx *ctx, libxl_waiter *waiter)
-{
-    if (!xs_unwatch(ctx->xsh, waiter->path, waiter->token))
-        return ERROR_FAIL;
-    else
-        return 0;
-}
+    rc = 0;
 
-int libxl_free_event(libxl_event *event)
-{
-    free(event->path);
-    free(event->token);
-    return 0;
-}
+ out:
+    CTX_UNLOCK;
+    return rc;
+};
 
-int libxl_free_waiter(libxl_waiter *waiter)
-{
-    free(waiter->path);
-    free(waiter->token);
-    return 0;
-}
+void libxl__evdisable_domain_death(libxl__gc *gc,
+                                   libxl_evgen_domain_death *evg) {
+    CTX_LOCK;
 
-int libxl_event_get_domain_death_info(libxl_ctx *ctx, uint32_t domid, libxl_event *event, libxl_dominfo *info)
-{
-    if (libxl_domain_info(ctx, info, domid) < 0)
-        return 0;
+    if (!evg->death_reported)
+        LIBXL_TAILQ_REMOVE(&CTX->death_list, evg, entry);
+    else
+        LIBXL_TAILQ_REMOVE(&CTX->death_reported, evg, entry);
 
-    if (info->running || (!info->shutdown && !info->dying))
-        return ERROR_INVAL;
+    free(evg);
+
+    if (!LIBXL_TAILQ_FIRST(&CTX->death_list) &&
+        libxl__ev_xswatch_isregistered(&CTX->death_watch))
+        libxl__ev_xswatch_deregister(gc, &CTX->death_watch);
 
-    return 1;
+    CTX_UNLOCK;
 }
 
-int libxl_event_get_disk_eject_info(libxl_ctx *ctx, uint32_t domid, libxl_event *event, libxl_device_disk *disk)
-{
+void libxl_evdisable_domain_death(libxl_ctx *ctx,
+                                  libxl_evgen_domain_death *evg) {
     GC_INIT(ctx);
-    char *path;
+    libxl__evdisable_domain_death(gc, evg);
+    GC_FREE;
+}
+
+static void disk_eject_xswatch_callback(libxl__gc *gc, libxl__ev_xswatch *watch,
+                                        const char *wpath, const char *epath) {
+    libxl_evgen_disk_eject *evg = (void*)watch;
     char *backend;
     char *value;
     char backend_type[BACKEND_STRING_SIZE+1];
 
-    value = libxl__xs_read(gc, XBT_NULL, event->path);
+    value = libxl__xs_read(gc, XBT_NULL, wpath);
 
-    if (!value || strcmp(value,  "eject")) {
-        GC_FREE;
-        return 0;
+    if (!value || strcmp(value,  "eject"))
+        return;
+
+    if (libxl__xs_write(gc, XBT_NULL, wpath, "")) {
+        LIBXL__EVENT_DISASTER(gc, "xs_write failed acknowledging eject",
+                              errno, LIBXL_EVENT_TYPE_DISK_EJECT);
+        return;
     }
 
-    path = strdup(event->path);
-    path[strlen(path) - 6] = '\0';
-    backend = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/backend", path));
+    libxl_event *ev = NEW_EVENT(gc, DISK_EJECT, evg->domid);
+    libxl_device_disk *disk = &ev->u.disk_eject.disk;
+    
+    backend = libxl__xs_read(gc, XBT_NULL,
+                             libxl__sprintf(gc, "%.*s/backend",
+                                            (int)strlen(wpath)-6, wpath));
 
     sscanf(backend,
-            "/local/domain/%d/backend/%" TOSTRING(BACKEND_STRING_SIZE) "[a-z]/%*d/%*d",
-            &disk->backend_domid, backend_type);
+            "/local/domain/%d/backend/%" TOSTRING(BACKEND_STRING_SIZE)
+           "[a-z]/%*d/%*d",
+           &disk->backend_domid, backend_type);
     if (!strcmp(backend_type, "tap") || !strcmp(backend_type, "vbd")) {
         disk->backend = LIBXL_DISK_BACKEND_TAP;
     } else if (!strcmp(backend_type, "qdisk")) {
@@ -733,19 +806,72 @@ int libxl_event_get_disk_eject_info(libxl_ctx *ctx, uint32_t domid, libxl_event
         disk->backend = LIBXL_DISK_BACKEND_UNKNOWN;
     }
 
-    disk->pdev_path = strdup("");
+    disk->pdev_path = strdup(""); /* xxx fixme malloc failure */
     disk->format = LIBXL_DISK_FORMAT_EMPTY;
     /* this value is returned to the user: do not free right away */
-    disk->vdev = xs_read(ctx->xsh, XBT_NULL, libxl__sprintf(gc, "%s/dev", backend), NULL);
+    disk->vdev = xs_read(CTX->xsh, XBT_NULL,
+                         libxl__sprintf(gc, "%s/dev", backend), NULL);
     disk->removable = 1;
     disk->readwrite = 0;
     disk->is_cdrom = 1;
 
-    free(path);
+    libxl__event_occurred(gc, ev);
+}
+
+int libxl_evenable_disk_eject(libxl_ctx *ctx, uint32_t guest_domid,
+                              const char *vdev, libxl_ev_user user,
+                              libxl_evgen_disk_eject **evgen_out) {
+    GC_INIT(ctx);
+    int rc;
+    char *path;
+    libxl_evgen_disk_eject *evg = NULL;
+
+    evg = malloc(sizeof(*evg));  if (!evg) { rc = ERROR_NOMEM; goto out; }
+    memset(evg, 0, sizeof(*evg));
+    evg->user = user;
+    evg->domid = guest_domid;
+
+    evg->vdev = strdup(vdev);
+    if (!evg->vdev) { rc = ERROR_NOMEM; goto out; }
+
+    uint32_t domid = libxl_get_stubdom_id(ctx, guest_domid);
+
+    if (!domid)
+        domid = guest_domid;
+
+    path = libxl__sprintf(gc, "%s/device/vbd/%d/eject",
+                 libxl__xs_get_dompath(gc, domid),
+                 libxl__device_disk_dev_number(vdev, NULL, NULL));
+    if (!path) { rc = ERROR_NOMEM; goto out; }
+
+    rc = libxl__ev_xswatch_register(gc, &evg->watch,
+                                    disk_eject_xswatch_callback, path);
+    if (rc) goto out;
+
     GC_FREE;
-    return 1;
+    return 0;
+
+ out:
+    if (evg)
+        libxl__evdisable_disk_eject(gc, evg);
+    GC_FREE;
+    return rc;
 }
 
+void libxl__evdisable_disk_eject(libxl__gc *gc, libxl_evgen_disk_eject *evg) {
+    if (libxl__ev_xswatch_isregistered(&evg->watch))
+        libxl__ev_xswatch_deregister(gc, &evg->watch);
+
+    free(evg->vdev);
+    free(evg);
+}
+
+void libxl_evdisable_disk_eject(libxl_ctx *ctx, libxl_evgen_disk_eject *evg) {
+    GC_INIT(ctx);
+    libxl__evdisable_disk_eject(gc, evg);
+    GC_FREE;
+}    
+
 int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid, int force)
 {
     GC_INIT(ctx);
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 654a5b0..17b15a6 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -53,7 +53,10 @@
  *    A public function may be called from within libxl; the call
  *    context initialisation macros will make sure that the internal
  *    caller's context is reused (eg, so that the same xenstore
- *    transaction is used).
+ *    transaction is used).  But in-libxl callers of libxl public
+ *    functions should note that any libxl public function may cause
+ *    recursively reentry into libxl via the application's event
+ *    callback hook.
  *
  *    Public functions have names like libxl_foobar.
  *
@@ -152,6 +155,8 @@ void libxl_key_value_list_dispose(libxl_key_value_list *kvl);
 
 typedef uint32_t libxl_hwcap[8];
 
+typedef uint64_t libxl_ev_user;
+
 typedef struct {
     uint32_t size;          /* number of bytes in map */
     uint8_t *map;
@@ -200,6 +205,9 @@ typedef struct {
     int v;
 } libxl_enum_string_table;
 
+struct libxl_event;
+typedef LIBXL_TAILQ_ENTRY(struct libxl_event) libxl_ev_link;
+
 typedef struct libxl__ctx libxl_ctx;
 
 #include "_libxl_types.h"
@@ -298,51 +306,6 @@ int libxl_run_bootloader(libxl_ctx *ctx,
 
   /* 0 means ERROR_ENOMEM, which we have logged */
 
-/* events handling */
-
-typedef struct {
-    /* event type */
-    libxl_event_type type;
-    /* data for internal use of the library */
-    char *path;
-    char *token;
-} libxl_event;
-
-typedef struct {
-    char *path;
-    char *token;
-} libxl_waiter;
-
-
-int libxl_get_wait_fd(libxl_ctx *ctx, int *fd);
-/* waiter is allocated by the caller */
-int libxl_wait_for_domain_death(libxl_ctx *ctx, uint32_t domid, libxl_waiter *waiter);
-/* waiter is a preallocated array of num_disks libxl_waiter elements */
-int libxl_wait_for_disk_ejects(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *disks, int num_disks, libxl_waiter *waiter);
-int libxl_get_event(libxl_ctx *ctx, libxl_event *event);
-int libxl_stop_waiting(libxl_ctx *ctx, libxl_waiter *waiter);
-int libxl_free_event(libxl_event *event);
-int libxl_free_waiter(libxl_waiter *waiter);
-
-/*
- * Returns:
- *  - 0 if the domain is dead but there is no cleanup to be done. e.g
- *    because someone else has already done it.
- *  - 1 if the domain is dead and there is cleanup to be done.
- *
- * Can return error if the domain exists and is still running.
- *
- * *info will contain valid domain state iff 1 is returned. In
- * particular if 1 is returned then info->shutdown_reason is
- * guaranteed to be valid since by definition the domain is
- * (shutdown||dying))
- */
-int libxl_event_get_domain_death_info(libxl_ctx *ctx, uint32_t domid, libxl_event *event, libxl_dominfo *info);
-
-/*
- * Returns true and fills *disk if the caller should eject the disk
- */
-int libxl_event_get_disk_eject_info(libxl_ctx *ctx, uint32_t domid, libxl_event *event, libxl_device_disk *disk);
 
 int libxl_domain_rename(libxl_ctx *ctx, uint32_t domid,
                         const char *old_name, const char *new_name);
diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
index 8d4dbf6..ec5c25e 100644
--- a/tools/libxl/libxl_event.c
+++ b/tools/libxl/libxl_event.c
@@ -493,9 +493,9 @@ void libxl__ev_xswatch_deregister(libxl__gc *gc, libxl__ev_xswatch *w) {
  * osevent poll
  */
 
-int libxl_osevent_beforepoll(libxl_ctx *ctx, int *nfds_io,
-                             struct pollfd *fds, int *timeout_upd,
-                             struct timeval now) {
+static int beforepoll_unlocked(libxl__gc *gc, int *nfds_io,
+                               struct pollfd *fds, int *timeout_upd,
+                               struct timeval now) {
     libxl__ev_fd *efd;
     int i;
 
@@ -506,9 +506,6 @@ int libxl_osevent_beforepoll(libxl_ctx *ctx, int *nfds_io,
      * the fds array corresponds to a slot in fd_beforepolled.
      */
 
-    GC_INIT(ctx);
-    CTX_LOCK;
-
     if (*nfds_io) {
         /*
          * As an optimisation, we don't touch fd_beforepolled_used
@@ -580,16 +577,25 @@ int libxl_osevent_beforepoll(libxl_ctx *ctx, int *nfds_io,
             *timeout_upd = our_timeout;
     }
 
-    CTX_UNLOCK;
-    GC_FREE;
     return rc;
 }
 
-void libxl_osevent_afterpoll(libxl_ctx *ctx, int nfds, const struct pollfd *fds,
+int libxl_osevent_beforepoll(libxl_ctx *ctx, int *nfds_io,
+                             struct pollfd *fds, int *timeout_upd,
                              struct timeval now) {
-    int i;
+
     GC_INIT(ctx);
     CTX_LOCK;
+    int rc = beforepoll_unlocked(gc, nfds_io, fds, timeout_upd, now);
+    CTX_UNLOCK;
+    GC_FREE;
+    return rc;
+}
+
+static void afterpoll_unlocked(libxl__gc *gc,
+                               int nfds, const struct pollfd *fds,
+                               struct timeval now) {
+    int i;
 
     assert(nfds <= CTX->fd_beforepolled_used);
 
@@ -625,12 +631,17 @@ void libxl_osevent_afterpoll(libxl_ctx *ctx, int nfds, const struct pollfd *fds,
 
         etime->func(gc, etime, &etime->abs);
     }
+}
 
+void libxl_osevent_afterpoll(libxl_ctx *ctx, int nfds, const struct pollfd *fds,
+                             struct timeval now) {
+    GC_INIT(ctx);
+    CTX_LOCK;
+    afterpoll_unlocked(gc, nfds, fds, now);
     CTX_UNLOCK;
     GC_FREE;
 }
 
-
 /*
  * osevent hook and callback machinery
  */
@@ -689,11 +700,10 @@ void libxl__event_disaster(libxl__gc *gc, const char *msg, int errnoval,
                type ? libxl_event_type_to_string(type) : "",
                type ? ")" : "");
 
-    /*
-     * FIXME: This should call the "disaster" hook supplied to
-     * libxl_event_register_callbacks, which will be introduced in the
-     * next patch.
-     */
+    if (CTX->event_hooks && CTX->event_hooks->disaster) {
+        CTX->event_hooks->disaster(CTX->event_hooks_user, type, msg, errnoval);
+        return;
+    }
 
     const char verybad[] =
         "DISASTER in event loop not handled by libxl application";
@@ -703,6 +713,152 @@ void libxl__event_disaster(libxl__gc *gc, const char *msg, int errnoval,
 }
 
 /*
+ * Event retrieval etc.
+ */
+
+void libxl_event_register_callbacks(libxl_ctx *ctx,
+                  const libxl_event_hooks *hooks, void *user) {
+    ctx->event_hooks = hooks;
+    ctx->event_hooks_user = user;
+}
+
+void libxl__event_occurred(libxl__gc *gc, libxl_event *event) {
+    if (CTX->event_hooks &&
+        (CTX->event_hooks->event_occurs_mask & (1UL << event->type))) {
+        /* libxl__free_all will call the callback, just before exit
+         * from libxl.  This helps avoid reentrancy bugs: parts of
+         * libxl that call libxl__event_occurred do not have to worry
+         * that libxl might be reentered at that point. */
+        LIBXL_TAILQ_INSERT_TAIL(&gc->occurred_for_callback, event, link);
+        return;
+    } else {
+        LIBXL_TAILQ_INSERT_TAIL(&CTX->occurred, event, link);
+    }
+}
+
+void libxl_event_free(libxl_ctx *ctx, libxl_event *event) {
+    libxl_event_dispose(event);
+    free(event);
+}
+
+libxl_event *libxl__event_new(libxl__gc *gc,
+                              libxl_event_type type, uint32_t domid) {
+    libxl_event *ev;
+
+    ev = malloc(sizeof(*ev));
+    if (!ev) {
+        LIBXL__EVENT_DISASTER(gc, "allocate new event", errno, type);
+        return NULL;
+    }
+
+    memset(ev, 0, sizeof(*ev));
+    ev->type = type;
+    ev->domid = domid;
+
+    return ev;
+}
+
+static int event_check_unlocked(libxl__gc *gc, libxl_event **event_r,
+                                unsigned long typemask,
+                                libxl_event_predicate *pred, void *pred_user) {
+    libxl_event *ev;
+    int rc;
+
+    LIBXL_TAILQ_FOREACH(ev, &CTX->occurred, link) {
+        if (!(typemask & (1UL << ev->type)))
+            continue;
+
+        if (pred && !pred(ev, pred_user))
+            continue;
+
+        /* got one! */
+        LIBXL_TAILQ_REMOVE(&CTX->occurred, ev, link);
+        *event_r = ev;
+        rc = 0;
+        goto out;
+    }
+    rc = ERROR_NOT_READY;
+
+ out:
+    return rc;
+}
+
+int libxl_event_check(libxl_ctx *ctx, libxl_event **event_r,
+                      unsigned long typemask,
+                      libxl_event_predicate *pred, void *pred_user) {
+    GC_INIT(ctx);
+    CTX_LOCK;
+    int rc = event_check_unlocked(gc, event_r, typemask, pred, pred_user);
+    CTX_UNLOCK;
+    GC_FREE;
+    return rc;
+}
+
+int libxl_event_wait(libxl_ctx *ctx, libxl_event **event_r,
+                     unsigned long typemask,
+                     libxl_event_predicate *pred, void *pred_user) {
+    int rc;
+    struct timeval now;
+
+    GC_INIT(ctx);
+    CTX_LOCK;
+
+    for (;;) {
+        rc = event_check_unlocked(gc, event_r, typemask, pred, pred_user);
+        if (rc != ERROR_NOT_READY) goto out;
+
+        rc = libxl__gettimeofday(gc, &now);
+        if (rc) goto out;
+
+        int timeout;
+
+        for (;;) {
+            int nfds = CTX->fd_polls_allocd;
+            timeout = -1;
+            rc = beforepoll_unlocked(gc, &nfds, CTX->fd_polls, &timeout, now);
+            if (!rc) break;
+            if (rc != ERROR_BUFFERFULL) goto out;
+            
+            struct pollfd *newarray =
+                (nfds > INT_MAX / sizeof(struct pollfd) / 2) ? 0 :
+                realloc(CTX->fd_polls, sizeof(*newarray) * nfds);
+            
+            if (!newarray) { rc = ERROR_NOMEM; goto out; }
+
+            CTX->fd_polls = newarray;
+            CTX->fd_polls_allocd = nfds;
+        }
+
+        rc = poll(CTX->fd_polls, CTX->fd_polls_allocd, timeout);
+        if (rc < 0) {
+            if (errno == EINTR) continue;
+            LIBXL__LOG_ERRNOVAL(CTX, LIBXL__LOG_ERROR, errno, "poll failed");
+            rc = ERROR_FAIL;
+            goto out;
+        }
+
+        rc = libxl__gettimeofday(gc, &now);
+        if (rc) goto out;
+
+        afterpoll_unlocked(gc, CTX->fd_polls_allocd, CTX->fd_polls, now);
+
+        /* we unlock and free the gc each time we go through this loop,
+         * so that (a) we don't accumulate garbage and (b) any events
+         * which are to be dispatched by callback are actually delivered
+         * in a timely fashion.
+         */
+        CTX_UNLOCK;
+        libxl__free_all(gc);
+        CTX_LOCK;
+    }
+
+ out:
+    CTX_UNLOCK;
+    GC_FREE;
+    return rc;
+}
+
+/*
  * Local variables:
  * mode: C
  * c-basic-offset: 4
diff --git a/tools/libxl/libxl_event.h b/tools/libxl/libxl_event.h
index 25efbdf..bbe1ed0 100644
--- a/tools/libxl/libxl_event.h
+++ b/tools/libxl/libxl_event.h
@@ -18,6 +18,178 @@
 
 #include <libxl.h>
 
+/*======================================================================*/
+
+/*
+ * Domain event handling - getting Xen events from libxl
+ */
+
+#define LIBXL_EVENTMASK_ALL (~(unsigned long)0)
+
+typedef int libxl_event_predicate(const libxl_event*, void *user);
+  /* Return value is 0 if the event is unwanted or non-0 if it is.
+   * Predicates are not allowed to fail.
+   */
+
+int libxl_event_check(libxl_ctx *ctx, libxl_event **event_r,
+                      unsigned long typemask,
+                      libxl_event_predicate *predicate, void *predicate_user);
+  /* Searches for an event, already-happened, which matches typemask
+   * and predicate.  predicate==0 matches any event.
+   * libxl_event_check returns the event, which must then later be
+   * freed by the caller using libxl_event_free.
+   *
+   * Returns ERROR_NOT_READY if no such event has happened.
+   */
+
+int libxl_event_wait(libxl_ctx *ctx, libxl_event **event_r,
+                     unsigned long typemask,
+                     libxl_event_predicate *predicate, void *predicate_user);
+  /* Like libxl_event_check but blocks if no suitable events are
+   * available, until some are.  Uses libxl_osevent_beforepoll/
+   * _afterpoll so may be inefficient if very many domains are being
+   * handled by a single program.
+   */
+
+void libxl_event_free(libxl_ctx *ctx, libxl_event *event);
+
+
+/* Alternatively or additionally, the application may also use this: */
+
+typedef struct libxl_event_hooks {
+    uint64_t event_occurs_mask;
+    void (*event_occurs)(void *user, const libxl_event *event);
+    void (*disaster)(void *user, libxl_event_type type,
+                     const char *msg, int errnoval);
+} libxl_event_hooks;
+
+void libxl_event_register_callbacks(libxl_ctx *ctx,
+                                    const libxl_event_hooks *hooks, void *user);
+  /*
+   * Arranges that libxl will henceforth call event_occurs for any
+   * events whose type is set in event_occurs_mask, rather than
+   * queueing the event for retrieval by libxl_event_check/wait.
+   * Events whose bit is clear in mask are not affected.
+   *
+   * event becomes owned by the application and must be freed, either
+   * by event_occurs or later.
+   *
+   * event_occurs may be NULL if mask is 0.
+   *
+   * libxl_event_register_callback also provides a way for libxl to
+   * report to the application that there was a problem reporting
+   * events; this can occur due to lack of host memory during event
+   * handling, or other wholly unrecoverable errors from system calls
+   * made by libxl.  This will not happen for frivolous reasons - only
+   * if the system, or the Xen components of it, are badly broken.
+   *
+   * msg and errnoval will describe the action that libxl was trying
+   * to do, and type specifies the type of libxl events which may be
+   * missing.  type may be 0 in which case events of all types may be
+   * missing.
+   *
+   * disaster may be NULL.  If it is, or if _register_callbacks has
+   * not been called, errors of this kind are fatal to the entire
+   * application: libxl will print messages to its logs and to stderr
+   * and call exit(-1).
+   *
+   * If disaster returns, it may be the case that some or all future
+   * libxl calls will return errors; likewise it may be the case that
+   * no more events (of the specified type, if applicable) can be
+   * produced.  An application which supplies a disaster function
+   * should normally react either by exiting, or by (when it has
+   * returned to its main event loop) shutting down libxl with
+   * libxl_ctx_free and perhaps trying to restart it with
+   * libxl_ctx_init.
+   *
+   * In any case before calling disaster, libxl will have logged a
+   * message with level XTL_CRITICAL.
+   *
+   * Reentrancy: it IS permitted to call libxl from within
+   * event_occurs.  It is NOT permitted to call libxl from within
+   * disaster.
+   *
+   * libxl_event_register_callbacks may be called as many times, with
+   * 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.
+   */
+
+
+/*
+ * Events are only generated if they have been requested.
+ * The following functions request the generation of specific events.
+ *
+ * Each set of functions for controlling event generation has this form:
+ *
+ *   typedef struct libxl__evgen_FOO libxl__evgen_FOO;
+ *   int libxl_evenable_FOO(libxl_ctx *ctx, FURTHER PARAMETERS,
+ *                          libxl_ev_user user, libxl__evgen_FOO **evgen_out);
+ *   void libxl_evdisable_FOO(libxl_ctx *ctx, libxl__evgen_FOO *evgen);
+ *
+ * The evenable function arranges that the events (as described in the
+ * doc comment for the individual function) will start to be generated
+ * by libxl.  On success, *evgen_out is set to a non-null pointer to
+ * an opaque struct.
+ *
+ * The user value is returned in the generated events and may be
+ * used by the caller for whatever it likes.  The type ev_user is
+ * guaranteed to be an unsigned integer type which is at least
+ * as big as uint64_t and is also guaranteed to be big enough to
+ * contain any intptr_t value.
+ *
+ * If it becomes desirable to stop generation of the relevant events,
+ * or to reclaim the resources in libxl associated with the evgen
+ * structure, the same evgen value should be passed to the evdisable
+ * function.  However, note that events which occurred prior to the
+ * evdisable call may still be returned.
+ *
+ * The caller may enable identical events more than once.  If they do
+ * so, each actual occurrence will generate several events to be
+ * returned by libxl_event_check, with the appropriate user value(s).
+ * Aside from this, each occurrence of each event is returned by
+ * libxl_event_check exactly once.
+ *
+ * An evgen is associated with the libxl_ctx used for its creation.
+ * After libxl_ctx_free, all corresponding evgen handles become
+ * invalid and must no longer be passed to evdisable.
+ *
+ * Events enabled with evenable prior to a fork and libxl_ctx_postfork
+ * are no longer generated after the fork/postfork; however the evgen
+ * structures are still valid and must be passed to evdisable if the
+ * memory they use should not be leaked.
+ *
+ * Applications should ensure that they eventually retrieve every
+ * event using libxl_event_check or libxl_event_wait, since events
+ * which occur but are not retreived by the application will be queued
+ * inside libxl indefinitely.  libxl_event_check/_wait may be O(n)
+ * where n is the number of queued events which do not match the
+ * criteria specified in the arguments to check/wait.
+ */
+
+typedef struct libxl__evgen_domain_death libxl_evgen_domain_death;
+int libxl_evenable_domain_death(libxl_ctx *ctx, uint32_t domid,
+                         libxl_ev_user, libxl_evgen_domain_death **evgen_out);
+void libxl_evdisable_domain_death(libxl_ctx *ctx, libxl_evgen_domain_death*);
+  /* Arranges for the generation of DOMAIN_SHUTDOWN and DOMAIN_DESTROY
+   * events.  A domain which is destroyed before it shuts down
+   * may generate only a DESTROY event.
+   */
+
+typedef struct libxl__evgen_disk_eject libxl_evgen_disk_eject;
+int libxl_evenable_disk_eject(libxl_ctx *ctx, uint32_t domid, const char *vdev,
+                        libxl_ev_user, libxl_evgen_disk_eject **evgen_out);
+void libxl_evdisable_disk_eject(libxl_ctx *ctx, libxl_evgen_disk_eject*);
+  /* Arranges for the generation of DISK_EJECT events.  A copy of the
+   * string *vdev will be made for libxl's internal use, and a pointer
+   * to this (or some other) copy will be returned as the vdev
+   * member of event.u.
+   */
+
 
 /*======================================================================*/
 
@@ -36,10 +208,10 @@
  *      poll();
  *      libxl_osevent_afterpoll(...);
  *      for (;;) {
- *        r=libxl_event_check(...);
- *        if (r==LIBXL_NOT_READY) break;
- *        if (r) handle failure;
- *        do something with the event;
+ *          r = libxl_event_check(...);
+ *          if (r==LIBXL_NOT_READY) break;
+ *          if (r) goto error_out;
+ *          do something with the event;
  *      }
  *   }
  *
diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c
index a2e5820..314ae0d 100644
--- a/tools/libxl/libxl_internal.c
+++ b/tools/libxl/libxl_internal.c
@@ -74,6 +74,12 @@ void libxl__free_all(libxl__gc *gc)
     free(gc->alloc_ptrs);
     gc->alloc_ptrs = 0;
     gc->alloc_maxsize = 0;
+
+    libxl_event *ev, *ev_tmp;
+    LIBXL_TAILQ_FOREACH_SAFE(ev, &gc->occurred_for_callback, link, ev_tmp) {
+        LIBXL_TAILQ_REMOVE(&gc->occurred_for_callback, ev, link);
+        CTX->event_hooks->event_occurs(CTX->event_hooks_user, ev);
+    }
 }
 
 void *libxl__zalloc(libxl__gc *gc, int bytes)
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 88e7dbb..518a06d 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -154,11 +154,44 @@ typedef struct libxl__ev_watch_slot {
     
 libxl__ev_xswatch *libxl__watch_slot_contents(libxl__gc *gc, int slotnum);
 
+
+/*
+ * evgen structures, which are the state we use for generating
+ * events for the caller.
+ *
+ * In general in each case there's an internal and an external
+ * version of the _evdisable_FOO function; the internal one is
+ * used during cleanup.
+ */
+
+struct libxl__evgen_domain_death {
+    uint32_t domid;
+    unsigned shutdown_reported:1, death_reported:1;
+    LIBXL_TAILQ_ENTRY(libxl_evgen_domain_death) entry;
+        /* on list .death_reported ? CTX->death_list : CTX->death_reported */
+    libxl_ev_user user;
+};
+_hidden void
+libxl__evdisable_domain_death(libxl__gc*, libxl_evgen_domain_death*);
+
+struct libxl__evgen_disk_eject {
+    libxl__ev_xswatch watch;
+    uint32_t domid;
+    libxl_ev_user user;
+    char *vdev;
+};
+_hidden void
+libxl__evdisable_disk_eject(libxl__gc*, libxl_evgen_disk_eject*);
+
+
 struct libxl__ctx {
     xentoollog_logger *lg;
     xc_interface *xch;
     struct xs_handle *xsh;
 
+    const libxl_event_hooks *event_hooks;
+    void *event_hooks_user;
+
     pthread_mutex_t lock; /* protects data structures hanging off the ctx */
       /* Always use CTX_LOCK and CTX_UNLOCK to manipulate this.
        *
@@ -171,12 +204,17 @@ struct libxl__ctx {
        * documented in the libxl public interface.
        */
 
+    LIBXL_TAILQ_HEAD(, libxl_event) occurred;
+
     int osevent_in_hook;
     const libxl_osevent_hooks *osevent_hooks;
     void *osevent_user;
       /* See the comment for OSEVENT_HOOK_INTERN in libxl_event.c
        * for restrictions on the use of the osevent fields. */
 
+    struct pollfd *fd_polls;
+    int fd_polls_allocd;
+
     int fd_beforepolled_allocd, fd_beforepolled_used;
     libxl__ev_fd **fd_beforepolled; /* see libxl_osevent_beforepoll */
     LIBXL_LIST_HEAD(, libxl__ev_fd) efds;
@@ -188,6 +226,11 @@ struct libxl__ctx {
     uint32_t watch_counter; /* helps disambiguate slot reuse */
     libxl__ev_fd watch_efd;
 
+    LIBXL_TAILQ_HEAD(libxl__evgen_domain_death_list, libxl_evgen_domain_death)
+        death_list /* sorted by domid */,
+        death_reported;
+    libxl__ev_xswatch death_watch;
+    
     /* for callers who reap children willy-nilly; caller must only
      * set this after libxl_init and before any other call - or
      * may leave them untouched */
@@ -223,12 +266,14 @@ struct libxl__gc {
     int alloc_maxsize;
     void **alloc_ptrs;
     libxl_ctx *owner;
+    LIBXL_TAILQ_HEAD(, libxl_event) occurred_for_callback;
 };
 
-#define LIBXL_INIT_GC(gc,ctx) do{               \
-        (gc).alloc_maxsize = 0;                 \
-        (gc).alloc_ptrs = 0;                    \
-        (gc).owner = (ctx);                     \
+#define LIBXL_INIT_GC(gc,ctx) do{                       \
+        (gc).alloc_maxsize = 0;                         \
+        (gc).alloc_ptrs = 0;                            \
+        (gc).owner = (ctx);                             \
+        LIBXL_TAILQ_INIT(&(gc).occurred_for_callback);  \
     } while(0)
 
 static inline libxl_ctx *libxl__gc_owner(libxl__gc *gc)
@@ -250,7 +295,9 @@ static inline libxl_ctx *libxl__gc_owner(libxl__gc *gc)
  */
 /* register @ptr in @gc for free on exit from outermost libxl callframe. */
 _hidden int libxl__ptr_add(libxl__gc *gc, void *ptr);
-/* if this is the outermost libxl callframe then free all pointers in @gc */
+/* if this is the outermost libxl callframe then free all pointers in @gc
+ *  and report all occurred events via callback, if applicable.
+ * May reenters the application so must not be called with ctx locked. */
 _hidden void libxl__free_all(libxl__gc *gc);
 /* allocate and zero @bytes. (similar to a gc'd malloc(3)+memzero()) */
 _hidden void *libxl__zalloc(libxl__gc *gc, int bytes);
@@ -400,6 +447,25 @@ static inline int libxl__ev_xswatch_isregistered(const libxl__ev_xswatch *xw)
 
 
 
+/*
+ * Other event-handling support provided by the libxl event core to
+ * the rest of libxl.
+ */
+
+_hidden void libxl__event_occurred(libxl__gc*, libxl_event *event);
+  /* Arranges to notify the application that the event has occurred.
+   * event should be suitable for passing to libxl_event_free. */
+
+_hidden libxl_event *libxl__event_new(libxl__gc*, libxl_event_type,
+                                      uint32_t domid);
+  /* Convenience function.
+   * Allocates a new libxl_event, fills in domid and type.
+   * If allocation fails, calls _disaster, and returns NULL. */
+
+#define NEW_EVENT(gc, type, domid)                              \
+    libxl__event_new((gc), LIBXL_EVENT_TYPE_##type, (domid));
+    /* Convenience macro. */
+
 _hidden void libxl__event_disaster(libxl__gc*, const char *msg, int errnoval,
                                    libxl_event_type type /* may be 0 */,
                                    const char *file, int line,
@@ -412,6 +478,9 @@ _hidden void libxl__event_disaster(libxl__gc*, const char *msg, int errnoval,
    * libxl__ev_FOO_callback or an application event), but are
    * prevented from doing so due to eg lack of memory.
    *
+   * See the "disaster" member of libxl_event_hooks and associated
+   * comment in libxl_event.h.
+   *
    * NB that this function may return and the caller isn't supposed to
    * then crash, although it may fail (and henceforth leave things in
    * a state where many or all calls fail).
@@ -892,7 +961,7 @@ libxl__device_model_version_running(libxl__gc *gc, uint32_t domid);
  */
 
 #define GC_INIT(ctx)  libxl__gc gc[1]; LIBXL_INIT_GC(gc[0],ctx)
-#define GC_FREE       libxl__free_all(gc)
+#define GC_FREE       libxl__free_all(gc) /* MUST NOT CALL WITH CTX LOCKED */
 #define CTX           libxl__gc_owner(gc)
 
 
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index d59d2cb..5a713f0 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -75,11 +75,6 @@ libxl_action_on_shutdown = Enumeration("action_on_shutdown", [
     (6, "COREDUMP_RESTART"),
     ])
 
-libxl_event_type = Enumeration("event_type", [
-    (1, "DOMAIN_DEATH"),
-    (2, "DISK_EJECT"),
-    ])
-
 libxl_button = Enumeration("button", [
     (1, "POWER"),
     (2, "SLEEP"),
@@ -381,3 +376,33 @@ libxl_sched_credit = Struct("sched_credit", [
     ("weight", integer),
     ("cap", integer),
     ], dispose_fn=None)
+
+libxl_event_type = Enumeration("event_type", [
+    (1, "DOMAIN_SHUTDOWN"),
+    (2, "DOMAIN_DESTROY"),
+    (3, "DISK_EJECT"),
+    ])
+
+libxl_ev_user = Number("libxl_ev_user")
+
+libxl_ev_link = Builtin("ev_link", passby=PASS_BY_REFERENCE, private=True)
+
+libxl_event = Struct("event",[
+    ("link",     libxl_ev_link,0,
+     "for use by libxl; caller may use this once the event has been"
+     " returned by libxl_event_{check,wait}"),
+    ("domid",    libxl_domid),
+    ("domuuid",  libxl_uuid),
+    ("for_user", libxl_ev_user),
+    ("type",     libxl_event_type),
+    ("u", KeyedUnion(None, libxl_event_type, "type",
+          [("domain_shutdown", Struct(None, [
+                                             ("shutdown_reason", uint8),
+                                      ])),
+           ("domain_destroy", Struct(None, [])),
+           ("disk_eject", Struct(None, [
+                                        ("vdev", string),
+                                        ("disk", libxl_device_disk),
+                                 ])),
+           ]))])
+
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index f1e729c..e5738b7 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -1221,14 +1221,16 @@ skip_vfb:
     xlu_cfg_destroy(config);
 }
 
-/* Returns 1 if domain should be restarted, 2 if domain should be renamed then restarted  */
-static int handle_domain_death(libxl_ctx *ctx, uint32_t domid, libxl_event *event,
-                               libxl_domain_config *d_config, libxl_dominfo *info)
+/* Returns 1 if domain should be restarted,
+ * 2 if domain should be renamed then restarted, or 0 */
+static int handle_domain_death(libxl_ctx *ctx, uint32_t domid,
+                               libxl_event *event,
+                               libxl_domain_config *d_config)
 {
     int restart = 0;
     libxl_action_on_shutdown action;
 
-    switch (info->shutdown_reason) {
+    switch (event->u.domain_shutdown.shutdown_reason) {
     case SHUTDOWN_poweroff:
         action = d_config->on_poweroff;
         break;
@@ -1245,11 +1247,14 @@ static int handle_domain_death(libxl_ctx *ctx, uint32_t domid, libxl_event *even
         action = d_config->on_watchdog;
         break;
     default:
-        LOG("Unknown shutdown reason code %d. Destroying domain.", info->shutdown_reason);
+        LOG("Unknown shutdown reason code %d. Destroying domain.",
+            event->u.domain_shutdown.shutdown_reason);
         action = LIBXL_ACTION_ON_SHUTDOWN_DESTROY;
     }
 
-    LOG("Action for shutdown reason code %d is %s", info->shutdown_reason, action_on_shutdown_names[action]);
+    LOG("Action for shutdown reason code %d is %s",
+        event->u.domain_shutdown.shutdown_reason,
+        action_on_shutdown_names[action]);
 
     if (action == LIBXL_ACTION_ON_SHUTDOWN_COREDUMP_DESTROY || action == LIBXL_ACTION_ON_SHUTDOWN_COREDUMP_RESTART) {
         char *corefile;
@@ -1314,7 +1319,7 @@ static void replace_string(char **str, const char *val)
 
 
 static int preserve_domain(libxl_ctx *ctx, uint32_t domid, libxl_event *event,
-                           libxl_domain_config *d_config, libxl_dominfo *info)
+                           libxl_domain_config *d_config)
 {
     time_t now;
     struct tm tm;
@@ -1426,6 +1431,27 @@ static int autoconnect_console(libxl_ctx *ctx, uint32_t domid, void *priv)
     _exit(1);
 }
 
+static int domain_wait_event(libxl_event **event_r) {
+    int ret;
+    for (;;) {
+        ret = libxl_event_wait(ctx, event_r, LIBXL_EVENTMASK_ALL, 0,0);
+        if (ret) {
+            LOG("Domain %d, failed to get event, quitting (rc=%d)", domid, ret);
+            return ret;
+        }
+        if ((*event_r)->domid != domid) {
+            char *evstr = libxl_event_to_json(ctx, *event_r);
+            LOG("INTERNAL PROBLEM - ignoring unexpected event for"
+                " domain %d (expected %d): event=%s",
+                (*event_r)->domid, domid, evstr);
+            free(evstr);
+            libxl_event_free(ctx, *event_r);
+            continue;
+        }
+        return ret;
+    }
+}
+
 static int create_domain(struct domain_create *dom_info)
 {
     libxl_domain_config d_config;
@@ -1439,10 +1465,11 @@ static int create_domain(struct domain_create *dom_info)
     const char *restore_file = dom_info->restore_file;
     int migrate_fd = dom_info->migrate_fd;
 
-    int fd, i;
+    int i;
     int need_daemon = daemonize;
     int ret, rc;
-    libxl_waiter *w1 = NULL, *w2 = NULL;
+    libxl_evgen_domain_death *deathw = NULL;
+    libxl_evgen_disk_eject **diskws = NULL; /* one per disk */
     void *config_data = 0;
     int config_len = 0;
     int restore_fd = -1;
@@ -1647,14 +1674,14 @@ start:
                 if (errno != EINTR) {
                     perror("failed to wait for daemonizing child");
                     ret = ERROR_FAIL;
-                    goto error_out;
+                    goto out;
                 }
             }
             if (status) {
                 libxl_report_child_exitstatus(ctx, XTL_ERROR,
                            "daemonizing child", child1, status);
                 ret = ERROR_FAIL;
-                goto error_out;
+                goto out;
             }
             ret = domid;
             goto out;
@@ -1691,92 +1718,106 @@ start:
     }
     LOG("Waiting for domain %s (domid %d) to die [pid %ld]",
         d_config.c_info.name, domid, (long)getpid());
-    w1 = (libxl_waiter*) xmalloc(sizeof(libxl_waiter) * d_config.num_disks);
-    w2 = (libxl_waiter*) xmalloc(sizeof(libxl_waiter));
-    libxl_wait_for_disk_ejects(ctx, domid, d_config.disks, d_config.num_disks, w1);
-    libxl_wait_for_domain_death(ctx, domid, w2);
-    libxl_get_wait_fd(ctx, &fd);
-    while (1) {
-        int ret;
-        fd_set rfds;
-        libxl_dominfo info;
-        libxl_event event;
-        libxl_device_disk disk;
 
-        FD_ZERO(&rfds);
-        FD_SET(fd, &rfds);
+    ret = libxl_evenable_domain_death(ctx, domid, 0, &deathw);
+    if (ret) goto out;
 
-        ret = select(fd + 1, &rfds, NULL, NULL, NULL);
-        if (!ret)
-            continue;
-        libxl_get_event(ctx, &event);
-        switch (event.type) {
-            case LIBXL_EVENT_TYPE_DOMAIN_DEATH:
-                ret = libxl_event_get_domain_death_info(ctx, domid, &event, &info);
-
-                if (ret < 0) {
-                    libxl_free_event(&event);
-                    continue;
+    if (!diskws) {
+        diskws = xmalloc(sizeof(*diskws) * d_config.num_disks);
+        for (i = 0; i < d_config.num_disks; i++)
+            diskws[i] = NULL;
+    }
+    for (i = 0; i < d_config.num_disks; i++) {
+        ret = libxl_evenable_disk_eject(ctx, domid, d_config.disks[i].vdev,
+                                        0, &diskws[i]);
+        if (ret) goto out;
+    }
+    while (1) {
+        libxl_event *event;
+        ret = domain_wait_event(&event);
+        if (ret) goto out;
+
+        switch (event->type) {
+
+        case LIBXL_EVENT_TYPE_DOMAIN_SHUTDOWN:
+            LOG("Domain %d has shut down, reason code %d 0x%x", domid,
+                event->u.domain_shutdown.shutdown_reason,
+                event->u.domain_shutdown.shutdown_reason);
+            switch (handle_domain_death(ctx, domid, event, &d_config)) {
+            case 2:
+                if (!preserve_domain(ctx, domid, event, &d_config)) {
+                    /* If we fail then exit leaving the old domain in place. */
+                    ret = -1;
+                    goto out;
                 }
 
-                LOG("Domain %d is dead", domid);
-
-                if (ret) {
-                    switch (handle_domain_death(ctx, domid, &event, &d_config, &info)) {
-                    case 2:
-                        if (!preserve_domain(ctx, domid, &event, &d_config, &info)) {
-                            /* If we fail then exit leaving the old domain in place. */
-                            ret = -1;
-                            goto out;
-                        }
-
-                        /* Otherwise fall through and restart. */
-                    case 1:
-
-                        for (i = 0; i < d_config.num_disks; i++)
-                            libxl_free_waiter(&w1[i]);
-                        libxl_free_waiter(w2);
-                        free(w1);
-                        free(w2);
-
-                        /*
-                         * Do not attempt to reconnect if we come round again due to a
-                         * guest reboot -- the stdin/out will be disconnected by then.
-                         */
-                        dom_info->console_autoconnect = 0;
-
-                        /* Some settings only make sense on first boot. */
-                        paused = 0;
-                        if (common_domname
-                            && strcmp(d_config.c_info.name, common_domname)) {
-                            d_config.c_info.name = strdup(common_domname);
-                        }
-
-                        /*
-                         * XXX FIXME: If this sleep is not there then domain
-                         * re-creation fails sometimes.
-                         */
-                        LOG("Done. Rebooting now");
-                        sleep(2);
-                        goto start;
-                    case 0:
-                        LOG("Done. Exiting now");
-                        ret = 0;
-                        goto out;
-                    }
-                } else {
-                    LOG("Unable to get domain death info, quitting");
-                    goto out;
+                /* Otherwise fall through and restart. */
+            case 1:
+                libxl_event_free(ctx, event);
+                libxl_evdisable_domain_death(ctx, deathw);
+                deathw = NULL;
+                for (i = 0; i < d_config.num_disks; i++) {
+                    libxl_evdisable_disk_eject(ctx, diskws[i]);
+                    diskws[i] = NULL;
                 }
-                break;
-            case LIBXL_EVENT_TYPE_DISK_EJECT:
-                if (libxl_event_get_disk_eject_info(ctx, domid, &event, &disk)) {
-                    libxl_cdrom_insert(ctx, domid, &disk);
-                    libxl_device_disk_dispose(&disk);
+                /* discard any other events which may have been generated */
+                while (!(ret = libxl_event_check(ctx, &event,
+                                                 LIBXL_EVENTMASK_ALL, 0,0))) {
+                    libxl_event_free(ctx, event);
                 }
-                break;
+                if (ret != ERROR_NOT_READY) {
+                    LOG("warning, libxl_event_check (cleanup) failed (rc=%d)",
+                        ret);
+                }
+
+                /*
+                 * Do not attempt to reconnect if we come round again due to a
+                 * guest reboot -- the stdin/out will be disconnected by then.
+                 */
+                dom_info->console_autoconnect = 0;
+
+                /* Some settings only make sense on first boot. */
+                paused = 0;
+                if (common_domname
+                    && strcmp(d_config.c_info.name, common_domname)) {
+                    d_config.c_info.name = strdup(common_domname);
+                }
+
+                /*
+                 * XXX FIXME: If this sleep is not there then domain
+                 * re-creation fails sometimes.
+                 */
+                LOG("Done. Rebooting now");
+                sleep(2);
+                goto start;
+
+            case 0:
+                LOG("Done. Exiting now");
+                ret = 0;
+                goto out;
+
+            default:
+                abort();
+            }
+
+        case LIBXL_EVENT_TYPE_DOMAIN_DESTROY:
+            LOG("Domain %d has been destroyed.", domid);
+            ret = 0;
+            goto out;
+
+        case LIBXL_EVENT_TYPE_DISK_EJECT:
+            /* XXX what is this for? */
+            libxl_cdrom_insert(ctx, domid, &event->u.disk_eject.disk);
+            break;
+
+        default:;
+            char *evstr = libxl_event_to_json(ctx, event);
+            LOG("warning, got unexpected event type %d, event=%s",
+                event->type, evstr);
+            free(evstr);
         }
-        libxl_free_event(&event);
+
+        libxl_event_free(ctx, event);
     }
 
 error_out:
@@ -2259,43 +2300,46 @@ static void destroy_domain(const char *p)
 static void shutdown_domain(const char *p, int wait)
 {
     int rc;
+    libxl_event *event;
 
     find_domain(p);
     rc=libxl_domain_shutdown(ctx, domid, 0);
     if (rc) { fprintf(stderr,"shutdown failed (rc=%d)\n",rc);exit(-1); }
 
     if (wait) {
-        libxl_waiter waiter;
-        int fd;
-
-        libxl_wait_for_domain_death(ctx, domid, &waiter);
+        libxl_evgen_domain_death *deathw;
 
-        libxl_get_wait_fd(ctx, &fd);
-
-        while (wait) {
-            fd_set rfds;
-            libxl_event event;
-            libxl_dominfo info;
+        rc = libxl_evenable_domain_death(ctx, domid, 0, &deathw);
+        if (rc) {
+            fprintf(stderr,"wait for death failed (evgen, rc=%d)\n",rc);
+            exit(-1);
+        }
 
-            FD_ZERO(&rfds);
-            FD_SET(fd, &rfds);
+        for (;;) {
+            rc = domain_wait_event(&event);
+            if (rc) exit(-1);
 
-            if (!select(fd + 1, &rfds, NULL, NULL, NULL))
-                continue;
+            switch (event->type) {
 
-            libxl_get_event(ctx, &event);
+            case LIBXL_EVENT_TYPE_DOMAIN_DESTROY:
+                LOG("Domain %d has been destroyed", domid);
+                goto done;
 
-            if (event.type == LIBXL_EVENT_TYPE_DOMAIN_DEATH) {
-                if (libxl_event_get_domain_death_info(ctx, domid, &event, &info) < 0)
-                    continue;
+            case LIBXL_EVENT_TYPE_DOMAIN_SHUTDOWN:
+                LOG("Domain %d has been shut down, reason code %d %x", domid,
+                    event->u.domain_shutdown.shutdown_reason,
+                    event->u.domain_shutdown.shutdown_reason);
+                goto done;
 
-                LOG("Domain %d is dead", domid);
-                wait = 0;
+            default:
+                LOG("Unexpected event type %d", event->type);
+                break;
             }
-
-            libxl_free_event(&event);
+            libxl_event_free(ctx, event);
         }
-        libxl_free_waiter(&waiter);
+    done:
+        libxl_event_free(ctx, event);
+        libxl_evdisable_domain_death(ctx, deathw);
     }
 }
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 18:11:31 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 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.xensource.com>)
	id 1RXd0T-00066s-FL; Mon, 05 Dec 2011 18:11:13 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RXd0R-00065n-Bf
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 18:11:11 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1323108624!1307875!4
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjAyNg==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27155 invoked from network); 5 Dec 2011 18:10:26 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Dec 2011 18:10:26 -0000
X-IronPort-AV: E=Sophos;i="4.71,300,1320624000"; 
   d="scan'208";a="9297522"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Dec 2011 18:10:26 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 5 Dec 2011 18:10:26 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RXczi-0003k0-0j; Mon, 05 Dec 2011 18:10:26 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RXczh-0006W1-W4;
	Mon, 05 Dec 2011 18:10:25 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Mon, 5 Dec 2011 18:10:09 +0000
Message-ID: <1323108621-22654-4-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1323108621-22654-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1323108621-22654-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 03/15] libxl: Provide a version of bsd's queue.h
	as _libxl_list.h
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

We would like some linked list macros which are (a) well known to be
sane and (b) typesafe.  BSD's queue.h meets these criteria.

We also provide some simple perlery to arrange to add the libxl_
namespace prefix to the macros.  This will allow us to #include
_libxl_list.h in our public header file without clashing with anyone
else who is also using another version of queue.h.

(A note on copyright: The FreeBSD files we are adding have an
[L]GPL-compatible licence, so there is no need to change our COPYING.
Although FreeBSD's queue.3 still contains the advertising clause, this
has been withdrawn by UCB as recorded in the FreeBSD COPYRIGHT file,
which is included in tools/libxl/external/ for reference.)

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <Ian.campbell@citrix.com>
Tested-by: Roger Pau Monne <roger.pau@entel.upc.edu>
---
 tools/libxl/Makefile                 |   10 +-
 tools/libxl/bsd-sys-queue-h-seddery  |   70 +++
 tools/libxl/external/README          |   14 +
 tools/libxl/external/bsd-COPYRIGHT   |  126 ++++
 tools/libxl/external/bsd-queue.3     | 1044 ++++++++++++++++++++++++++++++++++
 tools/libxl/external/bsd-sys-queue.h |  637 +++++++++++++++++++++
 6 files changed, 1898 insertions(+), 3 deletions(-)
 create mode 100755 tools/libxl/bsd-sys-queue-h-seddery
 create mode 100644 tools/libxl/external/README
 create mode 100644 tools/libxl/external/bsd-COPYRIGHT
 create mode 100644 tools/libxl/external/bsd-queue.3
 create mode 100644 tools/libxl/external/bsd-sys-queue.h

diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index a7a4625..f363da2 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -42,7 +42,7 @@ LIBXL_OBJS += _libxl_types.o libxl_flask.o _libxl_types_internal.o
 
 $(LIBXL_OBJS): CFLAGS += $(CFLAGS_libxenctrl) $(CFLAGS_libxenguest) $(CFLAGS_libxenstore) $(CFLAGS_libblktapctl)
 
-AUTOINCS= libxlu_cfg_y.h libxlu_cfg_l.h
+AUTOINCS= libxlu_cfg_y.h libxlu_cfg_l.h _libxl_list.h
 AUTOSRCS= libxlu_cfg_y.c libxlu_cfg_l.c
 LIBXLU_OBJS = libxlu_cfg_y.o libxlu_cfg_l.o libxlu_cfg.o \
 	libxlu_disk_l.o libxlu_disk.o
@@ -55,7 +55,7 @@ $(XL_OBJS): CFLAGS += $(CFLAGS_libxenctrl) # For xentoollog.h
 $(XL_OBJS): CFLAGS += $(CFLAGS_libxenlight)
 
 testidl.o: CFLAGS += $(CFLAGS_libxenctrl) $(CFLAGS_libxenlight)
-testidl.c: libxl_types.idl gentest.py libxl.h
+testidl.c: libxl_types.idl gentest.py libxl.h $(AUTOINCS)
 	$(PYTHON) gentest.py libxl_types.idl testidl.c.new
 	mv testidl.c.new testidl.c
 
@@ -63,7 +63,7 @@ testidl.c: libxl_types.idl gentest.py libxl.h
 all: $(CLIENTS) libxenlight.so libxenlight.a libxlutil.so libxlutil.a \
 	$(AUTOSRCS) $(AUTOINCS)
 
-$(LIBXLU_OBJS): $(AUTOINCS)
+$(LIBXL_OBJS) $(LIBXLU_OBJS) $(XL_OBJS): $(AUTOINCS)
 
 %.c %.h: %.y
 	@rm -f $*.[ch]
@@ -81,6 +81,10 @@ _libxl_paths.h: genpath
 	rm -f $@.tmp
 	$(call move-if-changed,$@.2.tmp,$@)
 
+_libxl_list.h: bsd-sys-queue-h-seddery external/bsd-sys-queue.h
+	perl ./$^ --prefix=libxl >$@.new
+	$(call move-if-changed,$@.new,$@)
+
 libxl_paths.c: _libxl_paths.h
 
 libxl.h: _libxl_types.h
diff --git a/tools/libxl/bsd-sys-queue-h-seddery b/tools/libxl/bsd-sys-queue-h-seddery
new file mode 100755
index 0000000..c0aa079
--- /dev/null
+++ b/tools/libxl/bsd-sys-queue-h-seddery
@@ -0,0 +1,70 @@
+#!/usr/bin/perl -p
+#
+# This script is part of the Xen build system.  It has a very
+# permissive licence to avoid complicating the licence of the
+# generated header file and to allow this seddery to be reused by
+# other projects.
+#
+# Permission is hereby granted, free of charge, to any person
+# obtaining a copy of this individual 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.
+#
+# Copyright (C) 2011 Citrix Ltd
+
+our $namespace, $ucnamespace;
+
+BEGIN {
+    die unless @ARGV;
+    $namespace = pop @ARGV;
+    $namespace =~ s/^--prefix=// or die;
+    $ucnamespace = uc $namespace;
+
+    print <<END or die $!;
+/*
+ * DO NOT EDIT THIS FILE
+ *
+ * Generated automatically by bsd-sys-queue-h-seddery to
+ *  - introduce ${ucnamespace}_ and ${namespace}_ namespace prefixes
+ *  - turn "struct type" into "type" so that type arguments
+ *     to the macros are type names not struct tags
+ *  - remove the reference to sys/cdefs.h, which is not needed
+ *
+ * The purpose of this seddery is to allow the resulting file to be
+ * freely included by software which might also want to include other
+ * list macros; to make it usable when struct tags are not being used
+ * or not known; to make it more portable.
+ */
+END
+}
+
+s/\b( _SYS_QUEUE |
+      SLIST | LIST | STAILQ | TAILQ | QUEUE
+      )/${ucnamespace}_$1/xg;
+
+s/\b( TRACEBUF | TRASHIT |
+      QMD_
+      )/${ucnamespace}__$1/xg;
+
+s/\b(
+      qm_
+      )/${namespace}__$1/xg;
+
+s/\b struct \s+ type \b/type/xg;
+
+s,^\#include.*sys/cdefs.*,/* $& */,xg;
diff --git a/tools/libxl/external/README b/tools/libxl/external/README
new file mode 100644
index 0000000..8c8beea
--- /dev/null
+++ b/tools/libxl/external/README
@@ -0,0 +1,14 @@
+WARNING - DO NOT EDIT THINGS IN THIS DIRECTORY (apart from this README)
+-----------------------------------------------------------------------
+
+These files were obtained elsewhere and should only be updated by
+copying new versions from the source location, as documented below:
+
+bsd-COPYRIGHT
+bsd-sys-queue.h
+bsd-queue.3
+
+  Obtained from the FreeBSD SVN using the following commands:
+    svn co -r 221843 svn://svn.freebsd.org/base/head/sys/sys/
+    svn co -r 221843 svn://svn.freebsd.org/base/head/share/man/man3
+    svn cat -r 221843 http://svn.freebsd.org/base/head/COPYRIGHT >tools/libxl/external/bsd-COPYRIGHT
diff --git a/tools/libxl/external/bsd-COPYRIGHT b/tools/libxl/external/bsd-COPYRIGHT
new file mode 100644
index 0000000..6dc5d16
--- /dev/null
+++ b/tools/libxl/external/bsd-COPYRIGHT
@@ -0,0 +1,126 @@
+# $FreeBSD$
+#	@(#)COPYRIGHT	8.2 (Berkeley) 3/21/94
+
+The compilation of software known as FreeBSD is distributed under the
+following terms:
+
+Copyright (c) 1992-2011 The FreeBSD Project. All rights reserved.
+
+Redistribution and use in source and binary forms, with or without
+modification, are permitted provided that the following conditions
+are met:
+1. Redistributions of source code must retain the above copyright
+   notice, this list of conditions and the following disclaimer.
+2. Redistributions in binary form must reproduce the above copyright
+   notice, this list of conditions and the following disclaimer in the
+   documentation and/or other materials provided with the distribution.
+
+THIS SOFTWARE IS PROVIDED BY THE 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 THE 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.
+
+The 4.4BSD and 4.4BSD-Lite software is distributed under the following
+terms:
+
+All of the documentation and software included in the 4.4BSD and 4.4BSD-Lite
+Releases is copyrighted by The Regents of the University of California.
+
+Copyright 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
+	The Regents of the University of California.  All rights reserved.
+
+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.
+3. All advertising materials mentioning features or use of this software
+   must display the following acknowledgement:
+This product includes software developed by the University of
+California, Berkeley and its contributors.
+4. Neither the name of the University 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 REGENTS 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 REGENTS 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.
+
+The Institute of Electrical and Electronics Engineers and the American
+National Standards Committee X3, on Information Processing Systems have
+given us permission to reprint portions of their documentation.
+
+In the following statement, the phrase ``this text'' refers to portions
+of the system documentation.
+
+Portions of this text are reprinted and reproduced in electronic form in
+the second BSD Networking Software Release, from IEEE Std 1003.1-1988, IEEE
+Standard Portable Operating System Interface for Computer Environments
+(POSIX), copyright C 1988 by the Institute of Electrical and Electronics
+Engineers, Inc.  In the event of any discrepancy between these versions
+and the original IEEE Standard, the original IEEE Standard is the referee
+document.
+
+In the following statement, the phrase ``This material'' refers to portions
+of the system documentation.
+
+This material is reproduced with permission from American National
+Standards Committee X3, on Information Processing Systems.  Computer and
+Business Equipment Manufacturers Association (CBEMA), 311 First St., NW,
+Suite 500, Washington, DC 20001-2178.  The developmental work of
+Programming Language C was completed by the X3J11 Technical Committee.
+
+The views and conclusions contained in the software and documentation are
+those of the authors and should not be interpreted as representing official
+policies, either expressed or implied, of the Regents of the University
+of California.
+
+
+NOTE: The copyright of UC Berkeley's Berkeley Software Distribution ("BSD")
+source has been updated.  The copyright addendum may be found at
+ftp://ftp.cs.berkeley.edu/pub/4bsd/README.Impt.License.Change and is
+included below.
+
+July 22, 1999
+
+To All Licensees, Distributors of Any Version of BSD:
+
+As you know, certain of the Berkeley Software Distribution ("BSD") source
+code files require that further distributions of products containing all or
+portions of the software, acknowledge within their advertising materials
+that such products contain software developed by UC Berkeley and its
+contributors.
+
+Specifically, the provision reads:
+
+"     * 3. All advertising materials mentioning features or use of this software
+      *    must display the following acknowledgement:
+      *    This product includes software developed by the University of
+      *    California, Berkeley and its contributors."
+
+Effective immediately, licensees and distributors are no longer required to
+include the acknowledgement within advertising materials.  Accordingly, the
+foregoing paragraph of those BSD Unix files containing it is hereby deleted
+in its entirety.
+
+William Hoskins
+Director, Office of Technology Licensing
+University of California, Berkeley
diff --git a/tools/libxl/external/bsd-queue.3 b/tools/libxl/external/bsd-queue.3
new file mode 100644
index 0000000..007ca5c
--- /dev/null
+++ b/tools/libxl/external/bsd-queue.3
@@ -0,0 +1,1044 @@
+.\" Copyright (c) 1993
+.\"	The Regents of the University of California.  All rights reserved.
+.\"
+.\" 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.
+.\" 3. All advertising materials mentioning features or use of this software
+.\"    must display the following acknowledgement:
+.\"	This product includes software developed by the University of
+.\"	California, Berkeley and its contributors.
+.\" 4. Neither the name of the University 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 REGENTS 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 REGENTS 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.
+.\"
+.\"	@(#)queue.3	8.2 (Berkeley) 1/24/94
+.\" $FreeBSD$
+.\"
+.Dd May 13, 2011
+.Dt QUEUE 3
+.Os
+.Sh NAME
+.Nm SLIST_EMPTY ,
+.Nm SLIST_ENTRY ,
+.Nm SLIST_FIRST ,
+.Nm SLIST_FOREACH ,
+.Nm SLIST_FOREACH_SAFE ,
+.Nm SLIST_HEAD ,
+.Nm SLIST_HEAD_INITIALIZER ,
+.Nm SLIST_INIT ,
+.Nm SLIST_INSERT_AFTER ,
+.Nm SLIST_INSERT_HEAD ,
+.Nm SLIST_NEXT ,
+.Nm SLIST_REMOVE_AFTER ,
+.Nm SLIST_REMOVE_HEAD ,
+.Nm SLIST_REMOVE ,
+.Nm SLIST_SWAP ,
+.Nm STAILQ_CONCAT ,
+.Nm STAILQ_EMPTY ,
+.Nm STAILQ_ENTRY ,
+.Nm STAILQ_FIRST ,
+.Nm STAILQ_FOREACH ,
+.Nm STAILQ_FOREACH_SAFE ,
+.Nm STAILQ_HEAD ,
+.Nm STAILQ_HEAD_INITIALIZER ,
+.Nm STAILQ_INIT ,
+.Nm STAILQ_INSERT_AFTER ,
+.Nm STAILQ_INSERT_HEAD ,
+.Nm STAILQ_INSERT_TAIL ,
+.Nm STAILQ_LAST ,
+.Nm STAILQ_NEXT ,
+.Nm STAILQ_REMOVE_AFTER ,
+.Nm STAILQ_REMOVE_HEAD ,
+.Nm STAILQ_REMOVE ,
+.Nm STAILQ_SWAP ,
+.Nm LIST_EMPTY ,
+.Nm LIST_ENTRY ,
+.Nm LIST_FIRST ,
+.Nm LIST_FOREACH ,
+.Nm LIST_FOREACH_SAFE ,
+.Nm LIST_HEAD ,
+.Nm LIST_HEAD_INITIALIZER ,
+.Nm LIST_INIT ,
+.Nm LIST_INSERT_AFTER ,
+.Nm LIST_INSERT_BEFORE ,
+.Nm LIST_INSERT_HEAD ,
+.Nm LIST_NEXT ,
+.Nm LIST_REMOVE ,
+.Nm LIST_SWAP ,
+.Nm TAILQ_CONCAT ,
+.Nm TAILQ_EMPTY ,
+.Nm TAILQ_ENTRY ,
+.Nm TAILQ_FIRST ,
+.Nm TAILQ_FOREACH ,
+.Nm TAILQ_FOREACH_SAFE ,
+.Nm TAILQ_FOREACH_REVERSE ,
+.Nm TAILQ_FOREACH_REVERSE_SAFE ,
+.Nm TAILQ_HEAD ,
+.Nm TAILQ_HEAD_INITIALIZER ,
+.Nm TAILQ_INIT ,
+.Nm TAILQ_INSERT_AFTER ,
+.Nm TAILQ_INSERT_BEFORE ,
+.Nm TAILQ_INSERT_HEAD ,
+.Nm TAILQ_INSERT_TAIL ,
+.Nm TAILQ_LAST ,
+.Nm TAILQ_NEXT ,
+.Nm TAILQ_PREV ,
+.Nm TAILQ_REMOVE ,
+.Nm TAILQ_SWAP
+.Nd implementations of singly-linked lists, singly-linked tail queues,
+lists and tail queues
+.Sh SYNOPSIS
+.In sys/queue.h
+.\"
+.Fn SLIST_EMPTY "SLIST_HEAD *head"
+.Fn SLIST_ENTRY "TYPE"
+.Fn SLIST_FIRST "SLIST_HEAD *head"
+.Fn SLIST_FOREACH "TYPE *var" "SLIST_HEAD *head" "SLIST_ENTRY NAME"
+.Fn SLIST_FOREACH_SAFE "TYPE *var" "SLIST_HEAD *head" "SLIST_ENTRY NAME" "TYPE *temp_var"
+.Fn SLIST_HEAD "HEADNAME" "TYPE"
+.Fn SLIST_HEAD_INITIALIZER "SLIST_HEAD head"
+.Fn SLIST_INIT "SLIST_HEAD *head"
+.Fn SLIST_INSERT_AFTER "TYPE *listelm" "TYPE *elm" "SLIST_ENTRY NAME"
+.Fn SLIST_INSERT_HEAD "SLIST_HEAD *head" "TYPE *elm" "SLIST_ENTRY NAME"
+.Fn SLIST_NEXT "TYPE *elm" "SLIST_ENTRY NAME"
+.Fn SLIST_REMOVE_AFTER "TYPE *elm" "SLIST_ENTRY NAME"
+.Fn SLIST_REMOVE_HEAD "SLIST_HEAD *head" "SLIST_ENTRY NAME"
+.Fn SLIST_REMOVE "SLIST_HEAD *head" "TYPE *elm" "TYPE" "SLIST_ENTRY NAME"
+.Fn SLIST_SWAP "SLIST_HEAD *head1" "SLIST_HEAD *head2" "SLIST_ENTRY NAME"
+.\"
+.Fn STAILQ_CONCAT "STAILQ_HEAD *head1" "STAILQ_HEAD *head2"
+.Fn STAILQ_EMPTY "STAILQ_HEAD *head"
+.Fn STAILQ_ENTRY "TYPE"
+.Fn STAILQ_FIRST "STAILQ_HEAD *head"
+.Fn STAILQ_FOREACH "TYPE *var" "STAILQ_HEAD *head" "STAILQ_ENTRY NAME"
+.Fn STAILQ_FOREACH_SAFE "TYPE *var" "STAILQ_HEAD *head" "STAILQ_ENTRY NAME" "TYPE *temp_var"
+.Fn STAILQ_HEAD "HEADNAME" "TYPE"
+.Fn STAILQ_HEAD_INITIALIZER "STAILQ_HEAD head"
+.Fn STAILQ_INIT "STAILQ_HEAD *head"
+.Fn STAILQ_INSERT_AFTER "STAILQ_HEAD *head" "TYPE *listelm" "TYPE *elm" "STAILQ_ENTRY NAME"
+.Fn STAILQ_INSERT_HEAD "STAILQ_HEAD *head" "TYPE *elm" "STAILQ_ENTRY NAME"
+.Fn STAILQ_INSERT_TAIL "STAILQ_HEAD *head" "TYPE *elm" "STAILQ_ENTRY NAME"
+.Fn STAILQ_LAST "STAILQ_HEAD *head" "TYPE" "STAILQ_ENTRY NAME"
+.Fn STAILQ_NEXT "TYPE *elm" "STAILQ_ENTRY NAME"
+.Fn STAILQ_REMOVE_AFTER "STAILQ_HEAD *head" "TYPE *elm" "STAILQ_ENTRY NAME"
+.Fn STAILQ_REMOVE_HEAD "STAILQ_HEAD *head" "STAILQ_ENTRY NAME"
+.Fn STAILQ_REMOVE "STAILQ_HEAD *head" "TYPE *elm" "TYPE" "STAILQ_ENTRY NAME"
+.Fn STAILQ_SWAP "STAILQ_HEAD *head1" "STAILQ_HEAD *head2" "STAILQ_ENTRY NAME"
+.\"
+.Fn LIST_EMPTY "LIST_HEAD *head"
+.Fn LIST_ENTRY "TYPE"
+.Fn LIST_FIRST "LIST_HEAD *head"
+.Fn LIST_FOREACH "TYPE *var" "LIST_HEAD *head" "LIST_ENTRY NAME"
+.Fn LIST_FOREACH_SAFE "TYPE *var" "LIST_HEAD *head" "LIST_ENTRY NAME" "TYPE *temp_var"
+.Fn LIST_HEAD "HEADNAME" "TYPE"
+.Fn LIST_HEAD_INITIALIZER "LIST_HEAD head"
+.Fn LIST_INIT "LIST_HEAD *head"
+.Fn LIST_INSERT_AFTER "TYPE *listelm" "TYPE *elm" "LIST_ENTRY NAME"
+.Fn LIST_INSERT_BEFORE "TYPE *listelm" "TYPE *elm" "LIST_ENTRY NAME"
+.Fn LIST_INSERT_HEAD "LIST_HEAD *head" "TYPE *elm" "LIST_ENTRY NAME"
+.Fn LIST_NEXT "TYPE *elm" "LIST_ENTRY NAME"
+.Fn LIST_REMOVE "TYPE *elm" "LIST_ENTRY NAME"
+.Fn LIST_SWAP "LIST_HEAD *head1" "LIST_HEAD *head2" "TYPE" "LIST_ENTRY NAME"
+.\"
+.Fn TAILQ_CONCAT "TAILQ_HEAD *head1" "TAILQ_HEAD *head2" "TAILQ_ENTRY NAME"
+.Fn TAILQ_EMPTY "TAILQ_HEAD *head"
+.Fn TAILQ_ENTRY "TYPE"
+.Fn TAILQ_FIRST "TAILQ_HEAD *head"
+.Fn TAILQ_FOREACH "TYPE *var" "TAILQ_HEAD *head" "TAILQ_ENTRY NAME"
+.Fn TAILQ_FOREACH_SAFE "TYPE *var" "TAILQ_HEAD *head" "TAILQ_ENTRY NAME" "TYPE *temp_var"
+.Fn TAILQ_FOREACH_REVERSE "TYPE *var" "TAILQ_HEAD *head" "HEADNAME" "TAILQ_ENTRY NAME"
+.Fn TAILQ_FOREACH_REVERSE_SAFE "TYPE *var" "TAILQ_HEAD *head" "HEADNAME" "TAILQ_ENTRY NAME" "TYPE *temp_var"
+.Fn TAILQ_HEAD "HEADNAME" "TYPE"
+.Fn TAILQ_HEAD_INITIALIZER "TAILQ_HEAD head"
+.Fn TAILQ_INIT "TAILQ_HEAD *head"
+.Fn TAILQ_INSERT_AFTER "TAILQ_HEAD *head" "TYPE *listelm" "TYPE *elm" "TAILQ_ENTRY NAME"
+.Fn TAILQ_INSERT_BEFORE "TYPE *listelm" "TYPE *elm" "TAILQ_ENTRY NAME"
+.Fn TAILQ_INSERT_HEAD "TAILQ_HEAD *head" "TYPE *elm" "TAILQ_ENTRY NAME"
+.Fn TAILQ_INSERT_TAIL "TAILQ_HEAD *head" "TYPE *elm" "TAILQ_ENTRY NAME"
+.Fn TAILQ_LAST "TAILQ_HEAD *head" "HEADNAME"
+.Fn TAILQ_NEXT "TYPE *elm" "TAILQ_ENTRY NAME"
+.Fn TAILQ_PREV "TYPE *elm" "HEADNAME" "TAILQ_ENTRY NAME"
+.Fn TAILQ_REMOVE "TAILQ_HEAD *head" "TYPE *elm" "TAILQ_ENTRY NAME"
+.Fn TAILQ_SWAP "TAILQ_HEAD *head1" "TAILQ_HEAD *head2" "TYPE" "TAILQ_ENTRY NAME"
+.\"
+.Sh DESCRIPTION
+These macros define and operate on four types of data structures:
+singly-linked lists, singly-linked tail queues, lists, and tail queues.
+All four structures support the following functionality:
+.Bl -enum -compact -offset indent
+.It
+Insertion of a new entry at the head of the list.
+.It
+Insertion of a new entry after any element in the list.
+.It
+O(1) removal of an entry from the head of the list.
+.It
+Forward traversal through the list.
+.It
+Swawpping the contents of two lists.
+.El
+.Pp
+Singly-linked lists are the simplest of the four data structures
+and support only the above functionality.
+Singly-linked lists are ideal for applications with large datasets
+and few or no removals,
+or for implementing a LIFO queue.
+Singly-linked lists add the following functionality:
+.Bl -enum -compact -offset indent
+.It
+O(n) removal of any entry in the list.
+.El
+.Pp
+Singly-linked tail queues add the following functionality:
+.Bl -enum -compact -offset indent
+.It
+Entries can be added at the end of a list.
+.It
+O(n) removal of any entry in the list.
+.It
+They may be concatenated.
+.El
+However:
+.Bl -enum -compact -offset indent
+.It
+All list insertions must specify the head of the list.
+.It
+Each head entry requires two pointers rather than one.
+.It
+Code size is about 15% greater and operations run about 20% slower
+than singly-linked lists.
+.El
+.Pp
+Singly-linked tailqs are ideal for applications with large datasets and
+few or no removals,
+or for implementing a FIFO queue.
+.Pp
+All doubly linked types of data structures (lists and tail queues)
+additionally allow:
+.Bl -enum -compact -offset indent
+.It
+Insertion of a new entry before any element in the list.
+.It
+O(1) removal of any entry in the list.
+.El
+However:
+.Bl -enum -compact -offset indent
+.It
+Each element requires two pointers rather than one.
+.It
+Code size and execution time of operations (except for removal) is about
+twice that of the singly-linked data-structures.
+.El
+.Pp
+Linked lists are the simplest of the doubly linked data structures and support
+only the above functionality over singly-linked lists.
+.Pp
+Tail queues add the following functionality:
+.Bl -enum -compact -offset indent
+.It
+Entries can be added at the end of a list.
+.It
+They may be traversed backwards, from tail to head.
+.It
+They may be concatenated.
+.El
+However:
+.Bl -enum -compact -offset indent
+.It
+All list insertions and removals must specify the head of the list.
+.It
+Each head entry requires two pointers rather than one.
+.It
+Code size is about 15% greater and operations run about 20% slower
+than singly-linked lists.
+.El
+.Pp
+In the macro definitions,
+.Fa TYPE
+is the name of a user defined structure,
+that must contain a field of type
+.Li SLIST_ENTRY ,
+.Li STAILQ_ENTRY ,
+.Li LIST_ENTRY ,
+or
+.Li TAILQ_ENTRY ,
+named
+.Fa NAME .
+The argument
+.Fa HEADNAME
+is the name of a user defined structure that must be declared
+using the macros
+.Li SLIST_HEAD ,
+.Li STAILQ_HEAD ,
+.Li LIST_HEAD ,
+or
+.Li TAILQ_HEAD .
+See the examples below for further explanation of how these
+macros are used.
+.Sh SINGLY-LINKED LISTS
+A singly-linked list is headed by a structure defined by the
+.Nm SLIST_HEAD
+macro.
+This structure contains a single pointer to the first element
+on the list.
+The elements are singly linked for minimum space and pointer manipulation
+overhead at the expense of O(n) removal for arbitrary elements.
+New elements can be added to the list after an existing element or
+at the head of the list.
+An
+.Fa SLIST_HEAD
+structure is declared as follows:
+.Bd -literal -offset indent
+SLIST_HEAD(HEADNAME, TYPE) head;
+.Ed
+.Pp
+where
+.Fa HEADNAME
+is the name of the structure to be defined, and
+.Fa TYPE
+is the type of the elements to be linked into the list.
+A pointer to the head of the list can later be declared as:
+.Bd -literal -offset indent
+struct HEADNAME *headp;
+.Ed
+.Pp
+(The names
+.Li head
+and
+.Li headp
+are user selectable.)
+.Pp
+The macro
+.Nm SLIST_HEAD_INITIALIZER
+evaluates to an initializer for the list
+.Fa head .
+.Pp
+The macro
+.Nm SLIST_EMPTY
+evaluates to true if there are no elements in the list.
+.Pp
+The macro
+.Nm SLIST_ENTRY
+declares a structure that connects the elements in
+the list.
+.Pp
+The macro
+.Nm SLIST_FIRST
+returns the first element in the list or NULL if the list is empty.
+.Pp
+The macro
+.Nm SLIST_FOREACH
+traverses the list referenced by
+.Fa head
+in the forward direction, assigning each element in
+turn to
+.Fa var .
+.Pp
+The macro
+.Nm SLIST_FOREACH_SAFE
+traverses the list referenced by
+.Fa head
+in the forward direction, assigning each element in
+turn to
+.Fa var .
+However, unlike
+.Fn SLIST_FOREACH
+here it is permitted to both remove
+.Fa var
+as well as free it from within the loop safely without interfering with the
+traversal.
+.Pp
+The macro
+.Nm SLIST_INIT
+initializes the list referenced by
+.Fa head .
+.Pp
+The macro
+.Nm SLIST_INSERT_HEAD
+inserts the new element
+.Fa elm
+at the head of the list.
+.Pp
+The macro
+.Nm SLIST_INSERT_AFTER
+inserts the new element
+.Fa elm
+after the element
+.Fa listelm .
+.Pp
+The macro
+.Nm SLIST_NEXT
+returns the next element in the list.
+.Pp
+The macro
+.Nm SLIST_REMOVE_AFTER
+removes the element after
+.Fa elm
+from the list. Unlike
+.Fa SLIST_REMOVE ,
+this macro does not traverse the entire list.
+.Pp
+The macro
+.Nm SLIST_REMOVE_HEAD
+removes the element
+.Fa elm
+from the head of the list.
+For optimum efficiency,
+elements being removed from the head of the list should explicitly use
+this macro instead of the generic
+.Fa SLIST_REMOVE
+macro.
+.Pp
+The macro
+.Nm SLIST_REMOVE
+removes the element
+.Fa elm
+from the list.
+.Pp
+The macro
+.Nm SLIST_SWAP
+swaps the contents of
+.Fa head1
+and
+.Fa head2 .
+.Sh SINGLY-LINKED LIST EXAMPLE
+.Bd -literal
+SLIST_HEAD(slisthead, entry) head =
+    SLIST_HEAD_INITIALIZER(head);
+struct slisthead *headp;		/* Singly-linked List head. */
+struct entry {
+	...
+	SLIST_ENTRY(entry) entries;	/* Singly-linked List. */
+	...
+} *n1, *n2, *n3, *np;
+
+SLIST_INIT(&head);			/* Initialize the list. */
+
+n1 = malloc(sizeof(struct entry));	/* Insert at the head. */
+SLIST_INSERT_HEAD(&head, n1, entries);
+
+n2 = malloc(sizeof(struct entry));	/* Insert after. */
+SLIST_INSERT_AFTER(n1, n2, entries);
+
+SLIST_REMOVE(&head, n2, entry, entries);/* Deletion. */
+free(n2);
+
+n3 = SLIST_FIRST(&head);
+SLIST_REMOVE_HEAD(&head, entries);	/* Deletion from the head. */
+free(n3);
+					/* Forward traversal. */
+SLIST_FOREACH(np, &head, entries)
+	np-> ...
+					/* Safe forward traversal. */
+SLIST_FOREACH_SAFE(np, &head, entries, np_temp) {
+	np->do_stuff();
+	...
+	SLIST_REMOVE(&head, np, entry, entries);
+	free(np);
+}
+
+while (!SLIST_EMPTY(&head)) {		/* List Deletion. */
+	n1 = SLIST_FIRST(&head);
+	SLIST_REMOVE_HEAD(&head, entries);
+	free(n1);
+}
+.Ed
+.Sh SINGLY-LINKED TAIL QUEUES
+A singly-linked tail queue is headed by a structure defined by the
+.Nm STAILQ_HEAD
+macro.
+This structure contains a pair of pointers,
+one to the first element in the tail queue and the other to
+the last element in the tail queue.
+The elements are singly linked for minimum space and pointer
+manipulation overhead at the expense of O(n) removal for arbitrary
+elements.
+New elements can be added to the tail queue after an existing element,
+at the head of the tail queue, or at the end of the tail queue.
+A
+.Fa STAILQ_HEAD
+structure is declared as follows:
+.Bd -literal -offset indent
+STAILQ_HEAD(HEADNAME, TYPE) head;
+.Ed
+.Pp
+where
+.Li HEADNAME
+is the name of the structure to be defined, and
+.Li TYPE
+is the type of the elements to be linked into the tail queue.
+A pointer to the head of the tail queue can later be declared as:
+.Bd -literal -offset indent
+struct HEADNAME *headp;
+.Ed
+.Pp
+(The names
+.Li head
+and
+.Li headp
+are user selectable.)
+.Pp
+The macro
+.Nm STAILQ_HEAD_INITIALIZER
+evaluates to an initializer for the tail queue
+.Fa head .
+.Pp
+The macro
+.Nm STAILQ_CONCAT
+concatenates the tail queue headed by
+.Fa head2
+onto the end of the one headed by
+.Fa head1
+removing all entries from the former.
+.Pp
+The macro
+.Nm STAILQ_EMPTY
+evaluates to true if there are no items on the tail queue.
+.Pp
+The macro
+.Nm STAILQ_ENTRY
+declares a structure that connects the elements in
+the tail queue.
+.Pp
+The macro
+.Nm STAILQ_FIRST
+returns the first item on the tail queue or NULL if the tail queue
+is empty.
+.Pp
+The macro
+.Nm STAILQ_FOREACH
+traverses the tail queue referenced by
+.Fa head
+in the forward direction, assigning each element
+in turn to
+.Fa var .
+.Pp
+The macro
+.Nm STAILQ_FOREACH_SAFE
+traverses the tail queue referenced by
+.Fa head
+in the forward direction, assigning each element
+in turn to
+.Fa var .
+However, unlike
+.Fn STAILQ_FOREACH
+here it is permitted to both remove
+.Fa var
+as well as free it from within the loop safely without interfering with the
+traversal.
+.Pp
+The macro
+.Nm STAILQ_INIT
+initializes the tail queue referenced by
+.Fa head .
+.Pp
+The macro
+.Nm STAILQ_INSERT_HEAD
+inserts the new element
+.Fa elm
+at the head of the tail queue.
+.Pp
+The macro
+.Nm STAILQ_INSERT_TAIL
+inserts the new element
+.Fa elm
+at the end of the tail queue.
+.Pp
+The macro
+.Nm STAILQ_INSERT_AFTER
+inserts the new element
+.Fa elm
+after the element
+.Fa listelm .
+.Pp
+The macro
+.Nm STAILQ_LAST
+returns the last item on the tail queue.
+If the tail queue is empty the return value is
+.Dv NULL .
+.Pp
+The macro
+.Nm STAILQ_NEXT
+returns the next item on the tail queue, or NULL this item is the last.
+.Pp
+The macro
+.Nm STAILQ_REMOVE_AFTER
+removes the element after
+.Fa elm
+from the tail queue. Unlike
+.Fa STAILQ_REMOVE ,
+this macro does not traverse the entire tail queue.
+.Pp
+The macro
+.Nm STAILQ_REMOVE_HEAD
+removes the element at the head of the tail queue.
+For optimum efficiency,
+elements being removed from the head of the tail queue should
+use this macro explicitly rather than the generic
+.Fa STAILQ_REMOVE
+macro.
+.Pp
+The macro
+.Nm STAILQ_REMOVE
+removes the element
+.Fa elm
+from the tail queue.
+.Pp
+The macro
+.Nm STAILQ_SWAP
+swaps the contents of
+.Fa head1
+and
+.Fa head2 .
+.Sh SINGLY-LINKED TAIL QUEUE EXAMPLE
+.Bd -literal
+STAILQ_HEAD(stailhead, entry) head =
+    STAILQ_HEAD_INITIALIZER(head);
+struct stailhead *headp;		/* Singly-linked tail queue head. */
+struct entry {
+	...
+	STAILQ_ENTRY(entry) entries;	/* Tail queue. */
+	...
+} *n1, *n2, *n3, *np;
+
+STAILQ_INIT(&head);			/* Initialize the queue. */
+
+n1 = malloc(sizeof(struct entry));	/* Insert at the head. */
+STAILQ_INSERT_HEAD(&head, n1, entries);
+
+n1 = malloc(sizeof(struct entry));	/* Insert at the tail. */
+STAILQ_INSERT_TAIL(&head, n1, entries);
+
+n2 = malloc(sizeof(struct entry));	/* Insert after. */
+STAILQ_INSERT_AFTER(&head, n1, n2, entries);
+					/* Deletion. */
+STAILQ_REMOVE(&head, n2, entry, entries);
+free(n2);
+					/* Deletion from the head. */
+n3 = STAILQ_FIRST(&head);
+STAILQ_REMOVE_HEAD(&head, entries);
+free(n3);
+					/* Forward traversal. */
+STAILQ_FOREACH(np, &head, entries)
+	np-> ...
+					/* Safe forward traversal. */
+STAILQ_FOREACH_SAFE(np, &head, entries, np_temp) {
+	np->do_stuff();
+	...
+	STAILQ_REMOVE(&head, np, entry, entries);
+	free(np);
+}
+					/* TailQ Deletion. */
+while (!STAILQ_EMPTY(&head)) {
+	n1 = STAILQ_FIRST(&head);
+	STAILQ_REMOVE_HEAD(&head, entries);
+	free(n1);
+}
+					/* Faster TailQ Deletion. */
+n1 = STAILQ_FIRST(&head);
+while (n1 != NULL) {
+	n2 = STAILQ_NEXT(n1, entries);
+	free(n1);
+	n1 = n2;
+}
+STAILQ_INIT(&head);
+.Ed
+.Sh LISTS
+A list is headed by a structure defined by the
+.Nm LIST_HEAD
+macro.
+This structure contains a single pointer to the first element
+on the list.
+The elements are doubly linked so that an arbitrary element can be
+removed without traversing the list.
+New elements can be added to the list after an existing element,
+before an existing element, or at the head of the list.
+A
+.Fa LIST_HEAD
+structure is declared as follows:
+.Bd -literal -offset indent
+LIST_HEAD(HEADNAME, TYPE) head;
+.Ed
+.Pp
+where
+.Fa HEADNAME
+is the name of the structure to be defined, and
+.Fa TYPE
+is the type of the elements to be linked into the list.
+A pointer to the head of the list can later be declared as:
+.Bd -literal -offset indent
+struct HEADNAME *headp;
+.Ed
+.Pp
+(The names
+.Li head
+and
+.Li headp
+are user selectable.)
+.Pp
+The macro
+.Nm LIST_HEAD_INITIALIZER
+evaluates to an initializer for the list
+.Fa head .
+.Pp
+The macro
+.Nm LIST_EMPTY
+evaluates to true if there are no elements in the list.
+.Pp
+The macro
+.Nm LIST_ENTRY
+declares a structure that connects the elements in
+the list.
+.Pp
+The macro
+.Nm LIST_FIRST
+returns the first element in the list or NULL if the list
+is empty.
+.Pp
+The macro
+.Nm LIST_FOREACH
+traverses the list referenced by
+.Fa head
+in the forward direction, assigning each element in turn to
+.Fa var .
+.Pp
+The macro
+.Nm LIST_FOREACH_SAFE
+traverses the list referenced by
+.Fa head
+in the forward direction, assigning each element in turn to
+.Fa var .
+However, unlike
+.Fn LIST_FOREACH
+here it is permitted to both remove
+.Fa var
+as well as free it from within the loop safely without interfering with the
+traversal.
+.Pp
+The macro
+.Nm LIST_INIT
+initializes the list referenced by
+.Fa head .
+.Pp
+The macro
+.Nm LIST_INSERT_HEAD
+inserts the new element
+.Fa elm
+at the head of the list.
+.Pp
+The macro
+.Nm LIST_INSERT_AFTER
+inserts the new element
+.Fa elm
+after the element
+.Fa listelm .
+.Pp
+The macro
+.Nm LIST_INSERT_BEFORE
+inserts the new element
+.Fa elm
+before the element
+.Fa listelm .
+.Pp
+The macro
+.Nm LIST_NEXT
+returns the next element in the list, or NULL if this is the last.
+.Pp
+The macro
+.Nm LIST_REMOVE
+removes the element
+.Fa elm
+from the list.
+.Pp
+The macro
+.Nm LIST_SWAP
+swaps the contents of
+.Fa head1
+and
+.Fa head2 .
+.Sh LIST EXAMPLE
+.Bd -literal
+LIST_HEAD(listhead, entry) head =
+    LIST_HEAD_INITIALIZER(head);
+struct listhead *headp;			/* List head. */
+struct entry {
+	...
+	LIST_ENTRY(entry) entries;	/* List. */
+	...
+} *n1, *n2, *n3, *np, *np_temp;
+
+LIST_INIT(&head);			/* Initialize the list. */
+
+n1 = malloc(sizeof(struct entry));	/* Insert at the head. */
+LIST_INSERT_HEAD(&head, n1, entries);
+
+n2 = malloc(sizeof(struct entry));	/* Insert after. */
+LIST_INSERT_AFTER(n1, n2, entries);
+
+n3 = malloc(sizeof(struct entry));	/* Insert before. */
+LIST_INSERT_BEFORE(n2, n3, entries);
+
+LIST_REMOVE(n2, entries);		/* Deletion. */
+free(n2);
+					/* Forward traversal. */
+LIST_FOREACH(np, &head, entries)
+	np-> ...
+
+					/* Safe forward traversal. */
+LIST_FOREACH_SAFE(np, &head, entries, np_temp) {
+	np->do_stuff();
+	...
+	LIST_REMOVE(np, entries);
+	free(np);
+}
+
+while (!LIST_EMPTY(&head)) {		/* List Deletion. */
+	n1 = LIST_FIRST(&head);
+	LIST_REMOVE(n1, entries);
+	free(n1);
+}
+
+n1 = LIST_FIRST(&head);			/* Faster List Deletion. */
+while (n1 != NULL) {
+	n2 = LIST_NEXT(n1, entries);
+	free(n1);
+	n1 = n2;
+}
+LIST_INIT(&head);
+.Ed
+.Sh TAIL QUEUES
+A tail queue is headed by a structure defined by the
+.Nm TAILQ_HEAD
+macro.
+This structure contains a pair of pointers,
+one to the first element in the tail queue and the other to
+the last element in the tail queue.
+The elements are doubly linked so that an arbitrary element can be
+removed without traversing the tail queue.
+New elements can be added to the tail queue after an existing element,
+before an existing element, at the head of the tail queue,
+or at the end of the tail queue.
+A
+.Fa TAILQ_HEAD
+structure is declared as follows:
+.Bd -literal -offset indent
+TAILQ_HEAD(HEADNAME, TYPE) head;
+.Ed
+.Pp
+where
+.Li HEADNAME
+is the name of the structure to be defined, and
+.Li TYPE
+is the type of the elements to be linked into the tail queue.
+A pointer to the head of the tail queue can later be declared as:
+.Bd -literal -offset indent
+struct HEADNAME *headp;
+.Ed
+.Pp
+(The names
+.Li head
+and
+.Li headp
+are user selectable.)
+.Pp
+The macro
+.Nm TAILQ_HEAD_INITIALIZER
+evaluates to an initializer for the tail queue
+.Fa head .
+.Pp
+The macro
+.Nm TAILQ_CONCAT
+concatenates the tail queue headed by
+.Fa head2
+onto the end of the one headed by
+.Fa head1
+removing all entries from the former.
+.Pp
+The macro
+.Nm TAILQ_EMPTY
+evaluates to true if there are no items on the tail queue.
+.Pp
+The macro
+.Nm TAILQ_ENTRY
+declares a structure that connects the elements in
+the tail queue.
+.Pp
+The macro
+.Nm TAILQ_FIRST
+returns the first item on the tail queue or NULL if the tail queue
+is empty.
+.Pp
+The macro
+.Nm TAILQ_FOREACH
+traverses the tail queue referenced by
+.Fa head
+in the forward direction, assigning each element in turn to
+.Fa var .
+.Fa var
+is set to
+.Dv NULL
+if the loop completes normally, or if there were no elements.
+.Pp
+The macro
+.Nm TAILQ_FOREACH_REVERSE
+traverses the tail queue referenced by
+.Fa head
+in the reverse direction, assigning each element in turn to
+.Fa var .
+.Pp
+The macros
+.Nm TAILQ_FOREACH_SAFE
+and
+.Nm TAILQ_FOREACH_REVERSE_SAFE
+traverse the list referenced by
+.Fa head
+in the forward or reverse direction respectively,
+assigning each element in turn to
+.Fa var .
+However, unlike their unsafe counterparts,
+.Nm TAILQ_FOREACH
+and
+.Nm TAILQ_FOREACH_REVERSE
+permit to both remove
+.Fa var
+as well as free it from within the loop safely without interfering with the
+traversal.
+.Pp
+The macro
+.Nm TAILQ_INIT
+initializes the tail queue referenced by
+.Fa head .
+.Pp
+The macro
+.Nm TAILQ_INSERT_HEAD
+inserts the new element
+.Fa elm
+at the head of the tail queue.
+.Pp
+The macro
+.Nm TAILQ_INSERT_TAIL
+inserts the new element
+.Fa elm
+at the end of the tail queue.
+.Pp
+The macro
+.Nm TAILQ_INSERT_AFTER
+inserts the new element
+.Fa elm
+after the element
+.Fa listelm .
+.Pp
+The macro
+.Nm TAILQ_INSERT_BEFORE
+inserts the new element
+.Fa elm
+before the element
+.Fa listelm .
+.Pp
+The macro
+.Nm TAILQ_LAST
+returns the last item on the tail queue.
+If the tail queue is empty the return value is
+.Dv NULL .
+.Pp
+The macro
+.Nm TAILQ_NEXT
+returns the next item on the tail queue, or NULL if this item is the last.
+.Pp
+The macro
+.Nm TAILQ_PREV
+returns the previous item on the tail queue, or NULL if this item
+is the first.
+.Pp
+The macro
+.Nm TAILQ_REMOVE
+removes the element
+.Fa elm
+from the tail queue.
+.Pp
+The macro
+.Nm TAILQ_SWAP
+swaps the contents of
+.Fa head1
+and
+.Fa head2 .
+.Sh TAIL QUEUE EXAMPLE
+.Bd -literal
+TAILQ_HEAD(tailhead, entry) head =
+    TAILQ_HEAD_INITIALIZER(head);
+struct tailhead *headp;			/* Tail queue head. */
+struct entry {
+	...
+	TAILQ_ENTRY(entry) entries;	/* Tail queue. */
+	...
+} *n1, *n2, *n3, *np;
+
+TAILQ_INIT(&head);			/* Initialize the queue. */
+
+n1 = malloc(sizeof(struct entry));	/* Insert at the head. */
+TAILQ_INSERT_HEAD(&head, n1, entries);
+
+n1 = malloc(sizeof(struct entry));	/* Insert at the tail. */
+TAILQ_INSERT_TAIL(&head, n1, entries);
+
+n2 = malloc(sizeof(struct entry));	/* Insert after. */
+TAILQ_INSERT_AFTER(&head, n1, n2, entries);
+
+n3 = malloc(sizeof(struct entry));	/* Insert before. */
+TAILQ_INSERT_BEFORE(n2, n3, entries);
+
+TAILQ_REMOVE(&head, n2, entries);	/* Deletion. */
+free(n2);
+					/* Forward traversal. */
+TAILQ_FOREACH(np, &head, entries)
+	np-> ...
+					/* Safe forward traversal. */
+TAILQ_FOREACH_SAFE(np, &head, entries, np_temp) {
+	np->do_stuff();
+	...
+	TAILQ_REMOVE(&head, np, entries);
+	free(np);
+}
+					/* Reverse traversal. */
+TAILQ_FOREACH_REVERSE(np, &head, tailhead, entries)
+	np-> ...
+					/* TailQ Deletion. */
+while (!TAILQ_EMPTY(&head)) {
+	n1 = TAILQ_FIRST(&head);
+	TAILQ_REMOVE(&head, n1, entries);
+	free(n1);
+}
+					/* Faster TailQ Deletion. */
+n1 = TAILQ_FIRST(&head);
+while (n1 != NULL) {
+	n2 = TAILQ_NEXT(n1, entries);
+	free(n1);
+	n1 = n2;
+}
+TAILQ_INIT(&head);
+.Ed
+.Sh SEE ALSO
+.Xr tree 3
+.Sh HISTORY
+The
+.Nm queue
+functions first appeared in
+.Bx 4.4 .
diff --git a/tools/libxl/external/bsd-sys-queue.h b/tools/libxl/external/bsd-sys-queue.h
new file mode 100644
index 0000000..274e636
--- /dev/null
+++ b/tools/libxl/external/bsd-sys-queue.h
@@ -0,0 +1,637 @@
+/*-
+ * Copyright (c) 1991, 1993
+ *	The Regents of the University of California.  All rights reserved.
+ *
+ * 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.
+ * 4. Neither the name of the University 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 REGENTS 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 REGENTS 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.
+ *
+ *	@(#)queue.h	8.5 (Berkeley) 8/20/94
+ * $FreeBSD$
+ */
+
+#ifndef _SYS_QUEUE_H_
+#define	_SYS_QUEUE_H_
+
+#include <sys/cdefs.h>
+
+/*
+ * This file defines four types of data structures: singly-linked lists,
+ * singly-linked tail queues, lists and tail queues.
+ *
+ * A singly-linked list is headed by a single forward pointer. The elements
+ * are singly linked for minimum space and pointer manipulation overhead at
+ * the expense of O(n) removal for arbitrary elements. New elements can be
+ * added to the list after an existing element or at the head of the list.
+ * Elements being removed from the head of the list should use the explicit
+ * macro for this purpose for optimum efficiency. A singly-linked list may
+ * only be traversed in the forward direction.  Singly-linked lists are ideal
+ * for applications with large datasets and few or no removals or for
+ * implementing a LIFO queue.
+ *
+ * A singly-linked tail queue is headed by a pair of pointers, one to the
+ * head of the list and the other to the tail of the list. The elements are
+ * singly linked for minimum space and pointer manipulation overhead at the
+ * expense of O(n) removal for arbitrary elements. New elements can be added
+ * to the list after an existing element, at the head of the list, or at the
+ * end of the list. Elements being removed from the head of the tail queue
+ * should use the explicit macro for this purpose for optimum efficiency.
+ * A singly-linked tail queue may only be traversed in the forward direction.
+ * Singly-linked tail queues are ideal for applications with large datasets
+ * and few or no removals or for implementing a FIFO queue.
+ *
+ * A list is headed by a single forward pointer (or an array of forward
+ * pointers for a hash table header). The elements are doubly linked
+ * so that an arbitrary element can be removed without a need to
+ * traverse the list. New elements can be added to the list before
+ * or after an existing element or at the head of the list. A list
+ * may only be traversed in the forward direction.
+ *
+ * A tail queue is headed by a pair of pointers, one to the head of the
+ * list and the other to the tail of the list. The elements are doubly
+ * linked so that an arbitrary element can be removed without a need to
+ * traverse the list. New elements can be added to the list before or
+ * after an existing element, at the head of the list, or at the end of
+ * the list. A tail queue may be traversed in either direction.
+ *
+ * For details on the use of these macros, see the queue(3) manual page.
+ *
+ *
+ *				SLIST	LIST	STAILQ	TAILQ
+ * _HEAD			+	+	+	+
+ * _HEAD_INITIALIZER		+	+	+	+
+ * _ENTRY			+	+	+	+
+ * _INIT			+	+	+	+
+ * _EMPTY			+	+	+	+
+ * _FIRST			+	+	+	+
+ * _NEXT			+	+	+	+
+ * _PREV			-	-	-	+
+ * _LAST			-	-	+	+
+ * _FOREACH			+	+	+	+
+ * _FOREACH_SAFE		+	+	+	+
+ * _FOREACH_REVERSE		-	-	-	+
+ * _FOREACH_REVERSE_SAFE	-	-	-	+
+ * _INSERT_HEAD			+	+	+	+
+ * _INSERT_BEFORE		-	+	-	+
+ * _INSERT_AFTER		+	+	+	+
+ * _INSERT_TAIL			-	-	+	+
+ * _CONCAT			-	-	+	+
+ * _REMOVE_AFTER		+	-	+	-
+ * _REMOVE_HEAD			+	-	+	-
+ * _REMOVE			+	+	+	+
+ * _SWAP			+	+	+	+
+ *
+ */
+#ifdef QUEUE_MACRO_DEBUG
+/* Store the last 2 places the queue element or head was altered */
+struct qm_trace {
+	char * lastfile;
+	int lastline;
+	char * prevfile;
+	int prevline;
+};
+
+#define	TRACEBUF	struct qm_trace trace;
+#define	TRASHIT(x)	do {(x) = (void *)-1;} while (0)
+#define	QMD_SAVELINK(name, link)	void **name = (void *)&(link)
+
+#define	QMD_TRACE_HEAD(head) do {					\
+	(head)->trace.prevline = (head)->trace.lastline;		\
+	(head)->trace.prevfile = (head)->trace.lastfile;		\
+	(head)->trace.lastline = __LINE__;				\
+	(head)->trace.lastfile = __FILE__;				\
+} while (0)
+
+#define	QMD_TRACE_ELEM(elem) do {					\
+	(elem)->trace.prevline = (elem)->trace.lastline;		\
+	(elem)->trace.prevfile = (elem)->trace.lastfile;		\
+	(elem)->trace.lastline = __LINE__;				\
+	(elem)->trace.lastfile = __FILE__;				\
+} while (0)
+
+#else
+#define	QMD_TRACE_ELEM(elem)
+#define	QMD_TRACE_HEAD(head)
+#define	QMD_SAVELINK(name, link)
+#define	TRACEBUF
+#define	TRASHIT(x)
+#endif	/* QUEUE_MACRO_DEBUG */
+
+/*
+ * Singly-linked List declarations.
+ */
+#define	SLIST_HEAD(name, type)						\
+struct name {								\
+	struct type *slh_first;	/* first element */			\
+}
+
+#define	SLIST_HEAD_INITIALIZER(head)					\
+	{ NULL }
+
+#define	SLIST_ENTRY(type)						\
+struct {								\
+	struct type *sle_next;	/* next element */			\
+}
+
+/*
+ * Singly-linked List functions.
+ */
+#define	SLIST_EMPTY(head)	((head)->slh_first == NULL)
+
+#define	SLIST_FIRST(head)	((head)->slh_first)
+
+#define	SLIST_FOREACH(var, head, field)					\
+	for ((var) = SLIST_FIRST((head));				\
+	    (var);							\
+	    (var) = SLIST_NEXT((var), field))
+
+#define	SLIST_FOREACH_SAFE(var, head, field, tvar)			\
+	for ((var) = SLIST_FIRST((head));				\
+	    (var) && ((tvar) = SLIST_NEXT((var), field), 1);		\
+	    (var) = (tvar))
+
+#define	SLIST_FOREACH_PREVPTR(var, varp, head, field)			\
+	for ((varp) = &SLIST_FIRST((head));				\
+	    ((var) = *(varp)) != NULL;					\
+	    (varp) = &SLIST_NEXT((var), field))
+
+#define	SLIST_INIT(head) do {						\
+	SLIST_FIRST((head)) = NULL;					\
+} while (0)
+
+#define	SLIST_INSERT_AFTER(slistelm, elm, field) do {			\
+	SLIST_NEXT((elm), field) = SLIST_NEXT((slistelm), field);	\
+	SLIST_NEXT((slistelm), field) = (elm);				\
+} while (0)
+
+#define	SLIST_INSERT_HEAD(head, elm, field) do {			\
+	SLIST_NEXT((elm), field) = SLIST_FIRST((head));			\
+	SLIST_FIRST((head)) = (elm);					\
+} while (0)
+
+#define	SLIST_NEXT(elm, field)	((elm)->field.sle_next)
+
+#define	SLIST_REMOVE(head, elm, type, field) do {			\
+	QMD_SAVELINK(oldnext, (elm)->field.sle_next);			\
+	if (SLIST_FIRST((head)) == (elm)) {				\
+		SLIST_REMOVE_HEAD((head), field);			\
+	}								\
+	else {								\
+		struct type *curelm = SLIST_FIRST((head));		\
+		while (SLIST_NEXT(curelm, field) != (elm))		\
+			curelm = SLIST_NEXT(curelm, field);		\
+		SLIST_REMOVE_AFTER(curelm, field);			\
+	}								\
+	TRASHIT(*oldnext);						\
+} while (0)
+
+#define SLIST_REMOVE_AFTER(elm, field) do {				\
+	SLIST_NEXT(elm, field) =					\
+	    SLIST_NEXT(SLIST_NEXT(elm, field), field);			\
+} while (0)
+
+#define	SLIST_REMOVE_HEAD(head, field) do {				\
+	SLIST_FIRST((head)) = SLIST_NEXT(SLIST_FIRST((head)), field);	\
+} while (0)
+
+#define SLIST_SWAP(head1, head2, type) do {				\
+	struct type *swap_first = SLIST_FIRST(head1);			\
+	SLIST_FIRST(head1) = SLIST_FIRST(head2);			\
+	SLIST_FIRST(head2) = swap_first;				\
+} while (0)
+
+/*
+ * Singly-linked Tail queue declarations.
+ */
+#define	STAILQ_HEAD(name, type)						\
+struct name {								\
+	struct type *stqh_first;/* first element */			\
+	struct type **stqh_last;/* addr of last next element */		\
+}
+
+#define	STAILQ_HEAD_INITIALIZER(head)					\
+	{ NULL, &(head).stqh_first }
+
+#define	STAILQ_ENTRY(type)						\
+struct {								\
+	struct type *stqe_next;	/* next element */			\
+}
+
+/*
+ * Singly-linked Tail queue functions.
+ */
+#define	STAILQ_CONCAT(head1, head2) do {				\
+	if (!STAILQ_EMPTY((head2))) {					\
+		*(head1)->stqh_last = (head2)->stqh_first;		\
+		(head1)->stqh_last = (head2)->stqh_last;		\
+		STAILQ_INIT((head2));					\
+	}								\
+} while (0)
+
+#define	STAILQ_EMPTY(head)	((head)->stqh_first == NULL)
+
+#define	STAILQ_FIRST(head)	((head)->stqh_first)
+
+#define	STAILQ_FOREACH(var, head, field)				\
+	for((var) = STAILQ_FIRST((head));				\
+	   (var);							\
+	   (var) = STAILQ_NEXT((var), field))
+
+
+#define	STAILQ_FOREACH_SAFE(var, head, field, tvar)			\
+	for ((var) = STAILQ_FIRST((head));				\
+	    (var) && ((tvar) = STAILQ_NEXT((var), field), 1);		\
+	    (var) = (tvar))
+
+#define	STAILQ_INIT(head) do {						\
+	STAILQ_FIRST((head)) = NULL;					\
+	(head)->stqh_last = &STAILQ_FIRST((head));			\
+} while (0)
+
+#define	STAILQ_INSERT_AFTER(head, tqelm, elm, field) do {		\
+	if ((STAILQ_NEXT((elm), field) = STAILQ_NEXT((tqelm), field)) == NULL)\
+		(head)->stqh_last = &STAILQ_NEXT((elm), field);		\
+	STAILQ_NEXT((tqelm), field) = (elm);				\
+} while (0)
+
+#define	STAILQ_INSERT_HEAD(head, elm, field) do {			\
+	if ((STAILQ_NEXT((elm), field) = STAILQ_FIRST((head))) == NULL)	\
+		(head)->stqh_last = &STAILQ_NEXT((elm), field);		\
+	STAILQ_FIRST((head)) = (elm);					\
+} while (0)
+
+#define	STAILQ_INSERT_TAIL(head, elm, field) do {			\
+	STAILQ_NEXT((elm), field) = NULL;				\
+	*(head)->stqh_last = (elm);					\
+	(head)->stqh_last = &STAILQ_NEXT((elm), field);			\
+} while (0)
+
+#define	STAILQ_LAST(head, type, field)					\
+	(STAILQ_EMPTY((head)) ?						\
+		NULL :							\
+	        ((struct type *)(void *)				\
+		((char *)((head)->stqh_last) - __offsetof(struct type, field))))
+
+#define	STAILQ_NEXT(elm, field)	((elm)->field.stqe_next)
+
+#define	STAILQ_REMOVE(head, elm, type, field) do {			\
+	QMD_SAVELINK(oldnext, (elm)->field.stqe_next);			\
+	if (STAILQ_FIRST((head)) == (elm)) {				\
+		STAILQ_REMOVE_HEAD((head), field);			\
+	}								\
+	else {								\
+		struct type *curelm = STAILQ_FIRST((head));		\
+		while (STAILQ_NEXT(curelm, field) != (elm))		\
+			curelm = STAILQ_NEXT(curelm, field);		\
+		STAILQ_REMOVE_AFTER(head, curelm, field);		\
+	}								\
+	TRASHIT(*oldnext);						\
+} while (0)
+
+#define STAILQ_REMOVE_AFTER(head, elm, field) do {			\
+	if ((STAILQ_NEXT(elm, field) =					\
+	     STAILQ_NEXT(STAILQ_NEXT(elm, field), field)) == NULL)	\
+		(head)->stqh_last = &STAILQ_NEXT((elm), field);		\
+} while (0)
+
+#define	STAILQ_REMOVE_HEAD(head, field) do {				\
+	if ((STAILQ_FIRST((head)) =					\
+	     STAILQ_NEXT(STAILQ_FIRST((head)), field)) == NULL)		\
+		(head)->stqh_last = &STAILQ_FIRST((head));		\
+} while (0)
+
+#define STAILQ_SWAP(head1, head2, type) do {				\
+	struct type *swap_first = STAILQ_FIRST(head1);			\
+	struct type **swap_last = (head1)->stqh_last;			\
+	STAILQ_FIRST(head1) = STAILQ_FIRST(head2);			\
+	(head1)->stqh_last = (head2)->stqh_last;			\
+	STAILQ_FIRST(head2) = swap_first;				\
+	(head2)->stqh_last = swap_last;					\
+	if (STAILQ_EMPTY(head1))					\
+		(head1)->stqh_last = &STAILQ_FIRST(head1);		\
+	if (STAILQ_EMPTY(head2))					\
+		(head2)->stqh_last = &STAILQ_FIRST(head2);		\
+} while (0)
+
+
+/*
+ * List declarations.
+ */
+#define	LIST_HEAD(name, type)						\
+struct name {								\
+	struct type *lh_first;	/* first element */			\
+}
+
+#define	LIST_HEAD_INITIALIZER(head)					\
+	{ NULL }
+
+#define	LIST_ENTRY(type)						\
+struct {								\
+	struct type *le_next;	/* next element */			\
+	struct type **le_prev;	/* address of previous next element */	\
+}
+
+/*
+ * List functions.
+ */
+
+#if (defined(_KERNEL) && defined(INVARIANTS))
+#define	QMD_LIST_CHECK_HEAD(head, field) do {				\
+	if (LIST_FIRST((head)) != NULL &&				\
+	    LIST_FIRST((head))->field.le_prev !=			\
+	     &LIST_FIRST((head)))					\
+		panic("Bad list head %p first->prev != head", (head));	\
+} while (0)
+
+#define	QMD_LIST_CHECK_NEXT(elm, field) do {				\
+	if (LIST_NEXT((elm), field) != NULL &&				\
+	    LIST_NEXT((elm), field)->field.le_prev !=			\
+	     &((elm)->field.le_next))					\
+	     	panic("Bad link elm %p next->prev != elm", (elm));	\
+} while (0)
+
+#define	QMD_LIST_CHECK_PREV(elm, field) do {				\
+	if (*(elm)->field.le_prev != (elm))				\
+		panic("Bad link elm %p prev->next != elm", (elm));	\
+} while (0)
+#else
+#define	QMD_LIST_CHECK_HEAD(head, field)
+#define	QMD_LIST_CHECK_NEXT(elm, field)
+#define	QMD_LIST_CHECK_PREV(elm, field)
+#endif /* (_KERNEL && INVARIANTS) */
+
+#define	LIST_EMPTY(head)	((head)->lh_first == NULL)
+
+#define	LIST_FIRST(head)	((head)->lh_first)
+
+#define	LIST_FOREACH(var, head, field)					\
+	for ((var) = LIST_FIRST((head));				\
+	    (var);							\
+	    (var) = LIST_NEXT((var), field))
+
+#define	LIST_FOREACH_SAFE(var, head, field, tvar)			\
+	for ((var) = LIST_FIRST((head));				\
+	    (var) && ((tvar) = LIST_NEXT((var), field), 1);		\
+	    (var) = (tvar))
+
+#define	LIST_INIT(head) do {						\
+	LIST_FIRST((head)) = NULL;					\
+} while (0)
+
+#define	LIST_INSERT_AFTER(listelm, elm, field) do {			\
+	QMD_LIST_CHECK_NEXT(listelm, field);				\
+	if ((LIST_NEXT((elm), field) = LIST_NEXT((listelm), field)) != NULL)\
+		LIST_NEXT((listelm), field)->field.le_prev =		\
+		    &LIST_NEXT((elm), field);				\
+	LIST_NEXT((listelm), field) = (elm);				\
+	(elm)->field.le_prev = &LIST_NEXT((listelm), field);		\
+} while (0)
+
+#define	LIST_INSERT_BEFORE(listelm, elm, field) do {			\
+	QMD_LIST_CHECK_PREV(listelm, field);				\
+	(elm)->field.le_prev = (listelm)->field.le_prev;		\
+	LIST_NEXT((elm), field) = (listelm);				\
+	*(listelm)->field.le_prev = (elm);				\
+	(listelm)->field.le_prev = &LIST_NEXT((elm), field);		\
+} while (0)
+
+#define	LIST_INSERT_HEAD(head, elm, field) do {				\
+	QMD_LIST_CHECK_HEAD((head), field);				\
+	if ((LIST_NEXT((elm), field) = LIST_FIRST((head))) != NULL)	\
+		LIST_FIRST((head))->field.le_prev = &LIST_NEXT((elm), field);\
+	LIST_FIRST((head)) = (elm);					\
+	(elm)->field.le_prev = &LIST_FIRST((head));			\
+} while (0)
+
+#define	LIST_NEXT(elm, field)	((elm)->field.le_next)
+
+#define	LIST_REMOVE(elm, field) do {					\
+	QMD_SAVELINK(oldnext, (elm)->field.le_next);			\
+	QMD_SAVELINK(oldprev, (elm)->field.le_prev);			\
+	QMD_LIST_CHECK_NEXT(elm, field);				\
+	QMD_LIST_CHECK_PREV(elm, field);				\
+	if (LIST_NEXT((elm), field) != NULL)				\
+		LIST_NEXT((elm), field)->field.le_prev = 		\
+		    (elm)->field.le_prev;				\
+	*(elm)->field.le_prev = LIST_NEXT((elm), field);		\
+	TRASHIT(*oldnext);						\
+	TRASHIT(*oldprev);						\
+} while (0)
+
+#define LIST_SWAP(head1, head2, type, field) do {			\
+	struct type *swap_tmp = LIST_FIRST((head1));			\
+	LIST_FIRST((head1)) = LIST_FIRST((head2));			\
+	LIST_FIRST((head2)) = swap_tmp;					\
+	if ((swap_tmp = LIST_FIRST((head1))) != NULL)			\
+		swap_tmp->field.le_prev = &LIST_FIRST((head1));		\
+	if ((swap_tmp = LIST_FIRST((head2))) != NULL)			\
+		swap_tmp->field.le_prev = &LIST_FIRST((head2));		\
+} while (0)
+
+/*
+ * Tail queue declarations.
+ */
+#define	TAILQ_HEAD(name, type)						\
+struct name {								\
+	struct type *tqh_first;	/* first element */			\
+	struct type **tqh_last;	/* addr of last next element */		\
+	TRACEBUF							\
+}
+
+#define	TAILQ_HEAD_INITIALIZER(head)					\
+	{ NULL, &(head).tqh_first }
+
+#define	TAILQ_ENTRY(type)						\
+struct {								\
+	struct type *tqe_next;	/* next element */			\
+	struct type **tqe_prev;	/* address of previous next element */	\
+	TRACEBUF							\
+}
+
+/*
+ * Tail queue functions.
+ */
+#if (defined(_KERNEL) && defined(INVARIANTS))
+#define	QMD_TAILQ_CHECK_HEAD(head, field) do {				\
+	if (!TAILQ_EMPTY(head) &&					\
+	    TAILQ_FIRST((head))->field.tqe_prev !=			\
+	     &TAILQ_FIRST((head)))					\
+		panic("Bad tailq head %p first->prev != head", (head));	\
+} while (0)
+
+#define	QMD_TAILQ_CHECK_TAIL(head, field) do {				\
+	if (*(head)->tqh_last != NULL)					\
+	    	panic("Bad tailq NEXT(%p->tqh_last) != NULL", (head)); 	\
+} while (0)
+
+#define	QMD_TAILQ_CHECK_NEXT(elm, field) do {				\
+	if (TAILQ_NEXT((elm), field) != NULL &&				\
+	    TAILQ_NEXT((elm), field)->field.tqe_prev !=			\
+	     &((elm)->field.tqe_next))					\
+		panic("Bad link elm %p next->prev != elm", (elm));	\
+} while (0)
+
+#define	QMD_TAILQ_CHECK_PREV(elm, field) do {				\
+	if (*(elm)->field.tqe_prev != (elm))				\
+		panic("Bad link elm %p prev->next != elm", (elm));	\
+} while (0)
+#else
+#define	QMD_TAILQ_CHECK_HEAD(head, field)
+#define	QMD_TAILQ_CHECK_TAIL(head, headname)
+#define	QMD_TAILQ_CHECK_NEXT(elm, field)
+#define	QMD_TAILQ_CHECK_PREV(elm, field)
+#endif /* (_KERNEL && INVARIANTS) */
+
+#define	TAILQ_CONCAT(head1, head2, field) do {				\
+	if (!TAILQ_EMPTY(head2)) {					\
+		*(head1)->tqh_last = (head2)->tqh_first;		\
+		(head2)->tqh_first->field.tqe_prev = (head1)->tqh_last;	\
+		(head1)->tqh_last = (head2)->tqh_last;			\
+		TAILQ_INIT((head2));					\
+		QMD_TRACE_HEAD(head1);					\
+		QMD_TRACE_HEAD(head2);					\
+	}								\
+} while (0)
+
+#define	TAILQ_EMPTY(head)	((head)->tqh_first == NULL)
+
+#define	TAILQ_FIRST(head)	((head)->tqh_first)
+
+#define	TAILQ_FOREACH(var, head, field)					\
+	for ((var) = TAILQ_FIRST((head));				\
+	    (var);							\
+	    (var) = TAILQ_NEXT((var), field))
+
+#define	TAILQ_FOREACH_SAFE(var, head, field, tvar)			\
+	for ((var) = TAILQ_FIRST((head));				\
+	    (var) && ((tvar) = TAILQ_NEXT((var), field), 1);		\
+	    (var) = (tvar))
+
+#define	TAILQ_FOREACH_REVERSE(var, head, headname, field)		\
+	for ((var) = TAILQ_LAST((head), headname);			\
+	    (var);							\
+	    (var) = TAILQ_PREV((var), headname, field))
+
+#define	TAILQ_FOREACH_REVERSE_SAFE(var, head, headname, field, tvar)	\
+	for ((var) = TAILQ_LAST((head), headname);			\
+	    (var) && ((tvar) = TAILQ_PREV((var), headname, field), 1);	\
+	    (var) = (tvar))
+
+#define	TAILQ_INIT(head) do {						\
+	TAILQ_FIRST((head)) = NULL;					\
+	(head)->tqh_last = &TAILQ_FIRST((head));			\
+	QMD_TRACE_HEAD(head);						\
+} while (0)
+
+#define	TAILQ_INSERT_AFTER(head, listelm, elm, field) do {		\
+	QMD_TAILQ_CHECK_NEXT(listelm, field);				\
+	if ((TAILQ_NEXT((elm), field) = TAILQ_NEXT((listelm), field)) != NULL)\
+		TAILQ_NEXT((elm), field)->field.tqe_prev = 		\
+		    &TAILQ_NEXT((elm), field);				\
+	else {								\
+		(head)->tqh_last = &TAILQ_NEXT((elm), field);		\
+		QMD_TRACE_HEAD(head);					\
+	}								\
+	TAILQ_NEXT((listelm), field) = (elm);				\
+	(elm)->field.tqe_prev = &TAILQ_NEXT((listelm), field);		\
+	QMD_TRACE_ELEM(&(elm)->field);					\
+	QMD_TRACE_ELEM(&listelm->field);				\
+} while (0)
+
+#define	TAILQ_INSERT_BEFORE(listelm, elm, field) do {			\
+	QMD_TAILQ_CHECK_PREV(listelm, field);				\
+	(elm)->field.tqe_prev = (listelm)->field.tqe_prev;		\
+	TAILQ_NEXT((elm), field) = (listelm);				\
+	*(listelm)->field.tqe_prev = (elm);				\
+	(listelm)->field.tqe_prev = &TAILQ_NEXT((elm), field);		\
+	QMD_TRACE_ELEM(&(elm)->field);					\
+	QMD_TRACE_ELEM(&listelm->field);				\
+} while (0)
+
+#define	TAILQ_INSERT_HEAD(head, elm, field) do {			\
+	QMD_TAILQ_CHECK_HEAD(head, field);				\
+	if ((TAILQ_NEXT((elm), field) = TAILQ_FIRST((head))) != NULL)	\
+		TAILQ_FIRST((head))->field.tqe_prev =			\
+		    &TAILQ_NEXT((elm), field);				\
+	else								\
+		(head)->tqh_last = &TAILQ_NEXT((elm), field);		\
+	TAILQ_FIRST((head)) = (elm);					\
+	(elm)->field.tqe_prev = &TAILQ_FIRST((head));			\
+	QMD_TRACE_HEAD(head);						\
+	QMD_TRACE_ELEM(&(elm)->field);					\
+} while (0)
+
+#define	TAILQ_INSERT_TAIL(head, elm, field) do {			\
+	QMD_TAILQ_CHECK_TAIL(head, field);				\
+	TAILQ_NEXT((elm), field) = NULL;				\
+	(elm)->field.tqe_prev = (head)->tqh_last;			\
+	*(head)->tqh_last = (elm);					\
+	(head)->tqh_last = &TAILQ_NEXT((elm), field);			\
+	QMD_TRACE_HEAD(head);						\
+	QMD_TRACE_ELEM(&(elm)->field);					\
+} while (0)
+
+#define	TAILQ_LAST(head, headname)					\
+	(*(((struct headname *)((head)->tqh_last))->tqh_last))
+
+#define	TAILQ_NEXT(elm, field) ((elm)->field.tqe_next)
+
+#define	TAILQ_PREV(elm, headname, field)				\
+	(*(((struct headname *)((elm)->field.tqe_prev))->tqh_last))
+
+#define	TAILQ_REMOVE(head, elm, field) do {				\
+	QMD_SAVELINK(oldnext, (elm)->field.tqe_next);			\
+	QMD_SAVELINK(oldprev, (elm)->field.tqe_prev);			\
+	QMD_TAILQ_CHECK_NEXT(elm, field);				\
+	QMD_TAILQ_CHECK_PREV(elm, field);				\
+	if ((TAILQ_NEXT((elm), field)) != NULL)				\
+		TAILQ_NEXT((elm), field)->field.tqe_prev = 		\
+		    (elm)->field.tqe_prev;				\
+	else {								\
+		(head)->tqh_last = (elm)->field.tqe_prev;		\
+		QMD_TRACE_HEAD(head);					\
+	}								\
+	*(elm)->field.tqe_prev = TAILQ_NEXT((elm), field);		\
+	TRASHIT(*oldnext);						\
+	TRASHIT(*oldprev);						\
+	QMD_TRACE_ELEM(&(elm)->field);					\
+} while (0)
+
+#define TAILQ_SWAP(head1, head2, type, field) do {			\
+	struct type *swap_first = (head1)->tqh_first;			\
+	struct type **swap_last = (head1)->tqh_last;			\
+	(head1)->tqh_first = (head2)->tqh_first;			\
+	(head1)->tqh_last = (head2)->tqh_last;				\
+	(head2)->tqh_first = swap_first;				\
+	(head2)->tqh_last = swap_last;					\
+	if ((swap_first = (head1)->tqh_first) != NULL)			\
+		swap_first->field.tqe_prev = &(head1)->tqh_first;	\
+	else								\
+		(head1)->tqh_last = &(head1)->tqh_first;		\
+	if ((swap_first = (head2)->tqh_first) != NULL)			\
+		swap_first->field.tqe_prev = &(head2)->tqh_first;	\
+	else								\
+		(head2)->tqh_last = &(head2)->tqh_first;		\
+} while (0)
+
+#endif /* !_SYS_QUEUE_H_ */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 18:11:31 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 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.xensource.com>)
	id 1RXd0W-00068i-IC; Mon, 05 Dec 2011 18:11:16 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RXd0T-00065w-CR
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 18:11:13 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1323108624!1307875!10
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjAyNg==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27300 invoked from network); 5 Dec 2011 18:10:28 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Dec 2011 18:10:28 -0000
X-IronPort-AV: E=Sophos;i="4.71,300,1320624000"; 
   d="scan'208";a="9297529"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Dec 2011 18:10:28 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 5 Dec 2011 18:10:28 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RXczk-0003kL-F6; Mon, 05 Dec 2011 18:10:28 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RXczk-0006WT-EG;
	Mon, 05 Dec 2011 18:10:28 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Mon, 5 Dec 2011 18:10:16 +0000
Message-ID: <1323108621-22654-11-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1323108621-22654-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1323108621-22654-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 10/15] libxl: make libxl__[v]log const-correct
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl_internal.c |    4 ++--
 tools/libxl/libxl_internal.h |    4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c
index d767ce3..ae28cb0 100644
--- a/tools/libxl/libxl_internal.c
+++ b/tools/libxl/libxl_internal.c
@@ -179,7 +179,7 @@ char *libxl__dirname(libxl__gc *gc, const char *s)
 
 void libxl__logv(libxl_ctx *ctx, xentoollog_level msglevel, int errnoval,
              const char *file, int line, const char *func,
-             char *fmt, va_list ap)
+             const char *fmt, va_list ap)
 {
     char *enomem = "[out of memory formatting log message]";
     char *base = NULL;
@@ -206,7 +206,7 @@ void libxl__logv(libxl_ctx *ctx, xentoollog_level msglevel, int errnoval,
 
 void libxl__log(libxl_ctx *ctx, xentoollog_level msglevel, int errnoval,
             const char *file, int line, const char *func,
-            char *fmt, ...)
+            const char *fmt, ...)
 {
     va_list ap;
     va_start(ap, fmt);
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 41de6fd..1d1dc35 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -80,13 +80,13 @@
 _hidden void libxl__logv(libxl_ctx *ctx, xentoollog_level msglevel, int errnoval,
              const char *file /* may be 0 */, int line /* ignored if !file */,
              const char *func /* may be 0 */,
-             char *fmt, va_list al)
+             const char *fmt, va_list al)
      __attribute__((format(printf,7,0)));
 
 _hidden void libxl__log(libxl_ctx *ctx, xentoollog_level msglevel, int errnoval,
             const char *file /* may be 0 */, int line /* ignored if !file */,
             const char *func /* may be 0 */,
-            char *fmt, ...)
+            const char *fmt, ...)
      __attribute__((format(printf,7,8)));
 
      /* these functions preserve errno (saving and restoring) */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 18:11:31 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 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.xensource.com>)
	id 1RXd0V-00068L-Lt; Mon, 05 Dec 2011 18:11:15 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RXd0T-00065u-1O
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 18:11:13 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1323108624!1307875!5
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjAyNg==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27171 invoked from network); 5 Dec 2011 18:10:26 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Dec 2011 18:10:26 -0000
X-IronPort-AV: E=Sophos;i="4.71,300,1320624000"; 
   d="scan'208";a="9297523"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Dec 2011 18:10:26 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 5 Dec 2011 18:10:26 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RXczi-0003k3-By; Mon, 05 Dec 2011 18:10:26 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RXczi-0006W5-BC;
	Mon, 05 Dec 2011 18:10:26 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Mon, 5 Dec 2011 18:10:10 +0000
Message-ID: <1323108621-22654-5-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1323108621-22654-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1323108621-22654-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 04/15] libxl: idl: support new "private" type
	attribute
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This provides for fields in libxl datatypes which are only present in
the C version of structures and are used only by libxl itself.  This
is useful when a libxl datatype wants to contain fields which are used
by libxl internally and which are only present in the structure to
avoid additional memory allocation inconvenience.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/gentest.py    |    2 ++
 tools/libxl/libxltypes.py |    4 +++-
 tools/python/genwrap.py   |    7 +++++++
 3 files changed, 12 insertions(+), 1 deletions(-)

diff --git a/tools/libxl/gentest.py b/tools/libxl/gentest.py
index 05e77cc..ac7a400 100644
--- a/tools/libxl/gentest.py
+++ b/tools/libxl/gentest.py
@@ -56,6 +56,8 @@ def gen_rand_init(ty, v, indent = "    ", parent = None):
         s += "%s = rand() %% 2;\n" % v
     elif ty.typename in ["char *"]:
         s += "%s = rand_str();\n" % v
+    elif ty.private:
+        pass
     elif ty.typename in handcoded:
         raise Exception("Gen for handcoded %s" % ty.typename)
     else:
diff --git a/tools/libxl/libxltypes.py b/tools/libxl/libxltypes.py
index 55056c2..450de88 100644
--- a/tools/libxl/libxltypes.py
+++ b/tools/libxl/libxltypes.py
@@ -33,6 +33,8 @@ class Type(object):
         if self.passby not in [PASS_BY_VALUE, PASS_BY_REFERENCE]:
             raise ValueError
 
+        self.private = kwargs.setdefault('private', False)
+
         if typename is None: # Anonymous type
             self.typename = None
             self.rawname = None
@@ -50,7 +52,7 @@ class Type(object):
 
         self.autogenerate_dispose_fn = kwargs.setdefault('autogenerate_dispose_fn', True)
 
-        if self.typename is not None:
+        if self.typename is not None and not self.private:
             self.json_fn = kwargs.setdefault('json_fn', self.typename + "_gen_json")
         else:
             self.json_fn = kwargs.setdefault('json_fn', None)
diff --git a/tools/python/genwrap.py b/tools/python/genwrap.py
index d0c193d..ecbec11 100644
--- a/tools/python/genwrap.py
+++ b/tools/python/genwrap.py
@@ -129,6 +129,8 @@ static PyObject *Py%(rawname)s_new(PyTypeObject *type, PyObject *args, PyObject
 
     l.append('static PyGetSetDef Py%s_getset[] = {'%ty.rawname)
     for f in ty.fields:
+        if f.type.private:
+            continue
         l.append('    { .name = "%s", '%f.name)
         if ty.marshal_out():
             l.append('      .get = (getter)py_%s_%s_get, '%(ty.rawname, f.name))
@@ -295,9 +297,14 @@ _hidden int genwrap__ll_set(PyObject *v, long long *val, long long mask);
 
 """ % tuple((' '.join(sys.argv),) + (os.path.split(decls)[-1:]),))
     for ty in types:
+        if ty.private:
+            continue
         if isinstance(ty, libxltypes.Aggregate):
             f.write('/* Attribute get/set functions for %s */\n'%ty.typename)
             for a in ty.fields:
+                print >>sys.stderr, `a`, `ty`, `a.type`, `a.type.__dict__`
+                if a.type.private:
+                    continue
                 if ty.marshal_out():
                     f.write(py_attrib_get(ty,a))
                 if ty.marshal_in():
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 18:11:31 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 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.xensource.com>)
	id 1RXd0Z-0006Ao-Cv; Mon, 05 Dec 2011 18:11:19 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RXd0V-000666-NR
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 18:11:16 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1323108629!5440616!5
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjAyNg==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14126 invoked from network); 5 Dec 2011 18:10:31 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Dec 2011 18:10:31 -0000
X-IronPort-AV: E=Sophos;i="4.71,300,1320624000"; 
   d="scan'208";a="9297534"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Dec 2011 18:10:30 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 5 Dec 2011 18:10:30 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RXczm-0003kb-ER; Mon, 05 Dec 2011 18:10:30 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RXczm-0006Wn-DU;
	Mon, 05 Dec 2011 18:10:30 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Mon, 5 Dec 2011 18:10:21 +0000
Message-ID: <1323108621-22654-16-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1323108621-22654-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1323108621-22654-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 15/15] libxl: New event generation API
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Replace the existing API for retrieving high-level events (events
about domains, etc.) from libxl with a new one.

This changes the definition and semantics of the `libxl_event'
structure, and replaces the calls for obtaining information about
domain death and disk eject events.

This is an incompatible change, sorry.  The alternative was to try to
provide both the previous horrid API and the new one, and would also
involve never using the name `libxl_event' for the new interface.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl.c          |  302 ++++++++++++++++++++++++++++++------------
 tools/libxl/libxl.h          |   55 ++-------
 tools/libxl/libxl_event.c    |  188 ++++++++++++++++++++++++---
 tools/libxl/libxl_event.h    |  180 ++++++++++++++++++++++++-
 tools/libxl/libxl_internal.c |    6 +
 tools/libxl/libxl_internal.h |   81 +++++++++++-
 tools/libxl/libxl_types.idl  |   35 ++++-
 tools/libxl/xl_cmdimpl.c     |  270 ++++++++++++++++++++++----------------
 8 files changed, 839 insertions(+), 278 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 58f280c..ba9293b 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -60,8 +60,11 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
      * only as an initialiser, not as an expression. */
     memcpy(&ctx->lock, &mutex_value, sizeof(ctx->lock));
 
+    LIBXL_TAILQ_INIT(&ctx->occurred);
+
     ctx->osevent_hooks = 0;
 
+    ctx->fd_polls = 0;
     ctx->fd_beforepolled = 0;
     LIBXL_LIST_INIT(&ctx->efds);
     LIBXL_TAILQ_INIT(&ctx->etimes);
@@ -70,6 +73,9 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
     LIBXL_SLIST_INIT(&ctx->watch_freeslots);
     libxl__ev_fd_init(&ctx->watch_efd);
 
+    LIBXL_TAILQ_INIT(&ctx->death_list);
+    libxl__ev_xswatch_init(&ctx->death_watch);
+
     if ( stat(XENSTORE_PID_FILE, &stat_buf) != 0 ) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "Is xenstore daemon running?\n"
                      "failed to stat %s", XENSTORE_PID_FILE);
@@ -97,6 +103,13 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
     return 0;
 }
 
+static void free_disable_deaths(libxl__gc *gc,
+                                struct libxl__evgen_domain_death_list *l) {
+    libxl_evgen_domain_death *death;
+    while ((death = LIBXL_TAILQ_FIRST(l)))
+        libxl__evdisable_domain_death(gc, death);
+}
+
 int libxl_ctx_free(libxl_ctx *ctx)
 {
     int i;
@@ -104,6 +117,9 @@ int libxl_ctx_free(libxl_ctx *ctx)
 
     if (!ctx) return 0;
 
+    free_disable_deaths(gc, &CTX->death_list);
+    free_disable_deaths(gc, &CTX->death_reported);
+
     for (i = 0; i < ctx->watch_nslots; i++)
         assert(!libxl__watch_slot_contents(gc, i));
     libxl__ev_fd_deregister(gc, &ctx->watch_efd);
@@ -115,6 +131,7 @@ int libxl_ctx_free(libxl_ctx *ctx)
     libxl_version_info_dispose(&ctx->version_info);
     if (ctx->xsh) xs_daemon_close(ctx->xsh);
 
+    free(ctx->fd_polls);
     free(ctx->fd_beforepolled);
     free(ctx->watch_slots);
 
@@ -614,117 +631,173 @@ int libxl_domain_shutdown(libxl_ctx *ctx, uint32_t domid, int req)
     return 0;
 }
 
-int libxl_get_wait_fd(libxl_ctx *ctx, int *fd)
-{
-    *fd = xs_fileno(ctx->xsh);
-    return 0;
-}
+static void domain_death_xswatch_callback(libxl__gc *gc, libxl__ev_xswatch *w,
+                                        const char *wpath, const char *epath) {
+    libxl_evgen_domain_death *evg;
+    uint32_t domid;
+    int rc;
 
-int libxl_wait_for_domain_death(libxl_ctx *ctx, uint32_t domid, libxl_waiter *waiter)
-{
-    waiter->path = strdup("@releaseDomain");
-    if (asprintf(&(waiter->token), "%d", LIBXL_EVENT_TYPE_DOMAIN_DEATH) < 0)
-        return -1;
-    if (!xs_watch(ctx->xsh, waiter->path, waiter->token))
-        return -1;
-    return 0;
-}
+    CTX_LOCK;
 
-int libxl_wait_for_disk_ejects(libxl_ctx *ctx, uint32_t guest_domid, libxl_device_disk *disks, int num_disks, libxl_waiter *waiter)
-{
-    GC_INIT(ctx);
-    int i, rc = -1;
-    uint32_t domid = libxl_get_stubdom_id(ctx, guest_domid);
+    evg = LIBXL_TAILQ_FIRST(&CTX->death_list);
+    if (!evg) goto out;
 
-    if (!domid)
-        domid = guest_domid;
+    domid = evg->domid;
 
-    for (i = 0; i < num_disks; i++) {
-        if (asprintf(&(waiter[i].path), "%s/device/vbd/%d/eject",
-                     libxl__xs_get_dompath(gc, domid),
-                     libxl__device_disk_dev_number(disks[i].vdev,
-                                                   NULL, NULL)) < 0)
-            goto out;
-        if (asprintf(&(waiter[i].token), "%d", LIBXL_EVENT_TYPE_DISK_EJECT) < 0)
+    for (;;) {
+        int nentries = LIBXL_TAILQ_NEXT(evg, entry) ? 200 : 1;
+        xc_domaininfo_t domaininfos[nentries];
+        const xc_domaininfo_t *got = domaininfos, *gotend;
+
+        rc = xc_domain_getinfolist(CTX->xch, domid, nentries, domaininfos);
+        if (rc == -1) {
+            LIBXL__EVENT_DISASTER(gc, "xc_domain_getinfolist failed while"
+                                  " processing @releaseDomain watch event",
+                                  errno, 0);
             goto out;
-        xs_watch(ctx->xsh, waiter[i].path, waiter[i].token);
+        }
+        gotend = &domaininfos[rc];
+
+        for (;;) {
+            if (!evg)
+                goto all_reported;
+
+            if (!rc || got->domain > evg->domid) {
+                /* ie, the list doesn't contain evg->domid any more so
+                 * the domain has been destroyed */
+                libxl_evgen_domain_death *evg_next;
+
+                libxl_event *ev = NEW_EVENT(gc, DOMAIN_DESTROY, evg->domid);
+                if (!ev) goto out;
+
+                libxl__event_occurred(gc, ev);
+
+                evg->death_reported = 1;
+                evg_next = LIBXL_TAILQ_NEXT(evg, entry);
+                LIBXL_TAILQ_REMOVE(&CTX->death_list, evg, entry);
+                LIBXL_TAILQ_INSERT_HEAD(&CTX->death_reported, evg, entry);
+                evg = evg_next;
+
+                continue;
+            }
+            
+            if (got == gotend)
+                break;
+
+            if (got->domain < evg->domid) {
+                got++;
+                continue;
+            }
+
+            assert(evg->domid == got->domain);
+
+            if (!evg->shutdown_reported &&
+                (got->flags & XEN_DOMINF_shutdown)) {
+                libxl_event *ev = NEW_EVENT(gc, DOMAIN_SHUTDOWN, got->domain);
+                if (!ev) goto out;
+                
+                ev->u.domain_shutdown.shutdown_reason =
+                    (got->flags >> XEN_DOMINF_shutdownshift) &
+                    XEN_DOMINF_shutdownmask;
+                libxl__event_occurred(gc, ev);
+
+                evg->shutdown_reported = 1;
+            }
+            evg = LIBXL_TAILQ_NEXT(evg, entry);
+        }
+
+        assert(rc); /* rc==0 results in us eating all evgs and quitting */
+        domid = gotend[-1].domain;
     }
-    rc = 0;
-out:
-    GC_FREE;
-    return rc;
+ all_reported:
+ out:
+
+    CTX_UNLOCK;
 }
 
-int libxl_get_event(libxl_ctx *ctx, libxl_event *event)
-{
-    unsigned int num;
-    char **events = xs_read_watch(ctx->xsh, &num);
-    if (num != 2) {
-        free(events);
-        return ERROR_FAIL;
+int libxl_evenable_domain_death(libxl_ctx *ctx, uint32_t domid,
+                libxl_ev_user user, libxl_evgen_domain_death **evgen_out) {
+    GC_INIT(ctx);
+    libxl_evgen_domain_death *evg, *evg_search;
+    int rc;
+    
+    CTX_LOCK;
+
+    evg = malloc(sizeof(*evg));  if (!evg) { rc = ERROR_NOMEM; goto out; }
+    memset(evg, 0, sizeof(*evg));
+    evg->domid = domid;
+    evg->user = user;
+
+    LIBXL_TAILQ_INSERT_SORTED(&ctx->death_list, entry, evg, evg_search, ,
+                              evg->domid > evg_search->domid);
+
+    if (!libxl__ev_xswatch_isregistered(&ctx->death_watch)) {
+        rc = libxl__ev_xswatch_register(gc, &ctx->death_watch,
+                        domain_death_xswatch_callback, "@releaseDomain");
+        if (rc) { libxl__evdisable_domain_death(gc, evg); goto out; }
     }
-    event->path = strdup(events[XS_WATCH_PATH]);
-    event->token = strdup(events[XS_WATCH_TOKEN]);
-    event->type = atoi(event->token);
-    free(events);
-    return 0;
-}
 
-int libxl_stop_waiting(libxl_ctx *ctx, libxl_waiter *waiter)
-{
-    if (!xs_unwatch(ctx->xsh, waiter->path, waiter->token))
-        return ERROR_FAIL;
-    else
-        return 0;
-}
+    rc = 0;
 
-int libxl_free_event(libxl_event *event)
-{
-    free(event->path);
-    free(event->token);
-    return 0;
-}
+ out:
+    CTX_UNLOCK;
+    return rc;
+};
 
-int libxl_free_waiter(libxl_waiter *waiter)
-{
-    free(waiter->path);
-    free(waiter->token);
-    return 0;
-}
+void libxl__evdisable_domain_death(libxl__gc *gc,
+                                   libxl_evgen_domain_death *evg) {
+    CTX_LOCK;
 
-int libxl_event_get_domain_death_info(libxl_ctx *ctx, uint32_t domid, libxl_event *event, libxl_dominfo *info)
-{
-    if (libxl_domain_info(ctx, info, domid) < 0)
-        return 0;
+    if (!evg->death_reported)
+        LIBXL_TAILQ_REMOVE(&CTX->death_list, evg, entry);
+    else
+        LIBXL_TAILQ_REMOVE(&CTX->death_reported, evg, entry);
 
-    if (info->running || (!info->shutdown && !info->dying))
-        return ERROR_INVAL;
+    free(evg);
+
+    if (!LIBXL_TAILQ_FIRST(&CTX->death_list) &&
+        libxl__ev_xswatch_isregistered(&CTX->death_watch))
+        libxl__ev_xswatch_deregister(gc, &CTX->death_watch);
 
-    return 1;
+    CTX_UNLOCK;
 }
 
-int libxl_event_get_disk_eject_info(libxl_ctx *ctx, uint32_t domid, libxl_event *event, libxl_device_disk *disk)
-{
+void libxl_evdisable_domain_death(libxl_ctx *ctx,
+                                  libxl_evgen_domain_death *evg) {
     GC_INIT(ctx);
-    char *path;
+    libxl__evdisable_domain_death(gc, evg);
+    GC_FREE;
+}
+
+static void disk_eject_xswatch_callback(libxl__gc *gc, libxl__ev_xswatch *watch,
+                                        const char *wpath, const char *epath) {
+    libxl_evgen_disk_eject *evg = (void*)watch;
     char *backend;
     char *value;
     char backend_type[BACKEND_STRING_SIZE+1];
 
-    value = libxl__xs_read(gc, XBT_NULL, event->path);
+    value = libxl__xs_read(gc, XBT_NULL, wpath);
 
-    if (!value || strcmp(value,  "eject")) {
-        GC_FREE;
-        return 0;
+    if (!value || strcmp(value,  "eject"))
+        return;
+
+    if (libxl__xs_write(gc, XBT_NULL, wpath, "")) {
+        LIBXL__EVENT_DISASTER(gc, "xs_write failed acknowledging eject",
+                              errno, LIBXL_EVENT_TYPE_DISK_EJECT);
+        return;
     }
 
-    path = strdup(event->path);
-    path[strlen(path) - 6] = '\0';
-    backend = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/backend", path));
+    libxl_event *ev = NEW_EVENT(gc, DISK_EJECT, evg->domid);
+    libxl_device_disk *disk = &ev->u.disk_eject.disk;
+    
+    backend = libxl__xs_read(gc, XBT_NULL,
+                             libxl__sprintf(gc, "%.*s/backend",
+                                            (int)strlen(wpath)-6, wpath));
 
     sscanf(backend,
-            "/local/domain/%d/backend/%" TOSTRING(BACKEND_STRING_SIZE) "[a-z]/%*d/%*d",
-            &disk->backend_domid, backend_type);
+            "/local/domain/%d/backend/%" TOSTRING(BACKEND_STRING_SIZE)
+           "[a-z]/%*d/%*d",
+           &disk->backend_domid, backend_type);
     if (!strcmp(backend_type, "tap") || !strcmp(backend_type, "vbd")) {
         disk->backend = LIBXL_DISK_BACKEND_TAP;
     } else if (!strcmp(backend_type, "qdisk")) {
@@ -733,19 +806,72 @@ int libxl_event_get_disk_eject_info(libxl_ctx *ctx, uint32_t domid, libxl_event
         disk->backend = LIBXL_DISK_BACKEND_UNKNOWN;
     }
 
-    disk->pdev_path = strdup("");
+    disk->pdev_path = strdup(""); /* xxx fixme malloc failure */
     disk->format = LIBXL_DISK_FORMAT_EMPTY;
     /* this value is returned to the user: do not free right away */
-    disk->vdev = xs_read(ctx->xsh, XBT_NULL, libxl__sprintf(gc, "%s/dev", backend), NULL);
+    disk->vdev = xs_read(CTX->xsh, XBT_NULL,
+                         libxl__sprintf(gc, "%s/dev", backend), NULL);
     disk->removable = 1;
     disk->readwrite = 0;
     disk->is_cdrom = 1;
 
-    free(path);
+    libxl__event_occurred(gc, ev);
+}
+
+int libxl_evenable_disk_eject(libxl_ctx *ctx, uint32_t guest_domid,
+                              const char *vdev, libxl_ev_user user,
+                              libxl_evgen_disk_eject **evgen_out) {
+    GC_INIT(ctx);
+    int rc;
+    char *path;
+    libxl_evgen_disk_eject *evg = NULL;
+
+    evg = malloc(sizeof(*evg));  if (!evg) { rc = ERROR_NOMEM; goto out; }
+    memset(evg, 0, sizeof(*evg));
+    evg->user = user;
+    evg->domid = guest_domid;
+
+    evg->vdev = strdup(vdev);
+    if (!evg->vdev) { rc = ERROR_NOMEM; goto out; }
+
+    uint32_t domid = libxl_get_stubdom_id(ctx, guest_domid);
+
+    if (!domid)
+        domid = guest_domid;
+
+    path = libxl__sprintf(gc, "%s/device/vbd/%d/eject",
+                 libxl__xs_get_dompath(gc, domid),
+                 libxl__device_disk_dev_number(vdev, NULL, NULL));
+    if (!path) { rc = ERROR_NOMEM; goto out; }
+
+    rc = libxl__ev_xswatch_register(gc, &evg->watch,
+                                    disk_eject_xswatch_callback, path);
+    if (rc) goto out;
+
     GC_FREE;
-    return 1;
+    return 0;
+
+ out:
+    if (evg)
+        libxl__evdisable_disk_eject(gc, evg);
+    GC_FREE;
+    return rc;
 }
 
+void libxl__evdisable_disk_eject(libxl__gc *gc, libxl_evgen_disk_eject *evg) {
+    if (libxl__ev_xswatch_isregistered(&evg->watch))
+        libxl__ev_xswatch_deregister(gc, &evg->watch);
+
+    free(evg->vdev);
+    free(evg);
+}
+
+void libxl_evdisable_disk_eject(libxl_ctx *ctx, libxl_evgen_disk_eject *evg) {
+    GC_INIT(ctx);
+    libxl__evdisable_disk_eject(gc, evg);
+    GC_FREE;
+}    
+
 int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid, int force)
 {
     GC_INIT(ctx);
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 654a5b0..17b15a6 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -53,7 +53,10 @@
  *    A public function may be called from within libxl; the call
  *    context initialisation macros will make sure that the internal
  *    caller's context is reused (eg, so that the same xenstore
- *    transaction is used).
+ *    transaction is used).  But in-libxl callers of libxl public
+ *    functions should note that any libxl public function may cause
+ *    recursively reentry into libxl via the application's event
+ *    callback hook.
  *
  *    Public functions have names like libxl_foobar.
  *
@@ -152,6 +155,8 @@ void libxl_key_value_list_dispose(libxl_key_value_list *kvl);
 
 typedef uint32_t libxl_hwcap[8];
 
+typedef uint64_t libxl_ev_user;
+
 typedef struct {
     uint32_t size;          /* number of bytes in map */
     uint8_t *map;
@@ -200,6 +205,9 @@ typedef struct {
     int v;
 } libxl_enum_string_table;
 
+struct libxl_event;
+typedef LIBXL_TAILQ_ENTRY(struct libxl_event) libxl_ev_link;
+
 typedef struct libxl__ctx libxl_ctx;
 
 #include "_libxl_types.h"
@@ -298,51 +306,6 @@ int libxl_run_bootloader(libxl_ctx *ctx,
 
   /* 0 means ERROR_ENOMEM, which we have logged */
 
-/* events handling */
-
-typedef struct {
-    /* event type */
-    libxl_event_type type;
-    /* data for internal use of the library */
-    char *path;
-    char *token;
-} libxl_event;
-
-typedef struct {
-    char *path;
-    char *token;
-} libxl_waiter;
-
-
-int libxl_get_wait_fd(libxl_ctx *ctx, int *fd);
-/* waiter is allocated by the caller */
-int libxl_wait_for_domain_death(libxl_ctx *ctx, uint32_t domid, libxl_waiter *waiter);
-/* waiter is a preallocated array of num_disks libxl_waiter elements */
-int libxl_wait_for_disk_ejects(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *disks, int num_disks, libxl_waiter *waiter);
-int libxl_get_event(libxl_ctx *ctx, libxl_event *event);
-int libxl_stop_waiting(libxl_ctx *ctx, libxl_waiter *waiter);
-int libxl_free_event(libxl_event *event);
-int libxl_free_waiter(libxl_waiter *waiter);
-
-/*
- * Returns:
- *  - 0 if the domain is dead but there is no cleanup to be done. e.g
- *    because someone else has already done it.
- *  - 1 if the domain is dead and there is cleanup to be done.
- *
- * Can return error if the domain exists and is still running.
- *
- * *info will contain valid domain state iff 1 is returned. In
- * particular if 1 is returned then info->shutdown_reason is
- * guaranteed to be valid since by definition the domain is
- * (shutdown||dying))
- */
-int libxl_event_get_domain_death_info(libxl_ctx *ctx, uint32_t domid, libxl_event *event, libxl_dominfo *info);
-
-/*
- * Returns true and fills *disk if the caller should eject the disk
- */
-int libxl_event_get_disk_eject_info(libxl_ctx *ctx, uint32_t domid, libxl_event *event, libxl_device_disk *disk);
 
 int libxl_domain_rename(libxl_ctx *ctx, uint32_t domid,
                         const char *old_name, const char *new_name);
diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
index 8d4dbf6..ec5c25e 100644
--- a/tools/libxl/libxl_event.c
+++ b/tools/libxl/libxl_event.c
@@ -493,9 +493,9 @@ void libxl__ev_xswatch_deregister(libxl__gc *gc, libxl__ev_xswatch *w) {
  * osevent poll
  */
 
-int libxl_osevent_beforepoll(libxl_ctx *ctx, int *nfds_io,
-                             struct pollfd *fds, int *timeout_upd,
-                             struct timeval now) {
+static int beforepoll_unlocked(libxl__gc *gc, int *nfds_io,
+                               struct pollfd *fds, int *timeout_upd,
+                               struct timeval now) {
     libxl__ev_fd *efd;
     int i;
 
@@ -506,9 +506,6 @@ int libxl_osevent_beforepoll(libxl_ctx *ctx, int *nfds_io,
      * the fds array corresponds to a slot in fd_beforepolled.
      */
 
-    GC_INIT(ctx);
-    CTX_LOCK;
-
     if (*nfds_io) {
         /*
          * As an optimisation, we don't touch fd_beforepolled_used
@@ -580,16 +577,25 @@ int libxl_osevent_beforepoll(libxl_ctx *ctx, int *nfds_io,
             *timeout_upd = our_timeout;
     }
 
-    CTX_UNLOCK;
-    GC_FREE;
     return rc;
 }
 
-void libxl_osevent_afterpoll(libxl_ctx *ctx, int nfds, const struct pollfd *fds,
+int libxl_osevent_beforepoll(libxl_ctx *ctx, int *nfds_io,
+                             struct pollfd *fds, int *timeout_upd,
                              struct timeval now) {
-    int i;
+
     GC_INIT(ctx);
     CTX_LOCK;
+    int rc = beforepoll_unlocked(gc, nfds_io, fds, timeout_upd, now);
+    CTX_UNLOCK;
+    GC_FREE;
+    return rc;
+}
+
+static void afterpoll_unlocked(libxl__gc *gc,
+                               int nfds, const struct pollfd *fds,
+                               struct timeval now) {
+    int i;
 
     assert(nfds <= CTX->fd_beforepolled_used);
 
@@ -625,12 +631,17 @@ void libxl_osevent_afterpoll(libxl_ctx *ctx, int nfds, const struct pollfd *fds,
 
         etime->func(gc, etime, &etime->abs);
     }
+}
 
+void libxl_osevent_afterpoll(libxl_ctx *ctx, int nfds, const struct pollfd *fds,
+                             struct timeval now) {
+    GC_INIT(ctx);
+    CTX_LOCK;
+    afterpoll_unlocked(gc, nfds, fds, now);
     CTX_UNLOCK;
     GC_FREE;
 }
 
-
 /*
  * osevent hook and callback machinery
  */
@@ -689,11 +700,10 @@ void libxl__event_disaster(libxl__gc *gc, const char *msg, int errnoval,
                type ? libxl_event_type_to_string(type) : "",
                type ? ")" : "");
 
-    /*
-     * FIXME: This should call the "disaster" hook supplied to
-     * libxl_event_register_callbacks, which will be introduced in the
-     * next patch.
-     */
+    if (CTX->event_hooks && CTX->event_hooks->disaster) {
+        CTX->event_hooks->disaster(CTX->event_hooks_user, type, msg, errnoval);
+        return;
+    }
 
     const char verybad[] =
         "DISASTER in event loop not handled by libxl application";
@@ -703,6 +713,152 @@ void libxl__event_disaster(libxl__gc *gc, const char *msg, int errnoval,
 }
 
 /*
+ * Event retrieval etc.
+ */
+
+void libxl_event_register_callbacks(libxl_ctx *ctx,
+                  const libxl_event_hooks *hooks, void *user) {
+    ctx->event_hooks = hooks;
+    ctx->event_hooks_user = user;
+}
+
+void libxl__event_occurred(libxl__gc *gc, libxl_event *event) {
+    if (CTX->event_hooks &&
+        (CTX->event_hooks->event_occurs_mask & (1UL << event->type))) {
+        /* libxl__free_all will call the callback, just before exit
+         * from libxl.  This helps avoid reentrancy bugs: parts of
+         * libxl that call libxl__event_occurred do not have to worry
+         * that libxl might be reentered at that point. */
+        LIBXL_TAILQ_INSERT_TAIL(&gc->occurred_for_callback, event, link);
+        return;
+    } else {
+        LIBXL_TAILQ_INSERT_TAIL(&CTX->occurred, event, link);
+    }
+}
+
+void libxl_event_free(libxl_ctx *ctx, libxl_event *event) {
+    libxl_event_dispose(event);
+    free(event);
+}
+
+libxl_event *libxl__event_new(libxl__gc *gc,
+                              libxl_event_type type, uint32_t domid) {
+    libxl_event *ev;
+
+    ev = malloc(sizeof(*ev));
+    if (!ev) {
+        LIBXL__EVENT_DISASTER(gc, "allocate new event", errno, type);
+        return NULL;
+    }
+
+    memset(ev, 0, sizeof(*ev));
+    ev->type = type;
+    ev->domid = domid;
+
+    return ev;
+}
+
+static int event_check_unlocked(libxl__gc *gc, libxl_event **event_r,
+                                unsigned long typemask,
+                                libxl_event_predicate *pred, void *pred_user) {
+    libxl_event *ev;
+    int rc;
+
+    LIBXL_TAILQ_FOREACH(ev, &CTX->occurred, link) {
+        if (!(typemask & (1UL << ev->type)))
+            continue;
+
+        if (pred && !pred(ev, pred_user))
+            continue;
+
+        /* got one! */
+        LIBXL_TAILQ_REMOVE(&CTX->occurred, ev, link);
+        *event_r = ev;
+        rc = 0;
+        goto out;
+    }
+    rc = ERROR_NOT_READY;
+
+ out:
+    return rc;
+}
+
+int libxl_event_check(libxl_ctx *ctx, libxl_event **event_r,
+                      unsigned long typemask,
+                      libxl_event_predicate *pred, void *pred_user) {
+    GC_INIT(ctx);
+    CTX_LOCK;
+    int rc = event_check_unlocked(gc, event_r, typemask, pred, pred_user);
+    CTX_UNLOCK;
+    GC_FREE;
+    return rc;
+}
+
+int libxl_event_wait(libxl_ctx *ctx, libxl_event **event_r,
+                     unsigned long typemask,
+                     libxl_event_predicate *pred, void *pred_user) {
+    int rc;
+    struct timeval now;
+
+    GC_INIT(ctx);
+    CTX_LOCK;
+
+    for (;;) {
+        rc = event_check_unlocked(gc, event_r, typemask, pred, pred_user);
+        if (rc != ERROR_NOT_READY) goto out;
+
+        rc = libxl__gettimeofday(gc, &now);
+        if (rc) goto out;
+
+        int timeout;
+
+        for (;;) {
+            int nfds = CTX->fd_polls_allocd;
+            timeout = -1;
+            rc = beforepoll_unlocked(gc, &nfds, CTX->fd_polls, &timeout, now);
+            if (!rc) break;
+            if (rc != ERROR_BUFFERFULL) goto out;
+            
+            struct pollfd *newarray =
+                (nfds > INT_MAX / sizeof(struct pollfd) / 2) ? 0 :
+                realloc(CTX->fd_polls, sizeof(*newarray) * nfds);
+            
+            if (!newarray) { rc = ERROR_NOMEM; goto out; }
+
+            CTX->fd_polls = newarray;
+            CTX->fd_polls_allocd = nfds;
+        }
+
+        rc = poll(CTX->fd_polls, CTX->fd_polls_allocd, timeout);
+        if (rc < 0) {
+            if (errno == EINTR) continue;
+            LIBXL__LOG_ERRNOVAL(CTX, LIBXL__LOG_ERROR, errno, "poll failed");
+            rc = ERROR_FAIL;
+            goto out;
+        }
+
+        rc = libxl__gettimeofday(gc, &now);
+        if (rc) goto out;
+
+        afterpoll_unlocked(gc, CTX->fd_polls_allocd, CTX->fd_polls, now);
+
+        /* we unlock and free the gc each time we go through this loop,
+         * so that (a) we don't accumulate garbage and (b) any events
+         * which are to be dispatched by callback are actually delivered
+         * in a timely fashion.
+         */
+        CTX_UNLOCK;
+        libxl__free_all(gc);
+        CTX_LOCK;
+    }
+
+ out:
+    CTX_UNLOCK;
+    GC_FREE;
+    return rc;
+}
+
+/*
  * Local variables:
  * mode: C
  * c-basic-offset: 4
diff --git a/tools/libxl/libxl_event.h b/tools/libxl/libxl_event.h
index 25efbdf..bbe1ed0 100644
--- a/tools/libxl/libxl_event.h
+++ b/tools/libxl/libxl_event.h
@@ -18,6 +18,178 @@
 
 #include <libxl.h>
 
+/*======================================================================*/
+
+/*
+ * Domain event handling - getting Xen events from libxl
+ */
+
+#define LIBXL_EVENTMASK_ALL (~(unsigned long)0)
+
+typedef int libxl_event_predicate(const libxl_event*, void *user);
+  /* Return value is 0 if the event is unwanted or non-0 if it is.
+   * Predicates are not allowed to fail.
+   */
+
+int libxl_event_check(libxl_ctx *ctx, libxl_event **event_r,
+                      unsigned long typemask,
+                      libxl_event_predicate *predicate, void *predicate_user);
+  /* Searches for an event, already-happened, which matches typemask
+   * and predicate.  predicate==0 matches any event.
+   * libxl_event_check returns the event, which must then later be
+   * freed by the caller using libxl_event_free.
+   *
+   * Returns ERROR_NOT_READY if no such event has happened.
+   */
+
+int libxl_event_wait(libxl_ctx *ctx, libxl_event **event_r,
+                     unsigned long typemask,
+                     libxl_event_predicate *predicate, void *predicate_user);
+  /* Like libxl_event_check but blocks if no suitable events are
+   * available, until some are.  Uses libxl_osevent_beforepoll/
+   * _afterpoll so may be inefficient if very many domains are being
+   * handled by a single program.
+   */
+
+void libxl_event_free(libxl_ctx *ctx, libxl_event *event);
+
+
+/* Alternatively or additionally, the application may also use this: */
+
+typedef struct libxl_event_hooks {
+    uint64_t event_occurs_mask;
+    void (*event_occurs)(void *user, const libxl_event *event);
+    void (*disaster)(void *user, libxl_event_type type,
+                     const char *msg, int errnoval);
+} libxl_event_hooks;
+
+void libxl_event_register_callbacks(libxl_ctx *ctx,
+                                    const libxl_event_hooks *hooks, void *user);
+  /*
+   * Arranges that libxl will henceforth call event_occurs for any
+   * events whose type is set in event_occurs_mask, rather than
+   * queueing the event for retrieval by libxl_event_check/wait.
+   * Events whose bit is clear in mask are not affected.
+   *
+   * event becomes owned by the application and must be freed, either
+   * by event_occurs or later.
+   *
+   * event_occurs may be NULL if mask is 0.
+   *
+   * libxl_event_register_callback also provides a way for libxl to
+   * report to the application that there was a problem reporting
+   * events; this can occur due to lack of host memory during event
+   * handling, or other wholly unrecoverable errors from system calls
+   * made by libxl.  This will not happen for frivolous reasons - only
+   * if the system, or the Xen components of it, are badly broken.
+   *
+   * msg and errnoval will describe the action that libxl was trying
+   * to do, and type specifies the type of libxl events which may be
+   * missing.  type may be 0 in which case events of all types may be
+   * missing.
+   *
+   * disaster may be NULL.  If it is, or if _register_callbacks has
+   * not been called, errors of this kind are fatal to the entire
+   * application: libxl will print messages to its logs and to stderr
+   * and call exit(-1).
+   *
+   * If disaster returns, it may be the case that some or all future
+   * libxl calls will return errors; likewise it may be the case that
+   * no more events (of the specified type, if applicable) can be
+   * produced.  An application which supplies a disaster function
+   * should normally react either by exiting, or by (when it has
+   * returned to its main event loop) shutting down libxl with
+   * libxl_ctx_free and perhaps trying to restart it with
+   * libxl_ctx_init.
+   *
+   * In any case before calling disaster, libxl will have logged a
+   * message with level XTL_CRITICAL.
+   *
+   * Reentrancy: it IS permitted to call libxl from within
+   * event_occurs.  It is NOT permitted to call libxl from within
+   * disaster.
+   *
+   * libxl_event_register_callbacks may be called as many times, with
+   * 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.
+   */
+
+
+/*
+ * Events are only generated if they have been requested.
+ * The following functions request the generation of specific events.
+ *
+ * Each set of functions for controlling event generation has this form:
+ *
+ *   typedef struct libxl__evgen_FOO libxl__evgen_FOO;
+ *   int libxl_evenable_FOO(libxl_ctx *ctx, FURTHER PARAMETERS,
+ *                          libxl_ev_user user, libxl__evgen_FOO **evgen_out);
+ *   void libxl_evdisable_FOO(libxl_ctx *ctx, libxl__evgen_FOO *evgen);
+ *
+ * The evenable function arranges that the events (as described in the
+ * doc comment for the individual function) will start to be generated
+ * by libxl.  On success, *evgen_out is set to a non-null pointer to
+ * an opaque struct.
+ *
+ * The user value is returned in the generated events and may be
+ * used by the caller for whatever it likes.  The type ev_user is
+ * guaranteed to be an unsigned integer type which is at least
+ * as big as uint64_t and is also guaranteed to be big enough to
+ * contain any intptr_t value.
+ *
+ * If it becomes desirable to stop generation of the relevant events,
+ * or to reclaim the resources in libxl associated with the evgen
+ * structure, the same evgen value should be passed to the evdisable
+ * function.  However, note that events which occurred prior to the
+ * evdisable call may still be returned.
+ *
+ * The caller may enable identical events more than once.  If they do
+ * so, each actual occurrence will generate several events to be
+ * returned by libxl_event_check, with the appropriate user value(s).
+ * Aside from this, each occurrence of each event is returned by
+ * libxl_event_check exactly once.
+ *
+ * An evgen is associated with the libxl_ctx used for its creation.
+ * After libxl_ctx_free, all corresponding evgen handles become
+ * invalid and must no longer be passed to evdisable.
+ *
+ * Events enabled with evenable prior to a fork and libxl_ctx_postfork
+ * are no longer generated after the fork/postfork; however the evgen
+ * structures are still valid and must be passed to evdisable if the
+ * memory they use should not be leaked.
+ *
+ * Applications should ensure that they eventually retrieve every
+ * event using libxl_event_check or libxl_event_wait, since events
+ * which occur but are not retreived by the application will be queued
+ * inside libxl indefinitely.  libxl_event_check/_wait may be O(n)
+ * where n is the number of queued events which do not match the
+ * criteria specified in the arguments to check/wait.
+ */
+
+typedef struct libxl__evgen_domain_death libxl_evgen_domain_death;
+int libxl_evenable_domain_death(libxl_ctx *ctx, uint32_t domid,
+                         libxl_ev_user, libxl_evgen_domain_death **evgen_out);
+void libxl_evdisable_domain_death(libxl_ctx *ctx, libxl_evgen_domain_death*);
+  /* Arranges for the generation of DOMAIN_SHUTDOWN and DOMAIN_DESTROY
+   * events.  A domain which is destroyed before it shuts down
+   * may generate only a DESTROY event.
+   */
+
+typedef struct libxl__evgen_disk_eject libxl_evgen_disk_eject;
+int libxl_evenable_disk_eject(libxl_ctx *ctx, uint32_t domid, const char *vdev,
+                        libxl_ev_user, libxl_evgen_disk_eject **evgen_out);
+void libxl_evdisable_disk_eject(libxl_ctx *ctx, libxl_evgen_disk_eject*);
+  /* Arranges for the generation of DISK_EJECT events.  A copy of the
+   * string *vdev will be made for libxl's internal use, and a pointer
+   * to this (or some other) copy will be returned as the vdev
+   * member of event.u.
+   */
+
 
 /*======================================================================*/
 
@@ -36,10 +208,10 @@
  *      poll();
  *      libxl_osevent_afterpoll(...);
  *      for (;;) {
- *        r=libxl_event_check(...);
- *        if (r==LIBXL_NOT_READY) break;
- *        if (r) handle failure;
- *        do something with the event;
+ *          r = libxl_event_check(...);
+ *          if (r==LIBXL_NOT_READY) break;
+ *          if (r) goto error_out;
+ *          do something with the event;
  *      }
  *   }
  *
diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c
index a2e5820..314ae0d 100644
--- a/tools/libxl/libxl_internal.c
+++ b/tools/libxl/libxl_internal.c
@@ -74,6 +74,12 @@ void libxl__free_all(libxl__gc *gc)
     free(gc->alloc_ptrs);
     gc->alloc_ptrs = 0;
     gc->alloc_maxsize = 0;
+
+    libxl_event *ev, *ev_tmp;
+    LIBXL_TAILQ_FOREACH_SAFE(ev, &gc->occurred_for_callback, link, ev_tmp) {
+        LIBXL_TAILQ_REMOVE(&gc->occurred_for_callback, ev, link);
+        CTX->event_hooks->event_occurs(CTX->event_hooks_user, ev);
+    }
 }
 
 void *libxl__zalloc(libxl__gc *gc, int bytes)
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 88e7dbb..518a06d 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -154,11 +154,44 @@ typedef struct libxl__ev_watch_slot {
     
 libxl__ev_xswatch *libxl__watch_slot_contents(libxl__gc *gc, int slotnum);
 
+
+/*
+ * evgen structures, which are the state we use for generating
+ * events for the caller.
+ *
+ * In general in each case there's an internal and an external
+ * version of the _evdisable_FOO function; the internal one is
+ * used during cleanup.
+ */
+
+struct libxl__evgen_domain_death {
+    uint32_t domid;
+    unsigned shutdown_reported:1, death_reported:1;
+    LIBXL_TAILQ_ENTRY(libxl_evgen_domain_death) entry;
+        /* on list .death_reported ? CTX->death_list : CTX->death_reported */
+    libxl_ev_user user;
+};
+_hidden void
+libxl__evdisable_domain_death(libxl__gc*, libxl_evgen_domain_death*);
+
+struct libxl__evgen_disk_eject {
+    libxl__ev_xswatch watch;
+    uint32_t domid;
+    libxl_ev_user user;
+    char *vdev;
+};
+_hidden void
+libxl__evdisable_disk_eject(libxl__gc*, libxl_evgen_disk_eject*);
+
+
 struct libxl__ctx {
     xentoollog_logger *lg;
     xc_interface *xch;
     struct xs_handle *xsh;
 
+    const libxl_event_hooks *event_hooks;
+    void *event_hooks_user;
+
     pthread_mutex_t lock; /* protects data structures hanging off the ctx */
       /* Always use CTX_LOCK and CTX_UNLOCK to manipulate this.
        *
@@ -171,12 +204,17 @@ struct libxl__ctx {
        * documented in the libxl public interface.
        */
 
+    LIBXL_TAILQ_HEAD(, libxl_event) occurred;
+
     int osevent_in_hook;
     const libxl_osevent_hooks *osevent_hooks;
     void *osevent_user;
       /* See the comment for OSEVENT_HOOK_INTERN in libxl_event.c
        * for restrictions on the use of the osevent fields. */
 
+    struct pollfd *fd_polls;
+    int fd_polls_allocd;
+
     int fd_beforepolled_allocd, fd_beforepolled_used;
     libxl__ev_fd **fd_beforepolled; /* see libxl_osevent_beforepoll */
     LIBXL_LIST_HEAD(, libxl__ev_fd) efds;
@@ -188,6 +226,11 @@ struct libxl__ctx {
     uint32_t watch_counter; /* helps disambiguate slot reuse */
     libxl__ev_fd watch_efd;
 
+    LIBXL_TAILQ_HEAD(libxl__evgen_domain_death_list, libxl_evgen_domain_death)
+        death_list /* sorted by domid */,
+        death_reported;
+    libxl__ev_xswatch death_watch;
+    
     /* for callers who reap children willy-nilly; caller must only
      * set this after libxl_init and before any other call - or
      * may leave them untouched */
@@ -223,12 +266,14 @@ struct libxl__gc {
     int alloc_maxsize;
     void **alloc_ptrs;
     libxl_ctx *owner;
+    LIBXL_TAILQ_HEAD(, libxl_event) occurred_for_callback;
 };
 
-#define LIBXL_INIT_GC(gc,ctx) do{               \
-        (gc).alloc_maxsize = 0;                 \
-        (gc).alloc_ptrs = 0;                    \
-        (gc).owner = (ctx);                     \
+#define LIBXL_INIT_GC(gc,ctx) do{                       \
+        (gc).alloc_maxsize = 0;                         \
+        (gc).alloc_ptrs = 0;                            \
+        (gc).owner = (ctx);                             \
+        LIBXL_TAILQ_INIT(&(gc).occurred_for_callback);  \
     } while(0)
 
 static inline libxl_ctx *libxl__gc_owner(libxl__gc *gc)
@@ -250,7 +295,9 @@ static inline libxl_ctx *libxl__gc_owner(libxl__gc *gc)
  */
 /* register @ptr in @gc for free on exit from outermost libxl callframe. */
 _hidden int libxl__ptr_add(libxl__gc *gc, void *ptr);
-/* if this is the outermost libxl callframe then free all pointers in @gc */
+/* if this is the outermost libxl callframe then free all pointers in @gc
+ *  and report all occurred events via callback, if applicable.
+ * May reenters the application so must not be called with ctx locked. */
 _hidden void libxl__free_all(libxl__gc *gc);
 /* allocate and zero @bytes. (similar to a gc'd malloc(3)+memzero()) */
 _hidden void *libxl__zalloc(libxl__gc *gc, int bytes);
@@ -400,6 +447,25 @@ static inline int libxl__ev_xswatch_isregistered(const libxl__ev_xswatch *xw)
 
 
 
+/*
+ * Other event-handling support provided by the libxl event core to
+ * the rest of libxl.
+ */
+
+_hidden void libxl__event_occurred(libxl__gc*, libxl_event *event);
+  /* Arranges to notify the application that the event has occurred.
+   * event should be suitable for passing to libxl_event_free. */
+
+_hidden libxl_event *libxl__event_new(libxl__gc*, libxl_event_type,
+                                      uint32_t domid);
+  /* Convenience function.
+   * Allocates a new libxl_event, fills in domid and type.
+   * If allocation fails, calls _disaster, and returns NULL. */
+
+#define NEW_EVENT(gc, type, domid)                              \
+    libxl__event_new((gc), LIBXL_EVENT_TYPE_##type, (domid));
+    /* Convenience macro. */
+
 _hidden void libxl__event_disaster(libxl__gc*, const char *msg, int errnoval,
                                    libxl_event_type type /* may be 0 */,
                                    const char *file, int line,
@@ -412,6 +478,9 @@ _hidden void libxl__event_disaster(libxl__gc*, const char *msg, int errnoval,
    * libxl__ev_FOO_callback or an application event), but are
    * prevented from doing so due to eg lack of memory.
    *
+   * See the "disaster" member of libxl_event_hooks and associated
+   * comment in libxl_event.h.
+   *
    * NB that this function may return and the caller isn't supposed to
    * then crash, although it may fail (and henceforth leave things in
    * a state where many or all calls fail).
@@ -892,7 +961,7 @@ libxl__device_model_version_running(libxl__gc *gc, uint32_t domid);
  */
 
 #define GC_INIT(ctx)  libxl__gc gc[1]; LIBXL_INIT_GC(gc[0],ctx)
-#define GC_FREE       libxl__free_all(gc)
+#define GC_FREE       libxl__free_all(gc) /* MUST NOT CALL WITH CTX LOCKED */
 #define CTX           libxl__gc_owner(gc)
 
 
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index d59d2cb..5a713f0 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -75,11 +75,6 @@ libxl_action_on_shutdown = Enumeration("action_on_shutdown", [
     (6, "COREDUMP_RESTART"),
     ])
 
-libxl_event_type = Enumeration("event_type", [
-    (1, "DOMAIN_DEATH"),
-    (2, "DISK_EJECT"),
-    ])
-
 libxl_button = Enumeration("button", [
     (1, "POWER"),
     (2, "SLEEP"),
@@ -381,3 +376,33 @@ libxl_sched_credit = Struct("sched_credit", [
     ("weight", integer),
     ("cap", integer),
     ], dispose_fn=None)
+
+libxl_event_type = Enumeration("event_type", [
+    (1, "DOMAIN_SHUTDOWN"),
+    (2, "DOMAIN_DESTROY"),
+    (3, "DISK_EJECT"),
+    ])
+
+libxl_ev_user = Number("libxl_ev_user")
+
+libxl_ev_link = Builtin("ev_link", passby=PASS_BY_REFERENCE, private=True)
+
+libxl_event = Struct("event",[
+    ("link",     libxl_ev_link,0,
+     "for use by libxl; caller may use this once the event has been"
+     " returned by libxl_event_{check,wait}"),
+    ("domid",    libxl_domid),
+    ("domuuid",  libxl_uuid),
+    ("for_user", libxl_ev_user),
+    ("type",     libxl_event_type),
+    ("u", KeyedUnion(None, libxl_event_type, "type",
+          [("domain_shutdown", Struct(None, [
+                                             ("shutdown_reason", uint8),
+                                      ])),
+           ("domain_destroy", Struct(None, [])),
+           ("disk_eject", Struct(None, [
+                                        ("vdev", string),
+                                        ("disk", libxl_device_disk),
+                                 ])),
+           ]))])
+
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index f1e729c..e5738b7 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -1221,14 +1221,16 @@ skip_vfb:
     xlu_cfg_destroy(config);
 }
 
-/* Returns 1 if domain should be restarted, 2 if domain should be renamed then restarted  */
-static int handle_domain_death(libxl_ctx *ctx, uint32_t domid, libxl_event *event,
-                               libxl_domain_config *d_config, libxl_dominfo *info)
+/* Returns 1 if domain should be restarted,
+ * 2 if domain should be renamed then restarted, or 0 */
+static int handle_domain_death(libxl_ctx *ctx, uint32_t domid,
+                               libxl_event *event,
+                               libxl_domain_config *d_config)
 {
     int restart = 0;
     libxl_action_on_shutdown action;
 
-    switch (info->shutdown_reason) {
+    switch (event->u.domain_shutdown.shutdown_reason) {
     case SHUTDOWN_poweroff:
         action = d_config->on_poweroff;
         break;
@@ -1245,11 +1247,14 @@ static int handle_domain_death(libxl_ctx *ctx, uint32_t domid, libxl_event *even
         action = d_config->on_watchdog;
         break;
     default:
-        LOG("Unknown shutdown reason code %d. Destroying domain.", info->shutdown_reason);
+        LOG("Unknown shutdown reason code %d. Destroying domain.",
+            event->u.domain_shutdown.shutdown_reason);
         action = LIBXL_ACTION_ON_SHUTDOWN_DESTROY;
     }
 
-    LOG("Action for shutdown reason code %d is %s", info->shutdown_reason, action_on_shutdown_names[action]);
+    LOG("Action for shutdown reason code %d is %s",
+        event->u.domain_shutdown.shutdown_reason,
+        action_on_shutdown_names[action]);
 
     if (action == LIBXL_ACTION_ON_SHUTDOWN_COREDUMP_DESTROY || action == LIBXL_ACTION_ON_SHUTDOWN_COREDUMP_RESTART) {
         char *corefile;
@@ -1314,7 +1319,7 @@ static void replace_string(char **str, const char *val)
 
 
 static int preserve_domain(libxl_ctx *ctx, uint32_t domid, libxl_event *event,
-                           libxl_domain_config *d_config, libxl_dominfo *info)
+                           libxl_domain_config *d_config)
 {
     time_t now;
     struct tm tm;
@@ -1426,6 +1431,27 @@ static int autoconnect_console(libxl_ctx *ctx, uint32_t domid, void *priv)
     _exit(1);
 }
 
+static int domain_wait_event(libxl_event **event_r) {
+    int ret;
+    for (;;) {
+        ret = libxl_event_wait(ctx, event_r, LIBXL_EVENTMASK_ALL, 0,0);
+        if (ret) {
+            LOG("Domain %d, failed to get event, quitting (rc=%d)", domid, ret);
+            return ret;
+        }
+        if ((*event_r)->domid != domid) {
+            char *evstr = libxl_event_to_json(ctx, *event_r);
+            LOG("INTERNAL PROBLEM - ignoring unexpected event for"
+                " domain %d (expected %d): event=%s",
+                (*event_r)->domid, domid, evstr);
+            free(evstr);
+            libxl_event_free(ctx, *event_r);
+            continue;
+        }
+        return ret;
+    }
+}
+
 static int create_domain(struct domain_create *dom_info)
 {
     libxl_domain_config d_config;
@@ -1439,10 +1465,11 @@ static int create_domain(struct domain_create *dom_info)
     const char *restore_file = dom_info->restore_file;
     int migrate_fd = dom_info->migrate_fd;
 
-    int fd, i;
+    int i;
     int need_daemon = daemonize;
     int ret, rc;
-    libxl_waiter *w1 = NULL, *w2 = NULL;
+    libxl_evgen_domain_death *deathw = NULL;
+    libxl_evgen_disk_eject **diskws = NULL; /* one per disk */
     void *config_data = 0;
     int config_len = 0;
     int restore_fd = -1;
@@ -1647,14 +1674,14 @@ start:
                 if (errno != EINTR) {
                     perror("failed to wait for daemonizing child");
                     ret = ERROR_FAIL;
-                    goto error_out;
+                    goto out;
                 }
             }
             if (status) {
                 libxl_report_child_exitstatus(ctx, XTL_ERROR,
                            "daemonizing child", child1, status);
                 ret = ERROR_FAIL;
-                goto error_out;
+                goto out;
             }
             ret = domid;
             goto out;
@@ -1691,92 +1718,106 @@ start:
     }
     LOG("Waiting for domain %s (domid %d) to die [pid %ld]",
         d_config.c_info.name, domid, (long)getpid());
-    w1 = (libxl_waiter*) xmalloc(sizeof(libxl_waiter) * d_config.num_disks);
-    w2 = (libxl_waiter*) xmalloc(sizeof(libxl_waiter));
-    libxl_wait_for_disk_ejects(ctx, domid, d_config.disks, d_config.num_disks, w1);
-    libxl_wait_for_domain_death(ctx, domid, w2);
-    libxl_get_wait_fd(ctx, &fd);
-    while (1) {
-        int ret;
-        fd_set rfds;
-        libxl_dominfo info;
-        libxl_event event;
-        libxl_device_disk disk;
 
-        FD_ZERO(&rfds);
-        FD_SET(fd, &rfds);
+    ret = libxl_evenable_domain_death(ctx, domid, 0, &deathw);
+    if (ret) goto out;
 
-        ret = select(fd + 1, &rfds, NULL, NULL, NULL);
-        if (!ret)
-            continue;
-        libxl_get_event(ctx, &event);
-        switch (event.type) {
-            case LIBXL_EVENT_TYPE_DOMAIN_DEATH:
-                ret = libxl_event_get_domain_death_info(ctx, domid, &event, &info);
-
-                if (ret < 0) {
-                    libxl_free_event(&event);
-                    continue;
+    if (!diskws) {
+        diskws = xmalloc(sizeof(*diskws) * d_config.num_disks);
+        for (i = 0; i < d_config.num_disks; i++)
+            diskws[i] = NULL;
+    }
+    for (i = 0; i < d_config.num_disks; i++) {
+        ret = libxl_evenable_disk_eject(ctx, domid, d_config.disks[i].vdev,
+                                        0, &diskws[i]);
+        if (ret) goto out;
+    }
+    while (1) {
+        libxl_event *event;
+        ret = domain_wait_event(&event);
+        if (ret) goto out;
+
+        switch (event->type) {
+
+        case LIBXL_EVENT_TYPE_DOMAIN_SHUTDOWN:
+            LOG("Domain %d has shut down, reason code %d 0x%x", domid,
+                event->u.domain_shutdown.shutdown_reason,
+                event->u.domain_shutdown.shutdown_reason);
+            switch (handle_domain_death(ctx, domid, event, &d_config)) {
+            case 2:
+                if (!preserve_domain(ctx, domid, event, &d_config)) {
+                    /* If we fail then exit leaving the old domain in place. */
+                    ret = -1;
+                    goto out;
                 }
 
-                LOG("Domain %d is dead", domid);
-
-                if (ret) {
-                    switch (handle_domain_death(ctx, domid, &event, &d_config, &info)) {
-                    case 2:
-                        if (!preserve_domain(ctx, domid, &event, &d_config, &info)) {
-                            /* If we fail then exit leaving the old domain in place. */
-                            ret = -1;
-                            goto out;
-                        }
-
-                        /* Otherwise fall through and restart. */
-                    case 1:
-
-                        for (i = 0; i < d_config.num_disks; i++)
-                            libxl_free_waiter(&w1[i]);
-                        libxl_free_waiter(w2);
-                        free(w1);
-                        free(w2);
-
-                        /*
-                         * Do not attempt to reconnect if we come round again due to a
-                         * guest reboot -- the stdin/out will be disconnected by then.
-                         */
-                        dom_info->console_autoconnect = 0;
-
-                        /* Some settings only make sense on first boot. */
-                        paused = 0;
-                        if (common_domname
-                            && strcmp(d_config.c_info.name, common_domname)) {
-                            d_config.c_info.name = strdup(common_domname);
-                        }
-
-                        /*
-                         * XXX FIXME: If this sleep is not there then domain
-                         * re-creation fails sometimes.
-                         */
-                        LOG("Done. Rebooting now");
-                        sleep(2);
-                        goto start;
-                    case 0:
-                        LOG("Done. Exiting now");
-                        ret = 0;
-                        goto out;
-                    }
-                } else {
-                    LOG("Unable to get domain death info, quitting");
-                    goto out;
+                /* Otherwise fall through and restart. */
+            case 1:
+                libxl_event_free(ctx, event);
+                libxl_evdisable_domain_death(ctx, deathw);
+                deathw = NULL;
+                for (i = 0; i < d_config.num_disks; i++) {
+                    libxl_evdisable_disk_eject(ctx, diskws[i]);
+                    diskws[i] = NULL;
                 }
-                break;
-            case LIBXL_EVENT_TYPE_DISK_EJECT:
-                if (libxl_event_get_disk_eject_info(ctx, domid, &event, &disk)) {
-                    libxl_cdrom_insert(ctx, domid, &disk);
-                    libxl_device_disk_dispose(&disk);
+                /* discard any other events which may have been generated */
+                while (!(ret = libxl_event_check(ctx, &event,
+                                                 LIBXL_EVENTMASK_ALL, 0,0))) {
+                    libxl_event_free(ctx, event);
                 }
-                break;
+                if (ret != ERROR_NOT_READY) {
+                    LOG("warning, libxl_event_check (cleanup) failed (rc=%d)",
+                        ret);
+                }
+
+                /*
+                 * Do not attempt to reconnect if we come round again due to a
+                 * guest reboot -- the stdin/out will be disconnected by then.
+                 */
+                dom_info->console_autoconnect = 0;
+
+                /* Some settings only make sense on first boot. */
+                paused = 0;
+                if (common_domname
+                    && strcmp(d_config.c_info.name, common_domname)) {
+                    d_config.c_info.name = strdup(common_domname);
+                }
+
+                /*
+                 * XXX FIXME: If this sleep is not there then domain
+                 * re-creation fails sometimes.
+                 */
+                LOG("Done. Rebooting now");
+                sleep(2);
+                goto start;
+
+            case 0:
+                LOG("Done. Exiting now");
+                ret = 0;
+                goto out;
+
+            default:
+                abort();
+            }
+
+        case LIBXL_EVENT_TYPE_DOMAIN_DESTROY:
+            LOG("Domain %d has been destroyed.", domid);
+            ret = 0;
+            goto out;
+
+        case LIBXL_EVENT_TYPE_DISK_EJECT:
+            /* XXX what is this for? */
+            libxl_cdrom_insert(ctx, domid, &event->u.disk_eject.disk);
+            break;
+
+        default:;
+            char *evstr = libxl_event_to_json(ctx, event);
+            LOG("warning, got unexpected event type %d, event=%s",
+                event->type, evstr);
+            free(evstr);
         }
-        libxl_free_event(&event);
+
+        libxl_event_free(ctx, event);
     }
 
 error_out:
@@ -2259,43 +2300,46 @@ static void destroy_domain(const char *p)
 static void shutdown_domain(const char *p, int wait)
 {
     int rc;
+    libxl_event *event;
 
     find_domain(p);
     rc=libxl_domain_shutdown(ctx, domid, 0);
     if (rc) { fprintf(stderr,"shutdown failed (rc=%d)\n",rc);exit(-1); }
 
     if (wait) {
-        libxl_waiter waiter;
-        int fd;
-
-        libxl_wait_for_domain_death(ctx, domid, &waiter);
+        libxl_evgen_domain_death *deathw;
 
-        libxl_get_wait_fd(ctx, &fd);
-
-        while (wait) {
-            fd_set rfds;
-            libxl_event event;
-            libxl_dominfo info;
+        rc = libxl_evenable_domain_death(ctx, domid, 0, &deathw);
+        if (rc) {
+            fprintf(stderr,"wait for death failed (evgen, rc=%d)\n",rc);
+            exit(-1);
+        }
 
-            FD_ZERO(&rfds);
-            FD_SET(fd, &rfds);
+        for (;;) {
+            rc = domain_wait_event(&event);
+            if (rc) exit(-1);
 
-            if (!select(fd + 1, &rfds, NULL, NULL, NULL))
-                continue;
+            switch (event->type) {
 
-            libxl_get_event(ctx, &event);
+            case LIBXL_EVENT_TYPE_DOMAIN_DESTROY:
+                LOG("Domain %d has been destroyed", domid);
+                goto done;
 
-            if (event.type == LIBXL_EVENT_TYPE_DOMAIN_DEATH) {
-                if (libxl_event_get_domain_death_info(ctx, domid, &event, &info) < 0)
-                    continue;
+            case LIBXL_EVENT_TYPE_DOMAIN_SHUTDOWN:
+                LOG("Domain %d has been shut down, reason code %d %x", domid,
+                    event->u.domain_shutdown.shutdown_reason,
+                    event->u.domain_shutdown.shutdown_reason);
+                goto done;
 
-                LOG("Domain %d is dead", domid);
-                wait = 0;
+            default:
+                LOG("Unexpected event type %d", event->type);
+                break;
             }
-
-            libxl_free_event(&event);
+            libxl_event_free(ctx, event);
         }
-        libxl_free_waiter(&waiter);
+    done:
+        libxl_event_free(ctx, event);
+        libxl_evdisable_domain_death(ctx, deathw);
     }
 }
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 18:11:31 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 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.xensource.com>)
	id 1RXd0T-00066s-FL; Mon, 05 Dec 2011 18:11:13 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RXd0R-00065n-Bf
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 18:11:11 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1323108624!1307875!4
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjAyNg==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27155 invoked from network); 5 Dec 2011 18:10:26 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Dec 2011 18:10:26 -0000
X-IronPort-AV: E=Sophos;i="4.71,300,1320624000"; 
   d="scan'208";a="9297522"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Dec 2011 18:10:26 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 5 Dec 2011 18:10:26 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RXczi-0003k0-0j; Mon, 05 Dec 2011 18:10:26 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RXczh-0006W1-W4;
	Mon, 05 Dec 2011 18:10:25 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Mon, 5 Dec 2011 18:10:09 +0000
Message-ID: <1323108621-22654-4-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1323108621-22654-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1323108621-22654-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 03/15] libxl: Provide a version of bsd's queue.h
	as _libxl_list.h
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

We would like some linked list macros which are (a) well known to be
sane and (b) typesafe.  BSD's queue.h meets these criteria.

We also provide some simple perlery to arrange to add the libxl_
namespace prefix to the macros.  This will allow us to #include
_libxl_list.h in our public header file without clashing with anyone
else who is also using another version of queue.h.

(A note on copyright: The FreeBSD files we are adding have an
[L]GPL-compatible licence, so there is no need to change our COPYING.
Although FreeBSD's queue.3 still contains the advertising clause, this
has been withdrawn by UCB as recorded in the FreeBSD COPYRIGHT file,
which is included in tools/libxl/external/ for reference.)

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <Ian.campbell@citrix.com>
Tested-by: Roger Pau Monne <roger.pau@entel.upc.edu>
---
 tools/libxl/Makefile                 |   10 +-
 tools/libxl/bsd-sys-queue-h-seddery  |   70 +++
 tools/libxl/external/README          |   14 +
 tools/libxl/external/bsd-COPYRIGHT   |  126 ++++
 tools/libxl/external/bsd-queue.3     | 1044 ++++++++++++++++++++++++++++++++++
 tools/libxl/external/bsd-sys-queue.h |  637 +++++++++++++++++++++
 6 files changed, 1898 insertions(+), 3 deletions(-)
 create mode 100755 tools/libxl/bsd-sys-queue-h-seddery
 create mode 100644 tools/libxl/external/README
 create mode 100644 tools/libxl/external/bsd-COPYRIGHT
 create mode 100644 tools/libxl/external/bsd-queue.3
 create mode 100644 tools/libxl/external/bsd-sys-queue.h

diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index a7a4625..f363da2 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -42,7 +42,7 @@ LIBXL_OBJS += _libxl_types.o libxl_flask.o _libxl_types_internal.o
 
 $(LIBXL_OBJS): CFLAGS += $(CFLAGS_libxenctrl) $(CFLAGS_libxenguest) $(CFLAGS_libxenstore) $(CFLAGS_libblktapctl)
 
-AUTOINCS= libxlu_cfg_y.h libxlu_cfg_l.h
+AUTOINCS= libxlu_cfg_y.h libxlu_cfg_l.h _libxl_list.h
 AUTOSRCS= libxlu_cfg_y.c libxlu_cfg_l.c
 LIBXLU_OBJS = libxlu_cfg_y.o libxlu_cfg_l.o libxlu_cfg.o \
 	libxlu_disk_l.o libxlu_disk.o
@@ -55,7 +55,7 @@ $(XL_OBJS): CFLAGS += $(CFLAGS_libxenctrl) # For xentoollog.h
 $(XL_OBJS): CFLAGS += $(CFLAGS_libxenlight)
 
 testidl.o: CFLAGS += $(CFLAGS_libxenctrl) $(CFLAGS_libxenlight)
-testidl.c: libxl_types.idl gentest.py libxl.h
+testidl.c: libxl_types.idl gentest.py libxl.h $(AUTOINCS)
 	$(PYTHON) gentest.py libxl_types.idl testidl.c.new
 	mv testidl.c.new testidl.c
 
@@ -63,7 +63,7 @@ testidl.c: libxl_types.idl gentest.py libxl.h
 all: $(CLIENTS) libxenlight.so libxenlight.a libxlutil.so libxlutil.a \
 	$(AUTOSRCS) $(AUTOINCS)
 
-$(LIBXLU_OBJS): $(AUTOINCS)
+$(LIBXL_OBJS) $(LIBXLU_OBJS) $(XL_OBJS): $(AUTOINCS)
 
 %.c %.h: %.y
 	@rm -f $*.[ch]
@@ -81,6 +81,10 @@ _libxl_paths.h: genpath
 	rm -f $@.tmp
 	$(call move-if-changed,$@.2.tmp,$@)
 
+_libxl_list.h: bsd-sys-queue-h-seddery external/bsd-sys-queue.h
+	perl ./$^ --prefix=libxl >$@.new
+	$(call move-if-changed,$@.new,$@)
+
 libxl_paths.c: _libxl_paths.h
 
 libxl.h: _libxl_types.h
diff --git a/tools/libxl/bsd-sys-queue-h-seddery b/tools/libxl/bsd-sys-queue-h-seddery
new file mode 100755
index 0000000..c0aa079
--- /dev/null
+++ b/tools/libxl/bsd-sys-queue-h-seddery
@@ -0,0 +1,70 @@
+#!/usr/bin/perl -p
+#
+# This script is part of the Xen build system.  It has a very
+# permissive licence to avoid complicating the licence of the
+# generated header file and to allow this seddery to be reused by
+# other projects.
+#
+# Permission is hereby granted, free of charge, to any person
+# obtaining a copy of this individual 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.
+#
+# Copyright (C) 2011 Citrix Ltd
+
+our $namespace, $ucnamespace;
+
+BEGIN {
+    die unless @ARGV;
+    $namespace = pop @ARGV;
+    $namespace =~ s/^--prefix=// or die;
+    $ucnamespace = uc $namespace;
+
+    print <<END or die $!;
+/*
+ * DO NOT EDIT THIS FILE
+ *
+ * Generated automatically by bsd-sys-queue-h-seddery to
+ *  - introduce ${ucnamespace}_ and ${namespace}_ namespace prefixes
+ *  - turn "struct type" into "type" so that type arguments
+ *     to the macros are type names not struct tags
+ *  - remove the reference to sys/cdefs.h, which is not needed
+ *
+ * The purpose of this seddery is to allow the resulting file to be
+ * freely included by software which might also want to include other
+ * list macros; to make it usable when struct tags are not being used
+ * or not known; to make it more portable.
+ */
+END
+}
+
+s/\b( _SYS_QUEUE |
+      SLIST | LIST | STAILQ | TAILQ | QUEUE
+      )/${ucnamespace}_$1/xg;
+
+s/\b( TRACEBUF | TRASHIT |
+      QMD_
+      )/${ucnamespace}__$1/xg;
+
+s/\b(
+      qm_
+      )/${namespace}__$1/xg;
+
+s/\b struct \s+ type \b/type/xg;
+
+s,^\#include.*sys/cdefs.*,/* $& */,xg;
diff --git a/tools/libxl/external/README b/tools/libxl/external/README
new file mode 100644
index 0000000..8c8beea
--- /dev/null
+++ b/tools/libxl/external/README
@@ -0,0 +1,14 @@
+WARNING - DO NOT EDIT THINGS IN THIS DIRECTORY (apart from this README)
+-----------------------------------------------------------------------
+
+These files were obtained elsewhere and should only be updated by
+copying new versions from the source location, as documented below:
+
+bsd-COPYRIGHT
+bsd-sys-queue.h
+bsd-queue.3
+
+  Obtained from the FreeBSD SVN using the following commands:
+    svn co -r 221843 svn://svn.freebsd.org/base/head/sys/sys/
+    svn co -r 221843 svn://svn.freebsd.org/base/head/share/man/man3
+    svn cat -r 221843 http://svn.freebsd.org/base/head/COPYRIGHT >tools/libxl/external/bsd-COPYRIGHT
diff --git a/tools/libxl/external/bsd-COPYRIGHT b/tools/libxl/external/bsd-COPYRIGHT
new file mode 100644
index 0000000..6dc5d16
--- /dev/null
+++ b/tools/libxl/external/bsd-COPYRIGHT
@@ -0,0 +1,126 @@
+# $FreeBSD$
+#	@(#)COPYRIGHT	8.2 (Berkeley) 3/21/94
+
+The compilation of software known as FreeBSD is distributed under the
+following terms:
+
+Copyright (c) 1992-2011 The FreeBSD Project. All rights reserved.
+
+Redistribution and use in source and binary forms, with or without
+modification, are permitted provided that the following conditions
+are met:
+1. Redistributions of source code must retain the above copyright
+   notice, this list of conditions and the following disclaimer.
+2. Redistributions in binary form must reproduce the above copyright
+   notice, this list of conditions and the following disclaimer in the
+   documentation and/or other materials provided with the distribution.
+
+THIS SOFTWARE IS PROVIDED BY THE 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 THE 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.
+
+The 4.4BSD and 4.4BSD-Lite software is distributed under the following
+terms:
+
+All of the documentation and software included in the 4.4BSD and 4.4BSD-Lite
+Releases is copyrighted by The Regents of the University of California.
+
+Copyright 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
+	The Regents of the University of California.  All rights reserved.
+
+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.
+3. All advertising materials mentioning features or use of this software
+   must display the following acknowledgement:
+This product includes software developed by the University of
+California, Berkeley and its contributors.
+4. Neither the name of the University 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 REGENTS 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 REGENTS 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.
+
+The Institute of Electrical and Electronics Engineers and the American
+National Standards Committee X3, on Information Processing Systems have
+given us permission to reprint portions of their documentation.
+
+In the following statement, the phrase ``this text'' refers to portions
+of the system documentation.
+
+Portions of this text are reprinted and reproduced in electronic form in
+the second BSD Networking Software Release, from IEEE Std 1003.1-1988, IEEE
+Standard Portable Operating System Interface for Computer Environments
+(POSIX), copyright C 1988 by the Institute of Electrical and Electronics
+Engineers, Inc.  In the event of any discrepancy between these versions
+and the original IEEE Standard, the original IEEE Standard is the referee
+document.
+
+In the following statement, the phrase ``This material'' refers to portions
+of the system documentation.
+
+This material is reproduced with permission from American National
+Standards Committee X3, on Information Processing Systems.  Computer and
+Business Equipment Manufacturers Association (CBEMA), 311 First St., NW,
+Suite 500, Washington, DC 20001-2178.  The developmental work of
+Programming Language C was completed by the X3J11 Technical Committee.
+
+The views and conclusions contained in the software and documentation are
+those of the authors and should not be interpreted as representing official
+policies, either expressed or implied, of the Regents of the University
+of California.
+
+
+NOTE: The copyright of UC Berkeley's Berkeley Software Distribution ("BSD")
+source has been updated.  The copyright addendum may be found at
+ftp://ftp.cs.berkeley.edu/pub/4bsd/README.Impt.License.Change and is
+included below.
+
+July 22, 1999
+
+To All Licensees, Distributors of Any Version of BSD:
+
+As you know, certain of the Berkeley Software Distribution ("BSD") source
+code files require that further distributions of products containing all or
+portions of the software, acknowledge within their advertising materials
+that such products contain software developed by UC Berkeley and its
+contributors.
+
+Specifically, the provision reads:
+
+"     * 3. All advertising materials mentioning features or use of this software
+      *    must display the following acknowledgement:
+      *    This product includes software developed by the University of
+      *    California, Berkeley and its contributors."
+
+Effective immediately, licensees and distributors are no longer required to
+include the acknowledgement within advertising materials.  Accordingly, the
+foregoing paragraph of those BSD Unix files containing it is hereby deleted
+in its entirety.
+
+William Hoskins
+Director, Office of Technology Licensing
+University of California, Berkeley
diff --git a/tools/libxl/external/bsd-queue.3 b/tools/libxl/external/bsd-queue.3
new file mode 100644
index 0000000..007ca5c
--- /dev/null
+++ b/tools/libxl/external/bsd-queue.3
@@ -0,0 +1,1044 @@
+.\" Copyright (c) 1993
+.\"	The Regents of the University of California.  All rights reserved.
+.\"
+.\" 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.
+.\" 3. All advertising materials mentioning features or use of this software
+.\"    must display the following acknowledgement:
+.\"	This product includes software developed by the University of
+.\"	California, Berkeley and its contributors.
+.\" 4. Neither the name of the University 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 REGENTS 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 REGENTS 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.
+.\"
+.\"	@(#)queue.3	8.2 (Berkeley) 1/24/94
+.\" $FreeBSD$
+.\"
+.Dd May 13, 2011
+.Dt QUEUE 3
+.Os
+.Sh NAME
+.Nm SLIST_EMPTY ,
+.Nm SLIST_ENTRY ,
+.Nm SLIST_FIRST ,
+.Nm SLIST_FOREACH ,
+.Nm SLIST_FOREACH_SAFE ,
+.Nm SLIST_HEAD ,
+.Nm SLIST_HEAD_INITIALIZER ,
+.Nm SLIST_INIT ,
+.Nm SLIST_INSERT_AFTER ,
+.Nm SLIST_INSERT_HEAD ,
+.Nm SLIST_NEXT ,
+.Nm SLIST_REMOVE_AFTER ,
+.Nm SLIST_REMOVE_HEAD ,
+.Nm SLIST_REMOVE ,
+.Nm SLIST_SWAP ,
+.Nm STAILQ_CONCAT ,
+.Nm STAILQ_EMPTY ,
+.Nm STAILQ_ENTRY ,
+.Nm STAILQ_FIRST ,
+.Nm STAILQ_FOREACH ,
+.Nm STAILQ_FOREACH_SAFE ,
+.Nm STAILQ_HEAD ,
+.Nm STAILQ_HEAD_INITIALIZER ,
+.Nm STAILQ_INIT ,
+.Nm STAILQ_INSERT_AFTER ,
+.Nm STAILQ_INSERT_HEAD ,
+.Nm STAILQ_INSERT_TAIL ,
+.Nm STAILQ_LAST ,
+.Nm STAILQ_NEXT ,
+.Nm STAILQ_REMOVE_AFTER ,
+.Nm STAILQ_REMOVE_HEAD ,
+.Nm STAILQ_REMOVE ,
+.Nm STAILQ_SWAP ,
+.Nm LIST_EMPTY ,
+.Nm LIST_ENTRY ,
+.Nm LIST_FIRST ,
+.Nm LIST_FOREACH ,
+.Nm LIST_FOREACH_SAFE ,
+.Nm LIST_HEAD ,
+.Nm LIST_HEAD_INITIALIZER ,
+.Nm LIST_INIT ,
+.Nm LIST_INSERT_AFTER ,
+.Nm LIST_INSERT_BEFORE ,
+.Nm LIST_INSERT_HEAD ,
+.Nm LIST_NEXT ,
+.Nm LIST_REMOVE ,
+.Nm LIST_SWAP ,
+.Nm TAILQ_CONCAT ,
+.Nm TAILQ_EMPTY ,
+.Nm TAILQ_ENTRY ,
+.Nm TAILQ_FIRST ,
+.Nm TAILQ_FOREACH ,
+.Nm TAILQ_FOREACH_SAFE ,
+.Nm TAILQ_FOREACH_REVERSE ,
+.Nm TAILQ_FOREACH_REVERSE_SAFE ,
+.Nm TAILQ_HEAD ,
+.Nm TAILQ_HEAD_INITIALIZER ,
+.Nm TAILQ_INIT ,
+.Nm TAILQ_INSERT_AFTER ,
+.Nm TAILQ_INSERT_BEFORE ,
+.Nm TAILQ_INSERT_HEAD ,
+.Nm TAILQ_INSERT_TAIL ,
+.Nm TAILQ_LAST ,
+.Nm TAILQ_NEXT ,
+.Nm TAILQ_PREV ,
+.Nm TAILQ_REMOVE ,
+.Nm TAILQ_SWAP
+.Nd implementations of singly-linked lists, singly-linked tail queues,
+lists and tail queues
+.Sh SYNOPSIS
+.In sys/queue.h
+.\"
+.Fn SLIST_EMPTY "SLIST_HEAD *head"
+.Fn SLIST_ENTRY "TYPE"
+.Fn SLIST_FIRST "SLIST_HEAD *head"
+.Fn SLIST_FOREACH "TYPE *var" "SLIST_HEAD *head" "SLIST_ENTRY NAME"
+.Fn SLIST_FOREACH_SAFE "TYPE *var" "SLIST_HEAD *head" "SLIST_ENTRY NAME" "TYPE *temp_var"
+.Fn SLIST_HEAD "HEADNAME" "TYPE"
+.Fn SLIST_HEAD_INITIALIZER "SLIST_HEAD head"
+.Fn SLIST_INIT "SLIST_HEAD *head"
+.Fn SLIST_INSERT_AFTER "TYPE *listelm" "TYPE *elm" "SLIST_ENTRY NAME"
+.Fn SLIST_INSERT_HEAD "SLIST_HEAD *head" "TYPE *elm" "SLIST_ENTRY NAME"
+.Fn SLIST_NEXT "TYPE *elm" "SLIST_ENTRY NAME"
+.Fn SLIST_REMOVE_AFTER "TYPE *elm" "SLIST_ENTRY NAME"
+.Fn SLIST_REMOVE_HEAD "SLIST_HEAD *head" "SLIST_ENTRY NAME"
+.Fn SLIST_REMOVE "SLIST_HEAD *head" "TYPE *elm" "TYPE" "SLIST_ENTRY NAME"
+.Fn SLIST_SWAP "SLIST_HEAD *head1" "SLIST_HEAD *head2" "SLIST_ENTRY NAME"
+.\"
+.Fn STAILQ_CONCAT "STAILQ_HEAD *head1" "STAILQ_HEAD *head2"
+.Fn STAILQ_EMPTY "STAILQ_HEAD *head"
+.Fn STAILQ_ENTRY "TYPE"
+.Fn STAILQ_FIRST "STAILQ_HEAD *head"
+.Fn STAILQ_FOREACH "TYPE *var" "STAILQ_HEAD *head" "STAILQ_ENTRY NAME"
+.Fn STAILQ_FOREACH_SAFE "TYPE *var" "STAILQ_HEAD *head" "STAILQ_ENTRY NAME" "TYPE *temp_var"
+.Fn STAILQ_HEAD "HEADNAME" "TYPE"
+.Fn STAILQ_HEAD_INITIALIZER "STAILQ_HEAD head"
+.Fn STAILQ_INIT "STAILQ_HEAD *head"
+.Fn STAILQ_INSERT_AFTER "STAILQ_HEAD *head" "TYPE *listelm" "TYPE *elm" "STAILQ_ENTRY NAME"
+.Fn STAILQ_INSERT_HEAD "STAILQ_HEAD *head" "TYPE *elm" "STAILQ_ENTRY NAME"
+.Fn STAILQ_INSERT_TAIL "STAILQ_HEAD *head" "TYPE *elm" "STAILQ_ENTRY NAME"
+.Fn STAILQ_LAST "STAILQ_HEAD *head" "TYPE" "STAILQ_ENTRY NAME"
+.Fn STAILQ_NEXT "TYPE *elm" "STAILQ_ENTRY NAME"
+.Fn STAILQ_REMOVE_AFTER "STAILQ_HEAD *head" "TYPE *elm" "STAILQ_ENTRY NAME"
+.Fn STAILQ_REMOVE_HEAD "STAILQ_HEAD *head" "STAILQ_ENTRY NAME"
+.Fn STAILQ_REMOVE "STAILQ_HEAD *head" "TYPE *elm" "TYPE" "STAILQ_ENTRY NAME"
+.Fn STAILQ_SWAP "STAILQ_HEAD *head1" "STAILQ_HEAD *head2" "STAILQ_ENTRY NAME"
+.\"
+.Fn LIST_EMPTY "LIST_HEAD *head"
+.Fn LIST_ENTRY "TYPE"
+.Fn LIST_FIRST "LIST_HEAD *head"
+.Fn LIST_FOREACH "TYPE *var" "LIST_HEAD *head" "LIST_ENTRY NAME"
+.Fn LIST_FOREACH_SAFE "TYPE *var" "LIST_HEAD *head" "LIST_ENTRY NAME" "TYPE *temp_var"
+.Fn LIST_HEAD "HEADNAME" "TYPE"
+.Fn LIST_HEAD_INITIALIZER "LIST_HEAD head"
+.Fn LIST_INIT "LIST_HEAD *head"
+.Fn LIST_INSERT_AFTER "TYPE *listelm" "TYPE *elm" "LIST_ENTRY NAME"
+.Fn LIST_INSERT_BEFORE "TYPE *listelm" "TYPE *elm" "LIST_ENTRY NAME"
+.Fn LIST_INSERT_HEAD "LIST_HEAD *head" "TYPE *elm" "LIST_ENTRY NAME"
+.Fn LIST_NEXT "TYPE *elm" "LIST_ENTRY NAME"
+.Fn LIST_REMOVE "TYPE *elm" "LIST_ENTRY NAME"
+.Fn LIST_SWAP "LIST_HEAD *head1" "LIST_HEAD *head2" "TYPE" "LIST_ENTRY NAME"
+.\"
+.Fn TAILQ_CONCAT "TAILQ_HEAD *head1" "TAILQ_HEAD *head2" "TAILQ_ENTRY NAME"
+.Fn TAILQ_EMPTY "TAILQ_HEAD *head"
+.Fn TAILQ_ENTRY "TYPE"
+.Fn TAILQ_FIRST "TAILQ_HEAD *head"
+.Fn TAILQ_FOREACH "TYPE *var" "TAILQ_HEAD *head" "TAILQ_ENTRY NAME"
+.Fn TAILQ_FOREACH_SAFE "TYPE *var" "TAILQ_HEAD *head" "TAILQ_ENTRY NAME" "TYPE *temp_var"
+.Fn TAILQ_FOREACH_REVERSE "TYPE *var" "TAILQ_HEAD *head" "HEADNAME" "TAILQ_ENTRY NAME"
+.Fn TAILQ_FOREACH_REVERSE_SAFE "TYPE *var" "TAILQ_HEAD *head" "HEADNAME" "TAILQ_ENTRY NAME" "TYPE *temp_var"
+.Fn TAILQ_HEAD "HEADNAME" "TYPE"
+.Fn TAILQ_HEAD_INITIALIZER "TAILQ_HEAD head"
+.Fn TAILQ_INIT "TAILQ_HEAD *head"
+.Fn TAILQ_INSERT_AFTER "TAILQ_HEAD *head" "TYPE *listelm" "TYPE *elm" "TAILQ_ENTRY NAME"
+.Fn TAILQ_INSERT_BEFORE "TYPE *listelm" "TYPE *elm" "TAILQ_ENTRY NAME"
+.Fn TAILQ_INSERT_HEAD "TAILQ_HEAD *head" "TYPE *elm" "TAILQ_ENTRY NAME"
+.Fn TAILQ_INSERT_TAIL "TAILQ_HEAD *head" "TYPE *elm" "TAILQ_ENTRY NAME"
+.Fn TAILQ_LAST "TAILQ_HEAD *head" "HEADNAME"
+.Fn TAILQ_NEXT "TYPE *elm" "TAILQ_ENTRY NAME"
+.Fn TAILQ_PREV "TYPE *elm" "HEADNAME" "TAILQ_ENTRY NAME"
+.Fn TAILQ_REMOVE "TAILQ_HEAD *head" "TYPE *elm" "TAILQ_ENTRY NAME"
+.Fn TAILQ_SWAP "TAILQ_HEAD *head1" "TAILQ_HEAD *head2" "TYPE" "TAILQ_ENTRY NAME"
+.\"
+.Sh DESCRIPTION
+These macros define and operate on four types of data structures:
+singly-linked lists, singly-linked tail queues, lists, and tail queues.
+All four structures support the following functionality:
+.Bl -enum -compact -offset indent
+.It
+Insertion of a new entry at the head of the list.
+.It
+Insertion of a new entry after any element in the list.
+.It
+O(1) removal of an entry from the head of the list.
+.It
+Forward traversal through the list.
+.It
+Swawpping the contents of two lists.
+.El
+.Pp
+Singly-linked lists are the simplest of the four data structures
+and support only the above functionality.
+Singly-linked lists are ideal for applications with large datasets
+and few or no removals,
+or for implementing a LIFO queue.
+Singly-linked lists add the following functionality:
+.Bl -enum -compact -offset indent
+.It
+O(n) removal of any entry in the list.
+.El
+.Pp
+Singly-linked tail queues add the following functionality:
+.Bl -enum -compact -offset indent
+.It
+Entries can be added at the end of a list.
+.It
+O(n) removal of any entry in the list.
+.It
+They may be concatenated.
+.El
+However:
+.Bl -enum -compact -offset indent
+.It
+All list insertions must specify the head of the list.
+.It
+Each head entry requires two pointers rather than one.
+.It
+Code size is about 15% greater and operations run about 20% slower
+than singly-linked lists.
+.El
+.Pp
+Singly-linked tailqs are ideal for applications with large datasets and
+few or no removals,
+or for implementing a FIFO queue.
+.Pp
+All doubly linked types of data structures (lists and tail queues)
+additionally allow:
+.Bl -enum -compact -offset indent
+.It
+Insertion of a new entry before any element in the list.
+.It
+O(1) removal of any entry in the list.
+.El
+However:
+.Bl -enum -compact -offset indent
+.It
+Each element requires two pointers rather than one.
+.It
+Code size and execution time of operations (except for removal) is about
+twice that of the singly-linked data-structures.
+.El
+.Pp
+Linked lists are the simplest of the doubly linked data structures and support
+only the above functionality over singly-linked lists.
+.Pp
+Tail queues add the following functionality:
+.Bl -enum -compact -offset indent
+.It
+Entries can be added at the end of a list.
+.It
+They may be traversed backwards, from tail to head.
+.It
+They may be concatenated.
+.El
+However:
+.Bl -enum -compact -offset indent
+.It
+All list insertions and removals must specify the head of the list.
+.It
+Each head entry requires two pointers rather than one.
+.It
+Code size is about 15% greater and operations run about 20% slower
+than singly-linked lists.
+.El
+.Pp
+In the macro definitions,
+.Fa TYPE
+is the name of a user defined structure,
+that must contain a field of type
+.Li SLIST_ENTRY ,
+.Li STAILQ_ENTRY ,
+.Li LIST_ENTRY ,
+or
+.Li TAILQ_ENTRY ,
+named
+.Fa NAME .
+The argument
+.Fa HEADNAME
+is the name of a user defined structure that must be declared
+using the macros
+.Li SLIST_HEAD ,
+.Li STAILQ_HEAD ,
+.Li LIST_HEAD ,
+or
+.Li TAILQ_HEAD .
+See the examples below for further explanation of how these
+macros are used.
+.Sh SINGLY-LINKED LISTS
+A singly-linked list is headed by a structure defined by the
+.Nm SLIST_HEAD
+macro.
+This structure contains a single pointer to the first element
+on the list.
+The elements are singly linked for minimum space and pointer manipulation
+overhead at the expense of O(n) removal for arbitrary elements.
+New elements can be added to the list after an existing element or
+at the head of the list.
+An
+.Fa SLIST_HEAD
+structure is declared as follows:
+.Bd -literal -offset indent
+SLIST_HEAD(HEADNAME, TYPE) head;
+.Ed
+.Pp
+where
+.Fa HEADNAME
+is the name of the structure to be defined, and
+.Fa TYPE
+is the type of the elements to be linked into the list.
+A pointer to the head of the list can later be declared as:
+.Bd -literal -offset indent
+struct HEADNAME *headp;
+.Ed
+.Pp
+(The names
+.Li head
+and
+.Li headp
+are user selectable.)
+.Pp
+The macro
+.Nm SLIST_HEAD_INITIALIZER
+evaluates to an initializer for the list
+.Fa head .
+.Pp
+The macro
+.Nm SLIST_EMPTY
+evaluates to true if there are no elements in the list.
+.Pp
+The macro
+.Nm SLIST_ENTRY
+declares a structure that connects the elements in
+the list.
+.Pp
+The macro
+.Nm SLIST_FIRST
+returns the first element in the list or NULL if the list is empty.
+.Pp
+The macro
+.Nm SLIST_FOREACH
+traverses the list referenced by
+.Fa head
+in the forward direction, assigning each element in
+turn to
+.Fa var .
+.Pp
+The macro
+.Nm SLIST_FOREACH_SAFE
+traverses the list referenced by
+.Fa head
+in the forward direction, assigning each element in
+turn to
+.Fa var .
+However, unlike
+.Fn SLIST_FOREACH
+here it is permitted to both remove
+.Fa var
+as well as free it from within the loop safely without interfering with the
+traversal.
+.Pp
+The macro
+.Nm SLIST_INIT
+initializes the list referenced by
+.Fa head .
+.Pp
+The macro
+.Nm SLIST_INSERT_HEAD
+inserts the new element
+.Fa elm
+at the head of the list.
+.Pp
+The macro
+.Nm SLIST_INSERT_AFTER
+inserts the new element
+.Fa elm
+after the element
+.Fa listelm .
+.Pp
+The macro
+.Nm SLIST_NEXT
+returns the next element in the list.
+.Pp
+The macro
+.Nm SLIST_REMOVE_AFTER
+removes the element after
+.Fa elm
+from the list. Unlike
+.Fa SLIST_REMOVE ,
+this macro does not traverse the entire list.
+.Pp
+The macro
+.Nm SLIST_REMOVE_HEAD
+removes the element
+.Fa elm
+from the head of the list.
+For optimum efficiency,
+elements being removed from the head of the list should explicitly use
+this macro instead of the generic
+.Fa SLIST_REMOVE
+macro.
+.Pp
+The macro
+.Nm SLIST_REMOVE
+removes the element
+.Fa elm
+from the list.
+.Pp
+The macro
+.Nm SLIST_SWAP
+swaps the contents of
+.Fa head1
+and
+.Fa head2 .
+.Sh SINGLY-LINKED LIST EXAMPLE
+.Bd -literal
+SLIST_HEAD(slisthead, entry) head =
+    SLIST_HEAD_INITIALIZER(head);
+struct slisthead *headp;		/* Singly-linked List head. */
+struct entry {
+	...
+	SLIST_ENTRY(entry) entries;	/* Singly-linked List. */
+	...
+} *n1, *n2, *n3, *np;
+
+SLIST_INIT(&head);			/* Initialize the list. */
+
+n1 = malloc(sizeof(struct entry));	/* Insert at the head. */
+SLIST_INSERT_HEAD(&head, n1, entries);
+
+n2 = malloc(sizeof(struct entry));	/* Insert after. */
+SLIST_INSERT_AFTER(n1, n2, entries);
+
+SLIST_REMOVE(&head, n2, entry, entries);/* Deletion. */
+free(n2);
+
+n3 = SLIST_FIRST(&head);
+SLIST_REMOVE_HEAD(&head, entries);	/* Deletion from the head. */
+free(n3);
+					/* Forward traversal. */
+SLIST_FOREACH(np, &head, entries)
+	np-> ...
+					/* Safe forward traversal. */
+SLIST_FOREACH_SAFE(np, &head, entries, np_temp) {
+	np->do_stuff();
+	...
+	SLIST_REMOVE(&head, np, entry, entries);
+	free(np);
+}
+
+while (!SLIST_EMPTY(&head)) {		/* List Deletion. */
+	n1 = SLIST_FIRST(&head);
+	SLIST_REMOVE_HEAD(&head, entries);
+	free(n1);
+}
+.Ed
+.Sh SINGLY-LINKED TAIL QUEUES
+A singly-linked tail queue is headed by a structure defined by the
+.Nm STAILQ_HEAD
+macro.
+This structure contains a pair of pointers,
+one to the first element in the tail queue and the other to
+the last element in the tail queue.
+The elements are singly linked for minimum space and pointer
+manipulation overhead at the expense of O(n) removal for arbitrary
+elements.
+New elements can be added to the tail queue after an existing element,
+at the head of the tail queue, or at the end of the tail queue.
+A
+.Fa STAILQ_HEAD
+structure is declared as follows:
+.Bd -literal -offset indent
+STAILQ_HEAD(HEADNAME, TYPE) head;
+.Ed
+.Pp
+where
+.Li HEADNAME
+is the name of the structure to be defined, and
+.Li TYPE
+is the type of the elements to be linked into the tail queue.
+A pointer to the head of the tail queue can later be declared as:
+.Bd -literal -offset indent
+struct HEADNAME *headp;
+.Ed
+.Pp
+(The names
+.Li head
+and
+.Li headp
+are user selectable.)
+.Pp
+The macro
+.Nm STAILQ_HEAD_INITIALIZER
+evaluates to an initializer for the tail queue
+.Fa head .
+.Pp
+The macro
+.Nm STAILQ_CONCAT
+concatenates the tail queue headed by
+.Fa head2
+onto the end of the one headed by
+.Fa head1
+removing all entries from the former.
+.Pp
+The macro
+.Nm STAILQ_EMPTY
+evaluates to true if there are no items on the tail queue.
+.Pp
+The macro
+.Nm STAILQ_ENTRY
+declares a structure that connects the elements in
+the tail queue.
+.Pp
+The macro
+.Nm STAILQ_FIRST
+returns the first item on the tail queue or NULL if the tail queue
+is empty.
+.Pp
+The macro
+.Nm STAILQ_FOREACH
+traverses the tail queue referenced by
+.Fa head
+in the forward direction, assigning each element
+in turn to
+.Fa var .
+.Pp
+The macro
+.Nm STAILQ_FOREACH_SAFE
+traverses the tail queue referenced by
+.Fa head
+in the forward direction, assigning each element
+in turn to
+.Fa var .
+However, unlike
+.Fn STAILQ_FOREACH
+here it is permitted to both remove
+.Fa var
+as well as free it from within the loop safely without interfering with the
+traversal.
+.Pp
+The macro
+.Nm STAILQ_INIT
+initializes the tail queue referenced by
+.Fa head .
+.Pp
+The macro
+.Nm STAILQ_INSERT_HEAD
+inserts the new element
+.Fa elm
+at the head of the tail queue.
+.Pp
+The macro
+.Nm STAILQ_INSERT_TAIL
+inserts the new element
+.Fa elm
+at the end of the tail queue.
+.Pp
+The macro
+.Nm STAILQ_INSERT_AFTER
+inserts the new element
+.Fa elm
+after the element
+.Fa listelm .
+.Pp
+The macro
+.Nm STAILQ_LAST
+returns the last item on the tail queue.
+If the tail queue is empty the return value is
+.Dv NULL .
+.Pp
+The macro
+.Nm STAILQ_NEXT
+returns the next item on the tail queue, or NULL this item is the last.
+.Pp
+The macro
+.Nm STAILQ_REMOVE_AFTER
+removes the element after
+.Fa elm
+from the tail queue. Unlike
+.Fa STAILQ_REMOVE ,
+this macro does not traverse the entire tail queue.
+.Pp
+The macro
+.Nm STAILQ_REMOVE_HEAD
+removes the element at the head of the tail queue.
+For optimum efficiency,
+elements being removed from the head of the tail queue should
+use this macro explicitly rather than the generic
+.Fa STAILQ_REMOVE
+macro.
+.Pp
+The macro
+.Nm STAILQ_REMOVE
+removes the element
+.Fa elm
+from the tail queue.
+.Pp
+The macro
+.Nm STAILQ_SWAP
+swaps the contents of
+.Fa head1
+and
+.Fa head2 .
+.Sh SINGLY-LINKED TAIL QUEUE EXAMPLE
+.Bd -literal
+STAILQ_HEAD(stailhead, entry) head =
+    STAILQ_HEAD_INITIALIZER(head);
+struct stailhead *headp;		/* Singly-linked tail queue head. */
+struct entry {
+	...
+	STAILQ_ENTRY(entry) entries;	/* Tail queue. */
+	...
+} *n1, *n2, *n3, *np;
+
+STAILQ_INIT(&head);			/* Initialize the queue. */
+
+n1 = malloc(sizeof(struct entry));	/* Insert at the head. */
+STAILQ_INSERT_HEAD(&head, n1, entries);
+
+n1 = malloc(sizeof(struct entry));	/* Insert at the tail. */
+STAILQ_INSERT_TAIL(&head, n1, entries);
+
+n2 = malloc(sizeof(struct entry));	/* Insert after. */
+STAILQ_INSERT_AFTER(&head, n1, n2, entries);
+					/* Deletion. */
+STAILQ_REMOVE(&head, n2, entry, entries);
+free(n2);
+					/* Deletion from the head. */
+n3 = STAILQ_FIRST(&head);
+STAILQ_REMOVE_HEAD(&head, entries);
+free(n3);
+					/* Forward traversal. */
+STAILQ_FOREACH(np, &head, entries)
+	np-> ...
+					/* Safe forward traversal. */
+STAILQ_FOREACH_SAFE(np, &head, entries, np_temp) {
+	np->do_stuff();
+	...
+	STAILQ_REMOVE(&head, np, entry, entries);
+	free(np);
+}
+					/* TailQ Deletion. */
+while (!STAILQ_EMPTY(&head)) {
+	n1 = STAILQ_FIRST(&head);
+	STAILQ_REMOVE_HEAD(&head, entries);
+	free(n1);
+}
+					/* Faster TailQ Deletion. */
+n1 = STAILQ_FIRST(&head);
+while (n1 != NULL) {
+	n2 = STAILQ_NEXT(n1, entries);
+	free(n1);
+	n1 = n2;
+}
+STAILQ_INIT(&head);
+.Ed
+.Sh LISTS
+A list is headed by a structure defined by the
+.Nm LIST_HEAD
+macro.
+This structure contains a single pointer to the first element
+on the list.
+The elements are doubly linked so that an arbitrary element can be
+removed without traversing the list.
+New elements can be added to the list after an existing element,
+before an existing element, or at the head of the list.
+A
+.Fa LIST_HEAD
+structure is declared as follows:
+.Bd -literal -offset indent
+LIST_HEAD(HEADNAME, TYPE) head;
+.Ed
+.Pp
+where
+.Fa HEADNAME
+is the name of the structure to be defined, and
+.Fa TYPE
+is the type of the elements to be linked into the list.
+A pointer to the head of the list can later be declared as:
+.Bd -literal -offset indent
+struct HEADNAME *headp;
+.Ed
+.Pp
+(The names
+.Li head
+and
+.Li headp
+are user selectable.)
+.Pp
+The macro
+.Nm LIST_HEAD_INITIALIZER
+evaluates to an initializer for the list
+.Fa head .
+.Pp
+The macro
+.Nm LIST_EMPTY
+evaluates to true if there are no elements in the list.
+.Pp
+The macro
+.Nm LIST_ENTRY
+declares a structure that connects the elements in
+the list.
+.Pp
+The macro
+.Nm LIST_FIRST
+returns the first element in the list or NULL if the list
+is empty.
+.Pp
+The macro
+.Nm LIST_FOREACH
+traverses the list referenced by
+.Fa head
+in the forward direction, assigning each element in turn to
+.Fa var .
+.Pp
+The macro
+.Nm LIST_FOREACH_SAFE
+traverses the list referenced by
+.Fa head
+in the forward direction, assigning each element in turn to
+.Fa var .
+However, unlike
+.Fn LIST_FOREACH
+here it is permitted to both remove
+.Fa var
+as well as free it from within the loop safely without interfering with the
+traversal.
+.Pp
+The macro
+.Nm LIST_INIT
+initializes the list referenced by
+.Fa head .
+.Pp
+The macro
+.Nm LIST_INSERT_HEAD
+inserts the new element
+.Fa elm
+at the head of the list.
+.Pp
+The macro
+.Nm LIST_INSERT_AFTER
+inserts the new element
+.Fa elm
+after the element
+.Fa listelm .
+.Pp
+The macro
+.Nm LIST_INSERT_BEFORE
+inserts the new element
+.Fa elm
+before the element
+.Fa listelm .
+.Pp
+The macro
+.Nm LIST_NEXT
+returns the next element in the list, or NULL if this is the last.
+.Pp
+The macro
+.Nm LIST_REMOVE
+removes the element
+.Fa elm
+from the list.
+.Pp
+The macro
+.Nm LIST_SWAP
+swaps the contents of
+.Fa head1
+and
+.Fa head2 .
+.Sh LIST EXAMPLE
+.Bd -literal
+LIST_HEAD(listhead, entry) head =
+    LIST_HEAD_INITIALIZER(head);
+struct listhead *headp;			/* List head. */
+struct entry {
+	...
+	LIST_ENTRY(entry) entries;	/* List. */
+	...
+} *n1, *n2, *n3, *np, *np_temp;
+
+LIST_INIT(&head);			/* Initialize the list. */
+
+n1 = malloc(sizeof(struct entry));	/* Insert at the head. */
+LIST_INSERT_HEAD(&head, n1, entries);
+
+n2 = malloc(sizeof(struct entry));	/* Insert after. */
+LIST_INSERT_AFTER(n1, n2, entries);
+
+n3 = malloc(sizeof(struct entry));	/* Insert before. */
+LIST_INSERT_BEFORE(n2, n3, entries);
+
+LIST_REMOVE(n2, entries);		/* Deletion. */
+free(n2);
+					/* Forward traversal. */
+LIST_FOREACH(np, &head, entries)
+	np-> ...
+
+					/* Safe forward traversal. */
+LIST_FOREACH_SAFE(np, &head, entries, np_temp) {
+	np->do_stuff();
+	...
+	LIST_REMOVE(np, entries);
+	free(np);
+}
+
+while (!LIST_EMPTY(&head)) {		/* List Deletion. */
+	n1 = LIST_FIRST(&head);
+	LIST_REMOVE(n1, entries);
+	free(n1);
+}
+
+n1 = LIST_FIRST(&head);			/* Faster List Deletion. */
+while (n1 != NULL) {
+	n2 = LIST_NEXT(n1, entries);
+	free(n1);
+	n1 = n2;
+}
+LIST_INIT(&head);
+.Ed
+.Sh TAIL QUEUES
+A tail queue is headed by a structure defined by the
+.Nm TAILQ_HEAD
+macro.
+This structure contains a pair of pointers,
+one to the first element in the tail queue and the other to
+the last element in the tail queue.
+The elements are doubly linked so that an arbitrary element can be
+removed without traversing the tail queue.
+New elements can be added to the tail queue after an existing element,
+before an existing element, at the head of the tail queue,
+or at the end of the tail queue.
+A
+.Fa TAILQ_HEAD
+structure is declared as follows:
+.Bd -literal -offset indent
+TAILQ_HEAD(HEADNAME, TYPE) head;
+.Ed
+.Pp
+where
+.Li HEADNAME
+is the name of the structure to be defined, and
+.Li TYPE
+is the type of the elements to be linked into the tail queue.
+A pointer to the head of the tail queue can later be declared as:
+.Bd -literal -offset indent
+struct HEADNAME *headp;
+.Ed
+.Pp
+(The names
+.Li head
+and
+.Li headp
+are user selectable.)
+.Pp
+The macro
+.Nm TAILQ_HEAD_INITIALIZER
+evaluates to an initializer for the tail queue
+.Fa head .
+.Pp
+The macro
+.Nm TAILQ_CONCAT
+concatenates the tail queue headed by
+.Fa head2
+onto the end of the one headed by
+.Fa head1
+removing all entries from the former.
+.Pp
+The macro
+.Nm TAILQ_EMPTY
+evaluates to true if there are no items on the tail queue.
+.Pp
+The macro
+.Nm TAILQ_ENTRY
+declares a structure that connects the elements in
+the tail queue.
+.Pp
+The macro
+.Nm TAILQ_FIRST
+returns the first item on the tail queue or NULL if the tail queue
+is empty.
+.Pp
+The macro
+.Nm TAILQ_FOREACH
+traverses the tail queue referenced by
+.Fa head
+in the forward direction, assigning each element in turn to
+.Fa var .
+.Fa var
+is set to
+.Dv NULL
+if the loop completes normally, or if there were no elements.
+.Pp
+The macro
+.Nm TAILQ_FOREACH_REVERSE
+traverses the tail queue referenced by
+.Fa head
+in the reverse direction, assigning each element in turn to
+.Fa var .
+.Pp
+The macros
+.Nm TAILQ_FOREACH_SAFE
+and
+.Nm TAILQ_FOREACH_REVERSE_SAFE
+traverse the list referenced by
+.Fa head
+in the forward or reverse direction respectively,
+assigning each element in turn to
+.Fa var .
+However, unlike their unsafe counterparts,
+.Nm TAILQ_FOREACH
+and
+.Nm TAILQ_FOREACH_REVERSE
+permit to both remove
+.Fa var
+as well as free it from within the loop safely without interfering with the
+traversal.
+.Pp
+The macro
+.Nm TAILQ_INIT
+initializes the tail queue referenced by
+.Fa head .
+.Pp
+The macro
+.Nm TAILQ_INSERT_HEAD
+inserts the new element
+.Fa elm
+at the head of the tail queue.
+.Pp
+The macro
+.Nm TAILQ_INSERT_TAIL
+inserts the new element
+.Fa elm
+at the end of the tail queue.
+.Pp
+The macro
+.Nm TAILQ_INSERT_AFTER
+inserts the new element
+.Fa elm
+after the element
+.Fa listelm .
+.Pp
+The macro
+.Nm TAILQ_INSERT_BEFORE
+inserts the new element
+.Fa elm
+before the element
+.Fa listelm .
+.Pp
+The macro
+.Nm TAILQ_LAST
+returns the last item on the tail queue.
+If the tail queue is empty the return value is
+.Dv NULL .
+.Pp
+The macro
+.Nm TAILQ_NEXT
+returns the next item on the tail queue, or NULL if this item is the last.
+.Pp
+The macro
+.Nm TAILQ_PREV
+returns the previous item on the tail queue, or NULL if this item
+is the first.
+.Pp
+The macro
+.Nm TAILQ_REMOVE
+removes the element
+.Fa elm
+from the tail queue.
+.Pp
+The macro
+.Nm TAILQ_SWAP
+swaps the contents of
+.Fa head1
+and
+.Fa head2 .
+.Sh TAIL QUEUE EXAMPLE
+.Bd -literal
+TAILQ_HEAD(tailhead, entry) head =
+    TAILQ_HEAD_INITIALIZER(head);
+struct tailhead *headp;			/* Tail queue head. */
+struct entry {
+	...
+	TAILQ_ENTRY(entry) entries;	/* Tail queue. */
+	...
+} *n1, *n2, *n3, *np;
+
+TAILQ_INIT(&head);			/* Initialize the queue. */
+
+n1 = malloc(sizeof(struct entry));	/* Insert at the head. */
+TAILQ_INSERT_HEAD(&head, n1, entries);
+
+n1 = malloc(sizeof(struct entry));	/* Insert at the tail. */
+TAILQ_INSERT_TAIL(&head, n1, entries);
+
+n2 = malloc(sizeof(struct entry));	/* Insert after. */
+TAILQ_INSERT_AFTER(&head, n1, n2, entries);
+
+n3 = malloc(sizeof(struct entry));	/* Insert before. */
+TAILQ_INSERT_BEFORE(n2, n3, entries);
+
+TAILQ_REMOVE(&head, n2, entries);	/* Deletion. */
+free(n2);
+					/* Forward traversal. */
+TAILQ_FOREACH(np, &head, entries)
+	np-> ...
+					/* Safe forward traversal. */
+TAILQ_FOREACH_SAFE(np, &head, entries, np_temp) {
+	np->do_stuff();
+	...
+	TAILQ_REMOVE(&head, np, entries);
+	free(np);
+}
+					/* Reverse traversal. */
+TAILQ_FOREACH_REVERSE(np, &head, tailhead, entries)
+	np-> ...
+					/* TailQ Deletion. */
+while (!TAILQ_EMPTY(&head)) {
+	n1 = TAILQ_FIRST(&head);
+	TAILQ_REMOVE(&head, n1, entries);
+	free(n1);
+}
+					/* Faster TailQ Deletion. */
+n1 = TAILQ_FIRST(&head);
+while (n1 != NULL) {
+	n2 = TAILQ_NEXT(n1, entries);
+	free(n1);
+	n1 = n2;
+}
+TAILQ_INIT(&head);
+.Ed
+.Sh SEE ALSO
+.Xr tree 3
+.Sh HISTORY
+The
+.Nm queue
+functions first appeared in
+.Bx 4.4 .
diff --git a/tools/libxl/external/bsd-sys-queue.h b/tools/libxl/external/bsd-sys-queue.h
new file mode 100644
index 0000000..274e636
--- /dev/null
+++ b/tools/libxl/external/bsd-sys-queue.h
@@ -0,0 +1,637 @@
+/*-
+ * Copyright (c) 1991, 1993
+ *	The Regents of the University of California.  All rights reserved.
+ *
+ * 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.
+ * 4. Neither the name of the University 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 REGENTS 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 REGENTS 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.
+ *
+ *	@(#)queue.h	8.5 (Berkeley) 8/20/94
+ * $FreeBSD$
+ */
+
+#ifndef _SYS_QUEUE_H_
+#define	_SYS_QUEUE_H_
+
+#include <sys/cdefs.h>
+
+/*
+ * This file defines four types of data structures: singly-linked lists,
+ * singly-linked tail queues, lists and tail queues.
+ *
+ * A singly-linked list is headed by a single forward pointer. The elements
+ * are singly linked for minimum space and pointer manipulation overhead at
+ * the expense of O(n) removal for arbitrary elements. New elements can be
+ * added to the list after an existing element or at the head of the list.
+ * Elements being removed from the head of the list should use the explicit
+ * macro for this purpose for optimum efficiency. A singly-linked list may
+ * only be traversed in the forward direction.  Singly-linked lists are ideal
+ * for applications with large datasets and few or no removals or for
+ * implementing a LIFO queue.
+ *
+ * A singly-linked tail queue is headed by a pair of pointers, one to the
+ * head of the list and the other to the tail of the list. The elements are
+ * singly linked for minimum space and pointer manipulation overhead at the
+ * expense of O(n) removal for arbitrary elements. New elements can be added
+ * to the list after an existing element, at the head of the list, or at the
+ * end of the list. Elements being removed from the head of the tail queue
+ * should use the explicit macro for this purpose for optimum efficiency.
+ * A singly-linked tail queue may only be traversed in the forward direction.
+ * Singly-linked tail queues are ideal for applications with large datasets
+ * and few or no removals or for implementing a FIFO queue.
+ *
+ * A list is headed by a single forward pointer (or an array of forward
+ * pointers for a hash table header). The elements are doubly linked
+ * so that an arbitrary element can be removed without a need to
+ * traverse the list. New elements can be added to the list before
+ * or after an existing element or at the head of the list. A list
+ * may only be traversed in the forward direction.
+ *
+ * A tail queue is headed by a pair of pointers, one to the head of the
+ * list and the other to the tail of the list. The elements are doubly
+ * linked so that an arbitrary element can be removed without a need to
+ * traverse the list. New elements can be added to the list before or
+ * after an existing element, at the head of the list, or at the end of
+ * the list. A tail queue may be traversed in either direction.
+ *
+ * For details on the use of these macros, see the queue(3) manual page.
+ *
+ *
+ *				SLIST	LIST	STAILQ	TAILQ
+ * _HEAD			+	+	+	+
+ * _HEAD_INITIALIZER		+	+	+	+
+ * _ENTRY			+	+	+	+
+ * _INIT			+	+	+	+
+ * _EMPTY			+	+	+	+
+ * _FIRST			+	+	+	+
+ * _NEXT			+	+	+	+
+ * _PREV			-	-	-	+
+ * _LAST			-	-	+	+
+ * _FOREACH			+	+	+	+
+ * _FOREACH_SAFE		+	+	+	+
+ * _FOREACH_REVERSE		-	-	-	+
+ * _FOREACH_REVERSE_SAFE	-	-	-	+
+ * _INSERT_HEAD			+	+	+	+
+ * _INSERT_BEFORE		-	+	-	+
+ * _INSERT_AFTER		+	+	+	+
+ * _INSERT_TAIL			-	-	+	+
+ * _CONCAT			-	-	+	+
+ * _REMOVE_AFTER		+	-	+	-
+ * _REMOVE_HEAD			+	-	+	-
+ * _REMOVE			+	+	+	+
+ * _SWAP			+	+	+	+
+ *
+ */
+#ifdef QUEUE_MACRO_DEBUG
+/* Store the last 2 places the queue element or head was altered */
+struct qm_trace {
+	char * lastfile;
+	int lastline;
+	char * prevfile;
+	int prevline;
+};
+
+#define	TRACEBUF	struct qm_trace trace;
+#define	TRASHIT(x)	do {(x) = (void *)-1;} while (0)
+#define	QMD_SAVELINK(name, link)	void **name = (void *)&(link)
+
+#define	QMD_TRACE_HEAD(head) do {					\
+	(head)->trace.prevline = (head)->trace.lastline;		\
+	(head)->trace.prevfile = (head)->trace.lastfile;		\
+	(head)->trace.lastline = __LINE__;				\
+	(head)->trace.lastfile = __FILE__;				\
+} while (0)
+
+#define	QMD_TRACE_ELEM(elem) do {					\
+	(elem)->trace.prevline = (elem)->trace.lastline;		\
+	(elem)->trace.prevfile = (elem)->trace.lastfile;		\
+	(elem)->trace.lastline = __LINE__;				\
+	(elem)->trace.lastfile = __FILE__;				\
+} while (0)
+
+#else
+#define	QMD_TRACE_ELEM(elem)
+#define	QMD_TRACE_HEAD(head)
+#define	QMD_SAVELINK(name, link)
+#define	TRACEBUF
+#define	TRASHIT(x)
+#endif	/* QUEUE_MACRO_DEBUG */
+
+/*
+ * Singly-linked List declarations.
+ */
+#define	SLIST_HEAD(name, type)						\
+struct name {								\
+	struct type *slh_first;	/* first element */			\
+}
+
+#define	SLIST_HEAD_INITIALIZER(head)					\
+	{ NULL }
+
+#define	SLIST_ENTRY(type)						\
+struct {								\
+	struct type *sle_next;	/* next element */			\
+}
+
+/*
+ * Singly-linked List functions.
+ */
+#define	SLIST_EMPTY(head)	((head)->slh_first == NULL)
+
+#define	SLIST_FIRST(head)	((head)->slh_first)
+
+#define	SLIST_FOREACH(var, head, field)					\
+	for ((var) = SLIST_FIRST((head));				\
+	    (var);							\
+	    (var) = SLIST_NEXT((var), field))
+
+#define	SLIST_FOREACH_SAFE(var, head, field, tvar)			\
+	for ((var) = SLIST_FIRST((head));				\
+	    (var) && ((tvar) = SLIST_NEXT((var), field), 1);		\
+	    (var) = (tvar))
+
+#define	SLIST_FOREACH_PREVPTR(var, varp, head, field)			\
+	for ((varp) = &SLIST_FIRST((head));				\
+	    ((var) = *(varp)) != NULL;					\
+	    (varp) = &SLIST_NEXT((var), field))
+
+#define	SLIST_INIT(head) do {						\
+	SLIST_FIRST((head)) = NULL;					\
+} while (0)
+
+#define	SLIST_INSERT_AFTER(slistelm, elm, field) do {			\
+	SLIST_NEXT((elm), field) = SLIST_NEXT((slistelm), field);	\
+	SLIST_NEXT((slistelm), field) = (elm);				\
+} while (0)
+
+#define	SLIST_INSERT_HEAD(head, elm, field) do {			\
+	SLIST_NEXT((elm), field) = SLIST_FIRST((head));			\
+	SLIST_FIRST((head)) = (elm);					\
+} while (0)
+
+#define	SLIST_NEXT(elm, field)	((elm)->field.sle_next)
+
+#define	SLIST_REMOVE(head, elm, type, field) do {			\
+	QMD_SAVELINK(oldnext, (elm)->field.sle_next);			\
+	if (SLIST_FIRST((head)) == (elm)) {				\
+		SLIST_REMOVE_HEAD((head), field);			\
+	}								\
+	else {								\
+		struct type *curelm = SLIST_FIRST((head));		\
+		while (SLIST_NEXT(curelm, field) != (elm))		\
+			curelm = SLIST_NEXT(curelm, field);		\
+		SLIST_REMOVE_AFTER(curelm, field);			\
+	}								\
+	TRASHIT(*oldnext);						\
+} while (0)
+
+#define SLIST_REMOVE_AFTER(elm, field) do {				\
+	SLIST_NEXT(elm, field) =					\
+	    SLIST_NEXT(SLIST_NEXT(elm, field), field);			\
+} while (0)
+
+#define	SLIST_REMOVE_HEAD(head, field) do {				\
+	SLIST_FIRST((head)) = SLIST_NEXT(SLIST_FIRST((head)), field);	\
+} while (0)
+
+#define SLIST_SWAP(head1, head2, type) do {				\
+	struct type *swap_first = SLIST_FIRST(head1);			\
+	SLIST_FIRST(head1) = SLIST_FIRST(head2);			\
+	SLIST_FIRST(head2) = swap_first;				\
+} while (0)
+
+/*
+ * Singly-linked Tail queue declarations.
+ */
+#define	STAILQ_HEAD(name, type)						\
+struct name {								\
+	struct type *stqh_first;/* first element */			\
+	struct type **stqh_last;/* addr of last next element */		\
+}
+
+#define	STAILQ_HEAD_INITIALIZER(head)					\
+	{ NULL, &(head).stqh_first }
+
+#define	STAILQ_ENTRY(type)						\
+struct {								\
+	struct type *stqe_next;	/* next element */			\
+}
+
+/*
+ * Singly-linked Tail queue functions.
+ */
+#define	STAILQ_CONCAT(head1, head2) do {				\
+	if (!STAILQ_EMPTY((head2))) {					\
+		*(head1)->stqh_last = (head2)->stqh_first;		\
+		(head1)->stqh_last = (head2)->stqh_last;		\
+		STAILQ_INIT((head2));					\
+	}								\
+} while (0)
+
+#define	STAILQ_EMPTY(head)	((head)->stqh_first == NULL)
+
+#define	STAILQ_FIRST(head)	((head)->stqh_first)
+
+#define	STAILQ_FOREACH(var, head, field)				\
+	for((var) = STAILQ_FIRST((head));				\
+	   (var);							\
+	   (var) = STAILQ_NEXT((var), field))
+
+
+#define	STAILQ_FOREACH_SAFE(var, head, field, tvar)			\
+	for ((var) = STAILQ_FIRST((head));				\
+	    (var) && ((tvar) = STAILQ_NEXT((var), field), 1);		\
+	    (var) = (tvar))
+
+#define	STAILQ_INIT(head) do {						\
+	STAILQ_FIRST((head)) = NULL;					\
+	(head)->stqh_last = &STAILQ_FIRST((head));			\
+} while (0)
+
+#define	STAILQ_INSERT_AFTER(head, tqelm, elm, field) do {		\
+	if ((STAILQ_NEXT((elm), field) = STAILQ_NEXT((tqelm), field)) == NULL)\
+		(head)->stqh_last = &STAILQ_NEXT((elm), field);		\
+	STAILQ_NEXT((tqelm), field) = (elm);				\
+} while (0)
+
+#define	STAILQ_INSERT_HEAD(head, elm, field) do {			\
+	if ((STAILQ_NEXT((elm), field) = STAILQ_FIRST((head))) == NULL)	\
+		(head)->stqh_last = &STAILQ_NEXT((elm), field);		\
+	STAILQ_FIRST((head)) = (elm);					\
+} while (0)
+
+#define	STAILQ_INSERT_TAIL(head, elm, field) do {			\
+	STAILQ_NEXT((elm), field) = NULL;				\
+	*(head)->stqh_last = (elm);					\
+	(head)->stqh_last = &STAILQ_NEXT((elm), field);			\
+} while (0)
+
+#define	STAILQ_LAST(head, type, field)					\
+	(STAILQ_EMPTY((head)) ?						\
+		NULL :							\
+	        ((struct type *)(void *)				\
+		((char *)((head)->stqh_last) - __offsetof(struct type, field))))
+
+#define	STAILQ_NEXT(elm, field)	((elm)->field.stqe_next)
+
+#define	STAILQ_REMOVE(head, elm, type, field) do {			\
+	QMD_SAVELINK(oldnext, (elm)->field.stqe_next);			\
+	if (STAILQ_FIRST((head)) == (elm)) {				\
+		STAILQ_REMOVE_HEAD((head), field);			\
+	}								\
+	else {								\
+		struct type *curelm = STAILQ_FIRST((head));		\
+		while (STAILQ_NEXT(curelm, field) != (elm))		\
+			curelm = STAILQ_NEXT(curelm, field);		\
+		STAILQ_REMOVE_AFTER(head, curelm, field);		\
+	}								\
+	TRASHIT(*oldnext);						\
+} while (0)
+
+#define STAILQ_REMOVE_AFTER(head, elm, field) do {			\
+	if ((STAILQ_NEXT(elm, field) =					\
+	     STAILQ_NEXT(STAILQ_NEXT(elm, field), field)) == NULL)	\
+		(head)->stqh_last = &STAILQ_NEXT((elm), field);		\
+} while (0)
+
+#define	STAILQ_REMOVE_HEAD(head, field) do {				\
+	if ((STAILQ_FIRST((head)) =					\
+	     STAILQ_NEXT(STAILQ_FIRST((head)), field)) == NULL)		\
+		(head)->stqh_last = &STAILQ_FIRST((head));		\
+} while (0)
+
+#define STAILQ_SWAP(head1, head2, type) do {				\
+	struct type *swap_first = STAILQ_FIRST(head1);			\
+	struct type **swap_last = (head1)->stqh_last;			\
+	STAILQ_FIRST(head1) = STAILQ_FIRST(head2);			\
+	(head1)->stqh_last = (head2)->stqh_last;			\
+	STAILQ_FIRST(head2) = swap_first;				\
+	(head2)->stqh_last = swap_last;					\
+	if (STAILQ_EMPTY(head1))					\
+		(head1)->stqh_last = &STAILQ_FIRST(head1);		\
+	if (STAILQ_EMPTY(head2))					\
+		(head2)->stqh_last = &STAILQ_FIRST(head2);		\
+} while (0)
+
+
+/*
+ * List declarations.
+ */
+#define	LIST_HEAD(name, type)						\
+struct name {								\
+	struct type *lh_first;	/* first element */			\
+}
+
+#define	LIST_HEAD_INITIALIZER(head)					\
+	{ NULL }
+
+#define	LIST_ENTRY(type)						\
+struct {								\
+	struct type *le_next;	/* next element */			\
+	struct type **le_prev;	/* address of previous next element */	\
+}
+
+/*
+ * List functions.
+ */
+
+#if (defined(_KERNEL) && defined(INVARIANTS))
+#define	QMD_LIST_CHECK_HEAD(head, field) do {				\
+	if (LIST_FIRST((head)) != NULL &&				\
+	    LIST_FIRST((head))->field.le_prev !=			\
+	     &LIST_FIRST((head)))					\
+		panic("Bad list head %p first->prev != head", (head));	\
+} while (0)
+
+#define	QMD_LIST_CHECK_NEXT(elm, field) do {				\
+	if (LIST_NEXT((elm), field) != NULL &&				\
+	    LIST_NEXT((elm), field)->field.le_prev !=			\
+	     &((elm)->field.le_next))					\
+	     	panic("Bad link elm %p next->prev != elm", (elm));	\
+} while (0)
+
+#define	QMD_LIST_CHECK_PREV(elm, field) do {				\
+	if (*(elm)->field.le_prev != (elm))				\
+		panic("Bad link elm %p prev->next != elm", (elm));	\
+} while (0)
+#else
+#define	QMD_LIST_CHECK_HEAD(head, field)
+#define	QMD_LIST_CHECK_NEXT(elm, field)
+#define	QMD_LIST_CHECK_PREV(elm, field)
+#endif /* (_KERNEL && INVARIANTS) */
+
+#define	LIST_EMPTY(head)	((head)->lh_first == NULL)
+
+#define	LIST_FIRST(head)	((head)->lh_first)
+
+#define	LIST_FOREACH(var, head, field)					\
+	for ((var) = LIST_FIRST((head));				\
+	    (var);							\
+	    (var) = LIST_NEXT((var), field))
+
+#define	LIST_FOREACH_SAFE(var, head, field, tvar)			\
+	for ((var) = LIST_FIRST((head));				\
+	    (var) && ((tvar) = LIST_NEXT((var), field), 1);		\
+	    (var) = (tvar))
+
+#define	LIST_INIT(head) do {						\
+	LIST_FIRST((head)) = NULL;					\
+} while (0)
+
+#define	LIST_INSERT_AFTER(listelm, elm, field) do {			\
+	QMD_LIST_CHECK_NEXT(listelm, field);				\
+	if ((LIST_NEXT((elm), field) = LIST_NEXT((listelm), field)) != NULL)\
+		LIST_NEXT((listelm), field)->field.le_prev =		\
+		    &LIST_NEXT((elm), field);				\
+	LIST_NEXT((listelm), field) = (elm);				\
+	(elm)->field.le_prev = &LIST_NEXT((listelm), field);		\
+} while (0)
+
+#define	LIST_INSERT_BEFORE(listelm, elm, field) do {			\
+	QMD_LIST_CHECK_PREV(listelm, field);				\
+	(elm)->field.le_prev = (listelm)->field.le_prev;		\
+	LIST_NEXT((elm), field) = (listelm);				\
+	*(listelm)->field.le_prev = (elm);				\
+	(listelm)->field.le_prev = &LIST_NEXT((elm), field);		\
+} while (0)
+
+#define	LIST_INSERT_HEAD(head, elm, field) do {				\
+	QMD_LIST_CHECK_HEAD((head), field);				\
+	if ((LIST_NEXT((elm), field) = LIST_FIRST((head))) != NULL)	\
+		LIST_FIRST((head))->field.le_prev = &LIST_NEXT((elm), field);\
+	LIST_FIRST((head)) = (elm);					\
+	(elm)->field.le_prev = &LIST_FIRST((head));			\
+} while (0)
+
+#define	LIST_NEXT(elm, field)	((elm)->field.le_next)
+
+#define	LIST_REMOVE(elm, field) do {					\
+	QMD_SAVELINK(oldnext, (elm)->field.le_next);			\
+	QMD_SAVELINK(oldprev, (elm)->field.le_prev);			\
+	QMD_LIST_CHECK_NEXT(elm, field);				\
+	QMD_LIST_CHECK_PREV(elm, field);				\
+	if (LIST_NEXT((elm), field) != NULL)				\
+		LIST_NEXT((elm), field)->field.le_prev = 		\
+		    (elm)->field.le_prev;				\
+	*(elm)->field.le_prev = LIST_NEXT((elm), field);		\
+	TRASHIT(*oldnext);						\
+	TRASHIT(*oldprev);						\
+} while (0)
+
+#define LIST_SWAP(head1, head2, type, field) do {			\
+	struct type *swap_tmp = LIST_FIRST((head1));			\
+	LIST_FIRST((head1)) = LIST_FIRST((head2));			\
+	LIST_FIRST((head2)) = swap_tmp;					\
+	if ((swap_tmp = LIST_FIRST((head1))) != NULL)			\
+		swap_tmp->field.le_prev = &LIST_FIRST((head1));		\
+	if ((swap_tmp = LIST_FIRST((head2))) != NULL)			\
+		swap_tmp->field.le_prev = &LIST_FIRST((head2));		\
+} while (0)
+
+/*
+ * Tail queue declarations.
+ */
+#define	TAILQ_HEAD(name, type)						\
+struct name {								\
+	struct type *tqh_first;	/* first element */			\
+	struct type **tqh_last;	/* addr of last next element */		\
+	TRACEBUF							\
+}
+
+#define	TAILQ_HEAD_INITIALIZER(head)					\
+	{ NULL, &(head).tqh_first }
+
+#define	TAILQ_ENTRY(type)						\
+struct {								\
+	struct type *tqe_next;	/* next element */			\
+	struct type **tqe_prev;	/* address of previous next element */	\
+	TRACEBUF							\
+}
+
+/*
+ * Tail queue functions.
+ */
+#if (defined(_KERNEL) && defined(INVARIANTS))
+#define	QMD_TAILQ_CHECK_HEAD(head, field) do {				\
+	if (!TAILQ_EMPTY(head) &&					\
+	    TAILQ_FIRST((head))->field.tqe_prev !=			\
+	     &TAILQ_FIRST((head)))					\
+		panic("Bad tailq head %p first->prev != head", (head));	\
+} while (0)
+
+#define	QMD_TAILQ_CHECK_TAIL(head, field) do {				\
+	if (*(head)->tqh_last != NULL)					\
+	    	panic("Bad tailq NEXT(%p->tqh_last) != NULL", (head)); 	\
+} while (0)
+
+#define	QMD_TAILQ_CHECK_NEXT(elm, field) do {				\
+	if (TAILQ_NEXT((elm), field) != NULL &&				\
+	    TAILQ_NEXT((elm), field)->field.tqe_prev !=			\
+	     &((elm)->field.tqe_next))					\
+		panic("Bad link elm %p next->prev != elm", (elm));	\
+} while (0)
+
+#define	QMD_TAILQ_CHECK_PREV(elm, field) do {				\
+	if (*(elm)->field.tqe_prev != (elm))				\
+		panic("Bad link elm %p prev->next != elm", (elm));	\
+} while (0)
+#else
+#define	QMD_TAILQ_CHECK_HEAD(head, field)
+#define	QMD_TAILQ_CHECK_TAIL(head, headname)
+#define	QMD_TAILQ_CHECK_NEXT(elm, field)
+#define	QMD_TAILQ_CHECK_PREV(elm, field)
+#endif /* (_KERNEL && INVARIANTS) */
+
+#define	TAILQ_CONCAT(head1, head2, field) do {				\
+	if (!TAILQ_EMPTY(head2)) {					\
+		*(head1)->tqh_last = (head2)->tqh_first;		\
+		(head2)->tqh_first->field.tqe_prev = (head1)->tqh_last;	\
+		(head1)->tqh_last = (head2)->tqh_last;			\
+		TAILQ_INIT((head2));					\
+		QMD_TRACE_HEAD(head1);					\
+		QMD_TRACE_HEAD(head2);					\
+	}								\
+} while (0)
+
+#define	TAILQ_EMPTY(head)	((head)->tqh_first == NULL)
+
+#define	TAILQ_FIRST(head)	((head)->tqh_first)
+
+#define	TAILQ_FOREACH(var, head, field)					\
+	for ((var) = TAILQ_FIRST((head));				\
+	    (var);							\
+	    (var) = TAILQ_NEXT((var), field))
+
+#define	TAILQ_FOREACH_SAFE(var, head, field, tvar)			\
+	for ((var) = TAILQ_FIRST((head));				\
+	    (var) && ((tvar) = TAILQ_NEXT((var), field), 1);		\
+	    (var) = (tvar))
+
+#define	TAILQ_FOREACH_REVERSE(var, head, headname, field)		\
+	for ((var) = TAILQ_LAST((head), headname);			\
+	    (var);							\
+	    (var) = TAILQ_PREV((var), headname, field))
+
+#define	TAILQ_FOREACH_REVERSE_SAFE(var, head, headname, field, tvar)	\
+	for ((var) = TAILQ_LAST((head), headname);			\
+	    (var) && ((tvar) = TAILQ_PREV((var), headname, field), 1);	\
+	    (var) = (tvar))
+
+#define	TAILQ_INIT(head) do {						\
+	TAILQ_FIRST((head)) = NULL;					\
+	(head)->tqh_last = &TAILQ_FIRST((head));			\
+	QMD_TRACE_HEAD(head);						\
+} while (0)
+
+#define	TAILQ_INSERT_AFTER(head, listelm, elm, field) do {		\
+	QMD_TAILQ_CHECK_NEXT(listelm, field);				\
+	if ((TAILQ_NEXT((elm), field) = TAILQ_NEXT((listelm), field)) != NULL)\
+		TAILQ_NEXT((elm), field)->field.tqe_prev = 		\
+		    &TAILQ_NEXT((elm), field);				\
+	else {								\
+		(head)->tqh_last = &TAILQ_NEXT((elm), field);		\
+		QMD_TRACE_HEAD(head);					\
+	}								\
+	TAILQ_NEXT((listelm), field) = (elm);				\
+	(elm)->field.tqe_prev = &TAILQ_NEXT((listelm), field);		\
+	QMD_TRACE_ELEM(&(elm)->field);					\
+	QMD_TRACE_ELEM(&listelm->field);				\
+} while (0)
+
+#define	TAILQ_INSERT_BEFORE(listelm, elm, field) do {			\
+	QMD_TAILQ_CHECK_PREV(listelm, field);				\
+	(elm)->field.tqe_prev = (listelm)->field.tqe_prev;		\
+	TAILQ_NEXT((elm), field) = (listelm);				\
+	*(listelm)->field.tqe_prev = (elm);				\
+	(listelm)->field.tqe_prev = &TAILQ_NEXT((elm), field);		\
+	QMD_TRACE_ELEM(&(elm)->field);					\
+	QMD_TRACE_ELEM(&listelm->field);				\
+} while (0)
+
+#define	TAILQ_INSERT_HEAD(head, elm, field) do {			\
+	QMD_TAILQ_CHECK_HEAD(head, field);				\
+	if ((TAILQ_NEXT((elm), field) = TAILQ_FIRST((head))) != NULL)	\
+		TAILQ_FIRST((head))->field.tqe_prev =			\
+		    &TAILQ_NEXT((elm), field);				\
+	else								\
+		(head)->tqh_last = &TAILQ_NEXT((elm), field);		\
+	TAILQ_FIRST((head)) = (elm);					\
+	(elm)->field.tqe_prev = &TAILQ_FIRST((head));			\
+	QMD_TRACE_HEAD(head);						\
+	QMD_TRACE_ELEM(&(elm)->field);					\
+} while (0)
+
+#define	TAILQ_INSERT_TAIL(head, elm, field) do {			\
+	QMD_TAILQ_CHECK_TAIL(head, field);				\
+	TAILQ_NEXT((elm), field) = NULL;				\
+	(elm)->field.tqe_prev = (head)->tqh_last;			\
+	*(head)->tqh_last = (elm);					\
+	(head)->tqh_last = &TAILQ_NEXT((elm), field);			\
+	QMD_TRACE_HEAD(head);						\
+	QMD_TRACE_ELEM(&(elm)->field);					\
+} while (0)
+
+#define	TAILQ_LAST(head, headname)					\
+	(*(((struct headname *)((head)->tqh_last))->tqh_last))
+
+#define	TAILQ_NEXT(elm, field) ((elm)->field.tqe_next)
+
+#define	TAILQ_PREV(elm, headname, field)				\
+	(*(((struct headname *)((elm)->field.tqe_prev))->tqh_last))
+
+#define	TAILQ_REMOVE(head, elm, field) do {				\
+	QMD_SAVELINK(oldnext, (elm)->field.tqe_next);			\
+	QMD_SAVELINK(oldprev, (elm)->field.tqe_prev);			\
+	QMD_TAILQ_CHECK_NEXT(elm, field);				\
+	QMD_TAILQ_CHECK_PREV(elm, field);				\
+	if ((TAILQ_NEXT((elm), field)) != NULL)				\
+		TAILQ_NEXT((elm), field)->field.tqe_prev = 		\
+		    (elm)->field.tqe_prev;				\
+	else {								\
+		(head)->tqh_last = (elm)->field.tqe_prev;		\
+		QMD_TRACE_HEAD(head);					\
+	}								\
+	*(elm)->field.tqe_prev = TAILQ_NEXT((elm), field);		\
+	TRASHIT(*oldnext);						\
+	TRASHIT(*oldprev);						\
+	QMD_TRACE_ELEM(&(elm)->field);					\
+} while (0)
+
+#define TAILQ_SWAP(head1, head2, type, field) do {			\
+	struct type *swap_first = (head1)->tqh_first;			\
+	struct type **swap_last = (head1)->tqh_last;			\
+	(head1)->tqh_first = (head2)->tqh_first;			\
+	(head1)->tqh_last = (head2)->tqh_last;				\
+	(head2)->tqh_first = swap_first;				\
+	(head2)->tqh_last = swap_last;					\
+	if ((swap_first = (head1)->tqh_first) != NULL)			\
+		swap_first->field.tqe_prev = &(head1)->tqh_first;	\
+	else								\
+		(head1)->tqh_last = &(head1)->tqh_first;		\
+	if ((swap_first = (head2)->tqh_first) != NULL)			\
+		swap_first->field.tqe_prev = &(head2)->tqh_first;	\
+	else								\
+		(head2)->tqh_last = &(head2)->tqh_first;		\
+} while (0)
+
+#endif /* !_SYS_QUEUE_H_ */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 18:11:31 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 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.xensource.com>)
	id 1RXd0W-00068i-IC; Mon, 05 Dec 2011 18:11:16 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RXd0T-00065w-CR
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 18:11:13 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1323108624!1307875!10
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjAyNg==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27300 invoked from network); 5 Dec 2011 18:10:28 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Dec 2011 18:10:28 -0000
X-IronPort-AV: E=Sophos;i="4.71,300,1320624000"; 
   d="scan'208";a="9297529"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Dec 2011 18:10:28 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 5 Dec 2011 18:10:28 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RXczk-0003kL-F6; Mon, 05 Dec 2011 18:10:28 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RXczk-0006WT-EG;
	Mon, 05 Dec 2011 18:10:28 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Mon, 5 Dec 2011 18:10:16 +0000
Message-ID: <1323108621-22654-11-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1323108621-22654-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1323108621-22654-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 10/15] libxl: make libxl__[v]log const-correct
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl_internal.c |    4 ++--
 tools/libxl/libxl_internal.h |    4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c
index d767ce3..ae28cb0 100644
--- a/tools/libxl/libxl_internal.c
+++ b/tools/libxl/libxl_internal.c
@@ -179,7 +179,7 @@ char *libxl__dirname(libxl__gc *gc, const char *s)
 
 void libxl__logv(libxl_ctx *ctx, xentoollog_level msglevel, int errnoval,
              const char *file, int line, const char *func,
-             char *fmt, va_list ap)
+             const char *fmt, va_list ap)
 {
     char *enomem = "[out of memory formatting log message]";
     char *base = NULL;
@@ -206,7 +206,7 @@ void libxl__logv(libxl_ctx *ctx, xentoollog_level msglevel, int errnoval,
 
 void libxl__log(libxl_ctx *ctx, xentoollog_level msglevel, int errnoval,
             const char *file, int line, const char *func,
-            char *fmt, ...)
+            const char *fmt, ...)
 {
     va_list ap;
     va_start(ap, fmt);
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 41de6fd..1d1dc35 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -80,13 +80,13 @@
 _hidden void libxl__logv(libxl_ctx *ctx, xentoollog_level msglevel, int errnoval,
              const char *file /* may be 0 */, int line /* ignored if !file */,
              const char *func /* may be 0 */,
-             char *fmt, va_list al)
+             const char *fmt, va_list al)
      __attribute__((format(printf,7,0)));
 
 _hidden void libxl__log(libxl_ctx *ctx, xentoollog_level msglevel, int errnoval,
             const char *file /* may be 0 */, int line /* ignored if !file */,
             const char *func /* may be 0 */,
-            char *fmt, ...)
+            const char *fmt, ...)
      __attribute__((format(printf,7,8)));
 
      /* these functions preserve errno (saving and restoring) */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 18:11:31 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 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.xensource.com>)
	id 1RXd0V-00068L-Lt; Mon, 05 Dec 2011 18:11:15 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RXd0T-00065u-1O
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 18:11:13 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1323108624!1307875!5
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjAyNg==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27171 invoked from network); 5 Dec 2011 18:10:26 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Dec 2011 18:10:26 -0000
X-IronPort-AV: E=Sophos;i="4.71,300,1320624000"; 
   d="scan'208";a="9297523"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Dec 2011 18:10:26 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 5 Dec 2011 18:10:26 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RXczi-0003k3-By; Mon, 05 Dec 2011 18:10:26 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RXczi-0006W5-BC;
	Mon, 05 Dec 2011 18:10:26 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Mon, 5 Dec 2011 18:10:10 +0000
Message-ID: <1323108621-22654-5-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1323108621-22654-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1323108621-22654-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 04/15] libxl: idl: support new "private" type
	attribute
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This provides for fields in libxl datatypes which are only present in
the C version of structures and are used only by libxl itself.  This
is useful when a libxl datatype wants to contain fields which are used
by libxl internally and which are only present in the structure to
avoid additional memory allocation inconvenience.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/gentest.py    |    2 ++
 tools/libxl/libxltypes.py |    4 +++-
 tools/python/genwrap.py   |    7 +++++++
 3 files changed, 12 insertions(+), 1 deletions(-)

diff --git a/tools/libxl/gentest.py b/tools/libxl/gentest.py
index 05e77cc..ac7a400 100644
--- a/tools/libxl/gentest.py
+++ b/tools/libxl/gentest.py
@@ -56,6 +56,8 @@ def gen_rand_init(ty, v, indent = "    ", parent = None):
         s += "%s = rand() %% 2;\n" % v
     elif ty.typename in ["char *"]:
         s += "%s = rand_str();\n" % v
+    elif ty.private:
+        pass
     elif ty.typename in handcoded:
         raise Exception("Gen for handcoded %s" % ty.typename)
     else:
diff --git a/tools/libxl/libxltypes.py b/tools/libxl/libxltypes.py
index 55056c2..450de88 100644
--- a/tools/libxl/libxltypes.py
+++ b/tools/libxl/libxltypes.py
@@ -33,6 +33,8 @@ class Type(object):
         if self.passby not in [PASS_BY_VALUE, PASS_BY_REFERENCE]:
             raise ValueError
 
+        self.private = kwargs.setdefault('private', False)
+
         if typename is None: # Anonymous type
             self.typename = None
             self.rawname = None
@@ -50,7 +52,7 @@ class Type(object):
 
         self.autogenerate_dispose_fn = kwargs.setdefault('autogenerate_dispose_fn', True)
 
-        if self.typename is not None:
+        if self.typename is not None and not self.private:
             self.json_fn = kwargs.setdefault('json_fn', self.typename + "_gen_json")
         else:
             self.json_fn = kwargs.setdefault('json_fn', None)
diff --git a/tools/python/genwrap.py b/tools/python/genwrap.py
index d0c193d..ecbec11 100644
--- a/tools/python/genwrap.py
+++ b/tools/python/genwrap.py
@@ -129,6 +129,8 @@ static PyObject *Py%(rawname)s_new(PyTypeObject *type, PyObject *args, PyObject
 
     l.append('static PyGetSetDef Py%s_getset[] = {'%ty.rawname)
     for f in ty.fields:
+        if f.type.private:
+            continue
         l.append('    { .name = "%s", '%f.name)
         if ty.marshal_out():
             l.append('      .get = (getter)py_%s_%s_get, '%(ty.rawname, f.name))
@@ -295,9 +297,14 @@ _hidden int genwrap__ll_set(PyObject *v, long long *val, long long mask);
 
 """ % tuple((' '.join(sys.argv),) + (os.path.split(decls)[-1:]),))
     for ty in types:
+        if ty.private:
+            continue
         if isinstance(ty, libxltypes.Aggregate):
             f.write('/* Attribute get/set functions for %s */\n'%ty.typename)
             for a in ty.fields:
+                print >>sys.stderr, `a`, `ty`, `a.type`, `a.type.__dict__`
+                if a.type.private:
+                    continue
                 if ty.marshal_out():
                     f.write(py_attrib_get(ty,a))
                 if ty.marshal_in():
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 18:11:31 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 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.xensource.com>)
	id 1RXd0T-00066c-19; Mon, 05 Dec 2011 18:11:13 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RXd0R-00065o-DM
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 18:11:11 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1323108624!1307875!3
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjAyNg==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27113 invoked from network); 5 Dec 2011 18:10:26 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Dec 2011 18:10:26 -0000
X-IronPort-AV: E=Sophos;i="4.71,300,1320624000"; 
   d="scan'208";a="9297521"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Dec 2011 18:10:26 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 5 Dec 2011 18:10:26 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RXczh-0003jx-Ms; Mon, 05 Dec 2011 18:10:25 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RXczh-0006Vx-M0;
	Mon, 05 Dec 2011 18:10:25 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Mon, 5 Dec 2011 18:10:08 +0000
Message-ID: <1323108621-22654-3-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1323108621-22654-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1323108621-22654-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 02/15] libxenstore: Provide xs_check_watch
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Event-driven programs want to wait until the xs_fileno triggers for
reading, and then repeatedly call xs_check_watch.

Also xs_read_watch exposes a useless "num" out parameter, which should
always (if things aren't going hideously wrong) be at least 2 and
which the caller shouldn't be interested in.  So xs_check_watch
doesn't have one of those.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/xenstore/xs.c |   89 ++++++++++++++++++++++++++++++++++++++++++++-------
 tools/xenstore/xs.h |   16 +++++++++
 2 files changed, 93 insertions(+), 12 deletions(-)

diff --git a/tools/xenstore/xs.c b/tools/xenstore/xs.c
index df270f7..8e54fe0 100644
--- a/tools/xenstore/xs.c
+++ b/tools/xenstore/xs.c
@@ -132,7 +132,23 @@ struct xs_handle {
 
 #endif
 
-static int read_message(struct xs_handle *h);
+static int read_message(struct xs_handle *h, int nonblocking);
+
+static void setnonblock(int fd, int nonblock) {
+	int esave = errno;
+	int flags = fcntl(fd, F_GETFL);
+	if (flags == -1)
+		goto out;
+
+	if (nonblock)
+		flags |= O_NONBLOCK;
+	else
+		flags &= ~O_NONBLOCK;
+
+	fcntl(fd, F_SETFL, flags);
+out:
+	errno = esave;
+}
 
 int xs_fileno(struct xs_handle *h)
 {
@@ -325,8 +341,16 @@ void xs_close(struct xs_handle* xsh)
 		xs_daemon_close(xsh);
 }
 
-static bool read_all(int fd, void *data, unsigned int len)
+static bool read_all(int fd, void *data, unsigned int len, int nonblocking)
+	/* With nonblocking, either reads either everything requested,
+	 * or nothing. */
 {
+	if (!len)
+		return true;
+
+	if (nonblocking)
+		setnonblock(fd, 1);
+
 	while (len) {
 		int done;
 
@@ -334,18 +358,28 @@ static bool read_all(int fd, void *data, unsigned int len)
 		if (done < 0) {
 			if (errno == EINTR)
 				continue;
-			return false;
+			goto out_false;
 		}
 		if (done == 0) {
 			/* It closed fd on us?  EBADF is appropriate. */
 			errno = EBADF;
-			return false;
+			goto out_false;
 		}
 		data += done;
 		len -= done;
+
+		if (nonblocking) {
+			setnonblock(fd, 0);
+			nonblocking = 0;
+		}
 	}
 
 	return true;
+
+out_false:
+	if (nonblocking)
+		setnonblock(fd, 0);
+	return false;
 }
 
 #ifdef XSTEST
@@ -374,7 +408,7 @@ static void *read_reply(
 	read_from_thread = read_thread_exists(h);
 
 	/* Read from comms channel ourselves if there is no reader thread. */
-	if (!read_from_thread && (read_message(h) == -1))
+	if (!read_from_thread && (read_message(h, 0) == -1))
 		return NULL;
 
 	mutex_lock(&h->reply_mutex);
@@ -693,7 +727,8 @@ bool xs_watch(struct xs_handle *h, const char *path, const char *token)
  * Returns array of two pointers: path and token, or NULL.
  * Call free() after use.
  */
-char **xs_read_watch(struct xs_handle *h, unsigned int *num)
+static char **read_watch_internal(struct xs_handle *h, unsigned int *num,
+				  int nonblocking)
 {
 	struct xs_stored_msg *msg;
 	char **ret, *strings, c = 0;
@@ -707,14 +742,20 @@ char **xs_read_watch(struct xs_handle *h, unsigned int *num)
 	 * we haven't called xs_watch.	Presumably the application
 	 * will do so later; in the meantime we just block.
 	 */
-	while (list_empty(&h->watch_list) && h->fd != -1)
+	while (list_empty(&h->watch_list) && h->fd != -1) {
+		if (nonblocking) {
+			mutex_unlock(&h->watch_mutex);
+			errno = EAGAIN;
+			return 0;
+		}
 		condvar_wait(&h->watch_condvar, &h->watch_mutex);
+	}
 #else /* !defined(USE_PTHREAD) */
 	/* Read from comms channel ourselves if there are no threads
 	 * and therefore no reader thread. */
 
 	assert(!read_thread_exists(h)); /* not threadsafe but worth a check */
-	if ((read_message(h) == -1))
+	if ((read_message(h, nonblocking) == -1))
 		return NULL;
 
 #endif /* !defined(USE_PTHREAD) */
@@ -760,6 +801,24 @@ char **xs_read_watch(struct xs_handle *h, unsigned int *num)
 	return ret;
 }
 
+char **xs_check_watch(struct xs_handle *h)
+{
+	unsigned int num;
+	char **ret;
+	ret = read_watch_internal(h, &num, 1);
+	if (ret) assert(num >= 2);
+	return ret;
+}
+
+/* Find out what node change was on (will block if nothing pending).
+ * Returns array of two pointers: path and token, or NULL.
+ * Call free() after use.
+ */
+char **xs_read_watch(struct xs_handle *h, unsigned int *num)
+{
+	return read_watch_internal(h, num, 0);
+}
+
 /* Remove a watch on a node.
  * Returns false on failure (no watch on that node).
  */
@@ -940,11 +999,17 @@ char *xs_debug_command(struct xs_handle *h, const char *cmd,
 			ARRAY_SIZE(iov), NULL);
 }
 
-static int read_message(struct xs_handle *h)
+static int read_message(struct xs_handle *h, int nonblocking)
 {
 	/* IMPORTANT: It is forbidden to call this function without
 	 * acquiring the request lock and checking that h->read_thr_exists
 	 * is false.  See "Lock discipline" in struct xs_handle, above. */
+
+	/* If nonblocking==1, this function will always read either
+	 * nothing, returning -1 and setting errno==EAGAIN, or we read
+	 * whole amount requested.  Ie as soon as we have the start of
+	 * the message we block until we get all of it.
+	 */
          
 	struct xs_stored_msg *msg = NULL;
 	char *body = NULL;
@@ -956,7 +1021,7 @@ static int read_message(struct xs_handle *h)
 	if (msg == NULL)
 		goto error;
 	cleanup_push(free, msg);
-	if (!read_all(h->fd, &msg->hdr, sizeof(msg->hdr))) { /* Cancellation point */
+	if (!read_all(h->fd, &msg->hdr, sizeof(msg->hdr), nonblocking)) { /* Cancellation point */
 		saved_errno = errno;
 		goto error_freemsg;
 	}
@@ -966,7 +1031,7 @@ static int read_message(struct xs_handle *h)
 	if (body == NULL)
 		goto error_freemsg;
 	cleanup_push(free, body);
-	if (!read_all(h->fd, body, msg->hdr.len)) { /* Cancellation point */
+	if (!read_all(h->fd, body, msg->hdr.len, 0)) { /* Cancellation point */
 		saved_errno = errno;
 		goto error_freebody;
 	}
@@ -1021,7 +1086,7 @@ static void *read_thread(void *arg)
 	struct xs_handle *h = arg;
 	int fd;
 
-	while (read_message(h) != -1)
+	while (read_message(h, 0) != -1)
 		continue;
 
 	/* An error return from read_message leaves the socket in an undefined
diff --git a/tools/xenstore/xs.h b/tools/xenstore/xs.h
index 1cbe255..63f535d 100644
--- a/tools/xenstore/xs.h
+++ b/tools/xenstore/xs.h
@@ -135,6 +135,22 @@ bool xs_watch(struct xs_handle *h, const char *path, const char *token);
 /* Return the FD to poll on to see if a watch has fired. */
 int xs_fileno(struct xs_handle *h);
 
+/* Check for node changes.  On success, returns a non-NULL pointer ret
+ * such that ret[0] and ret[1] are valid C strings, namely the
+ * triggering path (see docs/misc/xenstore.txt) and the token (from
+ * xs_watch).  On error return value is NULL setting errno.
+ * 
+ * Callers should, after xs_fileno has become readable, repeatedly
+ * call xs_check_watch until it returns NULL and sets errno to EAGAIN.
+ * (If the fd became readable, xs_check_watch is allowed to make it no
+ * longer show up as readable even if future calls to xs_check_watch
+ * will return more watch events.)
+ *
+ * After the caller is finished with the returned information it
+ * should be freed all in one go with free(ret).
+ */
+char **xs_check_watch(struct xs_handle *h);
+
 /* Find out what node change was on (will block if nothing pending).
  * Returns array containing the path and token. Use XS_WATCH_* to access these
  * elements. Call free() after use.
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 18:11:31 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 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.xensource.com>)
	id 1RXd0U-00067S-Qm; Mon, 05 Dec 2011 18:11:14 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RXd0S-00065s-Cr
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 18:11:12 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1323108624!1307875!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjAyNg==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27100 invoked from network); 5 Dec 2011 18:10:25 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Dec 2011 18:10:25 -0000
X-IronPort-AV: E=Sophos;i="4.71,300,1320624000"; 
   d="scan'208";a="9297520"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Dec 2011 18:10:25 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 5 Dec 2011 18:10:25 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RXczh-0003ju-CG; Mon, 05 Dec 2011 18:10:25 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RXczh-0006Vt-BQ;
	Mon, 05 Dec 2011 18:10:25 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Mon, 5 Dec 2011 18:10:07 +0000
Message-ID: <1323108621-22654-2-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1323108621-22654-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1323108621-22654-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 01/15] libxl: Make libxl__xs_* more const-correct
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Paths and values which are not modified by these functions should be
declared as "const char *" not "char *".

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl_internal.h |    9 +++++----
 tools/libxl/libxl_xshelp.c   |    9 +++++----
 2 files changed, 10 insertions(+), 8 deletions(-)

diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 84da6b1..bfc74c9 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -172,18 +172,19 @@ _hidden char *libxl__dirname(libxl__gc *gc, const char *s);
 _hidden char **libxl__xs_kvs_of_flexarray(libxl__gc *gc, flexarray_t *array, int length);
 
 _hidden int libxl__xs_writev(libxl__gc *gc, xs_transaction_t t,
-                    char *dir, char **kvs);
+                             const char *dir, char **kvs);
 _hidden int libxl__xs_write(libxl__gc *gc, xs_transaction_t t,
-                   char *path, const char *fmt, ...) PRINTF_ATTRIBUTE(4, 5);
+               const char *path, const char *fmt, ...) PRINTF_ATTRIBUTE(4, 5);
    /* Each fn returns 0 on success.
     * On error: returns -1, sets errno (no logging) */
 
 _hidden char *libxl__xs_get_dompath(libxl__gc *gc, uint32_t domid);
    /* On error: logs, returns NULL, sets errno. */
 
-_hidden char *libxl__xs_read(libxl__gc *gc, xs_transaction_t t, char *path);
+_hidden char *libxl__xs_read(libxl__gc *gc, xs_transaction_t t,
+                             const char *path);
 _hidden char **libxl__xs_directory(libxl__gc *gc, xs_transaction_t t,
-                                   char *path, unsigned int *nb);
+                                   const char *path, unsigned int *nb);
    /* On error: returns NULL, sets errno (no logging) */
 
 _hidden char *libxl__xs_libxl_path(libxl__gc *gc, uint32_t domid);
diff --git a/tools/libxl/libxl_xshelp.c b/tools/libxl/libxl_xshelp.c
index 4b09be3..bc4e7e4 100644
--- a/tools/libxl/libxl_xshelp.c
+++ b/tools/libxl/libxl_xshelp.c
@@ -49,7 +49,7 @@ char **libxl__xs_kvs_of_flexarray(libxl__gc *gc, flexarray_t *array, int length)
 }
 
 int libxl__xs_writev(libxl__gc *gc, xs_transaction_t t,
-                    char *dir, char *kvs[])
+                     const char *dir, char *kvs[])
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
     char *path;
@@ -69,7 +69,7 @@ int libxl__xs_writev(libxl__gc *gc, xs_transaction_t t,
 }
 
 int libxl__xs_write(libxl__gc *gc, xs_transaction_t t,
-                   char *path, const char *fmt, ...)
+                    const char *path, const char *fmt, ...)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
     char *s;
@@ -87,7 +87,7 @@ int libxl__xs_write(libxl__gc *gc, xs_transaction_t t,
     return 0;
 }
 
-char * libxl__xs_read(libxl__gc *gc, xs_transaction_t t, char *path)
+char * libxl__xs_read(libxl__gc *gc, xs_transaction_t t, const char *path)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
     char *ptr;
@@ -113,7 +113,8 @@ char *libxl__xs_get_dompath(libxl__gc *gc, uint32_t domid)
     return s;
 }
 
-char **libxl__xs_directory(libxl__gc *gc, xs_transaction_t t, char *path, unsigned int *nb)
+char **libxl__xs_directory(libxl__gc *gc, xs_transaction_t t,
+                           const char *path, unsigned int *nb)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
     char **ret = NULL;
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 18:11:31 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 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.xensource.com>)
	id 1RXd0W-00068S-2n; Mon, 05 Dec 2011 18:11:16 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RXd0T-00065t-1g
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 18:11:13 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1323108624!1307875!8
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjAyNg==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27239 invoked from network); 5 Dec 2011 18:10:27 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Dec 2011 18:10:27 -0000
X-IronPort-AV: E=Sophos;i="4.71,300,1320624000"; 
   d="scan'208";a="9297526"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Dec 2011 18:10:27 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 5 Dec 2011 18:10:27 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RXczj-0003kC-Gf; Mon, 05 Dec 2011 18:10:27 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RXczj-0006WH-Fo;
	Mon, 05 Dec 2011 18:10:27 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Mon, 5 Dec 2011 18:10:13 +0000
Message-ID: <1323108621-22654-8-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1323108621-22654-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1323108621-22654-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 07/15] libxl: internal convenience macros
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Provide some macros which are useful shorthands for use within libxl:
  * GC_INIT to initialise a gc from a ctx and GC_FREE to free it
  * CTX(gc) to give you back the ctx
  * LIBXL_TAILQ_INSERT_SORTED for inserting things into sorted lists

These will be used by later patches.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl_internal.h |   48 ++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 48 insertions(+), 0 deletions(-)

diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index bfc74c9..950c466 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -646,6 +646,54 @@ _hidden libxl__json_object *libxl__json_parse(libxl__gc *gc, const char *s);
 _hidden libxl_device_model_version
 libxl__device_model_version_running(libxl__gc *gc, uint32_t domid);
 
+
+/*
+ * Convenience macros.
+ */
+
+
+/*
+ * All of these assume (or define)
+ *    libxl__gc *gc;
+ * as a local variable.
+ */
+
+#define GC_INIT(ctx)  libxl__gc gc[1] = { LIBXL_INIT_GC(ctx) }
+#define GC_FREE       libxl__free_all(gc)
+#define CTX           libxl__gc_owner(gc)
+
+
+/*
+ * Inserts "elm_new" into the sorted list "head".
+ *
+ * "elm_search" must be a loop search variable of the same type as
+ * "elm_new".  "new_after_search_p" must be an expression which is
+ * true iff the element "elm_new" sorts after the element
+ * "elm_search".
+ *
+ * "search_body" can be empty, or some declaration(s) and statement(s)
+ * needed for "new_after_search_p".
+ */
+#define LIBXL_TAILQ_INSERT_SORTED(head, entry, elm_new, elm_search,     \
+                                  search_body, new_after_search_p)      \
+    do {                                                                \
+        for ((elm_search) = LIBXL_TAILQ_FIRST((head));                  \
+             (elm_search);                                              \
+             (elm_search) = LIBXL_TAILQ_NEXT((elm_search), entry)) {    \
+            search_body;                                                \
+            if (!(new_after_search_p))                                  \
+                break;                                                  \
+        }                                                               \
+        /* now elm_search is either the element before which we want    \
+         * to place elm_new, or NULL meaning we want to put elm_new at  \
+         * the end */                                                   \
+        if ((elm_search))                                               \
+            LIBXL_TAILQ_INSERT_BEFORE((elm_search), (elm_new), entry);  \
+        else                                                            \
+            LIBXL_TAILQ_INSERT_TAIL((head), (elm_new), entry);          \
+    } while(0)
+
+
 #endif
 
 /*
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 18:11:31 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 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.xensource.com>)
	id 1RXd0T-00066c-19; Mon, 05 Dec 2011 18:11:13 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RXd0R-00065o-DM
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 18:11:11 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1323108624!1307875!3
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjAyNg==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27113 invoked from network); 5 Dec 2011 18:10:26 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Dec 2011 18:10:26 -0000
X-IronPort-AV: E=Sophos;i="4.71,300,1320624000"; 
   d="scan'208";a="9297521"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Dec 2011 18:10:26 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 5 Dec 2011 18:10:26 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RXczh-0003jx-Ms; Mon, 05 Dec 2011 18:10:25 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RXczh-0006Vx-M0;
	Mon, 05 Dec 2011 18:10:25 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Mon, 5 Dec 2011 18:10:08 +0000
Message-ID: <1323108621-22654-3-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1323108621-22654-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1323108621-22654-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 02/15] libxenstore: Provide xs_check_watch
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Event-driven programs want to wait until the xs_fileno triggers for
reading, and then repeatedly call xs_check_watch.

Also xs_read_watch exposes a useless "num" out parameter, which should
always (if things aren't going hideously wrong) be at least 2 and
which the caller shouldn't be interested in.  So xs_check_watch
doesn't have one of those.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/xenstore/xs.c |   89 ++++++++++++++++++++++++++++++++++++++++++++-------
 tools/xenstore/xs.h |   16 +++++++++
 2 files changed, 93 insertions(+), 12 deletions(-)

diff --git a/tools/xenstore/xs.c b/tools/xenstore/xs.c
index df270f7..8e54fe0 100644
--- a/tools/xenstore/xs.c
+++ b/tools/xenstore/xs.c
@@ -132,7 +132,23 @@ struct xs_handle {
 
 #endif
 
-static int read_message(struct xs_handle *h);
+static int read_message(struct xs_handle *h, int nonblocking);
+
+static void setnonblock(int fd, int nonblock) {
+	int esave = errno;
+	int flags = fcntl(fd, F_GETFL);
+	if (flags == -1)
+		goto out;
+
+	if (nonblock)
+		flags |= O_NONBLOCK;
+	else
+		flags &= ~O_NONBLOCK;
+
+	fcntl(fd, F_SETFL, flags);
+out:
+	errno = esave;
+}
 
 int xs_fileno(struct xs_handle *h)
 {
@@ -325,8 +341,16 @@ void xs_close(struct xs_handle* xsh)
 		xs_daemon_close(xsh);
 }
 
-static bool read_all(int fd, void *data, unsigned int len)
+static bool read_all(int fd, void *data, unsigned int len, int nonblocking)
+	/* With nonblocking, either reads either everything requested,
+	 * or nothing. */
 {
+	if (!len)
+		return true;
+
+	if (nonblocking)
+		setnonblock(fd, 1);
+
 	while (len) {
 		int done;
 
@@ -334,18 +358,28 @@ static bool read_all(int fd, void *data, unsigned int len)
 		if (done < 0) {
 			if (errno == EINTR)
 				continue;
-			return false;
+			goto out_false;
 		}
 		if (done == 0) {
 			/* It closed fd on us?  EBADF is appropriate. */
 			errno = EBADF;
-			return false;
+			goto out_false;
 		}
 		data += done;
 		len -= done;
+
+		if (nonblocking) {
+			setnonblock(fd, 0);
+			nonblocking = 0;
+		}
 	}
 
 	return true;
+
+out_false:
+	if (nonblocking)
+		setnonblock(fd, 0);
+	return false;
 }
 
 #ifdef XSTEST
@@ -374,7 +408,7 @@ static void *read_reply(
 	read_from_thread = read_thread_exists(h);
 
 	/* Read from comms channel ourselves if there is no reader thread. */
-	if (!read_from_thread && (read_message(h) == -1))
+	if (!read_from_thread && (read_message(h, 0) == -1))
 		return NULL;
 
 	mutex_lock(&h->reply_mutex);
@@ -693,7 +727,8 @@ bool xs_watch(struct xs_handle *h, const char *path, const char *token)
  * Returns array of two pointers: path and token, or NULL.
  * Call free() after use.
  */
-char **xs_read_watch(struct xs_handle *h, unsigned int *num)
+static char **read_watch_internal(struct xs_handle *h, unsigned int *num,
+				  int nonblocking)
 {
 	struct xs_stored_msg *msg;
 	char **ret, *strings, c = 0;
@@ -707,14 +742,20 @@ char **xs_read_watch(struct xs_handle *h, unsigned int *num)
 	 * we haven't called xs_watch.	Presumably the application
 	 * will do so later; in the meantime we just block.
 	 */
-	while (list_empty(&h->watch_list) && h->fd != -1)
+	while (list_empty(&h->watch_list) && h->fd != -1) {
+		if (nonblocking) {
+			mutex_unlock(&h->watch_mutex);
+			errno = EAGAIN;
+			return 0;
+		}
 		condvar_wait(&h->watch_condvar, &h->watch_mutex);
+	}
 #else /* !defined(USE_PTHREAD) */
 	/* Read from comms channel ourselves if there are no threads
 	 * and therefore no reader thread. */
 
 	assert(!read_thread_exists(h)); /* not threadsafe but worth a check */
-	if ((read_message(h) == -1))
+	if ((read_message(h, nonblocking) == -1))
 		return NULL;
 
 #endif /* !defined(USE_PTHREAD) */
@@ -760,6 +801,24 @@ char **xs_read_watch(struct xs_handle *h, unsigned int *num)
 	return ret;
 }
 
+char **xs_check_watch(struct xs_handle *h)
+{
+	unsigned int num;
+	char **ret;
+	ret = read_watch_internal(h, &num, 1);
+	if (ret) assert(num >= 2);
+	return ret;
+}
+
+/* Find out what node change was on (will block if nothing pending).
+ * Returns array of two pointers: path and token, or NULL.
+ * Call free() after use.
+ */
+char **xs_read_watch(struct xs_handle *h, unsigned int *num)
+{
+	return read_watch_internal(h, num, 0);
+}
+
 /* Remove a watch on a node.
  * Returns false on failure (no watch on that node).
  */
@@ -940,11 +999,17 @@ char *xs_debug_command(struct xs_handle *h, const char *cmd,
 			ARRAY_SIZE(iov), NULL);
 }
 
-static int read_message(struct xs_handle *h)
+static int read_message(struct xs_handle *h, int nonblocking)
 {
 	/* IMPORTANT: It is forbidden to call this function without
 	 * acquiring the request lock and checking that h->read_thr_exists
 	 * is false.  See "Lock discipline" in struct xs_handle, above. */
+
+	/* If nonblocking==1, this function will always read either
+	 * nothing, returning -1 and setting errno==EAGAIN, or we read
+	 * whole amount requested.  Ie as soon as we have the start of
+	 * the message we block until we get all of it.
+	 */
          
 	struct xs_stored_msg *msg = NULL;
 	char *body = NULL;
@@ -956,7 +1021,7 @@ static int read_message(struct xs_handle *h)
 	if (msg == NULL)
 		goto error;
 	cleanup_push(free, msg);
-	if (!read_all(h->fd, &msg->hdr, sizeof(msg->hdr))) { /* Cancellation point */
+	if (!read_all(h->fd, &msg->hdr, sizeof(msg->hdr), nonblocking)) { /* Cancellation point */
 		saved_errno = errno;
 		goto error_freemsg;
 	}
@@ -966,7 +1031,7 @@ static int read_message(struct xs_handle *h)
 	if (body == NULL)
 		goto error_freemsg;
 	cleanup_push(free, body);
-	if (!read_all(h->fd, body, msg->hdr.len)) { /* Cancellation point */
+	if (!read_all(h->fd, body, msg->hdr.len, 0)) { /* Cancellation point */
 		saved_errno = errno;
 		goto error_freebody;
 	}
@@ -1021,7 +1086,7 @@ static void *read_thread(void *arg)
 	struct xs_handle *h = arg;
 	int fd;
 
-	while (read_message(h) != -1)
+	while (read_message(h, 0) != -1)
 		continue;
 
 	/* An error return from read_message leaves the socket in an undefined
diff --git a/tools/xenstore/xs.h b/tools/xenstore/xs.h
index 1cbe255..63f535d 100644
--- a/tools/xenstore/xs.h
+++ b/tools/xenstore/xs.h
@@ -135,6 +135,22 @@ bool xs_watch(struct xs_handle *h, const char *path, const char *token);
 /* Return the FD to poll on to see if a watch has fired. */
 int xs_fileno(struct xs_handle *h);
 
+/* Check for node changes.  On success, returns a non-NULL pointer ret
+ * such that ret[0] and ret[1] are valid C strings, namely the
+ * triggering path (see docs/misc/xenstore.txt) and the token (from
+ * xs_watch).  On error return value is NULL setting errno.
+ * 
+ * Callers should, after xs_fileno has become readable, repeatedly
+ * call xs_check_watch until it returns NULL and sets errno to EAGAIN.
+ * (If the fd became readable, xs_check_watch is allowed to make it no
+ * longer show up as readable even if future calls to xs_check_watch
+ * will return more watch events.)
+ *
+ * After the caller is finished with the returned information it
+ * should be freed all in one go with free(ret).
+ */
+char **xs_check_watch(struct xs_handle *h);
+
 /* Find out what node change was on (will block if nothing pending).
  * Returns array containing the path and token. Use XS_WATCH_* to access these
  * elements. Call free() after use.
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 18:11:31 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 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.xensource.com>)
	id 1RXd0T-000679-VA; Mon, 05 Dec 2011 18:11:13 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RXd0S-00065q-2y
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 18:11:12 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1323108624!1307875!6
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjAyNg==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27192 invoked from network); 5 Dec 2011 18:10:27 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Dec 2011 18:10:27 -0000
X-IronPort-AV: E=Sophos;i="4.71,300,1320624000"; 
   d="scan'208";a="9297524"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Dec 2011 18:10:27 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 5 Dec 2011 18:10:27 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RXczi-0003k6-Pd; Mon, 05 Dec 2011 18:10:26 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RXczi-0006W9-Oq;
	Mon, 05 Dec 2011 18:10:26 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Mon, 5 Dec 2011 18:10:11 +0000
Message-ID: <1323108621-22654-6-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1323108621-22654-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1323108621-22654-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 05/15] libxl: idl: Provide struct and union tags
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Instead of generating:

   typedef struct {
     ...
   } libxl_foo;

Produce:

   typedef struct libxl_foo {
     ...
   } libxl_foo;

This makes it possible to refer to libxl idl-generated structs and
unions, as incomplete types, before they have been defined.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/gentypes.py |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/tools/libxl/gentypes.py b/tools/libxl/gentypes.py
index d8f43e3..7ca6375 100644
--- a/tools/libxl/gentypes.py
+++ b/tools/libxl/gentypes.py
@@ -56,7 +56,7 @@ def libxl_C_type_define(ty, indent = ""):
         if ty.typename is None:
             s += "%s {\n" % ty.kind
         else:
-            s += "typedef %s {\n" % ty.kind
+            s += "typedef %s %s {\n" % (ty.kind, ty.typename)
 
         for f in ty.fields:
             if f.comment is not None:
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 18:11:31 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 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.xensource.com>)
	id 1RXd0X-00069f-K6; Mon, 05 Dec 2011 18:11:17 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RXd0U-00065z-4z
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 18:11:14 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1323108629!5440616!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjAyNg==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13993 invoked from network); 5 Dec 2011 18:10:29 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Dec 2011 18:10:29 -0000
X-IronPort-AV: E=Sophos;i="4.71,300,1320624000"; 
   d="scan'208";a="9297530"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Dec 2011 18:10:29 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 5 Dec 2011 18:10:29 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RXczk-0003kO-PA; Mon, 05 Dec 2011 18:10:28 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RXczk-0006WX-OK;
	Mon, 05 Dec 2011 18:10:28 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Mon, 5 Dec 2011 18:10:17 +0000
Message-ID: <1323108621-22654-12-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1323108621-22654-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1323108621-22654-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 11/15] libxl: make libxl__free_all idempotent
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl_internal.c |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c
index ae28cb0..a2e5820 100644
--- a/tools/libxl/libxl_internal.c
+++ b/tools/libxl/libxl_internal.c
@@ -72,6 +72,8 @@ void libxl__free_all(libxl__gc *gc)
         free(ptr);
     }
     free(gc->alloc_ptrs);
+    gc->alloc_ptrs = 0;
+    gc->alloc_maxsize = 0;
 }
 
 void *libxl__zalloc(libxl__gc *gc, int bytes)
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 18:11:31 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 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.xensource.com>)
	id 1RXd0U-00067S-Qm; Mon, 05 Dec 2011 18:11:14 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RXd0S-00065s-Cr
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 18:11:12 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1323108624!1307875!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjAyNg==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27100 invoked from network); 5 Dec 2011 18:10:25 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Dec 2011 18:10:25 -0000
X-IronPort-AV: E=Sophos;i="4.71,300,1320624000"; 
   d="scan'208";a="9297520"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Dec 2011 18:10:25 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 5 Dec 2011 18:10:25 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RXczh-0003ju-CG; Mon, 05 Dec 2011 18:10:25 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RXczh-0006Vt-BQ;
	Mon, 05 Dec 2011 18:10:25 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Mon, 5 Dec 2011 18:10:07 +0000
Message-ID: <1323108621-22654-2-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1323108621-22654-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1323108621-22654-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 01/15] libxl: Make libxl__xs_* more const-correct
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Paths and values which are not modified by these functions should be
declared as "const char *" not "char *".

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl_internal.h |    9 +++++----
 tools/libxl/libxl_xshelp.c   |    9 +++++----
 2 files changed, 10 insertions(+), 8 deletions(-)

diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 84da6b1..bfc74c9 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -172,18 +172,19 @@ _hidden char *libxl__dirname(libxl__gc *gc, const char *s);
 _hidden char **libxl__xs_kvs_of_flexarray(libxl__gc *gc, flexarray_t *array, int length);
 
 _hidden int libxl__xs_writev(libxl__gc *gc, xs_transaction_t t,
-                    char *dir, char **kvs);
+                             const char *dir, char **kvs);
 _hidden int libxl__xs_write(libxl__gc *gc, xs_transaction_t t,
-                   char *path, const char *fmt, ...) PRINTF_ATTRIBUTE(4, 5);
+               const char *path, const char *fmt, ...) PRINTF_ATTRIBUTE(4, 5);
    /* Each fn returns 0 on success.
     * On error: returns -1, sets errno (no logging) */
 
 _hidden char *libxl__xs_get_dompath(libxl__gc *gc, uint32_t domid);
    /* On error: logs, returns NULL, sets errno. */
 
-_hidden char *libxl__xs_read(libxl__gc *gc, xs_transaction_t t, char *path);
+_hidden char *libxl__xs_read(libxl__gc *gc, xs_transaction_t t,
+                             const char *path);
 _hidden char **libxl__xs_directory(libxl__gc *gc, xs_transaction_t t,
-                                   char *path, unsigned int *nb);
+                                   const char *path, unsigned int *nb);
    /* On error: returns NULL, sets errno (no logging) */
 
 _hidden char *libxl__xs_libxl_path(libxl__gc *gc, uint32_t domid);
diff --git a/tools/libxl/libxl_xshelp.c b/tools/libxl/libxl_xshelp.c
index 4b09be3..bc4e7e4 100644
--- a/tools/libxl/libxl_xshelp.c
+++ b/tools/libxl/libxl_xshelp.c
@@ -49,7 +49,7 @@ char **libxl__xs_kvs_of_flexarray(libxl__gc *gc, flexarray_t *array, int length)
 }
 
 int libxl__xs_writev(libxl__gc *gc, xs_transaction_t t,
-                    char *dir, char *kvs[])
+                     const char *dir, char *kvs[])
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
     char *path;
@@ -69,7 +69,7 @@ int libxl__xs_writev(libxl__gc *gc, xs_transaction_t t,
 }
 
 int libxl__xs_write(libxl__gc *gc, xs_transaction_t t,
-                   char *path, const char *fmt, ...)
+                    const char *path, const char *fmt, ...)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
     char *s;
@@ -87,7 +87,7 @@ int libxl__xs_write(libxl__gc *gc, xs_transaction_t t,
     return 0;
 }
 
-char * libxl__xs_read(libxl__gc *gc, xs_transaction_t t, char *path)
+char * libxl__xs_read(libxl__gc *gc, xs_transaction_t t, const char *path)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
     char *ptr;
@@ -113,7 +113,8 @@ char *libxl__xs_get_dompath(libxl__gc *gc, uint32_t domid)
     return s;
 }
 
-char **libxl__xs_directory(libxl__gc *gc, xs_transaction_t t, char *path, unsigned int *nb)
+char **libxl__xs_directory(libxl__gc *gc, xs_transaction_t t,
+                           const char *path, unsigned int *nb)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
     char **ret = NULL;
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 18:11:31 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 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.xensource.com>)
	id 1RXd0U-00067G-CX; Mon, 05 Dec 2011 18:11:14 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RXd0S-00065r-B6
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 18:11:12 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1323108624!1307875!7
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjAyNg==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27205 invoked from network); 5 Dec 2011 18:10:27 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Dec 2011 18:10:27 -0000
X-IronPort-AV: E=Sophos;i="4.71,300,1320624000"; 
   d="scan'208";a="9297525"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Dec 2011 18:10:27 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 5 Dec 2011 18:10:27 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RXczj-0003k9-50; Mon, 05 Dec 2011 18:10:27 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RXczj-0006WD-4C;
	Mon, 05 Dec 2011 18:10:27 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Mon, 5 Dec 2011 18:10:12 +0000
Message-ID: <1323108621-22654-7-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1323108621-22654-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1323108621-22654-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 06/15] libxl: permit declaration after statement
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

GCC and C99 allow declarations to be mixed with code.  This is a good
idea because:

 * It allows variables to be more often initialised as they are
   declared, thus reducing the occurrence of uninitialised variable
   errors.

 * Certain alloca-like constructs (arrays allocated at runtime on the
   stack) can more often be written without a spurious { } block.
   Such blocks are confusing to read.

 * It makes it easier to write and use macros which declare and
   initialise formulaic variables and do other function setup code,
   because there is no need to worry that such macros might be
   incompatible with each other or have strict ordering constraints.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/Makefile |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index f363da2..4e0f3fb 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -11,7 +11,8 @@ MINOR = 0
 XLUMAJOR = 1.0
 XLUMINOR = 0
 
-CFLAGS += -Werror -Wno-format-zero-length -Wmissing-declarations
+CFLAGS += -Werror -Wno-format-zero-length -Wmissing-declarations \
+	-Wno-declaration-after-statement
 CFLAGS += -I. -fPIC
 
 ifeq ($(CONFIG_Linux),y)
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 18:11:31 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 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.xensource.com>)
	id 1RXd0W-00068S-2n; Mon, 05 Dec 2011 18:11:16 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RXd0T-00065t-1g
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 18:11:13 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1323108624!1307875!8
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjAyNg==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27239 invoked from network); 5 Dec 2011 18:10:27 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Dec 2011 18:10:27 -0000
X-IronPort-AV: E=Sophos;i="4.71,300,1320624000"; 
   d="scan'208";a="9297526"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Dec 2011 18:10:27 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 5 Dec 2011 18:10:27 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RXczj-0003kC-Gf; Mon, 05 Dec 2011 18:10:27 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RXczj-0006WH-Fo;
	Mon, 05 Dec 2011 18:10:27 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Mon, 5 Dec 2011 18:10:13 +0000
Message-ID: <1323108621-22654-8-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1323108621-22654-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1323108621-22654-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 07/15] libxl: internal convenience macros
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Provide some macros which are useful shorthands for use within libxl:
  * GC_INIT to initialise a gc from a ctx and GC_FREE to free it
  * CTX(gc) to give you back the ctx
  * LIBXL_TAILQ_INSERT_SORTED for inserting things into sorted lists

These will be used by later patches.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl_internal.h |   48 ++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 48 insertions(+), 0 deletions(-)

diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index bfc74c9..950c466 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -646,6 +646,54 @@ _hidden libxl__json_object *libxl__json_parse(libxl__gc *gc, const char *s);
 _hidden libxl_device_model_version
 libxl__device_model_version_running(libxl__gc *gc, uint32_t domid);
 
+
+/*
+ * Convenience macros.
+ */
+
+
+/*
+ * All of these assume (or define)
+ *    libxl__gc *gc;
+ * as a local variable.
+ */
+
+#define GC_INIT(ctx)  libxl__gc gc[1] = { LIBXL_INIT_GC(ctx) }
+#define GC_FREE       libxl__free_all(gc)
+#define CTX           libxl__gc_owner(gc)
+
+
+/*
+ * Inserts "elm_new" into the sorted list "head".
+ *
+ * "elm_search" must be a loop search variable of the same type as
+ * "elm_new".  "new_after_search_p" must be an expression which is
+ * true iff the element "elm_new" sorts after the element
+ * "elm_search".
+ *
+ * "search_body" can be empty, or some declaration(s) and statement(s)
+ * needed for "new_after_search_p".
+ */
+#define LIBXL_TAILQ_INSERT_SORTED(head, entry, elm_new, elm_search,     \
+                                  search_body, new_after_search_p)      \
+    do {                                                                \
+        for ((elm_search) = LIBXL_TAILQ_FIRST((head));                  \
+             (elm_search);                                              \
+             (elm_search) = LIBXL_TAILQ_NEXT((elm_search), entry)) {    \
+            search_body;                                                \
+            if (!(new_after_search_p))                                  \
+                break;                                                  \
+        }                                                               \
+        /* now elm_search is either the element before which we want    \
+         * to place elm_new, or NULL meaning we want to put elm_new at  \
+         * the end */                                                   \
+        if ((elm_search))                                               \
+            LIBXL_TAILQ_INSERT_BEFORE((elm_search), (elm_new), entry);  \
+        else                                                            \
+            LIBXL_TAILQ_INSERT_TAIL((head), (elm_new), entry);          \
+    } while(0)
+
+
 #endif
 
 /*
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 18:11:31 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 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.xensource.com>)
	id 1RXd0T-000679-VA; Mon, 05 Dec 2011 18:11:13 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RXd0S-00065q-2y
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 18:11:12 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1323108624!1307875!6
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjAyNg==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27192 invoked from network); 5 Dec 2011 18:10:27 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Dec 2011 18:10:27 -0000
X-IronPort-AV: E=Sophos;i="4.71,300,1320624000"; 
   d="scan'208";a="9297524"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Dec 2011 18:10:27 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 5 Dec 2011 18:10:27 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RXczi-0003k6-Pd; Mon, 05 Dec 2011 18:10:26 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RXczi-0006W9-Oq;
	Mon, 05 Dec 2011 18:10:26 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Mon, 5 Dec 2011 18:10:11 +0000
Message-ID: <1323108621-22654-6-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1323108621-22654-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1323108621-22654-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 05/15] libxl: idl: Provide struct and union tags
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Instead of generating:

   typedef struct {
     ...
   } libxl_foo;

Produce:

   typedef struct libxl_foo {
     ...
   } libxl_foo;

This makes it possible to refer to libxl idl-generated structs and
unions, as incomplete types, before they have been defined.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/gentypes.py |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/tools/libxl/gentypes.py b/tools/libxl/gentypes.py
index d8f43e3..7ca6375 100644
--- a/tools/libxl/gentypes.py
+++ b/tools/libxl/gentypes.py
@@ -56,7 +56,7 @@ def libxl_C_type_define(ty, indent = ""):
         if ty.typename is None:
             s += "%s {\n" % ty.kind
         else:
-            s += "typedef %s {\n" % ty.kind
+            s += "typedef %s %s {\n" % (ty.kind, ty.typename)
 
         for f in ty.fields:
             if f.comment is not None:
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 18:11:31 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 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.xensource.com>)
	id 1RXd0W-000696-VE; Mon, 05 Dec 2011 18:11:16 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RXd0T-00065v-9J
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 18:11:13 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1323108624!1307875!9
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjAyNg==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27276 invoked from network); 5 Dec 2011 18:10:28 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Dec 2011 18:10:28 -0000
X-IronPort-AV: E=Sophos;i="4.71,300,1320624000"; 
   d="scan'208";a="9297527"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Dec 2011 18:10:28 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 5 Dec 2011 18:10:28 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RXczj-0003kF-Qg; Mon, 05 Dec 2011 18:10:27 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RXczj-0006WL-Ps;
	Mon, 05 Dec 2011 18:10:27 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Mon, 5 Dec 2011 18:10:14 +0000
Message-ID: <1323108621-22654-9-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1323108621-22654-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1323108621-22654-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 08/15] libxl: Rationalise #includes
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

libxl_internal.h now #includes libxl.h and various system headers.

This
 1. makes the order of header inclusion more predictable
 2. explicitly allows libxl_internal.h to use objects defined in libxl.h
 3. removes the need for individual files to include these headers

Also
 - remove some unnecessary #includes of libxl_utils.h,
   flexarray.h, etc. in some libxl*.c files,
 - include libxl_osdeps.h at the top of libxl_internal.h
 - add missing includes of libxl_osdeps.h to a couple of files
 - change libxl.h to libxl_internal.h in a couple of files

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl.c            |    3 ---
 tools/libxl/libxl_blktap2.c    |    1 -
 tools/libxl/libxl_bootloader.c |    4 ----
 tools/libxl/libxl_cpuid.c      |    4 ----
 tools/libxl/libxl_create.c     |    4 +---
 tools/libxl/libxl_device.c     |    1 -
 tools/libxl/libxl_dm.c         |    4 +---
 tools/libxl/libxl_dom.c        |    1 -
 tools/libxl/libxl_exec.c       |    1 -
 tools/libxl/libxl_flask.c      |    3 ++-
 tools/libxl/libxl_internal.c   |    4 ----
 tools/libxl/libxl_internal.h   |    5 +++++
 tools/libxl/libxl_json.c       |    3 ++-
 tools/libxl/libxl_noblktap2.c  |    2 --
 tools/libxl/libxl_nocpuid.c    |    2 +-
 tools/libxl/libxl_paths.c      |    2 +-
 tools/libxl/libxl_pci.c        |    5 -----
 tools/libxl/libxl_qmp.c        |    2 ++
 tools/libxl/libxl_utils.c      |    1 -
 tools/libxl/libxl_uuid.c       |    4 ++++
 tools/libxl/libxl_xshelp.c     |    1 -
 21 files changed, 19 insertions(+), 38 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index a171142..bc17b15 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -31,10 +31,7 @@
 #include <inttypes.h>
 #include <assert.h>
 
-#include "libxl.h"
-#include "libxl_utils.h"
 #include "libxl_internal.h"
-#include "flexarray.h"
 
 #define PAGE_TO_MEMKB(pages) ((pages) * 4)
 #define BACKEND_STRING_SIZE 5
diff --git a/tools/libxl/libxl_blktap2.c b/tools/libxl/libxl_blktap2.c
index c8d9148..acf4110 100644
--- a/tools/libxl/libxl_blktap2.c
+++ b/tools/libxl/libxl_blktap2.c
@@ -12,7 +12,6 @@
  * GNU Lesser General Public License for more details.
  */
 
-#include "libxl.h"
 #include "libxl_osdeps.h"
 #include "libxl_internal.h"
 
diff --git a/tools/libxl/libxl_bootloader.c b/tools/libxl/libxl_bootloader.c
index 47bb3a1..b8399a1 100644
--- a/tools/libxl/libxl_bootloader.c
+++ b/tools/libxl/libxl_bootloader.c
@@ -14,7 +14,6 @@
 
 #include "libxl_osdeps.h"
 
-#include <string.h>
 #include <unistd.h>
 #include <fcntl.h>
 #include <termios.h>
@@ -22,11 +21,8 @@
 #include <sys/stat.h>
 #include <sys/types.h>
 
-#include "libxl.h"
 #include "libxl_internal.h"
 
-#include "flexarray.h"
-
 #define XENCONSOLED_BUF_SIZE 16
 #define BOOTLOADER_BUF_SIZE 4096
 #define BOOTLOADER_TIMEOUT 1
diff --git a/tools/libxl/libxl_cpuid.c b/tools/libxl/libxl_cpuid.c
index 78bcab5..56a00cd 100644
--- a/tools/libxl/libxl_cpuid.c
+++ b/tools/libxl/libxl_cpuid.c
@@ -10,10 +10,6 @@
  * GNU Lesser General Public License for more details.
  */
 
-#include <string.h>
-
-#include "libxl.h"
-#include "libxl_osdeps.h"
 #include "libxl_internal.h"
 
 void libxl_cpuid_dispose(libxl_cpuid_policy_list *p_cpuid_list)
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index ce6a55e..ccb56c7 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -26,10 +26,8 @@
 #include <xc_dom.h>
 #include <xenguest.h>
 #include <assert.h>
-#include "libxl.h"
-#include "libxl_utils.h"
+
 #include "libxl_internal.h"
-#include "flexarray.h"
 
 void libxl_domain_config_dispose(libxl_domain_config *d_config)
 {
diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c
index a53fb70..46254ea 100644
--- a/tools/libxl/libxl_device.c
+++ b/tools/libxl/libxl_device.c
@@ -24,7 +24,6 @@
 #include <unistd.h>
 #include <fcntl.h>
 
-#include "libxl.h"
 #include "libxl_internal.h"
 
 char *libxl__device_frontend_path(libxl__gc *gc, libxl__device *device)
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index cef80be..05c83cd 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -24,10 +24,8 @@
 #include <unistd.h>
 #include <fcntl.h>
 #include <assert.h>
-#include "libxl_utils.h"
+
 #include "libxl_internal.h"
-#include "libxl.h"
-#include "flexarray.h"
 
 static const char *libxl_tapif_script(libxl__gc *gc)
 {
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index b74db34..96098de 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -32,7 +32,6 @@
 
 #include <xen/hvm/hvm_info_table.h>
 
-#include "libxl.h"
 #include "libxl_internal.h"
 
 libxl_domain_type libxl__domain_type(libxl__gc *gc, uint32_t domid)
diff --git a/tools/libxl/libxl_exec.c b/tools/libxl/libxl_exec.c
index 1a62d47..52d40d1 100644
--- a/tools/libxl/libxl_exec.c
+++ b/tools/libxl/libxl_exec.c
@@ -28,7 +28,6 @@
 #include <signal.h> /* for SIGKILL */
 #include <fcntl.h>
 
-#include "libxl.h"
 #include "libxl_internal.h"
 
 static int call_waitpid(pid_t (*waitpid_cb)(pid_t, int *, int), pid_t pid, int *status, int options)
diff --git a/tools/libxl/libxl_flask.c b/tools/libxl/libxl_flask.c
index c8d0594..6b548dd 100644
--- a/tools/libxl/libxl_flask.c
+++ b/tools/libxl/libxl_flask.c
@@ -7,13 +7,14 @@
  *  as published by the Free Software Foundation.
  */
 
+#include "libxl_osdeps.h"
+
 #include <stdio.h>
 #include <stdlib.h>
 #include <string.h>
 #include <errno.h>
 #include <xenctrl.h>
 
-#include "libxl.h"
 #include "libxl_internal.h"
 
 int libxl_flask_context_to_sid(libxl_ctx *ctx, char *buf, size_t len,
diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c
index 34edaf3..d767ce3 100644
--- a/tools/libxl/libxl_internal.c
+++ b/tools/libxl/libxl_internal.c
@@ -16,8 +16,6 @@
 #include "libxl_osdeps.h"
 
 #include <stdio.h>
-#include <stdarg.h>
-#include <string.h>
 
 #include <sys/types.h>
 #include <sys/stat.h>
@@ -25,9 +23,7 @@
 #include <sys/mman.h>
 #include <unistd.h>
 
-#include "libxl.h"
 #include "libxl_internal.h"
-#include "libxl_utils.h"
 
 int libxl__error_set(libxl__gc *gc, int code)
 {
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 950c466..cda6fc1 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -17,14 +17,19 @@
 #ifndef LIBXL_INTERNAL_H
 #define LIBXL_INTERNAL_H
 
+#include "libxl_osdeps.h"
+
 #include <stdint.h>
 #include <stdarg.h>
 #include <stdlib.h>
+#include <string.h>
 
 #include <xs.h>
 #include <xenctrl.h>
 #include "xentoollog.h"
 
+#include "libxl.h"
+
 #if __GNUC__ > 3 || (__GNUC__ == 3 && __GNUC_MINOR__ >= 1)
 #define _hidden __attribute__((visibility("hidden")))
 #define _protected __attribute__((visibility("protected")))
diff --git a/tools/libxl/libxl_json.c b/tools/libxl/libxl_json.c
index fd5e2aa..c0f869e 100644
--- a/tools/libxl/libxl_json.c
+++ b/tools/libxl/libxl_json.c
@@ -12,6 +12,8 @@
  * GNU Lesser General Public License for more details.
  */
 
+#include "libxl_osdeps.h"
+
 #include <assert.h>
 #include <string.h>
 #include <math.h>
@@ -19,7 +21,6 @@
 #include <yajl/yajl_parse.h>
 #include <yajl/yajl_gen.h>
 
-#include <libxl.h>
 #include "libxl_internal.h"
 
 /* #define DEBUG_ANSWER */
diff --git a/tools/libxl/libxl_noblktap2.c b/tools/libxl/libxl_noblktap2.c
index 704d03f..3307551 100644
--- a/tools/libxl/libxl_noblktap2.c
+++ b/tools/libxl/libxl_noblktap2.c
@@ -12,8 +12,6 @@
  * GNU Lesser General Public License for more details.
  */
 
-#include "libxl.h"
-#include "libxl_osdeps.h"
 #include "libxl_internal.h"
 
 int libxl__blktap_enabled(libxl__gc *gc)
diff --git a/tools/libxl/libxl_nocpuid.c b/tools/libxl/libxl_nocpuid.c
index d63757f..2e9490c 100644
--- a/tools/libxl/libxl_nocpuid.c
+++ b/tools/libxl/libxl_nocpuid.c
@@ -10,7 +10,7 @@
  * GNU Lesser General Public License for more details.
  */
 
-#include "libxl.h"
+#include "libxl_internal.h"
 
 void libxl_cpuid_destroy(libxl_cpuid_policy_list *p_cpuid_list)
 {
diff --git a/tools/libxl/libxl_paths.c b/tools/libxl/libxl_paths.c
index c84e51d..e7bd1a2 100644
--- a/tools/libxl/libxl_paths.c
+++ b/tools/libxl/libxl_paths.c
@@ -12,7 +12,7 @@
  * GNU Lesser General Public License for more details.
  */
 
-#include "libxl.h"
+#include "libxl_internal.h"
 #include "_libxl_paths.h"
 
 const char *libxl_sbindir_path(void)
diff --git a/tools/libxl/libxl_pci.c b/tools/libxl/libxl_pci.c
index 4186cf8..63c3050 100644
--- a/tools/libxl/libxl_pci.c
+++ b/tools/libxl/libxl_pci.c
@@ -17,7 +17,6 @@
 #include "libxl_osdeps.h"
 
 #include <stdio.h>
-#include <string.h>
 #include <stdlib.h>
 #include <sys/types.h>
 #include <fcntl.h>
@@ -27,15 +26,11 @@
 #include <sys/stat.h>
 #include <signal.h>
 #include <unistd.h> /* for write, unlink and close */
-#include <stdint.h>
 #include <inttypes.h>
 #include <dirent.h>
 #include <assert.h>
 
-#include "libxl.h"
-#include "libxl_utils.h"
 #include "libxl_internal.h"
-#include "flexarray.h"
 
 #define PCI_BDF                "%04x:%02x:%02x.%01x"
 #define PCI_BDF_SHORT          "%02x:%02x.%01x"
diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
index f749e01..c7696d7 100644
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/libxl/libxl_qmp.c
@@ -18,6 +18,8 @@
  * Specification, see in the QEMU repository.
  */
 
+#include "libxl_osdeps.h"
+
 #include <unistd.h>
 #include <sys/un.h>
 #include <sys/queue.h>
diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
index 1fa2c0f..f1f2a6d 100644
--- a/tools/libxl/libxl_utils.c
+++ b/tools/libxl/libxl_utils.c
@@ -28,7 +28,6 @@
 #include <unistd.h>
 #include <assert.h>
 
-#include "libxl_utils.h"
 #include "libxl_internal.h"
 
 struct schedid_name {
diff --git a/tools/libxl/libxl_uuid.c b/tools/libxl/libxl_uuid.c
index e837228..80ab789 100644
--- a/tools/libxl/libxl_uuid.c
+++ b/tools/libxl/libxl_uuid.c
@@ -12,8 +12,12 @@
  * GNU Lesser General Public License for more details.
  */
 
+#include "libxl_osdeps.h"
+
 #include <libxl_uuid.h>
 
+#include "libxl_internal.h"
+
 #if defined(__linux__)
 
 int libxl_uuid_is_nil(libxl_uuid *uuid)
diff --git a/tools/libxl/libxl_xshelp.c b/tools/libxl/libxl_xshelp.c
index bc4e7e4..ea835e2 100644
--- a/tools/libxl/libxl_xshelp.c
+++ b/tools/libxl/libxl_xshelp.c
@@ -21,7 +21,6 @@
 #include <stdarg.h>
 #include <inttypes.h>
 
-#include "libxl.h"
 #include "libxl_internal.h"
 
 char **libxl__xs_kvs_of_flexarray(libxl__gc *gc, flexarray_t *array, int length)
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 18:11:31 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 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.xensource.com>)
	id 1RXd0U-00067G-CX; Mon, 05 Dec 2011 18:11:14 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RXd0S-00065r-B6
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 18:11:12 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1323108624!1307875!7
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjAyNg==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27205 invoked from network); 5 Dec 2011 18:10:27 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Dec 2011 18:10:27 -0000
X-IronPort-AV: E=Sophos;i="4.71,300,1320624000"; 
   d="scan'208";a="9297525"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Dec 2011 18:10:27 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 5 Dec 2011 18:10:27 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RXczj-0003k9-50; Mon, 05 Dec 2011 18:10:27 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RXczj-0006WD-4C;
	Mon, 05 Dec 2011 18:10:27 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Mon, 5 Dec 2011 18:10:12 +0000
Message-ID: <1323108621-22654-7-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1323108621-22654-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1323108621-22654-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 06/15] libxl: permit declaration after statement
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

GCC and C99 allow declarations to be mixed with code.  This is a good
idea because:

 * It allows variables to be more often initialised as they are
   declared, thus reducing the occurrence of uninitialised variable
   errors.

 * Certain alloca-like constructs (arrays allocated at runtime on the
   stack) can more often be written without a spurious { } block.
   Such blocks are confusing to read.

 * It makes it easier to write and use macros which declare and
   initialise formulaic variables and do other function setup code,
   because there is no need to worry that such macros might be
   incompatible with each other or have strict ordering constraints.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/Makefile |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index f363da2..4e0f3fb 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -11,7 +11,8 @@ MINOR = 0
 XLUMAJOR = 1.0
 XLUMINOR = 0
 
-CFLAGS += -Werror -Wno-format-zero-length -Wmissing-declarations
+CFLAGS += -Werror -Wno-format-zero-length -Wmissing-declarations \
+	-Wno-declaration-after-statement
 CFLAGS += -I. -fPIC
 
 ifeq ($(CONFIG_Linux),y)
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 18:11:31 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 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.xensource.com>)
	id 1RXd0X-00069f-K6; Mon, 05 Dec 2011 18:11:17 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RXd0U-00065z-4z
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 18:11:14 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1323108629!5440616!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjAyNg==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13993 invoked from network); 5 Dec 2011 18:10:29 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Dec 2011 18:10:29 -0000
X-IronPort-AV: E=Sophos;i="4.71,300,1320624000"; 
   d="scan'208";a="9297530"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Dec 2011 18:10:29 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 5 Dec 2011 18:10:29 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RXczk-0003kO-PA; Mon, 05 Dec 2011 18:10:28 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RXczk-0006WX-OK;
	Mon, 05 Dec 2011 18:10:28 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Mon, 5 Dec 2011 18:10:17 +0000
Message-ID: <1323108621-22654-12-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1323108621-22654-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1323108621-22654-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 11/15] libxl: make libxl__free_all idempotent
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl_internal.c |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c
index ae28cb0..a2e5820 100644
--- a/tools/libxl/libxl_internal.c
+++ b/tools/libxl/libxl_internal.c
@@ -72,6 +72,8 @@ void libxl__free_all(libxl__gc *gc)
         free(ptr);
     }
     free(gc->alloc_ptrs);
+    gc->alloc_ptrs = 0;
+    gc->alloc_maxsize = 0;
 }
 
 void *libxl__zalloc(libxl__gc *gc, int bytes)
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 18:11:31 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 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.xensource.com>)
	id 1RXd0Z-0006B5-PZ; Mon, 05 Dec 2011 18:11:19 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RXd0V-000665-Ne
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 18:11:16 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1323108629!5440616!4
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjAyNg==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14087 invoked from network); 5 Dec 2011 18:10:30 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Dec 2011 18:10:30 -0000
X-IronPort-AV: E=Sophos;i="4.71,300,1320624000"; 
   d="scan'208";a="9297533"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Dec 2011 18:10:30 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 5 Dec 2011 18:10:30 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RXczl-0003kX-P6; Mon, 05 Dec 2011 18:10:29 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RXczl-0006Wj-O4;
	Mon, 05 Dec 2011 18:10:29 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Mon, 5 Dec 2011 18:10:20 +0000
Message-ID: <1323108621-22654-15-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1323108621-22654-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1323108621-22654-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 14/15] libxl: New API for providing OS events to
	libxl
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

We provide a new set of functions and related structures
  libxl_osevent_*
which are to be used by event-driven applications to receive
information from libxl about which fds libxl is interested in, and
what timeouts libxl is waiting for, and to pass back to libxl
information about which fds are readable/writeable etc., and which
timeouts have occurred.  Ie, low-level events.

In this patch, this new machinery is still all unused.  Callers will
appear in the next patch in the series, which introduces a new API for
applications to receive high-level events about actual domains etc.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/Makefile         |    2 +-
 tools/libxl/libxl.c          |   25 ++
 tools/libxl/libxl.h          |    6 +
 tools/libxl/libxl_event.c    |  711 ++++++++++++++++++++++++++++++++++++++++++
 tools/libxl/libxl_event.h    |  199 ++++++++++++
 tools/libxl/libxl_internal.h |  216 +++++++++++++-
 6 files changed, 1155 insertions(+), 4 deletions(-)
 create mode 100644 tools/libxl/libxl_event.c
 create mode 100644 tools/libxl/libxl_event.h

diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index 4e0f3fb..3d575b8 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -38,7 +38,7 @@ LIBXL_LIBS += -lyajl
 LIBXL_OBJS = flexarray.o libxl.o libxl_create.o libxl_dm.o libxl_pci.o \
 			libxl_dom.o libxl_exec.o libxl_xshelp.o libxl_device.o \
 			libxl_internal.o libxl_utils.o libxl_uuid.o libxl_json.o \
-			libxl_qmp.o $(LIBXL_OBJS-y)
+			libxl_qmp.o libxl_event.o $(LIBXL_OBJS-y)
 LIBXL_OBJS += _libxl_types.o libxl_flask.o _libxl_types_internal.o
 
 $(LIBXL_OBJS): CFLAGS += $(CFLAGS_libxenctrl) $(CFLAGS_libxenguest) $(CFLAGS_libxenstore) $(CFLAGS_libblktapctl)
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 3a8cfe3..58f280c 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -60,6 +60,16 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
      * only as an initialiser, not as an expression. */
     memcpy(&ctx->lock, &mutex_value, sizeof(ctx->lock));
 
+    ctx->osevent_hooks = 0;
+
+    ctx->fd_beforepolled = 0;
+    LIBXL_LIST_INIT(&ctx->efds);
+    LIBXL_TAILQ_INIT(&ctx->etimes);
+
+    ctx->watch_slots = 0;
+    LIBXL_SLIST_INIT(&ctx->watch_freeslots);
+    libxl__ev_fd_init(&ctx->watch_efd);
+
     if ( stat(XENSTORE_PID_FILE, &stat_buf) != 0 ) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "Is xenstore daemon running?\n"
                      "failed to stat %s", XENSTORE_PID_FILE);
@@ -89,10 +99,25 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
 
 int libxl_ctx_free(libxl_ctx *ctx)
 {
+    int i;
+    GC_INIT(ctx);
+
     if (!ctx) return 0;
+
+    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_LIST_EMPTY(&ctx->efds));
+    assert(LIBXL_TAILQ_EMPTY(&ctx->etimes));
+
     if (ctx->xch) xc_interface_close(ctx->xch);
     libxl_version_info_dispose(&ctx->version_info);
     if (ctx->xsh) xs_daemon_close(ctx->xsh);
+
+    free(ctx->fd_beforepolled);
+    free(ctx->watch_slots);
+
     return 0;
 }
 
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 289dc85..654a5b0 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -137,6 +137,7 @@
 #include <xen/sysctl.h>
 
 #include <libxl_uuid.h>
+#include <_libxl_list.h>
 
 typedef uint8_t libxl_mac[6];
 #define LIBXL_MAC_FMT "%02hhx:%02hhx:%02hhx:%02hhx:%02hhx:%02hhx"
@@ -222,6 +223,9 @@ enum {
     ERROR_BADFAIL = -7,
     ERROR_GUEST_TIMEDOUT = -8,
     ERROR_TIMEDOUT = -9,
+    ERROR_NOT_READY = -10,
+    ERROR_OSEVENT_REG_FAIL = -11,
+    ERROR_BUFFERFULL = -12,
 };
 
 #define LIBXL_VERSION 0
@@ -635,6 +639,8 @@ const char *libxl_lock_dir_path(void);
 const char *libxl_run_dir_path(void);
 const char *libxl_xenpaging_dir_path(void);
 
+#include <libxl_event.h>
+
 #endif /* LIBXL_H */
 
 /*
diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
new file mode 100644
index 0000000..8d4dbf6
--- /dev/null
+++ b/tools/libxl/libxl_event.c
@@ -0,0 +1,711 @@
+/*
+ * Copyright (C) 2011      Citrix Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU Lesser General Public License as published
+ * by the Free Software Foundation; version 2.1 only. with the special
+ * exception on linking described in file LICENSE.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU Lesser General Public License for more details.
+ */
+/*
+ * Internal event machinery for use by other parts of libxl
+ */
+
+#include <poll.h>
+
+#include "libxl_internal.h"
+
+/*
+ * The counter osevent_in_hook is used to ensure that the application
+ * honours the reentrancy restriction documented in libxl_event.h.
+ *
+ * The application's registration hooks should be called ONLY via
+ * these macros, with the ctx locked.  Likewise all the "occurred"
+ * entrypoints from the application should assert(!in_hook);
+ */
+#define OSEVENT_HOOK_INTERN(defval, hookname, ...)                      \
+    (CTX->osevent_hooks                                                 \
+     ? (CTX->osevent_in_hook++,                                         \
+        CTX->osevent_hooks->hookname(CTX->osevent_user, __VA_ARGS__),   \
+        CTX->osevent_in_hook--)                                         \
+     : defval)
+
+#define OSEVENT_HOOK(hookname,...)                      \
+    OSEVENT_HOOK_INTERN(0, hookname, __VA_ARGS__)
+
+#define OSEVENT_HOOK_VOID(hookname,...)                 \
+    OSEVENT_HOOK_INTERN((void)0, hookname, __VA_ARGS__)
+
+/*
+ * fd events
+ */
+
+int libxl__ev_fd_register(libxl__gc *gc, libxl__ev_fd *ev,
+                          libxl__ev_fd_callback *func,
+                          int fd, short events) {
+    int rc;
+
+    assert(fd >= 0);
+
+    CTX_LOCK;
+
+    rc = OSEVENT_HOOK(fd_register, fd, &ev->for_app_reg, events, ev);
+    if (rc) goto out;
+
+    LIBXL_LIST_INSERT_HEAD(&CTX->efds, ev, entry);
+
+    ev->fd = fd;
+    ev->events = events;
+    ev->in_beforepolled = -1;
+    ev->func = func;
+
+    rc = 0;
+
+ out:
+    CTX_UNLOCK;
+    return rc;
+}
+
+int libxl__ev_fd_modify(libxl__gc *gc, libxl__ev_fd *ev, short events) {
+    int rc;
+
+    CTX_LOCK;
+    assert(libxl__ev_fd_isregistered(ev));
+
+    rc = OSEVENT_HOOK(fd_modify, ev->fd, &ev->for_app_reg, events);
+    if (rc) goto out;
+
+    ev->events = events;
+
+    rc = 0;
+ out:
+    CTX_UNLOCK;
+    return rc;
+}
+
+void libxl__ev_fd_deregister(libxl__gc *gc, libxl__ev_fd *ev) {
+    CTX_LOCK;
+
+    if (!libxl__ev_fd_isregistered(ev))
+        goto out;
+
+    OSEVENT_HOOK_VOID(fd_deregister, ev->fd, ev->for_app_reg);
+    LIBXL_LIST_REMOVE(ev, entry);
+    ev->fd = -1;
+
+    if (ev->in_beforepolled >= 0 &&
+        ev->in_beforepolled < CTX->fd_beforepolled_used)
+        /* remove stale reference */
+        CTX->fd_beforepolled[ev->in_beforepolled] = NULL;
+
+ out:
+    CTX_UNLOCK;
+}
+
+/*
+ * timeouts
+ */
+
+
+int libxl__gettimeofday(libxl__gc *gc, struct timeval *now_r) {
+    int rc = gettimeofday(now_r, 0);
+    if (rc) {
+        LIBXL__LOG_ERRNO(CTX, LIBXL__LOG_ERROR, "gettimeofday failed");
+        return ERROR_FAIL;
+    }
+    return 0;
+}
+
+static int time_rel_to_abs(libxl__gc *gc, int ms, struct timeval *abs_out) {
+    int rc;
+    struct timeval additional = {
+        .tv_sec = ms / 1000,
+        .tv_usec = (ms % 1000) * 1000
+    };
+    struct timeval now;
+
+    rc = libxl__gettimeofday(gc, &now);
+    if (rc) return rc;
+
+    timeradd(&now, &additional, abs_out);
+    return 0;
+}
+
+static void time_insert_finite(libxl__gc *gc, libxl__ev_time *ev) {
+    libxl__ev_time *evsearch;
+    LIBXL_TAILQ_INSERT_SORTED(&CTX->etimes, entry, ev, evsearch, ,
+                              timercmp(&ev->abs, &evsearch->abs, >));
+    ev->infinite = 0;
+}
+
+static int time_register_finite(libxl__gc *gc, libxl__ev_time *ev,
+                                struct timeval abs) {
+    int rc;
+    
+    rc = OSEVENT_HOOK(timeout_register, &ev->for_app_reg, abs, ev);
+    if (rc) return rc;
+
+    ev->infinite = 0;
+    ev->abs = abs;
+    time_insert_finite(gc, ev);
+
+    return 0;
+}
+
+static void time_deregister(libxl__gc *gc, libxl__ev_time *ev) {
+    if (!ev->infinite) {
+        OSEVENT_HOOK_VOID(timeout_deregister, &ev->for_app_reg);
+        LIBXL_TAILQ_REMOVE(&CTX->etimes, ev, entry);
+    }
+}
+    
+
+int libxl__ev_time_register_abs(libxl__gc *gc, libxl__ev_time *ev,
+                                libxl__ev_time_callback *func,
+                                struct timeval abs) {
+    int rc;
+    
+    CTX_LOCK;
+
+    rc = time_register_finite(gc, ev, abs);
+    if (rc) goto out;
+
+    ev->func = func;
+
+    rc = 0;
+ out:
+    CTX_UNLOCK;
+    return rc;
+}
+
+
+int libxl__ev_time_register_rel(libxl__gc *gc, libxl__ev_time *ev,
+                                libxl__ev_time_callback *func,
+                                int milliseconds /* as for poll(2) */) {
+    struct timeval abs;
+    int rc;
+
+    CTX_LOCK;
+
+    if (milliseconds < 0) {
+        ev->infinite = 1;
+    } else {
+        rc = time_rel_to_abs(gc, milliseconds, &abs);
+        if (rc) goto out;
+
+        rc = time_register_finite(gc, ev, abs);
+        if (rc) goto out;
+    }
+
+    ev->func = func;
+    rc = 0;
+
+ out:
+    CTX_UNLOCK;
+    return 0;
+}
+
+int libxl__ev_time_modify_abs(libxl__gc *gc, libxl__ev_time *ev,
+                              struct timeval abs) {
+    int rc;
+
+    CTX_LOCK;
+
+    assert(libxl__ev_time_isregistered(ev));
+
+    if (ev->infinite) {
+        rc = time_register_finite(gc, ev, abs);
+        if (rc) goto out;
+    } else {
+        rc = OSEVENT_HOOK(timeout_modify, &ev->for_app_reg, abs);
+        if (rc) goto out;
+
+        LIBXL_TAILQ_REMOVE(&CTX->etimes, ev, entry);
+        ev->abs = abs;
+        time_insert_finite(gc, ev);
+    }
+
+    rc = 0;
+ out:
+    CTX_UNLOCK;
+    return rc;
+}
+
+int libxl__ev_time_modify_rel(libxl__gc *gc, libxl__ev_time *ev,
+                              int milliseconds) {
+    struct timeval abs;
+    int rc;
+
+    CTX_LOCK;
+
+    assert(libxl__ev_time_isregistered(ev));
+
+    if (milliseconds < 0) {
+        time_deregister(gc, ev);
+        ev->infinite = 1;
+        rc = 0;
+        goto out;
+    }
+
+    rc = time_rel_to_abs(gc, milliseconds, &abs);
+    if (rc) goto out;
+
+    rc = libxl__ev_time_modify_abs(gc, ev, abs);
+    if (rc) goto out;
+
+    rc = 0;
+ out:
+    CTX_UNLOCK;
+    return 0;
+}
+
+void libxl__ev_time_deregister(libxl__gc *gc, libxl__ev_time *ev) {
+    CTX_LOCK;
+
+    if (!libxl__ev_time_isregistered(ev))
+        goto out;
+        
+    time_deregister(gc, ev);
+    ev->func = 0;
+
+ out:
+    CTX_UNLOCK;
+    return;
+}
+
+
+/*
+ * xenstore watches
+ */
+
+libxl__ev_xswatch *libxl__watch_slot_contents(libxl__gc *gc, int slotnum) {
+    libxl__ev_watch_slot *slot = &CTX->watch_slots[slotnum];
+    libxl__ev_watch_slot *slotcontents = LIBXL_SLIST_NEXT(slot, empty);
+
+    if (slotcontents == NULL ||
+        ((uintptr_t)slotcontents >= (uintptr_t)CTX->watch_slots &&
+         (uintptr_t)slotcontents < (uintptr_t)(CTX->watch_slots +
+                                               CTX->watch_nslots)))
+        /* An empty slot has either a NULL pointer (end of the
+         * free list), or a pointer to another entry in the array.
+         * So we can do a bounds check to distinguish empty from
+         * full slots.
+         */
+        /* We need to do the comparisons as uintptr_t because
+         * comparing pointers which are not in the same object is
+         * undefined behaviour; if the compiler managed to figure
+         * out that watch_slots[0..watch_nslots-1] is all of the
+         * whole array object it could prove that the above bounds
+         * check was always true if it was legal, and remove it!
+         *
+         * uintptr_t because even on a machine with signed
+         * pointers, objects do not cross zero; whereas on
+         * machines with unsigned pointers, they may cross
+         * 0x8bazillion.
+         */
+        return NULL;
+
+        /* see comment near libxl__ev_watch_slot definition */
+    return (void*)slotcontents;
+}
+
+static void watchfd_callback(libxl__gc *gc, libxl__ev_fd *ev,
+                             int fd, short events, short revents) {
+    for (;;) {
+        char **event = xs_check_watch(CTX->xsh);
+        if (!event) {
+            if (errno == EAGAIN) break;
+            if (errno == EINTR) continue;
+            LIBXL__EVENT_DISASTER(gc, "cannot check/read watches", errno, 0);
+            return;
+        }
+
+        const char *epath = event[0];
+        const char *token = event[1];
+        int slotnum;
+        uint32_t counterval;
+        int rc = sscanf(token, "%d/%"SCNx32, &slotnum, &counterval);
+        if (rc != 2) {
+            LIBXL__LOG(CTX, LIBXL__LOG_ERROR,
+                       "watch epath=%s token=%s: failed to parse token",
+                       epath, token);
+            /* oh well */
+            goto ignore;
+        }
+        if (slotnum < 0 || slotnum >= CTX->watch_nslots) {
+            /* perhaps in the future we will make the watchslots array shrink */
+            LIBXL__LOG(CTX, LIBXL__LOG_DEBUG, "watch epath=%s token=%s:"
+                       " slotnum %d out of range [0,%d>",
+                       epath, token, slotnum, CTX->watch_nslots);
+            goto ignore;
+        }
+
+        libxl__ev_xswatch *w = libxl__watch_slot_contents(gc, slotnum);
+
+        if (!w) {
+            LIBXL__LOG(CTX, LIBXL__LOG_DEBUG,
+                       "watch epath=%s token=%s: empty slot",
+                       epath, token);
+            goto ignore;
+        }
+        
+        if (w->counterval != counterval) {
+            LIBXL__LOG(CTX, LIBXL__LOG_DEBUG,
+                       "watch epath=%s token=%s: counter != %"PRIx32,
+                       epath, token, w->counterval);
+            goto ignore;
+        }
+
+        /* Now it's possible, though unlikely, that this was an event
+         * from a previous use of the same slot with the same counterval.
+         *
+         * In that case either:
+         *  - the event path is a child of the watch path, in
+         *    which case this watch would really have generated this
+         *    event if it had been registered soon enough and we are
+         *    OK to give this possibly-spurious event to the caller; or
+         * - it is not, in which case we must suppress it as the
+         *   caller should not see events for unrelated paths.
+         *
+         * See also docs/misc/xenstore.txt.
+         */
+        size_t epathlen = strlen(epath);
+        size_t wpathlen = strlen(w->path);
+        if (epathlen < wpathlen ||
+            memcmp(epath, w->path, wpathlen) ||
+            (epathlen > wpathlen && epath[wpathlen] != '/')) {
+            LIBXL__LOG(CTX, LIBXL__LOG_DEBUG,
+                       "watch epath=%s token=%s: not child of wpath=%s",
+                       epath, token, w->path);
+            goto ignore;
+        }
+
+        /* At last, we have checked everything! */
+        LIBXL__LOG(CTX, LIBXL__LOG_DEBUG,
+                   "watch event: epath=%s token=%s wpath=%s w=%p",
+                   epath, token, w->path, w);
+        w->callback(gc, w, w->path, epath);
+
+    ignore:
+        free(event);
+    }
+}
+
+static char *watch_token(libxl__gc *gc, int slotnum, uint32_t counterval) {
+    return libxl__sprintf(gc, "%d/%"PRIx32, slotnum, counterval);
+}
+
+int libxl__ev_xswatch_register(libxl__gc *gc, libxl__ev_xswatch *w,
+                               libxl__ev_xswatch_callback *func,
+                               const char *path /* copied */) {
+    libxl__ev_watch_slot *use = NULL;
+    char *path_copy = NULL;
+    int rc;
+
+    CTX_LOCK;
+
+    if (!libxl__ev_fd_isregistered(&CTX->watch_efd)) {
+        rc = libxl__ev_fd_register(gc, &CTX->watch_efd, watchfd_callback,
+                                   xs_fileno(CTX->xsh), POLLIN);
+        if (rc) goto out_rc;
+    }
+
+    if (LIBXL_SLIST_EMPTY(&CTX->watch_freeslots)) {
+        /* Free list is empty so there is not in fact a linked
+         * free list in the array and we can safely realloc it */
+        int newarraysize = (CTX->watch_nslots + 1) << 2;
+        int i;
+        libxl__ev_watch_slot *newarray =
+            realloc(CTX->watch_slots, sizeof(*newarray) * newarraysize);
+        if (!newarray) goto out_nomem;
+        for (i=CTX->watch_nslots; i<newarraysize; i++)
+            LIBXL_SLIST_INSERT_HEAD(&CTX->watch_freeslots,
+                                    &newarray[i], empty);
+        CTX->watch_slots = newarray;
+        CTX->watch_nslots = newarraysize;
+    }
+    use = LIBXL_SLIST_FIRST(&CTX->watch_freeslots);
+    assert(use);
+    LIBXL_SLIST_REMOVE_HEAD(&CTX->watch_freeslots, empty);
+
+    path_copy = strdup(path);
+    if (!path_copy) goto out_nomem;
+
+    int slotnum = use - CTX->watch_slots;
+    w->counterval = CTX->watch_counter++;
+
+    if (!xs_watch(CTX->xsh, path, watch_token(gc, slotnum, w->counterval))) {
+        LIBXL__LOG_ERRNOVAL(CTX, LIBXL__LOG_ERROR, errno,
+                            "create watch for path %s", path);
+        rc = ERROR_FAIL;
+        goto out_rc;
+    }
+
+    w->slotnum = slotnum;
+    w->path = path_copy;
+    w->callback = func;
+    /* we look a bit behind the curtain of LIBXL_SLIST, to explictly
+     * assign to the pointer that's the next link.  See the comment
+     * by the definitionn of libxl__ev_watch_slot */
+    use->empty.sle_next = (void*)w;
+
+    CTX_UNLOCK;
+    return 0;
+
+ out_nomem:
+    rc = ERROR_NOMEM;
+ out_rc:
+    if (use)
+        LIBXL_SLIST_INSERT_HEAD(&CTX->watch_freeslots, use, empty);
+    if (path_copy)
+        free(path_copy);
+    CTX_UNLOCK;
+    return rc;
+}
+
+void libxl__ev_xswatch_deregister(libxl__gc *gc, libxl__ev_xswatch *w) {
+    /* it is legal to deregister from within _callback */
+    CTX_LOCK;
+
+    if (w->slotnum >= 0) {
+        char *token = watch_token(gc, w->slotnum, w->counterval);
+        if (!xs_unwatch(CTX->xsh, w->path, token))
+            /* Oh well, we will just get watch events forever more
+             * and ignore them.  But we should complain to the log. */
+            LIBXL__LOG_ERRNOVAL(CTX, LIBXL__LOG_ERROR, errno,
+                                "remove watch for path %s", w->path);
+
+        libxl__ev_watch_slot *slot = &CTX->watch_slots[w->slotnum];
+        LIBXL_SLIST_INSERT_HEAD(&CTX->watch_freeslots, slot, empty);
+    }
+
+    free(w->path);
+    w->path = NULL;
+
+    CTX_UNLOCK;
+}
+
+/*
+ * osevent poll
+ */
+
+int libxl_osevent_beforepoll(libxl_ctx *ctx, int *nfds_io,
+                             struct pollfd *fds, int *timeout_upd,
+                             struct timeval now) {
+    libxl__ev_fd *efd;
+    int i;
+
+    /*
+     * In order to be able to efficiently find the libxl__ev_fd
+     * for a struct poll during _afterpoll, we maintain a shadow
+     * data structure in CTX->fd_beforepolled: each slot in
+     * the fds array corresponds to a slot in fd_beforepolled.
+     */
+
+    GC_INIT(ctx);
+    CTX_LOCK;
+
+    if (*nfds_io) {
+        /*
+         * As an optimisation, we don't touch fd_beforepolled_used
+         * if *nfds_io is zero on entry, since in that case the
+         * caller just wanted to know how big an array to give us.
+         *
+         * If !*nfds_io, the unconditional parts below are guaranteed
+         * not to mess with fd_beforepolled... or any in_beforepolled.
+         */
+
+        /* Remove all the old references into beforepolled */
+        for (i = 0; i < CTX->fd_beforepolled_used; i++) {
+            efd = CTX->fd_beforepolled[i];
+            if (efd) {
+                assert(efd->in_beforepolled == i);
+                efd->in_beforepolled = -1;
+                CTX->fd_beforepolled[i] = NULL;
+            }
+        }
+        CTX->fd_beforepolled_used = 0;
+
+        /* make sure our array is as big as *nfds_io */
+        if (CTX->fd_beforepolled_allocd < *nfds_io) {
+            assert(*nfds_io < INT_MAX / sizeof(libxl__ev_fd*) / 2);
+            libxl__ev_fd **newarray =
+                realloc(CTX->fd_beforepolled, sizeof(*newarray) * *nfds_io);
+            if (!newarray)
+                return ERROR_NOMEM;
+            CTX->fd_beforepolled = newarray;
+            CTX->fd_beforepolled_allocd = *nfds_io;
+        }
+    }
+
+    int used = 0;
+    LIBXL_LIST_FOREACH(efd, &CTX->efds, entry) {
+        if (used < *nfds_io) {
+            fds[used].fd = efd->fd;
+            fds[used].events = efd->events;
+            fds[used].revents = 0;
+            CTX->fd_beforepolled[used] = efd;
+            efd->in_beforepolled = used;
+        }
+        used++;
+    }
+    int rc = used <= *nfds_io ? 0 : ERROR_BUFFERFULL;
+
+    if (*nfds_io) {
+        CTX->fd_beforepolled_used = used;
+    }
+
+    *nfds_io = used;
+
+    libxl__ev_time *etime = LIBXL_TAILQ_FIRST(&CTX->etimes);
+    if (etime) {
+        int our_timeout;
+        struct timeval rel;
+        static struct timeval zero;
+
+        timersub(&etime->abs, &now, &rel);
+
+        if (timercmp(&rel, &zero, <)) {
+            our_timeout = 0;
+        } else if (rel.tv_sec >= 2000000) {
+            our_timeout = 2000000000;
+        } else {
+            our_timeout = rel.tv_sec * 1000 + (rel.tv_usec + 999) / 1000;
+        }
+        if (*timeout_upd < 0 || our_timeout < *timeout_upd)
+            *timeout_upd = our_timeout;
+    }
+
+    CTX_UNLOCK;
+    GC_FREE;
+    return rc;
+}
+
+void libxl_osevent_afterpoll(libxl_ctx *ctx, int nfds, const struct pollfd *fds,
+                             struct timeval now) {
+    int i;
+    GC_INIT(ctx);
+    CTX_LOCK;
+
+    assert(nfds <= CTX->fd_beforepolled_used);
+
+    for (i = 0; i < nfds; i++) {
+        if (!fds[i].revents)
+            continue;
+
+        libxl__ev_fd *efd = CTX->fd_beforepolled[i];
+        if (!efd)
+            continue;
+
+        assert(efd->in_beforepolled == i);
+        assert(fds[i].fd == efd->fd);
+
+        int revents = fds[i].revents & efd->events;
+        if (!revents)
+            continue;
+
+        efd->func(gc, efd, efd->fd, efd->events, revents);
+    }
+
+    for (;;) {
+        libxl__ev_time *etime = LIBXL_TAILQ_FIRST(&CTX->etimes);
+        if (!etime)
+            break;
+
+        assert(!etime->infinite);
+
+        if (timercmp(&etime->abs, &now, >))
+            break;
+
+        time_deregister(gc, etime);
+
+        etime->func(gc, etime, &etime->abs);
+    }
+
+    CTX_UNLOCK;
+    GC_FREE;
+}
+
+
+/*
+ * osevent hook and callback machinery
+ */
+
+void libxl_osevent_register_hooks(libxl_ctx *ctx,
+                                  const libxl_osevent_hooks *hooks,
+                                  void *user) {
+    GC_INIT(ctx);
+    CTX_LOCK;
+    ctx->osevent_hooks = hooks;
+    ctx->osevent_user = user;
+    CTX_UNLOCK;
+    GC_FREE;
+}
+
+
+void libxl_osevent_occurred_fd(libxl_ctx *ctx, void *for_libxl,
+                               int fd, short events, short revents) {
+    libxl__ev_fd *ev = for_libxl;
+
+    GC_INIT(ctx);
+    CTX_LOCK;
+    assert(!CTX->osevent_in_hook);
+
+    assert(fd == ev->fd);
+    revents &= ev->events;
+    if (revents)
+        ev->func(gc, ev, fd, ev->events, revents);
+
+    CTX_UNLOCK;
+    GC_FREE;
+}
+
+void libxl_osevent_occurred_timeout(libxl_ctx *ctx, void *for_libxl) {
+    libxl__ev_time *ev = for_libxl;
+
+    GC_INIT(ctx);
+    CTX_LOCK;
+    assert(!CTX->osevent_in_hook);
+
+    assert(!ev->infinite);
+    LIBXL_TAILQ_REMOVE(&CTX->etimes, ev, entry);
+    ev->func(gc, ev, &ev->abs);
+
+    CTX_UNLOCK;
+    GC_FREE;
+}
+
+void libxl__event_disaster(libxl__gc *gc, const char *msg, int errnoval,
+                           libxl_event_type type /* may be 0 */,
+                           const char *file, int line, const char *func) {
+    libxl__log(CTX, XTL_CRITICAL, errnoval, file, line, func,
+               "DISASTER in event loop: %s%s%s%s",
+               msg,
+               type ? " (relates to event type " : "",
+               type ? libxl_event_type_to_string(type) : "",
+               type ? ")" : "");
+
+    /*
+     * FIXME: This should call the "disaster" hook supplied to
+     * libxl_event_register_callbacks, which will be introduced in the
+     * next patch.
+     */
+
+    const char verybad[] =
+        "DISASTER in event loop not handled by libxl application";
+    LIBXL__LOG(CTX, XTL_CRITICAL, verybad);
+    fprintf(stderr, "libxl: fatal error, exiting program: %s\n", verybad);
+    exit(-1);
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/tools/libxl/libxl_event.h b/tools/libxl/libxl_event.h
new file mode 100644
index 0000000..25efbdf
--- /dev/null
+++ b/tools/libxl/libxl_event.h
@@ -0,0 +1,199 @@
+/*
+ * Copyright (C) 2011      Citrix Ltd.
+ * Author Ian Jackson <ian.jackson@eu.citrix.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU Lesser General Public License as published
+ * by the Free Software Foundation; version 2.1 only. with the special
+ * exception on linking described in file LICENSE.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU Lesser General Public License for more details.
+ */
+
+#ifndef LIBXL_EVENT_H
+#define LIBXL_EVENT_H
+
+#include <libxl.h>
+
+
+/*======================================================================*/
+
+/*
+ * OS event handling - passing low-level OS events to libxl
+ *
+ * Event-driven programs must use these facilities to allow libxl
+ * to become aware of readability/writeability of file descriptors
+ * and the occurrence of timeouts.
+ *
+ * There are two approaches available.  The first is appropriate for
+ * simple programs handling reasonably small numbers of domains:
+ *
+ *   for (;;) {
+ *      libxl_osevent_beforepoll(...)
+ *      poll();
+ *      libxl_osevent_afterpoll(...);
+ *      for (;;) {
+ *        r=libxl_event_check(...);
+ *        if (r==LIBXL_NOT_READY) break;
+ *        if (r) handle failure;
+ *        do something with the event;
+ *      }
+ *   }
+ *
+ * The second approach uses libxl_osevent_register_hooks and is
+ * suitable for programs which are already using a callback-based
+ * event library.
+ *
+ * An application may freely mix the two styles of interaction.
+ */
+
+struct pollfd;
+
+int libxl_osevent_beforepoll(libxl_ctx *ctx, int *nfds_io,
+                             struct pollfd *fds, int *timeout_upd,
+                             struct timeval now);
+  /* The caller should provide beforepoll with some space for libxl's
+   * fds, and tell libxl how much space is available by setting *nfds_io.
+   * fds points to the start of this space (and fds may be a pointer into
+   * a larger array, for example, if the application has some fds of
+   * its own that it is interested in).
+   *
+   * On return *nfds_io will in any case have been updated by libxl
+   * according to how many fds libxl wants to poll on.
+   *
+   * If the space was sufficient, libxl fills in fds[0..<new
+   * *nfds_io>] suitably for poll(2), updates *timeout_upd if needed,
+   * and returns ok.
+   *
+   * If space was insufficient, fds[0..<old *nfds_io>] is undefined on
+   * return; *nfds_io on return will be greater than the value on
+   * entry; *timeout_upd may or may not have been updated; and
+   * libxl_osevent_beforepoll returns ERROR_BUFERFULL.  In this case
+   * the application needs to make more space (enough space for
+   * *nfds_io struct pollfd) and then call beforepoll again, before
+   * entering poll(2).  Typically this will involve calling realloc.
+   *
+   * The application may call beforepoll with fds==NULL and
+   * *nfds_io==0 in order to find out how much space is needed.
+   *
+   * *timeout_upd is as for poll(2): it's in milliseconds, and
+   * negative values mean no timeout (infinity).
+   * libxl_osevent_beforepoll will only reduce the timeout, naturally.
+   */
+void libxl_osevent_afterpoll(libxl_ctx *ctx, int nfds, const struct pollfd *fds,
+                             struct timeval now);
+  /* nfds and fds[0..nfds] must be from the most recent call to
+   * _beforepoll, as modified by poll.
+   *
+   * This function actually performs all of the IO and other actions,
+   * and generates events (libxl_event), which are implied by either
+   * (a) the time of day or (b) both (i) the returned information from
+   * _beforepoll, and (ii) the results from poll specified in
+   * fds[0..nfds-1].  Generated events can then be retrieved by
+   * libxl_event_check.
+   */
+
+
+typedef struct libxl_osevent_hooks {
+  int (*fd_register)(void *user, int fd, void **for_app_registration_out,
+                     short events, void *for_libxl);
+  int (*fd_modify)(void *user, int fd, void **for_app_registration_update,
+                   short events);
+  void (*fd_deregister)(void *user, int fd, void *for_app_registration);
+  int (*timeout_register)(void *user, void **for_app_registration_out,
+                          struct timeval abs, void *for_libxl);
+  int (*timeout_modify)(void *user, void **for_app_registration_update,
+                         struct timeval abs);
+  void (*timeout_deregister)(void *user, void *for_app_registration_io);
+} libxl_osevent_hooks;
+
+void libxl_osevent_register_hooks(libxl_ctx *ctx,
+                                  const libxl_osevent_hooks *hooks,
+                                  void *user);
+  /* The application which calls register_fd_hooks promises to
+   * maintain a register of fds and timeouts that libxl is interested
+   * in, and make calls into libxl (libxl_osevent_occurred_*)
+   * when those fd events and timeouts occur.  This is more efficient
+   * than _beforepoll/_afterpoll if there are many fds (which can
+   * happen if the same libxl application is managing many domains).
+   *
+   * For an fd event, events is as for poll().  register or modify may
+   * be called with events==0, in which case it must still work
+   * normally, just not generate any events.
+   *
+   * For a timeout event, milliseconds is as for poll().
+   * Specifically, negative values of milliseconds mean NO TIMEOUT.
+   * This is used by libxl to temporarily disable a timeout.
+   *
+   * If the register or modify hook succeeds it may update
+   * *for_app_registration_out/_update and must then return 0.
+   * On entry to register, *for_app_registration_out is always NULL.
+   *
+   * A registration or modification hook may fail, in which case it
+   * must leave the registration state of the fd or timeout unchanged.
+   * It may then either return ERROR_OSEVENT_REG_FAIL or any positive
+   * int.  The value returned will be passed up through libxl and
+   * eventually returned back to the application.  When register
+   * fails, any value stored into *for_registration_out is ignored by
+   * libxl; when modify fails, any changed value stored into
+   * *for_registration_update is honoured by libxl and will be passed
+   * to future modify or deregister calls.
+   *
+   * libxl will only attempt to register one callback for any one fd.
+   * libxl will remember the value stored in *for_app_registration_io
+   * by a successful call to register or modify and pass it into
+   * subsequent calls to modify or deregister.
+   *
+   * register_fd_hooks may be called only once for each libxl_ctx.
+   * libxl may make calls to register/modify/deregister from within
+   * any libxl function (indeed, it will usually call register from
+   * register_event_hooks).  Conversely, the application MUST NOT make
+   * the event occurrence calls (libxl_osevent_occurred_*) into libxl
+   * reentrantly from within libxl (for example, from within the
+   * register/modify functions).
+   *
+   * Lock hierarchy: the register/modify/deregister functions may be
+   * called with locks held.  These locks (the "libxl internal locks")
+   * are inside the libxl_ctx.  Therefore, if those register functions
+   * acquire any locks of their own ("caller register locks") outside
+   * libxl, to avoid deadlock one of the following must hold for each
+   * such caller register lock:
+   *  (a) "acquire libxl internal locks before caller register lock":
+   *      No libxl function may be called with the caller register
+   *      lock held.
+   *  (b) "acquire caller register lock before libxl internal locks":
+   *      No libxl function may be called _without_ the caller
+   *      register lock held.
+   * Of these we would normally recommend (a).
+   *
+   * The value *hooks is not copied and must outlast the libxl_ctx.
+   */
+
+/* It is NOT legal to call _occurred_ reentrantly within any libxl
+ * function.  Specifically it is NOT legal to call it from within
+ * a register callback.  Conversely, libxl MAY call register/deregister
+ * from within libxl_event_registered_call_*.
+ */
+
+void libxl_osevent_occurred_fd(libxl_ctx *ctx, void *for_libxl,
+                               int fd, short events, short revents);
+
+void libxl_osevent_occurred_timeout(libxl_ctx *ctx, void *for_libxl);
+  /* Implicitly, on entry to this function the timeout has been
+   * deregistered.  If _occurred_timeout is called, libxl will not
+   * call timeout_deregister; if it wants to requeue the timeout it
+   * will call timeout_register again.
+   */
+
+#endif
+
+/*
+ * Local variables:
+ * mode: C
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index d015c7c..88e7dbb 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -24,6 +24,9 @@
 #include <stdlib.h>
 #include <string.h>
 #include <pthread.h>
+#include <inttypes.h>
+#include <assert.h>
+#include <sys/poll.h>
 
 #include <xs.h>
 #include <xenctrl.h>
@@ -91,6 +94,66 @@ _hidden void libxl__log(libxl_ctx *ctx, xentoollog_level msglevel, int errnoval,
 
      /* these functions preserve errno (saving and restoring) */
 
+typedef struct libxl__gc libxl__gc;
+
+typedef struct libxl__ev_fd libxl__ev_fd;
+typedef void libxl__ev_fd_callback(libxl__gc *gc, libxl__ev_fd *ev,
+                                   int fd, short events, short revents);
+struct libxl__ev_fd {
+    /* all private for libxl__ev_fd... */
+    LIBXL_LIST_ENTRY(libxl__ev_fd) entry;
+    int fd;
+    short events;
+    int in_beforepolled; /* -1 means not in fd_beforepolled */
+    void *for_app_reg;
+    libxl__ev_fd_callback *func;
+};
+
+
+typedef struct libxl__ev_time libxl__ev_time;
+typedef void libxl__ev_time_callback(libxl__gc *gc, libxl__ev_time *ev,
+                                     const struct timeval *requested_abs);
+struct libxl__ev_time {
+    /* all private for libxl__ev_time... */
+    int infinite; /* not registered in list or with app if infinite */
+    LIBXL_TAILQ_ENTRY(libxl__ev_time) entry;
+    struct timeval abs;
+    void *for_app_reg;
+    libxl__ev_time_callback *func;
+};
+
+typedef struct libxl__ev_xswatch libxl__ev_xswatch;
+typedef void libxl__ev_xswatch_callback(libxl__gc *gc, libxl__ev_xswatch*,
+                            const char *watch_path, const char *event_path);
+struct libxl__ev_xswatch {
+    /* caller should include this in their own struct */
+    /* contents are private to xswatch_register */
+    int slotnum;
+    uint32_t counterval;
+    char *path;
+    libxl__ev_xswatch_callback *callback;
+};
+
+/*
+ * An entry in the watch_slots table is either:
+ *  1. an entry in the free list, ie NULL or pointer to next free list entry
+ *  2. an pointer to a libxl__ev_xswatch
+ *
+ * But we don't want to use unions or type-punning because the
+ * compiler might "prove" that our code is wrong and misoptimise it.
+ *
+ * The rules say that all struct pointers have identical
+ * representation and alignment requirements (C99+TC1+TC2 6.2.5p26) so
+ * what we do is simply declare our array as containing only the free
+ * list pointers, and explicitly convert from and to our actual
+ * xswatch pointers when we store and retrieve them.
+ */
+typedef struct libxl__ev_watch_slot {
+    LIBXL_SLIST_ENTRY(struct libxl__ev_watch_slot) empty;
+} libxl__ev_watch_slot;
+    
+libxl__ev_xswatch *libxl__watch_slot_contents(libxl__gc *gc, int slotnum);
+
 struct libxl__ctx {
     xentoollog_logger *lg;
     xc_interface *xch;
@@ -108,6 +171,23 @@ struct libxl__ctx {
        * documented in the libxl public interface.
        */
 
+    int osevent_in_hook;
+    const libxl_osevent_hooks *osevent_hooks;
+    void *osevent_user;
+      /* See the comment for OSEVENT_HOOK_INTERN in libxl_event.c
+       * for restrictions on the use of the osevent fields. */
+
+    int fd_beforepolled_allocd, fd_beforepolled_used;
+    libxl__ev_fd **fd_beforepolled; /* see libxl_osevent_beforepoll */
+    LIBXL_LIST_HEAD(, libxl__ev_fd) efds;
+    LIBXL_TAILQ_HEAD(, libxl__ev_time) etimes;
+
+    libxl__ev_watch_slot *watch_slots;
+    int watch_nslots;
+    LIBXL_SLIST_HEAD(, libxl__ev_watch_slot) watch_freeslots;
+    uint32_t watch_counter; /* helps disambiguate slot reuse */
+    libxl__ev_fd watch_efd;
+
     /* for callers who reap children willy-nilly; caller must only
      * set this after libxl_init and before any other call - or
      * may leave them untouched */
@@ -138,12 +218,12 @@ typedef struct {
 
 #define PRINTF_ATTRIBUTE(x, y) __attribute__((format(printf, x, y)))
 
-typedef struct {
+struct libxl__gc {
     /* mini-GC */
     int alloc_maxsize;
     void **alloc_ptrs;
     libxl_ctx *owner;
-} libxl__gc;
+};
 
 #define LIBXL_INIT_GC(gc,ctx) do{               \
         (gc).alloc_maxsize = 0;                 \
@@ -209,9 +289,137 @@ _hidden char *libxl__xs_read(libxl__gc *gc, xs_transaction_t t,
 _hidden char **libxl__xs_directory(libxl__gc *gc, xs_transaction_t t,
                                    const char *path, unsigned int *nb);
    /* On error: returns NULL, sets errno (no logging) */
-
 _hidden char *libxl__xs_libxl_path(libxl__gc *gc, uint32_t domid);
 
+
+/*
+ * Event generation functions provided by the libxl event core to the
+ * rest of libxl.  Implemented in terms of _beforepoll/_afterpoll
+ * and/or the fd registration machinery, as provided by the
+ * application.
+ *
+ * Semantics are similar to those of the fd and timeout registration
+ * functions provided to libxl_osevent_register_hooks.
+ *
+ * Non-0 returns from libxl__ev_{modify,deregister} have already been
+ * logged by the core and should be returned unmodified to libxl's
+ * caller; NB that they may be valid libxl error codes but they may
+ * also be positive numbers supplied by the caller.
+ *
+ * In each case, there is a libxl__ev_FOO structure which can be in
+ * one of three states:
+ *
+ *   Undefined   - Might contain anything.  All-bits-zero is
+ *                 an undefined state.
+ *
+ *   Idle        - Struct contents are defined enough to pass to any
+ *                 libxl__ev_FOO function but not registered and
+ *                 callback will not be called.  The struct does not
+ *                 contain references to any allocated resources so
+ *                 can be thrown away.
+ *
+ *   Active      - Request for events has been registered and events
+ *                 may be generated.  _deregister must be called to
+ *                 reclaim resources.
+ *
+ * These functions are provided for each kind of event KIND:
+ *
+ *   int libxl__ev_KIND_register(libxl__gc *gc, libxl__ev_KIND *GEN,
+ *                              libxl__ev_KIND_callback *FUNC,
+ *                              DETAILS);
+ *      On entry *GEN must be in state Undefined or Idle.
+ *      Returns a libxl error code; on error return *GEN is Idle.
+ *      On successful return *GEN is Active and FUNC wil be
+ *      called by the event machinery in future.  FUNC will
+ *      not be called from within the call to _register.
+ *
+ *  void libxl__ev_KIND_deregister(libxl__gc *gc, libxl__ev_KIND *GEN_upd);
+ *      On entry *GEN must be in state Active or Idle.
+ *      On return it is Idle.  (Idempotent.)
+ *
+ *  void libxl__ev_KIND_init(libxl__ev_KIND *GEN);
+ *      Provided for initialising an Undefined KIND.
+ *      On entry *GEN must be in state Idle or Undefined.
+ *      On return it is Idle.  (Idempotent.)
+ *
+ *  int libxl__ev_KIND_isregistered(const libxl__ev_KIND *GEN);
+ *      On entry *GEN must be Idle or Active.
+ *      Returns nonzero if it is Active, zero otherwise.
+ *      Cannot fail.
+ *
+ *  int libxl__ev_KiND_modify(libxl__gc*, libxl__ev_KIND *GEN,
+ *                            DETAILS);
+ *      Only provided for some kinds of generator.
+ *      On entry *GEN must be Active and on return, whether successful
+ *      or not, it will be Active.
+ *      Returns a libxl error code; on error the modification
+ *      is not effective.
+ *
+ * All of these functions are fully threadsafe and may be called by
+ * general code in libxl even from within event callback FUNCs.
+ */
+
+
+_hidden int libxl__ev_fd_register(libxl__gc*, libxl__ev_fd *ev_out,
+                                  libxl__ev_fd_callback*,
+                                  int fd, short events /* as for poll(2) */);
+_hidden int libxl__ev_fd_modify(libxl__gc*, libxl__ev_fd *ev,
+                                short events);
+_hidden void libxl__ev_fd_deregister(libxl__gc*, libxl__ev_fd *ev);
+static inline void libxl__ev_fd_init(libxl__ev_fd *efd)
+                    { efd->fd = -1; }
+static inline int libxl__ev_fd_isregistered(libxl__ev_fd *efd)
+                    { return efd->fd >= 0; }
+
+_hidden int libxl__ev_time_register_rel(libxl__gc*, libxl__ev_time *ev_out,
+                                        libxl__ev_time_callback*,
+                                        int milliseconds /* as for poll(2) */);
+_hidden int libxl__ev_time_register_abs(libxl__gc*, libxl__ev_time *ev_out,
+                                        libxl__ev_time_callback*,
+                                        struct timeval);
+_hidden int libxl__ev_time_modify_rel(libxl__gc*, libxl__ev_time *ev,
+                                      int milliseconds /* as for poll(2) */);
+_hidden int libxl__ev_time_modify_abs(libxl__gc*, libxl__ev_time *ev,
+                                      struct timeval);
+_hidden void libxl__ev_time_deregister(libxl__gc*, libxl__ev_time *ev);
+static inline void libxl__ev_time_init(libxl__ev_time *ev)
+                { ev->func = 0; }
+static inline int libxl__ev_time_isregistered(libxl__ev_time *ev)
+                { return !!ev->func; }
+
+
+_hidden int libxl__ev_xswatch_register(libxl__gc*, libxl__ev_xswatch *xsw_out,
+                                       libxl__ev_xswatch_callback*,
+                                       const char *path /* copied */);
+_hidden void libxl__ev_xswatch_deregister(libxl__gc *gc, libxl__ev_xswatch*);
+
+static inline void libxl__ev_xswatch_init(libxl__ev_xswatch *xswatch_out)
+                { xswatch_out->slotnum = -1; }
+static inline int libxl__ev_xswatch_isregistered(const libxl__ev_xswatch *xw)
+                { return xw->slotnum >= 0; }
+
+
+
+_hidden void libxl__event_disaster(libxl__gc*, const char *msg, int errnoval,
+                                   libxl_event_type type /* may be 0 */,
+                                   const char *file, int line,
+                                   const char *func);
+  /*
+   * In general, call this via the macro LIBXL__EVENT_DISASTER.
+   *
+   * Event-generating functions may call this if they might have
+   * wanted to generate an event (either an internal one ie a
+   * libxl__ev_FOO_callback or an application event), but are
+   * prevented from doing so due to eg lack of memory.
+   *
+   * NB that this function may return and the caller isn't supposed to
+   * then crash, although it may fail (and henceforth leave things in
+   * a state where many or all calls fail).
+   */
+#define LIBXL__EVENT_DISASTER(gc, msg, errnoval, type) \
+    libxl__event_disaster(gc, msg, errnoval, type, __FILE__, __LINE__, __func__)
+
+
 /* from xl_dom */
 _hidden libxl_domain_type libxl__domain_type(libxl__gc *gc, uint32_t domid);
 _hidden int libxl__domain_shutdown_reason(libxl__gc *gc, uint32_t domid);
@@ -536,6 +744,8 @@ _hidden int libxl__parse_mac(const char *s, libxl_mac mac);
 /* compare mac address @a and @b. 0 if the same, -ve if a<b and +ve if a>b */
 _hidden int libxl__compare_macs(libxl_mac *a, libxl_mac *b);
 
+_hidden int libxl__gettimeofday(libxl__gc *gc, struct timeval *now_r);
+
 #define STRINGIFY(x) #x
 #define TOSTRING(x) STRINGIFY(x)
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 18:11:31 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 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.xensource.com>)
	id 1RXd0W-000696-VE; Mon, 05 Dec 2011 18:11:16 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RXd0T-00065v-9J
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 18:11:13 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1323108624!1307875!9
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjAyNg==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27276 invoked from network); 5 Dec 2011 18:10:28 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Dec 2011 18:10:28 -0000
X-IronPort-AV: E=Sophos;i="4.71,300,1320624000"; 
   d="scan'208";a="9297527"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Dec 2011 18:10:28 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 5 Dec 2011 18:10:28 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RXczj-0003kF-Qg; Mon, 05 Dec 2011 18:10:27 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RXczj-0006WL-Ps;
	Mon, 05 Dec 2011 18:10:27 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Mon, 5 Dec 2011 18:10:14 +0000
Message-ID: <1323108621-22654-9-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1323108621-22654-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1323108621-22654-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 08/15] libxl: Rationalise #includes
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

libxl_internal.h now #includes libxl.h and various system headers.

This
 1. makes the order of header inclusion more predictable
 2. explicitly allows libxl_internal.h to use objects defined in libxl.h
 3. removes the need for individual files to include these headers

Also
 - remove some unnecessary #includes of libxl_utils.h,
   flexarray.h, etc. in some libxl*.c files,
 - include libxl_osdeps.h at the top of libxl_internal.h
 - add missing includes of libxl_osdeps.h to a couple of files
 - change libxl.h to libxl_internal.h in a couple of files

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl.c            |    3 ---
 tools/libxl/libxl_blktap2.c    |    1 -
 tools/libxl/libxl_bootloader.c |    4 ----
 tools/libxl/libxl_cpuid.c      |    4 ----
 tools/libxl/libxl_create.c     |    4 +---
 tools/libxl/libxl_device.c     |    1 -
 tools/libxl/libxl_dm.c         |    4 +---
 tools/libxl/libxl_dom.c        |    1 -
 tools/libxl/libxl_exec.c       |    1 -
 tools/libxl/libxl_flask.c      |    3 ++-
 tools/libxl/libxl_internal.c   |    4 ----
 tools/libxl/libxl_internal.h   |    5 +++++
 tools/libxl/libxl_json.c       |    3 ++-
 tools/libxl/libxl_noblktap2.c  |    2 --
 tools/libxl/libxl_nocpuid.c    |    2 +-
 tools/libxl/libxl_paths.c      |    2 +-
 tools/libxl/libxl_pci.c        |    5 -----
 tools/libxl/libxl_qmp.c        |    2 ++
 tools/libxl/libxl_utils.c      |    1 -
 tools/libxl/libxl_uuid.c       |    4 ++++
 tools/libxl/libxl_xshelp.c     |    1 -
 21 files changed, 19 insertions(+), 38 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index a171142..bc17b15 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -31,10 +31,7 @@
 #include <inttypes.h>
 #include <assert.h>
 
-#include "libxl.h"
-#include "libxl_utils.h"
 #include "libxl_internal.h"
-#include "flexarray.h"
 
 #define PAGE_TO_MEMKB(pages) ((pages) * 4)
 #define BACKEND_STRING_SIZE 5
diff --git a/tools/libxl/libxl_blktap2.c b/tools/libxl/libxl_blktap2.c
index c8d9148..acf4110 100644
--- a/tools/libxl/libxl_blktap2.c
+++ b/tools/libxl/libxl_blktap2.c
@@ -12,7 +12,6 @@
  * GNU Lesser General Public License for more details.
  */
 
-#include "libxl.h"
 #include "libxl_osdeps.h"
 #include "libxl_internal.h"
 
diff --git a/tools/libxl/libxl_bootloader.c b/tools/libxl/libxl_bootloader.c
index 47bb3a1..b8399a1 100644
--- a/tools/libxl/libxl_bootloader.c
+++ b/tools/libxl/libxl_bootloader.c
@@ -14,7 +14,6 @@
 
 #include "libxl_osdeps.h"
 
-#include <string.h>
 #include <unistd.h>
 #include <fcntl.h>
 #include <termios.h>
@@ -22,11 +21,8 @@
 #include <sys/stat.h>
 #include <sys/types.h>
 
-#include "libxl.h"
 #include "libxl_internal.h"
 
-#include "flexarray.h"
-
 #define XENCONSOLED_BUF_SIZE 16
 #define BOOTLOADER_BUF_SIZE 4096
 #define BOOTLOADER_TIMEOUT 1
diff --git a/tools/libxl/libxl_cpuid.c b/tools/libxl/libxl_cpuid.c
index 78bcab5..56a00cd 100644
--- a/tools/libxl/libxl_cpuid.c
+++ b/tools/libxl/libxl_cpuid.c
@@ -10,10 +10,6 @@
  * GNU Lesser General Public License for more details.
  */
 
-#include <string.h>
-
-#include "libxl.h"
-#include "libxl_osdeps.h"
 #include "libxl_internal.h"
 
 void libxl_cpuid_dispose(libxl_cpuid_policy_list *p_cpuid_list)
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index ce6a55e..ccb56c7 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -26,10 +26,8 @@
 #include <xc_dom.h>
 #include <xenguest.h>
 #include <assert.h>
-#include "libxl.h"
-#include "libxl_utils.h"
+
 #include "libxl_internal.h"
-#include "flexarray.h"
 
 void libxl_domain_config_dispose(libxl_domain_config *d_config)
 {
diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c
index a53fb70..46254ea 100644
--- a/tools/libxl/libxl_device.c
+++ b/tools/libxl/libxl_device.c
@@ -24,7 +24,6 @@
 #include <unistd.h>
 #include <fcntl.h>
 
-#include "libxl.h"
 #include "libxl_internal.h"
 
 char *libxl__device_frontend_path(libxl__gc *gc, libxl__device *device)
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index cef80be..05c83cd 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -24,10 +24,8 @@
 #include <unistd.h>
 #include <fcntl.h>
 #include <assert.h>
-#include "libxl_utils.h"
+
 #include "libxl_internal.h"
-#include "libxl.h"
-#include "flexarray.h"
 
 static const char *libxl_tapif_script(libxl__gc *gc)
 {
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index b74db34..96098de 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -32,7 +32,6 @@
 
 #include <xen/hvm/hvm_info_table.h>
 
-#include "libxl.h"
 #include "libxl_internal.h"
 
 libxl_domain_type libxl__domain_type(libxl__gc *gc, uint32_t domid)
diff --git a/tools/libxl/libxl_exec.c b/tools/libxl/libxl_exec.c
index 1a62d47..52d40d1 100644
--- a/tools/libxl/libxl_exec.c
+++ b/tools/libxl/libxl_exec.c
@@ -28,7 +28,6 @@
 #include <signal.h> /* for SIGKILL */
 #include <fcntl.h>
 
-#include "libxl.h"
 #include "libxl_internal.h"
 
 static int call_waitpid(pid_t (*waitpid_cb)(pid_t, int *, int), pid_t pid, int *status, int options)
diff --git a/tools/libxl/libxl_flask.c b/tools/libxl/libxl_flask.c
index c8d0594..6b548dd 100644
--- a/tools/libxl/libxl_flask.c
+++ b/tools/libxl/libxl_flask.c
@@ -7,13 +7,14 @@
  *  as published by the Free Software Foundation.
  */
 
+#include "libxl_osdeps.h"
+
 #include <stdio.h>
 #include <stdlib.h>
 #include <string.h>
 #include <errno.h>
 #include <xenctrl.h>
 
-#include "libxl.h"
 #include "libxl_internal.h"
 
 int libxl_flask_context_to_sid(libxl_ctx *ctx, char *buf, size_t len,
diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c
index 34edaf3..d767ce3 100644
--- a/tools/libxl/libxl_internal.c
+++ b/tools/libxl/libxl_internal.c
@@ -16,8 +16,6 @@
 #include "libxl_osdeps.h"
 
 #include <stdio.h>
-#include <stdarg.h>
-#include <string.h>
 
 #include <sys/types.h>
 #include <sys/stat.h>
@@ -25,9 +23,7 @@
 #include <sys/mman.h>
 #include <unistd.h>
 
-#include "libxl.h"
 #include "libxl_internal.h"
-#include "libxl_utils.h"
 
 int libxl__error_set(libxl__gc *gc, int code)
 {
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 950c466..cda6fc1 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -17,14 +17,19 @@
 #ifndef LIBXL_INTERNAL_H
 #define LIBXL_INTERNAL_H
 
+#include "libxl_osdeps.h"
+
 #include <stdint.h>
 #include <stdarg.h>
 #include <stdlib.h>
+#include <string.h>
 
 #include <xs.h>
 #include <xenctrl.h>
 #include "xentoollog.h"
 
+#include "libxl.h"
+
 #if __GNUC__ > 3 || (__GNUC__ == 3 && __GNUC_MINOR__ >= 1)
 #define _hidden __attribute__((visibility("hidden")))
 #define _protected __attribute__((visibility("protected")))
diff --git a/tools/libxl/libxl_json.c b/tools/libxl/libxl_json.c
index fd5e2aa..c0f869e 100644
--- a/tools/libxl/libxl_json.c
+++ b/tools/libxl/libxl_json.c
@@ -12,6 +12,8 @@
  * GNU Lesser General Public License for more details.
  */
 
+#include "libxl_osdeps.h"
+
 #include <assert.h>
 #include <string.h>
 #include <math.h>
@@ -19,7 +21,6 @@
 #include <yajl/yajl_parse.h>
 #include <yajl/yajl_gen.h>
 
-#include <libxl.h>
 #include "libxl_internal.h"
 
 /* #define DEBUG_ANSWER */
diff --git a/tools/libxl/libxl_noblktap2.c b/tools/libxl/libxl_noblktap2.c
index 704d03f..3307551 100644
--- a/tools/libxl/libxl_noblktap2.c
+++ b/tools/libxl/libxl_noblktap2.c
@@ -12,8 +12,6 @@
  * GNU Lesser General Public License for more details.
  */
 
-#include "libxl.h"
-#include "libxl_osdeps.h"
 #include "libxl_internal.h"
 
 int libxl__blktap_enabled(libxl__gc *gc)
diff --git a/tools/libxl/libxl_nocpuid.c b/tools/libxl/libxl_nocpuid.c
index d63757f..2e9490c 100644
--- a/tools/libxl/libxl_nocpuid.c
+++ b/tools/libxl/libxl_nocpuid.c
@@ -10,7 +10,7 @@
  * GNU Lesser General Public License for more details.
  */
 
-#include "libxl.h"
+#include "libxl_internal.h"
 
 void libxl_cpuid_destroy(libxl_cpuid_policy_list *p_cpuid_list)
 {
diff --git a/tools/libxl/libxl_paths.c b/tools/libxl/libxl_paths.c
index c84e51d..e7bd1a2 100644
--- a/tools/libxl/libxl_paths.c
+++ b/tools/libxl/libxl_paths.c
@@ -12,7 +12,7 @@
  * GNU Lesser General Public License for more details.
  */
 
-#include "libxl.h"
+#include "libxl_internal.h"
 #include "_libxl_paths.h"
 
 const char *libxl_sbindir_path(void)
diff --git a/tools/libxl/libxl_pci.c b/tools/libxl/libxl_pci.c
index 4186cf8..63c3050 100644
--- a/tools/libxl/libxl_pci.c
+++ b/tools/libxl/libxl_pci.c
@@ -17,7 +17,6 @@
 #include "libxl_osdeps.h"
 
 #include <stdio.h>
-#include <string.h>
 #include <stdlib.h>
 #include <sys/types.h>
 #include <fcntl.h>
@@ -27,15 +26,11 @@
 #include <sys/stat.h>
 #include <signal.h>
 #include <unistd.h> /* for write, unlink and close */
-#include <stdint.h>
 #include <inttypes.h>
 #include <dirent.h>
 #include <assert.h>
 
-#include "libxl.h"
-#include "libxl_utils.h"
 #include "libxl_internal.h"
-#include "flexarray.h"
 
 #define PCI_BDF                "%04x:%02x:%02x.%01x"
 #define PCI_BDF_SHORT          "%02x:%02x.%01x"
diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
index f749e01..c7696d7 100644
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/libxl/libxl_qmp.c
@@ -18,6 +18,8 @@
  * Specification, see in the QEMU repository.
  */
 
+#include "libxl_osdeps.h"
+
 #include <unistd.h>
 #include <sys/un.h>
 #include <sys/queue.h>
diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
index 1fa2c0f..f1f2a6d 100644
--- a/tools/libxl/libxl_utils.c
+++ b/tools/libxl/libxl_utils.c
@@ -28,7 +28,6 @@
 #include <unistd.h>
 #include <assert.h>
 
-#include "libxl_utils.h"
 #include "libxl_internal.h"
 
 struct schedid_name {
diff --git a/tools/libxl/libxl_uuid.c b/tools/libxl/libxl_uuid.c
index e837228..80ab789 100644
--- a/tools/libxl/libxl_uuid.c
+++ b/tools/libxl/libxl_uuid.c
@@ -12,8 +12,12 @@
  * GNU Lesser General Public License for more details.
  */
 
+#include "libxl_osdeps.h"
+
 #include <libxl_uuid.h>
 
+#include "libxl_internal.h"
+
 #if defined(__linux__)
 
 int libxl_uuid_is_nil(libxl_uuid *uuid)
diff --git a/tools/libxl/libxl_xshelp.c b/tools/libxl/libxl_xshelp.c
index bc4e7e4..ea835e2 100644
--- a/tools/libxl/libxl_xshelp.c
+++ b/tools/libxl/libxl_xshelp.c
@@ -21,7 +21,6 @@
 #include <stdarg.h>
 #include <inttypes.h>
 
-#include "libxl.h"
 #include "libxl_internal.h"
 
 char **libxl__xs_kvs_of_flexarray(libxl__gc *gc, flexarray_t *array, int length)
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 18:11:31 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 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.xensource.com>)
	id 1RXd0Z-0006B5-PZ; Mon, 05 Dec 2011 18:11:19 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RXd0V-000665-Ne
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 18:11:16 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1323108629!5440616!4
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjAyNg==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14087 invoked from network); 5 Dec 2011 18:10:30 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Dec 2011 18:10:30 -0000
X-IronPort-AV: E=Sophos;i="4.71,300,1320624000"; 
   d="scan'208";a="9297533"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Dec 2011 18:10:30 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 5 Dec 2011 18:10:30 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RXczl-0003kX-P6; Mon, 05 Dec 2011 18:10:29 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RXczl-0006Wj-O4;
	Mon, 05 Dec 2011 18:10:29 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Mon, 5 Dec 2011 18:10:20 +0000
Message-ID: <1323108621-22654-15-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1323108621-22654-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1323108621-22654-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 14/15] libxl: New API for providing OS events to
	libxl
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

We provide a new set of functions and related structures
  libxl_osevent_*
which are to be used by event-driven applications to receive
information from libxl about which fds libxl is interested in, and
what timeouts libxl is waiting for, and to pass back to libxl
information about which fds are readable/writeable etc., and which
timeouts have occurred.  Ie, low-level events.

In this patch, this new machinery is still all unused.  Callers will
appear in the next patch in the series, which introduces a new API for
applications to receive high-level events about actual domains etc.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/Makefile         |    2 +-
 tools/libxl/libxl.c          |   25 ++
 tools/libxl/libxl.h          |    6 +
 tools/libxl/libxl_event.c    |  711 ++++++++++++++++++++++++++++++++++++++++++
 tools/libxl/libxl_event.h    |  199 ++++++++++++
 tools/libxl/libxl_internal.h |  216 +++++++++++++-
 6 files changed, 1155 insertions(+), 4 deletions(-)
 create mode 100644 tools/libxl/libxl_event.c
 create mode 100644 tools/libxl/libxl_event.h

diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index 4e0f3fb..3d575b8 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -38,7 +38,7 @@ LIBXL_LIBS += -lyajl
 LIBXL_OBJS = flexarray.o libxl.o libxl_create.o libxl_dm.o libxl_pci.o \
 			libxl_dom.o libxl_exec.o libxl_xshelp.o libxl_device.o \
 			libxl_internal.o libxl_utils.o libxl_uuid.o libxl_json.o \
-			libxl_qmp.o $(LIBXL_OBJS-y)
+			libxl_qmp.o libxl_event.o $(LIBXL_OBJS-y)
 LIBXL_OBJS += _libxl_types.o libxl_flask.o _libxl_types_internal.o
 
 $(LIBXL_OBJS): CFLAGS += $(CFLAGS_libxenctrl) $(CFLAGS_libxenguest) $(CFLAGS_libxenstore) $(CFLAGS_libblktapctl)
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 3a8cfe3..58f280c 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -60,6 +60,16 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
      * only as an initialiser, not as an expression. */
     memcpy(&ctx->lock, &mutex_value, sizeof(ctx->lock));
 
+    ctx->osevent_hooks = 0;
+
+    ctx->fd_beforepolled = 0;
+    LIBXL_LIST_INIT(&ctx->efds);
+    LIBXL_TAILQ_INIT(&ctx->etimes);
+
+    ctx->watch_slots = 0;
+    LIBXL_SLIST_INIT(&ctx->watch_freeslots);
+    libxl__ev_fd_init(&ctx->watch_efd);
+
     if ( stat(XENSTORE_PID_FILE, &stat_buf) != 0 ) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "Is xenstore daemon running?\n"
                      "failed to stat %s", XENSTORE_PID_FILE);
@@ -89,10 +99,25 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
 
 int libxl_ctx_free(libxl_ctx *ctx)
 {
+    int i;
+    GC_INIT(ctx);
+
     if (!ctx) return 0;
+
+    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_LIST_EMPTY(&ctx->efds));
+    assert(LIBXL_TAILQ_EMPTY(&ctx->etimes));
+
     if (ctx->xch) xc_interface_close(ctx->xch);
     libxl_version_info_dispose(&ctx->version_info);
     if (ctx->xsh) xs_daemon_close(ctx->xsh);
+
+    free(ctx->fd_beforepolled);
+    free(ctx->watch_slots);
+
     return 0;
 }
 
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 289dc85..654a5b0 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -137,6 +137,7 @@
 #include <xen/sysctl.h>
 
 #include <libxl_uuid.h>
+#include <_libxl_list.h>
 
 typedef uint8_t libxl_mac[6];
 #define LIBXL_MAC_FMT "%02hhx:%02hhx:%02hhx:%02hhx:%02hhx:%02hhx"
@@ -222,6 +223,9 @@ enum {
     ERROR_BADFAIL = -7,
     ERROR_GUEST_TIMEDOUT = -8,
     ERROR_TIMEDOUT = -9,
+    ERROR_NOT_READY = -10,
+    ERROR_OSEVENT_REG_FAIL = -11,
+    ERROR_BUFFERFULL = -12,
 };
 
 #define LIBXL_VERSION 0
@@ -635,6 +639,8 @@ const char *libxl_lock_dir_path(void);
 const char *libxl_run_dir_path(void);
 const char *libxl_xenpaging_dir_path(void);
 
+#include <libxl_event.h>
+
 #endif /* LIBXL_H */
 
 /*
diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
new file mode 100644
index 0000000..8d4dbf6
--- /dev/null
+++ b/tools/libxl/libxl_event.c
@@ -0,0 +1,711 @@
+/*
+ * Copyright (C) 2011      Citrix Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU Lesser General Public License as published
+ * by the Free Software Foundation; version 2.1 only. with the special
+ * exception on linking described in file LICENSE.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU Lesser General Public License for more details.
+ */
+/*
+ * Internal event machinery for use by other parts of libxl
+ */
+
+#include <poll.h>
+
+#include "libxl_internal.h"
+
+/*
+ * The counter osevent_in_hook is used to ensure that the application
+ * honours the reentrancy restriction documented in libxl_event.h.
+ *
+ * The application's registration hooks should be called ONLY via
+ * these macros, with the ctx locked.  Likewise all the "occurred"
+ * entrypoints from the application should assert(!in_hook);
+ */
+#define OSEVENT_HOOK_INTERN(defval, hookname, ...)                      \
+    (CTX->osevent_hooks                                                 \
+     ? (CTX->osevent_in_hook++,                                         \
+        CTX->osevent_hooks->hookname(CTX->osevent_user, __VA_ARGS__),   \
+        CTX->osevent_in_hook--)                                         \
+     : defval)
+
+#define OSEVENT_HOOK(hookname,...)                      \
+    OSEVENT_HOOK_INTERN(0, hookname, __VA_ARGS__)
+
+#define OSEVENT_HOOK_VOID(hookname,...)                 \
+    OSEVENT_HOOK_INTERN((void)0, hookname, __VA_ARGS__)
+
+/*
+ * fd events
+ */
+
+int libxl__ev_fd_register(libxl__gc *gc, libxl__ev_fd *ev,
+                          libxl__ev_fd_callback *func,
+                          int fd, short events) {
+    int rc;
+
+    assert(fd >= 0);
+
+    CTX_LOCK;
+
+    rc = OSEVENT_HOOK(fd_register, fd, &ev->for_app_reg, events, ev);
+    if (rc) goto out;
+
+    LIBXL_LIST_INSERT_HEAD(&CTX->efds, ev, entry);
+
+    ev->fd = fd;
+    ev->events = events;
+    ev->in_beforepolled = -1;
+    ev->func = func;
+
+    rc = 0;
+
+ out:
+    CTX_UNLOCK;
+    return rc;
+}
+
+int libxl__ev_fd_modify(libxl__gc *gc, libxl__ev_fd *ev, short events) {
+    int rc;
+
+    CTX_LOCK;
+    assert(libxl__ev_fd_isregistered(ev));
+
+    rc = OSEVENT_HOOK(fd_modify, ev->fd, &ev->for_app_reg, events);
+    if (rc) goto out;
+
+    ev->events = events;
+
+    rc = 0;
+ out:
+    CTX_UNLOCK;
+    return rc;
+}
+
+void libxl__ev_fd_deregister(libxl__gc *gc, libxl__ev_fd *ev) {
+    CTX_LOCK;
+
+    if (!libxl__ev_fd_isregistered(ev))
+        goto out;
+
+    OSEVENT_HOOK_VOID(fd_deregister, ev->fd, ev->for_app_reg);
+    LIBXL_LIST_REMOVE(ev, entry);
+    ev->fd = -1;
+
+    if (ev->in_beforepolled >= 0 &&
+        ev->in_beforepolled < CTX->fd_beforepolled_used)
+        /* remove stale reference */
+        CTX->fd_beforepolled[ev->in_beforepolled] = NULL;
+
+ out:
+    CTX_UNLOCK;
+}
+
+/*
+ * timeouts
+ */
+
+
+int libxl__gettimeofday(libxl__gc *gc, struct timeval *now_r) {
+    int rc = gettimeofday(now_r, 0);
+    if (rc) {
+        LIBXL__LOG_ERRNO(CTX, LIBXL__LOG_ERROR, "gettimeofday failed");
+        return ERROR_FAIL;
+    }
+    return 0;
+}
+
+static int time_rel_to_abs(libxl__gc *gc, int ms, struct timeval *abs_out) {
+    int rc;
+    struct timeval additional = {
+        .tv_sec = ms / 1000,
+        .tv_usec = (ms % 1000) * 1000
+    };
+    struct timeval now;
+
+    rc = libxl__gettimeofday(gc, &now);
+    if (rc) return rc;
+
+    timeradd(&now, &additional, abs_out);
+    return 0;
+}
+
+static void time_insert_finite(libxl__gc *gc, libxl__ev_time *ev) {
+    libxl__ev_time *evsearch;
+    LIBXL_TAILQ_INSERT_SORTED(&CTX->etimes, entry, ev, evsearch, ,
+                              timercmp(&ev->abs, &evsearch->abs, >));
+    ev->infinite = 0;
+}
+
+static int time_register_finite(libxl__gc *gc, libxl__ev_time *ev,
+                                struct timeval abs) {
+    int rc;
+    
+    rc = OSEVENT_HOOK(timeout_register, &ev->for_app_reg, abs, ev);
+    if (rc) return rc;
+
+    ev->infinite = 0;
+    ev->abs = abs;
+    time_insert_finite(gc, ev);
+
+    return 0;
+}
+
+static void time_deregister(libxl__gc *gc, libxl__ev_time *ev) {
+    if (!ev->infinite) {
+        OSEVENT_HOOK_VOID(timeout_deregister, &ev->for_app_reg);
+        LIBXL_TAILQ_REMOVE(&CTX->etimes, ev, entry);
+    }
+}
+    
+
+int libxl__ev_time_register_abs(libxl__gc *gc, libxl__ev_time *ev,
+                                libxl__ev_time_callback *func,
+                                struct timeval abs) {
+    int rc;
+    
+    CTX_LOCK;
+
+    rc = time_register_finite(gc, ev, abs);
+    if (rc) goto out;
+
+    ev->func = func;
+
+    rc = 0;
+ out:
+    CTX_UNLOCK;
+    return rc;
+}
+
+
+int libxl__ev_time_register_rel(libxl__gc *gc, libxl__ev_time *ev,
+                                libxl__ev_time_callback *func,
+                                int milliseconds /* as for poll(2) */) {
+    struct timeval abs;
+    int rc;
+
+    CTX_LOCK;
+
+    if (milliseconds < 0) {
+        ev->infinite = 1;
+    } else {
+        rc = time_rel_to_abs(gc, milliseconds, &abs);
+        if (rc) goto out;
+
+        rc = time_register_finite(gc, ev, abs);
+        if (rc) goto out;
+    }
+
+    ev->func = func;
+    rc = 0;
+
+ out:
+    CTX_UNLOCK;
+    return 0;
+}
+
+int libxl__ev_time_modify_abs(libxl__gc *gc, libxl__ev_time *ev,
+                              struct timeval abs) {
+    int rc;
+
+    CTX_LOCK;
+
+    assert(libxl__ev_time_isregistered(ev));
+
+    if (ev->infinite) {
+        rc = time_register_finite(gc, ev, abs);
+        if (rc) goto out;
+    } else {
+        rc = OSEVENT_HOOK(timeout_modify, &ev->for_app_reg, abs);
+        if (rc) goto out;
+
+        LIBXL_TAILQ_REMOVE(&CTX->etimes, ev, entry);
+        ev->abs = abs;
+        time_insert_finite(gc, ev);
+    }
+
+    rc = 0;
+ out:
+    CTX_UNLOCK;
+    return rc;
+}
+
+int libxl__ev_time_modify_rel(libxl__gc *gc, libxl__ev_time *ev,
+                              int milliseconds) {
+    struct timeval abs;
+    int rc;
+
+    CTX_LOCK;
+
+    assert(libxl__ev_time_isregistered(ev));
+
+    if (milliseconds < 0) {
+        time_deregister(gc, ev);
+        ev->infinite = 1;
+        rc = 0;
+        goto out;
+    }
+
+    rc = time_rel_to_abs(gc, milliseconds, &abs);
+    if (rc) goto out;
+
+    rc = libxl__ev_time_modify_abs(gc, ev, abs);
+    if (rc) goto out;
+
+    rc = 0;
+ out:
+    CTX_UNLOCK;
+    return 0;
+}
+
+void libxl__ev_time_deregister(libxl__gc *gc, libxl__ev_time *ev) {
+    CTX_LOCK;
+
+    if (!libxl__ev_time_isregistered(ev))
+        goto out;
+        
+    time_deregister(gc, ev);
+    ev->func = 0;
+
+ out:
+    CTX_UNLOCK;
+    return;
+}
+
+
+/*
+ * xenstore watches
+ */
+
+libxl__ev_xswatch *libxl__watch_slot_contents(libxl__gc *gc, int slotnum) {
+    libxl__ev_watch_slot *slot = &CTX->watch_slots[slotnum];
+    libxl__ev_watch_slot *slotcontents = LIBXL_SLIST_NEXT(slot, empty);
+
+    if (slotcontents == NULL ||
+        ((uintptr_t)slotcontents >= (uintptr_t)CTX->watch_slots &&
+         (uintptr_t)slotcontents < (uintptr_t)(CTX->watch_slots +
+                                               CTX->watch_nslots)))
+        /* An empty slot has either a NULL pointer (end of the
+         * free list), or a pointer to another entry in the array.
+         * So we can do a bounds check to distinguish empty from
+         * full slots.
+         */
+        /* We need to do the comparisons as uintptr_t because
+         * comparing pointers which are not in the same object is
+         * undefined behaviour; if the compiler managed to figure
+         * out that watch_slots[0..watch_nslots-1] is all of the
+         * whole array object it could prove that the above bounds
+         * check was always true if it was legal, and remove it!
+         *
+         * uintptr_t because even on a machine with signed
+         * pointers, objects do not cross zero; whereas on
+         * machines with unsigned pointers, they may cross
+         * 0x8bazillion.
+         */
+        return NULL;
+
+        /* see comment near libxl__ev_watch_slot definition */
+    return (void*)slotcontents;
+}
+
+static void watchfd_callback(libxl__gc *gc, libxl__ev_fd *ev,
+                             int fd, short events, short revents) {
+    for (;;) {
+        char **event = xs_check_watch(CTX->xsh);
+        if (!event) {
+            if (errno == EAGAIN) break;
+            if (errno == EINTR) continue;
+            LIBXL__EVENT_DISASTER(gc, "cannot check/read watches", errno, 0);
+            return;
+        }
+
+        const char *epath = event[0];
+        const char *token = event[1];
+        int slotnum;
+        uint32_t counterval;
+        int rc = sscanf(token, "%d/%"SCNx32, &slotnum, &counterval);
+        if (rc != 2) {
+            LIBXL__LOG(CTX, LIBXL__LOG_ERROR,
+                       "watch epath=%s token=%s: failed to parse token",
+                       epath, token);
+            /* oh well */
+            goto ignore;
+        }
+        if (slotnum < 0 || slotnum >= CTX->watch_nslots) {
+            /* perhaps in the future we will make the watchslots array shrink */
+            LIBXL__LOG(CTX, LIBXL__LOG_DEBUG, "watch epath=%s token=%s:"
+                       " slotnum %d out of range [0,%d>",
+                       epath, token, slotnum, CTX->watch_nslots);
+            goto ignore;
+        }
+
+        libxl__ev_xswatch *w = libxl__watch_slot_contents(gc, slotnum);
+
+        if (!w) {
+            LIBXL__LOG(CTX, LIBXL__LOG_DEBUG,
+                       "watch epath=%s token=%s: empty slot",
+                       epath, token);
+            goto ignore;
+        }
+        
+        if (w->counterval != counterval) {
+            LIBXL__LOG(CTX, LIBXL__LOG_DEBUG,
+                       "watch epath=%s token=%s: counter != %"PRIx32,
+                       epath, token, w->counterval);
+            goto ignore;
+        }
+
+        /* Now it's possible, though unlikely, that this was an event
+         * from a previous use of the same slot with the same counterval.
+         *
+         * In that case either:
+         *  - the event path is a child of the watch path, in
+         *    which case this watch would really have generated this
+         *    event if it had been registered soon enough and we are
+         *    OK to give this possibly-spurious event to the caller; or
+         * - it is not, in which case we must suppress it as the
+         *   caller should not see events for unrelated paths.
+         *
+         * See also docs/misc/xenstore.txt.
+         */
+        size_t epathlen = strlen(epath);
+        size_t wpathlen = strlen(w->path);
+        if (epathlen < wpathlen ||
+            memcmp(epath, w->path, wpathlen) ||
+            (epathlen > wpathlen && epath[wpathlen] != '/')) {
+            LIBXL__LOG(CTX, LIBXL__LOG_DEBUG,
+                       "watch epath=%s token=%s: not child of wpath=%s",
+                       epath, token, w->path);
+            goto ignore;
+        }
+
+        /* At last, we have checked everything! */
+        LIBXL__LOG(CTX, LIBXL__LOG_DEBUG,
+                   "watch event: epath=%s token=%s wpath=%s w=%p",
+                   epath, token, w->path, w);
+        w->callback(gc, w, w->path, epath);
+
+    ignore:
+        free(event);
+    }
+}
+
+static char *watch_token(libxl__gc *gc, int slotnum, uint32_t counterval) {
+    return libxl__sprintf(gc, "%d/%"PRIx32, slotnum, counterval);
+}
+
+int libxl__ev_xswatch_register(libxl__gc *gc, libxl__ev_xswatch *w,
+                               libxl__ev_xswatch_callback *func,
+                               const char *path /* copied */) {
+    libxl__ev_watch_slot *use = NULL;
+    char *path_copy = NULL;
+    int rc;
+
+    CTX_LOCK;
+
+    if (!libxl__ev_fd_isregistered(&CTX->watch_efd)) {
+        rc = libxl__ev_fd_register(gc, &CTX->watch_efd, watchfd_callback,
+                                   xs_fileno(CTX->xsh), POLLIN);
+        if (rc) goto out_rc;
+    }
+
+    if (LIBXL_SLIST_EMPTY(&CTX->watch_freeslots)) {
+        /* Free list is empty so there is not in fact a linked
+         * free list in the array and we can safely realloc it */
+        int newarraysize = (CTX->watch_nslots + 1) << 2;
+        int i;
+        libxl__ev_watch_slot *newarray =
+            realloc(CTX->watch_slots, sizeof(*newarray) * newarraysize);
+        if (!newarray) goto out_nomem;
+        for (i=CTX->watch_nslots; i<newarraysize; i++)
+            LIBXL_SLIST_INSERT_HEAD(&CTX->watch_freeslots,
+                                    &newarray[i], empty);
+        CTX->watch_slots = newarray;
+        CTX->watch_nslots = newarraysize;
+    }
+    use = LIBXL_SLIST_FIRST(&CTX->watch_freeslots);
+    assert(use);
+    LIBXL_SLIST_REMOVE_HEAD(&CTX->watch_freeslots, empty);
+
+    path_copy = strdup(path);
+    if (!path_copy) goto out_nomem;
+
+    int slotnum = use - CTX->watch_slots;
+    w->counterval = CTX->watch_counter++;
+
+    if (!xs_watch(CTX->xsh, path, watch_token(gc, slotnum, w->counterval))) {
+        LIBXL__LOG_ERRNOVAL(CTX, LIBXL__LOG_ERROR, errno,
+                            "create watch for path %s", path);
+        rc = ERROR_FAIL;
+        goto out_rc;
+    }
+
+    w->slotnum = slotnum;
+    w->path = path_copy;
+    w->callback = func;
+    /* we look a bit behind the curtain of LIBXL_SLIST, to explictly
+     * assign to the pointer that's the next link.  See the comment
+     * by the definitionn of libxl__ev_watch_slot */
+    use->empty.sle_next = (void*)w;
+
+    CTX_UNLOCK;
+    return 0;
+
+ out_nomem:
+    rc = ERROR_NOMEM;
+ out_rc:
+    if (use)
+        LIBXL_SLIST_INSERT_HEAD(&CTX->watch_freeslots, use, empty);
+    if (path_copy)
+        free(path_copy);
+    CTX_UNLOCK;
+    return rc;
+}
+
+void libxl__ev_xswatch_deregister(libxl__gc *gc, libxl__ev_xswatch *w) {
+    /* it is legal to deregister from within _callback */
+    CTX_LOCK;
+
+    if (w->slotnum >= 0) {
+        char *token = watch_token(gc, w->slotnum, w->counterval);
+        if (!xs_unwatch(CTX->xsh, w->path, token))
+            /* Oh well, we will just get watch events forever more
+             * and ignore them.  But we should complain to the log. */
+            LIBXL__LOG_ERRNOVAL(CTX, LIBXL__LOG_ERROR, errno,
+                                "remove watch for path %s", w->path);
+
+        libxl__ev_watch_slot *slot = &CTX->watch_slots[w->slotnum];
+        LIBXL_SLIST_INSERT_HEAD(&CTX->watch_freeslots, slot, empty);
+    }
+
+    free(w->path);
+    w->path = NULL;
+
+    CTX_UNLOCK;
+}
+
+/*
+ * osevent poll
+ */
+
+int libxl_osevent_beforepoll(libxl_ctx *ctx, int *nfds_io,
+                             struct pollfd *fds, int *timeout_upd,
+                             struct timeval now) {
+    libxl__ev_fd *efd;
+    int i;
+
+    /*
+     * In order to be able to efficiently find the libxl__ev_fd
+     * for a struct poll during _afterpoll, we maintain a shadow
+     * data structure in CTX->fd_beforepolled: each slot in
+     * the fds array corresponds to a slot in fd_beforepolled.
+     */
+
+    GC_INIT(ctx);
+    CTX_LOCK;
+
+    if (*nfds_io) {
+        /*
+         * As an optimisation, we don't touch fd_beforepolled_used
+         * if *nfds_io is zero on entry, since in that case the
+         * caller just wanted to know how big an array to give us.
+         *
+         * If !*nfds_io, the unconditional parts below are guaranteed
+         * not to mess with fd_beforepolled... or any in_beforepolled.
+         */
+
+        /* Remove all the old references into beforepolled */
+        for (i = 0; i < CTX->fd_beforepolled_used; i++) {
+            efd = CTX->fd_beforepolled[i];
+            if (efd) {
+                assert(efd->in_beforepolled == i);
+                efd->in_beforepolled = -1;
+                CTX->fd_beforepolled[i] = NULL;
+            }
+        }
+        CTX->fd_beforepolled_used = 0;
+
+        /* make sure our array is as big as *nfds_io */
+        if (CTX->fd_beforepolled_allocd < *nfds_io) {
+            assert(*nfds_io < INT_MAX / sizeof(libxl__ev_fd*) / 2);
+            libxl__ev_fd **newarray =
+                realloc(CTX->fd_beforepolled, sizeof(*newarray) * *nfds_io);
+            if (!newarray)
+                return ERROR_NOMEM;
+            CTX->fd_beforepolled = newarray;
+            CTX->fd_beforepolled_allocd = *nfds_io;
+        }
+    }
+
+    int used = 0;
+    LIBXL_LIST_FOREACH(efd, &CTX->efds, entry) {
+        if (used < *nfds_io) {
+            fds[used].fd = efd->fd;
+            fds[used].events = efd->events;
+            fds[used].revents = 0;
+            CTX->fd_beforepolled[used] = efd;
+            efd->in_beforepolled = used;
+        }
+        used++;
+    }
+    int rc = used <= *nfds_io ? 0 : ERROR_BUFFERFULL;
+
+    if (*nfds_io) {
+        CTX->fd_beforepolled_used = used;
+    }
+
+    *nfds_io = used;
+
+    libxl__ev_time *etime = LIBXL_TAILQ_FIRST(&CTX->etimes);
+    if (etime) {
+        int our_timeout;
+        struct timeval rel;
+        static struct timeval zero;
+
+        timersub(&etime->abs, &now, &rel);
+
+        if (timercmp(&rel, &zero, <)) {
+            our_timeout = 0;
+        } else if (rel.tv_sec >= 2000000) {
+            our_timeout = 2000000000;
+        } else {
+            our_timeout = rel.tv_sec * 1000 + (rel.tv_usec + 999) / 1000;
+        }
+        if (*timeout_upd < 0 || our_timeout < *timeout_upd)
+            *timeout_upd = our_timeout;
+    }
+
+    CTX_UNLOCK;
+    GC_FREE;
+    return rc;
+}
+
+void libxl_osevent_afterpoll(libxl_ctx *ctx, int nfds, const struct pollfd *fds,
+                             struct timeval now) {
+    int i;
+    GC_INIT(ctx);
+    CTX_LOCK;
+
+    assert(nfds <= CTX->fd_beforepolled_used);
+
+    for (i = 0; i < nfds; i++) {
+        if (!fds[i].revents)
+            continue;
+
+        libxl__ev_fd *efd = CTX->fd_beforepolled[i];
+        if (!efd)
+            continue;
+
+        assert(efd->in_beforepolled == i);
+        assert(fds[i].fd == efd->fd);
+
+        int revents = fds[i].revents & efd->events;
+        if (!revents)
+            continue;
+
+        efd->func(gc, efd, efd->fd, efd->events, revents);
+    }
+
+    for (;;) {
+        libxl__ev_time *etime = LIBXL_TAILQ_FIRST(&CTX->etimes);
+        if (!etime)
+            break;
+
+        assert(!etime->infinite);
+
+        if (timercmp(&etime->abs, &now, >))
+            break;
+
+        time_deregister(gc, etime);
+
+        etime->func(gc, etime, &etime->abs);
+    }
+
+    CTX_UNLOCK;
+    GC_FREE;
+}
+
+
+/*
+ * osevent hook and callback machinery
+ */
+
+void libxl_osevent_register_hooks(libxl_ctx *ctx,
+                                  const libxl_osevent_hooks *hooks,
+                                  void *user) {
+    GC_INIT(ctx);
+    CTX_LOCK;
+    ctx->osevent_hooks = hooks;
+    ctx->osevent_user = user;
+    CTX_UNLOCK;
+    GC_FREE;
+}
+
+
+void libxl_osevent_occurred_fd(libxl_ctx *ctx, void *for_libxl,
+                               int fd, short events, short revents) {
+    libxl__ev_fd *ev = for_libxl;
+
+    GC_INIT(ctx);
+    CTX_LOCK;
+    assert(!CTX->osevent_in_hook);
+
+    assert(fd == ev->fd);
+    revents &= ev->events;
+    if (revents)
+        ev->func(gc, ev, fd, ev->events, revents);
+
+    CTX_UNLOCK;
+    GC_FREE;
+}
+
+void libxl_osevent_occurred_timeout(libxl_ctx *ctx, void *for_libxl) {
+    libxl__ev_time *ev = for_libxl;
+
+    GC_INIT(ctx);
+    CTX_LOCK;
+    assert(!CTX->osevent_in_hook);
+
+    assert(!ev->infinite);
+    LIBXL_TAILQ_REMOVE(&CTX->etimes, ev, entry);
+    ev->func(gc, ev, &ev->abs);
+
+    CTX_UNLOCK;
+    GC_FREE;
+}
+
+void libxl__event_disaster(libxl__gc *gc, const char *msg, int errnoval,
+                           libxl_event_type type /* may be 0 */,
+                           const char *file, int line, const char *func) {
+    libxl__log(CTX, XTL_CRITICAL, errnoval, file, line, func,
+               "DISASTER in event loop: %s%s%s%s",
+               msg,
+               type ? " (relates to event type " : "",
+               type ? libxl_event_type_to_string(type) : "",
+               type ? ")" : "");
+
+    /*
+     * FIXME: This should call the "disaster" hook supplied to
+     * libxl_event_register_callbacks, which will be introduced in the
+     * next patch.
+     */
+
+    const char verybad[] =
+        "DISASTER in event loop not handled by libxl application";
+    LIBXL__LOG(CTX, XTL_CRITICAL, verybad);
+    fprintf(stderr, "libxl: fatal error, exiting program: %s\n", verybad);
+    exit(-1);
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/tools/libxl/libxl_event.h b/tools/libxl/libxl_event.h
new file mode 100644
index 0000000..25efbdf
--- /dev/null
+++ b/tools/libxl/libxl_event.h
@@ -0,0 +1,199 @@
+/*
+ * Copyright (C) 2011      Citrix Ltd.
+ * Author Ian Jackson <ian.jackson@eu.citrix.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU Lesser General Public License as published
+ * by the Free Software Foundation; version 2.1 only. with the special
+ * exception on linking described in file LICENSE.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU Lesser General Public License for more details.
+ */
+
+#ifndef LIBXL_EVENT_H
+#define LIBXL_EVENT_H
+
+#include <libxl.h>
+
+
+/*======================================================================*/
+
+/*
+ * OS event handling - passing low-level OS events to libxl
+ *
+ * Event-driven programs must use these facilities to allow libxl
+ * to become aware of readability/writeability of file descriptors
+ * and the occurrence of timeouts.
+ *
+ * There are two approaches available.  The first is appropriate for
+ * simple programs handling reasonably small numbers of domains:
+ *
+ *   for (;;) {
+ *      libxl_osevent_beforepoll(...)
+ *      poll();
+ *      libxl_osevent_afterpoll(...);
+ *      for (;;) {
+ *        r=libxl_event_check(...);
+ *        if (r==LIBXL_NOT_READY) break;
+ *        if (r) handle failure;
+ *        do something with the event;
+ *      }
+ *   }
+ *
+ * The second approach uses libxl_osevent_register_hooks and is
+ * suitable for programs which are already using a callback-based
+ * event library.
+ *
+ * An application may freely mix the two styles of interaction.
+ */
+
+struct pollfd;
+
+int libxl_osevent_beforepoll(libxl_ctx *ctx, int *nfds_io,
+                             struct pollfd *fds, int *timeout_upd,
+                             struct timeval now);
+  /* The caller should provide beforepoll with some space for libxl's
+   * fds, and tell libxl how much space is available by setting *nfds_io.
+   * fds points to the start of this space (and fds may be a pointer into
+   * a larger array, for example, if the application has some fds of
+   * its own that it is interested in).
+   *
+   * On return *nfds_io will in any case have been updated by libxl
+   * according to how many fds libxl wants to poll on.
+   *
+   * If the space was sufficient, libxl fills in fds[0..<new
+   * *nfds_io>] suitably for poll(2), updates *timeout_upd if needed,
+   * and returns ok.
+   *
+   * If space was insufficient, fds[0..<old *nfds_io>] is undefined on
+   * return; *nfds_io on return will be greater than the value on
+   * entry; *timeout_upd may or may not have been updated; and
+   * libxl_osevent_beforepoll returns ERROR_BUFERFULL.  In this case
+   * the application needs to make more space (enough space for
+   * *nfds_io struct pollfd) and then call beforepoll again, before
+   * entering poll(2).  Typically this will involve calling realloc.
+   *
+   * The application may call beforepoll with fds==NULL and
+   * *nfds_io==0 in order to find out how much space is needed.
+   *
+   * *timeout_upd is as for poll(2): it's in milliseconds, and
+   * negative values mean no timeout (infinity).
+   * libxl_osevent_beforepoll will only reduce the timeout, naturally.
+   */
+void libxl_osevent_afterpoll(libxl_ctx *ctx, int nfds, const struct pollfd *fds,
+                             struct timeval now);
+  /* nfds and fds[0..nfds] must be from the most recent call to
+   * _beforepoll, as modified by poll.
+   *
+   * This function actually performs all of the IO and other actions,
+   * and generates events (libxl_event), which are implied by either
+   * (a) the time of day or (b) both (i) the returned information from
+   * _beforepoll, and (ii) the results from poll specified in
+   * fds[0..nfds-1].  Generated events can then be retrieved by
+   * libxl_event_check.
+   */
+
+
+typedef struct libxl_osevent_hooks {
+  int (*fd_register)(void *user, int fd, void **for_app_registration_out,
+                     short events, void *for_libxl);
+  int (*fd_modify)(void *user, int fd, void **for_app_registration_update,
+                   short events);
+  void (*fd_deregister)(void *user, int fd, void *for_app_registration);
+  int (*timeout_register)(void *user, void **for_app_registration_out,
+                          struct timeval abs, void *for_libxl);
+  int (*timeout_modify)(void *user, void **for_app_registration_update,
+                         struct timeval abs);
+  void (*timeout_deregister)(void *user, void *for_app_registration_io);
+} libxl_osevent_hooks;
+
+void libxl_osevent_register_hooks(libxl_ctx *ctx,
+                                  const libxl_osevent_hooks *hooks,
+                                  void *user);
+  /* The application which calls register_fd_hooks promises to
+   * maintain a register of fds and timeouts that libxl is interested
+   * in, and make calls into libxl (libxl_osevent_occurred_*)
+   * when those fd events and timeouts occur.  This is more efficient
+   * than _beforepoll/_afterpoll if there are many fds (which can
+   * happen if the same libxl application is managing many domains).
+   *
+   * For an fd event, events is as for poll().  register or modify may
+   * be called with events==0, in which case it must still work
+   * normally, just not generate any events.
+   *
+   * For a timeout event, milliseconds is as for poll().
+   * Specifically, negative values of milliseconds mean NO TIMEOUT.
+   * This is used by libxl to temporarily disable a timeout.
+   *
+   * If the register or modify hook succeeds it may update
+   * *for_app_registration_out/_update and must then return 0.
+   * On entry to register, *for_app_registration_out is always NULL.
+   *
+   * A registration or modification hook may fail, in which case it
+   * must leave the registration state of the fd or timeout unchanged.
+   * It may then either return ERROR_OSEVENT_REG_FAIL or any positive
+   * int.  The value returned will be passed up through libxl and
+   * eventually returned back to the application.  When register
+   * fails, any value stored into *for_registration_out is ignored by
+   * libxl; when modify fails, any changed value stored into
+   * *for_registration_update is honoured by libxl and will be passed
+   * to future modify or deregister calls.
+   *
+   * libxl will only attempt to register one callback for any one fd.
+   * libxl will remember the value stored in *for_app_registration_io
+   * by a successful call to register or modify and pass it into
+   * subsequent calls to modify or deregister.
+   *
+   * register_fd_hooks may be called only once for each libxl_ctx.
+   * libxl may make calls to register/modify/deregister from within
+   * any libxl function (indeed, it will usually call register from
+   * register_event_hooks).  Conversely, the application MUST NOT make
+   * the event occurrence calls (libxl_osevent_occurred_*) into libxl
+   * reentrantly from within libxl (for example, from within the
+   * register/modify functions).
+   *
+   * Lock hierarchy: the register/modify/deregister functions may be
+   * called with locks held.  These locks (the "libxl internal locks")
+   * are inside the libxl_ctx.  Therefore, if those register functions
+   * acquire any locks of their own ("caller register locks") outside
+   * libxl, to avoid deadlock one of the following must hold for each
+   * such caller register lock:
+   *  (a) "acquire libxl internal locks before caller register lock":
+   *      No libxl function may be called with the caller register
+   *      lock held.
+   *  (b) "acquire caller register lock before libxl internal locks":
+   *      No libxl function may be called _without_ the caller
+   *      register lock held.
+   * Of these we would normally recommend (a).
+   *
+   * The value *hooks is not copied and must outlast the libxl_ctx.
+   */
+
+/* It is NOT legal to call _occurred_ reentrantly within any libxl
+ * function.  Specifically it is NOT legal to call it from within
+ * a register callback.  Conversely, libxl MAY call register/deregister
+ * from within libxl_event_registered_call_*.
+ */
+
+void libxl_osevent_occurred_fd(libxl_ctx *ctx, void *for_libxl,
+                               int fd, short events, short revents);
+
+void libxl_osevent_occurred_timeout(libxl_ctx *ctx, void *for_libxl);
+  /* Implicitly, on entry to this function the timeout has been
+   * deregistered.  If _occurred_timeout is called, libxl will not
+   * call timeout_deregister; if it wants to requeue the timeout it
+   * will call timeout_register again.
+   */
+
+#endif
+
+/*
+ * Local variables:
+ * mode: C
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index d015c7c..88e7dbb 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -24,6 +24,9 @@
 #include <stdlib.h>
 #include <string.h>
 #include <pthread.h>
+#include <inttypes.h>
+#include <assert.h>
+#include <sys/poll.h>
 
 #include <xs.h>
 #include <xenctrl.h>
@@ -91,6 +94,66 @@ _hidden void libxl__log(libxl_ctx *ctx, xentoollog_level msglevel, int errnoval,
 
      /* these functions preserve errno (saving and restoring) */
 
+typedef struct libxl__gc libxl__gc;
+
+typedef struct libxl__ev_fd libxl__ev_fd;
+typedef void libxl__ev_fd_callback(libxl__gc *gc, libxl__ev_fd *ev,
+                                   int fd, short events, short revents);
+struct libxl__ev_fd {
+    /* all private for libxl__ev_fd... */
+    LIBXL_LIST_ENTRY(libxl__ev_fd) entry;
+    int fd;
+    short events;
+    int in_beforepolled; /* -1 means not in fd_beforepolled */
+    void *for_app_reg;
+    libxl__ev_fd_callback *func;
+};
+
+
+typedef struct libxl__ev_time libxl__ev_time;
+typedef void libxl__ev_time_callback(libxl__gc *gc, libxl__ev_time *ev,
+                                     const struct timeval *requested_abs);
+struct libxl__ev_time {
+    /* all private for libxl__ev_time... */
+    int infinite; /* not registered in list or with app if infinite */
+    LIBXL_TAILQ_ENTRY(libxl__ev_time) entry;
+    struct timeval abs;
+    void *for_app_reg;
+    libxl__ev_time_callback *func;
+};
+
+typedef struct libxl__ev_xswatch libxl__ev_xswatch;
+typedef void libxl__ev_xswatch_callback(libxl__gc *gc, libxl__ev_xswatch*,
+                            const char *watch_path, const char *event_path);
+struct libxl__ev_xswatch {
+    /* caller should include this in their own struct */
+    /* contents are private to xswatch_register */
+    int slotnum;
+    uint32_t counterval;
+    char *path;
+    libxl__ev_xswatch_callback *callback;
+};
+
+/*
+ * An entry in the watch_slots table is either:
+ *  1. an entry in the free list, ie NULL or pointer to next free list entry
+ *  2. an pointer to a libxl__ev_xswatch
+ *
+ * But we don't want to use unions or type-punning because the
+ * compiler might "prove" that our code is wrong and misoptimise it.
+ *
+ * The rules say that all struct pointers have identical
+ * representation and alignment requirements (C99+TC1+TC2 6.2.5p26) so
+ * what we do is simply declare our array as containing only the free
+ * list pointers, and explicitly convert from and to our actual
+ * xswatch pointers when we store and retrieve them.
+ */
+typedef struct libxl__ev_watch_slot {
+    LIBXL_SLIST_ENTRY(struct libxl__ev_watch_slot) empty;
+} libxl__ev_watch_slot;
+    
+libxl__ev_xswatch *libxl__watch_slot_contents(libxl__gc *gc, int slotnum);
+
 struct libxl__ctx {
     xentoollog_logger *lg;
     xc_interface *xch;
@@ -108,6 +171,23 @@ struct libxl__ctx {
        * documented in the libxl public interface.
        */
 
+    int osevent_in_hook;
+    const libxl_osevent_hooks *osevent_hooks;
+    void *osevent_user;
+      /* See the comment for OSEVENT_HOOK_INTERN in libxl_event.c
+       * for restrictions on the use of the osevent fields. */
+
+    int fd_beforepolled_allocd, fd_beforepolled_used;
+    libxl__ev_fd **fd_beforepolled; /* see libxl_osevent_beforepoll */
+    LIBXL_LIST_HEAD(, libxl__ev_fd) efds;
+    LIBXL_TAILQ_HEAD(, libxl__ev_time) etimes;
+
+    libxl__ev_watch_slot *watch_slots;
+    int watch_nslots;
+    LIBXL_SLIST_HEAD(, libxl__ev_watch_slot) watch_freeslots;
+    uint32_t watch_counter; /* helps disambiguate slot reuse */
+    libxl__ev_fd watch_efd;
+
     /* for callers who reap children willy-nilly; caller must only
      * set this after libxl_init and before any other call - or
      * may leave them untouched */
@@ -138,12 +218,12 @@ typedef struct {
 
 #define PRINTF_ATTRIBUTE(x, y) __attribute__((format(printf, x, y)))
 
-typedef struct {
+struct libxl__gc {
     /* mini-GC */
     int alloc_maxsize;
     void **alloc_ptrs;
     libxl_ctx *owner;
-} libxl__gc;
+};
 
 #define LIBXL_INIT_GC(gc,ctx) do{               \
         (gc).alloc_maxsize = 0;                 \
@@ -209,9 +289,137 @@ _hidden char *libxl__xs_read(libxl__gc *gc, xs_transaction_t t,
 _hidden char **libxl__xs_directory(libxl__gc *gc, xs_transaction_t t,
                                    const char *path, unsigned int *nb);
    /* On error: returns NULL, sets errno (no logging) */
-
 _hidden char *libxl__xs_libxl_path(libxl__gc *gc, uint32_t domid);
 
+
+/*
+ * Event generation functions provided by the libxl event core to the
+ * rest of libxl.  Implemented in terms of _beforepoll/_afterpoll
+ * and/or the fd registration machinery, as provided by the
+ * application.
+ *
+ * Semantics are similar to those of the fd and timeout registration
+ * functions provided to libxl_osevent_register_hooks.
+ *
+ * Non-0 returns from libxl__ev_{modify,deregister} have already been
+ * logged by the core and should be returned unmodified to libxl's
+ * caller; NB that they may be valid libxl error codes but they may
+ * also be positive numbers supplied by the caller.
+ *
+ * In each case, there is a libxl__ev_FOO structure which can be in
+ * one of three states:
+ *
+ *   Undefined   - Might contain anything.  All-bits-zero is
+ *                 an undefined state.
+ *
+ *   Idle        - Struct contents are defined enough to pass to any
+ *                 libxl__ev_FOO function but not registered and
+ *                 callback will not be called.  The struct does not
+ *                 contain references to any allocated resources so
+ *                 can be thrown away.
+ *
+ *   Active      - Request for events has been registered and events
+ *                 may be generated.  _deregister must be called to
+ *                 reclaim resources.
+ *
+ * These functions are provided for each kind of event KIND:
+ *
+ *   int libxl__ev_KIND_register(libxl__gc *gc, libxl__ev_KIND *GEN,
+ *                              libxl__ev_KIND_callback *FUNC,
+ *                              DETAILS);
+ *      On entry *GEN must be in state Undefined or Idle.
+ *      Returns a libxl error code; on error return *GEN is Idle.
+ *      On successful return *GEN is Active and FUNC wil be
+ *      called by the event machinery in future.  FUNC will
+ *      not be called from within the call to _register.
+ *
+ *  void libxl__ev_KIND_deregister(libxl__gc *gc, libxl__ev_KIND *GEN_upd);
+ *      On entry *GEN must be in state Active or Idle.
+ *      On return it is Idle.  (Idempotent.)
+ *
+ *  void libxl__ev_KIND_init(libxl__ev_KIND *GEN);
+ *      Provided for initialising an Undefined KIND.
+ *      On entry *GEN must be in state Idle or Undefined.
+ *      On return it is Idle.  (Idempotent.)
+ *
+ *  int libxl__ev_KIND_isregistered(const libxl__ev_KIND *GEN);
+ *      On entry *GEN must be Idle or Active.
+ *      Returns nonzero if it is Active, zero otherwise.
+ *      Cannot fail.
+ *
+ *  int libxl__ev_KiND_modify(libxl__gc*, libxl__ev_KIND *GEN,
+ *                            DETAILS);
+ *      Only provided for some kinds of generator.
+ *      On entry *GEN must be Active and on return, whether successful
+ *      or not, it will be Active.
+ *      Returns a libxl error code; on error the modification
+ *      is not effective.
+ *
+ * All of these functions are fully threadsafe and may be called by
+ * general code in libxl even from within event callback FUNCs.
+ */
+
+
+_hidden int libxl__ev_fd_register(libxl__gc*, libxl__ev_fd *ev_out,
+                                  libxl__ev_fd_callback*,
+                                  int fd, short events /* as for poll(2) */);
+_hidden int libxl__ev_fd_modify(libxl__gc*, libxl__ev_fd *ev,
+                                short events);
+_hidden void libxl__ev_fd_deregister(libxl__gc*, libxl__ev_fd *ev);
+static inline void libxl__ev_fd_init(libxl__ev_fd *efd)
+                    { efd->fd = -1; }
+static inline int libxl__ev_fd_isregistered(libxl__ev_fd *efd)
+                    { return efd->fd >= 0; }
+
+_hidden int libxl__ev_time_register_rel(libxl__gc*, libxl__ev_time *ev_out,
+                                        libxl__ev_time_callback*,
+                                        int milliseconds /* as for poll(2) */);
+_hidden int libxl__ev_time_register_abs(libxl__gc*, libxl__ev_time *ev_out,
+                                        libxl__ev_time_callback*,
+                                        struct timeval);
+_hidden int libxl__ev_time_modify_rel(libxl__gc*, libxl__ev_time *ev,
+                                      int milliseconds /* as for poll(2) */);
+_hidden int libxl__ev_time_modify_abs(libxl__gc*, libxl__ev_time *ev,
+                                      struct timeval);
+_hidden void libxl__ev_time_deregister(libxl__gc*, libxl__ev_time *ev);
+static inline void libxl__ev_time_init(libxl__ev_time *ev)
+                { ev->func = 0; }
+static inline int libxl__ev_time_isregistered(libxl__ev_time *ev)
+                { return !!ev->func; }
+
+
+_hidden int libxl__ev_xswatch_register(libxl__gc*, libxl__ev_xswatch *xsw_out,
+                                       libxl__ev_xswatch_callback*,
+                                       const char *path /* copied */);
+_hidden void libxl__ev_xswatch_deregister(libxl__gc *gc, libxl__ev_xswatch*);
+
+static inline void libxl__ev_xswatch_init(libxl__ev_xswatch *xswatch_out)
+                { xswatch_out->slotnum = -1; }
+static inline int libxl__ev_xswatch_isregistered(const libxl__ev_xswatch *xw)
+                { return xw->slotnum >= 0; }
+
+
+
+_hidden void libxl__event_disaster(libxl__gc*, const char *msg, int errnoval,
+                                   libxl_event_type type /* may be 0 */,
+                                   const char *file, int line,
+                                   const char *func);
+  /*
+   * In general, call this via the macro LIBXL__EVENT_DISASTER.
+   *
+   * Event-generating functions may call this if they might have
+   * wanted to generate an event (either an internal one ie a
+   * libxl__ev_FOO_callback or an application event), but are
+   * prevented from doing so due to eg lack of memory.
+   *
+   * NB that this function may return and the caller isn't supposed to
+   * then crash, although it may fail (and henceforth leave things in
+   * a state where many or all calls fail).
+   */
+#define LIBXL__EVENT_DISASTER(gc, msg, errnoval, type) \
+    libxl__event_disaster(gc, msg, errnoval, type, __FILE__, __LINE__, __func__)
+
+
 /* from xl_dom */
 _hidden libxl_domain_type libxl__domain_type(libxl__gc *gc, uint32_t domid);
 _hidden int libxl__domain_shutdown_reason(libxl__gc *gc, uint32_t domid);
@@ -536,6 +744,8 @@ _hidden int libxl__parse_mac(const char *s, libxl_mac mac);
 /* compare mac address @a and @b. 0 if the same, -ve if a<b and +ve if a>b */
 _hidden int libxl__compare_macs(libxl_mac *a, libxl_mac *b);
 
+_hidden int libxl__gettimeofday(libxl__gc *gc, struct timeval *now_r);
+
 #define STRINGIFY(x) #x
 #define TOSTRING(x) STRINGIFY(x)
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 18:11:32 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 18:11:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXd0R-00066B-K3; Mon, 05 Dec 2011 18:11:11 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RXd0Q-00065k-M6
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 18:11:10 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1323108624!1307875!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjAyNg==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27093 invoked from network); 5 Dec 2011 18:10:25 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Dec 2011 18:10:25 -0000
X-IronPort-AV: E=Sophos;i="4.71,300,1320624000"; 
   d="scan'208";a="9297519"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Dec 2011 18:10:24 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 5 Dec 2011 18:10:24 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RXczg-0003jr-EH; Mon, 05 Dec 2011 18:10:24 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RXczg-0006Vj-DH;
	Mon, 05 Dec 2011 18:10:24 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Mon, 5 Dec 2011 18:10:06 +0000
Message-ID: <1323108621-22654-1-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Subject: [Xen-devel] [PATCH v4 00/15] New event API
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a tested version of my event handling API proposal.  This
series contains a number of uncontroversial stylistic and bugfix
patches, plus these:

  02/15 libxenstore: Provide xs_check_watch
  12/15 libxl: Use GC_INIT and GC_FREE everywhere
  13/15 libxl: make LIBXL_INIT_GC a statement, not an initialiser
  14/15 libxl: New API for providing OS events to libxl
  15/15 libxl: New event generation API

Changes since v3:

 * New patches to use GC_INIT and GC_FREE everywhere so we could
   change LIBXL_INIT_GC to properly initialise the new tail queue in
   the gc.

 * Bugfixes resulting from testing.  Domain shutdown/death events work.
   Disk eject events work as well as they did beforehand, but it turns
   out that our cdrom insert/eject machinery is not currently working
   very well.  This needs to be addressed separately. 

 * Added some comments regarding #define OSEVENT_HOOK_INTERN
   in libxl_event.c.

Please review.  I would like to apply 12/15 in particular ASAP, as it
is textually very intrusive.  I think 01-12 ought to be pretty
uncontroversial by now, and I have now tested 02/15 so I think it's
ready to go in.

14 and 15 have the meat.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 18:11:32 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 18:11:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXd0Y-0006AC-GN; Mon, 05 Dec 2011 18:11:18 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RXd0U-000662-NW
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 18:11:14 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1323108628!7056836!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjAyNg==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20408 invoked from network); 5 Dec 2011 18:10:28 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Dec 2011 18:10:28 -0000
X-IronPort-AV: E=Sophos;i="4.71,300,1320624000"; 
   d="scan'208";a="9297528"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Dec 2011 18:10:28 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 5 Dec 2011 18:10:28 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RXczk-0003kI-5M; Mon, 05 Dec 2011 18:10:28 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RXczk-0006WP-4T;
	Mon, 05 Dec 2011 18:10:28 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Mon, 5 Dec 2011 18:10:15 +0000
Message-ID: <1323108621-22654-10-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1323108621-22654-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1323108621-22654-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 09/15] libxl: introduce lock in libxl_ctx
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This lock will be used to protect data structures which will be hung
off the libxl_ctx in subsequent patches.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl.c          |    6 ++++++
 tools/libxl/libxl_internal.h |   27 +++++++++++++++++++++++++++
 2 files changed, 33 insertions(+), 0 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index bc17b15..7488538 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -41,6 +41,7 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
 {
     libxl_ctx *ctx;
     struct stat stat_buf;
+    const pthread_mutex_t mutex_value = PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP;
 
     if (version != LIBXL_VERSION)
         return ERROR_VERSION;
@@ -54,6 +55,11 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
     memset(ctx, 0, sizeof(libxl_ctx));
     ctx->lg = lg;
 
+    /* This somewhat convoluted approach is needed because
+     * PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP is defined to be valid
+     * only as an initialiser, not as an expression. */
+    memcpy(&ctx->lock, &mutex_value, sizeof(ctx->lock));
+
     if ( stat(XENSTORE_PID_FILE, &stat_buf) != 0 ) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "Is xenstore daemon running?\n"
                      "failed to stat %s", XENSTORE_PID_FILE);
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index cda6fc1..41de6fd 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -23,6 +23,7 @@
 #include <stdarg.h>
 #include <stdlib.h>
 #include <string.h>
+#include <pthread.h>
 
 #include <xs.h>
 #include <xenctrl.h>
@@ -95,6 +96,18 @@ struct libxl__ctx {
     xc_interface *xch;
     struct xs_handle *xsh;
 
+    pthread_mutex_t lock; /* protects data structures hanging off the ctx */
+      /* Always use CTX_LOCK and CTX_UNLOCK to manipulate this.
+       *
+       * You may acquire this mutex recursively if it is convenient to
+       * do so.  You may not acquire this lock at the same time as any
+       * other lock.  If you need to call application code outside
+       * libxl (ie, a callback) with this lock held then it is
+       * necessaray to impose restrictions on the caller to maintain a
+       * proper lock hierarchy, and these restrictions must then be
+       * documented in the libxl public interface.
+       */
+
     /* for callers who reap children willy-nilly; caller must only
      * set this after libxl_init and before any other call - or
      * may leave them untouched */
@@ -668,6 +681,20 @@ libxl__device_model_version_running(libxl__gc *gc, uint32_t domid);
 #define CTX           libxl__gc_owner(gc)
 
 
+/* Locking functions.  See comment for "lock" member of libxl__ctx. */
+
+#define CTX_LOCK do {                                   \
+        int mutex_r = pthread_mutex_lock(&CTX->lock);   \
+        assert(!mutex_r);                               \
+    } while(0)
+
+#define CTX_UNLOCK do {                                 \
+        int mutex_r = pthread_mutex_unlock(&CTX->lock); \
+        assert(!mutex_r);                               \
+    } while(0)
+        
+
+
 /*
  * Inserts "elm_new" into the sorted list "head".
  *
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 18:11:32 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 18:11:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXd0R-00066B-K3; Mon, 05 Dec 2011 18:11:11 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RXd0Q-00065k-M6
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 18:11:10 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1323108624!1307875!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjAyNg==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27093 invoked from network); 5 Dec 2011 18:10:25 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Dec 2011 18:10:25 -0000
X-IronPort-AV: E=Sophos;i="4.71,300,1320624000"; 
   d="scan'208";a="9297519"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Dec 2011 18:10:24 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 5 Dec 2011 18:10:24 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RXczg-0003jr-EH; Mon, 05 Dec 2011 18:10:24 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RXczg-0006Vj-DH;
	Mon, 05 Dec 2011 18:10:24 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Mon, 5 Dec 2011 18:10:06 +0000
Message-ID: <1323108621-22654-1-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Subject: [Xen-devel] [PATCH v4 00/15] New event API
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a tested version of my event handling API proposal.  This
series contains a number of uncontroversial stylistic and bugfix
patches, plus these:

  02/15 libxenstore: Provide xs_check_watch
  12/15 libxl: Use GC_INIT and GC_FREE everywhere
  13/15 libxl: make LIBXL_INIT_GC a statement, not an initialiser
  14/15 libxl: New API for providing OS events to libxl
  15/15 libxl: New event generation API

Changes since v3:

 * New patches to use GC_INIT and GC_FREE everywhere so we could
   change LIBXL_INIT_GC to properly initialise the new tail queue in
   the gc.

 * Bugfixes resulting from testing.  Domain shutdown/death events work.
   Disk eject events work as well as they did beforehand, but it turns
   out that our cdrom insert/eject machinery is not currently working
   very well.  This needs to be addressed separately. 

 * Added some comments regarding #define OSEVENT_HOOK_INTERN
   in libxl_event.c.

Please review.  I would like to apply 12/15 in particular ASAP, as it
is textually very intrusive.  I think 01-12 ought to be pretty
uncontroversial by now, and I have now tested 02/15 so I think it's
ready to go in.

14 and 15 have the meat.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 18:11:32 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 18:11:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXd0Y-00069s-2T; Mon, 05 Dec 2011 18:11:18 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RXd0U-000661-Kq
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 18:11:14 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1323108629!5440616!3
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjAyNg==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14069 invoked from network); 5 Dec 2011 18:10:30 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Dec 2011 18:10:30 -0000
X-IronPort-AV: E=Sophos;i="4.71,300,1320624000"; 
   d="scan'208";a="9297532"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Dec 2011 18:10:29 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 5 Dec 2011 18:10:29 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RXczl-0003kU-CW; Mon, 05 Dec 2011 18:10:29 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RXczl-0006Wf-Au;
	Mon, 05 Dec 2011 18:10:29 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Mon, 5 Dec 2011 18:10:19 +0000
Message-ID: <1323108621-22654-14-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1323108621-22654-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1323108621-22654-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 13/15] libxl: make LIBXL_INIT_GC a statement,
	not an initialiser
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Previously LIBXL_INIT_GC was an initialiser, which you were expected
to use like this:
    libxl__gc gc = LIBXL_INIT_GC(ctx);

But we are going to want to put things in the gc which are to be
initialised using other macros.  That means that LIBXL_INIT_GC has to
become a statement too.  So instead, we make it so that it's used like this:
    libxl_gc gc;
    LIBXL_INIT_GC(gc,ctx);

In fact there is only one caller now, GC_INIT, which uses this trick:
    libxl_gc gc[1];
    LIBXL_INIT_GC(gc[0],ctx);

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl_internal.h |    9 +++++++--
 1 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 1d1dc35..d015c7c 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -145,7 +145,12 @@ typedef struct {
     libxl_ctx *owner;
 } libxl__gc;
 
-#define LIBXL_INIT_GC(ctx) (libxl__gc){ .alloc_maxsize = 0, .alloc_ptrs = 0, .owner = ctx }
+#define LIBXL_INIT_GC(gc,ctx) do{               \
+        (gc).alloc_maxsize = 0;                 \
+        (gc).alloc_ptrs = 0;                    \
+        (gc).owner = (ctx);                     \
+    } while(0)
+
 static inline libxl_ctx *libxl__gc_owner(libxl__gc *gc)
 {
     return gc->owner;
@@ -676,7 +681,7 @@ libxl__device_model_version_running(libxl__gc *gc, uint32_t domid);
  * as a local variable.
  */
 
-#define GC_INIT(ctx)  libxl__gc gc[1] = { LIBXL_INIT_GC(ctx) }
+#define GC_INIT(ctx)  libxl__gc gc[1]; LIBXL_INIT_GC(gc[0],ctx)
 #define GC_FREE       libxl__free_all(gc)
 #define CTX           libxl__gc_owner(gc)
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 18:11:32 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 18:11:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXd0Y-0006AC-GN; Mon, 05 Dec 2011 18:11:18 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RXd0U-000662-NW
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 18:11:14 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1323108628!7056836!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjAyNg==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20408 invoked from network); 5 Dec 2011 18:10:28 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Dec 2011 18:10:28 -0000
X-IronPort-AV: E=Sophos;i="4.71,300,1320624000"; 
   d="scan'208";a="9297528"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Dec 2011 18:10:28 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 5 Dec 2011 18:10:28 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RXczk-0003kI-5M; Mon, 05 Dec 2011 18:10:28 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RXczk-0006WP-4T;
	Mon, 05 Dec 2011 18:10:28 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Mon, 5 Dec 2011 18:10:15 +0000
Message-ID: <1323108621-22654-10-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1323108621-22654-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1323108621-22654-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 09/15] libxl: introduce lock in libxl_ctx
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This lock will be used to protect data structures which will be hung
off the libxl_ctx in subsequent patches.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl.c          |    6 ++++++
 tools/libxl/libxl_internal.h |   27 +++++++++++++++++++++++++++
 2 files changed, 33 insertions(+), 0 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index bc17b15..7488538 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -41,6 +41,7 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
 {
     libxl_ctx *ctx;
     struct stat stat_buf;
+    const pthread_mutex_t mutex_value = PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP;
 
     if (version != LIBXL_VERSION)
         return ERROR_VERSION;
@@ -54,6 +55,11 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
     memset(ctx, 0, sizeof(libxl_ctx));
     ctx->lg = lg;
 
+    /* This somewhat convoluted approach is needed because
+     * PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP is defined to be valid
+     * only as an initialiser, not as an expression. */
+    memcpy(&ctx->lock, &mutex_value, sizeof(ctx->lock));
+
     if ( stat(XENSTORE_PID_FILE, &stat_buf) != 0 ) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "Is xenstore daemon running?\n"
                      "failed to stat %s", XENSTORE_PID_FILE);
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index cda6fc1..41de6fd 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -23,6 +23,7 @@
 #include <stdarg.h>
 #include <stdlib.h>
 #include <string.h>
+#include <pthread.h>
 
 #include <xs.h>
 #include <xenctrl.h>
@@ -95,6 +96,18 @@ struct libxl__ctx {
     xc_interface *xch;
     struct xs_handle *xsh;
 
+    pthread_mutex_t lock; /* protects data structures hanging off the ctx */
+      /* Always use CTX_LOCK and CTX_UNLOCK to manipulate this.
+       *
+       * You may acquire this mutex recursively if it is convenient to
+       * do so.  You may not acquire this lock at the same time as any
+       * other lock.  If you need to call application code outside
+       * libxl (ie, a callback) with this lock held then it is
+       * necessaray to impose restrictions on the caller to maintain a
+       * proper lock hierarchy, and these restrictions must then be
+       * documented in the libxl public interface.
+       */
+
     /* for callers who reap children willy-nilly; caller must only
      * set this after libxl_init and before any other call - or
      * may leave them untouched */
@@ -668,6 +681,20 @@ libxl__device_model_version_running(libxl__gc *gc, uint32_t domid);
 #define CTX           libxl__gc_owner(gc)
 
 
+/* Locking functions.  See comment for "lock" member of libxl__ctx. */
+
+#define CTX_LOCK do {                                   \
+        int mutex_r = pthread_mutex_lock(&CTX->lock);   \
+        assert(!mutex_r);                               \
+    } while(0)
+
+#define CTX_UNLOCK do {                                 \
+        int mutex_r = pthread_mutex_unlock(&CTX->lock); \
+        assert(!mutex_r);                               \
+    } while(0)
+        
+
+
 /*
  * Inserts "elm_new" into the sorted list "head".
  *
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 18:11:32 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 18:11:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXd0Y-0006AR-Ur; Mon, 05 Dec 2011 18:11:18 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RXd0U-000660-Px
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 18:11:15 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1323108629!5440616!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjAyNg==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14036 invoked from network); 5 Dec 2011 18:10:29 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Dec 2011 18:10:29 -0000
X-IronPort-AV: E=Sophos;i="4.71,300,1320624000"; 
   d="scan'208";a="9297531"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Dec 2011 18:10:29 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 5 Dec 2011 18:10:29 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RXczl-0003kR-2X; Mon, 05 Dec 2011 18:10:29 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RXczl-0006Wb-1c;
	Mon, 05 Dec 2011 18:10:29 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Mon, 5 Dec 2011 18:10:18 +0000
Message-ID: <1323108621-22654-13-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1323108621-22654-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1323108621-22654-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 12/15] libxl: Use GC_INIT and GC_FREE everywhere
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Replace
    libxl__gc gc = LIBXL_INIT_GC(ctx);
    ...
    libxl__free_all(&gc);
with
    GC_INIT(ctx);
    ...
    GC_FREE;
throughout with a couple of perl runes.

We must then adjust uses of the resulting gc for pointerness, which is
mostly just replacing all occurrences of "&gc" with "gc".  Also a
couple of unusual uses of LIBXL_INIT_GC needed to be fixed up by hand.

Here are those runes:
 perl -i -pe 's/\Q    libxl__gc gc = LIBXL_INIT_GC(ctx);/    GC_INIT(ctx);/' tools/libxl/*.c
 perl -i -pe 's/\Q    libxl__free_all(&gc);/    GC_FREE;/' tools/libxl/*.c

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl.c            |  590 ++++++++++++++++++++--------------------
 tools/libxl/libxl_bootloader.c |   14 +-
 tools/libxl/libxl_create.c     |   12 +-
 tools/libxl/libxl_dom.c        |   16 +-
 tools/libxl/libxl_pci.c        |   34 ++--
 tools/libxl/libxl_qmp.c        |   32 +-
 tools/libxl/libxl_utils.c      |   36 ++--
 7 files changed, 367 insertions(+), 367 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 7488538..3a8cfe3 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -232,19 +232,19 @@ int libxl__domain_rename(libxl__gc *gc, uint32_t domid,
 int libxl_domain_rename(libxl_ctx *ctx, uint32_t domid,
                         const char *old_name, const char *new_name)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     int rc;
-    rc = libxl__domain_rename(&gc, domid, old_name, new_name, XBT_NULL);
-    libxl__free_all(&gc);
+    rc = libxl__domain_rename(gc, domid, old_name, new_name, XBT_NULL);
+    GC_FREE;
     return rc;
 }
 
 int libxl_domain_resume(libxl_ctx *ctx, uint32_t domid)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     int rc = 0;
 
-    if (LIBXL__DOMAIN_IS_TYPE(&gc,  domid, HVM)) {
+    if (LIBXL__DOMAIN_IS_TYPE(gc,  domid, HVM)) {
         LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Called domain_resume on "
                 "non-cooperative hvm domain %u", domid);
         rc = ERROR_NI;
@@ -264,7 +264,7 @@ int libxl_domain_resume(libxl_ctx *ctx, uint32_t domid)
         rc = ERROR_FAIL;
     }
 out:
-    libxl__free_all(&gc);
+    GC_FREE;
     return rc;
 }
 
@@ -277,7 +277,7 @@ out:
 int libxl_domain_preserve(libxl_ctx *ctx, uint32_t domid,
                           libxl_domain_create_info *info, const char *name_suffix, libxl_uuid new_uuid)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     struct xs_permissions roperm[2];
     xs_transaction_t t;
     char *preserved_name;
@@ -287,27 +287,27 @@ int libxl_domain_preserve(libxl_ctx *ctx, uint32_t domid,
 
     int rc;
 
-    preserved_name = libxl__sprintf(&gc, "%s%s", info->name, name_suffix);
+    preserved_name = libxl__sprintf(gc, "%s%s", info->name, name_suffix);
     if (!preserved_name) {
-        libxl__free_all(&gc);
+        GC_FREE;
         return ERROR_NOMEM;
     }
 
-    uuid_string = libxl__uuid2string(&gc, new_uuid);
+    uuid_string = libxl__uuid2string(gc, new_uuid);
     if (!uuid_string) {
-        libxl__free_all(&gc);
+        GC_FREE;
         return ERROR_NOMEM;
     }
 
-    dom_path = libxl__xs_get_dompath(&gc, domid);
+    dom_path = libxl__xs_get_dompath(gc, domid);
     if (!dom_path) {
-        libxl__free_all(&gc);
+        GC_FREE;
         return ERROR_FAIL;
     }
 
-    vm_path = libxl__sprintf(&gc, "/vm/%s", uuid_string);
+    vm_path = libxl__sprintf(gc, "/vm/%s", uuid_string);
     if (!vm_path) {
-        libxl__free_all(&gc);
+        GC_FREE;
         return ERROR_FAIL;
     }
 
@@ -323,20 +323,20 @@ int libxl_domain_preserve(libxl_ctx *ctx, uint32_t domid,
     xs_mkdir(ctx->xsh, t, vm_path);
     xs_set_permissions(ctx->xsh, t, vm_path, roperm, ARRAY_SIZE(roperm));
 
-    xs_write(ctx->xsh, t, libxl__sprintf(&gc, "%s/vm", dom_path), vm_path, strlen(vm_path));
-    rc = libxl__domain_rename(&gc, domid, info->name, preserved_name, t);
+    xs_write(ctx->xsh, t, libxl__sprintf(gc, "%s/vm", dom_path), vm_path, strlen(vm_path));
+    rc = libxl__domain_rename(gc, domid, info->name, preserved_name, t);
     if (rc) {
-        libxl__free_all(&gc);
+        GC_FREE;
         return rc;
     }
 
-    xs_write(ctx->xsh, t, libxl__sprintf(&gc, "%s/uuid", vm_path), uuid_string, strlen(uuid_string));
+    xs_write(ctx->xsh, t, libxl__sprintf(gc, "%s/uuid", vm_path), uuid_string, strlen(uuid_string));
 
     if (!xs_transaction_end(ctx->xsh, t, 0))
         if (errno == EAGAIN)
             goto retry_transaction;
 
-    libxl__free_all(&gc);
+    GC_FREE;
     return 0;
 }
 
@@ -478,16 +478,16 @@ libxl_vminfo * libxl_list_vm(libxl_ctx *ctx, int *nb_vm)
 int libxl_domain_suspend(libxl_ctx *ctx, libxl_domain_suspend_info *info,
                          uint32_t domid, int fd)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
-    libxl_domain_type type = libxl__domain_type(&gc, domid);
+    GC_INIT(ctx);
+    libxl_domain_type type = libxl__domain_type(gc, domid);
     int live = info != NULL && info->flags & XL_SUSPEND_LIVE;
     int debug = info != NULL && info->flags & XL_SUSPEND_DEBUG;
     int rc = 0;
 
-    rc = libxl__domain_suspend_common(&gc, domid, fd, type, live, debug);
+    rc = libxl__domain_suspend_common(gc, domid, fd, type, live, debug);
     if (!rc && type == LIBXL_DOMAIN_TYPE_HVM)
-        rc = libxl__domain_save_device_model(&gc, domid, fd);
-    libxl__free_all(&gc);
+        rc = libxl__domain_save_device_model(gc, domid, fd);
+    GC_FREE;
     return rc;
 }
 
@@ -517,17 +517,17 @@ int libxl_domain_core_dump(libxl_ctx *ctx, uint32_t domid,
 
 int libxl_domain_unpause(libxl_ctx *ctx, uint32_t domid)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     char *path;
     char *state;
     int ret, rc = 0;
 
-    if (LIBXL__DOMAIN_IS_TYPE(&gc,  domid, HVM)) {
-        path = libxl__sprintf(&gc, "/local/domain/0/device-model/%d/state", domid);
-        state = libxl__xs_read(&gc, XBT_NULL, path);
+    if (LIBXL__DOMAIN_IS_TYPE(gc,  domid, HVM)) {
+        path = libxl__sprintf(gc, "/local/domain/0/device-model/%d/state", domid);
+        state = libxl__xs_read(gc, XBT_NULL, path);
         if (state != NULL && !strcmp(state, "paused")) {
-            libxl__xs_write(&gc, XBT_NULL, libxl__sprintf(&gc, "/local/domain/0/device-model/%d/command", domid), "continue");
-            libxl__wait_for_device_model(&gc, domid, "running",
+            libxl__xs_write(gc, XBT_NULL, libxl__sprintf(gc, "/local/domain/0/device-model/%d/command", domid), "continue");
+            libxl__wait_for_device_model(gc, domid, "running",
                                          NULL, NULL, NULL);
         }
     }
@@ -536,7 +536,7 @@ int libxl_domain_unpause(libxl_ctx *ctx, uint32_t domid)
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "unpausing domain %d", domid);
         rc = ERROR_FAIL;
     }
-    libxl__free_all(&gc);
+    GC_FREE;
     return rc;
 }
 
@@ -550,42 +550,42 @@ static char *req_table[] = {
 
 int libxl_domain_shutdown(libxl_ctx *ctx, uint32_t domid, int req)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     char *shutdown_path;
     char *dom_path;
 
     if (req > ARRAY_SIZE(req_table)) {
-        libxl__free_all(&gc);
+        GC_FREE;
         return ERROR_INVAL;
     }
 
-    dom_path = libxl__xs_get_dompath(&gc, domid);
+    dom_path = libxl__xs_get_dompath(gc, domid);
     if (!dom_path) {
-        libxl__free_all(&gc);
+        GC_FREE;
         return ERROR_FAIL;
     }
 
-    if (LIBXL__DOMAIN_IS_TYPE(&gc,  domid, HVM)) {
+    if (LIBXL__DOMAIN_IS_TYPE(gc,  domid, HVM)) {
         unsigned long pvdriver = 0;
         int ret;
         ret = xc_get_hvm_param(ctx->xch, domid, HVM_PARAM_CALLBACK_IRQ, &pvdriver);
         if (ret<0) {
             LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "getting HVM callback IRQ");
-            libxl__free_all(&gc);
+            GC_FREE;
             return ERROR_FAIL;
         }
         if (!pvdriver) {
             LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "HVM domain without PV drivers:"
                        " graceful shutdown not possible, use destroy");
-            libxl__free_all(&gc);
+            GC_FREE;
             return ERROR_FAIL;
         }
     }
 
-    shutdown_path = libxl__sprintf(&gc, "%s/control/shutdown", dom_path);
+    shutdown_path = libxl__sprintf(gc, "%s/control/shutdown", dom_path);
     xs_write(ctx->xsh, XBT_NULL, shutdown_path, req_table[req], strlen(req_table[req]));
 
-    libxl__free_all(&gc);
+    GC_FREE;
     return 0;
 }
 
@@ -607,7 +607,7 @@ int libxl_wait_for_domain_death(libxl_ctx *ctx, uint32_t domid, libxl_waiter *wa
 
 int libxl_wait_for_disk_ejects(libxl_ctx *ctx, uint32_t guest_domid, libxl_device_disk *disks, int num_disks, libxl_waiter *waiter)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     int i, rc = -1;
     uint32_t domid = libxl_get_stubdom_id(ctx, guest_domid);
 
@@ -616,7 +616,7 @@ int libxl_wait_for_disk_ejects(libxl_ctx *ctx, uint32_t guest_domid, libxl_devic
 
     for (i = 0; i < num_disks; i++) {
         if (asprintf(&(waiter[i].path), "%s/device/vbd/%d/eject",
-                     libxl__xs_get_dompath(&gc, domid),
+                     libxl__xs_get_dompath(gc, domid),
                      libxl__device_disk_dev_number(disks[i].vdev,
                                                    NULL, NULL)) < 0)
             goto out;
@@ -626,7 +626,7 @@ int libxl_wait_for_disk_ejects(libxl_ctx *ctx, uint32_t guest_domid, libxl_devic
     }
     rc = 0;
 out:
-    libxl__free_all(&gc);
+    GC_FREE;
     return rc;
 }
 
@@ -680,22 +680,22 @@ int libxl_event_get_domain_death_info(libxl_ctx *ctx, uint32_t domid, libxl_even
 
 int libxl_event_get_disk_eject_info(libxl_ctx *ctx, uint32_t domid, libxl_event *event, libxl_device_disk *disk)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     char *path;
     char *backend;
     char *value;
     char backend_type[BACKEND_STRING_SIZE+1];
 
-    value = libxl__xs_read(&gc, XBT_NULL, event->path);
+    value = libxl__xs_read(gc, XBT_NULL, event->path);
 
     if (!value || strcmp(value,  "eject")) {
-        libxl__free_all(&gc);
+        GC_FREE;
         return 0;
     }
 
     path = strdup(event->path);
     path[strlen(path) - 6] = '\0';
-    backend = libxl__xs_read(&gc, XBT_NULL, libxl__sprintf(&gc, "%s/backend", path));
+    backend = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/backend", path));
 
     sscanf(backend,
             "/local/domain/%d/backend/%" TOSTRING(BACKEND_STRING_SIZE) "[a-z]/%*d/%*d",
@@ -711,19 +711,19 @@ int libxl_event_get_disk_eject_info(libxl_ctx *ctx, uint32_t domid, libxl_event
     disk->pdev_path = strdup("");
     disk->format = LIBXL_DISK_FORMAT_EMPTY;
     /* this value is returned to the user: do not free right away */
-    disk->vdev = xs_read(ctx->xsh, XBT_NULL, libxl__sprintf(&gc, "%s/dev", backend), NULL);
+    disk->vdev = xs_read(ctx->xsh, XBT_NULL, libxl__sprintf(gc, "%s/dev", backend), NULL);
     disk->removable = 1;
     disk->readwrite = 0;
     disk->is_cdrom = 1;
 
     free(path);
-    libxl__free_all(&gc);
+    GC_FREE;
     return 1;
 }
 
 int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid, int force)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     libxl_dominfo dominfo;
     char *dom_path;
     char *vm_path;
@@ -740,40 +740,40 @@ int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid, int force)
         return rc;
     }
 
-    switch (libxl__domain_type(&gc, domid)) {
+    switch (libxl__domain_type(gc, domid)) {
     case LIBXL_DOMAIN_TYPE_HVM:
         dm_present = 1;
         break;
     case LIBXL_DOMAIN_TYPE_PV:
-        pid = libxl__xs_read(&gc, XBT_NULL, libxl__sprintf(&gc, "/local/domain/%d/image/device-model-pid", domid));
+        pid = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "/local/domain/%d/image/device-model-pid", domid));
         dm_present = (pid != NULL);
         break;
     default:
         abort();
     }
 
-    dom_path = libxl__xs_get_dompath(&gc, domid);
+    dom_path = libxl__xs_get_dompath(gc, domid);
     if (!dom_path) {
         rc = ERROR_FAIL;
         goto out;
     }
 
-    if (libxl__device_pci_destroy_all(&gc, domid) < 0)
+    if (libxl__device_pci_destroy_all(gc, domid) < 0)
         LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "pci shutdown failed for domid %d", domid);
     rc = xc_domain_pause(ctx->xch, domid);
     if (rc < 0) {
         LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, rc, "xc_domain_pause failed for %d", domid);
     }
     if (dm_present) {
-        if (libxl__destroy_device_model(&gc, domid) < 0)
+        if (libxl__destroy_device_model(gc, domid) < 0)
             LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "libxl__destroy_device_model failed for %d", domid);
 
-        libxl__qmp_cleanup(&gc, domid);
+        libxl__qmp_cleanup(gc, domid);
     }
-    if (libxl__devices_destroy(&gc, domid, force) < 0)
+    if (libxl__devices_destroy(gc, domid, force) < 0)
         LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "libxl_devices_dispose failed for %d", domid);
 
-    vm_path = libxl__xs_read(&gc, XBT_NULL, libxl__sprintf(&gc, "%s/vm", dom_path));
+    vm_path = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/vm", dom_path));
     if (vm_path)
         if (!xs_rm(ctx->xsh, XBT_NULL, vm_path))
             LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "xs_rm failed for %s", vm_path);
@@ -781,9 +781,9 @@ int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid, int force)
     if (!xs_rm(ctx->xsh, XBT_NULL, dom_path))
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "xs_rm failed for %s", dom_path);
 
-    xs_rm(ctx->xsh, XBT_NULL, libxl__xs_libxl_path(&gc, domid));
+    xs_rm(ctx->xsh, XBT_NULL, libxl__xs_libxl_path(gc, domid));
 
-    libxl__userdata_destroyall(&gc, domid);
+    libxl__userdata_destroyall(gc, domid);
 
     rc = xc_domain_destroy(ctx->xch, domid);
     if (rc < 0) {
@@ -793,16 +793,16 @@ int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid, int force)
     }
     rc = 0;
 out:
-    libxl__free_all(&gc);
+    GC_FREE;
     return rc;
 }
 
 int libxl_console_exec(libxl_ctx *ctx, uint32_t domid, int cons_num, libxl_console_type type)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
-    char *p = libxl__sprintf(&gc, "%s/xenconsole", libxl_private_bindir_path());
-    char *domid_s = libxl__sprintf(&gc, "%d", domid);
-    char *cons_num_s = libxl__sprintf(&gc, "%d", cons_num);
+    GC_INIT(ctx);
+    char *p = libxl__sprintf(gc, "%s/xenconsole", libxl_private_bindir_path());
+    char *domid_s = libxl__sprintf(gc, "%d", domid);
+    char *cons_num_s = libxl__sprintf(gc, "%d", cons_num);
     char *cons_type_s;
 
     switch (type) {
@@ -819,20 +819,20 @@ int libxl_console_exec(libxl_ctx *ctx, uint32_t domid, int cons_num, libxl_conso
     execl(p, p, domid_s, "--num", cons_num_s, "--type", cons_type_s, (void *)NULL);
 
 out:
-    libxl__free_all(&gc);
+    GC_FREE;
     return ERROR_FAIL;
 }
 
 int libxl_primary_console_exec(libxl_ctx *ctx, uint32_t domid_vm)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     uint32_t stubdomid = libxl_get_stubdom_id(ctx, domid_vm);
     int rc;
     if (stubdomid)
         rc = libxl_console_exec(ctx, stubdomid,
                                 STUBDOM_CONSOLE_SERIAL, LIBXL_CONSOLE_TYPE_PV);
     else {
-        switch (libxl__domain_type(&gc, domid_vm)) {
+        switch (libxl__domain_type(gc, domid_vm)) {
         case LIBXL_DOMAIN_TYPE_HVM:
             rc = libxl_console_exec(ctx, domid_vm, 0, LIBXL_CONSOLE_TYPE_SERIAL);
             break;
@@ -843,13 +843,13 @@ int libxl_primary_console_exec(libxl_ctx *ctx, uint32_t domid_vm)
             abort();
         }
     }
-    libxl__free_all(&gc);
+    GC_FREE;
     return rc;
 }
 
 int libxl_vncviewer_exec(libxl_ctx *ctx, uint32_t domid, int autopass)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     const char *vnc_port;
     const char *vnc_listen = NULL, *vnc_pass = NULL;
     int port = 0, autopass_fd = -1;
@@ -860,19 +860,19 @@ int libxl_vncviewer_exec(libxl_ctx *ctx, uint32_t domid, int autopass)
         NULL,
     };
 
-    vnc_port = libxl__xs_read(&gc, XBT_NULL,
-                            libxl__sprintf(&gc,
+    vnc_port = libxl__xs_read(gc, XBT_NULL,
+                            libxl__sprintf(gc,
                             "/local/domain/%d/console/vnc-port", domid));
     if ( vnc_port )
         port = atoi(vnc_port) - 5900;
 
-    vnc_listen = libxl__xs_read(&gc, XBT_NULL,
-                                libxl__sprintf(&gc,
+    vnc_listen = libxl__xs_read(gc, XBT_NULL,
+                                libxl__sprintf(gc,
                             "/local/domain/%d/console/vnc-listen", domid));
 
     if ( autopass )
-        vnc_pass = libxl__xs_read(&gc, XBT_NULL,
-                                  libxl__sprintf(&gc,
+        vnc_pass = libxl__xs_read(gc, XBT_NULL,
+                                  libxl__sprintf(gc,
                             "/local/domain/%d/console/vnc-pass", domid));
 
     if ( NULL == vnc_listen )
@@ -881,7 +881,7 @@ int libxl_vncviewer_exec(libxl_ctx *ctx, uint32_t domid, int autopass)
     if ( (vnc_bin = getenv("VNCVIEWER")) )
         args[0] = vnc_bin;
 
-    args[1] = libxl__sprintf(&gc, "%s:%d", vnc_listen, port);
+    args[1] = libxl__sprintf(gc, "%s:%d", vnc_listen, port);
 
     if ( vnc_pass ) {
         char tmpname[] = "/tmp/vncautopass.XXXXXX";
@@ -916,7 +916,7 @@ int libxl_vncviewer_exec(libxl_ctx *ctx, uint32_t domid, int autopass)
     abort();
 
  x_fail:
-    libxl__free_all(&gc);
+    GC_FREE;
     return ERROR_FAIL;
 }
 
@@ -970,17 +970,17 @@ static int libxl__device_from_disk(libxl__gc *gc, uint32_t domid,
 
 int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *disk)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     flexarray_t *front;
     flexarray_t *back;
     char *dev;
     libxl__device device;
     int major, minor, rc;
 
-    rc = libxl__device_disk_set_backend(&gc, disk);
+    rc = libxl__device_disk_set_backend(gc, disk);
     if (rc) goto out;
 
-    rc = libxl__device_disk_set_backend(&gc, disk);
+    rc = libxl__device_disk_set_backend(gc, disk);
     if (rc) goto out;
 
     front = flexarray_make(16, 1);
@@ -1001,7 +1001,7 @@ int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *dis
         goto out_free;
     }
 
-    rc = libxl__device_from_disk(&gc, domid, disk, &device);
+    rc = libxl__device_from_disk(gc, domid, disk, &device);
     if (rc != 0) {
         LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Invalid or unsupported"
                " virtual disk identifier %s", disk->vdev);
@@ -1014,7 +1014,7 @@ int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *dis
     do_backend_phy:
             libxl__device_physdisk_major_minor(dev, &major, &minor);
             flexarray_append(back, "physical-device");
-            flexarray_append(back, libxl__sprintf(&gc, "%x:%x", major, minor));
+            flexarray_append(back, libxl__sprintf(gc, "%x:%x", major, minor));
 
             flexarray_append(back, "params");
             flexarray_append(back, dev);
@@ -1022,13 +1022,13 @@ int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *dis
             assert(device.backend_kind == LIBXL__DEVICE_KIND_VBD);
             break;
         case LIBXL_DISK_BACKEND_TAP:
-            dev = libxl__blktap_devpath(&gc, disk->pdev_path, disk->format);
+            dev = libxl__blktap_devpath(gc, disk->pdev_path, disk->format);
             if (!dev) {
                 rc = ERROR_FAIL;
                 goto out_free;
             }
             flexarray_append(back, "tapdisk-params");
-            flexarray_append(back, libxl__sprintf(&gc, "%s:%s",
+            flexarray_append(back, libxl__sprintf(gc, "%s:%s",
                 libxl__device_disk_string_of_format(disk->format),
                 disk->pdev_path));
 
@@ -1036,7 +1036,7 @@ int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *dis
             goto do_backend_phy;
         case LIBXL_DISK_BACKEND_QDISK:
             flexarray_append(back, "params");
-            flexarray_append(back, libxl__sprintf(&gc, "%s:%s",
+            flexarray_append(back, libxl__sprintf(gc, "%s:%s",
                           libxl__device_disk_string_of_format(disk->format), disk->pdev_path));
             assert(device.backend_kind == LIBXL__DEVICE_KIND_QDISK);
             break;
@@ -1047,15 +1047,15 @@ int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *dis
     }
 
     flexarray_append(back, "frontend-id");
-    flexarray_append(back, libxl__sprintf(&gc, "%d", domid));
+    flexarray_append(back, libxl__sprintf(gc, "%d", domid));
     flexarray_append(back, "online");
     flexarray_append(back, "1");
     flexarray_append(back, "removable");
-    flexarray_append(back, libxl__sprintf(&gc, "%d", (disk->removable) ? 1 : 0));
+    flexarray_append(back, libxl__sprintf(gc, "%d", (disk->removable) ? 1 : 0));
     flexarray_append(back, "bootable");
-    flexarray_append(back, libxl__sprintf(&gc, "%d", 1));
+    flexarray_append(back, libxl__sprintf(gc, "%d", 1));
     flexarray_append(back, "state");
-    flexarray_append(back, libxl__sprintf(&gc, "%d", 1));
+    flexarray_append(back, libxl__sprintf(gc, "%d", 1));
     flexarray_append(back, "dev");
     flexarray_append(back, disk->vdev);
     flexarray_append(back, "type");
@@ -1066,17 +1066,17 @@ int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *dis
     flexarray_append(back, disk->is_cdrom ? "cdrom" : "disk");
 
     flexarray_append(front, "backend-id");
-    flexarray_append(front, libxl__sprintf(&gc, "%d", disk->backend_domid));
+    flexarray_append(front, libxl__sprintf(gc, "%d", disk->backend_domid));
     flexarray_append(front, "state");
-    flexarray_append(front, libxl__sprintf(&gc, "%d", 1));
+    flexarray_append(front, libxl__sprintf(gc, "%d", 1));
     flexarray_append(front, "virtual-device");
-    flexarray_append(front, libxl__sprintf(&gc, "%d", device.devid));
+    flexarray_append(front, libxl__sprintf(gc, "%d", device.devid));
     flexarray_append(front, "device-type");
     flexarray_append(front, disk->is_cdrom ? "cdrom" : "disk");
 
-    libxl__device_generic_add(&gc, &device,
-                             libxl__xs_kvs_of_flexarray(&gc, back, back->count),
-                             libxl__xs_kvs_of_flexarray(&gc, front, front->count));
+    libxl__device_generic_add(gc, &device,
+                             libxl__xs_kvs_of_flexarray(gc, back, back->count),
+                             libxl__xs_kvs_of_flexarray(gc, front, front->count));
 
     rc = 0;
 
@@ -1084,39 +1084,39 @@ out_free:
     flexarray_free(back);
     flexarray_free(front);
 out:
-    libxl__free_all(&gc);
+    GC_FREE;
     return rc;
 }
 
 int libxl_device_disk_remove(libxl_ctx *ctx, uint32_t domid,
                              libxl_device_disk *disk)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     libxl__device device;
     int rc;
 
-    rc = libxl__device_from_disk(&gc, domid, disk, &device);
+    rc = libxl__device_from_disk(gc, domid, disk, &device);
     if (rc != 0) goto out;
 
-    rc = libxl__device_remove(&gc, &device, 1);
+    rc = libxl__device_remove(gc, &device, 1);
 out:
-    libxl__free_all(&gc);
+    GC_FREE;
     return rc;
 }
 
 int libxl_device_disk_destroy(libxl_ctx *ctx, uint32_t domid,
                               libxl_device_disk *disk)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     libxl__device device;
     int rc;
 
-    rc = libxl__device_from_disk(&gc, domid, disk, &device);
+    rc = libxl__device_from_disk(gc, domid, disk, &device);
     if (rc != 0) goto out;
 
-    rc = libxl__device_destroy(&gc, &device);
+    rc = libxl__device_destroy(gc, &device);
 out:
-    libxl__free_all(&gc);
+    GC_FREE;
     return rc;
 }
 
@@ -1168,27 +1168,27 @@ static void libxl__device_disk_from_xs_be(libxl__gc *gc,
 int libxl_devid_to_device_disk(libxl_ctx *ctx, uint32_t domid,
                                int devid, libxl_device_disk *disk)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     char *dompath, *path;
     int rc = ERROR_FAIL;
 
     libxl_device_disk_init(ctx, disk);
 
-    dompath = libxl__xs_get_dompath(&gc, domid);
+    dompath = libxl__xs_get_dompath(gc, domid);
     if (!dompath) {
         goto out;
     }
-    path = libxl__xs_read(&gc, XBT_NULL,
-                          libxl__sprintf(&gc, "%s/device/vbd/%d/backend",
+    path = libxl__xs_read(gc, XBT_NULL,
+                          libxl__sprintf(gc, "%s/device/vbd/%d/backend",
                                          dompath, devid));
     if (!path)
         goto out;
 
-    libxl__device_disk_from_xs_be(&gc, path, disk);
+    libxl__device_disk_from_xs_be(gc, path, disk);
 
     rc = 0;
 out:
-    libxl__free_all(&gc);
+    GC_FREE;
     return rc;
 }
 
@@ -1228,22 +1228,22 @@ static int libxl__append_disk_list_of_type(libxl__gc *gc,
 
 libxl_device_disk *libxl_device_disk_list(libxl_ctx *ctx, uint32_t domid, int *num)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     libxl_device_disk *disks = NULL;
     int rc;
 
     *num = 0;
 
-    rc = libxl__append_disk_list_of_type(&gc, domid, "vbd", &disks, num);
+    rc = libxl__append_disk_list_of_type(gc, domid, "vbd", &disks, num);
     if (rc) goto out_err;
 
-    rc = libxl__append_disk_list_of_type(&gc, domid, "tap", &disks, num);
+    rc = libxl__append_disk_list_of_type(gc, domid, "tap", &disks, num);
     if (rc) goto out_err;
 
-    rc = libxl__append_disk_list_of_type(&gc, domid, "qdisk", &disks, num);
+    rc = libxl__append_disk_list_of_type(gc, domid, "qdisk", &disks, num);
     if (rc) goto out_err;
 
-    libxl__free_all(&gc);
+    GC_FREE;
     return disks;
 
 out_err:
@@ -1259,35 +1259,35 @@ out_err:
 int libxl_device_disk_getinfo(libxl_ctx *ctx, uint32_t domid,
                               libxl_device_disk *disk, libxl_diskinfo *diskinfo)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     char *dompath, *diskpath;
     char *val;
 
-    dompath = libxl__xs_get_dompath(&gc, domid);
+    dompath = libxl__xs_get_dompath(gc, domid);
     diskinfo->devid = libxl__device_disk_dev_number(disk->vdev, NULL, NULL);
 
     /* tap devices entries in xenstore are written as vbd devices. */
-    diskpath = libxl__sprintf(&gc, "%s/device/vbd/%d", dompath, diskinfo->devid);
+    diskpath = libxl__sprintf(gc, "%s/device/vbd/%d", dompath, diskinfo->devid);
     diskinfo->backend = xs_read(ctx->xsh, XBT_NULL,
-                                libxl__sprintf(&gc, "%s/backend", diskpath), NULL);
+                                libxl__sprintf(gc, "%s/backend", diskpath), NULL);
     if (!diskinfo->backend) {
-        libxl__free_all(&gc);
+        GC_FREE;
         return ERROR_FAIL;
     }
-    val = libxl__xs_read(&gc, XBT_NULL, libxl__sprintf(&gc, "%s/backend-id", diskpath));
+    val = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/backend-id", diskpath));
     diskinfo->backend_id = val ? strtoul(val, NULL, 10) : -1;
-    val = libxl__xs_read(&gc, XBT_NULL, libxl__sprintf(&gc, "%s/state", diskpath));
+    val = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/state", diskpath));
     diskinfo->state = val ? strtoul(val, NULL, 10) : -1;
-    val = libxl__xs_read(&gc, XBT_NULL, libxl__sprintf(&gc, "%s/event-channel", diskpath));
+    val = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/event-channel", diskpath));
     diskinfo->evtch = val ? strtoul(val, NULL, 10) : -1;
-    val = libxl__xs_read(&gc, XBT_NULL, libxl__sprintf(&gc, "%s/ring-ref", diskpath));
+    val = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/ring-ref", diskpath));
     diskinfo->rref = val ? strtoul(val, NULL, 10) : -1;
     diskinfo->frontend = xs_read(ctx->xsh, XBT_NULL,
-                                 libxl__sprintf(&gc, "%s/frontend", diskinfo->backend), NULL);
-    val = libxl__xs_read(&gc, XBT_NULL, libxl__sprintf(&gc, "%s/frontend-id", diskinfo->backend));
+                                 libxl__sprintf(gc, "%s/frontend", diskinfo->backend), NULL);
+    val = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/frontend-id", diskinfo->backend));
     diskinfo->frontend_id = val ? strtoul(val, NULL, 10) : -1;
 
-    libxl__free_all(&gc);
+    GC_FREE;
     return 0;
 }
 
@@ -1331,12 +1331,12 @@ out:
 
 char * libxl_device_disk_local_attach(libxl_ctx *ctx, libxl_device_disk *disk)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     char *dev = NULL;
     char *ret = NULL;
     int rc;
 
-    rc = libxl__device_disk_set_backend(&gc, disk);
+    rc = libxl__device_disk_set_backend(gc, disk);
     if (rc) goto out;
 
     switch (disk->backend) {
@@ -1355,7 +1355,7 @@ char * libxl_device_disk_local_attach(libxl_ctx *ctx, libxl_device_disk *disk)
                 dev = disk->pdev_path;
                 break;
             case LIBXL_DISK_FORMAT_VHD:
-                dev = libxl__blktap_devpath(&gc, disk->pdev_path,
+                dev = libxl__blktap_devpath(gc, disk->pdev_path,
                                             disk->format);
                 break;
             case LIBXL_DISK_FORMAT_QCOW:
@@ -1386,7 +1386,7 @@ char * libxl_device_disk_local_attach(libxl_ctx *ctx, libxl_device_disk *disk)
  out:
     if (dev != NULL)
         ret = strdup(dev);
-    libxl__free_all(&gc);
+    GC_FREE;
     return ret;
 }
 
@@ -1448,7 +1448,7 @@ static int libxl__device_from_nic(libxl__gc *gc, uint32_t domid,
 
 int libxl_device_nic_add(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     flexarray_t *front;
     flexarray_t *back;
     libxl__device device;
@@ -1467,59 +1467,59 @@ int libxl_device_nic_add(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic)
     }
 
     if (nic->devid == -1) {
-        if (!(dompath = libxl__xs_get_dompath(&gc, domid))) {
+        if (!(dompath = libxl__xs_get_dompath(gc, domid))) {
             rc = ERROR_FAIL;
             goto out_free;
         }
-        if (!(l = libxl__xs_directory(&gc, XBT_NULL,
-                                     libxl__sprintf(&gc, "%s/device/vif", dompath), &nb))) {
+        if (!(l = libxl__xs_directory(gc, XBT_NULL,
+                                     libxl__sprintf(gc, "%s/device/vif", dompath), &nb))) {
             nic->devid = 0;
         } else {
             nic->devid = strtoul(l[nb - 1], NULL, 10) + 1;
         }
     }
 
-    rc = libxl__device_from_nic(&gc, domid, nic, &device);
+    rc = libxl__device_from_nic(gc, domid, nic, &device);
     if ( rc != 0 ) goto out_free;
 
     flexarray_append(back, "frontend-id");
-    flexarray_append(back, libxl__sprintf(&gc, "%d", domid));
+    flexarray_append(back, libxl__sprintf(gc, "%d", domid));
     flexarray_append(back, "online");
     flexarray_append(back, "1");
     flexarray_append(back, "state");
-    flexarray_append(back, libxl__sprintf(&gc, "%d", 1));
+    flexarray_append(back, libxl__sprintf(gc, "%d", 1));
     if (nic->script) {
         flexarray_append(back, "script");
         flexarray_append(back, nic->script[0]=='/' ? nic->script
-                         : libxl__sprintf(&gc, "%s/%s",
+                         : libxl__sprintf(gc, "%s/%s",
                                           libxl_xen_script_dir_path(),
                                           nic->script));
     }
     flexarray_append(back, "mac");
-    flexarray_append(back,libxl__sprintf(&gc,
+    flexarray_append(back,libxl__sprintf(gc,
                                     LIBXL_MAC_FMT, LIBXL_MAC_BYTES(nic->mac)));
     if (nic->ip) {
         flexarray_append(back, "ip");
-        flexarray_append(back, libxl__strdup(&gc, nic->ip));
+        flexarray_append(back, libxl__strdup(gc, nic->ip));
     }
 
     flexarray_append(back, "bridge");
-    flexarray_append(back, libxl__strdup(&gc, nic->bridge));
+    flexarray_append(back, libxl__strdup(gc, nic->bridge));
     flexarray_append(back, "handle");
-    flexarray_append(back, libxl__sprintf(&gc, "%d", nic->devid));
+    flexarray_append(back, libxl__sprintf(gc, "%d", nic->devid));
 
     flexarray_append(front, "backend-id");
-    flexarray_append(front, libxl__sprintf(&gc, "%d", nic->backend_domid));
+    flexarray_append(front, libxl__sprintf(gc, "%d", nic->backend_domid));
     flexarray_append(front, "state");
-    flexarray_append(front, libxl__sprintf(&gc, "%d", 1));
+    flexarray_append(front, libxl__sprintf(gc, "%d", 1));
     flexarray_append(front, "handle");
-    flexarray_append(front, libxl__sprintf(&gc, "%d", nic->devid));
+    flexarray_append(front, libxl__sprintf(gc, "%d", nic->devid));
     flexarray_append(front, "mac");
-    flexarray_append(front, libxl__sprintf(&gc,
+    flexarray_append(front, libxl__sprintf(gc,
                                     LIBXL_MAC_FMT, LIBXL_MAC_BYTES(nic->mac)));
-    libxl__device_generic_add(&gc, &device,
-                             libxl__xs_kvs_of_flexarray(&gc, back, back->count),
-                             libxl__xs_kvs_of_flexarray(&gc, front, front->count));
+    libxl__device_generic_add(gc, &device,
+                             libxl__xs_kvs_of_flexarray(gc, back, back->count),
+                             libxl__xs_kvs_of_flexarray(gc, front, front->count));
 
     /* FIXME: wait for plug */
     rc = 0;
@@ -1527,39 +1527,39 @@ out_free:
     flexarray_free(back);
     flexarray_free(front);
 out:
-    libxl__free_all(&gc);
+    GC_FREE;
     return rc;
 }
 
 int libxl_device_nic_remove(libxl_ctx *ctx, uint32_t domid,
                             libxl_device_nic *nic)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     libxl__device device;
     int rc;
 
-    rc = libxl__device_from_nic(&gc, domid, nic, &device);
+    rc = libxl__device_from_nic(gc, domid, nic, &device);
     if (rc != 0) goto out;
 
-    rc = libxl__device_remove(&gc, &device, 1);
+    rc = libxl__device_remove(gc, &device, 1);
 out:
-    libxl__free_all(&gc);
+    GC_FREE;
     return rc;
 }
 
 int libxl_device_nic_destroy(libxl_ctx *ctx, uint32_t domid,
                                   libxl_device_nic *nic)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     libxl__device device;
     int rc;
 
-    rc = libxl__device_from_nic(&gc, domid, nic, &device);
+    rc = libxl__device_from_nic(gc, domid, nic, &device);
     if (rc != 0) goto out;
 
-    rc = libxl__device_destroy(&gc, &device);
+    rc = libxl__device_destroy(gc, &device);
 out:
-    libxl__free_all(&gc);
+    GC_FREE;
     return rc;
 }
 
@@ -1607,26 +1607,26 @@ static void libxl__device_nic_from_xs_be(libxl__gc *gc,
 int libxl_devid_to_device_nic(libxl_ctx *ctx, uint32_t domid,
                               int devid, libxl_device_nic *nic)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     char *dompath, *path;
     int rc = ERROR_FAIL;
 
     memset(nic, 0, sizeof (libxl_device_nic));
-    dompath = libxl__xs_get_dompath(&gc, domid);
+    dompath = libxl__xs_get_dompath(gc, domid);
     if (!dompath)
         goto out;
 
-    path = libxl__xs_read(&gc, XBT_NULL,
-                          libxl__sprintf(&gc, "%s/device/vif/%d/backend",
+    path = libxl__xs_read(gc, XBT_NULL,
+                          libxl__sprintf(gc, "%s/device/vif/%d/backend",
                                          dompath, devid));
     if (!path)
         goto out;
 
-    libxl__device_nic_from_xs_be(&gc, path, nic);
+    libxl__device_nic_from_xs_be(gc, path, nic);
 
     rc = 0;
 out:
-    libxl__free_all(&gc);
+    GC_FREE;
     return rc;
 }
 
@@ -1665,16 +1665,16 @@ static int libxl__append_nic_list_of_type(libxl__gc *gc,
 
 libxl_device_nic *libxl_device_nic_list(libxl_ctx *ctx, uint32_t domid, int *num)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     libxl_device_nic *nics = NULL;
     int rc;
 
     *num = 0;
 
-    rc = libxl__append_nic_list_of_type(&gc, domid, "vif", &nics, num);
+    rc = libxl__append_nic_list_of_type(gc, domid, "vif", &nics, num);
     if (rc) goto out_err;
 
-    libxl__free_all(&gc);
+    GC_FREE;
     return nics;
 
 out_err:
@@ -1690,36 +1690,36 @@ out_err:
 int libxl_device_nic_getinfo(libxl_ctx *ctx, uint32_t domid,
                               libxl_device_nic *nic, libxl_nicinfo *nicinfo)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     char *dompath, *nicpath;
     char *val;
 
-    dompath = libxl__xs_get_dompath(&gc, domid);
+    dompath = libxl__xs_get_dompath(gc, domid);
     nicinfo->devid = nic->devid;
 
-    nicpath = libxl__sprintf(&gc, "%s/device/vif/%d", dompath, nicinfo->devid);
+    nicpath = libxl__sprintf(gc, "%s/device/vif/%d", dompath, nicinfo->devid);
     nicinfo->backend = xs_read(ctx->xsh, XBT_NULL,
-                                libxl__sprintf(&gc, "%s/backend", nicpath), NULL);
+                                libxl__sprintf(gc, "%s/backend", nicpath), NULL);
     if (!nicinfo->backend) {
-        libxl__free_all(&gc);
+        GC_FREE;
         return ERROR_FAIL;
     }
-    val = libxl__xs_read(&gc, XBT_NULL, libxl__sprintf(&gc, "%s/backend-id", nicpath));
+    val = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/backend-id", nicpath));
     nicinfo->backend_id = val ? strtoul(val, NULL, 10) : -1;
-    val = libxl__xs_read(&gc, XBT_NULL, libxl__sprintf(&gc, "%s/state", nicpath));
+    val = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/state", nicpath));
     nicinfo->state = val ? strtoul(val, NULL, 10) : -1;
-    val = libxl__xs_read(&gc, XBT_NULL, libxl__sprintf(&gc, "%s/event-channel", nicpath));
+    val = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/event-channel", nicpath));
     nicinfo->evtch = val ? strtoul(val, NULL, 10) : -1;
-    val = libxl__xs_read(&gc, XBT_NULL, libxl__sprintf(&gc, "%s/tx-ring-ref", nicpath));
+    val = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/tx-ring-ref", nicpath));
     nicinfo->rref_tx = val ? strtoul(val, NULL, 10) : -1;
-    val = libxl__xs_read(&gc, XBT_NULL, libxl__sprintf(&gc, "%s/rx-ring-ref", nicpath));
+    val = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/rx-ring-ref", nicpath));
     nicinfo->rref_rx = val ? strtoul(val, NULL, 10) : -1;
     nicinfo->frontend = xs_read(ctx->xsh, XBT_NULL,
-                                 libxl__sprintf(&gc, "%s/frontend", nicinfo->backend), NULL);
-    val = libxl__xs_read(&gc, XBT_NULL, libxl__sprintf(&gc, "%s/frontend-id", nicinfo->backend));
+                                 libxl__sprintf(gc, "%s/frontend", nicinfo->backend), NULL);
+    val = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/frontend-id", nicinfo->backend));
     nicinfo->frontend_id = val ? strtoul(val, NULL, 10) : -1;
 
-    libxl__free_all(&gc);
+    GC_FREE;
     return 0;
 }
 
@@ -1825,7 +1825,7 @@ static int libxl__device_from_vkb(libxl__gc *gc, uint32_t domid,
 
 int libxl_device_vkb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vkb *vkb)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     flexarray_t *front;
     flexarray_t *back;
     libxl__device device;
@@ -1842,64 +1842,64 @@ int libxl_device_vkb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vkb *vkb)
         goto out_free;
     }
 
-    rc = libxl__device_from_vkb(&gc, domid, vkb, &device);
+    rc = libxl__device_from_vkb(gc, domid, vkb, &device);
     if (rc != 0) goto out_free;
 
     flexarray_append(back, "frontend-id");
-    flexarray_append(back, libxl__sprintf(&gc, "%d", domid));
+    flexarray_append(back, libxl__sprintf(gc, "%d", domid));
     flexarray_append(back, "online");
     flexarray_append(back, "1");
     flexarray_append(back, "state");
-    flexarray_append(back, libxl__sprintf(&gc, "%d", 1));
+    flexarray_append(back, libxl__sprintf(gc, "%d", 1));
     flexarray_append(back, "domain");
-    flexarray_append(back, libxl__domid_to_name(&gc, domid));
+    flexarray_append(back, libxl__domid_to_name(gc, domid));
 
     flexarray_append(front, "backend-id");
-    flexarray_append(front, libxl__sprintf(&gc, "%d", vkb->backend_domid));
+    flexarray_append(front, libxl__sprintf(gc, "%d", vkb->backend_domid));
     flexarray_append(front, "state");
-    flexarray_append(front, libxl__sprintf(&gc, "%d", 1));
+    flexarray_append(front, libxl__sprintf(gc, "%d", 1));
 
-    libxl__device_generic_add(&gc, &device,
-                             libxl__xs_kvs_of_flexarray(&gc, back, back->count),
-                             libxl__xs_kvs_of_flexarray(&gc, front, front->count));
+    libxl__device_generic_add(gc, &device,
+                             libxl__xs_kvs_of_flexarray(gc, back, back->count),
+                             libxl__xs_kvs_of_flexarray(gc, front, front->count));
     rc = 0;
 out_free:
     flexarray_free(back);
     flexarray_free(front);
 out:
-    libxl__free_all(&gc);
+    GC_FREE;
     return rc;
 }
 
 int libxl_device_vkb_remove(libxl_ctx *ctx, uint32_t domid,
                             libxl_device_vkb *vkb)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     libxl__device device;
     int rc;
 
-    rc = libxl__device_from_vkb(&gc, domid, vkb, &device);
+    rc = libxl__device_from_vkb(gc, domid, vkb, &device);
     if (rc != 0) goto out;
 
-    rc = libxl__device_remove(&gc, &device, 1);
+    rc = libxl__device_remove(gc, &device, 1);
 out:
-    libxl__free_all(&gc);
+    GC_FREE;
     return rc;
 }
 
 int libxl_device_vkb_destroy(libxl_ctx *ctx, uint32_t domid,
                                   libxl_device_vkb *vkb)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     libxl__device device;
     int rc;
 
-    rc = libxl__device_from_vkb(&gc, domid, vkb, &device);
+    rc = libxl__device_from_vkb(gc, domid, vkb, &device);
     if (rc != 0) goto out;
 
-    rc = libxl__device_destroy(&gc, &device);
+    rc = libxl__device_destroy(gc, &device);
 out:
-    libxl__free_all(&gc);
+    GC_FREE;
     return rc;
 }
 
@@ -1935,7 +1935,7 @@ static int libxl__device_from_vfb(libxl__gc *gc, uint32_t domid,
 
 int libxl_device_vfb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vfb *vfb)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     flexarray_t *front;
     flexarray_t *back;
     libxl__device device;
@@ -1952,20 +1952,20 @@ int libxl_device_vfb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vfb *vfb)
         goto out_free;
     }
 
-    rc = libxl__device_from_vfb(&gc, domid, vfb, &device);
+    rc = libxl__device_from_vfb(gc, domid, vfb, &device);
     if (rc != 0) goto out_free;
 
-    flexarray_append_pair(back, "frontend-id", libxl__sprintf(&gc, "%d", domid));
+    flexarray_append_pair(back, "frontend-id", libxl__sprintf(gc, "%d", domid));
     flexarray_append_pair(back, "online", "1");
-    flexarray_append_pair(back, "state", libxl__sprintf(&gc, "%d", 1));
-    flexarray_append_pair(back, "domain", libxl__domid_to_name(&gc, domid));
-    flexarray_append_pair(back, "vnc", libxl__sprintf(&gc, "%d", vfb->vnc));
+    flexarray_append_pair(back, "state", libxl__sprintf(gc, "%d", 1));
+    flexarray_append_pair(back, "domain", libxl__domid_to_name(gc, domid));
+    flexarray_append_pair(back, "vnc", libxl__sprintf(gc, "%d", vfb->vnc));
     flexarray_append_pair(back, "vnclisten", vfb->vnclisten);
     flexarray_append_pair(back, "vncpasswd", vfb->vncpasswd);
-    flexarray_append_pair(back, "vncdisplay", libxl__sprintf(&gc, "%d", vfb->vncdisplay));
-    flexarray_append_pair(back, "vncunused", libxl__sprintf(&gc, "%d", vfb->vncunused));
-    flexarray_append_pair(back, "sdl", libxl__sprintf(&gc, "%d", vfb->sdl));
-    flexarray_append_pair(back, "opengl", libxl__sprintf(&gc, "%d", vfb->opengl));
+    flexarray_append_pair(back, "vncdisplay", libxl__sprintf(gc, "%d", vfb->vncdisplay));
+    flexarray_append_pair(back, "vncunused", libxl__sprintf(gc, "%d", vfb->vncunused));
+    flexarray_append_pair(back, "sdl", libxl__sprintf(gc, "%d", vfb->sdl));
+    flexarray_append_pair(back, "opengl", libxl__sprintf(gc, "%d", vfb->opengl));
     if (vfb->xauthority) {
         flexarray_append_pair(back, "xauthority", vfb->xauthority);
     }
@@ -1973,50 +1973,50 @@ int libxl_device_vfb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vfb *vfb)
         flexarray_append_pair(back, "display", vfb->display);
     }
 
-    flexarray_append_pair(front, "backend-id", libxl__sprintf(&gc, "%d", vfb->backend_domid));
-    flexarray_append_pair(front, "state", libxl__sprintf(&gc, "%d", 1));
+    flexarray_append_pair(front, "backend-id", libxl__sprintf(gc, "%d", vfb->backend_domid));
+    flexarray_append_pair(front, "state", libxl__sprintf(gc, "%d", 1));
 
-    libxl__device_generic_add(&gc, &device,
-                             libxl__xs_kvs_of_flexarray(&gc, back, back->count),
-                             libxl__xs_kvs_of_flexarray(&gc, front, front->count));
+    libxl__device_generic_add(gc, &device,
+                             libxl__xs_kvs_of_flexarray(gc, back, back->count),
+                             libxl__xs_kvs_of_flexarray(gc, front, front->count));
     rc = 0;
 out_free:
     flexarray_free(front);
     flexarray_free(back);
 out:
-    libxl__free_all(&gc);
+    GC_FREE;
     return rc;
 }
 
 int libxl_device_vfb_remove(libxl_ctx *ctx, uint32_t domid,
                             libxl_device_vfb *vfb)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     libxl__device device;
     int rc;
 
-    rc = libxl__device_from_vfb(&gc, domid, vfb, &device);
+    rc = libxl__device_from_vfb(gc, domid, vfb, &device);
     if (rc != 0) goto out;
 
-    rc = libxl__device_remove(&gc, &device, 1);
+    rc = libxl__device_remove(gc, &device, 1);
 out:
-    libxl__free_all(&gc);
+    GC_FREE;
     return rc;
 }
 
 int libxl_device_vfb_destroy(libxl_ctx *ctx, uint32_t domid,
                                   libxl_device_vfb *vfb)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     libxl__device device;
     int rc;
 
-    rc = libxl__device_from_vfb(&gc, domid, vfb, &device);
+    rc = libxl__device_from_vfb(gc, domid, vfb, &device);
     if (rc != 0) goto out;
 
-    rc = libxl__device_destroy(&gc, &device);
+    rc = libxl__device_destroy(gc, &device);
 out:
-    libxl__free_all(&gc);
+    GC_FREE;
     return rc;
 }
 
@@ -2024,13 +2024,13 @@ out:
 
 int libxl_domain_setmaxmem(libxl_ctx *ctx, uint32_t domid, uint32_t max_memkb)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     char *mem, *endptr;
     uint32_t memorykb;
-    char *dompath = libxl__xs_get_dompath(&gc, domid);
+    char *dompath = libxl__xs_get_dompath(gc, domid);
     int rc = 1;
 
-    mem = libxl__xs_read(&gc, XBT_NULL, libxl__sprintf(&gc, "%s/memory/target", dompath));
+    mem = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/memory/target", dompath));
     if (!mem) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "cannot get memory info from %s/memory/target\n", dompath);
         goto out;
@@ -2055,7 +2055,7 @@ int libxl_domain_setmaxmem(libxl_ctx *ctx, uint32_t domid, uint32_t max_memkb)
 
     rc = 0;
 out:
-    libxl__free_all(&gc);
+    GC_FREE;
     return rc;
 }
 
@@ -2163,12 +2163,12 @@ retry:
 int libxl_set_memory_target(libxl_ctx *ctx, uint32_t domid,
         int32_t target_memkb, int relative, int enforce)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     int rc = 1, abort = 0;
     uint32_t memorykb = 0, videoram = 0;
     uint32_t current_target_memkb = 0, new_target_memkb = 0;
     char *memmax, *endptr, *videoram_s = NULL, *target = NULL;
-    char *dompath = libxl__xs_get_dompath(&gc, domid);
+    char *dompath = libxl__xs_get_dompath(gc, domid);
     xc_domaininfo_t info;
     libxl_dominfo ptr;
     char *uuid;
@@ -2177,11 +2177,11 @@ int libxl_set_memory_target(libxl_ctx *ctx, uint32_t domid,
 retry_transaction:
     t = xs_transaction_start(ctx->xsh);
 
-    target = libxl__xs_read(&gc, t, libxl__sprintf(&gc,
+    target = libxl__xs_read(gc, t, libxl__sprintf(gc,
                 "%s/memory/target", dompath));
     if (!target && !domid) {
         xs_transaction_end(ctx->xsh, t, 1);
-        rc = libxl__fill_dom0_memory_info(&gc, &current_target_memkb);
+        rc = libxl__fill_dom0_memory_info(gc, &current_target_memkb);
         if (rc < 0) {
             abort = 1;
             goto out;
@@ -2203,7 +2203,7 @@ retry_transaction:
             goto out;
         }
     }
-    memmax = libxl__xs_read(&gc, t, libxl__sprintf(&gc,
+    memmax = libxl__xs_read(gc, t, libxl__sprintf(gc,
                 "%s/memory/static-max", dompath));
     if (!memmax) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
@@ -2243,7 +2243,7 @@ retry_transaction:
         abort = 1;
         goto out;
     }
-    videoram_s = libxl__xs_read(&gc, t, libxl__sprintf(&gc,
+    videoram_s = libxl__xs_read(gc, t, libxl__sprintf(gc,
                 "%s/memory/videoram", dompath));
     videoram = videoram_s ? atoi(videoram_s) : 0;
 
@@ -2272,7 +2272,7 @@ retry_transaction:
         goto out;
     }
 
-    libxl__xs_write(&gc, t, libxl__sprintf(&gc, "%s/memory/target",
+    libxl__xs_write(gc, t, libxl__sprintf(gc, "%s/memory/target",
                 dompath), "%"PRIu32, new_target_memkb);
     rc = xc_domain_getinfolist(ctx->xch, domid, 1, &info);
     if (rc != 1 || info.domain != domid) {
@@ -2280,8 +2280,8 @@ retry_transaction:
         goto out;
     }
     xcinfo2xlinfo(&info, &ptr);
-    uuid = libxl__uuid2string(&gc, ptr.uuid);
-    libxl__xs_write(&gc, t, libxl__sprintf(&gc, "/vm/%s/memory", uuid),
+    uuid = libxl__uuid2string(gc, ptr.uuid);
+    libxl__xs_write(gc, t, libxl__sprintf(gc, "/vm/%s/memory", uuid),
             "%"PRIu32, new_target_memkb / 1024);
 
 out:
@@ -2289,22 +2289,22 @@ out:
         if (errno == EAGAIN)
             goto retry_transaction;
 
-    libxl__free_all(&gc);
+    GC_FREE;
     return rc;
 }
 
 int libxl_get_memory_target(libxl_ctx *ctx, uint32_t domid, uint32_t *out_target)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     int rc = 1;
     char *target = NULL, *endptr = NULL;
-    char *dompath = libxl__xs_get_dompath(&gc, domid);
+    char *dompath = libxl__xs_get_dompath(gc, domid);
     uint32_t target_memkb;
 
-    target = libxl__xs_read(&gc, XBT_NULL, libxl__sprintf(&gc,
+    target = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc,
                 "%s/memory/target", dompath));
     if (!target && !domid) {
-        rc = libxl__fill_dom0_memory_info(&gc, &target_memkb);
+        rc = libxl__fill_dom0_memory_info(gc, &target_memkb);
         if (rc < 0)
             goto out;
     } else if (!target) {
@@ -2325,14 +2325,14 @@ int libxl_get_memory_target(libxl_ctx *ctx, uint32_t domid, uint32_t *out_target
     rc = 0;
 
 out:
-    libxl__free_all(&gc);
+    GC_FREE;
     return rc;
 }
 
 int libxl_domain_need_memory(libxl_ctx *ctx, libxl_domain_build_info *b_info,
         libxl_device_model_info *dm_info, uint32_t *need_memkb)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     int rc = ERROR_INVAL;
     *need_memkb = b_info->target_memkb;
     switch (b_info->type) {
@@ -2351,7 +2351,7 @@ int libxl_domain_need_memory(libxl_ctx *ctx, libxl_domain_build_info *b_info,
         *need_memkb += (2 * 1024) - (*need_memkb % (2 * 1024));
     rc = 0;
 out:
-    libxl__free_all(&gc);
+    GC_FREE;
     return rc;
 
 }
@@ -2361,12 +2361,12 @@ int libxl_get_free_memory(libxl_ctx *ctx, uint32_t *memkb)
     int rc = 0;
     libxl_physinfo info;
     uint32_t freemem_slack;
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
 
     rc = libxl_get_physinfo(ctx, &info);
     if (rc < 0)
         goto out;
-    rc = libxl__get_free_memory_slack(&gc, &freemem_slack);
+    rc = libxl__get_free_memory_slack(gc, &freemem_slack);
     if (rc < 0)
         goto out;
 
@@ -2376,7 +2376,7 @@ int libxl_get_free_memory(libxl_ctx *ctx, uint32_t *memkb)
         *memkb = 0;
 
 out:
-    libxl__free_all(&gc);
+    GC_FREE;
     return rc;
 }
 
@@ -2386,9 +2386,9 @@ int libxl_wait_for_free_memory(libxl_ctx *ctx, uint32_t domid, uint32_t
     int rc = 0;
     libxl_physinfo info;
     uint32_t freemem_slack;
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
 
-    rc = libxl__get_free_memory_slack(&gc, &freemem_slack);
+    rc = libxl__get_free_memory_slack(gc, &freemem_slack);
     if (rc < 0)
         goto out;
     while (wait_secs > 0) {
@@ -2405,7 +2405,7 @@ int libxl_wait_for_free_memory(libxl_ctx *ctx, uint32_t domid, uint32_t
     rc = ERROR_NOMEM;
 
 out:
-    libxl__free_all(&gc);
+    GC_FREE;
     return rc;
 }
 
@@ -2631,7 +2631,7 @@ int libxl_set_vcpuaffinity(libxl_ctx *ctx, uint32_t domid, uint32_t vcpuid,
 
 int libxl_set_vcpuonline(libxl_ctx *ctx, uint32_t domid, libxl_cpumap *cpumap)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     libxl_dominfo info;
     char *dompath;
     xs_transaction_t t;
@@ -2641,14 +2641,14 @@ int libxl_set_vcpuonline(libxl_ctx *ctx, uint32_t domid, libxl_cpumap *cpumap)
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "getting domain info list");
         goto out;
     }
-    if (!(dompath = libxl__xs_get_dompath(&gc, domid)))
+    if (!(dompath = libxl__xs_get_dompath(gc, domid)))
         goto out;
 
 retry_transaction:
     t = xs_transaction_start(ctx->xsh);
     for (i = 0; i <= info.vcpu_max_id; i++)
-        libxl__xs_write(&gc, t,
-                       libxl__sprintf(&gc, "%s/cpu/%u/availability", dompath, i),
+        libxl__xs_write(gc, t,
+                       libxl__sprintf(gc, "%s/cpu/%u/availability", dompath, i),
                        "%s", libxl_cpumap_test(cpumap, i) ? "online" : "offline");
     if (!xs_transaction_end(ctx->xsh, t, 0)) {
         if (errno == EAGAIN)
@@ -2656,7 +2656,7 @@ retry_transaction:
     } else
         rc = 0;
 out:
-    libxl__free_all(&gc);
+    GC_FREE;
     return rc;
 }
 
@@ -2776,12 +2776,12 @@ int libxl_send_trigger(libxl_ctx *ctx, uint32_t domid, char *trigger_name, uint3
 
 int libxl_send_sysrq(libxl_ctx *ctx, uint32_t domid, char sysrq)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
-    char *dompath = libxl__xs_get_dompath(&gc, domid);
+    GC_INIT(ctx);
+    char *dompath = libxl__xs_get_dompath(gc, domid);
 
-    libxl__xs_write(&gc, XBT_NULL, libxl__sprintf(&gc, "%s/control/sysrq", dompath), "%c", sysrq);
+    libxl__xs_write(gc, XBT_NULL, libxl__sprintf(gc, "%s/control/sysrq", dompath), "%c", sysrq);
 
-    libxl__free_all(&gc);
+    GC_FREE;
     return 0;
 }
 
@@ -2868,15 +2868,15 @@ void libxl_xen_console_read_finish(libxl_ctx *ctx,
 
 uint32_t libxl_vm_get_start_time(libxl_ctx *ctx, uint32_t domid)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
-    char *dompath = libxl__xs_get_dompath(&gc, domid);
+    GC_INIT(ctx);
+    char *dompath = libxl__xs_get_dompath(gc, domid);
     char *vm_path, *start_time;
     uint32_t ret;
 
     vm_path = libxl__xs_read(
-        &gc, XBT_NULL, libxl__sprintf(&gc, "%s/vm", dompath));
+        gc, XBT_NULL, libxl__sprintf(gc, "%s/vm", dompath));
     start_time = libxl__xs_read(
-        &gc, XBT_NULL, libxl__sprintf(&gc, "%s/start_time", vm_path));
+        gc, XBT_NULL, libxl__sprintf(gc, "%s/start_time", vm_path));
     if (start_time == NULL) {
         LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, -1,
                         "Can't get start time of domain '%d'", domid);
@@ -2884,7 +2884,7 @@ uint32_t libxl_vm_get_start_time(libxl_ctx *ctx, uint32_t domid)
     }else{
         ret = strtoul(start_time, NULL, 10);
     }
-    libxl__free_all(&gc);
+    GC_FREE;
     return ret;
 }
 
@@ -3037,15 +3037,15 @@ int libxl_create_cpupool(libxl_ctx *ctx, const char *name, int schedid,
                          libxl_cpumap cpumap, libxl_uuid *uuid,
                          uint32_t *poolid)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     int rc;
     int i;
     xs_transaction_t t;
     char *uuid_string;
 
-    uuid_string = libxl__uuid2string(&gc, *uuid);
+    uuid_string = libxl__uuid2string(gc, *uuid);
     if (!uuid_string) {
-        libxl__free_all(&gc);
+        GC_FREE;
         return ERROR_NOMEM;
     }
 
@@ -3053,7 +3053,7 @@ int libxl_create_cpupool(libxl_ctx *ctx, const char *name, int schedid,
     if (rc) {
         LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, rc,
            "Could not create cpupool");
-        libxl__free_all(&gc);
+        GC_FREE;
         return ERROR_FAIL;
     }
 
@@ -3064,7 +3064,7 @@ int libxl_create_cpupool(libxl_ctx *ctx, const char *name, int schedid,
                 LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, rc,
                     "Error moving cpu to cpupool");
                 libxl_cpupool_destroy(ctx, *poolid);
-                libxl__free_all(&gc);
+                GC_FREE;
                 return ERROR_FAIL;
             }
         }
@@ -3072,16 +3072,16 @@ int libxl_create_cpupool(libxl_ctx *ctx, const char *name, int schedid,
     for (;;) {
         t = xs_transaction_start(ctx->xsh);
 
-        xs_mkdir(ctx->xsh, t, libxl__sprintf(&gc, "/local/pool/%d", *poolid));
-        libxl__xs_write(&gc, t,
-                        libxl__sprintf(&gc, "/local/pool/%d/uuid", *poolid),
+        xs_mkdir(ctx->xsh, t, libxl__sprintf(gc, "/local/pool/%d", *poolid));
+        libxl__xs_write(gc, t,
+                        libxl__sprintf(gc, "/local/pool/%d/uuid", *poolid),
                         "%s", uuid_string);
-        libxl__xs_write(&gc, t,
-                        libxl__sprintf(&gc, "/local/pool/%d/name", *poolid),
+        libxl__xs_write(gc, t,
+                        libxl__sprintf(gc, "/local/pool/%d/name", *poolid),
                         "%s", name);
 
         if (xs_transaction_end(ctx->xsh, t, 0) || (errno != EAGAIN)) {
-            libxl__free_all(&gc);
+            GC_FREE;
             return 0;
         }
     }
@@ -3089,7 +3089,7 @@ int libxl_create_cpupool(libxl_ctx *ctx, const char *name, int schedid,
 
 int libxl_cpupool_destroy(libxl_ctx *ctx, uint32_t poolid)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     int rc, i;
     xc_cpupoolinfo_t *info;
     xs_transaction_t t;
@@ -3097,7 +3097,7 @@ int libxl_cpupool_destroy(libxl_ctx *ctx, uint32_t poolid)
 
     info = xc_cpupool_getinfo(ctx->xch, poolid);
     if (info == NULL) {
-        libxl__free_all(&gc);
+        GC_FREE;
         return ERROR_NOMEM;
     }
 
@@ -3131,7 +3131,7 @@ int libxl_cpupool_destroy(libxl_ctx *ctx, uint32_t poolid)
     for (;;) {
         t = xs_transaction_start(ctx->xsh);
 
-        xs_rm(ctx->xsh, XBT_NULL, libxl__sprintf(&gc, "/local/pool/%d", poolid));
+        xs_rm(ctx->xsh, XBT_NULL, libxl__sprintf(gc, "/local/pool/%d", poolid));
 
         if (xs_transaction_end(ctx->xsh, t, 0) || (errno != EAGAIN))
             break;
@@ -3143,21 +3143,21 @@ out1:
     libxl_cpumap_dispose(&cpumap);
 out:
     xc_cpupool_infofree(ctx->xch, info);
-    libxl__free_all(&gc);
+    GC_FREE;
 
     return rc;
 }
 
 int libxl_cpupool_rename(libxl_ctx *ctx, const char *name, uint32_t poolid)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     xs_transaction_t t;
     xc_cpupoolinfo_t *info;
     int rc;
 
     info = xc_cpupool_getinfo(ctx->xch, poolid);
     if (info == NULL) {
-        libxl__free_all(&gc);
+        GC_FREE;
         return ERROR_NOMEM;
     }
 
@@ -3170,8 +3170,8 @@ int libxl_cpupool_rename(libxl_ctx *ctx, const char *name, uint32_t poolid)
     for (;;) {
         t = xs_transaction_start(ctx->xsh);
 
-        libxl__xs_write(&gc, t,
-                        libxl__sprintf(&gc, "/local/pool/%d/name", poolid),
+        libxl__xs_write(gc, t,
+                        libxl__sprintf(gc, "/local/pool/%d/name", poolid),
                         "%s", name);
 
         if (xs_transaction_end(ctx->xsh, t, 0))
@@ -3186,7 +3186,7 @@ int libxl_cpupool_rename(libxl_ctx *ctx, const char *name, uint32_t poolid)
 
 out:
     xc_cpupool_infofree(ctx->xch, info);
-    libxl__free_all(&gc);
+    GC_FREE;
 
     return rc;
 }
@@ -3293,16 +3293,16 @@ out:
 
 int libxl_cpupool_movedomain(libxl_ctx *ctx, uint32_t poolid, uint32_t domid)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     int rc;
     char *dom_path;
     char *vm_path;
     char *poolname;
     xs_transaction_t t;
 
-    dom_path = libxl__xs_get_dompath(&gc, domid);
+    dom_path = libxl__xs_get_dompath(gc, domid);
     if (!dom_path) {
-        libxl__free_all(&gc);
+        GC_FREE;
         return ERROR_FAIL;
     }
 
@@ -3310,26 +3310,26 @@ int libxl_cpupool_movedomain(libxl_ctx *ctx, uint32_t poolid, uint32_t domid)
     if (rc) {
         LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, rc,
             "Error moving domain to cpupool");
-        libxl__free_all(&gc);
+        GC_FREE;
         return ERROR_FAIL;
     }
 
     for (;;) {
         t = xs_transaction_start(ctx->xsh);
 
-        poolname = libxl__cpupoolid_to_name(&gc, poolid);
-        vm_path = libxl__xs_read(&gc, XBT_NULL, libxl__sprintf(&gc, "%s/vm", dom_path));
+        poolname = libxl__cpupoolid_to_name(gc, poolid);
+        vm_path = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/vm", dom_path));
         if (!vm_path)
             break;
 
-        libxl__xs_write(&gc, t, libxl__sprintf(&gc, "%s/pool_name", vm_path),
+        libxl__xs_write(gc, t, libxl__sprintf(gc, "%s/pool_name", vm_path),
                         "%s", poolname);
 
         if (xs_transaction_end(ctx->xsh, t, 0) || (errno != EAGAIN))
             break;
     }
 
-    libxl__free_all(&gc);
+    GC_FREE;
     return 0;
 }
 
diff --git a/tools/libxl/libxl_bootloader.c b/tools/libxl/libxl_bootloader.c
index b8399a1..ce83b8e 100644
--- a/tools/libxl/libxl_bootloader.c
+++ b/tools/libxl/libxl_bootloader.c
@@ -328,7 +328,7 @@ int libxl_run_bootloader(libxl_ctx *ctx,
                          libxl_device_disk *disk,
                          uint32_t domid)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     int ret, rc = 0;
     char *fifo = NULL;
     char *diskpath = NULL;
@@ -388,7 +388,7 @@ int libxl_run_bootloader(libxl_ctx *ctx,
         goto out_close;
     }
 
-    args = make_bootloader_args(&gc, info, domid, fifo, diskpath);
+    args = make_bootloader_args(gc, info, domid, fifo, diskpath);
     if (args == NULL) {
         rc = ERROR_NOMEM;
         goto out_close;
@@ -411,8 +411,8 @@ int libxl_run_bootloader(libxl_ctx *ctx,
         goto out_close;
     }
 
-    dom_console_xs_path = libxl__sprintf(&gc, "%s/console/tty", libxl__xs_get_dompath(&gc, domid));
-    libxl__xs_write(&gc, XBT_NULL, dom_console_xs_path, "%s", dom_console_slave_tty_path);
+    dom_console_xs_path = libxl__sprintf(gc, "%s/console/tty", libxl__xs_get_dompath(gc, domid));
+    libxl__xs_write(gc, XBT_NULL, dom_console_xs_path, "%s", dom_console_slave_tty_path);
 
     pid = fork_exec_bootloader(&bootloader_fd, info->u.pv.bootloader, args);
     if (pid < 0) {
@@ -435,7 +435,7 @@ int libxl_run_bootloader(libxl_ctx *ctx,
 
     fcntl(fifo_fd, F_SETFL, O_NDELAY);
 
-    blout = bootloader_interact(&gc, xenconsoled_fd, bootloader_fd, fifo_fd);
+    blout = bootloader_interact(gc, xenconsoled_fd, bootloader_fd, fifo_fd);
     if (blout == NULL) {
         goto out_close;
     }
@@ -445,7 +445,7 @@ int libxl_run_bootloader(libxl_ctx *ctx,
         goto out_close;
     }
 
-    parse_bootloader_result(&gc, info, blout);
+    parse_bootloader_result(gc, info, blout);
 
     rc = 0;
 out_close:
@@ -472,7 +472,7 @@ out_close:
     free(args);
 
 out:
-    libxl__free_all(&gc);
+    GC_FREE;
     return rc;
 }
 
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index ccb56c7..69f10fe 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -670,20 +670,20 @@ error_out:
 int libxl_domain_create_new(libxl_ctx *ctx, libxl_domain_config *d_config,
                             libxl_console_ready cb, void *priv, uint32_t *domid)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     int rc;
-    rc = do_domain_create(&gc, d_config, cb, priv, domid, -1);
-    libxl__free_all(&gc);
+    rc = do_domain_create(gc, d_config, cb, priv, domid, -1);
+    GC_FREE;
     return rc;
 }
 
 int libxl_domain_create_restore(libxl_ctx *ctx, libxl_domain_config *d_config,
                                 libxl_console_ready cb, void *priv, uint32_t *domid, int restore_fd)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     int rc;
-    rc = do_domain_create(&gc, d_config, cb, priv, domid, restore_fd);
-    libxl__free_all(&gc);
+    rc = do_domain_create(gc, d_config, cb, priv, domid, restore_fd);
+    GC_FREE;
     return rc;
 }
 
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 96098de..b1ff967 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -730,7 +730,7 @@ int libxl_userdata_store(libxl_ctx *ctx, uint32_t domid,
                               const char *userdata_userid,
                               const uint8_t *data, int datalen)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     const char *filename;
     const char *newfilename;
     int e, rc;
@@ -738,18 +738,18 @@ int libxl_userdata_store(libxl_ctx *ctx, uint32_t domid,
     FILE *f = NULL;
     size_t rs;
 
-    filename = userdata_path(&gc, domid, userdata_userid, "d");
+    filename = userdata_path(gc, domid, userdata_userid, "d");
     if (!filename) {
         rc = ERROR_NOMEM;
         goto out;
     }
 
     if (!datalen) {
-        rc = userdata_delete(&gc, filename);
+        rc = userdata_delete(gc, filename);
         goto out;
     }
 
-    newfilename = userdata_path(&gc, domid, userdata_userid, "n");
+    newfilename = userdata_path(gc, domid, userdata_userid, "n");
     if (!newfilename) {
         rc = ERROR_NOMEM;
         goto out;
@@ -791,7 +791,7 @@ err:
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "cannot write %s for %s",
                  newfilename, filename);
 out:
-    libxl__free_all(&gc);
+    GC_FREE;
     return rc;
 }
 
@@ -799,13 +799,13 @@ int libxl_userdata_retrieve(libxl_ctx *ctx, uint32_t domid,
                                  const char *userdata_userid,
                                  uint8_t **data_r, int *datalen_r)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     const char *filename;
     int e, rc;
     int datalen = 0;
     void *data = 0;
 
-    filename = userdata_path(&gc, domid, userdata_userid, "d");
+    filename = userdata_path(gc, domid, userdata_userid, "d");
     if (!filename) {
         rc = ERROR_NOMEM;
         goto out;
@@ -827,7 +827,7 @@ int libxl_userdata_retrieve(libxl_ctx *ctx, uint32_t domid,
     if (datalen_r) *datalen_r = datalen;
     rc = 0;
 out:
-    libxl__free_all(&gc);
+    GC_FREE;
     return rc;
 }
 
diff --git a/tools/libxl/libxl_pci.c b/tools/libxl/libxl_pci.c
index 63c3050..120c239 100644
--- a/tools/libxl/libxl_pci.c
+++ b/tools/libxl/libxl_pci.c
@@ -483,7 +483,7 @@ static int is_assigned(libxl_device_pci *assigned, int num_assigned,
 
 libxl_device_pci *libxl_device_pci_list_assignable(libxl_ctx *ctx, int *num)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     libxl_device_pci *pcidevs = NULL, *new, *assigned;
     struct dirent *de;
     DIR *dir;
@@ -491,7 +491,7 @@ libxl_device_pci *libxl_device_pci_list_assignable(libxl_ctx *ctx, int *num)
 
     *num = 0;
 
-    rc = get_all_assigned_devices(&gc, &assigned, &num_assigned);
+    rc = get_all_assigned_devices(gc, &assigned, &num_assigned);
     if ( rc )
         goto out;
 
@@ -528,7 +528,7 @@ libxl_device_pci *libxl_device_pci_list_assignable(libxl_ctx *ctx, int *num)
 out_closedir:
     closedir(dir);
 out:
-    libxl__free_all(&gc);
+    GC_FREE;
     return pcidevs;
 }
 
@@ -782,10 +782,10 @@ static int libxl__device_pci_reset(libxl__gc *gc, unsigned int domain, unsigned
 
 int libxl_device_pci_add(libxl_ctx *ctx, uint32_t domid, libxl_device_pci *pcidev)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     int rc;
-    rc = libxl__device_pci_add(&gc, domid, pcidev, 0);
-    libxl__free_all(&gc);
+    rc = libxl__device_pci_add(gc, domid, pcidev, 0);
+    GC_FREE;
     return rc;
 }
 
@@ -1057,24 +1057,24 @@ out:
 
 int libxl_device_pci_remove(libxl_ctx *ctx, uint32_t domid, libxl_device_pci *pcidev)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     int rc;
 
-    rc = libxl__device_pci_remove_common(&gc, domid, pcidev, 0);
+    rc = libxl__device_pci_remove_common(gc, domid, pcidev, 0);
 
-    libxl__free_all(&gc);
+    GC_FREE;
     return rc;
 }
 
 int libxl_device_pci_destroy(libxl_ctx *ctx, uint32_t domid,
                                   libxl_device_pci *pcidev)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     int rc;
 
-    rc = libxl__device_pci_remove_common(&gc, domid, pcidev, 1);
+    rc = libxl__device_pci_remove_common(gc, domid, pcidev, 1);
 
-    libxl__free_all(&gc);
+    GC_FREE;
     return rc;
 }
 
@@ -1115,15 +1115,15 @@ static void libxl__device_pci_from_xs_be(libxl__gc *gc,
 
 libxl_device_pci *libxl_device_pci_list(libxl_ctx *ctx, uint32_t domid, int *num)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     char *be_path, *num_devs;
     int n, i;
     libxl_device_pci *pcidevs = NULL;
 
     *num = 0;
 
-    be_path = libxl__sprintf(&gc, "%s/backend/pci/%d/0", libxl__xs_get_dompath(&gc, 0), domid);
-    num_devs = libxl__xs_read(&gc, XBT_NULL, libxl__sprintf(&gc, "%s/num_devs", be_path));
+    be_path = libxl__sprintf(gc, "%s/backend/pci/%d/0", libxl__xs_get_dompath(gc, 0), domid);
+    num_devs = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/num_devs", be_path));
     if (!num_devs)
         goto out;
 
@@ -1131,11 +1131,11 @@ libxl_device_pci *libxl_device_pci_list(libxl_ctx *ctx, uint32_t domid, int *num
     pcidevs = calloc(n, sizeof(libxl_device_pci));
 
     for (i = 0; i < n; i++)
-        libxl__device_pci_from_xs_be(&gc, be_path, pcidevs + i, i);
+        libxl__device_pci_from_xs_be(gc, be_path, pcidevs + i, i);
 
     *num = n;
 out:
-    libxl__free_all(&gc);
+    GC_FREE;
     return pcidevs;
 }
 
diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
index c7696d7..60af98c 100644
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/libxl/libxl_qmp.c
@@ -94,7 +94,7 @@ static int store_serial_port_info(libxl__qmp_handler *qmp,
                                   const char *chardev,
                                   int port)
 {
-    libxl__gc gc = LIBXL_INIT_GC(qmp->ctx);
+    GC_INIT(qmp->ctx);
     char *path = NULL;
     int ret = 0;
 
@@ -102,12 +102,12 @@ static int store_serial_port_info(libxl__qmp_handler *qmp,
         return 0;
     }
 
-    path = libxl__xs_get_dompath(&gc, qmp->domid);
-    path = libxl__sprintf(&gc, "%s/serial/%d/tty", path, port);
+    path = libxl__xs_get_dompath(gc, qmp->domid);
+    path = libxl__sprintf(gc, "%s/serial/%d/tty", path, port);
 
-    ret = libxl__xs_write(&gc, XBT_NULL, path, "%s", chardev + 4);
+    ret = libxl__xs_write(gc, XBT_NULL, path, "%s", chardev + 4);
 
-    libxl__free_all(&gc);
+    GC_FREE;
     return ret;
 }
 
@@ -521,7 +521,7 @@ static int qmp_synchronous_send(libxl__qmp_handler *qmp, const char *cmd,
 {
     int id = 0;
     int ret = 0;
-    libxl__gc gc = LIBXL_INIT_GC(qmp->ctx);
+    GC_INIT(qmp->ctx);
     qmp_request_context context = { .rc = 0 };
 
     id = qmp_send(qmp, cmd, args, callback, opaque, &context);
@@ -531,7 +531,7 @@ static int qmp_synchronous_send(libxl__qmp_handler *qmp, const char *cmd,
     qmp->wait_for_id = id;
 
     while (qmp->wait_for_id == id) {
-        if ((ret = qmp_next(&gc, qmp)) < 0) {
+        if ((ret = qmp_next(gc, qmp)) < 0) {
             break;
         }
     }
@@ -540,7 +540,7 @@ static int qmp_synchronous_send(libxl__qmp_handler *qmp, const char *cmd,
         ret = context.rc;
     }
 
-    libxl__free_all(&gc);
+    GC_FREE;
 
     return ret;
 }
@@ -559,15 +559,15 @@ libxl__qmp_handler *libxl__qmp_initialize(libxl_ctx *ctx, uint32_t domid)
     int ret = 0;
     libxl__qmp_handler *qmp = NULL;
     char *qmp_socket;
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
 
     qmp = qmp_init_handler(ctx, domid);
 
-    qmp_socket = libxl__sprintf(&gc, "%s/qmp-libxl-%d",
+    qmp_socket = libxl__sprintf(gc, "%s/qmp-libxl-%d",
                                 libxl_run_dir_path(), domid);
     if ((ret = qmp_open(qmp, qmp_socket, QMP_SOCKET_CONNECT_TIMEOUT)) < 0) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "Connection error");
-        libxl__free_all(&gc);
+        GC_FREE;
         qmp_free_handler(qmp);
         return NULL;
     }
@@ -576,12 +576,12 @@ libxl__qmp_handler *libxl__qmp_initialize(libxl_ctx *ctx, uint32_t domid)
 
     /* Wait for the response to qmp_capabilities */
     while (!qmp->connected) {
-        if ((ret = qmp_next(&gc, qmp)) < 0) {
+        if ((ret = qmp_next(gc, qmp)) < 0) {
             break;
         }
     }
 
-    libxl__free_all(&gc);
+    GC_FREE;
     if (!qmp->connected) {
         LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Failed to connect to QMP");
         libxl__qmp_close(qmp);
@@ -626,9 +626,9 @@ static int pci_add_callback(libxl__qmp_handler *qmp,
 {
     libxl_device_pci *pcidev = opaque;
     const libxl__json_object *bus = NULL;
-    libxl__gc gc = LIBXL_INIT_GC(qmp->ctx);
+    GC_INIT(qmp->ctx);
     int i, j, rc = -1;
-    char *asked_id = libxl__sprintf(&gc, PCI_PT_QDEV_ID,
+    char *asked_id = libxl__sprintf(gc, PCI_PT_QDEV_ID,
                                     pcidev->bus, pcidev->dev, pcidev->func);
 
     for (i = 0; (bus = libxl__json_array_get(response, i)); i++) {
@@ -665,7 +665,7 @@ static int pci_add_callback(libxl__qmp_handler *qmp,
 
 
 out:
-    libxl__free_all(&gc);
+    GC_FREE;
     return rc;
 }
 
diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
index f1f2a6d..d36c737 100644
--- a/tools/libxl/libxl_utils.c
+++ b/tools/libxl/libxl_utils.c
@@ -186,29 +186,29 @@ char *libxl_schedid_to_name(libxl_ctx *ctx, int schedid)
 
 int libxl_get_stubdom_id(libxl_ctx *ctx, int guest_domid)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     char * stubdom_id_s;
     int ret;
 
-    stubdom_id_s = libxl__xs_read(&gc, XBT_NULL,
-                                 libxl__sprintf(&gc, "%s/image/device-model-domid",
-                                               libxl__xs_get_dompath(&gc, guest_domid)));
+    stubdom_id_s = libxl__xs_read(gc, XBT_NULL,
+                                 libxl__sprintf(gc, "%s/image/device-model-domid",
+                                               libxl__xs_get_dompath(gc, guest_domid)));
     if (stubdom_id_s)
         ret = atoi(stubdom_id_s);
     else
         ret = 0;
-    libxl__free_all(&gc);
+    GC_FREE;
     return ret;
 }
 
 int libxl_is_stubdom(libxl_ctx *ctx, uint32_t domid, uint32_t *target_domid)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     char *target, *endptr;
     uint32_t value;
     int ret = 0;
 
-    target = libxl__xs_read(&gc, XBT_NULL, libxl__sprintf(&gc, "%s/target", libxl__xs_get_dompath(&gc, domid)));
+    target = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/target", libxl__xs_get_dompath(gc, domid)));
     if (!target)
         goto out;
     value = strtol(target, &endptr, 10);
@@ -218,7 +218,7 @@ int libxl_is_stubdom(libxl_ctx *ctx, uint32_t domid, uint32_t *target_domid)
         *target_domid = value;
     ret = 1;
 out:
-    libxl__free_all(&gc);
+    GC_FREE;
     return ret;
 }
 
@@ -240,27 +240,27 @@ static int logrename(libxl__gc *gc, const char *old, const char *new)
 
 int libxl_create_logfile(libxl_ctx *ctx, char *name, char **full_name)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     struct stat stat_buf;
     char *logfile, *logfile_new;
     int i, rc;
 
-    logfile = libxl__sprintf(&gc, "/var/log/xen/%s.log", name);
+    logfile = libxl__sprintf(gc, "/var/log/xen/%s.log", name);
     if (stat(logfile, &stat_buf) == 0) {
         /* file exists, rotate */
-        logfile = libxl__sprintf(&gc, "/var/log/xen/%s.log.10", name);
+        logfile = libxl__sprintf(gc, "/var/log/xen/%s.log.10", name);
         unlink(logfile);
         for (i = 9; i > 0; i--) {
-            logfile = libxl__sprintf(&gc, "/var/log/xen/%s.log.%d", name, i);
-            logfile_new = libxl__sprintf(&gc, "/var/log/xen/%s.log.%d", name, i + 1);
-            rc = logrename(&gc, logfile, logfile_new);
+            logfile = libxl__sprintf(gc, "/var/log/xen/%s.log.%d", name, i);
+            logfile_new = libxl__sprintf(gc, "/var/log/xen/%s.log.%d", name, i + 1);
+            rc = logrename(gc, logfile, logfile_new);
             if (rc)
                 goto out;
         }
-        logfile = libxl__sprintf(&gc, "/var/log/xen/%s.log", name);
-        logfile_new = libxl__sprintf(&gc, "/var/log/xen/%s.log.1", name);
+        logfile = libxl__sprintf(gc, "/var/log/xen/%s.log", name);
+        logfile_new = libxl__sprintf(gc, "/var/log/xen/%s.log.1", name);
 
-        rc = logrename(&gc, logfile, logfile_new);
+        rc = logrename(gc, logfile, logfile_new);
         if (rc)
             goto out;
     } else {
@@ -272,7 +272,7 @@ int libxl_create_logfile(libxl_ctx *ctx, char *name, char **full_name)
     *full_name = strdup(logfile);
     rc = 0;
 out:
-    libxl__free_all(&gc);
+    GC_FREE;
     return rc;
 }
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 18:11:32 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 18:11:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXd0Y-00069s-2T; Mon, 05 Dec 2011 18:11:18 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RXd0U-000661-Kq
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 18:11:14 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1323108629!5440616!3
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjAyNg==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14069 invoked from network); 5 Dec 2011 18:10:30 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Dec 2011 18:10:30 -0000
X-IronPort-AV: E=Sophos;i="4.71,300,1320624000"; 
   d="scan'208";a="9297532"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Dec 2011 18:10:29 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 5 Dec 2011 18:10:29 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RXczl-0003kU-CW; Mon, 05 Dec 2011 18:10:29 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RXczl-0006Wf-Au;
	Mon, 05 Dec 2011 18:10:29 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Mon, 5 Dec 2011 18:10:19 +0000
Message-ID: <1323108621-22654-14-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1323108621-22654-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1323108621-22654-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 13/15] libxl: make LIBXL_INIT_GC a statement,
	not an initialiser
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Previously LIBXL_INIT_GC was an initialiser, which you were expected
to use like this:
    libxl__gc gc = LIBXL_INIT_GC(ctx);

But we are going to want to put things in the gc which are to be
initialised using other macros.  That means that LIBXL_INIT_GC has to
become a statement too.  So instead, we make it so that it's used like this:
    libxl_gc gc;
    LIBXL_INIT_GC(gc,ctx);

In fact there is only one caller now, GC_INIT, which uses this trick:
    libxl_gc gc[1];
    LIBXL_INIT_GC(gc[0],ctx);

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl_internal.h |    9 +++++++--
 1 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 1d1dc35..d015c7c 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -145,7 +145,12 @@ typedef struct {
     libxl_ctx *owner;
 } libxl__gc;
 
-#define LIBXL_INIT_GC(ctx) (libxl__gc){ .alloc_maxsize = 0, .alloc_ptrs = 0, .owner = ctx }
+#define LIBXL_INIT_GC(gc,ctx) do{               \
+        (gc).alloc_maxsize = 0;                 \
+        (gc).alloc_ptrs = 0;                    \
+        (gc).owner = (ctx);                     \
+    } while(0)
+
 static inline libxl_ctx *libxl__gc_owner(libxl__gc *gc)
 {
     return gc->owner;
@@ -676,7 +681,7 @@ libxl__device_model_version_running(libxl__gc *gc, uint32_t domid);
  * as a local variable.
  */
 
-#define GC_INIT(ctx)  libxl__gc gc[1] = { LIBXL_INIT_GC(ctx) }
+#define GC_INIT(ctx)  libxl__gc gc[1]; LIBXL_INIT_GC(gc[0],ctx)
 #define GC_FREE       libxl__free_all(gc)
 #define CTX           libxl__gc_owner(gc)
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 18:11:32 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 18:11:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXd0Y-0006AR-Ur; Mon, 05 Dec 2011 18:11:18 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RXd0U-000660-Px
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 18:11:15 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1323108629!5440616!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjAyNg==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14036 invoked from network); 5 Dec 2011 18:10:29 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Dec 2011 18:10:29 -0000
X-IronPort-AV: E=Sophos;i="4.71,300,1320624000"; 
   d="scan'208";a="9297531"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Dec 2011 18:10:29 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 5 Dec 2011 18:10:29 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RXczl-0003kR-2X; Mon, 05 Dec 2011 18:10:29 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RXczl-0006Wb-1c;
	Mon, 05 Dec 2011 18:10:29 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Mon, 5 Dec 2011 18:10:18 +0000
Message-ID: <1323108621-22654-13-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1323108621-22654-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1323108621-22654-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 12/15] libxl: Use GC_INIT and GC_FREE everywhere
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Replace
    libxl__gc gc = LIBXL_INIT_GC(ctx);
    ...
    libxl__free_all(&gc);
with
    GC_INIT(ctx);
    ...
    GC_FREE;
throughout with a couple of perl runes.

We must then adjust uses of the resulting gc for pointerness, which is
mostly just replacing all occurrences of "&gc" with "gc".  Also a
couple of unusual uses of LIBXL_INIT_GC needed to be fixed up by hand.

Here are those runes:
 perl -i -pe 's/\Q    libxl__gc gc = LIBXL_INIT_GC(ctx);/    GC_INIT(ctx);/' tools/libxl/*.c
 perl -i -pe 's/\Q    libxl__free_all(&gc);/    GC_FREE;/' tools/libxl/*.c

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl.c            |  590 ++++++++++++++++++++--------------------
 tools/libxl/libxl_bootloader.c |   14 +-
 tools/libxl/libxl_create.c     |   12 +-
 tools/libxl/libxl_dom.c        |   16 +-
 tools/libxl/libxl_pci.c        |   34 ++--
 tools/libxl/libxl_qmp.c        |   32 +-
 tools/libxl/libxl_utils.c      |   36 ++--
 7 files changed, 367 insertions(+), 367 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 7488538..3a8cfe3 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -232,19 +232,19 @@ int libxl__domain_rename(libxl__gc *gc, uint32_t domid,
 int libxl_domain_rename(libxl_ctx *ctx, uint32_t domid,
                         const char *old_name, const char *new_name)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     int rc;
-    rc = libxl__domain_rename(&gc, domid, old_name, new_name, XBT_NULL);
-    libxl__free_all(&gc);
+    rc = libxl__domain_rename(gc, domid, old_name, new_name, XBT_NULL);
+    GC_FREE;
     return rc;
 }
 
 int libxl_domain_resume(libxl_ctx *ctx, uint32_t domid)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     int rc = 0;
 
-    if (LIBXL__DOMAIN_IS_TYPE(&gc,  domid, HVM)) {
+    if (LIBXL__DOMAIN_IS_TYPE(gc,  domid, HVM)) {
         LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Called domain_resume on "
                 "non-cooperative hvm domain %u", domid);
         rc = ERROR_NI;
@@ -264,7 +264,7 @@ int libxl_domain_resume(libxl_ctx *ctx, uint32_t domid)
         rc = ERROR_FAIL;
     }
 out:
-    libxl__free_all(&gc);
+    GC_FREE;
     return rc;
 }
 
@@ -277,7 +277,7 @@ out:
 int libxl_domain_preserve(libxl_ctx *ctx, uint32_t domid,
                           libxl_domain_create_info *info, const char *name_suffix, libxl_uuid new_uuid)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     struct xs_permissions roperm[2];
     xs_transaction_t t;
     char *preserved_name;
@@ -287,27 +287,27 @@ int libxl_domain_preserve(libxl_ctx *ctx, uint32_t domid,
 
     int rc;
 
-    preserved_name = libxl__sprintf(&gc, "%s%s", info->name, name_suffix);
+    preserved_name = libxl__sprintf(gc, "%s%s", info->name, name_suffix);
     if (!preserved_name) {
-        libxl__free_all(&gc);
+        GC_FREE;
         return ERROR_NOMEM;
     }
 
-    uuid_string = libxl__uuid2string(&gc, new_uuid);
+    uuid_string = libxl__uuid2string(gc, new_uuid);
     if (!uuid_string) {
-        libxl__free_all(&gc);
+        GC_FREE;
         return ERROR_NOMEM;
     }
 
-    dom_path = libxl__xs_get_dompath(&gc, domid);
+    dom_path = libxl__xs_get_dompath(gc, domid);
     if (!dom_path) {
-        libxl__free_all(&gc);
+        GC_FREE;
         return ERROR_FAIL;
     }
 
-    vm_path = libxl__sprintf(&gc, "/vm/%s", uuid_string);
+    vm_path = libxl__sprintf(gc, "/vm/%s", uuid_string);
     if (!vm_path) {
-        libxl__free_all(&gc);
+        GC_FREE;
         return ERROR_FAIL;
     }
 
@@ -323,20 +323,20 @@ int libxl_domain_preserve(libxl_ctx *ctx, uint32_t domid,
     xs_mkdir(ctx->xsh, t, vm_path);
     xs_set_permissions(ctx->xsh, t, vm_path, roperm, ARRAY_SIZE(roperm));
 
-    xs_write(ctx->xsh, t, libxl__sprintf(&gc, "%s/vm", dom_path), vm_path, strlen(vm_path));
-    rc = libxl__domain_rename(&gc, domid, info->name, preserved_name, t);
+    xs_write(ctx->xsh, t, libxl__sprintf(gc, "%s/vm", dom_path), vm_path, strlen(vm_path));
+    rc = libxl__domain_rename(gc, domid, info->name, preserved_name, t);
     if (rc) {
-        libxl__free_all(&gc);
+        GC_FREE;
         return rc;
     }
 
-    xs_write(ctx->xsh, t, libxl__sprintf(&gc, "%s/uuid", vm_path), uuid_string, strlen(uuid_string));
+    xs_write(ctx->xsh, t, libxl__sprintf(gc, "%s/uuid", vm_path), uuid_string, strlen(uuid_string));
 
     if (!xs_transaction_end(ctx->xsh, t, 0))
         if (errno == EAGAIN)
             goto retry_transaction;
 
-    libxl__free_all(&gc);
+    GC_FREE;
     return 0;
 }
 
@@ -478,16 +478,16 @@ libxl_vminfo * libxl_list_vm(libxl_ctx *ctx, int *nb_vm)
 int libxl_domain_suspend(libxl_ctx *ctx, libxl_domain_suspend_info *info,
                          uint32_t domid, int fd)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
-    libxl_domain_type type = libxl__domain_type(&gc, domid);
+    GC_INIT(ctx);
+    libxl_domain_type type = libxl__domain_type(gc, domid);
     int live = info != NULL && info->flags & XL_SUSPEND_LIVE;
     int debug = info != NULL && info->flags & XL_SUSPEND_DEBUG;
     int rc = 0;
 
-    rc = libxl__domain_suspend_common(&gc, domid, fd, type, live, debug);
+    rc = libxl__domain_suspend_common(gc, domid, fd, type, live, debug);
     if (!rc && type == LIBXL_DOMAIN_TYPE_HVM)
-        rc = libxl__domain_save_device_model(&gc, domid, fd);
-    libxl__free_all(&gc);
+        rc = libxl__domain_save_device_model(gc, domid, fd);
+    GC_FREE;
     return rc;
 }
 
@@ -517,17 +517,17 @@ int libxl_domain_core_dump(libxl_ctx *ctx, uint32_t domid,
 
 int libxl_domain_unpause(libxl_ctx *ctx, uint32_t domid)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     char *path;
     char *state;
     int ret, rc = 0;
 
-    if (LIBXL__DOMAIN_IS_TYPE(&gc,  domid, HVM)) {
-        path = libxl__sprintf(&gc, "/local/domain/0/device-model/%d/state", domid);
-        state = libxl__xs_read(&gc, XBT_NULL, path);
+    if (LIBXL__DOMAIN_IS_TYPE(gc,  domid, HVM)) {
+        path = libxl__sprintf(gc, "/local/domain/0/device-model/%d/state", domid);
+        state = libxl__xs_read(gc, XBT_NULL, path);
         if (state != NULL && !strcmp(state, "paused")) {
-            libxl__xs_write(&gc, XBT_NULL, libxl__sprintf(&gc, "/local/domain/0/device-model/%d/command", domid), "continue");
-            libxl__wait_for_device_model(&gc, domid, "running",
+            libxl__xs_write(gc, XBT_NULL, libxl__sprintf(gc, "/local/domain/0/device-model/%d/command", domid), "continue");
+            libxl__wait_for_device_model(gc, domid, "running",
                                          NULL, NULL, NULL);
         }
     }
@@ -536,7 +536,7 @@ int libxl_domain_unpause(libxl_ctx *ctx, uint32_t domid)
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "unpausing domain %d", domid);
         rc = ERROR_FAIL;
     }
-    libxl__free_all(&gc);
+    GC_FREE;
     return rc;
 }
 
@@ -550,42 +550,42 @@ static char *req_table[] = {
 
 int libxl_domain_shutdown(libxl_ctx *ctx, uint32_t domid, int req)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     char *shutdown_path;
     char *dom_path;
 
     if (req > ARRAY_SIZE(req_table)) {
-        libxl__free_all(&gc);
+        GC_FREE;
         return ERROR_INVAL;
     }
 
-    dom_path = libxl__xs_get_dompath(&gc, domid);
+    dom_path = libxl__xs_get_dompath(gc, domid);
     if (!dom_path) {
-        libxl__free_all(&gc);
+        GC_FREE;
         return ERROR_FAIL;
     }
 
-    if (LIBXL__DOMAIN_IS_TYPE(&gc,  domid, HVM)) {
+    if (LIBXL__DOMAIN_IS_TYPE(gc,  domid, HVM)) {
         unsigned long pvdriver = 0;
         int ret;
         ret = xc_get_hvm_param(ctx->xch, domid, HVM_PARAM_CALLBACK_IRQ, &pvdriver);
         if (ret<0) {
             LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "getting HVM callback IRQ");
-            libxl__free_all(&gc);
+            GC_FREE;
             return ERROR_FAIL;
         }
         if (!pvdriver) {
             LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "HVM domain without PV drivers:"
                        " graceful shutdown not possible, use destroy");
-            libxl__free_all(&gc);
+            GC_FREE;
             return ERROR_FAIL;
         }
     }
 
-    shutdown_path = libxl__sprintf(&gc, "%s/control/shutdown", dom_path);
+    shutdown_path = libxl__sprintf(gc, "%s/control/shutdown", dom_path);
     xs_write(ctx->xsh, XBT_NULL, shutdown_path, req_table[req], strlen(req_table[req]));
 
-    libxl__free_all(&gc);
+    GC_FREE;
     return 0;
 }
 
@@ -607,7 +607,7 @@ int libxl_wait_for_domain_death(libxl_ctx *ctx, uint32_t domid, libxl_waiter *wa
 
 int libxl_wait_for_disk_ejects(libxl_ctx *ctx, uint32_t guest_domid, libxl_device_disk *disks, int num_disks, libxl_waiter *waiter)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     int i, rc = -1;
     uint32_t domid = libxl_get_stubdom_id(ctx, guest_domid);
 
@@ -616,7 +616,7 @@ int libxl_wait_for_disk_ejects(libxl_ctx *ctx, uint32_t guest_domid, libxl_devic
 
     for (i = 0; i < num_disks; i++) {
         if (asprintf(&(waiter[i].path), "%s/device/vbd/%d/eject",
-                     libxl__xs_get_dompath(&gc, domid),
+                     libxl__xs_get_dompath(gc, domid),
                      libxl__device_disk_dev_number(disks[i].vdev,
                                                    NULL, NULL)) < 0)
             goto out;
@@ -626,7 +626,7 @@ int libxl_wait_for_disk_ejects(libxl_ctx *ctx, uint32_t guest_domid, libxl_devic
     }
     rc = 0;
 out:
-    libxl__free_all(&gc);
+    GC_FREE;
     return rc;
 }
 
@@ -680,22 +680,22 @@ int libxl_event_get_domain_death_info(libxl_ctx *ctx, uint32_t domid, libxl_even
 
 int libxl_event_get_disk_eject_info(libxl_ctx *ctx, uint32_t domid, libxl_event *event, libxl_device_disk *disk)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     char *path;
     char *backend;
     char *value;
     char backend_type[BACKEND_STRING_SIZE+1];
 
-    value = libxl__xs_read(&gc, XBT_NULL, event->path);
+    value = libxl__xs_read(gc, XBT_NULL, event->path);
 
     if (!value || strcmp(value,  "eject")) {
-        libxl__free_all(&gc);
+        GC_FREE;
         return 0;
     }
 
     path = strdup(event->path);
     path[strlen(path) - 6] = '\0';
-    backend = libxl__xs_read(&gc, XBT_NULL, libxl__sprintf(&gc, "%s/backend", path));
+    backend = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/backend", path));
 
     sscanf(backend,
             "/local/domain/%d/backend/%" TOSTRING(BACKEND_STRING_SIZE) "[a-z]/%*d/%*d",
@@ -711,19 +711,19 @@ int libxl_event_get_disk_eject_info(libxl_ctx *ctx, uint32_t domid, libxl_event
     disk->pdev_path = strdup("");
     disk->format = LIBXL_DISK_FORMAT_EMPTY;
     /* this value is returned to the user: do not free right away */
-    disk->vdev = xs_read(ctx->xsh, XBT_NULL, libxl__sprintf(&gc, "%s/dev", backend), NULL);
+    disk->vdev = xs_read(ctx->xsh, XBT_NULL, libxl__sprintf(gc, "%s/dev", backend), NULL);
     disk->removable = 1;
     disk->readwrite = 0;
     disk->is_cdrom = 1;
 
     free(path);
-    libxl__free_all(&gc);
+    GC_FREE;
     return 1;
 }
 
 int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid, int force)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     libxl_dominfo dominfo;
     char *dom_path;
     char *vm_path;
@@ -740,40 +740,40 @@ int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid, int force)
         return rc;
     }
 
-    switch (libxl__domain_type(&gc, domid)) {
+    switch (libxl__domain_type(gc, domid)) {
     case LIBXL_DOMAIN_TYPE_HVM:
         dm_present = 1;
         break;
     case LIBXL_DOMAIN_TYPE_PV:
-        pid = libxl__xs_read(&gc, XBT_NULL, libxl__sprintf(&gc, "/local/domain/%d/image/device-model-pid", domid));
+        pid = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "/local/domain/%d/image/device-model-pid", domid));
         dm_present = (pid != NULL);
         break;
     default:
         abort();
     }
 
-    dom_path = libxl__xs_get_dompath(&gc, domid);
+    dom_path = libxl__xs_get_dompath(gc, domid);
     if (!dom_path) {
         rc = ERROR_FAIL;
         goto out;
     }
 
-    if (libxl__device_pci_destroy_all(&gc, domid) < 0)
+    if (libxl__device_pci_destroy_all(gc, domid) < 0)
         LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "pci shutdown failed for domid %d", domid);
     rc = xc_domain_pause(ctx->xch, domid);
     if (rc < 0) {
         LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, rc, "xc_domain_pause failed for %d", domid);
     }
     if (dm_present) {
-        if (libxl__destroy_device_model(&gc, domid) < 0)
+        if (libxl__destroy_device_model(gc, domid) < 0)
             LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "libxl__destroy_device_model failed for %d", domid);
 
-        libxl__qmp_cleanup(&gc, domid);
+        libxl__qmp_cleanup(gc, domid);
     }
-    if (libxl__devices_destroy(&gc, domid, force) < 0)
+    if (libxl__devices_destroy(gc, domid, force) < 0)
         LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "libxl_devices_dispose failed for %d", domid);
 
-    vm_path = libxl__xs_read(&gc, XBT_NULL, libxl__sprintf(&gc, "%s/vm", dom_path));
+    vm_path = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/vm", dom_path));
     if (vm_path)
         if (!xs_rm(ctx->xsh, XBT_NULL, vm_path))
             LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "xs_rm failed for %s", vm_path);
@@ -781,9 +781,9 @@ int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid, int force)
     if (!xs_rm(ctx->xsh, XBT_NULL, dom_path))
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "xs_rm failed for %s", dom_path);
 
-    xs_rm(ctx->xsh, XBT_NULL, libxl__xs_libxl_path(&gc, domid));
+    xs_rm(ctx->xsh, XBT_NULL, libxl__xs_libxl_path(gc, domid));
 
-    libxl__userdata_destroyall(&gc, domid);
+    libxl__userdata_destroyall(gc, domid);
 
     rc = xc_domain_destroy(ctx->xch, domid);
     if (rc < 0) {
@@ -793,16 +793,16 @@ int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid, int force)
     }
     rc = 0;
 out:
-    libxl__free_all(&gc);
+    GC_FREE;
     return rc;
 }
 
 int libxl_console_exec(libxl_ctx *ctx, uint32_t domid, int cons_num, libxl_console_type type)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
-    char *p = libxl__sprintf(&gc, "%s/xenconsole", libxl_private_bindir_path());
-    char *domid_s = libxl__sprintf(&gc, "%d", domid);
-    char *cons_num_s = libxl__sprintf(&gc, "%d", cons_num);
+    GC_INIT(ctx);
+    char *p = libxl__sprintf(gc, "%s/xenconsole", libxl_private_bindir_path());
+    char *domid_s = libxl__sprintf(gc, "%d", domid);
+    char *cons_num_s = libxl__sprintf(gc, "%d", cons_num);
     char *cons_type_s;
 
     switch (type) {
@@ -819,20 +819,20 @@ int libxl_console_exec(libxl_ctx *ctx, uint32_t domid, int cons_num, libxl_conso
     execl(p, p, domid_s, "--num", cons_num_s, "--type", cons_type_s, (void *)NULL);
 
 out:
-    libxl__free_all(&gc);
+    GC_FREE;
     return ERROR_FAIL;
 }
 
 int libxl_primary_console_exec(libxl_ctx *ctx, uint32_t domid_vm)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     uint32_t stubdomid = libxl_get_stubdom_id(ctx, domid_vm);
     int rc;
     if (stubdomid)
         rc = libxl_console_exec(ctx, stubdomid,
                                 STUBDOM_CONSOLE_SERIAL, LIBXL_CONSOLE_TYPE_PV);
     else {
-        switch (libxl__domain_type(&gc, domid_vm)) {
+        switch (libxl__domain_type(gc, domid_vm)) {
         case LIBXL_DOMAIN_TYPE_HVM:
             rc = libxl_console_exec(ctx, domid_vm, 0, LIBXL_CONSOLE_TYPE_SERIAL);
             break;
@@ -843,13 +843,13 @@ int libxl_primary_console_exec(libxl_ctx *ctx, uint32_t domid_vm)
             abort();
         }
     }
-    libxl__free_all(&gc);
+    GC_FREE;
     return rc;
 }
 
 int libxl_vncviewer_exec(libxl_ctx *ctx, uint32_t domid, int autopass)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     const char *vnc_port;
     const char *vnc_listen = NULL, *vnc_pass = NULL;
     int port = 0, autopass_fd = -1;
@@ -860,19 +860,19 @@ int libxl_vncviewer_exec(libxl_ctx *ctx, uint32_t domid, int autopass)
         NULL,
     };
 
-    vnc_port = libxl__xs_read(&gc, XBT_NULL,
-                            libxl__sprintf(&gc,
+    vnc_port = libxl__xs_read(gc, XBT_NULL,
+                            libxl__sprintf(gc,
                             "/local/domain/%d/console/vnc-port", domid));
     if ( vnc_port )
         port = atoi(vnc_port) - 5900;
 
-    vnc_listen = libxl__xs_read(&gc, XBT_NULL,
-                                libxl__sprintf(&gc,
+    vnc_listen = libxl__xs_read(gc, XBT_NULL,
+                                libxl__sprintf(gc,
                             "/local/domain/%d/console/vnc-listen", domid));
 
     if ( autopass )
-        vnc_pass = libxl__xs_read(&gc, XBT_NULL,
-                                  libxl__sprintf(&gc,
+        vnc_pass = libxl__xs_read(gc, XBT_NULL,
+                                  libxl__sprintf(gc,
                             "/local/domain/%d/console/vnc-pass", domid));
 
     if ( NULL == vnc_listen )
@@ -881,7 +881,7 @@ int libxl_vncviewer_exec(libxl_ctx *ctx, uint32_t domid, int autopass)
     if ( (vnc_bin = getenv("VNCVIEWER")) )
         args[0] = vnc_bin;
 
-    args[1] = libxl__sprintf(&gc, "%s:%d", vnc_listen, port);
+    args[1] = libxl__sprintf(gc, "%s:%d", vnc_listen, port);
 
     if ( vnc_pass ) {
         char tmpname[] = "/tmp/vncautopass.XXXXXX";
@@ -916,7 +916,7 @@ int libxl_vncviewer_exec(libxl_ctx *ctx, uint32_t domid, int autopass)
     abort();
 
  x_fail:
-    libxl__free_all(&gc);
+    GC_FREE;
     return ERROR_FAIL;
 }
 
@@ -970,17 +970,17 @@ static int libxl__device_from_disk(libxl__gc *gc, uint32_t domid,
 
 int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *disk)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     flexarray_t *front;
     flexarray_t *back;
     char *dev;
     libxl__device device;
     int major, minor, rc;
 
-    rc = libxl__device_disk_set_backend(&gc, disk);
+    rc = libxl__device_disk_set_backend(gc, disk);
     if (rc) goto out;
 
-    rc = libxl__device_disk_set_backend(&gc, disk);
+    rc = libxl__device_disk_set_backend(gc, disk);
     if (rc) goto out;
 
     front = flexarray_make(16, 1);
@@ -1001,7 +1001,7 @@ int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *dis
         goto out_free;
     }
 
-    rc = libxl__device_from_disk(&gc, domid, disk, &device);
+    rc = libxl__device_from_disk(gc, domid, disk, &device);
     if (rc != 0) {
         LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Invalid or unsupported"
                " virtual disk identifier %s", disk->vdev);
@@ -1014,7 +1014,7 @@ int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *dis
     do_backend_phy:
             libxl__device_physdisk_major_minor(dev, &major, &minor);
             flexarray_append(back, "physical-device");
-            flexarray_append(back, libxl__sprintf(&gc, "%x:%x", major, minor));
+            flexarray_append(back, libxl__sprintf(gc, "%x:%x", major, minor));
 
             flexarray_append(back, "params");
             flexarray_append(back, dev);
@@ -1022,13 +1022,13 @@ int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *dis
             assert(device.backend_kind == LIBXL__DEVICE_KIND_VBD);
             break;
         case LIBXL_DISK_BACKEND_TAP:
-            dev = libxl__blktap_devpath(&gc, disk->pdev_path, disk->format);
+            dev = libxl__blktap_devpath(gc, disk->pdev_path, disk->format);
             if (!dev) {
                 rc = ERROR_FAIL;
                 goto out_free;
             }
             flexarray_append(back, "tapdisk-params");
-            flexarray_append(back, libxl__sprintf(&gc, "%s:%s",
+            flexarray_append(back, libxl__sprintf(gc, "%s:%s",
                 libxl__device_disk_string_of_format(disk->format),
                 disk->pdev_path));
 
@@ -1036,7 +1036,7 @@ int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *dis
             goto do_backend_phy;
         case LIBXL_DISK_BACKEND_QDISK:
             flexarray_append(back, "params");
-            flexarray_append(back, libxl__sprintf(&gc, "%s:%s",
+            flexarray_append(back, libxl__sprintf(gc, "%s:%s",
                           libxl__device_disk_string_of_format(disk->format), disk->pdev_path));
             assert(device.backend_kind == LIBXL__DEVICE_KIND_QDISK);
             break;
@@ -1047,15 +1047,15 @@ int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *dis
     }
 
     flexarray_append(back, "frontend-id");
-    flexarray_append(back, libxl__sprintf(&gc, "%d", domid));
+    flexarray_append(back, libxl__sprintf(gc, "%d", domid));
     flexarray_append(back, "online");
     flexarray_append(back, "1");
     flexarray_append(back, "removable");
-    flexarray_append(back, libxl__sprintf(&gc, "%d", (disk->removable) ? 1 : 0));
+    flexarray_append(back, libxl__sprintf(gc, "%d", (disk->removable) ? 1 : 0));
     flexarray_append(back, "bootable");
-    flexarray_append(back, libxl__sprintf(&gc, "%d", 1));
+    flexarray_append(back, libxl__sprintf(gc, "%d", 1));
     flexarray_append(back, "state");
-    flexarray_append(back, libxl__sprintf(&gc, "%d", 1));
+    flexarray_append(back, libxl__sprintf(gc, "%d", 1));
     flexarray_append(back, "dev");
     flexarray_append(back, disk->vdev);
     flexarray_append(back, "type");
@@ -1066,17 +1066,17 @@ int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *dis
     flexarray_append(back, disk->is_cdrom ? "cdrom" : "disk");
 
     flexarray_append(front, "backend-id");
-    flexarray_append(front, libxl__sprintf(&gc, "%d", disk->backend_domid));
+    flexarray_append(front, libxl__sprintf(gc, "%d", disk->backend_domid));
     flexarray_append(front, "state");
-    flexarray_append(front, libxl__sprintf(&gc, "%d", 1));
+    flexarray_append(front, libxl__sprintf(gc, "%d", 1));
     flexarray_append(front, "virtual-device");
-    flexarray_append(front, libxl__sprintf(&gc, "%d", device.devid));
+    flexarray_append(front, libxl__sprintf(gc, "%d", device.devid));
     flexarray_append(front, "device-type");
     flexarray_append(front, disk->is_cdrom ? "cdrom" : "disk");
 
-    libxl__device_generic_add(&gc, &device,
-                             libxl__xs_kvs_of_flexarray(&gc, back, back->count),
-                             libxl__xs_kvs_of_flexarray(&gc, front, front->count));
+    libxl__device_generic_add(gc, &device,
+                             libxl__xs_kvs_of_flexarray(gc, back, back->count),
+                             libxl__xs_kvs_of_flexarray(gc, front, front->count));
 
     rc = 0;
 
@@ -1084,39 +1084,39 @@ out_free:
     flexarray_free(back);
     flexarray_free(front);
 out:
-    libxl__free_all(&gc);
+    GC_FREE;
     return rc;
 }
 
 int libxl_device_disk_remove(libxl_ctx *ctx, uint32_t domid,
                              libxl_device_disk *disk)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     libxl__device device;
     int rc;
 
-    rc = libxl__device_from_disk(&gc, domid, disk, &device);
+    rc = libxl__device_from_disk(gc, domid, disk, &device);
     if (rc != 0) goto out;
 
-    rc = libxl__device_remove(&gc, &device, 1);
+    rc = libxl__device_remove(gc, &device, 1);
 out:
-    libxl__free_all(&gc);
+    GC_FREE;
     return rc;
 }
 
 int libxl_device_disk_destroy(libxl_ctx *ctx, uint32_t domid,
                               libxl_device_disk *disk)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     libxl__device device;
     int rc;
 
-    rc = libxl__device_from_disk(&gc, domid, disk, &device);
+    rc = libxl__device_from_disk(gc, domid, disk, &device);
     if (rc != 0) goto out;
 
-    rc = libxl__device_destroy(&gc, &device);
+    rc = libxl__device_destroy(gc, &device);
 out:
-    libxl__free_all(&gc);
+    GC_FREE;
     return rc;
 }
 
@@ -1168,27 +1168,27 @@ static void libxl__device_disk_from_xs_be(libxl__gc *gc,
 int libxl_devid_to_device_disk(libxl_ctx *ctx, uint32_t domid,
                                int devid, libxl_device_disk *disk)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     char *dompath, *path;
     int rc = ERROR_FAIL;
 
     libxl_device_disk_init(ctx, disk);
 
-    dompath = libxl__xs_get_dompath(&gc, domid);
+    dompath = libxl__xs_get_dompath(gc, domid);
     if (!dompath) {
         goto out;
     }
-    path = libxl__xs_read(&gc, XBT_NULL,
-                          libxl__sprintf(&gc, "%s/device/vbd/%d/backend",
+    path = libxl__xs_read(gc, XBT_NULL,
+                          libxl__sprintf(gc, "%s/device/vbd/%d/backend",
                                          dompath, devid));
     if (!path)
         goto out;
 
-    libxl__device_disk_from_xs_be(&gc, path, disk);
+    libxl__device_disk_from_xs_be(gc, path, disk);
 
     rc = 0;
 out:
-    libxl__free_all(&gc);
+    GC_FREE;
     return rc;
 }
 
@@ -1228,22 +1228,22 @@ static int libxl__append_disk_list_of_type(libxl__gc *gc,
 
 libxl_device_disk *libxl_device_disk_list(libxl_ctx *ctx, uint32_t domid, int *num)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     libxl_device_disk *disks = NULL;
     int rc;
 
     *num = 0;
 
-    rc = libxl__append_disk_list_of_type(&gc, domid, "vbd", &disks, num);
+    rc = libxl__append_disk_list_of_type(gc, domid, "vbd", &disks, num);
     if (rc) goto out_err;
 
-    rc = libxl__append_disk_list_of_type(&gc, domid, "tap", &disks, num);
+    rc = libxl__append_disk_list_of_type(gc, domid, "tap", &disks, num);
     if (rc) goto out_err;
 
-    rc = libxl__append_disk_list_of_type(&gc, domid, "qdisk", &disks, num);
+    rc = libxl__append_disk_list_of_type(gc, domid, "qdisk", &disks, num);
     if (rc) goto out_err;
 
-    libxl__free_all(&gc);
+    GC_FREE;
     return disks;
 
 out_err:
@@ -1259,35 +1259,35 @@ out_err:
 int libxl_device_disk_getinfo(libxl_ctx *ctx, uint32_t domid,
                               libxl_device_disk *disk, libxl_diskinfo *diskinfo)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     char *dompath, *diskpath;
     char *val;
 
-    dompath = libxl__xs_get_dompath(&gc, domid);
+    dompath = libxl__xs_get_dompath(gc, domid);
     diskinfo->devid = libxl__device_disk_dev_number(disk->vdev, NULL, NULL);
 
     /* tap devices entries in xenstore are written as vbd devices. */
-    diskpath = libxl__sprintf(&gc, "%s/device/vbd/%d", dompath, diskinfo->devid);
+    diskpath = libxl__sprintf(gc, "%s/device/vbd/%d", dompath, diskinfo->devid);
     diskinfo->backend = xs_read(ctx->xsh, XBT_NULL,
-                                libxl__sprintf(&gc, "%s/backend", diskpath), NULL);
+                                libxl__sprintf(gc, "%s/backend", diskpath), NULL);
     if (!diskinfo->backend) {
-        libxl__free_all(&gc);
+        GC_FREE;
         return ERROR_FAIL;
     }
-    val = libxl__xs_read(&gc, XBT_NULL, libxl__sprintf(&gc, "%s/backend-id", diskpath));
+    val = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/backend-id", diskpath));
     diskinfo->backend_id = val ? strtoul(val, NULL, 10) : -1;
-    val = libxl__xs_read(&gc, XBT_NULL, libxl__sprintf(&gc, "%s/state", diskpath));
+    val = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/state", diskpath));
     diskinfo->state = val ? strtoul(val, NULL, 10) : -1;
-    val = libxl__xs_read(&gc, XBT_NULL, libxl__sprintf(&gc, "%s/event-channel", diskpath));
+    val = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/event-channel", diskpath));
     diskinfo->evtch = val ? strtoul(val, NULL, 10) : -1;
-    val = libxl__xs_read(&gc, XBT_NULL, libxl__sprintf(&gc, "%s/ring-ref", diskpath));
+    val = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/ring-ref", diskpath));
     diskinfo->rref = val ? strtoul(val, NULL, 10) : -1;
     diskinfo->frontend = xs_read(ctx->xsh, XBT_NULL,
-                                 libxl__sprintf(&gc, "%s/frontend", diskinfo->backend), NULL);
-    val = libxl__xs_read(&gc, XBT_NULL, libxl__sprintf(&gc, "%s/frontend-id", diskinfo->backend));
+                                 libxl__sprintf(gc, "%s/frontend", diskinfo->backend), NULL);
+    val = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/frontend-id", diskinfo->backend));
     diskinfo->frontend_id = val ? strtoul(val, NULL, 10) : -1;
 
-    libxl__free_all(&gc);
+    GC_FREE;
     return 0;
 }
 
@@ -1331,12 +1331,12 @@ out:
 
 char * libxl_device_disk_local_attach(libxl_ctx *ctx, libxl_device_disk *disk)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     char *dev = NULL;
     char *ret = NULL;
     int rc;
 
-    rc = libxl__device_disk_set_backend(&gc, disk);
+    rc = libxl__device_disk_set_backend(gc, disk);
     if (rc) goto out;
 
     switch (disk->backend) {
@@ -1355,7 +1355,7 @@ char * libxl_device_disk_local_attach(libxl_ctx *ctx, libxl_device_disk *disk)
                 dev = disk->pdev_path;
                 break;
             case LIBXL_DISK_FORMAT_VHD:
-                dev = libxl__blktap_devpath(&gc, disk->pdev_path,
+                dev = libxl__blktap_devpath(gc, disk->pdev_path,
                                             disk->format);
                 break;
             case LIBXL_DISK_FORMAT_QCOW:
@@ -1386,7 +1386,7 @@ char * libxl_device_disk_local_attach(libxl_ctx *ctx, libxl_device_disk *disk)
  out:
     if (dev != NULL)
         ret = strdup(dev);
-    libxl__free_all(&gc);
+    GC_FREE;
     return ret;
 }
 
@@ -1448,7 +1448,7 @@ static int libxl__device_from_nic(libxl__gc *gc, uint32_t domid,
 
 int libxl_device_nic_add(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     flexarray_t *front;
     flexarray_t *back;
     libxl__device device;
@@ -1467,59 +1467,59 @@ int libxl_device_nic_add(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic)
     }
 
     if (nic->devid == -1) {
-        if (!(dompath = libxl__xs_get_dompath(&gc, domid))) {
+        if (!(dompath = libxl__xs_get_dompath(gc, domid))) {
             rc = ERROR_FAIL;
             goto out_free;
         }
-        if (!(l = libxl__xs_directory(&gc, XBT_NULL,
-                                     libxl__sprintf(&gc, "%s/device/vif", dompath), &nb))) {
+        if (!(l = libxl__xs_directory(gc, XBT_NULL,
+                                     libxl__sprintf(gc, "%s/device/vif", dompath), &nb))) {
             nic->devid = 0;
         } else {
             nic->devid = strtoul(l[nb - 1], NULL, 10) + 1;
         }
     }
 
-    rc = libxl__device_from_nic(&gc, domid, nic, &device);
+    rc = libxl__device_from_nic(gc, domid, nic, &device);
     if ( rc != 0 ) goto out_free;
 
     flexarray_append(back, "frontend-id");
-    flexarray_append(back, libxl__sprintf(&gc, "%d", domid));
+    flexarray_append(back, libxl__sprintf(gc, "%d", domid));
     flexarray_append(back, "online");
     flexarray_append(back, "1");
     flexarray_append(back, "state");
-    flexarray_append(back, libxl__sprintf(&gc, "%d", 1));
+    flexarray_append(back, libxl__sprintf(gc, "%d", 1));
     if (nic->script) {
         flexarray_append(back, "script");
         flexarray_append(back, nic->script[0]=='/' ? nic->script
-                         : libxl__sprintf(&gc, "%s/%s",
+                         : libxl__sprintf(gc, "%s/%s",
                                           libxl_xen_script_dir_path(),
                                           nic->script));
     }
     flexarray_append(back, "mac");
-    flexarray_append(back,libxl__sprintf(&gc,
+    flexarray_append(back,libxl__sprintf(gc,
                                     LIBXL_MAC_FMT, LIBXL_MAC_BYTES(nic->mac)));
     if (nic->ip) {
         flexarray_append(back, "ip");
-        flexarray_append(back, libxl__strdup(&gc, nic->ip));
+        flexarray_append(back, libxl__strdup(gc, nic->ip));
     }
 
     flexarray_append(back, "bridge");
-    flexarray_append(back, libxl__strdup(&gc, nic->bridge));
+    flexarray_append(back, libxl__strdup(gc, nic->bridge));
     flexarray_append(back, "handle");
-    flexarray_append(back, libxl__sprintf(&gc, "%d", nic->devid));
+    flexarray_append(back, libxl__sprintf(gc, "%d", nic->devid));
 
     flexarray_append(front, "backend-id");
-    flexarray_append(front, libxl__sprintf(&gc, "%d", nic->backend_domid));
+    flexarray_append(front, libxl__sprintf(gc, "%d", nic->backend_domid));
     flexarray_append(front, "state");
-    flexarray_append(front, libxl__sprintf(&gc, "%d", 1));
+    flexarray_append(front, libxl__sprintf(gc, "%d", 1));
     flexarray_append(front, "handle");
-    flexarray_append(front, libxl__sprintf(&gc, "%d", nic->devid));
+    flexarray_append(front, libxl__sprintf(gc, "%d", nic->devid));
     flexarray_append(front, "mac");
-    flexarray_append(front, libxl__sprintf(&gc,
+    flexarray_append(front, libxl__sprintf(gc,
                                     LIBXL_MAC_FMT, LIBXL_MAC_BYTES(nic->mac)));
-    libxl__device_generic_add(&gc, &device,
-                             libxl__xs_kvs_of_flexarray(&gc, back, back->count),
-                             libxl__xs_kvs_of_flexarray(&gc, front, front->count));
+    libxl__device_generic_add(gc, &device,
+                             libxl__xs_kvs_of_flexarray(gc, back, back->count),
+                             libxl__xs_kvs_of_flexarray(gc, front, front->count));
 
     /* FIXME: wait for plug */
     rc = 0;
@@ -1527,39 +1527,39 @@ out_free:
     flexarray_free(back);
     flexarray_free(front);
 out:
-    libxl__free_all(&gc);
+    GC_FREE;
     return rc;
 }
 
 int libxl_device_nic_remove(libxl_ctx *ctx, uint32_t domid,
                             libxl_device_nic *nic)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     libxl__device device;
     int rc;
 
-    rc = libxl__device_from_nic(&gc, domid, nic, &device);
+    rc = libxl__device_from_nic(gc, domid, nic, &device);
     if (rc != 0) goto out;
 
-    rc = libxl__device_remove(&gc, &device, 1);
+    rc = libxl__device_remove(gc, &device, 1);
 out:
-    libxl__free_all(&gc);
+    GC_FREE;
     return rc;
 }
 
 int libxl_device_nic_destroy(libxl_ctx *ctx, uint32_t domid,
                                   libxl_device_nic *nic)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     libxl__device device;
     int rc;
 
-    rc = libxl__device_from_nic(&gc, domid, nic, &device);
+    rc = libxl__device_from_nic(gc, domid, nic, &device);
     if (rc != 0) goto out;
 
-    rc = libxl__device_destroy(&gc, &device);
+    rc = libxl__device_destroy(gc, &device);
 out:
-    libxl__free_all(&gc);
+    GC_FREE;
     return rc;
 }
 
@@ -1607,26 +1607,26 @@ static void libxl__device_nic_from_xs_be(libxl__gc *gc,
 int libxl_devid_to_device_nic(libxl_ctx *ctx, uint32_t domid,
                               int devid, libxl_device_nic *nic)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     char *dompath, *path;
     int rc = ERROR_FAIL;
 
     memset(nic, 0, sizeof (libxl_device_nic));
-    dompath = libxl__xs_get_dompath(&gc, domid);
+    dompath = libxl__xs_get_dompath(gc, domid);
     if (!dompath)
         goto out;
 
-    path = libxl__xs_read(&gc, XBT_NULL,
-                          libxl__sprintf(&gc, "%s/device/vif/%d/backend",
+    path = libxl__xs_read(gc, XBT_NULL,
+                          libxl__sprintf(gc, "%s/device/vif/%d/backend",
                                          dompath, devid));
     if (!path)
         goto out;
 
-    libxl__device_nic_from_xs_be(&gc, path, nic);
+    libxl__device_nic_from_xs_be(gc, path, nic);
 
     rc = 0;
 out:
-    libxl__free_all(&gc);
+    GC_FREE;
     return rc;
 }
 
@@ -1665,16 +1665,16 @@ static int libxl__append_nic_list_of_type(libxl__gc *gc,
 
 libxl_device_nic *libxl_device_nic_list(libxl_ctx *ctx, uint32_t domid, int *num)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     libxl_device_nic *nics = NULL;
     int rc;
 
     *num = 0;
 
-    rc = libxl__append_nic_list_of_type(&gc, domid, "vif", &nics, num);
+    rc = libxl__append_nic_list_of_type(gc, domid, "vif", &nics, num);
     if (rc) goto out_err;
 
-    libxl__free_all(&gc);
+    GC_FREE;
     return nics;
 
 out_err:
@@ -1690,36 +1690,36 @@ out_err:
 int libxl_device_nic_getinfo(libxl_ctx *ctx, uint32_t domid,
                               libxl_device_nic *nic, libxl_nicinfo *nicinfo)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     char *dompath, *nicpath;
     char *val;
 
-    dompath = libxl__xs_get_dompath(&gc, domid);
+    dompath = libxl__xs_get_dompath(gc, domid);
     nicinfo->devid = nic->devid;
 
-    nicpath = libxl__sprintf(&gc, "%s/device/vif/%d", dompath, nicinfo->devid);
+    nicpath = libxl__sprintf(gc, "%s/device/vif/%d", dompath, nicinfo->devid);
     nicinfo->backend = xs_read(ctx->xsh, XBT_NULL,
-                                libxl__sprintf(&gc, "%s/backend", nicpath), NULL);
+                                libxl__sprintf(gc, "%s/backend", nicpath), NULL);
     if (!nicinfo->backend) {
-        libxl__free_all(&gc);
+        GC_FREE;
         return ERROR_FAIL;
     }
-    val = libxl__xs_read(&gc, XBT_NULL, libxl__sprintf(&gc, "%s/backend-id", nicpath));
+    val = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/backend-id", nicpath));
     nicinfo->backend_id = val ? strtoul(val, NULL, 10) : -1;
-    val = libxl__xs_read(&gc, XBT_NULL, libxl__sprintf(&gc, "%s/state", nicpath));
+    val = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/state", nicpath));
     nicinfo->state = val ? strtoul(val, NULL, 10) : -1;
-    val = libxl__xs_read(&gc, XBT_NULL, libxl__sprintf(&gc, "%s/event-channel", nicpath));
+    val = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/event-channel", nicpath));
     nicinfo->evtch = val ? strtoul(val, NULL, 10) : -1;
-    val = libxl__xs_read(&gc, XBT_NULL, libxl__sprintf(&gc, "%s/tx-ring-ref", nicpath));
+    val = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/tx-ring-ref", nicpath));
     nicinfo->rref_tx = val ? strtoul(val, NULL, 10) : -1;
-    val = libxl__xs_read(&gc, XBT_NULL, libxl__sprintf(&gc, "%s/rx-ring-ref", nicpath));
+    val = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/rx-ring-ref", nicpath));
     nicinfo->rref_rx = val ? strtoul(val, NULL, 10) : -1;
     nicinfo->frontend = xs_read(ctx->xsh, XBT_NULL,
-                                 libxl__sprintf(&gc, "%s/frontend", nicinfo->backend), NULL);
-    val = libxl__xs_read(&gc, XBT_NULL, libxl__sprintf(&gc, "%s/frontend-id", nicinfo->backend));
+                                 libxl__sprintf(gc, "%s/frontend", nicinfo->backend), NULL);
+    val = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/frontend-id", nicinfo->backend));
     nicinfo->frontend_id = val ? strtoul(val, NULL, 10) : -1;
 
-    libxl__free_all(&gc);
+    GC_FREE;
     return 0;
 }
 
@@ -1825,7 +1825,7 @@ static int libxl__device_from_vkb(libxl__gc *gc, uint32_t domid,
 
 int libxl_device_vkb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vkb *vkb)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     flexarray_t *front;
     flexarray_t *back;
     libxl__device device;
@@ -1842,64 +1842,64 @@ int libxl_device_vkb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vkb *vkb)
         goto out_free;
     }
 
-    rc = libxl__device_from_vkb(&gc, domid, vkb, &device);
+    rc = libxl__device_from_vkb(gc, domid, vkb, &device);
     if (rc != 0) goto out_free;
 
     flexarray_append(back, "frontend-id");
-    flexarray_append(back, libxl__sprintf(&gc, "%d", domid));
+    flexarray_append(back, libxl__sprintf(gc, "%d", domid));
     flexarray_append(back, "online");
     flexarray_append(back, "1");
     flexarray_append(back, "state");
-    flexarray_append(back, libxl__sprintf(&gc, "%d", 1));
+    flexarray_append(back, libxl__sprintf(gc, "%d", 1));
     flexarray_append(back, "domain");
-    flexarray_append(back, libxl__domid_to_name(&gc, domid));
+    flexarray_append(back, libxl__domid_to_name(gc, domid));
 
     flexarray_append(front, "backend-id");
-    flexarray_append(front, libxl__sprintf(&gc, "%d", vkb->backend_domid));
+    flexarray_append(front, libxl__sprintf(gc, "%d", vkb->backend_domid));
     flexarray_append(front, "state");
-    flexarray_append(front, libxl__sprintf(&gc, "%d", 1));
+    flexarray_append(front, libxl__sprintf(gc, "%d", 1));
 
-    libxl__device_generic_add(&gc, &device,
-                             libxl__xs_kvs_of_flexarray(&gc, back, back->count),
-                             libxl__xs_kvs_of_flexarray(&gc, front, front->count));
+    libxl__device_generic_add(gc, &device,
+                             libxl__xs_kvs_of_flexarray(gc, back, back->count),
+                             libxl__xs_kvs_of_flexarray(gc, front, front->count));
     rc = 0;
 out_free:
     flexarray_free(back);
     flexarray_free(front);
 out:
-    libxl__free_all(&gc);
+    GC_FREE;
     return rc;
 }
 
 int libxl_device_vkb_remove(libxl_ctx *ctx, uint32_t domid,
                             libxl_device_vkb *vkb)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     libxl__device device;
     int rc;
 
-    rc = libxl__device_from_vkb(&gc, domid, vkb, &device);
+    rc = libxl__device_from_vkb(gc, domid, vkb, &device);
     if (rc != 0) goto out;
 
-    rc = libxl__device_remove(&gc, &device, 1);
+    rc = libxl__device_remove(gc, &device, 1);
 out:
-    libxl__free_all(&gc);
+    GC_FREE;
     return rc;
 }
 
 int libxl_device_vkb_destroy(libxl_ctx *ctx, uint32_t domid,
                                   libxl_device_vkb *vkb)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     libxl__device device;
     int rc;
 
-    rc = libxl__device_from_vkb(&gc, domid, vkb, &device);
+    rc = libxl__device_from_vkb(gc, domid, vkb, &device);
     if (rc != 0) goto out;
 
-    rc = libxl__device_destroy(&gc, &device);
+    rc = libxl__device_destroy(gc, &device);
 out:
-    libxl__free_all(&gc);
+    GC_FREE;
     return rc;
 }
 
@@ -1935,7 +1935,7 @@ static int libxl__device_from_vfb(libxl__gc *gc, uint32_t domid,
 
 int libxl_device_vfb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vfb *vfb)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     flexarray_t *front;
     flexarray_t *back;
     libxl__device device;
@@ -1952,20 +1952,20 @@ int libxl_device_vfb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vfb *vfb)
         goto out_free;
     }
 
-    rc = libxl__device_from_vfb(&gc, domid, vfb, &device);
+    rc = libxl__device_from_vfb(gc, domid, vfb, &device);
     if (rc != 0) goto out_free;
 
-    flexarray_append_pair(back, "frontend-id", libxl__sprintf(&gc, "%d", domid));
+    flexarray_append_pair(back, "frontend-id", libxl__sprintf(gc, "%d", domid));
     flexarray_append_pair(back, "online", "1");
-    flexarray_append_pair(back, "state", libxl__sprintf(&gc, "%d", 1));
-    flexarray_append_pair(back, "domain", libxl__domid_to_name(&gc, domid));
-    flexarray_append_pair(back, "vnc", libxl__sprintf(&gc, "%d", vfb->vnc));
+    flexarray_append_pair(back, "state", libxl__sprintf(gc, "%d", 1));
+    flexarray_append_pair(back, "domain", libxl__domid_to_name(gc, domid));
+    flexarray_append_pair(back, "vnc", libxl__sprintf(gc, "%d", vfb->vnc));
     flexarray_append_pair(back, "vnclisten", vfb->vnclisten);
     flexarray_append_pair(back, "vncpasswd", vfb->vncpasswd);
-    flexarray_append_pair(back, "vncdisplay", libxl__sprintf(&gc, "%d", vfb->vncdisplay));
-    flexarray_append_pair(back, "vncunused", libxl__sprintf(&gc, "%d", vfb->vncunused));
-    flexarray_append_pair(back, "sdl", libxl__sprintf(&gc, "%d", vfb->sdl));
-    flexarray_append_pair(back, "opengl", libxl__sprintf(&gc, "%d", vfb->opengl));
+    flexarray_append_pair(back, "vncdisplay", libxl__sprintf(gc, "%d", vfb->vncdisplay));
+    flexarray_append_pair(back, "vncunused", libxl__sprintf(gc, "%d", vfb->vncunused));
+    flexarray_append_pair(back, "sdl", libxl__sprintf(gc, "%d", vfb->sdl));
+    flexarray_append_pair(back, "opengl", libxl__sprintf(gc, "%d", vfb->opengl));
     if (vfb->xauthority) {
         flexarray_append_pair(back, "xauthority", vfb->xauthority);
     }
@@ -1973,50 +1973,50 @@ int libxl_device_vfb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vfb *vfb)
         flexarray_append_pair(back, "display", vfb->display);
     }
 
-    flexarray_append_pair(front, "backend-id", libxl__sprintf(&gc, "%d", vfb->backend_domid));
-    flexarray_append_pair(front, "state", libxl__sprintf(&gc, "%d", 1));
+    flexarray_append_pair(front, "backend-id", libxl__sprintf(gc, "%d", vfb->backend_domid));
+    flexarray_append_pair(front, "state", libxl__sprintf(gc, "%d", 1));
 
-    libxl__device_generic_add(&gc, &device,
-                             libxl__xs_kvs_of_flexarray(&gc, back, back->count),
-                             libxl__xs_kvs_of_flexarray(&gc, front, front->count));
+    libxl__device_generic_add(gc, &device,
+                             libxl__xs_kvs_of_flexarray(gc, back, back->count),
+                             libxl__xs_kvs_of_flexarray(gc, front, front->count));
     rc = 0;
 out_free:
     flexarray_free(front);
     flexarray_free(back);
 out:
-    libxl__free_all(&gc);
+    GC_FREE;
     return rc;
 }
 
 int libxl_device_vfb_remove(libxl_ctx *ctx, uint32_t domid,
                             libxl_device_vfb *vfb)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     libxl__device device;
     int rc;
 
-    rc = libxl__device_from_vfb(&gc, domid, vfb, &device);
+    rc = libxl__device_from_vfb(gc, domid, vfb, &device);
     if (rc != 0) goto out;
 
-    rc = libxl__device_remove(&gc, &device, 1);
+    rc = libxl__device_remove(gc, &device, 1);
 out:
-    libxl__free_all(&gc);
+    GC_FREE;
     return rc;
 }
 
 int libxl_device_vfb_destroy(libxl_ctx *ctx, uint32_t domid,
                                   libxl_device_vfb *vfb)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     libxl__device device;
     int rc;
 
-    rc = libxl__device_from_vfb(&gc, domid, vfb, &device);
+    rc = libxl__device_from_vfb(gc, domid, vfb, &device);
     if (rc != 0) goto out;
 
-    rc = libxl__device_destroy(&gc, &device);
+    rc = libxl__device_destroy(gc, &device);
 out:
-    libxl__free_all(&gc);
+    GC_FREE;
     return rc;
 }
 
@@ -2024,13 +2024,13 @@ out:
 
 int libxl_domain_setmaxmem(libxl_ctx *ctx, uint32_t domid, uint32_t max_memkb)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     char *mem, *endptr;
     uint32_t memorykb;
-    char *dompath = libxl__xs_get_dompath(&gc, domid);
+    char *dompath = libxl__xs_get_dompath(gc, domid);
     int rc = 1;
 
-    mem = libxl__xs_read(&gc, XBT_NULL, libxl__sprintf(&gc, "%s/memory/target", dompath));
+    mem = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/memory/target", dompath));
     if (!mem) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "cannot get memory info from %s/memory/target\n", dompath);
         goto out;
@@ -2055,7 +2055,7 @@ int libxl_domain_setmaxmem(libxl_ctx *ctx, uint32_t domid, uint32_t max_memkb)
 
     rc = 0;
 out:
-    libxl__free_all(&gc);
+    GC_FREE;
     return rc;
 }
 
@@ -2163,12 +2163,12 @@ retry:
 int libxl_set_memory_target(libxl_ctx *ctx, uint32_t domid,
         int32_t target_memkb, int relative, int enforce)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     int rc = 1, abort = 0;
     uint32_t memorykb = 0, videoram = 0;
     uint32_t current_target_memkb = 0, new_target_memkb = 0;
     char *memmax, *endptr, *videoram_s = NULL, *target = NULL;
-    char *dompath = libxl__xs_get_dompath(&gc, domid);
+    char *dompath = libxl__xs_get_dompath(gc, domid);
     xc_domaininfo_t info;
     libxl_dominfo ptr;
     char *uuid;
@@ -2177,11 +2177,11 @@ int libxl_set_memory_target(libxl_ctx *ctx, uint32_t domid,
 retry_transaction:
     t = xs_transaction_start(ctx->xsh);
 
-    target = libxl__xs_read(&gc, t, libxl__sprintf(&gc,
+    target = libxl__xs_read(gc, t, libxl__sprintf(gc,
                 "%s/memory/target", dompath));
     if (!target && !domid) {
         xs_transaction_end(ctx->xsh, t, 1);
-        rc = libxl__fill_dom0_memory_info(&gc, &current_target_memkb);
+        rc = libxl__fill_dom0_memory_info(gc, &current_target_memkb);
         if (rc < 0) {
             abort = 1;
             goto out;
@@ -2203,7 +2203,7 @@ retry_transaction:
             goto out;
         }
     }
-    memmax = libxl__xs_read(&gc, t, libxl__sprintf(&gc,
+    memmax = libxl__xs_read(gc, t, libxl__sprintf(gc,
                 "%s/memory/static-max", dompath));
     if (!memmax) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
@@ -2243,7 +2243,7 @@ retry_transaction:
         abort = 1;
         goto out;
     }
-    videoram_s = libxl__xs_read(&gc, t, libxl__sprintf(&gc,
+    videoram_s = libxl__xs_read(gc, t, libxl__sprintf(gc,
                 "%s/memory/videoram", dompath));
     videoram = videoram_s ? atoi(videoram_s) : 0;
 
@@ -2272,7 +2272,7 @@ retry_transaction:
         goto out;
     }
 
-    libxl__xs_write(&gc, t, libxl__sprintf(&gc, "%s/memory/target",
+    libxl__xs_write(gc, t, libxl__sprintf(gc, "%s/memory/target",
                 dompath), "%"PRIu32, new_target_memkb);
     rc = xc_domain_getinfolist(ctx->xch, domid, 1, &info);
     if (rc != 1 || info.domain != domid) {
@@ -2280,8 +2280,8 @@ retry_transaction:
         goto out;
     }
     xcinfo2xlinfo(&info, &ptr);
-    uuid = libxl__uuid2string(&gc, ptr.uuid);
-    libxl__xs_write(&gc, t, libxl__sprintf(&gc, "/vm/%s/memory", uuid),
+    uuid = libxl__uuid2string(gc, ptr.uuid);
+    libxl__xs_write(gc, t, libxl__sprintf(gc, "/vm/%s/memory", uuid),
             "%"PRIu32, new_target_memkb / 1024);
 
 out:
@@ -2289,22 +2289,22 @@ out:
         if (errno == EAGAIN)
             goto retry_transaction;
 
-    libxl__free_all(&gc);
+    GC_FREE;
     return rc;
 }
 
 int libxl_get_memory_target(libxl_ctx *ctx, uint32_t domid, uint32_t *out_target)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     int rc = 1;
     char *target = NULL, *endptr = NULL;
-    char *dompath = libxl__xs_get_dompath(&gc, domid);
+    char *dompath = libxl__xs_get_dompath(gc, domid);
     uint32_t target_memkb;
 
-    target = libxl__xs_read(&gc, XBT_NULL, libxl__sprintf(&gc,
+    target = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc,
                 "%s/memory/target", dompath));
     if (!target && !domid) {
-        rc = libxl__fill_dom0_memory_info(&gc, &target_memkb);
+        rc = libxl__fill_dom0_memory_info(gc, &target_memkb);
         if (rc < 0)
             goto out;
     } else if (!target) {
@@ -2325,14 +2325,14 @@ int libxl_get_memory_target(libxl_ctx *ctx, uint32_t domid, uint32_t *out_target
     rc = 0;
 
 out:
-    libxl__free_all(&gc);
+    GC_FREE;
     return rc;
 }
 
 int libxl_domain_need_memory(libxl_ctx *ctx, libxl_domain_build_info *b_info,
         libxl_device_model_info *dm_info, uint32_t *need_memkb)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     int rc = ERROR_INVAL;
     *need_memkb = b_info->target_memkb;
     switch (b_info->type) {
@@ -2351,7 +2351,7 @@ int libxl_domain_need_memory(libxl_ctx *ctx, libxl_domain_build_info *b_info,
         *need_memkb += (2 * 1024) - (*need_memkb % (2 * 1024));
     rc = 0;
 out:
-    libxl__free_all(&gc);
+    GC_FREE;
     return rc;
 
 }
@@ -2361,12 +2361,12 @@ int libxl_get_free_memory(libxl_ctx *ctx, uint32_t *memkb)
     int rc = 0;
     libxl_physinfo info;
     uint32_t freemem_slack;
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
 
     rc = libxl_get_physinfo(ctx, &info);
     if (rc < 0)
         goto out;
-    rc = libxl__get_free_memory_slack(&gc, &freemem_slack);
+    rc = libxl__get_free_memory_slack(gc, &freemem_slack);
     if (rc < 0)
         goto out;
 
@@ -2376,7 +2376,7 @@ int libxl_get_free_memory(libxl_ctx *ctx, uint32_t *memkb)
         *memkb = 0;
 
 out:
-    libxl__free_all(&gc);
+    GC_FREE;
     return rc;
 }
 
@@ -2386,9 +2386,9 @@ int libxl_wait_for_free_memory(libxl_ctx *ctx, uint32_t domid, uint32_t
     int rc = 0;
     libxl_physinfo info;
     uint32_t freemem_slack;
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
 
-    rc = libxl__get_free_memory_slack(&gc, &freemem_slack);
+    rc = libxl__get_free_memory_slack(gc, &freemem_slack);
     if (rc < 0)
         goto out;
     while (wait_secs > 0) {
@@ -2405,7 +2405,7 @@ int libxl_wait_for_free_memory(libxl_ctx *ctx, uint32_t domid, uint32_t
     rc = ERROR_NOMEM;
 
 out:
-    libxl__free_all(&gc);
+    GC_FREE;
     return rc;
 }
 
@@ -2631,7 +2631,7 @@ int libxl_set_vcpuaffinity(libxl_ctx *ctx, uint32_t domid, uint32_t vcpuid,
 
 int libxl_set_vcpuonline(libxl_ctx *ctx, uint32_t domid, libxl_cpumap *cpumap)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     libxl_dominfo info;
     char *dompath;
     xs_transaction_t t;
@@ -2641,14 +2641,14 @@ int libxl_set_vcpuonline(libxl_ctx *ctx, uint32_t domid, libxl_cpumap *cpumap)
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "getting domain info list");
         goto out;
     }
-    if (!(dompath = libxl__xs_get_dompath(&gc, domid)))
+    if (!(dompath = libxl__xs_get_dompath(gc, domid)))
         goto out;
 
 retry_transaction:
     t = xs_transaction_start(ctx->xsh);
     for (i = 0; i <= info.vcpu_max_id; i++)
-        libxl__xs_write(&gc, t,
-                       libxl__sprintf(&gc, "%s/cpu/%u/availability", dompath, i),
+        libxl__xs_write(gc, t,
+                       libxl__sprintf(gc, "%s/cpu/%u/availability", dompath, i),
                        "%s", libxl_cpumap_test(cpumap, i) ? "online" : "offline");
     if (!xs_transaction_end(ctx->xsh, t, 0)) {
         if (errno == EAGAIN)
@@ -2656,7 +2656,7 @@ retry_transaction:
     } else
         rc = 0;
 out:
-    libxl__free_all(&gc);
+    GC_FREE;
     return rc;
 }
 
@@ -2776,12 +2776,12 @@ int libxl_send_trigger(libxl_ctx *ctx, uint32_t domid, char *trigger_name, uint3
 
 int libxl_send_sysrq(libxl_ctx *ctx, uint32_t domid, char sysrq)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
-    char *dompath = libxl__xs_get_dompath(&gc, domid);
+    GC_INIT(ctx);
+    char *dompath = libxl__xs_get_dompath(gc, domid);
 
-    libxl__xs_write(&gc, XBT_NULL, libxl__sprintf(&gc, "%s/control/sysrq", dompath), "%c", sysrq);
+    libxl__xs_write(gc, XBT_NULL, libxl__sprintf(gc, "%s/control/sysrq", dompath), "%c", sysrq);
 
-    libxl__free_all(&gc);
+    GC_FREE;
     return 0;
 }
 
@@ -2868,15 +2868,15 @@ void libxl_xen_console_read_finish(libxl_ctx *ctx,
 
 uint32_t libxl_vm_get_start_time(libxl_ctx *ctx, uint32_t domid)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
-    char *dompath = libxl__xs_get_dompath(&gc, domid);
+    GC_INIT(ctx);
+    char *dompath = libxl__xs_get_dompath(gc, domid);
     char *vm_path, *start_time;
     uint32_t ret;
 
     vm_path = libxl__xs_read(
-        &gc, XBT_NULL, libxl__sprintf(&gc, "%s/vm", dompath));
+        gc, XBT_NULL, libxl__sprintf(gc, "%s/vm", dompath));
     start_time = libxl__xs_read(
-        &gc, XBT_NULL, libxl__sprintf(&gc, "%s/start_time", vm_path));
+        gc, XBT_NULL, libxl__sprintf(gc, "%s/start_time", vm_path));
     if (start_time == NULL) {
         LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, -1,
                         "Can't get start time of domain '%d'", domid);
@@ -2884,7 +2884,7 @@ uint32_t libxl_vm_get_start_time(libxl_ctx *ctx, uint32_t domid)
     }else{
         ret = strtoul(start_time, NULL, 10);
     }
-    libxl__free_all(&gc);
+    GC_FREE;
     return ret;
 }
 
@@ -3037,15 +3037,15 @@ int libxl_create_cpupool(libxl_ctx *ctx, const char *name, int schedid,
                          libxl_cpumap cpumap, libxl_uuid *uuid,
                          uint32_t *poolid)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     int rc;
     int i;
     xs_transaction_t t;
     char *uuid_string;
 
-    uuid_string = libxl__uuid2string(&gc, *uuid);
+    uuid_string = libxl__uuid2string(gc, *uuid);
     if (!uuid_string) {
-        libxl__free_all(&gc);
+        GC_FREE;
         return ERROR_NOMEM;
     }
 
@@ -3053,7 +3053,7 @@ int libxl_create_cpupool(libxl_ctx *ctx, const char *name, int schedid,
     if (rc) {
         LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, rc,
            "Could not create cpupool");
-        libxl__free_all(&gc);
+        GC_FREE;
         return ERROR_FAIL;
     }
 
@@ -3064,7 +3064,7 @@ int libxl_create_cpupool(libxl_ctx *ctx, const char *name, int schedid,
                 LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, rc,
                     "Error moving cpu to cpupool");
                 libxl_cpupool_destroy(ctx, *poolid);
-                libxl__free_all(&gc);
+                GC_FREE;
                 return ERROR_FAIL;
             }
         }
@@ -3072,16 +3072,16 @@ int libxl_create_cpupool(libxl_ctx *ctx, const char *name, int schedid,
     for (;;) {
         t = xs_transaction_start(ctx->xsh);
 
-        xs_mkdir(ctx->xsh, t, libxl__sprintf(&gc, "/local/pool/%d", *poolid));
-        libxl__xs_write(&gc, t,
-                        libxl__sprintf(&gc, "/local/pool/%d/uuid", *poolid),
+        xs_mkdir(ctx->xsh, t, libxl__sprintf(gc, "/local/pool/%d", *poolid));
+        libxl__xs_write(gc, t,
+                        libxl__sprintf(gc, "/local/pool/%d/uuid", *poolid),
                         "%s", uuid_string);
-        libxl__xs_write(&gc, t,
-                        libxl__sprintf(&gc, "/local/pool/%d/name", *poolid),
+        libxl__xs_write(gc, t,
+                        libxl__sprintf(gc, "/local/pool/%d/name", *poolid),
                         "%s", name);
 
         if (xs_transaction_end(ctx->xsh, t, 0) || (errno != EAGAIN)) {
-            libxl__free_all(&gc);
+            GC_FREE;
             return 0;
         }
     }
@@ -3089,7 +3089,7 @@ int libxl_create_cpupool(libxl_ctx *ctx, const char *name, int schedid,
 
 int libxl_cpupool_destroy(libxl_ctx *ctx, uint32_t poolid)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     int rc, i;
     xc_cpupoolinfo_t *info;
     xs_transaction_t t;
@@ -3097,7 +3097,7 @@ int libxl_cpupool_destroy(libxl_ctx *ctx, uint32_t poolid)
 
     info = xc_cpupool_getinfo(ctx->xch, poolid);
     if (info == NULL) {
-        libxl__free_all(&gc);
+        GC_FREE;
         return ERROR_NOMEM;
     }
 
@@ -3131,7 +3131,7 @@ int libxl_cpupool_destroy(libxl_ctx *ctx, uint32_t poolid)
     for (;;) {
         t = xs_transaction_start(ctx->xsh);
 
-        xs_rm(ctx->xsh, XBT_NULL, libxl__sprintf(&gc, "/local/pool/%d", poolid));
+        xs_rm(ctx->xsh, XBT_NULL, libxl__sprintf(gc, "/local/pool/%d", poolid));
 
         if (xs_transaction_end(ctx->xsh, t, 0) || (errno != EAGAIN))
             break;
@@ -3143,21 +3143,21 @@ out1:
     libxl_cpumap_dispose(&cpumap);
 out:
     xc_cpupool_infofree(ctx->xch, info);
-    libxl__free_all(&gc);
+    GC_FREE;
 
     return rc;
 }
 
 int libxl_cpupool_rename(libxl_ctx *ctx, const char *name, uint32_t poolid)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     xs_transaction_t t;
     xc_cpupoolinfo_t *info;
     int rc;
 
     info = xc_cpupool_getinfo(ctx->xch, poolid);
     if (info == NULL) {
-        libxl__free_all(&gc);
+        GC_FREE;
         return ERROR_NOMEM;
     }
 
@@ -3170,8 +3170,8 @@ int libxl_cpupool_rename(libxl_ctx *ctx, const char *name, uint32_t poolid)
     for (;;) {
         t = xs_transaction_start(ctx->xsh);
 
-        libxl__xs_write(&gc, t,
-                        libxl__sprintf(&gc, "/local/pool/%d/name", poolid),
+        libxl__xs_write(gc, t,
+                        libxl__sprintf(gc, "/local/pool/%d/name", poolid),
                         "%s", name);
 
         if (xs_transaction_end(ctx->xsh, t, 0))
@@ -3186,7 +3186,7 @@ int libxl_cpupool_rename(libxl_ctx *ctx, const char *name, uint32_t poolid)
 
 out:
     xc_cpupool_infofree(ctx->xch, info);
-    libxl__free_all(&gc);
+    GC_FREE;
 
     return rc;
 }
@@ -3293,16 +3293,16 @@ out:
 
 int libxl_cpupool_movedomain(libxl_ctx *ctx, uint32_t poolid, uint32_t domid)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     int rc;
     char *dom_path;
     char *vm_path;
     char *poolname;
     xs_transaction_t t;
 
-    dom_path = libxl__xs_get_dompath(&gc, domid);
+    dom_path = libxl__xs_get_dompath(gc, domid);
     if (!dom_path) {
-        libxl__free_all(&gc);
+        GC_FREE;
         return ERROR_FAIL;
     }
 
@@ -3310,26 +3310,26 @@ int libxl_cpupool_movedomain(libxl_ctx *ctx, uint32_t poolid, uint32_t domid)
     if (rc) {
         LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, rc,
             "Error moving domain to cpupool");
-        libxl__free_all(&gc);
+        GC_FREE;
         return ERROR_FAIL;
     }
 
     for (;;) {
         t = xs_transaction_start(ctx->xsh);
 
-        poolname = libxl__cpupoolid_to_name(&gc, poolid);
-        vm_path = libxl__xs_read(&gc, XBT_NULL, libxl__sprintf(&gc, "%s/vm", dom_path));
+        poolname = libxl__cpupoolid_to_name(gc, poolid);
+        vm_path = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/vm", dom_path));
         if (!vm_path)
             break;
 
-        libxl__xs_write(&gc, t, libxl__sprintf(&gc, "%s/pool_name", vm_path),
+        libxl__xs_write(gc, t, libxl__sprintf(gc, "%s/pool_name", vm_path),
                         "%s", poolname);
 
         if (xs_transaction_end(ctx->xsh, t, 0) || (errno != EAGAIN))
             break;
     }
 
-    libxl__free_all(&gc);
+    GC_FREE;
     return 0;
 }
 
diff --git a/tools/libxl/libxl_bootloader.c b/tools/libxl/libxl_bootloader.c
index b8399a1..ce83b8e 100644
--- a/tools/libxl/libxl_bootloader.c
+++ b/tools/libxl/libxl_bootloader.c
@@ -328,7 +328,7 @@ int libxl_run_bootloader(libxl_ctx *ctx,
                          libxl_device_disk *disk,
                          uint32_t domid)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     int ret, rc = 0;
     char *fifo = NULL;
     char *diskpath = NULL;
@@ -388,7 +388,7 @@ int libxl_run_bootloader(libxl_ctx *ctx,
         goto out_close;
     }
 
-    args = make_bootloader_args(&gc, info, domid, fifo, diskpath);
+    args = make_bootloader_args(gc, info, domid, fifo, diskpath);
     if (args == NULL) {
         rc = ERROR_NOMEM;
         goto out_close;
@@ -411,8 +411,8 @@ int libxl_run_bootloader(libxl_ctx *ctx,
         goto out_close;
     }
 
-    dom_console_xs_path = libxl__sprintf(&gc, "%s/console/tty", libxl__xs_get_dompath(&gc, domid));
-    libxl__xs_write(&gc, XBT_NULL, dom_console_xs_path, "%s", dom_console_slave_tty_path);
+    dom_console_xs_path = libxl__sprintf(gc, "%s/console/tty", libxl__xs_get_dompath(gc, domid));
+    libxl__xs_write(gc, XBT_NULL, dom_console_xs_path, "%s", dom_console_slave_tty_path);
 
     pid = fork_exec_bootloader(&bootloader_fd, info->u.pv.bootloader, args);
     if (pid < 0) {
@@ -435,7 +435,7 @@ int libxl_run_bootloader(libxl_ctx *ctx,
 
     fcntl(fifo_fd, F_SETFL, O_NDELAY);
 
-    blout = bootloader_interact(&gc, xenconsoled_fd, bootloader_fd, fifo_fd);
+    blout = bootloader_interact(gc, xenconsoled_fd, bootloader_fd, fifo_fd);
     if (blout == NULL) {
         goto out_close;
     }
@@ -445,7 +445,7 @@ int libxl_run_bootloader(libxl_ctx *ctx,
         goto out_close;
     }
 
-    parse_bootloader_result(&gc, info, blout);
+    parse_bootloader_result(gc, info, blout);
 
     rc = 0;
 out_close:
@@ -472,7 +472,7 @@ out_close:
     free(args);
 
 out:
-    libxl__free_all(&gc);
+    GC_FREE;
     return rc;
 }
 
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index ccb56c7..69f10fe 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -670,20 +670,20 @@ error_out:
 int libxl_domain_create_new(libxl_ctx *ctx, libxl_domain_config *d_config,
                             libxl_console_ready cb, void *priv, uint32_t *domid)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     int rc;
-    rc = do_domain_create(&gc, d_config, cb, priv, domid, -1);
-    libxl__free_all(&gc);
+    rc = do_domain_create(gc, d_config, cb, priv, domid, -1);
+    GC_FREE;
     return rc;
 }
 
 int libxl_domain_create_restore(libxl_ctx *ctx, libxl_domain_config *d_config,
                                 libxl_console_ready cb, void *priv, uint32_t *domid, int restore_fd)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     int rc;
-    rc = do_domain_create(&gc, d_config, cb, priv, domid, restore_fd);
-    libxl__free_all(&gc);
+    rc = do_domain_create(gc, d_config, cb, priv, domid, restore_fd);
+    GC_FREE;
     return rc;
 }
 
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 96098de..b1ff967 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -730,7 +730,7 @@ int libxl_userdata_store(libxl_ctx *ctx, uint32_t domid,
                               const char *userdata_userid,
                               const uint8_t *data, int datalen)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     const char *filename;
     const char *newfilename;
     int e, rc;
@@ -738,18 +738,18 @@ int libxl_userdata_store(libxl_ctx *ctx, uint32_t domid,
     FILE *f = NULL;
     size_t rs;
 
-    filename = userdata_path(&gc, domid, userdata_userid, "d");
+    filename = userdata_path(gc, domid, userdata_userid, "d");
     if (!filename) {
         rc = ERROR_NOMEM;
         goto out;
     }
 
     if (!datalen) {
-        rc = userdata_delete(&gc, filename);
+        rc = userdata_delete(gc, filename);
         goto out;
     }
 
-    newfilename = userdata_path(&gc, domid, userdata_userid, "n");
+    newfilename = userdata_path(gc, domid, userdata_userid, "n");
     if (!newfilename) {
         rc = ERROR_NOMEM;
         goto out;
@@ -791,7 +791,7 @@ err:
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "cannot write %s for %s",
                  newfilename, filename);
 out:
-    libxl__free_all(&gc);
+    GC_FREE;
     return rc;
 }
 
@@ -799,13 +799,13 @@ int libxl_userdata_retrieve(libxl_ctx *ctx, uint32_t domid,
                                  const char *userdata_userid,
                                  uint8_t **data_r, int *datalen_r)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     const char *filename;
     int e, rc;
     int datalen = 0;
     void *data = 0;
 
-    filename = userdata_path(&gc, domid, userdata_userid, "d");
+    filename = userdata_path(gc, domid, userdata_userid, "d");
     if (!filename) {
         rc = ERROR_NOMEM;
         goto out;
@@ -827,7 +827,7 @@ int libxl_userdata_retrieve(libxl_ctx *ctx, uint32_t domid,
     if (datalen_r) *datalen_r = datalen;
     rc = 0;
 out:
-    libxl__free_all(&gc);
+    GC_FREE;
     return rc;
 }
 
diff --git a/tools/libxl/libxl_pci.c b/tools/libxl/libxl_pci.c
index 63c3050..120c239 100644
--- a/tools/libxl/libxl_pci.c
+++ b/tools/libxl/libxl_pci.c
@@ -483,7 +483,7 @@ static int is_assigned(libxl_device_pci *assigned, int num_assigned,
 
 libxl_device_pci *libxl_device_pci_list_assignable(libxl_ctx *ctx, int *num)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     libxl_device_pci *pcidevs = NULL, *new, *assigned;
     struct dirent *de;
     DIR *dir;
@@ -491,7 +491,7 @@ libxl_device_pci *libxl_device_pci_list_assignable(libxl_ctx *ctx, int *num)
 
     *num = 0;
 
-    rc = get_all_assigned_devices(&gc, &assigned, &num_assigned);
+    rc = get_all_assigned_devices(gc, &assigned, &num_assigned);
     if ( rc )
         goto out;
 
@@ -528,7 +528,7 @@ libxl_device_pci *libxl_device_pci_list_assignable(libxl_ctx *ctx, int *num)
 out_closedir:
     closedir(dir);
 out:
-    libxl__free_all(&gc);
+    GC_FREE;
     return pcidevs;
 }
 
@@ -782,10 +782,10 @@ static int libxl__device_pci_reset(libxl__gc *gc, unsigned int domain, unsigned
 
 int libxl_device_pci_add(libxl_ctx *ctx, uint32_t domid, libxl_device_pci *pcidev)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     int rc;
-    rc = libxl__device_pci_add(&gc, domid, pcidev, 0);
-    libxl__free_all(&gc);
+    rc = libxl__device_pci_add(gc, domid, pcidev, 0);
+    GC_FREE;
     return rc;
 }
 
@@ -1057,24 +1057,24 @@ out:
 
 int libxl_device_pci_remove(libxl_ctx *ctx, uint32_t domid, libxl_device_pci *pcidev)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     int rc;
 
-    rc = libxl__device_pci_remove_common(&gc, domid, pcidev, 0);
+    rc = libxl__device_pci_remove_common(gc, domid, pcidev, 0);
 
-    libxl__free_all(&gc);
+    GC_FREE;
     return rc;
 }
 
 int libxl_device_pci_destroy(libxl_ctx *ctx, uint32_t domid,
                                   libxl_device_pci *pcidev)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     int rc;
 
-    rc = libxl__device_pci_remove_common(&gc, domid, pcidev, 1);
+    rc = libxl__device_pci_remove_common(gc, domid, pcidev, 1);
 
-    libxl__free_all(&gc);
+    GC_FREE;
     return rc;
 }
 
@@ -1115,15 +1115,15 @@ static void libxl__device_pci_from_xs_be(libxl__gc *gc,
 
 libxl_device_pci *libxl_device_pci_list(libxl_ctx *ctx, uint32_t domid, int *num)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     char *be_path, *num_devs;
     int n, i;
     libxl_device_pci *pcidevs = NULL;
 
     *num = 0;
 
-    be_path = libxl__sprintf(&gc, "%s/backend/pci/%d/0", libxl__xs_get_dompath(&gc, 0), domid);
-    num_devs = libxl__xs_read(&gc, XBT_NULL, libxl__sprintf(&gc, "%s/num_devs", be_path));
+    be_path = libxl__sprintf(gc, "%s/backend/pci/%d/0", libxl__xs_get_dompath(gc, 0), domid);
+    num_devs = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/num_devs", be_path));
     if (!num_devs)
         goto out;
 
@@ -1131,11 +1131,11 @@ libxl_device_pci *libxl_device_pci_list(libxl_ctx *ctx, uint32_t domid, int *num
     pcidevs = calloc(n, sizeof(libxl_device_pci));
 
     for (i = 0; i < n; i++)
-        libxl__device_pci_from_xs_be(&gc, be_path, pcidevs + i, i);
+        libxl__device_pci_from_xs_be(gc, be_path, pcidevs + i, i);
 
     *num = n;
 out:
-    libxl__free_all(&gc);
+    GC_FREE;
     return pcidevs;
 }
 
diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
index c7696d7..60af98c 100644
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/libxl/libxl_qmp.c
@@ -94,7 +94,7 @@ static int store_serial_port_info(libxl__qmp_handler *qmp,
                                   const char *chardev,
                                   int port)
 {
-    libxl__gc gc = LIBXL_INIT_GC(qmp->ctx);
+    GC_INIT(qmp->ctx);
     char *path = NULL;
     int ret = 0;
 
@@ -102,12 +102,12 @@ static int store_serial_port_info(libxl__qmp_handler *qmp,
         return 0;
     }
 
-    path = libxl__xs_get_dompath(&gc, qmp->domid);
-    path = libxl__sprintf(&gc, "%s/serial/%d/tty", path, port);
+    path = libxl__xs_get_dompath(gc, qmp->domid);
+    path = libxl__sprintf(gc, "%s/serial/%d/tty", path, port);
 
-    ret = libxl__xs_write(&gc, XBT_NULL, path, "%s", chardev + 4);
+    ret = libxl__xs_write(gc, XBT_NULL, path, "%s", chardev + 4);
 
-    libxl__free_all(&gc);
+    GC_FREE;
     return ret;
 }
 
@@ -521,7 +521,7 @@ static int qmp_synchronous_send(libxl__qmp_handler *qmp, const char *cmd,
 {
     int id = 0;
     int ret = 0;
-    libxl__gc gc = LIBXL_INIT_GC(qmp->ctx);
+    GC_INIT(qmp->ctx);
     qmp_request_context context = { .rc = 0 };
 
     id = qmp_send(qmp, cmd, args, callback, opaque, &context);
@@ -531,7 +531,7 @@ static int qmp_synchronous_send(libxl__qmp_handler *qmp, const char *cmd,
     qmp->wait_for_id = id;
 
     while (qmp->wait_for_id == id) {
-        if ((ret = qmp_next(&gc, qmp)) < 0) {
+        if ((ret = qmp_next(gc, qmp)) < 0) {
             break;
         }
     }
@@ -540,7 +540,7 @@ static int qmp_synchronous_send(libxl__qmp_handler *qmp, const char *cmd,
         ret = context.rc;
     }
 
-    libxl__free_all(&gc);
+    GC_FREE;
 
     return ret;
 }
@@ -559,15 +559,15 @@ libxl__qmp_handler *libxl__qmp_initialize(libxl_ctx *ctx, uint32_t domid)
     int ret = 0;
     libxl__qmp_handler *qmp = NULL;
     char *qmp_socket;
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
 
     qmp = qmp_init_handler(ctx, domid);
 
-    qmp_socket = libxl__sprintf(&gc, "%s/qmp-libxl-%d",
+    qmp_socket = libxl__sprintf(gc, "%s/qmp-libxl-%d",
                                 libxl_run_dir_path(), domid);
     if ((ret = qmp_open(qmp, qmp_socket, QMP_SOCKET_CONNECT_TIMEOUT)) < 0) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "Connection error");
-        libxl__free_all(&gc);
+        GC_FREE;
         qmp_free_handler(qmp);
         return NULL;
     }
@@ -576,12 +576,12 @@ libxl__qmp_handler *libxl__qmp_initialize(libxl_ctx *ctx, uint32_t domid)
 
     /* Wait for the response to qmp_capabilities */
     while (!qmp->connected) {
-        if ((ret = qmp_next(&gc, qmp)) < 0) {
+        if ((ret = qmp_next(gc, qmp)) < 0) {
             break;
         }
     }
 
-    libxl__free_all(&gc);
+    GC_FREE;
     if (!qmp->connected) {
         LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Failed to connect to QMP");
         libxl__qmp_close(qmp);
@@ -626,9 +626,9 @@ static int pci_add_callback(libxl__qmp_handler *qmp,
 {
     libxl_device_pci *pcidev = opaque;
     const libxl__json_object *bus = NULL;
-    libxl__gc gc = LIBXL_INIT_GC(qmp->ctx);
+    GC_INIT(qmp->ctx);
     int i, j, rc = -1;
-    char *asked_id = libxl__sprintf(&gc, PCI_PT_QDEV_ID,
+    char *asked_id = libxl__sprintf(gc, PCI_PT_QDEV_ID,
                                     pcidev->bus, pcidev->dev, pcidev->func);
 
     for (i = 0; (bus = libxl__json_array_get(response, i)); i++) {
@@ -665,7 +665,7 @@ static int pci_add_callback(libxl__qmp_handler *qmp,
 
 
 out:
-    libxl__free_all(&gc);
+    GC_FREE;
     return rc;
 }
 
diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
index f1f2a6d..d36c737 100644
--- a/tools/libxl/libxl_utils.c
+++ b/tools/libxl/libxl_utils.c
@@ -186,29 +186,29 @@ char *libxl_schedid_to_name(libxl_ctx *ctx, int schedid)
 
 int libxl_get_stubdom_id(libxl_ctx *ctx, int guest_domid)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     char * stubdom_id_s;
     int ret;
 
-    stubdom_id_s = libxl__xs_read(&gc, XBT_NULL,
-                                 libxl__sprintf(&gc, "%s/image/device-model-domid",
-                                               libxl__xs_get_dompath(&gc, guest_domid)));
+    stubdom_id_s = libxl__xs_read(gc, XBT_NULL,
+                                 libxl__sprintf(gc, "%s/image/device-model-domid",
+                                               libxl__xs_get_dompath(gc, guest_domid)));
     if (stubdom_id_s)
         ret = atoi(stubdom_id_s);
     else
         ret = 0;
-    libxl__free_all(&gc);
+    GC_FREE;
     return ret;
 }
 
 int libxl_is_stubdom(libxl_ctx *ctx, uint32_t domid, uint32_t *target_domid)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     char *target, *endptr;
     uint32_t value;
     int ret = 0;
 
-    target = libxl__xs_read(&gc, XBT_NULL, libxl__sprintf(&gc, "%s/target", libxl__xs_get_dompath(&gc, domid)));
+    target = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/target", libxl__xs_get_dompath(gc, domid)));
     if (!target)
         goto out;
     value = strtol(target, &endptr, 10);
@@ -218,7 +218,7 @@ int libxl_is_stubdom(libxl_ctx *ctx, uint32_t domid, uint32_t *target_domid)
         *target_domid = value;
     ret = 1;
 out:
-    libxl__free_all(&gc);
+    GC_FREE;
     return ret;
 }
 
@@ -240,27 +240,27 @@ static int logrename(libxl__gc *gc, const char *old, const char *new)
 
 int libxl_create_logfile(libxl_ctx *ctx, char *name, char **full_name)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     struct stat stat_buf;
     char *logfile, *logfile_new;
     int i, rc;
 
-    logfile = libxl__sprintf(&gc, "/var/log/xen/%s.log", name);
+    logfile = libxl__sprintf(gc, "/var/log/xen/%s.log", name);
     if (stat(logfile, &stat_buf) == 0) {
         /* file exists, rotate */
-        logfile = libxl__sprintf(&gc, "/var/log/xen/%s.log.10", name);
+        logfile = libxl__sprintf(gc, "/var/log/xen/%s.log.10", name);
         unlink(logfile);
         for (i = 9; i > 0; i--) {
-            logfile = libxl__sprintf(&gc, "/var/log/xen/%s.log.%d", name, i);
-            logfile_new = libxl__sprintf(&gc, "/var/log/xen/%s.log.%d", name, i + 1);
-            rc = logrename(&gc, logfile, logfile_new);
+            logfile = libxl__sprintf(gc, "/var/log/xen/%s.log.%d", name, i);
+            logfile_new = libxl__sprintf(gc, "/var/log/xen/%s.log.%d", name, i + 1);
+            rc = logrename(gc, logfile, logfile_new);
             if (rc)
                 goto out;
         }
-        logfile = libxl__sprintf(&gc, "/var/log/xen/%s.log", name);
-        logfile_new = libxl__sprintf(&gc, "/var/log/xen/%s.log.1", name);
+        logfile = libxl__sprintf(gc, "/var/log/xen/%s.log", name);
+        logfile_new = libxl__sprintf(gc, "/var/log/xen/%s.log.1", name);
 
-        rc = logrename(&gc, logfile, logfile_new);
+        rc = logrename(gc, logfile, logfile_new);
         if (rc)
             goto out;
     } else {
@@ -272,7 +272,7 @@ int libxl_create_logfile(libxl_ctx *ctx, char *name, char **full_name)
     *full_name = strdup(logfile);
     rc = 0;
 out:
-    libxl__free_all(&gc);
+    GC_FREE;
     return rc;
 }
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 18:18:01 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 18: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.xensource.com>)
	id 1RXd6u-0000F7-Ge; Mon, 05 Dec 2011 18:17:52 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RXd6s-0000Ec-E0
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 18:17:50 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-16.tower-216.messagelabs.com!1323109024!6173686!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.5 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNDI4NTE=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNDI4NTE=\n,BODY_RANDOM_LONG
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27926 invoked from network); 5 Dec 2011 18:17:04 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-16.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 5 Dec 2011 18:17:04 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1323109023; l=499;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=MN4Y2CjP7pocvjEWtLeGHyI24hE=;
	b=wuhKo8mWvmUAmLcVuQKz6tG+B+XXGaLVTvDg6Ji8MNBKDzJS0ymw/a16ra6VnfE9gCQ
	3sXGun/VhBihcMeWEeNjJHuE70/IfjD5dyiSWfimbn8Ejc3Ijy9mfoLpmFavpns+c+b5k
	q8Y10cwnH8GGmZxg9qy42TL4VXexb4LAeMA=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFJjS0NG7Q=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-073-038.pools.arcor-ip.net [88.65.73.38])
	by smtp.strato.de (cohen mo15) (RZmta 26.10 AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id U0402dnB5GJIti ;
	Mon, 5 Dec 2011 19:16:53 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 3AB0218637; Mon,  5 Dec 2011 19:16:53 +0100 (CET)
Date: Mon, 5 Dec 2011 19:16:53 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Anthony PERARD <anthony.perard@citrix.com>
Message-ID: <20111205181652.GA31962@aepfle.de>
References: <1322070039-439-1-git-send-email-anthony.perard@citrix.com>
	<1322070039-439-4-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1322070039-439-4-git-send-email-anthony.perard@citrix.com>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: Xen Devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 3/3] libxl: Introduce migrate with the new
 QEMU.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Nov 23, Anthony PERARD wrote:

> +    case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
> +        fd2 = open(filename, O_WRONLY | O_CREAT | O_TRUNC);

I havent checked wether automated testing caught this, but:

In function 'open',
    inlined from 'libxl__domain_save_device_model' at libxl_dom.c:630:
/usr/include/bits/fcntl2.h:51: error: call to '__open_missing_mode' declared with attribute error: open with O_CREAT in second argument needs 3 arguments
make[3]: *** [libxl_dom.o] Error 1

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 18:18:01 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 18: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.xensource.com>)
	id 1RXd6u-0000F7-Ge; Mon, 05 Dec 2011 18:17:52 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RXd6s-0000Ec-E0
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 18:17:50 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-16.tower-216.messagelabs.com!1323109024!6173686!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.5 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNDI4NTE=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNDI4NTE=\n,BODY_RANDOM_LONG
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27926 invoked from network); 5 Dec 2011 18:17:04 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-16.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 5 Dec 2011 18:17:04 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1323109023; l=499;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=MN4Y2CjP7pocvjEWtLeGHyI24hE=;
	b=wuhKo8mWvmUAmLcVuQKz6tG+B+XXGaLVTvDg6Ji8MNBKDzJS0ymw/a16ra6VnfE9gCQ
	3sXGun/VhBihcMeWEeNjJHuE70/IfjD5dyiSWfimbn8Ejc3Ijy9mfoLpmFavpns+c+b5k
	q8Y10cwnH8GGmZxg9qy42TL4VXexb4LAeMA=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFJjS0NG7Q=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-073-038.pools.arcor-ip.net [88.65.73.38])
	by smtp.strato.de (cohen mo15) (RZmta 26.10 AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id U0402dnB5GJIti ;
	Mon, 5 Dec 2011 19:16:53 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 3AB0218637; Mon,  5 Dec 2011 19:16:53 +0100 (CET)
Date: Mon, 5 Dec 2011 19:16:53 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Anthony PERARD <anthony.perard@citrix.com>
Message-ID: <20111205181652.GA31962@aepfle.de>
References: <1322070039-439-1-git-send-email-anthony.perard@citrix.com>
	<1322070039-439-4-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1322070039-439-4-git-send-email-anthony.perard@citrix.com>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: Xen Devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 3/3] libxl: Introduce migrate with the new
 QEMU.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Nov 23, Anthony PERARD wrote:

> +    case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
> +        fd2 = open(filename, O_WRONLY | O_CREAT | O_TRUNC);

I havent checked wether automated testing caught this, but:

In function 'open',
    inlined from 'libxl__domain_save_device_model' at libxl_dom.c:630:
/usr/include/bits/fcntl2.h:51: error: call to '__open_missing_mode' declared with attribute error: open with O_CREAT in second argument needs 3 arguments
make[3]: *** [libxl_dom.o] Error 1

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 18:45:57 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 18:45:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXdXq-0000a5-BQ; Mon, 05 Dec 2011 18:45:42 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RXdXn-0000a0-EC
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 18:45:39 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-13.tower-174.messagelabs.com!1323110693!4342297!1
X-Originating-IP: [63.239.65.40]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28733 invoked from network); 5 Dec 2011 18:44:54 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-13.tower-174.messagelabs.com with SMTP;
	5 Dec 2011 18:44:54 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea02.nsa.gov (8.12.10/8.12.10) with ESMTP id
	pB5Iip9F024526; Mon, 5 Dec 2011 18:44:51 GMT
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id pB5Iip7i029920; 
	Mon, 5 Dec 2011 13:44:51 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: Keir Fraser <keir@xen.org>, olaf@aepfle.de
Date: Mon,  5 Dec 2011 13:45:10 -0500
Message-Id: <1323110710-18260-1-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.3
In-Reply-To: <20111205180538.GA31722@aepfle.de>
References: <20111205180538.GA31722@aepfle.de>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>, xen-devel@lists.xensource.com,
	JBeulich@suse.com
Subject: [Xen-devel] [PATCH v3] flask: Fix 32-bit compilation of label-pci
	tool
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

The 32-bit tools need to support 64-bit addresses, so use the correct
printf/scanf formats. Also, some systems declare fscanf with attribute
warn_unused_result, so check the result instead of relying on the value
of start being unmodified across a failed call.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 tools/flask/utils/label-pci.c |   17 +++++++++--------
 1 files changed, 9 insertions(+), 8 deletions(-)

diff --git a/tools/flask/utils/label-pci.c b/tools/flask/utils/label-pci.c
index 839ad61..da0cb61 100644
--- a/tools/flask/utils/label-pci.c
+++ b/tools/flask/utils/label-pci.c
@@ -15,6 +15,7 @@
 #include <sys/stat.h>
 #include <string.h>
 #include <unistd.h>
+#include <inttypes.h>
 #include <libflask.h>
 
 /* Pulled from linux/include/linux/ioport.h */
@@ -76,22 +77,22 @@ int main (int argCnt, char *argv[])
 		goto done;
 	}
 
-	while (fscanf(f, "0x%lx 0x%lx 0x%lx\n", &start, &end, &flags) == 3) {
+	while (fscanf(f, "0x%"SCNx64" 0x%"SCNx64" 0x%"SCNx64"\n", &start, &end, &flags) == 3) {
 		if (flags & IORESOURCE_IO) {
-			// printf("Port %lx-%lx\n", start, end);
+			// printf("Port %"PRIx64"-%"PRIx64"\n", start, end);
 			ret = flask_add_ioport(xch, start, end, argv[2]);
 			if (ret) {
-				fprintf(stderr, "flask_add_ioport %lx-%lx failed: %d\n",
+				fprintf(stderr, "flask_add_ioport %"PRIx64"-%"PRIx64" failed: %d\n",
 						start, end, ret);
 				err = 2;
 			}
 		} else if (flags & IORESOURCE_MEM) {
 			start >>= 12;
 			end >>= 12;
-			// printf("IOMEM %lx-%lx\n", start, end);
+			// printf("IOMEM %"PRIx64"-%"PRIx64"\n", start, end);
 			ret = flask_add_iomem(xch, start, end, argv[2]);
 			if (ret) {
-				fprintf(stderr, "flask_add_iomem %lx-%lx failed: %d\n",
+				fprintf(stderr, "flask_add_iomem %"PRIx64"-%"PRIx64" failed: %d\n",
 						start, end, ret);
 				err = 2;
 			}
@@ -104,12 +105,12 @@ int main (int argCnt, char *argv[])
 	f = fopen(buf, "r");
 	if (!f)
 		goto done;
-	start = 0;
-	fscanf(f, "%ld", &start);
+	if (fscanf(f, "%" SCNu64, &start) != 1)
+		start = 0;
 	if (start) {
 		ret = flask_add_pirq(xch, start, argv[2]);
 		if (ret) {
-			fprintf(stderr, "flask_add_pirq %ld failed: %d\n",
+			fprintf(stderr, "flask_add_pirq %"PRIu64" failed: %d\n",
 					start, ret);
 			err = 2;
 		}
-- 
1.7.7.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 18:45:57 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 18:45:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXdXq-0000a5-BQ; Mon, 05 Dec 2011 18:45:42 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RXdXn-0000a0-EC
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 18:45:39 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-13.tower-174.messagelabs.com!1323110693!4342297!1
X-Originating-IP: [63.239.65.40]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28733 invoked from network); 5 Dec 2011 18:44:54 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-13.tower-174.messagelabs.com with SMTP;
	5 Dec 2011 18:44:54 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea02.nsa.gov (8.12.10/8.12.10) with ESMTP id
	pB5Iip9F024526; Mon, 5 Dec 2011 18:44:51 GMT
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id pB5Iip7i029920; 
	Mon, 5 Dec 2011 13:44:51 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: Keir Fraser <keir@xen.org>, olaf@aepfle.de
Date: Mon,  5 Dec 2011 13:45:10 -0500
Message-Id: <1323110710-18260-1-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.3
In-Reply-To: <20111205180538.GA31722@aepfle.de>
References: <20111205180538.GA31722@aepfle.de>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>, xen-devel@lists.xensource.com,
	JBeulich@suse.com
Subject: [Xen-devel] [PATCH v3] flask: Fix 32-bit compilation of label-pci
	tool
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

The 32-bit tools need to support 64-bit addresses, so use the correct
printf/scanf formats. Also, some systems declare fscanf with attribute
warn_unused_result, so check the result instead of relying on the value
of start being unmodified across a failed call.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 tools/flask/utils/label-pci.c |   17 +++++++++--------
 1 files changed, 9 insertions(+), 8 deletions(-)

diff --git a/tools/flask/utils/label-pci.c b/tools/flask/utils/label-pci.c
index 839ad61..da0cb61 100644
--- a/tools/flask/utils/label-pci.c
+++ b/tools/flask/utils/label-pci.c
@@ -15,6 +15,7 @@
 #include <sys/stat.h>
 #include <string.h>
 #include <unistd.h>
+#include <inttypes.h>
 #include <libflask.h>
 
 /* Pulled from linux/include/linux/ioport.h */
@@ -76,22 +77,22 @@ int main (int argCnt, char *argv[])
 		goto done;
 	}
 
-	while (fscanf(f, "0x%lx 0x%lx 0x%lx\n", &start, &end, &flags) == 3) {
+	while (fscanf(f, "0x%"SCNx64" 0x%"SCNx64" 0x%"SCNx64"\n", &start, &end, &flags) == 3) {
 		if (flags & IORESOURCE_IO) {
-			// printf("Port %lx-%lx\n", start, end);
+			// printf("Port %"PRIx64"-%"PRIx64"\n", start, end);
 			ret = flask_add_ioport(xch, start, end, argv[2]);
 			if (ret) {
-				fprintf(stderr, "flask_add_ioport %lx-%lx failed: %d\n",
+				fprintf(stderr, "flask_add_ioport %"PRIx64"-%"PRIx64" failed: %d\n",
 						start, end, ret);
 				err = 2;
 			}
 		} else if (flags & IORESOURCE_MEM) {
 			start >>= 12;
 			end >>= 12;
-			// printf("IOMEM %lx-%lx\n", start, end);
+			// printf("IOMEM %"PRIx64"-%"PRIx64"\n", start, end);
 			ret = flask_add_iomem(xch, start, end, argv[2]);
 			if (ret) {
-				fprintf(stderr, "flask_add_iomem %lx-%lx failed: %d\n",
+				fprintf(stderr, "flask_add_iomem %"PRIx64"-%"PRIx64" failed: %d\n",
 						start, end, ret);
 				err = 2;
 			}
@@ -104,12 +105,12 @@ int main (int argCnt, char *argv[])
 	f = fopen(buf, "r");
 	if (!f)
 		goto done;
-	start = 0;
-	fscanf(f, "%ld", &start);
+	if (fscanf(f, "%" SCNu64, &start) != 1)
+		start = 0;
 	if (start) {
 		ret = flask_add_pirq(xch, start, argv[2]);
 		if (ret) {
-			fprintf(stderr, "flask_add_pirq %ld failed: %d\n",
+			fprintf(stderr, "flask_add_pirq %"PRIu64" failed: %d\n",
 					start, ret);
 			err = 2;
 		}
-- 
1.7.7.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 19:48:07 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 19:48:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXeVi-0001Bf-Ag; Mon, 05 Dec 2011 19:47:34 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RXeVh-0001BX-0T
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 19:47:33 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1323114407!749385!1
X-Originating-IP: [74.125.83.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5378 invoked from network); 5 Dec 2011 19:46:48 -0000
Received: from mail-ee0-f43.google.com (HELO mail-ee0-f43.google.com)
	(74.125.83.43)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Dec 2011 19:46:48 -0000
Received: by eeaq46 with SMTP id q46so6996213eea.30
	for <xen-devel@lists.xensource.com>;
	Mon, 05 Dec 2011 11:46:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=UNpqQlAtvCILe5v12oeBaMtE2ypjQob8alnVM0HJLFU=;
	b=Imn8vfSSuDfSmQ9aID9BWjdM059Yb3p7ybp4Y/cg8Mcf3M23Fq+H9QCSBuiH3Kc/im
	QwdLE5lZktaMp+7qBfRqFrNMkuShN/MCc8wi1GQgRiMQJ2niDBIaFU+OJlaDou4j4SjJ
	fpSeP1lHtd00qvuyPlh4P2p4FuAkCmXoHI3ec=
Received: by 10.14.10.206 with SMTP id 54mr1343699eev.154.1323114407141;
	Mon, 05 Dec 2011 11:46:47 -0800 (PST)
Received: from [192.168.1.3] (host81-155-119-104.range81-155.btcentralplus.com.
	[81.155.119.104])
	by mx.google.com with ESMTPS id z7sm30942801bka.1.2011.12.05.11.46.41
	(version=SSLv3 cipher=OTHER); Mon, 05 Dec 2011 11:46:44 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Mon, 05 Dec 2011 19:46:33 +0000
From: Keir Fraser <keir@xen.org>
To: Andrew Cooper <andrew.cooper3@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Message-ID: <CB02D019.34FCD%keir@xen.org>
Thread-Topic: [Xen-devel] KEXEC: fix kexec_get_range_compat to fail vocally
Thread-Index: Acyzhpcp+S45x7wEAk+Avx+sQdG8JQ==
In-Reply-To: <4EDCAC68.8060303@citrix.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] KEXEC: fix kexec_get_range_compat to fail vocally
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 05/12/2011 11:35, "Andrew Cooper" <andrew.cooper3@citrix.com> wrote:

> I am not sure that this is the only instance, but it is really not
> acceptable to hand truncated pointers or sizes for physical memory to dom0.

I applied as c/s 24358 but I changed the mask-checking arithmetic a bit. Not
only is it now shorter, I'm also more certain that it is correct: It looks
to me like ~((unsigned int)-1) performs the ~ before promotion to unsigned
long, hence this term ends up as 0 rather than 0xffffffff00000000.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 19:48:07 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 19:48:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXeVi-0001Bf-Ag; Mon, 05 Dec 2011 19:47:34 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RXeVh-0001BX-0T
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 19:47:33 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1323114407!749385!1
X-Originating-IP: [74.125.83.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5378 invoked from network); 5 Dec 2011 19:46:48 -0000
Received: from mail-ee0-f43.google.com (HELO mail-ee0-f43.google.com)
	(74.125.83.43)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Dec 2011 19:46:48 -0000
Received: by eeaq46 with SMTP id q46so6996213eea.30
	for <xen-devel@lists.xensource.com>;
	Mon, 05 Dec 2011 11:46:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=UNpqQlAtvCILe5v12oeBaMtE2ypjQob8alnVM0HJLFU=;
	b=Imn8vfSSuDfSmQ9aID9BWjdM059Yb3p7ybp4Y/cg8Mcf3M23Fq+H9QCSBuiH3Kc/im
	QwdLE5lZktaMp+7qBfRqFrNMkuShN/MCc8wi1GQgRiMQJ2niDBIaFU+OJlaDou4j4SjJ
	fpSeP1lHtd00qvuyPlh4P2p4FuAkCmXoHI3ec=
Received: by 10.14.10.206 with SMTP id 54mr1343699eev.154.1323114407141;
	Mon, 05 Dec 2011 11:46:47 -0800 (PST)
Received: from [192.168.1.3] (host81-155-119-104.range81-155.btcentralplus.com.
	[81.155.119.104])
	by mx.google.com with ESMTPS id z7sm30942801bka.1.2011.12.05.11.46.41
	(version=SSLv3 cipher=OTHER); Mon, 05 Dec 2011 11:46:44 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Mon, 05 Dec 2011 19:46:33 +0000
From: Keir Fraser <keir@xen.org>
To: Andrew Cooper <andrew.cooper3@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Message-ID: <CB02D019.34FCD%keir@xen.org>
Thread-Topic: [Xen-devel] KEXEC: fix kexec_get_range_compat to fail vocally
Thread-Index: Acyzhpcp+S45x7wEAk+Avx+sQdG8JQ==
In-Reply-To: <4EDCAC68.8060303@citrix.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] KEXEC: fix kexec_get_range_compat to fail vocally
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 05/12/2011 11:35, "Andrew Cooper" <andrew.cooper3@citrix.com> wrote:

> I am not sure that this is the only instance, but it is really not
> acceptable to hand truncated pointers or sizes for physical memory to dom0.

I applied as c/s 24358 but I changed the mask-checking arithmetic a bit. Not
only is it now shorter, I'm also more certain that it is correct: It looks
to me like ~((unsigned int)-1) performs the ~ before promotion to unsigned
long, hence this term ends up as 0 rather than 0xffffffff00000000.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 20:04:50 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 20: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.xensource.com>)
	id 1RXelr-0001U7-TJ; Mon, 05 Dec 2011 20:04:15 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RXelq-0001U0-DU
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 20:04:14 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1323115409!6283322!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjAyNg==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9711 invoked from network); 5 Dec 2011 20:03:29 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Dec 2011 20:03:29 -0000
X-IronPort-AV: E=Sophos;i="4.71,300,1320624000"; 
   d="scan'208";a="9299077"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Dec 2011 20:03:29 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 5 Dec 2011 20:03:29 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RXel6-0004N4-Pk;
	Mon, 05 Dec 2011 20:03:28 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RXel6-0004Um-P2;
	Mon, 05 Dec 2011 20:03:28 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10351-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 5 Dec 2011 20:03:28 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10351: regressions - trouble:
	blocked/broken/fail/pass
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10351 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10351/

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-i386-xl-winxpsp3-vcpus1  4 xen-install         fail REGR. vs. 10201
 test-amd64-i386-xl-win7-amd64  4 xen-install              fail REGR. vs. 10201
 test-amd64-i386-xend-winxpsp3  4 xen-install              fail REGR. vs. 10201
 test-amd64-i386-rhel6hvm-intel  4 xen-install             fail REGR. vs. 10201
 test-amd64-i386-pv            4 xen-install               fail REGR. vs. 10201
 test-amd64-i386-xl-credit2    4 xen-install               fail REGR. vs. 10201
 test-amd64-i386-xl-multivcpu  4 xen-install               fail REGR. vs. 10201
 test-amd64-i386-xl            4 xen-install               fail REGR. vs. 10201
 test-amd64-i386-rhel6hvm-amd  4 xen-install               fail REGR. vs. 10201
 test-amd64-i386-pair          6 xen-install/dst_host      fail REGR. vs. 10201
 test-amd64-i386-pair          5 xen-install/src_host      fail REGR. vs. 10201
 build-i386                    4 xen-build                 fail REGR. vs. 10201
 build-i386-oldkern            4 xen-build                 fail REGR. vs. 10201
 test-amd64-amd64-xl-sedf-pin  3 host-install(3)              broken
 test-amd64-i386-win-vcpus1    4 xen-install               fail REGR. vs. 10201
 test-amd64-i386-win           4 xen-install               fail REGR. vs. 10201
 test-amd64-amd64-win          8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-amd64-xl-win       8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-i386-xl-win-vcpus1  4 xen-install              fail REGR. vs. 10201

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf     14 guest-localmigrate/x10      fail pass in 10347

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-win7-amd64  7 windows-install              fail never pass
 test-i386-i386-xl-winxpsp3    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-i386-i386-pv             1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl             1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pair           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   never pass
 test-i386-i386-win            1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-win         1 xen-build-check(1)           blocked  n/a

version targeted for testing:
 xen                  af099b66c109
baseline version:
 xen                  62ff6a318c5d

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Anthony PERARD <anthony.perard@citrix.com>
  Brendan Cully <brendan@cs.ubc.ca>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@novell.com>
  Jan Beulich <jbeulich@suse.com>
  Jonathan Davies <jonathan.davies@citrix.com>
  juergen.gross@ts.fujitsu.com
  Keir Fraser <keir@xen.org>
  Liu, Jinsong <jinsong.liu@intel.com>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
  Philipp Hahn <hahn@univention.de>
  Shriram Rajagopalan <rshriram@cs.ubc.ca>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang2 <wei.wang2@amd.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   fail    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           fail    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           fail    
 test-i386-i386-xl                                            blocked 
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-i386-i386-pair                                          blocked 
 test-amd64-amd64-xl-sedf-pin                                 broken  
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           fail    
 test-i386-i386-pv                                            blocked 
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           blocked 
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        blocked 
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   blocked 


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 1272 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 20:04:50 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 20: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.xensource.com>)
	id 1RXelr-0001U7-TJ; Mon, 05 Dec 2011 20:04:15 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RXelq-0001U0-DU
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 20:04:14 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1323115409!6283322!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjAyNg==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9711 invoked from network); 5 Dec 2011 20:03:29 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Dec 2011 20:03:29 -0000
X-IronPort-AV: E=Sophos;i="4.71,300,1320624000"; 
   d="scan'208";a="9299077"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Dec 2011 20:03:29 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 5 Dec 2011 20:03:29 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RXel6-0004N4-Pk;
	Mon, 05 Dec 2011 20:03:28 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RXel6-0004Um-P2;
	Mon, 05 Dec 2011 20:03:28 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10351-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 5 Dec 2011 20:03:28 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10351: regressions - trouble:
	blocked/broken/fail/pass
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10351 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10351/

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-i386-xl-winxpsp3-vcpus1  4 xen-install         fail REGR. vs. 10201
 test-amd64-i386-xl-win7-amd64  4 xen-install              fail REGR. vs. 10201
 test-amd64-i386-xend-winxpsp3  4 xen-install              fail REGR. vs. 10201
 test-amd64-i386-rhel6hvm-intel  4 xen-install             fail REGR. vs. 10201
 test-amd64-i386-pv            4 xen-install               fail REGR. vs. 10201
 test-amd64-i386-xl-credit2    4 xen-install               fail REGR. vs. 10201
 test-amd64-i386-xl-multivcpu  4 xen-install               fail REGR. vs. 10201
 test-amd64-i386-xl            4 xen-install               fail REGR. vs. 10201
 test-amd64-i386-rhel6hvm-amd  4 xen-install               fail REGR. vs. 10201
 test-amd64-i386-pair          6 xen-install/dst_host      fail REGR. vs. 10201
 test-amd64-i386-pair          5 xen-install/src_host      fail REGR. vs. 10201
 build-i386                    4 xen-build                 fail REGR. vs. 10201
 build-i386-oldkern            4 xen-build                 fail REGR. vs. 10201
 test-amd64-amd64-xl-sedf-pin  3 host-install(3)              broken
 test-amd64-i386-win-vcpus1    4 xen-install               fail REGR. vs. 10201
 test-amd64-i386-win           4 xen-install               fail REGR. vs. 10201
 test-amd64-amd64-win          8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-amd64-xl-win       8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-i386-xl-win-vcpus1  4 xen-install              fail REGR. vs. 10201

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf     14 guest-localmigrate/x10      fail pass in 10347

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-win7-amd64  7 windows-install              fail never pass
 test-i386-i386-xl-winxpsp3    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-i386-i386-pv             1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl             1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pair           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   never pass
 test-i386-i386-win            1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-win         1 xen-build-check(1)           blocked  n/a

version targeted for testing:
 xen                  af099b66c109
baseline version:
 xen                  62ff6a318c5d

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Anthony PERARD <anthony.perard@citrix.com>
  Brendan Cully <brendan@cs.ubc.ca>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@novell.com>
  Jan Beulich <jbeulich@suse.com>
  Jonathan Davies <jonathan.davies@citrix.com>
  juergen.gross@ts.fujitsu.com
  Keir Fraser <keir@xen.org>
  Liu, Jinsong <jinsong.liu@intel.com>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
  Philipp Hahn <hahn@univention.de>
  Shriram Rajagopalan <rshriram@cs.ubc.ca>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang2 <wei.wang2@amd.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   fail    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           fail    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           fail    
 test-i386-i386-xl                                            blocked 
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-i386-i386-pair                                          blocked 
 test-amd64-amd64-xl-sedf-pin                                 broken  
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           fail    
 test-i386-i386-pv                                            blocked 
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           blocked 
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        blocked 
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   blocked 


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 1272 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 20:10:17 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 20:10:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXerD-0001cQ-M2; Mon, 05 Dec 2011 20:09:47 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1RXerC-0001cG-5L
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 20:09:46 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-6.tower-216.messagelabs.com!1323115741!6246071!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17940 invoked from network); 5 Dec 2011 20:09:01 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-6.tower-216.messagelabs.com with AES256-SHA encrypted SMTP;
	5 Dec 2011 20:09:01 -0000
Received: from 31-73-ftth.onsneteindhoven.nl ([88.159.73.31]:50679
	helo=[172.16.1.229])
	by smtp.eikelenboom.it with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32)
	(Exim 4.72) (envelope-from <linux@eikelenboom.it>)
	id 1RXeno-0005bf-Or; Mon, 05 Dec 2011 21:06:16 +0100
Date: Mon, 5 Dec 2011 21:08:59 +0100
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <411725096.20111205210859@eikelenboom.it>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com
Subject: [Xen-devel] Branch devel/acpi-cpufreq.v4 not yet in linux-next ?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi Konrad,

The devel/acpi-cpufreq.v4 branch doesn't seem to be merged into your linux-next branch yet.
Is it still targeted for 3.3 ?

I have been running your testing branch with linus his tree pulled on top of that, and it ran stable for me.
Thx for all the hard work upstreaming everything !

--
Sander


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 20:10:17 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 20:10:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXerD-0001cQ-M2; Mon, 05 Dec 2011 20:09:47 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1RXerC-0001cG-5L
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 20:09:46 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-6.tower-216.messagelabs.com!1323115741!6246071!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17940 invoked from network); 5 Dec 2011 20:09:01 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-6.tower-216.messagelabs.com with AES256-SHA encrypted SMTP;
	5 Dec 2011 20:09:01 -0000
Received: from 31-73-ftth.onsneteindhoven.nl ([88.159.73.31]:50679
	helo=[172.16.1.229])
	by smtp.eikelenboom.it with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32)
	(Exim 4.72) (envelope-from <linux@eikelenboom.it>)
	id 1RXeno-0005bf-Or; Mon, 05 Dec 2011 21:06:16 +0100
Date: Mon, 5 Dec 2011 21:08:59 +0100
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <411725096.20111205210859@eikelenboom.it>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com
Subject: [Xen-devel] Branch devel/acpi-cpufreq.v4 not yet in linux-next ?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi Konrad,

The devel/acpi-cpufreq.v4 branch doesn't seem to be merged into your linux-next branch yet.
Is it still targeted for 3.3 ?

I have been running your testing branch with linus his tree pulled on top of that, and it ran stable for me.
Thx for all the hard work upstreaming everything !

--
Sander


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 20:41:48 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 20: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.xensource.com>)
	id 1RXfLk-0001vN-Is; Mon, 05 Dec 2011 20:41:20 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <nathan@gt.net>) id 1RXfLi-0001vI-7a
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 20:41:18 +0000
X-Env-Sender: nathan@gt.net
X-Msg-Ref: server-13.tower-216.messagelabs.com!1323117631!6250444!1
X-Originating-IP: [208.70.244.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3362 invoked from network); 5 Dec 2011 20:40:33 -0000
Received: from gossamer.nmsrv.com (HELO gossamer.nmsrv.com) (208.70.244.21)
	by server-13.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 5 Dec 2011 20:40:33 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gt.net; h=message-id:date
	:from:mime-version:to:subject:content-type
	:content-transfer-encoding; s=mail; bh=9lNrxJkJyieIJkbMWf8r5BUxF
	9E=; b=tF+RGmMjLSDQduoKdA7ihmph7UdNBAndbMDthOnMujDGZ8rYwzu4eAsiv
	8ZGpSaRmkEtzwOV2HQmf6SYIqj6p3RL7qTiNYn1Z6geEq8wC5KiMjqkZfCz3ta0s
	+QbSz3vK2ThvanDboGVz5fA0IbxehlAvivszXrpwwuyFYlAP2c=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gt.net; h=message-id:date
	:from:mime-version:to:subject:content-type
	:content-transfer-encoding; q=dns; s=mail; b=Kv0TeQb0cjY41tZqkKB
	Cw1HBkxE3iPLBaK2W6uxlZfU9OtTdN8TnEzD3EjFmwJOUwZPD0xjN1MBBmxFFImL
	E/nU+P+AmnD89X8MASxpvVFCz4F984okZItz7FUzQazoRkKBqeUS8H0WfrZiuFV5
	99Z6dBljs9Ue9l55KPh0AMlI=
Received: (qmail 6779 invoked from network); 5 Dec 2011 20:40:31 -0000
X-AntiVirus: Clean
Received: from gateway.gossamer-threads.com (HELO ?192.168.1.152?)
	(nathan@gossamer-threads.com@208.70.247.145)
	by gossamer.nmsrv.com with ESMTPSA (DHE-RSA-CAMELLIA256-SHA encrypted);
	5 Dec 2011 20:40:31 -0000
Message-ID: <4EDD2C3D.3090807@gt.net>
Date: Mon, 05 Dec 2011 12:40:29 -0800
From: Nathan March <nathan@gt.net>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:9.0) Gecko/20111130 Thunderbird/9.0
MIME-Version: 1.0
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] Xenwatch crash on migration
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Running into an intermittant issue where the domU xenwatch thread gets 
stuck in D mode on migration:

root        17  0.0  0.0      0     0 ?        D    Sep13   0:00  \_ 
[xenwatch]

It was in S before attempting the migration and once it goes into D the 
only option is to destroy the VM.

Dom0 - xen 4.1.1, kernel 3.0.3
Domu - kernel 2.6.32.27, 64bit pvops

Haven't found any indication of an error anywhere, not sure how to debug 
further since I can't attach to the thread with anything.

Possibly related to "xen/pv-on-hvm kexec: prevent crash in 
xenwatch_thread() when stale watch events arrive"?

- Nathan

-- 
Nathan March<nathan@gt.net>
Gossamer Threads Inc. http://www.gossamer-threads.com/
Tel: (604) 687-5804 Fax: (604) 687-5806


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 20:41:48 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 20: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.xensource.com>)
	id 1RXfLk-0001vN-Is; Mon, 05 Dec 2011 20:41:20 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <nathan@gt.net>) id 1RXfLi-0001vI-7a
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 20:41:18 +0000
X-Env-Sender: nathan@gt.net
X-Msg-Ref: server-13.tower-216.messagelabs.com!1323117631!6250444!1
X-Originating-IP: [208.70.244.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3362 invoked from network); 5 Dec 2011 20:40:33 -0000
Received: from gossamer.nmsrv.com (HELO gossamer.nmsrv.com) (208.70.244.21)
	by server-13.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 5 Dec 2011 20:40:33 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gt.net; h=message-id:date
	:from:mime-version:to:subject:content-type
	:content-transfer-encoding; s=mail; bh=9lNrxJkJyieIJkbMWf8r5BUxF
	9E=; b=tF+RGmMjLSDQduoKdA7ihmph7UdNBAndbMDthOnMujDGZ8rYwzu4eAsiv
	8ZGpSaRmkEtzwOV2HQmf6SYIqj6p3RL7qTiNYn1Z6geEq8wC5KiMjqkZfCz3ta0s
	+QbSz3vK2ThvanDboGVz5fA0IbxehlAvivszXrpwwuyFYlAP2c=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gt.net; h=message-id:date
	:from:mime-version:to:subject:content-type
	:content-transfer-encoding; q=dns; s=mail; b=Kv0TeQb0cjY41tZqkKB
	Cw1HBkxE3iPLBaK2W6uxlZfU9OtTdN8TnEzD3EjFmwJOUwZPD0xjN1MBBmxFFImL
	E/nU+P+AmnD89X8MASxpvVFCz4F984okZItz7FUzQazoRkKBqeUS8H0WfrZiuFV5
	99Z6dBljs9Ue9l55KPh0AMlI=
Received: (qmail 6779 invoked from network); 5 Dec 2011 20:40:31 -0000
X-AntiVirus: Clean
Received: from gateway.gossamer-threads.com (HELO ?192.168.1.152?)
	(nathan@gossamer-threads.com@208.70.247.145)
	by gossamer.nmsrv.com with ESMTPSA (DHE-RSA-CAMELLIA256-SHA encrypted);
	5 Dec 2011 20:40:31 -0000
Message-ID: <4EDD2C3D.3090807@gt.net>
Date: Mon, 05 Dec 2011 12:40:29 -0800
From: Nathan March <nathan@gt.net>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:9.0) Gecko/20111130 Thunderbird/9.0
MIME-Version: 1.0
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] Xenwatch crash on migration
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Running into an intermittant issue where the domU xenwatch thread gets 
stuck in D mode on migration:

root        17  0.0  0.0      0     0 ?        D    Sep13   0:00  \_ 
[xenwatch]

It was in S before attempting the migration and once it goes into D the 
only option is to destroy the VM.

Dom0 - xen 4.1.1, kernel 3.0.3
Domu - kernel 2.6.32.27, 64bit pvops

Haven't found any indication of an error anywhere, not sure how to debug 
further since I can't attach to the thread with anything.

Possibly related to "xen/pv-on-hvm kexec: prevent crash in 
xenwatch_thread() when stale watch events arrive"?

- Nathan

-- 
Nathan March<nathan@gt.net>
Gossamer Threads Inc. http://www.gossamer-threads.com/
Tel: (604) 687-5804 Fax: (604) 687-5806


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 21:04:17 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 21: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.xensource.com>)
	id 1RXfhQ-0002TS-87; Mon, 05 Dec 2011 21:03:44 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1RXfhO-0002TC-AN
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 21:03:42 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-11.tower-182.messagelabs.com!1323118975!5976584!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28057 invoked from network); 5 Dec 2011 21:02:57 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-11.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 5 Dec 2011 21:02:57 -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
	pB5L2pRm008604
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Mon, 5 Dec 2011 16:02:51 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pB5L2o2q008602;
	Mon, 5 Dec 2011 16:02:50 -0500
Date: Mon, 5 Dec 2011 17:02:50 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Sander Eikelenboom <linux@eikelenboom.it>
Message-ID: <20111205210250.GA7784@andromeda.dapyr.net>
References: <411725096.20111205210859@eikelenboom.it>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <411725096.20111205210859@eikelenboom.it>
User-Agent: Mutt/1.5.9i
Cc: xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] Branch devel/acpi-cpufreq.v4 not yet in linux-next ?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Dec 05, 2011 at 09:08:59PM +0100, Sander Eikelenboom wrote:
> Hi Konrad,
> 
> The devel/acpi-cpufreq.v4 branch doesn't seem to be merged into your linux-next branch yet.
> Is it still targeted for 3.3 ?

It needs to be reviewed by ACPI folks before I can stick it in there.
And that has not yet completed :-(

> 
> I have been running your testing branch with linus his tree pulled on top of that, and it ran stable for me.

Neat! Were you using any fancy power saving modes/cpufreq options?
(ondeman, userspace, performance) or just let it run default?

> Thx for all the hard work upstreaming everything !

Thanks.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 21:04:17 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 21: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.xensource.com>)
	id 1RXfhQ-0002TS-87; Mon, 05 Dec 2011 21:03:44 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1RXfhO-0002TC-AN
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 21:03:42 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-11.tower-182.messagelabs.com!1323118975!5976584!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28057 invoked from network); 5 Dec 2011 21:02:57 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-11.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 5 Dec 2011 21:02:57 -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
	pB5L2pRm008604
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Mon, 5 Dec 2011 16:02:51 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pB5L2o2q008602;
	Mon, 5 Dec 2011 16:02:50 -0500
Date: Mon, 5 Dec 2011 17:02:50 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Sander Eikelenboom <linux@eikelenboom.it>
Message-ID: <20111205210250.GA7784@andromeda.dapyr.net>
References: <411725096.20111205210859@eikelenboom.it>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <411725096.20111205210859@eikelenboom.it>
User-Agent: Mutt/1.5.9i
Cc: xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] Branch devel/acpi-cpufreq.v4 not yet in linux-next ?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Dec 05, 2011 at 09:08:59PM +0100, Sander Eikelenboom wrote:
> Hi Konrad,
> 
> The devel/acpi-cpufreq.v4 branch doesn't seem to be merged into your linux-next branch yet.
> Is it still targeted for 3.3 ?

It needs to be reviewed by ACPI folks before I can stick it in there.
And that has not yet completed :-(

> 
> I have been running your testing branch with linus his tree pulled on top of that, and it ran stable for me.

Neat! Were you using any fancy power saving modes/cpufreq options?
(ondeman, userspace, performance) or just let it run default?

> Thx for all the hard work upstreaming everything !

Thanks.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 21:10:33 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 21:10:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXfnc-0002gO-2u; Mon, 05 Dec 2011 21:10:08 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1RXfnZ-0002g3-OX
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 21:10:06 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-7.tower-182.messagelabs.com!1323119358!5925636!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22936 invoked from network); 5 Dec 2011 21:09:19 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-7.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 5 Dec 2011 21:09:19 -0000
Received: from andromeda.dapyr.net (darnok@localhost [127.0.0.1])
	by andromeda.dapyr.net (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id
	pB5L98vG009346
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Mon, 5 Dec 2011 16:09:08 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pB5L98Fn009344;
	Mon, 5 Dec 2011 16:09:08 -0500
Date: Mon, 5 Dec 2011 17:09:08 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: "Taylor, Neal E" <Neal.Taylor@ca.com>
Message-ID: <20111205210907.GB7784@andromeda.dapyr.net>
References: <20111012035032.GB26092@phenom.oracle.com>
	<CAE1-PRfuo10T2iKJUNoY=Aj4S_TjUbiPT1jARv+iD7g+1qWuNg@mail.gmail.com>
	<CAE1-PRd9Kicm=dRtDmPKGXM8-fp62NyvDdpww38jA3Afwrt8+g@mail.gmail.com>
	<20111013181543.GF15499@phenom.oracle.com>
	<CAE1-PRfGTxeQ59jmHfB6bKKk2+B5bNnKhAvXoV-5P__+nkhgKQ@mail.gmail.com>
	<1318674976.11016.24.camel@dagon.hellion.org.uk>
	<CAE1-PRe3FZknxdCLkhkGbzd-i=y5eGMAwY+yoa36j61oHNcRSw@mail.gmail.com>
	<CAE1-PRcUkuBexHrCnCCNEA4m=yoC8qWjmtfsaSq0h9NUA6r2cw@mail.gmail.com>
	<1319616286.9436.1.camel@zakaz.uk.xensource.com>
	<3E243B26F475504B9BB0BCC9728B0DA629E14CDE@USILMS110A.ca.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="C7zPtVaVf+AK4Oqc"
Content-Disposition: inline
In-Reply-To: <3E243B26F475504B9BB0BCC9728B0DA629E14CDE@USILMS110A.ca.com>
User-Agent: Mutt/1.5.9i
Cc: Andy Burns <xen.lists@burns.me.uk>,
	xen-devel <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] PCI passthrough stopped working, brainache!
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--C7zPtVaVf+AK4Oqc
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Mon, Dec 05, 2011 at 04:10:39PM +0000, Taylor, Neal E wrote:
> Andy,
> 
> Did I mess the solution for this or are you still working with 'mem=3.99999G'?
> 
.. snip..
> 
> Konrad had some suggestions in
> <20111020034000.GA2401@phenom.dumpdata.com> which would be worth trying.
> (that mail was sent on Thursday but appears to have sat in a queue
> somewhere until after you sent this mail so just checking you've seen
> it).
> 

.. which resolves itself to:

http://article.gmane.org/gmane.comp.emulators.xen.devel/114063

and in 3). I mentioned a patch. See attached please

--C7zPtVaVf+AK4Oqc
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="swiotlb-debug.patch"

diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
index a59638b..d513c8d 100644
--- a/drivers/xen/Kconfig
+++ b/drivers/xen/Kconfig
@@ -105,4 +105,10 @@ config SWIOTLB_XEN
 	depends on PCI
 	select SWIOTLB
 
+config SWIOTLB_DEBUG
+	tristate "swiotlb debug facility"
+	default m
+	help
+	  Do not enable it unless you know what you are doing.
+
 endmenu
diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
index bbc1825..1dea490 100644
--- a/drivers/xen/Makefile
+++ b/drivers/xen/Makefile
@@ -16,6 +16,7 @@ obj-$(CONFIG_XENFS)			+= xenfs/
 obj-$(CONFIG_XEN_SYS_HYPERVISOR)	+= sys-hypervisor.o
 obj-$(CONFIG_XEN_PLATFORM_PCI)		+= xen-platform-pci.o
 obj-$(CONFIG_SWIOTLB_XEN)		+= swiotlb-xen.o
+obj-$(CONFIG_SWIOTLB_DEBUG)		+= dump_swiotlb.o
 obj-$(CONFIG_XEN_DOM0)			+= pci.o
 
 xen-evtchn-y				:= evtchn.o
diff --git a/drivers/xen/dump_swiotlb.c b/drivers/xen/dump_swiotlb.c
new file mode 100644
index 0000000..e0e4a0b
--- /dev/null
+++ b/drivers/xen/dump_swiotlb.c
@@ -0,0 +1,72 @@
+/*
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License v2.0 as published by
+ * the Free Software Foundation
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include <linux/module.h>
+#include <linux/string.h>
+#include <linux/types.h>
+#include <linux/init.h>
+#include <linux/stat.h>
+#include <linux/err.h>
+#include <linux/ctype.h>
+#include <linux/slab.h>
+#include <linux/limits.h>
+#include <linux/device.h>
+#include <linux/pci.h>
+#include <linux/blkdev.h>
+#include <linux/device.h>
+
+#include <linux/init.h>
+#include <linux/mm.h>
+#include <linux/fcntl.h>
+#include <linux/slab.h>
+#include <linux/kmod.h>
+#include <linux/major.h>
+#include <linux/highmem.h>
+#include <linux/blkdev.h>
+#include <linux/module.h>
+#include <linux/blkpg.h>
+#include <linux/buffer_head.h>
+#include <linux/mpage.h>
+#include <linux/mount.h>
+#include <linux/uio.h>
+#include <linux/namei.h>
+#include <asm/uaccess.h>
+
+#include <linux/pagemap.h>
+#include <linux/pagevec.h>
+
+#include <linux/swiotlb.h>
+#define DUMP_SWIOTLB_FUN  "0.1"
+
+MODULE_AUTHOR("Konrad Rzeszutek Wilk <konrad@darnok.org>");
+MODULE_DESCRIPTION("dump swiotlb");
+MODULE_LICENSE("GPL");
+MODULE_VERSION(DUMP_SWIOTLB_FUN);
+
+extern int xen_swiotlb_start_thread(void);
+extern void xen_swiotlb_stop_thread(void);
+static int __init dump_swiotlb_init(void)
+{
+	printk(KERN_INFO "Starting SWIOTLB debug thread.\n");
+	swiotlb_start_thread();
+	xen_swiotlb_start_thread();
+	return 0;
+}
+
+static void __exit dump_swiotlb_exit(void)
+{
+	swiotlb_stop_thread();
+	xen_swiotlb_stop_thread();
+}
+
+module_init(dump_swiotlb_init);
+module_exit(dump_swiotlb_exit);
diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index 6e8c15a..c833501 100644
--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -143,6 +143,63 @@ xen_swiotlb_fixup(void *buf, size_t size, unsigned long nslabs)
 	return 0;
 }
 
+#include <linux/percpu.h>
+struct xen_swiotlb_debug {
+	unsigned long alloc;
+	unsigned long dealloc;
+	char dev_name[64];
+};
+static DEFINE_PER_CPU(struct xen_swiotlb_debug, xen_tlb_debug);
+#include <linux/kthread.h>
+static int xen_swiotlb_debug_thread(void *arg)
+{
+	int cpu;
+	do {
+		set_current_state(TASK_INTERRUPTIBLE);
+		schedule_timeout_interruptible(HZ*10);
+
+		for_each_online_cpu(cpu) {
+			struct xen_swiotlb_debug *d;
+
+			d = &per_cpu(xen_tlb_debug, cpu);
+			/* Can't really happend.*/
+			if (!d)
+				continue;
+
+			if (d->dev_name[0] == 0)
+				continue;
+
+			printk(KERN_INFO "%u %s alloc coherent: %ld, free: %ld\n",
+				cpu,
+				d->dev_name ? d->dev_name : "?",
+				d->alloc, d->dealloc);
+
+			memset(d, 0, sizeof(struct xen_swiotlb_debug));
+		}
+
+	} while (!kthread_should_stop());
+	return 0;
+}
+static struct task_struct *xen_debug_thread = NULL;
+
+int xen_swiotlb_start_thread(void) {
+
+	if (xen_debug_thread)
+		return -EINVAL;
+	printk(KERN_INFO "%s: Go!\n",__func__);
+	xen_debug_thread =  kthread_run(xen_swiotlb_debug_thread, NULL, "xen_swiotlb_debug");
+	return 0;
+}
+EXPORT_SYMBOL_GPL(xen_swiotlb_start_thread);
+void xen_swiotlb_stop_thread(void) {
+
+	printk(KERN_INFO "%s: Stop!\n",__func__);
+	if (xen_debug_thread)
+		kthread_stop(xen_debug_thread);
+	xen_debug_thread = NULL;
+}
+EXPORT_SYMBOL_GPL(xen_swiotlb_stop_thread);
+
 void __init xen_swiotlb_init(int verbose)
 {
 	unsigned long bytes;
@@ -194,7 +251,14 @@ xen_swiotlb_alloc_coherent(struct device *hwdev, size_t size,
 	int order = get_order(size);
 	u64 dma_mask = DMA_BIT_MASK(32);
 	unsigned long vstart;
-
+	struct xen_swiotlb_debug *d;
+
+	preempt_disable();
+	d = &__get_cpu_var(xen_tlb_debug);
+	preempt_enable();
+	d->alloc++;
+	snprintf(d->dev_name, sizeof(d->dev_name), "%s %s",
+                dev_driver_string(hwdev), dev_name(hwdev));
 	/*
 	* Ignore region specifiers - the kernel's ideas of
 	* pseudo-phys memory layout has nothing to do with the
@@ -230,6 +294,14 @@ xen_swiotlb_free_coherent(struct device *hwdev, size_t size, void *vaddr,
 			  dma_addr_t dev_addr)
 {
 	int order = get_order(size);
+	struct xen_swiotlb_debug *d;
+
+	preempt_disable();
+	d = &__get_cpu_var(xen_tlb_debug);
+	preempt_enable();
+	d->dealloc++;
+	snprintf(d->dev_name, sizeof(d->dev_name), "%s %s",
+                dev_driver_string(hwdev), dev_name(hwdev));
 
 	if (dma_release_from_coherent(hwdev, order, vaddr))
 		return;
diff --git a/include/linux/swiotlb.h b/include/linux/swiotlb.h
index 445702c..0d2e049 100644
--- a/include/linux/swiotlb.h
+++ b/include/linux/swiotlb.h
@@ -26,6 +26,8 @@ extern void swiotlb_init(int verbose);
 extern void swiotlb_init_with_tbl(char *tlb, unsigned long nslabs, int verbose);
 extern unsigned long swioltb_nr_tbl(void);
 
+extern int swiotlb_start_thread(void);
+extern void swiotlb_stop_thread(void);
 /*
  * Enumeration for sync targets
  */
diff --git a/lib/swiotlb.c b/lib/swiotlb.c
index 99093b3..5446076 100644
--- a/lib/swiotlb.c
+++ b/lib/swiotlb.c
@@ -92,6 +92,74 @@ static DEFINE_SPINLOCK(io_tlb_lock);
 
 static int late_alloc;
 
+#include <linux/percpu.h>
+struct swiotlb_debug {
+	unsigned long bounce_to;
+	unsigned long bounce_from;
+	unsigned long bounce_slow;
+	unsigned long map;
+	unsigned long unmap;
+	unsigned long sync;
+	char dev_name[64];
+};
+static DEFINE_PER_CPU(struct swiotlb_debug, tlb_debug);
+#include <linux/kthread.h>
+static int swiotlb_debug_thread(void *arg)
+{
+	int cpu;
+	int size = io_tlb_nslabs;
+	do {
+		int i;
+		unsigned long filled = 0;
+		set_current_state(TASK_INTERRUPTIBLE);
+		schedule_timeout_interruptible(HZ*5);
+
+		for_each_online_cpu(cpu) {
+			struct swiotlb_debug *d = &per_cpu(tlb_debug, cpu);
+			/* Can't really happend.*/
+			if (!d)
+				continue;
+			if (d->dev_name[0] == 0)
+				continue;
+
+			printk(KERN_INFO "%d [%s] bounce: from:%ld(slow:%ld)to:%ld map:%ld unmap:%ld sync:%ld\n",
+				cpu,
+				d->dev_name ? d->dev_name : "?",
+				d->bounce_from,
+				d->bounce_slow,
+				d->bounce_to,
+				d->map, d->unmap, d->sync);
+			memset(d, 0, sizeof(struct swiotlb_debug));
+		}
+		/* Very crude calculation. */
+		for (i = 0; i < size; i++) {
+			if (io_tlb_list[i] == 0)
+				filled++;
+		}
+		printk(KERN_INFO "SWIOTLB is %ld%% full\n", (filled * 100) / size);
+
+	} while (!kthread_should_stop());
+	return 0;
+}
+static struct task_struct *debug_thread = NULL;
+
+int swiotlb_start_thread(void) {
+
+	if (debug_thread)
+		return -EINVAL;
+	printk(KERN_INFO "%s: Go!\n",__func__);
+	debug_thread =  kthread_run(swiotlb_debug_thread, NULL, "swiotlb_debug");
+}
+EXPORT_SYMBOL_GPL(swiotlb_start_thread);
+void swiotlb_stop_thread(void) {
+
+	printk(KERN_INFO "%s: Stop!\n",__func__);
+	if (debug_thread)
+		kthread_stop(debug_thread);
+	debug_thread = NULL;
+}
+EXPORT_SYMBOL_GPL(swiotlb_stop_thread);
+
 static int __init
 setup_io_tlb_npages(char *str)
 {
@@ -166,6 +234,7 @@ void __init swiotlb_init_with_tbl(char *tlb, unsigned long nslabs, int verbose)
 		panic("Cannot allocate SWIOTLB overflow buffer!\n");
 	if (verbose)
 		swiotlb_print_info();
+
 }
 
 /*
@@ -336,6 +405,7 @@ void swiotlb_bounce(phys_addr_t phys, char *dma_addr, size_t size,
 		    enum dma_data_direction dir)
 {
 	unsigned long pfn = PFN_DOWN(phys);
+	struct swiotlb_debug *d = &__get_cpu_var(tlb_debug);
 
 	if (PageHighMem(pfn_to_page(pfn))) {
 		/* The buffer does not have a mapping.  Map it in and copy */
@@ -362,11 +432,16 @@ void swiotlb_bounce(phys_addr_t phys, char *dma_addr, size_t size,
 			dma_addr += sz;
 			offset = 0;
 		}
+		d->bounce_slow++;
 	} else {
-		if (dir == DMA_TO_DEVICE)
+		if (dir == DMA_TO_DEVICE) {
 			memcpy(dma_addr, phys_to_virt(phys), size);
-		else
+			d->bounce_to++;
+		}
+		else {
 			memcpy(phys_to_virt(phys), dma_addr, size);
+			d->bounce_from++;
+		}
 	}
 }
 EXPORT_SYMBOL_GPL(swiotlb_bounce);
@@ -471,7 +546,15 @@ found:
 		io_tlb_orig_addr[index+i] = phys + (i << IO_TLB_SHIFT);
 	if (dir == DMA_TO_DEVICE || dir == DMA_BIDIRECTIONAL)
 		swiotlb_bounce(phys, dma_addr, size, DMA_TO_DEVICE);
-
+	{
+		struct swiotlb_debug *d;
+		preempt_disable();
+		d = &__get_cpu_var(tlb_debug);
+		preempt_enable();
+		d->map++;
+		snprintf(d->dev_name, sizeof(d->dev_name), "%s %s",
+                	dev_driver_string(hwdev), dev_name(hwdev));
+	}
 	return dma_addr;
 }
 EXPORT_SYMBOL_GPL(swiotlb_tbl_map_single);
@@ -531,6 +614,15 @@ swiotlb_tbl_unmap_single(struct device *hwdev, char *dma_addr, size_t size,
 			io_tlb_list[i] = ++count;
 	}
 	spin_unlock_irqrestore(&io_tlb_lock, flags);
+	{
+		struct swiotlb_debug *d;
+		preempt_disable();
+		d = &__get_cpu_var(tlb_debug);
+		preempt_enable();
+		d->unmap++;
+		snprintf(d->dev_name, sizeof(d->dev_name), "%s %s",
+                	dev_driver_string(hwdev), dev_name(hwdev));
+	}
 }
 EXPORT_SYMBOL_GPL(swiotlb_tbl_unmap_single);
 
@@ -541,7 +633,13 @@ swiotlb_tbl_sync_single(struct device *hwdev, char *dma_addr, size_t size,
 {
 	int index = (dma_addr - io_tlb_start) >> IO_TLB_SHIFT;
 	phys_addr_t phys = io_tlb_orig_addr[index];
-
+	struct swiotlb_debug *d;
+	preempt_disable();
+	d = &__get_cpu_var(tlb_debug);
+	preempt_enable();
+	d->sync++;
+	snprintf(d->dev_name, sizeof(d->dev_name), "%s %s",
+               	dev_driver_string(hwdev), dev_name(hwdev));
 	phys += ((unsigned long)dma_addr & ((1 << IO_TLB_SHIFT) - 1));
 
 	switch (target) {

--C7zPtVaVf+AK4Oqc
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--C7zPtVaVf+AK4Oqc--


From xen-devel-bounces@lists.xensource.com Mon Dec 05 21:10:33 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 21:10:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXfnc-0002gO-2u; Mon, 05 Dec 2011 21:10:08 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1RXfnZ-0002g3-OX
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 21:10:06 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-7.tower-182.messagelabs.com!1323119358!5925636!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22936 invoked from network); 5 Dec 2011 21:09:19 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-7.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 5 Dec 2011 21:09:19 -0000
Received: from andromeda.dapyr.net (darnok@localhost [127.0.0.1])
	by andromeda.dapyr.net (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id
	pB5L98vG009346
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Mon, 5 Dec 2011 16:09:08 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pB5L98Fn009344;
	Mon, 5 Dec 2011 16:09:08 -0500
Date: Mon, 5 Dec 2011 17:09:08 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: "Taylor, Neal E" <Neal.Taylor@ca.com>
Message-ID: <20111205210907.GB7784@andromeda.dapyr.net>
References: <20111012035032.GB26092@phenom.oracle.com>
	<CAE1-PRfuo10T2iKJUNoY=Aj4S_TjUbiPT1jARv+iD7g+1qWuNg@mail.gmail.com>
	<CAE1-PRd9Kicm=dRtDmPKGXM8-fp62NyvDdpww38jA3Afwrt8+g@mail.gmail.com>
	<20111013181543.GF15499@phenom.oracle.com>
	<CAE1-PRfGTxeQ59jmHfB6bKKk2+B5bNnKhAvXoV-5P__+nkhgKQ@mail.gmail.com>
	<1318674976.11016.24.camel@dagon.hellion.org.uk>
	<CAE1-PRe3FZknxdCLkhkGbzd-i=y5eGMAwY+yoa36j61oHNcRSw@mail.gmail.com>
	<CAE1-PRcUkuBexHrCnCCNEA4m=yoC8qWjmtfsaSq0h9NUA6r2cw@mail.gmail.com>
	<1319616286.9436.1.camel@zakaz.uk.xensource.com>
	<3E243B26F475504B9BB0BCC9728B0DA629E14CDE@USILMS110A.ca.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="C7zPtVaVf+AK4Oqc"
Content-Disposition: inline
In-Reply-To: <3E243B26F475504B9BB0BCC9728B0DA629E14CDE@USILMS110A.ca.com>
User-Agent: Mutt/1.5.9i
Cc: Andy Burns <xen.lists@burns.me.uk>,
	xen-devel <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] PCI passthrough stopped working, brainache!
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--C7zPtVaVf+AK4Oqc
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Mon, Dec 05, 2011 at 04:10:39PM +0000, Taylor, Neal E wrote:
> Andy,
> 
> Did I mess the solution for this or are you still working with 'mem=3.99999G'?
> 
.. snip..
> 
> Konrad had some suggestions in
> <20111020034000.GA2401@phenom.dumpdata.com> which would be worth trying.
> (that mail was sent on Thursday but appears to have sat in a queue
> somewhere until after you sent this mail so just checking you've seen
> it).
> 

.. which resolves itself to:

http://article.gmane.org/gmane.comp.emulators.xen.devel/114063

and in 3). I mentioned a patch. See attached please

--C7zPtVaVf+AK4Oqc
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="swiotlb-debug.patch"

diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
index a59638b..d513c8d 100644
--- a/drivers/xen/Kconfig
+++ b/drivers/xen/Kconfig
@@ -105,4 +105,10 @@ config SWIOTLB_XEN
 	depends on PCI
 	select SWIOTLB
 
+config SWIOTLB_DEBUG
+	tristate "swiotlb debug facility"
+	default m
+	help
+	  Do not enable it unless you know what you are doing.
+
 endmenu
diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
index bbc1825..1dea490 100644
--- a/drivers/xen/Makefile
+++ b/drivers/xen/Makefile
@@ -16,6 +16,7 @@ obj-$(CONFIG_XENFS)			+= xenfs/
 obj-$(CONFIG_XEN_SYS_HYPERVISOR)	+= sys-hypervisor.o
 obj-$(CONFIG_XEN_PLATFORM_PCI)		+= xen-platform-pci.o
 obj-$(CONFIG_SWIOTLB_XEN)		+= swiotlb-xen.o
+obj-$(CONFIG_SWIOTLB_DEBUG)		+= dump_swiotlb.o
 obj-$(CONFIG_XEN_DOM0)			+= pci.o
 
 xen-evtchn-y				:= evtchn.o
diff --git a/drivers/xen/dump_swiotlb.c b/drivers/xen/dump_swiotlb.c
new file mode 100644
index 0000000..e0e4a0b
--- /dev/null
+++ b/drivers/xen/dump_swiotlb.c
@@ -0,0 +1,72 @@
+/*
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License v2.0 as published by
+ * the Free Software Foundation
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include <linux/module.h>
+#include <linux/string.h>
+#include <linux/types.h>
+#include <linux/init.h>
+#include <linux/stat.h>
+#include <linux/err.h>
+#include <linux/ctype.h>
+#include <linux/slab.h>
+#include <linux/limits.h>
+#include <linux/device.h>
+#include <linux/pci.h>
+#include <linux/blkdev.h>
+#include <linux/device.h>
+
+#include <linux/init.h>
+#include <linux/mm.h>
+#include <linux/fcntl.h>
+#include <linux/slab.h>
+#include <linux/kmod.h>
+#include <linux/major.h>
+#include <linux/highmem.h>
+#include <linux/blkdev.h>
+#include <linux/module.h>
+#include <linux/blkpg.h>
+#include <linux/buffer_head.h>
+#include <linux/mpage.h>
+#include <linux/mount.h>
+#include <linux/uio.h>
+#include <linux/namei.h>
+#include <asm/uaccess.h>
+
+#include <linux/pagemap.h>
+#include <linux/pagevec.h>
+
+#include <linux/swiotlb.h>
+#define DUMP_SWIOTLB_FUN  "0.1"
+
+MODULE_AUTHOR("Konrad Rzeszutek Wilk <konrad@darnok.org>");
+MODULE_DESCRIPTION("dump swiotlb");
+MODULE_LICENSE("GPL");
+MODULE_VERSION(DUMP_SWIOTLB_FUN);
+
+extern int xen_swiotlb_start_thread(void);
+extern void xen_swiotlb_stop_thread(void);
+static int __init dump_swiotlb_init(void)
+{
+	printk(KERN_INFO "Starting SWIOTLB debug thread.\n");
+	swiotlb_start_thread();
+	xen_swiotlb_start_thread();
+	return 0;
+}
+
+static void __exit dump_swiotlb_exit(void)
+{
+	swiotlb_stop_thread();
+	xen_swiotlb_stop_thread();
+}
+
+module_init(dump_swiotlb_init);
+module_exit(dump_swiotlb_exit);
diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index 6e8c15a..c833501 100644
--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -143,6 +143,63 @@ xen_swiotlb_fixup(void *buf, size_t size, unsigned long nslabs)
 	return 0;
 }
 
+#include <linux/percpu.h>
+struct xen_swiotlb_debug {
+	unsigned long alloc;
+	unsigned long dealloc;
+	char dev_name[64];
+};
+static DEFINE_PER_CPU(struct xen_swiotlb_debug, xen_tlb_debug);
+#include <linux/kthread.h>
+static int xen_swiotlb_debug_thread(void *arg)
+{
+	int cpu;
+	do {
+		set_current_state(TASK_INTERRUPTIBLE);
+		schedule_timeout_interruptible(HZ*10);
+
+		for_each_online_cpu(cpu) {
+			struct xen_swiotlb_debug *d;
+
+			d = &per_cpu(xen_tlb_debug, cpu);
+			/* Can't really happend.*/
+			if (!d)
+				continue;
+
+			if (d->dev_name[0] == 0)
+				continue;
+
+			printk(KERN_INFO "%u %s alloc coherent: %ld, free: %ld\n",
+				cpu,
+				d->dev_name ? d->dev_name : "?",
+				d->alloc, d->dealloc);
+
+			memset(d, 0, sizeof(struct xen_swiotlb_debug));
+		}
+
+	} while (!kthread_should_stop());
+	return 0;
+}
+static struct task_struct *xen_debug_thread = NULL;
+
+int xen_swiotlb_start_thread(void) {
+
+	if (xen_debug_thread)
+		return -EINVAL;
+	printk(KERN_INFO "%s: Go!\n",__func__);
+	xen_debug_thread =  kthread_run(xen_swiotlb_debug_thread, NULL, "xen_swiotlb_debug");
+	return 0;
+}
+EXPORT_SYMBOL_GPL(xen_swiotlb_start_thread);
+void xen_swiotlb_stop_thread(void) {
+
+	printk(KERN_INFO "%s: Stop!\n",__func__);
+	if (xen_debug_thread)
+		kthread_stop(xen_debug_thread);
+	xen_debug_thread = NULL;
+}
+EXPORT_SYMBOL_GPL(xen_swiotlb_stop_thread);
+
 void __init xen_swiotlb_init(int verbose)
 {
 	unsigned long bytes;
@@ -194,7 +251,14 @@ xen_swiotlb_alloc_coherent(struct device *hwdev, size_t size,
 	int order = get_order(size);
 	u64 dma_mask = DMA_BIT_MASK(32);
 	unsigned long vstart;
-
+	struct xen_swiotlb_debug *d;
+
+	preempt_disable();
+	d = &__get_cpu_var(xen_tlb_debug);
+	preempt_enable();
+	d->alloc++;
+	snprintf(d->dev_name, sizeof(d->dev_name), "%s %s",
+                dev_driver_string(hwdev), dev_name(hwdev));
 	/*
 	* Ignore region specifiers - the kernel's ideas of
 	* pseudo-phys memory layout has nothing to do with the
@@ -230,6 +294,14 @@ xen_swiotlb_free_coherent(struct device *hwdev, size_t size, void *vaddr,
 			  dma_addr_t dev_addr)
 {
 	int order = get_order(size);
+	struct xen_swiotlb_debug *d;
+
+	preempt_disable();
+	d = &__get_cpu_var(xen_tlb_debug);
+	preempt_enable();
+	d->dealloc++;
+	snprintf(d->dev_name, sizeof(d->dev_name), "%s %s",
+                dev_driver_string(hwdev), dev_name(hwdev));
 
 	if (dma_release_from_coherent(hwdev, order, vaddr))
 		return;
diff --git a/include/linux/swiotlb.h b/include/linux/swiotlb.h
index 445702c..0d2e049 100644
--- a/include/linux/swiotlb.h
+++ b/include/linux/swiotlb.h
@@ -26,6 +26,8 @@ extern void swiotlb_init(int verbose);
 extern void swiotlb_init_with_tbl(char *tlb, unsigned long nslabs, int verbose);
 extern unsigned long swioltb_nr_tbl(void);
 
+extern int swiotlb_start_thread(void);
+extern void swiotlb_stop_thread(void);
 /*
  * Enumeration for sync targets
  */
diff --git a/lib/swiotlb.c b/lib/swiotlb.c
index 99093b3..5446076 100644
--- a/lib/swiotlb.c
+++ b/lib/swiotlb.c
@@ -92,6 +92,74 @@ static DEFINE_SPINLOCK(io_tlb_lock);
 
 static int late_alloc;
 
+#include <linux/percpu.h>
+struct swiotlb_debug {
+	unsigned long bounce_to;
+	unsigned long bounce_from;
+	unsigned long bounce_slow;
+	unsigned long map;
+	unsigned long unmap;
+	unsigned long sync;
+	char dev_name[64];
+};
+static DEFINE_PER_CPU(struct swiotlb_debug, tlb_debug);
+#include <linux/kthread.h>
+static int swiotlb_debug_thread(void *arg)
+{
+	int cpu;
+	int size = io_tlb_nslabs;
+	do {
+		int i;
+		unsigned long filled = 0;
+		set_current_state(TASK_INTERRUPTIBLE);
+		schedule_timeout_interruptible(HZ*5);
+
+		for_each_online_cpu(cpu) {
+			struct swiotlb_debug *d = &per_cpu(tlb_debug, cpu);
+			/* Can't really happend.*/
+			if (!d)
+				continue;
+			if (d->dev_name[0] == 0)
+				continue;
+
+			printk(KERN_INFO "%d [%s] bounce: from:%ld(slow:%ld)to:%ld map:%ld unmap:%ld sync:%ld\n",
+				cpu,
+				d->dev_name ? d->dev_name : "?",
+				d->bounce_from,
+				d->bounce_slow,
+				d->bounce_to,
+				d->map, d->unmap, d->sync);
+			memset(d, 0, sizeof(struct swiotlb_debug));
+		}
+		/* Very crude calculation. */
+		for (i = 0; i < size; i++) {
+			if (io_tlb_list[i] == 0)
+				filled++;
+		}
+		printk(KERN_INFO "SWIOTLB is %ld%% full\n", (filled * 100) / size);
+
+	} while (!kthread_should_stop());
+	return 0;
+}
+static struct task_struct *debug_thread = NULL;
+
+int swiotlb_start_thread(void) {
+
+	if (debug_thread)
+		return -EINVAL;
+	printk(KERN_INFO "%s: Go!\n",__func__);
+	debug_thread =  kthread_run(swiotlb_debug_thread, NULL, "swiotlb_debug");
+}
+EXPORT_SYMBOL_GPL(swiotlb_start_thread);
+void swiotlb_stop_thread(void) {
+
+	printk(KERN_INFO "%s: Stop!\n",__func__);
+	if (debug_thread)
+		kthread_stop(debug_thread);
+	debug_thread = NULL;
+}
+EXPORT_SYMBOL_GPL(swiotlb_stop_thread);
+
 static int __init
 setup_io_tlb_npages(char *str)
 {
@@ -166,6 +234,7 @@ void __init swiotlb_init_with_tbl(char *tlb, unsigned long nslabs, int verbose)
 		panic("Cannot allocate SWIOTLB overflow buffer!\n");
 	if (verbose)
 		swiotlb_print_info();
+
 }
 
 /*
@@ -336,6 +405,7 @@ void swiotlb_bounce(phys_addr_t phys, char *dma_addr, size_t size,
 		    enum dma_data_direction dir)
 {
 	unsigned long pfn = PFN_DOWN(phys);
+	struct swiotlb_debug *d = &__get_cpu_var(tlb_debug);
 
 	if (PageHighMem(pfn_to_page(pfn))) {
 		/* The buffer does not have a mapping.  Map it in and copy */
@@ -362,11 +432,16 @@ void swiotlb_bounce(phys_addr_t phys, char *dma_addr, size_t size,
 			dma_addr += sz;
 			offset = 0;
 		}
+		d->bounce_slow++;
 	} else {
-		if (dir == DMA_TO_DEVICE)
+		if (dir == DMA_TO_DEVICE) {
 			memcpy(dma_addr, phys_to_virt(phys), size);
-		else
+			d->bounce_to++;
+		}
+		else {
 			memcpy(phys_to_virt(phys), dma_addr, size);
+			d->bounce_from++;
+		}
 	}
 }
 EXPORT_SYMBOL_GPL(swiotlb_bounce);
@@ -471,7 +546,15 @@ found:
 		io_tlb_orig_addr[index+i] = phys + (i << IO_TLB_SHIFT);
 	if (dir == DMA_TO_DEVICE || dir == DMA_BIDIRECTIONAL)
 		swiotlb_bounce(phys, dma_addr, size, DMA_TO_DEVICE);
-
+	{
+		struct swiotlb_debug *d;
+		preempt_disable();
+		d = &__get_cpu_var(tlb_debug);
+		preempt_enable();
+		d->map++;
+		snprintf(d->dev_name, sizeof(d->dev_name), "%s %s",
+                	dev_driver_string(hwdev), dev_name(hwdev));
+	}
 	return dma_addr;
 }
 EXPORT_SYMBOL_GPL(swiotlb_tbl_map_single);
@@ -531,6 +614,15 @@ swiotlb_tbl_unmap_single(struct device *hwdev, char *dma_addr, size_t size,
 			io_tlb_list[i] = ++count;
 	}
 	spin_unlock_irqrestore(&io_tlb_lock, flags);
+	{
+		struct swiotlb_debug *d;
+		preempt_disable();
+		d = &__get_cpu_var(tlb_debug);
+		preempt_enable();
+		d->unmap++;
+		snprintf(d->dev_name, sizeof(d->dev_name), "%s %s",
+                	dev_driver_string(hwdev), dev_name(hwdev));
+	}
 }
 EXPORT_SYMBOL_GPL(swiotlb_tbl_unmap_single);
 
@@ -541,7 +633,13 @@ swiotlb_tbl_sync_single(struct device *hwdev, char *dma_addr, size_t size,
 {
 	int index = (dma_addr - io_tlb_start) >> IO_TLB_SHIFT;
 	phys_addr_t phys = io_tlb_orig_addr[index];
-
+	struct swiotlb_debug *d;
+	preempt_disable();
+	d = &__get_cpu_var(tlb_debug);
+	preempt_enable();
+	d->sync++;
+	snprintf(d->dev_name, sizeof(d->dev_name), "%s %s",
+               	dev_driver_string(hwdev), dev_name(hwdev));
 	phys += ((unsigned long)dma_addr & ((1 << IO_TLB_SHIFT) - 1));
 
 	switch (target) {

--C7zPtVaVf+AK4Oqc
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--C7zPtVaVf+AK4Oqc--


From xen-devel-bounces@lists.xensource.com Mon Dec 05 22:29:19 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 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.xensource.com>)
	id 1RXh0I-0003cp-EX; Mon, 05 Dec 2011 22:27:18 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <shandivo@gmail.com>) id 1RXh0H-0003ck-Fi
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 22:27:17 +0000
X-Env-Sender: shandivo@gmail.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1323123991!6254546!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,spamassassin: 
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1117 invoked from network); 5 Dec 2011 22:26:32 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-6.tower-216.messagelabs.com with AES256-SHA encrypted SMTP;
	5 Dec 2011 22:26:32 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <shandivo@gmail.com>) id 1RXgzW-0005cg-Eg
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 14:26:30 -0800
Date: Mon, 5 Dec 2011 14:26:30 -0800 (PST)
From: n4rC0t1C <shandivo@gmail.com>
To: xen-devel@lists.xensource.com
Message-ID: <1323123990448-5050354.post@n5.nabble.com>
In-Reply-To: <1319710499.206.YahooMailNeo@web29804.mail.ird.yahoo.com>
References: <20110922182705.GE12984@reaktio.net>
	<1316728444821-4831624.post@n5.nabble.com>
	<1316777654598-4833174.post@n5.nabble.com>
	<1316786412428-4833637.post@n5.nabble.com>
	<20110923172115.GI12984@reaktio.net>
	<1318672856439-4904945.post@n5.nabble.com>
	<1319630071722-4939528.post@n5.nabble.com>
	<1319636130.20499.YahooMailNeo@web29808.mail.ird.yahoo.com>
	<1319695116310-4942047.post@n5.nabble.com>
	<1319710499.206.YahooMailNeo@web29804.mail.ird.yahoo.com>
MIME-Version: 1.0
Subject: Re: [Xen-devel] Re : Re : Re : Re : Re : Re : Re: Patches for
 VGA-Passthrough XEN 4.2 unstable
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

I've been able to successfully passthrough my nvidia vga card to a windowsxp
32 bit domU, using the patches provided by David in this thread. 
Performances are AMAZING! I've played entire single player campaing of
Battlefield 3 at 1680x1050@ULTRA settings in domU, with NO visible lags or
artifacts. DomU is really rock solid, not a single crash. Crysis2, Fifa12,
NBA2K12 also played really well at maximum quality settings and resolutions.
Adobe Suite, Flash 11 and CUDA also works as on bare metal systems (eg using
gpu to accelerate).
I've been able to passthrough an usb controller and the integreted audio
card too. 


I can swich between dom0 e domU by changing the input source of the monitor,
and using synergy to share keyboard and mouse over ssh.
At boot i bind the nvidia card to pciback in grub conf file.
Later I use pci-stub to passthrough audio and usb.
When I shutdown the domU, i can bind the audio card back to the dom0 in this
way:

echo "8086 1c20" > remove_id
echo "0000:00:1b.0" > /sys/bus/pci/drivers/pci-stub/unbind
alsa force-reload



Follows a bit of infos about my system config and hardware:

CPU: Intel i5-2500
MB: Asrock z68 EXTREME4 GEN3 (bios 1.10)
PRIMARY VGA: GIGABYTE GTX460 (GV-N460OC-1GI, rev. 1.0). (@dvi on monitor)
SECONDARY VGA: integrated intel hd3000, running gnome shell 3 in dom0
(xorg-edgers ppa) (@DP on monitor).


Ubuntu 11.10-64bit with kernel 3.1.4 from ubuntu developers ppa
Linux ibeast 3.1.4-030104-generic #201111281851 SMP Mon Nov 28 23:52:23 UTC
2011 x86_64 x86_64 x86_64 GNU/Linux


xl info:

host                   : ibeast
release                : 3.1.4-030104-generic
version                : #201111281851 SMP Mon Nov 28 23:52:23 UTC 2011
machine                : x86_64
nr_cpus                : 4
nr_nodes               : 1
cores_per_socket       : 4
threads_per_core       : 1
cpu_mhz                : 3300
hw_caps                :
bfebfbff:28000800:00000000:00003f40:17bae3ff:00000000:00000001:00000000
virt_caps              : hvm hvm_directio
total_memory           : 8100
free_memory            : 117
free_cpus              : 0
xen_major              : 4
xen_minor              : 2
xen_extra              : -unstable
xen_caps               : xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32
hvm-3.0-x86_32p hvm-3.0-x86_64 
xen_scheduler          : credit
xen_pagesize           : 4096
platform_params        : virt_start=0xffff800000000000
xen_changeset          : Fri Dec 02 09:05:26 2011 +0100 24341:60d4e257d04b
xen_commandline        : placeholder
cc_compiler            : gcc version 4.6.1 (Ubuntu/Linaro 4.6.1-9ubuntu3) 
cc_compile_by          : ivo
cc_compile_domain      : 
cc_compile_date        : Fri Dec  2 13:14:41 CET 2011
xend_config_format     : 4

No remarkable changes made to xen default config files.


I just want to say thanks to every single xen developer out there, and David
for posting patched for nvidia cards. You just made my "life's dream" true.
Best Regards, 
Ivo

--
View this message in context: http://xen.1045712.n5.nabble.com/Patches-for-VGA-Passthrough-XEN-4-2-unstable-tp4406265p5050354.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 22:29:19 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 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.xensource.com>)
	id 1RXh0I-0003cp-EX; Mon, 05 Dec 2011 22:27:18 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <shandivo@gmail.com>) id 1RXh0H-0003ck-Fi
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 22:27:17 +0000
X-Env-Sender: shandivo@gmail.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1323123991!6254546!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,spamassassin: 
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1117 invoked from network); 5 Dec 2011 22:26:32 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-6.tower-216.messagelabs.com with AES256-SHA encrypted SMTP;
	5 Dec 2011 22:26:32 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <shandivo@gmail.com>) id 1RXgzW-0005cg-Eg
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 14:26:30 -0800
Date: Mon, 5 Dec 2011 14:26:30 -0800 (PST)
From: n4rC0t1C <shandivo@gmail.com>
To: xen-devel@lists.xensource.com
Message-ID: <1323123990448-5050354.post@n5.nabble.com>
In-Reply-To: <1319710499.206.YahooMailNeo@web29804.mail.ird.yahoo.com>
References: <20110922182705.GE12984@reaktio.net>
	<1316728444821-4831624.post@n5.nabble.com>
	<1316777654598-4833174.post@n5.nabble.com>
	<1316786412428-4833637.post@n5.nabble.com>
	<20110923172115.GI12984@reaktio.net>
	<1318672856439-4904945.post@n5.nabble.com>
	<1319630071722-4939528.post@n5.nabble.com>
	<1319636130.20499.YahooMailNeo@web29808.mail.ird.yahoo.com>
	<1319695116310-4942047.post@n5.nabble.com>
	<1319710499.206.YahooMailNeo@web29804.mail.ird.yahoo.com>
MIME-Version: 1.0
Subject: Re: [Xen-devel] Re : Re : Re : Re : Re : Re : Re: Patches for
 VGA-Passthrough XEN 4.2 unstable
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

I've been able to successfully passthrough my nvidia vga card to a windowsxp
32 bit domU, using the patches provided by David in this thread. 
Performances are AMAZING! I've played entire single player campaing of
Battlefield 3 at 1680x1050@ULTRA settings in domU, with NO visible lags or
artifacts. DomU is really rock solid, not a single crash. Crysis2, Fifa12,
NBA2K12 also played really well at maximum quality settings and resolutions.
Adobe Suite, Flash 11 and CUDA also works as on bare metal systems (eg using
gpu to accelerate).
I've been able to passthrough an usb controller and the integreted audio
card too. 


I can swich between dom0 e domU by changing the input source of the monitor,
and using synergy to share keyboard and mouse over ssh.
At boot i bind the nvidia card to pciback in grub conf file.
Later I use pci-stub to passthrough audio and usb.
When I shutdown the domU, i can bind the audio card back to the dom0 in this
way:

echo "8086 1c20" > remove_id
echo "0000:00:1b.0" > /sys/bus/pci/drivers/pci-stub/unbind
alsa force-reload



Follows a bit of infos about my system config and hardware:

CPU: Intel i5-2500
MB: Asrock z68 EXTREME4 GEN3 (bios 1.10)
PRIMARY VGA: GIGABYTE GTX460 (GV-N460OC-1GI, rev. 1.0). (@dvi on monitor)
SECONDARY VGA: integrated intel hd3000, running gnome shell 3 in dom0
(xorg-edgers ppa) (@DP on monitor).


Ubuntu 11.10-64bit with kernel 3.1.4 from ubuntu developers ppa
Linux ibeast 3.1.4-030104-generic #201111281851 SMP Mon Nov 28 23:52:23 UTC
2011 x86_64 x86_64 x86_64 GNU/Linux


xl info:

host                   : ibeast
release                : 3.1.4-030104-generic
version                : #201111281851 SMP Mon Nov 28 23:52:23 UTC 2011
machine                : x86_64
nr_cpus                : 4
nr_nodes               : 1
cores_per_socket       : 4
threads_per_core       : 1
cpu_mhz                : 3300
hw_caps                :
bfebfbff:28000800:00000000:00003f40:17bae3ff:00000000:00000001:00000000
virt_caps              : hvm hvm_directio
total_memory           : 8100
free_memory            : 117
free_cpus              : 0
xen_major              : 4
xen_minor              : 2
xen_extra              : -unstable
xen_caps               : xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32
hvm-3.0-x86_32p hvm-3.0-x86_64 
xen_scheduler          : credit
xen_pagesize           : 4096
platform_params        : virt_start=0xffff800000000000
xen_changeset          : Fri Dec 02 09:05:26 2011 +0100 24341:60d4e257d04b
xen_commandline        : placeholder
cc_compiler            : gcc version 4.6.1 (Ubuntu/Linaro 4.6.1-9ubuntu3) 
cc_compile_by          : ivo
cc_compile_domain      : 
cc_compile_date        : Fri Dec  2 13:14:41 CET 2011
xend_config_format     : 4

No remarkable changes made to xen default config files.


I just want to say thanks to every single xen developer out there, and David
for posting patched for nvidia cards. You just made my "life's dream" true.
Best Regards, 
Ivo

--
View this message in context: http://xen.1045712.n5.nabble.com/Patches-for-VGA-Passthrough-XEN-4-2-unstable-tp4406265p5050354.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 22:33:36 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 22:33:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXh4d-0003nF-6k; Mon, 05 Dec 2011 22:31:47 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RXh4b-0003mw-7F
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 22:31:45 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1323124259!4182474!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjAyNg==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28040 invoked from network); 5 Dec 2011 22:31:00 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Dec 2011 22:31:00 -0000
X-IronPort-AV: E=Sophos;i="4.71,301,1320624000"; 
   d="scan'208";a="9300291"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Dec 2011 22:30:59 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 5 Dec 2011 22:30:59 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RXh3r-0005CM-4T;
	Mon, 05 Dec 2011 22:30:59 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RXh3r-00007V-2d;
	Mon, 05 Dec 2011 22:30:59 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10353-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 5 Dec 2011 22:30:59 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10353: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10353 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10353/

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-amd64-xl-sedf     14 guest-localmigrate/x10    fail REGR. vs. 10201
 test-amd64-i386-win-vcpus1    8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-i386-win           8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-amd64-win          8 guest-saverestore         fail REGR. vs. 10201
 test-i386-i386-win            8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-amd64-xl-win       8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-i386-xl-win-vcpus1  8 guest-saverestore        fail REGR. vs. 10201
 test-i386-i386-xl-win         8 guest-saverestore         fail REGR. vs. 10201

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-win7-amd64  7 windows-install              fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install          fail never pass
 test-amd64-i386-xl-win7-amd64  7 windows-install              fail  never pass
 test-i386-i386-xl-winxpsp3    7 windows-install              fail   never pass
 test-amd64-i386-xend-winxpsp3  7 windows-install              fail  never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   never pass

version targeted for testing:
 xen                  9961a6d5356a
baseline version:
 xen                  62ff6a318c5d

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Andrew Cooper <andrew.cooper3@citrix.com>
  Anthony PERARD <anthony.perard@citrix.com>
  Brendan Cully <brendan@cs.ubc.ca>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Haitao Shan <haitao.shan@intel.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@novell.com>
  Jan Beulich <jbeulich@suse.com>
  Jonathan Davies <jonathan.davies@citrix.com>
  juergen.gross@ts.fujitsu.com
  Keir Fraser <keir@xen.org>
  Liu, Jinsong <jinsong.liu@intel.com>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
  Philipp Hahn <hahn@univention.de>
  Shriram Rajagopalan <rshriram@cs.ubc.ca>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang2 <wei.wang2@amd.com>
  Xudong Hao <xudong.hao@intel.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 1324 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 22:33:36 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 22:33:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXh4d-0003nF-6k; Mon, 05 Dec 2011 22:31:47 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RXh4b-0003mw-7F
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 22:31:45 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1323124259!4182474!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjAyNg==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28040 invoked from network); 5 Dec 2011 22:31:00 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Dec 2011 22:31:00 -0000
X-IronPort-AV: E=Sophos;i="4.71,301,1320624000"; 
   d="scan'208";a="9300291"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Dec 2011 22:30:59 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 5 Dec 2011 22:30:59 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RXh3r-0005CM-4T;
	Mon, 05 Dec 2011 22:30:59 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RXh3r-00007V-2d;
	Mon, 05 Dec 2011 22:30:59 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10353-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 5 Dec 2011 22:30:59 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10353: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10353 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10353/

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-amd64-xl-sedf     14 guest-localmigrate/x10    fail REGR. vs. 10201
 test-amd64-i386-win-vcpus1    8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-i386-win           8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-amd64-win          8 guest-saverestore         fail REGR. vs. 10201
 test-i386-i386-win            8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-amd64-xl-win       8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-i386-xl-win-vcpus1  8 guest-saverestore        fail REGR. vs. 10201
 test-i386-i386-xl-win         8 guest-saverestore         fail REGR. vs. 10201

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-win7-amd64  7 windows-install              fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install          fail never pass
 test-amd64-i386-xl-win7-amd64  7 windows-install              fail  never pass
 test-i386-i386-xl-winxpsp3    7 windows-install              fail   never pass
 test-amd64-i386-xend-winxpsp3  7 windows-install              fail  never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   never pass

version targeted for testing:
 xen                  9961a6d5356a
baseline version:
 xen                  62ff6a318c5d

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Andrew Cooper <andrew.cooper3@citrix.com>
  Anthony PERARD <anthony.perard@citrix.com>
  Brendan Cully <brendan@cs.ubc.ca>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Haitao Shan <haitao.shan@intel.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@novell.com>
  Jan Beulich <jbeulich@suse.com>
  Jonathan Davies <jonathan.davies@citrix.com>
  juergen.gross@ts.fujitsu.com
  Keir Fraser <keir@xen.org>
  Liu, Jinsong <jinsong.liu@intel.com>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
  Philipp Hahn <hahn@univention.de>
  Shriram Rajagopalan <rshriram@cs.ubc.ca>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang2 <wei.wang2@amd.com>
  Xudong Hao <xudong.hao@intel.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 1324 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 23:02:00 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 23: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.xensource.com>)
	id 1RXhXN-0004At-44; Mon, 05 Dec 2011 23:01:29 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1RXhXK-0004Am-VB
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 23:01:27 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-12.tower-174.messagelabs.com!1323126034!4319077!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12981 invoked from network); 5 Dec 2011 23:00:36 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-12.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 5 Dec 2011 23:00:36 -0000
Received: from andromeda.dapyr.net (darnok@localhost [127.0.0.1])
	by andromeda.dapyr.net (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id
	pB5N0Ku8015829
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Mon, 5 Dec 2011 18:00:20 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pB5N0K88015827;
	Mon, 5 Dec 2011 18:00:20 -0500
Date: Mon, 5 Dec 2011 19:00:20 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Anthony PERARD <anthony.perard@citrix.com>
Message-ID: <20111205230019.GA9560@andromeda.dapyr.net>
References: <1322156679-9441-1-git-send-email-anthony.perard@citrix.com>
	<1322156679-9441-9-git-send-email-anthony.perard@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1322156679-9441-9-git-send-email-anthony.perard@citrix.com>
User-Agent: Mutt/1.5.9i
Cc: Guy Zana <guy@neocleus.com>, Xen Devel <xen-devel@lists.xensource.com>,
	Allen Kay <allen.m.kay@intel.com>, QEMU-devel <qemu-devel@nongnu.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH V5 08/10] Introduce Xen PCI Passthrough,
	PCI config space helpers (2/3)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Nov 24, 2011 at 05:44:37PM +0000, Anthony PERARD wrote:
> From: Allen Kay <allen.m.kay@intel.com>
> 
> A more complete history can be found here:
> git://xenbits.xensource.com/qemu-xen-unstable.git
> 
> Signed-off-by: Allen Kay <allen.m.kay@intel.com>
> Signed-off-by: Guy Zana <guy@neocleus.com>
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> ---
>  hw/xen_pci_passthrough.c             |   15 +
>  hw/xen_pci_passthrough_config_init.c | 2131 ++++++++++++++++++++++++++++++++++
>  2 files changed, 2146 insertions(+), 0 deletions(-)
> 
> diff --git a/hw/xen_pci_passthrough.c b/hw/xen_pci_passthrough.c
> index 998470b..c816ed5 100644
> --- a/hw/xen_pci_passthrough.c
> +++ b/hw/xen_pci_passthrough.c
> @@ -360,6 +360,11 @@ out:
>              PT_ERR(d, "pci_write_block failed. return value: %d.\n", rc);
>          }
>      }
> +
> +    if (s->pm_state != NULL && s->pm_state->flags & PT_FLAG_TRANSITING) {
> +        qemu_mod_timer(s->pm_state->pm_timer,
> +                       qemu_get_clock_ms(rt_clock) + s->pm_state->pm_delay);
> +    }

Is this in the right place? There is code before in this function that
does:

if (s->pm_state != NULL && s->pm_state->flags & PT_FLAG_TRANSITING)
	return;

so we would never get here, I think?

>  }
>  
>  /* ioport/iomem space*/
> @@ -706,6 +711,13 @@ static int pt_initfn(PCIDevice *pcidev)
>      /* Handle real device's MMIO/PIO BARs */
>      pt_register_regions(s);
>  
> +    /* reinitialize each config register to be emulated */
> +    if (pt_config_init(s)) {
> +        PT_ERR(pcidev, "PCI Config space initialisation failed.\n");
> +        host_pci_device_put(s->real_device);
> +        return -1;
> +    }
> +
>      /* Bind interrupt */
>      if (!s->dev.config[PCI_INTERRUPT_PIN]) {
>          PT_LOG(pcidev, "no pin interrupt\n");
> @@ -798,6 +810,9 @@ static int pt_unregister_device(PCIDevice *pcidev)
>          }
>      }
>  
> +    /* delete all emulated config registers */
> +    pt_config_delete(s);
> +
>      /* unregister real device's MMIO/PIO BARs */
>      pt_unregister_regions(s);
>  
> diff --git a/hw/xen_pci_passthrough_config_init.c b/hw/xen_pci_passthrough_config_init.c
> index 1e9de64..ae64544 100644
> --- a/hw/xen_pci_passthrough_config_init.c
> +++ b/hw/xen_pci_passthrough_config_init.c
> @@ -1,11 +1,2142 @@
> +/*
> + * Copyright (c) 2007, Neocleus Corporation.
> + * Copyright (c) 2007, Intel Corporation.
> + *
> + * This work is licensed under the terms of the GNU GPL, version 2.  See
> + * the COPYING file in the top-level directory.
> + *
> + * Alex Novik <alex@neocleus.com>
> + * Allen Kay <allen.m.kay@intel.com>
> + * Guy Zana <guy@neocleus.com>
> + *
> + * This file implements direct PCI assignment to a HVM guest
> + */
> +
> +#include "qemu-timer.h"
> +#include "xen_backend.h"
>  #include "xen_pci_passthrough.h"
>  
> +#define PT_MERGE_VALUE(value, data, val_mask) \
> +    (((value) & (val_mask)) | ((data) & ~(val_mask)))
> +
> +#define PT_INVALID_REG          0xFFFFFFFF      /* invalid register value */
> +
> +/* prototype */
> +
> +static int pt_ptr_reg_init(XenPCIPassthroughState *s, XenPTRegInfo *reg,
> +                           uint32_t real_offset, uint32_t *data);
> +static int pt_init_pci_config(XenPCIPassthroughState *s);
> +
> +
> +/* helper */
> +
> +/* A return value of 1 means the capability should NOT be exposed to guest. */
> +static int pt_hide_dev_cap(const HostPCIDevice *d, uint8_t grp_id)
> +{
> +    switch (grp_id) {
> +    case PCI_CAP_ID_EXP:
> +        /* The PCI Express Capability Structure of the VF of Intel 82599 10GbE
> +         * Controller looks trivial, e.g., the PCI Express Capabilities
> +         * Register is 0. We should not try to expose it to guest.
> +         *
> +         * The datasheet is available at
> +         * http://download.intel.com/design/network/datashts/82599_datasheet.pdf
> +         *
> +         * See 'Table 9.7. VF PCIe Configuration Space' of the datasheet, the
> +         * PCI Express Capability Structure of the VF of Intel 82599 10GbE
> +         * Controller looks trivial, e.g., the PCI Express Capabilities
> +         * Register is 0, so the Capability Version is 0 and
> +         * pt_pcie_size_init() would fail.
> +         */
> +        if (d->vendor_id == PCI_VENDOR_ID_INTEL &&
> +            d->device_id == PCI_DEVICE_ID_INTEL_82599_VF) {
> +            return 1;
> +        }
> +        break;
> +    }
> +    return 0;
> +}
> +
> +/*   find emulate register group entry */
>  XenPTRegGroup *pt_find_reg_grp(XenPCIPassthroughState *s, uint32_t address)
>  {
> +    XenPTRegGroup *entry = NULL;
> +
> +    /* find register group entry */
> +    QLIST_FOREACH(entry, &s->reg_grp_tbl, entries) {
> +        /* check address */
> +        if ((entry->base_offset <= address)
> +            && ((entry->base_offset + entry->size) > address)) {
> +            return entry;
> +        }
> +    }
> +
> +    /* group entry not found */
>      return NULL;
>  }
>  
> +/* find emulate register entry */
>  XenPTReg *pt_find_reg(XenPTRegGroup *reg_grp, uint32_t address)
>  {
> +    XenPTReg *reg_entry = NULL;
> +    XenPTRegInfo *reg = NULL;
> +    uint32_t real_offset = 0;
> +
> +    /* find register entry */
> +    QLIST_FOREACH(reg_entry, &reg_grp->reg_tbl_list, entries) {
> +        reg = reg_entry->reg;
> +        real_offset = reg_grp->base_offset + reg->offset;
> +        /* check address */
> +        if ((real_offset <= address)
> +            && ((real_offset + reg->size) > address)) {
> +            return reg_entry;
> +        }
> +    }
> +
>      return NULL;
>  }
> +
> +/* parse BAR */
> +static PTBarFlag pt_bar_reg_parse(XenPCIPassthroughState *s, XenPTRegInfo *reg)
> +{
> +    PCIDevice *d = &s->dev;
> +    XenPTRegion *region = NULL;
> +    PCIIORegion *r;
> +    int index = 0;
> +
> +    /* check 64bit BAR */
> +    index = pt_bar_offset_to_index(reg->offset);
> +    if ((0 < index) && (index < PCI_ROM_SLOT)) {
> +        int flags = s->real_device->io_regions[index - 1].flags;

Can you put a comment explaining why you need to shift it?
I presume its b/c the ROM slot is its own variable, but it would useful
to have that explicitly stated.

> +
> +        if ((flags & IORESOURCE_MEM) && (flags & IORESOURCE_MEM_64)) {

You could collapse these two I think?
(flags & (IORESOURCE_MEM | IORESOURCE_MEM_64))

> +            region = &s->bases[index - 1];
> +            if (region->bar_flag != PT_BAR_FLAG_UPPER) {
> +                return PT_BAR_FLAG_UPPER;
> +            }
> +        }
> +    }
> +
> +    /* check unused BAR */
> +    r = &d->io_regions[index];
> +    if (r->size == 0) {
> +        return PT_BAR_FLAG_UNUSED;
> +    }
> +
> +    /* for ExpROM BAR */
> +    if (index == PCI_ROM_SLOT) {
> +        return PT_BAR_FLAG_MEM;
> +    }
> +
> +    /* check BAR I/O indicator */
> +    if (s->real_device->io_regions[index].flags & IORESOURCE_IO) {
> +        return PT_BAR_FLAG_IO;
> +    } else {
> +        return PT_BAR_FLAG_MEM;
> +    }
> +}
> +
> +
> +/****************
> + * general register functions
> + */
> +
> +/* register initialization function */
> +
> +static int pt_common_reg_init(XenPCIPassthroughState *s,
> +                              XenPTRegInfo *reg, uint32_t real_offset,
> +                              uint32_t *data)
> +{
> +    *data = reg->init_val;
> +    return 0;
> +}
> +
> +/* Read register functions */
> +
> +static int pt_byte_reg_read(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
> +                            uint8_t *value, uint8_t valid_mask)
> +{
> +    XenPTRegInfo *reg = cfg_entry->reg;
> +    uint8_t valid_emu_mask = 0;
> +
> +    /* emulate byte register */
> +    valid_emu_mask = reg->emu_mask & valid_mask;
> +    *value = PT_MERGE_VALUE(*value, cfg_entry->data, ~valid_emu_mask);
> +
> +    return 0;
> +}
> +static int pt_word_reg_read(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
> +                            uint16_t *value, uint16_t valid_mask)
> +{
> +    XenPTRegInfo *reg = cfg_entry->reg;
> +    uint16_t valid_emu_mask = 0;
> +
> +    /* emulate word register */
> +    valid_emu_mask = reg->emu_mask & valid_mask;
> +    *value = PT_MERGE_VALUE(*value, cfg_entry->data, ~valid_emu_mask);
> +
> +    return 0;
> +}
> +static int pt_long_reg_read(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
> +                            uint32_t *value, uint32_t valid_mask)
> +{
> +    XenPTRegInfo *reg = cfg_entry->reg;
> +    uint32_t valid_emu_mask = 0;
> +
> +    /* emulate long register */
> +    valid_emu_mask = reg->emu_mask & valid_mask;
> +    *value = PT_MERGE_VALUE(*value, cfg_entry->data, ~valid_emu_mask);
> +
> +   return 0;
> +}
> +
> +/* Write register functions */
> +
> +static int pt_byte_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
> +                             uint8_t *value, uint8_t dev_value,
> +                             uint8_t valid_mask)
> +{
> +    XenPTRegInfo *reg = cfg_entry->reg;
> +    uint8_t writable_mask = 0;
> +    uint8_t throughable_mask = 0;
> +
> +    /* modify emulate register */
> +    writable_mask = reg->emu_mask & ~reg->ro_mask & valid_mask;
> +    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
> +
> +    /* create value for writing to I/O device register */
> +    throughable_mask = ~reg->emu_mask & valid_mask;
> +    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
> +
> +    return 0;
> +}
> +static int pt_word_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
> +                             uint16_t *value, uint16_t dev_value,
> +                             uint16_t valid_mask)
> +{
> +    XenPTRegInfo *reg = cfg_entry->reg;
> +    uint16_t writable_mask = 0;
> +    uint16_t throughable_mask = 0;
> +
> +    /* modify emulate register */
> +    writable_mask = reg->emu_mask & ~reg->ro_mask & valid_mask;
> +    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
> +
> +    /* create value for writing to I/O device register */
> +    throughable_mask = ~reg->emu_mask & valid_mask;
> +    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
> +
> +    return 0;
> +}
> +static int pt_long_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
> +                             uint32_t *value, uint32_t dev_value,
> +                             uint32_t valid_mask)
> +{
> +    XenPTRegInfo *reg = cfg_entry->reg;
> +    uint32_t writable_mask = 0;
> +    uint32_t throughable_mask = 0;
> +
> +    /* modify emulate register */
> +    writable_mask = reg->emu_mask & ~reg->ro_mask & valid_mask;
> +    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
> +
> +    /* create value for writing to I/O device register */
> +    throughable_mask = ~reg->emu_mask & valid_mask;
> +    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
> +
> +    return 0;
> +}
> +
> +/* common restore register fonctions */
> +static int pt_byte_reg_restore(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
> +                               uint32_t real_offset, uint8_t dev_value,
> +                               uint8_t *value)
> +{
> +    XenPTRegInfo *reg = cfg_entry->reg;
> +    PCIDevice *d = &s->dev;
> +
> +    /* use I/O device register's value as restore value */
> +    *value = pci_get_byte(d->config + real_offset);
> +
> +    /* create value for restoring to I/O device register */
> +    *value = PT_MERGE_VALUE(*value, dev_value, reg->emu_mask);
> +
> +    return 0;
> +}
> +static int pt_word_reg_restore(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
> +                               uint32_t real_offset, uint16_t dev_value,
> +                               uint16_t *value)
> +{
> +    XenPTRegInfo *reg = cfg_entry->reg;
> +    PCIDevice *d = &s->dev;
> +
> +    /* use I/O device register's value as restore value */
> +    *value = pci_get_word(d->config + real_offset);
> +
> +    /* create value for restoring to I/O device register */
> +    *value = PT_MERGE_VALUE(*value, dev_value, reg->emu_mask);
> +
> +    return 0;
> +}
> +
> +
> +/* XenPTRegInfo declaration
> + * - only for emulated register (either a part or whole bit).
> + * - for passthrough register that need special behavior (like interacting with
> + *   other component), set emu_mask to all 0 and specify r/w func properly.
> + * - do NOT use ALL F for init_val, otherwise the tbl will not be registered.
> + */
> +
> +/********************
> + * Header Type0
> + */
> +
> +static int pt_vendor_reg_init(XenPCIPassthroughState *s,
> +                              XenPTRegInfo *reg, uint32_t real_offset,
> +                              uint32_t *data)
> +{
> +    *data = s->real_device->vendor_id;
> +    return 0;
> +}
> +static int pt_device_reg_init(XenPCIPassthroughState *s,
> +                              XenPTRegInfo *reg, uint32_t real_offset,
> +                              uint32_t *data)
> +{
> +    *data = s->real_device->device_id;
> +    return 0;
> +}
> +static int pt_status_reg_init(XenPCIPassthroughState *s,
> +                              XenPTRegInfo *reg, uint32_t real_offset,
> +                              uint32_t *data)
> +{
> +    XenPTRegGroup *reg_grp_entry = NULL;
> +    XenPTReg *reg_entry = NULL;
> +    uint32_t reg_field = 0;
> +
> +    /* find Header register group */
> +    reg_grp_entry = pt_find_reg_grp(s, PCI_CAPABILITY_LIST);
> +    if (reg_grp_entry) {
> +        /* find Capabilities Pointer register */
> +        reg_entry = pt_find_reg(reg_grp_entry, PCI_CAPABILITY_LIST);
> +        if (reg_entry) {
> +            /* check Capabilities Pointer register */
> +            if (reg_entry->data) {
> +                reg_field |= PCI_STATUS_CAP_LIST;
> +            } else {
> +                reg_field &= ~PCI_STATUS_CAP_LIST;
> +            }
> +        } else {
> +            xen_shutdown_fatal_error("Internal error: Couldn't find XenPTReg*"
> +                                     " for Capabilities Pointer register."
> +                                     " (%s)\n", __func__);
> +            return -1;
> +        }
> +    } else {
> +        xen_shutdown_fatal_error("Internal error: Couldn't find XenPTRegGroup"
> +                                 " for Header. (%s)\n", __func__);
> +        return -1;
> +    }
> +
> +    *data = reg_field;
> +    return 0;
> +}
> +static int pt_header_type_reg_init(XenPCIPassthroughState *s,
> +                                   XenPTRegInfo *reg, uint32_t real_offset,
> +                                   uint32_t *data)
> +{
> +    /* read PCI_HEADER_TYPE */
> +    *data = reg->init_val | 0x80;
> +    return 0;
> +}
> +
> +/* initialize Interrupt Pin register */
> +static int pt_irqpin_reg_init(XenPCIPassthroughState *s,
> +                              XenPTRegInfo *reg, uint32_t real_offset,
> +                              uint32_t *data)
> +{
> +    *data = pci_read_intx(s);
> +    return 0;
> +}
> +
> +/* Command register */
> +static int pt_cmd_reg_read(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
> +                           uint16_t *value, uint16_t valid_mask)
> +{
> +    XenPTRegInfo *reg = cfg_entry->reg;
> +    uint16_t valid_emu_mask = 0;
> +    uint16_t emu_mask = reg->emu_mask;
> +
> +    if (s->is_virtfn) {
> +        emu_mask |= PCI_COMMAND_MEMORY;
> +    }
> +
> +    /* emulate word register */
> +    valid_emu_mask = emu_mask & valid_mask;
> +    *value = PT_MERGE_VALUE(*value, cfg_entry->data, ~valid_emu_mask);
> +
> +    return 0;
> +}
> +static int pt_cmd_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
> +                            uint16_t *value, uint16_t dev_value,

So the *value here is the return value right? How about
*response ?

> +                            uint16_t valid_mask)
> +{
> +    XenPTRegInfo *reg = cfg_entry->reg;
> +    uint16_t writable_mask = 0;
> +    uint16_t throughable_mask = 0;
> +    uint16_t wr_value = *value;
> +    uint16_t emu_mask = reg->emu_mask;
> +
> +    if (s->is_virtfn) {
> +        emu_mask |= PCI_COMMAND_MEMORY;
> +    }
> +
> +    /* modify emulate register */
> +    writable_mask = ~reg->ro_mask & valid_mask;
> +    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
> +
> +    /* create value for writing to I/O device register */
> +    throughable_mask = ~emu_mask & valid_mask;

What does 'throughable' mean? Is there a better term for it?
Say filtered? emulated? cleaned?

> +
> +    if (*value & PCI_COMMAND_INTX_DISABLE) {
> +        throughable_mask |= PCI_COMMAND_INTX_DISABLE;
> +    } else {
> +        if (s->machine_irq) {
> +            throughable_mask |= PCI_COMMAND_INTX_DISABLE;
> +        }
> +    }
> +
> +    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
> +
> +    /* mapping BAR */
> +    pt_bar_mapping(s, wr_value & PCI_COMMAND_IO,
> +                   wr_value & PCI_COMMAND_MEMORY);

Ah, here we kick of the real memory mapping with the hypervisor.
You might want to expand the comment to say that.

> +
> +    return 0;
> +}
> +static int pt_cmd_reg_restore(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
> +                              uint32_t real_offset, uint16_t dev_value,
> +                              uint16_t *value)
> +{
> +    XenPTRegInfo *reg = cfg_entry->reg;
> +    PCIDevice *d = &s->dev;
> +    uint16_t restorable_mask = 0;
> +
> +    /* use I/O device register's value as restore value */
> +    *value = pci_get_word(d->config + real_offset);
> +
> +    /* create value for restoring to I/O device register

s/to/the/

> +     * but do not include Fast Back-to-Back Enable bit.
> +     */
> +    restorable_mask = reg->emu_mask & ~PCI_COMMAND_FAST_BACK;
> +    *value = PT_MERGE_VALUE(*value, dev_value, restorable_mask);
> +
> +    if (!s->machine_irq) {
> +        *value |= PCI_COMMAND_INTX_DISABLE;
> +    } else {
> +        *value &= ~PCI_COMMAND_INTX_DISABLE;
> +    }
> +
> +    return 0;
> +}
> +
> +/* BAR */
> +#define PT_BAR_MEM_RO_MASK      0x0000000F      /* BAR ReadOnly mask(Memory) */
> +#define PT_BAR_MEM_EMU_MASK     0xFFFFFFF0      /* BAR emul mask(Memory) */
> +#define PT_BAR_IO_RO_MASK       0x00000003      /* BAR ReadOnly mask(I/O) */
> +#define PT_BAR_IO_EMU_MASK      0xFFFFFFFC      /* BAR emul mask(I/O) */
> +
> +static inline uint32_t base_address_with_flags(HostPCIIORegion *hr)
> +{
> +    if ((hr->flags & PCI_BASE_ADDRESS_SPACE) == PCI_BASE_ADDRESS_SPACE_IO) {
> +        return hr->base_addr | (hr->flags & ~PCI_BASE_ADDRESS_IO_MASK);
> +    } else {
> +        return hr->base_addr | (hr->flags & ~PCI_BASE_ADDRESS_MEM_MASK);
> +    }
> +}
> +
> +static int pt_bar_reg_init(XenPCIPassthroughState *s, XenPTRegInfo *reg,
> +                           uint32_t real_offset, uint32_t *data)
> +{
> +    uint32_t reg_field = 0;
> +    int index;
> +
> +    /* get BAR index */
> +    index = pt_bar_offset_to_index(reg->offset);
> +    if (index < 0) {

Should we check for index > PCI_ROM_BASE as well?
> +        PT_ERR(&s->dev, "Internal error: Invalid BAR index [%d].\n", index);
> +        return -1;
> +    }
> +
> +    /* set initial guest physical base address to -1 */
> +    s->bases[index].e_physbase = -1;
> +
> +    /* set BAR flag */
> +    s->bases[index].bar_flag = pt_bar_reg_parse(s, reg);
> +    if (s->bases[index].bar_flag == PT_BAR_FLAG_UNUSED) {
> +        reg_field = PT_INVALID_REG;
> +    }
> +
> +    *data = reg_field;
> +    return 0;
> +}
> +static int pt_bar_reg_read(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
> +                           uint32_t *value, uint32_t valid_mask)
> +{
> +    XenPTRegInfo *reg = cfg_entry->reg;
> +    uint32_t valid_emu_mask = 0;
> +    uint32_t bar_emu_mask = 0;
> +    int index;
> +
> +    /* get BAR index */
> +    index = pt_bar_offset_to_index(reg->offset);
> +    if (index < 0) {

Should we check for index > PCI_ROM_BASE?
> +        PT_ERR(&s->dev, "Internal error: Invalid BAR index [%d].\n", index);
> +        return -1;
> +    }
> +
> +    /* use fixed-up value from kernel sysfs */
> +    *value = base_address_with_flags(&s->real_device->io_regions[index]);
> +
> +    /* set emulate mask depend on BAR flag */
> +    switch (s->bases[index].bar_flag) {
> +    case PT_BAR_FLAG_MEM:
> +        bar_emu_mask = PT_BAR_MEM_EMU_MASK;
> +        break;
> +    case PT_BAR_FLAG_IO:
> +        bar_emu_mask = PT_BAR_IO_EMU_MASK;
> +        break;
> +    case PT_BAR_FLAG_UPPER:
> +        bar_emu_mask = PT_BAR_ALLF;
> +        break;
> +    default:
> +        break;
> +    }
> +
> +    /* emulate BAR */
> +    valid_emu_mask = bar_emu_mask & valid_mask;
> +    *value = PT_MERGE_VALUE(*value, cfg_entry->data, ~valid_emu_mask);
> +
> +   return 0;
> +}
> +static int pt_bar_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
> +                            uint32_t *value, uint32_t dev_value,
> +                            uint32_t valid_mask)
> +{
> +    XenPTRegInfo *reg = cfg_entry->reg;
> +    XenPTRegGroup *reg_grp_entry = NULL;
> +    XenPTReg *reg_entry = NULL;
> +    XenPTRegion *base = NULL;
> +    PCIDevice *d = &s->dev;
> +    PCIIORegion *r;
> +    uint32_t writable_mask = 0;
> +    uint32_t throughable_mask = 0;
> +    uint32_t bar_emu_mask = 0;
> +    uint32_t bar_ro_mask = 0;
> +    uint32_t new_addr, last_addr;
> +    uint32_t prev_offset;
> +    uint32_t r_size = 0;
> +    int index = 0;
> +
> +    /* get BAR index */
> +    index = pt_bar_offset_to_index(reg->offset);
> +    if (index < 0) {
> +        PT_ERR(d, "Internal error: Invalid BAR index [%d].\n", index);
> +        return -1;
> +    }
> +
> +    r = &d->io_regions[index];
> +    base = &s->bases[index];
> +    r_size = pt_get_emul_size(base->bar_flag, r->size);
> +
> +    /* set emulate mask and read-only mask depend on BAR flag */
                                             ^^values   ^^ the

> +    switch (s->bases[index].bar_flag) {
> +    case PT_BAR_FLAG_MEM:
> +        bar_emu_mask = PT_BAR_MEM_EMU_MASK;
> +        bar_ro_mask = PT_BAR_MEM_RO_MASK | (r_size - 1);
> +        break;
> +    case PT_BAR_FLAG_IO:
> +        bar_emu_mask = PT_BAR_IO_EMU_MASK;
> +        bar_ro_mask = PT_BAR_IO_RO_MASK | (r_size - 1);
> +        break;
> +    case PT_BAR_FLAG_UPPER:
> +        bar_emu_mask = PT_BAR_ALLF;
> +        bar_ro_mask = 0;    /* all upper 32bit are R/W */
> +        break;
> +    default:
> +        break;
> +    }
> +
> +    /* modify emulate register */
> +    writable_mask = bar_emu_mask & ~bar_ro_mask & valid_mask;
> +    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
> +
> +    /* check whether we need to update the virtual region address or not */
> +    switch (s->bases[index].bar_flag) {
> +    case PT_BAR_FLAG_MEM:
> +        /* nothing to do */
> +        break;
> +    case PT_BAR_FLAG_IO:
> +        new_addr = cfg_entry->data;
> +        last_addr = new_addr + r_size - 1;
> +        /* check invalid address */
> +        if (last_addr <= new_addr || !new_addr || last_addr >= UINT16_MAX) {
> +            /* check 64K range */
> +            if ((last_addr >= UINT16_MAX) &&
> +                (cfg_entry->data != (PT_BAR_ALLF & ~bar_ro_mask))) {

You seem to be using 'PT_BAR_ALLF & ~bar_ro_mask' this function and
never actually use the bar_ro_mask by itself. Perhaps you can
(before this switch statement) do:

  bar_ro_mask = PT_BAR_ALLF & ~bar_ro_mask;


> +                PT_WARN(d, "Guest attempt to set Base Address "
> +                       "over the 64KB. (offset: 0x%02x,"
> +                       " addr: 0x%08x, size: 0x%08x)\n",
> +                       reg->offset, new_addr, r_size);
> +            }
> +            /* just remove mapping */
> +            r->addr = PCI_BAR_UNMAPPED;
> +            goto exit;
> +        }
> +        break;
> +    case PT_BAR_FLAG_UPPER:
> +        if (cfg_entry->data) {
> +            if (cfg_entry->data != (PT_BAR_ALLF & ~bar_ro_mask)) {
> +                PT_WARN(d, "Guest attempt to set high MMIO Base Address. "
> +                        "Ignore mapping. "
> +                        "(offset: 0x%02x, high address: 0x%08x)\n",
> +                        reg->offset, cfg_entry->data);
> +            }
> +            /* clear lower address */
> +            d->io_regions[index-1].addr = -1;
> +        } else {
> +            /* find lower 32bit BAR */
> +            prev_offset = (reg->offset - 4);
> +            reg_grp_entry = pt_find_reg_grp(s, prev_offset);
> +            if (reg_grp_entry) {
> +                reg_entry = pt_find_reg(reg_grp_entry, prev_offset);
> +                if (reg_entry) {
> +                    /* restore lower address */
> +                    d->io_regions[index-1].addr = reg_entry->data;
> +                } else {
> +                    return -1;
> +                }
> +            } else {
> +                return -1;
> +            }
> +        }
> +
> +        /* never mapping the 'empty' upper region,
> +         * because we'll do it enough for the lower region.

umm, not sure what you mean here. Do you mean to say:
"Do not map the 'empty' upper region b/c we do not need to.
As we only need the lower region."?


> +         */
> +        r->addr = -1;
> +        goto exit;
> +    default:
> +        break;
> +    }
> +
> +    /* update the corresponding virtual region address */
> +    /*
> +     * When guest code tries to get block size of mmio, it will write all "1"s
> +     * into pci bar register. In this case, cfg_entry->data == writable_mask.
> +     * Especially for devices with large mmio, the value of writable_mask
> +     * is likely to be a guest physical address that has been mapped to ram
> +     * rather than mmio. Remapping this value to mmio should be prevented.
> +     */
> +
> +    if (cfg_entry->data != writable_mask) {
> +        r->addr = cfg_entry->data;
> +    }
> +
> +exit:
> +    /* create value for writing to I/O device register */
> +    throughable_mask = ~bar_emu_mask & valid_mask;
> +    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
> +
> +    /* After BAR reg update, we need to remap BAR */
> +    reg_grp_entry = pt_find_reg_grp(s, PCI_COMMAND);
> +    if (reg_grp_entry) {
> +        reg_entry = pt_find_reg(reg_grp_entry, PCI_COMMAND);
> +        if (reg_entry) {
> +            pt_bar_mapping_one(s, index, reg_entry->data & PCI_COMMAND_IO,
> +                               reg_entry->data & PCI_COMMAND_MEMORY);
> +        }
> +    }
> +
> +    return 0;
> +}
> +static int pt_bar_reg_restore(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
> +                              uint32_t real_offset, uint32_t dev_value,
> +                              uint32_t *value)
> +{
> +    XenPTRegInfo *reg = cfg_entry->reg;
> +    uint32_t bar_emu_mask = 0;
> +    int index = 0;
> +
> +    /* get BAR index */
> +    index = pt_bar_offset_to_index(reg->offset);
> +    if (index < 0) {
> +        PT_ERR(&s->dev, "Internal error: Invalid BAR index [%d].\n", index);
> +        return -1;
> +    }
> +
> +    /* use value from kernel sysfs */
> +    if (s->bases[index].bar_flag == PT_BAR_FLAG_UPPER) {
> +        *value = s->real_device->io_regions[index - 1].base_addr >> 32;
> +    } else {
> +        *value = base_address_with_flags(&s->real_device->io_regions[index]);
> +    }
> +
> +    /* set emulate mask depend on BAR flag */
> +    switch (s->bases[index].bar_flag) {
> +    case PT_BAR_FLAG_MEM:
> +        bar_emu_mask = PT_BAR_MEM_EMU_MASK;
> +        break;
> +    case PT_BAR_FLAG_IO:
> +        bar_emu_mask = PT_BAR_IO_EMU_MASK;
> +        break;
> +    case PT_BAR_FLAG_UPPER:
> +        bar_emu_mask = PT_BAR_ALLF;
> +        break;
> +    default:
> +        break;
> +    }
> +
> +    /* create value for restoring to I/O device register */
> +    *value = PT_MERGE_VALUE(*value, dev_value, bar_emu_mask);
> +
> +    return 0;
> +}
> +
> +/* write Exp ROM BAR */
> +static int pt_exp_rom_bar_reg_write(XenPCIPassthroughState *s,
> +                                    XenPTReg *cfg_entry, uint32_t *value,
> +                                    uint32_t dev_value, uint32_t valid_mask)
> +{
> +    XenPTRegInfo *reg = cfg_entry->reg;
> +    XenPTRegGroup *reg_grp_entry = NULL;
> +    XenPTReg *reg_entry = NULL;
> +    XenPTRegion *base = NULL;
> +    PCIDevice *d = (PCIDevice *)&s->dev;
> +    PCIIORegion *r;
> +    uint32_t writable_mask = 0;
> +    uint32_t throughable_mask = 0;
> +    pcibus_t r_size = 0;
> +    uint32_t bar_emu_mask = 0;
> +    uint32_t bar_ro_mask = 0;
> +
> +    r = &d->io_regions[PCI_ROM_SLOT];
> +    r_size = r->size;
> +    base = &s->bases[PCI_ROM_SLOT];
> +    /* align memory type resource size */
> +    pt_get_emul_size(base->bar_flag, r_size);
> +
> +    /* set emulate mask and read-only mask */
> +    bar_emu_mask = reg->emu_mask;
> +    bar_ro_mask = (reg->ro_mask | (r_size - 1)) & ~PCI_ROM_ADDRESS_ENABLE;
> +
> +    /* modify emulate register */
> +    writable_mask = ~bar_ro_mask & valid_mask;
> +    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
> +
> +    /* update the corresponding virtual region address */
> +    /*
> +     * When guest code tries to get block size of mmio, it will write all "1"s
> +     * into pci bar register. In this case, cfg_entry->data == writable_mask.
> +     * Especially for devices with large mmio, the value of writable_mask
> +     * is likely to be a guest physical address that has been mapped to ram
> +     * rather than mmio. Remapping this value to mmio should be prevented.
> +     */
> +
> +    if (cfg_entry->data != writable_mask) {
> +        r->addr = cfg_entry->data;
> +    }
> +
> +    /* create value for writing to I/O device register */
> +    throughable_mask = ~bar_emu_mask & valid_mask;
> +    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
> +
> +    /* After BAR reg update, we need to remap BAR*/
> +    reg_grp_entry = pt_find_reg_grp(s, PCI_COMMAND);
> +    if (reg_grp_entry) {
> +        reg_entry = pt_find_reg(reg_grp_entry, PCI_COMMAND);
> +        if (reg_entry) {
> +            pt_bar_mapping_one(s, PCI_ROM_SLOT,
> +                               reg_entry->data & PCI_COMMAND_IO,
> +                               reg_entry->data & PCI_COMMAND_MEMORY);
> +        }
> +    }
> +
> +    return 0;
> +}
> +/* restore ROM BAR */
> +static int pt_exp_rom_bar_reg_restore(XenPCIPassthroughState *s,
> +                                      XenPTReg *cfg_entry,
> +                                      uint32_t real_offset,
> +                                      uint32_t dev_value, uint32_t *value)
> +{
> +    XenPTRegInfo *reg = cfg_entry->reg;
> +    uint32_t v;
> +
> +    if (host_pci_get_long(s->real_device, PCI_ROM_ADDRESS, &v)) {
> +        return -1;
> +    }
> +    /* use value from kernel sysfs */
> +    *value = PT_MERGE_VALUE(v, dev_value, reg->emu_mask);
> +    return 0;
> +}
> +
> +/* Header Type0 reg static infomation table */
> +static XenPTRegInfo pt_emu_reg_header0_tbl[] = {
> +    /* Vendor ID reg */
> +    {
> +        .offset     = PCI_VENDOR_ID,
> +        .size       = 2,
> +        .init_val   = 0x0000,
> +        .ro_mask    = 0xFFFF,
> +        .emu_mask   = 0xFFFF,
> +        .init       = pt_vendor_reg_init,
> +        .u.w.read   = pt_word_reg_read,
> +        .u.w.write  = pt_word_reg_write,
> +        .u.w.restore  = NULL,
> +    },
> +    /* Device ID reg */
> +    {
> +        .offset     = PCI_DEVICE_ID,
> +        .size       = 2,
> +        .init_val   = 0x0000,
> +        .ro_mask    = 0xFFFF,
> +        .emu_mask   = 0xFFFF,
> +        .init       = pt_device_reg_init,
> +        .u.w.read   = pt_word_reg_read,
> +        .u.w.write  = pt_word_reg_write,
> +        .u.w.restore  = NULL,
> +    },
> +    /* Command reg */
> +    {
> +        .offset     = PCI_COMMAND,
> +        .size       = 2,
> +        .init_val   = 0x0000,
> +        .ro_mask    = 0xF880,
> +        .emu_mask   = 0x0740,
> +        .init       = pt_common_reg_init,
> +        .u.w.read   = pt_cmd_reg_read,
> +        .u.w.write  = pt_cmd_reg_write,
> +        .u.w.restore  = pt_cmd_reg_restore,
> +    },
> +    /* Capabilities Pointer reg */
> +    {
> +        .offset     = PCI_CAPABILITY_LIST,
> +        .size       = 1,
> +        .init_val   = 0x00,
> +        .ro_mask    = 0xFF,
> +        .emu_mask   = 0xFF,
> +        .init       = pt_ptr_reg_init,
> +        .u.b.read   = pt_byte_reg_read,
> +        .u.b.write  = pt_byte_reg_write,
> +        .u.b.restore  = NULL,
> +    },
> +    /* Status reg */
> +    /* use emulated Cap Ptr value to initialize,
> +     * so need to be declared after Cap Ptr reg
> +     */
> +    {
> +        .offset     = PCI_STATUS,
> +        .size       = 2,
> +        .init_val   = 0x0000,
> +        .ro_mask    = 0x06FF,
> +        .emu_mask   = 0x0010,
> +        .init       = pt_status_reg_init,
> +        .u.w.read   = pt_word_reg_read,
> +        .u.w.write  = pt_word_reg_write,
> +        .u.w.restore  = NULL,
> +    },
> +    /* Cache Line Size reg */
> +    {
> +        .offset     = PCI_CACHE_LINE_SIZE,
> +        .size       = 1,
> +        .init_val   = 0x00,
> +        .ro_mask    = 0x00,
> +        .emu_mask   = 0xFF,
> +        .init       = pt_common_reg_init,
> +        .u.b.read   = pt_byte_reg_read,
> +        .u.b.write  = pt_byte_reg_write,
> +        .u.b.restore  = pt_byte_reg_restore,
> +    },
> +    /* Latency Timer reg */
> +    {
> +        .offset     = PCI_LATENCY_TIMER,
> +        .size       = 1,
> +        .init_val   = 0x00,
> +        .ro_mask    = 0x00,
> +        .emu_mask   = 0xFF,
> +        .init       = pt_common_reg_init,
> +        .u.b.read   = pt_byte_reg_read,
> +        .u.b.write  = pt_byte_reg_write,
> +        .u.b.restore  = pt_byte_reg_restore,
> +    },
> +    /* Header Type reg */
> +    {
> +        .offset     = PCI_HEADER_TYPE,
> +        .size       = 1,
> +        .init_val   = 0x00,
> +        .ro_mask    = 0xFF,
> +        .emu_mask   = 0x00,
> +        .init       = pt_header_type_reg_init,
> +        .u.b.read   = pt_byte_reg_read,
> +        .u.b.write  = pt_byte_reg_write,
> +        .u.b.restore  = NULL,
> +    },
> +    /* Interrupt Line reg */
> +    {
> +        .offset     = PCI_INTERRUPT_LINE,
> +        .size       = 1,
> +        .init_val   = 0x00,
> +        .ro_mask    = 0x00,
> +        .emu_mask   = 0xFF,
> +        .init       = pt_common_reg_init,
> +        .u.b.read   = pt_byte_reg_read,
> +        .u.b.write  = pt_byte_reg_write,
> +        .u.b.restore  = NULL,
> +    },
> +    /* Interrupt Pin reg */
> +    {
> +        .offset     = PCI_INTERRUPT_PIN,
> +        .size       = 1,
> +        .init_val   = 0x00,
> +        .ro_mask    = 0xFF,
> +        .emu_mask   = 0xFF,
> +        .init       = pt_irqpin_reg_init,
> +        .u.b.read   = pt_byte_reg_read,
> +        .u.b.write  = pt_byte_reg_write,
> +        .u.b.restore  = NULL,
> +    },
> +    /* BAR 0 reg */
> +    /* mask of BAR need to be decided later, depends on IO/MEM type */
> +    {
> +        .offset     = PCI_BASE_ADDRESS_0,
> +        .size       = 4,
> +        .init_val   = 0x00000000,
> +        .init       = pt_bar_reg_init,
> +        .u.dw.read  = pt_bar_reg_read,
> +        .u.dw.write = pt_bar_reg_write,
> +        .u.dw.restore = pt_bar_reg_restore,
> +    },
> +    /* BAR 1 reg */
> +    {
> +        .offset     = PCI_BASE_ADDRESS_1,
> +        .size       = 4,
> +        .init_val   = 0x00000000,
> +        .init       = pt_bar_reg_init,
> +        .u.dw.read  = pt_bar_reg_read,
> +        .u.dw.write = pt_bar_reg_write,
> +        .u.dw.restore = pt_bar_reg_restore,
> +    },
> +    /* BAR 2 reg */
> +    {
> +        .offset     = PCI_BASE_ADDRESS_2,
> +        .size       = 4,
> +        .init_val   = 0x00000000,
> +        .init       = pt_bar_reg_init,
> +        .u.dw.read  = pt_bar_reg_read,
> +        .u.dw.write = pt_bar_reg_write,
> +        .u.dw.restore = pt_bar_reg_restore,
> +    },
> +    /* BAR 3 reg */
> +    {
> +        .offset     = PCI_BASE_ADDRESS_3,
> +        .size       = 4,
> +        .init_val   = 0x00000000,
> +        .init       = pt_bar_reg_init,
> +        .u.dw.read  = pt_bar_reg_read,
> +        .u.dw.write = pt_bar_reg_write,
> +        .u.dw.restore = pt_bar_reg_restore,
> +    },
> +    /* BAR 4 reg */
> +    {
> +        .offset     = PCI_BASE_ADDRESS_4,
> +        .size       = 4,
> +        .init_val   = 0x00000000,
> +        .init       = pt_bar_reg_init,
> +        .u.dw.read  = pt_bar_reg_read,
> +        .u.dw.write = pt_bar_reg_write,
> +        .u.dw.restore = pt_bar_reg_restore,
> +    },
> +    /* BAR 5 reg */
> +    {
> +        .offset     = PCI_BASE_ADDRESS_5,
> +        .size       = 4,
> +        .init_val   = 0x00000000,
> +        .init       = pt_bar_reg_init,
> +        .u.dw.read  = pt_bar_reg_read,
> +        .u.dw.write = pt_bar_reg_write,
> +        .u.dw.restore = pt_bar_reg_restore,
> +    },
> +    /* Expansion ROM BAR reg */
> +    {
> +        .offset     = PCI_ROM_ADDRESS,
> +        .size       = 4,
> +        .init_val   = 0x00000000,
> +        .ro_mask    = 0x000007FE,
> +        .emu_mask   = 0xFFFFF800,
> +        .init       = pt_bar_reg_init,
> +        .u.dw.read  = pt_long_reg_read,
> +        .u.dw.write = pt_exp_rom_bar_reg_write,
> +        .u.dw.restore = pt_exp_rom_bar_reg_restore,
> +    },
> +    {
> +        .size = 0,
> +    },
> +};
> +
> +
> +/*********************************
> + * Vital Product Data Capability
> + */
> +
> +/* Vital Product Data Capability Structure reg static infomation table */
> +static XenPTRegInfo pt_emu_reg_vpd_tbl[] = {
> +    {
> +        .offset     = PCI_CAP_LIST_NEXT,
> +        .size       = 1,
> +        .init_val   = 0x00,
> +        .ro_mask    = 0xFF,
> +        .emu_mask   = 0xFF,
> +        .init       = pt_ptr_reg_init,
> +        .u.b.read   = pt_byte_reg_read,
> +        .u.b.write  = pt_byte_reg_write,
> +        .u.b.restore  = NULL,
> +    },
> +    {
> +        .size = 0,
> +    },
> +};
> +
> +
> +/**************************************
> + * Vendor Specific Capability
> + */
> +
> +/* Vendor Specific Capability Structure reg static infomation table */
> +static XenPTRegInfo pt_emu_reg_vendor_tbl[] = {
> +    {
> +        .offset     = PCI_CAP_LIST_NEXT,
> +        .size       = 1,
> +        .init_val   = 0x00,
> +        .ro_mask    = 0xFF,
> +        .emu_mask   = 0xFF,
> +        .init       = pt_ptr_reg_init,
> +        .u.b.read   = pt_byte_reg_read,
> +        .u.b.write  = pt_byte_reg_write,
> +        .u.b.restore  = NULL,
> +    },
> +    {
> +        .size = 0,
> +    },
> +};
> +
> +
> +/*****************************
> + * PCI Express Capability
> + */
> +
> +/* initialize Link Control register */
> +static int pt_linkctrl_reg_init(XenPCIPassthroughState *s,
> +                                XenPTRegInfo *reg, uint32_t real_offset,
> +                                uint32_t *data)
> +{
> +    uint8_t cap_ver = 0;
> +    uint8_t dev_type = 0;
> +
> +    cap_ver = pci_get_byte(s->dev.config + real_offset - reg->offset
> +                           + PCI_EXP_FLAGS)
> +        & PCI_EXP_FLAGS_VERS;

Hmm. Weird tabbing? Or maybe it is my mailer?

> +    dev_type = (pci_get_byte(s->dev.config + real_offset - reg->offset
> +                             + PCI_EXP_FLAGS)
> +                & PCI_EXP_FLAGS_TYPE) >> 4;

Here it looks better.. but still not sure about the "+ PCI_EXP_FLAGS"?

> +
> +    /* no need to initialize in case of Root Complex Integrated Endpoint
> +     * with cap_ver 1.x
> +     */
> +    if ((dev_type == PCI_EXP_TYPE_RC_END) && (cap_ver == 1)) {
> +        *data = PT_INVALID_REG;
> +    }
> +
> +    *data = reg->init_val;
> +    return 0;
> +}
> +/* initialize Device Control 2 register */
> +static int pt_devctrl2_reg_init(XenPCIPassthroughState *s,
> +                                XenPTRegInfo *reg, uint32_t real_offset,
> +                                uint32_t *data)
> +{
> +    uint8_t cap_ver = 0;
> +
> +    cap_ver = pci_get_byte(s->dev.config + real_offset - reg->offset
> +                           + PCI_EXP_FLAGS)
> +        & PCI_EXP_FLAGS_VERS;

Tab-mayhem!

> +
> +    /* no need to initialize in case of cap_ver 1.x */
> +    if (cap_ver == 1) {
> +        *data = PT_INVALID_REG;
> +    }
> +
> +    *data = reg->init_val;
> +    return 0;
> +}
> +/* initialize Link Control 2 register */
> +static int pt_linkctrl2_reg_init(XenPCIPassthroughState *s,
> +                                 XenPTRegInfo *reg, uint32_t real_offset,
> +                                 uint32_t *data)
> +{
> +    uint32_t reg_field = 0;
> +    uint8_t cap_ver = 0;
> +
> +    cap_ver = pci_get_byte(s->dev.config + real_offset - reg->offset
> +                           + PCI_EXP_FLAGS)
> +        & PCI_EXP_FLAGS_VERS;

.. strikes again!

> +
> +    /* no need to initialize in case of cap_ver 1.x */
> +    if (cap_ver == 1) {
> +        reg_field = PT_INVALID_REG;
> +    } else {
> +        /* set Supported Link Speed */
> +        uint8_t lnkcap = pci_get_byte(s->dev.config + real_offset - reg->offset
> +                                      + PCI_EXP_LNKCAP);
> +        reg_field |= PCI_EXP_LNKCAP_SLS & lnkcap;
> +    }
> +
> +    *data = reg_field;
> +    return 0;
> +}
> +
> +/* PCI Express Capability Structure reg static infomation table */
> +static XenPTRegInfo pt_emu_reg_pcie_tbl[] = {
> +    /* Next Pointer reg */
> +    {
> +        .offset     = PCI_CAP_LIST_NEXT,
> +        .size       = 1,
> +        .init_val   = 0x00,
> +        .ro_mask    = 0xFF,
> +        .emu_mask   = 0xFF,
> +        .init       = pt_ptr_reg_init,
> +        .u.b.read   = pt_byte_reg_read,
> +        .u.b.write  = pt_byte_reg_write,
> +        .u.b.restore  = NULL,
> +    },
> +    /* Device Capabilities reg */
> +    {
> +        .offset     = PCI_EXP_DEVCAP,
> +        .size       = 4,
> +        .init_val   = 0x00000000,
> +        .ro_mask    = 0x1FFCFFFF,
> +        .emu_mask   = 0x10000000,
> +        .init       = pt_common_reg_init,
> +        .u.dw.read  = pt_long_reg_read,
> +        .u.dw.write = pt_long_reg_write,
> +        .u.dw.restore = NULL,
> +    },
> +    /* Device Control reg */
> +    {
> +        .offset     = PCI_EXP_DEVCTL,
> +        .size       = 2,
> +        .init_val   = 0x2810,
> +        .ro_mask    = 0x8400,
> +        .emu_mask   = 0xFFFF,
> +        .init       = pt_common_reg_init,
> +        .u.w.read   = pt_word_reg_read,
> +        .u.w.write  = pt_word_reg_write,
> +        .u.w.restore  = pt_word_reg_restore,
> +    },
> +    /* Link Control reg */
> +    {
> +        .offset     = PCI_EXP_LNKCTL,
> +        .size       = 2,
> +        .init_val   = 0x0000,
> +        .ro_mask    = 0xFC34,
> +        .emu_mask   = 0xFFFF,
> +        .init       = pt_linkctrl_reg_init,
> +        .u.w.read   = pt_word_reg_read,
> +        .u.w.write  = pt_word_reg_write,
> +        .u.w.restore  = pt_word_reg_restore,
> +    },
> +    /* Device Control 2 reg */
> +    {
> +        .offset     = 0x28,
> +        .size       = 2,
> +        .init_val   = 0x0000,
> +        .ro_mask    = 0xFFE0,
> +        .emu_mask   = 0xFFFF,
> +        .init       = pt_devctrl2_reg_init,
> +        .u.w.read   = pt_word_reg_read,
> +        .u.w.write  = pt_word_reg_write,
> +        .u.w.restore  = pt_word_reg_restore,
> +    },
> +    /* Link Control 2 reg */
> +    {
> +        .offset     = 0x30,
> +        .size       = 2,
> +        .init_val   = 0x0000,
> +        .ro_mask    = 0xE040,
> +        .emu_mask   = 0xFFFF,
> +        .init       = pt_linkctrl2_reg_init,
> +        .u.w.read   = pt_word_reg_read,
> +        .u.w.write  = pt_word_reg_write,
> +        .u.w.restore  = pt_word_reg_restore,
> +    },
> +    {
> +        .size = 0,
> +    },
> +};
> +
> +
> +/*********************************
> + * Power Management Capability
> + */
> +
> +/* initialize Power Management Capabilities register */
> +static int pt_pmc_reg_init(XenPCIPassthroughState *s,
> +                           XenPTRegInfo *reg, uint32_t real_offset,
> +                           uint32_t *data)
> +{
> +    PCIDevice *d = &s->dev;
> +
> +    if (s->power_mgmt) {
> +        /* set Power Management Capabilities register */
> +        s->pm_state->pmc_field = pci_get_word(d->config + real_offset);
> +    }
> +
> +    *data = reg->init_val;
> +    return 0;
> +}
> +/* initialize PCI Power Management Control/Status register */
> +static int pt_pmcsr_reg_init(XenPCIPassthroughState *s,
> +                             XenPTRegInfo *reg, uint32_t real_offset,
> +                             uint32_t *data)
> +{
> +    PCIDevice *d = &s->dev;
> +    uint16_t cap_ver  = 0;
> +    uint16_t v = 0;
> +
> +    if (!s->power_mgmt) {
> +        *data = reg->init_val;
> +        return 0;
> +    }
> +
> +    /* check PCI Power Management support version */
> +    cap_ver = s->pm_state->pmc_field & PCI_PM_CAP_VER_MASK;
> +
> +    if (cap_ver > 2) {
> +        /* set No Soft Reset */
> +        s->pm_state->no_soft_reset =
> +            pci_get_byte(d->config + real_offset) & PCI_PM_CTRL_NO_SOFT_RESET;
> +    }
> +
> +    host_pci_get_word(s->real_device, real_offset, &v);
> +    /* wake up real physical device */
> +    switch (v & PCI_PM_CTRL_STATE_MASK) {
> +    case 0:
> +        break;
> +    case 1:
> +        PT_LOG(d, "Power state transition D1 -> D0active\n");
> +        host_pci_set_word(s->real_device, real_offset, 0);
> +        break;
> +    case 2:
> +        PT_LOG(d, "Power state transition D2 -> D0active\n");
> +        host_pci_set_word(s->real_device, real_offset, 0);
> +        usleep(200);
> +        break;
> +    case 3:
> +        PT_LOG(d, "Power state transition D3hot -> D0active\n");
> +        host_pci_set_word(s->real_device, real_offset, 0);
> +        usleep(10 * 1000);
> +        if (pt_init_pci_config(s)) {
> +            return -1;
> +        }
> +        break;
> +    }
> +
> +    *data = reg->init_val;
> +    return 0;
> +}
> +/* read Power Management Control/Status register */
> +static int pt_pmcsr_reg_read(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
> +                             uint16_t *value, uint16_t valid_mask)
> +{
> +    XenPTRegInfo *reg = cfg_entry->reg;
> +    uint16_t valid_emu_mask = reg->emu_mask;
> +
> +    if (!s->power_mgmt) {
> +        valid_emu_mask |= PCI_PM_CTRL_STATE_MASK | PCI_PM_CTRL_NO_SOFT_RESET;
> +    }
> +
> +    valid_emu_mask = valid_emu_mask & valid_mask;
> +    *value = PT_MERGE_VALUE(*value, cfg_entry->data, ~valid_emu_mask);
> +
> +    return 0;
> +}
> +/* reset Interrupt and I/O resource  */
> +static void pt_reset_interrupt_and_io_mapping(XenPCIPassthroughState *s)
> +{
> +    PCIDevice *d = &s->dev;
> +    PCIIORegion *r;
> +    int i = 0;
> +    uint8_t e_device = 0;
> +    uint8_t e_intx = 0;
> +
> +    /* unbind INTx */
> +    e_device = PCI_SLOT(s->dev.devfn);
> +    e_intx = pci_intx(s);
> +
> +    if (s->machine_irq) {
> +        if (xc_domain_unbind_pt_irq(xen_xc, xen_domid, s->machine_irq,
> +                                    PT_IRQ_TYPE_PCI, 0, e_device, e_intx, 0)) {
> +            PT_ERR(d, "Unbinding of interrupt failed!\n");
> +        }
> +    }
> +
> +    /* clear all virtual region address */
> +    for (i = 0; i < PCI_NUM_REGIONS; i++) {
> +        r = &d->io_regions[i];
> +        r->addr = -1;
> +    }
> +
> +    /* unmapping BAR */
> +    pt_bar_mapping(s, 0, 0);
> +}
> +/* check power state transition */
> +static int check_power_state(XenPCIPassthroughState *s)
> +{
> +    XenPTPM *pm_state = s->pm_state;
> +    PCIDevice *d = &s->dev;
> +    uint16_t read_val = 0;
> +    uint16_t cur_state = 0;
> +
> +    /* get current power state */
> +    if (host_pci_get_word(s->real_device, pm_state->pm_base + PCI_PM_CTRL,
> +                          &read_val)) {
> +        return -1;
> +    }
> +    cur_state = read_val & PCI_PM_CTRL_STATE_MASK;
> +
> +    if (pm_state->req_state != cur_state) {
> +        PT_ERR(d, "Failed to change power state. "
> +               "(requested state: %d, current state: %d)\n",
> +               pm_state->req_state, cur_state);
> +        return -1;
> +    }
> +    return 0;
> +}
> +/* write Power Management Control/Status register */
> +static void pt_from_d3hot_to_d0_with_reset(void *opaque)
> +{
> +    XenPCIPassthroughState *s = opaque;
> +    XenPTPM *pm_state = s->pm_state;
> +    int ret = 0;
> +
> +    /* check power state */
> +    ret = check_power_state(s);
> +
> +    if (ret < 0) {
> +        goto out;
> +    }
> +
> +    pt_init_pci_config(s);
> +
> +out:
> +    /* power state transition flags off */
> +    pm_state->flags &= ~PT_FLAG_TRANSITING;
> +
> +    qemu_free_timer(pm_state->pm_timer);
> +    pm_state->pm_timer = NULL;
> +}
> +static void pt_default_power_transition(void *opaque)
> +{
> +    XenPCIPassthroughState *ptdev = opaque;
> +    XenPTPM *pm_state = ptdev->pm_state;
> +
> +    /* check power state */
> +    check_power_state(ptdev);
> +
> +    /* power state transition flags off */
> +    pm_state->flags &= ~PT_FLAG_TRANSITING;
> +
> +    qemu_free_timer(pm_state->pm_timer);
> +    pm_state->pm_timer = NULL;
> +}
> +static int pt_pmcsr_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
> +                              uint16_t *value, uint16_t dev_value,
> +                              uint16_t valid_mask)
> +{
> +    XenPTRegInfo *reg = cfg_entry->reg;
> +    PCIDevice *d = &s->dev;
> +    uint16_t emu_mask = reg->emu_mask;
> +    uint16_t writable_mask = 0;
> +    uint16_t throughable_mask = 0;
> +    XenPTPM *pm_state = s->pm_state;
> +
> +    if (!s->power_mgmt) {
> +        emu_mask |= PCI_PM_CTRL_STATE_MASK | PCI_PM_CTRL_NO_SOFT_RESET;
> +    }
> +
> +    /* modify emulate register */
> +    writable_mask = emu_mask & ~reg->ro_mask & valid_mask;
> +    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
> +
> +    /* create value for writing to I/O device register */
> +    throughable_mask = ~emu_mask & valid_mask;
> +    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
> +
> +    if (!s->power_mgmt) {
> +        return 0;
> +    }
> +
> +    /* set I/O device power state */
> +    pm_state->cur_state = dev_value & PCI_PM_CTRL_STATE_MASK;
> +
> +    /* set Guest requested PowerState */
> +    pm_state->req_state = *value & PCI_PM_CTRL_STATE_MASK;
> +
> +    /* check power state transition or not */
> +    if (pm_state->cur_state == pm_state->req_state) {
> +        /* not power state transition */

.. No power state transition.

> +        return 0;
> +    }
> +
> +    /* check enable power state transition */
> +    if ((pm_state->req_state != 0) &&
> +        (pm_state->cur_state > pm_state->req_state)) {
> +        PT_ERR(d, "Invalid power transition. "
> +               "(requested state: %d, current state: %d)\n",
> +               pm_state->req_state, pm_state->cur_state);
> +
> +        return 0;
> +    }
> +
> +    /* check if this device supports the requested power state */
> +    if (((pm_state->req_state == 1) && !(pm_state->pmc_field & PCI_PM_CAP_D1))
> +        || ((pm_state->req_state == 2) &&
> +            !(pm_state->pmc_field & PCI_PM_CAP_D2))) {
> +        PT_ERR(d, "Invalid power transition. "
> +               "(requested state: %d, current state: %d)\n",
> +               pm_state->req_state, pm_state->cur_state);
> +
> +        return 0;
> +    }
> +
> +    /* in case of transition related to D3hot, it's necessary to wait 10 ms.
> +     * But because writing to register will be performed later on actually,

'performed later on,'
> +     * don't start QEMUTimer right now, just alloc and init QEMUTimer here.

You might want to say where it will be started.

> +     */
> +    if ((pm_state->cur_state == 3) || (pm_state->req_state == 3)) {
> +        if (pm_state->req_state == 0) {
> +            /* alloc and init QEMUTimer */
> +            if (!pm_state->no_soft_reset) {
> +                pm_state->pm_timer = qemu_new_timer_ms(rt_clock,
> +                    pt_from_d3hot_to_d0_with_reset, s);
> +
> +                /* reset Interrupt and I/O resource mapping */
> +                pt_reset_interrupt_and_io_mapping(s);
> +            } else {
> +                pm_state->pm_timer = qemu_new_timer_ms(rt_clock,
> +                                        pt_default_power_transition, s);
> +            }
> +        } else {
> +            /* alloc and init QEMUTimer */
> +            pm_state->pm_timer = qemu_new_timer_ms(rt_clock,
> +                pt_default_power_transition, s);
> +        }
> +
> +        /* set power state transition delay */
> +        pm_state->pm_delay = 10;
> +
> +        /* power state transition flags on */
> +        pm_state->flags |= PT_FLAG_TRANSITING;
> +    }
> +    /* in case of transition related to D0, D1 and D2,
> +     * no need to use QEMUTimer.
> +     * So, we perfom writing to register here and then read it back.
> +     */
> +    else {
> +        /* write power state to I/O device register */
> +        host_pci_set_word(s->real_device, pm_state->pm_base + PCI_PM_CTRL,
> +                          *value);
> +
> +        /* in case of transition related to D2,
> +         * it's necessary to wait 200 usec.
> +         * But because QEMUTimer do not support microsec unit right now,
> +         * so we do wait ourself here.

'.. QEMUTimer does not support microsec resolution, we will wait here.'

> +         */
> +        if ((pm_state->cur_state == 2) || (pm_state->req_state == 2)) {
> +            usleep(200);
> +        }
> +
> +        /* check power state */
> +        check_power_state(s);
> +
> +        /* recreate value for writing to I/O device register */
> +        if (host_pci_get_word(s->real_device, pm_state->pm_base + PCI_PM_CTRL,
> +                              value)) {
> +            return -1;
> +        }
> +    }
> +
> +    return 0;
> +}
> +
> +/* restore Power Management Control/Status register */
> +static int pt_pmcsr_reg_restore(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
> +                                uint32_t real_offset, uint16_t dev_value,
> +                                uint16_t *value)
> +{
> +    /* create value for restoring to I/O device register
> +     * No need to restore, just clear PME Enable and PME Status bit
> +     * Note: register type of PME Status bit is RW1C, so clear by writing 1b
> +     */
> +    *value = (dev_value & ~PCI_PM_CTRL_PME_ENABLE) | PCI_PM_CTRL_PME_STATUS;
> +
> +    return 0;
> +}
> +
> +
> +/* Power Management Capability reg static infomation table */
> +static XenPTRegInfo pt_emu_reg_pm_tbl[] = {
> +    /* Next Pointer reg */
> +    {
> +        .offset     = PCI_CAP_LIST_NEXT,
> +        .size       = 1,
> +        .init_val   = 0x00,
> +        .ro_mask    = 0xFF,
> +        .emu_mask   = 0xFF,
> +        .init       = pt_ptr_reg_init,
> +        .u.b.read   = pt_byte_reg_read,
> +        .u.b.write  = pt_byte_reg_write,
> +        .u.b.restore  = NULL,
> +    },
> +    /* Power Management Capabilities reg */
> +    {
> +        .offset     = PCI_CAP_FLAGS,
> +        .size       = 2,
> +        .init_val   = 0x0000,
> +        .ro_mask    = 0xFFFF,
> +        .emu_mask   = 0xF9C8,
> +        .init       = pt_pmc_reg_init,
> +        .u.w.read   = pt_word_reg_read,
> +        .u.w.write  = pt_word_reg_write,
> +        .u.w.restore  = NULL,
> +    },
> +    /* PCI Power Management Control/Status reg */
> +    {
> +        .offset     = PCI_PM_CTRL,
> +        .size       = 2,
> +        .init_val   = 0x0008,
> +        .ro_mask    = 0xE1FC,
> +        .emu_mask   = 0x8100,
> +        .init       = pt_pmcsr_reg_init,
> +        .u.w.read   = pt_pmcsr_reg_read,
> +        .u.w.write  = pt_pmcsr_reg_write,
> +        .u.w.restore  = pt_pmcsr_reg_restore,
> +    },
> +    {
> +        .size = 0,
> +    },
> +};
> +
> +
> +/****************************
> + * Capabilities
> + */
> +
> +/* AER register operations */
> +
> +static void aer_save_one_register(XenPCIPassthroughState *s, int offset)
> +{
> +    PCIDevice *d = &s->dev;
> +    uint32_t aer_base = s->pm_state->aer_base;
> +    uint32_t val = 0;
> +
> +    if (host_pci_get_long(s->real_device, aer_base + offset, &val)) {
> +        return;
> +    }
> +    pci_set_long(d->config + aer_base + offset, val);
> +}
> +static void pt_aer_reg_save(XenPCIPassthroughState *s)
> +{
> +    /* after reset, following register values should be restored.
> +     * So, save them.
> +     */
> +    aer_save_one_register(s, PCI_ERR_UNCOR_MASK);
> +    aer_save_one_register(s, PCI_ERR_UNCOR_SEVER);
> +    aer_save_one_register(s, PCI_ERR_COR_MASK);
> +    aer_save_one_register(s, PCI_ERR_CAP);
> +}
> +static void aer_restore_one_register(XenPCIPassthroughState *s, int offset)
> +{
> +    PCIDevice *d = &s->dev;
> +    uint32_t aer_base = s->pm_state->aer_base;
> +    uint32_t config = 0;
> +
> +    config = pci_get_long(d->config + aer_base + offset);
> +    host_pci_set_long(s->real_device, aer_base + offset, config);
> +}
> +static void pt_aer_reg_restore(XenPCIPassthroughState *s)
> +{
> +    /* the following registers should be reconfigured to correct values

the -> The
> +     * after reset. restore them.

reset. -> reset, hence
> +     * other registers should not be reconfigured after reset

'Other'

> +     * if there is no reason

So what are the other registers? Every other register _but_ the
ones that are enumerated here? If so, please state that explicitly.

> +     */
> +    aer_restore_one_register(s, PCI_ERR_UNCOR_MASK);
> +    aer_restore_one_register(s, PCI_ERR_UNCOR_SEVER);
> +    aer_restore_one_register(s, PCI_ERR_COR_MASK);
> +    aer_restore_one_register(s, PCI_ERR_CAP);
> +}
> +
> +/* capability structure register group size functions */
> +
> +static int pt_reg_grp_size_init(XenPCIPassthroughState *s,
> +                                const XenPTRegGroupInfo *grp_reg,
> +                                uint32_t base_offset, uint8_t *size)
> +{
> +    *size = grp_reg->grp_size;
> +    return 0;
> +}
> +/* get Power Management Capability Structure register group size */
> +static int pt_pm_size_init(XenPCIPassthroughState *s,
> +                           const XenPTRegGroupInfo *grp_reg,
> +                           uint32_t base_offset, uint8_t *size)
> +{
> +    *size = grp_reg->grp_size;
> +
> +    if (!s->power_mgmt) {
> +        return 0;
> +    }
> +
> +    s->pm_state = g_new0(XenPTPM, 1);
> +
> +    /* set Power Management Capability base offset */
> +    s->pm_state->pm_base = base_offset;
> +
> +    /* find AER register and set AER Capability base offset */
> +    s->pm_state->aer_base = host_pci_find_ext_cap_offset(s->real_device,
> +                                                         PCI_EXT_CAP_ID_ERR);
> +
> +    /* save AER register */
> +    if (s->pm_state->aer_base) {
> +        pt_aer_reg_save(s);
> +    }
> +
> +    return 0;
> +}
> +/* get Vendor Specific Capability Structure register group size */
> +static int pt_vendor_size_init(XenPCIPassthroughState *s,
> +                               const XenPTRegGroupInfo *grp_reg,
> +                               uint32_t base_offset, uint8_t *size)
> +{
> +    *size = pci_get_byte(s->dev.config + base_offset + 0x02);
> +    return 0;
> +}
> +/* get PCI Express Capability Structure register group size */
> +static int pt_pcie_size_init(XenPCIPassthroughState *s,
> +                             const XenPTRegGroupInfo *grp_reg,
> +                             uint32_t base_offset, uint8_t *size)
> +{
> +    PCIDevice *d = &s->dev;
> +    uint16_t exp_flag = 0;
> +    uint16_t type = 0;
> +    uint16_t version = 0;
> +    uint8_t pcie_size = 0;
> +
> +    exp_flag = pci_get_word(d->config + base_offset + PCI_EXP_FLAGS);
> +    type = (exp_flag & PCI_EXP_FLAGS_TYPE) >> 4;
> +    version = exp_flag & PCI_EXP_FLAGS_VERS;
> +
> +    /* calculate size depend on capability version and device/port type */
> +    /* in case of PCI Express Base Specification Rev 1.x */
> +    if (version == 1) {
> +        /* The PCI Express Capabilities, Device Capabilities, and Device
> +         * Status/Control registers are required for all PCI Express devices.
> +         * The Link Capabilities and Link Status/Control are required for all
> +         * Endpoints that are not Root Complex Integrated Endpoints. Endpoints
> +         * are not required to implement registers other than those listed
> +         * above and terminate the capability structure.
> +         */
> +        switch (type) {
> +        case PCI_EXP_TYPE_ENDPOINT:
> +        case PCI_EXP_TYPE_LEG_END:
> +            pcie_size = 0x14;
> +            break;
> +        case PCI_EXP_TYPE_RC_END:
> +            /* has no link */
> +            pcie_size = 0x0C;
> +            break;
> +        /* only EndPoint passthrough is supported */
> +        case PCI_EXP_TYPE_ROOT_PORT:
> +        case PCI_EXP_TYPE_UPSTREAM:
> +        case PCI_EXP_TYPE_DOWNSTREAM:
> +        case PCI_EXP_TYPE_PCI_BRIDGE:
> +        case PCI_EXP_TYPE_PCIE_BRIDGE:
> +        case PCI_EXP_TYPE_RC_EC:
> +        default:
> +            PT_ERR(d, "Internal error: Unsupported device/port type (%d).\n",
> +                   type);
> +            return -1;
> +        }
> +    }
> +    /* in case of PCI Express Base Specification Rev 2.0 */
> +    else if (version == 2) {
> +        switch (type) {
> +        case PCI_EXP_TYPE_ENDPOINT:
> +        case PCI_EXP_TYPE_LEG_END:
> +        case PCI_EXP_TYPE_RC_END:
> +            /* For Functions that do not implement the registers,
> +             * these spaces must be hardwired to 0b.

So this comment applies to the functions below the 'break' right?
Should you move it? But that doesn't make sense - we end up hitting
return -1 so it bails out and does not return 0b. Hmmm.. So what is
this comment referring to?

> +             */
> +            pcie_size = 0x3C;
> +            break;
> +        /* only EndPoint passthrough is supported */
> +        case PCI_EXP_TYPE_ROOT_PORT:
> +        case PCI_EXP_TYPE_UPSTREAM:
> +        case PCI_EXP_TYPE_DOWNSTREAM:
> +        case PCI_EXP_TYPE_PCI_BRIDGE:
> +        case PCI_EXP_TYPE_PCIE_BRIDGE:
> +        case PCI_EXP_TYPE_RC_EC:
> +        default:
> +            PT_ERR(d, "Internal error: Unsupported device/port type (%d).\n",
> +                   type);
> +            return -1;
> +        }
> +    } else {
> +        PT_ERR(d, "Internal error: Unsupported capability version (%d).\n",
> +               version);
> +        return -1;
> +    }
> +
> +    *size = pcie_size;
> +    return 0;
> +}
> +
> +static const XenPTRegGroupInfo pt_emu_reg_grp_tbl[] = {
> +    /* Header Type0 reg group */
> +    {
> +        .grp_id      = 0xFF,
> +        .grp_type    = GRP_TYPE_EMU,
> +        .grp_size    = 0x40,
> +        .size_init   = pt_reg_grp_size_init,
> +        .emu_reg_tbl = pt_emu_reg_header0_tbl,
> +    },
> +    /* PCI PowerManagement Capability reg group */
> +    {
> +        .grp_id      = PCI_CAP_ID_PM,
> +        .grp_type    = GRP_TYPE_EMU,
> +        .grp_size    = PCI_PM_SIZEOF,
> +        .size_init   = pt_pm_size_init,
> +        .emu_reg_tbl = pt_emu_reg_pm_tbl,
> +    },
> +    /* AGP Capability Structure reg group */
> +    {
> +        .grp_id     = PCI_CAP_ID_AGP,
> +        .grp_type   = GRP_TYPE_HARDWIRED,
> +        .grp_size   = 0x30,
> +        .size_init  = pt_reg_grp_size_init,
> +    },
> +    /* Vital Product Data Capability Structure reg group */
> +    {
> +        .grp_id      = PCI_CAP_ID_VPD,
> +        .grp_type    = GRP_TYPE_EMU,
> +        .grp_size    = 0x08,
> +        .size_init   = pt_reg_grp_size_init,
> +        .emu_reg_tbl = pt_emu_reg_vpd_tbl,
> +    },
> +    /* Slot Identification reg group */
> +    {
> +        .grp_id     = PCI_CAP_ID_SLOTID,
> +        .grp_type   = GRP_TYPE_HARDWIRED,
> +        .grp_size   = 0x04,
> +        .size_init  = pt_reg_grp_size_init,
> +    },
> +    /* PCI-X Capabilities List Item reg group */
> +    {
> +        .grp_id     = PCI_CAP_ID_PCIX,
> +        .grp_type   = GRP_TYPE_HARDWIRED,
> +        .grp_size   = 0x18,
> +        .size_init  = pt_reg_grp_size_init,
> +    },
> +    /* Vendor Specific Capability Structure reg group */
> +    {
> +        .grp_id      = PCI_CAP_ID_VNDR,
> +        .grp_type    = GRP_TYPE_EMU,
> +        .grp_size    = 0xFF,
> +        .size_init   = pt_vendor_size_init,
> +        .emu_reg_tbl = pt_emu_reg_vendor_tbl,
> +    },
> +    /* SHPC Capability List Item reg group */
> +    {
> +        .grp_id     = PCI_CAP_ID_SHPC,
> +        .grp_type   = GRP_TYPE_HARDWIRED,
> +        .grp_size   = 0x08,
> +        .size_init  = pt_reg_grp_size_init,
> +    },
> +    /* Subsystem ID and Subsystem Vendor ID Capability List Item reg group */
> +    {
> +        .grp_id     = PCI_CAP_ID_SSVID,
> +        .grp_type   = GRP_TYPE_HARDWIRED,
> +        .grp_size   = 0x08,
> +        .size_init  = pt_reg_grp_size_init,
> +    },
> +    /* AGP 8x Capability Structure reg group */
> +    {
> +        .grp_id     = PCI_CAP_ID_AGP3,
> +        .grp_type   = GRP_TYPE_HARDWIRED,
> +        .grp_size   = 0x30,
> +        .size_init  = pt_reg_grp_size_init,
> +    },
> +    /* PCI Express Capability Structure reg group */
> +    {
> +        .grp_id      = PCI_CAP_ID_EXP,
> +        .grp_type    = GRP_TYPE_EMU,
> +        .grp_size    = 0xFF,
> +        .size_init   = pt_pcie_size_init,
> +        .emu_reg_tbl = pt_emu_reg_pcie_tbl,
> +    },
> +    {
> +        .grp_size = 0,
> +    },
> +};
> +
> +/* initialize Capabilities Pointer or Next Pointer register */
> +static int pt_ptr_reg_init(XenPCIPassthroughState *s,
> +                           XenPTRegInfo *reg, uint32_t real_offset,
> +                           uint32_t *data)
> +{
> +    /* uint32_t reg_field = (uint32_t)s->dev.config[real_offset]; */
> +    uint32_t reg_field = pci_get_byte(s->dev.config + real_offset);

There is no check whether real_offset > than the size of what is
in dev.config. Perhaps that should be done?

> +    int i;
> +
> +    /* find capability offset */
> +    while (reg_field) {
> +        for (i = 0; pt_emu_reg_grp_tbl[i].grp_size != 0; i++) {
> +            if (pt_hide_dev_cap(s->real_device,
> +                                pt_emu_reg_grp_tbl[i].grp_id)) {
> +                continue;
> +            }
> +            if (pt_emu_reg_grp_tbl[i].grp_id == s->dev.config[reg_field]) {
> +                if (pt_emu_reg_grp_tbl[i].grp_type == GRP_TYPE_EMU) {
> +                    goto out;
> +                }
> +                /* ignore the 0 hardwired capability, find next one */
> +                break;
> +            }
> +        }
> +        /* next capability */
> +        /* reg_field = (uint32_t)s->dev.config[reg_field + 1]; */
> +        reg_field = pci_get_byte(s->dev.config + reg_field + 1);
> +    }
> +
> +out:
> +    *data = reg_field;
> +    return 0;
> +}
> +
> +
> +/*************
> + * Main
> + */
> +
> +/* restore a part of I/O device register */
> +static int pt_config_restore(XenPCIPassthroughState *s)
> +{
> +    XenPTRegGroup *reg_grp_entry = NULL;
> +    XenPTReg *reg_entry = NULL;
> +    XenPTRegInfo *reg = NULL;
> +    uint32_t real_offset = 0;
> +    uint32_t read_val = 0;
> +    uint32_t val = 0;
> +    int rc = 0;
> +
> +    /* find emulate register group entry */
> +    QLIST_FOREACH(reg_grp_entry, &s->reg_grp_tbl, entries) {
> +        /* find emulate register entry */
> +        QLIST_FOREACH(reg_entry, &reg_grp_entry->reg_tbl_list, entries) {
> +            reg = reg_entry->reg;
> +
> +            /* check whether restoring is needed */
> +            if (!reg->u.b.restore) {
> +                continue;
> +            }
> +
> +            real_offset = reg_grp_entry->base_offset + reg->offset;
> +
> +            /* read I/O device register value */
> +            rc = host_pci_get_block(s->real_device, real_offset,
> +                                    (uint8_t *)&read_val, reg->size);
> +
> +            if (rc < 0) {
> +                PT_ERR(&s->dev, "pci_read_block failed. "
> +                       "return value: %d.\n", rc);
> +                memset(&read_val, 0xff, reg->size);
> +            }
> +
> +            val = 0;
> +
> +            /* restore based on register size */
> +            switch (reg->size) {
> +            case 1:
> +                /* byte register */
> +                rc = reg->u.b.restore(s, reg_entry, real_offset,
> +                                      (uint8_t)read_val, (uint8_t *)&val);
> +                break;
> +            case 2:
> +                /* word register */
> +                rc = reg->u.w.restore(s, reg_entry, real_offset,
> +                                      (uint16_t)read_val, (uint16_t *)&val);
> +                break;
> +            case 4:
> +                /* double word register */
> +                rc = reg->u.dw.restore(s, reg_entry, real_offset,
> +                                       (uint32_t)read_val, (uint32_t *)&val);
> +                break;
> +            }
> +
> +            /* restoring error */
> +            if (rc < 0) {
> +                xen_shutdown_fatal_error("Internal error: Invalid restoring."
> +                                         " (%s, rc: %d)\n", __func__, rc);
> +                return -1;
> +            }
> +
> +            PT_LOG_CONFIG(&s->dev, real_offset, val, reg->size);
> +
> +            rc = host_pci_set_block(s->real_device, real_offset,
> +                                    (uint8_t *)&val, reg->size);
> +
> +            if (rc < 0) {
> +                PT_ERR(&s->dev, "pci_write_block failed. "
> +                       "return value: %d.\n", rc);
> +                return -1;
> +            }
> +        }
> +    }
> +
> +    /* if AER supported, restore it */
> +    if (s->pm_state->aer_base) {
> +        pt_aer_reg_restore(s);
> +    }
> +    return 0;
> +}
> +/* reinitialize all emulate registers */
> +static int pt_config_reinit(XenPCIPassthroughState *s)
> +{
> +    XenPTRegGroup *reg_grp_entry = NULL;
> +    XenPTReg *reg_entry = NULL;
> +    XenPTRegInfo *reg = NULL;
> +    int rc = 0;
> +
> +    /* find emulate register group entry */
> +    QLIST_FOREACH(reg_grp_entry, &s->reg_grp_tbl, entries) {
> +        /* find emulate register entry */
> +        QLIST_FOREACH(reg_entry, &reg_grp_entry->reg_tbl_list, entries) {
> +            reg = reg_entry->reg;
> +            if (reg->init) {
> +                /* initialize emulate register */
> +                rc = reg->init(s, reg_entry->reg,
> +                               reg_grp_entry->base_offset + reg->offset,
> +                               &reg_entry->data);
> +                if (rc < 0) {
> +                    return rc;
> +                }
> +            }
> +        }
> +    }
> +    return 0;
> +}
> +
> +static int pt_init_pci_config(XenPCIPassthroughState *s)
> +{
> +    PCIDevice *d = &s->dev;
> +    int rc = 0;
> +
> +    PT_LOG(d, "Reinitialize PCI configuration registers due to power state"
> +           " transition with internal reset.\n");
> +
> +    /* restore a part of I/O device register */
> +    rc = pt_config_restore(s);
> +    if (rc < 0) {
> +        return rc;
> +    }
> +
> +    /* reinitialize all emulate register */
> +    rc = pt_config_reinit(s);
> +    if (rc < 0) {
> +        return rc;
> +    }
> +
> +    /* rebind machine_irq to device */
> +    if (s->machine_irq != 0) {
> +        uint8_t e_device = PCI_SLOT(s->dev.devfn);
> +        uint8_t e_intx = pci_intx(s);
> +
> +        rc = xc_domain_bind_pt_pci_irq(xen_xc, xen_domid, s->machine_irq, 0,
> +                                       e_device, e_intx);
> +        if (rc < 0) {
> +            PT_ERR(d, "Rebinding of interrupt failed! rc=%d\n", rc);
> +        }
> +    }
> +
> +    return rc;
> +}
> +
> +static uint8_t find_cap_offset(XenPCIPassthroughState *s, uint8_t cap)
> +{
> +    uint8_t id;
> +    int max_cap = 48;

You need to use #define for that. Also you might want just make it an
unsigned.

> +    uint8_t pos = PCI_CAPABILITY_LIST;
> +    uint8_t status = 0;
> +
> +    if (host_pci_get_byte(s->real_device, PCI_STATUS, &status)) {
> +        return 0;
> +    }
> +    if ((status & PCI_STATUS_CAP_LIST) == 0) {
> +        return 0;
> +    }
> +
> +    while (max_cap--) {
> +        if (host_pci_get_byte(s->real_device, pos, &pos)) {
> +            break;
> +        }
> +        if (pos < 0x40) {

Can you explain why? (I presume it is b/c the capabilities entries do
not exist before 0x40 offset?)

> +            break;
> +        }
> +
> +        pos &= ~3;
> +        if (host_pci_get_byte(s->real_device, pos + PCI_CAP_LIST_ID, &id)) {
> +            break;
> +        }
> +
> +        if (id == 0xff) {
> +            break;
> +        }
> +        if (id == cap) {
> +            return pos;
> +        }
> +
> +        pos += PCI_CAP_LIST_NEXT;
> +    }
> +    return 0;
> +}
> +
> +static int pt_config_reg_init(XenPCIPassthroughState *s,
> +                              XenPTRegGroup *reg_grp, XenPTRegInfo *reg)
> +{
> +    XenPTReg *reg_entry;
> +    uint32_t data = 0;
> +    int rc = 0;
> +
> +    reg_entry = g_new0(XenPTReg, 1);
> +    reg_entry->reg = reg;
> +
> +    if (reg->init) {
> +        /* initialize emulate register */
> +        rc = reg->init(s, reg_entry->reg,
> +                       reg_grp->base_offset + reg->offset, &data);
> +        if (rc < 0) {
> +            free(reg_entry);
> +            return rc;
> +        }
> +        if (data == PT_INVALID_REG) {
> +            /* free unused BAR register entry */
> +            free(reg_entry);
> +            return 0;
> +        }
> +        /* set register value */
> +        reg_entry->data = data;
> +    }
> +    /* list add register entry */
> +    QLIST_INSERT_HEAD(&reg_grp->reg_tbl_list, reg_entry, entries);
> +
> +    return 0;
> +}
> +
> +int pt_config_init(XenPCIPassthroughState *s)
> +{
> +    XenPTRegGroup *reg_grp_entry = NULL;
> +    uint32_t reg_grp_offset = 0;
> +    XenPTRegInfo *reg_tbl = NULL;
> +    int i, j, rc;
> +
> +    QLIST_INIT(&s->reg_grp_tbl);
> +
> +    for (i = 0; pt_emu_reg_grp_tbl[i].grp_size != 0; i++) {
> +        if (pt_emu_reg_grp_tbl[i].grp_id != 0xFF) {
> +            if (pt_hide_dev_cap(s->real_device,
> +                                pt_emu_reg_grp_tbl[i].grp_id)) {
> +                continue;
> +            }
> +
> +            reg_grp_offset = find_cap_offset(s, pt_emu_reg_grp_tbl[i].grp_id);
> +
> +            if (!reg_grp_offset) {
> +                continue;
> +            }
> +        }
> +
> +        reg_grp_entry = g_new0(XenPTRegGroup, 1);
> +        QLIST_INIT(&reg_grp_entry->reg_tbl_list);
> +        QLIST_INSERT_HEAD(&s->reg_grp_tbl, reg_grp_entry, entries);
> +
> +        reg_grp_entry->base_offset = reg_grp_offset;
> +        reg_grp_entry->reg_grp = pt_emu_reg_grp_tbl + i;
> +        if (pt_emu_reg_grp_tbl[i].size_init) {
> +            /* get register group size */
> +            rc = pt_emu_reg_grp_tbl[i].size_init(s, reg_grp_entry->reg_grp,
> +                                                 reg_grp_offset,
> +                                                 &reg_grp_entry->size);
> +            if (rc < 0) {
> +                pt_config_delete(s);
> +                return rc;
> +            }
> +        }
> +
> +        if (pt_emu_reg_grp_tbl[i].grp_type == GRP_TYPE_EMU) {
> +            if (pt_emu_reg_grp_tbl[i].emu_reg_tbl) {
> +                reg_tbl = pt_emu_reg_grp_tbl[i].emu_reg_tbl;
> +                /* initialize capability register */
> +                for (j = 0; reg_tbl->size != 0; j++, reg_tbl++) {
> +                    /* initialize capability register */
> +                    rc = pt_config_reg_init(s, reg_grp_entry, reg_tbl);
> +                    if (rc < 0) {
> +                        pt_config_delete(s);
> +                        return rc;
> +                    }
> +                }
> +            }
> +        }
> +        reg_grp_offset = 0;

Can you move this to the top of the loop?
> +    }
> +
> +    return 0;
> +}
> +
> +/* delete all emulate register */
> +void pt_config_delete(XenPCIPassthroughState *s)
> +{
> +    struct XenPTRegGroup *reg_group, *next_grp;
> +    struct XenPTReg *reg, *next_reg;
> +
> +    /* free Power Management info table */
> +    if (s->pm_state) {
> +        if (s->pm_state->pm_timer) {
> +            qemu_del_timer(s->pm_state->pm_timer);
> +            qemu_free_timer(s->pm_state->pm_timer);
> +            s->pm_state->pm_timer = NULL;
> +        }
> +
> +        g_free(s->pm_state);
> +    }
> +
> +    /* free all register group entry */
> +    QLIST_FOREACH_SAFE(reg_group, &s->reg_grp_tbl, entries, next_grp) {
> +        /* free all register entry */
> +        QLIST_FOREACH_SAFE(reg, &reg_group->reg_tbl_list, entries, next_reg) {
> +            QLIST_REMOVE(reg, entries);
> +            g_free(reg);
> +        }
> +
> +        QLIST_REMOVE(reg_group, entries);
> +        g_free(reg_group);
> +    }
> +}
> -- 
> Anthony PERARD
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 23:02:00 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 23: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.xensource.com>)
	id 1RXhXN-0004At-44; Mon, 05 Dec 2011 23:01:29 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1RXhXK-0004Am-VB
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 23:01:27 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-12.tower-174.messagelabs.com!1323126034!4319077!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12981 invoked from network); 5 Dec 2011 23:00:36 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-12.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 5 Dec 2011 23:00:36 -0000
Received: from andromeda.dapyr.net (darnok@localhost [127.0.0.1])
	by andromeda.dapyr.net (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id
	pB5N0Ku8015829
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Mon, 5 Dec 2011 18:00:20 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pB5N0K88015827;
	Mon, 5 Dec 2011 18:00:20 -0500
Date: Mon, 5 Dec 2011 19:00:20 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Anthony PERARD <anthony.perard@citrix.com>
Message-ID: <20111205230019.GA9560@andromeda.dapyr.net>
References: <1322156679-9441-1-git-send-email-anthony.perard@citrix.com>
	<1322156679-9441-9-git-send-email-anthony.perard@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1322156679-9441-9-git-send-email-anthony.perard@citrix.com>
User-Agent: Mutt/1.5.9i
Cc: Guy Zana <guy@neocleus.com>, Xen Devel <xen-devel@lists.xensource.com>,
	Allen Kay <allen.m.kay@intel.com>, QEMU-devel <qemu-devel@nongnu.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH V5 08/10] Introduce Xen PCI Passthrough,
	PCI config space helpers (2/3)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Nov 24, 2011 at 05:44:37PM +0000, Anthony PERARD wrote:
> From: Allen Kay <allen.m.kay@intel.com>
> 
> A more complete history can be found here:
> git://xenbits.xensource.com/qemu-xen-unstable.git
> 
> Signed-off-by: Allen Kay <allen.m.kay@intel.com>
> Signed-off-by: Guy Zana <guy@neocleus.com>
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> ---
>  hw/xen_pci_passthrough.c             |   15 +
>  hw/xen_pci_passthrough_config_init.c | 2131 ++++++++++++++++++++++++++++++++++
>  2 files changed, 2146 insertions(+), 0 deletions(-)
> 
> diff --git a/hw/xen_pci_passthrough.c b/hw/xen_pci_passthrough.c
> index 998470b..c816ed5 100644
> --- a/hw/xen_pci_passthrough.c
> +++ b/hw/xen_pci_passthrough.c
> @@ -360,6 +360,11 @@ out:
>              PT_ERR(d, "pci_write_block failed. return value: %d.\n", rc);
>          }
>      }
> +
> +    if (s->pm_state != NULL && s->pm_state->flags & PT_FLAG_TRANSITING) {
> +        qemu_mod_timer(s->pm_state->pm_timer,
> +                       qemu_get_clock_ms(rt_clock) + s->pm_state->pm_delay);
> +    }

Is this in the right place? There is code before in this function that
does:

if (s->pm_state != NULL && s->pm_state->flags & PT_FLAG_TRANSITING)
	return;

so we would never get here, I think?

>  }
>  
>  /* ioport/iomem space*/
> @@ -706,6 +711,13 @@ static int pt_initfn(PCIDevice *pcidev)
>      /* Handle real device's MMIO/PIO BARs */
>      pt_register_regions(s);
>  
> +    /* reinitialize each config register to be emulated */
> +    if (pt_config_init(s)) {
> +        PT_ERR(pcidev, "PCI Config space initialisation failed.\n");
> +        host_pci_device_put(s->real_device);
> +        return -1;
> +    }
> +
>      /* Bind interrupt */
>      if (!s->dev.config[PCI_INTERRUPT_PIN]) {
>          PT_LOG(pcidev, "no pin interrupt\n");
> @@ -798,6 +810,9 @@ static int pt_unregister_device(PCIDevice *pcidev)
>          }
>      }
>  
> +    /* delete all emulated config registers */
> +    pt_config_delete(s);
> +
>      /* unregister real device's MMIO/PIO BARs */
>      pt_unregister_regions(s);
>  
> diff --git a/hw/xen_pci_passthrough_config_init.c b/hw/xen_pci_passthrough_config_init.c
> index 1e9de64..ae64544 100644
> --- a/hw/xen_pci_passthrough_config_init.c
> +++ b/hw/xen_pci_passthrough_config_init.c
> @@ -1,11 +1,2142 @@
> +/*
> + * Copyright (c) 2007, Neocleus Corporation.
> + * Copyright (c) 2007, Intel Corporation.
> + *
> + * This work is licensed under the terms of the GNU GPL, version 2.  See
> + * the COPYING file in the top-level directory.
> + *
> + * Alex Novik <alex@neocleus.com>
> + * Allen Kay <allen.m.kay@intel.com>
> + * Guy Zana <guy@neocleus.com>
> + *
> + * This file implements direct PCI assignment to a HVM guest
> + */
> +
> +#include "qemu-timer.h"
> +#include "xen_backend.h"
>  #include "xen_pci_passthrough.h"
>  
> +#define PT_MERGE_VALUE(value, data, val_mask) \
> +    (((value) & (val_mask)) | ((data) & ~(val_mask)))
> +
> +#define PT_INVALID_REG          0xFFFFFFFF      /* invalid register value */
> +
> +/* prototype */
> +
> +static int pt_ptr_reg_init(XenPCIPassthroughState *s, XenPTRegInfo *reg,
> +                           uint32_t real_offset, uint32_t *data);
> +static int pt_init_pci_config(XenPCIPassthroughState *s);
> +
> +
> +/* helper */
> +
> +/* A return value of 1 means the capability should NOT be exposed to guest. */
> +static int pt_hide_dev_cap(const HostPCIDevice *d, uint8_t grp_id)
> +{
> +    switch (grp_id) {
> +    case PCI_CAP_ID_EXP:
> +        /* The PCI Express Capability Structure of the VF of Intel 82599 10GbE
> +         * Controller looks trivial, e.g., the PCI Express Capabilities
> +         * Register is 0. We should not try to expose it to guest.
> +         *
> +         * The datasheet is available at
> +         * http://download.intel.com/design/network/datashts/82599_datasheet.pdf
> +         *
> +         * See 'Table 9.7. VF PCIe Configuration Space' of the datasheet, the
> +         * PCI Express Capability Structure of the VF of Intel 82599 10GbE
> +         * Controller looks trivial, e.g., the PCI Express Capabilities
> +         * Register is 0, so the Capability Version is 0 and
> +         * pt_pcie_size_init() would fail.
> +         */
> +        if (d->vendor_id == PCI_VENDOR_ID_INTEL &&
> +            d->device_id == PCI_DEVICE_ID_INTEL_82599_VF) {
> +            return 1;
> +        }
> +        break;
> +    }
> +    return 0;
> +}
> +
> +/*   find emulate register group entry */
>  XenPTRegGroup *pt_find_reg_grp(XenPCIPassthroughState *s, uint32_t address)
>  {
> +    XenPTRegGroup *entry = NULL;
> +
> +    /* find register group entry */
> +    QLIST_FOREACH(entry, &s->reg_grp_tbl, entries) {
> +        /* check address */
> +        if ((entry->base_offset <= address)
> +            && ((entry->base_offset + entry->size) > address)) {
> +            return entry;
> +        }
> +    }
> +
> +    /* group entry not found */
>      return NULL;
>  }
>  
> +/* find emulate register entry */
>  XenPTReg *pt_find_reg(XenPTRegGroup *reg_grp, uint32_t address)
>  {
> +    XenPTReg *reg_entry = NULL;
> +    XenPTRegInfo *reg = NULL;
> +    uint32_t real_offset = 0;
> +
> +    /* find register entry */
> +    QLIST_FOREACH(reg_entry, &reg_grp->reg_tbl_list, entries) {
> +        reg = reg_entry->reg;
> +        real_offset = reg_grp->base_offset + reg->offset;
> +        /* check address */
> +        if ((real_offset <= address)
> +            && ((real_offset + reg->size) > address)) {
> +            return reg_entry;
> +        }
> +    }
> +
>      return NULL;
>  }
> +
> +/* parse BAR */
> +static PTBarFlag pt_bar_reg_parse(XenPCIPassthroughState *s, XenPTRegInfo *reg)
> +{
> +    PCIDevice *d = &s->dev;
> +    XenPTRegion *region = NULL;
> +    PCIIORegion *r;
> +    int index = 0;
> +
> +    /* check 64bit BAR */
> +    index = pt_bar_offset_to_index(reg->offset);
> +    if ((0 < index) && (index < PCI_ROM_SLOT)) {
> +        int flags = s->real_device->io_regions[index - 1].flags;

Can you put a comment explaining why you need to shift it?
I presume its b/c the ROM slot is its own variable, but it would useful
to have that explicitly stated.

> +
> +        if ((flags & IORESOURCE_MEM) && (flags & IORESOURCE_MEM_64)) {

You could collapse these two I think?
(flags & (IORESOURCE_MEM | IORESOURCE_MEM_64))

> +            region = &s->bases[index - 1];
> +            if (region->bar_flag != PT_BAR_FLAG_UPPER) {
> +                return PT_BAR_FLAG_UPPER;
> +            }
> +        }
> +    }
> +
> +    /* check unused BAR */
> +    r = &d->io_regions[index];
> +    if (r->size == 0) {
> +        return PT_BAR_FLAG_UNUSED;
> +    }
> +
> +    /* for ExpROM BAR */
> +    if (index == PCI_ROM_SLOT) {
> +        return PT_BAR_FLAG_MEM;
> +    }
> +
> +    /* check BAR I/O indicator */
> +    if (s->real_device->io_regions[index].flags & IORESOURCE_IO) {
> +        return PT_BAR_FLAG_IO;
> +    } else {
> +        return PT_BAR_FLAG_MEM;
> +    }
> +}
> +
> +
> +/****************
> + * general register functions
> + */
> +
> +/* register initialization function */
> +
> +static int pt_common_reg_init(XenPCIPassthroughState *s,
> +                              XenPTRegInfo *reg, uint32_t real_offset,
> +                              uint32_t *data)
> +{
> +    *data = reg->init_val;
> +    return 0;
> +}
> +
> +/* Read register functions */
> +
> +static int pt_byte_reg_read(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
> +                            uint8_t *value, uint8_t valid_mask)
> +{
> +    XenPTRegInfo *reg = cfg_entry->reg;
> +    uint8_t valid_emu_mask = 0;
> +
> +    /* emulate byte register */
> +    valid_emu_mask = reg->emu_mask & valid_mask;
> +    *value = PT_MERGE_VALUE(*value, cfg_entry->data, ~valid_emu_mask);
> +
> +    return 0;
> +}
> +static int pt_word_reg_read(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
> +                            uint16_t *value, uint16_t valid_mask)
> +{
> +    XenPTRegInfo *reg = cfg_entry->reg;
> +    uint16_t valid_emu_mask = 0;
> +
> +    /* emulate word register */
> +    valid_emu_mask = reg->emu_mask & valid_mask;
> +    *value = PT_MERGE_VALUE(*value, cfg_entry->data, ~valid_emu_mask);
> +
> +    return 0;
> +}
> +static int pt_long_reg_read(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
> +                            uint32_t *value, uint32_t valid_mask)
> +{
> +    XenPTRegInfo *reg = cfg_entry->reg;
> +    uint32_t valid_emu_mask = 0;
> +
> +    /* emulate long register */
> +    valid_emu_mask = reg->emu_mask & valid_mask;
> +    *value = PT_MERGE_VALUE(*value, cfg_entry->data, ~valid_emu_mask);
> +
> +   return 0;
> +}
> +
> +/* Write register functions */
> +
> +static int pt_byte_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
> +                             uint8_t *value, uint8_t dev_value,
> +                             uint8_t valid_mask)
> +{
> +    XenPTRegInfo *reg = cfg_entry->reg;
> +    uint8_t writable_mask = 0;
> +    uint8_t throughable_mask = 0;
> +
> +    /* modify emulate register */
> +    writable_mask = reg->emu_mask & ~reg->ro_mask & valid_mask;
> +    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
> +
> +    /* create value for writing to I/O device register */
> +    throughable_mask = ~reg->emu_mask & valid_mask;
> +    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
> +
> +    return 0;
> +}
> +static int pt_word_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
> +                             uint16_t *value, uint16_t dev_value,
> +                             uint16_t valid_mask)
> +{
> +    XenPTRegInfo *reg = cfg_entry->reg;
> +    uint16_t writable_mask = 0;
> +    uint16_t throughable_mask = 0;
> +
> +    /* modify emulate register */
> +    writable_mask = reg->emu_mask & ~reg->ro_mask & valid_mask;
> +    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
> +
> +    /* create value for writing to I/O device register */
> +    throughable_mask = ~reg->emu_mask & valid_mask;
> +    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
> +
> +    return 0;
> +}
> +static int pt_long_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
> +                             uint32_t *value, uint32_t dev_value,
> +                             uint32_t valid_mask)
> +{
> +    XenPTRegInfo *reg = cfg_entry->reg;
> +    uint32_t writable_mask = 0;
> +    uint32_t throughable_mask = 0;
> +
> +    /* modify emulate register */
> +    writable_mask = reg->emu_mask & ~reg->ro_mask & valid_mask;
> +    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
> +
> +    /* create value for writing to I/O device register */
> +    throughable_mask = ~reg->emu_mask & valid_mask;
> +    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
> +
> +    return 0;
> +}
> +
> +/* common restore register fonctions */
> +static int pt_byte_reg_restore(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
> +                               uint32_t real_offset, uint8_t dev_value,
> +                               uint8_t *value)
> +{
> +    XenPTRegInfo *reg = cfg_entry->reg;
> +    PCIDevice *d = &s->dev;
> +
> +    /* use I/O device register's value as restore value */
> +    *value = pci_get_byte(d->config + real_offset);
> +
> +    /* create value for restoring to I/O device register */
> +    *value = PT_MERGE_VALUE(*value, dev_value, reg->emu_mask);
> +
> +    return 0;
> +}
> +static int pt_word_reg_restore(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
> +                               uint32_t real_offset, uint16_t dev_value,
> +                               uint16_t *value)
> +{
> +    XenPTRegInfo *reg = cfg_entry->reg;
> +    PCIDevice *d = &s->dev;
> +
> +    /* use I/O device register's value as restore value */
> +    *value = pci_get_word(d->config + real_offset);
> +
> +    /* create value for restoring to I/O device register */
> +    *value = PT_MERGE_VALUE(*value, dev_value, reg->emu_mask);
> +
> +    return 0;
> +}
> +
> +
> +/* XenPTRegInfo declaration
> + * - only for emulated register (either a part or whole bit).
> + * - for passthrough register that need special behavior (like interacting with
> + *   other component), set emu_mask to all 0 and specify r/w func properly.
> + * - do NOT use ALL F for init_val, otherwise the tbl will not be registered.
> + */
> +
> +/********************
> + * Header Type0
> + */
> +
> +static int pt_vendor_reg_init(XenPCIPassthroughState *s,
> +                              XenPTRegInfo *reg, uint32_t real_offset,
> +                              uint32_t *data)
> +{
> +    *data = s->real_device->vendor_id;
> +    return 0;
> +}
> +static int pt_device_reg_init(XenPCIPassthroughState *s,
> +                              XenPTRegInfo *reg, uint32_t real_offset,
> +                              uint32_t *data)
> +{
> +    *data = s->real_device->device_id;
> +    return 0;
> +}
> +static int pt_status_reg_init(XenPCIPassthroughState *s,
> +                              XenPTRegInfo *reg, uint32_t real_offset,
> +                              uint32_t *data)
> +{
> +    XenPTRegGroup *reg_grp_entry = NULL;
> +    XenPTReg *reg_entry = NULL;
> +    uint32_t reg_field = 0;
> +
> +    /* find Header register group */
> +    reg_grp_entry = pt_find_reg_grp(s, PCI_CAPABILITY_LIST);
> +    if (reg_grp_entry) {
> +        /* find Capabilities Pointer register */
> +        reg_entry = pt_find_reg(reg_grp_entry, PCI_CAPABILITY_LIST);
> +        if (reg_entry) {
> +            /* check Capabilities Pointer register */
> +            if (reg_entry->data) {
> +                reg_field |= PCI_STATUS_CAP_LIST;
> +            } else {
> +                reg_field &= ~PCI_STATUS_CAP_LIST;
> +            }
> +        } else {
> +            xen_shutdown_fatal_error("Internal error: Couldn't find XenPTReg*"
> +                                     " for Capabilities Pointer register."
> +                                     " (%s)\n", __func__);
> +            return -1;
> +        }
> +    } else {
> +        xen_shutdown_fatal_error("Internal error: Couldn't find XenPTRegGroup"
> +                                 " for Header. (%s)\n", __func__);
> +        return -1;
> +    }
> +
> +    *data = reg_field;
> +    return 0;
> +}
> +static int pt_header_type_reg_init(XenPCIPassthroughState *s,
> +                                   XenPTRegInfo *reg, uint32_t real_offset,
> +                                   uint32_t *data)
> +{
> +    /* read PCI_HEADER_TYPE */
> +    *data = reg->init_val | 0x80;
> +    return 0;
> +}
> +
> +/* initialize Interrupt Pin register */
> +static int pt_irqpin_reg_init(XenPCIPassthroughState *s,
> +                              XenPTRegInfo *reg, uint32_t real_offset,
> +                              uint32_t *data)
> +{
> +    *data = pci_read_intx(s);
> +    return 0;
> +}
> +
> +/* Command register */
> +static int pt_cmd_reg_read(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
> +                           uint16_t *value, uint16_t valid_mask)
> +{
> +    XenPTRegInfo *reg = cfg_entry->reg;
> +    uint16_t valid_emu_mask = 0;
> +    uint16_t emu_mask = reg->emu_mask;
> +
> +    if (s->is_virtfn) {
> +        emu_mask |= PCI_COMMAND_MEMORY;
> +    }
> +
> +    /* emulate word register */
> +    valid_emu_mask = emu_mask & valid_mask;
> +    *value = PT_MERGE_VALUE(*value, cfg_entry->data, ~valid_emu_mask);
> +
> +    return 0;
> +}
> +static int pt_cmd_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
> +                            uint16_t *value, uint16_t dev_value,

So the *value here is the return value right? How about
*response ?

> +                            uint16_t valid_mask)
> +{
> +    XenPTRegInfo *reg = cfg_entry->reg;
> +    uint16_t writable_mask = 0;
> +    uint16_t throughable_mask = 0;
> +    uint16_t wr_value = *value;
> +    uint16_t emu_mask = reg->emu_mask;
> +
> +    if (s->is_virtfn) {
> +        emu_mask |= PCI_COMMAND_MEMORY;
> +    }
> +
> +    /* modify emulate register */
> +    writable_mask = ~reg->ro_mask & valid_mask;
> +    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
> +
> +    /* create value for writing to I/O device register */
> +    throughable_mask = ~emu_mask & valid_mask;

What does 'throughable' mean? Is there a better term for it?
Say filtered? emulated? cleaned?

> +
> +    if (*value & PCI_COMMAND_INTX_DISABLE) {
> +        throughable_mask |= PCI_COMMAND_INTX_DISABLE;
> +    } else {
> +        if (s->machine_irq) {
> +            throughable_mask |= PCI_COMMAND_INTX_DISABLE;
> +        }
> +    }
> +
> +    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
> +
> +    /* mapping BAR */
> +    pt_bar_mapping(s, wr_value & PCI_COMMAND_IO,
> +                   wr_value & PCI_COMMAND_MEMORY);

Ah, here we kick of the real memory mapping with the hypervisor.
You might want to expand the comment to say that.

> +
> +    return 0;
> +}
> +static int pt_cmd_reg_restore(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
> +                              uint32_t real_offset, uint16_t dev_value,
> +                              uint16_t *value)
> +{
> +    XenPTRegInfo *reg = cfg_entry->reg;
> +    PCIDevice *d = &s->dev;
> +    uint16_t restorable_mask = 0;
> +
> +    /* use I/O device register's value as restore value */
> +    *value = pci_get_word(d->config + real_offset);
> +
> +    /* create value for restoring to I/O device register

s/to/the/

> +     * but do not include Fast Back-to-Back Enable bit.
> +     */
> +    restorable_mask = reg->emu_mask & ~PCI_COMMAND_FAST_BACK;
> +    *value = PT_MERGE_VALUE(*value, dev_value, restorable_mask);
> +
> +    if (!s->machine_irq) {
> +        *value |= PCI_COMMAND_INTX_DISABLE;
> +    } else {
> +        *value &= ~PCI_COMMAND_INTX_DISABLE;
> +    }
> +
> +    return 0;
> +}
> +
> +/* BAR */
> +#define PT_BAR_MEM_RO_MASK      0x0000000F      /* BAR ReadOnly mask(Memory) */
> +#define PT_BAR_MEM_EMU_MASK     0xFFFFFFF0      /* BAR emul mask(Memory) */
> +#define PT_BAR_IO_RO_MASK       0x00000003      /* BAR ReadOnly mask(I/O) */
> +#define PT_BAR_IO_EMU_MASK      0xFFFFFFFC      /* BAR emul mask(I/O) */
> +
> +static inline uint32_t base_address_with_flags(HostPCIIORegion *hr)
> +{
> +    if ((hr->flags & PCI_BASE_ADDRESS_SPACE) == PCI_BASE_ADDRESS_SPACE_IO) {
> +        return hr->base_addr | (hr->flags & ~PCI_BASE_ADDRESS_IO_MASK);
> +    } else {
> +        return hr->base_addr | (hr->flags & ~PCI_BASE_ADDRESS_MEM_MASK);
> +    }
> +}
> +
> +static int pt_bar_reg_init(XenPCIPassthroughState *s, XenPTRegInfo *reg,
> +                           uint32_t real_offset, uint32_t *data)
> +{
> +    uint32_t reg_field = 0;
> +    int index;
> +
> +    /* get BAR index */
> +    index = pt_bar_offset_to_index(reg->offset);
> +    if (index < 0) {

Should we check for index > PCI_ROM_BASE as well?
> +        PT_ERR(&s->dev, "Internal error: Invalid BAR index [%d].\n", index);
> +        return -1;
> +    }
> +
> +    /* set initial guest physical base address to -1 */
> +    s->bases[index].e_physbase = -1;
> +
> +    /* set BAR flag */
> +    s->bases[index].bar_flag = pt_bar_reg_parse(s, reg);
> +    if (s->bases[index].bar_flag == PT_BAR_FLAG_UNUSED) {
> +        reg_field = PT_INVALID_REG;
> +    }
> +
> +    *data = reg_field;
> +    return 0;
> +}
> +static int pt_bar_reg_read(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
> +                           uint32_t *value, uint32_t valid_mask)
> +{
> +    XenPTRegInfo *reg = cfg_entry->reg;
> +    uint32_t valid_emu_mask = 0;
> +    uint32_t bar_emu_mask = 0;
> +    int index;
> +
> +    /* get BAR index */
> +    index = pt_bar_offset_to_index(reg->offset);
> +    if (index < 0) {

Should we check for index > PCI_ROM_BASE?
> +        PT_ERR(&s->dev, "Internal error: Invalid BAR index [%d].\n", index);
> +        return -1;
> +    }
> +
> +    /* use fixed-up value from kernel sysfs */
> +    *value = base_address_with_flags(&s->real_device->io_regions[index]);
> +
> +    /* set emulate mask depend on BAR flag */
> +    switch (s->bases[index].bar_flag) {
> +    case PT_BAR_FLAG_MEM:
> +        bar_emu_mask = PT_BAR_MEM_EMU_MASK;
> +        break;
> +    case PT_BAR_FLAG_IO:
> +        bar_emu_mask = PT_BAR_IO_EMU_MASK;
> +        break;
> +    case PT_BAR_FLAG_UPPER:
> +        bar_emu_mask = PT_BAR_ALLF;
> +        break;
> +    default:
> +        break;
> +    }
> +
> +    /* emulate BAR */
> +    valid_emu_mask = bar_emu_mask & valid_mask;
> +    *value = PT_MERGE_VALUE(*value, cfg_entry->data, ~valid_emu_mask);
> +
> +   return 0;
> +}
> +static int pt_bar_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
> +                            uint32_t *value, uint32_t dev_value,
> +                            uint32_t valid_mask)
> +{
> +    XenPTRegInfo *reg = cfg_entry->reg;
> +    XenPTRegGroup *reg_grp_entry = NULL;
> +    XenPTReg *reg_entry = NULL;
> +    XenPTRegion *base = NULL;
> +    PCIDevice *d = &s->dev;
> +    PCIIORegion *r;
> +    uint32_t writable_mask = 0;
> +    uint32_t throughable_mask = 0;
> +    uint32_t bar_emu_mask = 0;
> +    uint32_t bar_ro_mask = 0;
> +    uint32_t new_addr, last_addr;
> +    uint32_t prev_offset;
> +    uint32_t r_size = 0;
> +    int index = 0;
> +
> +    /* get BAR index */
> +    index = pt_bar_offset_to_index(reg->offset);
> +    if (index < 0) {
> +        PT_ERR(d, "Internal error: Invalid BAR index [%d].\n", index);
> +        return -1;
> +    }
> +
> +    r = &d->io_regions[index];
> +    base = &s->bases[index];
> +    r_size = pt_get_emul_size(base->bar_flag, r->size);
> +
> +    /* set emulate mask and read-only mask depend on BAR flag */
                                             ^^values   ^^ the

> +    switch (s->bases[index].bar_flag) {
> +    case PT_BAR_FLAG_MEM:
> +        bar_emu_mask = PT_BAR_MEM_EMU_MASK;
> +        bar_ro_mask = PT_BAR_MEM_RO_MASK | (r_size - 1);
> +        break;
> +    case PT_BAR_FLAG_IO:
> +        bar_emu_mask = PT_BAR_IO_EMU_MASK;
> +        bar_ro_mask = PT_BAR_IO_RO_MASK | (r_size - 1);
> +        break;
> +    case PT_BAR_FLAG_UPPER:
> +        bar_emu_mask = PT_BAR_ALLF;
> +        bar_ro_mask = 0;    /* all upper 32bit are R/W */
> +        break;
> +    default:
> +        break;
> +    }
> +
> +    /* modify emulate register */
> +    writable_mask = bar_emu_mask & ~bar_ro_mask & valid_mask;
> +    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
> +
> +    /* check whether we need to update the virtual region address or not */
> +    switch (s->bases[index].bar_flag) {
> +    case PT_BAR_FLAG_MEM:
> +        /* nothing to do */
> +        break;
> +    case PT_BAR_FLAG_IO:
> +        new_addr = cfg_entry->data;
> +        last_addr = new_addr + r_size - 1;
> +        /* check invalid address */
> +        if (last_addr <= new_addr || !new_addr || last_addr >= UINT16_MAX) {
> +            /* check 64K range */
> +            if ((last_addr >= UINT16_MAX) &&
> +                (cfg_entry->data != (PT_BAR_ALLF & ~bar_ro_mask))) {

You seem to be using 'PT_BAR_ALLF & ~bar_ro_mask' this function and
never actually use the bar_ro_mask by itself. Perhaps you can
(before this switch statement) do:

  bar_ro_mask = PT_BAR_ALLF & ~bar_ro_mask;


> +                PT_WARN(d, "Guest attempt to set Base Address "
> +                       "over the 64KB. (offset: 0x%02x,"
> +                       " addr: 0x%08x, size: 0x%08x)\n",
> +                       reg->offset, new_addr, r_size);
> +            }
> +            /* just remove mapping */
> +            r->addr = PCI_BAR_UNMAPPED;
> +            goto exit;
> +        }
> +        break;
> +    case PT_BAR_FLAG_UPPER:
> +        if (cfg_entry->data) {
> +            if (cfg_entry->data != (PT_BAR_ALLF & ~bar_ro_mask)) {
> +                PT_WARN(d, "Guest attempt to set high MMIO Base Address. "
> +                        "Ignore mapping. "
> +                        "(offset: 0x%02x, high address: 0x%08x)\n",
> +                        reg->offset, cfg_entry->data);
> +            }
> +            /* clear lower address */
> +            d->io_regions[index-1].addr = -1;
> +        } else {
> +            /* find lower 32bit BAR */
> +            prev_offset = (reg->offset - 4);
> +            reg_grp_entry = pt_find_reg_grp(s, prev_offset);
> +            if (reg_grp_entry) {
> +                reg_entry = pt_find_reg(reg_grp_entry, prev_offset);
> +                if (reg_entry) {
> +                    /* restore lower address */
> +                    d->io_regions[index-1].addr = reg_entry->data;
> +                } else {
> +                    return -1;
> +                }
> +            } else {
> +                return -1;
> +            }
> +        }
> +
> +        /* never mapping the 'empty' upper region,
> +         * because we'll do it enough for the lower region.

umm, not sure what you mean here. Do you mean to say:
"Do not map the 'empty' upper region b/c we do not need to.
As we only need the lower region."?


> +         */
> +        r->addr = -1;
> +        goto exit;
> +    default:
> +        break;
> +    }
> +
> +    /* update the corresponding virtual region address */
> +    /*
> +     * When guest code tries to get block size of mmio, it will write all "1"s
> +     * into pci bar register. In this case, cfg_entry->data == writable_mask.
> +     * Especially for devices with large mmio, the value of writable_mask
> +     * is likely to be a guest physical address that has been mapped to ram
> +     * rather than mmio. Remapping this value to mmio should be prevented.
> +     */
> +
> +    if (cfg_entry->data != writable_mask) {
> +        r->addr = cfg_entry->data;
> +    }
> +
> +exit:
> +    /* create value for writing to I/O device register */
> +    throughable_mask = ~bar_emu_mask & valid_mask;
> +    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
> +
> +    /* After BAR reg update, we need to remap BAR */
> +    reg_grp_entry = pt_find_reg_grp(s, PCI_COMMAND);
> +    if (reg_grp_entry) {
> +        reg_entry = pt_find_reg(reg_grp_entry, PCI_COMMAND);
> +        if (reg_entry) {
> +            pt_bar_mapping_one(s, index, reg_entry->data & PCI_COMMAND_IO,
> +                               reg_entry->data & PCI_COMMAND_MEMORY);
> +        }
> +    }
> +
> +    return 0;
> +}
> +static int pt_bar_reg_restore(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
> +                              uint32_t real_offset, uint32_t dev_value,
> +                              uint32_t *value)
> +{
> +    XenPTRegInfo *reg = cfg_entry->reg;
> +    uint32_t bar_emu_mask = 0;
> +    int index = 0;
> +
> +    /* get BAR index */
> +    index = pt_bar_offset_to_index(reg->offset);
> +    if (index < 0) {
> +        PT_ERR(&s->dev, "Internal error: Invalid BAR index [%d].\n", index);
> +        return -1;
> +    }
> +
> +    /* use value from kernel sysfs */
> +    if (s->bases[index].bar_flag == PT_BAR_FLAG_UPPER) {
> +        *value = s->real_device->io_regions[index - 1].base_addr >> 32;
> +    } else {
> +        *value = base_address_with_flags(&s->real_device->io_regions[index]);
> +    }
> +
> +    /* set emulate mask depend on BAR flag */
> +    switch (s->bases[index].bar_flag) {
> +    case PT_BAR_FLAG_MEM:
> +        bar_emu_mask = PT_BAR_MEM_EMU_MASK;
> +        break;
> +    case PT_BAR_FLAG_IO:
> +        bar_emu_mask = PT_BAR_IO_EMU_MASK;
> +        break;
> +    case PT_BAR_FLAG_UPPER:
> +        bar_emu_mask = PT_BAR_ALLF;
> +        break;
> +    default:
> +        break;
> +    }
> +
> +    /* create value for restoring to I/O device register */
> +    *value = PT_MERGE_VALUE(*value, dev_value, bar_emu_mask);
> +
> +    return 0;
> +}
> +
> +/* write Exp ROM BAR */
> +static int pt_exp_rom_bar_reg_write(XenPCIPassthroughState *s,
> +                                    XenPTReg *cfg_entry, uint32_t *value,
> +                                    uint32_t dev_value, uint32_t valid_mask)
> +{
> +    XenPTRegInfo *reg = cfg_entry->reg;
> +    XenPTRegGroup *reg_grp_entry = NULL;
> +    XenPTReg *reg_entry = NULL;
> +    XenPTRegion *base = NULL;
> +    PCIDevice *d = (PCIDevice *)&s->dev;
> +    PCIIORegion *r;
> +    uint32_t writable_mask = 0;
> +    uint32_t throughable_mask = 0;
> +    pcibus_t r_size = 0;
> +    uint32_t bar_emu_mask = 0;
> +    uint32_t bar_ro_mask = 0;
> +
> +    r = &d->io_regions[PCI_ROM_SLOT];
> +    r_size = r->size;
> +    base = &s->bases[PCI_ROM_SLOT];
> +    /* align memory type resource size */
> +    pt_get_emul_size(base->bar_flag, r_size);
> +
> +    /* set emulate mask and read-only mask */
> +    bar_emu_mask = reg->emu_mask;
> +    bar_ro_mask = (reg->ro_mask | (r_size - 1)) & ~PCI_ROM_ADDRESS_ENABLE;
> +
> +    /* modify emulate register */
> +    writable_mask = ~bar_ro_mask & valid_mask;
> +    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
> +
> +    /* update the corresponding virtual region address */
> +    /*
> +     * When guest code tries to get block size of mmio, it will write all "1"s
> +     * into pci bar register. In this case, cfg_entry->data == writable_mask.
> +     * Especially for devices with large mmio, the value of writable_mask
> +     * is likely to be a guest physical address that has been mapped to ram
> +     * rather than mmio. Remapping this value to mmio should be prevented.
> +     */
> +
> +    if (cfg_entry->data != writable_mask) {
> +        r->addr = cfg_entry->data;
> +    }
> +
> +    /* create value for writing to I/O device register */
> +    throughable_mask = ~bar_emu_mask & valid_mask;
> +    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
> +
> +    /* After BAR reg update, we need to remap BAR*/
> +    reg_grp_entry = pt_find_reg_grp(s, PCI_COMMAND);
> +    if (reg_grp_entry) {
> +        reg_entry = pt_find_reg(reg_grp_entry, PCI_COMMAND);
> +        if (reg_entry) {
> +            pt_bar_mapping_one(s, PCI_ROM_SLOT,
> +                               reg_entry->data & PCI_COMMAND_IO,
> +                               reg_entry->data & PCI_COMMAND_MEMORY);
> +        }
> +    }
> +
> +    return 0;
> +}
> +/* restore ROM BAR */
> +static int pt_exp_rom_bar_reg_restore(XenPCIPassthroughState *s,
> +                                      XenPTReg *cfg_entry,
> +                                      uint32_t real_offset,
> +                                      uint32_t dev_value, uint32_t *value)
> +{
> +    XenPTRegInfo *reg = cfg_entry->reg;
> +    uint32_t v;
> +
> +    if (host_pci_get_long(s->real_device, PCI_ROM_ADDRESS, &v)) {
> +        return -1;
> +    }
> +    /* use value from kernel sysfs */
> +    *value = PT_MERGE_VALUE(v, dev_value, reg->emu_mask);
> +    return 0;
> +}
> +
> +/* Header Type0 reg static infomation table */
> +static XenPTRegInfo pt_emu_reg_header0_tbl[] = {
> +    /* Vendor ID reg */
> +    {
> +        .offset     = PCI_VENDOR_ID,
> +        .size       = 2,
> +        .init_val   = 0x0000,
> +        .ro_mask    = 0xFFFF,
> +        .emu_mask   = 0xFFFF,
> +        .init       = pt_vendor_reg_init,
> +        .u.w.read   = pt_word_reg_read,
> +        .u.w.write  = pt_word_reg_write,
> +        .u.w.restore  = NULL,
> +    },
> +    /* Device ID reg */
> +    {
> +        .offset     = PCI_DEVICE_ID,
> +        .size       = 2,
> +        .init_val   = 0x0000,
> +        .ro_mask    = 0xFFFF,
> +        .emu_mask   = 0xFFFF,
> +        .init       = pt_device_reg_init,
> +        .u.w.read   = pt_word_reg_read,
> +        .u.w.write  = pt_word_reg_write,
> +        .u.w.restore  = NULL,
> +    },
> +    /* Command reg */
> +    {
> +        .offset     = PCI_COMMAND,
> +        .size       = 2,
> +        .init_val   = 0x0000,
> +        .ro_mask    = 0xF880,
> +        .emu_mask   = 0x0740,
> +        .init       = pt_common_reg_init,
> +        .u.w.read   = pt_cmd_reg_read,
> +        .u.w.write  = pt_cmd_reg_write,
> +        .u.w.restore  = pt_cmd_reg_restore,
> +    },
> +    /* Capabilities Pointer reg */
> +    {
> +        .offset     = PCI_CAPABILITY_LIST,
> +        .size       = 1,
> +        .init_val   = 0x00,
> +        .ro_mask    = 0xFF,
> +        .emu_mask   = 0xFF,
> +        .init       = pt_ptr_reg_init,
> +        .u.b.read   = pt_byte_reg_read,
> +        .u.b.write  = pt_byte_reg_write,
> +        .u.b.restore  = NULL,
> +    },
> +    /* Status reg */
> +    /* use emulated Cap Ptr value to initialize,
> +     * so need to be declared after Cap Ptr reg
> +     */
> +    {
> +        .offset     = PCI_STATUS,
> +        .size       = 2,
> +        .init_val   = 0x0000,
> +        .ro_mask    = 0x06FF,
> +        .emu_mask   = 0x0010,
> +        .init       = pt_status_reg_init,
> +        .u.w.read   = pt_word_reg_read,
> +        .u.w.write  = pt_word_reg_write,
> +        .u.w.restore  = NULL,
> +    },
> +    /* Cache Line Size reg */
> +    {
> +        .offset     = PCI_CACHE_LINE_SIZE,
> +        .size       = 1,
> +        .init_val   = 0x00,
> +        .ro_mask    = 0x00,
> +        .emu_mask   = 0xFF,
> +        .init       = pt_common_reg_init,
> +        .u.b.read   = pt_byte_reg_read,
> +        .u.b.write  = pt_byte_reg_write,
> +        .u.b.restore  = pt_byte_reg_restore,
> +    },
> +    /* Latency Timer reg */
> +    {
> +        .offset     = PCI_LATENCY_TIMER,
> +        .size       = 1,
> +        .init_val   = 0x00,
> +        .ro_mask    = 0x00,
> +        .emu_mask   = 0xFF,
> +        .init       = pt_common_reg_init,
> +        .u.b.read   = pt_byte_reg_read,
> +        .u.b.write  = pt_byte_reg_write,
> +        .u.b.restore  = pt_byte_reg_restore,
> +    },
> +    /* Header Type reg */
> +    {
> +        .offset     = PCI_HEADER_TYPE,
> +        .size       = 1,
> +        .init_val   = 0x00,
> +        .ro_mask    = 0xFF,
> +        .emu_mask   = 0x00,
> +        .init       = pt_header_type_reg_init,
> +        .u.b.read   = pt_byte_reg_read,
> +        .u.b.write  = pt_byte_reg_write,
> +        .u.b.restore  = NULL,
> +    },
> +    /* Interrupt Line reg */
> +    {
> +        .offset     = PCI_INTERRUPT_LINE,
> +        .size       = 1,
> +        .init_val   = 0x00,
> +        .ro_mask    = 0x00,
> +        .emu_mask   = 0xFF,
> +        .init       = pt_common_reg_init,
> +        .u.b.read   = pt_byte_reg_read,
> +        .u.b.write  = pt_byte_reg_write,
> +        .u.b.restore  = NULL,
> +    },
> +    /* Interrupt Pin reg */
> +    {
> +        .offset     = PCI_INTERRUPT_PIN,
> +        .size       = 1,
> +        .init_val   = 0x00,
> +        .ro_mask    = 0xFF,
> +        .emu_mask   = 0xFF,
> +        .init       = pt_irqpin_reg_init,
> +        .u.b.read   = pt_byte_reg_read,
> +        .u.b.write  = pt_byte_reg_write,
> +        .u.b.restore  = NULL,
> +    },
> +    /* BAR 0 reg */
> +    /* mask of BAR need to be decided later, depends on IO/MEM type */
> +    {
> +        .offset     = PCI_BASE_ADDRESS_0,
> +        .size       = 4,
> +        .init_val   = 0x00000000,
> +        .init       = pt_bar_reg_init,
> +        .u.dw.read  = pt_bar_reg_read,
> +        .u.dw.write = pt_bar_reg_write,
> +        .u.dw.restore = pt_bar_reg_restore,
> +    },
> +    /* BAR 1 reg */
> +    {
> +        .offset     = PCI_BASE_ADDRESS_1,
> +        .size       = 4,
> +        .init_val   = 0x00000000,
> +        .init       = pt_bar_reg_init,
> +        .u.dw.read  = pt_bar_reg_read,
> +        .u.dw.write = pt_bar_reg_write,
> +        .u.dw.restore = pt_bar_reg_restore,
> +    },
> +    /* BAR 2 reg */
> +    {
> +        .offset     = PCI_BASE_ADDRESS_2,
> +        .size       = 4,
> +        .init_val   = 0x00000000,
> +        .init       = pt_bar_reg_init,
> +        .u.dw.read  = pt_bar_reg_read,
> +        .u.dw.write = pt_bar_reg_write,
> +        .u.dw.restore = pt_bar_reg_restore,
> +    },
> +    /* BAR 3 reg */
> +    {
> +        .offset     = PCI_BASE_ADDRESS_3,
> +        .size       = 4,
> +        .init_val   = 0x00000000,
> +        .init       = pt_bar_reg_init,
> +        .u.dw.read  = pt_bar_reg_read,
> +        .u.dw.write = pt_bar_reg_write,
> +        .u.dw.restore = pt_bar_reg_restore,
> +    },
> +    /* BAR 4 reg */
> +    {
> +        .offset     = PCI_BASE_ADDRESS_4,
> +        .size       = 4,
> +        .init_val   = 0x00000000,
> +        .init       = pt_bar_reg_init,
> +        .u.dw.read  = pt_bar_reg_read,
> +        .u.dw.write = pt_bar_reg_write,
> +        .u.dw.restore = pt_bar_reg_restore,
> +    },
> +    /* BAR 5 reg */
> +    {
> +        .offset     = PCI_BASE_ADDRESS_5,
> +        .size       = 4,
> +        .init_val   = 0x00000000,
> +        .init       = pt_bar_reg_init,
> +        .u.dw.read  = pt_bar_reg_read,
> +        .u.dw.write = pt_bar_reg_write,
> +        .u.dw.restore = pt_bar_reg_restore,
> +    },
> +    /* Expansion ROM BAR reg */
> +    {
> +        .offset     = PCI_ROM_ADDRESS,
> +        .size       = 4,
> +        .init_val   = 0x00000000,
> +        .ro_mask    = 0x000007FE,
> +        .emu_mask   = 0xFFFFF800,
> +        .init       = pt_bar_reg_init,
> +        .u.dw.read  = pt_long_reg_read,
> +        .u.dw.write = pt_exp_rom_bar_reg_write,
> +        .u.dw.restore = pt_exp_rom_bar_reg_restore,
> +    },
> +    {
> +        .size = 0,
> +    },
> +};
> +
> +
> +/*********************************
> + * Vital Product Data Capability
> + */
> +
> +/* Vital Product Data Capability Structure reg static infomation table */
> +static XenPTRegInfo pt_emu_reg_vpd_tbl[] = {
> +    {
> +        .offset     = PCI_CAP_LIST_NEXT,
> +        .size       = 1,
> +        .init_val   = 0x00,
> +        .ro_mask    = 0xFF,
> +        .emu_mask   = 0xFF,
> +        .init       = pt_ptr_reg_init,
> +        .u.b.read   = pt_byte_reg_read,
> +        .u.b.write  = pt_byte_reg_write,
> +        .u.b.restore  = NULL,
> +    },
> +    {
> +        .size = 0,
> +    },
> +};
> +
> +
> +/**************************************
> + * Vendor Specific Capability
> + */
> +
> +/* Vendor Specific Capability Structure reg static infomation table */
> +static XenPTRegInfo pt_emu_reg_vendor_tbl[] = {
> +    {
> +        .offset     = PCI_CAP_LIST_NEXT,
> +        .size       = 1,
> +        .init_val   = 0x00,
> +        .ro_mask    = 0xFF,
> +        .emu_mask   = 0xFF,
> +        .init       = pt_ptr_reg_init,
> +        .u.b.read   = pt_byte_reg_read,
> +        .u.b.write  = pt_byte_reg_write,
> +        .u.b.restore  = NULL,
> +    },
> +    {
> +        .size = 0,
> +    },
> +};
> +
> +
> +/*****************************
> + * PCI Express Capability
> + */
> +
> +/* initialize Link Control register */
> +static int pt_linkctrl_reg_init(XenPCIPassthroughState *s,
> +                                XenPTRegInfo *reg, uint32_t real_offset,
> +                                uint32_t *data)
> +{
> +    uint8_t cap_ver = 0;
> +    uint8_t dev_type = 0;
> +
> +    cap_ver = pci_get_byte(s->dev.config + real_offset - reg->offset
> +                           + PCI_EXP_FLAGS)
> +        & PCI_EXP_FLAGS_VERS;

Hmm. Weird tabbing? Or maybe it is my mailer?

> +    dev_type = (pci_get_byte(s->dev.config + real_offset - reg->offset
> +                             + PCI_EXP_FLAGS)
> +                & PCI_EXP_FLAGS_TYPE) >> 4;

Here it looks better.. but still not sure about the "+ PCI_EXP_FLAGS"?

> +
> +    /* no need to initialize in case of Root Complex Integrated Endpoint
> +     * with cap_ver 1.x
> +     */
> +    if ((dev_type == PCI_EXP_TYPE_RC_END) && (cap_ver == 1)) {
> +        *data = PT_INVALID_REG;
> +    }
> +
> +    *data = reg->init_val;
> +    return 0;
> +}
> +/* initialize Device Control 2 register */
> +static int pt_devctrl2_reg_init(XenPCIPassthroughState *s,
> +                                XenPTRegInfo *reg, uint32_t real_offset,
> +                                uint32_t *data)
> +{
> +    uint8_t cap_ver = 0;
> +
> +    cap_ver = pci_get_byte(s->dev.config + real_offset - reg->offset
> +                           + PCI_EXP_FLAGS)
> +        & PCI_EXP_FLAGS_VERS;

Tab-mayhem!

> +
> +    /* no need to initialize in case of cap_ver 1.x */
> +    if (cap_ver == 1) {
> +        *data = PT_INVALID_REG;
> +    }
> +
> +    *data = reg->init_val;
> +    return 0;
> +}
> +/* initialize Link Control 2 register */
> +static int pt_linkctrl2_reg_init(XenPCIPassthroughState *s,
> +                                 XenPTRegInfo *reg, uint32_t real_offset,
> +                                 uint32_t *data)
> +{
> +    uint32_t reg_field = 0;
> +    uint8_t cap_ver = 0;
> +
> +    cap_ver = pci_get_byte(s->dev.config + real_offset - reg->offset
> +                           + PCI_EXP_FLAGS)
> +        & PCI_EXP_FLAGS_VERS;

.. strikes again!

> +
> +    /* no need to initialize in case of cap_ver 1.x */
> +    if (cap_ver == 1) {
> +        reg_field = PT_INVALID_REG;
> +    } else {
> +        /* set Supported Link Speed */
> +        uint8_t lnkcap = pci_get_byte(s->dev.config + real_offset - reg->offset
> +                                      + PCI_EXP_LNKCAP);
> +        reg_field |= PCI_EXP_LNKCAP_SLS & lnkcap;
> +    }
> +
> +    *data = reg_field;
> +    return 0;
> +}
> +
> +/* PCI Express Capability Structure reg static infomation table */
> +static XenPTRegInfo pt_emu_reg_pcie_tbl[] = {
> +    /* Next Pointer reg */
> +    {
> +        .offset     = PCI_CAP_LIST_NEXT,
> +        .size       = 1,
> +        .init_val   = 0x00,
> +        .ro_mask    = 0xFF,
> +        .emu_mask   = 0xFF,
> +        .init       = pt_ptr_reg_init,
> +        .u.b.read   = pt_byte_reg_read,
> +        .u.b.write  = pt_byte_reg_write,
> +        .u.b.restore  = NULL,
> +    },
> +    /* Device Capabilities reg */
> +    {
> +        .offset     = PCI_EXP_DEVCAP,
> +        .size       = 4,
> +        .init_val   = 0x00000000,
> +        .ro_mask    = 0x1FFCFFFF,
> +        .emu_mask   = 0x10000000,
> +        .init       = pt_common_reg_init,
> +        .u.dw.read  = pt_long_reg_read,
> +        .u.dw.write = pt_long_reg_write,
> +        .u.dw.restore = NULL,
> +    },
> +    /* Device Control reg */
> +    {
> +        .offset     = PCI_EXP_DEVCTL,
> +        .size       = 2,
> +        .init_val   = 0x2810,
> +        .ro_mask    = 0x8400,
> +        .emu_mask   = 0xFFFF,
> +        .init       = pt_common_reg_init,
> +        .u.w.read   = pt_word_reg_read,
> +        .u.w.write  = pt_word_reg_write,
> +        .u.w.restore  = pt_word_reg_restore,
> +    },
> +    /* Link Control reg */
> +    {
> +        .offset     = PCI_EXP_LNKCTL,
> +        .size       = 2,
> +        .init_val   = 0x0000,
> +        .ro_mask    = 0xFC34,
> +        .emu_mask   = 0xFFFF,
> +        .init       = pt_linkctrl_reg_init,
> +        .u.w.read   = pt_word_reg_read,
> +        .u.w.write  = pt_word_reg_write,
> +        .u.w.restore  = pt_word_reg_restore,
> +    },
> +    /* Device Control 2 reg */
> +    {
> +        .offset     = 0x28,
> +        .size       = 2,
> +        .init_val   = 0x0000,
> +        .ro_mask    = 0xFFE0,
> +        .emu_mask   = 0xFFFF,
> +        .init       = pt_devctrl2_reg_init,
> +        .u.w.read   = pt_word_reg_read,
> +        .u.w.write  = pt_word_reg_write,
> +        .u.w.restore  = pt_word_reg_restore,
> +    },
> +    /* Link Control 2 reg */
> +    {
> +        .offset     = 0x30,
> +        .size       = 2,
> +        .init_val   = 0x0000,
> +        .ro_mask    = 0xE040,
> +        .emu_mask   = 0xFFFF,
> +        .init       = pt_linkctrl2_reg_init,
> +        .u.w.read   = pt_word_reg_read,
> +        .u.w.write  = pt_word_reg_write,
> +        .u.w.restore  = pt_word_reg_restore,
> +    },
> +    {
> +        .size = 0,
> +    },
> +};
> +
> +
> +/*********************************
> + * Power Management Capability
> + */
> +
> +/* initialize Power Management Capabilities register */
> +static int pt_pmc_reg_init(XenPCIPassthroughState *s,
> +                           XenPTRegInfo *reg, uint32_t real_offset,
> +                           uint32_t *data)
> +{
> +    PCIDevice *d = &s->dev;
> +
> +    if (s->power_mgmt) {
> +        /* set Power Management Capabilities register */
> +        s->pm_state->pmc_field = pci_get_word(d->config + real_offset);
> +    }
> +
> +    *data = reg->init_val;
> +    return 0;
> +}
> +/* initialize PCI Power Management Control/Status register */
> +static int pt_pmcsr_reg_init(XenPCIPassthroughState *s,
> +                             XenPTRegInfo *reg, uint32_t real_offset,
> +                             uint32_t *data)
> +{
> +    PCIDevice *d = &s->dev;
> +    uint16_t cap_ver  = 0;
> +    uint16_t v = 0;
> +
> +    if (!s->power_mgmt) {
> +        *data = reg->init_val;
> +        return 0;
> +    }
> +
> +    /* check PCI Power Management support version */
> +    cap_ver = s->pm_state->pmc_field & PCI_PM_CAP_VER_MASK;
> +
> +    if (cap_ver > 2) {
> +        /* set No Soft Reset */
> +        s->pm_state->no_soft_reset =
> +            pci_get_byte(d->config + real_offset) & PCI_PM_CTRL_NO_SOFT_RESET;
> +    }
> +
> +    host_pci_get_word(s->real_device, real_offset, &v);
> +    /* wake up real physical device */
> +    switch (v & PCI_PM_CTRL_STATE_MASK) {
> +    case 0:
> +        break;
> +    case 1:
> +        PT_LOG(d, "Power state transition D1 -> D0active\n");
> +        host_pci_set_word(s->real_device, real_offset, 0);
> +        break;
> +    case 2:
> +        PT_LOG(d, "Power state transition D2 -> D0active\n");
> +        host_pci_set_word(s->real_device, real_offset, 0);
> +        usleep(200);
> +        break;
> +    case 3:
> +        PT_LOG(d, "Power state transition D3hot -> D0active\n");
> +        host_pci_set_word(s->real_device, real_offset, 0);
> +        usleep(10 * 1000);
> +        if (pt_init_pci_config(s)) {
> +            return -1;
> +        }
> +        break;
> +    }
> +
> +    *data = reg->init_val;
> +    return 0;
> +}
> +/* read Power Management Control/Status register */
> +static int pt_pmcsr_reg_read(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
> +                             uint16_t *value, uint16_t valid_mask)
> +{
> +    XenPTRegInfo *reg = cfg_entry->reg;
> +    uint16_t valid_emu_mask = reg->emu_mask;
> +
> +    if (!s->power_mgmt) {
> +        valid_emu_mask |= PCI_PM_CTRL_STATE_MASK | PCI_PM_CTRL_NO_SOFT_RESET;
> +    }
> +
> +    valid_emu_mask = valid_emu_mask & valid_mask;
> +    *value = PT_MERGE_VALUE(*value, cfg_entry->data, ~valid_emu_mask);
> +
> +    return 0;
> +}
> +/* reset Interrupt and I/O resource  */
> +static void pt_reset_interrupt_and_io_mapping(XenPCIPassthroughState *s)
> +{
> +    PCIDevice *d = &s->dev;
> +    PCIIORegion *r;
> +    int i = 0;
> +    uint8_t e_device = 0;
> +    uint8_t e_intx = 0;
> +
> +    /* unbind INTx */
> +    e_device = PCI_SLOT(s->dev.devfn);
> +    e_intx = pci_intx(s);
> +
> +    if (s->machine_irq) {
> +        if (xc_domain_unbind_pt_irq(xen_xc, xen_domid, s->machine_irq,
> +                                    PT_IRQ_TYPE_PCI, 0, e_device, e_intx, 0)) {
> +            PT_ERR(d, "Unbinding of interrupt failed!\n");
> +        }
> +    }
> +
> +    /* clear all virtual region address */
> +    for (i = 0; i < PCI_NUM_REGIONS; i++) {
> +        r = &d->io_regions[i];
> +        r->addr = -1;
> +    }
> +
> +    /* unmapping BAR */
> +    pt_bar_mapping(s, 0, 0);
> +}
> +/* check power state transition */
> +static int check_power_state(XenPCIPassthroughState *s)
> +{
> +    XenPTPM *pm_state = s->pm_state;
> +    PCIDevice *d = &s->dev;
> +    uint16_t read_val = 0;
> +    uint16_t cur_state = 0;
> +
> +    /* get current power state */
> +    if (host_pci_get_word(s->real_device, pm_state->pm_base + PCI_PM_CTRL,
> +                          &read_val)) {
> +        return -1;
> +    }
> +    cur_state = read_val & PCI_PM_CTRL_STATE_MASK;
> +
> +    if (pm_state->req_state != cur_state) {
> +        PT_ERR(d, "Failed to change power state. "
> +               "(requested state: %d, current state: %d)\n",
> +               pm_state->req_state, cur_state);
> +        return -1;
> +    }
> +    return 0;
> +}
> +/* write Power Management Control/Status register */
> +static void pt_from_d3hot_to_d0_with_reset(void *opaque)
> +{
> +    XenPCIPassthroughState *s = opaque;
> +    XenPTPM *pm_state = s->pm_state;
> +    int ret = 0;
> +
> +    /* check power state */
> +    ret = check_power_state(s);
> +
> +    if (ret < 0) {
> +        goto out;
> +    }
> +
> +    pt_init_pci_config(s);
> +
> +out:
> +    /* power state transition flags off */
> +    pm_state->flags &= ~PT_FLAG_TRANSITING;
> +
> +    qemu_free_timer(pm_state->pm_timer);
> +    pm_state->pm_timer = NULL;
> +}
> +static void pt_default_power_transition(void *opaque)
> +{
> +    XenPCIPassthroughState *ptdev = opaque;
> +    XenPTPM *pm_state = ptdev->pm_state;
> +
> +    /* check power state */
> +    check_power_state(ptdev);
> +
> +    /* power state transition flags off */
> +    pm_state->flags &= ~PT_FLAG_TRANSITING;
> +
> +    qemu_free_timer(pm_state->pm_timer);
> +    pm_state->pm_timer = NULL;
> +}
> +static int pt_pmcsr_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
> +                              uint16_t *value, uint16_t dev_value,
> +                              uint16_t valid_mask)
> +{
> +    XenPTRegInfo *reg = cfg_entry->reg;
> +    PCIDevice *d = &s->dev;
> +    uint16_t emu_mask = reg->emu_mask;
> +    uint16_t writable_mask = 0;
> +    uint16_t throughable_mask = 0;
> +    XenPTPM *pm_state = s->pm_state;
> +
> +    if (!s->power_mgmt) {
> +        emu_mask |= PCI_PM_CTRL_STATE_MASK | PCI_PM_CTRL_NO_SOFT_RESET;
> +    }
> +
> +    /* modify emulate register */
> +    writable_mask = emu_mask & ~reg->ro_mask & valid_mask;
> +    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
> +
> +    /* create value for writing to I/O device register */
> +    throughable_mask = ~emu_mask & valid_mask;
> +    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
> +
> +    if (!s->power_mgmt) {
> +        return 0;
> +    }
> +
> +    /* set I/O device power state */
> +    pm_state->cur_state = dev_value & PCI_PM_CTRL_STATE_MASK;
> +
> +    /* set Guest requested PowerState */
> +    pm_state->req_state = *value & PCI_PM_CTRL_STATE_MASK;
> +
> +    /* check power state transition or not */
> +    if (pm_state->cur_state == pm_state->req_state) {
> +        /* not power state transition */

.. No power state transition.

> +        return 0;
> +    }
> +
> +    /* check enable power state transition */
> +    if ((pm_state->req_state != 0) &&
> +        (pm_state->cur_state > pm_state->req_state)) {
> +        PT_ERR(d, "Invalid power transition. "
> +               "(requested state: %d, current state: %d)\n",
> +               pm_state->req_state, pm_state->cur_state);
> +
> +        return 0;
> +    }
> +
> +    /* check if this device supports the requested power state */
> +    if (((pm_state->req_state == 1) && !(pm_state->pmc_field & PCI_PM_CAP_D1))
> +        || ((pm_state->req_state == 2) &&
> +            !(pm_state->pmc_field & PCI_PM_CAP_D2))) {
> +        PT_ERR(d, "Invalid power transition. "
> +               "(requested state: %d, current state: %d)\n",
> +               pm_state->req_state, pm_state->cur_state);
> +
> +        return 0;
> +    }
> +
> +    /* in case of transition related to D3hot, it's necessary to wait 10 ms.
> +     * But because writing to register will be performed later on actually,

'performed later on,'
> +     * don't start QEMUTimer right now, just alloc and init QEMUTimer here.

You might want to say where it will be started.

> +     */
> +    if ((pm_state->cur_state == 3) || (pm_state->req_state == 3)) {
> +        if (pm_state->req_state == 0) {
> +            /* alloc and init QEMUTimer */
> +            if (!pm_state->no_soft_reset) {
> +                pm_state->pm_timer = qemu_new_timer_ms(rt_clock,
> +                    pt_from_d3hot_to_d0_with_reset, s);
> +
> +                /* reset Interrupt and I/O resource mapping */
> +                pt_reset_interrupt_and_io_mapping(s);
> +            } else {
> +                pm_state->pm_timer = qemu_new_timer_ms(rt_clock,
> +                                        pt_default_power_transition, s);
> +            }
> +        } else {
> +            /* alloc and init QEMUTimer */
> +            pm_state->pm_timer = qemu_new_timer_ms(rt_clock,
> +                pt_default_power_transition, s);
> +        }
> +
> +        /* set power state transition delay */
> +        pm_state->pm_delay = 10;
> +
> +        /* power state transition flags on */
> +        pm_state->flags |= PT_FLAG_TRANSITING;
> +    }
> +    /* in case of transition related to D0, D1 and D2,
> +     * no need to use QEMUTimer.
> +     * So, we perfom writing to register here and then read it back.
> +     */
> +    else {
> +        /* write power state to I/O device register */
> +        host_pci_set_word(s->real_device, pm_state->pm_base + PCI_PM_CTRL,
> +                          *value);
> +
> +        /* in case of transition related to D2,
> +         * it's necessary to wait 200 usec.
> +         * But because QEMUTimer do not support microsec unit right now,
> +         * so we do wait ourself here.

'.. QEMUTimer does not support microsec resolution, we will wait here.'

> +         */
> +        if ((pm_state->cur_state == 2) || (pm_state->req_state == 2)) {
> +            usleep(200);
> +        }
> +
> +        /* check power state */
> +        check_power_state(s);
> +
> +        /* recreate value for writing to I/O device register */
> +        if (host_pci_get_word(s->real_device, pm_state->pm_base + PCI_PM_CTRL,
> +                              value)) {
> +            return -1;
> +        }
> +    }
> +
> +    return 0;
> +}
> +
> +/* restore Power Management Control/Status register */
> +static int pt_pmcsr_reg_restore(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
> +                                uint32_t real_offset, uint16_t dev_value,
> +                                uint16_t *value)
> +{
> +    /* create value for restoring to I/O device register
> +     * No need to restore, just clear PME Enable and PME Status bit
> +     * Note: register type of PME Status bit is RW1C, so clear by writing 1b
> +     */
> +    *value = (dev_value & ~PCI_PM_CTRL_PME_ENABLE) | PCI_PM_CTRL_PME_STATUS;
> +
> +    return 0;
> +}
> +
> +
> +/* Power Management Capability reg static infomation table */
> +static XenPTRegInfo pt_emu_reg_pm_tbl[] = {
> +    /* Next Pointer reg */
> +    {
> +        .offset     = PCI_CAP_LIST_NEXT,
> +        .size       = 1,
> +        .init_val   = 0x00,
> +        .ro_mask    = 0xFF,
> +        .emu_mask   = 0xFF,
> +        .init       = pt_ptr_reg_init,
> +        .u.b.read   = pt_byte_reg_read,
> +        .u.b.write  = pt_byte_reg_write,
> +        .u.b.restore  = NULL,
> +    },
> +    /* Power Management Capabilities reg */
> +    {
> +        .offset     = PCI_CAP_FLAGS,
> +        .size       = 2,
> +        .init_val   = 0x0000,
> +        .ro_mask    = 0xFFFF,
> +        .emu_mask   = 0xF9C8,
> +        .init       = pt_pmc_reg_init,
> +        .u.w.read   = pt_word_reg_read,
> +        .u.w.write  = pt_word_reg_write,
> +        .u.w.restore  = NULL,
> +    },
> +    /* PCI Power Management Control/Status reg */
> +    {
> +        .offset     = PCI_PM_CTRL,
> +        .size       = 2,
> +        .init_val   = 0x0008,
> +        .ro_mask    = 0xE1FC,
> +        .emu_mask   = 0x8100,
> +        .init       = pt_pmcsr_reg_init,
> +        .u.w.read   = pt_pmcsr_reg_read,
> +        .u.w.write  = pt_pmcsr_reg_write,
> +        .u.w.restore  = pt_pmcsr_reg_restore,
> +    },
> +    {
> +        .size = 0,
> +    },
> +};
> +
> +
> +/****************************
> + * Capabilities
> + */
> +
> +/* AER register operations */
> +
> +static void aer_save_one_register(XenPCIPassthroughState *s, int offset)
> +{
> +    PCIDevice *d = &s->dev;
> +    uint32_t aer_base = s->pm_state->aer_base;
> +    uint32_t val = 0;
> +
> +    if (host_pci_get_long(s->real_device, aer_base + offset, &val)) {
> +        return;
> +    }
> +    pci_set_long(d->config + aer_base + offset, val);
> +}
> +static void pt_aer_reg_save(XenPCIPassthroughState *s)
> +{
> +    /* after reset, following register values should be restored.
> +     * So, save them.
> +     */
> +    aer_save_one_register(s, PCI_ERR_UNCOR_MASK);
> +    aer_save_one_register(s, PCI_ERR_UNCOR_SEVER);
> +    aer_save_one_register(s, PCI_ERR_COR_MASK);
> +    aer_save_one_register(s, PCI_ERR_CAP);
> +}
> +static void aer_restore_one_register(XenPCIPassthroughState *s, int offset)
> +{
> +    PCIDevice *d = &s->dev;
> +    uint32_t aer_base = s->pm_state->aer_base;
> +    uint32_t config = 0;
> +
> +    config = pci_get_long(d->config + aer_base + offset);
> +    host_pci_set_long(s->real_device, aer_base + offset, config);
> +}
> +static void pt_aer_reg_restore(XenPCIPassthroughState *s)
> +{
> +    /* the following registers should be reconfigured to correct values

the -> The
> +     * after reset. restore them.

reset. -> reset, hence
> +     * other registers should not be reconfigured after reset

'Other'

> +     * if there is no reason

So what are the other registers? Every other register _but_ the
ones that are enumerated here? If so, please state that explicitly.

> +     */
> +    aer_restore_one_register(s, PCI_ERR_UNCOR_MASK);
> +    aer_restore_one_register(s, PCI_ERR_UNCOR_SEVER);
> +    aer_restore_one_register(s, PCI_ERR_COR_MASK);
> +    aer_restore_one_register(s, PCI_ERR_CAP);
> +}
> +
> +/* capability structure register group size functions */
> +
> +static int pt_reg_grp_size_init(XenPCIPassthroughState *s,
> +                                const XenPTRegGroupInfo *grp_reg,
> +                                uint32_t base_offset, uint8_t *size)
> +{
> +    *size = grp_reg->grp_size;
> +    return 0;
> +}
> +/* get Power Management Capability Structure register group size */
> +static int pt_pm_size_init(XenPCIPassthroughState *s,
> +                           const XenPTRegGroupInfo *grp_reg,
> +                           uint32_t base_offset, uint8_t *size)
> +{
> +    *size = grp_reg->grp_size;
> +
> +    if (!s->power_mgmt) {
> +        return 0;
> +    }
> +
> +    s->pm_state = g_new0(XenPTPM, 1);
> +
> +    /* set Power Management Capability base offset */
> +    s->pm_state->pm_base = base_offset;
> +
> +    /* find AER register and set AER Capability base offset */
> +    s->pm_state->aer_base = host_pci_find_ext_cap_offset(s->real_device,
> +                                                         PCI_EXT_CAP_ID_ERR);
> +
> +    /* save AER register */
> +    if (s->pm_state->aer_base) {
> +        pt_aer_reg_save(s);
> +    }
> +
> +    return 0;
> +}
> +/* get Vendor Specific Capability Structure register group size */
> +static int pt_vendor_size_init(XenPCIPassthroughState *s,
> +                               const XenPTRegGroupInfo *grp_reg,
> +                               uint32_t base_offset, uint8_t *size)
> +{
> +    *size = pci_get_byte(s->dev.config + base_offset + 0x02);
> +    return 0;
> +}
> +/* get PCI Express Capability Structure register group size */
> +static int pt_pcie_size_init(XenPCIPassthroughState *s,
> +                             const XenPTRegGroupInfo *grp_reg,
> +                             uint32_t base_offset, uint8_t *size)
> +{
> +    PCIDevice *d = &s->dev;
> +    uint16_t exp_flag = 0;
> +    uint16_t type = 0;
> +    uint16_t version = 0;
> +    uint8_t pcie_size = 0;
> +
> +    exp_flag = pci_get_word(d->config + base_offset + PCI_EXP_FLAGS);
> +    type = (exp_flag & PCI_EXP_FLAGS_TYPE) >> 4;
> +    version = exp_flag & PCI_EXP_FLAGS_VERS;
> +
> +    /* calculate size depend on capability version and device/port type */
> +    /* in case of PCI Express Base Specification Rev 1.x */
> +    if (version == 1) {
> +        /* The PCI Express Capabilities, Device Capabilities, and Device
> +         * Status/Control registers are required for all PCI Express devices.
> +         * The Link Capabilities and Link Status/Control are required for all
> +         * Endpoints that are not Root Complex Integrated Endpoints. Endpoints
> +         * are not required to implement registers other than those listed
> +         * above and terminate the capability structure.
> +         */
> +        switch (type) {
> +        case PCI_EXP_TYPE_ENDPOINT:
> +        case PCI_EXP_TYPE_LEG_END:
> +            pcie_size = 0x14;
> +            break;
> +        case PCI_EXP_TYPE_RC_END:
> +            /* has no link */
> +            pcie_size = 0x0C;
> +            break;
> +        /* only EndPoint passthrough is supported */
> +        case PCI_EXP_TYPE_ROOT_PORT:
> +        case PCI_EXP_TYPE_UPSTREAM:
> +        case PCI_EXP_TYPE_DOWNSTREAM:
> +        case PCI_EXP_TYPE_PCI_BRIDGE:
> +        case PCI_EXP_TYPE_PCIE_BRIDGE:
> +        case PCI_EXP_TYPE_RC_EC:
> +        default:
> +            PT_ERR(d, "Internal error: Unsupported device/port type (%d).\n",
> +                   type);
> +            return -1;
> +        }
> +    }
> +    /* in case of PCI Express Base Specification Rev 2.0 */
> +    else if (version == 2) {
> +        switch (type) {
> +        case PCI_EXP_TYPE_ENDPOINT:
> +        case PCI_EXP_TYPE_LEG_END:
> +        case PCI_EXP_TYPE_RC_END:
> +            /* For Functions that do not implement the registers,
> +             * these spaces must be hardwired to 0b.

So this comment applies to the functions below the 'break' right?
Should you move it? But that doesn't make sense - we end up hitting
return -1 so it bails out and does not return 0b. Hmmm.. So what is
this comment referring to?

> +             */
> +            pcie_size = 0x3C;
> +            break;
> +        /* only EndPoint passthrough is supported */
> +        case PCI_EXP_TYPE_ROOT_PORT:
> +        case PCI_EXP_TYPE_UPSTREAM:
> +        case PCI_EXP_TYPE_DOWNSTREAM:
> +        case PCI_EXP_TYPE_PCI_BRIDGE:
> +        case PCI_EXP_TYPE_PCIE_BRIDGE:
> +        case PCI_EXP_TYPE_RC_EC:
> +        default:
> +            PT_ERR(d, "Internal error: Unsupported device/port type (%d).\n",
> +                   type);
> +            return -1;
> +        }
> +    } else {
> +        PT_ERR(d, "Internal error: Unsupported capability version (%d).\n",
> +               version);
> +        return -1;
> +    }
> +
> +    *size = pcie_size;
> +    return 0;
> +}
> +
> +static const XenPTRegGroupInfo pt_emu_reg_grp_tbl[] = {
> +    /* Header Type0 reg group */
> +    {
> +        .grp_id      = 0xFF,
> +        .grp_type    = GRP_TYPE_EMU,
> +        .grp_size    = 0x40,
> +        .size_init   = pt_reg_grp_size_init,
> +        .emu_reg_tbl = pt_emu_reg_header0_tbl,
> +    },
> +    /* PCI PowerManagement Capability reg group */
> +    {
> +        .grp_id      = PCI_CAP_ID_PM,
> +        .grp_type    = GRP_TYPE_EMU,
> +        .grp_size    = PCI_PM_SIZEOF,
> +        .size_init   = pt_pm_size_init,
> +        .emu_reg_tbl = pt_emu_reg_pm_tbl,
> +    },
> +    /* AGP Capability Structure reg group */
> +    {
> +        .grp_id     = PCI_CAP_ID_AGP,
> +        .grp_type   = GRP_TYPE_HARDWIRED,
> +        .grp_size   = 0x30,
> +        .size_init  = pt_reg_grp_size_init,
> +    },
> +    /* Vital Product Data Capability Structure reg group */
> +    {
> +        .grp_id      = PCI_CAP_ID_VPD,
> +        .grp_type    = GRP_TYPE_EMU,
> +        .grp_size    = 0x08,
> +        .size_init   = pt_reg_grp_size_init,
> +        .emu_reg_tbl = pt_emu_reg_vpd_tbl,
> +    },
> +    /* Slot Identification reg group */
> +    {
> +        .grp_id     = PCI_CAP_ID_SLOTID,
> +        .grp_type   = GRP_TYPE_HARDWIRED,
> +        .grp_size   = 0x04,
> +        .size_init  = pt_reg_grp_size_init,
> +    },
> +    /* PCI-X Capabilities List Item reg group */
> +    {
> +        .grp_id     = PCI_CAP_ID_PCIX,
> +        .grp_type   = GRP_TYPE_HARDWIRED,
> +        .grp_size   = 0x18,
> +        .size_init  = pt_reg_grp_size_init,
> +    },
> +    /* Vendor Specific Capability Structure reg group */
> +    {
> +        .grp_id      = PCI_CAP_ID_VNDR,
> +        .grp_type    = GRP_TYPE_EMU,
> +        .grp_size    = 0xFF,
> +        .size_init   = pt_vendor_size_init,
> +        .emu_reg_tbl = pt_emu_reg_vendor_tbl,
> +    },
> +    /* SHPC Capability List Item reg group */
> +    {
> +        .grp_id     = PCI_CAP_ID_SHPC,
> +        .grp_type   = GRP_TYPE_HARDWIRED,
> +        .grp_size   = 0x08,
> +        .size_init  = pt_reg_grp_size_init,
> +    },
> +    /* Subsystem ID and Subsystem Vendor ID Capability List Item reg group */
> +    {
> +        .grp_id     = PCI_CAP_ID_SSVID,
> +        .grp_type   = GRP_TYPE_HARDWIRED,
> +        .grp_size   = 0x08,
> +        .size_init  = pt_reg_grp_size_init,
> +    },
> +    /* AGP 8x Capability Structure reg group */
> +    {
> +        .grp_id     = PCI_CAP_ID_AGP3,
> +        .grp_type   = GRP_TYPE_HARDWIRED,
> +        .grp_size   = 0x30,
> +        .size_init  = pt_reg_grp_size_init,
> +    },
> +    /* PCI Express Capability Structure reg group */
> +    {
> +        .grp_id      = PCI_CAP_ID_EXP,
> +        .grp_type    = GRP_TYPE_EMU,
> +        .grp_size    = 0xFF,
> +        .size_init   = pt_pcie_size_init,
> +        .emu_reg_tbl = pt_emu_reg_pcie_tbl,
> +    },
> +    {
> +        .grp_size = 0,
> +    },
> +};
> +
> +/* initialize Capabilities Pointer or Next Pointer register */
> +static int pt_ptr_reg_init(XenPCIPassthroughState *s,
> +                           XenPTRegInfo *reg, uint32_t real_offset,
> +                           uint32_t *data)
> +{
> +    /* uint32_t reg_field = (uint32_t)s->dev.config[real_offset]; */
> +    uint32_t reg_field = pci_get_byte(s->dev.config + real_offset);

There is no check whether real_offset > than the size of what is
in dev.config. Perhaps that should be done?

> +    int i;
> +
> +    /* find capability offset */
> +    while (reg_field) {
> +        for (i = 0; pt_emu_reg_grp_tbl[i].grp_size != 0; i++) {
> +            if (pt_hide_dev_cap(s->real_device,
> +                                pt_emu_reg_grp_tbl[i].grp_id)) {
> +                continue;
> +            }
> +            if (pt_emu_reg_grp_tbl[i].grp_id == s->dev.config[reg_field]) {
> +                if (pt_emu_reg_grp_tbl[i].grp_type == GRP_TYPE_EMU) {
> +                    goto out;
> +                }
> +                /* ignore the 0 hardwired capability, find next one */
> +                break;
> +            }
> +        }
> +        /* next capability */
> +        /* reg_field = (uint32_t)s->dev.config[reg_field + 1]; */
> +        reg_field = pci_get_byte(s->dev.config + reg_field + 1);
> +    }
> +
> +out:
> +    *data = reg_field;
> +    return 0;
> +}
> +
> +
> +/*************
> + * Main
> + */
> +
> +/* restore a part of I/O device register */
> +static int pt_config_restore(XenPCIPassthroughState *s)
> +{
> +    XenPTRegGroup *reg_grp_entry = NULL;
> +    XenPTReg *reg_entry = NULL;
> +    XenPTRegInfo *reg = NULL;
> +    uint32_t real_offset = 0;
> +    uint32_t read_val = 0;
> +    uint32_t val = 0;
> +    int rc = 0;
> +
> +    /* find emulate register group entry */
> +    QLIST_FOREACH(reg_grp_entry, &s->reg_grp_tbl, entries) {
> +        /* find emulate register entry */
> +        QLIST_FOREACH(reg_entry, &reg_grp_entry->reg_tbl_list, entries) {
> +            reg = reg_entry->reg;
> +
> +            /* check whether restoring is needed */
> +            if (!reg->u.b.restore) {
> +                continue;
> +            }
> +
> +            real_offset = reg_grp_entry->base_offset + reg->offset;
> +
> +            /* read I/O device register value */
> +            rc = host_pci_get_block(s->real_device, real_offset,
> +                                    (uint8_t *)&read_val, reg->size);
> +
> +            if (rc < 0) {
> +                PT_ERR(&s->dev, "pci_read_block failed. "
> +                       "return value: %d.\n", rc);
> +                memset(&read_val, 0xff, reg->size);
> +            }
> +
> +            val = 0;
> +
> +            /* restore based on register size */
> +            switch (reg->size) {
> +            case 1:
> +                /* byte register */
> +                rc = reg->u.b.restore(s, reg_entry, real_offset,
> +                                      (uint8_t)read_val, (uint8_t *)&val);
> +                break;
> +            case 2:
> +                /* word register */
> +                rc = reg->u.w.restore(s, reg_entry, real_offset,
> +                                      (uint16_t)read_val, (uint16_t *)&val);
> +                break;
> +            case 4:
> +                /* double word register */
> +                rc = reg->u.dw.restore(s, reg_entry, real_offset,
> +                                       (uint32_t)read_val, (uint32_t *)&val);
> +                break;
> +            }
> +
> +            /* restoring error */
> +            if (rc < 0) {
> +                xen_shutdown_fatal_error("Internal error: Invalid restoring."
> +                                         " (%s, rc: %d)\n", __func__, rc);
> +                return -1;
> +            }
> +
> +            PT_LOG_CONFIG(&s->dev, real_offset, val, reg->size);
> +
> +            rc = host_pci_set_block(s->real_device, real_offset,
> +                                    (uint8_t *)&val, reg->size);
> +
> +            if (rc < 0) {
> +                PT_ERR(&s->dev, "pci_write_block failed. "
> +                       "return value: %d.\n", rc);
> +                return -1;
> +            }
> +        }
> +    }
> +
> +    /* if AER supported, restore it */
> +    if (s->pm_state->aer_base) {
> +        pt_aer_reg_restore(s);
> +    }
> +    return 0;
> +}
> +/* reinitialize all emulate registers */
> +static int pt_config_reinit(XenPCIPassthroughState *s)
> +{
> +    XenPTRegGroup *reg_grp_entry = NULL;
> +    XenPTReg *reg_entry = NULL;
> +    XenPTRegInfo *reg = NULL;
> +    int rc = 0;
> +
> +    /* find emulate register group entry */
> +    QLIST_FOREACH(reg_grp_entry, &s->reg_grp_tbl, entries) {
> +        /* find emulate register entry */
> +        QLIST_FOREACH(reg_entry, &reg_grp_entry->reg_tbl_list, entries) {
> +            reg = reg_entry->reg;
> +            if (reg->init) {
> +                /* initialize emulate register */
> +                rc = reg->init(s, reg_entry->reg,
> +                               reg_grp_entry->base_offset + reg->offset,
> +                               &reg_entry->data);
> +                if (rc < 0) {
> +                    return rc;
> +                }
> +            }
> +        }
> +    }
> +    return 0;
> +}
> +
> +static int pt_init_pci_config(XenPCIPassthroughState *s)
> +{
> +    PCIDevice *d = &s->dev;
> +    int rc = 0;
> +
> +    PT_LOG(d, "Reinitialize PCI configuration registers due to power state"
> +           " transition with internal reset.\n");
> +
> +    /* restore a part of I/O device register */
> +    rc = pt_config_restore(s);
> +    if (rc < 0) {
> +        return rc;
> +    }
> +
> +    /* reinitialize all emulate register */
> +    rc = pt_config_reinit(s);
> +    if (rc < 0) {
> +        return rc;
> +    }
> +
> +    /* rebind machine_irq to device */
> +    if (s->machine_irq != 0) {
> +        uint8_t e_device = PCI_SLOT(s->dev.devfn);
> +        uint8_t e_intx = pci_intx(s);
> +
> +        rc = xc_domain_bind_pt_pci_irq(xen_xc, xen_domid, s->machine_irq, 0,
> +                                       e_device, e_intx);
> +        if (rc < 0) {
> +            PT_ERR(d, "Rebinding of interrupt failed! rc=%d\n", rc);
> +        }
> +    }
> +
> +    return rc;
> +}
> +
> +static uint8_t find_cap_offset(XenPCIPassthroughState *s, uint8_t cap)
> +{
> +    uint8_t id;
> +    int max_cap = 48;

You need to use #define for that. Also you might want just make it an
unsigned.

> +    uint8_t pos = PCI_CAPABILITY_LIST;
> +    uint8_t status = 0;
> +
> +    if (host_pci_get_byte(s->real_device, PCI_STATUS, &status)) {
> +        return 0;
> +    }
> +    if ((status & PCI_STATUS_CAP_LIST) == 0) {
> +        return 0;
> +    }
> +
> +    while (max_cap--) {
> +        if (host_pci_get_byte(s->real_device, pos, &pos)) {
> +            break;
> +        }
> +        if (pos < 0x40) {

Can you explain why? (I presume it is b/c the capabilities entries do
not exist before 0x40 offset?)

> +            break;
> +        }
> +
> +        pos &= ~3;
> +        if (host_pci_get_byte(s->real_device, pos + PCI_CAP_LIST_ID, &id)) {
> +            break;
> +        }
> +
> +        if (id == 0xff) {
> +            break;
> +        }
> +        if (id == cap) {
> +            return pos;
> +        }
> +
> +        pos += PCI_CAP_LIST_NEXT;
> +    }
> +    return 0;
> +}
> +
> +static int pt_config_reg_init(XenPCIPassthroughState *s,
> +                              XenPTRegGroup *reg_grp, XenPTRegInfo *reg)
> +{
> +    XenPTReg *reg_entry;
> +    uint32_t data = 0;
> +    int rc = 0;
> +
> +    reg_entry = g_new0(XenPTReg, 1);
> +    reg_entry->reg = reg;
> +
> +    if (reg->init) {
> +        /* initialize emulate register */
> +        rc = reg->init(s, reg_entry->reg,
> +                       reg_grp->base_offset + reg->offset, &data);
> +        if (rc < 0) {
> +            free(reg_entry);
> +            return rc;
> +        }
> +        if (data == PT_INVALID_REG) {
> +            /* free unused BAR register entry */
> +            free(reg_entry);
> +            return 0;
> +        }
> +        /* set register value */
> +        reg_entry->data = data;
> +    }
> +    /* list add register entry */
> +    QLIST_INSERT_HEAD(&reg_grp->reg_tbl_list, reg_entry, entries);
> +
> +    return 0;
> +}
> +
> +int pt_config_init(XenPCIPassthroughState *s)
> +{
> +    XenPTRegGroup *reg_grp_entry = NULL;
> +    uint32_t reg_grp_offset = 0;
> +    XenPTRegInfo *reg_tbl = NULL;
> +    int i, j, rc;
> +
> +    QLIST_INIT(&s->reg_grp_tbl);
> +
> +    for (i = 0; pt_emu_reg_grp_tbl[i].grp_size != 0; i++) {
> +        if (pt_emu_reg_grp_tbl[i].grp_id != 0xFF) {
> +            if (pt_hide_dev_cap(s->real_device,
> +                                pt_emu_reg_grp_tbl[i].grp_id)) {
> +                continue;
> +            }
> +
> +            reg_grp_offset = find_cap_offset(s, pt_emu_reg_grp_tbl[i].grp_id);
> +
> +            if (!reg_grp_offset) {
> +                continue;
> +            }
> +        }
> +
> +        reg_grp_entry = g_new0(XenPTRegGroup, 1);
> +        QLIST_INIT(&reg_grp_entry->reg_tbl_list);
> +        QLIST_INSERT_HEAD(&s->reg_grp_tbl, reg_grp_entry, entries);
> +
> +        reg_grp_entry->base_offset = reg_grp_offset;
> +        reg_grp_entry->reg_grp = pt_emu_reg_grp_tbl + i;
> +        if (pt_emu_reg_grp_tbl[i].size_init) {
> +            /* get register group size */
> +            rc = pt_emu_reg_grp_tbl[i].size_init(s, reg_grp_entry->reg_grp,
> +                                                 reg_grp_offset,
> +                                                 &reg_grp_entry->size);
> +            if (rc < 0) {
> +                pt_config_delete(s);
> +                return rc;
> +            }
> +        }
> +
> +        if (pt_emu_reg_grp_tbl[i].grp_type == GRP_TYPE_EMU) {
> +            if (pt_emu_reg_grp_tbl[i].emu_reg_tbl) {
> +                reg_tbl = pt_emu_reg_grp_tbl[i].emu_reg_tbl;
> +                /* initialize capability register */
> +                for (j = 0; reg_tbl->size != 0; j++, reg_tbl++) {
> +                    /* initialize capability register */
> +                    rc = pt_config_reg_init(s, reg_grp_entry, reg_tbl);
> +                    if (rc < 0) {
> +                        pt_config_delete(s);
> +                        return rc;
> +                    }
> +                }
> +            }
> +        }
> +        reg_grp_offset = 0;

Can you move this to the top of the loop?
> +    }
> +
> +    return 0;
> +}
> +
> +/* delete all emulate register */
> +void pt_config_delete(XenPCIPassthroughState *s)
> +{
> +    struct XenPTRegGroup *reg_group, *next_grp;
> +    struct XenPTReg *reg, *next_reg;
> +
> +    /* free Power Management info table */
> +    if (s->pm_state) {
> +        if (s->pm_state->pm_timer) {
> +            qemu_del_timer(s->pm_state->pm_timer);
> +            qemu_free_timer(s->pm_state->pm_timer);
> +            s->pm_state->pm_timer = NULL;
> +        }
> +
> +        g_free(s->pm_state);
> +    }
> +
> +    /* free all register group entry */
> +    QLIST_FOREACH_SAFE(reg_group, &s->reg_grp_tbl, entries, next_grp) {
> +        /* free all register entry */
> +        QLIST_FOREACH_SAFE(reg, &reg_group->reg_tbl_list, entries, next_reg) {
> +            QLIST_REMOVE(reg, entries);
> +            g_free(reg);
> +        }
> +
> +        QLIST_REMOVE(reg_group, entries);
> +        g_free(reg_group);
> +    }
> +}
> -- 
> Anthony PERARD
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 23:02:35 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 23:02:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXhXq-0004ER-Pw; Mon, 05 Dec 2011 23:01:58 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1RXhXp-0004E7-Ib
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 23:01:57 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-12.tower-174.messagelabs.com!1323126071!4319121!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13870 invoked from network); 5 Dec 2011 23:01:12 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-12.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 5 Dec 2011 23:01:12 -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
	pB5N15lM015862
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Mon, 5 Dec 2011 18:01:05 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pB5N15nV015860;
	Mon, 5 Dec 2011 18:01:05 -0500
Date: Mon, 5 Dec 2011 19:01:05 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Anthony PERARD <anthony.perard@citrix.com>
Message-ID: <20111205230105.GB9560@andromeda.dapyr.net>
References: <1322156679-9441-1-git-send-email-anthony.perard@citrix.com>
	<1322156679-9441-8-git-send-email-anthony.perard@citrix.com>
	<20111201231847.GA636@andromeda.dapyr.net>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20111201231847.GA636@andromeda.dapyr.net>
User-Agent: Mutt/1.5.9i
Cc: Guy Zana <guy@neocleus.com>, Xen Devel <xen-devel@lists.xensource.com>,
	Allen Kay <allen.m.kay@intel.com>, QEMU-devel <qemu-devel@nongnu.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH V5 07/10] Introduce Xen PCI Passthrough,
	qdevice (1/3)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> > +/* emulated register management */
> > +struct XenPTReg {
> > +    QLIST_ENTRY(XenPTReg) entries;
> > +    XenPTRegInfo *reg;
> > +    uint32_t data;

There should be a comment saying what 'data' is actually. Say
the register value... But I wonder - what if the register is more than
32-bytes? Where do we keep the "data" then?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 05 23:02:35 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 Dec 2011 23:02:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXhXq-0004ER-Pw; Mon, 05 Dec 2011 23:01:58 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1RXhXp-0004E7-Ib
	for xen-devel@lists.xensource.com; Mon, 05 Dec 2011 23:01:57 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-12.tower-174.messagelabs.com!1323126071!4319121!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13870 invoked from network); 5 Dec 2011 23:01:12 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-12.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 5 Dec 2011 23:01:12 -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
	pB5N15lM015862
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Mon, 5 Dec 2011 18:01:05 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pB5N15nV015860;
	Mon, 5 Dec 2011 18:01:05 -0500
Date: Mon, 5 Dec 2011 19:01:05 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Anthony PERARD <anthony.perard@citrix.com>
Message-ID: <20111205230105.GB9560@andromeda.dapyr.net>
References: <1322156679-9441-1-git-send-email-anthony.perard@citrix.com>
	<1322156679-9441-8-git-send-email-anthony.perard@citrix.com>
	<20111201231847.GA636@andromeda.dapyr.net>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20111201231847.GA636@andromeda.dapyr.net>
User-Agent: Mutt/1.5.9i
Cc: Guy Zana <guy@neocleus.com>, Xen Devel <xen-devel@lists.xensource.com>,
	Allen Kay <allen.m.kay@intel.com>, QEMU-devel <qemu-devel@nongnu.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH V5 07/10] Introduce Xen PCI Passthrough,
	qdevice (1/3)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> > +/* emulated register management */
> > +struct XenPTReg {
> > +    QLIST_ENTRY(XenPTReg) entries;
> > +    XenPTRegInfo *reg;
> > +    uint32_t data;

There should be a comment saying what 'data' is actually. Say
the register value... But I wonder - what if the register is more than
32-bytes? Where do we keep the "data" then?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 00:04:15 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 00:04:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXiVX-0005Ca-Nt; Tue, 06 Dec 2011 00:03:39 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1RXiVV-0005CV-5x
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 00:03:37 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-5.tower-27.messagelabs.com!1323129735!45522561!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14307 invoked from network); 6 Dec 2011 00:02:17 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-5.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 6 Dec 2011 00:02:17 -0000
Received: from andromeda.dapyr.net (darnok@localhost [127.0.0.1])
	by andromeda.dapyr.net (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id
	pB602eeY020107
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Mon, 5 Dec 2011 19:02:40 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pB602eMw020105;
	Mon, 5 Dec 2011 19:02:40 -0500
Date: Mon, 5 Dec 2011 20:02:40 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Anthony PERARD <anthony.perard@citrix.com>
Message-ID: <20111206000240.GA15873@andromeda.dapyr.net>
References: <1322156679-9441-1-git-send-email-anthony.perard@citrix.com>
	<1322156679-9441-11-git-send-email-anthony.perard@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1322156679-9441-11-git-send-email-anthony.perard@citrix.com>
User-Agent: Mutt/1.5.9i
Cc: Xen Devel <xen-devel@lists.xensource.com>,
	Jiang Yunhong <yunhong.jiang@intel.com>,
	Shan Haitao <haitao.shan@intel.com>, QEMU-devel <qemu-devel@nongnu.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH V5 10/10] Introduce Xen PCI Passthrough,
	MSI (3/3)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Nov 24, 2011 at 05:44:39PM +0000, Anthony PERARD wrote:
> From: Jiang Yunhong <yunhong.jiang@intel.com>
> 
> A more complete history can be found here:
> git://xenbits.xensource.com/qemu-xen-unstable.git
> 
> Signed-off-by: Jiang Yunhong <yunhong.jiang@intel.com>
> Signed-off-by: Shan Haitao <haitao.shan@intel.com>
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> ---
>  Makefile.target                      |    1 +
>  hw/apic-msidef.h                     |    2 +
>  hw/xen_pci_passthrough.c             |   60 +++-
>  hw/xen_pci_passthrough.h             |   55 +++
>  hw/xen_pci_passthrough_config_init.c |  505 +++++++++++++++++++++++++-
>  hw/xen_pci_passthrough_msi.c         |  678 ++++++++++++++++++++++++++++++++++
>  6 files changed, 1294 insertions(+), 7 deletions(-)
>  create mode 100644 hw/xen_pci_passthrough_msi.c
> 
> diff --git a/Makefile.target b/Makefile.target
> index 33435a3..81cff70 100644
> --- a/Makefile.target
> +++ b/Makefile.target
> @@ -223,6 +223,7 @@ obj-i386-$(CONFIG_XEN) += xen_platform.o
>  obj-i386-$(CONFIG_XEN_PCI_PASSTHROUGH) += host-pci-device.o
>  obj-i386-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen_pci_passthrough.o
>  obj-i386-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen_pci_passthrough_config_init.o
> +obj-i386-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen_pci_passthrough_msi.o
>  
>  # Inter-VM PCI shared memory
>  CONFIG_IVSHMEM =
> diff --git a/hw/apic-msidef.h b/hw/apic-msidef.h
> index 3182f0b..6e2eb71 100644
> --- a/hw/apic-msidef.h
> +++ b/hw/apic-msidef.h
> @@ -22,6 +22,8 @@
>  
>  #define MSI_ADDR_DEST_MODE_SHIFT        2
>  
> +#define MSI_ADDR_REDIRECTION_SHIFT      3
> +
>  #define MSI_ADDR_DEST_ID_SHIFT          12
>  #define  MSI_ADDR_DEST_ID_MASK          0x00ffff0
>  
> diff --git a/hw/xen_pci_passthrough.c b/hw/xen_pci_passthrough.c
> index c816ed5..cd7e3c7 100644
> --- a/hw/xen_pci_passthrough.c
> +++ b/hw/xen_pci_passthrough.c
> @@ -38,6 +38,39 @@
>   *     Write '1'
>   *       <ptdev->msi_trans_en is false>
>   *         - Set real bit to '1'.
> + *
> + * MSI-INTx translation.
> + *   Initialize(xc_physdev_map_pirq_msi/pt_msi_setup)
> + *     Bind MSI-INTx(xc_domain_bind_pt_irq)
> + *       <fail>
> + *         - Unmap MSI.
> + *           <success>
> + *             - Set dev->msi->pirq to '-1'.
> + *           <fail>
> + *             - Do nothing.
> + *
> + *   Write to Interrupt Disable bit by guest software(pt_cmd_reg_write)
> + *     Write '0'
> + *       <ptdev->msi_trans_en is true>
> + *         - Set MSI Enable bit to '1'.
> + *
> + *     Write '1'
> + *       <ptdev->msi_trans_en is true>
> + *         - Set MSI Enable bit to '0'.
> + *
> + * MSI interrupt:
> + *   Initialize MSI register(pt_msi_setup, pt_msi_update)
> + *     Bind MSI(xc_domain_update_msi_irq)
> + *       <fail>
> + *         - Unmap MSI.
> + *         - Set dev->msi->pirq to '-1'.
> + *
> + * MSI-X interrupt:
> + *   Initialize MSI-X register(pt_msix_update_one)
> + *     Bind MSI-X(xc_domain_update_msi_irq)
> + *       <fail>
> + *         - Unmap MSI-X.
> + *         - Set entry->pirq to '-1'.
>   */
>  
>  #include <sys/ioctl.h>
> @@ -389,6 +422,7 @@ static void pt_iomem_map(XenPCIPassthroughState *s, int i,
>      }
>  
>      if (!first_map && old_ebase != PT_PCI_BAR_UNMAPPED) {
> +        pt_add_msix_mapping(s, i);
>          /* Remove old mapping */
>          memory_region_del_subregion(r->address_space,
>                                      r->memory);
> @@ -417,6 +451,15 @@ static void pt_iomem_map(XenPCIPassthroughState *s, int i,
>          if (ret != 0) {
>              PT_ERR(&s->dev, "create new mapping failed!\n");
>          }
> +
> +        ret = pt_remove_msix_mapping(s, i);
> +        if (ret != 0) {
> +            PT_ERR(&s->dev, "Remove MSI-X MMIO mapping failed!\n");
> +        }
> +
> +        if (old_ebase != e_phys && old_ebase != -1) {
> +            pt_msix_update_remap(s, i);
> +        }
>      }
>  }
>  
> @@ -744,6 +787,9 @@ static int pt_initfn(PCIDevice *pcidev)
>          mapped_machine_irq[machine_irq]++;
>      }
>  
> +    /* setup MSI-INTx translation if support */
> +    rc = pt_enable_msi_translate(s);
> +
>      /* bind machine_irq to device */
>      if (rc < 0 && machine_irq != 0) {
>          uint8_t e_device = PCI_SLOT(s->dev.devfn);
> @@ -773,7 +819,8 @@ static int pt_initfn(PCIDevice *pcidev)
>  
>  out:
>      PT_LOG(pcidev, "Real physical device %02x:%02x.%x registered successfuly!"
> -           "\nIRQ type = %s\n", bus, slot, func, "INTx");
> +           "\nIRQ type = %s\n", bus, slot, func,
> +           s->msi_trans_en ? "MSI-INTx" : "INTx");
>  
>      return 0;
>  }
> @@ -790,7 +837,7 @@ static int pt_unregister_device(PCIDevice *pcidev)
>      e_intx = pci_intx(s);
>      machine_irq = s->machine_irq;
>  
> -    if (machine_irq) {
> +    if (s->msi_trans_en == 0 && machine_irq) {

It is defined as 'bool' so you could do !s->msi_trans_en instead?

>          rc = xc_domain_unbind_pt_irq(xen_xc, xen_domid, machine_irq,
>                                       PT_IRQ_TYPE_PCI, 0, e_device, e_intx, 0);
>          if (rc < 0) {
> @@ -798,6 +845,13 @@ static int pt_unregister_device(PCIDevice *pcidev)
>          }
>      }
>  
> +    if (s->msi) {
> +        pt_msi_disable(s);
> +    }
> +    if (s->msix) {
> +        pt_msix_disable(s);
> +    }
> +
>      if (machine_irq) {
>          mapped_machine_irq[machine_irq]--;
>  
> @@ -832,6 +886,8 @@ static PCIDeviceInfo xen_pci_passthrough = {
>      .is_express = 0,
>      .qdev.props = (Property[]) {
>          DEFINE_PROP_STRING("hostaddr", XenPCIPassthroughState, hostaddr),
> +        DEFINE_PROP_BIT("msitranslate", XenPCIPassthroughState, msi_trans_cap,
> +                        0, true),
>          DEFINE_PROP_BIT("power-mgmt", XenPCIPassthroughState, power_mgmt,
>                          0, false),
>          DEFINE_PROP_END_OF_LIST(),
> diff --git a/hw/xen_pci_passthrough.h b/hw/xen_pci_passthrough.h
> index 110325c..acbbab5 100644
> --- a/hw/xen_pci_passthrough.h
> +++ b/hw/xen_pci_passthrough.h
> @@ -74,6 +74,10 @@ typedef int (*conf_byte_restore)
>  #define PT_PCI_BAR_UNMAPPED (-1)
>  #define PT_UNASSIGNED_PIRQ (-1)
>  
> +/* MSI-X */
> +#define PT_MSI_FLAG_UNINIT 0x1000
> +#define PT_MSI_FLAG_MAPPED 0x2000


Can you explain what those two defines do please?

> +
>  
>  typedef enum {
>      GRP_TYPE_HARDWIRED = 0,                     /* 0 Hardwired reg group */
> @@ -177,6 +181,34 @@ typedef struct XenPTRegGroup {
>  } XenPTRegGroup;
>  
>  
> +typedef struct XenPTMSI {
> +    uint32_t flags;
> +    uint32_t ctrl_offset; /* saved control offset */
> +    int pirq;          /* guest pirq corresponding */
> +    uint32_t addr_lo;  /* guest message address */
> +    uint32_t addr_hi;  /* guest message upper address */
> +    uint16_t data;     /* guest message data */
> +} XenPTMSI;
> +
> +typedef struct XenMSIXEntry {
> +    int pirq;        /* -1 means unmapped */
> +    int flags;       /* flags indicting whether MSI ADDR or DATA is updated */
> +    uint32_t io_mem[4];

Can you document what is in each position? Perhaps some enums or
#defines for them?

> +} XenMSIXEntry;
> +typedef struct XenPTMSIX {
> +    uint32_t ctrl_offset;
> +    int enabled;
> +    int total_entries;
> +    int bar_index;
> +    uint64_t table_base;
> +    uint32_t table_off;
> +    uint32_t table_offset_adjust; /* page align mmap */
> +    uint64_t mmio_base_addr;
> +    int mmio_index;
> +    void *phys_iomem_base;
> +    XenMSIXEntry msix_entry[0];
> +} XenPTMSIX;
> +
>  typedef struct XenPTPM {
>      QEMUTimer *pm_timer;  /* QEMUTimer struct */
>      int no_soft_reset;    /* No Soft Reset flags */
> @@ -200,6 +232,13 @@ struct XenPCIPassthroughState {
>  
>      uint32_t machine_irq;
>  
> +    XenPTMSI *msi;
> +    XenPTMSIX *msix;
> +
> +    /* Physical MSI to guest INTx translation when possible */

Meaning that the MSI vector is going to show up as INTx in the guest?

This is by default enabled, right? At least that is what
txt/misc/vtd.txt

tells me. So would it be better than to have 'msi_trans_off' as flag
as by default we would enable it? So would it be better than to have
'msi_trans_off' as flag?

> +    uint32_t msi_trans_cap;
> +    bool msi_trans_en;
> +
>      uint32_t power_mgmt;
>      XenPTPM *pm_state;
>  
> @@ -279,4 +318,20 @@ static inline uint8_t pci_intx(XenPCIPassthroughState *s)
>      return r_val;
>  }
>  
> +/* MSI/MSI-X */
> +void pt_msi_set_enable(XenPCIPassthroughState *s, int en);

You could make it a bool. So "bool en" instead?
> +int pt_msi_setup(XenPCIPassthroughState *s);
> +int pt_msi_update(XenPCIPassthroughState *d);
> +void pt_msi_disable(XenPCIPassthroughState *s);
> +int pt_enable_msi_translate(XenPCIPassthroughState *s);
> +void pt_disable_msi_translate(XenPCIPassthroughState *s);
> +
> +int pt_msix_init(XenPCIPassthroughState *s, int pos);

uint32_t as pos?
> +void pt_msix_delete(XenPCIPassthroughState *s);
> +int pt_msix_update(XenPCIPassthroughState *s);
> +int pt_msix_update_remap(XenPCIPassthroughState *s, int bar_index);

uint32_t as bar_index?
> +void pt_msix_disable(XenPCIPassthroughState *s);
> +int pt_add_msix_mapping(XenPCIPassthroughState *s, int bar_index);
> +int pt_remove_msix_mapping(XenPCIPassthroughState *s, int bar_index);
> +
>  #endif /* !QEMU_HW_XEN_PCI_PASSTHROUGH_H */
> diff --git a/hw/xen_pci_passthrough_config_init.c b/hw/xen_pci_passthrough_config_init.c
> index ae64544..28523f1 100644
> --- a/hw/xen_pci_passthrough_config_init.c
> +++ b/hw/xen_pci_passthrough_config_init.c
> @@ -398,11 +398,19 @@ static int pt_cmd_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
>      throughable_mask = ~emu_mask & valid_mask;
>  
>      if (*value & PCI_COMMAND_INTX_DISABLE) {
> -        throughable_mask |= PCI_COMMAND_INTX_DISABLE;
> -    } else {
> -        if (s->machine_irq) {
> +        if (s->msi_trans_en) {
> +            pt_msi_set_enable(s, 0);

Can you put a comment explaining the '0' argument?
> +        } else {
>              throughable_mask |= PCI_COMMAND_INTX_DISABLE;
>          }
> +    } else {
> +        if (s->msi_trans_en) {
> +            pt_msi_set_enable(s, 1);
> +        } else {
> +            if (s->machine_irq) {
> +                throughable_mask |= PCI_COMMAND_INTX_DISABLE;
> +            }
> +        }
>      }
>  
>      *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
> @@ -1282,13 +1290,21 @@ static void pt_reset_interrupt_and_io_mapping(XenPCIPassthroughState *s)
>      e_device = PCI_SLOT(s->dev.devfn);
>      e_intx = pci_intx(s);
>  
> -    if (s->machine_irq) {
> +    if (s->msi_trans_en == 0 && s->machine_irq) {
>          if (xc_domain_unbind_pt_irq(xen_xc, xen_domid, s->machine_irq,
>                                      PT_IRQ_TYPE_PCI, 0, e_device, e_intx, 0)) {
>              PT_ERR(d, "Unbinding of interrupt failed!\n");
>          }
>      }
>  
> +    /* disable MSI/MSI-X and MSI-INTx translation */
> +    if (s->msi) {
> +        pt_msi_disable(s);
> +    }
> +    if (s->msix) {
> +        pt_msix_disable(s);
> +    }
> +
>      /* clear all virtual region address */
>      for (i = 0; i < PCI_NUM_REGIONS; i++) {
>          r = &d->io_regions[i];
> @@ -1536,6 +1552,415 @@ static XenPTRegInfo pt_emu_reg_pm_tbl[] = {
>      },
>  };
>  
> +/********************************
> + * MSI Capability
> + */
> +
> +/* Message Control register */
> +static int pt_msgctrl_reg_init(XenPCIPassthroughState *s,
> +                               XenPTRegInfo *reg, uint32_t real_offset,
> +                               uint32_t *data)
> +{
> +    PCIDevice *d = &s->dev;
> +    uint16_t reg_field = 0;
> +
> +    /* use I/O device register's value as initial value */
> +    reg_field = pci_get_word(d->config + real_offset);

There is no 'pci_get_halfword' operations?

> +
> +    if (reg_field & PCI_MSI_FLAGS_ENABLE) {
> +        PT_LOG(&s->dev, "MSI already enabled, disable it first\n");

.. "disabling it first."

> +        host_pci_set_word(s->real_device, real_offset,
> +                          reg_field & ~PCI_MSI_FLAGS_ENABLE);
> +    }
> +    s->msi->flags |= reg_field | PT_MSI_FLAG_UNINIT;

There is no chance that you PT_MSI_FLAG_UNINIT would shadow what
is in the register? You are reading a word after all.. ah, the
reg_field is a 16-bit, so you are populating the unused fields.
Perhaps you could use bit-fields?


> +    s->msi->ctrl_offset = real_offset;
> +
> +    *data = reg->init_val;
> +    return 0;
> +}
> +static int pt_msgctrl_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
> +                                uint16_t *value, uint16_t dev_value,
> +                                uint16_t valid_mask)
> +{
> +    XenPTRegInfo *reg = cfg_entry->reg;
> +    uint16_t writable_mask = 0;
> +    uint16_t throughable_mask = 0;
> +    uint16_t val;
> +
> +    /* Currently no support for multi-vector */
> +    if (*value & PCI_MSI_FLAGS_QSIZE) {
> +        PT_WARN(&s->dev, "try to set more than 1 vector ctrl %x\n", *value);


But no return -ENOSPC?

The message should probably read: "Tries to set more.."
> +    }
> +
> +    /* modify emulate register */
> +    writable_mask = reg->emu_mask & ~reg->ro_mask & valid_mask;
> +    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
> +    /* update the msi_info too */

err, msi_info -> msi->flags?

> +    s->msi->flags |= cfg_entry->data &
> +        ~(PT_MSI_FLAG_UNINIT | PT_MSI_FLAG_MAPPED | PCI_MSI_FLAGS_ENABLE);
> +
> +    /* create value for writing to I/O device register */
> +    val = *value;
> +    throughable_mask = ~reg->emu_mask & valid_mask;
> +    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
> +
> +    /* update MSI */
> +    if (val & PCI_MSI_FLAGS_ENABLE) {
> +        /* setup MSI pirq for the first time */
> +        if (s->msi->flags & PT_MSI_FLAG_UNINIT) {
> +            if (s->msi_trans_en) {
> +                PT_LOG(&s->dev,
> +                       "guest enabling MSI, disable MSI-INTx translation\n");
> +                pt_disable_msi_translate(s);
> +            } else {
> +                /* Init physical one */
> +                PT_LOG(&s->dev, "setup MSI\n");
> +                if (pt_msi_setup(s)) {
> +                    /* We do not broadcast the error to the framework code, so
> +                     * that MSI errors are contained in MSI emulation code and
> +                     * QEMU can go on running.
> +                     * Guest MSI would be actually not working.

Not sure if the last sentence is needed?

> +                     */
> +                    *value &= ~PCI_MSI_FLAGS_ENABLE;
> +                    PT_WARN(&s->dev, "Can not map MSI.\n");
> +                    return 0;
> +                }
> +            }
> +            if (pt_msi_update(s)) {
> +                *value &= ~PCI_MSI_FLAGS_ENABLE;
> +                PT_WARN(&s->dev, "Can not bind MSI\n");
> +                return 0;
> +            }
> +            s->msi->flags &= ~PT_MSI_FLAG_UNINIT;
> +            s->msi->flags |= PT_MSI_FLAG_MAPPED;
> +        }
> +        s->msi->flags |= PCI_MSI_FLAGS_ENABLE;
> +    } else {
> +        s->msi->flags &= ~PCI_MSI_FLAGS_ENABLE;
> +    }
> +
> +    /* pass through MSI_ENABLE bit when no MSI-INTx translation */
                                          ^- "there is"


> +    if (!s->msi_trans_en) {
> +        *value &= ~PCI_MSI_FLAGS_ENABLE;
> +        *value |= val & PCI_MSI_FLAGS_ENABLE;
> +    }
> +
> +    return 0;
> +}
> +
> +/* initialize Message Upper Address register */
> +static int pt_msgaddr64_reg_init(XenPCIPassthroughState *ptdev,
> +                                 XenPTRegInfo *reg, uint32_t real_offset,
> +                                 uint32_t *data)
> +{
> +    /* no need to initialize in case of 32 bit type */
> +    if (!(ptdev->msi->flags & PCI_MSI_FLAGS_64BIT)) {
> +        *data = PT_INVALID_REG;
> +    } else {
> +        *data = reg->init_val;
> +    }
> +
> +    return 0;
> +}
> +/* this function will be called twice (for 32 bit and 64 bit type) */
> +/* initialize Message Data register */
> +static int pt_msgdata_reg_init(XenPCIPassthroughState *ptdev,
> +                               XenPTRegInfo *reg, uint32_t real_offset,
> +                               uint32_t *data)
> +{
> +    uint32_t flags = ptdev->msi->flags;
> +    uint32_t offset = reg->offset;
> +
> +    /* check the offset whether matches the type or not */
> +    if (((offset == PCI_MSI_DATA_64) &&  (flags & PCI_MSI_FLAGS_64BIT)) ||
> +        ((offset == PCI_MSI_DATA_32) && !(flags & PCI_MSI_FLAGS_64BIT))) {

This looks like it could be made in a helper function..

> +        *data = reg->init_val;
> +    } else {
> +        *data = PT_INVALID_REG;
> +    }
> +    return 0;
> +}
> +
> +/* write Message Address register */
> +static int pt_msgaddr32_reg_write(XenPCIPassthroughState *s,
> +                                  XenPTReg *cfg_entry, uint32_t *value,
> +                                  uint32_t dev_value, uint32_t valid_mask)
> +{
> +    XenPTRegInfo *reg = cfg_entry->reg;
> +    uint32_t writable_mask = 0;
> +    uint32_t throughable_mask = 0;
> +    uint32_t old_addr = cfg_entry->data;
> +
> +    /* modify emulate register */
> +    writable_mask = reg->emu_mask & ~reg->ro_mask & valid_mask;
> +    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
> +    /* update the msi_info too */
> +    s->msi->addr_lo = cfg_entry->data;
> +
> +    /* create value for writing to I/O device register */
> +    throughable_mask = ~reg->emu_mask & valid_mask;
> +    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
> +
> +    /* update MSI */
> +    if (cfg_entry->data != old_addr) {
> +        if (s->msi->flags & PT_MSI_FLAG_MAPPED) {
> +            pt_msi_update(s);
> +        }
> +    }
> +
> +    return 0;
> +}
> +/* write Message Upper Address register */
> +static int pt_msgaddr64_reg_write(XenPCIPassthroughState *s,
> +                                  XenPTReg *cfg_entry, uint32_t *value,
> +                                  uint32_t dev_value, uint32_t valid_mask)
> +{
> +    XenPTRegInfo *reg = cfg_entry->reg;
> +    uint32_t writable_mask = 0;
> +    uint32_t throughable_mask = 0;
> +    uint32_t old_addr = cfg_entry->data;
> +
> +    /* check whether the type is 64 bit or not */
> +    if (!(s->msi->flags & PCI_MSI_FLAGS_64BIT)) {
> +        PT_ERR(&s->dev, "Write to the Upper Address without 64 bit support\n");

"Can't write to the ..."
> +        return -1;

-ENOSPC?

> +    }
> +
> +    /* modify emulate register */
> +    writable_mask = reg->emu_mask & ~reg->ro_mask & valid_mask;
> +    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
> +    /* update the msi_info too */
> +    s->msi->addr_hi = cfg_entry->data;
> +
> +    /* create value for writing to I/O device register */
> +    throughable_mask = ~reg->emu_mask & valid_mask;
> +    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
> +
> +    /* update MSI */
> +    if (cfg_entry->data != old_addr) {
> +        if (s->msi->flags & PT_MSI_FLAG_MAPPED) {
> +            pt_msi_update(s);
> +        }
> +    }
> +
> +    return 0;
> +}
> +
> +
> +/* this function will be called twice (for 32 bit and 64 bit type) */
> +/* write Message Data register */
> +static int pt_msgdata_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
> +                                uint16_t *value, uint16_t dev_value,
> +                                uint16_t valid_mask)
> +{
> +    XenPTRegInfo *reg = cfg_entry->reg;
> +    uint16_t writable_mask = 0;
> +    uint16_t throughable_mask = 0;
> +    uint16_t old_data = cfg_entry->data;
> +    uint32_t flags = s->msi->flags;
> +    uint32_t offset = reg->offset;
> +
> +    /* check the offset whether matches the type or not */
> +    if (!((offset == PCI_MSI_DATA_64) &&  (flags & PCI_MSI_FLAGS_64BIT)) &&
> +        !((offset == PCI_MSI_DATA_32) && !(flags & PCI_MSI_FLAGS_64BIT))) {
> +        /* exit I/O emulator */
> +        PT_ERR(&s->dev, "the offset does not match the 32/64 bit type!\n");
> +        return -1;

-ENOSPC
> +    }
> +
> +    /* modify emulate register */
> +    writable_mask = reg->emu_mask & ~reg->ro_mask & valid_mask;
> +    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
> +    /* update the msi_info too */
> +    s->msi->data = cfg_entry->data;
> +
> +    /* create value for writing to I/O device register */
> +    throughable_mask = ~reg->emu_mask & valid_mask;
> +    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
> +
> +    /* update MSI */
> +    if (cfg_entry->data != old_data) {
> +        if (flags & PT_MSI_FLAG_MAPPED) {
> +            pt_msi_update(s);
> +        }
> +    }
> +
> +    return 0;
> +}
> +
> +/* MSI Capability Structure reg static infomation table */
> +static XenPTRegInfo pt_emu_reg_msi_tbl[] = {
> +    /* Next Pointer reg */
> +    {
> +        .offset     = PCI_CAP_LIST_NEXT,
> +        .size       = 1,
> +        .init_val   = 0x00,
> +        .ro_mask    = 0xFF,
> +        .emu_mask   = 0xFF,
> +        .init       = pt_ptr_reg_init,
> +        .u.b.read   = pt_byte_reg_read,
> +        .u.b.write  = pt_byte_reg_write,
> +        .u.b.restore  = NULL,
> +    },
> +    /* Message Control reg */
> +    {
> +        .offset     = PCI_MSI_FLAGS,
> +        .size       = 2,
> +        .init_val   = 0x0000,
> +        .ro_mask    = 0xFF8E,
> +        .emu_mask   = 0x007F,
> +        .init       = pt_msgctrl_reg_init,
> +        .u.w.read   = pt_word_reg_read,
> +        .u.w.write  = pt_msgctrl_reg_write,
> +        .u.w.restore  = NULL,
> +    },
> +    /* Message Address reg */
> +    {
> +        .offset     = PCI_MSI_ADDRESS_LO,
> +        .size       = 4,
> +        .init_val   = 0x00000000,
> +        .ro_mask    = 0x00000003,
> +        .emu_mask   = 0xFFFFFFFF,
> +        .no_wb      = 1,
> +        .init       = pt_common_reg_init,
> +        .u.dw.read  = pt_long_reg_read,
> +        .u.dw.write = pt_msgaddr32_reg_write,
> +        .u.dw.restore = NULL,
> +    },
> +    /* Message Upper Address reg (if PCI_MSI_FLAGS_64BIT set) */
> +    {
> +        .offset     = PCI_MSI_ADDRESS_HI,
> +        .size       = 4,
> +        .init_val   = 0x00000000,
> +        .ro_mask    = 0x00000000,
> +        .emu_mask   = 0xFFFFFFFF,
> +        .no_wb      = 1,
> +        .init       = pt_msgaddr64_reg_init,
> +        .u.dw.read  = pt_long_reg_read,
> +        .u.dw.write = pt_msgaddr64_reg_write,
> +        .u.dw.restore = NULL,
> +    },
> +    /* Message Data reg (16 bits of data for 32-bit devices) */
> +    {
> +        .offset     = PCI_MSI_DATA_32,
> +        .size       = 2,
> +        .init_val   = 0x0000,
> +        .ro_mask    = 0x0000,
> +        .emu_mask   = 0xFFFF,
> +        .no_wb      = 1,
> +        .init       = pt_msgdata_reg_init,
> +        .u.w.read   = pt_word_reg_read,
> +        .u.w.write  = pt_msgdata_reg_write,
> +        .u.w.restore  = NULL,
> +    },
> +    /* Message Data reg (16 bits of data for 64-bit devices) */
> +    {
> +        .offset     = PCI_MSI_DATA_64,
> +        .size       = 2,
> +        .init_val   = 0x0000,
> +        .ro_mask    = 0x0000,
> +        .emu_mask   = 0xFFFF,
> +        .no_wb      = 1,
> +        .init       = pt_msgdata_reg_init,
> +        .u.w.read   = pt_word_reg_read,
> +        .u.w.write  = pt_msgdata_reg_write,
> +        .u.w.restore  = NULL,
> +    },
> +    {
> +        .size = 0,
> +    },
> +};
> +
> +
> +/**************************************
> + * MSI-X Capability
> + */
> +
> +/* Message Control register for MSI-X */
> +static int pt_msixctrl_reg_init(XenPCIPassthroughState *s,
> +                                XenPTRegInfo *reg, uint32_t real_offset,
> +                                uint32_t *data)
> +{
> +    PCIDevice *d = &s->dev;
> +    uint16_t reg_field = 0;
> +
> +    /* use I/O device register's value as initial value */
> +    reg_field = pci_get_word(d->config + real_offset);
> +
> +    if (reg_field & PCI_MSIX_FLAGS_ENABLE) {
> +        PT_LOG(d, "MSIX already enabled, disable it first\n");

.. disabling it first..
> +        host_pci_set_word(s->real_device, real_offset,
> +                          reg_field & ~PCI_MSIX_FLAGS_ENABLE);
> +    }
> +
> +    s->msix->ctrl_offset = real_offset;
> +
> +    *data = reg->init_val;
> +    return 0;
> +}
> +static int pt_msixctrl_reg_write(XenPCIPassthroughState *s,
> +                                 XenPTReg *cfg_entry, uint16_t *value,
> +                                 uint16_t dev_value, uint16_t valid_mask)
> +{
> +    XenPTRegInfo *reg = cfg_entry->reg;
> +    uint16_t writable_mask = 0;
> +    uint16_t throughable_mask = 0;
> +
> +    /* modify emulate register */
> +    writable_mask = reg->emu_mask & ~reg->ro_mask & valid_mask;
> +    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
> +
> +    /* create value for writing to I/O device register */
> +    throughable_mask = ~reg->emu_mask & valid_mask;
> +    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
> +
> +    /* update MSI-X */
> +    if ((*value & PCI_MSIX_FLAGS_ENABLE)
> +        && !(*value & PCI_MSIX_FLAGS_MASKALL)) {
> +        if (s->msi_trans_en) {
> +            PT_LOG(&s->dev,
> +                   "guest enabling MSI-X, disable MSI-INTx translation\n");

... disabling
> +            pt_disable_msi_translate(s);
> +        }
> +        pt_msix_update(s);
> +    }
> +
> +    s->msix->enabled = !!(*value & PCI_MSIX_FLAGS_ENABLE);
> +
> +    return 0;
> +}
> +
> +/* MSI-X Capability Structure reg static infomation table */
> +static XenPTRegInfo pt_emu_reg_msix_tbl[] = {
> +    /* Next Pointer reg */
> +    {
> +        .offset     = PCI_CAP_LIST_NEXT,
> +        .size       = 1,
> +        .init_val   = 0x00,
> +        .ro_mask    = 0xFF,
> +        .emu_mask   = 0xFF,
> +        .init       = pt_ptr_reg_init,
> +        .u.b.read   = pt_byte_reg_read,
> +        .u.b.write  = pt_byte_reg_write,
> +        .u.b.restore  = NULL,
> +    },
> +    /* Message Control reg */
> +    {
> +        .offset     = PCI_MSI_FLAGS,
> +        .size       = 2,
> +        .init_val   = 0x0000,
> +        .ro_mask    = 0x3FFF,
> +        .emu_mask   = 0x0000,
> +        .init       = pt_msixctrl_reg_init,
> +        .u.w.read   = pt_word_reg_read,
> +        .u.w.write  = pt_msixctrl_reg_write,
> +        .u.w.restore  = NULL,
> +    },
> +    {
> +        .size = 0,
> +    },
> +};
> +
>  
>  /****************************
>   * Capabilities
> @@ -1709,6 +2134,49 @@ static int pt_pcie_size_init(XenPCIPassthroughState *s,
>      *size = pcie_size;
>      return 0;
>  }
> +/* get MSI Capability Structure register group size */
> +static int pt_msi_size_init(XenPCIPassthroughState *s,
> +                            const XenPTRegGroupInfo *grp_reg,
> +                            uint32_t base_offset, uint8_t *size)
> +{
> +    PCIDevice *d = &s->dev;
> +    uint16_t msg_ctrl = 0;
> +    uint8_t msi_size = 0xa;
> +
> +    msg_ctrl = pci_get_word(d->config + (base_offset + PCI_MSI_FLAGS));
> +
> +    /* check 64 bit address capable & Per-vector masking capable */

.. 'check if 64-bit address is capable of per-vector masking.'

> +    if (msg_ctrl & PCI_MSI_FLAGS_64BIT) {
> +        msi_size += 4;
> +    }
> +    if (msg_ctrl & PCI_MSI_FLAGS_MASKBIT) {
> +        msi_size += 10;
> +    }
> +
> +    s->msi = g_new0(XenPTMSI, 1);
> +    s->msi->pirq = PT_UNASSIGNED_PIRQ;
> +
> +    *size = msi_size;
> +    return 0;
> +}
> +/* get MSI-X Capability Structure register group size */
> +static int pt_msix_size_init(XenPCIPassthroughState *s,
> +                             const XenPTRegGroupInfo *grp_reg,
> +                             uint32_t base_offset, uint8_t *size)
> +{
> +    int rc = 0;
> +
> +    rc = pt_msix_init(s, base_offset);
> +
> +    if (rc == -1) {

if (rc < 0) ..

> +        PT_ERR(&s->dev, "Internal error: Invalid pt_msix_init.\n");
> +        return rc;
> +    }
> +
> +    *size = grp_reg->grp_size;
> +    return 0;
> +}
> +
>  
>  static const XenPTRegGroupInfo pt_emu_reg_grp_tbl[] = {
>      /* Header Type0 reg group */
> @@ -1749,6 +2217,14 @@ static const XenPTRegGroupInfo pt_emu_reg_grp_tbl[] = {
>          .grp_size   = 0x04,
>          .size_init  = pt_reg_grp_size_init,
>      },
> +    /* MSI Capability Structure reg group */
> +    {
> +        .grp_id      = PCI_CAP_ID_MSI,
> +        .grp_type    = GRP_TYPE_EMU,
> +        .grp_size    = 0xFF,
> +        .size_init   = pt_msi_size_init,
> +        .emu_reg_tbl = pt_emu_reg_msi_tbl,
> +    },
>      /* PCI-X Capabilities List Item reg group */
>      {
>          .grp_id     = PCI_CAP_ID_PCIX,
> @@ -1793,6 +2269,14 @@ static const XenPTRegGroupInfo pt_emu_reg_grp_tbl[] = {
>          .size_init   = pt_pcie_size_init,
>          .emu_reg_tbl = pt_emu_reg_pcie_tbl,
>      },
> +    /* MSI-X Capability Structure reg group */
> +    {
> +        .grp_id      = PCI_CAP_ID_MSIX,
> +        .grp_type    = GRP_TYPE_EMU,
> +        .grp_size    = 0x0C,
> +        .size_init   = pt_msix_size_init,
> +        .emu_reg_tbl = pt_emu_reg_msix_tbl,
> +    },
>      {
>          .grp_size = 0,
>      },
> @@ -1965,8 +2449,11 @@ static int pt_init_pci_config(XenPCIPassthroughState *s)
>          return rc;
>      }
>  
> +    /* setup MSI-INTx translation if support */

.. if supported.

> +    rc = pt_enable_msi_translate(s);
> +
>      /* rebind machine_irq to device */
> -    if (s->machine_irq != 0) {
> +    if (rc < 0 && s->machine_irq != 0) {
>          uint8_t e_device = PCI_SLOT(s->dev.devfn);
>          uint8_t e_intx = pci_intx(s);
>  
> @@ -2117,6 +2604,14 @@ void pt_config_delete(XenPCIPassthroughState *s)
>      struct XenPTRegGroup *reg_group, *next_grp;
>      struct XenPTReg *reg, *next_reg;
>  
> +    /* free MSI/MSI-X info table */
> +    if (s->msix) {
> +        pt_msix_delete(s);
> +    }
> +    if (s->msi) {
> +        g_free(s->msi);
> +    }
> +
>      /* free Power Management info table */
>      if (s->pm_state) {
>          if (s->pm_state->pm_timer) {
> diff --git a/hw/xen_pci_passthrough_msi.c b/hw/xen_pci_passthrough_msi.c
> new file mode 100644
> index 0000000..73d3d9b
> --- /dev/null
> +++ b/hw/xen_pci_passthrough_msi.c
> @@ -0,0 +1,678 @@
> +/*
> + * Copyright (c) 2007, Intel Corporation.
> + *
> + * This work is licensed under the terms of the GNU GPL, version 2.  See
> + * the COPYING file in the top-level directory.
> + *
> + * Jiang Yunhong <yunhong.jiang@intel.com>
> + *
> + * This file implements direct PCI assignment to a HVM guest
> + */
> +
> +#include <sys/mman.h>
> +
> +#include "xen_backend.h"
> +#include "xen_pci_passthrough.h"
> +#include "apic-msidef.h"
> +
> +
> +#define AUTO_ASSIGN -1
> +
> +/* shift count for gflags */
> +#define GFLAGS_SHIFT_DEST_ID        0
> +#define GFLAGS_SHIFT_RH             8
> +#define GFLAGS_SHIFT_DM             9
> +#define GLFAGS_SHIFT_DELIV_MODE     12
> +#define GLFAGS_SHIFT_TRG_MODE       15
> +
> +
> +/*
> + * Helpers
> + */
> +
> +static uint32_t get_msi_gflags(uint32_t data, uint64_t addr)
> +{
> +    uint32_t result = 0;
> +    int rh, dm, dest_id, deliv_mode, trig_mode;
> +
> +    rh = (addr >> MSI_ADDR_REDIRECTION_SHIFT) & 0x1;
> +    dm = (addr >> MSI_ADDR_DEST_MODE_SHIFT) & 0x1;
> +    dest_id = (addr >> MSI_ADDR_DEST_ID_SHIFT) & 0xff;
> +    deliv_mode = (data >> MSI_DATA_DELIVERY_MODE_SHIFT) & 0x7;
> +    trig_mode = (data >> MSI_DATA_TRIGGER_SHIFT) & 0x1;
> +
> +    result = dest_id | (rh << GFLAGS_SHIFT_RH) | (dm << GFLAGS_SHIFT_DM) |
> +             (deliv_mode << GLFAGS_SHIFT_DELIV_MODE) |
> +             (trig_mode << GLFAGS_SHIFT_TRG_MODE);
> +
> +    return result;
> +}
> +
> +
> +/*
> + * MSI virtualization functions
> + */
> +
> +void pt_msi_set_enable(XenPCIPassthroughState *s, int en)

Usually these functions that 'enable' something return a value.
Perhaps this function should do that?

> +{
> +    uint16_t val = 0;
> +    uint32_t address = 0;
> +
> +    PT_LOG(&s->dev, "enable: %i\n", en);

Uh, why not: "PT_LOG(&s->dev,"%s.\n", en ? "enabling" : "disabling");

> +
> +    if (!s->msi) {
> +        return;
> +    }
> +
> +    address = s->msi->ctrl_offset;
> +    if (!address) {
> +        return;
> +    }
> +
> +    host_pci_get_word(s->real_device, address, &val);
> +    val &= ~PCI_MSI_FLAGS_ENABLE;
> +    val |= en & PCI_MSI_FLAGS_ENABLE;
> +    host_pci_set_word(s->real_device, address, val);
> +}
> +
> +/* setup physical msi, but don't enable it */
> +int pt_msi_setup(XenPCIPassthroughState *s)
> +{
> +    int pirq = PT_UNASSIGNED_PIRQ;
> +    uint8_t gvec = 0;
> +    int rc = 0;
> +
> +    if (!(s->msi->flags & PT_MSI_FLAG_UNINIT)) {
> +        PT_ERR(&s->dev, "Setup physical MSI when it's already initialized.\n");

Eh? I think you mean "Setup physical MSI when it has been properly
initialized." ?

> +        return -1;
> +    }
> +
> +    gvec = s->msi->data & 0xFF;
> +    if (!gvec) {
> +        /* if gvec is 0, the guest is asking for a particular pirq that
> +         * is passed as dest_id */
> +        pirq = (s->msi->addr_hi & 0xffffff00) |
> +               ((s->msi->addr_lo >> MSI_ADDR_DEST_ID_SHIFT) & 0xff);

Please macrofy this.

> +        if (!pirq) {
> +            /* this probably identifies an misconfiguration of the guest,
> +             * try the emulated path */
> +            pirq = PT_UNASSIGNED_PIRQ;
> +        } else {
> +            PT_LOG(&s->dev, "requested pirq: %d\n", pirq);
> +        }
> +    }
> +
> +    rc = xc_physdev_map_pirq_msi(xen_xc, xen_domid, AUTO_ASSIGN, &pirq,
> +                                 PCI_DEVFN(s->real_device->dev,
> +                                           s->real_device->func),
> +                                 s->real_device->bus, 0, 0);

What are the two '0' at the end for? Can you provide a comment in there?

> +    if (rc) {
> +        PT_ERR(&s->dev, "Mapping of MSI failed. (rc: %d,"
> +               " assigned device: %02x:%02x.%x)\n", rc,
> +               s->real_device->dev, s->real_device->func, s->real_device->bus);

You might want to include the 'pirq' value that was requested.

> +        return -1;
> +    }
> +
> +    if (pirq < 0) {
> +        PT_ERR(&s->dev, "Invalid pirq number.\n");
> +        return -1;
> +    }
> +
> +    s->msi->pirq = pirq;
> +    PT_LOG(&s->dev, "MSI mapped with pirq %d.\n", pirq);
> +
> +    return 0;
> +}
> +
> +int pt_msi_update(XenPCIPassthroughState *s)
> +{
> +    uint8_t gvec = 0;
> +    uint32_t gflags = 0;
> +    uint64_t addr = 0;
> +    int rc = 0;
> +
> +    /* get vector, address, flags info, etc. */
> +    gvec = s->msi->data & 0xFF;
> +    addr = (uint64_t)s->msi->addr_hi << 32 | s->msi->addr_lo;
> +    gflags = get_msi_gflags(s->msi->data, addr);
> +
> +    PT_LOG(&s->dev, "Update MSI with pirq %d gvec 0x%x gflags 0x%x\n",

Updating
> +           s->msi->pirq, gvec, gflags);
> +
> +    rc = xc_domain_update_msi_irq(xen_xc, xen_domid, gvec,
> +                                  s->msi->pirq, gflags, 0);
> +    if (rc) {
> +        PT_ERR(&s->dev, "Binding of MSI failed. (rc: %d)\n", rc);

Not binding.. Updating
> +
> +        if (xc_physdev_unmap_pirq(xen_xc, xen_domid, s->msi->pirq)) {
> +            PT_ERR(&s->dev, "Unmapping of MSI pirq %d failed.\n",
> +                   s->msi->pirq);
> +        }
> +        s->msi->pirq = PT_UNASSIGNED_PIRQ;
> +    }
> +    return rc;
> +}
> +
> +void pt_msi_disable(XenPCIPassthroughState *s)
> +{
> +    PCIDevice *d = &s->dev;
> +    uint8_t gvec = 0;
> +    uint32_t gflags = 0;
> +    uint64_t addr = 0;
> +    uint8_t e_device = 0;
> +    uint8_t e_intx = 0;
> +
> +    pt_msi_set_enable(s, 0);
> +
> +    e_device = PCI_SLOT(d->devfn);
> +    e_intx = pci_intx(s);
> +
> +    if (s->msi_trans_en) {
> +        if (xc_domain_unbind_pt_irq(xen_xc, xen_domid, s->msi->pirq,
> +                                    PT_IRQ_TYPE_MSI_TRANSLATE, 0,
> +                                    e_device, e_intx, 0)) {
> +            PT_ERR(d, "Unbinding pt irq for MSI-INTx failed!\n");

Please include the e_intx and pirq that was being unbinded.

> +            goto out;
> +        }
> +    } else if (!(s->msi->flags & PT_MSI_FLAG_UNINIT)) {
> +        /* get vector, address, flags info, etc. */
> +        gvec = s->msi->data & 0xFF;
> +        addr = (uint64_t)s->msi->addr_hi << 32 | s->msi->addr_lo;
> +        gflags = get_msi_gflags(s->msi->data, addr);
> +
> +        PT_ERR(&s->dev, "Unbind MSI with pirq %x, gvec %x\n",
> +               s->msi->pirq, gvec);
> +
> +        if (xc_domain_unbind_msi_irq(xen_xc, xen_domid, gvec,
> +                                     s->msi->pirq, gflags)) {
> +            PT_ERR(&s->dev, "Unbinding of MSI failed. (pirq: %d)\n",
> +                   s->msi->pirq);
> +            goto out;
> +        }
> +    }
> +
> +    if (s->msi->pirq != PT_UNASSIGNED_PIRQ) {
> +        PT_LOG(&s->dev, "Unmap msi with pirq %d\n", s->msi->pirq);
> +
> +        if (xc_physdev_unmap_pirq(xen_xc, xen_domid, s->msi->pirq)) {
> +            PT_ERR(&s->dev, "Unmapping of MSI failed. (pirq: %d)\n",
> +                   s->msi->pirq);
> +            goto out;
> +        }
> +    }
> +
> +out:
> +    /* clear msi info */
> +    s->msi->flags = 0;
> +    s->msi->pirq = -1;
> +    s->msi_trans_en = 0;
> +}
> +
> +/*
> + * MSI-INTx translation virtualization functions
> + */
> +
> +int pt_enable_msi_translate(XenPCIPassthroughState *s)
> +{
> +    uint8_t e_device = 0;
> +    uint8_t e_intx = 0;
> +
> +    if (!(s->msi && s->msi_trans_cap)) {
> +        return -1;

-ENODEV ?

> +    }
> +
> +    pt_msi_set_enable(s, 0);
> +    s->msi_trans_en = 0;
> +
> +    if (pt_msi_setup(s)) {

You can save the return value from pt_msi_setup..
> +        PT_ERR(&s->dev, "MSI-INTx translation MSI setup failed, fallback\n");

..falling back. But not sure what it is actually falling back to? Just
to normal INTx injecting? If so, you might want to say that.


.. and the return value from pt_msi_setup could be returned here.

> +        return -1;
> +    }
> +
> +    e_device = PCI_SLOT(s->dev.devfn);
> +    /* fix virtual interrupt pin to INTA# */
> +    e_intx = pci_intx(s);
> +
> +    if (xc_domain_bind_pt_irq(xen_xc, xen_domid, s->msi->pirq,
> +                              PT_IRQ_TYPE_MSI_TRANSLATE, 0,
> +                              e_device, e_intx, 0)) {

Please document those '0'.

> +        PT_ERR(&s->dev, "MSI-INTx translation bind failed, fallback\n");
> +
> +        if (xc_physdev_unmap_pirq(xen_xc, xen_domid, s->msi->pirq)) {
> +            PT_ERR(&s->dev, "Unmapping of MSI failed.\n");

Mention which PIRQ failed.

> +        }
> +        s->msi->pirq = PT_UNASSIGNED_PIRQ;
> +        return -1;

You can return the error value returned from xc_domain_bind_pt_irq..
> +    }
> +
> +    pt_msi_set_enable(s, 1);

Should really have pt_msi_set_enable return a value and then check it.

Or do we really don't care about its value? If so, please mention
that in the pt_msi_set_enable.

> +    s->msi_trans_en = 1;
> +
> +    return 0;
> +}
> +
> +void pt_disable_msi_translate(XenPCIPassthroughState *s)
> +{
> +    uint8_t e_device = 0;
> +    uint8_t e_intx = 0;
> +
> +    /* MSI_ENABLE bit should be disabed until the new handler is set */

disabled.

> +    pt_msi_set_enable(s, 0);
> +
> +    e_device = PCI_SLOT(s->dev.devfn);
> +    e_intx = pci_intx(s);
> +
> +    if (xc_domain_unbind_pt_irq(xen_xc, xen_domid, s->msi->pirq,
> +                                PT_IRQ_TYPE_MSI_TRANSLATE, 0,
> +                                e_device, e_intx, 0)) {
> +        PT_ERR(&s->dev, "Unbinding pt irq for MSI-INTx failed!\n");

Can you include the error code please?
> +    }
> +
> +    if (s->machine_irq) {
> +        if (xc_domain_bind_pt_pci_irq(xen_xc, xen_domid, s->machine_irq,
> +                                      0, e_device, e_intx)) {
> +            PT_ERR(&s->dev, "Rebinding of interrupt failed!\n");

And here as well.. And also the machine_irq and e_intx value.

> +        }
> +    }
> +
> +    s->msi_trans_en = 0;
> +}
> +
> +/*
> + * MSI-X virtualization functions
> + */
> +
> +static void msix_set_enable(XenPCIPassthroughState *s, int en)

No return value? The 'int en' can also be a bool.

> +{
> +    uint16_t val = 0;
> +    uint32_t address = 0;
> +
> +    if (!s->msix) {
> +        return;
> +    }
> +
> +    address = s->msix->ctrl_offset;
> +    if (!address) {
> +        return;
> +    }
> +
> +    host_pci_get_word(s->real_device, address, &val);
> +    val &= ~PCI_MSIX_FLAGS_ENABLE;
> +    if (en) {
> +        val |= PCI_MSIX_FLAGS_ENABLE;
> +    }
> +    host_pci_set_word(s->real_device, address, val);
> +}
> +
> +static void mask_physical_msix_entry(XenPCIPassthroughState *s,
> +                                     int entry_nr, int mask)
> +{
> +    void *phys_off;
> +
> +    phys_off = s->msix->phys_iomem_base + 16 * entry_nr + 12;

Can you provide a comment explaining this math please?

> +    *(uint32_t *)phys_off = mask;
> +}
> +
> +static int pt_msix_update_one(XenPCIPassthroughState *s, int entry_nr)
> +{
> +    XenMSIXEntry *entry = &s->msix->msix_entry[entry_nr];

You should be checking whether entry_nr is outside the bounds of
msix_entry just in case.


> +    int pirq = entry->pirq;
> +    int gvec = entry->io_mem[2] & 0xff;
> +    uint64_t gaddr = *(uint64_t *)&entry->io_mem[0];
> +    uint32_t gflags = get_msi_gflags(entry->io_mem[2], gaddr);
> +    int rc;
> +
> +    if (!entry->flags) {
> +        return 0;
> +    }
> +
> +    if (!gvec) {
> +        /* if gvec is 0, the guest is asking for a particular pirq that
> +         * is passed as dest_id */
> +        pirq = ((gaddr >> 32) & 0xffffff00) |
> +               (((gaddr & 0xffffffff) >> MSI_ADDR_DEST_ID_SHIFT) & 0xff);
> +        if (!pirq) {
> +            /* this probably identifies an misconfiguration of the guest,
> +             * try the emulated path */
> +            pirq = PT_UNASSIGNED_PIRQ;
> +        } else {
> +            PT_LOG(&s->dev, "requested pirq: %d\n", pirq);
> +        }
> +    }
> +
> +    /* Check if this entry is already mapped */
> +    if (entry->pirq == PT_UNASSIGNED_PIRQ) {
> +        rc = xc_physdev_map_pirq_msi(xen_xc, xen_domid, AUTO_ASSIGN, &pirq,
> +                                     PCI_DEVFN(s->real_device->dev,
> +                                               s->real_device->func),
> +                                     s->real_device->bus, entry_nr,
> +                                     s->msix->table_base);
> +        if (rc) {
> +            PT_ERR(&s->dev, "Mapping msix entry %x\n", entry_nr);
> +            return rc;
> +        }
> +        entry->pirq = pirq;
> +    }
> +
> +    PT_LOG(&s->dev, "Update msix entry 0x%x with pirq %d gvec 0x%x\n",
> +            entry_nr, pirq, gvec);
> +
> +    rc = xc_domain_update_msi_irq(xen_xc, xen_domid, gvec, pirq, gflags,
> +                                  s->msix->mmio_base_addr);
> +    if (rc) {
> +        PT_ERR(&s->dev, "Updating msix irq %d info for entry %d\n",
> +               pirq, entry_nr);
> +
> +        if (xc_physdev_unmap_pirq(xen_xc, xen_domid, entry->pirq)) {
> +            PT_ERR(&s->dev, "Unmapping of MSI-X failed. (pirq: %d)\n",
> +                   entry->pirq);
> +        }
> +        entry->pirq = PT_UNASSIGNED_PIRQ;
> +        return rc;
> +    }
> +
> +    entry->flags = 0;

This whole function looks so similar to msi one.. Is there no chance of
collapsing them together? And perhaps having an extra argument to check
if it is MSI or MSI-X and where to get the gflags and such.

> +
> +    return 0;
> +}
> +
> +int pt_msix_update(XenPCIPassthroughState *s)
> +{
> +    XenPTMSIX *msix = s->msix;
> +    int i;
> +
> +    for (i = 0; i < msix->total_entries; i++) {
> +        pt_msix_update_one(s, i);
> +    }
> +
> +    return 0;
> +}
> +
> +void pt_msix_disable(XenPCIPassthroughState *s)
> +{
> +    PCIDevice *d = &s->dev;
> +    uint8_t gvec = 0;
> +    uint32_t gflags = 0;
> +    uint64_t addr = 0;
> +    int i = 0;
> +    XenMSIXEntry *entry = NULL;
> +
> +    msix_set_enable(s, 0);
> +
> +    for (i = 0; i < s->msix->total_entries; i++) {
> +        entry = &s->msix->msix_entry[i];
> +
> +        if (entry->pirq == PT_UNASSIGNED_PIRQ) {
> +            continue;
> +        }
> +
> +        gvec = entry->io_mem[2] & 0xff;
> +        addr = *(uint64_t *)&entry->io_mem[0];
> +        gflags = get_msi_gflags(entry->io_mem[2], addr);
> +
> +        PT_LOG(d, "Unbind msix with pirq %d, gvec 0x%x\n",
> +                entry->pirq, gvec);
> +
> +        if (xc_domain_unbind_msi_irq(xen_xc, xen_domid, gvec,
> +                                        entry->pirq, gflags)) {
> +            PT_ERR(d, "Unbinding of MSI-X failed.\n");
> +        } else {
> +            PT_LOG(d, "Unmap msix with pirq %d\n", entry->pirq);
> +
> +            if (xc_physdev_unmap_pirq(xen_xc, xen_domid, entry->pirq)) {
> +                PT_ERR(d, "Unmapping of MSI-X failed.\n");
> +            }
> +        }
> +        /* clear msi-x info */
> +        entry->pirq = PT_UNASSIGNED_PIRQ;
> +        entry->flags = 0;
> +    }

This looks like a candidate for squashing with the MSI as well. If
you can manage to abstract the gflags, addr, etc.

> +}
> +
> +int pt_msix_update_remap(XenPCIPassthroughState *s, int bar_index)
> +{
> +    XenMSIXEntry *entry;
> +    int i, ret;
> +
> +    if (!(s->msix && s->msix->bar_index == bar_index)) {
> +        return 0;
> +    }
> +
> +    for (i = 0; i < s->msix->total_entries; i++) {
> +        entry = &s->msix->msix_entry[i];
> +        if (entry->pirq != PT_UNASSIGNED_PIRQ) {
> +            ret = xc_domain_unbind_pt_irq(xen_xc, xen_domid, entry->pirq,
> +                                          PT_IRQ_TYPE_MSI, 0, 0, 0, 0);

Lots of zeros. Can you document those please?

> +            if (ret) {
> +                PT_ERR(&s->dev, "unbind MSI-X entry %d failed\n", entry->pirq);
> +            }
> +            entry->flags = 1;

Could use a #define for the '1' value.

> +        }
> +    }
> +    pt_msix_update(s);
> +
> +    return 0;
> +}
> +
> +static void pci_msix_invalid_write(void *opaque, target_phys_addr_t addr,
> +                                   uint32_t val)
> +{
> +    XenPCIPassthroughState *s = opaque;
> +    PT_ERR(&s->dev, "Invalid write to MSI-X table,"
> +           " only dword access is allowed.\n");
> +}
> +
> +static void pci_msix_writel(void *opaque, target_phys_addr_t addr,
> +                            uint32_t val)
> +{
> +    XenPCIPassthroughState *s = opaque;
> +    XenPTMSIX *msix = s->msix;
> +    XenMSIXEntry *entry;
> +    int entry_nr, offset;
> +    void *phys_off;
> +    uint32_t vec_ctrl;
> +
> +    if (addr % 4) {
> +        PT_ERR(&s->dev, "Unaligned dword access to MSI-X table, "
> +                "addr 0x"TARGET_FMT_plx"\n", addr);
> +        return;
> +    }
> +
> +    entry_nr = addr / 16;
> +    entry = &msix->msix_entry[entry_nr];

You should double-check that that entry_nr is actually allocated.

> +    offset = (addr % 16) / 4;
> +
> +    /*
> +     * If Xen intercepts the mask bit access, io_mem[3] may not be
> +     * up-to-date. Read from hardware directly.
> +     */
> +    phys_off = s->msix->phys_iomem_base + 16 * entry_nr + 12;
> +    vec_ctrl = *(uint32_t *)phys_off;
> +
> +    if (offset != 3 && msix->enabled && !(vec_ctrl & 0x1)) {
> +        PT_ERR(&s->dev, "Can't update msix entry %d since MSI-X is already "
> +                "enabled.\n", entry_nr);

Well, and a whole bunch of other things are set. Would it make sense to
provide 'offset' and 'vec_ctrl' contents?

> +        return;
> +    }
> +
> +    if (offset != 3 && entry->io_mem[offset] != val) {

What is the magical '3' value? Can you document it a bit please? Perhaps
along with the io_mem[x] definition?

> +        entry->flags = 1;
> +    }
> +    entry->io_mem[offset] = val;
> +
> +    if (offset == 3) {
> +        if (msix->enabled && !(val & 0x1)) {
> +            pt_msix_update_one(s, entry_nr);
> +        }
> +        mask_physical_msix_entry(s, entry_nr, entry->io_mem[3] & 0x1);
> +    }
> +}
> +
> +static CPUWriteMemoryFunc *pci_msix_write[] = {
> +    pci_msix_invalid_write,
> +    pci_msix_invalid_write,
> +    pci_msix_writel
> +};
> +
> +static uint32_t pci_msix_invalid_read(void *opaque, target_phys_addr_t addr)
> +{
> +    XenPCIPassthroughState *s = opaque;
> +    PT_ERR(&s->dev, "Invalid read to MSI-X table,"
> +           " only dword access is allowed.\n");
> +    return 0;
> +}
> +
> +static uint32_t pci_msix_readl(void *opaque, target_phys_addr_t addr)
> +{
> +    XenPCIPassthroughState *s = opaque;
> +    XenPTMSIX *msix = s->msix;
> +    int entry_nr, offset;
> +
> +    if (addr % 4) {
> +        PT_ERR(&s->dev, "Unaligned dword access to MSI-X table, "
> +                "addr 0x"TARGET_FMT_plx"\n", addr);
> +        return 0;
> +    }
> +
> +    entry_nr = addr / 16;
> +    offset = (addr % 16) / 4;
> +
> +    return msix->msix_entry[entry_nr].io_mem[offset];
> +}
> +
> +static CPUReadMemoryFunc *pci_msix_read[] = {
> +    pci_msix_invalid_read,
> +    pci_msix_invalid_read,
> +    pci_msix_readl
> +};
> +
> +int pt_add_msix_mapping(XenPCIPassthroughState *s, int bar_index)
> +{
> +    if (!(s->msix && s->msix->bar_index == bar_index)) {
> +        return 0;
> +    }
> +
> +    return xc_domain_memory_mapping(xen_xc, xen_domid,
> +         s->msix->mmio_base_addr >> XC_PAGE_SHIFT,
> +         (s->bases[bar_index].access.maddr + s->msix->table_off)
> +             >> XC_PAGE_SHIFT,
> +         (s->msix->total_entries * 16 + XC_PAGE_SIZE - 1) >> XC_PAGE_SHIFT,
> +         DPCI_ADD_MAPPING);
> +}
> +
> +int pt_remove_msix_mapping(XenPCIPassthroughState *s, int bar_index)
> +{
> +    if (!(s->msix && s->msix->bar_index == bar_index)) {
> +        return 0;
> +    }
> +
> +    s->msix->mmio_base_addr = s->bases[bar_index].e_physbase
> +        + s->msix->table_off;
> +
> +    cpu_register_physical_memory(s->msix->mmio_base_addr,
> +                                 s->msix->total_entries * 16,
> +                                 s->msix->mmio_index);
> +
> +    return xc_domain_memory_mapping(xen_xc, xen_domid,
> +         s->msix->mmio_base_addr >> XC_PAGE_SHIFT,
> +         (s->bases[bar_index].access.maddr + s->msix->table_off)
> +             >> XC_PAGE_SHIFT,
> +         (s->msix->total_entries * 16 + XC_PAGE_SIZE - 1) >> XC_PAGE_SHIFT,
> +         DPCI_REMOVE_MAPPING);
> +}
> +
> +int pt_msix_init(XenPCIPassthroughState *s, int base)
> +{
> +    uint8_t id = 0;
> +    uint16_t control = 0;
> +    uint32_t table_off = 0;
> +    int i, total_entries, bar_index;
> +    HostPCIDevice *d = s->real_device;
> +    int fd;
> +
> +    if (host_pci_get_byte(d, base + PCI_CAP_LIST_ID, &id)) {
> +        return -1;

-ENOSPC?

> +    }
> +
> +    if (id != PCI_CAP_ID_MSIX) {
> +        PT_ERR(&s->dev, "Invalid id %#x base %#x\n", id, base);
> +        return -1;
> +    }
> +
> +    host_pci_get_word(d, base + 2, &control);
> +    total_entries = control & 0x7ff;
> +    total_entries += 1;
> +
> +    s->msix = g_malloc0(sizeof (XenPTMSIX)
> +                        + total_entries * sizeof (XenMSIXEntry));
> +
> +    s->msix->total_entries = total_entries;
> +    for (i = 0; i < total_entries; i++) {
> +        s->msix->msix_entry[i].pirq = PT_UNASSIGNED_PIRQ;
> +    }
> +
> +    s->msix->mmio_index =
> +        cpu_register_io_memory(pci_msix_read, pci_msix_write,
> +                               s, DEVICE_NATIVE_ENDIAN);
> +
> +    host_pci_get_long(d, base + PCI_MSIX_TABLE, &table_off);
> +    bar_index = s->msix->bar_index = table_off & PCI_MSIX_FLAGS_BIRMASK;
> +    table_off = s->msix->table_off = table_off & ~PCI_MSIX_FLAGS_BIRMASK;
> +    s->msix->table_base = s->real_device->io_regions[bar_index].base_addr;
> +    PT_LOG(&s->dev, "get MSI-X table BAR base 0x%"PRIx64"\n",
> +           s->msix->table_base);

Can you also include the amount of entries it can have?
> +
> +    fd = open("/dev/mem", O_RDWR);
> +    if (fd == -1) {
> +        PT_ERR(&s->dev, "Can't open /dev/mem: %s\n", strerror(errno));
> +        goto error_out;
> +    }
> +    PT_LOG(&s->dev, "table_off = %#x, total_entries = %d\n",
> +           table_off, total_entries);
> +    s->msix->table_offset_adjust = table_off & 0x0fff;
> +    s->msix->phys_iomem_base =
> +        mmap(0,
> +             total_entries * 16 + s->msix->table_offset_adjust,
> +             PROT_WRITE | PROT_READ,
> +             MAP_SHARED | MAP_LOCKED,
> +             fd,
> +             s->msix->table_base + table_off - s->msix->table_offset_adjust);
> +
> +    if (s->msix->phys_iomem_base == MAP_FAILED) {
> +        PT_ERR(&s->dev, "Can't map physical MSI-X table: %s\n",
> +               strerror(errno));
> +        close(fd);
> +        goto error_out;
> +    }
> +    s->msix->phys_iomem_base = (char *)s->msix->phys_iomem_base
> +        + s->msix->table_offset_adjust;
> +
> +    close(fd);
> +
> +    PT_LOG(&s->dev, "mapping physical MSI-X table to %p\n",
> +           s->msix->phys_iomem_base);
> +    return 0;
> +
> +error_out:
> +    g_free(s->msix);
> +    s->msix = NULL;
> +    return -1;
> +}
> +
> +void pt_msix_delete(XenPCIPassthroughState *s)
> +{
> +    /* unmap the MSI-X memory mapped register area */
> +    if (s->msix->phys_iomem_base) {
> +        PT_LOG(&s->dev, "unmapping physical MSI-X table from %p\n",
> +           s->msix->phys_iomem_base);
> +        munmap(s->msix->phys_iomem_base, s->msix->total_entries * 16 +
> +           s->msix->table_offset_adjust);
> +    }
> +
> +    if (s->msix->mmio_index > 0) {
> +        cpu_unregister_io_memory(s->msix->mmio_index);
> +    }
> +
> +    g_free(s->msix);
> +    s->msix = NULL;
> +}
> -- 
> Anthony PERARD
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 00:04:15 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 00:04:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXiVX-0005Ca-Nt; Tue, 06 Dec 2011 00:03:39 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1RXiVV-0005CV-5x
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 00:03:37 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-5.tower-27.messagelabs.com!1323129735!45522561!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14307 invoked from network); 6 Dec 2011 00:02:17 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-5.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 6 Dec 2011 00:02:17 -0000
Received: from andromeda.dapyr.net (darnok@localhost [127.0.0.1])
	by andromeda.dapyr.net (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id
	pB602eeY020107
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Mon, 5 Dec 2011 19:02:40 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pB602eMw020105;
	Mon, 5 Dec 2011 19:02:40 -0500
Date: Mon, 5 Dec 2011 20:02:40 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Anthony PERARD <anthony.perard@citrix.com>
Message-ID: <20111206000240.GA15873@andromeda.dapyr.net>
References: <1322156679-9441-1-git-send-email-anthony.perard@citrix.com>
	<1322156679-9441-11-git-send-email-anthony.perard@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1322156679-9441-11-git-send-email-anthony.perard@citrix.com>
User-Agent: Mutt/1.5.9i
Cc: Xen Devel <xen-devel@lists.xensource.com>,
	Jiang Yunhong <yunhong.jiang@intel.com>,
	Shan Haitao <haitao.shan@intel.com>, QEMU-devel <qemu-devel@nongnu.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH V5 10/10] Introduce Xen PCI Passthrough,
	MSI (3/3)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Nov 24, 2011 at 05:44:39PM +0000, Anthony PERARD wrote:
> From: Jiang Yunhong <yunhong.jiang@intel.com>
> 
> A more complete history can be found here:
> git://xenbits.xensource.com/qemu-xen-unstable.git
> 
> Signed-off-by: Jiang Yunhong <yunhong.jiang@intel.com>
> Signed-off-by: Shan Haitao <haitao.shan@intel.com>
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> ---
>  Makefile.target                      |    1 +
>  hw/apic-msidef.h                     |    2 +
>  hw/xen_pci_passthrough.c             |   60 +++-
>  hw/xen_pci_passthrough.h             |   55 +++
>  hw/xen_pci_passthrough_config_init.c |  505 +++++++++++++++++++++++++-
>  hw/xen_pci_passthrough_msi.c         |  678 ++++++++++++++++++++++++++++++++++
>  6 files changed, 1294 insertions(+), 7 deletions(-)
>  create mode 100644 hw/xen_pci_passthrough_msi.c
> 
> diff --git a/Makefile.target b/Makefile.target
> index 33435a3..81cff70 100644
> --- a/Makefile.target
> +++ b/Makefile.target
> @@ -223,6 +223,7 @@ obj-i386-$(CONFIG_XEN) += xen_platform.o
>  obj-i386-$(CONFIG_XEN_PCI_PASSTHROUGH) += host-pci-device.o
>  obj-i386-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen_pci_passthrough.o
>  obj-i386-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen_pci_passthrough_config_init.o
> +obj-i386-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen_pci_passthrough_msi.o
>  
>  # Inter-VM PCI shared memory
>  CONFIG_IVSHMEM =
> diff --git a/hw/apic-msidef.h b/hw/apic-msidef.h
> index 3182f0b..6e2eb71 100644
> --- a/hw/apic-msidef.h
> +++ b/hw/apic-msidef.h
> @@ -22,6 +22,8 @@
>  
>  #define MSI_ADDR_DEST_MODE_SHIFT        2
>  
> +#define MSI_ADDR_REDIRECTION_SHIFT      3
> +
>  #define MSI_ADDR_DEST_ID_SHIFT          12
>  #define  MSI_ADDR_DEST_ID_MASK          0x00ffff0
>  
> diff --git a/hw/xen_pci_passthrough.c b/hw/xen_pci_passthrough.c
> index c816ed5..cd7e3c7 100644
> --- a/hw/xen_pci_passthrough.c
> +++ b/hw/xen_pci_passthrough.c
> @@ -38,6 +38,39 @@
>   *     Write '1'
>   *       <ptdev->msi_trans_en is false>
>   *         - Set real bit to '1'.
> + *
> + * MSI-INTx translation.
> + *   Initialize(xc_physdev_map_pirq_msi/pt_msi_setup)
> + *     Bind MSI-INTx(xc_domain_bind_pt_irq)
> + *       <fail>
> + *         - Unmap MSI.
> + *           <success>
> + *             - Set dev->msi->pirq to '-1'.
> + *           <fail>
> + *             - Do nothing.
> + *
> + *   Write to Interrupt Disable bit by guest software(pt_cmd_reg_write)
> + *     Write '0'
> + *       <ptdev->msi_trans_en is true>
> + *         - Set MSI Enable bit to '1'.
> + *
> + *     Write '1'
> + *       <ptdev->msi_trans_en is true>
> + *         - Set MSI Enable bit to '0'.
> + *
> + * MSI interrupt:
> + *   Initialize MSI register(pt_msi_setup, pt_msi_update)
> + *     Bind MSI(xc_domain_update_msi_irq)
> + *       <fail>
> + *         - Unmap MSI.
> + *         - Set dev->msi->pirq to '-1'.
> + *
> + * MSI-X interrupt:
> + *   Initialize MSI-X register(pt_msix_update_one)
> + *     Bind MSI-X(xc_domain_update_msi_irq)
> + *       <fail>
> + *         - Unmap MSI-X.
> + *         - Set entry->pirq to '-1'.
>   */
>  
>  #include <sys/ioctl.h>
> @@ -389,6 +422,7 @@ static void pt_iomem_map(XenPCIPassthroughState *s, int i,
>      }
>  
>      if (!first_map && old_ebase != PT_PCI_BAR_UNMAPPED) {
> +        pt_add_msix_mapping(s, i);
>          /* Remove old mapping */
>          memory_region_del_subregion(r->address_space,
>                                      r->memory);
> @@ -417,6 +451,15 @@ static void pt_iomem_map(XenPCIPassthroughState *s, int i,
>          if (ret != 0) {
>              PT_ERR(&s->dev, "create new mapping failed!\n");
>          }
> +
> +        ret = pt_remove_msix_mapping(s, i);
> +        if (ret != 0) {
> +            PT_ERR(&s->dev, "Remove MSI-X MMIO mapping failed!\n");
> +        }
> +
> +        if (old_ebase != e_phys && old_ebase != -1) {
> +            pt_msix_update_remap(s, i);
> +        }
>      }
>  }
>  
> @@ -744,6 +787,9 @@ static int pt_initfn(PCIDevice *pcidev)
>          mapped_machine_irq[machine_irq]++;
>      }
>  
> +    /* setup MSI-INTx translation if support */
> +    rc = pt_enable_msi_translate(s);
> +
>      /* bind machine_irq to device */
>      if (rc < 0 && machine_irq != 0) {
>          uint8_t e_device = PCI_SLOT(s->dev.devfn);
> @@ -773,7 +819,8 @@ static int pt_initfn(PCIDevice *pcidev)
>  
>  out:
>      PT_LOG(pcidev, "Real physical device %02x:%02x.%x registered successfuly!"
> -           "\nIRQ type = %s\n", bus, slot, func, "INTx");
> +           "\nIRQ type = %s\n", bus, slot, func,
> +           s->msi_trans_en ? "MSI-INTx" : "INTx");
>  
>      return 0;
>  }
> @@ -790,7 +837,7 @@ static int pt_unregister_device(PCIDevice *pcidev)
>      e_intx = pci_intx(s);
>      machine_irq = s->machine_irq;
>  
> -    if (machine_irq) {
> +    if (s->msi_trans_en == 0 && machine_irq) {

It is defined as 'bool' so you could do !s->msi_trans_en instead?

>          rc = xc_domain_unbind_pt_irq(xen_xc, xen_domid, machine_irq,
>                                       PT_IRQ_TYPE_PCI, 0, e_device, e_intx, 0);
>          if (rc < 0) {
> @@ -798,6 +845,13 @@ static int pt_unregister_device(PCIDevice *pcidev)
>          }
>      }
>  
> +    if (s->msi) {
> +        pt_msi_disable(s);
> +    }
> +    if (s->msix) {
> +        pt_msix_disable(s);
> +    }
> +
>      if (machine_irq) {
>          mapped_machine_irq[machine_irq]--;
>  
> @@ -832,6 +886,8 @@ static PCIDeviceInfo xen_pci_passthrough = {
>      .is_express = 0,
>      .qdev.props = (Property[]) {
>          DEFINE_PROP_STRING("hostaddr", XenPCIPassthroughState, hostaddr),
> +        DEFINE_PROP_BIT("msitranslate", XenPCIPassthroughState, msi_trans_cap,
> +                        0, true),
>          DEFINE_PROP_BIT("power-mgmt", XenPCIPassthroughState, power_mgmt,
>                          0, false),
>          DEFINE_PROP_END_OF_LIST(),
> diff --git a/hw/xen_pci_passthrough.h b/hw/xen_pci_passthrough.h
> index 110325c..acbbab5 100644
> --- a/hw/xen_pci_passthrough.h
> +++ b/hw/xen_pci_passthrough.h
> @@ -74,6 +74,10 @@ typedef int (*conf_byte_restore)
>  #define PT_PCI_BAR_UNMAPPED (-1)
>  #define PT_UNASSIGNED_PIRQ (-1)
>  
> +/* MSI-X */
> +#define PT_MSI_FLAG_UNINIT 0x1000
> +#define PT_MSI_FLAG_MAPPED 0x2000


Can you explain what those two defines do please?

> +
>  
>  typedef enum {
>      GRP_TYPE_HARDWIRED = 0,                     /* 0 Hardwired reg group */
> @@ -177,6 +181,34 @@ typedef struct XenPTRegGroup {
>  } XenPTRegGroup;
>  
>  
> +typedef struct XenPTMSI {
> +    uint32_t flags;
> +    uint32_t ctrl_offset; /* saved control offset */
> +    int pirq;          /* guest pirq corresponding */
> +    uint32_t addr_lo;  /* guest message address */
> +    uint32_t addr_hi;  /* guest message upper address */
> +    uint16_t data;     /* guest message data */
> +} XenPTMSI;
> +
> +typedef struct XenMSIXEntry {
> +    int pirq;        /* -1 means unmapped */
> +    int flags;       /* flags indicting whether MSI ADDR or DATA is updated */
> +    uint32_t io_mem[4];

Can you document what is in each position? Perhaps some enums or
#defines for them?

> +} XenMSIXEntry;
> +typedef struct XenPTMSIX {
> +    uint32_t ctrl_offset;
> +    int enabled;
> +    int total_entries;
> +    int bar_index;
> +    uint64_t table_base;
> +    uint32_t table_off;
> +    uint32_t table_offset_adjust; /* page align mmap */
> +    uint64_t mmio_base_addr;
> +    int mmio_index;
> +    void *phys_iomem_base;
> +    XenMSIXEntry msix_entry[0];
> +} XenPTMSIX;
> +
>  typedef struct XenPTPM {
>      QEMUTimer *pm_timer;  /* QEMUTimer struct */
>      int no_soft_reset;    /* No Soft Reset flags */
> @@ -200,6 +232,13 @@ struct XenPCIPassthroughState {
>  
>      uint32_t machine_irq;
>  
> +    XenPTMSI *msi;
> +    XenPTMSIX *msix;
> +
> +    /* Physical MSI to guest INTx translation when possible */

Meaning that the MSI vector is going to show up as INTx in the guest?

This is by default enabled, right? At least that is what
txt/misc/vtd.txt

tells me. So would it be better than to have 'msi_trans_off' as flag
as by default we would enable it? So would it be better than to have
'msi_trans_off' as flag?

> +    uint32_t msi_trans_cap;
> +    bool msi_trans_en;
> +
>      uint32_t power_mgmt;
>      XenPTPM *pm_state;
>  
> @@ -279,4 +318,20 @@ static inline uint8_t pci_intx(XenPCIPassthroughState *s)
>      return r_val;
>  }
>  
> +/* MSI/MSI-X */
> +void pt_msi_set_enable(XenPCIPassthroughState *s, int en);

You could make it a bool. So "bool en" instead?
> +int pt_msi_setup(XenPCIPassthroughState *s);
> +int pt_msi_update(XenPCIPassthroughState *d);
> +void pt_msi_disable(XenPCIPassthroughState *s);
> +int pt_enable_msi_translate(XenPCIPassthroughState *s);
> +void pt_disable_msi_translate(XenPCIPassthroughState *s);
> +
> +int pt_msix_init(XenPCIPassthroughState *s, int pos);

uint32_t as pos?
> +void pt_msix_delete(XenPCIPassthroughState *s);
> +int pt_msix_update(XenPCIPassthroughState *s);
> +int pt_msix_update_remap(XenPCIPassthroughState *s, int bar_index);

uint32_t as bar_index?
> +void pt_msix_disable(XenPCIPassthroughState *s);
> +int pt_add_msix_mapping(XenPCIPassthroughState *s, int bar_index);
> +int pt_remove_msix_mapping(XenPCIPassthroughState *s, int bar_index);
> +
>  #endif /* !QEMU_HW_XEN_PCI_PASSTHROUGH_H */
> diff --git a/hw/xen_pci_passthrough_config_init.c b/hw/xen_pci_passthrough_config_init.c
> index ae64544..28523f1 100644
> --- a/hw/xen_pci_passthrough_config_init.c
> +++ b/hw/xen_pci_passthrough_config_init.c
> @@ -398,11 +398,19 @@ static int pt_cmd_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
>      throughable_mask = ~emu_mask & valid_mask;
>  
>      if (*value & PCI_COMMAND_INTX_DISABLE) {
> -        throughable_mask |= PCI_COMMAND_INTX_DISABLE;
> -    } else {
> -        if (s->machine_irq) {
> +        if (s->msi_trans_en) {
> +            pt_msi_set_enable(s, 0);

Can you put a comment explaining the '0' argument?
> +        } else {
>              throughable_mask |= PCI_COMMAND_INTX_DISABLE;
>          }
> +    } else {
> +        if (s->msi_trans_en) {
> +            pt_msi_set_enable(s, 1);
> +        } else {
> +            if (s->machine_irq) {
> +                throughable_mask |= PCI_COMMAND_INTX_DISABLE;
> +            }
> +        }
>      }
>  
>      *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
> @@ -1282,13 +1290,21 @@ static void pt_reset_interrupt_and_io_mapping(XenPCIPassthroughState *s)
>      e_device = PCI_SLOT(s->dev.devfn);
>      e_intx = pci_intx(s);
>  
> -    if (s->machine_irq) {
> +    if (s->msi_trans_en == 0 && s->machine_irq) {
>          if (xc_domain_unbind_pt_irq(xen_xc, xen_domid, s->machine_irq,
>                                      PT_IRQ_TYPE_PCI, 0, e_device, e_intx, 0)) {
>              PT_ERR(d, "Unbinding of interrupt failed!\n");
>          }
>      }
>  
> +    /* disable MSI/MSI-X and MSI-INTx translation */
> +    if (s->msi) {
> +        pt_msi_disable(s);
> +    }
> +    if (s->msix) {
> +        pt_msix_disable(s);
> +    }
> +
>      /* clear all virtual region address */
>      for (i = 0; i < PCI_NUM_REGIONS; i++) {
>          r = &d->io_regions[i];
> @@ -1536,6 +1552,415 @@ static XenPTRegInfo pt_emu_reg_pm_tbl[] = {
>      },
>  };
>  
> +/********************************
> + * MSI Capability
> + */
> +
> +/* Message Control register */
> +static int pt_msgctrl_reg_init(XenPCIPassthroughState *s,
> +                               XenPTRegInfo *reg, uint32_t real_offset,
> +                               uint32_t *data)
> +{
> +    PCIDevice *d = &s->dev;
> +    uint16_t reg_field = 0;
> +
> +    /* use I/O device register's value as initial value */
> +    reg_field = pci_get_word(d->config + real_offset);

There is no 'pci_get_halfword' operations?

> +
> +    if (reg_field & PCI_MSI_FLAGS_ENABLE) {
> +        PT_LOG(&s->dev, "MSI already enabled, disable it first\n");

.. "disabling it first."

> +        host_pci_set_word(s->real_device, real_offset,
> +                          reg_field & ~PCI_MSI_FLAGS_ENABLE);
> +    }
> +    s->msi->flags |= reg_field | PT_MSI_FLAG_UNINIT;

There is no chance that you PT_MSI_FLAG_UNINIT would shadow what
is in the register? You are reading a word after all.. ah, the
reg_field is a 16-bit, so you are populating the unused fields.
Perhaps you could use bit-fields?


> +    s->msi->ctrl_offset = real_offset;
> +
> +    *data = reg->init_val;
> +    return 0;
> +}
> +static int pt_msgctrl_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
> +                                uint16_t *value, uint16_t dev_value,
> +                                uint16_t valid_mask)
> +{
> +    XenPTRegInfo *reg = cfg_entry->reg;
> +    uint16_t writable_mask = 0;
> +    uint16_t throughable_mask = 0;
> +    uint16_t val;
> +
> +    /* Currently no support for multi-vector */
> +    if (*value & PCI_MSI_FLAGS_QSIZE) {
> +        PT_WARN(&s->dev, "try to set more than 1 vector ctrl %x\n", *value);


But no return -ENOSPC?

The message should probably read: "Tries to set more.."
> +    }
> +
> +    /* modify emulate register */
> +    writable_mask = reg->emu_mask & ~reg->ro_mask & valid_mask;
> +    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
> +    /* update the msi_info too */

err, msi_info -> msi->flags?

> +    s->msi->flags |= cfg_entry->data &
> +        ~(PT_MSI_FLAG_UNINIT | PT_MSI_FLAG_MAPPED | PCI_MSI_FLAGS_ENABLE);
> +
> +    /* create value for writing to I/O device register */
> +    val = *value;
> +    throughable_mask = ~reg->emu_mask & valid_mask;
> +    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
> +
> +    /* update MSI */
> +    if (val & PCI_MSI_FLAGS_ENABLE) {
> +        /* setup MSI pirq for the first time */
> +        if (s->msi->flags & PT_MSI_FLAG_UNINIT) {
> +            if (s->msi_trans_en) {
> +                PT_LOG(&s->dev,
> +                       "guest enabling MSI, disable MSI-INTx translation\n");
> +                pt_disable_msi_translate(s);
> +            } else {
> +                /* Init physical one */
> +                PT_LOG(&s->dev, "setup MSI\n");
> +                if (pt_msi_setup(s)) {
> +                    /* We do not broadcast the error to the framework code, so
> +                     * that MSI errors are contained in MSI emulation code and
> +                     * QEMU can go on running.
> +                     * Guest MSI would be actually not working.

Not sure if the last sentence is needed?

> +                     */
> +                    *value &= ~PCI_MSI_FLAGS_ENABLE;
> +                    PT_WARN(&s->dev, "Can not map MSI.\n");
> +                    return 0;
> +                }
> +            }
> +            if (pt_msi_update(s)) {
> +                *value &= ~PCI_MSI_FLAGS_ENABLE;
> +                PT_WARN(&s->dev, "Can not bind MSI\n");
> +                return 0;
> +            }
> +            s->msi->flags &= ~PT_MSI_FLAG_UNINIT;
> +            s->msi->flags |= PT_MSI_FLAG_MAPPED;
> +        }
> +        s->msi->flags |= PCI_MSI_FLAGS_ENABLE;
> +    } else {
> +        s->msi->flags &= ~PCI_MSI_FLAGS_ENABLE;
> +    }
> +
> +    /* pass through MSI_ENABLE bit when no MSI-INTx translation */
                                          ^- "there is"


> +    if (!s->msi_trans_en) {
> +        *value &= ~PCI_MSI_FLAGS_ENABLE;
> +        *value |= val & PCI_MSI_FLAGS_ENABLE;
> +    }
> +
> +    return 0;
> +}
> +
> +/* initialize Message Upper Address register */
> +static int pt_msgaddr64_reg_init(XenPCIPassthroughState *ptdev,
> +                                 XenPTRegInfo *reg, uint32_t real_offset,
> +                                 uint32_t *data)
> +{
> +    /* no need to initialize in case of 32 bit type */
> +    if (!(ptdev->msi->flags & PCI_MSI_FLAGS_64BIT)) {
> +        *data = PT_INVALID_REG;
> +    } else {
> +        *data = reg->init_val;
> +    }
> +
> +    return 0;
> +}
> +/* this function will be called twice (for 32 bit and 64 bit type) */
> +/* initialize Message Data register */
> +static int pt_msgdata_reg_init(XenPCIPassthroughState *ptdev,
> +                               XenPTRegInfo *reg, uint32_t real_offset,
> +                               uint32_t *data)
> +{
> +    uint32_t flags = ptdev->msi->flags;
> +    uint32_t offset = reg->offset;
> +
> +    /* check the offset whether matches the type or not */
> +    if (((offset == PCI_MSI_DATA_64) &&  (flags & PCI_MSI_FLAGS_64BIT)) ||
> +        ((offset == PCI_MSI_DATA_32) && !(flags & PCI_MSI_FLAGS_64BIT))) {

This looks like it could be made in a helper function..

> +        *data = reg->init_val;
> +    } else {
> +        *data = PT_INVALID_REG;
> +    }
> +    return 0;
> +}
> +
> +/* write Message Address register */
> +static int pt_msgaddr32_reg_write(XenPCIPassthroughState *s,
> +                                  XenPTReg *cfg_entry, uint32_t *value,
> +                                  uint32_t dev_value, uint32_t valid_mask)
> +{
> +    XenPTRegInfo *reg = cfg_entry->reg;
> +    uint32_t writable_mask = 0;
> +    uint32_t throughable_mask = 0;
> +    uint32_t old_addr = cfg_entry->data;
> +
> +    /* modify emulate register */
> +    writable_mask = reg->emu_mask & ~reg->ro_mask & valid_mask;
> +    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
> +    /* update the msi_info too */
> +    s->msi->addr_lo = cfg_entry->data;
> +
> +    /* create value for writing to I/O device register */
> +    throughable_mask = ~reg->emu_mask & valid_mask;
> +    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
> +
> +    /* update MSI */
> +    if (cfg_entry->data != old_addr) {
> +        if (s->msi->flags & PT_MSI_FLAG_MAPPED) {
> +            pt_msi_update(s);
> +        }
> +    }
> +
> +    return 0;
> +}
> +/* write Message Upper Address register */
> +static int pt_msgaddr64_reg_write(XenPCIPassthroughState *s,
> +                                  XenPTReg *cfg_entry, uint32_t *value,
> +                                  uint32_t dev_value, uint32_t valid_mask)
> +{
> +    XenPTRegInfo *reg = cfg_entry->reg;
> +    uint32_t writable_mask = 0;
> +    uint32_t throughable_mask = 0;
> +    uint32_t old_addr = cfg_entry->data;
> +
> +    /* check whether the type is 64 bit or not */
> +    if (!(s->msi->flags & PCI_MSI_FLAGS_64BIT)) {
> +        PT_ERR(&s->dev, "Write to the Upper Address without 64 bit support\n");

"Can't write to the ..."
> +        return -1;

-ENOSPC?

> +    }
> +
> +    /* modify emulate register */
> +    writable_mask = reg->emu_mask & ~reg->ro_mask & valid_mask;
> +    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
> +    /* update the msi_info too */
> +    s->msi->addr_hi = cfg_entry->data;
> +
> +    /* create value for writing to I/O device register */
> +    throughable_mask = ~reg->emu_mask & valid_mask;
> +    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
> +
> +    /* update MSI */
> +    if (cfg_entry->data != old_addr) {
> +        if (s->msi->flags & PT_MSI_FLAG_MAPPED) {
> +            pt_msi_update(s);
> +        }
> +    }
> +
> +    return 0;
> +}
> +
> +
> +/* this function will be called twice (for 32 bit and 64 bit type) */
> +/* write Message Data register */
> +static int pt_msgdata_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
> +                                uint16_t *value, uint16_t dev_value,
> +                                uint16_t valid_mask)
> +{
> +    XenPTRegInfo *reg = cfg_entry->reg;
> +    uint16_t writable_mask = 0;
> +    uint16_t throughable_mask = 0;
> +    uint16_t old_data = cfg_entry->data;
> +    uint32_t flags = s->msi->flags;
> +    uint32_t offset = reg->offset;
> +
> +    /* check the offset whether matches the type or not */
> +    if (!((offset == PCI_MSI_DATA_64) &&  (flags & PCI_MSI_FLAGS_64BIT)) &&
> +        !((offset == PCI_MSI_DATA_32) && !(flags & PCI_MSI_FLAGS_64BIT))) {
> +        /* exit I/O emulator */
> +        PT_ERR(&s->dev, "the offset does not match the 32/64 bit type!\n");
> +        return -1;

-ENOSPC
> +    }
> +
> +    /* modify emulate register */
> +    writable_mask = reg->emu_mask & ~reg->ro_mask & valid_mask;
> +    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
> +    /* update the msi_info too */
> +    s->msi->data = cfg_entry->data;
> +
> +    /* create value for writing to I/O device register */
> +    throughable_mask = ~reg->emu_mask & valid_mask;
> +    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
> +
> +    /* update MSI */
> +    if (cfg_entry->data != old_data) {
> +        if (flags & PT_MSI_FLAG_MAPPED) {
> +            pt_msi_update(s);
> +        }
> +    }
> +
> +    return 0;
> +}
> +
> +/* MSI Capability Structure reg static infomation table */
> +static XenPTRegInfo pt_emu_reg_msi_tbl[] = {
> +    /* Next Pointer reg */
> +    {
> +        .offset     = PCI_CAP_LIST_NEXT,
> +        .size       = 1,
> +        .init_val   = 0x00,
> +        .ro_mask    = 0xFF,
> +        .emu_mask   = 0xFF,
> +        .init       = pt_ptr_reg_init,
> +        .u.b.read   = pt_byte_reg_read,
> +        .u.b.write  = pt_byte_reg_write,
> +        .u.b.restore  = NULL,
> +    },
> +    /* Message Control reg */
> +    {
> +        .offset     = PCI_MSI_FLAGS,
> +        .size       = 2,
> +        .init_val   = 0x0000,
> +        .ro_mask    = 0xFF8E,
> +        .emu_mask   = 0x007F,
> +        .init       = pt_msgctrl_reg_init,
> +        .u.w.read   = pt_word_reg_read,
> +        .u.w.write  = pt_msgctrl_reg_write,
> +        .u.w.restore  = NULL,
> +    },
> +    /* Message Address reg */
> +    {
> +        .offset     = PCI_MSI_ADDRESS_LO,
> +        .size       = 4,
> +        .init_val   = 0x00000000,
> +        .ro_mask    = 0x00000003,
> +        .emu_mask   = 0xFFFFFFFF,
> +        .no_wb      = 1,
> +        .init       = pt_common_reg_init,
> +        .u.dw.read  = pt_long_reg_read,
> +        .u.dw.write = pt_msgaddr32_reg_write,
> +        .u.dw.restore = NULL,
> +    },
> +    /* Message Upper Address reg (if PCI_MSI_FLAGS_64BIT set) */
> +    {
> +        .offset     = PCI_MSI_ADDRESS_HI,
> +        .size       = 4,
> +        .init_val   = 0x00000000,
> +        .ro_mask    = 0x00000000,
> +        .emu_mask   = 0xFFFFFFFF,
> +        .no_wb      = 1,
> +        .init       = pt_msgaddr64_reg_init,
> +        .u.dw.read  = pt_long_reg_read,
> +        .u.dw.write = pt_msgaddr64_reg_write,
> +        .u.dw.restore = NULL,
> +    },
> +    /* Message Data reg (16 bits of data for 32-bit devices) */
> +    {
> +        .offset     = PCI_MSI_DATA_32,
> +        .size       = 2,
> +        .init_val   = 0x0000,
> +        .ro_mask    = 0x0000,
> +        .emu_mask   = 0xFFFF,
> +        .no_wb      = 1,
> +        .init       = pt_msgdata_reg_init,
> +        .u.w.read   = pt_word_reg_read,
> +        .u.w.write  = pt_msgdata_reg_write,
> +        .u.w.restore  = NULL,
> +    },
> +    /* Message Data reg (16 bits of data for 64-bit devices) */
> +    {
> +        .offset     = PCI_MSI_DATA_64,
> +        .size       = 2,
> +        .init_val   = 0x0000,
> +        .ro_mask    = 0x0000,
> +        .emu_mask   = 0xFFFF,
> +        .no_wb      = 1,
> +        .init       = pt_msgdata_reg_init,
> +        .u.w.read   = pt_word_reg_read,
> +        .u.w.write  = pt_msgdata_reg_write,
> +        .u.w.restore  = NULL,
> +    },
> +    {
> +        .size = 0,
> +    },
> +};
> +
> +
> +/**************************************
> + * MSI-X Capability
> + */
> +
> +/* Message Control register for MSI-X */
> +static int pt_msixctrl_reg_init(XenPCIPassthroughState *s,
> +                                XenPTRegInfo *reg, uint32_t real_offset,
> +                                uint32_t *data)
> +{
> +    PCIDevice *d = &s->dev;
> +    uint16_t reg_field = 0;
> +
> +    /* use I/O device register's value as initial value */
> +    reg_field = pci_get_word(d->config + real_offset);
> +
> +    if (reg_field & PCI_MSIX_FLAGS_ENABLE) {
> +        PT_LOG(d, "MSIX already enabled, disable it first\n");

.. disabling it first..
> +        host_pci_set_word(s->real_device, real_offset,
> +                          reg_field & ~PCI_MSIX_FLAGS_ENABLE);
> +    }
> +
> +    s->msix->ctrl_offset = real_offset;
> +
> +    *data = reg->init_val;
> +    return 0;
> +}
> +static int pt_msixctrl_reg_write(XenPCIPassthroughState *s,
> +                                 XenPTReg *cfg_entry, uint16_t *value,
> +                                 uint16_t dev_value, uint16_t valid_mask)
> +{
> +    XenPTRegInfo *reg = cfg_entry->reg;
> +    uint16_t writable_mask = 0;
> +    uint16_t throughable_mask = 0;
> +
> +    /* modify emulate register */
> +    writable_mask = reg->emu_mask & ~reg->ro_mask & valid_mask;
> +    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
> +
> +    /* create value for writing to I/O device register */
> +    throughable_mask = ~reg->emu_mask & valid_mask;
> +    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
> +
> +    /* update MSI-X */
> +    if ((*value & PCI_MSIX_FLAGS_ENABLE)
> +        && !(*value & PCI_MSIX_FLAGS_MASKALL)) {
> +        if (s->msi_trans_en) {
> +            PT_LOG(&s->dev,
> +                   "guest enabling MSI-X, disable MSI-INTx translation\n");

... disabling
> +            pt_disable_msi_translate(s);
> +        }
> +        pt_msix_update(s);
> +    }
> +
> +    s->msix->enabled = !!(*value & PCI_MSIX_FLAGS_ENABLE);
> +
> +    return 0;
> +}
> +
> +/* MSI-X Capability Structure reg static infomation table */
> +static XenPTRegInfo pt_emu_reg_msix_tbl[] = {
> +    /* Next Pointer reg */
> +    {
> +        .offset     = PCI_CAP_LIST_NEXT,
> +        .size       = 1,
> +        .init_val   = 0x00,
> +        .ro_mask    = 0xFF,
> +        .emu_mask   = 0xFF,
> +        .init       = pt_ptr_reg_init,
> +        .u.b.read   = pt_byte_reg_read,
> +        .u.b.write  = pt_byte_reg_write,
> +        .u.b.restore  = NULL,
> +    },
> +    /* Message Control reg */
> +    {
> +        .offset     = PCI_MSI_FLAGS,
> +        .size       = 2,
> +        .init_val   = 0x0000,
> +        .ro_mask    = 0x3FFF,
> +        .emu_mask   = 0x0000,
> +        .init       = pt_msixctrl_reg_init,
> +        .u.w.read   = pt_word_reg_read,
> +        .u.w.write  = pt_msixctrl_reg_write,
> +        .u.w.restore  = NULL,
> +    },
> +    {
> +        .size = 0,
> +    },
> +};
> +
>  
>  /****************************
>   * Capabilities
> @@ -1709,6 +2134,49 @@ static int pt_pcie_size_init(XenPCIPassthroughState *s,
>      *size = pcie_size;
>      return 0;
>  }
> +/* get MSI Capability Structure register group size */
> +static int pt_msi_size_init(XenPCIPassthroughState *s,
> +                            const XenPTRegGroupInfo *grp_reg,
> +                            uint32_t base_offset, uint8_t *size)
> +{
> +    PCIDevice *d = &s->dev;
> +    uint16_t msg_ctrl = 0;
> +    uint8_t msi_size = 0xa;
> +
> +    msg_ctrl = pci_get_word(d->config + (base_offset + PCI_MSI_FLAGS));
> +
> +    /* check 64 bit address capable & Per-vector masking capable */

.. 'check if 64-bit address is capable of per-vector masking.'

> +    if (msg_ctrl & PCI_MSI_FLAGS_64BIT) {
> +        msi_size += 4;
> +    }
> +    if (msg_ctrl & PCI_MSI_FLAGS_MASKBIT) {
> +        msi_size += 10;
> +    }
> +
> +    s->msi = g_new0(XenPTMSI, 1);
> +    s->msi->pirq = PT_UNASSIGNED_PIRQ;
> +
> +    *size = msi_size;
> +    return 0;
> +}
> +/* get MSI-X Capability Structure register group size */
> +static int pt_msix_size_init(XenPCIPassthroughState *s,
> +                             const XenPTRegGroupInfo *grp_reg,
> +                             uint32_t base_offset, uint8_t *size)
> +{
> +    int rc = 0;
> +
> +    rc = pt_msix_init(s, base_offset);
> +
> +    if (rc == -1) {

if (rc < 0) ..

> +        PT_ERR(&s->dev, "Internal error: Invalid pt_msix_init.\n");
> +        return rc;
> +    }
> +
> +    *size = grp_reg->grp_size;
> +    return 0;
> +}
> +
>  
>  static const XenPTRegGroupInfo pt_emu_reg_grp_tbl[] = {
>      /* Header Type0 reg group */
> @@ -1749,6 +2217,14 @@ static const XenPTRegGroupInfo pt_emu_reg_grp_tbl[] = {
>          .grp_size   = 0x04,
>          .size_init  = pt_reg_grp_size_init,
>      },
> +    /* MSI Capability Structure reg group */
> +    {
> +        .grp_id      = PCI_CAP_ID_MSI,
> +        .grp_type    = GRP_TYPE_EMU,
> +        .grp_size    = 0xFF,
> +        .size_init   = pt_msi_size_init,
> +        .emu_reg_tbl = pt_emu_reg_msi_tbl,
> +    },
>      /* PCI-X Capabilities List Item reg group */
>      {
>          .grp_id     = PCI_CAP_ID_PCIX,
> @@ -1793,6 +2269,14 @@ static const XenPTRegGroupInfo pt_emu_reg_grp_tbl[] = {
>          .size_init   = pt_pcie_size_init,
>          .emu_reg_tbl = pt_emu_reg_pcie_tbl,
>      },
> +    /* MSI-X Capability Structure reg group */
> +    {
> +        .grp_id      = PCI_CAP_ID_MSIX,
> +        .grp_type    = GRP_TYPE_EMU,
> +        .grp_size    = 0x0C,
> +        .size_init   = pt_msix_size_init,
> +        .emu_reg_tbl = pt_emu_reg_msix_tbl,
> +    },
>      {
>          .grp_size = 0,
>      },
> @@ -1965,8 +2449,11 @@ static int pt_init_pci_config(XenPCIPassthroughState *s)
>          return rc;
>      }
>  
> +    /* setup MSI-INTx translation if support */

.. if supported.

> +    rc = pt_enable_msi_translate(s);
> +
>      /* rebind machine_irq to device */
> -    if (s->machine_irq != 0) {
> +    if (rc < 0 && s->machine_irq != 0) {
>          uint8_t e_device = PCI_SLOT(s->dev.devfn);
>          uint8_t e_intx = pci_intx(s);
>  
> @@ -2117,6 +2604,14 @@ void pt_config_delete(XenPCIPassthroughState *s)
>      struct XenPTRegGroup *reg_group, *next_grp;
>      struct XenPTReg *reg, *next_reg;
>  
> +    /* free MSI/MSI-X info table */
> +    if (s->msix) {
> +        pt_msix_delete(s);
> +    }
> +    if (s->msi) {
> +        g_free(s->msi);
> +    }
> +
>      /* free Power Management info table */
>      if (s->pm_state) {
>          if (s->pm_state->pm_timer) {
> diff --git a/hw/xen_pci_passthrough_msi.c b/hw/xen_pci_passthrough_msi.c
> new file mode 100644
> index 0000000..73d3d9b
> --- /dev/null
> +++ b/hw/xen_pci_passthrough_msi.c
> @@ -0,0 +1,678 @@
> +/*
> + * Copyright (c) 2007, Intel Corporation.
> + *
> + * This work is licensed under the terms of the GNU GPL, version 2.  See
> + * the COPYING file in the top-level directory.
> + *
> + * Jiang Yunhong <yunhong.jiang@intel.com>
> + *
> + * This file implements direct PCI assignment to a HVM guest
> + */
> +
> +#include <sys/mman.h>
> +
> +#include "xen_backend.h"
> +#include "xen_pci_passthrough.h"
> +#include "apic-msidef.h"
> +
> +
> +#define AUTO_ASSIGN -1
> +
> +/* shift count for gflags */
> +#define GFLAGS_SHIFT_DEST_ID        0
> +#define GFLAGS_SHIFT_RH             8
> +#define GFLAGS_SHIFT_DM             9
> +#define GLFAGS_SHIFT_DELIV_MODE     12
> +#define GLFAGS_SHIFT_TRG_MODE       15
> +
> +
> +/*
> + * Helpers
> + */
> +
> +static uint32_t get_msi_gflags(uint32_t data, uint64_t addr)
> +{
> +    uint32_t result = 0;
> +    int rh, dm, dest_id, deliv_mode, trig_mode;
> +
> +    rh = (addr >> MSI_ADDR_REDIRECTION_SHIFT) & 0x1;
> +    dm = (addr >> MSI_ADDR_DEST_MODE_SHIFT) & 0x1;
> +    dest_id = (addr >> MSI_ADDR_DEST_ID_SHIFT) & 0xff;
> +    deliv_mode = (data >> MSI_DATA_DELIVERY_MODE_SHIFT) & 0x7;
> +    trig_mode = (data >> MSI_DATA_TRIGGER_SHIFT) & 0x1;
> +
> +    result = dest_id | (rh << GFLAGS_SHIFT_RH) | (dm << GFLAGS_SHIFT_DM) |
> +             (deliv_mode << GLFAGS_SHIFT_DELIV_MODE) |
> +             (trig_mode << GLFAGS_SHIFT_TRG_MODE);
> +
> +    return result;
> +}
> +
> +
> +/*
> + * MSI virtualization functions
> + */
> +
> +void pt_msi_set_enable(XenPCIPassthroughState *s, int en)

Usually these functions that 'enable' something return a value.
Perhaps this function should do that?

> +{
> +    uint16_t val = 0;
> +    uint32_t address = 0;
> +
> +    PT_LOG(&s->dev, "enable: %i\n", en);

Uh, why not: "PT_LOG(&s->dev,"%s.\n", en ? "enabling" : "disabling");

> +
> +    if (!s->msi) {
> +        return;
> +    }
> +
> +    address = s->msi->ctrl_offset;
> +    if (!address) {
> +        return;
> +    }
> +
> +    host_pci_get_word(s->real_device, address, &val);
> +    val &= ~PCI_MSI_FLAGS_ENABLE;
> +    val |= en & PCI_MSI_FLAGS_ENABLE;
> +    host_pci_set_word(s->real_device, address, val);
> +}
> +
> +/* setup physical msi, but don't enable it */
> +int pt_msi_setup(XenPCIPassthroughState *s)
> +{
> +    int pirq = PT_UNASSIGNED_PIRQ;
> +    uint8_t gvec = 0;
> +    int rc = 0;
> +
> +    if (!(s->msi->flags & PT_MSI_FLAG_UNINIT)) {
> +        PT_ERR(&s->dev, "Setup physical MSI when it's already initialized.\n");

Eh? I think you mean "Setup physical MSI when it has been properly
initialized." ?

> +        return -1;
> +    }
> +
> +    gvec = s->msi->data & 0xFF;
> +    if (!gvec) {
> +        /* if gvec is 0, the guest is asking for a particular pirq that
> +         * is passed as dest_id */
> +        pirq = (s->msi->addr_hi & 0xffffff00) |
> +               ((s->msi->addr_lo >> MSI_ADDR_DEST_ID_SHIFT) & 0xff);

Please macrofy this.

> +        if (!pirq) {
> +            /* this probably identifies an misconfiguration of the guest,
> +             * try the emulated path */
> +            pirq = PT_UNASSIGNED_PIRQ;
> +        } else {
> +            PT_LOG(&s->dev, "requested pirq: %d\n", pirq);
> +        }
> +    }
> +
> +    rc = xc_physdev_map_pirq_msi(xen_xc, xen_domid, AUTO_ASSIGN, &pirq,
> +                                 PCI_DEVFN(s->real_device->dev,
> +                                           s->real_device->func),
> +                                 s->real_device->bus, 0, 0);

What are the two '0' at the end for? Can you provide a comment in there?

> +    if (rc) {
> +        PT_ERR(&s->dev, "Mapping of MSI failed. (rc: %d,"
> +               " assigned device: %02x:%02x.%x)\n", rc,
> +               s->real_device->dev, s->real_device->func, s->real_device->bus);

You might want to include the 'pirq' value that was requested.

> +        return -1;
> +    }
> +
> +    if (pirq < 0) {
> +        PT_ERR(&s->dev, "Invalid pirq number.\n");
> +        return -1;
> +    }
> +
> +    s->msi->pirq = pirq;
> +    PT_LOG(&s->dev, "MSI mapped with pirq %d.\n", pirq);
> +
> +    return 0;
> +}
> +
> +int pt_msi_update(XenPCIPassthroughState *s)
> +{
> +    uint8_t gvec = 0;
> +    uint32_t gflags = 0;
> +    uint64_t addr = 0;
> +    int rc = 0;
> +
> +    /* get vector, address, flags info, etc. */
> +    gvec = s->msi->data & 0xFF;
> +    addr = (uint64_t)s->msi->addr_hi << 32 | s->msi->addr_lo;
> +    gflags = get_msi_gflags(s->msi->data, addr);
> +
> +    PT_LOG(&s->dev, "Update MSI with pirq %d gvec 0x%x gflags 0x%x\n",

Updating
> +           s->msi->pirq, gvec, gflags);
> +
> +    rc = xc_domain_update_msi_irq(xen_xc, xen_domid, gvec,
> +                                  s->msi->pirq, gflags, 0);
> +    if (rc) {
> +        PT_ERR(&s->dev, "Binding of MSI failed. (rc: %d)\n", rc);

Not binding.. Updating
> +
> +        if (xc_physdev_unmap_pirq(xen_xc, xen_domid, s->msi->pirq)) {
> +            PT_ERR(&s->dev, "Unmapping of MSI pirq %d failed.\n",
> +                   s->msi->pirq);
> +        }
> +        s->msi->pirq = PT_UNASSIGNED_PIRQ;
> +    }
> +    return rc;
> +}
> +
> +void pt_msi_disable(XenPCIPassthroughState *s)
> +{
> +    PCIDevice *d = &s->dev;
> +    uint8_t gvec = 0;
> +    uint32_t gflags = 0;
> +    uint64_t addr = 0;
> +    uint8_t e_device = 0;
> +    uint8_t e_intx = 0;
> +
> +    pt_msi_set_enable(s, 0);
> +
> +    e_device = PCI_SLOT(d->devfn);
> +    e_intx = pci_intx(s);
> +
> +    if (s->msi_trans_en) {
> +        if (xc_domain_unbind_pt_irq(xen_xc, xen_domid, s->msi->pirq,
> +                                    PT_IRQ_TYPE_MSI_TRANSLATE, 0,
> +                                    e_device, e_intx, 0)) {
> +            PT_ERR(d, "Unbinding pt irq for MSI-INTx failed!\n");

Please include the e_intx and pirq that was being unbinded.

> +            goto out;
> +        }
> +    } else if (!(s->msi->flags & PT_MSI_FLAG_UNINIT)) {
> +        /* get vector, address, flags info, etc. */
> +        gvec = s->msi->data & 0xFF;
> +        addr = (uint64_t)s->msi->addr_hi << 32 | s->msi->addr_lo;
> +        gflags = get_msi_gflags(s->msi->data, addr);
> +
> +        PT_ERR(&s->dev, "Unbind MSI with pirq %x, gvec %x\n",
> +               s->msi->pirq, gvec);
> +
> +        if (xc_domain_unbind_msi_irq(xen_xc, xen_domid, gvec,
> +                                     s->msi->pirq, gflags)) {
> +            PT_ERR(&s->dev, "Unbinding of MSI failed. (pirq: %d)\n",
> +                   s->msi->pirq);
> +            goto out;
> +        }
> +    }
> +
> +    if (s->msi->pirq != PT_UNASSIGNED_PIRQ) {
> +        PT_LOG(&s->dev, "Unmap msi with pirq %d\n", s->msi->pirq);
> +
> +        if (xc_physdev_unmap_pirq(xen_xc, xen_domid, s->msi->pirq)) {
> +            PT_ERR(&s->dev, "Unmapping of MSI failed. (pirq: %d)\n",
> +                   s->msi->pirq);
> +            goto out;
> +        }
> +    }
> +
> +out:
> +    /* clear msi info */
> +    s->msi->flags = 0;
> +    s->msi->pirq = -1;
> +    s->msi_trans_en = 0;
> +}
> +
> +/*
> + * MSI-INTx translation virtualization functions
> + */
> +
> +int pt_enable_msi_translate(XenPCIPassthroughState *s)
> +{
> +    uint8_t e_device = 0;
> +    uint8_t e_intx = 0;
> +
> +    if (!(s->msi && s->msi_trans_cap)) {
> +        return -1;

-ENODEV ?

> +    }
> +
> +    pt_msi_set_enable(s, 0);
> +    s->msi_trans_en = 0;
> +
> +    if (pt_msi_setup(s)) {

You can save the return value from pt_msi_setup..
> +        PT_ERR(&s->dev, "MSI-INTx translation MSI setup failed, fallback\n");

..falling back. But not sure what it is actually falling back to? Just
to normal INTx injecting? If so, you might want to say that.


.. and the return value from pt_msi_setup could be returned here.

> +        return -1;
> +    }
> +
> +    e_device = PCI_SLOT(s->dev.devfn);
> +    /* fix virtual interrupt pin to INTA# */
> +    e_intx = pci_intx(s);
> +
> +    if (xc_domain_bind_pt_irq(xen_xc, xen_domid, s->msi->pirq,
> +                              PT_IRQ_TYPE_MSI_TRANSLATE, 0,
> +                              e_device, e_intx, 0)) {

Please document those '0'.

> +        PT_ERR(&s->dev, "MSI-INTx translation bind failed, fallback\n");
> +
> +        if (xc_physdev_unmap_pirq(xen_xc, xen_domid, s->msi->pirq)) {
> +            PT_ERR(&s->dev, "Unmapping of MSI failed.\n");

Mention which PIRQ failed.

> +        }
> +        s->msi->pirq = PT_UNASSIGNED_PIRQ;
> +        return -1;

You can return the error value returned from xc_domain_bind_pt_irq..
> +    }
> +
> +    pt_msi_set_enable(s, 1);

Should really have pt_msi_set_enable return a value and then check it.

Or do we really don't care about its value? If so, please mention
that in the pt_msi_set_enable.

> +    s->msi_trans_en = 1;
> +
> +    return 0;
> +}
> +
> +void pt_disable_msi_translate(XenPCIPassthroughState *s)
> +{
> +    uint8_t e_device = 0;
> +    uint8_t e_intx = 0;
> +
> +    /* MSI_ENABLE bit should be disabed until the new handler is set */

disabled.

> +    pt_msi_set_enable(s, 0);
> +
> +    e_device = PCI_SLOT(s->dev.devfn);
> +    e_intx = pci_intx(s);
> +
> +    if (xc_domain_unbind_pt_irq(xen_xc, xen_domid, s->msi->pirq,
> +                                PT_IRQ_TYPE_MSI_TRANSLATE, 0,
> +                                e_device, e_intx, 0)) {
> +        PT_ERR(&s->dev, "Unbinding pt irq for MSI-INTx failed!\n");

Can you include the error code please?
> +    }
> +
> +    if (s->machine_irq) {
> +        if (xc_domain_bind_pt_pci_irq(xen_xc, xen_domid, s->machine_irq,
> +                                      0, e_device, e_intx)) {
> +            PT_ERR(&s->dev, "Rebinding of interrupt failed!\n");

And here as well.. And also the machine_irq and e_intx value.

> +        }
> +    }
> +
> +    s->msi_trans_en = 0;
> +}
> +
> +/*
> + * MSI-X virtualization functions
> + */
> +
> +static void msix_set_enable(XenPCIPassthroughState *s, int en)

No return value? The 'int en' can also be a bool.

> +{
> +    uint16_t val = 0;
> +    uint32_t address = 0;
> +
> +    if (!s->msix) {
> +        return;
> +    }
> +
> +    address = s->msix->ctrl_offset;
> +    if (!address) {
> +        return;
> +    }
> +
> +    host_pci_get_word(s->real_device, address, &val);
> +    val &= ~PCI_MSIX_FLAGS_ENABLE;
> +    if (en) {
> +        val |= PCI_MSIX_FLAGS_ENABLE;
> +    }
> +    host_pci_set_word(s->real_device, address, val);
> +}
> +
> +static void mask_physical_msix_entry(XenPCIPassthroughState *s,
> +                                     int entry_nr, int mask)
> +{
> +    void *phys_off;
> +
> +    phys_off = s->msix->phys_iomem_base + 16 * entry_nr + 12;

Can you provide a comment explaining this math please?

> +    *(uint32_t *)phys_off = mask;
> +}
> +
> +static int pt_msix_update_one(XenPCIPassthroughState *s, int entry_nr)
> +{
> +    XenMSIXEntry *entry = &s->msix->msix_entry[entry_nr];

You should be checking whether entry_nr is outside the bounds of
msix_entry just in case.


> +    int pirq = entry->pirq;
> +    int gvec = entry->io_mem[2] & 0xff;
> +    uint64_t gaddr = *(uint64_t *)&entry->io_mem[0];
> +    uint32_t gflags = get_msi_gflags(entry->io_mem[2], gaddr);
> +    int rc;
> +
> +    if (!entry->flags) {
> +        return 0;
> +    }
> +
> +    if (!gvec) {
> +        /* if gvec is 0, the guest is asking for a particular pirq that
> +         * is passed as dest_id */
> +        pirq = ((gaddr >> 32) & 0xffffff00) |
> +               (((gaddr & 0xffffffff) >> MSI_ADDR_DEST_ID_SHIFT) & 0xff);
> +        if (!pirq) {
> +            /* this probably identifies an misconfiguration of the guest,
> +             * try the emulated path */
> +            pirq = PT_UNASSIGNED_PIRQ;
> +        } else {
> +            PT_LOG(&s->dev, "requested pirq: %d\n", pirq);
> +        }
> +    }
> +
> +    /* Check if this entry is already mapped */
> +    if (entry->pirq == PT_UNASSIGNED_PIRQ) {
> +        rc = xc_physdev_map_pirq_msi(xen_xc, xen_domid, AUTO_ASSIGN, &pirq,
> +                                     PCI_DEVFN(s->real_device->dev,
> +                                               s->real_device->func),
> +                                     s->real_device->bus, entry_nr,
> +                                     s->msix->table_base);
> +        if (rc) {
> +            PT_ERR(&s->dev, "Mapping msix entry %x\n", entry_nr);
> +            return rc;
> +        }
> +        entry->pirq = pirq;
> +    }
> +
> +    PT_LOG(&s->dev, "Update msix entry 0x%x with pirq %d gvec 0x%x\n",
> +            entry_nr, pirq, gvec);
> +
> +    rc = xc_domain_update_msi_irq(xen_xc, xen_domid, gvec, pirq, gflags,
> +                                  s->msix->mmio_base_addr);
> +    if (rc) {
> +        PT_ERR(&s->dev, "Updating msix irq %d info for entry %d\n",
> +               pirq, entry_nr);
> +
> +        if (xc_physdev_unmap_pirq(xen_xc, xen_domid, entry->pirq)) {
> +            PT_ERR(&s->dev, "Unmapping of MSI-X failed. (pirq: %d)\n",
> +                   entry->pirq);
> +        }
> +        entry->pirq = PT_UNASSIGNED_PIRQ;
> +        return rc;
> +    }
> +
> +    entry->flags = 0;

This whole function looks so similar to msi one.. Is there no chance of
collapsing them together? And perhaps having an extra argument to check
if it is MSI or MSI-X and where to get the gflags and such.

> +
> +    return 0;
> +}
> +
> +int pt_msix_update(XenPCIPassthroughState *s)
> +{
> +    XenPTMSIX *msix = s->msix;
> +    int i;
> +
> +    for (i = 0; i < msix->total_entries; i++) {
> +        pt_msix_update_one(s, i);
> +    }
> +
> +    return 0;
> +}
> +
> +void pt_msix_disable(XenPCIPassthroughState *s)
> +{
> +    PCIDevice *d = &s->dev;
> +    uint8_t gvec = 0;
> +    uint32_t gflags = 0;
> +    uint64_t addr = 0;
> +    int i = 0;
> +    XenMSIXEntry *entry = NULL;
> +
> +    msix_set_enable(s, 0);
> +
> +    for (i = 0; i < s->msix->total_entries; i++) {
> +        entry = &s->msix->msix_entry[i];
> +
> +        if (entry->pirq == PT_UNASSIGNED_PIRQ) {
> +            continue;
> +        }
> +
> +        gvec = entry->io_mem[2] & 0xff;
> +        addr = *(uint64_t *)&entry->io_mem[0];
> +        gflags = get_msi_gflags(entry->io_mem[2], addr);
> +
> +        PT_LOG(d, "Unbind msix with pirq %d, gvec 0x%x\n",
> +                entry->pirq, gvec);
> +
> +        if (xc_domain_unbind_msi_irq(xen_xc, xen_domid, gvec,
> +                                        entry->pirq, gflags)) {
> +            PT_ERR(d, "Unbinding of MSI-X failed.\n");
> +        } else {
> +            PT_LOG(d, "Unmap msix with pirq %d\n", entry->pirq);
> +
> +            if (xc_physdev_unmap_pirq(xen_xc, xen_domid, entry->pirq)) {
> +                PT_ERR(d, "Unmapping of MSI-X failed.\n");
> +            }
> +        }
> +        /* clear msi-x info */
> +        entry->pirq = PT_UNASSIGNED_PIRQ;
> +        entry->flags = 0;
> +    }

This looks like a candidate for squashing with the MSI as well. If
you can manage to abstract the gflags, addr, etc.

> +}
> +
> +int pt_msix_update_remap(XenPCIPassthroughState *s, int bar_index)
> +{
> +    XenMSIXEntry *entry;
> +    int i, ret;
> +
> +    if (!(s->msix && s->msix->bar_index == bar_index)) {
> +        return 0;
> +    }
> +
> +    for (i = 0; i < s->msix->total_entries; i++) {
> +        entry = &s->msix->msix_entry[i];
> +        if (entry->pirq != PT_UNASSIGNED_PIRQ) {
> +            ret = xc_domain_unbind_pt_irq(xen_xc, xen_domid, entry->pirq,
> +                                          PT_IRQ_TYPE_MSI, 0, 0, 0, 0);

Lots of zeros. Can you document those please?

> +            if (ret) {
> +                PT_ERR(&s->dev, "unbind MSI-X entry %d failed\n", entry->pirq);
> +            }
> +            entry->flags = 1;

Could use a #define for the '1' value.

> +        }
> +    }
> +    pt_msix_update(s);
> +
> +    return 0;
> +}
> +
> +static void pci_msix_invalid_write(void *opaque, target_phys_addr_t addr,
> +                                   uint32_t val)
> +{
> +    XenPCIPassthroughState *s = opaque;
> +    PT_ERR(&s->dev, "Invalid write to MSI-X table,"
> +           " only dword access is allowed.\n");
> +}
> +
> +static void pci_msix_writel(void *opaque, target_phys_addr_t addr,
> +                            uint32_t val)
> +{
> +    XenPCIPassthroughState *s = opaque;
> +    XenPTMSIX *msix = s->msix;
> +    XenMSIXEntry *entry;
> +    int entry_nr, offset;
> +    void *phys_off;
> +    uint32_t vec_ctrl;
> +
> +    if (addr % 4) {
> +        PT_ERR(&s->dev, "Unaligned dword access to MSI-X table, "
> +                "addr 0x"TARGET_FMT_plx"\n", addr);
> +        return;
> +    }
> +
> +    entry_nr = addr / 16;
> +    entry = &msix->msix_entry[entry_nr];

You should double-check that that entry_nr is actually allocated.

> +    offset = (addr % 16) / 4;
> +
> +    /*
> +     * If Xen intercepts the mask bit access, io_mem[3] may not be
> +     * up-to-date. Read from hardware directly.
> +     */
> +    phys_off = s->msix->phys_iomem_base + 16 * entry_nr + 12;
> +    vec_ctrl = *(uint32_t *)phys_off;
> +
> +    if (offset != 3 && msix->enabled && !(vec_ctrl & 0x1)) {
> +        PT_ERR(&s->dev, "Can't update msix entry %d since MSI-X is already "
> +                "enabled.\n", entry_nr);

Well, and a whole bunch of other things are set. Would it make sense to
provide 'offset' and 'vec_ctrl' contents?

> +        return;
> +    }
> +
> +    if (offset != 3 && entry->io_mem[offset] != val) {

What is the magical '3' value? Can you document it a bit please? Perhaps
along with the io_mem[x] definition?

> +        entry->flags = 1;
> +    }
> +    entry->io_mem[offset] = val;
> +
> +    if (offset == 3) {
> +        if (msix->enabled && !(val & 0x1)) {
> +            pt_msix_update_one(s, entry_nr);
> +        }
> +        mask_physical_msix_entry(s, entry_nr, entry->io_mem[3] & 0x1);
> +    }
> +}
> +
> +static CPUWriteMemoryFunc *pci_msix_write[] = {
> +    pci_msix_invalid_write,
> +    pci_msix_invalid_write,
> +    pci_msix_writel
> +};
> +
> +static uint32_t pci_msix_invalid_read(void *opaque, target_phys_addr_t addr)
> +{
> +    XenPCIPassthroughState *s = opaque;
> +    PT_ERR(&s->dev, "Invalid read to MSI-X table,"
> +           " only dword access is allowed.\n");
> +    return 0;
> +}
> +
> +static uint32_t pci_msix_readl(void *opaque, target_phys_addr_t addr)
> +{
> +    XenPCIPassthroughState *s = opaque;
> +    XenPTMSIX *msix = s->msix;
> +    int entry_nr, offset;
> +
> +    if (addr % 4) {
> +        PT_ERR(&s->dev, "Unaligned dword access to MSI-X table, "
> +                "addr 0x"TARGET_FMT_plx"\n", addr);
> +        return 0;
> +    }
> +
> +    entry_nr = addr / 16;
> +    offset = (addr % 16) / 4;
> +
> +    return msix->msix_entry[entry_nr].io_mem[offset];
> +}
> +
> +static CPUReadMemoryFunc *pci_msix_read[] = {
> +    pci_msix_invalid_read,
> +    pci_msix_invalid_read,
> +    pci_msix_readl
> +};
> +
> +int pt_add_msix_mapping(XenPCIPassthroughState *s, int bar_index)
> +{
> +    if (!(s->msix && s->msix->bar_index == bar_index)) {
> +        return 0;
> +    }
> +
> +    return xc_domain_memory_mapping(xen_xc, xen_domid,
> +         s->msix->mmio_base_addr >> XC_PAGE_SHIFT,
> +         (s->bases[bar_index].access.maddr + s->msix->table_off)
> +             >> XC_PAGE_SHIFT,
> +         (s->msix->total_entries * 16 + XC_PAGE_SIZE - 1) >> XC_PAGE_SHIFT,
> +         DPCI_ADD_MAPPING);
> +}
> +
> +int pt_remove_msix_mapping(XenPCIPassthroughState *s, int bar_index)
> +{
> +    if (!(s->msix && s->msix->bar_index == bar_index)) {
> +        return 0;
> +    }
> +
> +    s->msix->mmio_base_addr = s->bases[bar_index].e_physbase
> +        + s->msix->table_off;
> +
> +    cpu_register_physical_memory(s->msix->mmio_base_addr,
> +                                 s->msix->total_entries * 16,
> +                                 s->msix->mmio_index);
> +
> +    return xc_domain_memory_mapping(xen_xc, xen_domid,
> +         s->msix->mmio_base_addr >> XC_PAGE_SHIFT,
> +         (s->bases[bar_index].access.maddr + s->msix->table_off)
> +             >> XC_PAGE_SHIFT,
> +         (s->msix->total_entries * 16 + XC_PAGE_SIZE - 1) >> XC_PAGE_SHIFT,
> +         DPCI_REMOVE_MAPPING);
> +}
> +
> +int pt_msix_init(XenPCIPassthroughState *s, int base)
> +{
> +    uint8_t id = 0;
> +    uint16_t control = 0;
> +    uint32_t table_off = 0;
> +    int i, total_entries, bar_index;
> +    HostPCIDevice *d = s->real_device;
> +    int fd;
> +
> +    if (host_pci_get_byte(d, base + PCI_CAP_LIST_ID, &id)) {
> +        return -1;

-ENOSPC?

> +    }
> +
> +    if (id != PCI_CAP_ID_MSIX) {
> +        PT_ERR(&s->dev, "Invalid id %#x base %#x\n", id, base);
> +        return -1;
> +    }
> +
> +    host_pci_get_word(d, base + 2, &control);
> +    total_entries = control & 0x7ff;
> +    total_entries += 1;
> +
> +    s->msix = g_malloc0(sizeof (XenPTMSIX)
> +                        + total_entries * sizeof (XenMSIXEntry));
> +
> +    s->msix->total_entries = total_entries;
> +    for (i = 0; i < total_entries; i++) {
> +        s->msix->msix_entry[i].pirq = PT_UNASSIGNED_PIRQ;
> +    }
> +
> +    s->msix->mmio_index =
> +        cpu_register_io_memory(pci_msix_read, pci_msix_write,
> +                               s, DEVICE_NATIVE_ENDIAN);
> +
> +    host_pci_get_long(d, base + PCI_MSIX_TABLE, &table_off);
> +    bar_index = s->msix->bar_index = table_off & PCI_MSIX_FLAGS_BIRMASK;
> +    table_off = s->msix->table_off = table_off & ~PCI_MSIX_FLAGS_BIRMASK;
> +    s->msix->table_base = s->real_device->io_regions[bar_index].base_addr;
> +    PT_LOG(&s->dev, "get MSI-X table BAR base 0x%"PRIx64"\n",
> +           s->msix->table_base);

Can you also include the amount of entries it can have?
> +
> +    fd = open("/dev/mem", O_RDWR);
> +    if (fd == -1) {
> +        PT_ERR(&s->dev, "Can't open /dev/mem: %s\n", strerror(errno));
> +        goto error_out;
> +    }
> +    PT_LOG(&s->dev, "table_off = %#x, total_entries = %d\n",
> +           table_off, total_entries);
> +    s->msix->table_offset_adjust = table_off & 0x0fff;
> +    s->msix->phys_iomem_base =
> +        mmap(0,
> +             total_entries * 16 + s->msix->table_offset_adjust,
> +             PROT_WRITE | PROT_READ,
> +             MAP_SHARED | MAP_LOCKED,
> +             fd,
> +             s->msix->table_base + table_off - s->msix->table_offset_adjust);
> +
> +    if (s->msix->phys_iomem_base == MAP_FAILED) {
> +        PT_ERR(&s->dev, "Can't map physical MSI-X table: %s\n",
> +               strerror(errno));
> +        close(fd);
> +        goto error_out;
> +    }
> +    s->msix->phys_iomem_base = (char *)s->msix->phys_iomem_base
> +        + s->msix->table_offset_adjust;
> +
> +    close(fd);
> +
> +    PT_LOG(&s->dev, "mapping physical MSI-X table to %p\n",
> +           s->msix->phys_iomem_base);
> +    return 0;
> +
> +error_out:
> +    g_free(s->msix);
> +    s->msix = NULL;
> +    return -1;
> +}
> +
> +void pt_msix_delete(XenPCIPassthroughState *s)
> +{
> +    /* unmap the MSI-X memory mapped register area */
> +    if (s->msix->phys_iomem_base) {
> +        PT_LOG(&s->dev, "unmapping physical MSI-X table from %p\n",
> +           s->msix->phys_iomem_base);
> +        munmap(s->msix->phys_iomem_base, s->msix->total_entries * 16 +
> +           s->msix->table_offset_adjust);
> +    }
> +
> +    if (s->msix->mmio_index > 0) {
> +        cpu_unregister_io_memory(s->msix->mmio_index);
> +    }
> +
> +    g_free(s->msix);
> +    s->msix = NULL;
> +}
> -- 
> Anthony PERARD
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 02:06:54 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 02:06:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXkQ1-0001Qo-Js; Tue, 06 Dec 2011 02:06:05 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <xen-devel.GarveyPatrickD@OrdinaryAmerican.net>)
	id 1RXkQ0-0001Qj-40
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 02:06:04 +0000
X-Env-Sender: xen-devel.GarveyPatrickD@OrdinaryAmerican.net
X-Msg-Ref: server-14.tower-27.messagelabs.com!1323136638!47101598!1
X-Originating-IP: [216.75.62.102]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16774 invoked from network); 6 Dec 2011 01:57:18 -0000
Received: from gourmet7.spamgourmet.com (HELO gourmet8.spamgourmet.com)
	(216.75.62.102) by server-14.tower-27.messagelabs.com with SMTP;
	6 Dec 2011 01:57:18 -0000
Received: from spamgourmet by gourmet7.spamgourmet.com with local (Exim 4.69)
	(envelope-from <xen-devel.GarveyPatrickD@OrdinaryAmerican.net>)
	id 1RXkJT-0007LR-QO
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 01:59:19 +0000
Received: from mail-gx0-f176.google.com ([209.85.161.176])
	by gourmet7.spamgourmet.com with esmtp (Exim 4.69)
	(envelope-from <xen-devel.GarveyPatrickD@OrdinaryAmerican.net>)
	id 1RXkJT-0007LL-Jw for
	+xen-devel+GarveyPatrickD+fbe7693c78.xen-devel#lists.xensource.com@spamgourmet.com;
	Tue, 06 Dec 2011 01:59:19 +0000
Received: by ggnv2 with SMTP id v2so6101430ggn.7 for
	<+xen-devel+GarveyPatrickD+fbe7693c78.xen-devel#lists.xensource.com@spamgourmet.com>;
	Mon, 05 Dec 2011 17:59:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=xwgytn1oH7BjDFeV5Vj0D5jVB33xmFeADi4qRkgCHhA=;
	b=SozHW9yteYIlztUtnY117DLnAXL7sAs50C9SbkFOmqmhLt5urYrKNs3/jOZJSEpuuN
	BV+2liZaWzoDXGvD3JD+Dy6AYlSjjj9WoGGX6HpHGgoMm9GoWGKT2gXoucvBLsnD1C/F
	m+1POKOLHbzNAuOnvZ70NvXlfGDuIrrjoWmVI=
MIME-Version: 1.0
Received: by 10.182.222.106 with SMTP id ql10mr2283214obc.53.1323136759094;
	Mon, 05 Dec 2011 17:59:19 -0800 (PST)
Received: by 10.182.35.167 with HTTP; Mon, 5 Dec 2011 17:59:19 -0800 (PST)
Date: Mon, 5 Dec 2011 17:59:19 -0800
Message-ID: <CACm5R6Sv2isGevS-gzprj6w0qnbKehpbC5=ai16zh29oty7jLg@mail.gmail.com>
From: xen-devel.GarveyPatrickD@OrdinaryAmerican.net
To: xen-devel@lists.xensource.com
X-Spamgourmet: 
Subject: [Xen-devel] Xen Wiki Spaceflight page
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

According to http://wiki.xen.org/wiki/Special:AllPages
there is a page http://wiki.xen.org/wiki/Spaceflight
When I use the link there is a redirection to
https://en.wikipedia.org/wiki/Spaceflight?rdfrom=http%3A%2F%2Fwiki.xen.org%2Fwiki%3Ftitle%3DSpaceflight%26redirect%3Dno

Was http://wiki.xen.org/wiki/Spaceflight purposely created?
Is it needed in http://wiki.xen.org/wiki/
Can it be removed?


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 02:06:54 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 02:06:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXkQ1-0001Qo-Js; Tue, 06 Dec 2011 02:06:05 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <xen-devel.GarveyPatrickD@OrdinaryAmerican.net>)
	id 1RXkQ0-0001Qj-40
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 02:06:04 +0000
X-Env-Sender: xen-devel.GarveyPatrickD@OrdinaryAmerican.net
X-Msg-Ref: server-14.tower-27.messagelabs.com!1323136638!47101598!1
X-Originating-IP: [216.75.62.102]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16774 invoked from network); 6 Dec 2011 01:57:18 -0000
Received: from gourmet7.spamgourmet.com (HELO gourmet8.spamgourmet.com)
	(216.75.62.102) by server-14.tower-27.messagelabs.com with SMTP;
	6 Dec 2011 01:57:18 -0000
Received: from spamgourmet by gourmet7.spamgourmet.com with local (Exim 4.69)
	(envelope-from <xen-devel.GarveyPatrickD@OrdinaryAmerican.net>)
	id 1RXkJT-0007LR-QO
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 01:59:19 +0000
Received: from mail-gx0-f176.google.com ([209.85.161.176])
	by gourmet7.spamgourmet.com with esmtp (Exim 4.69)
	(envelope-from <xen-devel.GarveyPatrickD@OrdinaryAmerican.net>)
	id 1RXkJT-0007LL-Jw for
	+xen-devel+GarveyPatrickD+fbe7693c78.xen-devel#lists.xensource.com@spamgourmet.com;
	Tue, 06 Dec 2011 01:59:19 +0000
Received: by ggnv2 with SMTP id v2so6101430ggn.7 for
	<+xen-devel+GarveyPatrickD+fbe7693c78.xen-devel#lists.xensource.com@spamgourmet.com>;
	Mon, 05 Dec 2011 17:59:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=xwgytn1oH7BjDFeV5Vj0D5jVB33xmFeADi4qRkgCHhA=;
	b=SozHW9yteYIlztUtnY117DLnAXL7sAs50C9SbkFOmqmhLt5urYrKNs3/jOZJSEpuuN
	BV+2liZaWzoDXGvD3JD+Dy6AYlSjjj9WoGGX6HpHGgoMm9GoWGKT2gXoucvBLsnD1C/F
	m+1POKOLHbzNAuOnvZ70NvXlfGDuIrrjoWmVI=
MIME-Version: 1.0
Received: by 10.182.222.106 with SMTP id ql10mr2283214obc.53.1323136759094;
	Mon, 05 Dec 2011 17:59:19 -0800 (PST)
Received: by 10.182.35.167 with HTTP; Mon, 5 Dec 2011 17:59:19 -0800 (PST)
Date: Mon, 5 Dec 2011 17:59:19 -0800
Message-ID: <CACm5R6Sv2isGevS-gzprj6w0qnbKehpbC5=ai16zh29oty7jLg@mail.gmail.com>
From: xen-devel.GarveyPatrickD@OrdinaryAmerican.net
To: xen-devel@lists.xensource.com
X-Spamgourmet: 
Subject: [Xen-devel] Xen Wiki Spaceflight page
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

According to http://wiki.xen.org/wiki/Special:AllPages
there is a page http://wiki.xen.org/wiki/Spaceflight
When I use the link there is a redirection to
https://en.wikipedia.org/wiki/Spaceflight?rdfrom=http%3A%2F%2Fwiki.xen.org%2Fwiki%3Ftitle%3DSpaceflight%26redirect%3Dno

Was http://wiki.xen.org/wiki/Spaceflight purposely created?
Is it needed in http://wiki.xen.org/wiki/
Can it be removed?


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 03:29:18 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 03: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.xensource.com>)
	id 1RXlhy-0001sR-29; Tue, 06 Dec 2011 03:28:42 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RXlhw-0001sB-VN
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 03:28:41 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1323142073!4198840!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQyOTgzMw==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30559 invoked from network); 6 Dec 2011 03:27:54 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-16.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 6 Dec 2011 03:27:54 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pB63Rm9E009601
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 6 Dec 2011 03:27:49 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pB63Rkhp026128
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 6 Dec 2011 03:27:46 GMT
Received: from abhmt104.oracle.com (abhmt104.oracle.com [141.146.116.56])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pB63Redd012480; Mon, 5 Dec 2011 21:27:40 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 05 Dec 2011 19:27:40 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id E5C6F416F9; Mon,  5 Dec 2011 22:27:09 -0500 (EST)
Date: Mon, 5 Dec 2011 22:27:09 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Thomas Meyer <thomas@m3y3r.de>
Message-ID: <20111206032709.GB6647@phenom.dumpdata.com>
References: <1322600880.1534.293.camel@localhost.localdomain>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1322600880.1534.293.camel@localhost.localdomain>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090207.4EDD8BB5.00CA,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org,
	virtualization@lists.linux-foundation.org
Subject: Re: [Xen-devel] [PATCH] xen-blkfront: Use kcalloc instead of
 kzalloc to allocate array
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Nov 29, 2011 at 10:08:00PM +0100, Thomas Meyer wrote:
> The advantage of kcalloc is, that will prevent integer overflows which could
> result from the multiplication of number of elements and size and it is also
> a bit nicer to read.
> 
> The semantic patch that makes this change is available
> in https://lkml.org/lkml/2011/11/25/107
> 
> Signed-off-by: Thomas Meyer <thomas@m3y3r.de>
> ---
> 
> diff -u -p a/drivers/block/cciss_scsi.c b/drivers/block/cciss_scsi.c
> --- a/drivers/block/cciss_scsi.c 2011-11-28 19:36:47.343430551 +0100
> +++ b/drivers/block/cciss_scsi.c 2011-11-28 19:49:24.922716381 +0100
> @@ -534,10 +534,10 @@ adjust_cciss_scsi_table(ctlr_info_t *h,
>  	int nadded, nremoved;
>  	struct Scsi_Host *sh = NULL;
>  
> -	added = kzalloc(sizeof(*added) * CCISS_MAX_SCSI_DEVS_PER_HBA,
> -			GFP_KERNEL);
> -	removed = kzalloc(sizeof(*removed) * CCISS_MAX_SCSI_DEVS_PER_HBA,
> +	added = kcalloc(CCISS_MAX_SCSI_DEVS_PER_HBA, sizeof(*added),
>  			GFP_KERNEL);
> +	removed = kcalloc(CCISS_MAX_SCSI_DEVS_PER_HBA, sizeof(*removed),
> +			  GFP_KERNEL);
>  

It looks like you mixed two patches together.

>  	if (!added || !removed) {
>  		dev_warn(&h->pdev->dev,
> @@ -1191,8 +1191,8 @@ cciss_update_non_disk_devices(ctlr_info_
>  
>  	ld_buff = kzalloc(reportlunsize, GFP_KERNEL);
>  	inq_buff = kmalloc(OBDR_TAPE_INQ_SIZE, GFP_KERNEL);
> -	currentsd = kzalloc(sizeof(*currentsd) *
> -			(CCISS_MAX_SCSI_DEVS_PER_HBA+1), GFP_KERNEL);
> +	currentsd = kcalloc(CCISS_MAX_SCSI_DEVS_PER_HBA + 1,
> +			    sizeof(*currentsd), GFP_KERNEL);
>  	if (ld_buff == NULL || inq_buff == NULL || currentsd == NULL) {
>  		printk(KERN_ERR "cciss: out of memory\n");
>  		goto out;
> diff -u -p a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
> --- a/drivers/block/xen-blkfront.c 2011-11-13 11:07:22.680095573 +0100
> +++ b/drivers/block/xen-blkfront.c 2011-11-28 19:49:29.109460410 +0100
> @@ -156,7 +156,7 @@ static int xlbd_reserve_minors(unsigned
>  	if (end > nr_minors) {
>  		unsigned long *bitmap, *old;
>  
> -		bitmap = kzalloc(BITS_TO_LONGS(end) * sizeof(*bitmap),
> +		bitmap = kcalloc(BITS_TO_LONGS(end), sizeof(*bitmap),
>  				 GFP_KERNEL);

But this parts looks good.

Can you respin it with just that part please?
>  		if (bitmap == NULL)
>  			return -ENOMEM;
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 03:29:18 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 03: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.xensource.com>)
	id 1RXlhy-0001sR-29; Tue, 06 Dec 2011 03:28:42 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RXlhw-0001sB-VN
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 03:28:41 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1323142073!4198840!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQyOTgzMw==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30559 invoked from network); 6 Dec 2011 03:27:54 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-16.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 6 Dec 2011 03:27:54 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pB63Rm9E009601
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 6 Dec 2011 03:27:49 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pB63Rkhp026128
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 6 Dec 2011 03:27:46 GMT
Received: from abhmt104.oracle.com (abhmt104.oracle.com [141.146.116.56])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pB63Redd012480; Mon, 5 Dec 2011 21:27:40 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 05 Dec 2011 19:27:40 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id E5C6F416F9; Mon,  5 Dec 2011 22:27:09 -0500 (EST)
Date: Mon, 5 Dec 2011 22:27:09 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Thomas Meyer <thomas@m3y3r.de>
Message-ID: <20111206032709.GB6647@phenom.dumpdata.com>
References: <1322600880.1534.293.camel@localhost.localdomain>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1322600880.1534.293.camel@localhost.localdomain>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090207.4EDD8BB5.00CA,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org,
	virtualization@lists.linux-foundation.org
Subject: Re: [Xen-devel] [PATCH] xen-blkfront: Use kcalloc instead of
 kzalloc to allocate array
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Nov 29, 2011 at 10:08:00PM +0100, Thomas Meyer wrote:
> The advantage of kcalloc is, that will prevent integer overflows which could
> result from the multiplication of number of elements and size and it is also
> a bit nicer to read.
> 
> The semantic patch that makes this change is available
> in https://lkml.org/lkml/2011/11/25/107
> 
> Signed-off-by: Thomas Meyer <thomas@m3y3r.de>
> ---
> 
> diff -u -p a/drivers/block/cciss_scsi.c b/drivers/block/cciss_scsi.c
> --- a/drivers/block/cciss_scsi.c 2011-11-28 19:36:47.343430551 +0100
> +++ b/drivers/block/cciss_scsi.c 2011-11-28 19:49:24.922716381 +0100
> @@ -534,10 +534,10 @@ adjust_cciss_scsi_table(ctlr_info_t *h,
>  	int nadded, nremoved;
>  	struct Scsi_Host *sh = NULL;
>  
> -	added = kzalloc(sizeof(*added) * CCISS_MAX_SCSI_DEVS_PER_HBA,
> -			GFP_KERNEL);
> -	removed = kzalloc(sizeof(*removed) * CCISS_MAX_SCSI_DEVS_PER_HBA,
> +	added = kcalloc(CCISS_MAX_SCSI_DEVS_PER_HBA, sizeof(*added),
>  			GFP_KERNEL);
> +	removed = kcalloc(CCISS_MAX_SCSI_DEVS_PER_HBA, sizeof(*removed),
> +			  GFP_KERNEL);
>  

It looks like you mixed two patches together.

>  	if (!added || !removed) {
>  		dev_warn(&h->pdev->dev,
> @@ -1191,8 +1191,8 @@ cciss_update_non_disk_devices(ctlr_info_
>  
>  	ld_buff = kzalloc(reportlunsize, GFP_KERNEL);
>  	inq_buff = kmalloc(OBDR_TAPE_INQ_SIZE, GFP_KERNEL);
> -	currentsd = kzalloc(sizeof(*currentsd) *
> -			(CCISS_MAX_SCSI_DEVS_PER_HBA+1), GFP_KERNEL);
> +	currentsd = kcalloc(CCISS_MAX_SCSI_DEVS_PER_HBA + 1,
> +			    sizeof(*currentsd), GFP_KERNEL);
>  	if (ld_buff == NULL || inq_buff == NULL || currentsd == NULL) {
>  		printk(KERN_ERR "cciss: out of memory\n");
>  		goto out;
> diff -u -p a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
> --- a/drivers/block/xen-blkfront.c 2011-11-13 11:07:22.680095573 +0100
> +++ b/drivers/block/xen-blkfront.c 2011-11-28 19:49:29.109460410 +0100
> @@ -156,7 +156,7 @@ static int xlbd_reserve_minors(unsigned
>  	if (end > nr_minors) {
>  		unsigned long *bitmap, *old;
>  
> -		bitmap = kzalloc(BITS_TO_LONGS(end) * sizeof(*bitmap),
> +		bitmap = kcalloc(BITS_TO_LONGS(end), sizeof(*bitmap),
>  				 GFP_KERNEL);

But this parts looks good.

Can you respin it with just that part please?
>  		if (bitmap == NULL)
>  			return -ENOMEM;
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 03:29:19 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 03: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.xensource.com>)
	id 1RXlhu-0001sG-L8; Tue, 06 Dec 2011 03:28:38 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RXlhs-0001s9-Ty
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 03:28:37 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1323142070!6921878!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDMzNjkw\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15183 invoked from network); 6 Dec 2011 03:27:51 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-6.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Dec 2011 03:27:51 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pB63R04R015812
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 6 Dec 2011 03:27:01 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pB63QxwM025467
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 6 Dec 2011 03:26:59 GMT
Received: from abhmt110.oracle.com (abhmt110.oracle.com [141.146.116.62])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pB63QqO0016361; Mon, 5 Dec 2011 21:26:53 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 05 Dec 2011 19:26:52 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id CF15E416F9; Mon,  5 Dec 2011 22:26:21 -0500 (EST)
Date: Mon, 5 Dec 2011 22:26:21 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Carsten Schiers <carsten@schiers.de>
Message-ID: <20111206032621.GA6568@phenom.dumpdata.com>
References: <zarafa.4ece387c.6e85.6aa0c9ca21e63bd9@uhura.space.zz>
	<zarafa.4edb62f8.6417.1a54a5c25b8f0fd7@uhura.space.zz>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <zarafa.4edb62f8.6417.1a54a5c25b8f0fd7@uhura.space.zz>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090204.4EDD8B85.00E9,ss=1,re=0.000,fgs=0
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>,
	xen-devel <xen-devel@lists.xensource.com>,
	"lersek@redhat.com" <lersek@redhat.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"zhenzhong.duan@oracle.com" <zhenzhong.duan@oracle.com>
Subject: Re: [Xen-devel] Load increase after memory upgrade (part2)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Sun, Dec 04, 2011 at 01:09:28PM +0100, Carsten Schiers wrote:
> Here with two cards enabled and creating a bit "work" by watching TV with one oft hem:
> 
> [   23.842720] Starting SWIOTLB debug thread.
> [   23.842750] swiotlb_start_thread: Go!
> [   23.842838] xen_swiotlb_start_thread: Go!
> [   28.841451] 0 [budget_av 0000:00:01.0] bounce: from:435596(slow:0)to:0 map:658 unmap:0 sync:435596
> [   28.841592] SWIOTLB is 4% full
> [   33.840147] 0 [budget_av 0000:00:01.0] bounce: from:127652(slow:0)to:0 map:0 unmap:0 sync:127652
> [   33.840283] SWIOTLB is 4% full
> [   33.844222] 0 budget_av 0000:00:01.0 alloc coherent: 8, free: 0
> [   38.840227] 0 [budget_av 0000:00:01.0] bounce: from:128310(slow:0)to:0 map:0 unmap:0 sync:128310

Whoa. Yes. You are definitly using the bounce buffer :-)

Now it is time to look at why the drive is not using those coherent ones - it
looks to allocate just eight of them but does not use them.. Unless it is
using them _and_ bouncing them (which would be odd).

And BTW, you can lower your 'swiotlb=XX' value.  The 4% is how much you
are using of the default size.

I should find out_why_ the old Xen kernels do not use the bounce buffer
so much...


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 03:29:19 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 03: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.xensource.com>)
	id 1RXlhu-0001sG-L8; Tue, 06 Dec 2011 03:28:38 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RXlhs-0001s9-Ty
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 03:28:37 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1323142070!6921878!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDMzNjkw\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15183 invoked from network); 6 Dec 2011 03:27:51 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-6.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Dec 2011 03:27:51 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pB63R04R015812
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 6 Dec 2011 03:27:01 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pB63QxwM025467
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 6 Dec 2011 03:26:59 GMT
Received: from abhmt110.oracle.com (abhmt110.oracle.com [141.146.116.62])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pB63QqO0016361; Mon, 5 Dec 2011 21:26:53 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 05 Dec 2011 19:26:52 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id CF15E416F9; Mon,  5 Dec 2011 22:26:21 -0500 (EST)
Date: Mon, 5 Dec 2011 22:26:21 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Carsten Schiers <carsten@schiers.de>
Message-ID: <20111206032621.GA6568@phenom.dumpdata.com>
References: <zarafa.4ece387c.6e85.6aa0c9ca21e63bd9@uhura.space.zz>
	<zarafa.4edb62f8.6417.1a54a5c25b8f0fd7@uhura.space.zz>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <zarafa.4edb62f8.6417.1a54a5c25b8f0fd7@uhura.space.zz>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090204.4EDD8B85.00E9,ss=1,re=0.000,fgs=0
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>,
	xen-devel <xen-devel@lists.xensource.com>,
	"lersek@redhat.com" <lersek@redhat.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"zhenzhong.duan@oracle.com" <zhenzhong.duan@oracle.com>
Subject: Re: [Xen-devel] Load increase after memory upgrade (part2)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Sun, Dec 04, 2011 at 01:09:28PM +0100, Carsten Schiers wrote:
> Here with two cards enabled and creating a bit "work" by watching TV with one oft hem:
> 
> [   23.842720] Starting SWIOTLB debug thread.
> [   23.842750] swiotlb_start_thread: Go!
> [   23.842838] xen_swiotlb_start_thread: Go!
> [   28.841451] 0 [budget_av 0000:00:01.0] bounce: from:435596(slow:0)to:0 map:658 unmap:0 sync:435596
> [   28.841592] SWIOTLB is 4% full
> [   33.840147] 0 [budget_av 0000:00:01.0] bounce: from:127652(slow:0)to:0 map:0 unmap:0 sync:127652
> [   33.840283] SWIOTLB is 4% full
> [   33.844222] 0 budget_av 0000:00:01.0 alloc coherent: 8, free: 0
> [   38.840227] 0 [budget_av 0000:00:01.0] bounce: from:128310(slow:0)to:0 map:0 unmap:0 sync:128310

Whoa. Yes. You are definitly using the bounce buffer :-)

Now it is time to look at why the drive is not using those coherent ones - it
looks to allocate just eight of them but does not use them.. Unless it is
using them _and_ bouncing them (which would be odd).

And BTW, you can lower your 'swiotlb=XX' value.  The 4% is how much you
are using of the default size.

I should find out_why_ the old Xen kernels do not use the bounce buffer
so much...


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 03:29:29 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 03:29:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXli9-0001tG-FW; Tue, 06 Dec 2011 03:28:53 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RXli7-0001sf-Fa
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 03:28:51 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1323142084!4386162!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDMzNjkw\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7066 invoked from network); 6 Dec 2011 03:28:05 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-6.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Dec 2011 03:28:05 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pB63S094016652
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 6 Dec 2011 03:28:01 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pB63S0Dr015937
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 6 Dec 2011 03:28:00 GMT
Received: from abhmt119.oracle.com (abhmt119.oracle.com [141.146.116.71])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pB63RtsU031620; Mon, 5 Dec 2011 21:27:55 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 05 Dec 2011 19:27:54 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 2F702416F9; Mon,  5 Dec 2011 22:27:24 -0500 (EST)
Date: Mon, 5 Dec 2011 22:27:24 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: ANNIE LI <annie.li@oracle.com>
Message-ID: <20111206032724.GC6647@phenom.dumpdata.com>
References: <4ed6746d25537aefd2@agluck-desktop.sc.intel.com>
	<20111130183900.GA15847@phenom.dumpdata.com>
	<4EDC8D57.6050900@oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4EDC8D57.6050900@oracle.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090204.4EDD8BC2.0002,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com, "Luck, Tony" <tony.luck@intel.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH] ia64: fix build breakage because of
 conflicting u64 guest handles
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gTW9uLCBEZWMgMDUsIDIwMTEgYXQgMDU6MjI6MzFQTSArMDgwMCwgQU5OSUUgTEkgd3JvdGU6
Cj4gCj4gCj4gT24gMjAxMS0xMi0xIDI6MzksIEtvbnJhZCBSemVzenV0ZWsgV2lsayB3cm90ZToK
PiA+T24gV2VkLCBOb3YgMzAsIDIwMTEgYXQgMTA6MjI6MzdBTSAtMDgwMCwgTHVjaywgVG9ueSB3
cm90ZToKPiA+PmluY2x1ZGUveGVuL2ludGVyZmFjZS94ZW4uaDo1MjY6IGVycm9yOiBjb25mbGlj
dGluZyB0eXBlcyBmb3Ig4oCYX19ndWVzdF9oYW5kbGVfdTY04oCZCj4gPj5hcmNoL2lhNjQvaW5j
bHVkZS9hc20veGVuL2ludGVyZmFjZS5oOjc0OiBlcnJvcjogcHJldmlvdXMgZGVjbGFyYXRpb24g
b2Yg4oCYX19ndWVzdF9oYW5kbGVfdTY04oCZIHdhcyBoZXJlCj4gPj4KPiA+PlByb2JsZW0gaW50
cm9kdWNlZCBieSAieGVuL2dyYW50dGFibGU6IEludHJvZHVjaW5nIGdyYW50IHRhYmxlIFYyIHN0
dWN0dXJlIgo+ID4+Cj4gPj53aGljaCBhZGRlZCBhIG5ldyBkZWZpbml0aW9uIHRvIGluY2x1ZGUv
eGVuL2ludGVyZmFjZS94ZW4uaCBmb3IgInU2NCIuCj4gPj4KPiA+PkZpeDogZGVsZXRlIHRoZSBp
YTY0IGFyY2ggc3BlY2lmaWMgZGVmaW5pdGlvbi4KPiA+Pgo+ID4+U2lnbmVkLW9mZi1ieTogVG9u
eSBMdWNrPHRvbnkubHVja0BpbnRlbC5jb20+Cj4gPj4tLS0KPiA+Pgo+ID4+Q2FuIHNvbWVvbmUg
ZWl0aGVyIGZvbGQgdGhpcyBpbnRvIHRoZSBhYm92ZSBwYXRjaCwgb3IgYWRkIGl0IHRvIHRoZQo+
ID4+c2FtZSB0cmVlIHRoYXQgaXMgZmVlZGluZyBpbnRvIGxpbnV4LW5leHQgLSBJIHNhdyB0aGUg
YnJlYWthZ2UgaW4KPiA+PnRvZGF5J3MgIm5leHQtMjAxMTExMzAiIHRhZy4gIFRoYW5rcy4KPiA+
QWgsIEkgY2FuIGZvbGQgaXQgaW4uIFRoYW5rcyEKPiBBIGRlZmluaXRpb24gZm9yIHVpbnQ2NF90
IGFscmVhZHkgZXhpc3RpbmcgaW4KPiBhcmNoL3g4Ni9pbmNsdWRlL2FzbS94ZW4vaW50ZXJmYWNl
LmgsIDU4IGxpbmU6Cj4gREVGSU5FX0dVRVNUX0hBTkRMRSh1aW50NjRfdCk7Cj4gTWF5YmUgaXQg
aXMgYmV0dGVyIHRvIHJlbW92ZSB0aGUgZGVmaW5pdGlvbiBpbgo+IGluY2x1ZGUveGVuL2ludGVy
ZmFjZS94ZW4uaCBvZiBncmFudCB0YWJsZSB2MiBwYXRjaCwgYW5kIG5vdCBjaGFuZ2UKPiBjb2Rl
IG9mIGFyY2gvaWE2NC9pbmNsdWRlL2FzbS94ZW4vaW50ZXJmYWNlLmguCj4gCj4gS29ucmFkLCBk
aWQgeW91IGZvbGQgaXQgYWxyZWFkeT8gb3IgSSByZXZlcnQgdGhlIGRlZmluaXRpb24gaW4gbXkK
PiBmb2xsb3dpbmcgc3ViLXBhZ2UgYW5kIHRyYW5zaXRpdmUgcGF0Y2hlcz8KCkkgdG9vayBUb255
J3MgcGF0Y2guCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
XwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tCmh0
dHA6Ly9saXN0cy54ZW5zb3VyY2UuY29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Tue Dec 06 03:29:29 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 03:29:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXli9-0001tG-FW; Tue, 06 Dec 2011 03:28:53 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RXli7-0001sf-Fa
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 03:28:51 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1323142084!4386162!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDMzNjkw\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7066 invoked from network); 6 Dec 2011 03:28:05 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-6.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Dec 2011 03:28:05 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pB63S094016652
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 6 Dec 2011 03:28:01 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pB63S0Dr015937
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 6 Dec 2011 03:28:00 GMT
Received: from abhmt119.oracle.com (abhmt119.oracle.com [141.146.116.71])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pB63RtsU031620; Mon, 5 Dec 2011 21:27:55 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 05 Dec 2011 19:27:54 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 2F702416F9; Mon,  5 Dec 2011 22:27:24 -0500 (EST)
Date: Mon, 5 Dec 2011 22:27:24 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: ANNIE LI <annie.li@oracle.com>
Message-ID: <20111206032724.GC6647@phenom.dumpdata.com>
References: <4ed6746d25537aefd2@agluck-desktop.sc.intel.com>
	<20111130183900.GA15847@phenom.dumpdata.com>
	<4EDC8D57.6050900@oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4EDC8D57.6050900@oracle.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090204.4EDD8BC2.0002,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com, "Luck, Tony" <tony.luck@intel.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH] ia64: fix build breakage because of
 conflicting u64 guest handles
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gTW9uLCBEZWMgMDUsIDIwMTEgYXQgMDU6MjI6MzFQTSArMDgwMCwgQU5OSUUgTEkgd3JvdGU6
Cj4gCj4gCj4gT24gMjAxMS0xMi0xIDI6MzksIEtvbnJhZCBSemVzenV0ZWsgV2lsayB3cm90ZToK
PiA+T24gV2VkLCBOb3YgMzAsIDIwMTEgYXQgMTA6MjI6MzdBTSAtMDgwMCwgTHVjaywgVG9ueSB3
cm90ZToKPiA+PmluY2x1ZGUveGVuL2ludGVyZmFjZS94ZW4uaDo1MjY6IGVycm9yOiBjb25mbGlj
dGluZyB0eXBlcyBmb3Ig4oCYX19ndWVzdF9oYW5kbGVfdTY04oCZCj4gPj5hcmNoL2lhNjQvaW5j
bHVkZS9hc20veGVuL2ludGVyZmFjZS5oOjc0OiBlcnJvcjogcHJldmlvdXMgZGVjbGFyYXRpb24g
b2Yg4oCYX19ndWVzdF9oYW5kbGVfdTY04oCZIHdhcyBoZXJlCj4gPj4KPiA+PlByb2JsZW0gaW50
cm9kdWNlZCBieSAieGVuL2dyYW50dGFibGU6IEludHJvZHVjaW5nIGdyYW50IHRhYmxlIFYyIHN0
dWN0dXJlIgo+ID4+Cj4gPj53aGljaCBhZGRlZCBhIG5ldyBkZWZpbml0aW9uIHRvIGluY2x1ZGUv
eGVuL2ludGVyZmFjZS94ZW4uaCBmb3IgInU2NCIuCj4gPj4KPiA+PkZpeDogZGVsZXRlIHRoZSBp
YTY0IGFyY2ggc3BlY2lmaWMgZGVmaW5pdGlvbi4KPiA+Pgo+ID4+U2lnbmVkLW9mZi1ieTogVG9u
eSBMdWNrPHRvbnkubHVja0BpbnRlbC5jb20+Cj4gPj4tLS0KPiA+Pgo+ID4+Q2FuIHNvbWVvbmUg
ZWl0aGVyIGZvbGQgdGhpcyBpbnRvIHRoZSBhYm92ZSBwYXRjaCwgb3IgYWRkIGl0IHRvIHRoZQo+
ID4+c2FtZSB0cmVlIHRoYXQgaXMgZmVlZGluZyBpbnRvIGxpbnV4LW5leHQgLSBJIHNhdyB0aGUg
YnJlYWthZ2UgaW4KPiA+PnRvZGF5J3MgIm5leHQtMjAxMTExMzAiIHRhZy4gIFRoYW5rcy4KPiA+
QWgsIEkgY2FuIGZvbGQgaXQgaW4uIFRoYW5rcyEKPiBBIGRlZmluaXRpb24gZm9yIHVpbnQ2NF90
IGFscmVhZHkgZXhpc3RpbmcgaW4KPiBhcmNoL3g4Ni9pbmNsdWRlL2FzbS94ZW4vaW50ZXJmYWNl
LmgsIDU4IGxpbmU6Cj4gREVGSU5FX0dVRVNUX0hBTkRMRSh1aW50NjRfdCk7Cj4gTWF5YmUgaXQg
aXMgYmV0dGVyIHRvIHJlbW92ZSB0aGUgZGVmaW5pdGlvbiBpbgo+IGluY2x1ZGUveGVuL2ludGVy
ZmFjZS94ZW4uaCBvZiBncmFudCB0YWJsZSB2MiBwYXRjaCwgYW5kIG5vdCBjaGFuZ2UKPiBjb2Rl
IG9mIGFyY2gvaWE2NC9pbmNsdWRlL2FzbS94ZW4vaW50ZXJmYWNlLmguCj4gCj4gS29ucmFkLCBk
aWQgeW91IGZvbGQgaXQgYWxyZWFkeT8gb3IgSSByZXZlcnQgdGhlIGRlZmluaXRpb24gaW4gbXkK
PiBmb2xsb3dpbmcgc3ViLXBhZ2UgYW5kIHRyYW5zaXRpdmUgcGF0Y2hlcz8KCkkgdG9vayBUb255
J3MgcGF0Y2guCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
XwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tCmh0
dHA6Ly9saXN0cy54ZW5zb3VyY2UuY29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Tue Dec 06 04:50:10 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 04: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.xensource.com>)
	id 1RXmy4-0002i0-Tm; Tue, 06 Dec 2011 04:49:24 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RXmy2-0002hv-P8
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 04:49:23 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1323146901!48355673!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjE3NQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16723 invoked from network); 6 Dec 2011 04:48:21 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Dec 2011 04:48:21 -0000
X-IronPort-AV: E=Sophos;i="4.71,303,1320624000"; 
   d="scan'208";a="9301950"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Dec 2011 04:48:38 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 6 Dec 2011 04:48:38 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RXmxK-0007H9-7m;
	Tue, 06 Dec 2011 04:48:38 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RXmxK-0006MR-77;
	Tue, 06 Dec 2011 04:48:38 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10360-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 6 Dec 2011 04:48:38 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10360: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10360 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10360/

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-i386-win-vcpus1    8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-i386-win           8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-amd64-win          8 guest-saverestore         fail REGR. vs. 10201
 test-i386-i386-win            8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-amd64-xl-win       8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-i386-xl-win-vcpus1  8 guest-saverestore        fail REGR. vs. 10201
 test-i386-i386-xl-win         8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-amd64-xl-sedf 14 guest-localmigrate/x10 fail in 10353 REGR. vs. 10201

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf     10 guest-saverestore           fail pass in 10353

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-win7-amd64  7 windows-install              fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install          fail never pass
 test-amd64-i386-xl-win7-amd64  7 windows-install              fail  never pass
 test-i386-i386-xl-winxpsp3    7 windows-install              fail   never pass
 test-amd64-i386-xend-winxpsp3  7 windows-install              fail  never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   never pass

version targeted for testing:
 xen                  9961a6d5356a
baseline version:
 xen                  62ff6a318c5d

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Andrew Cooper <andrew.cooper3@citrix.com>
  Anthony PERARD <anthony.perard@citrix.com>
  Brendan Cully <brendan@cs.ubc.ca>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Haitao Shan <haitao.shan@intel.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@novell.com>
  Jan Beulich <jbeulich@suse.com>
  Jonathan Davies <jonathan.davies@citrix.com>
  juergen.gross@ts.fujitsu.com
  Keir Fraser <keir@xen.org>
  Liu, Jinsong <jinsong.liu@intel.com>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
  Philipp Hahn <hahn@univention.de>
  Shriram Rajagopalan <rshriram@cs.ubc.ca>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang2 <wei.wang2@amd.com>
  Xudong Hao <xudong.hao@intel.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 1324 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 04:50:10 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 04: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.xensource.com>)
	id 1RXmy4-0002i0-Tm; Tue, 06 Dec 2011 04:49:24 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RXmy2-0002hv-P8
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 04:49:23 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1323146901!48355673!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjE3NQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16723 invoked from network); 6 Dec 2011 04:48:21 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Dec 2011 04:48:21 -0000
X-IronPort-AV: E=Sophos;i="4.71,303,1320624000"; 
   d="scan'208";a="9301950"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Dec 2011 04:48:38 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 6 Dec 2011 04:48:38 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RXmxK-0007H9-7m;
	Tue, 06 Dec 2011 04:48:38 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RXmxK-0006MR-77;
	Tue, 06 Dec 2011 04:48:38 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10360-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 6 Dec 2011 04:48:38 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10360: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10360 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10360/

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-i386-win-vcpus1    8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-i386-win           8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-amd64-win          8 guest-saverestore         fail REGR. vs. 10201
 test-i386-i386-win            8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-amd64-xl-win       8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-i386-xl-win-vcpus1  8 guest-saverestore        fail REGR. vs. 10201
 test-i386-i386-xl-win         8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-amd64-xl-sedf 14 guest-localmigrate/x10 fail in 10353 REGR. vs. 10201

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf     10 guest-saverestore           fail pass in 10353

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-win7-amd64  7 windows-install              fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install          fail never pass
 test-amd64-i386-xl-win7-amd64  7 windows-install              fail  never pass
 test-i386-i386-xl-winxpsp3    7 windows-install              fail   never pass
 test-amd64-i386-xend-winxpsp3  7 windows-install              fail  never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   never pass

version targeted for testing:
 xen                  9961a6d5356a
baseline version:
 xen                  62ff6a318c5d

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Andrew Cooper <andrew.cooper3@citrix.com>
  Anthony PERARD <anthony.perard@citrix.com>
  Brendan Cully <brendan@cs.ubc.ca>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Haitao Shan <haitao.shan@intel.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@novell.com>
  Jan Beulich <jbeulich@suse.com>
  Jonathan Davies <jonathan.davies@citrix.com>
  juergen.gross@ts.fujitsu.com
  Keir Fraser <keir@xen.org>
  Liu, Jinsong <jinsong.liu@intel.com>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
  Philipp Hahn <hahn@univention.de>
  Shriram Rajagopalan <rshriram@cs.ubc.ca>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang2 <wei.wang2@amd.com>
  Xudong Hao <xudong.hao@intel.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 1324 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 05:35:03 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 05:35:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXnf7-0003Ey-IZ; Tue, 06 Dec 2011 05:33:53 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <davem@davemloft.net>) id 1RXnf5-0003Ep-W4
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 05:33:52 +0000
X-Env-Sender: davem@davemloft.net
X-Msg-Ref: server-5.tower-216.messagelabs.com!1323149585!6309015!1
X-Originating-IP: [198.137.202.13]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18452 invoked from network); 6 Dec 2011 05:33:06 -0000
Received: from shards.monkeyblade.net (HELO shards.monkeyblade.net)
	(198.137.202.13)
	by server-5.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Dec 2011 05:33:06 -0000
Received: from localhost (cpe-66-65-61-233.nyc.res.rr.com [66.65.61.233])
	(authenticated bits=0)
	by shards.monkeyblade.net (8.14.4/8.14.4) with ESMTP id pB65X0KL032338
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO);
	Mon, 5 Dec 2011 21:33:01 -0800
Date: Tue, 06 Dec 2011 00:33:00 -0500 (EST)
Message-Id: <20111206.003300.884000484943808807.davem@davemloft.net>
To: Ian.Campbell@citrix.com
From: David Miller <davem@davemloft.net>
In-Reply-To: <1323104325.23681.22.camel@zakaz.uk.xensource.com>
References: <1323104264-3601-1-git-send-email-wei.liu2@citrix.com>
	<1323104325.23681.22.camel@zakaz.uk.xensource.com>
X-Mailer: Mew version 6.4 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6
	(shards.monkeyblade.net [198.137.202.13]);
	Mon, 05 Dec 2011 21:33:02 -0800 (PST)
Cc: netdev@vger.kernel.org, xen-devel@lists.xensource.com, wei.liu2@citrix.com
Subject: Re: [Xen-devel] [PATCH] netback: Fix alert message.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Ian Campbell <Ian.Campbell@citrix.com>
Date: Mon, 5 Dec 2011 16:58:45 +0000

> On Mon, 2011-12-05 at 16:57 +0000, Wei Liu wrote:
>> The original message in netback_init was 'kthread_run() fails', which should be
>> 'kthread_create() fails'.
>> 
>> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> Acked-by: Ian Campbell <ian.campbell@citrix.com>

Applied, thanks.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 05:35:03 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 05:35:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXnf7-0003Ey-IZ; Tue, 06 Dec 2011 05:33:53 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <davem@davemloft.net>) id 1RXnf5-0003Ep-W4
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 05:33:52 +0000
X-Env-Sender: davem@davemloft.net
X-Msg-Ref: server-5.tower-216.messagelabs.com!1323149585!6309015!1
X-Originating-IP: [198.137.202.13]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18452 invoked from network); 6 Dec 2011 05:33:06 -0000
Received: from shards.monkeyblade.net (HELO shards.monkeyblade.net)
	(198.137.202.13)
	by server-5.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Dec 2011 05:33:06 -0000
Received: from localhost (cpe-66-65-61-233.nyc.res.rr.com [66.65.61.233])
	(authenticated bits=0)
	by shards.monkeyblade.net (8.14.4/8.14.4) with ESMTP id pB65X0KL032338
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO);
	Mon, 5 Dec 2011 21:33:01 -0800
Date: Tue, 06 Dec 2011 00:33:00 -0500 (EST)
Message-Id: <20111206.003300.884000484943808807.davem@davemloft.net>
To: Ian.Campbell@citrix.com
From: David Miller <davem@davemloft.net>
In-Reply-To: <1323104325.23681.22.camel@zakaz.uk.xensource.com>
References: <1323104264-3601-1-git-send-email-wei.liu2@citrix.com>
	<1323104325.23681.22.camel@zakaz.uk.xensource.com>
X-Mailer: Mew version 6.4 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6
	(shards.monkeyblade.net [198.137.202.13]);
	Mon, 05 Dec 2011 21:33:02 -0800 (PST)
Cc: netdev@vger.kernel.org, xen-devel@lists.xensource.com, wei.liu2@citrix.com
Subject: Re: [Xen-devel] [PATCH] netback: Fix alert message.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Ian Campbell <Ian.Campbell@citrix.com>
Date: Mon, 5 Dec 2011 16:58:45 +0000

> On Mon, 2011-12-05 at 16:57 +0000, Wei Liu wrote:
>> The original message in netback_init was 'kthread_run() fails', which should be
>> 'kthread_create() fails'.
>> 
>> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> Acked-by: Ian Campbell <ian.campbell@citrix.com>

Applied, thanks.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 08:40:35 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 08:40:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXqYW-0004fQ-VO; Tue, 06 Dec 2011 08:39:16 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <juergen.gross@ts.fujitsu.com>) id 1RXqYV-0004fL-RW
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 08:39:16 +0000
X-Env-Sender: juergen.gross@ts.fujitsu.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1323160710!4396597!1
X-Originating-IP: [80.70.172.49]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNzAuMTcyLjQ5ID0+IDIzNzc1MA==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31669 invoked from network); 6 Dec 2011 08:38:30 -0000
Received: from dgate10.ts.fujitsu.com (HELO dgate10.ts.fujitsu.com)
	(80.70.172.49)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Dec 2011 08:38:30 -0000
DomainKey-Signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns;
	h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV:
	Received:Received:Message-ID:Date:From:Organization:
	User-Agent:MIME-Version:To:CC:Subject:References:
	In-Reply-To:Content-Type:Content-Transfer-Encoding;
	b=WGbHyd1AayFVaD5IXOin5UBMg7LRUMzs40jidTGdRtEDhaf+b6oO4LR8
	7nVcIyH30mJPXBwUVMI20Pp5WTX0P0R/Lk21uSoGX/TW/SSicGZD9l5MN
	IAaPJbhTmkY9l8A80eIrmqDWXebRELI/bKQqegI5nQNJ/1Xo+7tJ6Pvka
	nJdTbyWnWIcEBI58DUF6pRkdUekWNSUP96Teb2OAxp9L4zIBHv49Zc9Dd
	oeDjwRhECAsQ5q9YnGVnC5d0tEgQQ;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=ts.fujitsu.com; i=juergen.gross@ts.fujitsu.com;
	q=dns/txt; s=s1536b; t=1323160710; x=1354696710;
	h=message-id:date:from:mime-version:to:cc:subject:
	references:in-reply-to:content-transfer-encoding;
	bh=q+rJeNtXckMbm+EgyQOYp4o95/1I5l3EEQI43/n6M0o=;
	b=hZnY5SeDRBOpb6GeKCszFmjpXr9W7+naipWENwXzYLfJhTaz7jkyi1lB
	oo310tvVvE9fpXYz46rTaU4rcxog7jtJZOlVu5kQJIPKfQldcNUzMCM+U
	MR5rW4v7To9EpDs8+vWzMC/2aDYqY0qOqUCivnz5DnRWR1kSXkPk5vZj3
	e4zyDDpfG/0KyE7YCuA7Tf6bvGqmuhe/UMbaJmxgNglJ0SlYnb9CnCyr7
	y5v7UYSQNVThgsIs1bZ7fyXhRtVzr;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.71,304,1320620400"; d="scan'208";a="95101495"
Received: from abgdgate40u.abg.fsc.net ([172.25.138.90])
	by dgate10u.abg.fsc.net with ESMTP; 06 Dec 2011 09:38:30 +0100
X-IronPort-AV: E=Sophos;i="4.71,303,1320620400"; d="scan'208";a="124790643"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdgate40u.abg.fsc.net with ESMTP; 06 Dec 2011 09:38:29 +0100
Received: from [172.17.21.50] (verdon.osd.mch.fsc.net [172.17.21.50])
	by sanpedro.mch.fsc.net (Postfix) with ESMTP id B68DB95B258;
	Tue,  6 Dec 2011 09:38:29 +0100 (CET)
Message-ID: <4EDDD485.70208@ts.fujitsu.com>
Date: Tue, 06 Dec 2011 09:38:29 +0100
From: Juergen Gross <juergen.gross@ts.fujitsu.com>
Organization: Fujitsu Technology Solutions
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.24) Gecko/20111114 Iceowl/1.0b2 Icedove/3.1.16
MIME-Version: 1.0
To: Dario Faggioli <raistlin@linux.it>
References: <1322060131.30168.15.camel@Abyss>
In-Reply-To: <1322060131.30168.15.camel@Abyss>
Cc: George Dunlap <George.Dunlap@eu.citrix.com>, xen-devel@lists.xensource.com,
	Keir Fraser <keir@xen.org>
Subject: Re: [Xen-devel] [RFC/RFT][PATCH 0 of 3] rework locking in
	sched_adjust
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 11/23/2011 03:55 PM, Dario Faggioli wrote:
> Hi everyone,
>
> This series changes how locks are dealt with while adjusting domains'
> scheduling parameters.
>
> I've done and am still doing tests for credit and credit2, and it's
> surviving to all I threw at it up to now. Unfortunately, I can't test
> the sedf part yet, since it is not working on my test boxes due to other
> issues (which I'm also trying to track down). I'm sending the series out
> anyway, so that at least you can have a look at it, and maybe give a
> spin on the sedf part, if you don't have anything more interesting to
> do. ;-P

Sorry, does not work with sched=sedf:

nehalem1 login: (XEN) Xen BUG at spinlock.c:47
(XEN) ----[ Xen-4.2-unstable  x86_64  debug=y  Tainted:    C ]----
(XEN) CPU:    0
(XEN) RIP:    e008:[<ffff82c480124e84>] check_lock+0x44/0x50
(XEN) RFLAGS: 0000000000010046   CONTEXT: hypervisor
(XEN) rax: 0000000000000000   rbx: ffff83033eb17868   rcx: 0000000000000001
(XEN) rdx: 0000000000000000   rsi: 0000000000000001   rdi: ffff83033eb1786c
(XEN) rbp: ffff82c4802afc10   rsp: ffff82c4802afc10   r8:  0000000000000004
(XEN) r9:  000000000000003c   r10: ffff82c4802285b0   r11: 0000000000000212
(XEN) r12: ffff83033eb16000   r13: 0000000000000010   r14: ffff82c4802e3c60
(XEN) r15: ffff83033eb17868   cr0: 0000000080050033   cr4: 00000000000026f0
(XEN) cr3: 000000032b937000   cr2: 00007f09a92342c0
(XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: e010   cs: e008
(XEN) Xen stack trace from rsp=ffff82c4802afc10:
(XEN)    ffff82c4802afc28 ffff82c480124ec1 0000000000000010 ffff82c4802afc68
(XEN)    ffff82c48012c085 7400000000000002 0000000000000010 0000000000000010
(XEN)    0000000000000020 ffff82c4802e3c60 ffff83033eaf8fb0 ffff82c4802afca8
(XEN)    ffff82c48012c557 ffff82c4802afd18 0000000000000010 0000000000000003
(XEN)    0000000000000004 ffff82c4802e3c60 ffff83033eaf8fb0 ffff82c4802afcc8
(XEN)    ffff82c48012c660 ffff82c480124ec1 0000000000000004 ffff82c4802afd58
(XEN)    ffff82c48011f8ab ffff82c480124ec1 ffff83033ea97048 ffff82c4802afd18
(XEN)    ffff82c480121084 ffff82c4802afe48 ffff83033ea92000 ffff83033eb11f60
(XEN)    0000000000000296 ffff82c4802afd38 ffff82c480121aab 00000004bf2fb000
(XEN)    ffff83033ea92000 000000000064b004 ffff83033ea92000 0000000000000000
(XEN)    00007fff37431340 ffff82c4802afd88 ffff82c480120fec ffff82c480125104
(XEN)    fffffffffffffff3 ffff82c4802afd88 fffffffffffffff3 ffff82c4802afef8
(XEN)    ffff82c4801037e3 000000000061f004 0000000000000000 000000000061f004
(XEN)    0000000000000001 ffff82c4802afef8 ffff82c480126cb8 ffff82c4802afdf8
(XEN)    ffff82c480106f0e ffff002000000000 00000000000c0000 00000000ffffffff
(XEN)    0000000000000000 0000000000000000 00000000000bf7b3 00000018d63a6d18
(XEN)    0000000300000004 0000000000000000 0000000000000000 0000000000000000
(XEN)    ffff82c4802afe88 0000000800000010 00007f09a9890000 0000000000000004
(XEN)    0000000000000000 0000000000000000 0000000000000000 0000000a00000001
(XEN)    0000000000000000 00007fff374314e0 00007fff37431540 000000000061e050
(XEN) Xen call trace:
(XEN)    [<ffff82c480124e84>] check_lock+0x44/0x50
(XEN)    [<ffff82c480124ec1>] _spin_lock+0x11/0x5d
(XEN)    [<ffff82c48012c085>] xmem_pool_alloc+0x138/0x4d2
(XEN)    [<ffff82c48012c557>] _xmalloc+0x138/0x230
(XEN)    [<ffff82c48012c660>] _xzalloc+0x11/0x2d
(XEN)    [<ffff82c48011f8ab>] sedf_adjust+0x37c/0x9b2
(XEN)    [<ffff82c480120fec>] sched_adjust+0x5f/0xb7
(XEN)    [<ffff82c4801037e3>] do_domctl+0xf32/0x1a9f
(XEN)    [<ffff82c48021f128>] syscall_enter+0xc8/0x122
(XEN)
(XEN)
(XEN) ****************************************
(XEN) Panic on CPU 0:
(XEN) Xen BUG at spinlock.c:47
(XEN) ****************************************
(XEN)

-- 
Juergen Gross                 Principal Developer Operating Systems
PDG ES&S SWE OS6                       Telephone: +49 (0) 89 3222 2967
Fujitsu Technology Solutions              e-mail: juergen.gross@ts.fujitsu.com
Domagkstr. 28                           Internet: ts.fujitsu.com
D-80807 Muenchen                 Company details: ts.fujitsu.com/imprint.html


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 08:40:35 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 08:40:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXqYW-0004fQ-VO; Tue, 06 Dec 2011 08:39:16 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <juergen.gross@ts.fujitsu.com>) id 1RXqYV-0004fL-RW
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 08:39:16 +0000
X-Env-Sender: juergen.gross@ts.fujitsu.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1323160710!4396597!1
X-Originating-IP: [80.70.172.49]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNzAuMTcyLjQ5ID0+IDIzNzc1MA==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31669 invoked from network); 6 Dec 2011 08:38:30 -0000
Received: from dgate10.ts.fujitsu.com (HELO dgate10.ts.fujitsu.com)
	(80.70.172.49)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Dec 2011 08:38:30 -0000
DomainKey-Signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns;
	h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV:
	Received:Received:Message-ID:Date:From:Organization:
	User-Agent:MIME-Version:To:CC:Subject:References:
	In-Reply-To:Content-Type:Content-Transfer-Encoding;
	b=WGbHyd1AayFVaD5IXOin5UBMg7LRUMzs40jidTGdRtEDhaf+b6oO4LR8
	7nVcIyH30mJPXBwUVMI20Pp5WTX0P0R/Lk21uSoGX/TW/SSicGZD9l5MN
	IAaPJbhTmkY9l8A80eIrmqDWXebRELI/bKQqegI5nQNJ/1Xo+7tJ6Pvka
	nJdTbyWnWIcEBI58DUF6pRkdUekWNSUP96Teb2OAxp9L4zIBHv49Zc9Dd
	oeDjwRhECAsQ5q9YnGVnC5d0tEgQQ;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=ts.fujitsu.com; i=juergen.gross@ts.fujitsu.com;
	q=dns/txt; s=s1536b; t=1323160710; x=1354696710;
	h=message-id:date:from:mime-version:to:cc:subject:
	references:in-reply-to:content-transfer-encoding;
	bh=q+rJeNtXckMbm+EgyQOYp4o95/1I5l3EEQI43/n6M0o=;
	b=hZnY5SeDRBOpb6GeKCszFmjpXr9W7+naipWENwXzYLfJhTaz7jkyi1lB
	oo310tvVvE9fpXYz46rTaU4rcxog7jtJZOlVu5kQJIPKfQldcNUzMCM+U
	MR5rW4v7To9EpDs8+vWzMC/2aDYqY0qOqUCivnz5DnRWR1kSXkPk5vZj3
	e4zyDDpfG/0KyE7YCuA7Tf6bvGqmuhe/UMbaJmxgNglJ0SlYnb9CnCyr7
	y5v7UYSQNVThgsIs1bZ7fyXhRtVzr;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.71,304,1320620400"; d="scan'208";a="95101495"
Received: from abgdgate40u.abg.fsc.net ([172.25.138.90])
	by dgate10u.abg.fsc.net with ESMTP; 06 Dec 2011 09:38:30 +0100
X-IronPort-AV: E=Sophos;i="4.71,303,1320620400"; d="scan'208";a="124790643"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdgate40u.abg.fsc.net with ESMTP; 06 Dec 2011 09:38:29 +0100
Received: from [172.17.21.50] (verdon.osd.mch.fsc.net [172.17.21.50])
	by sanpedro.mch.fsc.net (Postfix) with ESMTP id B68DB95B258;
	Tue,  6 Dec 2011 09:38:29 +0100 (CET)
Message-ID: <4EDDD485.70208@ts.fujitsu.com>
Date: Tue, 06 Dec 2011 09:38:29 +0100
From: Juergen Gross <juergen.gross@ts.fujitsu.com>
Organization: Fujitsu Technology Solutions
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.24) Gecko/20111114 Iceowl/1.0b2 Icedove/3.1.16
MIME-Version: 1.0
To: Dario Faggioli <raistlin@linux.it>
References: <1322060131.30168.15.camel@Abyss>
In-Reply-To: <1322060131.30168.15.camel@Abyss>
Cc: George Dunlap <George.Dunlap@eu.citrix.com>, xen-devel@lists.xensource.com,
	Keir Fraser <keir@xen.org>
Subject: Re: [Xen-devel] [RFC/RFT][PATCH 0 of 3] rework locking in
	sched_adjust
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 11/23/2011 03:55 PM, Dario Faggioli wrote:
> Hi everyone,
>
> This series changes how locks are dealt with while adjusting domains'
> scheduling parameters.
>
> I've done and am still doing tests for credit and credit2, and it's
> surviving to all I threw at it up to now. Unfortunately, I can't test
> the sedf part yet, since it is not working on my test boxes due to other
> issues (which I'm also trying to track down). I'm sending the series out
> anyway, so that at least you can have a look at it, and maybe give a
> spin on the sedf part, if you don't have anything more interesting to
> do. ;-P

Sorry, does not work with sched=sedf:

nehalem1 login: (XEN) Xen BUG at spinlock.c:47
(XEN) ----[ Xen-4.2-unstable  x86_64  debug=y  Tainted:    C ]----
(XEN) CPU:    0
(XEN) RIP:    e008:[<ffff82c480124e84>] check_lock+0x44/0x50
(XEN) RFLAGS: 0000000000010046   CONTEXT: hypervisor
(XEN) rax: 0000000000000000   rbx: ffff83033eb17868   rcx: 0000000000000001
(XEN) rdx: 0000000000000000   rsi: 0000000000000001   rdi: ffff83033eb1786c
(XEN) rbp: ffff82c4802afc10   rsp: ffff82c4802afc10   r8:  0000000000000004
(XEN) r9:  000000000000003c   r10: ffff82c4802285b0   r11: 0000000000000212
(XEN) r12: ffff83033eb16000   r13: 0000000000000010   r14: ffff82c4802e3c60
(XEN) r15: ffff83033eb17868   cr0: 0000000080050033   cr4: 00000000000026f0
(XEN) cr3: 000000032b937000   cr2: 00007f09a92342c0
(XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: e010   cs: e008
(XEN) Xen stack trace from rsp=ffff82c4802afc10:
(XEN)    ffff82c4802afc28 ffff82c480124ec1 0000000000000010 ffff82c4802afc68
(XEN)    ffff82c48012c085 7400000000000002 0000000000000010 0000000000000010
(XEN)    0000000000000020 ffff82c4802e3c60 ffff83033eaf8fb0 ffff82c4802afca8
(XEN)    ffff82c48012c557 ffff82c4802afd18 0000000000000010 0000000000000003
(XEN)    0000000000000004 ffff82c4802e3c60 ffff83033eaf8fb0 ffff82c4802afcc8
(XEN)    ffff82c48012c660 ffff82c480124ec1 0000000000000004 ffff82c4802afd58
(XEN)    ffff82c48011f8ab ffff82c480124ec1 ffff83033ea97048 ffff82c4802afd18
(XEN)    ffff82c480121084 ffff82c4802afe48 ffff83033ea92000 ffff83033eb11f60
(XEN)    0000000000000296 ffff82c4802afd38 ffff82c480121aab 00000004bf2fb000
(XEN)    ffff83033ea92000 000000000064b004 ffff83033ea92000 0000000000000000
(XEN)    00007fff37431340 ffff82c4802afd88 ffff82c480120fec ffff82c480125104
(XEN)    fffffffffffffff3 ffff82c4802afd88 fffffffffffffff3 ffff82c4802afef8
(XEN)    ffff82c4801037e3 000000000061f004 0000000000000000 000000000061f004
(XEN)    0000000000000001 ffff82c4802afef8 ffff82c480126cb8 ffff82c4802afdf8
(XEN)    ffff82c480106f0e ffff002000000000 00000000000c0000 00000000ffffffff
(XEN)    0000000000000000 0000000000000000 00000000000bf7b3 00000018d63a6d18
(XEN)    0000000300000004 0000000000000000 0000000000000000 0000000000000000
(XEN)    ffff82c4802afe88 0000000800000010 00007f09a9890000 0000000000000004
(XEN)    0000000000000000 0000000000000000 0000000000000000 0000000a00000001
(XEN)    0000000000000000 00007fff374314e0 00007fff37431540 000000000061e050
(XEN) Xen call trace:
(XEN)    [<ffff82c480124e84>] check_lock+0x44/0x50
(XEN)    [<ffff82c480124ec1>] _spin_lock+0x11/0x5d
(XEN)    [<ffff82c48012c085>] xmem_pool_alloc+0x138/0x4d2
(XEN)    [<ffff82c48012c557>] _xmalloc+0x138/0x230
(XEN)    [<ffff82c48012c660>] _xzalloc+0x11/0x2d
(XEN)    [<ffff82c48011f8ab>] sedf_adjust+0x37c/0x9b2
(XEN)    [<ffff82c480120fec>] sched_adjust+0x5f/0xb7
(XEN)    [<ffff82c4801037e3>] do_domctl+0xf32/0x1a9f
(XEN)    [<ffff82c48021f128>] syscall_enter+0xc8/0x122
(XEN)
(XEN)
(XEN) ****************************************
(XEN) Panic on CPU 0:
(XEN) Xen BUG at spinlock.c:47
(XEN) ****************************************
(XEN)

-- 
Juergen Gross                 Principal Developer Operating Systems
PDG ES&S SWE OS6                       Telephone: +49 (0) 89 3222 2967
Fujitsu Technology Solutions              e-mail: juergen.gross@ts.fujitsu.com
Domagkstr. 28                           Internet: ts.fujitsu.com
D-80807 Muenchen                 Company details: ts.fujitsu.com/imprint.html


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 09:36:20 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 09:36:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXrR3-00056U-AR; Tue, 06 Dec 2011 09:35:37 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Christoph.Egger@amd.com>) id 1RXrR1-00056G-61
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 09:35:35 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1323164087!4416529!1
X-Originating-IP: [216.32.181.183]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19198 invoked from network); 6 Dec 2011 09:34:48 -0000
Received: from ch1ehsobe003.messaging.microsoft.com (HELO
	ch1outboundpool.messaging.microsoft.com) (216.32.181.183)
	by server-11.tower-174.messagelabs.com with AES128-SHA encrypted SMTP;
	6 Dec 2011 09:34:48 -0000
Received: from mail78-ch1-R.bigfish.com (10.43.68.247) by
	CH1EHSOBE006.bigfish.com (10.43.70.56) with Microsoft SMTP Server id
	14.1.225.23; Tue, 6 Dec 2011 09:34:47 +0000
Received: from mail78-ch1 (localhost.localdomain [127.0.0.1])	by
	mail78-ch1-R.bigfish.com (Postfix) with ESMTP id B3F99190506;
	Tue,  6 Dec 2011 09:34:40 +0000 (UTC)
X-SpamScore: 1
X-BigFish: VPS1(zzc85dhzz1202hzz8275bhz32i668h839h34h)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
Received: from mail78-ch1 (localhost.localdomain [127.0.0.1]) by mail78-ch1
	(MessageSwitch) id 1323164062774076_32179;
	Tue,  6 Dec 2011 09:34:22 +0000 (UTC)
Received: from CH1EHSMHS029.bigfish.com (snatpool1.int.messaging.microsoft.com
	[10.43.68.250])	by mail78-ch1.bigfish.com (Postfix) with ESMTP id
	44BB8BE8062;	Tue,  6 Dec 2011 09:34:22 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	CH1EHSMHS029.bigfish.com (10.43.70.29) with Microsoft SMTP Server id
	14.1.225.23; Tue, 6 Dec 2011 09:34:21 +0000
X-WSS-ID: 0LVRZX7-01-8TF-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2E0DA102802A;	Tue,  6 Dec 2011 03:34:19 -0600 (CST)
Received: from SAUSEXDAG01.amd.com (163.181.55.1) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Tue, 6 Dec 2011 03:34:27 -0600
Received: from storexhtp02.amd.com (172.24.4.4) by sausexdag01.amd.com
	(163.181.55.1) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Tue, 6 Dec 2011 03:34:19 -0600
Received: from rhodium.osrc.amd.com (165.204.15.173) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Tue, 6 Dec 2011
	04:34:18 -0500
Message-ID: <4EDDE199.2090801@amd.com>
Date: Tue, 6 Dec 2011 10:34:17 +0100
From: Christoph Egger <Christoph.Egger@amd.com>
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:8.0) Gecko/20111114 Thunderbird/8.0
MIME-Version: 1.0
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Ian
	Campbell <Ian.Campbell@citrix.com>
Content-Type: multipart/mixed; boundary="------------010807080500050607060300"
X-OriginatorOrg: amd.com
Subject: [Xen-devel] [PATCH] libxc: switch to XC_PAGE_*
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--------------010807080500050607060300
Content-Type: text/plain; charset="ISO-8859-15"; format=flowed
Content-Transfer-Encoding: 7bit


Switch to a consistent set of XC_PAGE_* constants.

Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>


-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo, Andrew Bowd
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632

--------------010807080500050607060300
Content-Type: text/plain; name="xen_libxc_page.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="xen_libxc_page.diff"
Content-Description: xen_libxc_page.diff

diff -r 7244cea070fc tools/libxc/xc_dom_ia64.c
--- a/tools/libxc/xc_dom_ia64.c	Tue Nov 15 11:18:34 2011 +0100
+++ b/tools/libxc/xc_dom_ia64.c	Tue Dec 06 10:28:03 2011 +0100
@@ -83,7 +83,7 @@ int start_info_ia64(struct xc_dom_image 
         bp->initrd_start = start_info->mod_start;
         bp->initrd_size = start_info->mod_len;
     }
-    bp->command_line = (dom->start_info_pfn << PAGE_SHIFT_IA64)
+    bp->command_line = (dom->start_info_pfn << XC_PAGE_SHIFT)
         + offsetof(start_info_t, cmd_line);
     if ( dom->cmdline )
     {
@@ -128,7 +128,7 @@ static int vcpu_ia64(struct xc_dom_image
 #ifdef __ia64__			/* FIXME */
     ctxt->regs.ar.fpsr = xc_ia64_fpsr_default();
 #endif
-    ctxt->regs.r[28] = (dom->start_info_pfn << PAGE_SHIFT_IA64)
+    ctxt->regs.r[28] = (dom->start_info_pfn << XC_PAGE_SHIFT)
         + sizeof(start_info_ia64_t);
     return 0;
 }
@@ -138,7 +138,7 @@ static int vcpu_ia64(struct xc_dom_image
 static struct xc_dom_arch xc_dom_arch = {
     .guest_type = "xen-3.0-ia64",
     .native_protocol = XEN_IO_PROTO_ABI_IA64,
-    .page_shift = PAGE_SHIFT_IA64,
+    .page_shift = XC_PAGE_SHIFT,
     .alloc_magic_pages = alloc_magic_pages,
     .start_info = start_info_ia64,
     .shared_info = shared_info_ia64,
@@ -148,7 +148,7 @@ static struct xc_dom_arch xc_dom_arch = 
 static struct xc_dom_arch xc_dom_arch_ia64be = {
     .guest_type = "xen-3.0-ia64be",
     .native_protocol = XEN_IO_PROTO_ABI_IA64,
-    .page_shift = PAGE_SHIFT_IA64,
+    .page_shift = XC_PAGE_SHIFT,
     .alloc_magic_pages = alloc_magic_pages,
     .start_info = start_info_ia64,
     .shared_info = shared_info_ia64,
@@ -173,8 +173,8 @@ int arch_setup_meminit(struct xc_dom_ima
     /* setup initial p2m */
     if (dom->guest_type && strcmp(dom->guest_type,
                                   "hvm-3.0-ia64-sioemu") == 0) {
-        start = FW_MEM_BASE >> PAGE_SHIFT_IA64;
-        nbr = FW_MEM_SIZE >> PAGE_SHIFT_IA64;
+        start = FW_MEM_BASE >> XC_PAGE_SHIFT;
+        nbr = FW_MEM_SIZE >> XC_PAGE_SHIFT;
     } else {
         start = 0;
         nbr = dom->total_pages;
diff -r 7244cea070fc tools/libxc/xc_dom_x86.c
--- a/tools/libxc/xc_dom_x86.c	Tue Nov 15 11:18:34 2011 +0100
+++ b/tools/libxc/xc_dom_x86.c	Tue Dec 06 10:28:03 2011 +0100
@@ -89,7 +89,7 @@ static int count_pgtables(struct xc_dom_
     pages = extra_pages;
     for ( ; ; )
     {
-        try_virt_end = round_up(dom->virt_alloc_end + pages * PAGE_SIZE_X86,
+        try_virt_end = round_up(dom->virt_alloc_end + pages * XC_PAGE_SIZE,
                                 bits_to_mask(22)); /* 4MB alignment */
         dom->pg_l4 =
             nr_page_tables(dom, dom->parms.virt_base, try_virt_end, l4_bits);
@@ -107,7 +107,7 @@ static int count_pgtables(struct xc_dom_
         }
         dom->pgtables = dom->pg_l4 + dom->pg_l3 + dom->pg_l2 + dom->pg_l1;
         pages = dom->pgtables + extra_pages;
-        if ( dom->virt_alloc_end + pages * PAGE_SIZE_X86 <= try_virt_end + 1 )
+        if ( dom->virt_alloc_end + pages * XC_PAGE_SIZE <= try_virt_end + 1 )
             break;
     }
     dom->virt_pgtab_end = try_virt_end + 1;
@@ -132,7 +132,7 @@ static int count_pgtables_x86_32_pae(str
                           L3_PAGETABLE_SHIFT_PAE, L2_PAGETABLE_SHIFT_PAE);
 }
 
-#define pfn_to_paddr(pfn) ((xen_paddr_t)(pfn) << PAGE_SHIFT_X86)
+#define pfn_to_paddr(pfn) ((xen_paddr_t)(pfn) << XC_PAGE_SHIFT)
 
 static int setup_pgtables_x86_32(struct xc_dom_image *dom)
 {
@@ -145,7 +145,7 @@ static int setup_pgtables_x86_32(struct 
     xen_pfn_t pgpfn;
 
     for ( addr = dom->parms.virt_base; addr < dom->virt_pgtab_end;
-          addr += PAGE_SIZE_X86 )
+          addr += XC_PAGE_SIZE )
     {
         if ( l1tab == NULL )
         {
@@ -159,7 +159,7 @@ static int setup_pgtables_x86_32(struct 
 
         /* make L1 entry */
         l1off = l1_table_offset_i386(addr);
-        pgpfn = (addr - dom->parms.virt_base) >> PAGE_SHIFT_X86;
+        pgpfn = (addr - dom->parms.virt_base) >> XC_PAGE_SHIFT;
         l1tab[l1off] =
             pfn_to_paddr(xc_dom_p2m_guest(dom, pgpfn)) | L1_PROT;
         if ( (addr >= dom->pgtables_seg.vstart) && 
@@ -264,7 +264,7 @@ static int setup_pgtables_x86_32_pae(str
     l3tab = xc_dom_pfn_to_ptr(dom, l3pfn, 1);
 
     for ( addr = dom->parms.virt_base; addr < dom->virt_pgtab_end;
-          addr += PAGE_SIZE_X86 )
+          addr += XC_PAGE_SIZE )
     {
         if ( l2tab == NULL )
         {
@@ -290,7 +290,7 @@ static int setup_pgtables_x86_32_pae(str
 
         /* make L1 entry */
         l1off = l1_table_offset_pae(addr);
-        pgpfn = (addr - dom->parms.virt_base) >> PAGE_SHIFT_X86;
+        pgpfn = (addr - dom->parms.virt_base) >> XC_PAGE_SHIFT;
         l1tab[l1off] =
             pfn_to_paddr(xc_dom_p2m_guest(dom, pgpfn)) | L1_PROT;
         if ( (addr >= dom->pgtables_seg.vstart) &&
@@ -345,7 +345,7 @@ static int setup_pgtables_x86_64(struct 
     xen_pfn_t pgpfn;
 
     for ( addr = dom->parms.virt_base; addr < dom->virt_pgtab_end;
-          addr += PAGE_SIZE_X86 )
+          addr += XC_PAGE_SIZE )
     {
         if ( l3tab == NULL )
         {
@@ -383,7 +383,7 @@ static int setup_pgtables_x86_64(struct 
 
         /* make L1 entry */
         l1off = l1_table_offset_x86_64(addr);
-        pgpfn = (addr - dom->parms.virt_base) >> PAGE_SHIFT_X86;
+        pgpfn = (addr - dom->parms.virt_base) >> XC_PAGE_SHIFT;
         l1tab[l1off] =
             pfn_to_paddr(xc_dom_p2m_guest(dom, pgpfn)) | L1_PROT;
         if ( (addr >= dom->pgtables_seg.vstart) && 
@@ -438,7 +438,7 @@ static int start_info_x86_32(struct xc_d
     strncpy(start_info->magic, dom->guest_type, sizeof(start_info->magic));
     start_info->magic[sizeof(start_info->magic) - 1] = '\0';
     start_info->nr_pages = dom->total_pages;
-    start_info->shared_info = shinfo << PAGE_SHIFT_X86;
+    start_info->shared_info = shinfo << XC_PAGE_SHIFT;
     start_info->pt_base = dom->pgtables_seg.vstart;
     start_info->nr_pt_frames = dom->pgtables;
     start_info->mfn_list = dom->p2m_seg.vstart;
@@ -478,7 +478,7 @@ static int start_info_x86_64(struct xc_d
     strncpy(start_info->magic, dom->guest_type, sizeof(start_info->magic));
     start_info->magic[sizeof(start_info->magic) - 1] = '\0';
     start_info->nr_pages = dom->total_pages;
-    start_info->shared_info = shinfo << PAGE_SHIFT_X86;
+    start_info->shared_info = shinfo << XC_PAGE_SHIFT;
     start_info->pt_base = dom->pgtables_seg.vstart;
     start_info->nr_pt_frames = dom->pgtables;
     start_info->mfn_list = dom->p2m_seg.vstart;
@@ -550,9 +550,9 @@ static int vcpu_x86_32(struct xc_dom_ima
     ctxt->user_regs.cs = FLAT_KERNEL_CS_X86_32;
     ctxt->user_regs.eip = dom->parms.virt_entry;
     ctxt->user_regs.esp =
-        dom->parms.virt_base + (dom->bootstack_pfn + 1) * PAGE_SIZE_X86;
+        dom->parms.virt_base + (dom->bootstack_pfn + 1) * XC_PAGE_SIZE;
     ctxt->user_regs.esi =
-        dom->parms.virt_base + (dom->start_info_pfn) * PAGE_SIZE_X86;
+        dom->parms.virt_base + (dom->start_info_pfn) * XC_PAGE_SIZE;
     ctxt->user_regs.eflags = 1 << 9; /* Interrupt Enable */
 
     ctxt->kernel_ss = ctxt->user_regs.ss;
@@ -589,9 +589,9 @@ static int vcpu_x86_64(struct xc_dom_ima
     ctxt->user_regs.cs = FLAT_KERNEL_CS_X86_64;
     ctxt->user_regs.rip = dom->parms.virt_entry;
     ctxt->user_regs.rsp =
-        dom->parms.virt_base + (dom->bootstack_pfn + 1) * PAGE_SIZE_X86;
+        dom->parms.virt_base + (dom->bootstack_pfn + 1) * XC_PAGE_SIZE;
     ctxt->user_regs.rsi =
-        dom->parms.virt_base + (dom->start_info_pfn) * PAGE_SIZE_X86;
+        dom->parms.virt_base + (dom->start_info_pfn) * XC_PAGE_SIZE;
     ctxt->user_regs.rflags = 1 << 9; /* Interrupt Enable */
 
     ctxt->kernel_ss = ctxt->user_regs.ss;
@@ -611,7 +611,7 @@ static int vcpu_x86_64(struct xc_dom_ima
 static struct xc_dom_arch xc_dom_32 = {
     .guest_type = "xen-3.0-x86_32",
     .native_protocol = XEN_IO_PROTO_ABI_X86_32,
-    .page_shift = PAGE_SHIFT_X86,
+    .page_shift = XC_PAGE_SHIFT,
     .sizeof_pfn = 4,
     .alloc_magic_pages = alloc_magic_pages,
     .count_pgtables = count_pgtables_x86_32,
@@ -623,7 +623,7 @@ static struct xc_dom_arch xc_dom_32 = {
 static struct xc_dom_arch xc_dom_32_pae = {
     .guest_type = "xen-3.0-x86_32p",
     .native_protocol = XEN_IO_PROTO_ABI_X86_32,
-    .page_shift = PAGE_SHIFT_X86,
+    .page_shift = XC_PAGE_SHIFT,
     .sizeof_pfn = 4,
     .alloc_magic_pages = alloc_magic_pages,
     .count_pgtables = count_pgtables_x86_32_pae,
@@ -636,7 +636,7 @@ static struct xc_dom_arch xc_dom_32_pae 
 static struct xc_dom_arch xc_dom_64 = {
     .guest_type = "xen-3.0-x86_64",
     .native_protocol = XEN_IO_PROTO_ABI_X86_64,
-    .page_shift = PAGE_SHIFT_X86,
+    .page_shift = XC_PAGE_SHIFT,
     .sizeof_pfn = 8,
     .alloc_magic_pages = alloc_magic_pages,
     .count_pgtables = count_pgtables_x86_64,
@@ -855,13 +855,13 @@ int arch_setup_bootlate(struct xc_dom_im
     DOMPRINTF("%s: shared_info: pfn 0x%" PRIpfn ", mfn 0x%" PRIpfn "",
               __FUNCTION__, dom->shared_info_pfn, dom->shared_info_mfn);
     shared_info = xc_map_foreign_range(dom->xch, dom->guest_domid,
-                                       PAGE_SIZE_X86,
+                                       XC_PAGE_SIZE,
                                        PROT_READ | PROT_WRITE,
                                        shinfo);
     if ( shared_info == NULL )
         return -1;
     dom->arch_hooks->shared_info(dom, shared_info);
-    munmap(shared_info, PAGE_SIZE_X86);
+    munmap(shared_info, XC_PAGE_SIZE);
 
     return 0;
 }
diff -r 7244cea070fc tools/libxc/xc_offline_page.c
--- a/tools/libxc/xc_offline_page.c	Tue Nov 15 11:18:34 2011 +0100
+++ b/tools/libxc/xc_offline_page.c	Tue Dec 06 10:28:03 2011 +0100
@@ -369,7 +369,7 @@ static int __clear_pte(xc_interface *xch
 
     /* XXX Check for PSE bit here */
     /* Hit one entry */
-    if ( ((pte >> PAGE_SHIFT_X86) & MFN_MASK_X86) == mfn)
+    if ( ((pte >> XC_PAGE_SHIFT) & MFN_MASK_X86) == mfn)
     {
         *new_pte = pte & ~_PAGE_PRESENT;
         if (!backup_ptes(table_mfn, table_offset, backup))
@@ -400,7 +400,7 @@ static int __update_pte(xc_interface *xc
         if (pte & _PAGE_PRESENT)
             ERROR("Page present while in backup ptes\n");
         pte &= ~MFN_MASK_X86;
-        pte |= (new_mfn << PAGE_SHIFT_X86) | _PAGE_PRESENT;
+        pte |= (new_mfn << XC_PAGE_SHIFT) | _PAGE_PRESENT;
         *new_pte = pte;
         return 1;
     }
diff -r 7244cea070fc tools/libxc/xg_private.h
--- a/tools/libxc/xg_private.h	Tue Nov 15 11:18:34 2011 +0100
+++ b/tools/libxc/xg_private.h	Tue Dec 06 10:28:03 2011 +0100
@@ -148,16 +148,8 @@ typedef l4_pgentry_64_t l4_pgentry_t;
 #define l4_table_offset(_a) l4_table_offset_x86_64(_a)
 #endif
 
-#define PAGE_SHIFT_X86          12
-#define PAGE_SIZE_X86           (1UL << PAGE_SHIFT_X86)
-#define PAGE_MASK_X86           (~(PAGE_SIZE_X86-1))
-
-#define PAGE_SHIFT_IA64         14
-#define PAGE_SIZE_IA64          (1UL << PAGE_SHIFT_IA64)
-#define PAGE_MASK_IA64          (~(PAGE_SIZE_IA64-1))
-
 #define ROUNDUP(_x,_w) (((unsigned long)(_x)+(1UL<<(_w))-1) & ~((1UL<<(_w))-1))
-#define NRPAGES(x) (ROUNDUP(x, PAGE_SHIFT) >> PAGE_SHIFT)
+#define NRPAGES(x) (ROUNDUP(x, XC_PAGE_SHIFT) >> XC_PAGE_SHIFT)
 
 
 /* XXX SMH: following skanky macros rely on variable p2m_size being set */
@@ -169,7 +161,7 @@ struct domain_info_context {
 };
 
 /* Number of xen_pfn_t in a page */
-#define FPP             (PAGE_SIZE/(dinfo->guest_width))
+#define FPP             (XC_PAGE_SIZE/(dinfo->guest_width))
 
 /* Number of entries in the pfn_to_mfn_frame_list_list */
 #define P2M_FLL_ENTRIES (((dinfo->p2m_size)+(FPP*FPP)-1)/(FPP*FPP))
@@ -184,8 +176,8 @@ struct domain_info_context {
 
 /* Masks for PTE<->PFN conversions */
 #define MADDR_BITS_X86  ((dinfo->guest_width == 8) ? 52 : 44)
-#define MFN_MASK_X86    ((1ULL << (MADDR_BITS_X86 - PAGE_SHIFT_X86)) - 1)
-#define MADDR_MASK_X86  (MFN_MASK_X86 << PAGE_SHIFT_X86)
+#define MFN_MASK_X86    ((1ULL << (MADDR_BITS_X86 - XC_PAGE_SHIFT)) - 1)
+#define MADDR_MASK_X86  (MFN_MASK_X86 << XC_PAGE_SHIFT)
 
 
 #define PAEKERN_no           0

--------------010807080500050607060300
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--------------010807080500050607060300--


From xen-devel-bounces@lists.xensource.com Tue Dec 06 09:36:20 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 09:36:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXrR3-00056U-AR; Tue, 06 Dec 2011 09:35:37 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Christoph.Egger@amd.com>) id 1RXrR1-00056G-61
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 09:35:35 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1323164087!4416529!1
X-Originating-IP: [216.32.181.183]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19198 invoked from network); 6 Dec 2011 09:34:48 -0000
Received: from ch1ehsobe003.messaging.microsoft.com (HELO
	ch1outboundpool.messaging.microsoft.com) (216.32.181.183)
	by server-11.tower-174.messagelabs.com with AES128-SHA encrypted SMTP;
	6 Dec 2011 09:34:48 -0000
Received: from mail78-ch1-R.bigfish.com (10.43.68.247) by
	CH1EHSOBE006.bigfish.com (10.43.70.56) with Microsoft SMTP Server id
	14.1.225.23; Tue, 6 Dec 2011 09:34:47 +0000
Received: from mail78-ch1 (localhost.localdomain [127.0.0.1])	by
	mail78-ch1-R.bigfish.com (Postfix) with ESMTP id B3F99190506;
	Tue,  6 Dec 2011 09:34:40 +0000 (UTC)
X-SpamScore: 1
X-BigFish: VPS1(zzc85dhzz1202hzz8275bhz32i668h839h34h)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
Received: from mail78-ch1 (localhost.localdomain [127.0.0.1]) by mail78-ch1
	(MessageSwitch) id 1323164062774076_32179;
	Tue,  6 Dec 2011 09:34:22 +0000 (UTC)
Received: from CH1EHSMHS029.bigfish.com (snatpool1.int.messaging.microsoft.com
	[10.43.68.250])	by mail78-ch1.bigfish.com (Postfix) with ESMTP id
	44BB8BE8062;	Tue,  6 Dec 2011 09:34:22 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	CH1EHSMHS029.bigfish.com (10.43.70.29) with Microsoft SMTP Server id
	14.1.225.23; Tue, 6 Dec 2011 09:34:21 +0000
X-WSS-ID: 0LVRZX7-01-8TF-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2E0DA102802A;	Tue,  6 Dec 2011 03:34:19 -0600 (CST)
Received: from SAUSEXDAG01.amd.com (163.181.55.1) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Tue, 6 Dec 2011 03:34:27 -0600
Received: from storexhtp02.amd.com (172.24.4.4) by sausexdag01.amd.com
	(163.181.55.1) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Tue, 6 Dec 2011 03:34:19 -0600
Received: from rhodium.osrc.amd.com (165.204.15.173) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Tue, 6 Dec 2011
	04:34:18 -0500
Message-ID: <4EDDE199.2090801@amd.com>
Date: Tue, 6 Dec 2011 10:34:17 +0100
From: Christoph Egger <Christoph.Egger@amd.com>
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:8.0) Gecko/20111114 Thunderbird/8.0
MIME-Version: 1.0
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Ian
	Campbell <Ian.Campbell@citrix.com>
Content-Type: multipart/mixed; boundary="------------010807080500050607060300"
X-OriginatorOrg: amd.com
Subject: [Xen-devel] [PATCH] libxc: switch to XC_PAGE_*
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--------------010807080500050607060300
Content-Type: text/plain; charset="ISO-8859-15"; format=flowed
Content-Transfer-Encoding: 7bit


Switch to a consistent set of XC_PAGE_* constants.

Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>


-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo, Andrew Bowd
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632

--------------010807080500050607060300
Content-Type: text/plain; name="xen_libxc_page.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="xen_libxc_page.diff"
Content-Description: xen_libxc_page.diff

diff -r 7244cea070fc tools/libxc/xc_dom_ia64.c
--- a/tools/libxc/xc_dom_ia64.c	Tue Nov 15 11:18:34 2011 +0100
+++ b/tools/libxc/xc_dom_ia64.c	Tue Dec 06 10:28:03 2011 +0100
@@ -83,7 +83,7 @@ int start_info_ia64(struct xc_dom_image 
         bp->initrd_start = start_info->mod_start;
         bp->initrd_size = start_info->mod_len;
     }
-    bp->command_line = (dom->start_info_pfn << PAGE_SHIFT_IA64)
+    bp->command_line = (dom->start_info_pfn << XC_PAGE_SHIFT)
         + offsetof(start_info_t, cmd_line);
     if ( dom->cmdline )
     {
@@ -128,7 +128,7 @@ static int vcpu_ia64(struct xc_dom_image
 #ifdef __ia64__			/* FIXME */
     ctxt->regs.ar.fpsr = xc_ia64_fpsr_default();
 #endif
-    ctxt->regs.r[28] = (dom->start_info_pfn << PAGE_SHIFT_IA64)
+    ctxt->regs.r[28] = (dom->start_info_pfn << XC_PAGE_SHIFT)
         + sizeof(start_info_ia64_t);
     return 0;
 }
@@ -138,7 +138,7 @@ static int vcpu_ia64(struct xc_dom_image
 static struct xc_dom_arch xc_dom_arch = {
     .guest_type = "xen-3.0-ia64",
     .native_protocol = XEN_IO_PROTO_ABI_IA64,
-    .page_shift = PAGE_SHIFT_IA64,
+    .page_shift = XC_PAGE_SHIFT,
     .alloc_magic_pages = alloc_magic_pages,
     .start_info = start_info_ia64,
     .shared_info = shared_info_ia64,
@@ -148,7 +148,7 @@ static struct xc_dom_arch xc_dom_arch = 
 static struct xc_dom_arch xc_dom_arch_ia64be = {
     .guest_type = "xen-3.0-ia64be",
     .native_protocol = XEN_IO_PROTO_ABI_IA64,
-    .page_shift = PAGE_SHIFT_IA64,
+    .page_shift = XC_PAGE_SHIFT,
     .alloc_magic_pages = alloc_magic_pages,
     .start_info = start_info_ia64,
     .shared_info = shared_info_ia64,
@@ -173,8 +173,8 @@ int arch_setup_meminit(struct xc_dom_ima
     /* setup initial p2m */
     if (dom->guest_type && strcmp(dom->guest_type,
                                   "hvm-3.0-ia64-sioemu") == 0) {
-        start = FW_MEM_BASE >> PAGE_SHIFT_IA64;
-        nbr = FW_MEM_SIZE >> PAGE_SHIFT_IA64;
+        start = FW_MEM_BASE >> XC_PAGE_SHIFT;
+        nbr = FW_MEM_SIZE >> XC_PAGE_SHIFT;
     } else {
         start = 0;
         nbr = dom->total_pages;
diff -r 7244cea070fc tools/libxc/xc_dom_x86.c
--- a/tools/libxc/xc_dom_x86.c	Tue Nov 15 11:18:34 2011 +0100
+++ b/tools/libxc/xc_dom_x86.c	Tue Dec 06 10:28:03 2011 +0100
@@ -89,7 +89,7 @@ static int count_pgtables(struct xc_dom_
     pages = extra_pages;
     for ( ; ; )
     {
-        try_virt_end = round_up(dom->virt_alloc_end + pages * PAGE_SIZE_X86,
+        try_virt_end = round_up(dom->virt_alloc_end + pages * XC_PAGE_SIZE,
                                 bits_to_mask(22)); /* 4MB alignment */
         dom->pg_l4 =
             nr_page_tables(dom, dom->parms.virt_base, try_virt_end, l4_bits);
@@ -107,7 +107,7 @@ static int count_pgtables(struct xc_dom_
         }
         dom->pgtables = dom->pg_l4 + dom->pg_l3 + dom->pg_l2 + dom->pg_l1;
         pages = dom->pgtables + extra_pages;
-        if ( dom->virt_alloc_end + pages * PAGE_SIZE_X86 <= try_virt_end + 1 )
+        if ( dom->virt_alloc_end + pages * XC_PAGE_SIZE <= try_virt_end + 1 )
             break;
     }
     dom->virt_pgtab_end = try_virt_end + 1;
@@ -132,7 +132,7 @@ static int count_pgtables_x86_32_pae(str
                           L3_PAGETABLE_SHIFT_PAE, L2_PAGETABLE_SHIFT_PAE);
 }
 
-#define pfn_to_paddr(pfn) ((xen_paddr_t)(pfn) << PAGE_SHIFT_X86)
+#define pfn_to_paddr(pfn) ((xen_paddr_t)(pfn) << XC_PAGE_SHIFT)
 
 static int setup_pgtables_x86_32(struct xc_dom_image *dom)
 {
@@ -145,7 +145,7 @@ static int setup_pgtables_x86_32(struct 
     xen_pfn_t pgpfn;
 
     for ( addr = dom->parms.virt_base; addr < dom->virt_pgtab_end;
-          addr += PAGE_SIZE_X86 )
+          addr += XC_PAGE_SIZE )
     {
         if ( l1tab == NULL )
         {
@@ -159,7 +159,7 @@ static int setup_pgtables_x86_32(struct 
 
         /* make L1 entry */
         l1off = l1_table_offset_i386(addr);
-        pgpfn = (addr - dom->parms.virt_base) >> PAGE_SHIFT_X86;
+        pgpfn = (addr - dom->parms.virt_base) >> XC_PAGE_SHIFT;
         l1tab[l1off] =
             pfn_to_paddr(xc_dom_p2m_guest(dom, pgpfn)) | L1_PROT;
         if ( (addr >= dom->pgtables_seg.vstart) && 
@@ -264,7 +264,7 @@ static int setup_pgtables_x86_32_pae(str
     l3tab = xc_dom_pfn_to_ptr(dom, l3pfn, 1);
 
     for ( addr = dom->parms.virt_base; addr < dom->virt_pgtab_end;
-          addr += PAGE_SIZE_X86 )
+          addr += XC_PAGE_SIZE )
     {
         if ( l2tab == NULL )
         {
@@ -290,7 +290,7 @@ static int setup_pgtables_x86_32_pae(str
 
         /* make L1 entry */
         l1off = l1_table_offset_pae(addr);
-        pgpfn = (addr - dom->parms.virt_base) >> PAGE_SHIFT_X86;
+        pgpfn = (addr - dom->parms.virt_base) >> XC_PAGE_SHIFT;
         l1tab[l1off] =
             pfn_to_paddr(xc_dom_p2m_guest(dom, pgpfn)) | L1_PROT;
         if ( (addr >= dom->pgtables_seg.vstart) &&
@@ -345,7 +345,7 @@ static int setup_pgtables_x86_64(struct 
     xen_pfn_t pgpfn;
 
     for ( addr = dom->parms.virt_base; addr < dom->virt_pgtab_end;
-          addr += PAGE_SIZE_X86 )
+          addr += XC_PAGE_SIZE )
     {
         if ( l3tab == NULL )
         {
@@ -383,7 +383,7 @@ static int setup_pgtables_x86_64(struct 
 
         /* make L1 entry */
         l1off = l1_table_offset_x86_64(addr);
-        pgpfn = (addr - dom->parms.virt_base) >> PAGE_SHIFT_X86;
+        pgpfn = (addr - dom->parms.virt_base) >> XC_PAGE_SHIFT;
         l1tab[l1off] =
             pfn_to_paddr(xc_dom_p2m_guest(dom, pgpfn)) | L1_PROT;
         if ( (addr >= dom->pgtables_seg.vstart) && 
@@ -438,7 +438,7 @@ static int start_info_x86_32(struct xc_d
     strncpy(start_info->magic, dom->guest_type, sizeof(start_info->magic));
     start_info->magic[sizeof(start_info->magic) - 1] = '\0';
     start_info->nr_pages = dom->total_pages;
-    start_info->shared_info = shinfo << PAGE_SHIFT_X86;
+    start_info->shared_info = shinfo << XC_PAGE_SHIFT;
     start_info->pt_base = dom->pgtables_seg.vstart;
     start_info->nr_pt_frames = dom->pgtables;
     start_info->mfn_list = dom->p2m_seg.vstart;
@@ -478,7 +478,7 @@ static int start_info_x86_64(struct xc_d
     strncpy(start_info->magic, dom->guest_type, sizeof(start_info->magic));
     start_info->magic[sizeof(start_info->magic) - 1] = '\0';
     start_info->nr_pages = dom->total_pages;
-    start_info->shared_info = shinfo << PAGE_SHIFT_X86;
+    start_info->shared_info = shinfo << XC_PAGE_SHIFT;
     start_info->pt_base = dom->pgtables_seg.vstart;
     start_info->nr_pt_frames = dom->pgtables;
     start_info->mfn_list = dom->p2m_seg.vstart;
@@ -550,9 +550,9 @@ static int vcpu_x86_32(struct xc_dom_ima
     ctxt->user_regs.cs = FLAT_KERNEL_CS_X86_32;
     ctxt->user_regs.eip = dom->parms.virt_entry;
     ctxt->user_regs.esp =
-        dom->parms.virt_base + (dom->bootstack_pfn + 1) * PAGE_SIZE_X86;
+        dom->parms.virt_base + (dom->bootstack_pfn + 1) * XC_PAGE_SIZE;
     ctxt->user_regs.esi =
-        dom->parms.virt_base + (dom->start_info_pfn) * PAGE_SIZE_X86;
+        dom->parms.virt_base + (dom->start_info_pfn) * XC_PAGE_SIZE;
     ctxt->user_regs.eflags = 1 << 9; /* Interrupt Enable */
 
     ctxt->kernel_ss = ctxt->user_regs.ss;
@@ -589,9 +589,9 @@ static int vcpu_x86_64(struct xc_dom_ima
     ctxt->user_regs.cs = FLAT_KERNEL_CS_X86_64;
     ctxt->user_regs.rip = dom->parms.virt_entry;
     ctxt->user_regs.rsp =
-        dom->parms.virt_base + (dom->bootstack_pfn + 1) * PAGE_SIZE_X86;
+        dom->parms.virt_base + (dom->bootstack_pfn + 1) * XC_PAGE_SIZE;
     ctxt->user_regs.rsi =
-        dom->parms.virt_base + (dom->start_info_pfn) * PAGE_SIZE_X86;
+        dom->parms.virt_base + (dom->start_info_pfn) * XC_PAGE_SIZE;
     ctxt->user_regs.rflags = 1 << 9; /* Interrupt Enable */
 
     ctxt->kernel_ss = ctxt->user_regs.ss;
@@ -611,7 +611,7 @@ static int vcpu_x86_64(struct xc_dom_ima
 static struct xc_dom_arch xc_dom_32 = {
     .guest_type = "xen-3.0-x86_32",
     .native_protocol = XEN_IO_PROTO_ABI_X86_32,
-    .page_shift = PAGE_SHIFT_X86,
+    .page_shift = XC_PAGE_SHIFT,
     .sizeof_pfn = 4,
     .alloc_magic_pages = alloc_magic_pages,
     .count_pgtables = count_pgtables_x86_32,
@@ -623,7 +623,7 @@ static struct xc_dom_arch xc_dom_32 = {
 static struct xc_dom_arch xc_dom_32_pae = {
     .guest_type = "xen-3.0-x86_32p",
     .native_protocol = XEN_IO_PROTO_ABI_X86_32,
-    .page_shift = PAGE_SHIFT_X86,
+    .page_shift = XC_PAGE_SHIFT,
     .sizeof_pfn = 4,
     .alloc_magic_pages = alloc_magic_pages,
     .count_pgtables = count_pgtables_x86_32_pae,
@@ -636,7 +636,7 @@ static struct xc_dom_arch xc_dom_32_pae 
 static struct xc_dom_arch xc_dom_64 = {
     .guest_type = "xen-3.0-x86_64",
     .native_protocol = XEN_IO_PROTO_ABI_X86_64,
-    .page_shift = PAGE_SHIFT_X86,
+    .page_shift = XC_PAGE_SHIFT,
     .sizeof_pfn = 8,
     .alloc_magic_pages = alloc_magic_pages,
     .count_pgtables = count_pgtables_x86_64,
@@ -855,13 +855,13 @@ int arch_setup_bootlate(struct xc_dom_im
     DOMPRINTF("%s: shared_info: pfn 0x%" PRIpfn ", mfn 0x%" PRIpfn "",
               __FUNCTION__, dom->shared_info_pfn, dom->shared_info_mfn);
     shared_info = xc_map_foreign_range(dom->xch, dom->guest_domid,
-                                       PAGE_SIZE_X86,
+                                       XC_PAGE_SIZE,
                                        PROT_READ | PROT_WRITE,
                                        shinfo);
     if ( shared_info == NULL )
         return -1;
     dom->arch_hooks->shared_info(dom, shared_info);
-    munmap(shared_info, PAGE_SIZE_X86);
+    munmap(shared_info, XC_PAGE_SIZE);
 
     return 0;
 }
diff -r 7244cea070fc tools/libxc/xc_offline_page.c
--- a/tools/libxc/xc_offline_page.c	Tue Nov 15 11:18:34 2011 +0100
+++ b/tools/libxc/xc_offline_page.c	Tue Dec 06 10:28:03 2011 +0100
@@ -369,7 +369,7 @@ static int __clear_pte(xc_interface *xch
 
     /* XXX Check for PSE bit here */
     /* Hit one entry */
-    if ( ((pte >> PAGE_SHIFT_X86) & MFN_MASK_X86) == mfn)
+    if ( ((pte >> XC_PAGE_SHIFT) & MFN_MASK_X86) == mfn)
     {
         *new_pte = pte & ~_PAGE_PRESENT;
         if (!backup_ptes(table_mfn, table_offset, backup))
@@ -400,7 +400,7 @@ static int __update_pte(xc_interface *xc
         if (pte & _PAGE_PRESENT)
             ERROR("Page present while in backup ptes\n");
         pte &= ~MFN_MASK_X86;
-        pte |= (new_mfn << PAGE_SHIFT_X86) | _PAGE_PRESENT;
+        pte |= (new_mfn << XC_PAGE_SHIFT) | _PAGE_PRESENT;
         *new_pte = pte;
         return 1;
     }
diff -r 7244cea070fc tools/libxc/xg_private.h
--- a/tools/libxc/xg_private.h	Tue Nov 15 11:18:34 2011 +0100
+++ b/tools/libxc/xg_private.h	Tue Dec 06 10:28:03 2011 +0100
@@ -148,16 +148,8 @@ typedef l4_pgentry_64_t l4_pgentry_t;
 #define l4_table_offset(_a) l4_table_offset_x86_64(_a)
 #endif
 
-#define PAGE_SHIFT_X86          12
-#define PAGE_SIZE_X86           (1UL << PAGE_SHIFT_X86)
-#define PAGE_MASK_X86           (~(PAGE_SIZE_X86-1))
-
-#define PAGE_SHIFT_IA64         14
-#define PAGE_SIZE_IA64          (1UL << PAGE_SHIFT_IA64)
-#define PAGE_MASK_IA64          (~(PAGE_SIZE_IA64-1))
-
 #define ROUNDUP(_x,_w) (((unsigned long)(_x)+(1UL<<(_w))-1) & ~((1UL<<(_w))-1))
-#define NRPAGES(x) (ROUNDUP(x, PAGE_SHIFT) >> PAGE_SHIFT)
+#define NRPAGES(x) (ROUNDUP(x, XC_PAGE_SHIFT) >> XC_PAGE_SHIFT)
 
 
 /* XXX SMH: following skanky macros rely on variable p2m_size being set */
@@ -169,7 +161,7 @@ struct domain_info_context {
 };
 
 /* Number of xen_pfn_t in a page */
-#define FPP             (PAGE_SIZE/(dinfo->guest_width))
+#define FPP             (XC_PAGE_SIZE/(dinfo->guest_width))
 
 /* Number of entries in the pfn_to_mfn_frame_list_list */
 #define P2M_FLL_ENTRIES (((dinfo->p2m_size)+(FPP*FPP)-1)/(FPP*FPP))
@@ -184,8 +176,8 @@ struct domain_info_context {
 
 /* Masks for PTE<->PFN conversions */
 #define MADDR_BITS_X86  ((dinfo->guest_width == 8) ? 52 : 44)
-#define MFN_MASK_X86    ((1ULL << (MADDR_BITS_X86 - PAGE_SHIFT_X86)) - 1)
-#define MADDR_MASK_X86  (MFN_MASK_X86 << PAGE_SHIFT_X86)
+#define MFN_MASK_X86    ((1ULL << (MADDR_BITS_X86 - XC_PAGE_SHIFT)) - 1)
+#define MADDR_MASK_X86  (MFN_MASK_X86 << XC_PAGE_SHIFT)
 
 
 #define PAEKERN_no           0

--------------010807080500050607060300
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--------------010807080500050607060300--


From xen-devel-bounces@lists.xensource.com Tue Dec 06 09:49:53 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 09:49:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXre3-0005HS-Pq; Tue, 06 Dec 2011 09:49:03 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RXre2-0005HJ-1z
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 09:49:02 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1323164849!59597913!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjM3Ng==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30439 invoked from network); 6 Dec 2011 09:47:29 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Dec 2011 09:47:29 -0000
X-IronPort-AV: E=Sophos;i="4.71,304,1320624000"; 
   d="scan'208";a="9308935"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Dec 2011 09:48:18 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Tue, 6 Dec 2011
	09:48:17 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Tue, 6 Dec 2011 09:48:17 +0000
In-Reply-To: <1322499580-2322-13-git-send-email-ian.jackson@eu.citrix.com>
References: <1322499580-2322-1-git-send-email-ian.jackson@eu.citrix.com>
	<1322499580-2322-13-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323164897.23681.27.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 12/13] libxl: New API for providing OS
 events to libxl
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2011-11-28 at 16:59 +0000, Ian Jackson wrote:
> @@ -89,10 +99,25 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
> 
>  int libxl_ctx_free(libxl_ctx *ctx)
>  {
> +    int i;
> +    GC_INIT(ctx);

You never call GC_FREE in this function. It's a bit of an odd one to
need in the free function I guess but I think you still need it after
the last call to a function which takes a gc argument?

> +
>      if (!ctx) return 0;
> +
> +    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_LIST_EMPTY(&ctx->efds));
> +    assert(LIBXL_TAILQ_EMPTY(&ctx->etimes));

Am I right that libxl__ev_fd_deregister is what ensures this is the
case? If not then who is responsible for unregistering akk events before
freeing a context?

I've just seen you've reposted the series so I'll stop here and pickup
in the repost instead.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 09:49:53 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 09:49:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXre3-0005HS-Pq; Tue, 06 Dec 2011 09:49:03 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RXre2-0005HJ-1z
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 09:49:02 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1323164849!59597913!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjM3Ng==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30439 invoked from network); 6 Dec 2011 09:47:29 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Dec 2011 09:47:29 -0000
X-IronPort-AV: E=Sophos;i="4.71,304,1320624000"; 
   d="scan'208";a="9308935"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Dec 2011 09:48:18 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Tue, 6 Dec 2011
	09:48:17 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Tue, 6 Dec 2011 09:48:17 +0000
In-Reply-To: <1322499580-2322-13-git-send-email-ian.jackson@eu.citrix.com>
References: <1322499580-2322-1-git-send-email-ian.jackson@eu.citrix.com>
	<1322499580-2322-13-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323164897.23681.27.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 12/13] libxl: New API for providing OS
 events to libxl
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2011-11-28 at 16:59 +0000, Ian Jackson wrote:
> @@ -89,10 +99,25 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
> 
>  int libxl_ctx_free(libxl_ctx *ctx)
>  {
> +    int i;
> +    GC_INIT(ctx);

You never call GC_FREE in this function. It's a bit of an odd one to
need in the free function I guess but I think you still need it after
the last call to a function which takes a gc argument?

> +
>      if (!ctx) return 0;
> +
> +    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_LIST_EMPTY(&ctx->efds));
> +    assert(LIBXL_TAILQ_EMPTY(&ctx->etimes));

Am I right that libxl__ev_fd_deregister is what ensures this is the
case? If not then who is responsible for unregistering akk events before
freeing a context?

I've just seen you've reposted the series so I'll stop here and pickup
in the repost instead.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 09:49:54 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 09:49:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXre4-0005HZ-SC; Tue, 06 Dec 2011 09:49:04 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RXre2-0005HI-DB
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 09:49:02 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1323164895!6335726!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM3Mzk=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5389 invoked from network); 6 Dec 2011 09:48:16 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-7.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 6 Dec 2011 09:48:16 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 06 Dec 2011 09:48:15 +0000
Message-Id: <4EDDF3190200007800065A38@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 06 Dec 2011 09:48:57 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
References: <patchbomb.1323098647@xdev.gridcentric.ca>
	<4c4a9ed0728c7ba34b09.1323098648@xdev.gridcentric.ca>
In-Reply-To: <4c4a9ed0728c7ba34b09.1323098648@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
Cc: olaf@aepfle.de, xen-devel@lists.xensource.com, andres@gridcentric.ca,
	tim@xen.org, keir.xen@gmail.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 1 of 2] Allow decrease_reservation to be
 preempted if remove_page returns negative
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 >>> On 05.12.11 at 16:24, Andres Lagar-Cavilla <andres@lagarcavilla.org> wrote:
> This will allow for handling of full paging rings in a more graceful manner.
> ATM, remove_page does not return negative values, so this code is not yet
> exercised.

Which makes the patch on its own be of questionable value...

> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
> 
> diff -r 790cd814bee8 -r 4c4a9ed0728c xen/common/memory.c
> --- a/xen/common/memory.c
> +++ b/xen/common/memory.c
> @@ -226,6 +226,8 @@ static void decrease_reservation(struct 
>  
>      for ( i = a->nr_done; i < a->nr_extents; i++ )
>      {
> +        int one_remove_succeeded = 0;
> +
>          if ( hypercall_preempt_check() )
>          {
>              a->preempted = 1;
> @@ -255,8 +257,33 @@ static void decrease_reservation(struct 
>              continue;
>  
>          for ( j = 0; j < (1 << a->extent_order); j++ )
> -            if ( !guest_remove_page(a->domain, gmfn + j) )
> +        {
> +            int rv = guest_remove_page(a->domain, gmfn + j);
> +            /* negative rv is a result of a mem event ring full
> +             * in the presence of paging. We preempt the hypercall */
> +            if ( rv < 0 )
> +            {
> +                /* Indicate we're done with this extent */
> +                if ((j+1) == (1 << a->extent_order))
> +                    i++;

So this implies that the page was actually acted upon? How that, if
the event ring was full? (That's part of the reason why doing the
change here without the change to guest_remove_page() is
bogus - one can't really review it in one step.)

> +                a->preempted = 1;
> +                raise_softirq(SCHEDULE_SOFTIRQ);

Do you really need to open code this *here* (rather than, if at all,
in guest_remove_page() or wherever else the event ring full
condition is actually being determined)?

>                  goto out;
> +            }
> +            /* rv of zero means we tried to remove a gfn with no backing
> +             * mfn. It can be a bad argument, or, a continuation in the midst
> +             * of an extent. Heuristically determine second case. */

Heuristically? What if this goes wrong (I can't really judge this from the
code below)?

Jan

> +            if ( !rv )
> +            {
> +                /* Has to be first extent */
> +                if ( i != a->nr_done )
> +                    goto out;
> +                /* No previous remove in this extent must have succeeded */
> +                if ( one_remove_succeeded )
> +                    goto out;
> +            } else
> +                one_remove_succeeded = 1;
> +        }
>      }
>  
>   out:
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com 
> http://lists.xensource.com/xen-devel 




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 09:49:54 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 09:49:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXre4-0005HZ-SC; Tue, 06 Dec 2011 09:49:04 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RXre2-0005HI-DB
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 09:49:02 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1323164895!6335726!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM3Mzk=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5389 invoked from network); 6 Dec 2011 09:48:16 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-7.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 6 Dec 2011 09:48:16 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 06 Dec 2011 09:48:15 +0000
Message-Id: <4EDDF3190200007800065A38@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 06 Dec 2011 09:48:57 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
References: <patchbomb.1323098647@xdev.gridcentric.ca>
	<4c4a9ed0728c7ba34b09.1323098648@xdev.gridcentric.ca>
In-Reply-To: <4c4a9ed0728c7ba34b09.1323098648@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
Cc: olaf@aepfle.de, xen-devel@lists.xensource.com, andres@gridcentric.ca,
	tim@xen.org, keir.xen@gmail.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 1 of 2] Allow decrease_reservation to be
 preempted if remove_page returns negative
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 >>> On 05.12.11 at 16:24, Andres Lagar-Cavilla <andres@lagarcavilla.org> wrote:
> This will allow for handling of full paging rings in a more graceful manner.
> ATM, remove_page does not return negative values, so this code is not yet
> exercised.

Which makes the patch on its own be of questionable value...

> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
> 
> diff -r 790cd814bee8 -r 4c4a9ed0728c xen/common/memory.c
> --- a/xen/common/memory.c
> +++ b/xen/common/memory.c
> @@ -226,6 +226,8 @@ static void decrease_reservation(struct 
>  
>      for ( i = a->nr_done; i < a->nr_extents; i++ )
>      {
> +        int one_remove_succeeded = 0;
> +
>          if ( hypercall_preempt_check() )
>          {
>              a->preempted = 1;
> @@ -255,8 +257,33 @@ static void decrease_reservation(struct 
>              continue;
>  
>          for ( j = 0; j < (1 << a->extent_order); j++ )
> -            if ( !guest_remove_page(a->domain, gmfn + j) )
> +        {
> +            int rv = guest_remove_page(a->domain, gmfn + j);
> +            /* negative rv is a result of a mem event ring full
> +             * in the presence of paging. We preempt the hypercall */
> +            if ( rv < 0 )
> +            {
> +                /* Indicate we're done with this extent */
> +                if ((j+1) == (1 << a->extent_order))
> +                    i++;

So this implies that the page was actually acted upon? How that, if
the event ring was full? (That's part of the reason why doing the
change here without the change to guest_remove_page() is
bogus - one can't really review it in one step.)

> +                a->preempted = 1;
> +                raise_softirq(SCHEDULE_SOFTIRQ);

Do you really need to open code this *here* (rather than, if at all,
in guest_remove_page() or wherever else the event ring full
condition is actually being determined)?

>                  goto out;
> +            }
> +            /* rv of zero means we tried to remove a gfn with no backing
> +             * mfn. It can be a bad argument, or, a continuation in the midst
> +             * of an extent. Heuristically determine second case. */

Heuristically? What if this goes wrong (I can't really judge this from the
code below)?

Jan

> +            if ( !rv )
> +            {
> +                /* Has to be first extent */
> +                if ( i != a->nr_done )
> +                    goto out;
> +                /* No previous remove in this extent must have succeeded */
> +                if ( one_remove_succeeded )
> +                    goto out;
> +            } else
> +                one_remove_succeeded = 1;
> +        }
>      }
>  
>   out:
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com 
> http://lists.xensource.com/xen-devel 




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 10:09:38 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 10: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.xensource.com>)
	id 1RXrxS-0005jx-W1; Tue, 06 Dec 2011 10:09:06 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1RXrxR-0005js-9V
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 10:09:05 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1323166098!6078795!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDcxMjI=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17193 invoked from network); 6 Dec 2011 10:08:19 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Dec 2011 10:08:19 -0000
X-IronPort-AV: E=Sophos;i="4.71,304,1320642000"; d="scan'208";a="19696826"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Dec 2011 05:08:18 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Tue, 6 Dec 2011 05:08:18 -0500
Received: from testbox64.uk.xensource.com ([10.80.237.153])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pB6A8FJn017032;
	Tue, 6 Dec 2011 02:08:16 -0800
From: Wei Liu <wei.liu2@citrix.com>
To: xen-devel@lists.xensource.com, netdev@vger.kernel.org
Date: Tue, 6 Dec 2011 10:08:20 +0000
Message-ID: <1323166100-7059-1-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com
Subject: [Xen-devel] [PATCH] netback: remove redundant assignment
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

New value for netbk->mmap_pages[pending_idx] is assigned in
xen_netbk_alloc_page(), no need for a second assignment which
exposes internal to the outside world.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 drivers/net/xen-netback/netback.c |    4 ----
 1 files changed, 0 insertions(+), 4 deletions(-)

diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
index 15e332d..3ecb5aa 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -940,8 +940,6 @@ static struct gnttab_copy *xen_netbk_get_requests(struct xen_netbk *netbk,
 		if (!page)
 			return NULL;
 
-		netbk->mmap_pages[pending_idx] = page;
-
 		gop->source.u.ref = txp->gref;
 		gop->source.domid = vif->domid;
 		gop->source.offset = txp->offset;
@@ -1336,8 +1334,6 @@ static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk)
 			continue;
 		}
 
-		netbk->mmap_pages[pending_idx] = page;
-
 		gop->source.u.ref = txreq.gref;
 		gop->source.domid = vif->domid;
 		gop->source.offset = txreq.offset;
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 10:09:38 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 10: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.xensource.com>)
	id 1RXrxS-0005jx-W1; Tue, 06 Dec 2011 10:09:06 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1RXrxR-0005js-9V
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 10:09:05 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1323166098!6078795!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDcxMjI=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17193 invoked from network); 6 Dec 2011 10:08:19 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Dec 2011 10:08:19 -0000
X-IronPort-AV: E=Sophos;i="4.71,304,1320642000"; d="scan'208";a="19696826"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Dec 2011 05:08:18 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Tue, 6 Dec 2011 05:08:18 -0500
Received: from testbox64.uk.xensource.com ([10.80.237.153])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pB6A8FJn017032;
	Tue, 6 Dec 2011 02:08:16 -0800
From: Wei Liu <wei.liu2@citrix.com>
To: xen-devel@lists.xensource.com, netdev@vger.kernel.org
Date: Tue, 6 Dec 2011 10:08:20 +0000
Message-ID: <1323166100-7059-1-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com
Subject: [Xen-devel] [PATCH] netback: remove redundant assignment
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

New value for netbk->mmap_pages[pending_idx] is assigned in
xen_netbk_alloc_page(), no need for a second assignment which
exposes internal to the outside world.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 drivers/net/xen-netback/netback.c |    4 ----
 1 files changed, 0 insertions(+), 4 deletions(-)

diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
index 15e332d..3ecb5aa 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -940,8 +940,6 @@ static struct gnttab_copy *xen_netbk_get_requests(struct xen_netbk *netbk,
 		if (!page)
 			return NULL;
 
-		netbk->mmap_pages[pending_idx] = page;
-
 		gop->source.u.ref = txp->gref;
 		gop->source.domid = vif->domid;
 		gop->source.offset = txp->offset;
@@ -1336,8 +1334,6 @@ static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk)
 			continue;
 		}
 
-		netbk->mmap_pages[pending_idx] = page;
-
 		gop->source.u.ref = txreq.gref;
 		gop->source.domid = vif->domid;
 		gop->source.offset = txreq.offset;
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 10:12:31 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 10: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.xensource.com>)
	id 1RXs0H-0005pQ-JJ; Tue, 06 Dec 2011 10:12:01 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1RXs0G-0005pE-QT
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 10:12:01 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-3.tower-216.messagelabs.com!1323166274!6294491!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28686 invoked from network); 6 Dec 2011 10:11:15 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-3.tower-216.messagelabs.com with SMTP;
	6 Dec 2011 10:11:15 -0000
Received: from [62.94.142.85] (account d.faggioli@sssup.it HELO [192.168.0.40])
	by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 73708456; Tue, 06 Dec 2011 11:11:14 +0100
Message-ID: <1323166254.2605.2.camel@Solace>
From: Dario Faggioli <raistlin@linux.it>
To: Juergen Gross <juergen.gross@ts.fujitsu.com>
Date: Tue, 06 Dec 2011 11:10:54 +0100
In-Reply-To: <4EDDD485.70208@ts.fujitsu.com>
References: <1322060131.30168.15.camel@Abyss> <4EDDD485.70208@ts.fujitsu.com>
X-Mailer: Evolution 3.0.3-3 
Mime-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>, xen-devel@lists.xensource.com,
	Keir Fraser <keir@xen.org>
Subject: Re: [Xen-devel] [RFC/RFT][PATCH 0 of 3] rework locking in
 sched_adjust
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============2473035003343730490=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--===============2473035003343730490==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-1BuAHAKU/eX+yfeL/oT5"


--=-1BuAHAKU/eX+yfeL/oT5
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, 2011-12-06 at 09:38 +0100, Juergen Gross wrote:
> Sorry, does not work with sched=3Dsedf:
>=20
Hi Juergen,

Thanks for reporting. I'm reworking this as per Ian's suggestions, but
I'll check this out. Can I as how you made this happening? Just trying
to change a sedf-domain scheduling parameter I guess... Is that right?

Thanks again and Regards,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-------------------------------------------------------------------
Dario Faggioli, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
PhD Candidate, ReTiS Lab, Scuola Superiore Sant'Anna, Pisa (Italy)


--=-1BuAHAKU/eX+yfeL/oT5
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEABECAAYFAk7d6i4ACgkQk4XaBE3IOsQBfQCfVungGJauWQnDIDOFOwJW73jh
nZcAn10UyD+FP5AH6Wuj2qOUX9sUUzdJ
=qNZx
-----END PGP SIGNATURE-----

--=-1BuAHAKU/eX+yfeL/oT5--



--===============2473035003343730490==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============2473035003343730490==--



From xen-devel-bounces@lists.xensource.com Tue Dec 06 10:12:31 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 10: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.xensource.com>)
	id 1RXs0H-0005pQ-JJ; Tue, 06 Dec 2011 10:12:01 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1RXs0G-0005pE-QT
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 10:12:01 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-3.tower-216.messagelabs.com!1323166274!6294491!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28686 invoked from network); 6 Dec 2011 10:11:15 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-3.tower-216.messagelabs.com with SMTP;
	6 Dec 2011 10:11:15 -0000
Received: from [62.94.142.85] (account d.faggioli@sssup.it HELO [192.168.0.40])
	by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 73708456; Tue, 06 Dec 2011 11:11:14 +0100
Message-ID: <1323166254.2605.2.camel@Solace>
From: Dario Faggioli <raistlin@linux.it>
To: Juergen Gross <juergen.gross@ts.fujitsu.com>
Date: Tue, 06 Dec 2011 11:10:54 +0100
In-Reply-To: <4EDDD485.70208@ts.fujitsu.com>
References: <1322060131.30168.15.camel@Abyss> <4EDDD485.70208@ts.fujitsu.com>
X-Mailer: Evolution 3.0.3-3 
Mime-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>, xen-devel@lists.xensource.com,
	Keir Fraser <keir@xen.org>
Subject: Re: [Xen-devel] [RFC/RFT][PATCH 0 of 3] rework locking in
 sched_adjust
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============2473035003343730490=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--===============2473035003343730490==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-1BuAHAKU/eX+yfeL/oT5"


--=-1BuAHAKU/eX+yfeL/oT5
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, 2011-12-06 at 09:38 +0100, Juergen Gross wrote:
> Sorry, does not work with sched=3Dsedf:
>=20
Hi Juergen,

Thanks for reporting. I'm reworking this as per Ian's suggestions, but
I'll check this out. Can I as how you made this happening? Just trying
to change a sedf-domain scheduling parameter I guess... Is that right?

Thanks again and Regards,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-------------------------------------------------------------------
Dario Faggioli, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
PhD Candidate, ReTiS Lab, Scuola Superiore Sant'Anna, Pisa (Italy)


--=-1BuAHAKU/eX+yfeL/oT5
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEABECAAYFAk7d6i4ACgkQk4XaBE3IOsQBfQCfVungGJauWQnDIDOFOwJW73jh
nZcAn10UyD+FP5AH6Wuj2qOUX9sUUzdJ
=qNZx
-----END PGP SIGNATURE-----

--=-1BuAHAKU/eX+yfeL/oT5--



--===============2473035003343730490==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============2473035003343730490==--



From xen-devel-bounces@lists.xensource.com Tue Dec 06 10:22:50 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 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.xensource.com>)
	id 1RXsA5-00065x-US; Tue, 06 Dec 2011 10:22:09 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RXsA4-00065s-J2
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 10:22:08 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1323166882!6356199!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjM3Ng==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4260 invoked from network); 6 Dec 2011 10:21:23 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Dec 2011 10:21:23 -0000
X-IronPort-AV: E=Sophos;i="4.71,304,1320624000"; 
   d="scan'208";a="9309911"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Dec 2011 10:21:22 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Tue, 6 Dec 2011
	10:21:22 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>
Date: Tue, 6 Dec 2011 10:21:22 +0000
In-Reply-To: <1323166100-7059-1-git-send-email-wei.liu2@citrix.com>
References: <1323166100-7059-1-git-send-email-wei.liu2@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323166882.23681.46.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] netback: remove redundant assignment
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2011-12-06 at 10:08 +0000, Wei Liu wrote:
> New value for netbk->mmap_pages[pending_idx] is assigned in
> xen_netbk_alloc_page(), no need for a second assignment which
> exposes internal to the outside world.
> 
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>

> ---
>  drivers/net/xen-netback/netback.c |    4 ----
>  1 files changed, 0 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
> index 15e332d..3ecb5aa 100644
> --- a/drivers/net/xen-netback/netback.c
> +++ b/drivers/net/xen-netback/netback.c
> @@ -940,8 +940,6 @@ static struct gnttab_copy *xen_netbk_get_requests(struct xen_netbk *netbk,
>  		if (!page)
>  			return NULL;
>  
> -		netbk->mmap_pages[pending_idx] = page;
> -
>  		gop->source.u.ref = txp->gref;
>  		gop->source.domid = vif->domid;
>  		gop->source.offset = txp->offset;
> @@ -1336,8 +1334,6 @@ static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk)
>  			continue;
>  		}
>  
> -		netbk->mmap_pages[pending_idx] = page;
> -
>  		gop->source.u.ref = txreq.gref;
>  		gop->source.domid = vif->domid;
>  		gop->source.offset = txreq.offset;



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 10:22:50 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 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.xensource.com>)
	id 1RXsA5-00065x-US; Tue, 06 Dec 2011 10:22:09 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RXsA4-00065s-J2
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 10:22:08 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1323166882!6356199!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjM3Ng==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4260 invoked from network); 6 Dec 2011 10:21:23 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Dec 2011 10:21:23 -0000
X-IronPort-AV: E=Sophos;i="4.71,304,1320624000"; 
   d="scan'208";a="9309911"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Dec 2011 10:21:22 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Tue, 6 Dec 2011
	10:21:22 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>
Date: Tue, 6 Dec 2011 10:21:22 +0000
In-Reply-To: <1323166100-7059-1-git-send-email-wei.liu2@citrix.com>
References: <1323166100-7059-1-git-send-email-wei.liu2@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323166882.23681.46.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] netback: remove redundant assignment
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2011-12-06 at 10:08 +0000, Wei Liu wrote:
> New value for netbk->mmap_pages[pending_idx] is assigned in
> xen_netbk_alloc_page(), no need for a second assignment which
> exposes internal to the outside world.
> 
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>

> ---
>  drivers/net/xen-netback/netback.c |    4 ----
>  1 files changed, 0 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
> index 15e332d..3ecb5aa 100644
> --- a/drivers/net/xen-netback/netback.c
> +++ b/drivers/net/xen-netback/netback.c
> @@ -940,8 +940,6 @@ static struct gnttab_copy *xen_netbk_get_requests(struct xen_netbk *netbk,
>  		if (!page)
>  			return NULL;
>  
> -		netbk->mmap_pages[pending_idx] = page;
> -
>  		gop->source.u.ref = txp->gref;
>  		gop->source.domid = vif->domid;
>  		gop->source.offset = txp->offset;
> @@ -1336,8 +1334,6 @@ static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk)
>  			continue;
>  		}
>  
> -		netbk->mmap_pages[pending_idx] = page;
> -
>  		gop->source.u.ref = txreq.gref;
>  		gop->source.domid = vif->domid;
>  		gop->source.offset = txreq.offset;



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 10:25:04 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 10:25:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXsC2-0006AR-Fa; Tue, 06 Dec 2011 10:24:10 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RXsBz-0006AF-Q4
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 10:24:08 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1323166975!51281662!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjM3Ng==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30879 invoked from network); 6 Dec 2011 10:22:55 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Dec 2011 10:22:55 -0000
X-IronPort-AV: E=Sophos;i="4.71,304,1320624000"; 
   d="scan'208";a="9309971"
Received: from lonpmailmx02.citrite.net ([10.30.203.163])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Dec 2011 10:23:26 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.161]) by
	LONPMAILMX02.citrite.net ([10.30.203.163]) with mapi; Tue, 6 Dec 2011
	10:23:26 +0000
From: Paul Durrant <Paul.Durrant@citrix.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Tue, 6 Dec 2011 10:23:33 +0000
Thread-Topic: [PATCH] VM generation ID save/restore and migrate
Thread-Index: AcyzNbCfhv/StC5ORAaVnBUCmBiYgAAyzrwQ
Message-ID: <291EDFCB1E9E224A99088639C4762022B5988E5355@LONPMAILBOX01.citrite.net>
References: <152a79fbe918d8a6c63a.1323079622@cosworth.uk.xensource.com>
In-Reply-To: <152a79fbe918d8a6c63a.1323079622@cosworth.uk.xensource.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: Paul Durrant <Paul.Durrant@citrix.com>
Subject: Re: [Xen-devel] [PATCH] VM generation ID save/restore and migrate
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ping?

> -----Original Message-----
> From: Paul Durrant [mailto:paul.durrant@citrix.com]
> Sent: 05 December 2011 10:07
> To: xen-devel@lists.xensource.com
> Cc: Paul Durrant
> Subject: [PATCH] VM generation ID save/restore and migrate
>
> # HG changeset patch
> # User Paul Durrant <paul.durrant@citrix.com> # Date 1323079290 0 #
> Node ID 152a79fbe918d8a6c63ab15a03aebb9d7d305843
> # Parent  a4d7c27ec1f190ecbb9a909609f6ef0eca250c00
> VM generation ID save/restore and migrate.
>
> Add code to track the address of the VM generation id buffer across
> a save/restore or migrate and increment it as necessary.
> The address of the buffer is written into xenstore by hvmloader at
> boot time. It must be read from xenstore by the caller of
> xc_domain_save() and then written back again by the caller of
> xc_domain_restore().
>
> Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
>
> diff -r a4d7c27ec1f1 -r 152a79fbe918
> tools/libxc/ia64/xc_ia64_linux_restore.c
> --- a/tools/libxc/ia64/xc_ia64_linux_restore.c        Fri Dec 02 13:51:17
> 2011 -0800
> +++ b/tools/libxc/ia64/xc_ia64_linux_restore.c        Mon Dec 05 10:01:30
> 2011 +0000
> @@ -548,7 +548,8 @@ int
>  xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
>                    unsigned int store_evtchn, unsigned long
> *store_mfn,
>                    unsigned int console_evtchn, unsigned long
> *console_mfn,
> -                  unsigned int hvm, unsigned int pae, int
> superpages)
> +                  unsigned int hvm, unsigned int pae, int
> superpages,
> +                  int increment_gid, unsigned long *vm_gid_addr)
>  {
>      DECLARE_DOMCTL;
>      int rc = 1;
> diff -r a4d7c27ec1f1 -r 152a79fbe918
> tools/libxc/ia64/xc_ia64_linux_save.c
> --- a/tools/libxc/ia64/xc_ia64_linux_save.c   Fri Dec 02 13:51:17
> 2011 -0800
> +++ b/tools/libxc/ia64/xc_ia64_linux_save.c   Mon Dec 05 10:01:30
> 2011 +0000
> @@ -382,7 +382,8 @@ out:
>  int
>  xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t
> max_iters,
>                 uint32_t max_factor, uint32_t flags,
> -               struct save_callbacks* callbacks, int hvm)
> +               struct save_callbacks* callbacks, int hvm,
> +               unsigned long vm_gid_addr)
>  {
>      DECLARE_DOMCTL;
>      xc_dominfo_t info;
> diff -r a4d7c27ec1f1 -r 152a79fbe918 tools/libxc/xc_domain_restore.c
> --- a/tools/libxc/xc_domain_restore.c Fri Dec 02 13:51:17 2011 -
> 0800
> +++ b/tools/libxc/xc_domain_restore.c Mon Dec 05 10:01:30 2011
> +0000
> @@ -681,6 +681,7 @@ typedef struct {
>      uint64_t console_pfn;
>      uint64_t acpi_ioport_location;
>      uint64_t viridian;
> +    uint64_t vm_gid_addr;
>  } pagebuf_t;
>
>  static int pagebuf_init(pagebuf_t* buf) @@ -860,6 +861,17 @@ static
> int pagebuf_get_one(xc_interface
>          }
>          return compbuf_size;
>
> +    case XC_SAVE_ID_HVM_GENERATION_ID_ADDR:
> +        /* Skip padding 4 bytes then read the generation id buffer
> location. */
> +        if ( RDEXACT(fd, &buf->vm_gid_addr, sizeof(uint32_t)) ||
> +             RDEXACT(fd, &buf->vm_gid_addr, sizeof(uint64_t)) )
> +        {
> +            PERROR("error read the generation id buffer location");
> +            return -1;
> +        }
> +        DPRINTF("read generation id buffer address");
> +        return pagebuf_get_one(xch, ctx, buf, fd, dom);
> +
>      default:
>          if ( (count > MAX_BATCH_SIZE) || (count < 0) ) {
>              ERROR("Max batch size exceeded (%d). Giving up.",
> count); @@ -1248,7 +1260,8 @@ static int apply_batch(xc_interface
> *xch  int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t
> dom,
>                        unsigned int store_evtchn, unsigned long
> *store_mfn,
>                        unsigned int console_evtchn, unsigned long
> *console_mfn,
> -                      unsigned int hvm, unsigned int pae, int
> superpages)
> +                      unsigned int hvm, unsigned int pae, int
> superpages,
> +                      int no_increment_gid, unsigned long
> *vm_gid_addr)
>  {
>      DECLARE_DOMCTL;
>      int rc = 1, frc, i, j, n, m, pae_extended_cr3 = 0,
> ext_vcpucontext = 0; @@ -1449,6 +1462,39 @@ int
> xc_domain_restore(xc_interface *xch,
>                  xc_set_hvm_param(xch, dom, HVM_PARAM_VM86_TSS,
> pagebuf.vm86_tss);
>              if ( pagebuf.console_pfn )
>                  console_pfn = pagebuf.console_pfn;
> +            if ( pagebuf.vm_gid_addr ) {
> +                if ( !no_increment_gid ) {
> +                    unsigned int offset;
> +                    unsigned char *buf;
> +                    unsigned long long gid;
> +
> +                    /*
> +                     * Map the VM generation id buffer and inject
> the new value.
> +                     */
> +
> +                    pfn = pagebuf.vm_gid_addr >> PAGE_SHIFT;
> +                    offset = pagebuf.vm_gid_addr & (PAGE_SIZE - 1);
> +
> +                    if ( (pfn >= dinfo->p2m_size) ||
> +                         (pfn_type[pfn] != XEN_DOMCTL_PFINFO_NOTAB)
> )
> +                    {
> +                        ERROR("generation id buffer frame is bad");
> +                        goto out;
> +                    }
> +
> +                    mfn = ctx->p2m[pfn];
> +                    buf = xc_map_foreign_range(xch, dom, PAGE_SIZE,
> +                                               PROT_READ |
> PROT_WRITE,
> + mfn);
> +
> +                    gid = *(unsigned long long *)(buf + offset);
> +                    *(unsigned long long *)(buf + offset) = gid +
> 1;
> +
> +                    munmap(buf, PAGE_SIZE);
> +                }
> +
> +                *vm_gid_addr = pagebuf.vm_gid_addr;
> +            }
> +
>              break;  /* our work here is done */
>          }
>
> diff -r a4d7c27ec1f1 -r 152a79fbe918 tools/libxc/xc_domain_save.c
> --- a/tools/libxc/xc_domain_save.c    Fri Dec 02 13:51:17 2011 -0800
> +++ b/tools/libxc/xc_domain_save.c    Mon Dec 05 10:01:30 2011 +0000
> @@ -804,7 +804,8 @@ static int save_tsc_info(xc_interface *x
>
>  int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom,
> uint32_t max_iters,
>                     uint32_t max_factor, uint32_t flags,
> -                   struct save_callbacks* callbacks, int hvm)
> +                   struct save_callbacks* callbacks, int hvm,
> +                   unsigned long vm_gid_addr)
>  {
>      xc_dominfo_t info;
>      DECLARE_DOMCTL;
> @@ -1616,6 +1617,16 @@ int xc_domain_save(xc_interface *xch, in
>              uint64_t data;
>          } chunk = { 0, };
>
> +        chunk.id = XC_SAVE_ID_HVM_GENERATION_ID_ADDR;
> +        chunk.data = vm_gid_addr;
> +
> +        if ( (chunk.data != 0) &&
> +             wrexact(io_fd, &chunk, sizeof(chunk)) )
> +        {
> +            PERROR("Error when writing the generation id buffer
> location for guest");
> +            goto out;
> +        }
> +
>          chunk.id = XC_SAVE_ID_HVM_IDENT_PT;
>          chunk.data = 0;
>          xc_get_hvm_param(xch, dom, HVM_PARAM_IDENT_PT, diff -r
> a4d7c27ec1f1 -r 152a79fbe918 tools/libxc/xenguest.h
> --- a/tools/libxc/xenguest.h  Fri Dec 02 13:51:17 2011 -0800
> +++ b/tools/libxc/xenguest.h  Mon Dec 05 10:01:30 2011 +0000
> @@ -58,7 +58,8 @@ struct save_callbacks {
>   */
>  int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom,
> uint32_t max_iters,
>                     uint32_t max_factor, uint32_t flags /*
> XCFLAGS_xxx */,
> -                   struct save_callbacks* callbacks, int hvm);
> +                   struct save_callbacks* callbacks, int hvm,
> +                   unsigned long vm_gid_addr);
>
>
>  /**
> @@ -72,12 +73,15 @@ int xc_domain_save(xc_interface *xch, in
>   * @parm hvm non-zero if this is a HVM restore
>   * @parm pae non-zero if this HVM domain has PAE support enabled
>   * @parm superpages non-zero to allocate guest memory with
> superpages
> + * @parm gid the new generation id of the VM
> + * @parm vm_gid_addr returned with the address of the generation id
> + buffer
>   * @return 0 on success, -1 on failure
>   */
>  int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
>                        unsigned int store_evtchn, unsigned long
> *store_mfn,
>                        unsigned int console_evtchn, unsigned long
> *console_mfn,
> -                      unsigned int hvm, unsigned int pae, int
> superpages);
> +                      unsigned int hvm, unsigned int pae, int
> superpages,
> +                      int increment_gid, unsigned long
> *vm_gid_addr);
>  /**
>   * xc_domain_restore writes a file to disk that contains the device
>   * model saved state.
> diff -r a4d7c27ec1f1 -r 152a79fbe918 tools/libxc/xg_save_restore.h
> --- a/tools/libxc/xg_save_restore.h   Fri Dec 02 13:51:17 2011 -
> 0800
> +++ b/tools/libxc/xg_save_restore.h   Mon Dec 05 10:01:30 2011
> +0000
> @@ -253,6 +253,7 @@
>  #define XC_SAVE_ID_HVM_VIRIDIAN       -11
>  #define XC_SAVE_ID_COMPRESSED_DATA    -12 /* Marker to indicate
> arrival of compressed data */
>  #define XC_SAVE_ID_ENABLE_COMPRESSION -13 /* Marker to enable
> compression logic at receiver side */
> +#define XC_SAVE_ID_HVM_GENERATION_ID_ADDR -14
>
>  /*
>  ** We process save/restore/migrate in batches of pages; the below
> diff -r a4d7c27ec1f1 -r 152a79fbe918 tools/libxl/libxl_create.c
> --- a/tools/libxl/libxl_create.c      Fri Dec 02 13:51:17 2011 -0800
> +++ b/tools/libxl/libxl_create.c      Mon Dec 05 10:01:30 2011 +0000
> @@ -101,6 +101,7 @@ int libxl_init_build_info(libxl_ctx *ctx
>          b_info->u.hvm.vpt_align = 1;
>          b_info->u.hvm.timer_mode = 1;
>          b_info->u.hvm.nested_hvm = 0;
> +        b_info->u.hvm.no_increment_gid = 0;
>          break;
>      case LIBXL_DOMAIN_TYPE_PV:
>          b_info->u.pv.slack_memkb = 8 * 1024; diff -r a4d7c27ec1f1 -
> r 152a79fbe918 tools/libxl/libxl_dom.c
> --- a/tools/libxl/libxl_dom.c Fri Dec 02 13:51:17 2011 -0800
> +++ b/tools/libxl/libxl_dom.c Mon Dec 05 10:01:30 2011 +0000
> @@ -125,7 +125,7 @@ int libxl__build_post(libxl__gc *gc, uin
>      if (info->cpuid != NULL)
>          libxl_cpuid_set(ctx, domid, info->cpuid);
>
> -    ents = libxl__calloc(gc, 12 + (info->max_vcpus * 2) + 2,
> sizeof(char *));
> +    ents = libxl__calloc(gc, 14 + (info->max_vcpus * 2) + 2,
> + sizeof(char *));
>      ents[0] = "memory/static-max";
>      ents[1] = libxl__sprintf(gc, "%d", info->max_memkb);
>      ents[2] = "memory/target";
> @@ -138,9 +138,11 @@ int libxl__build_post(libxl__gc *gc, uin
>      ents[9] = libxl__sprintf(gc, "%"PRIu32, state->store_port);
>      ents[10] = "store/ring-ref";
>      ents[11] = libxl__sprintf(gc, "%lu", state->store_mfn);
> +    ents[12] = "data/generation-id";
> +    ents[13] = libxl__sprintf(gc, "0x%lx", state->vm_gid_addr);
>      for (i = 0; i < info->max_vcpus; i++) {
> -        ents[12+(i*2)]   = libxl__sprintf(gc,
> "cpu/%d/availability", i);
> -        ents[12+(i*2)+1] = (i && info->cur_vcpus && !(info-
> >cur_vcpus & (1 << i)))
> +        ents[14+(i*2)]   = libxl__sprintf(gc,
> "cpu/%d/availability", i);
> +        ents[14+(i*2)+1] = (i && info->cur_vcpus && !(info-
> >cur_vcpus &
> + (1 << i)))
>                              ? "offline" : "online";
>      }
>
> @@ -357,16 +359,19 @@ int libxl__domain_restore_common(libxl__
>      /* read signature */
>      int rc;
>      int hvm, pae, superpages;
> +    int no_increment_gid;
>      switch (info->type) {
>      case LIBXL_DOMAIN_TYPE_HVM:
>          hvm = 1;
>          superpages = 1;
>          pae = info->u.hvm.pae;
> +        no_increment_gid = info->u.hvm.no_increment_gid;
>          break;
>      case LIBXL_DOMAIN_TYPE_PV:
>          hvm = 0;
>          superpages = 0;
>          pae = 1;
> +        no_increment_gid = 0;
>          break;
>      default:
>          return ERROR_INVAL;
> @@ -374,7 +379,7 @@ int libxl__domain_restore_common(libxl__
>      rc = xc_domain_restore(ctx->xch, fd, domid,
>                             state->store_port, &state->store_mfn,
>                             state->console_port, &state-
> >console_mfn,
> -                           hvm, pae, superpages);
> +                           hvm, pae, superpages, no_increment_gid,
> + &state->vm_gid_addr);
>      if ( rc ) {
>          LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "restoring
> domain");
>          return ERROR_FAIL;
> @@ -540,12 +545,22 @@ int libxl__domain_suspend_common(libxl__
>      struct save_callbacks callbacks;
>      struct suspendinfo si;
>      int hvm, rc = ERROR_FAIL;
> +    unsigned long vm_gid_addr;
>
>      switch (type) {
> -    case LIBXL_DOMAIN_TYPE_HVM:
> +    case LIBXL_DOMAIN_TYPE_HVM: {
> +        char *path;
> +        char *addr;
> +
> +        path = libxl__sprintf(gc, "%s/data/generation-id",
> libxl__xs_get_dompath(gc, domid));
> +        addr = libxl__xs_read(gc, XBT_NULL, path);
> +
> +        vm_gid_addr = (addr) ? strtoul(addr, NULL, 0) : 0;
>          hvm = 1;
>          break;
> +    }
>      case LIBXL_DOMAIN_TYPE_PV:
> +        vm_gid_addr = 0;
>          hvm = 0;
>          break;
>      default:
> @@ -583,7 +598,8 @@ int libxl__domain_suspend_common(libxl__
>      callbacks.switch_qemu_logdirty =
> libxl__domain_suspend_common_switch_qemu_logdirty;
>      callbacks.data = &si;
>
> -    rc = xc_domain_save(ctx->xch, fd, domid, 0, 0, flags,
> &callbacks, hvm);
> +    rc = xc_domain_save(ctx->xch, fd, domid, 0, 0, flags,
> &callbacks,
> +                        hvm, vm_gid_addr);
>      if ( rc ) {
>          LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "saving domain:
> %s",
>                           si.guest_responded ?
> diff -r a4d7c27ec1f1 -r 152a79fbe918 tools/libxl/libxl_internal.h
> --- a/tools/libxl/libxl_internal.h    Fri Dec 02 13:51:17 2011 -0800
> +++ b/tools/libxl/libxl_internal.h    Mon Dec 05 10:01:30 2011 +0000
> @@ -199,6 +199,7 @@ typedef struct {
>
>      uint32_t console_port;
>      unsigned long console_mfn;
> +    unsigned long vm_gid_addr;
>  } libxl__domain_build_state;
>
>  _hidden int libxl__build_pre(libxl__gc *gc, uint32_t domid, diff -r
> a4d7c27ec1f1 -r 152a79fbe918 tools/libxl/libxl_types.idl
> --- a/tools/libxl/libxl_types.idl     Fri Dec 02 13:51:17 2011 -0800
> +++ b/tools/libxl/libxl_types.idl     Mon Dec 05 10:01:30 2011 +0000
> @@ -184,6 +184,7 @@ libxl_domain_build_info = Struct("domain
>                                         ("vpt_align", bool),
>                                         ("timer_mode", integer),
>                                         ("nested_hvm", bool),
> +                                       ("no_increment_gid", bool),
>                                         ])),
>                   ("pv", Struct(None, [("kernel",
> libxl_file_reference),
>                                        ("slack_memkb", uint32), diff
> -r a4d7c27ec1f1 -r 152a79fbe918 tools/libxl/xl_cmdimpl.c
> --- a/tools/libxl/xl_cmdimpl.c        Fri Dec 02 13:51:17 2011 -0800
> +++ b/tools/libxl/xl_cmdimpl.c        Mon Dec 05 10:01:30 2011 +0000
> @@ -360,6 +360,7 @@ static void printf_info(int domid,
>          printf("\t\t\t(vpt_align %d)\n", b_info->u.hvm.vpt_align);
>          printf("\t\t\t(timer_mode %d)\n", b_info-
> >u.hvm.timer_mode);
>          printf("\t\t\t(nestedhvm %d)\n", b_info->u.hvm.nested_hvm);
> +        printf("\t\t\t(no_increment_gid %d)\n",
> + b_info->u.hvm.no_increment_gid);
>
>          printf("\t\t\t(device_model %s)\n", dm_info->device_model ?
> : "default");
>          printf("\t\t\t(videoram %d)\n", dm_info->videoram); @@ -
> 1362,6 +1363,7 @@ struct domain_create {
>      const char *restore_file;
>      int migrate_fd; /* -1 means none */
>      char **migration_domname_r; /* from malloc */
> +    int no_increment_gid;
>  };
>
>  static int freemem(libxl_domain_build_info *b_info,
> libxl_device_model_info *dm_info) @@ -1575,6 +1577,8 @@ static int
> create_domain(struct domain_c
>          }
>      }
>
> +    d_config.b_info.u.hvm.no_increment_gid =
> + dom_info->no_increment_gid;
> +
>      if (debug || dom_info->dryrun)
>          printf_info(-1, &d_config, &d_config.dm_info);
>
> @@ -2800,6 +2804,7 @@ static void migrate_receive(int debug, i
>      dom_info.restore_file = "incoming migration stream";
>      dom_info.migrate_fd = 0; /* stdin */
>      dom_info.migration_domname_r = &migration_domname;
> +    dom_info.no_increment_gid = 1;
>
>      rc = create_domain(&dom_info);
>      if (rc < 0) {
> diff -r a4d7c27ec1f1 -r 152a79fbe918
> tools/python/xen/lowlevel/checkpoint/libcheckpoint.c
> --- a/tools/python/xen/lowlevel/checkpoint/libcheckpoint.c    Fri
> Dec 02 13:51:17 2011 -0800
> +++ b/tools/python/xen/lowlevel/checkpoint/libcheckpoint.c    Mon
> Dec 05 10:01:30 2011 +0000
> @@ -175,6 +175,7 @@ int checkpoint_start(checkpoint_state* s  {
>      int hvm, rc;
>      int flags = XCFLAGS_LIVE;
> +    unsigned long vm_gid_addr;
>
>      if (!s->domid) {
>         s->errstr = "checkpoint state not opened"; @@ -185,16
> +186,27 @@ int checkpoint_start(checkpoint_state* s
>
>      hvm = s->domtype > dt_pv;
>      if (hvm) {
> +       char path[128];
> +       char *addr;
> +
> +       sprintf(path, "/local/domain/%u/data/generation-id", s-
> >domid);
> +       addr = xs_read(s->xsh, XBT_NULL, path, NULL);
> +
> +       vm_gid_addr = (addr) ? strtoul(addr, NULL, 0) : 0;
> +       free(addr);
> +
>         flags |= XCFLAGS_HVM;
>         if (switch_qemu_logdirty(s, 1))
>             return -1;
> +    } else {
> +       vm_gid_addr = 0;
>      }
>      if (remus_flags & CHECKPOINT_FLAGS_COMPRESSION)
>        flags |= XCFLAGS_CHECKPOINT_COMPRESS;
>
>      callbacks->switch_qemu_logdirty = noop_switch_logdirty;
>
> -    rc = xc_domain_save(s->xch, fd, s->domid, 0, 0, flags,
> callbacks, hvm);
> +    rc = xc_domain_save(s->xch, fd, s->domid, 0, 0, flags,
> callbacks,
> + hvm, vm_gid_addr);
>
>      if (hvm)
>         switch_qemu_logdirty(s, 0);
> diff -r a4d7c27ec1f1 -r 152a79fbe918 tools/xcutils/xc_restore.c
> --- a/tools/xcutils/xc_restore.c      Fri Dec 02 13:51:17 2011 -0800
> +++ b/tools/xcutils/xc_restore.c      Mon Dec 05 10:01:30 2011 +0000
> @@ -23,7 +23,8 @@ main(int argc, char **argv)
>      xc_interface *xch;
>      int io_fd, ret;
>      int superpages;
> -    unsigned long store_mfn, console_mfn;
> +    unsigned long store_mfn, console_mfn, vm_gid_addr;
> +    int no_increment_gid;
>
>      if ( (argc != 8) && (argc != 9) )
>          errx(1, "usage: %s iofd domid store_evtchn "
> @@ -40,19 +41,25 @@ main(int argc, char **argv)
>      hvm  = atoi(argv[5]);
>      pae  = atoi(argv[6]);
>      apic = atoi(argv[7]);
> -    if ( argc == 9 )
> +    if ( argc >= 9 )
>           superpages = atoi(argv[8]);
>      else
>           superpages = !!hvm;
> +    if ( argc >= 10 )
> +         no_increment_gid = !atoi(argv[9]);
> +    else
> +         no_increment_gid = 0;
>
>      ret = xc_domain_restore(xch, io_fd, domid, store_evtchn,
> &store_mfn,
> -                            console_evtchn, &console_mfn, hvm, pae,
> superpages);
> +                            console_evtchn, &console_mfn, hvm, pae,
> superpages,
> +                            no_increment_gid, &vm_gid_addr);
>
>      if ( ret == 0 )
>      {
>       printf("store-mfn %li\n", store_mfn);
>          if ( !hvm )
>              printf("console-mfn %li\n", console_mfn);
> +     printf("vm-gid-addr %lx\n", vm_gid_addr);
>       fflush(stdout);
>      }
>
> diff -r a4d7c27ec1f1 -r 152a79fbe918 tools/xcutils/xc_save.c
> --- a/tools/xcutils/xc_save.c Fri Dec 02 13:51:17 2011 -0800
> +++ b/tools/xcutils/xc_save.c Mon Dec 05 10:01:30 2011 +0000
> @@ -169,6 +169,10 @@ main(int argc, char **argv)
>      unsigned int maxit, max_f;
>      int io_fd, ret, port;
>      struct save_callbacks callbacks;
> +    char path[128];
> +    struct xs_handle *xs;
> +    char *addr;
> +    unsigned long vm_gid_addr;
>
>      if (argc != 6)
>          errx(1, "usage: %s iofd domid maxit maxf flags", argv[0]);
> @@ -207,8 +211,21 @@ main(int argc, char **argv)
>      memset(&callbacks, 0, sizeof(callbacks));
>      callbacks.suspend = suspend;
>      callbacks.switch_qemu_logdirty = switch_qemu_logdirty;
> +
> +    sprintf(path, "/local/domain/%d/data/generation-id", si.domid);
> +
> +    if ((xs = xs_daemon_open()) == NULL)
> +        errx(1, "Couldn't contact xenstore");
> +
> +    addr = xs_read(xs, XBT_NULL, path, NULL);
> +
> +    xs_daemon_close(xs);
> +
> +    vm_gid_addr = (addr) ? strtoul(addr, NULL, 0) : 0;
> +    free(addr);
> +
>      ret = xc_domain_save(si.xch, io_fd, si.domid, maxit, max_f,
> si.flags,
> -                         &callbacks, !!(si.flags & XCFLAGS_HVM));
> +                         &callbacks, !!(si.flags & XCFLAGS_HVM),
> + vm_gid_addr);
>
>      if (si.suspend_evtchn > 0)
>        xc_suspend_evtchn_release(si.xch, si.xce, si.domid,
> si.suspend_evtchn);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 10:25:04 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 10:25:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXsC2-0006AR-Fa; Tue, 06 Dec 2011 10:24:10 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RXsBz-0006AF-Q4
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 10:24:08 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1323166975!51281662!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjM3Ng==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30879 invoked from network); 6 Dec 2011 10:22:55 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Dec 2011 10:22:55 -0000
X-IronPort-AV: E=Sophos;i="4.71,304,1320624000"; 
   d="scan'208";a="9309971"
Received: from lonpmailmx02.citrite.net ([10.30.203.163])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Dec 2011 10:23:26 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.161]) by
	LONPMAILMX02.citrite.net ([10.30.203.163]) with mapi; Tue, 6 Dec 2011
	10:23:26 +0000
From: Paul Durrant <Paul.Durrant@citrix.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Tue, 6 Dec 2011 10:23:33 +0000
Thread-Topic: [PATCH] VM generation ID save/restore and migrate
Thread-Index: AcyzNbCfhv/StC5ORAaVnBUCmBiYgAAyzrwQ
Message-ID: <291EDFCB1E9E224A99088639C4762022B5988E5355@LONPMAILBOX01.citrite.net>
References: <152a79fbe918d8a6c63a.1323079622@cosworth.uk.xensource.com>
In-Reply-To: <152a79fbe918d8a6c63a.1323079622@cosworth.uk.xensource.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: Paul Durrant <Paul.Durrant@citrix.com>
Subject: Re: [Xen-devel] [PATCH] VM generation ID save/restore and migrate
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ping?

> -----Original Message-----
> From: Paul Durrant [mailto:paul.durrant@citrix.com]
> Sent: 05 December 2011 10:07
> To: xen-devel@lists.xensource.com
> Cc: Paul Durrant
> Subject: [PATCH] VM generation ID save/restore and migrate
>
> # HG changeset patch
> # User Paul Durrant <paul.durrant@citrix.com> # Date 1323079290 0 #
> Node ID 152a79fbe918d8a6c63ab15a03aebb9d7d305843
> # Parent  a4d7c27ec1f190ecbb9a909609f6ef0eca250c00
> VM generation ID save/restore and migrate.
>
> Add code to track the address of the VM generation id buffer across
> a save/restore or migrate and increment it as necessary.
> The address of the buffer is written into xenstore by hvmloader at
> boot time. It must be read from xenstore by the caller of
> xc_domain_save() and then written back again by the caller of
> xc_domain_restore().
>
> Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
>
> diff -r a4d7c27ec1f1 -r 152a79fbe918
> tools/libxc/ia64/xc_ia64_linux_restore.c
> --- a/tools/libxc/ia64/xc_ia64_linux_restore.c        Fri Dec 02 13:51:17
> 2011 -0800
> +++ b/tools/libxc/ia64/xc_ia64_linux_restore.c        Mon Dec 05 10:01:30
> 2011 +0000
> @@ -548,7 +548,8 @@ int
>  xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
>                    unsigned int store_evtchn, unsigned long
> *store_mfn,
>                    unsigned int console_evtchn, unsigned long
> *console_mfn,
> -                  unsigned int hvm, unsigned int pae, int
> superpages)
> +                  unsigned int hvm, unsigned int pae, int
> superpages,
> +                  int increment_gid, unsigned long *vm_gid_addr)
>  {
>      DECLARE_DOMCTL;
>      int rc = 1;
> diff -r a4d7c27ec1f1 -r 152a79fbe918
> tools/libxc/ia64/xc_ia64_linux_save.c
> --- a/tools/libxc/ia64/xc_ia64_linux_save.c   Fri Dec 02 13:51:17
> 2011 -0800
> +++ b/tools/libxc/ia64/xc_ia64_linux_save.c   Mon Dec 05 10:01:30
> 2011 +0000
> @@ -382,7 +382,8 @@ out:
>  int
>  xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t
> max_iters,
>                 uint32_t max_factor, uint32_t flags,
> -               struct save_callbacks* callbacks, int hvm)
> +               struct save_callbacks* callbacks, int hvm,
> +               unsigned long vm_gid_addr)
>  {
>      DECLARE_DOMCTL;
>      xc_dominfo_t info;
> diff -r a4d7c27ec1f1 -r 152a79fbe918 tools/libxc/xc_domain_restore.c
> --- a/tools/libxc/xc_domain_restore.c Fri Dec 02 13:51:17 2011 -
> 0800
> +++ b/tools/libxc/xc_domain_restore.c Mon Dec 05 10:01:30 2011
> +0000
> @@ -681,6 +681,7 @@ typedef struct {
>      uint64_t console_pfn;
>      uint64_t acpi_ioport_location;
>      uint64_t viridian;
> +    uint64_t vm_gid_addr;
>  } pagebuf_t;
>
>  static int pagebuf_init(pagebuf_t* buf) @@ -860,6 +861,17 @@ static
> int pagebuf_get_one(xc_interface
>          }
>          return compbuf_size;
>
> +    case XC_SAVE_ID_HVM_GENERATION_ID_ADDR:
> +        /* Skip padding 4 bytes then read the generation id buffer
> location. */
> +        if ( RDEXACT(fd, &buf->vm_gid_addr, sizeof(uint32_t)) ||
> +             RDEXACT(fd, &buf->vm_gid_addr, sizeof(uint64_t)) )
> +        {
> +            PERROR("error read the generation id buffer location");
> +            return -1;
> +        }
> +        DPRINTF("read generation id buffer address");
> +        return pagebuf_get_one(xch, ctx, buf, fd, dom);
> +
>      default:
>          if ( (count > MAX_BATCH_SIZE) || (count < 0) ) {
>              ERROR("Max batch size exceeded (%d). Giving up.",
> count); @@ -1248,7 +1260,8 @@ static int apply_batch(xc_interface
> *xch  int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t
> dom,
>                        unsigned int store_evtchn, unsigned long
> *store_mfn,
>                        unsigned int console_evtchn, unsigned long
> *console_mfn,
> -                      unsigned int hvm, unsigned int pae, int
> superpages)
> +                      unsigned int hvm, unsigned int pae, int
> superpages,
> +                      int no_increment_gid, unsigned long
> *vm_gid_addr)
>  {
>      DECLARE_DOMCTL;
>      int rc = 1, frc, i, j, n, m, pae_extended_cr3 = 0,
> ext_vcpucontext = 0; @@ -1449,6 +1462,39 @@ int
> xc_domain_restore(xc_interface *xch,
>                  xc_set_hvm_param(xch, dom, HVM_PARAM_VM86_TSS,
> pagebuf.vm86_tss);
>              if ( pagebuf.console_pfn )
>                  console_pfn = pagebuf.console_pfn;
> +            if ( pagebuf.vm_gid_addr ) {
> +                if ( !no_increment_gid ) {
> +                    unsigned int offset;
> +                    unsigned char *buf;
> +                    unsigned long long gid;
> +
> +                    /*
> +                     * Map the VM generation id buffer and inject
> the new value.
> +                     */
> +
> +                    pfn = pagebuf.vm_gid_addr >> PAGE_SHIFT;
> +                    offset = pagebuf.vm_gid_addr & (PAGE_SIZE - 1);
> +
> +                    if ( (pfn >= dinfo->p2m_size) ||
> +                         (pfn_type[pfn] != XEN_DOMCTL_PFINFO_NOTAB)
> )
> +                    {
> +                        ERROR("generation id buffer frame is bad");
> +                        goto out;
> +                    }
> +
> +                    mfn = ctx->p2m[pfn];
> +                    buf = xc_map_foreign_range(xch, dom, PAGE_SIZE,
> +                                               PROT_READ |
> PROT_WRITE,
> + mfn);
> +
> +                    gid = *(unsigned long long *)(buf + offset);
> +                    *(unsigned long long *)(buf + offset) = gid +
> 1;
> +
> +                    munmap(buf, PAGE_SIZE);
> +                }
> +
> +                *vm_gid_addr = pagebuf.vm_gid_addr;
> +            }
> +
>              break;  /* our work here is done */
>          }
>
> diff -r a4d7c27ec1f1 -r 152a79fbe918 tools/libxc/xc_domain_save.c
> --- a/tools/libxc/xc_domain_save.c    Fri Dec 02 13:51:17 2011 -0800
> +++ b/tools/libxc/xc_domain_save.c    Mon Dec 05 10:01:30 2011 +0000
> @@ -804,7 +804,8 @@ static int save_tsc_info(xc_interface *x
>
>  int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom,
> uint32_t max_iters,
>                     uint32_t max_factor, uint32_t flags,
> -                   struct save_callbacks* callbacks, int hvm)
> +                   struct save_callbacks* callbacks, int hvm,
> +                   unsigned long vm_gid_addr)
>  {
>      xc_dominfo_t info;
>      DECLARE_DOMCTL;
> @@ -1616,6 +1617,16 @@ int xc_domain_save(xc_interface *xch, in
>              uint64_t data;
>          } chunk = { 0, };
>
> +        chunk.id = XC_SAVE_ID_HVM_GENERATION_ID_ADDR;
> +        chunk.data = vm_gid_addr;
> +
> +        if ( (chunk.data != 0) &&
> +             wrexact(io_fd, &chunk, sizeof(chunk)) )
> +        {
> +            PERROR("Error when writing the generation id buffer
> location for guest");
> +            goto out;
> +        }
> +
>          chunk.id = XC_SAVE_ID_HVM_IDENT_PT;
>          chunk.data = 0;
>          xc_get_hvm_param(xch, dom, HVM_PARAM_IDENT_PT, diff -r
> a4d7c27ec1f1 -r 152a79fbe918 tools/libxc/xenguest.h
> --- a/tools/libxc/xenguest.h  Fri Dec 02 13:51:17 2011 -0800
> +++ b/tools/libxc/xenguest.h  Mon Dec 05 10:01:30 2011 +0000
> @@ -58,7 +58,8 @@ struct save_callbacks {
>   */
>  int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom,
> uint32_t max_iters,
>                     uint32_t max_factor, uint32_t flags /*
> XCFLAGS_xxx */,
> -                   struct save_callbacks* callbacks, int hvm);
> +                   struct save_callbacks* callbacks, int hvm,
> +                   unsigned long vm_gid_addr);
>
>
>  /**
> @@ -72,12 +73,15 @@ int xc_domain_save(xc_interface *xch, in
>   * @parm hvm non-zero if this is a HVM restore
>   * @parm pae non-zero if this HVM domain has PAE support enabled
>   * @parm superpages non-zero to allocate guest memory with
> superpages
> + * @parm gid the new generation id of the VM
> + * @parm vm_gid_addr returned with the address of the generation id
> + buffer
>   * @return 0 on success, -1 on failure
>   */
>  int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
>                        unsigned int store_evtchn, unsigned long
> *store_mfn,
>                        unsigned int console_evtchn, unsigned long
> *console_mfn,
> -                      unsigned int hvm, unsigned int pae, int
> superpages);
> +                      unsigned int hvm, unsigned int pae, int
> superpages,
> +                      int increment_gid, unsigned long
> *vm_gid_addr);
>  /**
>   * xc_domain_restore writes a file to disk that contains the device
>   * model saved state.
> diff -r a4d7c27ec1f1 -r 152a79fbe918 tools/libxc/xg_save_restore.h
> --- a/tools/libxc/xg_save_restore.h   Fri Dec 02 13:51:17 2011 -
> 0800
> +++ b/tools/libxc/xg_save_restore.h   Mon Dec 05 10:01:30 2011
> +0000
> @@ -253,6 +253,7 @@
>  #define XC_SAVE_ID_HVM_VIRIDIAN       -11
>  #define XC_SAVE_ID_COMPRESSED_DATA    -12 /* Marker to indicate
> arrival of compressed data */
>  #define XC_SAVE_ID_ENABLE_COMPRESSION -13 /* Marker to enable
> compression logic at receiver side */
> +#define XC_SAVE_ID_HVM_GENERATION_ID_ADDR -14
>
>  /*
>  ** We process save/restore/migrate in batches of pages; the below
> diff -r a4d7c27ec1f1 -r 152a79fbe918 tools/libxl/libxl_create.c
> --- a/tools/libxl/libxl_create.c      Fri Dec 02 13:51:17 2011 -0800
> +++ b/tools/libxl/libxl_create.c      Mon Dec 05 10:01:30 2011 +0000
> @@ -101,6 +101,7 @@ int libxl_init_build_info(libxl_ctx *ctx
>          b_info->u.hvm.vpt_align = 1;
>          b_info->u.hvm.timer_mode = 1;
>          b_info->u.hvm.nested_hvm = 0;
> +        b_info->u.hvm.no_increment_gid = 0;
>          break;
>      case LIBXL_DOMAIN_TYPE_PV:
>          b_info->u.pv.slack_memkb = 8 * 1024; diff -r a4d7c27ec1f1 -
> r 152a79fbe918 tools/libxl/libxl_dom.c
> --- a/tools/libxl/libxl_dom.c Fri Dec 02 13:51:17 2011 -0800
> +++ b/tools/libxl/libxl_dom.c Mon Dec 05 10:01:30 2011 +0000
> @@ -125,7 +125,7 @@ int libxl__build_post(libxl__gc *gc, uin
>      if (info->cpuid != NULL)
>          libxl_cpuid_set(ctx, domid, info->cpuid);
>
> -    ents = libxl__calloc(gc, 12 + (info->max_vcpus * 2) + 2,
> sizeof(char *));
> +    ents = libxl__calloc(gc, 14 + (info->max_vcpus * 2) + 2,
> + sizeof(char *));
>      ents[0] = "memory/static-max";
>      ents[1] = libxl__sprintf(gc, "%d", info->max_memkb);
>      ents[2] = "memory/target";
> @@ -138,9 +138,11 @@ int libxl__build_post(libxl__gc *gc, uin
>      ents[9] = libxl__sprintf(gc, "%"PRIu32, state->store_port);
>      ents[10] = "store/ring-ref";
>      ents[11] = libxl__sprintf(gc, "%lu", state->store_mfn);
> +    ents[12] = "data/generation-id";
> +    ents[13] = libxl__sprintf(gc, "0x%lx", state->vm_gid_addr);
>      for (i = 0; i < info->max_vcpus; i++) {
> -        ents[12+(i*2)]   = libxl__sprintf(gc,
> "cpu/%d/availability", i);
> -        ents[12+(i*2)+1] = (i && info->cur_vcpus && !(info-
> >cur_vcpus & (1 << i)))
> +        ents[14+(i*2)]   = libxl__sprintf(gc,
> "cpu/%d/availability", i);
> +        ents[14+(i*2)+1] = (i && info->cur_vcpus && !(info-
> >cur_vcpus &
> + (1 << i)))
>                              ? "offline" : "online";
>      }
>
> @@ -357,16 +359,19 @@ int libxl__domain_restore_common(libxl__
>      /* read signature */
>      int rc;
>      int hvm, pae, superpages;
> +    int no_increment_gid;
>      switch (info->type) {
>      case LIBXL_DOMAIN_TYPE_HVM:
>          hvm = 1;
>          superpages = 1;
>          pae = info->u.hvm.pae;
> +        no_increment_gid = info->u.hvm.no_increment_gid;
>          break;
>      case LIBXL_DOMAIN_TYPE_PV:
>          hvm = 0;
>          superpages = 0;
>          pae = 1;
> +        no_increment_gid = 0;
>          break;
>      default:
>          return ERROR_INVAL;
> @@ -374,7 +379,7 @@ int libxl__domain_restore_common(libxl__
>      rc = xc_domain_restore(ctx->xch, fd, domid,
>                             state->store_port, &state->store_mfn,
>                             state->console_port, &state-
> >console_mfn,
> -                           hvm, pae, superpages);
> +                           hvm, pae, superpages, no_increment_gid,
> + &state->vm_gid_addr);
>      if ( rc ) {
>          LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "restoring
> domain");
>          return ERROR_FAIL;
> @@ -540,12 +545,22 @@ int libxl__domain_suspend_common(libxl__
>      struct save_callbacks callbacks;
>      struct suspendinfo si;
>      int hvm, rc = ERROR_FAIL;
> +    unsigned long vm_gid_addr;
>
>      switch (type) {
> -    case LIBXL_DOMAIN_TYPE_HVM:
> +    case LIBXL_DOMAIN_TYPE_HVM: {
> +        char *path;
> +        char *addr;
> +
> +        path = libxl__sprintf(gc, "%s/data/generation-id",
> libxl__xs_get_dompath(gc, domid));
> +        addr = libxl__xs_read(gc, XBT_NULL, path);
> +
> +        vm_gid_addr = (addr) ? strtoul(addr, NULL, 0) : 0;
>          hvm = 1;
>          break;
> +    }
>      case LIBXL_DOMAIN_TYPE_PV:
> +        vm_gid_addr = 0;
>          hvm = 0;
>          break;
>      default:
> @@ -583,7 +598,8 @@ int libxl__domain_suspend_common(libxl__
>      callbacks.switch_qemu_logdirty =
> libxl__domain_suspend_common_switch_qemu_logdirty;
>      callbacks.data = &si;
>
> -    rc = xc_domain_save(ctx->xch, fd, domid, 0, 0, flags,
> &callbacks, hvm);
> +    rc = xc_domain_save(ctx->xch, fd, domid, 0, 0, flags,
> &callbacks,
> +                        hvm, vm_gid_addr);
>      if ( rc ) {
>          LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "saving domain:
> %s",
>                           si.guest_responded ?
> diff -r a4d7c27ec1f1 -r 152a79fbe918 tools/libxl/libxl_internal.h
> --- a/tools/libxl/libxl_internal.h    Fri Dec 02 13:51:17 2011 -0800
> +++ b/tools/libxl/libxl_internal.h    Mon Dec 05 10:01:30 2011 +0000
> @@ -199,6 +199,7 @@ typedef struct {
>
>      uint32_t console_port;
>      unsigned long console_mfn;
> +    unsigned long vm_gid_addr;
>  } libxl__domain_build_state;
>
>  _hidden int libxl__build_pre(libxl__gc *gc, uint32_t domid, diff -r
> a4d7c27ec1f1 -r 152a79fbe918 tools/libxl/libxl_types.idl
> --- a/tools/libxl/libxl_types.idl     Fri Dec 02 13:51:17 2011 -0800
> +++ b/tools/libxl/libxl_types.idl     Mon Dec 05 10:01:30 2011 +0000
> @@ -184,6 +184,7 @@ libxl_domain_build_info = Struct("domain
>                                         ("vpt_align", bool),
>                                         ("timer_mode", integer),
>                                         ("nested_hvm", bool),
> +                                       ("no_increment_gid", bool),
>                                         ])),
>                   ("pv", Struct(None, [("kernel",
> libxl_file_reference),
>                                        ("slack_memkb", uint32), diff
> -r a4d7c27ec1f1 -r 152a79fbe918 tools/libxl/xl_cmdimpl.c
> --- a/tools/libxl/xl_cmdimpl.c        Fri Dec 02 13:51:17 2011 -0800
> +++ b/tools/libxl/xl_cmdimpl.c        Mon Dec 05 10:01:30 2011 +0000
> @@ -360,6 +360,7 @@ static void printf_info(int domid,
>          printf("\t\t\t(vpt_align %d)\n", b_info->u.hvm.vpt_align);
>          printf("\t\t\t(timer_mode %d)\n", b_info-
> >u.hvm.timer_mode);
>          printf("\t\t\t(nestedhvm %d)\n", b_info->u.hvm.nested_hvm);
> +        printf("\t\t\t(no_increment_gid %d)\n",
> + b_info->u.hvm.no_increment_gid);
>
>          printf("\t\t\t(device_model %s)\n", dm_info->device_model ?
> : "default");
>          printf("\t\t\t(videoram %d)\n", dm_info->videoram); @@ -
> 1362,6 +1363,7 @@ struct domain_create {
>      const char *restore_file;
>      int migrate_fd; /* -1 means none */
>      char **migration_domname_r; /* from malloc */
> +    int no_increment_gid;
>  };
>
>  static int freemem(libxl_domain_build_info *b_info,
> libxl_device_model_info *dm_info) @@ -1575,6 +1577,8 @@ static int
> create_domain(struct domain_c
>          }
>      }
>
> +    d_config.b_info.u.hvm.no_increment_gid =
> + dom_info->no_increment_gid;
> +
>      if (debug || dom_info->dryrun)
>          printf_info(-1, &d_config, &d_config.dm_info);
>
> @@ -2800,6 +2804,7 @@ static void migrate_receive(int debug, i
>      dom_info.restore_file = "incoming migration stream";
>      dom_info.migrate_fd = 0; /* stdin */
>      dom_info.migration_domname_r = &migration_domname;
> +    dom_info.no_increment_gid = 1;
>
>      rc = create_domain(&dom_info);
>      if (rc < 0) {
> diff -r a4d7c27ec1f1 -r 152a79fbe918
> tools/python/xen/lowlevel/checkpoint/libcheckpoint.c
> --- a/tools/python/xen/lowlevel/checkpoint/libcheckpoint.c    Fri
> Dec 02 13:51:17 2011 -0800
> +++ b/tools/python/xen/lowlevel/checkpoint/libcheckpoint.c    Mon
> Dec 05 10:01:30 2011 +0000
> @@ -175,6 +175,7 @@ int checkpoint_start(checkpoint_state* s  {
>      int hvm, rc;
>      int flags = XCFLAGS_LIVE;
> +    unsigned long vm_gid_addr;
>
>      if (!s->domid) {
>         s->errstr = "checkpoint state not opened"; @@ -185,16
> +186,27 @@ int checkpoint_start(checkpoint_state* s
>
>      hvm = s->domtype > dt_pv;
>      if (hvm) {
> +       char path[128];
> +       char *addr;
> +
> +       sprintf(path, "/local/domain/%u/data/generation-id", s-
> >domid);
> +       addr = xs_read(s->xsh, XBT_NULL, path, NULL);
> +
> +       vm_gid_addr = (addr) ? strtoul(addr, NULL, 0) : 0;
> +       free(addr);
> +
>         flags |= XCFLAGS_HVM;
>         if (switch_qemu_logdirty(s, 1))
>             return -1;
> +    } else {
> +       vm_gid_addr = 0;
>      }
>      if (remus_flags & CHECKPOINT_FLAGS_COMPRESSION)
>        flags |= XCFLAGS_CHECKPOINT_COMPRESS;
>
>      callbacks->switch_qemu_logdirty = noop_switch_logdirty;
>
> -    rc = xc_domain_save(s->xch, fd, s->domid, 0, 0, flags,
> callbacks, hvm);
> +    rc = xc_domain_save(s->xch, fd, s->domid, 0, 0, flags,
> callbacks,
> + hvm, vm_gid_addr);
>
>      if (hvm)
>         switch_qemu_logdirty(s, 0);
> diff -r a4d7c27ec1f1 -r 152a79fbe918 tools/xcutils/xc_restore.c
> --- a/tools/xcutils/xc_restore.c      Fri Dec 02 13:51:17 2011 -0800
> +++ b/tools/xcutils/xc_restore.c      Mon Dec 05 10:01:30 2011 +0000
> @@ -23,7 +23,8 @@ main(int argc, char **argv)
>      xc_interface *xch;
>      int io_fd, ret;
>      int superpages;
> -    unsigned long store_mfn, console_mfn;
> +    unsigned long store_mfn, console_mfn, vm_gid_addr;
> +    int no_increment_gid;
>
>      if ( (argc != 8) && (argc != 9) )
>          errx(1, "usage: %s iofd domid store_evtchn "
> @@ -40,19 +41,25 @@ main(int argc, char **argv)
>      hvm  = atoi(argv[5]);
>      pae  = atoi(argv[6]);
>      apic = atoi(argv[7]);
> -    if ( argc == 9 )
> +    if ( argc >= 9 )
>           superpages = atoi(argv[8]);
>      else
>           superpages = !!hvm;
> +    if ( argc >= 10 )
> +         no_increment_gid = !atoi(argv[9]);
> +    else
> +         no_increment_gid = 0;
>
>      ret = xc_domain_restore(xch, io_fd, domid, store_evtchn,
> &store_mfn,
> -                            console_evtchn, &console_mfn, hvm, pae,
> superpages);
> +                            console_evtchn, &console_mfn, hvm, pae,
> superpages,
> +                            no_increment_gid, &vm_gid_addr);
>
>      if ( ret == 0 )
>      {
>       printf("store-mfn %li\n", store_mfn);
>          if ( !hvm )
>              printf("console-mfn %li\n", console_mfn);
> +     printf("vm-gid-addr %lx\n", vm_gid_addr);
>       fflush(stdout);
>      }
>
> diff -r a4d7c27ec1f1 -r 152a79fbe918 tools/xcutils/xc_save.c
> --- a/tools/xcutils/xc_save.c Fri Dec 02 13:51:17 2011 -0800
> +++ b/tools/xcutils/xc_save.c Mon Dec 05 10:01:30 2011 +0000
> @@ -169,6 +169,10 @@ main(int argc, char **argv)
>      unsigned int maxit, max_f;
>      int io_fd, ret, port;
>      struct save_callbacks callbacks;
> +    char path[128];
> +    struct xs_handle *xs;
> +    char *addr;
> +    unsigned long vm_gid_addr;
>
>      if (argc != 6)
>          errx(1, "usage: %s iofd domid maxit maxf flags", argv[0]);
> @@ -207,8 +211,21 @@ main(int argc, char **argv)
>      memset(&callbacks, 0, sizeof(callbacks));
>      callbacks.suspend = suspend;
>      callbacks.switch_qemu_logdirty = switch_qemu_logdirty;
> +
> +    sprintf(path, "/local/domain/%d/data/generation-id", si.domid);
> +
> +    if ((xs = xs_daemon_open()) == NULL)
> +        errx(1, "Couldn't contact xenstore");
> +
> +    addr = xs_read(xs, XBT_NULL, path, NULL);
> +
> +    xs_daemon_close(xs);
> +
> +    vm_gid_addr = (addr) ? strtoul(addr, NULL, 0) : 0;
> +    free(addr);
> +
>      ret = xc_domain_save(si.xch, io_fd, si.domid, maxit, max_f,
> si.flags,
> -                         &callbacks, !!(si.flags & XCFLAGS_HVM));
> +                         &callbacks, !!(si.flags & XCFLAGS_HVM),
> + vm_gid_addr);
>
>      if (si.suspend_evtchn > 0)
>        xc_suspend_evtchn_release(si.xch, si.xce, si.domid,
> si.suspend_evtchn);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 10:32:20 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 10:32:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXsJb-0006RA-Fq; Tue, 06 Dec 2011 10:31:59 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1RXsJa-0006R1-Dr
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 10:31:58 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1323167471!6342905!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDcxMjI=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19613 invoked from network); 6 Dec 2011 10:31:12 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Dec 2011 10:31:12 -0000
X-IronPort-AV: E=Sophos;i="4.71,304,1320642000"; d="scan'208";a="19697230"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Dec 2011 05:31:10 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Tue, 6 Dec 2011 05:31:10 -0500
Received: from [10.80.2.24] (elijah.uk.xensource.com [10.80.2.24])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pB6AV7pN017088;
	Tue, 6 Dec 2011 02:31:07 -0800
From: George Dunlap <george.dunlap@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1322065473.1005.151.camel@zakaz.uk.xensource.com>
References: <1322060131.30168.15.camel@Abyss> <1322060876.30168.18.camel@Abyss>
	<1322065473.1005.151.camel@zakaz.uk.xensource.com>
Date: Tue, 6 Dec 2011 10:34:57 +0000
Message-ID: <1323167697.2488.5613.camel@elijah>
MIME-Version: 1.0
X-Mailer: Evolution 2.28.3 
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Dario Faggioli <raistlin@linux.it>
Subject: Re: [Xen-devel] [RFC/RFT][PATCH 1 of 3] Move locking into pluggable
 schedulers.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2011-11-23 at 16:24 +0000, Ian Campbell wrote:
> On Wed, 2011-11-23 at 15:07 +0000, Dario Faggioli wrote:
> > Pluggable schedulers' code knows what (and when) to lock better than
> > generic code, let's delegate to them all the concurrency related issues.
> > 
> > Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
> > 
> > diff -r 84b3e46aa7d2 xen/common/sched_credit.c
> > --- a/xen/common/sched_credit.c	Wed Nov 23 12:03:37 2011 +0000
> > +++ b/xen/common/sched_credit.c	Wed Nov 23 15:09:14 2011 +0100
> > @@ -161,6 +161,7 @@ struct csched_dom {
> >   * System-wide private data
> >   */
> >  struct csched_private {
> > +    /* lock for the whole pluggable scheduler, nests inside cpupool_lock */
> >      spinlock_t lock;
> >      struct list_head active_sdom;
> >      uint32_t ncpus;
> 
> Given that every scheduler plugin is going to need this lock perhaps it
> could be provided globally (but still have the responsibility for using
> it fall on the plugin)?

Sorry for the long delay in responding... I don't really like this idea.
For one thing, that would make the generic scheduler code responsible
for making per-cpupool locks, which could look messy, and adds to code
complexity. There's already code to allocate per-pool data structures
for the schedulers -- it seems like just leveraging that would be
easiest.  I also think that logically, having each scheduler in charge
of its own locking makes more sense; having the generic scheduling code
do stuff on behalf of the pluggable scheduler is what caused this
problem in the first place.

If we think having a one-item struct is ugly, could we just use
spinlock_t as the type we allocate / cast to in the sedf scheduler?

 -George


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 10:32:20 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 10:32:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXsJb-0006RA-Fq; Tue, 06 Dec 2011 10:31:59 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1RXsJa-0006R1-Dr
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 10:31:58 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1323167471!6342905!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDcxMjI=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19613 invoked from network); 6 Dec 2011 10:31:12 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Dec 2011 10:31:12 -0000
X-IronPort-AV: E=Sophos;i="4.71,304,1320642000"; d="scan'208";a="19697230"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Dec 2011 05:31:10 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Tue, 6 Dec 2011 05:31:10 -0500
Received: from [10.80.2.24] (elijah.uk.xensource.com [10.80.2.24])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pB6AV7pN017088;
	Tue, 6 Dec 2011 02:31:07 -0800
From: George Dunlap <george.dunlap@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1322065473.1005.151.camel@zakaz.uk.xensource.com>
References: <1322060131.30168.15.camel@Abyss> <1322060876.30168.18.camel@Abyss>
	<1322065473.1005.151.camel@zakaz.uk.xensource.com>
Date: Tue, 6 Dec 2011 10:34:57 +0000
Message-ID: <1323167697.2488.5613.camel@elijah>
MIME-Version: 1.0
X-Mailer: Evolution 2.28.3 
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Dario Faggioli <raistlin@linux.it>
Subject: Re: [Xen-devel] [RFC/RFT][PATCH 1 of 3] Move locking into pluggable
 schedulers.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2011-11-23 at 16:24 +0000, Ian Campbell wrote:
> On Wed, 2011-11-23 at 15:07 +0000, Dario Faggioli wrote:
> > Pluggable schedulers' code knows what (and when) to lock better than
> > generic code, let's delegate to them all the concurrency related issues.
> > 
> > Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
> > 
> > diff -r 84b3e46aa7d2 xen/common/sched_credit.c
> > --- a/xen/common/sched_credit.c	Wed Nov 23 12:03:37 2011 +0000
> > +++ b/xen/common/sched_credit.c	Wed Nov 23 15:09:14 2011 +0100
> > @@ -161,6 +161,7 @@ struct csched_dom {
> >   * System-wide private data
> >   */
> >  struct csched_private {
> > +    /* lock for the whole pluggable scheduler, nests inside cpupool_lock */
> >      spinlock_t lock;
> >      struct list_head active_sdom;
> >      uint32_t ncpus;
> 
> Given that every scheduler plugin is going to need this lock perhaps it
> could be provided globally (but still have the responsibility for using
> it fall on the plugin)?

Sorry for the long delay in responding... I don't really like this idea.
For one thing, that would make the generic scheduler code responsible
for making per-cpupool locks, which could look messy, and adds to code
complexity. There's already code to allocate per-pool data structures
for the schedulers -- it seems like just leveraging that would be
easiest.  I also think that logically, having each scheduler in charge
of its own locking makes more sense; having the generic scheduling code
do stuff on behalf of the pluggable scheduler is what caused this
problem in the first place.

If we think having a one-item struct is ugly, could we just use
spinlock_t as the type we allocate / cast to in the sedf scheduler?

 -George


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 10:54:58 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 10:54:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXsfK-0006hC-Tn; Tue, 06 Dec 2011 10:54:26 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <annie.li@oracle.com>) id 1RXsfJ-0006h6-0G
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 10:54:25 +0000
X-Env-Sender: annie.li@oracle.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1323168817!7055877!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQzMTk4NA==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29864 invoked from network); 6 Dec 2011 10:53:39 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-10.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Dec 2011 10:53:39 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pB6ArXEU008292
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 6 Dec 2011 10:53:33 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pB6ArUSt012016
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 6 Dec 2011 10:53:31 GMT
Received: from abhmt113.oracle.com (abhmt113.oracle.com [141.146.116.65])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pB6ArNSH024956; Tue, 6 Dec 2011 04:53:23 -0600
Received: from [10.182.39.81] (/10.182.39.81)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 06 Dec 2011 02:53:23 -0800
Message-ID: <4EDDF41E.8070200@oracle.com>
Date: Tue, 06 Dec 2011 18:53:18 +0800
From: ANNIE LI <annie.li@oracle.com>
Organization: Oracle Corporation
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.9.2.23) Gecko/20110920 Thunderbird/3.1.15
MIME-Version: 1.0
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"jeremy@goop.org" <jeremy@goop.org>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090208.4EDDF42F.0069,ss=1,re=0.000,fgs=0
Cc: Kurt Hackel <Kurt.Hackel@oracle.com>,
	Paul Durrant <paul.durrant@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: [Xen-devel] xen: patches for supporting sub-page and transitive
	grants
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi

Following two patches introduce and implement interfaces for sub-page 
and transitive grants, and they are based on linux-next branch of 
linux/kernel/git/konrad/xen.git(3.2.0-rc2+). Sub-page and transitive 
grants are new types of grant table V2.

Descriptions for those patches:

Through sub-page grant table interfaces, a domain can grant another 
domain access to a range of bytes within a page, and Xen will then 
prevent the grantee domain accessing outside that range.  For obvious 
reasons, it isn't possible to map these grant references, and domains 
are expected to use the grant copy hypercall instead.

Through transitive grant interfaces,  a domain can create grant 
reference which redirects to another grant reference, so that any 
attempt to access the first grant reference will be redirected to the 
second one.  This is used to implement receiver-side copy on 
inter-domain traffic: rather than copying the packet in dom0, dom0 
creates a transitive grant referencing the original transmit buffer, and 
passes that to the receiving domain.

Diff:

  drivers/xen/grant-table.c |   74 
+++++++++++++++++++++++++++++++++++++++++++++
  include/xen/grant_table.h |   19 +++++++++++
  2 files changed, 93 insertions(+), 0 deletions(-)

Shortlog:

Annie Li (2):
       xen/granttable: Support sub-page grants
       xen/granttable: Support transitive grants

Thanks
Annie

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 10:54:58 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 10:54:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXsfK-0006hC-Tn; Tue, 06 Dec 2011 10:54:26 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <annie.li@oracle.com>) id 1RXsfJ-0006h6-0G
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 10:54:25 +0000
X-Env-Sender: annie.li@oracle.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1323168817!7055877!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQzMTk4NA==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29864 invoked from network); 6 Dec 2011 10:53:39 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-10.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Dec 2011 10:53:39 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pB6ArXEU008292
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 6 Dec 2011 10:53:33 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pB6ArUSt012016
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 6 Dec 2011 10:53:31 GMT
Received: from abhmt113.oracle.com (abhmt113.oracle.com [141.146.116.65])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pB6ArNSH024956; Tue, 6 Dec 2011 04:53:23 -0600
Received: from [10.182.39.81] (/10.182.39.81)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 06 Dec 2011 02:53:23 -0800
Message-ID: <4EDDF41E.8070200@oracle.com>
Date: Tue, 06 Dec 2011 18:53:18 +0800
From: ANNIE LI <annie.li@oracle.com>
Organization: Oracle Corporation
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.9.2.23) Gecko/20110920 Thunderbird/3.1.15
MIME-Version: 1.0
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"jeremy@goop.org" <jeremy@goop.org>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090208.4EDDF42F.0069,ss=1,re=0.000,fgs=0
Cc: Kurt Hackel <Kurt.Hackel@oracle.com>,
	Paul Durrant <paul.durrant@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: [Xen-devel] xen: patches for supporting sub-page and transitive
	grants
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi

Following two patches introduce and implement interfaces for sub-page 
and transitive grants, and they are based on linux-next branch of 
linux/kernel/git/konrad/xen.git(3.2.0-rc2+). Sub-page and transitive 
grants are new types of grant table V2.

Descriptions for those patches:

Through sub-page grant table interfaces, a domain can grant another 
domain access to a range of bytes within a page, and Xen will then 
prevent the grantee domain accessing outside that range.  For obvious 
reasons, it isn't possible to map these grant references, and domains 
are expected to use the grant copy hypercall instead.

Through transitive grant interfaces,  a domain can create grant 
reference which redirects to another grant reference, so that any 
attempt to access the first grant reference will be redirected to the 
second one.  This is used to implement receiver-side copy on 
inter-domain traffic: rather than copying the packet in dom0, dom0 
creates a transitive grant referencing the original transmit buffer, and 
passes that to the receiving domain.

Diff:

  drivers/xen/grant-table.c |   74 
+++++++++++++++++++++++++++++++++++++++++++++
  include/xen/grant_table.h |   19 +++++++++++
  2 files changed, 93 insertions(+), 0 deletions(-)

Shortlog:

Annie Li (2):
       xen/granttable: Support sub-page grants
       xen/granttable: Support transitive grants

Thanks
Annie

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 10:58:03 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 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.xensource.com>)
	id 1RXsiQ-0006oQ-LL; Tue, 06 Dec 2011 10:57:38 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <annie.li@oracle.com>) id 1RXsiP-0006oH-SX
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 10:57:38 +0000
X-Env-Sender: annie.li@oracle.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1323169010!4433515!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQzMTk4NA==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3910 invoked from network); 6 Dec 2011 10:56:51 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-11.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 6 Dec 2011 10:56:51 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pB6AukPL011745
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 6 Dec 2011 10:56:47 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pB6Aujw1021839
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 6 Dec 2011 10:56:45 GMT
Received: from abhmt106.oracle.com (abhmt106.oracle.com [141.146.116.58])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pB6AudKl031193; Tue, 6 Dec 2011 04:56:39 -0600
Received: from annie2.cn.oracle.com.com (/10.182.37.169)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 06 Dec 2011 02:56:38 -0800
From: annie.li@oracle.com
To: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org,
	konrad.wilk@oracle.com, jeremy@goop.org
Date: Tue,  6 Dec 2011 18:56:39 +0800
Message-Id: <1323168999-4434-1-git-send-email-annie.li@oracle.com>
X-Mailer: git-send-email 1.7.6.4
In-Reply-To: <4EDDF41E.8070200@oracle.com>
References: <4EDDF41E.8070200@oracle.com>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090205.4EDDF4EF.00A4,ss=1,re=0.000,fgs=0
Cc: kurt.hackel@oracle.com, annie.li@oracle.com, paul.durrant@citrix.com,
	Ian.Campbell@citrix.com
Subject: [Xen-devel] [PATCH 1/2] xen/granttable: Support sub-page grants
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Annie Li <annie.li@oracle.com>

    -- They can't be used to map the page (so can only be used in a GNTTABOP_copy
       hypercall).
    -- It's possible to grant access with a finer granularity than whole pages.
    -- Xen guarantees that they can be revoked quickly (a normal map grant can
       only be revoked with the cooperation of the domain which has been granted
       access).

Signed-off-by: Annie Li <annie.li@oracle.com>
---
 drivers/xen/grant-table.c |   41 +++++++++++++++++++++++++++++++++++++++++
 include/xen/grant_table.h |   13 +++++++++++++
 2 files changed, 54 insertions(+), 0 deletions(-)

diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
index bd325fd..7a0f4d1 100644
--- a/drivers/xen/grant-table.c
+++ b/drivers/xen/grant-table.c
@@ -261,6 +261,47 @@ int gnttab_grant_foreign_access(domid_t domid, unsigned long frame,
 }
 EXPORT_SYMBOL_GPL(gnttab_grant_foreign_access);
 
+int gnttab_grant_foreign_access_subpage_v2(domid_t domid, unsigned long frame,
+					   int flags, unsigned page_off,
+					   unsigned length)
+{
+	int ref;
+
+	ref = get_free_entries(1);
+	if (unlikely(ref < 0))
+		return -ENOSPC;
+
+	gnttab_grant_foreign_access_ref_subpage_v2(ref, domid, frame, flags,
+						   page_off, length);
+
+	return ref;
+}
+EXPORT_SYMBOL_GPL(gnttab_grant_foreign_access_subpage_v2);
+
+void gnttab_grant_foreign_access_ref_subpage_v2(grant_ref_t ref, domid_t domid,
+						unsigned long frame, int flags,
+						unsigned page_off,
+						unsigned length)
+{
+	BUG_ON(flags & (GTF_accept_transfer | GTF_reading |
+			GTF_writing | GTF_transitive));
+	BUG_ON(grant_table_version == 1);
+	gnttab_shared.v2[ref].sub_page.frame = frame;
+	gnttab_shared.v2[ref].sub_page.page_off = page_off;
+	gnttab_shared.v2[ref].sub_page.length = length;
+	gnttab_shared.v2[ref].hdr.domid = domid;
+	wmb();
+	gnttab_shared.v2[ref].hdr.flags =
+				GTF_permit_access | GTF_sub_page | flags;
+}
+EXPORT_SYMBOL_GPL(gnttab_grant_foreign_access_ref_subpage_v2);
+
+bool gnttab_subpage_trans_grants_available(void)
+{
+	return grant_table_version == 2;
+}
+EXPORT_SYMBOL_GPL(gnttab_subpage_trans_grants_available);
+
 static int gnttab_query_foreign_access_v1(grant_ref_t ref)
 {
 	return gnttab_shared.v1[ref].flags & (GTF_reading|GTF_writing);
diff --git a/include/xen/grant_table.h b/include/xen/grant_table.h
index fea4954..7e43652 100644
--- a/include/xen/grant_table.h
+++ b/include/xen/grant_table.h
@@ -62,6 +62,15 @@ int gnttab_resume(void);
 
 int gnttab_grant_foreign_access(domid_t domid, unsigned long frame,
 				int readonly);
+int gnttab_grant_foreign_access_subpage_v2(domid_t domid, unsigned long frame,
+					   int flags, unsigned page_off,
+					   unsigned length);
+
+/*
+ * Are sub-page or transitive grants available on this version of Xen?  Returns
+ * true if they are, and false if they're not.
+ */
+bool gnttab_subpage_trans_grants_available(void);
 
 /*
  * End access through the given grant reference, iff the grant entry is no
@@ -108,6 +117,10 @@ void gnttab_cancel_free_callback(struct gnttab_free_callback *callback);
 
 void gnttab_grant_foreign_access_ref(grant_ref_t ref, domid_t domid,
 				     unsigned long frame, int readonly);
+void gnttab_grant_foreign_access_ref_subpage_v2(grant_ref_t ref, domid_t domid,
+						unsigned long frame, int flags,
+						unsigned page_off,
+						unsigned length);
 
 void gnttab_grant_foreign_transfer_ref(grant_ref_t, domid_t domid,
 				       unsigned long pfn);
-- 
1.7.6.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 10:58:03 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 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.xensource.com>)
	id 1RXsiQ-0006oQ-LL; Tue, 06 Dec 2011 10:57:38 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <annie.li@oracle.com>) id 1RXsiP-0006oH-SX
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 10:57:38 +0000
X-Env-Sender: annie.li@oracle.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1323169010!4433515!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQzMTk4NA==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3910 invoked from network); 6 Dec 2011 10:56:51 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-11.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 6 Dec 2011 10:56:51 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pB6AukPL011745
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 6 Dec 2011 10:56:47 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pB6Aujw1021839
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 6 Dec 2011 10:56:45 GMT
Received: from abhmt106.oracle.com (abhmt106.oracle.com [141.146.116.58])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pB6AudKl031193; Tue, 6 Dec 2011 04:56:39 -0600
Received: from annie2.cn.oracle.com.com (/10.182.37.169)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 06 Dec 2011 02:56:38 -0800
From: annie.li@oracle.com
To: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org,
	konrad.wilk@oracle.com, jeremy@goop.org
Date: Tue,  6 Dec 2011 18:56:39 +0800
Message-Id: <1323168999-4434-1-git-send-email-annie.li@oracle.com>
X-Mailer: git-send-email 1.7.6.4
In-Reply-To: <4EDDF41E.8070200@oracle.com>
References: <4EDDF41E.8070200@oracle.com>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090205.4EDDF4EF.00A4,ss=1,re=0.000,fgs=0
Cc: kurt.hackel@oracle.com, annie.li@oracle.com, paul.durrant@citrix.com,
	Ian.Campbell@citrix.com
Subject: [Xen-devel] [PATCH 1/2] xen/granttable: Support sub-page grants
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Annie Li <annie.li@oracle.com>

    -- They can't be used to map the page (so can only be used in a GNTTABOP_copy
       hypercall).
    -- It's possible to grant access with a finer granularity than whole pages.
    -- Xen guarantees that they can be revoked quickly (a normal map grant can
       only be revoked with the cooperation of the domain which has been granted
       access).

Signed-off-by: Annie Li <annie.li@oracle.com>
---
 drivers/xen/grant-table.c |   41 +++++++++++++++++++++++++++++++++++++++++
 include/xen/grant_table.h |   13 +++++++++++++
 2 files changed, 54 insertions(+), 0 deletions(-)

diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
index bd325fd..7a0f4d1 100644
--- a/drivers/xen/grant-table.c
+++ b/drivers/xen/grant-table.c
@@ -261,6 +261,47 @@ int gnttab_grant_foreign_access(domid_t domid, unsigned long frame,
 }
 EXPORT_SYMBOL_GPL(gnttab_grant_foreign_access);
 
+int gnttab_grant_foreign_access_subpage_v2(domid_t domid, unsigned long frame,
+					   int flags, unsigned page_off,
+					   unsigned length)
+{
+	int ref;
+
+	ref = get_free_entries(1);
+	if (unlikely(ref < 0))
+		return -ENOSPC;
+
+	gnttab_grant_foreign_access_ref_subpage_v2(ref, domid, frame, flags,
+						   page_off, length);
+
+	return ref;
+}
+EXPORT_SYMBOL_GPL(gnttab_grant_foreign_access_subpage_v2);
+
+void gnttab_grant_foreign_access_ref_subpage_v2(grant_ref_t ref, domid_t domid,
+						unsigned long frame, int flags,
+						unsigned page_off,
+						unsigned length)
+{
+	BUG_ON(flags & (GTF_accept_transfer | GTF_reading |
+			GTF_writing | GTF_transitive));
+	BUG_ON(grant_table_version == 1);
+	gnttab_shared.v2[ref].sub_page.frame = frame;
+	gnttab_shared.v2[ref].sub_page.page_off = page_off;
+	gnttab_shared.v2[ref].sub_page.length = length;
+	gnttab_shared.v2[ref].hdr.domid = domid;
+	wmb();
+	gnttab_shared.v2[ref].hdr.flags =
+				GTF_permit_access | GTF_sub_page | flags;
+}
+EXPORT_SYMBOL_GPL(gnttab_grant_foreign_access_ref_subpage_v2);
+
+bool gnttab_subpage_trans_grants_available(void)
+{
+	return grant_table_version == 2;
+}
+EXPORT_SYMBOL_GPL(gnttab_subpage_trans_grants_available);
+
 static int gnttab_query_foreign_access_v1(grant_ref_t ref)
 {
 	return gnttab_shared.v1[ref].flags & (GTF_reading|GTF_writing);
diff --git a/include/xen/grant_table.h b/include/xen/grant_table.h
index fea4954..7e43652 100644
--- a/include/xen/grant_table.h
+++ b/include/xen/grant_table.h
@@ -62,6 +62,15 @@ int gnttab_resume(void);
 
 int gnttab_grant_foreign_access(domid_t domid, unsigned long frame,
 				int readonly);
+int gnttab_grant_foreign_access_subpage_v2(domid_t domid, unsigned long frame,
+					   int flags, unsigned page_off,
+					   unsigned length);
+
+/*
+ * Are sub-page or transitive grants available on this version of Xen?  Returns
+ * true if they are, and false if they're not.
+ */
+bool gnttab_subpage_trans_grants_available(void);
 
 /*
  * End access through the given grant reference, iff the grant entry is no
@@ -108,6 +117,10 @@ void gnttab_cancel_free_callback(struct gnttab_free_callback *callback);
 
 void gnttab_grant_foreign_access_ref(grant_ref_t ref, domid_t domid,
 				     unsigned long frame, int readonly);
+void gnttab_grant_foreign_access_ref_subpage_v2(grant_ref_t ref, domid_t domid,
+						unsigned long frame, int flags,
+						unsigned page_off,
+						unsigned length);
 
 void gnttab_grant_foreign_transfer_ref(grant_ref_t, domid_t domid,
 				       unsigned long pfn);
-- 
1.7.6.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 10:58:32 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 10:58:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXsj0-0006qW-36; Tue, 06 Dec 2011 10:58:14 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <annie.li@oracle.com>) id 1RXsiy-0006qB-TY
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 10:58:13 +0000
X-Env-Sender: annie.li@oracle.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1323169045!6351872!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQzMTk4NA==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18032 invoked from network); 6 Dec 2011 10:57:27 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-5.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Dec 2011 10:57:27 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pB6AvMnR012573
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 6 Dec 2011 10:57:23 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pB6AvLos008895
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 6 Dec 2011 10:57:22 GMT
Received: from abhmt113.oracle.com (abhmt113.oracle.com [141.146.116.65])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pB6AvGx9031529; Tue, 6 Dec 2011 04:57:16 -0600
Received: from annie2.cn.oracle.com.com (/10.182.37.169)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 06 Dec 2011 02:57:15 -0800
From: annie.li@oracle.com
To: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org,
	konrad.wilk@oracle.com, jeremy@goop.org
Date: Tue,  6 Dec 2011 18:57:23 +0800
Message-Id: <1323169043-4470-1-git-send-email-annie.li@oracle.com>
X-Mailer: git-send-email 1.7.6.4
In-Reply-To: <4EDDF41E.8070200@oracle.com>
References: <4EDDF41E.8070200@oracle.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090204.4EDDF514.0037,ss=1,re=0.000,fgs=0
Cc: kurt.hackel@oracle.com, annie.li@oracle.com, paul.durrant@citrix.com,
	Ian.Campbell@citrix.com
Subject: [Xen-devel] [PATCH 2/2] xen/granttable: Support transitive grants
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Annie Li <annie.li@oracle.com>

These allow a domain A which has been granted access on a page of domain B's
memory to issue domain C with a copy-grant on the same page.  This is useful
e.g. for forwarding packets between domains.

Signed-off-by: Annie Li <annie.li@oracle.com>
---
 drivers/xen/grant-table.c |   33 +++++++++++++++++++++++++++++++++
 include/xen/grant_table.h |    6 ++++++
 2 files changed, 39 insertions(+), 0 deletions(-)

diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
index 7a0f4d1..d64b7c5 100644
--- a/drivers/xen/grant-table.c
+++ b/drivers/xen/grant-table.c
@@ -296,6 +296,39 @@ void gnttab_grant_foreign_access_ref_subpage_v2(grant_ref_t ref, domid_t domid,
 }
 EXPORT_SYMBOL_GPL(gnttab_grant_foreign_access_ref_subpage_v2);
 
+int gnttab_grant_foreign_access_trans_v2(domid_t domid, int flags,
+					 domid_t trans_domid,
+					 grant_ref_t trans_gref)
+{
+	int ref;
+
+	ref = get_free_entries(1);
+	if (unlikely(ref < 0))
+		return -ENOSPC;
+
+	gnttab_grant_foreign_access_ref_trans_v2(ref, domid, flags,
+						 trans_domid, trans_gref);
+
+	return ref;
+}
+EXPORT_SYMBOL_GPL(gnttab_grant_foreign_access_trans_v2);
+
+void gnttab_grant_foreign_access_ref_trans_v2(grant_ref_t ref, domid_t domid,
+					      int flags, domid_t trans_domid,
+					      grant_ref_t trans_gref)
+{
+	BUG_ON(flags & (GTF_accept_transfer | GTF_reading |
+			GTF_writing | GTF_sub_page));
+	BUG_ON(grant_table_version == 1);
+	gnttab_shared.v2[ref].transitive.trans_domid = trans_domid;
+	gnttab_shared.v2[ref].transitive.gref = trans_gref;
+	gnttab_shared.v2[ref].hdr.domid = domid;
+	wmb();
+	gnttab_shared.v2[ref].hdr.flags =
+				GTF_permit_access | GTF_transitive | flags;
+}
+EXPORT_SYMBOL_GPL(gnttab_grant_foreign_access_ref_trans_v2);
+
 bool gnttab_subpage_trans_grants_available(void)
 {
 	return grant_table_version == 2;
diff --git a/include/xen/grant_table.h b/include/xen/grant_table.h
index 7e43652..35a8c73 100644
--- a/include/xen/grant_table.h
+++ b/include/xen/grant_table.h
@@ -65,6 +65,9 @@ int gnttab_grant_foreign_access(domid_t domid, unsigned long frame,
 int gnttab_grant_foreign_access_subpage_v2(domid_t domid, unsigned long frame,
 					   int flags, unsigned page_off,
 					   unsigned length);
+int gnttab_grant_foreign_access_trans_v2(domid_t domid, int flags,
+					 domid_t trans_domid,
+					 grant_ref_t trans_gref);
 
 /*
  * Are sub-page or transitive grants available on this version of Xen?  Returns
@@ -121,6 +124,9 @@ void gnttab_grant_foreign_access_ref_subpage_v2(grant_ref_t ref, domid_t domid,
 						unsigned long frame, int flags,
 						unsigned page_off,
 						unsigned length);
+void gnttab_grant_foreign_access_ref_trans_v2(grant_ref_t ref, domid_t domid,
+					      int flags, domid_t trans_domid,
+					      grant_ref_t trans_gref);
 
 void gnttab_grant_foreign_transfer_ref(grant_ref_t, domid_t domid,
 				       unsigned long pfn);
-- 
1.7.6.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 10:58:32 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 10:58:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXsj0-0006qW-36; Tue, 06 Dec 2011 10:58:14 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <annie.li@oracle.com>) id 1RXsiy-0006qB-TY
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 10:58:13 +0000
X-Env-Sender: annie.li@oracle.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1323169045!6351872!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQzMTk4NA==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18032 invoked from network); 6 Dec 2011 10:57:27 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-5.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Dec 2011 10:57:27 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pB6AvMnR012573
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 6 Dec 2011 10:57:23 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pB6AvLos008895
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 6 Dec 2011 10:57:22 GMT
Received: from abhmt113.oracle.com (abhmt113.oracle.com [141.146.116.65])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pB6AvGx9031529; Tue, 6 Dec 2011 04:57:16 -0600
Received: from annie2.cn.oracle.com.com (/10.182.37.169)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 06 Dec 2011 02:57:15 -0800
From: annie.li@oracle.com
To: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org,
	konrad.wilk@oracle.com, jeremy@goop.org
Date: Tue,  6 Dec 2011 18:57:23 +0800
Message-Id: <1323169043-4470-1-git-send-email-annie.li@oracle.com>
X-Mailer: git-send-email 1.7.6.4
In-Reply-To: <4EDDF41E.8070200@oracle.com>
References: <4EDDF41E.8070200@oracle.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090204.4EDDF514.0037,ss=1,re=0.000,fgs=0
Cc: kurt.hackel@oracle.com, annie.li@oracle.com, paul.durrant@citrix.com,
	Ian.Campbell@citrix.com
Subject: [Xen-devel] [PATCH 2/2] xen/granttable: Support transitive grants
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Annie Li <annie.li@oracle.com>

These allow a domain A which has been granted access on a page of domain B's
memory to issue domain C with a copy-grant on the same page.  This is useful
e.g. for forwarding packets between domains.

Signed-off-by: Annie Li <annie.li@oracle.com>
---
 drivers/xen/grant-table.c |   33 +++++++++++++++++++++++++++++++++
 include/xen/grant_table.h |    6 ++++++
 2 files changed, 39 insertions(+), 0 deletions(-)

diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
index 7a0f4d1..d64b7c5 100644
--- a/drivers/xen/grant-table.c
+++ b/drivers/xen/grant-table.c
@@ -296,6 +296,39 @@ void gnttab_grant_foreign_access_ref_subpage_v2(grant_ref_t ref, domid_t domid,
 }
 EXPORT_SYMBOL_GPL(gnttab_grant_foreign_access_ref_subpage_v2);
 
+int gnttab_grant_foreign_access_trans_v2(domid_t domid, int flags,
+					 domid_t trans_domid,
+					 grant_ref_t trans_gref)
+{
+	int ref;
+
+	ref = get_free_entries(1);
+	if (unlikely(ref < 0))
+		return -ENOSPC;
+
+	gnttab_grant_foreign_access_ref_trans_v2(ref, domid, flags,
+						 trans_domid, trans_gref);
+
+	return ref;
+}
+EXPORT_SYMBOL_GPL(gnttab_grant_foreign_access_trans_v2);
+
+void gnttab_grant_foreign_access_ref_trans_v2(grant_ref_t ref, domid_t domid,
+					      int flags, domid_t trans_domid,
+					      grant_ref_t trans_gref)
+{
+	BUG_ON(flags & (GTF_accept_transfer | GTF_reading |
+			GTF_writing | GTF_sub_page));
+	BUG_ON(grant_table_version == 1);
+	gnttab_shared.v2[ref].transitive.trans_domid = trans_domid;
+	gnttab_shared.v2[ref].transitive.gref = trans_gref;
+	gnttab_shared.v2[ref].hdr.domid = domid;
+	wmb();
+	gnttab_shared.v2[ref].hdr.flags =
+				GTF_permit_access | GTF_transitive | flags;
+}
+EXPORT_SYMBOL_GPL(gnttab_grant_foreign_access_ref_trans_v2);
+
 bool gnttab_subpage_trans_grants_available(void)
 {
 	return grant_table_version == 2;
diff --git a/include/xen/grant_table.h b/include/xen/grant_table.h
index 7e43652..35a8c73 100644
--- a/include/xen/grant_table.h
+++ b/include/xen/grant_table.h
@@ -65,6 +65,9 @@ int gnttab_grant_foreign_access(domid_t domid, unsigned long frame,
 int gnttab_grant_foreign_access_subpage_v2(domid_t domid, unsigned long frame,
 					   int flags, unsigned page_off,
 					   unsigned length);
+int gnttab_grant_foreign_access_trans_v2(domid_t domid, int flags,
+					 domid_t trans_domid,
+					 grant_ref_t trans_gref);
 
 /*
  * Are sub-page or transitive grants available on this version of Xen?  Returns
@@ -121,6 +124,9 @@ void gnttab_grant_foreign_access_ref_subpage_v2(grant_ref_t ref, domid_t domid,
 						unsigned long frame, int flags,
 						unsigned page_off,
 						unsigned length);
+void gnttab_grant_foreign_access_ref_trans_v2(grant_ref_t ref, domid_t domid,
+					      int flags, domid_t trans_domid,
+					      grant_ref_t trans_gref);
 
 void gnttab_grant_foreign_transfer_ref(grant_ref_t, domid_t domid,
 				       unsigned long pfn);
-- 
1.7.6.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 11:04:40 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 11:04:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXsou-0007EH-Uh; Tue, 06 Dec 2011 11:04:20 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <juergen.gross@ts.fujitsu.com>) id 1RXsot-0007Di-7s
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 11:04:19 +0000
X-Env-Sender: juergen.gross@ts.fujitsu.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1323169412!7140546!1
X-Originating-IP: [80.70.172.49]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNzAuMTcyLjQ5ID0+IDIzNzk3Nw==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1997 invoked from network); 6 Dec 2011 11:03:32 -0000
Received: from dgate10.ts.fujitsu.com (HELO dgate10.ts.fujitsu.com)
	(80.70.172.49)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Dec 2011 11:03:32 -0000
DomainKey-Signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns;
	h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV:
	Received:Received:Message-ID:Date:From:Organization:
	User-Agent:MIME-Version:To:CC:Subject:References:
	In-Reply-To:Content-Type:Content-Transfer-Encoding;
	b=C2sYAeQOaFkmhBwNXfa4x8OAf3w1mgBDzV12Qj5wIpqw9i/wCoX9crKS
	EronxhminKRcIlOhtK1pSOf6ou2D8uUTm0nv0ihaTMKUS/4S5eccLwA8o
	u7NSXL9By86W7/jkyQ/+DA2h5ZSvyf36Jej9b2Bb5gdTCxDiUWDj7HI2x
	QWln2hDs501KkwJ3W/uztFuFsT2275wB+YVPNpzlF7S8rlqPWWla6tfGl
	5wZSTbNSRpLm3i6x0IWCU+tVfOdhs;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=ts.fujitsu.com; i=juergen.gross@ts.fujitsu.com;
	q=dns/txt; s=s1536b; t=1323169413; x=1354705413;
	h=message-id:date:from:mime-version:to:cc:subject:
	references:in-reply-to:content-transfer-encoding;
	bh=ca7vm5ewa40JKdj1Rf7W8xso1LyItRcJnj/ToXJgleY=;
	b=OK/A2Y596YRbeSEB8pJYNU6TpCLwkluqx30SObW6+qrhS4H0Z0woKwmj
	XLl11QAThsQ8Yj0cQSfhfuAjYB3OdmHRq/ObEGD0sFh7u51GYesO9dCZ9
	ixQmlO3Z2Kao/4ZIacJcy91DrMRFBGG288949mTGRbMNDPvTLxOVkaIzT
	HPfaXJPrCZv1E+Rnx8ZsTh0PJw3Bpvp7XllgUq5q3cqYE0gtftjjSsLWR
	axXdc6EQK43N0wRcPl03DPaXEkeLY;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.71,304,1320620400"; d="scan'208";a="95126070"
Received: from abgdgate30u.abg.fsc.net ([172.25.138.66])
	by dgate10u.abg.fsc.net with ESMTP; 06 Dec 2011 12:03:33 +0100
X-IronPort-AV: E=Sophos;i="4.71,303,1320620400"; d="scan'208";a="124464110"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdgate30u.abg.fsc.net with ESMTP; 06 Dec 2011 12:03:32 +0100
Received: from [172.17.21.50] (verdon.osd.mch.fsc.net [172.17.21.50])
	by sanpedro.mch.fsc.net (Postfix) with ESMTP id 3ADBD95B5FD;
	Tue,  6 Dec 2011 12:03:32 +0100 (CET)
Message-ID: <4EDDF684.3030104@ts.fujitsu.com>
Date: Tue, 06 Dec 2011 12:03:32 +0100
From: Juergen Gross <juergen.gross@ts.fujitsu.com>
Organization: Fujitsu Technology Solutions
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.24) Gecko/20111114 Iceowl/1.0b2 Icedove/3.1.16
MIME-Version: 1.0
To: Dario Faggioli <raistlin@linux.it>
References: <1322060131.30168.15.camel@Abyss> <4EDDD485.70208@ts.fujitsu.com>
	<1323166254.2605.2.camel@Solace>
In-Reply-To: <1323166254.2605.2.camel@Solace>
Cc: George Dunlap <George.Dunlap@eu.citrix.com>, xen-devel@lists.xensource.com,
	Keir Fraser <keir@xen.org>
Subject: Re: [Xen-devel] [RFC/RFT][PATCH 0 of 3] rework locking in
	sched_adjust
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi Dario,

On 12/06/2011 11:10 AM, Dario Faggioli wrote:
> On Tue, 2011-12-06 at 09:38 +0100, Juergen Gross wrote:
>> Sorry, does not work with sched=sedf:
>>
> Hi Juergen,
>
> Thanks for reporting. I'm reworking this as per Ian's suggestions, but
> I'll check this out. Can I as how you made this happening? Just trying
> to change a sedf-domain scheduling parameter I guess... Is that right?

I booted with sched=sedf and tried to change Domain-0 parameters with:

xl sched-sedf -d Domain-0 -w 10


Juergen

-- 
Juergen Gross                 Principal Developer Operating Systems
PDG ES&S SWE OS6                       Telephone: +49 (0) 89 3222 2967
Fujitsu Technology Solutions              e-mail: juergen.gross@ts.fujitsu.com
Domagkstr. 28                           Internet: ts.fujitsu.com
D-80807 Muenchen                 Company details: ts.fujitsu.com/imprint.html


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 11:04:40 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 11:04:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXsou-0007EH-Uh; Tue, 06 Dec 2011 11:04:20 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <juergen.gross@ts.fujitsu.com>) id 1RXsot-0007Di-7s
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 11:04:19 +0000
X-Env-Sender: juergen.gross@ts.fujitsu.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1323169412!7140546!1
X-Originating-IP: [80.70.172.49]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNzAuMTcyLjQ5ID0+IDIzNzk3Nw==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1997 invoked from network); 6 Dec 2011 11:03:32 -0000
Received: from dgate10.ts.fujitsu.com (HELO dgate10.ts.fujitsu.com)
	(80.70.172.49)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Dec 2011 11:03:32 -0000
DomainKey-Signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns;
	h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV:
	Received:Received:Message-ID:Date:From:Organization:
	User-Agent:MIME-Version:To:CC:Subject:References:
	In-Reply-To:Content-Type:Content-Transfer-Encoding;
	b=C2sYAeQOaFkmhBwNXfa4x8OAf3w1mgBDzV12Qj5wIpqw9i/wCoX9crKS
	EronxhminKRcIlOhtK1pSOf6ou2D8uUTm0nv0ihaTMKUS/4S5eccLwA8o
	u7NSXL9By86W7/jkyQ/+DA2h5ZSvyf36Jej9b2Bb5gdTCxDiUWDj7HI2x
	QWln2hDs501KkwJ3W/uztFuFsT2275wB+YVPNpzlF7S8rlqPWWla6tfGl
	5wZSTbNSRpLm3i6x0IWCU+tVfOdhs;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=ts.fujitsu.com; i=juergen.gross@ts.fujitsu.com;
	q=dns/txt; s=s1536b; t=1323169413; x=1354705413;
	h=message-id:date:from:mime-version:to:cc:subject:
	references:in-reply-to:content-transfer-encoding;
	bh=ca7vm5ewa40JKdj1Rf7W8xso1LyItRcJnj/ToXJgleY=;
	b=OK/A2Y596YRbeSEB8pJYNU6TpCLwkluqx30SObW6+qrhS4H0Z0woKwmj
	XLl11QAThsQ8Yj0cQSfhfuAjYB3OdmHRq/ObEGD0sFh7u51GYesO9dCZ9
	ixQmlO3Z2Kao/4ZIacJcy91DrMRFBGG288949mTGRbMNDPvTLxOVkaIzT
	HPfaXJPrCZv1E+Rnx8ZsTh0PJw3Bpvp7XllgUq5q3cqYE0gtftjjSsLWR
	axXdc6EQK43N0wRcPl03DPaXEkeLY;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.71,304,1320620400"; d="scan'208";a="95126070"
Received: from abgdgate30u.abg.fsc.net ([172.25.138.66])
	by dgate10u.abg.fsc.net with ESMTP; 06 Dec 2011 12:03:33 +0100
X-IronPort-AV: E=Sophos;i="4.71,303,1320620400"; d="scan'208";a="124464110"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdgate30u.abg.fsc.net with ESMTP; 06 Dec 2011 12:03:32 +0100
Received: from [172.17.21.50] (verdon.osd.mch.fsc.net [172.17.21.50])
	by sanpedro.mch.fsc.net (Postfix) with ESMTP id 3ADBD95B5FD;
	Tue,  6 Dec 2011 12:03:32 +0100 (CET)
Message-ID: <4EDDF684.3030104@ts.fujitsu.com>
Date: Tue, 06 Dec 2011 12:03:32 +0100
From: Juergen Gross <juergen.gross@ts.fujitsu.com>
Organization: Fujitsu Technology Solutions
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.24) Gecko/20111114 Iceowl/1.0b2 Icedove/3.1.16
MIME-Version: 1.0
To: Dario Faggioli <raistlin@linux.it>
References: <1322060131.30168.15.camel@Abyss> <4EDDD485.70208@ts.fujitsu.com>
	<1323166254.2605.2.camel@Solace>
In-Reply-To: <1323166254.2605.2.camel@Solace>
Cc: George Dunlap <George.Dunlap@eu.citrix.com>, xen-devel@lists.xensource.com,
	Keir Fraser <keir@xen.org>
Subject: Re: [Xen-devel] [RFC/RFT][PATCH 0 of 3] rework locking in
	sched_adjust
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi Dario,

On 12/06/2011 11:10 AM, Dario Faggioli wrote:
> On Tue, 2011-12-06 at 09:38 +0100, Juergen Gross wrote:
>> Sorry, does not work with sched=sedf:
>>
> Hi Juergen,
>
> Thanks for reporting. I'm reworking this as per Ian's suggestions, but
> I'll check this out. Can I as how you made this happening? Just trying
> to change a sedf-domain scheduling parameter I guess... Is that right?

I booted with sched=sedf and tried to change Domain-0 parameters with:

xl sched-sedf -d Domain-0 -w 10


Juergen

-- 
Juergen Gross                 Principal Developer Operating Systems
PDG ES&S SWE OS6                       Telephone: +49 (0) 89 3222 2967
Fujitsu Technology Solutions              e-mail: juergen.gross@ts.fujitsu.com
Domagkstr. 28                           Internet: ts.fujitsu.com
D-80807 Muenchen                 Company details: ts.fujitsu.com/imprint.html


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 11:24:01 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 11:24:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXt7Y-0007Tt-TJ; Tue, 06 Dec 2011 11:23:36 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <davidtecher@yahoo.fr>) id 1RXt7X-0007To-NL
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 11:23:36 +0000
X-Env-Sender: davidtecher@yahoo.fr
X-Msg-Ref: server-3.tower-216.messagelabs.com!1323170569!6310523!1
X-Originating-IP: [212.82.108.207]
X-SpamReason: No, hits=1.1 required=7.0 tests=BODY_RANDOM_LONG,
	HTML_40_50, HTML_MESSAGE, ML_RADAR_SPEW_LINKS_12, ML_RADAR_SPEW_LINKS_14,
	ML_RADAR_SPEW_LINKS_6,spamassassin: 
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28820 invoked from network); 6 Dec 2011 11:22:49 -0000
Received: from nm21-vm3.bullet.mail.ird.yahoo.com (HELO
	nm21-vm3.bullet.mail.ird.yahoo.com) (212.82.108.207)
	by server-3.tower-216.messagelabs.com with SMTP;
	6 Dec 2011 11:22:49 -0000
Received: from [77.238.189.57] by nm21.bullet.mail.ird.yahoo.com with NNFMP;
	06 Dec 2011 11:22:49 -0000
Received: from [212.82.108.250] by tm10.bullet.mail.ird.yahoo.com with NNFMP;
	06 Dec 2011 11:22:48 -0000
Received: from [127.0.0.1] by omp1015.mail.ird.yahoo.com with NNFMP;
	06 Dec 2011 11:22:48 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 908756.67870.bm@omp1015.mail.ird.yahoo.com
Received: (qmail 91875 invoked by uid 60001); 6 Dec 2011 11:22:48 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.fr; s=s1024;
	t=1323170568; bh=Jx/Hxn2JR7R/1Ujly8dN0CSCcLaskHb+5AoQkgCj3mQ=;
	h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type;
	b=t/lJfG/SIpFQnTLAF0SBGgJx8s50k+VI32NFR+nRHgNpxOnRnlpVHZ7jnNPBl/YEWqs86q9NbxKOd1unbliHl7xgDPxr567yyuOdssSBSSG2CcGuLkZ33CgqI374uwK2xci8T3OmSbN1KLFAu2QXHJKHruz46vUEsU5Vp1bA+sM=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.fr;
	h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type;
	b=0WqKfGs+HX3Tv8nhotD/CzY1nEO4E4umayfI3JkW4xZnhQ8ZDJ5RGeNL3sIWSxsIU5Yra57KJjRSdC89NsLf/5OyO3uZFo5CgQP7TjSaE+QZwyH7VO1I4mzXlU7KkTRzY5qjEILPhTGG8KGywu5v8h7zWhaHFPlQYN2Rh52tfS8=;
X-YMail-OSG: _US2wskVM1mUoM59Pf8XpZ30nNVBqoUhoTseHnrLo5ZMJx7
	WjQkJJ2MuDB5olTMXrE36u.2qzD77TScBePgEDlgZxT1KT8A8ub65ks3E5l1
	FJosNeJpKtqCME7FGsH3gAK.7CubS3w1CsXcWV9GOxy8xox4cmHE6tRXd1mi
	sg117_sxuwG7jouDlyiUFGY1I7BBiSD.KoBaaHxFD6gQQSiM4pd9sqSYGf3W
	yQqUedwYlU2bo84luPeAuGIfuD0g0ay46H89nKBbc63Ppc.K1IsD9kdBgyao
	7bBh4jO9uaplhVae4ie33.eEKpMr4.ico5RI7Us9DRf4lUpWYXdUHJI2bPa5
	vvMUF4APg6RULcqLKC3h2IrwR27HBjaWmkIZrWWK2v5i6D2SyfsmsXLhLhPJ
	LyKxyuHXwVixnjFWQYsf6q8ZfKo5eqcGFQhfmfs.sX5zAp6nIAuf87g.qYt0
	.nC_IaCBK4kiR5ULnsby5GMV8vgYKO8vHhSSG3bAZh6jVfB6.m0d4QYCm7um
	tYLKz5JeL2HpSCbpx.I3BleO_2T4sGHqsKA3pEIS2cTX15m8CSNq1OFf5Mgs
	25VxtYC0KCSntSCXDklfmXCpzzykE.iLcOh7fFs3GAeWF5YzGVVvJWMnIGQH
	jIJeVORjy7jevlMyRrnNzFQ_YpWElCI1z2d1p6ZrGpcVC4w8Pow8sofkGYij
	D0TEYTMikpL3gWHGdkgd1SxJKbhq88Oe2PHxxu0QmcRI47uv8kPxplNVEfuc
	LfXotF3JUxV_6KmMTU7EH.2g3rPoPX4JFTkCbsExCpmgiZ6_Cx3NEXAwRj_S
	qwj792Vp9JIDcTA7hN.VfeG6Ay.sM9UcO66Di
Received: from [195.167.237.98] by web29813.mail.ird.yahoo.com via HTTP;
	Tue, 06 Dec 2011 11:22:48 GMT
X-Mailer: YahooMailWebService/0.8.115.331698
References: <20110922182705.GE12984@reaktio.net>
	<1316728444821-4831624.post@n5.nabble.com>
	<1316777654598-4833174.post@n5.nabble.com>
	<1316786412428-4833637.post@n5.nabble.com>
	<20110923172115.GI12984@reaktio.net>
	<1318672856439-4904945.post@n5.nabble.com>
	<1319630071722-4939528.post@n5.nabble.com>
	<1319636130.20499.YahooMailNeo@web29808.mail.ird.yahoo.com>
	<1319695116310-4942047.post@n5.nabble.com>
	<1319710499.206.YahooMailNeo@web29804.mail.ird.yahoo.com>
	<1323123990448-5050354.post@n5.nabble.com>
Message-ID: <1323170568.90631.YahooMailNeo@web29813.mail.ird.yahoo.com>
Date: Tue, 6 Dec 2011 11:22:48 +0000 (GMT)
From: David TECHER <davidtecher@yahoo.fr>
To: n4rC0t1C <shandivo@gmail.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
In-Reply-To: <1323123990448-5050354.post@n5.nabble.com>
MIME-Version: 1.0
Subject: [Xen-devel] Re : Re : Re : Re : Re : Re : Re : Re: Patches for
	VGA-Passthrough XEN 4.2 unstable
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: David TECHER <davidtecher@yahoo.fr>
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============5239676851620253628=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============5239676851620253628==
Content-Type: multipart/alternative; boundary="1260217059-1767661483-1323170568=:90631"

--1260217059-1767661483-1323170568=:90631
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

Hi=0A=0AThanks for your mail. It is a real pleasure=0A=0A- to see that it w=
orks for you=0A=0A- to see that you can play your favorite game with such s=
ettings :). I played Crysis 2 using 1920x1080 resolution, DirectX 9=0A=A0bu=
t this is the only game that I tested - single player -. I have to test as =
you did :) for the others games.=0A=0A=0AI' ve got the same CPU as you. Int=
el i5 2500 :) and a GTX 460 SE EVGA=A0 1024.=0A=0A=0AXen should work with a=
 Linux domU too. I've did a few test on Ubuntu Lucid 64 bits.=0AYou have to=
 take care of the good version of Nvidia drivers for GTX 460to work. =0A=0A=
I do not remember=A0 the real version but it is for driver 270.??=0A=0AMy l=
ast patches for Xen Staging (http://xenbits.xensource.com/staging/xen-unsta=
ble.hg) for revision >=3D 24332=0A=0Aare available at http://www.davidgis.f=
r/download/xen-4.2_rev24232_gfx-passthrough-patchs.tar.bz2=0A=0AThanks for =
the tip about audio.=0A=0AThanks for all.=0A=0A=0AKind regards.=0A=0ADavid=
=0A=0A=0A=0A=0A________________________________=0A De=A0: n4rC0t1C <shandiv=
o@gmail.com>=0A=C0=A0: xen-devel@lists.xensource.com =0AEnvoy=E9 le : Lundi=
 5 D=E9cembre 2011 23h26=0AObjet=A0: Re: [Xen-devel] Re : Re : Re : Re : Re=
 : Re : Re: Patches for VGA-Passthrough XEN 4.2 unstable=0A =0AI've been ab=
le to successfully passthrough my nvidia vga card to a windowsxp=0A32 bit d=
omU, using the patches provided by David in this thread. =0APerformances ar=
e AMAZING! I've played entire single player campaing of=0ABattlefield 3 at =
1680x1050@ULTRA settings in domU, with NO visible lags or=0Aartifacts. DomU=
 is really rock solid, not a single crash. Crysis2, Fifa12,=0ANBA2K12 also =
played really well at maximum quality settings and resolutions.=0AAdobe Sui=
te, Flash 11 and CUDA also works as on bare metal systems (eg using=0Agpu t=
o accelerate).=0AI've been able to passthrough an usb controller and the in=
tegreted audio=0Acard too. =0A=0A=0AI can swich between dom0 e domU by chan=
ging the input source of the monitor,=0Aand using synergy to share keyboard=
 and mouse over ssh.=0AAt boot i bind the nvidia card to pciback in grub co=
nf file.=0ALater I use pci-stub to passthrough audio and usb.=0AWhen I shut=
down the domU, i can bind the audio card back to the dom0 in this=0Away:=0A=
=0Aecho "8086 1c20" > remove_id=0Aecho "0000:00:1b.0" > /sys/bus/pci/driver=
s/pci-stub/unbind=0Aalsa force-reload=0A=0A=0A=0AFollows a bit of infos abo=
ut my system config and hardware:=0A=0ACPU: Intel i5-2500=0AMB: Asrock z68 =
EXTREME4 GEN3 (bios 1.10)=0APRIMARY VGA: GIGABYTE GTX460 (GV-N460OC-1GI, re=
v. 1.0). (@dvi on monitor)=0ASECONDARY VGA: integrated intel hd3000, runnin=
g gnome shell 3 in dom0=0A(xorg-edgers ppa) (@DP on monitor).=0A=0A=0AUbunt=
u 11.10-64bit with kernel 3.1.4 from ubuntu developers ppa=0ALinux ibeast 3=
.1.4-030104-generic #201111281851 SMP Mon Nov 28 23:52:23 UTC=0A2011 x86_64=
 x86_64 x86_64 GNU/Linux=0A=0A=0Axl info:=0A=0Ahost=A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0  : ibeast=0Arelease=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 : 3.1.4-0301=
04-generic=0Aversion=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 : #201111281851 SMP Mon=
 Nov 28 23:52:23 UTC 2011=0Amachine=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 : x86_64=
=0Anr_cpus=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 : 4=0Anr_nodes=A0 =A0 =A0 =A0 =A0=
 =A0 =A0  : 1=0Acores_per_socket=A0 =A0 =A0  : 4=0Athreads_per_core=A0 =A0 =
=A0  : 1=0Acpu_mhz=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 : 3300=0Ahw_caps=A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 :=0Abfebfbff:28000800:00000000:00003f40:17bae3ff:00=
000000:00000001:00000000=0Avirt_caps=A0 =A0 =A0 =A0 =A0 =A0 =A0 : hvm hvm_d=
irectio=0Atotal_memory=A0 =A0 =A0 =A0 =A0  : 8100=0Afree_memory=A0 =A0 =A0 =
=A0 =A0 =A0 : 117=0Afree_cpus=A0 =A0 =A0 =A0 =A0 =A0 =A0 : 0=0Axen_major=A0=
 =A0 =A0 =A0 =A0 =A0 =A0 : 4=0Axen_minor=A0 =A0 =A0 =A0 =A0 =A0 =A0 : 2=0Ax=
en_extra=A0 =A0 =A0 =A0 =A0 =A0 =A0 : -unstable=0Axen_caps=A0 =A0 =A0 =A0 =
=A0 =A0 =A0  : xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32=0Ahvm-3.0-x86_=
32p hvm-3.0-x86_64 =0Axen_scheduler=A0 =A0 =A0 =A0 =A0 : credit=0Axen_pages=
ize=A0 =A0 =A0 =A0 =A0  : 4096=0Aplatform_params=A0 =A0 =A0 =A0 : virt_star=
t=3D0xffff800000000000=0Axen_changeset=A0 =A0 =A0 =A0 =A0 : Fri Dec 02 09:0=
5:26 2011 +0100 24341:60d4e257d04b=0Axen_commandline=A0 =A0 =A0 =A0 : place=
holder=0Acc_compiler=A0 =A0 =A0 =A0 =A0 =A0 : gcc version 4.6.1 (Ubuntu/Lin=
aro 4.6.1-9ubuntu3) =0Acc_compile_by=A0 =A0 =A0 =A0 =A0 : ivo=0Acc_compile_=
domain=A0 =A0 =A0 : =0Acc_compile_date=A0 =A0 =A0 =A0 : Fri Dec=A0 2 13:14:=
41 CET 2011=0Axend_config_format=A0 =A0  : 4=0A=0ANo remarkable changes mad=
e to xen default config files.=0A=0A=0AI just want to say thanks to every s=
ingle xen developer out there, and David=0Afor posting patched for nvidia c=
ards. You just made my "life's dream" true.=0ABest Regards, =0AIvo=0A=0A--=
=0AView this message in context: http://xen.1045712.n5.nabble.com/Patches-f=
or-VGA-Passthrough-XEN-4-2-unstable-tp4406265p5050354.html=0ASent from the =
Xen - Dev mailing list archive at Nabble.com.=0A=0A________________________=
_______________________=0AXen-devel mailing list=0AXen-devel@lists.xensourc=
e.com=0Ahttp://lists.xensource.com/xen-devel
--1260217059-1767661483-1323170568=:90631
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

<html><body><div style=3D"color:#000; background-color:#fff; font-family:ti=
mes new roman, new york, times, serif;font-size:12pt"><div><span>Hi</span><=
/div><div><br><span></span></div><div><span>Thanks for your mail. It is a r=
eal pleasure</span></div><div><span><br></span></div><div><span>- to see th=
at it works for you</span></div><div><span><br></span></div><div><span>- to=
 see that you can play your favorite game with such settings :). I played C=
rysis 2 using 1920x1080 resolution, DirectX 9</span></div><div><span>&nbsp;=
but this is the only game that I tested - single player -. I have to test a=
s you did :) for the others games.<br></span></div><div><br><span></span></=
div><div><span>I' ve got the same CPU as you. Intel i5 2500 :) and a GTX 46=
0 SE EVGA&nbsp; 1024.</span></div><div><span><br></span></div><div><br><spa=
n>Xen should work with a Linux domU too. I've did a few test on Ubuntu Luci=
d 64 bits.</span></div><div><span>You have to take care of the good
 version of Nvidia drivers for GTX 460to work. <br></span></div><div><span>=
I do not remember&nbsp; the real version but it is for driver 270.??</span>=
</div><div><br><span></span></div><div><span>My last patches for Xen Stagin=
g (http://xenbits.xensource.com/staging/xen-unstable.hg) for revision &gt;=
=3D 24332<br></span></div><div><span>are available at http://www.davidgis.f=
r/download/xen-4.2_rev24232_gfx-passthrough-patchs.tar.bz2</span></div><div=
><br><span></span></div><div><span>Thanks for the tip about audio.</span></=
div><div><br><span></span></div><div><span>Thanks for all.<br></span></div>=
<div><br><span></span></div><div><span>Kind regards.</span></div><div><br><=
span></span></div><div><span>David</span></div><div><br></div><div><br></di=
v>  <div style=3D"font-family: times new roman, new york, times, serif; fon=
t-size: 12pt;"> <div style=3D"font-family: times new roman, new york, times=
, serif; font-size: 12pt;"> <font face=3D"Arial" size=3D"2"> <hr size=3D"1"=
>=20
 <b><span style=3D"font-weight:bold;">De&nbsp;:</span></b> n4rC0t1C &lt;sha=
ndivo@gmail.com&gt;<br> <b><span style=3D"font-weight: bold;">=C0&nbsp;:</s=
pan></b> xen-devel@lists.xensource.com <br> <b><span style=3D"font-weight: =
bold;">Envoy=E9 le :</span></b> Lundi 5 D=E9cembre 2011 23h26<br> <b><span =
style=3D"font-weight: bold;">Objet&nbsp;:</span></b> Re: [Xen-devel] Re : R=
e : Re : Re : Re : Re : Re: Patches for VGA-Passthrough XEN 4.2 unstable<br=
> </font> <br>I've been able to successfully passthrough my nvidia vga card=
 to a windowsxp<br>32 bit domU, using the patches provided by David in this=
 thread. <br>Performances are AMAZING! I've played entire single player cam=
paing of<br>Battlefield 3 at 1680x1050@ULTRA settings in domU, with NO visi=
ble lags or<br>artifacts. DomU is really rock solid, not a single crash. Cr=
ysis2, Fifa12,<br>NBA2K12 also played really well at maximum quality settin=
gs and resolutions.<br>Adobe Suite, Flash 11 and CUDA also works as on bare
 metal systems (eg using<br>gpu to accelerate).<br>I've been able to passth=
rough an usb controller and the integreted audio<br>card too. <br><br><br>I=
 can swich between dom0 e domU by changing the input source of the monitor,=
<br>and using synergy to share keyboard and mouse over ssh.<br>At boot i bi=
nd the nvidia card to pciback in grub conf file.<br>Later I use pci-stub to=
 passthrough audio and usb.<br>When I shutdown the domU, i can bind the aud=
io card back to the dom0 in this<br>way:<br><br>echo "8086 1c20" &gt; remov=
e_id<br>echo "0000:00:1b.0" &gt; /sys/bus/pci/drivers/pci-stub/unbind<br>al=
sa force-reload<br><br><br><br>Follows a bit of infos about my system confi=
g and hardware:<br><br>CPU: Intel i5-2500<br>MB: Asrock z68 EXTREME4 GEN3 (=
bios 1.10)<br>PRIMARY VGA: GIGABYTE GTX460 (GV-N460OC-1GI, rev. 1.0). (@dvi=
 on monitor)<br>SECONDARY VGA: integrated intel hd3000, running gnome shell=
 3 in dom0<br>(xorg-edgers ppa) (@DP on monitor).<br><br><br>Ubuntu
 11.10-64bit with kernel 3.1.4 from ubuntu developers ppa<br>Linux ibeast 3=
.1.4-030104-generic #201111281851 SMP Mon Nov 28 23:52:23 UTC<br>2011 x86_6=
4 x86_64 x86_64 GNU/Linux<br><br><br>xl info:<br><br>host&nbsp; &nbsp; &nbs=
p; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;  : ibeast<br>release&nbsp; &nb=
sp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; : 3.1.4-030104-generic<br>ver=
sion&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; : #201111281851=
 SMP Mon Nov 28 23:52:23 UTC 2011<br>machine&nbsp; &nbsp; &nbsp; &nbsp; &nb=
sp; &nbsp; &nbsp; &nbsp; : x86_64<br>nr_cpus&nbsp; &nbsp; &nbsp; &nbsp; &nb=
sp; &nbsp; &nbsp; &nbsp; : 4<br>nr_nodes&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; =
&nbsp; &nbsp;  : 1<br>cores_per_socket&nbsp; &nbsp; &nbsp;  : 4<br>threads_=
per_core&nbsp; &nbsp; &nbsp;  : 1<br>cpu_mhz&nbsp; &nbsp; &nbsp; &nbsp; &nb=
sp; &nbsp; &nbsp; &nbsp; : 3300<br>hw_caps&nbsp; &nbsp; &nbsp; &nbsp; &nbsp=
; &nbsp; &nbsp; &nbsp;
 :<br>bfebfbff:28000800:00000000:00003f40:17bae3ff:00000000:00000001:000000=
00<br>virt_caps&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; : hvm hvm_d=
irectio<br>total_memory&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;  : 8100<br>free_m=
emory&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; : 117<br>free_cpus&nbsp; &nb=
sp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; : 0<br>xen_major&nbsp; &nbsp; &nbsp;=
 &nbsp; &nbsp; &nbsp; &nbsp; : 4<br>xen_minor&nbsp; &nbsp; &nbsp; &nbsp; &n=
bsp; &nbsp; &nbsp; : 2<br>xen_extra&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp=
; &nbsp; : -unstable<br>xen_caps&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &=
nbsp;  : xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32<br>hvm-3.0-x86_32p h=
vm-3.0-x86_64 <br>xen_scheduler&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; : credit<=
br>xen_pagesize&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;  : 4096<br>platform_param=
s&nbsp; &nbsp; &nbsp; &nbsp; : virt_start=3D0xffff800000000000<br>xen_chang=
eset&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; : Fri Dec 02 09:05:26 2011
 +0100 24341:60d4e257d04b<br>xen_commandline&nbsp; &nbsp; &nbsp; &nbsp; : p=
laceholder<br>cc_compiler&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; : gcc ve=
rsion 4.6.1 (Ubuntu/Linaro 4.6.1-9ubuntu3) <br>cc_compile_by&nbsp; &nbsp; &=
nbsp; &nbsp; &nbsp; : ivo<br>cc_compile_domain&nbsp; &nbsp; &nbsp; : <br>cc=
_compile_date&nbsp; &nbsp; &nbsp; &nbsp; : Fri Dec&nbsp; 2 13:14:41 CET 201=
1<br>xend_config_format&nbsp; &nbsp;  : 4<br><br>No remarkable changes made=
 to xen default config files.<br><br><br>I just want to say thanks to every=
 single xen developer out there, and David<br>for posting patched for nvidi=
a cards. You just made my "life's dream" true.<br>Best Regards, <br>Ivo<br>=
<br>--<br>View this message in context: <a href=3D"http://xen.1045712.n5.na=
bble.com/Patches-for-VGA-Passthrough-XEN-4-2-unstable-tp4406265p5050354.htm=
l" target=3D"_blank">http://xen.1045712.n5.nabble.com/Patches-for-VGA-Passt=
hrough-XEN-4-2-unstable-tp4406265p5050354.html</a><br>Sent from the Xen
 - Dev mailing list archive at Nabble.com.<br><br>_________________________=
______________________<br>Xen-devel mailing list<br><a ymailto=3D"mailto:Xe=
n-devel@lists.xensource.com" href=3D"mailto:Xen-devel@lists.xensource.com">=
Xen-devel@lists.xensource.com</a><br><a href=3D"http://lists.xensource.com/=
xen-devel" target=3D"_blank">http://lists.xensource.com/xen-devel</a><br><b=
r><br> </div> </div>  </div></body></html>
--1260217059-1767661483-1323170568=:90631--


--===============5239676851620253628==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============5239676851620253628==--


From xen-devel-bounces@lists.xensource.com Tue Dec 06 11:24:01 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 11:24:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXt7Y-0007Tt-TJ; Tue, 06 Dec 2011 11:23:36 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <davidtecher@yahoo.fr>) id 1RXt7X-0007To-NL
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 11:23:36 +0000
X-Env-Sender: davidtecher@yahoo.fr
X-Msg-Ref: server-3.tower-216.messagelabs.com!1323170569!6310523!1
X-Originating-IP: [212.82.108.207]
X-SpamReason: No, hits=1.1 required=7.0 tests=BODY_RANDOM_LONG,
	HTML_40_50, HTML_MESSAGE, ML_RADAR_SPEW_LINKS_12, ML_RADAR_SPEW_LINKS_14,
	ML_RADAR_SPEW_LINKS_6,spamassassin: 
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28820 invoked from network); 6 Dec 2011 11:22:49 -0000
Received: from nm21-vm3.bullet.mail.ird.yahoo.com (HELO
	nm21-vm3.bullet.mail.ird.yahoo.com) (212.82.108.207)
	by server-3.tower-216.messagelabs.com with SMTP;
	6 Dec 2011 11:22:49 -0000
Received: from [77.238.189.57] by nm21.bullet.mail.ird.yahoo.com with NNFMP;
	06 Dec 2011 11:22:49 -0000
Received: from [212.82.108.250] by tm10.bullet.mail.ird.yahoo.com with NNFMP;
	06 Dec 2011 11:22:48 -0000
Received: from [127.0.0.1] by omp1015.mail.ird.yahoo.com with NNFMP;
	06 Dec 2011 11:22:48 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 908756.67870.bm@omp1015.mail.ird.yahoo.com
Received: (qmail 91875 invoked by uid 60001); 6 Dec 2011 11:22:48 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.fr; s=s1024;
	t=1323170568; bh=Jx/Hxn2JR7R/1Ujly8dN0CSCcLaskHb+5AoQkgCj3mQ=;
	h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type;
	b=t/lJfG/SIpFQnTLAF0SBGgJx8s50k+VI32NFR+nRHgNpxOnRnlpVHZ7jnNPBl/YEWqs86q9NbxKOd1unbliHl7xgDPxr567yyuOdssSBSSG2CcGuLkZ33CgqI374uwK2xci8T3OmSbN1KLFAu2QXHJKHruz46vUEsU5Vp1bA+sM=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.fr;
	h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type;
	b=0WqKfGs+HX3Tv8nhotD/CzY1nEO4E4umayfI3JkW4xZnhQ8ZDJ5RGeNL3sIWSxsIU5Yra57KJjRSdC89NsLf/5OyO3uZFo5CgQP7TjSaE+QZwyH7VO1I4mzXlU7KkTRzY5qjEILPhTGG8KGywu5v8h7zWhaHFPlQYN2Rh52tfS8=;
X-YMail-OSG: _US2wskVM1mUoM59Pf8XpZ30nNVBqoUhoTseHnrLo5ZMJx7
	WjQkJJ2MuDB5olTMXrE36u.2qzD77TScBePgEDlgZxT1KT8A8ub65ks3E5l1
	FJosNeJpKtqCME7FGsH3gAK.7CubS3w1CsXcWV9GOxy8xox4cmHE6tRXd1mi
	sg117_sxuwG7jouDlyiUFGY1I7BBiSD.KoBaaHxFD6gQQSiM4pd9sqSYGf3W
	yQqUedwYlU2bo84luPeAuGIfuD0g0ay46H89nKBbc63Ppc.K1IsD9kdBgyao
	7bBh4jO9uaplhVae4ie33.eEKpMr4.ico5RI7Us9DRf4lUpWYXdUHJI2bPa5
	vvMUF4APg6RULcqLKC3h2IrwR27HBjaWmkIZrWWK2v5i6D2SyfsmsXLhLhPJ
	LyKxyuHXwVixnjFWQYsf6q8ZfKo5eqcGFQhfmfs.sX5zAp6nIAuf87g.qYt0
	.nC_IaCBK4kiR5ULnsby5GMV8vgYKO8vHhSSG3bAZh6jVfB6.m0d4QYCm7um
	tYLKz5JeL2HpSCbpx.I3BleO_2T4sGHqsKA3pEIS2cTX15m8CSNq1OFf5Mgs
	25VxtYC0KCSntSCXDklfmXCpzzykE.iLcOh7fFs3GAeWF5YzGVVvJWMnIGQH
	jIJeVORjy7jevlMyRrnNzFQ_YpWElCI1z2d1p6ZrGpcVC4w8Pow8sofkGYij
	D0TEYTMikpL3gWHGdkgd1SxJKbhq88Oe2PHxxu0QmcRI47uv8kPxplNVEfuc
	LfXotF3JUxV_6KmMTU7EH.2g3rPoPX4JFTkCbsExCpmgiZ6_Cx3NEXAwRj_S
	qwj792Vp9JIDcTA7hN.VfeG6Ay.sM9UcO66Di
Received: from [195.167.237.98] by web29813.mail.ird.yahoo.com via HTTP;
	Tue, 06 Dec 2011 11:22:48 GMT
X-Mailer: YahooMailWebService/0.8.115.331698
References: <20110922182705.GE12984@reaktio.net>
	<1316728444821-4831624.post@n5.nabble.com>
	<1316777654598-4833174.post@n5.nabble.com>
	<1316786412428-4833637.post@n5.nabble.com>
	<20110923172115.GI12984@reaktio.net>
	<1318672856439-4904945.post@n5.nabble.com>
	<1319630071722-4939528.post@n5.nabble.com>
	<1319636130.20499.YahooMailNeo@web29808.mail.ird.yahoo.com>
	<1319695116310-4942047.post@n5.nabble.com>
	<1319710499.206.YahooMailNeo@web29804.mail.ird.yahoo.com>
	<1323123990448-5050354.post@n5.nabble.com>
Message-ID: <1323170568.90631.YahooMailNeo@web29813.mail.ird.yahoo.com>
Date: Tue, 6 Dec 2011 11:22:48 +0000 (GMT)
From: David TECHER <davidtecher@yahoo.fr>
To: n4rC0t1C <shandivo@gmail.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
In-Reply-To: <1323123990448-5050354.post@n5.nabble.com>
MIME-Version: 1.0
Subject: [Xen-devel] Re : Re : Re : Re : Re : Re : Re : Re: Patches for
	VGA-Passthrough XEN 4.2 unstable
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: David TECHER <davidtecher@yahoo.fr>
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============5239676851620253628=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============5239676851620253628==
Content-Type: multipart/alternative; boundary="1260217059-1767661483-1323170568=:90631"

--1260217059-1767661483-1323170568=:90631
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

Hi=0A=0AThanks for your mail. It is a real pleasure=0A=0A- to see that it w=
orks for you=0A=0A- to see that you can play your favorite game with such s=
ettings :). I played Crysis 2 using 1920x1080 resolution, DirectX 9=0A=A0bu=
t this is the only game that I tested - single player -. I have to test as =
you did :) for the others games.=0A=0A=0AI' ve got the same CPU as you. Int=
el i5 2500 :) and a GTX 460 SE EVGA=A0 1024.=0A=0A=0AXen should work with a=
 Linux domU too. I've did a few test on Ubuntu Lucid 64 bits.=0AYou have to=
 take care of the good version of Nvidia drivers for GTX 460to work. =0A=0A=
I do not remember=A0 the real version but it is for driver 270.??=0A=0AMy l=
ast patches for Xen Staging (http://xenbits.xensource.com/staging/xen-unsta=
ble.hg) for revision >=3D 24332=0A=0Aare available at http://www.davidgis.f=
r/download/xen-4.2_rev24232_gfx-passthrough-patchs.tar.bz2=0A=0AThanks for =
the tip about audio.=0A=0AThanks for all.=0A=0A=0AKind regards.=0A=0ADavid=
=0A=0A=0A=0A=0A________________________________=0A De=A0: n4rC0t1C <shandiv=
o@gmail.com>=0A=C0=A0: xen-devel@lists.xensource.com =0AEnvoy=E9 le : Lundi=
 5 D=E9cembre 2011 23h26=0AObjet=A0: Re: [Xen-devel] Re : Re : Re : Re : Re=
 : Re : Re: Patches for VGA-Passthrough XEN 4.2 unstable=0A =0AI've been ab=
le to successfully passthrough my nvidia vga card to a windowsxp=0A32 bit d=
omU, using the patches provided by David in this thread. =0APerformances ar=
e AMAZING! I've played entire single player campaing of=0ABattlefield 3 at =
1680x1050@ULTRA settings in domU, with NO visible lags or=0Aartifacts. DomU=
 is really rock solid, not a single crash. Crysis2, Fifa12,=0ANBA2K12 also =
played really well at maximum quality settings and resolutions.=0AAdobe Sui=
te, Flash 11 and CUDA also works as on bare metal systems (eg using=0Agpu t=
o accelerate).=0AI've been able to passthrough an usb controller and the in=
tegreted audio=0Acard too. =0A=0A=0AI can swich between dom0 e domU by chan=
ging the input source of the monitor,=0Aand using synergy to share keyboard=
 and mouse over ssh.=0AAt boot i bind the nvidia card to pciback in grub co=
nf file.=0ALater I use pci-stub to passthrough audio and usb.=0AWhen I shut=
down the domU, i can bind the audio card back to the dom0 in this=0Away:=0A=
=0Aecho "8086 1c20" > remove_id=0Aecho "0000:00:1b.0" > /sys/bus/pci/driver=
s/pci-stub/unbind=0Aalsa force-reload=0A=0A=0A=0AFollows a bit of infos abo=
ut my system config and hardware:=0A=0ACPU: Intel i5-2500=0AMB: Asrock z68 =
EXTREME4 GEN3 (bios 1.10)=0APRIMARY VGA: GIGABYTE GTX460 (GV-N460OC-1GI, re=
v. 1.0). (@dvi on monitor)=0ASECONDARY VGA: integrated intel hd3000, runnin=
g gnome shell 3 in dom0=0A(xorg-edgers ppa) (@DP on monitor).=0A=0A=0AUbunt=
u 11.10-64bit with kernel 3.1.4 from ubuntu developers ppa=0ALinux ibeast 3=
.1.4-030104-generic #201111281851 SMP Mon Nov 28 23:52:23 UTC=0A2011 x86_64=
 x86_64 x86_64 GNU/Linux=0A=0A=0Axl info:=0A=0Ahost=A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0  : ibeast=0Arelease=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 : 3.1.4-0301=
04-generic=0Aversion=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 : #201111281851 SMP Mon=
 Nov 28 23:52:23 UTC 2011=0Amachine=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 : x86_64=
=0Anr_cpus=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 : 4=0Anr_nodes=A0 =A0 =A0 =A0 =A0=
 =A0 =A0  : 1=0Acores_per_socket=A0 =A0 =A0  : 4=0Athreads_per_core=A0 =A0 =
=A0  : 1=0Acpu_mhz=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 : 3300=0Ahw_caps=A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 :=0Abfebfbff:28000800:00000000:00003f40:17bae3ff:00=
000000:00000001:00000000=0Avirt_caps=A0 =A0 =A0 =A0 =A0 =A0 =A0 : hvm hvm_d=
irectio=0Atotal_memory=A0 =A0 =A0 =A0 =A0  : 8100=0Afree_memory=A0 =A0 =A0 =
=A0 =A0 =A0 : 117=0Afree_cpus=A0 =A0 =A0 =A0 =A0 =A0 =A0 : 0=0Axen_major=A0=
 =A0 =A0 =A0 =A0 =A0 =A0 : 4=0Axen_minor=A0 =A0 =A0 =A0 =A0 =A0 =A0 : 2=0Ax=
en_extra=A0 =A0 =A0 =A0 =A0 =A0 =A0 : -unstable=0Axen_caps=A0 =A0 =A0 =A0 =
=A0 =A0 =A0  : xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32=0Ahvm-3.0-x86_=
32p hvm-3.0-x86_64 =0Axen_scheduler=A0 =A0 =A0 =A0 =A0 : credit=0Axen_pages=
ize=A0 =A0 =A0 =A0 =A0  : 4096=0Aplatform_params=A0 =A0 =A0 =A0 : virt_star=
t=3D0xffff800000000000=0Axen_changeset=A0 =A0 =A0 =A0 =A0 : Fri Dec 02 09:0=
5:26 2011 +0100 24341:60d4e257d04b=0Axen_commandline=A0 =A0 =A0 =A0 : place=
holder=0Acc_compiler=A0 =A0 =A0 =A0 =A0 =A0 : gcc version 4.6.1 (Ubuntu/Lin=
aro 4.6.1-9ubuntu3) =0Acc_compile_by=A0 =A0 =A0 =A0 =A0 : ivo=0Acc_compile_=
domain=A0 =A0 =A0 : =0Acc_compile_date=A0 =A0 =A0 =A0 : Fri Dec=A0 2 13:14:=
41 CET 2011=0Axend_config_format=A0 =A0  : 4=0A=0ANo remarkable changes mad=
e to xen default config files.=0A=0A=0AI just want to say thanks to every s=
ingle xen developer out there, and David=0Afor posting patched for nvidia c=
ards. You just made my "life's dream" true.=0ABest Regards, =0AIvo=0A=0A--=
=0AView this message in context: http://xen.1045712.n5.nabble.com/Patches-f=
or-VGA-Passthrough-XEN-4-2-unstable-tp4406265p5050354.html=0ASent from the =
Xen - Dev mailing list archive at Nabble.com.=0A=0A________________________=
_______________________=0AXen-devel mailing list=0AXen-devel@lists.xensourc=
e.com=0Ahttp://lists.xensource.com/xen-devel
--1260217059-1767661483-1323170568=:90631
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

<html><body><div style=3D"color:#000; background-color:#fff; font-family:ti=
mes new roman, new york, times, serif;font-size:12pt"><div><span>Hi</span><=
/div><div><br><span></span></div><div><span>Thanks for your mail. It is a r=
eal pleasure</span></div><div><span><br></span></div><div><span>- to see th=
at it works for you</span></div><div><span><br></span></div><div><span>- to=
 see that you can play your favorite game with such settings :). I played C=
rysis 2 using 1920x1080 resolution, DirectX 9</span></div><div><span>&nbsp;=
but this is the only game that I tested - single player -. I have to test a=
s you did :) for the others games.<br></span></div><div><br><span></span></=
div><div><span>I' ve got the same CPU as you. Intel i5 2500 :) and a GTX 46=
0 SE EVGA&nbsp; 1024.</span></div><div><span><br></span></div><div><br><spa=
n>Xen should work with a Linux domU too. I've did a few test on Ubuntu Luci=
d 64 bits.</span></div><div><span>You have to take care of the good
 version of Nvidia drivers for GTX 460to work. <br></span></div><div><span>=
I do not remember&nbsp; the real version but it is for driver 270.??</span>=
</div><div><br><span></span></div><div><span>My last patches for Xen Stagin=
g (http://xenbits.xensource.com/staging/xen-unstable.hg) for revision &gt;=
=3D 24332<br></span></div><div><span>are available at http://www.davidgis.f=
r/download/xen-4.2_rev24232_gfx-passthrough-patchs.tar.bz2</span></div><div=
><br><span></span></div><div><span>Thanks for the tip about audio.</span></=
div><div><br><span></span></div><div><span>Thanks for all.<br></span></div>=
<div><br><span></span></div><div><span>Kind regards.</span></div><div><br><=
span></span></div><div><span>David</span></div><div><br></div><div><br></di=
v>  <div style=3D"font-family: times new roman, new york, times, serif; fon=
t-size: 12pt;"> <div style=3D"font-family: times new roman, new york, times=
, serif; font-size: 12pt;"> <font face=3D"Arial" size=3D"2"> <hr size=3D"1"=
>=20
 <b><span style=3D"font-weight:bold;">De&nbsp;:</span></b> n4rC0t1C &lt;sha=
ndivo@gmail.com&gt;<br> <b><span style=3D"font-weight: bold;">=C0&nbsp;:</s=
pan></b> xen-devel@lists.xensource.com <br> <b><span style=3D"font-weight: =
bold;">Envoy=E9 le :</span></b> Lundi 5 D=E9cembre 2011 23h26<br> <b><span =
style=3D"font-weight: bold;">Objet&nbsp;:</span></b> Re: [Xen-devel] Re : R=
e : Re : Re : Re : Re : Re: Patches for VGA-Passthrough XEN 4.2 unstable<br=
> </font> <br>I've been able to successfully passthrough my nvidia vga card=
 to a windowsxp<br>32 bit domU, using the patches provided by David in this=
 thread. <br>Performances are AMAZING! I've played entire single player cam=
paing of<br>Battlefield 3 at 1680x1050@ULTRA settings in domU, with NO visi=
ble lags or<br>artifacts. DomU is really rock solid, not a single crash. Cr=
ysis2, Fifa12,<br>NBA2K12 also played really well at maximum quality settin=
gs and resolutions.<br>Adobe Suite, Flash 11 and CUDA also works as on bare
 metal systems (eg using<br>gpu to accelerate).<br>I've been able to passth=
rough an usb controller and the integreted audio<br>card too. <br><br><br>I=
 can swich between dom0 e domU by changing the input source of the monitor,=
<br>and using synergy to share keyboard and mouse over ssh.<br>At boot i bi=
nd the nvidia card to pciback in grub conf file.<br>Later I use pci-stub to=
 passthrough audio and usb.<br>When I shutdown the domU, i can bind the aud=
io card back to the dom0 in this<br>way:<br><br>echo "8086 1c20" &gt; remov=
e_id<br>echo "0000:00:1b.0" &gt; /sys/bus/pci/drivers/pci-stub/unbind<br>al=
sa force-reload<br><br><br><br>Follows a bit of infos about my system confi=
g and hardware:<br><br>CPU: Intel i5-2500<br>MB: Asrock z68 EXTREME4 GEN3 (=
bios 1.10)<br>PRIMARY VGA: GIGABYTE GTX460 (GV-N460OC-1GI, rev. 1.0). (@dvi=
 on monitor)<br>SECONDARY VGA: integrated intel hd3000, running gnome shell=
 3 in dom0<br>(xorg-edgers ppa) (@DP on monitor).<br><br><br>Ubuntu
 11.10-64bit with kernel 3.1.4 from ubuntu developers ppa<br>Linux ibeast 3=
.1.4-030104-generic #201111281851 SMP Mon Nov 28 23:52:23 UTC<br>2011 x86_6=
4 x86_64 x86_64 GNU/Linux<br><br><br>xl info:<br><br>host&nbsp; &nbsp; &nbs=
p; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;  : ibeast<br>release&nbsp; &nb=
sp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; : 3.1.4-030104-generic<br>ver=
sion&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; : #201111281851=
 SMP Mon Nov 28 23:52:23 UTC 2011<br>machine&nbsp; &nbsp; &nbsp; &nbsp; &nb=
sp; &nbsp; &nbsp; &nbsp; : x86_64<br>nr_cpus&nbsp; &nbsp; &nbsp; &nbsp; &nb=
sp; &nbsp; &nbsp; &nbsp; : 4<br>nr_nodes&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; =
&nbsp; &nbsp;  : 1<br>cores_per_socket&nbsp; &nbsp; &nbsp;  : 4<br>threads_=
per_core&nbsp; &nbsp; &nbsp;  : 1<br>cpu_mhz&nbsp; &nbsp; &nbsp; &nbsp; &nb=
sp; &nbsp; &nbsp; &nbsp; : 3300<br>hw_caps&nbsp; &nbsp; &nbsp; &nbsp; &nbsp=
; &nbsp; &nbsp; &nbsp;
 :<br>bfebfbff:28000800:00000000:00003f40:17bae3ff:00000000:00000001:000000=
00<br>virt_caps&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; : hvm hvm_d=
irectio<br>total_memory&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;  : 8100<br>free_m=
emory&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; : 117<br>free_cpus&nbsp; &nb=
sp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; : 0<br>xen_major&nbsp; &nbsp; &nbsp;=
 &nbsp; &nbsp; &nbsp; &nbsp; : 4<br>xen_minor&nbsp; &nbsp; &nbsp; &nbsp; &n=
bsp; &nbsp; &nbsp; : 2<br>xen_extra&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp=
; &nbsp; : -unstable<br>xen_caps&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &=
nbsp;  : xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32<br>hvm-3.0-x86_32p h=
vm-3.0-x86_64 <br>xen_scheduler&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; : credit<=
br>xen_pagesize&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;  : 4096<br>platform_param=
s&nbsp; &nbsp; &nbsp; &nbsp; : virt_start=3D0xffff800000000000<br>xen_chang=
eset&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; : Fri Dec 02 09:05:26 2011
 +0100 24341:60d4e257d04b<br>xen_commandline&nbsp; &nbsp; &nbsp; &nbsp; : p=
laceholder<br>cc_compiler&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; : gcc ve=
rsion 4.6.1 (Ubuntu/Linaro 4.6.1-9ubuntu3) <br>cc_compile_by&nbsp; &nbsp; &=
nbsp; &nbsp; &nbsp; : ivo<br>cc_compile_domain&nbsp; &nbsp; &nbsp; : <br>cc=
_compile_date&nbsp; &nbsp; &nbsp; &nbsp; : Fri Dec&nbsp; 2 13:14:41 CET 201=
1<br>xend_config_format&nbsp; &nbsp;  : 4<br><br>No remarkable changes made=
 to xen default config files.<br><br><br>I just want to say thanks to every=
 single xen developer out there, and David<br>for posting patched for nvidi=
a cards. You just made my "life's dream" true.<br>Best Regards, <br>Ivo<br>=
<br>--<br>View this message in context: <a href=3D"http://xen.1045712.n5.na=
bble.com/Patches-for-VGA-Passthrough-XEN-4-2-unstable-tp4406265p5050354.htm=
l" target=3D"_blank">http://xen.1045712.n5.nabble.com/Patches-for-VGA-Passt=
hrough-XEN-4-2-unstable-tp4406265p5050354.html</a><br>Sent from the Xen
 - Dev mailing list archive at Nabble.com.<br><br>_________________________=
______________________<br>Xen-devel mailing list<br><a ymailto=3D"mailto:Xe=
n-devel@lists.xensource.com" href=3D"mailto:Xen-devel@lists.xensource.com">=
Xen-devel@lists.xensource.com</a><br><a href=3D"http://lists.xensource.com/=
xen-devel" target=3D"_blank">http://lists.xensource.com/xen-devel</a><br><b=
r><br> </div> </div>  </div></body></html>
--1260217059-1767661483-1323170568=:90631--


--===============5239676851620253628==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============5239676851620253628==--


From xen-devel-bounces@lists.xensource.com Tue Dec 06 11:43:23 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 11:43:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXtQF-0007lL-1L; Tue, 06 Dec 2011 11:42:55 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RXtQD-0007lG-HQ
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 11:42:53 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1323171727!6963917!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjM3Ng==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31158 invoked from network); 6 Dec 2011 11:42:07 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Dec 2011 11:42:07 -0000
X-IronPort-AV: E=Sophos;i="4.71,304,1320624000"; 
   d="scan'208";a="9313514"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Dec 2011 11:42:06 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Tue, 6 Dec 2011
	11:42:06 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "annie.li@oracle.com" <annie.li@oracle.com>
Date: Tue, 6 Dec 2011 11:42:06 +0000
In-Reply-To: <1323168999-4434-1-git-send-email-annie.li@oracle.com>
References: <4EDDF41E.8070200@oracle.com>
	<1323168999-4434-1-git-send-email-annie.li@oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323171726.23681.65.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "jeremy@goop.org" <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	"kurt.hackel@oracle.com" <kurt.hackel@oracle.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Paul Durrant <Paul.Durrant@citrix.com>
Subject: Re: [Xen-devel] [PATCH 1/2] xen/granttable: Support sub-page grants
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2011-12-06 at 10:56 +0000, annie.li@oracle.com wrote:
> From: Annie Li <annie.li@oracle.com>
> 
>     -- They can't be used to map the page (so can only be used in a GNTTABOP_copy
>        hypercall).
>     -- It's possible to grant access with a finer granularity than whole pages.
>     -- Xen guarantees that they can be revoked quickly (a normal map grant can
>        only be revoked with the cooperation of the domain which has been granted
>        access).
> 

Almost all my comments will apply to the transitive grants patch too.

> Signed-off-by: Annie Li <annie.li@oracle.com>
> ---
>  drivers/xen/grant-table.c |   41 +++++++++++++++++++++++++++++++++++++++++
>  include/xen/grant_table.h |   13 +++++++++++++
>  2 files changed, 54 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
> index bd325fd..7a0f4d1 100644
> --- a/drivers/xen/grant-table.c
> +++ b/drivers/xen/grant-table.c
> @@ -261,6 +261,47 @@ int gnttab_grant_foreign_access(domid_t domid, unsigned long frame,
>  }
>  EXPORT_SYMBOL_GPL(gnttab_grant_foreign_access);
>  
> +int gnttab_grant_foreign_access_subpage_v2(domid_t domid, unsigned long frame,
> +					   int flags, unsigned page_off,
> +					   unsigned length)

Please drop the v2 suffixes on the public functions.

Any reason not to route these via the ops table for consistency with all
the other ops? Then your availability check becomes a test for NULL fn
pointer rather than a specific version.

> +{
> +	int ref;
> +
> +	ref = get_free_entries(1);
> +	if (unlikely(ref < 0))
> +		return -ENOSPC;
> +
> +	gnttab_grant_foreign_access_ref_subpage_v2(ref, domid, frame, flags,
> +						   page_off, length);
> +
> +	return ref;
> +}
> +EXPORT_SYMBOL_GPL(gnttab_grant_foreign_access_subpage_v2);
> +
> +void gnttab_grant_foreign_access_ref_subpage_v2(grant_ref_t ref, domid_t domid,
> +						unsigned long frame, int flags,
> +						unsigned page_off,
> +						unsigned length)
> +{
> +	BUG_ON(flags & (GTF_accept_transfer | GTF_reading |
> +			GTF_writing | GTF_transitive));
> +	BUG_ON(grant_table_version == 1);

Returning -Esomething might be less drastic? ENOSYS perhaps?

> +	gnttab_shared.v2[ref].sub_page.frame = frame;
> +	gnttab_shared.v2[ref].sub_page.page_off = page_off;
> +	gnttab_shared.v2[ref].sub_page.length = length;
> +	gnttab_shared.v2[ref].hdr.domid = domid;
> +	wmb();
> +	gnttab_shared.v2[ref].hdr.flags =
> +				GTF_permit_access | GTF_sub_page | flags;
> +}
> +EXPORT_SYMBOL_GPL(gnttab_grant_foreign_access_ref_subpage_v2);
> +
> +bool gnttab_subpage_trans_grants_available(void)
> +{
> +	return grant_table_version == 2;
> +}

It's not clear this adds anything over and above letting the user query
the grant table version. It's hard to tell since there are no users
presented here though. Perhaps separate subpage and transitive functions
would be cleaner?

> +EXPORT_SYMBOL_GPL(gnttab_subpage_trans_grants_available);
> +
>  static int gnttab_query_foreign_access_v1(grant_ref_t ref)
>  {
>  	return gnttab_shared.v1[ref].flags & (GTF_reading|GTF_writing);
> diff --git a/include/xen/grant_table.h b/include/xen/grant_table.h
> index fea4954..7e43652 100644
> --- a/include/xen/grant_table.h
> +++ b/include/xen/grant_table.h
> @@ -62,6 +62,15 @@ int gnttab_resume(void);
>  
>  int gnttab_grant_foreign_access(domid_t domid, unsigned long frame,
>  				int readonly);
> +int gnttab_grant_foreign_access_subpage_v2(domid_t domid, unsigned long frame,
> +					   int flags, unsigned page_off,
> +					   unsigned length);

> +
> +/*
> + * Are sub-page or transitive grants available on this version of Xen?  Returns
> + * true if they are, and false if they're not.
> + */
> +bool gnttab_subpage_trans_grants_available(void);
>  
>  /*
>   * End access through the given grant reference, iff the grant entry is no
> @@ -108,6 +117,10 @@ void gnttab_cancel_free_callback(struct gnttab_free_callback *callback);
>  
>  void gnttab_grant_foreign_access_ref(grant_ref_t ref, domid_t domid,
>  				     unsigned long frame, int readonly);
> +void gnttab_grant_foreign_access_ref_subpage_v2(grant_ref_t ref, domid_t domid,
> +						unsigned long frame, int flags,
> +						unsigned page_off,
> +						unsigned length);
>  
>  void gnttab_grant_foreign_transfer_ref(grant_ref_t, domid_t domid,
>  				       unsigned long pfn);



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 11:43:23 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 11:43:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXtQF-0007lL-1L; Tue, 06 Dec 2011 11:42:55 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RXtQD-0007lG-HQ
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 11:42:53 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1323171727!6963917!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjM3Ng==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31158 invoked from network); 6 Dec 2011 11:42:07 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Dec 2011 11:42:07 -0000
X-IronPort-AV: E=Sophos;i="4.71,304,1320624000"; 
   d="scan'208";a="9313514"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Dec 2011 11:42:06 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Tue, 6 Dec 2011
	11:42:06 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "annie.li@oracle.com" <annie.li@oracle.com>
Date: Tue, 6 Dec 2011 11:42:06 +0000
In-Reply-To: <1323168999-4434-1-git-send-email-annie.li@oracle.com>
References: <4EDDF41E.8070200@oracle.com>
	<1323168999-4434-1-git-send-email-annie.li@oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323171726.23681.65.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "jeremy@goop.org" <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	"kurt.hackel@oracle.com" <kurt.hackel@oracle.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Paul Durrant <Paul.Durrant@citrix.com>
Subject: Re: [Xen-devel] [PATCH 1/2] xen/granttable: Support sub-page grants
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2011-12-06 at 10:56 +0000, annie.li@oracle.com wrote:
> From: Annie Li <annie.li@oracle.com>
> 
>     -- They can't be used to map the page (so can only be used in a GNTTABOP_copy
>        hypercall).
>     -- It's possible to grant access with a finer granularity than whole pages.
>     -- Xen guarantees that they can be revoked quickly (a normal map grant can
>        only be revoked with the cooperation of the domain which has been granted
>        access).
> 

Almost all my comments will apply to the transitive grants patch too.

> Signed-off-by: Annie Li <annie.li@oracle.com>
> ---
>  drivers/xen/grant-table.c |   41 +++++++++++++++++++++++++++++++++++++++++
>  include/xen/grant_table.h |   13 +++++++++++++
>  2 files changed, 54 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
> index bd325fd..7a0f4d1 100644
> --- a/drivers/xen/grant-table.c
> +++ b/drivers/xen/grant-table.c
> @@ -261,6 +261,47 @@ int gnttab_grant_foreign_access(domid_t domid, unsigned long frame,
>  }
>  EXPORT_SYMBOL_GPL(gnttab_grant_foreign_access);
>  
> +int gnttab_grant_foreign_access_subpage_v2(domid_t domid, unsigned long frame,
> +					   int flags, unsigned page_off,
> +					   unsigned length)

Please drop the v2 suffixes on the public functions.

Any reason not to route these via the ops table for consistency with all
the other ops? Then your availability check becomes a test for NULL fn
pointer rather than a specific version.

> +{
> +	int ref;
> +
> +	ref = get_free_entries(1);
> +	if (unlikely(ref < 0))
> +		return -ENOSPC;
> +
> +	gnttab_grant_foreign_access_ref_subpage_v2(ref, domid, frame, flags,
> +						   page_off, length);
> +
> +	return ref;
> +}
> +EXPORT_SYMBOL_GPL(gnttab_grant_foreign_access_subpage_v2);
> +
> +void gnttab_grant_foreign_access_ref_subpage_v2(grant_ref_t ref, domid_t domid,
> +						unsigned long frame, int flags,
> +						unsigned page_off,
> +						unsigned length)
> +{
> +	BUG_ON(flags & (GTF_accept_transfer | GTF_reading |
> +			GTF_writing | GTF_transitive));
> +	BUG_ON(grant_table_version == 1);

Returning -Esomething might be less drastic? ENOSYS perhaps?

> +	gnttab_shared.v2[ref].sub_page.frame = frame;
> +	gnttab_shared.v2[ref].sub_page.page_off = page_off;
> +	gnttab_shared.v2[ref].sub_page.length = length;
> +	gnttab_shared.v2[ref].hdr.domid = domid;
> +	wmb();
> +	gnttab_shared.v2[ref].hdr.flags =
> +				GTF_permit_access | GTF_sub_page | flags;
> +}
> +EXPORT_SYMBOL_GPL(gnttab_grant_foreign_access_ref_subpage_v2);
> +
> +bool gnttab_subpage_trans_grants_available(void)
> +{
> +	return grant_table_version == 2;
> +}

It's not clear this adds anything over and above letting the user query
the grant table version. It's hard to tell since there are no users
presented here though. Perhaps separate subpage and transitive functions
would be cleaner?

> +EXPORT_SYMBOL_GPL(gnttab_subpage_trans_grants_available);
> +
>  static int gnttab_query_foreign_access_v1(grant_ref_t ref)
>  {
>  	return gnttab_shared.v1[ref].flags & (GTF_reading|GTF_writing);
> diff --git a/include/xen/grant_table.h b/include/xen/grant_table.h
> index fea4954..7e43652 100644
> --- a/include/xen/grant_table.h
> +++ b/include/xen/grant_table.h
> @@ -62,6 +62,15 @@ int gnttab_resume(void);
>  
>  int gnttab_grant_foreign_access(domid_t domid, unsigned long frame,
>  				int readonly);
> +int gnttab_grant_foreign_access_subpage_v2(domid_t domid, unsigned long frame,
> +					   int flags, unsigned page_off,
> +					   unsigned length);

> +
> +/*
> + * Are sub-page or transitive grants available on this version of Xen?  Returns
> + * true if they are, and false if they're not.
> + */
> +bool gnttab_subpage_trans_grants_available(void);
>  
>  /*
>   * End access through the given grant reference, iff the grant entry is no
> @@ -108,6 +117,10 @@ void gnttab_cancel_free_callback(struct gnttab_free_callback *callback);
>  
>  void gnttab_grant_foreign_access_ref(grant_ref_t ref, domid_t domid,
>  				     unsigned long frame, int readonly);
> +void gnttab_grant_foreign_access_ref_subpage_v2(grant_ref_t ref, domid_t domid,
> +						unsigned long frame, int flags,
> +						unsigned page_off,
> +						unsigned length);
>  
>  void gnttab_grant_foreign_transfer_ref(grant_ref_t, domid_t domid,
>  				       unsigned long pfn);



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 12:06:26 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 12:06:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXtmD-0008BK-Qn; Tue, 06 Dec 2011 12:05:37 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1RXtmB-0008BB-PY
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 12:05:36 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1323173088!6375242!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDcxMjI=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24585 invoked from network); 6 Dec 2011 12:04:50 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Dec 2011 12:04:50 -0000
X-IronPort-AV: E=Sophos;i="4.71,304,1320642000"; d="scan'208";a="19702611"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Dec 2011 07:04:48 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Tue, 6 Dec 2011 07:04:48 -0500
Received: from testbox64.uk.xensource.com ([10.80.237.153])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pB6C4k4X017714;
	Tue, 6 Dec 2011 04:04:47 -0800
From: Wei Liu <wei.liu2@citrix.com>
To: xen-devel@lists.xensource.com, netdev@vger.kernel.org
Date: Tue, 6 Dec 2011 12:04:50 +0000
Message-ID: <1323173090-7867-1-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com
Subject: [Xen-devel] [PATCH] netback: fix typo in comment
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

"variables a used" should be "variables are used".

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 drivers/net/xen-netback/netback.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
index 3ecb5aa..639cf8a 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -395,7 +395,7 @@ static void netbk_gop_frag_copy(struct xenvif *vif, struct sk_buff *skb,
 	struct gnttab_copy *copy_gop;
 	struct netbk_rx_meta *meta;
 	/*
-	 * These variables a used iff get_page_ext returns true,
+	 * These variables are used iff get_page_ext returns true,
 	 * in which case they are guaranteed to be initialized.
 	 */
 	unsigned int uninitialized_var(group), uninitialized_var(idx);
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 12:06:26 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 12:06:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXtmD-0008BK-Qn; Tue, 06 Dec 2011 12:05:37 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1RXtmB-0008BB-PY
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 12:05:36 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1323173088!6375242!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDcxMjI=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24585 invoked from network); 6 Dec 2011 12:04:50 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Dec 2011 12:04:50 -0000
X-IronPort-AV: E=Sophos;i="4.71,304,1320642000"; d="scan'208";a="19702611"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Dec 2011 07:04:48 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Tue, 6 Dec 2011 07:04:48 -0500
Received: from testbox64.uk.xensource.com ([10.80.237.153])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pB6C4k4X017714;
	Tue, 6 Dec 2011 04:04:47 -0800
From: Wei Liu <wei.liu2@citrix.com>
To: xen-devel@lists.xensource.com, netdev@vger.kernel.org
Date: Tue, 6 Dec 2011 12:04:50 +0000
Message-ID: <1323173090-7867-1-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com
Subject: [Xen-devel] [PATCH] netback: fix typo in comment
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

"variables a used" should be "variables are used".

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 drivers/net/xen-netback/netback.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
index 3ecb5aa..639cf8a 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -395,7 +395,7 @@ static void netbk_gop_frag_copy(struct xenvif *vif, struct sk_buff *skb,
 	struct gnttab_copy *copy_gop;
 	struct netbk_rx_meta *meta;
 	/*
-	 * These variables a used iff get_page_ext returns true,
+	 * These variables are used iff get_page_ext returns true,
 	 * in which case they are guaranteed to be initialized.
 	 */
 	unsigned int uninitialized_var(group), uninitialized_var(idx);
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 12:06:27 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 12:06:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXtmK-0008Ba-76; Tue, 06 Dec 2011 12:05:44 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <shandivo@gmail.com>) id 1RXtmJ-0008BJ-7k
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 12:05:43 +0000
X-Env-Sender: shandivo@gmail.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1323173095!842179!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21996 invoked from network); 6 Dec 2011 12:04:56 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-5.tower-21.messagelabs.com with AES256-SHA encrypted SMTP;
	6 Dec 2011 12:04:56 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <shandivo@gmail.com>) id 1RXtlW-0007iV-EE
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 04:04:54 -0800
Date: Tue, 6 Dec 2011 04:04:54 -0800 (PST)
From: n4rC0t1C <shandivo@gmail.com>
To: xen-devel@lists.xensource.com
Message-ID: <1323173094434-5051880.post@n5.nabble.com>
In-Reply-To: <1323170568.90631.YahooMailNeo@web29813.mail.ird.yahoo.com>
References: <1316777654598-4833174.post@n5.nabble.com>
	<1316786412428-4833637.post@n5.nabble.com>
	<20110923172115.GI12984@reaktio.net>
	<1318672856439-4904945.post@n5.nabble.com>
	<1319630071722-4939528.post@n5.nabble.com>
	<1319636130.20499.YahooMailNeo@web29808.mail.ird.yahoo.com>
	<1319695116310-4942047.post@n5.nabble.com>
	<1319710499.206.YahooMailNeo@web29804.mail.ird.yahoo.com>
	<1323123990448-5050354.post@n5.nabble.com>
	<1323170568.90631.YahooMailNeo@web29813.mail.ird.yahoo.com>
MIME-Version: 1.0
Subject: Re: [Xen-devel] Re : Re : Re : Re : Re : Re : Re : Re: Patches for
 VGA-Passthrough XEN 4.2 unstable
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Iep I used your last patches, (your website it's at the top of my bookmarks),
and they apply to xen-unstable rev. 24341 as well (which i'm using). 

I forgot to mention that I had to make a couple of fix to xen tree, cause it
wasn't compiling on my system due to  "error: format not a string literal
and no format arguments":


--- /usr/src/xen-unstable.hg-rev-24341-460gtx/tools/libxl/libxl_create.c
+++ /usr/src/xen-unstable.hg-rev-24341-460gtx/tools/libxl/libxl_create.c
@@ -462,7 +462,7 @@
     path = libxl__xs_libxl_path(gc, domid);
     path = libxl__sprintf(gc, "%s/dm-version", path);
     return libxl__xs_write(gc, XBT_NULL, path, libxl__strdup(gc,
-       
libxl_device_model_version_to_string(dm_info->device_model_version)));
+       
libxl_device_model_version_to_string(dm_info->device_model_version)),"%s");
 }
 
 static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,


--- /usr/src/xen-unstable.hg-rev-24341-460gtx/tools/libxl/libxl_device.c
+++ /usr/src/xen-unstable.hg-rev-24341-460gtx/tools/libxl/libxl_device.c
@@ -516,7 +516,7 @@
         for (j = 0; j < num_devs; j++) {
             path = libxl__sprintf(gc,
"/local/domain/%d/device/%s/%s/backend",
                                   domid, kinds[i], devs[j]);
-            path = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, path));
+            path = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc,
path,"%s"));
             if (path && libxl__parse_backend_path(gc, path, &dev) == 0) {
                 dev.domid = domid;
                 dev.kind = kind;

and an due to an argument missing:

--- /usr/src/xen-unstable.hg-rev-24341-460gtx/tools/libxl/libxl_dom.c
+++ /usr/src/xen-unstable.hg-rev-24341-460gtx/tools/libxl/libxl_dom.c
@@ -625,7 +625,7 @@
         break;
     }
     case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
-        fd2 = open(filename, O_WRONLY | O_CREAT | O_TRUNC);
+        fd2 = open(filename, O_WRONLY | O_CREAT | O_TRUNC, 0644);
         if (fd2 < 0) {
             LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
                              "Unable to create a QEMU save file\n");

As far as I know those doesn't break anything, but dont take too seriously,
i'm not an experienced developer :)


Forgot 2:
Since I'm using an ubuntu kernel, the xen support is not integrated, but you
need to add xen modules at your inittrd file. I did this by adding those:

xen-pciback passthrough=1
xen-blkback
xenfs
xen-netback
pci-stub

to /etc/xen/initramfs-tools/modules and the issuing update-initramfs. 

In the future, I'll try to boot a linux domU, right now I'm still smiling
cause I can fully wipe my Windows installation from the hard disk. And I'm
sure that in future Win7 will be supported too.

Thanks again David and everyone,
Ivo

--
View this message in context: http://xen.1045712.n5.nabble.com/Patches-for-VGA-Passthrough-XEN-4-2-unstable-tp4406265p5051880.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 12:06:27 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 12:06:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXtmK-0008Ba-76; Tue, 06 Dec 2011 12:05:44 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <shandivo@gmail.com>) id 1RXtmJ-0008BJ-7k
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 12:05:43 +0000
X-Env-Sender: shandivo@gmail.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1323173095!842179!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21996 invoked from network); 6 Dec 2011 12:04:56 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-5.tower-21.messagelabs.com with AES256-SHA encrypted SMTP;
	6 Dec 2011 12:04:56 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <shandivo@gmail.com>) id 1RXtlW-0007iV-EE
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 04:04:54 -0800
Date: Tue, 6 Dec 2011 04:04:54 -0800 (PST)
From: n4rC0t1C <shandivo@gmail.com>
To: xen-devel@lists.xensource.com
Message-ID: <1323173094434-5051880.post@n5.nabble.com>
In-Reply-To: <1323170568.90631.YahooMailNeo@web29813.mail.ird.yahoo.com>
References: <1316777654598-4833174.post@n5.nabble.com>
	<1316786412428-4833637.post@n5.nabble.com>
	<20110923172115.GI12984@reaktio.net>
	<1318672856439-4904945.post@n5.nabble.com>
	<1319630071722-4939528.post@n5.nabble.com>
	<1319636130.20499.YahooMailNeo@web29808.mail.ird.yahoo.com>
	<1319695116310-4942047.post@n5.nabble.com>
	<1319710499.206.YahooMailNeo@web29804.mail.ird.yahoo.com>
	<1323123990448-5050354.post@n5.nabble.com>
	<1323170568.90631.YahooMailNeo@web29813.mail.ird.yahoo.com>
MIME-Version: 1.0
Subject: Re: [Xen-devel] Re : Re : Re : Re : Re : Re : Re : Re: Patches for
 VGA-Passthrough XEN 4.2 unstable
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Iep I used your last patches, (your website it's at the top of my bookmarks),
and they apply to xen-unstable rev. 24341 as well (which i'm using). 

I forgot to mention that I had to make a couple of fix to xen tree, cause it
wasn't compiling on my system due to  "error: format not a string literal
and no format arguments":


--- /usr/src/xen-unstable.hg-rev-24341-460gtx/tools/libxl/libxl_create.c
+++ /usr/src/xen-unstable.hg-rev-24341-460gtx/tools/libxl/libxl_create.c
@@ -462,7 +462,7 @@
     path = libxl__xs_libxl_path(gc, domid);
     path = libxl__sprintf(gc, "%s/dm-version", path);
     return libxl__xs_write(gc, XBT_NULL, path, libxl__strdup(gc,
-       
libxl_device_model_version_to_string(dm_info->device_model_version)));
+       
libxl_device_model_version_to_string(dm_info->device_model_version)),"%s");
 }
 
 static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,


--- /usr/src/xen-unstable.hg-rev-24341-460gtx/tools/libxl/libxl_device.c
+++ /usr/src/xen-unstable.hg-rev-24341-460gtx/tools/libxl/libxl_device.c
@@ -516,7 +516,7 @@
         for (j = 0; j < num_devs; j++) {
             path = libxl__sprintf(gc,
"/local/domain/%d/device/%s/%s/backend",
                                   domid, kinds[i], devs[j]);
-            path = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, path));
+            path = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc,
path,"%s"));
             if (path && libxl__parse_backend_path(gc, path, &dev) == 0) {
                 dev.domid = domid;
                 dev.kind = kind;

and an due to an argument missing:

--- /usr/src/xen-unstable.hg-rev-24341-460gtx/tools/libxl/libxl_dom.c
+++ /usr/src/xen-unstable.hg-rev-24341-460gtx/tools/libxl/libxl_dom.c
@@ -625,7 +625,7 @@
         break;
     }
     case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
-        fd2 = open(filename, O_WRONLY | O_CREAT | O_TRUNC);
+        fd2 = open(filename, O_WRONLY | O_CREAT | O_TRUNC, 0644);
         if (fd2 < 0) {
             LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
                              "Unable to create a QEMU save file\n");

As far as I know those doesn't break anything, but dont take too seriously,
i'm not an experienced developer :)


Forgot 2:
Since I'm using an ubuntu kernel, the xen support is not integrated, but you
need to add xen modules at your inittrd file. I did this by adding those:

xen-pciback passthrough=1
xen-blkback
xenfs
xen-netback
pci-stub

to /etc/xen/initramfs-tools/modules and the issuing update-initramfs. 

In the future, I'll try to boot a linux domU, right now I'm still smiling
cause I can fully wipe my Windows installation from the hard disk. And I'm
sure that in future Win7 will be supported too.

Thanks again David and everyone,
Ivo

--
View this message in context: http://xen.1045712.n5.nabble.com/Patches-for-VGA-Passthrough-XEN-4-2-unstable-tp4406265p5051880.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 12:24:41 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 12:24:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXu4A-0008W0-0h; Tue, 06 Dec 2011 12:24:10 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RXu48-0008Vt-NY
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 12:24:09 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-9.tower-182.messagelabs.com!1323174202!6073962!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMjA5MTI=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMjA5MTI=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2954 invoked from network); 6 Dec 2011 12:23:23 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-9.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Dec 2011 12:23:23 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1323174202; l=544;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=hvHfTdljpP5KGkKK6KhOlYPJfVo=;
	b=O0GSwLf2Ee9RTYB4O3DSBn6tmZsVjqDjhPni4lAG2TCe/14QQTt5Ebo7mm6E7NM9kzr
	WD/pL843yCB7XsU/My1qa5F+OJtsGspHFwuFyZV8AfXfjsNWVNokudwTVvQExRt+u4Cnm
	tMxfsnmny85cFLBy8wyWnCoCsLWSfAYocPw=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lq387qFz2T
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-076-151.pools.arcor-ip.net [84.57.76.151])
	by smtp.strato.de (cohen mo39) (RZmta 26.10 AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id q0520anB6BkgRh ;
	Tue, 6 Dec 2011 13:23:16 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id B2F1918637; Tue,  6 Dec 2011 13:23:15 +0100 (CET)
Date: Tue, 6 Dec 2011 13:23:15 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20111206122315.GA5614@aepfle.de>
References: <patchbomb.1323097919@xdev.gridcentric.ca>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <patchbomb.1323097919@xdev.gridcentric.ca>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com, tim@xen.org,
	keir.xen@gmail.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 0 of 5] Mem event interface improvements
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Dec 05, Andres Lagar-Cavilla wrote:

> In this patch series we add a series of improevements to the memory
> event interface. Namely:
> - Allow batched consumption of multiple outstanding responses
> - Signal Xen to consume responses solely with an event channel kick
> - Extra flag to tag events generated byforeign-domains
> - Allow placing dummy domains in the ring, to keep it in sync if
>  a state transition does not require an explicit response.

Assuming that these patches have been tested, I'm ok with them.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 12:24:41 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 12:24:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXu4A-0008W0-0h; Tue, 06 Dec 2011 12:24:10 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RXu48-0008Vt-NY
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 12:24:09 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-9.tower-182.messagelabs.com!1323174202!6073962!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMjA5MTI=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMjA5MTI=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2954 invoked from network); 6 Dec 2011 12:23:23 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-9.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Dec 2011 12:23:23 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1323174202; l=544;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=hvHfTdljpP5KGkKK6KhOlYPJfVo=;
	b=O0GSwLf2Ee9RTYB4O3DSBn6tmZsVjqDjhPni4lAG2TCe/14QQTt5Ebo7mm6E7NM9kzr
	WD/pL843yCB7XsU/My1qa5F+OJtsGspHFwuFyZV8AfXfjsNWVNokudwTVvQExRt+u4Cnm
	tMxfsnmny85cFLBy8wyWnCoCsLWSfAYocPw=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lq387qFz2T
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-076-151.pools.arcor-ip.net [84.57.76.151])
	by smtp.strato.de (cohen mo39) (RZmta 26.10 AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id q0520anB6BkgRh ;
	Tue, 6 Dec 2011 13:23:16 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id B2F1918637; Tue,  6 Dec 2011 13:23:15 +0100 (CET)
Date: Tue, 6 Dec 2011 13:23:15 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20111206122315.GA5614@aepfle.de>
References: <patchbomb.1323097919@xdev.gridcentric.ca>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <patchbomb.1323097919@xdev.gridcentric.ca>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com, tim@xen.org,
	keir.xen@gmail.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 0 of 5] Mem event interface improvements
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Dec 05, Andres Lagar-Cavilla wrote:

> In this patch series we add a series of improevements to the memory
> event interface. Namely:
> - Allow batched consumption of multiple outstanding responses
> - Signal Xen to consume responses solely with an event channel kick
> - Extra flag to tag events generated byforeign-domains
> - Allow placing dummy domains in the ring, to keep it in sync if
>  a state transition does not require an explicit response.

Assuming that these patches have been tested, I'm ok with them.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 12:25:12 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 12: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.xensource.com>)
	id 1RXu4o-00006F-IS; Tue, 06 Dec 2011 12:24:50 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1RXu4n-00005v-8r
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 12:24:49 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1323174242!4430080!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4709 invoked from network); 6 Dec 2011 12:24:03 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Dec 2011 12:24:03 -0000
Received: by iaen33 with SMTP id n33so26639553iae.30
	for <xen-devel@lists.xensource.com>;
	Tue, 06 Dec 2011 04:24:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=/blnOT7DHTFzlRKhSaoS84zl5Hqc5paDka7NXG3CkzM=;
	b=k+xtL89gthe5OZrIZN/CZKFu2IRdcLKiq5DkkhBWrX3DkYpkanCAmYAARov6LC/S3s
	6ruQf7M0CxEExaj+7snwQ2LyQ7XrKGmgGY8fPIbJ3eGQJAcjvsKkkaYXWJeilJK/pq/4
	R+MpfAMJ1P62ujLjuTM8iAm0NUZUg5kpsX/Vg=
MIME-Version: 1.0
Received: by 10.42.168.202 with SMTP id x10mr14059993icy.4.1323174241737; Tue,
	06 Dec 2011 04:24:01 -0800 (PST)
Received: by 10.231.80.201 with HTTP; Tue, 6 Dec 2011 04:24:01 -0800 (PST)
In-Reply-To: <1322060131.30168.15.camel@Abyss>
References: <1322060131.30168.15.camel@Abyss>
Date: Tue, 6 Dec 2011 12:24:01 +0000
X-Google-Sender-Auth: a0uAwiPwod5wl-Fp4cpB_DgTb_A
Message-ID: <CAFLBxZaa2L4a1sXqcCQPRk8tDPwJ6tCnm6w=ut_1NtbK+9XP=g@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Dario Faggioli <raistlin@linux.it>
Cc: Juergen Gross <juergen.gross@ts.fujitsu.com>, xen-devel@lists.xensource.com,
	Keir Fraser <keir@xen.org>
Subject: Re: [Xen-devel] [RFC/RFT][PATCH 0 of 3] rework locking in
	sched_adjust
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Nov 23, 2011 at 2:55 PM, Dario Faggioli <raistlin@linux.it> wrote:
> Hi everyone,
>
> This series changes how locks are dealt with while adjusting domains'
> scheduling parameters.
>
> I've done and am still doing tests for credit and credit2, and it's
> surviving to all I threw at it up to now. Unfortunately, I can't test
> the sedf part yet, since it is not working on my test boxes due to other
> issues (which I'm also trying to track down). I'm sending the series out
> anyway, so that at least you can have a look at it, and maybe give a
> spin on the sedf part, if you don't have anything more interesting to
> do. ;-P
>
> Juergen series on xl scheduling support attached to this mail, in the
> form of a single patch, for testing convenience.

Hey Dario,  sorry for the long delay in responding.

Overall the patch series looks good to me.  The only issue I see is
that it looks like you introduce a regression between patch 2 and 3 --
that is, if you apply patches 1 and 2, but not 3, then the lock you
grab in sched_sedf.c:sedf_adjust() won't protect against concurrent
accesses from other vcpus; nor will it correctly handle updates to the
per-vcpu EDOM_INFO() variables.

Regressions in mid-patch series are bad because it can mess up bisection.

I think a better way of breaking it down would be:
* Add scheduler global locks, and have them called in the pluggable
scheduler *_adjust() function.  This is redundant, but shouldn't be
harmful.
* Atomically remove both the pause and the lock in schedule.c, and add
the scheduling locks around the per-vcpu EDOM_INFO variables in
sched_sedf.c, all in one patch.  This makes the patch bigger, but it
avoids a regression.  The two things are related anwyay: the reason
you now need scheduling locks around EDOM_INFO variables is because
you're getting rid of the pausing and the lock in schedule.c.

Thoughts?

 -George

>
> --
>
> xen/common/sched_credit.c =A0| =A0 10 +++++++---
> xen/common/sched_credit2.c | =A0 21 +++++++++++----------
> xen/common/sched_sedf.c =A0 =A0| =A0131 +++++++++++++++++++++++++++++++++=
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++=
++---------------------
> xen/common/schedule.c =A0 =A0 =A0| =A0 34 ++-----------------------------=
---
> 4 files changed, 130 insertions(+), 66 deletions(-)
>
> --
> <<This happens because I choose it to happen!>> (Raistlin Majere)
> -------------------------------------------------------------------
> Dario Faggioli, http://retis.sssup.it/people/faggioli
> Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
> PhD Candidate, ReTiS Lab, Scuola Superiore Sant'Anna, Pisa (Italy)
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 12:25:12 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 12: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.xensource.com>)
	id 1RXu4o-00006F-IS; Tue, 06 Dec 2011 12:24:50 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1RXu4n-00005v-8r
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 12:24:49 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1323174242!4430080!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4709 invoked from network); 6 Dec 2011 12:24:03 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Dec 2011 12:24:03 -0000
Received: by iaen33 with SMTP id n33so26639553iae.30
	for <xen-devel@lists.xensource.com>;
	Tue, 06 Dec 2011 04:24:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=/blnOT7DHTFzlRKhSaoS84zl5Hqc5paDka7NXG3CkzM=;
	b=k+xtL89gthe5OZrIZN/CZKFu2IRdcLKiq5DkkhBWrX3DkYpkanCAmYAARov6LC/S3s
	6ruQf7M0CxEExaj+7snwQ2LyQ7XrKGmgGY8fPIbJ3eGQJAcjvsKkkaYXWJeilJK/pq/4
	R+MpfAMJ1P62ujLjuTM8iAm0NUZUg5kpsX/Vg=
MIME-Version: 1.0
Received: by 10.42.168.202 with SMTP id x10mr14059993icy.4.1323174241737; Tue,
	06 Dec 2011 04:24:01 -0800 (PST)
Received: by 10.231.80.201 with HTTP; Tue, 6 Dec 2011 04:24:01 -0800 (PST)
In-Reply-To: <1322060131.30168.15.camel@Abyss>
References: <1322060131.30168.15.camel@Abyss>
Date: Tue, 6 Dec 2011 12:24:01 +0000
X-Google-Sender-Auth: a0uAwiPwod5wl-Fp4cpB_DgTb_A
Message-ID: <CAFLBxZaa2L4a1sXqcCQPRk8tDPwJ6tCnm6w=ut_1NtbK+9XP=g@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Dario Faggioli <raistlin@linux.it>
Cc: Juergen Gross <juergen.gross@ts.fujitsu.com>, xen-devel@lists.xensource.com,
	Keir Fraser <keir@xen.org>
Subject: Re: [Xen-devel] [RFC/RFT][PATCH 0 of 3] rework locking in
	sched_adjust
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Nov 23, 2011 at 2:55 PM, Dario Faggioli <raistlin@linux.it> wrote:
> Hi everyone,
>
> This series changes how locks are dealt with while adjusting domains'
> scheduling parameters.
>
> I've done and am still doing tests for credit and credit2, and it's
> surviving to all I threw at it up to now. Unfortunately, I can't test
> the sedf part yet, since it is not working on my test boxes due to other
> issues (which I'm also trying to track down). I'm sending the series out
> anyway, so that at least you can have a look at it, and maybe give a
> spin on the sedf part, if you don't have anything more interesting to
> do. ;-P
>
> Juergen series on xl scheduling support attached to this mail, in the
> form of a single patch, for testing convenience.

Hey Dario,  sorry for the long delay in responding.

Overall the patch series looks good to me.  The only issue I see is
that it looks like you introduce a regression between patch 2 and 3 --
that is, if you apply patches 1 and 2, but not 3, then the lock you
grab in sched_sedf.c:sedf_adjust() won't protect against concurrent
accesses from other vcpus; nor will it correctly handle updates to the
per-vcpu EDOM_INFO() variables.

Regressions in mid-patch series are bad because it can mess up bisection.

I think a better way of breaking it down would be:
* Add scheduler global locks, and have them called in the pluggable
scheduler *_adjust() function.  This is redundant, but shouldn't be
harmful.
* Atomically remove both the pause and the lock in schedule.c, and add
the scheduling locks around the per-vcpu EDOM_INFO variables in
sched_sedf.c, all in one patch.  This makes the patch bigger, but it
avoids a regression.  The two things are related anwyay: the reason
you now need scheduling locks around EDOM_INFO variables is because
you're getting rid of the pausing and the lock in schedule.c.

Thoughts?

 -George

>
> --
>
> xen/common/sched_credit.c =A0| =A0 10 +++++++---
> xen/common/sched_credit2.c | =A0 21 +++++++++++----------
> xen/common/sched_sedf.c =A0 =A0| =A0131 +++++++++++++++++++++++++++++++++=
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++=
++---------------------
> xen/common/schedule.c =A0 =A0 =A0| =A0 34 ++-----------------------------=
---
> 4 files changed, 130 insertions(+), 66 deletions(-)
>
> --
> <<This happens because I choose it to happen!>> (Raistlin Majere)
> -------------------------------------------------------------------
> Dario Faggioli, http://retis.sssup.it/people/faggioli
> Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
> PhD Candidate, ReTiS Lab, Scuola Superiore Sant'Anna, Pisa (Italy)
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 12:32:01 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 12:32:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXuBM-0000NV-EC; Tue, 06 Dec 2011 12:31:36 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1RXuBL-0000NO-HS
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 12:31:35 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1323174646!1410991!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8717 invoked from network); 6 Dec 2011 12:30:47 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Dec 2011 12:30:47 -0000
Received: by iaen33 with SMTP id n33so26666935iae.30
	for <xen-devel@lists.xensource.com>;
	Tue, 06 Dec 2011 04:30:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=TDJVXmxN8tXFz4kSHt2SNI20CTTjJ/RqhG1NdiSrFSk=;
	b=qONz7WFpMNqTmXCH/F6FKc6B4isIeYMVEBj0N37eXOVBCYe9apY4PIxNh8Ds7kwfHK
	bG8jatfpdo1TGjgCsxWRt2h3B2p94QmIygNyRkrw+bg2iqbWj5n9ruamhmqORDcri1j0
	FgB1zuxVGADanHANb7AZDcm40nA4qBHRuYt7o=
MIME-Version: 1.0
Received: by 10.42.244.137 with SMTP id lq9mr14227161icb.28.1323174645522;
	Tue, 06 Dec 2011 04:30:45 -0800 (PST)
Received: by 10.231.80.201 with HTTP; Tue, 6 Dec 2011 04:30:45 -0800 (PST)
In-Reply-To: <4EDDD485.70208@ts.fujitsu.com>
References: <1322060131.30168.15.camel@Abyss> <4EDDD485.70208@ts.fujitsu.com>
Date: Tue, 6 Dec 2011 12:30:45 +0000
X-Google-Sender-Auth: 7duNxE9KwZyl2nIvmI9SJnOUgaM
Message-ID: <CAFLBxZao_zmfjnKisp+mQee62RhjFVRsvqy_pKP5V5oqzTBzEw@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Juergen Gross <juergen.gross@ts.fujitsu.com>
Cc: Keir Fraser <keir@xen.org>, xen-devel@lists.xensource.com,
	Dario Faggioli <raistlin@linux.it>
Subject: Re: [Xen-devel] [RFC/RFT][PATCH 0 of 3] rework locking in
	sched_adjust
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Dec 6, 2011 at 8:38 AM, Juergen Gross
<juergen.gross@ts.fujitsu.com> wrote:
> (XEN) Xen BUG at spinlock.c:47
[snip]
> (XEN) Xen call trace:
> (XEN) =A0 =A0[<ffff82c480124e84>] check_lock+0x44/0x50
> (XEN) =A0 =A0[<ffff82c480124ec1>] _spin_lock+0x11/0x5d
> (XEN) =A0 =A0[<ffff82c48012c085>] xmem_pool_alloc+0x138/0x4d2
> (XEN) =A0 =A0[<ffff82c48012c557>] _xmalloc+0x138/0x230
> (XEN) =A0 =A0[<ffff82c48012c660>] _xzalloc+0x11/0x2d
> (XEN) =A0 =A0[<ffff82c48011f8ab>] sedf_adjust+0x37c/0x9b2
> (XEN) =A0 =A0[<ffff82c480120fec>] sched_adjust+0x5f/0xb7
> (XEN) =A0 =A0[<ffff82c4801037e3>] do_domctl+0xf32/0x1a9f
> (XEN) =A0 =A0[<ffff82c48021f128>] syscall_enter+0xc8/0x122

Hmm, looks like the problem is that we assert that locks must be
called with IRQs enabled all the time, or never.  From
xen/common/spinlock.c:

     * We partition locks into IRQ-safe (always held with IRQs disabled) and
     * IRQ-unsafe (always held with IRQs enabled) types. The convention for
     * every lock must be consistently observed else we can deadlock in
     * IRQ-context rendezvous functions (a rendezvous which gets every CPU
     * into IRQ context before any CPU is released from the rendezvous).

sedf_adj() grabs the private lock with irqs disabled, then calls
sedf_adjust_weights(), which calls xmalloc to allocate some local
scratch space, which ultimately grabs a non-IRQ spinlock.

Not sure the best thing to do here...

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 12:32:01 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 12:32:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXuBM-0000NV-EC; Tue, 06 Dec 2011 12:31:36 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1RXuBL-0000NO-HS
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 12:31:35 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1323174646!1410991!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8717 invoked from network); 6 Dec 2011 12:30:47 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Dec 2011 12:30:47 -0000
Received: by iaen33 with SMTP id n33so26666935iae.30
	for <xen-devel@lists.xensource.com>;
	Tue, 06 Dec 2011 04:30:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=TDJVXmxN8tXFz4kSHt2SNI20CTTjJ/RqhG1NdiSrFSk=;
	b=qONz7WFpMNqTmXCH/F6FKc6B4isIeYMVEBj0N37eXOVBCYe9apY4PIxNh8Ds7kwfHK
	bG8jatfpdo1TGjgCsxWRt2h3B2p94QmIygNyRkrw+bg2iqbWj5n9ruamhmqORDcri1j0
	FgB1zuxVGADanHANb7AZDcm40nA4qBHRuYt7o=
MIME-Version: 1.0
Received: by 10.42.244.137 with SMTP id lq9mr14227161icb.28.1323174645522;
	Tue, 06 Dec 2011 04:30:45 -0800 (PST)
Received: by 10.231.80.201 with HTTP; Tue, 6 Dec 2011 04:30:45 -0800 (PST)
In-Reply-To: <4EDDD485.70208@ts.fujitsu.com>
References: <1322060131.30168.15.camel@Abyss> <4EDDD485.70208@ts.fujitsu.com>
Date: Tue, 6 Dec 2011 12:30:45 +0000
X-Google-Sender-Auth: 7duNxE9KwZyl2nIvmI9SJnOUgaM
Message-ID: <CAFLBxZao_zmfjnKisp+mQee62RhjFVRsvqy_pKP5V5oqzTBzEw@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Juergen Gross <juergen.gross@ts.fujitsu.com>
Cc: Keir Fraser <keir@xen.org>, xen-devel@lists.xensource.com,
	Dario Faggioli <raistlin@linux.it>
Subject: Re: [Xen-devel] [RFC/RFT][PATCH 0 of 3] rework locking in
	sched_adjust
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Dec 6, 2011 at 8:38 AM, Juergen Gross
<juergen.gross@ts.fujitsu.com> wrote:
> (XEN) Xen BUG at spinlock.c:47
[snip]
> (XEN) Xen call trace:
> (XEN) =A0 =A0[<ffff82c480124e84>] check_lock+0x44/0x50
> (XEN) =A0 =A0[<ffff82c480124ec1>] _spin_lock+0x11/0x5d
> (XEN) =A0 =A0[<ffff82c48012c085>] xmem_pool_alloc+0x138/0x4d2
> (XEN) =A0 =A0[<ffff82c48012c557>] _xmalloc+0x138/0x230
> (XEN) =A0 =A0[<ffff82c48012c660>] _xzalloc+0x11/0x2d
> (XEN) =A0 =A0[<ffff82c48011f8ab>] sedf_adjust+0x37c/0x9b2
> (XEN) =A0 =A0[<ffff82c480120fec>] sched_adjust+0x5f/0xb7
> (XEN) =A0 =A0[<ffff82c4801037e3>] do_domctl+0xf32/0x1a9f
> (XEN) =A0 =A0[<ffff82c48021f128>] syscall_enter+0xc8/0x122

Hmm, looks like the problem is that we assert that locks must be
called with IRQs enabled all the time, or never.  From
xen/common/spinlock.c:

     * We partition locks into IRQ-safe (always held with IRQs disabled) and
     * IRQ-unsafe (always held with IRQs enabled) types. The convention for
     * every lock must be consistently observed else we can deadlock in
     * IRQ-context rendezvous functions (a rendezvous which gets every CPU
     * into IRQ context before any CPU is released from the rendezvous).

sedf_adj() grabs the private lock with irqs disabled, then calls
sedf_adjust_weights(), which calls xmalloc to allocate some local
scratch space, which ultimately grabs a non-IRQ spinlock.

Not sure the best thing to do here...

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 12:36:52 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 12:36:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXuG9-0000ZY-5U; Tue, 06 Dec 2011 12:36:33 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raghukt@linux.vnet.ibm.com>) id 1RXGTz-0006Lh-Ja
	for xen-devel@lists.xensource.com; Sun, 04 Dec 2011 18:08:11 +0000
X-Env-Sender: raghukt@linux.vnet.ibm.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1323022025!50821152!1
X-Originating-IP: [202.81.31.141]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjAyLjgxLjMxLjE0MSA9PiA1NzQ0NQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19202 invoked from network); 4 Dec 2011 18:07:08 -0000
Received: from e23smtp08.au.ibm.com (HELO e23smtp08.au.ibm.com) (202.81.31.141)
	by server-13.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Dec 2011 18:07:08 -0000
Received: from /spool/local
	by e23smtp08.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use
	Only! Violators will be prosecuted
	for <xen-devel@lists.xensource.com> from <raghukt@linux.vnet.ibm.com>; 
	Sun, 4 Dec 2011 18:05:42 +1000
Received: from d23relay03.au.ibm.com ([202.81.31.245])
	by e23smtp08.au.ibm.com ([202.81.31.205]) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Sun, 4 Dec 2011 18:05:36 +1000
Received: from d23av04.au.ibm.com (d23av04.au.ibm.com [9.190.235.139])
	by d23relay03.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	pB4I7A7a5398530
	for <xen-devel@lists.xensource.com>; Mon, 5 Dec 2011 05:07:13 +1100
Received: from d23av04.au.ibm.com (loopback [127.0.0.1])
	by d23av04.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id
	pB4I7802027634
	for <xen-devel@lists.xensource.com>; Mon, 5 Dec 2011 05:07:09 +1100
Received: from oc5400248562.ibm.com ([9.79.238.83])
	by d23av04.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	pB4I6xHg027489; Mon, 5 Dec 2011 05:07:01 +1100
Message-ID: <4EDBB6C2.9050303@linux.vnet.ibm.com>
Date: Sun, 04 Dec 2011 23:36:58 +0530
From: Raghavendra K T <raghukt@linux.vnet.ibm.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
	rv:1.9.2.24) Gecko/20111108 Fedora/3.1.16-1.fc14 Thunderbird/3.1.16
MIME-Version: 1.0
To: Avi Kivity <avi@redhat.com>
References: <20111130085921.23386.89708.sendpatchset@oc5400248562.ibm.com>
	<20111130085959.23386.69166.sendpatchset@oc5400248562.ibm.com>
	<4ED760F1.6080804@redhat.com> <4ED7DA85.5080504@linux.vnet.ibm.com>
In-Reply-To: <4ED7DA85.5080504@linux.vnet.ibm.com>
x-cbid: 11120408-5140-0000-0000-0000005E65E7
X-Mailman-Approved-At: Tue, 06 Dec 2011 12:36:31 +0000
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, x86@kernel.org,
	Gleb Natapov <gleb@redhat.com>, Peter Zijlstra <peterz@infradead.org>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Xen <xen-devel@lists.xensource.com>,
	Dave Jiang <dave.jiang@intel.com>, KVM <kvm@vger.kernel.org>,
	Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	Ingo Molnar <mingo@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Marcelo Tosatti <mtosatti@redhat.com>,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>,
	Sasha Levin <levinsasha928@gmail.com>, Sedat Dilek <sedat.dilek@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>, Yinghai Lu <yinghai@kernel.org>,
	Greg Kroah-Hartman <gregkh@suse.de>, LKML <linux-kernel@vger.kernel.org>,
	Dave Hansen <dave@linux.vnet.ibm.com>,
	Suzuki Poulose <suzuki@linux.vnet.ibm.com>
Subject: Re: [Xen-devel] [PATCH RFC V3 2/4] kvm hypervisor : Add a hypercall
 to KVM hypervisor to support pv-ticketlocks
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 12/02/2011 01:20 AM, Raghavendra K T wrote:
>> Have you tested it on AMD machines? There are some differences in the
>> hypercall infrastructure there.
>
> Yes. 'll test on AMD machine and update on that.
>

I tested the code on 64 bit Dual-Core AMD Opteron machine, and it is 
working.

- Raghu


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 12:36:52 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 12:36:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXuG9-0000ZY-5U; Tue, 06 Dec 2011 12:36:33 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raghukt@linux.vnet.ibm.com>) id 1RXGTz-0006Lh-Ja
	for xen-devel@lists.xensource.com; Sun, 04 Dec 2011 18:08:11 +0000
X-Env-Sender: raghukt@linux.vnet.ibm.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1323022025!50821152!1
X-Originating-IP: [202.81.31.141]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjAyLjgxLjMxLjE0MSA9PiA1NzQ0NQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19202 invoked from network); 4 Dec 2011 18:07:08 -0000
Received: from e23smtp08.au.ibm.com (HELO e23smtp08.au.ibm.com) (202.81.31.141)
	by server-13.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Dec 2011 18:07:08 -0000
Received: from /spool/local
	by e23smtp08.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use
	Only! Violators will be prosecuted
	for <xen-devel@lists.xensource.com> from <raghukt@linux.vnet.ibm.com>; 
	Sun, 4 Dec 2011 18:05:42 +1000
Received: from d23relay03.au.ibm.com ([202.81.31.245])
	by e23smtp08.au.ibm.com ([202.81.31.205]) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Sun, 4 Dec 2011 18:05:36 +1000
Received: from d23av04.au.ibm.com (d23av04.au.ibm.com [9.190.235.139])
	by d23relay03.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	pB4I7A7a5398530
	for <xen-devel@lists.xensource.com>; Mon, 5 Dec 2011 05:07:13 +1100
Received: from d23av04.au.ibm.com (loopback [127.0.0.1])
	by d23av04.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id
	pB4I7802027634
	for <xen-devel@lists.xensource.com>; Mon, 5 Dec 2011 05:07:09 +1100
Received: from oc5400248562.ibm.com ([9.79.238.83])
	by d23av04.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	pB4I6xHg027489; Mon, 5 Dec 2011 05:07:01 +1100
Message-ID: <4EDBB6C2.9050303@linux.vnet.ibm.com>
Date: Sun, 04 Dec 2011 23:36:58 +0530
From: Raghavendra K T <raghukt@linux.vnet.ibm.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
	rv:1.9.2.24) Gecko/20111108 Fedora/3.1.16-1.fc14 Thunderbird/3.1.16
MIME-Version: 1.0
To: Avi Kivity <avi@redhat.com>
References: <20111130085921.23386.89708.sendpatchset@oc5400248562.ibm.com>
	<20111130085959.23386.69166.sendpatchset@oc5400248562.ibm.com>
	<4ED760F1.6080804@redhat.com> <4ED7DA85.5080504@linux.vnet.ibm.com>
In-Reply-To: <4ED7DA85.5080504@linux.vnet.ibm.com>
x-cbid: 11120408-5140-0000-0000-0000005E65E7
X-Mailman-Approved-At: Tue, 06 Dec 2011 12:36:31 +0000
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, x86@kernel.org,
	Gleb Natapov <gleb@redhat.com>, Peter Zijlstra <peterz@infradead.org>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Xen <xen-devel@lists.xensource.com>,
	Dave Jiang <dave.jiang@intel.com>, KVM <kvm@vger.kernel.org>,
	Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	Ingo Molnar <mingo@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Marcelo Tosatti <mtosatti@redhat.com>,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>,
	Sasha Levin <levinsasha928@gmail.com>, Sedat Dilek <sedat.dilek@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>, Yinghai Lu <yinghai@kernel.org>,
	Greg Kroah-Hartman <gregkh@suse.de>, LKML <linux-kernel@vger.kernel.org>,
	Dave Hansen <dave@linux.vnet.ibm.com>,
	Suzuki Poulose <suzuki@linux.vnet.ibm.com>
Subject: Re: [Xen-devel] [PATCH RFC V3 2/4] kvm hypervisor : Add a hypercall
 to KVM hypervisor to support pv-ticketlocks
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 12/02/2011 01:20 AM, Raghavendra K T wrote:
>> Have you tested it on AMD machines? There are some differences in the
>> hypercall infrastructure there.
>
> Yes. 'll test on AMD machine and update on that.
>

I tested the code on 64 bit Dual-Core AMD Opteron machine, and it is 
working.

- Raghu


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 12:36:54 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 12:36:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXuG9-0000Zf-Hx; Tue, 06 Dec 2011 12:36:33 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1RXiht-0005PK-Ft
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 00:16:25 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-10.tower-216.messagelabs.com!1323130537!6190586!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27688 invoked from network); 6 Dec 2011 00:15:38 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-10.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 6 Dec 2011 00:15:38 -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
	pB60DSU2020633
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Mon, 5 Dec 2011 19:13:28 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pB60DRFM020631;
	Mon, 5 Dec 2011 19:13:27 -0500
Date: Mon, 5 Dec 2011 20:13:27 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
Message-ID: <20111206001327.GA20511@andromeda.dapyr.net>
References: <20111130085921.23386.89708.sendpatchset@oc5400248562.ibm.com>
	<20111130085939.23386.1242.sendpatchset@oc5400248562.ibm.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20111130085939.23386.1242.sendpatchset@oc5400248562.ibm.com>
User-Agent: Mutt/1.5.9i
X-Mailman-Approved-At: Tue, 06 Dec 2011 12:36:31 +0000
Cc: Marcelo Tosatti <mtosatti@redhat.com>, KVM <kvm@vger.kernel.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	"H. Peter Anvin" <hpa@zytor.com>, Xen <xen-devel@lists.xensource.com>,
	Dave Jiang <dave.jiang@intel.com>,
	Gleb Natapov <gleb@redhat.com>, x86@kernel.org,
	Ingo Molnar <mingo@redhat.com>, Avi Kivity <avi@redhat.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>,
	Sasha Levin <levinsasha928@gmail.com>, Sedat Dilek <sedat.dilek@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>, Yinghai Lu <yinghai@kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Greg Kroah-Hartman <gregkh@suse.de>, LKML <linux-kernel@vger.kernel.org>,
	Dave Hansen <dave@linux.vnet.ibm.com>,
	Suzuki Poulose <suzuki@linux.vnet.ibm.com>
Subject: Re: [Xen-devel] [PATCH RFC V3 1/4] debugfs: Add support to print
	u32 array in debugfs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Nov 30, 2011 at 02:29:39PM +0530, Raghavendra K T wrote:
> Add debugfs support to print u32-arrays in debugfs. Move the code from Xen to debugfs
> to make the code common for other users as well.
> 
> Signed-off-by: Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>
> Signed-off-by: Suzuki Poulose <suzuki@in.ibm.com>
> Signed-off-by: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>

Looks good to me.
> ---
> diff --git a/arch/x86/xen/debugfs.c b/arch/x86/xen/debugfs.c
> index 7c0fedd..c8377fb 100644
> --- a/arch/x86/xen/debugfs.c
> +++ b/arch/x86/xen/debugfs.c
> @@ -19,107 +19,3 @@ struct dentry * __init xen_init_debugfs(void)
>  	return d_xen_debug;
>  }
>  
> -struct array_data
> -{
> -	void *array;
> -	unsigned elements;
> -};
> -
> -static int u32_array_open(struct inode *inode, struct file *file)
> -{
> -	file->private_data = NULL;
> -	return nonseekable_open(inode, file);
> -}
> -
> -static size_t format_array(char *buf, size_t bufsize, const char *fmt,
> -			   u32 *array, unsigned array_size)
> -{
> -	size_t ret = 0;
> -	unsigned i;
> -
> -	for(i = 0; i < array_size; i++) {
> -		size_t len;
> -
> -		len = snprintf(buf, bufsize, fmt, array[i]);
> -		len++;	/* ' ' or '\n' */
> -		ret += len;
> -
> -		if (buf) {
> -			buf += len;
> -			bufsize -= len;
> -			buf[-1] = (i == array_size-1) ? '\n' : ' ';
> -		}
> -	}
> -
> -	ret++;		/* \0 */
> -	if (buf)
> -		*buf = '\0';
> -
> -	return ret;
> -}
> -
> -static char *format_array_alloc(const char *fmt, u32 *array, unsigned array_size)
> -{
> -	size_t len = format_array(NULL, 0, fmt, array, array_size);
> -	char *ret;
> -
> -	ret = kmalloc(len, GFP_KERNEL);
> -	if (ret == NULL)
> -		return NULL;
> -
> -	format_array(ret, len, fmt, array, array_size);
> -	return ret;
> -}
> -
> -static ssize_t u32_array_read(struct file *file, char __user *buf, size_t len,
> -			      loff_t *ppos)
> -{
> -	struct inode *inode = file->f_path.dentry->d_inode;
> -	struct array_data *data = inode->i_private;
> -	size_t size;
> -
> -	if (*ppos == 0) {
> -		if (file->private_data) {
> -			kfree(file->private_data);
> -			file->private_data = NULL;
> -		}
> -
> -		file->private_data = format_array_alloc("%u", data->array, data->elements);
> -	}
> -
> -	size = 0;
> -	if (file->private_data)
> -		size = strlen(file->private_data);
> -
> -	return simple_read_from_buffer(buf, len, ppos, file->private_data, size);
> -}
> -
> -static int xen_array_release(struct inode *inode, struct file *file)
> -{
> -	kfree(file->private_data);
> -
> -	return 0;
> -}
> -
> -static const struct file_operations u32_array_fops = {
> -	.owner	= THIS_MODULE,
> -	.open	= u32_array_open,
> -	.release= xen_array_release,
> -	.read	= u32_array_read,
> -	.llseek = no_llseek,
> -};
> -
> -struct dentry *xen_debugfs_create_u32_array(const char *name, mode_t mode,
> -					    struct dentry *parent,
> -					    u32 *array, unsigned elements)
> -{
> -	struct array_data *data = kmalloc(sizeof(*data), GFP_KERNEL);
> -
> -	if (data == NULL)
> -		return NULL;
> -
> -	data->array = array;
> -	data->elements = elements;
> -
> -	return debugfs_create_file(name, mode, parent, data, &u32_array_fops);
> -}
> diff --git a/arch/x86/xen/debugfs.h b/arch/x86/xen/debugfs.h
> index e281320..12ebf33 100644
> --- a/arch/x86/xen/debugfs.h
> +++ b/arch/x86/xen/debugfs.h
> @@ -3,8 +3,4 @@
>  
>  struct dentry * __init xen_init_debugfs(void);
>  
> -struct dentry *xen_debugfs_create_u32_array(const char *name, mode_t mode,
> -					    struct dentry *parent,
> -					    u32 *array, unsigned elements);
> -
>  #endif /* _XEN_DEBUGFS_H */
> diff --git a/arch/x86/xen/spinlock.c b/arch/x86/xen/spinlock.c
> index fc506e6..14a8961 100644
> --- a/arch/x86/xen/spinlock.c
> +++ b/arch/x86/xen/spinlock.c
> @@ -286,7 +286,7 @@ static int __init xen_spinlock_debugfs(void)
>  	debugfs_create_u64("time_blocked", 0444, d_spin_debug,
>  			   &spinlock_stats.time_blocked);
>  
> -	xen_debugfs_create_u32_array("histo_blocked", 0444, d_spin_debug,
> +	debugfs_create_u32_array("histo_blocked", 0444, d_spin_debug,
>  				     spinlock_stats.histo_spin_blocked, HISTO_BUCKETS + 1);
>  
>  	return 0;
> diff --git a/fs/debugfs/file.c b/fs/debugfs/file.c
> index 90f7657..df44ccf 100644
> --- a/fs/debugfs/file.c
> +++ b/fs/debugfs/file.c
> @@ -18,6 +18,7 @@
>  #include <linux/pagemap.h>
>  #include <linux/namei.h>
>  #include <linux/debugfs.h>
> +#include <linux/slab.h>
>  
>  static ssize_t default_read_file(struct file *file, char __user *buf,
>  				 size_t count, loff_t *ppos)
> @@ -525,3 +526,130 @@ struct dentry *debugfs_create_blob(const char *name, mode_t mode,
>  	return debugfs_create_file(name, mode, parent, blob, &fops_blob);
>  }
>  EXPORT_SYMBOL_GPL(debugfs_create_blob);
> +
> +struct array_data {
> +	void *array;
> +	u32 elements;
> +};
> +
> +static int u32_array_open(struct inode *inode, struct file *file)
> +{
> +	file->private_data = NULL;
> +	return nonseekable_open(inode, file);
> +}
> +
> +static size_t format_array(char *buf, size_t bufsize, const char *fmt,
> +			   u32 *array, u32 array_size)
> +{
> +	size_t ret = 0;
> +	u32 i;
> +
> +	for (i = 0; i < array_size; i++) {
> +		size_t len;
> +
> +		len = snprintf(buf, bufsize, fmt, array[i]);
> +		len++;	/* ' ' or '\n' */
> +		ret += len;
> +
> +		if (buf) {
> +			buf += len;
> +			bufsize -= len;
> +			buf[-1] = (i == array_size-1) ? '\n' : ' ';
> +		}
> +	}
> +
> +	ret++;		/* \0 */
> +	if (buf)
> +		*buf = '\0';
> +
> +	return ret;
> +}
> +
> +static char *format_array_alloc(const char *fmt, u32 *array,
> +						u32 array_size)
> +{
> +	size_t len = format_array(NULL, 0, fmt, array, array_size);
> +	char *ret;
> +
> +	ret = kmalloc(len, GFP_KERNEL);
> +	if (ret == NULL)
> +		return NULL;
> +
> +	format_array(ret, len, fmt, array, array_size);
> +	return ret;
> +}
> +
> +static ssize_t u32_array_read(struct file *file, char __user *buf, size_t len,
> +			      loff_t *ppos)
> +{
> +	struct inode *inode = file->f_path.dentry->d_inode;
> +	struct array_data *data = inode->i_private;
> +	size_t size;
> +
> +	if (*ppos == 0) {
> +		if (file->private_data) {
> +			kfree(file->private_data);
> +			file->private_data = NULL;
> +		}
> +
> +		file->private_data = format_array_alloc("%u", data->array,
> +							      data->elements);
> +	}
> +
> +	size = 0;
> +	if (file->private_data)
> +		size = strlen(file->private_data);
> +
> +	return simple_read_from_buffer(buf, len, ppos,
> +					file->private_data, size);
> +}
> +
> +static int u32_array_release(struct inode *inode, struct file *file)
> +{
> +	kfree(file->private_data);
> +
> +	return 0;
> +}
> +
> +static const struct file_operations u32_array_fops = {
> +	.owner	 = THIS_MODULE,
> +	.open	 = u32_array_open,
> +	.release = u32_array_release,
> +	.read	 = u32_array_read,
> +	.llseek  = no_llseek,
> +};
> +
> +/**
> + * debugfs_create_u32_array - create a debugfs file that is used to read u32
> + * array.
> + * @name: a pointer to a string containing the name of the file to create.
> + * @mode: the permission that the file should have.
> + * @parent: a pointer to the parent dentry for this file.  This should be a
> + *          directory dentry if set.  If this parameter is %NULL, then the
> + *          file will be created in the root of the debugfs filesystem.
> + * @array: u32 array that provides data.
> + * @elements: total number of elements in the array.
> + *
> + * This function creates a file in debugfs with the given name that exports
> + * @array as data. If the @mode variable is so set it can be read from.
> + * Writing is not supported. Seek within the file is also not supported.
> + * Once array is created its size can not be changed.
> + *
> + * The function returns a pointer to dentry on success. If debugfs is not
> + * enabled in the kernel, the value -%ENODEV will be returned.
> + */
> +struct dentry *debugfs_create_u32_array(const char *name, mode_t mode,
> +					    struct dentry *parent,
> +					    u32 *array, u32 elements)
> +{
> +	struct array_data *data = kmalloc(sizeof(*data), GFP_KERNEL);
> +
> +	if (data == NULL)
> +		return NULL;
> +
> +	data->array = array;
> +	data->elements = elements;
> +
> +	return debugfs_create_file(name, mode, parent, data, &u32_array_fops);
> +}
> +EXPORT_SYMBOL_GPL(debugfs_create_u32_array);
> diff --git a/include/linux/debugfs.h b/include/linux/debugfs.h
> index e7d9b20..253e2fb 100644
> --- a/include/linux/debugfs.h
> +++ b/include/linux/debugfs.h
> @@ -74,6 +74,10 @@ struct dentry *debugfs_create_blob(const char *name, mode_t mode,
>  				  struct dentry *parent,
>  				  struct debugfs_blob_wrapper *blob);
>  
> +struct dentry *debugfs_create_u32_array(const char *name, mode_t mode,
> +					struct dentry *parent,
> +					u32 *array, u32 elements);
> +
>  bool debugfs_initialized(void);
>  
>  #else
> @@ -193,6 +197,13 @@ static inline bool debugfs_initialized(void)
>  	return false;
>  }
>  
> +struct dentry *debugfs_create_u32_array(const char *name, mode_t mode,
> +					struct dentry *parent,
> +					u32 *array, u32 elements)
> +{
> +	return ERR_PTR(-ENODEV);
> +}
> +
>  #endif
>  
>  #endif
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 12:36:54 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 12:36:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXuG9-0000Zf-Hx; Tue, 06 Dec 2011 12:36:33 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1RXiht-0005PK-Ft
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 00:16:25 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-10.tower-216.messagelabs.com!1323130537!6190586!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27688 invoked from network); 6 Dec 2011 00:15:38 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-10.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 6 Dec 2011 00:15:38 -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
	pB60DSU2020633
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Mon, 5 Dec 2011 19:13:28 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pB60DRFM020631;
	Mon, 5 Dec 2011 19:13:27 -0500
Date: Mon, 5 Dec 2011 20:13:27 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
Message-ID: <20111206001327.GA20511@andromeda.dapyr.net>
References: <20111130085921.23386.89708.sendpatchset@oc5400248562.ibm.com>
	<20111130085939.23386.1242.sendpatchset@oc5400248562.ibm.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20111130085939.23386.1242.sendpatchset@oc5400248562.ibm.com>
User-Agent: Mutt/1.5.9i
X-Mailman-Approved-At: Tue, 06 Dec 2011 12:36:31 +0000
Cc: Marcelo Tosatti <mtosatti@redhat.com>, KVM <kvm@vger.kernel.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	"H. Peter Anvin" <hpa@zytor.com>, Xen <xen-devel@lists.xensource.com>,
	Dave Jiang <dave.jiang@intel.com>,
	Gleb Natapov <gleb@redhat.com>, x86@kernel.org,
	Ingo Molnar <mingo@redhat.com>, Avi Kivity <avi@redhat.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>,
	Sasha Levin <levinsasha928@gmail.com>, Sedat Dilek <sedat.dilek@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>, Yinghai Lu <yinghai@kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Greg Kroah-Hartman <gregkh@suse.de>, LKML <linux-kernel@vger.kernel.org>,
	Dave Hansen <dave@linux.vnet.ibm.com>,
	Suzuki Poulose <suzuki@linux.vnet.ibm.com>
Subject: Re: [Xen-devel] [PATCH RFC V3 1/4] debugfs: Add support to print
	u32 array in debugfs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Nov 30, 2011 at 02:29:39PM +0530, Raghavendra K T wrote:
> Add debugfs support to print u32-arrays in debugfs. Move the code from Xen to debugfs
> to make the code common for other users as well.
> 
> Signed-off-by: Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>
> Signed-off-by: Suzuki Poulose <suzuki@in.ibm.com>
> Signed-off-by: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>

Looks good to me.
> ---
> diff --git a/arch/x86/xen/debugfs.c b/arch/x86/xen/debugfs.c
> index 7c0fedd..c8377fb 100644
> --- a/arch/x86/xen/debugfs.c
> +++ b/arch/x86/xen/debugfs.c
> @@ -19,107 +19,3 @@ struct dentry * __init xen_init_debugfs(void)
>  	return d_xen_debug;
>  }
>  
> -struct array_data
> -{
> -	void *array;
> -	unsigned elements;
> -};
> -
> -static int u32_array_open(struct inode *inode, struct file *file)
> -{
> -	file->private_data = NULL;
> -	return nonseekable_open(inode, file);
> -}
> -
> -static size_t format_array(char *buf, size_t bufsize, const char *fmt,
> -			   u32 *array, unsigned array_size)
> -{
> -	size_t ret = 0;
> -	unsigned i;
> -
> -	for(i = 0; i < array_size; i++) {
> -		size_t len;
> -
> -		len = snprintf(buf, bufsize, fmt, array[i]);
> -		len++;	/* ' ' or '\n' */
> -		ret += len;
> -
> -		if (buf) {
> -			buf += len;
> -			bufsize -= len;
> -			buf[-1] = (i == array_size-1) ? '\n' : ' ';
> -		}
> -	}
> -
> -	ret++;		/* \0 */
> -	if (buf)
> -		*buf = '\0';
> -
> -	return ret;
> -}
> -
> -static char *format_array_alloc(const char *fmt, u32 *array, unsigned array_size)
> -{
> -	size_t len = format_array(NULL, 0, fmt, array, array_size);
> -	char *ret;
> -
> -	ret = kmalloc(len, GFP_KERNEL);
> -	if (ret == NULL)
> -		return NULL;
> -
> -	format_array(ret, len, fmt, array, array_size);
> -	return ret;
> -}
> -
> -static ssize_t u32_array_read(struct file *file, char __user *buf, size_t len,
> -			      loff_t *ppos)
> -{
> -	struct inode *inode = file->f_path.dentry->d_inode;
> -	struct array_data *data = inode->i_private;
> -	size_t size;
> -
> -	if (*ppos == 0) {
> -		if (file->private_data) {
> -			kfree(file->private_data);
> -			file->private_data = NULL;
> -		}
> -
> -		file->private_data = format_array_alloc("%u", data->array, data->elements);
> -	}
> -
> -	size = 0;
> -	if (file->private_data)
> -		size = strlen(file->private_data);
> -
> -	return simple_read_from_buffer(buf, len, ppos, file->private_data, size);
> -}
> -
> -static int xen_array_release(struct inode *inode, struct file *file)
> -{
> -	kfree(file->private_data);
> -
> -	return 0;
> -}
> -
> -static const struct file_operations u32_array_fops = {
> -	.owner	= THIS_MODULE,
> -	.open	= u32_array_open,
> -	.release= xen_array_release,
> -	.read	= u32_array_read,
> -	.llseek = no_llseek,
> -};
> -
> -struct dentry *xen_debugfs_create_u32_array(const char *name, mode_t mode,
> -					    struct dentry *parent,
> -					    u32 *array, unsigned elements)
> -{
> -	struct array_data *data = kmalloc(sizeof(*data), GFP_KERNEL);
> -
> -	if (data == NULL)
> -		return NULL;
> -
> -	data->array = array;
> -	data->elements = elements;
> -
> -	return debugfs_create_file(name, mode, parent, data, &u32_array_fops);
> -}
> diff --git a/arch/x86/xen/debugfs.h b/arch/x86/xen/debugfs.h
> index e281320..12ebf33 100644
> --- a/arch/x86/xen/debugfs.h
> +++ b/arch/x86/xen/debugfs.h
> @@ -3,8 +3,4 @@
>  
>  struct dentry * __init xen_init_debugfs(void);
>  
> -struct dentry *xen_debugfs_create_u32_array(const char *name, mode_t mode,
> -					    struct dentry *parent,
> -					    u32 *array, unsigned elements);
> -
>  #endif /* _XEN_DEBUGFS_H */
> diff --git a/arch/x86/xen/spinlock.c b/arch/x86/xen/spinlock.c
> index fc506e6..14a8961 100644
> --- a/arch/x86/xen/spinlock.c
> +++ b/arch/x86/xen/spinlock.c
> @@ -286,7 +286,7 @@ static int __init xen_spinlock_debugfs(void)
>  	debugfs_create_u64("time_blocked", 0444, d_spin_debug,
>  			   &spinlock_stats.time_blocked);
>  
> -	xen_debugfs_create_u32_array("histo_blocked", 0444, d_spin_debug,
> +	debugfs_create_u32_array("histo_blocked", 0444, d_spin_debug,
>  				     spinlock_stats.histo_spin_blocked, HISTO_BUCKETS + 1);
>  
>  	return 0;
> diff --git a/fs/debugfs/file.c b/fs/debugfs/file.c
> index 90f7657..df44ccf 100644
> --- a/fs/debugfs/file.c
> +++ b/fs/debugfs/file.c
> @@ -18,6 +18,7 @@
>  #include <linux/pagemap.h>
>  #include <linux/namei.h>
>  #include <linux/debugfs.h>
> +#include <linux/slab.h>
>  
>  static ssize_t default_read_file(struct file *file, char __user *buf,
>  				 size_t count, loff_t *ppos)
> @@ -525,3 +526,130 @@ struct dentry *debugfs_create_blob(const char *name, mode_t mode,
>  	return debugfs_create_file(name, mode, parent, blob, &fops_blob);
>  }
>  EXPORT_SYMBOL_GPL(debugfs_create_blob);
> +
> +struct array_data {
> +	void *array;
> +	u32 elements;
> +};
> +
> +static int u32_array_open(struct inode *inode, struct file *file)
> +{
> +	file->private_data = NULL;
> +	return nonseekable_open(inode, file);
> +}
> +
> +static size_t format_array(char *buf, size_t bufsize, const char *fmt,
> +			   u32 *array, u32 array_size)
> +{
> +	size_t ret = 0;
> +	u32 i;
> +
> +	for (i = 0; i < array_size; i++) {
> +		size_t len;
> +
> +		len = snprintf(buf, bufsize, fmt, array[i]);
> +		len++;	/* ' ' or '\n' */
> +		ret += len;
> +
> +		if (buf) {
> +			buf += len;
> +			bufsize -= len;
> +			buf[-1] = (i == array_size-1) ? '\n' : ' ';
> +		}
> +	}
> +
> +	ret++;		/* \0 */
> +	if (buf)
> +		*buf = '\0';
> +
> +	return ret;
> +}
> +
> +static char *format_array_alloc(const char *fmt, u32 *array,
> +						u32 array_size)
> +{
> +	size_t len = format_array(NULL, 0, fmt, array, array_size);
> +	char *ret;
> +
> +	ret = kmalloc(len, GFP_KERNEL);
> +	if (ret == NULL)
> +		return NULL;
> +
> +	format_array(ret, len, fmt, array, array_size);
> +	return ret;
> +}
> +
> +static ssize_t u32_array_read(struct file *file, char __user *buf, size_t len,
> +			      loff_t *ppos)
> +{
> +	struct inode *inode = file->f_path.dentry->d_inode;
> +	struct array_data *data = inode->i_private;
> +	size_t size;
> +
> +	if (*ppos == 0) {
> +		if (file->private_data) {
> +			kfree(file->private_data);
> +			file->private_data = NULL;
> +		}
> +
> +		file->private_data = format_array_alloc("%u", data->array,
> +							      data->elements);
> +	}
> +
> +	size = 0;
> +	if (file->private_data)
> +		size = strlen(file->private_data);
> +
> +	return simple_read_from_buffer(buf, len, ppos,
> +					file->private_data, size);
> +}
> +
> +static int u32_array_release(struct inode *inode, struct file *file)
> +{
> +	kfree(file->private_data);
> +
> +	return 0;
> +}
> +
> +static const struct file_operations u32_array_fops = {
> +	.owner	 = THIS_MODULE,
> +	.open	 = u32_array_open,
> +	.release = u32_array_release,
> +	.read	 = u32_array_read,
> +	.llseek  = no_llseek,
> +};
> +
> +/**
> + * debugfs_create_u32_array - create a debugfs file that is used to read u32
> + * array.
> + * @name: a pointer to a string containing the name of the file to create.
> + * @mode: the permission that the file should have.
> + * @parent: a pointer to the parent dentry for this file.  This should be a
> + *          directory dentry if set.  If this parameter is %NULL, then the
> + *          file will be created in the root of the debugfs filesystem.
> + * @array: u32 array that provides data.
> + * @elements: total number of elements in the array.
> + *
> + * This function creates a file in debugfs with the given name that exports
> + * @array as data. If the @mode variable is so set it can be read from.
> + * Writing is not supported. Seek within the file is also not supported.
> + * Once array is created its size can not be changed.
> + *
> + * The function returns a pointer to dentry on success. If debugfs is not
> + * enabled in the kernel, the value -%ENODEV will be returned.
> + */
> +struct dentry *debugfs_create_u32_array(const char *name, mode_t mode,
> +					    struct dentry *parent,
> +					    u32 *array, u32 elements)
> +{
> +	struct array_data *data = kmalloc(sizeof(*data), GFP_KERNEL);
> +
> +	if (data == NULL)
> +		return NULL;
> +
> +	data->array = array;
> +	data->elements = elements;
> +
> +	return debugfs_create_file(name, mode, parent, data, &u32_array_fops);
> +}
> +EXPORT_SYMBOL_GPL(debugfs_create_u32_array);
> diff --git a/include/linux/debugfs.h b/include/linux/debugfs.h
> index e7d9b20..253e2fb 100644
> --- a/include/linux/debugfs.h
> +++ b/include/linux/debugfs.h
> @@ -74,6 +74,10 @@ struct dentry *debugfs_create_blob(const char *name, mode_t mode,
>  				  struct dentry *parent,
>  				  struct debugfs_blob_wrapper *blob);
>  
> +struct dentry *debugfs_create_u32_array(const char *name, mode_t mode,
> +					struct dentry *parent,
> +					u32 *array, u32 elements);
> +
>  bool debugfs_initialized(void);
>  
>  #else
> @@ -193,6 +197,13 @@ static inline bool debugfs_initialized(void)
>  	return false;
>  }
>  
> +struct dentry *debugfs_create_u32_array(const char *name, mode_t mode,
> +					struct dentry *parent,
> +					u32 *array, u32 elements)
> +{
> +	return ERR_PTR(-ENODEV);
> +}
> +
>  #endif
>  
>  #endif
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 12:36:56 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 12:36:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXuG9-0000Zn-Tu; Tue, 06 Dec 2011 12:36:33 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RXlio-0001xH-0d
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 03:29:34 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1323142127!7630000!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQyOTgzMw==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13445 invoked from network); 6 Dec 2011 03:28:48 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-2.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Dec 2011 03:28:48 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pB63SLsA010129
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 6 Dec 2011 03:28:22 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pB63SJdh016278
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 6 Dec 2011 03:28:19 GMT
Received: from abhmt119.oracle.com (abhmt119.oracle.com [141.146.116.71])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pB63SDgU031742; Mon, 5 Dec 2011 21:28:13 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 05 Dec 2011 19:28:13 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id ADE59416F9; Mon,  5 Dec 2011 22:27:41 -0500 (EST)
Date: Mon, 5 Dec 2011 22:27:41 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
Message-ID: <20111206032741.GF6647@phenom.dumpdata.com>
References: <20111130085921.23386.89708.sendpatchset@oc5400248562.ibm.com>
	<20111130090038.23386.4505.sendpatchset@oc5400248562.ibm.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20111130090038.23386.4505.sendpatchset@oc5400248562.ibm.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090202.4EDD8BD8.005B,ss=1,re=0.000,fgs=0
X-Mailman-Approved-At: Tue, 06 Dec 2011 12:36:31 +0000
Cc: Marcelo Tosatti <mtosatti@redhat.com>, Gleb Natapov <gleb@redhat.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>,
	Dave Jiang <dave.jiang@intel.com>, KVM <kvm@vger.kernel.org>,
	x86@kernel.org, Ingo Molnar <mingo@redhat.com>,
	Avi Kivity <avi@redhat.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Xen <xen-devel@lists.xensource.com>, Sasha Levin <levinsasha928@gmail.com>,
	Sedat Dilek <sedat.dilek@gmail.com>, Thomas Gleixner <tglx@linutronix.de>,
	Yinghai Lu <yinghai@kernel.org>, Greg Kroah-Hartman <gregkh@suse.de>,
	LKML <linux-kernel@vger.kernel.org>, Dave Hansen <dave@linux.vnet.ibm.com>,
	Suzuki Poulose <suzuki@linux.vnet.ibm.com>
Subject: Re: [Xen-devel] [PATCH RFC V3 4/4] kvm : pv-ticketlocks support for
 linux guests running on KVM hypervisor
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Nov 30, 2011 at 02:30:38PM +0530, Raghavendra K T wrote:
> This patch extends Linux guests running on KVM hypervisor to support
> pv-ticketlocks. 
> During smp_boot_cpus  paravirtualied KVM guest detects if the hypervisor has
> required feature (KVM_FEATURE_KICK_VCPU) to support pv-ticketlocks. If so,
>  support for pv-ticketlocks is registered via pv_lock_ops.
> 
> Signed-off-by: Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>
> Signed-off-by: Suzuki Poulose <suzuki@in.ibm.com>
> Signed-off-by: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
> ---
> diff --git a/arch/x86/include/asm/kvm_para.h b/arch/x86/include/asm/kvm_para.h
> index 8b1d65d..7e419ad 100644
> --- a/arch/x86/include/asm/kvm_para.h
> +++ b/arch/x86/include/asm/kvm_para.h
> @@ -195,10 +195,21 @@ void kvm_async_pf_task_wait(u32 token);
>  void kvm_async_pf_task_wake(u32 token);
>  u32 kvm_read_and_reset_pf_reason(void);
>  extern void kvm_disable_steal_time(void);
> -#else
> -#define kvm_guest_init() do { } while (0)
> +
> +#ifdef CONFIG_PARAVIRT_SPINLOCKS
> +void __init kvm_spinlock_init(void);
> +#else /* CONFIG_PARAVIRT_SPINLOCKS */
> +static void kvm_spinlock_init(void)
> +{
> +}
> +#endif /* CONFIG_PARAVIRT_SPINLOCKS */
> +
> +#else /* CONFIG_KVM_GUEST */
> +#define kvm_guest_init() do {} while (0)
>  #define kvm_async_pf_task_wait(T) do {} while(0)
>  #define kvm_async_pf_task_wake(T) do {} while(0)
> +#define kvm_spinlock_init() do {} while (0)
> +
>  static inline u32 kvm_read_and_reset_pf_reason(void)
>  {
>  	return 0;
> diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c
> index a9c2116..dffeea3 100644
> --- a/arch/x86/kernel/kvm.c
> +++ b/arch/x86/kernel/kvm.c
> @@ -33,6 +33,7 @@
>  #include <linux/sched.h>
>  #include <linux/slab.h>
>  #include <linux/kprobes.h>
> +#include <linux/debugfs.h>
>  #include <asm/timer.h>
>  #include <asm/cpu.h>
>  #include <asm/traps.h>
> @@ -545,6 +546,7 @@ static void __init kvm_smp_prepare_boot_cpu(void)
>  #endif
>  	kvm_guest_cpu_init();
>  	native_smp_prepare_boot_cpu();
> +	kvm_spinlock_init();
>  }
>  
>  static void __cpuinit kvm_guest_cpu_online(void *dummy)
> @@ -627,3 +629,248 @@ static __init int activate_jump_labels(void)
>  	return 0;
>  }
>  arch_initcall(activate_jump_labels);
> +
> +#ifdef CONFIG_PARAVIRT_SPINLOCKS
> +
> +enum kvm_contention_stat {
> +	TAKEN_SLOW,
> +	TAKEN_SLOW_PICKUP,
> +	RELEASED_SLOW,
> +	RELEASED_SLOW_KICKED,
> +	NR_CONTENTION_STATS
> +};
> +
> +#ifdef CONFIG_KVM_DEBUG_FS
> +
> +static struct kvm_spinlock_stats
> +{
> +	u32 contention_stats[NR_CONTENTION_STATS];
> +
> +#define HISTO_BUCKETS	30
> +	u32 histo_spin_blocked[HISTO_BUCKETS+1];
> +
> +	u64 time_blocked;
> +} spinlock_stats;
> +
> +static u8 zero_stats;
> +
> +static inline void check_zero(void)
> +{
> +	u8 ret;
> +	u8 old = ACCESS_ONCE(zero_stats);
> +	if (unlikely(old)) {
> +		ret = cmpxchg(&zero_stats, old, 0);
> +		/* This ensures only one fellow resets the stat */
> +		if (ret == old)
> +			memset(&spinlock_stats, 0, sizeof(spinlock_stats));
> +	}
> +}
> +
> +static inline void add_stats(enum kvm_contention_stat var, int val)

You probably want 'int val' to be 'u32 val' as that is the type
in contention_stats.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 12:36:56 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 12:36:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXuG9-0000Zn-Tu; Tue, 06 Dec 2011 12:36:33 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RXlio-0001xH-0d
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 03:29:34 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1323142127!7630000!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQyOTgzMw==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13445 invoked from network); 6 Dec 2011 03:28:48 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-2.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Dec 2011 03:28:48 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pB63SLsA010129
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 6 Dec 2011 03:28:22 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pB63SJdh016278
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 6 Dec 2011 03:28:19 GMT
Received: from abhmt119.oracle.com (abhmt119.oracle.com [141.146.116.71])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pB63SDgU031742; Mon, 5 Dec 2011 21:28:13 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 05 Dec 2011 19:28:13 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id ADE59416F9; Mon,  5 Dec 2011 22:27:41 -0500 (EST)
Date: Mon, 5 Dec 2011 22:27:41 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
Message-ID: <20111206032741.GF6647@phenom.dumpdata.com>
References: <20111130085921.23386.89708.sendpatchset@oc5400248562.ibm.com>
	<20111130090038.23386.4505.sendpatchset@oc5400248562.ibm.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20111130090038.23386.4505.sendpatchset@oc5400248562.ibm.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090202.4EDD8BD8.005B,ss=1,re=0.000,fgs=0
X-Mailman-Approved-At: Tue, 06 Dec 2011 12:36:31 +0000
Cc: Marcelo Tosatti <mtosatti@redhat.com>, Gleb Natapov <gleb@redhat.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>,
	Dave Jiang <dave.jiang@intel.com>, KVM <kvm@vger.kernel.org>,
	x86@kernel.org, Ingo Molnar <mingo@redhat.com>,
	Avi Kivity <avi@redhat.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Xen <xen-devel@lists.xensource.com>, Sasha Levin <levinsasha928@gmail.com>,
	Sedat Dilek <sedat.dilek@gmail.com>, Thomas Gleixner <tglx@linutronix.de>,
	Yinghai Lu <yinghai@kernel.org>, Greg Kroah-Hartman <gregkh@suse.de>,
	LKML <linux-kernel@vger.kernel.org>, Dave Hansen <dave@linux.vnet.ibm.com>,
	Suzuki Poulose <suzuki@linux.vnet.ibm.com>
Subject: Re: [Xen-devel] [PATCH RFC V3 4/4] kvm : pv-ticketlocks support for
 linux guests running on KVM hypervisor
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Nov 30, 2011 at 02:30:38PM +0530, Raghavendra K T wrote:
> This patch extends Linux guests running on KVM hypervisor to support
> pv-ticketlocks. 
> During smp_boot_cpus  paravirtualied KVM guest detects if the hypervisor has
> required feature (KVM_FEATURE_KICK_VCPU) to support pv-ticketlocks. If so,
>  support for pv-ticketlocks is registered via pv_lock_ops.
> 
> Signed-off-by: Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>
> Signed-off-by: Suzuki Poulose <suzuki@in.ibm.com>
> Signed-off-by: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
> ---
> diff --git a/arch/x86/include/asm/kvm_para.h b/arch/x86/include/asm/kvm_para.h
> index 8b1d65d..7e419ad 100644
> --- a/arch/x86/include/asm/kvm_para.h
> +++ b/arch/x86/include/asm/kvm_para.h
> @@ -195,10 +195,21 @@ void kvm_async_pf_task_wait(u32 token);
>  void kvm_async_pf_task_wake(u32 token);
>  u32 kvm_read_and_reset_pf_reason(void);
>  extern void kvm_disable_steal_time(void);
> -#else
> -#define kvm_guest_init() do { } while (0)
> +
> +#ifdef CONFIG_PARAVIRT_SPINLOCKS
> +void __init kvm_spinlock_init(void);
> +#else /* CONFIG_PARAVIRT_SPINLOCKS */
> +static void kvm_spinlock_init(void)
> +{
> +}
> +#endif /* CONFIG_PARAVIRT_SPINLOCKS */
> +
> +#else /* CONFIG_KVM_GUEST */
> +#define kvm_guest_init() do {} while (0)
>  #define kvm_async_pf_task_wait(T) do {} while(0)
>  #define kvm_async_pf_task_wake(T) do {} while(0)
> +#define kvm_spinlock_init() do {} while (0)
> +
>  static inline u32 kvm_read_and_reset_pf_reason(void)
>  {
>  	return 0;
> diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c
> index a9c2116..dffeea3 100644
> --- a/arch/x86/kernel/kvm.c
> +++ b/arch/x86/kernel/kvm.c
> @@ -33,6 +33,7 @@
>  #include <linux/sched.h>
>  #include <linux/slab.h>
>  #include <linux/kprobes.h>
> +#include <linux/debugfs.h>
>  #include <asm/timer.h>
>  #include <asm/cpu.h>
>  #include <asm/traps.h>
> @@ -545,6 +546,7 @@ static void __init kvm_smp_prepare_boot_cpu(void)
>  #endif
>  	kvm_guest_cpu_init();
>  	native_smp_prepare_boot_cpu();
> +	kvm_spinlock_init();
>  }
>  
>  static void __cpuinit kvm_guest_cpu_online(void *dummy)
> @@ -627,3 +629,248 @@ static __init int activate_jump_labels(void)
>  	return 0;
>  }
>  arch_initcall(activate_jump_labels);
> +
> +#ifdef CONFIG_PARAVIRT_SPINLOCKS
> +
> +enum kvm_contention_stat {
> +	TAKEN_SLOW,
> +	TAKEN_SLOW_PICKUP,
> +	RELEASED_SLOW,
> +	RELEASED_SLOW_KICKED,
> +	NR_CONTENTION_STATS
> +};
> +
> +#ifdef CONFIG_KVM_DEBUG_FS
> +
> +static struct kvm_spinlock_stats
> +{
> +	u32 contention_stats[NR_CONTENTION_STATS];
> +
> +#define HISTO_BUCKETS	30
> +	u32 histo_spin_blocked[HISTO_BUCKETS+1];
> +
> +	u64 time_blocked;
> +} spinlock_stats;
> +
> +static u8 zero_stats;
> +
> +static inline void check_zero(void)
> +{
> +	u8 ret;
> +	u8 old = ACCESS_ONCE(zero_stats);
> +	if (unlikely(old)) {
> +		ret = cmpxchg(&zero_stats, old, 0);
> +		/* This ensures only one fellow resets the stat */
> +		if (ret == old)
> +			memset(&spinlock_stats, 0, sizeof(spinlock_stats));
> +	}
> +}
> +
> +static inline void add_stats(enum kvm_contention_stat var, int val)

You probably want 'int val' to be 'u32 val' as that is the type
in contention_stats.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 12:37:01 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 12:37:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXuGA-0000Zu-AV; Tue, 06 Dec 2011 12:36:34 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raghukt@linux.vnet.ibm.com>) id 1RXovl-0003hK-GY
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 06:55:09 +0000
X-Env-Sender: raghukt@linux.vnet.ibm.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1323154437!43693490!1
X-Originating-IP: [122.248.162.2]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTIyLjI0OC4xNjIuMiA9PiAxODcyNjM=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18666 invoked from network); 6 Dec 2011 06:54:00 -0000
Received: from e28smtp02.in.ibm.com (HELO e28smtp02.in.ibm.com) (122.248.162.2)
	by server-12.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Dec 2011 06:54:00 -0000
Received: from /spool/local
	by e28smtp02.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use
	Only! Violators will be prosecuted
	for <xen-devel@lists.xensource.com> from <raghukt@linux.vnet.ibm.com>; 
	Tue, 6 Dec 2011 12:24:20 +0530
Received: from d28relay02.in.ibm.com (9.184.220.59)
	by e28smtp02.in.ibm.com (192.168.1.132) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Tue, 6 Dec 2011 12:24:09 +0530
Received: from d28av05.in.ibm.com (d28av05.in.ibm.com [9.184.220.67])
	by d28relay02.in.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	pB66s8511589398
	for <xen-devel@lists.xensource.com>; Tue, 6 Dec 2011 12:24:08 +0530
Received: from d28av05.in.ibm.com (loopback [127.0.0.1])
	by d28av05.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id
	pB66s6cu013477
	for <xen-devel@lists.xensource.com>; Tue, 6 Dec 2011 17:54:07 +1100
Received: from oc5400248562.ibm.com (oc5400248562.in.ibm.com [9.124.35.17])
	by d28av05.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	pB66s6Uj013463; Tue, 6 Dec 2011 17:54:06 +1100
Message-ID: <4EDDBC0D.5090602@linux.vnet.ibm.com>
Date: Tue, 06 Dec 2011 12:24:05 +0530
From: Raghavendra K T <raghukt@linux.vnet.ibm.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
	rv:1.9.2.24) Gecko/20111108 Fedora/3.1.16-1.fc14 Thunderbird/3.1.16
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <20111130085921.23386.89708.sendpatchset@oc5400248562.ibm.com>
	<20111130090038.23386.4505.sendpatchset@oc5400248562.ibm.com>
	<20111206032741.GF6647@phenom.dumpdata.com>
In-Reply-To: <20111206032741.GF6647@phenom.dumpdata.com>
x-cbid: 11120606-5816-0000-0000-0000005422AF
X-Mailman-Approved-At: Tue, 06 Dec 2011 12:36:31 +0000
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	Gleb Natapov <gleb@redhat.com>, Peter Zijlstra <peterz@infradead.org>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>,
	Dave Jiang <dave.jiang@intel.com>, KVM <kvm@vger.kernel.org>,
	x86@kernel.org, Ingo Molnar <mingo@redhat.com>,
	Avi Kivity <avi@redhat.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Marcelo Tosatti <mtosatti@redhat.com>, Xen <xen-devel@lists.xensource.com>,
	Sasha Levin <levinsasha928@gmail.com>, Sedat Dilek <sedat.dilek@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>, Yinghai Lu <yinghai@kernel.org>,
	Greg Kroah-Hartman <gregkh@suse.de>, LKML <linux-kernel@vger.kernel.org>,
	Dave Hansen <dave@linux.vnet.ibm.com>,
	Suzuki Poulose <suzuki@linux.vnet.ibm.com>
Subject: Re: [Xen-devel] [PATCH RFC V3 4/4] kvm : pv-ticketlocks support for
 linux guests running on KVM hypervisor
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 12/06/2011 08:57 AM, Konrad Rzeszutek Wilk wrote:
>> +static inline void add_stats(enum kvm_contention_stat var, int val)
>
> You probably want 'int val' to be 'u32 val' as that is the type
> in contention_stats.
>

Yes. Thanks for pointing, as its cumulative.   It is indeed u32 in #else 
:).I 'll change that.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 12:37:01 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 12:37:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXuGA-0000Zu-AV; Tue, 06 Dec 2011 12:36:34 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raghukt@linux.vnet.ibm.com>) id 1RXovl-0003hK-GY
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 06:55:09 +0000
X-Env-Sender: raghukt@linux.vnet.ibm.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1323154437!43693490!1
X-Originating-IP: [122.248.162.2]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTIyLjI0OC4xNjIuMiA9PiAxODcyNjM=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18666 invoked from network); 6 Dec 2011 06:54:00 -0000
Received: from e28smtp02.in.ibm.com (HELO e28smtp02.in.ibm.com) (122.248.162.2)
	by server-12.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Dec 2011 06:54:00 -0000
Received: from /spool/local
	by e28smtp02.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use
	Only! Violators will be prosecuted
	for <xen-devel@lists.xensource.com> from <raghukt@linux.vnet.ibm.com>; 
	Tue, 6 Dec 2011 12:24:20 +0530
Received: from d28relay02.in.ibm.com (9.184.220.59)
	by e28smtp02.in.ibm.com (192.168.1.132) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Tue, 6 Dec 2011 12:24:09 +0530
Received: from d28av05.in.ibm.com (d28av05.in.ibm.com [9.184.220.67])
	by d28relay02.in.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	pB66s8511589398
	for <xen-devel@lists.xensource.com>; Tue, 6 Dec 2011 12:24:08 +0530
Received: from d28av05.in.ibm.com (loopback [127.0.0.1])
	by d28av05.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id
	pB66s6cu013477
	for <xen-devel@lists.xensource.com>; Tue, 6 Dec 2011 17:54:07 +1100
Received: from oc5400248562.ibm.com (oc5400248562.in.ibm.com [9.124.35.17])
	by d28av05.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	pB66s6Uj013463; Tue, 6 Dec 2011 17:54:06 +1100
Message-ID: <4EDDBC0D.5090602@linux.vnet.ibm.com>
Date: Tue, 06 Dec 2011 12:24:05 +0530
From: Raghavendra K T <raghukt@linux.vnet.ibm.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
	rv:1.9.2.24) Gecko/20111108 Fedora/3.1.16-1.fc14 Thunderbird/3.1.16
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <20111130085921.23386.89708.sendpatchset@oc5400248562.ibm.com>
	<20111130090038.23386.4505.sendpatchset@oc5400248562.ibm.com>
	<20111206032741.GF6647@phenom.dumpdata.com>
In-Reply-To: <20111206032741.GF6647@phenom.dumpdata.com>
x-cbid: 11120606-5816-0000-0000-0000005422AF
X-Mailman-Approved-At: Tue, 06 Dec 2011 12:36:31 +0000
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	Gleb Natapov <gleb@redhat.com>, Peter Zijlstra <peterz@infradead.org>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>,
	Dave Jiang <dave.jiang@intel.com>, KVM <kvm@vger.kernel.org>,
	x86@kernel.org, Ingo Molnar <mingo@redhat.com>,
	Avi Kivity <avi@redhat.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Marcelo Tosatti <mtosatti@redhat.com>, Xen <xen-devel@lists.xensource.com>,
	Sasha Levin <levinsasha928@gmail.com>, Sedat Dilek <sedat.dilek@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>, Yinghai Lu <yinghai@kernel.org>,
	Greg Kroah-Hartman <gregkh@suse.de>, LKML <linux-kernel@vger.kernel.org>,
	Dave Hansen <dave@linux.vnet.ibm.com>,
	Suzuki Poulose <suzuki@linux.vnet.ibm.com>
Subject: Re: [Xen-devel] [PATCH RFC V3 4/4] kvm : pv-ticketlocks support for
 linux guests running on KVM hypervisor
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 12/06/2011 08:57 AM, Konrad Rzeszutek Wilk wrote:
>> +static inline void add_stats(enum kvm_contention_stat var, int val)
>
> You probably want 'int val' to be 'u32 val' as that is the type
> in contention_stats.
>

Yes. Thanks for pointing, as its cumulative.   It is indeed u32 in #else 
:).I 'll change that.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 12:40:25 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 12:40:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXuJi-0001LM-MN; Tue, 06 Dec 2011 12:40:15 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <juergen.gross@ts.fujitsu.com>) id 1RXuJh-0001KA-4u
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 12:40:13 +0000
X-Env-Sender: juergen.gross@ts.fujitsu.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1323175131!49675291!1
X-Originating-IP: [80.70.172.49]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNzAuMTcyLjQ5ID0+IDIzNzk3Nw==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10387 invoked from network); 6 Dec 2011 12:38:51 -0000
Received: from dgate10.ts.fujitsu.com (HELO dgate10.ts.fujitsu.com)
	(80.70.172.49)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Dec 2011 12:38:51 -0000
DomainKey-Signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns;
	h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV:
	Received:Received:Message-ID:Date:From:Organization:
	User-Agent:MIME-Version:To:CC:Subject:References:
	In-Reply-To:Content-Type:Content-Transfer-Encoding;
	b=Qs0kSE3bOp+vuMr62SdZ2zTcb6H8h9Uu8CImh6k5eSnrKI+MO/mWnYHg
	aoEhPpu56lKljJm6cHWDUd/2edcTjRhuaWNXml6upldfM1zZczTYVfwdN
	ohEogdB9ytTg7rNSYRLXf8+j8VTyAAX9kTMWTH8qDHd2FUhZS45bd1nSr
	/B20suthHPQ3cKurZ2o3gciOIkwYmdBH9Ys7jxFhEls+QbpdNt77jmbQd
	J9pB36YTYQoQ4q025K/KVhv1H7GsY;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=ts.fujitsu.com; i=juergen.gross@ts.fujitsu.com;
	q=dns/txt; s=s1536b; t=1323175167; x=1354711167;
	h=message-id:date:from:mime-version:to:cc:subject:
	references:in-reply-to:content-transfer-encoding;
	bh=7tMdrAEARQmeAD2PiqG9J9N00SY6FSmhMlHTpNemjTA=;
	b=Bz2CWpgrUjtVwcnmlfB9L5OO3IaVeYQi1Y4FY8N9LN7bkcYKmq5Vx2P4
	X9zHBD4C9kvfTe5AaBfCR9bLTzOBM0zEg8LIaNiAfqD/edIqGZFXom4bq
	AIBqUZc5ZVoEkDGWcvVKxNEYdGDy0nXD8ITv1X9ssll+m+x6CPSZQAnqf
	Ecd4zqBhB8sXaWe4cKYt2cIAnbkO7TCbDRDlLSMGyznXOoIH+H9o3z5de
	3uPCT7CTVU9zz2v7dCugjom2W3/Kl;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.71,304,1320620400"; d="scan'208";a="95140365"
Received: from abgdgate30u.abg.fsc.net ([172.25.138.66])
	by dgate10u.abg.fsc.net with ESMTP; 06 Dec 2011 13:39:27 +0100
X-IronPort-AV: E=Sophos;i="4.71,304,1320620400"; d="scan'208";a="124474940"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdgate30u.abg.fsc.net with ESMTP; 06 Dec 2011 13:39:27 +0100
Received: from [172.17.21.50] (verdon.osd.mch.fsc.net [172.17.21.50])
	by sanpedro.mch.fsc.net (Postfix) with ESMTP id 25D6662DD33;
	Tue,  6 Dec 2011 13:39:27 +0100 (CET)
Message-ID: <4EDE0CFF.3000203@ts.fujitsu.com>
Date: Tue, 06 Dec 2011 13:39:27 +0100
From: Juergen Gross <juergen.gross@ts.fujitsu.com>
Organization: Fujitsu Technology Solutions
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.24) Gecko/20111114 Iceowl/1.0b2 Icedove/3.1.16
MIME-Version: 1.0
To: George Dunlap <George.Dunlap@eu.citrix.com>
References: <1322060131.30168.15.camel@Abyss> <4EDDD485.70208@ts.fujitsu.com>
	<CAFLBxZao_zmfjnKisp+mQee62RhjFVRsvqy_pKP5V5oqzTBzEw@mail.gmail.com>
In-Reply-To: <CAFLBxZao_zmfjnKisp+mQee62RhjFVRsvqy_pKP5V5oqzTBzEw@mail.gmail.com>
Cc: Dario Faggioli <raistlin@linux.it>, xen-devel@lists.xensource.com,
	Keir Fraser <keir@xen.org>
Subject: Re: [Xen-devel] [RFC/RFT][PATCH 0 of 3] rework locking
	in	sched_adjust
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 12/06/2011 01:30 PM, George Dunlap wrote:
> On Tue, Dec 6, 2011 at 8:38 AM, Juergen Gross
> <juergen.gross@ts.fujitsu.com>  wrote:
>> (XEN) Xen BUG at spinlock.c:47
> [snip]
>> (XEN) Xen call trace:
>> (XEN)    [<ffff82c480124e84>] check_lock+0x44/0x50
>> (XEN)    [<ffff82c480124ec1>] _spin_lock+0x11/0x5d
>> (XEN)    [<ffff82c48012c085>] xmem_pool_alloc+0x138/0x4d2
>> (XEN)    [<ffff82c48012c557>] _xmalloc+0x138/0x230
>> (XEN)    [<ffff82c48012c660>] _xzalloc+0x11/0x2d
>> (XEN)    [<ffff82c48011f8ab>] sedf_adjust+0x37c/0x9b2
>> (XEN)    [<ffff82c480120fec>] sched_adjust+0x5f/0xb7
>> (XEN)    [<ffff82c4801037e3>] do_domctl+0xf32/0x1a9f
>> (XEN)    [<ffff82c48021f128>] syscall_enter+0xc8/0x122
> Hmm, looks like the problem is that we assert that locks must be
> called with IRQs enabled all the time, or never.  From
> xen/common/spinlock.c:
>
>       * We partition locks into IRQ-safe (always held with IRQs disabled) and
>       * IRQ-unsafe (always held with IRQs enabled) types. The convention for
>       * every lock must be consistently observed else we can deadlock in
>       * IRQ-context rendezvous functions (a rendezvous which gets every CPU
>       * into IRQ context before any CPU is released from the rendezvous).
>
> sedf_adj() grabs the private lock with irqs disabled, then calls
> sedf_adjust_weights(), which calls xmalloc to allocate some local
> scratch space, which ultimately grabs a non-IRQ spinlock.
>
> Not sure the best thing to do here...
sedf_adjust_weights() is called only from sedf_adj(). The easiest solution
would be to xmalloc the scratch space in sedf_adj() before grabbing the lock
and passing the xmalloced area to sedf_adjust_weights().


Juergen

-- 
Juergen Gross                 Principal Developer Operating Systems
PDG ES&S SWE OS6                       Telephone: +49 (0) 89 3222 2967
Fujitsu Technology Solutions              e-mail: juergen.gross@ts.fujitsu.com
Domagkstr. 28                           Internet: ts.fujitsu.com
D-80807 Muenchen                 Company details: ts.fujitsu.com/imprint.html


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 12:40:25 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 12:40:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXuJi-0001LM-MN; Tue, 06 Dec 2011 12:40:15 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <juergen.gross@ts.fujitsu.com>) id 1RXuJh-0001KA-4u
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 12:40:13 +0000
X-Env-Sender: juergen.gross@ts.fujitsu.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1323175131!49675291!1
X-Originating-IP: [80.70.172.49]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNzAuMTcyLjQ5ID0+IDIzNzk3Nw==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10387 invoked from network); 6 Dec 2011 12:38:51 -0000
Received: from dgate10.ts.fujitsu.com (HELO dgate10.ts.fujitsu.com)
	(80.70.172.49)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Dec 2011 12:38:51 -0000
DomainKey-Signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns;
	h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV:
	Received:Received:Message-ID:Date:From:Organization:
	User-Agent:MIME-Version:To:CC:Subject:References:
	In-Reply-To:Content-Type:Content-Transfer-Encoding;
	b=Qs0kSE3bOp+vuMr62SdZ2zTcb6H8h9Uu8CImh6k5eSnrKI+MO/mWnYHg
	aoEhPpu56lKljJm6cHWDUd/2edcTjRhuaWNXml6upldfM1zZczTYVfwdN
	ohEogdB9ytTg7rNSYRLXf8+j8VTyAAX9kTMWTH8qDHd2FUhZS45bd1nSr
	/B20suthHPQ3cKurZ2o3gciOIkwYmdBH9Ys7jxFhEls+QbpdNt77jmbQd
	J9pB36YTYQoQ4q025K/KVhv1H7GsY;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=ts.fujitsu.com; i=juergen.gross@ts.fujitsu.com;
	q=dns/txt; s=s1536b; t=1323175167; x=1354711167;
	h=message-id:date:from:mime-version:to:cc:subject:
	references:in-reply-to:content-transfer-encoding;
	bh=7tMdrAEARQmeAD2PiqG9J9N00SY6FSmhMlHTpNemjTA=;
	b=Bz2CWpgrUjtVwcnmlfB9L5OO3IaVeYQi1Y4FY8N9LN7bkcYKmq5Vx2P4
	X9zHBD4C9kvfTe5AaBfCR9bLTzOBM0zEg8LIaNiAfqD/edIqGZFXom4bq
	AIBqUZc5ZVoEkDGWcvVKxNEYdGDy0nXD8ITv1X9ssll+m+x6CPSZQAnqf
	Ecd4zqBhB8sXaWe4cKYt2cIAnbkO7TCbDRDlLSMGyznXOoIH+H9o3z5de
	3uPCT7CTVU9zz2v7dCugjom2W3/Kl;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.71,304,1320620400"; d="scan'208";a="95140365"
Received: from abgdgate30u.abg.fsc.net ([172.25.138.66])
	by dgate10u.abg.fsc.net with ESMTP; 06 Dec 2011 13:39:27 +0100
X-IronPort-AV: E=Sophos;i="4.71,304,1320620400"; d="scan'208";a="124474940"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdgate30u.abg.fsc.net with ESMTP; 06 Dec 2011 13:39:27 +0100
Received: from [172.17.21.50] (verdon.osd.mch.fsc.net [172.17.21.50])
	by sanpedro.mch.fsc.net (Postfix) with ESMTP id 25D6662DD33;
	Tue,  6 Dec 2011 13:39:27 +0100 (CET)
Message-ID: <4EDE0CFF.3000203@ts.fujitsu.com>
Date: Tue, 06 Dec 2011 13:39:27 +0100
From: Juergen Gross <juergen.gross@ts.fujitsu.com>
Organization: Fujitsu Technology Solutions
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.24) Gecko/20111114 Iceowl/1.0b2 Icedove/3.1.16
MIME-Version: 1.0
To: George Dunlap <George.Dunlap@eu.citrix.com>
References: <1322060131.30168.15.camel@Abyss> <4EDDD485.70208@ts.fujitsu.com>
	<CAFLBxZao_zmfjnKisp+mQee62RhjFVRsvqy_pKP5V5oqzTBzEw@mail.gmail.com>
In-Reply-To: <CAFLBxZao_zmfjnKisp+mQee62RhjFVRsvqy_pKP5V5oqzTBzEw@mail.gmail.com>
Cc: Dario Faggioli <raistlin@linux.it>, xen-devel@lists.xensource.com,
	Keir Fraser <keir@xen.org>
Subject: Re: [Xen-devel] [RFC/RFT][PATCH 0 of 3] rework locking
	in	sched_adjust
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 12/06/2011 01:30 PM, George Dunlap wrote:
> On Tue, Dec 6, 2011 at 8:38 AM, Juergen Gross
> <juergen.gross@ts.fujitsu.com>  wrote:
>> (XEN) Xen BUG at spinlock.c:47
> [snip]
>> (XEN) Xen call trace:
>> (XEN)    [<ffff82c480124e84>] check_lock+0x44/0x50
>> (XEN)    [<ffff82c480124ec1>] _spin_lock+0x11/0x5d
>> (XEN)    [<ffff82c48012c085>] xmem_pool_alloc+0x138/0x4d2
>> (XEN)    [<ffff82c48012c557>] _xmalloc+0x138/0x230
>> (XEN)    [<ffff82c48012c660>] _xzalloc+0x11/0x2d
>> (XEN)    [<ffff82c48011f8ab>] sedf_adjust+0x37c/0x9b2
>> (XEN)    [<ffff82c480120fec>] sched_adjust+0x5f/0xb7
>> (XEN)    [<ffff82c4801037e3>] do_domctl+0xf32/0x1a9f
>> (XEN)    [<ffff82c48021f128>] syscall_enter+0xc8/0x122
> Hmm, looks like the problem is that we assert that locks must be
> called with IRQs enabled all the time, or never.  From
> xen/common/spinlock.c:
>
>       * We partition locks into IRQ-safe (always held with IRQs disabled) and
>       * IRQ-unsafe (always held with IRQs enabled) types. The convention for
>       * every lock must be consistently observed else we can deadlock in
>       * IRQ-context rendezvous functions (a rendezvous which gets every CPU
>       * into IRQ context before any CPU is released from the rendezvous).
>
> sedf_adj() grabs the private lock with irqs disabled, then calls
> sedf_adjust_weights(), which calls xmalloc to allocate some local
> scratch space, which ultimately grabs a non-IRQ spinlock.
>
> Not sure the best thing to do here...
sedf_adjust_weights() is called only from sedf_adj(). The easiest solution
would be to xmalloc the scratch space in sedf_adj() before grabbing the lock
and passing the xmalloced area to sedf_adjust_weights().


Juergen

-- 
Juergen Gross                 Principal Developer Operating Systems
PDG ES&S SWE OS6                       Telephone: +49 (0) 89 3222 2967
Fujitsu Technology Solutions              e-mail: juergen.gross@ts.fujitsu.com
Domagkstr. 28                           Internet: ts.fujitsu.com
D-80807 Muenchen                 Company details: ts.fujitsu.com/imprint.html


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 13:00:35 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 13:00:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXud6-00028y-8Z; Tue, 06 Dec 2011 13:00:16 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RXud5-00028q-MQ
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 13:00:15 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1323176369!6087746!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjM3Ng==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27193 invoked from network); 6 Dec 2011 12:59:29 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Dec 2011 12:59:29 -0000
X-IronPort-AV: E=Sophos;i="4.71,305,1320624000"; 
   d="scan'208";a="9318948"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Dec 2011 12:59:29 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 6 Dec 2011 12:59:29 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RXucL-0001iu-5A; Tue, 06 Dec 2011 12:59:29 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RXucL-0002G1-2Z;
	Tue, 06 Dec 2011 12:59:29 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20190.4529.64404.682257@mariner.uk.xensource.com>
Date: Tue, 6 Dec 2011 12:59:29 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1323164897.23681.27.camel@zakaz.uk.xensource.com>
References: <1322499580-2322-1-git-send-email-ian.jackson@eu.citrix.com>
	<1322499580-2322-13-git-send-email-ian.jackson@eu.citrix.com>
	<1323164897.23681.27.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 12/13] libxl: New API for providing OS
 events to libxl
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("Re: [Xen-devel] [PATCH 12/13] libxl: New API for providing OS events to libxl"):
> On Mon, 2011-11-28 at 16:59 +0000, Ian Jackson wrote:
> > @@ -89,10 +99,25 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
> > 
> >  int libxl_ctx_free(libxl_ctx *ctx)
> >  {
> > +    int i;
> > +    GC_INIT(ctx);
> 
> You never call GC_FREE in this function. It's a bit of an odd one to
> need in the free function I guess but I think you still need it after
> the last call to a function which takes a gc argument?

Yes, you are right.

Also this function failed to free(ctx), so I have added (in my tree)
another patch to this series to do that.

> > +    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_LIST_EMPTY(&ctx->efds));
> > +    assert(LIBXL_TAILQ_EMPTY(&ctx->etimes));
> 
> Am I right that libxl__ev_fd_deregister is what ensures this is the
> case? If not then who is responsible for unregistering akk events before
> freeing a context?

libxl is supposed to do this.  In this patch, the only consumer of
events is the watch machinery.  But in the next patch, consumers
inside libxl of events are supposed to deregister them in
libxl_ctx_free.

I have added some comments to this effect in this and the subsequent
patch.

Also, while looking at this area it turns out that I wasn't doing this
deregistration properly for disk events, and that libxl_ctx_free
leaked events which had occurred but not been reported.  I have fixed
these too.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 13:00:35 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 13:00:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXud6-00028y-8Z; Tue, 06 Dec 2011 13:00:16 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RXud5-00028q-MQ
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 13:00:15 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1323176369!6087746!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjM3Ng==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27193 invoked from network); 6 Dec 2011 12:59:29 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Dec 2011 12:59:29 -0000
X-IronPort-AV: E=Sophos;i="4.71,305,1320624000"; 
   d="scan'208";a="9318948"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Dec 2011 12:59:29 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 6 Dec 2011 12:59:29 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RXucL-0001iu-5A; Tue, 06 Dec 2011 12:59:29 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RXucL-0002G1-2Z;
	Tue, 06 Dec 2011 12:59:29 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20190.4529.64404.682257@mariner.uk.xensource.com>
Date: Tue, 6 Dec 2011 12:59:29 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1323164897.23681.27.camel@zakaz.uk.xensource.com>
References: <1322499580-2322-1-git-send-email-ian.jackson@eu.citrix.com>
	<1322499580-2322-13-git-send-email-ian.jackson@eu.citrix.com>
	<1323164897.23681.27.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 12/13] libxl: New API for providing OS
 events to libxl
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("Re: [Xen-devel] [PATCH 12/13] libxl: New API for providing OS events to libxl"):
> On Mon, 2011-11-28 at 16:59 +0000, Ian Jackson wrote:
> > @@ -89,10 +99,25 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
> > 
> >  int libxl_ctx_free(libxl_ctx *ctx)
> >  {
> > +    int i;
> > +    GC_INIT(ctx);
> 
> You never call GC_FREE in this function. It's a bit of an odd one to
> need in the free function I guess but I think you still need it after
> the last call to a function which takes a gc argument?

Yes, you are right.

Also this function failed to free(ctx), so I have added (in my tree)
another patch to this series to do that.

> > +    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_LIST_EMPTY(&ctx->efds));
> > +    assert(LIBXL_TAILQ_EMPTY(&ctx->etimes));
> 
> Am I right that libxl__ev_fd_deregister is what ensures this is the
> case? If not then who is responsible for unregistering akk events before
> freeing a context?

libxl is supposed to do this.  In this patch, the only consumer of
events is the watch machinery.  But in the next patch, consumers
inside libxl of events are supposed to deregister them in
libxl_ctx_free.

I have added some comments to this effect in this and the subsequent
patch.

Also, while looking at this area it turns out that I wasn't doing this
deregistration properly for disk events, and that libxl_ctx_free
leaked events which had occurred but not been reported.  I have fixed
these too.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 13:17:47 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 13:17:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXuta-0002QQ-UF; Tue, 06 Dec 2011 13:17:18 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RXutY-0002QL-UO
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 13:17:17 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1323177390!6115362!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM3Mzk=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7245 invoked from network); 6 Dec 2011 13:16:30 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-5.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 6 Dec 2011 13:16:30 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 06 Dec 2011 13:16:30 +0000
Message-Id: <4EDE23E90200007800065B06@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 06 Dec 2011 13:17:13 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part240BB9C9.0__="
Subject: [Xen-devel] [PATCH linux-2.6.18/ACPI: eliminate restriction on ACPI
 processor ID range
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__Part240BB9C9.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Rather than storing the reference acpi_device pointers in an ACPI-ID-
indexed array (and having a bogus BUG_ON() check on a platform provided
value), use a radix tree instead.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/drivers/acpi/processor_core.c
+++ b/drivers/acpi/processor_core.c
@@ -513,7 +513,14 @@ static int acpi_processor_get_info(struc
 	return 0;
 }
=20
-static void *processor_device_array[NR_ACPI_CPUS];
+#ifndef CONFIG_XEN
+static void *processor_device_array[NR_CPUS];
+#else
+#include <linux/mutex.h>
+#include <linux/radix-tree.h>
+static DEFINE_MUTEX(processor_device_mutex);
+static RADIX_TREE(processor_device_tree, GFP_KERNEL);
+#endif
=20
 static int acpi_processor_start(struct acpi_device *device)
 {
@@ -541,9 +548,20 @@ static int __cpuinit acpi_processor_add(
 	 * Don't trust it blindly
 	 */
 #ifdef CONFIG_XEN
-	BUG_ON(pr->acpi_id >=3D NR_ACPI_CPUS);
-	if (processor_device_array[pr->acpi_id] !=3D NULL &&
-	    processor_device_array[pr->acpi_id] !=3D (void *)device) {
+	mutex_lock(&processor_device_mutex);
+	result =3D radix_tree_insert(&processor_device_tree,
+				   pr->acpi_id, device);
+	switch (result) {
+	default:
+		goto end_unlock;
+	case -EEXIST:
+		if (radix_tree_lookup(&processor_device_tree,
+				      pr->acpi_id) =3D=3D device) {
+	case 0:
+			mutex_unlock(&processor_device_mutex);
+			break;
+		}
+		mutex_unlock(&processor_device_mutex);
 #else
 	if (processor_device_array[pr->id] !=3D NULL &&
 	    processor_device_array[pr->id] !=3D (void *)device) {
@@ -553,14 +571,11 @@ static int __cpuinit acpi_processor_add(
 		return -ENODEV;
 	}
 #ifdef CONFIG_XEN
-	processor_device_array[pr->acpi_id] =3D (void *)device;
 	if (pr->id !=3D -1)
-		processors[pr->id] =3D pr;
 #else
 	processor_device_array[pr->id] =3D (void *)device;
-
-	processors[pr->id] =3D pr;
 #endif /* CONFIG_XEN */
+	processors[pr->id] =3D pr;
=20
 	result =3D acpi_processor_add_fs(device);
 	if (result)
@@ -602,6 +617,14 @@ err_thermal_unregister:
 	}
=20
       end:
+#ifdef CONFIG_XEN
+	mutex_lock(&processor_device_mutex);
+	if (radix_tree_lookup(&processor_device_tree,
+			      pr->acpi_id) =3D=3D device)
+		radix_tree_delete(&processor_device_tree, pr->acpi_id);
+      end_unlock:
+	mutex_unlock(&processor_device_mutex);
+#endif
=20
 	return result;
 }
@@ -692,10 +715,8 @@ static int acpi_processor_remove(struct=20
=20
 #ifdef CONFIG_XEN
 	if (pr->id !=3D -1)
-		processors[pr->id] =3D NULL;
-#else
+#endif
 	processors[pr->id] =3D NULL;
-#endif /* CONFIG_XEN */
=20
=20
 	kfree(pr);
@@ -992,6 +1013,30 @@ static void __exit acpi_processor_exit(v
=20
 	remove_proc_entry(ACPI_PROCESSOR_CLASS, acpi_root_dir);
=20
+#ifdef CONFIG_XEN
+	{
+		struct acpi_device *dev;
+		unsigned int idx =3D 0;
+
+		while (radix_tree_gang_lookup(&processor_device_tree,
+					      (void **)&dev, idx, 1)) {
+			struct acpi_processor *pr =3D acpi_driver_data(dev)=
;
+
+			/* prevent live lock */
+			if (pr->acpi_id < idx) {
+				printk(KERN_WARNING PREFIX "ID %u =
unexpected"
+				       " (less than %u); leaking memory\n",=

+				       pr->acpi_id, idx);
+				break;
+			}
+			idx =3D pr->acpi_id;
+			radix_tree_delete(&processor_device_tree, idx);
+			if (!++idx)
+				break;
+		}
+	}
+#endif
+
 	return;
 }
=20
--- a/include/acpi/processor.h
+++ b/include/acpi/processor.h
@@ -24,12 +24,6 @@
 #define ACPI_TSD_REV0_REVISION		0	/* Support for _PSD as in =
ACPI 3.0 */
 #define ACPI_TSD_REV0_ENTRIES		5
=20
-#ifdef CONFIG_XEN
-#define NR_ACPI_CPUS			(NR_CPUS < 256 ? 256 : NR_CPUS)
-#else
-#define NR_ACPI_CPUS			NR_CPUS
-#endif /* CONFIG_XEN */
-
 /*
  * Types of coordination defined in ACPI 3.0. Same macros can be used =
across
  * P, C and T states




--=__Part240BB9C9.0__=
Content-Type: text/plain; name="xen-acpi-processor-limit.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="xen-acpi-processor-limit.patch"

ACPI: eliminate restriction on ACPI processor ID range=0A=0ARather than =
storing the reference acpi_device pointers in an ACPI-ID-=0Aindexed array =
(and having a bogus BUG_ON() check on a platform provided=0Avalue), use a =
radix tree instead.=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=0A=
=0A--- a/drivers/acpi/processor_core.c=0A+++ b/drivers/acpi/processor_core.=
c=0A@@ -513,7 +513,14 @@ static int acpi_processor_get_info(struc=0A 	=
return 0;=0A }=0A =0A-static void *processor_device_array[NR_ACPI_CPUS];=0A=
+#ifndef CONFIG_XEN=0A+static void *processor_device_array[NR_CPUS];=0A+#el=
se=0A+#include <linux/mutex.h>=0A+#include <linux/radix-tree.h>=0A+static =
DEFINE_MUTEX(processor_device_mutex);=0A+static RADIX_TREE(processor_device=
_tree, GFP_KERNEL);=0A+#endif=0A =0A static int acpi_processor_start(struct=
 acpi_device *device)=0A {=0A@@ -541,9 +548,20 @@ static int __cpuinit =
acpi_processor_add(=0A 	 * Don't trust it blindly=0A 	 */=0A #ifdef =
CONFIG_XEN=0A-	BUG_ON(pr->acpi_id >=3D NR_ACPI_CPUS);=0A-	if =
(processor_device_array[pr->acpi_id] !=3D NULL &&=0A-	    processor_devic=
e_array[pr->acpi_id] !=3D (void *)device) {=0A+	mutex_lock(&processor_devic=
e_mutex);=0A+	result =3D radix_tree_insert(&processor_device_tree,=0A+	=
			   pr->acpi_id, device);=0A+	switch (result) =
{=0A+	default:=0A+		goto end_unlock;=0A+	case -EEXIST:=0A+	=
	if (radix_tree_lookup(&processor_device_tree,=0A+			=
	      pr->acpi_id) =3D=3D device) {=0A+	case 0:=0A+			=
mutex_unlock(&processor_device_mutex);=0A+			break;=0A+	=
	}=0A+		mutex_unlock(&processor_device_mutex);=0A #else=0A =
	if (processor_device_array[pr->id] !=3D NULL &&=0A 	    =
processor_device_array[pr->id] !=3D (void *)device) {=0A@@ -553,14 +571,11 =
@@ static int __cpuinit acpi_processor_add(=0A 		return -ENODEV;=0A =
	}=0A #ifdef CONFIG_XEN=0A-	processor_device_array[pr->acpi_id]=
 =3D (void *)device;=0A 	if (pr->id !=3D -1)=0A-		processors[=
pr->id] =3D pr;=0A #else=0A 	processor_device_array[pr->id] =3D (void =
*)device;=0A-=0A-	processors[pr->id] =3D pr;=0A #endif /* CONFIG_XEN =
*/=0A+	processors[pr->id] =3D pr;=0A =0A 	result =3D acpi_processor_a=
dd_fs(device);=0A 	if (result)=0A@@ -602,6 +617,14 @@ err_thermal_unre=
gister:=0A 	}=0A =0A       end:=0A+#ifdef CONFIG_XEN=0A+	mutex_lock(=
&processor_device_mutex);=0A+	if (radix_tree_lookup(&processor_device_tre=
e,=0A+			      pr->acpi_id) =3D=3D device)=0A+		=
radix_tree_delete(&processor_device_tree, pr->acpi_id);=0A+      end_unlock=
:=0A+	mutex_unlock(&processor_device_mutex);=0A+#endif=0A =0A 	=
return result;=0A }=0A@@ -692,10 +715,8 @@ static int acpi_processor_remove=
(struct =0A =0A #ifdef CONFIG_XEN=0A 	if (pr->id !=3D -1)=0A-		=
processors[pr->id] =3D NULL;=0A-#else=0A+#endif=0A 	processors[pr->id] =
=3D NULL;=0A-#endif /* CONFIG_XEN */=0A =0A =0A 	kfree(pr);=0A@@ =
-992,6 +1013,30 @@ static void __exit acpi_processor_exit(v=0A =0A 	=
remove_proc_entry(ACPI_PROCESSOR_CLASS, acpi_root_dir);=0A =0A+#ifdef =
CONFIG_XEN=0A+	{=0A+		struct acpi_device *dev;=0A+		=
unsigned int idx =3D 0;=0A+=0A+		while (radix_tree_gang_lookup(&proc=
essor_device_tree,=0A+					      (void =
**)&dev, idx, 1)) {=0A+			struct acpi_processor *pr =3D =
acpi_driver_data(dev);=0A+=0A+			/* prevent live lock =
*/=0A+			if (pr->acpi_id < idx) {=0A+				=
printk(KERN_WARNING PREFIX "ID %u unexpected"=0A+				=
       " (less than %u); leaking memory\n",=0A+				   =
    pr->acpi_id, idx);=0A+				break;=0A+		=
	}=0A+			idx =3D pr->acpi_id;=0A+			=
radix_tree_delete(&processor_device_tree, idx);=0A+			if =
(!++idx)=0A+				break;=0A+		}=0A+	=
}=0A+#endif=0A+=0A 	return;=0A }=0A =0A--- a/include/acpi/processor.h=
=0A+++ b/include/acpi/processor.h=0A@@ -24,12 +24,6 @@=0A #define =
ACPI_TSD_REV0_REVISION		0	/* Support for _PSD as in ACPI 3.0 =
*/=0A #define ACPI_TSD_REV0_ENTRIES		5=0A =0A-#ifdef CONFIG_XEN=
=0A-#define NR_ACPI_CPUS			(NR_CPUS < 256 ? 256 : =
NR_CPUS)=0A-#else=0A-#define NR_ACPI_CPUS			NR_CPUS=0A-=
#endif /* CONFIG_XEN */=0A-=0A /*=0A  * Types of coordination defined in =
ACPI 3.0. Same macros can be used across=0A  * P, C and T states=0A
--=__Part240BB9C9.0__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--=__Part240BB9C9.0__=--


From xen-devel-bounces@lists.xensource.com Tue Dec 06 13:17:47 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 13:17:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXuta-0002QQ-UF; Tue, 06 Dec 2011 13:17:18 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RXutY-0002QL-UO
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 13:17:17 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1323177390!6115362!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM3Mzk=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7245 invoked from network); 6 Dec 2011 13:16:30 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-5.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 6 Dec 2011 13:16:30 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 06 Dec 2011 13:16:30 +0000
Message-Id: <4EDE23E90200007800065B06@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 06 Dec 2011 13:17:13 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part240BB9C9.0__="
Subject: [Xen-devel] [PATCH linux-2.6.18/ACPI: eliminate restriction on ACPI
 processor ID range
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__Part240BB9C9.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Rather than storing the reference acpi_device pointers in an ACPI-ID-
indexed array (and having a bogus BUG_ON() check on a platform provided
value), use a radix tree instead.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/drivers/acpi/processor_core.c
+++ b/drivers/acpi/processor_core.c
@@ -513,7 +513,14 @@ static int acpi_processor_get_info(struc
 	return 0;
 }
=20
-static void *processor_device_array[NR_ACPI_CPUS];
+#ifndef CONFIG_XEN
+static void *processor_device_array[NR_CPUS];
+#else
+#include <linux/mutex.h>
+#include <linux/radix-tree.h>
+static DEFINE_MUTEX(processor_device_mutex);
+static RADIX_TREE(processor_device_tree, GFP_KERNEL);
+#endif
=20
 static int acpi_processor_start(struct acpi_device *device)
 {
@@ -541,9 +548,20 @@ static int __cpuinit acpi_processor_add(
 	 * Don't trust it blindly
 	 */
 #ifdef CONFIG_XEN
-	BUG_ON(pr->acpi_id >=3D NR_ACPI_CPUS);
-	if (processor_device_array[pr->acpi_id] !=3D NULL &&
-	    processor_device_array[pr->acpi_id] !=3D (void *)device) {
+	mutex_lock(&processor_device_mutex);
+	result =3D radix_tree_insert(&processor_device_tree,
+				   pr->acpi_id, device);
+	switch (result) {
+	default:
+		goto end_unlock;
+	case -EEXIST:
+		if (radix_tree_lookup(&processor_device_tree,
+				      pr->acpi_id) =3D=3D device) {
+	case 0:
+			mutex_unlock(&processor_device_mutex);
+			break;
+		}
+		mutex_unlock(&processor_device_mutex);
 #else
 	if (processor_device_array[pr->id] !=3D NULL &&
 	    processor_device_array[pr->id] !=3D (void *)device) {
@@ -553,14 +571,11 @@ static int __cpuinit acpi_processor_add(
 		return -ENODEV;
 	}
 #ifdef CONFIG_XEN
-	processor_device_array[pr->acpi_id] =3D (void *)device;
 	if (pr->id !=3D -1)
-		processors[pr->id] =3D pr;
 #else
 	processor_device_array[pr->id] =3D (void *)device;
-
-	processors[pr->id] =3D pr;
 #endif /* CONFIG_XEN */
+	processors[pr->id] =3D pr;
=20
 	result =3D acpi_processor_add_fs(device);
 	if (result)
@@ -602,6 +617,14 @@ err_thermal_unregister:
 	}
=20
       end:
+#ifdef CONFIG_XEN
+	mutex_lock(&processor_device_mutex);
+	if (radix_tree_lookup(&processor_device_tree,
+			      pr->acpi_id) =3D=3D device)
+		radix_tree_delete(&processor_device_tree, pr->acpi_id);
+      end_unlock:
+	mutex_unlock(&processor_device_mutex);
+#endif
=20
 	return result;
 }
@@ -692,10 +715,8 @@ static int acpi_processor_remove(struct=20
=20
 #ifdef CONFIG_XEN
 	if (pr->id !=3D -1)
-		processors[pr->id] =3D NULL;
-#else
+#endif
 	processors[pr->id] =3D NULL;
-#endif /* CONFIG_XEN */
=20
=20
 	kfree(pr);
@@ -992,6 +1013,30 @@ static void __exit acpi_processor_exit(v
=20
 	remove_proc_entry(ACPI_PROCESSOR_CLASS, acpi_root_dir);
=20
+#ifdef CONFIG_XEN
+	{
+		struct acpi_device *dev;
+		unsigned int idx =3D 0;
+
+		while (radix_tree_gang_lookup(&processor_device_tree,
+					      (void **)&dev, idx, 1)) {
+			struct acpi_processor *pr =3D acpi_driver_data(dev)=
;
+
+			/* prevent live lock */
+			if (pr->acpi_id < idx) {
+				printk(KERN_WARNING PREFIX "ID %u =
unexpected"
+				       " (less than %u); leaking memory\n",=

+				       pr->acpi_id, idx);
+				break;
+			}
+			idx =3D pr->acpi_id;
+			radix_tree_delete(&processor_device_tree, idx);
+			if (!++idx)
+				break;
+		}
+	}
+#endif
+
 	return;
 }
=20
--- a/include/acpi/processor.h
+++ b/include/acpi/processor.h
@@ -24,12 +24,6 @@
 #define ACPI_TSD_REV0_REVISION		0	/* Support for _PSD as in =
ACPI 3.0 */
 #define ACPI_TSD_REV0_ENTRIES		5
=20
-#ifdef CONFIG_XEN
-#define NR_ACPI_CPUS			(NR_CPUS < 256 ? 256 : NR_CPUS)
-#else
-#define NR_ACPI_CPUS			NR_CPUS
-#endif /* CONFIG_XEN */
-
 /*
  * Types of coordination defined in ACPI 3.0. Same macros can be used =
across
  * P, C and T states




--=__Part240BB9C9.0__=
Content-Type: text/plain; name="xen-acpi-processor-limit.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="xen-acpi-processor-limit.patch"

ACPI: eliminate restriction on ACPI processor ID range=0A=0ARather than =
storing the reference acpi_device pointers in an ACPI-ID-=0Aindexed array =
(and having a bogus BUG_ON() check on a platform provided=0Avalue), use a =
radix tree instead.=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=0A=
=0A--- a/drivers/acpi/processor_core.c=0A+++ b/drivers/acpi/processor_core.=
c=0A@@ -513,7 +513,14 @@ static int acpi_processor_get_info(struc=0A 	=
return 0;=0A }=0A =0A-static void *processor_device_array[NR_ACPI_CPUS];=0A=
+#ifndef CONFIG_XEN=0A+static void *processor_device_array[NR_CPUS];=0A+#el=
se=0A+#include <linux/mutex.h>=0A+#include <linux/radix-tree.h>=0A+static =
DEFINE_MUTEX(processor_device_mutex);=0A+static RADIX_TREE(processor_device=
_tree, GFP_KERNEL);=0A+#endif=0A =0A static int acpi_processor_start(struct=
 acpi_device *device)=0A {=0A@@ -541,9 +548,20 @@ static int __cpuinit =
acpi_processor_add(=0A 	 * Don't trust it blindly=0A 	 */=0A #ifdef =
CONFIG_XEN=0A-	BUG_ON(pr->acpi_id >=3D NR_ACPI_CPUS);=0A-	if =
(processor_device_array[pr->acpi_id] !=3D NULL &&=0A-	    processor_devic=
e_array[pr->acpi_id] !=3D (void *)device) {=0A+	mutex_lock(&processor_devic=
e_mutex);=0A+	result =3D radix_tree_insert(&processor_device_tree,=0A+	=
			   pr->acpi_id, device);=0A+	switch (result) =
{=0A+	default:=0A+		goto end_unlock;=0A+	case -EEXIST:=0A+	=
	if (radix_tree_lookup(&processor_device_tree,=0A+			=
	      pr->acpi_id) =3D=3D device) {=0A+	case 0:=0A+			=
mutex_unlock(&processor_device_mutex);=0A+			break;=0A+	=
	}=0A+		mutex_unlock(&processor_device_mutex);=0A #else=0A =
	if (processor_device_array[pr->id] !=3D NULL &&=0A 	    =
processor_device_array[pr->id] !=3D (void *)device) {=0A@@ -553,14 +571,11 =
@@ static int __cpuinit acpi_processor_add(=0A 		return -ENODEV;=0A =
	}=0A #ifdef CONFIG_XEN=0A-	processor_device_array[pr->acpi_id]=
 =3D (void *)device;=0A 	if (pr->id !=3D -1)=0A-		processors[=
pr->id] =3D pr;=0A #else=0A 	processor_device_array[pr->id] =3D (void =
*)device;=0A-=0A-	processors[pr->id] =3D pr;=0A #endif /* CONFIG_XEN =
*/=0A+	processors[pr->id] =3D pr;=0A =0A 	result =3D acpi_processor_a=
dd_fs(device);=0A 	if (result)=0A@@ -602,6 +617,14 @@ err_thermal_unre=
gister:=0A 	}=0A =0A       end:=0A+#ifdef CONFIG_XEN=0A+	mutex_lock(=
&processor_device_mutex);=0A+	if (radix_tree_lookup(&processor_device_tre=
e,=0A+			      pr->acpi_id) =3D=3D device)=0A+		=
radix_tree_delete(&processor_device_tree, pr->acpi_id);=0A+      end_unlock=
:=0A+	mutex_unlock(&processor_device_mutex);=0A+#endif=0A =0A 	=
return result;=0A }=0A@@ -692,10 +715,8 @@ static int acpi_processor_remove=
(struct =0A =0A #ifdef CONFIG_XEN=0A 	if (pr->id !=3D -1)=0A-		=
processors[pr->id] =3D NULL;=0A-#else=0A+#endif=0A 	processors[pr->id] =
=3D NULL;=0A-#endif /* CONFIG_XEN */=0A =0A =0A 	kfree(pr);=0A@@ =
-992,6 +1013,30 @@ static void __exit acpi_processor_exit(v=0A =0A 	=
remove_proc_entry(ACPI_PROCESSOR_CLASS, acpi_root_dir);=0A =0A+#ifdef =
CONFIG_XEN=0A+	{=0A+		struct acpi_device *dev;=0A+		=
unsigned int idx =3D 0;=0A+=0A+		while (radix_tree_gang_lookup(&proc=
essor_device_tree,=0A+					      (void =
**)&dev, idx, 1)) {=0A+			struct acpi_processor *pr =3D =
acpi_driver_data(dev);=0A+=0A+			/* prevent live lock =
*/=0A+			if (pr->acpi_id < idx) {=0A+				=
printk(KERN_WARNING PREFIX "ID %u unexpected"=0A+				=
       " (less than %u); leaking memory\n",=0A+				   =
    pr->acpi_id, idx);=0A+				break;=0A+		=
	}=0A+			idx =3D pr->acpi_id;=0A+			=
radix_tree_delete(&processor_device_tree, idx);=0A+			if =
(!++idx)=0A+				break;=0A+		}=0A+	=
}=0A+#endif=0A+=0A 	return;=0A }=0A =0A--- a/include/acpi/processor.h=
=0A+++ b/include/acpi/processor.h=0A@@ -24,12 +24,6 @@=0A #define =
ACPI_TSD_REV0_REVISION		0	/* Support for _PSD as in ACPI 3.0 =
*/=0A #define ACPI_TSD_REV0_ENTRIES		5=0A =0A-#ifdef CONFIG_XEN=
=0A-#define NR_ACPI_CPUS			(NR_CPUS < 256 ? 256 : =
NR_CPUS)=0A-#else=0A-#define NR_ACPI_CPUS			NR_CPUS=0A-=
#endif /* CONFIG_XEN */=0A-=0A /*=0A  * Types of coordination defined in =
ACPI 3.0. Same macros can be used across=0A  * P, C and T states=0A
--=__Part240BB9C9.0__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--=__Part240BB9C9.0__=--


From xen-devel-bounces@lists.xensource.com Tue Dec 06 13:42:14 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 13:42:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXvHD-0002ij-C8; Tue, 06 Dec 2011 13:41:43 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RXvHA-0002id-Il
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 13:41:40 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1323178854!6116003!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjM3Ng==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27489 invoked from network); 6 Dec 2011 13:40:55 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Dec 2011 13:40:55 -0000
X-IronPort-AV: E=Sophos;i="4.71,306,1320624000"; 
   d="scan'208";a="9320561"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Dec 2011 13:40:54 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Tue, 6 Dec 2011
	13:40:54 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>
Date: Tue, 6 Dec 2011 13:40:54 +0000
In-Reply-To: <1323173090-7867-1-git-send-email-wei.liu2@citrix.com>
References: <1323173090-7867-1-git-send-email-wei.liu2@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323178854.23681.75.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] netback: fix typo in comment
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2011-12-06 at 12:04 +0000, Wei Liu wrote:
> "variables a used" should be "variables are used".
> 
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>

> ---
>  drivers/net/xen-netback/netback.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
> index 3ecb5aa..639cf8a 100644
> --- a/drivers/net/xen-netback/netback.c
> +++ b/drivers/net/xen-netback/netback.c
> @@ -395,7 +395,7 @@ static void netbk_gop_frag_copy(struct xenvif *vif, struct sk_buff *skb,
>  	struct gnttab_copy *copy_gop;
>  	struct netbk_rx_meta *meta;
>  	/*
> -	 * These variables a used iff get_page_ext returns true,
> +	 * These variables are used iff get_page_ext returns true,
>  	 * in which case they are guaranteed to be initialized.
>  	 */
>  	unsigned int uninitialized_var(group), uninitialized_var(idx);



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 13:42:14 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 13:42:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXvHD-0002ij-C8; Tue, 06 Dec 2011 13:41:43 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RXvHA-0002id-Il
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 13:41:40 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1323178854!6116003!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjM3Ng==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27489 invoked from network); 6 Dec 2011 13:40:55 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Dec 2011 13:40:55 -0000
X-IronPort-AV: E=Sophos;i="4.71,306,1320624000"; 
   d="scan'208";a="9320561"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Dec 2011 13:40:54 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Tue, 6 Dec 2011
	13:40:54 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>
Date: Tue, 6 Dec 2011 13:40:54 +0000
In-Reply-To: <1323173090-7867-1-git-send-email-wei.liu2@citrix.com>
References: <1323173090-7867-1-git-send-email-wei.liu2@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323178854.23681.75.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] netback: fix typo in comment
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2011-12-06 at 12:04 +0000, Wei Liu wrote:
> "variables a used" should be "variables are used".
> 
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>

> ---
>  drivers/net/xen-netback/netback.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
> index 3ecb5aa..639cf8a 100644
> --- a/drivers/net/xen-netback/netback.c
> +++ b/drivers/net/xen-netback/netback.c
> @@ -395,7 +395,7 @@ static void netbk_gop_frag_copy(struct xenvif *vif, struct sk_buff *skb,
>  	struct gnttab_copy *copy_gop;
>  	struct netbk_rx_meta *meta;
>  	/*
> -	 * These variables a used iff get_page_ext returns true,
> +	 * These variables are used iff get_page_ext returns true,
>  	 * in which case they are guaranteed to be initialized.
>  	 */
>  	unsigned int uninitialized_var(group), uninitialized_var(idx);



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 13:58:49 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 13: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.xensource.com>)
	id 1RXvXG-0002uH-UZ; Tue, 06 Dec 2011 13:58:18 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <davidtecher@yahoo.fr>) id 1RXvXF-0002uC-Fa
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 13:58:17 +0000
X-Env-Sender: davidtecher@yahoo.fr
X-Msg-Ref: server-6.tower-216.messagelabs.com!1323179850!6355721!1
X-Originating-IP: [77.238.189.76]
X-SpamReason: No, hits=0.6 required=7.0 tests=HTML_40_50,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_12,ML_RADAR_SPEW_LINKS_14,ML_RADAR_SPEW_LINKS_6,
	spamassassin: 
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14705 invoked from network); 6 Dec 2011 13:57:30 -0000
Received: from nm19.bullet.mail.ird.yahoo.com (HELO
	nm19.bullet.mail.ird.yahoo.com) (77.238.189.76)
	by server-6.tower-216.messagelabs.com with SMTP;
	6 Dec 2011 13:57:30 -0000
Received: from [77.238.189.56] by nm19.bullet.mail.ird.yahoo.com with NNFMP;
	06 Dec 2011 13:57:30 -0000
Received: from [212.82.108.119] by tm9.bullet.mail.ird.yahoo.com with NNFMP;
	06 Dec 2011 13:57:30 -0000
Received: from [127.0.0.1] by omp1028.mail.ird.yahoo.com with NNFMP;
	06 Dec 2011 13:57:30 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 412796.23775.bm@omp1028.mail.ird.yahoo.com
Received: (qmail 79252 invoked by uid 60001); 6 Dec 2011 13:57:30 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.fr; s=s1024;
	t=1323179850; bh=I2k2HNL4VimDpsjzZnCYAOEuvwUUDj2MqwLxPL3kH+4=;
	h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type;
	b=0mRkwQ1vk6t2pLHh0Rx5BYjdKiBz/yE9mbCS2JwpTXUbw6TFUsu3Hc8/ticuFkKnNZJw2dBne8/jleLYrbEriQSn1qURm6NZ3ZTKZYQJ0ik+6Giqi2yXJfEpVdUCVsv9abJnMLptlC6OFL15VTVqs+2Nl3L4EDNdB+2ZVwqvUoI=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.fr;
	h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type;
	b=BVUxF+6t+ePzNOUpcGC9JHc49xWJWrZgHMv/d5AGPhNZAOBDHzTjlUZ+97TAX1/nQExwxgXJuCKiTZ8lRnsuH7j+d8zEgKJt14tpx8E7m3CqQMqzLEjE1UeO4TLBf9b2uAC67OTxUGxz9evNmYleMkk8x+A58HVaLUrch+f8+vQ=;
X-YMail-OSG: TDweZZUVM1lG24bU4mXFWuzr7f9xgBpZCpDB4qTf.rsS.PM
	TenuWOkBFlozt4urwaKoZnBvb.H66M6zpXl_9jg3mW.TQQ8y.ZkrpMRXYvqL
	iX6yMGV2D3ryYlaN1h2hm4N_0Nw7dlpy8ehRksVs84_PrEZlHkHsz7QKEK4m
	xuHydRZmNPOwWhFI6yDPF2iOS6kGY0UesvFYLSXKpwckBC9tSH2t1FPYlOpj
	dJ54VUmxn.3jFORsoq_1Tt1zPsE2EzuxugLbWEseHFRgBsbv7SoX4EY9iEdU
	1uPCdQ8SLJTa9fogvn3Fs9_MIgy_1WyJi90EQOtZyGyKg9RNbUR6.U94JnuQ
	_ry0vBopT6G3jfoBahE8qkzZcmi.2RGVCWFDr2I7OEEV2ScAz0WRmKTmwI0A
	nWzISguGM7f4GtgrXFgCm.vIaHCQSpwyxgnPmuUPiqRx9NLtzd2bI_pswOri
	DdnKfzCpmtZx0jVVSS44fS9v2MyJbWH_3YnGVS9Jv7TiRqMeBS5pbVs0vq6j
	zhm0f68.irxAjYUy28Nsln9lsTWfFWdhsT5JlVvVr9jCILe4dNW9FkXK_sq5
	7G.pnvo7hV8ec7_9SD_gGpDD8_vXK9vNc34YJV5uAK5I397dCKq5Ij9KyUVz
	NNdjIID8eVVvZ34MIr49WQ2HmP9R0BgOfU0QFhs4jos4CnaSyrpZCUw5brqO
	hp5_HRmb8b31xGG.CcNyFmo7ahv.YoMWAPw--
Received: from [195.167.237.98] by web29801.mail.ird.yahoo.com via HTTP;
	Tue, 06 Dec 2011 13:57:30 GMT
X-Mailer: YahooMailWebService/0.8.115.331698
References: <1316777654598-4833174.post@n5.nabble.com>
	<1316786412428-4833637.post@n5.nabble.com>
	<20110923172115.GI12984@reaktio.net>
	<1318672856439-4904945.post@n5.nabble.com>
	<1319630071722-4939528.post@n5.nabble.com>
	<1319636130.20499.YahooMailNeo@web29808.mail.ird.yahoo.com>
	<1319695116310-4942047.post@n5.nabble.com>
	<1319710499.206.YahooMailNeo@web29804.mail.ird.yahoo.com>
	<1323123990448-5050354.post@n5.nabble.com>
	<1323170568.90631.YahooMailNeo@web29813.mail.ird.yahoo.com>
	<1323173094434-5051880.post@n5.nabble.com>
Message-ID: <1323179850.78658.YahooMailNeo@web29801.mail.ird.yahoo.com>
Date: Tue, 6 Dec 2011 13:57:30 +0000 (GMT)
From: David TECHER <davidtecher@yahoo.fr>
To: n4rC0t1C <shandivo@gmail.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
In-Reply-To: <1323173094434-5051880.post@n5.nabble.com>
MIME-Version: 1.0
Subject: [Xen-devel] Re : Re : Re : Re : Re : Re : Re : Re : Re: Patches for
	VGA-Passthrough XEN 4.2 unstable
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: David TECHER <davidtecher@yahoo.fr>
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============7989788617255817618=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============7989788617255817618==
Content-Type: multipart/alternative; boundary="908097277-1377650170-1323179850=:78658"

--908097277-1377650170-1323179850=:78658
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

Hi=0A=0AThanks for these informations. I am on Debian. So it could be usefu=
ll for Ubuntu users.=0A=0AThanks.=0A=0ADavid=0A=0A=0A=0A___________________=
_____________=0A De=A0: n4rC0t1C <shandivo@gmail.com>=0A=C0=A0: xen-devel@l=
ists.xensource.com =0AEnvoy=E9 le : Mardi 6 D=E9cembre 2011 13h04=0AObjet=
=A0: Re: [Xen-devel] Re : Re : Re : Re : Re : Re : Re : Re: Patches for VGA=
-Passthrough XEN 4.2 unstable=0A =0AIep I used your last patches, (your web=
site it's at the top of my bookmarks),=0Aand they apply to xen-unstable rev=
. 24341 as well (which i'm using). =0A=0AI forgot to mention that I had to =
make a couple of fix to xen tree, cause it=0Awasn't compiling on my system =
due to=A0 "error: format not a string literal=0Aand no format arguments":=
=0A=0A=0A--- /usr/src/xen-unstable.hg-rev-24341-460gtx/tools/libxl/libxl_cr=
eate.c=0A+++ /usr/src/xen-unstable.hg-rev-24341-460gtx/tools/libxl/libxl_cr=
eate.c=0A@@ -462,7 +462,7 @@=0A=A0 =A0  path =3D libxl__xs_libxl_path(gc, d=
omid);=0A=A0 =A0  path =3D libxl__sprintf(gc, "%s/dm-version", path);=0A=A0=
 =A0  return libxl__xs_write(gc, XBT_NULL, path, libxl__strdup(gc,=0A-=A0 =
=A0 =A0 =0Alibxl_device_model_version_to_string(dm_info->device_model_versi=
on)));=0A+=A0 =A0 =A0 =0Alibxl_device_model_version_to_string(dm_info->devi=
ce_model_version)),"%s");=0A}=0A=0Astatic int do_domain_create(libxl__gc *g=
c, libxl_domain_config *d_config,=0A=0A=0A--- /usr/src/xen-unstable.hg-rev-=
24341-460gtx/tools/libxl/libxl_device.c=0A+++ /usr/src/xen-unstable.hg-rev-=
24341-460gtx/tools/libxl/libxl_device.c=0A@@ -516,7 +516,7 @@=0A=A0 =A0 =A0=
 =A0  for (j =3D 0; j < num_devs; j++) {=0A=A0 =A0 =A0 =A0 =A0 =A0  path =
=3D libxl__sprintf(gc,=0A"/local/domain/%d/device/%s/%s/backend",=0A=A0 =A0=
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0  domid, kinds[=
i], devs[j]);=0A-=A0 =A0 =A0 =A0 =A0 =A0 path =3D libxl__xs_read(gc, XBT_NU=
LL, libxl__sprintf(gc, path));=0A+=A0 =A0 =A0 =A0 =A0 =A0 path =3D libxl__x=
s_read(gc, XBT_NULL, libxl__sprintf(gc,=0Apath,"%s"));=0A=A0 =A0 =A0 =A0 =
=A0 =A0  if (path && libxl__parse_backend_path(gc, path, &dev) =3D=3D 0) {=
=0A=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0  dev.domid =3D domid;=0A=A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0  dev.kind =3D kind;=0A=0Aand an due to an argument missing:=
=0A=0A--- /usr/src/xen-unstable.hg-rev-24341-460gtx/tools/libxl/libxl_dom.c=
=0A+++ /usr/src/xen-unstable.hg-rev-24341-460gtx/tools/libxl/libxl_dom.c=0A=
@@ -625,7 +625,7 @@=0A=A0 =A0 =A0 =A0  break;=0A=A0 =A0  }=0A=A0 =A0  case =
LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:=0A-=A0 =A0 =A0 =A0 fd2 =3D open(filena=
me, O_WRONLY | O_CREAT | O_TRUNC);=0A+=A0 =A0 =A0 =A0 fd2 =3D open(filename=
, O_WRONLY | O_CREAT | O_TRUNC, 0644);=0A=A0 =A0 =A0 =A0  if (fd2 < 0) {=0A=
=A0 =A0 =A0 =A0 =A0 =A0  LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,=0A=A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 "Unable to create a QEM=
U save file\n");=0A=0AAs far as I know those doesn't break anything, but do=
nt take too seriously,=0Ai'm not an experienced developer :)=0A=0A=0AForgot=
 2:=0ASince I'm using an ubuntu kernel, the xen support is not integrated, =
but you=0Aneed to add xen modules at your inittrd file. I did this by addin=
g those:=0A=0Axen-pciback passthrough=3D1=0Axen-blkback=0Axenfs=0Axen-netba=
ck=0Apci-stub=0A=0Ato /etc/xen/initramfs-tools/modules and the issuing upda=
te-initramfs. =0A=0AIn the future, I'll try to boot a linux domU, right now=
 I'm still smiling=0Acause I can fully wipe my Windows installation from th=
e hard disk. And I'm=0Asure that in future Win7 will be supported too.=0A=
=0AThanks again David and everyone,=0AIvo=0A=0A--=0AView this message in co=
ntext: http://xen.1045712.n5.nabble.com/Patches-for-VGA-Passthrough-XEN-4-2=
-unstable-tp4406265p5051880.html=0ASent from the Xen - Dev mailing list arc=
hive at Nabble.com.=0A=0A_______________________________________________=0A=
Xen-devel mailing list=0AXen-devel@lists.xensource.com=0Ahttp://lists.xenso=
urce.com/xen-devel
--908097277-1377650170-1323179850=:78658
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

<html><body><div style=3D"color:#000; background-color:#fff; font-family:ti=
mes new roman, new york, times, serif;font-size:12pt"><div><span>Hi</span><=
/div><div><br><span></span></div><div><span>Thanks for these informations. =
I am on Debian. So it could be usefull for Ubuntu users.</span></div><div><=
br><span></span></div><div><span>Thanks.</span></div><div><br><span></span>=
</div><div><span>David</span></div><div><br></div>  <div style=3D"font-fami=
ly: times new roman, new york, times, serif; font-size: 12pt;"> <div style=
=3D"font-family: times new roman, new york, times, serif; font-size: 12pt;"=
> <font face=3D"Arial" size=3D"2"> <hr size=3D"1">  <b><span style=3D"font-=
weight:bold;">De&nbsp;:</span></b> n4rC0t1C &lt;shandivo@gmail.com&gt;<br> =
<b><span style=3D"font-weight: bold;">=C0&nbsp;:</span></b> xen-devel@lists=
.xensource.com <br> <b><span style=3D"font-weight: bold;">Envoy=E9 le :</sp=
an></b> Mardi 6 D=E9cembre 2011 13h04<br> <b><span style=3D"font-weight:
 bold;">Objet&nbsp;:</span></b> Re: [Xen-devel] Re : Re : Re : Re : Re : Re=
 : Re : Re: Patches for VGA-Passthrough XEN 4.2 unstable<br> </font> <br>Ie=
p I used your last patches, (your website it's at the top of my bookmarks),=
<br>and they apply to xen-unstable rev. 24341 as well (which i'm using). <b=
r><br>I forgot to mention that I had to make a couple of fix to xen tree, c=
ause it<br>wasn't compiling on my system due to&nbsp; "error: format not a =
string literal<br>and no format arguments":<br><br><br>--- /usr/src/xen-uns=
table.hg-rev-24341-460gtx/tools/libxl/libxl_create.c<br>+++ /usr/src/xen-un=
stable.hg-rev-24341-460gtx/tools/libxl/libxl_create.c<br>@@ -462,7 +462,7 @=
@<br>&nbsp; &nbsp;  path =3D libxl__xs_libxl_path(gc, domid);<br>&nbsp; &nb=
sp;  path =3D libxl__sprintf(gc, "%s/dm-version", path);<br>&nbsp; &nbsp;  =
return libxl__xs_write(gc, XBT_NULL, path, libxl__strdup(gc,<br>-&nbsp; &nb=
sp; &nbsp;=20
 <br>libxl_device_model_version_to_string(dm_info-&gt;device_model_version)=
));<br>+&nbsp; &nbsp; &nbsp;  <br>libxl_device_model_version_to_string(dm_i=
nfo-&gt;device_model_version)),"%s");<br> }<br> <br> static int do_domain_c=
reate(libxl__gc *gc, libxl_domain_config *d_config,<br><br><br>--- /usr/src=
/xen-unstable.hg-rev-24341-460gtx/tools/libxl/libxl_device.c<br>+++ /usr/sr=
c/xen-unstable.hg-rev-24341-460gtx/tools/libxl/libxl_device.c<br>@@ -516,7 =
+516,7 @@<br>&nbsp; &nbsp; &nbsp; &nbsp;  for (j =3D 0; j &lt; num_devs; j+=
+) {<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;  path =3D libxl__sprintf(=
gc,<br>"/local/domain/%d/device/%s/%s/backend",<br>&nbsp; &nbsp; &nbsp; &nb=
sp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &=
nbsp; &nbsp; &nbsp;  domid, kinds[i], devs[j]);<br>-&nbsp; &nbsp; &nbsp; &n=
bsp; &nbsp; &nbsp; path =3D libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc,=
 path));<br>+&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; path =3D
 libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc,<br>path,"%s"));<br>&nbsp; =
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;  if (path &amp;&amp; libxl__parse_backen=
d_path(gc, path, &amp;dev) =3D=3D 0) {<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp=
; &nbsp; &nbsp; &nbsp;  dev.domid =3D domid;<br>&nbsp; &nbsp; &nbsp; &nbsp;=
 &nbsp; &nbsp; &nbsp; &nbsp;  dev.kind =3D kind;<br><br>and an due to an ar=
gument missing:<br><br>--- /usr/src/xen-unstable.hg-rev-24341-460gtx/tools/=
libxl/libxl_dom.c<br>+++ /usr/src/xen-unstable.hg-rev-24341-460gtx/tools/li=
bxl/libxl_dom.c<br>@@ -625,7 +625,7 @@<br>&nbsp; &nbsp; &nbsp; &nbsp;  brea=
k;<br>&nbsp; &nbsp;  }<br>&nbsp; &nbsp;  case LIBXL_DEVICE_MODEL_VERSION_QE=
MU_XEN:<br>-&nbsp; &nbsp; &nbsp; &nbsp; fd2 =3D open(filename, O_WRONLY | O=
_CREAT | O_TRUNC);<br>+&nbsp; &nbsp; &nbsp; &nbsp; fd2 =3D open(filename, O=
_WRONLY | O_CREAT | O_TRUNC, 0644);<br>&nbsp; &nbsp; &nbsp; &nbsp;  if (fd2=
 &lt; 0) {<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;  LIBXL__LOG_ERRNO(c=
tx,
 LIBXL__LOG_ERROR,<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbs=
p; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; "Unable to create a QEM=
U save file\n");<br><br>As far as I know those doesn't break anything, but =
dont take too seriously,<br>i'm not an experienced developer :)<br><br><br>=
Forgot 2:<br>Since I'm using an ubuntu kernel, the xen support is not integ=
rated, but you<br>need to add xen modules at your inittrd file. I did this =
by adding those:<br><br>xen-pciback passthrough=3D1<br>xen-blkback<br>xenfs=
<br>xen-netback<br>pci-stub<br><br>to /etc/xen/initramfs-tools/modules and =
the issuing update-initramfs. <br><br>In the future, I'll try to boot a lin=
ux domU, right now I'm still smiling<br>cause I can fully wipe my Windows i=
nstallation from the hard disk. And I'm<br>sure that in future Win7 will be=
 supported too.<br><br>Thanks again David and everyone,<br>Ivo<br><br>--<br=
>View this message in context: <a
 href=3D"http://xen.1045712.n5.nabble.com/Patches-for-VGA-Passthrough-XEN-4=
-2-unstable-tp4406265p5051880.html" target=3D"_blank">http://xen.1045712.n5=
.nabble.com/Patches-for-VGA-Passthrough-XEN-4-2-unstable-tp4406265p5051880.=
html</a><br>Sent from the Xen - Dev mailing list archive at Nabble.com.<br>=
<br>_______________________________________________<br>Xen-devel mailing li=
st<br><a ymailto=3D"mailto:Xen-devel@lists.xensource.com" href=3D"mailto:Xe=
n-devel@lists.xensource.com">Xen-devel@lists.xensource.com</a><br><a href=
=3D"http://lists.xensource.com/xen-devel" target=3D"_blank">http://lists.xe=
nsource.com/xen-devel</a><br><br><br> </div> </div>  </div></body></html>
--908097277-1377650170-1323179850=:78658--


--===============7989788617255817618==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============7989788617255817618==--


From xen-devel-bounces@lists.xensource.com Tue Dec 06 13:58:49 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 13: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.xensource.com>)
	id 1RXvXG-0002uH-UZ; Tue, 06 Dec 2011 13:58:18 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <davidtecher@yahoo.fr>) id 1RXvXF-0002uC-Fa
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 13:58:17 +0000
X-Env-Sender: davidtecher@yahoo.fr
X-Msg-Ref: server-6.tower-216.messagelabs.com!1323179850!6355721!1
X-Originating-IP: [77.238.189.76]
X-SpamReason: No, hits=0.6 required=7.0 tests=HTML_40_50,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_12,ML_RADAR_SPEW_LINKS_14,ML_RADAR_SPEW_LINKS_6,
	spamassassin: 
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14705 invoked from network); 6 Dec 2011 13:57:30 -0000
Received: from nm19.bullet.mail.ird.yahoo.com (HELO
	nm19.bullet.mail.ird.yahoo.com) (77.238.189.76)
	by server-6.tower-216.messagelabs.com with SMTP;
	6 Dec 2011 13:57:30 -0000
Received: from [77.238.189.56] by nm19.bullet.mail.ird.yahoo.com with NNFMP;
	06 Dec 2011 13:57:30 -0000
Received: from [212.82.108.119] by tm9.bullet.mail.ird.yahoo.com with NNFMP;
	06 Dec 2011 13:57:30 -0000
Received: from [127.0.0.1] by omp1028.mail.ird.yahoo.com with NNFMP;
	06 Dec 2011 13:57:30 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 412796.23775.bm@omp1028.mail.ird.yahoo.com
Received: (qmail 79252 invoked by uid 60001); 6 Dec 2011 13:57:30 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.fr; s=s1024;
	t=1323179850; bh=I2k2HNL4VimDpsjzZnCYAOEuvwUUDj2MqwLxPL3kH+4=;
	h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type;
	b=0mRkwQ1vk6t2pLHh0Rx5BYjdKiBz/yE9mbCS2JwpTXUbw6TFUsu3Hc8/ticuFkKnNZJw2dBne8/jleLYrbEriQSn1qURm6NZ3ZTKZYQJ0ik+6Giqi2yXJfEpVdUCVsv9abJnMLptlC6OFL15VTVqs+2Nl3L4EDNdB+2ZVwqvUoI=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.fr;
	h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type;
	b=BVUxF+6t+ePzNOUpcGC9JHc49xWJWrZgHMv/d5AGPhNZAOBDHzTjlUZ+97TAX1/nQExwxgXJuCKiTZ8lRnsuH7j+d8zEgKJt14tpx8E7m3CqQMqzLEjE1UeO4TLBf9b2uAC67OTxUGxz9evNmYleMkk8x+A58HVaLUrch+f8+vQ=;
X-YMail-OSG: TDweZZUVM1lG24bU4mXFWuzr7f9xgBpZCpDB4qTf.rsS.PM
	TenuWOkBFlozt4urwaKoZnBvb.H66M6zpXl_9jg3mW.TQQ8y.ZkrpMRXYvqL
	iX6yMGV2D3ryYlaN1h2hm4N_0Nw7dlpy8ehRksVs84_PrEZlHkHsz7QKEK4m
	xuHydRZmNPOwWhFI6yDPF2iOS6kGY0UesvFYLSXKpwckBC9tSH2t1FPYlOpj
	dJ54VUmxn.3jFORsoq_1Tt1zPsE2EzuxugLbWEseHFRgBsbv7SoX4EY9iEdU
	1uPCdQ8SLJTa9fogvn3Fs9_MIgy_1WyJi90EQOtZyGyKg9RNbUR6.U94JnuQ
	_ry0vBopT6G3jfoBahE8qkzZcmi.2RGVCWFDr2I7OEEV2ScAz0WRmKTmwI0A
	nWzISguGM7f4GtgrXFgCm.vIaHCQSpwyxgnPmuUPiqRx9NLtzd2bI_pswOri
	DdnKfzCpmtZx0jVVSS44fS9v2MyJbWH_3YnGVS9Jv7TiRqMeBS5pbVs0vq6j
	zhm0f68.irxAjYUy28Nsln9lsTWfFWdhsT5JlVvVr9jCILe4dNW9FkXK_sq5
	7G.pnvo7hV8ec7_9SD_gGpDD8_vXK9vNc34YJV5uAK5I397dCKq5Ij9KyUVz
	NNdjIID8eVVvZ34MIr49WQ2HmP9R0BgOfU0QFhs4jos4CnaSyrpZCUw5brqO
	hp5_HRmb8b31xGG.CcNyFmo7ahv.YoMWAPw--
Received: from [195.167.237.98] by web29801.mail.ird.yahoo.com via HTTP;
	Tue, 06 Dec 2011 13:57:30 GMT
X-Mailer: YahooMailWebService/0.8.115.331698
References: <1316777654598-4833174.post@n5.nabble.com>
	<1316786412428-4833637.post@n5.nabble.com>
	<20110923172115.GI12984@reaktio.net>
	<1318672856439-4904945.post@n5.nabble.com>
	<1319630071722-4939528.post@n5.nabble.com>
	<1319636130.20499.YahooMailNeo@web29808.mail.ird.yahoo.com>
	<1319695116310-4942047.post@n5.nabble.com>
	<1319710499.206.YahooMailNeo@web29804.mail.ird.yahoo.com>
	<1323123990448-5050354.post@n5.nabble.com>
	<1323170568.90631.YahooMailNeo@web29813.mail.ird.yahoo.com>
	<1323173094434-5051880.post@n5.nabble.com>
Message-ID: <1323179850.78658.YahooMailNeo@web29801.mail.ird.yahoo.com>
Date: Tue, 6 Dec 2011 13:57:30 +0000 (GMT)
From: David TECHER <davidtecher@yahoo.fr>
To: n4rC0t1C <shandivo@gmail.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
In-Reply-To: <1323173094434-5051880.post@n5.nabble.com>
MIME-Version: 1.0
Subject: [Xen-devel] Re : Re : Re : Re : Re : Re : Re : Re : Re: Patches for
	VGA-Passthrough XEN 4.2 unstable
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: David TECHER <davidtecher@yahoo.fr>
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============7989788617255817618=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============7989788617255817618==
Content-Type: multipart/alternative; boundary="908097277-1377650170-1323179850=:78658"

--908097277-1377650170-1323179850=:78658
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

Hi=0A=0AThanks for these informations. I am on Debian. So it could be usefu=
ll for Ubuntu users.=0A=0AThanks.=0A=0ADavid=0A=0A=0A=0A___________________=
_____________=0A De=A0: n4rC0t1C <shandivo@gmail.com>=0A=C0=A0: xen-devel@l=
ists.xensource.com =0AEnvoy=E9 le : Mardi 6 D=E9cembre 2011 13h04=0AObjet=
=A0: Re: [Xen-devel] Re : Re : Re : Re : Re : Re : Re : Re: Patches for VGA=
-Passthrough XEN 4.2 unstable=0A =0AIep I used your last patches, (your web=
site it's at the top of my bookmarks),=0Aand they apply to xen-unstable rev=
. 24341 as well (which i'm using). =0A=0AI forgot to mention that I had to =
make a couple of fix to xen tree, cause it=0Awasn't compiling on my system =
due to=A0 "error: format not a string literal=0Aand no format arguments":=
=0A=0A=0A--- /usr/src/xen-unstable.hg-rev-24341-460gtx/tools/libxl/libxl_cr=
eate.c=0A+++ /usr/src/xen-unstable.hg-rev-24341-460gtx/tools/libxl/libxl_cr=
eate.c=0A@@ -462,7 +462,7 @@=0A=A0 =A0  path =3D libxl__xs_libxl_path(gc, d=
omid);=0A=A0 =A0  path =3D libxl__sprintf(gc, "%s/dm-version", path);=0A=A0=
 =A0  return libxl__xs_write(gc, XBT_NULL, path, libxl__strdup(gc,=0A-=A0 =
=A0 =A0 =0Alibxl_device_model_version_to_string(dm_info->device_model_versi=
on)));=0A+=A0 =A0 =A0 =0Alibxl_device_model_version_to_string(dm_info->devi=
ce_model_version)),"%s");=0A}=0A=0Astatic int do_domain_create(libxl__gc *g=
c, libxl_domain_config *d_config,=0A=0A=0A--- /usr/src/xen-unstable.hg-rev-=
24341-460gtx/tools/libxl/libxl_device.c=0A+++ /usr/src/xen-unstable.hg-rev-=
24341-460gtx/tools/libxl/libxl_device.c=0A@@ -516,7 +516,7 @@=0A=A0 =A0 =A0=
 =A0  for (j =3D 0; j < num_devs; j++) {=0A=A0 =A0 =A0 =A0 =A0 =A0  path =
=3D libxl__sprintf(gc,=0A"/local/domain/%d/device/%s/%s/backend",=0A=A0 =A0=
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0  domid, kinds[=
i], devs[j]);=0A-=A0 =A0 =A0 =A0 =A0 =A0 path =3D libxl__xs_read(gc, XBT_NU=
LL, libxl__sprintf(gc, path));=0A+=A0 =A0 =A0 =A0 =A0 =A0 path =3D libxl__x=
s_read(gc, XBT_NULL, libxl__sprintf(gc,=0Apath,"%s"));=0A=A0 =A0 =A0 =A0 =
=A0 =A0  if (path && libxl__parse_backend_path(gc, path, &dev) =3D=3D 0) {=
=0A=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0  dev.domid =3D domid;=0A=A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0  dev.kind =3D kind;=0A=0Aand an due to an argument missing:=
=0A=0A--- /usr/src/xen-unstable.hg-rev-24341-460gtx/tools/libxl/libxl_dom.c=
=0A+++ /usr/src/xen-unstable.hg-rev-24341-460gtx/tools/libxl/libxl_dom.c=0A=
@@ -625,7 +625,7 @@=0A=A0 =A0 =A0 =A0  break;=0A=A0 =A0  }=0A=A0 =A0  case =
LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:=0A-=A0 =A0 =A0 =A0 fd2 =3D open(filena=
me, O_WRONLY | O_CREAT | O_TRUNC);=0A+=A0 =A0 =A0 =A0 fd2 =3D open(filename=
, O_WRONLY | O_CREAT | O_TRUNC, 0644);=0A=A0 =A0 =A0 =A0  if (fd2 < 0) {=0A=
=A0 =A0 =A0 =A0 =A0 =A0  LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,=0A=A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 "Unable to create a QEM=
U save file\n");=0A=0AAs far as I know those doesn't break anything, but do=
nt take too seriously,=0Ai'm not an experienced developer :)=0A=0A=0AForgot=
 2:=0ASince I'm using an ubuntu kernel, the xen support is not integrated, =
but you=0Aneed to add xen modules at your inittrd file. I did this by addin=
g those:=0A=0Axen-pciback passthrough=3D1=0Axen-blkback=0Axenfs=0Axen-netba=
ck=0Apci-stub=0A=0Ato /etc/xen/initramfs-tools/modules and the issuing upda=
te-initramfs. =0A=0AIn the future, I'll try to boot a linux domU, right now=
 I'm still smiling=0Acause I can fully wipe my Windows installation from th=
e hard disk. And I'm=0Asure that in future Win7 will be supported too.=0A=
=0AThanks again David and everyone,=0AIvo=0A=0A--=0AView this message in co=
ntext: http://xen.1045712.n5.nabble.com/Patches-for-VGA-Passthrough-XEN-4-2=
-unstable-tp4406265p5051880.html=0ASent from the Xen - Dev mailing list arc=
hive at Nabble.com.=0A=0A_______________________________________________=0A=
Xen-devel mailing list=0AXen-devel@lists.xensource.com=0Ahttp://lists.xenso=
urce.com/xen-devel
--908097277-1377650170-1323179850=:78658
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

<html><body><div style=3D"color:#000; background-color:#fff; font-family:ti=
mes new roman, new york, times, serif;font-size:12pt"><div><span>Hi</span><=
/div><div><br><span></span></div><div><span>Thanks for these informations. =
I am on Debian. So it could be usefull for Ubuntu users.</span></div><div><=
br><span></span></div><div><span>Thanks.</span></div><div><br><span></span>=
</div><div><span>David</span></div><div><br></div>  <div style=3D"font-fami=
ly: times new roman, new york, times, serif; font-size: 12pt;"> <div style=
=3D"font-family: times new roman, new york, times, serif; font-size: 12pt;"=
> <font face=3D"Arial" size=3D"2"> <hr size=3D"1">  <b><span style=3D"font-=
weight:bold;">De&nbsp;:</span></b> n4rC0t1C &lt;shandivo@gmail.com&gt;<br> =
<b><span style=3D"font-weight: bold;">=C0&nbsp;:</span></b> xen-devel@lists=
.xensource.com <br> <b><span style=3D"font-weight: bold;">Envoy=E9 le :</sp=
an></b> Mardi 6 D=E9cembre 2011 13h04<br> <b><span style=3D"font-weight:
 bold;">Objet&nbsp;:</span></b> Re: [Xen-devel] Re : Re : Re : Re : Re : Re=
 : Re : Re: Patches for VGA-Passthrough XEN 4.2 unstable<br> </font> <br>Ie=
p I used your last patches, (your website it's at the top of my bookmarks),=
<br>and they apply to xen-unstable rev. 24341 as well (which i'm using). <b=
r><br>I forgot to mention that I had to make a couple of fix to xen tree, c=
ause it<br>wasn't compiling on my system due to&nbsp; "error: format not a =
string literal<br>and no format arguments":<br><br><br>--- /usr/src/xen-uns=
table.hg-rev-24341-460gtx/tools/libxl/libxl_create.c<br>+++ /usr/src/xen-un=
stable.hg-rev-24341-460gtx/tools/libxl/libxl_create.c<br>@@ -462,7 +462,7 @=
@<br>&nbsp; &nbsp;  path =3D libxl__xs_libxl_path(gc, domid);<br>&nbsp; &nb=
sp;  path =3D libxl__sprintf(gc, "%s/dm-version", path);<br>&nbsp; &nbsp;  =
return libxl__xs_write(gc, XBT_NULL, path, libxl__strdup(gc,<br>-&nbsp; &nb=
sp; &nbsp;=20
 <br>libxl_device_model_version_to_string(dm_info-&gt;device_model_version)=
));<br>+&nbsp; &nbsp; &nbsp;  <br>libxl_device_model_version_to_string(dm_i=
nfo-&gt;device_model_version)),"%s");<br> }<br> <br> static int do_domain_c=
reate(libxl__gc *gc, libxl_domain_config *d_config,<br><br><br>--- /usr/src=
/xen-unstable.hg-rev-24341-460gtx/tools/libxl/libxl_device.c<br>+++ /usr/sr=
c/xen-unstable.hg-rev-24341-460gtx/tools/libxl/libxl_device.c<br>@@ -516,7 =
+516,7 @@<br>&nbsp; &nbsp; &nbsp; &nbsp;  for (j =3D 0; j &lt; num_devs; j+=
+) {<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;  path =3D libxl__sprintf(=
gc,<br>"/local/domain/%d/device/%s/%s/backend",<br>&nbsp; &nbsp; &nbsp; &nb=
sp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &=
nbsp; &nbsp; &nbsp;  domid, kinds[i], devs[j]);<br>-&nbsp; &nbsp; &nbsp; &n=
bsp; &nbsp; &nbsp; path =3D libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc,=
 path));<br>+&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; path =3D
 libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc,<br>path,"%s"));<br>&nbsp; =
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;  if (path &amp;&amp; libxl__parse_backen=
d_path(gc, path, &amp;dev) =3D=3D 0) {<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp=
; &nbsp; &nbsp; &nbsp;  dev.domid =3D domid;<br>&nbsp; &nbsp; &nbsp; &nbsp;=
 &nbsp; &nbsp; &nbsp; &nbsp;  dev.kind =3D kind;<br><br>and an due to an ar=
gument missing:<br><br>--- /usr/src/xen-unstable.hg-rev-24341-460gtx/tools/=
libxl/libxl_dom.c<br>+++ /usr/src/xen-unstable.hg-rev-24341-460gtx/tools/li=
bxl/libxl_dom.c<br>@@ -625,7 +625,7 @@<br>&nbsp; &nbsp; &nbsp; &nbsp;  brea=
k;<br>&nbsp; &nbsp;  }<br>&nbsp; &nbsp;  case LIBXL_DEVICE_MODEL_VERSION_QE=
MU_XEN:<br>-&nbsp; &nbsp; &nbsp; &nbsp; fd2 =3D open(filename, O_WRONLY | O=
_CREAT | O_TRUNC);<br>+&nbsp; &nbsp; &nbsp; &nbsp; fd2 =3D open(filename, O=
_WRONLY | O_CREAT | O_TRUNC, 0644);<br>&nbsp; &nbsp; &nbsp; &nbsp;  if (fd2=
 &lt; 0) {<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;  LIBXL__LOG_ERRNO(c=
tx,
 LIBXL__LOG_ERROR,<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbs=
p; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; "Unable to create a QEM=
U save file\n");<br><br>As far as I know those doesn't break anything, but =
dont take too seriously,<br>i'm not an experienced developer :)<br><br><br>=
Forgot 2:<br>Since I'm using an ubuntu kernel, the xen support is not integ=
rated, but you<br>need to add xen modules at your inittrd file. I did this =
by adding those:<br><br>xen-pciback passthrough=3D1<br>xen-blkback<br>xenfs=
<br>xen-netback<br>pci-stub<br><br>to /etc/xen/initramfs-tools/modules and =
the issuing update-initramfs. <br><br>In the future, I'll try to boot a lin=
ux domU, right now I'm still smiling<br>cause I can fully wipe my Windows i=
nstallation from the hard disk. And I'm<br>sure that in future Win7 will be=
 supported too.<br><br>Thanks again David and everyone,<br>Ivo<br><br>--<br=
>View this message in context: <a
 href=3D"http://xen.1045712.n5.nabble.com/Patches-for-VGA-Passthrough-XEN-4=
-2-unstable-tp4406265p5051880.html" target=3D"_blank">http://xen.1045712.n5=
.nabble.com/Patches-for-VGA-Passthrough-XEN-4-2-unstable-tp4406265p5051880.=
html</a><br>Sent from the Xen - Dev mailing list archive at Nabble.com.<br>=
<br>_______________________________________________<br>Xen-devel mailing li=
st<br><a ymailto=3D"mailto:Xen-devel@lists.xensource.com" href=3D"mailto:Xe=
n-devel@lists.xensource.com">Xen-devel@lists.xensource.com</a><br><a href=
=3D"http://lists.xensource.com/xen-devel" target=3D"_blank">http://lists.xe=
nsource.com/xen-devel</a><br><br><br> </div> </div>  </div></body></html>
--908097277-1377650170-1323179850=:78658--


--===============7989788617255817618==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============7989788617255817618==--


From xen-devel-bounces@lists.xensource.com Tue Dec 06 14:37:37 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 14: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.xensource.com>)
	id 1RXw8K-0003Fi-9i; Tue, 06 Dec 2011 14:36:36 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RXw8I-0003Fa-LC
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 14:36:35 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1323182147!7720411!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM3Mzk=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16706 invoked from network); 6 Dec 2011 14:35:47 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-2.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 6 Dec 2011 14:35:47 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 06 Dec 2011 14:35:47 +0000
Message-Id: <4EDE367D0200007800065B6B@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 06 Dec 2011 14:36:29 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Stefano Stabellini" <stefano.stabellini@eu.citrix.com>,
	"Haitao Shan" <maillists.shan@gmail.com>
References: <CAFQ2Z+fpR1UkxFEAYTD6irBUBeA3c7eJ3x1bXE0jzpdfQtH64w@mail.gmail.com>
	<alpine.DEB.2.00.1112021223190.31179@kaball-desktop>
In-Reply-To: <alpine.DEB.2.00.1112021223190.31179@kaball-desktop>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartAD82307D.3__="
Cc: Haitao Shan <haitao.shan@intel.com>, Keir Fraser <keir@xen.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] Qemu MSI Cleaning Up
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__PartAD82307D.3__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

>>> On 02.12.11 at 13:40, Stefano Stabellini <stefano.stabellini@eu.citrix.=
com> wrote:
> The two mapping and unmapping big chuncks of code looks very similar
> apart from the DPCI_ADD_MAPPING/DPCI_REMOVE_MAPPING parameter.
> Could they be refactored into a single function called=20
> "change_msix_mappings"?
> This is more or less what I have in mind:
>=20
> change_msix_mappings(assigned_device, DPCI_REMOVE_MAPPING);
>=20
> update mmio_base_addr
>=20
> change_msix_mappings(assigned_device, DPCI_ADD_MAPPING);

Please see below/attached for the outcome. Without MSI-X capable
devices to pass through, I have to rely on others to do some testing
on this.

Jan

qemu: clean up MSI-X table handling

This patch does cleaning up of QEMU MSI handling. The fixes are:
1. Changes made to MSI-X table mapping handling to eliminate the small
windows in which guest could have access to physical MSI-X table.
2. MSI-X table is mapped as read-only to QEMU, as masking of MSI-X is
already in Xen now.
3. For registers that coexists inside the MSI-X table (this could be
only PBA I think), value read from physical page would be returned.

Signed-off-by:  Shan Haitao <maillists.shan@gmail.com>

Consolidated duplicate code into _pt_iomem_helper(). Fixed formatting.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/hw/pass-through.c
+++ b/hw/pass-through.c
@@ -92,6 +92,7 @@
=20
 #include <unistd.h>
 #include <sys/ioctl.h>
+#include <assert.h>
=20
 extern int gfx_passthru;
 int igd_passthru =3D 0;
@@ -1097,6 +1098,44 @@ uint8_t pci_intx(struct pt_dev *ptdev)
     return r_val;
 }
=20
+static int _pt_iomem_helper(struct pt_dev *assigned_device, int i,
+                            uint32_t e_base, uint32_t e_size, int op)
+{
+    if ( has_msix_mapping(assigned_device, i) )
+    {
+        uint32_t msix_last_pfn =3D (assigned_device->msix->mmio_base_addr =
- 1 +
+            assigned_device->msix->total_entries * 16) >> XC_PAGE_SHIFT;
+        uint32_t bar_last_pfn =3D (e_base + e_size - 1) >> XC_PAGE_SHIFT;
+        int ret =3D 0;
+
+        if ( assigned_device->msix->table_off )
+            ret =3D xc_domain_memory_mapping(xc_handle, domid,
+                e_base >> XC_PAGE_SHIFT,
+                assigned_device->bases[i].access.maddr >> XC_PAGE_SHIFT,
+                (assigned_device->msix->mmio_base_addr >> XC_PAGE_SHIFT)
+                - (e_base >> XC_PAGE_SHIFT), op);
+
+        if ( ret =3D=3D 0 && msix_last_pfn !=3D bar_last_pfn )
+        {
+            assert(msix_last_pfn < bar_last_pfn);
+            ret =3D xc_domain_memory_mapping(xc_handle, domid,
+                msix_last_pfn + 1,
+                (assigned_device->bases[i].access.maddr +
+                 assigned_device->msix->table_off +
+                 assigned_device->msix->total_entries * 16 +
+                 XC_PAGE_SIZE - 1) >> XC_PAGE_SHIFT,
+                bar_last_pfn - msix_last_pfn, op);
+        }
+
+        return ret;
+    }
+
+    return xc_domain_memory_mapping(xc_handle, domid,
+        e_base >> XC_PAGE_SHIFT,
+        assigned_device->bases[i].access.maddr >> XC_PAGE_SHIFT,
+        (e_size + XC_PAGE_SIZE - 1) >> XC_PAGE_SHIFT, op);
+}
+
 /* Being called each time a mmio region has been updated */
 static void pt_iomem_map(PCIDevice *d, int i, uint32_t e_phys, uint32_t =
e_size,
                          int type)
@@ -1118,13 +1157,11 @@ static void pt_iomem_map(PCIDevice *d, i
=20
     if ( !first_map && old_ebase !=3D -1 )
     {
-        add_msix_mapping(assigned_device, i);
-        /* Remove old mapping */
-        ret =3D xc_domain_memory_mapping(xc_handle, domid,
-                old_ebase >> XC_PAGE_SHIFT,
-                assigned_device->bases[i].access.maddr >> XC_PAGE_SHIFT,
-                (e_size+XC_PAGE_SIZE-1) >> XC_PAGE_SHIFT,
-                DPCI_REMOVE_MAPPING);
+        if ( has_msix_mapping(assigned_device, i) )
+            unregister_iomem(assigned_device->msix->mmio_base_addr);
+
+        ret =3D _pt_iomem_helper(assigned_device, i, old_ebase, e_size,
+                               DPCI_REMOVE_MAPPING);
         if ( ret !=3D 0 )
         {
             PT_LOG("Error: remove old mapping failed!\n");
@@ -1135,22 +1172,26 @@ static void pt_iomem_map(PCIDevice *d, i
     /* map only valid guest address */
     if (e_phys !=3D -1)
     {
-        /* Create new mapping */
-        ret =3D xc_domain_memory_mapping(xc_handle, domid,
-                assigned_device->bases[i].e_physbase >> XC_PAGE_SHIFT,
-                assigned_device->bases[i].access.maddr >> XC_PAGE_SHIFT,
-                (e_size+XC_PAGE_SIZE-1) >> XC_PAGE_SHIFT,
-                DPCI_ADD_MAPPING);
+        if ( has_msix_mapping(assigned_device, i) )
+        {
+            assigned_device->msix->mmio_base_addr =3D
+                assigned_device->bases[i].e_physbase
+                + assigned_device->msix->table_off;
+
+            cpu_register_physical_memory(assigned_device->msix->mmio_base_=
addr,
+                 (assigned_device->msix->total_entries * 16 + XC_PAGE_SIZE=
 - 1)
+                  & XC_PAGE_MASK,
+                 assigned_device->msix->mmio_index);
+        }
=20
+        ret =3D _pt_iomem_helper(assigned_device, i, e_phys, e_size,
+                               DPCI_ADD_MAPPING);
         if ( ret !=3D 0 )
         {
             PT_LOG("Error: create new mapping failed!\n");
+            return;
         }
=20
-        ret =3D remove_msix_mapping(assigned_device, i);
-        if ( ret !=3D 0 )
-            PT_LOG("Error: remove MSI-X mmio mapping failed!\n");
-
         if ( old_ebase !=3D e_phys && old_ebase !=3D -1 )
             pt_msix_update_remap(assigned_device, i);
     }
--- a/hw/pt-msi.c
+++ b/hw/pt-msi.c
@@ -284,15 +284,6 @@ void pt_disable_msi_translate(struct pt_
     dev->msi_trans_en =3D 0;
 }
=20
-/* MSI-X virtulization functions */
-static void mask_physical_msix_entry(struct pt_dev *dev, int entry_nr, =
int mask)
-{
-    void *phys_off;
-
-    phys_off =3D dev->msix->phys_iomem_base + 16 * entry_nr + 12;
-    *(uint32_t *)phys_off =3D mask;
-}
-
 static int pt_msix_update_one(struct pt_dev *dev, int entry_nr)
 {
     struct msix_entry_info *entry =3D &dev->msix->msix_entry[entry_nr];
@@ -486,7 +477,6 @@ static void pci_msix_writel(void *opaque
     {
         if ( msix->enabled && !(val & 0x1) )
             pt_msix_update_one(dev, entry_nr);
-        mask_physical_msix_entry(dev, entry_nr, entry->io_mem[3] & 0x1);
     }
 }
=20
@@ -519,7 +509,11 @@ static uint32_t pci_msix_readl(void *opa
     entry_nr =3D (addr - msix->mmio_base_addr) / 16;
     offset =3D ((addr - msix->mmio_base_addr) % 16) / 4;
=20
-    return msix->msix_entry[entry_nr].io_mem[offset];
+    if ( addr - msix->mmio_base_addr < msix->total_entries * 16 )
+        return msix->msix_entry[entry_nr].io_mem[offset];
+    else
+        return *(uint32_t *)(msix->phys_iomem_base +
+                             (addr - msix->mmio_base_addr));
 }
=20
 static CPUReadMemoryFunc *pci_msix_read[] =3D {
@@ -528,39 +522,12 @@ static CPUReadMemoryFunc *pci_msix_read[
     pci_msix_readl
 };
=20
-int add_msix_mapping(struct pt_dev *dev, int bar_index)
+int has_msix_mapping(struct pt_dev *dev, int bar_index)
 {
     if ( !(dev->msix && dev->msix->bar_index =3D=3D bar_index) )
         return 0;
=20
-    return xc_domain_memory_mapping(xc_handle, domid,
-                dev->msix->mmio_base_addr >> XC_PAGE_SHIFT,
-                (dev->bases[bar_index].access.maddr
-                + dev->msix->table_off) >> XC_PAGE_SHIFT,
-                (dev->msix->total_entries * 16
-                + XC_PAGE_SIZE -1) >> XC_PAGE_SHIFT,
-                DPCI_ADD_MAPPING);
-}
-
-int remove_msix_mapping(struct pt_dev *dev, int bar_index)
-{
-    if ( !(dev->msix && dev->msix->bar_index =3D=3D bar_index) )
-        return 0;
-
-    dev->msix->mmio_base_addr =3D dev->bases[bar_index].e_physbase
-                                + dev->msix->table_off;
-
-    cpu_register_physical_memory(dev->msix->mmio_base_addr,
-                                 dev->msix->total_entries * 16,
-                                 dev->msix->mmio_index);
-
-    return xc_domain_memory_mapping(xc_handle, domid,
-                dev->msix->mmio_base_addr >> XC_PAGE_SHIFT,
-                (dev->bases[bar_index].access.maddr
-                + dev->msix->table_off) >> XC_PAGE_SHIFT,
-                (dev->msix->total_entries * 16
-                + XC_PAGE_SIZE -1) >> XC_PAGE_SHIFT,
-                DPCI_REMOVE_MAPPING);
+    return 1;
 }
=20
 int pt_msix_init(struct pt_dev *dev, int pos)
@@ -616,7 +583,7 @@ int pt_msix_init(struct pt_dev *dev, int
     PT_LOG("table_off =3D %x, total_entries =3D %d\n", table_off, =
total_entries);
     dev->msix->table_offset_adjust =3D table_off & 0x0fff;
     dev->msix->phys_iomem_base =3D mmap(0, total_entries * 16 + dev->msix-=
>table_offset_adjust,
-                          PROT_WRITE | PROT_READ, MAP_SHARED | MAP_LOCKED,=

+                          PROT_READ, MAP_SHARED | MAP_LOCKED,
                           fd, dev->msix->table_base + table_off - =
dev->msix->table_offset_adjust);
     dev->msix->phys_iomem_base =3D (void *)((char *)dev->msix->phys_iomem_=
base +=20
                           dev->msix->table_offset_adjust);
--- a/hw/pt-msi.h
+++ b/hw/pt-msi.h
@@ -107,10 +107,7 @@ void
 pt_msix_disable(struct pt_dev *dev);
=20
 int
-remove_msix_mapping(struct pt_dev *dev, int bar_index);
-
-int
-add_msix_mapping(struct pt_dev *dev, int bar_index);
+has_msix_mapping(struct pt_dev *dev, int bar_index);
=20
 int
 pt_msix_init(struct pt_dev *dev, int pos);



--=__PartAD82307D.3__=
Content-Type: text/plain; name="qemu-msix-cleanup.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="qemu-msix-cleanup.patch"

qemu: clean up MSI-X table handling=0A=0AThis patch does cleaning up of =
QEMU MSI handling. The fixes are:=0A1. Changes made to MSI-X table mapping =
handling to eliminate the small=0Awindows in which guest could have access =
to physical MSI-X table.=0A2. MSI-X table is mapped as read-only to QEMU, =
as masking of MSI-X is=0Aalready in Xen now.=0A3. For registers that =
coexists inside the MSI-X table (this could be=0Aonly PBA I think), value =
read from physical page would be returned.=0A=0ASigned-off-by:  Shan =
Haitao <maillists.shan@gmail.com>=0A=0AConsolidated duplicate code into =
_pt_iomem_helper(). Fixed formatting.=0A=0ASigned-off-by: Jan Beulich =
<jbeulich@suse.com>=0A=0A--- a/hw/pass-through.c=0A+++ b/hw/pass-through.c=
=0A@@ -92,6 +92,7 @@=0A =0A #include <unistd.h>=0A #include <sys/ioctl.h>=
=0A+#include <assert.h>=0A =0A extern int gfx_passthru;=0A int igd_passthru=
 =3D 0;=0A@@ -1097,6 +1098,44 @@ uint8_t pci_intx(struct pt_dev *ptdev)=0A =
    return r_val;=0A }=0A =0A+static int _pt_iomem_helper(struct pt_dev =
*assigned_device, int i,=0A+                            uint32_t e_base, =
uint32_t e_size, int op)=0A+{=0A+    if ( has_msix_mapping(assigned_device,=
 i) )=0A+    {=0A+        uint32_t msix_last_pfn =3D (assigned_device->msix=
->mmio_base_addr - 1 +=0A+            assigned_device->msix->total_entries =
* 16) >> XC_PAGE_SHIFT;=0A+        uint32_t bar_last_pfn =3D (e_base + =
e_size - 1) >> XC_PAGE_SHIFT;=0A+        int ret =3D 0;=0A+=0A+        if =
( assigned_device->msix->table_off )=0A+            ret =3D xc_domain_memor=
y_mapping(xc_handle, domid,=0A+                e_base >> XC_PAGE_SHIFT,=0A+=
                assigned_device->bases[i].access.maddr >> XC_PAGE_SHIFT,=0A=
+                (assigned_device->msix->mmio_base_addr >> XC_PAGE_SHIFT)=
=0A+                - (e_base >> XC_PAGE_SHIFT), op);=0A+=0A+        if ( =
ret =3D=3D 0 && msix_last_pfn !=3D bar_last_pfn )=0A+        {=0A+         =
   assert(msix_last_pfn < bar_last_pfn);=0A+            ret =3D xc_domain_m=
emory_mapping(xc_handle, domid,=0A+                msix_last_pfn + 1,=0A+  =
              (assigned_device->bases[i].access.maddr +=0A+                =
 assigned_device->msix->table_off +=0A+                 assigned_device->ms=
ix->total_entries * 16 +=0A+                 XC_PAGE_SIZE - 1) >> =
XC_PAGE_SHIFT,=0A+                bar_last_pfn - msix_last_pfn, op);=0A+   =
     }=0A+=0A+        return ret;=0A+    }=0A+=0A+    return xc_domain_memo=
ry_mapping(xc_handle, domid,=0A+        e_base >> XC_PAGE_SHIFT,=0A+       =
 assigned_device->bases[i].access.maddr >> XC_PAGE_SHIFT,=0A+        =
(e_size + XC_PAGE_SIZE - 1) >> XC_PAGE_SHIFT, op);=0A+}=0A+=0A /* Being =
called each time a mmio region has been updated */=0A static void =
pt_iomem_map(PCIDevice *d, int i, uint32_t e_phys, uint32_t e_size,=0A     =
                     int type)=0A@@ -1118,13 +1157,11 @@ static void =
pt_iomem_map(PCIDevice *d, i=0A =0A     if ( !first_map && old_ebase !=3D =
-1 )=0A     {=0A-        add_msix_mapping(assigned_device, i);=0A-        =
/* Remove old mapping */=0A-        ret =3D xc_domain_memory_mapping(xc_han=
dle, domid,=0A-                old_ebase >> XC_PAGE_SHIFT,=0A-             =
   assigned_device->bases[i].access.maddr >> XC_PAGE_SHIFT,=0A-            =
    (e_size+XC_PAGE_SIZE-1) >> XC_PAGE_SHIFT,=0A-                DPCI_REMOV=
E_MAPPING);=0A+        if ( has_msix_mapping(assigned_device, i) )=0A+     =
       unregister_iomem(assigned_device->msix->mmio_base_addr);=0A+=0A+    =
    ret =3D _pt_iomem_helper(assigned_device, i, old_ebase, e_size,=0A+    =
                           DPCI_REMOVE_MAPPING);=0A         if ( ret !=3D =
0 )=0A         {=0A             PT_LOG("Error: remove old mapping =
failed!\n");=0A@@ -1135,22 +1172,26 @@ static void pt_iomem_map(PCIDevice =
*d, i=0A     /* map only valid guest address */=0A     if (e_phys !=3D =
-1)=0A     {=0A-        /* Create new mapping */=0A-        ret =3D =
xc_domain_memory_mapping(xc_handle, domid,=0A-                assigned_devi=
ce->bases[i].e_physbase >> XC_PAGE_SHIFT,=0A-                assigned_devic=
e->bases[i].access.maddr >> XC_PAGE_SHIFT,=0A-                (e_size+XC_PA=
GE_SIZE-1) >> XC_PAGE_SHIFT,=0A-                DPCI_ADD_MAPPING);=0A+     =
   if ( has_msix_mapping(assigned_device, i) )=0A+        {=0A+            =
assigned_device->msix->mmio_base_addr =3D=0A+                assigned_devic=
e->bases[i].e_physbase=0A+                + assigned_device->msix->table_of=
f;=0A+=0A+            cpu_register_physical_memory(assigned_device->msix->m=
mio_base_addr,=0A+                 (assigned_device->msix->total_entries * =
16 + XC_PAGE_SIZE - 1)=0A+                  & XC_PAGE_MASK,=0A+            =
     assigned_device->msix->mmio_index);=0A+        }=0A =0A+        ret =
=3D _pt_iomem_helper(assigned_device, i, e_phys, e_size,=0A+               =
                DPCI_ADD_MAPPING);=0A         if ( ret !=3D 0 )=0A         =
{=0A             PT_LOG("Error: create new mapping failed!\n");=0A+        =
    return;=0A         }=0A =0A-        ret =3D remove_msix_mapping(assigne=
d_device, i);=0A-        if ( ret !=3D 0 )=0A-            PT_LOG("Error: =
remove MSI-X mmio mapping failed!\n");=0A-=0A         if ( old_ebase !=3D =
e_phys && old_ebase !=3D -1 )=0A             pt_msix_update_remap(assigned_=
device, i);=0A     }=0A--- a/hw/pt-msi.c=0A+++ b/hw/pt-msi.c=0A@@ -284,15 =
+284,6 @@ void pt_disable_msi_translate(struct pt_=0A     dev->msi_trans_en=
 =3D 0;=0A }=0A =0A-/* MSI-X virtulization functions */=0A-static void =
mask_physical_msix_entry(struct pt_dev *dev, int entry_nr, int mask)=0A-{=
=0A-    void *phys_off;=0A-=0A-    phys_off =3D dev->msix->phys_iomem_base =
+ 16 * entry_nr + 12;=0A-    *(uint32_t *)phys_off =3D mask;=0A-}=0A-=0A =
static int pt_msix_update_one(struct pt_dev *dev, int entry_nr)=0A {=0A    =
 struct msix_entry_info *entry =3D &dev->msix->msix_entry[entry_nr];=0A@@ =
-486,7 +477,6 @@ static void pci_msix_writel(void *opaque=0A     {=0A      =
   if ( msix->enabled && !(val & 0x1) )=0A             pt_msix_update_one(d=
ev, entry_nr);=0A-        mask_physical_msix_entry(dev, entry_nr, =
entry->io_mem[3] & 0x1);=0A     }=0A }=0A =0A@@ -519,7 +509,11 @@ static =
uint32_t pci_msix_readl(void *opa=0A     entry_nr =3D (addr - msix->mmio_ba=
se_addr) / 16;=0A     offset =3D ((addr - msix->mmio_base_addr) % 16) / =
4;=0A =0A-    return msix->msix_entry[entry_nr].io_mem[offset];=0A+    if =
( addr - msix->mmio_base_addr < msix->total_entries * 16 )=0A+        =
return msix->msix_entry[entry_nr].io_mem[offset];=0A+    else=0A+        =
return *(uint32_t *)(msix->phys_iomem_base +=0A+                           =
  (addr - msix->mmio_base_addr));=0A }=0A =0A static CPUReadMemoryFunc =
*pci_msix_read[] =3D {=0A@@ -528,39 +522,12 @@ static CPUReadMemoryFunc =
*pci_msix_read[=0A     pci_msix_readl=0A };=0A =0A-int add_msix_mapping(str=
uct pt_dev *dev, int bar_index)=0A+int has_msix_mapping(struct pt_dev =
*dev, int bar_index)=0A {=0A     if ( !(dev->msix && dev->msix->bar_index =
=3D=3D bar_index) )=0A         return 0;=0A =0A-    return xc_domain_memory=
_mapping(xc_handle, domid,=0A-                dev->msix->mmio_base_addr >> =
XC_PAGE_SHIFT,=0A-                (dev->bases[bar_index].access.maddr=0A-  =
              + dev->msix->table_off) >> XC_PAGE_SHIFT,=0A-                =
(dev->msix->total_entries * 16=0A-                + XC_PAGE_SIZE -1) >> =
XC_PAGE_SHIFT,=0A-                DPCI_ADD_MAPPING);=0A-}=0A-=0A-int =
remove_msix_mapping(struct pt_dev *dev, int bar_index)=0A-{=0A-    if ( =
!(dev->msix && dev->msix->bar_index =3D=3D bar_index) )=0A-        return =
0;=0A-=0A-    dev->msix->mmio_base_addr =3D dev->bases[bar_index].e_physbas=
e=0A-                                + dev->msix->table_off;=0A-=0A-    =
cpu_register_physical_memory(dev->msix->mmio_base_addr,=0A-                =
                 dev->msix->total_entries * 16,=0A-                        =
         dev->msix->mmio_index);=0A-=0A-    return xc_domain_memory_mapping=
(xc_handle, domid,=0A-                dev->msix->mmio_base_addr >> =
XC_PAGE_SHIFT,=0A-                (dev->bases[bar_index].access.maddr=0A-  =
              + dev->msix->table_off) >> XC_PAGE_SHIFT,=0A-                =
(dev->msix->total_entries * 16=0A-                + XC_PAGE_SIZE -1) >> =
XC_PAGE_SHIFT,=0A-                DPCI_REMOVE_MAPPING);=0A+    return =
1;=0A }=0A =0A int pt_msix_init(struct pt_dev *dev, int pos)=0A@@ -616,7 =
+583,7 @@ int pt_msix_init(struct pt_dev *dev, int=0A     PT_LOG("table_off=
 =3D %x, total_entries =3D %d\n", table_off, total_entries);=0A     =
dev->msix->table_offset_adjust =3D table_off & 0x0fff;=0A     dev->msix->ph=
ys_iomem_base =3D mmap(0, total_entries * 16 + dev->msix->table_offset_adju=
st,=0A-                          PROT_WRITE | PROT_READ, MAP_SHARED | =
MAP_LOCKED,=0A+                          PROT_READ, MAP_SHARED | MAP_LOCKED=
,=0A                           fd, dev->msix->table_base + table_off - =
dev->msix->table_offset_adjust);=0A     dev->msix->phys_iomem_base =3D =
(void *)((char *)dev->msix->phys_iomem_base + =0A                          =
 dev->msix->table_offset_adjust);=0A--- a/hw/pt-msi.h=0A+++ b/hw/pt-msi.h=
=0A@@ -107,10 +107,7 @@ void=0A pt_msix_disable(struct pt_dev *dev);=0A =
=0A int=0A-remove_msix_mapping(struct pt_dev *dev, int bar_index);=0A-=0A-i=
nt=0A-add_msix_mapping(struct pt_dev *dev, int bar_index);=0A+has_msix_mapp=
ing(struct pt_dev *dev, int bar_index);=0A =0A int=0A pt_msix_init(struct =
pt_dev *dev, int pos);=0A
--=__PartAD82307D.3__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--=__PartAD82307D.3__=--


From xen-devel-bounces@lists.xensource.com Tue Dec 06 14:37:37 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 14: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.xensource.com>)
	id 1RXw8K-0003Fi-9i; Tue, 06 Dec 2011 14:36:36 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RXw8I-0003Fa-LC
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 14:36:35 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1323182147!7720411!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM3Mzk=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16706 invoked from network); 6 Dec 2011 14:35:47 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-2.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 6 Dec 2011 14:35:47 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 06 Dec 2011 14:35:47 +0000
Message-Id: <4EDE367D0200007800065B6B@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 06 Dec 2011 14:36:29 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Stefano Stabellini" <stefano.stabellini@eu.citrix.com>,
	"Haitao Shan" <maillists.shan@gmail.com>
References: <CAFQ2Z+fpR1UkxFEAYTD6irBUBeA3c7eJ3x1bXE0jzpdfQtH64w@mail.gmail.com>
	<alpine.DEB.2.00.1112021223190.31179@kaball-desktop>
In-Reply-To: <alpine.DEB.2.00.1112021223190.31179@kaball-desktop>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartAD82307D.3__="
Cc: Haitao Shan <haitao.shan@intel.com>, Keir Fraser <keir@xen.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] Qemu MSI Cleaning Up
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__PartAD82307D.3__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

>>> On 02.12.11 at 13:40, Stefano Stabellini <stefano.stabellini@eu.citrix.=
com> wrote:
> The two mapping and unmapping big chuncks of code looks very similar
> apart from the DPCI_ADD_MAPPING/DPCI_REMOVE_MAPPING parameter.
> Could they be refactored into a single function called=20
> "change_msix_mappings"?
> This is more or less what I have in mind:
>=20
> change_msix_mappings(assigned_device, DPCI_REMOVE_MAPPING);
>=20
> update mmio_base_addr
>=20
> change_msix_mappings(assigned_device, DPCI_ADD_MAPPING);

Please see below/attached for the outcome. Without MSI-X capable
devices to pass through, I have to rely on others to do some testing
on this.

Jan

qemu: clean up MSI-X table handling

This patch does cleaning up of QEMU MSI handling. The fixes are:
1. Changes made to MSI-X table mapping handling to eliminate the small
windows in which guest could have access to physical MSI-X table.
2. MSI-X table is mapped as read-only to QEMU, as masking of MSI-X is
already in Xen now.
3. For registers that coexists inside the MSI-X table (this could be
only PBA I think), value read from physical page would be returned.

Signed-off-by:  Shan Haitao <maillists.shan@gmail.com>

Consolidated duplicate code into _pt_iomem_helper(). Fixed formatting.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/hw/pass-through.c
+++ b/hw/pass-through.c
@@ -92,6 +92,7 @@
=20
 #include <unistd.h>
 #include <sys/ioctl.h>
+#include <assert.h>
=20
 extern int gfx_passthru;
 int igd_passthru =3D 0;
@@ -1097,6 +1098,44 @@ uint8_t pci_intx(struct pt_dev *ptdev)
     return r_val;
 }
=20
+static int _pt_iomem_helper(struct pt_dev *assigned_device, int i,
+                            uint32_t e_base, uint32_t e_size, int op)
+{
+    if ( has_msix_mapping(assigned_device, i) )
+    {
+        uint32_t msix_last_pfn =3D (assigned_device->msix->mmio_base_addr =
- 1 +
+            assigned_device->msix->total_entries * 16) >> XC_PAGE_SHIFT;
+        uint32_t bar_last_pfn =3D (e_base + e_size - 1) >> XC_PAGE_SHIFT;
+        int ret =3D 0;
+
+        if ( assigned_device->msix->table_off )
+            ret =3D xc_domain_memory_mapping(xc_handle, domid,
+                e_base >> XC_PAGE_SHIFT,
+                assigned_device->bases[i].access.maddr >> XC_PAGE_SHIFT,
+                (assigned_device->msix->mmio_base_addr >> XC_PAGE_SHIFT)
+                - (e_base >> XC_PAGE_SHIFT), op);
+
+        if ( ret =3D=3D 0 && msix_last_pfn !=3D bar_last_pfn )
+        {
+            assert(msix_last_pfn < bar_last_pfn);
+            ret =3D xc_domain_memory_mapping(xc_handle, domid,
+                msix_last_pfn + 1,
+                (assigned_device->bases[i].access.maddr +
+                 assigned_device->msix->table_off +
+                 assigned_device->msix->total_entries * 16 +
+                 XC_PAGE_SIZE - 1) >> XC_PAGE_SHIFT,
+                bar_last_pfn - msix_last_pfn, op);
+        }
+
+        return ret;
+    }
+
+    return xc_domain_memory_mapping(xc_handle, domid,
+        e_base >> XC_PAGE_SHIFT,
+        assigned_device->bases[i].access.maddr >> XC_PAGE_SHIFT,
+        (e_size + XC_PAGE_SIZE - 1) >> XC_PAGE_SHIFT, op);
+}
+
 /* Being called each time a mmio region has been updated */
 static void pt_iomem_map(PCIDevice *d, int i, uint32_t e_phys, uint32_t =
e_size,
                          int type)
@@ -1118,13 +1157,11 @@ static void pt_iomem_map(PCIDevice *d, i
=20
     if ( !first_map && old_ebase !=3D -1 )
     {
-        add_msix_mapping(assigned_device, i);
-        /* Remove old mapping */
-        ret =3D xc_domain_memory_mapping(xc_handle, domid,
-                old_ebase >> XC_PAGE_SHIFT,
-                assigned_device->bases[i].access.maddr >> XC_PAGE_SHIFT,
-                (e_size+XC_PAGE_SIZE-1) >> XC_PAGE_SHIFT,
-                DPCI_REMOVE_MAPPING);
+        if ( has_msix_mapping(assigned_device, i) )
+            unregister_iomem(assigned_device->msix->mmio_base_addr);
+
+        ret =3D _pt_iomem_helper(assigned_device, i, old_ebase, e_size,
+                               DPCI_REMOVE_MAPPING);
         if ( ret !=3D 0 )
         {
             PT_LOG("Error: remove old mapping failed!\n");
@@ -1135,22 +1172,26 @@ static void pt_iomem_map(PCIDevice *d, i
     /* map only valid guest address */
     if (e_phys !=3D -1)
     {
-        /* Create new mapping */
-        ret =3D xc_domain_memory_mapping(xc_handle, domid,
-                assigned_device->bases[i].e_physbase >> XC_PAGE_SHIFT,
-                assigned_device->bases[i].access.maddr >> XC_PAGE_SHIFT,
-                (e_size+XC_PAGE_SIZE-1) >> XC_PAGE_SHIFT,
-                DPCI_ADD_MAPPING);
+        if ( has_msix_mapping(assigned_device, i) )
+        {
+            assigned_device->msix->mmio_base_addr =3D
+                assigned_device->bases[i].e_physbase
+                + assigned_device->msix->table_off;
+
+            cpu_register_physical_memory(assigned_device->msix->mmio_base_=
addr,
+                 (assigned_device->msix->total_entries * 16 + XC_PAGE_SIZE=
 - 1)
+                  & XC_PAGE_MASK,
+                 assigned_device->msix->mmio_index);
+        }
=20
+        ret =3D _pt_iomem_helper(assigned_device, i, e_phys, e_size,
+                               DPCI_ADD_MAPPING);
         if ( ret !=3D 0 )
         {
             PT_LOG("Error: create new mapping failed!\n");
+            return;
         }
=20
-        ret =3D remove_msix_mapping(assigned_device, i);
-        if ( ret !=3D 0 )
-            PT_LOG("Error: remove MSI-X mmio mapping failed!\n");
-
         if ( old_ebase !=3D e_phys && old_ebase !=3D -1 )
             pt_msix_update_remap(assigned_device, i);
     }
--- a/hw/pt-msi.c
+++ b/hw/pt-msi.c
@@ -284,15 +284,6 @@ void pt_disable_msi_translate(struct pt_
     dev->msi_trans_en =3D 0;
 }
=20
-/* MSI-X virtulization functions */
-static void mask_physical_msix_entry(struct pt_dev *dev, int entry_nr, =
int mask)
-{
-    void *phys_off;
-
-    phys_off =3D dev->msix->phys_iomem_base + 16 * entry_nr + 12;
-    *(uint32_t *)phys_off =3D mask;
-}
-
 static int pt_msix_update_one(struct pt_dev *dev, int entry_nr)
 {
     struct msix_entry_info *entry =3D &dev->msix->msix_entry[entry_nr];
@@ -486,7 +477,6 @@ static void pci_msix_writel(void *opaque
     {
         if ( msix->enabled && !(val & 0x1) )
             pt_msix_update_one(dev, entry_nr);
-        mask_physical_msix_entry(dev, entry_nr, entry->io_mem[3] & 0x1);
     }
 }
=20
@@ -519,7 +509,11 @@ static uint32_t pci_msix_readl(void *opa
     entry_nr =3D (addr - msix->mmio_base_addr) / 16;
     offset =3D ((addr - msix->mmio_base_addr) % 16) / 4;
=20
-    return msix->msix_entry[entry_nr].io_mem[offset];
+    if ( addr - msix->mmio_base_addr < msix->total_entries * 16 )
+        return msix->msix_entry[entry_nr].io_mem[offset];
+    else
+        return *(uint32_t *)(msix->phys_iomem_base +
+                             (addr - msix->mmio_base_addr));
 }
=20
 static CPUReadMemoryFunc *pci_msix_read[] =3D {
@@ -528,39 +522,12 @@ static CPUReadMemoryFunc *pci_msix_read[
     pci_msix_readl
 };
=20
-int add_msix_mapping(struct pt_dev *dev, int bar_index)
+int has_msix_mapping(struct pt_dev *dev, int bar_index)
 {
     if ( !(dev->msix && dev->msix->bar_index =3D=3D bar_index) )
         return 0;
=20
-    return xc_domain_memory_mapping(xc_handle, domid,
-                dev->msix->mmio_base_addr >> XC_PAGE_SHIFT,
-                (dev->bases[bar_index].access.maddr
-                + dev->msix->table_off) >> XC_PAGE_SHIFT,
-                (dev->msix->total_entries * 16
-                + XC_PAGE_SIZE -1) >> XC_PAGE_SHIFT,
-                DPCI_ADD_MAPPING);
-}
-
-int remove_msix_mapping(struct pt_dev *dev, int bar_index)
-{
-    if ( !(dev->msix && dev->msix->bar_index =3D=3D bar_index) )
-        return 0;
-
-    dev->msix->mmio_base_addr =3D dev->bases[bar_index].e_physbase
-                                + dev->msix->table_off;
-
-    cpu_register_physical_memory(dev->msix->mmio_base_addr,
-                                 dev->msix->total_entries * 16,
-                                 dev->msix->mmio_index);
-
-    return xc_domain_memory_mapping(xc_handle, domid,
-                dev->msix->mmio_base_addr >> XC_PAGE_SHIFT,
-                (dev->bases[bar_index].access.maddr
-                + dev->msix->table_off) >> XC_PAGE_SHIFT,
-                (dev->msix->total_entries * 16
-                + XC_PAGE_SIZE -1) >> XC_PAGE_SHIFT,
-                DPCI_REMOVE_MAPPING);
+    return 1;
 }
=20
 int pt_msix_init(struct pt_dev *dev, int pos)
@@ -616,7 +583,7 @@ int pt_msix_init(struct pt_dev *dev, int
     PT_LOG("table_off =3D %x, total_entries =3D %d\n", table_off, =
total_entries);
     dev->msix->table_offset_adjust =3D table_off & 0x0fff;
     dev->msix->phys_iomem_base =3D mmap(0, total_entries * 16 + dev->msix-=
>table_offset_adjust,
-                          PROT_WRITE | PROT_READ, MAP_SHARED | MAP_LOCKED,=

+                          PROT_READ, MAP_SHARED | MAP_LOCKED,
                           fd, dev->msix->table_base + table_off - =
dev->msix->table_offset_adjust);
     dev->msix->phys_iomem_base =3D (void *)((char *)dev->msix->phys_iomem_=
base +=20
                           dev->msix->table_offset_adjust);
--- a/hw/pt-msi.h
+++ b/hw/pt-msi.h
@@ -107,10 +107,7 @@ void
 pt_msix_disable(struct pt_dev *dev);
=20
 int
-remove_msix_mapping(struct pt_dev *dev, int bar_index);
-
-int
-add_msix_mapping(struct pt_dev *dev, int bar_index);
+has_msix_mapping(struct pt_dev *dev, int bar_index);
=20
 int
 pt_msix_init(struct pt_dev *dev, int pos);



--=__PartAD82307D.3__=
Content-Type: text/plain; name="qemu-msix-cleanup.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="qemu-msix-cleanup.patch"

qemu: clean up MSI-X table handling=0A=0AThis patch does cleaning up of =
QEMU MSI handling. The fixes are:=0A1. Changes made to MSI-X table mapping =
handling to eliminate the small=0Awindows in which guest could have access =
to physical MSI-X table.=0A2. MSI-X table is mapped as read-only to QEMU, =
as masking of MSI-X is=0Aalready in Xen now.=0A3. For registers that =
coexists inside the MSI-X table (this could be=0Aonly PBA I think), value =
read from physical page would be returned.=0A=0ASigned-off-by:  Shan =
Haitao <maillists.shan@gmail.com>=0A=0AConsolidated duplicate code into =
_pt_iomem_helper(). Fixed formatting.=0A=0ASigned-off-by: Jan Beulich =
<jbeulich@suse.com>=0A=0A--- a/hw/pass-through.c=0A+++ b/hw/pass-through.c=
=0A@@ -92,6 +92,7 @@=0A =0A #include <unistd.h>=0A #include <sys/ioctl.h>=
=0A+#include <assert.h>=0A =0A extern int gfx_passthru;=0A int igd_passthru=
 =3D 0;=0A@@ -1097,6 +1098,44 @@ uint8_t pci_intx(struct pt_dev *ptdev)=0A =
    return r_val;=0A }=0A =0A+static int _pt_iomem_helper(struct pt_dev =
*assigned_device, int i,=0A+                            uint32_t e_base, =
uint32_t e_size, int op)=0A+{=0A+    if ( has_msix_mapping(assigned_device,=
 i) )=0A+    {=0A+        uint32_t msix_last_pfn =3D (assigned_device->msix=
->mmio_base_addr - 1 +=0A+            assigned_device->msix->total_entries =
* 16) >> XC_PAGE_SHIFT;=0A+        uint32_t bar_last_pfn =3D (e_base + =
e_size - 1) >> XC_PAGE_SHIFT;=0A+        int ret =3D 0;=0A+=0A+        if =
( assigned_device->msix->table_off )=0A+            ret =3D xc_domain_memor=
y_mapping(xc_handle, domid,=0A+                e_base >> XC_PAGE_SHIFT,=0A+=
                assigned_device->bases[i].access.maddr >> XC_PAGE_SHIFT,=0A=
+                (assigned_device->msix->mmio_base_addr >> XC_PAGE_SHIFT)=
=0A+                - (e_base >> XC_PAGE_SHIFT), op);=0A+=0A+        if ( =
ret =3D=3D 0 && msix_last_pfn !=3D bar_last_pfn )=0A+        {=0A+         =
   assert(msix_last_pfn < bar_last_pfn);=0A+            ret =3D xc_domain_m=
emory_mapping(xc_handle, domid,=0A+                msix_last_pfn + 1,=0A+  =
              (assigned_device->bases[i].access.maddr +=0A+                =
 assigned_device->msix->table_off +=0A+                 assigned_device->ms=
ix->total_entries * 16 +=0A+                 XC_PAGE_SIZE - 1) >> =
XC_PAGE_SHIFT,=0A+                bar_last_pfn - msix_last_pfn, op);=0A+   =
     }=0A+=0A+        return ret;=0A+    }=0A+=0A+    return xc_domain_memo=
ry_mapping(xc_handle, domid,=0A+        e_base >> XC_PAGE_SHIFT,=0A+       =
 assigned_device->bases[i].access.maddr >> XC_PAGE_SHIFT,=0A+        =
(e_size + XC_PAGE_SIZE - 1) >> XC_PAGE_SHIFT, op);=0A+}=0A+=0A /* Being =
called each time a mmio region has been updated */=0A static void =
pt_iomem_map(PCIDevice *d, int i, uint32_t e_phys, uint32_t e_size,=0A     =
                     int type)=0A@@ -1118,13 +1157,11 @@ static void =
pt_iomem_map(PCIDevice *d, i=0A =0A     if ( !first_map && old_ebase !=3D =
-1 )=0A     {=0A-        add_msix_mapping(assigned_device, i);=0A-        =
/* Remove old mapping */=0A-        ret =3D xc_domain_memory_mapping(xc_han=
dle, domid,=0A-                old_ebase >> XC_PAGE_SHIFT,=0A-             =
   assigned_device->bases[i].access.maddr >> XC_PAGE_SHIFT,=0A-            =
    (e_size+XC_PAGE_SIZE-1) >> XC_PAGE_SHIFT,=0A-                DPCI_REMOV=
E_MAPPING);=0A+        if ( has_msix_mapping(assigned_device, i) )=0A+     =
       unregister_iomem(assigned_device->msix->mmio_base_addr);=0A+=0A+    =
    ret =3D _pt_iomem_helper(assigned_device, i, old_ebase, e_size,=0A+    =
                           DPCI_REMOVE_MAPPING);=0A         if ( ret !=3D =
0 )=0A         {=0A             PT_LOG("Error: remove old mapping =
failed!\n");=0A@@ -1135,22 +1172,26 @@ static void pt_iomem_map(PCIDevice =
*d, i=0A     /* map only valid guest address */=0A     if (e_phys !=3D =
-1)=0A     {=0A-        /* Create new mapping */=0A-        ret =3D =
xc_domain_memory_mapping(xc_handle, domid,=0A-                assigned_devi=
ce->bases[i].e_physbase >> XC_PAGE_SHIFT,=0A-                assigned_devic=
e->bases[i].access.maddr >> XC_PAGE_SHIFT,=0A-                (e_size+XC_PA=
GE_SIZE-1) >> XC_PAGE_SHIFT,=0A-                DPCI_ADD_MAPPING);=0A+     =
   if ( has_msix_mapping(assigned_device, i) )=0A+        {=0A+            =
assigned_device->msix->mmio_base_addr =3D=0A+                assigned_devic=
e->bases[i].e_physbase=0A+                + assigned_device->msix->table_of=
f;=0A+=0A+            cpu_register_physical_memory(assigned_device->msix->m=
mio_base_addr,=0A+                 (assigned_device->msix->total_entries * =
16 + XC_PAGE_SIZE - 1)=0A+                  & XC_PAGE_MASK,=0A+            =
     assigned_device->msix->mmio_index);=0A+        }=0A =0A+        ret =
=3D _pt_iomem_helper(assigned_device, i, e_phys, e_size,=0A+               =
                DPCI_ADD_MAPPING);=0A         if ( ret !=3D 0 )=0A         =
{=0A             PT_LOG("Error: create new mapping failed!\n");=0A+        =
    return;=0A         }=0A =0A-        ret =3D remove_msix_mapping(assigne=
d_device, i);=0A-        if ( ret !=3D 0 )=0A-            PT_LOG("Error: =
remove MSI-X mmio mapping failed!\n");=0A-=0A         if ( old_ebase !=3D =
e_phys && old_ebase !=3D -1 )=0A             pt_msix_update_remap(assigned_=
device, i);=0A     }=0A--- a/hw/pt-msi.c=0A+++ b/hw/pt-msi.c=0A@@ -284,15 =
+284,6 @@ void pt_disable_msi_translate(struct pt_=0A     dev->msi_trans_en=
 =3D 0;=0A }=0A =0A-/* MSI-X virtulization functions */=0A-static void =
mask_physical_msix_entry(struct pt_dev *dev, int entry_nr, int mask)=0A-{=
=0A-    void *phys_off;=0A-=0A-    phys_off =3D dev->msix->phys_iomem_base =
+ 16 * entry_nr + 12;=0A-    *(uint32_t *)phys_off =3D mask;=0A-}=0A-=0A =
static int pt_msix_update_one(struct pt_dev *dev, int entry_nr)=0A {=0A    =
 struct msix_entry_info *entry =3D &dev->msix->msix_entry[entry_nr];=0A@@ =
-486,7 +477,6 @@ static void pci_msix_writel(void *opaque=0A     {=0A      =
   if ( msix->enabled && !(val & 0x1) )=0A             pt_msix_update_one(d=
ev, entry_nr);=0A-        mask_physical_msix_entry(dev, entry_nr, =
entry->io_mem[3] & 0x1);=0A     }=0A }=0A =0A@@ -519,7 +509,11 @@ static =
uint32_t pci_msix_readl(void *opa=0A     entry_nr =3D (addr - msix->mmio_ba=
se_addr) / 16;=0A     offset =3D ((addr - msix->mmio_base_addr) % 16) / =
4;=0A =0A-    return msix->msix_entry[entry_nr].io_mem[offset];=0A+    if =
( addr - msix->mmio_base_addr < msix->total_entries * 16 )=0A+        =
return msix->msix_entry[entry_nr].io_mem[offset];=0A+    else=0A+        =
return *(uint32_t *)(msix->phys_iomem_base +=0A+                           =
  (addr - msix->mmio_base_addr));=0A }=0A =0A static CPUReadMemoryFunc =
*pci_msix_read[] =3D {=0A@@ -528,39 +522,12 @@ static CPUReadMemoryFunc =
*pci_msix_read[=0A     pci_msix_readl=0A };=0A =0A-int add_msix_mapping(str=
uct pt_dev *dev, int bar_index)=0A+int has_msix_mapping(struct pt_dev =
*dev, int bar_index)=0A {=0A     if ( !(dev->msix && dev->msix->bar_index =
=3D=3D bar_index) )=0A         return 0;=0A =0A-    return xc_domain_memory=
_mapping(xc_handle, domid,=0A-                dev->msix->mmio_base_addr >> =
XC_PAGE_SHIFT,=0A-                (dev->bases[bar_index].access.maddr=0A-  =
              + dev->msix->table_off) >> XC_PAGE_SHIFT,=0A-                =
(dev->msix->total_entries * 16=0A-                + XC_PAGE_SIZE -1) >> =
XC_PAGE_SHIFT,=0A-                DPCI_ADD_MAPPING);=0A-}=0A-=0A-int =
remove_msix_mapping(struct pt_dev *dev, int bar_index)=0A-{=0A-    if ( =
!(dev->msix && dev->msix->bar_index =3D=3D bar_index) )=0A-        return =
0;=0A-=0A-    dev->msix->mmio_base_addr =3D dev->bases[bar_index].e_physbas=
e=0A-                                + dev->msix->table_off;=0A-=0A-    =
cpu_register_physical_memory(dev->msix->mmio_base_addr,=0A-                =
                 dev->msix->total_entries * 16,=0A-                        =
         dev->msix->mmio_index);=0A-=0A-    return xc_domain_memory_mapping=
(xc_handle, domid,=0A-                dev->msix->mmio_base_addr >> =
XC_PAGE_SHIFT,=0A-                (dev->bases[bar_index].access.maddr=0A-  =
              + dev->msix->table_off) >> XC_PAGE_SHIFT,=0A-                =
(dev->msix->total_entries * 16=0A-                + XC_PAGE_SIZE -1) >> =
XC_PAGE_SHIFT,=0A-                DPCI_REMOVE_MAPPING);=0A+    return =
1;=0A }=0A =0A int pt_msix_init(struct pt_dev *dev, int pos)=0A@@ -616,7 =
+583,7 @@ int pt_msix_init(struct pt_dev *dev, int=0A     PT_LOG("table_off=
 =3D %x, total_entries =3D %d\n", table_off, total_entries);=0A     =
dev->msix->table_offset_adjust =3D table_off & 0x0fff;=0A     dev->msix->ph=
ys_iomem_base =3D mmap(0, total_entries * 16 + dev->msix->table_offset_adju=
st,=0A-                          PROT_WRITE | PROT_READ, MAP_SHARED | =
MAP_LOCKED,=0A+                          PROT_READ, MAP_SHARED | MAP_LOCKED=
,=0A                           fd, dev->msix->table_base + table_off - =
dev->msix->table_offset_adjust);=0A     dev->msix->phys_iomem_base =3D =
(void *)((char *)dev->msix->phys_iomem_base + =0A                          =
 dev->msix->table_offset_adjust);=0A--- a/hw/pt-msi.h=0A+++ b/hw/pt-msi.h=
=0A@@ -107,10 +107,7 @@ void=0A pt_msix_disable(struct pt_dev *dev);=0A =
=0A int=0A-remove_msix_mapping(struct pt_dev *dev, int bar_index);=0A-=0A-i=
nt=0A-add_msix_mapping(struct pt_dev *dev, int bar_index);=0A+has_msix_mapp=
ing(struct pt_dev *dev, int bar_index);=0A =0A int=0A pt_msix_init(struct =
pt_dev *dev, int pos);=0A
--=__PartAD82307D.3__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--=__PartAD82307D.3__=--


From xen-devel-bounces@lists.xensource.com Tue Dec 06 15:21:04 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 15:21:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXwol-0003ZD-1m; Tue, 06 Dec 2011 15:20:27 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RXwoj-0003Z8-FA
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 15:20:25 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1323184779!6404511!1
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3499 invoked from network); 6 Dec 2011 15:19:39 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Dec 2011 15:19:39 -0000
Received: by wgbds11 with SMTP id ds11so5466693wgb.24
	for <xen-devel@lists.xensource.com>;
	Tue, 06 Dec 2011 07:19:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=qkJ2FCPTIbcUpE6G2kqZkAQjE5QKZ0cLeIULQQOlqvU=;
	b=ke3qO1zwHDAeTqPrGIHJXqNIrsWMVfewQT2Q7sCI89BNupxdsQm55CIL9eWKpi9X16
	yOp3RC3sxUF7+hsmx2mzY21AYAyf87uGy/OuBguOUXzgSA4Lne12q8aeJ+umvLHcJVJg
	MqTs4IE0nch+Zan+kQqesO2otdDSKto1QNUSE=
Received: by 10.227.206.82 with SMTP id ft18mr11370901wbb.21.1323184779174;
	Tue, 06 Dec 2011 07:19:39 -0800 (PST)
Received: from [192.168.1.70]
	(host81-155-119-104.range81-155.btcentralplus.com. [81.155.119.104])
	by mx.google.com with ESMTPS id k5sm15182491wiz.9.2011.12.06.07.19.34
	(version=SSLv3 cipher=OTHER); Tue, 06 Dec 2011 07:19:37 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Tue, 06 Dec 2011 15:19:30 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Message-ID: <CB03E302.26975%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH linux-2.6.18/ACPI: eliminate restriction on
	ACPI processor ID range
Thread-Index: Acy0KnMflAP8/JspDESEDAmsZviM1Q==
In-Reply-To: <4EDE23E90200007800065B06@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH linux-2.6.18/ACPI: eliminate restriction on
 ACPI processor ID range
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 06/12/2011 13:17, "Jan Beulich" <JBeulich@suse.com> wrote:

> Rather than storing the reference acpi_device pointers in an ACPI-ID-
> indexed array (and having a bogus BUG_ON() check on a platform provided
> value), use a radix tree instead.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Keir Fraser <keir@xen.org>

> --- a/drivers/acpi/processor_core.c
> +++ b/drivers/acpi/processor_core.c
> @@ -513,7 +513,14 @@ static int acpi_processor_get_info(struc
> return 0;
>  }
>  
> -static void *processor_device_array[NR_ACPI_CPUS];
> +#ifndef CONFIG_XEN
> +static void *processor_device_array[NR_CPUS];
> +#else
> +#include <linux/mutex.h>
> +#include <linux/radix-tree.h>
> +static DEFINE_MUTEX(processor_device_mutex);
> +static RADIX_TREE(processor_device_tree, GFP_KERNEL);
> +#endif
>  
>  static int acpi_processor_start(struct acpi_device *device)
>  {
> @@ -541,9 +548,20 @@ static int __cpuinit acpi_processor_add(
> * Don't trust it blindly
> */
>  #ifdef CONFIG_XEN
> - BUG_ON(pr->acpi_id >= NR_ACPI_CPUS);
> - if (processor_device_array[pr->acpi_id] != NULL &&
> -     processor_device_array[pr->acpi_id] != (void *)device) {
> + mutex_lock(&processor_device_mutex);
> + result = radix_tree_insert(&processor_device_tree,
> +       pr->acpi_id, device);
> + switch (result) {
> + default:
> +  goto end_unlock;
> + case -EEXIST:
> +  if (radix_tree_lookup(&processor_device_tree,
> +          pr->acpi_id) == device) {
> + case 0:
> +   mutex_unlock(&processor_device_mutex);
> +   break;
> +  }
> +  mutex_unlock(&processor_device_mutex);
>  #else
> if (processor_device_array[pr->id] != NULL &&
>    processor_device_array[pr->id] != (void *)device) {
> @@ -553,14 +571,11 @@ static int __cpuinit acpi_processor_add(
> return -ENODEV;
> }
>  #ifdef CONFIG_XEN
> - processor_device_array[pr->acpi_id] = (void *)device;
> if (pr->id != -1)
> -  processors[pr->id] = pr;
>  #else
> processor_device_array[pr->id] = (void *)device;
> -
> - processors[pr->id] = pr;
>  #endif /* CONFIG_XEN */
> + processors[pr->id] = pr;
>  
> result = acpi_processor_add_fs(device);
> if (result)
> @@ -602,6 +617,14 @@ err_thermal_unregister:
> }
>  
>        end:
> +#ifdef CONFIG_XEN
> + mutex_lock(&processor_device_mutex);
> + if (radix_tree_lookup(&processor_device_tree,
> +         pr->acpi_id) == device)
> +  radix_tree_delete(&processor_device_tree, pr->acpi_id);
> +      end_unlock:
> + mutex_unlock(&processor_device_mutex);
> +#endif
>  
> return result;
>  }
> @@ -692,10 +715,8 @@ static int acpi_processor_remove(struct
>  
>  #ifdef CONFIG_XEN
> if (pr->id != -1)
> -  processors[pr->id] = NULL;
> -#else
> +#endif
> processors[pr->id] = NULL;
> -#endif /* CONFIG_XEN */
>  
>  
> kfree(pr);
> @@ -992,6 +1013,30 @@ static void __exit acpi_processor_exit(v
>  
> remove_proc_entry(ACPI_PROCESSOR_CLASS, acpi_root_dir);
>  
> +#ifdef CONFIG_XEN
> + {
> +  struct acpi_device *dev;
> +  unsigned int idx = 0;
> +
> +  while (radix_tree_gang_lookup(&processor_device_tree,
> +           (void **)&dev, idx, 1)) {
> +   struct acpi_processor *pr = acpi_driver_data(dev);
> +
> +   /* prevent live lock */
> +   if (pr->acpi_id < idx) {
> +    printk(KERN_WARNING PREFIX "ID %u unexpected"
> +           " (less than %u); leaking memory\n",
> +           pr->acpi_id, idx);
> +    break;
> +   }
> +   idx = pr->acpi_id;
> +   radix_tree_delete(&processor_device_tree, idx);
> +   if (!++idx)
> +    break;
> +  }
> + }
> +#endif
> +
> return;
>  }
>  
> --- a/include/acpi/processor.h
> +++ b/include/acpi/processor.h
> @@ -24,12 +24,6 @@
>  #define ACPI_TSD_REV0_REVISION  0 /* Support for _PSD as in ACPI 3.0 */
>  #define ACPI_TSD_REV0_ENTRIES  5
>  
> -#ifdef CONFIG_XEN
> -#define NR_ACPI_CPUS   (NR_CPUS < 256 ? 256 : NR_CPUS)
> -#else
> -#define NR_ACPI_CPUS   NR_CPUS
> -#endif /* CONFIG_XEN */
> -
>  /*
>   * Types of coordination defined in ACPI 3.0. Same macros can be used across
>   * P, C and T states
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 15:21:04 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 15:21:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXwol-0003ZD-1m; Tue, 06 Dec 2011 15:20:27 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RXwoj-0003Z8-FA
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 15:20:25 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1323184779!6404511!1
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3499 invoked from network); 6 Dec 2011 15:19:39 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Dec 2011 15:19:39 -0000
Received: by wgbds11 with SMTP id ds11so5466693wgb.24
	for <xen-devel@lists.xensource.com>;
	Tue, 06 Dec 2011 07:19:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=qkJ2FCPTIbcUpE6G2kqZkAQjE5QKZ0cLeIULQQOlqvU=;
	b=ke3qO1zwHDAeTqPrGIHJXqNIrsWMVfewQT2Q7sCI89BNupxdsQm55CIL9eWKpi9X16
	yOp3RC3sxUF7+hsmx2mzY21AYAyf87uGy/OuBguOUXzgSA4Lne12q8aeJ+umvLHcJVJg
	MqTs4IE0nch+Zan+kQqesO2otdDSKto1QNUSE=
Received: by 10.227.206.82 with SMTP id ft18mr11370901wbb.21.1323184779174;
	Tue, 06 Dec 2011 07:19:39 -0800 (PST)
Received: from [192.168.1.70]
	(host81-155-119-104.range81-155.btcentralplus.com. [81.155.119.104])
	by mx.google.com with ESMTPS id k5sm15182491wiz.9.2011.12.06.07.19.34
	(version=SSLv3 cipher=OTHER); Tue, 06 Dec 2011 07:19:37 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Tue, 06 Dec 2011 15:19:30 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Message-ID: <CB03E302.26975%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH linux-2.6.18/ACPI: eliminate restriction on
	ACPI processor ID range
Thread-Index: Acy0KnMflAP8/JspDESEDAmsZviM1Q==
In-Reply-To: <4EDE23E90200007800065B06@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH linux-2.6.18/ACPI: eliminate restriction on
 ACPI processor ID range
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 06/12/2011 13:17, "Jan Beulich" <JBeulich@suse.com> wrote:

> Rather than storing the reference acpi_device pointers in an ACPI-ID-
> indexed array (and having a bogus BUG_ON() check on a platform provided
> value), use a radix tree instead.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Keir Fraser <keir@xen.org>

> --- a/drivers/acpi/processor_core.c
> +++ b/drivers/acpi/processor_core.c
> @@ -513,7 +513,14 @@ static int acpi_processor_get_info(struc
> return 0;
>  }
>  
> -static void *processor_device_array[NR_ACPI_CPUS];
> +#ifndef CONFIG_XEN
> +static void *processor_device_array[NR_CPUS];
> +#else
> +#include <linux/mutex.h>
> +#include <linux/radix-tree.h>
> +static DEFINE_MUTEX(processor_device_mutex);
> +static RADIX_TREE(processor_device_tree, GFP_KERNEL);
> +#endif
>  
>  static int acpi_processor_start(struct acpi_device *device)
>  {
> @@ -541,9 +548,20 @@ static int __cpuinit acpi_processor_add(
> * Don't trust it blindly
> */
>  #ifdef CONFIG_XEN
> - BUG_ON(pr->acpi_id >= NR_ACPI_CPUS);
> - if (processor_device_array[pr->acpi_id] != NULL &&
> -     processor_device_array[pr->acpi_id] != (void *)device) {
> + mutex_lock(&processor_device_mutex);
> + result = radix_tree_insert(&processor_device_tree,
> +       pr->acpi_id, device);
> + switch (result) {
> + default:
> +  goto end_unlock;
> + case -EEXIST:
> +  if (radix_tree_lookup(&processor_device_tree,
> +          pr->acpi_id) == device) {
> + case 0:
> +   mutex_unlock(&processor_device_mutex);
> +   break;
> +  }
> +  mutex_unlock(&processor_device_mutex);
>  #else
> if (processor_device_array[pr->id] != NULL &&
>    processor_device_array[pr->id] != (void *)device) {
> @@ -553,14 +571,11 @@ static int __cpuinit acpi_processor_add(
> return -ENODEV;
> }
>  #ifdef CONFIG_XEN
> - processor_device_array[pr->acpi_id] = (void *)device;
> if (pr->id != -1)
> -  processors[pr->id] = pr;
>  #else
> processor_device_array[pr->id] = (void *)device;
> -
> - processors[pr->id] = pr;
>  #endif /* CONFIG_XEN */
> + processors[pr->id] = pr;
>  
> result = acpi_processor_add_fs(device);
> if (result)
> @@ -602,6 +617,14 @@ err_thermal_unregister:
> }
>  
>        end:
> +#ifdef CONFIG_XEN
> + mutex_lock(&processor_device_mutex);
> + if (radix_tree_lookup(&processor_device_tree,
> +         pr->acpi_id) == device)
> +  radix_tree_delete(&processor_device_tree, pr->acpi_id);
> +      end_unlock:
> + mutex_unlock(&processor_device_mutex);
> +#endif
>  
> return result;
>  }
> @@ -692,10 +715,8 @@ static int acpi_processor_remove(struct
>  
>  #ifdef CONFIG_XEN
> if (pr->id != -1)
> -  processors[pr->id] = NULL;
> -#else
> +#endif
> processors[pr->id] = NULL;
> -#endif /* CONFIG_XEN */
>  
>  
> kfree(pr);
> @@ -992,6 +1013,30 @@ static void __exit acpi_processor_exit(v
>  
> remove_proc_entry(ACPI_PROCESSOR_CLASS, acpi_root_dir);
>  
> +#ifdef CONFIG_XEN
> + {
> +  struct acpi_device *dev;
> +  unsigned int idx = 0;
> +
> +  while (radix_tree_gang_lookup(&processor_device_tree,
> +           (void **)&dev, idx, 1)) {
> +   struct acpi_processor *pr = acpi_driver_data(dev);
> +
> +   /* prevent live lock */
> +   if (pr->acpi_id < idx) {
> +    printk(KERN_WARNING PREFIX "ID %u unexpected"
> +           " (less than %u); leaking memory\n",
> +           pr->acpi_id, idx);
> +    break;
> +   }
> +   idx = pr->acpi_id;
> +   radix_tree_delete(&processor_device_tree, idx);
> +   if (!++idx)
> +    break;
> +  }
> + }
> +#endif
> +
> return;
>  }
>  
> --- a/include/acpi/processor.h
> +++ b/include/acpi/processor.h
> @@ -24,12 +24,6 @@
>  #define ACPI_TSD_REV0_REVISION  0 /* Support for _PSD as in ACPI 3.0 */
>  #define ACPI_TSD_REV0_ENTRIES  5
>  
> -#ifdef CONFIG_XEN
> -#define NR_ACPI_CPUS   (NR_CPUS < 256 ? 256 : NR_CPUS)
> -#else
> -#define NR_ACPI_CPUS   NR_CPUS
> -#endif /* CONFIG_XEN */
> -
>  /*
>   * Types of coordination defined in ACPI 3.0. Same macros can be used across
>   * P, C and T states
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 15:21:29 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 15:21:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXwpG-0003aG-GB; Tue, 06 Dec 2011 15:20:58 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <tobias.geiger@vido.info>) id 1RXwpE-0003Zw-Rr
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 15:20:57 +0000
X-Env-Sender: tobias.geiger@vido.info
X-Msg-Ref: server-4.tower-174.messagelabs.com!1323184810!4467566!1
X-Originating-IP: [78.47.43.171]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1274 invoked from network); 6 Dec 2011 15:20:10 -0000
Received: from www.vido.info (HELO mail.vido.info) (78.47.43.171)
	by server-4.tower-174.messagelabs.com with SMTP;
	6 Dec 2011 15:20:10 -0000
Received: from localhost (ip6-localhost [127.0.0.1])
	by mail.vido.info (Postfix) with ESMTP id 8F06F2768007;
	Tue,  6 Dec 2011 16:20:09 +0100 (CET)
X-Virus-Scanned: by amavis at mail.vido.info
Received: from mail.vido.info ([127.0.0.1])
	by localhost (mail.vido.info [127.0.0.1]) (amavisd-new, port 10024)
	with LMTP id WQVqnriF8bum; Tue,  6 Dec 2011 16:20:01 +0100 (CET)
Received: from lxgeigert.localnet (et-1-10.gw-nat.bs.kae.de.oneandone.net
	[212.227.35.74])
	by mail.vido.info (Postfix) with ESMTPSA id 7E6C02768004;
	Tue,  6 Dec 2011 16:20:01 +0100 (CET)
From: Tobias Geiger <tobias.geiger@vido.info>
Organization: VIDO IT-Service
To: xen-devel@lists.xensource.com,
 David TECHER <davidtecher@yahoo.fr>
Date: Tue, 6 Dec 2011 16:19:55 +0100
User-Agent: KMail/1.13.7 (Linux/3.0.0-1-amd64; KDE/4.6.5; x86_64; ; )
References: <1316777654598-4833174.post@n5.nabble.com>
	<1323173094434-5051880.post@n5.nabble.com>
	<1323179850.78658.YahooMailNeo@web29801.mail.ird.yahoo.com>
In-Reply-To: <1323179850.78658.YahooMailNeo@web29801.mail.ird.yahoo.com>
MIME-Version: 1.0
Message-Id: <201112061619.56224.tobias.geiger@vido.info>
Cc: n4rC0t1C <shandivo@gmail.com>
Subject: Re: [Xen-devel] Re : Re : Re : Re : Re : Re : Re : Re : Re: Patches
	for VGA-Passthrough XEN 4.2 unstable
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-15"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hello,

glad to hear it works for you!

As i run a similar setup, perhaps you can share your experience regarding =

DomU-Reboot with a VGA Card passed through to it: Does a reboot work, i.e. =

does the passed-through VGA Card work after a DomU reboot?

My hole System (DomU + Dom0) freezes after a reboot of DomU (exaclty then, =

when the passed-through VGA Card is accessed...), therefore the question.

Thanks for your info!
Greetings
Tobias

Am Dienstag, 6. Dezember 2011, 14:57:30 schrieb David TECHER:
> Hi
> =

> Thanks for these informations. I am on Debian. So it could be usefull for
> Ubuntu users.
> =

> Thanks.
> =

> David
> =

> =

> =

> ________________________________
>  De : n4rC0t1C <shandivo@gmail.com>
> =C0 : xen-devel@lists.xensource.com
> Envoy=E9 le : Mardi 6 D=E9cembre 2011 13h04
> Objet : Re: [Xen-devel] Re : Re : Re : Re : Re : Re : Re : Re: Patches for
> VGA-Passthrough XEN 4.2 unstable
> =

> Iep I used your last patches, (your website it's at the top of my
> bookmarks), and they apply to xen-unstable rev. 24341 as well (which i'm
> using).
> =

> I forgot to mention that I had to make a couple of fix to xen tree, cause
> it wasn't compiling on my system due to  "error: format not a string
> literal and no format arguments":
> =

> =

> --- /usr/src/xen-unstable.hg-rev-24341-460gtx/tools/libxl/libxl_create.c
> +++ /usr/src/xen-unstable.hg-rev-24341-460gtx/tools/libxl/libxl_create.c
> @@ -462,7 +462,7 @@
>      path =3D libxl__xs_libxl_path(gc, domid);
>      path =3D libxl__sprintf(gc, "%s/dm-version", path);
>      return libxl__xs_write(gc, XBT_NULL, path, libxl__strdup(gc,
> -     =

> libxl_device_model_version_to_string(dm_info->device_model_version)));
> +     =

> libxl_device_model_version_to_string(dm_info->device_model_version)),"%s"=
);
> }
> =

> static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
> =

> =

> --- /usr/src/xen-unstable.hg-rev-24341-460gtx/tools/libxl/libxl_device.c
> +++ /usr/src/xen-unstable.hg-rev-24341-460gtx/tools/libxl/libxl_device.c
> @@ -516,7 +516,7 @@
>          for (j =3D 0; j < num_devs; j++) {
>              path =3D libxl__sprintf(gc,
> "/local/domain/%d/device/%s/%s/backend",
>                                    domid, kinds[i], devs[j]);
> -            path =3D libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, pat=
h));
> +            path =3D libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc,
> path,"%s"));
>              if (path && libxl__parse_backend_path(gc, path, &dev) =3D=3D=
 0) {
>                  dev.domid =3D domid;
>                  dev.kind =3D kind;
> =

> and an due to an argument missing:
> =

> --- /usr/src/xen-unstable.hg-rev-24341-460gtx/tools/libxl/libxl_dom.c
> +++ /usr/src/xen-unstable.hg-rev-24341-460gtx/tools/libxl/libxl_dom.c
> @@ -625,7 +625,7 @@
>          break;
>      }
>      case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
> -        fd2 =3D open(filename, O_WRONLY | O_CREAT | O_TRUNC);
> +        fd2 =3D open(filename, O_WRONLY | O_CREAT | O_TRUNC, 0644);
>          if (fd2 < 0) {
>              LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
>                               "Unable to create a QEMU save file\n");
> =

> As far as I know those doesn't break anything, but dont take too seriousl=
y,
> i'm not an experienced developer :)
> =

> =

> Forgot 2:
> Since I'm using an ubuntu kernel, the xen support is not integrated, but
> you need to add xen modules at your inittrd file. I did this by adding
> those:
> =

> xen-pciback passthrough=3D1
> xen-blkback
> xenfs
> xen-netback
> pci-stub
> =

> to /etc/xen/initramfs-tools/modules and the issuing update-initramfs.
> =

> In the future, I'll try to boot a linux domU, right now I'm still smiling
> cause I can fully wipe my Windows installation from the hard disk. And I'm
> sure that in future Win7 will be supported too.
> =

> Thanks again David and everyone,
> Ivo
> =

> --
> View this message in context:
> http://xen.1045712.n5.nabble.com/Patches-for-VGA-Passthrough-XEN-4-2-unsta
> ble-tp4406265p5051880.html Sent from the Xen - Dev mailing list archive at
> Nabble.com.
> =

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 15:21:29 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 15:21:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXwpG-0003aG-GB; Tue, 06 Dec 2011 15:20:58 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <tobias.geiger@vido.info>) id 1RXwpE-0003Zw-Rr
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 15:20:57 +0000
X-Env-Sender: tobias.geiger@vido.info
X-Msg-Ref: server-4.tower-174.messagelabs.com!1323184810!4467566!1
X-Originating-IP: [78.47.43.171]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1274 invoked from network); 6 Dec 2011 15:20:10 -0000
Received: from www.vido.info (HELO mail.vido.info) (78.47.43.171)
	by server-4.tower-174.messagelabs.com with SMTP;
	6 Dec 2011 15:20:10 -0000
Received: from localhost (ip6-localhost [127.0.0.1])
	by mail.vido.info (Postfix) with ESMTP id 8F06F2768007;
	Tue,  6 Dec 2011 16:20:09 +0100 (CET)
X-Virus-Scanned: by amavis at mail.vido.info
Received: from mail.vido.info ([127.0.0.1])
	by localhost (mail.vido.info [127.0.0.1]) (amavisd-new, port 10024)
	with LMTP id WQVqnriF8bum; Tue,  6 Dec 2011 16:20:01 +0100 (CET)
Received: from lxgeigert.localnet (et-1-10.gw-nat.bs.kae.de.oneandone.net
	[212.227.35.74])
	by mail.vido.info (Postfix) with ESMTPSA id 7E6C02768004;
	Tue,  6 Dec 2011 16:20:01 +0100 (CET)
From: Tobias Geiger <tobias.geiger@vido.info>
Organization: VIDO IT-Service
To: xen-devel@lists.xensource.com,
 David TECHER <davidtecher@yahoo.fr>
Date: Tue, 6 Dec 2011 16:19:55 +0100
User-Agent: KMail/1.13.7 (Linux/3.0.0-1-amd64; KDE/4.6.5; x86_64; ; )
References: <1316777654598-4833174.post@n5.nabble.com>
	<1323173094434-5051880.post@n5.nabble.com>
	<1323179850.78658.YahooMailNeo@web29801.mail.ird.yahoo.com>
In-Reply-To: <1323179850.78658.YahooMailNeo@web29801.mail.ird.yahoo.com>
MIME-Version: 1.0
Message-Id: <201112061619.56224.tobias.geiger@vido.info>
Cc: n4rC0t1C <shandivo@gmail.com>
Subject: Re: [Xen-devel] Re : Re : Re : Re : Re : Re : Re : Re : Re: Patches
	for VGA-Passthrough XEN 4.2 unstable
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-15"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hello,

glad to hear it works for you!

As i run a similar setup, perhaps you can share your experience regarding =

DomU-Reboot with a VGA Card passed through to it: Does a reboot work, i.e. =

does the passed-through VGA Card work after a DomU reboot?

My hole System (DomU + Dom0) freezes after a reboot of DomU (exaclty then, =

when the passed-through VGA Card is accessed...), therefore the question.

Thanks for your info!
Greetings
Tobias

Am Dienstag, 6. Dezember 2011, 14:57:30 schrieb David TECHER:
> Hi
> =

> Thanks for these informations. I am on Debian. So it could be usefull for
> Ubuntu users.
> =

> Thanks.
> =

> David
> =

> =

> =

> ________________________________
>  De : n4rC0t1C <shandivo@gmail.com>
> =C0 : xen-devel@lists.xensource.com
> Envoy=E9 le : Mardi 6 D=E9cembre 2011 13h04
> Objet : Re: [Xen-devel] Re : Re : Re : Re : Re : Re : Re : Re: Patches for
> VGA-Passthrough XEN 4.2 unstable
> =

> Iep I used your last patches, (your website it's at the top of my
> bookmarks), and they apply to xen-unstable rev. 24341 as well (which i'm
> using).
> =

> I forgot to mention that I had to make a couple of fix to xen tree, cause
> it wasn't compiling on my system due to  "error: format not a string
> literal and no format arguments":
> =

> =

> --- /usr/src/xen-unstable.hg-rev-24341-460gtx/tools/libxl/libxl_create.c
> +++ /usr/src/xen-unstable.hg-rev-24341-460gtx/tools/libxl/libxl_create.c
> @@ -462,7 +462,7 @@
>      path =3D libxl__xs_libxl_path(gc, domid);
>      path =3D libxl__sprintf(gc, "%s/dm-version", path);
>      return libxl__xs_write(gc, XBT_NULL, path, libxl__strdup(gc,
> -     =

> libxl_device_model_version_to_string(dm_info->device_model_version)));
> +     =

> libxl_device_model_version_to_string(dm_info->device_model_version)),"%s"=
);
> }
> =

> static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
> =

> =

> --- /usr/src/xen-unstable.hg-rev-24341-460gtx/tools/libxl/libxl_device.c
> +++ /usr/src/xen-unstable.hg-rev-24341-460gtx/tools/libxl/libxl_device.c
> @@ -516,7 +516,7 @@
>          for (j =3D 0; j < num_devs; j++) {
>              path =3D libxl__sprintf(gc,
> "/local/domain/%d/device/%s/%s/backend",
>                                    domid, kinds[i], devs[j]);
> -            path =3D libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, pat=
h));
> +            path =3D libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc,
> path,"%s"));
>              if (path && libxl__parse_backend_path(gc, path, &dev) =3D=3D=
 0) {
>                  dev.domid =3D domid;
>                  dev.kind =3D kind;
> =

> and an due to an argument missing:
> =

> --- /usr/src/xen-unstable.hg-rev-24341-460gtx/tools/libxl/libxl_dom.c
> +++ /usr/src/xen-unstable.hg-rev-24341-460gtx/tools/libxl/libxl_dom.c
> @@ -625,7 +625,7 @@
>          break;
>      }
>      case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
> -        fd2 =3D open(filename, O_WRONLY | O_CREAT | O_TRUNC);
> +        fd2 =3D open(filename, O_WRONLY | O_CREAT | O_TRUNC, 0644);
>          if (fd2 < 0) {
>              LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
>                               "Unable to create a QEMU save file\n");
> =

> As far as I know those doesn't break anything, but dont take too seriousl=
y,
> i'm not an experienced developer :)
> =

> =

> Forgot 2:
> Since I'm using an ubuntu kernel, the xen support is not integrated, but
> you need to add xen modules at your inittrd file. I did this by adding
> those:
> =

> xen-pciback passthrough=3D1
> xen-blkback
> xenfs
> xen-netback
> pci-stub
> =

> to /etc/xen/initramfs-tools/modules and the issuing update-initramfs.
> =

> In the future, I'll try to boot a linux domU, right now I'm still smiling
> cause I can fully wipe my Windows installation from the hard disk. And I'm
> sure that in future Win7 will be supported too.
> =

> Thanks again David and everyone,
> Ivo
> =

> --
> View this message in context:
> http://xen.1045712.n5.nabble.com/Patches-for-VGA-Passthrough-XEN-4-2-unsta
> ble-tp4406265p5051880.html Sent from the Xen - Dev mailing list archive at
> Nabble.com.
> =

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 15:58:03 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 15: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.xensource.com>)
	id 1RXxOZ-0003xB-GA; Tue, 06 Dec 2011 15:57:27 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <davidtecher@yahoo.fr>) id 1RXxOY-0003x6-1v
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 15:57:26 +0000
X-Env-Sender: davidtecher@yahoo.fr
X-Msg-Ref: server-15.tower-182.messagelabs.com!1323186998!6061499!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.6 required=7.0 tests=HTML_40_50,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,spamassassin: 
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14625 invoked from network); 6 Dec 2011 15:56:39 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-15.tower-182.messagelabs.com with AES256-SHA encrypted SMTP;
	6 Dec 2011 15:56:39 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <davidtecher@yahoo.fr>) id 1RXxNl-0006bq-9g
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 07:56:37 -0800
Date: Tue, 6 Dec 2011 07:56:37 -0800 (PST)
From: David TECHER <davidtecher@yahoo.fr>
To: xen-devel@lists.xensource.com
Message-ID: <1323186981.67093.YahooMailNeo@web29807.mail.ird.yahoo.com>
In-Reply-To: <201112061619.56224.tobias.geiger@vido.info>
References: <1318672856439-4904945.post@n5.nabble.com>
	<1319630071722-4939528.post@n5.nabble.com>
	<1319636130.20499.YahooMailNeo@web29808.mail.ird.yahoo.com>
	<1319695116310-4942047.post@n5.nabble.com>
	<1319710499.206.YahooMailNeo@web29804.mail.ird.yahoo.com>
	<1323123990448-5050354.post@n5.nabble.com>
	<1323170568.90631.YahooMailNeo@web29813.mail.ird.yahoo.com>
	<1323173094434-5051880.post@n5.nabble.com>
	<1323179850.78658.YahooMailNeo@web29801.mail.ird.yahoo.com>
	<201112061619.56224.tobias.geiger@vido.info>
MIME-Version: 1.0
Subject: [Xen-devel] Re : Re : Re : Re : Re : Re : Re : Re : Re : Re:
 Patches for VGA-Passthrough XEN 4.2 unstable
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============5420372796785576371=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============5420372796785576371==
Content-Type: multipart/alternative; 
	boundary="----=_Part_43809_24350281.1323186997245"

------=_Part_43809_24350281.1323186997245
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Tobias

I am at office for the moment. I will have a try when I go back to home in =
a couple of hours.

Thanks.

David.



________________________________
 De=C2=A0: Tobias Geiger [via Xen] <ml-node+s1045712n5052398h36@n5.nabble.c=
om>
=C3=80=C2=A0: David TECHER <davidtecher@yahoo.fr>=20
Envoy=C3=A9 le : Mardi 6 D=C3=A9cembre 2011 16h21
Objet=C2=A0: Re: Re : Re : Re : Re : Re : Re : Re : Re : Re: Patches for VG=
A-Passthrough XEN 4.2 unstable
=20

Hello,=20

glad to hear it works for you!=20

As i run a similar setup, perhaps you can share your experience regarding=
=20
DomU-Reboot with a VGA Card passed through to it: Does a reboot work, i.e.=
=20
does the passed-through VGA Card work after a DomU reboot?=20

My hole System (DomU + Dom0) freezes after a reboot of DomU (exaclty then,=
=20
when the passed-through VGA Card is accessed...), therefore the question.=
=20

Thanks for your info!=20
Greetings=20
Tobias=20

Am Dienstag, 6. Dezember 2011, 14:57:30 schrieb David TECHER:=20

> Hi=20
>=20
> Thanks for these informations. I am on Debian. So it could be usefull for=
=20
> Ubuntu users.=20
>=20
> Thanks.=20
>=20
> David=20
>=20
>=20
>=20
> ________________________________=20
> =C2=A0De : n4rC0t1C <[hidden email]>=20
> =C3=80 : [hidden email]=20
> Envoy=C3=A9 le : Mardi 6 D=C3=A9cembre 2011 13h04=20
> Objet : Re: [Xen-devel] Re : Re : Re : Re : Re : Re : Re : Re: Patches fo=
r=20
> VGA-Passthrough XEN 4.2 unstable=20
>=20
> Iep I used your last patches, (your website it's at the top of my=20
> bookmarks), and they apply to xen-unstable rev. 24341 as well (which i'm=
=20
> using).=20
>=20
> I forgot to mention that I had to make a couple of fix to xen tree, cause=
=20
> it wasn't compiling on my system due to =C2=A0"error: format not a string=
=20
> literal and no format arguments":=20
>=20
>=20
> --- /usr/src/xen-unstable.hg-rev-24341-460gtx/tools/libxl/libxl_create.c=
=20
> +++ /usr/src/xen-unstable.hg-rev-24341-460gtx/tools/libxl/libxl_create.c=
=20
> @@ -462,7 +462,7 @@=20
> =C2=A0 =C2=A0 =C2=A0path =3D libxl__xs_libxl_path(gc, domid);=20
> =C2=A0 =C2=A0 =C2=A0path =3D libxl__sprintf(gc, "%s/dm-version", path);=
=20
> =C2=A0 =C2=A0 =C2=A0return libxl__xs_write(gc, XBT_NULL, path, libxl__str=
dup(gc,=20
> - =C2=A0 =C2=A0=20
> libxl_device_model_version_to_string(dm_info->device_model_version)));=20
> + =C2=A0 =C2=A0=20
> libxl_device_model_version_to_string(dm_info->device_model_version)),"%s"=
);=20
> }=20
>=20
> static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,=
=20
>=20
>=20
> --- /usr/src/xen-unstable.hg-rev-24341-460gtx/tools/libxl/libxl_device.c=
=20
> +++ /usr/src/xen-unstable.hg-rev-24341-460gtx/tools/libxl/libxl_device.c=
=20
> @@ -516,7 +516,7 @@=20
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0for (j =3D 0; j < num_devs; j++) {=20
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0path =3D libxl__sprintf(g=
c,=20
> "/local/domain/%d/device/%s/%s/backend",=20
> =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 =C2=A0domid, kinds[i], devs[j=
]);=20
> - =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0path =3D libxl__xs_read(gc, XB=
T_NULL, libxl__sprintf(gc, path));=20
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0path =3D libxl__xs_read(gc, XB=
T_NULL, libxl__sprintf(gc,=20
> path,"%s"));=20
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0if (path && libxl__parse_=
backend_path(gc, path, &dev) =3D=3D 0) {=20
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0dev.domid =
=3D domid;=20
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0dev.kind =
=3D kind;=20
>=20
> and an due to an argument missing:=20
>=20
> --- /usr/src/xen-unstable.hg-rev-24341-460gtx/tools/libxl/libxl_dom.c=20
> +++ /usr/src/xen-unstable.hg-rev-24341-460gtx/tools/libxl/libxl_dom.c=20
> @@ -625,7 +625,7 @@=20
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0break;=20
> =C2=A0 =C2=A0 =C2=A0}=20
> =C2=A0 =C2=A0 =C2=A0case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:=20
> - =C2=A0 =C2=A0 =C2=A0 =C2=A0fd2 =3D open(filename, O_WRONLY | O_CREAT | =
O_TRUNC);=20
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0fd2 =3D open(filename, O_WRONLY | O_CREAT | =
O_TRUNC, 0644);=20
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0if (fd2 < 0) {=20
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0LIBXL__LOG_ERRNO(ctx, LIB=
XL__LOG_ERROR,=20
> =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 "Unable to create a QEMU save file\n");=20
>=20
> As far as I know those doesn't break anything, but dont take too seriousl=
y,=20
> i'm not an experienced developer :)=20
>=20
>=20
> Forgot 2:=20
> Since I'm using an ubuntu kernel, the xen support is not integrated, but=
=20
> you need to add xen modules at your inittrd file. I did this by adding=20
> those:=20
>=20
> xen-pciback passthrough=3D1=20
> xen-blkback=20
> xenfs=20
> xen-netback=20
> pci-stub=20
>=20
> to /etc/xen/initramfs-tools/modules and the issuing update-initramfs.=20
>=20
> In the future, I'll try to boot a linux domU, right now I'm still smiling=
=20
> cause I can fully wipe my Windows installation from the hard disk. And I'=
m=20
> sure that in future Win7 will be supported too.=20
>=20
> Thanks again David and everyone,=20
> Ivo=20
>=20
> --=20
> View this message in context:=20
> http://xen.1045712.n5.nabble.com/Patches-for-VGA-Passthrough-XEN-4-2-unst=
a
> ble-tp4406265p5051880.html Sent from the Xen - Dev mailing list archive a=
t=20
> Nabble.com.=20
>=20
> _______________________________________________=20
> Xen-devel mailing list=20
> [hidden email]=20
> http://lists.xensource.com/xen-devel

_______________________________________________=20
Xen-devel mailing list=20
[hidden email]=20
http://lists.xensource.com/xen-devel


________________________________
=20
If you reply to this email, your message will be added to the discussion be=
low:http://xen.1045712.n5.nabble.com/Patches-for-VGA-Passthrough-XEN-4-2-un=
stable-tp4406265p5052398.html=20
To unsubscribe from Patches for VGA-Passthrough XEN 4.2 unstable, click her=
e.
NAML

--
View this message in context: http://xen.1045712.n5.nabble.com/Patches-for-=
VGA-Passthrough-XEN-4-2-unstable-tp4406265p5052523.html
Sent from the Xen - Dev mailing list archive at Nabble.com.
------=_Part_43809_24350281.1323186997245
Content-Type: text/html; charset=UTF8
Content-Transfer-Encoding: quoted-printable

<div style=3D"color:#000; background-color:#fff; font-family:times new roma=
n, new york, times, serif;font-size:12pt"><div><span>Tobias</span></div><di=
v><br><span></span></div><div><span>I am at office for the moment. I will h=
ave a try when I go back to home in a couple of hours.</span></div><div><br=
><span></span></div><div><span>Thanks.</span></div><div><br><span></span></=
div><div><span>David.</span><span class=3D"tab"><br></span></div><div><br><=
/div>  <div style=3D"font-family: times new roman, new york, times, serif; =
font-size: 12pt;"> <div style=3D"font-family: times new roman, new york, ti=
mes, serif; font-size: 12pt;"> <font face=3D"Arial" size=3D"2"> <hr size=3D=
"1">  <b><span style=3D"font-weight:bold;">De&nbsp;:</span></b> Tobias Geig=
er [via Xen] &lt;<a href=3D"/user/SendEmail.jtp?type=3Dnode&node=3D5052523&=
i=3D0" target=3D"_top" rel=3D"nofollow" link=3D"external">[hidden email]</a=
>&gt;<br> <b><span style=3D"font-weight: bold;">=C3=80&nbsp;:</span></b> Da=
vid TECHER &lt;<a href=3D"/user/SendEmail.jtp?type=3Dnode&node=3D5052523&i=
=3D1" target=3D"_top" rel=3D"nofollow" link=3D"external">[hidden email]</a>=
&gt; <br> <b><span style=3D"font-weight: bold;">Envoy=C3=A9 le
 :</span></b> Mardi 6 D=C3=A9cembre 2011 16h21<br> <b><span style=3D"font-w=
eight: bold;">Objet&nbsp;:</span></b> Re: Re : Re : Re : Re : Re : Re : Re =
: Re : Re: Patches for VGA-Passthrough XEN 4.2 unstable<br> </font> <br><di=
v id=3D"yiv1629207433">

=09Hello,
<br><br>glad to hear it works for you!
<br><br>As i run a similar setup, perhaps you can share your experience reg=
arding=20
<br>DomU-Reboot with a VGA Card passed through to it: Does a reboot work, i=
.e.=20
<br>does the passed-through VGA Card work after a DomU reboot?
<br><br>My hole System (DomU + Dom0) freezes after a reboot of DomU (exaclt=
y then,=20
<br>when the passed-through VGA Card is accessed...), therefore the questio=
n.
<br><br>Thanks for your info!
<br>Greetings
<br>Tobias
<br><br>Am Dienstag, 6. Dezember 2011, 14:57:30 schrieb David TECHER:
<div class=3D"yiv1629207433shrinkable-quote"><div class=3D'shrinkable-quote=
'><br>&gt; Hi
<br>&gt;=20
<br>&gt; Thanks for these informations. I am on Debian. So it could be usef=
ull for
<br>&gt; Ubuntu users.
<br>&gt;=20
<br>&gt; Thanks.
<br>&gt;=20
<br>&gt; David
<br>&gt;=20
<br>&gt;=20
<br>&gt;=20
<br>&gt; ________________________________
<br>&gt; &nbsp;De : n4rC0t1C &lt;<a rel=3D"nofollow" target=3D"_top" link=
=3D"external">[hidden email]</a>&gt;
<br>&gt; =C3=80 : <a rel=3D"nofollow" target=3D"_top" link=3D"external">[hi=
dden email]</a>
<br>&gt; Envoy=C3=A9 le : Mardi 6 D=C3=A9cembre 2011 13h04
<br>&gt; Objet : Re: [Xen-devel] Re : Re : Re : Re : Re : Re : Re : Re: Pat=
ches for
<br>&gt; VGA-Passthrough XEN 4.2 unstable
<br>&gt;=20
<br>&gt; Iep I used your last patches, (your website it's at the top of my
<br>&gt; bookmarks), and they apply to xen-unstable rev. 24341 as well (whi=
ch i'm
<br>&gt; using).
<br>&gt;=20
<br>&gt; I forgot to mention that I had to make a couple of fix to xen tree=
, cause
<br>&gt; it wasn't compiling on my system due to &nbsp;"error: format not a=
 string
<br>&gt; literal and no format arguments":
<br>&gt;=20
<br>&gt;=20
<br>&gt; --- /usr/src/xen-unstable.hg-rev-24341-460gtx/tools/libxl/libxl_cr=
eate.c
<br>&gt; +++ /usr/src/xen-unstable.hg-rev-24341-460gtx/tools/libxl/libxl_cr=
eate.c
<br>&gt; @@ -462,7 +462,7 @@
<br>&gt; &nbsp; &nbsp; &nbsp;path =3D libxl__xs_libxl_path(gc, domid);
<br>&gt; &nbsp; &nbsp; &nbsp;path =3D libxl__sprintf(gc, "%s/dm-version", p=
ath);
<br>&gt; &nbsp; &nbsp; &nbsp;return libxl__xs_write(gc, XBT_NULL, path, lib=
xl__strdup(gc,
<br>&gt; - &nbsp; &nbsp;=20
<br>&gt; libxl_device_model_version_to_string(dm_info-&gt;device_model_vers=
ion)));
<br>&gt; + &nbsp; &nbsp;=20
<br>&gt; libxl_device_model_version_to_string(dm_info-&gt;device_model_vers=
ion)),"%s");
<br>&gt; }
<br>&gt;=20
<br>&gt; static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_=
config,
<br>&gt;=20
<br>&gt;=20
<br>&gt; --- /usr/src/xen-unstable.hg-rev-24341-460gtx/tools/libxl/libxl_de=
vice.c
<br>&gt; +++ /usr/src/xen-unstable.hg-rev-24341-460gtx/tools/libxl/libxl_de=
vice.c
<br>&gt; @@ -516,7 +516,7 @@
<br>&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;for (j =3D 0; j &lt; num_devs; j=
++) {
<br>&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;path =3D libxl__sp=
rintf(gc,
<br>&gt; "/local/domain/%d/device/%s/%s/backend",
<br>&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nb=
sp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;domid, kinds[i],=
 devs[j]);
<br>&gt; - &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;path =3D libxl__xs_read=
(gc, XBT_NULL, libxl__sprintf(gc, path));
<br>&gt; + &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;path =3D libxl__xs_read=
(gc, XBT_NULL, libxl__sprintf(gc,
<br>&gt; path,"%s"));
<br>&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;if (path &amp;&amp=
; libxl__parse_backend_path(gc, path, &amp;dev) =3D=3D 0) {
<br>&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;dev.=
domid =3D domid;
<br>&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;dev.=
kind =3D kind;
<br>&gt;=20
<br>&gt; and an due to an argument missing:
<br>&gt;=20
<br>&gt; --- /usr/src/xen-unstable.hg-rev-24341-460gtx/tools/libxl/libxl_do=
m.c
<br>&gt; +++ /usr/src/xen-unstable.hg-rev-24341-460gtx/tools/libxl/libxl_do=
m.c
<br>&gt; @@ -625,7 +625,7 @@
<br>&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;break;
<br>&gt; &nbsp; &nbsp; &nbsp;}
<br>&gt; &nbsp; &nbsp; &nbsp;case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
<br>&gt; - &nbsp; &nbsp; &nbsp; &nbsp;fd2 =3D open(filename, O_WRONLY | O_C=
REAT | O_TRUNC);
<br>&gt; + &nbsp; &nbsp; &nbsp; &nbsp;fd2 =3D open(filename, O_WRONLY | O_C=
REAT | O_TRUNC, 0644);
<br>&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;if (fd2 &lt; 0) {
<br>&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;LIBXL__LOG_ERRNO(c=
tx, LIBXL__LOG_ERROR,
<br>&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nb=
sp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; "Unable to create a QEMU save file\n=
");
<br>&gt;=20
<br>&gt; As far as I know those doesn't break anything, but dont take too s=
eriously,
<br>&gt; i'm not an experienced developer :)
<br>&gt;=20
<br>&gt;=20
<br>&gt; Forgot 2:
<br>&gt; Since I'm using an ubuntu kernel, the xen support is not integrate=
d, but
<br>&gt; you need to add xen modules at your inittrd file. I did this by ad=
ding
<br>&gt; those:
<br>&gt;=20
<br>&gt; xen-pciback passthrough=3D1
<br>&gt; xen-blkback
<br>&gt; xenfs
<br>&gt; xen-netback
<br>&gt; pci-stub
<br>&gt;=20
<br>&gt; to /etc/xen/initramfs-tools/modules and the issuing update-initram=
fs.
<br>&gt;=20
<br>&gt; In the future, I'll try to boot a linux domU, right now I'm still =
smiling
<br>&gt; cause I can fully wipe my Windows installation from the hard disk.=
 And I'm
<br>&gt; sure that in future Win7 will be supported too.
<br>&gt;=20
<br>&gt; Thanks again David and everyone,
<br>&gt; Ivo
<br>&gt;=20
<br>&gt; --
<br>&gt; View this message in context:
<br>&gt; <a rel=3D"nofollow" target=3D"_blank" href=3D"http://xen.1045712.n=
5.nabble.com/Patches-for-VGA-Passthrough-XEN-4-2-unsta" link=3D"external">h=
ttp://xen.1045712.n5.nabble.com/Patches-for-VGA-Passthrough-XEN-4-2-unsta</=
a><br>&gt; ble-tp4406265p5051880.html Sent from the Xen - Dev mailing list =
archive at
<br>&gt; Nabble.com.
<br>&gt;=20
<br>&gt; _______________________________________________
<br>&gt; Xen-devel mailing list
<br>&gt; <a rel=3D"nofollow" target=3D"_top" link=3D"external">[hidden emai=
l]</a>
<br>&gt; <a rel=3D"nofollow" target=3D"_blank" href=3D"http://lists.xensour=
ce.com/xen-devel" link=3D"external">http://lists.xensource.com/xen-devel</a=
></div></div><br>_______________________________________________
<br>Xen-devel mailing list
<br><a rel=3D"nofollow" target=3D"_top" link=3D"external">[hidden email]</a=
>
<br><a rel=3D"nofollow" target=3D"_blank" href=3D"http://lists.xensource.co=
m/xen-devel" link=3D"external">http://lists.xensource.com/xen-devel</a><br>
=09
=09<br>
=09<br>
=09<hr noshade=3D"noshade" size=3D"1" color=3D"#cccccc">
=09<div style=3D"color:#444;font:12px tahoma, geneva, helvetica, arial, san=
s-serif;">
=09=09<div style=3D"font-weight:bold;">If you reply to this email, your mes=
sage will be added to the discussion below:</div>
=09=09<a rel=3D"nofollow" target=3D"_blank" href=3D"http://xen.1045712.n5.n=
abble.com/Patches-for-VGA-Passthrough-XEN-4-2-unstable-tp4406265p5052398.ht=
ml" link=3D"external">http://xen.1045712.n5.nabble.com/Patches-for-VGA-Pass=
through-XEN-4-2-unstable-tp4406265p5052398.html</a>
=09</div>
=09<div style=3D"color:#666;font:11px tahoma, geneva, helvetica, arial, san=
s-serif;margin-top:.4em;line-height:1.5em;">
=09=09
=09=09To unsubscribe from Patches for VGA-Passthrough XEN 4.2 unstable, <a =
rel=3D"nofollow" target=3D"_blank" href=3D"" link=3D"external">click here</=
a>.<br>
=09=09<a rel=3D"nofollow" target=3D"_blank" href=3D"http://xen.1045712.n5.n=
abble.com/template/NamlServlet.jtp?macro=3Dmacro_viewer&amp;id=3Dinstant_ht=
ml%21nabble%3Aemail.naml&amp;base=3Dnabble.naml.namespaces.BasicNamespace-n=
abble.view.web.template.NabbleNamespace-nabble.view.web.template.InstantMai=
lNamespace&amp;breadcrumbs=3Dinstant+emails%21nabble%3Aemail.naml-instant_e=
mails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml" style=
=3D"font:9px serif;" link=3D"external">NAML</a>
=09</div></div><br><br> </div> </div>  </div>
=09
<br/><hr align=3D"left" width=3D"300" />
View this message in context: <a href=3D"http://xen.1045712.n5.nabble.com/P=
atches-for-VGA-Passthrough-XEN-4-2-unstable-tp4406265p5052523.html">Re : Re=
 : Re : Re : Re : Re : Re : Re : Re : Re: Patches for VGA-Passthrough XEN 4=
.2 unstable</a><br/>
Sent from the <a href=3D"http://xen.1045712.n5.nabble.com/Xen-Dev-f2473738.=
html">Xen - Dev mailing list archive</a> at Nabble.com.<br/>
------=_Part_43809_24350281.1323186997245--


--===============5420372796785576371==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============5420372796785576371==--


From xen-devel-bounces@lists.xensource.com Tue Dec 06 15:58:03 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 15: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.xensource.com>)
	id 1RXxOZ-0003xB-GA; Tue, 06 Dec 2011 15:57:27 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <davidtecher@yahoo.fr>) id 1RXxOY-0003x6-1v
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 15:57:26 +0000
X-Env-Sender: davidtecher@yahoo.fr
X-Msg-Ref: server-15.tower-182.messagelabs.com!1323186998!6061499!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.6 required=7.0 tests=HTML_40_50,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,spamassassin: 
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14625 invoked from network); 6 Dec 2011 15:56:39 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-15.tower-182.messagelabs.com with AES256-SHA encrypted SMTP;
	6 Dec 2011 15:56:39 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <davidtecher@yahoo.fr>) id 1RXxNl-0006bq-9g
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 07:56:37 -0800
Date: Tue, 6 Dec 2011 07:56:37 -0800 (PST)
From: David TECHER <davidtecher@yahoo.fr>
To: xen-devel@lists.xensource.com
Message-ID: <1323186981.67093.YahooMailNeo@web29807.mail.ird.yahoo.com>
In-Reply-To: <201112061619.56224.tobias.geiger@vido.info>
References: <1318672856439-4904945.post@n5.nabble.com>
	<1319630071722-4939528.post@n5.nabble.com>
	<1319636130.20499.YahooMailNeo@web29808.mail.ird.yahoo.com>
	<1319695116310-4942047.post@n5.nabble.com>
	<1319710499.206.YahooMailNeo@web29804.mail.ird.yahoo.com>
	<1323123990448-5050354.post@n5.nabble.com>
	<1323170568.90631.YahooMailNeo@web29813.mail.ird.yahoo.com>
	<1323173094434-5051880.post@n5.nabble.com>
	<1323179850.78658.YahooMailNeo@web29801.mail.ird.yahoo.com>
	<201112061619.56224.tobias.geiger@vido.info>
MIME-Version: 1.0
Subject: [Xen-devel] Re : Re : Re : Re : Re : Re : Re : Re : Re : Re:
 Patches for VGA-Passthrough XEN 4.2 unstable
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============5420372796785576371=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============5420372796785576371==
Content-Type: multipart/alternative; 
	boundary="----=_Part_43809_24350281.1323186997245"

------=_Part_43809_24350281.1323186997245
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Tobias

I am at office for the moment. I will have a try when I go back to home in =
a couple of hours.

Thanks.

David.



________________________________
 De=C2=A0: Tobias Geiger [via Xen] <ml-node+s1045712n5052398h36@n5.nabble.c=
om>
=C3=80=C2=A0: David TECHER <davidtecher@yahoo.fr>=20
Envoy=C3=A9 le : Mardi 6 D=C3=A9cembre 2011 16h21
Objet=C2=A0: Re: Re : Re : Re : Re : Re : Re : Re : Re : Re: Patches for VG=
A-Passthrough XEN 4.2 unstable
=20

Hello,=20

glad to hear it works for you!=20

As i run a similar setup, perhaps you can share your experience regarding=
=20
DomU-Reboot with a VGA Card passed through to it: Does a reboot work, i.e.=
=20
does the passed-through VGA Card work after a DomU reboot?=20

My hole System (DomU + Dom0) freezes after a reboot of DomU (exaclty then,=
=20
when the passed-through VGA Card is accessed...), therefore the question.=
=20

Thanks for your info!=20
Greetings=20
Tobias=20

Am Dienstag, 6. Dezember 2011, 14:57:30 schrieb David TECHER:=20

> Hi=20
>=20
> Thanks for these informations. I am on Debian. So it could be usefull for=
=20
> Ubuntu users.=20
>=20
> Thanks.=20
>=20
> David=20
>=20
>=20
>=20
> ________________________________=20
> =C2=A0De : n4rC0t1C <[hidden email]>=20
> =C3=80 : [hidden email]=20
> Envoy=C3=A9 le : Mardi 6 D=C3=A9cembre 2011 13h04=20
> Objet : Re: [Xen-devel] Re : Re : Re : Re : Re : Re : Re : Re: Patches fo=
r=20
> VGA-Passthrough XEN 4.2 unstable=20
>=20
> Iep I used your last patches, (your website it's at the top of my=20
> bookmarks), and they apply to xen-unstable rev. 24341 as well (which i'm=
=20
> using).=20
>=20
> I forgot to mention that I had to make a couple of fix to xen tree, cause=
=20
> it wasn't compiling on my system due to =C2=A0"error: format not a string=
=20
> literal and no format arguments":=20
>=20
>=20
> --- /usr/src/xen-unstable.hg-rev-24341-460gtx/tools/libxl/libxl_create.c=
=20
> +++ /usr/src/xen-unstable.hg-rev-24341-460gtx/tools/libxl/libxl_create.c=
=20
> @@ -462,7 +462,7 @@=20
> =C2=A0 =C2=A0 =C2=A0path =3D libxl__xs_libxl_path(gc, domid);=20
> =C2=A0 =C2=A0 =C2=A0path =3D libxl__sprintf(gc, "%s/dm-version", path);=
=20
> =C2=A0 =C2=A0 =C2=A0return libxl__xs_write(gc, XBT_NULL, path, libxl__str=
dup(gc,=20
> - =C2=A0 =C2=A0=20
> libxl_device_model_version_to_string(dm_info->device_model_version)));=20
> + =C2=A0 =C2=A0=20
> libxl_device_model_version_to_string(dm_info->device_model_version)),"%s"=
);=20
> }=20
>=20
> static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,=
=20
>=20
>=20
> --- /usr/src/xen-unstable.hg-rev-24341-460gtx/tools/libxl/libxl_device.c=
=20
> +++ /usr/src/xen-unstable.hg-rev-24341-460gtx/tools/libxl/libxl_device.c=
=20
> @@ -516,7 +516,7 @@=20
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0for (j =3D 0; j < num_devs; j++) {=20
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0path =3D libxl__sprintf(g=
c,=20
> "/local/domain/%d/device/%s/%s/backend",=20
> =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 =C2=A0domid, kinds[i], devs[j=
]);=20
> - =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0path =3D libxl__xs_read(gc, XB=
T_NULL, libxl__sprintf(gc, path));=20
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0path =3D libxl__xs_read(gc, XB=
T_NULL, libxl__sprintf(gc,=20
> path,"%s"));=20
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0if (path && libxl__parse_=
backend_path(gc, path, &dev) =3D=3D 0) {=20
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0dev.domid =
=3D domid;=20
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0dev.kind =
=3D kind;=20
>=20
> and an due to an argument missing:=20
>=20
> --- /usr/src/xen-unstable.hg-rev-24341-460gtx/tools/libxl/libxl_dom.c=20
> +++ /usr/src/xen-unstable.hg-rev-24341-460gtx/tools/libxl/libxl_dom.c=20
> @@ -625,7 +625,7 @@=20
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0break;=20
> =C2=A0 =C2=A0 =C2=A0}=20
> =C2=A0 =C2=A0 =C2=A0case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:=20
> - =C2=A0 =C2=A0 =C2=A0 =C2=A0fd2 =3D open(filename, O_WRONLY | O_CREAT | =
O_TRUNC);=20
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0fd2 =3D open(filename, O_WRONLY | O_CREAT | =
O_TRUNC, 0644);=20
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0if (fd2 < 0) {=20
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0LIBXL__LOG_ERRNO(ctx, LIB=
XL__LOG_ERROR,=20
> =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 "Unable to create a QEMU save file\n");=20
>=20
> As far as I know those doesn't break anything, but dont take too seriousl=
y,=20
> i'm not an experienced developer :)=20
>=20
>=20
> Forgot 2:=20
> Since I'm using an ubuntu kernel, the xen support is not integrated, but=
=20
> you need to add xen modules at your inittrd file. I did this by adding=20
> those:=20
>=20
> xen-pciback passthrough=3D1=20
> xen-blkback=20
> xenfs=20
> xen-netback=20
> pci-stub=20
>=20
> to /etc/xen/initramfs-tools/modules and the issuing update-initramfs.=20
>=20
> In the future, I'll try to boot a linux domU, right now I'm still smiling=
=20
> cause I can fully wipe my Windows installation from the hard disk. And I'=
m=20
> sure that in future Win7 will be supported too.=20
>=20
> Thanks again David and everyone,=20
> Ivo=20
>=20
> --=20
> View this message in context:=20
> http://xen.1045712.n5.nabble.com/Patches-for-VGA-Passthrough-XEN-4-2-unst=
a
> ble-tp4406265p5051880.html Sent from the Xen - Dev mailing list archive a=
t=20
> Nabble.com.=20
>=20
> _______________________________________________=20
> Xen-devel mailing list=20
> [hidden email]=20
> http://lists.xensource.com/xen-devel

_______________________________________________=20
Xen-devel mailing list=20
[hidden email]=20
http://lists.xensource.com/xen-devel


________________________________
=20
If you reply to this email, your message will be added to the discussion be=
low:http://xen.1045712.n5.nabble.com/Patches-for-VGA-Passthrough-XEN-4-2-un=
stable-tp4406265p5052398.html=20
To unsubscribe from Patches for VGA-Passthrough XEN 4.2 unstable, click her=
e.
NAML

--
View this message in context: http://xen.1045712.n5.nabble.com/Patches-for-=
VGA-Passthrough-XEN-4-2-unstable-tp4406265p5052523.html
Sent from the Xen - Dev mailing list archive at Nabble.com.
------=_Part_43809_24350281.1323186997245
Content-Type: text/html; charset=UTF8
Content-Transfer-Encoding: quoted-printable

<div style=3D"color:#000; background-color:#fff; font-family:times new roma=
n, new york, times, serif;font-size:12pt"><div><span>Tobias</span></div><di=
v><br><span></span></div><div><span>I am at office for the moment. I will h=
ave a try when I go back to home in a couple of hours.</span></div><div><br=
><span></span></div><div><span>Thanks.</span></div><div><br><span></span></=
div><div><span>David.</span><span class=3D"tab"><br></span></div><div><br><=
/div>  <div style=3D"font-family: times new roman, new york, times, serif; =
font-size: 12pt;"> <div style=3D"font-family: times new roman, new york, ti=
mes, serif; font-size: 12pt;"> <font face=3D"Arial" size=3D"2"> <hr size=3D=
"1">  <b><span style=3D"font-weight:bold;">De&nbsp;:</span></b> Tobias Geig=
er [via Xen] &lt;<a href=3D"/user/SendEmail.jtp?type=3Dnode&node=3D5052523&=
i=3D0" target=3D"_top" rel=3D"nofollow" link=3D"external">[hidden email]</a=
>&gt;<br> <b><span style=3D"font-weight: bold;">=C3=80&nbsp;:</span></b> Da=
vid TECHER &lt;<a href=3D"/user/SendEmail.jtp?type=3Dnode&node=3D5052523&i=
=3D1" target=3D"_top" rel=3D"nofollow" link=3D"external">[hidden email]</a>=
&gt; <br> <b><span style=3D"font-weight: bold;">Envoy=C3=A9 le
 :</span></b> Mardi 6 D=C3=A9cembre 2011 16h21<br> <b><span style=3D"font-w=
eight: bold;">Objet&nbsp;:</span></b> Re: Re : Re : Re : Re : Re : Re : Re =
: Re : Re: Patches for VGA-Passthrough XEN 4.2 unstable<br> </font> <br><di=
v id=3D"yiv1629207433">

=09Hello,
<br><br>glad to hear it works for you!
<br><br>As i run a similar setup, perhaps you can share your experience reg=
arding=20
<br>DomU-Reboot with a VGA Card passed through to it: Does a reboot work, i=
.e.=20
<br>does the passed-through VGA Card work after a DomU reboot?
<br><br>My hole System (DomU + Dom0) freezes after a reboot of DomU (exaclt=
y then,=20
<br>when the passed-through VGA Card is accessed...), therefore the questio=
n.
<br><br>Thanks for your info!
<br>Greetings
<br>Tobias
<br><br>Am Dienstag, 6. Dezember 2011, 14:57:30 schrieb David TECHER:
<div class=3D"yiv1629207433shrinkable-quote"><div class=3D'shrinkable-quote=
'><br>&gt; Hi
<br>&gt;=20
<br>&gt; Thanks for these informations. I am on Debian. So it could be usef=
ull for
<br>&gt; Ubuntu users.
<br>&gt;=20
<br>&gt; Thanks.
<br>&gt;=20
<br>&gt; David
<br>&gt;=20
<br>&gt;=20
<br>&gt;=20
<br>&gt; ________________________________
<br>&gt; &nbsp;De : n4rC0t1C &lt;<a rel=3D"nofollow" target=3D"_top" link=
=3D"external">[hidden email]</a>&gt;
<br>&gt; =C3=80 : <a rel=3D"nofollow" target=3D"_top" link=3D"external">[hi=
dden email]</a>
<br>&gt; Envoy=C3=A9 le : Mardi 6 D=C3=A9cembre 2011 13h04
<br>&gt; Objet : Re: [Xen-devel] Re : Re : Re : Re : Re : Re : Re : Re: Pat=
ches for
<br>&gt; VGA-Passthrough XEN 4.2 unstable
<br>&gt;=20
<br>&gt; Iep I used your last patches, (your website it's at the top of my
<br>&gt; bookmarks), and they apply to xen-unstable rev. 24341 as well (whi=
ch i'm
<br>&gt; using).
<br>&gt;=20
<br>&gt; I forgot to mention that I had to make a couple of fix to xen tree=
, cause
<br>&gt; it wasn't compiling on my system due to &nbsp;"error: format not a=
 string
<br>&gt; literal and no format arguments":
<br>&gt;=20
<br>&gt;=20
<br>&gt; --- /usr/src/xen-unstable.hg-rev-24341-460gtx/tools/libxl/libxl_cr=
eate.c
<br>&gt; +++ /usr/src/xen-unstable.hg-rev-24341-460gtx/tools/libxl/libxl_cr=
eate.c
<br>&gt; @@ -462,7 +462,7 @@
<br>&gt; &nbsp; &nbsp; &nbsp;path =3D libxl__xs_libxl_path(gc, domid);
<br>&gt; &nbsp; &nbsp; &nbsp;path =3D libxl__sprintf(gc, "%s/dm-version", p=
ath);
<br>&gt; &nbsp; &nbsp; &nbsp;return libxl__xs_write(gc, XBT_NULL, path, lib=
xl__strdup(gc,
<br>&gt; - &nbsp; &nbsp;=20
<br>&gt; libxl_device_model_version_to_string(dm_info-&gt;device_model_vers=
ion)));
<br>&gt; + &nbsp; &nbsp;=20
<br>&gt; libxl_device_model_version_to_string(dm_info-&gt;device_model_vers=
ion)),"%s");
<br>&gt; }
<br>&gt;=20
<br>&gt; static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_=
config,
<br>&gt;=20
<br>&gt;=20
<br>&gt; --- /usr/src/xen-unstable.hg-rev-24341-460gtx/tools/libxl/libxl_de=
vice.c
<br>&gt; +++ /usr/src/xen-unstable.hg-rev-24341-460gtx/tools/libxl/libxl_de=
vice.c
<br>&gt; @@ -516,7 +516,7 @@
<br>&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;for (j =3D 0; j &lt; num_devs; j=
++) {
<br>&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;path =3D libxl__sp=
rintf(gc,
<br>&gt; "/local/domain/%d/device/%s/%s/backend",
<br>&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nb=
sp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;domid, kinds[i],=
 devs[j]);
<br>&gt; - &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;path =3D libxl__xs_read=
(gc, XBT_NULL, libxl__sprintf(gc, path));
<br>&gt; + &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;path =3D libxl__xs_read=
(gc, XBT_NULL, libxl__sprintf(gc,
<br>&gt; path,"%s"));
<br>&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;if (path &amp;&amp=
; libxl__parse_backend_path(gc, path, &amp;dev) =3D=3D 0) {
<br>&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;dev.=
domid =3D domid;
<br>&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;dev.=
kind =3D kind;
<br>&gt;=20
<br>&gt; and an due to an argument missing:
<br>&gt;=20
<br>&gt; --- /usr/src/xen-unstable.hg-rev-24341-460gtx/tools/libxl/libxl_do=
m.c
<br>&gt; +++ /usr/src/xen-unstable.hg-rev-24341-460gtx/tools/libxl/libxl_do=
m.c
<br>&gt; @@ -625,7 +625,7 @@
<br>&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;break;
<br>&gt; &nbsp; &nbsp; &nbsp;}
<br>&gt; &nbsp; &nbsp; &nbsp;case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
<br>&gt; - &nbsp; &nbsp; &nbsp; &nbsp;fd2 =3D open(filename, O_WRONLY | O_C=
REAT | O_TRUNC);
<br>&gt; + &nbsp; &nbsp; &nbsp; &nbsp;fd2 =3D open(filename, O_WRONLY | O_C=
REAT | O_TRUNC, 0644);
<br>&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;if (fd2 &lt; 0) {
<br>&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;LIBXL__LOG_ERRNO(c=
tx, LIBXL__LOG_ERROR,
<br>&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nb=
sp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; "Unable to create a QEMU save file\n=
");
<br>&gt;=20
<br>&gt; As far as I know those doesn't break anything, but dont take too s=
eriously,
<br>&gt; i'm not an experienced developer :)
<br>&gt;=20
<br>&gt;=20
<br>&gt; Forgot 2:
<br>&gt; Since I'm using an ubuntu kernel, the xen support is not integrate=
d, but
<br>&gt; you need to add xen modules at your inittrd file. I did this by ad=
ding
<br>&gt; those:
<br>&gt;=20
<br>&gt; xen-pciback passthrough=3D1
<br>&gt; xen-blkback
<br>&gt; xenfs
<br>&gt; xen-netback
<br>&gt; pci-stub
<br>&gt;=20
<br>&gt; to /etc/xen/initramfs-tools/modules and the issuing update-initram=
fs.
<br>&gt;=20
<br>&gt; In the future, I'll try to boot a linux domU, right now I'm still =
smiling
<br>&gt; cause I can fully wipe my Windows installation from the hard disk.=
 And I'm
<br>&gt; sure that in future Win7 will be supported too.
<br>&gt;=20
<br>&gt; Thanks again David and everyone,
<br>&gt; Ivo
<br>&gt;=20
<br>&gt; --
<br>&gt; View this message in context:
<br>&gt; <a rel=3D"nofollow" target=3D"_blank" href=3D"http://xen.1045712.n=
5.nabble.com/Patches-for-VGA-Passthrough-XEN-4-2-unsta" link=3D"external">h=
ttp://xen.1045712.n5.nabble.com/Patches-for-VGA-Passthrough-XEN-4-2-unsta</=
a><br>&gt; ble-tp4406265p5051880.html Sent from the Xen - Dev mailing list =
archive at
<br>&gt; Nabble.com.
<br>&gt;=20
<br>&gt; _______________________________________________
<br>&gt; Xen-devel mailing list
<br>&gt; <a rel=3D"nofollow" target=3D"_top" link=3D"external">[hidden emai=
l]</a>
<br>&gt; <a rel=3D"nofollow" target=3D"_blank" href=3D"http://lists.xensour=
ce.com/xen-devel" link=3D"external">http://lists.xensource.com/xen-devel</a=
></div></div><br>_______________________________________________
<br>Xen-devel mailing list
<br><a rel=3D"nofollow" target=3D"_top" link=3D"external">[hidden email]</a=
>
<br><a rel=3D"nofollow" target=3D"_blank" href=3D"http://lists.xensource.co=
m/xen-devel" link=3D"external">http://lists.xensource.com/xen-devel</a><br>
=09
=09<br>
=09<br>
=09<hr noshade=3D"noshade" size=3D"1" color=3D"#cccccc">
=09<div style=3D"color:#444;font:12px tahoma, geneva, helvetica, arial, san=
s-serif;">
=09=09<div style=3D"font-weight:bold;">If you reply to this email, your mes=
sage will be added to the discussion below:</div>
=09=09<a rel=3D"nofollow" target=3D"_blank" href=3D"http://xen.1045712.n5.n=
abble.com/Patches-for-VGA-Passthrough-XEN-4-2-unstable-tp4406265p5052398.ht=
ml" link=3D"external">http://xen.1045712.n5.nabble.com/Patches-for-VGA-Pass=
through-XEN-4-2-unstable-tp4406265p5052398.html</a>
=09</div>
=09<div style=3D"color:#666;font:11px tahoma, geneva, helvetica, arial, san=
s-serif;margin-top:.4em;line-height:1.5em;">
=09=09
=09=09To unsubscribe from Patches for VGA-Passthrough XEN 4.2 unstable, <a =
rel=3D"nofollow" target=3D"_blank" href=3D"" link=3D"external">click here</=
a>.<br>
=09=09<a rel=3D"nofollow" target=3D"_blank" href=3D"http://xen.1045712.n5.n=
abble.com/template/NamlServlet.jtp?macro=3Dmacro_viewer&amp;id=3Dinstant_ht=
ml%21nabble%3Aemail.naml&amp;base=3Dnabble.naml.namespaces.BasicNamespace-n=
abble.view.web.template.NabbleNamespace-nabble.view.web.template.InstantMai=
lNamespace&amp;breadcrumbs=3Dinstant+emails%21nabble%3Aemail.naml-instant_e=
mails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml" style=
=3D"font:9px serif;" link=3D"external">NAML</a>
=09</div></div><br><br> </div> </div>  </div>
=09
<br/><hr align=3D"left" width=3D"300" />
View this message in context: <a href=3D"http://xen.1045712.n5.nabble.com/P=
atches-for-VGA-Passthrough-XEN-4-2-unstable-tp4406265p5052523.html">Re : Re=
 : Re : Re : Re : Re : Re : Re : Re : Re: Patches for VGA-Passthrough XEN 4=
.2 unstable</a><br/>
Sent from the <a href=3D"http://xen.1045712.n5.nabble.com/Xen-Dev-f2473738.=
html">Xen - Dev mailing list archive</a> at Nabble.com.<br/>
------=_Part_43809_24350281.1323186997245--


--===============5420372796785576371==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============5420372796785576371==--


From xen-devel-bounces@lists.xensource.com Tue Dec 06 16:23:32 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 16:23:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXxnL-0004d4-0q; Tue, 06 Dec 2011 16:23:03 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RXxnJ-0004cr-VA
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 16:23:02 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1323188536!6413665!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjM3Ng==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27504 invoked from network); 6 Dec 2011 16:22:16 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Dec 2011 16:22:16 -0000
X-IronPort-AV: E=Sophos;i="4.71,306,1320624000"; 
   d="scan'208";a="9325587"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Dec 2011 16:22:15 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 6 Dec 2011 16:22:15 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RXxmZ-0002yF-Ho;
	Tue, 06 Dec 2011 16:22:15 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RXxmZ-0003dJ-Gg;
	Tue, 06 Dec 2011 16:22:15 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10369-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 6 Dec 2011 16:22:15 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.0-testing test] 10369: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10369 xen-4.0-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10369/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-i386-i386-xl-winxpsp3    7 windows-install              fail   never pass
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   never pass
 test-amd64-i386-xend-winxpsp3  7 windows-install              fail  never pass
 test-amd64-amd64-xl-win7-amd64  7 windows-install              fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1  5 xen-boot                 fail never pass
 test-amd64-i386-xl-win7-amd64  7 windows-install              fail  never pass
 test-amd64-amd64-xl          15 guest-stop                   fail   never pass
 test-amd64-amd64-xl-pcipt-intel  8 debian-fixup                fail never pass
 test-i386-i386-xl            15 guest-stop                   fail   never pass
 test-amd64-amd64-xl-sedf-pin 15 guest-stop                   fail   never pass
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail    like 9827
 test-amd64-i386-xl-multivcpu 15 guest-stop                   fail   never pass
 test-amd64-i386-xl-credit2    5 xen-boot                     fail    like 9850
 test-amd64-i386-xl           15 guest-stop                   fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-rhel6hvm-amd  7 redhat-install               fail   never pass
 test-amd64-i386-rhel6hvm-intel  7 redhat-install               fail never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win       7 windows-install              fail   never pass
 test-amd64-i386-xl-win-vcpus1  7 windows-install              fail  never pass
 test-i386-i386-xl-win         7 windows-install              fail   never pass

version targeted for testing:
 xen                  beabf510c4a1
baseline version:
 xen                  c16b0a997a05

------------------------------------------------------------
People who touched revisions under test:
  Gianluca Guida <gianluca.guida@citrix.com>
  Jan Beulich <jbeulich@novell.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          fail    
 test-amd64-i386-xl                                           fail    
 test-i386-i386-xl                                            fail    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-4.0-testing
+ revision=beabf510c4a1
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-4.0-testing beabf510c4a1
+ branch=xen-4.0-testing
+ revision=beabf510c4a1
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ : xen@xenbits.xensource.com
+ : xen@xenbits.xensource.com:git/linux-pvops
+ : master
+ : tested/2.6.39.x
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-4.0-testing.hg
+ hg push -r beabf510c4a1 ssh://xen@xenbits.xensource.com/HG/xen-4.0-testing.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-4.0-testing.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 1 changesets with 2 changes to 2 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 16:23:32 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 16:23:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXxnL-0004d4-0q; Tue, 06 Dec 2011 16:23:03 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RXxnJ-0004cr-VA
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 16:23:02 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1323188536!6413665!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjM3Ng==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27504 invoked from network); 6 Dec 2011 16:22:16 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Dec 2011 16:22:16 -0000
X-IronPort-AV: E=Sophos;i="4.71,306,1320624000"; 
   d="scan'208";a="9325587"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Dec 2011 16:22:15 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 6 Dec 2011 16:22:15 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RXxmZ-0002yF-Ho;
	Tue, 06 Dec 2011 16:22:15 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RXxmZ-0003dJ-Gg;
	Tue, 06 Dec 2011 16:22:15 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10369-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 6 Dec 2011 16:22:15 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.0-testing test] 10369: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10369 xen-4.0-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10369/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-i386-i386-xl-winxpsp3    7 windows-install              fail   never pass
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   never pass
 test-amd64-i386-xend-winxpsp3  7 windows-install              fail  never pass
 test-amd64-amd64-xl-win7-amd64  7 windows-install              fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1  5 xen-boot                 fail never pass
 test-amd64-i386-xl-win7-amd64  7 windows-install              fail  never pass
 test-amd64-amd64-xl          15 guest-stop                   fail   never pass
 test-amd64-amd64-xl-pcipt-intel  8 debian-fixup                fail never pass
 test-i386-i386-xl            15 guest-stop                   fail   never pass
 test-amd64-amd64-xl-sedf-pin 15 guest-stop                   fail   never pass
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail    like 9827
 test-amd64-i386-xl-multivcpu 15 guest-stop                   fail   never pass
 test-amd64-i386-xl-credit2    5 xen-boot                     fail    like 9850
 test-amd64-i386-xl           15 guest-stop                   fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-rhel6hvm-amd  7 redhat-install               fail   never pass
 test-amd64-i386-rhel6hvm-intel  7 redhat-install               fail never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win       7 windows-install              fail   never pass
 test-amd64-i386-xl-win-vcpus1  7 windows-install              fail  never pass
 test-i386-i386-xl-win         7 windows-install              fail   never pass

version targeted for testing:
 xen                  beabf510c4a1
baseline version:
 xen                  c16b0a997a05

------------------------------------------------------------
People who touched revisions under test:
  Gianluca Guida <gianluca.guida@citrix.com>
  Jan Beulich <jbeulich@novell.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          fail    
 test-amd64-i386-xl                                           fail    
 test-i386-i386-xl                                            fail    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-4.0-testing
+ revision=beabf510c4a1
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-4.0-testing beabf510c4a1
+ branch=xen-4.0-testing
+ revision=beabf510c4a1
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ : xen@xenbits.xensource.com
+ : xen@xenbits.xensource.com:git/linux-pvops
+ : master
+ : tested/2.6.39.x
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-4.0-testing.hg
+ hg push -r beabf510c4a1 ssh://xen@xenbits.xensource.com/HG/xen-4.0-testing.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-4.0-testing.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 1 changesets with 2 changes to 2 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 16:37:06 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 16: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.xensource.com>)
	id 1RXy0Q-0004pi-CS; Tue, 06 Dec 2011 16:36:34 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin.df@gmail.com>) id 1RXy0O-0004pX-JT
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 16:36:32 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1323189344!868110!1
X-Originating-IP: [209.85.216.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27603 invoked from network); 6 Dec 2011 16:35:45 -0000
Received: from mail-qy0-f171.google.com (HELO mail-qy0-f171.google.com)
	(209.85.216.171)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Dec 2011 16:35:45 -0000
Received: by qcsc20 with SMTP id c20so23130073qcs.30
	for <xen-devel@lists.xensource.com>;
	Tue, 06 Dec 2011 08:35:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=Fe2tmsT++X6p8/iyGr9SrYIwo9OTSu94uBP6x4sM+HY=;
	b=XZhiV0gohD4A+qnF1NVdIGtVKlF6bGunRRcG34VOcnHPRoqSlkbMxPIXsGb8ZUZFM+
	EUOsdl6KgwoxrscWV5tcRxPHeH0yQRrTKY/+glua6mD9xane6AGfURCpMg6e5U6AMJmn
	SETZy/wJOJ4jZYH1O3eq7Efr2xuIAG3LfovFs=
MIME-Version: 1.0
Received: by 10.68.30.10 with SMTP id o10mr33623429pbh.131.1323189343323; Tue,
	06 Dec 2011 08:35:43 -0800 (PST)
Received: by 10.142.68.2 with HTTP; Tue, 6 Dec 2011 08:35:43 -0800 (PST)
In-Reply-To: <1323167697.2488.5613.camel@elijah>
References: <1322060131.30168.15.camel@Abyss> <1322060876.30168.18.camel@Abyss>
	<1322065473.1005.151.camel@zakaz.uk.xensource.com>
	<1323167697.2488.5613.camel@elijah>
Date: Tue, 6 Dec 2011 17:35:43 +0100
X-Google-Sender-Auth: bPoF0KVIKD09LycIKiiwdvQd2iU
Message-ID: <CAAWQectTByka9Pw--Vgy0ECTfc8NJLkfRWpqpmxqJq+hgzZW5A@mail.gmail.com>
From: Dario Faggioli <raistlin@linux.it>
To: George Dunlap <george.dunlap@citrix.com>
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [RFC/RFT][PATCH 1 of 3] Move locking into pluggable
	schedulers.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Dec 6, 2011 at 11:34 AM, George Dunlap <george.dunlap@citrix.com> w=
rote:
>> Given that every scheduler plugin is going to need this lock perhaps it
>> could be provided globally (but still have the responsibility for using
>> it fall on the plugin)?
>
> Sorry for the long delay in responding... I don't really like this idea.
> For one thing, that would make the generic scheduler code responsible
> for making per-cpupool locks, which could look messy, and adds to code
> complexity.
>
Right. I was looking into this and facing right this issue, i.e., how to ma=
ke
that lock a per-cpupool thing, and wasn't quite succeeding in doing that
in a clean way.

> I also think that logically, having each scheduler in charge
> of its own locking makes more sense; having the generic scheduling code
> do stuff on behalf of the pluggable scheduler is what caused this
> problem in the first place.
>
Indeed.

> If we think having a one-item struct is ugly, could we just use
> spinlock_t as the type we allocate / cast to in the sedf scheduler?
>
Well, I put that struct there in the first place so I definitely can live
with it. I certainly don't think it is the most beautiful piece of code
I've ever wrote but, considering I'd have to dynamically allocate the
lock anyway (for the reasons above), and access it through
ops->sched_data, having it pointing directly to the lock is not that
much better than the struct to me.

Therefore, I think I'll let you decide here, and will keep or kill the
struct basing on what you think is nicer! :-)

Thanks and Regards,
Dario

-- =

<<This happens because I choose it to happen!>> (Raistlin Majere)
----------------------------------------------------------------------
Dario Faggioli, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
PhD Candidate, ReTiS Lab, Scuola Superiore Sant'Anna, Pisa =A0(Italy)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 16:37:06 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 16: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.xensource.com>)
	id 1RXy0Q-0004pi-CS; Tue, 06 Dec 2011 16:36:34 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin.df@gmail.com>) id 1RXy0O-0004pX-JT
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 16:36:32 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1323189344!868110!1
X-Originating-IP: [209.85.216.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27603 invoked from network); 6 Dec 2011 16:35:45 -0000
Received: from mail-qy0-f171.google.com (HELO mail-qy0-f171.google.com)
	(209.85.216.171)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Dec 2011 16:35:45 -0000
Received: by qcsc20 with SMTP id c20so23130073qcs.30
	for <xen-devel@lists.xensource.com>;
	Tue, 06 Dec 2011 08:35:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=Fe2tmsT++X6p8/iyGr9SrYIwo9OTSu94uBP6x4sM+HY=;
	b=XZhiV0gohD4A+qnF1NVdIGtVKlF6bGunRRcG34VOcnHPRoqSlkbMxPIXsGb8ZUZFM+
	EUOsdl6KgwoxrscWV5tcRxPHeH0yQRrTKY/+glua6mD9xane6AGfURCpMg6e5U6AMJmn
	SETZy/wJOJ4jZYH1O3eq7Efr2xuIAG3LfovFs=
MIME-Version: 1.0
Received: by 10.68.30.10 with SMTP id o10mr33623429pbh.131.1323189343323; Tue,
	06 Dec 2011 08:35:43 -0800 (PST)
Received: by 10.142.68.2 with HTTP; Tue, 6 Dec 2011 08:35:43 -0800 (PST)
In-Reply-To: <1323167697.2488.5613.camel@elijah>
References: <1322060131.30168.15.camel@Abyss> <1322060876.30168.18.camel@Abyss>
	<1322065473.1005.151.camel@zakaz.uk.xensource.com>
	<1323167697.2488.5613.camel@elijah>
Date: Tue, 6 Dec 2011 17:35:43 +0100
X-Google-Sender-Auth: bPoF0KVIKD09LycIKiiwdvQd2iU
Message-ID: <CAAWQectTByka9Pw--Vgy0ECTfc8NJLkfRWpqpmxqJq+hgzZW5A@mail.gmail.com>
From: Dario Faggioli <raistlin@linux.it>
To: George Dunlap <george.dunlap@citrix.com>
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [RFC/RFT][PATCH 1 of 3] Move locking into pluggable
	schedulers.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Dec 6, 2011 at 11:34 AM, George Dunlap <george.dunlap@citrix.com> w=
rote:
>> Given that every scheduler plugin is going to need this lock perhaps it
>> could be provided globally (but still have the responsibility for using
>> it fall on the plugin)?
>
> Sorry for the long delay in responding... I don't really like this idea.
> For one thing, that would make the generic scheduler code responsible
> for making per-cpupool locks, which could look messy, and adds to code
> complexity.
>
Right. I was looking into this and facing right this issue, i.e., how to ma=
ke
that lock a per-cpupool thing, and wasn't quite succeeding in doing that
in a clean way.

> I also think that logically, having each scheduler in charge
> of its own locking makes more sense; having the generic scheduling code
> do stuff on behalf of the pluggable scheduler is what caused this
> problem in the first place.
>
Indeed.

> If we think having a one-item struct is ugly, could we just use
> spinlock_t as the type we allocate / cast to in the sedf scheduler?
>
Well, I put that struct there in the first place so I definitely can live
with it. I certainly don't think it is the most beautiful piece of code
I've ever wrote but, considering I'd have to dynamically allocate the
lock anyway (for the reasons above), and access it through
ops->sched_data, having it pointing directly to the lock is not that
much better than the struct to me.

Therefore, I think I'll let you decide here, and will keep or kill the
struct basing on what you think is nicer! :-)

Thanks and Regards,
Dario

-- =

<<This happens because I choose it to happen!>> (Raistlin Majere)
----------------------------------------------------------------------
Dario Faggioli, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
PhD Candidate, ReTiS Lab, Scuola Superiore Sant'Anna, Pisa =A0(Italy)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 16:41:08 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 16:41:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXy4R-0004wx-24; Tue, 06 Dec 2011 16:40:43 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin.df@gmail.com>) id 1RXy4O-0004wh-QP
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 16:40:41 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1323189591!4442239!1
X-Originating-IP: [209.85.210.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11548 invoked from network); 6 Dec 2011 16:39:53 -0000
Received: from mail-pz0-f43.google.com (HELO mail-pz0-f43.google.com)
	(209.85.210.43)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Dec 2011 16:39:53 -0000
Received: by dadz13 with SMTP id z13so29238434dad.30
	for <xen-devel@lists.xensource.com>;
	Tue, 06 Dec 2011 08:39:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=+sktVdurXeZRD6rprNGodSUoEKeOjsHuESTtu1EADcg=;
	b=hWtE6RJv38TUOqmuqwojmpb0YUUTCt+hJ5ZytUvkF0pvxWH9qoUC/WgbFMeIVTFw+o
	b9WxiJVWIplUSltNXcrYV8yKMu7HRHAv9m/f7biyt93lTegiM6XyP4VvHjkwq06a2xKx
	nC7LScmag6B5DZliKMhYJ7NLlFv/Ozn5J1Dgc=
MIME-Version: 1.0
Received: by 10.68.59.4 with SMTP id v4mr33766412pbq.114.1323189590929; Tue,
	06 Dec 2011 08:39:50 -0800 (PST)
Received: by 10.142.68.2 with HTTP; Tue, 6 Dec 2011 08:39:50 -0800 (PST)
In-Reply-To: <4EDE0CFF.3000203@ts.fujitsu.com>
References: <1322060131.30168.15.camel@Abyss> <4EDDD485.70208@ts.fujitsu.com>
	<CAFLBxZao_zmfjnKisp+mQee62RhjFVRsvqy_pKP5V5oqzTBzEw@mail.gmail.com>
	<4EDE0CFF.3000203@ts.fujitsu.com>
Date: Tue, 6 Dec 2011 17:39:50 +0100
X-Google-Sender-Auth: XsBOD30MavRIThCQUqh8cNAA4q4
Message-ID: <CAAWQecs2gU2e-GtqUUKOaeEORKjznR12mYvVBsdp9TA4bONf5A@mail.gmail.com>
From: Dario Faggioli <raistlin@linux.it>
To: Juergen Gross <juergen.gross@ts.fujitsu.com>
Cc: George Dunlap <George.Dunlap@eu.citrix.com>, xen-devel@lists.xensource.com,
	Keir Fraser <keir@xen.org>
Subject: Re: [Xen-devel] [RFC/RFT][PATCH 0 of 3] rework locking in
	sched_adjust
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Dec 6, 2011 at 1:39 PM, Juergen Gross
<juergen.gross@ts.fujitsu.com> wrote:
> sedf_adjust_weights() is called only from sedf_adj(). The easiest solution
> would be to xmalloc the scratch space in sedf_adj() before grabbing the l=
ock
> and passing the xmalloced area to sedf_adjust_weights().
>
Done, and it seems to be working... It might be a bit weird to read,
but I couldn't
find any other equally easy and effective solution so.

Thanks a lot and Regards,
Dario

-- =

<<This happens because I choose it to happen!>> (Raistlin Majere)
----------------------------------------------------------------------
Dario Faggioli, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
PhD Candidate, ReTiS Lab, Scuola Superiore Sant'Anna, Pisa =A0(Italy)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 16:41:08 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 16:41:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXy4R-0004wx-24; Tue, 06 Dec 2011 16:40:43 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin.df@gmail.com>) id 1RXy4O-0004wh-QP
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 16:40:41 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1323189591!4442239!1
X-Originating-IP: [209.85.210.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11548 invoked from network); 6 Dec 2011 16:39:53 -0000
Received: from mail-pz0-f43.google.com (HELO mail-pz0-f43.google.com)
	(209.85.210.43)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Dec 2011 16:39:53 -0000
Received: by dadz13 with SMTP id z13so29238434dad.30
	for <xen-devel@lists.xensource.com>;
	Tue, 06 Dec 2011 08:39:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=+sktVdurXeZRD6rprNGodSUoEKeOjsHuESTtu1EADcg=;
	b=hWtE6RJv38TUOqmuqwojmpb0YUUTCt+hJ5ZytUvkF0pvxWH9qoUC/WgbFMeIVTFw+o
	b9WxiJVWIplUSltNXcrYV8yKMu7HRHAv9m/f7biyt93lTegiM6XyP4VvHjkwq06a2xKx
	nC7LScmag6B5DZliKMhYJ7NLlFv/Ozn5J1Dgc=
MIME-Version: 1.0
Received: by 10.68.59.4 with SMTP id v4mr33766412pbq.114.1323189590929; Tue,
	06 Dec 2011 08:39:50 -0800 (PST)
Received: by 10.142.68.2 with HTTP; Tue, 6 Dec 2011 08:39:50 -0800 (PST)
In-Reply-To: <4EDE0CFF.3000203@ts.fujitsu.com>
References: <1322060131.30168.15.camel@Abyss> <4EDDD485.70208@ts.fujitsu.com>
	<CAFLBxZao_zmfjnKisp+mQee62RhjFVRsvqy_pKP5V5oqzTBzEw@mail.gmail.com>
	<4EDE0CFF.3000203@ts.fujitsu.com>
Date: Tue, 6 Dec 2011 17:39:50 +0100
X-Google-Sender-Auth: XsBOD30MavRIThCQUqh8cNAA4q4
Message-ID: <CAAWQecs2gU2e-GtqUUKOaeEORKjznR12mYvVBsdp9TA4bONf5A@mail.gmail.com>
From: Dario Faggioli <raistlin@linux.it>
To: Juergen Gross <juergen.gross@ts.fujitsu.com>
Cc: George Dunlap <George.Dunlap@eu.citrix.com>, xen-devel@lists.xensource.com,
	Keir Fraser <keir@xen.org>
Subject: Re: [Xen-devel] [RFC/RFT][PATCH 0 of 3] rework locking in
	sched_adjust
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Dec 6, 2011 at 1:39 PM, Juergen Gross
<juergen.gross@ts.fujitsu.com> wrote:
> sedf_adjust_weights() is called only from sedf_adj(). The easiest solution
> would be to xmalloc the scratch space in sedf_adj() before grabbing the l=
ock
> and passing the xmalloced area to sedf_adjust_weights().
>
Done, and it seems to be working... It might be a bit weird to read,
but I couldn't
find any other equally easy and effective solution so.

Thanks a lot and Regards,
Dario

-- =

<<This happens because I choose it to happen!>> (Raistlin Majere)
----------------------------------------------------------------------
Dario Faggioli, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
PhD Candidate, ReTiS Lab, Scuola Superiore Sant'Anna, Pisa =A0(Italy)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 16:48:22 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 16:48:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXyB8-00059V-U4; Tue, 06 Dec 2011 16:47:38 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin.df@gmail.com>) id 1RXyB7-00059P-Qs
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 16:47:38 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1323189969!56240339!1
X-Originating-IP: [209.85.210.43]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4987 invoked from network); 6 Dec 2011 16:46:11 -0000
Received: from mail-pz0-f43.google.com (HELO mail-pz0-f43.google.com)
	(209.85.210.43)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Dec 2011 16:46:10 -0000
Received: by dadz13 with SMTP id z13so29264920dad.30
	for <xen-devel@lists.xensource.com>;
	Tue, 06 Dec 2011 08:46:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=YPRX2+pcJJvrrILMY64G6ggjYOGxB5Q6HaV2oeP4Ngc=;
	b=WjtqhgQeM7c7Ty4fTqgnifFv8EXSSjH5X6xSr/J8jxTVuA0w9C+Uaa28lt1wEaWqlX
	X2IXxhrGfOlqqo57JK3SnMiesFjVBduqa2MYquvTcsiwP2xa/cMIg74hQA/XvXNoOJpj
	U9+xGbO0tTmFZ5thLPrQNSsvI2RCYr1mJCPI0=
MIME-Version: 1.0
Received: by 10.68.59.4 with SMTP id v4mr33810149pbq.114.1323190014565; Tue,
	06 Dec 2011 08:46:54 -0800 (PST)
Received: by 10.142.68.2 with HTTP; Tue, 6 Dec 2011 08:46:54 -0800 (PST)
In-Reply-To: <CAFLBxZaa2L4a1sXqcCQPRk8tDPwJ6tCnm6w=ut_1NtbK+9XP=g@mail.gmail.com>
References: <1322060131.30168.15.camel@Abyss>
	<CAFLBxZaa2L4a1sXqcCQPRk8tDPwJ6tCnm6w=ut_1NtbK+9XP=g@mail.gmail.com>
Date: Tue, 6 Dec 2011 17:46:54 +0100
X-Google-Sender-Auth: r_amNDPS80c3IE7_18dcoU-7ZQ0
Message-ID: <CAAWQecu6zRsP8gY88AvL-sx4FYvLSWsSvobhJS=C_9axceU3FQ@mail.gmail.com>
From: Dario Faggioli <raistlin@linux.it>
To: George Dunlap <George.Dunlap@eu.citrix.com>
Cc: Juergen Gross <juergen.gross@ts.fujitsu.com>, xen-devel@lists.xensource.com,
	Keir Fraser <keir@xen.org>
Subject: Re: [Xen-devel] [RFC/RFT][PATCH 0 of 3] rework locking in
	sched_adjust
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Dec 6, 2011 at 1:24 PM, George Dunlap
<George.Dunlap@eu.citrix.com> wrote:
> Hey Dario, =A0sorry for the long delay in responding.
>
Hi, and no problem at all :-)

> Regressions in mid-patch series are bad because it can mess up bisection.
>
I strongly agree. I didn't think much about that for this series since
the mechanism
I was trying to fix was (especially for sedf) already broken in
various ways but,
indeed, patches could be better split.

> I think a better way of breaking it down would be:
> * Add scheduler global locks, and have them called in the pluggable
> scheduler *_adjust() function. =A0This is redundant, but shouldn't be
> harmful.
> * Atomically remove both the pause and the lock in schedule.c, and add
> the scheduling locks around the per-vcpu EDOM_INFO variables in
> sched_sedf.c, all in one patch. =A0This makes the patch bigger, but it
> avoids a regression.
>
Ok, I'll go for this.

> The two things are related anwyay: the reason
> you now need scheduling locks around EDOM_INFO variables is because
> you're getting rid of the pausing and the lock in schedule.c.
>
Yeah, what I was trying to do was leaving a clear footstep about why
pausing was going and, yes, also making patches smaller, but again, I
see your point and will follow your advice. :-)

Thanks and Regards,
Dario

-- =

<<This happens because I choose it to happen!>> (Raistlin Majere)
----------------------------------------------------------------------
Dario Faggioli, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
PhD Candidate, ReTiS Lab, Scuola Superiore Sant'Anna, Pisa =A0(Italy)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 16:48:22 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 16:48:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXyB8-00059V-U4; Tue, 06 Dec 2011 16:47:38 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin.df@gmail.com>) id 1RXyB7-00059P-Qs
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 16:47:38 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1323189969!56240339!1
X-Originating-IP: [209.85.210.43]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4987 invoked from network); 6 Dec 2011 16:46:11 -0000
Received: from mail-pz0-f43.google.com (HELO mail-pz0-f43.google.com)
	(209.85.210.43)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Dec 2011 16:46:10 -0000
Received: by dadz13 with SMTP id z13so29264920dad.30
	for <xen-devel@lists.xensource.com>;
	Tue, 06 Dec 2011 08:46:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=YPRX2+pcJJvrrILMY64G6ggjYOGxB5Q6HaV2oeP4Ngc=;
	b=WjtqhgQeM7c7Ty4fTqgnifFv8EXSSjH5X6xSr/J8jxTVuA0w9C+Uaa28lt1wEaWqlX
	X2IXxhrGfOlqqo57JK3SnMiesFjVBduqa2MYquvTcsiwP2xa/cMIg74hQA/XvXNoOJpj
	U9+xGbO0tTmFZ5thLPrQNSsvI2RCYr1mJCPI0=
MIME-Version: 1.0
Received: by 10.68.59.4 with SMTP id v4mr33810149pbq.114.1323190014565; Tue,
	06 Dec 2011 08:46:54 -0800 (PST)
Received: by 10.142.68.2 with HTTP; Tue, 6 Dec 2011 08:46:54 -0800 (PST)
In-Reply-To: <CAFLBxZaa2L4a1sXqcCQPRk8tDPwJ6tCnm6w=ut_1NtbK+9XP=g@mail.gmail.com>
References: <1322060131.30168.15.camel@Abyss>
	<CAFLBxZaa2L4a1sXqcCQPRk8tDPwJ6tCnm6w=ut_1NtbK+9XP=g@mail.gmail.com>
Date: Tue, 6 Dec 2011 17:46:54 +0100
X-Google-Sender-Auth: r_amNDPS80c3IE7_18dcoU-7ZQ0
Message-ID: <CAAWQecu6zRsP8gY88AvL-sx4FYvLSWsSvobhJS=C_9axceU3FQ@mail.gmail.com>
From: Dario Faggioli <raistlin@linux.it>
To: George Dunlap <George.Dunlap@eu.citrix.com>
Cc: Juergen Gross <juergen.gross@ts.fujitsu.com>, xen-devel@lists.xensource.com,
	Keir Fraser <keir@xen.org>
Subject: Re: [Xen-devel] [RFC/RFT][PATCH 0 of 3] rework locking in
	sched_adjust
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Dec 6, 2011 at 1:24 PM, George Dunlap
<George.Dunlap@eu.citrix.com> wrote:
> Hey Dario, =A0sorry for the long delay in responding.
>
Hi, and no problem at all :-)

> Regressions in mid-patch series are bad because it can mess up bisection.
>
I strongly agree. I didn't think much about that for this series since
the mechanism
I was trying to fix was (especially for sedf) already broken in
various ways but,
indeed, patches could be better split.

> I think a better way of breaking it down would be:
> * Add scheduler global locks, and have them called in the pluggable
> scheduler *_adjust() function. =A0This is redundant, but shouldn't be
> harmful.
> * Atomically remove both the pause and the lock in schedule.c, and add
> the scheduling locks around the per-vcpu EDOM_INFO variables in
> sched_sedf.c, all in one patch. =A0This makes the patch bigger, but it
> avoids a regression.
>
Ok, I'll go for this.

> The two things are related anwyay: the reason
> you now need scheduling locks around EDOM_INFO variables is because
> you're getting rid of the pausing and the lock in schedule.c.
>
Yeah, what I was trying to do was leaving a clear footstep about why
pausing was going and, yes, also making patches smaller, but again, I
see your point and will follow your advice. :-)

Thanks and Regards,
Dario

-- =

<<This happens because I choose it to happen!>> (Raistlin Majere)
----------------------------------------------------------------------
Dario Faggioli, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
PhD Candidate, ReTiS Lab, Scuola Superiore Sant'Anna, Pisa =A0(Italy)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 17:07:17 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 17:07:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXyTM-0005PQ-RF; Tue, 06 Dec 2011 17:06:28 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <miche@google.com>) id 1RXyTL-0005PL-Jr
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 17:06:27 +0000
X-Env-Sender: miche@google.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1323191139!4503076!1
X-Originating-IP: [209.85.216.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15116 invoked from network); 6 Dec 2011 17:05:40 -0000
Received: from mail-qy0-f171.google.com (HELO mail-qy0-f171.google.com)
	(209.85.216.171)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Dec 2011 17:05:40 -0000
Received: by qcsc20 with SMTP id c20so23330947qcs.30
	for <xen-devel@lists.xensource.com>;
	Tue, 06 Dec 2011 09:05:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding:x-system-of-record;
	bh=h2JUNgcd8A8Ab9D4O7wkpIufOBgpIVBU2ljpe8A9yxs=;
	b=bJjyf3oi6l28NtD+SGfk5UxOuz8epNHZvv0p7vN405HO2yH45H/4vLYUdJzcR1oZpn
	M7HXt23kmilBOXH8J1Rg==
Received: by 10.229.213.73 with SMTP id gv9mr3315327qcb.134.1323191138822;
	Tue, 06 Dec 2011 09:05:38 -0800 (PST)
MIME-Version: 1.0
Received: by 10.229.213.73 with SMTP id gv9mr3315309qcb.134.1323191138411;
	Tue, 06 Dec 2011 09:05:38 -0800 (PST)
Received: by 10.229.176.154 with HTTP; Tue, 6 Dec 2011 09:05:38 -0800 (PST)
In-Reply-To: <20111205105452.GB27683@amit-x200.redhat.com>
References: <20111108214452.28884.14840.stgit@miche.sea.corp.google.com>
	<20111108214504.28884.61814.stgit@miche.sea.corp.google.com>
	<874nybqo0o.fsf@rustcorp.com.au>
	<CAB8RdapbaueyWLJuJDE_ZdvLkRNM4sQHTxgmgO=jrnXZ6YPSmA@mail.gmail.com>
	<20111123103852.GG16665@amit-x200.redhat.com>
	<CAB8RdaoDxMCgTjuGP70bGrsrtgh=USYtU3Spo5OPtVMYAM5EzQ@mail.gmail.com>
	<20111129142149.GE2822@amit-x200.redhat.com>
	<CAB8RdapuPRym2dH_9mgmGdzpCxnP1KpS+hS8JJ-geVkga5fMcw@mail.gmail.com>
	<CAB8Rdapfuf5XH+X9gsUL+CJ9gTQcSNfq4Dj9DoYWQeFgD04ODQ@mail.gmail.com>
	<20111205105452.GB27683@amit-x200.redhat.com>
Date: Tue, 6 Dec 2011 09:05:38 -0800
Message-ID: <CAB8Rdar=qOokxZkjQVRmo=zN_f75jPwzU+6=WBRo0g+P7w+pAw@mail.gmail.com>
From: Miche Baker-Harvey <miche@google.com>
To: Amit Shah <amit.shah@redhat.com>
X-System-Of-Record: true
Cc: Stephen Rothwell <sfr@canb.auug.org.au>, xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Rusty Russell <rusty@rustcorp.com.au>, linux-kernel@vger.kernel.org,
	virtualization@lists.linux-foundation.org,
	Anton Blanchard <anton@samba.org>, Mike Waychison <mikew@google.com>,
	ppc-dev <linuxppc-dev@lists.ozlabs.org>,
	Greg Kroah-Hartman <gregkh@suse.de>, Eric Northrup <digitaleric@google.com>
Subject: Re: [Xen-devel] [PATCH v3 2/3] hvc_init(): Enforce one-time
	initialization.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Amit,

Ah, indeed.  I am not using MSI-X, so virtio_pci::vp_try_to_find_vqs()
calls vp_request_intx() and sets up an interrupt callback.  From
there, when an interrupt occurs, the stack looks something like this:

virtio_pci::vp_interrupt()
  virtio_pci::vp_vring_interrupt()
    virtio_ring::vring_interrupt()
      vq->vq.callback()  <-- in this case, that's virtio_console::control_i=
ntr()
        workqueue::schedule_work()
          workqueue::queue_work()
            queue_work_on(get_cpu())  <-- queues the work on the current CP=
U.

I'm not doing anything to keep multiple control message from being
sent concurrently to the guest, and we will take those interrupts on
any CPU. I've confirmed that the two instances of
handle_control_message() are occurring on different CPUs.

Should this work?  I don't see anywhere that QEMU is serializing the
sending of data to the control queue in the guest, and there's no
serialization in
the control_intr.  I don't understand why you are not seeing the
concurrent execution of handle_control_message().  Are you taking all
your interrupts on a single CPU, maybe?  Or is there some other
serialization in user space?

Miche


On Mon, Dec 5, 2011 at 2:54 AM, Amit Shah <amit.shah@redhat.com> wrote:
> On (Tue) 29 Nov 2011 [09:50:41], Miche Baker-Harvey wrote:
>> Good grief! =A0Sorry for the spacing mess-up! =A0Here's a resend with re=
formatting.
>>
>> Amit,
>> We aren't using either QEMU or kvmtool, but we are using KVM. =A0All
>
> So it's a different userspace? =A0Any chance this different userspace is
> causing these problems to appear? =A0Esp. since I couldn't reproduce
> with qemu.
>
>> the issues we are seeing happen when we try to establish multiple
>> virtioconsoles at boot time. =A0The command line isn't relevant, but I
>> can tell you the protocol that's passing between the host (kvm) and
>> the guest (see the end of this message).
>>
>> We do go through the control_work_handler(), but it's not
>> providing synchronization. =A0Here's a trace of the
>> control_work_handler() and handle_control_message() calls; note that
>> there are two concurrent calls to control_work_handler().
>
> Ah; how does that happen? =A0control_work_handler() should just be
> invoked once, and if there are any more pending work items to be
> consumed, they should be done within the loop inside
> control_work_handler().
>
>> I decorated control_work_handler() with a "lifetime" marker, and
>> passed this value to handle_control_message(), so we can see which
>> control messages are being handled from which instance of
>> the control_work_handler() thread.
>>
>> Notice that we enter control_work_handler() a second time before
>> the handling of the second PORT_ADD message is complete. The
>> first CONSOLE_PORT message is handled by the second
>> control_work_handler() call, but the second is handled by the first
>> control_work_handler() call.
>>
>> root@myubuntu:~# dmesg | grep MBH
>> [3371055.808738] control_work_handler #1
>> [3371055.809372] + #1 handle_control_message PORT_ADD
>> [3371055.810169] - handle_control_message PORT_ADD
>> [3371055.810170] + #1 handle_control_message PORT_ADD
>> [3371055.810244] =A0control_work_handler #2
>> [3371055.810245] + #2 handle_control_message CONSOLE_PORT
>> [3371055.810246] =A0got hvc_ports_mutex
>> [3371055.810578] - handle_control_message PORT_ADD
>> [3371055.810579] + #1 handle_control_message CONSOLE_PORT
>> [3371055.810580] =A0trylock of hvc_ports_mutex failed
>> [3371055.811352] =A0got hvc_ports_mutex
>> [3371055.811370] - handle_control_message CONSOLE_PORT
>> [3371055.816609] - handle_control_message CONSOLE_PORT
>>
>> So, I'm guessing the bug is that there shouldn't be two instances of
>> control_work_handler() running simultaneously?
>
> Yep, I assumed we did that but apparently not. =A0Do you plan to chase
> this one down?
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Amit
>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 17:07:17 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 17:07:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXyTM-0005PQ-RF; Tue, 06 Dec 2011 17:06:28 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <miche@google.com>) id 1RXyTL-0005PL-Jr
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 17:06:27 +0000
X-Env-Sender: miche@google.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1323191139!4503076!1
X-Originating-IP: [209.85.216.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15116 invoked from network); 6 Dec 2011 17:05:40 -0000
Received: from mail-qy0-f171.google.com (HELO mail-qy0-f171.google.com)
	(209.85.216.171)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Dec 2011 17:05:40 -0000
Received: by qcsc20 with SMTP id c20so23330947qcs.30
	for <xen-devel@lists.xensource.com>;
	Tue, 06 Dec 2011 09:05:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding:x-system-of-record;
	bh=h2JUNgcd8A8Ab9D4O7wkpIufOBgpIVBU2ljpe8A9yxs=;
	b=bJjyf3oi6l28NtD+SGfk5UxOuz8epNHZvv0p7vN405HO2yH45H/4vLYUdJzcR1oZpn
	M7HXt23kmilBOXH8J1Rg==
Received: by 10.229.213.73 with SMTP id gv9mr3315327qcb.134.1323191138822;
	Tue, 06 Dec 2011 09:05:38 -0800 (PST)
MIME-Version: 1.0
Received: by 10.229.213.73 with SMTP id gv9mr3315309qcb.134.1323191138411;
	Tue, 06 Dec 2011 09:05:38 -0800 (PST)
Received: by 10.229.176.154 with HTTP; Tue, 6 Dec 2011 09:05:38 -0800 (PST)
In-Reply-To: <20111205105452.GB27683@amit-x200.redhat.com>
References: <20111108214452.28884.14840.stgit@miche.sea.corp.google.com>
	<20111108214504.28884.61814.stgit@miche.sea.corp.google.com>
	<874nybqo0o.fsf@rustcorp.com.au>
	<CAB8RdapbaueyWLJuJDE_ZdvLkRNM4sQHTxgmgO=jrnXZ6YPSmA@mail.gmail.com>
	<20111123103852.GG16665@amit-x200.redhat.com>
	<CAB8RdaoDxMCgTjuGP70bGrsrtgh=USYtU3Spo5OPtVMYAM5EzQ@mail.gmail.com>
	<20111129142149.GE2822@amit-x200.redhat.com>
	<CAB8RdapuPRym2dH_9mgmGdzpCxnP1KpS+hS8JJ-geVkga5fMcw@mail.gmail.com>
	<CAB8Rdapfuf5XH+X9gsUL+CJ9gTQcSNfq4Dj9DoYWQeFgD04ODQ@mail.gmail.com>
	<20111205105452.GB27683@amit-x200.redhat.com>
Date: Tue, 6 Dec 2011 09:05:38 -0800
Message-ID: <CAB8Rdar=qOokxZkjQVRmo=zN_f75jPwzU+6=WBRo0g+P7w+pAw@mail.gmail.com>
From: Miche Baker-Harvey <miche@google.com>
To: Amit Shah <amit.shah@redhat.com>
X-System-Of-Record: true
Cc: Stephen Rothwell <sfr@canb.auug.org.au>, xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Rusty Russell <rusty@rustcorp.com.au>, linux-kernel@vger.kernel.org,
	virtualization@lists.linux-foundation.org,
	Anton Blanchard <anton@samba.org>, Mike Waychison <mikew@google.com>,
	ppc-dev <linuxppc-dev@lists.ozlabs.org>,
	Greg Kroah-Hartman <gregkh@suse.de>, Eric Northrup <digitaleric@google.com>
Subject: Re: [Xen-devel] [PATCH v3 2/3] hvc_init(): Enforce one-time
	initialization.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Amit,

Ah, indeed.  I am not using MSI-X, so virtio_pci::vp_try_to_find_vqs()
calls vp_request_intx() and sets up an interrupt callback.  From
there, when an interrupt occurs, the stack looks something like this:

virtio_pci::vp_interrupt()
  virtio_pci::vp_vring_interrupt()
    virtio_ring::vring_interrupt()
      vq->vq.callback()  <-- in this case, that's virtio_console::control_i=
ntr()
        workqueue::schedule_work()
          workqueue::queue_work()
            queue_work_on(get_cpu())  <-- queues the work on the current CP=
U.

I'm not doing anything to keep multiple control message from being
sent concurrently to the guest, and we will take those interrupts on
any CPU. I've confirmed that the two instances of
handle_control_message() are occurring on different CPUs.

Should this work?  I don't see anywhere that QEMU is serializing the
sending of data to the control queue in the guest, and there's no
serialization in
the control_intr.  I don't understand why you are not seeing the
concurrent execution of handle_control_message().  Are you taking all
your interrupts on a single CPU, maybe?  Or is there some other
serialization in user space?

Miche


On Mon, Dec 5, 2011 at 2:54 AM, Amit Shah <amit.shah@redhat.com> wrote:
> On (Tue) 29 Nov 2011 [09:50:41], Miche Baker-Harvey wrote:
>> Good grief! =A0Sorry for the spacing mess-up! =A0Here's a resend with re=
formatting.
>>
>> Amit,
>> We aren't using either QEMU or kvmtool, but we are using KVM. =A0All
>
> So it's a different userspace? =A0Any chance this different userspace is
> causing these problems to appear? =A0Esp. since I couldn't reproduce
> with qemu.
>
>> the issues we are seeing happen when we try to establish multiple
>> virtioconsoles at boot time. =A0The command line isn't relevant, but I
>> can tell you the protocol that's passing between the host (kvm) and
>> the guest (see the end of this message).
>>
>> We do go through the control_work_handler(), but it's not
>> providing synchronization. =A0Here's a trace of the
>> control_work_handler() and handle_control_message() calls; note that
>> there are two concurrent calls to control_work_handler().
>
> Ah; how does that happen? =A0control_work_handler() should just be
> invoked once, and if there are any more pending work items to be
> consumed, they should be done within the loop inside
> control_work_handler().
>
>> I decorated control_work_handler() with a "lifetime" marker, and
>> passed this value to handle_control_message(), so we can see which
>> control messages are being handled from which instance of
>> the control_work_handler() thread.
>>
>> Notice that we enter control_work_handler() a second time before
>> the handling of the second PORT_ADD message is complete. The
>> first CONSOLE_PORT message is handled by the second
>> control_work_handler() call, but the second is handled by the first
>> control_work_handler() call.
>>
>> root@myubuntu:~# dmesg | grep MBH
>> [3371055.808738] control_work_handler #1
>> [3371055.809372] + #1 handle_control_message PORT_ADD
>> [3371055.810169] - handle_control_message PORT_ADD
>> [3371055.810170] + #1 handle_control_message PORT_ADD
>> [3371055.810244] =A0control_work_handler #2
>> [3371055.810245] + #2 handle_control_message CONSOLE_PORT
>> [3371055.810246] =A0got hvc_ports_mutex
>> [3371055.810578] - handle_control_message PORT_ADD
>> [3371055.810579] + #1 handle_control_message CONSOLE_PORT
>> [3371055.810580] =A0trylock of hvc_ports_mutex failed
>> [3371055.811352] =A0got hvc_ports_mutex
>> [3371055.811370] - handle_control_message CONSOLE_PORT
>> [3371055.816609] - handle_control_message CONSOLE_PORT
>>
>> So, I'm guessing the bug is that there shouldn't be two instances of
>> control_work_handler() running simultaneously?
>
> Yep, I assumed we did that but apparently not. =A0Do you plan to chase
> this one down?
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Amit
>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 17:08:41 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 17:08:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXyUm-0005TB-U0; Tue, 06 Dec 2011 17:07:56 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RXyUk-0005SN-IM
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 17:07:54 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-3.tower-21.messagelabs.com!1323191226!7183238!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMjA5MTI=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMjA5MTI=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27156 invoked from network); 6 Dec 2011 17:07:07 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-3.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Dec 2011 17:07:07 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1323191226; l=2157;
	s=domk; d=aepfle.de;
	h=To:From:Date:References:In-Reply-To:Subject:
	Content-Transfer-Encoding:MIME-Version:Content-Type:X-RZG-CLASS-ID:
	X-RZG-AUTH; bh=SpWbiDDa+hY7dra+ZCFXn4+1Lp0=;
	b=MntHhl42x10tgGCnEIPLbG1j2kkF1323qDI0Sjrue2aud2UzHq8zd9TpjQqAJWJr/G6
	fafxsOYlBVRQ6hXafrEHCmjD2WVBPnyB+NDSxdrRfEUdFoy16FPf5Tmxfj+Rh8W6LWAfB
	0hV9g7u1owklLDWjn82J8au+s0QGdJK47qM=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lq387qFz2T
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-076-151.pools.arcor-ip.net [84.57.76.151])
	by smtp.strato.de (cohen mo16) (RZmta 26.10 AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id L040e3nB6GJC8S
	for <xen-devel@lists.xensource.com>;
	Tue, 6 Dec 2011 18:07:04 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 9FC291863A
	for <xen-devel@lists.xensource.com>;
	Tue,  6 Dec 2011 18:07:03 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 4e52b9c9309815a4b05c7b970a95e318d59fb71b
Message-Id: <4e52b9c9309815a4b05c.1323191225@probook.site>
In-Reply-To: <patchbomb.1323191221@probook.site>
References: <patchbomb.1323191221@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Tue, 06 Dec 2011 18:07:05 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 4 of 5] xenpaging: restore p2mt if gfn is needed
	before evict
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1323189150 -3600
# Node ID 4e52b9c9309815a4b05c7b970a95e318d59fb71b
# Parent  7f2cfd9bd113c40a49cc7e036fd07eb706a22f15
xenpaging: restore p2mt if gfn is needed before evict

In the rare case that a gfn is needed by a guest or a foreign domain
between nominate and evict, restore the p2mt and skip sending a request.
A request is not needed because the pager will notice the evict failure.

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 7f2cfd9bd113 -r 4e52b9c93098 xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -905,6 +905,7 @@ void p2m_mem_paging_populate(struct doma
     p2m_type_t p2mt;
     p2m_access_t a;
     mfn_t mfn;
+    int restored = 0;
     struct p2m_domain *p2m = p2m_get_hostp2m(d);
 
     /* Check that there's space on the ring for this request */
@@ -920,22 +921,25 @@ void p2m_mem_paging_populate(struct doma
     /* Allow only nominated or evicted pages to enter page-in path */
     if ( p2m_do_populate(p2mt) )
     {
-        /* Evict will fail now, tag this request for pager */
-        if ( p2mt == p2m_ram_paging_out )
-            req.flags |= MEM_EVENT_FLAG_EVICT_FAIL;
-
-        set_p2m_entry(p2m, gfn, mfn, PAGE_ORDER_4K, p2m_ram_paging_in_start, a);
+        /* Restore page state if gfn was requested before evict */
+        if ( p2mt == p2m_ram_paging_out && mfn_valid(mfn) ) {
+            set_p2m_entry(p2m, gfn, mfn, PAGE_ORDER_4K,
+                          paging_mode_log_dirty(d) ? p2m_ram_logdirty : p2m_ram_rw, a);
+            restored = 1;
+        } else {
+            set_p2m_entry(p2m, gfn, mfn, PAGE_ORDER_4K, p2m_ram_paging_in_start, a);
+        }
     }
     p2m_unlock(p2m);
 
     /* Pause domain if request came from guest and gfn has paging type */
-    if (  p2m_is_paging(p2mt) && v->domain == d )
+    if ( !restored && p2m_is_paging(p2mt) && v->domain == d )
     {
         vcpu_pause_nosync(v);
         req.flags |= MEM_EVENT_FLAG_VCPU_PAUSED;
     }
     /* No need to inform pager if the gfn is not in the page-out path */
-    else if ( !p2m_do_populate(p2mt) )
+    else if ( restored || !p2m_do_populate(p2mt) )
     {
         /* gfn is already on its way back and vcpu is not paused */
         mem_event_put_req_producers(&d->mem_event->paging);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 17:08:41 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 17:08:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXyUm-0005TB-U0; Tue, 06 Dec 2011 17:07:56 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RXyUk-0005SN-IM
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 17:07:54 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-3.tower-21.messagelabs.com!1323191226!7183238!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMjA5MTI=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMjA5MTI=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27156 invoked from network); 6 Dec 2011 17:07:07 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-3.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Dec 2011 17:07:07 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1323191226; l=2157;
	s=domk; d=aepfle.de;
	h=To:From:Date:References:In-Reply-To:Subject:
	Content-Transfer-Encoding:MIME-Version:Content-Type:X-RZG-CLASS-ID:
	X-RZG-AUTH; bh=SpWbiDDa+hY7dra+ZCFXn4+1Lp0=;
	b=MntHhl42x10tgGCnEIPLbG1j2kkF1323qDI0Sjrue2aud2UzHq8zd9TpjQqAJWJr/G6
	fafxsOYlBVRQ6hXafrEHCmjD2WVBPnyB+NDSxdrRfEUdFoy16FPf5Tmxfj+Rh8W6LWAfB
	0hV9g7u1owklLDWjn82J8au+s0QGdJK47qM=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lq387qFz2T
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-076-151.pools.arcor-ip.net [84.57.76.151])
	by smtp.strato.de (cohen mo16) (RZmta 26.10 AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id L040e3nB6GJC8S
	for <xen-devel@lists.xensource.com>;
	Tue, 6 Dec 2011 18:07:04 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 9FC291863A
	for <xen-devel@lists.xensource.com>;
	Tue,  6 Dec 2011 18:07:03 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 4e52b9c9309815a4b05c7b970a95e318d59fb71b
Message-Id: <4e52b9c9309815a4b05c.1323191225@probook.site>
In-Reply-To: <patchbomb.1323191221@probook.site>
References: <patchbomb.1323191221@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Tue, 06 Dec 2011 18:07:05 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 4 of 5] xenpaging: restore p2mt if gfn is needed
	before evict
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1323189150 -3600
# Node ID 4e52b9c9309815a4b05c7b970a95e318d59fb71b
# Parent  7f2cfd9bd113c40a49cc7e036fd07eb706a22f15
xenpaging: restore p2mt if gfn is needed before evict

In the rare case that a gfn is needed by a guest or a foreign domain
between nominate and evict, restore the p2mt and skip sending a request.
A request is not needed because the pager will notice the evict failure.

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 7f2cfd9bd113 -r 4e52b9c93098 xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -905,6 +905,7 @@ void p2m_mem_paging_populate(struct doma
     p2m_type_t p2mt;
     p2m_access_t a;
     mfn_t mfn;
+    int restored = 0;
     struct p2m_domain *p2m = p2m_get_hostp2m(d);
 
     /* Check that there's space on the ring for this request */
@@ -920,22 +921,25 @@ void p2m_mem_paging_populate(struct doma
     /* Allow only nominated or evicted pages to enter page-in path */
     if ( p2m_do_populate(p2mt) )
     {
-        /* Evict will fail now, tag this request for pager */
-        if ( p2mt == p2m_ram_paging_out )
-            req.flags |= MEM_EVENT_FLAG_EVICT_FAIL;
-
-        set_p2m_entry(p2m, gfn, mfn, PAGE_ORDER_4K, p2m_ram_paging_in_start, a);
+        /* Restore page state if gfn was requested before evict */
+        if ( p2mt == p2m_ram_paging_out && mfn_valid(mfn) ) {
+            set_p2m_entry(p2m, gfn, mfn, PAGE_ORDER_4K,
+                          paging_mode_log_dirty(d) ? p2m_ram_logdirty : p2m_ram_rw, a);
+            restored = 1;
+        } else {
+            set_p2m_entry(p2m, gfn, mfn, PAGE_ORDER_4K, p2m_ram_paging_in_start, a);
+        }
     }
     p2m_unlock(p2m);
 
     /* Pause domain if request came from guest and gfn has paging type */
-    if (  p2m_is_paging(p2mt) && v->domain == d )
+    if ( !restored && p2m_is_paging(p2mt) && v->domain == d )
     {
         vcpu_pause_nosync(v);
         req.flags |= MEM_EVENT_FLAG_VCPU_PAUSED;
     }
     /* No need to inform pager if the gfn is not in the page-out path */
-    else if ( !p2m_do_populate(p2mt) )
+    else if ( restored || !p2m_do_populate(p2mt) )
     {
         /* gfn is already on its way back and vcpu is not paused */
         mem_event_put_req_producers(&d->mem_event->paging);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 17:08:43 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 17: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.xensource.com>)
	id 1RXyUy-0005Vj-4L; Tue, 06 Dec 2011 17:08:08 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RXyUw-0005Tt-5R
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 17:08:06 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-15.tower-216.messagelabs.com!1323191239!6386861!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMzU2Mjg=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMzU2Mjg=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25374 invoked from network); 6 Dec 2011 17:07:20 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-15.tower-216.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 6 Dec 2011 17:07:20 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1323191239; l=1224;
	s=domk; d=aepfle.de;
	h=To:From:Date:Subject:Content-Transfer-Encoding:MIME-Version:
	Content-Type:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=OG/r6KkBxgctb34AGOJZHD7n4uk=;
	b=pIr8ZsQmWjwLUEFl9pHt8+uO5VMiHNZcKKJuKTbvpupRrlFwZI9cPfigoRrttV7q0hy
	2Q3qWEC5BqbbBpRw3CHQ3PrFYAkjh+rrSifUOeBgiRxvMwDqMic47K334lMcignu2X/qJ
	r9uWWDNkZp9YpMGczt2/INBtmFOtFqoJBzA=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lq387qFz2T
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-076-151.pools.arcor-ip.net [84.57.76.151])
	by smtp.strato.de (klopstock mo53) (RZmta 26.10 AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id 2054ffnB6FRoNy
	for <xen-devel@lists.xensource.com>;
	Tue, 6 Dec 2011 18:07:03 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id E500218636
	for <xen-devel@lists.xensource.com>;
	Tue,  6 Dec 2011 18:07:02 +0100 (CET)
MIME-Version: 1.0
Message-Id: <patchbomb.1323191221@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Tue, 06 Dec 2011 18:07:01 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 0 of 5] xenpaging: improve page-out path
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


The following series makes mapping a gfn from foreign domains more robust. Now
that xc_mem_paging_load() takes care of the page-in path, adjust also the
page-out path. This moves the pager out of the way and all places where a p2mt
check is done can now return -ENOENT right away.

Olaf

Changes:
xenpaging: extend xc_mem_paging_enable() to handle interface version
xenpaging: map gfn before nomination
xenpaging: add need_populate and paged_no_mfn checks
xenpaging: restore p2mt if gfn is needed before evict
xenpaging: improve evict error handling

 tools/libxc/xc_mem_paging.c      |    3 +-
 tools/libxc/xenctrl.h            |    1 
 tools/xenpaging/xenpaging.c      |   49 ++++++++++++++++++++++++----------
 xen/arch/x86/hvm/emulate.c       |    3 +-
 xen/arch/x86/hvm/hvm.c           |   17 +++++++-----
 xen/arch/x86/mm.c                |   55 +++++++++++----------------------------
 xen/arch/x86/mm/guest_walk.c     |    3 +-
 xen/arch/x86/mm/hap/guest_walk.c |    6 ++--
 xen/arch/x86/mm/mem_event.c      |    9 ++++++
 xen/arch/x86/mm/p2m-ept.c        |    3 --
 xen/arch/x86/mm/p2m.c            |   33 ++++++++++++-----------
 xen/common/grant_table.c         |    3 +-
 xen/include/asm-x86/p2m.h        |    9 ++++--
 xen/include/public/mem_event.h   |    2 +
 14 files changed, 110 insertions(+), 86 deletions(-)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 17:08:43 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 17: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.xensource.com>)
	id 1RXyUu-0005Uj-NO; Tue, 06 Dec 2011 17:08:04 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RXyUs-0005TL-L2
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 17:08:03 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-5.tower-21.messagelabs.com!1323191235!887721!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMjA5MTI=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMjA5MTI=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29502 invoked from network); 6 Dec 2011 17:07:16 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-5.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Dec 2011 17:07:16 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1323191234; l=4146;
	s=domk; d=aepfle.de;
	h=To:From:Date:References:In-Reply-To:Subject:
	Content-Transfer-Encoding:MIME-Version:Content-Type:X-RZG-CLASS-ID:
	X-RZG-AUTH; bh=1UXGKBFFWWbEQXYbyBB0s85H1Q8=;
	b=a0G+uEG03+wTJSJh/BsguoA22nGQagKla36uSy/+Z0SMovV6/vuQlt0do1qfmMWjYRg
	+AXFsXZywXoeY0EG+wQprh3tnWgRfD8KMhY9wmMPyjnzJEn7U590VU9lm+S1o7xBFfAGn
	+krJkwg2T5y0ro8NH7kPBcKPpbCTgRiDyZA=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lq387qFz2T
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-076-151.pools.arcor-ip.net [84.57.76.151])
	by smtp.strato.de (cohen mo63) (RZmta 26.10 AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id 2063cbnB6H06cH
	for <xen-devel@lists.xensource.com>;
	Tue, 6 Dec 2011 18:07:04 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id CFEBB1863B
	for <xen-devel@lists.xensource.com>;
	Tue,  6 Dec 2011 18:07:03 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 344e337be85eee244036f7cd158b64fe9d09aa00
Message-Id: <344e337be85eee244036.1323191226@probook.site>
In-Reply-To: <patchbomb.1323191221@probook.site>
References: <patchbomb.1323191221@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Tue, 06 Dec 2011 18:07:06 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 5 of 5] xenpaging: improve evict error handling
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1323189154 -3600
# Node ID 344e337be85eee244036f7cd158b64fe9d09aa00
# Parent  4e52b9c9309815a4b05c7b970a95e318d59fb71b
xenpaging: improve evict error handling

Adjust return codes in Xen and handle errors in evict_victim() properly.

p2m_mem_paging_nominate() returns -EAGAIN, p2m_mem_paging_evict()
returns -EBUSY.  Other errors indicate guest failures, which
xenpaging_evict_page() can now catch correctly. Also write() failures
are fatal.

Without this change, evict_victim() may spin forever if the guest is
killed because this function does not get a signal.

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 4e52b9c93098 -r 344e337be85e tools/xenpaging/xenpaging.c
--- a/tools/xenpaging/xenpaging.c
+++ b/tools/xenpaging/xenpaging.c
@@ -576,9 +576,11 @@ static int xenpaging_evict_page(xenpagin
 
     DECLARE_DOMCTL;
 
+    /* Errors are fatal */
+    ret = -1;
+
     /* Map page to get a handle */
     gfn = victim->gfn;
-    ret = -EFAULT;
     page = xc_map_foreign_pages(xch, paging->mem_event.domain_id,
                                 PROT_READ | PROT_WRITE, &gfn, 1);
     if ( page == NULL )
@@ -588,13 +590,15 @@ static int xenpaging_evict_page(xenpagin
     }
 
     /* Nominate the page */
-    ret = xc_mem_paging_nominate(xch, paging->mem_event.domain_id, gfn);
-    if ( ret != 0 )
+    if ( xc_mem_paging_nominate(xch, paging->mem_event.domain_id, gfn) )
+    {
+        if ( errno == EAGAIN )
+            ret = 1;
         goto out;
+    }
 
     /* Copy page */
-    ret = write_page(fd, page, i);
-    if ( ret != 0 )
+    if ( write_page(fd, page, i) )
     {
         PERROR("Error copying page %lx", victim->gfn);
         goto out;
@@ -604,10 +608,10 @@ static int xenpaging_evict_page(xenpagin
     page = NULL;
 
     /* Tell Xen to evict page */
-    ret = xc_mem_paging_evict(xch, paging->mem_event.domain_id,
-                              victim->gfn);
-    if ( ret != 0 )
+    if ( xc_mem_paging_evict(xch, paging->mem_event.domain_id, victim->gfn) )
     {
+        if ( errno == EBUSY )
+            ret = 1;
         PERROR("Error evicting page %lx", victim->gfn);
         goto out;
     }
@@ -619,6 +623,8 @@ static int xenpaging_evict_page(xenpagin
     /* Record number of evicted pages */
     paging->num_paged_out++;
 
+    ret = 0;
+
  out:
     if (page)
         munmap(page, PAGE_SIZE);
@@ -746,7 +752,12 @@ static int evict_victim(xenpaging_t *pag
             goto out;
         }
         ret = xenpaging_evict_page(paging, victim, fd, i);
-        if ( ret && j++ % 1000 == 0 )
+        if ( ret < 0 )
+        {
+            ret = -EINTR;
+            goto out;
+        }
+        if ( ret > 0 && j++ % 1000 == 0 )
         {
             if ( xenpaging_mem_paging_flush_ioemu_cache(paging) )
                 PERROR("Error flushing ioemu cache");
diff -r 4e52b9c93098 -r 344e337be85e xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -735,19 +735,17 @@ int p2m_mem_paging_nominate(struct domai
     p2m_type_t p2mt;
     p2m_access_t a;
     mfn_t mfn;
-    int ret;
+    int ret = -EAGAIN;
 
     p2m_lock(p2m);
 
     mfn = p2m->get_entry(p2m, gfn, &p2mt, &a, p2m_query, NULL);
 
     /* Check if mfn is valid */
-    ret = -EINVAL;
     if ( !mfn_valid(mfn) )
         goto out;
 
     /* Check p2m type */
-    ret = -EAGAIN;
     if ( !p2m_is_pageable(p2mt) )
         goto out;
 
@@ -799,7 +797,7 @@ int p2m_mem_paging_evict(struct domain *
     p2m_access_t a;
     mfn_t mfn;
     struct p2m_domain *p2m = p2m_get_hostp2m(d);
-    int ret = -EINVAL;
+    int ret = -EBUSY;
 
     p2m_lock(p2m);
 
@@ -812,7 +810,6 @@ int p2m_mem_paging_evict(struct domain *
     if ( p2mt != p2m_ram_paging_out )
         goto out;
 
-    ret = -EBUSY;
     /* Get the page so it doesn't get modified under Xen's feet */
     page = mfn_to_page(mfn);
     if ( unlikely(!get_page(page, d)) )
diff -r 4e52b9c93098 -r 344e337be85e xen/include/public/mem_event.h
--- a/xen/include/public/mem_event.h
+++ b/xen/include/public/mem_event.h
@@ -49,7 +49,7 @@
 #define MEM_EVENT_REASON_INT3        5    /* int3 was hit: gla/gfn are RIP */
 #define MEM_EVENT_REASON_SINGLESTEP  6    /* single step was invoked: gla/gfn are RIP */
 
-#define MEM_EVENT_PAGING_AGE         2UL  /* Number distinguish the mem_paging <-> pager interface */
+#define MEM_EVENT_PAGING_AGE         3UL  /* Number distinguish the mem_paging <-> pager interface */
 
 typedef struct mem_event_shared_page {
     uint32_t port;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 17:08:43 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 17: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.xensource.com>)
	id 1RXyUy-0005Vj-4L; Tue, 06 Dec 2011 17:08:08 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RXyUw-0005Tt-5R
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 17:08:06 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-15.tower-216.messagelabs.com!1323191239!6386861!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMzU2Mjg=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMzU2Mjg=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25374 invoked from network); 6 Dec 2011 17:07:20 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-15.tower-216.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 6 Dec 2011 17:07:20 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1323191239; l=1224;
	s=domk; d=aepfle.de;
	h=To:From:Date:Subject:Content-Transfer-Encoding:MIME-Version:
	Content-Type:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=OG/r6KkBxgctb34AGOJZHD7n4uk=;
	b=pIr8ZsQmWjwLUEFl9pHt8+uO5VMiHNZcKKJuKTbvpupRrlFwZI9cPfigoRrttV7q0hy
	2Q3qWEC5BqbbBpRw3CHQ3PrFYAkjh+rrSifUOeBgiRxvMwDqMic47K334lMcignu2X/qJ
	r9uWWDNkZp9YpMGczt2/INBtmFOtFqoJBzA=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lq387qFz2T
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-076-151.pools.arcor-ip.net [84.57.76.151])
	by smtp.strato.de (klopstock mo53) (RZmta 26.10 AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id 2054ffnB6FRoNy
	for <xen-devel@lists.xensource.com>;
	Tue, 6 Dec 2011 18:07:03 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id E500218636
	for <xen-devel@lists.xensource.com>;
	Tue,  6 Dec 2011 18:07:02 +0100 (CET)
MIME-Version: 1.0
Message-Id: <patchbomb.1323191221@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Tue, 06 Dec 2011 18:07:01 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 0 of 5] xenpaging: improve page-out path
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


The following series makes mapping a gfn from foreign domains more robust. Now
that xc_mem_paging_load() takes care of the page-in path, adjust also the
page-out path. This moves the pager out of the way and all places where a p2mt
check is done can now return -ENOENT right away.

Olaf

Changes:
xenpaging: extend xc_mem_paging_enable() to handle interface version
xenpaging: map gfn before nomination
xenpaging: add need_populate and paged_no_mfn checks
xenpaging: restore p2mt if gfn is needed before evict
xenpaging: improve evict error handling

 tools/libxc/xc_mem_paging.c      |    3 +-
 tools/libxc/xenctrl.h            |    1 
 tools/xenpaging/xenpaging.c      |   49 ++++++++++++++++++++++++----------
 xen/arch/x86/hvm/emulate.c       |    3 +-
 xen/arch/x86/hvm/hvm.c           |   17 +++++++-----
 xen/arch/x86/mm.c                |   55 +++++++++++----------------------------
 xen/arch/x86/mm/guest_walk.c     |    3 +-
 xen/arch/x86/mm/hap/guest_walk.c |    6 ++--
 xen/arch/x86/mm/mem_event.c      |    9 ++++++
 xen/arch/x86/mm/p2m-ept.c        |    3 --
 xen/arch/x86/mm/p2m.c            |   33 ++++++++++++-----------
 xen/common/grant_table.c         |    3 +-
 xen/include/asm-x86/p2m.h        |    9 ++++--
 xen/include/public/mem_event.h   |    2 +
 14 files changed, 110 insertions(+), 86 deletions(-)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 17:08:43 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 17: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.xensource.com>)
	id 1RXyUu-0005Uj-NO; Tue, 06 Dec 2011 17:08:04 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RXyUs-0005TL-L2
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 17:08:03 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-5.tower-21.messagelabs.com!1323191235!887721!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMjA5MTI=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMjA5MTI=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29502 invoked from network); 6 Dec 2011 17:07:16 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-5.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Dec 2011 17:07:16 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1323191234; l=4146;
	s=domk; d=aepfle.de;
	h=To:From:Date:References:In-Reply-To:Subject:
	Content-Transfer-Encoding:MIME-Version:Content-Type:X-RZG-CLASS-ID:
	X-RZG-AUTH; bh=1UXGKBFFWWbEQXYbyBB0s85H1Q8=;
	b=a0G+uEG03+wTJSJh/BsguoA22nGQagKla36uSy/+Z0SMovV6/vuQlt0do1qfmMWjYRg
	+AXFsXZywXoeY0EG+wQprh3tnWgRfD8KMhY9wmMPyjnzJEn7U590VU9lm+S1o7xBFfAGn
	+krJkwg2T5y0ro8NH7kPBcKPpbCTgRiDyZA=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lq387qFz2T
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-076-151.pools.arcor-ip.net [84.57.76.151])
	by smtp.strato.de (cohen mo63) (RZmta 26.10 AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id 2063cbnB6H06cH
	for <xen-devel@lists.xensource.com>;
	Tue, 6 Dec 2011 18:07:04 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id CFEBB1863B
	for <xen-devel@lists.xensource.com>;
	Tue,  6 Dec 2011 18:07:03 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 344e337be85eee244036f7cd158b64fe9d09aa00
Message-Id: <344e337be85eee244036.1323191226@probook.site>
In-Reply-To: <patchbomb.1323191221@probook.site>
References: <patchbomb.1323191221@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Tue, 06 Dec 2011 18:07:06 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 5 of 5] xenpaging: improve evict error handling
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1323189154 -3600
# Node ID 344e337be85eee244036f7cd158b64fe9d09aa00
# Parent  4e52b9c9309815a4b05c7b970a95e318d59fb71b
xenpaging: improve evict error handling

Adjust return codes in Xen and handle errors in evict_victim() properly.

p2m_mem_paging_nominate() returns -EAGAIN, p2m_mem_paging_evict()
returns -EBUSY.  Other errors indicate guest failures, which
xenpaging_evict_page() can now catch correctly. Also write() failures
are fatal.

Without this change, evict_victim() may spin forever if the guest is
killed because this function does not get a signal.

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 4e52b9c93098 -r 344e337be85e tools/xenpaging/xenpaging.c
--- a/tools/xenpaging/xenpaging.c
+++ b/tools/xenpaging/xenpaging.c
@@ -576,9 +576,11 @@ static int xenpaging_evict_page(xenpagin
 
     DECLARE_DOMCTL;
 
+    /* Errors are fatal */
+    ret = -1;
+
     /* Map page to get a handle */
     gfn = victim->gfn;
-    ret = -EFAULT;
     page = xc_map_foreign_pages(xch, paging->mem_event.domain_id,
                                 PROT_READ | PROT_WRITE, &gfn, 1);
     if ( page == NULL )
@@ -588,13 +590,15 @@ static int xenpaging_evict_page(xenpagin
     }
 
     /* Nominate the page */
-    ret = xc_mem_paging_nominate(xch, paging->mem_event.domain_id, gfn);
-    if ( ret != 0 )
+    if ( xc_mem_paging_nominate(xch, paging->mem_event.domain_id, gfn) )
+    {
+        if ( errno == EAGAIN )
+            ret = 1;
         goto out;
+    }
 
     /* Copy page */
-    ret = write_page(fd, page, i);
-    if ( ret != 0 )
+    if ( write_page(fd, page, i) )
     {
         PERROR("Error copying page %lx", victim->gfn);
         goto out;
@@ -604,10 +608,10 @@ static int xenpaging_evict_page(xenpagin
     page = NULL;
 
     /* Tell Xen to evict page */
-    ret = xc_mem_paging_evict(xch, paging->mem_event.domain_id,
-                              victim->gfn);
-    if ( ret != 0 )
+    if ( xc_mem_paging_evict(xch, paging->mem_event.domain_id, victim->gfn) )
     {
+        if ( errno == EBUSY )
+            ret = 1;
         PERROR("Error evicting page %lx", victim->gfn);
         goto out;
     }
@@ -619,6 +623,8 @@ static int xenpaging_evict_page(xenpagin
     /* Record number of evicted pages */
     paging->num_paged_out++;
 
+    ret = 0;
+
  out:
     if (page)
         munmap(page, PAGE_SIZE);
@@ -746,7 +752,12 @@ static int evict_victim(xenpaging_t *pag
             goto out;
         }
         ret = xenpaging_evict_page(paging, victim, fd, i);
-        if ( ret && j++ % 1000 == 0 )
+        if ( ret < 0 )
+        {
+            ret = -EINTR;
+            goto out;
+        }
+        if ( ret > 0 && j++ % 1000 == 0 )
         {
             if ( xenpaging_mem_paging_flush_ioemu_cache(paging) )
                 PERROR("Error flushing ioemu cache");
diff -r 4e52b9c93098 -r 344e337be85e xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -735,19 +735,17 @@ int p2m_mem_paging_nominate(struct domai
     p2m_type_t p2mt;
     p2m_access_t a;
     mfn_t mfn;
-    int ret;
+    int ret = -EAGAIN;
 
     p2m_lock(p2m);
 
     mfn = p2m->get_entry(p2m, gfn, &p2mt, &a, p2m_query, NULL);
 
     /* Check if mfn is valid */
-    ret = -EINVAL;
     if ( !mfn_valid(mfn) )
         goto out;
 
     /* Check p2m type */
-    ret = -EAGAIN;
     if ( !p2m_is_pageable(p2mt) )
         goto out;
 
@@ -799,7 +797,7 @@ int p2m_mem_paging_evict(struct domain *
     p2m_access_t a;
     mfn_t mfn;
     struct p2m_domain *p2m = p2m_get_hostp2m(d);
-    int ret = -EINVAL;
+    int ret = -EBUSY;
 
     p2m_lock(p2m);
 
@@ -812,7 +810,6 @@ int p2m_mem_paging_evict(struct domain *
     if ( p2mt != p2m_ram_paging_out )
         goto out;
 
-    ret = -EBUSY;
     /* Get the page so it doesn't get modified under Xen's feet */
     page = mfn_to_page(mfn);
     if ( unlikely(!get_page(page, d)) )
diff -r 4e52b9c93098 -r 344e337be85e xen/include/public/mem_event.h
--- a/xen/include/public/mem_event.h
+++ b/xen/include/public/mem_event.h
@@ -49,7 +49,7 @@
 #define MEM_EVENT_REASON_INT3        5    /* int3 was hit: gla/gfn are RIP */
 #define MEM_EVENT_REASON_SINGLESTEP  6    /* single step was invoked: gla/gfn are RIP */
 
-#define MEM_EVENT_PAGING_AGE         2UL  /* Number distinguish the mem_paging <-> pager interface */
+#define MEM_EVENT_PAGING_AGE         3UL  /* Number distinguish the mem_paging <-> pager interface */
 
 typedef struct mem_event_shared_page {
     uint32_t port;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 17:08:45 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 17:08:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXyV1-0005XH-Ol; Tue, 06 Dec 2011 17:08:11 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RXyUz-0005Uh-VA
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 17:08:10 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-2.tower-216.messagelabs.com!1323191243!7743701!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.5 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMjA5MTI=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMjA5MTI=\n,BODY_RANDOM_LONG
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30589 invoked from network); 6 Dec 2011 17:07:23 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-2.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Dec 2011 17:07:23 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1323191243; l=10363;
	s=domk; d=aepfle.de;
	h=To:From:Date:References:In-Reply-To:Subject:
	Content-Transfer-Encoding:MIME-Version:Content-Type:X-RZG-CLASS-ID:
	X-RZG-AUTH; bh=/8boVDxWUQL5mFuKZWt5Gbxd70Q=;
	b=ZpUS282V86ZGz3DiXkEDlwSqd9S2oVQEZiE1G1rngeW5XgvWAGRFL2yeNbLVEDrqhBU
	+scuHX+nxGHbZOF+xXwvKFOkxQUEold4isUh2IS79U385BkdJwjbjGZN0d6n9ck0xwdaI
	Hz7QO3x6kV3wbCiPAzEBe/cw4wuo+tnlJNc=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lq387qFz2T
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-076-151.pools.arcor-ip.net [84.57.76.151])
	by smtp.strato.de (jimi mo49) (RZmta 26.10 AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id Y050f7nB6FcAE0
	for <xen-devel@lists.xensource.com>;
	Tue, 6 Dec 2011 18:07:04 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 7B06318639
	for <xen-devel@lists.xensource.com>;
	Tue,  6 Dec 2011 18:07:03 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 7f2cfd9bd113c40a49cc7e036fd07eb706a22f15
Message-Id: <7f2cfd9bd113c40a49cc.1323191224@probook.site>
In-Reply-To: <patchbomb.1323191221@probook.site>
References: <patchbomb.1323191221@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Tue, 06 Dec 2011 18:07:04 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 3 of 5] xenpaging: add need_populate and
	paged_no_mfn checks
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1323189148 -3600
# Node ID 7f2cfd9bd113c40a49cc7e036fd07eb706a22f15
# Parent  96d3292797d861592a7d2d3840f371ec719775a9
xenpaging: add need_populate and paged_no_mfn checks

There is currently a mix of p2mt checks for the various paging types.
Some mean the p2mt needs to be populated, others mean a gfn without mfn.

Add a new p2m_do_populate() helper which covers the p2m_ram_paged and
p2m_ram_paging_out types. If a gfn is not in these states anymore another
populate request for the pager is not needed. This avoids a call to
p2m_mem_paging_populate() which in turn reduces the pressure on the ring
buffer because no temporary slot needs to be claimed. As such, this helper is
an optimization.

Modify the existing p2m_is_paged() helper which now covers also
p2m_ram_paging_in_start in addition to the current p2m_ram_paged type.  A gfn
in these two states is not backed by a mfn.

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 96d3292797d8 -r 7f2cfd9bd113 xen/arch/x86/hvm/emulate.c
--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -67,7 +67,8 @@ static int hvmemul_do_io(
     ram_mfn = get_gfn_unshare(curr->domain, ram_gfn, &p2mt);
     if ( p2m_is_paging(p2mt) )
     {
-        p2m_mem_paging_populate(curr->domain, ram_gfn);
+        if ( p2m_do_populate(p2mt) )
+            p2m_mem_paging_populate(curr->domain, ram_gfn);
         put_gfn(curr->domain, ram_gfn); 
         return X86EMUL_RETRY;
     }
diff -r 96d3292797d8 -r 7f2cfd9bd113 xen/arch/x86/hvm/hvm.c
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -363,7 +363,8 @@ static int hvm_set_ioreq_page(
     }
     if ( p2m_is_paging(p2mt) )
     {
-        p2m_mem_paging_populate(d, gmfn);
+        if ( p2m_do_populate(p2mt) )
+            p2m_mem_paging_populate(d, gmfn);
         put_gfn(d, gmfn);
         return -ENOENT;
     }
@@ -1298,7 +1299,7 @@ int hvm_hap_nested_page_fault(unsigned l
 
 #ifdef __x86_64__
     /* Check if the page has been paged out */
-    if ( p2m_is_paged(p2mt) || (p2mt == p2m_ram_paging_out) )
+    if ( p2m_do_populate(p2mt) )
         p2m_mem_paging_populate(v->domain, gfn);
 
     /* Mem sharing: unshare the page and try again */
@@ -1844,7 +1845,8 @@ static void *__hvm_map_guest_frame(unsig
     }
     if ( p2m_is_paging(p2mt) )
     {
-        p2m_mem_paging_populate(d, gfn);
+        if ( p2m_do_populate(p2mt) )
+            p2m_mem_paging_populate(d, gfn);
         put_gfn(d, gfn);
         return NULL;
     }
@@ -2320,7 +2322,8 @@ static enum hvm_copy_result __hvm_copy(
 
         if ( p2m_is_paging(p2mt) )
         {
-            p2m_mem_paging_populate(curr->domain, gfn);
+            if ( p2m_do_populate(p2mt) )
+                p2m_mem_paging_populate(curr->domain, gfn);
             put_gfn(curr->domain, gfn);
             return HVMCOPY_gfn_paged_out;
         }
@@ -3808,7 +3811,8 @@ long do_hvm_op(unsigned long op, XEN_GUE
             mfn_t mfn = get_gfn_unshare(d, pfn, &t);
             if ( p2m_is_paging(t) )
             {
-                p2m_mem_paging_populate(d, pfn);
+                if ( p2m_do_populate(t) )
+                    p2m_mem_paging_populate(d, pfn);
                 put_gfn(d, pfn);
                 rc = -EINVAL;
                 goto param_fail3;
@@ -3912,7 +3916,8 @@ long do_hvm_op(unsigned long op, XEN_GUE
             mfn = get_gfn_unshare(d, pfn, &t);
             if ( p2m_is_paging(t) )
             {
-                p2m_mem_paging_populate(d, pfn);
+                if ( p2m_do_populate(t) )
+                    p2m_mem_paging_populate(d, pfn);
                 put_gfn(d, pfn);
                 rc = -EINVAL;
                 goto param_fail4;
diff -r 96d3292797d8 -r 7f2cfd9bd113 xen/arch/x86/mm.c
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -3528,9 +3528,10 @@ int do_mmu_update(
             if ( !p2m_is_valid(p2mt) )
                 mfn = INVALID_MFN;
 
-            if ( p2m_is_paged(p2mt) )
+            if ( p2m_is_paging(p2mt) )
             {
-                p2m_mem_paging_populate(pg_owner, gmfn);
+                if ( p2m_is_paged(p2mt) )
+                    p2m_mem_paging_populate(pg_owner, gmfn);
                 put_gfn(pt_owner, gmfn);
                 rc = -ENOENT;
                 break;
@@ -3560,21 +3561,15 @@ int do_mmu_update(
     
                     l1emfn = mfn_x(get_gfn(pg_owner, l1egfn, &l1e_p2mt));
 
-                    if ( p2m_is_paged(l1e_p2mt) )
+#ifdef __x86_64__
+                    if ( p2m_is_paging(l1e_p2mt) )
                     {
-                        p2m_mem_paging_populate(pg_owner, l1e_get_pfn(l1e));
+                        if ( p2m_is_paged(l1e_p2mt) )
+                            p2m_mem_paging_populate(pg_owner, l1e_get_pfn(l1e));
                         put_gfn(pg_owner, l1egfn);
                         rc = -ENOENT;
                         break;
                     }
-                    else if ( p2m_ram_paging_in_start == l1e_p2mt && 
-                                !mfn_valid(l1emfn) )
-                    {
-                        put_gfn(pg_owner, l1egfn);
-                        rc = -ENOENT;
-                        break;
-                    }
-#ifdef __x86_64__
                     /* XXX: Ugly: pull all the checks into a separate function. 
                      * Don't want to do it now, not to interfere with mem_paging
                      * patches */
@@ -3609,16 +3604,10 @@ int do_mmu_update(
 
                     l2emfn = mfn_x(get_gfn(pg_owner, l2egfn, &l2e_p2mt));
 
-                    if ( p2m_is_paged(l2e_p2mt) )
+                    if ( p2m_is_paging(l2e_p2mt) )
                     {
-                        p2m_mem_paging_populate(pg_owner, l2egfn);
-                        put_gfn(pg_owner, l2egfn);
-                        rc = -ENOENT;
-                        break;
-                    }
-                    else if ( p2m_ram_paging_in_start == l2e_p2mt && 
-                                !mfn_valid(l2emfn) )
-                    {
+                        if ( p2m_is_paged(l2e_p2mt) )
+                            p2m_mem_paging_populate(pg_owner, l2egfn);
                         put_gfn(pg_owner, l2egfn);
                         rc = -ENOENT;
                         break;
@@ -3644,16 +3633,10 @@ int do_mmu_update(
 
                     l3emfn = mfn_x(get_gfn(pg_owner, l3egfn, &l3e_p2mt));
 
-                    if ( p2m_is_paged(l3e_p2mt) )
+                    if ( p2m_is_paging(l3e_p2mt) )
                     {
-                        p2m_mem_paging_populate(pg_owner, l3egfn);
-                        put_gfn(pg_owner, l3egfn);
-                        rc = -ENOENT;
-                        break;
-                    }
-                    else if ( p2m_ram_paging_in_start == l3e_p2mt && 
-                                !mfn_valid(l3emfn) )
-                    {
+                        if ( p2m_is_paged(l3e_p2mt) )
+                            p2m_mem_paging_populate(pg_owner, l3egfn);
                         put_gfn(pg_owner, l3egfn);
                         rc = -ENOENT;
                         break;
@@ -3679,16 +3662,10 @@ int do_mmu_update(
 
                     l4emfn = mfn_x(get_gfn(pg_owner, l4egfn, &l4e_p2mt));
 
-                    if ( p2m_is_paged(l4e_p2mt) )
+                    if ( p2m_is_paging(l4e_p2mt) )
                     {
-                        p2m_mem_paging_populate(pg_owner, l4egfn);
-                        put_gfn(pg_owner, l4egfn);
-                        rc = -ENOENT;
-                        break;
-                    }
-                    else if ( p2m_ram_paging_in_start == l4e_p2mt && 
-                                !mfn_valid(l4emfn) )
-                    {
+                        if ( p2m_is_paged(l4e_p2mt) )
+                            p2m_mem_paging_populate(pg_owner, l4egfn);
                         put_gfn(pg_owner, l4egfn);
                         rc = -ENOENT;
                         break;
diff -r 96d3292797d8 -r 7f2cfd9bd113 xen/arch/x86/mm/guest_walk.c
--- a/xen/arch/x86/mm/guest_walk.c
+++ b/xen/arch/x86/mm/guest_walk.c
@@ -102,7 +102,8 @@ static inline void *map_domain_gfn(struc
     if ( p2m_is_paging(*p2mt) )
     {
         ASSERT(!p2m_is_nestedp2m(p2m));
-        p2m_mem_paging_populate(p2m->domain, gfn_x(gfn));
+        if ( p2m_do_populate(*p2mt) )
+            p2m_mem_paging_populate(p2m->domain, gfn_x(gfn));
         __put_gfn(p2m, gfn_x(gfn));
         *rc = _PAGE_PAGED;
         return NULL;
diff -r 96d3292797d8 -r 7f2cfd9bd113 xen/arch/x86/mm/hap/guest_walk.c
--- a/xen/arch/x86/mm/hap/guest_walk.c
+++ b/xen/arch/x86/mm/hap/guest_walk.c
@@ -64,7 +64,8 @@ unsigned long hap_p2m_ga_to_gfn(GUEST_PA
     if ( p2m_is_paging(p2mt) )
     {
         ASSERT(!p2m_is_nestedp2m(p2m));
-        p2m_mem_paging_populate(p2m->domain, cr3 >> PAGE_SHIFT);
+        if ( p2m_do_populate(p2mt) )
+            p2m_mem_paging_populate(p2m->domain, cr3 >> PAGE_SHIFT);
 
         pfec[0] = PFEC_page_paged;
         __put_gfn(p2m, top_gfn);
@@ -101,7 +102,8 @@ unsigned long hap_p2m_ga_to_gfn(GUEST_PA
         if ( p2m_is_paging(p2mt) )
         {
             ASSERT(!p2m_is_nestedp2m(p2m));
-            p2m_mem_paging_populate(p2m->domain, gfn_x(gfn));
+            if ( p2m_do_populate(p2mt) )
+                p2m_mem_paging_populate(p2m->domain, gfn_x(gfn));
 
             pfec[0] = PFEC_page_paged;
             __put_gfn(p2m, gfn_x(gfn));
diff -r 96d3292797d8 -r 7f2cfd9bd113 xen/arch/x86/mm/p2m-ept.c
--- a/xen/arch/x86/mm/p2m-ept.c
+++ b/xen/arch/x86/mm/p2m-ept.c
@@ -375,8 +375,7 @@ ept_set_entry(struct p2m_domain *p2m, un
          * Read-then-write is OK because we hold the p2m lock. */
         old_entry = *ept_entry;
 
-        if ( mfn_valid(mfn_x(mfn)) || direct_mmio || p2m_is_paged(p2mt) ||
-             (p2mt == p2m_ram_paging_in_start) )
+        if ( mfn_valid(mfn_x(mfn)) || direct_mmio || p2m_is_paged(p2mt) )
         {
             /* Construct the new entry, and then write it once */
             new_entry.emt = epte_get_entry_emt(p2m->domain, gfn, mfn, &ipat,
diff -r 96d3292797d8 -r 7f2cfd9bd113 xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -918,7 +918,7 @@ void p2m_mem_paging_populate(struct doma
     p2m_lock(p2m);
     mfn = p2m->get_entry(p2m, gfn, &p2mt, &a, p2m_query, NULL);
     /* Allow only nominated or evicted pages to enter page-in path */
-    if ( p2mt == p2m_ram_paging_out || p2mt == p2m_ram_paged )
+    if ( p2m_do_populate(p2mt) )
     {
         /* Evict will fail now, tag this request for pager */
         if ( p2mt == p2m_ram_paging_out )
@@ -935,7 +935,7 @@ void p2m_mem_paging_populate(struct doma
         req.flags |= MEM_EVENT_FLAG_VCPU_PAUSED;
     }
     /* No need to inform pager if the gfn is not in the page-out path */
-    else if ( p2mt != p2m_ram_paging_out && p2mt != p2m_ram_paged )
+    else if ( !p2m_do_populate(p2mt) )
     {
         /* gfn is already on its way back and vcpu is not paused */
         mem_event_put_req_producers(&d->mem_event->paging);
diff -r 96d3292797d8 -r 7f2cfd9bd113 xen/common/grant_table.c
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -163,7 +163,8 @@ static int __get_paged_frame(unsigned lo
         *frame = mfn_x(mfn);
         if ( p2m_is_paging(p2mt) )
         {
-            p2m_mem_paging_populate(rd, gfn);
+            if ( p2m_do_populate(p2mt) )
+                p2m_mem_paging_populate(rd, gfn);
             put_gfn(rd, gfn);
             rc = GNTST_eagain;
         }
diff -r 96d3292797d8 -r 7f2cfd9bd113 xen/include/asm-x86/p2m.h
--- a/xen/include/asm-x86/p2m.h
+++ b/xen/include/asm-x86/p2m.h
@@ -158,7 +158,11 @@ typedef enum {
                           | p2m_to_mask(p2m_ram_paging_in_start) \
                           | p2m_to_mask(p2m_ram_paging_in))
 
-#define P2M_PAGED_TYPES (p2m_to_mask(p2m_ram_paged))
+#define P2M_POPULATE_TYPES (p2m_to_mask(p2m_ram_paged) \
+                            | p2m_to_mask(p2m_ram_paging_out) )
+
+#define P2M_PAGED_NO_MFN_TYPES (p2m_to_mask(p2m_ram_paged) \
+                               | p2m_to_mask(p2m_ram_paging_in_start) )
 
 /* Shared types */
 /* XXX: Sharable types could include p2m_ram_ro too, but we would need to
@@ -184,7 +188,8 @@ typedef enum {
 #define p2m_has_emt(_t)  (p2m_to_mask(_t) & (P2M_RAM_TYPES | p2m_to_mask(p2m_mmio_direct)))
 #define p2m_is_pageable(_t) (p2m_to_mask(_t) & P2M_PAGEABLE_TYPES)
 #define p2m_is_paging(_t)   (p2m_to_mask(_t) & P2M_PAGING_TYPES)
-#define p2m_is_paged(_t)    (p2m_to_mask(_t) & P2M_PAGED_TYPES)
+#define p2m_is_paged(_t)    (p2m_to_mask(_t) & P2M_PAGED_NO_MFN_TYPES)
+#define p2m_do_populate(_t) (p2m_to_mask(_t) & P2M_POPULATE_TYPES)
 #define p2m_is_sharable(_t) (p2m_to_mask(_t) & P2M_SHARABLE_TYPES)
 #define p2m_is_shared(_t)   (p2m_to_mask(_t) & P2M_SHARED_TYPES)
 #define p2m_is_broken(_t)   (p2m_to_mask(_t) & P2M_BROKEN_TYPES)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 17:08:45 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 17:08:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXyV1-0005XH-Ol; Tue, 06 Dec 2011 17:08:11 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RXyUz-0005Uh-VA
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 17:08:10 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-2.tower-216.messagelabs.com!1323191243!7743701!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.5 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMjA5MTI=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMjA5MTI=\n,BODY_RANDOM_LONG
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30589 invoked from network); 6 Dec 2011 17:07:23 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-2.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Dec 2011 17:07:23 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1323191243; l=10363;
	s=domk; d=aepfle.de;
	h=To:From:Date:References:In-Reply-To:Subject:
	Content-Transfer-Encoding:MIME-Version:Content-Type:X-RZG-CLASS-ID:
	X-RZG-AUTH; bh=/8boVDxWUQL5mFuKZWt5Gbxd70Q=;
	b=ZpUS282V86ZGz3DiXkEDlwSqd9S2oVQEZiE1G1rngeW5XgvWAGRFL2yeNbLVEDrqhBU
	+scuHX+nxGHbZOF+xXwvKFOkxQUEold4isUh2IS79U385BkdJwjbjGZN0d6n9ck0xwdaI
	Hz7QO3x6kV3wbCiPAzEBe/cw4wuo+tnlJNc=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lq387qFz2T
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-076-151.pools.arcor-ip.net [84.57.76.151])
	by smtp.strato.de (jimi mo49) (RZmta 26.10 AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id Y050f7nB6FcAE0
	for <xen-devel@lists.xensource.com>;
	Tue, 6 Dec 2011 18:07:04 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 7B06318639
	for <xen-devel@lists.xensource.com>;
	Tue,  6 Dec 2011 18:07:03 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 7f2cfd9bd113c40a49cc7e036fd07eb706a22f15
Message-Id: <7f2cfd9bd113c40a49cc.1323191224@probook.site>
In-Reply-To: <patchbomb.1323191221@probook.site>
References: <patchbomb.1323191221@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Tue, 06 Dec 2011 18:07:04 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 3 of 5] xenpaging: add need_populate and
	paged_no_mfn checks
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1323189148 -3600
# Node ID 7f2cfd9bd113c40a49cc7e036fd07eb706a22f15
# Parent  96d3292797d861592a7d2d3840f371ec719775a9
xenpaging: add need_populate and paged_no_mfn checks

There is currently a mix of p2mt checks for the various paging types.
Some mean the p2mt needs to be populated, others mean a gfn without mfn.

Add a new p2m_do_populate() helper which covers the p2m_ram_paged and
p2m_ram_paging_out types. If a gfn is not in these states anymore another
populate request for the pager is not needed. This avoids a call to
p2m_mem_paging_populate() which in turn reduces the pressure on the ring
buffer because no temporary slot needs to be claimed. As such, this helper is
an optimization.

Modify the existing p2m_is_paged() helper which now covers also
p2m_ram_paging_in_start in addition to the current p2m_ram_paged type.  A gfn
in these two states is not backed by a mfn.

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 96d3292797d8 -r 7f2cfd9bd113 xen/arch/x86/hvm/emulate.c
--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -67,7 +67,8 @@ static int hvmemul_do_io(
     ram_mfn = get_gfn_unshare(curr->domain, ram_gfn, &p2mt);
     if ( p2m_is_paging(p2mt) )
     {
-        p2m_mem_paging_populate(curr->domain, ram_gfn);
+        if ( p2m_do_populate(p2mt) )
+            p2m_mem_paging_populate(curr->domain, ram_gfn);
         put_gfn(curr->domain, ram_gfn); 
         return X86EMUL_RETRY;
     }
diff -r 96d3292797d8 -r 7f2cfd9bd113 xen/arch/x86/hvm/hvm.c
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -363,7 +363,8 @@ static int hvm_set_ioreq_page(
     }
     if ( p2m_is_paging(p2mt) )
     {
-        p2m_mem_paging_populate(d, gmfn);
+        if ( p2m_do_populate(p2mt) )
+            p2m_mem_paging_populate(d, gmfn);
         put_gfn(d, gmfn);
         return -ENOENT;
     }
@@ -1298,7 +1299,7 @@ int hvm_hap_nested_page_fault(unsigned l
 
 #ifdef __x86_64__
     /* Check if the page has been paged out */
-    if ( p2m_is_paged(p2mt) || (p2mt == p2m_ram_paging_out) )
+    if ( p2m_do_populate(p2mt) )
         p2m_mem_paging_populate(v->domain, gfn);
 
     /* Mem sharing: unshare the page and try again */
@@ -1844,7 +1845,8 @@ static void *__hvm_map_guest_frame(unsig
     }
     if ( p2m_is_paging(p2mt) )
     {
-        p2m_mem_paging_populate(d, gfn);
+        if ( p2m_do_populate(p2mt) )
+            p2m_mem_paging_populate(d, gfn);
         put_gfn(d, gfn);
         return NULL;
     }
@@ -2320,7 +2322,8 @@ static enum hvm_copy_result __hvm_copy(
 
         if ( p2m_is_paging(p2mt) )
         {
-            p2m_mem_paging_populate(curr->domain, gfn);
+            if ( p2m_do_populate(p2mt) )
+                p2m_mem_paging_populate(curr->domain, gfn);
             put_gfn(curr->domain, gfn);
             return HVMCOPY_gfn_paged_out;
         }
@@ -3808,7 +3811,8 @@ long do_hvm_op(unsigned long op, XEN_GUE
             mfn_t mfn = get_gfn_unshare(d, pfn, &t);
             if ( p2m_is_paging(t) )
             {
-                p2m_mem_paging_populate(d, pfn);
+                if ( p2m_do_populate(t) )
+                    p2m_mem_paging_populate(d, pfn);
                 put_gfn(d, pfn);
                 rc = -EINVAL;
                 goto param_fail3;
@@ -3912,7 +3916,8 @@ long do_hvm_op(unsigned long op, XEN_GUE
             mfn = get_gfn_unshare(d, pfn, &t);
             if ( p2m_is_paging(t) )
             {
-                p2m_mem_paging_populate(d, pfn);
+                if ( p2m_do_populate(t) )
+                    p2m_mem_paging_populate(d, pfn);
                 put_gfn(d, pfn);
                 rc = -EINVAL;
                 goto param_fail4;
diff -r 96d3292797d8 -r 7f2cfd9bd113 xen/arch/x86/mm.c
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -3528,9 +3528,10 @@ int do_mmu_update(
             if ( !p2m_is_valid(p2mt) )
                 mfn = INVALID_MFN;
 
-            if ( p2m_is_paged(p2mt) )
+            if ( p2m_is_paging(p2mt) )
             {
-                p2m_mem_paging_populate(pg_owner, gmfn);
+                if ( p2m_is_paged(p2mt) )
+                    p2m_mem_paging_populate(pg_owner, gmfn);
                 put_gfn(pt_owner, gmfn);
                 rc = -ENOENT;
                 break;
@@ -3560,21 +3561,15 @@ int do_mmu_update(
     
                     l1emfn = mfn_x(get_gfn(pg_owner, l1egfn, &l1e_p2mt));
 
-                    if ( p2m_is_paged(l1e_p2mt) )
+#ifdef __x86_64__
+                    if ( p2m_is_paging(l1e_p2mt) )
                     {
-                        p2m_mem_paging_populate(pg_owner, l1e_get_pfn(l1e));
+                        if ( p2m_is_paged(l1e_p2mt) )
+                            p2m_mem_paging_populate(pg_owner, l1e_get_pfn(l1e));
                         put_gfn(pg_owner, l1egfn);
                         rc = -ENOENT;
                         break;
                     }
-                    else if ( p2m_ram_paging_in_start == l1e_p2mt && 
-                                !mfn_valid(l1emfn) )
-                    {
-                        put_gfn(pg_owner, l1egfn);
-                        rc = -ENOENT;
-                        break;
-                    }
-#ifdef __x86_64__
                     /* XXX: Ugly: pull all the checks into a separate function. 
                      * Don't want to do it now, not to interfere with mem_paging
                      * patches */
@@ -3609,16 +3604,10 @@ int do_mmu_update(
 
                     l2emfn = mfn_x(get_gfn(pg_owner, l2egfn, &l2e_p2mt));
 
-                    if ( p2m_is_paged(l2e_p2mt) )
+                    if ( p2m_is_paging(l2e_p2mt) )
                     {
-                        p2m_mem_paging_populate(pg_owner, l2egfn);
-                        put_gfn(pg_owner, l2egfn);
-                        rc = -ENOENT;
-                        break;
-                    }
-                    else if ( p2m_ram_paging_in_start == l2e_p2mt && 
-                                !mfn_valid(l2emfn) )
-                    {
+                        if ( p2m_is_paged(l2e_p2mt) )
+                            p2m_mem_paging_populate(pg_owner, l2egfn);
                         put_gfn(pg_owner, l2egfn);
                         rc = -ENOENT;
                         break;
@@ -3644,16 +3633,10 @@ int do_mmu_update(
 
                     l3emfn = mfn_x(get_gfn(pg_owner, l3egfn, &l3e_p2mt));
 
-                    if ( p2m_is_paged(l3e_p2mt) )
+                    if ( p2m_is_paging(l3e_p2mt) )
                     {
-                        p2m_mem_paging_populate(pg_owner, l3egfn);
-                        put_gfn(pg_owner, l3egfn);
-                        rc = -ENOENT;
-                        break;
-                    }
-                    else if ( p2m_ram_paging_in_start == l3e_p2mt && 
-                                !mfn_valid(l3emfn) )
-                    {
+                        if ( p2m_is_paged(l3e_p2mt) )
+                            p2m_mem_paging_populate(pg_owner, l3egfn);
                         put_gfn(pg_owner, l3egfn);
                         rc = -ENOENT;
                         break;
@@ -3679,16 +3662,10 @@ int do_mmu_update(
 
                     l4emfn = mfn_x(get_gfn(pg_owner, l4egfn, &l4e_p2mt));
 
-                    if ( p2m_is_paged(l4e_p2mt) )
+                    if ( p2m_is_paging(l4e_p2mt) )
                     {
-                        p2m_mem_paging_populate(pg_owner, l4egfn);
-                        put_gfn(pg_owner, l4egfn);
-                        rc = -ENOENT;
-                        break;
-                    }
-                    else if ( p2m_ram_paging_in_start == l4e_p2mt && 
-                                !mfn_valid(l4emfn) )
-                    {
+                        if ( p2m_is_paged(l4e_p2mt) )
+                            p2m_mem_paging_populate(pg_owner, l4egfn);
                         put_gfn(pg_owner, l4egfn);
                         rc = -ENOENT;
                         break;
diff -r 96d3292797d8 -r 7f2cfd9bd113 xen/arch/x86/mm/guest_walk.c
--- a/xen/arch/x86/mm/guest_walk.c
+++ b/xen/arch/x86/mm/guest_walk.c
@@ -102,7 +102,8 @@ static inline void *map_domain_gfn(struc
     if ( p2m_is_paging(*p2mt) )
     {
         ASSERT(!p2m_is_nestedp2m(p2m));
-        p2m_mem_paging_populate(p2m->domain, gfn_x(gfn));
+        if ( p2m_do_populate(*p2mt) )
+            p2m_mem_paging_populate(p2m->domain, gfn_x(gfn));
         __put_gfn(p2m, gfn_x(gfn));
         *rc = _PAGE_PAGED;
         return NULL;
diff -r 96d3292797d8 -r 7f2cfd9bd113 xen/arch/x86/mm/hap/guest_walk.c
--- a/xen/arch/x86/mm/hap/guest_walk.c
+++ b/xen/arch/x86/mm/hap/guest_walk.c
@@ -64,7 +64,8 @@ unsigned long hap_p2m_ga_to_gfn(GUEST_PA
     if ( p2m_is_paging(p2mt) )
     {
         ASSERT(!p2m_is_nestedp2m(p2m));
-        p2m_mem_paging_populate(p2m->domain, cr3 >> PAGE_SHIFT);
+        if ( p2m_do_populate(p2mt) )
+            p2m_mem_paging_populate(p2m->domain, cr3 >> PAGE_SHIFT);
 
         pfec[0] = PFEC_page_paged;
         __put_gfn(p2m, top_gfn);
@@ -101,7 +102,8 @@ unsigned long hap_p2m_ga_to_gfn(GUEST_PA
         if ( p2m_is_paging(p2mt) )
         {
             ASSERT(!p2m_is_nestedp2m(p2m));
-            p2m_mem_paging_populate(p2m->domain, gfn_x(gfn));
+            if ( p2m_do_populate(p2mt) )
+                p2m_mem_paging_populate(p2m->domain, gfn_x(gfn));
 
             pfec[0] = PFEC_page_paged;
             __put_gfn(p2m, gfn_x(gfn));
diff -r 96d3292797d8 -r 7f2cfd9bd113 xen/arch/x86/mm/p2m-ept.c
--- a/xen/arch/x86/mm/p2m-ept.c
+++ b/xen/arch/x86/mm/p2m-ept.c
@@ -375,8 +375,7 @@ ept_set_entry(struct p2m_domain *p2m, un
          * Read-then-write is OK because we hold the p2m lock. */
         old_entry = *ept_entry;
 
-        if ( mfn_valid(mfn_x(mfn)) || direct_mmio || p2m_is_paged(p2mt) ||
-             (p2mt == p2m_ram_paging_in_start) )
+        if ( mfn_valid(mfn_x(mfn)) || direct_mmio || p2m_is_paged(p2mt) )
         {
             /* Construct the new entry, and then write it once */
             new_entry.emt = epte_get_entry_emt(p2m->domain, gfn, mfn, &ipat,
diff -r 96d3292797d8 -r 7f2cfd9bd113 xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -918,7 +918,7 @@ void p2m_mem_paging_populate(struct doma
     p2m_lock(p2m);
     mfn = p2m->get_entry(p2m, gfn, &p2mt, &a, p2m_query, NULL);
     /* Allow only nominated or evicted pages to enter page-in path */
-    if ( p2mt == p2m_ram_paging_out || p2mt == p2m_ram_paged )
+    if ( p2m_do_populate(p2mt) )
     {
         /* Evict will fail now, tag this request for pager */
         if ( p2mt == p2m_ram_paging_out )
@@ -935,7 +935,7 @@ void p2m_mem_paging_populate(struct doma
         req.flags |= MEM_EVENT_FLAG_VCPU_PAUSED;
     }
     /* No need to inform pager if the gfn is not in the page-out path */
-    else if ( p2mt != p2m_ram_paging_out && p2mt != p2m_ram_paged )
+    else if ( !p2m_do_populate(p2mt) )
     {
         /* gfn is already on its way back and vcpu is not paused */
         mem_event_put_req_producers(&d->mem_event->paging);
diff -r 96d3292797d8 -r 7f2cfd9bd113 xen/common/grant_table.c
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -163,7 +163,8 @@ static int __get_paged_frame(unsigned lo
         *frame = mfn_x(mfn);
         if ( p2m_is_paging(p2mt) )
         {
-            p2m_mem_paging_populate(rd, gfn);
+            if ( p2m_do_populate(p2mt) )
+                p2m_mem_paging_populate(rd, gfn);
             put_gfn(rd, gfn);
             rc = GNTST_eagain;
         }
diff -r 96d3292797d8 -r 7f2cfd9bd113 xen/include/asm-x86/p2m.h
--- a/xen/include/asm-x86/p2m.h
+++ b/xen/include/asm-x86/p2m.h
@@ -158,7 +158,11 @@ typedef enum {
                           | p2m_to_mask(p2m_ram_paging_in_start) \
                           | p2m_to_mask(p2m_ram_paging_in))
 
-#define P2M_PAGED_TYPES (p2m_to_mask(p2m_ram_paged))
+#define P2M_POPULATE_TYPES (p2m_to_mask(p2m_ram_paged) \
+                            | p2m_to_mask(p2m_ram_paging_out) )
+
+#define P2M_PAGED_NO_MFN_TYPES (p2m_to_mask(p2m_ram_paged) \
+                               | p2m_to_mask(p2m_ram_paging_in_start) )
 
 /* Shared types */
 /* XXX: Sharable types could include p2m_ram_ro too, but we would need to
@@ -184,7 +188,8 @@ typedef enum {
 #define p2m_has_emt(_t)  (p2m_to_mask(_t) & (P2M_RAM_TYPES | p2m_to_mask(p2m_mmio_direct)))
 #define p2m_is_pageable(_t) (p2m_to_mask(_t) & P2M_PAGEABLE_TYPES)
 #define p2m_is_paging(_t)   (p2m_to_mask(_t) & P2M_PAGING_TYPES)
-#define p2m_is_paged(_t)    (p2m_to_mask(_t) & P2M_PAGED_TYPES)
+#define p2m_is_paged(_t)    (p2m_to_mask(_t) & P2M_PAGED_NO_MFN_TYPES)
+#define p2m_do_populate(_t) (p2m_to_mask(_t) & P2M_POPULATE_TYPES)
 #define p2m_is_sharable(_t) (p2m_to_mask(_t) & P2M_SHARABLE_TYPES)
 #define p2m_is_shared(_t)   (p2m_to_mask(_t) & P2M_SHARED_TYPES)
 #define p2m_is_broken(_t)   (p2m_to_mask(_t) & P2M_BROKEN_TYPES)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 17:09:18 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 17: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.xensource.com>)
	id 1RXyUn-0005TM-A9; Tue, 06 Dec 2011 17:07:57 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RXyUl-0005SO-4G
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 17:07:55 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-10.tower-174.messagelabs.com!1323191228!4496014!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMjA5MTI=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMjA5MTI=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21802 invoked from network); 6 Dec 2011 17:07:08 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-10.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 6 Dec 2011 17:07:08 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1323191228; l=3327;
	s=domk; d=aepfle.de;
	h=To:From:Date:References:In-Reply-To:Subject:
	Content-Transfer-Encoding:MIME-Version:Content-Type:X-RZG-CLASS-ID:
	X-RZG-AUTH; bh=c8K5zo57rI+hvv0iTlepoIWXtvQ=;
	b=ERVoAn6wgQ74DYaw6F5zn86Fv8n0tFx0xcD3iFSh3znRal5COKIFVM8kNiGwnPiBSD2
	D2sKSqFjNweWgm6N0YhhoonJGQqwm+D+yBCYg4qUhC5JuArSCDxrqke7NSXlAFN4+aRos
	irggqKMTZtn7nQR3zEY9r1EVasx4rH+h4ec=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lq387qFz2T
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-076-151.pools.arcor-ip.net [84.57.76.151])
	by smtp.strato.de (jimi mo47) (RZmta 26.10 AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id K04fc0nB6EnkyE
	for <xen-devel@lists.xensource.com>;
	Tue, 6 Dec 2011 18:07:03 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 2C90618637
	for <xen-devel@lists.xensource.com>;
	Tue,  6 Dec 2011 18:07:03 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: b733498b351a8650b2d952aa56725f63d49c1889
Message-Id: <b733498b351a8650b2d9.1323191222@probook.site>
In-Reply-To: <patchbomb.1323191221@probook.site>
References: <patchbomb.1323191221@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Tue, 06 Dec 2011 18:07:02 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 1 of 5] xenpaging: extend xc_mem_paging_enable()
 to handle interface version
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1323189139 -3600
# Node ID b733498b351a8650b2d952aa56725f63d49c1889
# Parent  a4d7c27ec1f190ecbb9a909609f6ef0eca250c00
xenpaging: extend xc_mem_paging_enable() to handle interface version

Since upcoming patches will change the way how paging internally works,
add a new interface to xc_mem_paging_enable() to make sure the pager is
not out-of-date. This is similar to XEN_DOMCTL_INTERFACE_VERSION in
do_domctl() where the tools have to match the running hypervisor.

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r a4d7c27ec1f1 -r b733498b351a tools/libxc/xc_mem_paging.c
--- a/tools/libxc/xc_mem_paging.c
+++ b/tools/libxc/xc_mem_paging.c
@@ -25,12 +25,13 @@
 
 
 int xc_mem_paging_enable(xc_interface *xch, domid_t domain_id,
+                        unsigned long interface_age,
                         void *shared_page, void *ring_page)
 {
     return xc_mem_event_control(xch, domain_id,
                                 XEN_DOMCTL_MEM_EVENT_OP_PAGING_ENABLE,
                                 XEN_DOMCTL_MEM_EVENT_OP_PAGING,
-                                shared_page, ring_page, INVALID_MFN);
+                                shared_page, ring_page, interface_age);
 }
 
 int xc_mem_paging_disable(xc_interface *xch, domid_t domain_id)
diff -r a4d7c27ec1f1 -r b733498b351a tools/libxc/xenctrl.h
--- a/tools/libxc/xenctrl.h
+++ b/tools/libxc/xenctrl.h
@@ -1859,6 +1859,7 @@ int xc_mem_event_control(xc_interface *x
                           void *ring_page, unsigned long gfn);
 
 int xc_mem_paging_enable(xc_interface *xch, domid_t domain_id,
+                        unsigned long interface_age,
                         void *shared_page, void *ring_page);
 int xc_mem_paging_disable(xc_interface *xch, domid_t domain_id);
 int xc_mem_paging_nominate(xc_interface *xch, domid_t domain_id,
diff -r a4d7c27ec1f1 -r b733498b351a tools/xenpaging/xenpaging.c
--- a/tools/xenpaging/xenpaging.c
+++ b/tools/xenpaging/xenpaging.c
@@ -366,6 +366,7 @@ static xenpaging_t *xenpaging_init(int a
     
     /* Initialise Xen */
     rc = xc_mem_paging_enable(xch, paging->mem_event.domain_id,
+                             MEM_EVENT_PAGING_AGE,
                              paging->mem_event.shared_page,
                              paging->mem_event.ring_page);
     if ( rc != 0 )
@@ -380,6 +381,9 @@ static xenpaging_t *xenpaging_init(int a
             case EXDEV:
                 ERROR("xenpaging not supported in a PoD guest");
                 break;
+            case ENOEXEC:
+                ERROR("xenpaging version mismatch");
+                break;
             default:
                 PERROR("Error initialising shared page");
                 break;
diff -r a4d7c27ec1f1 -r b733498b351a xen/arch/x86/mm/mem_event.c
--- a/xen/arch/x86/mm/mem_event.c
+++ b/xen/arch/x86/mm/mem_event.c
@@ -287,6 +287,15 @@ int mem_event_domctl(struct domain *d, x
             if ( p2m->pod.entry_count )
                 break;
 
+            rc = -ENOEXEC;
+            /* Reject old pager */
+            if ( mec->gfn != MEM_EVENT_PAGING_AGE )
+	    {
+                gdprintk(XENLOG_INFO, "Expected paging age %lx, got %lx\n",
+                         MEM_EVENT_PAGING_AGE, mec->gfn);
+                break;
+	    }
+
             rc = mem_event_enable(d, mec, med);
         }
         break;
diff -r a4d7c27ec1f1 -r b733498b351a xen/include/public/mem_event.h
--- a/xen/include/public/mem_event.h
+++ b/xen/include/public/mem_event.h
@@ -49,6 +49,8 @@
 #define MEM_EVENT_REASON_INT3        5    /* int3 was hit: gla/gfn are RIP */
 #define MEM_EVENT_REASON_SINGLESTEP  6    /* single step was invoked: gla/gfn are RIP */
 
+#define MEM_EVENT_PAGING_AGE         1UL  /* Number distinguish the mem_paging <-> pager interface */
+
 typedef struct mem_event_shared_page {
     uint32_t port;
 } mem_event_shared_page_t;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 17:09:18 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 17: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.xensource.com>)
	id 1RXyUn-0005TM-A9; Tue, 06 Dec 2011 17:07:57 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RXyUl-0005SO-4G
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 17:07:55 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-10.tower-174.messagelabs.com!1323191228!4496014!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMjA5MTI=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMjA5MTI=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21802 invoked from network); 6 Dec 2011 17:07:08 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-10.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 6 Dec 2011 17:07:08 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1323191228; l=3327;
	s=domk; d=aepfle.de;
	h=To:From:Date:References:In-Reply-To:Subject:
	Content-Transfer-Encoding:MIME-Version:Content-Type:X-RZG-CLASS-ID:
	X-RZG-AUTH; bh=c8K5zo57rI+hvv0iTlepoIWXtvQ=;
	b=ERVoAn6wgQ74DYaw6F5zn86Fv8n0tFx0xcD3iFSh3znRal5COKIFVM8kNiGwnPiBSD2
	D2sKSqFjNweWgm6N0YhhoonJGQqwm+D+yBCYg4qUhC5JuArSCDxrqke7NSXlAFN4+aRos
	irggqKMTZtn7nQR3zEY9r1EVasx4rH+h4ec=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lq387qFz2T
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-076-151.pools.arcor-ip.net [84.57.76.151])
	by smtp.strato.de (jimi mo47) (RZmta 26.10 AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id K04fc0nB6EnkyE
	for <xen-devel@lists.xensource.com>;
	Tue, 6 Dec 2011 18:07:03 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 2C90618637
	for <xen-devel@lists.xensource.com>;
	Tue,  6 Dec 2011 18:07:03 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: b733498b351a8650b2d952aa56725f63d49c1889
Message-Id: <b733498b351a8650b2d9.1323191222@probook.site>
In-Reply-To: <patchbomb.1323191221@probook.site>
References: <patchbomb.1323191221@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Tue, 06 Dec 2011 18:07:02 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 1 of 5] xenpaging: extend xc_mem_paging_enable()
 to handle interface version
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1323189139 -3600
# Node ID b733498b351a8650b2d952aa56725f63d49c1889
# Parent  a4d7c27ec1f190ecbb9a909609f6ef0eca250c00
xenpaging: extend xc_mem_paging_enable() to handle interface version

Since upcoming patches will change the way how paging internally works,
add a new interface to xc_mem_paging_enable() to make sure the pager is
not out-of-date. This is similar to XEN_DOMCTL_INTERFACE_VERSION in
do_domctl() where the tools have to match the running hypervisor.

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r a4d7c27ec1f1 -r b733498b351a tools/libxc/xc_mem_paging.c
--- a/tools/libxc/xc_mem_paging.c
+++ b/tools/libxc/xc_mem_paging.c
@@ -25,12 +25,13 @@
 
 
 int xc_mem_paging_enable(xc_interface *xch, domid_t domain_id,
+                        unsigned long interface_age,
                         void *shared_page, void *ring_page)
 {
     return xc_mem_event_control(xch, domain_id,
                                 XEN_DOMCTL_MEM_EVENT_OP_PAGING_ENABLE,
                                 XEN_DOMCTL_MEM_EVENT_OP_PAGING,
-                                shared_page, ring_page, INVALID_MFN);
+                                shared_page, ring_page, interface_age);
 }
 
 int xc_mem_paging_disable(xc_interface *xch, domid_t domain_id)
diff -r a4d7c27ec1f1 -r b733498b351a tools/libxc/xenctrl.h
--- a/tools/libxc/xenctrl.h
+++ b/tools/libxc/xenctrl.h
@@ -1859,6 +1859,7 @@ int xc_mem_event_control(xc_interface *x
                           void *ring_page, unsigned long gfn);
 
 int xc_mem_paging_enable(xc_interface *xch, domid_t domain_id,
+                        unsigned long interface_age,
                         void *shared_page, void *ring_page);
 int xc_mem_paging_disable(xc_interface *xch, domid_t domain_id);
 int xc_mem_paging_nominate(xc_interface *xch, domid_t domain_id,
diff -r a4d7c27ec1f1 -r b733498b351a tools/xenpaging/xenpaging.c
--- a/tools/xenpaging/xenpaging.c
+++ b/tools/xenpaging/xenpaging.c
@@ -366,6 +366,7 @@ static xenpaging_t *xenpaging_init(int a
     
     /* Initialise Xen */
     rc = xc_mem_paging_enable(xch, paging->mem_event.domain_id,
+                             MEM_EVENT_PAGING_AGE,
                              paging->mem_event.shared_page,
                              paging->mem_event.ring_page);
     if ( rc != 0 )
@@ -380,6 +381,9 @@ static xenpaging_t *xenpaging_init(int a
             case EXDEV:
                 ERROR("xenpaging not supported in a PoD guest");
                 break;
+            case ENOEXEC:
+                ERROR("xenpaging version mismatch");
+                break;
             default:
                 PERROR("Error initialising shared page");
                 break;
diff -r a4d7c27ec1f1 -r b733498b351a xen/arch/x86/mm/mem_event.c
--- a/xen/arch/x86/mm/mem_event.c
+++ b/xen/arch/x86/mm/mem_event.c
@@ -287,6 +287,15 @@ int mem_event_domctl(struct domain *d, x
             if ( p2m->pod.entry_count )
                 break;
 
+            rc = -ENOEXEC;
+            /* Reject old pager */
+            if ( mec->gfn != MEM_EVENT_PAGING_AGE )
+	    {
+                gdprintk(XENLOG_INFO, "Expected paging age %lx, got %lx\n",
+                         MEM_EVENT_PAGING_AGE, mec->gfn);
+                break;
+	    }
+
             rc = mem_event_enable(d, mec, med);
         }
         break;
diff -r a4d7c27ec1f1 -r b733498b351a xen/include/public/mem_event.h
--- a/xen/include/public/mem_event.h
+++ b/xen/include/public/mem_event.h
@@ -49,6 +49,8 @@
 #define MEM_EVENT_REASON_INT3        5    /* int3 was hit: gla/gfn are RIP */
 #define MEM_EVENT_REASON_SINGLESTEP  6    /* single step was invoked: gla/gfn are RIP */
 
+#define MEM_EVENT_PAGING_AGE         1UL  /* Number distinguish the mem_paging <-> pager interface */
+
 typedef struct mem_event_shared_page {
     uint32_t port;
 } mem_event_shared_page_t;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 17:09:56 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 17:09:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXyUi-0005ST-AZ; Tue, 06 Dec 2011 17:07:52 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RXyUg-0005SK-B4
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 17:07:50 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-3.tower-27.messagelabs.com!1323191184!48768064!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMzU2Mjg=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMzU2Mjg=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19110 invoked from network); 6 Dec 2011 17:06:25 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-3.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Dec 2011 17:06:25 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1323191225; l=4058;
	s=domk; d=aepfle.de;
	h=To:From:Date:References:In-Reply-To:Subject:
	Content-Transfer-Encoding:MIME-Version:Content-Type:X-RZG-CLASS-ID:
	X-RZG-AUTH; bh=MQYUNLS2gjkuFXgWWJhvKGWic/0=;
	b=NqbtVclGUWTUsvKifOhToHAb9zAZZl7rd3nd01OsSxeZT9yOCzSjKJdYt4qXe5Naiux
	0Cc3FFvPnpWUdykqydFMujqTYKfyWvIOqc+vRixlkld0SSfIQAoLbJUs53TzNauHLgKrm
	+bPIbACddBRfohgcUMfWuvGXr/hQoqpG9gU=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lq387qFz2T
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-076-151.pools.arcor-ip.net [84.57.76.151])
	by smtp.strato.de (jimi mo31) (RZmta 26.10 AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id e04425nB6FbLyX
	for <xen-devel@lists.xensource.com>;
	Tue, 6 Dec 2011 18:07:04 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 592CA18638
	for <xen-devel@lists.xensource.com>;
	Tue,  6 Dec 2011 18:07:03 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 96d3292797d861592a7d2d3840f371ec719775a9
Message-Id: <96d3292797d861592a7d.1323191223@probook.site>
In-Reply-To: <patchbomb.1323191221@probook.site>
References: <patchbomb.1323191221@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Tue, 06 Dec 2011 18:07:03 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 2 of 5] xenpaging: map gfn before nomination
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1323189147 -3600
# Node ID 96d3292797d861592a7d2d3840f371ec719775a9
# Parent  b733498b351a8650b2d952aa56725f63d49c1889
xenpaging: map gfn before nomination

If the gfn is mapped before nomination, all special cases in do_mmu_update()
for paged gfns can be removed. If a gfn is actually in any of the paging
states the caller has to try again.

Bump interface age.

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r b733498b351a -r 96d3292797d8 tools/xenpaging/xenpaging.c
--- a/tools/xenpaging/xenpaging.c
+++ b/tools/xenpaging/xenpaging.c
@@ -576,7 +576,7 @@ static int xenpaging_evict_page(xenpagin
 
     DECLARE_DOMCTL;
 
-    /* Map page */
+    /* Map page to get a handle */
     gfn = victim->gfn;
     ret = -EFAULT;
     page = xc_map_foreign_pages(xch, paging->mem_event.domain_id,
@@ -587,16 +587,21 @@ static int xenpaging_evict_page(xenpagin
         goto out;
     }
 
+    /* Nominate the page */
+    ret = xc_mem_paging_nominate(xch, paging->mem_event.domain_id, gfn);
+    if ( ret != 0 )
+        goto out;
+
     /* Copy page */
     ret = write_page(fd, page, i);
     if ( ret != 0 )
     {
         PERROR("Error copying page %lx", victim->gfn);
-        munmap(page, PAGE_SIZE);
         goto out;
     }
 
     munmap(page, PAGE_SIZE);
+    page = NULL;
 
     /* Tell Xen to evict page */
     ret = xc_mem_paging_evict(xch, paging->mem_event.domain_id,
@@ -615,6 +620,8 @@ static int xenpaging_evict_page(xenpagin
     paging->num_paged_out++;
 
  out:
+    if (page)
+        munmap(page, PAGE_SIZE);
     return ret;
 }
 
@@ -738,14 +745,11 @@ static int evict_victim(xenpaging_t *pag
             ret = -EINTR;
             goto out;
         }
-        ret = xc_mem_paging_nominate(xch, paging->mem_event.domain_id, victim->gfn);
-        if ( ret == 0 )
-            ret = xenpaging_evict_page(paging, victim, fd, i);
-        else
+        ret = xenpaging_evict_page(paging, victim, fd, i);
+        if ( ret && j++ % 1000 == 0 )
         {
-            if ( j++ % 1000 == 0 )
-                if ( xenpaging_mem_paging_flush_ioemu_cache(paging) )
-                    PERROR("Error flushing ioemu cache");
+            if ( xenpaging_mem_paging_flush_ioemu_cache(paging) )
+                PERROR("Error flushing ioemu cache");
         }
     }
     while ( ret );
diff -r b733498b351a -r 96d3292797d8 xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -723,7 +723,7 @@ set_shared_p2m_entry(struct domain *d, u
  * - the gfn is backed by a mfn
  * - the p2mt of the gfn is pageable
  * - the mfn is not used for IO
- * - the mfn has exactly one user and has no special meaning
+ * - the mfn has exactly two users (guest+pager) and has no special meaning
  *
  * Once the p2mt is changed the page is readonly for the guest.  On success the
  * pager can write the page contents to disk and later evict the page.
@@ -758,7 +758,7 @@ int p2m_mem_paging_nominate(struct domai
     /* Check page count and type */
     page = mfn_to_page(mfn);
     if ( (page->count_info & (PGC_count_mask | PGC_allocated)) !=
-         (1 | PGC_allocated) )
+         (2 | PGC_allocated) )
         goto out;
 
     if ( (page->u.inuse.type_info & PGT_type_mask) != PGT_none )
@@ -785,7 +785,7 @@ int p2m_mem_paging_nominate(struct domai
  * freed:
  * - the gfn is backed by a mfn
  * - the gfn was nominated
- * - the mfn has still exactly one user and has no special meaning
+ * - the mfn has still exactly one user (the guest) and has no special meaning
  *
  * After successful nomination some other process could have mapped the page. In
  * this case eviction can not be done. If the gfn was populated before the pager
diff -r b733498b351a -r 96d3292797d8 xen/include/public/mem_event.h
--- a/xen/include/public/mem_event.h
+++ b/xen/include/public/mem_event.h
@@ -49,7 +49,7 @@
 #define MEM_EVENT_REASON_INT3        5    /* int3 was hit: gla/gfn are RIP */
 #define MEM_EVENT_REASON_SINGLESTEP  6    /* single step was invoked: gla/gfn are RIP */
 
-#define MEM_EVENT_PAGING_AGE         1UL  /* Number distinguish the mem_paging <-> pager interface */
+#define MEM_EVENT_PAGING_AGE         2UL  /* Number distinguish the mem_paging <-> pager interface */
 
 typedef struct mem_event_shared_page {
     uint32_t port;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 17:09:56 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 17:09:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXyUi-0005ST-AZ; Tue, 06 Dec 2011 17:07:52 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RXyUg-0005SK-B4
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 17:07:50 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-3.tower-27.messagelabs.com!1323191184!48768064!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMzU2Mjg=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMzU2Mjg=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19110 invoked from network); 6 Dec 2011 17:06:25 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-3.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Dec 2011 17:06:25 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1323191225; l=4058;
	s=domk; d=aepfle.de;
	h=To:From:Date:References:In-Reply-To:Subject:
	Content-Transfer-Encoding:MIME-Version:Content-Type:X-RZG-CLASS-ID:
	X-RZG-AUTH; bh=MQYUNLS2gjkuFXgWWJhvKGWic/0=;
	b=NqbtVclGUWTUsvKifOhToHAb9zAZZl7rd3nd01OsSxeZT9yOCzSjKJdYt4qXe5Naiux
	0Cc3FFvPnpWUdykqydFMujqTYKfyWvIOqc+vRixlkld0SSfIQAoLbJUs53TzNauHLgKrm
	+bPIbACddBRfohgcUMfWuvGXr/hQoqpG9gU=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lq387qFz2T
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-076-151.pools.arcor-ip.net [84.57.76.151])
	by smtp.strato.de (jimi mo31) (RZmta 26.10 AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id e04425nB6FbLyX
	for <xen-devel@lists.xensource.com>;
	Tue, 6 Dec 2011 18:07:04 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 592CA18638
	for <xen-devel@lists.xensource.com>;
	Tue,  6 Dec 2011 18:07:03 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 96d3292797d861592a7d2d3840f371ec719775a9
Message-Id: <96d3292797d861592a7d.1323191223@probook.site>
In-Reply-To: <patchbomb.1323191221@probook.site>
References: <patchbomb.1323191221@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Tue, 06 Dec 2011 18:07:03 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 2 of 5] xenpaging: map gfn before nomination
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1323189147 -3600
# Node ID 96d3292797d861592a7d2d3840f371ec719775a9
# Parent  b733498b351a8650b2d952aa56725f63d49c1889
xenpaging: map gfn before nomination

If the gfn is mapped before nomination, all special cases in do_mmu_update()
for paged gfns can be removed. If a gfn is actually in any of the paging
states the caller has to try again.

Bump interface age.

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r b733498b351a -r 96d3292797d8 tools/xenpaging/xenpaging.c
--- a/tools/xenpaging/xenpaging.c
+++ b/tools/xenpaging/xenpaging.c
@@ -576,7 +576,7 @@ static int xenpaging_evict_page(xenpagin
 
     DECLARE_DOMCTL;
 
-    /* Map page */
+    /* Map page to get a handle */
     gfn = victim->gfn;
     ret = -EFAULT;
     page = xc_map_foreign_pages(xch, paging->mem_event.domain_id,
@@ -587,16 +587,21 @@ static int xenpaging_evict_page(xenpagin
         goto out;
     }
 
+    /* Nominate the page */
+    ret = xc_mem_paging_nominate(xch, paging->mem_event.domain_id, gfn);
+    if ( ret != 0 )
+        goto out;
+
     /* Copy page */
     ret = write_page(fd, page, i);
     if ( ret != 0 )
     {
         PERROR("Error copying page %lx", victim->gfn);
-        munmap(page, PAGE_SIZE);
         goto out;
     }
 
     munmap(page, PAGE_SIZE);
+    page = NULL;
 
     /* Tell Xen to evict page */
     ret = xc_mem_paging_evict(xch, paging->mem_event.domain_id,
@@ -615,6 +620,8 @@ static int xenpaging_evict_page(xenpagin
     paging->num_paged_out++;
 
  out:
+    if (page)
+        munmap(page, PAGE_SIZE);
     return ret;
 }
 
@@ -738,14 +745,11 @@ static int evict_victim(xenpaging_t *pag
             ret = -EINTR;
             goto out;
         }
-        ret = xc_mem_paging_nominate(xch, paging->mem_event.domain_id, victim->gfn);
-        if ( ret == 0 )
-            ret = xenpaging_evict_page(paging, victim, fd, i);
-        else
+        ret = xenpaging_evict_page(paging, victim, fd, i);
+        if ( ret && j++ % 1000 == 0 )
         {
-            if ( j++ % 1000 == 0 )
-                if ( xenpaging_mem_paging_flush_ioemu_cache(paging) )
-                    PERROR("Error flushing ioemu cache");
+            if ( xenpaging_mem_paging_flush_ioemu_cache(paging) )
+                PERROR("Error flushing ioemu cache");
         }
     }
     while ( ret );
diff -r b733498b351a -r 96d3292797d8 xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -723,7 +723,7 @@ set_shared_p2m_entry(struct domain *d, u
  * - the gfn is backed by a mfn
  * - the p2mt of the gfn is pageable
  * - the mfn is not used for IO
- * - the mfn has exactly one user and has no special meaning
+ * - the mfn has exactly two users (guest+pager) and has no special meaning
  *
  * Once the p2mt is changed the page is readonly for the guest.  On success the
  * pager can write the page contents to disk and later evict the page.
@@ -758,7 +758,7 @@ int p2m_mem_paging_nominate(struct domai
     /* Check page count and type */
     page = mfn_to_page(mfn);
     if ( (page->count_info & (PGC_count_mask | PGC_allocated)) !=
-         (1 | PGC_allocated) )
+         (2 | PGC_allocated) )
         goto out;
 
     if ( (page->u.inuse.type_info & PGT_type_mask) != PGT_none )
@@ -785,7 +785,7 @@ int p2m_mem_paging_nominate(struct domai
  * freed:
  * - the gfn is backed by a mfn
  * - the gfn was nominated
- * - the mfn has still exactly one user and has no special meaning
+ * - the mfn has still exactly one user (the guest) and has no special meaning
  *
  * After successful nomination some other process could have mapped the page. In
  * this case eviction can not be done. If the gfn was populated before the pager
diff -r b733498b351a -r 96d3292797d8 xen/include/public/mem_event.h
--- a/xen/include/public/mem_event.h
+++ b/xen/include/public/mem_event.h
@@ -49,7 +49,7 @@
 #define MEM_EVENT_REASON_INT3        5    /* int3 was hit: gla/gfn are RIP */
 #define MEM_EVENT_REASON_SINGLESTEP  6    /* single step was invoked: gla/gfn are RIP */
 
-#define MEM_EVENT_PAGING_AGE         1UL  /* Number distinguish the mem_paging <-> pager interface */
+#define MEM_EVENT_PAGING_AGE         2UL  /* Number distinguish the mem_paging <-> pager interface */
 
 typedef struct mem_event_shared_page {
     uint32_t port;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 17:20:39 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 17:20:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXygZ-0006Xu-8i; Tue, 06 Dec 2011 17:20:07 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RXygX-0006Xp-Qg
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 17:20:06 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1323191928!45653821!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjM3Ng==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6753 invoked from network); 6 Dec 2011 17:18:48 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Dec 2011 17:18:48 -0000
X-IronPort-AV: E=Sophos;i="4.71,307,1320624000"; 
   d="scan'208";a="9327204"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Dec 2011 17:19:24 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 6 Dec 2011 17:19:24 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RXyfs-0003Jz-6e;
	Tue, 06 Dec 2011 17:19:24 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RXyfs-0005so-6I;
	Tue, 06 Dec 2011 17:19:24 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10370-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 6 Dec 2011 17:19:24 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing test] 10370: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10370 xen-4.1-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10370/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-i386-xend-winxpsp3  7 windows-install              fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install          fail never pass
 test-i386-i386-xl-winxpsp3    7 windows-install              fail   never pass
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   never pass
 test-amd64-amd64-xl-win7-amd64  7 windows-install              fail never pass
 test-amd64-i386-xl-win7-amd64  7 windows-install              fail  never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  d9f8316a8291
baseline version:
 xen                  c613d436ca09

------------------------------------------------------------
People who touched revisions under test:
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Andrew Cooper <andrew.cooper3@citrix.com>
  Jan Beulich <jbeulich@novell.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Keir Fraser <keir@xen.org>
  Paul Durrant <paul.durrant@citrix.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-4.1-testing
+ revision=d9f8316a8291
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-4.1-testing d9f8316a8291
+ branch=xen-4.1-testing
+ revision=d9f8316a8291
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ : xen@xenbits.xensource.com
+ : xen@xenbits.xensource.com:git/linux-pvops
+ : master
+ : tested/2.6.39.x
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-4.1-testing.hg
+ hg push -r d9f8316a8291 ssh://xen@xenbits.xensource.com/HG/xen-4.1-testing.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-4.1-testing.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 4 changesets with 7 changes to 7 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 17:20:39 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 17:20:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXygZ-0006Xu-8i; Tue, 06 Dec 2011 17:20:07 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RXygX-0006Xp-Qg
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 17:20:06 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1323191928!45653821!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjM3Ng==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6753 invoked from network); 6 Dec 2011 17:18:48 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Dec 2011 17:18:48 -0000
X-IronPort-AV: E=Sophos;i="4.71,307,1320624000"; 
   d="scan'208";a="9327204"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Dec 2011 17:19:24 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 6 Dec 2011 17:19:24 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RXyfs-0003Jz-6e;
	Tue, 06 Dec 2011 17:19:24 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RXyfs-0005so-6I;
	Tue, 06 Dec 2011 17:19:24 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10370-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 6 Dec 2011 17:19:24 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing test] 10370: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10370 xen-4.1-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10370/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-i386-xend-winxpsp3  7 windows-install              fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install          fail never pass
 test-i386-i386-xl-winxpsp3    7 windows-install              fail   never pass
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   never pass
 test-amd64-amd64-xl-win7-amd64  7 windows-install              fail never pass
 test-amd64-i386-xl-win7-amd64  7 windows-install              fail  never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  d9f8316a8291
baseline version:
 xen                  c613d436ca09

------------------------------------------------------------
People who touched revisions under test:
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Andrew Cooper <andrew.cooper3@citrix.com>
  Jan Beulich <jbeulich@novell.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Keir Fraser <keir@xen.org>
  Paul Durrant <paul.durrant@citrix.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-4.1-testing
+ revision=d9f8316a8291
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-4.1-testing d9f8316a8291
+ branch=xen-4.1-testing
+ revision=d9f8316a8291
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ : xen@xenbits.xensource.com
+ : xen@xenbits.xensource.com:git/linux-pvops
+ : master
+ : tested/2.6.39.x
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-4.1-testing.hg
+ hg push -r d9f8316a8291 ssh://xen@xenbits.xensource.com/HG/xen-4.1-testing.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-4.1-testing.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 4 changesets with 7 changes to 7 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 17:27:19 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 17:27:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXymy-0006po-4f; Tue, 06 Dec 2011 17:26:44 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jeremy@goop.org>) id 1RXymv-0006pj-Fk
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 17:26:41 +0000
X-Env-Sender: jeremy@goop.org
X-Msg-Ref: server-6.tower-182.messagelabs.com!1323192353!6135473!1
X-Originating-IP: [74.207.240.146]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21923 invoked from network); 6 Dec 2011 17:25:55 -0000
Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146)
	by server-6.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Dec 2011 17:25:55 -0000
Received: from saboo.goop.org (me30536d0.tmodns.net [208.54.5.227])
	(Authenticated sender: smtp-saboo)
	by claw.goop.org (Postfix) with ESMTPSA id B3B89934C;
	Tue,  6 Dec 2011 09:25:52 -0800 (PST)
Received: from saboo.goop.org (localhost [IPv6:::1])
	by saboo.goop.org (Postfix) with ESMTP id 1E0C320F56;
	Tue,  6 Dec 2011 09:25:51 -0800 (PST)
Message-ID: <4EDE4EC4.8070802@goop.org>
Date: Tue, 06 Dec 2011 09:20:04 -0800
From: Jeremy Fitzhardinge <jeremy@goop.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:8.0) Gecko/20111115 Thunderbird/8.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <4EDDF41E.8070200@oracle.com>
	<1323168999-4434-1-git-send-email-annie.li@oracle.com>
	<1323171726.23681.65.camel@zakaz.uk.xensource.com>
In-Reply-To: <1323171726.23681.65.camel@zakaz.uk.xensource.com>
X-Enigmail-Version: 1.3.3
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	"kurt.hackel@oracle.com" <kurt.hackel@oracle.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"annie.li@oracle.com" <annie.li@oracle.com>,
	Paul Durrant <Paul.Durrant@citrix.com>
Subject: Re: [Xen-devel] [PATCH 1/2] xen/granttable: Support sub-page grants
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 12/06/2011 03:42 AM, Ian Campbell wrote:
>> +{
>> +	int ref;
>> +
>> +	ref = get_free_entries(1);
>> +	if (unlikely(ref < 0))
>> +		return -ENOSPC;
>> +
>> +	gnttab_grant_foreign_access_ref_subpage_v2(ref, domid, frame, flags,
>> +						   page_off, length);
>> +
>> +	return ref;
>> +}
>> +EXPORT_SYMBOL_GPL(gnttab_grant_foreign_access_subpage_v2);
>> +
>> +void gnttab_grant_foreign_access_ref_subpage_v2(grant_ref_t ref, domid_t domid,
>> +						unsigned long frame, int flags,
>> +						unsigned page_off,
>> +						unsigned length)
>> +{
>> +	BUG_ON(flags & (GTF_accept_transfer | GTF_reading |
>> +			GTF_writing | GTF_transitive));
>> +	BUG_ON(grant_table_version == 1);
> Returning -Esomething might be less drastic? ENOSYS perhaps?

Yeah, BUG_ON shouldn't be used for API misuse unless there's absolutely
no other way to handle it.

>
>> +	gnttab_shared.v2[ref].sub_page.frame = frame;
>> +	gnttab_shared.v2[ref].sub_page.page_off = page_off;
>> +	gnttab_shared.v2[ref].sub_page.length = length;
>> +	gnttab_shared.v2[ref].hdr.domid = domid;
>> +	wmb();
>> +	gnttab_shared.v2[ref].hdr.flags =
>> +				GTF_permit_access | GTF_sub_page | flags;
>> +}
>> +EXPORT_SYMBOL_GPL(gnttab_grant_foreign_access_ref_subpage_v2);
>> +
>> +bool gnttab_subpage_trans_grants_available(void)
>> +{
>> +	return grant_table_version == 2;
>> +}
> It's not clear this adds anything over and above letting the user query
> the grant table version. It's hard to tell since there are no users
> presented here though. Perhaps separate subpage and transitive functions
> would be cleaner?

Well, in general, specifically testing for features rather than
interface versions is better.

    J

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 17:27:19 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 17:27:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXymy-0006po-4f; Tue, 06 Dec 2011 17:26:44 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jeremy@goop.org>) id 1RXymv-0006pj-Fk
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 17:26:41 +0000
X-Env-Sender: jeremy@goop.org
X-Msg-Ref: server-6.tower-182.messagelabs.com!1323192353!6135473!1
X-Originating-IP: [74.207.240.146]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21923 invoked from network); 6 Dec 2011 17:25:55 -0000
Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146)
	by server-6.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Dec 2011 17:25:55 -0000
Received: from saboo.goop.org (me30536d0.tmodns.net [208.54.5.227])
	(Authenticated sender: smtp-saboo)
	by claw.goop.org (Postfix) with ESMTPSA id B3B89934C;
	Tue,  6 Dec 2011 09:25:52 -0800 (PST)
Received: from saboo.goop.org (localhost [IPv6:::1])
	by saboo.goop.org (Postfix) with ESMTP id 1E0C320F56;
	Tue,  6 Dec 2011 09:25:51 -0800 (PST)
Message-ID: <4EDE4EC4.8070802@goop.org>
Date: Tue, 06 Dec 2011 09:20:04 -0800
From: Jeremy Fitzhardinge <jeremy@goop.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:8.0) Gecko/20111115 Thunderbird/8.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <4EDDF41E.8070200@oracle.com>
	<1323168999-4434-1-git-send-email-annie.li@oracle.com>
	<1323171726.23681.65.camel@zakaz.uk.xensource.com>
In-Reply-To: <1323171726.23681.65.camel@zakaz.uk.xensource.com>
X-Enigmail-Version: 1.3.3
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	"kurt.hackel@oracle.com" <kurt.hackel@oracle.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"annie.li@oracle.com" <annie.li@oracle.com>,
	Paul Durrant <Paul.Durrant@citrix.com>
Subject: Re: [Xen-devel] [PATCH 1/2] xen/granttable: Support sub-page grants
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 12/06/2011 03:42 AM, Ian Campbell wrote:
>> +{
>> +	int ref;
>> +
>> +	ref = get_free_entries(1);
>> +	if (unlikely(ref < 0))
>> +		return -ENOSPC;
>> +
>> +	gnttab_grant_foreign_access_ref_subpage_v2(ref, domid, frame, flags,
>> +						   page_off, length);
>> +
>> +	return ref;
>> +}
>> +EXPORT_SYMBOL_GPL(gnttab_grant_foreign_access_subpage_v2);
>> +
>> +void gnttab_grant_foreign_access_ref_subpage_v2(grant_ref_t ref, domid_t domid,
>> +						unsigned long frame, int flags,
>> +						unsigned page_off,
>> +						unsigned length)
>> +{
>> +	BUG_ON(flags & (GTF_accept_transfer | GTF_reading |
>> +			GTF_writing | GTF_transitive));
>> +	BUG_ON(grant_table_version == 1);
> Returning -Esomething might be less drastic? ENOSYS perhaps?

Yeah, BUG_ON shouldn't be used for API misuse unless there's absolutely
no other way to handle it.

>
>> +	gnttab_shared.v2[ref].sub_page.frame = frame;
>> +	gnttab_shared.v2[ref].sub_page.page_off = page_off;
>> +	gnttab_shared.v2[ref].sub_page.length = length;
>> +	gnttab_shared.v2[ref].hdr.domid = domid;
>> +	wmb();
>> +	gnttab_shared.v2[ref].hdr.flags =
>> +				GTF_permit_access | GTF_sub_page | flags;
>> +}
>> +EXPORT_SYMBOL_GPL(gnttab_grant_foreign_access_ref_subpage_v2);
>> +
>> +bool gnttab_subpage_trans_grants_available(void)
>> +{
>> +	return grant_table_version == 2;
>> +}
> It's not clear this adds anything over and above letting the user query
> the grant table version. It's hard to tell since there are no users
> presented here though. Perhaps separate subpage and transitive functions
> would be cleaner?

Well, in general, specifically testing for features rather than
interface versions is better.

    J

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 17:28:56 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 17:28:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXyn7-0006qM-Id; Tue, 06 Dec 2011 17:26:53 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RXyn6-0006q2-Hq
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 17:26:52 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-11.tower-27.messagelabs.com!1323192350!48470573!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNDU4MDM=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNDU4MDM=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24878 invoked from network); 6 Dec 2011 17:25:51 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-11.tower-27.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 6 Dec 2011 17:25:51 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1323192367; l=1029;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=MwgH08v8AG423cM1HvLM2//yXLA=;
	b=PU8dVbzLwwoyGi8tz5u1MaI6kV+TArdo6/mDHvfBzasRmLHrQaqYrvCCKp2yz9ddM0E
	uQloq3GGSHN9n/fwPwmDNUgQ6a452B8J4gOCVFRgsc7LUypH+PimrgiPBMpCWfp5TkU5c
	V360cfRq1nk/KhNAItAg5mR8bMTtauTtDpo=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lq387qFz2T
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-076-151.pools.arcor-ip.net [84.57.76.151])
	by post.strato.de (mrclete mo9) (RZmta 26.10 AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id m037e0nB6Gp138 ;
	Tue, 6 Dec 2011 18:26:06 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 477BA18637; Tue,  6 Dec 2011 18:26:05 +0100 (CET)
Date: Tue, 6 Dec 2011 18:26:05 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20111206172605.GA18176@aepfle.de>
References: <patchbomb.1323098647@xdev.gridcentric.ca>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <patchbomb.1323098647@xdev.gridcentric.ca>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com, tim@xen.org,
	keir.xen@gmail.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 0 of 2] Mem event ring management overhaul
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Dec 05, Andres Lagar-Cavilla wrote:

> Ensure no guest events are ever lost in the mem event ring.
> 
> This is one of two outstanding proposals to solve this issue. One
> key difference between them being that ours does not necessitate wait 
> queues.
> 
> Instead, we rely on foreign domain retry (already in place), preempting
> hypercalls that may cause unbounded guest events (such as 
> decrease_reservation), and ensuring there is always space left in the 
> ring for each guest vcpu to place at least one event.

Thats not enough. Cases like hvm_copy and the emulator do currently no
retry, instead they get an invalid mfn and crash the guest. Its possible
to code around that in some places, like shown in the URL below, but
wouldnt it make sense to just stop execution until the expected
condition is met?
Its not clear to me how to properly handle a full ring in
get_gfn_type_access() with your proposal.

Olaf

http://old-list-archives.xen.org/archives/html/xen-devel/2011-01/msg01121.html

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 17:28:56 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 17:28:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXyn7-0006qM-Id; Tue, 06 Dec 2011 17:26:53 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RXyn6-0006q2-Hq
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 17:26:52 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-11.tower-27.messagelabs.com!1323192350!48470573!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNDU4MDM=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNDU4MDM=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24878 invoked from network); 6 Dec 2011 17:25:51 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-11.tower-27.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 6 Dec 2011 17:25:51 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1323192367; l=1029;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=MwgH08v8AG423cM1HvLM2//yXLA=;
	b=PU8dVbzLwwoyGi8tz5u1MaI6kV+TArdo6/mDHvfBzasRmLHrQaqYrvCCKp2yz9ddM0E
	uQloq3GGSHN9n/fwPwmDNUgQ6a452B8J4gOCVFRgsc7LUypH+PimrgiPBMpCWfp5TkU5c
	V360cfRq1nk/KhNAItAg5mR8bMTtauTtDpo=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lq387qFz2T
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-076-151.pools.arcor-ip.net [84.57.76.151])
	by post.strato.de (mrclete mo9) (RZmta 26.10 AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id m037e0nB6Gp138 ;
	Tue, 6 Dec 2011 18:26:06 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 477BA18637; Tue,  6 Dec 2011 18:26:05 +0100 (CET)
Date: Tue, 6 Dec 2011 18:26:05 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20111206172605.GA18176@aepfle.de>
References: <patchbomb.1323098647@xdev.gridcentric.ca>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <patchbomb.1323098647@xdev.gridcentric.ca>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com, tim@xen.org,
	keir.xen@gmail.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 0 of 2] Mem event ring management overhaul
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Dec 05, Andres Lagar-Cavilla wrote:

> Ensure no guest events are ever lost in the mem event ring.
> 
> This is one of two outstanding proposals to solve this issue. One
> key difference between them being that ours does not necessitate wait 
> queues.
> 
> Instead, we rely on foreign domain retry (already in place), preempting
> hypercalls that may cause unbounded guest events (such as 
> decrease_reservation), and ensuring there is always space left in the 
> ring for each guest vcpu to place at least one event.

Thats not enough. Cases like hvm_copy and the emulator do currently no
retry, instead they get an invalid mfn and crash the guest. Its possible
to code around that in some places, like shown in the URL below, but
wouldnt it make sense to just stop execution until the expected
condition is met?
Its not clear to me how to properly handle a full ring in
get_gfn_type_access() with your proposal.

Olaf

http://old-list-archives.xen.org/archives/html/xen-devel/2011-01/msg01121.html

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 17:44:34 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 17: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.xensource.com>)
	id 1RXz3u-0007EU-5v; Tue, 06 Dec 2011 17:44:14 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RXz3s-0007EP-KG
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 17:44:12 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-11.tower-216.messagelabs.com!1323193405!6344256!1
X-Originating-IP: [208.97.132.66]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi42NiA9PiAxNjA4Nw==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25995 invoked from network); 6 Dec 2011 17:43:26 -0000
Received: from caiajhbdcagg.dreamhost.com (HELO homiemail-a76.g.dreamhost.com)
	(208.97.132.66) by server-11.tower-216.messagelabs.com with SMTP;
	6 Dec 2011 17:43:26 -0000
Received: from homiemail-a76.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTP id DCE3E458083;
	Tue,  6 Dec 2011 09:43:24 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=QYRI9iR0EhtqazY0y+Vw7aOa11pmSaZMzgoUReDHspsc
	wqVOqJhKKhYZOPrPPWK8Eu6Pj7pvlICrOo6woQP+pQuQ2h3qWvBelJjZ5Y9+PCK9
	D0la6v+hOwDnMdHK2kCbpkMojrjDKQdtxGoi53Hv2W00EjiBRMJ0vhau5I8ooww=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=q0fGS4YNogg2m9oL2AJoOyLsEek=; b=XG1G7GUS
	rTwJ1MhWOGYZHyZvTbWcgpRk4Ar5mPxVr21t+n0NKBy5NDoLHK9j6xgkHTeP0ZTL
	oAEojqadEFqvfg2gmEAtt6eeMal18YsoCWhxr5y63svcuVmCbQHRfN6QkIczvLJS
	he63B1HwaaNl/pq9607L31goNl7J6Sra/mE=
Received: from webmail.lagarcavilla.org (ahfbbjcaiaae.dreamhost.com
	[75.119.208.4]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTPA id 71BC4458081; 
	Tue,  6 Dec 2011 09:43:24 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP; Tue, 6 Dec 2011 09:43:24 -0800
Message-ID: <d33d99829ec12990334e271eeb36b06c.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20111206172605.GA18176@aepfle.de>
References: <patchbomb.1323098647@xdev.gridcentric.ca>
	<20111206172605.GA18176@aepfle.de>
Date: Tue, 6 Dec 2011 09:43:24 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Olaf Hering" <olaf@aepfle.de>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com, tim@xen.org,
	keir.xen@gmail.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 0 of 2] Mem event ring management overhaul
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> On Mon, Dec 05, Andres Lagar-Cavilla wrote:
>
>> Ensure no guest events are ever lost in the mem event ring.
>>
>> This is one of two outstanding proposals to solve this issue. One
>> key difference between them being that ours does not necessitate wait
>> queues.
>>
>> Instead, we rely on foreign domain retry (already in place), preempting
>> hypercalls that may cause unbounded guest events (such as
>> decrease_reservation), and ensuring there is always space left in the
>> ring for each guest vcpu to place at least one event.
>
> Thats not enough. Cases like hvm_copy and the emulator do currently no
> retry, instead they get an invalid mfn and crash the guest. Its possible
> to code around that in some places, like shown in the URL below, but
> wouldnt it make sense to just stop execution until the expected
> condition is met?
These things are completely unrelated. *Foreign* domains retry. With our
patch, events caused by the guest itself are guaranteed to go in, no
retry.

The fact that hvm_copy et al. currently crash the guest is independent of
ring management. They crash the guest after placing the event in the ring.
And that's where the wait queues are expected to save the day.

> Its not clear to me how to properly handle a full ring in
> get_gfn_type_access() with your proposal.

If the request comes from a foreign domain, and there is no space in the
ring, ENOENT goes upwards.

If the request comes from the guest itself, and it's p2m_query, no event
needs to be generated.

If the request comes from the guest itself, and it requires
paging_populate (!= p2m_query), the event is guaranteed to be put in the
ring, and then the vcpu goes to sleep.

Easy-peasy
Andres
>
> Olaf
>
> http://old-list-archives.xen.org/archives/html/xen-devel/2011-01/msg01121.html
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 17:44:34 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 17: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.xensource.com>)
	id 1RXz3u-0007EU-5v; Tue, 06 Dec 2011 17:44:14 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RXz3s-0007EP-KG
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 17:44:12 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-11.tower-216.messagelabs.com!1323193405!6344256!1
X-Originating-IP: [208.97.132.66]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi42NiA9PiAxNjA4Nw==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25995 invoked from network); 6 Dec 2011 17:43:26 -0000
Received: from caiajhbdcagg.dreamhost.com (HELO homiemail-a76.g.dreamhost.com)
	(208.97.132.66) by server-11.tower-216.messagelabs.com with SMTP;
	6 Dec 2011 17:43:26 -0000
Received: from homiemail-a76.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTP id DCE3E458083;
	Tue,  6 Dec 2011 09:43:24 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=QYRI9iR0EhtqazY0y+Vw7aOa11pmSaZMzgoUReDHspsc
	wqVOqJhKKhYZOPrPPWK8Eu6Pj7pvlICrOo6woQP+pQuQ2h3qWvBelJjZ5Y9+PCK9
	D0la6v+hOwDnMdHK2kCbpkMojrjDKQdtxGoi53Hv2W00EjiBRMJ0vhau5I8ooww=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=q0fGS4YNogg2m9oL2AJoOyLsEek=; b=XG1G7GUS
	rTwJ1MhWOGYZHyZvTbWcgpRk4Ar5mPxVr21t+n0NKBy5NDoLHK9j6xgkHTeP0ZTL
	oAEojqadEFqvfg2gmEAtt6eeMal18YsoCWhxr5y63svcuVmCbQHRfN6QkIczvLJS
	he63B1HwaaNl/pq9607L31goNl7J6Sra/mE=
Received: from webmail.lagarcavilla.org (ahfbbjcaiaae.dreamhost.com
	[75.119.208.4]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTPA id 71BC4458081; 
	Tue,  6 Dec 2011 09:43:24 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP; Tue, 6 Dec 2011 09:43:24 -0800
Message-ID: <d33d99829ec12990334e271eeb36b06c.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20111206172605.GA18176@aepfle.de>
References: <patchbomb.1323098647@xdev.gridcentric.ca>
	<20111206172605.GA18176@aepfle.de>
Date: Tue, 6 Dec 2011 09:43:24 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Olaf Hering" <olaf@aepfle.de>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com, tim@xen.org,
	keir.xen@gmail.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 0 of 2] Mem event ring management overhaul
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> On Mon, Dec 05, Andres Lagar-Cavilla wrote:
>
>> Ensure no guest events are ever lost in the mem event ring.
>>
>> This is one of two outstanding proposals to solve this issue. One
>> key difference between them being that ours does not necessitate wait
>> queues.
>>
>> Instead, we rely on foreign domain retry (already in place), preempting
>> hypercalls that may cause unbounded guest events (such as
>> decrease_reservation), and ensuring there is always space left in the
>> ring for each guest vcpu to place at least one event.
>
> Thats not enough. Cases like hvm_copy and the emulator do currently no
> retry, instead they get an invalid mfn and crash the guest. Its possible
> to code around that in some places, like shown in the URL below, but
> wouldnt it make sense to just stop execution until the expected
> condition is met?
These things are completely unrelated. *Foreign* domains retry. With our
patch, events caused by the guest itself are guaranteed to go in, no
retry.

The fact that hvm_copy et al. currently crash the guest is independent of
ring management. They crash the guest after placing the event in the ring.
And that's where the wait queues are expected to save the day.

> Its not clear to me how to properly handle a full ring in
> get_gfn_type_access() with your proposal.

If the request comes from a foreign domain, and there is no space in the
ring, ENOENT goes upwards.

If the request comes from the guest itself, and it's p2m_query, no event
needs to be generated.

If the request comes from the guest itself, and it requires
paging_populate (!= p2m_query), the event is guaranteed to be put in the
ring, and then the vcpu goes to sleep.

Easy-peasy
Andres
>
> Olaf
>
> http://old-list-archives.xen.org/archives/html/xen-devel/2011-01/msg01121.html
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 18:15:03 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 18:15:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXzWr-0007Vi-NO; Tue, 06 Dec 2011 18:14:09 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RXzWo-0007Vd-VD
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 18:14:07 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-15.tower-21.messagelabs.com!1323195199!7172340!1
X-Originating-IP: [208.97.132.74]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi43NCA9PiAxNTc0Mw==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2033 invoked from network); 6 Dec 2011 18:13:20 -0000
Received: from caiajhbdcahe.dreamhost.com (HELO homiemail-a21.g.dreamhost.com)
	(208.97.132.74) by server-15.tower-21.messagelabs.com with SMTP;
	6 Dec 2011 18:13:20 -0000
Received: from homiemail-a21.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTP id 22F6D30007B;
	Tue,  6 Dec 2011 10:13:19 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=kXjH/0+fxxF4+E9vjOGbNIxmIF4czyPF7j3pmkOEKyDT
	kb0WPdQwhAd/FwqEvqHvj6BH8VWaWrqMqcDUmXgwPDg3vp02xF25WIe6TdnFmOyt
	5JPf4ogwfjW+czOxTCrmWWr0CGtJoertO6dY+JecYXPSWJd793FILYrByOJqS04=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=1IKPWw157LUlWlwNmAmswOW/QQA=; b=n0WbFYvt
	NqGho3RjbgVlnOo0vEwwXcMg3s7IBPJ1pHl9+fTLBGuFbgb53YMYpXuxBCLNHoOK
	1C3IkQYik+X03FfH+dGLV7JykEaOX0KXoOdT4ZWpFHBBHKXQHpPa2OwRyvw39M8K
	5U1LNLEsBk78wNp3uLwZ4DptkkAh2lp6v88=
Received: from webmail.lagarcavilla.org (ahfbbjcaiaae.dreamhost.com
	[75.119.208.4]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTPA id ACC1B30006C; 
	Tue,  6 Dec 2011 10:13:18 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP; Tue, 6 Dec 2011 10:13:19 -0800
Message-ID: <78bcef1bbb35c6176c138c1a6089f034.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <mailman.3467.1323191271.12970.xen-devel@lists.xensource.com>
References: <mailman.3467.1323191271.12970.xen-devel@lists.xensource.com>
Date: Tue, 6 Dec 2011 10:13:19 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: olaf@aepfle.de
Subject: Re: [Xen-devel] [PATCH 2 of 5] xenpaging: map gfn before nomination
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> Date: Tue, 06 Dec 2011 18:07:03 +0100
> From: Olaf Hering <olaf@aepfle.de>
> To: xen-devel@lists.xensource.com
> Subject: [Xen-devel] [PATCH 2 of 5] xenpaging: map gfn before
> 	nomination
> Message-ID: <96d3292797d861592a7d.1323191223@probook.site>
> Content-Type: text/plain; charset="us-ascii"
>
> # HG changeset patch
> # User Olaf Hering <olaf@aepfle.de>
> # Date 1323189147 -3600
> # Node ID 96d3292797d861592a7d2d3840f371ec719775a9
> # Parent  b733498b351a8650b2d952aa56725f63d49c1889
> xenpaging: map gfn before nomination
>
> If the gfn is mapped before nomination, all special cases in
> do_mmu_update()
> for paged gfns can be removed. If a gfn is actually in any of the paging
> states the caller has to try again.
>
> Bump interface age.

Ouch! You're absolutely tying the user space pager with the underlying xen
paging code. Most of your patches change the tools and the hypervisor in
lockstep.

These things are independent.

Let me clarify this: I'm working on a pager. I rely on the current
interface. I'm not opposed to changes that optimize the paging code in
Xen, but I am not in favor of changes that change the interface in a
rather gratuitous manner.

Patch 4 in your series is one such case. Short-cutting the state machine:
great. But what is the gain for the hypervisor in *not* sending the
EVICT_FAIL event. It's a good thing. It keeps the same interface to
user-space. Xenpaging may not need it, but the Xen paging code does not
exist solely for xenpaging.

Patch 5 also ties xenpaging and xen code together. I don't mind this
patch, but it should definitely be split in two.

Patch 1 is also a problem. I don't buy that we can number interfaces, and
then only support the tip ("Sorry, ENOEXEC, dig out an older hypervisor").
Either we bite the bullet of some level of backwards compatibility with
all its messiness, or we just keep it in flux until there is convergence
on a major "barrier".

Patch 3 makes a lot of sense.

This current patch 2 is also rather gratuitous. The need to map before
nominate feels superfluous. If Xen cannot deal with nomination requests on
pages that have not been mapped, then we've broken Xen.

Anyway, I hope my message gets across. I'm not trying to organize a
blockade on your code. I'm trying to get to the best possible hypervisor
paging support we can.

Thanks,
Andres

>
> Signed-off-by: Olaf Hering <olaf@aepfle.de>
>
> diff -r b733498b351a -r 96d3292797d8 tools/xenpaging/xenpaging.c
> --- a/tools/xenpaging/xenpaging.c
> +++ b/tools/xenpaging/xenpaging.c
> @@ -576,7 +576,7 @@ static int xenpaging_evict_page(xenpagin
>
>      DECLARE_DOMCTL;
>
> -    /* Map page */
> +    /* Map page to get a handle */
>      gfn = victim->gfn;
>      ret = -EFAULT;
>      page = xc_map_foreign_pages(xch, paging->mem_event.domain_id,
> @@ -587,16 +587,21 @@ static int xenpaging_evict_page(xenpagin
>          goto out;
>      }
>
> +    /* Nominate the page */
> +    ret = xc_mem_paging_nominate(xch, paging->mem_event.domain_id, gfn);
> +    if ( ret != 0 )
> +        goto out;
> +
>      /* Copy page */
>      ret = write_page(fd, page, i);
>      if ( ret != 0 )
>      {
>          PERROR("Error copying page %lx", victim->gfn);
> -        munmap(page, PAGE_SIZE);
>          goto out;
>      }
>
>      munmap(page, PAGE_SIZE);
> +    page = NULL;
>
>      /* Tell Xen to evict page */
>      ret = xc_mem_paging_evict(xch, paging->mem_event.domain_id,
> @@ -615,6 +620,8 @@ static int xenpaging_evict_page(xenpagin
>      paging->num_paged_out++;
>
>   out:
> +    if (page)
> +        munmap(page, PAGE_SIZE);
>      return ret;
>  }
>
> @@ -738,14 +745,11 @@ static int evict_victim(xenpaging_t *pag
>              ret = -EINTR;
>              goto out;
>          }
> -        ret = xc_mem_paging_nominate(xch, paging->mem_event.domain_id,
> victim->gfn);
> -        if ( ret == 0 )
> -            ret = xenpaging_evict_page(paging, victim, fd, i);
> -        else
> +        ret = xenpaging_evict_page(paging, victim, fd, i);
> +        if ( ret && j++ % 1000 == 0 )
>          {
> -            if ( j++ % 1000 == 0 )
> -                if ( xenpaging_mem_paging_flush_ioemu_cache(paging) )
> -                    PERROR("Error flushing ioemu cache");
> +            if ( xenpaging_mem_paging_flush_ioemu_cache(paging) )
> +                PERROR("Error flushing ioemu cache");
>          }
>      }
>      while ( ret );
> diff -r b733498b351a -r 96d3292797d8 xen/arch/x86/mm/p2m.c
> --- a/xen/arch/x86/mm/p2m.c
> +++ b/xen/arch/x86/mm/p2m.c
> @@ -723,7 +723,7 @@ set_shared_p2m_entry(struct domain *d, u
>   * - the gfn is backed by a mfn
>   * - the p2mt of the gfn is pageable
>   * - the mfn is not used for IO
> - * - the mfn has exactly one user and has no special meaning
> + * - the mfn has exactly two users (guest+pager) and has no special
> meaning
>   *
>   * Once the p2mt is changed the page is readonly for the guest.  On
> success the
>   * pager can write the page contents to disk and later evict the page.
> @@ -758,7 +758,7 @@ int p2m_mem_paging_nominate(struct domai
>      /* Check page count and type */
>      page = mfn_to_page(mfn);
>      if ( (page->count_info & (PGC_count_mask | PGC_allocated)) !=
> -         (1 | PGC_allocated) )
> +         (2 | PGC_allocated) )
>          goto out;
>
>      if ( (page->u.inuse.type_info & PGT_type_mask) != PGT_none )
> @@ -785,7 +785,7 @@ int p2m_mem_paging_nominate(struct domai
>   * freed:
>   * - the gfn is backed by a mfn
>   * - the gfn was nominated
> - * - the mfn has still exactly one user and has no special meaning
> + * - the mfn has still exactly one user (the guest) and has no special
> meaning
>   *
>   * After successful nomination some other process could have mapped the
> page. In
>   * this case eviction can not be done. If the gfn was populated before
> the pager
> diff -r b733498b351a -r 96d3292797d8 xen/include/public/mem_event.h
> --- a/xen/include/public/mem_event.h
> +++ b/xen/include/public/mem_event.h
> @@ -49,7 +49,7 @@
>  #define MEM_EVENT_REASON_INT3        5    /* int3 was hit: gla/gfn are
> RIP */
>  #define MEM_EVENT_REASON_SINGLESTEP  6    /* single step was invoked:
> gla/gfn are RIP */
>
> -#define MEM_EVENT_PAGING_AGE         1UL  /* Number distinguish the
> mem_paging <-> pager interface */
> +#define MEM_EVENT_PAGING_AGE         2UL  /* Number distinguish the
> mem_paging <-> pager interface */
>
>  typedef struct mem_event_shared_page {
>      uint32_t port;
>
>
>
> ------------------------------
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>
>
> End of Xen-devel Digest, Vol 82, Issue 93
> *****************************************
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 18:15:03 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 18:15:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXzWr-0007Vi-NO; Tue, 06 Dec 2011 18:14:09 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RXzWo-0007Vd-VD
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 18:14:07 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-15.tower-21.messagelabs.com!1323195199!7172340!1
X-Originating-IP: [208.97.132.74]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi43NCA9PiAxNTc0Mw==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2033 invoked from network); 6 Dec 2011 18:13:20 -0000
Received: from caiajhbdcahe.dreamhost.com (HELO homiemail-a21.g.dreamhost.com)
	(208.97.132.74) by server-15.tower-21.messagelabs.com with SMTP;
	6 Dec 2011 18:13:20 -0000
Received: from homiemail-a21.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTP id 22F6D30007B;
	Tue,  6 Dec 2011 10:13:19 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=kXjH/0+fxxF4+E9vjOGbNIxmIF4czyPF7j3pmkOEKyDT
	kb0WPdQwhAd/FwqEvqHvj6BH8VWaWrqMqcDUmXgwPDg3vp02xF25WIe6TdnFmOyt
	5JPf4ogwfjW+czOxTCrmWWr0CGtJoertO6dY+JecYXPSWJd793FILYrByOJqS04=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=1IKPWw157LUlWlwNmAmswOW/QQA=; b=n0WbFYvt
	NqGho3RjbgVlnOo0vEwwXcMg3s7IBPJ1pHl9+fTLBGuFbgb53YMYpXuxBCLNHoOK
	1C3IkQYik+X03FfH+dGLV7JykEaOX0KXoOdT4ZWpFHBBHKXQHpPa2OwRyvw39M8K
	5U1LNLEsBk78wNp3uLwZ4DptkkAh2lp6v88=
Received: from webmail.lagarcavilla.org (ahfbbjcaiaae.dreamhost.com
	[75.119.208.4]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTPA id ACC1B30006C; 
	Tue,  6 Dec 2011 10:13:18 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP; Tue, 6 Dec 2011 10:13:19 -0800
Message-ID: <78bcef1bbb35c6176c138c1a6089f034.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <mailman.3467.1323191271.12970.xen-devel@lists.xensource.com>
References: <mailman.3467.1323191271.12970.xen-devel@lists.xensource.com>
Date: Tue, 6 Dec 2011 10:13:19 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: olaf@aepfle.de
Subject: Re: [Xen-devel] [PATCH 2 of 5] xenpaging: map gfn before nomination
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> Date: Tue, 06 Dec 2011 18:07:03 +0100
> From: Olaf Hering <olaf@aepfle.de>
> To: xen-devel@lists.xensource.com
> Subject: [Xen-devel] [PATCH 2 of 5] xenpaging: map gfn before
> 	nomination
> Message-ID: <96d3292797d861592a7d.1323191223@probook.site>
> Content-Type: text/plain; charset="us-ascii"
>
> # HG changeset patch
> # User Olaf Hering <olaf@aepfle.de>
> # Date 1323189147 -3600
> # Node ID 96d3292797d861592a7d2d3840f371ec719775a9
> # Parent  b733498b351a8650b2d952aa56725f63d49c1889
> xenpaging: map gfn before nomination
>
> If the gfn is mapped before nomination, all special cases in
> do_mmu_update()
> for paged gfns can be removed. If a gfn is actually in any of the paging
> states the caller has to try again.
>
> Bump interface age.

Ouch! You're absolutely tying the user space pager with the underlying xen
paging code. Most of your patches change the tools and the hypervisor in
lockstep.

These things are independent.

Let me clarify this: I'm working on a pager. I rely on the current
interface. I'm not opposed to changes that optimize the paging code in
Xen, but I am not in favor of changes that change the interface in a
rather gratuitous manner.

Patch 4 in your series is one such case. Short-cutting the state machine:
great. But what is the gain for the hypervisor in *not* sending the
EVICT_FAIL event. It's a good thing. It keeps the same interface to
user-space. Xenpaging may not need it, but the Xen paging code does not
exist solely for xenpaging.

Patch 5 also ties xenpaging and xen code together. I don't mind this
patch, but it should definitely be split in two.

Patch 1 is also a problem. I don't buy that we can number interfaces, and
then only support the tip ("Sorry, ENOEXEC, dig out an older hypervisor").
Either we bite the bullet of some level of backwards compatibility with
all its messiness, or we just keep it in flux until there is convergence
on a major "barrier".

Patch 3 makes a lot of sense.

This current patch 2 is also rather gratuitous. The need to map before
nominate feels superfluous. If Xen cannot deal with nomination requests on
pages that have not been mapped, then we've broken Xen.

Anyway, I hope my message gets across. I'm not trying to organize a
blockade on your code. I'm trying to get to the best possible hypervisor
paging support we can.

Thanks,
Andres

>
> Signed-off-by: Olaf Hering <olaf@aepfle.de>
>
> diff -r b733498b351a -r 96d3292797d8 tools/xenpaging/xenpaging.c
> --- a/tools/xenpaging/xenpaging.c
> +++ b/tools/xenpaging/xenpaging.c
> @@ -576,7 +576,7 @@ static int xenpaging_evict_page(xenpagin
>
>      DECLARE_DOMCTL;
>
> -    /* Map page */
> +    /* Map page to get a handle */
>      gfn = victim->gfn;
>      ret = -EFAULT;
>      page = xc_map_foreign_pages(xch, paging->mem_event.domain_id,
> @@ -587,16 +587,21 @@ static int xenpaging_evict_page(xenpagin
>          goto out;
>      }
>
> +    /* Nominate the page */
> +    ret = xc_mem_paging_nominate(xch, paging->mem_event.domain_id, gfn);
> +    if ( ret != 0 )
> +        goto out;
> +
>      /* Copy page */
>      ret = write_page(fd, page, i);
>      if ( ret != 0 )
>      {
>          PERROR("Error copying page %lx", victim->gfn);
> -        munmap(page, PAGE_SIZE);
>          goto out;
>      }
>
>      munmap(page, PAGE_SIZE);
> +    page = NULL;
>
>      /* Tell Xen to evict page */
>      ret = xc_mem_paging_evict(xch, paging->mem_event.domain_id,
> @@ -615,6 +620,8 @@ static int xenpaging_evict_page(xenpagin
>      paging->num_paged_out++;
>
>   out:
> +    if (page)
> +        munmap(page, PAGE_SIZE);
>      return ret;
>  }
>
> @@ -738,14 +745,11 @@ static int evict_victim(xenpaging_t *pag
>              ret = -EINTR;
>              goto out;
>          }
> -        ret = xc_mem_paging_nominate(xch, paging->mem_event.domain_id,
> victim->gfn);
> -        if ( ret == 0 )
> -            ret = xenpaging_evict_page(paging, victim, fd, i);
> -        else
> +        ret = xenpaging_evict_page(paging, victim, fd, i);
> +        if ( ret && j++ % 1000 == 0 )
>          {
> -            if ( j++ % 1000 == 0 )
> -                if ( xenpaging_mem_paging_flush_ioemu_cache(paging) )
> -                    PERROR("Error flushing ioemu cache");
> +            if ( xenpaging_mem_paging_flush_ioemu_cache(paging) )
> +                PERROR("Error flushing ioemu cache");
>          }
>      }
>      while ( ret );
> diff -r b733498b351a -r 96d3292797d8 xen/arch/x86/mm/p2m.c
> --- a/xen/arch/x86/mm/p2m.c
> +++ b/xen/arch/x86/mm/p2m.c
> @@ -723,7 +723,7 @@ set_shared_p2m_entry(struct domain *d, u
>   * - the gfn is backed by a mfn
>   * - the p2mt of the gfn is pageable
>   * - the mfn is not used for IO
> - * - the mfn has exactly one user and has no special meaning
> + * - the mfn has exactly two users (guest+pager) and has no special
> meaning
>   *
>   * Once the p2mt is changed the page is readonly for the guest.  On
> success the
>   * pager can write the page contents to disk and later evict the page.
> @@ -758,7 +758,7 @@ int p2m_mem_paging_nominate(struct domai
>      /* Check page count and type */
>      page = mfn_to_page(mfn);
>      if ( (page->count_info & (PGC_count_mask | PGC_allocated)) !=
> -         (1 | PGC_allocated) )
> +         (2 | PGC_allocated) )
>          goto out;
>
>      if ( (page->u.inuse.type_info & PGT_type_mask) != PGT_none )
> @@ -785,7 +785,7 @@ int p2m_mem_paging_nominate(struct domai
>   * freed:
>   * - the gfn is backed by a mfn
>   * - the gfn was nominated
> - * - the mfn has still exactly one user and has no special meaning
> + * - the mfn has still exactly one user (the guest) and has no special
> meaning
>   *
>   * After successful nomination some other process could have mapped the
> page. In
>   * this case eviction can not be done. If the gfn was populated before
> the pager
> diff -r b733498b351a -r 96d3292797d8 xen/include/public/mem_event.h
> --- a/xen/include/public/mem_event.h
> +++ b/xen/include/public/mem_event.h
> @@ -49,7 +49,7 @@
>  #define MEM_EVENT_REASON_INT3        5    /* int3 was hit: gla/gfn are
> RIP */
>  #define MEM_EVENT_REASON_SINGLESTEP  6    /* single step was invoked:
> gla/gfn are RIP */
>
> -#define MEM_EVENT_PAGING_AGE         1UL  /* Number distinguish the
> mem_paging <-> pager interface */
> +#define MEM_EVENT_PAGING_AGE         2UL  /* Number distinguish the
> mem_paging <-> pager interface */
>
>  typedef struct mem_event_shared_page {
>      uint32_t port;
>
>
>
> ------------------------------
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>
>
> End of Xen-devel Digest, Vol 82, Issue 93
> *****************************************
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 18:16:33 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 18: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.xensource.com>)
	id 1RXzYM-0007aU-Dr; Tue, 06 Dec 2011 18:15:42 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <davem@davemloft.net>) id 1RXzYL-0007aA-Ge
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 18:15:41 +0000
X-Env-Sender: davem@davemloft.net
X-Msg-Ref: server-16.tower-21.messagelabs.com!1323195293!481992!1
X-Originating-IP: [198.137.202.13]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25203 invoked from network); 6 Dec 2011 18:14:55 -0000
Received: from shards.monkeyblade.net (HELO shards.monkeyblade.net)
	(198.137.202.13)
	by server-16.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Dec 2011 18:14:55 -0000
Received: from localhost (nat-pool-rdu.redhat.com [66.187.233.202])
	(authenticated bits=0)
	by shards.monkeyblade.net (8.14.4/8.14.4) with ESMTP id pB6IEnSw012856
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO);
	Tue, 6 Dec 2011 10:14:50 -0800
Date: Tue, 06 Dec 2011 13:14:49 -0500 (EST)
Message-Id: <20111206.131449.1351676944529284449.davem@davemloft.net>
To: Ian.Campbell@citrix.com
From: David Miller <davem@davemloft.net>
In-Reply-To: <1323166882.23681.46.camel@zakaz.uk.xensource.com>
References: <1323166100-7059-1-git-send-email-wei.liu2@citrix.com>
	<1323166882.23681.46.camel@zakaz.uk.xensource.com>
X-Mailer: Mew version 6.4 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6
	(shards.monkeyblade.net [198.137.202.13]);
	Tue, 06 Dec 2011 10:14:51 -0800 (PST)
Cc: netdev@vger.kernel.org, xen-devel@lists.xensource.com, wei.liu2@citrix.com
Subject: Re: [Xen-devel] [PATCH] netback: remove redundant assignment
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Ian Campbell <Ian.Campbell@citrix.com>
Date: Tue, 6 Dec 2011 10:21:22 +0000

> On Tue, 2011-12-06 at 10:08 +0000, Wei Liu wrote:
>> New value for netbk->mmap_pages[pending_idx] is assigned in
>> xen_netbk_alloc_page(), no need for a second assignment which
>> exposes internal to the outside world.
>> 
>> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> Acked-by: Ian Campbell <ian.campbell@citrix.com>

Applied to net-next, thanks.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 18:16:33 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 18: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.xensource.com>)
	id 1RXzYM-0007aU-Dr; Tue, 06 Dec 2011 18:15:42 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <davem@davemloft.net>) id 1RXzYL-0007aA-Ge
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 18:15:41 +0000
X-Env-Sender: davem@davemloft.net
X-Msg-Ref: server-16.tower-21.messagelabs.com!1323195293!481992!1
X-Originating-IP: [198.137.202.13]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25203 invoked from network); 6 Dec 2011 18:14:55 -0000
Received: from shards.monkeyblade.net (HELO shards.monkeyblade.net)
	(198.137.202.13)
	by server-16.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Dec 2011 18:14:55 -0000
Received: from localhost (nat-pool-rdu.redhat.com [66.187.233.202])
	(authenticated bits=0)
	by shards.monkeyblade.net (8.14.4/8.14.4) with ESMTP id pB6IEnSw012856
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO);
	Tue, 6 Dec 2011 10:14:50 -0800
Date: Tue, 06 Dec 2011 13:14:49 -0500 (EST)
Message-Id: <20111206.131449.1351676944529284449.davem@davemloft.net>
To: Ian.Campbell@citrix.com
From: David Miller <davem@davemloft.net>
In-Reply-To: <1323166882.23681.46.camel@zakaz.uk.xensource.com>
References: <1323166100-7059-1-git-send-email-wei.liu2@citrix.com>
	<1323166882.23681.46.camel@zakaz.uk.xensource.com>
X-Mailer: Mew version 6.4 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6
	(shards.monkeyblade.net [198.137.202.13]);
	Tue, 06 Dec 2011 10:14:51 -0800 (PST)
Cc: netdev@vger.kernel.org, xen-devel@lists.xensource.com, wei.liu2@citrix.com
Subject: Re: [Xen-devel] [PATCH] netback: remove redundant assignment
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Ian Campbell <Ian.Campbell@citrix.com>
Date: Tue, 6 Dec 2011 10:21:22 +0000

> On Tue, 2011-12-06 at 10:08 +0000, Wei Liu wrote:
>> New value for netbk->mmap_pages[pending_idx] is assigned in
>> xen_netbk_alloc_page(), no need for a second assignment which
>> exposes internal to the outside world.
>> 
>> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> Acked-by: Ian Campbell <ian.campbell@citrix.com>

Applied to net-next, thanks.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 18:19:12 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 18:19:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXzbP-0007lS-16; Tue, 06 Dec 2011 18:18:51 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RXzbN-0007lC-5S
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 18:18:49 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1323195447!46815854!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjM3Ng==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31961 invoked from network); 6 Dec 2011 18:17:27 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Dec 2011 18:17:27 -0000
X-IronPort-AV: E=Sophos;i="4.71,307,1320624000"; 
   d="scan'208";a="9328255"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Dec 2011 18:18:00 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 6 Dec 2011 18:17:59 +0000
Date: Tue, 6 Dec 2011 18:19:12 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: <xen-devel@lists.xensource.com>
Message-ID: <alpine.DEB.2.00.1112061753410.31179@kaball-desktop>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, Tim Deegan <Tim.Deegan@citrix.com>
Subject: [Xen-devel] [PATCH RFC 00/25] xen: ARMv7 with virtualization
	extensions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hello everyone,
this is the very first version of the patch series that introduces ARMv7
with virtualization extensions support in Xen.
The series allows Xen and Dom0 to boot on a Cortex-A15 based Versatile
Express simulator.
See the following announce email for more informations about what we
are trying to achieve, as well as the original git history:

See http://marc.info/?l=xen-devel&m=132257857628098&w=2


The first 7 patches affect generic Xen code and are not ARM specific;
often they fix real issues, hidden in the default X86 configuration.

The following 18 patches introduce ARMv7 with virtualization extensions
support: makefiles first, then the asm-arm header files and finally
everything else, ordered in a way that should make the patches easier
to read.

Although I have been working on cleaning these patches for a week now,
this is just the first version of the series, so expect some rough
edges. You have been warned :-)
Also keep in mind that many functions still have only a dummy
implementation; we hope to fill the gaps as soon as possible.

Please read the patch series and let me know if you find any bugs, have
any comments or suggestions. With your help I am looking forward to
improving the quality of this work.


Stefano Stabellini (25):
      Include some header files that are not automatically included on all archs
      A collection of fixes to Xen common files
      Move cpufreq option parsing to cpufreq.c
      Replace "/" operand with div64
      Introduce clear_user
      libelf-loader: introduce elf_load_image and CONFIG_KERNEL_NO_RELOC
      xen/common/Makefile: introduce HAS_CPUFREQ, HAS_PCI, HAS_PASSTHROUGH, HAS_NS16550
      arm: makefiles
      arm: compile tmem
      arm: header files
      arm: bit manipulation, copy and division libraries
      arm: entry.S and head.S
      arm: domain
      arm: domain_build
      arm: driver for CoreLink GIC-400 Generic Interrupt Controller
      arm: mmio handlers
      arm: irq
      arm: mm and p2m
      arm: pl011 UART driver
      arm: early setup code
      arm: shutdown, smp and smpboot
      arm: driver for the generic timer for ARMv7
      arm: trap handlers
      arm: vgic emulation
      arm: vtimer


 config/arm.mk                                  |   18 +
 xen/arch/arm/Makefile                          |   76 +++
 xen/arch/arm/Rules.mk                          |   29 ++
 xen/arch/arm/asm-offsets.c                     |   76 +++
 xen/arch/arm/domain.c                          |  269 +++++++++++
 xen/arch/arm/domain_build.c                    |  211 ++++++++
 xen/arch/arm/dummy.S                           |   72 +++
 xen/arch/arm/entry.S                           |  107 +++++
 xen/arch/arm/gic.c                             |  473 ++++++++++++++++++
 xen/arch/arm/gic.h                             |  154 ++++++
 xen/arch/arm/head.S                            |  298 ++++++++++++
 xen/arch/arm/io.c                              |   51 ++
 xen/arch/arm/io.h                              |   55 +++
 xen/arch/arm/irq.c                             |  180 +++++++
 xen/arch/arm/lib/Makefile                      |    5 +
 xen/arch/arm/lib/assembler.h                   |   49 ++
 xen/arch/arm/lib/bitops.h                      |   36 ++
 xen/arch/arm/lib/changebit.S                   |   18 +
 xen/arch/arm/lib/clearbit.S                    |   19 +
 xen/arch/arm/lib/copy_template.S               |  266 +++++++++++
 xen/arch/arm/lib/div64.S                       |  149 ++++++
 xen/arch/arm/lib/findbit.S                     |  115 +++++
 xen/arch/arm/lib/lib1funcs.S                   |  274 +++++++++++
 xen/arch/arm/lib/memcpy.S                      |   64 +++
 xen/arch/arm/lib/memmove.S                     |  200 ++++++++
 xen/arch/arm/lib/memset.S                      |  129 +++++
 xen/arch/arm/lib/memzero.S                     |  127 +++++
 xen/arch/arm/lib/setbit.S                      |   18 +
 xen/arch/arm/lib/testchangebit.S               |   18 +
 xen/arch/arm/lib/testclearbit.S                |   18 +
 xen/arch/arm/lib/testsetbit.S                  |   18 +
 xen/arch/arm/mm.c                              |  321 +++++++++++++
 xen/arch/arm/p2m.c                             |  214 +++++++++
 xen/arch/arm/setup.c                           |  206 ++++++++
 xen/arch/arm/shutdown.c                        |   23 +
 xen/arch/arm/smp.c                             |   29 ++
 xen/arch/arm/smpboot.c                         |   50 ++
 xen/arch/arm/time.c                            |  181 +++++++
 xen/arch/arm/traps.c                           |  609 ++++++++++++++++++++++++
 xen/arch/arm/usercopy.c                        |   81 ++++
 xen/arch/arm/vgic.c                            |  605 +++++++++++++++++++++++
 xen/arch/arm/vtimer.c                          |  148 ++++++
 xen/arch/arm/vtimer.h                          |   35 ++
 xen/arch/arm/xen.lds.S                         |  141 ++++++
 xen/arch/ia64/Rules.mk                         |    4 +
 xen/arch/ia64/linux/memcpy_mck.S               |  177 +++++++
 xen/arch/x86/Rules.mk                          |    4 +
 xen/arch/x86/usercopy.c                        |   36 ++
 xen/common/Makefile                            |    2 +-
 xen/common/domain.c                            |   37 +--
 xen/common/domctl.c                            |    1 +
 xen/common/grant_table.c                       |    1 +
 xen/common/irq.c                               |    1 +
 xen/common/kernel.c                            |    2 +-
 xen/common/keyhandler.c                        |    5 +-
 xen/common/lib.c                               |    9 +-
 xen/common/libelf/libelf-dominfo.c             |    6 +
 xen/common/libelf/libelf-loader.c              |   21 +-
 xen/common/memory.c                            |    4 +-
 xen/common/sched_credit.c                      |    7 +-
 xen/common/sched_credit2.c                     |   11 +-
 xen/common/sched_sedf.c                        |   30 +-
 xen/common/shutdown.c                          |    4 +
 xen/common/spinlock.c                          |    1 +
 xen/common/timer.c                             |    7 +-
 xen/common/tmem.c                              |    3 +-
 xen/common/tmem_xen.c                          |    6 +-
 xen/common/wait.c                              |    1 +
 xen/drivers/Makefile                           |    6 +-
 xen/drivers/char/Makefile                      |    3 +-
 xen/drivers/char/console.c                     |    5 +
 xen/drivers/char/pl011.c                       |  266 +++++++++++
 xen/drivers/cpufreq/cpufreq.c                  |   31 ++
 xen/include/asm-arm/asm_defns.h                |   18 +
 xen/include/asm-arm/atomic.h                   |  212 ++++++++
 xen/include/asm-arm/bitops.h                   |  195 ++++++++
 xen/include/asm-arm/bug.h                      |   15 +
 xen/include/asm-arm/byteorder.h                |   16 +
 xen/include/asm-arm/cache.h                    |   20 +
 xen/include/asm-arm/config.h                   |  124 +++++
 xen/include/asm-arm/cpregs.h                   |  207 ++++++++
 xen/include/asm-arm/current.h                  |   60 +++
 xen/include/asm-arm/debugger.h                 |   15 +
 xen/include/asm-arm/delay.h                    |   15 +
 xen/include/asm-arm/desc.h                     |   12 +
 xen/include/asm-arm/div64.h                    |  241 ++++++++++
 xen/include/asm-arm/domain.h                   |   82 ++++
 xen/include/asm-arm/elf.h                      |   33 ++
 xen/include/asm-arm/event.h                    |   41 ++
 xen/include/asm-arm/flushtlb.h                 |   31 ++
 xen/include/asm-arm/grant_table.h              |   35 ++
 xen/include/asm-arm/guest_access.h             |  125 +++++
 xen/include/asm-arm/hardirq.h                  |   28 ++
 xen/include/asm-arm/hypercall.h                |   24 +
 xen/include/asm-arm/init.h                     |   12 +
 xen/include/asm-arm/io.h                       |   12 +
 xen/include/asm-arm/iocap.h                    |   20 +
 xen/include/asm-arm/irq.h                      |   30 ++
 xen/include/asm-arm/mm.h                       |  315 ++++++++++++
 xen/include/asm-arm/multicall.h                |   23 +
 xen/include/asm-arm/nmi.h                      |   15 +
 xen/include/asm-arm/numa.h                     |   21 +
 xen/include/asm-arm/p2m.h                      |   88 ++++
 xen/include/asm-arm/page.h                     |  335 +++++++++++++
 xen/include/asm-arm/paging.h                   |   13 +
 xen/include/asm-arm/percpu.h                   |   28 ++
 xen/include/asm-arm/processor.h                |  269 +++++++++++
 xen/include/asm-arm/regs.h                     |   43 ++
 xen/include/asm-arm/setup.h                    |   20 +
 xen/include/asm-arm/smp.h                      |   25 +
 xen/include/asm-arm/softirq.h                  |   15 +
 xen/include/asm-arm/spinlock.h                 |  144 ++++++
 xen/include/asm-arm/string.h                   |   38 ++
 xen/include/asm-arm/system.h                   |  202 ++++++++
 xen/include/asm-arm/time.h                     |   26 +
 xen/include/asm-arm/trace.h                    |   12 +
 xen/include/asm-arm/types.h                    |   57 +++
 xen/include/asm-arm/xenoprof.h                 |   12 +
 xen/include/asm-ia64/linux/asm-generic/div64.h |    6 +
 xen/include/asm-ia64/uaccess.h                 |   12 +
 xen/include/asm-x86/div64.h                    |    6 +
 xen/include/asm-x86/uaccess.h                  |    1 +
 xen/include/public/arch-arm.h                  |  125 +++++
 xen/include/public/xen.h                       |    2 +
 xen/include/xen/domain.h                       |    2 +
 xen/include/xen/grant_table.h                  |    1 +
 xen/include/xen/irq.h                          |   13 +
 xen/include/xen/kernel.h                       |   12 +-
 xen/include/xen/libelf.h                       |    2 +-
 xen/include/xen/list.h                         |    1 +
 xen/include/xen/sched.h                        |    4 +
 xen/include/xen/serial.h                       |    2 +
 xen/include/xen/time.h                         |    1 +
 xen/include/xen/timer.h                        |    1 +
 xen/include/xen/tmem_xen.h                     |    1 +
 135 files changed, 10358 insertions(+), 84 deletions(-)


A git branch is available here, based on xen-unstable (git CS
367ababd691a023944d648a6d980ccf866b01169):

git://xenbits.xen.org/people/sstabellini/xen-unstable.git arm-v1


Cheers,

Stefano

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 18:19:12 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 18:19:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXzbP-0007lS-16; Tue, 06 Dec 2011 18:18:51 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RXzbN-0007lC-5S
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 18:18:49 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1323195447!46815854!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjM3Ng==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31961 invoked from network); 6 Dec 2011 18:17:27 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Dec 2011 18:17:27 -0000
X-IronPort-AV: E=Sophos;i="4.71,307,1320624000"; 
   d="scan'208";a="9328255"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Dec 2011 18:18:00 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 6 Dec 2011 18:17:59 +0000
Date: Tue, 6 Dec 2011 18:19:12 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: <xen-devel@lists.xensource.com>
Message-ID: <alpine.DEB.2.00.1112061753410.31179@kaball-desktop>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, Tim Deegan <Tim.Deegan@citrix.com>
Subject: [Xen-devel] [PATCH RFC 00/25] xen: ARMv7 with virtualization
	extensions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hello everyone,
this is the very first version of the patch series that introduces ARMv7
with virtualization extensions support in Xen.
The series allows Xen and Dom0 to boot on a Cortex-A15 based Versatile
Express simulator.
See the following announce email for more informations about what we
are trying to achieve, as well as the original git history:

See http://marc.info/?l=xen-devel&m=132257857628098&w=2


The first 7 patches affect generic Xen code and are not ARM specific;
often they fix real issues, hidden in the default X86 configuration.

The following 18 patches introduce ARMv7 with virtualization extensions
support: makefiles first, then the asm-arm header files and finally
everything else, ordered in a way that should make the patches easier
to read.

Although I have been working on cleaning these patches for a week now,
this is just the first version of the series, so expect some rough
edges. You have been warned :-)
Also keep in mind that many functions still have only a dummy
implementation; we hope to fill the gaps as soon as possible.

Please read the patch series and let me know if you find any bugs, have
any comments or suggestions. With your help I am looking forward to
improving the quality of this work.


Stefano Stabellini (25):
      Include some header files that are not automatically included on all archs
      A collection of fixes to Xen common files
      Move cpufreq option parsing to cpufreq.c
      Replace "/" operand with div64
      Introduce clear_user
      libelf-loader: introduce elf_load_image and CONFIG_KERNEL_NO_RELOC
      xen/common/Makefile: introduce HAS_CPUFREQ, HAS_PCI, HAS_PASSTHROUGH, HAS_NS16550
      arm: makefiles
      arm: compile tmem
      arm: header files
      arm: bit manipulation, copy and division libraries
      arm: entry.S and head.S
      arm: domain
      arm: domain_build
      arm: driver for CoreLink GIC-400 Generic Interrupt Controller
      arm: mmio handlers
      arm: irq
      arm: mm and p2m
      arm: pl011 UART driver
      arm: early setup code
      arm: shutdown, smp and smpboot
      arm: driver for the generic timer for ARMv7
      arm: trap handlers
      arm: vgic emulation
      arm: vtimer


 config/arm.mk                                  |   18 +
 xen/arch/arm/Makefile                          |   76 +++
 xen/arch/arm/Rules.mk                          |   29 ++
 xen/arch/arm/asm-offsets.c                     |   76 +++
 xen/arch/arm/domain.c                          |  269 +++++++++++
 xen/arch/arm/domain_build.c                    |  211 ++++++++
 xen/arch/arm/dummy.S                           |   72 +++
 xen/arch/arm/entry.S                           |  107 +++++
 xen/arch/arm/gic.c                             |  473 ++++++++++++++++++
 xen/arch/arm/gic.h                             |  154 ++++++
 xen/arch/arm/head.S                            |  298 ++++++++++++
 xen/arch/arm/io.c                              |   51 ++
 xen/arch/arm/io.h                              |   55 +++
 xen/arch/arm/irq.c                             |  180 +++++++
 xen/arch/arm/lib/Makefile                      |    5 +
 xen/arch/arm/lib/assembler.h                   |   49 ++
 xen/arch/arm/lib/bitops.h                      |   36 ++
 xen/arch/arm/lib/changebit.S                   |   18 +
 xen/arch/arm/lib/clearbit.S                    |   19 +
 xen/arch/arm/lib/copy_template.S               |  266 +++++++++++
 xen/arch/arm/lib/div64.S                       |  149 ++++++
 xen/arch/arm/lib/findbit.S                     |  115 +++++
 xen/arch/arm/lib/lib1funcs.S                   |  274 +++++++++++
 xen/arch/arm/lib/memcpy.S                      |   64 +++
 xen/arch/arm/lib/memmove.S                     |  200 ++++++++
 xen/arch/arm/lib/memset.S                      |  129 +++++
 xen/arch/arm/lib/memzero.S                     |  127 +++++
 xen/arch/arm/lib/setbit.S                      |   18 +
 xen/arch/arm/lib/testchangebit.S               |   18 +
 xen/arch/arm/lib/testclearbit.S                |   18 +
 xen/arch/arm/lib/testsetbit.S                  |   18 +
 xen/arch/arm/mm.c                              |  321 +++++++++++++
 xen/arch/arm/p2m.c                             |  214 +++++++++
 xen/arch/arm/setup.c                           |  206 ++++++++
 xen/arch/arm/shutdown.c                        |   23 +
 xen/arch/arm/smp.c                             |   29 ++
 xen/arch/arm/smpboot.c                         |   50 ++
 xen/arch/arm/time.c                            |  181 +++++++
 xen/arch/arm/traps.c                           |  609 ++++++++++++++++++++++++
 xen/arch/arm/usercopy.c                        |   81 ++++
 xen/arch/arm/vgic.c                            |  605 +++++++++++++++++++++++
 xen/arch/arm/vtimer.c                          |  148 ++++++
 xen/arch/arm/vtimer.h                          |   35 ++
 xen/arch/arm/xen.lds.S                         |  141 ++++++
 xen/arch/ia64/Rules.mk                         |    4 +
 xen/arch/ia64/linux/memcpy_mck.S               |  177 +++++++
 xen/arch/x86/Rules.mk                          |    4 +
 xen/arch/x86/usercopy.c                        |   36 ++
 xen/common/Makefile                            |    2 +-
 xen/common/domain.c                            |   37 +--
 xen/common/domctl.c                            |    1 +
 xen/common/grant_table.c                       |    1 +
 xen/common/irq.c                               |    1 +
 xen/common/kernel.c                            |    2 +-
 xen/common/keyhandler.c                        |    5 +-
 xen/common/lib.c                               |    9 +-
 xen/common/libelf/libelf-dominfo.c             |    6 +
 xen/common/libelf/libelf-loader.c              |   21 +-
 xen/common/memory.c                            |    4 +-
 xen/common/sched_credit.c                      |    7 +-
 xen/common/sched_credit2.c                     |   11 +-
 xen/common/sched_sedf.c                        |   30 +-
 xen/common/shutdown.c                          |    4 +
 xen/common/spinlock.c                          |    1 +
 xen/common/timer.c                             |    7 +-
 xen/common/tmem.c                              |    3 +-
 xen/common/tmem_xen.c                          |    6 +-
 xen/common/wait.c                              |    1 +
 xen/drivers/Makefile                           |    6 +-
 xen/drivers/char/Makefile                      |    3 +-
 xen/drivers/char/console.c                     |    5 +
 xen/drivers/char/pl011.c                       |  266 +++++++++++
 xen/drivers/cpufreq/cpufreq.c                  |   31 ++
 xen/include/asm-arm/asm_defns.h                |   18 +
 xen/include/asm-arm/atomic.h                   |  212 ++++++++
 xen/include/asm-arm/bitops.h                   |  195 ++++++++
 xen/include/asm-arm/bug.h                      |   15 +
 xen/include/asm-arm/byteorder.h                |   16 +
 xen/include/asm-arm/cache.h                    |   20 +
 xen/include/asm-arm/config.h                   |  124 +++++
 xen/include/asm-arm/cpregs.h                   |  207 ++++++++
 xen/include/asm-arm/current.h                  |   60 +++
 xen/include/asm-arm/debugger.h                 |   15 +
 xen/include/asm-arm/delay.h                    |   15 +
 xen/include/asm-arm/desc.h                     |   12 +
 xen/include/asm-arm/div64.h                    |  241 ++++++++++
 xen/include/asm-arm/domain.h                   |   82 ++++
 xen/include/asm-arm/elf.h                      |   33 ++
 xen/include/asm-arm/event.h                    |   41 ++
 xen/include/asm-arm/flushtlb.h                 |   31 ++
 xen/include/asm-arm/grant_table.h              |   35 ++
 xen/include/asm-arm/guest_access.h             |  125 +++++
 xen/include/asm-arm/hardirq.h                  |   28 ++
 xen/include/asm-arm/hypercall.h                |   24 +
 xen/include/asm-arm/init.h                     |   12 +
 xen/include/asm-arm/io.h                       |   12 +
 xen/include/asm-arm/iocap.h                    |   20 +
 xen/include/asm-arm/irq.h                      |   30 ++
 xen/include/asm-arm/mm.h                       |  315 ++++++++++++
 xen/include/asm-arm/multicall.h                |   23 +
 xen/include/asm-arm/nmi.h                      |   15 +
 xen/include/asm-arm/numa.h                     |   21 +
 xen/include/asm-arm/p2m.h                      |   88 ++++
 xen/include/asm-arm/page.h                     |  335 +++++++++++++
 xen/include/asm-arm/paging.h                   |   13 +
 xen/include/asm-arm/percpu.h                   |   28 ++
 xen/include/asm-arm/processor.h                |  269 +++++++++++
 xen/include/asm-arm/regs.h                     |   43 ++
 xen/include/asm-arm/setup.h                    |   20 +
 xen/include/asm-arm/smp.h                      |   25 +
 xen/include/asm-arm/softirq.h                  |   15 +
 xen/include/asm-arm/spinlock.h                 |  144 ++++++
 xen/include/asm-arm/string.h                   |   38 ++
 xen/include/asm-arm/system.h                   |  202 ++++++++
 xen/include/asm-arm/time.h                     |   26 +
 xen/include/asm-arm/trace.h                    |   12 +
 xen/include/asm-arm/types.h                    |   57 +++
 xen/include/asm-arm/xenoprof.h                 |   12 +
 xen/include/asm-ia64/linux/asm-generic/div64.h |    6 +
 xen/include/asm-ia64/uaccess.h                 |   12 +
 xen/include/asm-x86/div64.h                    |    6 +
 xen/include/asm-x86/uaccess.h                  |    1 +
 xen/include/public/arch-arm.h                  |  125 +++++
 xen/include/public/xen.h                       |    2 +
 xen/include/xen/domain.h                       |    2 +
 xen/include/xen/grant_table.h                  |    1 +
 xen/include/xen/irq.h                          |   13 +
 xen/include/xen/kernel.h                       |   12 +-
 xen/include/xen/libelf.h                       |    2 +-
 xen/include/xen/list.h                         |    1 +
 xen/include/xen/sched.h                        |    4 +
 xen/include/xen/serial.h                       |    2 +
 xen/include/xen/time.h                         |    1 +
 xen/include/xen/timer.h                        |    1 +
 xen/include/xen/tmem_xen.h                     |    1 +
 135 files changed, 10358 insertions(+), 84 deletions(-)


A git branch is available here, based on xen-unstable (git CS
367ababd691a023944d648a6d980ccf866b01169):

git://xenbits.xen.org/people/sstabellini/xen-unstable.git arm-v1


Cheers,

Stefano

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 18:20:36 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 18:20:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXzd0-0007w7-Bx; Tue, 06 Dec 2011 18:20:30 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RXzcy-0007uy-E2
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 18:20:29 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1323195545!51363948!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMzAwOTc=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4073 invoked from network); 6 Dec 2011 18:19:13 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Dec 2011 18:19:13 -0000
X-IronPort-AV: E=Sophos;i="4.71,307,1320642000"; d="scan'208";a="173120747"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Dec 2011 13:19:45 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Tue, 6 Dec 2011 13:19:44 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pB6IJEjK019549;
	Tue, 6 Dec 2011 10:19:28 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Tue, 6 Dec 2011 18:19:54 +0000
Message-ID: <1323195609-17277-10-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1112061753410.31179@kaball-desktop>
References: <alpine.DEB.2.00.1112061753410.31179@kaball-desktop>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>, Tim.Deegan@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH RFC 10/25] arm: header files
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

A simple implementation of everything under asm-arm and arch-arm.h; some
of these files are shamelessly taken from Linux.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
---
 xen/include/asm-arm/atomic.h      |  212 +++++++++++++++++++++++++++++
 xen/include/asm-arm/bitops.h      |  195 +++++++++++++++++++++++++++
 xen/include/asm-arm/bug.h         |   15 ++
 xen/include/asm-arm/byteorder.h   |   16 +++
 xen/include/asm-arm/cache.h       |   20 +++
 xen/include/asm-arm/config.h      |  124 +++++++++++++++++
 xen/include/asm-arm/cpregs.h      |  207 ++++++++++++++++++++++++++++
 xen/include/asm-arm/current.h     |   60 ++++++++
 xen/include/asm-arm/debugger.h    |   15 ++
 xen/include/asm-arm/delay.h       |   15 ++
 xen/include/asm-arm/desc.h        |   12 ++
 xen/include/asm-arm/div64.h       |  241 +++++++++++++++++++++++++++++++++
 xen/include/asm-arm/elf.h         |   33 +++++
 xen/include/asm-arm/event.h       |   41 ++++++
 xen/include/asm-arm/flushtlb.h    |   31 +++++
 xen/include/asm-arm/grant_table.h |   35 +++++
 xen/include/asm-arm/hardirq.h     |   28 ++++
 xen/include/asm-arm/hypercall.h   |   24 ++++
 xen/include/asm-arm/init.h        |   12 ++
 xen/include/asm-arm/io.h          |   12 ++
 xen/include/asm-arm/iocap.h       |   20 +++
 xen/include/asm-arm/multicall.h   |   23 +++
 xen/include/asm-arm/nmi.h         |   15 ++
 xen/include/asm-arm/numa.h        |   21 +++
 xen/include/asm-arm/paging.h      |   13 ++
 xen/include/asm-arm/percpu.h      |   28 ++++
 xen/include/asm-arm/processor.h   |  269 +++++++++++++++++++++++++++++++++++++
 xen/include/asm-arm/regs.h        |   43 ++++++
 xen/include/asm-arm/setup.h       |   16 +++
 xen/include/asm-arm/smp.h         |   25 ++++
 xen/include/asm-arm/softirq.h     |   15 ++
 xen/include/asm-arm/spinlock.h    |  144 ++++++++++++++++++++
 xen/include/asm-arm/string.h      |   38 +++++
 xen/include/asm-arm/system.h      |  202 ++++++++++++++++++++++++++++
 xen/include/asm-arm/trace.h       |   12 ++
 xen/include/asm-arm/types.h       |   57 ++++++++
 xen/include/asm-arm/xenoprof.h    |   12 ++
 xen/include/public/arch-arm.h     |  125 +++++++++++++++++
 xen/include/public/xen.h          |    2 +
 39 files changed, 2428 insertions(+), 0 deletions(-)
 create mode 100644 xen/include/asm-arm/atomic.h
 create mode 100644 xen/include/asm-arm/bitops.h
 create mode 100644 xen/include/asm-arm/bug.h
 create mode 100644 xen/include/asm-arm/byteorder.h
 create mode 100644 xen/include/asm-arm/cache.h
 create mode 100644 xen/include/asm-arm/config.h
 create mode 100644 xen/include/asm-arm/cpregs.h
 create mode 100644 xen/include/asm-arm/current.h
 create mode 100644 xen/include/asm-arm/debugger.h
 create mode 100644 xen/include/asm-arm/delay.h
 create mode 100644 xen/include/asm-arm/desc.h
 create mode 100644 xen/include/asm-arm/div64.h
 create mode 100644 xen/include/asm-arm/elf.h
 create mode 100644 xen/include/asm-arm/event.h
 create mode 100644 xen/include/asm-arm/flushtlb.h
 create mode 100644 xen/include/asm-arm/grant_table.h
 create mode 100644 xen/include/asm-arm/hardirq.h
 create mode 100644 xen/include/asm-arm/hypercall.h
 create mode 100644 xen/include/asm-arm/init.h
 create mode 100644 xen/include/asm-arm/io.h
 create mode 100644 xen/include/asm-arm/iocap.h
 create mode 100644 xen/include/asm-arm/multicall.h
 create mode 100644 xen/include/asm-arm/nmi.h
 create mode 100644 xen/include/asm-arm/numa.h
 create mode 100644 xen/include/asm-arm/paging.h
 create mode 100644 xen/include/asm-arm/percpu.h
 create mode 100644 xen/include/asm-arm/processor.h
 create mode 100644 xen/include/asm-arm/regs.h
 create mode 100644 xen/include/asm-arm/setup.h
 create mode 100644 xen/include/asm-arm/smp.h
 create mode 100644 xen/include/asm-arm/softirq.h
 create mode 100644 xen/include/asm-arm/spinlock.h
 create mode 100644 xen/include/asm-arm/string.h
 create mode 100644 xen/include/asm-arm/system.h
 create mode 100644 xen/include/asm-arm/trace.h
 create mode 100644 xen/include/asm-arm/types.h
 create mode 100644 xen/include/asm-arm/xenoprof.h
 create mode 100644 xen/include/public/arch-arm.h

diff --git a/xen/include/asm-arm/atomic.h b/xen/include/asm-arm/atomic.h
new file mode 100644
index 0000000..2b9ce0e
--- /dev/null
+++ b/xen/include/asm-arm/atomic.h
@@ -0,0 +1,212 @@
+/*
+ *  arch/arm/include/asm/atomic.h
+ *
+ *  Copyright (C) 1996 Russell King.
+ *  Copyright (C) 2002 Deep Blue Solutions Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#ifndef __ARCH_ARM_ATOMIC__
+#define __ARCH_ARM_ATOMIC__
+
+#include <xen/config.h>
+#include <asm/system.h>
+
+#define build_atomic_read(name, size, type, reg)   \
+static inline type name(const volatile type *addr) \
+{                                                  \
+    type ret;                                      \
+    asm volatile("ldr" size " %0,%1"               \
+                 : reg (ret)                       \
+                 : "m" (*(volatile type *)addr));  \
+    return ret;                                    \
+}
+
+#define build_atomic_write(name, size, type, reg)      \
+static inline void name(volatile type *addr, type val) \
+{                                                      \
+    asm volatile("str" size " %1,%0"                   \
+                 : "=m" (*(volatile type *)addr)       \
+                 : reg (val));                         \
+}
+
+build_atomic_read(atomic_read8, "b", uint8_t, "=q")
+build_atomic_read(atomic_read16, "h", uint16_t, "=r")
+build_atomic_read(atomic_read32, "", uint32_t, "=r")
+//build_atomic_read(atomic_read64, "d", uint64_t, "=r")
+build_atomic_read(atomic_read_int, "", int, "=r")
+
+build_atomic_write(atomic_write8, "b", uint8_t, "q")
+build_atomic_write(atomic_write16, "h", uint16_t, "r")
+build_atomic_write(atomic_write32, "", uint32_t, "r")
+//build_atomic_write(atomic_write64, "d", uint64_t, "r")
+build_atomic_write(atomic_write_int, "", int, "r")
+
+/*
+ * NB. I've pushed the volatile qualifier into the operations. This allows
+ * fast accessors such as _atomic_read() and _atomic_set() which don't give
+ * the compiler a fit.
+ */
+typedef struct { int counter; } atomic_t;
+
+#define ATOMIC_INIT(i) { (i) }
+
+/*
+ * On ARM, ordinary assignment (str instruction) doesn't clear the local
+ * strex/ldrex monitor on some implementations. The reason we can use it for
+ * atomic_set() is the clrex or dummy strex done on every exception return.
+ */
+#define _atomic_read(v) ((v).counter)
+#define atomic_read(v)  (*(volatile int *)&(v)->counter)
+
+#define _atomic_set(v,i) (((v).counter) = (i))
+#define atomic_set(v,i) (((v)->counter) = (i))
+
+/*
+ * ARMv6 UP and SMP safe atomic ops.  We use load exclusive and
+ * store exclusive to ensure that these are atomic.  We may loop
+ * to ensure that the update happens.
+ */
+static inline void atomic_add(int i, atomic_t *v)
+{
+        unsigned long tmp;
+        int result;
+
+        __asm__ __volatile__("@ atomic_add\n"
+"1:     ldrex   %0, [%3]\n"
+"       add     %0, %0, %4\n"
+"       strex   %1, %0, [%3]\n"
+"       teq     %1, #0\n"
+"       bne     1b"
+        : "=&r" (result), "=&r" (tmp), "+Qo" (v->counter)
+        : "r" (&v->counter), "Ir" (i)
+        : "cc");
+}
+
+static inline int atomic_add_return(int i, atomic_t *v)
+{
+        unsigned long tmp;
+        int result;
+
+        smp_mb();
+
+        __asm__ __volatile__("@ atomic_add_return\n"
+"1:     ldrex   %0, [%3]\n"
+"       add     %0, %0, %4\n"
+"       strex   %1, %0, [%3]\n"
+"       teq     %1, #0\n"
+"       bne     1b"
+        : "=&r" (result), "=&r" (tmp), "+Qo" (v->counter)
+        : "r" (&v->counter), "Ir" (i)
+        : "cc");
+
+        smp_mb();
+
+        return result;
+}
+
+static inline void atomic_sub(int i, atomic_t *v)
+{
+        unsigned long tmp;
+        int result;
+
+        __asm__ __volatile__("@ atomic_sub\n"
+"1:     ldrex   %0, [%3]\n"
+"       sub     %0, %0, %4\n"
+"       strex   %1, %0, [%3]\n"
+"       teq     %1, #0\n"
+"       bne     1b"
+        : "=&r" (result), "=&r" (tmp), "+Qo" (v->counter)
+        : "r" (&v->counter), "Ir" (i)
+        : "cc");
+}
+
+static inline int atomic_sub_return(int i, atomic_t *v)
+{
+        unsigned long tmp;
+        int result;
+
+        smp_mb();
+
+        __asm__ __volatile__("@ atomic_sub_return\n"
+"1:     ldrex   %0, [%3]\n"
+"       sub     %0, %0, %4\n"
+"       strex   %1, %0, [%3]\n"
+"       teq     %1, #0\n"
+"       bne     1b"
+        : "=&r" (result), "=&r" (tmp), "+Qo" (v->counter)
+        : "r" (&v->counter), "Ir" (i)
+        : "cc");
+
+        smp_mb();
+
+        return result;
+}
+
+static inline int atomic_cmpxchg(atomic_t *ptr, int old, int new)
+{
+        unsigned long oldval, res;
+
+        smp_mb();
+
+        do {
+                __asm__ __volatile__("@ atomic_cmpxchg\n"
+                "ldrex  %1, [%3]\n"
+                "mov    %0, #0\n"
+                "teq    %1, %4\n"
+                "strexeq %0, %5, [%3]\n"
+                    : "=&r" (res), "=&r" (oldval), "+Qo" (ptr->counter)
+                    : "r" (&ptr->counter), "Ir" (old), "r" (new)
+                    : "cc");
+        } while (res);
+
+        smp_mb();
+
+        return oldval;
+}
+
+static inline void atomic_clear_mask(unsigned long mask, unsigned long *addr)
+{
+        unsigned long tmp, tmp2;
+
+        __asm__ __volatile__("@ atomic_clear_mask\n"
+"1:     ldrex   %0, [%3]\n"
+"       bic     %0, %0, %4\n"
+"       strex   %1, %0, [%3]\n"
+"       teq     %1, #0\n"
+"       bne     1b"
+        : "=&r" (tmp), "=&r" (tmp2), "+Qo" (*addr)
+        : "r" (addr), "Ir" (mask)
+        : "cc");
+}
+
+#define atomic_inc(v)           atomic_add(1, v)
+#define atomic_dec(v)           atomic_sub(1, v)
+
+#define atomic_inc_and_test(v)  (atomic_add_return(1, v) == 0)
+#define atomic_dec_and_test(v)  (atomic_sub_return(1, v) == 0)
+#define atomic_inc_return(v)    (atomic_add_return(1, v))
+#define atomic_dec_return(v)    (atomic_sub_return(1, v))
+#define atomic_sub_and_test(i, v) (atomic_sub_return(i, v) == 0)
+
+#define atomic_add_negative(i,v) (atomic_add_return(i, v) < 0)
+
+static inline atomic_t atomic_compareandswap(
+    atomic_t old, atomic_t new, atomic_t *v)
+{
+    atomic_t rc;
+    rc.counter = __cmpxchg(&v->counter, old.counter, new.counter, sizeof(int));
+    return rc;
+}
+
+#endif /* __ARCH_ARM_ATOMIC__ */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/bitops.h b/xen/include/asm-arm/bitops.h
new file mode 100644
index 0000000..3d6b30b
--- /dev/null
+++ b/xen/include/asm-arm/bitops.h
@@ -0,0 +1,195 @@
+/*
+ * Copyright 1995, Russell King.
+ * Various bits and pieces copyrights include:
+ *  Linus Torvalds (test_bit).
+ * Big endian support: Copyright 2001, Nicolas Pitre
+ *  reworked by rmk.
+ */
+
+#ifndef _ARM_BITOPS_H
+#define _ARM_BITOPS_H
+
+extern void _set_bit(int nr, volatile void * p);
+extern void _clear_bit(int nr, volatile void * p);
+extern void _change_bit(int nr, volatile void * p);
+extern int _test_and_set_bit(int nr, volatile void * p);
+extern int _test_and_clear_bit(int nr, volatile void * p);
+extern int _test_and_change_bit(int nr, volatile void * p);
+
+#define set_bit(n,p)              _set_bit(n,p)
+#define clear_bit(n,p)            _clear_bit(n,p)
+#define change_bit(n,p)           _change_bit(n,p)
+#define test_and_set_bit(n,p)     _test_and_set_bit(n,p)
+#define test_and_clear_bit(n,p)   _test_and_clear_bit(n,p)
+#define test_and_change_bit(n,p)  _test_and_change_bit(n,p)
+
+#define BIT(nr)                 (1UL << (nr))
+#define BIT_MASK(nr)            (1UL << ((nr) % BITS_PER_LONG))
+#define BIT_WORD(nr)            ((nr) / BITS_PER_LONG)
+#define BITS_PER_BYTE           8
+
+#define ADDR (*(volatile long *) addr)
+#define CONST_ADDR (*(const volatile long *) addr)
+
+/**
+ * __test_and_set_bit - Set a bit and return its old value
+ * @nr: Bit to set
+ * @addr: Address to count from
+ *
+ * This operation is non-atomic and can be reordered.
+ * If two examples of this operation race, one can appear to succeed
+ * but actually fail.  You must protect multiple accesses with a lock.
+ */
+static inline int __test_and_set_bit(int nr, volatile void *addr)
+{
+        unsigned long mask = BIT_MASK(nr);
+        volatile unsigned long *p =
+                ((volatile unsigned long *)addr) + BIT_WORD(nr);
+        unsigned long old = *p;
+
+        *p = old | mask;
+        return (old & mask) != 0;
+}
+
+/**
+ * __test_and_clear_bit - Clear a bit and return its old value
+ * @nr: Bit to clear
+ * @addr: Address to count from
+ *
+ * This operation is non-atomic and can be reordered.
+ * If two examples of this operation race, one can appear to succeed
+ * but actually fail.  You must protect multiple accesses with a lock.
+ */
+static inline int __test_and_clear_bit(int nr, volatile void *addr)
+{
+        unsigned long mask = BIT_MASK(nr);
+        volatile unsigned long *p =
+                ((volatile unsigned long *)addr) + BIT_WORD(nr);
+        unsigned long old = *p;
+
+        *p = old & ~mask;
+        return (old & mask) != 0;
+}
+
+/* WARNING: non atomic and it can be reordered! */
+static inline int __test_and_change_bit(int nr,
+                                            volatile void *addr)
+{
+        unsigned long mask = BIT_MASK(nr);
+        volatile unsigned long *p =
+                ((volatile unsigned long *)addr) + BIT_WORD(nr);
+        unsigned long old = *p;
+
+        *p = old ^ mask;
+        return (old & mask) != 0;
+}
+
+/**
+ * test_bit - Determine whether a bit is set
+ * @nr: bit number to test
+ * @addr: Address to start counting from
+ */
+static inline int test_bit(int nr, const volatile void *addr)
+{
+        const volatile unsigned long *p = (const volatile unsigned long *)addr;
+        return 1UL & (p[BIT_WORD(nr)] >> (nr & (BITS_PER_LONG-1)));
+}
+
+
+extern unsigned int _find_first_bit(
+    const unsigned long *addr, unsigned int size);
+extern unsigned int _find_next_bit(
+    const unsigned long *addr, unsigned int size, unsigned int offset);
+extern unsigned int _find_first_zero_bit(
+    const unsigned long *addr, unsigned int size);
+extern unsigned int _find_next_zero_bit(
+    const unsigned long *addr, unsigned int size, unsigned int offset);
+
+/*
+ * These are the little endian, atomic definitions.
+ */
+#define find_first_zero_bit(p,sz)       _find_first_zero_bit(p,sz)
+#define find_next_zero_bit(p,sz,off)    _find_next_zero_bit(p,sz,off)
+#define find_first_bit(p,sz)            _find_first_bit(p,sz)
+#define find_next_bit(p,sz,off)         _find_next_bit(p,sz,off)
+
+static inline int constant_fls(int x)
+{
+        int r = 32;
+
+        if (!x)
+                return 0;
+        if (!(x & 0xffff0000u)) {
+                x <<= 16;
+                r -= 16;
+        }
+        if (!(x & 0xff000000u)) {
+                x <<= 8;
+                r -= 8;
+        }
+        if (!(x & 0xf0000000u)) {
+                x <<= 4;
+                r -= 4;
+        }
+        if (!(x & 0xc0000000u)) {
+                x <<= 2;
+                r -= 2;
+        }
+        if (!(x & 0x80000000u)) {
+                x <<= 1;
+                r -= 1;
+        }
+        return r;
+}
+
+/*
+ * On ARMv5 and above those functions can be implemented around
+ * the clz instruction for much better code efficiency.
+ */
+
+static inline int fls(int x)
+{
+        int ret;
+
+        if (__builtin_constant_p(x))
+               return constant_fls(x);
+
+        asm("clz\t%0, %1" : "=r" (ret) : "r" (x));
+        ret = 32 - ret;
+        return ret;
+}
+
+#define ffs(x) ({ unsigned long __t = (x); fls(__t & -__t); })
+
+/**
+ * find_first_set_bit - find the first set bit in @word
+ * @word: the word to search
+ *
+ * Returns the bit-number of the first set bit (first bit being 0).
+ * The input must *not* be zero.
+ */
+static inline unsigned int find_first_set_bit(unsigned long word)
+{
+        return ffs(word) - 1;
+}
+
+/**
+ * hweightN - returns the hamming weight of a N-bit word
+ * @x: the word to weigh
+ *
+ * The Hamming Weight of a number is the total number of bits set in it.
+ */
+#define hweight64(x) generic_hweight64(x)
+#define hweight32(x) generic_hweight32(x)
+#define hweight16(x) generic_hweight16(x)
+#define hweight8(x) generic_hweight8(x)
+
+#endif /* _ARM_BITOPS_H */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/bug.h b/xen/include/asm-arm/bug.h
new file mode 100644
index 0000000..bc2532c
--- /dev/null
+++ b/xen/include/asm-arm/bug.h
@@ -0,0 +1,15 @@
+#ifndef __ARM_BUG_H__
+#define __ARM_BUG_H__
+
+#define BUG() __bug(__FILE__, __LINE__)
+#define WARN() __warn(__FILE__, __LINE__)
+
+#endif /* __X86_BUG_H__ */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/byteorder.h b/xen/include/asm-arm/byteorder.h
new file mode 100644
index 0000000..f6ad883
--- /dev/null
+++ b/xen/include/asm-arm/byteorder.h
@@ -0,0 +1,16 @@
+#ifndef __ASM_ARM_BYTEORDER_H__
+#define __ASM_ARM_BYTEORDER_H__
+
+#define __BYTEORDER_HAS_U64__
+
+#include <xen/byteorder/little_endian.h>
+
+#endif /* __ASM_ARM_BYTEORDER_H__ */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/cache.h b/xen/include/asm-arm/cache.h
new file mode 100644
index 0000000..41b6291
--- /dev/null
+++ b/xen/include/asm-arm/cache.h
@@ -0,0 +1,20 @@
+#ifndef __ARCH_ARM_CACHE_H
+#define __ARCH_ARM_CACHE_H
+
+#include <xen/config.h>
+
+/* L1 cache line size */
+#define L1_CACHE_SHIFT  (CONFIG_ARM_L1_CACHE_SHIFT)
+#define L1_CACHE_BYTES  (1 << L1_CACHE_SHIFT)
+
+#define __read_mostly __attribute__((__section__(".data.read_mostly")))
+
+#endif
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/config.h b/xen/include/asm-arm/config.h
new file mode 100644
index 0000000..671ac52
--- /dev/null
+++ b/xen/include/asm-arm/config.h
@@ -0,0 +1,124 @@
+/******************************************************************************
+ * config.h
+ *
+ * A Linux-style configuration list.
+ */
+
+#ifndef __ARM_CONFIG_H__
+#define __ARM_CONFIG_H__
+
+#define CONFIG_PAGING_LEVELS 3
+
+#define CONFIG_ARM 1
+
+#define CONFIG_ARM_L1_CACHE_SHIFT 7 /* XXX */
+
+#define CONFIG_SMP 1
+
+#define CONFIG_DOMAIN_PAGE 1
+
+#define OPT_CONSOLE_STR "com1"
+
+#ifdef MAX_PHYS_CPUS
+#define NR_CPUS MAX_PHYS_CPUS
+#else
+#define NR_CPUS 128
+#endif
+
+#define MAX_VIRT_CPUS 128 /* XXX */
+#define MAX_HVM_VCPUS MAX_VIRT_CPUS
+
+#define asmlinkage /* Nothing needed */
+
+/* Linkage for ARM */
+#define __ALIGN .align 2
+#define __ALIGN_STR ".align 2"
+#ifdef __ASSEMBLY__
+#define ALIGN __ALIGN
+#define ALIGN_STR __ALIGN_STR
+#define ENTRY(name)                             \
+  .globl name;                                  \
+  ALIGN;                                        \
+  name:
+#define END(name) \
+  .size name, .-name
+#define ENDPROC(name) \
+  .type name, %function; \
+  END(name)
+#endif
+
+#define CONFIG_KERNEL_NO_RELOC 1
+
+/*
+ * Memory layout:
+ *  0  -   2M   Unmapped
+ *  2M -   4M   Xen text, data, bss
+ *  4M -   6M   Fixmap: special-purpose 4K mapping slots
+ *
+ * 32M - 128M   Frametable: 24 bytes per page for 16GB of RAM
+ *
+ *  1G -   2G   Xenheap: always-mapped memory
+ *  2G -   4G   Domheap: on-demand-mapped
+ */
+
+#define XEN_VIRT_START         0x00200000
+#define FIXMAP_ADDR(n)        (0x00400000 + (n) * PAGE_SIZE)
+#define FRAMETABLE_VIRT_START  0x02000000
+#define XENHEAP_VIRT_START     0x40000000
+#define DOMHEAP_VIRT_START     0x80000000
+
+#define HYPERVISOR_VIRT_START mk_unsigned_long(XEN_VIRT_START)
+
+#define DOMHEAP_ENTRIES        1024  /* 1024 2MB mapping slots */
+
+/* Fixmap slots */
+#define FIXMAP_CONSOLE  0  /* The primary UART */
+#define FIXMAP_PT       1  /* Temporary mappings of pagetable pages */
+#define FIXMAP_MISC     2  /* Ephemeral mappings of hardware */
+#define FIXMAP_GICD     3  /* Interrupt controller: distributor registers */
+#define FIXMAP_GICC1    4  /* Interrupt controller: CPU registers (first page) */
+#define FIXMAP_GICC2    5  /* Interrupt controller: CPU registers (second page) */
+#define FIXMAP_GICH     6  /* Interrupt controller: virtual interface control registers */
+
+#define PAGE_SHIFT              12
+
+#ifndef __ASSEMBLY__
+#define PAGE_SIZE           (1L << PAGE_SHIFT)
+#else
+#define PAGE_SIZE           (1 << PAGE_SHIFT)
+#endif
+#define PAGE_MASK           (~(PAGE_SIZE-1))
+#define PAGE_FLAG_MASK      (~0)
+
+#define STACK_ORDER 3
+#define STACK_SIZE  (PAGE_SIZE << STACK_ORDER)
+
+#ifndef __ASSEMBLY__
+extern unsigned long xen_phys_start;
+extern unsigned long xenheap_phys_end;
+extern unsigned long frametable_virt_end;
+#endif
+
+#define supervisor_mode_kernel (0)
+
+#define watchdog_disable() ((void)0)
+#define watchdog_enable()  ((void)0)
+
+/* Board-specific: base address of PL011 UART */
+#define EARLY_UART_ADDRESS 0x1c090000
+/* Board-specific: base address of GIC + its regs */
+#define GIC_BASE_ADDRESS 0x2c000000
+#define GIC_DR_OFFSET 0x1000
+#define GIC_CR_OFFSET 0x2000
+#define GIC_HR_OFFSET 0x4000 /* Guess work http://lists.infradead.org/pipermail/linux-arm-kernel/2011-September/064219.html */
+#define GIC_VR_OFFSET 0x6000 /* Virtual Machine CPU interface) */
+
+#endif /* __ARM_CONFIG_H__ */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/cpregs.h b/xen/include/asm-arm/cpregs.h
new file mode 100644
index 0000000..3a4028d
--- /dev/null
+++ b/xen/include/asm-arm/cpregs.h
@@ -0,0 +1,207 @@
+#ifndef __ASM_ARM_CPREGS_H
+#define __ASM_ARM_CPREGS_H
+
+#include <xen/stringify.h>
+
+/* Co-processor registers */
+
+/* Layout as used in assembly, with src/dest registers mixed in */
+#define __CP32(r, coproc, opc1, crn, crm, opc2) coproc, opc1, r, crn, crm, opc2
+#define __CP64(r1, r2, coproc, opc, crm) coproc, opc, r1, r2, crm
+#define CP32(r, name...) __CP32(r, name)
+#define CP64(r, name...) __CP64(r, name)
+
+/* Stringified for inline assembly */
+#define LOAD_CP32(r, name...)  "mrc " __stringify(CP32(%r, name)) ";"
+#define STORE_CP32(r, name...) "mcr " __stringify(CP32(%r, name)) ";"
+#define LOAD_CP64(r, name...)  "mrrc " __stringify(CP64(%r, %H##r, name)) ";"
+#define STORE_CP64(r, name...) "mcrr " __stringify(CP64(%r, %H##r, name)) ";"
+
+/* C wrappers */
+#define READ_CP32(name...) ({                                   \
+    register uint32_t _r;                                       \
+    asm volatile(LOAD_CP32(0, name) : "=r" (_r));               \
+    _r; })
+
+#define WRITE_CP32(v, name...) do {                             \
+    register uint32_t _r = (v);                                 \
+    asm volatile(STORE_CP32(0, name) : : "r" (_r));             \
+} while (0)
+
+#define READ_CP64(name...) ({                                   \
+    register uint64_t _r;                                       \
+    asm volatile(LOAD_CP64(0, name) : "=r" (_r));               \
+    _r; })
+
+#define WRITE_CP64(v, name...) do {                             \
+    register uint64_t _r = (v);                                 \
+    asm volatile(STORE_CP64(0, name) : : "r" (_r));             \
+} while (0)
+
+#define __HSR_CPREG_c0  0
+#define __HSR_CPREG_c1  1
+#define __HSR_CPREG_c2  2
+#define __HSR_CPREG_c3  3
+#define __HSR_CPREG_c4  4
+#define __HSR_CPREG_c5  5
+#define __HSR_CPREG_c6  6
+#define __HSR_CPREG_c7  7
+#define __HSR_CPREG_c8  8
+#define __HSR_CPREG_c9  9
+#define __HSR_CPREG_c10 10
+#define __HSR_CPREG_c11 11
+#define __HSR_CPREG_c12 12
+#define __HSR_CPREG_c13 13
+#define __HSR_CPREG_c14 14
+#define __HSR_CPREG_c15 15
+
+#define __HSR_CPREG_0   0
+#define __HSR_CPREG_1   1
+#define __HSR_CPREG_2   2
+#define __HSR_CPREG_3   3
+#define __HSR_CPREG_4   4
+#define __HSR_CPREG_5   5
+#define __HSR_CPREG_6   6
+#define __HSR_CPREG_7   7
+
+#define _HSR_CPREG32(cp,op1,crn,crm,op2) \
+    ((__HSR_CPREG_##crn) << HSR_CP32_CRN_SHIFT) | \
+    ((__HSR_CPREG_##crm) << HSR_CP32_CRM_SHIFT) | \
+    ((__HSR_CPREG_##op1) << HSR_CP32_OP1_SHIFT) | \
+    ((__HSR_CPREG_##op2) << HSR_CP32_OP2_SHIFT)
+
+#define _HSR_CPREG64(cp,op1,crm) \
+    ((__HSR_CPREG_##crm) << HSR_CP64_CRM_SHIFT) | \
+    ((__HSR_CPREG_##op1) << HSR_CP64_OP1_SHIFT)
+
+/* Encode a register as per HSR ISS pattern */
+#define HSR_CPREG32(X) _HSR_CPREG32(X)
+#define HSR_CPREG64(X) _HSR_CPREG64(X)
+
+/*
+ * Order registers by Coprocessor-> CRn-> Opcode 1-> CRm-> Opcode 2
+ *
+ * This matches the ordering used in the ARM as well as the groupings
+ * which the CP registers are allocated in.
+ *
+ * This is slightly different to the form of the instruction
+ * arguments, which are cp,opc1,crn,crm,opc2.
+ */
+
+/* Coprocessor 15 */
+
+/* CP15 CR0: CPUID and Cache Type Registers */
+#define ID_PFR0         p15,0,c0,c1,0   /* Processor Feature Register 0 */
+#define ID_PFR1         p15,0,c0,c1,1   /* Processor Feature Register 1 */
+#define CCSIDR          p15,1,c0,c0,0   /* Cache Size ID Registers */
+#define CLIDR           p15,1,c0,c0,1   /* Cache Level ID Register */
+#define CSSELR          p15,2,c0,c0,0   /* Cache Size Selection Register */
+
+/* CP15 CR1: System Control Registers */
+#define SCTLR           p15,0,c1,c0,0   /* System Control Register */
+#define SCR             p15,0,c1,c1,0   /* Secure Configuration Register */
+#define NSACR           p15,0,c1,c1,2   /* Non-Secure Access Control Register */
+#define HSCTLR          p15,4,c1,c0,0   /* Hyp. System Control Register */
+#define HCR             p15,4,c1,c1,0   /* Hyp. Configuration Register */
+
+/* CP15 CR2: Translation Table Base and Control Registers */
+#define TTBR0           p15,0,c2,c0,0   /* Translation Table Base Reg. 0 */
+#define TTBR1           p15,0,c2,c0,1   /* Translation Table Base Reg. 1 */
+#define TTBCR           p15,0,c2,c0,2   /* Translatation Table Base Control Register */
+#define HTTBR           p15,4,c2        /* Hyp. Translation Table Base Register */
+#define HTCR            p15,4,c2,c0,2   /* Hyp. Translation Control Register */
+#define VTCR            p15,4,c2,c1,2   /* Virtualization Translation Control Register */
+#define VTTBR           p15,6,c2        /* Virtualization Translation Table Base Register */
+
+/* CP15 CR3: Domain Access Control Register */
+
+/* CP15 CR4: */
+
+/* CP15 CR5: Fault Status Registers */
+#define DFSR            p15,0,c5,c0,0   /* Data Fault Status Register */
+#define IFSR            p15,0,c5,c0,1   /* Instruction Fault Status Register */
+#define HSR             p15,4,c5,c2,0   /* Hyp. Syndrome Register */
+
+/* CP15 CR6: Fault Address Registers */
+#define DFAR            p15,0,c6,c0,0   /* Data Fault Address Register  */
+#define IFAR            p15,0,c6,c0,2   /* Instruction Fault Address Register */
+#define HDFAR           p15,4,c6,c0,0   /* Hyp. Data Fault Address Register */
+#define HIFAR           p15,4,c6,c0,2   /* Hyp. Instruction Fault Address Register */
+#define HPFAR           p15,4,c6,c0,4   /* Hyp. IPA Fault Address Register */
+
+/* CP15 CR7: Cache and address translation operations */
+#define PAR             p15,0,c7        /* Physical Address Register */
+#define ICIALLUIS       p15,0,c7,c1,0   /* Invalidate all instruction caches to PoU inner shareable */
+#define BPIALLIS        p15,0,c7,c1,6   /* Invalidate entire branch predictor array inner shareable */
+#define ICIALLU         p15,0,c7,c5,0   /* Invalidate all instruction caches to PoU */
+#define BPIALL          p15,0,c7,c5,6   /* Invalidate entire branch predictor array */
+#define ATS1CPR         p15,0,c7,c8,0   /* Address Translation Stage 1. Non-Secure Kernel Read */
+#define ATS1CPW         p15,0,c7,c8,1   /* Address Translation Stage 1. Non-Secure Kernel Write */
+#define ATS1CUR         p15,0,c7,c8,2   /* Address Translation Stage 1. Non-Secure User Read */
+#define ATS1CUW         p15,0,c7,c8,3   /* Address Translation Stage 1. Non-Secure User Write */
+#define ATS12NSOPR      p15,0,c7,c8,4   /* Address Translation Stage 1+2 Non-Secure Kernel Read */
+#define ATS12NSOPW      p15,0,c7,c8,5   /* Address Translation Stage 1+2 Non-Secure Kernel Write */
+#define ATS12NSOUR      p15,0,c7,c8,6   /* Address Translation Stage 1+2 Non-Secure User Read */
+#define ATS12NSOUW      p15,0,c7,c8,7   /* Address Translation Stage 1+2 Non-Secure User Write */
+#define DCCMVAC         p15,0,c7,c10,1  /* Clean data or unified cache line by MVA to PoC */
+#define DCCISW          p15,0,c7,c14,2  /* Clean and invalidate data cache line by set/way */
+#define ATS1HR          p15,4,c7,c8,0   /* Address Translation Stage 1 Hyp. Read */
+#define ATS1HW          p15,4,c7,c8,1   /* Address Translation Stage 1 Hyp. Write */
+
+/* CP15 CR8: TLB maintenance operations */
+#define TLBIALLIS       p15,0,c8,c3,0   /* Invalidate entire TLB innrer shareable */
+#define TLBIMVAIS       p15,0,c8,c3,1   /* Invalidate unified TLB entry by MVA inner shareable */
+#define TLBIASIDIS      p15,0,c8,c3,2   /* Invalidate unified TLB by ASID match inner shareable */
+#define TLBIMVAAIS      p15,0,c8,c3,3   /* Invalidate unified TLB entry by MVA all ASID inner shareable */
+#define DTLBIALL        p15,0,c8,c6,0   /* Invalidate data TLB */
+#define DTLBIMVA        p15,0,c8,c6,1   /* Invalidate data TLB entry by MVA */
+#define DTLBIASID       p15,0,c8,c6,2   /* Invalidate data TLB by ASID match */
+#define TLBILLHIS       p15,4,c8,c3,0   /* Invalidate Entire Hyp. Unified TLB inner shareable */
+#define TLBIMVAHIS      p15,4,c8,c3,1   /* Invalidate Unified Hyp. TLB by MVA inner shareable */
+#define TLBIALLNSNHIS   p15,4,c8,c7,4   /* Invalidate Entire Non-Secure Non-Hyp. Unified TLB inner shareable */
+#define TLBIALLH        p15,4,c8,c7,0   /* Invalidate Entire Hyp. Unified TLB */
+#define TLBIMVAH        p15,4,c8,c7,1   /* Invalidate Unified Hyp. TLB by MVA */
+#define TLBIALLNSNH     p15,4,c8,c7,4   /* Invalidate Entire Non-Secure Non-Hyp. Unified TLB */
+
+/* CP15 CR9: */
+
+/* CP15 CR10: */
+#define MAIR0           p15,0,c10,c2,0  /* Memory Attribute Indirection Register 0 */
+#define MAIR1           p15,0,c10,c2,1  /* Memory Attribute Indirection Register 1 */
+#define HMAIR0          p15,4,c10,c2,0  /* Hyp. Memory Attribute Indirection Register 0 */
+#define HMAIR1          p15,4,c10,c2,1  /* Hyp. Memory Attribute Indirection Register 1 */
+
+/* CP15 CR11: DMA Operations for TCM Access */
+
+/* CP15 CR12:  */
+#define HVBAR           p15,4,c12,c0,0  /* Hyp. Vector Base Address Register */
+
+/* CP15 CR13:  */
+#define FCSEIDR         p15,0,c13,c0,0  /* FCSE Process ID Register */
+#define CONTEXTIDR      p15,0,c13,c0,1  /* Context ID Register */
+
+/* CP15 CR14:  */
+#define CNTPCT          p15,0,c14       /* Time counter value */
+#define CNTFRQ          p15,0,c14,c0,0  /* Time counter frequency */
+#define CNTKCTL         p15,0,c14,c1,0  /* Time counter kernel control */
+#define CNTP_TVAL       p15,0,c14,c2,0  /* Physical Timer value */
+#define CNTP_CTL        p15,0,c14,c2,1  /* Physical Timer control register */
+#define CNTVCT          p15,1,c14       /* Time counter value + offset */
+#define CNTP_CVAL       p15,2,c14       /* Physical Timer comparator */
+#define CNTVOFF         p15,4,c14       /* Time counter offset */
+#define CNTHCTL         p15,4,c14,c1,0  /* Time counter hyp. control */
+#define CNTHP_TVAL      p15,4,c14,c2,0  /* Hyp. Timer value */
+#define CNTHP_CTL       p15,4,c14,c2,1  /* Hyp. Timer control register */
+#define CNTHP_CVAL      p15,6,c14       /* Hyp. Timer comparator */
+
+/* CP15 CR15: Implementation Defined Registers */
+
+#endif
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/current.h b/xen/include/asm-arm/current.h
new file mode 100644
index 0000000..826efa5
--- /dev/null
+++ b/xen/include/asm-arm/current.h
@@ -0,0 +1,60 @@
+#ifndef __ARM_CURRENT_H__
+#define __ARM_CURRENT_H__
+
+#include <xen/config.h>
+#include <xen/percpu.h>
+#include <public/xen.h>
+
+#ifndef __ASSEMBLY__
+
+struct vcpu;
+
+struct cpu_info {
+    struct cpu_user_regs guest_cpu_user_regs;
+    unsigned long elr;
+    unsigned int processor_id;
+    struct vcpu *current_vcpu;
+    unsigned long per_cpu_offset;
+};
+
+static inline struct cpu_info *get_cpu_info(void)
+{
+        register unsigned long sp asm ("sp");
+        return (struct cpu_info *)((sp & ~(STACK_SIZE - 1)) + STACK_SIZE - sizeof(struct cpu_info));
+}
+
+#define get_current()         (get_cpu_info()->current_vcpu)
+#define set_current(vcpu)     (get_cpu_info()->current_vcpu = (vcpu))
+#define current               (get_current())
+
+#define get_processor_id()    (get_cpu_info()->processor_id)
+#define set_processor_id(id)  do {                                      \
+    struct cpu_info *ci__ = get_cpu_info();                             \
+    ci__->per_cpu_offset = __per_cpu_offset[ci__->processor_id = (id)]; \
+} while (0)
+
+#define guest_cpu_user_regs() (&get_cpu_info()->guest_cpu_user_regs)
+
+#define reset_stack_and_jump(__fn)              \
+    __asm__ __volatile__ (                      \
+        "mov sp,%0; b "STR(__fn)      \
+        : : "r" (guest_cpu_user_regs()) : "memory" )
+#endif
+
+
+/*
+ * Which VCPU's state is currently running on each CPU?
+ * This is not necesasrily the same as 'current' as a CPU may be
+ * executing a lazy state switch.
+ */
+DECLARE_PER_CPU(struct vcpu *, curr_vcpu);
+
+#endif /* __ARM_CURRENT_H__ */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/debugger.h b/xen/include/asm-arm/debugger.h
new file mode 100644
index 0000000..84b2eec
--- /dev/null
+++ b/xen/include/asm-arm/debugger.h
@@ -0,0 +1,15 @@
+#ifndef __ARM_DEBUGGER_H__
+#define __ARM_DEBUGGER_H__
+
+#define debugger_trap_fatal(v, r) (0)
+#define debugger_trap_immediate() (0)
+
+#endif /* __ARM_DEBUGGER_H__ */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/delay.h b/xen/include/asm-arm/delay.h
new file mode 100644
index 0000000..6250774
--- /dev/null
+++ b/xen/include/asm-arm/delay.h
@@ -0,0 +1,15 @@
+#ifndef _ARM_DELAY_H
+#define _ARM_DELAY_H
+
+extern void __udelay(unsigned long usecs);
+#define udelay(n) __udelay(n)
+
+#endif /* defined(_ARM_DELAY_H) */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/desc.h b/xen/include/asm-arm/desc.h
new file mode 100644
index 0000000..3989e8a
--- /dev/null
+++ b/xen/include/asm-arm/desc.h
@@ -0,0 +1,12 @@
+#ifndef __ARCH_DESC_H
+#define __ARCH_DESC_H
+
+#endif /* __ARCH_DESC_H */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/div64.h b/xen/include/asm-arm/div64.h
new file mode 100644
index 0000000..5f23b65
--- /dev/null
+++ b/xen/include/asm-arm/div64.h
@@ -0,0 +1,241 @@
+/* Taken from Linux arch/arm */
+#ifndef __ASM_ARM_DIV64
+#define __ASM_ARM_DIV64
+
+#include <asm/system.h>
+#include <xen/types.h>
+
+/*
+ * The semantics of do_div() are:
+ *
+ * uint32_t do_div(uint64_t *n, uint32_t base)
+ * {
+ * 	uint32_t remainder = *n % base;
+ * 	*n = *n / base;
+ * 	return remainder;
+ * }
+ *
+ * In other words, a 64-bit dividend with a 32-bit divisor producing
+ * a 64-bit result and a 32-bit remainder.  To accomplish this optimally
+ * we call a special __do_div64 helper with completely non standard
+ * calling convention for arguments and results (beware).
+ */
+
+#ifdef __ARMEB__
+#define __xh "r0"
+#define __xl "r1"
+#else
+#define __xl "r0"
+#define __xh "r1"
+#endif
+
+#define __do_div_asm(n, base)					\
+({								\
+	register unsigned int __base      asm("r4") = base;	\
+	register unsigned long long __n   asm("r0") = n;	\
+	register unsigned long long __res asm("r2");		\
+	register unsigned int __rem       asm(__xh);		\
+	asm(	__asmeq("%0", __xh)				\
+		__asmeq("%1", "r2")				\
+		__asmeq("%2", "r0")				\
+		__asmeq("%3", "r4")				\
+		"bl	__do_div64"				\
+		: "=r" (__rem), "=r" (__res)			\
+		: "r" (__n), "r" (__base)			\
+		: "ip", "lr", "cc");				\
+	n = __res;						\
+	__rem;							\
+})
+
+#if __GNUC__ < 4
+
+/*
+ * gcc versions earlier than 4.0 are simply too problematic for the
+ * optimized implementation below. First there is gcc PR 15089 that
+ * tend to trig on more complex constructs, spurious .global __udivsi3
+ * are inserted even if none of those symbols are referenced in the
+ * generated code, and those gcc versions are not able to do constant
+ * propagation on long long values anyway.
+ */
+#define do_div(n, base) __do_div_asm(n, base)
+
+#elif __GNUC__ >= 4
+
+#include <asm/bug.h>
+
+/*
+ * If the divisor happens to be constant, we determine the appropriate
+ * inverse at compile time to turn the division into a few inline
+ * multiplications instead which is much faster. And yet only if compiling
+ * for ARMv4 or higher (we need umull/umlal) and if the gcc version is
+ * sufficiently recent to perform proper long long constant propagation.
+ * (It is unfortunate that gcc doesn't perform all this internally.)
+ */
+#define do_div(n, base)							\
+({									\
+	unsigned int __r, __b = (base);					\
+	if (!__builtin_constant_p(__b) || __b == 0) {			\
+		/* non-constant divisor (or zero): slow path */		\
+		__r = __do_div_asm(n, __b);				\
+	} else if ((__b & (__b - 1)) == 0) {				\
+		/* Trivial: __b is constant and a power of 2 */		\
+		/* gcc does the right thing with this code.  */		\
+		__r = n;						\
+		__r &= (__b - 1);					\
+		n /= __b;						\
+	} else {							\
+		/* Multiply by inverse of __b: n/b = n*(p/b)/p       */	\
+		/* We rely on the fact that most of this code gets   */	\
+		/* optimized away at compile time due to constant    */	\
+		/* propagation and only a couple inline assembly     */	\
+		/* instructions should remain. Better avoid any      */	\
+		/* code construct that might prevent that.           */	\
+		unsigned long long __res, __x, __t, __m, __n = n;	\
+		unsigned int __c, __p, __z = 0;				\
+		/* preserve low part of n for reminder computation */	\
+		__r = __n;						\
+		/* determine number of bits to represent __b */		\
+		__p = 1 << __div64_fls(__b);				\
+		/* compute __m = ((__p << 64) + __b - 1) / __b */	\
+		__m = (~0ULL / __b) * __p;				\
+		__m += (((~0ULL % __b + 1) * __p) + __b - 1) / __b;	\
+		/* compute __res = __m*(~0ULL/__b*__b-1)/(__p << 64) */	\
+		__x = ~0ULL / __b * __b - 1;				\
+		__res = (__m & 0xffffffff) * (__x & 0xffffffff);	\
+		__res >>= 32;						\
+		__res += (__m & 0xffffffff) * (__x >> 32);		\
+		__t = __res;						\
+		__res += (__x & 0xffffffff) * (__m >> 32);		\
+		__t = (__res < __t) ? (1ULL << 32) : 0;			\
+		__res = (__res >> 32) + __t;				\
+		__res += (__m >> 32) * (__x >> 32);			\
+		__res /= __p;						\
+		/* Now sanitize and optimize what we've got. */		\
+		if (~0ULL % (__b / (__b & -__b)) == 0) {		\
+			/* those cases can be simplified with: */	\
+			__n /= (__b & -__b);				\
+			__m = ~0ULL / (__b / (__b & -__b));		\
+			__p = 1;					\
+			__c = 1;					\
+		} else if (__res != __x / __b) {			\
+			/* We can't get away without a correction    */	\
+			/* to compensate for bit truncation errors.  */	\
+			/* To avoid it we'd need an additional bit   */	\
+			/* to represent __m which would overflow it. */	\
+			/* Instead we do m=p/b and n/b=(n*m+m)/p.    */	\
+			__c = 1;					\
+			/* Compute __m = (__p << 64) / __b */		\
+			__m = (~0ULL / __b) * __p;			\
+			__m += ((~0ULL % __b + 1) * __p) / __b;		\
+		} else {						\
+			/* Reduce __m/__p, and try to clear bit 31   */	\
+			/* of __m when possible otherwise that'll    */	\
+			/* need extra overflow handling later.       */	\
+			unsigned int __bits = -(__m & -__m);		\
+			__bits |= __m >> 32;				\
+			__bits = (~__bits) << 1;			\
+			/* If __bits == 0 then setting bit 31 is     */	\
+			/* unavoidable.  Simply apply the maximum    */	\
+			/* possible reduction in that case.          */	\
+			/* Otherwise the MSB of __bits indicates the */	\
+			/* best reduction we should apply.           */	\
+			if (!__bits) {					\
+				__p /= (__m & -__m);			\
+				__m /= (__m & -__m);			\
+			} else {					\
+				__p >>= __div64_fls(__bits);		\
+				__m >>= __div64_fls(__bits);		\
+			}						\
+			/* No correction needed. */			\
+			__c = 0;					\
+		}							\
+		/* Now we have a combination of 2 conditions:        */	\
+		/* 1) whether or not we need a correction (__c), and */	\
+		/* 2) whether or not there might be an overflow in   */	\
+		/*    the cross product (__m & ((1<<63) | (1<<31)))  */	\
+		/* Select the best insn combination to perform the   */	\
+		/* actual __m * __n / (__p << 64) operation.         */	\
+		if (!__c) {						\
+			asm (	"umull	%Q0, %R0, %1, %Q2\n\t"		\
+				"mov	%Q0, #0"			\
+				: "=&r" (__res)				\
+				: "r" (__m), "r" (__n)			\
+				: "cc" );				\
+		} else if (!(__m & ((1ULL << 63) | (1ULL << 31)))) {	\
+			__res = __m;					\
+			asm (	"umlal	%Q0, %R0, %Q1, %Q2\n\t"		\
+				"mov	%Q0, #0"			\
+				: "+&r" (__res)				\
+				: "r" (__m), "r" (__n)			\
+				: "cc" );				\
+		} else {						\
+			asm (	"umull	%Q0, %R0, %Q1, %Q2\n\t"		\
+				"cmn	%Q0, %Q1\n\t"			\
+				"adcs	%R0, %R0, %R1\n\t"		\
+				"adc	%Q0, %3, #0"			\
+				: "=&r" (__res)				\
+				: "r" (__m), "r" (__n), "r" (__z)	\
+				: "cc" );				\
+		}							\
+		if (!(__m & ((1ULL << 63) | (1ULL << 31)))) {		\
+			asm (	"umlal	%R0, %Q0, %R1, %Q2\n\t"		\
+				"umlal	%R0, %Q0, %Q1, %R2\n\t"		\
+				"mov	%R0, #0\n\t"			\
+				"umlal	%Q0, %R0, %R1, %R2"		\
+				: "+&r" (__res)				\
+				: "r" (__m), "r" (__n)			\
+				: "cc" );				\
+		} else {						\
+			asm (	"umlal	%R0, %Q0, %R2, %Q3\n\t"		\
+				"umlal	%R0, %1, %Q2, %R3\n\t"		\
+				"mov	%R0, #0\n\t"			\
+				"adds	%Q0, %1, %Q0\n\t"		\
+				"adc	%R0, %R0, #0\n\t"		\
+				"umlal	%Q0, %R0, %R2, %R3"		\
+				: "+&r" (__res), "+&r" (__z)		\
+				: "r" (__m), "r" (__n)			\
+				: "cc" );				\
+		}							\
+		__res /= __p;						\
+		/* The reminder can be computed with 32-bit regs     */	\
+		/* only, and gcc is good at that.                    */	\
+		{							\
+			unsigned int __res0 = __res;			\
+			unsigned int __b0 = __b;			\
+			__r -= __res0 * __b0;				\
+		}							\
+		/* BUG_ON(__r >= __b || __res * __b + __r != n); */	\
+		n = __res;						\
+	}								\
+	__r;								\
+})
+
+/* our own fls implementation to make sure constant propagation is fine */
+#define __div64_fls(bits)						\
+({									\
+	unsigned int __left = (bits), __nr = 0;				\
+	if (__left & 0xffff0000) __nr += 16, __left >>= 16;		\
+	if (__left & 0x0000ff00) __nr +=  8, __left >>=  8;		\
+	if (__left & 0x000000f0) __nr +=  4, __left >>=  4;		\
+	if (__left & 0x0000000c) __nr +=  2, __left >>=  2;		\
+	if (__left & 0x00000002) __nr +=  1;				\
+	__nr;								\
+})
+
+#endif
+
+static inline uint64_t div64(uint64_t n, uint32_t base)
+{
+	do_div(n, base);
+	return n;
+}
+
+#endif
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/elf.h b/xen/include/asm-arm/elf.h
new file mode 100644
index 0000000..12d487c
--- /dev/null
+++ b/xen/include/asm-arm/elf.h
@@ -0,0 +1,33 @@
+#ifndef __ARM_ELF_H__
+#define __ARM_ELF_H__
+
+typedef struct {
+    unsigned long r0;
+    unsigned long r1;
+    unsigned long r2;
+    unsigned long r3;
+    unsigned long r4;
+    unsigned long r5;
+    unsigned long r6;
+    unsigned long r7;
+    unsigned long r8;
+    unsigned long r9;
+    unsigned long r10;
+    unsigned long r11;
+    unsigned long r12;
+    unsigned long sp;
+    unsigned long lr;
+    unsigned long pc;
+} ELF_Gregset;
+
+#endif /* __ARM_ELF_H__ */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/event.h b/xen/include/asm-arm/event.h
new file mode 100644
index 0000000..6b2fb7c
--- /dev/null
+++ b/xen/include/asm-arm/event.h
@@ -0,0 +1,41 @@
+#ifndef __ASM_EVENT_H__
+#define __ASM_EVENT_H__
+
+void vcpu_kick(struct vcpu *v);
+void vcpu_mark_events_pending(struct vcpu *v);
+
+static inline int local_events_need_delivery(void)
+{
+    /* TODO
+     * return (vcpu_info(v, evtchn_upcall_pending) &&
+                        !vcpu_info(v, evtchn_upcall_mask)); */
+        return 0;
+}
+
+int local_event_delivery_is_enabled(void);
+
+static inline void local_event_delivery_disable(void)
+{
+    /* TODO current->vcpu_info->evtchn_upcall_mask = 1; */
+}
+
+static inline void local_event_delivery_enable(void)
+{
+    /* TODO current->vcpu_info->evtchn_upcall_mask = 0; */
+}
+
+/* No arch specific virq definition now. Default to global. */
+static inline int arch_virq_is_global(int virq)
+{
+    return 1;
+}
+
+#endif
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/flushtlb.h b/xen/include/asm-arm/flushtlb.h
new file mode 100644
index 0000000..c8486fc
--- /dev/null
+++ b/xen/include/asm-arm/flushtlb.h
@@ -0,0 +1,31 @@
+#ifndef __FLUSHTLB_H__
+#define __FLUSHTLB_H__
+
+#include <xen/cpumask.h>
+
+/*
+ * Filter the given set of CPUs, removing those that definitely flushed their
+ * TLB since @page_timestamp.
+ */
+/* XXX lazy implementation just doesn't clear anything.... */
+#define tlbflush_filter(mask, page_timestamp)                           \
+do {                                                                    \
+} while ( 0 )
+
+#define tlbflush_current_time()                 (0)
+
+/* Flush local TLBs */
+void flush_tlb_local(void);
+
+/* Flush specified CPUs' TLBs */
+void flush_tlb_mask(const cpumask_t *mask);
+
+#endif /* __FLUSHTLB_H__ */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/grant_table.h b/xen/include/asm-arm/grant_table.h
new file mode 100644
index 0000000..8f6ffd8
--- /dev/null
+++ b/xen/include/asm-arm/grant_table.h
@@ -0,0 +1,35 @@
+#ifndef __ASM_GRANT_TABLE_H__
+#define __ASM_GRANT_TABLE_H__
+
+#include <xen/grant_table.h>
+
+#define INVALID_GFN (-1UL)
+#define INITIAL_NR_GRANT_FRAMES 1
+
+void gnttab_clear_flag(unsigned long nr, uint16_t *addr);
+int create_grant_host_mapping(unsigned long gpaddr,
+		unsigned long mfn, unsigned int flags, unsigned int
+		cache_flags);
+#define gnttab_host_mapping_get_page_type(op, d, rd) (0)
+int replace_grant_host_mapping(unsigned long gpaddr, unsigned long mfn,
+		unsigned long new_gpaddr, unsigned int flags);
+void gnttab_mark_dirty(struct domain *d, unsigned long l);
+#define gnttab_create_status_page(d, t, i) (0)
+#define gnttab_create_shared_page(d, t, i) (0)
+#define gnttab_shared_gmfn(d, t, i) (0)
+#define gnttab_status_gmfn(d, t, i) (0)
+#define gnttab_release_host_mappings(domain) 1
+static inline int replace_grant_supported(void)
+{
+    return 1;
+}
+
+#endif /* __ASM_GRANT_TABLE_H__ */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/hardirq.h b/xen/include/asm-arm/hardirq.h
new file mode 100644
index 0000000..9c031a8
--- /dev/null
+++ b/xen/include/asm-arm/hardirq.h
@@ -0,0 +1,28 @@
+#ifndef __ASM_HARDIRQ_H
+#define __ASM_HARDIRQ_H
+
+#include <xen/config.h>
+#include <xen/cache.h>
+#include <xen/smp.h>
+
+typedef struct {
+        unsigned long __softirq_pending;
+        unsigned int __local_irq_count;
+} __cacheline_aligned irq_cpustat_t;
+
+#include <xen/irq_cpustat.h>    /* Standard mappings for irq_cpustat_t above */
+
+#define in_irq() (local_irq_count(smp_processor_id()) != 0)
+
+#define irq_enter()     (local_irq_count(smp_processor_id())++)
+#define irq_exit()      (local_irq_count(smp_processor_id())--)
+
+#endif /* __ASM_HARDIRQ_H */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/hypercall.h b/xen/include/asm-arm/hypercall.h
new file mode 100644
index 0000000..90a87ef
--- /dev/null
+++ b/xen/include/asm-arm/hypercall.h
@@ -0,0 +1,24 @@
+#ifndef __ASM_ARM_HYPERCALL_H__
+#define __ASM_ARM_HYPERCALL_H__
+
+#include <public/domctl.h> /* for arch_do_domctl */
+
+struct vcpu;
+extern long
+arch_do_vcpu_op(
+    int cmd, struct vcpu *v, XEN_GUEST_HANDLE(void) arg);
+
+extern long
+arch_do_sysctl(
+    struct xen_sysctl *op,
+    XEN_GUEST_HANDLE(xen_sysctl_t) u_sysctl);
+
+#endif /* __ASM_ARM_HYPERCALL_H__ */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/init.h b/xen/include/asm-arm/init.h
new file mode 100644
index 0000000..5f44929
--- /dev/null
+++ b/xen/include/asm-arm/init.h
@@ -0,0 +1,12 @@
+#ifndef _XEN_ASM_INIT_H
+#define _XEN_ASM_INIT_H
+
+#endif /* _XEN_ASM_INIT_H */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/io.h b/xen/include/asm-arm/io.h
new file mode 100644
index 0000000..1babbab
--- /dev/null
+++ b/xen/include/asm-arm/io.h
@@ -0,0 +1,12 @@
+#ifndef _ASM_IO_H
+#define _ASM_IO_H
+
+#endif
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/iocap.h b/xen/include/asm-arm/iocap.h
new file mode 100644
index 0000000..f647f30
--- /dev/null
+++ b/xen/include/asm-arm/iocap.h
@@ -0,0 +1,20 @@
+#ifndef __X86_IOCAP_H__
+#define __X86_IOCAP_H__
+
+#define cache_flush_permitted(d)                        \
+    (!rangeset_is_empty((d)->iomem_caps))
+
+#define multipage_allocation_permitted(d, order)        \
+    (((order) <= 9) || /* allow 2MB superpages */       \
+     !rangeset_is_empty((d)->iomem_caps))
+
+#endif
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/multicall.h b/xen/include/asm-arm/multicall.h
new file mode 100644
index 0000000..c800940
--- /dev/null
+++ b/xen/include/asm-arm/multicall.h
@@ -0,0 +1,23 @@
+#ifndef __ASM_ARM_MULTICALL_H__
+#define __ASM_ARM_MULTICALL_H__
+
+#define do_multicall_call(_call)                             \
+    do {                                                     \
+        __asm__ __volatile__ (                               \
+            ".word 0xe7f000f0@; do_multicall_call\n"         \
+            "    mov r0,#0; @ do_multicall_call\n"           \
+            "    str r0, [r0];\n"                            \
+            :                                                \
+            :                                                \
+            : );                                             \
+    } while ( 0 )
+
+#endif /* __ASM_ARM_MULTICALL_H__ */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/nmi.h b/xen/include/asm-arm/nmi.h
new file mode 100644
index 0000000..e0f19f9
--- /dev/null
+++ b/xen/include/asm-arm/nmi.h
@@ -0,0 +1,15 @@
+#ifndef ASM_NMI_H
+#define ASM_NMI_H
+
+#define register_guest_nmi_callback(a)  (-ENOSYS)
+#define unregister_guest_nmi_callback() (-ENOSYS)
+
+#endif /* ASM_NMI_H */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/numa.h b/xen/include/asm-arm/numa.h
new file mode 100644
index 0000000..cffee5c
--- /dev/null
+++ b/xen/include/asm-arm/numa.h
@@ -0,0 +1,21 @@
+#ifndef __ARCH_ARM_NUMA_H
+#define __ARCH_ARM_NUMA_H
+
+/* Fake one node for now... */
+#define cpu_to_node(cpu) 0
+#define node_to_cpumask(node)	(cpu_online_map)
+
+static inline __attribute__((pure)) int phys_to_nid(paddr_t addr)
+{
+        return 0;
+}
+
+#endif /* __ARCH_ARM_NUMA_H */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/paging.h b/xen/include/asm-arm/paging.h
new file mode 100644
index 0000000..4dc340f
--- /dev/null
+++ b/xen/include/asm-arm/paging.h
@@ -0,0 +1,13 @@
+#ifndef _XEN_PAGING_H
+#define _XEN_PAGING_H
+
+#endif /* XEN_PAGING_H */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/percpu.h b/xen/include/asm-arm/percpu.h
new file mode 100644
index 0000000..9d369eb
--- /dev/null
+++ b/xen/include/asm-arm/percpu.h
@@ -0,0 +1,28 @@
+#ifndef __ARM_PERCPU_H__
+#define __ARM_PERCPU_H__
+
+#ifndef __ASSEMBLY__
+extern char __per_cpu_start[], __per_cpu_data_end[];
+extern unsigned long __per_cpu_offset[NR_CPUS];
+void percpu_init_areas(void);
+#endif
+
+/* Separate out the type, so (int[3], foo) works. */
+#define __DEFINE_PER_CPU(type, name, suffix)                    \
+    __attribute__((__section__(".bss.percpu" #suffix)))         \
+    __typeof__(type) per_cpu_##name
+
+#define per_cpu(var, cpu) ((&per_cpu__##var)[cpu?0:0])
+#define __get_cpu_var(var) per_cpu__##var
+
+#define DECLARE_PER_CPU(type, name) extern __typeof__(type) per_cpu__##name
+
+#endif /* __ARM_PERCPU_H__ */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/processor.h b/xen/include/asm-arm/processor.h
new file mode 100644
index 0000000..1f85d31
--- /dev/null
+++ b/xen/include/asm-arm/processor.h
@@ -0,0 +1,269 @@
+#ifndef __ASM_ARM_PROCESSOR_H
+#define __ASM_ARM_PROCESSOR_H
+
+#include <asm/cpregs.h>
+
+/* PSR bits (CPSR, SPSR)*/
+
+/* 0-4: Mode */
+#define PSR_MODE_MASK 0x1f
+#define PSR_MODE_USR 0x10
+#define PSR_MODE_FIQ 0x11
+#define PSR_MODE_IRQ 0x12
+#define PSR_MODE_SVC 0x13
+#define PSR_MODE_MON 0x16
+#define PSR_MODE_ABT 0x17
+#define PSR_MODE_HYP 0x1a
+#define PSR_MODE_UND 0x1b
+#define PSR_MODE_SYS 0x1f
+
+#define PSR_THUMB        (1<<5)        /* Thumb Mode enable */
+#define PSR_FIQ_MASK        (1<<6)        /* Fast Interrupt mask */
+#define PSR_IRQ_MASK        (1<<7)        /* Interrupt mask */
+#define PSR_ABT_MASK         (1<<8)        /* Asynchronous Abort mask */
+#define PSR_BIG_ENDIAN        (1<<9)        /* Big Endian Mode */
+#define PSR_JAZELLE        (1<<24)        /* Jazelle Mode */
+
+/* TTBCR Translation Table Base Control Register */
+#define TTBCR_N_MASK 0x07
+#define TTBCR_N_16KB 0x00
+#define TTBCR_N_8KB  0x01
+#define TTBCR_N_4KB  0x02
+#define TTBCR_N_2KB  0x03
+#define TTBCR_N_1KB  0x04
+
+/* SCTLR System Control Register. */
+/* HSCTLR is a subset of this. */
+#define SCTLR_TE        (1<<30)
+#define SCTLR_AFE        (1<<29)
+#define SCTLR_TRE        (1<<28)
+#define SCTLR_NMFI        (1<<27)
+#define SCTLR_EE        (1<<25)
+#define SCTLR_VE        (1<<24)
+#define SCTLR_U                (1<<22)
+#define SCTLR_FI        (1<<21)
+#define SCTLR_WXN        (1<<19)
+#define SCTLR_HA        (1<<17)
+#define SCTLR_RR        (1<<14)
+#define SCTLR_V                (1<<13)
+#define SCTLR_I                (1<<12)
+#define SCTLR_Z                (1<<11)
+#define SCTLR_SW        (1<<10)
+#define SCTLR_B                (1<<7)
+#define SCTLR_C                (1<<2)
+#define SCTLR_A                (1<<1)
+#define SCTLR_M                (1<<0)
+
+#define SCTLR_BASE        0x00c50078
+#define HSCTLR_BASE        0x30c51878
+
+/* HCR Hyp Configuration Register */
+#define HCR_TGE                (1<<27)
+#define HCR_TVM                (1<<26)
+#define HCR_TTLB        (1<<25)
+#define HCR_TPU                (1<<24)
+#define HCR_TPC                (1<<23)
+#define HCR_TSW                (1<<22)
+#define HCR_TAC                (1<<21)
+#define HCR_TIDCP        (1<<20)
+#define HCR_TSC                (1<<19)
+#define HCR_TID3        (1<<18)
+#define HCR_TID2        (1<<17)
+#define HCR_TID1        (1<<16)
+#define HCR_TID0        (1<<15)
+#define HCR_TWE                (1<<14)
+#define HCR_TWI                (1<<13)
+#define HCR_DC                (1<<12)
+#define HCR_BSU_MASK        (3<<10)
+#define HCR_FB                (1<<9)
+#define HCR_VA                (1<<8)
+#define HCR_VI                (1<<7)
+#define HCR_VF                (1<<6)
+#define HCR_AMO                (1<<5)
+#define HCR_IMO                (1<<4)
+#define HCR_FMO                (1<<3)
+#define HCR_PTW                (1<<2)
+#define HCR_SWIO        (1<<1)
+#define HCR_VM                (1<<0)
+
+#define HSR_EC_WFI_WFE              0x01
+#define HSR_EC_CP15_32              0x03
+#define HSR_EC_CP15_64              0x04
+#define HSR_EC_CP14_32              0x05
+#define HSR_EC_CP14_DBG             0x06
+#define HSR_EC_CP                   0x07
+#define HSR_EC_CP10                 0x08
+#define HSR_EC_JAZELLE              0x09
+#define HSR_EC_BXJ                  0x0a
+#define HSR_EC_CP14_64              0x0c
+#define HSR_EC_SVC                  0x11
+#define HSR_EC_HVC                  0x12
+#define HSR_EC_INSTR_ABORT_GUEST    0x20
+#define HSR_EC_INSTR_ABORT_HYP      0x21
+#define HSR_EC_DATA_ABORT_GUEST     0x24
+#define HSR_EC_DATA_ABORT_HYP       0x25
+
+#ifndef __ASSEMBLY__
+union hsr {
+    uint32_t bits;
+    struct {
+        unsigned long iss:25;  /* Instruction Specific Syndrome */
+        unsigned long len:1;   /* Instruction length */
+        unsigned long ec:6;    /* Exception Class */
+    };
+
+    struct hsr_cp32 {
+        unsigned long read:1;  /* Direction */
+        unsigned long crm:4;   /* CRm */
+        unsigned long reg:4;   /* Rt */
+        unsigned long sbzp:1;
+        unsigned long crn:4;   /* CRn */
+        unsigned long op1:3;   /* Op1 */
+        unsigned long op2:3;   /* Op2 */
+        unsigned long cc:4;    /* Condition Code */
+        unsigned long ccvalid:1;/* CC Valid */
+        unsigned long len:1;   /* Instruction length */
+        unsigned long ec:6;    /* Exception Class */
+    } cp32; /* HSR_EC_CP15_32, CP14_32, CP10 */
+
+    struct hsr_cp64 {
+        unsigned long read:1;   /* Direction */
+        unsigned long crm:4;    /* CRm */
+        unsigned long reg1:4;   /* Rt1 */
+        unsigned long sbzp1:1;
+        unsigned long reg2:4;   /* Rt2 */
+        unsigned long sbzp2:2;
+        unsigned long op1:4;   /* Op1 */
+        unsigned long cc:4;    /* Condition Code */
+        unsigned long ccvalid:1;/* CC Valid */
+        unsigned long len:1;   /* Instruction length */
+        unsigned long ec:6;    /* Exception Class */
+    } cp64; /* HSR_EC_CP15_64, HSR_EC_CP14_64 */
+
+    struct hsr_dabt {
+        unsigned long dfsc:6;  /* Data Fault Status Code */
+        unsigned long write:1; /* Write / not Read */
+        unsigned long s1ptw:1; /* */
+        unsigned long cache:1; /* Cache Maintenance */
+        unsigned long eat:1;   /* External Abort Type */
+        unsigned long sbzp0:6;
+        unsigned long reg:4;   /* Register */
+        unsigned long sbzp1:1;
+        unsigned long sign:1;  /* Sign extend */
+        unsigned long size:2;  /* Access Size */
+        unsigned long valid:1; /* Syndrome Valid */
+        unsigned long len:1;   /* Instruction length */
+        unsigned long ec:6;    /* Exception Class */
+    } dabt; /* HSR_EC_DATA_ABORT_* */
+};
+#endif
+
+/* HSR.EC == HSR_CP{15,14,10}_32 */
+#define HSR_CP32_OP2_MASK (0x000e0000)
+#define HSR_CP32_OP2_SHIFT (17)
+#define HSR_CP32_OP1_MASK (0x0001c000)
+#define HSR_CP32_OP1_SHIFT (14)
+#define HSR_CP32_CRN_MASK (0x00003c00)
+#define HSR_CP32_CRN_SHIFT (10)
+#define HSR_CP32_CRM_MASK (0x0000001e)
+#define HSR_CP32_CRM_SHIFT (1)
+#define HSR_CP32_REGS_MASK (HSR_CP32_OP1_MASK|HSR_CP32_OP2_MASK|\
+                            HSR_CP32_CRN_MASK|HSR_CP32_CRM_MASK)
+
+/* HSR.EC == HSR_CP{15,14}_64 */
+#define HSR_CP64_OP1_MASK (0x000f0000)
+#define HSR_CP64_OP1_SHIFT (16)
+#define HSR_CP64_CRM_MASK (0x0000001e)
+#define HSR_CP64_CRM_SHIFT (1)
+#define HSR_CP64_REGS_MASK (HSR_CP64_OP1_MASK|HSR_CP64_CRM_MASK)
+
+/* Physical Address Register */
+#define PAR_F           (1<<0)
+
+/* .... If F == 1 */
+#define PAR_FSC_SHIFT   (1)
+#define PAR_FSC_MASK    (0x3f<<PAR_FSC_SHIFT)
+#define PAR_STAGE21     (1<<8)     /* Stage 2 Fault During Stage 1 Walk */
+#define PAR_STAGE2      (1<<9)     /* Stage 2 Fault */
+
+/* If F == 0 */
+#define PAR_MAIR_SHIFT  56                       /* Memory Attributes */
+#define PAR_MAIR_MASK   (0xffLL<<PAR_MAIR_SHIFT)
+#define PAR_NS          (1<<9)                   /* Non-Secure */
+#define PAR_SH_SHIFT    7                        /* Shareability */
+#define PAR_SH_MASK     (3<<PAR_SH_SHIFT)
+
+/* Fault Status Register */
+/*
+ * 543210 BIT
+ * 00XXLL -- XX Fault Level LL
+ * ..01LL -- Translation Fault LL
+ * ..10LL -- Access Fault LL
+ * ..11LL -- Permission Fault LL
+ * 01xxxx -- Abort/Parity
+ * 10xxxx -- Other
+ * 11xxxx -- Implementation Defined
+ */
+#define FSC_TYPE_MASK (0x3<<4)
+#define FSC_TYPE_FAULT (0x00<<4)
+#define FSC_TYPE_ABT   (0x01<<4)
+#define FSC_TYPE_OTH   (0x02<<4)
+#define FSC_TYPE_IMPL  (0x03<<4)
+
+#define FSC_FLT_TRANS  (0x04)
+#define FSC_FLT_ACCESS (0x08)
+#define FSC_FLT_PERM   (0x0c)
+#define FSC_SEA        (0x10) /* Synchronous External Abort */
+#define FSC_SPE        (0x18) /* Memory Access Synchronous Parity Error */
+#define FSC_APE        (0x11) /* Memory Access Asynchronous Parity Error */
+#define FSC_SEATT      (0x14) /* Sync. Ext. Abort Translation Table */
+#define FSC_SPETT      (0x1c) /* Sync. Parity. Error Translation Table */
+#define FSC_AF         (0x21) /* Alignment Fault */
+#define FSC_DE         (0x22) /* Debug Event */
+#define FSC_LKD        (0x34) /* Lockdown Abort */
+#define FSC_CPR        (0x3a) /* Coprocossor Abort */
+
+#define FSC_LL_MASK    (0x03<<0)
+
+/* Time counter hypervisor control register */
+#define CNTHCTL_PA      (1u<<0)  /* Kernel/user access to physical counter */
+#define CNTHCTL_TA      (1u<<1)  /* Kernel/user access to CNTP timer */
+
+/* Timer control registers */
+#define CNTx_CTL_ENABLE   (1u<<0)  /* Enable timer */
+#define CNTx_CTL_MASK     (1u<<1)  /* Mask IRQ */
+#define CNTx_CTL_PENDING  (1u<<2)  /* IRQ pending */
+
+/* CPUID bits */
+#define ID_PFR1_GT_MASK  0x000F0000  /* Generic Timer interface support */
+#define ID_PFR1_GT_v1    0x00010000
+
+#define MSR(reg,val)        asm volatile ("msr "#reg", %0\n" : : "r" (val))
+#define MRS(val,reg)        asm volatile ("mrs %0,"#reg"\n" : "=r" (v))
+
+#ifndef __ASSEMBLY__
+extern uint32_t hyp_traps_vector[8];
+
+void panic_PAR(uint64_t par, const char *when);
+
+void show_execution_state(struct cpu_user_regs *regs);
+void show_registers(struct cpu_user_regs *regs);
+//#define dump_execution_state() run_in_exception_handler(show_execution_state)
+#define dump_execution_state() asm volatile (".word 0xe7f000f0\n"); /* XXX */
+
+#define cpu_relax() barrier() /* Could yield? */
+
+/* All a bit UP for the moment */
+#define cpu_to_core(_cpu)   (0)
+#define cpu_to_socket(_cpu) (0)
+
+#endif /* __ASSEMBLY__ */
+#endif /* __ASM_ARM_PROCESSOR_H */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/regs.h b/xen/include/asm-arm/regs.h
new file mode 100644
index 0000000..ee095bf
--- /dev/null
+++ b/xen/include/asm-arm/regs.h
@@ -0,0 +1,43 @@
+#ifndef __ARM_REGS_H__
+#define __ARM_REGS_H__
+
+#include <xen/types.h>
+#include <public/xen.h>
+#include <asm/processor.h>
+
+#define psr_mode(psr,m) (((psr) & PSR_MODE_MASK) == m)
+
+#define usr_mode(r)     psr_mode((r)->cpsr,PSR_MODE_USR)
+#define fiq_mode(r)     psr_mode((r)->cpsr,PSR_MODE_FIQ)
+#define irq_mode(r)     psr_mode((r)->cpsr,PSR_MODE_IRQ)
+#define svc_mode(r)     psr_mode((r)->cpsr,PSR_MODE_SVC)
+#define mon_mode(r)     psr_mode((r)->cpsr,PSR_MODE_MON)
+#define abt_mode(r)     psr_mode((r)->cpsr,PSR_MODE_ABT)
+#define hyp_mode(r)     psr_mode((r)->cpsr,PSR_MODE_HYP)
+#define und_mode(r)     psr_mode((r)->cpsr,PSR_MODE_UND)
+#define sys_mode(r)     psr_mode((r)->cpsr,PSR_MODE_SYS)
+
+#define guest_mode(r)                                                         \
+({                                                                            \
+    unsigned long diff = (char *)guest_cpu_user_regs() - (char *)(r);         \
+    /* Frame pointer must point into current CPU stack. */                    \
+    ASSERT(diff < STACK_SIZE);                                                \
+    /* If not a guest frame, it must be a hypervisor frame. */                \
+    ASSERT((diff == 0) || hyp_mode(r));                                       \
+    /* Return TRUE if it's a guest frame. */                                  \
+    (diff == 0);                                                              \
+})
+
+#define return_reg(v) ((v)->arch.user_regs.r0)
+
+#define CTXT_SWITCH_STACK_BYTES (sizeof(struct cpu_user_regs))
+
+#endif /* __ARM_REGS_H__ */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/setup.h b/xen/include/asm-arm/setup.h
new file mode 100644
index 0000000..c27d438
--- /dev/null
+++ b/xen/include/asm-arm/setup.h
@@ -0,0 +1,16 @@
+#ifndef __ARM_SETUP_H_
+#define __ARM_SETUP_H_
+
+#include <public/version.h>
+
+void arch_get_xen_caps(xen_capabilities_info_t *info);
+
+#endif
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/smp.h b/xen/include/asm-arm/smp.h
new file mode 100644
index 0000000..9cdd87f
--- /dev/null
+++ b/xen/include/asm-arm/smp.h
@@ -0,0 +1,25 @@
+#ifndef __ASM_SMP_H
+#define __ASM_SMP_H
+
+#ifndef __ASSEMBLY__
+#include <xen/config.h>
+#include <xen/cpumask.h>
+#include <asm/current.h>
+#endif
+
+DECLARE_PER_CPU(cpumask_var_t, cpu_sibling_mask);
+DECLARE_PER_CPU(cpumask_var_t, cpu_core_mask);
+
+#define cpu_is_offline(cpu) unlikely(!cpu_online(cpu))
+
+#define raw_smp_processor_id() (get_processor_id())
+
+#endif
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/softirq.h b/xen/include/asm-arm/softirq.h
new file mode 100644
index 0000000..536af38
--- /dev/null
+++ b/xen/include/asm-arm/softirq.h
@@ -0,0 +1,15 @@
+#ifndef __ASM_SOFTIRQ_H__
+#define __ASM_SOFTIRQ_H__
+
+#define VGIC_SOFTIRQ        (NR_COMMON_SOFTIRQS + 0)
+#define NR_ARCH_SOFTIRQS       1
+
+#endif /* __ASM_SOFTIRQ_H__ */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/spinlock.h b/xen/include/asm-arm/spinlock.h
new file mode 100644
index 0000000..b1825c9
--- /dev/null
+++ b/xen/include/asm-arm/spinlock.h
@@ -0,0 +1,144 @@
+#ifndef __ASM_SPINLOCK_H
+#define __ASM_SPINLOCK_H
+
+#include <xen/config.h>
+#include <xen/lib.h>
+
+static inline void dsb_sev(void)
+{
+    __asm__ __volatile__ (
+        "dsb\n"
+        "sev\n"
+        );
+}
+
+typedef struct {
+    volatile unsigned int lock;
+} raw_spinlock_t;
+
+#define _RAW_SPIN_LOCK_UNLOCKED { 0 }
+
+#define _raw_spin_is_locked(x)          ((x)->lock != 0)
+
+static always_inline void _raw_spin_unlock(raw_spinlock_t *lock)
+{
+    ASSERT(_raw_spin_is_locked(lock));
+
+    smp_mb();
+
+    __asm__ __volatile__(
+"   str     %1, [%0]\n"
+    :
+    : "r" (&lock->lock), "r" (0)
+    : "cc");
+
+    dsb_sev();
+}
+
+static always_inline int _raw_spin_trylock(raw_spinlock_t *lock)
+{
+    unsigned long tmp;
+
+    __asm__ __volatile__(
+"   ldrex   %0, [%1]\n"
+"   teq     %0, #0\n"
+"   strexeq %0, %2, [%1]"
+    : "=&r" (tmp)
+    : "r" (&lock->lock), "r" (1)
+    : "cc");
+
+    if (tmp == 0) {
+        smp_mb();
+        return 1;
+    } else {
+        return 0;
+    }
+}
+
+typedef struct {
+    volatile unsigned int lock;
+} raw_rwlock_t;
+
+#define _RAW_RW_LOCK_UNLOCKED { 0 }
+
+static always_inline int _raw_read_trylock(raw_rwlock_t *rw)
+{
+    unsigned long tmp, tmp2 = 1;
+
+    __asm__ __volatile__(
+"1: ldrex   %0, [%2]\n"
+"   adds    %0, %0, #1\n"
+"   strexpl %1, %0, [%2]\n"
+    : "=&r" (tmp), "+r" (tmp2)
+    : "r" (&rw->lock)
+    : "cc");
+
+    smp_mb();
+    return tmp2 == 0;
+}
+
+static always_inline int _raw_write_trylock(raw_rwlock_t *rw)
+{
+    unsigned long tmp;
+
+    __asm__ __volatile__(
+"1: ldrex   %0, [%1]\n"
+"   teq     %0, #0\n"
+"   strexeq %0, %2, [%1]"
+    : "=&r" (tmp)
+    : "r" (&rw->lock), "r" (0x80000000)
+    : "cc");
+
+    if (tmp == 0) {
+        smp_mb();
+        return 1;
+    } else {
+        return 0;
+    }
+}
+
+static inline void _raw_read_unlock(raw_rwlock_t *rw)
+{
+    unsigned long tmp, tmp2;
+
+    smp_mb();
+
+    __asm__ __volatile__(
+"1: ldrex   %0, [%2]\n"
+"   sub     %0, %0, #1\n"
+"   strex   %1, %0, [%2]\n"
+"   teq     %1, #0\n"
+"   bne     1b"
+    : "=&r" (tmp), "=&r" (tmp2)
+    : "r" (&rw->lock)
+    : "cc");
+
+    if (tmp == 0)
+        dsb_sev();
+}
+
+static inline void _raw_write_unlock(raw_rwlock_t *rw)
+{
+    smp_mb();
+
+    __asm__ __volatile__(
+    "str    %1, [%0]\n"
+    :
+    : "r" (&rw->lock), "r" (0)
+    : "cc");
+
+    dsb_sev();
+}
+
+#define _raw_rw_is_locked(x) ((x)->lock != 0)
+#define _raw_rw_is_write_locked(x) ((x)->lock == 0x80000000)
+
+#endif /* __ASM_SPINLOCK_H */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/string.h b/xen/include/asm-arm/string.h
new file mode 100644
index 0000000..f2d643d
--- /dev/null
+++ b/xen/include/asm-arm/string.h
@@ -0,0 +1,38 @@
+#ifndef __ARM_STRING_H__
+#define __ARM_STRING_H__
+
+#include <xen/config.h>
+
+#define __HAVE_ARCH_MEMCPY
+extern void * memcpy(void *, const void *, __kernel_size_t);
+
+/* Some versions of gcc don't have this builtin. It's non-critical anyway. */
+#define __HAVE_ARCH_MEMMOVE
+extern void *memmove(void *dest, const void *src, size_t n);
+
+#define __HAVE_ARCH_MEMSET
+extern void * memset(void *, int, __kernel_size_t);
+
+extern void __memzero(void *ptr, __kernel_size_t n);
+
+#define memset(p,v,n)                                                   \
+        ({                                                              \
+                void *__p = (p); size_t __n = n;                        \
+                if ((__n) != 0) {                                       \
+                        if (__builtin_constant_p((v)) && (v) == 0)      \
+                                __memzero((__p),(__n));                 \
+                        else                                            \
+                                memset((__p),(v),(__n));                \
+                }                                                       \
+                (__p);                                                  \
+        })
+
+#endif /* __ARM_STRING_H__ */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/system.h b/xen/include/asm-arm/system.h
new file mode 100644
index 0000000..731d89f
--- /dev/null
+++ b/xen/include/asm-arm/system.h
@@ -0,0 +1,202 @@
+/* Portions taken from Linux arch arm */
+#ifndef __ASM_SYSTEM_H
+#define __ASM_SYSTEM_H
+
+#include <xen/lib.h>
+#include <asm/processor.h>
+
+#define nop() \
+    asm volatile ( "nop" )
+
+#define xchg(ptr,x) \
+        ((__typeof__(*(ptr)))__xchg((unsigned long)(x),(ptr),sizeof(*(ptr))))
+
+#define isb() __asm__ __volatile__ ("isb" : : : "memory")
+#define dsb() __asm__ __volatile__ ("dsb" : : : "memory")
+#define dmb() __asm__ __volatile__ ("dmb" : : : "memory")
+
+#define mb()            dsb()
+#define rmb()           dsb()
+#define wmb()           mb()
+
+#define smp_mb()        dmb()
+#define smp_rmb()       dmb()
+#define smp_wmb()       dmb()
+
+/*
+ * This is used to ensure the compiler did actually allocate the register we
+ * asked it for some inline assembly sequences.  Apparently we can't trust
+ * the compiler from one version to another so a bit of paranoia won't hurt.
+ * This string is meant to be concatenated with the inline asm string and
+ * will cause compilation to stop on mismatch.
+ * (for details, see gcc PR 15089)
+ */
+#define __asmeq(x, y)  ".ifnc " x "," y " ; .err ; .endif\n\t"
+
+extern void __bad_xchg(volatile void *, int);
+
+static inline unsigned long __xchg(unsigned long x, volatile void *ptr, int size)
+{
+        unsigned long ret;
+        unsigned int tmp;
+
+        smp_mb();
+
+        switch (size) {
+        case 1:
+                asm volatile("@ __xchg1\n"
+                "1:     ldrexb  %0, [%3]\n"
+                "       strexb  %1, %2, [%3]\n"
+                "       teq     %1, #0\n"
+                "       bne     1b"
+                        : "=&r" (ret), "=&r" (tmp)
+                        : "r" (x), "r" (ptr)
+                        : "memory", "cc");
+                break;
+        case 4:
+                asm volatile("@ __xchg4\n"
+                "1:     ldrex   %0, [%3]\n"
+                "       strex   %1, %2, [%3]\n"
+                "       teq     %1, #0\n"
+                "       bne     1b"
+                        : "=&r" (ret), "=&r" (tmp)
+                        : "r" (x), "r" (ptr)
+                        : "memory", "cc");
+                break;
+        default:
+                __bad_xchg(ptr, size), ret = 0;
+                break;
+        }
+        smp_mb();
+
+        return ret;
+}
+
+/*
+ * Atomic compare and exchange.  Compare OLD with MEM, if identical,
+ * store NEW in MEM.  Return the initial value in MEM.  Success is
+ * indicated by comparing RETURN with OLD.
+ */
+
+extern void __bad_cmpxchg(volatile void *ptr, int size);
+
+static always_inline unsigned long __cmpxchg(
+    volatile void *ptr, unsigned long old, unsigned long new, int size)
+{
+    unsigned long /*long*/ oldval, res;
+
+    switch (size) {
+    case 1:
+        do {
+            asm volatile("@ __cmpxchg1\n"
+                         "       ldrexb  %1, [%2]\n"
+                         "       mov     %0, #0\n"
+                         "       teq     %1, %3\n"
+                         "       strexbeq %0, %4, [%2]\n"
+                         : "=&r" (res), "=&r" (oldval)
+                         : "r" (ptr), "Ir" (old), "r" (new)
+                         : "memory", "cc");
+        } while (res);
+        break;
+    case 2:
+        do {
+            asm volatile("@ __cmpxchg2\n"
+                         "       ldrexh  %1, [%2]\n"
+                         "       mov     %0, #0\n"
+                         "       teq     %1, %3\n"
+                         "       strexheq %0, %4, [%2]\n"
+                         : "=&r" (res), "=&r" (oldval)
+                         : "r" (ptr), "Ir" (old), "r" (new)
+                         : "memory", "cc");
+        } while (res);
+        break;
+    case 4:
+        do {
+            asm volatile("@ __cmpxchg4\n"
+                         "       ldrex   %1, [%2]\n"
+                         "       mov     %0, #0\n"
+                         "       teq     %1, %3\n"
+                         "       strexeq %0, %4, [%2]\n"
+                         : "=&r" (res), "=&r" (oldval)
+                         : "r" (ptr), "Ir" (old), "r" (new)
+                         : "memory", "cc");
+        } while (res);
+        break;
+#if 0
+    case 8:
+        do {
+            asm volatile("@ __cmpxchg8\n"
+                         "       ldrexd   %1, [%2]\n"
+                         "       mov      %0, #0\n"
+                         "       teq      %1, %3\n"
+                         "       strexdeq %0, %4, [%2]\n"
+                         : "=&r" (res), "=&r" (oldval)
+                         : "r" (ptr), "Ir" (old), "r" (new)
+                         : "memory", "cc");
+        } while (res);
+        break;
+#endif
+    default:
+        __bad_cmpxchg(ptr, size);
+        oldval = 0;
+    }
+
+    return oldval;
+}
+#define cmpxchg(ptr,o,n)                                                \
+    ((__typeof__(*(ptr)))__cmpxchg((ptr),(unsigned long)(o),            \
+                                   (unsigned long)(n),sizeof(*(ptr))))
+
+#define local_irq_disable() asm volatile ( "cpsid i @ local_irq_disable\n" : : : "cc" )
+#define local_irq_enable()  asm volatile ( "cpsie i @ local_irq_enable\n" : : : "cc" )
+
+#define local_save_flags(x)                                      \
+({                                                               \
+    BUILD_BUG_ON(sizeof(x) != sizeof(long));                     \
+    asm volatile ( "mrs %0, cpsr     @ local_save_flags\n"       \
+                  : "=r" (x) :: "memory", "cc" );                \
+})
+#define local_irq_save(x)                                        \
+({                                                               \
+    local_save_flags(x);                                         \
+    local_irq_disable();                                         \
+})
+#define local_irq_restore(x)                                     \
+({                                                               \
+    BUILD_BUG_ON(sizeof(x) != sizeof(long));                     \
+    asm volatile (                                               \
+            "msr     cpsr_c, %0      @ local_irq_restore\n"      \
+            :                                                    \
+            : "r" (flags)                                        \
+            : "memory", "cc");                                   \
+})
+
+static inline int local_irq_is_enabled(void)
+{
+    unsigned long flags;
+    local_save_flags(flags);
+    return !(flags & PSR_IRQ_MASK);
+}
+
+#define local_fiq_enable()  __asm__("cpsie f   @ __stf\n" : : : "memory", "cc")
+#define local_fiq_disable() __asm__("cpsid f   @ __clf\n" : : : "memory", "cc")
+
+#define local_abort_enable() __asm__("cpsie a  @ __sta\n" : : : "memory", "cc")
+#define local_abort_disable() __asm__("cpsid a @ __sta\n" : : : "memory", "cc")
+
+static inline int local_fiq_is_enabled(void)
+{
+    unsigned long flags;
+    local_save_flags(flags);
+    return !!(flags & PSR_FIQ_MASK);
+}
+
+#endif
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/trace.h b/xen/include/asm-arm/trace.h
new file mode 100644
index 0000000..db84541
--- /dev/null
+++ b/xen/include/asm-arm/trace.h
@@ -0,0 +1,12 @@
+#ifndef __ASM_TRACE_H__
+#define __ASM_TRACE_H__
+
+#endif /* __ASM_TRACE_H__ */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/types.h b/xen/include/asm-arm/types.h
new file mode 100644
index 0000000..48864f9
--- /dev/null
+++ b/xen/include/asm-arm/types.h
@@ -0,0 +1,57 @@
+#ifndef __ARM_TYPES_H__
+#define __ARM_TYPES_H__
+
+#ifndef __ASSEMBLY__
+
+#include <xen/config.h>
+
+typedef __signed__ char __s8;
+typedef unsigned char __u8;
+
+typedef __signed__ short __s16;
+typedef unsigned short __u16;
+
+typedef __signed__ int __s32;
+typedef unsigned int __u32;
+
+#if defined(__GNUC__) && !defined(__STRICT_ANSI__)
+typedef __signed__ long long __s64;
+typedef unsigned long long __u64;
+#endif
+
+typedef signed char s8;
+typedef unsigned char u8;
+
+typedef signed short s16;
+typedef unsigned short u16;
+
+typedef signed int s32;
+typedef unsigned int u32;
+
+typedef signed long long s64;
+typedef unsigned long long u64;
+typedef u64 paddr_t;
+#define INVALID_PADDR (~0ULL)
+#define PRIpaddr "016llx"
+
+typedef unsigned long size_t;
+
+typedef char bool_t;
+#define test_and_set_bool(b)   xchg(&(b), 1)
+#define test_and_clear_bool(b) xchg(&(b), 0)
+
+#endif /* __ASSEMBLY__ */
+
+#define BITS_PER_LONG 32
+#define BYTES_PER_LONG 4
+#define LONG_BYTEORDER 2
+
+#endif /* __ARM_TYPES_H__ */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/xenoprof.h b/xen/include/asm-arm/xenoprof.h
new file mode 100644
index 0000000..131ac13
--- /dev/null
+++ b/xen/include/asm-arm/xenoprof.h
@@ -0,0 +1,12 @@
+#ifndef __ASM_XENOPROF_H__
+#define __ASM_XENOPROF_H__
+
+#endif /* __ASM_XENOPROF_H__ */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
new file mode 100644
index 0000000..4d1daa9
--- /dev/null
+++ b/xen/include/public/arch-arm.h
@@ -0,0 +1,125 @@
+/******************************************************************************
+ * arch-arm.h
+ *
+ * Guest OS interface to ARM 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 2011 (C) Citrix Systems
+ */
+
+#ifndef __XEN_PUBLIC_ARCH_ARM_H__
+#define __XEN_PUBLIC_ARCH_ARM_H__
+
+#ifndef __ASSEMBLY__
+#define ___DEFINE_XEN_GUEST_HANDLE(name, type) \
+    typedef struct { type *p; } __guest_handle_ ## name
+
+#define __DEFINE_XEN_GUEST_HANDLE(name, type) \
+    ___DEFINE_XEN_GUEST_HANDLE(name, type);   \
+    ___DEFINE_XEN_GUEST_HANDLE(const_##name, const type)
+#define DEFINE_XEN_GUEST_HANDLE(name)   __DEFINE_XEN_GUEST_HANDLE(name, name)
+#define __XEN_GUEST_HANDLE(name)        __guest_handle_ ## name
+#define XEN_GUEST_HANDLE(name)          __XEN_GUEST_HANDLE(name)
+#define set_xen_guest_handle_raw(hnd, val)  do { (hnd).p = val; } while (0)
+#ifdef __XEN_TOOLS__
+#define get_xen_guest_handle(val, hnd)  do { val = (hnd).p; } while (0)
+#endif
+#define set_xen_guest_handle(hnd, val) set_xen_guest_handle_raw(hnd, val)
+
+struct cpu_user_regs
+{
+    uint32_t r0;
+    uint32_t r1;
+    uint32_t r2;
+    uint32_t r3;
+    uint32_t r4;
+    uint32_t r5;
+    uint32_t r6;
+    uint32_t r7;
+    uint32_t r8;
+    uint32_t r9;
+    uint32_t r10;
+    union {
+	uint32_t r11;
+	uint32_t fp;
+    };
+    uint32_t r12;
+
+    uint32_t sp; /* r13 - SP: Valid for Hyp. frames only, o/w banked (see below) */
+    uint32_t lr; /* r14 - LR: Valid for Hyp. Same physical register as lr_usr. */
+
+    uint32_t pc; /* Return IP */
+    uint32_t cpsr; /* Return mode */
+    uint32_t pad0; /* Doubleword-align the kernel half of the frame */
+
+    /* Outer guest frame only from here on... */
+
+    uint32_t r8_fiq, r9_fiq, r10_fiq, r11_fiq, r12_fiq;
+
+    uint32_t sp_usr, sp_svc, sp_abt, sp_und, sp_irq, sp_fiq;
+    uint32_t lr_usr, lr_svc, lr_abt, lr_und, lr_irq, lr_fiq;
+
+    uint32_t spsr_svc, spsr_abt, spsr_und, spsr_irq, spsr_fiq;
+};
+typedef struct cpu_user_regs cpu_user_regs_t;
+DEFINE_XEN_GUEST_HANDLE(cpu_user_regs_t);
+
+typedef uint64_t xen_pfn_t;
+#define PRI_xen_pfn PRIx64
+
+/* Maximum number of virtual CPUs in legacy multi-processor guests. */
+/* Only one. All other VCPUS must use VCPUOP_register_vcpu_info */
+#define XEN_LEGACY_MAX_VCPUS 1
+
+typedef uint32_t xen_ulong_t;
+
+struct vcpu_guest_context {
+    struct cpu_user_regs user_regs;         /* User-level CPU registers     */
+    union {
+	uint32_t reg[16];
+	struct {
+	    uint32_t __pad[12];
+	    uint32_t sp; /* r13 */
+	    uint32_t lr; /* r14 */
+	    uint32_t pc; /* r15 */
+	};
+    };
+};
+typedef struct vcpu_guest_context vcpu_guest_context_t;
+DEFINE_XEN_GUEST_HANDLE(vcpu_guest_context_t);
+
+struct arch_vcpu_info { };
+typedef struct arch_vcpu_info arch_vcpu_info_t;
+
+struct arch_shared_info { };
+typedef struct arch_shared_info arch_shared_info_t;
+#endif
+
+#endif /*  __XEN_PUBLIC_ARCH_ARM_H__ */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
index fde9fa5..7196400 100644
--- a/xen/include/public/xen.h
+++ b/xen/include/public/xen.h
@@ -33,6 +33,8 @@
 #include "arch-x86/xen.h"
 #elif defined(__ia64__)
 #include "arch-ia64.h"
+#elif defined(__arm__)
+#include "arch-arm.h"
 #else
 #error "Unsupported architecture"
 #endif
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 18:20:36 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 18:20:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXzd0-0007w7-Bx; Tue, 06 Dec 2011 18:20:30 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RXzcy-0007uy-E2
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 18:20:29 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1323195545!51363948!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMzAwOTc=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4073 invoked from network); 6 Dec 2011 18:19:13 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Dec 2011 18:19:13 -0000
X-IronPort-AV: E=Sophos;i="4.71,307,1320642000"; d="scan'208";a="173120747"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Dec 2011 13:19:45 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Tue, 6 Dec 2011 13:19:44 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pB6IJEjK019549;
	Tue, 6 Dec 2011 10:19:28 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Tue, 6 Dec 2011 18:19:54 +0000
Message-ID: <1323195609-17277-10-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1112061753410.31179@kaball-desktop>
References: <alpine.DEB.2.00.1112061753410.31179@kaball-desktop>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>, Tim.Deegan@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH RFC 10/25] arm: header files
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

A simple implementation of everything under asm-arm and arch-arm.h; some
of these files are shamelessly taken from Linux.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
---
 xen/include/asm-arm/atomic.h      |  212 +++++++++++++++++++++++++++++
 xen/include/asm-arm/bitops.h      |  195 +++++++++++++++++++++++++++
 xen/include/asm-arm/bug.h         |   15 ++
 xen/include/asm-arm/byteorder.h   |   16 +++
 xen/include/asm-arm/cache.h       |   20 +++
 xen/include/asm-arm/config.h      |  124 +++++++++++++++++
 xen/include/asm-arm/cpregs.h      |  207 ++++++++++++++++++++++++++++
 xen/include/asm-arm/current.h     |   60 ++++++++
 xen/include/asm-arm/debugger.h    |   15 ++
 xen/include/asm-arm/delay.h       |   15 ++
 xen/include/asm-arm/desc.h        |   12 ++
 xen/include/asm-arm/div64.h       |  241 +++++++++++++++++++++++++++++++++
 xen/include/asm-arm/elf.h         |   33 +++++
 xen/include/asm-arm/event.h       |   41 ++++++
 xen/include/asm-arm/flushtlb.h    |   31 +++++
 xen/include/asm-arm/grant_table.h |   35 +++++
 xen/include/asm-arm/hardirq.h     |   28 ++++
 xen/include/asm-arm/hypercall.h   |   24 ++++
 xen/include/asm-arm/init.h        |   12 ++
 xen/include/asm-arm/io.h          |   12 ++
 xen/include/asm-arm/iocap.h       |   20 +++
 xen/include/asm-arm/multicall.h   |   23 +++
 xen/include/asm-arm/nmi.h         |   15 ++
 xen/include/asm-arm/numa.h        |   21 +++
 xen/include/asm-arm/paging.h      |   13 ++
 xen/include/asm-arm/percpu.h      |   28 ++++
 xen/include/asm-arm/processor.h   |  269 +++++++++++++++++++++++++++++++++++++
 xen/include/asm-arm/regs.h        |   43 ++++++
 xen/include/asm-arm/setup.h       |   16 +++
 xen/include/asm-arm/smp.h         |   25 ++++
 xen/include/asm-arm/softirq.h     |   15 ++
 xen/include/asm-arm/spinlock.h    |  144 ++++++++++++++++++++
 xen/include/asm-arm/string.h      |   38 +++++
 xen/include/asm-arm/system.h      |  202 ++++++++++++++++++++++++++++
 xen/include/asm-arm/trace.h       |   12 ++
 xen/include/asm-arm/types.h       |   57 ++++++++
 xen/include/asm-arm/xenoprof.h    |   12 ++
 xen/include/public/arch-arm.h     |  125 +++++++++++++++++
 xen/include/public/xen.h          |    2 +
 39 files changed, 2428 insertions(+), 0 deletions(-)
 create mode 100644 xen/include/asm-arm/atomic.h
 create mode 100644 xen/include/asm-arm/bitops.h
 create mode 100644 xen/include/asm-arm/bug.h
 create mode 100644 xen/include/asm-arm/byteorder.h
 create mode 100644 xen/include/asm-arm/cache.h
 create mode 100644 xen/include/asm-arm/config.h
 create mode 100644 xen/include/asm-arm/cpregs.h
 create mode 100644 xen/include/asm-arm/current.h
 create mode 100644 xen/include/asm-arm/debugger.h
 create mode 100644 xen/include/asm-arm/delay.h
 create mode 100644 xen/include/asm-arm/desc.h
 create mode 100644 xen/include/asm-arm/div64.h
 create mode 100644 xen/include/asm-arm/elf.h
 create mode 100644 xen/include/asm-arm/event.h
 create mode 100644 xen/include/asm-arm/flushtlb.h
 create mode 100644 xen/include/asm-arm/grant_table.h
 create mode 100644 xen/include/asm-arm/hardirq.h
 create mode 100644 xen/include/asm-arm/hypercall.h
 create mode 100644 xen/include/asm-arm/init.h
 create mode 100644 xen/include/asm-arm/io.h
 create mode 100644 xen/include/asm-arm/iocap.h
 create mode 100644 xen/include/asm-arm/multicall.h
 create mode 100644 xen/include/asm-arm/nmi.h
 create mode 100644 xen/include/asm-arm/numa.h
 create mode 100644 xen/include/asm-arm/paging.h
 create mode 100644 xen/include/asm-arm/percpu.h
 create mode 100644 xen/include/asm-arm/processor.h
 create mode 100644 xen/include/asm-arm/regs.h
 create mode 100644 xen/include/asm-arm/setup.h
 create mode 100644 xen/include/asm-arm/smp.h
 create mode 100644 xen/include/asm-arm/softirq.h
 create mode 100644 xen/include/asm-arm/spinlock.h
 create mode 100644 xen/include/asm-arm/string.h
 create mode 100644 xen/include/asm-arm/system.h
 create mode 100644 xen/include/asm-arm/trace.h
 create mode 100644 xen/include/asm-arm/types.h
 create mode 100644 xen/include/asm-arm/xenoprof.h
 create mode 100644 xen/include/public/arch-arm.h

diff --git a/xen/include/asm-arm/atomic.h b/xen/include/asm-arm/atomic.h
new file mode 100644
index 0000000..2b9ce0e
--- /dev/null
+++ b/xen/include/asm-arm/atomic.h
@@ -0,0 +1,212 @@
+/*
+ *  arch/arm/include/asm/atomic.h
+ *
+ *  Copyright (C) 1996 Russell King.
+ *  Copyright (C) 2002 Deep Blue Solutions Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#ifndef __ARCH_ARM_ATOMIC__
+#define __ARCH_ARM_ATOMIC__
+
+#include <xen/config.h>
+#include <asm/system.h>
+
+#define build_atomic_read(name, size, type, reg)   \
+static inline type name(const volatile type *addr) \
+{                                                  \
+    type ret;                                      \
+    asm volatile("ldr" size " %0,%1"               \
+                 : reg (ret)                       \
+                 : "m" (*(volatile type *)addr));  \
+    return ret;                                    \
+}
+
+#define build_atomic_write(name, size, type, reg)      \
+static inline void name(volatile type *addr, type val) \
+{                                                      \
+    asm volatile("str" size " %1,%0"                   \
+                 : "=m" (*(volatile type *)addr)       \
+                 : reg (val));                         \
+}
+
+build_atomic_read(atomic_read8, "b", uint8_t, "=q")
+build_atomic_read(atomic_read16, "h", uint16_t, "=r")
+build_atomic_read(atomic_read32, "", uint32_t, "=r")
+//build_atomic_read(atomic_read64, "d", uint64_t, "=r")
+build_atomic_read(atomic_read_int, "", int, "=r")
+
+build_atomic_write(atomic_write8, "b", uint8_t, "q")
+build_atomic_write(atomic_write16, "h", uint16_t, "r")
+build_atomic_write(atomic_write32, "", uint32_t, "r")
+//build_atomic_write(atomic_write64, "d", uint64_t, "r")
+build_atomic_write(atomic_write_int, "", int, "r")
+
+/*
+ * NB. I've pushed the volatile qualifier into the operations. This allows
+ * fast accessors such as _atomic_read() and _atomic_set() which don't give
+ * the compiler a fit.
+ */
+typedef struct { int counter; } atomic_t;
+
+#define ATOMIC_INIT(i) { (i) }
+
+/*
+ * On ARM, ordinary assignment (str instruction) doesn't clear the local
+ * strex/ldrex monitor on some implementations. The reason we can use it for
+ * atomic_set() is the clrex or dummy strex done on every exception return.
+ */
+#define _atomic_read(v) ((v).counter)
+#define atomic_read(v)  (*(volatile int *)&(v)->counter)
+
+#define _atomic_set(v,i) (((v).counter) = (i))
+#define atomic_set(v,i) (((v)->counter) = (i))
+
+/*
+ * ARMv6 UP and SMP safe atomic ops.  We use load exclusive and
+ * store exclusive to ensure that these are atomic.  We may loop
+ * to ensure that the update happens.
+ */
+static inline void atomic_add(int i, atomic_t *v)
+{
+        unsigned long tmp;
+        int result;
+
+        __asm__ __volatile__("@ atomic_add\n"
+"1:     ldrex   %0, [%3]\n"
+"       add     %0, %0, %4\n"
+"       strex   %1, %0, [%3]\n"
+"       teq     %1, #0\n"
+"       bne     1b"
+        : "=&r" (result), "=&r" (tmp), "+Qo" (v->counter)
+        : "r" (&v->counter), "Ir" (i)
+        : "cc");
+}
+
+static inline int atomic_add_return(int i, atomic_t *v)
+{
+        unsigned long tmp;
+        int result;
+
+        smp_mb();
+
+        __asm__ __volatile__("@ atomic_add_return\n"
+"1:     ldrex   %0, [%3]\n"
+"       add     %0, %0, %4\n"
+"       strex   %1, %0, [%3]\n"
+"       teq     %1, #0\n"
+"       bne     1b"
+        : "=&r" (result), "=&r" (tmp), "+Qo" (v->counter)
+        : "r" (&v->counter), "Ir" (i)
+        : "cc");
+
+        smp_mb();
+
+        return result;
+}
+
+static inline void atomic_sub(int i, atomic_t *v)
+{
+        unsigned long tmp;
+        int result;
+
+        __asm__ __volatile__("@ atomic_sub\n"
+"1:     ldrex   %0, [%3]\n"
+"       sub     %0, %0, %4\n"
+"       strex   %1, %0, [%3]\n"
+"       teq     %1, #0\n"
+"       bne     1b"
+        : "=&r" (result), "=&r" (tmp), "+Qo" (v->counter)
+        : "r" (&v->counter), "Ir" (i)
+        : "cc");
+}
+
+static inline int atomic_sub_return(int i, atomic_t *v)
+{
+        unsigned long tmp;
+        int result;
+
+        smp_mb();
+
+        __asm__ __volatile__("@ atomic_sub_return\n"
+"1:     ldrex   %0, [%3]\n"
+"       sub     %0, %0, %4\n"
+"       strex   %1, %0, [%3]\n"
+"       teq     %1, #0\n"
+"       bne     1b"
+        : "=&r" (result), "=&r" (tmp), "+Qo" (v->counter)
+        : "r" (&v->counter), "Ir" (i)
+        : "cc");
+
+        smp_mb();
+
+        return result;
+}
+
+static inline int atomic_cmpxchg(atomic_t *ptr, int old, int new)
+{
+        unsigned long oldval, res;
+
+        smp_mb();
+
+        do {
+                __asm__ __volatile__("@ atomic_cmpxchg\n"
+                "ldrex  %1, [%3]\n"
+                "mov    %0, #0\n"
+                "teq    %1, %4\n"
+                "strexeq %0, %5, [%3]\n"
+                    : "=&r" (res), "=&r" (oldval), "+Qo" (ptr->counter)
+                    : "r" (&ptr->counter), "Ir" (old), "r" (new)
+                    : "cc");
+        } while (res);
+
+        smp_mb();
+
+        return oldval;
+}
+
+static inline void atomic_clear_mask(unsigned long mask, unsigned long *addr)
+{
+        unsigned long tmp, tmp2;
+
+        __asm__ __volatile__("@ atomic_clear_mask\n"
+"1:     ldrex   %0, [%3]\n"
+"       bic     %0, %0, %4\n"
+"       strex   %1, %0, [%3]\n"
+"       teq     %1, #0\n"
+"       bne     1b"
+        : "=&r" (tmp), "=&r" (tmp2), "+Qo" (*addr)
+        : "r" (addr), "Ir" (mask)
+        : "cc");
+}
+
+#define atomic_inc(v)           atomic_add(1, v)
+#define atomic_dec(v)           atomic_sub(1, v)
+
+#define atomic_inc_and_test(v)  (atomic_add_return(1, v) == 0)
+#define atomic_dec_and_test(v)  (atomic_sub_return(1, v) == 0)
+#define atomic_inc_return(v)    (atomic_add_return(1, v))
+#define atomic_dec_return(v)    (atomic_sub_return(1, v))
+#define atomic_sub_and_test(i, v) (atomic_sub_return(i, v) == 0)
+
+#define atomic_add_negative(i,v) (atomic_add_return(i, v) < 0)
+
+static inline atomic_t atomic_compareandswap(
+    atomic_t old, atomic_t new, atomic_t *v)
+{
+    atomic_t rc;
+    rc.counter = __cmpxchg(&v->counter, old.counter, new.counter, sizeof(int));
+    return rc;
+}
+
+#endif /* __ARCH_ARM_ATOMIC__ */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/bitops.h b/xen/include/asm-arm/bitops.h
new file mode 100644
index 0000000..3d6b30b
--- /dev/null
+++ b/xen/include/asm-arm/bitops.h
@@ -0,0 +1,195 @@
+/*
+ * Copyright 1995, Russell King.
+ * Various bits and pieces copyrights include:
+ *  Linus Torvalds (test_bit).
+ * Big endian support: Copyright 2001, Nicolas Pitre
+ *  reworked by rmk.
+ */
+
+#ifndef _ARM_BITOPS_H
+#define _ARM_BITOPS_H
+
+extern void _set_bit(int nr, volatile void * p);
+extern void _clear_bit(int nr, volatile void * p);
+extern void _change_bit(int nr, volatile void * p);
+extern int _test_and_set_bit(int nr, volatile void * p);
+extern int _test_and_clear_bit(int nr, volatile void * p);
+extern int _test_and_change_bit(int nr, volatile void * p);
+
+#define set_bit(n,p)              _set_bit(n,p)
+#define clear_bit(n,p)            _clear_bit(n,p)
+#define change_bit(n,p)           _change_bit(n,p)
+#define test_and_set_bit(n,p)     _test_and_set_bit(n,p)
+#define test_and_clear_bit(n,p)   _test_and_clear_bit(n,p)
+#define test_and_change_bit(n,p)  _test_and_change_bit(n,p)
+
+#define BIT(nr)                 (1UL << (nr))
+#define BIT_MASK(nr)            (1UL << ((nr) % BITS_PER_LONG))
+#define BIT_WORD(nr)            ((nr) / BITS_PER_LONG)
+#define BITS_PER_BYTE           8
+
+#define ADDR (*(volatile long *) addr)
+#define CONST_ADDR (*(const volatile long *) addr)
+
+/**
+ * __test_and_set_bit - Set a bit and return its old value
+ * @nr: Bit to set
+ * @addr: Address to count from
+ *
+ * This operation is non-atomic and can be reordered.
+ * If two examples of this operation race, one can appear to succeed
+ * but actually fail.  You must protect multiple accesses with a lock.
+ */
+static inline int __test_and_set_bit(int nr, volatile void *addr)
+{
+        unsigned long mask = BIT_MASK(nr);
+        volatile unsigned long *p =
+                ((volatile unsigned long *)addr) + BIT_WORD(nr);
+        unsigned long old = *p;
+
+        *p = old | mask;
+        return (old & mask) != 0;
+}
+
+/**
+ * __test_and_clear_bit - Clear a bit and return its old value
+ * @nr: Bit to clear
+ * @addr: Address to count from
+ *
+ * This operation is non-atomic and can be reordered.
+ * If two examples of this operation race, one can appear to succeed
+ * but actually fail.  You must protect multiple accesses with a lock.
+ */
+static inline int __test_and_clear_bit(int nr, volatile void *addr)
+{
+        unsigned long mask = BIT_MASK(nr);
+        volatile unsigned long *p =
+                ((volatile unsigned long *)addr) + BIT_WORD(nr);
+        unsigned long old = *p;
+
+        *p = old & ~mask;
+        return (old & mask) != 0;
+}
+
+/* WARNING: non atomic and it can be reordered! */
+static inline int __test_and_change_bit(int nr,
+                                            volatile void *addr)
+{
+        unsigned long mask = BIT_MASK(nr);
+        volatile unsigned long *p =
+                ((volatile unsigned long *)addr) + BIT_WORD(nr);
+        unsigned long old = *p;
+
+        *p = old ^ mask;
+        return (old & mask) != 0;
+}
+
+/**
+ * test_bit - Determine whether a bit is set
+ * @nr: bit number to test
+ * @addr: Address to start counting from
+ */
+static inline int test_bit(int nr, const volatile void *addr)
+{
+        const volatile unsigned long *p = (const volatile unsigned long *)addr;
+        return 1UL & (p[BIT_WORD(nr)] >> (nr & (BITS_PER_LONG-1)));
+}
+
+
+extern unsigned int _find_first_bit(
+    const unsigned long *addr, unsigned int size);
+extern unsigned int _find_next_bit(
+    const unsigned long *addr, unsigned int size, unsigned int offset);
+extern unsigned int _find_first_zero_bit(
+    const unsigned long *addr, unsigned int size);
+extern unsigned int _find_next_zero_bit(
+    const unsigned long *addr, unsigned int size, unsigned int offset);
+
+/*
+ * These are the little endian, atomic definitions.
+ */
+#define find_first_zero_bit(p,sz)       _find_first_zero_bit(p,sz)
+#define find_next_zero_bit(p,sz,off)    _find_next_zero_bit(p,sz,off)
+#define find_first_bit(p,sz)            _find_first_bit(p,sz)
+#define find_next_bit(p,sz,off)         _find_next_bit(p,sz,off)
+
+static inline int constant_fls(int x)
+{
+        int r = 32;
+
+        if (!x)
+                return 0;
+        if (!(x & 0xffff0000u)) {
+                x <<= 16;
+                r -= 16;
+        }
+        if (!(x & 0xff000000u)) {
+                x <<= 8;
+                r -= 8;
+        }
+        if (!(x & 0xf0000000u)) {
+                x <<= 4;
+                r -= 4;
+        }
+        if (!(x & 0xc0000000u)) {
+                x <<= 2;
+                r -= 2;
+        }
+        if (!(x & 0x80000000u)) {
+                x <<= 1;
+                r -= 1;
+        }
+        return r;
+}
+
+/*
+ * On ARMv5 and above those functions can be implemented around
+ * the clz instruction for much better code efficiency.
+ */
+
+static inline int fls(int x)
+{
+        int ret;
+
+        if (__builtin_constant_p(x))
+               return constant_fls(x);
+
+        asm("clz\t%0, %1" : "=r" (ret) : "r" (x));
+        ret = 32 - ret;
+        return ret;
+}
+
+#define ffs(x) ({ unsigned long __t = (x); fls(__t & -__t); })
+
+/**
+ * find_first_set_bit - find the first set bit in @word
+ * @word: the word to search
+ *
+ * Returns the bit-number of the first set bit (first bit being 0).
+ * The input must *not* be zero.
+ */
+static inline unsigned int find_first_set_bit(unsigned long word)
+{
+        return ffs(word) - 1;
+}
+
+/**
+ * hweightN - returns the hamming weight of a N-bit word
+ * @x: the word to weigh
+ *
+ * The Hamming Weight of a number is the total number of bits set in it.
+ */
+#define hweight64(x) generic_hweight64(x)
+#define hweight32(x) generic_hweight32(x)
+#define hweight16(x) generic_hweight16(x)
+#define hweight8(x) generic_hweight8(x)
+
+#endif /* _ARM_BITOPS_H */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/bug.h b/xen/include/asm-arm/bug.h
new file mode 100644
index 0000000..bc2532c
--- /dev/null
+++ b/xen/include/asm-arm/bug.h
@@ -0,0 +1,15 @@
+#ifndef __ARM_BUG_H__
+#define __ARM_BUG_H__
+
+#define BUG() __bug(__FILE__, __LINE__)
+#define WARN() __warn(__FILE__, __LINE__)
+
+#endif /* __X86_BUG_H__ */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/byteorder.h b/xen/include/asm-arm/byteorder.h
new file mode 100644
index 0000000..f6ad883
--- /dev/null
+++ b/xen/include/asm-arm/byteorder.h
@@ -0,0 +1,16 @@
+#ifndef __ASM_ARM_BYTEORDER_H__
+#define __ASM_ARM_BYTEORDER_H__
+
+#define __BYTEORDER_HAS_U64__
+
+#include <xen/byteorder/little_endian.h>
+
+#endif /* __ASM_ARM_BYTEORDER_H__ */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/cache.h b/xen/include/asm-arm/cache.h
new file mode 100644
index 0000000..41b6291
--- /dev/null
+++ b/xen/include/asm-arm/cache.h
@@ -0,0 +1,20 @@
+#ifndef __ARCH_ARM_CACHE_H
+#define __ARCH_ARM_CACHE_H
+
+#include <xen/config.h>
+
+/* L1 cache line size */
+#define L1_CACHE_SHIFT  (CONFIG_ARM_L1_CACHE_SHIFT)
+#define L1_CACHE_BYTES  (1 << L1_CACHE_SHIFT)
+
+#define __read_mostly __attribute__((__section__(".data.read_mostly")))
+
+#endif
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/config.h b/xen/include/asm-arm/config.h
new file mode 100644
index 0000000..671ac52
--- /dev/null
+++ b/xen/include/asm-arm/config.h
@@ -0,0 +1,124 @@
+/******************************************************************************
+ * config.h
+ *
+ * A Linux-style configuration list.
+ */
+
+#ifndef __ARM_CONFIG_H__
+#define __ARM_CONFIG_H__
+
+#define CONFIG_PAGING_LEVELS 3
+
+#define CONFIG_ARM 1
+
+#define CONFIG_ARM_L1_CACHE_SHIFT 7 /* XXX */
+
+#define CONFIG_SMP 1
+
+#define CONFIG_DOMAIN_PAGE 1
+
+#define OPT_CONSOLE_STR "com1"
+
+#ifdef MAX_PHYS_CPUS
+#define NR_CPUS MAX_PHYS_CPUS
+#else
+#define NR_CPUS 128
+#endif
+
+#define MAX_VIRT_CPUS 128 /* XXX */
+#define MAX_HVM_VCPUS MAX_VIRT_CPUS
+
+#define asmlinkage /* Nothing needed */
+
+/* Linkage for ARM */
+#define __ALIGN .align 2
+#define __ALIGN_STR ".align 2"
+#ifdef __ASSEMBLY__
+#define ALIGN __ALIGN
+#define ALIGN_STR __ALIGN_STR
+#define ENTRY(name)                             \
+  .globl name;                                  \
+  ALIGN;                                        \
+  name:
+#define END(name) \
+  .size name, .-name
+#define ENDPROC(name) \
+  .type name, %function; \
+  END(name)
+#endif
+
+#define CONFIG_KERNEL_NO_RELOC 1
+
+/*
+ * Memory layout:
+ *  0  -   2M   Unmapped
+ *  2M -   4M   Xen text, data, bss
+ *  4M -   6M   Fixmap: special-purpose 4K mapping slots
+ *
+ * 32M - 128M   Frametable: 24 bytes per page for 16GB of RAM
+ *
+ *  1G -   2G   Xenheap: always-mapped memory
+ *  2G -   4G   Domheap: on-demand-mapped
+ */
+
+#define XEN_VIRT_START         0x00200000
+#define FIXMAP_ADDR(n)        (0x00400000 + (n) * PAGE_SIZE)
+#define FRAMETABLE_VIRT_START  0x02000000
+#define XENHEAP_VIRT_START     0x40000000
+#define DOMHEAP_VIRT_START     0x80000000
+
+#define HYPERVISOR_VIRT_START mk_unsigned_long(XEN_VIRT_START)
+
+#define DOMHEAP_ENTRIES        1024  /* 1024 2MB mapping slots */
+
+/* Fixmap slots */
+#define FIXMAP_CONSOLE  0  /* The primary UART */
+#define FIXMAP_PT       1  /* Temporary mappings of pagetable pages */
+#define FIXMAP_MISC     2  /* Ephemeral mappings of hardware */
+#define FIXMAP_GICD     3  /* Interrupt controller: distributor registers */
+#define FIXMAP_GICC1    4  /* Interrupt controller: CPU registers (first page) */
+#define FIXMAP_GICC2    5  /* Interrupt controller: CPU registers (second page) */
+#define FIXMAP_GICH     6  /* Interrupt controller: virtual interface control registers */
+
+#define PAGE_SHIFT              12
+
+#ifndef __ASSEMBLY__
+#define PAGE_SIZE           (1L << PAGE_SHIFT)
+#else
+#define PAGE_SIZE           (1 << PAGE_SHIFT)
+#endif
+#define PAGE_MASK           (~(PAGE_SIZE-1))
+#define PAGE_FLAG_MASK      (~0)
+
+#define STACK_ORDER 3
+#define STACK_SIZE  (PAGE_SIZE << STACK_ORDER)
+
+#ifndef __ASSEMBLY__
+extern unsigned long xen_phys_start;
+extern unsigned long xenheap_phys_end;
+extern unsigned long frametable_virt_end;
+#endif
+
+#define supervisor_mode_kernel (0)
+
+#define watchdog_disable() ((void)0)
+#define watchdog_enable()  ((void)0)
+
+/* Board-specific: base address of PL011 UART */
+#define EARLY_UART_ADDRESS 0x1c090000
+/* Board-specific: base address of GIC + its regs */
+#define GIC_BASE_ADDRESS 0x2c000000
+#define GIC_DR_OFFSET 0x1000
+#define GIC_CR_OFFSET 0x2000
+#define GIC_HR_OFFSET 0x4000 /* Guess work http://lists.infradead.org/pipermail/linux-arm-kernel/2011-September/064219.html */
+#define GIC_VR_OFFSET 0x6000 /* Virtual Machine CPU interface) */
+
+#endif /* __ARM_CONFIG_H__ */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/cpregs.h b/xen/include/asm-arm/cpregs.h
new file mode 100644
index 0000000..3a4028d
--- /dev/null
+++ b/xen/include/asm-arm/cpregs.h
@@ -0,0 +1,207 @@
+#ifndef __ASM_ARM_CPREGS_H
+#define __ASM_ARM_CPREGS_H
+
+#include <xen/stringify.h>
+
+/* Co-processor registers */
+
+/* Layout as used in assembly, with src/dest registers mixed in */
+#define __CP32(r, coproc, opc1, crn, crm, opc2) coproc, opc1, r, crn, crm, opc2
+#define __CP64(r1, r2, coproc, opc, crm) coproc, opc, r1, r2, crm
+#define CP32(r, name...) __CP32(r, name)
+#define CP64(r, name...) __CP64(r, name)
+
+/* Stringified for inline assembly */
+#define LOAD_CP32(r, name...)  "mrc " __stringify(CP32(%r, name)) ";"
+#define STORE_CP32(r, name...) "mcr " __stringify(CP32(%r, name)) ";"
+#define LOAD_CP64(r, name...)  "mrrc " __stringify(CP64(%r, %H##r, name)) ";"
+#define STORE_CP64(r, name...) "mcrr " __stringify(CP64(%r, %H##r, name)) ";"
+
+/* C wrappers */
+#define READ_CP32(name...) ({                                   \
+    register uint32_t _r;                                       \
+    asm volatile(LOAD_CP32(0, name) : "=r" (_r));               \
+    _r; })
+
+#define WRITE_CP32(v, name...) do {                             \
+    register uint32_t _r = (v);                                 \
+    asm volatile(STORE_CP32(0, name) : : "r" (_r));             \
+} while (0)
+
+#define READ_CP64(name...) ({                                   \
+    register uint64_t _r;                                       \
+    asm volatile(LOAD_CP64(0, name) : "=r" (_r));               \
+    _r; })
+
+#define WRITE_CP64(v, name...) do {                             \
+    register uint64_t _r = (v);                                 \
+    asm volatile(STORE_CP64(0, name) : : "r" (_r));             \
+} while (0)
+
+#define __HSR_CPREG_c0  0
+#define __HSR_CPREG_c1  1
+#define __HSR_CPREG_c2  2
+#define __HSR_CPREG_c3  3
+#define __HSR_CPREG_c4  4
+#define __HSR_CPREG_c5  5
+#define __HSR_CPREG_c6  6
+#define __HSR_CPREG_c7  7
+#define __HSR_CPREG_c8  8
+#define __HSR_CPREG_c9  9
+#define __HSR_CPREG_c10 10
+#define __HSR_CPREG_c11 11
+#define __HSR_CPREG_c12 12
+#define __HSR_CPREG_c13 13
+#define __HSR_CPREG_c14 14
+#define __HSR_CPREG_c15 15
+
+#define __HSR_CPREG_0   0
+#define __HSR_CPREG_1   1
+#define __HSR_CPREG_2   2
+#define __HSR_CPREG_3   3
+#define __HSR_CPREG_4   4
+#define __HSR_CPREG_5   5
+#define __HSR_CPREG_6   6
+#define __HSR_CPREG_7   7
+
+#define _HSR_CPREG32(cp,op1,crn,crm,op2) \
+    ((__HSR_CPREG_##crn) << HSR_CP32_CRN_SHIFT) | \
+    ((__HSR_CPREG_##crm) << HSR_CP32_CRM_SHIFT) | \
+    ((__HSR_CPREG_##op1) << HSR_CP32_OP1_SHIFT) | \
+    ((__HSR_CPREG_##op2) << HSR_CP32_OP2_SHIFT)
+
+#define _HSR_CPREG64(cp,op1,crm) \
+    ((__HSR_CPREG_##crm) << HSR_CP64_CRM_SHIFT) | \
+    ((__HSR_CPREG_##op1) << HSR_CP64_OP1_SHIFT)
+
+/* Encode a register as per HSR ISS pattern */
+#define HSR_CPREG32(X) _HSR_CPREG32(X)
+#define HSR_CPREG64(X) _HSR_CPREG64(X)
+
+/*
+ * Order registers by Coprocessor-> CRn-> Opcode 1-> CRm-> Opcode 2
+ *
+ * This matches the ordering used in the ARM as well as the groupings
+ * which the CP registers are allocated in.
+ *
+ * This is slightly different to the form of the instruction
+ * arguments, which are cp,opc1,crn,crm,opc2.
+ */
+
+/* Coprocessor 15 */
+
+/* CP15 CR0: CPUID and Cache Type Registers */
+#define ID_PFR0         p15,0,c0,c1,0   /* Processor Feature Register 0 */
+#define ID_PFR1         p15,0,c0,c1,1   /* Processor Feature Register 1 */
+#define CCSIDR          p15,1,c0,c0,0   /* Cache Size ID Registers */
+#define CLIDR           p15,1,c0,c0,1   /* Cache Level ID Register */
+#define CSSELR          p15,2,c0,c0,0   /* Cache Size Selection Register */
+
+/* CP15 CR1: System Control Registers */
+#define SCTLR           p15,0,c1,c0,0   /* System Control Register */
+#define SCR             p15,0,c1,c1,0   /* Secure Configuration Register */
+#define NSACR           p15,0,c1,c1,2   /* Non-Secure Access Control Register */
+#define HSCTLR          p15,4,c1,c0,0   /* Hyp. System Control Register */
+#define HCR             p15,4,c1,c1,0   /* Hyp. Configuration Register */
+
+/* CP15 CR2: Translation Table Base and Control Registers */
+#define TTBR0           p15,0,c2,c0,0   /* Translation Table Base Reg. 0 */
+#define TTBR1           p15,0,c2,c0,1   /* Translation Table Base Reg. 1 */
+#define TTBCR           p15,0,c2,c0,2   /* Translatation Table Base Control Register */
+#define HTTBR           p15,4,c2        /* Hyp. Translation Table Base Register */
+#define HTCR            p15,4,c2,c0,2   /* Hyp. Translation Control Register */
+#define VTCR            p15,4,c2,c1,2   /* Virtualization Translation Control Register */
+#define VTTBR           p15,6,c2        /* Virtualization Translation Table Base Register */
+
+/* CP15 CR3: Domain Access Control Register */
+
+/* CP15 CR4: */
+
+/* CP15 CR5: Fault Status Registers */
+#define DFSR            p15,0,c5,c0,0   /* Data Fault Status Register */
+#define IFSR            p15,0,c5,c0,1   /* Instruction Fault Status Register */
+#define HSR             p15,4,c5,c2,0   /* Hyp. Syndrome Register */
+
+/* CP15 CR6: Fault Address Registers */
+#define DFAR            p15,0,c6,c0,0   /* Data Fault Address Register  */
+#define IFAR            p15,0,c6,c0,2   /* Instruction Fault Address Register */
+#define HDFAR           p15,4,c6,c0,0   /* Hyp. Data Fault Address Register */
+#define HIFAR           p15,4,c6,c0,2   /* Hyp. Instruction Fault Address Register */
+#define HPFAR           p15,4,c6,c0,4   /* Hyp. IPA Fault Address Register */
+
+/* CP15 CR7: Cache and address translation operations */
+#define PAR             p15,0,c7        /* Physical Address Register */
+#define ICIALLUIS       p15,0,c7,c1,0   /* Invalidate all instruction caches to PoU inner shareable */
+#define BPIALLIS        p15,0,c7,c1,6   /* Invalidate entire branch predictor array inner shareable */
+#define ICIALLU         p15,0,c7,c5,0   /* Invalidate all instruction caches to PoU */
+#define BPIALL          p15,0,c7,c5,6   /* Invalidate entire branch predictor array */
+#define ATS1CPR         p15,0,c7,c8,0   /* Address Translation Stage 1. Non-Secure Kernel Read */
+#define ATS1CPW         p15,0,c7,c8,1   /* Address Translation Stage 1. Non-Secure Kernel Write */
+#define ATS1CUR         p15,0,c7,c8,2   /* Address Translation Stage 1. Non-Secure User Read */
+#define ATS1CUW         p15,0,c7,c8,3   /* Address Translation Stage 1. Non-Secure User Write */
+#define ATS12NSOPR      p15,0,c7,c8,4   /* Address Translation Stage 1+2 Non-Secure Kernel Read */
+#define ATS12NSOPW      p15,0,c7,c8,5   /* Address Translation Stage 1+2 Non-Secure Kernel Write */
+#define ATS12NSOUR      p15,0,c7,c8,6   /* Address Translation Stage 1+2 Non-Secure User Read */
+#define ATS12NSOUW      p15,0,c7,c8,7   /* Address Translation Stage 1+2 Non-Secure User Write */
+#define DCCMVAC         p15,0,c7,c10,1  /* Clean data or unified cache line by MVA to PoC */
+#define DCCISW          p15,0,c7,c14,2  /* Clean and invalidate data cache line by set/way */
+#define ATS1HR          p15,4,c7,c8,0   /* Address Translation Stage 1 Hyp. Read */
+#define ATS1HW          p15,4,c7,c8,1   /* Address Translation Stage 1 Hyp. Write */
+
+/* CP15 CR8: TLB maintenance operations */
+#define TLBIALLIS       p15,0,c8,c3,0   /* Invalidate entire TLB innrer shareable */
+#define TLBIMVAIS       p15,0,c8,c3,1   /* Invalidate unified TLB entry by MVA inner shareable */
+#define TLBIASIDIS      p15,0,c8,c3,2   /* Invalidate unified TLB by ASID match inner shareable */
+#define TLBIMVAAIS      p15,0,c8,c3,3   /* Invalidate unified TLB entry by MVA all ASID inner shareable */
+#define DTLBIALL        p15,0,c8,c6,0   /* Invalidate data TLB */
+#define DTLBIMVA        p15,0,c8,c6,1   /* Invalidate data TLB entry by MVA */
+#define DTLBIASID       p15,0,c8,c6,2   /* Invalidate data TLB by ASID match */
+#define TLBILLHIS       p15,4,c8,c3,0   /* Invalidate Entire Hyp. Unified TLB inner shareable */
+#define TLBIMVAHIS      p15,4,c8,c3,1   /* Invalidate Unified Hyp. TLB by MVA inner shareable */
+#define TLBIALLNSNHIS   p15,4,c8,c7,4   /* Invalidate Entire Non-Secure Non-Hyp. Unified TLB inner shareable */
+#define TLBIALLH        p15,4,c8,c7,0   /* Invalidate Entire Hyp. Unified TLB */
+#define TLBIMVAH        p15,4,c8,c7,1   /* Invalidate Unified Hyp. TLB by MVA */
+#define TLBIALLNSNH     p15,4,c8,c7,4   /* Invalidate Entire Non-Secure Non-Hyp. Unified TLB */
+
+/* CP15 CR9: */
+
+/* CP15 CR10: */
+#define MAIR0           p15,0,c10,c2,0  /* Memory Attribute Indirection Register 0 */
+#define MAIR1           p15,0,c10,c2,1  /* Memory Attribute Indirection Register 1 */
+#define HMAIR0          p15,4,c10,c2,0  /* Hyp. Memory Attribute Indirection Register 0 */
+#define HMAIR1          p15,4,c10,c2,1  /* Hyp. Memory Attribute Indirection Register 1 */
+
+/* CP15 CR11: DMA Operations for TCM Access */
+
+/* CP15 CR12:  */
+#define HVBAR           p15,4,c12,c0,0  /* Hyp. Vector Base Address Register */
+
+/* CP15 CR13:  */
+#define FCSEIDR         p15,0,c13,c0,0  /* FCSE Process ID Register */
+#define CONTEXTIDR      p15,0,c13,c0,1  /* Context ID Register */
+
+/* CP15 CR14:  */
+#define CNTPCT          p15,0,c14       /* Time counter value */
+#define CNTFRQ          p15,0,c14,c0,0  /* Time counter frequency */
+#define CNTKCTL         p15,0,c14,c1,0  /* Time counter kernel control */
+#define CNTP_TVAL       p15,0,c14,c2,0  /* Physical Timer value */
+#define CNTP_CTL        p15,0,c14,c2,1  /* Physical Timer control register */
+#define CNTVCT          p15,1,c14       /* Time counter value + offset */
+#define CNTP_CVAL       p15,2,c14       /* Physical Timer comparator */
+#define CNTVOFF         p15,4,c14       /* Time counter offset */
+#define CNTHCTL         p15,4,c14,c1,0  /* Time counter hyp. control */
+#define CNTHP_TVAL      p15,4,c14,c2,0  /* Hyp. Timer value */
+#define CNTHP_CTL       p15,4,c14,c2,1  /* Hyp. Timer control register */
+#define CNTHP_CVAL      p15,6,c14       /* Hyp. Timer comparator */
+
+/* CP15 CR15: Implementation Defined Registers */
+
+#endif
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/current.h b/xen/include/asm-arm/current.h
new file mode 100644
index 0000000..826efa5
--- /dev/null
+++ b/xen/include/asm-arm/current.h
@@ -0,0 +1,60 @@
+#ifndef __ARM_CURRENT_H__
+#define __ARM_CURRENT_H__
+
+#include <xen/config.h>
+#include <xen/percpu.h>
+#include <public/xen.h>
+
+#ifndef __ASSEMBLY__
+
+struct vcpu;
+
+struct cpu_info {
+    struct cpu_user_regs guest_cpu_user_regs;
+    unsigned long elr;
+    unsigned int processor_id;
+    struct vcpu *current_vcpu;
+    unsigned long per_cpu_offset;
+};
+
+static inline struct cpu_info *get_cpu_info(void)
+{
+        register unsigned long sp asm ("sp");
+        return (struct cpu_info *)((sp & ~(STACK_SIZE - 1)) + STACK_SIZE - sizeof(struct cpu_info));
+}
+
+#define get_current()         (get_cpu_info()->current_vcpu)
+#define set_current(vcpu)     (get_cpu_info()->current_vcpu = (vcpu))
+#define current               (get_current())
+
+#define get_processor_id()    (get_cpu_info()->processor_id)
+#define set_processor_id(id)  do {                                      \
+    struct cpu_info *ci__ = get_cpu_info();                             \
+    ci__->per_cpu_offset = __per_cpu_offset[ci__->processor_id = (id)]; \
+} while (0)
+
+#define guest_cpu_user_regs() (&get_cpu_info()->guest_cpu_user_regs)
+
+#define reset_stack_and_jump(__fn)              \
+    __asm__ __volatile__ (                      \
+        "mov sp,%0; b "STR(__fn)      \
+        : : "r" (guest_cpu_user_regs()) : "memory" )
+#endif
+
+
+/*
+ * Which VCPU's state is currently running on each CPU?
+ * This is not necesasrily the same as 'current' as a CPU may be
+ * executing a lazy state switch.
+ */
+DECLARE_PER_CPU(struct vcpu *, curr_vcpu);
+
+#endif /* __ARM_CURRENT_H__ */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/debugger.h b/xen/include/asm-arm/debugger.h
new file mode 100644
index 0000000..84b2eec
--- /dev/null
+++ b/xen/include/asm-arm/debugger.h
@@ -0,0 +1,15 @@
+#ifndef __ARM_DEBUGGER_H__
+#define __ARM_DEBUGGER_H__
+
+#define debugger_trap_fatal(v, r) (0)
+#define debugger_trap_immediate() (0)
+
+#endif /* __ARM_DEBUGGER_H__ */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/delay.h b/xen/include/asm-arm/delay.h
new file mode 100644
index 0000000..6250774
--- /dev/null
+++ b/xen/include/asm-arm/delay.h
@@ -0,0 +1,15 @@
+#ifndef _ARM_DELAY_H
+#define _ARM_DELAY_H
+
+extern void __udelay(unsigned long usecs);
+#define udelay(n) __udelay(n)
+
+#endif /* defined(_ARM_DELAY_H) */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/desc.h b/xen/include/asm-arm/desc.h
new file mode 100644
index 0000000..3989e8a
--- /dev/null
+++ b/xen/include/asm-arm/desc.h
@@ -0,0 +1,12 @@
+#ifndef __ARCH_DESC_H
+#define __ARCH_DESC_H
+
+#endif /* __ARCH_DESC_H */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/div64.h b/xen/include/asm-arm/div64.h
new file mode 100644
index 0000000..5f23b65
--- /dev/null
+++ b/xen/include/asm-arm/div64.h
@@ -0,0 +1,241 @@
+/* Taken from Linux arch/arm */
+#ifndef __ASM_ARM_DIV64
+#define __ASM_ARM_DIV64
+
+#include <asm/system.h>
+#include <xen/types.h>
+
+/*
+ * The semantics of do_div() are:
+ *
+ * uint32_t do_div(uint64_t *n, uint32_t base)
+ * {
+ * 	uint32_t remainder = *n % base;
+ * 	*n = *n / base;
+ * 	return remainder;
+ * }
+ *
+ * In other words, a 64-bit dividend with a 32-bit divisor producing
+ * a 64-bit result and a 32-bit remainder.  To accomplish this optimally
+ * we call a special __do_div64 helper with completely non standard
+ * calling convention for arguments and results (beware).
+ */
+
+#ifdef __ARMEB__
+#define __xh "r0"
+#define __xl "r1"
+#else
+#define __xl "r0"
+#define __xh "r1"
+#endif
+
+#define __do_div_asm(n, base)					\
+({								\
+	register unsigned int __base      asm("r4") = base;	\
+	register unsigned long long __n   asm("r0") = n;	\
+	register unsigned long long __res asm("r2");		\
+	register unsigned int __rem       asm(__xh);		\
+	asm(	__asmeq("%0", __xh)				\
+		__asmeq("%1", "r2")				\
+		__asmeq("%2", "r0")				\
+		__asmeq("%3", "r4")				\
+		"bl	__do_div64"				\
+		: "=r" (__rem), "=r" (__res)			\
+		: "r" (__n), "r" (__base)			\
+		: "ip", "lr", "cc");				\
+	n = __res;						\
+	__rem;							\
+})
+
+#if __GNUC__ < 4
+
+/*
+ * gcc versions earlier than 4.0 are simply too problematic for the
+ * optimized implementation below. First there is gcc PR 15089 that
+ * tend to trig on more complex constructs, spurious .global __udivsi3
+ * are inserted even if none of those symbols are referenced in the
+ * generated code, and those gcc versions are not able to do constant
+ * propagation on long long values anyway.
+ */
+#define do_div(n, base) __do_div_asm(n, base)
+
+#elif __GNUC__ >= 4
+
+#include <asm/bug.h>
+
+/*
+ * If the divisor happens to be constant, we determine the appropriate
+ * inverse at compile time to turn the division into a few inline
+ * multiplications instead which is much faster. And yet only if compiling
+ * for ARMv4 or higher (we need umull/umlal) and if the gcc version is
+ * sufficiently recent to perform proper long long constant propagation.
+ * (It is unfortunate that gcc doesn't perform all this internally.)
+ */
+#define do_div(n, base)							\
+({									\
+	unsigned int __r, __b = (base);					\
+	if (!__builtin_constant_p(__b) || __b == 0) {			\
+		/* non-constant divisor (or zero): slow path */		\
+		__r = __do_div_asm(n, __b);				\
+	} else if ((__b & (__b - 1)) == 0) {				\
+		/* Trivial: __b is constant and a power of 2 */		\
+		/* gcc does the right thing with this code.  */		\
+		__r = n;						\
+		__r &= (__b - 1);					\
+		n /= __b;						\
+	} else {							\
+		/* Multiply by inverse of __b: n/b = n*(p/b)/p       */	\
+		/* We rely on the fact that most of this code gets   */	\
+		/* optimized away at compile time due to constant    */	\
+		/* propagation and only a couple inline assembly     */	\
+		/* instructions should remain. Better avoid any      */	\
+		/* code construct that might prevent that.           */	\
+		unsigned long long __res, __x, __t, __m, __n = n;	\
+		unsigned int __c, __p, __z = 0;				\
+		/* preserve low part of n for reminder computation */	\
+		__r = __n;						\
+		/* determine number of bits to represent __b */		\
+		__p = 1 << __div64_fls(__b);				\
+		/* compute __m = ((__p << 64) + __b - 1) / __b */	\
+		__m = (~0ULL / __b) * __p;				\
+		__m += (((~0ULL % __b + 1) * __p) + __b - 1) / __b;	\
+		/* compute __res = __m*(~0ULL/__b*__b-1)/(__p << 64) */	\
+		__x = ~0ULL / __b * __b - 1;				\
+		__res = (__m & 0xffffffff) * (__x & 0xffffffff);	\
+		__res >>= 32;						\
+		__res += (__m & 0xffffffff) * (__x >> 32);		\
+		__t = __res;						\
+		__res += (__x & 0xffffffff) * (__m >> 32);		\
+		__t = (__res < __t) ? (1ULL << 32) : 0;			\
+		__res = (__res >> 32) + __t;				\
+		__res += (__m >> 32) * (__x >> 32);			\
+		__res /= __p;						\
+		/* Now sanitize and optimize what we've got. */		\
+		if (~0ULL % (__b / (__b & -__b)) == 0) {		\
+			/* those cases can be simplified with: */	\
+			__n /= (__b & -__b);				\
+			__m = ~0ULL / (__b / (__b & -__b));		\
+			__p = 1;					\
+			__c = 1;					\
+		} else if (__res != __x / __b) {			\
+			/* We can't get away without a correction    */	\
+			/* to compensate for bit truncation errors.  */	\
+			/* To avoid it we'd need an additional bit   */	\
+			/* to represent __m which would overflow it. */	\
+			/* Instead we do m=p/b and n/b=(n*m+m)/p.    */	\
+			__c = 1;					\
+			/* Compute __m = (__p << 64) / __b */		\
+			__m = (~0ULL / __b) * __p;			\
+			__m += ((~0ULL % __b + 1) * __p) / __b;		\
+		} else {						\
+			/* Reduce __m/__p, and try to clear bit 31   */	\
+			/* of __m when possible otherwise that'll    */	\
+			/* need extra overflow handling later.       */	\
+			unsigned int __bits = -(__m & -__m);		\
+			__bits |= __m >> 32;				\
+			__bits = (~__bits) << 1;			\
+			/* If __bits == 0 then setting bit 31 is     */	\
+			/* unavoidable.  Simply apply the maximum    */	\
+			/* possible reduction in that case.          */	\
+			/* Otherwise the MSB of __bits indicates the */	\
+			/* best reduction we should apply.           */	\
+			if (!__bits) {					\
+				__p /= (__m & -__m);			\
+				__m /= (__m & -__m);			\
+			} else {					\
+				__p >>= __div64_fls(__bits);		\
+				__m >>= __div64_fls(__bits);		\
+			}						\
+			/* No correction needed. */			\
+			__c = 0;					\
+		}							\
+		/* Now we have a combination of 2 conditions:        */	\
+		/* 1) whether or not we need a correction (__c), and */	\
+		/* 2) whether or not there might be an overflow in   */	\
+		/*    the cross product (__m & ((1<<63) | (1<<31)))  */	\
+		/* Select the best insn combination to perform the   */	\
+		/* actual __m * __n / (__p << 64) operation.         */	\
+		if (!__c) {						\
+			asm (	"umull	%Q0, %R0, %1, %Q2\n\t"		\
+				"mov	%Q0, #0"			\
+				: "=&r" (__res)				\
+				: "r" (__m), "r" (__n)			\
+				: "cc" );				\
+		} else if (!(__m & ((1ULL << 63) | (1ULL << 31)))) {	\
+			__res = __m;					\
+			asm (	"umlal	%Q0, %R0, %Q1, %Q2\n\t"		\
+				"mov	%Q0, #0"			\
+				: "+&r" (__res)				\
+				: "r" (__m), "r" (__n)			\
+				: "cc" );				\
+		} else {						\
+			asm (	"umull	%Q0, %R0, %Q1, %Q2\n\t"		\
+				"cmn	%Q0, %Q1\n\t"			\
+				"adcs	%R0, %R0, %R1\n\t"		\
+				"adc	%Q0, %3, #0"			\
+				: "=&r" (__res)				\
+				: "r" (__m), "r" (__n), "r" (__z)	\
+				: "cc" );				\
+		}							\
+		if (!(__m & ((1ULL << 63) | (1ULL << 31)))) {		\
+			asm (	"umlal	%R0, %Q0, %R1, %Q2\n\t"		\
+				"umlal	%R0, %Q0, %Q1, %R2\n\t"		\
+				"mov	%R0, #0\n\t"			\
+				"umlal	%Q0, %R0, %R1, %R2"		\
+				: "+&r" (__res)				\
+				: "r" (__m), "r" (__n)			\
+				: "cc" );				\
+		} else {						\
+			asm (	"umlal	%R0, %Q0, %R2, %Q3\n\t"		\
+				"umlal	%R0, %1, %Q2, %R3\n\t"		\
+				"mov	%R0, #0\n\t"			\
+				"adds	%Q0, %1, %Q0\n\t"		\
+				"adc	%R0, %R0, #0\n\t"		\
+				"umlal	%Q0, %R0, %R2, %R3"		\
+				: "+&r" (__res), "+&r" (__z)		\
+				: "r" (__m), "r" (__n)			\
+				: "cc" );				\
+		}							\
+		__res /= __p;						\
+		/* The reminder can be computed with 32-bit regs     */	\
+		/* only, and gcc is good at that.                    */	\
+		{							\
+			unsigned int __res0 = __res;			\
+			unsigned int __b0 = __b;			\
+			__r -= __res0 * __b0;				\
+		}							\
+		/* BUG_ON(__r >= __b || __res * __b + __r != n); */	\
+		n = __res;						\
+	}								\
+	__r;								\
+})
+
+/* our own fls implementation to make sure constant propagation is fine */
+#define __div64_fls(bits)						\
+({									\
+	unsigned int __left = (bits), __nr = 0;				\
+	if (__left & 0xffff0000) __nr += 16, __left >>= 16;		\
+	if (__left & 0x0000ff00) __nr +=  8, __left >>=  8;		\
+	if (__left & 0x000000f0) __nr +=  4, __left >>=  4;		\
+	if (__left & 0x0000000c) __nr +=  2, __left >>=  2;		\
+	if (__left & 0x00000002) __nr +=  1;				\
+	__nr;								\
+})
+
+#endif
+
+static inline uint64_t div64(uint64_t n, uint32_t base)
+{
+	do_div(n, base);
+	return n;
+}
+
+#endif
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/elf.h b/xen/include/asm-arm/elf.h
new file mode 100644
index 0000000..12d487c
--- /dev/null
+++ b/xen/include/asm-arm/elf.h
@@ -0,0 +1,33 @@
+#ifndef __ARM_ELF_H__
+#define __ARM_ELF_H__
+
+typedef struct {
+    unsigned long r0;
+    unsigned long r1;
+    unsigned long r2;
+    unsigned long r3;
+    unsigned long r4;
+    unsigned long r5;
+    unsigned long r6;
+    unsigned long r7;
+    unsigned long r8;
+    unsigned long r9;
+    unsigned long r10;
+    unsigned long r11;
+    unsigned long r12;
+    unsigned long sp;
+    unsigned long lr;
+    unsigned long pc;
+} ELF_Gregset;
+
+#endif /* __ARM_ELF_H__ */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/event.h b/xen/include/asm-arm/event.h
new file mode 100644
index 0000000..6b2fb7c
--- /dev/null
+++ b/xen/include/asm-arm/event.h
@@ -0,0 +1,41 @@
+#ifndef __ASM_EVENT_H__
+#define __ASM_EVENT_H__
+
+void vcpu_kick(struct vcpu *v);
+void vcpu_mark_events_pending(struct vcpu *v);
+
+static inline int local_events_need_delivery(void)
+{
+    /* TODO
+     * return (vcpu_info(v, evtchn_upcall_pending) &&
+                        !vcpu_info(v, evtchn_upcall_mask)); */
+        return 0;
+}
+
+int local_event_delivery_is_enabled(void);
+
+static inline void local_event_delivery_disable(void)
+{
+    /* TODO current->vcpu_info->evtchn_upcall_mask = 1; */
+}
+
+static inline void local_event_delivery_enable(void)
+{
+    /* TODO current->vcpu_info->evtchn_upcall_mask = 0; */
+}
+
+/* No arch specific virq definition now. Default to global. */
+static inline int arch_virq_is_global(int virq)
+{
+    return 1;
+}
+
+#endif
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/flushtlb.h b/xen/include/asm-arm/flushtlb.h
new file mode 100644
index 0000000..c8486fc
--- /dev/null
+++ b/xen/include/asm-arm/flushtlb.h
@@ -0,0 +1,31 @@
+#ifndef __FLUSHTLB_H__
+#define __FLUSHTLB_H__
+
+#include <xen/cpumask.h>
+
+/*
+ * Filter the given set of CPUs, removing those that definitely flushed their
+ * TLB since @page_timestamp.
+ */
+/* XXX lazy implementation just doesn't clear anything.... */
+#define tlbflush_filter(mask, page_timestamp)                           \
+do {                                                                    \
+} while ( 0 )
+
+#define tlbflush_current_time()                 (0)
+
+/* Flush local TLBs */
+void flush_tlb_local(void);
+
+/* Flush specified CPUs' TLBs */
+void flush_tlb_mask(const cpumask_t *mask);
+
+#endif /* __FLUSHTLB_H__ */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/grant_table.h b/xen/include/asm-arm/grant_table.h
new file mode 100644
index 0000000..8f6ffd8
--- /dev/null
+++ b/xen/include/asm-arm/grant_table.h
@@ -0,0 +1,35 @@
+#ifndef __ASM_GRANT_TABLE_H__
+#define __ASM_GRANT_TABLE_H__
+
+#include <xen/grant_table.h>
+
+#define INVALID_GFN (-1UL)
+#define INITIAL_NR_GRANT_FRAMES 1
+
+void gnttab_clear_flag(unsigned long nr, uint16_t *addr);
+int create_grant_host_mapping(unsigned long gpaddr,
+		unsigned long mfn, unsigned int flags, unsigned int
+		cache_flags);
+#define gnttab_host_mapping_get_page_type(op, d, rd) (0)
+int replace_grant_host_mapping(unsigned long gpaddr, unsigned long mfn,
+		unsigned long new_gpaddr, unsigned int flags);
+void gnttab_mark_dirty(struct domain *d, unsigned long l);
+#define gnttab_create_status_page(d, t, i) (0)
+#define gnttab_create_shared_page(d, t, i) (0)
+#define gnttab_shared_gmfn(d, t, i) (0)
+#define gnttab_status_gmfn(d, t, i) (0)
+#define gnttab_release_host_mappings(domain) 1
+static inline int replace_grant_supported(void)
+{
+    return 1;
+}
+
+#endif /* __ASM_GRANT_TABLE_H__ */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/hardirq.h b/xen/include/asm-arm/hardirq.h
new file mode 100644
index 0000000..9c031a8
--- /dev/null
+++ b/xen/include/asm-arm/hardirq.h
@@ -0,0 +1,28 @@
+#ifndef __ASM_HARDIRQ_H
+#define __ASM_HARDIRQ_H
+
+#include <xen/config.h>
+#include <xen/cache.h>
+#include <xen/smp.h>
+
+typedef struct {
+        unsigned long __softirq_pending;
+        unsigned int __local_irq_count;
+} __cacheline_aligned irq_cpustat_t;
+
+#include <xen/irq_cpustat.h>    /* Standard mappings for irq_cpustat_t above */
+
+#define in_irq() (local_irq_count(smp_processor_id()) != 0)
+
+#define irq_enter()     (local_irq_count(smp_processor_id())++)
+#define irq_exit()      (local_irq_count(smp_processor_id())--)
+
+#endif /* __ASM_HARDIRQ_H */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/hypercall.h b/xen/include/asm-arm/hypercall.h
new file mode 100644
index 0000000..90a87ef
--- /dev/null
+++ b/xen/include/asm-arm/hypercall.h
@@ -0,0 +1,24 @@
+#ifndef __ASM_ARM_HYPERCALL_H__
+#define __ASM_ARM_HYPERCALL_H__
+
+#include <public/domctl.h> /* for arch_do_domctl */
+
+struct vcpu;
+extern long
+arch_do_vcpu_op(
+    int cmd, struct vcpu *v, XEN_GUEST_HANDLE(void) arg);
+
+extern long
+arch_do_sysctl(
+    struct xen_sysctl *op,
+    XEN_GUEST_HANDLE(xen_sysctl_t) u_sysctl);
+
+#endif /* __ASM_ARM_HYPERCALL_H__ */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/init.h b/xen/include/asm-arm/init.h
new file mode 100644
index 0000000..5f44929
--- /dev/null
+++ b/xen/include/asm-arm/init.h
@@ -0,0 +1,12 @@
+#ifndef _XEN_ASM_INIT_H
+#define _XEN_ASM_INIT_H
+
+#endif /* _XEN_ASM_INIT_H */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/io.h b/xen/include/asm-arm/io.h
new file mode 100644
index 0000000..1babbab
--- /dev/null
+++ b/xen/include/asm-arm/io.h
@@ -0,0 +1,12 @@
+#ifndef _ASM_IO_H
+#define _ASM_IO_H
+
+#endif
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/iocap.h b/xen/include/asm-arm/iocap.h
new file mode 100644
index 0000000..f647f30
--- /dev/null
+++ b/xen/include/asm-arm/iocap.h
@@ -0,0 +1,20 @@
+#ifndef __X86_IOCAP_H__
+#define __X86_IOCAP_H__
+
+#define cache_flush_permitted(d)                        \
+    (!rangeset_is_empty((d)->iomem_caps))
+
+#define multipage_allocation_permitted(d, order)        \
+    (((order) <= 9) || /* allow 2MB superpages */       \
+     !rangeset_is_empty((d)->iomem_caps))
+
+#endif
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/multicall.h b/xen/include/asm-arm/multicall.h
new file mode 100644
index 0000000..c800940
--- /dev/null
+++ b/xen/include/asm-arm/multicall.h
@@ -0,0 +1,23 @@
+#ifndef __ASM_ARM_MULTICALL_H__
+#define __ASM_ARM_MULTICALL_H__
+
+#define do_multicall_call(_call)                             \
+    do {                                                     \
+        __asm__ __volatile__ (                               \
+            ".word 0xe7f000f0@; do_multicall_call\n"         \
+            "    mov r0,#0; @ do_multicall_call\n"           \
+            "    str r0, [r0];\n"                            \
+            :                                                \
+            :                                                \
+            : );                                             \
+    } while ( 0 )
+
+#endif /* __ASM_ARM_MULTICALL_H__ */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/nmi.h b/xen/include/asm-arm/nmi.h
new file mode 100644
index 0000000..e0f19f9
--- /dev/null
+++ b/xen/include/asm-arm/nmi.h
@@ -0,0 +1,15 @@
+#ifndef ASM_NMI_H
+#define ASM_NMI_H
+
+#define register_guest_nmi_callback(a)  (-ENOSYS)
+#define unregister_guest_nmi_callback() (-ENOSYS)
+
+#endif /* ASM_NMI_H */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/numa.h b/xen/include/asm-arm/numa.h
new file mode 100644
index 0000000..cffee5c
--- /dev/null
+++ b/xen/include/asm-arm/numa.h
@@ -0,0 +1,21 @@
+#ifndef __ARCH_ARM_NUMA_H
+#define __ARCH_ARM_NUMA_H
+
+/* Fake one node for now... */
+#define cpu_to_node(cpu) 0
+#define node_to_cpumask(node)	(cpu_online_map)
+
+static inline __attribute__((pure)) int phys_to_nid(paddr_t addr)
+{
+        return 0;
+}
+
+#endif /* __ARCH_ARM_NUMA_H */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/paging.h b/xen/include/asm-arm/paging.h
new file mode 100644
index 0000000..4dc340f
--- /dev/null
+++ b/xen/include/asm-arm/paging.h
@@ -0,0 +1,13 @@
+#ifndef _XEN_PAGING_H
+#define _XEN_PAGING_H
+
+#endif /* XEN_PAGING_H */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/percpu.h b/xen/include/asm-arm/percpu.h
new file mode 100644
index 0000000..9d369eb
--- /dev/null
+++ b/xen/include/asm-arm/percpu.h
@@ -0,0 +1,28 @@
+#ifndef __ARM_PERCPU_H__
+#define __ARM_PERCPU_H__
+
+#ifndef __ASSEMBLY__
+extern char __per_cpu_start[], __per_cpu_data_end[];
+extern unsigned long __per_cpu_offset[NR_CPUS];
+void percpu_init_areas(void);
+#endif
+
+/* Separate out the type, so (int[3], foo) works. */
+#define __DEFINE_PER_CPU(type, name, suffix)                    \
+    __attribute__((__section__(".bss.percpu" #suffix)))         \
+    __typeof__(type) per_cpu_##name
+
+#define per_cpu(var, cpu) ((&per_cpu__##var)[cpu?0:0])
+#define __get_cpu_var(var) per_cpu__##var
+
+#define DECLARE_PER_CPU(type, name) extern __typeof__(type) per_cpu__##name
+
+#endif /* __ARM_PERCPU_H__ */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/processor.h b/xen/include/asm-arm/processor.h
new file mode 100644
index 0000000..1f85d31
--- /dev/null
+++ b/xen/include/asm-arm/processor.h
@@ -0,0 +1,269 @@
+#ifndef __ASM_ARM_PROCESSOR_H
+#define __ASM_ARM_PROCESSOR_H
+
+#include <asm/cpregs.h>
+
+/* PSR bits (CPSR, SPSR)*/
+
+/* 0-4: Mode */
+#define PSR_MODE_MASK 0x1f
+#define PSR_MODE_USR 0x10
+#define PSR_MODE_FIQ 0x11
+#define PSR_MODE_IRQ 0x12
+#define PSR_MODE_SVC 0x13
+#define PSR_MODE_MON 0x16
+#define PSR_MODE_ABT 0x17
+#define PSR_MODE_HYP 0x1a
+#define PSR_MODE_UND 0x1b
+#define PSR_MODE_SYS 0x1f
+
+#define PSR_THUMB        (1<<5)        /* Thumb Mode enable */
+#define PSR_FIQ_MASK        (1<<6)        /* Fast Interrupt mask */
+#define PSR_IRQ_MASK        (1<<7)        /* Interrupt mask */
+#define PSR_ABT_MASK         (1<<8)        /* Asynchronous Abort mask */
+#define PSR_BIG_ENDIAN        (1<<9)        /* Big Endian Mode */
+#define PSR_JAZELLE        (1<<24)        /* Jazelle Mode */
+
+/* TTBCR Translation Table Base Control Register */
+#define TTBCR_N_MASK 0x07
+#define TTBCR_N_16KB 0x00
+#define TTBCR_N_8KB  0x01
+#define TTBCR_N_4KB  0x02
+#define TTBCR_N_2KB  0x03
+#define TTBCR_N_1KB  0x04
+
+/* SCTLR System Control Register. */
+/* HSCTLR is a subset of this. */
+#define SCTLR_TE        (1<<30)
+#define SCTLR_AFE        (1<<29)
+#define SCTLR_TRE        (1<<28)
+#define SCTLR_NMFI        (1<<27)
+#define SCTLR_EE        (1<<25)
+#define SCTLR_VE        (1<<24)
+#define SCTLR_U                (1<<22)
+#define SCTLR_FI        (1<<21)
+#define SCTLR_WXN        (1<<19)
+#define SCTLR_HA        (1<<17)
+#define SCTLR_RR        (1<<14)
+#define SCTLR_V                (1<<13)
+#define SCTLR_I                (1<<12)
+#define SCTLR_Z                (1<<11)
+#define SCTLR_SW        (1<<10)
+#define SCTLR_B                (1<<7)
+#define SCTLR_C                (1<<2)
+#define SCTLR_A                (1<<1)
+#define SCTLR_M                (1<<0)
+
+#define SCTLR_BASE        0x00c50078
+#define HSCTLR_BASE        0x30c51878
+
+/* HCR Hyp Configuration Register */
+#define HCR_TGE                (1<<27)
+#define HCR_TVM                (1<<26)
+#define HCR_TTLB        (1<<25)
+#define HCR_TPU                (1<<24)
+#define HCR_TPC                (1<<23)
+#define HCR_TSW                (1<<22)
+#define HCR_TAC                (1<<21)
+#define HCR_TIDCP        (1<<20)
+#define HCR_TSC                (1<<19)
+#define HCR_TID3        (1<<18)
+#define HCR_TID2        (1<<17)
+#define HCR_TID1        (1<<16)
+#define HCR_TID0        (1<<15)
+#define HCR_TWE                (1<<14)
+#define HCR_TWI                (1<<13)
+#define HCR_DC                (1<<12)
+#define HCR_BSU_MASK        (3<<10)
+#define HCR_FB                (1<<9)
+#define HCR_VA                (1<<8)
+#define HCR_VI                (1<<7)
+#define HCR_VF                (1<<6)
+#define HCR_AMO                (1<<5)
+#define HCR_IMO                (1<<4)
+#define HCR_FMO                (1<<3)
+#define HCR_PTW                (1<<2)
+#define HCR_SWIO        (1<<1)
+#define HCR_VM                (1<<0)
+
+#define HSR_EC_WFI_WFE              0x01
+#define HSR_EC_CP15_32              0x03
+#define HSR_EC_CP15_64              0x04
+#define HSR_EC_CP14_32              0x05
+#define HSR_EC_CP14_DBG             0x06
+#define HSR_EC_CP                   0x07
+#define HSR_EC_CP10                 0x08
+#define HSR_EC_JAZELLE              0x09
+#define HSR_EC_BXJ                  0x0a
+#define HSR_EC_CP14_64              0x0c
+#define HSR_EC_SVC                  0x11
+#define HSR_EC_HVC                  0x12
+#define HSR_EC_INSTR_ABORT_GUEST    0x20
+#define HSR_EC_INSTR_ABORT_HYP      0x21
+#define HSR_EC_DATA_ABORT_GUEST     0x24
+#define HSR_EC_DATA_ABORT_HYP       0x25
+
+#ifndef __ASSEMBLY__
+union hsr {
+    uint32_t bits;
+    struct {
+        unsigned long iss:25;  /* Instruction Specific Syndrome */
+        unsigned long len:1;   /* Instruction length */
+        unsigned long ec:6;    /* Exception Class */
+    };
+
+    struct hsr_cp32 {
+        unsigned long read:1;  /* Direction */
+        unsigned long crm:4;   /* CRm */
+        unsigned long reg:4;   /* Rt */
+        unsigned long sbzp:1;
+        unsigned long crn:4;   /* CRn */
+        unsigned long op1:3;   /* Op1 */
+        unsigned long op2:3;   /* Op2 */
+        unsigned long cc:4;    /* Condition Code */
+        unsigned long ccvalid:1;/* CC Valid */
+        unsigned long len:1;   /* Instruction length */
+        unsigned long ec:6;    /* Exception Class */
+    } cp32; /* HSR_EC_CP15_32, CP14_32, CP10 */
+
+    struct hsr_cp64 {
+        unsigned long read:1;   /* Direction */
+        unsigned long crm:4;    /* CRm */
+        unsigned long reg1:4;   /* Rt1 */
+        unsigned long sbzp1:1;
+        unsigned long reg2:4;   /* Rt2 */
+        unsigned long sbzp2:2;
+        unsigned long op1:4;   /* Op1 */
+        unsigned long cc:4;    /* Condition Code */
+        unsigned long ccvalid:1;/* CC Valid */
+        unsigned long len:1;   /* Instruction length */
+        unsigned long ec:6;    /* Exception Class */
+    } cp64; /* HSR_EC_CP15_64, HSR_EC_CP14_64 */
+
+    struct hsr_dabt {
+        unsigned long dfsc:6;  /* Data Fault Status Code */
+        unsigned long write:1; /* Write / not Read */
+        unsigned long s1ptw:1; /* */
+        unsigned long cache:1; /* Cache Maintenance */
+        unsigned long eat:1;   /* External Abort Type */
+        unsigned long sbzp0:6;
+        unsigned long reg:4;   /* Register */
+        unsigned long sbzp1:1;
+        unsigned long sign:1;  /* Sign extend */
+        unsigned long size:2;  /* Access Size */
+        unsigned long valid:1; /* Syndrome Valid */
+        unsigned long len:1;   /* Instruction length */
+        unsigned long ec:6;    /* Exception Class */
+    } dabt; /* HSR_EC_DATA_ABORT_* */
+};
+#endif
+
+/* HSR.EC == HSR_CP{15,14,10}_32 */
+#define HSR_CP32_OP2_MASK (0x000e0000)
+#define HSR_CP32_OP2_SHIFT (17)
+#define HSR_CP32_OP1_MASK (0x0001c000)
+#define HSR_CP32_OP1_SHIFT (14)
+#define HSR_CP32_CRN_MASK (0x00003c00)
+#define HSR_CP32_CRN_SHIFT (10)
+#define HSR_CP32_CRM_MASK (0x0000001e)
+#define HSR_CP32_CRM_SHIFT (1)
+#define HSR_CP32_REGS_MASK (HSR_CP32_OP1_MASK|HSR_CP32_OP2_MASK|\
+                            HSR_CP32_CRN_MASK|HSR_CP32_CRM_MASK)
+
+/* HSR.EC == HSR_CP{15,14}_64 */
+#define HSR_CP64_OP1_MASK (0x000f0000)
+#define HSR_CP64_OP1_SHIFT (16)
+#define HSR_CP64_CRM_MASK (0x0000001e)
+#define HSR_CP64_CRM_SHIFT (1)
+#define HSR_CP64_REGS_MASK (HSR_CP64_OP1_MASK|HSR_CP64_CRM_MASK)
+
+/* Physical Address Register */
+#define PAR_F           (1<<0)
+
+/* .... If F == 1 */
+#define PAR_FSC_SHIFT   (1)
+#define PAR_FSC_MASK    (0x3f<<PAR_FSC_SHIFT)
+#define PAR_STAGE21     (1<<8)     /* Stage 2 Fault During Stage 1 Walk */
+#define PAR_STAGE2      (1<<9)     /* Stage 2 Fault */
+
+/* If F == 0 */
+#define PAR_MAIR_SHIFT  56                       /* Memory Attributes */
+#define PAR_MAIR_MASK   (0xffLL<<PAR_MAIR_SHIFT)
+#define PAR_NS          (1<<9)                   /* Non-Secure */
+#define PAR_SH_SHIFT    7                        /* Shareability */
+#define PAR_SH_MASK     (3<<PAR_SH_SHIFT)
+
+/* Fault Status Register */
+/*
+ * 543210 BIT
+ * 00XXLL -- XX Fault Level LL
+ * ..01LL -- Translation Fault LL
+ * ..10LL -- Access Fault LL
+ * ..11LL -- Permission Fault LL
+ * 01xxxx -- Abort/Parity
+ * 10xxxx -- Other
+ * 11xxxx -- Implementation Defined
+ */
+#define FSC_TYPE_MASK (0x3<<4)
+#define FSC_TYPE_FAULT (0x00<<4)
+#define FSC_TYPE_ABT   (0x01<<4)
+#define FSC_TYPE_OTH   (0x02<<4)
+#define FSC_TYPE_IMPL  (0x03<<4)
+
+#define FSC_FLT_TRANS  (0x04)
+#define FSC_FLT_ACCESS (0x08)
+#define FSC_FLT_PERM   (0x0c)
+#define FSC_SEA        (0x10) /* Synchronous External Abort */
+#define FSC_SPE        (0x18) /* Memory Access Synchronous Parity Error */
+#define FSC_APE        (0x11) /* Memory Access Asynchronous Parity Error */
+#define FSC_SEATT      (0x14) /* Sync. Ext. Abort Translation Table */
+#define FSC_SPETT      (0x1c) /* Sync. Parity. Error Translation Table */
+#define FSC_AF         (0x21) /* Alignment Fault */
+#define FSC_DE         (0x22) /* Debug Event */
+#define FSC_LKD        (0x34) /* Lockdown Abort */
+#define FSC_CPR        (0x3a) /* Coprocossor Abort */
+
+#define FSC_LL_MASK    (0x03<<0)
+
+/* Time counter hypervisor control register */
+#define CNTHCTL_PA      (1u<<0)  /* Kernel/user access to physical counter */
+#define CNTHCTL_TA      (1u<<1)  /* Kernel/user access to CNTP timer */
+
+/* Timer control registers */
+#define CNTx_CTL_ENABLE   (1u<<0)  /* Enable timer */
+#define CNTx_CTL_MASK     (1u<<1)  /* Mask IRQ */
+#define CNTx_CTL_PENDING  (1u<<2)  /* IRQ pending */
+
+/* CPUID bits */
+#define ID_PFR1_GT_MASK  0x000F0000  /* Generic Timer interface support */
+#define ID_PFR1_GT_v1    0x00010000
+
+#define MSR(reg,val)        asm volatile ("msr "#reg", %0\n" : : "r" (val))
+#define MRS(val,reg)        asm volatile ("mrs %0,"#reg"\n" : "=r" (v))
+
+#ifndef __ASSEMBLY__
+extern uint32_t hyp_traps_vector[8];
+
+void panic_PAR(uint64_t par, const char *when);
+
+void show_execution_state(struct cpu_user_regs *regs);
+void show_registers(struct cpu_user_regs *regs);
+//#define dump_execution_state() run_in_exception_handler(show_execution_state)
+#define dump_execution_state() asm volatile (".word 0xe7f000f0\n"); /* XXX */
+
+#define cpu_relax() barrier() /* Could yield? */
+
+/* All a bit UP for the moment */
+#define cpu_to_core(_cpu)   (0)
+#define cpu_to_socket(_cpu) (0)
+
+#endif /* __ASSEMBLY__ */
+#endif /* __ASM_ARM_PROCESSOR_H */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/regs.h b/xen/include/asm-arm/regs.h
new file mode 100644
index 0000000..ee095bf
--- /dev/null
+++ b/xen/include/asm-arm/regs.h
@@ -0,0 +1,43 @@
+#ifndef __ARM_REGS_H__
+#define __ARM_REGS_H__
+
+#include <xen/types.h>
+#include <public/xen.h>
+#include <asm/processor.h>
+
+#define psr_mode(psr,m) (((psr) & PSR_MODE_MASK) == m)
+
+#define usr_mode(r)     psr_mode((r)->cpsr,PSR_MODE_USR)
+#define fiq_mode(r)     psr_mode((r)->cpsr,PSR_MODE_FIQ)
+#define irq_mode(r)     psr_mode((r)->cpsr,PSR_MODE_IRQ)
+#define svc_mode(r)     psr_mode((r)->cpsr,PSR_MODE_SVC)
+#define mon_mode(r)     psr_mode((r)->cpsr,PSR_MODE_MON)
+#define abt_mode(r)     psr_mode((r)->cpsr,PSR_MODE_ABT)
+#define hyp_mode(r)     psr_mode((r)->cpsr,PSR_MODE_HYP)
+#define und_mode(r)     psr_mode((r)->cpsr,PSR_MODE_UND)
+#define sys_mode(r)     psr_mode((r)->cpsr,PSR_MODE_SYS)
+
+#define guest_mode(r)                                                         \
+({                                                                            \
+    unsigned long diff = (char *)guest_cpu_user_regs() - (char *)(r);         \
+    /* Frame pointer must point into current CPU stack. */                    \
+    ASSERT(diff < STACK_SIZE);                                                \
+    /* If not a guest frame, it must be a hypervisor frame. */                \
+    ASSERT((diff == 0) || hyp_mode(r));                                       \
+    /* Return TRUE if it's a guest frame. */                                  \
+    (diff == 0);                                                              \
+})
+
+#define return_reg(v) ((v)->arch.user_regs.r0)
+
+#define CTXT_SWITCH_STACK_BYTES (sizeof(struct cpu_user_regs))
+
+#endif /* __ARM_REGS_H__ */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/setup.h b/xen/include/asm-arm/setup.h
new file mode 100644
index 0000000..c27d438
--- /dev/null
+++ b/xen/include/asm-arm/setup.h
@@ -0,0 +1,16 @@
+#ifndef __ARM_SETUP_H_
+#define __ARM_SETUP_H_
+
+#include <public/version.h>
+
+void arch_get_xen_caps(xen_capabilities_info_t *info);
+
+#endif
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/smp.h b/xen/include/asm-arm/smp.h
new file mode 100644
index 0000000..9cdd87f
--- /dev/null
+++ b/xen/include/asm-arm/smp.h
@@ -0,0 +1,25 @@
+#ifndef __ASM_SMP_H
+#define __ASM_SMP_H
+
+#ifndef __ASSEMBLY__
+#include <xen/config.h>
+#include <xen/cpumask.h>
+#include <asm/current.h>
+#endif
+
+DECLARE_PER_CPU(cpumask_var_t, cpu_sibling_mask);
+DECLARE_PER_CPU(cpumask_var_t, cpu_core_mask);
+
+#define cpu_is_offline(cpu) unlikely(!cpu_online(cpu))
+
+#define raw_smp_processor_id() (get_processor_id())
+
+#endif
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/softirq.h b/xen/include/asm-arm/softirq.h
new file mode 100644
index 0000000..536af38
--- /dev/null
+++ b/xen/include/asm-arm/softirq.h
@@ -0,0 +1,15 @@
+#ifndef __ASM_SOFTIRQ_H__
+#define __ASM_SOFTIRQ_H__
+
+#define VGIC_SOFTIRQ        (NR_COMMON_SOFTIRQS + 0)
+#define NR_ARCH_SOFTIRQS       1
+
+#endif /* __ASM_SOFTIRQ_H__ */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/spinlock.h b/xen/include/asm-arm/spinlock.h
new file mode 100644
index 0000000..b1825c9
--- /dev/null
+++ b/xen/include/asm-arm/spinlock.h
@@ -0,0 +1,144 @@
+#ifndef __ASM_SPINLOCK_H
+#define __ASM_SPINLOCK_H
+
+#include <xen/config.h>
+#include <xen/lib.h>
+
+static inline void dsb_sev(void)
+{
+    __asm__ __volatile__ (
+        "dsb\n"
+        "sev\n"
+        );
+}
+
+typedef struct {
+    volatile unsigned int lock;
+} raw_spinlock_t;
+
+#define _RAW_SPIN_LOCK_UNLOCKED { 0 }
+
+#define _raw_spin_is_locked(x)          ((x)->lock != 0)
+
+static always_inline void _raw_spin_unlock(raw_spinlock_t *lock)
+{
+    ASSERT(_raw_spin_is_locked(lock));
+
+    smp_mb();
+
+    __asm__ __volatile__(
+"   str     %1, [%0]\n"
+    :
+    : "r" (&lock->lock), "r" (0)
+    : "cc");
+
+    dsb_sev();
+}
+
+static always_inline int _raw_spin_trylock(raw_spinlock_t *lock)
+{
+    unsigned long tmp;
+
+    __asm__ __volatile__(
+"   ldrex   %0, [%1]\n"
+"   teq     %0, #0\n"
+"   strexeq %0, %2, [%1]"
+    : "=&r" (tmp)
+    : "r" (&lock->lock), "r" (1)
+    : "cc");
+
+    if (tmp == 0) {
+        smp_mb();
+        return 1;
+    } else {
+        return 0;
+    }
+}
+
+typedef struct {
+    volatile unsigned int lock;
+} raw_rwlock_t;
+
+#define _RAW_RW_LOCK_UNLOCKED { 0 }
+
+static always_inline int _raw_read_trylock(raw_rwlock_t *rw)
+{
+    unsigned long tmp, tmp2 = 1;
+
+    __asm__ __volatile__(
+"1: ldrex   %0, [%2]\n"
+"   adds    %0, %0, #1\n"
+"   strexpl %1, %0, [%2]\n"
+    : "=&r" (tmp), "+r" (tmp2)
+    : "r" (&rw->lock)
+    : "cc");
+
+    smp_mb();
+    return tmp2 == 0;
+}
+
+static always_inline int _raw_write_trylock(raw_rwlock_t *rw)
+{
+    unsigned long tmp;
+
+    __asm__ __volatile__(
+"1: ldrex   %0, [%1]\n"
+"   teq     %0, #0\n"
+"   strexeq %0, %2, [%1]"
+    : "=&r" (tmp)
+    : "r" (&rw->lock), "r" (0x80000000)
+    : "cc");
+
+    if (tmp == 0) {
+        smp_mb();
+        return 1;
+    } else {
+        return 0;
+    }
+}
+
+static inline void _raw_read_unlock(raw_rwlock_t *rw)
+{
+    unsigned long tmp, tmp2;
+
+    smp_mb();
+
+    __asm__ __volatile__(
+"1: ldrex   %0, [%2]\n"
+"   sub     %0, %0, #1\n"
+"   strex   %1, %0, [%2]\n"
+"   teq     %1, #0\n"
+"   bne     1b"
+    : "=&r" (tmp), "=&r" (tmp2)
+    : "r" (&rw->lock)
+    : "cc");
+
+    if (tmp == 0)
+        dsb_sev();
+}
+
+static inline void _raw_write_unlock(raw_rwlock_t *rw)
+{
+    smp_mb();
+
+    __asm__ __volatile__(
+    "str    %1, [%0]\n"
+    :
+    : "r" (&rw->lock), "r" (0)
+    : "cc");
+
+    dsb_sev();
+}
+
+#define _raw_rw_is_locked(x) ((x)->lock != 0)
+#define _raw_rw_is_write_locked(x) ((x)->lock == 0x80000000)
+
+#endif /* __ASM_SPINLOCK_H */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/string.h b/xen/include/asm-arm/string.h
new file mode 100644
index 0000000..f2d643d
--- /dev/null
+++ b/xen/include/asm-arm/string.h
@@ -0,0 +1,38 @@
+#ifndef __ARM_STRING_H__
+#define __ARM_STRING_H__
+
+#include <xen/config.h>
+
+#define __HAVE_ARCH_MEMCPY
+extern void * memcpy(void *, const void *, __kernel_size_t);
+
+/* Some versions of gcc don't have this builtin. It's non-critical anyway. */
+#define __HAVE_ARCH_MEMMOVE
+extern void *memmove(void *dest, const void *src, size_t n);
+
+#define __HAVE_ARCH_MEMSET
+extern void * memset(void *, int, __kernel_size_t);
+
+extern void __memzero(void *ptr, __kernel_size_t n);
+
+#define memset(p,v,n)                                                   \
+        ({                                                              \
+                void *__p = (p); size_t __n = n;                        \
+                if ((__n) != 0) {                                       \
+                        if (__builtin_constant_p((v)) && (v) == 0)      \
+                                __memzero((__p),(__n));                 \
+                        else                                            \
+                                memset((__p),(v),(__n));                \
+                }                                                       \
+                (__p);                                                  \
+        })
+
+#endif /* __ARM_STRING_H__ */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/system.h b/xen/include/asm-arm/system.h
new file mode 100644
index 0000000..731d89f
--- /dev/null
+++ b/xen/include/asm-arm/system.h
@@ -0,0 +1,202 @@
+/* Portions taken from Linux arch arm */
+#ifndef __ASM_SYSTEM_H
+#define __ASM_SYSTEM_H
+
+#include <xen/lib.h>
+#include <asm/processor.h>
+
+#define nop() \
+    asm volatile ( "nop" )
+
+#define xchg(ptr,x) \
+        ((__typeof__(*(ptr)))__xchg((unsigned long)(x),(ptr),sizeof(*(ptr))))
+
+#define isb() __asm__ __volatile__ ("isb" : : : "memory")
+#define dsb() __asm__ __volatile__ ("dsb" : : : "memory")
+#define dmb() __asm__ __volatile__ ("dmb" : : : "memory")
+
+#define mb()            dsb()
+#define rmb()           dsb()
+#define wmb()           mb()
+
+#define smp_mb()        dmb()
+#define smp_rmb()       dmb()
+#define smp_wmb()       dmb()
+
+/*
+ * This is used to ensure the compiler did actually allocate the register we
+ * asked it for some inline assembly sequences.  Apparently we can't trust
+ * the compiler from one version to another so a bit of paranoia won't hurt.
+ * This string is meant to be concatenated with the inline asm string and
+ * will cause compilation to stop on mismatch.
+ * (for details, see gcc PR 15089)
+ */
+#define __asmeq(x, y)  ".ifnc " x "," y " ; .err ; .endif\n\t"
+
+extern void __bad_xchg(volatile void *, int);
+
+static inline unsigned long __xchg(unsigned long x, volatile void *ptr, int size)
+{
+        unsigned long ret;
+        unsigned int tmp;
+
+        smp_mb();
+
+        switch (size) {
+        case 1:
+                asm volatile("@ __xchg1\n"
+                "1:     ldrexb  %0, [%3]\n"
+                "       strexb  %1, %2, [%3]\n"
+                "       teq     %1, #0\n"
+                "       bne     1b"
+                        : "=&r" (ret), "=&r" (tmp)
+                        : "r" (x), "r" (ptr)
+                        : "memory", "cc");
+                break;
+        case 4:
+                asm volatile("@ __xchg4\n"
+                "1:     ldrex   %0, [%3]\n"
+                "       strex   %1, %2, [%3]\n"
+                "       teq     %1, #0\n"
+                "       bne     1b"
+                        : "=&r" (ret), "=&r" (tmp)
+                        : "r" (x), "r" (ptr)
+                        : "memory", "cc");
+                break;
+        default:
+                __bad_xchg(ptr, size), ret = 0;
+                break;
+        }
+        smp_mb();
+
+        return ret;
+}
+
+/*
+ * Atomic compare and exchange.  Compare OLD with MEM, if identical,
+ * store NEW in MEM.  Return the initial value in MEM.  Success is
+ * indicated by comparing RETURN with OLD.
+ */
+
+extern void __bad_cmpxchg(volatile void *ptr, int size);
+
+static always_inline unsigned long __cmpxchg(
+    volatile void *ptr, unsigned long old, unsigned long new, int size)
+{
+    unsigned long /*long*/ oldval, res;
+
+    switch (size) {
+    case 1:
+        do {
+            asm volatile("@ __cmpxchg1\n"
+                         "       ldrexb  %1, [%2]\n"
+                         "       mov     %0, #0\n"
+                         "       teq     %1, %3\n"
+                         "       strexbeq %0, %4, [%2]\n"
+                         : "=&r" (res), "=&r" (oldval)
+                         : "r" (ptr), "Ir" (old), "r" (new)
+                         : "memory", "cc");
+        } while (res);
+        break;
+    case 2:
+        do {
+            asm volatile("@ __cmpxchg2\n"
+                         "       ldrexh  %1, [%2]\n"
+                         "       mov     %0, #0\n"
+                         "       teq     %1, %3\n"
+                         "       strexheq %0, %4, [%2]\n"
+                         : "=&r" (res), "=&r" (oldval)
+                         : "r" (ptr), "Ir" (old), "r" (new)
+                         : "memory", "cc");
+        } while (res);
+        break;
+    case 4:
+        do {
+            asm volatile("@ __cmpxchg4\n"
+                         "       ldrex   %1, [%2]\n"
+                         "       mov     %0, #0\n"
+                         "       teq     %1, %3\n"
+                         "       strexeq %0, %4, [%2]\n"
+                         : "=&r" (res), "=&r" (oldval)
+                         : "r" (ptr), "Ir" (old), "r" (new)
+                         : "memory", "cc");
+        } while (res);
+        break;
+#if 0
+    case 8:
+        do {
+            asm volatile("@ __cmpxchg8\n"
+                         "       ldrexd   %1, [%2]\n"
+                         "       mov      %0, #0\n"
+                         "       teq      %1, %3\n"
+                         "       strexdeq %0, %4, [%2]\n"
+                         : "=&r" (res), "=&r" (oldval)
+                         : "r" (ptr), "Ir" (old), "r" (new)
+                         : "memory", "cc");
+        } while (res);
+        break;
+#endif
+    default:
+        __bad_cmpxchg(ptr, size);
+        oldval = 0;
+    }
+
+    return oldval;
+}
+#define cmpxchg(ptr,o,n)                                                \
+    ((__typeof__(*(ptr)))__cmpxchg((ptr),(unsigned long)(o),            \
+                                   (unsigned long)(n),sizeof(*(ptr))))
+
+#define local_irq_disable() asm volatile ( "cpsid i @ local_irq_disable\n" : : : "cc" )
+#define local_irq_enable()  asm volatile ( "cpsie i @ local_irq_enable\n" : : : "cc" )
+
+#define local_save_flags(x)                                      \
+({                                                               \
+    BUILD_BUG_ON(sizeof(x) != sizeof(long));                     \
+    asm volatile ( "mrs %0, cpsr     @ local_save_flags\n"       \
+                  : "=r" (x) :: "memory", "cc" );                \
+})
+#define local_irq_save(x)                                        \
+({                                                               \
+    local_save_flags(x);                                         \
+    local_irq_disable();                                         \
+})
+#define local_irq_restore(x)                                     \
+({                                                               \
+    BUILD_BUG_ON(sizeof(x) != sizeof(long));                     \
+    asm volatile (                                               \
+            "msr     cpsr_c, %0      @ local_irq_restore\n"      \
+            :                                                    \
+            : "r" (flags)                                        \
+            : "memory", "cc");                                   \
+})
+
+static inline int local_irq_is_enabled(void)
+{
+    unsigned long flags;
+    local_save_flags(flags);
+    return !(flags & PSR_IRQ_MASK);
+}
+
+#define local_fiq_enable()  __asm__("cpsie f   @ __stf\n" : : : "memory", "cc")
+#define local_fiq_disable() __asm__("cpsid f   @ __clf\n" : : : "memory", "cc")
+
+#define local_abort_enable() __asm__("cpsie a  @ __sta\n" : : : "memory", "cc")
+#define local_abort_disable() __asm__("cpsid a @ __sta\n" : : : "memory", "cc")
+
+static inline int local_fiq_is_enabled(void)
+{
+    unsigned long flags;
+    local_save_flags(flags);
+    return !!(flags & PSR_FIQ_MASK);
+}
+
+#endif
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/trace.h b/xen/include/asm-arm/trace.h
new file mode 100644
index 0000000..db84541
--- /dev/null
+++ b/xen/include/asm-arm/trace.h
@@ -0,0 +1,12 @@
+#ifndef __ASM_TRACE_H__
+#define __ASM_TRACE_H__
+
+#endif /* __ASM_TRACE_H__ */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/types.h b/xen/include/asm-arm/types.h
new file mode 100644
index 0000000..48864f9
--- /dev/null
+++ b/xen/include/asm-arm/types.h
@@ -0,0 +1,57 @@
+#ifndef __ARM_TYPES_H__
+#define __ARM_TYPES_H__
+
+#ifndef __ASSEMBLY__
+
+#include <xen/config.h>
+
+typedef __signed__ char __s8;
+typedef unsigned char __u8;
+
+typedef __signed__ short __s16;
+typedef unsigned short __u16;
+
+typedef __signed__ int __s32;
+typedef unsigned int __u32;
+
+#if defined(__GNUC__) && !defined(__STRICT_ANSI__)
+typedef __signed__ long long __s64;
+typedef unsigned long long __u64;
+#endif
+
+typedef signed char s8;
+typedef unsigned char u8;
+
+typedef signed short s16;
+typedef unsigned short u16;
+
+typedef signed int s32;
+typedef unsigned int u32;
+
+typedef signed long long s64;
+typedef unsigned long long u64;
+typedef u64 paddr_t;
+#define INVALID_PADDR (~0ULL)
+#define PRIpaddr "016llx"
+
+typedef unsigned long size_t;
+
+typedef char bool_t;
+#define test_and_set_bool(b)   xchg(&(b), 1)
+#define test_and_clear_bool(b) xchg(&(b), 0)
+
+#endif /* __ASSEMBLY__ */
+
+#define BITS_PER_LONG 32
+#define BYTES_PER_LONG 4
+#define LONG_BYTEORDER 2
+
+#endif /* __ARM_TYPES_H__ */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/xenoprof.h b/xen/include/asm-arm/xenoprof.h
new file mode 100644
index 0000000..131ac13
--- /dev/null
+++ b/xen/include/asm-arm/xenoprof.h
@@ -0,0 +1,12 @@
+#ifndef __ASM_XENOPROF_H__
+#define __ASM_XENOPROF_H__
+
+#endif /* __ASM_XENOPROF_H__ */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
new file mode 100644
index 0000000..4d1daa9
--- /dev/null
+++ b/xen/include/public/arch-arm.h
@@ -0,0 +1,125 @@
+/******************************************************************************
+ * arch-arm.h
+ *
+ * Guest OS interface to ARM 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 2011 (C) Citrix Systems
+ */
+
+#ifndef __XEN_PUBLIC_ARCH_ARM_H__
+#define __XEN_PUBLIC_ARCH_ARM_H__
+
+#ifndef __ASSEMBLY__
+#define ___DEFINE_XEN_GUEST_HANDLE(name, type) \
+    typedef struct { type *p; } __guest_handle_ ## name
+
+#define __DEFINE_XEN_GUEST_HANDLE(name, type) \
+    ___DEFINE_XEN_GUEST_HANDLE(name, type);   \
+    ___DEFINE_XEN_GUEST_HANDLE(const_##name, const type)
+#define DEFINE_XEN_GUEST_HANDLE(name)   __DEFINE_XEN_GUEST_HANDLE(name, name)
+#define __XEN_GUEST_HANDLE(name)        __guest_handle_ ## name
+#define XEN_GUEST_HANDLE(name)          __XEN_GUEST_HANDLE(name)
+#define set_xen_guest_handle_raw(hnd, val)  do { (hnd).p = val; } while (0)
+#ifdef __XEN_TOOLS__
+#define get_xen_guest_handle(val, hnd)  do { val = (hnd).p; } while (0)
+#endif
+#define set_xen_guest_handle(hnd, val) set_xen_guest_handle_raw(hnd, val)
+
+struct cpu_user_regs
+{
+    uint32_t r0;
+    uint32_t r1;
+    uint32_t r2;
+    uint32_t r3;
+    uint32_t r4;
+    uint32_t r5;
+    uint32_t r6;
+    uint32_t r7;
+    uint32_t r8;
+    uint32_t r9;
+    uint32_t r10;
+    union {
+	uint32_t r11;
+	uint32_t fp;
+    };
+    uint32_t r12;
+
+    uint32_t sp; /* r13 - SP: Valid for Hyp. frames only, o/w banked (see below) */
+    uint32_t lr; /* r14 - LR: Valid for Hyp. Same physical register as lr_usr. */
+
+    uint32_t pc; /* Return IP */
+    uint32_t cpsr; /* Return mode */
+    uint32_t pad0; /* Doubleword-align the kernel half of the frame */
+
+    /* Outer guest frame only from here on... */
+
+    uint32_t r8_fiq, r9_fiq, r10_fiq, r11_fiq, r12_fiq;
+
+    uint32_t sp_usr, sp_svc, sp_abt, sp_und, sp_irq, sp_fiq;
+    uint32_t lr_usr, lr_svc, lr_abt, lr_und, lr_irq, lr_fiq;
+
+    uint32_t spsr_svc, spsr_abt, spsr_und, spsr_irq, spsr_fiq;
+};
+typedef struct cpu_user_regs cpu_user_regs_t;
+DEFINE_XEN_GUEST_HANDLE(cpu_user_regs_t);
+
+typedef uint64_t xen_pfn_t;
+#define PRI_xen_pfn PRIx64
+
+/* Maximum number of virtual CPUs in legacy multi-processor guests. */
+/* Only one. All other VCPUS must use VCPUOP_register_vcpu_info */
+#define XEN_LEGACY_MAX_VCPUS 1
+
+typedef uint32_t xen_ulong_t;
+
+struct vcpu_guest_context {
+    struct cpu_user_regs user_regs;         /* User-level CPU registers     */
+    union {
+	uint32_t reg[16];
+	struct {
+	    uint32_t __pad[12];
+	    uint32_t sp; /* r13 */
+	    uint32_t lr; /* r14 */
+	    uint32_t pc; /* r15 */
+	};
+    };
+};
+typedef struct vcpu_guest_context vcpu_guest_context_t;
+DEFINE_XEN_GUEST_HANDLE(vcpu_guest_context_t);
+
+struct arch_vcpu_info { };
+typedef struct arch_vcpu_info arch_vcpu_info_t;
+
+struct arch_shared_info { };
+typedef struct arch_shared_info arch_shared_info_t;
+#endif
+
+#endif /*  __XEN_PUBLIC_ARCH_ARM_H__ */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
index fde9fa5..7196400 100644
--- a/xen/include/public/xen.h
+++ b/xen/include/public/xen.h
@@ -33,6 +33,8 @@
 #include "arch-x86/xen.h"
 #elif defined(__ia64__)
 #include "arch-ia64.h"
+#elif defined(__arm__)
+#include "arch-arm.h"
 #else
 #error "Unsupported architecture"
 #endif
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 18:20:36 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 18:20:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXzcs-0007sw-UW; Tue, 06 Dec 2011 18:20:22 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RXzcr-0007sC-K7
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 18:20:21 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1323195573!4508317!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDcxMjI=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13365 invoked from network); 6 Dec 2011 18:19:35 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Dec 2011 18:19:35 -0000
X-IronPort-AV: E=Sophos;i="4.71,307,1320642000"; d="scan'208";a="19721936"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Dec 2011 13:19:35 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Tue, 6 Dec 2011 13:19:35 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pB6IJEjD019549;
	Tue, 6 Dec 2011 10:19:18 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Tue, 6 Dec 2011 18:19:47 +0000
Message-ID: <1323195609-17277-3-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1112061753410.31179@kaball-desktop>
References: <alpine.DEB.2.00.1112061753410.31179@kaball-desktop>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>, Tim.Deegan@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH RFC 03/25] Move cpufreq option parsing to
	cpufreq.c
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
---
 xen/common/domain.c           |   35 ++---------------------------------
 xen/drivers/cpufreq/cpufreq.c |   31 +++++++++++++++++++++++++++++++
 xen/include/xen/domain.h      |    2 ++
 3 files changed, 35 insertions(+), 33 deletions(-)

diff --git a/xen/common/domain.c b/xen/common/domain.c
index b75fc1d..f751d8f 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -31,8 +31,8 @@
 #include <xen/grant_table.h>
 #include <xen/xenoprof.h>
 #include <xen/irq.h>
-#include <acpi/cpufreq/cpufreq.h>
 #include <asm/debugger.h>
+#include <asm/processor.h>
 #include <public/sched.h>
 #include <public/sysctl.h>
 #include <public/vcpu.h>
@@ -45,40 +45,9 @@
 unsigned int xen_processor_pmbits = XEN_PROCESSOR_PM_PX;
 
 /* opt_dom0_vcpus_pin: If true, dom0 VCPUs are pinned. */
-static bool_t opt_dom0_vcpus_pin;
+bool_t opt_dom0_vcpus_pin;
 boolean_param("dom0_vcpus_pin", opt_dom0_vcpus_pin);
 
-/* set xen as default cpufreq */
-enum cpufreq_controller cpufreq_controller = FREQCTL_xen;
-
-static void __init setup_cpufreq_option(char *str)
-{
-    char *arg;
-
-    if ( !strcmp(str, "dom0-kernel") )
-    {
-        xen_processor_pmbits &= ~XEN_PROCESSOR_PM_PX;
-        cpufreq_controller = FREQCTL_dom0_kernel;
-        opt_dom0_vcpus_pin = 1;
-        return;
-    }
-
-    if ( !strcmp(str, "none") )
-    {
-        xen_processor_pmbits &= ~XEN_PROCESSOR_PM_PX;
-        cpufreq_controller = FREQCTL_none;
-        return;
-    }
-
-    if ( (arg = strpbrk(str, ",:")) != NULL )
-        *arg++ = '\0';
-
-    if ( !strcmp(str, "xen") )
-        if ( arg && *arg )
-            cpufreq_cmdline_parse(arg);
-}
-custom_param("cpufreq", setup_cpufreq_option);
-
 /* Protect updates/reads (resp.) of domain_list and domain_hash. */
 DEFINE_SPINLOCK(domlist_update_lock);
 DEFINE_RCU_READ_LOCK(domlist_read_lock);
diff --git a/xen/drivers/cpufreq/cpufreq.c b/xen/drivers/cpufreq/cpufreq.c
index f49ea1c..34ea2a9 100644
--- a/xen/drivers/cpufreq/cpufreq.c
+++ b/xen/drivers/cpufreq/cpufreq.c
@@ -61,6 +61,37 @@ static LIST_HEAD_READ_MOSTLY(cpufreq_dom_list_head);
 struct cpufreq_governor *__read_mostly cpufreq_opt_governor;
 LIST_HEAD_READ_MOSTLY(cpufreq_governor_list);
 
+/* set xen as default cpufreq */
+enum cpufreq_controller cpufreq_controller = FREQCTL_xen;
+
+static void __init setup_cpufreq_option(char *str)
+{
+    char *arg;
+
+    if ( !strcmp(str, "dom0-kernel") )
+    {
+        xen_processor_pmbits &= ~XEN_PROCESSOR_PM_PX;
+        cpufreq_controller = FREQCTL_dom0_kernel;
+        opt_dom0_vcpus_pin = 1;
+        return;
+    }
+
+    if ( !strcmp(str, "none") )
+    {
+        xen_processor_pmbits &= ~XEN_PROCESSOR_PM_PX;
+        cpufreq_controller = FREQCTL_none;
+        return;
+    }
+
+    if ( (arg = strpbrk(str, ",:")) != NULL )
+        *arg++ = '\0';
+
+    if ( !strcmp(str, "xen") )
+        if ( arg && *arg )
+            cpufreq_cmdline_parse(arg);
+}
+custom_param("cpufreq", setup_cpufreq_option);
+
 bool_t __read_mostly cpufreq_verbose;
 
 struct cpufreq_governor *__find_governor(const char *governor)
diff --git a/xen/include/xen/domain.h b/xen/include/xen/domain.h
index 765e132..de3e8db 100644
--- a/xen/include/xen/domain.h
+++ b/xen/include/xen/domain.h
@@ -85,4 +85,6 @@ int continue_hypercall_on_cpu(
 
 extern unsigned int xen_processor_pmbits;
 
+extern bool_t opt_dom0_vcpus_pin;
+
 #endif /* __XEN_DOMAIN_H__ */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 18:20:36 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 18:20:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXzcs-0007sw-UW; Tue, 06 Dec 2011 18:20:22 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RXzcr-0007sC-K7
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 18:20:21 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1323195573!4508317!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDcxMjI=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13365 invoked from network); 6 Dec 2011 18:19:35 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Dec 2011 18:19:35 -0000
X-IronPort-AV: E=Sophos;i="4.71,307,1320642000"; d="scan'208";a="19721936"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Dec 2011 13:19:35 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Tue, 6 Dec 2011 13:19:35 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pB6IJEjD019549;
	Tue, 6 Dec 2011 10:19:18 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Tue, 6 Dec 2011 18:19:47 +0000
Message-ID: <1323195609-17277-3-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1112061753410.31179@kaball-desktop>
References: <alpine.DEB.2.00.1112061753410.31179@kaball-desktop>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>, Tim.Deegan@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH RFC 03/25] Move cpufreq option parsing to
	cpufreq.c
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
---
 xen/common/domain.c           |   35 ++---------------------------------
 xen/drivers/cpufreq/cpufreq.c |   31 +++++++++++++++++++++++++++++++
 xen/include/xen/domain.h      |    2 ++
 3 files changed, 35 insertions(+), 33 deletions(-)

diff --git a/xen/common/domain.c b/xen/common/domain.c
index b75fc1d..f751d8f 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -31,8 +31,8 @@
 #include <xen/grant_table.h>
 #include <xen/xenoprof.h>
 #include <xen/irq.h>
-#include <acpi/cpufreq/cpufreq.h>
 #include <asm/debugger.h>
+#include <asm/processor.h>
 #include <public/sched.h>
 #include <public/sysctl.h>
 #include <public/vcpu.h>
@@ -45,40 +45,9 @@
 unsigned int xen_processor_pmbits = XEN_PROCESSOR_PM_PX;
 
 /* opt_dom0_vcpus_pin: If true, dom0 VCPUs are pinned. */
-static bool_t opt_dom0_vcpus_pin;
+bool_t opt_dom0_vcpus_pin;
 boolean_param("dom0_vcpus_pin", opt_dom0_vcpus_pin);
 
-/* set xen as default cpufreq */
-enum cpufreq_controller cpufreq_controller = FREQCTL_xen;
-
-static void __init setup_cpufreq_option(char *str)
-{
-    char *arg;
-
-    if ( !strcmp(str, "dom0-kernel") )
-    {
-        xen_processor_pmbits &= ~XEN_PROCESSOR_PM_PX;
-        cpufreq_controller = FREQCTL_dom0_kernel;
-        opt_dom0_vcpus_pin = 1;
-        return;
-    }
-
-    if ( !strcmp(str, "none") )
-    {
-        xen_processor_pmbits &= ~XEN_PROCESSOR_PM_PX;
-        cpufreq_controller = FREQCTL_none;
-        return;
-    }
-
-    if ( (arg = strpbrk(str, ",:")) != NULL )
-        *arg++ = '\0';
-
-    if ( !strcmp(str, "xen") )
-        if ( arg && *arg )
-            cpufreq_cmdline_parse(arg);
-}
-custom_param("cpufreq", setup_cpufreq_option);
-
 /* Protect updates/reads (resp.) of domain_list and domain_hash. */
 DEFINE_SPINLOCK(domlist_update_lock);
 DEFINE_RCU_READ_LOCK(domlist_read_lock);
diff --git a/xen/drivers/cpufreq/cpufreq.c b/xen/drivers/cpufreq/cpufreq.c
index f49ea1c..34ea2a9 100644
--- a/xen/drivers/cpufreq/cpufreq.c
+++ b/xen/drivers/cpufreq/cpufreq.c
@@ -61,6 +61,37 @@ static LIST_HEAD_READ_MOSTLY(cpufreq_dom_list_head);
 struct cpufreq_governor *__read_mostly cpufreq_opt_governor;
 LIST_HEAD_READ_MOSTLY(cpufreq_governor_list);
 
+/* set xen as default cpufreq */
+enum cpufreq_controller cpufreq_controller = FREQCTL_xen;
+
+static void __init setup_cpufreq_option(char *str)
+{
+    char *arg;
+
+    if ( !strcmp(str, "dom0-kernel") )
+    {
+        xen_processor_pmbits &= ~XEN_PROCESSOR_PM_PX;
+        cpufreq_controller = FREQCTL_dom0_kernel;
+        opt_dom0_vcpus_pin = 1;
+        return;
+    }
+
+    if ( !strcmp(str, "none") )
+    {
+        xen_processor_pmbits &= ~XEN_PROCESSOR_PM_PX;
+        cpufreq_controller = FREQCTL_none;
+        return;
+    }
+
+    if ( (arg = strpbrk(str, ",:")) != NULL )
+        *arg++ = '\0';
+
+    if ( !strcmp(str, "xen") )
+        if ( arg && *arg )
+            cpufreq_cmdline_parse(arg);
+}
+custom_param("cpufreq", setup_cpufreq_option);
+
 bool_t __read_mostly cpufreq_verbose;
 
 struct cpufreq_governor *__find_governor(const char *governor)
diff --git a/xen/include/xen/domain.h b/xen/include/xen/domain.h
index 765e132..de3e8db 100644
--- a/xen/include/xen/domain.h
+++ b/xen/include/xen/domain.h
@@ -85,4 +85,6 @@ int continue_hypercall_on_cpu(
 
 extern unsigned int xen_processor_pmbits;
 
+extern bool_t opt_dom0_vcpus_pin;
+
 #endif /* __XEN_DOMAIN_H__ */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 18:20:36 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 18:20:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXzcw-0007uB-Da; Tue, 06 Dec 2011 18:20:26 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RXzcu-0007sK-Oo
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 18:20:25 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1323195568!6426244!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDcxMjI=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7576 invoked from network); 6 Dec 2011 18:19:38 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Dec 2011 18:19:38 -0000
X-IronPort-AV: E=Sophos;i="4.71,307,1320642000"; d="scan'208";a="19721934"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Dec 2011 13:19:27 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Tue, 6 Dec 2011 13:19:27 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pB6IJEjB019549;
	Tue, 6 Dec 2011 10:19:15 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Tue, 6 Dec 2011 18:19:45 +0000
Message-ID: <1323195609-17277-1-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1112061753410.31179@kaball-desktop>
References: <alpine.DEB.2.00.1112061753410.31179@kaball-desktop>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>, Tim.Deegan@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH RFC 01/25] Include some header files that are
	not automatically included on all archs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
---
 xen/common/domctl.c           |    1 +
 xen/common/grant_table.c      |    1 +
 xen/common/irq.c              |    1 +
 xen/common/kernel.c           |    2 +-
 xen/common/keyhandler.c       |    1 +
 xen/common/memory.c           |    4 +---
 xen/common/spinlock.c         |    1 +
 xen/common/wait.c             |    1 +
 xen/drivers/char/console.c    |    1 +
 xen/include/xen/grant_table.h |    1 +
 xen/include/xen/list.h        |    1 +
 xen/include/xen/sched.h       |    4 ++++
 xen/include/xen/timer.h       |    1 +
 xen/include/xen/tmem_xen.h    |    1 +
 14 files changed, 17 insertions(+), 4 deletions(-)

diff --git a/xen/common/domctl.c b/xen/common/domctl.c
index 6705a57..397f774 100644
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -24,6 +24,7 @@
 #include <xen/paging.h>
 #include <xen/hypercall.h>
 #include <asm/current.h>
+#include <asm/page.h>
 #include <public/domctl.h>
 #include <xsm/xsm.h>
 
diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c
index c80a359..66c98ec 100644
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -24,6 +24,7 @@
  * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
  */
 
+#include <asm/flushtlb.h>
 #include <xen/config.h>
 #include <xen/iocap.h>
 #include <xen/lib.h>
diff --git a/xen/common/irq.c b/xen/common/irq.c
index 6d37dd4..3e55dfa 100644
--- a/xen/common/irq.c
+++ b/xen/common/irq.c
@@ -1,5 +1,6 @@
 #include <xen/config.h>
 #include <xen/irq.h>
+#include <xen/errno.h>
 
 int init_one_irq_desc(struct irq_desc *desc)
 {
diff --git a/xen/common/kernel.c b/xen/common/kernel.c
index 7decc1d..f51d387 100644
--- a/xen/common/kernel.c
+++ b/xen/common/kernel.c
@@ -18,8 +18,8 @@
 #include <public/version.h>
 #ifdef CONFIG_X86
 #include <asm/shared.h>
-#include <asm/setup.h>
 #endif
+#include <asm/setup.h>
 
 #ifndef COMPAT
 
diff --git a/xen/common/keyhandler.c b/xen/common/keyhandler.c
index a8f256a..6071f09 100644
--- a/xen/common/keyhandler.c
+++ b/xen/common/keyhandler.c
@@ -15,6 +15,7 @@
 #include <xen/compat.h>
 #include <xen/ctype.h>
 #include <xen/perfc.h>
+#include <xen/init.h>
 #include <asm/debugger.h>
 #include <asm/div64.h>
 
diff --git a/xen/common/memory.c b/xen/common/memory.c
index aefb706..094db03 100644
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -23,9 +23,7 @@
 #include <xen/tmem_xen.h>
 #include <asm/current.h>
 #include <asm/hardirq.h>
-#ifdef CONFIG_X86
-# include <asm/p2m.h>
-#endif
+#include <asm/p2m.h>
 #include <xen/numa.h>
 #include <public/memory.h>
 #include <xsm/xsm.h>
diff --git a/xen/common/spinlock.c b/xen/common/spinlock.c
index ecf5b44..bfb9670 100644
--- a/xen/common/spinlock.c
+++ b/xen/common/spinlock.c
@@ -8,6 +8,7 @@
 #include <xen/preempt.h>
 #include <public/sysctl.h>
 #include <asm/processor.h>
+#include <asm/atomic.h>
 
 #ifndef NDEBUG
 
diff --git a/xen/common/wait.c b/xen/common/wait.c
index a2c7640..0410c98 100644
--- a/xen/common/wait.c
+++ b/xen/common/wait.c
@@ -23,6 +23,7 @@
 #include <xen/config.h>
 #include <xen/sched.h>
 #include <xen/wait.h>
+#include <xen/errno.h>
 
 struct waitqueue_vcpu {
     struct list_head list;
diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
index 8a4c684..89cf4f8 100644
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -12,6 +12,7 @@
 
 #include <xen/version.h>
 #include <xen/lib.h>
+#include <xen/init.h>
 #include <xen/event.h>
 #include <xen/console.h>
 #include <xen/serial.h>
diff --git a/xen/include/xen/grant_table.h b/xen/include/xen/grant_table.h
index c161705..cb0596a 100644
--- a/xen/include/xen/grant_table.h
+++ b/xen/include/xen/grant_table.h
@@ -26,6 +26,7 @@
 
 #include <xen/config.h>
 #include <public/grant_table.h>
+#include <asm/page.h>
 #include <asm/grant_table.h>
 
 /* Active grant entry - used for shadowing GTF_permit_access grants. */
diff --git a/xen/include/xen/list.h b/xen/include/xen/list.h
index b87682f..18443a4 100644
--- a/xen/include/xen/list.h
+++ b/xen/include/xen/list.h
@@ -8,6 +8,7 @@
 #define __XEN_LIST_H__
 
 #include <xen/lib.h>
+#include <xen/prefetch.h>
 #include <asm/system.h>
 
 /* These are non-NULL pointers that will result in page faults
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index e12293c..832ca6f 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -14,6 +14,10 @@
 #include <xen/nodemask.h>
 #include <xen/radix-tree.h>
 #include <xen/multicall.h>
+#include <xen/tasklet.h>
+#include <xen/mm.h>
+#include <xen/smp.h>
+#include <asm/atomic.h>
 #include <public/xen.h>
 #include <public/domctl.h>
 #include <public/sysctl.h>
diff --git a/xen/include/xen/timer.h b/xen/include/xen/timer.h
index d209142..7c465fb 100644
--- a/xen/include/xen/timer.h
+++ b/xen/include/xen/timer.h
@@ -12,6 +12,7 @@
 #include <xen/time.h>
 #include <xen/string.h>
 #include <xen/list.h>
+#include <xen/percpu.h>
 
 struct timer {
     /* System time expiry value (nanoseconds since boot). */
diff --git a/xen/include/xen/tmem_xen.h b/xen/include/xen/tmem_xen.h
index 3dbf6f8..8d81bb4 100644
--- a/xen/include/xen/tmem_xen.h
+++ b/xen/include/xen/tmem_xen.h
@@ -11,6 +11,7 @@
 
 #include <xen/config.h>
 #include <xen/mm.h> /* heap alloc/free */
+#include <xen/pfn.h> /* heap alloc/free */
 #include <xen/xmalloc.h> /* xmalloc/xfree */
 #include <xen/sched.h>  /* struct domain */
 #include <xen/guest_access.h> /* copy_from_guest */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 18:20:36 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 18:20:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXzcw-0007uB-Da; Tue, 06 Dec 2011 18:20:26 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RXzcu-0007sK-Oo
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 18:20:25 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1323195568!6426244!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDcxMjI=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7576 invoked from network); 6 Dec 2011 18:19:38 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Dec 2011 18:19:38 -0000
X-IronPort-AV: E=Sophos;i="4.71,307,1320642000"; d="scan'208";a="19721934"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Dec 2011 13:19:27 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Tue, 6 Dec 2011 13:19:27 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pB6IJEjB019549;
	Tue, 6 Dec 2011 10:19:15 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Tue, 6 Dec 2011 18:19:45 +0000
Message-ID: <1323195609-17277-1-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1112061753410.31179@kaball-desktop>
References: <alpine.DEB.2.00.1112061753410.31179@kaball-desktop>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>, Tim.Deegan@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH RFC 01/25] Include some header files that are
	not automatically included on all archs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
---
 xen/common/domctl.c           |    1 +
 xen/common/grant_table.c      |    1 +
 xen/common/irq.c              |    1 +
 xen/common/kernel.c           |    2 +-
 xen/common/keyhandler.c       |    1 +
 xen/common/memory.c           |    4 +---
 xen/common/spinlock.c         |    1 +
 xen/common/wait.c             |    1 +
 xen/drivers/char/console.c    |    1 +
 xen/include/xen/grant_table.h |    1 +
 xen/include/xen/list.h        |    1 +
 xen/include/xen/sched.h       |    4 ++++
 xen/include/xen/timer.h       |    1 +
 xen/include/xen/tmem_xen.h    |    1 +
 14 files changed, 17 insertions(+), 4 deletions(-)

diff --git a/xen/common/domctl.c b/xen/common/domctl.c
index 6705a57..397f774 100644
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -24,6 +24,7 @@
 #include <xen/paging.h>
 #include <xen/hypercall.h>
 #include <asm/current.h>
+#include <asm/page.h>
 #include <public/domctl.h>
 #include <xsm/xsm.h>
 
diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c
index c80a359..66c98ec 100644
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -24,6 +24,7 @@
  * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
  */
 
+#include <asm/flushtlb.h>
 #include <xen/config.h>
 #include <xen/iocap.h>
 #include <xen/lib.h>
diff --git a/xen/common/irq.c b/xen/common/irq.c
index 6d37dd4..3e55dfa 100644
--- a/xen/common/irq.c
+++ b/xen/common/irq.c
@@ -1,5 +1,6 @@
 #include <xen/config.h>
 #include <xen/irq.h>
+#include <xen/errno.h>
 
 int init_one_irq_desc(struct irq_desc *desc)
 {
diff --git a/xen/common/kernel.c b/xen/common/kernel.c
index 7decc1d..f51d387 100644
--- a/xen/common/kernel.c
+++ b/xen/common/kernel.c
@@ -18,8 +18,8 @@
 #include <public/version.h>
 #ifdef CONFIG_X86
 #include <asm/shared.h>
-#include <asm/setup.h>
 #endif
+#include <asm/setup.h>
 
 #ifndef COMPAT
 
diff --git a/xen/common/keyhandler.c b/xen/common/keyhandler.c
index a8f256a..6071f09 100644
--- a/xen/common/keyhandler.c
+++ b/xen/common/keyhandler.c
@@ -15,6 +15,7 @@
 #include <xen/compat.h>
 #include <xen/ctype.h>
 #include <xen/perfc.h>
+#include <xen/init.h>
 #include <asm/debugger.h>
 #include <asm/div64.h>
 
diff --git a/xen/common/memory.c b/xen/common/memory.c
index aefb706..094db03 100644
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -23,9 +23,7 @@
 #include <xen/tmem_xen.h>
 #include <asm/current.h>
 #include <asm/hardirq.h>
-#ifdef CONFIG_X86
-# include <asm/p2m.h>
-#endif
+#include <asm/p2m.h>
 #include <xen/numa.h>
 #include <public/memory.h>
 #include <xsm/xsm.h>
diff --git a/xen/common/spinlock.c b/xen/common/spinlock.c
index ecf5b44..bfb9670 100644
--- a/xen/common/spinlock.c
+++ b/xen/common/spinlock.c
@@ -8,6 +8,7 @@
 #include <xen/preempt.h>
 #include <public/sysctl.h>
 #include <asm/processor.h>
+#include <asm/atomic.h>
 
 #ifndef NDEBUG
 
diff --git a/xen/common/wait.c b/xen/common/wait.c
index a2c7640..0410c98 100644
--- a/xen/common/wait.c
+++ b/xen/common/wait.c
@@ -23,6 +23,7 @@
 #include <xen/config.h>
 #include <xen/sched.h>
 #include <xen/wait.h>
+#include <xen/errno.h>
 
 struct waitqueue_vcpu {
     struct list_head list;
diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
index 8a4c684..89cf4f8 100644
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -12,6 +12,7 @@
 
 #include <xen/version.h>
 #include <xen/lib.h>
+#include <xen/init.h>
 #include <xen/event.h>
 #include <xen/console.h>
 #include <xen/serial.h>
diff --git a/xen/include/xen/grant_table.h b/xen/include/xen/grant_table.h
index c161705..cb0596a 100644
--- a/xen/include/xen/grant_table.h
+++ b/xen/include/xen/grant_table.h
@@ -26,6 +26,7 @@
 
 #include <xen/config.h>
 #include <public/grant_table.h>
+#include <asm/page.h>
 #include <asm/grant_table.h>
 
 /* Active grant entry - used for shadowing GTF_permit_access grants. */
diff --git a/xen/include/xen/list.h b/xen/include/xen/list.h
index b87682f..18443a4 100644
--- a/xen/include/xen/list.h
+++ b/xen/include/xen/list.h
@@ -8,6 +8,7 @@
 #define __XEN_LIST_H__
 
 #include <xen/lib.h>
+#include <xen/prefetch.h>
 #include <asm/system.h>
 
 /* These are non-NULL pointers that will result in page faults
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index e12293c..832ca6f 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -14,6 +14,10 @@
 #include <xen/nodemask.h>
 #include <xen/radix-tree.h>
 #include <xen/multicall.h>
+#include <xen/tasklet.h>
+#include <xen/mm.h>
+#include <xen/smp.h>
+#include <asm/atomic.h>
 #include <public/xen.h>
 #include <public/domctl.h>
 #include <public/sysctl.h>
diff --git a/xen/include/xen/timer.h b/xen/include/xen/timer.h
index d209142..7c465fb 100644
--- a/xen/include/xen/timer.h
+++ b/xen/include/xen/timer.h
@@ -12,6 +12,7 @@
 #include <xen/time.h>
 #include <xen/string.h>
 #include <xen/list.h>
+#include <xen/percpu.h>
 
 struct timer {
     /* System time expiry value (nanoseconds since boot). */
diff --git a/xen/include/xen/tmem_xen.h b/xen/include/xen/tmem_xen.h
index 3dbf6f8..8d81bb4 100644
--- a/xen/include/xen/tmem_xen.h
+++ b/xen/include/xen/tmem_xen.h
@@ -11,6 +11,7 @@
 
 #include <xen/config.h>
 #include <xen/mm.h> /* heap alloc/free */
+#include <xen/pfn.h> /* heap alloc/free */
 #include <xen/xmalloc.h> /* xmalloc/xfree */
 #include <xen/sched.h>  /* struct domain */
 #include <xen/guest_access.h> /* copy_from_guest */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 18:20:37 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 18:20:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXzcx-0007uU-72; Tue, 06 Dec 2011 18:20:27 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RXzcv-0007sP-5R
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 18:20:25 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1323195545!51363948!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMzAwOTc=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3951 invoked from network); 6 Dec 2011 18:19:07 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Dec 2011 18:19:07 -0000
X-IronPort-AV: E=Sophos;i="4.71,307,1320642000"; d="scan'208";a="173120721"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Dec 2011 13:19:36 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Tue, 6 Dec 2011 13:19:36 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pB6IJEjE019549;
	Tue, 6 Dec 2011 10:19:19 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Tue, 6 Dec 2011 18:19:48 +0000
Message-ID: <1323195609-17277-4-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1112061753410.31179@kaball-desktop>
References: <alpine.DEB.2.00.1112061753410.31179@kaball-desktop>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>, Tim.Deegan@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH RFC 04/25] Replace "/" operand with div64
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

ARM does not have a division operator: division has to be implemented
in software.
On x86 and ia64 div64 falls back to a do_div based implementation.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
---
 xen/common/keyhandler.c                        |    4 +-
 xen/common/lib.c                               |    9 ++++--
 xen/common/sched_credit.c                      |    7 +++--
 xen/common/sched_credit2.c                     |    5 ++-
 xen/common/sched_sedf.c                        |   30 ++++++++++++------------
 xen/common/timer.c                             |    7 ++++-
 xen/include/asm-ia64/linux/asm-generic/div64.h |    6 ++++
 xen/include/asm-x86/div64.h                    |    6 ++++
 8 files changed, 47 insertions(+), 27 deletions(-)

diff --git a/xen/common/keyhandler.c b/xen/common/keyhandler.c
index 6071f09..1700b8a 100644
--- a/xen/common/keyhandler.c
+++ b/xen/common/keyhandler.c
@@ -392,10 +392,10 @@ static void read_clocks(unsigned char key)
     count++;
     printk("Synced stime skew: max=%"PRIu64"ns avg=%"PRIu64"ns "
            "samples=%"PRIu32" current=%"PRIu64"ns\n",
-           maxdif_stime, sumdif_stime/count, count, dif_stime);
+           maxdif_stime, div64(sumdif_stime, count), count, dif_stime);
     printk("Synced cycles skew: max=%"PRIu64" avg=%"PRIu64" "
            "samples=%"PRIu32" current=%"PRIu64"\n",
-           maxdif_cycles, sumdif_cycles/count, count, dif_cycles);
+           maxdif_cycles, div64(sumdif_cycles, count), count, dif_cycles);
 }
 
 static struct keyhandler read_clocks_keyhandler = {
diff --git a/xen/common/lib.c b/xen/common/lib.c
index 4ae637c..2b543b0 100644
--- a/xen/common/lib.c
+++ b/xen/common/lib.c
@@ -3,6 +3,7 @@
 #include <xen/lib.h>
 #include <xen/types.h>
 #include <asm/byteorder.h>
+#include <asm/div64.h>
 
 /* for ctype.h */
 const unsigned char _ctype[] = {
@@ -418,14 +419,16 @@ uint64_t muldiv64(uint64_t a, uint32_t b, uint32_t c)
 #endif            
         } l;
     } u, res;
-    uint64_t rl, rh;
+    uint64_t rl, rh, t;
 
     u.ll = a;
     rl = (uint64_t)u.l.low * (uint64_t)b;
     rh = (uint64_t)u.l.high * (uint64_t)b;
     rh += (rl >> 32);
-    res.l.high = rh / c;
-    res.l.low = (((rh % c) << 32) + (rl & 0xffffffff)) / c;
+
+    t = do_div(rh, c);
+    res.l.high = rh;
+    res.l.low = div64(((t << 32) + (rl & 0xffffffff)), c);
     return res.ll;
 #endif
 }
diff --git a/xen/common/sched_credit.c b/xen/common/sched_credit.c
index 4fa6140..02f77ee 100644
--- a/xen/common/sched_credit.c
+++ b/xen/common/sched_credit.c
@@ -22,6 +22,7 @@
 #include <asm/atomic.h>
 #include <xen/errno.h>
 #include <xen/keyhandler.h>
+#include <asm/div64.h>
 
 /*
  * CSCHED_STATS
@@ -241,9 +242,9 @@ static void burn_credits(struct csched_vcpu *svc, s_time_t now)
     if ( (delta = now - svc->start_time) <= 0 )
         return;
 
-    credits = (delta*CSCHED_CREDITS_PER_MSEC + MILLISECS(1)/2) / MILLISECS(1);
+    credits = div64((delta*CSCHED_CREDITS_PER_MSEC + MILLISECS(1)/2), MILLISECS(1));
     atomic_sub(credits, &svc->credit);
-    svc->start_time += (credits * MILLISECS(1)) / CSCHED_CREDITS_PER_MSEC;
+    svc->start_time += div64(credits * MILLISECS(1), CSCHED_CREDITS_PER_MSEC);
 }
 
 static bool_t __read_mostly opt_tickle_one_idle = 1;
@@ -1570,7 +1571,7 @@ static void csched_tick_resume(const struct scheduler *ops, unsigned int cpu)
     prv = CSCHED_PRIV(ops);
 
     set_timer(&spc->ticker, now + MICROSECS(prv->tick_period_us)
-            - now % MICROSECS(prv->tick_period_us) );
+            - do_div(now, MILLISECS(prv->tick_period_us)) );
 }
 
 static struct csched_private _csched_priv;
diff --git a/xen/common/sched_credit2.c b/xen/common/sched_credit2.c
index 73f7138..46f48db 100644
--- a/xen/common/sched_credit2.c
+++ b/xen/common/sched_credit2.c
@@ -25,6 +25,7 @@
 #include <xen/errno.h>
 #include <xen/trace.h>
 #include <xen/cpu.h>
+#include <asm/div64.h>
 
 #define d2printk(x...)
 //#define d2printk printk
@@ -273,12 +274,12 @@ struct csched_dom {
  */
 static s_time_t t2c(struct csched_runqueue_data *rqd, s_time_t time, struct csched_vcpu *svc)
 {
-    return time * rqd->max_weight / svc->weight;
+    return div64(time * rqd->max_weight, svc->weight);
 }
 
 static s_time_t c2t(struct csched_runqueue_data *rqd, s_time_t credit, struct csched_vcpu *svc)
 {
-    return credit * svc->weight / rqd->max_weight;
+    return div64(credit * svc->weight, rqd->max_weight);
 }
 
 /*
diff --git a/xen/common/sched_sedf.c b/xen/common/sched_sedf.c
index 8bff90c..e8eab31 100644
--- a/xen/common/sched_sedf.c
+++ b/xen/common/sched_sedf.c
@@ -12,6 +12,7 @@
 #include <xen/softirq.h>
 #include <xen/time.h>
 #include <xen/errno.h>
+#include <asm/div64.h>
 
 /*verbosity settings*/
 #define SEDFLEVEL 0
@@ -127,7 +128,7 @@ struct sedf_cpu_info {
 
 #define PERIOD_BEGIN(inf) ((inf)->deadl_abs - (inf)->period)
 
-#define DIV_UP(x,y) (((x) + (y) - 1) / y)
+#define DIV_UP(x,y) div64((x) + (y) - 1, y)
 
 #define extra_runs(inf)      ((inf->status) & 6)
 #define extra_get_cur_q(inf) (((inf->status & 6) >> 1)-1)
@@ -678,8 +679,7 @@ static void desched_extra_dom(s_time_t now, struct vcpu *d)
           utilization and is used somewhat incremental!*/
         if ( !inf->extraweight )
             /*NB: use fixed point arithmetic with 10 bits*/
-            inf->score[EXTRA_UTIL_Q] = (inf->period << 10) /
-                inf->slice;
+            inf->score[EXTRA_UTIL_Q] = div64(inf->period << 10, inf->slice);
         else
             /*conversion between realtime utilisation and extrawieght:
               full (ie 100%) utilization is equivalent to 128 extraweight*/
@@ -996,8 +996,8 @@ static void unblock_short_extra_support(
   
         if ( inf->short_block_lost_tot )
         {
-            inf->score[0] = (inf->period << 10) /
-                inf->short_block_lost_tot;
+            inf->score[0] = div64(inf->period << 10,
+                                     inf->short_block_lost_tot);
 #ifdef SEDF_STATS
             inf->pen_extra_blocks++;
 #endif
@@ -1224,8 +1224,8 @@ static void sedf_dump_domain(struct vcpu *d)
     
 #ifdef SEDF_STATS
     if ( EDOM_INFO(d)->block_time_tot != 0 )
-        printk(" pen=%"PRIu64"%%", (EDOM_INFO(d)->penalty_time_tot * 100) /
-               EDOM_INFO(d)->block_time_tot);
+        printk(" pen=%"PRIu64"%%",
+               div64(EDOM_INFO(d)->penalty_time_tot * 100, EDOM_INFO(d)->block_time_tot));
     if ( EDOM_INFO(d)->block_tot != 0 )
         printk("\n   blks=%u sh=%u (%u%%) (shc=%u (%u%%) shex=%i "\
                "shexsl=%i) l=%u (%u%%) avg: b=%"PRIu64" p=%"PRIu64"",
@@ -1237,8 +1237,8 @@ static void sedf_dump_domain(struct vcpu *d)
                EDOM_INFO(d)->pen_extra_slices,
                EDOM_INFO(d)->long_block_tot,
                (EDOM_INFO(d)->long_block_tot * 100) / EDOM_INFO(d)->block_tot,
-               (EDOM_INFO(d)->block_time_tot) / EDOM_INFO(d)->block_tot,
-               (EDOM_INFO(d)->penalty_time_tot) / EDOM_INFO(d)->block_tot);
+               div64(EDOM_INFO(d)->block_time_tot, EDOM_INFO(d)->block_tot),
+               div64(EDOM_INFO(d)->penalty_time_tot, EDOM_INFO(d)->block_tot));
 #endif
     printk("\n");
 }
@@ -1357,9 +1357,9 @@ static int sedf_adjust_weights(struct cpupool *c, struct xen_domctl_scheduler_op
                 /*check for overflows*/
                 ASSERT((WEIGHT_PERIOD < ULONG_MAX) 
                        && (EDOM_INFO(p)->slice_orig < ULONG_MAX));
-                sumt[cpu] += 
-                    (WEIGHT_PERIOD * EDOM_INFO(p)->slice_orig) / 
-                    EDOM_INFO(p)->period_orig;
+                sumt[cpu] += div64(
+                    WEIGHT_PERIOD * EDOM_INFO(p)->slice_orig,
+                    EDOM_INFO(p)->period_orig);
             }
         }
     }
@@ -1378,9 +1378,9 @@ static int sedf_adjust_weights(struct cpupool *c, struct xen_domctl_scheduler_op
                 EDOM_INFO(p)->period_orig = 
                     EDOM_INFO(p)->period  = WEIGHT_PERIOD;
                 EDOM_INFO(p)->slice_orig  =
-                    EDOM_INFO(p)->slice   = 
-                    (EDOM_INFO(p)->weight *
-                     (WEIGHT_PERIOD - WEIGHT_SAFETY - sumt[cpu])) / sumw[cpu];
+                    EDOM_INFO(p)->slice   = div64(
+                        EDOM_INFO(p)->weight * (WEIGHT_PERIOD - WEIGHT_SAFETY - sumt[cpu]),
+                        sumw[cpu]);
             }
         }
     }
diff --git a/xen/common/timer.c b/xen/common/timer.c
index 0547ea3..043250e 100644
--- a/xen/common/timer.c
+++ b/xen/common/timer.c
@@ -23,6 +23,7 @@
 #include <xen/symbols.h>
 #include <asm/system.h>
 #include <asm/desc.h>
+#include <asm/div64.h>
 #include <asm/atomic.h>
 
 /* We program the time hardware this far behind the closest deadline. */
@@ -503,16 +504,18 @@ static void timer_softirq_action(void)
 
 s_time_t align_timer(s_time_t firsttick, uint64_t period)
 {
+    uint64_t n;
     if ( !period )
         return firsttick;
 
-    return firsttick + (period - 1) - ((firsttick - 1) % period);
+    n = firsttick + (period - 1) - (firsttick - 1);
+    return do_div(n, period);
 }
 
 static void dump_timer(struct timer *t, s_time_t now)
 {
     printk("  ex=%8"PRId64"us timer=%p cb=%p(%p)",
-           (t->expires - now) / 1000, t, t->function, t->data);
+           div64(t->expires - now, 1000), t, t->function, t->data);
     print_symbol(" %s\n", (unsigned long)t->function);
 }
 
diff --git a/xen/include/asm-ia64/linux/asm-generic/div64.h b/xen/include/asm-ia64/linux/asm-generic/div64.h
index 8f4e319..820c073 100644
--- a/xen/include/asm-ia64/linux/asm-generic/div64.h
+++ b/xen/include/asm-ia64/linux/asm-generic/div64.h
@@ -55,4 +55,10 @@ extern uint32_t __div64_32(uint64_t *dividend, uint32_t divisor);
 
 #endif /* BITS_PER_LONG */
 
+static inline uint64_t div64(uint64_t n, uint32_t base)
+{
+	do_div(n, base);
+	return n;
+}
+
 #endif /* _ASM_GENERIC_DIV64_H */
diff --git a/xen/include/asm-x86/div64.h b/xen/include/asm-x86/div64.h
index 1ce87cd..800ef2a 100644
--- a/xen/include/asm-x86/div64.h
+++ b/xen/include/asm-x86/div64.h
@@ -46,4 +46,10 @@
 
 #endif
 
+static inline uint64_t div64(uint64_t n, uint32_t base)
+{
+	do_div(n, base);
+	return n;
+}
+
 #endif
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 18:20:37 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 18:20:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXzcx-0007uU-72; Tue, 06 Dec 2011 18:20:27 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RXzcv-0007sP-5R
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 18:20:25 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1323195545!51363948!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMzAwOTc=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3951 invoked from network); 6 Dec 2011 18:19:07 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Dec 2011 18:19:07 -0000
X-IronPort-AV: E=Sophos;i="4.71,307,1320642000"; d="scan'208";a="173120721"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Dec 2011 13:19:36 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Tue, 6 Dec 2011 13:19:36 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pB6IJEjE019549;
	Tue, 6 Dec 2011 10:19:19 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Tue, 6 Dec 2011 18:19:48 +0000
Message-ID: <1323195609-17277-4-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1112061753410.31179@kaball-desktop>
References: <alpine.DEB.2.00.1112061753410.31179@kaball-desktop>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>, Tim.Deegan@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH RFC 04/25] Replace "/" operand with div64
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

ARM does not have a division operator: division has to be implemented
in software.
On x86 and ia64 div64 falls back to a do_div based implementation.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
---
 xen/common/keyhandler.c                        |    4 +-
 xen/common/lib.c                               |    9 ++++--
 xen/common/sched_credit.c                      |    7 +++--
 xen/common/sched_credit2.c                     |    5 ++-
 xen/common/sched_sedf.c                        |   30 ++++++++++++------------
 xen/common/timer.c                             |    7 ++++-
 xen/include/asm-ia64/linux/asm-generic/div64.h |    6 ++++
 xen/include/asm-x86/div64.h                    |    6 ++++
 8 files changed, 47 insertions(+), 27 deletions(-)

diff --git a/xen/common/keyhandler.c b/xen/common/keyhandler.c
index 6071f09..1700b8a 100644
--- a/xen/common/keyhandler.c
+++ b/xen/common/keyhandler.c
@@ -392,10 +392,10 @@ static void read_clocks(unsigned char key)
     count++;
     printk("Synced stime skew: max=%"PRIu64"ns avg=%"PRIu64"ns "
            "samples=%"PRIu32" current=%"PRIu64"ns\n",
-           maxdif_stime, sumdif_stime/count, count, dif_stime);
+           maxdif_stime, div64(sumdif_stime, count), count, dif_stime);
     printk("Synced cycles skew: max=%"PRIu64" avg=%"PRIu64" "
            "samples=%"PRIu32" current=%"PRIu64"\n",
-           maxdif_cycles, sumdif_cycles/count, count, dif_cycles);
+           maxdif_cycles, div64(sumdif_cycles, count), count, dif_cycles);
 }
 
 static struct keyhandler read_clocks_keyhandler = {
diff --git a/xen/common/lib.c b/xen/common/lib.c
index 4ae637c..2b543b0 100644
--- a/xen/common/lib.c
+++ b/xen/common/lib.c
@@ -3,6 +3,7 @@
 #include <xen/lib.h>
 #include <xen/types.h>
 #include <asm/byteorder.h>
+#include <asm/div64.h>
 
 /* for ctype.h */
 const unsigned char _ctype[] = {
@@ -418,14 +419,16 @@ uint64_t muldiv64(uint64_t a, uint32_t b, uint32_t c)
 #endif            
         } l;
     } u, res;
-    uint64_t rl, rh;
+    uint64_t rl, rh, t;
 
     u.ll = a;
     rl = (uint64_t)u.l.low * (uint64_t)b;
     rh = (uint64_t)u.l.high * (uint64_t)b;
     rh += (rl >> 32);
-    res.l.high = rh / c;
-    res.l.low = (((rh % c) << 32) + (rl & 0xffffffff)) / c;
+
+    t = do_div(rh, c);
+    res.l.high = rh;
+    res.l.low = div64(((t << 32) + (rl & 0xffffffff)), c);
     return res.ll;
 #endif
 }
diff --git a/xen/common/sched_credit.c b/xen/common/sched_credit.c
index 4fa6140..02f77ee 100644
--- a/xen/common/sched_credit.c
+++ b/xen/common/sched_credit.c
@@ -22,6 +22,7 @@
 #include <asm/atomic.h>
 #include <xen/errno.h>
 #include <xen/keyhandler.h>
+#include <asm/div64.h>
 
 /*
  * CSCHED_STATS
@@ -241,9 +242,9 @@ static void burn_credits(struct csched_vcpu *svc, s_time_t now)
     if ( (delta = now - svc->start_time) <= 0 )
         return;
 
-    credits = (delta*CSCHED_CREDITS_PER_MSEC + MILLISECS(1)/2) / MILLISECS(1);
+    credits = div64((delta*CSCHED_CREDITS_PER_MSEC + MILLISECS(1)/2), MILLISECS(1));
     atomic_sub(credits, &svc->credit);
-    svc->start_time += (credits * MILLISECS(1)) / CSCHED_CREDITS_PER_MSEC;
+    svc->start_time += div64(credits * MILLISECS(1), CSCHED_CREDITS_PER_MSEC);
 }
 
 static bool_t __read_mostly opt_tickle_one_idle = 1;
@@ -1570,7 +1571,7 @@ static void csched_tick_resume(const struct scheduler *ops, unsigned int cpu)
     prv = CSCHED_PRIV(ops);
 
     set_timer(&spc->ticker, now + MICROSECS(prv->tick_period_us)
-            - now % MICROSECS(prv->tick_period_us) );
+            - do_div(now, MILLISECS(prv->tick_period_us)) );
 }
 
 static struct csched_private _csched_priv;
diff --git a/xen/common/sched_credit2.c b/xen/common/sched_credit2.c
index 73f7138..46f48db 100644
--- a/xen/common/sched_credit2.c
+++ b/xen/common/sched_credit2.c
@@ -25,6 +25,7 @@
 #include <xen/errno.h>
 #include <xen/trace.h>
 #include <xen/cpu.h>
+#include <asm/div64.h>
 
 #define d2printk(x...)
 //#define d2printk printk
@@ -273,12 +274,12 @@ struct csched_dom {
  */
 static s_time_t t2c(struct csched_runqueue_data *rqd, s_time_t time, struct csched_vcpu *svc)
 {
-    return time * rqd->max_weight / svc->weight;
+    return div64(time * rqd->max_weight, svc->weight);
 }
 
 static s_time_t c2t(struct csched_runqueue_data *rqd, s_time_t credit, struct csched_vcpu *svc)
 {
-    return credit * svc->weight / rqd->max_weight;
+    return div64(credit * svc->weight, rqd->max_weight);
 }
 
 /*
diff --git a/xen/common/sched_sedf.c b/xen/common/sched_sedf.c
index 8bff90c..e8eab31 100644
--- a/xen/common/sched_sedf.c
+++ b/xen/common/sched_sedf.c
@@ -12,6 +12,7 @@
 #include <xen/softirq.h>
 #include <xen/time.h>
 #include <xen/errno.h>
+#include <asm/div64.h>
 
 /*verbosity settings*/
 #define SEDFLEVEL 0
@@ -127,7 +128,7 @@ struct sedf_cpu_info {
 
 #define PERIOD_BEGIN(inf) ((inf)->deadl_abs - (inf)->period)
 
-#define DIV_UP(x,y) (((x) + (y) - 1) / y)
+#define DIV_UP(x,y) div64((x) + (y) - 1, y)
 
 #define extra_runs(inf)      ((inf->status) & 6)
 #define extra_get_cur_q(inf) (((inf->status & 6) >> 1)-1)
@@ -678,8 +679,7 @@ static void desched_extra_dom(s_time_t now, struct vcpu *d)
           utilization and is used somewhat incremental!*/
         if ( !inf->extraweight )
             /*NB: use fixed point arithmetic with 10 bits*/
-            inf->score[EXTRA_UTIL_Q] = (inf->period << 10) /
-                inf->slice;
+            inf->score[EXTRA_UTIL_Q] = div64(inf->period << 10, inf->slice);
         else
             /*conversion between realtime utilisation and extrawieght:
               full (ie 100%) utilization is equivalent to 128 extraweight*/
@@ -996,8 +996,8 @@ static void unblock_short_extra_support(
   
         if ( inf->short_block_lost_tot )
         {
-            inf->score[0] = (inf->period << 10) /
-                inf->short_block_lost_tot;
+            inf->score[0] = div64(inf->period << 10,
+                                     inf->short_block_lost_tot);
 #ifdef SEDF_STATS
             inf->pen_extra_blocks++;
 #endif
@@ -1224,8 +1224,8 @@ static void sedf_dump_domain(struct vcpu *d)
     
 #ifdef SEDF_STATS
     if ( EDOM_INFO(d)->block_time_tot != 0 )
-        printk(" pen=%"PRIu64"%%", (EDOM_INFO(d)->penalty_time_tot * 100) /
-               EDOM_INFO(d)->block_time_tot);
+        printk(" pen=%"PRIu64"%%",
+               div64(EDOM_INFO(d)->penalty_time_tot * 100, EDOM_INFO(d)->block_time_tot));
     if ( EDOM_INFO(d)->block_tot != 0 )
         printk("\n   blks=%u sh=%u (%u%%) (shc=%u (%u%%) shex=%i "\
                "shexsl=%i) l=%u (%u%%) avg: b=%"PRIu64" p=%"PRIu64"",
@@ -1237,8 +1237,8 @@ static void sedf_dump_domain(struct vcpu *d)
                EDOM_INFO(d)->pen_extra_slices,
                EDOM_INFO(d)->long_block_tot,
                (EDOM_INFO(d)->long_block_tot * 100) / EDOM_INFO(d)->block_tot,
-               (EDOM_INFO(d)->block_time_tot) / EDOM_INFO(d)->block_tot,
-               (EDOM_INFO(d)->penalty_time_tot) / EDOM_INFO(d)->block_tot);
+               div64(EDOM_INFO(d)->block_time_tot, EDOM_INFO(d)->block_tot),
+               div64(EDOM_INFO(d)->penalty_time_tot, EDOM_INFO(d)->block_tot));
 #endif
     printk("\n");
 }
@@ -1357,9 +1357,9 @@ static int sedf_adjust_weights(struct cpupool *c, struct xen_domctl_scheduler_op
                 /*check for overflows*/
                 ASSERT((WEIGHT_PERIOD < ULONG_MAX) 
                        && (EDOM_INFO(p)->slice_orig < ULONG_MAX));
-                sumt[cpu] += 
-                    (WEIGHT_PERIOD * EDOM_INFO(p)->slice_orig) / 
-                    EDOM_INFO(p)->period_orig;
+                sumt[cpu] += div64(
+                    WEIGHT_PERIOD * EDOM_INFO(p)->slice_orig,
+                    EDOM_INFO(p)->period_orig);
             }
         }
     }
@@ -1378,9 +1378,9 @@ static int sedf_adjust_weights(struct cpupool *c, struct xen_domctl_scheduler_op
                 EDOM_INFO(p)->period_orig = 
                     EDOM_INFO(p)->period  = WEIGHT_PERIOD;
                 EDOM_INFO(p)->slice_orig  =
-                    EDOM_INFO(p)->slice   = 
-                    (EDOM_INFO(p)->weight *
-                     (WEIGHT_PERIOD - WEIGHT_SAFETY - sumt[cpu])) / sumw[cpu];
+                    EDOM_INFO(p)->slice   = div64(
+                        EDOM_INFO(p)->weight * (WEIGHT_PERIOD - WEIGHT_SAFETY - sumt[cpu]),
+                        sumw[cpu]);
             }
         }
     }
diff --git a/xen/common/timer.c b/xen/common/timer.c
index 0547ea3..043250e 100644
--- a/xen/common/timer.c
+++ b/xen/common/timer.c
@@ -23,6 +23,7 @@
 #include <xen/symbols.h>
 #include <asm/system.h>
 #include <asm/desc.h>
+#include <asm/div64.h>
 #include <asm/atomic.h>
 
 /* We program the time hardware this far behind the closest deadline. */
@@ -503,16 +504,18 @@ static void timer_softirq_action(void)
 
 s_time_t align_timer(s_time_t firsttick, uint64_t period)
 {
+    uint64_t n;
     if ( !period )
         return firsttick;
 
-    return firsttick + (period - 1) - ((firsttick - 1) % period);
+    n = firsttick + (period - 1) - (firsttick - 1);
+    return do_div(n, period);
 }
 
 static void dump_timer(struct timer *t, s_time_t now)
 {
     printk("  ex=%8"PRId64"us timer=%p cb=%p(%p)",
-           (t->expires - now) / 1000, t, t->function, t->data);
+           div64(t->expires - now, 1000), t, t->function, t->data);
     print_symbol(" %s\n", (unsigned long)t->function);
 }
 
diff --git a/xen/include/asm-ia64/linux/asm-generic/div64.h b/xen/include/asm-ia64/linux/asm-generic/div64.h
index 8f4e319..820c073 100644
--- a/xen/include/asm-ia64/linux/asm-generic/div64.h
+++ b/xen/include/asm-ia64/linux/asm-generic/div64.h
@@ -55,4 +55,10 @@ extern uint32_t __div64_32(uint64_t *dividend, uint32_t divisor);
 
 #endif /* BITS_PER_LONG */
 
+static inline uint64_t div64(uint64_t n, uint32_t base)
+{
+	do_div(n, base);
+	return n;
+}
+
 #endif /* _ASM_GENERIC_DIV64_H */
diff --git a/xen/include/asm-x86/div64.h b/xen/include/asm-x86/div64.h
index 1ce87cd..800ef2a 100644
--- a/xen/include/asm-x86/div64.h
+++ b/xen/include/asm-x86/div64.h
@@ -46,4 +46,10 @@
 
 #endif
 
+static inline uint64_t div64(uint64_t n, uint32_t base)
+{
+	do_div(n, base);
+	return n;
+}
+
 #endif
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 18:20:37 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 18:20:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXzcy-0007vL-SX; Tue, 06 Dec 2011 18:20:28 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RXzcx-0007uP-Fj
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 18:20:27 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1323195530!59687716!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDcxMjI=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2241 invoked from network); 6 Dec 2011 18:18:57 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Dec 2011 18:18:57 -0000
X-IronPort-AV: E=Sophos;i="4.71,307,1320642000"; d="scan'208";a="19721944"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Dec 2011 13:19:45 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Tue, 6 Dec 2011 13:19:45 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pB6IJEjO019549;
	Tue, 6 Dec 2011 10:19:34 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Tue, 6 Dec 2011 18:19:58 +0000
Message-ID: <1323195609-17277-14-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1112061753410.31179@kaball-desktop>
References: <alpine.DEB.2.00.1112061753410.31179@kaball-desktop>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>, Tim.Deegan@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH RFC 14/25] arm: domain_build
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Functions to build dom0: memory allocation, p2m construction, mappings
of the MMIO regions, ATAG setup.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
---
 xen/arch/arm/Makefile              |    1 +
 xen/arch/arm/domain_build.c        |  211 ++++++++++++++++++++++++++++++++++++
 xen/common/libelf/libelf-dominfo.c |    6 +
 xen/include/asm-arm/setup.h        |    2 +
 xen/include/xen/libelf.h           |    2 +-
 5 files changed, 221 insertions(+), 1 deletions(-)
 create mode 100644 xen/arch/arm/domain_build.c

diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index 8549f33..28faa73 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -3,6 +3,7 @@ subdir-y += lib
 obj-y += dummy.o
 obj-y += entry.o
 obj-y += domain.o
+obj-y += domain_build.o
 
 #obj-bin-y += ....o
 
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
new file mode 100644
index 0000000..bffd85e
--- /dev/null
+++ b/xen/arch/arm/domain_build.c
@@ -0,0 +1,211 @@
+#include <xen/config.h>
+#include <xen/init.h>
+#include <xen/lib.h>
+#include <xen/mm.h>
+#include <xen/domain_page.h>
+#include <xen/sched.h>
+#include <xen/libelf.h>
+#include <asm/irq.h>
+
+#include "gic.h"
+
+static unsigned int __initdata opt_dom0_max_vcpus;
+integer_param("dom0_max_vcpus", opt_dom0_max_vcpus);
+
+struct vcpu *__init alloc_dom0_vcpu0(void)
+{
+    dom0->vcpu = xmalloc_array(struct vcpu *, opt_dom0_max_vcpus);
+    if ( !dom0->vcpu )
+    {
+            printk("failed to alloc dom0->vccpu\n");
+        return NULL;
+    }
+    memset(dom0->vcpu, 0, opt_dom0_max_vcpus * sizeof(*dom0->vcpu));
+    dom0->max_vcpus = opt_dom0_max_vcpus;
+
+    return alloc_vcpu(dom0, 0, 0);
+}
+
+extern void guest_mode_entry(void);
+
+static void copy_from_flash(void *dst, paddr_t flash, unsigned long len)
+{
+    void *src = (void *)FIXMAP_ADDR(FIXMAP_MISC);
+    unsigned long offs;
+
+    printk("Copying %#lx bytes from flash %"PRIpaddr" to %p-%p: [",
+           len, flash, dst, dst+(1<<23));
+    for ( offs = 0; offs < len ; offs += PAGE_SIZE )
+    {
+        if ( ( offs % (1<<20) ) == 0 )
+            printk(".");
+        set_fixmap(FIXMAP_MISC, (flash+offs) >> PAGE_SHIFT, DEV_SHARED);
+        memcpy(dst+offs, src, PAGE_SIZE);
+    }
+    printk("]\n");
+
+    clear_fixmap(FIXMAP_MISC);
+}
+
+static void setup_linux_atag(paddr_t tags, paddr_t ram_s, paddr_t ram_e)
+{
+    paddr_t ma = gvirt_to_maddr(tags);
+    void *map = map_domain_page(ma>>PAGE_SHIFT);
+    void *p = map + (tags & (PAGE_SIZE - 1));
+    char cmdline[] = "earlyprintk=xenboot console=ttyAMA1 root=/dev/mmcblk0 debug rw";
+
+    /* not enough room on this page for all the tags */
+    BUG_ON(PAGE_SIZE - (tags & (PAGE_SIZE - 1)) < 8 * sizeof(uint32_t));
+
+#define TAG(type, val) *(type*)p = val; p+= sizeof(type)
+
+    /* ATAG_CORE */
+    TAG(uint32_t, 2);
+    TAG(uint32_t, 0x54410001);
+
+    /* ATAG_MEM */
+    TAG(uint32_t, 4);
+    TAG(uint32_t, 0x54410002);
+    TAG(uint32_t, (ram_e - ram_s) & 0xFFFFFFFF);
+    TAG(uint32_t, ram_s & 0xFFFFFFFF);
+
+    /* ATAG_CMDLINE */
+    TAG(uint32_t, 2 + ((strlen(cmdline) + 4) >> 2));
+    TAG(uint32_t, 0x54410009);
+    memcpy(p, cmdline, strlen(cmdline) + 1);
+    p += ((strlen(cmdline) + 4) >> 2) << 2;
+
+    /* ATAG_NONE */
+    TAG(uint32_t, 0);
+    TAG(uint32_t, 0);
+
+#undef TAG
+
+    unmap_domain_page(map);
+}
+
+/* Store kernel in first 8M of flash */
+#define KERNEL_FLASH_ADDRESS 0x00000000UL
+#define KERNEL_FLASH_SIZE    0x00800000UL
+
+int construct_dom0(struct domain *d)
+{
+    int rc, kernel_order;
+    void *kernel_img;
+
+    struct vcpu *v = d->vcpu[0];
+    struct cpu_user_regs *regs = &v->arch.user_regs;
+
+    struct elf_binary elf;
+    struct elf_dom_parms parms;
+
+    /* Sanity! */
+    BUG_ON(d->domain_id != 0);
+    BUG_ON(d->vcpu[0] == NULL);
+    BUG_ON(v->is_initialised);
+
+    printk("*** LOADING DOMAIN 0 ***\n");
+
+    kernel_order = get_order_from_bytes(KERNEL_FLASH_SIZE);
+    kernel_img = alloc_xenheap_pages(kernel_order, 0);
+    if ( kernel_img == NULL )
+        panic("Cannot allocate temporary buffer for kernel.\n");
+
+    copy_from_flash(kernel_img, KERNEL_FLASH_ADDRESS, KERNEL_FLASH_SIZE);
+
+    d->max_pages = ~0U;
+
+    if ( (rc = elf_init(&elf, kernel_img, KERNEL_FLASH_SIZE )) != 0 )
+        return rc;  memset(regs, 0, sizeof(*regs));
+#ifdef VERBOSE
+    elf_set_verbose(&elf);
+#endif
+    elf_parse_binary(&elf);
+    if ( (rc = elf_xen_parse(&elf, &parms)) != 0 )
+        return rc;
+
+    if ( (rc = p2m_alloc_table(d)) != 0 )
+        return rc;
+
+    /* 128M at 3G physical */
+    /* TODO size and location according to platform info */
+    printk("Populate P2M %#llx->%#llx\n", 0xc0000000ULL, 0xc8000000ULL);
+    p2m_populate_ram(d, 0xc0000000ULL, 0xc8000000ULL);
+
+    printk("Map CS2 MMIO regions 1:1 in the P2M %#llx->%#llx\n", 0x18000000ULL, 0x1BFFFFFFULL);
+    map_mmio_regions(d, 0x18000000, 0x1BFFFFFF, 0x18000000);
+    printk("Map CS3 MMIO regions 1:1 in the P2M %#llx->%#llx\n", 0x1C000000ULL, 0x1FFFFFFFULL);
+    map_mmio_regions(d, 0x1C000000, 0x1FFFFFFF, 0x1C000000);
+    printk("Map VGIC MMIO regions 1:1 in the P2M %#llx->%#llx\n", 0x2C008000ULL, 0x2DFFFFFFULL);
+    map_mmio_regions(d, 0x2C008000, 0x2DFFFFFF, 0x2C008000);
+
+    gicv_setup(d);
+
+    printk("Routing peripheral interrupts to guest\n");
+    /* TODO Get from device tree */
+    /*gic_route_irq_to_guest(d, 37, "uart0"); -- XXX used by Xen*/
+    gic_route_irq_to_guest(d, 38, "uart1");
+    gic_route_irq_to_guest(d, 39, "uart2");
+    gic_route_irq_to_guest(d, 40, "uart3");
+    gic_route_irq_to_guest(d, 41, "mmc0-1");
+    gic_route_irq_to_guest(d, 42, "mmc0-2");
+    gic_route_irq_to_guest(d, 44, "keyboard");
+    gic_route_irq_to_guest(d, 45, "mouse");
+    gic_route_irq_to_guest(d, 46, "lcd");
+    gic_route_irq_to_guest(d, 47, "eth");
+
+    /* Enable second stage translation */
+    WRITE_CP32(READ_CP32(HCR) | HCR_VM, HCR); isb();
+
+    /* The following load uses domain's p2m */
+    p2m_load_VTTBR(d);
+
+    printk("Loading ELF image into guest memory\n");
+    elf_load_binary(&elf);
+
+    printk("Free temporary kernel buffer\n");
+    free_xenheap_pages(kernel_img, kernel_order);
+
+    setup_linux_atag(0xc0000100ULL, 0xc0000000ULL, 0xc8000000ULL);
+
+    clear_bit(_VPF_down, &v->pause_flags);
+
+    memset(regs, 0, sizeof(*regs));
+
+    regs->pc = (uint32_t)parms.virt_entry;
+
+    regs->cpsr = PSR_ABT_MASK|PSR_FIQ_MASK|PSR_IRQ_MASK|PSR_MODE_SVC;
+
+/* FROM LINUX head.S
+
+ * Kernel startup entry point.
+ * ---------------------------
+ *
+ * This is normally called from the decompressor code.  The requirements
+ * are: MMU = off, D-cache = off, I-cache = dont care, r0 = 0,
+ * r1 = machine nr, r2 = atags or dtb pointer.
+ *...
+ */
+
+    regs->r0 = 0; /* SBZ */
+    regs->r1 = 2272; /* Machine NR: Versatile Express */
+    regs->r2 = 0xc0000100; /* ATAGS */
+
+    WRITE_CP32(SCTLR_BASE, SCTLR);
+
+    WRITE_CP32(HCR_AMO|HCR_IMO|HCR_VM, HCR);
+    isb();
+
+    local_abort_enable();
+
+    return 0;
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/common/libelf/libelf-dominfo.c b/xen/common/libelf/libelf-dominfo.c
index c569a48..523837f 100644
--- a/xen/common/libelf/libelf-dominfo.c
+++ b/xen/common/libelf/libelf-dominfo.c
@@ -341,6 +341,12 @@ static int elf_xen_note_check(struct elf_binary *elf,
         return 0;
     }
 
+    if ( elf_uval(elf, elf->ehdr, e_machine) == EM_ARM )
+    {
+         elf_msg(elf, "%s: Not bothering with notes on ARM\n", __FUNCTION__);
+         return 0;
+    }
+
     /* Check the contents of the Xen notes or guest string. */
     if ( ((strlen(parms->loader) == 0) ||
           strncmp(parms->loader, "generic", 7)) &&
diff --git a/xen/include/asm-arm/setup.h b/xen/include/asm-arm/setup.h
index c27d438..1dc3f97 100644
--- a/xen/include/asm-arm/setup.h
+++ b/xen/include/asm-arm/setup.h
@@ -5,6 +5,8 @@
 
 void arch_get_xen_caps(xen_capabilities_info_t *info);
 
+int construct_dom0(struct domain *d);
+
 #endif
 /*
  * Local variables:
diff --git a/xen/include/xen/libelf.h b/xen/include/xen/libelf.h
index 9de84eb..d799a80 100644
--- a/xen/include/xen/libelf.h
+++ b/xen/include/xen/libelf.h
@@ -23,7 +23,7 @@
 #ifndef __XEN_LIBELF_H__
 #define __XEN_LIBELF_H__
 
-#if defined(__i386__) || defined(__x86_64__) || defined(__ia64__)
+#if defined(__i386__) || defined(__x86_64__) || defined(__ia64__) || defined(__arm__)
 #define XEN_ELF_LITTLE_ENDIAN
 #else
 #error define architectural endianness
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 18:20:37 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 18:20:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXzct-0007t3-AO; Tue, 06 Dec 2011 18:20:23 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RXzcr-0007sa-V0
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 18:20:22 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1323195530!59687716!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDcxMjI=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2087 invoked from network); 6 Dec 2011 18:18:51 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Dec 2011 18:18:51 -0000
X-IronPort-AV: E=Sophos;i="4.71,307,1320642000"; d="scan'208";a="19721938"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Dec 2011 13:19:39 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Tue, 6 Dec 2011 13:19:39 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pB6IJEjG019549;
	Tue, 6 Dec 2011 10:19:22 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Tue, 6 Dec 2011 18:19:50 +0000
Message-ID: <1323195609-17277-6-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1112061753410.31179@kaball-desktop>
References: <alpine.DEB.2.00.1112061753410.31179@kaball-desktop>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>, Tim.Deegan@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH RFC 06/25] libelf-loader: introduce
	elf_load_image and CONFIG_KERNEL_NO_RELOC
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Implement a new function, called elf_load_image, to perform the actually
copy of the elf image and clearing the padding.
The function is implemented as memcpy and memset when the library is
built as part of the tools, but it is implemented as copy_to_user and
clear_user when built as part of Xen, so that it can be safely called
with an HVM style dom0.

Introduce CONFIG_KERNEL_NO_RELOC: the dom0 kernel might not support
being relocated to an address different of the one specified in the elf
file.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
---
 xen/common/libelf/libelf-loader.c |   21 +++++++++++++++++++--
 1 files changed, 19 insertions(+), 2 deletions(-)

diff --git a/xen/common/libelf/libelf-loader.c b/xen/common/libelf/libelf-loader.c
index 1ccf7d3..21e3804 100644
--- a/xen/common/libelf/libelf-loader.c
+++ b/xen/common/libelf/libelf-loader.c
@@ -107,11 +107,25 @@ void elf_set_log(struct elf_binary *elf, elf_log_callback *log_callback,
     elf->log_caller_data = log_caller_data;
     elf->verbose = verbose;
 }
+
+static void elf_load_image(void *dst, const void *src, uint64_t filesz, uint64_t memsz)
+{
+    memcpy(dst, src, filesz);
+    memset(dst + filesz, 0, memsz - filesz);
+}
 #else
+#include <asm/guest_access.h>
+
 void elf_set_verbose(struct elf_binary *elf)
 {
     elf->verbose = 1;
 }
+
+static void elf_load_image(void *dst, const void *src, uint64_t filesz, uint64_t memsz)
+{
+    copy_to_user(dst, src, filesz);
+    clear_user(dst + filesz, memsz - filesz);
+}
 #endif
 
 /* Calculate the required additional kernel space for the elf image */
@@ -256,8 +270,7 @@ void elf_load_binary(struct elf_binary *elf)
         dest = elf_get_ptr(elf, paddr);
         elf_msg(elf, "%s: phdr %" PRIu64 " at 0x%p -> 0x%p\n",
                 __func__, i, dest, dest + filesz);
-        memcpy(dest, elf->image + offset, filesz);
-        memset(dest + filesz, 0, memsz - filesz);
+        elf_load_image(dest, elf->image + offset, filesz, memsz);
     }
 
     elf_load_bsdsyms(elf);
@@ -265,7 +278,11 @@ void elf_load_binary(struct elf_binary *elf)
 
 void *elf_get_ptr(struct elf_binary *elf, unsigned long addr)
 {
+#ifdef CONFIG_KERNEL_NO_RELOC
+    return elf->dest + addr;
+#else
     return elf->dest + addr - elf->pstart;
+#endif
 }
 
 uint64_t elf_lookup_addr(struct elf_binary * elf, const char *symbol)
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 18:20:37 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 18:20:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXzcw-0007uI-QL; Tue, 06 Dec 2011 18:20:26 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RXzcv-0007sO-1x
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 18:20:25 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1323195573!4508317!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDcxMjI=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13428 invoked from network); 6 Dec 2011 18:19:39 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Dec 2011 18:19:39 -0000
X-IronPort-AV: E=Sophos;i="4.71,307,1320642000"; d="scan'208";a="19721937"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Dec 2011 13:19:38 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Tue, 6 Dec 2011 13:19:38 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pB6IJEjJ019549;
	Tue, 6 Dec 2011 10:19:27 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Tue, 6 Dec 2011 18:19:53 +0000
Message-ID: <1323195609-17277-9-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1112061753410.31179@kaball-desktop>
References: <alpine.DEB.2.00.1112061753410.31179@kaball-desktop>
MIME-Version: 1.0
Cc: Ian.Campbell@citrix.com, Tim.Deegan@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH RFC 09/25] arm: compile tmem
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Include few missing header files; fix the definition of cli_put_page;
introduce defined(CONFIG_ARM) where required.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen/common/tmem.c     |    3 ++-
 xen/common/tmem_xen.c |    6 ++++--
 2 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/xen/common/tmem.c b/xen/common/tmem.c
index 115465b..dd276df 100644
--- a/xen/common/tmem.c
+++ b/xen/common/tmem.c
@@ -22,6 +22,7 @@
 #include <xen/rbtree.h>
 #include <xen/radix-tree.h>
 #include <xen/list.h>
+#include <xen/init.h>
 
 #define EXPORT /* indicates code other modules are dependent upon */
 #define FORWARD
@@ -49,7 +50,7 @@
 #define INVERT_SENTINEL(_x,_y) _x->sentinel = ~_y##_SENTINEL
 #define ASSERT_SENTINEL(_x,_y) \
     ASSERT(_x->sentinel != ~_y##_SENTINEL);ASSERT(_x->sentinel == _y##_SENTINEL)
-#ifdef __i386__
+#if defined(__i386__) || defined(CONFIG_ARM)
 #define POOL_SENTINEL 0x87658765
 #define OBJ_SENTINEL 0x12345678
 #define OBJNODE_SENTINEL 0xfedcba09
diff --git a/xen/common/tmem_xen.c b/xen/common/tmem_xen.c
index c094095..9b2a22c 100644
--- a/xen/common/tmem_xen.c
+++ b/xen/common/tmem_xen.c
@@ -12,6 +12,8 @@
 #include <xen/paging.h>
 #include <xen/domain_page.h>
 #include <xen/cpu.h>
+#include <xen/init.h>
+#include <asm/p2m.h>
 
 #define EXPORT /* indicates code other modules are dependent upon */
 
@@ -87,7 +89,7 @@ void tmh_copy_page(char *to, char*from)
 #endif
 }
 
-#ifdef __ia64__
+#if defined(__ia64__) || defined (CONFIG_ARM)
 static inline void *cli_get_page(tmem_cli_mfn_t cmfn, unsigned long *pcli_mfn,
                                  pfp_t **pcli_pfp, bool_t cli_write)
 {
@@ -95,7 +97,7 @@ static inline void *cli_get_page(tmem_cli_mfn_t cmfn, unsigned long *pcli_mfn,
     return NULL;
 }
 
-static inline void cli_put_page(void *cli_va, pfp_t *cli_pfp,
+static inline void cli_put_page(tmem_cli_mfn_t cmfn, void *cli_va, pfp_t *cli_pfp,
                                 unsigned long cli_mfn, bool_t mark_dirty)
 {
     ASSERT(0);
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 18:20:37 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 18:20:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXzcy-0007vL-SX; Tue, 06 Dec 2011 18:20:28 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RXzcx-0007uP-Fj
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 18:20:27 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1323195530!59687716!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDcxMjI=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2241 invoked from network); 6 Dec 2011 18:18:57 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Dec 2011 18:18:57 -0000
X-IronPort-AV: E=Sophos;i="4.71,307,1320642000"; d="scan'208";a="19721944"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Dec 2011 13:19:45 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Tue, 6 Dec 2011 13:19:45 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pB6IJEjO019549;
	Tue, 6 Dec 2011 10:19:34 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Tue, 6 Dec 2011 18:19:58 +0000
Message-ID: <1323195609-17277-14-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1112061753410.31179@kaball-desktop>
References: <alpine.DEB.2.00.1112061753410.31179@kaball-desktop>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>, Tim.Deegan@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH RFC 14/25] arm: domain_build
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Functions to build dom0: memory allocation, p2m construction, mappings
of the MMIO regions, ATAG setup.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
---
 xen/arch/arm/Makefile              |    1 +
 xen/arch/arm/domain_build.c        |  211 ++++++++++++++++++++++++++++++++++++
 xen/common/libelf/libelf-dominfo.c |    6 +
 xen/include/asm-arm/setup.h        |    2 +
 xen/include/xen/libelf.h           |    2 +-
 5 files changed, 221 insertions(+), 1 deletions(-)
 create mode 100644 xen/arch/arm/domain_build.c

diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index 8549f33..28faa73 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -3,6 +3,7 @@ subdir-y += lib
 obj-y += dummy.o
 obj-y += entry.o
 obj-y += domain.o
+obj-y += domain_build.o
 
 #obj-bin-y += ....o
 
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
new file mode 100644
index 0000000..bffd85e
--- /dev/null
+++ b/xen/arch/arm/domain_build.c
@@ -0,0 +1,211 @@
+#include <xen/config.h>
+#include <xen/init.h>
+#include <xen/lib.h>
+#include <xen/mm.h>
+#include <xen/domain_page.h>
+#include <xen/sched.h>
+#include <xen/libelf.h>
+#include <asm/irq.h>
+
+#include "gic.h"
+
+static unsigned int __initdata opt_dom0_max_vcpus;
+integer_param("dom0_max_vcpus", opt_dom0_max_vcpus);
+
+struct vcpu *__init alloc_dom0_vcpu0(void)
+{
+    dom0->vcpu = xmalloc_array(struct vcpu *, opt_dom0_max_vcpus);
+    if ( !dom0->vcpu )
+    {
+            printk("failed to alloc dom0->vccpu\n");
+        return NULL;
+    }
+    memset(dom0->vcpu, 0, opt_dom0_max_vcpus * sizeof(*dom0->vcpu));
+    dom0->max_vcpus = opt_dom0_max_vcpus;
+
+    return alloc_vcpu(dom0, 0, 0);
+}
+
+extern void guest_mode_entry(void);
+
+static void copy_from_flash(void *dst, paddr_t flash, unsigned long len)
+{
+    void *src = (void *)FIXMAP_ADDR(FIXMAP_MISC);
+    unsigned long offs;
+
+    printk("Copying %#lx bytes from flash %"PRIpaddr" to %p-%p: [",
+           len, flash, dst, dst+(1<<23));
+    for ( offs = 0; offs < len ; offs += PAGE_SIZE )
+    {
+        if ( ( offs % (1<<20) ) == 0 )
+            printk(".");
+        set_fixmap(FIXMAP_MISC, (flash+offs) >> PAGE_SHIFT, DEV_SHARED);
+        memcpy(dst+offs, src, PAGE_SIZE);
+    }
+    printk("]\n");
+
+    clear_fixmap(FIXMAP_MISC);
+}
+
+static void setup_linux_atag(paddr_t tags, paddr_t ram_s, paddr_t ram_e)
+{
+    paddr_t ma = gvirt_to_maddr(tags);
+    void *map = map_domain_page(ma>>PAGE_SHIFT);
+    void *p = map + (tags & (PAGE_SIZE - 1));
+    char cmdline[] = "earlyprintk=xenboot console=ttyAMA1 root=/dev/mmcblk0 debug rw";
+
+    /* not enough room on this page for all the tags */
+    BUG_ON(PAGE_SIZE - (tags & (PAGE_SIZE - 1)) < 8 * sizeof(uint32_t));
+
+#define TAG(type, val) *(type*)p = val; p+= sizeof(type)
+
+    /* ATAG_CORE */
+    TAG(uint32_t, 2);
+    TAG(uint32_t, 0x54410001);
+
+    /* ATAG_MEM */
+    TAG(uint32_t, 4);
+    TAG(uint32_t, 0x54410002);
+    TAG(uint32_t, (ram_e - ram_s) & 0xFFFFFFFF);
+    TAG(uint32_t, ram_s & 0xFFFFFFFF);
+
+    /* ATAG_CMDLINE */
+    TAG(uint32_t, 2 + ((strlen(cmdline) + 4) >> 2));
+    TAG(uint32_t, 0x54410009);
+    memcpy(p, cmdline, strlen(cmdline) + 1);
+    p += ((strlen(cmdline) + 4) >> 2) << 2;
+
+    /* ATAG_NONE */
+    TAG(uint32_t, 0);
+    TAG(uint32_t, 0);
+
+#undef TAG
+
+    unmap_domain_page(map);
+}
+
+/* Store kernel in first 8M of flash */
+#define KERNEL_FLASH_ADDRESS 0x00000000UL
+#define KERNEL_FLASH_SIZE    0x00800000UL
+
+int construct_dom0(struct domain *d)
+{
+    int rc, kernel_order;
+    void *kernel_img;
+
+    struct vcpu *v = d->vcpu[0];
+    struct cpu_user_regs *regs = &v->arch.user_regs;
+
+    struct elf_binary elf;
+    struct elf_dom_parms parms;
+
+    /* Sanity! */
+    BUG_ON(d->domain_id != 0);
+    BUG_ON(d->vcpu[0] == NULL);
+    BUG_ON(v->is_initialised);
+
+    printk("*** LOADING DOMAIN 0 ***\n");
+
+    kernel_order = get_order_from_bytes(KERNEL_FLASH_SIZE);
+    kernel_img = alloc_xenheap_pages(kernel_order, 0);
+    if ( kernel_img == NULL )
+        panic("Cannot allocate temporary buffer for kernel.\n");
+
+    copy_from_flash(kernel_img, KERNEL_FLASH_ADDRESS, KERNEL_FLASH_SIZE);
+
+    d->max_pages = ~0U;
+
+    if ( (rc = elf_init(&elf, kernel_img, KERNEL_FLASH_SIZE )) != 0 )
+        return rc;  memset(regs, 0, sizeof(*regs));
+#ifdef VERBOSE
+    elf_set_verbose(&elf);
+#endif
+    elf_parse_binary(&elf);
+    if ( (rc = elf_xen_parse(&elf, &parms)) != 0 )
+        return rc;
+
+    if ( (rc = p2m_alloc_table(d)) != 0 )
+        return rc;
+
+    /* 128M at 3G physical */
+    /* TODO size and location according to platform info */
+    printk("Populate P2M %#llx->%#llx\n", 0xc0000000ULL, 0xc8000000ULL);
+    p2m_populate_ram(d, 0xc0000000ULL, 0xc8000000ULL);
+
+    printk("Map CS2 MMIO regions 1:1 in the P2M %#llx->%#llx\n", 0x18000000ULL, 0x1BFFFFFFULL);
+    map_mmio_regions(d, 0x18000000, 0x1BFFFFFF, 0x18000000);
+    printk("Map CS3 MMIO regions 1:1 in the P2M %#llx->%#llx\n", 0x1C000000ULL, 0x1FFFFFFFULL);
+    map_mmio_regions(d, 0x1C000000, 0x1FFFFFFF, 0x1C000000);
+    printk("Map VGIC MMIO regions 1:1 in the P2M %#llx->%#llx\n", 0x2C008000ULL, 0x2DFFFFFFULL);
+    map_mmio_regions(d, 0x2C008000, 0x2DFFFFFF, 0x2C008000);
+
+    gicv_setup(d);
+
+    printk("Routing peripheral interrupts to guest\n");
+    /* TODO Get from device tree */
+    /*gic_route_irq_to_guest(d, 37, "uart0"); -- XXX used by Xen*/
+    gic_route_irq_to_guest(d, 38, "uart1");
+    gic_route_irq_to_guest(d, 39, "uart2");
+    gic_route_irq_to_guest(d, 40, "uart3");
+    gic_route_irq_to_guest(d, 41, "mmc0-1");
+    gic_route_irq_to_guest(d, 42, "mmc0-2");
+    gic_route_irq_to_guest(d, 44, "keyboard");
+    gic_route_irq_to_guest(d, 45, "mouse");
+    gic_route_irq_to_guest(d, 46, "lcd");
+    gic_route_irq_to_guest(d, 47, "eth");
+
+    /* Enable second stage translation */
+    WRITE_CP32(READ_CP32(HCR) | HCR_VM, HCR); isb();
+
+    /* The following load uses domain's p2m */
+    p2m_load_VTTBR(d);
+
+    printk("Loading ELF image into guest memory\n");
+    elf_load_binary(&elf);
+
+    printk("Free temporary kernel buffer\n");
+    free_xenheap_pages(kernel_img, kernel_order);
+
+    setup_linux_atag(0xc0000100ULL, 0xc0000000ULL, 0xc8000000ULL);
+
+    clear_bit(_VPF_down, &v->pause_flags);
+
+    memset(regs, 0, sizeof(*regs));
+
+    regs->pc = (uint32_t)parms.virt_entry;
+
+    regs->cpsr = PSR_ABT_MASK|PSR_FIQ_MASK|PSR_IRQ_MASK|PSR_MODE_SVC;
+
+/* FROM LINUX head.S
+
+ * Kernel startup entry point.
+ * ---------------------------
+ *
+ * This is normally called from the decompressor code.  The requirements
+ * are: MMU = off, D-cache = off, I-cache = dont care, r0 = 0,
+ * r1 = machine nr, r2 = atags or dtb pointer.
+ *...
+ */
+
+    regs->r0 = 0; /* SBZ */
+    regs->r1 = 2272; /* Machine NR: Versatile Express */
+    regs->r2 = 0xc0000100; /* ATAGS */
+
+    WRITE_CP32(SCTLR_BASE, SCTLR);
+
+    WRITE_CP32(HCR_AMO|HCR_IMO|HCR_VM, HCR);
+    isb();
+
+    local_abort_enable();
+
+    return 0;
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/common/libelf/libelf-dominfo.c b/xen/common/libelf/libelf-dominfo.c
index c569a48..523837f 100644
--- a/xen/common/libelf/libelf-dominfo.c
+++ b/xen/common/libelf/libelf-dominfo.c
@@ -341,6 +341,12 @@ static int elf_xen_note_check(struct elf_binary *elf,
         return 0;
     }
 
+    if ( elf_uval(elf, elf->ehdr, e_machine) == EM_ARM )
+    {
+         elf_msg(elf, "%s: Not bothering with notes on ARM\n", __FUNCTION__);
+         return 0;
+    }
+
     /* Check the contents of the Xen notes or guest string. */
     if ( ((strlen(parms->loader) == 0) ||
           strncmp(parms->loader, "generic", 7)) &&
diff --git a/xen/include/asm-arm/setup.h b/xen/include/asm-arm/setup.h
index c27d438..1dc3f97 100644
--- a/xen/include/asm-arm/setup.h
+++ b/xen/include/asm-arm/setup.h
@@ -5,6 +5,8 @@
 
 void arch_get_xen_caps(xen_capabilities_info_t *info);
 
+int construct_dom0(struct domain *d);
+
 #endif
 /*
  * Local variables:
diff --git a/xen/include/xen/libelf.h b/xen/include/xen/libelf.h
index 9de84eb..d799a80 100644
--- a/xen/include/xen/libelf.h
+++ b/xen/include/xen/libelf.h
@@ -23,7 +23,7 @@
 #ifndef __XEN_LIBELF_H__
 #define __XEN_LIBELF_H__
 
-#if defined(__i386__) || defined(__x86_64__) || defined(__ia64__)
+#if defined(__i386__) || defined(__x86_64__) || defined(__ia64__) || defined(__arm__)
 #define XEN_ELF_LITTLE_ENDIAN
 #else
 #error define architectural endianness
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 18:20:37 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 18:20:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXzct-0007t3-AO; Tue, 06 Dec 2011 18:20:23 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RXzcr-0007sa-V0
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 18:20:22 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1323195530!59687716!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDcxMjI=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2087 invoked from network); 6 Dec 2011 18:18:51 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Dec 2011 18:18:51 -0000
X-IronPort-AV: E=Sophos;i="4.71,307,1320642000"; d="scan'208";a="19721938"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Dec 2011 13:19:39 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Tue, 6 Dec 2011 13:19:39 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pB6IJEjG019549;
	Tue, 6 Dec 2011 10:19:22 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Tue, 6 Dec 2011 18:19:50 +0000
Message-ID: <1323195609-17277-6-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1112061753410.31179@kaball-desktop>
References: <alpine.DEB.2.00.1112061753410.31179@kaball-desktop>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>, Tim.Deegan@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH RFC 06/25] libelf-loader: introduce
	elf_load_image and CONFIG_KERNEL_NO_RELOC
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Implement a new function, called elf_load_image, to perform the actually
copy of the elf image and clearing the padding.
The function is implemented as memcpy and memset when the library is
built as part of the tools, but it is implemented as copy_to_user and
clear_user when built as part of Xen, so that it can be safely called
with an HVM style dom0.

Introduce CONFIG_KERNEL_NO_RELOC: the dom0 kernel might not support
being relocated to an address different of the one specified in the elf
file.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
---
 xen/common/libelf/libelf-loader.c |   21 +++++++++++++++++++--
 1 files changed, 19 insertions(+), 2 deletions(-)

diff --git a/xen/common/libelf/libelf-loader.c b/xen/common/libelf/libelf-loader.c
index 1ccf7d3..21e3804 100644
--- a/xen/common/libelf/libelf-loader.c
+++ b/xen/common/libelf/libelf-loader.c
@@ -107,11 +107,25 @@ void elf_set_log(struct elf_binary *elf, elf_log_callback *log_callback,
     elf->log_caller_data = log_caller_data;
     elf->verbose = verbose;
 }
+
+static void elf_load_image(void *dst, const void *src, uint64_t filesz, uint64_t memsz)
+{
+    memcpy(dst, src, filesz);
+    memset(dst + filesz, 0, memsz - filesz);
+}
 #else
+#include <asm/guest_access.h>
+
 void elf_set_verbose(struct elf_binary *elf)
 {
     elf->verbose = 1;
 }
+
+static void elf_load_image(void *dst, const void *src, uint64_t filesz, uint64_t memsz)
+{
+    copy_to_user(dst, src, filesz);
+    clear_user(dst + filesz, memsz - filesz);
+}
 #endif
 
 /* Calculate the required additional kernel space for the elf image */
@@ -256,8 +270,7 @@ void elf_load_binary(struct elf_binary *elf)
         dest = elf_get_ptr(elf, paddr);
         elf_msg(elf, "%s: phdr %" PRIu64 " at 0x%p -> 0x%p\n",
                 __func__, i, dest, dest + filesz);
-        memcpy(dest, elf->image + offset, filesz);
-        memset(dest + filesz, 0, memsz - filesz);
+        elf_load_image(dest, elf->image + offset, filesz, memsz);
     }
 
     elf_load_bsdsyms(elf);
@@ -265,7 +278,11 @@ void elf_load_binary(struct elf_binary *elf)
 
 void *elf_get_ptr(struct elf_binary *elf, unsigned long addr)
 {
+#ifdef CONFIG_KERNEL_NO_RELOC
+    return elf->dest + addr;
+#else
     return elf->dest + addr - elf->pstart;
+#endif
 }
 
 uint64_t elf_lookup_addr(struct elf_binary * elf, const char *symbol)
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 18:20:37 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 18:20:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXzcw-0007uI-QL; Tue, 06 Dec 2011 18:20:26 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RXzcv-0007sO-1x
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 18:20:25 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1323195573!4508317!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDcxMjI=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13428 invoked from network); 6 Dec 2011 18:19:39 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Dec 2011 18:19:39 -0000
X-IronPort-AV: E=Sophos;i="4.71,307,1320642000"; d="scan'208";a="19721937"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Dec 2011 13:19:38 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Tue, 6 Dec 2011 13:19:38 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pB6IJEjJ019549;
	Tue, 6 Dec 2011 10:19:27 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Tue, 6 Dec 2011 18:19:53 +0000
Message-ID: <1323195609-17277-9-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1112061753410.31179@kaball-desktop>
References: <alpine.DEB.2.00.1112061753410.31179@kaball-desktop>
MIME-Version: 1.0
Cc: Ian.Campbell@citrix.com, Tim.Deegan@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH RFC 09/25] arm: compile tmem
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Include few missing header files; fix the definition of cli_put_page;
introduce defined(CONFIG_ARM) where required.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen/common/tmem.c     |    3 ++-
 xen/common/tmem_xen.c |    6 ++++--
 2 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/xen/common/tmem.c b/xen/common/tmem.c
index 115465b..dd276df 100644
--- a/xen/common/tmem.c
+++ b/xen/common/tmem.c
@@ -22,6 +22,7 @@
 #include <xen/rbtree.h>
 #include <xen/radix-tree.h>
 #include <xen/list.h>
+#include <xen/init.h>
 
 #define EXPORT /* indicates code other modules are dependent upon */
 #define FORWARD
@@ -49,7 +50,7 @@
 #define INVERT_SENTINEL(_x,_y) _x->sentinel = ~_y##_SENTINEL
 #define ASSERT_SENTINEL(_x,_y) \
     ASSERT(_x->sentinel != ~_y##_SENTINEL);ASSERT(_x->sentinel == _y##_SENTINEL)
-#ifdef __i386__
+#if defined(__i386__) || defined(CONFIG_ARM)
 #define POOL_SENTINEL 0x87658765
 #define OBJ_SENTINEL 0x12345678
 #define OBJNODE_SENTINEL 0xfedcba09
diff --git a/xen/common/tmem_xen.c b/xen/common/tmem_xen.c
index c094095..9b2a22c 100644
--- a/xen/common/tmem_xen.c
+++ b/xen/common/tmem_xen.c
@@ -12,6 +12,8 @@
 #include <xen/paging.h>
 #include <xen/domain_page.h>
 #include <xen/cpu.h>
+#include <xen/init.h>
+#include <asm/p2m.h>
 
 #define EXPORT /* indicates code other modules are dependent upon */
 
@@ -87,7 +89,7 @@ void tmh_copy_page(char *to, char*from)
 #endif
 }
 
-#ifdef __ia64__
+#if defined(__ia64__) || defined (CONFIG_ARM)
 static inline void *cli_get_page(tmem_cli_mfn_t cmfn, unsigned long *pcli_mfn,
                                  pfp_t **pcli_pfp, bool_t cli_write)
 {
@@ -95,7 +97,7 @@ static inline void *cli_get_page(tmem_cli_mfn_t cmfn, unsigned long *pcli_mfn,
     return NULL;
 }
 
-static inline void cli_put_page(void *cli_va, pfp_t *cli_pfp,
+static inline void cli_put_page(tmem_cli_mfn_t cmfn, void *cli_va, pfp_t *cli_pfp,
                                 unsigned long cli_mfn, bool_t mark_dirty)
 {
     ASSERT(0);
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 18:20:37 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 18:20:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXzcs-0007so-Hu; Tue, 06 Dec 2011 18:20:22 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RXzcr-0007sA-2c
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 18:20:21 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1323195573!4508317!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDcxMjI=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13080 invoked from network); 6 Dec 2011 18:19:34 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Dec 2011 18:19:34 -0000
X-IronPort-AV: E=Sophos;i="4.71,307,1320642000"; d="scan'208";a="19721935"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Dec 2011 13:19:33 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Tue, 6 Dec 2011 13:19:32 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pB6IJEjF019549;
	Tue, 6 Dec 2011 10:19:21 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Tue, 6 Dec 2011 18:19:49 +0000
Message-ID: <1323195609-17277-5-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1112061753410.31179@kaball-desktop>
References: <alpine.DEB.2.00.1112061753410.31179@kaball-desktop>
MIME-Version: 1.0
Cc: Ian.Campbell@citrix.com, Tim.Deegan@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH RFC 05/25] Introduce clear_user
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Introduce clear_user for x86 and ia64, shamelessly taken from Linux.
The x86 version is the 32 bit clear_user implementation.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen/arch/ia64/linux/memcpy_mck.S |  177 ++++++++++++++++++++++++++++++++++++++
 xen/arch/x86/usercopy.c          |   36 ++++++++
 xen/include/asm-ia64/uaccess.h   |   12 +++
 xen/include/asm-x86/uaccess.h    |    1 +
 4 files changed, 226 insertions(+), 0 deletions(-)

diff --git a/xen/arch/ia64/linux/memcpy_mck.S b/xen/arch/ia64/linux/memcpy_mck.S
index 6f308e6..8b07006 100644
--- a/xen/arch/ia64/linux/memcpy_mck.S
+++ b/xen/arch/ia64/linux/memcpy_mck.S
@@ -659,3 +659,180 @@ EK(.ex_handler,  (p17)	st8	[dst1]=r39,8);						\
 
 /* end of McKinley specific optimization */
 END(__copy_user)
+
+/*
+ * Theory of operations:
+ *	- we check whether or not the buffer is small, i.e., less than 17
+ *	  in which case we do the byte by byte loop.
+ *
+ *	- Otherwise we go progressively from 1 byte store to 8byte store in
+ *	  the head part, the body is a 16byte store loop and we finish we the
+ *	  tail for the last 15 bytes.
+ *	  The good point about this breakdown is that the long buffer handling
+ *	  contains only 2 branches.
+ *
+ *	The reason for not using shifting & masking for both the head and the
+ *	tail is to stay semantically correct. This routine is not supposed
+ *	to write bytes outside of the buffer. While most of the time this would
+ *	be ok, we can't tolerate a mistake. A classical example is the case
+ *	of multithreaded code were to the extra bytes touched is actually owned
+ *	by another thread which runs concurrently to ours. Another, less likely,
+ *	example is with device drivers where reading an I/O mapped location may
+ *	have side effects (same thing for writing).
+ */
+GLOBAL_ENTRY(__do_clear_user)
+	.prologue
+	.save ar.pfs, saved_pfs
+	alloc	saved_pfs=ar.pfs,2,0,0,0
+	cmp.eq p6,p0=r0,len		// check for zero length
+	.save ar.lc, saved_lc
+	mov saved_lc=ar.lc		// preserve ar.lc (slow)
+	.body
+	;;				// avoid WAW on CFM
+	adds tmp=-1,len			// br.ctop is repeat/until
+	mov ret0=len			// return value is length at this point
+(p6)	br.ret.spnt.many rp
+	;;
+	cmp.lt p6,p0=16,len		// if len > 16 then long memset
+	mov ar.lc=tmp			// initialize lc for small count
+(p6)	br.cond.dptk .long_do_clear
+	;;				// WAR on ar.lc
+	//
+	// worst case 16 iterations, avg 8 iterations
+	//
+	// We could have played with the predicates to use the extra
+	// M slot for 2 stores/iteration but the cost the initialization
+	// the various counters compared to how long the loop is supposed
+	// to last on average does not make this solution viable.
+	//
+1:
+	EX( .Lexit1, st1 [buf]=r0,1 )
+	adds len=-1,len			// countdown length using len
+	br.cloop.dptk 1b
+	;;				// avoid RAW on ar.lc
+	//
+	// .Lexit4: comes from byte by byte loop
+	//	    len contains bytes left
+.Lexit1:
+	mov ret0=len			// faster than using ar.lc
+	mov ar.lc=saved_lc
+	br.ret.sptk.many rp		// end of short clear_user
+
+
+	//
+	// At this point we know we have more than 16 bytes to copy
+	// so we focus on alignment (no branches required)
+	//
+	// The use of len/len2 for countdown of the number of bytes left
+	// instead of ret0 is due to the fact that the exception code
+	// changes the values of r8.
+	//
+.long_do_clear:
+	tbit.nz p6,p0=buf,0		// odd alignment (for long_do_clear)
+	;;
+	EX( .Lexit3, (p6) st1 [buf]=r0,1 )	// 1-byte aligned
+(p6)	adds len=-1,len;;		// sync because buf is modified
+	tbit.nz p6,p0=buf,1
+	;;
+	EX( .Lexit3, (p6) st2 [buf]=r0,2 )	// 2-byte aligned
+(p6)	adds len=-2,len;;
+	tbit.nz p6,p0=buf,2
+	;;
+	EX( .Lexit3, (p6) st4 [buf]=r0,4 )	// 4-byte aligned
+(p6)	adds len=-4,len;;
+	tbit.nz p6,p0=buf,3
+	;;
+	EX( .Lexit3, (p6) st8 [buf]=r0,8 )	// 8-byte aligned
+(p6)	adds len=-8,len;;
+	shr.u cnt=len,4		// number of 128-bit (2x64bit) words
+	;;
+	cmp.eq p6,p0=r0,cnt
+	adds tmp=-1,cnt
+(p6)	br.cond.dpnt .dotail		// we have less than 16 bytes left
+	;;
+	adds buf2=8,buf			// setup second base pointer
+	mov ar.lc=tmp
+	;;
+
+	//
+	// 16bytes/iteration core loop
+	//
+	// The second store can never generate a fault because
+	// we come into the loop only when we are 16-byte aligned.
+	// This means that if we cross a page then it will always be
+	// in the first store and never in the second.
+	//
+	//
+	// We need to keep track of the remaining length. A possible (optimistic)
+	// way would be to use ar.lc and derive how many byte were left by
+	// doing : left= 16*ar.lc + 16.  this would avoid the addition at
+	// every iteration.
+	// However we need to keep the synchronization point. A template
+	// M;;MB does not exist and thus we can keep the addition at no
+	// extra cycle cost (use a nop slot anyway). It also simplifies the
+	// (unlikely)  error recovery code
+	//
+
+2:	EX(.Lexit3, st8 [buf]=r0,16 )
+	;;				// needed to get len correct when error
+	st8 [buf2]=r0,16
+	adds len=-16,len
+	br.cloop.dptk 2b
+	;;
+	mov ar.lc=saved_lc
+	//
+	// tail correction based on len only
+	//
+	// We alternate the use of len3,len2 to allow parallelism and correct
+	// error handling. We also reuse p6/p7 to return correct value.
+	// The addition of len2/len3 does not cost anything more compared to
+	// the regular memset as we had empty slots.
+	//
+.dotail:
+	mov len2=len			// for parallelization of error handling
+	mov len3=len
+	tbit.nz p6,p0=len,3
+	;;
+	EX( .Lexit2, (p6) st8 [buf]=r0,8 )	// at least 8 bytes
+(p6)	adds len3=-8,len2
+	tbit.nz p7,p6=len,2
+	;;
+	EX( .Lexit2, (p7) st4 [buf]=r0,4 )	// at least 4 bytes
+(p7)	adds len2=-4,len3
+	tbit.nz p6,p7=len,1
+	;;
+	EX( .Lexit2, (p6) st2 [buf]=r0,2 )	// at least 2 bytes
+(p6)	adds len3=-2,len2
+	tbit.nz p7,p6=len,0
+	;;
+	EX( .Lexit2, (p7) st1 [buf]=r0 )	// only 1 byte left
+	mov ret0=r0				// success
+	br.ret.sptk.many rp			// end of most likely path
+
+	//
+	// Outlined error handling code
+	//
+
+	//
+	// .Lexit3: comes from core loop, need restore pr/lc
+	//	    len contains bytes left
+	//
+	//
+	// .Lexit2:
+	//	if p6 -> coming from st8 or st2 : len2 contains what's left
+	//	if p7 -> coming from st4 or st1 : len3 contains what's left
+	// We must restore lc/pr even though might not have been used.
+.Lexit2:
+	.pred.rel "mutex", p6, p7
+(p6)	mov len=len2
+(p7)	mov len=len3
+	;;
+	//
+	// .Lexit4: comes from head, need not restore pr/lc
+	//	    len contains bytes left
+	//
+.Lexit3:
+	mov ret0=len
+	mov ar.lc=saved_lc
+	br.ret.sptk.many rp
+END(__do_clear_user)
diff --git a/xen/arch/x86/usercopy.c b/xen/arch/x86/usercopy.c
index d88e635..58dfc81 100644
--- a/xen/arch/x86/usercopy.c
+++ b/xen/arch/x86/usercopy.c
@@ -110,6 +110,42 @@ copy_to_user(void __user *to, const void *from, unsigned n)
     return n;
 }
 
+#define __do_clear_user(addr,size)					\
+do {									\
+	int __d0;							\
+	__asm__ __volatile__(						\
+		"0:	rep; stosl\n"					\
+		"	movl %2,%0\n"					\
+		"1:	rep; stosb\n"					\
+		"2:\n"							\
+		".section .fixup,\"ax\"\n"				\
+		"3:	lea 0(%2,%0,4),%0\n"				\
+		"	jmp 2b\n"					\
+		".previous\n"						\
+		_ASM_EXTABLE(0b,3b)					\
+		_ASM_EXTABLE(1b,2b)					\
+		: "=&c"(size), "=&D" (__d0)				\
+		: "r"(size & 3), "0"(size / 4), "1"(addr), "a"(0));	\
+} while (0)
+
+/**
+ * clear_user: - Zero a block of memory in user space.
+ * @to:   Destination address, in user space.
+ * @n:    Number of bytes to zero.
+ *
+ * Zero a block of memory in user space.
+ *
+ * Returns number of bytes that could not be cleared.
+ * On success, this will be zero.
+ */
+unsigned long
+clear_user(void __user *to, unsigned n)
+{
+	if ( access_ok(to, n) )
+		__do_clear_user(to, n);
+	return n;
+}
+
 /**
  * copy_from_user: - Copy a block of data from user space.
  * @to:   Destination address, in kernel space.
diff --git a/xen/include/asm-ia64/uaccess.h b/xen/include/asm-ia64/uaccess.h
index 32ef415..2ececb1 100644
--- a/xen/include/asm-ia64/uaccess.h
+++ b/xen/include/asm-ia64/uaccess.h
@@ -236,6 +236,18 @@ __copy_from_user (void *to, const void __user *from, unsigned long count)
 	__cu_len;									\
 })
 
+extern unsigned long __do_clear_user (void __user * to, unsigned long count);
+
+#define clear_user(to, n)					\
+({								\
+	void __user *__cu_to = (to);							\
+	long __cu_len = (n);								\
+											\
+	if (__access_ok(__cu_to))							\
+		__cu_len = __do_clear_user(__cu_to, __cu_len);	\
+	__cu_len;						\
+})
+
 #define copy_from_user(to, from, n)							\
 ({											\
 	void *__cu_to = (to);								\
diff --git a/xen/include/asm-x86/uaccess.h b/xen/include/asm-x86/uaccess.h
index e3e541b..d6f4458 100644
--- a/xen/include/asm-x86/uaccess.h
+++ b/xen/include/asm-x86/uaccess.h
@@ -16,6 +16,7 @@
 #endif
 
 unsigned long copy_to_user(void *to, const void *from, unsigned len);
+unsigned long clear_user(void *to, unsigned len);
 unsigned long copy_from_user(void *to, const void *from, unsigned len);
 /* Handles exceptions in both to and from, but doesn't do access_ok */
 unsigned long __copy_to_user_ll(void *to, const void *from, unsigned n);
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 18:20:37 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 18:20:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXzcv-0007u1-V1; Tue, 06 Dec 2011 18:20:25 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RXzct-0007t7-Ul
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 18:20:24 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1323195545!51363948!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMzAwOTc=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4001 invoked from network); 6 Dec 2011 18:19:10 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Dec 2011 18:19:10 -0000
X-IronPort-AV: E=Sophos;i="4.71,307,1320642000"; d="scan'208";a="173120739"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Dec 2011 13:19:42 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Tue, 6 Dec 2011 13:19:42 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pB6IJEjI019549;
	Tue, 6 Dec 2011 10:19:25 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Tue, 6 Dec 2011 18:19:52 +0000
Message-ID: <1323195609-17277-8-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1112061753410.31179@kaball-desktop>
References: <alpine.DEB.2.00.1112061753410.31179@kaball-desktop>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>, Tim.Deegan@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH RFC 08/25] arm: makefiles
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Makefile and config options for the ARM architecture.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
---
 config/arm.mk         |   18 +++++++++++++++
 xen/arch/arm/Makefile |   57 +++++++++++++++++++++++++++++++++++++++++++++++++
 xen/arch/arm/Rules.mk |   29 +++++++++++++++++++++++++
 3 files changed, 104 insertions(+), 0 deletions(-)
 create mode 100644 config/arm.mk
 create mode 100644 xen/arch/arm/Makefile
 create mode 100644 xen/arch/arm/Rules.mk

diff --git a/config/arm.mk b/config/arm.mk
new file mode 100644
index 0000000..f64f0c1
--- /dev/null
+++ b/config/arm.mk
@@ -0,0 +1,18 @@
+CONFIG_ARM := y
+CONFIG_ARM_32 := y
+CONFIG_ARM_$(XEN_OS) := y
+
+# -march= -mcpu=
+
+# Explicitly specifiy 32-bit ARM ISA since toolchain default can be -mthumb:
+CFLAGS += -marm
+
+HAS_PL011 := y
+
+# Use only if calling $(LD) directly.
+#LDFLAGS_DIRECT_OpenBSD = _obsd
+#LDFLAGS_DIRECT_FreeBSD = _fbsd
+LDFLAGS_DIRECT_Linux = _linux
+LDFLAGS_DIRECT += -marmelf$(LDFLAGS_DIRECT_$(XEN_OS))_eabi
+
+CONFIG_LOAD_ADDRESS ?= 0x80000000
diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
new file mode 100644
index 0000000..fd86cb0
--- /dev/null
+++ b/xen/arch/arm/Makefile
@@ -0,0 +1,57 @@
+subdir-y += lib
+
+#obj-bin-y += ....o
+
+ALL_OBJS := $(ALL_OBJS)
+
+$(TARGET): $(TARGET)-syms
+	# XXX: VE model loads by VMA so instead of
+	# making a proper ELF we link with LMA == VMA and adjust crudely
+	$(OBJCOPY) --change-addresses +0x7fe00000 $< $@
+	# XXX strip it
+
+#$(TARGET): $(TARGET)-syms $(efi-y) boot/mkelf32
+#	./boot/mkelf32 $(TARGET)-syms $(TARGET) 0x100000 \
+#	`$(NM) -nr $(TARGET)-syms | head -n 1 | sed -e 's/^\([^ ]*\).*/0x\1/'`
+
+ifeq ($(lto),y)
+# Gather all LTO objects together
+prelink_lto.o: $(ALL_OBJS)
+	$(LD_LTO) -r -o $@ $^
+
+# Link it with all the binary objects
+prelink.o: $(patsubst %/built_in.o,%/built_in_bin.o,$(ALL_OBJS)) prelink_lto.o
+	$(LD) $(LDFLAGS) -r -o $@ $^
+else
+prelink.o: $(ALL_OBJS)
+	$(LD) $(LDFLAGS) -r -o $@ $^
+endif
+
+$(BASEDIR)/common/symbols-dummy.o:
+	$(MAKE) -f $(BASEDIR)/Rules.mk -C $(BASEDIR)/common symbols-dummy.o
+
+$(TARGET)-syms: prelink.o xen.lds $(BASEDIR)/common/symbols-dummy.o
+	$(LD) $(LDFLAGS) -T xen.lds -N prelink.o \
+	    $(BASEDIR)/common/symbols-dummy.o -o $(@D)/.$(@F).0
+	$(NM) -n $(@D)/.$(@F).0 | $(BASEDIR)/tools/symbols >$(@D)/.$(@F).0.S
+	$(MAKE) -f $(BASEDIR)/Rules.mk $(@D)/.$(@F).0.o
+	$(LD) $(LDFLAGS) -T xen.lds -N prelink.o \
+	    $(@D)/.$(@F).0.o -o $(@D)/.$(@F).1
+	$(NM) -n $(@D)/.$(@F).1 | $(BASEDIR)/tools/symbols >$(@D)/.$(@F).1.S
+	$(MAKE) -f $(BASEDIR)/Rules.mk $(@D)/.$(@F).1.o
+	$(LD) $(LDFLAGS) -T xen.lds -N prelink.o \
+	    $(@D)/.$(@F).1.o -o $@
+	rm -f $(@D)/.$(@F).[0-9]*
+
+asm-offsets.s: asm-offsets.c
+	$(CC) $(filter-out -flto,$(CFLAGS)) -S -o $@ $<
+
+xen.lds: xen.lds.S
+	$(CC) -P -E -Ui386 $(AFLAGS) -DXEN_PHYS_START=$(CONFIG_LOAD_ADDRESS) -o $@ $<
+	sed -e 's/xen\.lds\.o:/xen\.lds:/g' <.xen.lds.d >.xen.lds.d.new
+	mv -f .xen.lds.d.new .xen.lds.d
+
+.PHONY: clean
+clean::
+	rm -f asm-offsets.s xen.lds
+	rm -f $(BASEDIR)/.xen-syms.[0-9]*
diff --git a/xen/arch/arm/Rules.mk b/xen/arch/arm/Rules.mk
new file mode 100644
index 0000000..336e209
--- /dev/null
+++ b/xen/arch/arm/Rules.mk
@@ -0,0 +1,29 @@
+########################################
+# arm-specific definitions
+
+#
+# If you change any of these configuration options then you must
+# 'make clean' before rebuilding.
+#
+
+CFLAGS += -fno-builtin -fno-common -Wredundant-decls
+CFLAGS += -iwithprefix include -Werror -Wno-pointer-arith -pipe
+CFLAGS += -I$(BASEDIR)/include
+
+# Prevent floating-point variables from creeping into Xen.
+CFLAGS += -msoft-float
+
+$(call cc-options-add,CFLAGS,CC,$(EMBEDDED_EXTRA_CFLAGS))
+$(call cc-option-add,CFLAGS,CC,-Wnested-externs)
+
+arm := y
+
+ifneq ($(call cc-option,$(CC),-fvisibility=hidden,n),n)
+CFLAGS += -DGCC_HAS_VISIBILITY_ATTRIBUTE
+endif
+
+CFLAGS += -march=armv7-a -mcpu=cortex-a15
+
+# Require GCC v3.4+ (to avoid issues with alignment constraints in Xen headers)
+check-$(gcc) = $(call cc-ver-check,CC,0x030400,"Xen requires at least gcc-3.4")
+$(eval $(check-y))
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 18:20:37 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 18:20:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXzd1-0007xE-Il; Tue, 06 Dec 2011 18:20:31 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RXzcz-0007vS-IG
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 18:20:30 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1323195530!59687716!4
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDcxMjI=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2314 invoked from network); 6 Dec 2011 18:18:59 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Dec 2011 18:18:59 -0000
X-IronPort-AV: E=Sophos;i="4.71,307,1320642000"; d="scan'208";a="19721948"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Dec 2011 13:19:47 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Tue, 6 Dec 2011 13:19:47 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pB6IJEjP019549;
	Tue, 6 Dec 2011 10:19:35 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Tue, 6 Dec 2011 18:19:59 +0000
Message-ID: <1323195609-17277-15-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1112061753410.31179@kaball-desktop>
References: <alpine.DEB.2.00.1112061753410.31179@kaball-desktop>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>, Tim.Deegan@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH RFC 15/25] arm: driver for CoreLink GIC-400
	Generic Interrupt Controller
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

- GICC, GICD and GICH initialization;

- interrupts routing, acking and EOI;

- interrupt injection into guests;

- maintenance interrupt handler, that takes care of EOI physical
  interrupts on behalf of the guest;

- a function to remap the virtual cpu interface into the guest address
  space, where the guest expect the GICC to be.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
---
 xen/arch/arm/Makefile |    1 +
 xen/arch/arm/domain.c |    2 +
 xen/arch/arm/gic.c    |  473 +++++++++++++++++++++++++++++++++++++++++++++++++
 xen/arch/arm/gic.h    |  151 ++++++++++++++++
 4 files changed, 627 insertions(+), 0 deletions(-)
 create mode 100644 xen/arch/arm/gic.c
 create mode 100644 xen/arch/arm/gic.h

diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index 28faa73..cd196c3 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -4,6 +4,7 @@ obj-y += dummy.o
 obj-y += entry.o
 obj-y += domain.o
 obj-y += domain_build.o
+obj-y += gic.o
 
 #obj-bin-y += ....o
 
diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index d706b5f..ecbc5b7 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -11,6 +11,8 @@
 #include <asm/p2m.h>
 #include <asm/irq.h>
 
+#include "gic.h"
+
 DEFINE_PER_CPU(struct vcpu *, curr_vcpu);
 
 static void continue_idle_domain(struct vcpu *v)
diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
new file mode 100644
index 0000000..9643a7d
--- /dev/null
+++ b/xen/arch/arm/gic.c
@@ -0,0 +1,473 @@
+/*
+ * xen/arch/arm/gic.c
+ *
+ * ARM Generic Interrupt Controller support
+ *
+ * Tim Deegan <tim@xen.org>
+ * Copyright (c) 2011 Citrix Systems.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include <xen/config.h>
+#include <xen/lib.h>
+#include <xen/init.h>
+#include <xen/mm.h>
+#include <xen/irq.h>
+#include <xen/sched.h>
+#include <xen/errno.h>
+#include <xen/softirq.h>
+#include <asm/p2m.h>
+#include <asm/domain.h>
+
+#include "gic.h"
+
+/* Access to the GIC Distributor registers through the fixmap */
+#define GICD ((volatile uint32_t *) FIXMAP_ADDR(FIXMAP_GICD))
+#define GICC ((volatile uint32_t *) (FIXMAP_ADDR(FIXMAP_GICC1)  \
+                                     + (GIC_CR_OFFSET & 0xfff)))
+#define GICH ((volatile uint32_t *) (FIXMAP_ADDR(FIXMAP_GICH)  \
+                                     + (GIC_HR_OFFSET & 0xfff)))
+
+/* Global state */
+static struct {
+    paddr_t dbase;       /* Address of distributor registers */
+    paddr_t cbase;       /* Address of CPU interface registers */
+    paddr_t hbase;       /* Address of virtual interface registers */
+    unsigned int lines;
+    unsigned int cpus;
+    spinlock_t lock;
+} gic;
+
+irq_desc_t irq_desc[NR_IRQS];
+unsigned nr_lrs;
+
+static unsigned int gic_irq_startup(struct irq_desc *desc)
+{
+    uint32_t enabler;
+	int irq = desc->irq;
+
+    /* Enable routing */
+    enabler = GICD[GICD_ISENABLER + irq / 32];
+    GICD[GICD_ISENABLER + irq / 32] = enabler | (1u << (irq % 32));
+
+    return 0;
+}
+
+static void gic_irq_shutdown(struct irq_desc *desc)
+{
+    uint32_t enabler;
+	int irq = desc->irq;
+
+    /* Disable routing */
+    enabler = GICD[GICD_ICENABLER + irq / 32];
+    GICD[GICD_ICENABLER + irq / 32] = enabler | (1u << (irq % 32));
+}
+
+static void gic_irq_enable(struct irq_desc *desc)
+{
+
+}
+
+static void gic_irq_disable(struct irq_desc *desc)
+{
+
+}
+
+static void gic_irq_ack(struct irq_desc *desc)
+{
+    /* No ACK -- reading IAR has done this for us */
+}
+
+static void gic_host_irq_end(struct irq_desc *desc)
+{
+	int irq = desc->irq;
+    /* Lower the priority */
+    GICC[GICC_EOIR] = irq;
+    /* Deactivate */
+    GICC[GICC_DIR] = irq;
+}
+
+static void gic_guest_irq_end(struct irq_desc *desc)
+{
+	int irq = desc->irq;
+    /* Lower the priority of the IRQ */
+    GICC[GICC_EOIR] = irq;
+    /* Deactivation happens in maintenance interrupt / via GICV */
+}
+
+static void gic_irq_set_affinity(struct irq_desc *desc, const cpumask_t *mask)
+{
+    BUG();
+}
+
+/* XXX different for level vs edge */
+static hw_irq_controller gic_host_irq_type = {
+    .typename = "gic",
+    .startup = gic_irq_startup,
+    .shutdown = gic_irq_shutdown,
+    .enable = gic_irq_enable,
+    .disable = gic_irq_disable,
+    .ack = gic_irq_ack,
+    .end = gic_host_irq_end,
+    .set_affinity = gic_irq_set_affinity,
+};
+static hw_irq_controller gic_guest_irq_type = {
+    .typename = "gic",
+    .startup = gic_irq_startup,
+    .shutdown = gic_irq_shutdown,
+    .enable = gic_irq_enable,
+    .disable = gic_irq_disable,
+    .ack = gic_irq_ack,
+    .end = gic_guest_irq_end,
+    .set_affinity = gic_irq_set_affinity,
+};
+
+/* Program the GIC to route an interrupt */
+static int gic_route_irq(unsigned int irq, bool_t level,
+                         unsigned int cpu_mask, unsigned int priority)
+{
+    volatile unsigned char *bytereg;
+    uint32_t cfg, edgebit;
+    struct irq_desc *desc = irq_to_desc(irq);
+    unsigned long flags;
+
+    ASSERT(!(cpu_mask & ~0xff));  /* Targets bitmap only supports 8 CPUs */
+    ASSERT(priority <= 0xff);     /* Only 8 bits of priority */
+    ASSERT(irq < gic.lines + 32); /* Can't route interrupts that don't exist */
+
+    spin_lock_irqsave(&desc->lock, flags);
+    spin_lock(&gic.lock);
+
+    if ( desc->action != NULL )
+    {
+        spin_unlock(&desc->lock);
+        return -EBUSY;
+    }
+
+    desc->handler = &gic_host_irq_type;
+
+    /* Disable interrupt */
+    desc->handler->shutdown(desc);
+
+    /* Set edge / level */
+    cfg = GICD[GICD_ICFGR + irq / 16];
+    edgebit = 2u << (2 * (irq % 16));
+    if ( level )
+        cfg &= ~edgebit;
+    else
+        cfg |= edgebit;
+    GICD[GICD_ICFGR + irq / 16] = cfg;
+
+    /* Set target CPU mask (RAZ/WI on uniprocessor) */
+    bytereg = (unsigned char *) (GICD + GICD_ITARGETSR);
+    bytereg[irq] = cpu_mask;
+
+    /* Set priority */
+    bytereg = (unsigned char *) (GICD + GICD_IPRIORITYR);
+    bytereg[irq] = priority;
+
+    spin_unlock(&gic.lock);
+    spin_unlock_irqrestore(&desc->lock, flags);
+    return 0;
+}
+
+static void __init gic_dist_init(void)
+{
+    uint32_t type;
+    uint32_t cpumask = 1 << smp_processor_id();
+    int i;
+
+    cpumask |= cpumask << 8;
+    cpumask |= cpumask << 16;
+
+    /* Disable the distributor */
+    GICD[GICD_CTLR] = 0;
+
+    type = GICD[GICD_TYPER];
+    gic.lines = 32 * (type & GICD_TYPE_LINES);
+    gic.cpus = 1 + ((type & GICD_TYPE_CPUS) >> 5);
+    printk("GIC: %d lines, %d cpu%s%s (IID %8.8x).\n",
+           gic.lines, gic.cpus, (gic.cpus == 1) ? "" : "s",
+           (type & GICD_TYPE_SEC) ? ", secure" : "",
+           GICD[GICD_IIDR]);
+
+    /* Default all global IRQs to level, active low */
+    for ( i = 32; i < gic.lines; i += 16 )
+        GICD[GICD_ICFGR + i / 16] = 0x0;
+
+    /* Route all global IRQs to this CPU */
+    for ( i = 32; i < gic.lines; i += 4 )
+        GICD[GICD_ICFGR + i / 4] = cpumask;
+
+    /* Default priority for global interrupts */
+    for ( i = 32; i < gic.lines; i += 4 )
+        GICD[GICD_IPRIORITYR + i / 4] = 0xa0a0a0a0;
+
+    /* Disable all global interrupts */
+    for ( i = 32; i < gic.lines; i += 32 )
+        GICD[GICD_ICENABLER + i / 32] = ~0ul;
+
+    /* Turn on the distributor */
+    GICD[GICD_CTLR] = GICD_CTL_ENABLE;
+}
+
+static void __cpuinit gic_cpu_init(void)
+{
+    int i;
+
+    /* Disable all PPI and enable all SGI */
+    GICD[GICD_ICENABLER] = 0xffff0000; /* Disable all PPI */
+    GICD[GICD_ISENABLER] = 0x0000ffff; /* Enable all SGI */
+    /* Set PPI and SGI priorities */
+    for (i = 0; i < 32; i += 4)
+        GICD[GICD_IPRIORITYR + i / 4] = 0xa0a0a0a0;
+
+    /* Local settings: interface controller */
+    GICC[GICC_PMR] = 0xff;                /* Don't mask by priority */
+    GICC[GICC_BPR] = 0;                   /* Finest granularity of priority */
+    GICC[GICC_CTLR] = GICC_CTL_ENABLE|GICC_CTL_EOI;    /* Turn on delivery */
+}
+
+static void __cpuinit gic_hyp_init(void)
+{
+    uint32_t vtr;
+
+    vtr = GICH[GICH_VTR];
+    nr_lrs  = (vtr & GICH_VTR_NRLRGS) + 1;
+    printk("GICH: %d list registers available\n", nr_lrs);
+
+    GICH[GICH_HCR] = GICH_HCR_EN;
+    GICH[GICH_MISR] = GICH_MISR_EOI;
+}
+
+/* Set up the GIC */
+void gic_init(void)
+{
+    /* XXX FIXME get this from devicetree */
+    gic.dbase = GIC_BASE_ADDRESS + GIC_DR_OFFSET;
+    gic.cbase = GIC_BASE_ADDRESS + GIC_CR_OFFSET;
+    gic.hbase = GIC_BASE_ADDRESS + GIC_HR_OFFSET;
+    set_fixmap(FIXMAP_GICD, gic.dbase >> PAGE_SHIFT, DEV_SHARED);
+    BUILD_BUG_ON(FIXMAP_ADDR(FIXMAP_GICC1) !=
+                 FIXMAP_ADDR(FIXMAP_GICC2)-PAGE_SIZE);
+    set_fixmap(FIXMAP_GICC1, gic.cbase >> PAGE_SHIFT, DEV_SHARED);
+    set_fixmap(FIXMAP_GICC2, (gic.cbase >> PAGE_SHIFT) + 1, DEV_SHARED);
+    set_fixmap(FIXMAP_GICH, gic.hbase >> PAGE_SHIFT, DEV_SHARED);
+
+    /* Global settings: interrupt distributor */
+    spin_lock_init(&gic.lock);
+    spin_lock(&gic.lock);
+
+    gic_dist_init();
+    gic_cpu_init();
+    gic_hyp_init();
+
+    spin_unlock(&gic.lock);
+}
+
+void gic_route_irqs(void)
+{
+    /* XXX should get these from DT */
+    /* GIC maintenance */
+    gic_route_irq(25, 1, 1u << smp_processor_id(), 0xa0);
+    /* Hypervisor Timer */
+    gic_route_irq(26, 1, 1u << smp_processor_id(), 0xa0);
+    /* Timer */
+    gic_route_irq(30, 1, 1u << smp_processor_id(), 0xa0);
+    /* UART */
+    gic_route_irq(37, 0, 1u << smp_processor_id(), 0xa0);
+}
+
+void __init release_irq(unsigned int irq)
+{
+    struct irq_desc *desc;
+    unsigned long flags;
+   struct irqaction *action;
+
+    desc = irq_to_desc(irq);
+
+    spin_lock_irqsave(&desc->lock,flags);
+    action = desc->action;
+    desc->action  = NULL;
+    desc->status |= IRQ_DISABLED;
+
+    spin_lock(&gic.lock);
+    desc->handler->shutdown(desc);
+    spin_unlock(&gic.lock);
+
+    spin_unlock_irqrestore(&desc->lock,flags);
+
+    /* Wait to make sure it's not being used on another CPU */
+    do { smp_mb(); } while ( desc->status & IRQ_INPROGRESS );
+
+    if (action && action->free_on_release)
+        xfree(action);
+}
+
+static int __setup_irq(struct irq_desc *desc, unsigned int irq,
+                       struct irqaction *new)
+{
+    if ( desc->action != NULL )
+        return -EBUSY;
+
+    desc->action  = new;
+    desc->status &= ~IRQ_DISABLED;
+    dsb();
+
+    desc->handler->startup(desc);
+
+    return 0;
+}
+
+int __init setup_irq(unsigned int irq, struct irqaction *new)
+{
+    int rc;
+    unsigned long flags;
+    struct irq_desc *desc;
+
+    desc = irq_to_desc(irq);
+
+    spin_lock_irqsave(&desc->lock, flags);
+
+    rc = __setup_irq(desc, irq, new);
+
+    spin_unlock_irqrestore(&desc->lock,flags);
+
+    return rc;
+}
+
+void gic_set_guest_irq(unsigned int virtual_irq,
+        unsigned int state, unsigned int priority)
+{
+    BUG_ON(virtual_irq > nr_lrs);
+    GICH[GICH_LR + virtual_irq] = state |
+        GICH_LR_MAINTENANCE_IRQ |
+        ((priority >> 3) << GICH_LR_PRIORITY_SHIFT) |
+        ((virtual_irq & GICH_LR_VIRTUAL_MASK) << GICH_LR_VIRTUAL_SHIFT);
+}
+
+void gic_inject_irq_start(void)
+{
+    uint32_t hcr;
+    hcr = READ_CP32(HCR);
+    WRITE_CP32(hcr | HCR_VI, HCR);
+    isb();
+}
+
+void gic_inject_irq_stop(void)
+{
+    uint32_t hcr;
+    hcr = READ_CP32(HCR);
+    if (hcr & HCR_VI) {
+        WRITE_CP32(hcr & ~HCR_VI, HCR);
+        isb();
+    }
+}
+
+int gic_route_irq_to_guest(struct domain *d, unsigned int irq,
+                           const char * devname)
+{
+    struct irqaction *action;
+    struct irq_desc *desc = irq_to_desc(irq);
+    unsigned long flags;
+    int retval;
+
+    action = xmalloc(struct irqaction);
+    if (!action)
+        return -ENOMEM;
+
+    action->dev_id = d;
+    action->name = devname;
+
+    spin_lock_irqsave(&desc->lock, flags);
+
+    desc->handler = &gic_guest_irq_type;
+    desc->status |= IRQ_GUEST;
+
+    retval = __setup_irq(desc, irq, action);
+    if (retval) {
+        xfree(action);
+        goto out;
+    }
+
+out:
+    spin_unlock_irqrestore(&desc->lock, flags);
+    return retval;
+}
+
+/* Accept an interrupt from the GIC and dispatch its handler */
+void gic_interrupt(struct cpu_user_regs *regs, int is_fiq)
+{
+    uint32_t intack = GICC[GICC_IAR];
+    unsigned int irq = intack & GICC_IA_IRQ;
+
+    if ( irq == 1023 )
+        /* Spurious interrupt */
+        return;
+
+    do_IRQ(regs, irq, is_fiq);
+}
+
+void gicv_setup(struct domain *d)
+{
+    /* map the gic virtual cpu interface in the gic cpu interface region of
+     * the guest */
+    printk("mapping GICC at %#"PRIx32" to %#"PRIx32"\n",
+           GIC_BASE_ADDRESS + GIC_CR_OFFSET,
+           GIC_BASE_ADDRESS + GIC_VR_OFFSET);
+    map_mmio_regions(d, GIC_BASE_ADDRESS + GIC_CR_OFFSET,
+                        GIC_BASE_ADDRESS + GIC_CR_OFFSET + (2 * PAGE_SIZE) - 1,
+                        GIC_BASE_ADDRESS + GIC_VR_OFFSET);
+}
+
+static void maintenance_interrupt(int irq, void *dev_id, struct cpu_user_regs *regs)
+{
+    int i, virq;
+    uint32_t lr;
+    uint64_t eisr = GICH[GICH_EISR0] | (((uint64_t) GICH[GICH_EISR1]) << 32);
+
+    for ( i = 0; i < 64; i++ ) {
+        if ( eisr & ((uint64_t)1 << i) ) {
+            struct pending_irq *p;
+
+            lr = GICH[GICH_LR + i];
+            virq = lr & GICH_LR_VIRTUAL_MASK;
+            GICH[GICH_LR + i] = 0;
+
+            spin_lock(&current->arch.vgic.lock);
+            p = irq_to_pending(current, virq);
+            if ( p->desc != NULL ) {
+                p->desc->status &= ~IRQ_INPROGRESS;
+                GICC[GICC_DIR] = virq;
+            }
+            gic_inject_irq_stop();
+            list_del(&p->link);
+            INIT_LIST_HEAD(&p->link);
+            cpu_raise_softirq(current->processor, VGIC_SOFTIRQ);
+            spin_unlock(&current->arch.vgic.lock);
+        }
+    }
+}
+
+void __cpuinit init_maintenance_interrupt(void)
+{
+    request_irq(25, maintenance_interrupt, 0, "irq-maintenance", NULL);
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/arch/arm/gic.h b/xen/arch/arm/gic.h
new file mode 100644
index 0000000..63b6648
--- /dev/null
+++ b/xen/arch/arm/gic.h
@@ -0,0 +1,151 @@
+/*
+ * xen/arch/arm/gic.h
+ *
+ * ARM Generic Interrupt Controller support
+ *
+ * Tim Deegan <tim@xen.org>
+ * Copyright (c) 2011 Citrix Systems.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#ifndef __ARCH_ARM_GIC_H__
+#define __ARCH_ARM_GIC_H__
+
+#define GICD_CTLR       (0x000/4)
+#define GICD_TYPER      (0x004/4)
+#define GICD_IIDR       (0x008/4)
+#define GICD_IGROUPR    (0x080/4)
+#define GICD_IGROUPRN   (0x0FC/4)
+#define GICD_ISENABLER  (0x100/4)
+#define GICD_ISENABLERN (0x17C/4)
+#define GICD_ICENABLER  (0x180/4)
+#define GICD_ICENABLERN (0x1fC/4)
+#define GICD_ISPENDR    (0x200/4)
+#define GICD_ISPENDRN   (0x27C/4)
+#define GICD_ICPENDR    (0x280/4)
+#define GICD_ICPENDRN   (0x2FC/4)
+#define GICD_ISACTIVER  (0x300/4)
+#define GICD_ISACTIVERN (0x37C/4)
+#define GICD_ICACTIVER  (0x380/4)
+#define GICD_ICACTIVERN (0x3FC/4)
+#define GICD_IPRIORITYR (0x400/4)
+#define GICD_IPRIORITYRN (0x7F8/4)
+#define GICD_ITARGETSR  (0x800/4)
+#define GICD_ITARGETSRN (0xBF8/4)
+#define GICD_ICFGR      (0xC00/4)
+#define GICD_ICFGRN     (0xCFC/4)
+#define GICD_NSACR      (0xE00/4)
+#define GICD_NSACRN     (0xEFC/4)
+#define GICD_ICPIDR2    (0xFE8/4)
+#define GICD_SGIR       (0xF00/4)
+#define GICD_CPENDSGIR  (0xF10/4)
+#define GICD_CPENDSGIRN (0xF1C/4)
+#define GICD_SPENDSGIR  (0xF20/4)
+#define GICD_SPENDSGIRN (0xF2C/4)
+#define GICD_ICPIDR2    (0xFE8/4)
+
+#define GICC_CTLR       (0x0000/4)
+#define GICC_PMR        (0x0004/4)
+#define GICC_BPR        (0x0008/4)
+#define GICC_IAR        (0x000C/4)
+#define GICC_EOIR       (0x0010/4)
+#define GICC_RPR        (0x0014/4)
+#define GICC_HPPIR      (0x0018/4)
+#define GICC_APR        (0x00D0/4)
+#define GICC_NSAPR      (0x00E0/4)
+#define GICC_DIR        (0x1000/4)
+
+#define GICH_HCR        (0x00/4)
+#define GICH_VTR        (0x04/4)
+#define GICH_VMCR       (0x08/4)
+#define GICH_MISR       (0x10/4)
+#define GICH_EISR0      (0x20/4)
+#define GICH_EISR1      (0x24/4)
+#define GICH_ELRSR0     (0x30/4)
+#define GICH_ELRSR1     (0x34/4)
+#define GICH_APR        (0xF0/4)
+#define GICH_LR         (0x100/4)
+
+/* Register bits */
+#define GICD_CTL_ENABLE 0x1
+
+#define GICD_TYPE_LINES 0x01f
+#define GICD_TYPE_CPUS  0x0e0
+#define GICD_TYPE_SEC   0x400
+
+#define GICC_CTL_ENABLE 0x1
+#define GICC_CTL_EOI    (0x1 << 9)
+
+#define GICC_IA_IRQ     0x03ff
+#define GICC_IA_CPU     0x1c00
+
+#define GICH_HCR_EN       (1 << 0)
+#define GICH_HCR_UIE      (1 << 1)
+#define GICH_HCR_LRENPIE  (1 << 2)
+#define GICH_HCR_NPIE     (1 << 3)
+#define GICH_HCR_VGRP0EIE (1 << 4)
+#define GICH_HCR_VGRP0DIE (1 << 5)
+#define GICH_HCR_VGRP1EIE (1 << 6)
+#define GICH_HCR_VGRP1DIE (1 << 7)
+
+#define GICH_MISR_EOI     (1 << 0)
+#define GICH_MISR_U       (1 << 1)
+#define GICH_MISR_LRENP   (1 << 2)
+#define GICH_MISR_NP      (1 << 3)
+#define GICH_MISR_VGRP0E  (1 << 4)
+#define GICH_MISR_VGRP0D  (1 << 5)
+#define GICH_MISR_VGRP1E  (1 << 6)
+#define GICH_MISR_VGRP1D  (1 << 7)
+
+#define GICH_LR_VIRTUAL_MASK    0x3ff
+#define GICH_LR_VIRTUAL_SHIFT   0
+#define GICH_LR_PHYSICAL_MASK   0x3ff
+#define GICH_LR_PHYSICAL_SHIFT  10
+#define GICH_LR_STATE_MASK      0x3
+#define GICH_LR_STATE_SHIFT     28
+#define GICH_LR_PRIORITY_SHIFT  23
+#define GICH_LR_MAINTENANCE_IRQ (1<<19)
+#define GICH_LR_PENDING         (1<<28)
+#define GICH_LR_ACTIVE          (1<<29)
+#define GICH_LR_GRP1            (1<<30)
+#define GICH_LR_HW              (1<<31)
+#define GICH_LR_CPUID_SHIFT     9
+#define GICH_VTR_NRLRGS         0x3f
+
+extern struct pending_irq *irq_to_pending(struct vcpu *v, unsigned int irq);
+
+extern void gic_route_irqs(void);
+
+extern void __cpuinit init_maintenance_interrupt(void);
+extern void gic_set_guest_irq(unsigned int irq,
+        unsigned int state, unsigned int priority);
+extern void gic_inject_irq_start(void);
+extern void gic_inject_irq_stop(void);
+extern int gic_route_irq_to_guest(struct domain *d, unsigned int irq,
+                                  const char * devname);
+
+/* Accept an interrupt from the GIC and dispatch its handler */
+extern void gic_interrupt(struct cpu_user_regs *regs, int is_fiq);
+/* Bring up the interrupt controller */
+extern void gic_init(void);
+/* setup the gic virtual interface for a guest */
+extern void gicv_setup(struct domain *d);
+#endif
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 18:20:37 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 18:20:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXzcv-0007u1-V1; Tue, 06 Dec 2011 18:20:25 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RXzct-0007t7-Ul
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 18:20:24 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1323195545!51363948!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMzAwOTc=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4001 invoked from network); 6 Dec 2011 18:19:10 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Dec 2011 18:19:10 -0000
X-IronPort-AV: E=Sophos;i="4.71,307,1320642000"; d="scan'208";a="173120739"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Dec 2011 13:19:42 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Tue, 6 Dec 2011 13:19:42 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pB6IJEjI019549;
	Tue, 6 Dec 2011 10:19:25 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Tue, 6 Dec 2011 18:19:52 +0000
Message-ID: <1323195609-17277-8-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1112061753410.31179@kaball-desktop>
References: <alpine.DEB.2.00.1112061753410.31179@kaball-desktop>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>, Tim.Deegan@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH RFC 08/25] arm: makefiles
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Makefile and config options for the ARM architecture.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
---
 config/arm.mk         |   18 +++++++++++++++
 xen/arch/arm/Makefile |   57 +++++++++++++++++++++++++++++++++++++++++++++++++
 xen/arch/arm/Rules.mk |   29 +++++++++++++++++++++++++
 3 files changed, 104 insertions(+), 0 deletions(-)
 create mode 100644 config/arm.mk
 create mode 100644 xen/arch/arm/Makefile
 create mode 100644 xen/arch/arm/Rules.mk

diff --git a/config/arm.mk b/config/arm.mk
new file mode 100644
index 0000000..f64f0c1
--- /dev/null
+++ b/config/arm.mk
@@ -0,0 +1,18 @@
+CONFIG_ARM := y
+CONFIG_ARM_32 := y
+CONFIG_ARM_$(XEN_OS) := y
+
+# -march= -mcpu=
+
+# Explicitly specifiy 32-bit ARM ISA since toolchain default can be -mthumb:
+CFLAGS += -marm
+
+HAS_PL011 := y
+
+# Use only if calling $(LD) directly.
+#LDFLAGS_DIRECT_OpenBSD = _obsd
+#LDFLAGS_DIRECT_FreeBSD = _fbsd
+LDFLAGS_DIRECT_Linux = _linux
+LDFLAGS_DIRECT += -marmelf$(LDFLAGS_DIRECT_$(XEN_OS))_eabi
+
+CONFIG_LOAD_ADDRESS ?= 0x80000000
diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
new file mode 100644
index 0000000..fd86cb0
--- /dev/null
+++ b/xen/arch/arm/Makefile
@@ -0,0 +1,57 @@
+subdir-y += lib
+
+#obj-bin-y += ....o
+
+ALL_OBJS := $(ALL_OBJS)
+
+$(TARGET): $(TARGET)-syms
+	# XXX: VE model loads by VMA so instead of
+	# making a proper ELF we link with LMA == VMA and adjust crudely
+	$(OBJCOPY) --change-addresses +0x7fe00000 $< $@
+	# XXX strip it
+
+#$(TARGET): $(TARGET)-syms $(efi-y) boot/mkelf32
+#	./boot/mkelf32 $(TARGET)-syms $(TARGET) 0x100000 \
+#	`$(NM) -nr $(TARGET)-syms | head -n 1 | sed -e 's/^\([^ ]*\).*/0x\1/'`
+
+ifeq ($(lto),y)
+# Gather all LTO objects together
+prelink_lto.o: $(ALL_OBJS)
+	$(LD_LTO) -r -o $@ $^
+
+# Link it with all the binary objects
+prelink.o: $(patsubst %/built_in.o,%/built_in_bin.o,$(ALL_OBJS)) prelink_lto.o
+	$(LD) $(LDFLAGS) -r -o $@ $^
+else
+prelink.o: $(ALL_OBJS)
+	$(LD) $(LDFLAGS) -r -o $@ $^
+endif
+
+$(BASEDIR)/common/symbols-dummy.o:
+	$(MAKE) -f $(BASEDIR)/Rules.mk -C $(BASEDIR)/common symbols-dummy.o
+
+$(TARGET)-syms: prelink.o xen.lds $(BASEDIR)/common/symbols-dummy.o
+	$(LD) $(LDFLAGS) -T xen.lds -N prelink.o \
+	    $(BASEDIR)/common/symbols-dummy.o -o $(@D)/.$(@F).0
+	$(NM) -n $(@D)/.$(@F).0 | $(BASEDIR)/tools/symbols >$(@D)/.$(@F).0.S
+	$(MAKE) -f $(BASEDIR)/Rules.mk $(@D)/.$(@F).0.o
+	$(LD) $(LDFLAGS) -T xen.lds -N prelink.o \
+	    $(@D)/.$(@F).0.o -o $(@D)/.$(@F).1
+	$(NM) -n $(@D)/.$(@F).1 | $(BASEDIR)/tools/symbols >$(@D)/.$(@F).1.S
+	$(MAKE) -f $(BASEDIR)/Rules.mk $(@D)/.$(@F).1.o
+	$(LD) $(LDFLAGS) -T xen.lds -N prelink.o \
+	    $(@D)/.$(@F).1.o -o $@
+	rm -f $(@D)/.$(@F).[0-9]*
+
+asm-offsets.s: asm-offsets.c
+	$(CC) $(filter-out -flto,$(CFLAGS)) -S -o $@ $<
+
+xen.lds: xen.lds.S
+	$(CC) -P -E -Ui386 $(AFLAGS) -DXEN_PHYS_START=$(CONFIG_LOAD_ADDRESS) -o $@ $<
+	sed -e 's/xen\.lds\.o:/xen\.lds:/g' <.xen.lds.d >.xen.lds.d.new
+	mv -f .xen.lds.d.new .xen.lds.d
+
+.PHONY: clean
+clean::
+	rm -f asm-offsets.s xen.lds
+	rm -f $(BASEDIR)/.xen-syms.[0-9]*
diff --git a/xen/arch/arm/Rules.mk b/xen/arch/arm/Rules.mk
new file mode 100644
index 0000000..336e209
--- /dev/null
+++ b/xen/arch/arm/Rules.mk
@@ -0,0 +1,29 @@
+########################################
+# arm-specific definitions
+
+#
+# If you change any of these configuration options then you must
+# 'make clean' before rebuilding.
+#
+
+CFLAGS += -fno-builtin -fno-common -Wredundant-decls
+CFLAGS += -iwithprefix include -Werror -Wno-pointer-arith -pipe
+CFLAGS += -I$(BASEDIR)/include
+
+# Prevent floating-point variables from creeping into Xen.
+CFLAGS += -msoft-float
+
+$(call cc-options-add,CFLAGS,CC,$(EMBEDDED_EXTRA_CFLAGS))
+$(call cc-option-add,CFLAGS,CC,-Wnested-externs)
+
+arm := y
+
+ifneq ($(call cc-option,$(CC),-fvisibility=hidden,n),n)
+CFLAGS += -DGCC_HAS_VISIBILITY_ATTRIBUTE
+endif
+
+CFLAGS += -march=armv7-a -mcpu=cortex-a15
+
+# Require GCC v3.4+ (to avoid issues with alignment constraints in Xen headers)
+check-$(gcc) = $(call cc-ver-check,CC,0x030400,"Xen requires at least gcc-3.4")
+$(eval $(check-y))
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 18:20:37 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 18:20:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXzd1-0007xE-Il; Tue, 06 Dec 2011 18:20:31 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RXzcz-0007vS-IG
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 18:20:30 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1323195530!59687716!4
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDcxMjI=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2314 invoked from network); 6 Dec 2011 18:18:59 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Dec 2011 18:18:59 -0000
X-IronPort-AV: E=Sophos;i="4.71,307,1320642000"; d="scan'208";a="19721948"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Dec 2011 13:19:47 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Tue, 6 Dec 2011 13:19:47 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pB6IJEjP019549;
	Tue, 6 Dec 2011 10:19:35 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Tue, 6 Dec 2011 18:19:59 +0000
Message-ID: <1323195609-17277-15-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1112061753410.31179@kaball-desktop>
References: <alpine.DEB.2.00.1112061753410.31179@kaball-desktop>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>, Tim.Deegan@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH RFC 15/25] arm: driver for CoreLink GIC-400
	Generic Interrupt Controller
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

- GICC, GICD and GICH initialization;

- interrupts routing, acking and EOI;

- interrupt injection into guests;

- maintenance interrupt handler, that takes care of EOI physical
  interrupts on behalf of the guest;

- a function to remap the virtual cpu interface into the guest address
  space, where the guest expect the GICC to be.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
---
 xen/arch/arm/Makefile |    1 +
 xen/arch/arm/domain.c |    2 +
 xen/arch/arm/gic.c    |  473 +++++++++++++++++++++++++++++++++++++++++++++++++
 xen/arch/arm/gic.h    |  151 ++++++++++++++++
 4 files changed, 627 insertions(+), 0 deletions(-)
 create mode 100644 xen/arch/arm/gic.c
 create mode 100644 xen/arch/arm/gic.h

diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index 28faa73..cd196c3 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -4,6 +4,7 @@ obj-y += dummy.o
 obj-y += entry.o
 obj-y += domain.o
 obj-y += domain_build.o
+obj-y += gic.o
 
 #obj-bin-y += ....o
 
diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index d706b5f..ecbc5b7 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -11,6 +11,8 @@
 #include <asm/p2m.h>
 #include <asm/irq.h>
 
+#include "gic.h"
+
 DEFINE_PER_CPU(struct vcpu *, curr_vcpu);
 
 static void continue_idle_domain(struct vcpu *v)
diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
new file mode 100644
index 0000000..9643a7d
--- /dev/null
+++ b/xen/arch/arm/gic.c
@@ -0,0 +1,473 @@
+/*
+ * xen/arch/arm/gic.c
+ *
+ * ARM Generic Interrupt Controller support
+ *
+ * Tim Deegan <tim@xen.org>
+ * Copyright (c) 2011 Citrix Systems.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include <xen/config.h>
+#include <xen/lib.h>
+#include <xen/init.h>
+#include <xen/mm.h>
+#include <xen/irq.h>
+#include <xen/sched.h>
+#include <xen/errno.h>
+#include <xen/softirq.h>
+#include <asm/p2m.h>
+#include <asm/domain.h>
+
+#include "gic.h"
+
+/* Access to the GIC Distributor registers through the fixmap */
+#define GICD ((volatile uint32_t *) FIXMAP_ADDR(FIXMAP_GICD))
+#define GICC ((volatile uint32_t *) (FIXMAP_ADDR(FIXMAP_GICC1)  \
+                                     + (GIC_CR_OFFSET & 0xfff)))
+#define GICH ((volatile uint32_t *) (FIXMAP_ADDR(FIXMAP_GICH)  \
+                                     + (GIC_HR_OFFSET & 0xfff)))
+
+/* Global state */
+static struct {
+    paddr_t dbase;       /* Address of distributor registers */
+    paddr_t cbase;       /* Address of CPU interface registers */
+    paddr_t hbase;       /* Address of virtual interface registers */
+    unsigned int lines;
+    unsigned int cpus;
+    spinlock_t lock;
+} gic;
+
+irq_desc_t irq_desc[NR_IRQS];
+unsigned nr_lrs;
+
+static unsigned int gic_irq_startup(struct irq_desc *desc)
+{
+    uint32_t enabler;
+	int irq = desc->irq;
+
+    /* Enable routing */
+    enabler = GICD[GICD_ISENABLER + irq / 32];
+    GICD[GICD_ISENABLER + irq / 32] = enabler | (1u << (irq % 32));
+
+    return 0;
+}
+
+static void gic_irq_shutdown(struct irq_desc *desc)
+{
+    uint32_t enabler;
+	int irq = desc->irq;
+
+    /* Disable routing */
+    enabler = GICD[GICD_ICENABLER + irq / 32];
+    GICD[GICD_ICENABLER + irq / 32] = enabler | (1u << (irq % 32));
+}
+
+static void gic_irq_enable(struct irq_desc *desc)
+{
+
+}
+
+static void gic_irq_disable(struct irq_desc *desc)
+{
+
+}
+
+static void gic_irq_ack(struct irq_desc *desc)
+{
+    /* No ACK -- reading IAR has done this for us */
+}
+
+static void gic_host_irq_end(struct irq_desc *desc)
+{
+	int irq = desc->irq;
+    /* Lower the priority */
+    GICC[GICC_EOIR] = irq;
+    /* Deactivate */
+    GICC[GICC_DIR] = irq;
+}
+
+static void gic_guest_irq_end(struct irq_desc *desc)
+{
+	int irq = desc->irq;
+    /* Lower the priority of the IRQ */
+    GICC[GICC_EOIR] = irq;
+    /* Deactivation happens in maintenance interrupt / via GICV */
+}
+
+static void gic_irq_set_affinity(struct irq_desc *desc, const cpumask_t *mask)
+{
+    BUG();
+}
+
+/* XXX different for level vs edge */
+static hw_irq_controller gic_host_irq_type = {
+    .typename = "gic",
+    .startup = gic_irq_startup,
+    .shutdown = gic_irq_shutdown,
+    .enable = gic_irq_enable,
+    .disable = gic_irq_disable,
+    .ack = gic_irq_ack,
+    .end = gic_host_irq_end,
+    .set_affinity = gic_irq_set_affinity,
+};
+static hw_irq_controller gic_guest_irq_type = {
+    .typename = "gic",
+    .startup = gic_irq_startup,
+    .shutdown = gic_irq_shutdown,
+    .enable = gic_irq_enable,
+    .disable = gic_irq_disable,
+    .ack = gic_irq_ack,
+    .end = gic_guest_irq_end,
+    .set_affinity = gic_irq_set_affinity,
+};
+
+/* Program the GIC to route an interrupt */
+static int gic_route_irq(unsigned int irq, bool_t level,
+                         unsigned int cpu_mask, unsigned int priority)
+{
+    volatile unsigned char *bytereg;
+    uint32_t cfg, edgebit;
+    struct irq_desc *desc = irq_to_desc(irq);
+    unsigned long flags;
+
+    ASSERT(!(cpu_mask & ~0xff));  /* Targets bitmap only supports 8 CPUs */
+    ASSERT(priority <= 0xff);     /* Only 8 bits of priority */
+    ASSERT(irq < gic.lines + 32); /* Can't route interrupts that don't exist */
+
+    spin_lock_irqsave(&desc->lock, flags);
+    spin_lock(&gic.lock);
+
+    if ( desc->action != NULL )
+    {
+        spin_unlock(&desc->lock);
+        return -EBUSY;
+    }
+
+    desc->handler = &gic_host_irq_type;
+
+    /* Disable interrupt */
+    desc->handler->shutdown(desc);
+
+    /* Set edge / level */
+    cfg = GICD[GICD_ICFGR + irq / 16];
+    edgebit = 2u << (2 * (irq % 16));
+    if ( level )
+        cfg &= ~edgebit;
+    else
+        cfg |= edgebit;
+    GICD[GICD_ICFGR + irq / 16] = cfg;
+
+    /* Set target CPU mask (RAZ/WI on uniprocessor) */
+    bytereg = (unsigned char *) (GICD + GICD_ITARGETSR);
+    bytereg[irq] = cpu_mask;
+
+    /* Set priority */
+    bytereg = (unsigned char *) (GICD + GICD_IPRIORITYR);
+    bytereg[irq] = priority;
+
+    spin_unlock(&gic.lock);
+    spin_unlock_irqrestore(&desc->lock, flags);
+    return 0;
+}
+
+static void __init gic_dist_init(void)
+{
+    uint32_t type;
+    uint32_t cpumask = 1 << smp_processor_id();
+    int i;
+
+    cpumask |= cpumask << 8;
+    cpumask |= cpumask << 16;
+
+    /* Disable the distributor */
+    GICD[GICD_CTLR] = 0;
+
+    type = GICD[GICD_TYPER];
+    gic.lines = 32 * (type & GICD_TYPE_LINES);
+    gic.cpus = 1 + ((type & GICD_TYPE_CPUS) >> 5);
+    printk("GIC: %d lines, %d cpu%s%s (IID %8.8x).\n",
+           gic.lines, gic.cpus, (gic.cpus == 1) ? "" : "s",
+           (type & GICD_TYPE_SEC) ? ", secure" : "",
+           GICD[GICD_IIDR]);
+
+    /* Default all global IRQs to level, active low */
+    for ( i = 32; i < gic.lines; i += 16 )
+        GICD[GICD_ICFGR + i / 16] = 0x0;
+
+    /* Route all global IRQs to this CPU */
+    for ( i = 32; i < gic.lines; i += 4 )
+        GICD[GICD_ICFGR + i / 4] = cpumask;
+
+    /* Default priority for global interrupts */
+    for ( i = 32; i < gic.lines; i += 4 )
+        GICD[GICD_IPRIORITYR + i / 4] = 0xa0a0a0a0;
+
+    /* Disable all global interrupts */
+    for ( i = 32; i < gic.lines; i += 32 )
+        GICD[GICD_ICENABLER + i / 32] = ~0ul;
+
+    /* Turn on the distributor */
+    GICD[GICD_CTLR] = GICD_CTL_ENABLE;
+}
+
+static void __cpuinit gic_cpu_init(void)
+{
+    int i;
+
+    /* Disable all PPI and enable all SGI */
+    GICD[GICD_ICENABLER] = 0xffff0000; /* Disable all PPI */
+    GICD[GICD_ISENABLER] = 0x0000ffff; /* Enable all SGI */
+    /* Set PPI and SGI priorities */
+    for (i = 0; i < 32; i += 4)
+        GICD[GICD_IPRIORITYR + i / 4] = 0xa0a0a0a0;
+
+    /* Local settings: interface controller */
+    GICC[GICC_PMR] = 0xff;                /* Don't mask by priority */
+    GICC[GICC_BPR] = 0;                   /* Finest granularity of priority */
+    GICC[GICC_CTLR] = GICC_CTL_ENABLE|GICC_CTL_EOI;    /* Turn on delivery */
+}
+
+static void __cpuinit gic_hyp_init(void)
+{
+    uint32_t vtr;
+
+    vtr = GICH[GICH_VTR];
+    nr_lrs  = (vtr & GICH_VTR_NRLRGS) + 1;
+    printk("GICH: %d list registers available\n", nr_lrs);
+
+    GICH[GICH_HCR] = GICH_HCR_EN;
+    GICH[GICH_MISR] = GICH_MISR_EOI;
+}
+
+/* Set up the GIC */
+void gic_init(void)
+{
+    /* XXX FIXME get this from devicetree */
+    gic.dbase = GIC_BASE_ADDRESS + GIC_DR_OFFSET;
+    gic.cbase = GIC_BASE_ADDRESS + GIC_CR_OFFSET;
+    gic.hbase = GIC_BASE_ADDRESS + GIC_HR_OFFSET;
+    set_fixmap(FIXMAP_GICD, gic.dbase >> PAGE_SHIFT, DEV_SHARED);
+    BUILD_BUG_ON(FIXMAP_ADDR(FIXMAP_GICC1) !=
+                 FIXMAP_ADDR(FIXMAP_GICC2)-PAGE_SIZE);
+    set_fixmap(FIXMAP_GICC1, gic.cbase >> PAGE_SHIFT, DEV_SHARED);
+    set_fixmap(FIXMAP_GICC2, (gic.cbase >> PAGE_SHIFT) + 1, DEV_SHARED);
+    set_fixmap(FIXMAP_GICH, gic.hbase >> PAGE_SHIFT, DEV_SHARED);
+
+    /* Global settings: interrupt distributor */
+    spin_lock_init(&gic.lock);
+    spin_lock(&gic.lock);
+
+    gic_dist_init();
+    gic_cpu_init();
+    gic_hyp_init();
+
+    spin_unlock(&gic.lock);
+}
+
+void gic_route_irqs(void)
+{
+    /* XXX should get these from DT */
+    /* GIC maintenance */
+    gic_route_irq(25, 1, 1u << smp_processor_id(), 0xa0);
+    /* Hypervisor Timer */
+    gic_route_irq(26, 1, 1u << smp_processor_id(), 0xa0);
+    /* Timer */
+    gic_route_irq(30, 1, 1u << smp_processor_id(), 0xa0);
+    /* UART */
+    gic_route_irq(37, 0, 1u << smp_processor_id(), 0xa0);
+}
+
+void __init release_irq(unsigned int irq)
+{
+    struct irq_desc *desc;
+    unsigned long flags;
+   struct irqaction *action;
+
+    desc = irq_to_desc(irq);
+
+    spin_lock_irqsave(&desc->lock,flags);
+    action = desc->action;
+    desc->action  = NULL;
+    desc->status |= IRQ_DISABLED;
+
+    spin_lock(&gic.lock);
+    desc->handler->shutdown(desc);
+    spin_unlock(&gic.lock);
+
+    spin_unlock_irqrestore(&desc->lock,flags);
+
+    /* Wait to make sure it's not being used on another CPU */
+    do { smp_mb(); } while ( desc->status & IRQ_INPROGRESS );
+
+    if (action && action->free_on_release)
+        xfree(action);
+}
+
+static int __setup_irq(struct irq_desc *desc, unsigned int irq,
+                       struct irqaction *new)
+{
+    if ( desc->action != NULL )
+        return -EBUSY;
+
+    desc->action  = new;
+    desc->status &= ~IRQ_DISABLED;
+    dsb();
+
+    desc->handler->startup(desc);
+
+    return 0;
+}
+
+int __init setup_irq(unsigned int irq, struct irqaction *new)
+{
+    int rc;
+    unsigned long flags;
+    struct irq_desc *desc;
+
+    desc = irq_to_desc(irq);
+
+    spin_lock_irqsave(&desc->lock, flags);
+
+    rc = __setup_irq(desc, irq, new);
+
+    spin_unlock_irqrestore(&desc->lock,flags);
+
+    return rc;
+}
+
+void gic_set_guest_irq(unsigned int virtual_irq,
+        unsigned int state, unsigned int priority)
+{
+    BUG_ON(virtual_irq > nr_lrs);
+    GICH[GICH_LR + virtual_irq] = state |
+        GICH_LR_MAINTENANCE_IRQ |
+        ((priority >> 3) << GICH_LR_PRIORITY_SHIFT) |
+        ((virtual_irq & GICH_LR_VIRTUAL_MASK) << GICH_LR_VIRTUAL_SHIFT);
+}
+
+void gic_inject_irq_start(void)
+{
+    uint32_t hcr;
+    hcr = READ_CP32(HCR);
+    WRITE_CP32(hcr | HCR_VI, HCR);
+    isb();
+}
+
+void gic_inject_irq_stop(void)
+{
+    uint32_t hcr;
+    hcr = READ_CP32(HCR);
+    if (hcr & HCR_VI) {
+        WRITE_CP32(hcr & ~HCR_VI, HCR);
+        isb();
+    }
+}
+
+int gic_route_irq_to_guest(struct domain *d, unsigned int irq,
+                           const char * devname)
+{
+    struct irqaction *action;
+    struct irq_desc *desc = irq_to_desc(irq);
+    unsigned long flags;
+    int retval;
+
+    action = xmalloc(struct irqaction);
+    if (!action)
+        return -ENOMEM;
+
+    action->dev_id = d;
+    action->name = devname;
+
+    spin_lock_irqsave(&desc->lock, flags);
+
+    desc->handler = &gic_guest_irq_type;
+    desc->status |= IRQ_GUEST;
+
+    retval = __setup_irq(desc, irq, action);
+    if (retval) {
+        xfree(action);
+        goto out;
+    }
+
+out:
+    spin_unlock_irqrestore(&desc->lock, flags);
+    return retval;
+}
+
+/* Accept an interrupt from the GIC and dispatch its handler */
+void gic_interrupt(struct cpu_user_regs *regs, int is_fiq)
+{
+    uint32_t intack = GICC[GICC_IAR];
+    unsigned int irq = intack & GICC_IA_IRQ;
+
+    if ( irq == 1023 )
+        /* Spurious interrupt */
+        return;
+
+    do_IRQ(regs, irq, is_fiq);
+}
+
+void gicv_setup(struct domain *d)
+{
+    /* map the gic virtual cpu interface in the gic cpu interface region of
+     * the guest */
+    printk("mapping GICC at %#"PRIx32" to %#"PRIx32"\n",
+           GIC_BASE_ADDRESS + GIC_CR_OFFSET,
+           GIC_BASE_ADDRESS + GIC_VR_OFFSET);
+    map_mmio_regions(d, GIC_BASE_ADDRESS + GIC_CR_OFFSET,
+                        GIC_BASE_ADDRESS + GIC_CR_OFFSET + (2 * PAGE_SIZE) - 1,
+                        GIC_BASE_ADDRESS + GIC_VR_OFFSET);
+}
+
+static void maintenance_interrupt(int irq, void *dev_id, struct cpu_user_regs *regs)
+{
+    int i, virq;
+    uint32_t lr;
+    uint64_t eisr = GICH[GICH_EISR0] | (((uint64_t) GICH[GICH_EISR1]) << 32);
+
+    for ( i = 0; i < 64; i++ ) {
+        if ( eisr & ((uint64_t)1 << i) ) {
+            struct pending_irq *p;
+
+            lr = GICH[GICH_LR + i];
+            virq = lr & GICH_LR_VIRTUAL_MASK;
+            GICH[GICH_LR + i] = 0;
+
+            spin_lock(&current->arch.vgic.lock);
+            p = irq_to_pending(current, virq);
+            if ( p->desc != NULL ) {
+                p->desc->status &= ~IRQ_INPROGRESS;
+                GICC[GICC_DIR] = virq;
+            }
+            gic_inject_irq_stop();
+            list_del(&p->link);
+            INIT_LIST_HEAD(&p->link);
+            cpu_raise_softirq(current->processor, VGIC_SOFTIRQ);
+            spin_unlock(&current->arch.vgic.lock);
+        }
+    }
+}
+
+void __cpuinit init_maintenance_interrupt(void)
+{
+    request_irq(25, maintenance_interrupt, 0, "irq-maintenance", NULL);
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/arch/arm/gic.h b/xen/arch/arm/gic.h
new file mode 100644
index 0000000..63b6648
--- /dev/null
+++ b/xen/arch/arm/gic.h
@@ -0,0 +1,151 @@
+/*
+ * xen/arch/arm/gic.h
+ *
+ * ARM Generic Interrupt Controller support
+ *
+ * Tim Deegan <tim@xen.org>
+ * Copyright (c) 2011 Citrix Systems.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#ifndef __ARCH_ARM_GIC_H__
+#define __ARCH_ARM_GIC_H__
+
+#define GICD_CTLR       (0x000/4)
+#define GICD_TYPER      (0x004/4)
+#define GICD_IIDR       (0x008/4)
+#define GICD_IGROUPR    (0x080/4)
+#define GICD_IGROUPRN   (0x0FC/4)
+#define GICD_ISENABLER  (0x100/4)
+#define GICD_ISENABLERN (0x17C/4)
+#define GICD_ICENABLER  (0x180/4)
+#define GICD_ICENABLERN (0x1fC/4)
+#define GICD_ISPENDR    (0x200/4)
+#define GICD_ISPENDRN   (0x27C/4)
+#define GICD_ICPENDR    (0x280/4)
+#define GICD_ICPENDRN   (0x2FC/4)
+#define GICD_ISACTIVER  (0x300/4)
+#define GICD_ISACTIVERN (0x37C/4)
+#define GICD_ICACTIVER  (0x380/4)
+#define GICD_ICACTIVERN (0x3FC/4)
+#define GICD_IPRIORITYR (0x400/4)
+#define GICD_IPRIORITYRN (0x7F8/4)
+#define GICD_ITARGETSR  (0x800/4)
+#define GICD_ITARGETSRN (0xBF8/4)
+#define GICD_ICFGR      (0xC00/4)
+#define GICD_ICFGRN     (0xCFC/4)
+#define GICD_NSACR      (0xE00/4)
+#define GICD_NSACRN     (0xEFC/4)
+#define GICD_ICPIDR2    (0xFE8/4)
+#define GICD_SGIR       (0xF00/4)
+#define GICD_CPENDSGIR  (0xF10/4)
+#define GICD_CPENDSGIRN (0xF1C/4)
+#define GICD_SPENDSGIR  (0xF20/4)
+#define GICD_SPENDSGIRN (0xF2C/4)
+#define GICD_ICPIDR2    (0xFE8/4)
+
+#define GICC_CTLR       (0x0000/4)
+#define GICC_PMR        (0x0004/4)
+#define GICC_BPR        (0x0008/4)
+#define GICC_IAR        (0x000C/4)
+#define GICC_EOIR       (0x0010/4)
+#define GICC_RPR        (0x0014/4)
+#define GICC_HPPIR      (0x0018/4)
+#define GICC_APR        (0x00D0/4)
+#define GICC_NSAPR      (0x00E0/4)
+#define GICC_DIR        (0x1000/4)
+
+#define GICH_HCR        (0x00/4)
+#define GICH_VTR        (0x04/4)
+#define GICH_VMCR       (0x08/4)
+#define GICH_MISR       (0x10/4)
+#define GICH_EISR0      (0x20/4)
+#define GICH_EISR1      (0x24/4)
+#define GICH_ELRSR0     (0x30/4)
+#define GICH_ELRSR1     (0x34/4)
+#define GICH_APR        (0xF0/4)
+#define GICH_LR         (0x100/4)
+
+/* Register bits */
+#define GICD_CTL_ENABLE 0x1
+
+#define GICD_TYPE_LINES 0x01f
+#define GICD_TYPE_CPUS  0x0e0
+#define GICD_TYPE_SEC   0x400
+
+#define GICC_CTL_ENABLE 0x1
+#define GICC_CTL_EOI    (0x1 << 9)
+
+#define GICC_IA_IRQ     0x03ff
+#define GICC_IA_CPU     0x1c00
+
+#define GICH_HCR_EN       (1 << 0)
+#define GICH_HCR_UIE      (1 << 1)
+#define GICH_HCR_LRENPIE  (1 << 2)
+#define GICH_HCR_NPIE     (1 << 3)
+#define GICH_HCR_VGRP0EIE (1 << 4)
+#define GICH_HCR_VGRP0DIE (1 << 5)
+#define GICH_HCR_VGRP1EIE (1 << 6)
+#define GICH_HCR_VGRP1DIE (1 << 7)
+
+#define GICH_MISR_EOI     (1 << 0)
+#define GICH_MISR_U       (1 << 1)
+#define GICH_MISR_LRENP   (1 << 2)
+#define GICH_MISR_NP      (1 << 3)
+#define GICH_MISR_VGRP0E  (1 << 4)
+#define GICH_MISR_VGRP0D  (1 << 5)
+#define GICH_MISR_VGRP1E  (1 << 6)
+#define GICH_MISR_VGRP1D  (1 << 7)
+
+#define GICH_LR_VIRTUAL_MASK    0x3ff
+#define GICH_LR_VIRTUAL_SHIFT   0
+#define GICH_LR_PHYSICAL_MASK   0x3ff
+#define GICH_LR_PHYSICAL_SHIFT  10
+#define GICH_LR_STATE_MASK      0x3
+#define GICH_LR_STATE_SHIFT     28
+#define GICH_LR_PRIORITY_SHIFT  23
+#define GICH_LR_MAINTENANCE_IRQ (1<<19)
+#define GICH_LR_PENDING         (1<<28)
+#define GICH_LR_ACTIVE          (1<<29)
+#define GICH_LR_GRP1            (1<<30)
+#define GICH_LR_HW              (1<<31)
+#define GICH_LR_CPUID_SHIFT     9
+#define GICH_VTR_NRLRGS         0x3f
+
+extern struct pending_irq *irq_to_pending(struct vcpu *v, unsigned int irq);
+
+extern void gic_route_irqs(void);
+
+extern void __cpuinit init_maintenance_interrupt(void);
+extern void gic_set_guest_irq(unsigned int irq,
+        unsigned int state, unsigned int priority);
+extern void gic_inject_irq_start(void);
+extern void gic_inject_irq_stop(void);
+extern int gic_route_irq_to_guest(struct domain *d, unsigned int irq,
+                                  const char * devname);
+
+/* Accept an interrupt from the GIC and dispatch its handler */
+extern void gic_interrupt(struct cpu_user_regs *regs, int is_fiq);
+/* Bring up the interrupt controller */
+extern void gic_init(void);
+/* setup the gic virtual interface for a guest */
+extern void gicv_setup(struct domain *d);
+#endif
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 18:20:37 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 18:20:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXzd0-0007wX-SP; Tue, 06 Dec 2011 18:20:30 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RXzcy-0007tn-TR
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 18:20:29 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1323195530!59687716!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDcxMjI=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2174 invoked from network); 6 Dec 2011 18:18:55 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Dec 2011 18:18:55 -0000
X-IronPort-AV: E=Sophos;i="4.71,307,1320642000"; d="scan'208";a="19721943"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Dec 2011 13:19:44 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Tue, 6 Dec 2011 13:19:44 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pB6IJEjN019549;
	Tue, 6 Dec 2011 10:19:32 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Tue, 6 Dec 2011 18:19:57 +0000
Message-ID: <1323195609-17277-13-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1112061753410.31179@kaball-desktop>
References: <alpine.DEB.2.00.1112061753410.31179@kaball-desktop>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>, Tim.Deegan@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH RFC 13/25] arm: domain
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Domain creation and destruction, vcpu initialization and destruction,
arch specific scheduling functions called by common code.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
---
 xen/arch/arm/Makefile        |    1 +
 xen/arch/arm/domain.c        |  253 ++++++++++++++++++++++++++++++++++++++++++
 xen/include/asm-arm/domain.h |   43 +++++++
 3 files changed, 297 insertions(+), 0 deletions(-)
 create mode 100644 xen/arch/arm/domain.c
 create mode 100644 xen/include/asm-arm/domain.h

diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index 6a250f1..8549f33 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -2,6 +2,7 @@ subdir-y += lib
 
 obj-y += dummy.o
 obj-y += entry.o
+obj-y += domain.o
 
 #obj-bin-y += ....o
 
diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
new file mode 100644
index 0000000..d706b5f
--- /dev/null
+++ b/xen/arch/arm/domain.c
@@ -0,0 +1,253 @@
+#include <xen/config.h>
+#include <xen/init.h>
+#include <xen/lib.h>
+#include <xen/sched.h>
+#include <xen/softirq.h>
+#include <xen/wait.h>
+#include <xen/errno.h>
+
+#include <asm/current.h>
+#include <asm/regs.h>
+#include <asm/p2m.h>
+#include <asm/irq.h>
+
+DEFINE_PER_CPU(struct vcpu *, curr_vcpu);
+
+static void continue_idle_domain(struct vcpu *v)
+{
+    reset_stack_and_jump(idle_loop);
+}
+
+static void continue_nonidle_domain(struct vcpu *v)
+{
+    /* check_wakeup_from_wait(); */
+    reset_stack_and_jump(return_from_trap);
+}
+
+void idle_loop(void)
+{
+    for ( ; ; )
+    {
+		/* TODO
+		   if ( cpu_is_offline(smp_processor_id()) )
+		   play_dead();
+		   (*pm_idle)();
+		   BUG();
+		*/
+        do_tasklet();
+        do_softirq();
+    }
+}
+
+static void ctxt_switch_from(struct vcpu *p)
+{
+
+}
+
+static void ctxt_switch_to(struct vcpu *n)
+{
+    p2m_load_VTTBR(n->domain);
+}
+
+static void __context_switch(void)
+{
+    struct cpu_user_regs *stack_regs = guest_cpu_user_regs();
+    unsigned int          cpu = smp_processor_id();
+    struct vcpu          *p = per_cpu(curr_vcpu, cpu);
+    struct vcpu          *n = current;
+
+    ASSERT(p != n);
+    ASSERT(cpumask_empty(n->vcpu_dirty_cpumask));
+
+    if ( !is_idle_vcpu(p) )
+    {
+        memcpy(&p->arch.user_regs, stack_regs, CTXT_SWITCH_STACK_BYTES);
+        ctxt_switch_from(p);
+    }
+
+    if ( !is_idle_vcpu(n) )
+    {
+        memcpy(stack_regs, &n->arch.user_regs, CTXT_SWITCH_STACK_BYTES);
+        ctxt_switch_to(n);
+    }
+
+    per_cpu(curr_vcpu, cpu) = n;
+
+}
+
+static void schedule_tail(struct vcpu *v)
+{
+    if ( is_idle_vcpu(v) )
+        continue_idle_domain(v);
+    else
+        continue_nonidle_domain(v);
+}
+
+void context_switch(struct vcpu *prev, struct vcpu *next)
+{
+    unsigned int cpu = smp_processor_id();
+
+    ASSERT(local_irq_is_enabled());
+
+    printk("context switch %d:%d%s -> %d:%d%s\n",
+           prev->domain->domain_id, prev->vcpu_id, is_idle_vcpu(prev) ? " (idle)" : "",
+           next->domain->domain_id, next->vcpu_id, is_idle_vcpu(next) ? " (idle)" : "");
+
+	/* TODO
+	   if (prev != next)
+	   update_runstate_area(prev);
+	*/
+
+    local_irq_disable();
+
+    set_current(next);
+
+    if ( (per_cpu(curr_vcpu, cpu) == next) ||
+         (is_idle_vcpu(next) && cpu_online(cpu)) )
+    {
+        local_irq_enable();
+    }
+    else
+    {
+        __context_switch();
+
+        /* Re-enable interrupts before restoring state which may fault. */
+        local_irq_enable();
+    }
+
+    context_saved(prev);
+
+	/* TODO
+	   if (prev != next)
+	   update_runstate_area(next);
+	*/
+
+    schedule_tail(next);
+    BUG();
+
+}
+
+void continue_running(struct vcpu *same)
+{
+    schedule_tail(same);
+    BUG();
+}
+
+int __sync_local_execstate(void)
+{
+    unsigned long flags;
+    int switch_required;
+
+    local_irq_save(flags);
+
+    switch_required = (this_cpu(curr_vcpu) != current);
+
+    if ( switch_required )
+    {
+        ASSERT(current == idle_vcpu[smp_processor_id()]);
+        __context_switch();
+    }
+
+    local_irq_restore(flags);
+
+    return switch_required;
+}
+
+void sync_local_execstate(void)
+{
+    (void)__sync_local_execstate();
+}
+
+void startup_cpu_idle_loop(void)
+{
+        struct vcpu *v = current;
+
+        ASSERT(is_idle_vcpu(v));
+		/* TODO
+		   cpumask_set_cpu(v->processor, v->domain->domain_dirty_cpumask);
+		   cpumask_set_cpu(v->processor, v->vcpu_dirty_cpumask);
+		*/
+
+        reset_stack_and_jump(idle_loop);
+}
+
+struct domain *alloc_domain_struct(void)
+{
+    struct domain *d;
+    BUILD_BUG_ON(sizeof(*d) > PAGE_SIZE);
+    d = alloc_xenheap_pages(0, 0);
+    if ( d != NULL )
+        clear_page(d);
+    return d;
+}
+
+void free_domain_struct(struct domain *d)
+{
+    free_xenheap_page(d);
+}
+
+void dump_pageframe_info(struct domain *d)
+{
+
+}
+
+struct vcpu *alloc_vcpu_struct(void)
+{
+    struct vcpu *v;
+    BUILD_BUG_ON(sizeof(*v) > PAGE_SIZE);
+    v = alloc_xenheap_pages(0, 0);
+    if ( v != NULL )
+        clear_page(v);
+    return v;
+}
+
+void free_vcpu_struct(struct vcpu *v)
+{
+    free_xenheap_page(v);
+}
+
+int vcpu_initialise(struct vcpu *v)
+{
+    int rc = 0;
+
+    return rc;
+}
+
+void vcpu_destroy(struct vcpu *v)
+{
+
+}
+
+int arch_domain_create(struct domain *d, unsigned int domcr_flags)
+{
+    int rc;
+
+    d->max_vcpus = 8;
+
+    rc = 0;
+fail:
+    return rc;
+}
+
+void arch_domain_destroy(struct domain *d)
+{
+    /* p2m_destroy */
+    /* domain_vgic_destroy */
+}
+
+void arch_dump_domain_info(struct domain *d)
+{
+}
+
+void arch_dump_vcpu_info(struct vcpu *v)
+{
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
new file mode 100644
index 0000000..c226bdf
--- /dev/null
+++ b/xen/include/asm-arm/domain.h
@@ -0,0 +1,43 @@
+#ifndef __ASM_DOMAIN_H__
+#define __ASM_DOMAIN_H__
+
+#include <xen/config.h>
+#include <xen/cache.h>
+#include <asm/page.h>
+#include <asm/p2m.h>
+
+struct pending_irq
+{
+    int irq;
+    struct irq_desc *desc; /* only set it the irq corresponds to a physical irq */
+    uint8_t priority;
+    struct list_head link;
+};
+
+struct arch_domain
+{
+}  __cacheline_aligned;
+
+struct arch_vcpu
+{
+    struct cpu_user_regs user_regs;
+
+    uint32_t sctlr;
+    uint32_t ttbr0, ttbr1, ttbcr;
+
+}  __cacheline_aligned;
+
+void vcpu_show_execution_state(struct vcpu *);
+void vcpu_show_registers(const struct vcpu *);
+
+#endif /* __ASM_DOMAIN_H__ */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 18:20:37 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 18:20:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXzcs-0007so-Hu; Tue, 06 Dec 2011 18:20:22 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RXzcr-0007sA-2c
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 18:20:21 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1323195573!4508317!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDcxMjI=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13080 invoked from network); 6 Dec 2011 18:19:34 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Dec 2011 18:19:34 -0000
X-IronPort-AV: E=Sophos;i="4.71,307,1320642000"; d="scan'208";a="19721935"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Dec 2011 13:19:33 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Tue, 6 Dec 2011 13:19:32 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pB6IJEjF019549;
	Tue, 6 Dec 2011 10:19:21 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Tue, 6 Dec 2011 18:19:49 +0000
Message-ID: <1323195609-17277-5-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1112061753410.31179@kaball-desktop>
References: <alpine.DEB.2.00.1112061753410.31179@kaball-desktop>
MIME-Version: 1.0
Cc: Ian.Campbell@citrix.com, Tim.Deegan@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH RFC 05/25] Introduce clear_user
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Introduce clear_user for x86 and ia64, shamelessly taken from Linux.
The x86 version is the 32 bit clear_user implementation.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen/arch/ia64/linux/memcpy_mck.S |  177 ++++++++++++++++++++++++++++++++++++++
 xen/arch/x86/usercopy.c          |   36 ++++++++
 xen/include/asm-ia64/uaccess.h   |   12 +++
 xen/include/asm-x86/uaccess.h    |    1 +
 4 files changed, 226 insertions(+), 0 deletions(-)

diff --git a/xen/arch/ia64/linux/memcpy_mck.S b/xen/arch/ia64/linux/memcpy_mck.S
index 6f308e6..8b07006 100644
--- a/xen/arch/ia64/linux/memcpy_mck.S
+++ b/xen/arch/ia64/linux/memcpy_mck.S
@@ -659,3 +659,180 @@ EK(.ex_handler,  (p17)	st8	[dst1]=r39,8);						\
 
 /* end of McKinley specific optimization */
 END(__copy_user)
+
+/*
+ * Theory of operations:
+ *	- we check whether or not the buffer is small, i.e., less than 17
+ *	  in which case we do the byte by byte loop.
+ *
+ *	- Otherwise we go progressively from 1 byte store to 8byte store in
+ *	  the head part, the body is a 16byte store loop and we finish we the
+ *	  tail for the last 15 bytes.
+ *	  The good point about this breakdown is that the long buffer handling
+ *	  contains only 2 branches.
+ *
+ *	The reason for not using shifting & masking for both the head and the
+ *	tail is to stay semantically correct. This routine is not supposed
+ *	to write bytes outside of the buffer. While most of the time this would
+ *	be ok, we can't tolerate a mistake. A classical example is the case
+ *	of multithreaded code were to the extra bytes touched is actually owned
+ *	by another thread which runs concurrently to ours. Another, less likely,
+ *	example is with device drivers where reading an I/O mapped location may
+ *	have side effects (same thing for writing).
+ */
+GLOBAL_ENTRY(__do_clear_user)
+	.prologue
+	.save ar.pfs, saved_pfs
+	alloc	saved_pfs=ar.pfs,2,0,0,0
+	cmp.eq p6,p0=r0,len		// check for zero length
+	.save ar.lc, saved_lc
+	mov saved_lc=ar.lc		// preserve ar.lc (slow)
+	.body
+	;;				// avoid WAW on CFM
+	adds tmp=-1,len			// br.ctop is repeat/until
+	mov ret0=len			// return value is length at this point
+(p6)	br.ret.spnt.many rp
+	;;
+	cmp.lt p6,p0=16,len		// if len > 16 then long memset
+	mov ar.lc=tmp			// initialize lc for small count
+(p6)	br.cond.dptk .long_do_clear
+	;;				// WAR on ar.lc
+	//
+	// worst case 16 iterations, avg 8 iterations
+	//
+	// We could have played with the predicates to use the extra
+	// M slot for 2 stores/iteration but the cost the initialization
+	// the various counters compared to how long the loop is supposed
+	// to last on average does not make this solution viable.
+	//
+1:
+	EX( .Lexit1, st1 [buf]=r0,1 )
+	adds len=-1,len			// countdown length using len
+	br.cloop.dptk 1b
+	;;				// avoid RAW on ar.lc
+	//
+	// .Lexit4: comes from byte by byte loop
+	//	    len contains bytes left
+.Lexit1:
+	mov ret0=len			// faster than using ar.lc
+	mov ar.lc=saved_lc
+	br.ret.sptk.many rp		// end of short clear_user
+
+
+	//
+	// At this point we know we have more than 16 bytes to copy
+	// so we focus on alignment (no branches required)
+	//
+	// The use of len/len2 for countdown of the number of bytes left
+	// instead of ret0 is due to the fact that the exception code
+	// changes the values of r8.
+	//
+.long_do_clear:
+	tbit.nz p6,p0=buf,0		// odd alignment (for long_do_clear)
+	;;
+	EX( .Lexit3, (p6) st1 [buf]=r0,1 )	// 1-byte aligned
+(p6)	adds len=-1,len;;		// sync because buf is modified
+	tbit.nz p6,p0=buf,1
+	;;
+	EX( .Lexit3, (p6) st2 [buf]=r0,2 )	// 2-byte aligned
+(p6)	adds len=-2,len;;
+	tbit.nz p6,p0=buf,2
+	;;
+	EX( .Lexit3, (p6) st4 [buf]=r0,4 )	// 4-byte aligned
+(p6)	adds len=-4,len;;
+	tbit.nz p6,p0=buf,3
+	;;
+	EX( .Lexit3, (p6) st8 [buf]=r0,8 )	// 8-byte aligned
+(p6)	adds len=-8,len;;
+	shr.u cnt=len,4		// number of 128-bit (2x64bit) words
+	;;
+	cmp.eq p6,p0=r0,cnt
+	adds tmp=-1,cnt
+(p6)	br.cond.dpnt .dotail		// we have less than 16 bytes left
+	;;
+	adds buf2=8,buf			// setup second base pointer
+	mov ar.lc=tmp
+	;;
+
+	//
+	// 16bytes/iteration core loop
+	//
+	// The second store can never generate a fault because
+	// we come into the loop only when we are 16-byte aligned.
+	// This means that if we cross a page then it will always be
+	// in the first store and never in the second.
+	//
+	//
+	// We need to keep track of the remaining length. A possible (optimistic)
+	// way would be to use ar.lc and derive how many byte were left by
+	// doing : left= 16*ar.lc + 16.  this would avoid the addition at
+	// every iteration.
+	// However we need to keep the synchronization point. A template
+	// M;;MB does not exist and thus we can keep the addition at no
+	// extra cycle cost (use a nop slot anyway). It also simplifies the
+	// (unlikely)  error recovery code
+	//
+
+2:	EX(.Lexit3, st8 [buf]=r0,16 )
+	;;				// needed to get len correct when error
+	st8 [buf2]=r0,16
+	adds len=-16,len
+	br.cloop.dptk 2b
+	;;
+	mov ar.lc=saved_lc
+	//
+	// tail correction based on len only
+	//
+	// We alternate the use of len3,len2 to allow parallelism and correct
+	// error handling. We also reuse p6/p7 to return correct value.
+	// The addition of len2/len3 does not cost anything more compared to
+	// the regular memset as we had empty slots.
+	//
+.dotail:
+	mov len2=len			// for parallelization of error handling
+	mov len3=len
+	tbit.nz p6,p0=len,3
+	;;
+	EX( .Lexit2, (p6) st8 [buf]=r0,8 )	// at least 8 bytes
+(p6)	adds len3=-8,len2
+	tbit.nz p7,p6=len,2
+	;;
+	EX( .Lexit2, (p7) st4 [buf]=r0,4 )	// at least 4 bytes
+(p7)	adds len2=-4,len3
+	tbit.nz p6,p7=len,1
+	;;
+	EX( .Lexit2, (p6) st2 [buf]=r0,2 )	// at least 2 bytes
+(p6)	adds len3=-2,len2
+	tbit.nz p7,p6=len,0
+	;;
+	EX( .Lexit2, (p7) st1 [buf]=r0 )	// only 1 byte left
+	mov ret0=r0				// success
+	br.ret.sptk.many rp			// end of most likely path
+
+	//
+	// Outlined error handling code
+	//
+
+	//
+	// .Lexit3: comes from core loop, need restore pr/lc
+	//	    len contains bytes left
+	//
+	//
+	// .Lexit2:
+	//	if p6 -> coming from st8 or st2 : len2 contains what's left
+	//	if p7 -> coming from st4 or st1 : len3 contains what's left
+	// We must restore lc/pr even though might not have been used.
+.Lexit2:
+	.pred.rel "mutex", p6, p7
+(p6)	mov len=len2
+(p7)	mov len=len3
+	;;
+	//
+	// .Lexit4: comes from head, need not restore pr/lc
+	//	    len contains bytes left
+	//
+.Lexit3:
+	mov ret0=len
+	mov ar.lc=saved_lc
+	br.ret.sptk.many rp
+END(__do_clear_user)
diff --git a/xen/arch/x86/usercopy.c b/xen/arch/x86/usercopy.c
index d88e635..58dfc81 100644
--- a/xen/arch/x86/usercopy.c
+++ b/xen/arch/x86/usercopy.c
@@ -110,6 +110,42 @@ copy_to_user(void __user *to, const void *from, unsigned n)
     return n;
 }
 
+#define __do_clear_user(addr,size)					\
+do {									\
+	int __d0;							\
+	__asm__ __volatile__(						\
+		"0:	rep; stosl\n"					\
+		"	movl %2,%0\n"					\
+		"1:	rep; stosb\n"					\
+		"2:\n"							\
+		".section .fixup,\"ax\"\n"				\
+		"3:	lea 0(%2,%0,4),%0\n"				\
+		"	jmp 2b\n"					\
+		".previous\n"						\
+		_ASM_EXTABLE(0b,3b)					\
+		_ASM_EXTABLE(1b,2b)					\
+		: "=&c"(size), "=&D" (__d0)				\
+		: "r"(size & 3), "0"(size / 4), "1"(addr), "a"(0));	\
+} while (0)
+
+/**
+ * clear_user: - Zero a block of memory in user space.
+ * @to:   Destination address, in user space.
+ * @n:    Number of bytes to zero.
+ *
+ * Zero a block of memory in user space.
+ *
+ * Returns number of bytes that could not be cleared.
+ * On success, this will be zero.
+ */
+unsigned long
+clear_user(void __user *to, unsigned n)
+{
+	if ( access_ok(to, n) )
+		__do_clear_user(to, n);
+	return n;
+}
+
 /**
  * copy_from_user: - Copy a block of data from user space.
  * @to:   Destination address, in kernel space.
diff --git a/xen/include/asm-ia64/uaccess.h b/xen/include/asm-ia64/uaccess.h
index 32ef415..2ececb1 100644
--- a/xen/include/asm-ia64/uaccess.h
+++ b/xen/include/asm-ia64/uaccess.h
@@ -236,6 +236,18 @@ __copy_from_user (void *to, const void __user *from, unsigned long count)
 	__cu_len;									\
 })
 
+extern unsigned long __do_clear_user (void __user * to, unsigned long count);
+
+#define clear_user(to, n)					\
+({								\
+	void __user *__cu_to = (to);							\
+	long __cu_len = (n);								\
+											\
+	if (__access_ok(__cu_to))							\
+		__cu_len = __do_clear_user(__cu_to, __cu_len);	\
+	__cu_len;						\
+})
+
 #define copy_from_user(to, from, n)							\
 ({											\
 	void *__cu_to = (to);								\
diff --git a/xen/include/asm-x86/uaccess.h b/xen/include/asm-x86/uaccess.h
index e3e541b..d6f4458 100644
--- a/xen/include/asm-x86/uaccess.h
+++ b/xen/include/asm-x86/uaccess.h
@@ -16,6 +16,7 @@
 #endif
 
 unsigned long copy_to_user(void *to, const void *from, unsigned len);
+unsigned long clear_user(void *to, unsigned len);
 unsigned long copy_from_user(void *to, const void *from, unsigned len);
 /* Handles exceptions in both to and from, but doesn't do access_ok */
 unsigned long __copy_to_user_ll(void *to, const void *from, unsigned n);
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 18:20:37 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 18:20:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXzd0-0007wX-SP; Tue, 06 Dec 2011 18:20:30 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RXzcy-0007tn-TR
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 18:20:29 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1323195530!59687716!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDcxMjI=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2174 invoked from network); 6 Dec 2011 18:18:55 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Dec 2011 18:18:55 -0000
X-IronPort-AV: E=Sophos;i="4.71,307,1320642000"; d="scan'208";a="19721943"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Dec 2011 13:19:44 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Tue, 6 Dec 2011 13:19:44 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pB6IJEjN019549;
	Tue, 6 Dec 2011 10:19:32 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Tue, 6 Dec 2011 18:19:57 +0000
Message-ID: <1323195609-17277-13-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1112061753410.31179@kaball-desktop>
References: <alpine.DEB.2.00.1112061753410.31179@kaball-desktop>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>, Tim.Deegan@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH RFC 13/25] arm: domain
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Domain creation and destruction, vcpu initialization and destruction,
arch specific scheduling functions called by common code.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
---
 xen/arch/arm/Makefile        |    1 +
 xen/arch/arm/domain.c        |  253 ++++++++++++++++++++++++++++++++++++++++++
 xen/include/asm-arm/domain.h |   43 +++++++
 3 files changed, 297 insertions(+), 0 deletions(-)
 create mode 100644 xen/arch/arm/domain.c
 create mode 100644 xen/include/asm-arm/domain.h

diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index 6a250f1..8549f33 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -2,6 +2,7 @@ subdir-y += lib
 
 obj-y += dummy.o
 obj-y += entry.o
+obj-y += domain.o
 
 #obj-bin-y += ....o
 
diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
new file mode 100644
index 0000000..d706b5f
--- /dev/null
+++ b/xen/arch/arm/domain.c
@@ -0,0 +1,253 @@
+#include <xen/config.h>
+#include <xen/init.h>
+#include <xen/lib.h>
+#include <xen/sched.h>
+#include <xen/softirq.h>
+#include <xen/wait.h>
+#include <xen/errno.h>
+
+#include <asm/current.h>
+#include <asm/regs.h>
+#include <asm/p2m.h>
+#include <asm/irq.h>
+
+DEFINE_PER_CPU(struct vcpu *, curr_vcpu);
+
+static void continue_idle_domain(struct vcpu *v)
+{
+    reset_stack_and_jump(idle_loop);
+}
+
+static void continue_nonidle_domain(struct vcpu *v)
+{
+    /* check_wakeup_from_wait(); */
+    reset_stack_and_jump(return_from_trap);
+}
+
+void idle_loop(void)
+{
+    for ( ; ; )
+    {
+		/* TODO
+		   if ( cpu_is_offline(smp_processor_id()) )
+		   play_dead();
+		   (*pm_idle)();
+		   BUG();
+		*/
+        do_tasklet();
+        do_softirq();
+    }
+}
+
+static void ctxt_switch_from(struct vcpu *p)
+{
+
+}
+
+static void ctxt_switch_to(struct vcpu *n)
+{
+    p2m_load_VTTBR(n->domain);
+}
+
+static void __context_switch(void)
+{
+    struct cpu_user_regs *stack_regs = guest_cpu_user_regs();
+    unsigned int          cpu = smp_processor_id();
+    struct vcpu          *p = per_cpu(curr_vcpu, cpu);
+    struct vcpu          *n = current;
+
+    ASSERT(p != n);
+    ASSERT(cpumask_empty(n->vcpu_dirty_cpumask));
+
+    if ( !is_idle_vcpu(p) )
+    {
+        memcpy(&p->arch.user_regs, stack_regs, CTXT_SWITCH_STACK_BYTES);
+        ctxt_switch_from(p);
+    }
+
+    if ( !is_idle_vcpu(n) )
+    {
+        memcpy(stack_regs, &n->arch.user_regs, CTXT_SWITCH_STACK_BYTES);
+        ctxt_switch_to(n);
+    }
+
+    per_cpu(curr_vcpu, cpu) = n;
+
+}
+
+static void schedule_tail(struct vcpu *v)
+{
+    if ( is_idle_vcpu(v) )
+        continue_idle_domain(v);
+    else
+        continue_nonidle_domain(v);
+}
+
+void context_switch(struct vcpu *prev, struct vcpu *next)
+{
+    unsigned int cpu = smp_processor_id();
+
+    ASSERT(local_irq_is_enabled());
+
+    printk("context switch %d:%d%s -> %d:%d%s\n",
+           prev->domain->domain_id, prev->vcpu_id, is_idle_vcpu(prev) ? " (idle)" : "",
+           next->domain->domain_id, next->vcpu_id, is_idle_vcpu(next) ? " (idle)" : "");
+
+	/* TODO
+	   if (prev != next)
+	   update_runstate_area(prev);
+	*/
+
+    local_irq_disable();
+
+    set_current(next);
+
+    if ( (per_cpu(curr_vcpu, cpu) == next) ||
+         (is_idle_vcpu(next) && cpu_online(cpu)) )
+    {
+        local_irq_enable();
+    }
+    else
+    {
+        __context_switch();
+
+        /* Re-enable interrupts before restoring state which may fault. */
+        local_irq_enable();
+    }
+
+    context_saved(prev);
+
+	/* TODO
+	   if (prev != next)
+	   update_runstate_area(next);
+	*/
+
+    schedule_tail(next);
+    BUG();
+
+}
+
+void continue_running(struct vcpu *same)
+{
+    schedule_tail(same);
+    BUG();
+}
+
+int __sync_local_execstate(void)
+{
+    unsigned long flags;
+    int switch_required;
+
+    local_irq_save(flags);
+
+    switch_required = (this_cpu(curr_vcpu) != current);
+
+    if ( switch_required )
+    {
+        ASSERT(current == idle_vcpu[smp_processor_id()]);
+        __context_switch();
+    }
+
+    local_irq_restore(flags);
+
+    return switch_required;
+}
+
+void sync_local_execstate(void)
+{
+    (void)__sync_local_execstate();
+}
+
+void startup_cpu_idle_loop(void)
+{
+        struct vcpu *v = current;
+
+        ASSERT(is_idle_vcpu(v));
+		/* TODO
+		   cpumask_set_cpu(v->processor, v->domain->domain_dirty_cpumask);
+		   cpumask_set_cpu(v->processor, v->vcpu_dirty_cpumask);
+		*/
+
+        reset_stack_and_jump(idle_loop);
+}
+
+struct domain *alloc_domain_struct(void)
+{
+    struct domain *d;
+    BUILD_BUG_ON(sizeof(*d) > PAGE_SIZE);
+    d = alloc_xenheap_pages(0, 0);
+    if ( d != NULL )
+        clear_page(d);
+    return d;
+}
+
+void free_domain_struct(struct domain *d)
+{
+    free_xenheap_page(d);
+}
+
+void dump_pageframe_info(struct domain *d)
+{
+
+}
+
+struct vcpu *alloc_vcpu_struct(void)
+{
+    struct vcpu *v;
+    BUILD_BUG_ON(sizeof(*v) > PAGE_SIZE);
+    v = alloc_xenheap_pages(0, 0);
+    if ( v != NULL )
+        clear_page(v);
+    return v;
+}
+
+void free_vcpu_struct(struct vcpu *v)
+{
+    free_xenheap_page(v);
+}
+
+int vcpu_initialise(struct vcpu *v)
+{
+    int rc = 0;
+
+    return rc;
+}
+
+void vcpu_destroy(struct vcpu *v)
+{
+
+}
+
+int arch_domain_create(struct domain *d, unsigned int domcr_flags)
+{
+    int rc;
+
+    d->max_vcpus = 8;
+
+    rc = 0;
+fail:
+    return rc;
+}
+
+void arch_domain_destroy(struct domain *d)
+{
+    /* p2m_destroy */
+    /* domain_vgic_destroy */
+}
+
+void arch_dump_domain_info(struct domain *d)
+{
+}
+
+void arch_dump_vcpu_info(struct vcpu *v)
+{
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
new file mode 100644
index 0000000..c226bdf
--- /dev/null
+++ b/xen/include/asm-arm/domain.h
@@ -0,0 +1,43 @@
+#ifndef __ASM_DOMAIN_H__
+#define __ASM_DOMAIN_H__
+
+#include <xen/config.h>
+#include <xen/cache.h>
+#include <asm/page.h>
+#include <asm/p2m.h>
+
+struct pending_irq
+{
+    int irq;
+    struct irq_desc *desc; /* only set it the irq corresponds to a physical irq */
+    uint8_t priority;
+    struct list_head link;
+};
+
+struct arch_domain
+{
+}  __cacheline_aligned;
+
+struct arch_vcpu
+{
+    struct cpu_user_regs user_regs;
+
+    uint32_t sctlr;
+    uint32_t ttbr0, ttbr1, ttbcr;
+
+}  __cacheline_aligned;
+
+void vcpu_show_execution_state(struct vcpu *);
+void vcpu_show_registers(const struct vcpu *);
+
+#endif /* __ASM_DOMAIN_H__ */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 18:20:39 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 18:20:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXzd4-0007zw-6z; Tue, 06 Dec 2011 18:20:34 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RXzd3-0007vp-0W
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 18:20:33 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1323195555!51363960!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMzAwOTc=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4130 invoked from network); 6 Dec 2011 18:19:16 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Dec 2011 18:19:16 -0000
X-IronPort-AV: E=Sophos;i="4.71,307,1320642000"; d="scan'208";a="173120754"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Dec 2011 13:19:48 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Tue, 6 Dec 2011 13:19:47 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pB6IJEjM019549;
	Tue, 6 Dec 2011 10:19:31 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Tue, 6 Dec 2011 18:19:56 +0000
Message-ID: <1323195609-17277-12-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1112061753410.31179@kaball-desktop>
References: <alpine.DEB.2.00.1112061753410.31179@kaball-desktop>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>, Tim.Deegan@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH RFC 12/25] arm: entry.S and head.S
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Low level assembly routines, including entry.S and head.S.
Also the linker script and a collection of dummy functions that we plan
to reduce to zero as soon as possible.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
---
 xen/arch/arm/Makefile           |    5 +-
 xen/arch/arm/asm-offsets.c      |   76 ++++++++++
 xen/arch/arm/dummy.S            |   72 ++++++++++
 xen/arch/arm/entry.S            |  107 ++++++++++++++
 xen/arch/arm/head.S             |  298 +++++++++++++++++++++++++++++++++++++++
 xen/arch/arm/xen.lds.S          |  141 ++++++++++++++++++
 xen/include/asm-arm/asm_defns.h |   18 +++
 7 files changed, 716 insertions(+), 1 deletions(-)
 create mode 100644 xen/arch/arm/asm-offsets.c
 create mode 100644 xen/arch/arm/dummy.S
 create mode 100644 xen/arch/arm/entry.S
 create mode 100644 xen/arch/arm/head.S
 create mode 100644 xen/arch/arm/xen.lds.S
 create mode 100644 xen/include/asm-arm/asm_defns.h

diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index fd86cb0..6a250f1 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -1,8 +1,11 @@
 subdir-y += lib
 
+obj-y += dummy.o
+obj-y += entry.o
+
 #obj-bin-y += ....o
 
-ALL_OBJS := $(ALL_OBJS)
+ALL_OBJS := head.o $(ALL_OBJS)
 
 $(TARGET): $(TARGET)-syms
 	# XXX: VE model loads by VMA so instead of
diff --git a/xen/arch/arm/asm-offsets.c b/xen/arch/arm/asm-offsets.c
new file mode 100644
index 0000000..ee5d5d4
--- /dev/null
+++ b/xen/arch/arm/asm-offsets.c
@@ -0,0 +1,76 @@
+/*
+ * Generate definitions needed by assembly language modules.
+ * This code generates raw asm output which is post-processed
+ * to extract and format the required data.
+ */
+#define COMPILE_OFFSETS
+
+#include <xen/config.h>
+#include <xen/types.h>
+#include <public/xen.h>
+#include <asm/current.h>
+
+#define DEFINE(_sym, _val) \
+    __asm__ __volatile__ ( "\n->" #_sym " %0 " #_val : : "i" (_val) )
+#define BLANK() \
+    __asm__ __volatile__ ( "\n->" : : )
+#define OFFSET(_sym, _str, _mem) \
+    DEFINE(_sym, offsetof(_str, _mem));
+
+/* base-2 logarithm */
+#define __L2(_x)  (((_x) & 0x00000002) ?   1 : 0)
+#define __L4(_x)  (((_x) & 0x0000000c) ? ( 2 + __L2( (_x)>> 2)) : __L2( _x))
+#define __L8(_x)  (((_x) & 0x000000f0) ? ( 4 + __L4( (_x)>> 4)) : __L4( _x))
+#define __L16(_x) (((_x) & 0x0000ff00) ? ( 8 + __L8( (_x)>> 8)) : __L8( _x))
+#define LOG_2(_x) (((_x) & 0xffff0000) ? (16 + __L16((_x)>>16)) : __L16(_x))
+
+void __dummy__(void)
+{
+   OFFSET(UREGS_sp, struct cpu_user_regs, sp);
+   OFFSET(UREGS_lr, struct cpu_user_regs, lr);
+   OFFSET(UREGS_pc, struct cpu_user_regs, pc);
+   OFFSET(UREGS_cpsr, struct cpu_user_regs, cpsr);
+
+   OFFSET(UREGS_LR_usr, struct cpu_user_regs, lr_usr);
+   OFFSET(UREGS_SP_usr, struct cpu_user_regs, sp_usr);
+
+   OFFSET(UREGS_SP_svc, struct cpu_user_regs, sp_svc);
+   OFFSET(UREGS_LR_svc, struct cpu_user_regs, lr_svc);
+   OFFSET(UREGS_SPSR_svc, struct cpu_user_regs, spsr_svc);
+
+   OFFSET(UREGS_SP_abt, struct cpu_user_regs, sp_abt);
+   OFFSET(UREGS_LR_abt, struct cpu_user_regs, lr_abt);
+   OFFSET(UREGS_SPSR_abt, struct cpu_user_regs, spsr_abt);
+
+   OFFSET(UREGS_SP_und, struct cpu_user_regs, sp_und);
+   OFFSET(UREGS_LR_und, struct cpu_user_regs, lr_und);
+   OFFSET(UREGS_SPSR_und, struct cpu_user_regs, spsr_und);
+
+   OFFSET(UREGS_SP_irq, struct cpu_user_regs, sp_irq);
+   OFFSET(UREGS_LR_irq, struct cpu_user_regs, lr_irq);
+   OFFSET(UREGS_SPSR_irq, struct cpu_user_regs, spsr_irq);
+
+   OFFSET(UREGS_SP_fiq, struct cpu_user_regs, sp_fiq);
+   OFFSET(UREGS_LR_fiq, struct cpu_user_regs, lr_fiq);
+   OFFSET(UREGS_SPSR_fiq, struct cpu_user_regs, spsr_fiq);
+
+   OFFSET(UREGS_R8_fiq, struct cpu_user_regs, r8_fiq);
+   OFFSET(UREGS_R9_fiq, struct cpu_user_regs, r9_fiq);
+   OFFSET(UREGS_R10_fiq, struct cpu_user_regs, r10_fiq);
+   OFFSET(UREGS_R11_fiq, struct cpu_user_regs, r11_fiq);
+   OFFSET(UREGS_R12_fiq, struct cpu_user_regs, r12_fiq);
+
+   OFFSET(UREGS_kernel_sizeof, struct cpu_user_regs, cpsr);
+   DEFINE(UREGS_user_sizeof, sizeof(struct cpu_user_regs));
+   BLANK();
+
+   DEFINE(CPUINFO_sizeof, sizeof(struct cpu_info));
+}
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/arch/arm/dummy.S b/xen/arch/arm/dummy.S
new file mode 100644
index 0000000..5bc4f21
--- /dev/null
+++ b/xen/arch/arm/dummy.S
@@ -0,0 +1,72 @@
+/* Nothing is mapped at 1G, for the moment */
+#define DUMMY(x) \
+	.globl x; \
+x:	.word 0xe7f000f0
+/* x:	mov r0, #0x40000000 ; str r0, [r0]; b x */
+
+#define  NOP(x) \
+	.globl x; \
+x:	mov pc, lr
+	
+DUMMY(alloc_pirq_struct);
+DUMMY(alloc_vcpu_guest_context);
+DUMMY(arch_do_domctl);
+DUMMY(arch_do_sysctl);
+DUMMY(arch_do_vcpu_op);
+DUMMY(arch_get_info_guest);
+DUMMY(arch_get_xen_caps);
+DUMMY(arch_memory_op);
+DUMMY(arch_set_info_guest);
+DUMMY(arch_vcpu_reset);
+DUMMY(create_grant_host_mapping);
+DUMMY(__cpu_die);
+DUMMY(__cpu_disable);
+DUMMY(__cpu_up);
+DUMMY(do_get_pm_info);
+DUMMY(domain_get_maximum_gpfn);
+DUMMY(domain_relinquish_resources);
+DUMMY(domain_set_time_offset);
+DUMMY(dom_cow);
+DUMMY(donate_page);
+DUMMY(do_pm_op);
+DUMMY(flush_tlb_mask);
+DUMMY(free_vcpu_guest_context);
+DUMMY(get_page);
+DUMMY(get_page_type);
+DUMMY(gmfn_to_mfn);
+DUMMY(gnttab_clear_flag);
+DUMMY(gnttab_host_mapping_get_page_type);
+DUMMY(gnttab_mark_dirty);
+DUMMY(hypercall_create_continuation);
+DUMMY(iommu_map_page);
+DUMMY(iommu_unmap_page);
+DUMMY(is_iomem_page);
+DUMMY(local_event_delivery_enable);
+DUMMY(local_events_need_delivery);
+DUMMY(machine_to_phys_mapping_valid);
+DUMMY(max_page);
+DUMMY(node_online_map);
+DUMMY(nr_irqs_gsi);
+DUMMY(p2m_pod_decrease_reservation);
+DUMMY(guest_physmap_mark_populate_on_demand);
+DUMMY(page_get_owner_and_reference);
+DUMMY(page_is_ram_type);
+DUMMY(per_cpu__cpu_core_mask);
+DUMMY(per_cpu__cpu_sibling_mask);
+DUMMY(__per_cpu_offset);
+DUMMY(pirq_guest_bind);
+DUMMY(pirq_guest_unbind);
+DUMMY(pirq_set_affinity);
+DUMMY(put_page);
+DUMMY(put_page_type);
+DUMMY(replace_grant_host_mapping);
+DUMMY(send_timer_event);
+DUMMY(share_xen_page_with_privileged_guests);
+DUMMY(smp_send_state_dump);
+DUMMY(steal_page);
+DUMMY(sync_vcpu_execstate);
+DUMMY(__udelay);
+NOP(update_vcpu_system_time);
+DUMMY(vcpu_mark_events_pending);
+DUMMY(vcpu_show_execution_state);
+DUMMY(wallclock_time);
diff --git a/xen/arch/arm/entry.S b/xen/arch/arm/entry.S
new file mode 100644
index 0000000..16a8f36
--- /dev/null
+++ b/xen/arch/arm/entry.S
@@ -0,0 +1,107 @@
+#include <xen/config.h>
+#include <asm/asm_defns.h>
+
+#define SAVE_ONE_BANKED(reg)	mrs r11, reg; str r11, [sp, #UREGS_##reg]
+#define RESTORE_ONE_BANKED(reg)	ldr r11, [sp, #UREGS_##reg]; msr reg, r11
+
+#define SAVE_BANKED(mode) \
+	SAVE_ONE_BANKED(SP_##mode) ; SAVE_ONE_BANKED(LR_##mode) ; SAVE_ONE_BANKED(SPSR_##mode)
+
+#define RESTORE_BANKED(mode) \
+	RESTORE_ONE_BANKED(SP_##mode) ; RESTORE_ONE_BANKED(LR_##mode) ; RESTORE_ONE_BANKED(SPSR_##mode)
+
+#define SAVE_ALL											\
+	sub sp, #(UREGS_R8_fiq - UREGS_sp); /* SP, LR, SPSR, PC */					\
+	push {r0-r12}; /* Save R0-R12 */								\
+													\
+	mrs r11, ELR_hyp;		/* ELR_hyp is return address. */				\
+	str r11, [sp, #UREGS_pc];									\
+													\
+	str lr, [sp, #UREGS_lr];									\
+													\
+	add r11, sp, #UREGS_kernel_sizeof+4;								\
+	str r11, [sp, #UREGS_sp];									\
+													\
+	mrs r11, SPSR_hyp;										\
+	str r11, [sp, #UREGS_cpsr];									\
+	and r11, #PSR_MODE_MASK;									\
+	cmp r11, #PSR_MODE_HYP;										\
+	blne save_guest_regs
+
+save_guest_regs:
+	ldr r11, [sp, #UREGS_lr]
+	str r11, [sp, #UREGS_LR_usr]
+	ldr r11, =0xffffffff  /* Clobber SP which is only valid for hypervisor frames. */
+	str r11, [sp, #UREGS_sp]
+	SAVE_ONE_BANKED(SP_usr)
+	SAVE_BANKED(svc)
+	SAVE_BANKED(abt)
+	SAVE_BANKED(und)
+	SAVE_BANKED(irq)
+	SAVE_BANKED(fiq)
+	SAVE_ONE_BANKED(R8_fiq); SAVE_ONE_BANKED(R9_fiq); SAVE_ONE_BANKED(R10_fiq)
+	SAVE_ONE_BANKED(R11_fiq); SAVE_ONE_BANKED(R12_fiq);
+	mov pc, lr
+
+#define DEFINE_TRAP_ENTRY(trap)										\
+	ALIGN;												\
+trap_##trap:												\
+	SAVE_ALL;											\
+	adr lr, return_from_trap;									\
+	mov r0, sp;											\
+	mov r11, sp;											\
+	bic sp, #7; /* Align the stack pointer (noop on guest trap) */					\
+	b do_trap_##trap
+
+.globl hyp_traps_vector
+	.align 5
+hyp_traps_vector:
+	.word 0				/* 0x00 - Reset */
+	b trap_undefined_instruction	/* 0x04 - Undefined Instruction */
+	b trap_supervisor_call		/* 0x08 - Supervisor Call */
+	b trap_prefetch_abort		/* 0x0c - Prefetch Abort */
+	b trap_data_abort		/* 0x10 - Data Abort */
+	b trap_hypervisor		/* 0x14 - Hypervisor */
+	b trap_irq			/* 0x18 - IRQ */
+	b trap_fiq			/* 0x1c - FIQ */
+
+DEFINE_TRAP_ENTRY(undefined_instruction)
+DEFINE_TRAP_ENTRY(supervisor_call)
+DEFINE_TRAP_ENTRY(prefetch_abort)
+DEFINE_TRAP_ENTRY(data_abort)
+DEFINE_TRAP_ENTRY(hypervisor)
+DEFINE_TRAP_ENTRY(irq)
+DEFINE_TRAP_ENTRY(fiq)
+
+ENTRY(return_from_trap)
+	ldr r11, [sp, #UREGS_cpsr]
+	and r11, #PSR_MODE_MASK
+	cmp r11, #PSR_MODE_HYP
+	beq return_to_hypervisor
+
+ENTRY(return_to_guest)
+	mov r11, sp
+	bic sp, #7 /* Align the stack pointer */
+	bl leave_hypervisor_tail
+	ldr r11, [sp, #UREGS_pc]
+	msr ELR_hyp, r11
+	ldr r11, [sp, #UREGS_cpsr]
+	msr SPSR_hyp, r11
+	RESTORE_ONE_BANKED(SP_usr)
+	RESTORE_BANKED(svc)
+	RESTORE_BANKED(abt)
+	RESTORE_BANKED(und)
+	RESTORE_BANKED(irq)
+	RESTORE_BANKED(fiq)
+	RESTORE_ONE_BANKED(R8_fiq); RESTORE_ONE_BANKED(R9_fiq); RESTORE_ONE_BANKED(R10_fiq)
+	RESTORE_ONE_BANKED(R11_fiq); RESTORE_ONE_BANKED(R12_fiq);
+	ldr lr, [sp, #UREGS_LR_usr]
+	pop {r0-r12}
+	add sp, #(UREGS_R8_fiq - UREGS_sp); /* SP, LR, SPSR, PC */
+	eret
+
+ENTRY(return_to_hypervisor)
+	ldr lr, [sp, #UREGS_lr]
+	pop {r0-r12}
+	add sp, #(UREGS_R8_fiq - UREGS_sp); /* SP, LR, SPSR, PC */
+	eret
diff --git a/xen/arch/arm/head.S b/xen/arch/arm/head.S
new file mode 100644
index 0000000..b98c921
--- /dev/null
+++ b/xen/arch/arm/head.S
@@ -0,0 +1,298 @@
+/*
+ * xen/arch/arm/head.S
+ *
+ * Start-of-day code for an ARMv7-A with virt extensions.
+ *
+ * Tim Deegan <tim@xen.org>
+ * Copyright (c) 2011 Citrix Systems.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include <asm/config.h>
+#include <asm/page.h>
+#include <asm/asm_defns.h>
+
+
+/* Macro to print a string to the UART, if there is one.
+ * Clobbers r0-r3. */
+#ifdef EARLY_UART_ADDRESS
+#define PRINT(_s)       \
+	adr   r0, 98f ; \
+	bl    puts    ; \
+	b     99f     ; \
+98:	.asciz _s     ; \
+	.align 2      ; \
+99:
+#else
+#define PRINT(s)
+#endif
+
+	.arm
+
+	/* This must be the very first address in the loaded image.
+	 * It should be linked at XEN_VIRT_START, and loaded at any
+	 * 2MB-aligned address.  All of text+data+bss must fit in 2MB,
+	 * or the initial pagetable code below will need adjustment. */
+	.global start
+start:
+	cpsid aif                    /* Disable all interrupts */
+
+	/* Save the bootloader arguments in less-clobberable registers */
+	mov   r7, r1                 /* r7 := ARM-linux machine type */
+	mov   r8, r2                 /* r8 := ATAG base address */
+
+	/* Find out where we are */
+	ldr   r0, =start
+	adr   r9, start              /* r9  := paddr (start) */
+	sub   r10, r9, r0            /* r10 := phys-offset */
+
+#ifdef EARLY_UART_ADDRESS
+	/* Say hello */
+	ldr   r11, =EARLY_UART_ADDRESS  /* r11 := UART base address */
+	bl    init_uart
+#endif
+
+	/* Check that this CPU has Hyp mode */
+	mrc   CP32(r0, ID_PFR1)
+	and   r0, r0, #0xf000        /* Bits 12-15 define virt extensions */
+	teq   r0, #0x1000            /* Must == 0x1 or may be incompatible */
+	beq   1f
+	bl    putn
+	PRINT("- CPU doesn't support the virtualization extensions -\r\n")
+	b     fail
+1:
+	/* Check if we're already in it */
+	mrs   r0, cpsr
+	and   r0, r0, #0x1f          /* Mode is in the low 5 bits of CPSR */
+	teq   r0, #0x1a              /* Hyp Mode? */
+	bne   1f
+	PRINT("- Started in Hyp mode -\r\n")
+	b     hyp
+1:
+	/* Otherwise, it must have been Secure Supervisor mode */
+	mrc   CP32(r0, SCR)
+	tst   r0, #0x1               /* Not-Secure bit set? */
+	beq   1f
+	PRINT("- CPU is not in Hyp mode or Secure state -\r\n")
+	b     fail
+1:
+	/* OK, we're in Secure state. */
+	PRINT("- Started in Secure state -\r\n- Entering Hyp mode -\r\n")
+
+	/* Dance into Hyp mode */
+	cpsid aif, #0x16             /* Enter Monitor mode */
+	mrc   CP32(r0, SCR)
+	orr   r0, r0, #0x100         /* Set HCE */
+	orr   r0, r0, #0xb1          /* Set SCD, AW, FW and NS */
+	bic   r0, r0, #0xe           /* Clear EA, FIQ and IRQ */
+	mcr   CP32(r0, SCR)
+	/* Ugly: the system timer's frequency register is only
+	 * programmable in Secure state.  Since we don't know where its
+	 * memory-mapped control registers live, we can't find out the
+	 * right frequency.  Use the VE model's default frequency here. */
+	ldr   r0, =0x5f5e100         /* 100 MHz */
+	mcr   CP32(r0, CNTFRQ)
+	ldr   r0, =0x40c00           /* SMP, c11, c10 in non-secure mode */
+	mcr   CP32(r0, NSACR)
+	/* Continuing ugliness: Set up the GIC so NS state owns interrupts */
+	mov   r0, #GIC_BASE_ADDRESS
+	add   r0, r0, #GIC_DR_OFFSET
+	mov   r1, #0
+	str   r1, [r0]               /* Disable delivery in the distributor */
+	add   r0, r0, #0x80          /* GICD_IGROUP0 */
+	mov   r2, #0xffffffff        /* All interrupts to group 1 */
+	str   r2, [r0]
+	str   r2, [r0, #4]
+	str   r2, [r0, #8]
+	/* Must drop priority mask below 0x80 before entering NS state */
+	mov   r0, #GIC_BASE_ADDRESS
+	add   r0, r0, #GIC_CR_OFFSET
+	ldr   r1, =0xff
+	str   r1, [r0, #0x4]         /* -> GICC_PMR */
+	/* Reset a few config registers */
+	mov   r0, #0
+	mcr   CP32(r0, FCSEIDR)
+	mcr   CP32(r0, CONTEXTIDR)
+	/* FIXME: ought to reset some other NS control regs here */
+	adr   r1, 1f
+	adr   r0, hyp                /* Store paddr (hyp entry point) */
+	str   r0, [r1]               /* where we can use it for RFE */
+	isb                          /* Ensure we see the stored target address */
+	rfeia r1                     /* Enter Hyp mode */
+
+1:	.word 0                      /* PC to enter Hyp mode at */
+	.word 0x000001da             /* CPSR: LE, Abort/IRQ/FIQ off, Hyp */
+
+hyp:
+	PRINT("- Setting up control registers -\r\n")
+
+	/* Set up memory attribute type tables */
+	ldr   r0, =MAIR0VAL
+	ldr   r1, =MAIR1VAL
+	mcr   CP32(r0, MAIR0)
+	mcr   CP32(r1, MAIR1)
+	mcr   CP32(r0, HMAIR0)
+	mcr   CP32(r1, HMAIR1)
+
+	/* Set up the HTCR:
+	 * PT walks use Outer-Shareable accesses,
+	 * PT walks are write-back, no-write-allocate in both cache levels,
+	 * Full 32-bit address space goes through this table. */
+	ldr   r0, =0x80002500
+	mcr   CP32(r0, HTCR)
+
+	/* Set up the HSCTLR:
+	 * Exceptions in LE ARM,
+	 * Low-latency IRQs disabled,
+	 * Write-implies-XN disabled (for now),
+	 * I-cache and d-cache enabled,
+	 * Alignment checking enabled,
+	 * MMU translation disabled (for now). */
+	ldr   r0, =(HSCTLR_BASE|SCTLR_A|SCTLR_C)
+	mcr   CP32(r0, HSCTLR)
+
+	/* Write Xen's PT's paddr into the HTTBR */
+	ldr   r4, =xen_pgtable
+	add   r4, r4, r10            /* r4 := paddr (xen_pagetable) */
+	mov   r5, #0                 /* r4:r5 is paddr (xen_pagetable) */
+	mcrr  CP64(r4, r5, HTTBR)
+
+	/* Build the baseline idle pagetable's first-level entries */
+	ldr   r1, =xen_second
+	add   r1, r1, r10            /* r1 := paddr (xen_second) */
+	mov   r3, #0x0
+	orr   r2, r1, #0xe00         /* r2:r3 := table map of xen_second */
+	orr   r2, r2, #0x07f         /* (+ rights for linear PT) */
+	strd  r2, r3, [r4, #0]       /* Map it in slot 0 */
+	add   r2, r2, #0x1000
+	strd  r2, r3, [r4, #8]       /* Map 2nd page in slot 1 */
+	add   r2, r2, #0x1000
+	strd  r2, r3, [r4, #16]      /* Map 3rd page in slot 2 */
+	add   r2, r2, #0x1000
+	strd  r2, r3, [r4, #24]      /* Map 4th page in slot 3 */
+
+	/* Now set up the second-level entries */
+	orr   r2, r9, #0xe00
+	orr   r2, r2, #0x07d         /* r2:r3 := 2MB normal map of Xen */
+	mov   r4, r9, lsr #18        /* Slot for paddr(start) */
+	strd  r2, r3, [r1, r4]       /* Map Xen there */
+	ldr   r4, =start
+	lsr   r4, #18                /* Slot for vaddr(start) */
+	strd  r2, r3, [r1, r4]       /* Map Xen there too */
+#ifdef EARLY_UART_ADDRESS
+	ldr   r3, =(1<<(54-32))      /* NS for device mapping */
+	lsr   r2, r11, #21
+	lsl   r2, r2, #21            /* 2MB-aligned paddr of UART */
+	orr   r2, r2, #0xe00
+	orr   r2, r2, #0x071         /* r2:r3 := 2MB dev map including UART */
+	add   r4, r4, #8
+	strd  r2, r3, [r1, r4]       /* Map it in the fixmap's slot */
+#endif
+
+	PRINT("- Turning on paging -\r\n")
+
+	ldr   r1, =paging            /* Explicit vaddr, not RIP-relative */
+	mrc   CP32(r0, HSCTLR)
+	orr   r0, r0, #0x1           /* Add in the MMU enable bit */
+	dsb                          /* Flush PTE writes and finish reads */
+	mcr   CP32(r0, HSCTLR)       /* now paging is enabled */
+	isb                          /* Now, flush the icache */
+	mov   pc, r1                 /* Get a proper vaddr into PC */
+paging:
+
+#ifdef EARLY_UART_ADDRESS
+	/* Recover the UART address in the new address space */
+	lsl   r11, #11
+	lsr   r11, #11               /* UART base's offset from 2MB base */
+	adr   r0, start
+	add   r0, r0, #0x200000      /* vaddr of the fixmap's 2MB slot */
+	add   r11, r11, r0           /* r11 := vaddr (UART base address) */
+#endif
+
+	PRINT("- Entering C -\r\n")
+
+	ldr   sp, =init_stack        /* Supply a stack */
+	add   sp, #STACK_SIZE        /* (which grows down from the top). */
+	sub   sp, #CPUINFO_sizeof    /* Make room for CPU save record */
+	mov   r0, r10                /* Marshal args: - phys_offset */
+	mov   r1, r7                 /*               - machine type */
+	mov   r2, r8                 /*               - ATAG address */
+	b     start_xen              /* and disappear into the land of C */
+
+/* Fail-stop
+ * r0: string explaining why */
+fail:	PRINT("- Boot failed -\r\n")
+1:	wfe
+	b     1b
+
+#ifdef EARLY_UART_ADDRESS
+
+/* Bring up the UART. Specific to the PL011 UART.
+ * Clobbers r0-r2 */
+init_uart:
+	mov   r1, #0x0
+	str   r1, [r11, #0x24]       /* -> UARTIBRD (Baud divisor fraction) */
+	mov   r1, #0x4               /* 7.3728MHz / 0x4 == 16 * 115200 */
+	str   r1, [r11, #0x24]       /* -> UARTIBRD (Baud divisor integer) */
+	mov   r1, #0x60              /* 8n1 */
+	str   r1, [r11, #0x24]       /* -> UARTLCR_H (Line control) */
+	ldr   r1, =0x00000301        /* RXE | TXE | UARTEN */
+	str   r1, [r11, #0x30]       /* -> UARTCR (Control Register) */
+	adr   r0, 1f
+	b     puts
+1:	.asciz "- UART enabled -\r\n"
+	.align 4
+
+/* Print early debug messages.  Specific to the PL011 UART.
+ * r0: Nul-terminated string to print.
+ * Clobbers r0-r2 */
+puts:
+	ldr   r2, [r11, #0x18]       /* <- UARTFR (Flag register) */
+	tst   r2, #0x8               /* Check BUSY bit */
+	bne   puts                   /* Wait for the UART to be ready */
+	ldrb  r2, [r0], #1           /* Load next char */
+	teq   r2, #0                 /* Exit on nul*/
+	moveq pc, lr
+	str   r2, [r11]              /* -> UARTDR (Data Register) */
+	b     puts
+
+/* Print a 32-bit number in hex.  Specific to the PL011 UART.
+ * r0: Number to print.
+ * clobbers r0-r3 */
+putn:
+	adr   r1, hex
+	mov   r3, #8
+1:	ldr   r2, [r11, #0x18]       /* <- UARTFR (Flag register) */
+	tst   r2, #0x8               /* Check BUSY bit */
+	bne   1b                     /* Wait for the UART to be ready */
+	and   r2, r0, #0xf0000000    /* Mask off the top nybble */
+	ldrb  r2, [r1, r2, lsr #28]  /* Convert to a char */
+	str   r2, [r11]              /* -> UARTDR (Data Register) */
+	lsl   r0, #4                 /* Roll it through one nybble at a time */
+	subs  r3, r3, #1
+	bne   1b
+	adr   r0, crlf               /* Finish with a newline */
+	b     puts
+
+crlf:	.asciz "\r\n"
+hex:	.ascii "0123456789abcdef"
+	.align 2
+
+#else  /* EARLY_UART_ADDRESS */
+
+init_uart:
+.global early_puts
+early_puts:
+puts:
+putn:	mov   pc, lr
+
+#endif /* EARLY_UART_ADDRESS */
diff --git a/xen/arch/arm/xen.lds.S b/xen/arch/arm/xen.lds.S
new file mode 100644
index 0000000..5a62e2c
--- /dev/null
+++ b/xen/arch/arm/xen.lds.S
@@ -0,0 +1,141 @@
+/* Excerpts written by Martin Mares <mj@atrey.karlin.mff.cuni.cz> */
+/* Modified for i386/x86-64 Xen by Keir Fraser */
+/* Modified for ARM Xen by Ian Campbell */
+
+#include <xen/config.h>
+#include <xen/cache.h>
+#include <asm/page.h>
+#include <asm/percpu.h>
+#undef ENTRY
+#undef ALIGN
+
+ENTRY(start)
+
+OUTPUT_ARCH(arm)
+
+PHDRS
+{
+  text PT_LOAD /* XXX should be AT ( XEN_PHYS_START ) */ ;
+}
+SECTIONS
+{
+  . = XEN_VIRT_START;
+  _start = .;
+  .text : /* XXX should be AT ( XEN_PHYS_START ) */ {
+        _stext = .;            /* Text section */
+       *(.text)
+       *(.fixup)
+       *(.gnu.warning)
+       _etext = .;             /* End of text section */
+  } :text = 0x9090
+
+  . = ALIGN(PAGE_SIZE);
+  .rodata : {
+        _srodata = .;          /* Read-only data */
+       *(.rodata)
+       *(.rodata.*)
+        _erodata = .;          /* End of read-only data */
+  } :text
+
+  .data : {                    /* Data */
+       . = ALIGN(PAGE_SIZE);
+       *(.data.page_aligned)
+       *(.data)
+       *(.data.rel)
+       *(.data.rel.*)
+       CONSTRUCTORS
+  } :text
+
+  . = ALIGN(SMP_CACHE_BYTES);
+  .data.read_mostly : {
+       /* Exception table */
+       __start___ex_table = .;
+       *(.ex_table)
+       __stop___ex_table = .;
+
+       /* Pre-exception table */
+       __start___pre_ex_table = .;
+       *(.ex_table.pre)
+       __stop___pre_ex_table = .;
+
+       *(.data.read_mostly)
+       *(.data.rel.ro)
+       *(.data.rel.ro.*)
+  } :text
+
+#ifdef LOCK_PROFILE
+  . = ALIGN(32);
+  __lock_profile_start = .;
+  .lockprofile.data : { *(.lockprofile.data) } :text
+  __lock_profile_end = .;
+#endif
+
+  . = ALIGN(PAGE_SIZE);             /* Init code and data */
+  __init_begin = .;
+  .init.text : {
+       _sinittext = .;
+       *(.init.text)
+       _einittext = .;
+  } :text
+  . = ALIGN(PAGE_SIZE);
+  .init.data : {
+       *(.init.rodata)
+       *(.init.rodata.str*)
+       *(.init.data)
+       *(.init.data.rel)
+       *(.init.data.rel.*)
+  } :text
+  . = ALIGN(32);
+  .init.setup : {
+       __setup_start = .;
+       *(.init.setup)
+       __setup_end = .;
+  } :text
+  .initcall.init : {
+       __initcall_start = .;
+       *(.initcallpresmp.init)
+       __presmp_initcall_end = .;
+       *(.initcall1.init)
+       __initcall_end = .;
+  } :text
+  .xsm_initcall.init : {
+       __xsm_initcall_start = .;
+       *(.xsm_initcall.init)
+       __xsm_initcall_end = .;
+  } :text
+  . = ALIGN(STACK_SIZE);
+  __init_end = .;
+
+  .bss : {                     /* BSS */
+       __bss_start = .;
+       *(.bss.stack_aligned)
+       . = ALIGN(PAGE_SIZE);
+       *(.bss.page_aligned)
+       *(.bss)
+       . = ALIGN(SMP_CACHE_BYTES);
+       __per_cpu_start = .;
+       *(.bss.percpu)
+       . = ALIGN(SMP_CACHE_BYTES);
+       *(.bss.percpu.read_mostly)
+       . = ALIGN(SMP_CACHE_BYTES);
+       __per_cpu_data_end = .;
+  } :text
+  _end = . ;
+
+  /* Sections to be discarded */
+  /DISCARD/ : {
+       *(.exit.text)
+       *(.exit.data)
+       *(.exitcall.exit)
+       *(.eh_frame)
+  }
+
+  /* Stabs debugging sections.  */
+  .stab 0 : { *(.stab) }
+  .stabstr 0 : { *(.stabstr) }
+  .stab.excl 0 : { *(.stab.excl) }
+  .stab.exclstr 0 : { *(.stab.exclstr) }
+  .stab.index 0 : { *(.stab.index) }
+  .stab.indexstr 0 : { *(.stab.indexstr) }
+  .comment 0 : { *(.comment) }
+}
diff --git a/xen/include/asm-arm/asm_defns.h b/xen/include/asm-arm/asm_defns.h
new file mode 100644
index 0000000..c59fb6c
--- /dev/null
+++ b/xen/include/asm-arm/asm_defns.h
@@ -0,0 +1,18 @@
+#ifndef __ARM_ASM_DEFNS_H__
+#define __ARM_ASM_DEFNS_H__
+
+#ifndef COMPILE_OFFSETS
+/* NB. Auto-generated from arch/.../asm-offsets.c */
+#include <asm/asm-offsets.h>
+#endif
+#include <asm/processor.h>
+
+#endif /* __ARM_ASM_DEFNS_H__ */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 18:20:39 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 18:20:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXzd4-0007zw-6z; Tue, 06 Dec 2011 18:20:34 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RXzd3-0007vp-0W
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 18:20:33 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1323195555!51363960!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMzAwOTc=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4130 invoked from network); 6 Dec 2011 18:19:16 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Dec 2011 18:19:16 -0000
X-IronPort-AV: E=Sophos;i="4.71,307,1320642000"; d="scan'208";a="173120754"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Dec 2011 13:19:48 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Tue, 6 Dec 2011 13:19:47 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pB6IJEjM019549;
	Tue, 6 Dec 2011 10:19:31 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Tue, 6 Dec 2011 18:19:56 +0000
Message-ID: <1323195609-17277-12-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1112061753410.31179@kaball-desktop>
References: <alpine.DEB.2.00.1112061753410.31179@kaball-desktop>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>, Tim.Deegan@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH RFC 12/25] arm: entry.S and head.S
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Low level assembly routines, including entry.S and head.S.
Also the linker script and a collection of dummy functions that we plan
to reduce to zero as soon as possible.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
---
 xen/arch/arm/Makefile           |    5 +-
 xen/arch/arm/asm-offsets.c      |   76 ++++++++++
 xen/arch/arm/dummy.S            |   72 ++++++++++
 xen/arch/arm/entry.S            |  107 ++++++++++++++
 xen/arch/arm/head.S             |  298 +++++++++++++++++++++++++++++++++++++++
 xen/arch/arm/xen.lds.S          |  141 ++++++++++++++++++
 xen/include/asm-arm/asm_defns.h |   18 +++
 7 files changed, 716 insertions(+), 1 deletions(-)
 create mode 100644 xen/arch/arm/asm-offsets.c
 create mode 100644 xen/arch/arm/dummy.S
 create mode 100644 xen/arch/arm/entry.S
 create mode 100644 xen/arch/arm/head.S
 create mode 100644 xen/arch/arm/xen.lds.S
 create mode 100644 xen/include/asm-arm/asm_defns.h

diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index fd86cb0..6a250f1 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -1,8 +1,11 @@
 subdir-y += lib
 
+obj-y += dummy.o
+obj-y += entry.o
+
 #obj-bin-y += ....o
 
-ALL_OBJS := $(ALL_OBJS)
+ALL_OBJS := head.o $(ALL_OBJS)
 
 $(TARGET): $(TARGET)-syms
 	# XXX: VE model loads by VMA so instead of
diff --git a/xen/arch/arm/asm-offsets.c b/xen/arch/arm/asm-offsets.c
new file mode 100644
index 0000000..ee5d5d4
--- /dev/null
+++ b/xen/arch/arm/asm-offsets.c
@@ -0,0 +1,76 @@
+/*
+ * Generate definitions needed by assembly language modules.
+ * This code generates raw asm output which is post-processed
+ * to extract and format the required data.
+ */
+#define COMPILE_OFFSETS
+
+#include <xen/config.h>
+#include <xen/types.h>
+#include <public/xen.h>
+#include <asm/current.h>
+
+#define DEFINE(_sym, _val) \
+    __asm__ __volatile__ ( "\n->" #_sym " %0 " #_val : : "i" (_val) )
+#define BLANK() \
+    __asm__ __volatile__ ( "\n->" : : )
+#define OFFSET(_sym, _str, _mem) \
+    DEFINE(_sym, offsetof(_str, _mem));
+
+/* base-2 logarithm */
+#define __L2(_x)  (((_x) & 0x00000002) ?   1 : 0)
+#define __L4(_x)  (((_x) & 0x0000000c) ? ( 2 + __L2( (_x)>> 2)) : __L2( _x))
+#define __L8(_x)  (((_x) & 0x000000f0) ? ( 4 + __L4( (_x)>> 4)) : __L4( _x))
+#define __L16(_x) (((_x) & 0x0000ff00) ? ( 8 + __L8( (_x)>> 8)) : __L8( _x))
+#define LOG_2(_x) (((_x) & 0xffff0000) ? (16 + __L16((_x)>>16)) : __L16(_x))
+
+void __dummy__(void)
+{
+   OFFSET(UREGS_sp, struct cpu_user_regs, sp);
+   OFFSET(UREGS_lr, struct cpu_user_regs, lr);
+   OFFSET(UREGS_pc, struct cpu_user_regs, pc);
+   OFFSET(UREGS_cpsr, struct cpu_user_regs, cpsr);
+
+   OFFSET(UREGS_LR_usr, struct cpu_user_regs, lr_usr);
+   OFFSET(UREGS_SP_usr, struct cpu_user_regs, sp_usr);
+
+   OFFSET(UREGS_SP_svc, struct cpu_user_regs, sp_svc);
+   OFFSET(UREGS_LR_svc, struct cpu_user_regs, lr_svc);
+   OFFSET(UREGS_SPSR_svc, struct cpu_user_regs, spsr_svc);
+
+   OFFSET(UREGS_SP_abt, struct cpu_user_regs, sp_abt);
+   OFFSET(UREGS_LR_abt, struct cpu_user_regs, lr_abt);
+   OFFSET(UREGS_SPSR_abt, struct cpu_user_regs, spsr_abt);
+
+   OFFSET(UREGS_SP_und, struct cpu_user_regs, sp_und);
+   OFFSET(UREGS_LR_und, struct cpu_user_regs, lr_und);
+   OFFSET(UREGS_SPSR_und, struct cpu_user_regs, spsr_und);
+
+   OFFSET(UREGS_SP_irq, struct cpu_user_regs, sp_irq);
+   OFFSET(UREGS_LR_irq, struct cpu_user_regs, lr_irq);
+   OFFSET(UREGS_SPSR_irq, struct cpu_user_regs, spsr_irq);
+
+   OFFSET(UREGS_SP_fiq, struct cpu_user_regs, sp_fiq);
+   OFFSET(UREGS_LR_fiq, struct cpu_user_regs, lr_fiq);
+   OFFSET(UREGS_SPSR_fiq, struct cpu_user_regs, spsr_fiq);
+
+   OFFSET(UREGS_R8_fiq, struct cpu_user_regs, r8_fiq);
+   OFFSET(UREGS_R9_fiq, struct cpu_user_regs, r9_fiq);
+   OFFSET(UREGS_R10_fiq, struct cpu_user_regs, r10_fiq);
+   OFFSET(UREGS_R11_fiq, struct cpu_user_regs, r11_fiq);
+   OFFSET(UREGS_R12_fiq, struct cpu_user_regs, r12_fiq);
+
+   OFFSET(UREGS_kernel_sizeof, struct cpu_user_regs, cpsr);
+   DEFINE(UREGS_user_sizeof, sizeof(struct cpu_user_regs));
+   BLANK();
+
+   DEFINE(CPUINFO_sizeof, sizeof(struct cpu_info));
+}
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/arch/arm/dummy.S b/xen/arch/arm/dummy.S
new file mode 100644
index 0000000..5bc4f21
--- /dev/null
+++ b/xen/arch/arm/dummy.S
@@ -0,0 +1,72 @@
+/* Nothing is mapped at 1G, for the moment */
+#define DUMMY(x) \
+	.globl x; \
+x:	.word 0xe7f000f0
+/* x:	mov r0, #0x40000000 ; str r0, [r0]; b x */
+
+#define  NOP(x) \
+	.globl x; \
+x:	mov pc, lr
+	
+DUMMY(alloc_pirq_struct);
+DUMMY(alloc_vcpu_guest_context);
+DUMMY(arch_do_domctl);
+DUMMY(arch_do_sysctl);
+DUMMY(arch_do_vcpu_op);
+DUMMY(arch_get_info_guest);
+DUMMY(arch_get_xen_caps);
+DUMMY(arch_memory_op);
+DUMMY(arch_set_info_guest);
+DUMMY(arch_vcpu_reset);
+DUMMY(create_grant_host_mapping);
+DUMMY(__cpu_die);
+DUMMY(__cpu_disable);
+DUMMY(__cpu_up);
+DUMMY(do_get_pm_info);
+DUMMY(domain_get_maximum_gpfn);
+DUMMY(domain_relinquish_resources);
+DUMMY(domain_set_time_offset);
+DUMMY(dom_cow);
+DUMMY(donate_page);
+DUMMY(do_pm_op);
+DUMMY(flush_tlb_mask);
+DUMMY(free_vcpu_guest_context);
+DUMMY(get_page);
+DUMMY(get_page_type);
+DUMMY(gmfn_to_mfn);
+DUMMY(gnttab_clear_flag);
+DUMMY(gnttab_host_mapping_get_page_type);
+DUMMY(gnttab_mark_dirty);
+DUMMY(hypercall_create_continuation);
+DUMMY(iommu_map_page);
+DUMMY(iommu_unmap_page);
+DUMMY(is_iomem_page);
+DUMMY(local_event_delivery_enable);
+DUMMY(local_events_need_delivery);
+DUMMY(machine_to_phys_mapping_valid);
+DUMMY(max_page);
+DUMMY(node_online_map);
+DUMMY(nr_irqs_gsi);
+DUMMY(p2m_pod_decrease_reservation);
+DUMMY(guest_physmap_mark_populate_on_demand);
+DUMMY(page_get_owner_and_reference);
+DUMMY(page_is_ram_type);
+DUMMY(per_cpu__cpu_core_mask);
+DUMMY(per_cpu__cpu_sibling_mask);
+DUMMY(__per_cpu_offset);
+DUMMY(pirq_guest_bind);
+DUMMY(pirq_guest_unbind);
+DUMMY(pirq_set_affinity);
+DUMMY(put_page);
+DUMMY(put_page_type);
+DUMMY(replace_grant_host_mapping);
+DUMMY(send_timer_event);
+DUMMY(share_xen_page_with_privileged_guests);
+DUMMY(smp_send_state_dump);
+DUMMY(steal_page);
+DUMMY(sync_vcpu_execstate);
+DUMMY(__udelay);
+NOP(update_vcpu_system_time);
+DUMMY(vcpu_mark_events_pending);
+DUMMY(vcpu_show_execution_state);
+DUMMY(wallclock_time);
diff --git a/xen/arch/arm/entry.S b/xen/arch/arm/entry.S
new file mode 100644
index 0000000..16a8f36
--- /dev/null
+++ b/xen/arch/arm/entry.S
@@ -0,0 +1,107 @@
+#include <xen/config.h>
+#include <asm/asm_defns.h>
+
+#define SAVE_ONE_BANKED(reg)	mrs r11, reg; str r11, [sp, #UREGS_##reg]
+#define RESTORE_ONE_BANKED(reg)	ldr r11, [sp, #UREGS_##reg]; msr reg, r11
+
+#define SAVE_BANKED(mode) \
+	SAVE_ONE_BANKED(SP_##mode) ; SAVE_ONE_BANKED(LR_##mode) ; SAVE_ONE_BANKED(SPSR_##mode)
+
+#define RESTORE_BANKED(mode) \
+	RESTORE_ONE_BANKED(SP_##mode) ; RESTORE_ONE_BANKED(LR_##mode) ; RESTORE_ONE_BANKED(SPSR_##mode)
+
+#define SAVE_ALL											\
+	sub sp, #(UREGS_R8_fiq - UREGS_sp); /* SP, LR, SPSR, PC */					\
+	push {r0-r12}; /* Save R0-R12 */								\
+													\
+	mrs r11, ELR_hyp;		/* ELR_hyp is return address. */				\
+	str r11, [sp, #UREGS_pc];									\
+													\
+	str lr, [sp, #UREGS_lr];									\
+													\
+	add r11, sp, #UREGS_kernel_sizeof+4;								\
+	str r11, [sp, #UREGS_sp];									\
+													\
+	mrs r11, SPSR_hyp;										\
+	str r11, [sp, #UREGS_cpsr];									\
+	and r11, #PSR_MODE_MASK;									\
+	cmp r11, #PSR_MODE_HYP;										\
+	blne save_guest_regs
+
+save_guest_regs:
+	ldr r11, [sp, #UREGS_lr]
+	str r11, [sp, #UREGS_LR_usr]
+	ldr r11, =0xffffffff  /* Clobber SP which is only valid for hypervisor frames. */
+	str r11, [sp, #UREGS_sp]
+	SAVE_ONE_BANKED(SP_usr)
+	SAVE_BANKED(svc)
+	SAVE_BANKED(abt)
+	SAVE_BANKED(und)
+	SAVE_BANKED(irq)
+	SAVE_BANKED(fiq)
+	SAVE_ONE_BANKED(R8_fiq); SAVE_ONE_BANKED(R9_fiq); SAVE_ONE_BANKED(R10_fiq)
+	SAVE_ONE_BANKED(R11_fiq); SAVE_ONE_BANKED(R12_fiq);
+	mov pc, lr
+
+#define DEFINE_TRAP_ENTRY(trap)										\
+	ALIGN;												\
+trap_##trap:												\
+	SAVE_ALL;											\
+	adr lr, return_from_trap;									\
+	mov r0, sp;											\
+	mov r11, sp;											\
+	bic sp, #7; /* Align the stack pointer (noop on guest trap) */					\
+	b do_trap_##trap
+
+.globl hyp_traps_vector
+	.align 5
+hyp_traps_vector:
+	.word 0				/* 0x00 - Reset */
+	b trap_undefined_instruction	/* 0x04 - Undefined Instruction */
+	b trap_supervisor_call		/* 0x08 - Supervisor Call */
+	b trap_prefetch_abort		/* 0x0c - Prefetch Abort */
+	b trap_data_abort		/* 0x10 - Data Abort */
+	b trap_hypervisor		/* 0x14 - Hypervisor */
+	b trap_irq			/* 0x18 - IRQ */
+	b trap_fiq			/* 0x1c - FIQ */
+
+DEFINE_TRAP_ENTRY(undefined_instruction)
+DEFINE_TRAP_ENTRY(supervisor_call)
+DEFINE_TRAP_ENTRY(prefetch_abort)
+DEFINE_TRAP_ENTRY(data_abort)
+DEFINE_TRAP_ENTRY(hypervisor)
+DEFINE_TRAP_ENTRY(irq)
+DEFINE_TRAP_ENTRY(fiq)
+
+ENTRY(return_from_trap)
+	ldr r11, [sp, #UREGS_cpsr]
+	and r11, #PSR_MODE_MASK
+	cmp r11, #PSR_MODE_HYP
+	beq return_to_hypervisor
+
+ENTRY(return_to_guest)
+	mov r11, sp
+	bic sp, #7 /* Align the stack pointer */
+	bl leave_hypervisor_tail
+	ldr r11, [sp, #UREGS_pc]
+	msr ELR_hyp, r11
+	ldr r11, [sp, #UREGS_cpsr]
+	msr SPSR_hyp, r11
+	RESTORE_ONE_BANKED(SP_usr)
+	RESTORE_BANKED(svc)
+	RESTORE_BANKED(abt)
+	RESTORE_BANKED(und)
+	RESTORE_BANKED(irq)
+	RESTORE_BANKED(fiq)
+	RESTORE_ONE_BANKED(R8_fiq); RESTORE_ONE_BANKED(R9_fiq); RESTORE_ONE_BANKED(R10_fiq)
+	RESTORE_ONE_BANKED(R11_fiq); RESTORE_ONE_BANKED(R12_fiq);
+	ldr lr, [sp, #UREGS_LR_usr]
+	pop {r0-r12}
+	add sp, #(UREGS_R8_fiq - UREGS_sp); /* SP, LR, SPSR, PC */
+	eret
+
+ENTRY(return_to_hypervisor)
+	ldr lr, [sp, #UREGS_lr]
+	pop {r0-r12}
+	add sp, #(UREGS_R8_fiq - UREGS_sp); /* SP, LR, SPSR, PC */
+	eret
diff --git a/xen/arch/arm/head.S b/xen/arch/arm/head.S
new file mode 100644
index 0000000..b98c921
--- /dev/null
+++ b/xen/arch/arm/head.S
@@ -0,0 +1,298 @@
+/*
+ * xen/arch/arm/head.S
+ *
+ * Start-of-day code for an ARMv7-A with virt extensions.
+ *
+ * Tim Deegan <tim@xen.org>
+ * Copyright (c) 2011 Citrix Systems.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include <asm/config.h>
+#include <asm/page.h>
+#include <asm/asm_defns.h>
+
+
+/* Macro to print a string to the UART, if there is one.
+ * Clobbers r0-r3. */
+#ifdef EARLY_UART_ADDRESS
+#define PRINT(_s)       \
+	adr   r0, 98f ; \
+	bl    puts    ; \
+	b     99f     ; \
+98:	.asciz _s     ; \
+	.align 2      ; \
+99:
+#else
+#define PRINT(s)
+#endif
+
+	.arm
+
+	/* This must be the very first address in the loaded image.
+	 * It should be linked at XEN_VIRT_START, and loaded at any
+	 * 2MB-aligned address.  All of text+data+bss must fit in 2MB,
+	 * or the initial pagetable code below will need adjustment. */
+	.global start
+start:
+	cpsid aif                    /* Disable all interrupts */
+
+	/* Save the bootloader arguments in less-clobberable registers */
+	mov   r7, r1                 /* r7 := ARM-linux machine type */
+	mov   r8, r2                 /* r8 := ATAG base address */
+
+	/* Find out where we are */
+	ldr   r0, =start
+	adr   r9, start              /* r9  := paddr (start) */
+	sub   r10, r9, r0            /* r10 := phys-offset */
+
+#ifdef EARLY_UART_ADDRESS
+	/* Say hello */
+	ldr   r11, =EARLY_UART_ADDRESS  /* r11 := UART base address */
+	bl    init_uart
+#endif
+
+	/* Check that this CPU has Hyp mode */
+	mrc   CP32(r0, ID_PFR1)
+	and   r0, r0, #0xf000        /* Bits 12-15 define virt extensions */
+	teq   r0, #0x1000            /* Must == 0x1 or may be incompatible */
+	beq   1f
+	bl    putn
+	PRINT("- CPU doesn't support the virtualization extensions -\r\n")
+	b     fail
+1:
+	/* Check if we're already in it */
+	mrs   r0, cpsr
+	and   r0, r0, #0x1f          /* Mode is in the low 5 bits of CPSR */
+	teq   r0, #0x1a              /* Hyp Mode? */
+	bne   1f
+	PRINT("- Started in Hyp mode -\r\n")
+	b     hyp
+1:
+	/* Otherwise, it must have been Secure Supervisor mode */
+	mrc   CP32(r0, SCR)
+	tst   r0, #0x1               /* Not-Secure bit set? */
+	beq   1f
+	PRINT("- CPU is not in Hyp mode or Secure state -\r\n")
+	b     fail
+1:
+	/* OK, we're in Secure state. */
+	PRINT("- Started in Secure state -\r\n- Entering Hyp mode -\r\n")
+
+	/* Dance into Hyp mode */
+	cpsid aif, #0x16             /* Enter Monitor mode */
+	mrc   CP32(r0, SCR)
+	orr   r0, r0, #0x100         /* Set HCE */
+	orr   r0, r0, #0xb1          /* Set SCD, AW, FW and NS */
+	bic   r0, r0, #0xe           /* Clear EA, FIQ and IRQ */
+	mcr   CP32(r0, SCR)
+	/* Ugly: the system timer's frequency register is only
+	 * programmable in Secure state.  Since we don't know where its
+	 * memory-mapped control registers live, we can't find out the
+	 * right frequency.  Use the VE model's default frequency here. */
+	ldr   r0, =0x5f5e100         /* 100 MHz */
+	mcr   CP32(r0, CNTFRQ)
+	ldr   r0, =0x40c00           /* SMP, c11, c10 in non-secure mode */
+	mcr   CP32(r0, NSACR)
+	/* Continuing ugliness: Set up the GIC so NS state owns interrupts */
+	mov   r0, #GIC_BASE_ADDRESS
+	add   r0, r0, #GIC_DR_OFFSET
+	mov   r1, #0
+	str   r1, [r0]               /* Disable delivery in the distributor */
+	add   r0, r0, #0x80          /* GICD_IGROUP0 */
+	mov   r2, #0xffffffff        /* All interrupts to group 1 */
+	str   r2, [r0]
+	str   r2, [r0, #4]
+	str   r2, [r0, #8]
+	/* Must drop priority mask below 0x80 before entering NS state */
+	mov   r0, #GIC_BASE_ADDRESS
+	add   r0, r0, #GIC_CR_OFFSET
+	ldr   r1, =0xff
+	str   r1, [r0, #0x4]         /* -> GICC_PMR */
+	/* Reset a few config registers */
+	mov   r0, #0
+	mcr   CP32(r0, FCSEIDR)
+	mcr   CP32(r0, CONTEXTIDR)
+	/* FIXME: ought to reset some other NS control regs here */
+	adr   r1, 1f
+	adr   r0, hyp                /* Store paddr (hyp entry point) */
+	str   r0, [r1]               /* where we can use it for RFE */
+	isb                          /* Ensure we see the stored target address */
+	rfeia r1                     /* Enter Hyp mode */
+
+1:	.word 0                      /* PC to enter Hyp mode at */
+	.word 0x000001da             /* CPSR: LE, Abort/IRQ/FIQ off, Hyp */
+
+hyp:
+	PRINT("- Setting up control registers -\r\n")
+
+	/* Set up memory attribute type tables */
+	ldr   r0, =MAIR0VAL
+	ldr   r1, =MAIR1VAL
+	mcr   CP32(r0, MAIR0)
+	mcr   CP32(r1, MAIR1)
+	mcr   CP32(r0, HMAIR0)
+	mcr   CP32(r1, HMAIR1)
+
+	/* Set up the HTCR:
+	 * PT walks use Outer-Shareable accesses,
+	 * PT walks are write-back, no-write-allocate in both cache levels,
+	 * Full 32-bit address space goes through this table. */
+	ldr   r0, =0x80002500
+	mcr   CP32(r0, HTCR)
+
+	/* Set up the HSCTLR:
+	 * Exceptions in LE ARM,
+	 * Low-latency IRQs disabled,
+	 * Write-implies-XN disabled (for now),
+	 * I-cache and d-cache enabled,
+	 * Alignment checking enabled,
+	 * MMU translation disabled (for now). */
+	ldr   r0, =(HSCTLR_BASE|SCTLR_A|SCTLR_C)
+	mcr   CP32(r0, HSCTLR)
+
+	/* Write Xen's PT's paddr into the HTTBR */
+	ldr   r4, =xen_pgtable
+	add   r4, r4, r10            /* r4 := paddr (xen_pagetable) */
+	mov   r5, #0                 /* r4:r5 is paddr (xen_pagetable) */
+	mcrr  CP64(r4, r5, HTTBR)
+
+	/* Build the baseline idle pagetable's first-level entries */
+	ldr   r1, =xen_second
+	add   r1, r1, r10            /* r1 := paddr (xen_second) */
+	mov   r3, #0x0
+	orr   r2, r1, #0xe00         /* r2:r3 := table map of xen_second */
+	orr   r2, r2, #0x07f         /* (+ rights for linear PT) */
+	strd  r2, r3, [r4, #0]       /* Map it in slot 0 */
+	add   r2, r2, #0x1000
+	strd  r2, r3, [r4, #8]       /* Map 2nd page in slot 1 */
+	add   r2, r2, #0x1000
+	strd  r2, r3, [r4, #16]      /* Map 3rd page in slot 2 */
+	add   r2, r2, #0x1000
+	strd  r2, r3, [r4, #24]      /* Map 4th page in slot 3 */
+
+	/* Now set up the second-level entries */
+	orr   r2, r9, #0xe00
+	orr   r2, r2, #0x07d         /* r2:r3 := 2MB normal map of Xen */
+	mov   r4, r9, lsr #18        /* Slot for paddr(start) */
+	strd  r2, r3, [r1, r4]       /* Map Xen there */
+	ldr   r4, =start
+	lsr   r4, #18                /* Slot for vaddr(start) */
+	strd  r2, r3, [r1, r4]       /* Map Xen there too */
+#ifdef EARLY_UART_ADDRESS
+	ldr   r3, =(1<<(54-32))      /* NS for device mapping */
+	lsr   r2, r11, #21
+	lsl   r2, r2, #21            /* 2MB-aligned paddr of UART */
+	orr   r2, r2, #0xe00
+	orr   r2, r2, #0x071         /* r2:r3 := 2MB dev map including UART */
+	add   r4, r4, #8
+	strd  r2, r3, [r1, r4]       /* Map it in the fixmap's slot */
+#endif
+
+	PRINT("- Turning on paging -\r\n")
+
+	ldr   r1, =paging            /* Explicit vaddr, not RIP-relative */
+	mrc   CP32(r0, HSCTLR)
+	orr   r0, r0, #0x1           /* Add in the MMU enable bit */
+	dsb                          /* Flush PTE writes and finish reads */
+	mcr   CP32(r0, HSCTLR)       /* now paging is enabled */
+	isb                          /* Now, flush the icache */
+	mov   pc, r1                 /* Get a proper vaddr into PC */
+paging:
+
+#ifdef EARLY_UART_ADDRESS
+	/* Recover the UART address in the new address space */
+	lsl   r11, #11
+	lsr   r11, #11               /* UART base's offset from 2MB base */
+	adr   r0, start
+	add   r0, r0, #0x200000      /* vaddr of the fixmap's 2MB slot */
+	add   r11, r11, r0           /* r11 := vaddr (UART base address) */
+#endif
+
+	PRINT("- Entering C -\r\n")
+
+	ldr   sp, =init_stack        /* Supply a stack */
+	add   sp, #STACK_SIZE        /* (which grows down from the top). */
+	sub   sp, #CPUINFO_sizeof    /* Make room for CPU save record */
+	mov   r0, r10                /* Marshal args: - phys_offset */
+	mov   r1, r7                 /*               - machine type */
+	mov   r2, r8                 /*               - ATAG address */
+	b     start_xen              /* and disappear into the land of C */
+
+/* Fail-stop
+ * r0: string explaining why */
+fail:	PRINT("- Boot failed -\r\n")
+1:	wfe
+	b     1b
+
+#ifdef EARLY_UART_ADDRESS
+
+/* Bring up the UART. Specific to the PL011 UART.
+ * Clobbers r0-r2 */
+init_uart:
+	mov   r1, #0x0
+	str   r1, [r11, #0x24]       /* -> UARTIBRD (Baud divisor fraction) */
+	mov   r1, #0x4               /* 7.3728MHz / 0x4 == 16 * 115200 */
+	str   r1, [r11, #0x24]       /* -> UARTIBRD (Baud divisor integer) */
+	mov   r1, #0x60              /* 8n1 */
+	str   r1, [r11, #0x24]       /* -> UARTLCR_H (Line control) */
+	ldr   r1, =0x00000301        /* RXE | TXE | UARTEN */
+	str   r1, [r11, #0x30]       /* -> UARTCR (Control Register) */
+	adr   r0, 1f
+	b     puts
+1:	.asciz "- UART enabled -\r\n"
+	.align 4
+
+/* Print early debug messages.  Specific to the PL011 UART.
+ * r0: Nul-terminated string to print.
+ * Clobbers r0-r2 */
+puts:
+	ldr   r2, [r11, #0x18]       /* <- UARTFR (Flag register) */
+	tst   r2, #0x8               /* Check BUSY bit */
+	bne   puts                   /* Wait for the UART to be ready */
+	ldrb  r2, [r0], #1           /* Load next char */
+	teq   r2, #0                 /* Exit on nul*/
+	moveq pc, lr
+	str   r2, [r11]              /* -> UARTDR (Data Register) */
+	b     puts
+
+/* Print a 32-bit number in hex.  Specific to the PL011 UART.
+ * r0: Number to print.
+ * clobbers r0-r3 */
+putn:
+	adr   r1, hex
+	mov   r3, #8
+1:	ldr   r2, [r11, #0x18]       /* <- UARTFR (Flag register) */
+	tst   r2, #0x8               /* Check BUSY bit */
+	bne   1b                     /* Wait for the UART to be ready */
+	and   r2, r0, #0xf0000000    /* Mask off the top nybble */
+	ldrb  r2, [r1, r2, lsr #28]  /* Convert to a char */
+	str   r2, [r11]              /* -> UARTDR (Data Register) */
+	lsl   r0, #4                 /* Roll it through one nybble at a time */
+	subs  r3, r3, #1
+	bne   1b
+	adr   r0, crlf               /* Finish with a newline */
+	b     puts
+
+crlf:	.asciz "\r\n"
+hex:	.ascii "0123456789abcdef"
+	.align 2
+
+#else  /* EARLY_UART_ADDRESS */
+
+init_uart:
+.global early_puts
+early_puts:
+puts:
+putn:	mov   pc, lr
+
+#endif /* EARLY_UART_ADDRESS */
diff --git a/xen/arch/arm/xen.lds.S b/xen/arch/arm/xen.lds.S
new file mode 100644
index 0000000..5a62e2c
--- /dev/null
+++ b/xen/arch/arm/xen.lds.S
@@ -0,0 +1,141 @@
+/* Excerpts written by Martin Mares <mj@atrey.karlin.mff.cuni.cz> */
+/* Modified for i386/x86-64 Xen by Keir Fraser */
+/* Modified for ARM Xen by Ian Campbell */
+
+#include <xen/config.h>
+#include <xen/cache.h>
+#include <asm/page.h>
+#include <asm/percpu.h>
+#undef ENTRY
+#undef ALIGN
+
+ENTRY(start)
+
+OUTPUT_ARCH(arm)
+
+PHDRS
+{
+  text PT_LOAD /* XXX should be AT ( XEN_PHYS_START ) */ ;
+}
+SECTIONS
+{
+  . = XEN_VIRT_START;
+  _start = .;
+  .text : /* XXX should be AT ( XEN_PHYS_START ) */ {
+        _stext = .;            /* Text section */
+       *(.text)
+       *(.fixup)
+       *(.gnu.warning)
+       _etext = .;             /* End of text section */
+  } :text = 0x9090
+
+  . = ALIGN(PAGE_SIZE);
+  .rodata : {
+        _srodata = .;          /* Read-only data */
+       *(.rodata)
+       *(.rodata.*)
+        _erodata = .;          /* End of read-only data */
+  } :text
+
+  .data : {                    /* Data */
+       . = ALIGN(PAGE_SIZE);
+       *(.data.page_aligned)
+       *(.data)
+       *(.data.rel)
+       *(.data.rel.*)
+       CONSTRUCTORS
+  } :text
+
+  . = ALIGN(SMP_CACHE_BYTES);
+  .data.read_mostly : {
+       /* Exception table */
+       __start___ex_table = .;
+       *(.ex_table)
+       __stop___ex_table = .;
+
+       /* Pre-exception table */
+       __start___pre_ex_table = .;
+       *(.ex_table.pre)
+       __stop___pre_ex_table = .;
+
+       *(.data.read_mostly)
+       *(.data.rel.ro)
+       *(.data.rel.ro.*)
+  } :text
+
+#ifdef LOCK_PROFILE
+  . = ALIGN(32);
+  __lock_profile_start = .;
+  .lockprofile.data : { *(.lockprofile.data) } :text
+  __lock_profile_end = .;
+#endif
+
+  . = ALIGN(PAGE_SIZE);             /* Init code and data */
+  __init_begin = .;
+  .init.text : {
+       _sinittext = .;
+       *(.init.text)
+       _einittext = .;
+  } :text
+  . = ALIGN(PAGE_SIZE);
+  .init.data : {
+       *(.init.rodata)
+       *(.init.rodata.str*)
+       *(.init.data)
+       *(.init.data.rel)
+       *(.init.data.rel.*)
+  } :text
+  . = ALIGN(32);
+  .init.setup : {
+       __setup_start = .;
+       *(.init.setup)
+       __setup_end = .;
+  } :text
+  .initcall.init : {
+       __initcall_start = .;
+       *(.initcallpresmp.init)
+       __presmp_initcall_end = .;
+       *(.initcall1.init)
+       __initcall_end = .;
+  } :text
+  .xsm_initcall.init : {
+       __xsm_initcall_start = .;
+       *(.xsm_initcall.init)
+       __xsm_initcall_end = .;
+  } :text
+  . = ALIGN(STACK_SIZE);
+  __init_end = .;
+
+  .bss : {                     /* BSS */
+       __bss_start = .;
+       *(.bss.stack_aligned)
+       . = ALIGN(PAGE_SIZE);
+       *(.bss.page_aligned)
+       *(.bss)
+       . = ALIGN(SMP_CACHE_BYTES);
+       __per_cpu_start = .;
+       *(.bss.percpu)
+       . = ALIGN(SMP_CACHE_BYTES);
+       *(.bss.percpu.read_mostly)
+       . = ALIGN(SMP_CACHE_BYTES);
+       __per_cpu_data_end = .;
+  } :text
+  _end = . ;
+
+  /* Sections to be discarded */
+  /DISCARD/ : {
+       *(.exit.text)
+       *(.exit.data)
+       *(.exitcall.exit)
+       *(.eh_frame)
+  }
+
+  /* Stabs debugging sections.  */
+  .stab 0 : { *(.stab) }
+  .stabstr 0 : { *(.stabstr) }
+  .stab.excl 0 : { *(.stab.excl) }
+  .stab.exclstr 0 : { *(.stab.exclstr) }
+  .stab.index 0 : { *(.stab.index) }
+  .stab.indexstr 0 : { *(.stab.indexstr) }
+  .comment 0 : { *(.comment) }
+}
diff --git a/xen/include/asm-arm/asm_defns.h b/xen/include/asm-arm/asm_defns.h
new file mode 100644
index 0000000..c59fb6c
--- /dev/null
+++ b/xen/include/asm-arm/asm_defns.h
@@ -0,0 +1,18 @@
+#ifndef __ARM_ASM_DEFNS_H__
+#define __ARM_ASM_DEFNS_H__
+
+#ifndef COMPILE_OFFSETS
+/* NB. Auto-generated from arch/.../asm-offsets.c */
+#include <asm/asm-offsets.h>
+#endif
+#include <asm/processor.h>
+
+#endif /* __ARM_ASM_DEFNS_H__ */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 18:20:40 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 18:20:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXzd6-00082E-LS; Tue, 06 Dec 2011 18:20:36 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RXzd4-0007vK-6N
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 18:20:34 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1323195545!51363948!4
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMzAwOTc=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4124 invoked from network); 6 Dec 2011 18:19:15 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Dec 2011 18:19:15 -0000
X-IronPort-AV: E=Sophos;i="4.71,307,1320642000"; d="scan'208";a="173120749"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Dec 2011 13:19:46 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Tue, 6 Dec 2011 13:19:46 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pB6IJEjL019549;
	Tue, 6 Dec 2011 10:19:29 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Tue, 6 Dec 2011 18:19:55 +0000
Message-ID: <1323195609-17277-11-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1112061753410.31179@kaball-desktop>
References: <alpine.DEB.2.00.1112061753410.31179@kaball-desktop>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>, Tim.Deegan@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH RFC 11/25] arm: bit manipulation,
	copy and division libraries
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Bit manipulation, division and memcpy & friends implementations for the
ARM architecture, shamelessly taken from Linux.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
---
 xen/arch/arm/lib/Makefile        |    5 +
 xen/arch/arm/lib/assembler.h     |   49 +++++++
 xen/arch/arm/lib/bitops.h        |   36 +++++
 xen/arch/arm/lib/changebit.S     |   18 +++
 xen/arch/arm/lib/clearbit.S      |   19 +++
 xen/arch/arm/lib/copy_template.S |  266 ++++++++++++++++++++++++++++++++++++
 xen/arch/arm/lib/div64.S         |  149 +++++++++++++++++++++
 xen/arch/arm/lib/findbit.S       |  115 ++++++++++++++++
 xen/arch/arm/lib/lib1funcs.S     |  274 ++++++++++++++++++++++++++++++++++++++
 xen/arch/arm/lib/memcpy.S        |   64 +++++++++
 xen/arch/arm/lib/memmove.S       |  200 +++++++++++++++++++++++++++
 xen/arch/arm/lib/memset.S        |  129 ++++++++++++++++++
 xen/arch/arm/lib/memzero.S       |  127 ++++++++++++++++++
 xen/arch/arm/lib/setbit.S        |   18 +++
 xen/arch/arm/lib/testchangebit.S |   18 +++
 xen/arch/arm/lib/testclearbit.S  |   18 +++
 xen/arch/arm/lib/testsetbit.S    |   18 +++
 17 files changed, 1523 insertions(+), 0 deletions(-)
 create mode 100644 xen/arch/arm/lib/Makefile
 create mode 100644 xen/arch/arm/lib/assembler.h
 create mode 100644 xen/arch/arm/lib/bitops.h
 create mode 100644 xen/arch/arm/lib/changebit.S
 create mode 100644 xen/arch/arm/lib/clearbit.S
 create mode 100644 xen/arch/arm/lib/copy_template.S
 create mode 100644 xen/arch/arm/lib/div64.S
 create mode 100644 xen/arch/arm/lib/findbit.S
 create mode 100644 xen/arch/arm/lib/lib1funcs.S
 create mode 100644 xen/arch/arm/lib/memcpy.S
 create mode 100644 xen/arch/arm/lib/memmove.S
 create mode 100644 xen/arch/arm/lib/memset.S
 create mode 100644 xen/arch/arm/lib/memzero.S
 create mode 100644 xen/arch/arm/lib/setbit.S
 create mode 100644 xen/arch/arm/lib/testchangebit.S
 create mode 100644 xen/arch/arm/lib/testclearbit.S
 create mode 100644 xen/arch/arm/lib/testsetbit.S

diff --git a/xen/arch/arm/lib/Makefile b/xen/arch/arm/lib/Makefile
new file mode 100644
index 0000000..cbbed68
--- /dev/null
+++ b/xen/arch/arm/lib/Makefile
@@ -0,0 +1,5 @@
+obj-y += memcpy.o memmove.o memset.o memzero.o
+obj-y += findbit.o setbit.o
+obj-y += setbit.o clearbit.o changebit.o
+obj-y += testsetbit.o testclearbit.o testchangebit.o
+obj-y += lib1funcs.o div64.o
diff --git a/xen/arch/arm/lib/assembler.h b/xen/arch/arm/lib/assembler.h
new file mode 100644
index 0000000..f8f0961
--- /dev/null
+++ b/xen/arch/arm/lib/assembler.h
@@ -0,0 +1,49 @@
+#ifndef __ARCH_ARM_LIB_ASSEMBLER_H__
+#define __ARCH_ARM_LIB_ASSEMBLER_H__
+
+/* From Linux arch/arm/include/asm/assembler.h */
+/*
+ * Data preload for architectures that support it
+ */
+#define PLD(code...)    code
+
+/*
+ * This can be used to enable code to cacheline align the destination
+ * pointer when bulk writing to memory.  Experiments on StrongARM and
+ * XScale didn't show this a worthwhile thing to do when the cache is not
+ * set to write-allocate (this would need further testing on XScale when WA
+ * is used).
+ *
+ * On Feroceon there is much to gain however, regardless of cache mode.
+ */
+#ifdef CONFIG_CPU_FEROCEON /* Not in Xen... */
+#define CALGN(code...) code
+#else
+#define CALGN(code...)
+#endif
+
+// No Thumb, hence:
+#define W(instr)        instr
+#define ARM(instr...)   instr
+#define THUMB(instr...)
+
+#ifdef CONFIG_ARM_UNWIND
+#define UNWIND(code...)         code
+#else
+#define UNWIND(code...)
+#endif
+
+#define pull            lsl
+#define push            lsr
+#define get_byte_0      lsr #24
+#define get_byte_1      lsr #16
+#define get_byte_2      lsr #8
+#define get_byte_3      lsl #0
+#define put_byte_0      lsl #24
+#define put_byte_1      lsl #16
+#define put_byte_2      lsl #8
+#define put_byte_3      lsl #0
+
+#define smp_dmb dmb
+
+#endif /*  __ARCH_ARM_LIB_ASSEMBLER_H__ */
diff --git a/xen/arch/arm/lib/bitops.h b/xen/arch/arm/lib/bitops.h
new file mode 100644
index 0000000..e56d4e8
--- /dev/null
+++ b/xen/arch/arm/lib/bitops.h
@@ -0,0 +1,36 @@
+	.macro	bitop, instr
+	ands	ip, r1, #3
+	strneb	r1, [ip]		@ assert word-aligned
+	mov	r2, #1
+	and	r3, r0, #31		@ Get bit offset
+	mov	r0, r0, lsr #5
+	add	r1, r1, r0, lsl #2	@ Get word offset
+	mov	r3, r2, lsl r3
+1:	ldrex	r2, [r1]
+	\instr	r2, r2, r3
+	strex	r0, r2, [r1]
+	cmp	r0, #0
+	bne	1b
+	bx	lr
+	.endm
+
+	.macro	testop, instr, store
+	ands	ip, r1, #3
+	strneb	r1, [ip]		@ assert word-aligned
+	mov	r2, #1
+	and	r3, r0, #31		@ Get bit offset
+	mov	r0, r0, lsr #5
+	add	r1, r1, r0, lsl #2	@ Get word offset
+	mov	r3, r2, lsl r3		@ create mask
+	smp_dmb
+1:	ldrex	r2, [r1]
+	ands	r0, r2, r3		@ save old value of bit
+	\instr	r2, r2, r3		@ toggle bit
+	strex	ip, r2, [r1]
+	cmp	ip, #0
+	bne	1b
+	smp_dmb
+	cmp	r0, #0
+	movne	r0, #1
+2:	bx	lr
+	.endm
diff --git a/xen/arch/arm/lib/changebit.S b/xen/arch/arm/lib/changebit.S
new file mode 100644
index 0000000..62954bc
--- /dev/null
+++ b/xen/arch/arm/lib/changebit.S
@@ -0,0 +1,18 @@
+/*
+ *  linux/arch/arm/lib/changebit.S
+ *
+ *  Copyright (C) 1995-1996 Russell King
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#include <xen/config.h>
+
+#include "assembler.h"
+#include "bitops.h"
+                .text
+
+ENTRY(_change_bit)
+	bitop	eor
+ENDPROC(_change_bit)
diff --git a/xen/arch/arm/lib/clearbit.S b/xen/arch/arm/lib/clearbit.S
new file mode 100644
index 0000000..42ce416
--- /dev/null
+++ b/xen/arch/arm/lib/clearbit.S
@@ -0,0 +1,19 @@
+/*
+ *  linux/arch/arm/lib/clearbit.S
+ *
+ *  Copyright (C) 1995-1996 Russell King
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <xen/config.h>
+
+#include "assembler.h"
+#include "bitops.h"
+                .text
+
+ENTRY(_clear_bit)
+	bitop	bic
+ENDPROC(_clear_bit)
diff --git a/xen/arch/arm/lib/copy_template.S b/xen/arch/arm/lib/copy_template.S
new file mode 100644
index 0000000..7f7f4d5
--- /dev/null
+++ b/xen/arch/arm/lib/copy_template.S
@@ -0,0 +1,266 @@
+/*
+ *  linux/arch/arm/lib/copy_template.s
+ *
+ *  Code template for optimized memory copy functions
+ *
+ *  Author:	Nicolas Pitre
+ *  Created:	Sep 28, 2005
+ *  Copyright:	MontaVista Software, Inc.
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License version 2 as
+ *  published by the Free Software Foundation.
+ */
+
+/*
+ * Theory of operation
+ * -------------------
+ *
+ * This file provides the core code for a forward memory copy used in
+ * the implementation of memcopy(), copy_to_user() and copy_from_user().
+ *
+ * The including file must define the following accessor macros
+ * according to the need of the given function:
+ *
+ * ldr1w ptr reg abort
+ *
+ *	This loads one word from 'ptr', stores it in 'reg' and increments
+ *	'ptr' to the next word. The 'abort' argument is used for fixup tables.
+ *
+ * ldr4w ptr reg1 reg2 reg3 reg4 abort
+ * ldr8w ptr, reg1 reg2 reg3 reg4 reg5 reg6 reg7 reg8 abort
+ *
+ *	This loads four or eight words starting from 'ptr', stores them
+ *	in provided registers and increments 'ptr' past those words.
+ *	The'abort' argument is used for fixup tables.
+ *
+ * ldr1b ptr reg cond abort
+ *
+ *	Similar to ldr1w, but it loads a byte and increments 'ptr' one byte.
+ *	It also must apply the condition code if provided, otherwise the
+ *	"al" condition is assumed by default.
+ *
+ * str1w ptr reg abort
+ * str8w ptr reg1 reg2 reg3 reg4 reg5 reg6 reg7 reg8 abort
+ * str1b ptr reg cond abort
+ *
+ *	Same as their ldr* counterparts, but data is stored to 'ptr' location
+ *	rather than being loaded.
+ *
+ * enter reg1 reg2
+ *
+ *	Preserve the provided registers on the stack plus any additional
+ *	data as needed by the implementation including this code. Called
+ *	upon code entry.
+ *
+ * exit reg1 reg2
+ *
+ *	Restore registers with the values previously saved with the
+ *	'preserv' macro. Called upon code termination.
+ *
+ * LDR1W_SHIFT
+ * STR1W_SHIFT
+ *
+ *	Correction to be applied to the "ip" register when branching into
+ *	the ldr1w or str1w instructions (some of these macros may expand to
+ *	than one 32bit instruction in Thumb-2)
+ */
+
+		enter	r4, lr
+
+		subs	r2, r2, #4
+		blt	8f
+		ands	ip, r0, #3
+	PLD(	pld	[r1, #0]		)
+		bne	9f
+		ands	ip, r1, #3
+		bne	10f
+
+1:		subs	r2, r2, #(28)
+		stmfd	sp!, {r5 - r8}
+		blt	5f
+
+	CALGN(	ands	ip, r0, #31		)
+	CALGN(	rsb	r3, ip, #32		)
+	CALGN(	sbcnes	r4, r3, r2		)  @ C is always set here
+	CALGN(	bcs	2f			)
+	CALGN(	adr	r4, 6f			)
+	CALGN(	subs	r2, r2, r3		)  @ C gets set
+	CALGN(	add	pc, r4, ip		)
+
+	PLD(	pld	[r1, #0]		)
+2:	PLD(	subs	r2, r2, #96		)
+	PLD(	pld	[r1, #28]		)
+	PLD(	blt	4f			)
+	PLD(	pld	[r1, #60]		)
+	PLD(	pld	[r1, #92]		)
+
+3:	PLD(	pld	[r1, #124]		)
+4:		ldr8w	r1, r3, r4, r5, r6, r7, r8, ip, lr, abort=20f
+		subs	r2, r2, #32
+		str8w	r0, r3, r4, r5, r6, r7, r8, ip, lr, abort=20f
+		bge	3b
+	PLD(	cmn	r2, #96			)
+	PLD(	bge	4b			)
+
+5:		ands	ip, r2, #28
+		rsb	ip, ip, #32
+#if LDR1W_SHIFT > 0
+		lsl	ip, ip, #LDR1W_SHIFT
+#endif
+		addne	pc, pc, ip		@ C is always clear here
+		b	7f
+6:
+		.rept	(1 << LDR1W_SHIFT)
+		W(nop)
+		.endr
+		ldr1w	r1, r3, abort=20f
+		ldr1w	r1, r4, abort=20f
+		ldr1w	r1, r5, abort=20f
+		ldr1w	r1, r6, abort=20f
+		ldr1w	r1, r7, abort=20f
+		ldr1w	r1, r8, abort=20f
+		ldr1w	r1, lr, abort=20f
+
+#if LDR1W_SHIFT < STR1W_SHIFT
+		lsl	ip, ip, #STR1W_SHIFT - LDR1W_SHIFT
+#elif LDR1W_SHIFT > STR1W_SHIFT
+		lsr	ip, ip, #LDR1W_SHIFT - STR1W_SHIFT
+#endif
+		add	pc, pc, ip
+		nop
+		.rept	(1 << STR1W_SHIFT)
+		W(nop)
+		.endr
+		str1w	r0, r3, abort=20f
+		str1w	r0, r4, abort=20f
+		str1w	r0, r5, abort=20f
+		str1w	r0, r6, abort=20f
+		str1w	r0, r7, abort=20f
+		str1w	r0, r8, abort=20f
+		str1w	r0, lr, abort=20f
+
+	CALGN(	bcs	2b			)
+
+7:		ldmfd	sp!, {r5 - r8}
+
+8:		movs	r2, r2, lsl #31
+		ldr1b	r1, r3, ne, abort=21f
+		ldr1b	r1, r4, cs, abort=21f
+		ldr1b	r1, ip, cs, abort=21f
+		str1b	r0, r3, ne, abort=21f
+		str1b	r0, r4, cs, abort=21f
+		str1b	r0, ip, cs, abort=21f
+
+		exit	r4, pc
+
+9:		rsb	ip, ip, #4
+		cmp	ip, #2
+		ldr1b	r1, r3, gt, abort=21f
+		ldr1b	r1, r4, ge, abort=21f
+		ldr1b	r1, lr, abort=21f
+		str1b	r0, r3, gt, abort=21f
+		str1b	r0, r4, ge, abort=21f
+		subs	r2, r2, ip
+		str1b	r0, lr, abort=21f
+		blt	8b
+		ands	ip, r1, #3
+		beq	1b
+
+10:		bic	r1, r1, #3
+		cmp	ip, #2
+		ldr1w	r1, lr, abort=21f
+		beq	17f
+		bgt	18f
+
+
+		.macro	forward_copy_shift pull push
+
+		subs	r2, r2, #28
+		blt	14f
+
+	CALGN(	ands	ip, r0, #31		)
+	CALGN(	rsb	ip, ip, #32		)
+	CALGN(	sbcnes	r4, ip, r2		)  @ C is always set here
+	CALGN(	subcc	r2, r2, ip		)
+	CALGN(	bcc	15f			)
+
+11:		stmfd	sp!, {r5 - r9}
+
+	PLD(	pld	[r1, #0]		)
+	PLD(	subs	r2, r2, #96		)
+	PLD(	pld	[r1, #28]		)
+	PLD(	blt	13f			)
+	PLD(	pld	[r1, #60]		)
+	PLD(	pld	[r1, #92]		)
+
+12:	PLD(	pld	[r1, #124]		)
+13:		ldr4w	r1, r4, r5, r6, r7, abort=19f
+		mov	r3, lr, pull #\pull
+		subs	r2, r2, #32
+		ldr4w	r1, r8, r9, ip, lr, abort=19f
+		orr	r3, r3, r4, push #\push
+		mov	r4, r4, pull #\pull
+		orr	r4, r4, r5, push #\push
+		mov	r5, r5, pull #\pull
+		orr	r5, r5, r6, push #\push
+		mov	r6, r6, pull #\pull
+		orr	r6, r6, r7, push #\push
+		mov	r7, r7, pull #\pull
+		orr	r7, r7, r8, push #\push
+		mov	r8, r8, pull #\pull
+		orr	r8, r8, r9, push #\push
+		mov	r9, r9, pull #\pull
+		orr	r9, r9, ip, push #\push
+		mov	ip, ip, pull #\pull
+		orr	ip, ip, lr, push #\push
+		str8w	r0, r3, r4, r5, r6, r7, r8, r9, ip, , abort=19f
+		bge	12b
+	PLD(	cmn	r2, #96			)
+	PLD(	bge	13b			)
+
+		ldmfd	sp!, {r5 - r9}
+
+14:		ands	ip, r2, #28
+		beq	16f
+
+15:		mov	r3, lr, pull #\pull
+		ldr1w	r1, lr, abort=21f
+		subs	ip, ip, #4
+		orr	r3, r3, lr, push #\push
+		str1w	r0, r3, abort=21f
+		bgt	15b
+	CALGN(	cmp	r2, #0			)
+	CALGN(	bge	11b			)
+
+16:		sub	r1, r1, #(\push / 8)
+		b	8b
+
+		.endm
+
+
+		forward_copy_shift	pull=8	push=24
+
+17:		forward_copy_shift	pull=16	push=16
+
+18:		forward_copy_shift	pull=24	push=8
+
+
+/*
+ * Abort preamble and completion macros.
+ * If a fixup handler is required then those macros must surround it.
+ * It is assumed that the fixup code will handle the private part of
+ * the exit macro.
+ */
+
+	.macro	copy_abort_preamble
+19:	ldmfd	sp!, {r5 - r9}
+	b	21f
+20:	ldmfd	sp!, {r5 - r8}
+21:
+	.endm
+
+	.macro	copy_abort_end
+	ldmfd	sp!, {r4, pc}
+	.endm
+
diff --git a/xen/arch/arm/lib/div64.S b/xen/arch/arm/lib/div64.S
new file mode 100644
index 0000000..2584772
--- /dev/null
+++ b/xen/arch/arm/lib/div64.S
@@ -0,0 +1,149 @@
+/*
+ *  linux/arch/arm/lib/div64.S
+ *
+ *  Optimized computation of 64-bit dividend / 32-bit divisor
+ *
+ *  Author:	Nicolas Pitre
+ *  Created:	Oct 5, 2003
+ *  Copyright:	Monta Vista Software, Inc.
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License version 2 as
+ *  published by the Free Software Foundation.
+ */
+
+#include <xen/config.h>
+#include "assembler.h"
+	
+#define xl r0
+#define xh r1
+#define yl r2
+#define yh r3
+
+/*
+ * __do_div64: perform a division with 64-bit dividend and 32-bit divisor.
+ *
+ * Note: Calling convention is totally non standard for optimal code.
+ *       This is meant to be used by do_div() from include/asm/div64.h only.
+ *
+ * Input parameters:
+ * 	xh-xl	= dividend (clobbered)
+ * 	r4	= divisor (preserved)
+ *
+ * Output values:
+ * 	yh-yl	= result
+ * 	xh	= remainder
+ *
+ * Clobbered regs: xl, ip
+ */
+
+ENTRY(__do_div64)
+
+	@ Test for easy paths first.
+	subs	ip, r4, #1
+	bls	9f			@ divisor is 0 or 1
+	tst	ip, r4
+	beq	8f			@ divisor is power of 2
+
+	@ See if we need to handle upper 32-bit result.
+	cmp	xh, r4
+	mov	yh, #0
+	blo	3f
+
+	@ Align divisor with upper part of dividend.
+	@ The aligned divisor is stored in yl preserving the original.
+	@ The bit position is stored in ip.
+
+	clz	yl, r4
+	clz	ip, xh
+	sub	yl, yl, ip
+	mov	ip, #1
+	mov	ip, ip, lsl yl
+	mov	yl, r4, lsl yl
+
+	@ The division loop for needed upper bit positions.
+ 	@ Break out early if dividend reaches 0.
+2:	cmp	xh, yl
+	orrcs	yh, yh, ip
+	subcss	xh, xh, yl
+	movnes	ip, ip, lsr #1
+	mov	yl, yl, lsr #1
+	bne	2b
+
+	@ See if we need to handle lower 32-bit result.
+3:	cmp	xh, #0
+	mov	yl, #0
+	cmpeq	xl, r4
+	movlo	xh, xl
+	movlo	pc, lr
+
+	@ The division loop for lower bit positions.
+	@ Here we shift remainer bits leftwards rather than moving the
+	@ divisor for comparisons, considering the carry-out bit as well.
+	mov	ip, #0x80000000
+4:	movs	xl, xl, lsl #1
+	adcs	xh, xh, xh
+	beq	6f
+	cmpcc	xh, r4
+5:	orrcs	yl, yl, ip
+	subcs	xh, xh, r4
+	movs	ip, ip, lsr #1
+	bne	4b
+	mov	pc, lr
+
+	@ The top part of remainder became zero.  If carry is set
+	@ (the 33th bit) this is a false positive so resume the loop.
+	@ Otherwise, if lower part is also null then we are done.
+6:	bcs	5b
+	cmp	xl, #0
+	moveq	pc, lr
+
+	@ We still have remainer bits in the low part.  Bring them up.
+
+	clz	xh, xl			@ we know xh is zero here so...
+	add	xh, xh, #1
+	mov	xl, xl, lsl xh
+	mov	ip, ip, lsr xh
+
+	@ Current remainder is now 1.  It is worthless to compare with
+	@ divisor at this point since divisor can not be smaller than 3 here.
+	@ If possible, branch for another shift in the division loop.
+	@ If no bit position left then we are done.
+	movs	ip, ip, lsr #1
+	mov	xh, #1
+	bne	4b
+	mov	pc, lr
+
+8:	@ Division by a power of 2: determine what that divisor order is
+	@ then simply shift values around
+
+	clz	ip, r4
+	rsb	ip, ip, #31
+
+	mov	yh, xh, lsr ip
+	mov	yl, xl, lsr ip
+	rsb	ip, ip, #32
+ ARM(	orr	yl, yl, xh, lsl ip	)
+ THUMB(	lsl	xh, xh, ip		)
+ THUMB(	orr	yl, yl, xh		)
+	mov	xh, xl, lsl ip
+	mov	xh, xh, lsr ip
+	mov	pc, lr
+
+	@ eq -> division by 1: obvious enough...
+9:	moveq	yl, xl
+	moveq	yh, xh
+	moveq	xh, #0
+	moveq	pc, lr
+
+	@ Division by 0:
+	str	lr, [sp, #-8]!
+	bl	__div0
+
+	@ as wrong as it could be...
+	mov	yl, #0
+	mov	yh, #0
+	mov	xh, #0
+	ldr	pc, [sp], #8
+
+ENDPROC(__do_div64)
diff --git a/xen/arch/arm/lib/findbit.S b/xen/arch/arm/lib/findbit.S
new file mode 100644
index 0000000..5669b91
--- /dev/null
+++ b/xen/arch/arm/lib/findbit.S
@@ -0,0 +1,115 @@
+/*
+ *  linux/arch/arm/lib/findbit.S
+ *
+ *  Copyright (C) 1995-2000 Russell King
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * 16th March 2001 - John Ripley <jripley@sonicblue.com>
+ *   Fixed so that "size" is an exclusive not an inclusive quantity.
+ *   All users of these functions expect exclusive sizes, and may
+ *   also call with zero size.
+ * Reworked by rmk.
+ */
+
+#include <xen/config.h>
+
+#include "assembler.h"
+                .text
+
+/*
+ * Purpose  : Find a 'zero' bit
+ * Prototype: int find_first_zero_bit(void *addr, unsigned int maxbit);
+ */
+ENTRY(_find_first_zero_bit)
+		teq	r1, #0	
+		beq	3f
+		mov	r2, #0
+1:
+ ARM(		ldrb	r3, [r0, r2, lsr #3]	)
+ THUMB(		lsr	r3, r2, #3		)
+ THUMB(		ldrb	r3, [r0, r3]		)
+		eors	r3, r3, #0xff		@ invert bits
+		bne	.L_found		@ any now set - found zero bit
+		add	r2, r2, #8		@ next bit pointer
+2:		cmp	r2, r1			@ any more?
+		blo	1b
+3:		mov	r0, r1			@ no free bits
+		mov	pc, lr
+ENDPROC(_find_first_zero_bit)
+
+/*
+ * Purpose  : Find next 'zero' bit
+ * Prototype: int find_next_zero_bit(void *addr, unsigned int maxbit, int offset)
+ */
+ENTRY(_find_next_zero_bit)
+		teq	r1, #0
+		beq	3b
+		ands	ip, r2, #7
+		beq	1b			@ If new byte, goto old routine
+ ARM(		ldrb	r3, [r0, r2, lsr #3]	)
+ THUMB(		lsr	r3, r2, #3		)
+ THUMB(		ldrb	r3, [r0, r3]		)
+		eor	r3, r3, #0xff		@ now looking for a 1 bit
+		movs	r3, r3, lsr ip		@ shift off unused bits
+		bne	.L_found
+		orr	r2, r2, #7		@ if zero, then no bits here
+		add	r2, r2, #1		@ align bit pointer
+		b	2b			@ loop for next bit
+ENDPROC(_find_next_zero_bit)
+
+/*
+ * Purpose  : Find a 'one' bit
+ * Prototype: int find_first_bit(const unsigned long *addr, unsigned int maxbit);
+ */
+ENTRY(_find_first_bit)
+		teq	r1, #0	
+		beq	3f
+		mov	r2, #0
+1:
+ ARM(		ldrb	r3, [r0, r2, lsr #3]	)
+ THUMB(		lsr	r3, r2, #3		)
+ THUMB(		ldrb	r3, [r0, r3]		)
+		movs	r3, r3
+		bne	.L_found		@ any now set - found zero bit
+		add	r2, r2, #8		@ next bit pointer
+2:		cmp	r2, r1			@ any more?
+		blo	1b
+3:		mov	r0, r1			@ no free bits
+		mov	pc, lr
+ENDPROC(_find_first_bit)
+
+/*
+ * Purpose  : Find next 'one' bit
+ * Prototype: int find_next_zero_bit(void *addr, unsigned int maxbit, int offset)
+ */
+ENTRY(_find_next_bit)
+		teq	r1, #0
+		beq	3b
+		ands	ip, r2, #7
+		beq	1b			@ If new byte, goto old routine
+ ARM(		ldrb	r3, [r0, r2, lsr #3]	)
+ THUMB(		lsr	r3, r2, #3		)
+ THUMB(		ldrb	r3, [r0, r3]		)
+		movs	r3, r3, lsr ip		@ shift off unused bits
+		bne	.L_found
+		orr	r2, r2, #7		@ if zero, then no bits here
+		add	r2, r2, #1		@ align bit pointer
+		b	2b			@ loop for next bit
+ENDPROC(_find_next_bit)
+
+/*
+ * One or more bits in the LSB of r3 are assumed to be set.
+ */
+.L_found:
+		rsb	r0, r3, #0
+		and	r3, r3, r0
+		clz	r3, r3
+		rsb	r3, r3, #31
+		add	r0, r2, r3
+		cmp	r1, r0			@ Clamp to maxbit
+		movlo	r0, r1
+		mov	pc, lr
+
diff --git a/xen/arch/arm/lib/lib1funcs.S b/xen/arch/arm/lib/lib1funcs.S
new file mode 100644
index 0000000..745f4af
--- /dev/null
+++ b/xen/arch/arm/lib/lib1funcs.S
@@ -0,0 +1,274 @@
+/*
+ * linux/arch/arm/lib/lib1funcs.S: Optimized ARM division routines
+ *
+ * Author: Nicolas Pitre <nico@fluxnic.net>
+ *   - contributed to gcc-3.4 on Sep 30, 2003
+ *   - adapted for the Linux kernel on Oct 2, 2003
+ */
+
+/* Copyright 1995, 1996, 1998, 1999, 2000, 2003 Free Software Foundation, Inc.
+
+This file 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, or (at your option) any
+later version.
+
+In addition to the permissions in the GNU General Public License, the
+Free Software Foundation gives you unlimited permission to link the
+compiled version of this file into combinations with other programs,
+and to distribute those combinations without any restriction coming
+from the use of this file.  (The General Public License restrictions
+do apply in other respects; for example, they cover modification of
+the file, and distribution when not linked into a combine
+executable.)
+
+This file is distributed in the hope that it will be useful, but
+WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  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; see the file COPYING.  If not, write to
+the Free Software Foundation, 59 Temple Place - Suite 330,
+Boston, MA 02111-1307, USA.  */
+
+
+#include <xen/config.h>
+#include "assembler.h"
+
+.macro ARM_DIV_BODY dividend, divisor, result, curbit
+
+	clz	\curbit, \divisor
+	clz	\result, \dividend
+	sub	\result, \curbit, \result
+	mov	\curbit, #1
+	mov	\divisor, \divisor, lsl \result
+	mov	\curbit, \curbit, lsl \result
+	mov	\result, #0
+	
+	@ Division loop
+1:	cmp	\dividend, \divisor
+	subhs	\dividend, \dividend, \divisor
+	orrhs	\result,   \result,   \curbit
+	cmp	\dividend, \divisor,  lsr #1
+	subhs	\dividend, \dividend, \divisor, lsr #1
+	orrhs	\result,   \result,   \curbit,  lsr #1
+	cmp	\dividend, \divisor,  lsr #2
+	subhs	\dividend, \dividend, \divisor, lsr #2
+	orrhs	\result,   \result,   \curbit,  lsr #2
+	cmp	\dividend, \divisor,  lsr #3
+	subhs	\dividend, \dividend, \divisor, lsr #3
+	orrhs	\result,   \result,   \curbit,  lsr #3
+	cmp	\dividend, #0			@ Early termination?
+	movnes	\curbit,   \curbit,  lsr #4	@ No, any more bits to do?
+	movne	\divisor,  \divisor, lsr #4
+	bne	1b
+
+.endm
+
+
+.macro ARM_DIV2_ORDER divisor, order
+
+	clz	\order, \divisor
+	rsb	\order, \order, #31
+
+.endm
+
+
+.macro ARM_MOD_BODY dividend, divisor, order, spare
+
+	clz	\order, \divisor
+	clz	\spare, \dividend
+	sub	\order, \order, \spare
+	mov	\divisor, \divisor, lsl \order
+
+	@ Perform all needed substractions to keep only the reminder.
+	@ Do comparisons in batch of 4 first.
+	subs	\order, \order, #3		@ yes, 3 is intended here
+	blt	2f
+
+1:	cmp	\dividend, \divisor
+	subhs	\dividend, \dividend, \divisor
+	cmp	\dividend, \divisor,  lsr #1
+	subhs	\dividend, \dividend, \divisor, lsr #1
+	cmp	\dividend, \divisor,  lsr #2
+	subhs	\dividend, \dividend, \divisor, lsr #2
+	cmp	\dividend, \divisor,  lsr #3
+	subhs	\dividend, \dividend, \divisor, lsr #3
+	cmp	\dividend, #1
+	mov	\divisor, \divisor, lsr #4
+	subges	\order, \order, #4
+	bge	1b
+
+	tst	\order, #3
+	teqne	\dividend, #0
+	beq	5f
+
+	@ Either 1, 2 or 3 comparison/substractions are left.
+2:	cmn	\order, #2
+	blt	4f
+	beq	3f
+	cmp	\dividend, \divisor
+	subhs	\dividend, \dividend, \divisor
+	mov	\divisor,  \divisor,  lsr #1
+3:	cmp	\dividend, \divisor
+	subhs	\dividend, \dividend, \divisor
+	mov	\divisor,  \divisor,  lsr #1
+4:	cmp	\dividend, \divisor
+	subhs	\dividend, \dividend, \divisor
+5:
+.endm
+
+
+ENTRY(__udivsi3)
+ENTRY(__aeabi_uidiv)
+UNWIND(.fnstart)
+
+	subs	r2, r1, #1
+	moveq	pc, lr
+	bcc	Ldiv0
+	cmp	r0, r1
+	bls	11f
+	tst	r1, r2
+	beq	12f
+
+	ARM_DIV_BODY r0, r1, r2, r3
+
+	mov	r0, r2
+	mov	pc, lr
+
+11:	moveq	r0, #1
+	movne	r0, #0
+	mov	pc, lr
+
+12:	ARM_DIV2_ORDER r1, r2
+
+	mov	r0, r0, lsr r2
+	mov	pc, lr
+
+UNWIND(.fnend)
+ENDPROC(__udivsi3)
+ENDPROC(__aeabi_uidiv)
+
+ENTRY(__umodsi3)
+UNWIND(.fnstart)
+
+	subs	r2, r1, #1			@ compare divisor with 1
+	bcc	Ldiv0
+	cmpne	r0, r1				@ compare dividend with divisor
+	moveq   r0, #0
+	tsthi	r1, r2				@ see if divisor is power of 2
+	andeq	r0, r0, r2
+	movls	pc, lr
+
+	ARM_MOD_BODY r0, r1, r2, r3
+
+	mov	pc, lr
+
+UNWIND(.fnend)
+ENDPROC(__umodsi3)
+
+ENTRY(__divsi3)
+ENTRY(__aeabi_idiv)
+UNWIND(.fnstart)
+
+	cmp	r1, #0
+	eor	ip, r0, r1			@ save the sign of the result.
+	beq	Ldiv0
+	rsbmi	r1, r1, #0			@ loops below use unsigned.
+	subs	r2, r1, #1			@ division by 1 or -1 ?
+	beq	10f
+	movs	r3, r0
+	rsbmi	r3, r0, #0			@ positive dividend value
+	cmp	r3, r1
+	bls	11f
+	tst	r1, r2				@ divisor is power of 2 ?
+	beq	12f
+
+	ARM_DIV_BODY r3, r1, r0, r2
+
+	cmp	ip, #0
+	rsbmi	r0, r0, #0
+	mov	pc, lr
+
+10:	teq	ip, r0				@ same sign ?
+	rsbmi	r0, r0, #0
+	mov	pc, lr
+
+11:	movlo	r0, #0
+	moveq	r0, ip, asr #31
+	orreq	r0, r0, #1
+	mov	pc, lr
+
+12:	ARM_DIV2_ORDER r1, r2
+
+	cmp	ip, #0
+	mov	r0, r3, lsr r2
+	rsbmi	r0, r0, #0
+	mov	pc, lr
+
+UNWIND(.fnend)
+ENDPROC(__divsi3)
+ENDPROC(__aeabi_idiv)
+
+ENTRY(__modsi3)
+UNWIND(.fnstart)
+
+	cmp	r1, #0
+	beq	Ldiv0
+	rsbmi	r1, r1, #0			@ loops below use unsigned.
+	movs	ip, r0				@ preserve sign of dividend
+	rsbmi	r0, r0, #0			@ if negative make positive
+	subs	r2, r1, #1			@ compare divisor with 1
+	cmpne	r0, r1				@ compare dividend with divisor
+	moveq	r0, #0
+	tsthi	r1, r2				@ see if divisor is power of 2
+	andeq	r0, r0, r2
+	bls	10f
+
+	ARM_MOD_BODY r0, r1, r2, r3
+
+10:	cmp	ip, #0
+	rsbmi	r0, r0, #0
+	mov	pc, lr
+
+UNWIND(.fnend)
+ENDPROC(__modsi3)
+
+ENTRY(__aeabi_uidivmod)
+UNWIND(.fnstart)
+UNWIND(.save {r0, r1, ip, lr}	)
+
+	stmfd	sp!, {r0, r1, ip, lr}
+	bl	__aeabi_uidiv
+	ldmfd	sp!, {r1, r2, ip, lr}
+	mul	r3, r0, r2
+	sub	r1, r1, r3
+	mov	pc, lr
+
+UNWIND(.fnend)
+ENDPROC(__aeabi_uidivmod)
+
+ENTRY(__aeabi_idivmod)
+UNWIND(.fnstart)
+UNWIND(.save {r0, r1, ip, lr}	)
+	stmfd	sp!, {r0, r1, ip, lr}
+	bl	__aeabi_idiv
+	ldmfd	sp!, {r1, r2, ip, lr}
+	mul	r3, r0, r2
+	sub	r1, r1, r3
+	mov	pc, lr
+
+UNWIND(.fnend)
+ENDPROC(__aeabi_idivmod)
+
+Ldiv0:
+UNWIND(.fnstart)
+UNWIND(.pad #4)
+UNWIND(.save {lr})
+	str	lr, [sp, #-8]!
+	bl	__div0
+	mov	r0, #0			@ About as wrong as it could be.
+	ldr	pc, [sp], #8
+UNWIND(.fnend)
+ENDPROC(Ldiv0)
diff --git a/xen/arch/arm/lib/memcpy.S b/xen/arch/arm/lib/memcpy.S
new file mode 100644
index 0000000..f4bad5c
--- /dev/null
+++ b/xen/arch/arm/lib/memcpy.S
@@ -0,0 +1,64 @@
+/*
+ *  linux/arch/arm/lib/memcpy.S
+ *
+ *  Author:     Nicolas Pitre
+ *  Created:    Sep 28, 2005
+ *  Copyright:  MontaVista Software, Inc.
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License version 2 as
+ *  published by the Free Software Foundation.
+ */
+
+#include <xen/config.h>
+
+#include "assembler.h"
+
+#define LDR1W_SHIFT     0
+#define STR1W_SHIFT     0
+
+        .macro ldr1w ptr reg abort
+        W(ldr) \reg, [\ptr], #4
+        .endm
+
+        .macro ldr4w ptr reg1 reg2 reg3 reg4 abort
+        ldmia \ptr!, {\reg1, \reg2, \reg3, \reg4}
+        .endm
+
+        .macro ldr8w ptr reg1 reg2 reg3 reg4 reg5 reg6 reg7 reg8 abort
+        ldmia \ptr!, {\reg1, \reg2, \reg3, \reg4, \reg5, \reg6, \reg7, \reg8}
+        .endm
+
+        .macro ldr1b ptr reg cond=al abort
+        ldr\cond\()b \reg, [\ptr], #1
+        .endm
+
+        .macro str1w ptr reg abort
+        W(str) \reg, [\ptr], #4
+        .endm
+
+        .macro str8w ptr reg1 reg2 reg3 reg4 reg5 reg6 reg7 reg8 abort
+        stmia \ptr!, {\reg1, \reg2, \reg3, \reg4, \reg5, \reg6, \reg7, \reg8}
+        .endm
+
+        .macro str1b ptr reg cond=al abort
+        str\cond\()b \reg, [\ptr], #1
+        .endm
+
+        .macro enter reg1 reg2
+        stmdb sp!, {r0, \reg1, \reg2}
+        .endm
+
+        .macro exit reg1 reg2
+        ldmfd sp!, {r0, \reg1, \reg2}
+        .endm
+
+        .text
+
+/* Prototype: void *memcpy(void *dest, const void *src, size_t n); */
+
+ENTRY(memcpy)
+
+#include "copy_template.S"
+
+ENDPROC(memcpy)
diff --git a/xen/arch/arm/lib/memmove.S b/xen/arch/arm/lib/memmove.S
new file mode 100644
index 0000000..4e142b8
--- /dev/null
+++ b/xen/arch/arm/lib/memmove.S
@@ -0,0 +1,200 @@
+/*
+ *  linux/arch/arm/lib/memmove.S
+ *
+ *  Author:	Nicolas Pitre
+ *  Created:	Sep 28, 2005
+ *  Copyright:	(C) MontaVista Software Inc.
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License version 2 as
+ *  published by the Free Software Foundation.
+ */
+
+#include <xen/config.h>
+
+#include "assembler.h"
+
+		.text
+
+/*
+ * Prototype: void *memmove(void *dest, const void *src, size_t n);
+ *
+ * Note:
+ *
+ * If the memory regions don't overlap, we simply branch to memcpy which is
+ * normally a bit faster. Otherwise the copy is done going downwards.  This
+ * is a transposition of the code from copy_template.S but with the copy
+ * occurring in the opposite direction.
+ */
+
+ENTRY(memmove)
+
+		subs	ip, r0, r1
+		cmphi	r2, ip
+		bls	memcpy
+
+		stmfd	sp!, {r0, r4, lr}
+		add	r1, r1, r2
+		add	r0, r0, r2
+		subs	r2, r2, #4
+		blt	8f
+		ands	ip, r0, #3
+	PLD(	pld	[r1, #-4]		)
+		bne	9f
+		ands	ip, r1, #3
+		bne	10f
+
+1:		subs	r2, r2, #(28)
+		stmfd	sp!, {r5 - r8}
+		blt	5f
+
+	CALGN(	ands	ip, r0, #31		)
+	CALGN(	sbcnes	r4, ip, r2		)  @ C is always set here
+	CALGN(	bcs	2f			)
+	CALGN(	adr	r4, 6f			)
+	CALGN(	subs	r2, r2, ip		)  @ C is set here
+	CALGN(	rsb	ip, ip, #32		)
+	CALGN(	add	pc, r4, ip		)
+
+	PLD(	pld	[r1, #-4]		)
+2:	PLD(	subs	r2, r2, #96		)
+	PLD(	pld	[r1, #-32]		)
+	PLD(	blt	4f			)
+	PLD(	pld	[r1, #-64]		)
+	PLD(	pld	[r1, #-96]		)
+
+3:	PLD(	pld	[r1, #-128]		)
+4:		ldmdb	r1!, {r3, r4, r5, r6, r7, r8, ip, lr}
+		subs	r2, r2, #32
+		stmdb	r0!, {r3, r4, r5, r6, r7, r8, ip, lr}
+		bge	3b
+	PLD(	cmn	r2, #96			)
+	PLD(	bge	4b			)
+
+5:		ands	ip, r2, #28
+		rsb	ip, ip, #32
+		addne	pc, pc, ip		@ C is always clear here
+		b	7f
+6:		W(nop)
+		W(ldr)	r3, [r1, #-4]!
+		W(ldr)	r4, [r1, #-4]!
+		W(ldr)	r5, [r1, #-4]!
+		W(ldr)	r6, [r1, #-4]!
+		W(ldr)	r7, [r1, #-4]!
+		W(ldr)	r8, [r1, #-4]!
+		W(ldr)	lr, [r1, #-4]!
+
+		add	pc, pc, ip
+		nop
+		W(nop)
+		W(str)	r3, [r0, #-4]!
+		W(str)	r4, [r0, #-4]!
+		W(str)	r5, [r0, #-4]!
+		W(str)	r6, [r0, #-4]!
+		W(str)	r7, [r0, #-4]!
+		W(str)	r8, [r0, #-4]!
+		W(str)	lr, [r0, #-4]!
+
+	CALGN(	bcs	2b			)
+
+7:		ldmfd	sp!, {r5 - r8}
+
+8:		movs	r2, r2, lsl #31
+		ldrneb	r3, [r1, #-1]!
+		ldrcsb	r4, [r1, #-1]!
+		ldrcsb	ip, [r1, #-1]
+		strneb	r3, [r0, #-1]!
+		strcsb	r4, [r0, #-1]!
+		strcsb	ip, [r0, #-1]
+		ldmfd	sp!, {r0, r4, pc}
+
+9:		cmp	ip, #2
+		ldrgtb	r3, [r1, #-1]!
+		ldrgeb	r4, [r1, #-1]!
+		ldrb	lr, [r1, #-1]!
+		strgtb	r3, [r0, #-1]!
+		strgeb	r4, [r0, #-1]!
+		subs	r2, r2, ip
+		strb	lr, [r0, #-1]!
+		blt	8b
+		ands	ip, r1, #3
+		beq	1b
+
+10:		bic	r1, r1, #3
+		cmp	ip, #2
+		ldr	r3, [r1, #0]
+		beq	17f
+		blt	18f
+
+
+		.macro	backward_copy_shift push pull
+
+		subs	r2, r2, #28
+		blt	14f
+
+	CALGN(	ands	ip, r0, #31		)
+	CALGN(	sbcnes	r4, ip, r2		)  @ C is always set here
+	CALGN(	subcc	r2, r2, ip		)
+	CALGN(	bcc	15f			)
+
+11:		stmfd	sp!, {r5 - r9}
+
+	PLD(	pld	[r1, #-4]		)
+	PLD(	subs	r2, r2, #96		)
+	PLD(	pld	[r1, #-32]		)
+	PLD(	blt	13f			)
+	PLD(	pld	[r1, #-64]		)
+	PLD(	pld	[r1, #-96]		)
+
+12:	PLD(	pld	[r1, #-128]		)
+13:		ldmdb   r1!, {r7, r8, r9, ip}
+		mov     lr, r3, push #\push
+		subs    r2, r2, #32
+		ldmdb   r1!, {r3, r4, r5, r6}
+		orr     lr, lr, ip, pull #\pull
+		mov     ip, ip, push #\push
+		orr     ip, ip, r9, pull #\pull
+		mov     r9, r9, push #\push
+		orr     r9, r9, r8, pull #\pull
+		mov     r8, r8, push #\push
+		orr     r8, r8, r7, pull #\pull
+		mov     r7, r7, push #\push
+		orr     r7, r7, r6, pull #\pull
+		mov     r6, r6, push #\push
+		orr     r6, r6, r5, pull #\pull
+		mov     r5, r5, push #\push
+		orr     r5, r5, r4, pull #\pull
+		mov     r4, r4, push #\push
+		orr     r4, r4, r3, pull #\pull
+		stmdb   r0!, {r4 - r9, ip, lr}
+		bge	12b
+	PLD(	cmn	r2, #96			)
+	PLD(	bge	13b			)
+
+		ldmfd	sp!, {r5 - r9}
+
+14:		ands	ip, r2, #28
+		beq	16f
+
+15:		mov     lr, r3, push #\push
+		ldr	r3, [r1, #-4]!
+		subs	ip, ip, #4
+		orr	lr, lr, r3, pull #\pull
+		str	lr, [r0, #-4]!
+		bgt	15b
+	CALGN(	cmp	r2, #0			)
+	CALGN(	bge	11b			)
+
+16:		add	r1, r1, #(\pull / 8)
+		b	8b
+
+		.endm
+
+
+		backward_copy_shift	push=8	pull=24
+
+17:		backward_copy_shift	push=16	pull=16
+
+18:		backward_copy_shift	push=24	pull=8
+
+ENDPROC(memmove)
diff --git a/xen/arch/arm/lib/memset.S b/xen/arch/arm/lib/memset.S
new file mode 100644
index 0000000..d2937a3
--- /dev/null
+++ b/xen/arch/arm/lib/memset.S
@@ -0,0 +1,129 @@
+/*
+ *  linux/arch/arm/lib/memset.S
+ *
+ *  Copyright (C) 1995-2000 Russell King
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ *  ASM optimised string functions
+ */
+
+#include <xen/config.h>
+
+#include "assembler.h"
+
+	.text
+	.align	5
+	.word	0
+
+1:	subs	r2, r2, #4		@ 1 do we have enough
+	blt	5f			@ 1 bytes to align with?
+	cmp	r3, #2			@ 1
+	strltb	r1, [r0], #1		@ 1
+	strleb	r1, [r0], #1		@ 1
+	strb	r1, [r0], #1		@ 1
+	add	r2, r2, r3		@ 1 (r2 = r2 - (4 - r3))
+/*
+ * The pointer is now aligned and the length is adjusted.  Try doing the
+ * memset again.
+ */
+
+ENTRY(memset)
+	ands	r3, r0, #3		@ 1 unaligned?
+	bne	1b			@ 1
+/*
+ * we know that the pointer in r0 is aligned to a word boundary.
+ */
+	orr	r1, r1, r1, lsl #8
+	orr	r1, r1, r1, lsl #16
+	mov	r3, r1
+	cmp	r2, #16
+	blt	4f
+
+#if ! CALGN(1)+0
+
+/*
+ * We need an extra register for this loop - save the return address and
+ * use the LR
+ */
+	str	lr, [sp, #-4]!
+	mov	ip, r1
+	mov	lr, r1
+
+2:	subs	r2, r2, #64
+	stmgeia	r0!, {r1, r3, ip, lr}	@ 64 bytes at a time.
+	stmgeia	r0!, {r1, r3, ip, lr}
+	stmgeia	r0!, {r1, r3, ip, lr}
+	stmgeia	r0!, {r1, r3, ip, lr}
+	bgt	2b
+	ldmeqfd	sp!, {pc}		@ Now <64 bytes to go.
+/*
+ * No need to correct the count; we're only testing bits from now on
+ */
+	tst	r2, #32
+	stmneia	r0!, {r1, r3, ip, lr}
+	stmneia	r0!, {r1, r3, ip, lr}
+	tst	r2, #16
+	stmneia	r0!, {r1, r3, ip, lr}
+	ldr	lr, [sp], #4
+
+#else
+
+/*
+ * This version aligns the destination pointer in order to write
+ * whole cache lines at once.
+ */
+
+	stmfd	sp!, {r4-r7, lr}
+	mov	r4, r1
+	mov	r5, r1
+	mov	r6, r1
+	mov	r7, r1
+	mov	ip, r1
+	mov	lr, r1
+
+	cmp	r2, #96
+	tstgt	r0, #31
+	ble	3f
+
+	and	ip, r0, #31
+	rsb	ip, ip, #32
+	sub	r2, r2, ip
+	movs	ip, ip, lsl #(32 - 4)
+	stmcsia	r0!, {r4, r5, r6, r7}
+	stmmiia	r0!, {r4, r5}
+	tst	ip, #(1 << 30)
+	mov	ip, r1
+	strne	r1, [r0], #4
+
+3:	subs	r2, r2, #64
+	stmgeia	r0!, {r1, r3-r7, ip, lr}
+	stmgeia	r0!, {r1, r3-r7, ip, lr}
+	bgt	3b
+	ldmeqfd	sp!, {r4-r7, pc}
+
+	tst	r2, #32
+	stmneia	r0!, {r1, r3-r7, ip, lr}
+	tst	r2, #16
+	stmneia	r0!, {r4-r7}
+	ldmfd	sp!, {r4-r7, lr}
+
+#endif
+
+4:	tst	r2, #8
+	stmneia	r0!, {r1, r3}
+	tst	r2, #4
+	strne	r1, [r0], #4
+/*
+ * When we get here, we've got less than 4 bytes to zero.  We
+ * may have an unaligned pointer as well.
+ */
+5:	tst	r2, #2
+	strneb	r1, [r0], #1
+	strneb	r1, [r0], #1
+	tst	r2, #1
+	strneb	r1, [r0], #1
+	mov	pc, lr
+ENDPROC(memset)
diff --git a/xen/arch/arm/lib/memzero.S b/xen/arch/arm/lib/memzero.S
new file mode 100644
index 0000000..ce25aca
--- /dev/null
+++ b/xen/arch/arm/lib/memzero.S
@@ -0,0 +1,127 @@
+/*
+ *  linux/arch/arm/lib/memzero.S
+ *
+ *  Copyright (C) 1995-2000 Russell King
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <xen/config.h>
+
+#include "assembler.h"
+
+	.text
+	.align	5
+	.word	0
+/*
+ * Align the pointer in r0.  r3 contains the number of bytes that we are
+ * mis-aligned by, and r1 is the number of bytes.  If r1 < 4, then we
+ * don't bother; we use byte stores instead.
+ */
+1:	subs	r1, r1, #4		@ 1 do we have enough
+	blt	5f			@ 1 bytes to align with?
+	cmp	r3, #2			@ 1
+	strltb	r2, [r0], #1		@ 1
+	strleb	r2, [r0], #1		@ 1
+	strb	r2, [r0], #1		@ 1
+	add	r1, r1, r3		@ 1 (r1 = r1 - (4 - r3))
+/*
+ * The pointer is now aligned and the length is adjusted.  Try doing the
+ * memzero again.
+ */
+
+ENTRY(__memzero)
+	mov	r2, #0			@ 1
+	ands	r3, r0, #3		@ 1 unaligned?
+	bne	1b			@ 1
+/*
+ * r3 = 0, and we know that the pointer in r0 is aligned to a word boundary.
+ */
+	cmp	r1, #16			@ 1 we can skip this chunk if we
+	blt	4f			@ 1 have < 16 bytes
+
+#if ! CALGN(1)+0
+
+/*
+ * We need an extra register for this loop - save the return address and
+ * use the LR
+ */
+	str	lr, [sp, #-4]!		@ 1
+	mov	ip, r2			@ 1
+	mov	lr, r2			@ 1
+
+3:	subs	r1, r1, #64		@ 1 write 32 bytes out per loop
+	stmgeia	r0!, {r2, r3, ip, lr}	@ 4
+	stmgeia	r0!, {r2, r3, ip, lr}	@ 4
+	stmgeia	r0!, {r2, r3, ip, lr}	@ 4
+	stmgeia	r0!, {r2, r3, ip, lr}	@ 4
+	bgt	3b			@ 1
+	ldmeqfd	sp!, {pc}		@ 1/2 quick exit
+/*
+ * No need to correct the count; we're only testing bits from now on
+ */
+	tst	r1, #32			@ 1
+	stmneia	r0!, {r2, r3, ip, lr}	@ 4
+	stmneia	r0!, {r2, r3, ip, lr}	@ 4
+	tst	r1, #16			@ 1 16 bytes or more?
+	stmneia	r0!, {r2, r3, ip, lr}	@ 4
+	ldr	lr, [sp], #4		@ 1
+
+#else
+
+/*
+ * This version aligns the destination pointer in order to write
+ * whole cache lines at once.
+ */
+
+	stmfd	sp!, {r4-r7, lr}
+	mov	r4, r2
+	mov	r5, r2
+	mov	r6, r2
+	mov	r7, r2
+	mov	ip, r2
+	mov	lr, r2
+
+	cmp	r1, #96
+	andgts	ip, r0, #31
+	ble	3f
+
+	rsb	ip, ip, #32
+	sub	r1, r1, ip
+	movs	ip, ip, lsl #(32 - 4)
+	stmcsia	r0!, {r4, r5, r6, r7}
+	stmmiia	r0!, {r4, r5}
+	movs	ip, ip, lsl #2
+	strcs	r2, [r0], #4
+
+3:	subs	r1, r1, #64
+	stmgeia	r0!, {r2-r7, ip, lr}
+	stmgeia	r0!, {r2-r7, ip, lr}
+	bgt	3b
+	ldmeqfd	sp!, {r4-r7, pc}
+
+	tst	r1, #32
+	stmneia	r0!, {r2-r7, ip, lr}
+	tst	r1, #16
+	stmneia	r0!, {r4-r7}
+	ldmfd	sp!, {r4-r7, lr}
+
+#endif
+
+4:	tst	r1, #8			@ 1 8 bytes or more?
+	stmneia	r0!, {r2, r3}		@ 2
+	tst	r1, #4			@ 1 4 bytes or more?
+	strne	r2, [r0], #4		@ 1
+/*
+ * When we get here, we've got less than 4 bytes to zero.  We
+ * may have an unaligned pointer as well.
+ */
+5:	tst	r1, #2			@ 1 2 bytes or more?
+	strneb	r2, [r0], #1		@ 1
+	strneb	r2, [r0], #1		@ 1
+	tst	r1, #1			@ 1 a byte left over
+	strneb	r2, [r0], #1		@ 1
+	mov	pc, lr			@ 1
+ENDPROC(__memzero)
diff --git a/xen/arch/arm/lib/setbit.S b/xen/arch/arm/lib/setbit.S
new file mode 100644
index 0000000..c828851
--- /dev/null
+++ b/xen/arch/arm/lib/setbit.S
@@ -0,0 +1,18 @@
+/*
+ *  linux/arch/arm/lib/setbit.S
+ *
+ *  Copyright (C) 1995-1996 Russell King
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#include <xen/config.h>
+
+#include "assembler.h"
+#include "bitops.h"
+	.text
+
+ENTRY(_set_bit)
+	bitop	orr
+ENDPROC(_set_bit)
diff --git a/xen/arch/arm/lib/testchangebit.S b/xen/arch/arm/lib/testchangebit.S
new file mode 100644
index 0000000..a7f527c
--- /dev/null
+++ b/xen/arch/arm/lib/testchangebit.S
@@ -0,0 +1,18 @@
+/*
+ *  linux/arch/arm/lib/testchangebit.S
+ *
+ *  Copyright (C) 1995-1996 Russell King
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#include <xen/config.h>
+
+#include "assembler.h"
+#include "bitops.h"
+                .text
+
+ENTRY(_test_and_change_bit)
+	testop	eor, str
+ENDPROC(_test_and_change_bit)
diff --git a/xen/arch/arm/lib/testclearbit.S b/xen/arch/arm/lib/testclearbit.S
new file mode 100644
index 0000000..8f39c72
--- /dev/null
+++ b/xen/arch/arm/lib/testclearbit.S
@@ -0,0 +1,18 @@
+/*
+ *  linux/arch/arm/lib/testclearbit.S
+ *
+ *  Copyright (C) 1995-1996 Russell King
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#include <xen/config.h>
+
+#include "assembler.h"
+#include "bitops.h"
+                .text
+
+ENTRY(_test_and_clear_bit)
+	testop	bicne, strne
+ENDPROC(_test_and_clear_bit)
diff --git a/xen/arch/arm/lib/testsetbit.S b/xen/arch/arm/lib/testsetbit.S
new file mode 100644
index 0000000..1b8d273
--- /dev/null
+++ b/xen/arch/arm/lib/testsetbit.S
@@ -0,0 +1,18 @@
+/*
+ *  linux/arch/arm/lib/testsetbit.S
+ *
+ *  Copyright (C) 1995-1996 Russell King
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#include <xen/config.h>
+
+#include "assembler.h"
+#include "bitops.h"
+                .text
+
+ENTRY(_test_and_set_bit)
+	testop	orreq, streq
+ENDPROC(_test_and_set_bit)
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 18:20:40 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 18:20:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXzd6-00082E-LS; Tue, 06 Dec 2011 18:20:36 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RXzd4-0007vK-6N
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 18:20:34 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1323195545!51363948!4
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMzAwOTc=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4124 invoked from network); 6 Dec 2011 18:19:15 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Dec 2011 18:19:15 -0000
X-IronPort-AV: E=Sophos;i="4.71,307,1320642000"; d="scan'208";a="173120749"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Dec 2011 13:19:46 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Tue, 6 Dec 2011 13:19:46 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pB6IJEjL019549;
	Tue, 6 Dec 2011 10:19:29 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Tue, 6 Dec 2011 18:19:55 +0000
Message-ID: <1323195609-17277-11-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1112061753410.31179@kaball-desktop>
References: <alpine.DEB.2.00.1112061753410.31179@kaball-desktop>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>, Tim.Deegan@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH RFC 11/25] arm: bit manipulation,
	copy and division libraries
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Bit manipulation, division and memcpy & friends implementations for the
ARM architecture, shamelessly taken from Linux.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
---
 xen/arch/arm/lib/Makefile        |    5 +
 xen/arch/arm/lib/assembler.h     |   49 +++++++
 xen/arch/arm/lib/bitops.h        |   36 +++++
 xen/arch/arm/lib/changebit.S     |   18 +++
 xen/arch/arm/lib/clearbit.S      |   19 +++
 xen/arch/arm/lib/copy_template.S |  266 ++++++++++++++++++++++++++++++++++++
 xen/arch/arm/lib/div64.S         |  149 +++++++++++++++++++++
 xen/arch/arm/lib/findbit.S       |  115 ++++++++++++++++
 xen/arch/arm/lib/lib1funcs.S     |  274 ++++++++++++++++++++++++++++++++++++++
 xen/arch/arm/lib/memcpy.S        |   64 +++++++++
 xen/arch/arm/lib/memmove.S       |  200 +++++++++++++++++++++++++++
 xen/arch/arm/lib/memset.S        |  129 ++++++++++++++++++
 xen/arch/arm/lib/memzero.S       |  127 ++++++++++++++++++
 xen/arch/arm/lib/setbit.S        |   18 +++
 xen/arch/arm/lib/testchangebit.S |   18 +++
 xen/arch/arm/lib/testclearbit.S  |   18 +++
 xen/arch/arm/lib/testsetbit.S    |   18 +++
 17 files changed, 1523 insertions(+), 0 deletions(-)
 create mode 100644 xen/arch/arm/lib/Makefile
 create mode 100644 xen/arch/arm/lib/assembler.h
 create mode 100644 xen/arch/arm/lib/bitops.h
 create mode 100644 xen/arch/arm/lib/changebit.S
 create mode 100644 xen/arch/arm/lib/clearbit.S
 create mode 100644 xen/arch/arm/lib/copy_template.S
 create mode 100644 xen/arch/arm/lib/div64.S
 create mode 100644 xen/arch/arm/lib/findbit.S
 create mode 100644 xen/arch/arm/lib/lib1funcs.S
 create mode 100644 xen/arch/arm/lib/memcpy.S
 create mode 100644 xen/arch/arm/lib/memmove.S
 create mode 100644 xen/arch/arm/lib/memset.S
 create mode 100644 xen/arch/arm/lib/memzero.S
 create mode 100644 xen/arch/arm/lib/setbit.S
 create mode 100644 xen/arch/arm/lib/testchangebit.S
 create mode 100644 xen/arch/arm/lib/testclearbit.S
 create mode 100644 xen/arch/arm/lib/testsetbit.S

diff --git a/xen/arch/arm/lib/Makefile b/xen/arch/arm/lib/Makefile
new file mode 100644
index 0000000..cbbed68
--- /dev/null
+++ b/xen/arch/arm/lib/Makefile
@@ -0,0 +1,5 @@
+obj-y += memcpy.o memmove.o memset.o memzero.o
+obj-y += findbit.o setbit.o
+obj-y += setbit.o clearbit.o changebit.o
+obj-y += testsetbit.o testclearbit.o testchangebit.o
+obj-y += lib1funcs.o div64.o
diff --git a/xen/arch/arm/lib/assembler.h b/xen/arch/arm/lib/assembler.h
new file mode 100644
index 0000000..f8f0961
--- /dev/null
+++ b/xen/arch/arm/lib/assembler.h
@@ -0,0 +1,49 @@
+#ifndef __ARCH_ARM_LIB_ASSEMBLER_H__
+#define __ARCH_ARM_LIB_ASSEMBLER_H__
+
+/* From Linux arch/arm/include/asm/assembler.h */
+/*
+ * Data preload for architectures that support it
+ */
+#define PLD(code...)    code
+
+/*
+ * This can be used to enable code to cacheline align the destination
+ * pointer when bulk writing to memory.  Experiments on StrongARM and
+ * XScale didn't show this a worthwhile thing to do when the cache is not
+ * set to write-allocate (this would need further testing on XScale when WA
+ * is used).
+ *
+ * On Feroceon there is much to gain however, regardless of cache mode.
+ */
+#ifdef CONFIG_CPU_FEROCEON /* Not in Xen... */
+#define CALGN(code...) code
+#else
+#define CALGN(code...)
+#endif
+
+// No Thumb, hence:
+#define W(instr)        instr
+#define ARM(instr...)   instr
+#define THUMB(instr...)
+
+#ifdef CONFIG_ARM_UNWIND
+#define UNWIND(code...)         code
+#else
+#define UNWIND(code...)
+#endif
+
+#define pull            lsl
+#define push            lsr
+#define get_byte_0      lsr #24
+#define get_byte_1      lsr #16
+#define get_byte_2      lsr #8
+#define get_byte_3      lsl #0
+#define put_byte_0      lsl #24
+#define put_byte_1      lsl #16
+#define put_byte_2      lsl #8
+#define put_byte_3      lsl #0
+
+#define smp_dmb dmb
+
+#endif /*  __ARCH_ARM_LIB_ASSEMBLER_H__ */
diff --git a/xen/arch/arm/lib/bitops.h b/xen/arch/arm/lib/bitops.h
new file mode 100644
index 0000000..e56d4e8
--- /dev/null
+++ b/xen/arch/arm/lib/bitops.h
@@ -0,0 +1,36 @@
+	.macro	bitop, instr
+	ands	ip, r1, #3
+	strneb	r1, [ip]		@ assert word-aligned
+	mov	r2, #1
+	and	r3, r0, #31		@ Get bit offset
+	mov	r0, r0, lsr #5
+	add	r1, r1, r0, lsl #2	@ Get word offset
+	mov	r3, r2, lsl r3
+1:	ldrex	r2, [r1]
+	\instr	r2, r2, r3
+	strex	r0, r2, [r1]
+	cmp	r0, #0
+	bne	1b
+	bx	lr
+	.endm
+
+	.macro	testop, instr, store
+	ands	ip, r1, #3
+	strneb	r1, [ip]		@ assert word-aligned
+	mov	r2, #1
+	and	r3, r0, #31		@ Get bit offset
+	mov	r0, r0, lsr #5
+	add	r1, r1, r0, lsl #2	@ Get word offset
+	mov	r3, r2, lsl r3		@ create mask
+	smp_dmb
+1:	ldrex	r2, [r1]
+	ands	r0, r2, r3		@ save old value of bit
+	\instr	r2, r2, r3		@ toggle bit
+	strex	ip, r2, [r1]
+	cmp	ip, #0
+	bne	1b
+	smp_dmb
+	cmp	r0, #0
+	movne	r0, #1
+2:	bx	lr
+	.endm
diff --git a/xen/arch/arm/lib/changebit.S b/xen/arch/arm/lib/changebit.S
new file mode 100644
index 0000000..62954bc
--- /dev/null
+++ b/xen/arch/arm/lib/changebit.S
@@ -0,0 +1,18 @@
+/*
+ *  linux/arch/arm/lib/changebit.S
+ *
+ *  Copyright (C) 1995-1996 Russell King
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#include <xen/config.h>
+
+#include "assembler.h"
+#include "bitops.h"
+                .text
+
+ENTRY(_change_bit)
+	bitop	eor
+ENDPROC(_change_bit)
diff --git a/xen/arch/arm/lib/clearbit.S b/xen/arch/arm/lib/clearbit.S
new file mode 100644
index 0000000..42ce416
--- /dev/null
+++ b/xen/arch/arm/lib/clearbit.S
@@ -0,0 +1,19 @@
+/*
+ *  linux/arch/arm/lib/clearbit.S
+ *
+ *  Copyright (C) 1995-1996 Russell King
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <xen/config.h>
+
+#include "assembler.h"
+#include "bitops.h"
+                .text
+
+ENTRY(_clear_bit)
+	bitop	bic
+ENDPROC(_clear_bit)
diff --git a/xen/arch/arm/lib/copy_template.S b/xen/arch/arm/lib/copy_template.S
new file mode 100644
index 0000000..7f7f4d5
--- /dev/null
+++ b/xen/arch/arm/lib/copy_template.S
@@ -0,0 +1,266 @@
+/*
+ *  linux/arch/arm/lib/copy_template.s
+ *
+ *  Code template for optimized memory copy functions
+ *
+ *  Author:	Nicolas Pitre
+ *  Created:	Sep 28, 2005
+ *  Copyright:	MontaVista Software, Inc.
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License version 2 as
+ *  published by the Free Software Foundation.
+ */
+
+/*
+ * Theory of operation
+ * -------------------
+ *
+ * This file provides the core code for a forward memory copy used in
+ * the implementation of memcopy(), copy_to_user() and copy_from_user().
+ *
+ * The including file must define the following accessor macros
+ * according to the need of the given function:
+ *
+ * ldr1w ptr reg abort
+ *
+ *	This loads one word from 'ptr', stores it in 'reg' and increments
+ *	'ptr' to the next word. The 'abort' argument is used for fixup tables.
+ *
+ * ldr4w ptr reg1 reg2 reg3 reg4 abort
+ * ldr8w ptr, reg1 reg2 reg3 reg4 reg5 reg6 reg7 reg8 abort
+ *
+ *	This loads four or eight words starting from 'ptr', stores them
+ *	in provided registers and increments 'ptr' past those words.
+ *	The'abort' argument is used for fixup tables.
+ *
+ * ldr1b ptr reg cond abort
+ *
+ *	Similar to ldr1w, but it loads a byte and increments 'ptr' one byte.
+ *	It also must apply the condition code if provided, otherwise the
+ *	"al" condition is assumed by default.
+ *
+ * str1w ptr reg abort
+ * str8w ptr reg1 reg2 reg3 reg4 reg5 reg6 reg7 reg8 abort
+ * str1b ptr reg cond abort
+ *
+ *	Same as their ldr* counterparts, but data is stored to 'ptr' location
+ *	rather than being loaded.
+ *
+ * enter reg1 reg2
+ *
+ *	Preserve the provided registers on the stack plus any additional
+ *	data as needed by the implementation including this code. Called
+ *	upon code entry.
+ *
+ * exit reg1 reg2
+ *
+ *	Restore registers with the values previously saved with the
+ *	'preserv' macro. Called upon code termination.
+ *
+ * LDR1W_SHIFT
+ * STR1W_SHIFT
+ *
+ *	Correction to be applied to the "ip" register when branching into
+ *	the ldr1w or str1w instructions (some of these macros may expand to
+ *	than one 32bit instruction in Thumb-2)
+ */
+
+		enter	r4, lr
+
+		subs	r2, r2, #4
+		blt	8f
+		ands	ip, r0, #3
+	PLD(	pld	[r1, #0]		)
+		bne	9f
+		ands	ip, r1, #3
+		bne	10f
+
+1:		subs	r2, r2, #(28)
+		stmfd	sp!, {r5 - r8}
+		blt	5f
+
+	CALGN(	ands	ip, r0, #31		)
+	CALGN(	rsb	r3, ip, #32		)
+	CALGN(	sbcnes	r4, r3, r2		)  @ C is always set here
+	CALGN(	bcs	2f			)
+	CALGN(	adr	r4, 6f			)
+	CALGN(	subs	r2, r2, r3		)  @ C gets set
+	CALGN(	add	pc, r4, ip		)
+
+	PLD(	pld	[r1, #0]		)
+2:	PLD(	subs	r2, r2, #96		)
+	PLD(	pld	[r1, #28]		)
+	PLD(	blt	4f			)
+	PLD(	pld	[r1, #60]		)
+	PLD(	pld	[r1, #92]		)
+
+3:	PLD(	pld	[r1, #124]		)
+4:		ldr8w	r1, r3, r4, r5, r6, r7, r8, ip, lr, abort=20f
+		subs	r2, r2, #32
+		str8w	r0, r3, r4, r5, r6, r7, r8, ip, lr, abort=20f
+		bge	3b
+	PLD(	cmn	r2, #96			)
+	PLD(	bge	4b			)
+
+5:		ands	ip, r2, #28
+		rsb	ip, ip, #32
+#if LDR1W_SHIFT > 0
+		lsl	ip, ip, #LDR1W_SHIFT
+#endif
+		addne	pc, pc, ip		@ C is always clear here
+		b	7f
+6:
+		.rept	(1 << LDR1W_SHIFT)
+		W(nop)
+		.endr
+		ldr1w	r1, r3, abort=20f
+		ldr1w	r1, r4, abort=20f
+		ldr1w	r1, r5, abort=20f
+		ldr1w	r1, r6, abort=20f
+		ldr1w	r1, r7, abort=20f
+		ldr1w	r1, r8, abort=20f
+		ldr1w	r1, lr, abort=20f
+
+#if LDR1W_SHIFT < STR1W_SHIFT
+		lsl	ip, ip, #STR1W_SHIFT - LDR1W_SHIFT
+#elif LDR1W_SHIFT > STR1W_SHIFT
+		lsr	ip, ip, #LDR1W_SHIFT - STR1W_SHIFT
+#endif
+		add	pc, pc, ip
+		nop
+		.rept	(1 << STR1W_SHIFT)
+		W(nop)
+		.endr
+		str1w	r0, r3, abort=20f
+		str1w	r0, r4, abort=20f
+		str1w	r0, r5, abort=20f
+		str1w	r0, r6, abort=20f
+		str1w	r0, r7, abort=20f
+		str1w	r0, r8, abort=20f
+		str1w	r0, lr, abort=20f
+
+	CALGN(	bcs	2b			)
+
+7:		ldmfd	sp!, {r5 - r8}
+
+8:		movs	r2, r2, lsl #31
+		ldr1b	r1, r3, ne, abort=21f
+		ldr1b	r1, r4, cs, abort=21f
+		ldr1b	r1, ip, cs, abort=21f
+		str1b	r0, r3, ne, abort=21f
+		str1b	r0, r4, cs, abort=21f
+		str1b	r0, ip, cs, abort=21f
+
+		exit	r4, pc
+
+9:		rsb	ip, ip, #4
+		cmp	ip, #2
+		ldr1b	r1, r3, gt, abort=21f
+		ldr1b	r1, r4, ge, abort=21f
+		ldr1b	r1, lr, abort=21f
+		str1b	r0, r3, gt, abort=21f
+		str1b	r0, r4, ge, abort=21f
+		subs	r2, r2, ip
+		str1b	r0, lr, abort=21f
+		blt	8b
+		ands	ip, r1, #3
+		beq	1b
+
+10:		bic	r1, r1, #3
+		cmp	ip, #2
+		ldr1w	r1, lr, abort=21f
+		beq	17f
+		bgt	18f
+
+
+		.macro	forward_copy_shift pull push
+
+		subs	r2, r2, #28
+		blt	14f
+
+	CALGN(	ands	ip, r0, #31		)
+	CALGN(	rsb	ip, ip, #32		)
+	CALGN(	sbcnes	r4, ip, r2		)  @ C is always set here
+	CALGN(	subcc	r2, r2, ip		)
+	CALGN(	bcc	15f			)
+
+11:		stmfd	sp!, {r5 - r9}
+
+	PLD(	pld	[r1, #0]		)
+	PLD(	subs	r2, r2, #96		)
+	PLD(	pld	[r1, #28]		)
+	PLD(	blt	13f			)
+	PLD(	pld	[r1, #60]		)
+	PLD(	pld	[r1, #92]		)
+
+12:	PLD(	pld	[r1, #124]		)
+13:		ldr4w	r1, r4, r5, r6, r7, abort=19f
+		mov	r3, lr, pull #\pull
+		subs	r2, r2, #32
+		ldr4w	r1, r8, r9, ip, lr, abort=19f
+		orr	r3, r3, r4, push #\push
+		mov	r4, r4, pull #\pull
+		orr	r4, r4, r5, push #\push
+		mov	r5, r5, pull #\pull
+		orr	r5, r5, r6, push #\push
+		mov	r6, r6, pull #\pull
+		orr	r6, r6, r7, push #\push
+		mov	r7, r7, pull #\pull
+		orr	r7, r7, r8, push #\push
+		mov	r8, r8, pull #\pull
+		orr	r8, r8, r9, push #\push
+		mov	r9, r9, pull #\pull
+		orr	r9, r9, ip, push #\push
+		mov	ip, ip, pull #\pull
+		orr	ip, ip, lr, push #\push
+		str8w	r0, r3, r4, r5, r6, r7, r8, r9, ip, , abort=19f
+		bge	12b
+	PLD(	cmn	r2, #96			)
+	PLD(	bge	13b			)
+
+		ldmfd	sp!, {r5 - r9}
+
+14:		ands	ip, r2, #28
+		beq	16f
+
+15:		mov	r3, lr, pull #\pull
+		ldr1w	r1, lr, abort=21f
+		subs	ip, ip, #4
+		orr	r3, r3, lr, push #\push
+		str1w	r0, r3, abort=21f
+		bgt	15b
+	CALGN(	cmp	r2, #0			)
+	CALGN(	bge	11b			)
+
+16:		sub	r1, r1, #(\push / 8)
+		b	8b
+
+		.endm
+
+
+		forward_copy_shift	pull=8	push=24
+
+17:		forward_copy_shift	pull=16	push=16
+
+18:		forward_copy_shift	pull=24	push=8
+
+
+/*
+ * Abort preamble and completion macros.
+ * If a fixup handler is required then those macros must surround it.
+ * It is assumed that the fixup code will handle the private part of
+ * the exit macro.
+ */
+
+	.macro	copy_abort_preamble
+19:	ldmfd	sp!, {r5 - r9}
+	b	21f
+20:	ldmfd	sp!, {r5 - r8}
+21:
+	.endm
+
+	.macro	copy_abort_end
+	ldmfd	sp!, {r4, pc}
+	.endm
+
diff --git a/xen/arch/arm/lib/div64.S b/xen/arch/arm/lib/div64.S
new file mode 100644
index 0000000..2584772
--- /dev/null
+++ b/xen/arch/arm/lib/div64.S
@@ -0,0 +1,149 @@
+/*
+ *  linux/arch/arm/lib/div64.S
+ *
+ *  Optimized computation of 64-bit dividend / 32-bit divisor
+ *
+ *  Author:	Nicolas Pitre
+ *  Created:	Oct 5, 2003
+ *  Copyright:	Monta Vista Software, Inc.
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License version 2 as
+ *  published by the Free Software Foundation.
+ */
+
+#include <xen/config.h>
+#include "assembler.h"
+	
+#define xl r0
+#define xh r1
+#define yl r2
+#define yh r3
+
+/*
+ * __do_div64: perform a division with 64-bit dividend and 32-bit divisor.
+ *
+ * Note: Calling convention is totally non standard for optimal code.
+ *       This is meant to be used by do_div() from include/asm/div64.h only.
+ *
+ * Input parameters:
+ * 	xh-xl	= dividend (clobbered)
+ * 	r4	= divisor (preserved)
+ *
+ * Output values:
+ * 	yh-yl	= result
+ * 	xh	= remainder
+ *
+ * Clobbered regs: xl, ip
+ */
+
+ENTRY(__do_div64)
+
+	@ Test for easy paths first.
+	subs	ip, r4, #1
+	bls	9f			@ divisor is 0 or 1
+	tst	ip, r4
+	beq	8f			@ divisor is power of 2
+
+	@ See if we need to handle upper 32-bit result.
+	cmp	xh, r4
+	mov	yh, #0
+	blo	3f
+
+	@ Align divisor with upper part of dividend.
+	@ The aligned divisor is stored in yl preserving the original.
+	@ The bit position is stored in ip.
+
+	clz	yl, r4
+	clz	ip, xh
+	sub	yl, yl, ip
+	mov	ip, #1
+	mov	ip, ip, lsl yl
+	mov	yl, r4, lsl yl
+
+	@ The division loop for needed upper bit positions.
+ 	@ Break out early if dividend reaches 0.
+2:	cmp	xh, yl
+	orrcs	yh, yh, ip
+	subcss	xh, xh, yl
+	movnes	ip, ip, lsr #1
+	mov	yl, yl, lsr #1
+	bne	2b
+
+	@ See if we need to handle lower 32-bit result.
+3:	cmp	xh, #0
+	mov	yl, #0
+	cmpeq	xl, r4
+	movlo	xh, xl
+	movlo	pc, lr
+
+	@ The division loop for lower bit positions.
+	@ Here we shift remainer bits leftwards rather than moving the
+	@ divisor for comparisons, considering the carry-out bit as well.
+	mov	ip, #0x80000000
+4:	movs	xl, xl, lsl #1
+	adcs	xh, xh, xh
+	beq	6f
+	cmpcc	xh, r4
+5:	orrcs	yl, yl, ip
+	subcs	xh, xh, r4
+	movs	ip, ip, lsr #1
+	bne	4b
+	mov	pc, lr
+
+	@ The top part of remainder became zero.  If carry is set
+	@ (the 33th bit) this is a false positive so resume the loop.
+	@ Otherwise, if lower part is also null then we are done.
+6:	bcs	5b
+	cmp	xl, #0
+	moveq	pc, lr
+
+	@ We still have remainer bits in the low part.  Bring them up.
+
+	clz	xh, xl			@ we know xh is zero here so...
+	add	xh, xh, #1
+	mov	xl, xl, lsl xh
+	mov	ip, ip, lsr xh
+
+	@ Current remainder is now 1.  It is worthless to compare with
+	@ divisor at this point since divisor can not be smaller than 3 here.
+	@ If possible, branch for another shift in the division loop.
+	@ If no bit position left then we are done.
+	movs	ip, ip, lsr #1
+	mov	xh, #1
+	bne	4b
+	mov	pc, lr
+
+8:	@ Division by a power of 2: determine what that divisor order is
+	@ then simply shift values around
+
+	clz	ip, r4
+	rsb	ip, ip, #31
+
+	mov	yh, xh, lsr ip
+	mov	yl, xl, lsr ip
+	rsb	ip, ip, #32
+ ARM(	orr	yl, yl, xh, lsl ip	)
+ THUMB(	lsl	xh, xh, ip		)
+ THUMB(	orr	yl, yl, xh		)
+	mov	xh, xl, lsl ip
+	mov	xh, xh, lsr ip
+	mov	pc, lr
+
+	@ eq -> division by 1: obvious enough...
+9:	moveq	yl, xl
+	moveq	yh, xh
+	moveq	xh, #0
+	moveq	pc, lr
+
+	@ Division by 0:
+	str	lr, [sp, #-8]!
+	bl	__div0
+
+	@ as wrong as it could be...
+	mov	yl, #0
+	mov	yh, #0
+	mov	xh, #0
+	ldr	pc, [sp], #8
+
+ENDPROC(__do_div64)
diff --git a/xen/arch/arm/lib/findbit.S b/xen/arch/arm/lib/findbit.S
new file mode 100644
index 0000000..5669b91
--- /dev/null
+++ b/xen/arch/arm/lib/findbit.S
@@ -0,0 +1,115 @@
+/*
+ *  linux/arch/arm/lib/findbit.S
+ *
+ *  Copyright (C) 1995-2000 Russell King
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * 16th March 2001 - John Ripley <jripley@sonicblue.com>
+ *   Fixed so that "size" is an exclusive not an inclusive quantity.
+ *   All users of these functions expect exclusive sizes, and may
+ *   also call with zero size.
+ * Reworked by rmk.
+ */
+
+#include <xen/config.h>
+
+#include "assembler.h"
+                .text
+
+/*
+ * Purpose  : Find a 'zero' bit
+ * Prototype: int find_first_zero_bit(void *addr, unsigned int maxbit);
+ */
+ENTRY(_find_first_zero_bit)
+		teq	r1, #0	
+		beq	3f
+		mov	r2, #0
+1:
+ ARM(		ldrb	r3, [r0, r2, lsr #3]	)
+ THUMB(		lsr	r3, r2, #3		)
+ THUMB(		ldrb	r3, [r0, r3]		)
+		eors	r3, r3, #0xff		@ invert bits
+		bne	.L_found		@ any now set - found zero bit
+		add	r2, r2, #8		@ next bit pointer
+2:		cmp	r2, r1			@ any more?
+		blo	1b
+3:		mov	r0, r1			@ no free bits
+		mov	pc, lr
+ENDPROC(_find_first_zero_bit)
+
+/*
+ * Purpose  : Find next 'zero' bit
+ * Prototype: int find_next_zero_bit(void *addr, unsigned int maxbit, int offset)
+ */
+ENTRY(_find_next_zero_bit)
+		teq	r1, #0
+		beq	3b
+		ands	ip, r2, #7
+		beq	1b			@ If new byte, goto old routine
+ ARM(		ldrb	r3, [r0, r2, lsr #3]	)
+ THUMB(		lsr	r3, r2, #3		)
+ THUMB(		ldrb	r3, [r0, r3]		)
+		eor	r3, r3, #0xff		@ now looking for a 1 bit
+		movs	r3, r3, lsr ip		@ shift off unused bits
+		bne	.L_found
+		orr	r2, r2, #7		@ if zero, then no bits here
+		add	r2, r2, #1		@ align bit pointer
+		b	2b			@ loop for next bit
+ENDPROC(_find_next_zero_bit)
+
+/*
+ * Purpose  : Find a 'one' bit
+ * Prototype: int find_first_bit(const unsigned long *addr, unsigned int maxbit);
+ */
+ENTRY(_find_first_bit)
+		teq	r1, #0	
+		beq	3f
+		mov	r2, #0
+1:
+ ARM(		ldrb	r3, [r0, r2, lsr #3]	)
+ THUMB(		lsr	r3, r2, #3		)
+ THUMB(		ldrb	r3, [r0, r3]		)
+		movs	r3, r3
+		bne	.L_found		@ any now set - found zero bit
+		add	r2, r2, #8		@ next bit pointer
+2:		cmp	r2, r1			@ any more?
+		blo	1b
+3:		mov	r0, r1			@ no free bits
+		mov	pc, lr
+ENDPROC(_find_first_bit)
+
+/*
+ * Purpose  : Find next 'one' bit
+ * Prototype: int find_next_zero_bit(void *addr, unsigned int maxbit, int offset)
+ */
+ENTRY(_find_next_bit)
+		teq	r1, #0
+		beq	3b
+		ands	ip, r2, #7
+		beq	1b			@ If new byte, goto old routine
+ ARM(		ldrb	r3, [r0, r2, lsr #3]	)
+ THUMB(		lsr	r3, r2, #3		)
+ THUMB(		ldrb	r3, [r0, r3]		)
+		movs	r3, r3, lsr ip		@ shift off unused bits
+		bne	.L_found
+		orr	r2, r2, #7		@ if zero, then no bits here
+		add	r2, r2, #1		@ align bit pointer
+		b	2b			@ loop for next bit
+ENDPROC(_find_next_bit)
+
+/*
+ * One or more bits in the LSB of r3 are assumed to be set.
+ */
+.L_found:
+		rsb	r0, r3, #0
+		and	r3, r3, r0
+		clz	r3, r3
+		rsb	r3, r3, #31
+		add	r0, r2, r3
+		cmp	r1, r0			@ Clamp to maxbit
+		movlo	r0, r1
+		mov	pc, lr
+
diff --git a/xen/arch/arm/lib/lib1funcs.S b/xen/arch/arm/lib/lib1funcs.S
new file mode 100644
index 0000000..745f4af
--- /dev/null
+++ b/xen/arch/arm/lib/lib1funcs.S
@@ -0,0 +1,274 @@
+/*
+ * linux/arch/arm/lib/lib1funcs.S: Optimized ARM division routines
+ *
+ * Author: Nicolas Pitre <nico@fluxnic.net>
+ *   - contributed to gcc-3.4 on Sep 30, 2003
+ *   - adapted for the Linux kernel on Oct 2, 2003
+ */
+
+/* Copyright 1995, 1996, 1998, 1999, 2000, 2003 Free Software Foundation, Inc.
+
+This file 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, or (at your option) any
+later version.
+
+In addition to the permissions in the GNU General Public License, the
+Free Software Foundation gives you unlimited permission to link the
+compiled version of this file into combinations with other programs,
+and to distribute those combinations without any restriction coming
+from the use of this file.  (The General Public License restrictions
+do apply in other respects; for example, they cover modification of
+the file, and distribution when not linked into a combine
+executable.)
+
+This file is distributed in the hope that it will be useful, but
+WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  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; see the file COPYING.  If not, write to
+the Free Software Foundation, 59 Temple Place - Suite 330,
+Boston, MA 02111-1307, USA.  */
+
+
+#include <xen/config.h>
+#include "assembler.h"
+
+.macro ARM_DIV_BODY dividend, divisor, result, curbit
+
+	clz	\curbit, \divisor
+	clz	\result, \dividend
+	sub	\result, \curbit, \result
+	mov	\curbit, #1
+	mov	\divisor, \divisor, lsl \result
+	mov	\curbit, \curbit, lsl \result
+	mov	\result, #0
+	
+	@ Division loop
+1:	cmp	\dividend, \divisor
+	subhs	\dividend, \dividend, \divisor
+	orrhs	\result,   \result,   \curbit
+	cmp	\dividend, \divisor,  lsr #1
+	subhs	\dividend, \dividend, \divisor, lsr #1
+	orrhs	\result,   \result,   \curbit,  lsr #1
+	cmp	\dividend, \divisor,  lsr #2
+	subhs	\dividend, \dividend, \divisor, lsr #2
+	orrhs	\result,   \result,   \curbit,  lsr #2
+	cmp	\dividend, \divisor,  lsr #3
+	subhs	\dividend, \dividend, \divisor, lsr #3
+	orrhs	\result,   \result,   \curbit,  lsr #3
+	cmp	\dividend, #0			@ Early termination?
+	movnes	\curbit,   \curbit,  lsr #4	@ No, any more bits to do?
+	movne	\divisor,  \divisor, lsr #4
+	bne	1b
+
+.endm
+
+
+.macro ARM_DIV2_ORDER divisor, order
+
+	clz	\order, \divisor
+	rsb	\order, \order, #31
+
+.endm
+
+
+.macro ARM_MOD_BODY dividend, divisor, order, spare
+
+	clz	\order, \divisor
+	clz	\spare, \dividend
+	sub	\order, \order, \spare
+	mov	\divisor, \divisor, lsl \order
+
+	@ Perform all needed substractions to keep only the reminder.
+	@ Do comparisons in batch of 4 first.
+	subs	\order, \order, #3		@ yes, 3 is intended here
+	blt	2f
+
+1:	cmp	\dividend, \divisor
+	subhs	\dividend, \dividend, \divisor
+	cmp	\dividend, \divisor,  lsr #1
+	subhs	\dividend, \dividend, \divisor, lsr #1
+	cmp	\dividend, \divisor,  lsr #2
+	subhs	\dividend, \dividend, \divisor, lsr #2
+	cmp	\dividend, \divisor,  lsr #3
+	subhs	\dividend, \dividend, \divisor, lsr #3
+	cmp	\dividend, #1
+	mov	\divisor, \divisor, lsr #4
+	subges	\order, \order, #4
+	bge	1b
+
+	tst	\order, #3
+	teqne	\dividend, #0
+	beq	5f
+
+	@ Either 1, 2 or 3 comparison/substractions are left.
+2:	cmn	\order, #2
+	blt	4f
+	beq	3f
+	cmp	\dividend, \divisor
+	subhs	\dividend, \dividend, \divisor
+	mov	\divisor,  \divisor,  lsr #1
+3:	cmp	\dividend, \divisor
+	subhs	\dividend, \dividend, \divisor
+	mov	\divisor,  \divisor,  lsr #1
+4:	cmp	\dividend, \divisor
+	subhs	\dividend, \dividend, \divisor
+5:
+.endm
+
+
+ENTRY(__udivsi3)
+ENTRY(__aeabi_uidiv)
+UNWIND(.fnstart)
+
+	subs	r2, r1, #1
+	moveq	pc, lr
+	bcc	Ldiv0
+	cmp	r0, r1
+	bls	11f
+	tst	r1, r2
+	beq	12f
+
+	ARM_DIV_BODY r0, r1, r2, r3
+
+	mov	r0, r2
+	mov	pc, lr
+
+11:	moveq	r0, #1
+	movne	r0, #0
+	mov	pc, lr
+
+12:	ARM_DIV2_ORDER r1, r2
+
+	mov	r0, r0, lsr r2
+	mov	pc, lr
+
+UNWIND(.fnend)
+ENDPROC(__udivsi3)
+ENDPROC(__aeabi_uidiv)
+
+ENTRY(__umodsi3)
+UNWIND(.fnstart)
+
+	subs	r2, r1, #1			@ compare divisor with 1
+	bcc	Ldiv0
+	cmpne	r0, r1				@ compare dividend with divisor
+	moveq   r0, #0
+	tsthi	r1, r2				@ see if divisor is power of 2
+	andeq	r0, r0, r2
+	movls	pc, lr
+
+	ARM_MOD_BODY r0, r1, r2, r3
+
+	mov	pc, lr
+
+UNWIND(.fnend)
+ENDPROC(__umodsi3)
+
+ENTRY(__divsi3)
+ENTRY(__aeabi_idiv)
+UNWIND(.fnstart)
+
+	cmp	r1, #0
+	eor	ip, r0, r1			@ save the sign of the result.
+	beq	Ldiv0
+	rsbmi	r1, r1, #0			@ loops below use unsigned.
+	subs	r2, r1, #1			@ division by 1 or -1 ?
+	beq	10f
+	movs	r3, r0
+	rsbmi	r3, r0, #0			@ positive dividend value
+	cmp	r3, r1
+	bls	11f
+	tst	r1, r2				@ divisor is power of 2 ?
+	beq	12f
+
+	ARM_DIV_BODY r3, r1, r0, r2
+
+	cmp	ip, #0
+	rsbmi	r0, r0, #0
+	mov	pc, lr
+
+10:	teq	ip, r0				@ same sign ?
+	rsbmi	r0, r0, #0
+	mov	pc, lr
+
+11:	movlo	r0, #0
+	moveq	r0, ip, asr #31
+	orreq	r0, r0, #1
+	mov	pc, lr
+
+12:	ARM_DIV2_ORDER r1, r2
+
+	cmp	ip, #0
+	mov	r0, r3, lsr r2
+	rsbmi	r0, r0, #0
+	mov	pc, lr
+
+UNWIND(.fnend)
+ENDPROC(__divsi3)
+ENDPROC(__aeabi_idiv)
+
+ENTRY(__modsi3)
+UNWIND(.fnstart)
+
+	cmp	r1, #0
+	beq	Ldiv0
+	rsbmi	r1, r1, #0			@ loops below use unsigned.
+	movs	ip, r0				@ preserve sign of dividend
+	rsbmi	r0, r0, #0			@ if negative make positive
+	subs	r2, r1, #1			@ compare divisor with 1
+	cmpne	r0, r1				@ compare dividend with divisor
+	moveq	r0, #0
+	tsthi	r1, r2				@ see if divisor is power of 2
+	andeq	r0, r0, r2
+	bls	10f
+
+	ARM_MOD_BODY r0, r1, r2, r3
+
+10:	cmp	ip, #0
+	rsbmi	r0, r0, #0
+	mov	pc, lr
+
+UNWIND(.fnend)
+ENDPROC(__modsi3)
+
+ENTRY(__aeabi_uidivmod)
+UNWIND(.fnstart)
+UNWIND(.save {r0, r1, ip, lr}	)
+
+	stmfd	sp!, {r0, r1, ip, lr}
+	bl	__aeabi_uidiv
+	ldmfd	sp!, {r1, r2, ip, lr}
+	mul	r3, r0, r2
+	sub	r1, r1, r3
+	mov	pc, lr
+
+UNWIND(.fnend)
+ENDPROC(__aeabi_uidivmod)
+
+ENTRY(__aeabi_idivmod)
+UNWIND(.fnstart)
+UNWIND(.save {r0, r1, ip, lr}	)
+	stmfd	sp!, {r0, r1, ip, lr}
+	bl	__aeabi_idiv
+	ldmfd	sp!, {r1, r2, ip, lr}
+	mul	r3, r0, r2
+	sub	r1, r1, r3
+	mov	pc, lr
+
+UNWIND(.fnend)
+ENDPROC(__aeabi_idivmod)
+
+Ldiv0:
+UNWIND(.fnstart)
+UNWIND(.pad #4)
+UNWIND(.save {lr})
+	str	lr, [sp, #-8]!
+	bl	__div0
+	mov	r0, #0			@ About as wrong as it could be.
+	ldr	pc, [sp], #8
+UNWIND(.fnend)
+ENDPROC(Ldiv0)
diff --git a/xen/arch/arm/lib/memcpy.S b/xen/arch/arm/lib/memcpy.S
new file mode 100644
index 0000000..f4bad5c
--- /dev/null
+++ b/xen/arch/arm/lib/memcpy.S
@@ -0,0 +1,64 @@
+/*
+ *  linux/arch/arm/lib/memcpy.S
+ *
+ *  Author:     Nicolas Pitre
+ *  Created:    Sep 28, 2005
+ *  Copyright:  MontaVista Software, Inc.
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License version 2 as
+ *  published by the Free Software Foundation.
+ */
+
+#include <xen/config.h>
+
+#include "assembler.h"
+
+#define LDR1W_SHIFT     0
+#define STR1W_SHIFT     0
+
+        .macro ldr1w ptr reg abort
+        W(ldr) \reg, [\ptr], #4
+        .endm
+
+        .macro ldr4w ptr reg1 reg2 reg3 reg4 abort
+        ldmia \ptr!, {\reg1, \reg2, \reg3, \reg4}
+        .endm
+
+        .macro ldr8w ptr reg1 reg2 reg3 reg4 reg5 reg6 reg7 reg8 abort
+        ldmia \ptr!, {\reg1, \reg2, \reg3, \reg4, \reg5, \reg6, \reg7, \reg8}
+        .endm
+
+        .macro ldr1b ptr reg cond=al abort
+        ldr\cond\()b \reg, [\ptr], #1
+        .endm
+
+        .macro str1w ptr reg abort
+        W(str) \reg, [\ptr], #4
+        .endm
+
+        .macro str8w ptr reg1 reg2 reg3 reg4 reg5 reg6 reg7 reg8 abort
+        stmia \ptr!, {\reg1, \reg2, \reg3, \reg4, \reg5, \reg6, \reg7, \reg8}
+        .endm
+
+        .macro str1b ptr reg cond=al abort
+        str\cond\()b \reg, [\ptr], #1
+        .endm
+
+        .macro enter reg1 reg2
+        stmdb sp!, {r0, \reg1, \reg2}
+        .endm
+
+        .macro exit reg1 reg2
+        ldmfd sp!, {r0, \reg1, \reg2}
+        .endm
+
+        .text
+
+/* Prototype: void *memcpy(void *dest, const void *src, size_t n); */
+
+ENTRY(memcpy)
+
+#include "copy_template.S"
+
+ENDPROC(memcpy)
diff --git a/xen/arch/arm/lib/memmove.S b/xen/arch/arm/lib/memmove.S
new file mode 100644
index 0000000..4e142b8
--- /dev/null
+++ b/xen/arch/arm/lib/memmove.S
@@ -0,0 +1,200 @@
+/*
+ *  linux/arch/arm/lib/memmove.S
+ *
+ *  Author:	Nicolas Pitre
+ *  Created:	Sep 28, 2005
+ *  Copyright:	(C) MontaVista Software Inc.
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License version 2 as
+ *  published by the Free Software Foundation.
+ */
+
+#include <xen/config.h>
+
+#include "assembler.h"
+
+		.text
+
+/*
+ * Prototype: void *memmove(void *dest, const void *src, size_t n);
+ *
+ * Note:
+ *
+ * If the memory regions don't overlap, we simply branch to memcpy which is
+ * normally a bit faster. Otherwise the copy is done going downwards.  This
+ * is a transposition of the code from copy_template.S but with the copy
+ * occurring in the opposite direction.
+ */
+
+ENTRY(memmove)
+
+		subs	ip, r0, r1
+		cmphi	r2, ip
+		bls	memcpy
+
+		stmfd	sp!, {r0, r4, lr}
+		add	r1, r1, r2
+		add	r0, r0, r2
+		subs	r2, r2, #4
+		blt	8f
+		ands	ip, r0, #3
+	PLD(	pld	[r1, #-4]		)
+		bne	9f
+		ands	ip, r1, #3
+		bne	10f
+
+1:		subs	r2, r2, #(28)
+		stmfd	sp!, {r5 - r8}
+		blt	5f
+
+	CALGN(	ands	ip, r0, #31		)
+	CALGN(	sbcnes	r4, ip, r2		)  @ C is always set here
+	CALGN(	bcs	2f			)
+	CALGN(	adr	r4, 6f			)
+	CALGN(	subs	r2, r2, ip		)  @ C is set here
+	CALGN(	rsb	ip, ip, #32		)
+	CALGN(	add	pc, r4, ip		)
+
+	PLD(	pld	[r1, #-4]		)
+2:	PLD(	subs	r2, r2, #96		)
+	PLD(	pld	[r1, #-32]		)
+	PLD(	blt	4f			)
+	PLD(	pld	[r1, #-64]		)
+	PLD(	pld	[r1, #-96]		)
+
+3:	PLD(	pld	[r1, #-128]		)
+4:		ldmdb	r1!, {r3, r4, r5, r6, r7, r8, ip, lr}
+		subs	r2, r2, #32
+		stmdb	r0!, {r3, r4, r5, r6, r7, r8, ip, lr}
+		bge	3b
+	PLD(	cmn	r2, #96			)
+	PLD(	bge	4b			)
+
+5:		ands	ip, r2, #28
+		rsb	ip, ip, #32
+		addne	pc, pc, ip		@ C is always clear here
+		b	7f
+6:		W(nop)
+		W(ldr)	r3, [r1, #-4]!
+		W(ldr)	r4, [r1, #-4]!
+		W(ldr)	r5, [r1, #-4]!
+		W(ldr)	r6, [r1, #-4]!
+		W(ldr)	r7, [r1, #-4]!
+		W(ldr)	r8, [r1, #-4]!
+		W(ldr)	lr, [r1, #-4]!
+
+		add	pc, pc, ip
+		nop
+		W(nop)
+		W(str)	r3, [r0, #-4]!
+		W(str)	r4, [r0, #-4]!
+		W(str)	r5, [r0, #-4]!
+		W(str)	r6, [r0, #-4]!
+		W(str)	r7, [r0, #-4]!
+		W(str)	r8, [r0, #-4]!
+		W(str)	lr, [r0, #-4]!
+
+	CALGN(	bcs	2b			)
+
+7:		ldmfd	sp!, {r5 - r8}
+
+8:		movs	r2, r2, lsl #31
+		ldrneb	r3, [r1, #-1]!
+		ldrcsb	r4, [r1, #-1]!
+		ldrcsb	ip, [r1, #-1]
+		strneb	r3, [r0, #-1]!
+		strcsb	r4, [r0, #-1]!
+		strcsb	ip, [r0, #-1]
+		ldmfd	sp!, {r0, r4, pc}
+
+9:		cmp	ip, #2
+		ldrgtb	r3, [r1, #-1]!
+		ldrgeb	r4, [r1, #-1]!
+		ldrb	lr, [r1, #-1]!
+		strgtb	r3, [r0, #-1]!
+		strgeb	r4, [r0, #-1]!
+		subs	r2, r2, ip
+		strb	lr, [r0, #-1]!
+		blt	8b
+		ands	ip, r1, #3
+		beq	1b
+
+10:		bic	r1, r1, #3
+		cmp	ip, #2
+		ldr	r3, [r1, #0]
+		beq	17f
+		blt	18f
+
+
+		.macro	backward_copy_shift push pull
+
+		subs	r2, r2, #28
+		blt	14f
+
+	CALGN(	ands	ip, r0, #31		)
+	CALGN(	sbcnes	r4, ip, r2		)  @ C is always set here
+	CALGN(	subcc	r2, r2, ip		)
+	CALGN(	bcc	15f			)
+
+11:		stmfd	sp!, {r5 - r9}
+
+	PLD(	pld	[r1, #-4]		)
+	PLD(	subs	r2, r2, #96		)
+	PLD(	pld	[r1, #-32]		)
+	PLD(	blt	13f			)
+	PLD(	pld	[r1, #-64]		)
+	PLD(	pld	[r1, #-96]		)
+
+12:	PLD(	pld	[r1, #-128]		)
+13:		ldmdb   r1!, {r7, r8, r9, ip}
+		mov     lr, r3, push #\push
+		subs    r2, r2, #32
+		ldmdb   r1!, {r3, r4, r5, r6}
+		orr     lr, lr, ip, pull #\pull
+		mov     ip, ip, push #\push
+		orr     ip, ip, r9, pull #\pull
+		mov     r9, r9, push #\push
+		orr     r9, r9, r8, pull #\pull
+		mov     r8, r8, push #\push
+		orr     r8, r8, r7, pull #\pull
+		mov     r7, r7, push #\push
+		orr     r7, r7, r6, pull #\pull
+		mov     r6, r6, push #\push
+		orr     r6, r6, r5, pull #\pull
+		mov     r5, r5, push #\push
+		orr     r5, r5, r4, pull #\pull
+		mov     r4, r4, push #\push
+		orr     r4, r4, r3, pull #\pull
+		stmdb   r0!, {r4 - r9, ip, lr}
+		bge	12b
+	PLD(	cmn	r2, #96			)
+	PLD(	bge	13b			)
+
+		ldmfd	sp!, {r5 - r9}
+
+14:		ands	ip, r2, #28
+		beq	16f
+
+15:		mov     lr, r3, push #\push
+		ldr	r3, [r1, #-4]!
+		subs	ip, ip, #4
+		orr	lr, lr, r3, pull #\pull
+		str	lr, [r0, #-4]!
+		bgt	15b
+	CALGN(	cmp	r2, #0			)
+	CALGN(	bge	11b			)
+
+16:		add	r1, r1, #(\pull / 8)
+		b	8b
+
+		.endm
+
+
+		backward_copy_shift	push=8	pull=24
+
+17:		backward_copy_shift	push=16	pull=16
+
+18:		backward_copy_shift	push=24	pull=8
+
+ENDPROC(memmove)
diff --git a/xen/arch/arm/lib/memset.S b/xen/arch/arm/lib/memset.S
new file mode 100644
index 0000000..d2937a3
--- /dev/null
+++ b/xen/arch/arm/lib/memset.S
@@ -0,0 +1,129 @@
+/*
+ *  linux/arch/arm/lib/memset.S
+ *
+ *  Copyright (C) 1995-2000 Russell King
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ *  ASM optimised string functions
+ */
+
+#include <xen/config.h>
+
+#include "assembler.h"
+
+	.text
+	.align	5
+	.word	0
+
+1:	subs	r2, r2, #4		@ 1 do we have enough
+	blt	5f			@ 1 bytes to align with?
+	cmp	r3, #2			@ 1
+	strltb	r1, [r0], #1		@ 1
+	strleb	r1, [r0], #1		@ 1
+	strb	r1, [r0], #1		@ 1
+	add	r2, r2, r3		@ 1 (r2 = r2 - (4 - r3))
+/*
+ * The pointer is now aligned and the length is adjusted.  Try doing the
+ * memset again.
+ */
+
+ENTRY(memset)
+	ands	r3, r0, #3		@ 1 unaligned?
+	bne	1b			@ 1
+/*
+ * we know that the pointer in r0 is aligned to a word boundary.
+ */
+	orr	r1, r1, r1, lsl #8
+	orr	r1, r1, r1, lsl #16
+	mov	r3, r1
+	cmp	r2, #16
+	blt	4f
+
+#if ! CALGN(1)+0
+
+/*
+ * We need an extra register for this loop - save the return address and
+ * use the LR
+ */
+	str	lr, [sp, #-4]!
+	mov	ip, r1
+	mov	lr, r1
+
+2:	subs	r2, r2, #64
+	stmgeia	r0!, {r1, r3, ip, lr}	@ 64 bytes at a time.
+	stmgeia	r0!, {r1, r3, ip, lr}
+	stmgeia	r0!, {r1, r3, ip, lr}
+	stmgeia	r0!, {r1, r3, ip, lr}
+	bgt	2b
+	ldmeqfd	sp!, {pc}		@ Now <64 bytes to go.
+/*
+ * No need to correct the count; we're only testing bits from now on
+ */
+	tst	r2, #32
+	stmneia	r0!, {r1, r3, ip, lr}
+	stmneia	r0!, {r1, r3, ip, lr}
+	tst	r2, #16
+	stmneia	r0!, {r1, r3, ip, lr}
+	ldr	lr, [sp], #4
+
+#else
+
+/*
+ * This version aligns the destination pointer in order to write
+ * whole cache lines at once.
+ */
+
+	stmfd	sp!, {r4-r7, lr}
+	mov	r4, r1
+	mov	r5, r1
+	mov	r6, r1
+	mov	r7, r1
+	mov	ip, r1
+	mov	lr, r1
+
+	cmp	r2, #96
+	tstgt	r0, #31
+	ble	3f
+
+	and	ip, r0, #31
+	rsb	ip, ip, #32
+	sub	r2, r2, ip
+	movs	ip, ip, lsl #(32 - 4)
+	stmcsia	r0!, {r4, r5, r6, r7}
+	stmmiia	r0!, {r4, r5}
+	tst	ip, #(1 << 30)
+	mov	ip, r1
+	strne	r1, [r0], #4
+
+3:	subs	r2, r2, #64
+	stmgeia	r0!, {r1, r3-r7, ip, lr}
+	stmgeia	r0!, {r1, r3-r7, ip, lr}
+	bgt	3b
+	ldmeqfd	sp!, {r4-r7, pc}
+
+	tst	r2, #32
+	stmneia	r0!, {r1, r3-r7, ip, lr}
+	tst	r2, #16
+	stmneia	r0!, {r4-r7}
+	ldmfd	sp!, {r4-r7, lr}
+
+#endif
+
+4:	tst	r2, #8
+	stmneia	r0!, {r1, r3}
+	tst	r2, #4
+	strne	r1, [r0], #4
+/*
+ * When we get here, we've got less than 4 bytes to zero.  We
+ * may have an unaligned pointer as well.
+ */
+5:	tst	r2, #2
+	strneb	r1, [r0], #1
+	strneb	r1, [r0], #1
+	tst	r2, #1
+	strneb	r1, [r0], #1
+	mov	pc, lr
+ENDPROC(memset)
diff --git a/xen/arch/arm/lib/memzero.S b/xen/arch/arm/lib/memzero.S
new file mode 100644
index 0000000..ce25aca
--- /dev/null
+++ b/xen/arch/arm/lib/memzero.S
@@ -0,0 +1,127 @@
+/*
+ *  linux/arch/arm/lib/memzero.S
+ *
+ *  Copyright (C) 1995-2000 Russell King
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <xen/config.h>
+
+#include "assembler.h"
+
+	.text
+	.align	5
+	.word	0
+/*
+ * Align the pointer in r0.  r3 contains the number of bytes that we are
+ * mis-aligned by, and r1 is the number of bytes.  If r1 < 4, then we
+ * don't bother; we use byte stores instead.
+ */
+1:	subs	r1, r1, #4		@ 1 do we have enough
+	blt	5f			@ 1 bytes to align with?
+	cmp	r3, #2			@ 1
+	strltb	r2, [r0], #1		@ 1
+	strleb	r2, [r0], #1		@ 1
+	strb	r2, [r0], #1		@ 1
+	add	r1, r1, r3		@ 1 (r1 = r1 - (4 - r3))
+/*
+ * The pointer is now aligned and the length is adjusted.  Try doing the
+ * memzero again.
+ */
+
+ENTRY(__memzero)
+	mov	r2, #0			@ 1
+	ands	r3, r0, #3		@ 1 unaligned?
+	bne	1b			@ 1
+/*
+ * r3 = 0, and we know that the pointer in r0 is aligned to a word boundary.
+ */
+	cmp	r1, #16			@ 1 we can skip this chunk if we
+	blt	4f			@ 1 have < 16 bytes
+
+#if ! CALGN(1)+0
+
+/*
+ * We need an extra register for this loop - save the return address and
+ * use the LR
+ */
+	str	lr, [sp, #-4]!		@ 1
+	mov	ip, r2			@ 1
+	mov	lr, r2			@ 1
+
+3:	subs	r1, r1, #64		@ 1 write 32 bytes out per loop
+	stmgeia	r0!, {r2, r3, ip, lr}	@ 4
+	stmgeia	r0!, {r2, r3, ip, lr}	@ 4
+	stmgeia	r0!, {r2, r3, ip, lr}	@ 4
+	stmgeia	r0!, {r2, r3, ip, lr}	@ 4
+	bgt	3b			@ 1
+	ldmeqfd	sp!, {pc}		@ 1/2 quick exit
+/*
+ * No need to correct the count; we're only testing bits from now on
+ */
+	tst	r1, #32			@ 1
+	stmneia	r0!, {r2, r3, ip, lr}	@ 4
+	stmneia	r0!, {r2, r3, ip, lr}	@ 4
+	tst	r1, #16			@ 1 16 bytes or more?
+	stmneia	r0!, {r2, r3, ip, lr}	@ 4
+	ldr	lr, [sp], #4		@ 1
+
+#else
+
+/*
+ * This version aligns the destination pointer in order to write
+ * whole cache lines at once.
+ */
+
+	stmfd	sp!, {r4-r7, lr}
+	mov	r4, r2
+	mov	r5, r2
+	mov	r6, r2
+	mov	r7, r2
+	mov	ip, r2
+	mov	lr, r2
+
+	cmp	r1, #96
+	andgts	ip, r0, #31
+	ble	3f
+
+	rsb	ip, ip, #32
+	sub	r1, r1, ip
+	movs	ip, ip, lsl #(32 - 4)
+	stmcsia	r0!, {r4, r5, r6, r7}
+	stmmiia	r0!, {r4, r5}
+	movs	ip, ip, lsl #2
+	strcs	r2, [r0], #4
+
+3:	subs	r1, r1, #64
+	stmgeia	r0!, {r2-r7, ip, lr}
+	stmgeia	r0!, {r2-r7, ip, lr}
+	bgt	3b
+	ldmeqfd	sp!, {r4-r7, pc}
+
+	tst	r1, #32
+	stmneia	r0!, {r2-r7, ip, lr}
+	tst	r1, #16
+	stmneia	r0!, {r4-r7}
+	ldmfd	sp!, {r4-r7, lr}
+
+#endif
+
+4:	tst	r1, #8			@ 1 8 bytes or more?
+	stmneia	r0!, {r2, r3}		@ 2
+	tst	r1, #4			@ 1 4 bytes or more?
+	strne	r2, [r0], #4		@ 1
+/*
+ * When we get here, we've got less than 4 bytes to zero.  We
+ * may have an unaligned pointer as well.
+ */
+5:	tst	r1, #2			@ 1 2 bytes or more?
+	strneb	r2, [r0], #1		@ 1
+	strneb	r2, [r0], #1		@ 1
+	tst	r1, #1			@ 1 a byte left over
+	strneb	r2, [r0], #1		@ 1
+	mov	pc, lr			@ 1
+ENDPROC(__memzero)
diff --git a/xen/arch/arm/lib/setbit.S b/xen/arch/arm/lib/setbit.S
new file mode 100644
index 0000000..c828851
--- /dev/null
+++ b/xen/arch/arm/lib/setbit.S
@@ -0,0 +1,18 @@
+/*
+ *  linux/arch/arm/lib/setbit.S
+ *
+ *  Copyright (C) 1995-1996 Russell King
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#include <xen/config.h>
+
+#include "assembler.h"
+#include "bitops.h"
+	.text
+
+ENTRY(_set_bit)
+	bitop	orr
+ENDPROC(_set_bit)
diff --git a/xen/arch/arm/lib/testchangebit.S b/xen/arch/arm/lib/testchangebit.S
new file mode 100644
index 0000000..a7f527c
--- /dev/null
+++ b/xen/arch/arm/lib/testchangebit.S
@@ -0,0 +1,18 @@
+/*
+ *  linux/arch/arm/lib/testchangebit.S
+ *
+ *  Copyright (C) 1995-1996 Russell King
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#include <xen/config.h>
+
+#include "assembler.h"
+#include "bitops.h"
+                .text
+
+ENTRY(_test_and_change_bit)
+	testop	eor, str
+ENDPROC(_test_and_change_bit)
diff --git a/xen/arch/arm/lib/testclearbit.S b/xen/arch/arm/lib/testclearbit.S
new file mode 100644
index 0000000..8f39c72
--- /dev/null
+++ b/xen/arch/arm/lib/testclearbit.S
@@ -0,0 +1,18 @@
+/*
+ *  linux/arch/arm/lib/testclearbit.S
+ *
+ *  Copyright (C) 1995-1996 Russell King
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#include <xen/config.h>
+
+#include "assembler.h"
+#include "bitops.h"
+                .text
+
+ENTRY(_test_and_clear_bit)
+	testop	bicne, strne
+ENDPROC(_test_and_clear_bit)
diff --git a/xen/arch/arm/lib/testsetbit.S b/xen/arch/arm/lib/testsetbit.S
new file mode 100644
index 0000000..1b8d273
--- /dev/null
+++ b/xen/arch/arm/lib/testsetbit.S
@@ -0,0 +1,18 @@
+/*
+ *  linux/arch/arm/lib/testsetbit.S
+ *
+ *  Copyright (C) 1995-1996 Russell King
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#include <xen/config.h>
+
+#include "assembler.h"
+#include "bitops.h"
+                .text
+
+ENTRY(_test_and_set_bit)
+	testop	orreq, streq
+ENDPROC(_test_and_set_bit)
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 18:20:41 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 18:20:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXzd9-00087V-CL; Tue, 06 Dec 2011 18:20:39 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RXzd6-0007wo-IL
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 18:20:36 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1323195530!59687716!5
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDcxMjI=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2402 invoked from network); 6 Dec 2011 18:19:01 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Dec 2011 18:19:01 -0000
X-IronPort-AV: E=Sophos;i="4.71,307,1320642000"; d="scan'208";a="19721950"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Dec 2011 13:19:49 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Tue, 6 Dec 2011 13:19:49 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pB6IJEjR019549;
	Tue, 6 Dec 2011 10:19:38 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Tue, 6 Dec 2011 18:20:01 +0000
Message-ID: <1323195609-17277-17-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1112061753410.31179@kaball-desktop>
References: <alpine.DEB.2.00.1112061753410.31179@kaball-desktop>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>, Tim.Deegan@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH RFC 17/25] arm: irq
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

A simple do_IRQ and request_irq implementation for ARM.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
---
 xen/arch/arm/Makefile       |    1 +
 xen/arch/arm/irq.c          |  179 +++++++++++++++++++++++++++++++++++++++++++
 xen/include/asm-arm/irq.h   |   30 +++++++
 xen/include/asm-arm/setup.h |    2 +
 xen/include/xen/irq.h       |   13 +++
 5 files changed, 225 insertions(+), 0 deletions(-)
 create mode 100644 xen/arch/arm/irq.c
 create mode 100644 xen/include/asm-arm/irq.h

diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index f1a97b6..5593d2b 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -6,6 +6,7 @@ obj-y += domain.o
 obj-y += domain_build.o
 obj-y += gic.o
 obj-y += io.o
+obj-y += irq.o
 
 #obj-bin-y += ....o
 
diff --git a/xen/arch/arm/irq.c b/xen/arch/arm/irq.c
new file mode 100644
index 0000000..5663762
--- /dev/null
+++ b/xen/arch/arm/irq.c
@@ -0,0 +1,179 @@
+/*
+ * xen/arch/arm/irq.c
+ *
+ * ARM Interrupt support
+ *
+ * Ian Campbell <ian.campbell@citrix.com>
+ * Copyright (c) 2011 Citrix Systems.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include <xen/config.h>
+#include <xen/lib.h>
+#include <xen/spinlock.h>
+#include <xen/irq.h>
+#include <xen/init.h>
+#include <xen/errno.h>
+#include <xen/sched.h>
+
+#include "gic.h"
+
+static void enable_none(struct irq_desc *irq) { }
+static unsigned int startup_none(struct irq_desc *irq) { return 0; }
+static void disable_none(struct irq_desc *irq) { }
+static void ack_none(struct irq_desc *irq)
+{
+    printk("unexpected IRQ trap at irq %02x\n", irq->irq);
+}
+
+#define shutdown_none   disable_none
+#define end_none        enable_none
+
+hw_irq_controller no_irq_type = {
+    .typename = "none",
+    .startup = startup_none,
+    .shutdown = shutdown_none,
+    .enable = enable_none,
+    .disable = disable_none,
+    .ack = ack_none,
+    .end = end_none
+};
+
+int __init arch_init_one_irq_desc(struct irq_desc *desc)
+{
+	return 0;
+}
+
+
+static int __init init_irq_data(void)
+{
+    int irq;
+
+    for (irq = 0; irq < NR_IRQS; irq++) {
+        struct irq_desc *desc = irq_to_desc(irq);
+        init_one_irq_desc(desc);
+        desc->irq = irq;
+        desc->action  = NULL;
+    }
+    return 0;
+}
+
+void __init init_IRQ(void)
+{
+    BUG_ON(init_irq_data() < 0);
+}
+
+int __init request_irq(unsigned int irq,
+        void (*handler)(int, void *, struct cpu_user_regs *),
+        unsigned long irqflags, const char * devname, void *dev_id)
+{
+    struct irqaction *action;
+    int retval;
+
+    /*
+     * Sanity-check: shared interrupts must pass in a real dev-ID,
+     * otherwise we'll have trouble later trying to figure out
+     * which interrupt is which (messes up the interrupt freeing
+     * logic etc).
+     */
+    if (irq >= nr_irqs)
+        return -EINVAL;
+    if (!handler)
+        return -EINVAL;
+
+    action = xmalloc(struct irqaction);
+    if (!action)
+        return -ENOMEM;
+
+    action->handler = handler;
+    action->name = devname;
+    action->dev_id = dev_id;
+    action->free_on_release = 1;
+
+    retval = setup_irq(irq, action);
+    if (retval)
+        xfree(action);
+
+    return retval;
+}
+
+/* Dispatch an interrupt */
+void do_IRQ(struct cpu_user_regs *regs, unsigned int irq, int is_fiq)
+{
+    struct irq_desc *desc = irq_to_desc(irq);
+    struct irqaction *action = desc->action;
+
+    /* TODO: perfc_incr(irqs); */
+
+    /* TODO: this_cpu(irq_count)++; */
+
+    irq_enter();
+
+    spin_lock(&desc->lock);
+    desc->handler->ack(desc);
+
+    if ( action == NULL )
+    {
+        printk("Unknown %s %#3.3x\n",
+               is_fiq ? "FIQ" : "IRQ", irq);
+        goto out;
+    }
+
+    if ( desc->status & IRQ_GUEST )
+    {
+        struct domain *d = action->dev_id;
+
+        desc->handler->end(desc);
+
+        desc->status |= IRQ_INPROGRESS;
+
+        /* XXX: inject irq into the guest */
+        goto out_no_end;
+    }
+
+    desc->status |= IRQ_PENDING;
+
+    /*
+     * Since we set PENDING, if another processor is handling a different
+     * instance of this same irq, the other processor will take care of it.
+     */
+    if ( desc->status & (IRQ_DISABLED | IRQ_INPROGRESS) )
+        goto out;
+
+    desc->status |= IRQ_INPROGRESS;
+
+    action = desc->action;
+    while ( desc->status & IRQ_PENDING )
+    {
+        desc->status &= ~IRQ_PENDING;
+        spin_unlock_irq(&desc->lock);
+        action->handler(irq, action->dev_id, regs);
+        spin_lock_irq(&desc->lock);
+    }
+
+    desc->status &= ~IRQ_INPROGRESS;
+
+out:
+    desc->handler->end(desc);
+out_no_end:
+    spin_unlock(&desc->lock);
+    irq_exit();
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/irq.h b/xen/include/asm-arm/irq.h
new file mode 100644
index 0000000..8e65a2e
--- /dev/null
+++ b/xen/include/asm-arm/irq.h
@@ -0,0 +1,30 @@
+#ifndef _ASM_HW_IRQ_H
+#define _ASM_HW_IRQ_H
+
+#include <xen/config.h>
+
+#define NR_VECTORS 256 /* XXX */
+
+typedef struct {
+    DECLARE_BITMAP(_bits,NR_VECTORS);
+} vmask_t;
+
+struct arch_pirq
+{
+};
+
+struct irq_cfg {
+#define arch_irq_desc irq_cfg
+};
+
+void do_IRQ(struct cpu_user_regs *regs, unsigned int irq, int is_fiq);
+
+#endif /* _ASM_HW_IRQ_H */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/setup.h b/xen/include/asm-arm/setup.h
index 1dc3f97..2041f06 100644
--- a/xen/include/asm-arm/setup.h
+++ b/xen/include/asm-arm/setup.h
@@ -7,6 +7,8 @@ void arch_get_xen_caps(xen_capabilities_info_t *info);
 
 int construct_dom0(struct domain *d);
 
+void init_IRQ(void);
+
 #endif
 /*
  * Local variables:
diff --git a/xen/include/xen/irq.h b/xen/include/xen/irq.h
index a2a90e1..5a711cc 100644
--- a/xen/include/xen/irq.h
+++ b/xen/include/xen/irq.h
@@ -107,6 +107,19 @@ extern irq_desc_t irq_desc[NR_VECTORS];
 
 #define request_irq(irq, handler, irqflags, devname, devid) \
     request_irq_vector(irq_to_vector(irq), handler, irqflags, devname, devid)
+
+#elif defined(__arm__)
+
+#define NR_IRQS		1024
+#define nr_irqs NR_IRQS
+extern irq_desc_t irq_desc[NR_IRQS];
+
+extern int setup_irq(unsigned int irq, struct irqaction *);
+extern void release_irq(unsigned int irq);
+extern int request_irq(unsigned int irq,
+               void (*handler)(int, void *, struct cpu_user_regs *),
+               unsigned long irqflags, const char * devname, void *dev_id);
+
 #else
 extern int setup_irq(unsigned int irq, struct irqaction *);
 extern void release_irq(unsigned int irq);
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 18:20:41 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 18:20:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXzd9-00087V-CL; Tue, 06 Dec 2011 18:20:39 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RXzd6-0007wo-IL
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 18:20:36 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1323195530!59687716!5
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDcxMjI=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2402 invoked from network); 6 Dec 2011 18:19:01 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Dec 2011 18:19:01 -0000
X-IronPort-AV: E=Sophos;i="4.71,307,1320642000"; d="scan'208";a="19721950"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Dec 2011 13:19:49 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Tue, 6 Dec 2011 13:19:49 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pB6IJEjR019549;
	Tue, 6 Dec 2011 10:19:38 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Tue, 6 Dec 2011 18:20:01 +0000
Message-ID: <1323195609-17277-17-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1112061753410.31179@kaball-desktop>
References: <alpine.DEB.2.00.1112061753410.31179@kaball-desktop>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>, Tim.Deegan@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH RFC 17/25] arm: irq
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

A simple do_IRQ and request_irq implementation for ARM.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
---
 xen/arch/arm/Makefile       |    1 +
 xen/arch/arm/irq.c          |  179 +++++++++++++++++++++++++++++++++++++++++++
 xen/include/asm-arm/irq.h   |   30 +++++++
 xen/include/asm-arm/setup.h |    2 +
 xen/include/xen/irq.h       |   13 +++
 5 files changed, 225 insertions(+), 0 deletions(-)
 create mode 100644 xen/arch/arm/irq.c
 create mode 100644 xen/include/asm-arm/irq.h

diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index f1a97b6..5593d2b 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -6,6 +6,7 @@ obj-y += domain.o
 obj-y += domain_build.o
 obj-y += gic.o
 obj-y += io.o
+obj-y += irq.o
 
 #obj-bin-y += ....o
 
diff --git a/xen/arch/arm/irq.c b/xen/arch/arm/irq.c
new file mode 100644
index 0000000..5663762
--- /dev/null
+++ b/xen/arch/arm/irq.c
@@ -0,0 +1,179 @@
+/*
+ * xen/arch/arm/irq.c
+ *
+ * ARM Interrupt support
+ *
+ * Ian Campbell <ian.campbell@citrix.com>
+ * Copyright (c) 2011 Citrix Systems.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include <xen/config.h>
+#include <xen/lib.h>
+#include <xen/spinlock.h>
+#include <xen/irq.h>
+#include <xen/init.h>
+#include <xen/errno.h>
+#include <xen/sched.h>
+
+#include "gic.h"
+
+static void enable_none(struct irq_desc *irq) { }
+static unsigned int startup_none(struct irq_desc *irq) { return 0; }
+static void disable_none(struct irq_desc *irq) { }
+static void ack_none(struct irq_desc *irq)
+{
+    printk("unexpected IRQ trap at irq %02x\n", irq->irq);
+}
+
+#define shutdown_none   disable_none
+#define end_none        enable_none
+
+hw_irq_controller no_irq_type = {
+    .typename = "none",
+    .startup = startup_none,
+    .shutdown = shutdown_none,
+    .enable = enable_none,
+    .disable = disable_none,
+    .ack = ack_none,
+    .end = end_none
+};
+
+int __init arch_init_one_irq_desc(struct irq_desc *desc)
+{
+	return 0;
+}
+
+
+static int __init init_irq_data(void)
+{
+    int irq;
+
+    for (irq = 0; irq < NR_IRQS; irq++) {
+        struct irq_desc *desc = irq_to_desc(irq);
+        init_one_irq_desc(desc);
+        desc->irq = irq;
+        desc->action  = NULL;
+    }
+    return 0;
+}
+
+void __init init_IRQ(void)
+{
+    BUG_ON(init_irq_data() < 0);
+}
+
+int __init request_irq(unsigned int irq,
+        void (*handler)(int, void *, struct cpu_user_regs *),
+        unsigned long irqflags, const char * devname, void *dev_id)
+{
+    struct irqaction *action;
+    int retval;
+
+    /*
+     * Sanity-check: shared interrupts must pass in a real dev-ID,
+     * otherwise we'll have trouble later trying to figure out
+     * which interrupt is which (messes up the interrupt freeing
+     * logic etc).
+     */
+    if (irq >= nr_irqs)
+        return -EINVAL;
+    if (!handler)
+        return -EINVAL;
+
+    action = xmalloc(struct irqaction);
+    if (!action)
+        return -ENOMEM;
+
+    action->handler = handler;
+    action->name = devname;
+    action->dev_id = dev_id;
+    action->free_on_release = 1;
+
+    retval = setup_irq(irq, action);
+    if (retval)
+        xfree(action);
+
+    return retval;
+}
+
+/* Dispatch an interrupt */
+void do_IRQ(struct cpu_user_regs *regs, unsigned int irq, int is_fiq)
+{
+    struct irq_desc *desc = irq_to_desc(irq);
+    struct irqaction *action = desc->action;
+
+    /* TODO: perfc_incr(irqs); */
+
+    /* TODO: this_cpu(irq_count)++; */
+
+    irq_enter();
+
+    spin_lock(&desc->lock);
+    desc->handler->ack(desc);
+
+    if ( action == NULL )
+    {
+        printk("Unknown %s %#3.3x\n",
+               is_fiq ? "FIQ" : "IRQ", irq);
+        goto out;
+    }
+
+    if ( desc->status & IRQ_GUEST )
+    {
+        struct domain *d = action->dev_id;
+
+        desc->handler->end(desc);
+
+        desc->status |= IRQ_INPROGRESS;
+
+        /* XXX: inject irq into the guest */
+        goto out_no_end;
+    }
+
+    desc->status |= IRQ_PENDING;
+
+    /*
+     * Since we set PENDING, if another processor is handling a different
+     * instance of this same irq, the other processor will take care of it.
+     */
+    if ( desc->status & (IRQ_DISABLED | IRQ_INPROGRESS) )
+        goto out;
+
+    desc->status |= IRQ_INPROGRESS;
+
+    action = desc->action;
+    while ( desc->status & IRQ_PENDING )
+    {
+        desc->status &= ~IRQ_PENDING;
+        spin_unlock_irq(&desc->lock);
+        action->handler(irq, action->dev_id, regs);
+        spin_lock_irq(&desc->lock);
+    }
+
+    desc->status &= ~IRQ_INPROGRESS;
+
+out:
+    desc->handler->end(desc);
+out_no_end:
+    spin_unlock(&desc->lock);
+    irq_exit();
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/irq.h b/xen/include/asm-arm/irq.h
new file mode 100644
index 0000000..8e65a2e
--- /dev/null
+++ b/xen/include/asm-arm/irq.h
@@ -0,0 +1,30 @@
+#ifndef _ASM_HW_IRQ_H
+#define _ASM_HW_IRQ_H
+
+#include <xen/config.h>
+
+#define NR_VECTORS 256 /* XXX */
+
+typedef struct {
+    DECLARE_BITMAP(_bits,NR_VECTORS);
+} vmask_t;
+
+struct arch_pirq
+{
+};
+
+struct irq_cfg {
+#define arch_irq_desc irq_cfg
+};
+
+void do_IRQ(struct cpu_user_regs *regs, unsigned int irq, int is_fiq);
+
+#endif /* _ASM_HW_IRQ_H */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/setup.h b/xen/include/asm-arm/setup.h
index 1dc3f97..2041f06 100644
--- a/xen/include/asm-arm/setup.h
+++ b/xen/include/asm-arm/setup.h
@@ -7,6 +7,8 @@ void arch_get_xen_caps(xen_capabilities_info_t *info);
 
 int construct_dom0(struct domain *d);
 
+void init_IRQ(void);
+
 #endif
 /*
  * Local variables:
diff --git a/xen/include/xen/irq.h b/xen/include/xen/irq.h
index a2a90e1..5a711cc 100644
--- a/xen/include/xen/irq.h
+++ b/xen/include/xen/irq.h
@@ -107,6 +107,19 @@ extern irq_desc_t irq_desc[NR_VECTORS];
 
 #define request_irq(irq, handler, irqflags, devname, devid) \
     request_irq_vector(irq_to_vector(irq), handler, irqflags, devname, devid)
+
+#elif defined(__arm__)
+
+#define NR_IRQS		1024
+#define nr_irqs NR_IRQS
+extern irq_desc_t irq_desc[NR_IRQS];
+
+extern int setup_irq(unsigned int irq, struct irqaction *);
+extern void release_irq(unsigned int irq);
+extern int request_irq(unsigned int irq,
+               void (*handler)(int, void *, struct cpu_user_regs *),
+               unsigned long irqflags, const char * devname, void *dev_id);
+
 #else
 extern int setup_irq(unsigned int irq, struct irqaction *);
 extern void release_irq(unsigned int irq);
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 18:20:46 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 18: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.xensource.com>)
	id 1RXzdD-0008Ce-RE; Tue, 06 Dec 2011 18:20:43 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RXzdB-00081X-3r
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 18:20:41 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1323195594!7123966!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMzAwOTc=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21746 invoked from network); 6 Dec 2011 18:19:55 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Dec 2011 18:19:55 -0000
X-IronPort-AV: E=Sophos;i="4.71,307,1320642000"; d="scan'208";a="173120765"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Dec 2011 13:19:53 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Tue, 6 Dec 2011 13:19:53 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pB6IJEjQ019549;
	Tue, 6 Dec 2011 10:19:37 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Tue, 6 Dec 2011 18:20:00 +0000
Message-ID: <1323195609-17277-16-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1112061753410.31179@kaball-desktop>
References: <alpine.DEB.2.00.1112061753410.31179@kaball-desktop>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>, Tim.Deegan@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH RFC 16/25] arm: mmio handlers
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Basic infrastructure to emulate mmio reads and writes.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
---
 xen/arch/arm/Makefile |    1 +
 xen/arch/arm/io.c     |   50 ++++++++++++++++++++++++++++++++++++++++++++++
 xen/arch/arm/io.h     |   53 +++++++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 104 insertions(+), 0 deletions(-)
 create mode 100644 xen/arch/arm/io.c
 create mode 100644 xen/arch/arm/io.h

diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index cd196c3..f1a97b6 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -5,6 +5,7 @@ obj-y += entry.o
 obj-y += domain.o
 obj-y += domain_build.o
 obj-y += gic.o
+obj-y += io.o
 
 #obj-bin-y += ....o
 
diff --git a/xen/arch/arm/io.c b/xen/arch/arm/io.c
new file mode 100644
index 0000000..8789705
--- /dev/null
+++ b/xen/arch/arm/io.c
@@ -0,0 +1,50 @@
+/*
+ * xen/arch/arm/io.h
+ *
+ * ARM I/O handlers
+ *
+ * Copyright (c) 2011 Citrix Systems.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include <xen/config.h>
+#include <xen/lib.h>
+#include <asm/current.h>
+
+#include "io.h"
+
+static const struct mmio_handler *const mmio_handlers[] =
+{
+};
+#define MMIO_HANDLER_NR ARRAY_SIZE(mmio_handlers)
+
+int handle_mmio(mmio_info_t *info)
+{
+    struct vcpu *v = current;
+    int i;
+
+    for ( i = 0; i < MMIO_HANDLER_NR; i++ )
+        if ( mmio_handlers[i]->check_handler(v, info->gpa) )
+            return info->dabt.write ?
+                mmio_handlers[i]->write_handler(v, info) :
+                mmio_handlers[i]->read_handler(v, info);
+
+    return 0;
+}
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/arch/arm/io.h b/xen/arch/arm/io.h
new file mode 100644
index 0000000..d7847e3
--- /dev/null
+++ b/xen/arch/arm/io.h
@@ -0,0 +1,53 @@
+/*
+ * xen/arch/arm/io.h
+ *
+ * ARM I/O handlers
+ *
+ * Copyright (c) 2011 Citrix Systems.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#ifndef __ARCH_ARM_IO_H__
+#define __ARCH_ARM_IO_H__
+
+#include <xen/lib.h>
+#include <asm/processor.h>
+
+typedef struct
+{
+    struct hsr_dabt dabt;
+    uint32_t gva;
+    paddr_t gpa;
+} mmio_info_t;
+
+typedef int (*mmio_read_t)(struct vcpu *v, mmio_info_t *info);
+typedef int (*mmio_write_t)(struct vcpu *v, mmio_info_t *info);
+typedef int (*mmio_check_t)(struct vcpu *v, paddr_t addr);
+
+struct mmio_handler {
+    mmio_check_t check_handler;
+    mmio_read_t read_handler;
+    mmio_write_t write_handler;
+};
+
+extern int handle_mmio(mmio_info_t *info);
+
+#endif
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 18:20:46 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 18: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.xensource.com>)
	id 1RXzdD-0008Ce-RE; Tue, 06 Dec 2011 18:20:43 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RXzdB-00081X-3r
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 18:20:41 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1323195594!7123966!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMzAwOTc=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21746 invoked from network); 6 Dec 2011 18:19:55 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Dec 2011 18:19:55 -0000
X-IronPort-AV: E=Sophos;i="4.71,307,1320642000"; d="scan'208";a="173120765"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Dec 2011 13:19:53 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Tue, 6 Dec 2011 13:19:53 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pB6IJEjQ019549;
	Tue, 6 Dec 2011 10:19:37 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Tue, 6 Dec 2011 18:20:00 +0000
Message-ID: <1323195609-17277-16-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1112061753410.31179@kaball-desktop>
References: <alpine.DEB.2.00.1112061753410.31179@kaball-desktop>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>, Tim.Deegan@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH RFC 16/25] arm: mmio handlers
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Basic infrastructure to emulate mmio reads and writes.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
---
 xen/arch/arm/Makefile |    1 +
 xen/arch/arm/io.c     |   50 ++++++++++++++++++++++++++++++++++++++++++++++
 xen/arch/arm/io.h     |   53 +++++++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 104 insertions(+), 0 deletions(-)
 create mode 100644 xen/arch/arm/io.c
 create mode 100644 xen/arch/arm/io.h

diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index cd196c3..f1a97b6 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -5,6 +5,7 @@ obj-y += entry.o
 obj-y += domain.o
 obj-y += domain_build.o
 obj-y += gic.o
+obj-y += io.o
 
 #obj-bin-y += ....o
 
diff --git a/xen/arch/arm/io.c b/xen/arch/arm/io.c
new file mode 100644
index 0000000..8789705
--- /dev/null
+++ b/xen/arch/arm/io.c
@@ -0,0 +1,50 @@
+/*
+ * xen/arch/arm/io.h
+ *
+ * ARM I/O handlers
+ *
+ * Copyright (c) 2011 Citrix Systems.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include <xen/config.h>
+#include <xen/lib.h>
+#include <asm/current.h>
+
+#include "io.h"
+
+static const struct mmio_handler *const mmio_handlers[] =
+{
+};
+#define MMIO_HANDLER_NR ARRAY_SIZE(mmio_handlers)
+
+int handle_mmio(mmio_info_t *info)
+{
+    struct vcpu *v = current;
+    int i;
+
+    for ( i = 0; i < MMIO_HANDLER_NR; i++ )
+        if ( mmio_handlers[i]->check_handler(v, info->gpa) )
+            return info->dabt.write ?
+                mmio_handlers[i]->write_handler(v, info) :
+                mmio_handlers[i]->read_handler(v, info);
+
+    return 0;
+}
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/arch/arm/io.h b/xen/arch/arm/io.h
new file mode 100644
index 0000000..d7847e3
--- /dev/null
+++ b/xen/arch/arm/io.h
@@ -0,0 +1,53 @@
+/*
+ * xen/arch/arm/io.h
+ *
+ * ARM I/O handlers
+ *
+ * Copyright (c) 2011 Citrix Systems.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#ifndef __ARCH_ARM_IO_H__
+#define __ARCH_ARM_IO_H__
+
+#include <xen/lib.h>
+#include <asm/processor.h>
+
+typedef struct
+{
+    struct hsr_dabt dabt;
+    uint32_t gva;
+    paddr_t gpa;
+} mmio_info_t;
+
+typedef int (*mmio_read_t)(struct vcpu *v, mmio_info_t *info);
+typedef int (*mmio_write_t)(struct vcpu *v, mmio_info_t *info);
+typedef int (*mmio_check_t)(struct vcpu *v, paddr_t addr);
+
+struct mmio_handler {
+    mmio_check_t check_handler;
+    mmio_read_t read_handler;
+    mmio_write_t write_handler;
+};
+
+extern int handle_mmio(mmio_info_t *info);
+
+#endif
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 18:20:48 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 18:20:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXzdG-0008EL-8o; Tue, 06 Dec 2011 18:20:46 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RXzdE-00086d-3b
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 18:20:44 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1323195594!7123966!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMzAwOTc=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21799 invoked from network); 6 Dec 2011 18:19:57 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Dec 2011 18:19:57 -0000
X-IronPort-AV: E=Sophos;i="4.71,307,1320642000"; d="scan'208";a="173120780"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Dec 2011 13:19:57 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Tue, 6 Dec 2011 13:19:57 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pB6IJEjW019549;
	Tue, 6 Dec 2011 10:19:45 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Tue, 6 Dec 2011 18:20:06 +0000
Message-ID: <1323195609-17277-22-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1112061753410.31179@kaball-desktop>
References: <alpine.DEB.2.00.1112061753410.31179@kaball-desktop>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>, Tim.Deegan@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH RFC 22/25] arm: driver for the generic timer for
	ARMv7
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Driver for the generic timer for ARMv7 with virtualization extensions.
Currently it is based on the kernel timer rather than the hypervisor timer
because the latter does not work correctly on our test environment.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
---
 xen/arch/arm/Makefile      |    1 +
 xen/arch/arm/time.c        |  181 ++++++++++++++++++++++++++++++++++++++++++++
 xen/include/asm-arm/time.h |   26 ++++++
 3 files changed, 208 insertions(+), 0 deletions(-)
 create mode 100644 xen/arch/arm/time.c
 create mode 100644 xen/include/asm-arm/time.h

diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index 7ba02dd..6eff96b 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -11,6 +11,7 @@ obj-y += mm.o
 obj-y += p2m.o
 obj-y += usercopy.o
 obj-y += setup.o
+obj-y += time.o
 obj-y += smpboot.o
 obj-y += smp.o
 obj-y += shutdown.o
diff --git a/xen/arch/arm/time.c b/xen/arch/arm/time.c
new file mode 100644
index 0000000..13c1254
--- /dev/null
+++ b/xen/arch/arm/time.c
@@ -0,0 +1,181 @@
+/*
+ * xen/arch/arm/time.c
+ *
+ * Time and timer support, using the ARM Generic Timer interfaces
+ *
+ * Tim Deegan <tim@xen.org>
+ * Copyright (c) 2011 Citrix Systems.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include <xen/config.h>
+#include <xen/console.h>
+#include <xen/init.h>
+#include <xen/irq.h>
+#include <xen/lib.h>
+#include <xen/mm.h>
+#include <xen/softirq.h>
+#include <xen/time.h>
+#include <asm/system.h>
+
+/* Unfortunately the hypervisor timer interrupt appears to be buggy */
+#define USE_HYP_TIMER 0
+
+/* For fine-grained timekeeping, we use the ARM "Generic Timer", a
+ * register-mapped time source in the SoC. */
+static uint32_t __read_mostly cntfrq;      /* Ticks per second */
+static uint64_t __read_mostly boot_count;  /* Counter value at boot time */
+
+/*static inline*/ s_time_t ticks_to_ns(uint64_t ticks)
+{
+    return muldiv64(ticks, SECONDS(1), cntfrq);
+}
+
+/*static inline*/ uint64_t ns_to_ticks(s_time_t ns)
+{
+    return muldiv64(ns, cntfrq, SECONDS(1));
+}
+
+/* TODO: On a real system the firmware would have set the frequency in
+   the CNTFRQ register.  Also we'd need to use devicetree to find
+   the RTC.  When we've seen some real systems, we can delete this.
+static uint32_t calibrate_timer(void)
+{
+    uint32_t sec;
+    uint64_t start, end;
+    paddr_t rtc_base = 0x1C170000ull;
+    volatile uint32_t *rtc;
+
+    ASSERT(!local_irq_is_enabled());
+    set_fixmap(FIXMAP_MISC, rtc_base >> PAGE_SHIFT, DEV_SHARED);
+    rtc = (uint32_t *) FIXMAP_ADDR(FIXMAP_MISC);
+
+    printk("Calibrating timer against RTC...");
+    // Turn on the RTC
+    rtc[3] = 1;
+    // Wait for an edge
+    sec = rtc[0] + 1;
+    do {} while ( rtc[0] != sec );
+    // Now time a few seconds
+    start = READ_CP64(CNTPCT);
+    do {} while ( rtc[0] < sec + 32 );
+    end = READ_CP64(CNTPCT);
+    printk("done.\n");
+
+    clear_fixmap(FIXMAP_MISC);
+    return (end - start) / 32;
+}
+*/
+
+/* Set up the timer on the boot CPU */
+int __init init_xen_time(void)
+{
+    /* Check that this CPU supports the Generic Timer interface */
+    if ( (READ_CP32(ID_PFR1) & ID_PFR1_GT_MASK) != ID_PFR1_GT_v1 )
+        panic("CPU does not support the Generic Timer v1 interface.\n");
+
+    cntfrq = READ_CP32(CNTFRQ);
+    boot_count = READ_CP64(CNTPCT);
+    printk("Using generic timer at %"PRIu32" Hz\n", cntfrq);
+
+    return 0;
+}
+
+/* Return number of nanoseconds since boot */
+s_time_t get_s_time(void)
+{
+    uint64_t ticks = READ_CP64(CNTPCT) - boot_count;
+    return ticks_to_ns(ticks);
+}
+
+/* Set the timer to wake us up at a particular time.
+ * Timeout is a Xen system time (nanoseconds since boot); 0 disables the timer.
+ * Returns 1 on success; 0 if the timeout is too soon or is in the past. */
+int reprogram_timer(s_time_t timeout)
+{
+    uint64_t deadline;
+
+    if ( timeout == 0 )
+    {
+#if USE_HYP_TIMER
+        WRITE_CP32(0, CNTHP_CTL);
+#else
+        WRITE_CP32(0, CNTP_CTL);
+#endif
+        return 1;
+    }
+
+    deadline = ns_to_ticks(timeout) + boot_count;
+#if USE_HYP_TIMER
+    WRITE_CP64(deadline, CNTHP_CVAL);
+    WRITE_CP32(CNTx_CTL_ENABLE, CNTHP_CTL);
+#else
+    WRITE_CP64(deadline, CNTP_CVAL);
+    WRITE_CP32(CNTx_CTL_ENABLE, CNTP_CTL);
+#endif
+    isb();
+
+    /* No need to check for timers in the past; the Generic Timer fires
+     * on a signed 63-bit comparison. */
+    return 1;
+}
+
+/* Handle the firing timer */
+static void timer_interrupt(int irq, void *dev_id, struct cpu_user_regs *regs)
+{
+    if ( irq == 26 && READ_CP32(CNTHP_CTL) & CNTx_CTL_PENDING )
+    {
+        /* Signal the generic timer code to do its work */
+        raise_softirq(TIMER_SOFTIRQ);
+        /* Disable the timer to avoid more interrupts */
+        WRITE_CP32(0, CNTHP_CTL);
+    }
+
+    if (irq == 30 && READ_CP32(CNTP_CTL) & CNTx_CTL_PENDING )
+    {
+        /* Signal the generic timer code to do its work */
+        raise_softirq(TIMER_SOFTIRQ);
+        /* Disable the timer to avoid more interrupts */
+        WRITE_CP32(0, CNTP_CTL);
+    }
+}
+
+/* Set up the timer interrupt on this CPU */
+void __cpuinit init_timer_interrupt(void)
+{
+    /* Sensible defaults */
+    WRITE_CP64(0, CNTVOFF);     /* No VM-specific offset */
+    WRITE_CP32(0, CNTKCTL);     /* No user-mode access */
+#if USE_HYP_TIMER
+    /* Let the VMs read the physical counter and timer so they can tell time */
+    WRITE_CP32(CNTHCTL_PA|CNTHCTL_TA, CNTHCTL);
+#else
+    /* Cannot let VMs access physical counter if we are using it */
+    WRITE_CP32(0, CNTHCTL);
+#endif
+    WRITE_CP32(0, CNTP_CTL);    /* Physical timer disabled */
+    WRITE_CP32(0, CNTHP_CTL);   /* Hypervisor's timer disabled */
+    isb();
+
+    /* XXX Need to find this IRQ number from devicetree? */
+    request_irq(26, timer_interrupt, 0, "hyptimer", NULL);
+    request_irq(30, timer_interrupt, 0, "phytimer", NULL);
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/time.h b/xen/include/asm-arm/time.h
new file mode 100644
index 0000000..8cc9e78
--- /dev/null
+++ b/xen/include/asm-arm/time.h
@@ -0,0 +1,26 @@
+#ifndef __ARM_TIME_H__
+#define __ARM_TIME_H__
+
+typedef unsigned long cycles_t;
+
+static inline cycles_t get_cycles (void)
+{
+        return 0;
+}
+
+struct tm;
+struct tm wallclock_time(void);
+
+
+/* Set up the timer interrupt on this CPU */
+extern void __cpuinit init_timer_interrupt(void);
+
+#endif /* __ARM_TIME_H__ */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 18:20:48 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 18:20:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXzdG-0008EL-8o; Tue, 06 Dec 2011 18:20:46 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RXzdE-00086d-3b
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 18:20:44 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1323195594!7123966!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMzAwOTc=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21799 invoked from network); 6 Dec 2011 18:19:57 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Dec 2011 18:19:57 -0000
X-IronPort-AV: E=Sophos;i="4.71,307,1320642000"; d="scan'208";a="173120780"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Dec 2011 13:19:57 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Tue, 6 Dec 2011 13:19:57 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pB6IJEjW019549;
	Tue, 6 Dec 2011 10:19:45 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Tue, 6 Dec 2011 18:20:06 +0000
Message-ID: <1323195609-17277-22-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1112061753410.31179@kaball-desktop>
References: <alpine.DEB.2.00.1112061753410.31179@kaball-desktop>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>, Tim.Deegan@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH RFC 22/25] arm: driver for the generic timer for
	ARMv7
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Driver for the generic timer for ARMv7 with virtualization extensions.
Currently it is based on the kernel timer rather than the hypervisor timer
because the latter does not work correctly on our test environment.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
---
 xen/arch/arm/Makefile      |    1 +
 xen/arch/arm/time.c        |  181 ++++++++++++++++++++++++++++++++++++++++++++
 xen/include/asm-arm/time.h |   26 ++++++
 3 files changed, 208 insertions(+), 0 deletions(-)
 create mode 100644 xen/arch/arm/time.c
 create mode 100644 xen/include/asm-arm/time.h

diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index 7ba02dd..6eff96b 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -11,6 +11,7 @@ obj-y += mm.o
 obj-y += p2m.o
 obj-y += usercopy.o
 obj-y += setup.o
+obj-y += time.o
 obj-y += smpboot.o
 obj-y += smp.o
 obj-y += shutdown.o
diff --git a/xen/arch/arm/time.c b/xen/arch/arm/time.c
new file mode 100644
index 0000000..13c1254
--- /dev/null
+++ b/xen/arch/arm/time.c
@@ -0,0 +1,181 @@
+/*
+ * xen/arch/arm/time.c
+ *
+ * Time and timer support, using the ARM Generic Timer interfaces
+ *
+ * Tim Deegan <tim@xen.org>
+ * Copyright (c) 2011 Citrix Systems.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include <xen/config.h>
+#include <xen/console.h>
+#include <xen/init.h>
+#include <xen/irq.h>
+#include <xen/lib.h>
+#include <xen/mm.h>
+#include <xen/softirq.h>
+#include <xen/time.h>
+#include <asm/system.h>
+
+/* Unfortunately the hypervisor timer interrupt appears to be buggy */
+#define USE_HYP_TIMER 0
+
+/* For fine-grained timekeeping, we use the ARM "Generic Timer", a
+ * register-mapped time source in the SoC. */
+static uint32_t __read_mostly cntfrq;      /* Ticks per second */
+static uint64_t __read_mostly boot_count;  /* Counter value at boot time */
+
+/*static inline*/ s_time_t ticks_to_ns(uint64_t ticks)
+{
+    return muldiv64(ticks, SECONDS(1), cntfrq);
+}
+
+/*static inline*/ uint64_t ns_to_ticks(s_time_t ns)
+{
+    return muldiv64(ns, cntfrq, SECONDS(1));
+}
+
+/* TODO: On a real system the firmware would have set the frequency in
+   the CNTFRQ register.  Also we'd need to use devicetree to find
+   the RTC.  When we've seen some real systems, we can delete this.
+static uint32_t calibrate_timer(void)
+{
+    uint32_t sec;
+    uint64_t start, end;
+    paddr_t rtc_base = 0x1C170000ull;
+    volatile uint32_t *rtc;
+
+    ASSERT(!local_irq_is_enabled());
+    set_fixmap(FIXMAP_MISC, rtc_base >> PAGE_SHIFT, DEV_SHARED);
+    rtc = (uint32_t *) FIXMAP_ADDR(FIXMAP_MISC);
+
+    printk("Calibrating timer against RTC...");
+    // Turn on the RTC
+    rtc[3] = 1;
+    // Wait for an edge
+    sec = rtc[0] + 1;
+    do {} while ( rtc[0] != sec );
+    // Now time a few seconds
+    start = READ_CP64(CNTPCT);
+    do {} while ( rtc[0] < sec + 32 );
+    end = READ_CP64(CNTPCT);
+    printk("done.\n");
+
+    clear_fixmap(FIXMAP_MISC);
+    return (end - start) / 32;
+}
+*/
+
+/* Set up the timer on the boot CPU */
+int __init init_xen_time(void)
+{
+    /* Check that this CPU supports the Generic Timer interface */
+    if ( (READ_CP32(ID_PFR1) & ID_PFR1_GT_MASK) != ID_PFR1_GT_v1 )
+        panic("CPU does not support the Generic Timer v1 interface.\n");
+
+    cntfrq = READ_CP32(CNTFRQ);
+    boot_count = READ_CP64(CNTPCT);
+    printk("Using generic timer at %"PRIu32" Hz\n", cntfrq);
+
+    return 0;
+}
+
+/* Return number of nanoseconds since boot */
+s_time_t get_s_time(void)
+{
+    uint64_t ticks = READ_CP64(CNTPCT) - boot_count;
+    return ticks_to_ns(ticks);
+}
+
+/* Set the timer to wake us up at a particular time.
+ * Timeout is a Xen system time (nanoseconds since boot); 0 disables the timer.
+ * Returns 1 on success; 0 if the timeout is too soon or is in the past. */
+int reprogram_timer(s_time_t timeout)
+{
+    uint64_t deadline;
+
+    if ( timeout == 0 )
+    {
+#if USE_HYP_TIMER
+        WRITE_CP32(0, CNTHP_CTL);
+#else
+        WRITE_CP32(0, CNTP_CTL);
+#endif
+        return 1;
+    }
+
+    deadline = ns_to_ticks(timeout) + boot_count;
+#if USE_HYP_TIMER
+    WRITE_CP64(deadline, CNTHP_CVAL);
+    WRITE_CP32(CNTx_CTL_ENABLE, CNTHP_CTL);
+#else
+    WRITE_CP64(deadline, CNTP_CVAL);
+    WRITE_CP32(CNTx_CTL_ENABLE, CNTP_CTL);
+#endif
+    isb();
+
+    /* No need to check for timers in the past; the Generic Timer fires
+     * on a signed 63-bit comparison. */
+    return 1;
+}
+
+/* Handle the firing timer */
+static void timer_interrupt(int irq, void *dev_id, struct cpu_user_regs *regs)
+{
+    if ( irq == 26 && READ_CP32(CNTHP_CTL) & CNTx_CTL_PENDING )
+    {
+        /* Signal the generic timer code to do its work */
+        raise_softirq(TIMER_SOFTIRQ);
+        /* Disable the timer to avoid more interrupts */
+        WRITE_CP32(0, CNTHP_CTL);
+    }
+
+    if (irq == 30 && READ_CP32(CNTP_CTL) & CNTx_CTL_PENDING )
+    {
+        /* Signal the generic timer code to do its work */
+        raise_softirq(TIMER_SOFTIRQ);
+        /* Disable the timer to avoid more interrupts */
+        WRITE_CP32(0, CNTP_CTL);
+    }
+}
+
+/* Set up the timer interrupt on this CPU */
+void __cpuinit init_timer_interrupt(void)
+{
+    /* Sensible defaults */
+    WRITE_CP64(0, CNTVOFF);     /* No VM-specific offset */
+    WRITE_CP32(0, CNTKCTL);     /* No user-mode access */
+#if USE_HYP_TIMER
+    /* Let the VMs read the physical counter and timer so they can tell time */
+    WRITE_CP32(CNTHCTL_PA|CNTHCTL_TA, CNTHCTL);
+#else
+    /* Cannot let VMs access physical counter if we are using it */
+    WRITE_CP32(0, CNTHCTL);
+#endif
+    WRITE_CP32(0, CNTP_CTL);    /* Physical timer disabled */
+    WRITE_CP32(0, CNTHP_CTL);   /* Hypervisor's timer disabled */
+    isb();
+
+    /* XXX Need to find this IRQ number from devicetree? */
+    request_irq(26, timer_interrupt, 0, "hyptimer", NULL);
+    request_irq(30, timer_interrupt, 0, "phytimer", NULL);
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/time.h b/xen/include/asm-arm/time.h
new file mode 100644
index 0000000..8cc9e78
--- /dev/null
+++ b/xen/include/asm-arm/time.h
@@ -0,0 +1,26 @@
+#ifndef __ARM_TIME_H__
+#define __ARM_TIME_H__
+
+typedef unsigned long cycles_t;
+
+static inline cycles_t get_cycles (void)
+{
+        return 0;
+}
+
+struct tm;
+struct tm wallclock_time(void);
+
+
+/* Set up the timer interrupt on this CPU */
+extern void __cpuinit init_timer_interrupt(void);
+
+#endif /* __ARM_TIME_H__ */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 18:20:50 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 18:20:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXzdH-0008Fv-OM; Tue, 06 Dec 2011 18:20:47 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RXzdF-000892-QY
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 18:20:46 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1323195597!1577792!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDcxMjI=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9799 invoked from network); 6 Dec 2011 18:19:58 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Dec 2011 18:19:58 -0000
X-IronPort-AV: E=Sophos;i="4.71,307,1320642000"; d="scan'208";a="19721951"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Dec 2011 13:19:56 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Tue, 6 Dec 2011 13:19:56 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pB6IJEjS019549;
	Tue, 6 Dec 2011 10:19:39 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Tue, 6 Dec 2011 18:20:02 +0000
Message-ID: <1323195609-17277-18-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1112061753410.31179@kaball-desktop>
References: <alpine.DEB.2.00.1112061753410.31179@kaball-desktop>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>, Tim.Deegan@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH RFC 18/25] arm: mm and p2m
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Functions to setup pagetables, handle the p2m, map and unmap domain
pages, copy data to/from guest addresses.
The implementation is based on the LPAE extension for ARMv7 and makes
use of the two level transtion mechanism.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
---
 xen/arch/arm/Makefile              |    3 +
 xen/arch/arm/domain.c              |    4 +
 xen/arch/arm/mm.c                  |  321 ++++++++++++++++++++++++++++++++++
 xen/arch/arm/p2m.c                 |  214 +++++++++++++++++++++++
 xen/arch/arm/usercopy.c            |   81 +++++++++
 xen/include/asm-arm/domain.h       |    2 +
 xen/include/asm-arm/guest_access.h |  125 +++++++++++++
 xen/include/asm-arm/mm.h           |  315 +++++++++++++++++++++++++++++++++
 xen/include/asm-arm/p2m.h          |   88 ++++++++++
 xen/include/asm-arm/page.h         |  335 ++++++++++++++++++++++++++++++++++++
 10 files changed, 1488 insertions(+), 0 deletions(-)
 create mode 100644 xen/arch/arm/mm.c
 create mode 100644 xen/arch/arm/p2m.c
 create mode 100644 xen/arch/arm/usercopy.c
 create mode 100644 xen/include/asm-arm/guest_access.h
 create mode 100644 xen/include/asm-arm/mm.h
 create mode 100644 xen/include/asm-arm/p2m.h
 create mode 100644 xen/include/asm-arm/page.h

diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index 5593d2b..fb8f4ee 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -7,6 +7,9 @@ obj-y += domain_build.o
 obj-y += gic.o
 obj-y += io.o
 obj-y += irq.o
+obj-y += mm.o
+obj-y += p2m.o
+obj-y += usercopy.o
 
 #obj-bin-y += ....o
 
diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index ecbc5b7..0844b37 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -224,6 +224,10 @@ int arch_domain_create(struct domain *d, unsigned int domcr_flags)
 {
     int rc;
 
+    rc = -ENOMEM;
+    if ( (rc = p2m_init(d)) != 0 )
+        goto fail;
+
     d->max_vcpus = 8;
 
     rc = 0;
diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
new file mode 100644
index 0000000..613d084
--- /dev/null
+++ b/xen/arch/arm/mm.c
@@ -0,0 +1,321 @@
+/*
+ * xen/arch/arm/mm.c
+ *
+ * MMU code for an ARMv7-A with virt extensions.
+ *
+ * Tim Deegan <tim@xen.org>
+ * Copyright (c) 2011 Citrix Systems.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include <xen/config.h>
+#include <xen/compile.h>
+#include <xen/types.h>
+#include <xen/init.h>
+#include <xen/mm.h>
+#include <xen/preempt.h>
+#include <asm/page.h>
+#include <asm/current.h>
+
+struct domain *dom_xen, *dom_io;
+
+/* Static start-of-day pagetables that we use before the allocators are up */
+lpae_t xen_pgtable[LPAE_ENTRIES] __attribute__((__aligned__(4096)));
+lpae_t xen_second[LPAE_ENTRIES*4] __attribute__((__aligned__(4096*4)));
+static lpae_t xen_fixmap[LPAE_ENTRIES] __attribute__((__aligned__(4096)));
+static lpae_t xen_xenmap[LPAE_ENTRIES] __attribute__((__aligned__(4096)));
+
+/* Limits of the Xen heap */
+unsigned long xenheap_mfn_start, xenheap_mfn_end;
+unsigned long xenheap_virt_end;
+
+unsigned long frametable_virt_end;
+
+/* Map a 4k page in a fixmap entry */
+void set_fixmap(unsigned map, unsigned long mfn, unsigned attributes)
+{
+    lpae_t pte = mfn_to_xen_entry(mfn);
+    pte.pt.table = 1; /* 4k mappings always have this bit set */
+    pte.pt.ai = attributes;
+    write_pte(xen_fixmap + third_table_offset(FIXMAP_ADDR(map)), pte);
+    flush_xen_data_tlb_va(FIXMAP_ADDR(map));
+}
+
+/* Remove a mapping from a fixmap entry */
+void clear_fixmap(unsigned map)
+{
+    lpae_t pte = {0};
+    write_pte(xen_fixmap + third_table_offset(FIXMAP_ADDR(map)), pte);
+    flush_xen_data_tlb_va(FIXMAP_ADDR(map));
+}
+
+/* Map a page of domheap memory */
+void *map_domain_page(unsigned long mfn)
+{
+    unsigned long flags;
+    lpae_t *map = xen_second + second_linear_offset(DOMHEAP_VIRT_START);
+    unsigned long slot_mfn = mfn & ~LPAE_ENTRY_MASK;
+    uint32_t va;
+    lpae_t pte;
+    int i, slot;
+
+    local_irq_save(flags);
+
+    /* The map is laid out as an open-addressed hash table where each
+     * entry is a 2MB superpage pte.  We use the available bits of each
+     * PTE as a reference count; when the refcount is zero the slot can
+     * be reused. */
+    for ( slot = (slot_mfn >> LPAE_SHIFT) % DOMHEAP_ENTRIES, i = 0;
+          i < DOMHEAP_ENTRIES;
+          slot = (slot + 1) % DOMHEAP_ENTRIES, i++ )
+    {
+        if ( map[slot].pt.avail == 0 )
+        {
+            /* Commandeer this 2MB slot */
+            pte = mfn_to_xen_entry(slot_mfn);
+            pte.pt.avail = 1;
+            write_pte(map + slot, pte);
+            break;
+        }
+        else if ( map[slot].pt.avail < 0xf && map[slot].pt.base == slot_mfn )
+        {
+            /* This slot already points to the right place; reuse it */
+            map[slot].pt.avail++;
+            break;
+        }
+    }
+    /* If the map fills up, the callers have misbehaved. */
+    BUG_ON(i == DOMHEAP_ENTRIES);
+
+#ifndef NDEBUG
+    /* Searching the hash could get slow if the map starts filling up.
+     * Cross that bridge when we come to it */
+    {
+        static int max_tries = 32;
+        if ( i >= max_tries )
+        {
+            dprintk(XENLOG_WARNING, "Domheap map is filling: %i tries\n", i);
+            max_tries *= 2;
+        }
+    }
+#endif
+
+    local_irq_restore(flags);
+
+    va = (DOMHEAP_VIRT_START
+          + (slot << SECOND_SHIFT)
+          + ((mfn & LPAE_ENTRY_MASK) << THIRD_SHIFT));
+
+    /*
+     * We may not have flushed this specific subpage at map time,
+     * since we only flush the 4k page not the superpage
+     */
+    flush_xen_data_tlb_va(va);
+
+    return (void *)va;
+}
+
+/* Release a mapping taken with map_domain_page() */
+void unmap_domain_page(const void *va)
+{
+    unsigned long flags;
+    lpae_t *map = xen_second + second_linear_offset(DOMHEAP_VIRT_START);
+    int slot = ((unsigned long) va - DOMHEAP_VIRT_START) >> SECOND_SHIFT;
+
+    local_irq_save(flags);
+
+    ASSERT(slot >= 0 && slot < DOMHEAP_ENTRIES);
+    ASSERT(map[slot].pt.avail != 0);
+
+    map[slot].pt.avail--;
+
+    local_irq_restore(flags);
+}
+
+
+/* Boot-time pagetable setup.
+ * Changes here may need matching changes in head.S */
+void __init setup_pagetables(unsigned long boot_phys_offset)
+{
+    paddr_t xen_paddr, phys_offset;
+    unsigned long dest_va;
+    lpae_t pte, *p;
+    int i;
+
+    if ( boot_phys_offset != 0 )
+    {
+        /* Remove the old identity mapping of the boot paddr */
+        pte.bits = 0;
+        dest_va = (unsigned long)_start + boot_phys_offset;
+        write_pte(xen_second + second_linear_offset(dest_va), pte);
+    }
+
+    xen_paddr = XEN_PADDR;
+
+    /* Map the destination in the empty L2 above the fixmap */
+    dest_va = FIXMAP_ADDR(0) + (1u << SECOND_SHIFT);
+    pte = mfn_to_xen_entry(xen_paddr >> PAGE_SHIFT);
+    write_pte(xen_second + second_table_offset(dest_va), pte);
+
+    /* Calculate virt-to-phys offset for the new location */
+    phys_offset = xen_paddr - (unsigned long) _start;
+
+    /* Copy */
+    memcpy((void *) dest_va, _start, _end - _start);
+
+    /* Beware!  Any state we modify between now and the PT switch may be
+     * discarded when we switch over to the copy. */
+
+    /* Update the copy of xen_pgtable to use the new paddrs */
+    p = (void *) xen_pgtable + dest_va - (unsigned long) _start;
+    for ( i = 0; i < 4; i++)
+        p[i].pt.base += (phys_offset - boot_phys_offset) >> PAGE_SHIFT;
+    p = (void *) xen_second + dest_va - (unsigned long) _start;
+    for ( i = 0; i < 4 * LPAE_ENTRIES; i++)
+        if ( p[i].pt.valid )
+                p[i].pt.base += (phys_offset - boot_phys_offset) >> PAGE_SHIFT;
+
+    /* Change pagetables to the copy in the relocated Xen */
+    asm volatile (
+        STORE_CP64(0, HTTBR)          /* Change translation base */
+        "dsb;"                        /* Ensure visibility of HTTBR update */
+        STORE_CP32(0, TLBIALLH)       /* Flush hypervisor TLB */
+        STORE_CP32(0, BPIALL)         /* Flush branch predictor */
+        "dsb;"                        /* Ensure completion of TLB+BP flush */
+        "isb;"
+        : : "r" ((unsigned long) xen_pgtable + phys_offset) : "memory");
+
+    /* Undo the temporary map */
+    pte.bits = 0;
+    write_pte(xen_second + second_table_offset(dest_va), pte);
+    /*
+     * Have removed a mapping previously used for .text. Flush everything
+     * for safety.
+     */
+    asm volatile (
+        "dsb;"                        /* Ensure visibility of PTE write */
+        STORE_CP32(0, TLBIALLH)       /* Flush hypervisor TLB */
+        STORE_CP32(0, BPIALL)         /* Flush branch predictor */
+        "dsb;"                        /* Ensure completion of TLB+BP flush */
+        "isb;"
+        : : "r" (i /*dummy*/) : "memory");
+
+    /* Link in the fixmap pagetable */
+    pte = mfn_to_xen_entry((((unsigned long) xen_fixmap) + phys_offset)
+                           >> PAGE_SHIFT);
+    pte.pt.table = 1;
+    write_pte(xen_second + second_table_offset(FIXMAP_ADDR(0)), pte);
+    /*
+     * No flush required here. Individual flushes are done in
+     * set_fixmap as entries are used.
+     */
+
+    /* Break up the Xen mapping into 4k pages and protect them separately. */
+    for ( i = 0; i < LPAE_ENTRIES; i++ )
+    {
+        unsigned long mfn = paddr_to_pfn(xen_paddr) + i;
+        unsigned long va = XEN_VIRT_START + (i << PAGE_SHIFT);
+        if ( !is_kernel(va) )
+            break;
+        pte = mfn_to_xen_entry(mfn);
+        pte.pt.table = 1; /* 4k mappings always have this bit set */
+        if ( is_kernel_text(va) || is_kernel_inittext(va) )
+        {
+            pte.pt.xn = 0;
+            pte.pt.ro = 1;
+        }
+        if ( is_kernel_rodata(va) )
+            pte.pt.ro = 1;
+        write_pte(xen_xenmap + i, pte);
+        /* No flush required here as page table is not hooked in yet. */
+    }
+    pte = mfn_to_xen_entry((((unsigned long) xen_xenmap) + phys_offset)
+                           >> PAGE_SHIFT);
+    pte.pt.table = 1;
+    write_pte(xen_second + second_linear_offset(XEN_VIRT_START), pte);
+    /* Have changed a mapping used for .text. Flush everything for safety. */
+    asm volatile (
+        "dsb;"                        /* Ensure visibility of PTE write */
+        STORE_CP32(0, TLBIALLH)       /* Flush hypervisor TLB */
+        STORE_CP32(0, BPIALL)         /* Flush branch predictor */
+        "dsb;"                        /* Ensure completion of TLB+BP flush */
+        "isb;"
+        : : "r" (i /*dummy*/) : "memory");
+
+    /* From now on, no mapping may be both writable and executable. */
+    WRITE_CP32(READ_CP32(HSCTLR) | SCTLR_WXN, HSCTLR);
+}
+
+/* Create Xen's mappings of memory.
+ * Base and virt must be 32MB aligned and size a multiple of 32MB. */
+static void __init create_mappings(unsigned long virt,
+                                   unsigned long base_mfn,
+                                   unsigned long nr_mfns)
+{
+    unsigned long i, count;
+    lpae_t pte, *p;
+
+    ASSERT(!((virt >> PAGE_SHIFT) % (16 * LPAE_ENTRIES)));
+    ASSERT(!(base_mfn % (16 * LPAE_ENTRIES)));
+    ASSERT(!(nr_mfns % (16 * LPAE_ENTRIES)));
+
+    count = nr_mfns / LPAE_ENTRIES;
+    p = xen_second + second_linear_offset(virt);
+    pte = mfn_to_xen_entry(base_mfn);
+    pte.pt.hint = 1;  /* These maps are in 16-entry contiguous chunks. */
+    for ( i = 0; i < count; i++ )
+    {
+        write_pte(p + i, pte);
+        pte.pt.base += 1 << LPAE_SHIFT;
+    }
+    flush_xen_data_tlb();
+}
+
+/* Set up the xenheap: up to 1GB of contiguous, always-mapped memory. */
+void __init setup_xenheap_mappings(unsigned long base_mfn,
+                                   unsigned long nr_mfns)
+{
+    create_mappings(XENHEAP_VIRT_START, base_mfn, nr_mfns);
+
+    /* Record where the xenheap is, for translation routines. */
+    xenheap_virt_end = XENHEAP_VIRT_START + nr_mfns * PAGE_SIZE;
+    xenheap_mfn_start = base_mfn;
+    xenheap_mfn_end = base_mfn + nr_mfns;
+}
+
+/* Map a frame table to cover physical addresses ps through pe */
+void __init setup_frametable_mappings(paddr_t ps, paddr_t pe)
+{
+    unsigned long nr_pages = (pe - ps) >> PAGE_SHIFT;
+    unsigned long frametable_size = nr_pages * sizeof(struct page_info);
+    unsigned long base_mfn;
+
+    /* Round up to 32M boundary */
+    frametable_size = (frametable_size + 0x1ffffff) & ~0x1ffffff;
+    base_mfn = alloc_boot_pages(frametable_size >> PAGE_SHIFT, 5);
+    create_mappings(FRAMETABLE_VIRT_START, base_mfn, frametable_size >> PAGE_SHIFT);
+
+    memset(&frame_table[0], 0, nr_pages * sizeof(struct page_info));
+    memset(&frame_table[nr_pages], -1,
+           frametable_size - (nr_pages * sizeof(struct page_info)));
+
+    frametable_virt_end = FRAMETABLE_VIRT_START + (nr_pages * sizeof(struct page_info));
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
new file mode 100644
index 0000000..a1d026d
--- /dev/null
+++ b/xen/arch/arm/p2m.c
@@ -0,0 +1,214 @@
+#include <xen/config.h>
+#include <xen/sched.h>
+#include <xen/lib.h>
+#include <xen/errno.h>
+#include <xen/domain_page.h>
+
+void p2m_load_VTTBR(struct domain *d)
+{
+    struct p2m_domain *p2m = &d->arch.p2m;
+    paddr_t maddr = page_to_maddr(p2m->first_level);
+    uint64_t vttbr = maddr;
+
+    vttbr |= ((uint64_t)p2m->vmid&0xff)<<48;
+
+    printk("VTTBR dom%d = %"PRIx64"\n", d->domain_id, vttbr);
+
+    WRITE_CP64(vttbr, VTTBR);
+    isb(); /* Ensure update is visible */
+}
+
+static int p2m_create_entry(struct domain *d,
+                            lpae_t *entry)
+{
+    struct p2m_domain *p2m = &d->arch.p2m;
+    struct page_info *page;
+    void *p;
+    lpae_t pte;
+
+    BUG_ON(entry->p2m.valid);
+
+    page = alloc_domheap_page(d, 0);
+    if ( page == NULL )
+        return -ENOMEM;
+
+    page_list_add(page, &p2m->pages);
+
+    p = __map_domain_page(page);
+    clear_page(p);
+    unmap_domain_page(p);
+
+    pte = mfn_to_p2m_entry(page_to_mfn(page));
+
+    write_pte(entry, pte);
+
+    return 0;
+}
+
+static int create_p2m_entries(struct domain *d,
+                     int alloc,
+                     paddr_t start_gpaddr,
+                     paddr_t end_gpaddr,
+                     paddr_t maddr)
+{
+    int rc;
+    struct p2m_domain *p2m = &d->arch.p2m;
+    lpae_t *first = NULL, *second = NULL, *third = NULL;
+    paddr_t addr;
+    unsigned long cur_first_offset = ~0, cur_second_offset = ~0;
+
+    /* XXX Don't actually handle 40 bit guest physical addresses */
+    BUG_ON(start_gpaddr & 0x8000000000ULL);
+    BUG_ON(end_gpaddr   & 0x8000000000ULL);
+
+    first = __map_domain_page(p2m->first_level);
+
+    for(addr = start_gpaddr; addr < end_gpaddr; addr += PAGE_SIZE)
+    {
+        if ( !first[first_table_offset(addr)].p2m.valid )
+        {
+            rc = p2m_create_entry(d, &first[first_table_offset(addr)]);
+            if ( rc < 0 ) {
+                printk("p2m_populate_ram: L1 failed\n");
+                goto out;
+            }
+        }
+
+        BUG_ON(!first[first_table_offset(addr)].p2m.valid);
+
+        if ( cur_first_offset != first_table_offset(addr) )
+        {
+            if (second) unmap_domain_page(second);
+            second = map_domain_page(first[first_table_offset(addr)].p2m.base);
+            cur_first_offset = first_table_offset(addr);
+        }
+        /* else: second already valid */
+
+        if ( !second[second_table_offset(addr)].p2m.valid )
+        {
+            rc = p2m_create_entry(d, &second[second_table_offset(addr)]);
+            if ( rc < 0 ) {
+                printk("p2m_populate_ram: L2 failed\n");
+                goto out;
+            }
+        }
+
+        BUG_ON(!second[second_table_offset(addr)].p2m.valid);
+
+        if ( cur_second_offset != second_table_offset(addr) )
+        {
+            /* map third level */
+            if (third) unmap_domain_page(third);
+            third = map_domain_page(second[second_table_offset(addr)].p2m.base);
+            cur_second_offset = second_table_offset(addr);
+        }
+        /* else: third already valid */
+
+        BUG_ON(third[third_table_offset(addr)].p2m.valid);
+
+        /* Allocate a new RAM page and attach */
+        if (alloc)
+        {
+            struct page_info *page;
+            lpae_t pte;
+
+            rc = -ENOMEM;
+            page = alloc_domheap_page(d, 0);
+            if ( page == NULL ) {
+                printk("p2m_populate_ram: failed to allocate page\n");
+                goto out;
+            }
+
+            pte = mfn_to_p2m_entry(page_to_mfn(page));
+
+            write_pte(&third[third_table_offset(addr)], pte);
+        } else {
+            lpae_t pte = mfn_to_p2m_entry(maddr >> PAGE_SHIFT);
+            write_pte(&third[third_table_offset(addr)], pte);
+            maddr += PAGE_SIZE;
+        }
+    }
+
+    rc = 0;
+
+out:
+    spin_lock(&p2m->lock);
+
+    if (third) unmap_domain_page(third);
+    if (second) unmap_domain_page(second);
+    if (first) unmap_domain_page(first);
+
+    spin_unlock(&p2m->lock);
+
+    return rc;
+}
+
+int p2m_populate_ram(struct domain *d,
+                     paddr_t start,
+                     paddr_t end)
+{
+    return create_p2m_entries(d, 1, start, end, 0);
+}
+
+int map_mmio_regions(struct domain *d,
+                     paddr_t start_gaddr,
+                     paddr_t end_gaddr,
+                     paddr_t maddr)
+{
+    return create_p2m_entries(d, 0, start_gaddr, end_gaddr, maddr);
+}
+
+int p2m_alloc_table(struct domain *d)
+{
+    struct p2m_domain *p2m = &d->arch.p2m;
+    struct page_info *page;
+    void *p;
+
+    /* First level P2M is 2 consecutive pages */
+    page = alloc_domheap_pages(d, 1, 0);
+    if ( page == NULL )
+        return -ENOMEM;
+
+    spin_lock(&p2m->lock);
+
+    page_list_add(page, &p2m->pages);
+
+    /* Clear both first level pages */
+    p = __map_domain_page(page);
+    clear_page(p);
+    unmap_domain_page(p);
+
+    p = __map_domain_page(page + 1);
+    clear_page(p);
+    unmap_domain_page(p);
+
+    p2m->first_level = page;
+
+    spin_unlock(&p2m->lock);
+
+    return 0;
+}
+
+int p2m_init(struct domain *d)
+{
+    struct p2m_domain *p2m = &d->arch.p2m;
+
+    spin_lock_init(&p2m->lock);
+    INIT_PAGE_LIST_HEAD(&p2m->pages);
+
+    /* XXX allocate properly */
+    /* Zero is reserved */
+    p2m->vmid = d->domain_id + 1;
+
+    p2m->first_level = NULL;
+
+    return 0;
+}
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/arch/arm/usercopy.c b/xen/arch/arm/usercopy.c
new file mode 100644
index 0000000..6f51e0f
--- /dev/null
+++ b/xen/arch/arm/usercopy.c
@@ -0,0 +1,81 @@
+#include <xen/config.h>
+#include <xen/lib.h>
+#include <xen/domain_page.h>
+
+#include <asm/mm.h>
+#include <asm/guest_access.h>
+
+unsigned long copy_to_user(void __user *to, const void *from, unsigned len)
+{
+    /* XXX needs to handle faults */
+    unsigned offset = ((unsigned long)to & ~PAGE_MASK);
+
+    while ( len )
+    {
+        paddr_t g = gvirt_to_maddr((uint32_t) to);
+        void *p = map_domain_page(g>>PAGE_SHIFT);
+        unsigned size = min(len, (unsigned)PAGE_SIZE - offset);
+
+        p += offset;
+        memcpy(p, from, size);
+
+        unmap_domain_page(p - offset);
+        len -= size;
+        from += size;
+        to += size;
+        offset = 0;
+    }
+
+    return 0;
+}
+
+unsigned long clear_user(void __user *to, unsigned len)
+{
+    /* XXX needs to handle faults */
+    unsigned offset = ((unsigned long)to & ~PAGE_MASK);
+
+    while ( len )
+    {
+        paddr_t g = gvirt_to_maddr((uint32_t) to);
+        void *p = map_domain_page(g>>PAGE_SHIFT);
+        unsigned size = min(len, (unsigned)PAGE_SIZE - offset);
+
+        p += offset;
+        memset(p, 0x00, size);
+
+        unmap_domain_page(p - offset);
+        len -= size;
+        to += size;
+        offset = 0;
+    }
+
+    return 0;
+}
+
+unsigned long copy_from_user(void *to, const void __user *from, unsigned len)
+{
+    while ( len )
+    {
+        paddr_t g = gvirt_to_maddr((uint32_t) from & PAGE_MASK);
+        void *p = map_domain_page(g>>PAGE_SHIFT);
+        unsigned size = min(len, (unsigned)(PAGE_SIZE - ((unsigned)from & (~PAGE_MASK))));
+
+        p += ((unsigned long)from & (~PAGE_MASK));
+
+        memcpy(to, p, size);
+
+        unmap_domain_page(p);
+        len -= size;
+        from += size;
+        to += size;
+    }
+    return 0;
+}
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
index c226bdf..2226a24 100644
--- a/xen/include/asm-arm/domain.h
+++ b/xen/include/asm-arm/domain.h
@@ -16,6 +16,8 @@ struct pending_irq
 
 struct arch_domain
 {
+    struct p2m_domain p2m;
+
 }  __cacheline_aligned;
 
 struct arch_vcpu
diff --git a/xen/include/asm-arm/guest_access.h b/xen/include/asm-arm/guest_access.h
new file mode 100644
index 0000000..b8d4e63
--- /dev/null
+++ b/xen/include/asm-arm/guest_access.h
@@ -0,0 +1,125 @@
+#ifndef __ASM_ARM_GUEST_ACCESS_H__
+#define __ASM_ARM_GUEST_ACCESS_H__
+
+#include <xen/errno.h>
+
+/* Guests have their own comlete address space */
+#define access_ok(addr,size) (1)
+
+#define array_access_ok(addr,count,size) \
+    (likely(count < (~0UL/size)) && access_ok(addr,count*size))
+
+unsigned long copy_to_user(void *to, const void *from, unsigned len);
+unsigned long copy_from_user(void *to, const void *from, unsigned len);
+unsigned long clear_user(void *to, unsigned len);
+
+/* Raw access functions: no type checking. */
+/* All accesses are HVM type in ARM */
+#define raw_copy_to_guest(dst, src, len)        \
+    copy_to_user((dst), (src), (len))
+#define raw_copy_from_guest(dst, src, len)      \
+    copy_from_user((dst), (src), (len))
+#define __raw_copy_to_guest(dst, src, len)      \
+    copy_to_user((dst), (src), (len))
+#define __raw_copy_from_guest(dst, src, len)    \
+    copy_from_user((dst), (src), (len))
+
+/* Remainder copied from x86 -- could be common? */
+
+/* Is the guest handle a NULL reference? */
+#define guest_handle_is_null(hnd)        ((hnd).p == NULL)
+
+/* Offset the given guest handle into the array it refers to. */
+#define guest_handle_add_offset(hnd, nr) ((hnd).p += (nr))
+#define guest_handle_subtract_offset(hnd, nr) ((hnd).p -= (nr))
+
+/* Cast a guest handle to the specified type of handle. */
+#define guest_handle_cast(hnd, type) ({         \
+    type *_x = (hnd).p;                         \
+    (XEN_GUEST_HANDLE(type)) { _x };            \
+})
+
+#define guest_handle_from_ptr(ptr, type)        \
+    ((XEN_GUEST_HANDLE(type)) { (type *)ptr })
+#define const_guest_handle_from_ptr(ptr, type)  \
+    ((XEN_GUEST_HANDLE(const_##type)) { (const type *)ptr })
+
+/*
+ * Copy an array of objects to guest context via a guest handle,
+ * specifying an offset into the guest array.
+ */
+#define copy_to_guest_offset(hnd, off, ptr, nr) ({      \
+    const typeof(*(ptr)) *_s = (ptr);                   \
+    char (*_d)[sizeof(*_s)] = (void *)(hnd).p;          \
+    ((void)((hnd).p == (ptr)));                         \
+    raw_copy_to_guest(_d+(off), _s, sizeof(*_s)*(nr));  \
+})
+
+/*
+ * Copy an array of objects from guest context via a guest handle,
+ * specifying an offset into the guest array.
+ */
+#define copy_from_guest_offset(ptr, hnd, off, nr) ({    \
+    const typeof(*(ptr)) *_s = (hnd).p;                 \
+    typeof(*(ptr)) *_d = (ptr);                         \
+    raw_copy_from_guest(_d, _s+(off), sizeof(*_d)*(nr));\
+})
+
+/* Copy sub-field of a structure to guest context via a guest handle. */
+#define copy_field_to_guest(hnd, ptr, field) ({         \
+    const typeof(&(ptr)->field) _s = &(ptr)->field;     \
+    void *_d = &(hnd).p->field;                         \
+    ((void)(&(hnd).p->field == &(ptr)->field));         \
+    raw_copy_to_guest(_d, _s, sizeof(*_s));             \
+})
+
+/* Copy sub-field of a structure from guest context via a guest handle. */
+#define copy_field_from_guest(ptr, hnd, field) ({       \
+    const typeof(&(ptr)->field) _s = &(hnd).p->field;   \
+    typeof(&(ptr)->field) _d = &(ptr)->field;           \
+    raw_copy_from_guest(_d, _s, sizeof(*_d));           \
+})
+
+/*
+ * Pre-validate a guest handle.
+ * Allows use of faster __copy_* functions.
+ */
+/* All ARM guests are paging mode external and hence safe */
+#define guest_handle_okay(hnd, nr) (1)
+#define guest_handle_subrange_okay(hnd, first, last) (1)
+
+#define __copy_to_guest_offset(hnd, off, ptr, nr) ({    \
+    const typeof(*(ptr)) *_s = (ptr);                   \
+    char (*_d)[sizeof(*_s)] = (void *)(hnd).p;          \
+    ((void)((hnd).p == (ptr)));                         \
+    __raw_copy_to_guest(_d+(off), _s, sizeof(*_s)*(nr));\
+})
+
+#define __copy_from_guest_offset(ptr, hnd, off, nr) ({  \
+    const typeof(*(ptr)) *_s = (hnd).p;                 \
+    typeof(*(ptr)) *_d = (ptr);                         \
+    __raw_copy_from_guest(_d, _s+(off), sizeof(*_d)*(nr));\
+})
+
+#define __copy_field_to_guest(hnd, ptr, field) ({       \
+    const typeof(&(ptr)->field) _s = &(ptr)->field;     \
+    void *_d = &(hnd).p->field;                         \
+    ((void)(&(hnd).p->field == &(ptr)->field));         \
+    __raw_copy_to_guest(_d, _s, sizeof(*_s));           \
+})
+
+#define __copy_field_from_guest(ptr, hnd, field) ({     \
+    const typeof(&(ptr)->field) _s = &(hnd).p->field;   \
+    typeof(&(ptr)->field) _d = &(ptr)->field;           \
+    __raw_copy_from_guest(_d, _s, sizeof(*_d));         \
+})
+
+#endif /* __ASM_ARM_GUEST_ACCESS_H__ */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/mm.h b/xen/include/asm-arm/mm.h
new file mode 100644
index 0000000..ead6e0c
--- /dev/null
+++ b/xen/include/asm-arm/mm.h
@@ -0,0 +1,315 @@
+#ifndef __ARCH_ARM_MM__
+#define __ARCH_ARM_MM__
+
+#include <xen/config.h>
+#include <xen/kernel.h>
+#include <asm/page.h>
+#include <public/xen.h>
+
+/* Find a suitable place at the top of memory for Xen to live */
+/* XXX For now, use the top of the VE's 4GB RAM, at a 40-bit alias */
+#define XEN_PADDR 0x80ffe00000ull
+
+/*
+ * Per-page-frame information.
+ *
+ * Every architecture must ensure the following:
+ *  1. 'struct page_info' contains a 'struct page_list_entry list'.
+ *  2. Provide a PFN_ORDER() macro for accessing the order of a free page.
+ */
+#define PFN_ORDER(_pfn) ((_pfn)->v.free.order)
+
+struct page_info
+{
+    /* Each frame can be threaded onto a doubly-linked list. */
+    struct page_list_entry list;
+
+    /* Reference count and various PGC_xxx flags and fields. */
+    unsigned long count_info;
+
+    /* Context-dependent fields follow... */
+    union {
+        /* Page is in use: ((count_info & PGC_count_mask) != 0). */
+        struct {
+            /* Type reference count and various PGT_xxx flags and fields. */
+            unsigned long type_info;
+        } inuse;
+        /* Page is on a free list: ((count_info & PGC_count_mask) == 0). */
+        struct {
+            /* Do TLBs need flushing for safety before next page use? */
+            bool_t need_tlbflush;
+        } free;
+
+    } u;
+
+    union {
+        /* Page is in use, but not as a shadow. */
+        struct {
+            /* Owner of this page (zero if page is anonymous). */
+            struct domain *domain;
+        } inuse;
+
+        /* Page is on a free list. */
+        struct {
+            /* Order-size of the free chunk this page is the head of. */
+            unsigned int order;
+        } free;
+
+    } v;
+
+    union {
+        /*
+         * Timestamp from 'TLB clock', used to avoid extra safety flushes.
+         * Only valid for: a) free pages, and b) pages with zero type count
+         */
+        u32 tlbflush_timestamp;
+    };
+    u64 pad;
+};
+
+#define PG_shift(idx)   (BITS_PER_LONG - (idx))
+#define PG_mask(x, idx) (x ## UL << PG_shift(idx))
+
+#define PGT_none          PG_mask(0, 4)  /* no special uses of this page   */
+#define PGT_writable_page PG_mask(7, 4)  /* has writable mappings?         */
+#define PGT_shared_page   PG_mask(8, 4)  /* CoW sharable page              */
+#define PGT_type_mask     PG_mask(15, 4) /* Bits 28-31 or 60-63.           */
+
+ /* Owning guest has pinned this page to its current type? */
+#define _PGT_pinned       PG_shift(5)
+#define PGT_pinned        PG_mask(1, 5)
+
+ /* Count of uses of this frame as its current type. */
+#define PGT_count_width   PG_shift(9)
+#define PGT_count_mask    ((1UL<<PGT_count_width)-1)
+
+ /* Cleared when the owning guest 'frees' this page. */
+#define _PGC_allocated    PG_shift(1)
+#define PGC_allocated     PG_mask(1, 1)
+  /* Page is Xen heap? */
+#define _PGC_xen_heap     PG_shift(2)
+#define PGC_xen_heap      PG_mask(1, 2)
+/* ... */
+/* Page is broken? */
+#define _PGC_broken       PG_shift(7)
+#define PGC_broken        PG_mask(1, 7)
+ /* Mutually-exclusive page states: { inuse, offlining, offlined, free }. */
+#define PGC_state         PG_mask(3, 9)
+#define PGC_state_inuse   PG_mask(0, 9)
+#define PGC_state_offlining PG_mask(1, 9)
+#define PGC_state_offlined PG_mask(2, 9)
+#define PGC_state_free    PG_mask(3, 9)
+#define page_state_is(pg, st) (((pg)->count_info&PGC_state) == PGC_state_##st)
+
+/* Count of references to this frame. */
+#define PGC_count_width   PG_shift(9)
+#define PGC_count_mask    ((1UL<<PGC_count_width)-1)
+
+extern unsigned long xenheap_mfn_start, xenheap_mfn_end;
+extern unsigned long xenheap_virt_end;
+
+#define is_xen_heap_page(page) is_xen_heap_mfn(page_to_mfn(page))
+#define is_xen_heap_mfn(mfn) ({                                 \
+    unsigned long _mfn = (mfn);                                 \
+    (_mfn >= xenheap_mfn_start && _mfn < xenheap_mfn_end);      \
+})
+#define is_xen_fixed_mfn(mfn) is_xen_heap_mfn(mfn)
+
+#define page_get_owner(_p)    (_p)->v.inuse.domain
+#define page_set_owner(_p,_d) ((_p)->v.inuse.domain = (_d))
+
+#define maddr_get_owner(ma)   (page_get_owner(maddr_to_page((ma))))
+#define vaddr_get_owner(va)   (page_get_owner(virt_to_page((va))))
+
+#define XENSHARE_writable 0
+#define XENSHARE_readonly 1
+extern void share_xen_page_with_guest(
+    struct page_info *page, struct domain *d, int readonly);
+extern void share_xen_page_with_privileged_guests(
+    struct page_info *page, int readonly);
+
+#define frame_table ((struct page_info *)FRAMETABLE_VIRT_START)
+
+extern unsigned long max_page;
+extern unsigned long total_pages;
+
+/* Boot-time pagetable setup */
+extern void setup_pagetables(unsigned long boot_phys_offset);
+/* Set up the xenheap: up to 1GB of contiguous, always-mapped memory.
+ * Base must be 32MB aligned and size a multiple of 32MB. */
+extern void setup_xenheap_mappings(unsigned long base_mfn, unsigned long nr_mfns);
+/* Map a frame table to cover physical addresses ps through pe */
+extern void setup_frametable_mappings(paddr_t ps, paddr_t pe);
+/* Map a 4k page in a fixmap entry */
+extern void set_fixmap(unsigned map, unsigned long mfn, unsigned attributes);
+/* Remove a mapping from a fixmap entry */
+extern void clear_fixmap(unsigned map);
+
+
+#define mfn_valid(mfn)        ({                                              \
+    unsigned long __m_f_n = (mfn);                                            \
+    likely(__m_f_n < max_page);                                               \
+})
+
+#define max_pdx                 max_page
+/* XXX Assume everything in the 40-bit physical alias 0x8000000000 for now */
+#define pfn_to_pdx(pfn)         ((pfn) - 0x8000000UL)
+#define pdx_to_pfn(pdx)         ((pdx) + 0x8000000UL)
+#define virt_to_pdx(va)         virt_to_mfn(va)
+#define pdx_to_virt(pdx)        mfn_to_virt(pdx)
+
+/* Convert between machine frame numbers and page-info structures. */
+#define mfn_to_page(mfn)  (frame_table + pfn_to_pdx(mfn))
+#define page_to_mfn(pg)   pdx_to_pfn((unsigned long)((pg) - frame_table))
+#define __page_to_mfn(pg)  page_to_mfn(pg)
+#define __mfn_to_page(mfn) mfn_to_page(mfn)
+
+/* Convert between machine addresses and page-info structures. */
+#define maddr_to_page(ma) __mfn_to_page((ma) >> PAGE_SHIFT)
+#define page_to_maddr(pg) ((paddr_t)__page_to_mfn(pg) << PAGE_SHIFT)
+
+/* Convert between frame number and address formats.  */
+#define pfn_to_paddr(pfn) ((paddr_t)(pfn) << PAGE_SHIFT)
+#define paddr_to_pfn(pa)  ((unsigned long)((pa) >> PAGE_SHIFT))
+#define paddr_to_pdx(pa)    pfn_to_pdx(paddr_to_pfn(pa))
+
+
+static inline paddr_t virt_to_maddr(void *va)
+{
+    uint64_t par = va_to_par((uint32_t)va);
+    return (par & PADDR_MASK & PAGE_MASK) | ((unsigned long) va & ~PAGE_MASK);
+}
+
+static inline void *maddr_to_virt(paddr_t ma)
+{
+    ASSERT(is_xen_heap_mfn(ma >> PAGE_SHIFT));
+    ma -= pfn_to_paddr(xenheap_mfn_start);
+    return (void *)(unsigned long) ma + XENHEAP_VIRT_START;
+}
+
+static inline paddr_t gvirt_to_maddr(uint32_t va)
+{
+    uint64_t par = gva_to_par(va);
+    return (par & PADDR_MASK & PAGE_MASK) | ((unsigned long) va & ~PAGE_MASK);
+}
+
+/* Convert between Xen-heap virtual addresses and machine addresses. */
+#define __pa(x)             (virt_to_maddr(x))
+#define __va(x)             (maddr_to_virt(x))
+
+/* Convert between Xen-heap virtual addresses and machine frame numbers. */
+#define virt_to_mfn(va)   (virt_to_maddr(va) >> PAGE_SHIFT)
+#define mfn_to_virt(mfn)  (maddr_to_virt((paddr_t)(mfn) << PAGE_SHIFT))
+
+
+static inline int get_order_from_bytes(paddr_t size)
+{
+    int order;
+    size = (size-1) >> PAGE_SHIFT;
+    for ( order = 0; size; order++ )
+        size >>= 1;
+    return order;
+}
+
+static inline int get_order_from_pages(unsigned long nr_pages)
+{
+    int order;
+    nr_pages--;
+    for ( order = 0; nr_pages; order++ )
+        nr_pages >>= 1;
+    return order;
+}
+
+
+/* Convert between Xen-heap virtual addresses and page-info structures. */
+static inline struct page_info *virt_to_page(const void *v)
+{
+    unsigned long va = (unsigned long)v;
+    ASSERT(va >= XENHEAP_VIRT_START);
+    ASSERT(va < xenheap_virt_end);
+
+    return frame_table + ((va - XENHEAP_VIRT_START) >> PAGE_SHIFT);
+}
+
+static inline void *page_to_virt(const struct page_info *pg)
+{
+    ASSERT((unsigned long)pg - FRAMETABLE_VIRT_START < frametable_virt_end);
+    return (void *)(XENHEAP_VIRT_START +
+                    ((unsigned long)pg - FRAMETABLE_VIRT_START) /
+                    (sizeof(*pg) / (sizeof(*pg) & -sizeof(*pg))) *
+                    (PAGE_SIZE / (sizeof(*pg) & -sizeof(*pg))));
+
+}
+
+struct domain *page_get_owner_and_reference(struct page_info *page);
+void put_page(struct page_info *page);
+int  get_page(struct page_info *page, struct domain *domain);
+
+/*
+ * The MPT (machine->physical mapping table) is an array of word-sized
+ * values, indexed on machine frame number. It is expected that guest OSes
+ * will use it to store a "physical" frame number to give the appearance of
+ * contiguous (or near contiguous) physical memory.
+ */
+#undef  machine_to_phys_mapping
+#define machine_to_phys_mapping  ((unsigned long *)RDWR_MPT_VIRT_START)
+#define INVALID_M2P_ENTRY        (~0UL)
+#define VALID_M2P(_e)            (!((_e) & (1UL<<(BITS_PER_LONG-1))))
+#define SHARED_M2P_ENTRY         (~0UL - 1UL)
+#define SHARED_M2P(_e)           ((_e) == SHARED_M2P_ENTRY)
+
+#define _set_gpfn_from_mfn(mfn, pfn) ({                        \
+    struct domain *d = page_get_owner(__mfn_to_page(mfn));     \
+    if(d && (d == dom_cow))                                    \
+        machine_to_phys_mapping[(mfn)] = SHARED_M2P_ENTRY;     \
+    else                                                       \
+        machine_to_phys_mapping[(mfn)] = (pfn);                \
+    })
+
+#define put_gfn(d, g)   ((void)0)
+
+#define INVALID_MFN             (~0UL)
+
+/* Xen always owns P2M on ARM */
+#define set_gpfn_from_mfn(mfn, pfn) do { (void) (mfn),(pfn); } while (0)
+#define mfn_to_gmfn(_d, mfn)  (mfn)
+
+
+/* Arch-specific portion of memory_op hypercall. */
+long arch_memory_op(int op, XEN_GUEST_HANDLE(void) arg);
+
+int steal_page(
+    struct domain *d, struct page_info *page, unsigned int memflags);
+int donate_page(
+    struct domain *d, struct page_info *page, unsigned int memflags);
+
+#define domain_set_alloc_bitsize(d) ((void)0)
+#define domain_clamp_alloc_bitsize(d, b) (b)
+
+unsigned long domain_get_maximum_gpfn(struct domain *d);
+
+extern struct domain *dom_xen, *dom_io, *dom_cow;
+
+#define memguard_init(_s)              (_s)
+#define memguard_guard_stack(_p)       ((void)0)
+#define memguard_guard_range(_p,_l)    ((void)0)
+#define memguard_unguard_range(_p,_l)  ((void)0)
+int guest_physmap_mark_populate_on_demand(struct domain *d, unsigned long gfn,
+                                          unsigned int order);
+
+extern void put_page_type(struct page_info *page);
+static inline void put_page_and_type(struct page_info *page)
+{
+    put_page_type(page);
+    put_page(page);
+}
+
+#endif /*  __ARCH_ARM_MM__ */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/p2m.h b/xen/include/asm-arm/p2m.h
new file mode 100644
index 0000000..aec52f7
--- /dev/null
+++ b/xen/include/asm-arm/p2m.h
@@ -0,0 +1,88 @@
+#ifndef _XEN_P2M_H
+#define _XEN_P2M_H
+
+#include <xen/mm.h>
+
+struct domain;
+
+/* Per-p2m-table state */
+struct p2m_domain {
+    /* Lock that protects updates to the p2m */
+    spinlock_t lock;
+
+    /* Pages used to construct the p2m */
+    struct page_list_head pages;
+
+    /* Root of p2m page tables, 2 contiguous pages */
+    struct page_info *first_level;
+
+    /* Current VMID in use */
+    uint8_t vmid;
+};
+
+/* Init the datastructures for later use by the p2m code */
+int p2m_init(struct domain *d);
+
+/* Allocate a new p2m table for a domain.
+ *
+ * Returns 0 for success or -errno.
+ */
+int p2m_alloc_table(struct domain *d);
+
+/* */
+void p2m_load_VTTBR(struct domain *d);
+
+/* Setup p2m RAM mapping for domain d from start-end. */
+int p2m_populate_ram(struct domain *d, paddr_t start, paddr_t end);
+/* Map MMIO regions in the p2m: start_gaddr and end_gaddr is the range
+ * in the guest physical address space to map, starting from the machine
+ * address maddr. */
+int map_mmio_regions(struct domain *d, paddr_t start_gaddr,
+                     paddr_t end_gaddr, paddr_t maddr);
+
+unsigned long gmfn_to_mfn(struct domain *d, unsigned long gpfn);
+
+/*
+ * Populate-on-demand
+ */
+
+/* Call when decreasing memory reservation to handle PoD entries properly.
+ * Will return '1' if all entries were handled and nothing more need be done.*/
+int
+p2m_pod_decrease_reservation(struct domain *d,
+                             xen_pfn_t gpfn,
+                             unsigned int order);
+
+/* Compatibility function exporting the old untyped interface */
+static inline unsigned long get_gfn_untyped(struct domain *d, unsigned long gpfn)
+{
+    return gmfn_to_mfn(d, gpfn);
+}
+
+int get_page_type(struct page_info *page, unsigned long type);
+int is_iomem_page(unsigned long mfn);
+static inline int get_page_and_type(struct page_info *page,
+                                    struct domain *domain,
+                                    unsigned long type)
+{
+    int rc = get_page(page, domain);
+
+    if ( likely(rc) && unlikely(!get_page_type(page, type)) )
+    {
+        put_page(page);
+        rc = 0;
+    }
+
+    return rc;
+}
+
+#endif /* _XEN_P2M_H */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/page.h b/xen/include/asm-arm/page.h
new file mode 100644
index 0000000..6dc1659
--- /dev/null
+++ b/xen/include/asm-arm/page.h
@@ -0,0 +1,335 @@
+#ifndef __ARM_PAGE_H__
+#define __ARM_PAGE_H__
+
+#include <xen/config.h>
+
+#define PADDR_BITS              40
+#define PADDR_MASK              ((1ULL << PADDR_BITS)-1)
+
+#define VADDR_BITS              32
+#define VADDR_MASK              (~0UL)
+
+/* Shareability values for the LPAE entries */
+#define LPAE_SH_NON_SHAREABLE 0x0
+#define LPAE_SH_UNPREDICTALE  0x1
+#define LPAE_SH_OUTER         0x2
+#define LPAE_SH_INNER         0x3
+
+/* LPAE Memory region attributes, to match Linux's (non-LPAE) choices.
+ * Indexed by the AttrIndex bits of a LPAE entry;
+ * the 8-bit fields are packed little-endian into MAIR0 and MAIR1
+ *
+ *                 ai    encoding
+ *   UNCACHED      000   0000 0000  -- Strongly Ordered
+ *   BUFFERABLE    001   0100 0100  -- Non-Cacheable
+ *   WRITETHROUGH  010   1010 1010  -- Write-through
+ *   WRITEBACK     011   1110 1110  -- Write-back
+ *   DEV_SHARED    100   0000 0100  -- Device
+ *   ??            101
+ *   reserved      110
+ *   WRITEALLOC    111   1111 1111  -- Write-back write-allocate
+ *
+ *   DEV_NONSHARED 100   (== DEV_SHARED)
+ *   DEV_WC        001   (== BUFFERABLE)
+ *   DEV_CACHED    011   (== WRITEBACK)
+ */
+#define MAIR0VAL 0xeeaa4400
+#define MAIR1VAL 0xff000004
+
+#define UNCACHED      0x0
+#define BUFFERABLE    0x1
+#define WRITETHROUGH  0x2
+#define WRITEBACK     0x3
+#define DEV_SHARED    0x4
+#define WRITEALLOC    0x7
+#define DEV_NONSHARED DEV_SHARED
+#define DEV_WC        BUFFERABLE
+#define DEV_CACHED    WRITEBACK
+
+
+#ifndef __ASSEMBLY__
+
+#include <xen/types.h>
+#include <xen/lib.h>
+
+/* WARNING!  Unlike the Intel pagetable code, where l1 is the lowest
+ * level and l4 is the root of the trie, the ARM pagetables follow ARM's
+ * documentation: the levels are called first, second &c in the order
+ * that the MMU walks them (i.e. "first" is the root of the trie). */
+
+/******************************************************************************
+ * ARMv7-A LPAE pagetables: 3-level trie, mapping 40-bit input to
+ * 40-bit output addresses.  Tables at all levels have 512 64-bit entries
+ * (i.e. are 4Kb long).
+ *
+ * The bit-shuffling that has the permission bits in branch nodes in a
+ * different place from those in leaf nodes seems to be to allow linear
+ * pagetable tricks.  If we're not doing that then the set of permission
+ * bits that's not in use in a given node type can be used as
+ * extra software-defined bits. */
+
+typedef struct {
+    /* These are used in all kinds of entry. */
+    unsigned long valid:1;      /* Valid mapping */
+    unsigned long table:1;      /* == 1 in 4k map entries too */
+
+    /* These ten bits are only used in Block entries and are ignored
+     * in Table entries. */
+    unsigned long ai:3;         /* Attribute Index */
+    unsigned long ns:1;         /* Not-Secure */
+    unsigned long user:1;       /* User-visible */
+    unsigned long ro:1;         /* Read-Only */
+    unsigned long sh:2;         /* Shareability */
+    unsigned long af:1;         /* Access Flag */
+    unsigned long ng:1;         /* Not-Global */
+
+    /* The base address must be approprately aligned for Block entries */
+    unsigned long base:28;      /* Base address of block or next table */
+    unsigned long sbz:12;       /* Must be zero */
+
+    /* These seven bits are only used in Block entries and are ignored
+     * in Table entries. */
+    unsigned long hint:1;       /* In a block of 16 contiguous entries */
+    unsigned long pxn:1;        /* Privileged-XN */
+    unsigned long xn:1;         /* eXecute-Never */
+    unsigned long avail:4;      /* Ignored by hardware */
+
+    /* These 5 bits are only used in Table entries and are ignored in
+     * Block entries */
+    unsigned long pxnt:1;       /* Privileged-XN */
+    unsigned long xnt:1;        /* eXecute-Never */
+    unsigned long apt:2;        /* Access Permissions */
+    unsigned long nst:1;        /* Not-Secure */
+} __attribute__((__packed__)) lpae_pt_t;
+
+/* The p2m tables have almost the same layout, but some of the permission
+ * and cache-control bits are laid out differently (or missing) */
+typedef struct {
+    /* These are used in all kinds of entry. */
+    unsigned long valid:1;      /* Valid mapping */
+    unsigned long table:1;      /* == 1 in 4k map entries too */
+
+    /* These ten bits are only used in Block entries and are ignored
+     * in Table entries. */
+    unsigned long mattr:4;      /* Memory Attributes */
+    unsigned long read:1;       /* Read access */
+    unsigned long write:1;      /* Write access */
+    unsigned long sh:2;         /* Shareability */
+    unsigned long af:1;         /* Access Flag */
+    unsigned long sbz4:1;
+
+    /* The base address must be approprately aligned for Block entries */
+    unsigned long base:28;      /* Base address of block or next table */
+    unsigned long sbz3:12;
+
+    /* These seven bits are only used in Block entries and are ignored
+     * in Table entries. */
+    unsigned long hint:1;       /* In a block of 16 contiguous entries */
+    unsigned long sbz2:1;
+    unsigned long xn:1;         /* eXecute-Never */
+    unsigned long avail:4;      /* Ignored by hardware */
+
+    unsigned long sbz1:5;
+} __attribute__((__packed__)) lpae_p2m_t;
+
+typedef union {
+    uint64_t bits;
+    lpae_pt_t pt;
+    lpae_p2m_t p2m;
+} lpae_t;
+
+/* Standard entry type that we'll use to build Xen's own pagetables.
+ * We put the same permissions at every level, because they're ignored
+ * by the walker in non-leaf entries. */
+static inline lpae_t mfn_to_xen_entry(unsigned long mfn)
+{
+    paddr_t pa = ((paddr_t) mfn) << PAGE_SHIFT;
+    lpae_t e = (lpae_t) {
+        .pt = {
+            .xn = 1,              /* No need to execute outside .text */
+            .ng = 1,              /* Makes TLB flushes easier */
+            .af = 1,              /* No need for access tracking */
+            .sh = LPAE_SH_OUTER,  /* Xen mappings are globally coherent */
+            .ns = 1,              /* Hyp mode is in the non-secure world */
+            .user = 1,            /* See below */
+            .ai = WRITEALLOC,
+            .table = 0,           /* Set to 1 for links and 4k maps */
+            .valid = 1,           /* Mappings are present */
+        }};;
+    /* Setting the User bit is strange, but the ATS1H[RW] instructions
+     * don't seem to work otherwise, and since we never run on Xen
+     * pagetables un User mode it's OK.  If this changes, remember
+     * to update the hard-coded values in head.S too */
+
+    ASSERT(!(pa & ~PAGE_MASK));
+    ASSERT(!(pa & ~PADDR_MASK));
+
+    // XXX shifts
+    e.bits |= pa;
+    return e;
+}
+
+static inline lpae_t mfn_to_p2m_entry(unsigned long mfn)
+{
+    paddr_t pa = ((paddr_t) mfn) << PAGE_SHIFT;
+    lpae_t e = (lpae_t) {
+        .p2m.xn = 0,
+        .p2m.af = 1,
+        .p2m.sh = LPAE_SH_OUTER,
+        .p2m.write = 1,
+        .p2m.read = 1,
+        .p2m.mattr = 0xf,
+        .p2m.table = 1,
+        .p2m.valid = 1,
+    };
+
+    ASSERT(!(pa & ~PAGE_MASK));
+    ASSERT(!(pa & ~PADDR_MASK));
+
+    e.bits |= pa;
+
+    return e;
+}
+
+/* Write a pagetable entry */
+static inline void write_pte(lpae_t *p, lpae_t pte)
+{
+    asm volatile (
+        /* Safely write the entry (STRD is atomic on CPUs that support LPAE) */
+        "strd %0, %H0, [%1];"
+        /* Push this cacheline to the PoC so the rest of the system sees it. */
+        STORE_CP32(1, DCCMVAC)
+        : : "r" (pte.bits), "r" (p) : "memory");
+}
+
+/*
+ * Flush all hypervisor mappings from the data TLB. This is not
+ * sufficient when changing code mappings or for self modifying code.
+ */
+static inline void flush_xen_data_tlb(void)
+{
+    register unsigned long r0 asm ("r0");
+    asm volatile("dsb;" /* Ensure preceding are visible */
+                 STORE_CP32(0, TLBIALLH)
+                 "dsb;" /* Ensure completion of the TLB flush */
+                 "isb;"
+                 : : "r" (r0) /* dummy */: "memory");
+}
+
+/*
+ * Flush one VA's hypervisor mappings from the data TLB. This is not
+ * sufficient when changing code mappings or for self modifying code.
+ */
+static inline void flush_xen_data_tlb_va(unsigned long va)
+{
+    asm volatile("dsb;" /* Ensure preceding are visible */
+                 STORE_CP32(0, TLBIMVAH)
+                 "dsb;" /* Ensure completion of the TLB flush */
+                 "isb;"
+                 : : "r" (va) : "memory");
+}
+
+/* Flush all non-hypervisor mappings from the TLB */
+static inline void flush_guest_tlb(void)
+{
+    register unsigned long r0 asm ("r0");
+    WRITE_CP32(r0 /* dummy */, TLBIALLNSNH);
+}
+
+/* Ask the MMU to translate a VA for us */
+static inline uint64_t __va_to_par(uint32_t va)
+{
+    uint64_t par, tmp;
+    tmp = READ_CP64(PAR);
+    WRITE_CP32(va, ATS1HR);
+    isb(); /* Ensure result is available. */
+    par = READ_CP64(PAR);
+    WRITE_CP64(tmp, PAR);
+    return par;
+}
+
+static inline uint64_t va_to_par(uint32_t va)
+{
+    uint64_t par = __va_to_par(va);
+    /* It is not OK to call this with an invalid VA */
+    if ( par & PAR_F ) panic_PAR(par, "Hypervisor");
+    return par;
+}
+
+/* Ask the MMU to translate a Guest VA for us */
+static inline uint64_t __gva_to_par(uint32_t va)
+{
+    uint64_t par, tmp;
+    tmp = READ_CP64(PAR);
+    WRITE_CP32(va, ATS12NSOPR);
+    isb(); /* Ensure result is available. */
+    par = READ_CP64(PAR);
+    WRITE_CP64(tmp, PAR);
+    return par;
+}
+static inline uint64_t gva_to_par(uint32_t va)
+{
+    uint64_t par = __gva_to_par(va);
+    /* It is not OK to call this with an invalid VA */
+    /* XXX harsh for a guest address... */
+    if ( par & PAR_F ) panic_PAR(par, "Guest");
+    return par;
+}
+static inline uint64_t __gva_to_ipa(uint32_t va)
+{
+    uint64_t par, tmp;
+    tmp = READ_CP64(PAR);
+    WRITE_CP32(va, ATS1CPR);
+    isb(); /* Ensure result is available. */
+    par = READ_CP64(PAR);
+    WRITE_CP64(tmp, PAR);
+    return par;
+}
+static inline uint64_t gva_to_ipa(uint32_t va)
+{
+    uint64_t par = __gva_to_ipa(va);
+    /* It is not OK to call this with an invalid VA */
+    /* XXX harsh for a guest address... */
+    if ( par & PAR_F ) panic_PAR(par, "Guest");
+    return (par & PADDR_MASK & PAGE_MASK) | ((unsigned long) va & ~PAGE_MASK);
+}
+/* Bits in the PAR returned by va_to_par */
+#define PAR_FAULT 0x1
+
+#endif /* __ASSEMBLY__ */
+
+/* These numbers add up to a 39-bit input address space.  The  ARMv7-A
+ * architecture actually specifies a 40-bit input address space for the p2m,
+ * with an 8K (1024-entry) top-level table. */
+
+#define LPAE_SHIFT      9
+#define LPAE_ENTRIES    (1u << LPAE_SHIFT)
+#define LPAE_ENTRY_MASK (LPAE_ENTRIES - 1)
+
+#define THIRD_SHIFT  PAGE_SHIFT
+#define SECOND_SHIFT (THIRD_SHIFT + LPAE_SHIFT)
+#define FIRST_SHIFT  (SECOND_SHIFT + LPAE_SHIFT)
+
+/* Calculate the offsets into the pagetables for a given VA */
+#define first_linear_offset(va) (va >> FIRST_SHIFT)
+#define second_linear_offset(va) (va >> SECOND_SHIFT)
+#define third_linear_offset(va) (va >> THIRD_SHIFT)
+#define first_table_offset(va) (first_linear_offset(va))
+#define second_table_offset(va) (second_linear_offset(va) & LPAE_ENTRY_MASK)
+#define third_table_offset(va) (third_linear_offset(va) & LPAE_ENTRY_MASK)
+
+#define clear_page(page)memset((void *)(page), 0, PAGE_SIZE)
+
+#define PAGE_ALIGN(x) (((x) + PAGE_SIZE - 1) & PAGE_MASK)
+
+#endif /* __ARM_PAGE_H__ */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 18:20:50 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 18:20:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXzdH-0008Fv-OM; Tue, 06 Dec 2011 18:20:47 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RXzdF-000892-QY
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 18:20:46 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1323195597!1577792!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDcxMjI=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9799 invoked from network); 6 Dec 2011 18:19:58 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Dec 2011 18:19:58 -0000
X-IronPort-AV: E=Sophos;i="4.71,307,1320642000"; d="scan'208";a="19721951"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Dec 2011 13:19:56 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Tue, 6 Dec 2011 13:19:56 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pB6IJEjS019549;
	Tue, 6 Dec 2011 10:19:39 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Tue, 6 Dec 2011 18:20:02 +0000
Message-ID: <1323195609-17277-18-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1112061753410.31179@kaball-desktop>
References: <alpine.DEB.2.00.1112061753410.31179@kaball-desktop>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>, Tim.Deegan@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH RFC 18/25] arm: mm and p2m
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Functions to setup pagetables, handle the p2m, map and unmap domain
pages, copy data to/from guest addresses.
The implementation is based on the LPAE extension for ARMv7 and makes
use of the two level transtion mechanism.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
---
 xen/arch/arm/Makefile              |    3 +
 xen/arch/arm/domain.c              |    4 +
 xen/arch/arm/mm.c                  |  321 ++++++++++++++++++++++++++++++++++
 xen/arch/arm/p2m.c                 |  214 +++++++++++++++++++++++
 xen/arch/arm/usercopy.c            |   81 +++++++++
 xen/include/asm-arm/domain.h       |    2 +
 xen/include/asm-arm/guest_access.h |  125 +++++++++++++
 xen/include/asm-arm/mm.h           |  315 +++++++++++++++++++++++++++++++++
 xen/include/asm-arm/p2m.h          |   88 ++++++++++
 xen/include/asm-arm/page.h         |  335 ++++++++++++++++++++++++++++++++++++
 10 files changed, 1488 insertions(+), 0 deletions(-)
 create mode 100644 xen/arch/arm/mm.c
 create mode 100644 xen/arch/arm/p2m.c
 create mode 100644 xen/arch/arm/usercopy.c
 create mode 100644 xen/include/asm-arm/guest_access.h
 create mode 100644 xen/include/asm-arm/mm.h
 create mode 100644 xen/include/asm-arm/p2m.h
 create mode 100644 xen/include/asm-arm/page.h

diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index 5593d2b..fb8f4ee 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -7,6 +7,9 @@ obj-y += domain_build.o
 obj-y += gic.o
 obj-y += io.o
 obj-y += irq.o
+obj-y += mm.o
+obj-y += p2m.o
+obj-y += usercopy.o
 
 #obj-bin-y += ....o
 
diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index ecbc5b7..0844b37 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -224,6 +224,10 @@ int arch_domain_create(struct domain *d, unsigned int domcr_flags)
 {
     int rc;
 
+    rc = -ENOMEM;
+    if ( (rc = p2m_init(d)) != 0 )
+        goto fail;
+
     d->max_vcpus = 8;
 
     rc = 0;
diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
new file mode 100644
index 0000000..613d084
--- /dev/null
+++ b/xen/arch/arm/mm.c
@@ -0,0 +1,321 @@
+/*
+ * xen/arch/arm/mm.c
+ *
+ * MMU code for an ARMv7-A with virt extensions.
+ *
+ * Tim Deegan <tim@xen.org>
+ * Copyright (c) 2011 Citrix Systems.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include <xen/config.h>
+#include <xen/compile.h>
+#include <xen/types.h>
+#include <xen/init.h>
+#include <xen/mm.h>
+#include <xen/preempt.h>
+#include <asm/page.h>
+#include <asm/current.h>
+
+struct domain *dom_xen, *dom_io;
+
+/* Static start-of-day pagetables that we use before the allocators are up */
+lpae_t xen_pgtable[LPAE_ENTRIES] __attribute__((__aligned__(4096)));
+lpae_t xen_second[LPAE_ENTRIES*4] __attribute__((__aligned__(4096*4)));
+static lpae_t xen_fixmap[LPAE_ENTRIES] __attribute__((__aligned__(4096)));
+static lpae_t xen_xenmap[LPAE_ENTRIES] __attribute__((__aligned__(4096)));
+
+/* Limits of the Xen heap */
+unsigned long xenheap_mfn_start, xenheap_mfn_end;
+unsigned long xenheap_virt_end;
+
+unsigned long frametable_virt_end;
+
+/* Map a 4k page in a fixmap entry */
+void set_fixmap(unsigned map, unsigned long mfn, unsigned attributes)
+{
+    lpae_t pte = mfn_to_xen_entry(mfn);
+    pte.pt.table = 1; /* 4k mappings always have this bit set */
+    pte.pt.ai = attributes;
+    write_pte(xen_fixmap + third_table_offset(FIXMAP_ADDR(map)), pte);
+    flush_xen_data_tlb_va(FIXMAP_ADDR(map));
+}
+
+/* Remove a mapping from a fixmap entry */
+void clear_fixmap(unsigned map)
+{
+    lpae_t pte = {0};
+    write_pte(xen_fixmap + third_table_offset(FIXMAP_ADDR(map)), pte);
+    flush_xen_data_tlb_va(FIXMAP_ADDR(map));
+}
+
+/* Map a page of domheap memory */
+void *map_domain_page(unsigned long mfn)
+{
+    unsigned long flags;
+    lpae_t *map = xen_second + second_linear_offset(DOMHEAP_VIRT_START);
+    unsigned long slot_mfn = mfn & ~LPAE_ENTRY_MASK;
+    uint32_t va;
+    lpae_t pte;
+    int i, slot;
+
+    local_irq_save(flags);
+
+    /* The map is laid out as an open-addressed hash table where each
+     * entry is a 2MB superpage pte.  We use the available bits of each
+     * PTE as a reference count; when the refcount is zero the slot can
+     * be reused. */
+    for ( slot = (slot_mfn >> LPAE_SHIFT) % DOMHEAP_ENTRIES, i = 0;
+          i < DOMHEAP_ENTRIES;
+          slot = (slot + 1) % DOMHEAP_ENTRIES, i++ )
+    {
+        if ( map[slot].pt.avail == 0 )
+        {
+            /* Commandeer this 2MB slot */
+            pte = mfn_to_xen_entry(slot_mfn);
+            pte.pt.avail = 1;
+            write_pte(map + slot, pte);
+            break;
+        }
+        else if ( map[slot].pt.avail < 0xf && map[slot].pt.base == slot_mfn )
+        {
+            /* This slot already points to the right place; reuse it */
+            map[slot].pt.avail++;
+            break;
+        }
+    }
+    /* If the map fills up, the callers have misbehaved. */
+    BUG_ON(i == DOMHEAP_ENTRIES);
+
+#ifndef NDEBUG
+    /* Searching the hash could get slow if the map starts filling up.
+     * Cross that bridge when we come to it */
+    {
+        static int max_tries = 32;
+        if ( i >= max_tries )
+        {
+            dprintk(XENLOG_WARNING, "Domheap map is filling: %i tries\n", i);
+            max_tries *= 2;
+        }
+    }
+#endif
+
+    local_irq_restore(flags);
+
+    va = (DOMHEAP_VIRT_START
+          + (slot << SECOND_SHIFT)
+          + ((mfn & LPAE_ENTRY_MASK) << THIRD_SHIFT));
+
+    /*
+     * We may not have flushed this specific subpage at map time,
+     * since we only flush the 4k page not the superpage
+     */
+    flush_xen_data_tlb_va(va);
+
+    return (void *)va;
+}
+
+/* Release a mapping taken with map_domain_page() */
+void unmap_domain_page(const void *va)
+{
+    unsigned long flags;
+    lpae_t *map = xen_second + second_linear_offset(DOMHEAP_VIRT_START);
+    int slot = ((unsigned long) va - DOMHEAP_VIRT_START) >> SECOND_SHIFT;
+
+    local_irq_save(flags);
+
+    ASSERT(slot >= 0 && slot < DOMHEAP_ENTRIES);
+    ASSERT(map[slot].pt.avail != 0);
+
+    map[slot].pt.avail--;
+
+    local_irq_restore(flags);
+}
+
+
+/* Boot-time pagetable setup.
+ * Changes here may need matching changes in head.S */
+void __init setup_pagetables(unsigned long boot_phys_offset)
+{
+    paddr_t xen_paddr, phys_offset;
+    unsigned long dest_va;
+    lpae_t pte, *p;
+    int i;
+
+    if ( boot_phys_offset != 0 )
+    {
+        /* Remove the old identity mapping of the boot paddr */
+        pte.bits = 0;
+        dest_va = (unsigned long)_start + boot_phys_offset;
+        write_pte(xen_second + second_linear_offset(dest_va), pte);
+    }
+
+    xen_paddr = XEN_PADDR;
+
+    /* Map the destination in the empty L2 above the fixmap */
+    dest_va = FIXMAP_ADDR(0) + (1u << SECOND_SHIFT);
+    pte = mfn_to_xen_entry(xen_paddr >> PAGE_SHIFT);
+    write_pte(xen_second + second_table_offset(dest_va), pte);
+
+    /* Calculate virt-to-phys offset for the new location */
+    phys_offset = xen_paddr - (unsigned long) _start;
+
+    /* Copy */
+    memcpy((void *) dest_va, _start, _end - _start);
+
+    /* Beware!  Any state we modify between now and the PT switch may be
+     * discarded when we switch over to the copy. */
+
+    /* Update the copy of xen_pgtable to use the new paddrs */
+    p = (void *) xen_pgtable + dest_va - (unsigned long) _start;
+    for ( i = 0; i < 4; i++)
+        p[i].pt.base += (phys_offset - boot_phys_offset) >> PAGE_SHIFT;
+    p = (void *) xen_second + dest_va - (unsigned long) _start;
+    for ( i = 0; i < 4 * LPAE_ENTRIES; i++)
+        if ( p[i].pt.valid )
+                p[i].pt.base += (phys_offset - boot_phys_offset) >> PAGE_SHIFT;
+
+    /* Change pagetables to the copy in the relocated Xen */
+    asm volatile (
+        STORE_CP64(0, HTTBR)          /* Change translation base */
+        "dsb;"                        /* Ensure visibility of HTTBR update */
+        STORE_CP32(0, TLBIALLH)       /* Flush hypervisor TLB */
+        STORE_CP32(0, BPIALL)         /* Flush branch predictor */
+        "dsb;"                        /* Ensure completion of TLB+BP flush */
+        "isb;"
+        : : "r" ((unsigned long) xen_pgtable + phys_offset) : "memory");
+
+    /* Undo the temporary map */
+    pte.bits = 0;
+    write_pte(xen_second + second_table_offset(dest_va), pte);
+    /*
+     * Have removed a mapping previously used for .text. Flush everything
+     * for safety.
+     */
+    asm volatile (
+        "dsb;"                        /* Ensure visibility of PTE write */
+        STORE_CP32(0, TLBIALLH)       /* Flush hypervisor TLB */
+        STORE_CP32(0, BPIALL)         /* Flush branch predictor */
+        "dsb;"                        /* Ensure completion of TLB+BP flush */
+        "isb;"
+        : : "r" (i /*dummy*/) : "memory");
+
+    /* Link in the fixmap pagetable */
+    pte = mfn_to_xen_entry((((unsigned long) xen_fixmap) + phys_offset)
+                           >> PAGE_SHIFT);
+    pte.pt.table = 1;
+    write_pte(xen_second + second_table_offset(FIXMAP_ADDR(0)), pte);
+    /*
+     * No flush required here. Individual flushes are done in
+     * set_fixmap as entries are used.
+     */
+
+    /* Break up the Xen mapping into 4k pages and protect them separately. */
+    for ( i = 0; i < LPAE_ENTRIES; i++ )
+    {
+        unsigned long mfn = paddr_to_pfn(xen_paddr) + i;
+        unsigned long va = XEN_VIRT_START + (i << PAGE_SHIFT);
+        if ( !is_kernel(va) )
+            break;
+        pte = mfn_to_xen_entry(mfn);
+        pte.pt.table = 1; /* 4k mappings always have this bit set */
+        if ( is_kernel_text(va) || is_kernel_inittext(va) )
+        {
+            pte.pt.xn = 0;
+            pte.pt.ro = 1;
+        }
+        if ( is_kernel_rodata(va) )
+            pte.pt.ro = 1;
+        write_pte(xen_xenmap + i, pte);
+        /* No flush required here as page table is not hooked in yet. */
+    }
+    pte = mfn_to_xen_entry((((unsigned long) xen_xenmap) + phys_offset)
+                           >> PAGE_SHIFT);
+    pte.pt.table = 1;
+    write_pte(xen_second + second_linear_offset(XEN_VIRT_START), pte);
+    /* Have changed a mapping used for .text. Flush everything for safety. */
+    asm volatile (
+        "dsb;"                        /* Ensure visibility of PTE write */
+        STORE_CP32(0, TLBIALLH)       /* Flush hypervisor TLB */
+        STORE_CP32(0, BPIALL)         /* Flush branch predictor */
+        "dsb;"                        /* Ensure completion of TLB+BP flush */
+        "isb;"
+        : : "r" (i /*dummy*/) : "memory");
+
+    /* From now on, no mapping may be both writable and executable. */
+    WRITE_CP32(READ_CP32(HSCTLR) | SCTLR_WXN, HSCTLR);
+}
+
+/* Create Xen's mappings of memory.
+ * Base and virt must be 32MB aligned and size a multiple of 32MB. */
+static void __init create_mappings(unsigned long virt,
+                                   unsigned long base_mfn,
+                                   unsigned long nr_mfns)
+{
+    unsigned long i, count;
+    lpae_t pte, *p;
+
+    ASSERT(!((virt >> PAGE_SHIFT) % (16 * LPAE_ENTRIES)));
+    ASSERT(!(base_mfn % (16 * LPAE_ENTRIES)));
+    ASSERT(!(nr_mfns % (16 * LPAE_ENTRIES)));
+
+    count = nr_mfns / LPAE_ENTRIES;
+    p = xen_second + second_linear_offset(virt);
+    pte = mfn_to_xen_entry(base_mfn);
+    pte.pt.hint = 1;  /* These maps are in 16-entry contiguous chunks. */
+    for ( i = 0; i < count; i++ )
+    {
+        write_pte(p + i, pte);
+        pte.pt.base += 1 << LPAE_SHIFT;
+    }
+    flush_xen_data_tlb();
+}
+
+/* Set up the xenheap: up to 1GB of contiguous, always-mapped memory. */
+void __init setup_xenheap_mappings(unsigned long base_mfn,
+                                   unsigned long nr_mfns)
+{
+    create_mappings(XENHEAP_VIRT_START, base_mfn, nr_mfns);
+
+    /* Record where the xenheap is, for translation routines. */
+    xenheap_virt_end = XENHEAP_VIRT_START + nr_mfns * PAGE_SIZE;
+    xenheap_mfn_start = base_mfn;
+    xenheap_mfn_end = base_mfn + nr_mfns;
+}
+
+/* Map a frame table to cover physical addresses ps through pe */
+void __init setup_frametable_mappings(paddr_t ps, paddr_t pe)
+{
+    unsigned long nr_pages = (pe - ps) >> PAGE_SHIFT;
+    unsigned long frametable_size = nr_pages * sizeof(struct page_info);
+    unsigned long base_mfn;
+
+    /* Round up to 32M boundary */
+    frametable_size = (frametable_size + 0x1ffffff) & ~0x1ffffff;
+    base_mfn = alloc_boot_pages(frametable_size >> PAGE_SHIFT, 5);
+    create_mappings(FRAMETABLE_VIRT_START, base_mfn, frametable_size >> PAGE_SHIFT);
+
+    memset(&frame_table[0], 0, nr_pages * sizeof(struct page_info));
+    memset(&frame_table[nr_pages], -1,
+           frametable_size - (nr_pages * sizeof(struct page_info)));
+
+    frametable_virt_end = FRAMETABLE_VIRT_START + (nr_pages * sizeof(struct page_info));
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
new file mode 100644
index 0000000..a1d026d
--- /dev/null
+++ b/xen/arch/arm/p2m.c
@@ -0,0 +1,214 @@
+#include <xen/config.h>
+#include <xen/sched.h>
+#include <xen/lib.h>
+#include <xen/errno.h>
+#include <xen/domain_page.h>
+
+void p2m_load_VTTBR(struct domain *d)
+{
+    struct p2m_domain *p2m = &d->arch.p2m;
+    paddr_t maddr = page_to_maddr(p2m->first_level);
+    uint64_t vttbr = maddr;
+
+    vttbr |= ((uint64_t)p2m->vmid&0xff)<<48;
+
+    printk("VTTBR dom%d = %"PRIx64"\n", d->domain_id, vttbr);
+
+    WRITE_CP64(vttbr, VTTBR);
+    isb(); /* Ensure update is visible */
+}
+
+static int p2m_create_entry(struct domain *d,
+                            lpae_t *entry)
+{
+    struct p2m_domain *p2m = &d->arch.p2m;
+    struct page_info *page;
+    void *p;
+    lpae_t pte;
+
+    BUG_ON(entry->p2m.valid);
+
+    page = alloc_domheap_page(d, 0);
+    if ( page == NULL )
+        return -ENOMEM;
+
+    page_list_add(page, &p2m->pages);
+
+    p = __map_domain_page(page);
+    clear_page(p);
+    unmap_domain_page(p);
+
+    pte = mfn_to_p2m_entry(page_to_mfn(page));
+
+    write_pte(entry, pte);
+
+    return 0;
+}
+
+static int create_p2m_entries(struct domain *d,
+                     int alloc,
+                     paddr_t start_gpaddr,
+                     paddr_t end_gpaddr,
+                     paddr_t maddr)
+{
+    int rc;
+    struct p2m_domain *p2m = &d->arch.p2m;
+    lpae_t *first = NULL, *second = NULL, *third = NULL;
+    paddr_t addr;
+    unsigned long cur_first_offset = ~0, cur_second_offset = ~0;
+
+    /* XXX Don't actually handle 40 bit guest physical addresses */
+    BUG_ON(start_gpaddr & 0x8000000000ULL);
+    BUG_ON(end_gpaddr   & 0x8000000000ULL);
+
+    first = __map_domain_page(p2m->first_level);
+
+    for(addr = start_gpaddr; addr < end_gpaddr; addr += PAGE_SIZE)
+    {
+        if ( !first[first_table_offset(addr)].p2m.valid )
+        {
+            rc = p2m_create_entry(d, &first[first_table_offset(addr)]);
+            if ( rc < 0 ) {
+                printk("p2m_populate_ram: L1 failed\n");
+                goto out;
+            }
+        }
+
+        BUG_ON(!first[first_table_offset(addr)].p2m.valid);
+
+        if ( cur_first_offset != first_table_offset(addr) )
+        {
+            if (second) unmap_domain_page(second);
+            second = map_domain_page(first[first_table_offset(addr)].p2m.base);
+            cur_first_offset = first_table_offset(addr);
+        }
+        /* else: second already valid */
+
+        if ( !second[second_table_offset(addr)].p2m.valid )
+        {
+            rc = p2m_create_entry(d, &second[second_table_offset(addr)]);
+            if ( rc < 0 ) {
+                printk("p2m_populate_ram: L2 failed\n");
+                goto out;
+            }
+        }
+
+        BUG_ON(!second[second_table_offset(addr)].p2m.valid);
+
+        if ( cur_second_offset != second_table_offset(addr) )
+        {
+            /* map third level */
+            if (third) unmap_domain_page(third);
+            third = map_domain_page(second[second_table_offset(addr)].p2m.base);
+            cur_second_offset = second_table_offset(addr);
+        }
+        /* else: third already valid */
+
+        BUG_ON(third[third_table_offset(addr)].p2m.valid);
+
+        /* Allocate a new RAM page and attach */
+        if (alloc)
+        {
+            struct page_info *page;
+            lpae_t pte;
+
+            rc = -ENOMEM;
+            page = alloc_domheap_page(d, 0);
+            if ( page == NULL ) {
+                printk("p2m_populate_ram: failed to allocate page\n");
+                goto out;
+            }
+
+            pte = mfn_to_p2m_entry(page_to_mfn(page));
+
+            write_pte(&third[third_table_offset(addr)], pte);
+        } else {
+            lpae_t pte = mfn_to_p2m_entry(maddr >> PAGE_SHIFT);
+            write_pte(&third[third_table_offset(addr)], pte);
+            maddr += PAGE_SIZE;
+        }
+    }
+
+    rc = 0;
+
+out:
+    spin_lock(&p2m->lock);
+
+    if (third) unmap_domain_page(third);
+    if (second) unmap_domain_page(second);
+    if (first) unmap_domain_page(first);
+
+    spin_unlock(&p2m->lock);
+
+    return rc;
+}
+
+int p2m_populate_ram(struct domain *d,
+                     paddr_t start,
+                     paddr_t end)
+{
+    return create_p2m_entries(d, 1, start, end, 0);
+}
+
+int map_mmio_regions(struct domain *d,
+                     paddr_t start_gaddr,
+                     paddr_t end_gaddr,
+                     paddr_t maddr)
+{
+    return create_p2m_entries(d, 0, start_gaddr, end_gaddr, maddr);
+}
+
+int p2m_alloc_table(struct domain *d)
+{
+    struct p2m_domain *p2m = &d->arch.p2m;
+    struct page_info *page;
+    void *p;
+
+    /* First level P2M is 2 consecutive pages */
+    page = alloc_domheap_pages(d, 1, 0);
+    if ( page == NULL )
+        return -ENOMEM;
+
+    spin_lock(&p2m->lock);
+
+    page_list_add(page, &p2m->pages);
+
+    /* Clear both first level pages */
+    p = __map_domain_page(page);
+    clear_page(p);
+    unmap_domain_page(p);
+
+    p = __map_domain_page(page + 1);
+    clear_page(p);
+    unmap_domain_page(p);
+
+    p2m->first_level = page;
+
+    spin_unlock(&p2m->lock);
+
+    return 0;
+}
+
+int p2m_init(struct domain *d)
+{
+    struct p2m_domain *p2m = &d->arch.p2m;
+
+    spin_lock_init(&p2m->lock);
+    INIT_PAGE_LIST_HEAD(&p2m->pages);
+
+    /* XXX allocate properly */
+    /* Zero is reserved */
+    p2m->vmid = d->domain_id + 1;
+
+    p2m->first_level = NULL;
+
+    return 0;
+}
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/arch/arm/usercopy.c b/xen/arch/arm/usercopy.c
new file mode 100644
index 0000000..6f51e0f
--- /dev/null
+++ b/xen/arch/arm/usercopy.c
@@ -0,0 +1,81 @@
+#include <xen/config.h>
+#include <xen/lib.h>
+#include <xen/domain_page.h>
+
+#include <asm/mm.h>
+#include <asm/guest_access.h>
+
+unsigned long copy_to_user(void __user *to, const void *from, unsigned len)
+{
+    /* XXX needs to handle faults */
+    unsigned offset = ((unsigned long)to & ~PAGE_MASK);
+
+    while ( len )
+    {
+        paddr_t g = gvirt_to_maddr((uint32_t) to);
+        void *p = map_domain_page(g>>PAGE_SHIFT);
+        unsigned size = min(len, (unsigned)PAGE_SIZE - offset);
+
+        p += offset;
+        memcpy(p, from, size);
+
+        unmap_domain_page(p - offset);
+        len -= size;
+        from += size;
+        to += size;
+        offset = 0;
+    }
+
+    return 0;
+}
+
+unsigned long clear_user(void __user *to, unsigned len)
+{
+    /* XXX needs to handle faults */
+    unsigned offset = ((unsigned long)to & ~PAGE_MASK);
+
+    while ( len )
+    {
+        paddr_t g = gvirt_to_maddr((uint32_t) to);
+        void *p = map_domain_page(g>>PAGE_SHIFT);
+        unsigned size = min(len, (unsigned)PAGE_SIZE - offset);
+
+        p += offset;
+        memset(p, 0x00, size);
+
+        unmap_domain_page(p - offset);
+        len -= size;
+        to += size;
+        offset = 0;
+    }
+
+    return 0;
+}
+
+unsigned long copy_from_user(void *to, const void __user *from, unsigned len)
+{
+    while ( len )
+    {
+        paddr_t g = gvirt_to_maddr((uint32_t) from & PAGE_MASK);
+        void *p = map_domain_page(g>>PAGE_SHIFT);
+        unsigned size = min(len, (unsigned)(PAGE_SIZE - ((unsigned)from & (~PAGE_MASK))));
+
+        p += ((unsigned long)from & (~PAGE_MASK));
+
+        memcpy(to, p, size);
+
+        unmap_domain_page(p);
+        len -= size;
+        from += size;
+        to += size;
+    }
+    return 0;
+}
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
index c226bdf..2226a24 100644
--- a/xen/include/asm-arm/domain.h
+++ b/xen/include/asm-arm/domain.h
@@ -16,6 +16,8 @@ struct pending_irq
 
 struct arch_domain
 {
+    struct p2m_domain p2m;
+
 }  __cacheline_aligned;
 
 struct arch_vcpu
diff --git a/xen/include/asm-arm/guest_access.h b/xen/include/asm-arm/guest_access.h
new file mode 100644
index 0000000..b8d4e63
--- /dev/null
+++ b/xen/include/asm-arm/guest_access.h
@@ -0,0 +1,125 @@
+#ifndef __ASM_ARM_GUEST_ACCESS_H__
+#define __ASM_ARM_GUEST_ACCESS_H__
+
+#include <xen/errno.h>
+
+/* Guests have their own comlete address space */
+#define access_ok(addr,size) (1)
+
+#define array_access_ok(addr,count,size) \
+    (likely(count < (~0UL/size)) && access_ok(addr,count*size))
+
+unsigned long copy_to_user(void *to, const void *from, unsigned len);
+unsigned long copy_from_user(void *to, const void *from, unsigned len);
+unsigned long clear_user(void *to, unsigned len);
+
+/* Raw access functions: no type checking. */
+/* All accesses are HVM type in ARM */
+#define raw_copy_to_guest(dst, src, len)        \
+    copy_to_user((dst), (src), (len))
+#define raw_copy_from_guest(dst, src, len)      \
+    copy_from_user((dst), (src), (len))
+#define __raw_copy_to_guest(dst, src, len)      \
+    copy_to_user((dst), (src), (len))
+#define __raw_copy_from_guest(dst, src, len)    \
+    copy_from_user((dst), (src), (len))
+
+/* Remainder copied from x86 -- could be common? */
+
+/* Is the guest handle a NULL reference? */
+#define guest_handle_is_null(hnd)        ((hnd).p == NULL)
+
+/* Offset the given guest handle into the array it refers to. */
+#define guest_handle_add_offset(hnd, nr) ((hnd).p += (nr))
+#define guest_handle_subtract_offset(hnd, nr) ((hnd).p -= (nr))
+
+/* Cast a guest handle to the specified type of handle. */
+#define guest_handle_cast(hnd, type) ({         \
+    type *_x = (hnd).p;                         \
+    (XEN_GUEST_HANDLE(type)) { _x };            \
+})
+
+#define guest_handle_from_ptr(ptr, type)        \
+    ((XEN_GUEST_HANDLE(type)) { (type *)ptr })
+#define const_guest_handle_from_ptr(ptr, type)  \
+    ((XEN_GUEST_HANDLE(const_##type)) { (const type *)ptr })
+
+/*
+ * Copy an array of objects to guest context via a guest handle,
+ * specifying an offset into the guest array.
+ */
+#define copy_to_guest_offset(hnd, off, ptr, nr) ({      \
+    const typeof(*(ptr)) *_s = (ptr);                   \
+    char (*_d)[sizeof(*_s)] = (void *)(hnd).p;          \
+    ((void)((hnd).p == (ptr)));                         \
+    raw_copy_to_guest(_d+(off), _s, sizeof(*_s)*(nr));  \
+})
+
+/*
+ * Copy an array of objects from guest context via a guest handle,
+ * specifying an offset into the guest array.
+ */
+#define copy_from_guest_offset(ptr, hnd, off, nr) ({    \
+    const typeof(*(ptr)) *_s = (hnd).p;                 \
+    typeof(*(ptr)) *_d = (ptr);                         \
+    raw_copy_from_guest(_d, _s+(off), sizeof(*_d)*(nr));\
+})
+
+/* Copy sub-field of a structure to guest context via a guest handle. */
+#define copy_field_to_guest(hnd, ptr, field) ({         \
+    const typeof(&(ptr)->field) _s = &(ptr)->field;     \
+    void *_d = &(hnd).p->field;                         \
+    ((void)(&(hnd).p->field == &(ptr)->field));         \
+    raw_copy_to_guest(_d, _s, sizeof(*_s));             \
+})
+
+/* Copy sub-field of a structure from guest context via a guest handle. */
+#define copy_field_from_guest(ptr, hnd, field) ({       \
+    const typeof(&(ptr)->field) _s = &(hnd).p->field;   \
+    typeof(&(ptr)->field) _d = &(ptr)->field;           \
+    raw_copy_from_guest(_d, _s, sizeof(*_d));           \
+})
+
+/*
+ * Pre-validate a guest handle.
+ * Allows use of faster __copy_* functions.
+ */
+/* All ARM guests are paging mode external and hence safe */
+#define guest_handle_okay(hnd, nr) (1)
+#define guest_handle_subrange_okay(hnd, first, last) (1)
+
+#define __copy_to_guest_offset(hnd, off, ptr, nr) ({    \
+    const typeof(*(ptr)) *_s = (ptr);                   \
+    char (*_d)[sizeof(*_s)] = (void *)(hnd).p;          \
+    ((void)((hnd).p == (ptr)));                         \
+    __raw_copy_to_guest(_d+(off), _s, sizeof(*_s)*(nr));\
+})
+
+#define __copy_from_guest_offset(ptr, hnd, off, nr) ({  \
+    const typeof(*(ptr)) *_s = (hnd).p;                 \
+    typeof(*(ptr)) *_d = (ptr);                         \
+    __raw_copy_from_guest(_d, _s+(off), sizeof(*_d)*(nr));\
+})
+
+#define __copy_field_to_guest(hnd, ptr, field) ({       \
+    const typeof(&(ptr)->field) _s = &(ptr)->field;     \
+    void *_d = &(hnd).p->field;                         \
+    ((void)(&(hnd).p->field == &(ptr)->field));         \
+    __raw_copy_to_guest(_d, _s, sizeof(*_s));           \
+})
+
+#define __copy_field_from_guest(ptr, hnd, field) ({     \
+    const typeof(&(ptr)->field) _s = &(hnd).p->field;   \
+    typeof(&(ptr)->field) _d = &(ptr)->field;           \
+    __raw_copy_from_guest(_d, _s, sizeof(*_d));         \
+})
+
+#endif /* __ASM_ARM_GUEST_ACCESS_H__ */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/mm.h b/xen/include/asm-arm/mm.h
new file mode 100644
index 0000000..ead6e0c
--- /dev/null
+++ b/xen/include/asm-arm/mm.h
@@ -0,0 +1,315 @@
+#ifndef __ARCH_ARM_MM__
+#define __ARCH_ARM_MM__
+
+#include <xen/config.h>
+#include <xen/kernel.h>
+#include <asm/page.h>
+#include <public/xen.h>
+
+/* Find a suitable place at the top of memory for Xen to live */
+/* XXX For now, use the top of the VE's 4GB RAM, at a 40-bit alias */
+#define XEN_PADDR 0x80ffe00000ull
+
+/*
+ * Per-page-frame information.
+ *
+ * Every architecture must ensure the following:
+ *  1. 'struct page_info' contains a 'struct page_list_entry list'.
+ *  2. Provide a PFN_ORDER() macro for accessing the order of a free page.
+ */
+#define PFN_ORDER(_pfn) ((_pfn)->v.free.order)
+
+struct page_info
+{
+    /* Each frame can be threaded onto a doubly-linked list. */
+    struct page_list_entry list;
+
+    /* Reference count and various PGC_xxx flags and fields. */
+    unsigned long count_info;
+
+    /* Context-dependent fields follow... */
+    union {
+        /* Page is in use: ((count_info & PGC_count_mask) != 0). */
+        struct {
+            /* Type reference count and various PGT_xxx flags and fields. */
+            unsigned long type_info;
+        } inuse;
+        /* Page is on a free list: ((count_info & PGC_count_mask) == 0). */
+        struct {
+            /* Do TLBs need flushing for safety before next page use? */
+            bool_t need_tlbflush;
+        } free;
+
+    } u;
+
+    union {
+        /* Page is in use, but not as a shadow. */
+        struct {
+            /* Owner of this page (zero if page is anonymous). */
+            struct domain *domain;
+        } inuse;
+
+        /* Page is on a free list. */
+        struct {
+            /* Order-size of the free chunk this page is the head of. */
+            unsigned int order;
+        } free;
+
+    } v;
+
+    union {
+        /*
+         * Timestamp from 'TLB clock', used to avoid extra safety flushes.
+         * Only valid for: a) free pages, and b) pages with zero type count
+         */
+        u32 tlbflush_timestamp;
+    };
+    u64 pad;
+};
+
+#define PG_shift(idx)   (BITS_PER_LONG - (idx))
+#define PG_mask(x, idx) (x ## UL << PG_shift(idx))
+
+#define PGT_none          PG_mask(0, 4)  /* no special uses of this page   */
+#define PGT_writable_page PG_mask(7, 4)  /* has writable mappings?         */
+#define PGT_shared_page   PG_mask(8, 4)  /* CoW sharable page              */
+#define PGT_type_mask     PG_mask(15, 4) /* Bits 28-31 or 60-63.           */
+
+ /* Owning guest has pinned this page to its current type? */
+#define _PGT_pinned       PG_shift(5)
+#define PGT_pinned        PG_mask(1, 5)
+
+ /* Count of uses of this frame as its current type. */
+#define PGT_count_width   PG_shift(9)
+#define PGT_count_mask    ((1UL<<PGT_count_width)-1)
+
+ /* Cleared when the owning guest 'frees' this page. */
+#define _PGC_allocated    PG_shift(1)
+#define PGC_allocated     PG_mask(1, 1)
+  /* Page is Xen heap? */
+#define _PGC_xen_heap     PG_shift(2)
+#define PGC_xen_heap      PG_mask(1, 2)
+/* ... */
+/* Page is broken? */
+#define _PGC_broken       PG_shift(7)
+#define PGC_broken        PG_mask(1, 7)
+ /* Mutually-exclusive page states: { inuse, offlining, offlined, free }. */
+#define PGC_state         PG_mask(3, 9)
+#define PGC_state_inuse   PG_mask(0, 9)
+#define PGC_state_offlining PG_mask(1, 9)
+#define PGC_state_offlined PG_mask(2, 9)
+#define PGC_state_free    PG_mask(3, 9)
+#define page_state_is(pg, st) (((pg)->count_info&PGC_state) == PGC_state_##st)
+
+/* Count of references to this frame. */
+#define PGC_count_width   PG_shift(9)
+#define PGC_count_mask    ((1UL<<PGC_count_width)-1)
+
+extern unsigned long xenheap_mfn_start, xenheap_mfn_end;
+extern unsigned long xenheap_virt_end;
+
+#define is_xen_heap_page(page) is_xen_heap_mfn(page_to_mfn(page))
+#define is_xen_heap_mfn(mfn) ({                                 \
+    unsigned long _mfn = (mfn);                                 \
+    (_mfn >= xenheap_mfn_start && _mfn < xenheap_mfn_end);      \
+})
+#define is_xen_fixed_mfn(mfn) is_xen_heap_mfn(mfn)
+
+#define page_get_owner(_p)    (_p)->v.inuse.domain
+#define page_set_owner(_p,_d) ((_p)->v.inuse.domain = (_d))
+
+#define maddr_get_owner(ma)   (page_get_owner(maddr_to_page((ma))))
+#define vaddr_get_owner(va)   (page_get_owner(virt_to_page((va))))
+
+#define XENSHARE_writable 0
+#define XENSHARE_readonly 1
+extern void share_xen_page_with_guest(
+    struct page_info *page, struct domain *d, int readonly);
+extern void share_xen_page_with_privileged_guests(
+    struct page_info *page, int readonly);
+
+#define frame_table ((struct page_info *)FRAMETABLE_VIRT_START)
+
+extern unsigned long max_page;
+extern unsigned long total_pages;
+
+/* Boot-time pagetable setup */
+extern void setup_pagetables(unsigned long boot_phys_offset);
+/* Set up the xenheap: up to 1GB of contiguous, always-mapped memory.
+ * Base must be 32MB aligned and size a multiple of 32MB. */
+extern void setup_xenheap_mappings(unsigned long base_mfn, unsigned long nr_mfns);
+/* Map a frame table to cover physical addresses ps through pe */
+extern void setup_frametable_mappings(paddr_t ps, paddr_t pe);
+/* Map a 4k page in a fixmap entry */
+extern void set_fixmap(unsigned map, unsigned long mfn, unsigned attributes);
+/* Remove a mapping from a fixmap entry */
+extern void clear_fixmap(unsigned map);
+
+
+#define mfn_valid(mfn)        ({                                              \
+    unsigned long __m_f_n = (mfn);                                            \
+    likely(__m_f_n < max_page);                                               \
+})
+
+#define max_pdx                 max_page
+/* XXX Assume everything in the 40-bit physical alias 0x8000000000 for now */
+#define pfn_to_pdx(pfn)         ((pfn) - 0x8000000UL)
+#define pdx_to_pfn(pdx)         ((pdx) + 0x8000000UL)
+#define virt_to_pdx(va)         virt_to_mfn(va)
+#define pdx_to_virt(pdx)        mfn_to_virt(pdx)
+
+/* Convert between machine frame numbers and page-info structures. */
+#define mfn_to_page(mfn)  (frame_table + pfn_to_pdx(mfn))
+#define page_to_mfn(pg)   pdx_to_pfn((unsigned long)((pg) - frame_table))
+#define __page_to_mfn(pg)  page_to_mfn(pg)
+#define __mfn_to_page(mfn) mfn_to_page(mfn)
+
+/* Convert between machine addresses and page-info structures. */
+#define maddr_to_page(ma) __mfn_to_page((ma) >> PAGE_SHIFT)
+#define page_to_maddr(pg) ((paddr_t)__page_to_mfn(pg) << PAGE_SHIFT)
+
+/* Convert between frame number and address formats.  */
+#define pfn_to_paddr(pfn) ((paddr_t)(pfn) << PAGE_SHIFT)
+#define paddr_to_pfn(pa)  ((unsigned long)((pa) >> PAGE_SHIFT))
+#define paddr_to_pdx(pa)    pfn_to_pdx(paddr_to_pfn(pa))
+
+
+static inline paddr_t virt_to_maddr(void *va)
+{
+    uint64_t par = va_to_par((uint32_t)va);
+    return (par & PADDR_MASK & PAGE_MASK) | ((unsigned long) va & ~PAGE_MASK);
+}
+
+static inline void *maddr_to_virt(paddr_t ma)
+{
+    ASSERT(is_xen_heap_mfn(ma >> PAGE_SHIFT));
+    ma -= pfn_to_paddr(xenheap_mfn_start);
+    return (void *)(unsigned long) ma + XENHEAP_VIRT_START;
+}
+
+static inline paddr_t gvirt_to_maddr(uint32_t va)
+{
+    uint64_t par = gva_to_par(va);
+    return (par & PADDR_MASK & PAGE_MASK) | ((unsigned long) va & ~PAGE_MASK);
+}
+
+/* Convert between Xen-heap virtual addresses and machine addresses. */
+#define __pa(x)             (virt_to_maddr(x))
+#define __va(x)             (maddr_to_virt(x))
+
+/* Convert between Xen-heap virtual addresses and machine frame numbers. */
+#define virt_to_mfn(va)   (virt_to_maddr(va) >> PAGE_SHIFT)
+#define mfn_to_virt(mfn)  (maddr_to_virt((paddr_t)(mfn) << PAGE_SHIFT))
+
+
+static inline int get_order_from_bytes(paddr_t size)
+{
+    int order;
+    size = (size-1) >> PAGE_SHIFT;
+    for ( order = 0; size; order++ )
+        size >>= 1;
+    return order;
+}
+
+static inline int get_order_from_pages(unsigned long nr_pages)
+{
+    int order;
+    nr_pages--;
+    for ( order = 0; nr_pages; order++ )
+        nr_pages >>= 1;
+    return order;
+}
+
+
+/* Convert between Xen-heap virtual addresses and page-info structures. */
+static inline struct page_info *virt_to_page(const void *v)
+{
+    unsigned long va = (unsigned long)v;
+    ASSERT(va >= XENHEAP_VIRT_START);
+    ASSERT(va < xenheap_virt_end);
+
+    return frame_table + ((va - XENHEAP_VIRT_START) >> PAGE_SHIFT);
+}
+
+static inline void *page_to_virt(const struct page_info *pg)
+{
+    ASSERT((unsigned long)pg - FRAMETABLE_VIRT_START < frametable_virt_end);
+    return (void *)(XENHEAP_VIRT_START +
+                    ((unsigned long)pg - FRAMETABLE_VIRT_START) /
+                    (sizeof(*pg) / (sizeof(*pg) & -sizeof(*pg))) *
+                    (PAGE_SIZE / (sizeof(*pg) & -sizeof(*pg))));
+
+}
+
+struct domain *page_get_owner_and_reference(struct page_info *page);
+void put_page(struct page_info *page);
+int  get_page(struct page_info *page, struct domain *domain);
+
+/*
+ * The MPT (machine->physical mapping table) is an array of word-sized
+ * values, indexed on machine frame number. It is expected that guest OSes
+ * will use it to store a "physical" frame number to give the appearance of
+ * contiguous (or near contiguous) physical memory.
+ */
+#undef  machine_to_phys_mapping
+#define machine_to_phys_mapping  ((unsigned long *)RDWR_MPT_VIRT_START)
+#define INVALID_M2P_ENTRY        (~0UL)
+#define VALID_M2P(_e)            (!((_e) & (1UL<<(BITS_PER_LONG-1))))
+#define SHARED_M2P_ENTRY         (~0UL - 1UL)
+#define SHARED_M2P(_e)           ((_e) == SHARED_M2P_ENTRY)
+
+#define _set_gpfn_from_mfn(mfn, pfn) ({                        \
+    struct domain *d = page_get_owner(__mfn_to_page(mfn));     \
+    if(d && (d == dom_cow))                                    \
+        machine_to_phys_mapping[(mfn)] = SHARED_M2P_ENTRY;     \
+    else                                                       \
+        machine_to_phys_mapping[(mfn)] = (pfn);                \
+    })
+
+#define put_gfn(d, g)   ((void)0)
+
+#define INVALID_MFN             (~0UL)
+
+/* Xen always owns P2M on ARM */
+#define set_gpfn_from_mfn(mfn, pfn) do { (void) (mfn),(pfn); } while (0)
+#define mfn_to_gmfn(_d, mfn)  (mfn)
+
+
+/* Arch-specific portion of memory_op hypercall. */
+long arch_memory_op(int op, XEN_GUEST_HANDLE(void) arg);
+
+int steal_page(
+    struct domain *d, struct page_info *page, unsigned int memflags);
+int donate_page(
+    struct domain *d, struct page_info *page, unsigned int memflags);
+
+#define domain_set_alloc_bitsize(d) ((void)0)
+#define domain_clamp_alloc_bitsize(d, b) (b)
+
+unsigned long domain_get_maximum_gpfn(struct domain *d);
+
+extern struct domain *dom_xen, *dom_io, *dom_cow;
+
+#define memguard_init(_s)              (_s)
+#define memguard_guard_stack(_p)       ((void)0)
+#define memguard_guard_range(_p,_l)    ((void)0)
+#define memguard_unguard_range(_p,_l)  ((void)0)
+int guest_physmap_mark_populate_on_demand(struct domain *d, unsigned long gfn,
+                                          unsigned int order);
+
+extern void put_page_type(struct page_info *page);
+static inline void put_page_and_type(struct page_info *page)
+{
+    put_page_type(page);
+    put_page(page);
+}
+
+#endif /*  __ARCH_ARM_MM__ */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/p2m.h b/xen/include/asm-arm/p2m.h
new file mode 100644
index 0000000..aec52f7
--- /dev/null
+++ b/xen/include/asm-arm/p2m.h
@@ -0,0 +1,88 @@
+#ifndef _XEN_P2M_H
+#define _XEN_P2M_H
+
+#include <xen/mm.h>
+
+struct domain;
+
+/* Per-p2m-table state */
+struct p2m_domain {
+    /* Lock that protects updates to the p2m */
+    spinlock_t lock;
+
+    /* Pages used to construct the p2m */
+    struct page_list_head pages;
+
+    /* Root of p2m page tables, 2 contiguous pages */
+    struct page_info *first_level;
+
+    /* Current VMID in use */
+    uint8_t vmid;
+};
+
+/* Init the datastructures for later use by the p2m code */
+int p2m_init(struct domain *d);
+
+/* Allocate a new p2m table for a domain.
+ *
+ * Returns 0 for success or -errno.
+ */
+int p2m_alloc_table(struct domain *d);
+
+/* */
+void p2m_load_VTTBR(struct domain *d);
+
+/* Setup p2m RAM mapping for domain d from start-end. */
+int p2m_populate_ram(struct domain *d, paddr_t start, paddr_t end);
+/* Map MMIO regions in the p2m: start_gaddr and end_gaddr is the range
+ * in the guest physical address space to map, starting from the machine
+ * address maddr. */
+int map_mmio_regions(struct domain *d, paddr_t start_gaddr,
+                     paddr_t end_gaddr, paddr_t maddr);
+
+unsigned long gmfn_to_mfn(struct domain *d, unsigned long gpfn);
+
+/*
+ * Populate-on-demand
+ */
+
+/* Call when decreasing memory reservation to handle PoD entries properly.
+ * Will return '1' if all entries were handled and nothing more need be done.*/
+int
+p2m_pod_decrease_reservation(struct domain *d,
+                             xen_pfn_t gpfn,
+                             unsigned int order);
+
+/* Compatibility function exporting the old untyped interface */
+static inline unsigned long get_gfn_untyped(struct domain *d, unsigned long gpfn)
+{
+    return gmfn_to_mfn(d, gpfn);
+}
+
+int get_page_type(struct page_info *page, unsigned long type);
+int is_iomem_page(unsigned long mfn);
+static inline int get_page_and_type(struct page_info *page,
+                                    struct domain *domain,
+                                    unsigned long type)
+{
+    int rc = get_page(page, domain);
+
+    if ( likely(rc) && unlikely(!get_page_type(page, type)) )
+    {
+        put_page(page);
+        rc = 0;
+    }
+
+    return rc;
+}
+
+#endif /* _XEN_P2M_H */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/page.h b/xen/include/asm-arm/page.h
new file mode 100644
index 0000000..6dc1659
--- /dev/null
+++ b/xen/include/asm-arm/page.h
@@ -0,0 +1,335 @@
+#ifndef __ARM_PAGE_H__
+#define __ARM_PAGE_H__
+
+#include <xen/config.h>
+
+#define PADDR_BITS              40
+#define PADDR_MASK              ((1ULL << PADDR_BITS)-1)
+
+#define VADDR_BITS              32
+#define VADDR_MASK              (~0UL)
+
+/* Shareability values for the LPAE entries */
+#define LPAE_SH_NON_SHAREABLE 0x0
+#define LPAE_SH_UNPREDICTALE  0x1
+#define LPAE_SH_OUTER         0x2
+#define LPAE_SH_INNER         0x3
+
+/* LPAE Memory region attributes, to match Linux's (non-LPAE) choices.
+ * Indexed by the AttrIndex bits of a LPAE entry;
+ * the 8-bit fields are packed little-endian into MAIR0 and MAIR1
+ *
+ *                 ai    encoding
+ *   UNCACHED      000   0000 0000  -- Strongly Ordered
+ *   BUFFERABLE    001   0100 0100  -- Non-Cacheable
+ *   WRITETHROUGH  010   1010 1010  -- Write-through
+ *   WRITEBACK     011   1110 1110  -- Write-back
+ *   DEV_SHARED    100   0000 0100  -- Device
+ *   ??            101
+ *   reserved      110
+ *   WRITEALLOC    111   1111 1111  -- Write-back write-allocate
+ *
+ *   DEV_NONSHARED 100   (== DEV_SHARED)
+ *   DEV_WC        001   (== BUFFERABLE)
+ *   DEV_CACHED    011   (== WRITEBACK)
+ */
+#define MAIR0VAL 0xeeaa4400
+#define MAIR1VAL 0xff000004
+
+#define UNCACHED      0x0
+#define BUFFERABLE    0x1
+#define WRITETHROUGH  0x2
+#define WRITEBACK     0x3
+#define DEV_SHARED    0x4
+#define WRITEALLOC    0x7
+#define DEV_NONSHARED DEV_SHARED
+#define DEV_WC        BUFFERABLE
+#define DEV_CACHED    WRITEBACK
+
+
+#ifndef __ASSEMBLY__
+
+#include <xen/types.h>
+#include <xen/lib.h>
+
+/* WARNING!  Unlike the Intel pagetable code, where l1 is the lowest
+ * level and l4 is the root of the trie, the ARM pagetables follow ARM's
+ * documentation: the levels are called first, second &c in the order
+ * that the MMU walks them (i.e. "first" is the root of the trie). */
+
+/******************************************************************************
+ * ARMv7-A LPAE pagetables: 3-level trie, mapping 40-bit input to
+ * 40-bit output addresses.  Tables at all levels have 512 64-bit entries
+ * (i.e. are 4Kb long).
+ *
+ * The bit-shuffling that has the permission bits in branch nodes in a
+ * different place from those in leaf nodes seems to be to allow linear
+ * pagetable tricks.  If we're not doing that then the set of permission
+ * bits that's not in use in a given node type can be used as
+ * extra software-defined bits. */
+
+typedef struct {
+    /* These are used in all kinds of entry. */
+    unsigned long valid:1;      /* Valid mapping */
+    unsigned long table:1;      /* == 1 in 4k map entries too */
+
+    /* These ten bits are only used in Block entries and are ignored
+     * in Table entries. */
+    unsigned long ai:3;         /* Attribute Index */
+    unsigned long ns:1;         /* Not-Secure */
+    unsigned long user:1;       /* User-visible */
+    unsigned long ro:1;         /* Read-Only */
+    unsigned long sh:2;         /* Shareability */
+    unsigned long af:1;         /* Access Flag */
+    unsigned long ng:1;         /* Not-Global */
+
+    /* The base address must be approprately aligned for Block entries */
+    unsigned long base:28;      /* Base address of block or next table */
+    unsigned long sbz:12;       /* Must be zero */
+
+    /* These seven bits are only used in Block entries and are ignored
+     * in Table entries. */
+    unsigned long hint:1;       /* In a block of 16 contiguous entries */
+    unsigned long pxn:1;        /* Privileged-XN */
+    unsigned long xn:1;         /* eXecute-Never */
+    unsigned long avail:4;      /* Ignored by hardware */
+
+    /* These 5 bits are only used in Table entries and are ignored in
+     * Block entries */
+    unsigned long pxnt:1;       /* Privileged-XN */
+    unsigned long xnt:1;        /* eXecute-Never */
+    unsigned long apt:2;        /* Access Permissions */
+    unsigned long nst:1;        /* Not-Secure */
+} __attribute__((__packed__)) lpae_pt_t;
+
+/* The p2m tables have almost the same layout, but some of the permission
+ * and cache-control bits are laid out differently (or missing) */
+typedef struct {
+    /* These are used in all kinds of entry. */
+    unsigned long valid:1;      /* Valid mapping */
+    unsigned long table:1;      /* == 1 in 4k map entries too */
+
+    /* These ten bits are only used in Block entries and are ignored
+     * in Table entries. */
+    unsigned long mattr:4;      /* Memory Attributes */
+    unsigned long read:1;       /* Read access */
+    unsigned long write:1;      /* Write access */
+    unsigned long sh:2;         /* Shareability */
+    unsigned long af:1;         /* Access Flag */
+    unsigned long sbz4:1;
+
+    /* The base address must be approprately aligned for Block entries */
+    unsigned long base:28;      /* Base address of block or next table */
+    unsigned long sbz3:12;
+
+    /* These seven bits are only used in Block entries and are ignored
+     * in Table entries. */
+    unsigned long hint:1;       /* In a block of 16 contiguous entries */
+    unsigned long sbz2:1;
+    unsigned long xn:1;         /* eXecute-Never */
+    unsigned long avail:4;      /* Ignored by hardware */
+
+    unsigned long sbz1:5;
+} __attribute__((__packed__)) lpae_p2m_t;
+
+typedef union {
+    uint64_t bits;
+    lpae_pt_t pt;
+    lpae_p2m_t p2m;
+} lpae_t;
+
+/* Standard entry type that we'll use to build Xen's own pagetables.
+ * We put the same permissions at every level, because they're ignored
+ * by the walker in non-leaf entries. */
+static inline lpae_t mfn_to_xen_entry(unsigned long mfn)
+{
+    paddr_t pa = ((paddr_t) mfn) << PAGE_SHIFT;
+    lpae_t e = (lpae_t) {
+        .pt = {
+            .xn = 1,              /* No need to execute outside .text */
+            .ng = 1,              /* Makes TLB flushes easier */
+            .af = 1,              /* No need for access tracking */
+            .sh = LPAE_SH_OUTER,  /* Xen mappings are globally coherent */
+            .ns = 1,              /* Hyp mode is in the non-secure world */
+            .user = 1,            /* See below */
+            .ai = WRITEALLOC,
+            .table = 0,           /* Set to 1 for links and 4k maps */
+            .valid = 1,           /* Mappings are present */
+        }};;
+    /* Setting the User bit is strange, but the ATS1H[RW] instructions
+     * don't seem to work otherwise, and since we never run on Xen
+     * pagetables un User mode it's OK.  If this changes, remember
+     * to update the hard-coded values in head.S too */
+
+    ASSERT(!(pa & ~PAGE_MASK));
+    ASSERT(!(pa & ~PADDR_MASK));
+
+    // XXX shifts
+    e.bits |= pa;
+    return e;
+}
+
+static inline lpae_t mfn_to_p2m_entry(unsigned long mfn)
+{
+    paddr_t pa = ((paddr_t) mfn) << PAGE_SHIFT;
+    lpae_t e = (lpae_t) {
+        .p2m.xn = 0,
+        .p2m.af = 1,
+        .p2m.sh = LPAE_SH_OUTER,
+        .p2m.write = 1,
+        .p2m.read = 1,
+        .p2m.mattr = 0xf,
+        .p2m.table = 1,
+        .p2m.valid = 1,
+    };
+
+    ASSERT(!(pa & ~PAGE_MASK));
+    ASSERT(!(pa & ~PADDR_MASK));
+
+    e.bits |= pa;
+
+    return e;
+}
+
+/* Write a pagetable entry */
+static inline void write_pte(lpae_t *p, lpae_t pte)
+{
+    asm volatile (
+        /* Safely write the entry (STRD is atomic on CPUs that support LPAE) */
+        "strd %0, %H0, [%1];"
+        /* Push this cacheline to the PoC so the rest of the system sees it. */
+        STORE_CP32(1, DCCMVAC)
+        : : "r" (pte.bits), "r" (p) : "memory");
+}
+
+/*
+ * Flush all hypervisor mappings from the data TLB. This is not
+ * sufficient when changing code mappings or for self modifying code.
+ */
+static inline void flush_xen_data_tlb(void)
+{
+    register unsigned long r0 asm ("r0");
+    asm volatile("dsb;" /* Ensure preceding are visible */
+                 STORE_CP32(0, TLBIALLH)
+                 "dsb;" /* Ensure completion of the TLB flush */
+                 "isb;"
+                 : : "r" (r0) /* dummy */: "memory");
+}
+
+/*
+ * Flush one VA's hypervisor mappings from the data TLB. This is not
+ * sufficient when changing code mappings or for self modifying code.
+ */
+static inline void flush_xen_data_tlb_va(unsigned long va)
+{
+    asm volatile("dsb;" /* Ensure preceding are visible */
+                 STORE_CP32(0, TLBIMVAH)
+                 "dsb;" /* Ensure completion of the TLB flush */
+                 "isb;"
+                 : : "r" (va) : "memory");
+}
+
+/* Flush all non-hypervisor mappings from the TLB */
+static inline void flush_guest_tlb(void)
+{
+    register unsigned long r0 asm ("r0");
+    WRITE_CP32(r0 /* dummy */, TLBIALLNSNH);
+}
+
+/* Ask the MMU to translate a VA for us */
+static inline uint64_t __va_to_par(uint32_t va)
+{
+    uint64_t par, tmp;
+    tmp = READ_CP64(PAR);
+    WRITE_CP32(va, ATS1HR);
+    isb(); /* Ensure result is available. */
+    par = READ_CP64(PAR);
+    WRITE_CP64(tmp, PAR);
+    return par;
+}
+
+static inline uint64_t va_to_par(uint32_t va)
+{
+    uint64_t par = __va_to_par(va);
+    /* It is not OK to call this with an invalid VA */
+    if ( par & PAR_F ) panic_PAR(par, "Hypervisor");
+    return par;
+}
+
+/* Ask the MMU to translate a Guest VA for us */
+static inline uint64_t __gva_to_par(uint32_t va)
+{
+    uint64_t par, tmp;
+    tmp = READ_CP64(PAR);
+    WRITE_CP32(va, ATS12NSOPR);
+    isb(); /* Ensure result is available. */
+    par = READ_CP64(PAR);
+    WRITE_CP64(tmp, PAR);
+    return par;
+}
+static inline uint64_t gva_to_par(uint32_t va)
+{
+    uint64_t par = __gva_to_par(va);
+    /* It is not OK to call this with an invalid VA */
+    /* XXX harsh for a guest address... */
+    if ( par & PAR_F ) panic_PAR(par, "Guest");
+    return par;
+}
+static inline uint64_t __gva_to_ipa(uint32_t va)
+{
+    uint64_t par, tmp;
+    tmp = READ_CP64(PAR);
+    WRITE_CP32(va, ATS1CPR);
+    isb(); /* Ensure result is available. */
+    par = READ_CP64(PAR);
+    WRITE_CP64(tmp, PAR);
+    return par;
+}
+static inline uint64_t gva_to_ipa(uint32_t va)
+{
+    uint64_t par = __gva_to_ipa(va);
+    /* It is not OK to call this with an invalid VA */
+    /* XXX harsh for a guest address... */
+    if ( par & PAR_F ) panic_PAR(par, "Guest");
+    return (par & PADDR_MASK & PAGE_MASK) | ((unsigned long) va & ~PAGE_MASK);
+}
+/* Bits in the PAR returned by va_to_par */
+#define PAR_FAULT 0x1
+
+#endif /* __ASSEMBLY__ */
+
+/* These numbers add up to a 39-bit input address space.  The  ARMv7-A
+ * architecture actually specifies a 40-bit input address space for the p2m,
+ * with an 8K (1024-entry) top-level table. */
+
+#define LPAE_SHIFT      9
+#define LPAE_ENTRIES    (1u << LPAE_SHIFT)
+#define LPAE_ENTRY_MASK (LPAE_ENTRIES - 1)
+
+#define THIRD_SHIFT  PAGE_SHIFT
+#define SECOND_SHIFT (THIRD_SHIFT + LPAE_SHIFT)
+#define FIRST_SHIFT  (SECOND_SHIFT + LPAE_SHIFT)
+
+/* Calculate the offsets into the pagetables for a given VA */
+#define first_linear_offset(va) (va >> FIRST_SHIFT)
+#define second_linear_offset(va) (va >> SECOND_SHIFT)
+#define third_linear_offset(va) (va >> THIRD_SHIFT)
+#define first_table_offset(va) (first_linear_offset(va))
+#define second_table_offset(va) (second_linear_offset(va) & LPAE_ENTRY_MASK)
+#define third_table_offset(va) (third_linear_offset(va) & LPAE_ENTRY_MASK)
+
+#define clear_page(page)memset((void *)(page), 0, PAGE_SIZE)
+
+#define PAGE_ALIGN(x) (((x) + PAGE_SIZE - 1) & PAGE_MASK)
+
+#endif /* __ARM_PAGE_H__ */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 18:20:52 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 18:20:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXzdK-0008Jd-GY; Tue, 06 Dec 2011 18:20:50 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RXzdH-0008F8-4b
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 18:20:47 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1323195567!45659852!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDcxMjI=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32241 invoked from network); 6 Dec 2011 18:19:28 -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;
	6 Dec 2011 18:19:28 -0000
X-IronPort-AV: E=Sophos;i="4.71,307,1320642000"; d="scan'208";a="19721961"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Dec 2011 13:20:03 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Tue, 6 Dec 2011 13:20:03 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pB6IJEjX019549;
	Tue, 6 Dec 2011 10:19:47 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Tue, 6 Dec 2011 18:20:07 +0000
Message-ID: <1323195609-17277-23-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1112061753410.31179@kaball-desktop>
References: <alpine.DEB.2.00.1112061753410.31179@kaball-desktop>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>, Tim.Deegan@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH RFC 23/25] arm: trap handlers
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Functions executed exiting from the guest and returning to the guest:
trap and hypercall handlers and leave_hypervisor_tail.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
---
 xen/arch/arm/Makefile |    1 +
 xen/arch/arm/traps.c  |  609 +++++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 610 insertions(+), 0 deletions(-)
 create mode 100644 xen/arch/arm/traps.c

diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index 6eff96b..0e989b2 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -15,6 +15,7 @@ obj-y += time.o
 obj-y += smpboot.o
 obj-y += smp.o
 obj-y += shutdown.o
+obj-y += traps.o
 
 #obj-bin-y += ....o
 
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
new file mode 100644
index 0000000..4346dd7
--- /dev/null
+++ b/xen/arch/arm/traps.c
@@ -0,0 +1,609 @@
+/*
+ * xen/arch/arm/traps.c
+ *
+ * ARM Trap handlers
+ *
+ * Copyright (c) 2011 Citrix Systems.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include <xen/config.h>
+#include <xen/init.h>
+#include <xen/string.h>
+#include <xen/version.h>
+#include <xen/smp.h>
+#include <xen/symbols.h>
+#include <xen/irq.h>
+#include <xen/lib.h>
+#include <xen/mm.h>
+#include <xen/errno.h>
+#include <xen/hypercall.h>
+#include <xen/softirq.h>
+#include <public/xen.h>
+#include <asm/regs.h>
+#include <asm/cpregs.h>
+
+#include "io.h"
+#include "vtimer.h"
+#include "gic.h"
+
+/* The base of the stack must always be double-word aligned, which means
+ * that both the kernel half of struct cpu_user_regs (which is pushed in
+ * entry.S) and struct cpu_info (which lives at the bottom of a Xen
+ * stack) must be doubleword-aligned in size.  */
+static inline void check_stack_alignment_constraints(void) {
+    BUILD_BUG_ON((sizeof (struct cpu_user_regs)) & 0x7);
+    BUILD_BUG_ON((offsetof(struct cpu_user_regs, r8_fiq)) & 0x7);
+    BUILD_BUG_ON((sizeof (struct cpu_info)) & 0x7);
+}
+
+static int debug_stack_lines = 20;
+integer_param("debug_stack_lines", debug_stack_lines);
+
+#define stack_words_per_line 8
+
+asmlinkage void __div0(void)
+{
+    printk("Division by zero in hypervisor.\n");
+    BUG();
+}
+
+/* XXX could/should be common code */
+static void print_xen_info(void)
+{
+    char taint_str[TAINT_STRING_MAX_LEN];
+    char debug = 'n';
+
+#ifndef NDEBUG
+    debug = 'y';
+#endif
+
+    printk("----[ Xen-%d.%d%s  x86_64  debug=%c  %s ]----\n",
+           xen_major_version(), xen_minor_version(), xen_extra_version(),
+           debug, print_tainted(taint_str));
+}
+
+static const char *decode_fsc(uint32_t fsc, int *level)
+{
+    const char *msg = NULL;
+
+    switch ( fsc & 0x3f )
+    {
+    case FSC_FLT_TRANS ... FSC_FLT_TRANS + 3:
+        msg = "Translation fault";
+        *level = fsc & FSC_LL_MASK;
+        break;
+    case FSC_FLT_ACCESS ... FSC_FLT_ACCESS + 3:
+        msg = "Access fault";
+        *level = fsc & FSC_LL_MASK;
+        break;
+    case FSC_FLT_PERM ... FSC_FLT_PERM + 3:
+        msg = "Permission fault";
+        *level = fsc & FSC_LL_MASK;
+        break;
+
+    case FSC_SEA:
+        msg = "Synchronous External Abort";
+        break;
+    case FSC_SPE:
+        msg = "Memory Access Synchronous Parity Error";
+        break;
+    case FSC_APE:
+        msg = "Memory Access Asynchronous Parity Error";
+        break;
+    case FSC_SEATT ... FSC_SEATT + 3:
+        msg = "Sync. Ext. Abort Translation Table";
+        *level = fsc & FSC_LL_MASK;
+        break;
+    case FSC_SPETT ... FSC_SPETT + 3:
+        msg = "Sync. Parity. Error Translation Table";
+        *level = fsc & FSC_LL_MASK;
+        break;
+    case FSC_AF:
+        msg = "Alignment Fault";
+        break;
+    case FSC_DE:
+        msg = "Debug Event";
+        break;
+
+    case FSC_LKD:
+        msg = "Implementation Fault: Lockdown Abort";
+        break;
+    case FSC_CPR:
+        msg = "Implementation Fault: Coprocossor Abort";
+        break;
+
+    default:
+        msg = "Unknown Failure";
+        break;
+    }
+    return msg;
+}
+
+static const char *fsc_level_str(int level)
+{
+    switch ( level )
+    {
+    case -1: return "";
+    case 1:  return " at level 1";
+    case 2:  return " at level 2";
+    case 3:  return " at level 3";
+    default: return " (level invalid)";
+    }
+}
+
+void panic_PAR(uint64_t par, const char *when)
+{
+    if ( par & PAR_F )
+    {
+        const char *msg;
+        int level = -1;
+        int stage = par & PAR_STAGE2 ? 2 : 1;
+        int second_in_first = !!(par & PAR_STAGE21);
+
+        msg = decode_fsc( (par&PAR_FSC_MASK) >> PAR_FSC_SHIFT, &level);
+
+        printk("PAR: %010"PRIx64": %s stage %d%s%s\n",
+               par, msg,
+               stage,
+               second_in_first ? " during second stage lookup" : "",
+               fsc_level_str(level));
+    }
+    else
+    {
+        printk("PAR: %010"PRIx64": paddr:%010"PRIx64
+               " attr %"PRIx64" sh %"PRIx64" %s\n",
+               par, par & PADDR_MASK, par >> PAR_MAIR_SHIFT,
+               (par & PAR_SH_MASK) >> PAR_SH_SHIFT,
+               (par & PAR_NS) ? "Non-Secure" : "Secure");
+    }
+    panic("Error during %s-to-physical address translation\n", when);
+}
+
+void show_registers(struct cpu_user_regs *regs)
+{
+    static const char *mode_strings[] = {
+       [PSR_MODE_USR] = "USR",
+       [PSR_MODE_FIQ] = "FIQ",
+       [PSR_MODE_IRQ] = "IRQ",
+       [PSR_MODE_SVC] = "SVC",
+       [PSR_MODE_MON] = "MON",
+       [PSR_MODE_ABT] = "ABT",
+       [PSR_MODE_HYP] = "HYP",
+       [PSR_MODE_UND] = "UND",
+       [PSR_MODE_SYS] = "SYS"
+    };
+
+    print_xen_info();
+    printk("CPU:    %d\n", smp_processor_id());
+    printk("PC:     %08"PRIx32, regs->pc);
+    if ( !guest_mode(regs) )
+            print_symbol(" %s", regs->pc);
+    printk("\n");
+    printk("CPSR:   %08"PRIx32" MODE:%s\n", regs->cpsr,
+           mode_strings[regs->cpsr & PSR_MODE_MASK]);
+    printk("     R0: %08"PRIx32" R1: %08"PRIx32" R2: %08"PRIx32" R3: %08"PRIx32"\n",
+           regs->r0, regs->r1, regs->r2, regs->r3);
+    printk("     R4: %08"PRIx32" R5: %08"PRIx32" R6: %08"PRIx32" R7: %08"PRIx32"\n",
+           regs->r4, regs->r5, regs->r6, regs->r7);
+    printk("     R8: %08"PRIx32" R9: %08"PRIx32" R10:%08"PRIx32" R11:%08"PRIx32" R12:%08"PRIx32"\n",
+           regs->r8, regs->r9, regs->r10, regs->r11, regs->r12);
+
+    if ( guest_mode(regs) )
+    {
+        printk("USR: SP: %08"PRIx32" LR: %08"PRIx32" CPSR:%08"PRIx32"\n",
+               regs->sp_usr, regs->lr_usr, regs->cpsr);
+        printk("SVC: SP: %08"PRIx32" LR: %08"PRIx32" SPSR:%08"PRIx32"\n",
+               regs->sp_svc, regs->lr_svc, regs->spsr_svc);
+        printk("ABT: SP: %08"PRIx32" LR: %08"PRIx32" SPSR:%08"PRIx32"\n",
+               regs->sp_abt, regs->lr_abt, regs->spsr_abt);
+        printk("UND: SP: %08"PRIx32" LR: %08"PRIx32" SPSR:%08"PRIx32"\n",
+               regs->sp_und, regs->lr_und, regs->spsr_und);
+        printk("IRQ: SP: %08"PRIx32" LR: %08"PRIx32" SPSR:%08"PRIx32"\n",
+               regs->sp_irq, regs->lr_irq, regs->spsr_irq);
+        printk("FIQ: SP: %08"PRIx32" LR: %08"PRIx32" SPSR:%08"PRIx32"\n",
+               regs->sp_fiq, regs->lr_fiq, regs->spsr_fiq);
+        printk("FIQ: R8: %08"PRIx32" R9: %08"PRIx32" R10:%08"PRIx32" R11:%08"PRIx32" R12:%08"PRIx32"\n",
+               regs->r8_fiq, regs->r9_fiq, regs->r10_fiq, regs->r11_fiq, regs->r11_fiq);
+        printk("\n");
+        printk("TTBR0 %08"PRIx32" TTBR1 %08"PRIx32" TTBCR %08"PRIx32"\n",
+               READ_CP32(TTBR0), READ_CP32(TTBR1), READ_CP32(TTBCR));
+        printk("SCTLR %08"PRIx32"\n", READ_CP32(SCTLR));
+        printk("VTTBR %010"PRIx64"\n", READ_CP64(VTTBR));
+        printk("\n");
+    }
+    else
+    {
+        printk("     SP: %08"PRIx32" LR: %08"PRIx32"\n", regs->sp, regs->lr);
+        printk("\n");
+    }
+
+    printk("HTTBR %"PRIx64"\n", READ_CP64(HTTBR));
+    printk("HDFAR %"PRIx32"\n", READ_CP32(HDFAR));
+    printk("HIFAR %"PRIx32"\n", READ_CP32(HIFAR));
+    printk("HPFAR %"PRIx32"\n", READ_CP32(HPFAR));
+    printk("HCR %08"PRIx32"\n", READ_CP32(HCR));
+    printk("HSR   %"PRIx32"\n", READ_CP32(HSR));
+    printk("\n");
+
+    printk("DFSR %"PRIx32" DFAR %"PRIx32"\n", READ_CP32(DFSR), READ_CP32(DFAR));
+    printk("IFSR %"PRIx32" IFAR %"PRIx32"\n", READ_CP32(IFSR), READ_CP32(IFAR));
+    printk("\n");
+}
+
+static void show_guest_stack(struct cpu_user_regs *regs)
+{
+    printk("GUEST STACK GOES HERE\n");
+}
+
+#define STACK_BEFORE_EXCEPTION(regs) ((uint32_t*)(regs)->sp)
+
+static void show_trace(struct cpu_user_regs *regs)
+{
+    uint32_t *frame, next, addr, low, high;
+
+    printk("Xen call trace:\n   ");
+
+    printk("[<%p>]", _p(regs->pc));
+    print_symbol(" %s\n   ", regs->pc);
+
+    /* Bounds for range of valid frame pointer. */
+    low  = (uint32_t)(STACK_BEFORE_EXCEPTION(regs)/* - 2*/);
+    high = (low & ~(STACK_SIZE - 1)) +
+        (STACK_SIZE - sizeof(struct cpu_info));
+
+    /* Frame:
+     * (largest address)
+     * | cpu_info
+     * | [...]                                   |
+     * | return addr      <-----------------,    |
+     * | fp --------------------------------+----'
+     * | [...]                              |
+     * | return addr      <------------,    |
+     * | fp ---------------------------+----'
+     * | [...]                         |
+     * | return addr      <- regs->fp  |
+     * | fp ---------------------------'
+     * |
+     * v (smallest address, sp)
+     */
+
+    /* The initial frame pointer. */
+    next = regs->fp;
+
+    for ( ; ; )
+    {
+        if ( (next < low) || (next >= high) )
+            break;
+        {
+            /* Ordinary stack frame. */
+            frame = (uint32_t *)next;
+            next  = frame[-1];
+            addr  = frame[0];
+        }
+
+        printk("[<%p>]", _p(addr));
+        print_symbol(" %s\n   ", addr);
+
+        low = (uint32_t)&frame[1];
+    }
+
+    printk("\n");
+}
+
+void show_stack(struct cpu_user_regs *regs)
+{
+    uint32_t *stack = STACK_BEFORE_EXCEPTION(regs), addr;
+    int i;
+
+    if ( guest_mode(regs) )
+        return show_guest_stack(regs);
+
+    printk("Xen stack trace from sp=%p:\n  ", stack);
+
+    for ( i = 0; i < (debug_stack_lines*stack_words_per_line); i++ )
+    {
+        if ( ((long)stack & (STACK_SIZE-BYTES_PER_LONG)) == 0 )
+            break;
+        if ( (i != 0) && ((i % stack_words_per_line) == 0) )
+            printk("\n  ");
+
+        addr = *stack++;
+        printk(" %p", _p(addr));
+    }
+    if ( i == 0 )
+        printk("Stack empty.");
+    printk("\n");
+
+    show_trace(regs);
+}
+
+void show_execution_state(struct cpu_user_regs *regs)
+{
+    show_registers(regs);
+    show_stack(regs);
+}
+
+static void do_unexpected_trap(const char *msg, struct cpu_user_regs *regs)
+{
+    printk("Unexpected Trap: %s\n", msg);
+    show_execution_state(regs);
+    while(1);
+}
+
+asmlinkage void do_trap_undefined_instruction(struct cpu_user_regs *regs)
+{
+    do_unexpected_trap("Undefined Instruction", regs);
+}
+
+asmlinkage void do_trap_supervisor_call(struct cpu_user_regs *regs)
+{
+    do_unexpected_trap("Supervisor Call", regs);
+}
+
+asmlinkage void do_trap_prefetch_abort(struct cpu_user_regs *regs)
+{
+    do_unexpected_trap("Prefetch Abort", regs);
+}
+
+asmlinkage void do_trap_data_abort(struct cpu_user_regs *regs)
+{
+    do_unexpected_trap("Data Abort", regs);
+}
+
+unsigned long do_arch_0(unsigned int cmd, unsigned long long value)
+{
+        printk("do_arch_0 cmd=%x arg=%llx\n", cmd, value);
+        return 0;
+}
+
+typedef unsigned long arm_hypercall_t(
+    unsigned int, unsigned int, unsigned int, unsigned int, unsigned int,
+    unsigned int, unsigned int, unsigned int, unsigned int, unsigned int);
+
+#define HYPERCALL(x)                                        \
+    [ __HYPERVISOR_ ## x ] = (arm_hypercall_t *) do_ ## x
+
+static arm_hypercall_t *arm_hypercall_table[] = {
+    HYPERCALL(arch_0),
+    HYPERCALL(sched_op),
+    HYPERCALL(console_io),
+};
+
+static void do_debug_trap(struct cpu_user_regs *regs, unsigned int code)
+{
+    uint32_t reg, *r;
+
+    switch ( code ) {
+    case 0xe0 ... 0xef:
+        reg = code - 0xe0;
+        r = &regs->r0 + reg;
+        printk("R%d = %#010"PRIx32" at %#010"PRIx32"\n", reg, *r, regs->pc);
+        break;
+    case 0xfd:
+        printk("Reached %08"PRIx32"\n", regs->pc);
+        break;
+    case 0xfe:
+        printk("%c", (char)(regs->r0 & 0xff));
+        break;
+    case 0xff:
+        printk("DEBUG\n");
+        show_execution_state(regs);
+        break;
+    default:
+        panic("Unhandled debug trap %#x\n", code);
+        break;
+    }
+}
+
+static void do_trap_hypercall(struct cpu_user_regs *regs, unsigned long iss)
+{
+    local_irq_enable();
+
+    regs->r0 = arm_hypercall_table[iss](regs->r0,
+                             regs->r1,
+                             regs->r2,
+                             regs->r3,
+                             regs->r4,
+                             regs->r5,
+                             regs->r6,
+                             regs->r7,
+                             regs->r8,
+                             regs->r9);
+}
+
+static void do_cp15_32(struct cpu_user_regs *regs,
+                       union hsr hsr)
+{
+    struct hsr_cp32 cp32 = hsr.cp32;
+    uint32_t *r = &regs->r0 + cp32.reg;
+
+    if ( !cp32.ccvalid ) {
+        dprintk(XENLOG_ERR, "cp_15(32): need to handle invalid condition codes\n");
+        domain_crash_synchronous();
+    }
+    if ( cp32.cc != 0xe ) {
+        dprintk(XENLOG_ERR, "cp_15(32): need to handle condition codes %x\n",
+                cp32.cc);
+        domain_crash_synchronous();
+    }
+
+    switch ( hsr.bits & HSR_CP32_REGS_MASK )
+    {
+    case HSR_CPREG32(CLIDR):
+        if ( !cp32.read )
+        {
+            dprintk(XENLOG_ERR,
+                    "attempt to write to read-only register CLIDR\n");
+            domain_crash_synchronous();
+        }
+        *r = READ_CP32(CLIDR);
+        break;
+    case HSR_CPREG32(CCSIDR):
+        if ( !cp32.read )
+        {
+            dprintk(XENLOG_ERR,
+                    "attempt to write to read-only register CSSIDR\n");
+            domain_crash_synchronous();
+        }
+        *r = READ_CP32(CCSIDR);
+        break;
+    case HSR_CPREG32(DCCISW):
+        if ( cp32.read )
+        {
+            dprintk(XENLOG_ERR,
+                    "attempt to read from write-only register DCCISW\n");
+            domain_crash_synchronous();
+        }
+        WRITE_CP32(*r, DCCISW);
+        break;
+    case HSR_CPREG32(CNTP_CTL):
+    case HSR_CPREG32(CNTP_TVAL):
+        /* emulate timer */
+        break;
+    default:
+        printk("%s p15, %d, r%d, cr%d, cr%d, %d @ %#08x\n",
+               cp32.read ? "mrc" : "mcr",
+               cp32.op1, cp32.reg, cp32.crn, cp32.crm, cp32.op2, regs->pc);
+        panic("unhandled 32-bit CP15 access %#x\n", hsr.bits & HSR_CP32_REGS_MASK);
+    }
+    regs->pc += cp32.len ? 4 : 2;
+
+}
+
+static void do_cp15_64(struct cpu_user_regs *regs,
+                       union hsr hsr)
+{
+    struct hsr_cp64 cp64 = hsr.cp64;
+
+    if ( !cp64.ccvalid ) {
+        dprintk(XENLOG_ERR, "cp_15(64): need to handle invalid condition codes\n");
+        domain_crash_synchronous();
+    }
+    if ( cp64.cc != 0xe ) {
+        dprintk(XENLOG_ERR, "cp_15(64): need to handle condition codes %x\n",
+                cp64.cc);
+        domain_crash_synchronous();
+    }
+
+    switch ( hsr.bits & HSR_CP64_REGS_MASK )
+    {
+    case HSR_CPREG64(CNTPCT):
+        /* emulate timer */
+        break;
+    default:
+        printk("%s p15, %d, r%d, r%d, cr%d @ %#08x\n",
+               cp64.read ? "mrrc" : "mcrr",
+               cp64.op1, cp64.reg1, cp64.reg2, cp64.crm, regs->pc);
+        panic("unhandled 64-bit CP15 access %#x\n", hsr.bits & HSR_CP64_REGS_MASK);
+    }
+    regs->pc += cp64.len ? 4 : 2;
+
+}
+
+static void do_trap_data_abort_guest(struct cpu_user_regs *regs,
+                                     struct hsr_dabt dabt)
+{
+    const char *msg;
+    int level = -1;
+    mmio_info_t info;
+
+    if (dabt.s1ptw)
+        goto bad_data_abort;
+
+    info.dabt = dabt;
+    info.gva = READ_CP32(HDFAR);
+    info.gpa = gva_to_ipa(info.gva);
+
+    if (handle_mmio(&info))
+    {
+        regs->pc += dabt.len ? 4 : 2;
+        return;
+    }
+
+bad_data_abort:
+
+    msg = decode_fsc( dabt.dfsc, &level);
+
+    printk("Guest data abort: %s%s%s\n"
+           "    gva=%"PRIx32" gpa=%"PRIpaddr"\n",
+           msg, dabt.s1ptw ? " S2 during S1" : "",
+           fsc_level_str(level),
+           info.gva, info.gpa);
+    if (dabt.valid)
+        printk("    size=%d sign=%d write=%d reg=%d\n",
+               dabt.size, dabt.sign, dabt.write, dabt.reg);
+    else
+        printk("    instruction syndrome invalid\n");
+    printk("    eat=%d cm=%d s1ptw=%d dfsc=%d\n",
+           dabt.eat, dabt.cache, dabt.s1ptw, dabt.dfsc);
+
+    show_execution_state(regs);
+    panic("Unhandled guest data abort\n");
+}
+
+asmlinkage void do_trap_hypervisor(struct cpu_user_regs *regs)
+{
+    union hsr hsr = { .bits = READ_CP32(HSR) };
+
+    switch (hsr.ec) {
+    case HSR_EC_CP15_32:
+        do_cp15_32(regs, hsr);
+        break;
+    case HSR_EC_CP15_64:
+        do_cp15_64(regs, hsr);
+        break;
+    case HSR_EC_HVC:
+        if ( (hsr.iss & 0xff00) == 0xff00 )
+            return do_debug_trap(regs, hsr.iss & 0x00ff);
+        do_trap_hypercall(regs, hsr.iss);
+        break;
+    case HSR_EC_DATA_ABORT_GUEST:
+        do_trap_data_abort_guest(regs, hsr.dabt);
+        break;
+    default:
+        printk("Hypervisor Trap. HSR=0x%x EC=0x%x IL=%x Syndrome=%"PRIx32"\n",
+               hsr.bits, hsr.ec, hsr.len, hsr.iss);
+        do_unexpected_trap("Hypervisor", regs);
+    }
+}
+
+asmlinkage void do_trap_irq(struct cpu_user_regs *regs)
+{
+    gic_interrupt(regs, 0);
+}
+
+asmlinkage void do_trap_fiq(struct cpu_user_regs *regs)
+{
+    gic_interrupt(regs, 1);
+}
+
+asmlinkage void leave_hypervisor_tail(void)
+{
+    while (1)
+    {
+        local_irq_disable();
+        if (!softirq_pending(smp_processor_id()))
+            return;
+        local_irq_enable();
+        do_softirq();
+    }
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 18:20:52 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 18:20:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXzdK-0008Jd-GY; Tue, 06 Dec 2011 18:20:50 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RXzdH-0008F8-4b
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 18:20:47 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1323195567!45659852!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDcxMjI=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32241 invoked from network); 6 Dec 2011 18:19:28 -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;
	6 Dec 2011 18:19:28 -0000
X-IronPort-AV: E=Sophos;i="4.71,307,1320642000"; d="scan'208";a="19721961"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Dec 2011 13:20:03 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Tue, 6 Dec 2011 13:20:03 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pB6IJEjX019549;
	Tue, 6 Dec 2011 10:19:47 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Tue, 6 Dec 2011 18:20:07 +0000
Message-ID: <1323195609-17277-23-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1112061753410.31179@kaball-desktop>
References: <alpine.DEB.2.00.1112061753410.31179@kaball-desktop>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>, Tim.Deegan@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH RFC 23/25] arm: trap handlers
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Functions executed exiting from the guest and returning to the guest:
trap and hypercall handlers and leave_hypervisor_tail.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
---
 xen/arch/arm/Makefile |    1 +
 xen/arch/arm/traps.c  |  609 +++++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 610 insertions(+), 0 deletions(-)
 create mode 100644 xen/arch/arm/traps.c

diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index 6eff96b..0e989b2 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -15,6 +15,7 @@ obj-y += time.o
 obj-y += smpboot.o
 obj-y += smp.o
 obj-y += shutdown.o
+obj-y += traps.o
 
 #obj-bin-y += ....o
 
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
new file mode 100644
index 0000000..4346dd7
--- /dev/null
+++ b/xen/arch/arm/traps.c
@@ -0,0 +1,609 @@
+/*
+ * xen/arch/arm/traps.c
+ *
+ * ARM Trap handlers
+ *
+ * Copyright (c) 2011 Citrix Systems.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include <xen/config.h>
+#include <xen/init.h>
+#include <xen/string.h>
+#include <xen/version.h>
+#include <xen/smp.h>
+#include <xen/symbols.h>
+#include <xen/irq.h>
+#include <xen/lib.h>
+#include <xen/mm.h>
+#include <xen/errno.h>
+#include <xen/hypercall.h>
+#include <xen/softirq.h>
+#include <public/xen.h>
+#include <asm/regs.h>
+#include <asm/cpregs.h>
+
+#include "io.h"
+#include "vtimer.h"
+#include "gic.h"
+
+/* The base of the stack must always be double-word aligned, which means
+ * that both the kernel half of struct cpu_user_regs (which is pushed in
+ * entry.S) and struct cpu_info (which lives at the bottom of a Xen
+ * stack) must be doubleword-aligned in size.  */
+static inline void check_stack_alignment_constraints(void) {
+    BUILD_BUG_ON((sizeof (struct cpu_user_regs)) & 0x7);
+    BUILD_BUG_ON((offsetof(struct cpu_user_regs, r8_fiq)) & 0x7);
+    BUILD_BUG_ON((sizeof (struct cpu_info)) & 0x7);
+}
+
+static int debug_stack_lines = 20;
+integer_param("debug_stack_lines", debug_stack_lines);
+
+#define stack_words_per_line 8
+
+asmlinkage void __div0(void)
+{
+    printk("Division by zero in hypervisor.\n");
+    BUG();
+}
+
+/* XXX could/should be common code */
+static void print_xen_info(void)
+{
+    char taint_str[TAINT_STRING_MAX_LEN];
+    char debug = 'n';
+
+#ifndef NDEBUG
+    debug = 'y';
+#endif
+
+    printk("----[ Xen-%d.%d%s  x86_64  debug=%c  %s ]----\n",
+           xen_major_version(), xen_minor_version(), xen_extra_version(),
+           debug, print_tainted(taint_str));
+}
+
+static const char *decode_fsc(uint32_t fsc, int *level)
+{
+    const char *msg = NULL;
+
+    switch ( fsc & 0x3f )
+    {
+    case FSC_FLT_TRANS ... FSC_FLT_TRANS + 3:
+        msg = "Translation fault";
+        *level = fsc & FSC_LL_MASK;
+        break;
+    case FSC_FLT_ACCESS ... FSC_FLT_ACCESS + 3:
+        msg = "Access fault";
+        *level = fsc & FSC_LL_MASK;
+        break;
+    case FSC_FLT_PERM ... FSC_FLT_PERM + 3:
+        msg = "Permission fault";
+        *level = fsc & FSC_LL_MASK;
+        break;
+
+    case FSC_SEA:
+        msg = "Synchronous External Abort";
+        break;
+    case FSC_SPE:
+        msg = "Memory Access Synchronous Parity Error";
+        break;
+    case FSC_APE:
+        msg = "Memory Access Asynchronous Parity Error";
+        break;
+    case FSC_SEATT ... FSC_SEATT + 3:
+        msg = "Sync. Ext. Abort Translation Table";
+        *level = fsc & FSC_LL_MASK;
+        break;
+    case FSC_SPETT ... FSC_SPETT + 3:
+        msg = "Sync. Parity. Error Translation Table";
+        *level = fsc & FSC_LL_MASK;
+        break;
+    case FSC_AF:
+        msg = "Alignment Fault";
+        break;
+    case FSC_DE:
+        msg = "Debug Event";
+        break;
+
+    case FSC_LKD:
+        msg = "Implementation Fault: Lockdown Abort";
+        break;
+    case FSC_CPR:
+        msg = "Implementation Fault: Coprocossor Abort";
+        break;
+
+    default:
+        msg = "Unknown Failure";
+        break;
+    }
+    return msg;
+}
+
+static const char *fsc_level_str(int level)
+{
+    switch ( level )
+    {
+    case -1: return "";
+    case 1:  return " at level 1";
+    case 2:  return " at level 2";
+    case 3:  return " at level 3";
+    default: return " (level invalid)";
+    }
+}
+
+void panic_PAR(uint64_t par, const char *when)
+{
+    if ( par & PAR_F )
+    {
+        const char *msg;
+        int level = -1;
+        int stage = par & PAR_STAGE2 ? 2 : 1;
+        int second_in_first = !!(par & PAR_STAGE21);
+
+        msg = decode_fsc( (par&PAR_FSC_MASK) >> PAR_FSC_SHIFT, &level);
+
+        printk("PAR: %010"PRIx64": %s stage %d%s%s\n",
+               par, msg,
+               stage,
+               second_in_first ? " during second stage lookup" : "",
+               fsc_level_str(level));
+    }
+    else
+    {
+        printk("PAR: %010"PRIx64": paddr:%010"PRIx64
+               " attr %"PRIx64" sh %"PRIx64" %s\n",
+               par, par & PADDR_MASK, par >> PAR_MAIR_SHIFT,
+               (par & PAR_SH_MASK) >> PAR_SH_SHIFT,
+               (par & PAR_NS) ? "Non-Secure" : "Secure");
+    }
+    panic("Error during %s-to-physical address translation\n", when);
+}
+
+void show_registers(struct cpu_user_regs *regs)
+{
+    static const char *mode_strings[] = {
+       [PSR_MODE_USR] = "USR",
+       [PSR_MODE_FIQ] = "FIQ",
+       [PSR_MODE_IRQ] = "IRQ",
+       [PSR_MODE_SVC] = "SVC",
+       [PSR_MODE_MON] = "MON",
+       [PSR_MODE_ABT] = "ABT",
+       [PSR_MODE_HYP] = "HYP",
+       [PSR_MODE_UND] = "UND",
+       [PSR_MODE_SYS] = "SYS"
+    };
+
+    print_xen_info();
+    printk("CPU:    %d\n", smp_processor_id());
+    printk("PC:     %08"PRIx32, regs->pc);
+    if ( !guest_mode(regs) )
+            print_symbol(" %s", regs->pc);
+    printk("\n");
+    printk("CPSR:   %08"PRIx32" MODE:%s\n", regs->cpsr,
+           mode_strings[regs->cpsr & PSR_MODE_MASK]);
+    printk("     R0: %08"PRIx32" R1: %08"PRIx32" R2: %08"PRIx32" R3: %08"PRIx32"\n",
+           regs->r0, regs->r1, regs->r2, regs->r3);
+    printk("     R4: %08"PRIx32" R5: %08"PRIx32" R6: %08"PRIx32" R7: %08"PRIx32"\n",
+           regs->r4, regs->r5, regs->r6, regs->r7);
+    printk("     R8: %08"PRIx32" R9: %08"PRIx32" R10:%08"PRIx32" R11:%08"PRIx32" R12:%08"PRIx32"\n",
+           regs->r8, regs->r9, regs->r10, regs->r11, regs->r12);
+
+    if ( guest_mode(regs) )
+    {
+        printk("USR: SP: %08"PRIx32" LR: %08"PRIx32" CPSR:%08"PRIx32"\n",
+               regs->sp_usr, regs->lr_usr, regs->cpsr);
+        printk("SVC: SP: %08"PRIx32" LR: %08"PRIx32" SPSR:%08"PRIx32"\n",
+               regs->sp_svc, regs->lr_svc, regs->spsr_svc);
+        printk("ABT: SP: %08"PRIx32" LR: %08"PRIx32" SPSR:%08"PRIx32"\n",
+               regs->sp_abt, regs->lr_abt, regs->spsr_abt);
+        printk("UND: SP: %08"PRIx32" LR: %08"PRIx32" SPSR:%08"PRIx32"\n",
+               regs->sp_und, regs->lr_und, regs->spsr_und);
+        printk("IRQ: SP: %08"PRIx32" LR: %08"PRIx32" SPSR:%08"PRIx32"\n",
+               regs->sp_irq, regs->lr_irq, regs->spsr_irq);
+        printk("FIQ: SP: %08"PRIx32" LR: %08"PRIx32" SPSR:%08"PRIx32"\n",
+               regs->sp_fiq, regs->lr_fiq, regs->spsr_fiq);
+        printk("FIQ: R8: %08"PRIx32" R9: %08"PRIx32" R10:%08"PRIx32" R11:%08"PRIx32" R12:%08"PRIx32"\n",
+               regs->r8_fiq, regs->r9_fiq, regs->r10_fiq, regs->r11_fiq, regs->r11_fiq);
+        printk("\n");
+        printk("TTBR0 %08"PRIx32" TTBR1 %08"PRIx32" TTBCR %08"PRIx32"\n",
+               READ_CP32(TTBR0), READ_CP32(TTBR1), READ_CP32(TTBCR));
+        printk("SCTLR %08"PRIx32"\n", READ_CP32(SCTLR));
+        printk("VTTBR %010"PRIx64"\n", READ_CP64(VTTBR));
+        printk("\n");
+    }
+    else
+    {
+        printk("     SP: %08"PRIx32" LR: %08"PRIx32"\n", regs->sp, regs->lr);
+        printk("\n");
+    }
+
+    printk("HTTBR %"PRIx64"\n", READ_CP64(HTTBR));
+    printk("HDFAR %"PRIx32"\n", READ_CP32(HDFAR));
+    printk("HIFAR %"PRIx32"\n", READ_CP32(HIFAR));
+    printk("HPFAR %"PRIx32"\n", READ_CP32(HPFAR));
+    printk("HCR %08"PRIx32"\n", READ_CP32(HCR));
+    printk("HSR   %"PRIx32"\n", READ_CP32(HSR));
+    printk("\n");
+
+    printk("DFSR %"PRIx32" DFAR %"PRIx32"\n", READ_CP32(DFSR), READ_CP32(DFAR));
+    printk("IFSR %"PRIx32" IFAR %"PRIx32"\n", READ_CP32(IFSR), READ_CP32(IFAR));
+    printk("\n");
+}
+
+static void show_guest_stack(struct cpu_user_regs *regs)
+{
+    printk("GUEST STACK GOES HERE\n");
+}
+
+#define STACK_BEFORE_EXCEPTION(regs) ((uint32_t*)(regs)->sp)
+
+static void show_trace(struct cpu_user_regs *regs)
+{
+    uint32_t *frame, next, addr, low, high;
+
+    printk("Xen call trace:\n   ");
+
+    printk("[<%p>]", _p(regs->pc));
+    print_symbol(" %s\n   ", regs->pc);
+
+    /* Bounds for range of valid frame pointer. */
+    low  = (uint32_t)(STACK_BEFORE_EXCEPTION(regs)/* - 2*/);
+    high = (low & ~(STACK_SIZE - 1)) +
+        (STACK_SIZE - sizeof(struct cpu_info));
+
+    /* Frame:
+     * (largest address)
+     * | cpu_info
+     * | [...]                                   |
+     * | return addr      <-----------------,    |
+     * | fp --------------------------------+----'
+     * | [...]                              |
+     * | return addr      <------------,    |
+     * | fp ---------------------------+----'
+     * | [...]                         |
+     * | return addr      <- regs->fp  |
+     * | fp ---------------------------'
+     * |
+     * v (smallest address, sp)
+     */
+
+    /* The initial frame pointer. */
+    next = regs->fp;
+
+    for ( ; ; )
+    {
+        if ( (next < low) || (next >= high) )
+            break;
+        {
+            /* Ordinary stack frame. */
+            frame = (uint32_t *)next;
+            next  = frame[-1];
+            addr  = frame[0];
+        }
+
+        printk("[<%p>]", _p(addr));
+        print_symbol(" %s\n   ", addr);
+
+        low = (uint32_t)&frame[1];
+    }
+
+    printk("\n");
+}
+
+void show_stack(struct cpu_user_regs *regs)
+{
+    uint32_t *stack = STACK_BEFORE_EXCEPTION(regs), addr;
+    int i;
+
+    if ( guest_mode(regs) )
+        return show_guest_stack(regs);
+
+    printk("Xen stack trace from sp=%p:\n  ", stack);
+
+    for ( i = 0; i < (debug_stack_lines*stack_words_per_line); i++ )
+    {
+        if ( ((long)stack & (STACK_SIZE-BYTES_PER_LONG)) == 0 )
+            break;
+        if ( (i != 0) && ((i % stack_words_per_line) == 0) )
+            printk("\n  ");
+
+        addr = *stack++;
+        printk(" %p", _p(addr));
+    }
+    if ( i == 0 )
+        printk("Stack empty.");
+    printk("\n");
+
+    show_trace(regs);
+}
+
+void show_execution_state(struct cpu_user_regs *regs)
+{
+    show_registers(regs);
+    show_stack(regs);
+}
+
+static void do_unexpected_trap(const char *msg, struct cpu_user_regs *regs)
+{
+    printk("Unexpected Trap: %s\n", msg);
+    show_execution_state(regs);
+    while(1);
+}
+
+asmlinkage void do_trap_undefined_instruction(struct cpu_user_regs *regs)
+{
+    do_unexpected_trap("Undefined Instruction", regs);
+}
+
+asmlinkage void do_trap_supervisor_call(struct cpu_user_regs *regs)
+{
+    do_unexpected_trap("Supervisor Call", regs);
+}
+
+asmlinkage void do_trap_prefetch_abort(struct cpu_user_regs *regs)
+{
+    do_unexpected_trap("Prefetch Abort", regs);
+}
+
+asmlinkage void do_trap_data_abort(struct cpu_user_regs *regs)
+{
+    do_unexpected_trap("Data Abort", regs);
+}
+
+unsigned long do_arch_0(unsigned int cmd, unsigned long long value)
+{
+        printk("do_arch_0 cmd=%x arg=%llx\n", cmd, value);
+        return 0;
+}
+
+typedef unsigned long arm_hypercall_t(
+    unsigned int, unsigned int, unsigned int, unsigned int, unsigned int,
+    unsigned int, unsigned int, unsigned int, unsigned int, unsigned int);
+
+#define HYPERCALL(x)                                        \
+    [ __HYPERVISOR_ ## x ] = (arm_hypercall_t *) do_ ## x
+
+static arm_hypercall_t *arm_hypercall_table[] = {
+    HYPERCALL(arch_0),
+    HYPERCALL(sched_op),
+    HYPERCALL(console_io),
+};
+
+static void do_debug_trap(struct cpu_user_regs *regs, unsigned int code)
+{
+    uint32_t reg, *r;
+
+    switch ( code ) {
+    case 0xe0 ... 0xef:
+        reg = code - 0xe0;
+        r = &regs->r0 + reg;
+        printk("R%d = %#010"PRIx32" at %#010"PRIx32"\n", reg, *r, regs->pc);
+        break;
+    case 0xfd:
+        printk("Reached %08"PRIx32"\n", regs->pc);
+        break;
+    case 0xfe:
+        printk("%c", (char)(regs->r0 & 0xff));
+        break;
+    case 0xff:
+        printk("DEBUG\n");
+        show_execution_state(regs);
+        break;
+    default:
+        panic("Unhandled debug trap %#x\n", code);
+        break;
+    }
+}
+
+static void do_trap_hypercall(struct cpu_user_regs *regs, unsigned long iss)
+{
+    local_irq_enable();
+
+    regs->r0 = arm_hypercall_table[iss](regs->r0,
+                             regs->r1,
+                             regs->r2,
+                             regs->r3,
+                             regs->r4,
+                             regs->r5,
+                             regs->r6,
+                             regs->r7,
+                             regs->r8,
+                             regs->r9);
+}
+
+static void do_cp15_32(struct cpu_user_regs *regs,
+                       union hsr hsr)
+{
+    struct hsr_cp32 cp32 = hsr.cp32;
+    uint32_t *r = &regs->r0 + cp32.reg;
+
+    if ( !cp32.ccvalid ) {
+        dprintk(XENLOG_ERR, "cp_15(32): need to handle invalid condition codes\n");
+        domain_crash_synchronous();
+    }
+    if ( cp32.cc != 0xe ) {
+        dprintk(XENLOG_ERR, "cp_15(32): need to handle condition codes %x\n",
+                cp32.cc);
+        domain_crash_synchronous();
+    }
+
+    switch ( hsr.bits & HSR_CP32_REGS_MASK )
+    {
+    case HSR_CPREG32(CLIDR):
+        if ( !cp32.read )
+        {
+            dprintk(XENLOG_ERR,
+                    "attempt to write to read-only register CLIDR\n");
+            domain_crash_synchronous();
+        }
+        *r = READ_CP32(CLIDR);
+        break;
+    case HSR_CPREG32(CCSIDR):
+        if ( !cp32.read )
+        {
+            dprintk(XENLOG_ERR,
+                    "attempt to write to read-only register CSSIDR\n");
+            domain_crash_synchronous();
+        }
+        *r = READ_CP32(CCSIDR);
+        break;
+    case HSR_CPREG32(DCCISW):
+        if ( cp32.read )
+        {
+            dprintk(XENLOG_ERR,
+                    "attempt to read from write-only register DCCISW\n");
+            domain_crash_synchronous();
+        }
+        WRITE_CP32(*r, DCCISW);
+        break;
+    case HSR_CPREG32(CNTP_CTL):
+    case HSR_CPREG32(CNTP_TVAL):
+        /* emulate timer */
+        break;
+    default:
+        printk("%s p15, %d, r%d, cr%d, cr%d, %d @ %#08x\n",
+               cp32.read ? "mrc" : "mcr",
+               cp32.op1, cp32.reg, cp32.crn, cp32.crm, cp32.op2, regs->pc);
+        panic("unhandled 32-bit CP15 access %#x\n", hsr.bits & HSR_CP32_REGS_MASK);
+    }
+    regs->pc += cp32.len ? 4 : 2;
+
+}
+
+static void do_cp15_64(struct cpu_user_regs *regs,
+                       union hsr hsr)
+{
+    struct hsr_cp64 cp64 = hsr.cp64;
+
+    if ( !cp64.ccvalid ) {
+        dprintk(XENLOG_ERR, "cp_15(64): need to handle invalid condition codes\n");
+        domain_crash_synchronous();
+    }
+    if ( cp64.cc != 0xe ) {
+        dprintk(XENLOG_ERR, "cp_15(64): need to handle condition codes %x\n",
+                cp64.cc);
+        domain_crash_synchronous();
+    }
+
+    switch ( hsr.bits & HSR_CP64_REGS_MASK )
+    {
+    case HSR_CPREG64(CNTPCT):
+        /* emulate timer */
+        break;
+    default:
+        printk("%s p15, %d, r%d, r%d, cr%d @ %#08x\n",
+               cp64.read ? "mrrc" : "mcrr",
+               cp64.op1, cp64.reg1, cp64.reg2, cp64.crm, regs->pc);
+        panic("unhandled 64-bit CP15 access %#x\n", hsr.bits & HSR_CP64_REGS_MASK);
+    }
+    regs->pc += cp64.len ? 4 : 2;
+
+}
+
+static void do_trap_data_abort_guest(struct cpu_user_regs *regs,
+                                     struct hsr_dabt dabt)
+{
+    const char *msg;
+    int level = -1;
+    mmio_info_t info;
+
+    if (dabt.s1ptw)
+        goto bad_data_abort;
+
+    info.dabt = dabt;
+    info.gva = READ_CP32(HDFAR);
+    info.gpa = gva_to_ipa(info.gva);
+
+    if (handle_mmio(&info))
+    {
+        regs->pc += dabt.len ? 4 : 2;
+        return;
+    }
+
+bad_data_abort:
+
+    msg = decode_fsc( dabt.dfsc, &level);
+
+    printk("Guest data abort: %s%s%s\n"
+           "    gva=%"PRIx32" gpa=%"PRIpaddr"\n",
+           msg, dabt.s1ptw ? " S2 during S1" : "",
+           fsc_level_str(level),
+           info.gva, info.gpa);
+    if (dabt.valid)
+        printk("    size=%d sign=%d write=%d reg=%d\n",
+               dabt.size, dabt.sign, dabt.write, dabt.reg);
+    else
+        printk("    instruction syndrome invalid\n");
+    printk("    eat=%d cm=%d s1ptw=%d dfsc=%d\n",
+           dabt.eat, dabt.cache, dabt.s1ptw, dabt.dfsc);
+
+    show_execution_state(regs);
+    panic("Unhandled guest data abort\n");
+}
+
+asmlinkage void do_trap_hypervisor(struct cpu_user_regs *regs)
+{
+    union hsr hsr = { .bits = READ_CP32(HSR) };
+
+    switch (hsr.ec) {
+    case HSR_EC_CP15_32:
+        do_cp15_32(regs, hsr);
+        break;
+    case HSR_EC_CP15_64:
+        do_cp15_64(regs, hsr);
+        break;
+    case HSR_EC_HVC:
+        if ( (hsr.iss & 0xff00) == 0xff00 )
+            return do_debug_trap(regs, hsr.iss & 0x00ff);
+        do_trap_hypercall(regs, hsr.iss);
+        break;
+    case HSR_EC_DATA_ABORT_GUEST:
+        do_trap_data_abort_guest(regs, hsr.dabt);
+        break;
+    default:
+        printk("Hypervisor Trap. HSR=0x%x EC=0x%x IL=%x Syndrome=%"PRIx32"\n",
+               hsr.bits, hsr.ec, hsr.len, hsr.iss);
+        do_unexpected_trap("Hypervisor", regs);
+    }
+}
+
+asmlinkage void do_trap_irq(struct cpu_user_regs *regs)
+{
+    gic_interrupt(regs, 0);
+}
+
+asmlinkage void do_trap_fiq(struct cpu_user_regs *regs)
+{
+    gic_interrupt(regs, 1);
+}
+
+asmlinkage void leave_hypervisor_tail(void)
+{
+    while (1)
+    {
+        local_irq_disable();
+        if (!softirq_pending(smp_processor_id()))
+            return;
+        local_irq_enable();
+        do_softirq();
+    }
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 18:20:52 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 18:20:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXzdL-0008LQ-H5; Tue, 06 Dec 2011 18:20:51 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RXzdI-0008BU-0g
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 18:20:48 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1323195598!5607861!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDcxMjI=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5426 invoked from network); 6 Dec 2011 18:20:01 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Dec 2011 18:20:01 -0000
X-IronPort-AV: E=Sophos;i="4.71,307,1320642000"; d="scan'208";a="19721956"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Dec 2011 13:20:00 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Tue, 6 Dec 2011 13:20:00 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pB6IJEjV019549;
	Tue, 6 Dec 2011 10:19:44 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Tue, 6 Dec 2011 18:20:05 +0000
Message-ID: <1323195609-17277-21-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1112061753410.31179@kaball-desktop>
References: <alpine.DEB.2.00.1112061753410.31179@kaball-desktop>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>, Tim.Deegan@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH RFC 21/25] arm: shutdown, smp and smpboot
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Dummy implementation of machine_* and smp_*

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
---
 xen/arch/arm/Makefile   |    3 ++
 xen/arch/arm/shutdown.c |   23 +++++++++++++++++++++
 xen/arch/arm/smp.c      |   29 +++++++++++++++++++++++++++
 xen/arch/arm/smpboot.c  |   50 +++++++++++++++++++++++++++++++++++++++++++++++
 4 files changed, 105 insertions(+), 0 deletions(-)
 create mode 100644 xen/arch/arm/shutdown.c
 create mode 100644 xen/arch/arm/smp.c
 create mode 100644 xen/arch/arm/smpboot.c

diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index a856f5e..7ba02dd 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -11,6 +11,9 @@ obj-y += mm.o
 obj-y += p2m.o
 obj-y += usercopy.o
 obj-y += setup.o
+obj-y += smpboot.o
+obj-y += smp.o
+obj-y += shutdown.o
 
 #obj-bin-y += ....o
 
diff --git a/xen/arch/arm/shutdown.c b/xen/arch/arm/shutdown.c
new file mode 100644
index 0000000..2e35d2d
--- /dev/null
+++ b/xen/arch/arm/shutdown.c
@@ -0,0 +1,23 @@
+#include <xen/config.h>
+#include <xen/lib.h>
+
+void machine_halt(void)
+{
+        /* TODO: halt */
+        while(1) ;
+}
+
+void machine_restart(unsigned int delay_millisecs)
+{
+        /* TODO: restart */
+        printk("Cannot restart yet\n");
+        while(1);
+}
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/arch/arm/smp.c b/xen/arch/arm/smp.c
new file mode 100644
index 0000000..677c71a
--- /dev/null
+++ b/xen/arch/arm/smp.c
@@ -0,0 +1,29 @@
+#include <xen/config.h>
+#include <asm/smp.h>
+
+void smp_call_function(
+    void (*func) (void *info),
+    void *info,
+    int wait)
+{
+	/* TODO: No SMP just now, does not include self so nothing to do.
+	   cpumask_t allbutself = cpu_online_map;
+	   cpu_clear(smp_processor_id(), allbutself);
+	   on_selected_cpus(&allbutself, func, info, wait);
+	*/
+}
+void smp_send_event_check_mask(const cpumask_t *mask)
+{
+    /* TODO: No SMP just now, does not include self so nothing to do.
+	   send_IPI_mask(mask, EVENT_CHECK_VECTOR);
+	*/
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c
new file mode 100644
index 0000000..8287473
--- /dev/null
+++ b/xen/arch/arm/smpboot.c
@@ -0,0 +1,50 @@
+/*
+ * xen/arch/arm/smpboot.c
+ *
+ * Dummy smpboot support
+ *
+ * Copyright (c) 2011 Citrix Systems.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include <xen/cpumask.h>
+#include <xen/smp.h>
+#include <xen/init.h>
+
+cpumask_t cpu_online_map;
+EXPORT_SYMBOL(cpu_online_map);
+cpumask_t cpu_present_map;
+EXPORT_SYMBOL(cpu_online_map);
+cpumask_t cpu_possible_map;
+EXPORT_SYMBOL(cpu_possible_map);
+
+void __init
+smp_prepare_cpus (unsigned int max_cpus)
+{
+        set_processor_id(0); /* needed early, for smp_processor_id() */
+
+        cpumask_clear(&cpu_online_map);
+        cpumask_clear(&cpu_present_map);
+        cpumask_clear(&cpu_possible_map);
+        cpumask_set_cpu(0, &cpu_online_map);
+        cpumask_set_cpu(0, &cpu_present_map);
+        cpumask_set_cpu(0, &cpu_possible_map);
+        return;
+}
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 18:20:52 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 18:20:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXzdL-0008LQ-H5; Tue, 06 Dec 2011 18:20:51 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RXzdI-0008BU-0g
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 18:20:48 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1323195598!5607861!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDcxMjI=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5426 invoked from network); 6 Dec 2011 18:20:01 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Dec 2011 18:20:01 -0000
X-IronPort-AV: E=Sophos;i="4.71,307,1320642000"; d="scan'208";a="19721956"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Dec 2011 13:20:00 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Tue, 6 Dec 2011 13:20:00 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pB6IJEjV019549;
	Tue, 6 Dec 2011 10:19:44 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Tue, 6 Dec 2011 18:20:05 +0000
Message-ID: <1323195609-17277-21-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1112061753410.31179@kaball-desktop>
References: <alpine.DEB.2.00.1112061753410.31179@kaball-desktop>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>, Tim.Deegan@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH RFC 21/25] arm: shutdown, smp and smpboot
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Dummy implementation of machine_* and smp_*

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
---
 xen/arch/arm/Makefile   |    3 ++
 xen/arch/arm/shutdown.c |   23 +++++++++++++++++++++
 xen/arch/arm/smp.c      |   29 +++++++++++++++++++++++++++
 xen/arch/arm/smpboot.c  |   50 +++++++++++++++++++++++++++++++++++++++++++++++
 4 files changed, 105 insertions(+), 0 deletions(-)
 create mode 100644 xen/arch/arm/shutdown.c
 create mode 100644 xen/arch/arm/smp.c
 create mode 100644 xen/arch/arm/smpboot.c

diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index a856f5e..7ba02dd 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -11,6 +11,9 @@ obj-y += mm.o
 obj-y += p2m.o
 obj-y += usercopy.o
 obj-y += setup.o
+obj-y += smpboot.o
+obj-y += smp.o
+obj-y += shutdown.o
 
 #obj-bin-y += ....o
 
diff --git a/xen/arch/arm/shutdown.c b/xen/arch/arm/shutdown.c
new file mode 100644
index 0000000..2e35d2d
--- /dev/null
+++ b/xen/arch/arm/shutdown.c
@@ -0,0 +1,23 @@
+#include <xen/config.h>
+#include <xen/lib.h>
+
+void machine_halt(void)
+{
+        /* TODO: halt */
+        while(1) ;
+}
+
+void machine_restart(unsigned int delay_millisecs)
+{
+        /* TODO: restart */
+        printk("Cannot restart yet\n");
+        while(1);
+}
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/arch/arm/smp.c b/xen/arch/arm/smp.c
new file mode 100644
index 0000000..677c71a
--- /dev/null
+++ b/xen/arch/arm/smp.c
@@ -0,0 +1,29 @@
+#include <xen/config.h>
+#include <asm/smp.h>
+
+void smp_call_function(
+    void (*func) (void *info),
+    void *info,
+    int wait)
+{
+	/* TODO: No SMP just now, does not include self so nothing to do.
+	   cpumask_t allbutself = cpu_online_map;
+	   cpu_clear(smp_processor_id(), allbutself);
+	   on_selected_cpus(&allbutself, func, info, wait);
+	*/
+}
+void smp_send_event_check_mask(const cpumask_t *mask)
+{
+    /* TODO: No SMP just now, does not include self so nothing to do.
+	   send_IPI_mask(mask, EVENT_CHECK_VECTOR);
+	*/
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c
new file mode 100644
index 0000000..8287473
--- /dev/null
+++ b/xen/arch/arm/smpboot.c
@@ -0,0 +1,50 @@
+/*
+ * xen/arch/arm/smpboot.c
+ *
+ * Dummy smpboot support
+ *
+ * Copyright (c) 2011 Citrix Systems.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include <xen/cpumask.h>
+#include <xen/smp.h>
+#include <xen/init.h>
+
+cpumask_t cpu_online_map;
+EXPORT_SYMBOL(cpu_online_map);
+cpumask_t cpu_present_map;
+EXPORT_SYMBOL(cpu_online_map);
+cpumask_t cpu_possible_map;
+EXPORT_SYMBOL(cpu_possible_map);
+
+void __init
+smp_prepare_cpus (unsigned int max_cpus)
+{
+        set_processor_id(0); /* needed early, for smp_processor_id() */
+
+        cpumask_clear(&cpu_online_map);
+        cpumask_clear(&cpu_present_map);
+        cpumask_clear(&cpu_possible_map);
+        cpumask_set_cpu(0, &cpu_online_map);
+        cpumask_set_cpu(0, &cpu_present_map);
+        cpumask_set_cpu(0, &cpu_possible_map);
+        return;
+}
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 18:20:53 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 18:20:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXzdK-0008Ka-Vf; Tue, 06 Dec 2011 18:20:50 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RXzdH-0008B7-Mt
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 18:20:48 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1323195597!1577792!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDcxMjI=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9813 invoked from network); 6 Dec 2011 18:20:00 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Dec 2011 18:20:00 -0000
X-IronPort-AV: E=Sophos;i="4.71,307,1320642000"; d="scan'208";a="19721955"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Dec 2011 13:19:59 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Tue, 6 Dec 2011 13:19:59 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pB6IJEjU019549;
	Tue, 6 Dec 2011 10:19:42 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Tue, 6 Dec 2011 18:20:04 +0000
Message-ID: <1323195609-17277-20-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1112061753410.31179@kaball-desktop>
References: <alpine.DEB.2.00.1112061753410.31179@kaball-desktop>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>, Tim.Deegan@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH RFC 20/25] arm: early setup code
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
---
 xen/arch/arm/Makefile |    1 +
 xen/arch/arm/setup.c  |  206 +++++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 207 insertions(+), 0 deletions(-)
 create mode 100644 xen/arch/arm/setup.c

diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index fb8f4ee..a856f5e 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -10,6 +10,7 @@ obj-y += irq.o
 obj-y += mm.o
 obj-y += p2m.o
 obj-y += usercopy.o
+obj-y += setup.o
 
 #obj-bin-y += ....o
 
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
new file mode 100644
index 0000000..33c880e
--- /dev/null
+++ b/xen/arch/arm/setup.c
@@ -0,0 +1,206 @@
+/*
+ * xen/arch/arm/setup.c
+ *
+ * Early bringup code for an ARMv7-A with virt extensions.
+ *
+ * Tim Deegan <tim@xen.org>
+ * Copyright (c) 2011 Citrix Systems.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include <xen/config.h>
+#include <xen/compile.h>
+#include <xen/domain_page.h>
+#include <xen/types.h>
+#include <xen/string.h>
+#include <xen/serial.h>
+#include <xen/sched.h>
+#include <xen/console.h>
+#include <xen/init.h>
+#include <xen/irq.h>
+#include <xen/mm.h>
+#include <xen/softirq.h>
+#include <xen/keyhandler.h>
+#include <xen/cpu.h>
+#include <asm/page.h>
+#include <asm/current.h>
+#include <asm/setup.h>
+#include "gic.h"
+
+/* maxcpus: maximum number of CPUs to activate. */
+static unsigned int __initdata max_cpus = NR_CPUS;
+
+/* Xen stack for bringing up the first CPU. */
+unsigned char init_stack[STACK_SIZE] __attribute__((__aligned__(STACK_SIZE)));
+
+extern char __init_begin[], __init_end[], __bss_start[];
+
+static __attribute_used__ void init_done(void)
+{
+	/* TODO: free (or page-protect) the init areas.
+	   memset(__init_begin, 0xcc, __init_end - __init_begin);
+	   free_xen_data(__init_begin, __init_end);
+	*/
+    printk("Freed %ldkB init memory.\n", (long)(__init_end-__init_begin)>>10);
+
+    startup_cpu_idle_loop();
+}
+
+static void __init init_idle_domain(void)
+{
+        scheduler_init();
+        set_current(idle_vcpu[0]);
+        this_cpu(curr_vcpu) = current;
+        /* TODO: setup_idle_pagetable(); */
+}
+
+void __init start_xen(unsigned long boot_phys_offset,
+                      unsigned long arm_type,
+                      unsigned long atag_paddr)
+
+{
+    int i;
+
+    setup_pagetables(boot_phys_offset);
+
+#ifdef EARLY_UART_ADDRESS
+    /* Map the UART */
+    /* TODO Need to get device tree or command line for UART address */
+    set_fixmap(FIXMAP_CONSOLE, EARLY_UART_ADDRESS >> PAGE_SHIFT, DEV_SHARED);
+    pl011_init(0, FIXMAP_ADDR(FIXMAP_CONSOLE));
+    console_init_preirq();
+#endif
+
+    set_current((struct vcpu *)0xfffff000); /* debug sanity */
+    idle_vcpu[0] = current;
+    set_processor_id(0); /* needed early, for smp_processor_id() */
+
+    /* TODO: smp_prepare_boot_cpu(void) */
+    cpumask_set_cpu(smp_processor_id(), &cpu_online_map);
+    cpumask_set_cpu(smp_processor_id(), &cpu_present_map);
+
+    smp_prepare_cpus(max_cpus);
+
+    init_xen_time();
+
+    /* TODO: This needs some thought, as well as device-tree mapping.
+     * For testing, assume that the whole xenheap is contiguous in RAM */
+    setup_xenheap_mappings(0x8000000, 0x40000); /* 1 GB @ 512GB */
+    /* Must pass a single mapped page for populating bootmem_region_list. */
+    init_boot_pages(pfn_to_paddr(xenheap_mfn_start),
+                    pfn_to_paddr(xenheap_mfn_start+1));
+
+    /* Add non-xenheap memory */
+    init_boot_pages(0x8040000000, 0x80c0000000); /* 2 GB @513GB */
+
+    /* TODO Make sure Xen's own pages aren't added
+     *     -- the memory above doesn't include our relocation target.  */
+    /* TODO Handle payloads too */
+
+    /* TODO Need to find actual memory, for now use 4GB at 512GB */
+    setup_frametable_mappings(0x8000000000ULL, 0x8100000000UL);
+
+    /* Add xenheap memory */
+    init_xenheap_pages(pfn_to_paddr(xenheap_mfn_start+1),
+                       pfn_to_paddr(xenheap_mfn_end));
+
+    end_boot_allocator();
+
+    /* Setup Hyp vector base */
+    WRITE_CP32((uint32_t) hyp_traps_vector, HVBAR);
+    printk("Set hyp vector base to %"PRIx32" (expected %p)\n",
+           READ_CP32(HVBAR), hyp_traps_vector);
+
+    /* Setup Stage 2 address translation */
+    /* SH0=00, ORGN0=IRGN0=01
+     * SL0=01 (Level-1)
+     * T0SZ=(1)1000 = -8 (40 bit physical addresses)
+     */
+    WRITE_CP32(0x80002558, VTCR); isb();
+
+    softirq_init();
+    tasklet_subsys_init();
+
+    init_IRQ();
+
+    gic_init();
+
+    gic_route_irqs();
+
+    init_maintenance_interrupt();
+    init_timer_interrupt();
+
+    timer_init();
+
+    init_idle_domain();
+
+    rcu_init();
+
+    local_irq_enable();
+
+    initialize_keytable();
+
+    console_init_postirq();
+
+    do_presmp_initcalls();
+
+    for_each_present_cpu ( i )
+    {
+        if ( (num_online_cpus() < max_cpus) && !cpu_online(i) )
+        {
+            int ret = cpu_up(i);
+            if ( ret != 0 )
+                printk("Failed to bring up CPU %u (error %d)\n", i, ret);
+        }
+    }
+
+    printk("Brought up %ld CPUs\n", (long)num_online_cpus());
+    /* TODO: smp_cpus_done(); */
+
+    do_initcalls();
+
+    /* Create initial domain 0. */
+    dom0 = domain_create(0, 0, 0);
+    if ( dom0 == NULL )
+            printk("domain_create failed\n");
+    if ( (dom0 == NULL) || (alloc_dom0_vcpu0() == NULL) )
+            panic("Error creating domain 0\n");
+
+    dom0->is_privileged = 1;
+    dom0->target = NULL;
+
+    if ( construct_dom0(dom0) != 0)
+            panic("Could not set up DOM0 guest OS\n");
+
+    /* Scrub RAM that is still free and so may go to an unprivileged domain.
+       XXX too slow in simulator
+       scrub_heap_pages();
+    */
+
+    console_endboot();
+
+    /* Hide UART from DOM0 if we're using it */
+    serial_endboot();
+
+    domain_unpause_by_systemcontroller(dom0);
+
+    reset_stack_and_jump(init_done);
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 18:20:53 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 18:20:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXzdK-0008Ka-Vf; Tue, 06 Dec 2011 18:20:50 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RXzdH-0008B7-Mt
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 18:20:48 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1323195597!1577792!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDcxMjI=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9813 invoked from network); 6 Dec 2011 18:20:00 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Dec 2011 18:20:00 -0000
X-IronPort-AV: E=Sophos;i="4.71,307,1320642000"; d="scan'208";a="19721955"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Dec 2011 13:19:59 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Tue, 6 Dec 2011 13:19:59 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pB6IJEjU019549;
	Tue, 6 Dec 2011 10:19:42 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Tue, 6 Dec 2011 18:20:04 +0000
Message-ID: <1323195609-17277-20-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1112061753410.31179@kaball-desktop>
References: <alpine.DEB.2.00.1112061753410.31179@kaball-desktop>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>, Tim.Deegan@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH RFC 20/25] arm: early setup code
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
---
 xen/arch/arm/Makefile |    1 +
 xen/arch/arm/setup.c  |  206 +++++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 207 insertions(+), 0 deletions(-)
 create mode 100644 xen/arch/arm/setup.c

diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index fb8f4ee..a856f5e 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -10,6 +10,7 @@ obj-y += irq.o
 obj-y += mm.o
 obj-y += p2m.o
 obj-y += usercopy.o
+obj-y += setup.o
 
 #obj-bin-y += ....o
 
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
new file mode 100644
index 0000000..33c880e
--- /dev/null
+++ b/xen/arch/arm/setup.c
@@ -0,0 +1,206 @@
+/*
+ * xen/arch/arm/setup.c
+ *
+ * Early bringup code for an ARMv7-A with virt extensions.
+ *
+ * Tim Deegan <tim@xen.org>
+ * Copyright (c) 2011 Citrix Systems.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include <xen/config.h>
+#include <xen/compile.h>
+#include <xen/domain_page.h>
+#include <xen/types.h>
+#include <xen/string.h>
+#include <xen/serial.h>
+#include <xen/sched.h>
+#include <xen/console.h>
+#include <xen/init.h>
+#include <xen/irq.h>
+#include <xen/mm.h>
+#include <xen/softirq.h>
+#include <xen/keyhandler.h>
+#include <xen/cpu.h>
+#include <asm/page.h>
+#include <asm/current.h>
+#include <asm/setup.h>
+#include "gic.h"
+
+/* maxcpus: maximum number of CPUs to activate. */
+static unsigned int __initdata max_cpus = NR_CPUS;
+
+/* Xen stack for bringing up the first CPU. */
+unsigned char init_stack[STACK_SIZE] __attribute__((__aligned__(STACK_SIZE)));
+
+extern char __init_begin[], __init_end[], __bss_start[];
+
+static __attribute_used__ void init_done(void)
+{
+	/* TODO: free (or page-protect) the init areas.
+	   memset(__init_begin, 0xcc, __init_end - __init_begin);
+	   free_xen_data(__init_begin, __init_end);
+	*/
+    printk("Freed %ldkB init memory.\n", (long)(__init_end-__init_begin)>>10);
+
+    startup_cpu_idle_loop();
+}
+
+static void __init init_idle_domain(void)
+{
+        scheduler_init();
+        set_current(idle_vcpu[0]);
+        this_cpu(curr_vcpu) = current;
+        /* TODO: setup_idle_pagetable(); */
+}
+
+void __init start_xen(unsigned long boot_phys_offset,
+                      unsigned long arm_type,
+                      unsigned long atag_paddr)
+
+{
+    int i;
+
+    setup_pagetables(boot_phys_offset);
+
+#ifdef EARLY_UART_ADDRESS
+    /* Map the UART */
+    /* TODO Need to get device tree or command line for UART address */
+    set_fixmap(FIXMAP_CONSOLE, EARLY_UART_ADDRESS >> PAGE_SHIFT, DEV_SHARED);
+    pl011_init(0, FIXMAP_ADDR(FIXMAP_CONSOLE));
+    console_init_preirq();
+#endif
+
+    set_current((struct vcpu *)0xfffff000); /* debug sanity */
+    idle_vcpu[0] = current;
+    set_processor_id(0); /* needed early, for smp_processor_id() */
+
+    /* TODO: smp_prepare_boot_cpu(void) */
+    cpumask_set_cpu(smp_processor_id(), &cpu_online_map);
+    cpumask_set_cpu(smp_processor_id(), &cpu_present_map);
+
+    smp_prepare_cpus(max_cpus);
+
+    init_xen_time();
+
+    /* TODO: This needs some thought, as well as device-tree mapping.
+     * For testing, assume that the whole xenheap is contiguous in RAM */
+    setup_xenheap_mappings(0x8000000, 0x40000); /* 1 GB @ 512GB */
+    /* Must pass a single mapped page for populating bootmem_region_list. */
+    init_boot_pages(pfn_to_paddr(xenheap_mfn_start),
+                    pfn_to_paddr(xenheap_mfn_start+1));
+
+    /* Add non-xenheap memory */
+    init_boot_pages(0x8040000000, 0x80c0000000); /* 2 GB @513GB */
+
+    /* TODO Make sure Xen's own pages aren't added
+     *     -- the memory above doesn't include our relocation target.  */
+    /* TODO Handle payloads too */
+
+    /* TODO Need to find actual memory, for now use 4GB at 512GB */
+    setup_frametable_mappings(0x8000000000ULL, 0x8100000000UL);
+
+    /* Add xenheap memory */
+    init_xenheap_pages(pfn_to_paddr(xenheap_mfn_start+1),
+                       pfn_to_paddr(xenheap_mfn_end));
+
+    end_boot_allocator();
+
+    /* Setup Hyp vector base */
+    WRITE_CP32((uint32_t) hyp_traps_vector, HVBAR);
+    printk("Set hyp vector base to %"PRIx32" (expected %p)\n",
+           READ_CP32(HVBAR), hyp_traps_vector);
+
+    /* Setup Stage 2 address translation */
+    /* SH0=00, ORGN0=IRGN0=01
+     * SL0=01 (Level-1)
+     * T0SZ=(1)1000 = -8 (40 bit physical addresses)
+     */
+    WRITE_CP32(0x80002558, VTCR); isb();
+
+    softirq_init();
+    tasklet_subsys_init();
+
+    init_IRQ();
+
+    gic_init();
+
+    gic_route_irqs();
+
+    init_maintenance_interrupt();
+    init_timer_interrupt();
+
+    timer_init();
+
+    init_idle_domain();
+
+    rcu_init();
+
+    local_irq_enable();
+
+    initialize_keytable();
+
+    console_init_postirq();
+
+    do_presmp_initcalls();
+
+    for_each_present_cpu ( i )
+    {
+        if ( (num_online_cpus() < max_cpus) && !cpu_online(i) )
+        {
+            int ret = cpu_up(i);
+            if ( ret != 0 )
+                printk("Failed to bring up CPU %u (error %d)\n", i, ret);
+        }
+    }
+
+    printk("Brought up %ld CPUs\n", (long)num_online_cpus());
+    /* TODO: smp_cpus_done(); */
+
+    do_initcalls();
+
+    /* Create initial domain 0. */
+    dom0 = domain_create(0, 0, 0);
+    if ( dom0 == NULL )
+            printk("domain_create failed\n");
+    if ( (dom0 == NULL) || (alloc_dom0_vcpu0() == NULL) )
+            panic("Error creating domain 0\n");
+
+    dom0->is_privileged = 1;
+    dom0->target = NULL;
+
+    if ( construct_dom0(dom0) != 0)
+            panic("Could not set up DOM0 guest OS\n");
+
+    /* Scrub RAM that is still free and so may go to an unprivileged domain.
+       XXX too slow in simulator
+       scrub_heap_pages();
+    */
+
+    console_endboot();
+
+    /* Hide UART from DOM0 if we're using it */
+    serial_endboot();
+
+    domain_unpause_by_systemcontroller(dom0);
+
+    reset_stack_and_jump(init_done);
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 18:20:54 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 18:20:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXzdM-0008ML-8x; Tue, 06 Dec 2011 18:20:52 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RXzdI-0008CD-PG
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 18:20:49 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1323195594!7123966!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMzAwOTc=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21872 invoked from network); 6 Dec 2011 18:20:01 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Dec 2011 18:20:01 -0000
X-IronPort-AV: E=Sophos;i="4.71,307,1320642000"; d="scan'208";a="173120800"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Dec 2011 13:20:00 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Tue, 6 Dec 2011 13:20:00 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pB6IJEjY019549;
	Tue, 6 Dec 2011 10:19:48 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Tue, 6 Dec 2011 18:20:08 +0000
Message-ID: <1323195609-17277-24-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1112061753410.31179@kaball-desktop>
References: <alpine.DEB.2.00.1112061753410.31179@kaball-desktop>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>, Tim.Deegan@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH RFC 24/25] arm: vgic emulation
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

- emulation of the GICD interface for the guest;

- interrupt injection into the guest;

- keep track of inflight irqs using a list, ordered by priority.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
---
 xen/arch/arm/Makefile        |    1 +
 xen/arch/arm/domain.c        |    6 +
 xen/arch/arm/gic.h           |    3 +
 xen/arch/arm/io.c            |    1 +
 xen/arch/arm/io.h            |    2 +
 xen/arch/arm/irq.c           |    3 +-
 xen/arch/arm/vgic.c          |  605 ++++++++++++++++++++++++++++++++++++++++++
 xen/include/asm-arm/domain.h |   30 ++
 8 files changed, 650 insertions(+), 1 deletions(-)
 create mode 100644 xen/arch/arm/vgic.c

diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index 0e989b2..6c9b18c 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -16,6 +16,7 @@ obj-y += smpboot.o
 obj-y += smp.o
 obj-y += shutdown.o
 obj-y += traps.o
+obj-y += vgic.o
 
 #obj-bin-y += ....o
 
diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 0844b37..7e681ab 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -212,6 +212,9 @@ int vcpu_initialise(struct vcpu *v)
 {
     int rc = 0;
 
+    if ( (rc = vcpu_vgic_init(v)) != 0 )
+        return rc;
+
     return rc;
 }
 
@@ -230,6 +233,9 @@ int arch_domain_create(struct domain *d, unsigned int domcr_flags)
 
     d->max_vcpus = 8;
 
+    if ( (rc = domain_vgic_init(d)) != 0 )
+        goto fail;
+
     rc = 0;
 fail:
     return rc;
diff --git a/xen/arch/arm/gic.h b/xen/arch/arm/gic.h
index 63b6648..81c388d 100644
--- a/xen/arch/arm/gic.h
+++ b/xen/arch/arm/gic.h
@@ -121,6 +121,9 @@
 #define GICH_LR_CPUID_SHIFT     9
 #define GICH_VTR_NRLRGS         0x3f
 
+extern int domain_vgic_init(struct domain *d);
+extern int vcpu_vgic_init(struct vcpu *v);
+extern void vgic_vcpu_inject_irq(struct vcpu *v, unsigned int irq,int virtual);
 extern struct pending_irq *irq_to_pending(struct vcpu *v, unsigned int irq);
 
 extern void gic_route_irqs(void);
diff --git a/xen/arch/arm/io.c b/xen/arch/arm/io.c
index 8789705..4461225 100644
--- a/xen/arch/arm/io.c
+++ b/xen/arch/arm/io.c
@@ -24,6 +24,7 @@
 
 static const struct mmio_handler *const mmio_handlers[] =
 {
+    &vgic_distr_mmio_handler,
 };
 #define MMIO_HANDLER_NR ARRAY_SIZE(mmio_handlers)
 
diff --git a/xen/arch/arm/io.h b/xen/arch/arm/io.h
index d7847e3..8cc5ca7 100644
--- a/xen/arch/arm/io.h
+++ b/xen/arch/arm/io.h
@@ -39,6 +39,8 @@ struct mmio_handler {
     mmio_write_t write_handler;
 };
 
+extern const struct mmio_handler vgic_distr_mmio_handler;
+
 extern int handle_mmio(mmio_info_t *info);
 
 #endif
diff --git a/xen/arch/arm/irq.c b/xen/arch/arm/irq.c
index 5663762..7820310 100644
--- a/xen/arch/arm/irq.c
+++ b/xen/arch/arm/irq.c
@@ -136,7 +136,8 @@ void do_IRQ(struct cpu_user_regs *regs, unsigned int irq, int is_fiq)
 
         desc->status |= IRQ_INPROGRESS;
 
-        /* XXX: inject irq into the guest */
+        /* XXX: inject irq into all guest vcpus */
+        vgic_vcpu_inject_irq(d->vcpu[0], irq, 0);
         goto out_no_end;
     }
 
diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
new file mode 100644
index 0000000..26eae55
--- /dev/null
+++ b/xen/arch/arm/vgic.c
@@ -0,0 +1,605 @@
+/*
+ * xen/arch/arm/vgic.c
+ *
+ * ARM Virtual Generic Interrupt Controller support
+ *
+ * Ian Campbell <ian.campbell@citrix.com>
+ * Copyright (c) 2011 Citrix Systems.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include <xen/config.h>
+#include <xen/lib.h>
+#include <xen/init.h>
+#include <xen/softirq.h>
+#include <xen/irq.h>
+#include <xen/sched.h>
+
+#include <asm/current.h>
+
+#include "io.h"
+#include "gic.h"
+
+#define VGIC_DISTR_BASE_ADDRESS 0x000000002c001000
+
+#define REG(n) (n/4)
+
+/* Number of ranks of interrupt registers for a domain */
+#define DOMAIN_NR_RANKS(d) (((d)->arch.vgic.nr_lines+31)/32)
+
+/*
+ * Rank containing GICD_<FOO><n> for GICD_<FOO> with
+ * <b>-bits-per-interrupt
+ */
+static inline int REG_RANK_NR(int b, uint32_t n)
+{
+    switch ( b )
+    {
+    case 8: return n >> 3;
+    case 4: return n >> 2;
+    case 2: return n >> 1;
+    default: BUG();
+    }
+}
+
+/*
+ * Offset of GICD_<FOO><n> with its rank, for GICD_<FOO> with
+ * <b>-bits-per-interrupt.
+ */
+#define REG_RANK_INDEX(b, n) ((n) & ((b)-1))
+
+/*
+ * Returns rank corresponding to a GICD_<FOO><n> register for
+ * GICD_<FOO> with <b>-bits-per-interrupt.
+ */
+static struct vgic_irq_rank *vgic_irq_rank(struct vcpu *v, int b, int n)
+{
+    int rank = REG_RANK_NR(b, n);
+
+    if ( rank == 0 )
+        return &v->arch.vgic.private_irqs;
+    else if ( rank <= DOMAIN_NR_RANKS(v->domain) )
+        return &v->domain->arch.vgic.shared_irqs[rank - 1];
+    else
+        return NULL;
+}
+
+int domain_vgic_init(struct domain *d)
+{
+    int i;
+
+    d->arch.vgic.ctlr = 0;
+    d->arch.vgic.nr_lines = 32;
+    d->arch.vgic.shared_irqs =
+        xmalloc_array(struct vgic_irq_rank, DOMAIN_NR_RANKS(d));
+    d->arch.vgic.pending_irqs =
+        xmalloc_array(struct pending_irq,
+                d->arch.vgic.nr_lines + (32 * d->max_vcpus));
+    for (i=0; i<d->arch.vgic.nr_lines + (32 * d->max_vcpus); i++)
+        INIT_LIST_HEAD(&d->arch.vgic.pending_irqs[i].link);
+    for (i=0; i<DOMAIN_NR_RANKS(d); i++)
+        spin_lock_init(&d->arch.vgic.shared_irqs[i].lock);
+    return 0;
+}
+
+int vcpu_vgic_init(struct vcpu *v)
+{
+    int i;
+    memset(&v->arch.vgic.private_irqs, 0, sizeof(v->arch.vgic.private_irqs));
+
+    spin_lock_init(&v->arch.vgic.private_irqs.lock);
+
+    /* For SGI and PPI the target is always this CPU */
+    for ( i = 0 ; i < 8 ; i++ )
+        v->arch.vgic.private_irqs.itargets[i] =
+              (1<<(v->vcpu_id+0))
+            | (1<<(v->vcpu_id+8))
+            | (1<<(v->vcpu_id+16))
+            | (1<<(v->vcpu_id+24));
+    INIT_LIST_HEAD(&v->arch.vgic.inflight_irqs);
+    spin_lock_init(&v->arch.vgic.lock);
+
+    return 0;
+}
+
+#define vgic_lock(v)   spin_lock(&(v)->domain->arch.vgic.lock)
+#define vgic_unlock(v) spin_unlock(&(v)->domain->arch.vgic.lock)
+
+#define vgic_lock_rank(v, r) spin_lock(&(r)->lock)
+#define vgic_unlock_rank(v, r) spin_unlock(&(r)->lock)
+
+static uint32_t byte_read(uint32_t val, int sign, int offset)
+{
+    int byte = offset & 0x3;
+
+    val = val >> (8*byte);
+    if ( sign && (val & 0x80) )
+        val |= 0xffffff00;
+    else
+        val &= 0x000000ff;
+    return val;
+}
+
+static void byte_write(uint32_t *reg, uint32_t var, int offset)
+{
+    int byte = offset & 0x3;
+
+    var &= (0xff << (8*byte));
+
+    *reg &= ~(0xff << (8*byte));
+    *reg |= var;
+}
+
+static int vgic_distr_mmio_read(struct vcpu *v, mmio_info_t *info)
+{
+    struct hsr_dabt dabt = info->dabt;
+    struct cpu_user_regs *regs = guest_cpu_user_regs();
+    uint32_t *r = &regs->r0 + dabt.reg;
+    struct vgic_irq_rank *rank;
+    int offset = (int)(info->gpa - VGIC_DISTR_BASE_ADDRESS);
+    int gicd_reg = REG(offset);
+
+    switch ( gicd_reg )
+    {
+    case GICD_CTLR:
+        if ( dabt.size != 2 ) goto bad_width;
+        vgic_lock(v);
+        *r = v->domain->arch.vgic.ctlr;
+        vgic_unlock(v);
+        return 1;
+    case GICD_TYPER:
+        if ( dabt.size != 2 ) goto bad_width;
+        /* 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 );
+        vgic_unlock(v);
+        return 1;
+    case GICD_IIDR:
+        if ( dabt.size != 2 ) goto bad_width;
+        /*
+         * XXX Do we need a JEP106 manufacturer ID?
+         * Just use the physical h/w value for now
+         */
+        *r = 0x0000043b;
+        return 1;
+
+    /* Implementation defined -- read as zero */
+    case REG(0x020) ... REG(0x03c):
+        goto read_as_zero;
+
+    case GICD_IGROUPR ... GICD_IGROUPRN:
+        /* We do not implement security extensions for guests, read zero */
+        goto read_as_zero;
+
+    case GICD_ISENABLER ... GICD_ISENABLERN:
+        if ( dabt.size != 2 ) goto bad_width;
+        rank = vgic_irq_rank(v, 8, gicd_reg - GICD_ISENABLER);
+        if ( rank == NULL) goto read_as_zero;
+        vgic_lock_rank(v, rank);
+        *r = rank->ienable;
+        vgic_unlock_rank(v, rank);
+        return 1;
+
+    case GICD_ICENABLER ... GICD_ICENABLERN:
+        if ( dabt.size != 2 ) goto bad_width;
+        rank = vgic_irq_rank(v, 8, gicd_reg - GICD_ICENABLER);
+        if ( rank == NULL) goto read_as_zero;
+        vgic_lock_rank(v, rank);
+        *r = rank->ienable;
+        vgic_unlock_rank(v, rank);
+        return 1;
+
+    case GICD_ISPENDR ... GICD_ISPENDRN:
+        if ( dabt.size != 0 && dabt.size != 2 ) goto bad_width;
+        rank = vgic_irq_rank(v, 8, gicd_reg - GICD_ISPENDR);
+        if ( rank == NULL) goto read_as_zero;
+        vgic_lock_rank(v, rank);
+        *r = byte_read(rank->ipend, dabt.sign, offset);
+        vgic_unlock_rank(v, rank);
+        return 1;
+
+    case GICD_ICPENDR ... GICD_ICPENDRN:
+        if ( dabt.size != 0 && dabt.size != 2 ) goto bad_width;
+        rank = vgic_irq_rank(v, 8, gicd_reg - GICD_ICPENDR);
+        if ( rank == NULL) goto read_as_zero;
+        vgic_lock_rank(v, rank);
+        *r = byte_read(rank->ipend, dabt.sign, offset);
+        vgic_unlock_rank(v, rank);
+        return 1;
+
+    case GICD_ISACTIVER ... GICD_ISACTIVERN:
+        if ( dabt.size != 2 ) goto bad_width;
+        rank = vgic_irq_rank(v, 8, gicd_reg - GICD_ISACTIVER);
+        if ( rank == NULL) goto read_as_zero;
+        vgic_lock_rank(v, rank);
+        *r = rank->iactive;
+        vgic_unlock_rank(v, rank);
+        return 1;
+
+    case GICD_ICACTIVER ... GICD_ICACTIVERN:
+        if ( dabt.size != 2 ) goto bad_width;
+        rank = vgic_irq_rank(v, 8, gicd_reg - GICD_ICACTIVER);
+        if ( rank == NULL) goto read_as_zero;
+        vgic_lock_rank(v, rank);
+        *r = rank->iactive;
+        vgic_unlock_rank(v, rank);
+        return 1;
+
+    case GICD_ITARGETSR ... GICD_ITARGETSRN:
+        if ( dabt.size != 0 && dabt.size != 2 ) goto bad_width;
+        rank = vgic_irq_rank(v, 8, gicd_reg - GICD_ITARGETSR);
+        if ( rank == NULL) goto read_as_zero;
+
+        vgic_lock_rank(v, rank);
+        *r = rank->itargets[REG_RANK_INDEX(8, gicd_reg - GICD_ITARGETSR)];
+        if ( dabt.size == 0 )
+            *r = byte_read(*r, dabt.sign, offset);
+        vgic_unlock_rank(v, rank);
+        return 1;
+
+    case GICD_IPRIORITYR ... GICD_IPRIORITYRN:
+        if ( dabt.size != 0 && dabt.size != 2 ) goto bad_width;
+        rank = vgic_irq_rank(v, 8, gicd_reg - GICD_IPRIORITYR);
+        if ( rank == NULL) goto read_as_zero;
+
+        vgic_lock_rank(v, rank);
+        *r = rank->ipriority[REG_RANK_INDEX(8, gicd_reg - GICD_IPRIORITYR)];
+        if ( dabt.size == 0 )
+            *r = byte_read(*r, dabt.sign, offset);
+        vgic_unlock_rank(v, rank);
+        return 1;
+
+    case GICD_ICFGR ... GICD_ICFGRN:
+        if ( dabt.size != 2 ) goto bad_width;
+        rank = vgic_irq_rank(v, 2, gicd_reg - GICD_ICFGR);
+        if ( rank == NULL) goto read_as_zero;
+        vgic_lock_rank(v, rank);
+        *r = rank->icfg[REG_RANK_INDEX(2, gicd_reg - GICD_ICFGR)];
+        vgic_unlock_rank(v, rank);
+        return 0;
+
+    case GICD_NSACR ... GICD_NSACRN:
+        /* We do not implement securty extensions for guests, read zero */
+        goto read_as_zero;
+
+    case GICD_SGIR:
+        if ( dabt.size != 2 ) goto bad_width;
+        /* Write only -- read unknown */
+        *r = 0xdeadbeef;
+        return 1;
+
+    case GICD_CPENDSGIR ... GICD_CPENDSGIRN:
+        if ( dabt.size != 0 && dabt.size != 2 ) goto bad_width;
+        rank = vgic_irq_rank(v, 8, gicd_reg - GICD_CPENDSGIR);
+        if ( rank == NULL) goto read_as_zero;
+        vgic_lock_rank(v, rank);
+        *r = byte_read(rank->pendsgi, dabt.sign, offset);
+        vgic_unlock_rank(v, rank);
+        return 1;
+
+    case GICD_SPENDSGIR ... GICD_SPENDSGIRN:
+        if ( dabt.size != 0 && dabt.size != 2 ) goto bad_width;
+        rank = vgic_irq_rank(v, 8, gicd_reg - GICD_SPENDSGIR);
+        if ( rank == NULL) goto read_as_zero;
+        vgic_lock_rank(v, rank);
+        *r = byte_read(rank->pendsgi, dabt.sign, offset);
+        vgic_unlock_rank(v, rank);
+        return 1;
+
+    /* Implementation defined -- read as zero */
+    case REG(0xfd0) ... REG(0xfe4):
+        goto read_as_zero;
+
+    case GICD_ICPIDR2:
+        if ( dabt.size != 2 ) goto bad_width;
+        printk("vGICD: unhandled read from ICPIDR2\n");
+        return 0;
+
+    /* Implementation defined -- read as zero */
+    case REG(0xfec) ... REG(0xffc):
+        goto read_as_zero;
+
+    /* Reserved -- read as zero */
+    case REG(0x00c) ... REG(0x01c):
+    case REG(0x040) ... REG(0x07c):
+    case REG(0x7fc):
+    case REG(0xbfc):
+    case REG(0xf04) ... REG(0xf0c):
+    case REG(0xf30) ... REG(0xfcc):
+        goto read_as_zero;
+
+    default:
+        printk("vGICD: unhandled read r%d offset %#08x\n",
+               dabt.reg, offset);
+        return 0;
+    }
+
+bad_width:
+    printk("vGICD: bad read width %d r%d offset %#08x\n",
+           dabt.size, dabt.reg, offset);
+    domain_crash_synchronous();
+    return 0;
+
+read_as_zero:
+    if ( dabt.size != 2 ) goto bad_width;
+    *r = 0;
+    return 1;
+}
+
+static int vgic_distr_mmio_write(struct vcpu *v, mmio_info_t *info)
+{
+    struct hsr_dabt dabt = info->dabt;
+    struct cpu_user_regs *regs = guest_cpu_user_regs();
+    uint32_t *r = &regs->r0 + dabt.reg;
+    struct vgic_irq_rank *rank;
+    int offset = (int)(info->gpa - VGIC_DISTR_BASE_ADDRESS);
+    int gicd_reg = REG(offset);
+
+    switch ( gicd_reg )
+    {
+    case GICD_CTLR:
+        if ( dabt.size != 2 ) goto bad_width;
+        /* Ignore all but the enable bit */
+        v->domain->arch.vgic.ctlr = (*r) & GICD_CTL_ENABLE;
+        return 1;
+
+    /* R/O -- write ignored */
+    case GICD_TYPER:
+    case GICD_IIDR:
+        goto write_ignore;
+
+    /* Implementation defined -- write ignored */
+    case REG(0x020) ... REG(0x03c):
+        goto write_ignore;
+
+    case GICD_IGROUPR ... GICD_IGROUPRN:
+        /* We do not implement securty extensions for guests, write ignore */
+        goto write_ignore;
+
+    case GICD_ISENABLER ... GICD_ISENABLERN:
+        if ( dabt.size != 2 ) goto bad_width;
+        rank = vgic_irq_rank(v, 8, gicd_reg - GICD_ISENABLER);
+        if ( rank == NULL) goto write_ignore;
+        vgic_lock_rank(v, rank);
+        rank->ienable |= *r;
+        vgic_unlock_rank(v, rank);
+        return 1;
+
+    case GICD_ICENABLER ... GICD_ICENABLERN:
+        if ( dabt.size != 2 ) goto bad_width;
+        rank = vgic_irq_rank(v, 8, gicd_reg - GICD_ICENABLER);
+        if ( rank == NULL) goto write_ignore;
+        vgic_lock_rank(v, rank);
+        rank->ienable &= ~*r;
+        vgic_unlock_rank(v, rank);
+        return 1;
+
+    case GICD_ISPENDR ... GICD_ISPENDRN:
+        if ( dabt.size != 0 && dabt.size != 2 ) goto bad_width;
+        printk("vGICD: unhandled %s write %#"PRIx32" to ISPENDR%d\n",
+               dabt.size ? "word" : "byte", *r, gicd_reg - GICD_ISPENDR);
+        return 0;
+
+    case GICD_ICPENDR ... GICD_ICPENDRN:
+        if ( dabt.size != 0 && dabt.size != 2 ) goto bad_width;
+        printk("vGICD: unhandled %s write %#"PRIx32" to ICPENDR%d\n",
+               dabt.size ? "word" : "byte", *r, gicd_reg - GICD_ICPENDR);
+        return 0;
+
+    case GICD_ISACTIVER ... GICD_ISACTIVERN:
+        if ( dabt.size != 2 ) goto bad_width;
+        rank = vgic_irq_rank(v, 8, gicd_reg - GICD_ISACTIVER);
+        if ( rank == NULL) goto write_ignore;
+        vgic_lock_rank(v, rank);
+        rank->iactive &= ~*r;
+        vgic_unlock_rank(v, rank);
+        return 1;
+
+    case GICD_ICACTIVER ... GICD_ICACTIVERN:
+        if ( dabt.size != 2 ) goto bad_width;
+        rank = vgic_irq_rank(v, 8, gicd_reg - GICD_ICACTIVER);
+        if ( rank == NULL) goto write_ignore;
+        vgic_lock_rank(v, rank);
+        rank->iactive &= ~*r;
+        vgic_unlock_rank(v, rank);
+        return 1;
+
+    case GICD_ITARGETSR ... GICD_ITARGETSR + 7:
+        /* SGI/PPI target is read only */
+        goto write_ignore;
+
+    case GICD_ITARGETSR + 8 ... GICD_ITARGETSRN:
+        if ( dabt.size != 0 && dabt.size != 2 ) goto bad_width;
+        rank = vgic_irq_rank(v, 8, gicd_reg - GICD_ITARGETSR);
+        if ( rank == NULL) goto write_ignore;
+        vgic_lock_rank(v, rank);
+        if ( dabt.size == 2 )
+            rank->itargets[REG_RANK_INDEX(8, gicd_reg - GICD_ITARGETSR)] = *r;
+        else
+            byte_write(&rank->itargets[REG_RANK_INDEX(8, gicd_reg - GICD_ITARGETSR)],
+                       *r, offset);
+        vgic_unlock_rank(v, rank);
+        return 1;
+
+    case GICD_IPRIORITYR ... GICD_IPRIORITYRN:
+        if ( dabt.size != 0 && dabt.size != 2 ) goto bad_width;
+        rank = vgic_irq_rank(v, 8, gicd_reg - GICD_IPRIORITYR);
+        if ( rank == NULL) goto write_ignore;
+        vgic_lock_rank(v, rank);
+        if ( dabt.size == 2 )
+            rank->ipriority[REG_RANK_INDEX(8, gicd_reg - GICD_IPRIORITYR)] = *r;
+        else
+            byte_write(&rank->ipriority[REG_RANK_INDEX(8, gicd_reg - GICD_IPRIORITYR)],
+                       *r, offset);
+        vgic_unlock_rank(v, rank);
+        return 1;
+
+    case GICD_ICFGR: /* SGIs */
+        goto write_ignore;
+    case GICD_ICFGR + 1: /* PPIs */
+        /* It is implementation defined if these are writeable. We chose not */
+        goto write_ignore;
+    case GICD_ICFGR + 2 ... GICD_ICFGRN: /* SPIs */
+        if ( dabt.size != 2 ) goto bad_width;
+        rank = vgic_irq_rank(v, 2, gicd_reg - GICD_ICFGR);
+        vgic_lock_rank(v, rank);
+        if ( rank == NULL) goto write_ignore;
+        rank->icfg[REG_RANK_INDEX(2, gicd_reg - GICD_ICFGR)] = *r;
+        vgic_unlock_rank(v, rank);
+        return 1;
+
+    case GICD_NSACR ... GICD_NSACRN:
+        /* We do not implement securty extensions for guests, write ignore */
+        goto write_ignore;
+
+    case GICD_SGIR:
+        if ( dabt.size != 2 ) goto bad_width;
+        printk("vGICD: unhandled write %#"PRIx32" to ICFGR%d\n",
+               *r, gicd_reg - GICD_ICFGR);
+        return 0;
+
+    case GICD_CPENDSGIR ... GICD_CPENDSGIRN:
+        if ( dabt.size != 0 && dabt.size != 2 ) goto bad_width;
+        printk("vGICD: unhandled %s write %#"PRIx32" to ICPENDSGIR%d\n",
+               dabt.size ? "word" : "byte", *r, gicd_reg - GICD_CPENDSGIR);
+        return 0;
+
+    case GICD_SPENDSGIR ... GICD_SPENDSGIRN:
+        if ( dabt.size != 0 && dabt.size != 2 ) goto bad_width;
+        printk("vGICD: unhandled %s write %#"PRIx32" to ISPENDSGIR%d\n",
+               dabt.size ? "word" : "byte", *r, gicd_reg - GICD_SPENDSGIR);
+        return 0;
+
+    /* Implementation defined -- write ignored */
+    case REG(0xfd0) ... REG(0xfe4):
+        goto write_ignore;
+
+    /* R/O -- write ignore */
+    case GICD_ICPIDR2:
+        goto write_ignore;
+
+    /* Implementation defined -- write ignored */
+    case REG(0xfec) ... REG(0xffc):
+        goto write_ignore;
+
+    /* Reserved -- write ignored */
+    case REG(0x00c) ... REG(0x01c):
+    case REG(0x040) ... REG(0x07c):
+    case REG(0x7fc):
+    case REG(0xbfc):
+    case REG(0xf04) ... REG(0xf0c):
+    case REG(0xf30) ... REG(0xfcc):
+        goto write_ignore;
+
+    default:
+        printk("vGICD: unhandled write r%d=%"PRIx32" offset %#08x\n",
+               dabt.reg, *r, offset);
+        return 0;
+    }
+
+bad_width:
+    printk("vGICD: bad write width %d r%d=%"PRIx32" offset %#08x\n",
+           dabt.size, dabt.reg, *r, offset);
+    domain_crash_synchronous();
+    return 0;
+
+write_ignore:
+    if ( dabt.size != 2 ) goto bad_width;
+    return 0;
+}
+
+static int vgic_distr_mmio_check(struct vcpu *v, paddr_t addr)
+{
+    return addr >= VGIC_DISTR_BASE_ADDRESS && addr < (VGIC_DISTR_BASE_ADDRESS+PAGE_SIZE);
+}
+
+const struct mmio_handler vgic_distr_mmio_handler = {
+    .check_handler = vgic_distr_mmio_check,
+    .read_handler  = vgic_distr_mmio_read,
+    .write_handler = vgic_distr_mmio_write,
+};
+
+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
+     * are used for SPIs; the rests are used for per cpu irqs */
+    if ( irq < 32 )
+        n = &v->domain->arch.vgic.pending_irqs[irq + (v->vcpu_id * 32)
+            + v->domain->arch.vgic.nr_lines];
+    else
+        n = &v->domain->arch.vgic.pending_irqs[irq - 32];
+    return n;
+}
+
+void vgic_vcpu_inject_irq(struct vcpu *v, unsigned int irq, int virtual)
+{
+    int idx = irq >> 2, byte = irq & 0x3;
+    uint8_t priority;
+    struct vgic_irq_rank *rank = vgic_irq_rank(v, 8, idx);
+    struct pending_irq *iter, *n = irq_to_pending(v, irq);
+
+    /* irq still pending */
+    if (!list_empty(&n->link))
+        return;
+
+    priority = byte_read(rank->ipriority[REG_RANK_INDEX(8, idx)], 0, byte);
+
+    n->irq = irq;
+    n->priority = priority;
+    if (!virtual)
+        n->desc = irq_to_desc(irq);
+    else
+        n->desc = NULL;
+
+    gic_set_guest_irq(irq, GICH_LR_PENDING, priority);
+
+    spin_lock(&v->arch.vgic.lock);
+    list_for_each_entry ( iter, &v->arch.vgic.inflight_irqs, link )
+    {
+        if ( iter->priority < priority )
+        {
+            list_add_tail(&n->link, &iter->link);
+            spin_unlock(&v->arch.vgic.lock);
+            return;
+        }
+    }
+    list_add(&n->link, &v->arch.vgic.inflight_irqs);
+    spin_unlock(&v->arch.vgic.lock);
+    /* we have a new higher priority irq, inject it into the guest */
+    cpu_raise_softirq(v->processor, VGIC_SOFTIRQ);
+}
+
+static void vgic_softirq(void)
+{
+    if (list_empty(&current->arch.vgic.inflight_irqs))
+        return;
+
+    gic_inject_irq_start();
+}
+
+static int __init init_vgic_softirq(void)
+{
+    open_softirq(VGIC_SOFTIRQ, vgic_softirq);
+    return 0;
+}
+__initcall(init_vgic_softirq);
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
+
diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
index 2226a24..2cd0bd3 100644
--- a/xen/include/asm-arm/domain.h
+++ b/xen/include/asm-arm/domain.h
@@ -6,6 +6,15 @@
 #include <asm/page.h>
 #include <asm/p2m.h>
 
+/* Represents state corresponding to a block of 32 interrupts */
+struct vgic_irq_rank {
+    spinlock_t lock; /* Covers access to all other members of this struct */
+    uint32_t ienable, iactive, ipend, pendsgi;
+    uint32_t icfg[2];
+    uint32_t ipriority[8];
+    uint32_t itargets[8];
+};
+
 struct pending_irq
 {
     int irq;
@@ -18,6 +27,22 @@ struct arch_domain
 {
     struct p2m_domain p2m;
 
+    struct {
+        /*
+         * Covers access to other members of this struct _except_ for
+         * shared_irqs where each member contains its own locking.
+         *
+         * If both class of lock is required then this lock must be
+         * taken first. If multiple rank locks are required (including
+         * the per-vcpu private_irqs rank) then they must be taken in
+         * rank order.
+         */
+        spinlock_t lock;
+        int ctlr;
+        int nr_lines;
+        struct vgic_irq_rank *shared_irqs;
+        struct pending_irq *pending_irqs;
+    } vgic;
 }  __cacheline_aligned;
 
 struct arch_vcpu
@@ -27,6 +52,11 @@ struct arch_vcpu
     uint32_t sctlr;
     uint32_t ttbr0, ttbr1, ttbcr;
 
+    struct {
+        struct vgic_irq_rank private_irqs;
+        struct list_head inflight_irqs;
+        spinlock_t lock;
+    } vgic;
 }  __cacheline_aligned;
 
 void vcpu_show_execution_state(struct vcpu *);
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 18:20:54 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 18:20:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXzdM-0008ML-8x; Tue, 06 Dec 2011 18:20:52 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RXzdI-0008CD-PG
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 18:20:49 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1323195594!7123966!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMzAwOTc=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21872 invoked from network); 6 Dec 2011 18:20:01 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Dec 2011 18:20:01 -0000
X-IronPort-AV: E=Sophos;i="4.71,307,1320642000"; d="scan'208";a="173120800"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Dec 2011 13:20:00 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Tue, 6 Dec 2011 13:20:00 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pB6IJEjY019549;
	Tue, 6 Dec 2011 10:19:48 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Tue, 6 Dec 2011 18:20:08 +0000
Message-ID: <1323195609-17277-24-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1112061753410.31179@kaball-desktop>
References: <alpine.DEB.2.00.1112061753410.31179@kaball-desktop>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>, Tim.Deegan@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH RFC 24/25] arm: vgic emulation
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

- emulation of the GICD interface for the guest;

- interrupt injection into the guest;

- keep track of inflight irqs using a list, ordered by priority.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
---
 xen/arch/arm/Makefile        |    1 +
 xen/arch/arm/domain.c        |    6 +
 xen/arch/arm/gic.h           |    3 +
 xen/arch/arm/io.c            |    1 +
 xen/arch/arm/io.h            |    2 +
 xen/arch/arm/irq.c           |    3 +-
 xen/arch/arm/vgic.c          |  605 ++++++++++++++++++++++++++++++++++++++++++
 xen/include/asm-arm/domain.h |   30 ++
 8 files changed, 650 insertions(+), 1 deletions(-)
 create mode 100644 xen/arch/arm/vgic.c

diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index 0e989b2..6c9b18c 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -16,6 +16,7 @@ obj-y += smpboot.o
 obj-y += smp.o
 obj-y += shutdown.o
 obj-y += traps.o
+obj-y += vgic.o
 
 #obj-bin-y += ....o
 
diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 0844b37..7e681ab 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -212,6 +212,9 @@ int vcpu_initialise(struct vcpu *v)
 {
     int rc = 0;
 
+    if ( (rc = vcpu_vgic_init(v)) != 0 )
+        return rc;
+
     return rc;
 }
 
@@ -230,6 +233,9 @@ int arch_domain_create(struct domain *d, unsigned int domcr_flags)
 
     d->max_vcpus = 8;
 
+    if ( (rc = domain_vgic_init(d)) != 0 )
+        goto fail;
+
     rc = 0;
 fail:
     return rc;
diff --git a/xen/arch/arm/gic.h b/xen/arch/arm/gic.h
index 63b6648..81c388d 100644
--- a/xen/arch/arm/gic.h
+++ b/xen/arch/arm/gic.h
@@ -121,6 +121,9 @@
 #define GICH_LR_CPUID_SHIFT     9
 #define GICH_VTR_NRLRGS         0x3f
 
+extern int domain_vgic_init(struct domain *d);
+extern int vcpu_vgic_init(struct vcpu *v);
+extern void vgic_vcpu_inject_irq(struct vcpu *v, unsigned int irq,int virtual);
 extern struct pending_irq *irq_to_pending(struct vcpu *v, unsigned int irq);
 
 extern void gic_route_irqs(void);
diff --git a/xen/arch/arm/io.c b/xen/arch/arm/io.c
index 8789705..4461225 100644
--- a/xen/arch/arm/io.c
+++ b/xen/arch/arm/io.c
@@ -24,6 +24,7 @@
 
 static const struct mmio_handler *const mmio_handlers[] =
 {
+    &vgic_distr_mmio_handler,
 };
 #define MMIO_HANDLER_NR ARRAY_SIZE(mmio_handlers)
 
diff --git a/xen/arch/arm/io.h b/xen/arch/arm/io.h
index d7847e3..8cc5ca7 100644
--- a/xen/arch/arm/io.h
+++ b/xen/arch/arm/io.h
@@ -39,6 +39,8 @@ struct mmio_handler {
     mmio_write_t write_handler;
 };
 
+extern const struct mmio_handler vgic_distr_mmio_handler;
+
 extern int handle_mmio(mmio_info_t *info);
 
 #endif
diff --git a/xen/arch/arm/irq.c b/xen/arch/arm/irq.c
index 5663762..7820310 100644
--- a/xen/arch/arm/irq.c
+++ b/xen/arch/arm/irq.c
@@ -136,7 +136,8 @@ void do_IRQ(struct cpu_user_regs *regs, unsigned int irq, int is_fiq)
 
         desc->status |= IRQ_INPROGRESS;
 
-        /* XXX: inject irq into the guest */
+        /* XXX: inject irq into all guest vcpus */
+        vgic_vcpu_inject_irq(d->vcpu[0], irq, 0);
         goto out_no_end;
     }
 
diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
new file mode 100644
index 0000000..26eae55
--- /dev/null
+++ b/xen/arch/arm/vgic.c
@@ -0,0 +1,605 @@
+/*
+ * xen/arch/arm/vgic.c
+ *
+ * ARM Virtual Generic Interrupt Controller support
+ *
+ * Ian Campbell <ian.campbell@citrix.com>
+ * Copyright (c) 2011 Citrix Systems.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include <xen/config.h>
+#include <xen/lib.h>
+#include <xen/init.h>
+#include <xen/softirq.h>
+#include <xen/irq.h>
+#include <xen/sched.h>
+
+#include <asm/current.h>
+
+#include "io.h"
+#include "gic.h"
+
+#define VGIC_DISTR_BASE_ADDRESS 0x000000002c001000
+
+#define REG(n) (n/4)
+
+/* Number of ranks of interrupt registers for a domain */
+#define DOMAIN_NR_RANKS(d) (((d)->arch.vgic.nr_lines+31)/32)
+
+/*
+ * Rank containing GICD_<FOO><n> for GICD_<FOO> with
+ * <b>-bits-per-interrupt
+ */
+static inline int REG_RANK_NR(int b, uint32_t n)
+{
+    switch ( b )
+    {
+    case 8: return n >> 3;
+    case 4: return n >> 2;
+    case 2: return n >> 1;
+    default: BUG();
+    }
+}
+
+/*
+ * Offset of GICD_<FOO><n> with its rank, for GICD_<FOO> with
+ * <b>-bits-per-interrupt.
+ */
+#define REG_RANK_INDEX(b, n) ((n) & ((b)-1))
+
+/*
+ * Returns rank corresponding to a GICD_<FOO><n> register for
+ * GICD_<FOO> with <b>-bits-per-interrupt.
+ */
+static struct vgic_irq_rank *vgic_irq_rank(struct vcpu *v, int b, int n)
+{
+    int rank = REG_RANK_NR(b, n);
+
+    if ( rank == 0 )
+        return &v->arch.vgic.private_irqs;
+    else if ( rank <= DOMAIN_NR_RANKS(v->domain) )
+        return &v->domain->arch.vgic.shared_irqs[rank - 1];
+    else
+        return NULL;
+}
+
+int domain_vgic_init(struct domain *d)
+{
+    int i;
+
+    d->arch.vgic.ctlr = 0;
+    d->arch.vgic.nr_lines = 32;
+    d->arch.vgic.shared_irqs =
+        xmalloc_array(struct vgic_irq_rank, DOMAIN_NR_RANKS(d));
+    d->arch.vgic.pending_irqs =
+        xmalloc_array(struct pending_irq,
+                d->arch.vgic.nr_lines + (32 * d->max_vcpus));
+    for (i=0; i<d->arch.vgic.nr_lines + (32 * d->max_vcpus); i++)
+        INIT_LIST_HEAD(&d->arch.vgic.pending_irqs[i].link);
+    for (i=0; i<DOMAIN_NR_RANKS(d); i++)
+        spin_lock_init(&d->arch.vgic.shared_irqs[i].lock);
+    return 0;
+}
+
+int vcpu_vgic_init(struct vcpu *v)
+{
+    int i;
+    memset(&v->arch.vgic.private_irqs, 0, sizeof(v->arch.vgic.private_irqs));
+
+    spin_lock_init(&v->arch.vgic.private_irqs.lock);
+
+    /* For SGI and PPI the target is always this CPU */
+    for ( i = 0 ; i < 8 ; i++ )
+        v->arch.vgic.private_irqs.itargets[i] =
+              (1<<(v->vcpu_id+0))
+            | (1<<(v->vcpu_id+8))
+            | (1<<(v->vcpu_id+16))
+            | (1<<(v->vcpu_id+24));
+    INIT_LIST_HEAD(&v->arch.vgic.inflight_irqs);
+    spin_lock_init(&v->arch.vgic.lock);
+
+    return 0;
+}
+
+#define vgic_lock(v)   spin_lock(&(v)->domain->arch.vgic.lock)
+#define vgic_unlock(v) spin_unlock(&(v)->domain->arch.vgic.lock)
+
+#define vgic_lock_rank(v, r) spin_lock(&(r)->lock)
+#define vgic_unlock_rank(v, r) spin_unlock(&(r)->lock)
+
+static uint32_t byte_read(uint32_t val, int sign, int offset)
+{
+    int byte = offset & 0x3;
+
+    val = val >> (8*byte);
+    if ( sign && (val & 0x80) )
+        val |= 0xffffff00;
+    else
+        val &= 0x000000ff;
+    return val;
+}
+
+static void byte_write(uint32_t *reg, uint32_t var, int offset)
+{
+    int byte = offset & 0x3;
+
+    var &= (0xff << (8*byte));
+
+    *reg &= ~(0xff << (8*byte));
+    *reg |= var;
+}
+
+static int vgic_distr_mmio_read(struct vcpu *v, mmio_info_t *info)
+{
+    struct hsr_dabt dabt = info->dabt;
+    struct cpu_user_regs *regs = guest_cpu_user_regs();
+    uint32_t *r = &regs->r0 + dabt.reg;
+    struct vgic_irq_rank *rank;
+    int offset = (int)(info->gpa - VGIC_DISTR_BASE_ADDRESS);
+    int gicd_reg = REG(offset);
+
+    switch ( gicd_reg )
+    {
+    case GICD_CTLR:
+        if ( dabt.size != 2 ) goto bad_width;
+        vgic_lock(v);
+        *r = v->domain->arch.vgic.ctlr;
+        vgic_unlock(v);
+        return 1;
+    case GICD_TYPER:
+        if ( dabt.size != 2 ) goto bad_width;
+        /* 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 );
+        vgic_unlock(v);
+        return 1;
+    case GICD_IIDR:
+        if ( dabt.size != 2 ) goto bad_width;
+        /*
+         * XXX Do we need a JEP106 manufacturer ID?
+         * Just use the physical h/w value for now
+         */
+        *r = 0x0000043b;
+        return 1;
+
+    /* Implementation defined -- read as zero */
+    case REG(0x020) ... REG(0x03c):
+        goto read_as_zero;
+
+    case GICD_IGROUPR ... GICD_IGROUPRN:
+        /* We do not implement security extensions for guests, read zero */
+        goto read_as_zero;
+
+    case GICD_ISENABLER ... GICD_ISENABLERN:
+        if ( dabt.size != 2 ) goto bad_width;
+        rank = vgic_irq_rank(v, 8, gicd_reg - GICD_ISENABLER);
+        if ( rank == NULL) goto read_as_zero;
+        vgic_lock_rank(v, rank);
+        *r = rank->ienable;
+        vgic_unlock_rank(v, rank);
+        return 1;
+
+    case GICD_ICENABLER ... GICD_ICENABLERN:
+        if ( dabt.size != 2 ) goto bad_width;
+        rank = vgic_irq_rank(v, 8, gicd_reg - GICD_ICENABLER);
+        if ( rank == NULL) goto read_as_zero;
+        vgic_lock_rank(v, rank);
+        *r = rank->ienable;
+        vgic_unlock_rank(v, rank);
+        return 1;
+
+    case GICD_ISPENDR ... GICD_ISPENDRN:
+        if ( dabt.size != 0 && dabt.size != 2 ) goto bad_width;
+        rank = vgic_irq_rank(v, 8, gicd_reg - GICD_ISPENDR);
+        if ( rank == NULL) goto read_as_zero;
+        vgic_lock_rank(v, rank);
+        *r = byte_read(rank->ipend, dabt.sign, offset);
+        vgic_unlock_rank(v, rank);
+        return 1;
+
+    case GICD_ICPENDR ... GICD_ICPENDRN:
+        if ( dabt.size != 0 && dabt.size != 2 ) goto bad_width;
+        rank = vgic_irq_rank(v, 8, gicd_reg - GICD_ICPENDR);
+        if ( rank == NULL) goto read_as_zero;
+        vgic_lock_rank(v, rank);
+        *r = byte_read(rank->ipend, dabt.sign, offset);
+        vgic_unlock_rank(v, rank);
+        return 1;
+
+    case GICD_ISACTIVER ... GICD_ISACTIVERN:
+        if ( dabt.size != 2 ) goto bad_width;
+        rank = vgic_irq_rank(v, 8, gicd_reg - GICD_ISACTIVER);
+        if ( rank == NULL) goto read_as_zero;
+        vgic_lock_rank(v, rank);
+        *r = rank->iactive;
+        vgic_unlock_rank(v, rank);
+        return 1;
+
+    case GICD_ICACTIVER ... GICD_ICACTIVERN:
+        if ( dabt.size != 2 ) goto bad_width;
+        rank = vgic_irq_rank(v, 8, gicd_reg - GICD_ICACTIVER);
+        if ( rank == NULL) goto read_as_zero;
+        vgic_lock_rank(v, rank);
+        *r = rank->iactive;
+        vgic_unlock_rank(v, rank);
+        return 1;
+
+    case GICD_ITARGETSR ... GICD_ITARGETSRN:
+        if ( dabt.size != 0 && dabt.size != 2 ) goto bad_width;
+        rank = vgic_irq_rank(v, 8, gicd_reg - GICD_ITARGETSR);
+        if ( rank == NULL) goto read_as_zero;
+
+        vgic_lock_rank(v, rank);
+        *r = rank->itargets[REG_RANK_INDEX(8, gicd_reg - GICD_ITARGETSR)];
+        if ( dabt.size == 0 )
+            *r = byte_read(*r, dabt.sign, offset);
+        vgic_unlock_rank(v, rank);
+        return 1;
+
+    case GICD_IPRIORITYR ... GICD_IPRIORITYRN:
+        if ( dabt.size != 0 && dabt.size != 2 ) goto bad_width;
+        rank = vgic_irq_rank(v, 8, gicd_reg - GICD_IPRIORITYR);
+        if ( rank == NULL) goto read_as_zero;
+
+        vgic_lock_rank(v, rank);
+        *r = rank->ipriority[REG_RANK_INDEX(8, gicd_reg - GICD_IPRIORITYR)];
+        if ( dabt.size == 0 )
+            *r = byte_read(*r, dabt.sign, offset);
+        vgic_unlock_rank(v, rank);
+        return 1;
+
+    case GICD_ICFGR ... GICD_ICFGRN:
+        if ( dabt.size != 2 ) goto bad_width;
+        rank = vgic_irq_rank(v, 2, gicd_reg - GICD_ICFGR);
+        if ( rank == NULL) goto read_as_zero;
+        vgic_lock_rank(v, rank);
+        *r = rank->icfg[REG_RANK_INDEX(2, gicd_reg - GICD_ICFGR)];
+        vgic_unlock_rank(v, rank);
+        return 0;
+
+    case GICD_NSACR ... GICD_NSACRN:
+        /* We do not implement securty extensions for guests, read zero */
+        goto read_as_zero;
+
+    case GICD_SGIR:
+        if ( dabt.size != 2 ) goto bad_width;
+        /* Write only -- read unknown */
+        *r = 0xdeadbeef;
+        return 1;
+
+    case GICD_CPENDSGIR ... GICD_CPENDSGIRN:
+        if ( dabt.size != 0 && dabt.size != 2 ) goto bad_width;
+        rank = vgic_irq_rank(v, 8, gicd_reg - GICD_CPENDSGIR);
+        if ( rank == NULL) goto read_as_zero;
+        vgic_lock_rank(v, rank);
+        *r = byte_read(rank->pendsgi, dabt.sign, offset);
+        vgic_unlock_rank(v, rank);
+        return 1;
+
+    case GICD_SPENDSGIR ... GICD_SPENDSGIRN:
+        if ( dabt.size != 0 && dabt.size != 2 ) goto bad_width;
+        rank = vgic_irq_rank(v, 8, gicd_reg - GICD_SPENDSGIR);
+        if ( rank == NULL) goto read_as_zero;
+        vgic_lock_rank(v, rank);
+        *r = byte_read(rank->pendsgi, dabt.sign, offset);
+        vgic_unlock_rank(v, rank);
+        return 1;
+
+    /* Implementation defined -- read as zero */
+    case REG(0xfd0) ... REG(0xfe4):
+        goto read_as_zero;
+
+    case GICD_ICPIDR2:
+        if ( dabt.size != 2 ) goto bad_width;
+        printk("vGICD: unhandled read from ICPIDR2\n");
+        return 0;
+
+    /* Implementation defined -- read as zero */
+    case REG(0xfec) ... REG(0xffc):
+        goto read_as_zero;
+
+    /* Reserved -- read as zero */
+    case REG(0x00c) ... REG(0x01c):
+    case REG(0x040) ... REG(0x07c):
+    case REG(0x7fc):
+    case REG(0xbfc):
+    case REG(0xf04) ... REG(0xf0c):
+    case REG(0xf30) ... REG(0xfcc):
+        goto read_as_zero;
+
+    default:
+        printk("vGICD: unhandled read r%d offset %#08x\n",
+               dabt.reg, offset);
+        return 0;
+    }
+
+bad_width:
+    printk("vGICD: bad read width %d r%d offset %#08x\n",
+           dabt.size, dabt.reg, offset);
+    domain_crash_synchronous();
+    return 0;
+
+read_as_zero:
+    if ( dabt.size != 2 ) goto bad_width;
+    *r = 0;
+    return 1;
+}
+
+static int vgic_distr_mmio_write(struct vcpu *v, mmio_info_t *info)
+{
+    struct hsr_dabt dabt = info->dabt;
+    struct cpu_user_regs *regs = guest_cpu_user_regs();
+    uint32_t *r = &regs->r0 + dabt.reg;
+    struct vgic_irq_rank *rank;
+    int offset = (int)(info->gpa - VGIC_DISTR_BASE_ADDRESS);
+    int gicd_reg = REG(offset);
+
+    switch ( gicd_reg )
+    {
+    case GICD_CTLR:
+        if ( dabt.size != 2 ) goto bad_width;
+        /* Ignore all but the enable bit */
+        v->domain->arch.vgic.ctlr = (*r) & GICD_CTL_ENABLE;
+        return 1;
+
+    /* R/O -- write ignored */
+    case GICD_TYPER:
+    case GICD_IIDR:
+        goto write_ignore;
+
+    /* Implementation defined -- write ignored */
+    case REG(0x020) ... REG(0x03c):
+        goto write_ignore;
+
+    case GICD_IGROUPR ... GICD_IGROUPRN:
+        /* We do not implement securty extensions for guests, write ignore */
+        goto write_ignore;
+
+    case GICD_ISENABLER ... GICD_ISENABLERN:
+        if ( dabt.size != 2 ) goto bad_width;
+        rank = vgic_irq_rank(v, 8, gicd_reg - GICD_ISENABLER);
+        if ( rank == NULL) goto write_ignore;
+        vgic_lock_rank(v, rank);
+        rank->ienable |= *r;
+        vgic_unlock_rank(v, rank);
+        return 1;
+
+    case GICD_ICENABLER ... GICD_ICENABLERN:
+        if ( dabt.size != 2 ) goto bad_width;
+        rank = vgic_irq_rank(v, 8, gicd_reg - GICD_ICENABLER);
+        if ( rank == NULL) goto write_ignore;
+        vgic_lock_rank(v, rank);
+        rank->ienable &= ~*r;
+        vgic_unlock_rank(v, rank);
+        return 1;
+
+    case GICD_ISPENDR ... GICD_ISPENDRN:
+        if ( dabt.size != 0 && dabt.size != 2 ) goto bad_width;
+        printk("vGICD: unhandled %s write %#"PRIx32" to ISPENDR%d\n",
+               dabt.size ? "word" : "byte", *r, gicd_reg - GICD_ISPENDR);
+        return 0;
+
+    case GICD_ICPENDR ... GICD_ICPENDRN:
+        if ( dabt.size != 0 && dabt.size != 2 ) goto bad_width;
+        printk("vGICD: unhandled %s write %#"PRIx32" to ICPENDR%d\n",
+               dabt.size ? "word" : "byte", *r, gicd_reg - GICD_ICPENDR);
+        return 0;
+
+    case GICD_ISACTIVER ... GICD_ISACTIVERN:
+        if ( dabt.size != 2 ) goto bad_width;
+        rank = vgic_irq_rank(v, 8, gicd_reg - GICD_ISACTIVER);
+        if ( rank == NULL) goto write_ignore;
+        vgic_lock_rank(v, rank);
+        rank->iactive &= ~*r;
+        vgic_unlock_rank(v, rank);
+        return 1;
+
+    case GICD_ICACTIVER ... GICD_ICACTIVERN:
+        if ( dabt.size != 2 ) goto bad_width;
+        rank = vgic_irq_rank(v, 8, gicd_reg - GICD_ICACTIVER);
+        if ( rank == NULL) goto write_ignore;
+        vgic_lock_rank(v, rank);
+        rank->iactive &= ~*r;
+        vgic_unlock_rank(v, rank);
+        return 1;
+
+    case GICD_ITARGETSR ... GICD_ITARGETSR + 7:
+        /* SGI/PPI target is read only */
+        goto write_ignore;
+
+    case GICD_ITARGETSR + 8 ... GICD_ITARGETSRN:
+        if ( dabt.size != 0 && dabt.size != 2 ) goto bad_width;
+        rank = vgic_irq_rank(v, 8, gicd_reg - GICD_ITARGETSR);
+        if ( rank == NULL) goto write_ignore;
+        vgic_lock_rank(v, rank);
+        if ( dabt.size == 2 )
+            rank->itargets[REG_RANK_INDEX(8, gicd_reg - GICD_ITARGETSR)] = *r;
+        else
+            byte_write(&rank->itargets[REG_RANK_INDEX(8, gicd_reg - GICD_ITARGETSR)],
+                       *r, offset);
+        vgic_unlock_rank(v, rank);
+        return 1;
+
+    case GICD_IPRIORITYR ... GICD_IPRIORITYRN:
+        if ( dabt.size != 0 && dabt.size != 2 ) goto bad_width;
+        rank = vgic_irq_rank(v, 8, gicd_reg - GICD_IPRIORITYR);
+        if ( rank == NULL) goto write_ignore;
+        vgic_lock_rank(v, rank);
+        if ( dabt.size == 2 )
+            rank->ipriority[REG_RANK_INDEX(8, gicd_reg - GICD_IPRIORITYR)] = *r;
+        else
+            byte_write(&rank->ipriority[REG_RANK_INDEX(8, gicd_reg - GICD_IPRIORITYR)],
+                       *r, offset);
+        vgic_unlock_rank(v, rank);
+        return 1;
+
+    case GICD_ICFGR: /* SGIs */
+        goto write_ignore;
+    case GICD_ICFGR + 1: /* PPIs */
+        /* It is implementation defined if these are writeable. We chose not */
+        goto write_ignore;
+    case GICD_ICFGR + 2 ... GICD_ICFGRN: /* SPIs */
+        if ( dabt.size != 2 ) goto bad_width;
+        rank = vgic_irq_rank(v, 2, gicd_reg - GICD_ICFGR);
+        vgic_lock_rank(v, rank);
+        if ( rank == NULL) goto write_ignore;
+        rank->icfg[REG_RANK_INDEX(2, gicd_reg - GICD_ICFGR)] = *r;
+        vgic_unlock_rank(v, rank);
+        return 1;
+
+    case GICD_NSACR ... GICD_NSACRN:
+        /* We do not implement securty extensions for guests, write ignore */
+        goto write_ignore;
+
+    case GICD_SGIR:
+        if ( dabt.size != 2 ) goto bad_width;
+        printk("vGICD: unhandled write %#"PRIx32" to ICFGR%d\n",
+               *r, gicd_reg - GICD_ICFGR);
+        return 0;
+
+    case GICD_CPENDSGIR ... GICD_CPENDSGIRN:
+        if ( dabt.size != 0 && dabt.size != 2 ) goto bad_width;
+        printk("vGICD: unhandled %s write %#"PRIx32" to ICPENDSGIR%d\n",
+               dabt.size ? "word" : "byte", *r, gicd_reg - GICD_CPENDSGIR);
+        return 0;
+
+    case GICD_SPENDSGIR ... GICD_SPENDSGIRN:
+        if ( dabt.size != 0 && dabt.size != 2 ) goto bad_width;
+        printk("vGICD: unhandled %s write %#"PRIx32" to ISPENDSGIR%d\n",
+               dabt.size ? "word" : "byte", *r, gicd_reg - GICD_SPENDSGIR);
+        return 0;
+
+    /* Implementation defined -- write ignored */
+    case REG(0xfd0) ... REG(0xfe4):
+        goto write_ignore;
+
+    /* R/O -- write ignore */
+    case GICD_ICPIDR2:
+        goto write_ignore;
+
+    /* Implementation defined -- write ignored */
+    case REG(0xfec) ... REG(0xffc):
+        goto write_ignore;
+
+    /* Reserved -- write ignored */
+    case REG(0x00c) ... REG(0x01c):
+    case REG(0x040) ... REG(0x07c):
+    case REG(0x7fc):
+    case REG(0xbfc):
+    case REG(0xf04) ... REG(0xf0c):
+    case REG(0xf30) ... REG(0xfcc):
+        goto write_ignore;
+
+    default:
+        printk("vGICD: unhandled write r%d=%"PRIx32" offset %#08x\n",
+               dabt.reg, *r, offset);
+        return 0;
+    }
+
+bad_width:
+    printk("vGICD: bad write width %d r%d=%"PRIx32" offset %#08x\n",
+           dabt.size, dabt.reg, *r, offset);
+    domain_crash_synchronous();
+    return 0;
+
+write_ignore:
+    if ( dabt.size != 2 ) goto bad_width;
+    return 0;
+}
+
+static int vgic_distr_mmio_check(struct vcpu *v, paddr_t addr)
+{
+    return addr >= VGIC_DISTR_BASE_ADDRESS && addr < (VGIC_DISTR_BASE_ADDRESS+PAGE_SIZE);
+}
+
+const struct mmio_handler vgic_distr_mmio_handler = {
+    .check_handler = vgic_distr_mmio_check,
+    .read_handler  = vgic_distr_mmio_read,
+    .write_handler = vgic_distr_mmio_write,
+};
+
+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
+     * are used for SPIs; the rests are used for per cpu irqs */
+    if ( irq < 32 )
+        n = &v->domain->arch.vgic.pending_irqs[irq + (v->vcpu_id * 32)
+            + v->domain->arch.vgic.nr_lines];
+    else
+        n = &v->domain->arch.vgic.pending_irqs[irq - 32];
+    return n;
+}
+
+void vgic_vcpu_inject_irq(struct vcpu *v, unsigned int irq, int virtual)
+{
+    int idx = irq >> 2, byte = irq & 0x3;
+    uint8_t priority;
+    struct vgic_irq_rank *rank = vgic_irq_rank(v, 8, idx);
+    struct pending_irq *iter, *n = irq_to_pending(v, irq);
+
+    /* irq still pending */
+    if (!list_empty(&n->link))
+        return;
+
+    priority = byte_read(rank->ipriority[REG_RANK_INDEX(8, idx)], 0, byte);
+
+    n->irq = irq;
+    n->priority = priority;
+    if (!virtual)
+        n->desc = irq_to_desc(irq);
+    else
+        n->desc = NULL;
+
+    gic_set_guest_irq(irq, GICH_LR_PENDING, priority);
+
+    spin_lock(&v->arch.vgic.lock);
+    list_for_each_entry ( iter, &v->arch.vgic.inflight_irqs, link )
+    {
+        if ( iter->priority < priority )
+        {
+            list_add_tail(&n->link, &iter->link);
+            spin_unlock(&v->arch.vgic.lock);
+            return;
+        }
+    }
+    list_add(&n->link, &v->arch.vgic.inflight_irqs);
+    spin_unlock(&v->arch.vgic.lock);
+    /* we have a new higher priority irq, inject it into the guest */
+    cpu_raise_softirq(v->processor, VGIC_SOFTIRQ);
+}
+
+static void vgic_softirq(void)
+{
+    if (list_empty(&current->arch.vgic.inflight_irqs))
+        return;
+
+    gic_inject_irq_start();
+}
+
+static int __init init_vgic_softirq(void)
+{
+    open_softirq(VGIC_SOFTIRQ, vgic_softirq);
+    return 0;
+}
+__initcall(init_vgic_softirq);
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
+
diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
index 2226a24..2cd0bd3 100644
--- a/xen/include/asm-arm/domain.h
+++ b/xen/include/asm-arm/domain.h
@@ -6,6 +6,15 @@
 #include <asm/page.h>
 #include <asm/p2m.h>
 
+/* Represents state corresponding to a block of 32 interrupts */
+struct vgic_irq_rank {
+    spinlock_t lock; /* Covers access to all other members of this struct */
+    uint32_t ienable, iactive, ipend, pendsgi;
+    uint32_t icfg[2];
+    uint32_t ipriority[8];
+    uint32_t itargets[8];
+};
+
 struct pending_irq
 {
     int irq;
@@ -18,6 +27,22 @@ struct arch_domain
 {
     struct p2m_domain p2m;
 
+    struct {
+        /*
+         * Covers access to other members of this struct _except_ for
+         * shared_irqs where each member contains its own locking.
+         *
+         * If both class of lock is required then this lock must be
+         * taken first. If multiple rank locks are required (including
+         * the per-vcpu private_irqs rank) then they must be taken in
+         * rank order.
+         */
+        spinlock_t lock;
+        int ctlr;
+        int nr_lines;
+        struct vgic_irq_rank *shared_irqs;
+        struct pending_irq *pending_irqs;
+    } vgic;
 }  __cacheline_aligned;
 
 struct arch_vcpu
@@ -27,6 +52,11 @@ struct arch_vcpu
     uint32_t sctlr;
     uint32_t ttbr0, ttbr1, ttbcr;
 
+    struct {
+        struct vgic_irq_rank private_irqs;
+        struct list_head inflight_irqs;
+        spinlock_t lock;
+    } vgic;
 }  __cacheline_aligned;
 
 void vcpu_show_execution_state(struct vcpu *);
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 18:21:00 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 18: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.xensource.com>)
	id 1RXzdQ-0008Us-NL; Tue, 06 Dec 2011 18:20:56 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RXzdO-0008I7-Qp
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 18:20:55 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1323195594!7123966!4
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMzAwOTc=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22518 invoked from network); 6 Dec 2011 18:20:07 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Dec 2011 18:20:07 -0000
X-IronPort-AV: E=Sophos;i="4.71,307,1320642000"; d="scan'208";a="173120822"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Dec 2011 13:20:06 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Tue, 6 Dec 2011 13:20:06 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pB6IJEjZ019549;
	Tue, 6 Dec 2011 10:19:50 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Tue, 6 Dec 2011 18:20:09 +0000
Message-ID: <1323195609-17277-25-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1112061753410.31179@kaball-desktop>
References: <alpine.DEB.2.00.1112061753410.31179@kaball-desktop>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>, Tim.Deegan@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH RFC 25/25] arm: vtimer
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Emulation of the generic timer kernel registers.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
---
 xen/arch/arm/Makefile        |    1 +
 xen/arch/arm/domain.c        |    4 +
 xen/arch/arm/traps.c         |    4 +-
 xen/arch/arm/vtimer.c        |  148 ++++++++++++++++++++++++++++++++++++++++++
 xen/arch/arm/vtimer.h        |   35 ++++++++++
 xen/include/asm-arm/domain.h |    7 ++
 6 files changed, 197 insertions(+), 2 deletions(-)
 create mode 100644 xen/arch/arm/vtimer.c
 create mode 100644 xen/arch/arm/vtimer.h

diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index 6c9b18c..517c720 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -17,6 +17,7 @@ obj-y += smp.o
 obj-y += shutdown.o
 obj-y += traps.o
 obj-y += vgic.o
+obj-y += vtimer.o
 
 #obj-bin-y += ....o
 
diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 7e681ab..70f71c3 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -12,6 +12,7 @@
 #include <asm/irq.h>
 
 #include "gic.h"
+#include "vtimer.h"
 
 DEFINE_PER_CPU(struct vcpu *, curr_vcpu);
 
@@ -215,6 +216,9 @@ int vcpu_initialise(struct vcpu *v)
     if ( (rc = vcpu_vgic_init(v)) != 0 )
         return rc;
 
+    if ( (rc = vcpu_vtimer_init(v)) != 0 )
+        return rc;
+
     return rc;
 }
 
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 4346dd7..395d0af 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -468,7 +468,7 @@ static void do_cp15_32(struct cpu_user_regs *regs,
         break;
     case HSR_CPREG32(CNTP_CTL):
     case HSR_CPREG32(CNTP_TVAL):
-        /* emulate timer */
+        BUG_ON(!vtimer_emulate(regs, hsr));
         break;
     default:
         printk("%s p15, %d, r%d, cr%d, cr%d, %d @ %#08x\n",
@@ -498,7 +498,7 @@ static void do_cp15_64(struct cpu_user_regs *regs,
     switch ( hsr.bits & HSR_CP64_REGS_MASK )
     {
     case HSR_CPREG64(CNTPCT):
-        /* emulate timer */
+        BUG_ON(!vtimer_emulate(regs, hsr));
         break;
     default:
         printk("%s p15, %d, r%d, r%d, cr%d @ %#08x\n",
diff --git a/xen/arch/arm/vtimer.c b/xen/arch/arm/vtimer.c
new file mode 100644
index 0000000..3ebf5b1
--- /dev/null
+++ b/xen/arch/arm/vtimer.c
@@ -0,0 +1,148 @@
+/*
+ * xen/arch/arm/vtimer.c
+ *
+ * ARM Virtual Timer emulation support
+ *
+ * Ian Campbell <ian.campbell@citrix.com>
+ * Copyright (c) 2011 Citrix Systems.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include <xen/config.h>
+#include <xen/lib.h>
+#include <xen/timer.h>
+#include <xen/sched.h>
+#include "gic.h"
+
+extern s_time_t ticks_to_ns(uint64_t ticks);
+extern uint64_t ns_to_ticks(s_time_t ns);
+
+static void vtimer_expired(void *data)
+{
+    struct vcpu *v = data;
+    v->arch.vtimer.ctl |= CNTx_CTL_PENDING;
+    v->arch.vtimer.ctl &= ~CNTx_CTL_MASK;
+    vgic_vcpu_inject_irq(v, 30, 1);
+}
+
+int vcpu_vtimer_init(struct vcpu *v)
+{
+    init_timer(&v->arch.vtimer.timer,
+               vtimer_expired, v,
+               smp_processor_id());
+    v->arch.vtimer.ctl = 0;
+    v->arch.vtimer.offset = NOW();
+    v->arch.vtimer.cval = NOW();
+    return 0;
+}
+
+static int vtimer_emulate_32(struct cpu_user_regs *regs, union hsr hsr)
+{
+    struct vcpu *v = current;
+    struct hsr_cp32 cp32 = hsr.cp32;
+    uint32_t *r = &regs->r0 + cp32.reg;
+    s_time_t now;
+
+    switch ( hsr.bits & HSR_CP32_REGS_MASK )
+    {
+    case HSR_CPREG32(CNTP_CTL):
+        if ( cp32.read )
+        {
+            *r = v->arch.vtimer.ctl;
+        }
+        else
+        {
+            v->arch.vtimer.ctl = *r;
+
+            if ( v->arch.vtimer.ctl & CNTx_CTL_ENABLE )
+            {
+                set_timer(&v->arch.vtimer.timer,
+                          v->arch.vtimer.cval + v->arch.vtimer.offset);
+            }
+            else
+                stop_timer(&v->arch.vtimer.timer);
+        }
+
+        return 1;
+
+    case HSR_CPREG32(CNTP_TVAL):
+        now = NOW() - v->arch.vtimer.offset;
+        if ( cp32.read )
+        {
+            *r = (uint32_t)(ns_to_ticks(v->arch.vtimer.cval - now) & 0xffffffffull);
+        }
+        else
+	{
+            v->arch.vtimer.cval = now + ticks_to_ns(*r);
+	    if ( v->arch.vtimer.ctl & CNTx_CTL_ENABLE )
+            {
+                set_timer(&v->arch.vtimer.timer,
+                          v->arch.vtimer.cval + v->arch.vtimer.offset);
+            }
+        }
+
+        return 1;
+
+    default:
+        return 0;
+    }
+}
+
+static int vtimer_emulate_64(struct cpu_user_regs *regs, union hsr hsr)
+{
+    struct vcpu *v = current;
+    struct hsr_cp64 cp64 = hsr.cp64;
+    uint32_t *r1 = &regs->r0 + cp64.reg1;
+    uint32_t *r2 = &regs->r0 + cp64.reg2;
+    s_time_t now;
+
+    switch ( hsr.bits & HSR_CP64_REGS_MASK )
+    {
+    case HSR_CPREG64(CNTPCT):
+        if ( cp64.read )
+        {
+            now = NOW() - v->arch.vtimer.offset;
+            *r1 = (uint32_t)(now & 0xffffffff);
+            *r2 = (uint32_t)(now >> 32);
+            return 1;
+        }
+        else
+        {
+            printk("READ from R/O CNTPCT\n");
+            return 0;
+        }
+
+    default:
+        return 0;
+    }
+}
+
+int vtimer_emulate(struct cpu_user_regs *regs, union hsr hsr)
+{
+    switch (hsr.ec) {
+    case HSR_EC_CP15_32:
+        return vtimer_emulate_32(regs, hsr);
+    case HSR_EC_CP15_64:
+        return vtimer_emulate_64(regs, hsr);
+    default:
+        return 0;
+    }
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/arch/arm/vtimer.h b/xen/arch/arm/vtimer.h
new file mode 100644
index 0000000..d87bb25
--- /dev/null
+++ b/xen/arch/arm/vtimer.h
@@ -0,0 +1,35 @@
+/*
+ * xen/arch/arm/vtimer.h
+ *
+ * ARM Virtual Timer emulation support
+ *
+ * Ian Campbell <ian.campbell@citrix.com>
+ * Copyright (c) 2011 Citrix Systems.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#ifndef __ARCH_ARM_VTIMER_H__
+#define __ARCH_ARM_VTIMER_H__
+
+extern int vcpu_vtimer_init(struct vcpu *v);
+extern int vtimer_emulate(struct cpu_user_regs *regs, union hsr hsr);
+
+#endif
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
index 2cd0bd3..3372d14 100644
--- a/xen/include/asm-arm/domain.h
+++ b/xen/include/asm-arm/domain.h
@@ -57,6 +57,13 @@ struct arch_vcpu
         struct list_head inflight_irqs;
         spinlock_t lock;
     } vgic;
+
+    struct {
+        struct timer timer;
+        uint32_t ctl;
+        s_time_t offset;
+        s_time_t cval;
+    } vtimer;
 }  __cacheline_aligned;
 
 void vcpu_show_execution_state(struct vcpu *);
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 18:21:00 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 18: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.xensource.com>)
	id 1RXzdQ-0008Us-NL; Tue, 06 Dec 2011 18:20:56 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RXzdO-0008I7-Qp
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 18:20:55 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1323195594!7123966!4
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMzAwOTc=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22518 invoked from network); 6 Dec 2011 18:20:07 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Dec 2011 18:20:07 -0000
X-IronPort-AV: E=Sophos;i="4.71,307,1320642000"; d="scan'208";a="173120822"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Dec 2011 13:20:06 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Tue, 6 Dec 2011 13:20:06 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pB6IJEjZ019549;
	Tue, 6 Dec 2011 10:19:50 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Tue, 6 Dec 2011 18:20:09 +0000
Message-ID: <1323195609-17277-25-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1112061753410.31179@kaball-desktop>
References: <alpine.DEB.2.00.1112061753410.31179@kaball-desktop>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>, Tim.Deegan@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH RFC 25/25] arm: vtimer
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Emulation of the generic timer kernel registers.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
---
 xen/arch/arm/Makefile        |    1 +
 xen/arch/arm/domain.c        |    4 +
 xen/arch/arm/traps.c         |    4 +-
 xen/arch/arm/vtimer.c        |  148 ++++++++++++++++++++++++++++++++++++++++++
 xen/arch/arm/vtimer.h        |   35 ++++++++++
 xen/include/asm-arm/domain.h |    7 ++
 6 files changed, 197 insertions(+), 2 deletions(-)
 create mode 100644 xen/arch/arm/vtimer.c
 create mode 100644 xen/arch/arm/vtimer.h

diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index 6c9b18c..517c720 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -17,6 +17,7 @@ obj-y += smp.o
 obj-y += shutdown.o
 obj-y += traps.o
 obj-y += vgic.o
+obj-y += vtimer.o
 
 #obj-bin-y += ....o
 
diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 7e681ab..70f71c3 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -12,6 +12,7 @@
 #include <asm/irq.h>
 
 #include "gic.h"
+#include "vtimer.h"
 
 DEFINE_PER_CPU(struct vcpu *, curr_vcpu);
 
@@ -215,6 +216,9 @@ int vcpu_initialise(struct vcpu *v)
     if ( (rc = vcpu_vgic_init(v)) != 0 )
         return rc;
 
+    if ( (rc = vcpu_vtimer_init(v)) != 0 )
+        return rc;
+
     return rc;
 }
 
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 4346dd7..395d0af 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -468,7 +468,7 @@ static void do_cp15_32(struct cpu_user_regs *regs,
         break;
     case HSR_CPREG32(CNTP_CTL):
     case HSR_CPREG32(CNTP_TVAL):
-        /* emulate timer */
+        BUG_ON(!vtimer_emulate(regs, hsr));
         break;
     default:
         printk("%s p15, %d, r%d, cr%d, cr%d, %d @ %#08x\n",
@@ -498,7 +498,7 @@ static void do_cp15_64(struct cpu_user_regs *regs,
     switch ( hsr.bits & HSR_CP64_REGS_MASK )
     {
     case HSR_CPREG64(CNTPCT):
-        /* emulate timer */
+        BUG_ON(!vtimer_emulate(regs, hsr));
         break;
     default:
         printk("%s p15, %d, r%d, r%d, cr%d @ %#08x\n",
diff --git a/xen/arch/arm/vtimer.c b/xen/arch/arm/vtimer.c
new file mode 100644
index 0000000..3ebf5b1
--- /dev/null
+++ b/xen/arch/arm/vtimer.c
@@ -0,0 +1,148 @@
+/*
+ * xen/arch/arm/vtimer.c
+ *
+ * ARM Virtual Timer emulation support
+ *
+ * Ian Campbell <ian.campbell@citrix.com>
+ * Copyright (c) 2011 Citrix Systems.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include <xen/config.h>
+#include <xen/lib.h>
+#include <xen/timer.h>
+#include <xen/sched.h>
+#include "gic.h"
+
+extern s_time_t ticks_to_ns(uint64_t ticks);
+extern uint64_t ns_to_ticks(s_time_t ns);
+
+static void vtimer_expired(void *data)
+{
+    struct vcpu *v = data;
+    v->arch.vtimer.ctl |= CNTx_CTL_PENDING;
+    v->arch.vtimer.ctl &= ~CNTx_CTL_MASK;
+    vgic_vcpu_inject_irq(v, 30, 1);
+}
+
+int vcpu_vtimer_init(struct vcpu *v)
+{
+    init_timer(&v->arch.vtimer.timer,
+               vtimer_expired, v,
+               smp_processor_id());
+    v->arch.vtimer.ctl = 0;
+    v->arch.vtimer.offset = NOW();
+    v->arch.vtimer.cval = NOW();
+    return 0;
+}
+
+static int vtimer_emulate_32(struct cpu_user_regs *regs, union hsr hsr)
+{
+    struct vcpu *v = current;
+    struct hsr_cp32 cp32 = hsr.cp32;
+    uint32_t *r = &regs->r0 + cp32.reg;
+    s_time_t now;
+
+    switch ( hsr.bits & HSR_CP32_REGS_MASK )
+    {
+    case HSR_CPREG32(CNTP_CTL):
+        if ( cp32.read )
+        {
+            *r = v->arch.vtimer.ctl;
+        }
+        else
+        {
+            v->arch.vtimer.ctl = *r;
+
+            if ( v->arch.vtimer.ctl & CNTx_CTL_ENABLE )
+            {
+                set_timer(&v->arch.vtimer.timer,
+                          v->arch.vtimer.cval + v->arch.vtimer.offset);
+            }
+            else
+                stop_timer(&v->arch.vtimer.timer);
+        }
+
+        return 1;
+
+    case HSR_CPREG32(CNTP_TVAL):
+        now = NOW() - v->arch.vtimer.offset;
+        if ( cp32.read )
+        {
+            *r = (uint32_t)(ns_to_ticks(v->arch.vtimer.cval - now) & 0xffffffffull);
+        }
+        else
+	{
+            v->arch.vtimer.cval = now + ticks_to_ns(*r);
+	    if ( v->arch.vtimer.ctl & CNTx_CTL_ENABLE )
+            {
+                set_timer(&v->arch.vtimer.timer,
+                          v->arch.vtimer.cval + v->arch.vtimer.offset);
+            }
+        }
+
+        return 1;
+
+    default:
+        return 0;
+    }
+}
+
+static int vtimer_emulate_64(struct cpu_user_regs *regs, union hsr hsr)
+{
+    struct vcpu *v = current;
+    struct hsr_cp64 cp64 = hsr.cp64;
+    uint32_t *r1 = &regs->r0 + cp64.reg1;
+    uint32_t *r2 = &regs->r0 + cp64.reg2;
+    s_time_t now;
+
+    switch ( hsr.bits & HSR_CP64_REGS_MASK )
+    {
+    case HSR_CPREG64(CNTPCT):
+        if ( cp64.read )
+        {
+            now = NOW() - v->arch.vtimer.offset;
+            *r1 = (uint32_t)(now & 0xffffffff);
+            *r2 = (uint32_t)(now >> 32);
+            return 1;
+        }
+        else
+        {
+            printk("READ from R/O CNTPCT\n");
+            return 0;
+        }
+
+    default:
+        return 0;
+    }
+}
+
+int vtimer_emulate(struct cpu_user_regs *regs, union hsr hsr)
+{
+    switch (hsr.ec) {
+    case HSR_EC_CP15_32:
+        return vtimer_emulate_32(regs, hsr);
+    case HSR_EC_CP15_64:
+        return vtimer_emulate_64(regs, hsr);
+    default:
+        return 0;
+    }
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/arch/arm/vtimer.h b/xen/arch/arm/vtimer.h
new file mode 100644
index 0000000..d87bb25
--- /dev/null
+++ b/xen/arch/arm/vtimer.h
@@ -0,0 +1,35 @@
+/*
+ * xen/arch/arm/vtimer.h
+ *
+ * ARM Virtual Timer emulation support
+ *
+ * Ian Campbell <ian.campbell@citrix.com>
+ * Copyright (c) 2011 Citrix Systems.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#ifndef __ARCH_ARM_VTIMER_H__
+#define __ARCH_ARM_VTIMER_H__
+
+extern int vcpu_vtimer_init(struct vcpu *v);
+extern int vtimer_emulate(struct cpu_user_regs *regs, union hsr hsr);
+
+#endif
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
index 2cd0bd3..3372d14 100644
--- a/xen/include/asm-arm/domain.h
+++ b/xen/include/asm-arm/domain.h
@@ -57,6 +57,13 @@ struct arch_vcpu
         struct list_head inflight_irqs;
         spinlock_t lock;
     } vgic;
+
+    struct {
+        struct timer timer;
+        uint32_t ctl;
+        s_time_t offset;
+        s_time_t cval;
+    } vtimer;
 }  __cacheline_aligned;
 
 void vcpu_show_execution_state(struct vcpu *);
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 18:21:28 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 18:21:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXzdu-0000bf-A5; Tue, 06 Dec 2011 18:21:26 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RXzds-0000Ur-5n
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 18:21:24 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1323195602!45659908!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMzAwOTc=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 960 invoked from network); 6 Dec 2011 18:20:03 -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;
	6 Dec 2011 18:20:03 -0000
X-IronPort-AV: E=Sophos;i="4.71,307,1320642000"; d="scan'208";a="173120714"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Dec 2011 13:19:33 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Tue, 6 Dec 2011 13:19:33 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pB6IJEjC019549;
	Tue, 6 Dec 2011 10:19:17 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Tue, 6 Dec 2011 18:19:46 +0000
Message-ID: <1323195609-17277-2-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1112061753410.31179@kaball-desktop>
References: <alpine.DEB.2.00.1112061753410.31179@kaball-desktop>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>, Tim.Deegan@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH RFC 02/25] A collection of fixes to Xen common
	files
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

- call free_xenoprof_pages only ifdef xenoprof;

- define PRI_stime as PRId64 in an header file;

- respect boundaries in is_kernel_*;

- implement is_kernel_rodata.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
---
 xen/common/domain.c        |    2 ++
 xen/common/sched_credit2.c |    6 ------
 xen/include/xen/kernel.h   |   12 +++++++++---
 xen/include/xen/time.h     |    1 +
 4 files changed, 12 insertions(+), 9 deletions(-)

diff --git a/xen/common/domain.c b/xen/common/domain.c
index 9e355c8..b75fc1d 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -661,7 +661,9 @@ static void complete_domain_destroy(struct rcu_head *head)
     sched_destroy_domain(d);
 
     /* Free page used by xen oprofile buffer. */
+#ifdef xenoprof
     free_xenoprof_pages(d);
+#endif
 
     for ( i = d->max_vcpus - 1; i >= 0; i-- )
         if ( (v = d->vcpu[i]) != NULL )
diff --git a/xen/common/sched_credit2.c b/xen/common/sched_credit2.c
index 86c4439..73f7138 100644
--- a/xen/common/sched_credit2.c
+++ b/xen/common/sched_credit2.c
@@ -26,12 +26,6 @@
 #include <xen/trace.h>
 #include <xen/cpu.h>
 
-#if __i386__
-#define PRI_stime "lld"
-#else
-#define PRI_stime "ld"
-#endif
-
 #define d2printk(x...)
 //#define d2printk printk
 
diff --git a/xen/include/xen/kernel.h b/xen/include/xen/kernel.h
index fd03f74..d5b13e8 100644
--- a/xen/include/xen/kernel.h
+++ b/xen/include/xen/kernel.h
@@ -66,19 +66,25 @@
 extern char _start[], _end[];
 #define is_kernel(p) ({                         \
     char *__p = (char *)(unsigned long)(p);     \
-    (__p >= _start) && (__p <= _end);           \
+    (__p >= _start) && (__p < _end);            \
 })
 
 extern char _stext[], _etext[];
 #define is_kernel_text(p) ({                    \
     char *__p = (char *)(unsigned long)(p);     \
-    (__p >= _stext) && (__p <= _etext);         \
+    (__p >= _stext) && (__p < _etext);          \
+})
+
+extern char _srodata[], _erodata[];
+#define is_kernel_rodata(p) ({                  \
+    char *__p = (char *)(unsigned long)(p);     \
+    (__p >= _srodata) && (__p < _erodata);      \
 })
 
 extern char _sinittext[], _einittext[];
 #define is_kernel_inittext(p) ({                \
     char *__p = (char *)(unsigned long)(p);     \
-    (__p >= _sinittext) && (__p <= _einittext); \
+    (__p >= _sinittext) && (__p < _einittext);  \
 })
 
 #endif /* _LINUX_KERNEL_H */
diff --git a/xen/include/xen/time.h b/xen/include/xen/time.h
index a194340..31c9ce5 100644
--- a/xen/include/xen/time.h
+++ b/xen/include/xen/time.h
@@ -30,6 +30,7 @@ struct vcpu;
  */
 
 typedef s64 s_time_t;
+#define PRI_stime PRId64
 
 s_time_t get_s_time(void);
 unsigned long get_localtime(struct domain *d);
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 18:21:28 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 18:21:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXzdu-0000bf-A5; Tue, 06 Dec 2011 18:21:26 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RXzds-0000Ur-5n
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 18:21:24 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1323195602!45659908!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMzAwOTc=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 960 invoked from network); 6 Dec 2011 18:20:03 -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;
	6 Dec 2011 18:20:03 -0000
X-IronPort-AV: E=Sophos;i="4.71,307,1320642000"; d="scan'208";a="173120714"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Dec 2011 13:19:33 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Tue, 6 Dec 2011 13:19:33 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pB6IJEjC019549;
	Tue, 6 Dec 2011 10:19:17 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Tue, 6 Dec 2011 18:19:46 +0000
Message-ID: <1323195609-17277-2-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1112061753410.31179@kaball-desktop>
References: <alpine.DEB.2.00.1112061753410.31179@kaball-desktop>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>, Tim.Deegan@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH RFC 02/25] A collection of fixes to Xen common
	files
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

- call free_xenoprof_pages only ifdef xenoprof;

- define PRI_stime as PRId64 in an header file;

- respect boundaries in is_kernel_*;

- implement is_kernel_rodata.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
---
 xen/common/domain.c        |    2 ++
 xen/common/sched_credit2.c |    6 ------
 xen/include/xen/kernel.h   |   12 +++++++++---
 xen/include/xen/time.h     |    1 +
 4 files changed, 12 insertions(+), 9 deletions(-)

diff --git a/xen/common/domain.c b/xen/common/domain.c
index 9e355c8..b75fc1d 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -661,7 +661,9 @@ static void complete_domain_destroy(struct rcu_head *head)
     sched_destroy_domain(d);
 
     /* Free page used by xen oprofile buffer. */
+#ifdef xenoprof
     free_xenoprof_pages(d);
+#endif
 
     for ( i = d->max_vcpus - 1; i >= 0; i-- )
         if ( (v = d->vcpu[i]) != NULL )
diff --git a/xen/common/sched_credit2.c b/xen/common/sched_credit2.c
index 86c4439..73f7138 100644
--- a/xen/common/sched_credit2.c
+++ b/xen/common/sched_credit2.c
@@ -26,12 +26,6 @@
 #include <xen/trace.h>
 #include <xen/cpu.h>
 
-#if __i386__
-#define PRI_stime "lld"
-#else
-#define PRI_stime "ld"
-#endif
-
 #define d2printk(x...)
 //#define d2printk printk
 
diff --git a/xen/include/xen/kernel.h b/xen/include/xen/kernel.h
index fd03f74..d5b13e8 100644
--- a/xen/include/xen/kernel.h
+++ b/xen/include/xen/kernel.h
@@ -66,19 +66,25 @@
 extern char _start[], _end[];
 #define is_kernel(p) ({                         \
     char *__p = (char *)(unsigned long)(p);     \
-    (__p >= _start) && (__p <= _end);           \
+    (__p >= _start) && (__p < _end);            \
 })
 
 extern char _stext[], _etext[];
 #define is_kernel_text(p) ({                    \
     char *__p = (char *)(unsigned long)(p);     \
-    (__p >= _stext) && (__p <= _etext);         \
+    (__p >= _stext) && (__p < _etext);          \
+})
+
+extern char _srodata[], _erodata[];
+#define is_kernel_rodata(p) ({                  \
+    char *__p = (char *)(unsigned long)(p);     \
+    (__p >= _srodata) && (__p < _erodata);      \
 })
 
 extern char _sinittext[], _einittext[];
 #define is_kernel_inittext(p) ({                \
     char *__p = (char *)(unsigned long)(p);     \
-    (__p >= _sinittext) && (__p <= _einittext); \
+    (__p >= _sinittext) && (__p < _einittext);  \
 })
 
 #endif /* _LINUX_KERNEL_H */
diff --git a/xen/include/xen/time.h b/xen/include/xen/time.h
index a194340..31c9ce5 100644
--- a/xen/include/xen/time.h
+++ b/xen/include/xen/time.h
@@ -30,6 +30,7 @@ struct vcpu;
  */
 
 typedef s64 s_time_t;
+#define PRI_stime PRId64
 
 s_time_t get_s_time(void);
 unsigned long get_localtime(struct domain *d);
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 18:21:29 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 18:21:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXzdu-0000cB-Ms; Tue, 06 Dec 2011 18:21:26 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RXzdt-0000ZO-1a
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 18:21:25 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1323195597!56250446!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDcxMjI=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1168 invoked from network); 6 Dec 2011 18:19:58 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Dec 2011 18:19:58 -0000
X-IronPort-AV: E=Sophos;i="4.71,307,1320642000"; d="scan'208";a="19721940"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Dec 2011 13:19:40 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Tue, 6 Dec 2011 13:19:40 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pB6IJEjH019549;
	Tue, 6 Dec 2011 10:19:24 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Tue, 6 Dec 2011 18:19:51 +0000
Message-ID: <1323195609-17277-7-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1112061753410.31179@kaball-desktop>
References: <alpine.DEB.2.00.1112061753410.31179@kaball-desktop>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>, Tim.Deegan@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH RFC 07/25] xen/common/Makefile: introduce
	HAS_CPUFREQ, HAS_PCI, HAS_PASSTHROUGH, HAS_NS16550
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

- make the compilation of ns16550.c depend upon HAS_NS16550;

- make the compilation of cpufreq depend upon HAS_CPUFREQ;

- make the compilation of pci depend upon HAS_PCI;

- make the compilation of passthrough depend upon HAS_PASSTHROUGH;

- make the compilation of kexec.o depend on HAS_ACPI.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
---
 xen/arch/ia64/Rules.mk     |    4 ++++
 xen/arch/x86/Rules.mk      |    4 ++++
 xen/common/Makefile        |    2 +-
 xen/common/shutdown.c      |    4 ++++
 xen/drivers/Makefile       |    6 +++---
 xen/drivers/char/Makefile  |    2 +-
 xen/drivers/char/console.c |    4 ++++
 7 files changed, 21 insertions(+), 5 deletions(-)

diff --git a/xen/arch/ia64/Rules.mk b/xen/arch/ia64/Rules.mk
index bef11c3..63e4405 100644
--- a/xen/arch/ia64/Rules.mk
+++ b/xen/arch/ia64/Rules.mk
@@ -4,6 +4,10 @@
 ia64 := y
 HAS_ACPI := y
 HAS_VGA  := y
+HAS_CPUFREQ := y
+HAS_PCI := y
+HAS_PASSTHROUGH := y
+HAS_NS16550 := y
 xenoprof := y
 no_warns ?= n
 vti_debug ?= n
diff --git a/xen/arch/x86/Rules.mk b/xen/arch/x86/Rules.mk
index bf77aef..d7a44e6 100644
--- a/xen/arch/x86/Rules.mk
+++ b/xen/arch/x86/Rules.mk
@@ -3,6 +3,10 @@
 
 HAS_ACPI := y
 HAS_VGA  := y
+HAS_CPUFREQ := y
+HAS_PCI := y
+HAS_PASSTHROUGH := y
+HAS_NS16550 := y
 xenoprof := y
 
 #
diff --git a/xen/common/Makefile b/xen/common/Makefile
index 1d85e65..1550d7b 100644
--- a/xen/common/Makefile
+++ b/xen/common/Makefile
@@ -5,10 +5,10 @@ obj-y += domctl.o
 obj-y += domain.o
 obj-y += event_channel.o
 obj-y += grant_table.o
+obj-$(HAS_ACPI) += kexec.o
 obj-y += irq.o
 obj-y += kernel.o
 obj-y += keyhandler.o
-obj-y += kexec.o
 obj-y += lib.o
 obj-y += memory.o
 obj-y += multicall.o
diff --git a/xen/common/shutdown.c b/xen/common/shutdown.c
index e356e86..ae6cc04 100644
--- a/xen/common/shutdown.c
+++ b/xen/common/shutdown.c
@@ -6,7 +6,9 @@
 #include <xen/delay.h>
 #include <xen/shutdown.h>
 #include <xen/console.h>
+#ifdef HAS_ACPI
 #include <xen/kexec.h>
+#endif
 #include <asm/debugger.h>
 #include <public/sched.h>
 
@@ -58,7 +60,9 @@ void dom0_shutdown(u8 reason)
     case SHUTDOWN_watchdog:
     {
         printk("Domain 0 shutdown: watchdog rebooting machine.\n");
+#ifdef HAS_ACPI
         kexec_crash();
+#endif
         machine_restart(0);
         break; /* not reached */
     }
diff --git a/xen/drivers/Makefile b/xen/drivers/Makefile
index eb4fb61..7239375 100644
--- a/xen/drivers/Makefile
+++ b/xen/drivers/Makefile
@@ -1,6 +1,6 @@
 subdir-y += char
-subdir-y += cpufreq
-subdir-y += pci
-subdir-y += passthrough
+subdir-$(HAS_CPUFREQ) += cpufreq
+subdir-$(HAS_PCI) += pci
+subdir-$(HAS_PASSTHROUGH) += passthrough
 subdir-$(HAS_ACPI) += acpi
 subdir-$(HAS_VGA) += video
diff --git a/xen/drivers/char/Makefile b/xen/drivers/char/Makefile
index ded9a94..19250c8 100644
--- a/xen/drivers/char/Makefile
+++ b/xen/drivers/char/Makefile
@@ -1,3 +1,3 @@
 obj-y += console.o
-obj-y += ns16550.o
+obj-$(HAS_NS16550) += ns16550.o
 obj-y += serial.o
diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
index 89cf4f8..d8e3749 100644
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -22,7 +22,9 @@
 #include <xen/guest_access.h>
 #include <xen/shutdown.h>
 #include <xen/vga.h>
+#ifdef HAS_ACPI
 #include <xen/kexec.h>
+#endif
 #include <asm/debugger.h>
 #include <asm/div64.h>
 #include <xen/hypercall.h> /* for do_console_io */
@@ -961,7 +963,9 @@ void panic(const char *fmt, ...)
 
     debugger_trap_immediate();
 
+#ifdef HAS_ACPI
     kexec_crash();
+#endif
 
     if ( opt_noreboot )
     {
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 18:21:29 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 18:21:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXzdu-0000cB-Ms; Tue, 06 Dec 2011 18:21:26 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RXzdt-0000ZO-1a
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 18:21:25 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1323195597!56250446!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDcxMjI=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1168 invoked from network); 6 Dec 2011 18:19:58 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Dec 2011 18:19:58 -0000
X-IronPort-AV: E=Sophos;i="4.71,307,1320642000"; d="scan'208";a="19721940"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Dec 2011 13:19:40 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Tue, 6 Dec 2011 13:19:40 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pB6IJEjH019549;
	Tue, 6 Dec 2011 10:19:24 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Tue, 6 Dec 2011 18:19:51 +0000
Message-ID: <1323195609-17277-7-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1112061753410.31179@kaball-desktop>
References: <alpine.DEB.2.00.1112061753410.31179@kaball-desktop>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>, Tim.Deegan@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH RFC 07/25] xen/common/Makefile: introduce
	HAS_CPUFREQ, HAS_PCI, HAS_PASSTHROUGH, HAS_NS16550
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

- make the compilation of ns16550.c depend upon HAS_NS16550;

- make the compilation of cpufreq depend upon HAS_CPUFREQ;

- make the compilation of pci depend upon HAS_PCI;

- make the compilation of passthrough depend upon HAS_PASSTHROUGH;

- make the compilation of kexec.o depend on HAS_ACPI.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
---
 xen/arch/ia64/Rules.mk     |    4 ++++
 xen/arch/x86/Rules.mk      |    4 ++++
 xen/common/Makefile        |    2 +-
 xen/common/shutdown.c      |    4 ++++
 xen/drivers/Makefile       |    6 +++---
 xen/drivers/char/Makefile  |    2 +-
 xen/drivers/char/console.c |    4 ++++
 7 files changed, 21 insertions(+), 5 deletions(-)

diff --git a/xen/arch/ia64/Rules.mk b/xen/arch/ia64/Rules.mk
index bef11c3..63e4405 100644
--- a/xen/arch/ia64/Rules.mk
+++ b/xen/arch/ia64/Rules.mk
@@ -4,6 +4,10 @@
 ia64 := y
 HAS_ACPI := y
 HAS_VGA  := y
+HAS_CPUFREQ := y
+HAS_PCI := y
+HAS_PASSTHROUGH := y
+HAS_NS16550 := y
 xenoprof := y
 no_warns ?= n
 vti_debug ?= n
diff --git a/xen/arch/x86/Rules.mk b/xen/arch/x86/Rules.mk
index bf77aef..d7a44e6 100644
--- a/xen/arch/x86/Rules.mk
+++ b/xen/arch/x86/Rules.mk
@@ -3,6 +3,10 @@
 
 HAS_ACPI := y
 HAS_VGA  := y
+HAS_CPUFREQ := y
+HAS_PCI := y
+HAS_PASSTHROUGH := y
+HAS_NS16550 := y
 xenoprof := y
 
 #
diff --git a/xen/common/Makefile b/xen/common/Makefile
index 1d85e65..1550d7b 100644
--- a/xen/common/Makefile
+++ b/xen/common/Makefile
@@ -5,10 +5,10 @@ obj-y += domctl.o
 obj-y += domain.o
 obj-y += event_channel.o
 obj-y += grant_table.o
+obj-$(HAS_ACPI) += kexec.o
 obj-y += irq.o
 obj-y += kernel.o
 obj-y += keyhandler.o
-obj-y += kexec.o
 obj-y += lib.o
 obj-y += memory.o
 obj-y += multicall.o
diff --git a/xen/common/shutdown.c b/xen/common/shutdown.c
index e356e86..ae6cc04 100644
--- a/xen/common/shutdown.c
+++ b/xen/common/shutdown.c
@@ -6,7 +6,9 @@
 #include <xen/delay.h>
 #include <xen/shutdown.h>
 #include <xen/console.h>
+#ifdef HAS_ACPI
 #include <xen/kexec.h>
+#endif
 #include <asm/debugger.h>
 #include <public/sched.h>
 
@@ -58,7 +60,9 @@ void dom0_shutdown(u8 reason)
     case SHUTDOWN_watchdog:
     {
         printk("Domain 0 shutdown: watchdog rebooting machine.\n");
+#ifdef HAS_ACPI
         kexec_crash();
+#endif
         machine_restart(0);
         break; /* not reached */
     }
diff --git a/xen/drivers/Makefile b/xen/drivers/Makefile
index eb4fb61..7239375 100644
--- a/xen/drivers/Makefile
+++ b/xen/drivers/Makefile
@@ -1,6 +1,6 @@
 subdir-y += char
-subdir-y += cpufreq
-subdir-y += pci
-subdir-y += passthrough
+subdir-$(HAS_CPUFREQ) += cpufreq
+subdir-$(HAS_PCI) += pci
+subdir-$(HAS_PASSTHROUGH) += passthrough
 subdir-$(HAS_ACPI) += acpi
 subdir-$(HAS_VGA) += video
diff --git a/xen/drivers/char/Makefile b/xen/drivers/char/Makefile
index ded9a94..19250c8 100644
--- a/xen/drivers/char/Makefile
+++ b/xen/drivers/char/Makefile
@@ -1,3 +1,3 @@
 obj-y += console.o
-obj-y += ns16550.o
+obj-$(HAS_NS16550) += ns16550.o
 obj-y += serial.o
diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
index 89cf4f8..d8e3749 100644
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -22,7 +22,9 @@
 #include <xen/guest_access.h>
 #include <xen/shutdown.h>
 #include <xen/vga.h>
+#ifdef HAS_ACPI
 #include <xen/kexec.h>
+#endif
 #include <asm/debugger.h>
 #include <asm/div64.h>
 #include <xen/hypercall.h> /* for do_console_io */
@@ -961,7 +963,9 @@ void panic(const char *fmt, ...)
 
     debugger_trap_immediate();
 
+#ifdef HAS_ACPI
     kexec_crash();
+#endif
 
     if ( opt_noreboot )
     {
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 18:22:13 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 18:22:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXzec-0001Gl-HO; Tue, 06 Dec 2011 18:22:10 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <davem@davemloft.net>) id 1RXzea-0001Ab-Dw
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 18:22:08 +0000
X-Env-Sender: davem@davemloft.net
X-Msg-Ref: server-15.tower-174.messagelabs.com!1323195680!4312771!1
X-Originating-IP: [198.137.202.13]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16195 invoked from network); 6 Dec 2011 18:21:22 -0000
Received: from shards.monkeyblade.net (HELO shards.monkeyblade.net)
	(198.137.202.13)
	by server-15.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 6 Dec 2011 18:21:22 -0000
Received: from localhost (nat-pool-rdu.redhat.com [66.187.233.202])
	(authenticated bits=0)
	by shards.monkeyblade.net (8.14.4/8.14.4) with ESMTP id pB6ILGl7013341
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO);
	Tue, 6 Dec 2011 10:21:17 -0800
Date: Tue, 06 Dec 2011 13:21:15 -0500 (EST)
Message-Id: <20111206.132115.2018027889218830384.davem@davemloft.net>
To: Ian.Campbell@citrix.com
From: David Miller <davem@davemloft.net>
In-Reply-To: <1323178854.23681.75.camel@zakaz.uk.xensource.com>
References: <1323173090-7867-1-git-send-email-wei.liu2@citrix.com>
	<1323178854.23681.75.camel@zakaz.uk.xensource.com>
X-Mailer: Mew version 6.4 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6
	(shards.monkeyblade.net [198.137.202.13]);
	Tue, 06 Dec 2011 10:21:18 -0800 (PST)
Cc: netdev@vger.kernel.org, xen-devel@lists.xensource.com, wei.liu2@citrix.com
Subject: Re: [Xen-devel] [PATCH] netback: fix typo in comment
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Ian Campbell <Ian.Campbell@citrix.com>
Date: Tue, 6 Dec 2011 13:40:54 +0000

> On Tue, 2011-12-06 at 12:04 +0000, Wei Liu wrote:
>> "variables a used" should be "variables are used".
>> 
>> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> Acked-by: Ian Campbell <ian.campbell@citrix.com>

Applied.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 18:22:13 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 18:22:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RXzec-0001Gl-HO; Tue, 06 Dec 2011 18:22:10 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <davem@davemloft.net>) id 1RXzea-0001Ab-Dw
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 18:22:08 +0000
X-Env-Sender: davem@davemloft.net
X-Msg-Ref: server-15.tower-174.messagelabs.com!1323195680!4312771!1
X-Originating-IP: [198.137.202.13]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16195 invoked from network); 6 Dec 2011 18:21:22 -0000
Received: from shards.monkeyblade.net (HELO shards.monkeyblade.net)
	(198.137.202.13)
	by server-15.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 6 Dec 2011 18:21:22 -0000
Received: from localhost (nat-pool-rdu.redhat.com [66.187.233.202])
	(authenticated bits=0)
	by shards.monkeyblade.net (8.14.4/8.14.4) with ESMTP id pB6ILGl7013341
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO);
	Tue, 6 Dec 2011 10:21:17 -0800
Date: Tue, 06 Dec 2011 13:21:15 -0500 (EST)
Message-Id: <20111206.132115.2018027889218830384.davem@davemloft.net>
To: Ian.Campbell@citrix.com
From: David Miller <davem@davemloft.net>
In-Reply-To: <1323178854.23681.75.camel@zakaz.uk.xensource.com>
References: <1323173090-7867-1-git-send-email-wei.liu2@citrix.com>
	<1323178854.23681.75.camel@zakaz.uk.xensource.com>
X-Mailer: Mew version 6.4 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6
	(shards.monkeyblade.net [198.137.202.13]);
	Tue, 06 Dec 2011 10:21:18 -0800 (PST)
Cc: netdev@vger.kernel.org, xen-devel@lists.xensource.com, wei.liu2@citrix.com
Subject: Re: [Xen-devel] [PATCH] netback: fix typo in comment
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Ian Campbell <Ian.Campbell@citrix.com>
Date: Tue, 6 Dec 2011 13:40:54 +0000

> On Tue, 2011-12-06 at 12:04 +0000, Wei Liu wrote:
>> "variables a used" should be "variables are used".
>> 
>> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> Acked-by: Ian Campbell <ian.campbell@citrix.com>

Applied.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 19:05:31 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 19:05:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RY0KI-00040R-PZ; Tue, 06 Dec 2011 19:05:14 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RY0KH-00040M-4g
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 19:05:13 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1323198239!55635280!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjM3Ng==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16255 invoked from network); 6 Dec 2011 19:03:59 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Dec 2011 19:03:59 -0000
X-IronPort-AV: E=Sophos;i="4.71,307,1320624000"; 
   d="scan'208";a="9328869"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Dec 2011 19:04:31 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 6 Dec 2011 19:04:31 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RY0Jb-0004I6-7F;
	Tue, 06 Dec 2011 19:04:31 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RY0Jb-0006nc-6v;
	Tue, 06 Dec 2011 19:04:31 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10371-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 6 Dec 2011 19:04:31 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10371: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10371 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10371/

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-amd64-xl-sedf     14 guest-localmigrate/x10    fail REGR. vs. 10201
 test-amd64-i386-win-vcpus1    8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-i386-win           8 guest-saverestore         fail REGR. vs. 10201
 test-i386-i386-win            8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-amd64-win          8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-amd64-xl-win       8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-i386-xl-win-vcpus1  8 guest-saverestore        fail REGR. vs. 10201
 test-i386-i386-xl-win         8 guest-saverestore         fail REGR. vs. 10201

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-win7-amd64  7 windows-install              fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install          fail never pass
 test-amd64-i386-xl-win7-amd64  7 windows-install              fail  never pass
 test-i386-i386-xl-winxpsp3    7 windows-install              fail   never pass
 test-amd64-i386-xend-winxpsp3  7 windows-install              fail  never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   never pass

version targeted for testing:
 xen                  ff988cea61ea
baseline version:
 xen                  62ff6a318c5d

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Andrew Cooper <andrew.cooper3@citrix.com>
  Anthony PERARD <anthony.perard@citrix.com>
  Brendan Cully <brendan@cs.ubc.ca>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Haitao Shan <haitao.shan@intel.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@novell.com>
  Jan Beulich <jbeulich@suse.com>
  Jonathan Davies <jonathan.davies@citrix.com>
  juergen.gross@ts.fujitsu.com
  Keir Fraser <keir@xen.org>
  Liu, Jinsong <jinsong.liu@intel.com>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
  Philipp Hahn <hahn@univention.de>
  Shriram Rajagopalan <rshriram@cs.ubc.ca>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang2 <wei.wang2@amd.com>
  Xudong Hao <xudong.hao@intel.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 1366 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 19:05:31 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 19:05:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RY0KI-00040R-PZ; Tue, 06 Dec 2011 19:05:14 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RY0KH-00040M-4g
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 19:05:13 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1323198239!55635280!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjM3Ng==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16255 invoked from network); 6 Dec 2011 19:03:59 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Dec 2011 19:03:59 -0000
X-IronPort-AV: E=Sophos;i="4.71,307,1320624000"; 
   d="scan'208";a="9328869"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Dec 2011 19:04:31 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 6 Dec 2011 19:04:31 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RY0Jb-0004I6-7F;
	Tue, 06 Dec 2011 19:04:31 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RY0Jb-0006nc-6v;
	Tue, 06 Dec 2011 19:04:31 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10371-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 6 Dec 2011 19:04:31 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10371: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10371 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10371/

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-amd64-xl-sedf     14 guest-localmigrate/x10    fail REGR. vs. 10201
 test-amd64-i386-win-vcpus1    8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-i386-win           8 guest-saverestore         fail REGR. vs. 10201
 test-i386-i386-win            8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-amd64-win          8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-amd64-xl-win       8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-i386-xl-win-vcpus1  8 guest-saverestore        fail REGR. vs. 10201
 test-i386-i386-xl-win         8 guest-saverestore         fail REGR. vs. 10201

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-win7-amd64  7 windows-install              fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install          fail never pass
 test-amd64-i386-xl-win7-amd64  7 windows-install              fail  never pass
 test-i386-i386-xl-winxpsp3    7 windows-install              fail   never pass
 test-amd64-i386-xend-winxpsp3  7 windows-install              fail  never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   never pass

version targeted for testing:
 xen                  ff988cea61ea
baseline version:
 xen                  62ff6a318c5d

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Andrew Cooper <andrew.cooper3@citrix.com>
  Anthony PERARD <anthony.perard@citrix.com>
  Brendan Cully <brendan@cs.ubc.ca>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Haitao Shan <haitao.shan@intel.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@novell.com>
  Jan Beulich <jbeulich@suse.com>
  Jonathan Davies <jonathan.davies@citrix.com>
  juergen.gross@ts.fujitsu.com
  Keir Fraser <keir@xen.org>
  Liu, Jinsong <jinsong.liu@intel.com>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
  Philipp Hahn <hahn@univention.de>
  Shriram Rajagopalan <rshriram@cs.ubc.ca>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang2 <wei.wang2@amd.com>
  Xudong Hao <xudong.hao@intel.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 1366 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 19:07:38 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 19: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.xensource.com>)
	id 1RY0MM-00049h-JU; Tue, 06 Dec 2011 19:07:22 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RY0MK-00049L-Kg
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 19:07:20 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1323198394!884015!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjM3Ng==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22868 invoked from network); 6 Dec 2011 19:06:34 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Dec 2011 19:06:34 -0000
X-IronPort-AV: E=Sophos;i="4.71,307,1320624000"; 
   d="scan'208";a="9328920"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Dec 2011 19:06:33 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 6 Dec 2011 19:06:33 +0000
Date: Tue, 6 Dec 2011 19:07:36 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Jan Beulich <JBeulich@suse.com>
In-Reply-To: <4EDE367D0200007800065B6B@nat28.tlf.novell.com>
Message-ID: <alpine.DEB.2.00.1112061906550.31179@kaball-desktop>
References: <CAFQ2Z+fpR1UkxFEAYTD6irBUBeA3c7eJ3x1bXE0jzpdfQtH64w@mail.gmail.com>
	<alpine.DEB.2.00.1112021223190.31179@kaball-desktop>
	<4EDE367D0200007800065B6B@nat28.tlf.novell.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Haitao Shan <haitao.shan@intel.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Haitao Shan <maillists.shan@gmail.com>
Subject: Re: [Xen-devel] [PATCH] Qemu MSI Cleaning Up
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 6 Dec 2011, Jan Beulich wrote:
> >>> On 02.12.11 at 13:40, Stefano Stabellini <stefano.stabellini@eu.citrix.com> wrote:
> > The two mapping and unmapping big chuncks of code looks very similar
> > apart from the DPCI_ADD_MAPPING/DPCI_REMOVE_MAPPING parameter.
> > Could they be refactored into a single function called 
> > "change_msix_mappings"?
> > This is more or less what I have in mind:
> > 
> > change_msix_mappings(assigned_device, DPCI_REMOVE_MAPPING);
> > 
> > update mmio_base_addr
> > 
> > change_msix_mappings(assigned_device, DPCI_ADD_MAPPING);
> 
> Please see below/attached for the outcome. Without MSI-X capable
> devices to pass through, I have to rely on others to do some testing
> on this.

It looks fine.
Haitao, are you happy with the new patch?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 19:07:38 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 19: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.xensource.com>)
	id 1RY0MM-00049h-JU; Tue, 06 Dec 2011 19:07:22 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RY0MK-00049L-Kg
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 19:07:20 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1323198394!884015!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjM3Ng==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22868 invoked from network); 6 Dec 2011 19:06:34 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Dec 2011 19:06:34 -0000
X-IronPort-AV: E=Sophos;i="4.71,307,1320624000"; 
   d="scan'208";a="9328920"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Dec 2011 19:06:33 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 6 Dec 2011 19:06:33 +0000
Date: Tue, 6 Dec 2011 19:07:36 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Jan Beulich <JBeulich@suse.com>
In-Reply-To: <4EDE367D0200007800065B6B@nat28.tlf.novell.com>
Message-ID: <alpine.DEB.2.00.1112061906550.31179@kaball-desktop>
References: <CAFQ2Z+fpR1UkxFEAYTD6irBUBeA3c7eJ3x1bXE0jzpdfQtH64w@mail.gmail.com>
	<alpine.DEB.2.00.1112021223190.31179@kaball-desktop>
	<4EDE367D0200007800065B6B@nat28.tlf.novell.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Haitao Shan <haitao.shan@intel.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Haitao Shan <maillists.shan@gmail.com>
Subject: Re: [Xen-devel] [PATCH] Qemu MSI Cleaning Up
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 6 Dec 2011, Jan Beulich wrote:
> >>> On 02.12.11 at 13:40, Stefano Stabellini <stefano.stabellini@eu.citrix.com> wrote:
> > The two mapping and unmapping big chuncks of code looks very similar
> > apart from the DPCI_ADD_MAPPING/DPCI_REMOVE_MAPPING parameter.
> > Could they be refactored into a single function called 
> > "change_msix_mappings"?
> > This is more or less what I have in mind:
> > 
> > change_msix_mappings(assigned_device, DPCI_REMOVE_MAPPING);
> > 
> > update mmio_base_addr
> > 
> > change_msix_mappings(assigned_device, DPCI_ADD_MAPPING);
> 
> Please see below/attached for the outcome. Without MSI-X capable
> devices to pass through, I have to rely on others to do some testing
> on this.

It looks fine.
Haitao, are you happy with the new patch?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 19:13:43 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 19:13:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RY0SH-0004S8-EL; Tue, 06 Dec 2011 19:13:29 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <thunderbird2k@gmail.com>) id 1RY0SF-0004S3-U0
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 19:13:28 +0000
X-Env-Sender: thunderbird2k@gmail.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1323198760!4512752!1
X-Originating-IP: [209.85.161.171]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13908 invoked from network); 6 Dec 2011 19:12:41 -0000
Received: from mail-gx0-f171.google.com (HELO mail-gx0-f171.google.com)
	(209.85.161.171)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Dec 2011 19:12:41 -0000
Received: by ggnr4 with SMTP id r4so43599835ggn.30
	for <xen-devel@lists.xensource.com>;
	Tue, 06 Dec 2011 11:12:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=sEGRvemAQ9T7c1QkLqNYv2CqC/NN10d71toa/68eAYc=;
	b=tTLjNZ/g1x3a/e9rUd1tmaAtHIXs29yWE6uNA1GYbTsWQ07JUX6m38sgl4evGwQfeF
	sUefV1Uyl4eeSY+5vv9BcKxuDo5XBKAaedX0nI0o5HzuYH6H0rM2tL+yKTqu/7Emotfl
	kQtb5Muoyt3KLUriwly26gXwAN3UYPfzmN/lU=
MIME-Version: 1.0
Received: by 10.236.155.170 with SMTP id j30mr21481105yhk.56.1323198760139;
	Tue, 06 Dec 2011 11:12:40 -0800 (PST)
Received: by 10.100.48.10 with HTTP; Tue, 6 Dec 2011 11:12:40 -0800 (PST)
In-Reply-To: <CAEc3jaAO0JhtOt6phQHwtE_A+NF7uGHGZ8uJv3BirEYybfVceg@mail.gmail.com>
References: <CAEc3jaBds7xmiKH8RMfmEHQumkEeZ3PopVfbZPs_B-Kz8-DsWw@mail.gmail.com>
	<4ED51291.1010308@hfp.de>
	<CAEc3jaAa7y8C2NNBn1=L3AhS0uuYFP6ze8o1cZ9yG2VYHx6qMA@mail.gmail.com>
	<4ED5215D.1010403@hfp.de>
	<20111129230212.GA23958@andromeda.dapyr.net>
	<CAEc3jaAO0JhtOt6phQHwtE_A+NF7uGHGZ8uJv3BirEYybfVceg@mail.gmail.com>
Date: Tue, 6 Dec 2011 19:12:40 +0000
Message-ID: <CAEc3jaACffpr9D1Hq_012vHAGhPLEfvsZjh7YyJ=Q-3FdtHS0Q@mail.gmail.com>
From: Roderick Colenbrander <thunderbird2k@gmail.com>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
Cc: xen-devel@lists.xensource.com, Andreas Kinzler <ml-xen-devel@hfp.de>
Subject: Re: [Xen-devel] Questions about GPLPV stability tests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Nov 30, 2011 at 12:01 AM, Roderick Colenbrander
<thunderbird2k@gmail.com> wrote:
> On Tue, Nov 29, 2011 at 3:02 PM, Konrad Rzeszutek Wilk
> <konrad@darnok.org> wrote:
>> On Tue, Nov 29, 2011 at 07:15:57PM +0100, Andreas Kinzler wrote:
>>> >>Not in this year of my stability tests. In this year I am always
>>> >>experiencing crashes of domU only. dom0 was always stable.
>>> >>But last year, I hunted a very serious problem which causes nasty
>>> >>hangs/crashes in dom0 (which crashes domU as a consequence). See this
>>> >>mailing list post:
>>> >>http://lists.xen.org/archives/html/xen-devel/2010-09/msg00556.html
>>> >>In my tests it clearly shows that if you have a CPU without ARAT and you
>>> >>don't have the patch from my post, your Xen 4.0.1 or 4.1.1 will crash
>>> >>under
>>> >>load and/or after a while. What is your CPU?
>>> >Most of our machines use i7 950 CPUs. They don't seem to have ARAT.
>>>
>>> Yes, i7 950 does not have ARAT as it is the first Nehalem generation.
>>>
>>> >Some other machines use Xeon CPUs with ARAT support. We never had
>>> >issues on the Xeon systems, so we may actually be suffering from the
>>> >ARAT issue. Are you still using the patch you linked to in a
>>> >production environment?
>>>
>>> Absolutely. As I mentioned I just re-performed tests recently and found
>>> that even Xen 4.1.1 (earlier tests were for 4.0.1) is unstable without
>>> my patch on non-ARAT-CPUs.
>>
>> Did you try 4.1.2? This looks quite similar to one particular bug where
>> the vectors were not migrated properly.
>
> I haven't tried Xen 4.1.2 yet. We likely had the issue on Xen 4.0.1
> though our data is not conclusive. Was the Xen 4.1.2 bug you refer to
> also around in Xen 4.0.1?
>
> I'm still preparing our tests. Is there any special logging option
> which would be useful to log anything? All systems are now setup with
> serial consoles and we log Xen and Dom0 to there.
>
> Roderick

It took about a week, but the systems went down again. Linux is down,
but the hypervisor is still reachable on the serial console. Is there
anything interesting to dump from there?

Thanks,
Roderick

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 19:13:43 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 19:13:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RY0SH-0004S8-EL; Tue, 06 Dec 2011 19:13:29 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <thunderbird2k@gmail.com>) id 1RY0SF-0004S3-U0
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 19:13:28 +0000
X-Env-Sender: thunderbird2k@gmail.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1323198760!4512752!1
X-Originating-IP: [209.85.161.171]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13908 invoked from network); 6 Dec 2011 19:12:41 -0000
Received: from mail-gx0-f171.google.com (HELO mail-gx0-f171.google.com)
	(209.85.161.171)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Dec 2011 19:12:41 -0000
Received: by ggnr4 with SMTP id r4so43599835ggn.30
	for <xen-devel@lists.xensource.com>;
	Tue, 06 Dec 2011 11:12:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=sEGRvemAQ9T7c1QkLqNYv2CqC/NN10d71toa/68eAYc=;
	b=tTLjNZ/g1x3a/e9rUd1tmaAtHIXs29yWE6uNA1GYbTsWQ07JUX6m38sgl4evGwQfeF
	sUefV1Uyl4eeSY+5vv9BcKxuDo5XBKAaedX0nI0o5HzuYH6H0rM2tL+yKTqu/7Emotfl
	kQtb5Muoyt3KLUriwly26gXwAN3UYPfzmN/lU=
MIME-Version: 1.0
Received: by 10.236.155.170 with SMTP id j30mr21481105yhk.56.1323198760139;
	Tue, 06 Dec 2011 11:12:40 -0800 (PST)
Received: by 10.100.48.10 with HTTP; Tue, 6 Dec 2011 11:12:40 -0800 (PST)
In-Reply-To: <CAEc3jaAO0JhtOt6phQHwtE_A+NF7uGHGZ8uJv3BirEYybfVceg@mail.gmail.com>
References: <CAEc3jaBds7xmiKH8RMfmEHQumkEeZ3PopVfbZPs_B-Kz8-DsWw@mail.gmail.com>
	<4ED51291.1010308@hfp.de>
	<CAEc3jaAa7y8C2NNBn1=L3AhS0uuYFP6ze8o1cZ9yG2VYHx6qMA@mail.gmail.com>
	<4ED5215D.1010403@hfp.de>
	<20111129230212.GA23958@andromeda.dapyr.net>
	<CAEc3jaAO0JhtOt6phQHwtE_A+NF7uGHGZ8uJv3BirEYybfVceg@mail.gmail.com>
Date: Tue, 6 Dec 2011 19:12:40 +0000
Message-ID: <CAEc3jaACffpr9D1Hq_012vHAGhPLEfvsZjh7YyJ=Q-3FdtHS0Q@mail.gmail.com>
From: Roderick Colenbrander <thunderbird2k@gmail.com>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
Cc: xen-devel@lists.xensource.com, Andreas Kinzler <ml-xen-devel@hfp.de>
Subject: Re: [Xen-devel] Questions about GPLPV stability tests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Nov 30, 2011 at 12:01 AM, Roderick Colenbrander
<thunderbird2k@gmail.com> wrote:
> On Tue, Nov 29, 2011 at 3:02 PM, Konrad Rzeszutek Wilk
> <konrad@darnok.org> wrote:
>> On Tue, Nov 29, 2011 at 07:15:57PM +0100, Andreas Kinzler wrote:
>>> >>Not in this year of my stability tests. In this year I am always
>>> >>experiencing crashes of domU only. dom0 was always stable.
>>> >>But last year, I hunted a very serious problem which causes nasty
>>> >>hangs/crashes in dom0 (which crashes domU as a consequence). See this
>>> >>mailing list post:
>>> >>http://lists.xen.org/archives/html/xen-devel/2010-09/msg00556.html
>>> >>In my tests it clearly shows that if you have a CPU without ARAT and you
>>> >>don't have the patch from my post, your Xen 4.0.1 or 4.1.1 will crash
>>> >>under
>>> >>load and/or after a while. What is your CPU?
>>> >Most of our machines use i7 950 CPUs. They don't seem to have ARAT.
>>>
>>> Yes, i7 950 does not have ARAT as it is the first Nehalem generation.
>>>
>>> >Some other machines use Xeon CPUs with ARAT support. We never had
>>> >issues on the Xeon systems, so we may actually be suffering from the
>>> >ARAT issue. Are you still using the patch you linked to in a
>>> >production environment?
>>>
>>> Absolutely. As I mentioned I just re-performed tests recently and found
>>> that even Xen 4.1.1 (earlier tests were for 4.0.1) is unstable without
>>> my patch on non-ARAT-CPUs.
>>
>> Did you try 4.1.2? This looks quite similar to one particular bug where
>> the vectors were not migrated properly.
>
> I haven't tried Xen 4.1.2 yet. We likely had the issue on Xen 4.0.1
> though our data is not conclusive. Was the Xen 4.1.2 bug you refer to
> also around in Xen 4.0.1?
>
> I'm still preparing our tests. Is there any special logging option
> which would be useful to log anything? All systems are now setup with
> serial consoles and we log Xen and Dom0 to there.
>
> Roderick

It took about a week, but the systems went down again. Linux is down,
but the hypervisor is still reachable on the serial console. Is there
anything interesting to dump from there?

Thanks,
Roderick

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 19:59:43 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 19:59:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RY1AU-0004uQ-7r; Tue, 06 Dec 2011 19:59:10 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@cs.ubc.ca>) id 1RY1AS-0004u1-OR
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 19:59:08 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-4.tower-21.messagelabs.com!1323201499!888421!1
X-Originating-IP: [142.103.6.52]
X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11077 invoked from network); 6 Dec 2011 19:58:21 -0000
Received: from smtp.cs.ubc.ca (HELO smtp.cs.ubc.ca) (142.103.6.52)
	by server-4.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Dec 2011 19:58:21 -0000
Received: from mail-ey0-f171.google.com (mail-ey0-f171.google.com
	[209.85.215.171]) (authenticated bits=0)
	by smtp.cs.ubc.ca (8.14.3/8.13.6) with ESMTP id pB6JwHm6023132
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL)
	for <xen-devel@lists.xensource.com>; Tue, 6 Dec 2011 11:58:18 -0800
Received: by eaad12 with SMTP id d12so13968858eaa.30
	for <xen-devel@lists.xensource.com>;
	Tue, 06 Dec 2011 11:58:15 -0800 (PST)
Received: by 10.213.10.205 with SMTP id q13mr2789978ebq.119.1323201495572;
	Tue, 06 Dec 2011 11:58:15 -0800 (PST)
MIME-Version: 1.0
Received: by 10.204.179.10 with HTTP; Tue, 6 Dec 2011 11:57:34 -0800 (PST)
In-Reply-To: <CAP8mzPOSQePUySZirCLTh6K_uJ3pj3ws=4KR0y-ybFKObk0yGw@mail.gmail.com>
References: <152a79fbe918d8a6c63a.1323079622@cosworth.uk.xensource.com>
	<CAP8mzPOSQePUySZirCLTh6K_uJ3pj3ws=4KR0y-ybFKObk0yGw@mail.gmail.com>
From: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Date: Tue, 6 Dec 2011 11:57:34 -0800
Message-ID: <CAP8mzPOSJj-_qDw1oeOzTNZApNEv1TgMxqR00U0Er3CQjky9Mw@mail.gmail.com>
To: Paul Durrant <paul.durrant@citrix.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] VM generation ID save/restore and migrate
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: rshriram@cs.ubc.ca
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3215904565893804526=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============3215904565893804526==
Content-Type: multipart/alternative; boundary=0015174c134a1c231104b371dba8

--0015174c134a1c231104b371dba8
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Dec 6, 2011 at 11:56 AM, Shriram Rajagopalan <rshriram@cs.ubc.ca>wrote:

> On Mon, Dec 5, 2011 at 2:07 AM, Paul Durrant <paul.durrant@citrix.com>wrote:
>
>> diff -r a4d7c27ec1f1 -r 152a79fbe918 tools/xcutils/xc_restore.c
>> --- a/tools/xcutils/xc_restore.c        Fri Dec 02 13:51:17 2011 -0800
>> +++ b/tools/xcutils/xc_restore.c        Mon Dec 05 10:01:30 2011 +0000
>> @@ -23,7 +23,8 @@ main(int argc, char **argv)
>>     xc_interface *xch;
>>     int io_fd, ret;
>>     int superpages;
>> -    unsigned long store_mfn, console_mfn;
>> +    unsigned long store_mfn, console_mfn, vm_gid_addr;
>> +    int no_increment_gid;
>>
>>     if ( (argc != 8) && (argc != 9) )
>>         errx(1, "usage: %s iofd domid store_evtchn "
>> @@ -40,19 +41,25 @@ main(int argc, char **argv)
>>     hvm  = atoi(argv[5]);
>>     pae  = atoi(argv[6]);
>>     apic = atoi(argv[7]);
>> -    if ( argc == 9 )
>> +    if ( argc >= 9 )
>>            superpages = atoi(argv[8]);
>>     else
>>            superpages = !!hvm;
>> +    if ( argc >= 10 )
>> +           no_increment_gid = !atoi(argv[9]);
>> +    else
>> +           no_increment_gid = 0;
>>
>> There is a "if ( (argc != 8) && (argc != 9) ) err()" condition and then
> there is "if (argc >= 10)".
>
> shriram
>

forgot to cc xen-devel explicitly.

--0015174c134a1c231104b371dba8
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><div class=3D"gmail_quote">On Tue, Dec 6, 2011 at 11:56 AM, Shriram Raj=
agopalan <span dir=3D"ltr">&lt;<a href=3D"mailto:rshriram@cs.ubc.ca">rshrir=
am@cs.ubc.ca</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<div class=3D"gmail_quote"><div><div class=3D"h5">On Mon, Dec 5, 2011 at 2:=
07 AM, Paul Durrant <span dir=3D"ltr">&lt;<a href=3D"mailto:paul.durrant@ci=
trix.com" target=3D"_blank">paul.durrant@citrix.com</a>&gt;</span> wrote:<b=
r>
<blockquote class=3D"gmail_quote" style=3D"margin:0pt 0pt 0pt 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex">diff -r a4d7c27ec1f1 -r 1=
52a79fbe918 tools/xcutils/xc_restore.c<br>
--- a/tools/xcutils/xc_restore.c =A0 =A0 =A0 =A0Fri Dec 02 13:51:17 2011 -0=
800<br>
+++ b/tools/xcutils/xc_restore.c =A0 =A0 =A0 =A0Mon Dec 05 10:01:30 2011 +0=
000<br>
<div><div>@@ -23,7 +23,8 @@ main(int argc, char **argv)<br>
 =A0 =A0 xc_interface *xch;<br>
 =A0 =A0 int io_fd, ret;<br>
 =A0 =A0 int superpages;<br>
- =A0 =A0unsigned long store_mfn, console_mfn;<br>
+ =A0 =A0unsigned long store_mfn, console_mfn, vm_gid_addr;<br>
+ =A0 =A0int no_increment_gid;<br>
<br>
 =A0 =A0 if ( (argc !=3D 8) &amp;&amp; (argc !=3D 9) )<br>
 =A0 =A0 =A0 =A0 errx(1, &quot;usage: %s iofd domid store_evtchn &quot;<br>
@@ -40,19 +41,25 @@ main(int argc, char **argv)<br>
 =A0 =A0 hvm =A0=3D atoi(argv[5]);<br>
 =A0 =A0 pae =A0=3D atoi(argv[6]);<br>
 =A0 =A0 apic =3D atoi(argv[7]);<br>
- =A0 =A0if ( argc =3D=3D 9 )<br>
+ =A0 =A0if ( argc &gt;=3D 9 )<br>
 =A0 =A0 =A0 =A0 =A0 =A0superpages =3D atoi(argv[8]);<br>
 =A0 =A0 else<br>
 =A0 =A0 =A0 =A0 =A0 =A0superpages =3D !!hvm;<br>
+ =A0 =A0if ( argc &gt;=3D 10 )<br>
+ =A0 =A0 =A0 =A0 =A0 no_increment_gid =3D !atoi(argv[9]);<br>
+ =A0 =A0else<br>
+ =A0 =A0 =A0 =A0 =A0 no_increment_gid =3D 0;<br>
<br></div></div></blockquote></div></div><div>There is a &quot;if ( (argc !=
=3D 8) &amp;&amp; (argc !=3D 9) ) err()&quot; condition and then<br>there i=
s &quot;if (argc &gt;=3D 10)&quot;.<span class=3D"HOEnZb"><font color=3D"#8=
88888"><br>

</font></span></div><span class=3D"HOEnZb"><font color=3D"#888888"><br>shri=
ram<br></font></span></div>
</blockquote></div><br>forgot to cc xen-devel explicitly.<br>

--0015174c134a1c231104b371dba8--


--===============3215904565893804526==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============3215904565893804526==--


From xen-devel-bounces@lists.xensource.com Tue Dec 06 19:59:43 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 19:59:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RY1AU-0004uQ-7r; Tue, 06 Dec 2011 19:59:10 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@cs.ubc.ca>) id 1RY1AS-0004u1-OR
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 19:59:08 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-4.tower-21.messagelabs.com!1323201499!888421!1
X-Originating-IP: [142.103.6.52]
X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11077 invoked from network); 6 Dec 2011 19:58:21 -0000
Received: from smtp.cs.ubc.ca (HELO smtp.cs.ubc.ca) (142.103.6.52)
	by server-4.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Dec 2011 19:58:21 -0000
Received: from mail-ey0-f171.google.com (mail-ey0-f171.google.com
	[209.85.215.171]) (authenticated bits=0)
	by smtp.cs.ubc.ca (8.14.3/8.13.6) with ESMTP id pB6JwHm6023132
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL)
	for <xen-devel@lists.xensource.com>; Tue, 6 Dec 2011 11:58:18 -0800
Received: by eaad12 with SMTP id d12so13968858eaa.30
	for <xen-devel@lists.xensource.com>;
	Tue, 06 Dec 2011 11:58:15 -0800 (PST)
Received: by 10.213.10.205 with SMTP id q13mr2789978ebq.119.1323201495572;
	Tue, 06 Dec 2011 11:58:15 -0800 (PST)
MIME-Version: 1.0
Received: by 10.204.179.10 with HTTP; Tue, 6 Dec 2011 11:57:34 -0800 (PST)
In-Reply-To: <CAP8mzPOSQePUySZirCLTh6K_uJ3pj3ws=4KR0y-ybFKObk0yGw@mail.gmail.com>
References: <152a79fbe918d8a6c63a.1323079622@cosworth.uk.xensource.com>
	<CAP8mzPOSQePUySZirCLTh6K_uJ3pj3ws=4KR0y-ybFKObk0yGw@mail.gmail.com>
From: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Date: Tue, 6 Dec 2011 11:57:34 -0800
Message-ID: <CAP8mzPOSJj-_qDw1oeOzTNZApNEv1TgMxqR00U0Er3CQjky9Mw@mail.gmail.com>
To: Paul Durrant <paul.durrant@citrix.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] VM generation ID save/restore and migrate
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: rshriram@cs.ubc.ca
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3215904565893804526=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============3215904565893804526==
Content-Type: multipart/alternative; boundary=0015174c134a1c231104b371dba8

--0015174c134a1c231104b371dba8
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Dec 6, 2011 at 11:56 AM, Shriram Rajagopalan <rshriram@cs.ubc.ca>wrote:

> On Mon, Dec 5, 2011 at 2:07 AM, Paul Durrant <paul.durrant@citrix.com>wrote:
>
>> diff -r a4d7c27ec1f1 -r 152a79fbe918 tools/xcutils/xc_restore.c
>> --- a/tools/xcutils/xc_restore.c        Fri Dec 02 13:51:17 2011 -0800
>> +++ b/tools/xcutils/xc_restore.c        Mon Dec 05 10:01:30 2011 +0000
>> @@ -23,7 +23,8 @@ main(int argc, char **argv)
>>     xc_interface *xch;
>>     int io_fd, ret;
>>     int superpages;
>> -    unsigned long store_mfn, console_mfn;
>> +    unsigned long store_mfn, console_mfn, vm_gid_addr;
>> +    int no_increment_gid;
>>
>>     if ( (argc != 8) && (argc != 9) )
>>         errx(1, "usage: %s iofd domid store_evtchn "
>> @@ -40,19 +41,25 @@ main(int argc, char **argv)
>>     hvm  = atoi(argv[5]);
>>     pae  = atoi(argv[6]);
>>     apic = atoi(argv[7]);
>> -    if ( argc == 9 )
>> +    if ( argc >= 9 )
>>            superpages = atoi(argv[8]);
>>     else
>>            superpages = !!hvm;
>> +    if ( argc >= 10 )
>> +           no_increment_gid = !atoi(argv[9]);
>> +    else
>> +           no_increment_gid = 0;
>>
>> There is a "if ( (argc != 8) && (argc != 9) ) err()" condition and then
> there is "if (argc >= 10)".
>
> shriram
>

forgot to cc xen-devel explicitly.

--0015174c134a1c231104b371dba8
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><div class=3D"gmail_quote">On Tue, Dec 6, 2011 at 11:56 AM, Shriram Raj=
agopalan <span dir=3D"ltr">&lt;<a href=3D"mailto:rshriram@cs.ubc.ca">rshrir=
am@cs.ubc.ca</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<div class=3D"gmail_quote"><div><div class=3D"h5">On Mon, Dec 5, 2011 at 2:=
07 AM, Paul Durrant <span dir=3D"ltr">&lt;<a href=3D"mailto:paul.durrant@ci=
trix.com" target=3D"_blank">paul.durrant@citrix.com</a>&gt;</span> wrote:<b=
r>
<blockquote class=3D"gmail_quote" style=3D"margin:0pt 0pt 0pt 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex">diff -r a4d7c27ec1f1 -r 1=
52a79fbe918 tools/xcutils/xc_restore.c<br>
--- a/tools/xcutils/xc_restore.c =A0 =A0 =A0 =A0Fri Dec 02 13:51:17 2011 -0=
800<br>
+++ b/tools/xcutils/xc_restore.c =A0 =A0 =A0 =A0Mon Dec 05 10:01:30 2011 +0=
000<br>
<div><div>@@ -23,7 +23,8 @@ main(int argc, char **argv)<br>
 =A0 =A0 xc_interface *xch;<br>
 =A0 =A0 int io_fd, ret;<br>
 =A0 =A0 int superpages;<br>
- =A0 =A0unsigned long store_mfn, console_mfn;<br>
+ =A0 =A0unsigned long store_mfn, console_mfn, vm_gid_addr;<br>
+ =A0 =A0int no_increment_gid;<br>
<br>
 =A0 =A0 if ( (argc !=3D 8) &amp;&amp; (argc !=3D 9) )<br>
 =A0 =A0 =A0 =A0 errx(1, &quot;usage: %s iofd domid store_evtchn &quot;<br>
@@ -40,19 +41,25 @@ main(int argc, char **argv)<br>
 =A0 =A0 hvm =A0=3D atoi(argv[5]);<br>
 =A0 =A0 pae =A0=3D atoi(argv[6]);<br>
 =A0 =A0 apic =3D atoi(argv[7]);<br>
- =A0 =A0if ( argc =3D=3D 9 )<br>
+ =A0 =A0if ( argc &gt;=3D 9 )<br>
 =A0 =A0 =A0 =A0 =A0 =A0superpages =3D atoi(argv[8]);<br>
 =A0 =A0 else<br>
 =A0 =A0 =A0 =A0 =A0 =A0superpages =3D !!hvm;<br>
+ =A0 =A0if ( argc &gt;=3D 10 )<br>
+ =A0 =A0 =A0 =A0 =A0 no_increment_gid =3D !atoi(argv[9]);<br>
+ =A0 =A0else<br>
+ =A0 =A0 =A0 =A0 =A0 no_increment_gid =3D 0;<br>
<br></div></div></blockquote></div></div><div>There is a &quot;if ( (argc !=
=3D 8) &amp;&amp; (argc !=3D 9) ) err()&quot; condition and then<br>there i=
s &quot;if (argc &gt;=3D 10)&quot;.<span class=3D"HOEnZb"><font color=3D"#8=
88888"><br>

</font></span></div><span class=3D"HOEnZb"><font color=3D"#888888"><br>shri=
ram<br></font></span></div>
</blockquote></div><br>forgot to cc xen-devel explicitly.<br>

--0015174c134a1c231104b371dba8--


--===============3215904565893804526==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============3215904565893804526==--


From xen-devel-bounces@lists.xensource.com Tue Dec 06 20:17:10 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 20:17:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RY1RQ-0005T1-Co; Tue, 06 Dec 2011 20:16:40 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RY1RN-0005Su-OQ
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 20:16:38 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-2.tower-182.messagelabs.com!1323202550!6149004!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26018 invoked from network); 6 Dec 2011 20:15:51 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-2.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 6 Dec 2011 20:15:51 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RY1Qa-0009GW-Gt; Tue, 06 Dec 2011 20:15:48 +0000
Date: Tue, 6 Dec 2011 20:15:48 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20111206201548.GA31448@ocelot.phlegethon.org>
References: <patchbomb.1323097919@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <patchbomb.1323097919@xdev.gridcentric.ca>
User-Agent: Mutt/1.4.2.1i
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com, olaf@aepfle.de,
	keir.xen@gmail.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 0 of 5] Mem event interface improvements
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 10:11 -0500 on 05 Dec (1323079919), Andres Lagar-Cavilla wrote:
> In this patch series we add a series of improevements to the memory
> event interface. Namely:
> - Allow batched consumption of multiple outstanding responses
> - Signal Xen to consume responses solely with an event channel kick
> - Extra flag to tag events generated byforeign-domains
> - Allow placing dummy domains in the ring, to keep it in sync if
>  a state transition does not require an explicit response.

Applied, thanks.  I stripped out the 'MEM_EVENT_RSP' macros from patch
5, as they didn't seem useful now that it's just a flag, so you might
have to fix up your client code to match.

Cheers,

Tim.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 20:17:10 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 20:17:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RY1RQ-0005T1-Co; Tue, 06 Dec 2011 20:16:40 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RY1RN-0005Su-OQ
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 20:16:38 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-2.tower-182.messagelabs.com!1323202550!6149004!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26018 invoked from network); 6 Dec 2011 20:15:51 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-2.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 6 Dec 2011 20:15:51 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RY1Qa-0009GW-Gt; Tue, 06 Dec 2011 20:15:48 +0000
Date: Tue, 6 Dec 2011 20:15:48 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20111206201548.GA31448@ocelot.phlegethon.org>
References: <patchbomb.1323097919@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <patchbomb.1323097919@xdev.gridcentric.ca>
User-Agent: Mutt/1.4.2.1i
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com, olaf@aepfle.de,
	keir.xen@gmail.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 0 of 5] Mem event interface improvements
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 10:11 -0500 on 05 Dec (1323079919), Andres Lagar-Cavilla wrote:
> In this patch series we add a series of improevements to the memory
> event interface. Namely:
> - Allow batched consumption of multiple outstanding responses
> - Signal Xen to consume responses solely with an event channel kick
> - Extra flag to tag events generated byforeign-domains
> - Allow placing dummy domains in the ring, to keep it in sync if
>  a state transition does not require an explicit response.

Applied, thanks.  I stripped out the 'MEM_EVENT_RSP' macros from patch
5, as they didn't seem useful now that it's just a flag, so you might
have to fix up your client code to match.

Cheers,

Tim.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 20:40:10 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 20:40:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RY1n0-00063m-5w; Tue, 06 Dec 2011 20:38:58 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RY1my-00063b-Ob
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 20:38:57 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-5.tower-174.messagelabs.com!1323203889!4519190!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32072 invoked from network); 6 Dec 2011 20:38:10 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-5.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 6 Dec 2011 20:38:10 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RY1m9-0009KP-Ad; Tue, 06 Dec 2011 20:38:05 +0000
Date: Tue, 6 Dec 2011 20:38:05 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20111206203805.GB31448@ocelot.phlegethon.org>
References: <patchbomb.1322767496@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <patchbomb.1322767496@xdev.gridcentric.ca>
User-Agent: Mutt/1.4.2.1i
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com, keir.xen@gmail.com,
	JBeulich@suse.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 0 of 3] Mem access improvements and new type
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 14:24 -0500 on 01 Dec (1322749496), Andres Lagar-Cavilla wrote:
> We improve the handling of hap faults when both type and access
> restrictions are present.
> 
> We also add a new p2m access type, n2rwx. It allows for implement a "log
> access" mode in the hypervisor, aking to log dirty but for all types of
> accesses. Faults caused by this access mode automatically promote the
> access rights of the ofending p2m entry, place the event in the ring, and
> let the vcpu keep on executing.

Applied 1/3; thanks. 

The other two don't apply cleanly to xen-unstable.  have you got some
other patches in you local environment that touch the same parts of
p2m.c?  

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 20:40:10 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 20:40:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RY1n0-00063m-5w; Tue, 06 Dec 2011 20:38:58 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RY1my-00063b-Ob
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 20:38:57 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-5.tower-174.messagelabs.com!1323203889!4519190!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32072 invoked from network); 6 Dec 2011 20:38:10 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-5.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 6 Dec 2011 20:38:10 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RY1m9-0009KP-Ad; Tue, 06 Dec 2011 20:38:05 +0000
Date: Tue, 6 Dec 2011 20:38:05 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20111206203805.GB31448@ocelot.phlegethon.org>
References: <patchbomb.1322767496@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <patchbomb.1322767496@xdev.gridcentric.ca>
User-Agent: Mutt/1.4.2.1i
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com, keir.xen@gmail.com,
	JBeulich@suse.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 0 of 3] Mem access improvements and new type
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 14:24 -0500 on 01 Dec (1322749496), Andres Lagar-Cavilla wrote:
> We improve the handling of hap faults when both type and access
> restrictions are present.
> 
> We also add a new p2m access type, n2rwx. It allows for implement a "log
> access" mode in the hypervisor, aking to log dirty but for all types of
> accesses. Faults caused by this access mode automatically promote the
> access rights of the ofending p2m entry, place the event in the ring, and
> let the vcpu keep on executing.

Applied 1/3; thanks. 

The other two don't apply cleanly to xen-unstable.  have you got some
other patches in you local environment that touch the same parts of
p2m.c?  

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 20:40:26 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 20: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.xensource.com>)
	id 1RY1o1-00066Z-LK; Tue, 06 Dec 2011 20:40:01 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RY1nv-00065v-5q
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 20:40:00 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-3.tower-182.messagelabs.com!1323203948!6169914!1
X-Originating-IP: [208.97.132.207]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4yMDcgPT4gMTU3NTM=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28242 invoked from network); 6 Dec 2011 20:39:09 -0000
Received: from caiajhbdccah.dreamhost.com (HELO homiemail-a15.g.dreamhost.com)
	(208.97.132.207) by server-3.tower-182.messagelabs.com with SMTP;
	6 Dec 2011 20:39:09 -0000
Received: from homiemail-a15.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a15.g.dreamhost.com (Postfix) with ESMTP id 23CBE76C072;
	Tue,  6 Dec 2011 12:39:08 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=GI121mU/A+L5rrFGbe1kz/K4ft1ZV1x44/g0lJ+JwRfg
	XZd19HtkRtTN1smVr2WXc2KEbUfJ8B6Us2EjHuuKbaZyOiJKYg+PA1ngvOK+vG8A
	cgh1REdXpso/ERvudD6Eu28nUqq3suKaNqTL0Enr8tiVSncymnmFx8xKLp5hpcU=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=N74vnLVyJ7mI0XoVmPc/umGT+wg=; b=XKhJYmPN
	59L8btW/QdW14Nv5cPFTIIZL68SLQ5KI7/aYPXttEywhKCo2KFov1bwx/9qH/IEa
	eltiRP2TAgckcisPoONvcY7b0TkIkiB4vR3TL6FDeWoEvtA+1WKOlRkK8Ws9EYGq
	x/Y6lW9mfRSWRO+6G++M/y07drBa+7kFB2U=
Received: from webmail.lagarcavilla.org (ahfbbjcaiaae.dreamhost.com
	[75.119.208.4]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a15.g.dreamhost.com (Postfix) with ESMTPA id ABF6A76C065; 
	Tue,  6 Dec 2011 12:39:07 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP; Tue, 6 Dec 2011 12:39:08 -0800
Message-ID: <bfe52036cc6126c1b6a4c2e0cbf653d3.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20111206201548.GA31448@ocelot.phlegethon.org>
References: <patchbomb.1323097919@xdev.gridcentric.ca>
	<20111206201548.GA31448@ocelot.phlegethon.org>
Date: Tue, 6 Dec 2011 12:39:08 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Tim Deegan" <tim@xen.org>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: olaf@aepfle.de, xen-devel@lists.xensource.com, andres@gridcentric.ca,
	keir.xen@gmail.com, Andres Lagar-Cavilla <andres@lagarcavilla.org>,
	adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 0 of 5] Mem event interface improvements
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> At 10:11 -0500 on 05 Dec (1323079919), Andres Lagar-Cavilla wrote:
>> In this patch series we add a series of improevements to the memory
>> event interface. Namely:
>> - Allow batched consumption of multiple outstanding responses
>> - Signal Xen to consume responses solely with an event channel kick
>> - Extra flag to tag events generated byforeign-domains
>> - Allow placing dummy domains in the ring, to keep it in sync if
>>  a state transition does not require an explicit response.
>
> Applied, thanks.  I stripped out the 'MEM_EVENT_RSP' macros from patch
> 5, as they didn't seem useful now that it's just a flag, so you might
> have to fix up your client code to match.
>
> Cheers,
>
> Tim.
Thanks! no biggie about macros
Andres

>
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 20:40:26 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 20: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.xensource.com>)
	id 1RY1o1-00066Z-LK; Tue, 06 Dec 2011 20:40:01 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RY1nv-00065v-5q
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 20:40:00 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-3.tower-182.messagelabs.com!1323203948!6169914!1
X-Originating-IP: [208.97.132.207]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4yMDcgPT4gMTU3NTM=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28242 invoked from network); 6 Dec 2011 20:39:09 -0000
Received: from caiajhbdccah.dreamhost.com (HELO homiemail-a15.g.dreamhost.com)
	(208.97.132.207) by server-3.tower-182.messagelabs.com with SMTP;
	6 Dec 2011 20:39:09 -0000
Received: from homiemail-a15.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a15.g.dreamhost.com (Postfix) with ESMTP id 23CBE76C072;
	Tue,  6 Dec 2011 12:39:08 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=GI121mU/A+L5rrFGbe1kz/K4ft1ZV1x44/g0lJ+JwRfg
	XZd19HtkRtTN1smVr2WXc2KEbUfJ8B6Us2EjHuuKbaZyOiJKYg+PA1ngvOK+vG8A
	cgh1REdXpso/ERvudD6Eu28nUqq3suKaNqTL0Enr8tiVSncymnmFx8xKLp5hpcU=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=N74vnLVyJ7mI0XoVmPc/umGT+wg=; b=XKhJYmPN
	59L8btW/QdW14Nv5cPFTIIZL68SLQ5KI7/aYPXttEywhKCo2KFov1bwx/9qH/IEa
	eltiRP2TAgckcisPoONvcY7b0TkIkiB4vR3TL6FDeWoEvtA+1WKOlRkK8Ws9EYGq
	x/Y6lW9mfRSWRO+6G++M/y07drBa+7kFB2U=
Received: from webmail.lagarcavilla.org (ahfbbjcaiaae.dreamhost.com
	[75.119.208.4]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a15.g.dreamhost.com (Postfix) with ESMTPA id ABF6A76C065; 
	Tue,  6 Dec 2011 12:39:07 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP; Tue, 6 Dec 2011 12:39:08 -0800
Message-ID: <bfe52036cc6126c1b6a4c2e0cbf653d3.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20111206201548.GA31448@ocelot.phlegethon.org>
References: <patchbomb.1323097919@xdev.gridcentric.ca>
	<20111206201548.GA31448@ocelot.phlegethon.org>
Date: Tue, 6 Dec 2011 12:39:08 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Tim Deegan" <tim@xen.org>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: olaf@aepfle.de, xen-devel@lists.xensource.com, andres@gridcentric.ca,
	keir.xen@gmail.com, Andres Lagar-Cavilla <andres@lagarcavilla.org>,
	adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 0 of 5] Mem event interface improvements
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> At 10:11 -0500 on 05 Dec (1323079919), Andres Lagar-Cavilla wrote:
>> In this patch series we add a series of improevements to the memory
>> event interface. Namely:
>> - Allow batched consumption of multiple outstanding responses
>> - Signal Xen to consume responses solely with an event channel kick
>> - Extra flag to tag events generated byforeign-domains
>> - Allow placing dummy domains in the ring, to keep it in sync if
>>  a state transition does not require an explicit response.
>
> Applied, thanks.  I stripped out the 'MEM_EVENT_RSP' macros from patch
> 5, as they didn't seem useful now that it's just a flag, so you might
> have to fix up your client code to match.
>
> Cheers,
>
> Tim.
Thanks! no biggie about macros
Andres

>
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 21:04:53 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 21:04:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RY2Bi-0006TC-7S; Tue, 06 Dec 2011 21:04:30 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RY2Bg-0006Sw-EP
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 21:04:28 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-15.tower-21.messagelabs.com!1323205421!7181609!1
X-Originating-IP: [208.97.132.119]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xMTkgPT4gMTYxMDc=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20844 invoked from network); 6 Dec 2011 21:03:42 -0000
Received: from caiajhbdcbbj.dreamhost.com (HELO homiemail-a20.g.dreamhost.com)
	(208.97.132.119) by server-15.tower-21.messagelabs.com with SMTP;
	6 Dec 2011 21:03:42 -0000
Received: from homiemail-a20.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTP id 1B9C47EC060;
	Tue,  6 Dec 2011 13:03:41 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=UsEBALej3Gztey8C0vvOhnNnVWM2gSS8EdEf2O9h3S73
	uADgDOtMZkx+lvHCf7HvVkRqG8Bd3kIsm0wFb4LK1hzEmpnqxdJG7gu/iDXm0KtA
	8PR9gczSgtWjPgSleXp5XtRioPMkzW9AcAzxxOk5d58zjiVJFe7RsYEhct2nzgQ=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=gKTwNUkhC3ls33u+MVePmxrwmEg=; b=TkOvzPOfR8f
	ojnoQHtQEgJ+CSigpb4llYAde2EuYw7uqAvWdtZ2j8gP73FSdfMS6gZ7rbuFI4a0
	Mu+uNUo2Ogyo0Ek/sX+CCkkMwO+V5/2YL08Il9We3j0eA+jyC3H1rs87Mb8U+DKc
	tBzJzSUvbGRrfFHO4BRskUFX5Xlmv05A=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTPSA id 1F0647EC061; 
	Tue,  6 Dec 2011 13:03:39 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 66ca1a02082f396fc3f6319c223af22b2ea52089
Message-Id: <66ca1a02082f396fc3f6.1323205471@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1323205469@xdev.gridcentric.ca>
References: <patchbomb.1323205469@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Tue, 06 Dec 2011 16:04:31 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: keir.xen@gmail.com, time@xen.org, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 2 of 2] x86/mm: New mem access type to log access
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/hvm/hvm.c          |   1 +
 xen/arch/x86/mm/p2m-ept.c       |   1 +
 xen/arch/x86/mm/p2m.c           |  30 +++++++++++++++++++++---------
 xen/include/asm-x86/p2m.h       |   3 +++
 xen/include/public/hvm/hvm_op.h |   3 +++
 5 files changed, 29 insertions(+), 9 deletions(-)


This patch adds a new p2m access type, n2rwx. It allows for implement a "log
access" mode in the hypervisor, aking to log dirty but for all types of
accesses. Faults caused by this access mode automatically promote the
access rights of the ofending p2m entry, place the event in the ring, and
let the vcpu keep on executing.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Signed-off-by: Adin Scannell <adin@scannell.ca>

diff -r e315ce73f082 -r 66ca1a02082f xen/arch/x86/hvm/hvm.c
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -1250,6 +1250,7 @@ int hvm_hap_nested_page_fault(unsigned l
         switch (p2ma) 
         {
         case p2m_access_n:
+        case p2m_access_n2rwx:
         default:
             violation = access_r || access_w || access_x;
             break;
diff -r e315ce73f082 -r 66ca1a02082f xen/arch/x86/mm/p2m-ept.c
--- a/xen/arch/x86/mm/p2m-ept.c
+++ b/xen/arch/x86/mm/p2m-ept.c
@@ -111,6 +111,7 @@ static void ept_p2m_type_to_flags(ept_en
     switch (access) 
     {
         case p2m_access_n:
+        case p2m_access_n2rwx:
             entry->r = entry->w = entry->x = 0;
             break;
         case p2m_access_r:
diff -r e315ce73f082 -r 66ca1a02082f xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -1107,6 +1107,11 @@ bool_t p2m_mem_access_check(unsigned lon
         p2m_unlock(p2m);
         return 1;
     }
+    else if ( p2ma == p2m_access_n2rwx )
+    {
+        ASSERT(access_w || access_r || access_x);
+        p2m->set_entry(p2m, gfn, mfn, PAGE_ORDER_4K, p2mt, p2m_access_rwx);
+    }
     p2m_unlock(p2m);
 
     /* Otherwise, check if there is a memory event listener, and send the message along */
@@ -1124,10 +1129,13 @@ bool_t p2m_mem_access_check(unsigned lon
         }
         else
         {
-            /* A listener is not required, so clear the access restrictions */
-            p2m_lock(p2m);
-            p2m->set_entry(p2m, gfn, mfn, PAGE_ORDER_4K, p2mt, p2m_access_rwx);
-            p2m_unlock(p2m);
+            if ( p2ma != p2m_access_n2rwx )
+            {
+                /* A listener is not required, so clear the access restrictions */
+                p2m_lock(p2m);
+                p2m->set_entry(p2m, gfn, mfn, PAGE_ORDER_4K, p2mt, p2m_access_rwx);
+                p2m_unlock(p2m);
+            }
             return 1;
         }
 
@@ -1140,9 +1148,12 @@ bool_t p2m_mem_access_check(unsigned lon
     req.type = MEM_EVENT_TYPE_ACCESS;
     req.reason = MEM_EVENT_REASON_VIOLATION;
 
-    /* Pause the current VCPU unconditionally */
-    vcpu_pause_nosync(v);
-    req.flags |= MEM_EVENT_FLAG_VCPU_PAUSED;    
+    /* Pause the current VCPU */
+    if ( p2ma != p2m_access_n2rwx )
+    {
+        vcpu_pause_nosync(v);
+        req.flags |= MEM_EVENT_FLAG_VCPU_PAUSED;
+    } 
 
     /* Send request to mem event */
     req.gfn = gfn;
@@ -1157,8 +1168,8 @@ bool_t p2m_mem_access_check(unsigned lon
 
     mem_event_put_request(d, &d->mem_event->access, &req);
 
-    /* VCPU paused, mem event request sent */
-    return 0;
+    /* VCPU may be paused, return whether we promoted automatically */
+    return (p2ma == p2m_access_n2rwx);
 }
 
 void p2m_mem_access_resume(struct domain *d)
@@ -1204,6 +1215,7 @@ int p2m_set_mem_access(struct domain *d,
         p2m_access_wx,
         p2m_access_rwx,
         p2m_access_rx2rw,
+        p2m_access_n2rwx,
         p2m->default_access,
     };
 
diff -r e315ce73f082 -r 66ca1a02082f xen/include/asm-x86/p2m.h
--- a/xen/include/asm-x86/p2m.h
+++ b/xen/include/asm-x86/p2m.h
@@ -108,6 +108,9 @@ typedef enum {
     p2m_access_wx    = 6, 
     p2m_access_rwx   = 7,
     p2m_access_rx2rw = 8, /* Special: page goes from RX to RW on write */
+    p2m_access_n2rwx = 9, /* Special: page goes from N to RWX on access, *
+                           * generates an event but does not pause the
+                           * vcpu */
 
     /* NOTE: Assumed to be only 4 bits right now */
 } p2m_access_t;
diff -r e315ce73f082 -r 66ca1a02082f xen/include/public/hvm/hvm_op.h
--- a/xen/include/public/hvm/hvm_op.h
+++ b/xen/include/public/hvm/hvm_op.h
@@ -174,6 +174,9 @@ typedef enum {
     HVMMEM_access_rwx,
     HVMMEM_access_rx2rw,       /* Page starts off as r-x, but automatically
                                 * change to r-w on a write */
+    HVMMEM_access_n2rwx,       /* Log access: starts off as n, automatically 
+                                * goes to rwx, generating an event without
+                                * pausing the vcpu */
     HVMMEM_access_default      /* Take the domain default */
 } hvmmem_access_t;
 /* Notify that a region of memory is to have specific access types */

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 21:04:53 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 21:04:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RY2Bi-0006TC-7S; Tue, 06 Dec 2011 21:04:30 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RY2Bg-0006Sw-EP
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 21:04:28 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-15.tower-21.messagelabs.com!1323205421!7181609!1
X-Originating-IP: [208.97.132.119]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xMTkgPT4gMTYxMDc=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20844 invoked from network); 6 Dec 2011 21:03:42 -0000
Received: from caiajhbdcbbj.dreamhost.com (HELO homiemail-a20.g.dreamhost.com)
	(208.97.132.119) by server-15.tower-21.messagelabs.com with SMTP;
	6 Dec 2011 21:03:42 -0000
Received: from homiemail-a20.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTP id 1B9C47EC060;
	Tue,  6 Dec 2011 13:03:41 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=UsEBALej3Gztey8C0vvOhnNnVWM2gSS8EdEf2O9h3S73
	uADgDOtMZkx+lvHCf7HvVkRqG8Bd3kIsm0wFb4LK1hzEmpnqxdJG7gu/iDXm0KtA
	8PR9gczSgtWjPgSleXp5XtRioPMkzW9AcAzxxOk5d58zjiVJFe7RsYEhct2nzgQ=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=gKTwNUkhC3ls33u+MVePmxrwmEg=; b=TkOvzPOfR8f
	ojnoQHtQEgJ+CSigpb4llYAde2EuYw7uqAvWdtZ2j8gP73FSdfMS6gZ7rbuFI4a0
	Mu+uNUo2Ogyo0Ek/sX+CCkkMwO+V5/2YL08Il9We3j0eA+jyC3H1rs87Mb8U+DKc
	tBzJzSUvbGRrfFHO4BRskUFX5Xlmv05A=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTPSA id 1F0647EC061; 
	Tue,  6 Dec 2011 13:03:39 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 66ca1a02082f396fc3f6319c223af22b2ea52089
Message-Id: <66ca1a02082f396fc3f6.1323205471@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1323205469@xdev.gridcentric.ca>
References: <patchbomb.1323205469@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Tue, 06 Dec 2011 16:04:31 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: keir.xen@gmail.com, time@xen.org, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 2 of 2] x86/mm: New mem access type to log access
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/hvm/hvm.c          |   1 +
 xen/arch/x86/mm/p2m-ept.c       |   1 +
 xen/arch/x86/mm/p2m.c           |  30 +++++++++++++++++++++---------
 xen/include/asm-x86/p2m.h       |   3 +++
 xen/include/public/hvm/hvm_op.h |   3 +++
 5 files changed, 29 insertions(+), 9 deletions(-)


This patch adds a new p2m access type, n2rwx. It allows for implement a "log
access" mode in the hypervisor, aking to log dirty but for all types of
accesses. Faults caused by this access mode automatically promote the
access rights of the ofending p2m entry, place the event in the ring, and
let the vcpu keep on executing.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Signed-off-by: Adin Scannell <adin@scannell.ca>

diff -r e315ce73f082 -r 66ca1a02082f xen/arch/x86/hvm/hvm.c
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -1250,6 +1250,7 @@ int hvm_hap_nested_page_fault(unsigned l
         switch (p2ma) 
         {
         case p2m_access_n:
+        case p2m_access_n2rwx:
         default:
             violation = access_r || access_w || access_x;
             break;
diff -r e315ce73f082 -r 66ca1a02082f xen/arch/x86/mm/p2m-ept.c
--- a/xen/arch/x86/mm/p2m-ept.c
+++ b/xen/arch/x86/mm/p2m-ept.c
@@ -111,6 +111,7 @@ static void ept_p2m_type_to_flags(ept_en
     switch (access) 
     {
         case p2m_access_n:
+        case p2m_access_n2rwx:
             entry->r = entry->w = entry->x = 0;
             break;
         case p2m_access_r:
diff -r e315ce73f082 -r 66ca1a02082f xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -1107,6 +1107,11 @@ bool_t p2m_mem_access_check(unsigned lon
         p2m_unlock(p2m);
         return 1;
     }
+    else if ( p2ma == p2m_access_n2rwx )
+    {
+        ASSERT(access_w || access_r || access_x);
+        p2m->set_entry(p2m, gfn, mfn, PAGE_ORDER_4K, p2mt, p2m_access_rwx);
+    }
     p2m_unlock(p2m);
 
     /* Otherwise, check if there is a memory event listener, and send the message along */
@@ -1124,10 +1129,13 @@ bool_t p2m_mem_access_check(unsigned lon
         }
         else
         {
-            /* A listener is not required, so clear the access restrictions */
-            p2m_lock(p2m);
-            p2m->set_entry(p2m, gfn, mfn, PAGE_ORDER_4K, p2mt, p2m_access_rwx);
-            p2m_unlock(p2m);
+            if ( p2ma != p2m_access_n2rwx )
+            {
+                /* A listener is not required, so clear the access restrictions */
+                p2m_lock(p2m);
+                p2m->set_entry(p2m, gfn, mfn, PAGE_ORDER_4K, p2mt, p2m_access_rwx);
+                p2m_unlock(p2m);
+            }
             return 1;
         }
 
@@ -1140,9 +1148,12 @@ bool_t p2m_mem_access_check(unsigned lon
     req.type = MEM_EVENT_TYPE_ACCESS;
     req.reason = MEM_EVENT_REASON_VIOLATION;
 
-    /* Pause the current VCPU unconditionally */
-    vcpu_pause_nosync(v);
-    req.flags |= MEM_EVENT_FLAG_VCPU_PAUSED;    
+    /* Pause the current VCPU */
+    if ( p2ma != p2m_access_n2rwx )
+    {
+        vcpu_pause_nosync(v);
+        req.flags |= MEM_EVENT_FLAG_VCPU_PAUSED;
+    } 
 
     /* Send request to mem event */
     req.gfn = gfn;
@@ -1157,8 +1168,8 @@ bool_t p2m_mem_access_check(unsigned lon
 
     mem_event_put_request(d, &d->mem_event->access, &req);
 
-    /* VCPU paused, mem event request sent */
-    return 0;
+    /* VCPU may be paused, return whether we promoted automatically */
+    return (p2ma == p2m_access_n2rwx);
 }
 
 void p2m_mem_access_resume(struct domain *d)
@@ -1204,6 +1215,7 @@ int p2m_set_mem_access(struct domain *d,
         p2m_access_wx,
         p2m_access_rwx,
         p2m_access_rx2rw,
+        p2m_access_n2rwx,
         p2m->default_access,
     };
 
diff -r e315ce73f082 -r 66ca1a02082f xen/include/asm-x86/p2m.h
--- a/xen/include/asm-x86/p2m.h
+++ b/xen/include/asm-x86/p2m.h
@@ -108,6 +108,9 @@ typedef enum {
     p2m_access_wx    = 6, 
     p2m_access_rwx   = 7,
     p2m_access_rx2rw = 8, /* Special: page goes from RX to RW on write */
+    p2m_access_n2rwx = 9, /* Special: page goes from N to RWX on access, *
+                           * generates an event but does not pause the
+                           * vcpu */
 
     /* NOTE: Assumed to be only 4 bits right now */
 } p2m_access_t;
diff -r e315ce73f082 -r 66ca1a02082f xen/include/public/hvm/hvm_op.h
--- a/xen/include/public/hvm/hvm_op.h
+++ b/xen/include/public/hvm/hvm_op.h
@@ -174,6 +174,9 @@ typedef enum {
     HVMMEM_access_rwx,
     HVMMEM_access_rx2rw,       /* Page starts off as r-x, but automatically
                                 * change to r-w on a write */
+    HVMMEM_access_n2rwx,       /* Log access: starts off as n, automatically 
+                                * goes to rwx, generating an event without
+                                * pausing the vcpu */
     HVMMEM_access_default      /* Take the domain default */
 } hvmmem_access_t;
 /* Notify that a region of memory is to have specific access types */

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 21:04:55 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 21:04:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RY2Bh-0006T5-QG; Tue, 06 Dec 2011 21:04:29 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RY2Bf-0006Sv-NE
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 21:04:28 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-10.tower-174.messagelabs.com!1323205420!4516418!1
X-Originating-IP: [208.97.132.207]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4yMDcgPT4gMTU3NTM=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29691 invoked from network); 6 Dec 2011 21:03:40 -0000
Received: from caiajhbdccah.dreamhost.com (HELO homiemail-a20.g.dreamhost.com)
	(208.97.132.207) by server-10.tower-174.messagelabs.com with SMTP;
	6 Dec 2011 21:03:40 -0000
Received: from homiemail-a20.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTP id D58AE7EC065;
	Tue,  6 Dec 2011 13:03:39 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=N+pZQIQLklIN/DRcdzhDM0IemQMkgX4HyFoURbvHy8jG
	w8OLQ3+eIt8gnzrnTtvQw2SlHZMYcW6yHsjS782J02aiN8l9Ybn46cPTc6rxGPRK
	kF+5D8/vIZV7FPIPxLm1QoO4u6yF6UgpDpDzBe8QPIEaVEKiB6gPhA6eDQDTfS4=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=kqcc9zyCPJrg/08kydRdSAagMYA=; b=DjXjgGkMJDk
	tHb9DhwxK9aUYNYGxLNlcBgFo1E00whaQfFXEHTu91brVzvO54pT8zDuT4UMbvI+
	vZs+VzO0Qis+zXZUHwWjO5xwImZlBabwc+LmizBr1k/HGVfZZbpd5490G+xE20ht
	6zHSyQIZXPiLysGgP+4VKUjs1+XvKQZM=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTPSA id 235887EC061; 
	Tue,  6 Dec 2011 13:03:39 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: e315ce73f082585b13104b099ff5fef9144cafb1
Message-Id: <e315ce73f082585b1310.1323205470@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1323205469@xdev.gridcentric.ca>
References: <patchbomb.1323205469@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Tue, 06 Dec 2011 16:04:30 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: keir.xen@gmail.com, time@xen.org, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 1 of 2] x86/mm: When mem event automatically
 promotes access rights, let other subsystems know
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/hvm/hvm.c    |  20 +++++++++++++++-----
 xen/arch/x86/mm/p2m.c     |  10 ++++++----
 xen/include/asm-x86/p2m.h |   9 +++++----
 3 files changed, 26 insertions(+), 13 deletions(-)


The mem event fault handler in the p2m can automatically promote the access
rights of a p2m entry. In those scenarios, vcpu's are not paused and they will
immediately retry the faulting instructions. This will generate a second fault
if the underlying entry type requires so (paging, unsharing, pod, etc).
Collapse the two faults into a single one.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 3c240efdd6ad -r e315ce73f082 xen/arch/x86/hvm/hvm.c
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -1205,7 +1205,7 @@ int hvm_hap_nested_page_fault(unsigned l
     mfn_t mfn;
     struct vcpu *v = current;
     struct p2m_domain *p2m;
-    int rc;
+    int rc, fall_through = 0;
 
     /* On Nested Virtualization, walk the guest page table.
      * If this succeeds, all is fine.
@@ -1278,9 +1278,15 @@ int hvm_hap_nested_page_fault(unsigned l
 
         if ( violation )
         {
-            p2m_mem_access_check(gpa, gla_valid, gla, access_r, access_w, access_x);
-            rc = 1;
-            goto out_put_gfn;
+            if ( p2m_mem_access_check(gpa, gla_valid, gla, access_r, 
+                                        access_w, access_x) )
+            {
+                fall_through = 1;
+            } else {
+                /* Rights not promoted, vcpu paused, work here is done */
+                rc = 1;
+                goto out_put_gfn;
+            }
         }
     }
 
@@ -1339,7 +1345,11 @@ int hvm_hap_nested_page_fault(unsigned l
         goto out_put_gfn;
     }
 
-    rc = 0;
+    /* 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. */
+    rc = fall_through;
+
 out_put_gfn:
     put_gfn(p2m->domain, gfn);
     return rc;
diff -r 3c240efdd6ad -r e315ce73f082 xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -1084,7 +1084,7 @@ void p2m_mem_paging_resume(struct domain
     mem_event_unpause_vcpus(d);
 }
 
-void p2m_mem_access_check(unsigned long gpa, bool_t gla_valid, unsigned long gla, 
+bool_t p2m_mem_access_check(unsigned long gpa, bool_t gla_valid, unsigned long gla, 
                           bool_t access_r, bool_t access_w, bool_t access_x)
 {
     struct vcpu *v = current;
@@ -1105,7 +1105,7 @@ void p2m_mem_access_check(unsigned long 
     {
         p2m->set_entry(p2m, gfn, mfn, PAGE_ORDER_4K, p2mt, p2m_access_rw);
         p2m_unlock(p2m);
-        return;
+        return 1;
     }
     p2m_unlock(p2m);
 
@@ -1128,12 +1128,13 @@ void p2m_mem_access_check(unsigned long 
             p2m_lock(p2m);
             p2m->set_entry(p2m, gfn, mfn, PAGE_ORDER_4K, p2mt, p2m_access_rwx);
             p2m_unlock(p2m);
+            return 1;
         }
 
-        return;
+        return 0;
     }
     else if ( res > 0 )
-        return;  /* No space in buffer; VCPU paused */
+        return 0;  /* No space in buffer; VCPU paused */
 
     memset(&req, 0, sizeof(req));
     req.type = MEM_EVENT_TYPE_ACCESS;
@@ -1157,6 +1158,7 @@ void p2m_mem_access_check(unsigned long 
     mem_event_put_request(d, &d->mem_event->access, &req);
 
     /* VCPU paused, mem event request sent */
+    return 0;
 }
 
 void p2m_mem_access_resume(struct domain *d)
diff -r 3c240efdd6ad -r e315ce73f082 xen/include/asm-x86/p2m.h
--- a/xen/include/asm-x86/p2m.h
+++ b/xen/include/asm-x86/p2m.h
@@ -491,8 +491,9 @@ static inline void p2m_mem_paging_popula
 
 #ifdef __x86_64__
 /* Send mem event based on the access (gla is -1ull if not available).  Handles
- * the rw2rx conversion */
-void p2m_mem_access_check(unsigned long gpa, bool_t gla_valid, unsigned long gla, 
+ * the rw2rx conversion. Boolean return value indicates if access rights have 
+ * been promoted with no underlying vcpu pause. */
+bool_t p2m_mem_access_check(unsigned long gpa, bool_t gla_valid, unsigned long gla, 
                           bool_t access_r, bool_t access_w, bool_t access_x);
 /* Resumes the running of the VCPU, restarting the last instruction */
 void p2m_mem_access_resume(struct domain *d);
@@ -508,10 +509,10 @@ int p2m_get_mem_access(struct domain *d,
                        hvmmem_access_t *access);
 
 #else
-static inline void p2m_mem_access_check(unsigned long gpa, bool_t gla_valid, 
+static inline bool_t p2m_mem_access_check(unsigned long gpa, bool_t gla_valid, 
                                         unsigned long gla, bool_t access_r, 
                                         bool_t access_w, bool_t access_x)
-{ }
+{ return 1; }
 static inline int p2m_set_mem_access(struct domain *d, 
                                      unsigned long start_pfn, 
                                      uint32_t nr, hvmmem_access_t access)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 21:04:55 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 21:04:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RY2Bh-0006T5-QG; Tue, 06 Dec 2011 21:04:29 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RY2Bf-0006Sv-NE
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 21:04:28 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-10.tower-174.messagelabs.com!1323205420!4516418!1
X-Originating-IP: [208.97.132.207]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4yMDcgPT4gMTU3NTM=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29691 invoked from network); 6 Dec 2011 21:03:40 -0000
Received: from caiajhbdccah.dreamhost.com (HELO homiemail-a20.g.dreamhost.com)
	(208.97.132.207) by server-10.tower-174.messagelabs.com with SMTP;
	6 Dec 2011 21:03:40 -0000
Received: from homiemail-a20.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTP id D58AE7EC065;
	Tue,  6 Dec 2011 13:03:39 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=N+pZQIQLklIN/DRcdzhDM0IemQMkgX4HyFoURbvHy8jG
	w8OLQ3+eIt8gnzrnTtvQw2SlHZMYcW6yHsjS782J02aiN8l9Ybn46cPTc6rxGPRK
	kF+5D8/vIZV7FPIPxLm1QoO4u6yF6UgpDpDzBe8QPIEaVEKiB6gPhA6eDQDTfS4=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=kqcc9zyCPJrg/08kydRdSAagMYA=; b=DjXjgGkMJDk
	tHb9DhwxK9aUYNYGxLNlcBgFo1E00whaQfFXEHTu91brVzvO54pT8zDuT4UMbvI+
	vZs+VzO0Qis+zXZUHwWjO5xwImZlBabwc+LmizBr1k/HGVfZZbpd5490G+xE20ht
	6zHSyQIZXPiLysGgP+4VKUjs1+XvKQZM=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTPSA id 235887EC061; 
	Tue,  6 Dec 2011 13:03:39 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: e315ce73f082585b13104b099ff5fef9144cafb1
Message-Id: <e315ce73f082585b1310.1323205470@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1323205469@xdev.gridcentric.ca>
References: <patchbomb.1323205469@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Tue, 06 Dec 2011 16:04:30 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: keir.xen@gmail.com, time@xen.org, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 1 of 2] x86/mm: When mem event automatically
 promotes access rights, let other subsystems know
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/hvm/hvm.c    |  20 +++++++++++++++-----
 xen/arch/x86/mm/p2m.c     |  10 ++++++----
 xen/include/asm-x86/p2m.h |   9 +++++----
 3 files changed, 26 insertions(+), 13 deletions(-)


The mem event fault handler in the p2m can automatically promote the access
rights of a p2m entry. In those scenarios, vcpu's are not paused and they will
immediately retry the faulting instructions. This will generate a second fault
if the underlying entry type requires so (paging, unsharing, pod, etc).
Collapse the two faults into a single one.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 3c240efdd6ad -r e315ce73f082 xen/arch/x86/hvm/hvm.c
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -1205,7 +1205,7 @@ int hvm_hap_nested_page_fault(unsigned l
     mfn_t mfn;
     struct vcpu *v = current;
     struct p2m_domain *p2m;
-    int rc;
+    int rc, fall_through = 0;
 
     /* On Nested Virtualization, walk the guest page table.
      * If this succeeds, all is fine.
@@ -1278,9 +1278,15 @@ int hvm_hap_nested_page_fault(unsigned l
 
         if ( violation )
         {
-            p2m_mem_access_check(gpa, gla_valid, gla, access_r, access_w, access_x);
-            rc = 1;
-            goto out_put_gfn;
+            if ( p2m_mem_access_check(gpa, gla_valid, gla, access_r, 
+                                        access_w, access_x) )
+            {
+                fall_through = 1;
+            } else {
+                /* Rights not promoted, vcpu paused, work here is done */
+                rc = 1;
+                goto out_put_gfn;
+            }
         }
     }
 
@@ -1339,7 +1345,11 @@ int hvm_hap_nested_page_fault(unsigned l
         goto out_put_gfn;
     }
 
-    rc = 0;
+    /* 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. */
+    rc = fall_through;
+
 out_put_gfn:
     put_gfn(p2m->domain, gfn);
     return rc;
diff -r 3c240efdd6ad -r e315ce73f082 xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -1084,7 +1084,7 @@ void p2m_mem_paging_resume(struct domain
     mem_event_unpause_vcpus(d);
 }
 
-void p2m_mem_access_check(unsigned long gpa, bool_t gla_valid, unsigned long gla, 
+bool_t p2m_mem_access_check(unsigned long gpa, bool_t gla_valid, unsigned long gla, 
                           bool_t access_r, bool_t access_w, bool_t access_x)
 {
     struct vcpu *v = current;
@@ -1105,7 +1105,7 @@ void p2m_mem_access_check(unsigned long 
     {
         p2m->set_entry(p2m, gfn, mfn, PAGE_ORDER_4K, p2mt, p2m_access_rw);
         p2m_unlock(p2m);
-        return;
+        return 1;
     }
     p2m_unlock(p2m);
 
@@ -1128,12 +1128,13 @@ void p2m_mem_access_check(unsigned long 
             p2m_lock(p2m);
             p2m->set_entry(p2m, gfn, mfn, PAGE_ORDER_4K, p2mt, p2m_access_rwx);
             p2m_unlock(p2m);
+            return 1;
         }
 
-        return;
+        return 0;
     }
     else if ( res > 0 )
-        return;  /* No space in buffer; VCPU paused */
+        return 0;  /* No space in buffer; VCPU paused */
 
     memset(&req, 0, sizeof(req));
     req.type = MEM_EVENT_TYPE_ACCESS;
@@ -1157,6 +1158,7 @@ void p2m_mem_access_check(unsigned long 
     mem_event_put_request(d, &d->mem_event->access, &req);
 
     /* VCPU paused, mem event request sent */
+    return 0;
 }
 
 void p2m_mem_access_resume(struct domain *d)
diff -r 3c240efdd6ad -r e315ce73f082 xen/include/asm-x86/p2m.h
--- a/xen/include/asm-x86/p2m.h
+++ b/xen/include/asm-x86/p2m.h
@@ -491,8 +491,9 @@ static inline void p2m_mem_paging_popula
 
 #ifdef __x86_64__
 /* Send mem event based on the access (gla is -1ull if not available).  Handles
- * the rw2rx conversion */
-void p2m_mem_access_check(unsigned long gpa, bool_t gla_valid, unsigned long gla, 
+ * the rw2rx conversion. Boolean return value indicates if access rights have 
+ * been promoted with no underlying vcpu pause. */
+bool_t p2m_mem_access_check(unsigned long gpa, bool_t gla_valid, unsigned long gla, 
                           bool_t access_r, bool_t access_w, bool_t access_x);
 /* Resumes the running of the VCPU, restarting the last instruction */
 void p2m_mem_access_resume(struct domain *d);
@@ -508,10 +509,10 @@ int p2m_get_mem_access(struct domain *d,
                        hvmmem_access_t *access);
 
 #else
-static inline void p2m_mem_access_check(unsigned long gpa, bool_t gla_valid, 
+static inline bool_t p2m_mem_access_check(unsigned long gpa, bool_t gla_valid, 
                                         unsigned long gla, bool_t access_r, 
                                         bool_t access_w, bool_t access_x)
-{ }
+{ return 1; }
 static inline int p2m_set_mem_access(struct domain *d, 
                                      unsigned long start_pfn, 
                                      uint32_t nr, hvmmem_access_t access)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 21:05:02 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 21:05:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RY2Bs-0006UY-PN; Tue, 06 Dec 2011 21:04:40 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RY2Br-0006Tj-3b
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 21:04:39 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-8.tower-21.messagelabs.com!1323205419!7164183!1
X-Originating-IP: [208.97.132.119]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xMTkgPT4gMTYxMDc=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17603 invoked from network); 6 Dec 2011 21:03:39 -0000
Received: from caiajhbdcbbj.dreamhost.com (HELO homiemail-a20.g.dreamhost.com)
	(208.97.132.119) by server-8.tower-21.messagelabs.com with SMTP;
	6 Dec 2011 21:03:39 -0000
Received: from homiemail-a20.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTP id E7B717EC064;
	Tue,  6 Dec 2011 13:03:38 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id:date
	:from:to:cc; q=dns; s=lagarcavilla.org; b=ANKPlTyQ8YZ80b4i/OXSwn
	duzhWF9qD1uVjhJ5Yc9t0WnLc9WgRfiqMCWXmVwF8rdd1xyvM/QFSzZ7BhD3keGa
	MaWzTXx31slPbictpwUCtDaYd3XfVVyVulQg/B/QIJoA9UM66TOgYtrFD33uVDUd
	NPnCHtPK4y9KcQcB91A0s=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:date:from:to:cc; s=lagarcavilla.org; bh=gF9y0n0G5wRL
	PEJ5SQPZhCPq7A0=; b=tDhi1wnwYiL9Sna0PWHYcpOy8qPWDKcw38zNcjdKP3b1
	g3fYwL6bKeTc6rhvDGPQfeBQXiwQ8FuiVpSj0dirLpAbhHiZHmxw+hVjMXb9G/0b
	OyOP0Zqncp9McZZWjbKgUL3rN6aWO0YNx8rkPbGl9JkYf4YV7IWnk/o0K9c+G9E=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTPSA id 412797EC061; 
	Tue,  6 Dec 2011 13:03:38 -0800 (PST)
MIME-Version: 1.0
Message-Id: <patchbomb.1323205469@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Tue, 06 Dec 2011 16:04:29 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: keir.xen@gmail.com, time@xen.org, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 0 of 2] Rebased mem access improvements and new
	type
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

We improve the handling of hap faults when both type and access
restrictions are present.

We also add a new p2m access type, n2rwx. It allows for implement a "log
access" mode in the hypervisor, aking to log dirty but for all types of
accesses. Faults caused by this access mode automatically promote the
access rights of the ofending p2m entry, place the event in the ring, and
let the vcpu keep on executing.

Rebased to apply cleanly on top of 537ceb11d51e.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Signed-off-by: Adin Scannell <adin@scannell.ca>

 xen/arch/x86/hvm/hvm.c          |  20 +++++++++++++++-----
 xen/arch/x86/mm/p2m.c           |  10 ++++++----
 xen/include/asm-x86/p2m.h       |   9 +++++----
 xen/arch/x86/hvm/hvm.c          |   1 +
 xen/arch/x86/mm/p2m-ept.c       |   1 +
 xen/arch/x86/mm/p2m.c           |  30 +++++++++++++++++++++---------
 xen/include/asm-x86/p2m.h       |   3 +++
 xen/include/public/hvm/hvm_op.h |   3 +++
 8 files changed, 55 insertions(+), 22 deletions(-)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 21:05:02 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 21:05:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RY2Bs-0006UY-PN; Tue, 06 Dec 2011 21:04:40 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RY2Br-0006Tj-3b
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 21:04:39 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-8.tower-21.messagelabs.com!1323205419!7164183!1
X-Originating-IP: [208.97.132.119]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xMTkgPT4gMTYxMDc=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17603 invoked from network); 6 Dec 2011 21:03:39 -0000
Received: from caiajhbdcbbj.dreamhost.com (HELO homiemail-a20.g.dreamhost.com)
	(208.97.132.119) by server-8.tower-21.messagelabs.com with SMTP;
	6 Dec 2011 21:03:39 -0000
Received: from homiemail-a20.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTP id E7B717EC064;
	Tue,  6 Dec 2011 13:03:38 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id:date
	:from:to:cc; q=dns; s=lagarcavilla.org; b=ANKPlTyQ8YZ80b4i/OXSwn
	duzhWF9qD1uVjhJ5Yc9t0WnLc9WgRfiqMCWXmVwF8rdd1xyvM/QFSzZ7BhD3keGa
	MaWzTXx31slPbictpwUCtDaYd3XfVVyVulQg/B/QIJoA9UM66TOgYtrFD33uVDUd
	NPnCHtPK4y9KcQcB91A0s=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:date:from:to:cc; s=lagarcavilla.org; bh=gF9y0n0G5wRL
	PEJ5SQPZhCPq7A0=; b=tDhi1wnwYiL9Sna0PWHYcpOy8qPWDKcw38zNcjdKP3b1
	g3fYwL6bKeTc6rhvDGPQfeBQXiwQ8FuiVpSj0dirLpAbhHiZHmxw+hVjMXb9G/0b
	OyOP0Zqncp9McZZWjbKgUL3rN6aWO0YNx8rkPbGl9JkYf4YV7IWnk/o0K9c+G9E=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTPSA id 412797EC061; 
	Tue,  6 Dec 2011 13:03:38 -0800 (PST)
MIME-Version: 1.0
Message-Id: <patchbomb.1323205469@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Tue, 06 Dec 2011 16:04:29 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: keir.xen@gmail.com, time@xen.org, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 0 of 2] Rebased mem access improvements and new
	type
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

We improve the handling of hap faults when both type and access
restrictions are present.

We also add a new p2m access type, n2rwx. It allows for implement a "log
access" mode in the hypervisor, aking to log dirty but for all types of
accesses. Faults caused by this access mode automatically promote the
access rights of the ofending p2m entry, place the event in the ring, and
let the vcpu keep on executing.

Rebased to apply cleanly on top of 537ceb11d51e.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Signed-off-by: Adin Scannell <adin@scannell.ca>

 xen/arch/x86/hvm/hvm.c          |  20 +++++++++++++++-----
 xen/arch/x86/mm/p2m.c           |  10 ++++++----
 xen/include/asm-x86/p2m.h       |   9 +++++----
 xen/arch/x86/hvm/hvm.c          |   1 +
 xen/arch/x86/mm/p2m-ept.c       |   1 +
 xen/arch/x86/mm/p2m.c           |  30 +++++++++++++++++++++---------
 xen/include/asm-x86/p2m.h       |   3 +++
 xen/include/public/hvm/hvm_op.h |   3 +++
 8 files changed, 55 insertions(+), 22 deletions(-)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 21:06:24 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 21:06:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RY2DI-0006fY-9u; Tue, 06 Dec 2011 21:06:08 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RY2DG-0006et-B5
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 21:06:06 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-11.tower-216.messagelabs.com!1323205518!6360066!1
X-Originating-IP: [208.97.132.119]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xMTkgPT4gMTYxMDc=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4359 invoked from network); 6 Dec 2011 21:05:19 -0000
Received: from caiajhbdcbbj.dreamhost.com (HELO homiemail-a12.g.dreamhost.com)
	(208.97.132.119) by server-11.tower-216.messagelabs.com with SMTP;
	6 Dec 2011 21:05:19 -0000
Received: from homiemail-a12.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a12.g.dreamhost.com (Postfix) with ESMTP id 4926971406B;
	Tue,  6 Dec 2011 13:05:17 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=EfuX4Clx6u2WpCoOlJlGrB+CVp008LQRspfkY0Vjxm8M
	axccdJtKFAbo6QCYHaCnMiceRHQMJz/su6ZJG2nQdsVKRWrtX50IwLNIUBeyASk7
	UpbaE5W3HeGntMmXcpRGE+C1CP6mb62PcukgdCnsd/jPvilH9bpitM6zRqgn3YQ=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=sVIcjrM6hnk8EAWtwTMvMw72jX8=; b=rM4QrKxS
	MsIvjUVZp/GlaINm9reg4fcv+O476NpJzt47EVmffX6ies2P2kWVQVn4XCmMqrXq
	krGYMIijfzQtLIAVWt+vIRmHVFtgVdFo5JDqXU4/cQIO0+91F/UJFAGOpsayZaNe
	fp57V8uXAF2T6ifpnh6/xDfx1GPxjnkxHp0=
Received: from webmail.lagarcavilla.org (ahfbbjcaiaae.dreamhost.com
	[75.119.208.4]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a12.g.dreamhost.com (Postfix) with ESMTPA id C4D7571406A; 
	Tue,  6 Dec 2011 13:05:16 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP; Tue, 6 Dec 2011 13:05:17 -0800
Message-ID: <34c5583af33c538f2ce54a4634da5098.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20111206203805.GB31448@ocelot.phlegethon.org>
References: <patchbomb.1322767496@xdev.gridcentric.ca>
	<20111206203805.GB31448@ocelot.phlegethon.org>
Date: Tue, 6 Dec 2011 13:05:17 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Tim Deegan" <tim@xen.org>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com, keir.xen@gmail.com,
	jbeulich@suse.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 0 of 3] Mem access improvements and new type
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> At 14:24 -0500 on 01 Dec (1322749496), Andres Lagar-Cavilla wrote:
>> We improve the handling of hap faults when both type and access
>> restrictions are present.
>>
>> We also add a new p2m access type, n2rwx. It allows for implement a "log
>> access" mode in the hypervisor, aking to log dirty but for all types of
>> accesses. Faults caused by this access mode automatically promote the
>> access rights of the ofending p2m entry, place the event in the ring,
>> and
>> let the vcpu keep on executing.
>
> Applied 1/3; thanks.
>
> The other two don't apply cleanly to xen-unstable.  have you got some
> other patches in you local environment that touch the same parts of
> p2m.c?

I don't know. Rebased, seems clean, resent just now.
Thanks a bunch
Andres

>
> Tim.
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 21:06:24 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 21:06:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RY2DI-0006fY-9u; Tue, 06 Dec 2011 21:06:08 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RY2DG-0006et-B5
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 21:06:06 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-11.tower-216.messagelabs.com!1323205518!6360066!1
X-Originating-IP: [208.97.132.119]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xMTkgPT4gMTYxMDc=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4359 invoked from network); 6 Dec 2011 21:05:19 -0000
Received: from caiajhbdcbbj.dreamhost.com (HELO homiemail-a12.g.dreamhost.com)
	(208.97.132.119) by server-11.tower-216.messagelabs.com with SMTP;
	6 Dec 2011 21:05:19 -0000
Received: from homiemail-a12.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a12.g.dreamhost.com (Postfix) with ESMTP id 4926971406B;
	Tue,  6 Dec 2011 13:05:17 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=EfuX4Clx6u2WpCoOlJlGrB+CVp008LQRspfkY0Vjxm8M
	axccdJtKFAbo6QCYHaCnMiceRHQMJz/su6ZJG2nQdsVKRWrtX50IwLNIUBeyASk7
	UpbaE5W3HeGntMmXcpRGE+C1CP6mb62PcukgdCnsd/jPvilH9bpitM6zRqgn3YQ=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=sVIcjrM6hnk8EAWtwTMvMw72jX8=; b=rM4QrKxS
	MsIvjUVZp/GlaINm9reg4fcv+O476NpJzt47EVmffX6ies2P2kWVQVn4XCmMqrXq
	krGYMIijfzQtLIAVWt+vIRmHVFtgVdFo5JDqXU4/cQIO0+91F/UJFAGOpsayZaNe
	fp57V8uXAF2T6ifpnh6/xDfx1GPxjnkxHp0=
Received: from webmail.lagarcavilla.org (ahfbbjcaiaae.dreamhost.com
	[75.119.208.4]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a12.g.dreamhost.com (Postfix) with ESMTPA id C4D7571406A; 
	Tue,  6 Dec 2011 13:05:16 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP; Tue, 6 Dec 2011 13:05:17 -0800
Message-ID: <34c5583af33c538f2ce54a4634da5098.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20111206203805.GB31448@ocelot.phlegethon.org>
References: <patchbomb.1322767496@xdev.gridcentric.ca>
	<20111206203805.GB31448@ocelot.phlegethon.org>
Date: Tue, 6 Dec 2011 13:05:17 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Tim Deegan" <tim@xen.org>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com, keir.xen@gmail.com,
	jbeulich@suse.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 0 of 3] Mem access improvements and new type
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> At 14:24 -0500 on 01 Dec (1322749496), Andres Lagar-Cavilla wrote:
>> We improve the handling of hap faults when both type and access
>> restrictions are present.
>>
>> We also add a new p2m access type, n2rwx. It allows for implement a "log
>> access" mode in the hypervisor, aking to log dirty but for all types of
>> accesses. Faults caused by this access mode automatically promote the
>> access rights of the ofending p2m entry, place the event in the ring,
>> and
>> let the vcpu keep on executing.
>
> Applied 1/3; thanks.
>
> The other two don't apply cleanly to xen-unstable.  have you got some
> other patches in you local environment that touch the same parts of
> p2m.c?

I don't know. Rebased, seems clean, resent just now.
Thanks a bunch
Andres

>
> Tim.
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 21:34:49 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 21:34:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RY2ee-0007Bx-P7; Tue, 06 Dec 2011 21:34:24 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RY2ed-0007Bs-55
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 21:34:23 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-5.tower-174.messagelabs.com!1323207215!4523370!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31125 invoked from network); 6 Dec 2011 21:33:36 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-5.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 6 Dec 2011 21:33:36 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RY2dp-0009SD-Kx; Tue, 06 Dec 2011 21:33:33 +0000
Date: Tue, 6 Dec 2011 21:33:33 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20111206213333.GD31448@ocelot.phlegethon.org>
References: <patchbomb.1323205469@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <patchbomb.1323205469@xdev.gridcentric.ca>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com, keir.xen@gmail.com, time@xen.org,
	adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 0 of 2] Rebased mem access improvements and
	new type
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 16:04 -0500 on 06 Dec (1323187469), Andres Lagar-Cavilla wrote:
> We improve the handling of hap faults when both type and access
> restrictions are present.
> 
> We also add a new p2m access type, n2rwx. It allows for implement a "log
> access" mode in the hypervisor, aking to log dirty but for all types of
> accesses. Faults caused by this access mode automatically promote the
> access rights of the ofending p2m entry, place the event in the ring, and
> let the vcpu keep on executing.
> 
> Rebased to apply cleanly on top of 537ceb11d51e.

Applied, thanks.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 21:34:49 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 21:34:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RY2ee-0007Bx-P7; Tue, 06 Dec 2011 21:34:24 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RY2ed-0007Bs-55
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 21:34:23 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-5.tower-174.messagelabs.com!1323207215!4523370!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31125 invoked from network); 6 Dec 2011 21:33:36 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-5.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 6 Dec 2011 21:33:36 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RY2dp-0009SD-Kx; Tue, 06 Dec 2011 21:33:33 +0000
Date: Tue, 6 Dec 2011 21:33:33 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20111206213333.GD31448@ocelot.phlegethon.org>
References: <patchbomb.1323205469@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <patchbomb.1323205469@xdev.gridcentric.ca>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com, keir.xen@gmail.com, time@xen.org,
	adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 0 of 2] Rebased mem access improvements and
	new type
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 16:04 -0500 on 06 Dec (1323187469), Andres Lagar-Cavilla wrote:
> We improve the handling of hap faults when both type and access
> restrictions are present.
> 
> We also add a new p2m access type, n2rwx. It allows for implement a "log
> access" mode in the hypervisor, aking to log dirty but for all types of
> accesses. Faults caused by this access mode automatically promote the
> access rights of the ofending p2m entry, place the event in the ring, and
> let the vcpu keep on executing.
> 
> Rebased to apply cleanly on top of 537ceb11d51e.

Applied, thanks.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 21:56:36 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 21:56:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RY2zg-0007OX-Oa; Tue, 06 Dec 2011 21:56:08 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RY2zf-0007OS-Dy
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 21:56:07 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1323208518!7208130!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjM3Ng==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6609 invoked from network); 6 Dec 2011 21:55:19 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Dec 2011 21:55:19 -0000
X-IronPort-AV: E=Sophos;i="4.71,308,1320624000"; 
   d="scan'208";a="9330561"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Dec 2011 21:55:18 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 6 Dec 2011 21:55:18 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RY2yr-0005E3-Rh;
	Tue, 06 Dec 2011 21:55:17 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RY2yr-00018x-RA;
	Tue, 06 Dec 2011 21:55:17 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10390-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 6 Dec 2011 21:55:17 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10390: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10390 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10390/

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-amd64-xl-sedf     14 guest-localmigrate/x10    fail REGR. vs. 10201
 test-amd64-i386-win-vcpus1    8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-i386-win           8 guest-saverestore         fail REGR. vs. 10201
 test-i386-i386-win            8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-amd64-win          8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-amd64-xl-win       8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-i386-xl-win-vcpus1  8 guest-saverestore        fail REGR. vs. 10201
 test-i386-i386-xl-win         8 guest-saverestore         fail REGR. vs. 10201

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-win7-amd64  7 windows-install              fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install          fail never pass
 test-amd64-i386-xl-win7-amd64  7 windows-install              fail  never pass
 test-i386-i386-xl-winxpsp3    7 windows-install              fail   never pass
 test-amd64-i386-xend-winxpsp3  7 windows-install              fail  never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   never pass

version targeted for testing:
 xen                  ff988cea61ea
baseline version:
 xen                  62ff6a318c5d

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Andrew Cooper <andrew.cooper3@citrix.com>
  Anthony PERARD <anthony.perard@citrix.com>
  Brendan Cully <brendan@cs.ubc.ca>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Haitao Shan <haitao.shan@intel.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@novell.com>
  Jan Beulich <jbeulich@suse.com>
  Jonathan Davies <jonathan.davies@citrix.com>
  juergen.gross@ts.fujitsu.com
  Keir Fraser <keir@xen.org>
  Liu, Jinsong <jinsong.liu@intel.com>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
  Philipp Hahn <hahn@univention.de>
  Shriram Rajagopalan <rshriram@cs.ubc.ca>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang2 <wei.wang2@amd.com>
  Xudong Hao <xudong.hao@intel.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 1366 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 21:56:36 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 21:56:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RY2zg-0007OX-Oa; Tue, 06 Dec 2011 21:56:08 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RY2zf-0007OS-Dy
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 21:56:07 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1323208518!7208130!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjM3Ng==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6609 invoked from network); 6 Dec 2011 21:55:19 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Dec 2011 21:55:19 -0000
X-IronPort-AV: E=Sophos;i="4.71,308,1320624000"; 
   d="scan'208";a="9330561"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Dec 2011 21:55:18 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 6 Dec 2011 21:55:18 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RY2yr-0005E3-Rh;
	Tue, 06 Dec 2011 21:55:17 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RY2yr-00018x-RA;
	Tue, 06 Dec 2011 21:55:17 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10390-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 6 Dec 2011 21:55:17 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10390: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10390 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10390/

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-amd64-xl-sedf     14 guest-localmigrate/x10    fail REGR. vs. 10201
 test-amd64-i386-win-vcpus1    8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-i386-win           8 guest-saverestore         fail REGR. vs. 10201
 test-i386-i386-win            8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-amd64-win          8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-amd64-xl-win       8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-i386-xl-win-vcpus1  8 guest-saverestore        fail REGR. vs. 10201
 test-i386-i386-xl-win         8 guest-saverestore         fail REGR. vs. 10201

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-win7-amd64  7 windows-install              fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install          fail never pass
 test-amd64-i386-xl-win7-amd64  7 windows-install              fail  never pass
 test-i386-i386-xl-winxpsp3    7 windows-install              fail   never pass
 test-amd64-i386-xend-winxpsp3  7 windows-install              fail  never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   never pass

version targeted for testing:
 xen                  ff988cea61ea
baseline version:
 xen                  62ff6a318c5d

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Andrew Cooper <andrew.cooper3@citrix.com>
  Anthony PERARD <anthony.perard@citrix.com>
  Brendan Cully <brendan@cs.ubc.ca>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Haitao Shan <haitao.shan@intel.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@novell.com>
  Jan Beulich <jbeulich@suse.com>
  Jonathan Davies <jonathan.davies@citrix.com>
  juergen.gross@ts.fujitsu.com
  Keir Fraser <keir@xen.org>
  Liu, Jinsong <jinsong.liu@intel.com>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
  Philipp Hahn <hahn@univention.de>
  Shriram Rajagopalan <rshriram@cs.ubc.ca>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang2 <wei.wang2@amd.com>
  Xudong Hao <xudong.hao@intel.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 1366 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 22:30:05 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 22: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.xensource.com>)
	id 1RY3Vz-0007es-FV; Tue, 06 Dec 2011 22:29:31 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <davidtecher@yahoo.fr>) id 1RY3Vw-0007ek-Vp
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 22:29:29 +0000
X-Env-Sender: davidtecher@yahoo.fr
X-Msg-Ref: server-14.tower-216.messagelabs.com!1323210520!5866710!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.6 required=7.0 tests=HTML_40_50,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,spamassassin: 
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10788 invoked from network); 6 Dec 2011 22:28:41 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-14.tower-216.messagelabs.com with AES256-SHA encrypted SMTP;
	6 Dec 2011 22:28:41 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <davidtecher@yahoo.fr>) id 1RY3V9-0004Lc-Vd
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 14:28:40 -0800
Date: Tue, 6 Dec 2011 14:28:39 -0800 (PST)
From: David TECHER <davidtecher@yahoo.fr>
To: xen-devel@lists.xensource.com
Message-ID: <1323210509.34541.YahooMailNeo@web29813.mail.ird.yahoo.com>
In-Reply-To: <201112061619.56224.tobias.geiger@vido.info>
References: <1318672856439-4904945.post@n5.nabble.com>
	<1319630071722-4939528.post@n5.nabble.com>
	<1319636130.20499.YahooMailNeo@web29808.mail.ird.yahoo.com>
	<1319695116310-4942047.post@n5.nabble.com>
	<1319710499.206.YahooMailNeo@web29804.mail.ird.yahoo.com>
	<1323123990448-5050354.post@n5.nabble.com>
	<1323170568.90631.YahooMailNeo@web29813.mail.ird.yahoo.com>
	<1323173094434-5051880.post@n5.nabble.com>
	<1323179850.78658.YahooMailNeo@web29801.mail.ird.yahoo.com>
	<201112061619.56224.tobias.geiger@vido.info>
MIME-Version: 1.0
Subject: [Xen-devel] Re : Re : Re : Re : Re : Re : Re : Re : Re : Re:
 Patches for VGA-Passthrough XEN 4.2 unstable
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============4326375892743597741=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============4326375892743597741==
Content-Type: multipart/alternative; 
	boundary="----=_Part_50381_54326.1323210519975"

------=_Part_50381_54326.1323210519975
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Tobias,

When I restart my domU, my domU freezes (the boot screen of Windows XP is f=
rozen with blue progression bar). Only my dom0 is available.

David.



________________________________
 De=C2=A0: Tobias Geiger [via Xen] <ml-node+s1045712n5052398h36@n5.nabble.c=
om>
=C3=80=C2=A0: David TECHER <davidtecher@yahoo.fr>=20
Envoy=C3=A9 le : Mardi 6 D=C3=A9cembre 2011 16h21
Objet=C2=A0: Re: Re : Re : Re : Re : Re : Re : Re : Re : Re: Patches for VG=
A-Passthrough XEN 4.2 unstable
=20

Hello,=20

glad to hear it works for you!=20

As i run a similar setup, perhaps you can share your experience regarding=
=20
DomU-Reboot with a VGA Card passed through to it: Does a reboot work, i.e.=
=20
does the passed-through VGA Card work after a DomU reboot?=20

My hole System (DomU + Dom0) freezes after a reboot of DomU (exaclty then,=
=20
when the passed-through VGA Card is accessed...), therefore the question.=
=20

Thanks for your info!=20
Greetings=20
Tobias=20

Am Dienstag, 6. Dezember 2011, 14:57:30 schrieb David TECHER:=20

> Hi=20
>=20
> Thanks for these informations. I am on Debian. So it could be usefull for=
=20
> Ubuntu users.=20
>=20
> Thanks.=20
>=20
> David=20
>=20
>=20
>=20
> ________________________________=20
> =C2=A0De : n4rC0t1C <[hidden email]>=20
> =C3=80 : [hidden email]=20
> Envoy=C3=A9 le : Mardi 6 D=C3=A9cembre 2011 13h04=20
> Objet : Re: [Xen-devel] Re : Re : Re : Re : Re : Re : Re : Re: Patches fo=
r=20
> VGA-Passthrough XEN 4.2 unstable=20
>=20
> Iep I used your last patches, (your website it's at the top of my=20
> bookmarks), and they apply to xen-unstable rev. 24341 as well (which i'm=
=20
> using).=20
>=20
> I forgot to mention that I had to make a couple of fix to xen tree, cause=
=20
> it wasn't compiling on my system due to =C2=A0"error: format not a string=
=20
> literal and no format arguments":=20
>=20
>=20
> --- /usr/src/xen-unstable.hg-rev-24341-460gtx/tools/libxl/libxl_create.c=
=20
> +++ /usr/src/xen-unstable.hg-rev-24341-460gtx/tools/libxl/libxl_create.c=
=20
> @@ -462,7 +462,7 @@=20
> =C2=A0 =C2=A0 =C2=A0path =3D libxl__xs_libxl_path(gc, domid);=20
> =C2=A0 =C2=A0 =C2=A0path =3D libxl__sprintf(gc, "%s/dm-version", path);=
=20
> =C2=A0 =C2=A0 =C2=A0return libxl__xs_write(gc, XBT_NULL, path, libxl__str=
dup(gc,=20
> - =C2=A0 =C2=A0=20
> libxl_device_model_version_to_string(dm_info->device_model_version)));=20
> + =C2=A0 =C2=A0=20
> libxl_device_model_version_to_string(dm_info->device_model_version)),"%s"=
);=20
> }=20
>=20
> static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,=
=20
>=20
>=20
> --- /usr/src/xen-unstable.hg-rev-24341-460gtx/tools/libxl/libxl_device.c=
=20
> +++ /usr/src/xen-unstable.hg-rev-24341-460gtx/tools/libxl/libxl_device.c=
=20
> @@ -516,7 +516,7 @@=20
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0for (j =3D 0; j < num_devs; j++) {=20
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0path =3D libxl__sprintf(g=
c,=20
> "/local/domain/%d/device/%s/%s/backend",=20
> =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 =C2=A0domid, kinds[i], devs[j=
]);=20
> - =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0path =3D libxl__xs_read(gc, XB=
T_NULL, libxl__sprintf(gc, path));=20
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0path =3D libxl__xs_read(gc, XB=
T_NULL, libxl__sprintf(gc,=20
> path,"%s"));=20
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0if (path && libxl__parse_=
backend_path(gc, path, &dev) =3D=3D 0) {=20
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0dev.domid =
=3D domid;=20
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0dev.kind =
=3D kind;=20
>=20
> and an due to an argument missing:=20
>=20
> --- /usr/src/xen-unstable.hg-rev-24341-460gtx/tools/libxl/libxl_dom.c=20
> +++ /usr/src/xen-unstable.hg-rev-24341-460gtx/tools/libxl/libxl_dom.c=20
> @@ -625,7 +625,7 @@=20
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0break;=20
> =C2=A0 =C2=A0 =C2=A0}=20
> =C2=A0 =C2=A0 =C2=A0case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:=20
> - =C2=A0 =C2=A0 =C2=A0 =C2=A0fd2 =3D open(filename, O_WRONLY | O_CREAT | =
O_TRUNC);=20
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0fd2 =3D open(filename, O_WRONLY | O_CREAT | =
O_TRUNC, 0644);=20
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0if (fd2 < 0) {=20
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0LIBXL__LOG_ERRNO(ctx, LIB=
XL__LOG_ERROR,=20
> =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 "Unable to create a QEMU save file\n");=20
>=20
> As far as I know those doesn't break anything, but dont take too seriousl=
y,=20
> i'm not an experienced developer :)=20
>=20
>=20
> Forgot 2:=20
> Since I'm using an ubuntu kernel, the xen support is not integrated, but=
=20
> you need to add xen modules at your inittrd file. I did this by adding=20
> those:=20
>=20
> xen-pciback passthrough=3D1=20
> xen-blkback=20
> xenfs=20
> xen-netback=20
> pci-stub=20
>=20
> to /etc/xen/initramfs-tools/modules and the issuing update-initramfs.=20
>=20
> In the future, I'll try to boot a linux domU, right now I'm still smiling=
=20
> cause I can fully wipe my Windows installation from the hard disk. And I'=
m=20
> sure that in future Win7 will be supported too.=20
>=20
> Thanks again David and everyone,=20
> Ivo=20
>=20
> --=20
> View this message in context:=20
> http://xen.1045712.n5.nabble.com/Patches-for-VGA-Passthrough-XEN-4-2-unst=
a
> ble-tp4406265p5051880.html Sent from the Xen - Dev mailing list archive a=
t=20
> Nabble.com.=20
>=20
> _______________________________________________=20
> Xen-devel mailing list=20
> [hidden email]=20
> http://lists.xensource.com/xen-devel

_______________________________________________=20
Xen-devel mailing list=20
[hidden email]=20
http://lists.xensource.com/xen-devel


________________________________
=20
If you reply to this email, your message will be added to the discussion be=
low:http://xen.1045712.n5.nabble.com/Patches-for-VGA-Passthrough-XEN-4-2-un=
stable-tp4406265p5052398.html=20
To unsubscribe from Patches for VGA-Passthrough XEN 4.2 unstable, click her=
e.
NAML

--
View this message in context: http://xen.1045712.n5.nabble.com/Patches-for-=
VGA-Passthrough-XEN-4-2-unstable-tp4406265p5053675.html
Sent from the Xen - Dev mailing list archive at Nabble.com.
------=_Part_50381_54326.1323210519975
Content-Type: text/html; charset=UTF8
Content-Transfer-Encoding: quoted-printable

<div style=3D"color:#000; background-color:#fff; font-family:times new roma=
n, new york, times, serif;font-size:12pt"><div><span>Tobias,</span></div><d=
iv><br><span></span></div><div><span>When I restart my domU, my domU freeze=
s (the boot screen of Windows XP is frozen with blue progression bar). Only=
 my dom0 is available.</span></div><div><br><span></span></div><div><span>D=
avid.</span></div><div><br></div>  <div style=3D"font-family: times new rom=
an, new york, times, serif; font-size: 12pt;"> <div style=3D"font-family: t=
imes new roman, new york, times, serif; font-size: 12pt;"> <font face=3D"Ar=
ial" size=3D"2"> <hr size=3D"1">  <b><span style=3D"font-weight:bold;">De&n=
bsp;:</span></b> Tobias Geiger [via Xen] &lt;<a href=3D"/user/SendEmail.jtp=
?type=3Dnode&node=3D5053675&i=3D0" target=3D"_top" rel=3D"nofollow" link=3D=
"external">[hidden email]</a>&gt;<br> <b><span style=3D"font-weight: bold;"=
>=C3=80&nbsp;:</span></b> David TECHER &lt;<a href=3D"/user/SendEmail.jtp?t=
ype=3Dnode&node=3D5053675&i=3D1" target=3D"_top" rel=3D"nofollow" link=3D"e=
xternal">[hidden email]</a>&gt; <br> <b><span style=3D"font-weight: bold;">=
Envoy=C3=A9 le :</span></b> Mardi 6 D=C3=A9cembre 2011 16h21<br>
 <b><span style=3D"font-weight: bold;">Objet&nbsp;:</span></b> Re: Re : Re =
: Re : Re : Re : Re : Re : Re : Re: Patches for VGA-Passthrough XEN 4.2 uns=
table<br> </font> <br><div id=3D"yiv1323447103">

=09Hello,
<br><br>glad to hear it works for you!
<br><br>As i run a similar setup, perhaps you can share your experience reg=
arding=20
<br>DomU-Reboot with a VGA Card passed through to it: Does a reboot work, i=
.e.=20
<br>does the passed-through VGA Card work after a DomU reboot?
<br><br>My hole System (DomU + Dom0) freezes after a reboot of DomU (exaclt=
y then,=20
<br>when the passed-through VGA Card is accessed...), therefore the questio=
n.
<br><br>Thanks for your info!
<br>Greetings
<br>Tobias
<br><br>Am Dienstag, 6. Dezember 2011, 14:57:30 schrieb David TECHER:
<div class=3D"yiv1323447103shrinkable-quote"><div class=3D'shrinkable-quote=
'><br>&gt; Hi
<br>&gt;=20
<br>&gt; Thanks for these informations. I am on Debian. So it could be usef=
ull for
<br>&gt; Ubuntu users.
<br>&gt;=20
<br>&gt; Thanks.
<br>&gt;=20
<br>&gt; David
<br>&gt;=20
<br>&gt;=20
<br>&gt;=20
<br>&gt; ________________________________
<br>&gt; &nbsp;De : n4rC0t1C &lt;<a rel=3D"nofollow" target=3D"_top" link=
=3D"external">[hidden email]</a>&gt;
<br>&gt; =C3=80 : <a rel=3D"nofollow" target=3D"_top" link=3D"external">[hi=
dden email]</a>
<br>&gt; Envoy=C3=A9 le : Mardi 6 D=C3=A9cembre 2011 13h04
<br>&gt; Objet : Re: [Xen-devel] Re : Re : Re : Re : Re : Re : Re : Re: Pat=
ches for
<br>&gt; VGA-Passthrough XEN 4.2 unstable
<br>&gt;=20
<br>&gt; Iep I used your last patches, (your website it's at the top of my
<br>&gt; bookmarks), and they apply to xen-unstable rev. 24341 as well (whi=
ch i'm
<br>&gt; using).
<br>&gt;=20
<br>&gt; I forgot to mention that I had to make a couple of fix to xen tree=
, cause
<br>&gt; it wasn't compiling on my system due to &nbsp;"error: format not a=
 string
<br>&gt; literal and no format arguments":
<br>&gt;=20
<br>&gt;=20
<br>&gt; --- /usr/src/xen-unstable.hg-rev-24341-460gtx/tools/libxl/libxl_cr=
eate.c
<br>&gt; +++ /usr/src/xen-unstable.hg-rev-24341-460gtx/tools/libxl/libxl_cr=
eate.c
<br>&gt; @@ -462,7 +462,7 @@
<br>&gt; &nbsp; &nbsp; &nbsp;path =3D libxl__xs_libxl_path(gc, domid);
<br>&gt; &nbsp; &nbsp; &nbsp;path =3D libxl__sprintf(gc, "%s/dm-version", p=
ath);
<br>&gt; &nbsp; &nbsp; &nbsp;return libxl__xs_write(gc, XBT_NULL, path, lib=
xl__strdup(gc,
<br>&gt; - &nbsp; &nbsp;=20
<br>&gt; libxl_device_model_version_to_string(dm_info-&gt;device_model_vers=
ion)));
<br>&gt; + &nbsp; &nbsp;=20
<br>&gt; libxl_device_model_version_to_string(dm_info-&gt;device_model_vers=
ion)),"%s");
<br>&gt; }
<br>&gt;=20
<br>&gt; static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_=
config,
<br>&gt;=20
<br>&gt;=20
<br>&gt; --- /usr/src/xen-unstable.hg-rev-24341-460gtx/tools/libxl/libxl_de=
vice.c
<br>&gt; +++ /usr/src/xen-unstable.hg-rev-24341-460gtx/tools/libxl/libxl_de=
vice.c
<br>&gt; @@ -516,7 +516,7 @@
<br>&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;for (j =3D 0; j &lt; num_devs; j=
++) {
<br>&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;path =3D libxl__sp=
rintf(gc,
<br>&gt; "/local/domain/%d/device/%s/%s/backend",
<br>&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nb=
sp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;domid, kinds[i],=
 devs[j]);
<br>&gt; - &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;path =3D libxl__xs_read=
(gc, XBT_NULL, libxl__sprintf(gc, path));
<br>&gt; + &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;path =3D libxl__xs_read=
(gc, XBT_NULL, libxl__sprintf(gc,
<br>&gt; path,"%s"));
<br>&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;if (path &amp;&amp=
; libxl__parse_backend_path(gc, path, &amp;dev) =3D=3D 0) {
<br>&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;dev.=
domid =3D domid;
<br>&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;dev.=
kind =3D kind;
<br>&gt;=20
<br>&gt; and an due to an argument missing:
<br>&gt;=20
<br>&gt; --- /usr/src/xen-unstable.hg-rev-24341-460gtx/tools/libxl/libxl_do=
m.c
<br>&gt; +++ /usr/src/xen-unstable.hg-rev-24341-460gtx/tools/libxl/libxl_do=
m.c
<br>&gt; @@ -625,7 +625,7 @@
<br>&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;break;
<br>&gt; &nbsp; &nbsp; &nbsp;}
<br>&gt; &nbsp; &nbsp; &nbsp;case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
<br>&gt; - &nbsp; &nbsp; &nbsp; &nbsp;fd2 =3D open(filename, O_WRONLY | O_C=
REAT | O_TRUNC);
<br>&gt; + &nbsp; &nbsp; &nbsp; &nbsp;fd2 =3D open(filename, O_WRONLY | O_C=
REAT | O_TRUNC, 0644);
<br>&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;if (fd2 &lt; 0) {
<br>&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;LIBXL__LOG_ERRNO(c=
tx, LIBXL__LOG_ERROR,
<br>&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nb=
sp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; "Unable to create a QEMU save file\n=
");
<br>&gt;=20
<br>&gt; As far as I know those doesn't break anything, but dont take too s=
eriously,
<br>&gt; i'm not an experienced developer :)
<br>&gt;=20
<br>&gt;=20
<br>&gt; Forgot 2:
<br>&gt; Since I'm using an ubuntu kernel, the xen support is not integrate=
d, but
<br>&gt; you need to add xen modules at your inittrd file. I did this by ad=
ding
<br>&gt; those:
<br>&gt;=20
<br>&gt; xen-pciback passthrough=3D1
<br>&gt; xen-blkback
<br>&gt; xenfs
<br>&gt; xen-netback
<br>&gt; pci-stub
<br>&gt;=20
<br>&gt; to /etc/xen/initramfs-tools/modules and the issuing update-initram=
fs.
<br>&gt;=20
<br>&gt; In the future, I'll try to boot a linux domU, right now I'm still =
smiling
<br>&gt; cause I can fully wipe my Windows installation from the hard disk.=
 And I'm
<br>&gt; sure that in future Win7 will be supported too.
<br>&gt;=20
<br>&gt; Thanks again David and everyone,
<br>&gt; Ivo
<br>&gt;=20
<br>&gt; --
<br>&gt; View this message in context:
<br>&gt; <a rel=3D"nofollow" target=3D"_blank" href=3D"http://xen.1045712.n=
5.nabble.com/Patches-for-VGA-Passthrough-XEN-4-2-unsta" link=3D"external">h=
ttp://xen.1045712.n5.nabble.com/Patches-for-VGA-Passthrough-XEN-4-2-unsta</=
a><br>&gt; ble-tp4406265p5051880.html Sent from the Xen - Dev mailing list =
archive at
<br>&gt; Nabble.com.
<br>&gt;=20
<br>&gt; _______________________________________________
<br>&gt; Xen-devel mailing list
<br>&gt; <a rel=3D"nofollow" target=3D"_top" link=3D"external">[hidden emai=
l]</a>
<br>&gt; <a rel=3D"nofollow" target=3D"_blank" href=3D"http://lists.xensour=
ce.com/xen-devel" link=3D"external">http://lists.xensource.com/xen-devel</a=
></div></div><br>_______________________________________________
<br>Xen-devel mailing list
<br><a rel=3D"nofollow" target=3D"_top" link=3D"external">[hidden email]</a=
>
<br><a rel=3D"nofollow" target=3D"_blank" href=3D"http://lists.xensource.co=
m/xen-devel" link=3D"external">http://lists.xensource.com/xen-devel</a><br>
=09
=09<br>
=09<br>
=09<hr color=3D"#cccccc" noshade=3D"noshade" size=3D"1">
=09<div style=3D"color:#444;font:12px tahoma, geneva, helvetica, arial, san=
s-serif;">
=09=09<div style=3D"font-weight:bold;">If you reply to this email, your mes=
sage will be added to the discussion below:</div>
=09=09<a rel=3D"nofollow" target=3D"_blank" href=3D"http://xen.1045712.n5.n=
abble.com/Patches-for-VGA-Passthrough-XEN-4-2-unstable-tp4406265p5052398.ht=
ml" link=3D"external">http://xen.1045712.n5.nabble.com/Patches-for-VGA-Pass=
through-XEN-4-2-unstable-tp4406265p5052398.html</a>
=09</div>
=09<div style=3D"color:#666;font:11px tahoma, geneva, helvetica, arial, san=
s-serif;margin-top:.4em;line-height:1.5em;">
=09=09
=09=09To unsubscribe from Patches for VGA-Passthrough XEN 4.2 unstable, <a =
rel=3D"nofollow" target=3D"_blank" href=3D"" link=3D"external">click here</=
a>.<br>
=09=09<a rel=3D"nofollow" target=3D"_blank" href=3D"http://xen.1045712.n5.n=
abble.com/template/NamlServlet.jtp?macro=3Dmacro_viewer&amp;id=3Dinstant_ht=
ml%21nabble%3Aemail.naml&amp;base=3Dnabble.naml.namespaces.BasicNamespace-n=
abble.view.web.template.NabbleNamespace-nabble.view.web.template.InstantMai=
lNamespace&amp;breadcrumbs=3Dinstant+emails%21nabble%3Aemail.naml-instant_e=
mails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml" style=
=3D"font:9px serif;" link=3D"external">NAML</a>
=09</div></div><br><br> </div> </div>  </div>
=09
<br/><hr align=3D"left" width=3D"300" />
View this message in context: <a href=3D"http://xen.1045712.n5.nabble.com/P=
atches-for-VGA-Passthrough-XEN-4-2-unstable-tp4406265p5053675.html">Re : Re=
 : Re : Re : Re : Re : Re : Re : Re : Re: Patches for VGA-Passthrough XEN 4=
.2 unstable</a><br/>
Sent from the <a href=3D"http://xen.1045712.n5.nabble.com/Xen-Dev-f2473738.=
html">Xen - Dev mailing list archive</a> at Nabble.com.<br/>
------=_Part_50381_54326.1323210519975--


--===============4326375892743597741==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============4326375892743597741==--


From xen-devel-bounces@lists.xensource.com Tue Dec 06 22:30:05 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 22: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.xensource.com>)
	id 1RY3Vz-0007es-FV; Tue, 06 Dec 2011 22:29:31 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <davidtecher@yahoo.fr>) id 1RY3Vw-0007ek-Vp
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 22:29:29 +0000
X-Env-Sender: davidtecher@yahoo.fr
X-Msg-Ref: server-14.tower-216.messagelabs.com!1323210520!5866710!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.6 required=7.0 tests=HTML_40_50,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,spamassassin: 
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10788 invoked from network); 6 Dec 2011 22:28:41 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-14.tower-216.messagelabs.com with AES256-SHA encrypted SMTP;
	6 Dec 2011 22:28:41 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <davidtecher@yahoo.fr>) id 1RY3V9-0004Lc-Vd
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 14:28:40 -0800
Date: Tue, 6 Dec 2011 14:28:39 -0800 (PST)
From: David TECHER <davidtecher@yahoo.fr>
To: xen-devel@lists.xensource.com
Message-ID: <1323210509.34541.YahooMailNeo@web29813.mail.ird.yahoo.com>
In-Reply-To: <201112061619.56224.tobias.geiger@vido.info>
References: <1318672856439-4904945.post@n5.nabble.com>
	<1319630071722-4939528.post@n5.nabble.com>
	<1319636130.20499.YahooMailNeo@web29808.mail.ird.yahoo.com>
	<1319695116310-4942047.post@n5.nabble.com>
	<1319710499.206.YahooMailNeo@web29804.mail.ird.yahoo.com>
	<1323123990448-5050354.post@n5.nabble.com>
	<1323170568.90631.YahooMailNeo@web29813.mail.ird.yahoo.com>
	<1323173094434-5051880.post@n5.nabble.com>
	<1323179850.78658.YahooMailNeo@web29801.mail.ird.yahoo.com>
	<201112061619.56224.tobias.geiger@vido.info>
MIME-Version: 1.0
Subject: [Xen-devel] Re : Re : Re : Re : Re : Re : Re : Re : Re : Re:
 Patches for VGA-Passthrough XEN 4.2 unstable
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============4326375892743597741=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============4326375892743597741==
Content-Type: multipart/alternative; 
	boundary="----=_Part_50381_54326.1323210519975"

------=_Part_50381_54326.1323210519975
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Tobias,

When I restart my domU, my domU freezes (the boot screen of Windows XP is f=
rozen with blue progression bar). Only my dom0 is available.

David.



________________________________
 De=C2=A0: Tobias Geiger [via Xen] <ml-node+s1045712n5052398h36@n5.nabble.c=
om>
=C3=80=C2=A0: David TECHER <davidtecher@yahoo.fr>=20
Envoy=C3=A9 le : Mardi 6 D=C3=A9cembre 2011 16h21
Objet=C2=A0: Re: Re : Re : Re : Re : Re : Re : Re : Re : Re: Patches for VG=
A-Passthrough XEN 4.2 unstable
=20

Hello,=20

glad to hear it works for you!=20

As i run a similar setup, perhaps you can share your experience regarding=
=20
DomU-Reboot with a VGA Card passed through to it: Does a reboot work, i.e.=
=20
does the passed-through VGA Card work after a DomU reboot?=20

My hole System (DomU + Dom0) freezes after a reboot of DomU (exaclty then,=
=20
when the passed-through VGA Card is accessed...), therefore the question.=
=20

Thanks for your info!=20
Greetings=20
Tobias=20

Am Dienstag, 6. Dezember 2011, 14:57:30 schrieb David TECHER:=20

> Hi=20
>=20
> Thanks for these informations. I am on Debian. So it could be usefull for=
=20
> Ubuntu users.=20
>=20
> Thanks.=20
>=20
> David=20
>=20
>=20
>=20
> ________________________________=20
> =C2=A0De : n4rC0t1C <[hidden email]>=20
> =C3=80 : [hidden email]=20
> Envoy=C3=A9 le : Mardi 6 D=C3=A9cembre 2011 13h04=20
> Objet : Re: [Xen-devel] Re : Re : Re : Re : Re : Re : Re : Re: Patches fo=
r=20
> VGA-Passthrough XEN 4.2 unstable=20
>=20
> Iep I used your last patches, (your website it's at the top of my=20
> bookmarks), and they apply to xen-unstable rev. 24341 as well (which i'm=
=20
> using).=20
>=20
> I forgot to mention that I had to make a couple of fix to xen tree, cause=
=20
> it wasn't compiling on my system due to =C2=A0"error: format not a string=
=20
> literal and no format arguments":=20
>=20
>=20
> --- /usr/src/xen-unstable.hg-rev-24341-460gtx/tools/libxl/libxl_create.c=
=20
> +++ /usr/src/xen-unstable.hg-rev-24341-460gtx/tools/libxl/libxl_create.c=
=20
> @@ -462,7 +462,7 @@=20
> =C2=A0 =C2=A0 =C2=A0path =3D libxl__xs_libxl_path(gc, domid);=20
> =C2=A0 =C2=A0 =C2=A0path =3D libxl__sprintf(gc, "%s/dm-version", path);=
=20
> =C2=A0 =C2=A0 =C2=A0return libxl__xs_write(gc, XBT_NULL, path, libxl__str=
dup(gc,=20
> - =C2=A0 =C2=A0=20
> libxl_device_model_version_to_string(dm_info->device_model_version)));=20
> + =C2=A0 =C2=A0=20
> libxl_device_model_version_to_string(dm_info->device_model_version)),"%s"=
);=20
> }=20
>=20
> static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,=
=20
>=20
>=20
> --- /usr/src/xen-unstable.hg-rev-24341-460gtx/tools/libxl/libxl_device.c=
=20
> +++ /usr/src/xen-unstable.hg-rev-24341-460gtx/tools/libxl/libxl_device.c=
=20
> @@ -516,7 +516,7 @@=20
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0for (j =3D 0; j < num_devs; j++) {=20
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0path =3D libxl__sprintf(g=
c,=20
> "/local/domain/%d/device/%s/%s/backend",=20
> =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 =C2=A0domid, kinds[i], devs[j=
]);=20
> - =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0path =3D libxl__xs_read(gc, XB=
T_NULL, libxl__sprintf(gc, path));=20
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0path =3D libxl__xs_read(gc, XB=
T_NULL, libxl__sprintf(gc,=20
> path,"%s"));=20
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0if (path && libxl__parse_=
backend_path(gc, path, &dev) =3D=3D 0) {=20
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0dev.domid =
=3D domid;=20
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0dev.kind =
=3D kind;=20
>=20
> and an due to an argument missing:=20
>=20
> --- /usr/src/xen-unstable.hg-rev-24341-460gtx/tools/libxl/libxl_dom.c=20
> +++ /usr/src/xen-unstable.hg-rev-24341-460gtx/tools/libxl/libxl_dom.c=20
> @@ -625,7 +625,7 @@=20
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0break;=20
> =C2=A0 =C2=A0 =C2=A0}=20
> =C2=A0 =C2=A0 =C2=A0case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:=20
> - =C2=A0 =C2=A0 =C2=A0 =C2=A0fd2 =3D open(filename, O_WRONLY | O_CREAT | =
O_TRUNC);=20
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0fd2 =3D open(filename, O_WRONLY | O_CREAT | =
O_TRUNC, 0644);=20
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0if (fd2 < 0) {=20
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0LIBXL__LOG_ERRNO(ctx, LIB=
XL__LOG_ERROR,=20
> =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 "Unable to create a QEMU save file\n");=20
>=20
> As far as I know those doesn't break anything, but dont take too seriousl=
y,=20
> i'm not an experienced developer :)=20
>=20
>=20
> Forgot 2:=20
> Since I'm using an ubuntu kernel, the xen support is not integrated, but=
=20
> you need to add xen modules at your inittrd file. I did this by adding=20
> those:=20
>=20
> xen-pciback passthrough=3D1=20
> xen-blkback=20
> xenfs=20
> xen-netback=20
> pci-stub=20
>=20
> to /etc/xen/initramfs-tools/modules and the issuing update-initramfs.=20
>=20
> In the future, I'll try to boot a linux domU, right now I'm still smiling=
=20
> cause I can fully wipe my Windows installation from the hard disk. And I'=
m=20
> sure that in future Win7 will be supported too.=20
>=20
> Thanks again David and everyone,=20
> Ivo=20
>=20
> --=20
> View this message in context:=20
> http://xen.1045712.n5.nabble.com/Patches-for-VGA-Passthrough-XEN-4-2-unst=
a
> ble-tp4406265p5051880.html Sent from the Xen - Dev mailing list archive a=
t=20
> Nabble.com.=20
>=20
> _______________________________________________=20
> Xen-devel mailing list=20
> [hidden email]=20
> http://lists.xensource.com/xen-devel

_______________________________________________=20
Xen-devel mailing list=20
[hidden email]=20
http://lists.xensource.com/xen-devel


________________________________
=20
If you reply to this email, your message will be added to the discussion be=
low:http://xen.1045712.n5.nabble.com/Patches-for-VGA-Passthrough-XEN-4-2-un=
stable-tp4406265p5052398.html=20
To unsubscribe from Patches for VGA-Passthrough XEN 4.2 unstable, click her=
e.
NAML

--
View this message in context: http://xen.1045712.n5.nabble.com/Patches-for-=
VGA-Passthrough-XEN-4-2-unstable-tp4406265p5053675.html
Sent from the Xen - Dev mailing list archive at Nabble.com.
------=_Part_50381_54326.1323210519975
Content-Type: text/html; charset=UTF8
Content-Transfer-Encoding: quoted-printable

<div style=3D"color:#000; background-color:#fff; font-family:times new roma=
n, new york, times, serif;font-size:12pt"><div><span>Tobias,</span></div><d=
iv><br><span></span></div><div><span>When I restart my domU, my domU freeze=
s (the boot screen of Windows XP is frozen with blue progression bar). Only=
 my dom0 is available.</span></div><div><br><span></span></div><div><span>D=
avid.</span></div><div><br></div>  <div style=3D"font-family: times new rom=
an, new york, times, serif; font-size: 12pt;"> <div style=3D"font-family: t=
imes new roman, new york, times, serif; font-size: 12pt;"> <font face=3D"Ar=
ial" size=3D"2"> <hr size=3D"1">  <b><span style=3D"font-weight:bold;">De&n=
bsp;:</span></b> Tobias Geiger [via Xen] &lt;<a href=3D"/user/SendEmail.jtp=
?type=3Dnode&node=3D5053675&i=3D0" target=3D"_top" rel=3D"nofollow" link=3D=
"external">[hidden email]</a>&gt;<br> <b><span style=3D"font-weight: bold;"=
>=C3=80&nbsp;:</span></b> David TECHER &lt;<a href=3D"/user/SendEmail.jtp?t=
ype=3Dnode&node=3D5053675&i=3D1" target=3D"_top" rel=3D"nofollow" link=3D"e=
xternal">[hidden email]</a>&gt; <br> <b><span style=3D"font-weight: bold;">=
Envoy=C3=A9 le :</span></b> Mardi 6 D=C3=A9cembre 2011 16h21<br>
 <b><span style=3D"font-weight: bold;">Objet&nbsp;:</span></b> Re: Re : Re =
: Re : Re : Re : Re : Re : Re : Re: Patches for VGA-Passthrough XEN 4.2 uns=
table<br> </font> <br><div id=3D"yiv1323447103">

=09Hello,
<br><br>glad to hear it works for you!
<br><br>As i run a similar setup, perhaps you can share your experience reg=
arding=20
<br>DomU-Reboot with a VGA Card passed through to it: Does a reboot work, i=
.e.=20
<br>does the passed-through VGA Card work after a DomU reboot?
<br><br>My hole System (DomU + Dom0) freezes after a reboot of DomU (exaclt=
y then,=20
<br>when the passed-through VGA Card is accessed...), therefore the questio=
n.
<br><br>Thanks for your info!
<br>Greetings
<br>Tobias
<br><br>Am Dienstag, 6. Dezember 2011, 14:57:30 schrieb David TECHER:
<div class=3D"yiv1323447103shrinkable-quote"><div class=3D'shrinkable-quote=
'><br>&gt; Hi
<br>&gt;=20
<br>&gt; Thanks for these informations. I am on Debian. So it could be usef=
ull for
<br>&gt; Ubuntu users.
<br>&gt;=20
<br>&gt; Thanks.
<br>&gt;=20
<br>&gt; David
<br>&gt;=20
<br>&gt;=20
<br>&gt;=20
<br>&gt; ________________________________
<br>&gt; &nbsp;De : n4rC0t1C &lt;<a rel=3D"nofollow" target=3D"_top" link=
=3D"external">[hidden email]</a>&gt;
<br>&gt; =C3=80 : <a rel=3D"nofollow" target=3D"_top" link=3D"external">[hi=
dden email]</a>
<br>&gt; Envoy=C3=A9 le : Mardi 6 D=C3=A9cembre 2011 13h04
<br>&gt; Objet : Re: [Xen-devel] Re : Re : Re : Re : Re : Re : Re : Re: Pat=
ches for
<br>&gt; VGA-Passthrough XEN 4.2 unstable
<br>&gt;=20
<br>&gt; Iep I used your last patches, (your website it's at the top of my
<br>&gt; bookmarks), and they apply to xen-unstable rev. 24341 as well (whi=
ch i'm
<br>&gt; using).
<br>&gt;=20
<br>&gt; I forgot to mention that I had to make a couple of fix to xen tree=
, cause
<br>&gt; it wasn't compiling on my system due to &nbsp;"error: format not a=
 string
<br>&gt; literal and no format arguments":
<br>&gt;=20
<br>&gt;=20
<br>&gt; --- /usr/src/xen-unstable.hg-rev-24341-460gtx/tools/libxl/libxl_cr=
eate.c
<br>&gt; +++ /usr/src/xen-unstable.hg-rev-24341-460gtx/tools/libxl/libxl_cr=
eate.c
<br>&gt; @@ -462,7 +462,7 @@
<br>&gt; &nbsp; &nbsp; &nbsp;path =3D libxl__xs_libxl_path(gc, domid);
<br>&gt; &nbsp; &nbsp; &nbsp;path =3D libxl__sprintf(gc, "%s/dm-version", p=
ath);
<br>&gt; &nbsp; &nbsp; &nbsp;return libxl__xs_write(gc, XBT_NULL, path, lib=
xl__strdup(gc,
<br>&gt; - &nbsp; &nbsp;=20
<br>&gt; libxl_device_model_version_to_string(dm_info-&gt;device_model_vers=
ion)));
<br>&gt; + &nbsp; &nbsp;=20
<br>&gt; libxl_device_model_version_to_string(dm_info-&gt;device_model_vers=
ion)),"%s");
<br>&gt; }
<br>&gt;=20
<br>&gt; static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_=
config,
<br>&gt;=20
<br>&gt;=20
<br>&gt; --- /usr/src/xen-unstable.hg-rev-24341-460gtx/tools/libxl/libxl_de=
vice.c
<br>&gt; +++ /usr/src/xen-unstable.hg-rev-24341-460gtx/tools/libxl/libxl_de=
vice.c
<br>&gt; @@ -516,7 +516,7 @@
<br>&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;for (j =3D 0; j &lt; num_devs; j=
++) {
<br>&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;path =3D libxl__sp=
rintf(gc,
<br>&gt; "/local/domain/%d/device/%s/%s/backend",
<br>&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nb=
sp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;domid, kinds[i],=
 devs[j]);
<br>&gt; - &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;path =3D libxl__xs_read=
(gc, XBT_NULL, libxl__sprintf(gc, path));
<br>&gt; + &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;path =3D libxl__xs_read=
(gc, XBT_NULL, libxl__sprintf(gc,
<br>&gt; path,"%s"));
<br>&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;if (path &amp;&amp=
; libxl__parse_backend_path(gc, path, &amp;dev) =3D=3D 0) {
<br>&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;dev.=
domid =3D domid;
<br>&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;dev.=
kind =3D kind;
<br>&gt;=20
<br>&gt; and an due to an argument missing:
<br>&gt;=20
<br>&gt; --- /usr/src/xen-unstable.hg-rev-24341-460gtx/tools/libxl/libxl_do=
m.c
<br>&gt; +++ /usr/src/xen-unstable.hg-rev-24341-460gtx/tools/libxl/libxl_do=
m.c
<br>&gt; @@ -625,7 +625,7 @@
<br>&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;break;
<br>&gt; &nbsp; &nbsp; &nbsp;}
<br>&gt; &nbsp; &nbsp; &nbsp;case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
<br>&gt; - &nbsp; &nbsp; &nbsp; &nbsp;fd2 =3D open(filename, O_WRONLY | O_C=
REAT | O_TRUNC);
<br>&gt; + &nbsp; &nbsp; &nbsp; &nbsp;fd2 =3D open(filename, O_WRONLY | O_C=
REAT | O_TRUNC, 0644);
<br>&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;if (fd2 &lt; 0) {
<br>&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;LIBXL__LOG_ERRNO(c=
tx, LIBXL__LOG_ERROR,
<br>&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nb=
sp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; "Unable to create a QEMU save file\n=
");
<br>&gt;=20
<br>&gt; As far as I know those doesn't break anything, but dont take too s=
eriously,
<br>&gt; i'm not an experienced developer :)
<br>&gt;=20
<br>&gt;=20
<br>&gt; Forgot 2:
<br>&gt; Since I'm using an ubuntu kernel, the xen support is not integrate=
d, but
<br>&gt; you need to add xen modules at your inittrd file. I did this by ad=
ding
<br>&gt; those:
<br>&gt;=20
<br>&gt; xen-pciback passthrough=3D1
<br>&gt; xen-blkback
<br>&gt; xenfs
<br>&gt; xen-netback
<br>&gt; pci-stub
<br>&gt;=20
<br>&gt; to /etc/xen/initramfs-tools/modules and the issuing update-initram=
fs.
<br>&gt;=20
<br>&gt; In the future, I'll try to boot a linux domU, right now I'm still =
smiling
<br>&gt; cause I can fully wipe my Windows installation from the hard disk.=
 And I'm
<br>&gt; sure that in future Win7 will be supported too.
<br>&gt;=20
<br>&gt; Thanks again David and everyone,
<br>&gt; Ivo
<br>&gt;=20
<br>&gt; --
<br>&gt; View this message in context:
<br>&gt; <a rel=3D"nofollow" target=3D"_blank" href=3D"http://xen.1045712.n=
5.nabble.com/Patches-for-VGA-Passthrough-XEN-4-2-unsta" link=3D"external">h=
ttp://xen.1045712.n5.nabble.com/Patches-for-VGA-Passthrough-XEN-4-2-unsta</=
a><br>&gt; ble-tp4406265p5051880.html Sent from the Xen - Dev mailing list =
archive at
<br>&gt; Nabble.com.
<br>&gt;=20
<br>&gt; _______________________________________________
<br>&gt; Xen-devel mailing list
<br>&gt; <a rel=3D"nofollow" target=3D"_top" link=3D"external">[hidden emai=
l]</a>
<br>&gt; <a rel=3D"nofollow" target=3D"_blank" href=3D"http://lists.xensour=
ce.com/xen-devel" link=3D"external">http://lists.xensource.com/xen-devel</a=
></div></div><br>_______________________________________________
<br>Xen-devel mailing list
<br><a rel=3D"nofollow" target=3D"_top" link=3D"external">[hidden email]</a=
>
<br><a rel=3D"nofollow" target=3D"_blank" href=3D"http://lists.xensource.co=
m/xen-devel" link=3D"external">http://lists.xensource.com/xen-devel</a><br>
=09
=09<br>
=09<br>
=09<hr color=3D"#cccccc" noshade=3D"noshade" size=3D"1">
=09<div style=3D"color:#444;font:12px tahoma, geneva, helvetica, arial, san=
s-serif;">
=09=09<div style=3D"font-weight:bold;">If you reply to this email, your mes=
sage will be added to the discussion below:</div>
=09=09<a rel=3D"nofollow" target=3D"_blank" href=3D"http://xen.1045712.n5.n=
abble.com/Patches-for-VGA-Passthrough-XEN-4-2-unstable-tp4406265p5052398.ht=
ml" link=3D"external">http://xen.1045712.n5.nabble.com/Patches-for-VGA-Pass=
through-XEN-4-2-unstable-tp4406265p5052398.html</a>
=09</div>
=09<div style=3D"color:#666;font:11px tahoma, geneva, helvetica, arial, san=
s-serif;margin-top:.4em;line-height:1.5em;">
=09=09
=09=09To unsubscribe from Patches for VGA-Passthrough XEN 4.2 unstable, <a =
rel=3D"nofollow" target=3D"_blank" href=3D"" link=3D"external">click here</=
a>.<br>
=09=09<a rel=3D"nofollow" target=3D"_blank" href=3D"http://xen.1045712.n5.n=
abble.com/template/NamlServlet.jtp?macro=3Dmacro_viewer&amp;id=3Dinstant_ht=
ml%21nabble%3Aemail.naml&amp;base=3Dnabble.naml.namespaces.BasicNamespace-n=
abble.view.web.template.NabbleNamespace-nabble.view.web.template.InstantMai=
lNamespace&amp;breadcrumbs=3Dinstant+emails%21nabble%3Aemail.naml-instant_e=
mails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml" style=
=3D"font:9px serif;" link=3D"external">NAML</a>
=09</div></div><br><br> </div> </div>  </div>
=09
<br/><hr align=3D"left" width=3D"300" />
View this message in context: <a href=3D"http://xen.1045712.n5.nabble.com/P=
atches-for-VGA-Passthrough-XEN-4-2-unstable-tp4406265p5053675.html">Re : Re=
 : Re : Re : Re : Re : Re : Re : Re : Re: Patches for VGA-Passthrough XEN 4=
.2 unstable</a><br/>
Sent from the <a href=3D"http://xen.1045712.n5.nabble.com/Xen-Dev-f2473738.=
html">Xen - Dev mailing list archive</a> at Nabble.com.<br/>
------=_Part_50381_54326.1323210519975--


--===============4326375892743597741==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============4326375892743597741==--


From xen-devel-bounces@lists.xensource.com Tue Dec 06 22:34:21 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 22:34:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RY3aF-00081K-BM; Tue, 06 Dec 2011 22:33:55 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <alex@alex.org.uk>) id 1RY3aD-00080u-Ho
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 22:33:53 +0000
X-Env-Sender: alex@alex.org.uk
X-Msg-Ref: server-8.tower-216.messagelabs.com!1323210787!6449505!1
X-Originating-IP: [89.16.176.221]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2667 invoked from network); 6 Dec 2011 22:33:07 -0000
Received: from mail.avalus.com (HELO mail.avalus.com) (89.16.176.221)
	by server-8.tower-216.messagelabs.com with SMTP;
	6 Dec 2011 22:33:07 -0000
Received: from [192.168.50.14] (lemondeh-adsl.demon.co.uk [83.105.105.209])
	by mail.avalus.com (Postfix) with ESMTPSA id 8F188C56126;
	Tue,  6 Dec 2011 22:32:56 +0000 (GMT)
Date: Tue, 06 Dec 2011 22:32:54 +0000
From: Alex Bligh <alex@alex.org.uk>
To: Stefan Bader <stefan.bader@canonical.com>
Message-ID: <84C23332C4B9369510FCD811@nimrod.local>
In-Reply-To: <4EDCDB75.6010403@canonical.com>
References: <4ED798B2.1040309@canonical.com>
	<20111201180944.GH12984@reaktio.net>	<4ED8A45A.3050403@canonical.com>
	<20111202104110.GL12984@reaktio.net>
	<BA1B675D85BDD87795D1666C@Ximines.local>
	<1322844048.29870.155.camel@zakaz.uk.xensource.com>
	<8D88C4D6C31A598129A942AD@Ximines.local>
	<4EDCDB75.6010403@canonical.com>
X-Mailer: Mulberry/4.0.8 (Mac OS X)
MIME-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com, Ian Campbell <Ian.Campbell@citrix.com>,
	Alex Bligh <alex@alex.org.uk>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Xen 4.x / Linux 3.x (dom0 and HVM domU)
 and	NIC	handling
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Alex Bligh <alex@alex.org.uk>
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Stefan,

--On 5 December 2011 15:55:49 +0100 Stefan Bader 
<stefan.bader@canonical.com> wrote:

> Personally I would think nobody could want both
> interfaces at the same time but I would not assume I know all of the use
> cases.

There are no sensible use cases I know of for having both at the
same time, but there are use cases where either a P2V migration
is done (where the P installation has hardcoded root=/dev/sda) or where
a kernel upgrade is done to a kernel supporting PV drivers and
unplug, where the current behaviour of unplugging stuff is not
the policy of least surprise.

OTOH we've got Xen4 cloud images booting with Precise with unplug
better than kvm does, precisely because kvm leaves both around
(as you have probably gathered from a bug that I filed in another
place...)

-- 
Alex Bligh

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 22:34:21 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 22:34:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RY3aF-00081K-BM; Tue, 06 Dec 2011 22:33:55 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <alex@alex.org.uk>) id 1RY3aD-00080u-Ho
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 22:33:53 +0000
X-Env-Sender: alex@alex.org.uk
X-Msg-Ref: server-8.tower-216.messagelabs.com!1323210787!6449505!1
X-Originating-IP: [89.16.176.221]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2667 invoked from network); 6 Dec 2011 22:33:07 -0000
Received: from mail.avalus.com (HELO mail.avalus.com) (89.16.176.221)
	by server-8.tower-216.messagelabs.com with SMTP;
	6 Dec 2011 22:33:07 -0000
Received: from [192.168.50.14] (lemondeh-adsl.demon.co.uk [83.105.105.209])
	by mail.avalus.com (Postfix) with ESMTPSA id 8F188C56126;
	Tue,  6 Dec 2011 22:32:56 +0000 (GMT)
Date: Tue, 06 Dec 2011 22:32:54 +0000
From: Alex Bligh <alex@alex.org.uk>
To: Stefan Bader <stefan.bader@canonical.com>
Message-ID: <84C23332C4B9369510FCD811@nimrod.local>
In-Reply-To: <4EDCDB75.6010403@canonical.com>
References: <4ED798B2.1040309@canonical.com>
	<20111201180944.GH12984@reaktio.net>	<4ED8A45A.3050403@canonical.com>
	<20111202104110.GL12984@reaktio.net>
	<BA1B675D85BDD87795D1666C@Ximines.local>
	<1322844048.29870.155.camel@zakaz.uk.xensource.com>
	<8D88C4D6C31A598129A942AD@Ximines.local>
	<4EDCDB75.6010403@canonical.com>
X-Mailer: Mulberry/4.0.8 (Mac OS X)
MIME-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com, Ian Campbell <Ian.Campbell@citrix.com>,
	Alex Bligh <alex@alex.org.uk>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Xen 4.x / Linux 3.x (dom0 and HVM domU)
 and	NIC	handling
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Alex Bligh <alex@alex.org.uk>
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Stefan,

--On 5 December 2011 15:55:49 +0100 Stefan Bader 
<stefan.bader@canonical.com> wrote:

> Personally I would think nobody could want both
> interfaces at the same time but I would not assume I know all of the use
> cases.

There are no sensible use cases I know of for having both at the
same time, but there are use cases where either a P2V migration
is done (where the P installation has hardcoded root=/dev/sda) or where
a kernel upgrade is done to a kernel supporting PV drivers and
unplug, where the current behaviour of unplugging stuff is not
the policy of least surprise.

OTOH we've got Xen4 cloud images booting with Precise with unplug
better than kvm does, precisely because kvm leaves both around
(as you have probably gathered from a bug that I filed in another
place...)

-- 
Alex Bligh

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 22:36:46 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 22:36:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RY3cU-0008BQ-Te; Tue, 06 Dec 2011 22:36:14 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <alex@alex.org.uk>) id 1RY3cT-0008B1-I1
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 22:36:13 +0000
X-Env-Sender: alex@alex.org.uk
X-Msg-Ref: server-3.tower-182.messagelabs.com!1323210926!6178428!1
X-Originating-IP: [89.16.176.221]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8593 invoked from network); 6 Dec 2011 22:35:27 -0000
Received: from mail.avalus.com (HELO mail.avalus.com) (89.16.176.221)
	by server-3.tower-182.messagelabs.com with SMTP;
	6 Dec 2011 22:35:27 -0000
Received: from [192.168.50.14] (lemondeh-adsl.demon.co.uk [83.105.105.209])
	by mail.avalus.com (Postfix) with ESMTPSA id E0B2DC560FE;
	Tue,  6 Dec 2011 22:35:24 +0000 (GMT)
Date: Tue, 06 Dec 2011 22:35:22 +0000
From: Alex Bligh <alex@alex.org.uk>
To: Stefan Bader <stefan.bader@canonical.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <6AD2EA47ECA2FF87985FFF1C@nimrod.local>
In-Reply-To: <4EDCDD42.3050104@canonical.com>
References: <4ED798B2.1040309@canonical.com> 
	<20111201180944.GH12984@reaktio.net>	<4ED8A45A.3050403@canonical.com> 
	<20111202104110.GL12984@reaktio.net> 
	<BA1B675D85BDD87795D1666C@Ximines.local> 
	<1322844048.29870.155.camel@zakaz.uk.xensource.com> 
	<8D88C4D6C31A598129A942AD@Ximines.local> 
	<1322847755.7376.45.camel@dagon.hellion.org.uk> 
	<12E319EEAA44FEB965D8F001@Ximines.local>
	<1322909055.7376.56.camel@dagon.hellion.org.uk>
	<4EDCDD42.3050104@canonical.com>
X-Mailer: Mulberry/4.0.8 (Mac OS X)
MIME-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com, Alex Bligh <alex@alex.org.uk>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Xen 4.x / Linux 3.x (dom0 and HVM domU) and	NIC
 handling
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Alex Bligh <alex@alex.org.uk>
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com



--On 5 December 2011 16:03:30 +0100 Stefan Bader 
<stefan.bader@canonical.com> wrote:

> At least in my limited experiments, this was not any issue. Though any
> newer installation uses grub2 and uuids.

Well, my experience here was mostly Lucid (as I think I said), and
vm-builder, which I believe is abandonware.

Ubuntu's cloud image stuff is now far better (having played with
it for a couple of days now we have Xen4 working). I am not sure
what Debian are doing.

-- 
Alex Bligh

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 22:36:46 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 22:36:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RY3cU-0008BQ-Te; Tue, 06 Dec 2011 22:36:14 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <alex@alex.org.uk>) id 1RY3cT-0008B1-I1
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 22:36:13 +0000
X-Env-Sender: alex@alex.org.uk
X-Msg-Ref: server-3.tower-182.messagelabs.com!1323210926!6178428!1
X-Originating-IP: [89.16.176.221]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8593 invoked from network); 6 Dec 2011 22:35:27 -0000
Received: from mail.avalus.com (HELO mail.avalus.com) (89.16.176.221)
	by server-3.tower-182.messagelabs.com with SMTP;
	6 Dec 2011 22:35:27 -0000
Received: from [192.168.50.14] (lemondeh-adsl.demon.co.uk [83.105.105.209])
	by mail.avalus.com (Postfix) with ESMTPSA id E0B2DC560FE;
	Tue,  6 Dec 2011 22:35:24 +0000 (GMT)
Date: Tue, 06 Dec 2011 22:35:22 +0000
From: Alex Bligh <alex@alex.org.uk>
To: Stefan Bader <stefan.bader@canonical.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <6AD2EA47ECA2FF87985FFF1C@nimrod.local>
In-Reply-To: <4EDCDD42.3050104@canonical.com>
References: <4ED798B2.1040309@canonical.com> 
	<20111201180944.GH12984@reaktio.net>	<4ED8A45A.3050403@canonical.com> 
	<20111202104110.GL12984@reaktio.net> 
	<BA1B675D85BDD87795D1666C@Ximines.local> 
	<1322844048.29870.155.camel@zakaz.uk.xensource.com> 
	<8D88C4D6C31A598129A942AD@Ximines.local> 
	<1322847755.7376.45.camel@dagon.hellion.org.uk> 
	<12E319EEAA44FEB965D8F001@Ximines.local>
	<1322909055.7376.56.camel@dagon.hellion.org.uk>
	<4EDCDD42.3050104@canonical.com>
X-Mailer: Mulberry/4.0.8 (Mac OS X)
MIME-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com, Alex Bligh <alex@alex.org.uk>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Xen 4.x / Linux 3.x (dom0 and HVM domU) and	NIC
 handling
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Alex Bligh <alex@alex.org.uk>
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com



--On 5 December 2011 16:03:30 +0100 Stefan Bader 
<stefan.bader@canonical.com> wrote:

> At least in my limited experiments, this was not any issue. Though any
> newer installation uses grub2 and uuids.

Well, my experience here was mostly Lucid (as I think I said), and
vm-builder, which I believe is abandonware.

Ubuntu's cloud image stuff is now far better (having played with
it for a couple of days now we have Xen4 working). I am not sure
what Debian are doing.

-- 
Alex Bligh

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 22:38:33 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 22:38:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RY3eS-0008Kf-DY; Tue, 06 Dec 2011 22:38:16 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <alex@alex.org.uk>) id 1RY3eR-0008KK-0a
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 22:38:15 +0000
X-Env-Sender: alex@alex.org.uk
X-Msg-Ref: server-12.tower-174.messagelabs.com!1323211048!4472617!1
X-Originating-IP: [89.16.176.221]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,lists.xensource.com
X-VirusChecked: Checked
Received: (qmail 10884 invoked from network); 6 Dec 2011 22:37:28 -0000
Received: from mail.avalus.com (HELO mail.avalus.com) (89.16.176.221)
	by server-12.tower-174.messagelabs.com with SMTP;
	6 Dec 2011 22:37:28 -0000
Received: from [192.168.50.14] (lemondeh-adsl.demon.co.uk [83.105.105.209])
	by mail.avalus.com (Postfix) with ESMTPSA id 5D5B4C560FE;
	Tue,  6 Dec 2011 22:37:25 +0000 (GMT)
Date: Tue, 06 Dec 2011 22:37:24 +0000
From: Alex Bligh <alex@alex.org.uk>
To: Ian Campbell <Ian.Campbell@citrix.com>,
	Stefan Bader <stefan.bader@canonical.com>
Message-ID: <A7261E19A92C4BB412171AA0@nimrod.local>
In-Reply-To: <1323101454.23681.7.camel@zakaz.uk.xensource.com>
References: <4ED798B2.1040309@canonical.com>	
	<20111201180944.GH12984@reaktio.net>	<4ED8A45A.3050403@canonical.com>	
	<20111202104110.GL12984@reaktio.net>	
	<BA1B675D85BDD87795D1666C@Ximines.local>	
	<1322844048.29870.155.camel@zakaz.uk.xensource.com>	
	<8D88C4D6C31A598129A942AD@Ximines.local>
	<4EDCDB75.6010403@canonical.com>
	<1323101454.23681.7.camel@zakaz.uk.xensource.com>
X-Mailer: Mulberry/4.0.8 (Mac OS X)
MIME-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com, Alex Bligh <alex@alex.org.uk>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Xen 4.x / Linux 3.x (dom0 and HVM domU) and	NIC
 handling
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Alex Bligh <alex@alex.org.uk>
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian,

--On 5 December 2011 16:10:54 +0000 Ian Campbell <Ian.Campbell@citrix.com> 
wrote:

>> Not sure how real the need for a mixed setup is.
>
> Basically non-existent IMHO. The option to not use pv devices is more
> for debugging or recovering in the case that you can't boot from the pv
> device for some reason (e.g. because you aren't using LABEL/UUID= ;-)).

I think the question was 'mixed setup' which I mostly agree on.

There is plenty of reason to use emulated only setup, including that
the kernel on the image does not support pv drivers at all. There's
an awful lot of crud that runs on 2.6.18.

-- 
Alex Bligh

 ------------------------------------------------------------------
The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 22:38:33 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 22:38:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RY3eS-0008Kf-DY; Tue, 06 Dec 2011 22:38:16 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <alex@alex.org.uk>) id 1RY3eR-0008KK-0a
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 22:38:15 +0000
X-Env-Sender: alex@alex.org.uk
X-Msg-Ref: server-12.tower-174.messagelabs.com!1323211048!4472617!1
X-Originating-IP: [89.16.176.221]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,lists.xensource.com
X-VirusChecked: Checked
Received: (qmail 10884 invoked from network); 6 Dec 2011 22:37:28 -0000
Received: from mail.avalus.com (HELO mail.avalus.com) (89.16.176.221)
	by server-12.tower-174.messagelabs.com with SMTP;
	6 Dec 2011 22:37:28 -0000
Received: from [192.168.50.14] (lemondeh-adsl.demon.co.uk [83.105.105.209])
	by mail.avalus.com (Postfix) with ESMTPSA id 5D5B4C560FE;
	Tue,  6 Dec 2011 22:37:25 +0000 (GMT)
Date: Tue, 06 Dec 2011 22:37:24 +0000
From: Alex Bligh <alex@alex.org.uk>
To: Ian Campbell <Ian.Campbell@citrix.com>,
	Stefan Bader <stefan.bader@canonical.com>
Message-ID: <A7261E19A92C4BB412171AA0@nimrod.local>
In-Reply-To: <1323101454.23681.7.camel@zakaz.uk.xensource.com>
References: <4ED798B2.1040309@canonical.com>	
	<20111201180944.GH12984@reaktio.net>	<4ED8A45A.3050403@canonical.com>	
	<20111202104110.GL12984@reaktio.net>	
	<BA1B675D85BDD87795D1666C@Ximines.local>	
	<1322844048.29870.155.camel@zakaz.uk.xensource.com>	
	<8D88C4D6C31A598129A942AD@Ximines.local>
	<4EDCDB75.6010403@canonical.com>
	<1323101454.23681.7.camel@zakaz.uk.xensource.com>
X-Mailer: Mulberry/4.0.8 (Mac OS X)
MIME-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com, Alex Bligh <alex@alex.org.uk>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Xen 4.x / Linux 3.x (dom0 and HVM domU) and	NIC
 handling
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Alex Bligh <alex@alex.org.uk>
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian,

--On 5 December 2011 16:10:54 +0000 Ian Campbell <Ian.Campbell@citrix.com> 
wrote:

>> Not sure how real the need for a mixed setup is.
>
> Basically non-existent IMHO. The option to not use pv devices is more
> for debugging or recovering in the case that you can't boot from the pv
> device for some reason (e.g. because you aren't using LABEL/UUID= ;-)).

I think the question was 'mixed setup' which I mostly agree on.

There is plenty of reason to use emulated only setup, including that
the kernel on the image does not support pv drivers at all. There's
an awful lot of crud that runs on 2.6.18.

-- 
Alex Bligh

 ------------------------------------------------------------------
The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 23:18:51 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 23:18:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RY4HN-0000KV-Pc; Tue, 06 Dec 2011 23:18:29 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jfehlig@suse.com>) id 1RY4HM-0000KQ-As
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 23:18:28 +0000
X-Env-Sender: jfehlig@suse.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1323213429!55651534!1
X-Originating-IP: [137.65.250.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17337 invoked from network); 6 Dec 2011 23:17:11 -0000
Received: from victor.provo.novell.com (HELO victor.provo.novell.com)
	(137.65.250.26)
	by server-9.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Dec 2011 23:17:11 -0000
Received: from [137.65.135.33] (prv-ext-foundry1int.gns.novell.com
	[137.65.251.240])
	by victor.provo.novell.com with ESMTP (TLS encrypted);
	Tue, 06 Dec 2011 16:17:35 -0700
Message-ID: <4EDEA28E.7010303@suse.com>
Date: Tue, 06 Dec 2011 16:17:34 -0700
From: Jim Fehlig <jfehlig@suse.com>
User-Agent: Thunderbird 2.0.0.24 (X11/20100302)
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <201111251721.12753.hahn@univention.de>	
	<20111201193711.GK12984@reaktio.net>	
	<1322769065.7376.36.camel@dagon.hellion.org.uk>	
	<201112020951.40156.hahn@univention.de>
	<1322821093.31810.332.camel@zakaz.uk.xensource.com>
In-Reply-To: <1322821093.31810.332.camel@zakaz.uk.xensource.com>
Cc: "libvir-list@redhat.com" <libvir-list@redhat.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Philipp Hahn <hahn@univention.de>
Subject: Re: [Xen-devel] [BUG] insufficient quoting between	"tap-ctl	list"
 and	xend/server/BlktapController.py
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell wrote:
> On Fri, 2011-12-02 at 08:51 +0000, Philipp Hahn wrote:
>   
>> Hello,
>>
>> On Thursday 01 December 2011 19:31:04 Ian Jackson wrote:
>>     
>>> Philipp Hahn writes ("Re: [Xen-devel] [BUG] insufficient quoting 
>>>       
>> between "tap-ctl list" and xend/server/BlktapController.py"):
>>     
>>>> As a quick work-around, the attached patch fixes the problem for me. That
>>>> is, until tap-ctl changes it's output format.
>>>>         
>>> Thanks, I have applied it.
>>>       
>> Thanks for applying.
>>
>> On Thursday 01 December 2011 20:51:05 Ian Campbell wrote:
>>     
>>> xend is deprecated. This ultimately means that xend will go away. If you
>>> are dependent on these features then you need put effort into ensuring
>>> that they become supported in libxl and xl.
>>>       
>> For our forthcomming release of UCS-3.0 we really wanted to switch from Xend 
>> to xl, but be had to switch back to using Xend, because libvirt still lacks 
>> some important features like migration; see 
>> <http://libvirt.org/hvsupport.html> for a comparison matrix. Back at the 
>> beginning of 2011 Univention sponsored Markus Gross to work on the xl-binding 
>> of libvirt, 
>>     
>
> Thank you for putting your money where your mouth is here!
>
>   
>> but after the end of his internship I have not seen that much 
>> work on the xl-binding in libvirt except from Jim Fehlig.
>>     
>
> AFAIK Jim is the main man working on this stuff. Last I heard he was
> working on migration but I don't know the status, Jim?
>   

As you've probably noticed, I haven't had much time to devote to libxl
and the libxl libvirt driver :-(.  Migration, and some other important
but missing features, are on my todo list, but not quite sure when I'll
get back to this work.

Regards,
Jim

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 23:18:51 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 23:18:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RY4HN-0000KV-Pc; Tue, 06 Dec 2011 23:18:29 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jfehlig@suse.com>) id 1RY4HM-0000KQ-As
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 23:18:28 +0000
X-Env-Sender: jfehlig@suse.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1323213429!55651534!1
X-Originating-IP: [137.65.250.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17337 invoked from network); 6 Dec 2011 23:17:11 -0000
Received: from victor.provo.novell.com (HELO victor.provo.novell.com)
	(137.65.250.26)
	by server-9.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Dec 2011 23:17:11 -0000
Received: from [137.65.135.33] (prv-ext-foundry1int.gns.novell.com
	[137.65.251.240])
	by victor.provo.novell.com with ESMTP (TLS encrypted);
	Tue, 06 Dec 2011 16:17:35 -0700
Message-ID: <4EDEA28E.7010303@suse.com>
Date: Tue, 06 Dec 2011 16:17:34 -0700
From: Jim Fehlig <jfehlig@suse.com>
User-Agent: Thunderbird 2.0.0.24 (X11/20100302)
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <201111251721.12753.hahn@univention.de>	
	<20111201193711.GK12984@reaktio.net>	
	<1322769065.7376.36.camel@dagon.hellion.org.uk>	
	<201112020951.40156.hahn@univention.de>
	<1322821093.31810.332.camel@zakaz.uk.xensource.com>
In-Reply-To: <1322821093.31810.332.camel@zakaz.uk.xensource.com>
Cc: "libvir-list@redhat.com" <libvir-list@redhat.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Philipp Hahn <hahn@univention.de>
Subject: Re: [Xen-devel] [BUG] insufficient quoting between	"tap-ctl	list"
 and	xend/server/BlktapController.py
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell wrote:
> On Fri, 2011-12-02 at 08:51 +0000, Philipp Hahn wrote:
>   
>> Hello,
>>
>> On Thursday 01 December 2011 19:31:04 Ian Jackson wrote:
>>     
>>> Philipp Hahn writes ("Re: [Xen-devel] [BUG] insufficient quoting 
>>>       
>> between "tap-ctl list" and xend/server/BlktapController.py"):
>>     
>>>> As a quick work-around, the attached patch fixes the problem for me. That
>>>> is, until tap-ctl changes it's output format.
>>>>         
>>> Thanks, I have applied it.
>>>       
>> Thanks for applying.
>>
>> On Thursday 01 December 2011 20:51:05 Ian Campbell wrote:
>>     
>>> xend is deprecated. This ultimately means that xend will go away. If you
>>> are dependent on these features then you need put effort into ensuring
>>> that they become supported in libxl and xl.
>>>       
>> For our forthcomming release of UCS-3.0 we really wanted to switch from Xend 
>> to xl, but be had to switch back to using Xend, because libvirt still lacks 
>> some important features like migration; see 
>> <http://libvirt.org/hvsupport.html> for a comparison matrix. Back at the 
>> beginning of 2011 Univention sponsored Markus Gross to work on the xl-binding 
>> of libvirt, 
>>     
>
> Thank you for putting your money where your mouth is here!
>
>   
>> but after the end of his internship I have not seen that much 
>> work on the xl-binding in libvirt except from Jim Fehlig.
>>     
>
> AFAIK Jim is the main man working on this stuff. Last I heard he was
> working on migration but I don't know the status, Jim?
>   

As you've probably noticed, I haven't had much time to devote to libxl
and the libxl libvirt driver :-(.  Migration, and some other important
but missing features, are on my todo list, but not quite sure when I'll
get back to this work.

Regards,
Jim

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 23:51:15 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 23:51:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RY4mU-0000ie-EE; Tue, 06 Dec 2011 23:50:38 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Neal.Taylor@ca.com>) id 1RY4mS-0000iZ-1k
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 23:50:36 +0000
X-Env-Sender: Neal.Taylor@ca.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1323215354!46838535!1
X-Originating-IP: [74.125.149.149]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7579 invoked from network); 6 Dec 2011 23:49:16 -0000
Received: from na3sys009aog123.obsmtp.com (HELO na3sys009aog123.obsmtp.com)
	(74.125.149.149)
	by server-10.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Dec 2011 23:49:16 -0000
Received: from USILMS191.ca.com ([141.202.246.45]) (using TLSv1) by
	na3sys009aob123.postini.com ([74.125.148.12]) with SMTP
	ID DSNKTt6qHwzZ6e6mxkKr8lIAz730cxZ9XrD0@postini.com;
	Tue, 06 Dec 2011 15:49:53 PST
Received: from USILMS170.ca.com (141.202.6.20) by USILMS191.ca.com
	(141.202.246.45) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Tue, 6 Dec 2011 18:49:50 -0500
Received: from USILMS110A.ca.com ([169.254.1.109]) by USILMS170.ca.com
	([141.202.6.20]) with mapi id 14.01.0289.001;
	Tue, 6 Dec 2011 18:49:49 -0500
From: "Taylor, Neal E" <Neal.Taylor@ca.com>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
Thread-Topic: [Xen-devel] PCI passthrough stopped working, brainache!
Thread-Index: AQHMs5IlDjGdeXPafk2P/m7YR1gy0ZXPbg1g
Date: Tue, 6 Dec 2011 23:49:48 +0000
Message-ID: <3E243B26F475504B9BB0BCC9728B0DA629E15807@USILMS110A.ca.com>
References: <20111012035032.GB26092@phenom.oracle.com>
	<CAE1-PRfuo10T2iKJUNoY=Aj4S_TjUbiPT1jARv+iD7g+1qWuNg@mail.gmail.com>
	<CAE1-PRd9Kicm=dRtDmPKGXM8-fp62NyvDdpww38jA3Afwrt8+g@mail.gmail.com>
	<20111013181543.GF15499@phenom.oracle.com>
	<CAE1-PRfGTxeQ59jmHfB6bKKk2+B5bNnKhAvXoV-5P__+nkhgKQ@mail.gmail.com>
	<1318674976.11016.24.camel@dagon.hellion.org.uk>
	<CAE1-PRe3FZknxdCLkhkGbzd-i=y5eGMAwY+yoa36j61oHNcRSw@mail.gmail.com>
	<CAE1-PRcUkuBexHrCnCCNEA4m=yoC8qWjmtfsaSq0h9NUA6r2cw@mail.gmail.com>
	<1319616286.9436.1.camel@zakaz.uk.xensource.com>
	<3E243B26F475504B9BB0BCC9728B0DA629E14CDE@USILMS110A.ca.com>
	<20111205210907.GB7784@andromeda.dapyr.net>
In-Reply-To: <20111205210907.GB7784@andromeda.dapyr.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [138.42.46.108]
MIME-Version: 1.0
Cc: Andy Burns <xen.lists@burns.me.uk>,
	xen-devel <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] PCI passthrough stopped working, brainache!
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Konrad,

Thanks for the patch but all I'm getting from the patch is:

Dec  6 19:40:30 Gridos_Node kernel: [  220.270179] SWIOTLB is 0% full
Dec  6 19:40:35 Gridos_Node kernel: [  225.270172] SWIOTLB is 0% full
Dec  6 19:40:40 Gridos_Node kernel: [  230.270179] SWIOTLB is 0% full
Dec  6 19:40:45 Gridos_Node kernel: [  235.270174] SWIOTLB is 0% full
Dec  6 19:40:50 Gridos_Node kernel: [  240.270179] SWIOTLB is 0% full
Dec  6 19:40:55 Gridos_Node kernel: [  245.270169] SWIOTLB is 0% full
Dec  6 19:41:00 Gridos_Node kernel: [  250.270178] SWIOTLB is 0% full
Dec  6 19:41:05 Gridos_Node kernel: [  255.270181] SWIOTLB is 0% full
Dec  6 19:41:10 Gridos_Node kernel: [  260.270181] SWIOTLB is 0% full
Dec  6 19:41:15 Gridos_Node kernel: [  265.270171] SWIOTLB is 0% full

I was hoping my problem was related but it looks like "not close enough." My issue is with the "failed to set dma mask" and others like it in the log segment below. The "Fusion MPT SPI Host driver 3.04.19" believes it is able to support dma, but nothing after it does. 

Dec  6 19:37:37 Gridos_Node kernel: Fusion MPT SAS Host driver 3.04.19
Dec  6 19:37:37 Gridos_Node kernel: ata_piix 0000:00:1f.1: enabling device (0005 -> 0007)
Dec  6 19:37:37 Gridos_Node kernel: ata_piix 0000:00:1f.1: can't derive routing for PCI INT A

Dec  6 19:37:37 Gridos_Node kernel: ata_piix 0000:00:1f.1: BMDMA: failed to set dma mask, falling back to PIO

Dec  6 19:37:37 Gridos_Node kernel: scsi1 : ata_piix
Dec  6 19:37:37 Gridos_Node kernel: scsi2 : ata_piix
Dec  6 19:37:37 Gridos_Node kernel: ata1: PATA max PIO4 cmd 0x1f0 ctl 0x3f6 bmdma 0xfc00 irq 14
Dec  6 19:37:37 Gridos_Node kernel: ata2: PATA max PIO4 cmd 0x170 ctl 0x376 bmdma 0xfc08 irq 15
Dec  6 19:37:37 Gridos_Node kernel: ata1.00: ATAPI: PHILIPS DVD-ROM SDR089, TD36, max UDMA/33
Dec  6 19:37:37 Gridos_Node kernel: ata1.00: configured for PIO4
Dec  6 19:37:37 Gridos_Node kernel: scsi 1:0:0:0: CD-ROM            PHILIPS  DVD-ROM SDR089   TD36 PQ: 0 ANSI: 5
Dec  6 19:37:37 Gridos_Node kernel: 0 mptspi 0000:02:05.0 alloc coherent: 57, free: 56
Dec  6 19:37:37 Gridos_Node kernel: 1 mptspi 0000:02:05.0 alloc coherent: 3, free: 0
Dec  6 19:37:37 Gridos_Node kernel: SWIOTLB is 0% full
Dec  6 19:37:37 Gridos_Node kernel: SWIOTLB is 0% full
Dec  6 19:37:37 Gridos_Node kernel: EXT3-fs: barriers not enabled
Dec  6 19:37:37 Gridos_Node kernel: kjournald starting.  Commit interval 5 seconds
Dec  6 19:37:37 Gridos_Node kernel: EXT3-fs (sda3): mounted filesystem with ordered data mode
Dec  6 19:37:37 Gridos_Node kernel: SWIOTLB is 0% full
Dec  6 19:37:37 Gridos_Node kernel: input: PC Speaker as /devices/platform/pcspkr/input/input2
Dec  6 19:37:37 Gridos_Node kernel: iTCO_vendor_support: vendor-support=0
Dec  6 19:37:37 Gridos_Node kernel: iTCO_wdt: Intel TCO WatchDog Timer Driver v1.06
Dec  6 19:37:37 Gridos_Node kernel: iTCO_wdt: Found a ICH5 or ICH5R TCO device (Version=1, TCOBASE=0x0860)
Dec  6 19:37:37 Gridos_Node kernel: iTCO_wdt: initialized. heartbeat=30 sec (nowayout=1)
Dec  6 19:37:37 Gridos_Node kernel: pata_acpi 0000:09:06.0: PCI INT A -> GSI 23 (level, low) -> IRQ 23
Dec  6 19:37:37 Gridos_Node kernel: pata_acpi 0000:09:06.0: BMDMA: failed to set dma mask, falling back to PIO
Dec  6 19:37:37 Gridos_Node kernel: pata_acpi 0000:09:06.0: PCI INT A disabled
Dec  6 19:37:37 Gridos_Node kernel: FDC 0 is a National Semiconductor PC87306
Dec  6 19:37:37 Gridos_Node kernel: xen_map_pirq_gsi: returning irq 23 for gsi 23
Dec  6 19:37:38 Gridos_Node kernel: Already setup the GSI :23
Dec  6 19:37:38 Gridos_Node kernel: pata_sil680 0000:09:06.0: PCI INT A -> GSI 23 (level, low) -> IRQ 23
Dec  6 19:37:38 Gridos_Node kernel: sil680: 133MHz clock.

Dec  6 19:37:38 Gridos_Node kernel: pata_sil680 0000:09:06.0: BMDMA: failed to set dma mask, falling back to PIO

neal

-----Original Message-----
From: Konrad Rzeszutek Wilk [mailto:konrad@darnok.org] 
Sent: Monday, December 05, 2011 1:09 PM
To: Taylor, Neal E
Cc: Ian Campbell; Andy Burns; xen-devel
Subject: Re: [Xen-devel] PCI passthrough stopped working, brainache!

On Mon, Dec 05, 2011 at 04:10:39PM +0000, Taylor, Neal E wrote:
> Andy,
> 
> Did I mess the solution for this or are you still working with 'mem=3.99999G'?
> 
.. snip..
> 
> Konrad had some suggestions in
> <20111020034000.GA2401@phenom.dumpdata.com> which would be worth trying.
> (that mail was sent on Thursday but appears to have sat in a queue 
> somewhere until after you sent this mail so just checking you've seen 
> it).
> 

.. which resolves itself to:

http://article.gmane.org/gmane.comp.emulators.xen.devel/114063

and in 3). I mentioned a patch. See attached please

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 06 23:51:15 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 Dec 2011 23:51:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RY4mU-0000ie-EE; Tue, 06 Dec 2011 23:50:38 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Neal.Taylor@ca.com>) id 1RY4mS-0000iZ-1k
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 23:50:36 +0000
X-Env-Sender: Neal.Taylor@ca.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1323215354!46838535!1
X-Originating-IP: [74.125.149.149]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7579 invoked from network); 6 Dec 2011 23:49:16 -0000
Received: from na3sys009aog123.obsmtp.com (HELO na3sys009aog123.obsmtp.com)
	(74.125.149.149)
	by server-10.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Dec 2011 23:49:16 -0000
Received: from USILMS191.ca.com ([141.202.246.45]) (using TLSv1) by
	na3sys009aob123.postini.com ([74.125.148.12]) with SMTP
	ID DSNKTt6qHwzZ6e6mxkKr8lIAz730cxZ9XrD0@postini.com;
	Tue, 06 Dec 2011 15:49:53 PST
Received: from USILMS170.ca.com (141.202.6.20) by USILMS191.ca.com
	(141.202.246.45) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Tue, 6 Dec 2011 18:49:50 -0500
Received: from USILMS110A.ca.com ([169.254.1.109]) by USILMS170.ca.com
	([141.202.6.20]) with mapi id 14.01.0289.001;
	Tue, 6 Dec 2011 18:49:49 -0500
From: "Taylor, Neal E" <Neal.Taylor@ca.com>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
Thread-Topic: [Xen-devel] PCI passthrough stopped working, brainache!
Thread-Index: AQHMs5IlDjGdeXPafk2P/m7YR1gy0ZXPbg1g
Date: Tue, 6 Dec 2011 23:49:48 +0000
Message-ID: <3E243B26F475504B9BB0BCC9728B0DA629E15807@USILMS110A.ca.com>
References: <20111012035032.GB26092@phenom.oracle.com>
	<CAE1-PRfuo10T2iKJUNoY=Aj4S_TjUbiPT1jARv+iD7g+1qWuNg@mail.gmail.com>
	<CAE1-PRd9Kicm=dRtDmPKGXM8-fp62NyvDdpww38jA3Afwrt8+g@mail.gmail.com>
	<20111013181543.GF15499@phenom.oracle.com>
	<CAE1-PRfGTxeQ59jmHfB6bKKk2+B5bNnKhAvXoV-5P__+nkhgKQ@mail.gmail.com>
	<1318674976.11016.24.camel@dagon.hellion.org.uk>
	<CAE1-PRe3FZknxdCLkhkGbzd-i=y5eGMAwY+yoa36j61oHNcRSw@mail.gmail.com>
	<CAE1-PRcUkuBexHrCnCCNEA4m=yoC8qWjmtfsaSq0h9NUA6r2cw@mail.gmail.com>
	<1319616286.9436.1.camel@zakaz.uk.xensource.com>
	<3E243B26F475504B9BB0BCC9728B0DA629E14CDE@USILMS110A.ca.com>
	<20111205210907.GB7784@andromeda.dapyr.net>
In-Reply-To: <20111205210907.GB7784@andromeda.dapyr.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [138.42.46.108]
MIME-Version: 1.0
Cc: Andy Burns <xen.lists@burns.me.uk>,
	xen-devel <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] PCI passthrough stopped working, brainache!
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Konrad,

Thanks for the patch but all I'm getting from the patch is:

Dec  6 19:40:30 Gridos_Node kernel: [  220.270179] SWIOTLB is 0% full
Dec  6 19:40:35 Gridos_Node kernel: [  225.270172] SWIOTLB is 0% full
Dec  6 19:40:40 Gridos_Node kernel: [  230.270179] SWIOTLB is 0% full
Dec  6 19:40:45 Gridos_Node kernel: [  235.270174] SWIOTLB is 0% full
Dec  6 19:40:50 Gridos_Node kernel: [  240.270179] SWIOTLB is 0% full
Dec  6 19:40:55 Gridos_Node kernel: [  245.270169] SWIOTLB is 0% full
Dec  6 19:41:00 Gridos_Node kernel: [  250.270178] SWIOTLB is 0% full
Dec  6 19:41:05 Gridos_Node kernel: [  255.270181] SWIOTLB is 0% full
Dec  6 19:41:10 Gridos_Node kernel: [  260.270181] SWIOTLB is 0% full
Dec  6 19:41:15 Gridos_Node kernel: [  265.270171] SWIOTLB is 0% full

I was hoping my problem was related but it looks like "not close enough." My issue is with the "failed to set dma mask" and others like it in the log segment below. The "Fusion MPT SPI Host driver 3.04.19" believes it is able to support dma, but nothing after it does. 

Dec  6 19:37:37 Gridos_Node kernel: Fusion MPT SAS Host driver 3.04.19
Dec  6 19:37:37 Gridos_Node kernel: ata_piix 0000:00:1f.1: enabling device (0005 -> 0007)
Dec  6 19:37:37 Gridos_Node kernel: ata_piix 0000:00:1f.1: can't derive routing for PCI INT A

Dec  6 19:37:37 Gridos_Node kernel: ata_piix 0000:00:1f.1: BMDMA: failed to set dma mask, falling back to PIO

Dec  6 19:37:37 Gridos_Node kernel: scsi1 : ata_piix
Dec  6 19:37:37 Gridos_Node kernel: scsi2 : ata_piix
Dec  6 19:37:37 Gridos_Node kernel: ata1: PATA max PIO4 cmd 0x1f0 ctl 0x3f6 bmdma 0xfc00 irq 14
Dec  6 19:37:37 Gridos_Node kernel: ata2: PATA max PIO4 cmd 0x170 ctl 0x376 bmdma 0xfc08 irq 15
Dec  6 19:37:37 Gridos_Node kernel: ata1.00: ATAPI: PHILIPS DVD-ROM SDR089, TD36, max UDMA/33
Dec  6 19:37:37 Gridos_Node kernel: ata1.00: configured for PIO4
Dec  6 19:37:37 Gridos_Node kernel: scsi 1:0:0:0: CD-ROM            PHILIPS  DVD-ROM SDR089   TD36 PQ: 0 ANSI: 5
Dec  6 19:37:37 Gridos_Node kernel: 0 mptspi 0000:02:05.0 alloc coherent: 57, free: 56
Dec  6 19:37:37 Gridos_Node kernel: 1 mptspi 0000:02:05.0 alloc coherent: 3, free: 0
Dec  6 19:37:37 Gridos_Node kernel: SWIOTLB is 0% full
Dec  6 19:37:37 Gridos_Node kernel: SWIOTLB is 0% full
Dec  6 19:37:37 Gridos_Node kernel: EXT3-fs: barriers not enabled
Dec  6 19:37:37 Gridos_Node kernel: kjournald starting.  Commit interval 5 seconds
Dec  6 19:37:37 Gridos_Node kernel: EXT3-fs (sda3): mounted filesystem with ordered data mode
Dec  6 19:37:37 Gridos_Node kernel: SWIOTLB is 0% full
Dec  6 19:37:37 Gridos_Node kernel: input: PC Speaker as /devices/platform/pcspkr/input/input2
Dec  6 19:37:37 Gridos_Node kernel: iTCO_vendor_support: vendor-support=0
Dec  6 19:37:37 Gridos_Node kernel: iTCO_wdt: Intel TCO WatchDog Timer Driver v1.06
Dec  6 19:37:37 Gridos_Node kernel: iTCO_wdt: Found a ICH5 or ICH5R TCO device (Version=1, TCOBASE=0x0860)
Dec  6 19:37:37 Gridos_Node kernel: iTCO_wdt: initialized. heartbeat=30 sec (nowayout=1)
Dec  6 19:37:37 Gridos_Node kernel: pata_acpi 0000:09:06.0: PCI INT A -> GSI 23 (level, low) -> IRQ 23
Dec  6 19:37:37 Gridos_Node kernel: pata_acpi 0000:09:06.0: BMDMA: failed to set dma mask, falling back to PIO
Dec  6 19:37:37 Gridos_Node kernel: pata_acpi 0000:09:06.0: PCI INT A disabled
Dec  6 19:37:37 Gridos_Node kernel: FDC 0 is a National Semiconductor PC87306
Dec  6 19:37:37 Gridos_Node kernel: xen_map_pirq_gsi: returning irq 23 for gsi 23
Dec  6 19:37:38 Gridos_Node kernel: Already setup the GSI :23
Dec  6 19:37:38 Gridos_Node kernel: pata_sil680 0000:09:06.0: PCI INT A -> GSI 23 (level, low) -> IRQ 23
Dec  6 19:37:38 Gridos_Node kernel: sil680: 133MHz clock.

Dec  6 19:37:38 Gridos_Node kernel: pata_sil680 0000:09:06.0: BMDMA: failed to set dma mask, falling back to PIO

neal

-----Original Message-----
From: Konrad Rzeszutek Wilk [mailto:konrad@darnok.org] 
Sent: Monday, December 05, 2011 1:09 PM
To: Taylor, Neal E
Cc: Ian Campbell; Andy Burns; xen-devel
Subject: Re: [Xen-devel] PCI passthrough stopped working, brainache!

On Mon, Dec 05, 2011 at 04:10:39PM +0000, Taylor, Neal E wrote:
> Andy,
> 
> Did I mess the solution for this or are you still working with 'mem=3.99999G'?
> 
.. snip..
> 
> Konrad had some suggestions in
> <20111020034000.GA2401@phenom.dumpdata.com> which would be worth trying.
> (that mail was sent on Thursday but appears to have sat in a queue 
> somewhere until after you sent this mail so just checking you've seen 
> it).
> 

.. which resolves itself to:

http://article.gmane.org/gmane.comp.emulators.xen.devel/114063

and in 3). I mentioned a patch. See attached please

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 00:44:48 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 00:44:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RY5cD-0001mm-Jn; Wed, 07 Dec 2011 00:44:05 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@cs.ubc.ca>) id 1RY5cC-0001mh-J6
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 00:44:04 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-6.tower-182.messagelabs.com!1323218595!6169813!1
X-Originating-IP: [142.103.6.52]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 527 invoked from network); 7 Dec 2011 00:43:17 -0000
Received: from smtp.cs.ubc.ca (HELO smtp.cs.ubc.ca) (142.103.6.52)
	by server-6.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 7 Dec 2011 00:43:17 -0000
Received: from mail-ee0-f43.google.com (mail-ee0-f43.google.com [74.125.83.43])
	(authenticated bits=0)
	by smtp.cs.ubc.ca (8.14.3/8.13.6) with ESMTP id pB70hCcl009500
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL)
	for <xen-devel@lists.xensource.com>; Tue, 6 Dec 2011 16:43:13 -0800
Received: by eekd49 with SMTP id d49so19501eek.30
	for <xen-devel@lists.xensource.com>;
	Tue, 06 Dec 2011 16:43:11 -0800 (PST)
Received: by 10.213.2.82 with SMTP id 18mr23195ebi.43.1323218591450; Tue, 06
	Dec 2011 16:43:11 -0800 (PST)
MIME-Version: 1.0
Received: by 10.204.179.10 with HTTP; Tue, 6 Dec 2011 16:42:30 -0800 (PST)
From: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Date: Tue, 6 Dec 2011 16:42:30 -0800
Message-ID: <CAP8mzPOvAXudECJb1_3LXL8i+cgq3jjD+vNM=UMWnN49ATUhqA@mail.gmail.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: [Xen-devel] X86 emulation under HAP/EPT
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: rshriram@cs.ubc.ca
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

For my research, I need to run a SMP hvm guest in log-dirty mode and
after the first log-dirty fault, instead of making the page r/w, I need to log
the next 128 reads & writes by the vcpus. After logging this many
accesses, I set the page
to rw as is the case with usual log-dirty mode. Basically, the page
access changes to
p2m_access_n after the first log-dirty fault and is then reverted to
p2m->default_access
after 128 accesses.

Log-dirty allows me to log only one write access. In order to log
multiple read/write accesses,
I resorted to *emulating* the instructions that cause the page fault.
(I guess I could also play around with the trap flags & single
stepping the guest, but thats a last resort).

My initial attempts to do this with shadow paging proved to be too
painful and cumbersome.
So I switched to HAP, and am using an Intel Xeon machine with EPT support.
I have a 32bit debian guest with 2.6.24 kernel and a 64-bit 2.6.32
pvops dom0, & xen-unstable.

I can see that the vmx_vmexit_handler does some emulation for select
operations (e.g., msr)
So, I assume that when the code faults with EXIT_REASON_EPT_VIOLATION
and jumps into
hvm.c:hvm_hap_nested_page_fault(), it is either due to MMIO/PoD/LogDirty

Is it right to assume that when the EPT_VIOLATION fault occurs, the
instruction in question
intends to do only simple reads/writes to the page? No MSRs, rdtscs,
cr3 switches, etc,
as they are caught and emulated in the vmexit handler

I added the following code in
xen/arch/x86/hvm/hvm.c:hvm_hap_nested_page_fault(),
where the majority of log-dirty bits get set,

/* Spurious fault? PoD and log-dirty also take this path. */
if ( p2m_is_ram(p2mt) )
{
  if ((p2ma != p2m_access_rx2rw) && (p2mt & p2m_ram_logdirty)
      && access_valid && (mfn_x(mfn) != INVALID_MFN) && !access_x)
    {
         if (pg->emulation_count >127)
         {
          emul_end:
                /* Set page as r/w in the EPT.
                   Give rwx access to page since earlier access was
no-access (hack)
                 */
                p2m_change_type(v->domain, gfn, p2m_ram_logdirty, p2m_ram_rw);
                paging_mark_dirty(mfn)
         }
         else
         {
            struct hvm_emulate_ctxt ctxt;
            struct cpu_user_regs = get_cpu_user_regs();
            int rc;

            /* Emulate */
            hvm_emulate_prepare(&ctxt, regs);
            rc = hvm_emulate_one(&ctxt);
            hvm_emulate_writeback(&ctxt);

            /* If emulation failed, give the page read/write access
and dont tinker with it again. */
            if (rc != X86EMUL_OKAY) goto emul_end;


            /* revoke all access to the page, so that we trap on next access.
             * the function below is exactly same as
p2m_change_type(), except that it takes the
             * access type also as a parameter, instead of setting the
access to p2m->default_access.
             */
            p2m_change_type_access(v->domain, gfn, p2m_ram_logdirty,
p2m_ram_logdirty, p2m_access_n);

            /* set bit in vcpu's log-dirty bitmap */
            vcpu_mark_dirty(v, mfn);
            pg->emul_count++;

            /* Seems to make no difference - with/without this call */
            ept_sync_domain(v->domain);
        }
           return 1;
    }
    else
    {
            paging_mark_dirty(v->domain, mfn_x(mfn));
            p2m_change_type(v->domain, gfn, p2m_ram_logdirty, p2m_ram_rw);
            return 1;
    }
}

When I enable the log dirty mode, I see a bunch of emulation failures
with exception code
X86EMUL_UNHANDLEABLE and then a vm-entry failure saying invalid guest state.

(XEN) Failed vm entry (exit reason 0x80000021) caused by invalid guest
state (0).
(XEN) ************* VMCS Area **************

(XEN) *** Guest State ***
(XEN) CR0: actual=0x000000008005003b, shadow=0x000000008005003b,
gh_mask=ffffffffffffffff
(XEN) CR4: actual=0x00000000000026d0, shadow=0x0000000000000690,
gh_mask=ffffffffffffffff
(XEN) CR3: actual=0x0000000037c90000, target_count=0
(XEN)      target0=0000000000000000, target1=0000000000000000
(XEN)      target2=0000000000000000, target3=0000000000000000
(XEN) RSP = 0x00000000f7c7ff84 (0x00000000f7c7ff84)  RIP =
0x00000000c03123e3 (0x00000000c03123e3)
(XEN) RFLAGS=0x0000000000000086 (0x0000000000000086)  DR7 = 0x0000000000000400
(XEN) Sysenter RSP=00000000c1fb1300 CS:RIP=0060:00000000c0104330
(XEN) CS: sel=0x0060, attr=0x0c09b, limit=0xffffffff, base=0x0000000000000000
(XEN) DS: sel=0x007b, attr=0x0c0f3, limit=0xffffffff, base=0x0000000000000000
(XEN) SS: sel=0x0068, attr=0x0c093, limit=0xffffffff, base=0x0000000000000000
(XEN) ES: sel=0x007b, attr=0x0c0f3, limit=0xffffffff, base=0x0000000000000000
(XEN) FS: sel=0x00d8, attr=0x08093, limit=0xffffffff, base=0x0000000001b63000
(XEN) GS: sel=0x0000, attr=0x1c000, limit=0xffffffff, base=0x0000000000000000
(XEN) GDTR:                           limit=0x000000ff, base=0x00000000c1fac000
(XEN) LDTR: sel=0x0000, attr=0x1c000, limit=0xffffffff, base=0x0000000000000000
(XEN) IDTR:                           limit=0x000007ff, base=0x00000000c03f8000
(XEN) TR: sel=0x0080, attr=0x0008b, limit=0x00002073, base=0x00000000c1faf100
(XEN) Guest PAT = 0x0007040600070406
(XEN) TSC Offset = fffffe96f2a9e5c0
(XEN) DebugCtl=0000000000000000 DebugExceptions=0000000000000000
(XEN) Interruptibility=0000 ActivityState=0000

(XEN) *** Host State ***
(XEN) RSP = 0xffff83082636ff90  RIP = 0xffff82c4801d0d40
(XEN) CS=e008 DS=0000 ES=0000 FS=0000 GS=0000 SS=0000 TR=e040
(XEN) FSBase=0000000000000000 GSBase=0000000000000000 TRBase=ffff8308263f5b00
(XEN) GDTBase=ffff830826359000 IDTBase=ffff830826365000
(XEN) CR0=000000008005003b CR3=000000083f7f0000 CR4=00000000000026f0
(XEN) Sysenter RSP=ffff83082636ffc0 CS:RIP=e008:ffff82c480218670
(XEN) Host PAT = 0x0000050100070406

(XEN) *** Control State ***
(XEN) PinBased=0000003f CPUBased=b6a065fa SecondaryExec=0000006b
(XEN) EntryControls=000051ff ExitControls=000fefff
(XEN) ExceptionBitmap=00040040
(XEN) VMEntry: intr_info=800000ef errcode=00000000 ilen=00000000
(XEN) VMExit: intr_info=00000000 errcode=00000000 ilen=00000000
(XEN)         reason=80000021 qualification=00000000
(XEN) IDTVectoring: info=800000ef errcode=00000000
(XEN) TPR Threshold = 0x00
(XEN) EPT pointer = 0x000000083f7fe01e
(XEN) Virtual processor ID = 0x0042
(XEN) **************************************

(XEN) domain_crash called from vmx.c:2161
(XEN) Domain 1 (vcpu#0) crashed on cpu#1:
(XEN) ----[ Xen-4.2-unstable-crew  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    1
(XEN) RIP:    0060:[<00000000c03123e3>]
(XEN) RFLAGS: 0000000000000086   CONTEXT: hvm guest
(XEN) rax: 00000000f7c0de80   rbx: 00000000f7c0de8c   rcx: 00000000f7cba700
(XEN) rdx: 00000000f7c0de80   rsi: 00000000f7c0de80   rdi: 00000000f7c0de80
(XEN) rbp: 00000000f7c0de84   rsp: 00000000f7c7ff84   r8:  0000000000000000
(XEN) r9:  0000000000000000   r10: 0000000000000000   r11: 0000000000000000
(XEN) r12: 0000000000000000   r13: 0000000000000000   r14: 0000000000000000
(XEN) r15: 0000000000000000   cr0: 000000008005003b   cr4: 0000000000000690
(XEN) cr3: 0000000037c90000   cr2: 00000000b7f69dcc
(XEN) ds: 007b   es: 007b   fs: 00d8   gs: 0000   ss: 0068   cs: 0060


Any pointers on how to resolve this issue?



Shriram

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 00:44:48 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 00:44:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RY5cD-0001mm-Jn; Wed, 07 Dec 2011 00:44:05 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@cs.ubc.ca>) id 1RY5cC-0001mh-J6
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 00:44:04 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-6.tower-182.messagelabs.com!1323218595!6169813!1
X-Originating-IP: [142.103.6.52]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 527 invoked from network); 7 Dec 2011 00:43:17 -0000
Received: from smtp.cs.ubc.ca (HELO smtp.cs.ubc.ca) (142.103.6.52)
	by server-6.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 7 Dec 2011 00:43:17 -0000
Received: from mail-ee0-f43.google.com (mail-ee0-f43.google.com [74.125.83.43])
	(authenticated bits=0)
	by smtp.cs.ubc.ca (8.14.3/8.13.6) with ESMTP id pB70hCcl009500
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL)
	for <xen-devel@lists.xensource.com>; Tue, 6 Dec 2011 16:43:13 -0800
Received: by eekd49 with SMTP id d49so19501eek.30
	for <xen-devel@lists.xensource.com>;
	Tue, 06 Dec 2011 16:43:11 -0800 (PST)
Received: by 10.213.2.82 with SMTP id 18mr23195ebi.43.1323218591450; Tue, 06
	Dec 2011 16:43:11 -0800 (PST)
MIME-Version: 1.0
Received: by 10.204.179.10 with HTTP; Tue, 6 Dec 2011 16:42:30 -0800 (PST)
From: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Date: Tue, 6 Dec 2011 16:42:30 -0800
Message-ID: <CAP8mzPOvAXudECJb1_3LXL8i+cgq3jjD+vNM=UMWnN49ATUhqA@mail.gmail.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: [Xen-devel] X86 emulation under HAP/EPT
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: rshriram@cs.ubc.ca
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

For my research, I need to run a SMP hvm guest in log-dirty mode and
after the first log-dirty fault, instead of making the page r/w, I need to log
the next 128 reads & writes by the vcpus. After logging this many
accesses, I set the page
to rw as is the case with usual log-dirty mode. Basically, the page
access changes to
p2m_access_n after the first log-dirty fault and is then reverted to
p2m->default_access
after 128 accesses.

Log-dirty allows me to log only one write access. In order to log
multiple read/write accesses,
I resorted to *emulating* the instructions that cause the page fault.
(I guess I could also play around with the trap flags & single
stepping the guest, but thats a last resort).

My initial attempts to do this with shadow paging proved to be too
painful and cumbersome.
So I switched to HAP, and am using an Intel Xeon machine with EPT support.
I have a 32bit debian guest with 2.6.24 kernel and a 64-bit 2.6.32
pvops dom0, & xen-unstable.

I can see that the vmx_vmexit_handler does some emulation for select
operations (e.g., msr)
So, I assume that when the code faults with EXIT_REASON_EPT_VIOLATION
and jumps into
hvm.c:hvm_hap_nested_page_fault(), it is either due to MMIO/PoD/LogDirty

Is it right to assume that when the EPT_VIOLATION fault occurs, the
instruction in question
intends to do only simple reads/writes to the page? No MSRs, rdtscs,
cr3 switches, etc,
as they are caught and emulated in the vmexit handler

I added the following code in
xen/arch/x86/hvm/hvm.c:hvm_hap_nested_page_fault(),
where the majority of log-dirty bits get set,

/* Spurious fault? PoD and log-dirty also take this path. */
if ( p2m_is_ram(p2mt) )
{
  if ((p2ma != p2m_access_rx2rw) && (p2mt & p2m_ram_logdirty)
      && access_valid && (mfn_x(mfn) != INVALID_MFN) && !access_x)
    {
         if (pg->emulation_count >127)
         {
          emul_end:
                /* Set page as r/w in the EPT.
                   Give rwx access to page since earlier access was
no-access (hack)
                 */
                p2m_change_type(v->domain, gfn, p2m_ram_logdirty, p2m_ram_rw);
                paging_mark_dirty(mfn)
         }
         else
         {
            struct hvm_emulate_ctxt ctxt;
            struct cpu_user_regs = get_cpu_user_regs();
            int rc;

            /* Emulate */
            hvm_emulate_prepare(&ctxt, regs);
            rc = hvm_emulate_one(&ctxt);
            hvm_emulate_writeback(&ctxt);

            /* If emulation failed, give the page read/write access
and dont tinker with it again. */
            if (rc != X86EMUL_OKAY) goto emul_end;


            /* revoke all access to the page, so that we trap on next access.
             * the function below is exactly same as
p2m_change_type(), except that it takes the
             * access type also as a parameter, instead of setting the
access to p2m->default_access.
             */
            p2m_change_type_access(v->domain, gfn, p2m_ram_logdirty,
p2m_ram_logdirty, p2m_access_n);

            /* set bit in vcpu's log-dirty bitmap */
            vcpu_mark_dirty(v, mfn);
            pg->emul_count++;

            /* Seems to make no difference - with/without this call */
            ept_sync_domain(v->domain);
        }
           return 1;
    }
    else
    {
            paging_mark_dirty(v->domain, mfn_x(mfn));
            p2m_change_type(v->domain, gfn, p2m_ram_logdirty, p2m_ram_rw);
            return 1;
    }
}

When I enable the log dirty mode, I see a bunch of emulation failures
with exception code
X86EMUL_UNHANDLEABLE and then a vm-entry failure saying invalid guest state.

(XEN) Failed vm entry (exit reason 0x80000021) caused by invalid guest
state (0).
(XEN) ************* VMCS Area **************

(XEN) *** Guest State ***
(XEN) CR0: actual=0x000000008005003b, shadow=0x000000008005003b,
gh_mask=ffffffffffffffff
(XEN) CR4: actual=0x00000000000026d0, shadow=0x0000000000000690,
gh_mask=ffffffffffffffff
(XEN) CR3: actual=0x0000000037c90000, target_count=0
(XEN)      target0=0000000000000000, target1=0000000000000000
(XEN)      target2=0000000000000000, target3=0000000000000000
(XEN) RSP = 0x00000000f7c7ff84 (0x00000000f7c7ff84)  RIP =
0x00000000c03123e3 (0x00000000c03123e3)
(XEN) RFLAGS=0x0000000000000086 (0x0000000000000086)  DR7 = 0x0000000000000400
(XEN) Sysenter RSP=00000000c1fb1300 CS:RIP=0060:00000000c0104330
(XEN) CS: sel=0x0060, attr=0x0c09b, limit=0xffffffff, base=0x0000000000000000
(XEN) DS: sel=0x007b, attr=0x0c0f3, limit=0xffffffff, base=0x0000000000000000
(XEN) SS: sel=0x0068, attr=0x0c093, limit=0xffffffff, base=0x0000000000000000
(XEN) ES: sel=0x007b, attr=0x0c0f3, limit=0xffffffff, base=0x0000000000000000
(XEN) FS: sel=0x00d8, attr=0x08093, limit=0xffffffff, base=0x0000000001b63000
(XEN) GS: sel=0x0000, attr=0x1c000, limit=0xffffffff, base=0x0000000000000000
(XEN) GDTR:                           limit=0x000000ff, base=0x00000000c1fac000
(XEN) LDTR: sel=0x0000, attr=0x1c000, limit=0xffffffff, base=0x0000000000000000
(XEN) IDTR:                           limit=0x000007ff, base=0x00000000c03f8000
(XEN) TR: sel=0x0080, attr=0x0008b, limit=0x00002073, base=0x00000000c1faf100
(XEN) Guest PAT = 0x0007040600070406
(XEN) TSC Offset = fffffe96f2a9e5c0
(XEN) DebugCtl=0000000000000000 DebugExceptions=0000000000000000
(XEN) Interruptibility=0000 ActivityState=0000

(XEN) *** Host State ***
(XEN) RSP = 0xffff83082636ff90  RIP = 0xffff82c4801d0d40
(XEN) CS=e008 DS=0000 ES=0000 FS=0000 GS=0000 SS=0000 TR=e040
(XEN) FSBase=0000000000000000 GSBase=0000000000000000 TRBase=ffff8308263f5b00
(XEN) GDTBase=ffff830826359000 IDTBase=ffff830826365000
(XEN) CR0=000000008005003b CR3=000000083f7f0000 CR4=00000000000026f0
(XEN) Sysenter RSP=ffff83082636ffc0 CS:RIP=e008:ffff82c480218670
(XEN) Host PAT = 0x0000050100070406

(XEN) *** Control State ***
(XEN) PinBased=0000003f CPUBased=b6a065fa SecondaryExec=0000006b
(XEN) EntryControls=000051ff ExitControls=000fefff
(XEN) ExceptionBitmap=00040040
(XEN) VMEntry: intr_info=800000ef errcode=00000000 ilen=00000000
(XEN) VMExit: intr_info=00000000 errcode=00000000 ilen=00000000
(XEN)         reason=80000021 qualification=00000000
(XEN) IDTVectoring: info=800000ef errcode=00000000
(XEN) TPR Threshold = 0x00
(XEN) EPT pointer = 0x000000083f7fe01e
(XEN) Virtual processor ID = 0x0042
(XEN) **************************************

(XEN) domain_crash called from vmx.c:2161
(XEN) Domain 1 (vcpu#0) crashed on cpu#1:
(XEN) ----[ Xen-4.2-unstable-crew  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    1
(XEN) RIP:    0060:[<00000000c03123e3>]
(XEN) RFLAGS: 0000000000000086   CONTEXT: hvm guest
(XEN) rax: 00000000f7c0de80   rbx: 00000000f7c0de8c   rcx: 00000000f7cba700
(XEN) rdx: 00000000f7c0de80   rsi: 00000000f7c0de80   rdi: 00000000f7c0de80
(XEN) rbp: 00000000f7c0de84   rsp: 00000000f7c7ff84   r8:  0000000000000000
(XEN) r9:  0000000000000000   r10: 0000000000000000   r11: 0000000000000000
(XEN) r12: 0000000000000000   r13: 0000000000000000   r14: 0000000000000000
(XEN) r15: 0000000000000000   cr0: 000000008005003b   cr4: 0000000000000690
(XEN) cr3: 0000000037c90000   cr2: 00000000b7f69dcc
(XEN) ds: 007b   es: 007b   fs: 00d8   gs: 0000   ss: 0068   cs: 0060


Any pointers on how to resolve this issue?



Shriram

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 01:54:02 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 01:54:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RY6hD-0005pu-5D; Wed, 07 Dec 2011 01:53:19 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RY6hB-0005pp-IY
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 01:53:17 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1323222751!6190134!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU5MQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21126 invoked from network); 7 Dec 2011 01:52:31 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Dec 2011 01:52:31 -0000
X-IronPort-AV: E=Sophos;i="4.71,310,1320624000"; 
   d="scan'208";a="9331892"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Dec 2011 01:52:30 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 7 Dec 2011 01:52:30 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RY6gQ-0006Wi-4m;
	Wed, 07 Dec 2011 01:52:30 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RY6gO-0001IA-IF;
	Wed, 07 Dec 2011 01:52:29 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10393-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 7 Dec 2011 01:52:28 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10393: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10393 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10393/

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-i386-win           8 guest-saverestore         fail REGR. vs. 10201
 test-i386-i386-win            8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-amd64-win          8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-i386-win-vcpus1    7 windows-install           fail REGR. vs. 10201
 test-amd64-amd64-xl-win       7 windows-install           fail REGR. vs. 10201
 test-amd64-i386-xl-win-vcpus1  7 windows-install          fail REGR. vs. 10201
 test-i386-i386-xl-win         7 windows-install           fail REGR. vs. 10201

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-win7-amd64  7 windows-install              fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install          fail never pass
 test-amd64-i386-xl-win7-amd64  7 windows-install              fail  never pass
 test-i386-i386-xl-winxpsp3    7 windows-install              fail   never pass
 test-amd64-i386-xend-winxpsp3  7 windows-install              fail  never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   never pass

version targeted for testing:
 xen                  38eb74c01d9d
baseline version:
 xen                  62ff6a318c5d

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scanneel.ca>
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Andres Lagar-Cavilla <andres@lagarcavilla>
  Andrew Cooper <andrew.cooper3@citrix.com>
  Anthony PERARD <anthony.perard@citrix.com>
  Brendan Cully <brendan@cs.ubc.ca>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Haitao Shan <haitao.shan@intel.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@novell.com>
  Jan Beulich <jbeulich@suse.com>
  Jonathan Davies <jonathan.davies@citrix.com>
  juergen.gross@ts.fujitsu.com
  Keir Fraser <keir@xen.org>
  Liu, Jinsong <jinsong.liu@intel.com>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
  Philipp Hahn <hahn@univention.de>
  Shriram Rajagopalan <rshriram@cs.ubc.ca>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang2 <wei.wang2@amd.com>
  Xudong Hao <xudong.hao@intel.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 1493 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 01:54:02 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 01:54:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RY6hD-0005pu-5D; Wed, 07 Dec 2011 01:53:19 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RY6hB-0005pp-IY
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 01:53:17 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1323222751!6190134!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU5MQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21126 invoked from network); 7 Dec 2011 01:52:31 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Dec 2011 01:52:31 -0000
X-IronPort-AV: E=Sophos;i="4.71,310,1320624000"; 
   d="scan'208";a="9331892"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Dec 2011 01:52:30 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 7 Dec 2011 01:52:30 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RY6gQ-0006Wi-4m;
	Wed, 07 Dec 2011 01:52:30 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RY6gO-0001IA-IF;
	Wed, 07 Dec 2011 01:52:29 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10393-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 7 Dec 2011 01:52:28 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10393: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10393 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10393/

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-i386-win           8 guest-saverestore         fail REGR. vs. 10201
 test-i386-i386-win            8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-amd64-win          8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-i386-win-vcpus1    7 windows-install           fail REGR. vs. 10201
 test-amd64-amd64-xl-win       7 windows-install           fail REGR. vs. 10201
 test-amd64-i386-xl-win-vcpus1  7 windows-install          fail REGR. vs. 10201
 test-i386-i386-xl-win         7 windows-install           fail REGR. vs. 10201

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-win7-amd64  7 windows-install              fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install          fail never pass
 test-amd64-i386-xl-win7-amd64  7 windows-install              fail  never pass
 test-i386-i386-xl-winxpsp3    7 windows-install              fail   never pass
 test-amd64-i386-xend-winxpsp3  7 windows-install              fail  never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   never pass

version targeted for testing:
 xen                  38eb74c01d9d
baseline version:
 xen                  62ff6a318c5d

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scanneel.ca>
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Andres Lagar-Cavilla <andres@lagarcavilla>
  Andrew Cooper <andrew.cooper3@citrix.com>
  Anthony PERARD <anthony.perard@citrix.com>
  Brendan Cully <brendan@cs.ubc.ca>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Haitao Shan <haitao.shan@intel.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@novell.com>
  Jan Beulich <jbeulich@suse.com>
  Jonathan Davies <jonathan.davies@citrix.com>
  juergen.gross@ts.fujitsu.com
  Keir Fraser <keir@xen.org>
  Liu, Jinsong <jinsong.liu@intel.com>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
  Philipp Hahn <hahn@univention.de>
  Shriram Rajagopalan <rshriram@cs.ubc.ca>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang2 <wei.wang2@amd.com>
  Xudong Hao <xudong.hao@intel.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 1493 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 02:03:20 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 02:03:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RY6qK-0006Zb-Vz; Wed, 07 Dec 2011 02:02:44 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RY6qI-0006ZU-A0
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 02:02:42 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-8.tower-216.messagelabs.com!1323223314!6461573!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15532 invoked from network); 7 Dec 2011 02:01:55 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-8.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 7 Dec 2011 02:01:55 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RY6pV-000B32-Ax; Wed, 07 Dec 2011 02:01:53 +0000
Date: Wed, 7 Dec 2011 02:01:53 +0000
From: Tim Deegan <tim@xen.org>
To: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Message-ID: <20111207020153.GE31448@ocelot.phlegethon.org>
References: <CAP8mzPOvAXudECJb1_3LXL8i+cgq3jjD+vNM=UMWnN49ATUhqA@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAP8mzPOvAXudECJb1_3LXL8i+cgq3jjD+vNM=UMWnN49ATUhqA@mail.gmail.com>
User-Agent: Mutt/1.4.2.1i
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] X86 emulation under HAP/EPT
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 16:42 -0800 on 06 Dec (1323189750), Shriram Rajagopalan wrote:
> Log-dirty allows me to log only one write access. In order to log
> multiple read/write accesses,
> I resorted to *emulating* the instructions that cause the page fault.
> (I guess I could also play around with the trap flags & single
> stepping the guest, but thats a last resort).

Sure.  Single-stepping would require you to pause all other vcpus for
safety.  While that might or might not be slower than emulating, it's
hard to do without deadlocking. :) 

> I can see that the vmx_vmexit_handler does some emulation for select
> operations (e.g., msr)
> So, I assume that when the code faults with EXIT_REASON_EPT_VIOLATION
> and jumps into
> hvm.c:hvm_hap_nested_page_fault(), it is either due to MMIO/PoD/LogDirty

It's because of a vioation of the right in the EPT table; so any of
those, or the newe mem_access/vm-paging/memory-sharing mechanisms (but
only if you enable them), or if the guest just accesses memory that
isn't there. :)

> Is it right to assume that when the EPT_VIOLATION fault occurs, the
> instruction in question
> intends to do only simple reads/writes to the page? No MSRs, rdtscs,
> cr3 switches, etc,

All you know is that the CPU is accessing the page.  The instruction under
%rip could be anything at all, if an interrupt arrived and the stack
pointer crossed into a new page while writing the stack frame.

Even if it is a plain memory access, it could be using a vector
instruction that's not supprted by the emulator.

> When I enable the log dirty mode, I see a bunch of emulation failures
> with exception code
> X86EMUL_UNHANDLEABLE and then a vm-entry failure saying invalid guest state.

[...]
 
> Any pointers on how to resolve this issue?

I'd start by printing the bytes under %rip when you see
X86EMUL_UNHANDLEABLE, which will tell you what instruciton is failing.
That will help you track down _why_ it's failing.

The Intel manuals have a long list of the state checks that can cause
this VMENTER failure; I don't think there's currently code in the tree
to figure out which it is, but if you do end up writing it a patch would
be welcome. :)

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 02:03:20 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 02:03:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RY6qK-0006Zb-Vz; Wed, 07 Dec 2011 02:02:44 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RY6qI-0006ZU-A0
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 02:02:42 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-8.tower-216.messagelabs.com!1323223314!6461573!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15532 invoked from network); 7 Dec 2011 02:01:55 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-8.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 7 Dec 2011 02:01:55 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RY6pV-000B32-Ax; Wed, 07 Dec 2011 02:01:53 +0000
Date: Wed, 7 Dec 2011 02:01:53 +0000
From: Tim Deegan <tim@xen.org>
To: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Message-ID: <20111207020153.GE31448@ocelot.phlegethon.org>
References: <CAP8mzPOvAXudECJb1_3LXL8i+cgq3jjD+vNM=UMWnN49ATUhqA@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAP8mzPOvAXudECJb1_3LXL8i+cgq3jjD+vNM=UMWnN49ATUhqA@mail.gmail.com>
User-Agent: Mutt/1.4.2.1i
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] X86 emulation under HAP/EPT
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 16:42 -0800 on 06 Dec (1323189750), Shriram Rajagopalan wrote:
> Log-dirty allows me to log only one write access. In order to log
> multiple read/write accesses,
> I resorted to *emulating* the instructions that cause the page fault.
> (I guess I could also play around with the trap flags & single
> stepping the guest, but thats a last resort).

Sure.  Single-stepping would require you to pause all other vcpus for
safety.  While that might or might not be slower than emulating, it's
hard to do without deadlocking. :) 

> I can see that the vmx_vmexit_handler does some emulation for select
> operations (e.g., msr)
> So, I assume that when the code faults with EXIT_REASON_EPT_VIOLATION
> and jumps into
> hvm.c:hvm_hap_nested_page_fault(), it is either due to MMIO/PoD/LogDirty

It's because of a vioation of the right in the EPT table; so any of
those, or the newe mem_access/vm-paging/memory-sharing mechanisms (but
only if you enable them), or if the guest just accesses memory that
isn't there. :)

> Is it right to assume that when the EPT_VIOLATION fault occurs, the
> instruction in question
> intends to do only simple reads/writes to the page? No MSRs, rdtscs,
> cr3 switches, etc,

All you know is that the CPU is accessing the page.  The instruction under
%rip could be anything at all, if an interrupt arrived and the stack
pointer crossed into a new page while writing the stack frame.

Even if it is a plain memory access, it could be using a vector
instruction that's not supprted by the emulator.

> When I enable the log dirty mode, I see a bunch of emulation failures
> with exception code
> X86EMUL_UNHANDLEABLE and then a vm-entry failure saying invalid guest state.

[...]
 
> Any pointers on how to resolve this issue?

I'd start by printing the bytes under %rip when you see
X86EMUL_UNHANDLEABLE, which will tell you what instruciton is failing.
That will help you track down _why_ it's failing.

The Intel manuals have a long list of the state checks that can cause
this VMENTER failure; I don't think there's currently code in the tree
to figure out which it is, but if you do end up writing it a patch would
be welcome. :)

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 03:38:03 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 03: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.xensource.com>)
	id 1RY8Ju-00071a-3Y; Wed, 07 Dec 2011 03:37:22 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <annie.li@oracle.com>) id 1RY8Js-00071V-1d
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 03:37:20 +0000
X-Env-Sender: annie.li@oracle.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1323228991!7787176!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDM3NDIw\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8774 invoked from network); 7 Dec 2011 03:36:33 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-2.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 7 Dec 2011 03:36:33 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pB73aRUx029851
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 7 Dec 2011 03:36:28 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pB73aQlF014172
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 7 Dec 2011 03:36:26 GMT
Received: from abhmt104.oracle.com (abhmt104.oracle.com [141.146.116.56])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pB73aJO1002394; Tue, 6 Dec 2011 21:36:19 -0600
Received: from [10.182.39.81] (/10.182.39.81)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 06 Dec 2011 19:36:19 -0800
Message-ID: <4EDEDF2E.3040204@oracle.com>
Date: Wed, 07 Dec 2011 11:36:14 +0800
From: ANNIE LI <annie.li@oracle.com>
Organization: Oracle Corporation
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.9.2.23) Gecko/20110920 Thunderbird/3.1.15
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <4EDDF41E.8070200@oracle.com>	
	<1323168999-4434-1-git-send-email-annie.li@oracle.com>
	<1323171726.23681.65.camel@zakaz.uk.xensource.com>
In-Reply-To: <1323171726.23681.65.camel@zakaz.uk.xensource.com>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090208.4EDEDF3C.00BF,ss=1,re=0.000,fgs=0
Cc: "jeremy@goop.org" <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	"kurt.hackel@oracle.com" <kurt.hackel@oracle.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Paul Durrant <Paul.Durrant@citrix.com>
Subject: Re: [Xen-devel] [PATCH 1/2] xen/granttable: Support sub-page grants
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Thanks for your reviewing, Ian.
>>   EXPORT_SYMBOL_GPL(gnttab_grant_foreign_access);
>>
>> +int gnttab_grant_foreign_access_subpage_v2(domid_t domid, unsigned long frame,
>> +					   int flags, unsigned page_off,
>> +					   unsigned length)
> Please drop the v2 suffixes on the public functions.
OK, the initial interface is without v2 suffixes. It was added in order 
to reminder user the interfaces are only available for grant table v2.
But I am fine to remove it, and following ops fn pointers are better.
> Any reason not to route these via the ops table for consistency with all
> the other ops? Then your availability check becomes a test for NULL fn
> pointer rather than a specific version.
Ok, it is good.
How about following implements?

gnttab_v1_ops = {
  ...
.access_subpage = NULL;
.access_ref_subpage = NULL;
.access_trans = NULL;
.access_ref_trans = NULL;
}

gnttab_v2_ops = {
  ...
.access_subpage = access_subpage_v2;
.access_ref_subpage = access_ref_subpage_v2;
.access_trans = access_trans_v2;
.access_ref_trans = access_ref_trans_v2;
}

gnttab_request_version()
{
.....
    if(v2)
       gnttab_interface = &gnttab_v2_ops;
    else
       gnttab_interface = &gnttab_v1_ops;
.....
}

int gnttab_grant_foreign_access_subpage()
{
       if(gnttab_interface->access_subpage != NULL)
             return gnttab_interface->access_subpage;
       return Esomething;
}

Same operations for access_ref_subpage, access_trans and access_ref_trans.

bool gnttab_subpage_available()
{
      return (gnttab_interface->access_subpage != NULL);
}

bool gnttab_subpage_available()
{
      return (gnttab_interface->access_trans != NULL);
}

Thanks
Annie

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 03:38:03 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 03: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.xensource.com>)
	id 1RY8Ju-00071a-3Y; Wed, 07 Dec 2011 03:37:22 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <annie.li@oracle.com>) id 1RY8Js-00071V-1d
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 03:37:20 +0000
X-Env-Sender: annie.li@oracle.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1323228991!7787176!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDM3NDIw\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8774 invoked from network); 7 Dec 2011 03:36:33 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-2.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 7 Dec 2011 03:36:33 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pB73aRUx029851
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 7 Dec 2011 03:36:28 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pB73aQlF014172
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 7 Dec 2011 03:36:26 GMT
Received: from abhmt104.oracle.com (abhmt104.oracle.com [141.146.116.56])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pB73aJO1002394; Tue, 6 Dec 2011 21:36:19 -0600
Received: from [10.182.39.81] (/10.182.39.81)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 06 Dec 2011 19:36:19 -0800
Message-ID: <4EDEDF2E.3040204@oracle.com>
Date: Wed, 07 Dec 2011 11:36:14 +0800
From: ANNIE LI <annie.li@oracle.com>
Organization: Oracle Corporation
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.9.2.23) Gecko/20110920 Thunderbird/3.1.15
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <4EDDF41E.8070200@oracle.com>	
	<1323168999-4434-1-git-send-email-annie.li@oracle.com>
	<1323171726.23681.65.camel@zakaz.uk.xensource.com>
In-Reply-To: <1323171726.23681.65.camel@zakaz.uk.xensource.com>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090208.4EDEDF3C.00BF,ss=1,re=0.000,fgs=0
Cc: "jeremy@goop.org" <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	"kurt.hackel@oracle.com" <kurt.hackel@oracle.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Paul Durrant <Paul.Durrant@citrix.com>
Subject: Re: [Xen-devel] [PATCH 1/2] xen/granttable: Support sub-page grants
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Thanks for your reviewing, Ian.
>>   EXPORT_SYMBOL_GPL(gnttab_grant_foreign_access);
>>
>> +int gnttab_grant_foreign_access_subpage_v2(domid_t domid, unsigned long frame,
>> +					   int flags, unsigned page_off,
>> +					   unsigned length)
> Please drop the v2 suffixes on the public functions.
OK, the initial interface is without v2 suffixes. It was added in order 
to reminder user the interfaces are only available for grant table v2.
But I am fine to remove it, and following ops fn pointers are better.
> Any reason not to route these via the ops table for consistency with all
> the other ops? Then your availability check becomes a test for NULL fn
> pointer rather than a specific version.
Ok, it is good.
How about following implements?

gnttab_v1_ops = {
  ...
.access_subpage = NULL;
.access_ref_subpage = NULL;
.access_trans = NULL;
.access_ref_trans = NULL;
}

gnttab_v2_ops = {
  ...
.access_subpage = access_subpage_v2;
.access_ref_subpage = access_ref_subpage_v2;
.access_trans = access_trans_v2;
.access_ref_trans = access_ref_trans_v2;
}

gnttab_request_version()
{
.....
    if(v2)
       gnttab_interface = &gnttab_v2_ops;
    else
       gnttab_interface = &gnttab_v1_ops;
.....
}

int gnttab_grant_foreign_access_subpage()
{
       if(gnttab_interface->access_subpage != NULL)
             return gnttab_interface->access_subpage;
       return Esomething;
}

Same operations for access_ref_subpage, access_trans and access_ref_trans.

bool gnttab_subpage_available()
{
      return (gnttab_interface->access_subpage != NULL);
}

bool gnttab_subpage_available()
{
      return (gnttab_interface->access_trans != NULL);
}

Thanks
Annie

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 03:38:15 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 03: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.xensource.com>)
	id 1RY8KD-00072H-HD; Wed, 07 Dec 2011 03:37:41 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <annie.li@oracle.com>) id 1RY8KB-00071x-VP
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 03:37:40 +0000
X-Env-Sender: annie.li@oracle.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1323229011!6165494!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDM3NDIw\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5554 invoked from network); 7 Dec 2011 03:36:53 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-11.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 7 Dec 2011 03:36:53 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pB73amUW030044
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 7 Dec 2011 03:36:49 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pB73akXv021849
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 7 Dec 2011 03:36:46 GMT
Received: from abhmt120.oracle.com (abhmt120.oracle.com [141.146.116.72])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pB73aeDE017050; Tue, 6 Dec 2011 21:36:41 -0600
Received: from [10.182.39.81] (/10.182.39.81)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 06 Dec 2011 19:36:40 -0800
Message-ID: <4EDEDF44.4000307@oracle.com>
Date: Wed, 07 Dec 2011 11:36:36 +0800
From: ANNIE LI <annie.li@oracle.com>
Organization: Oracle Corporation
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.9.2.23) Gecko/20110920 Thunderbird/3.1.15
MIME-Version: 1.0
To: Jeremy Fitzhardinge <jeremy@goop.org>
References: <4EDDF41E.8070200@oracle.com>
	<1323168999-4434-1-git-send-email-annie.li@oracle.com>
	<1323171726.23681.65.camel@zakaz.uk.xensource.com>
	<4EDE4EC4.8070802@goop.org>
In-Reply-To: <4EDE4EC4.8070802@goop.org>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090205.4EDEDF51.0054,ss=1,re=0.000,fgs=0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	"kurt.hackel@oracle.com" <kurt.hackel@oracle.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Paul Durrant <Paul.Durrant@citrix.com>
Subject: Re: [Xen-devel] [PATCH 1/2] xen/granttable: Support sub-page grants
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com



>> Returning -Esomething might be less drastic? ENOSYS perhaps?
> Yeah, BUG_ON shouldn't be used for API misuse unless there's absolutely
> no other way to handle it.
OK, will change it, thanks.
>>> +	gnttab_shared.v2[ref].sub_page.frame = frame;
>>> +	gnttab_shared.v2[ref].sub_page.page_off = page_off;
>>> +	gnttab_shared.v2[ref].sub_page.length = length;
>>> +	gnttab_shared.v2[ref].hdr.domid = domid;
>>> +	wmb();
>>> +	gnttab_shared.v2[ref].hdr.flags =
>>> +				GTF_permit_access | GTF_sub_page | flags;
>>> +}
>>> +EXPORT_SYMBOL_GPL(gnttab_grant_foreign_access_ref_subpage_v2);
>>> +
>>> +bool gnttab_subpage_trans_grants_available(void)
>>> +{
>>> +	return grant_table_version == 2;
>>> +}
>> It's not clear this adds anything over and above letting the user query
>> the grant table version. It's hard to tell since there are no users
>> presented here though. Perhaps separate subpage and transitive functions
>> would be cleaner?
> Well, in general, specifically testing for features rather than
> interface versions is better.
Ok, will split it into 2 functions and check the function pointer 
instead of grant table version, thanks.

Thanks
Annie


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 03:38:15 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 03: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.xensource.com>)
	id 1RY8KD-00072H-HD; Wed, 07 Dec 2011 03:37:41 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <annie.li@oracle.com>) id 1RY8KB-00071x-VP
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 03:37:40 +0000
X-Env-Sender: annie.li@oracle.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1323229011!6165494!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDM3NDIw\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5554 invoked from network); 7 Dec 2011 03:36:53 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-11.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 7 Dec 2011 03:36:53 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pB73amUW030044
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 7 Dec 2011 03:36:49 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pB73akXv021849
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 7 Dec 2011 03:36:46 GMT
Received: from abhmt120.oracle.com (abhmt120.oracle.com [141.146.116.72])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pB73aeDE017050; Tue, 6 Dec 2011 21:36:41 -0600
Received: from [10.182.39.81] (/10.182.39.81)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 06 Dec 2011 19:36:40 -0800
Message-ID: <4EDEDF44.4000307@oracle.com>
Date: Wed, 07 Dec 2011 11:36:36 +0800
From: ANNIE LI <annie.li@oracle.com>
Organization: Oracle Corporation
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.9.2.23) Gecko/20110920 Thunderbird/3.1.15
MIME-Version: 1.0
To: Jeremy Fitzhardinge <jeremy@goop.org>
References: <4EDDF41E.8070200@oracle.com>
	<1323168999-4434-1-git-send-email-annie.li@oracle.com>
	<1323171726.23681.65.camel@zakaz.uk.xensource.com>
	<4EDE4EC4.8070802@goop.org>
In-Reply-To: <4EDE4EC4.8070802@goop.org>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090205.4EDEDF51.0054,ss=1,re=0.000,fgs=0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	"kurt.hackel@oracle.com" <kurt.hackel@oracle.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Paul Durrant <Paul.Durrant@citrix.com>
Subject: Re: [Xen-devel] [PATCH 1/2] xen/granttable: Support sub-page grants
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com



>> Returning -Esomething might be less drastic? ENOSYS perhaps?
> Yeah, BUG_ON shouldn't be used for API misuse unless there's absolutely
> no other way to handle it.
OK, will change it, thanks.
>>> +	gnttab_shared.v2[ref].sub_page.frame = frame;
>>> +	gnttab_shared.v2[ref].sub_page.page_off = page_off;
>>> +	gnttab_shared.v2[ref].sub_page.length = length;
>>> +	gnttab_shared.v2[ref].hdr.domid = domid;
>>> +	wmb();
>>> +	gnttab_shared.v2[ref].hdr.flags =
>>> +				GTF_permit_access | GTF_sub_page | flags;
>>> +}
>>> +EXPORT_SYMBOL_GPL(gnttab_grant_foreign_access_ref_subpage_v2);
>>> +
>>> +bool gnttab_subpage_trans_grants_available(void)
>>> +{
>>> +	return grant_table_version == 2;
>>> +}
>> It's not clear this adds anything over and above letting the user query
>> the grant table version. It's hard to tell since there are no users
>> presented here though. Perhaps separate subpage and transitive functions
>> would be cleaner?
> Well, in general, specifically testing for features rather than
> interface versions is better.
Ok, will split it into 2 functions and check the function pointer 
instead of grant table version, thanks.

Thanks
Annie


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 05:17:48 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 05: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.xensource.com>)
	id 1RY9sT-0007lF-60; Wed, 07 Dec 2011 05:17:09 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RY9sR-0007lA-W2
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 05:17:08 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1323234981!6471911!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU5MQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20724 invoked from network); 7 Dec 2011 05:16:21 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Dec 2011 05:16:21 -0000
X-IronPort-AV: E=Sophos;i="4.71,311,1320624000"; 
   d="scan'208";a="9332846"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Dec 2011 05:16:20 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 7 Dec 2011 05:16:20 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RY9rg-0007eF-K3;
	Wed, 07 Dec 2011 05:16:20 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RY9rg-0007YL-J1;
	Wed, 07 Dec 2011 05:16:20 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10397-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 7 Dec 2011 05:16:20 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10397: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10397 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10397/

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-i386-win           8 guest-saverestore         fail REGR. vs. 10201
 test-i386-i386-win            8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-amd64-win          8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-i386-win-vcpus1    8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-amd64-xl-win       7 windows-install           fail REGR. vs. 10201
 test-amd64-i386-xl-win-vcpus1  8 guest-saverestore        fail REGR. vs. 10201
 test-i386-i386-xl-win         8 guest-saverestore         fail REGR. vs. 10201

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-win7-amd64  7 windows-install              fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install          fail never pass
 test-amd64-i386-xl-win7-amd64  7 windows-install              fail  never pass
 test-i386-i386-xl-winxpsp3    7 windows-install              fail   never pass
 test-amd64-i386-xend-winxpsp3  7 windows-install              fail  never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   never pass

version targeted for testing:
 xen                  38eb74c01d9d
baseline version:
 xen                  62ff6a318c5d

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scanneel.ca>
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Andres Lagar-Cavilla <andres@lagarcavilla>
  Andrew Cooper <andrew.cooper3@citrix.com>
  Anthony PERARD <anthony.perard@citrix.com>
  Brendan Cully <brendan@cs.ubc.ca>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Haitao Shan <haitao.shan@intel.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@novell.com>
  Jan Beulich <jbeulich@suse.com>
  Jonathan Davies <jonathan.davies@citrix.com>
  juergen.gross@ts.fujitsu.com
  Keir Fraser <keir@xen.org>
  Liu, Jinsong <jinsong.liu@intel.com>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
  Philipp Hahn <hahn@univention.de>
  Shriram Rajagopalan <rshriram@cs.ubc.ca>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang2 <wei.wang2@amd.com>
  Xudong Hao <xudong.hao@intel.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 1493 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 05:17:48 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 05: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.xensource.com>)
	id 1RY9sT-0007lF-60; Wed, 07 Dec 2011 05:17:09 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RY9sR-0007lA-W2
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 05:17:08 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1323234981!6471911!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU5MQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20724 invoked from network); 7 Dec 2011 05:16:21 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Dec 2011 05:16:21 -0000
X-IronPort-AV: E=Sophos;i="4.71,311,1320624000"; 
   d="scan'208";a="9332846"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Dec 2011 05:16:20 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 7 Dec 2011 05:16:20 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RY9rg-0007eF-K3;
	Wed, 07 Dec 2011 05:16:20 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RY9rg-0007YL-J1;
	Wed, 07 Dec 2011 05:16:20 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10397-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 7 Dec 2011 05:16:20 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10397: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10397 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10397/

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-i386-win           8 guest-saverestore         fail REGR. vs. 10201
 test-i386-i386-win            8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-amd64-win          8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-i386-win-vcpus1    8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-amd64-xl-win       7 windows-install           fail REGR. vs. 10201
 test-amd64-i386-xl-win-vcpus1  8 guest-saverestore        fail REGR. vs. 10201
 test-i386-i386-xl-win         8 guest-saverestore         fail REGR. vs. 10201

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-win7-amd64  7 windows-install              fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install          fail never pass
 test-amd64-i386-xl-win7-amd64  7 windows-install              fail  never pass
 test-i386-i386-xl-winxpsp3    7 windows-install              fail   never pass
 test-amd64-i386-xend-winxpsp3  7 windows-install              fail  never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   never pass

version targeted for testing:
 xen                  38eb74c01d9d
baseline version:
 xen                  62ff6a318c5d

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scanneel.ca>
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Andres Lagar-Cavilla <andres@lagarcavilla>
  Andrew Cooper <andrew.cooper3@citrix.com>
  Anthony PERARD <anthony.perard@citrix.com>
  Brendan Cully <brendan@cs.ubc.ca>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Haitao Shan <haitao.shan@intel.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@novell.com>
  Jan Beulich <jbeulich@suse.com>
  Jonathan Davies <jonathan.davies@citrix.com>
  juergen.gross@ts.fujitsu.com
  Keir Fraser <keir@xen.org>
  Liu, Jinsong <jinsong.liu@intel.com>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
  Philipp Hahn <hahn@univention.de>
  Shriram Rajagopalan <rshriram@cs.ubc.ca>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang2 <wei.wang2@amd.com>
  Xudong Hao <xudong.hao@intel.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 1493 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 07:05:31 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 07:05:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYBXf-0000C3-2m; Wed, 07 Dec 2011 07:03:47 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <xiantao.zhang@intel.com>) id 1RYBXd-0000By-6S
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 07:03:45 +0000
X-Env-Sender: xiantao.zhang@intel.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1323241377!4354422!1
X-Originating-IP: [143.182.124.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjEwNzkx\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16030 invoked from network); 7 Dec 2011 07:02:58 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-14.tower-174.messagelabs.com with SMTP;
	7 Dec 2011 07:02:58 -0000
Received: from azsmga002.ch.intel.com ([10.2.17.35])
	by azsmga101.ch.intel.com with ESMTP; 06 Dec 2011 23:02:56 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,311,1320652800"; d="scan'208";a="44659493"
Received: from pgsmsx603.gar.corp.intel.com ([10.221.43.87])
	by AZSMGA002.ch.intel.com with ESMTP; 06 Dec 2011 23:02:54 -0800
Received: from pgsmsx151.gar.corp.intel.com (172.30.236.41) by
	pgsmsx603.gar.corp.intel.com (10.221.43.87) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Wed, 7 Dec 2011 15:02:52 +0800
Received: from shsmsx602.ccr.corp.intel.com (10.239.4.104) by
	PGSMSX151.gar.corp.intel.com (172.30.236.41) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Wed, 7 Dec 2011 15:02:52 +0800
Received: from shsmsx502.ccr.corp.intel.com ([10.239.4.96]) by
	SHSMSX602.ccr.corp.intel.com ([10.239.4.104]) with mapi; Wed, 7 Dec 2011
	15:02:51 +0800
From: "Zhang, Xiantao" <xiantao.zhang@intel.com>
To: "stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Wed, 7 Dec 2011 15:00:11 +0800
Thread-Topic: [Xen-devel] [PATCH RFC 04/25] Replace "/" operand with div64
Thread-Index: Acy0RCyemylbkJbrQ06B4H2HTZu+wAAZifiA
Message-ID: <BC00F5384FCFC9499AF06F92E8B78A9E287D4A0E53@shsmsx502.ccr.corp.intel.com>
References: <alpine.DEB.2.00.1112061753410.31179@kaball-desktop>
	<1323195609-17277-4-git-send-email-stefano.stabellini@eu.citrix.com>
In-Reply-To: <1323195609-17277-4-git-send-email-stefano.stabellini@eu.citrix.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>,
	"Tim.Deegan@citrix.com" <Tim.Deegan@citrix.com>
Subject: Re: [Xen-devel] [PATCH RFC 04/25] Replace "/" operand with div64
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi, Stefano 
Great work from you guys!  One quick comment:  Just found the below logic's change maybe wrong and probably  break current things. 
Original logic is  A+B -(C%D), but it is changed to  (A+B-C)%D,  so if it is not an intended fix, it should be an issue. 
Thanks!
Xiantao  

>diff --git a/xen/common/timer.c b/xen/common/timer.c index 0547ea3..043250e 100644
>--- a/xen/common/timer.c
>+++ b/xen/common/timer.c
>@@ -23,6 +23,7 @@
>#include <xen/symbols.h>
>#include <asm/system.h>
>#include <asm/desc.h>
>+#include <asm/div64.h>
> #include <asm/atomic.h>
> 
> /* We program the time hardware this far behind the closest deadline. */ @@ -503,16 +504,18 @@ static void timer_softirq_action(void)
> 
> s_time_t align_timer(s_time_t firsttick, uint64_t period)  {
>+    uint64_t n;
 >    if ( !period )
 >        return firsttick;
 
>-    return firsttick + (period - 1) - ((firsttick - 1) % period);
>+    n = firsttick + (period - 1) - (firsttick - 1);
>+    return do_div(n, period);
> }
 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 07:05:31 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 07:05:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYBXf-0000C3-2m; Wed, 07 Dec 2011 07:03:47 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <xiantao.zhang@intel.com>) id 1RYBXd-0000By-6S
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 07:03:45 +0000
X-Env-Sender: xiantao.zhang@intel.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1323241377!4354422!1
X-Originating-IP: [143.182.124.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjEwNzkx\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16030 invoked from network); 7 Dec 2011 07:02:58 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-14.tower-174.messagelabs.com with SMTP;
	7 Dec 2011 07:02:58 -0000
Received: from azsmga002.ch.intel.com ([10.2.17.35])
	by azsmga101.ch.intel.com with ESMTP; 06 Dec 2011 23:02:56 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,311,1320652800"; d="scan'208";a="44659493"
Received: from pgsmsx603.gar.corp.intel.com ([10.221.43.87])
	by AZSMGA002.ch.intel.com with ESMTP; 06 Dec 2011 23:02:54 -0800
Received: from pgsmsx151.gar.corp.intel.com (172.30.236.41) by
	pgsmsx603.gar.corp.intel.com (10.221.43.87) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Wed, 7 Dec 2011 15:02:52 +0800
Received: from shsmsx602.ccr.corp.intel.com (10.239.4.104) by
	PGSMSX151.gar.corp.intel.com (172.30.236.41) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Wed, 7 Dec 2011 15:02:52 +0800
Received: from shsmsx502.ccr.corp.intel.com ([10.239.4.96]) by
	SHSMSX602.ccr.corp.intel.com ([10.239.4.104]) with mapi; Wed, 7 Dec 2011
	15:02:51 +0800
From: "Zhang, Xiantao" <xiantao.zhang@intel.com>
To: "stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Wed, 7 Dec 2011 15:00:11 +0800
Thread-Topic: [Xen-devel] [PATCH RFC 04/25] Replace "/" operand with div64
Thread-Index: Acy0RCyemylbkJbrQ06B4H2HTZu+wAAZifiA
Message-ID: <BC00F5384FCFC9499AF06F92E8B78A9E287D4A0E53@shsmsx502.ccr.corp.intel.com>
References: <alpine.DEB.2.00.1112061753410.31179@kaball-desktop>
	<1323195609-17277-4-git-send-email-stefano.stabellini@eu.citrix.com>
In-Reply-To: <1323195609-17277-4-git-send-email-stefano.stabellini@eu.citrix.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>,
	"Tim.Deegan@citrix.com" <Tim.Deegan@citrix.com>
Subject: Re: [Xen-devel] [PATCH RFC 04/25] Replace "/" operand with div64
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi, Stefano 
Great work from you guys!  One quick comment:  Just found the below logic's change maybe wrong and probably  break current things. 
Original logic is  A+B -(C%D), but it is changed to  (A+B-C)%D,  so if it is not an intended fix, it should be an issue. 
Thanks!
Xiantao  

>diff --git a/xen/common/timer.c b/xen/common/timer.c index 0547ea3..043250e 100644
>--- a/xen/common/timer.c
>+++ b/xen/common/timer.c
>@@ -23,6 +23,7 @@
>#include <xen/symbols.h>
>#include <asm/system.h>
>#include <asm/desc.h>
>+#include <asm/div64.h>
> #include <asm/atomic.h>
> 
> /* We program the time hardware this far behind the closest deadline. */ @@ -503,16 +504,18 @@ static void timer_softirq_action(void)
> 
> s_time_t align_timer(s_time_t firsttick, uint64_t period)  {
>+    uint64_t n;
 >    if ( !period )
 >        return firsttick;
 
>-    return firsttick + (period - 1) - ((firsttick - 1) % period);
>+    n = firsttick + (period - 1) - (firsttick - 1);
>+    return do_div(n, period);
> }
 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 07:14:56 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 07:14:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYBht-0000Ou-Iy; Wed, 07 Dec 2011 07:14:21 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Philippe.Simonet@swisscom.com>) id 1RYBhr-0000Oc-Ua
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 07:14:20 +0000
X-Env-Sender: Philippe.Simonet@swisscom.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1323242012!6480647!1
X-Originating-IP: [193.222.81.100]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkzLjIyMi44MS4xMDAgPT4gOTE4MzE=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28777 invoked from network); 7 Dec 2011 07:13:33 -0000
Received: from outmail100.swisscom.com (HELO mail.swisscom.com)
	(193.222.81.100)
	by server-9.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 7 Dec 2011 07:13:33 -0000
Received: by mail.swisscom.com; Wed, 7 Dec 2011 08:13:29 +0100
From: <Philippe.Simonet@swisscom.com>
To: <ml-xen-devel@hfp.de>, <xen-devel@lists.xensource.com>
Thread-Topic: [Xen-devel] Possible hint for "Clocksource tsc unstable" problem
Thread-Index: AQHMjad9lpfoNCzfJ0ekOlQTVsk4NpWDnHGAgAABUqD//9/2gIBDXsTA///zCQCAAlx1AIAHFykg
Date: Wed, 7 Dec 2011 07:13:27 +0000
Message-ID: <FF93AF260AC2BB499A119CC65B092CF7312080CC@sg000713.corproot.net>
References: <4E9D94A0.10102@hfp.de>
	<FF93AF260AC2BB499A119CC65B092CF7311817E2@sg000713.corproot.net>
	<F1CD4AC5B4A5024AAB60E28A82A8450A046CE5EE@winexch1.office.turtle-entertainment.de>
	<CABx4GKqodU4FLmX3adiCi3U-eKe5cDMVtNV2ZhzFAMsKL_1uTg@mail.gmail.com>
	<FF93AF260AC2BB499A119CC65B092CF7311EE626@sg000713.corproot.net>
	<CABx4GKo7CBCW6cn49Kr2O+NTm78ms7Xnh_ub1EZ7pdt+Cmp=Lg@mail.gmail.com>
	<4ED92CAA.2040008@hfp.de>
In-Reply-To: <4ED92CAA.2040008@hfp.de>
Accept-Language: en-US, de-CH
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.65.122.32]
MIME-Version: 1.0
Cc: tp@turtle-entertainment.de, olivier.hanesse@gmail.com
Subject: Re: [Xen-devel] Possible hint for "Clocksource tsc unstable" problem
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6945283992981499603=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============6945283992981499603==
Content-Language: en-US
Content-Type: multipart/alternative;
	boundary="_000_FF93AF260AC2BB499A119CC65B092CF7312080CCsg000713corproo_"

--_000_FF93AF260AC2BB499A119CC65B092CF7312080CCsg000713corproo_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi



by me it's the same case : I have 2 productive machine type, the one with t=
he AMD 6174

make problem 1 time per month, the one with the AMD 2384 didn't make any pr=
oblem since 2 years

and different XEN / kernel version.



Philippe



processor       : 23

vendor_id       : AuthenticAMD

cpu family      : 16

model           : 9

model name      : AMD Opteron(tm) Processor 6174

stepping        : 1

cpu MHz         : 1296464.014

cache size      : 512 KB

fpu             : yes

fpu_exception   : yes

cpuid level     : 5

wp              : yes

flags           : fpu de tsc msr pae mce cx8 apic mtrr mca cmov pat clflush=
 mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt lm 3dnowext 3dnow constant=
_tsc rep_good nonstop_tsc extd_apicid amd_dcm pni cx16 popcnt hypervisor la=
hf_lm cmp_legacy extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch nod=
eid_msr

bogomips        : 4400.22

TLB size        : 1024 4K pages

clflush size    : 64

cache_alignment : 64

address sizes   : 48 bits physical, 48 bits virtual

power management: ts ttp tm stc 100mhzsteps hwpstate





processor       : 7

vendor_id       : AuthenticAMD

cpu family      : 16

model           : 4

model name      : Quad-Core AMD Opteron(tm) Processor 2384

stepping        : 2

cpu MHz         : 2826450.137

cache size      : 512 KB

fpu             : yes

fpu_exception   : yes

cpuid level     : 5

wp              : yes

flags           : fpu de tsc msr pae mce cx8 apic mtrr mca cmov pat clflush=
 mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt lm 3dnowext 3dnow constant=
_tsc rep_good nonstop_tsc extd_apicid pni cx16 popcnt hypervisor lahf_lm cm=
p_legacy extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch

bogomips        : 5400.33

TLB size        : 1024 4K pages

clflush size    : 64

cache_alignment : 64

address sizes   : 48 bits physical, 48 bits virtual

power management: ts ttp tm stc 100mhzsteps hwpstate





> -----Original Message-----

> From: Andreas Kinzler [mailto:ml-xen-devel@hfp.de]

> Sent: Friday, December 02, 2011 8:53 PM

> To: xen-devel@lists.xensource.com

> Cc: Simonet Philippe, ITS-SDL-EIS-CNV-DLE-TLC; tp@turtle-entertainment.de=
;

> Olivier Hanesse

> Subject: Re: [Xen-devel] Possible hint for "Clocksource tsc unstable" pro=
blem

>

> On 01.12.2011 08:49, Olivier Hanesse wrote:

> > good news !

> > Is your "test system" the same hardware as before ?

> > For example, I don't have time issue with processor having the

> > 'nonstop_tsc' flag.

> > I got only time issue on older processor (Xeon L5420 for example)

>

> Sorry, but my report was on a machine with Xeon E5620 (has nonstop_tsc).

> I did some tests to reproduce the behavior by blocking NTP traffic via ip=
tables

> but the problem did not reproduce in a lab setting.

>

> Regards Andreas

>

> >     *From:*Olivier Hanesse [mailto:olivier.hanesse@gmail.com

> >     <mailto:olivier.hanesse@gmail.com>]

> >     *Sent:* Wednesday, October 19, 2011 2:48 PM

> >     *To:* Thomas P=F6hler

> >     *Cc:* Simonet Philippe, ITS-SDL-EIS-CNV-DLE-TLC; ml-xen-devel@hfp.d=
e<mailto:ml-xen-devel@hfp.de>

> >     <mailto:ml-xen-devel@hfp.de>

> >     *Subject:* Re: [Xen-devel] Possible hint for "Clocksource tsc

> >     unstable" problem____

> >

> >     __ __

> >

> >     Hi,____

> >

> >     __ __

> >

> >     Same here.____

> >

> >     I am using ntpd in dom0 too (lenny version so 4.2.4)____

> >

> >     __ __

> >

> >     Regards____

> >

> >     __ __

> >

> >     Olivier____

> >

> >     __ __

> >

> >     2011/10/19 Thomas P=F6hler <tp@turtle-entertainment.de

> >     <mailto:tp@turtle-entertainment.de>>____

> >

> >     Hi Philippe,

> >

> >     we are using ntpd in Dom0 too. (also ntpd - NTP daemon program -

> >     Ver. 4.2.6p2).

> >     We are monitoring ntp over a nagios plugin, check_ntp

> >

> >     Regards

> >     Thomas

> >

> >     -----Urspr=FCngliche Nachricht-----

> >     Von: Philippe.Simonet@swisscom.com<mailto:Philippe.Simonet@swisscom=
.com>

> >     <mailto:Philippe.Simonet@swisscom.com>

> >     [mailto:Philippe.Simonet@swisscom.com

> >     <mailto:Philippe.Simonet@swisscom.com>]

> >     Gesendet: Mittwoch, 19. Oktober 2011 14:40

> >     An: olivier.hanesse@gmail.com<mailto:olivier.hanesse@gmail.com> <ma=
ilto:olivier.hanesse@gmail.com>;

> >     Thomas P=F6hler

> >     Cc: ml-xen-devel@hfp.de<mailto:ml-xen-devel@hfp.de> <mailto:ml-xen-=
devel@hfp.de>

> >     Betreff: RE: [Xen-devel] Possible hint for "Clocksource tsc

> >     unstable" problem____

> >

> >

> >     Hi Olivier and Thomas

> >

> >     andreas ist using ntpd in DOM0, myself too (ntpd - NTP daemon

> >     program - Ver. 4.2.6p2)

> >

> >     and you ?

> >

> >     @andreas : how do you turn on your ntp logging ?

> >

> >     Philippe

> >

> >

> >      > -----Original Message-----

> >      > From: xen-devel-bounces@lists.xensource.com<mailto:xen-devel-bou=
nces@lists.xensource.com>

> >     <mailto:xen-devel-bounces@lists.xensource.com> [mailto:xen-devel-

> >     <mailto:xen-devel->

> >      > bounces@lists.xensource.com<mailto:bounces@lists.xensource.com>

> <mailto:bounces@lists.xensource.com>]

> >     On Behalf Of Andreas Kinzler

> >      > Sent: Tuesday, October 18, 2011 5:01 PM

> >      > To: xen-devel@lists.xensource.com<mailto:xen-devel@lists.xensour=
ce.com>

> >     <mailto:xen-devel@lists.xensource.com>

> >      > Subject: [Xen-devel] Possible hint for "Clocksource tsc unstable=
"

> >     problem

> >      >

> >      > Hello,

> >      >

> >      > I made an interesting observation related to the "Clocksource ts=
c

> >      > unstable (delta =3D -2999660320319 ns)" problem. In the log of n=
tpd

> >     I found:

> >      >

> >      > Oct  5 03:46:35 greenville-dom0 ntpd[4020]: kernel time sync sta=
tus

> >      > change 6001

> >      > Oct  5 04:03:41 greenville-dom0 ntpd[4020]: kernel time sync sta=
tus

> >      > change 2001

> >      > Oct  5 05:29:03 greenville-dom0 ntpd[4020]: kernel time sync sta=
tus

> >      > change 6001

> >      > Oct  5 05:46:09 greenville-dom0 ntpd[4020]: kernel time sync sta=
tus

> >      > change 2001

> >      > Oct  5 06:54:30 greenville-dom0 ntpd[4020]: synchronized to

> >      > 192.53.103.104 <tel:192.53.103.104>, stratum 1

> >      > Oct  5 06:54:30 greenville-dom0 ntpd[4020]: kernel time sync sta=
tus

> >      > change 6001

> >      > Oct  5 07:28:22 greenville-dom0 ntpd[4020]: kernel time sync sta=
tus

> >      > change 2001

> >      > Oct  5 08:19:35 greenville-dom0 ntpd[4020]: synchronized to

> >      > 192.53.103.108 <tel:192.53.103.108>, stratum 1

> >      > Oct  5 10:53:26 greenville-dom0 ntpd[4020]: kernel time sync sta=
tus

> >      > change 6001

> >      > Oct  5 11:27:32 greenville-dom0 ntpd[4020]: kernel time sync sta=
tus

> >      > change 2001

> >      > Oct  5 12:01:41 greenville-dom0 ntpd[4020]: kernel time sync sta=
tus

> >      > change 6001

> >      > Oct  5 12:18:44 greenville-dom0 ntpd[4020]: kernel time sync sta=
tus

> >      > change 2001

> >      > Oct  5 13:09:58 greenville-dom0 ntpd[4020]: kernel time sync sta=
tus

> >      > change 6001

> >      > Oct  5 13:27:04 greenville-dom0 ntpd[4020]: kernel time sync sta=
tus

> >      > change 2001

> >      > Oct  5 15:26:37 greenville-dom0 ntpd[4020]: kernel time sync sta=
tus

> >      > change 6001

> >      > Oct  5 15:43:41 greenville-dom0 ntpd[4020]: kernel time sync sta=
tus

> >      > change 2001

> >      > Oct  5 17:43:11 greenville-dom0 ntpd[4020]: kernel time sync sta=
tus

> >      > change 6001

> >      > Oct  5 19:08:31 greenville-dom0 ntpd[4020]: synchronized to

> >      > 192.53.103.104 <tel:192.53.103.104>, stratum 1

> >      > Oct  5 19:08:31 greenville-dom0 ntpd[4020]: kernel time sync sta=
tus

> >      > change 2001

> >      > Oct  5 21:23:58 greenville-dom0 ntpd[4020]: no servers reachable

> >      > Oct  5 21:40:58 greenville-dom0 ntpd[4020]: synchronized to

> >      > 192.53.103.104 <tel:192.53.103.104>, stratum 1

> >      > Oct  5 21:40:58 greenville-dom0 ntpd[4020]: time correction of -=
3000

> >      > seconds exceeds sanity limit (1000); set clock manually to the

> >     correct

> >      > UTC time.

> >      >

> >      > I had the problem twice on different machines but everytime I sa=
w the

> >      > line "no servers reachable". Could ntpd and/or linux kernel make=
 some

> >      > stupid stuff when ntp upstream servers are unreachable?

> >      >

> >      > Regards Andreas

> >      >

> >      >

> >      > _______________________________________________

> >      > Xen-devel mailing list

> >      > Xen-devel@lists.xensource.com<mailto:Xen-devel@lists.xensource.c=
om> <mailto:Xen-<mailto:Xen-devel@lists.xensource.com>

> devel@lists.xensource.com<mailto:Xen-devel@lists.xensource.com>>

> >      > http://lists.xensource.com/xen-devel____

> >

> >     __ __

> >

> >

--_000_FF93AF260AC2BB499A119CC65B092CF7312080CCsg000713corproo_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859-=
1">
<meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";
	mso-fareast-language:EN-US;}
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;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
	{mso-style-priority:99;
	mso-style-link:"Plain Text Char";
	margin:0cm;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";
	mso-fareast-language:EN-US;}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
	{mso-style-priority:99;
	mso-style-link:"Balloon Text Char";
	margin:0cm;
	margin-bottom:.0001pt;
	font-size:8.0pt;
	font-family:"Tahoma","sans-serif";
	mso-fareast-language:EN-US;}
span.PlainTextChar
	{mso-style-name:"Plain Text Char";
	mso-style-priority:99;
	mso-style-link:"Plain Text";
	font-family:"Calibri","sans-serif";}
span.BalloonTextChar
	{mso-style-name:"Balloon Text Char";
	mso-style-priority:99;
	mso-style-link:"Balloon Text";
	font-family:"Tahoma","sans-serif";}
.MsoChpDefault
	{mso-style-type:export-only;
	font-family:"Calibri","sans-serif";
	mso-fareast-language:EN-US;}
@page WordSection1
	{size:612.0pt 792.0pt;
	margin:70.85pt 129.75pt 70.85pt 129.7pt;}
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"FR-CH" link=3D"blue" vlink=3D"purple">
<div class=3D"WordSection1">
<p class=3D"MsoPlainText">Hi<o:p></o:p></p>
<p class=3D"MsoPlainText"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoPlainText"><span lang=3D"EN-US">by me it's the same case : I=
 have 2 productive machine type, the one with the AMD 6174<o:p></o:p></span=
></p>
<p class=3D"MsoPlainText"><span lang=3D"EN-US">make problem 1 time per mont=
h, the one with the AMD 2384 didn't make any problem since 2 years<o:p></o:=
p></span></p>
<p class=3D"MsoPlainText"><span lang=3D"EN-US">and different XEN / kernel v=
ersion.<o:p></o:p></span></p>
<p class=3D"MsoPlainText"><span lang=3D"EN-US"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoPlainText"><span lang=3D"EN-US">Philippe<o:p></o:p></span></=
p>
<p class=3D"MsoPlainText"><span lang=3D"EN-US"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoPlainText"><span lang=3D"EN-US">processor&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp; : 23<o:p></o:p></span></p>
<p class=3D"MsoPlainText"><span lang=3D"EN-US">vendor_id&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp; : AuthenticAMD<o:p></o:p></span></p>
<p class=3D"MsoPlainText"><span lang=3D"EN-US">cpu family&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp; : 16<o:p></o:p></span></p>
<p class=3D"MsoPlainText"><span lang=3D"EN-US">model&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : 9<o:p></o:p></span></p>
<p class=3D"MsoPlainText"><span lang=3D"EN-US">model name&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp; : AMD Opteron(tm) Processor 6174<o:p></o:p></span></p>
<p class=3D"MsoPlainText"><span lang=3D"EN-US">stepping&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp; : 1<o:p></o:p></span></p>
<p class=3D"MsoPlainText"><b><span lang=3D"EN-US" style=3D"color:red">cpu M=
Hz&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : 1296464.014<o:p></o:p>=
</span></b></p>
<p class=3D"MsoPlainText"><span lang=3D"EN-US">cache size&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp; : 512 KB<o:p></o:p></span></p>
<p class=3D"MsoPlainText"><span lang=3D"EN-US">fpu&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : yes<o:p></o:p></span></p>
<p class=3D"MsoPlainText"><span lang=3D"EN-US">fpu_exception&nbsp;&nbsp; : =
yes<o:p></o:p></span></p>
<p class=3D"MsoPlainText"><span lang=3D"EN-US">cpuid level&nbsp;&nbsp;&nbsp=
;&nbsp; : 5<o:p></o:p></span></p>
<p class=3D"MsoPlainText"><span lang=3D"EN-US">wp&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : yes<o:p></o:p></span=
></p>
<p class=3D"MsoPlainText"><span lang=3D"EN-US">flags&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : fpu de tsc msr pae mce cx8 apic mtr=
r mca cmov pat clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt lm 3=
dnowext 3dnow
<b><span style=3D"color:red">constant_tsc</span></b><span style=3D"color:re=
d"> </span>
rep_good <b><span style=3D"color:red">nonstop_tsc</span></b><span style=3D"=
color:red">
</span>extd_apicid amd_dcm pni cx16 popcnt hypervisor lahf_lm cmp_legacy ex=
tapic cr8_legacy abm sse4a misalignsse 3dnowprefetch nodeid_msr<o:p></o:p><=
/span></p>
<p class=3D"MsoPlainText"><span lang=3D"EN-US">bogomips&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp; : 4400.22<o:p></o:p></span></p>
<p class=3D"MsoPlainText"><span lang=3D"EN-US">TLB size&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp; : 1024 4K pages<o:p></o:p></span></p>
<p class=3D"MsoPlainText"><span lang=3D"EN-US">clflush size&nbsp;&nbsp;&nbs=
p; : 64<o:p></o:p></span></p>
<p class=3D"MsoPlainText"><span lang=3D"EN-US">cache_alignment : 64<o:p></o=
:p></span></p>
<p class=3D"MsoPlainText"><span lang=3D"EN-US">address sizes&nbsp;&nbsp; : =
48 bits physical, 48 bits virtual<o:p></o:p></span></p>
<p class=3D"MsoPlainText"><span lang=3D"EN-US">power management: ts ttp tm =
stc 100mhzsteps hwpstate<o:p></o:p></span></p>
<p class=3D"MsoPlainText"><span lang=3D"EN-US"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoPlainText"><span lang=3D"EN-US"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoPlainText"><span lang=3D"EN-US">processor&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp; : 7<o:p></o:p></span></p>
<p class=3D"MsoPlainText"><span lang=3D"EN-US">vendor_id&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp; : AuthenticAMD<o:p></o:p></span></p>
<p class=3D"MsoPlainText"><span lang=3D"EN-US">cpu family&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp; : 16<o:p></o:p></span></p>
<p class=3D"MsoPlainText"><span lang=3D"EN-US">model&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : 4<o:p></o:p></span></p>
<p class=3D"MsoPlainText"><span lang=3D"EN-US">model name&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp; : Quad-Core AMD Opteron(tm) Processor 2384<o:p></o:p></span></=
p>
<p class=3D"MsoPlainText"><span lang=3D"EN-US">stepping&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp; : 2<o:p></o:p></span></p>
<p class=3D"MsoPlainText"><span lang=3D"EN-US">cpu MHz&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp; : 2826450.137<o:p></o:p></span></p>
<p class=3D"MsoPlainText"><span lang=3D"EN-US">cache size&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp; : 512 KB<o:p></o:p></span></p>
<p class=3D"MsoPlainText"><span lang=3D"EN-US">fpu&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : yes<o:p></o:p></span></p>
<p class=3D"MsoPlainText"><span lang=3D"EN-US">fpu_exception&nbsp;&nbsp; : =
yes<o:p></o:p></span></p>
<p class=3D"MsoPlainText"><span lang=3D"EN-US">cpuid level&nbsp;&nbsp;&nbsp=
;&nbsp; : 5<o:p></o:p></span></p>
<p class=3D"MsoPlainText"><span lang=3D"EN-US">wp&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : yes<o:p></o:p></span=
></p>
<p class=3D"MsoPlainText"><span lang=3D"EN-US">flags&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : fpu de tsc msr pae mce cx8 apic mtr=
r mca cmov pat clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt lm 3=
dnowext 3dnow
<b><span style=3D"color:red">constant_tsc</span></b><span style=3D"color:re=
d"> </span>
rep_good <b><span style=3D"color:red">nonstop_tsc</span></b><span style=3D"=
color:red">
</span>extd_apicid pni cx16 popcnt hypervisor lahf_lm cmp_legacy extapic cr=
8_legacy abm sse4a misalignsse 3dnowprefetch<o:p></o:p></span></p>
<p class=3D"MsoPlainText"><span lang=3D"EN-US">bogomips&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp; : 5400.33<o:p></o:p></span></p>
<p class=3D"MsoPlainText"><span lang=3D"EN-US">TLB size&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp; : 1024 4K pages<o:p></o:p></span></p>
<p class=3D"MsoPlainText"><span lang=3D"EN-US">clflush size&nbsp;&nbsp;&nbs=
p; : 64<o:p></o:p></span></p>
<p class=3D"MsoPlainText"><span lang=3D"EN-US">cache_alignment : 64<o:p></o=
:p></span></p>
<p class=3D"MsoPlainText"><span lang=3D"EN-US">address sizes&nbsp;&nbsp; : =
48 bits physical, 48 bits virtual<o:p></o:p></span></p>
<p class=3D"MsoPlainText"><span lang=3D"EN-US">power management: ts ttp tm =
stc 100mhzsteps hwpstate<o:p></o:p></span></p>
<p class=3D"MsoPlainText"><span lang=3D"EN-US"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoPlainText"><span lang=3D"EN-US"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoPlainText">&gt; <span lang=3D"EN-US" style=3D"mso-fareast-la=
nguage:FR-CH">-----Original Message-----</span></p>
<p class=3D"MsoPlainText">&gt; <span lang=3D"EN-US" style=3D"mso-fareast-la=
nguage:FR-CH">From: Andreas Kinzler [mailto:ml-xen-devel@hfp.de]</span></p>
<p class=3D"MsoPlainText">&gt; <span lang=3D"EN-US" style=3D"mso-fareast-la=
nguage:FR-CH">Sent: Friday, December 02, 2011 8:53 PM</span></p>
<p class=3D"MsoPlainText">&gt; <span lang=3D"EN-US" style=3D"mso-fareast-la=
nguage:FR-CH">To: xen-devel@lists.xensource.com</span></p>
<p class=3D"MsoPlainText">&gt; <span lang=3D"EN-US" style=3D"mso-fareast-la=
nguage:FR-CH">Cc: Simonet Philippe, ITS-SDL-EIS-CNV-DLE-TLC; tp@turtle-ente=
rtainment.de;</span></p>
<p class=3D"MsoPlainText">&gt; <span lang=3D"EN-US" style=3D"mso-fareast-la=
nguage:FR-CH">Olivier Hanesse</span></p>
<p class=3D"MsoPlainText">&gt; <span lang=3D"EN-US" style=3D"mso-fareast-la=
nguage:FR-CH">Subject: Re: [Xen-devel] Possible hint for &quot;Clocksource =
tsc unstable&quot; problem</span></p>
<p class=3D"MsoPlainText">&gt; </p>
<p class=3D"MsoPlainText">&gt; On 01.12.2011 08:49, Olivier Hanesse wrote:<=
/p>
<p class=3D"MsoPlainText">&gt; &gt; good news !</p>
<p class=3D"MsoPlainText">&gt; &gt; Is your &quot;test system&quot; the sam=
e hardware as before ?</p>
<p class=3D"MsoPlainText">&gt; &gt; For example, I don't have time issue wi=
th processor having the</p>
<p class=3D"MsoPlainText">&gt; &gt; 'nonstop_tsc' flag.</p>
<p class=3D"MsoPlainText">&gt; &gt; I got only time issue on older processo=
r (Xeon L5420 for example)</p>
<p class=3D"MsoPlainText">&gt; </p>
<p class=3D"MsoPlainText">&gt; Sorry, but my report was on a machine with X=
eon E5620 (has nonstop_tsc).</p>
<p class=3D"MsoPlainText">&gt; I did some tests to reproduce the behavior b=
y blocking NTP traffic via iptables</p>
<p class=3D"MsoPlainText">&gt; but the problem did not reproduce in a lab s=
etting.</p>
<p class=3D"MsoPlainText">&gt; </p>
<p class=3D"MsoPlainText">&gt; Regards Andreas</p>
<p class=3D"MsoPlainText">&gt; </p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; *From:*Olivier =
Hanesse [mailto:olivier.hanesse@gmail.com</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; &lt;<a href=3D"=
mailto:olivier.hanesse@gmail.com"><span style=3D"color:windowtext;text-deco=
ration:none">mailto:olivier.hanesse@gmail.com</span></a>&gt;]</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; *Sent:* Wednesd=
ay, October 19, 2011 2:48 PM</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; *To:* Thomas P=
=F6hler</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; *Cc:* Simonet P=
hilippe, ITS-SDL-EIS-CNV-DLE-TLC; <a href=3D"mailto:ml-xen-devel@hfp.de">
<span style=3D"color:windowtext;text-decoration:none">ml-xen-devel@hfp.de</=
span></a></p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; &lt;<a href=3D"=
mailto:ml-xen-devel@hfp.de"><span style=3D"color:windowtext;text-decoration=
:none">mailto:ml-xen-devel@hfp.de</span></a>&gt;</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; *Subject:* Re: =
[Xen-devel] Possible hint for &quot;Clocksource tsc</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; unstable&quot; =
problem____</p>
<p class=3D"MsoPlainText">&gt; &gt;</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; __ __</p>
<p class=3D"MsoPlainText">&gt; &gt;</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; Hi,____</p>
<p class=3D"MsoPlainText">&gt; &gt;</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; __ __</p>
<p class=3D"MsoPlainText">&gt; &gt;</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; Same here.____<=
/p>
<p class=3D"MsoPlainText">&gt; &gt;</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; I am using ntpd=
 in dom0 too (lenny version so 4.2.4)____</p>
<p class=3D"MsoPlainText">&gt; &gt;</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; __ __</p>
<p class=3D"MsoPlainText">&gt; &gt;</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; Regards____</p>
<p class=3D"MsoPlainText">&gt; &gt;</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; __ __</p>
<p class=3D"MsoPlainText">&gt; &gt;</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; Olivier____</p>
<p class=3D"MsoPlainText">&gt; &gt;</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; __ __</p>
<p class=3D"MsoPlainText">&gt; &gt;</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; 2011/10/19 Thom=
as P=F6hler &lt;tp@turtle-entertainment.de</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; &lt;<a href=3D"=
mailto:tp@turtle-entertainment.de"><span style=3D"color:windowtext;text-dec=
oration:none">mailto:tp@turtle-entertainment.de</span></a>&gt;&gt;____</p>
<p class=3D"MsoPlainText">&gt; &gt;</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; Hi Philippe,</p=
>
<p class=3D"MsoPlainText">&gt; &gt;</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; we are using nt=
pd in Dom0 too. (also ntpd - NTP daemon program -</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; Ver. 4.2.6p2).<=
/p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; We are monitori=
ng ntp over a nagios plugin, check_ntp</p>
<p class=3D"MsoPlainText">&gt; &gt;</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; Regards</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; Thomas</p>
<p class=3D"MsoPlainText">&gt; &gt;</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; -----Urspr=FCng=
liche Nachricht-----</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; Von: <a href=3D=
"mailto:Philippe.Simonet@swisscom.com">
<span style=3D"color:windowtext;text-decoration:none">Philippe.Simonet@swis=
scom.com</span></a></p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; &lt;<a href=3D"=
mailto:Philippe.Simonet@swisscom.com"><span style=3D"color:windowtext;text-=
decoration:none">mailto:Philippe.Simonet@swisscom.com</span></a>&gt;</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; [mailto:Philipp=
e.Simonet@swisscom.com</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; &lt;<a href=3D"=
mailto:Philippe.Simonet@swisscom.com"><span style=3D"color:windowtext;text-=
decoration:none">mailto:Philippe.Simonet@swisscom.com</span></a>&gt;]</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; Gesendet: Mittw=
och, 19. Oktober 2011 14:40</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; An: <a href=3D"=
mailto:olivier.hanesse@gmail.com"><span style=3D"color:windowtext;text-deco=
ration:none">olivier.hanesse@gmail.com</span></a> &lt;<a href=3D"mailto:oli=
vier.hanesse@gmail.com"><span style=3D"color:windowtext;text-decoration:non=
e">mailto:olivier.hanesse@gmail.com</span></a>&gt;;</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; Thomas P=F6hler=
</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; Cc: <a href=3D"=
mailto:ml-xen-devel@hfp.de"><span style=3D"color:windowtext;text-decoration=
:none">ml-xen-devel@hfp.de</span></a> &lt;<a href=3D"mailto:ml-xen-devel@hf=
p.de"><span style=3D"color:windowtext;text-decoration:none">mailto:ml-xen-d=
evel@hfp.de</span></a>&gt;</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; Betreff: RE: [X=
en-devel] Possible hint for &quot;Clocksource tsc</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; unstable&quot; =
problem____</p>
<p class=3D"MsoPlainText">&gt; &gt;</p>
<p class=3D"MsoPlainText">&gt; &gt;</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; Hi Olivier and =
Thomas</p>
<p class=3D"MsoPlainText">&gt; &gt;</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; andreas ist usi=
ng ntpd in DOM0, myself too (ntpd - NTP daemon</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; program - Ver. =
4.2.6p2)</p>
<p class=3D"MsoPlainText">&gt; &gt;</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; and you ?</p>
<p class=3D"MsoPlainText">&gt; &gt;</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; @andreas : how =
do you turn on your ntp logging ?</p>
<p class=3D"MsoPlainText">&gt; &gt;</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; Philippe</p>
<p class=3D"MsoPlainText">&gt; &gt;</p>
<p class=3D"MsoPlainText">&gt; &gt;</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; ----=
-Original Message-----</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; From=
: <a href=3D"mailto:xen-devel-bounces@lists.xensource.com">
<span style=3D"color:windowtext;text-decoration:none">xen-devel-bounces@lis=
ts.xensource.com</span></a></p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; &lt;<a href=3D"=
mailto:xen-devel-bounces@lists.xensource.com"><span style=3D"color:windowte=
xt;text-decoration:none">mailto:xen-devel-bounces@lists.xensource.com</span=
></a>&gt; [mailto:xen-devel-</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; &lt;<a href=3D"=
mailto:xen-devel-"><span style=3D"color:windowtext;text-decoration:none">ma=
ilto:xen-devel-</span></a>&gt;</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; <a h=
ref=3D"mailto:bounces@lists.xensource.com"><span style=3D"color:windowtext;=
text-decoration:none">bounces@lists.xensource.com</span></a></p>
<p class=3D"MsoPlainText">&gt; &lt;<a href=3D"mailto:bounces@lists.xensourc=
e.com"><span style=3D"color:windowtext;text-decoration:none">mailto:bounces=
@lists.xensource.com</span></a>&gt;]</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; On Behalf Of An=
dreas Kinzler</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; Sent=
: Tuesday, October 18, 2011 5:01 PM</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; To: =
<a href=3D"mailto:xen-devel@lists.xensource.com">
<span style=3D"color:windowtext;text-decoration:none">xen-devel@lists.xenso=
urce.com</span></a></p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; &lt;<a href=3D"=
mailto:xen-devel@lists.xensource.com"><span style=3D"color:windowtext;text-=
decoration:none">mailto:xen-devel@lists.xensource.com</span></a>&gt;</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; Subj=
ect: [Xen-devel] Possible hint for &quot;Clocksource tsc unstable&quot;</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; problem</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt;</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; Hell=
o,</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt;</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; I ma=
de an interesting observation related to the &quot;Clocksource tsc</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; unst=
able (delta =3D -2999660320319 ns)&quot; problem. In the log of ntpd</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; I found:</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt;</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; Oct&=
nbsp; 5 03:46:35 greenville-dom0 ntpd[4020]: kernel time sync status</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; chan=
ge 6001</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; Oct&=
nbsp; 5 04:03:41 greenville-dom0 ntpd[4020]: kernel time sync status</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; chan=
ge 2001</p>
<p class=3D"MsoPlainText">&gt; &gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&gt; Oct&=
nbsp; 5 05:29:03 greenville-dom0 ntpd[4020]: kernel time sync status</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; chan=
ge 6001</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; Oct&=
nbsp; 5 05:46:09 greenville-dom0 ntpd[4020]: kernel time sync status</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; chan=
ge 2001</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; Oct&=
nbsp; 5 06:54:30 greenville-dom0 ntpd[4020]: synchronized to</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; 192.=
53.103.104 &lt;<a href=3D"tel:192.53.103.104"><span style=3D"color:windowte=
xt;text-decoration:none">tel:192.53.103.104</span></a>&gt;, stratum 1</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; Oct&=
nbsp; 5 06:54:30 greenville-dom0 ntpd[4020]: kernel time sync status</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; chan=
ge 6001</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; Oct&=
nbsp; 5 07:28:22 greenville-dom0 ntpd[4020]: kernel time sync status</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; chan=
ge 2001</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; Oct&=
nbsp; 5 08:19:35 greenville-dom0 ntpd[4020]: synchronized to</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; 192.=
53.103.108 &lt;<a href=3D"tel:192.53.103.108"><span style=3D"color:windowte=
xt;text-decoration:none">tel:192.53.103.108</span></a>&gt;, stratum 1</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; Oct&=
nbsp; 5 10:53:26 greenville-dom0 ntpd[4020]: kernel time sync status</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; chan=
ge 6001</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; Oct&=
nbsp; 5 11:27:32 greenville-dom0 ntpd[4020]: kernel time sync status</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; chan=
ge 2001</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; Oct&=
nbsp; 5 12:01:41 greenville-dom0 ntpd[4020]: kernel time sync status</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; chan=
ge 6001</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; Oct&=
nbsp; 5 12:18:44 greenville-dom0 ntpd[4020]: kernel time sync status</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; chan=
ge 2001</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; Oct&=
nbsp; 5 13:09:58 greenville-dom0 ntpd[4020]: kernel time sync status</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; chan=
ge 6001</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; Oct&=
nbsp; 5 13:27:04 greenville-dom0 ntpd[4020]: kernel time sync status</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; chan=
ge 2001</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; Oct&=
nbsp; 5 15:26:37 greenville-dom0 ntpd[4020]: kernel time sync status</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; chan=
ge 6001</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; Oct&=
nbsp; 5 15:43:41 greenville-dom0 ntpd[4020]: kernel time sync status</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; chan=
ge 2001</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; Oct&=
nbsp; 5 17:43:11 greenville-dom0 ntpd[4020]: kernel time sync status</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; chan=
ge 6001</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; Oct&=
nbsp; 5 19:08:31 greenville-dom0 ntpd[4020]: synchronized to</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; 192.=
53.103.104 &lt;<a href=3D"tel:192.53.103.104"><span style=3D"color:windowte=
xt;text-decoration:none">tel:192.53.103.104</span></a>&gt;, stratum 1</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; Oct&=
nbsp; 5 19:08:31 greenville-dom0 ntpd[4020]: kernel time sync status</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; chan=
ge 2001</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; Oct&=
nbsp; 5 21:23:58 greenville-dom0 ntpd[4020]: no servers reachable</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; Oct&=
nbsp; 5 21:40:58 greenville-dom0 ntpd[4020]: synchronized to</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; 192.=
53.103.104 &lt;<a href=3D"tel:192.53.103.104"><span style=3D"color:windowte=
xt;text-decoration:none">tel:192.53.103.104</span></a>&gt;, stratum 1</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; Oct&=
nbsp; 5 21:40:58 greenville-dom0 ntpd[4020]: time correction of -3000</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; seco=
nds exceeds sanity limit (1000); set clock manually to the</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; correct</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; UTC =
time.</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt;</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; I ha=
d the problem twice on different machines but everytime I saw the</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; line=
 &quot;no servers reachable&quot;. Could ntpd and/or linux kernel make some=
</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; stup=
id stuff when ntp upstream servers are unreachable?</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt;</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; Rega=
rds Andreas</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt;</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt;</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; ____=
___________________________________________</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; Xen-=
devel mailing list</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; <a h=
ref=3D"mailto:Xen-devel@lists.xensource.com">
<span style=3D"color:windowtext;text-decoration:none">Xen-devel@lists.xenso=
urce.com</span></a> &lt;<a href=3D"mailto:Xen-devel@lists.xensource.com"><s=
pan style=3D"color:windowtext;text-decoration:none">mailto:Xen-</span></a><=
/p>
<p class=3D"MsoPlainText"><a href=3D"mailto:Xen-devel@lists.xensource.com">=
<span style=3D"color:windowtext;text-decoration:none">&gt; devel@lists.xens=
ource.com</span></a>&gt;</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; <a h=
ref=3D"http://lists.xensource.com/xen-devel____">
<span style=3D"color:windowtext;text-decoration:none">http://lists.xensourc=
e.com/xen-devel____</span></a></p>
<p class=3D"MsoPlainText">&gt; &gt;</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; __ __</p>
<p class=3D"MsoPlainText">&gt; &gt;</p>
<p class=3D"MsoPlainText">&gt; &gt;</p>
</div>
</body>
</html>

--_000_FF93AF260AC2BB499A119CC65B092CF7312080CCsg000713corproo_--


--===============6945283992981499603==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============6945283992981499603==--


From xen-devel-bounces@lists.xensource.com Wed Dec 07 07:14:56 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 07:14:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYBht-0000Ou-Iy; Wed, 07 Dec 2011 07:14:21 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Philippe.Simonet@swisscom.com>) id 1RYBhr-0000Oc-Ua
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 07:14:20 +0000
X-Env-Sender: Philippe.Simonet@swisscom.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1323242012!6480647!1
X-Originating-IP: [193.222.81.100]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkzLjIyMi44MS4xMDAgPT4gOTE4MzE=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28777 invoked from network); 7 Dec 2011 07:13:33 -0000
Received: from outmail100.swisscom.com (HELO mail.swisscom.com)
	(193.222.81.100)
	by server-9.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 7 Dec 2011 07:13:33 -0000
Received: by mail.swisscom.com; Wed, 7 Dec 2011 08:13:29 +0100
From: <Philippe.Simonet@swisscom.com>
To: <ml-xen-devel@hfp.de>, <xen-devel@lists.xensource.com>
Thread-Topic: [Xen-devel] Possible hint for "Clocksource tsc unstable" problem
Thread-Index: AQHMjad9lpfoNCzfJ0ekOlQTVsk4NpWDnHGAgAABUqD//9/2gIBDXsTA///zCQCAAlx1AIAHFykg
Date: Wed, 7 Dec 2011 07:13:27 +0000
Message-ID: <FF93AF260AC2BB499A119CC65B092CF7312080CC@sg000713.corproot.net>
References: <4E9D94A0.10102@hfp.de>
	<FF93AF260AC2BB499A119CC65B092CF7311817E2@sg000713.corproot.net>
	<F1CD4AC5B4A5024AAB60E28A82A8450A046CE5EE@winexch1.office.turtle-entertainment.de>
	<CABx4GKqodU4FLmX3adiCi3U-eKe5cDMVtNV2ZhzFAMsKL_1uTg@mail.gmail.com>
	<FF93AF260AC2BB499A119CC65B092CF7311EE626@sg000713.corproot.net>
	<CABx4GKo7CBCW6cn49Kr2O+NTm78ms7Xnh_ub1EZ7pdt+Cmp=Lg@mail.gmail.com>
	<4ED92CAA.2040008@hfp.de>
In-Reply-To: <4ED92CAA.2040008@hfp.de>
Accept-Language: en-US, de-CH
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.65.122.32]
MIME-Version: 1.0
Cc: tp@turtle-entertainment.de, olivier.hanesse@gmail.com
Subject: Re: [Xen-devel] Possible hint for "Clocksource tsc unstable" problem
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6945283992981499603=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============6945283992981499603==
Content-Language: en-US
Content-Type: multipart/alternative;
	boundary="_000_FF93AF260AC2BB499A119CC65B092CF7312080CCsg000713corproo_"

--_000_FF93AF260AC2BB499A119CC65B092CF7312080CCsg000713corproo_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi



by me it's the same case : I have 2 productive machine type, the one with t=
he AMD 6174

make problem 1 time per month, the one with the AMD 2384 didn't make any pr=
oblem since 2 years

and different XEN / kernel version.



Philippe



processor       : 23

vendor_id       : AuthenticAMD

cpu family      : 16

model           : 9

model name      : AMD Opteron(tm) Processor 6174

stepping        : 1

cpu MHz         : 1296464.014

cache size      : 512 KB

fpu             : yes

fpu_exception   : yes

cpuid level     : 5

wp              : yes

flags           : fpu de tsc msr pae mce cx8 apic mtrr mca cmov pat clflush=
 mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt lm 3dnowext 3dnow constant=
_tsc rep_good nonstop_tsc extd_apicid amd_dcm pni cx16 popcnt hypervisor la=
hf_lm cmp_legacy extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch nod=
eid_msr

bogomips        : 4400.22

TLB size        : 1024 4K pages

clflush size    : 64

cache_alignment : 64

address sizes   : 48 bits physical, 48 bits virtual

power management: ts ttp tm stc 100mhzsteps hwpstate





processor       : 7

vendor_id       : AuthenticAMD

cpu family      : 16

model           : 4

model name      : Quad-Core AMD Opteron(tm) Processor 2384

stepping        : 2

cpu MHz         : 2826450.137

cache size      : 512 KB

fpu             : yes

fpu_exception   : yes

cpuid level     : 5

wp              : yes

flags           : fpu de tsc msr pae mce cx8 apic mtrr mca cmov pat clflush=
 mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt lm 3dnowext 3dnow constant=
_tsc rep_good nonstop_tsc extd_apicid pni cx16 popcnt hypervisor lahf_lm cm=
p_legacy extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch

bogomips        : 5400.33

TLB size        : 1024 4K pages

clflush size    : 64

cache_alignment : 64

address sizes   : 48 bits physical, 48 bits virtual

power management: ts ttp tm stc 100mhzsteps hwpstate





> -----Original Message-----

> From: Andreas Kinzler [mailto:ml-xen-devel@hfp.de]

> Sent: Friday, December 02, 2011 8:53 PM

> To: xen-devel@lists.xensource.com

> Cc: Simonet Philippe, ITS-SDL-EIS-CNV-DLE-TLC; tp@turtle-entertainment.de=
;

> Olivier Hanesse

> Subject: Re: [Xen-devel] Possible hint for "Clocksource tsc unstable" pro=
blem

>

> On 01.12.2011 08:49, Olivier Hanesse wrote:

> > good news !

> > Is your "test system" the same hardware as before ?

> > For example, I don't have time issue with processor having the

> > 'nonstop_tsc' flag.

> > I got only time issue on older processor (Xeon L5420 for example)

>

> Sorry, but my report was on a machine with Xeon E5620 (has nonstop_tsc).

> I did some tests to reproduce the behavior by blocking NTP traffic via ip=
tables

> but the problem did not reproduce in a lab setting.

>

> Regards Andreas

>

> >     *From:*Olivier Hanesse [mailto:olivier.hanesse@gmail.com

> >     <mailto:olivier.hanesse@gmail.com>]

> >     *Sent:* Wednesday, October 19, 2011 2:48 PM

> >     *To:* Thomas P=F6hler

> >     *Cc:* Simonet Philippe, ITS-SDL-EIS-CNV-DLE-TLC; ml-xen-devel@hfp.d=
e<mailto:ml-xen-devel@hfp.de>

> >     <mailto:ml-xen-devel@hfp.de>

> >     *Subject:* Re: [Xen-devel] Possible hint for "Clocksource tsc

> >     unstable" problem____

> >

> >     __ __

> >

> >     Hi,____

> >

> >     __ __

> >

> >     Same here.____

> >

> >     I am using ntpd in dom0 too (lenny version so 4.2.4)____

> >

> >     __ __

> >

> >     Regards____

> >

> >     __ __

> >

> >     Olivier____

> >

> >     __ __

> >

> >     2011/10/19 Thomas P=F6hler <tp@turtle-entertainment.de

> >     <mailto:tp@turtle-entertainment.de>>____

> >

> >     Hi Philippe,

> >

> >     we are using ntpd in Dom0 too. (also ntpd - NTP daemon program -

> >     Ver. 4.2.6p2).

> >     We are monitoring ntp over a nagios plugin, check_ntp

> >

> >     Regards

> >     Thomas

> >

> >     -----Urspr=FCngliche Nachricht-----

> >     Von: Philippe.Simonet@swisscom.com<mailto:Philippe.Simonet@swisscom=
.com>

> >     <mailto:Philippe.Simonet@swisscom.com>

> >     [mailto:Philippe.Simonet@swisscom.com

> >     <mailto:Philippe.Simonet@swisscom.com>]

> >     Gesendet: Mittwoch, 19. Oktober 2011 14:40

> >     An: olivier.hanesse@gmail.com<mailto:olivier.hanesse@gmail.com> <ma=
ilto:olivier.hanesse@gmail.com>;

> >     Thomas P=F6hler

> >     Cc: ml-xen-devel@hfp.de<mailto:ml-xen-devel@hfp.de> <mailto:ml-xen-=
devel@hfp.de>

> >     Betreff: RE: [Xen-devel] Possible hint for "Clocksource tsc

> >     unstable" problem____

> >

> >

> >     Hi Olivier and Thomas

> >

> >     andreas ist using ntpd in DOM0, myself too (ntpd - NTP daemon

> >     program - Ver. 4.2.6p2)

> >

> >     and you ?

> >

> >     @andreas : how do you turn on your ntp logging ?

> >

> >     Philippe

> >

> >

> >      > -----Original Message-----

> >      > From: xen-devel-bounces@lists.xensource.com<mailto:xen-devel-bou=
nces@lists.xensource.com>

> >     <mailto:xen-devel-bounces@lists.xensource.com> [mailto:xen-devel-

> >     <mailto:xen-devel->

> >      > bounces@lists.xensource.com<mailto:bounces@lists.xensource.com>

> <mailto:bounces@lists.xensource.com>]

> >     On Behalf Of Andreas Kinzler

> >      > Sent: Tuesday, October 18, 2011 5:01 PM

> >      > To: xen-devel@lists.xensource.com<mailto:xen-devel@lists.xensour=
ce.com>

> >     <mailto:xen-devel@lists.xensource.com>

> >      > Subject: [Xen-devel] Possible hint for "Clocksource tsc unstable=
"

> >     problem

> >      >

> >      > Hello,

> >      >

> >      > I made an interesting observation related to the "Clocksource ts=
c

> >      > unstable (delta =3D -2999660320319 ns)" problem. In the log of n=
tpd

> >     I found:

> >      >

> >      > Oct  5 03:46:35 greenville-dom0 ntpd[4020]: kernel time sync sta=
tus

> >      > change 6001

> >      > Oct  5 04:03:41 greenville-dom0 ntpd[4020]: kernel time sync sta=
tus

> >      > change 2001

> >      > Oct  5 05:29:03 greenville-dom0 ntpd[4020]: kernel time sync sta=
tus

> >      > change 6001

> >      > Oct  5 05:46:09 greenville-dom0 ntpd[4020]: kernel time sync sta=
tus

> >      > change 2001

> >      > Oct  5 06:54:30 greenville-dom0 ntpd[4020]: synchronized to

> >      > 192.53.103.104 <tel:192.53.103.104>, stratum 1

> >      > Oct  5 06:54:30 greenville-dom0 ntpd[4020]: kernel time sync sta=
tus

> >      > change 6001

> >      > Oct  5 07:28:22 greenville-dom0 ntpd[4020]: kernel time sync sta=
tus

> >      > change 2001

> >      > Oct  5 08:19:35 greenville-dom0 ntpd[4020]: synchronized to

> >      > 192.53.103.108 <tel:192.53.103.108>, stratum 1

> >      > Oct  5 10:53:26 greenville-dom0 ntpd[4020]: kernel time sync sta=
tus

> >      > change 6001

> >      > Oct  5 11:27:32 greenville-dom0 ntpd[4020]: kernel time sync sta=
tus

> >      > change 2001

> >      > Oct  5 12:01:41 greenville-dom0 ntpd[4020]: kernel time sync sta=
tus

> >      > change 6001

> >      > Oct  5 12:18:44 greenville-dom0 ntpd[4020]: kernel time sync sta=
tus

> >      > change 2001

> >      > Oct  5 13:09:58 greenville-dom0 ntpd[4020]: kernel time sync sta=
tus

> >      > change 6001

> >      > Oct  5 13:27:04 greenville-dom0 ntpd[4020]: kernel time sync sta=
tus

> >      > change 2001

> >      > Oct  5 15:26:37 greenville-dom0 ntpd[4020]: kernel time sync sta=
tus

> >      > change 6001

> >      > Oct  5 15:43:41 greenville-dom0 ntpd[4020]: kernel time sync sta=
tus

> >      > change 2001

> >      > Oct  5 17:43:11 greenville-dom0 ntpd[4020]: kernel time sync sta=
tus

> >      > change 6001

> >      > Oct  5 19:08:31 greenville-dom0 ntpd[4020]: synchronized to

> >      > 192.53.103.104 <tel:192.53.103.104>, stratum 1

> >      > Oct  5 19:08:31 greenville-dom0 ntpd[4020]: kernel time sync sta=
tus

> >      > change 2001

> >      > Oct  5 21:23:58 greenville-dom0 ntpd[4020]: no servers reachable

> >      > Oct  5 21:40:58 greenville-dom0 ntpd[4020]: synchronized to

> >      > 192.53.103.104 <tel:192.53.103.104>, stratum 1

> >      > Oct  5 21:40:58 greenville-dom0 ntpd[4020]: time correction of -=
3000

> >      > seconds exceeds sanity limit (1000); set clock manually to the

> >     correct

> >      > UTC time.

> >      >

> >      > I had the problem twice on different machines but everytime I sa=
w the

> >      > line "no servers reachable". Could ntpd and/or linux kernel make=
 some

> >      > stupid stuff when ntp upstream servers are unreachable?

> >      >

> >      > Regards Andreas

> >      >

> >      >

> >      > _______________________________________________

> >      > Xen-devel mailing list

> >      > Xen-devel@lists.xensource.com<mailto:Xen-devel@lists.xensource.c=
om> <mailto:Xen-<mailto:Xen-devel@lists.xensource.com>

> devel@lists.xensource.com<mailto:Xen-devel@lists.xensource.com>>

> >      > http://lists.xensource.com/xen-devel____

> >

> >     __ __

> >

> >

--_000_FF93AF260AC2BB499A119CC65B092CF7312080CCsg000713corproo_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859-=
1">
<meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";
	mso-fareast-language:EN-US;}
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;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
	{mso-style-priority:99;
	mso-style-link:"Plain Text Char";
	margin:0cm;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";
	mso-fareast-language:EN-US;}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
	{mso-style-priority:99;
	mso-style-link:"Balloon Text Char";
	margin:0cm;
	margin-bottom:.0001pt;
	font-size:8.0pt;
	font-family:"Tahoma","sans-serif";
	mso-fareast-language:EN-US;}
span.PlainTextChar
	{mso-style-name:"Plain Text Char";
	mso-style-priority:99;
	mso-style-link:"Plain Text";
	font-family:"Calibri","sans-serif";}
span.BalloonTextChar
	{mso-style-name:"Balloon Text Char";
	mso-style-priority:99;
	mso-style-link:"Balloon Text";
	font-family:"Tahoma","sans-serif";}
.MsoChpDefault
	{mso-style-type:export-only;
	font-family:"Calibri","sans-serif";
	mso-fareast-language:EN-US;}
@page WordSection1
	{size:612.0pt 792.0pt;
	margin:70.85pt 129.75pt 70.85pt 129.7pt;}
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"FR-CH" link=3D"blue" vlink=3D"purple">
<div class=3D"WordSection1">
<p class=3D"MsoPlainText">Hi<o:p></o:p></p>
<p class=3D"MsoPlainText"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoPlainText"><span lang=3D"EN-US">by me it's the same case : I=
 have 2 productive machine type, the one with the AMD 6174<o:p></o:p></span=
></p>
<p class=3D"MsoPlainText"><span lang=3D"EN-US">make problem 1 time per mont=
h, the one with the AMD 2384 didn't make any problem since 2 years<o:p></o:=
p></span></p>
<p class=3D"MsoPlainText"><span lang=3D"EN-US">and different XEN / kernel v=
ersion.<o:p></o:p></span></p>
<p class=3D"MsoPlainText"><span lang=3D"EN-US"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoPlainText"><span lang=3D"EN-US">Philippe<o:p></o:p></span></=
p>
<p class=3D"MsoPlainText"><span lang=3D"EN-US"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoPlainText"><span lang=3D"EN-US">processor&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp; : 23<o:p></o:p></span></p>
<p class=3D"MsoPlainText"><span lang=3D"EN-US">vendor_id&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp; : AuthenticAMD<o:p></o:p></span></p>
<p class=3D"MsoPlainText"><span lang=3D"EN-US">cpu family&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp; : 16<o:p></o:p></span></p>
<p class=3D"MsoPlainText"><span lang=3D"EN-US">model&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : 9<o:p></o:p></span></p>
<p class=3D"MsoPlainText"><span lang=3D"EN-US">model name&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp; : AMD Opteron(tm) Processor 6174<o:p></o:p></span></p>
<p class=3D"MsoPlainText"><span lang=3D"EN-US">stepping&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp; : 1<o:p></o:p></span></p>
<p class=3D"MsoPlainText"><b><span lang=3D"EN-US" style=3D"color:red">cpu M=
Hz&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : 1296464.014<o:p></o:p>=
</span></b></p>
<p class=3D"MsoPlainText"><span lang=3D"EN-US">cache size&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp; : 512 KB<o:p></o:p></span></p>
<p class=3D"MsoPlainText"><span lang=3D"EN-US">fpu&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : yes<o:p></o:p></span></p>
<p class=3D"MsoPlainText"><span lang=3D"EN-US">fpu_exception&nbsp;&nbsp; : =
yes<o:p></o:p></span></p>
<p class=3D"MsoPlainText"><span lang=3D"EN-US">cpuid level&nbsp;&nbsp;&nbsp=
;&nbsp; : 5<o:p></o:p></span></p>
<p class=3D"MsoPlainText"><span lang=3D"EN-US">wp&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : yes<o:p></o:p></span=
></p>
<p class=3D"MsoPlainText"><span lang=3D"EN-US">flags&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : fpu de tsc msr pae mce cx8 apic mtr=
r mca cmov pat clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt lm 3=
dnowext 3dnow
<b><span style=3D"color:red">constant_tsc</span></b><span style=3D"color:re=
d"> </span>
rep_good <b><span style=3D"color:red">nonstop_tsc</span></b><span style=3D"=
color:red">
</span>extd_apicid amd_dcm pni cx16 popcnt hypervisor lahf_lm cmp_legacy ex=
tapic cr8_legacy abm sse4a misalignsse 3dnowprefetch nodeid_msr<o:p></o:p><=
/span></p>
<p class=3D"MsoPlainText"><span lang=3D"EN-US">bogomips&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp; : 4400.22<o:p></o:p></span></p>
<p class=3D"MsoPlainText"><span lang=3D"EN-US">TLB size&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp; : 1024 4K pages<o:p></o:p></span></p>
<p class=3D"MsoPlainText"><span lang=3D"EN-US">clflush size&nbsp;&nbsp;&nbs=
p; : 64<o:p></o:p></span></p>
<p class=3D"MsoPlainText"><span lang=3D"EN-US">cache_alignment : 64<o:p></o=
:p></span></p>
<p class=3D"MsoPlainText"><span lang=3D"EN-US">address sizes&nbsp;&nbsp; : =
48 bits physical, 48 bits virtual<o:p></o:p></span></p>
<p class=3D"MsoPlainText"><span lang=3D"EN-US">power management: ts ttp tm =
stc 100mhzsteps hwpstate<o:p></o:p></span></p>
<p class=3D"MsoPlainText"><span lang=3D"EN-US"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoPlainText"><span lang=3D"EN-US"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoPlainText"><span lang=3D"EN-US">processor&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp; : 7<o:p></o:p></span></p>
<p class=3D"MsoPlainText"><span lang=3D"EN-US">vendor_id&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp; : AuthenticAMD<o:p></o:p></span></p>
<p class=3D"MsoPlainText"><span lang=3D"EN-US">cpu family&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp; : 16<o:p></o:p></span></p>
<p class=3D"MsoPlainText"><span lang=3D"EN-US">model&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : 4<o:p></o:p></span></p>
<p class=3D"MsoPlainText"><span lang=3D"EN-US">model name&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp; : Quad-Core AMD Opteron(tm) Processor 2384<o:p></o:p></span></=
p>
<p class=3D"MsoPlainText"><span lang=3D"EN-US">stepping&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp; : 2<o:p></o:p></span></p>
<p class=3D"MsoPlainText"><span lang=3D"EN-US">cpu MHz&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp; : 2826450.137<o:p></o:p></span></p>
<p class=3D"MsoPlainText"><span lang=3D"EN-US">cache size&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp; : 512 KB<o:p></o:p></span></p>
<p class=3D"MsoPlainText"><span lang=3D"EN-US">fpu&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : yes<o:p></o:p></span></p>
<p class=3D"MsoPlainText"><span lang=3D"EN-US">fpu_exception&nbsp;&nbsp; : =
yes<o:p></o:p></span></p>
<p class=3D"MsoPlainText"><span lang=3D"EN-US">cpuid level&nbsp;&nbsp;&nbsp=
;&nbsp; : 5<o:p></o:p></span></p>
<p class=3D"MsoPlainText"><span lang=3D"EN-US">wp&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : yes<o:p></o:p></span=
></p>
<p class=3D"MsoPlainText"><span lang=3D"EN-US">flags&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : fpu de tsc msr pae mce cx8 apic mtr=
r mca cmov pat clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt lm 3=
dnowext 3dnow
<b><span style=3D"color:red">constant_tsc</span></b><span style=3D"color:re=
d"> </span>
rep_good <b><span style=3D"color:red">nonstop_tsc</span></b><span style=3D"=
color:red">
</span>extd_apicid pni cx16 popcnt hypervisor lahf_lm cmp_legacy extapic cr=
8_legacy abm sse4a misalignsse 3dnowprefetch<o:p></o:p></span></p>
<p class=3D"MsoPlainText"><span lang=3D"EN-US">bogomips&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp; : 5400.33<o:p></o:p></span></p>
<p class=3D"MsoPlainText"><span lang=3D"EN-US">TLB size&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp; : 1024 4K pages<o:p></o:p></span></p>
<p class=3D"MsoPlainText"><span lang=3D"EN-US">clflush size&nbsp;&nbsp;&nbs=
p; : 64<o:p></o:p></span></p>
<p class=3D"MsoPlainText"><span lang=3D"EN-US">cache_alignment : 64<o:p></o=
:p></span></p>
<p class=3D"MsoPlainText"><span lang=3D"EN-US">address sizes&nbsp;&nbsp; : =
48 bits physical, 48 bits virtual<o:p></o:p></span></p>
<p class=3D"MsoPlainText"><span lang=3D"EN-US">power management: ts ttp tm =
stc 100mhzsteps hwpstate<o:p></o:p></span></p>
<p class=3D"MsoPlainText"><span lang=3D"EN-US"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoPlainText"><span lang=3D"EN-US"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoPlainText">&gt; <span lang=3D"EN-US" style=3D"mso-fareast-la=
nguage:FR-CH">-----Original Message-----</span></p>
<p class=3D"MsoPlainText">&gt; <span lang=3D"EN-US" style=3D"mso-fareast-la=
nguage:FR-CH">From: Andreas Kinzler [mailto:ml-xen-devel@hfp.de]</span></p>
<p class=3D"MsoPlainText">&gt; <span lang=3D"EN-US" style=3D"mso-fareast-la=
nguage:FR-CH">Sent: Friday, December 02, 2011 8:53 PM</span></p>
<p class=3D"MsoPlainText">&gt; <span lang=3D"EN-US" style=3D"mso-fareast-la=
nguage:FR-CH">To: xen-devel@lists.xensource.com</span></p>
<p class=3D"MsoPlainText">&gt; <span lang=3D"EN-US" style=3D"mso-fareast-la=
nguage:FR-CH">Cc: Simonet Philippe, ITS-SDL-EIS-CNV-DLE-TLC; tp@turtle-ente=
rtainment.de;</span></p>
<p class=3D"MsoPlainText">&gt; <span lang=3D"EN-US" style=3D"mso-fareast-la=
nguage:FR-CH">Olivier Hanesse</span></p>
<p class=3D"MsoPlainText">&gt; <span lang=3D"EN-US" style=3D"mso-fareast-la=
nguage:FR-CH">Subject: Re: [Xen-devel] Possible hint for &quot;Clocksource =
tsc unstable&quot; problem</span></p>
<p class=3D"MsoPlainText">&gt; </p>
<p class=3D"MsoPlainText">&gt; On 01.12.2011 08:49, Olivier Hanesse wrote:<=
/p>
<p class=3D"MsoPlainText">&gt; &gt; good news !</p>
<p class=3D"MsoPlainText">&gt; &gt; Is your &quot;test system&quot; the sam=
e hardware as before ?</p>
<p class=3D"MsoPlainText">&gt; &gt; For example, I don't have time issue wi=
th processor having the</p>
<p class=3D"MsoPlainText">&gt; &gt; 'nonstop_tsc' flag.</p>
<p class=3D"MsoPlainText">&gt; &gt; I got only time issue on older processo=
r (Xeon L5420 for example)</p>
<p class=3D"MsoPlainText">&gt; </p>
<p class=3D"MsoPlainText">&gt; Sorry, but my report was on a machine with X=
eon E5620 (has nonstop_tsc).</p>
<p class=3D"MsoPlainText">&gt; I did some tests to reproduce the behavior b=
y blocking NTP traffic via iptables</p>
<p class=3D"MsoPlainText">&gt; but the problem did not reproduce in a lab s=
etting.</p>
<p class=3D"MsoPlainText">&gt; </p>
<p class=3D"MsoPlainText">&gt; Regards Andreas</p>
<p class=3D"MsoPlainText">&gt; </p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; *From:*Olivier =
Hanesse [mailto:olivier.hanesse@gmail.com</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; &lt;<a href=3D"=
mailto:olivier.hanesse@gmail.com"><span style=3D"color:windowtext;text-deco=
ration:none">mailto:olivier.hanesse@gmail.com</span></a>&gt;]</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; *Sent:* Wednesd=
ay, October 19, 2011 2:48 PM</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; *To:* Thomas P=
=F6hler</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; *Cc:* Simonet P=
hilippe, ITS-SDL-EIS-CNV-DLE-TLC; <a href=3D"mailto:ml-xen-devel@hfp.de">
<span style=3D"color:windowtext;text-decoration:none">ml-xen-devel@hfp.de</=
span></a></p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; &lt;<a href=3D"=
mailto:ml-xen-devel@hfp.de"><span style=3D"color:windowtext;text-decoration=
:none">mailto:ml-xen-devel@hfp.de</span></a>&gt;</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; *Subject:* Re: =
[Xen-devel] Possible hint for &quot;Clocksource tsc</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; unstable&quot; =
problem____</p>
<p class=3D"MsoPlainText">&gt; &gt;</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; __ __</p>
<p class=3D"MsoPlainText">&gt; &gt;</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; Hi,____</p>
<p class=3D"MsoPlainText">&gt; &gt;</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; __ __</p>
<p class=3D"MsoPlainText">&gt; &gt;</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; Same here.____<=
/p>
<p class=3D"MsoPlainText">&gt; &gt;</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; I am using ntpd=
 in dom0 too (lenny version so 4.2.4)____</p>
<p class=3D"MsoPlainText">&gt; &gt;</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; __ __</p>
<p class=3D"MsoPlainText">&gt; &gt;</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; Regards____</p>
<p class=3D"MsoPlainText">&gt; &gt;</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; __ __</p>
<p class=3D"MsoPlainText">&gt; &gt;</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; Olivier____</p>
<p class=3D"MsoPlainText">&gt; &gt;</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; __ __</p>
<p class=3D"MsoPlainText">&gt; &gt;</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; 2011/10/19 Thom=
as P=F6hler &lt;tp@turtle-entertainment.de</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; &lt;<a href=3D"=
mailto:tp@turtle-entertainment.de"><span style=3D"color:windowtext;text-dec=
oration:none">mailto:tp@turtle-entertainment.de</span></a>&gt;&gt;____</p>
<p class=3D"MsoPlainText">&gt; &gt;</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; Hi Philippe,</p=
>
<p class=3D"MsoPlainText">&gt; &gt;</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; we are using nt=
pd in Dom0 too. (also ntpd - NTP daemon program -</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; Ver. 4.2.6p2).<=
/p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; We are monitori=
ng ntp over a nagios plugin, check_ntp</p>
<p class=3D"MsoPlainText">&gt; &gt;</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; Regards</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; Thomas</p>
<p class=3D"MsoPlainText">&gt; &gt;</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; -----Urspr=FCng=
liche Nachricht-----</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; Von: <a href=3D=
"mailto:Philippe.Simonet@swisscom.com">
<span style=3D"color:windowtext;text-decoration:none">Philippe.Simonet@swis=
scom.com</span></a></p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; &lt;<a href=3D"=
mailto:Philippe.Simonet@swisscom.com"><span style=3D"color:windowtext;text-=
decoration:none">mailto:Philippe.Simonet@swisscom.com</span></a>&gt;</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; [mailto:Philipp=
e.Simonet@swisscom.com</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; &lt;<a href=3D"=
mailto:Philippe.Simonet@swisscom.com"><span style=3D"color:windowtext;text-=
decoration:none">mailto:Philippe.Simonet@swisscom.com</span></a>&gt;]</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; Gesendet: Mittw=
och, 19. Oktober 2011 14:40</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; An: <a href=3D"=
mailto:olivier.hanesse@gmail.com"><span style=3D"color:windowtext;text-deco=
ration:none">olivier.hanesse@gmail.com</span></a> &lt;<a href=3D"mailto:oli=
vier.hanesse@gmail.com"><span style=3D"color:windowtext;text-decoration:non=
e">mailto:olivier.hanesse@gmail.com</span></a>&gt;;</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; Thomas P=F6hler=
</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; Cc: <a href=3D"=
mailto:ml-xen-devel@hfp.de"><span style=3D"color:windowtext;text-decoration=
:none">ml-xen-devel@hfp.de</span></a> &lt;<a href=3D"mailto:ml-xen-devel@hf=
p.de"><span style=3D"color:windowtext;text-decoration:none">mailto:ml-xen-d=
evel@hfp.de</span></a>&gt;</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; Betreff: RE: [X=
en-devel] Possible hint for &quot;Clocksource tsc</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; unstable&quot; =
problem____</p>
<p class=3D"MsoPlainText">&gt; &gt;</p>
<p class=3D"MsoPlainText">&gt; &gt;</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; Hi Olivier and =
Thomas</p>
<p class=3D"MsoPlainText">&gt; &gt;</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; andreas ist usi=
ng ntpd in DOM0, myself too (ntpd - NTP daemon</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; program - Ver. =
4.2.6p2)</p>
<p class=3D"MsoPlainText">&gt; &gt;</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; and you ?</p>
<p class=3D"MsoPlainText">&gt; &gt;</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; @andreas : how =
do you turn on your ntp logging ?</p>
<p class=3D"MsoPlainText">&gt; &gt;</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; Philippe</p>
<p class=3D"MsoPlainText">&gt; &gt;</p>
<p class=3D"MsoPlainText">&gt; &gt;</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; ----=
-Original Message-----</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; From=
: <a href=3D"mailto:xen-devel-bounces@lists.xensource.com">
<span style=3D"color:windowtext;text-decoration:none">xen-devel-bounces@lis=
ts.xensource.com</span></a></p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; &lt;<a href=3D"=
mailto:xen-devel-bounces@lists.xensource.com"><span style=3D"color:windowte=
xt;text-decoration:none">mailto:xen-devel-bounces@lists.xensource.com</span=
></a>&gt; [mailto:xen-devel-</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; &lt;<a href=3D"=
mailto:xen-devel-"><span style=3D"color:windowtext;text-decoration:none">ma=
ilto:xen-devel-</span></a>&gt;</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; <a h=
ref=3D"mailto:bounces@lists.xensource.com"><span style=3D"color:windowtext;=
text-decoration:none">bounces@lists.xensource.com</span></a></p>
<p class=3D"MsoPlainText">&gt; &lt;<a href=3D"mailto:bounces@lists.xensourc=
e.com"><span style=3D"color:windowtext;text-decoration:none">mailto:bounces=
@lists.xensource.com</span></a>&gt;]</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; On Behalf Of An=
dreas Kinzler</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; Sent=
: Tuesday, October 18, 2011 5:01 PM</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; To: =
<a href=3D"mailto:xen-devel@lists.xensource.com">
<span style=3D"color:windowtext;text-decoration:none">xen-devel@lists.xenso=
urce.com</span></a></p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; &lt;<a href=3D"=
mailto:xen-devel@lists.xensource.com"><span style=3D"color:windowtext;text-=
decoration:none">mailto:xen-devel@lists.xensource.com</span></a>&gt;</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; Subj=
ect: [Xen-devel] Possible hint for &quot;Clocksource tsc unstable&quot;</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; problem</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt;</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; Hell=
o,</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt;</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; I ma=
de an interesting observation related to the &quot;Clocksource tsc</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; unst=
able (delta =3D -2999660320319 ns)&quot; problem. In the log of ntpd</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; I found:</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt;</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; Oct&=
nbsp; 5 03:46:35 greenville-dom0 ntpd[4020]: kernel time sync status</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; chan=
ge 6001</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; Oct&=
nbsp; 5 04:03:41 greenville-dom0 ntpd[4020]: kernel time sync status</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; chan=
ge 2001</p>
<p class=3D"MsoPlainText">&gt; &gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&gt; Oct&=
nbsp; 5 05:29:03 greenville-dom0 ntpd[4020]: kernel time sync status</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; chan=
ge 6001</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; Oct&=
nbsp; 5 05:46:09 greenville-dom0 ntpd[4020]: kernel time sync status</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; chan=
ge 2001</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; Oct&=
nbsp; 5 06:54:30 greenville-dom0 ntpd[4020]: synchronized to</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; 192.=
53.103.104 &lt;<a href=3D"tel:192.53.103.104"><span style=3D"color:windowte=
xt;text-decoration:none">tel:192.53.103.104</span></a>&gt;, stratum 1</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; Oct&=
nbsp; 5 06:54:30 greenville-dom0 ntpd[4020]: kernel time sync status</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; chan=
ge 6001</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; Oct&=
nbsp; 5 07:28:22 greenville-dom0 ntpd[4020]: kernel time sync status</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; chan=
ge 2001</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; Oct&=
nbsp; 5 08:19:35 greenville-dom0 ntpd[4020]: synchronized to</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; 192.=
53.103.108 &lt;<a href=3D"tel:192.53.103.108"><span style=3D"color:windowte=
xt;text-decoration:none">tel:192.53.103.108</span></a>&gt;, stratum 1</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; Oct&=
nbsp; 5 10:53:26 greenville-dom0 ntpd[4020]: kernel time sync status</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; chan=
ge 6001</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; Oct&=
nbsp; 5 11:27:32 greenville-dom0 ntpd[4020]: kernel time sync status</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; chan=
ge 2001</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; Oct&=
nbsp; 5 12:01:41 greenville-dom0 ntpd[4020]: kernel time sync status</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; chan=
ge 6001</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; Oct&=
nbsp; 5 12:18:44 greenville-dom0 ntpd[4020]: kernel time sync status</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; chan=
ge 2001</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; Oct&=
nbsp; 5 13:09:58 greenville-dom0 ntpd[4020]: kernel time sync status</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; chan=
ge 6001</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; Oct&=
nbsp; 5 13:27:04 greenville-dom0 ntpd[4020]: kernel time sync status</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; chan=
ge 2001</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; Oct&=
nbsp; 5 15:26:37 greenville-dom0 ntpd[4020]: kernel time sync status</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; chan=
ge 6001</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; Oct&=
nbsp; 5 15:43:41 greenville-dom0 ntpd[4020]: kernel time sync status</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; chan=
ge 2001</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; Oct&=
nbsp; 5 17:43:11 greenville-dom0 ntpd[4020]: kernel time sync status</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; chan=
ge 6001</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; Oct&=
nbsp; 5 19:08:31 greenville-dom0 ntpd[4020]: synchronized to</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; 192.=
53.103.104 &lt;<a href=3D"tel:192.53.103.104"><span style=3D"color:windowte=
xt;text-decoration:none">tel:192.53.103.104</span></a>&gt;, stratum 1</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; Oct&=
nbsp; 5 19:08:31 greenville-dom0 ntpd[4020]: kernel time sync status</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; chan=
ge 2001</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; Oct&=
nbsp; 5 21:23:58 greenville-dom0 ntpd[4020]: no servers reachable</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; Oct&=
nbsp; 5 21:40:58 greenville-dom0 ntpd[4020]: synchronized to</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; 192.=
53.103.104 &lt;<a href=3D"tel:192.53.103.104"><span style=3D"color:windowte=
xt;text-decoration:none">tel:192.53.103.104</span></a>&gt;, stratum 1</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; Oct&=
nbsp; 5 21:40:58 greenville-dom0 ntpd[4020]: time correction of -3000</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; seco=
nds exceeds sanity limit (1000); set clock manually to the</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; correct</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; UTC =
time.</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt;</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; I ha=
d the problem twice on different machines but everytime I saw the</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; line=
 &quot;no servers reachable&quot;. Could ntpd and/or linux kernel make some=
</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; stup=
id stuff when ntp upstream servers are unreachable?</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt;</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; Rega=
rds Andreas</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt;</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt;</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; ____=
___________________________________________</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; Xen-=
devel mailing list</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; <a h=
ref=3D"mailto:Xen-devel@lists.xensource.com">
<span style=3D"color:windowtext;text-decoration:none">Xen-devel@lists.xenso=
urce.com</span></a> &lt;<a href=3D"mailto:Xen-devel@lists.xensource.com"><s=
pan style=3D"color:windowtext;text-decoration:none">mailto:Xen-</span></a><=
/p>
<p class=3D"MsoPlainText"><a href=3D"mailto:Xen-devel@lists.xensource.com">=
<span style=3D"color:windowtext;text-decoration:none">&gt; devel@lists.xens=
ource.com</span></a>&gt;</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; <a h=
ref=3D"http://lists.xensource.com/xen-devel____">
<span style=3D"color:windowtext;text-decoration:none">http://lists.xensourc=
e.com/xen-devel____</span></a></p>
<p class=3D"MsoPlainText">&gt; &gt;</p>
<p class=3D"MsoPlainText">&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; __ __</p>
<p class=3D"MsoPlainText">&gt; &gt;</p>
<p class=3D"MsoPlainText">&gt; &gt;</p>
</div>
</body>
</html>

--_000_FF93AF260AC2BB499A119CC65B092CF7312080CCsg000713corproo_--


--===============6945283992981499603==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============6945283992981499603==--


From xen-devel-bounces@lists.xensource.com Wed Dec 07 08:39:21 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 08:39:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYD1Z-0001aU-Jl; Wed, 07 Dec 2011 08:38:45 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RYD1X-0001aO-G6
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 08:38:43 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1323247048!55689555!1
X-Originating-IP: [74.125.83.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28755 invoked from network); 7 Dec 2011 08:37:29 -0000
Received: from mail-ee0-f43.google.com (HELO mail-ee0-f43.google.com)
	(74.125.83.43)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Dec 2011 08:37:29 -0000
Received: by eekd49 with SMTP id d49so1302403eek.30
	for <xen-devel@lists.xensource.com>;
	Wed, 07 Dec 2011 00:38:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:message-id:user-agent:date:from:to;
	bh=8lMEPLNOamsf1yw4cFnwKBT4YcW57wNBFEQfnkwFgcY=;
	b=sZx+N4Fkv3u9yZKc6h1rVTUq2FYJuEs7tIEnzkcXxAYUsiA7pgB/NFgBv+ziQoMnuj
	QpMi9XcrHdoP4ulZ+jXLE2ODCAaXlMmY5nBBmsL8ywMWSlhOgT+K6rykUvTyxqJlU9Lx
	zY6qkz1lnvBzzBg3V0qrpceBJbPC73oeoH5J4=
Received: by 10.14.12.136 with SMTP id 8mr3278755eez.240.1323247081336;
	Wed, 07 Dec 2011 00:38:01 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id d6sm3184965eec.10.2011.12.07.00.37.59
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 07 Dec 2011 00:37:59 -0800 (PST)
MIME-Version: 1.0
Message-Id: <patchbomb.1323246920@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Wed, 07 Dec 2011 09:35:20 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 0 of 3 v2] libxl: fix domain destruction with
 libxl hotplug script calling
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

When calling hotplug scripts from libxl we have to make sure the
device is disconnected before attepmting to execute hotplug scripts.

This patch series sets frontend status to 6 when a domain is
destroyed, so the devices are disconnected and then execute hotplug
scripts.

Also the syntax of the libxl_domain_destroy has been changed to always
force the destruction.

This series should be applied after "libxl: add support for hotplug
script calling from libxl".

Changes from v1:

 * Remove foce parameter from libxl__devices_destroy and clean up 
   unnecessary code in function.

Please review, Roger.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 08:39:21 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 08:39:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYD1Z-0001aU-Jl; Wed, 07 Dec 2011 08:38:45 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RYD1X-0001aO-G6
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 08:38:43 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1323247048!55689555!1
X-Originating-IP: [74.125.83.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28755 invoked from network); 7 Dec 2011 08:37:29 -0000
Received: from mail-ee0-f43.google.com (HELO mail-ee0-f43.google.com)
	(74.125.83.43)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Dec 2011 08:37:29 -0000
Received: by eekd49 with SMTP id d49so1302403eek.30
	for <xen-devel@lists.xensource.com>;
	Wed, 07 Dec 2011 00:38:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:message-id:user-agent:date:from:to;
	bh=8lMEPLNOamsf1yw4cFnwKBT4YcW57wNBFEQfnkwFgcY=;
	b=sZx+N4Fkv3u9yZKc6h1rVTUq2FYJuEs7tIEnzkcXxAYUsiA7pgB/NFgBv+ziQoMnuj
	QpMi9XcrHdoP4ulZ+jXLE2ODCAaXlMmY5nBBmsL8ywMWSlhOgT+K6rykUvTyxqJlU9Lx
	zY6qkz1lnvBzzBg3V0qrpceBJbPC73oeoH5J4=
Received: by 10.14.12.136 with SMTP id 8mr3278755eez.240.1323247081336;
	Wed, 07 Dec 2011 00:38:01 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id d6sm3184965eec.10.2011.12.07.00.37.59
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 07 Dec 2011 00:37:59 -0800 (PST)
MIME-Version: 1.0
Message-Id: <patchbomb.1323246920@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Wed, 07 Dec 2011 09:35:20 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 0 of 3 v2] libxl: fix domain destruction with
 libxl hotplug script calling
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

When calling hotplug scripts from libxl we have to make sure the
device is disconnected before attepmting to execute hotplug scripts.

This patch series sets frontend status to 6 when a domain is
destroyed, so the devices are disconnected and then execute hotplug
scripts.

Also the syntax of the libxl_domain_destroy has been changed to always
force the destruction.

This series should be applied after "libxl: add support for hotplug
script calling from libxl".

Changes from v1:

 * Remove foce parameter from libxl__devices_destroy and clean up 
   unnecessary code in function.

Please review, Roger.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 08:39:21 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 08:39:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYD1k-0001bH-Pt; Wed, 07 Dec 2011 08:38:56 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RYD1i-0001ac-IE
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 08:38:54 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1323247087!6456304!1
X-Originating-IP: [209.85.215.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16553 invoked from network); 7 Dec 2011 08:38:07 -0000
Received: from mail-ey0-f171.google.com (HELO mail-ey0-f171.google.com)
	(209.85.215.171)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Dec 2011 08:38:07 -0000
Received: by eaad12 with SMTP id d12so1294750eaa.30
	for <xen-devel@lists.xensource.com>;
	Wed, 07 Dec 2011 00:38:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=zuJlF5Xrp1Tui13jqKWOnxQlEqePjHJUY/VfdcNcFxI=;
	b=VeQjPjkHRJXIHIwuQYWplt+hkJqCIQl2fGK6Uep8sEd7nB2G38cAfdQ0wLXa4CHetX
	K0w9XmoFD/oC8XNmaw9/zJlhg0ivVx4ndNPUtNkLkT6t+aRnH4grAcSDCRoQPuqD3Y6B
	aKxznboO48q/VZXhROzWc6OiJdX3zIqzUnGJ8=
Received: by 10.213.4.15 with SMTP id 15mr253131ebp.142.1323247087521;
	Wed, 07 Dec 2011 00:38:07 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id d6sm3184965eec.10.2011.12.07.00.38.05
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 07 Dec 2011 00:38:06 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 2c0f1676a3667b9070832999818447e51143c110
Message-Id: <2c0f1676a3667b907083.1323246923@loki.upc.es>
In-Reply-To: <patchbomb.1323246920@loki.upc.es>
References: <patchbomb.1323246920@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Wed, 07 Dec 2011 09:35:23 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 3 of 3 v2] libxl: remove force parameter from
 libxl__devices_destroy
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1323081693 -3600
# Node ID 2c0f1676a3667b9070832999818447e51143c110
# Parent  c0d51df66b829995c4eb3902b5b9914c710a6c01
libxl: remove force parameter from libxl__devices_destroy

Remove the force flag, and always use forced destruction.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r c0d51df66b82 -r 2c0f1676a366 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Mon Dec 05 11:06:45 2011 +0100
+++ b/tools/libxl/libxl.c	Mon Dec 05 11:41:33 2011 +0100
@@ -767,7 +767,7 @@ int libxl_domain_destroy(libxl_ctx *ctx,
 
         libxl__qmp_cleanup(&gc, domid);
     }
-    if (libxl__devices_destroy(&gc, domid, 1) < 0)
+    if (libxl__devices_destroy(&gc, domid) < 0)
         LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "libxl__devices_destroy failed for %d", domid);
 
     vm_path = libxl__xs_read(&gc, XBT_NULL, libxl__sprintf(&gc, "%s/vm", dom_path));
diff -r c0d51df66b82 -r 2c0f1676a366 tools/libxl/libxl_device.c
--- a/tools/libxl/libxl_device.c	Mon Dec 05 11:06:45 2011 +0100
+++ b/tools/libxl/libxl_device.c	Mon Dec 05 11:41:33 2011 +0100
@@ -524,13 +524,13 @@ int libxl__device_destroy(libxl__gc *gc,
     return 0;
 }
 
-int libxl__devices_destroy(libxl__gc *gc, uint32_t domid, int force)
+int libxl__devices_destroy(libxl__gc *gc, uint32_t domid)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
     char *path;
     unsigned int num_kinds, num_devs;
     char **kinds = NULL, **devs = NULL;
-    int i, j, n_watches = 0;
+    int i, j;
     libxl__device dev;
     libxl__device_kind kind;
 
@@ -561,16 +561,7 @@ int libxl__devices_destroy(libxl__gc *gc
                 dev.kind = kind;
                 dev.devid = atoi(devs[j]);
 
-                if (force) {
-                    libxl__device_destroy(gc, &dev);
-                } else {
-                    int rc = libxl__device_remove(gc, &dev, 0);
-                    if (rc < 0)
-                        LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
-                                   "cannot remove device %s\n", path);
-                    else
-                        n_watches += rc;
-                }
+                libxl__device_destroy(gc, &dev);
             }
         }
     }
@@ -584,37 +575,9 @@ int libxl__devices_destroy(libxl__gc *gc
         dev.kind = LIBXL__DEVICE_KIND_CONSOLE;
         dev.devid = 0;
 
-        if (force) {
-            libxl__device_destroy(gc, &dev);
-        } else {
-            int rc = libxl__device_remove(gc, &dev, 0);
-            if (rc < 0)
-                LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
-                           "cannot remove device %s\n", path);
-            else
-                n_watches += rc;
-        }
+        libxl__device_destroy(gc, &dev);
     }
 
-    if (!force) {
-        /* Linux-ism. Most implementations leave the timeout
-         * untouched after select. Linux, however, will chip
-         * away the elapsed time from it, which is what we
-         * need to enforce a single time span waiting for
-         * device destruction. */
-        struct timeval tv;
-        tv.tv_sec = LIBXL_DESTROY_TIMEOUT;
-        tv.tv_usec = 0;
-        while (n_watches > 0) {
-            if (libxl__wait_for_device_state(gc, &tv, XenbusStateClosed,
-                                             destroy_device) < 0) {
-                /* function returned ERROR_* */
-                break;
-            } else {
-                n_watches--;
-            }
-        }
-    }
 out:
     return 0;
 }
diff -r c0d51df66b82 -r 2c0f1676a366 tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Mon Dec 05 11:06:45 2011 +0100
+++ b/tools/libxl/libxl_internal.h	Mon Dec 05 11:41:33 2011 +0100
@@ -252,7 +252,7 @@ _hidden int libxl__parse_backend_path(li
                                       libxl__device *dev);
 _hidden int libxl__device_remove(libxl__gc *gc, libxl__device *dev, int wait);
 _hidden int libxl__device_destroy(libxl__gc *gc, libxl__device *dev);
-_hidden int libxl__devices_destroy(libxl__gc *gc, uint32_t domid, int force);
+_hidden int libxl__devices_destroy(libxl__gc *gc, uint32_t domid);
 _hidden int libxl__wait_for_backend(libxl__gc *gc, char *be_path, char *state);
 
 /* Handler for the libxl__wait_for_device_state callback */

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 08:39:21 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 08:39:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYD1k-0001bH-Pt; Wed, 07 Dec 2011 08:38:56 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RYD1i-0001ac-IE
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 08:38:54 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1323247087!6456304!1
X-Originating-IP: [209.85.215.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16553 invoked from network); 7 Dec 2011 08:38:07 -0000
Received: from mail-ey0-f171.google.com (HELO mail-ey0-f171.google.com)
	(209.85.215.171)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Dec 2011 08:38:07 -0000
Received: by eaad12 with SMTP id d12so1294750eaa.30
	for <xen-devel@lists.xensource.com>;
	Wed, 07 Dec 2011 00:38:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=zuJlF5Xrp1Tui13jqKWOnxQlEqePjHJUY/VfdcNcFxI=;
	b=VeQjPjkHRJXIHIwuQYWplt+hkJqCIQl2fGK6Uep8sEd7nB2G38cAfdQ0wLXa4CHetX
	K0w9XmoFD/oC8XNmaw9/zJlhg0ivVx4ndNPUtNkLkT6t+aRnH4grAcSDCRoQPuqD3Y6B
	aKxznboO48q/VZXhROzWc6OiJdX3zIqzUnGJ8=
Received: by 10.213.4.15 with SMTP id 15mr253131ebp.142.1323247087521;
	Wed, 07 Dec 2011 00:38:07 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id d6sm3184965eec.10.2011.12.07.00.38.05
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 07 Dec 2011 00:38:06 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 2c0f1676a3667b9070832999818447e51143c110
Message-Id: <2c0f1676a3667b907083.1323246923@loki.upc.es>
In-Reply-To: <patchbomb.1323246920@loki.upc.es>
References: <patchbomb.1323246920@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Wed, 07 Dec 2011 09:35:23 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 3 of 3 v2] libxl: remove force parameter from
 libxl__devices_destroy
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1323081693 -3600
# Node ID 2c0f1676a3667b9070832999818447e51143c110
# Parent  c0d51df66b829995c4eb3902b5b9914c710a6c01
libxl: remove force parameter from libxl__devices_destroy

Remove the force flag, and always use forced destruction.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r c0d51df66b82 -r 2c0f1676a366 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Mon Dec 05 11:06:45 2011 +0100
+++ b/tools/libxl/libxl.c	Mon Dec 05 11:41:33 2011 +0100
@@ -767,7 +767,7 @@ int libxl_domain_destroy(libxl_ctx *ctx,
 
         libxl__qmp_cleanup(&gc, domid);
     }
-    if (libxl__devices_destroy(&gc, domid, 1) < 0)
+    if (libxl__devices_destroy(&gc, domid) < 0)
         LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "libxl__devices_destroy failed for %d", domid);
 
     vm_path = libxl__xs_read(&gc, XBT_NULL, libxl__sprintf(&gc, "%s/vm", dom_path));
diff -r c0d51df66b82 -r 2c0f1676a366 tools/libxl/libxl_device.c
--- a/tools/libxl/libxl_device.c	Mon Dec 05 11:06:45 2011 +0100
+++ b/tools/libxl/libxl_device.c	Mon Dec 05 11:41:33 2011 +0100
@@ -524,13 +524,13 @@ int libxl__device_destroy(libxl__gc *gc,
     return 0;
 }
 
-int libxl__devices_destroy(libxl__gc *gc, uint32_t domid, int force)
+int libxl__devices_destroy(libxl__gc *gc, uint32_t domid)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
     char *path;
     unsigned int num_kinds, num_devs;
     char **kinds = NULL, **devs = NULL;
-    int i, j, n_watches = 0;
+    int i, j;
     libxl__device dev;
     libxl__device_kind kind;
 
@@ -561,16 +561,7 @@ int libxl__devices_destroy(libxl__gc *gc
                 dev.kind = kind;
                 dev.devid = atoi(devs[j]);
 
-                if (force) {
-                    libxl__device_destroy(gc, &dev);
-                } else {
-                    int rc = libxl__device_remove(gc, &dev, 0);
-                    if (rc < 0)
-                        LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
-                                   "cannot remove device %s\n", path);
-                    else
-                        n_watches += rc;
-                }
+                libxl__device_destroy(gc, &dev);
             }
         }
     }
@@ -584,37 +575,9 @@ int libxl__devices_destroy(libxl__gc *gc
         dev.kind = LIBXL__DEVICE_KIND_CONSOLE;
         dev.devid = 0;
 
-        if (force) {
-            libxl__device_destroy(gc, &dev);
-        } else {
-            int rc = libxl__device_remove(gc, &dev, 0);
-            if (rc < 0)
-                LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
-                           "cannot remove device %s\n", path);
-            else
-                n_watches += rc;
-        }
+        libxl__device_destroy(gc, &dev);
     }
 
-    if (!force) {
-        /* Linux-ism. Most implementations leave the timeout
-         * untouched after select. Linux, however, will chip
-         * away the elapsed time from it, which is what we
-         * need to enforce a single time span waiting for
-         * device destruction. */
-        struct timeval tv;
-        tv.tv_sec = LIBXL_DESTROY_TIMEOUT;
-        tv.tv_usec = 0;
-        while (n_watches > 0) {
-            if (libxl__wait_for_device_state(gc, &tv, XenbusStateClosed,
-                                             destroy_device) < 0) {
-                /* function returned ERROR_* */
-                break;
-            } else {
-                n_watches--;
-            }
-        }
-    }
 out:
     return 0;
 }
diff -r c0d51df66b82 -r 2c0f1676a366 tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Mon Dec 05 11:06:45 2011 +0100
+++ b/tools/libxl/libxl_internal.h	Mon Dec 05 11:41:33 2011 +0100
@@ -252,7 +252,7 @@ _hidden int libxl__parse_backend_path(li
                                       libxl__device *dev);
 _hidden int libxl__device_remove(libxl__gc *gc, libxl__device *dev, int wait);
 _hidden int libxl__device_destroy(libxl__gc *gc, libxl__device *dev);
-_hidden int libxl__devices_destroy(libxl__gc *gc, uint32_t domid, int force);
+_hidden int libxl__devices_destroy(libxl__gc *gc, uint32_t domid);
 _hidden int libxl__wait_for_backend(libxl__gc *gc, char *be_path, char *state);
 
 /* Handler for the libxl__wait_for_device_state callback */

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 08:39:21 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 08:39:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYD1f-0001an-0A; Wed, 07 Dec 2011 08:38:51 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RYD1e-0001aT-5s
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 08:38:50 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1323247048!55689555!2
X-Originating-IP: [74.125.83.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28843 invoked from network); 7 Dec 2011 08:37:30 -0000
Received: from mail-ee0-f43.google.com (HELO mail-ee0-f43.google.com)
	(74.125.83.43)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Dec 2011 08:37:30 -0000
Received: by mail-ee0-f43.google.com with SMTP id d49so1302403eek.30
	for <xen-devel@lists.xensource.com>;
	Wed, 07 Dec 2011 00:38:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=O72rYREckCHH3aYvbom3j0Ct9fXJCK9fI6Dk0YYaREw=;
	b=vXAO6XgpJtUbgZWhN4grGhYByth5k0ZAHMb2IcldhaRYqrqFb1oMUDRhc46JBHdJRJ
	BOmeQKJFANSy8Rq2NthUpB+ffgxjx5zieOJraPwk1/N8JZmPPGtLdRwXZfNhZoqcJiMx
	mukJBUEJwl/F+Wgbz1pU99hXa1wuHYXA9Zbh8=
Received: by 10.14.10.142 with SMTP id 14mr3376471eev.62.1323247083397;
	Wed, 07 Dec 2011 00:38:03 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id d6sm3184965eec.10.2011.12.07.00.38.01
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 07 Dec 2011 00:38:02 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: bc90cfd8dd220d69d09cf94a3d39ff3cef76d021
Message-Id: <bc90cfd8dd220d69d09c.1323246921@loki.upc.es>
In-Reply-To: <patchbomb.1323246920@loki.upc.es>
References: <patchbomb.1323246920@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Wed, 07 Dec 2011 09:35:21 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 1 of 3 v2] libxl: set frontend status to 6 on
	domain destroy
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1323079583 -3600
# Node ID bc90cfd8dd220d69d09cf94a3d39ff3cef76d021
# Parent  274fa4aea2a30fb82228513f969d7cb807813bb8
libxl: set frontend status to 6 on domain destroy

Set frontend status to 6 on domain destruction and wait for devices to
be disconnected before executing hotplug scripts.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 274fa4aea2a3 -r bc90cfd8dd22 tools/libxl/libxl_device.c
--- a/tools/libxl/libxl_device.c	Thu Dec 01 16:01:31 2011 +0100
+++ b/tools/libxl/libxl_device.c	Mon Dec 05 11:06:23 2011 +0100
@@ -513,10 +513,7 @@ int libxl__device_destroy(libxl__gc *gc,
     char *be_path = libxl__device_backend_path(gc, dev);
     char *fe_path = libxl__device_frontend_path(gc, dev);
 
-    /* 
-     * Run hotplug scripts, which will probably not be able to
-     * execute successfully since the device may still be plugged
-     */
+    libxl__xs_write(gc, XBT_NULL, libxl__sprintf(gc, "%s/%s", fe_path, "state"), "6");
     libxl__device_execute_hotplug(gc, dev, DISCONNECT);
 
     xs_rm(ctx->xsh, XBT_NULL, be_path);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 08:39:21 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 08:39:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYD1f-0001an-0A; Wed, 07 Dec 2011 08:38:51 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RYD1e-0001aT-5s
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 08:38:50 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1323247048!55689555!2
X-Originating-IP: [74.125.83.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28843 invoked from network); 7 Dec 2011 08:37:30 -0000
Received: from mail-ee0-f43.google.com (HELO mail-ee0-f43.google.com)
	(74.125.83.43)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Dec 2011 08:37:30 -0000
Received: by mail-ee0-f43.google.com with SMTP id d49so1302403eek.30
	for <xen-devel@lists.xensource.com>;
	Wed, 07 Dec 2011 00:38:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=O72rYREckCHH3aYvbom3j0Ct9fXJCK9fI6Dk0YYaREw=;
	b=vXAO6XgpJtUbgZWhN4grGhYByth5k0ZAHMb2IcldhaRYqrqFb1oMUDRhc46JBHdJRJ
	BOmeQKJFANSy8Rq2NthUpB+ffgxjx5zieOJraPwk1/N8JZmPPGtLdRwXZfNhZoqcJiMx
	mukJBUEJwl/F+Wgbz1pU99hXa1wuHYXA9Zbh8=
Received: by 10.14.10.142 with SMTP id 14mr3376471eev.62.1323247083397;
	Wed, 07 Dec 2011 00:38:03 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id d6sm3184965eec.10.2011.12.07.00.38.01
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 07 Dec 2011 00:38:02 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: bc90cfd8dd220d69d09cf94a3d39ff3cef76d021
Message-Id: <bc90cfd8dd220d69d09c.1323246921@loki.upc.es>
In-Reply-To: <patchbomb.1323246920@loki.upc.es>
References: <patchbomb.1323246920@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Wed, 07 Dec 2011 09:35:21 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 1 of 3 v2] libxl: set frontend status to 6 on
	domain destroy
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1323079583 -3600
# Node ID bc90cfd8dd220d69d09cf94a3d39ff3cef76d021
# Parent  274fa4aea2a30fb82228513f969d7cb807813bb8
libxl: set frontend status to 6 on domain destroy

Set frontend status to 6 on domain destruction and wait for devices to
be disconnected before executing hotplug scripts.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 274fa4aea2a3 -r bc90cfd8dd22 tools/libxl/libxl_device.c
--- a/tools/libxl/libxl_device.c	Thu Dec 01 16:01:31 2011 +0100
+++ b/tools/libxl/libxl_device.c	Mon Dec 05 11:06:23 2011 +0100
@@ -513,10 +513,7 @@ int libxl__device_destroy(libxl__gc *gc,
     char *be_path = libxl__device_backend_path(gc, dev);
     char *fe_path = libxl__device_frontend_path(gc, dev);
 
-    /* 
-     * Run hotplug scripts, which will probably not be able to
-     * execute successfully since the device may still be plugged
-     */
+    libxl__xs_write(gc, XBT_NULL, libxl__sprintf(gc, "%s/%s", fe_path, "state"), "6");
     libxl__device_execute_hotplug(gc, dev, DISCONNECT);
 
     xs_rm(ctx->xsh, XBT_NULL, be_path);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 08:39:23 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 08:39:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYD1g-0001av-DF; Wed, 07 Dec 2011 08:38:52 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RYD1e-0001ab-F6
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 08:38:50 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1323247048!55689555!3
X-Originating-IP: [74.125.83.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28915 invoked from network); 7 Dec 2011 08:37:32 -0000
Received: from mail-ee0-f43.google.com (HELO mail-ee0-f43.google.com)
	(74.125.83.43)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Dec 2011 08:37:32 -0000
Received: by mail-ee0-f43.google.com with SMTP id d49so1302403eek.30
	for <xen-devel@lists.xensource.com>;
	Wed, 07 Dec 2011 00:38:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=gMeQJnu56LB2IdidJsPcuYct/MiVjmBIi1eMbxRt0Fo=;
	b=cpF5UXXuyl3Q4FDKnfFAe0DnzkkTrHy4QuHN1TpM6bRbcBlvspPRQOvV8vXYt/1U3+
	G7zMkpjYfbBHfP83O249VitWUhhKw8R3Mc3TtGTs6GCJQxRexvjn6ZUzAYAF+Wuo6nKM
	y6n5Q2Q08x8RZbNUC+Rz+BP2QcqIwalbqSvMg=
Received: by 10.14.17.144 with SMTP id j16mr3122006eej.182.1323247085446;
	Wed, 07 Dec 2011 00:38:05 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id d6sm3184965eec.10.2011.12.07.00.38.03
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 07 Dec 2011 00:38:04 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: c0d51df66b829995c4eb3902b5b9914c710a6c01
Message-Id: <c0d51df66b829995c4eb.1323246922@loki.upc.es>
In-Reply-To: <patchbomb.1323246920@loki.upc.es>
References: <patchbomb.1323246920@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Wed, 07 Dec 2011 09:35:22 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 2 of 3 v2] libxl: remove force parameter from
 libxl_domain_destroy
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1323079605 -3600
# Node ID c0d51df66b829995c4eb3902b5b9914c710a6c01
# Parent  bc90cfd8dd220d69d09cf94a3d39ff3cef76d021
libxl: remove force parameter from libxl_domain_destroy

Since a destroy is considered a forced shutdown, there's no point in
passing a force parameter. All the occurences of this function have
been replaced with the proper syntax.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r bc90cfd8dd22 -r c0d51df66b82 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Mon Dec 05 11:06:23 2011 +0100
+++ b/tools/libxl/libxl.c	Mon Dec 05 11:06:45 2011 +0100
@@ -718,7 +718,7 @@ int libxl_event_get_disk_eject_info(libx
     return 1;
 }
 
-int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid, int force)
+int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid)
 {
     libxl__gc gc = LIBXL_INIT_GC(ctx);
     libxl_dominfo dominfo;
@@ -767,7 +767,7 @@ int libxl_domain_destroy(libxl_ctx *ctx,
 
         libxl__qmp_cleanup(&gc, domid);
     }
-    if (libxl__devices_destroy(&gc, domid, force) < 0)
+    if (libxl__devices_destroy(&gc, domid, 1) < 0)
         LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "libxl__devices_destroy failed for %d", domid);
 
     vm_path = libxl__xs_read(&gc, XBT_NULL, libxl__sprintf(&gc, "%s/vm", dom_path));
diff -r bc90cfd8dd22 -r c0d51df66b82 tools/libxl/libxl.h
--- a/tools/libxl/libxl.h	Mon Dec 05 11:06:23 2011 +0100
+++ b/tools/libxl/libxl.h	Mon Dec 05 11:06:45 2011 +0100
@@ -269,7 +269,7 @@ int libxl_domain_suspend(libxl_ctx *ctx,
                           uint32_t domid, int fd);
 int libxl_domain_resume(libxl_ctx *ctx, uint32_t domid);
 int libxl_domain_shutdown(libxl_ctx *ctx, uint32_t domid, int req);
-int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid, int force);
+int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid);
 int libxl_domain_preserve(libxl_ctx *ctx, uint32_t domid, libxl_domain_create_info *info, const char *name_suffix, libxl_uuid new_uuid);
 
 /* get max. number of cpus supported by hypervisor */
diff -r bc90cfd8dd22 -r c0d51df66b82 tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Mon Dec 05 11:06:23 2011 +0100
+++ b/tools/libxl/libxl_create.c	Mon Dec 05 11:06:45 2011 +0100
@@ -646,7 +646,7 @@ static int do_domain_create(libxl__gc *g
 
 error_out:
     if (domid)
-        libxl_domain_destroy(ctx, domid, 0);
+        libxl_domain_destroy(ctx, domid);
 
     return ret;
 }
diff -r bc90cfd8dd22 -r c0d51df66b82 tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Mon Dec 05 11:06:23 2011 +0100
+++ b/tools/libxl/libxl_dm.c	Mon Dec 05 11:06:45 2011 +0100
@@ -917,7 +917,7 @@ int libxl__destroy_device_model(libxl__g
             goto out;
         }
         LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Device model is a stubdom, domid=%d", stubdomid);
-        ret = libxl_domain_destroy(ctx, stubdomid, 0);
+        ret = libxl_domain_destroy(ctx, stubdomid);
         if (ret)
             goto out;
     } else {
diff -r bc90cfd8dd22 -r c0d51df66b82 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Mon Dec 05 11:06:23 2011 +0100
+++ b/tools/libxl/xl_cmdimpl.c	Mon Dec 05 11:06:45 2011 +0100
@@ -1200,7 +1200,7 @@ static int handle_domain_death(libxl_ctx
         /* fall-through */
     case LIBXL_ACTION_ON_SHUTDOWN_DESTROY:
         LOG("Domain %d needs to be cleaned up: destroying the domain", domid);
-        libxl_domain_destroy(ctx, domid, 0);
+        libxl_domain_destroy(ctx, domid);
         break;
 
     case LIBXL_ACTION_ON_SHUTDOWN_COREDUMP_DESTROY:
@@ -1698,7 +1698,7 @@ start:
 error_out:
     release_lock();
     if (libxl_domid_valid_guest(domid))
-        libxl_domain_destroy(ctx, domid, 0);
+        libxl_domain_destroy(ctx, domid);
 
 out:
     if (logfile != 2)
@@ -2168,7 +2168,7 @@ static void destroy_domain(const char *p
         fprintf(stderr, "Cannot destroy privileged domain 0.\n\n");
         exit(-1);
     }
-    rc = libxl_domain_destroy(ctx, domid, 0);
+    rc = libxl_domain_destroy(ctx, domid);
     if (rc) { fprintf(stderr,"destroy failed (rc=%d)\n",rc); exit(-1); }
 }
 
@@ -2414,7 +2414,7 @@ static int save_domain(const char *p, co
     if (checkpoint)
         libxl_domain_unpause(ctx, domid);
     else
-        libxl_domain_destroy(ctx, domid, 0);
+        libxl_domain_destroy(ctx, domid);
 
     exit(0);
 }
@@ -2647,7 +2647,7 @@ static void migrate_domain(const char *d
     }
 
     fprintf(stderr, "migration sender: Target reports successful startup.\n");
-    libxl_domain_destroy(ctx, domid, 1); /* bang! */
+    libxl_domain_destroy(ctx, domid); /* bang! */
     fprintf(stderr, "Migration successful.\n");
     exit(0);
 
@@ -2764,7 +2764,7 @@ static void migrate_receive(int debug, i
     if (rc) {
         fprintf(stderr, "migration target: Failure, destroying our copy.\n");
 
-        rc2 = libxl_domain_destroy(ctx, domid, 1);
+        rc2 = libxl_domain_destroy(ctx, domid);
         if (rc2) {
             fprintf(stderr, "migration target: Failed to destroy our copy"
                     " (code %d).\n", rc2);
diff -r bc90cfd8dd22 -r c0d51df66b82 tools/python/xen/lowlevel/xl/xl.c
--- a/tools/python/xen/lowlevel/xl/xl.c	Mon Dec 05 11:06:23 2011 +0100
+++ b/tools/python/xen/lowlevel/xl/xl.c	Mon Dec 05 11:06:45 2011 +0100
@@ -437,10 +437,10 @@ static PyObject *pyxl_domain_shutdown(Xl
 
 static PyObject *pyxl_domain_destroy(XlObject *self, PyObject *args)
 {
-    int domid, force = 1;
-    if ( !PyArg_ParseTuple(args, "i|i", &domid, &force) )
+    int domid;
+    if ( !PyArg_ParseTuple(args, "i", &domid) )
         return NULL;
-    if ( libxl_domain_destroy(self->ctx, domid, force) ) {
+    if ( libxl_domain_destroy(self->ctx, domid) ) {
         PyErr_SetString(xl_error_obj, "cannot destroy domain");
         return NULL;
     }

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 08:39:23 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 08:39:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYD1g-0001av-DF; Wed, 07 Dec 2011 08:38:52 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RYD1e-0001ab-F6
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 08:38:50 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1323247048!55689555!3
X-Originating-IP: [74.125.83.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28915 invoked from network); 7 Dec 2011 08:37:32 -0000
Received: from mail-ee0-f43.google.com (HELO mail-ee0-f43.google.com)
	(74.125.83.43)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Dec 2011 08:37:32 -0000
Received: by mail-ee0-f43.google.com with SMTP id d49so1302403eek.30
	for <xen-devel@lists.xensource.com>;
	Wed, 07 Dec 2011 00:38:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=gMeQJnu56LB2IdidJsPcuYct/MiVjmBIi1eMbxRt0Fo=;
	b=cpF5UXXuyl3Q4FDKnfFAe0DnzkkTrHy4QuHN1TpM6bRbcBlvspPRQOvV8vXYt/1U3+
	G7zMkpjYfbBHfP83O249VitWUhhKw8R3Mc3TtGTs6GCJQxRexvjn6ZUzAYAF+Wuo6nKM
	y6n5Q2Q08x8RZbNUC+Rz+BP2QcqIwalbqSvMg=
Received: by 10.14.17.144 with SMTP id j16mr3122006eej.182.1323247085446;
	Wed, 07 Dec 2011 00:38:05 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id d6sm3184965eec.10.2011.12.07.00.38.03
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 07 Dec 2011 00:38:04 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: c0d51df66b829995c4eb3902b5b9914c710a6c01
Message-Id: <c0d51df66b829995c4eb.1323246922@loki.upc.es>
In-Reply-To: <patchbomb.1323246920@loki.upc.es>
References: <patchbomb.1323246920@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Wed, 07 Dec 2011 09:35:22 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 2 of 3 v2] libxl: remove force parameter from
 libxl_domain_destroy
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1323079605 -3600
# Node ID c0d51df66b829995c4eb3902b5b9914c710a6c01
# Parent  bc90cfd8dd220d69d09cf94a3d39ff3cef76d021
libxl: remove force parameter from libxl_domain_destroy

Since a destroy is considered a forced shutdown, there's no point in
passing a force parameter. All the occurences of this function have
been replaced with the proper syntax.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r bc90cfd8dd22 -r c0d51df66b82 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Mon Dec 05 11:06:23 2011 +0100
+++ b/tools/libxl/libxl.c	Mon Dec 05 11:06:45 2011 +0100
@@ -718,7 +718,7 @@ int libxl_event_get_disk_eject_info(libx
     return 1;
 }
 
-int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid, int force)
+int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid)
 {
     libxl__gc gc = LIBXL_INIT_GC(ctx);
     libxl_dominfo dominfo;
@@ -767,7 +767,7 @@ int libxl_domain_destroy(libxl_ctx *ctx,
 
         libxl__qmp_cleanup(&gc, domid);
     }
-    if (libxl__devices_destroy(&gc, domid, force) < 0)
+    if (libxl__devices_destroy(&gc, domid, 1) < 0)
         LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "libxl__devices_destroy failed for %d", domid);
 
     vm_path = libxl__xs_read(&gc, XBT_NULL, libxl__sprintf(&gc, "%s/vm", dom_path));
diff -r bc90cfd8dd22 -r c0d51df66b82 tools/libxl/libxl.h
--- a/tools/libxl/libxl.h	Mon Dec 05 11:06:23 2011 +0100
+++ b/tools/libxl/libxl.h	Mon Dec 05 11:06:45 2011 +0100
@@ -269,7 +269,7 @@ int libxl_domain_suspend(libxl_ctx *ctx,
                           uint32_t domid, int fd);
 int libxl_domain_resume(libxl_ctx *ctx, uint32_t domid);
 int libxl_domain_shutdown(libxl_ctx *ctx, uint32_t domid, int req);
-int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid, int force);
+int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid);
 int libxl_domain_preserve(libxl_ctx *ctx, uint32_t domid, libxl_domain_create_info *info, const char *name_suffix, libxl_uuid new_uuid);
 
 /* get max. number of cpus supported by hypervisor */
diff -r bc90cfd8dd22 -r c0d51df66b82 tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Mon Dec 05 11:06:23 2011 +0100
+++ b/tools/libxl/libxl_create.c	Mon Dec 05 11:06:45 2011 +0100
@@ -646,7 +646,7 @@ static int do_domain_create(libxl__gc *g
 
 error_out:
     if (domid)
-        libxl_domain_destroy(ctx, domid, 0);
+        libxl_domain_destroy(ctx, domid);
 
     return ret;
 }
diff -r bc90cfd8dd22 -r c0d51df66b82 tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Mon Dec 05 11:06:23 2011 +0100
+++ b/tools/libxl/libxl_dm.c	Mon Dec 05 11:06:45 2011 +0100
@@ -917,7 +917,7 @@ int libxl__destroy_device_model(libxl__g
             goto out;
         }
         LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Device model is a stubdom, domid=%d", stubdomid);
-        ret = libxl_domain_destroy(ctx, stubdomid, 0);
+        ret = libxl_domain_destroy(ctx, stubdomid);
         if (ret)
             goto out;
     } else {
diff -r bc90cfd8dd22 -r c0d51df66b82 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Mon Dec 05 11:06:23 2011 +0100
+++ b/tools/libxl/xl_cmdimpl.c	Mon Dec 05 11:06:45 2011 +0100
@@ -1200,7 +1200,7 @@ static int handle_domain_death(libxl_ctx
         /* fall-through */
     case LIBXL_ACTION_ON_SHUTDOWN_DESTROY:
         LOG("Domain %d needs to be cleaned up: destroying the domain", domid);
-        libxl_domain_destroy(ctx, domid, 0);
+        libxl_domain_destroy(ctx, domid);
         break;
 
     case LIBXL_ACTION_ON_SHUTDOWN_COREDUMP_DESTROY:
@@ -1698,7 +1698,7 @@ start:
 error_out:
     release_lock();
     if (libxl_domid_valid_guest(domid))
-        libxl_domain_destroy(ctx, domid, 0);
+        libxl_domain_destroy(ctx, domid);
 
 out:
     if (logfile != 2)
@@ -2168,7 +2168,7 @@ static void destroy_domain(const char *p
         fprintf(stderr, "Cannot destroy privileged domain 0.\n\n");
         exit(-1);
     }
-    rc = libxl_domain_destroy(ctx, domid, 0);
+    rc = libxl_domain_destroy(ctx, domid);
     if (rc) { fprintf(stderr,"destroy failed (rc=%d)\n",rc); exit(-1); }
 }
 
@@ -2414,7 +2414,7 @@ static int save_domain(const char *p, co
     if (checkpoint)
         libxl_domain_unpause(ctx, domid);
     else
-        libxl_domain_destroy(ctx, domid, 0);
+        libxl_domain_destroy(ctx, domid);
 
     exit(0);
 }
@@ -2647,7 +2647,7 @@ static void migrate_domain(const char *d
     }
 
     fprintf(stderr, "migration sender: Target reports successful startup.\n");
-    libxl_domain_destroy(ctx, domid, 1); /* bang! */
+    libxl_domain_destroy(ctx, domid); /* bang! */
     fprintf(stderr, "Migration successful.\n");
     exit(0);
 
@@ -2764,7 +2764,7 @@ static void migrate_receive(int debug, i
     if (rc) {
         fprintf(stderr, "migration target: Failure, destroying our copy.\n");
 
-        rc2 = libxl_domain_destroy(ctx, domid, 1);
+        rc2 = libxl_domain_destroy(ctx, domid);
         if (rc2) {
             fprintf(stderr, "migration target: Failed to destroy our copy"
                     " (code %d).\n", rc2);
diff -r bc90cfd8dd22 -r c0d51df66b82 tools/python/xen/lowlevel/xl/xl.c
--- a/tools/python/xen/lowlevel/xl/xl.c	Mon Dec 05 11:06:23 2011 +0100
+++ b/tools/python/xen/lowlevel/xl/xl.c	Mon Dec 05 11:06:45 2011 +0100
@@ -437,10 +437,10 @@ static PyObject *pyxl_domain_shutdown(Xl
 
 static PyObject *pyxl_domain_destroy(XlObject *self, PyObject *args)
 {
-    int domid, force = 1;
-    if ( !PyArg_ParseTuple(args, "i|i", &domid, &force) )
+    int domid;
+    if ( !PyArg_ParseTuple(args, "i", &domid) )
         return NULL;
-    if ( libxl_domain_destroy(self->ctx, domid, force) ) {
+    if ( libxl_domain_destroy(self->ctx, domid) ) {
         PyErr_SetString(xl_error_obj, "cannot destroy domain");
         return NULL;
     }

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 08:52:28 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 08:52:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYDEP-0002DN-8N; Wed, 07 Dec 2011 08:52:01 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RYDEN-0002DI-OP
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 08:52:00 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1323247853!51183742!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU5MQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1686 invoked from network); 7 Dec 2011 08:50:53 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Dec 2011 08:50:53 -0000
X-IronPort-AV: E=Sophos;i="4.71,313,1320624000"; 
   d="scan'208";a="9335069"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Dec 2011 08:50:12 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 7 Dec 2011 08:50:12 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RYDCe-0000Xz-3E;
	Wed, 07 Dec 2011 08:50:12 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RYDCe-00085p-2W;
	Wed, 07 Dec 2011 08:50:12 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10401-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 7 Dec 2011 08:50:12 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10401: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10401 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10401/

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-i386-win           8 guest-saverestore         fail REGR. vs. 10201
 test-i386-i386-win            8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-amd64-win          8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-i386-win-vcpus1    8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-amd64-xl-win       8 guest-saverestore         fail REGR. vs. 10201
 test-i386-i386-xl-win         8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-i386-xl-win-vcpus1 8 guest-saverestore fail in 10397 REGR. vs. 10201

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf     11 guest-localmigrate          fail pass in 10397
 test-amd64-i386-xl-win-vcpus1  7 windows-install            fail pass in 10397
 test-amd64-amd64-xl-win       7 windows-install    fail in 10397 pass in 10401

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-win7-amd64  7 windows-install              fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install          fail never pass
 test-amd64-i386-xl-win7-amd64  7 windows-install              fail  never pass
 test-i386-i386-xl-winxpsp3    7 windows-install              fail   never pass
 test-amd64-i386-xend-winxpsp3  7 windows-install              fail  never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   never pass

version targeted for testing:
 xen                  38eb74c01d9d
baseline version:
 xen                  62ff6a318c5d

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scanneel.ca>
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Andres Lagar-Cavilla <andres@lagarcavilla>
  Andrew Cooper <andrew.cooper3@citrix.com>
  Anthony PERARD <anthony.perard@citrix.com>
  Brendan Cully <brendan@cs.ubc.ca>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Haitao Shan <haitao.shan@intel.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@novell.com>
  Jan Beulich <jbeulich@suse.com>
  Jonathan Davies <jonathan.davies@citrix.com>
  juergen.gross@ts.fujitsu.com
  Keir Fraser <keir@xen.org>
  Liu, Jinsong <jinsong.liu@intel.com>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
  Philipp Hahn <hahn@univention.de>
  Shriram Rajagopalan <rshriram@cs.ubc.ca>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang2 <wei.wang2@amd.com>
  Xudong Hao <xudong.hao@intel.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 1493 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 08:52:28 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 08:52:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYDEP-0002DN-8N; Wed, 07 Dec 2011 08:52:01 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RYDEN-0002DI-OP
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 08:52:00 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1323247853!51183742!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU5MQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1686 invoked from network); 7 Dec 2011 08:50:53 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Dec 2011 08:50:53 -0000
X-IronPort-AV: E=Sophos;i="4.71,313,1320624000"; 
   d="scan'208";a="9335069"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Dec 2011 08:50:12 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 7 Dec 2011 08:50:12 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RYDCe-0000Xz-3E;
	Wed, 07 Dec 2011 08:50:12 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RYDCe-00085p-2W;
	Wed, 07 Dec 2011 08:50:12 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10401-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 7 Dec 2011 08:50:12 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10401: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10401 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10401/

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-i386-win           8 guest-saverestore         fail REGR. vs. 10201
 test-i386-i386-win            8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-amd64-win          8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-i386-win-vcpus1    8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-amd64-xl-win       8 guest-saverestore         fail REGR. vs. 10201
 test-i386-i386-xl-win         8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-i386-xl-win-vcpus1 8 guest-saverestore fail in 10397 REGR. vs. 10201

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf     11 guest-localmigrate          fail pass in 10397
 test-amd64-i386-xl-win-vcpus1  7 windows-install            fail pass in 10397
 test-amd64-amd64-xl-win       7 windows-install    fail in 10397 pass in 10401

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-win7-amd64  7 windows-install              fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install          fail never pass
 test-amd64-i386-xl-win7-amd64  7 windows-install              fail  never pass
 test-i386-i386-xl-winxpsp3    7 windows-install              fail   never pass
 test-amd64-i386-xend-winxpsp3  7 windows-install              fail  never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   never pass

version targeted for testing:
 xen                  38eb74c01d9d
baseline version:
 xen                  62ff6a318c5d

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scanneel.ca>
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Andres Lagar-Cavilla <andres@lagarcavilla>
  Andrew Cooper <andrew.cooper3@citrix.com>
  Anthony PERARD <anthony.perard@citrix.com>
  Brendan Cully <brendan@cs.ubc.ca>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Haitao Shan <haitao.shan@intel.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@novell.com>
  Jan Beulich <jbeulich@suse.com>
  Jonathan Davies <jonathan.davies@citrix.com>
  juergen.gross@ts.fujitsu.com
  Keir Fraser <keir@xen.org>
  Liu, Jinsong <jinsong.liu@intel.com>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
  Philipp Hahn <hahn@univention.de>
  Shriram Rajagopalan <rshriram@cs.ubc.ca>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang2 <wei.wang2@amd.com>
  Xudong Hao <xudong.hao@intel.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 1493 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 08:52:58 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 08:52:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYDEy-0002Fi-TD; Wed, 07 Dec 2011 08:52:36 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RYDEx-0002FH-SN
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 08:52:36 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1323247908!5281425!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM1ODk=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18862 invoked from network); 7 Dec 2011 08:51:49 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-13.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 7 Dec 2011 08:51:49 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 07 Dec 2011 08:51:48 +0000
Message-Id: <4EDF375E0200007800065E06@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 07 Dec 2011 08:52:30 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Stefano Stabellini" <stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1112061753410.31179@kaball-desktop>
	<1323195609-17277-1-git-send-email-stefano.stabellini@eu.citrix.com>
In-Reply-To: <1323195609-17277-1-git-send-email-stefano.stabellini@eu.citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com, Ian Campbell <ian.campbell@citrix.com>,
	Tim.Deegan@citrix.com
Subject: Re: [Xen-devel] [PATCH RFC 01/25] Include some header files that
 are not automatically included on all archs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 06.12.11 at 19:19, <stefano.stabellini@eu.citrix.com> wrote:
> --- a/xen/common/grant_table.c
> +++ b/xen/common/grant_table.c
> @@ -24,6 +24,7 @@
>   * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
>   */
>  
> +#include <asm/flushtlb.h>

It's pretty uncommon to have asm/ headers included before xen/ ones,
and it's definitely wrong to do so before xen/config.h.

>  #include <xen/config.h>
>  #include <xen/iocap.h>
>  #include <xen/lib.h>
> --- a/xen/common/memory.c
> +++ b/xen/common/memory.c
> @@ -23,9 +23,7 @@
>  #include <xen/tmem_xen.h>
>  #include <asm/current.h>
>  #include <asm/hardirq.h>
> -#ifdef CONFIG_X86
> -# include <asm/p2m.h>
> -#endif
> +#include <asm/p2m.h>

This header doesn't exist on ia64; if you had looked in the history
why the #ifdef got introduced, you would have noticed. So either
we need to introduce something like CONFIG_P2M, or ia64 needs
to get a stub header, or the conditional above needs to simply be
extended.

>  #include <xen/numa.h>
>  #include <public/memory.h>
>  #include <xsm/xsm.h>
> --- a/xen/include/xen/tmem_xen.h
> +++ b/xen/include/xen/tmem_xen.h
> @@ -11,6 +11,7 @@
>  
>  #include <xen/config.h>
>  #include <xen/mm.h> /* heap alloc/free */
> +#include <xen/pfn.h> /* heap alloc/free */

The comment is certainly wrong - correct it or remove it.

>  #include <xen/xmalloc.h> /* xmalloc/xfree */
>  #include <xen/sched.h>  /* struct domain */
>  #include <xen/guest_access.h> /* copy_from_guest */

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 08:52:58 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 08:52:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYDEy-0002Fi-TD; Wed, 07 Dec 2011 08:52:36 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RYDEx-0002FH-SN
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 08:52:36 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1323247908!5281425!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM1ODk=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18862 invoked from network); 7 Dec 2011 08:51:49 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-13.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 7 Dec 2011 08:51:49 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 07 Dec 2011 08:51:48 +0000
Message-Id: <4EDF375E0200007800065E06@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 07 Dec 2011 08:52:30 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Stefano Stabellini" <stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1112061753410.31179@kaball-desktop>
	<1323195609-17277-1-git-send-email-stefano.stabellini@eu.citrix.com>
In-Reply-To: <1323195609-17277-1-git-send-email-stefano.stabellini@eu.citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com, Ian Campbell <ian.campbell@citrix.com>,
	Tim.Deegan@citrix.com
Subject: Re: [Xen-devel] [PATCH RFC 01/25] Include some header files that
 are not automatically included on all archs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 06.12.11 at 19:19, <stefano.stabellini@eu.citrix.com> wrote:
> --- a/xen/common/grant_table.c
> +++ b/xen/common/grant_table.c
> @@ -24,6 +24,7 @@
>   * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
>   */
>  
> +#include <asm/flushtlb.h>

It's pretty uncommon to have asm/ headers included before xen/ ones,
and it's definitely wrong to do so before xen/config.h.

>  #include <xen/config.h>
>  #include <xen/iocap.h>
>  #include <xen/lib.h>
> --- a/xen/common/memory.c
> +++ b/xen/common/memory.c
> @@ -23,9 +23,7 @@
>  #include <xen/tmem_xen.h>
>  #include <asm/current.h>
>  #include <asm/hardirq.h>
> -#ifdef CONFIG_X86
> -# include <asm/p2m.h>
> -#endif
> +#include <asm/p2m.h>

This header doesn't exist on ia64; if you had looked in the history
why the #ifdef got introduced, you would have noticed. So either
we need to introduce something like CONFIG_P2M, or ia64 needs
to get a stub header, or the conditional above needs to simply be
extended.

>  #include <xen/numa.h>
>  #include <public/memory.h>
>  #include <xsm/xsm.h>
> --- a/xen/include/xen/tmem_xen.h
> +++ b/xen/include/xen/tmem_xen.h
> @@ -11,6 +11,7 @@
>  
>  #include <xen/config.h>
>  #include <xen/mm.h> /* heap alloc/free */
> +#include <xen/pfn.h> /* heap alloc/free */

The comment is certainly wrong - correct it or remove it.

>  #include <xen/xmalloc.h> /* xmalloc/xfree */
>  #include <xen/sched.h>  /* struct domain */
>  #include <xen/guest_access.h> /* copy_from_guest */

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 09:00:27 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 09:00:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYDME-0002bo-0h; Wed, 07 Dec 2011 09:00:06 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RYDMC-0002ZJ-T4
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 09:00:05 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1323248357!1526105!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM1ODk=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20387 invoked from network); 7 Dec 2011 08:59:18 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-2.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 7 Dec 2011 08:59:18 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 07 Dec 2011 08:59:17 +0000
Message-Id: <4EDF39210200007800065E15@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 07 Dec 2011 09:00:01 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Stefano Stabellini" <stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1112061753410.31179@kaball-desktop>
	<1323195609-17277-2-git-send-email-stefano.stabellini@eu.citrix.com>
In-Reply-To: <1323195609-17277-2-git-send-email-stefano.stabellini@eu.citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com, Ian Campbell <ian.campbell@citrix.com>,
	Tim.Deegan@citrix.com
Subject: Re: [Xen-devel] [PATCH RFC 02/25] A collection of fixes to Xen
 common files
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 06.12.11 at 19:19, <stefano.stabellini@eu.citrix.com> wrote:
> - call free_xenoprof_pages only ifdef xenoprof;

I can't find where this symbol would get defined, so effectively you're
removing the call unconditionally.

> +extern char _srodata[], _erodata[];

While I realize that this isn't currently the case on e.g. the respective
.text symbols, if you introduce new once, please add const to the
declarations *at least* when the section contents really are read only
(in many cases doing so even for writable sections is likely appropriate
too).

> +#define is_kernel_rodata(p) ({                  \
> +    char *__p = (char *)(unsigned long)(p);     \
> +    (__p >= _srodata) && (__p < _erodata);      \

Obviously the above calls for adjustments here, too.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 09:00:27 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 09:00:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYDME-0002bo-0h; Wed, 07 Dec 2011 09:00:06 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RYDMC-0002ZJ-T4
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 09:00:05 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1323248357!1526105!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM1ODk=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20387 invoked from network); 7 Dec 2011 08:59:18 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-2.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 7 Dec 2011 08:59:18 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 07 Dec 2011 08:59:17 +0000
Message-Id: <4EDF39210200007800065E15@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 07 Dec 2011 09:00:01 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Stefano Stabellini" <stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1112061753410.31179@kaball-desktop>
	<1323195609-17277-2-git-send-email-stefano.stabellini@eu.citrix.com>
In-Reply-To: <1323195609-17277-2-git-send-email-stefano.stabellini@eu.citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com, Ian Campbell <ian.campbell@citrix.com>,
	Tim.Deegan@citrix.com
Subject: Re: [Xen-devel] [PATCH RFC 02/25] A collection of fixes to Xen
 common files
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 06.12.11 at 19:19, <stefano.stabellini@eu.citrix.com> wrote:
> - call free_xenoprof_pages only ifdef xenoprof;

I can't find where this symbol would get defined, so effectively you're
removing the call unconditionally.

> +extern char _srodata[], _erodata[];

While I realize that this isn't currently the case on e.g. the respective
.text symbols, if you introduce new once, please add const to the
declarations *at least* when the section contents really are read only
(in many cases doing so even for writable sections is likely appropriate
too).

> +#define is_kernel_rodata(p) ({                  \
> +    char *__p = (char *)(unsigned long)(p);     \
> +    (__p >= _srodata) && (__p < _erodata);      \

Obviously the above calls for adjustments here, too.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 09:00:53 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 09: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.xensource.com>)
	id 1RYDMi-0002eC-EJ; Wed, 07 Dec 2011 09:00:36 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RYDMg-0002dm-QH
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 09:00:35 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1323248387!4548697!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU5MQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20404 invoked from network); 7 Dec 2011 08:59:47 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Dec 2011 08:59:47 -0000
X-IronPort-AV: E=Sophos;i="4.71,313,1320624000"; 
   d="scan'208";a="9335241"
Received: from lonpmailmx02.citrite.net ([10.30.203.163])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Dec 2011 08:59:47 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.161]) by
	LONPMAILMX02.citrite.net ([10.30.203.163]) with mapi; Wed, 7 Dec 2011
	08:59:47 +0000
From: Paul Durrant <Paul.Durrant@citrix.com>
To: ANNIE LI <annie.li@oracle.com>, Ian Campbell <Ian.Campbell@citrix.com>
Date: Wed, 7 Dec 2011 08:59:54 +0000
Thread-Topic: [PATCH 1/2] xen/granttable: Support sub-page grants
Thread-Index: Acy0kWlTUi6fNwM7RkGEcuaSxoQaNwALOQeA
Message-ID: <291EDFCB1E9E224A99088639C4762022B5988E542E@LONPMAILBOX01.citrite.net>
References: <4EDDF41E.8070200@oracle.com>
	<1323168999-4434-1-git-send-email-annie.li@oracle.com>
	<1323171726.23681.65.camel@zakaz.uk.xensource.com>
	<4EDEDF2E.3040204@oracle.com>
In-Reply-To: <4EDEDF2E.3040204@oracle.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "kurt.hackel@oracle.com" <kurt.hackel@oracle.com>,
	"jeremy@goop.org" <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH 1/2] xen/granttable: Support sub-page grants
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com



> -----Original Message-----
> From: ANNIE LI [mailto:annie.li@oracle.com]
> Sent: 07 December 2011 03:36
> To: Ian Campbell
> Cc: xen-devel@lists.xensource.com; linux-kernel@vger.kernel.org;
> konrad.wilk@oracle.com; jeremy@goop.org; kurt.hackel@oracle.com;
> Paul Durrant
> Subject: Re: [PATCH 1/2] xen/granttable: Support sub-page grants
> 
> Thanks for your reviewing, Ian.
> >>   EXPORT_SYMBOL_GPL(gnttab_grant_foreign_access);
> >>
> >> +int gnttab_grant_foreign_access_subpage_v2(domid_t domid,
> unsigned long frame,
> >> +					   int flags, unsigned page_off,
> >> +					   unsigned length)
> > Please drop the v2 suffixes on the public functions.
> OK, the initial interface is without v2 suffixes. It was added in
> order to reminder user the interfaces are only available for grant
> table v2.
> But I am fine to remove it, and following ops fn pointers are
> better.
> > Any reason not to route these via the ops table for consistency
> with
> > all the other ops? Then your availability check becomes a test for
> > NULL fn pointer rather than a specific version.
> Ok, it is good.
> How about following implements?
> 
> gnttab_v1_ops = {
>   ...
> .access_subpage = NULL;
> .access_ref_subpage = NULL;
> .access_trans = NULL;
> .access_ref_trans = NULL;
> }
> 
> gnttab_v2_ops = {
>   ...
> .access_subpage = access_subpage_v2;
> .access_ref_subpage = access_ref_subpage_v2; .access_trans =
> access_trans_v2; .access_ref_trans = access_ref_trans_v2; }
> 


Do you need ops for the ref and non-ref functions? I would have thought you could just have the ref ones since the all the non-ref variants do is allocate and then call the ref variant.

  Paul

> gnttab_request_version()
> {
> .....
>     if(v2)
>        gnttab_interface = &gnttab_v2_ops;
>     else
>        gnttab_interface = &gnttab_v1_ops; .....
> }
> 
> int gnttab_grant_foreign_access_subpage()
> {
>        if(gnttab_interface->access_subpage != NULL)
>              return gnttab_interface->access_subpage;
>        return Esomething;
> }
> 
> Same operations for access_ref_subpage, access_trans and
> access_ref_trans.
> 
> bool gnttab_subpage_available()
> {
>       return (gnttab_interface->access_subpage != NULL); }
> 
> bool gnttab_subpage_available()
> {
>       return (gnttab_interface->access_trans != NULL); }
> 
> Thanks
> Annie
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 09:00:53 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 09: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.xensource.com>)
	id 1RYDMi-0002eC-EJ; Wed, 07 Dec 2011 09:00:36 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RYDMg-0002dm-QH
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 09:00:35 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1323248387!4548697!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjU5MQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20404 invoked from network); 7 Dec 2011 08:59:47 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Dec 2011 08:59:47 -0000
X-IronPort-AV: E=Sophos;i="4.71,313,1320624000"; 
   d="scan'208";a="9335241"
Received: from lonpmailmx02.citrite.net ([10.30.203.163])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Dec 2011 08:59:47 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.161]) by
	LONPMAILMX02.citrite.net ([10.30.203.163]) with mapi; Wed, 7 Dec 2011
	08:59:47 +0000
From: Paul Durrant <Paul.Durrant@citrix.com>
To: ANNIE LI <annie.li@oracle.com>, Ian Campbell <Ian.Campbell@citrix.com>
Date: Wed, 7 Dec 2011 08:59:54 +0000
Thread-Topic: [PATCH 1/2] xen/granttable: Support sub-page grants
Thread-Index: Acy0kWlTUi6fNwM7RkGEcuaSxoQaNwALOQeA
Message-ID: <291EDFCB1E9E224A99088639C4762022B5988E542E@LONPMAILBOX01.citrite.net>
References: <4EDDF41E.8070200@oracle.com>
	<1323168999-4434-1-git-send-email-annie.li@oracle.com>
	<1323171726.23681.65.camel@zakaz.uk.xensource.com>
	<4EDEDF2E.3040204@oracle.com>
In-Reply-To: <4EDEDF2E.3040204@oracle.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "kurt.hackel@oracle.com" <kurt.hackel@oracle.com>,
	"jeremy@goop.org" <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH 1/2] xen/granttable: Support sub-page grants
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com



> -----Original Message-----
> From: ANNIE LI [mailto:annie.li@oracle.com]
> Sent: 07 December 2011 03:36
> To: Ian Campbell
> Cc: xen-devel@lists.xensource.com; linux-kernel@vger.kernel.org;
> konrad.wilk@oracle.com; jeremy@goop.org; kurt.hackel@oracle.com;
> Paul Durrant
> Subject: Re: [PATCH 1/2] xen/granttable: Support sub-page grants
> 
> Thanks for your reviewing, Ian.
> >>   EXPORT_SYMBOL_GPL(gnttab_grant_foreign_access);
> >>
> >> +int gnttab_grant_foreign_access_subpage_v2(domid_t domid,
> unsigned long frame,
> >> +					   int flags, unsigned page_off,
> >> +					   unsigned length)
> > Please drop the v2 suffixes on the public functions.
> OK, the initial interface is without v2 suffixes. It was added in
> order to reminder user the interfaces are only available for grant
> table v2.
> But I am fine to remove it, and following ops fn pointers are
> better.
> > Any reason not to route these via the ops table for consistency
> with
> > all the other ops? Then your availability check becomes a test for
> > NULL fn pointer rather than a specific version.
> Ok, it is good.
> How about following implements?
> 
> gnttab_v1_ops = {
>   ...
> .access_subpage = NULL;
> .access_ref_subpage = NULL;
> .access_trans = NULL;
> .access_ref_trans = NULL;
> }
> 
> gnttab_v2_ops = {
>   ...
> .access_subpage = access_subpage_v2;
> .access_ref_subpage = access_ref_subpage_v2; .access_trans =
> access_trans_v2; .access_ref_trans = access_ref_trans_v2; }
> 


Do you need ops for the ref and non-ref functions? I would have thought you could just have the ref ones since the all the non-ref variants do is allocate and then call the ref variant.

  Paul

> gnttab_request_version()
> {
> .....
>     if(v2)
>        gnttab_interface = &gnttab_v2_ops;
>     else
>        gnttab_interface = &gnttab_v1_ops; .....
> }
> 
> int gnttab_grant_foreign_access_subpage()
> {
>        if(gnttab_interface->access_subpage != NULL)
>              return gnttab_interface->access_subpage;
>        return Esomething;
> }
> 
> Same operations for access_ref_subpage, access_trans and
> access_ref_trans.
> 
> bool gnttab_subpage_available()
> {
>       return (gnttab_interface->access_subpage != NULL); }
> 
> bool gnttab_subpage_available()
> {
>       return (gnttab_interface->access_trans != NULL); }
> 
> Thanks
> Annie
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 09:02:11 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 09:02:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYDNy-0002ln-UV; Wed, 07 Dec 2011 09:01:54 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RYDNx-0002l8-6f
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 09:01:53 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1323248466!976773!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM2OTE=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6842 invoked from network); 7 Dec 2011 09:01:06 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-9.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 7 Dec 2011 09:01:06 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 07 Dec 2011 09:01:05 +0000
Message-Id: <4EDF398C0200007800065E18@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 07 Dec 2011 09:01:48 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Stefano Stabellini" <stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1112061753410.31179@kaball-desktop>
	<1323195609-17277-3-git-send-email-stefano.stabellini@eu.citrix.com>
In-Reply-To: <1323195609-17277-3-git-send-email-stefano.stabellini@eu.citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com, Ian Campbell <ian.campbell@citrix.com>,
	Tim.Deegan@citrix.com
Subject: Re: [Xen-devel] [PATCH RFC 03/25] Move cpufreq option parsing to
 cpufreq.c
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 06.12.11 at 19:19, <stefano.stabellini@eu.citrix.com> wrote:
> From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>

Acked-by: Jan Beulich <jbeulich@suse.com>

(perhaps as a standalone change, i.e. outside the whole series)

> ---
>  xen/common/domain.c           |   35 ++---------------------------------
>  xen/drivers/cpufreq/cpufreq.c |   31 +++++++++++++++++++++++++++++++
>  xen/include/xen/domain.h      |    2 ++
>  3 files changed, 35 insertions(+), 33 deletions(-)
> 
> diff --git a/xen/common/domain.c b/xen/common/domain.c
> index b75fc1d..f751d8f 100644
> --- a/xen/common/domain.c
> +++ b/xen/common/domain.c
> @@ -31,8 +31,8 @@
>  #include <xen/grant_table.h>
>  #include <xen/xenoprof.h>
>  #include <xen/irq.h>
> -#include <acpi/cpufreq/cpufreq.h>
>  #include <asm/debugger.h>
> +#include <asm/processor.h>
>  #include <public/sched.h>
>  #include <public/sysctl.h>
>  #include <public/vcpu.h>
> @@ -45,40 +45,9 @@
>  unsigned int xen_processor_pmbits = XEN_PROCESSOR_PM_PX;
>  
>  /* opt_dom0_vcpus_pin: If true, dom0 VCPUs are pinned. */
> -static bool_t opt_dom0_vcpus_pin;
> +bool_t opt_dom0_vcpus_pin;
>  boolean_param("dom0_vcpus_pin", opt_dom0_vcpus_pin);
>  
> -/* set xen as default cpufreq */
> -enum cpufreq_controller cpufreq_controller = FREQCTL_xen;
> -
> -static void __init setup_cpufreq_option(char *str)
> -{
> -    char *arg;
> -
> -    if ( !strcmp(str, "dom0-kernel") )
> -    {
> -        xen_processor_pmbits &= ~XEN_PROCESSOR_PM_PX;
> -        cpufreq_controller = FREQCTL_dom0_kernel;
> -        opt_dom0_vcpus_pin = 1;
> -        return;
> -    }
> -
> -    if ( !strcmp(str, "none") )
> -    {
> -        xen_processor_pmbits &= ~XEN_PROCESSOR_PM_PX;
> -        cpufreq_controller = FREQCTL_none;
> -        return;
> -    }
> -
> -    if ( (arg = strpbrk(str, ",:")) != NULL )
> -        *arg++ = '\0';
> -
> -    if ( !strcmp(str, "xen") )
> -        if ( arg && *arg )
> -            cpufreq_cmdline_parse(arg);
> -}
> -custom_param("cpufreq", setup_cpufreq_option);
> -
>  /* Protect updates/reads (resp.) of domain_list and domain_hash. */
>  DEFINE_SPINLOCK(domlist_update_lock);
>  DEFINE_RCU_READ_LOCK(domlist_read_lock);
> diff --git a/xen/drivers/cpufreq/cpufreq.c b/xen/drivers/cpufreq/cpufreq.c
> index f49ea1c..34ea2a9 100644
> --- a/xen/drivers/cpufreq/cpufreq.c
> +++ b/xen/drivers/cpufreq/cpufreq.c
> @@ -61,6 +61,37 @@ static LIST_HEAD_READ_MOSTLY(cpufreq_dom_list_head);
>  struct cpufreq_governor *__read_mostly cpufreq_opt_governor;
>  LIST_HEAD_READ_MOSTLY(cpufreq_governor_list);
>  
> +/* set xen as default cpufreq */
> +enum cpufreq_controller cpufreq_controller = FREQCTL_xen;
> +
> +static void __init setup_cpufreq_option(char *str)
> +{
> +    char *arg;
> +
> +    if ( !strcmp(str, "dom0-kernel") )
> +    {
> +        xen_processor_pmbits &= ~XEN_PROCESSOR_PM_PX;
> +        cpufreq_controller = FREQCTL_dom0_kernel;
> +        opt_dom0_vcpus_pin = 1;
> +        return;
> +    }
> +
> +    if ( !strcmp(str, "none") )
> +    {
> +        xen_processor_pmbits &= ~XEN_PROCESSOR_PM_PX;
> +        cpufreq_controller = FREQCTL_none;
> +        return;
> +    }
> +
> +    if ( (arg = strpbrk(str, ",:")) != NULL )
> +        *arg++ = '\0';
> +
> +    if ( !strcmp(str, "xen") )
> +        if ( arg && *arg )
> +            cpufreq_cmdline_parse(arg);
> +}
> +custom_param("cpufreq", setup_cpufreq_option);
> +
>  bool_t __read_mostly cpufreq_verbose;
>  
>  struct cpufreq_governor *__find_governor(const char *governor)
> diff --git a/xen/include/xen/domain.h b/xen/include/xen/domain.h
> index 765e132..de3e8db 100644
> --- a/xen/include/xen/domain.h
> +++ b/xen/include/xen/domain.h
> @@ -85,4 +85,6 @@ int continue_hypercall_on_cpu(
>  
>  extern unsigned int xen_processor_pmbits;
>  
> +extern bool_t opt_dom0_vcpus_pin;
> +
>  #endif /* __XEN_DOMAIN_H__ */




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 09:02:11 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 09:02:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYDNy-0002ln-UV; Wed, 07 Dec 2011 09:01:54 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RYDNx-0002l8-6f
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 09:01:53 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1323248466!976773!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM2OTE=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6842 invoked from network); 7 Dec 2011 09:01:06 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-9.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 7 Dec 2011 09:01:06 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 07 Dec 2011 09:01:05 +0000
Message-Id: <4EDF398C0200007800065E18@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 07 Dec 2011 09:01:48 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Stefano Stabellini" <stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1112061753410.31179@kaball-desktop>
	<1323195609-17277-3-git-send-email-stefano.stabellini@eu.citrix.com>
In-Reply-To: <1323195609-17277-3-git-send-email-stefano.stabellini@eu.citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com, Ian Campbell <ian.campbell@citrix.com>,
	Tim.Deegan@citrix.com
Subject: Re: [Xen-devel] [PATCH RFC 03/25] Move cpufreq option parsing to
 cpufreq.c
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 06.12.11 at 19:19, <stefano.stabellini@eu.citrix.com> wrote:
> From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>

Acked-by: Jan Beulich <jbeulich@suse.com>

(perhaps as a standalone change, i.e. outside the whole series)

> ---
>  xen/common/domain.c           |   35 ++---------------------------------
>  xen/drivers/cpufreq/cpufreq.c |   31 +++++++++++++++++++++++++++++++
>  xen/include/xen/domain.h      |    2 ++
>  3 files changed, 35 insertions(+), 33 deletions(-)
> 
> diff --git a/xen/common/domain.c b/xen/common/domain.c
> index b75fc1d..f751d8f 100644
> --- a/xen/common/domain.c
> +++ b/xen/common/domain.c
> @@ -31,8 +31,8 @@
>  #include <xen/grant_table.h>
>  #include <xen/xenoprof.h>
>  #include <xen/irq.h>
> -#include <acpi/cpufreq/cpufreq.h>
>  #include <asm/debugger.h>
> +#include <asm/processor.h>
>  #include <public/sched.h>
>  #include <public/sysctl.h>
>  #include <public/vcpu.h>
> @@ -45,40 +45,9 @@
>  unsigned int xen_processor_pmbits = XEN_PROCESSOR_PM_PX;
>  
>  /* opt_dom0_vcpus_pin: If true, dom0 VCPUs are pinned. */
> -static bool_t opt_dom0_vcpus_pin;
> +bool_t opt_dom0_vcpus_pin;
>  boolean_param("dom0_vcpus_pin", opt_dom0_vcpus_pin);
>  
> -/* set xen as default cpufreq */
> -enum cpufreq_controller cpufreq_controller = FREQCTL_xen;
> -
> -static void __init setup_cpufreq_option(char *str)
> -{
> -    char *arg;
> -
> -    if ( !strcmp(str, "dom0-kernel") )
> -    {
> -        xen_processor_pmbits &= ~XEN_PROCESSOR_PM_PX;
> -        cpufreq_controller = FREQCTL_dom0_kernel;
> -        opt_dom0_vcpus_pin = 1;
> -        return;
> -    }
> -
> -    if ( !strcmp(str, "none") )
> -    {
> -        xen_processor_pmbits &= ~XEN_PROCESSOR_PM_PX;
> -        cpufreq_controller = FREQCTL_none;
> -        return;
> -    }
> -
> -    if ( (arg = strpbrk(str, ",:")) != NULL )
> -        *arg++ = '\0';
> -
> -    if ( !strcmp(str, "xen") )
> -        if ( arg && *arg )
> -            cpufreq_cmdline_parse(arg);
> -}
> -custom_param("cpufreq", setup_cpufreq_option);
> -
>  /* Protect updates/reads (resp.) of domain_list and domain_hash. */
>  DEFINE_SPINLOCK(domlist_update_lock);
>  DEFINE_RCU_READ_LOCK(domlist_read_lock);
> diff --git a/xen/drivers/cpufreq/cpufreq.c b/xen/drivers/cpufreq/cpufreq.c
> index f49ea1c..34ea2a9 100644
> --- a/xen/drivers/cpufreq/cpufreq.c
> +++ b/xen/drivers/cpufreq/cpufreq.c
> @@ -61,6 +61,37 @@ static LIST_HEAD_READ_MOSTLY(cpufreq_dom_list_head);
>  struct cpufreq_governor *__read_mostly cpufreq_opt_governor;
>  LIST_HEAD_READ_MOSTLY(cpufreq_governor_list);
>  
> +/* set xen as default cpufreq */
> +enum cpufreq_controller cpufreq_controller = FREQCTL_xen;
> +
> +static void __init setup_cpufreq_option(char *str)
> +{
> +    char *arg;
> +
> +    if ( !strcmp(str, "dom0-kernel") )
> +    {
> +        xen_processor_pmbits &= ~XEN_PROCESSOR_PM_PX;
> +        cpufreq_controller = FREQCTL_dom0_kernel;
> +        opt_dom0_vcpus_pin = 1;
> +        return;
> +    }
> +
> +    if ( !strcmp(str, "none") )
> +    {
> +        xen_processor_pmbits &= ~XEN_PROCESSOR_PM_PX;
> +        cpufreq_controller = FREQCTL_none;
> +        return;
> +    }
> +
> +    if ( (arg = strpbrk(str, ",:")) != NULL )
> +        *arg++ = '\0';
> +
> +    if ( !strcmp(str, "xen") )
> +        if ( arg && *arg )
> +            cpufreq_cmdline_parse(arg);
> +}
> +custom_param("cpufreq", setup_cpufreq_option);
> +
>  bool_t __read_mostly cpufreq_verbose;
>  
>  struct cpufreq_governor *__find_governor(const char *governor)
> diff --git a/xen/include/xen/domain.h b/xen/include/xen/domain.h
> index 765e132..de3e8db 100644
> --- a/xen/include/xen/domain.h
> +++ b/xen/include/xen/domain.h
> @@ -85,4 +85,6 @@ int continue_hypercall_on_cpu(
>  
>  extern unsigned int xen_processor_pmbits;
>  
> +extern bool_t opt_dom0_vcpus_pin;
> +
>  #endif /* __XEN_DOMAIN_H__ */




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 09:13:49 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 09: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.xensource.com>)
	id 1RYDZE-00037J-7q; Wed, 07 Dec 2011 09:13:32 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RYDZB-00037B-Sl
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 09:13:30 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1323249162!5285003!1
X-Originating-IP: [209.85.215.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 963 invoked from network); 7 Dec 2011 09:12:42 -0000
Received: from mail-ey0-f171.google.com (HELO mail-ey0-f171.google.com)
	(209.85.215.171)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Dec 2011 09:12:42 -0000
Received: by eaad12 with SMTP id d12so1394225eaa.30
	for <xen-devel@lists.xensource.com>;
	Wed, 07 Dec 2011 01:12:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=5cMa3BQV5Ucwz08MAtpnvKNMrTJHMkanmAjaF1miaRk=;
	b=VQafQ1+Ga30g/kVc+tjxcDrdHytKPR9/10B02m8XmimP8PkDG3SzLg6q4jhx6S7Tug
	JYCiLltqq/UxB6UpttfaOCrcEYVhkcGQWR2O8gOhn9BEx6QhAXpyS9Vg9MfI6LuWVpph
	+fKZD+kVrtzlq+NJBtZYy5pUwu6CvT50hkd5Q=
Received: by 10.213.19.72 with SMTP id z8mr292440eba.35.1323249160703;
	Wed, 07 Dec 2011 01:12:40 -0800 (PST)
Received: from [192.168.1.70]
	(host81-155-119-104.range81-155.btcentralplus.com. [81.155.119.104])
	by mx.google.com with ESMTPS id e18sm1346619bkr.15.2011.12.07.01.12.38
	(version=SSLv3 cipher=OTHER); Wed, 07 Dec 2011 01:12:39 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Wed, 07 Dec 2011 09:12:36 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: "Zhang, Xiantao" <xiantao.zhang@intel.com>,
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>, 
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Message-ID: <CB04DE84.26A14%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH RFC 04/25] Replace "/" operand with div64
Thread-Index: Acy0RCyemylbkJbrQ06B4H2HTZu+wAAZifiAAAWB624=
In-Reply-To: <BC00F5384FCFC9499AF06F92E8B78A9E287D4A0E53@shsmsx502.ccr.corp.intel.com>
Mime-version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>, Tim Deegan <Tim.Deegan@citrix.com>
Subject: Re: [Xen-devel] [PATCH RFC 04/25] Replace "/" operand with div64
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Also, I assume the gcc arm target can at least do 64-bit arithmetic via
library calls, which you could then implement in arch/arm. __divdi3 etc.
Perhaps you intend to do this anyway and do_div() here is a bandaid.

 -- Keir

On 07/12/2011 07:00, "Zhang, Xiantao" <xiantao.zhang@intel.com> wrote:

> Hi, Stefano 
> Great work from you guys!  One quick comment:  Just found the below logic's
> change maybe wrong and probably  break current things.
> Original logic is  A+B -(C%D), but it is changed to  (A+B-C)%D,  so if it is
> not an intended fix, it should be an issue.
> Thanks!
> Xiantao  
> 
>> diff --git a/xen/common/timer.c b/xen/common/timer.c index 0547ea3..043250e
>> 100644
>> --- a/xen/common/timer.c
>> +++ b/xen/common/timer.c
>> @@ -23,6 +23,7 @@
>> #include <xen/symbols.h>
>> #include <asm/system.h>
>> #include <asm/desc.h>
>> +#include <asm/div64.h>
>> #include <asm/atomic.h>
>> 
>> /* We program the time hardware this far behind the closest deadline. */ @@
>> -503,16 +504,18 @@ static void timer_softirq_action(void)
>> 
>> s_time_t align_timer(s_time_t firsttick, uint64_t period)  {
>> +    uint64_t n;
>>    if ( !period )
>>        return firsttick;
>  
>> -    return firsttick + (period - 1) - ((firsttick - 1) % period);
>> +    n = firsttick + (period - 1) - (firsttick - 1);
>> +    return do_div(n, period);
>> }
>  
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 09:13:49 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 09: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.xensource.com>)
	id 1RYDZE-00037J-7q; Wed, 07 Dec 2011 09:13:32 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RYDZB-00037B-Sl
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 09:13:30 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1323249162!5285003!1
X-Originating-IP: [209.85.215.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 963 invoked from network); 7 Dec 2011 09:12:42 -0000
Received: from mail-ey0-f171.google.com (HELO mail-ey0-f171.google.com)
	(209.85.215.171)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Dec 2011 09:12:42 -0000
Received: by eaad12 with SMTP id d12so1394225eaa.30
	for <xen-devel@lists.xensource.com>;
	Wed, 07 Dec 2011 01:12:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=5cMa3BQV5Ucwz08MAtpnvKNMrTJHMkanmAjaF1miaRk=;
	b=VQafQ1+Ga30g/kVc+tjxcDrdHytKPR9/10B02m8XmimP8PkDG3SzLg6q4jhx6S7Tug
	JYCiLltqq/UxB6UpttfaOCrcEYVhkcGQWR2O8gOhn9BEx6QhAXpyS9Vg9MfI6LuWVpph
	+fKZD+kVrtzlq+NJBtZYy5pUwu6CvT50hkd5Q=
Received: by 10.213.19.72 with SMTP id z8mr292440eba.35.1323249160703;
	Wed, 07 Dec 2011 01:12:40 -0800 (PST)
Received: from [192.168.1.70]
	(host81-155-119-104.range81-155.btcentralplus.com. [81.155.119.104])
	by mx.google.com with ESMTPS id e18sm1346619bkr.15.2011.12.07.01.12.38
	(version=SSLv3 cipher=OTHER); Wed, 07 Dec 2011 01:12:39 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Wed, 07 Dec 2011 09:12:36 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: "Zhang, Xiantao" <xiantao.zhang@intel.com>,
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>, 
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Message-ID: <CB04DE84.26A14%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH RFC 04/25] Replace "/" operand with div64
Thread-Index: Acy0RCyemylbkJbrQ06B4H2HTZu+wAAZifiAAAWB624=
In-Reply-To: <BC00F5384FCFC9499AF06F92E8B78A9E287D4A0E53@shsmsx502.ccr.corp.intel.com>
Mime-version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>, Tim Deegan <Tim.Deegan@citrix.com>
Subject: Re: [Xen-devel] [PATCH RFC 04/25] Replace "/" operand with div64
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Also, I assume the gcc arm target can at least do 64-bit arithmetic via
library calls, which you could then implement in arch/arm. __divdi3 etc.
Perhaps you intend to do this anyway and do_div() here is a bandaid.

 -- Keir

On 07/12/2011 07:00, "Zhang, Xiantao" <xiantao.zhang@intel.com> wrote:

> Hi, Stefano 
> Great work from you guys!  One quick comment:  Just found the below logic's
> change maybe wrong and probably  break current things.
> Original logic is  A+B -(C%D), but it is changed to  (A+B-C)%D,  so if it is
> not an intended fix, it should be an issue.
> Thanks!
> Xiantao  
> 
>> diff --git a/xen/common/timer.c b/xen/common/timer.c index 0547ea3..043250e
>> 100644
>> --- a/xen/common/timer.c
>> +++ b/xen/common/timer.c
>> @@ -23,6 +23,7 @@
>> #include <xen/symbols.h>
>> #include <asm/system.h>
>> #include <asm/desc.h>
>> +#include <asm/div64.h>
>> #include <asm/atomic.h>
>> 
>> /* We program the time hardware this far behind the closest deadline. */ @@
>> -503,16 +504,18 @@ static void timer_softirq_action(void)
>> 
>> s_time_t align_timer(s_time_t firsttick, uint64_t period)  {
>> +    uint64_t n;
>>    if ( !period )
>>        return firsttick;
>  
>> -    return firsttick + (period - 1) - ((firsttick - 1) % period);
>> +    n = firsttick + (period - 1) - (firsttick - 1);
>> +    return do_div(n, period);
>> }
>  
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 09:17:59 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 09: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.xensource.com>)
	id 1RYDdG-0003Ek-UF; Wed, 07 Dec 2011 09:17:42 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RYDdG-0003Ea-6N
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 09:17:42 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1323249414!5285708!1
X-Originating-IP: [74.125.83.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16525 invoked from network); 7 Dec 2011 09:16:55 -0000
Received: from mail-ee0-f43.google.com (HELO mail-ee0-f43.google.com)
	(74.125.83.43)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Dec 2011 09:16:55 -0000
Received: by eekd49 with SMTP id d49so1417281eek.30
	for <xen-devel@lists.xensource.com>;
	Wed, 07 Dec 2011 01:16:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=3nFHYJ4zo86z55+/qV2kPDxAIzGic5ZX1kDxF1/jCu4=;
	b=SLOtWgCedGDvclqEDx06TcSWKXOHKdqUdgKqV9XG4CNYNROKWprSXayWxrk3nk0lS5
	UWxxo6ff4f6I4WB/h71aljfB0W8FKTHRDMhQN43MQ8gt4ukksolraCGMY0Z0SZXRXUIk
	9LU+buWyILx3KQeQtjypEtdKuj34X7dgPji/c=
Received: by 10.14.7.206 with SMTP id 54mr1033186eep.37.1323249414682;
	Wed, 07 Dec 2011 01:16:54 -0800 (PST)
Received: from [192.168.1.70]
	(host81-155-119-104.range81-155.btcentralplus.com. [81.155.119.104])
	by mx.google.com with ESMTPS id fg16sm1360098bkb.16.2011.12.07.01.16.52
	(version=SSLv3 cipher=OTHER); Wed, 07 Dec 2011 01:16:53 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Wed, 07 Dec 2011 09:16:48 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: "Zhang, Xiantao" <xiantao.zhang@intel.com>,
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>, 
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Message-ID: <CB04DF80.26A1E%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH RFC 04/25] Replace "/" operand with div64
Thread-Index: Acy0RCyemylbkJbrQ06B4H2HTZu+wAAZifiAAAWB624AACWNYw==
In-Reply-To: <CB04DE84.26A14%keir.xen@gmail.com>
Mime-version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>, Tim Deegan <Tim.Deegan@citrix.com>
Subject: Re: [Xen-devel] [PATCH RFC 04/25] Replace "/" operand with div64
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 07/12/2011 09:12, "Keir Fraser" <keir.xen@gmail.com> wrote:

> Also, I assume the gcc arm target can at least do 64-bit arithmetic via
> library calls, which you could then implement in arch/arm. __divdi3 etc.
> Perhaps you intend to do this anyway and do_div() here is a bandaid.

Of course we already implement __divdi3/__udivdi3 in common/lib.c. That
should already have been sufficient so not sure why this timer.c change
would be needed at all?

>  -- Keir
> 
> On 07/12/2011 07:00, "Zhang, Xiantao" <xiantao.zhang@intel.com> wrote:
> 
>> Hi, Stefano 
>> Great work from you guys!  One quick comment:  Just found the below logic's
>> change maybe wrong and probably  break current things.
>> Original logic is  A+B -(C%D), but it is changed to  (A+B-C)%D,  so if it is
>> not an intended fix, it should be an issue.
>> Thanks!
>> Xiantao  
>> 
>>> diff --git a/xen/common/timer.c b/xen/common/timer.c index 0547ea3..043250e
>>> 100644
>>> --- a/xen/common/timer.c
>>> +++ b/xen/common/timer.c
>>> @@ -23,6 +23,7 @@
>>> #include <xen/symbols.h>
>>> #include <asm/system.h>
>>> #include <asm/desc.h>
>>> +#include <asm/div64.h>
>>> #include <asm/atomic.h>
>>> 
>>> /* We program the time hardware this far behind the closest deadline. */ @@
>>> -503,16 +504,18 @@ static void timer_softirq_action(void)
>>> 
>>> s_time_t align_timer(s_time_t firsttick, uint64_t period)  {
>>> +    uint64_t n;
>>>    if ( !period )
>>>        return firsttick;
>>  
>>> -    return firsttick + (period - 1) - ((firsttick - 1) % period);
>>> +    n = firsttick + (period - 1) - (firsttick - 1);
>>> +    return do_div(n, period);
>>> }
>>  
>> 
>> 
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 09:17:59 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 09: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.xensource.com>)
	id 1RYDdG-0003Ek-UF; Wed, 07 Dec 2011 09:17:42 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RYDdG-0003Ea-6N
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 09:17:42 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1323249414!5285708!1
X-Originating-IP: [74.125.83.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16525 invoked from network); 7 Dec 2011 09:16:55 -0000
Received: from mail-ee0-f43.google.com (HELO mail-ee0-f43.google.com)
	(74.125.83.43)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Dec 2011 09:16:55 -0000
Received: by eekd49 with SMTP id d49so1417281eek.30
	for <xen-devel@lists.xensource.com>;
	Wed, 07 Dec 2011 01:16:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=3nFHYJ4zo86z55+/qV2kPDxAIzGic5ZX1kDxF1/jCu4=;
	b=SLOtWgCedGDvclqEDx06TcSWKXOHKdqUdgKqV9XG4CNYNROKWprSXayWxrk3nk0lS5
	UWxxo6ff4f6I4WB/h71aljfB0W8FKTHRDMhQN43MQ8gt4ukksolraCGMY0Z0SZXRXUIk
	9LU+buWyILx3KQeQtjypEtdKuj34X7dgPji/c=
Received: by 10.14.7.206 with SMTP id 54mr1033186eep.37.1323249414682;
	Wed, 07 Dec 2011 01:16:54 -0800 (PST)
Received: from [192.168.1.70]
	(host81-155-119-104.range81-155.btcentralplus.com. [81.155.119.104])
	by mx.google.com with ESMTPS id fg16sm1360098bkb.16.2011.12.07.01.16.52
	(version=SSLv3 cipher=OTHER); Wed, 07 Dec 2011 01:16:53 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Wed, 07 Dec 2011 09:16:48 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: "Zhang, Xiantao" <xiantao.zhang@intel.com>,
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>, 
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Message-ID: <CB04DF80.26A1E%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH RFC 04/25] Replace "/" operand with div64
Thread-Index: Acy0RCyemylbkJbrQ06B4H2HTZu+wAAZifiAAAWB624AACWNYw==
In-Reply-To: <CB04DE84.26A14%keir.xen@gmail.com>
Mime-version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>, Tim Deegan <Tim.Deegan@citrix.com>
Subject: Re: [Xen-devel] [PATCH RFC 04/25] Replace "/" operand with div64
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 07/12/2011 09:12, "Keir Fraser" <keir.xen@gmail.com> wrote:

> Also, I assume the gcc arm target can at least do 64-bit arithmetic via
> library calls, which you could then implement in arch/arm. __divdi3 etc.
> Perhaps you intend to do this anyway and do_div() here is a bandaid.

Of course we already implement __divdi3/__udivdi3 in common/lib.c. That
should already have been sufficient so not sure why this timer.c change
would be needed at all?

>  -- Keir
> 
> On 07/12/2011 07:00, "Zhang, Xiantao" <xiantao.zhang@intel.com> wrote:
> 
>> Hi, Stefano 
>> Great work from you guys!  One quick comment:  Just found the below logic's
>> change maybe wrong and probably  break current things.
>> Original logic is  A+B -(C%D), but it is changed to  (A+B-C)%D,  so if it is
>> not an intended fix, it should be an issue.
>> Thanks!
>> Xiantao  
>> 
>>> diff --git a/xen/common/timer.c b/xen/common/timer.c index 0547ea3..043250e
>>> 100644
>>> --- a/xen/common/timer.c
>>> +++ b/xen/common/timer.c
>>> @@ -23,6 +23,7 @@
>>> #include <xen/symbols.h>
>>> #include <asm/system.h>
>>> #include <asm/desc.h>
>>> +#include <asm/div64.h>
>>> #include <asm/atomic.h>
>>> 
>>> /* We program the time hardware this far behind the closest deadline. */ @@
>>> -503,16 +504,18 @@ static void timer_softirq_action(void)
>>> 
>>> s_time_t align_timer(s_time_t firsttick, uint64_t period)  {
>>> +    uint64_t n;
>>>    if ( !period )
>>>        return firsttick;
>>  
>>> -    return firsttick + (period - 1) - ((firsttick - 1) % period);
>>> +    n = firsttick + (period - 1) - (firsttick - 1);
>>> +    return do_div(n, period);
>>> }
>>  
>> 
>> 
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 09:19:07 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 09:19:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYDeM-0003J9-Dk; Wed, 07 Dec 2011 09:18:50 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RYDeL-0003Iz-5r
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 09:18:49 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1323249449!46881589!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjA3NQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18815 invoked from network); 7 Dec 2011 09:17:30 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Dec 2011 09:17:30 -0000
X-IronPort-AV: E=Sophos;i="4.71,313,1320624000"; 
   d="scan'208";a="9335718"
Received: from lonpmailmx02.citrite.net ([10.30.203.163])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Dec 2011 09:17:38 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.161]) by
	LONPMAILMX02.citrite.net ([10.30.203.163]) with mapi; Wed, 7 Dec 2011
	09:17:38 +0000
From: Paul Durrant <Paul.Durrant@citrix.com>
To: "rshriram@cs.ubc.ca" <rshriram@cs.ubc.ca>
Date: Wed, 7 Dec 2011 09:17:46 +0000
Thread-Topic: [Xen-devel] [PATCH] VM generation ID save/restore and migrate
Thread-Index: Acy0UXmzRFVoscLDSbyDtEvmI1m17QAb022w
Message-ID: <291EDFCB1E9E224A99088639C4762022B5988E543C@LONPMAILBOX01.citrite.net>
References: <152a79fbe918d8a6c63a.1323079622@cosworth.uk.xensource.com>
	<CAP8mzPOSQePUySZirCLTh6K_uJ3pj3ws=4KR0y-ybFKObk0yGw@mail.gmail.com>
In-Reply-To: <CAP8mzPOSQePUySZirCLTh6K_uJ3pj3ws=4KR0y-ybFKObk0yGw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] VM generation ID save/restore and migrate
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

De-html-ing (again)...

--
There is a "if ( (argc != 8) && (argc != 9) ) err()" condition and then
there is "if (argc >= 10)".
--

Yes, good catch. I will fix and re-send.

  Paul

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 09:19:07 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 09:19:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYDeM-0003J9-Dk; Wed, 07 Dec 2011 09:18:50 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RYDeL-0003Iz-5r
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 09:18:49 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1323249449!46881589!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjA3NQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18815 invoked from network); 7 Dec 2011 09:17:30 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Dec 2011 09:17:30 -0000
X-IronPort-AV: E=Sophos;i="4.71,313,1320624000"; 
   d="scan'208";a="9335718"
Received: from lonpmailmx02.citrite.net ([10.30.203.163])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Dec 2011 09:17:38 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.161]) by
	LONPMAILMX02.citrite.net ([10.30.203.163]) with mapi; Wed, 7 Dec 2011
	09:17:38 +0000
From: Paul Durrant <Paul.Durrant@citrix.com>
To: "rshriram@cs.ubc.ca" <rshriram@cs.ubc.ca>
Date: Wed, 7 Dec 2011 09:17:46 +0000
Thread-Topic: [Xen-devel] [PATCH] VM generation ID save/restore and migrate
Thread-Index: Acy0UXmzRFVoscLDSbyDtEvmI1m17QAb022w
Message-ID: <291EDFCB1E9E224A99088639C4762022B5988E543C@LONPMAILBOX01.citrite.net>
References: <152a79fbe918d8a6c63a.1323079622@cosworth.uk.xensource.com>
	<CAP8mzPOSQePUySZirCLTh6K_uJ3pj3ws=4KR0y-ybFKObk0yGw@mail.gmail.com>
In-Reply-To: <CAP8mzPOSQePUySZirCLTh6K_uJ3pj3ws=4KR0y-ybFKObk0yGw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] VM generation ID save/restore and migrate
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

De-html-ing (again)...

--
There is a "if ( (argc != 8) && (argc != 9) ) err()" condition and then
there is "if (argc >= 10)".
--

Yes, good catch. I will fix and re-send.

  Paul

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 09:24:28 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 09:24:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYDja-0003cJ-EZ; Wed, 07 Dec 2011 09:24:14 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RYDjZ-0003c5-62
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 09:24:13 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1323249805!7262223!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM1ODk=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29806 invoked from network); 7 Dec 2011 09:23:26 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-3.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 7 Dec 2011 09:23:26 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 07 Dec 2011 09:23:25 +0000
Message-Id: <4EDF3EC70200007800065E3B@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 07 Dec 2011 09:24:07 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Stefano Stabellini" <stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1112061753410.31179@kaball-desktop>
	<1323195609-17277-4-git-send-email-stefano.stabellini@eu.citrix.com>
In-Reply-To: <1323195609-17277-4-git-send-email-stefano.stabellini@eu.citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com, Ian Campbell <ian.campbell@citrix.com>,
	Tim.Deegan@citrix.com
Subject: Re: [Xen-devel] [PATCH RFC 04/25] Replace "/" operand with div64
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 06.12.11 at 19:19, <stefano.stabellini@eu.citrix.com> wrote:
> ARM does not have a division operator: division has to be implemented
> in software.
> On x86 and ia64 div64 falls back to a do_div based implementation.

But this needs to be done carefully and correctly - there's no
one-fits-all div64() implementation.

> --- a/xen/common/sched_sedf.c
> +++ b/xen/common/sched_sedf.c
> @@ -127,7 +128,7 @@ struct sedf_cpu_info {
>  
>  #define PERIOD_BEGIN(inf) ((inf)->deadl_abs - (inf)->period)
>  
> -#define DIV_UP(x,y) (((x) + (y) - 1) / y)
> +#define DIV_UP(x,y) div64((x) + (y) - 1, y)

There are uses of this with y being s_time_t.

>  #define extra_runs(inf)      ((inf->status) & 6)
>  #define extra_get_cur_q(inf) (((inf->status & 6) >> 1)-1)
> @@ -678,8 +679,7 @@ static void desched_extra_dom(s_time_t now, struct vcpu *d)
>            utilization and is used somewhat incremental!*/
>          if ( !inf->extraweight )
>              /*NB: use fixed point arithmetic with 10 bits*/
> -            inf->score[EXTRA_UTIL_Q] = (inf->period << 10) /
> -                inf->slice;
> +            inf->score[EXTRA_UTIL_Q] = div64(inf->period << 10, inf->slice);

inf->slice is s_time_t, i.e. 64-bit (and signed, but that's not relevant here).

>          else
>              /*conversion between realtime utilisation and extrawieght:
>                full (ie 100%) utilization is equivalent to 128 extraweight*/
> @@ -996,8 +996,8 @@ static void unblock_short_extra_support(
>    
>          if ( inf->short_block_lost_tot )
>          {
> -            inf->score[0] = (inf->period << 10) /
> -                inf->short_block_lost_tot;
> +            inf->score[0] = div64(inf->period << 10,
> +                                     inf->short_block_lost_tot);

inf->short_block_lost_tot is s_time_t, too.

>  #ifdef SEDF_STATS
>              inf->pen_extra_blocks++;
>  #endif
> @@ -1224,8 +1224,8 @@ static void sedf_dump_domain(struct vcpu *d)
>      
>  #ifdef SEDF_STATS
>      if ( EDOM_INFO(d)->block_time_tot != 0 )
> -        printk(" pen=%"PRIu64"%%", (EDOM_INFO(d)->penalty_time_tot * 100) /
> -               EDOM_INFO(d)->block_time_tot);
> +        printk(" pen=%"PRIu64"%%",
> +               div64(EDOM_INFO(d)->penalty_time_tot * 100, EDOM_INFO(d)->block_time_tot));

As is ->block_time_tot.

>      if ( EDOM_INFO(d)->block_tot != 0 )
>          printk("\n   blks=%u sh=%u (%u%%) (shc=%u (%u%%) shex=%i "\
>                 "shexsl=%i) l=%u (%u%%) avg: b=%"PRIu64" p=%"PRIu64"",
> @@ -1357,9 +1357,9 @@ static int sedf_adjust_weights(struct cpupool *c, 
> struct xen_domctl_scheduler_op
>                  /*check for overflows*/
>                  ASSERT((WEIGHT_PERIOD < ULONG_MAX) 
>                         && (EDOM_INFO(p)->slice_orig < ULONG_MAX));
> -                sumt[cpu] += 
> -                    (WEIGHT_PERIOD * EDOM_INFO(p)->slice_orig) / 
> -                    EDOM_INFO(p)->period_orig;
> +                sumt[cpu] += div64(
> +                    WEIGHT_PERIOD * EDOM_INFO(p)->slice_orig,
> +                    EDOM_INFO(p)->period_orig);

And ->period_orig.

>              }
>          }
>      }
> --- a/xen/common/timer.c
> +++ b/xen/common/timer.c
> @@ -503,16 +504,18 @@ static void timer_softirq_action(void)
>  
>  s_time_t align_timer(s_time_t firsttick, uint64_t period)
>  {
> +    uint64_t n;

    uint64_t n = firsttick - 1;

>      if ( !period )
>          return firsttick;
>  
> -    return firsttick + (period - 1) - ((firsttick - 1) % period);
> +    n = firsttick + (period - 1) - (firsttick - 1);
> +    return do_div(n, period);

    return firsttick + (period - 1) - do_div(n, period);

But again period is a 64-bit value, so using do_div() isn't correct
here.

>  }
>  
>  static void dump_timer(struct timer *t, s_time_t now)
> --- a/xen/include/asm-ia64/linux/asm-generic/div64.h
> +++ b/xen/include/asm-ia64/linux/asm-generic/div64.h
> @@ -55,4 +55,10 @@ extern uint32_t __div64_32(uint64_t *dividend, uint32_t 
> divisor);
>  
>  #endif /* BITS_PER_LONG */
>  
> +static inline uint64_t div64(uint64_t n, uint32_t base)

Return value type ought to be uint32_t for this particular flavor. More
flavors (64-bit divisor, signed divisor) may/will be needed.

> +{
> +	do_div(n, base);
> +	return n;
> +}
> +
>  #endif /* _ASM_GENERIC_DIV64_H */
> --- a/xen/include/asm-x86/div64.h
> +++ b/xen/include/asm-x86/div64.h
> @@ -46,4 +46,10 @@
>  
>  #endif
>  
> +static inline uint64_t div64(uint64_t n, uint32_t base)

Same here.

> +{
> +	do_div(n, base);
> +	return n;
> +}
> +
>  #endif

Did you really test this in its current shape on x86 (32-bit and 64-bit)?

Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 09:24:28 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 09:24:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYDja-0003cJ-EZ; Wed, 07 Dec 2011 09:24:14 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RYDjZ-0003c5-62
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 09:24:13 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1323249805!7262223!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM1ODk=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29806 invoked from network); 7 Dec 2011 09:23:26 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-3.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 7 Dec 2011 09:23:26 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 07 Dec 2011 09:23:25 +0000
Message-Id: <4EDF3EC70200007800065E3B@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 07 Dec 2011 09:24:07 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Stefano Stabellini" <stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1112061753410.31179@kaball-desktop>
	<1323195609-17277-4-git-send-email-stefano.stabellini@eu.citrix.com>
In-Reply-To: <1323195609-17277-4-git-send-email-stefano.stabellini@eu.citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com, Ian Campbell <ian.campbell@citrix.com>,
	Tim.Deegan@citrix.com
Subject: Re: [Xen-devel] [PATCH RFC 04/25] Replace "/" operand with div64
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 06.12.11 at 19:19, <stefano.stabellini@eu.citrix.com> wrote:
> ARM does not have a division operator: division has to be implemented
> in software.
> On x86 and ia64 div64 falls back to a do_div based implementation.

But this needs to be done carefully and correctly - there's no
one-fits-all div64() implementation.

> --- a/xen/common/sched_sedf.c
> +++ b/xen/common/sched_sedf.c
> @@ -127,7 +128,7 @@ struct sedf_cpu_info {
>  
>  #define PERIOD_BEGIN(inf) ((inf)->deadl_abs - (inf)->period)
>  
> -#define DIV_UP(x,y) (((x) + (y) - 1) / y)
> +#define DIV_UP(x,y) div64((x) + (y) - 1, y)

There are uses of this with y being s_time_t.

>  #define extra_runs(inf)      ((inf->status) & 6)
>  #define extra_get_cur_q(inf) (((inf->status & 6) >> 1)-1)
> @@ -678,8 +679,7 @@ static void desched_extra_dom(s_time_t now, struct vcpu *d)
>            utilization and is used somewhat incremental!*/
>          if ( !inf->extraweight )
>              /*NB: use fixed point arithmetic with 10 bits*/
> -            inf->score[EXTRA_UTIL_Q] = (inf->period << 10) /
> -                inf->slice;
> +            inf->score[EXTRA_UTIL_Q] = div64(inf->period << 10, inf->slice);

inf->slice is s_time_t, i.e. 64-bit (and signed, but that's not relevant here).

>          else
>              /*conversion between realtime utilisation and extrawieght:
>                full (ie 100%) utilization is equivalent to 128 extraweight*/
> @@ -996,8 +996,8 @@ static void unblock_short_extra_support(
>    
>          if ( inf->short_block_lost_tot )
>          {
> -            inf->score[0] = (inf->period << 10) /
> -                inf->short_block_lost_tot;
> +            inf->score[0] = div64(inf->period << 10,
> +                                     inf->short_block_lost_tot);

inf->short_block_lost_tot is s_time_t, too.

>  #ifdef SEDF_STATS
>              inf->pen_extra_blocks++;
>  #endif
> @@ -1224,8 +1224,8 @@ static void sedf_dump_domain(struct vcpu *d)
>      
>  #ifdef SEDF_STATS
>      if ( EDOM_INFO(d)->block_time_tot != 0 )
> -        printk(" pen=%"PRIu64"%%", (EDOM_INFO(d)->penalty_time_tot * 100) /
> -               EDOM_INFO(d)->block_time_tot);
> +        printk(" pen=%"PRIu64"%%",
> +               div64(EDOM_INFO(d)->penalty_time_tot * 100, EDOM_INFO(d)->block_time_tot));

As is ->block_time_tot.

>      if ( EDOM_INFO(d)->block_tot != 0 )
>          printk("\n   blks=%u sh=%u (%u%%) (shc=%u (%u%%) shex=%i "\
>                 "shexsl=%i) l=%u (%u%%) avg: b=%"PRIu64" p=%"PRIu64"",
> @@ -1357,9 +1357,9 @@ static int sedf_adjust_weights(struct cpupool *c, 
> struct xen_domctl_scheduler_op
>                  /*check for overflows*/
>                  ASSERT((WEIGHT_PERIOD < ULONG_MAX) 
>                         && (EDOM_INFO(p)->slice_orig < ULONG_MAX));
> -                sumt[cpu] += 
> -                    (WEIGHT_PERIOD * EDOM_INFO(p)->slice_orig) / 
> -                    EDOM_INFO(p)->period_orig;
> +                sumt[cpu] += div64(
> +                    WEIGHT_PERIOD * EDOM_INFO(p)->slice_orig,
> +                    EDOM_INFO(p)->period_orig);

And ->period_orig.

>              }
>          }
>      }
> --- a/xen/common/timer.c
> +++ b/xen/common/timer.c
> @@ -503,16 +504,18 @@ static void timer_softirq_action(void)
>  
>  s_time_t align_timer(s_time_t firsttick, uint64_t period)
>  {
> +    uint64_t n;

    uint64_t n = firsttick - 1;

>      if ( !period )
>          return firsttick;
>  
> -    return firsttick + (period - 1) - ((firsttick - 1) % period);
> +    n = firsttick + (period - 1) - (firsttick - 1);
> +    return do_div(n, period);

    return firsttick + (period - 1) - do_div(n, period);

But again period is a 64-bit value, so using do_div() isn't correct
here.

>  }
>  
>  static void dump_timer(struct timer *t, s_time_t now)
> --- a/xen/include/asm-ia64/linux/asm-generic/div64.h
> +++ b/xen/include/asm-ia64/linux/asm-generic/div64.h
> @@ -55,4 +55,10 @@ extern uint32_t __div64_32(uint64_t *dividend, uint32_t 
> divisor);
>  
>  #endif /* BITS_PER_LONG */
>  
> +static inline uint64_t div64(uint64_t n, uint32_t base)

Return value type ought to be uint32_t for this particular flavor. More
flavors (64-bit divisor, signed divisor) may/will be needed.

> +{
> +	do_div(n, base);
> +	return n;
> +}
> +
>  #endif /* _ASM_GENERIC_DIV64_H */
> --- a/xen/include/asm-x86/div64.h
> +++ b/xen/include/asm-x86/div64.h
> @@ -46,4 +46,10 @@
>  
>  #endif
>  
> +static inline uint64_t div64(uint64_t n, uint32_t base)

Same here.

> +{
> +	do_div(n, base);
> +	return n;
> +}
> +
>  #endif

Did you really test this in its current shape on x86 (32-bit and 64-bit)?

Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 09:28:43 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 09:28:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYDni-0003kX-51; Wed, 07 Dec 2011 09:28:30 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RYDng-0003kO-Au
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 09:28:28 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-13.tower-216.messagelabs.com!1323250061!5888155!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMzEwMTc=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMzEwMTc=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 579 invoked from network); 7 Dec 2011 09:27:41 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-13.tower-216.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 7 Dec 2011 09:27:41 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1323250061; l=2091;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=CtDYzXpDqFQOBd4zw5J/O8LR8ks=;
	b=v3/P3hMhP/CkORBQkRVtDA1ESofWaksgNA8ZyyuE+Fniks8CqL/D31zF5zw0frInG2j
	5eME/+2rtIjir48FjH9VPRSD6GnORdgZtQ6bE1KzRWCOaer9uNHcVEp2zy71i0a0llObe
	vVj9Mn1F/J/Uc441qTx79MKk8uDSxh7n/vg=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/ll3s7qGpVx
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-087-188.pools.arcor-ip.net [84.57.87.188])
	by post.strato.de (mrclete mo19) (RZmta 26.10 AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id C01b3bnB799JDF ;
	Wed, 7 Dec 2011 10:27:38 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id DD6EB18637; Wed,  7 Dec 2011 10:27:37 +0100 (CET)
Date: Wed, 7 Dec 2011 10:27:37 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20111207092737.GA24563@aepfle.de>
References: <mailman.3467.1323191271.12970.xen-devel@lists.xensource.com>
	<78bcef1bbb35c6176c138c1a6089f034.squirrel@webmail.lagarcavilla.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <78bcef1bbb35c6176c138c1a6089f034.squirrel@webmail.lagarcavilla.org>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 2 of 5] xenpaging: map gfn before nomination
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Dec 06, Andres Lagar-Cavilla wrote:

> Ouch! You're absolutely tying the user space pager with the underlying xen
> paging code. Most of your patches change the tools and the hypervisor in
> lockstep.

Yes, pager and hypervisor are bound closely together.

> Patch 4 in your series is one such case. Short-cutting the state machine:
> great. But what is the gain for the hypervisor in *not* sending the
> EVICT_FAIL event. It's a good thing. It keeps the same interface to
> user-space. Xenpaging may not need it, but the Xen paging code does not
> exist solely for xenpaging.

What IS the need to send yet another request? It adds just overhead for
no obvious need. Please show the code that will benefit from the extra
EVICT_FAIL message.

> Patch 1 is also a problem. I don't buy that we can number interfaces, and
> then only support the tip ("Sorry, ENOEXEC, dig out an older hypervisor").
> Either we bite the bullet of some level of backwards compatibility with
> all its messiness, or we just keep it in flux until there is convergence
> on a major "barrier".

An out-of-tree pager can very well try to support a number of
hypervisors, perhaps patch #1 can be extended to report the age in some
way. But why would the upstream pager care about (development!) state
from the past?


> This current patch 2 is also rather gratuitous. The need to map before
> nominate feels superfluous. If Xen cannot deal with nomination requests on
> pages that have not been mapped, then we've broken Xen.

Why? It was broken (or rather: not optimal) in the first place.
Any attempt to map a gfn in any  paging state has to return -ENOENT
right away. The pager is certainly a special case, and thanks to this
change, and your change for the page-in part, the special handling can now
get removed.

> Anyway, I hope my message gets across. I'm not trying to organize a
> blockade on your code. I'm trying to get to the best possible hypervisor
> paging support we can.

Great.
Then please improve tools/xenpaging/, thats the cure for NIH.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 09:28:43 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 09:28:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYDni-0003kX-51; Wed, 07 Dec 2011 09:28:30 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RYDng-0003kO-Au
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 09:28:28 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-13.tower-216.messagelabs.com!1323250061!5888155!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMzEwMTc=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMzEwMTc=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 579 invoked from network); 7 Dec 2011 09:27:41 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-13.tower-216.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 7 Dec 2011 09:27:41 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1323250061; l=2091;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=CtDYzXpDqFQOBd4zw5J/O8LR8ks=;
	b=v3/P3hMhP/CkORBQkRVtDA1ESofWaksgNA8ZyyuE+Fniks8CqL/D31zF5zw0frInG2j
	5eME/+2rtIjir48FjH9VPRSD6GnORdgZtQ6bE1KzRWCOaer9uNHcVEp2zy71i0a0llObe
	vVj9Mn1F/J/Uc441qTx79MKk8uDSxh7n/vg=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/ll3s7qGpVx
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-087-188.pools.arcor-ip.net [84.57.87.188])
	by post.strato.de (mrclete mo19) (RZmta 26.10 AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id C01b3bnB799JDF ;
	Wed, 7 Dec 2011 10:27:38 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id DD6EB18637; Wed,  7 Dec 2011 10:27:37 +0100 (CET)
Date: Wed, 7 Dec 2011 10:27:37 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20111207092737.GA24563@aepfle.de>
References: <mailman.3467.1323191271.12970.xen-devel@lists.xensource.com>
	<78bcef1bbb35c6176c138c1a6089f034.squirrel@webmail.lagarcavilla.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <78bcef1bbb35c6176c138c1a6089f034.squirrel@webmail.lagarcavilla.org>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 2 of 5] xenpaging: map gfn before nomination
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Dec 06, Andres Lagar-Cavilla wrote:

> Ouch! You're absolutely tying the user space pager with the underlying xen
> paging code. Most of your patches change the tools and the hypervisor in
> lockstep.

Yes, pager and hypervisor are bound closely together.

> Patch 4 in your series is one such case. Short-cutting the state machine:
> great. But what is the gain for the hypervisor in *not* sending the
> EVICT_FAIL event. It's a good thing. It keeps the same interface to
> user-space. Xenpaging may not need it, but the Xen paging code does not
> exist solely for xenpaging.

What IS the need to send yet another request? It adds just overhead for
no obvious need. Please show the code that will benefit from the extra
EVICT_FAIL message.

> Patch 1 is also a problem. I don't buy that we can number interfaces, and
> then only support the tip ("Sorry, ENOEXEC, dig out an older hypervisor").
> Either we bite the bullet of some level of backwards compatibility with
> all its messiness, or we just keep it in flux until there is convergence
> on a major "barrier".

An out-of-tree pager can very well try to support a number of
hypervisors, perhaps patch #1 can be extended to report the age in some
way. But why would the upstream pager care about (development!) state
from the past?


> This current patch 2 is also rather gratuitous. The need to map before
> nominate feels superfluous. If Xen cannot deal with nomination requests on
> pages that have not been mapped, then we've broken Xen.

Why? It was broken (or rather: not optimal) in the first place.
Any attempt to map a gfn in any  paging state has to return -ENOENT
right away. The pager is certainly a special case, and thanks to this
change, and your change for the page-in part, the special handling can now
get removed.

> Anyway, I hope my message gets across. I'm not trying to organize a
> blockade on your code. I'm trying to get to the best possible hypervisor
> paging support we can.

Great.
Then please improve tools/xenpaging/, thats the cure for NIH.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 09:40:18 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 09:40:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYDyk-0003yQ-H9; Wed, 07 Dec 2011 09:39:54 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RYDyi-0003yL-HL
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 09:39:53 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1323250743!6217730!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjk1NTQ=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24872 invoked from network); 7 Dec 2011 09:39:05 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Dec 2011 09:39:05 -0000
X-IronPort-AV: E=Sophos;i="4.71,313,1320642000"; d="scan'208";a="173207633"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Dec 2011 04:39:01 -0500
Received: from cosworth.uk.xensource.com (10.80.16.52) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 7 Dec 2011 04:39:01 -0500
MIME-Version: 1.0
X-Mercurial-Node: 9eaac880f504a12c145d72a96d789dbcff33d624
Message-ID: <9eaac880f504a12c145d.1323250728@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Wed, 7 Dec 2011 09:38:48 +0000
From: Paul Durrant <paul.durrant@citrix.com>
To: xen-devel@lists.xensource.com
Cc: paul.durrant@citrix.com
Subject: [Xen-devel] [PATCH] VM generation ID save/restore and migrate
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Paul Durrant <paul.durrant@citrix.com>
# Date 1323250567 0
# Node ID 9eaac880f504a12c145d72a96d789dbcff33d624
# Parent  38eb74c01d9d9afacdf0c79fcb5555d99719dfa5
VM generation ID save/restore and migrate.

Add code to track the address of the VM generation id buffer across a
save/restore or migrate and increment it as necessary.
The address of the buffer is written into xenstore by hvmloader at
boot time. It must be read from xenstore by the caller of
xc_domain_save() and then written back again by the caller of
xc_domain_restore().

Signed-off-by: Paul Durrant <paul.durrant@citrix.com>

diff -r 38eb74c01d9d -r 9eaac880f504 tools/libxc/ia64/xc_ia64_linux_restore.c
--- a/tools/libxc/ia64/xc_ia64_linux_restore.c	Tue Dec 06 21:16:56 2011 +0000
+++ b/tools/libxc/ia64/xc_ia64_linux_restore.c	Wed Dec 07 09:36:07 2011 +0000
@@ -548,7 +548,8 @@ int
 xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
                   unsigned int store_evtchn, unsigned long *store_mfn,
                   unsigned int console_evtchn, unsigned long *console_mfn,
-                  unsigned int hvm, unsigned int pae, int superpages)
+                  unsigned int hvm, unsigned int pae, int superpages,
+                  int increment_gid, unsigned long *vm_gid_addr)
 {
     DECLARE_DOMCTL;
     int rc = 1;
diff -r 38eb74c01d9d -r 9eaac880f504 tools/libxc/ia64/xc_ia64_linux_save.c
--- a/tools/libxc/ia64/xc_ia64_linux_save.c	Tue Dec 06 21:16:56 2011 +0000
+++ b/tools/libxc/ia64/xc_ia64_linux_save.c	Wed Dec 07 09:36:07 2011 +0000
@@ -382,7 +382,8 @@ out:
 int
 xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iters,
                uint32_t max_factor, uint32_t flags,
-               struct save_callbacks* callbacks, int hvm)
+               struct save_callbacks* callbacks, int hvm,
+               unsigned long vm_gid_addr)
 {
     DECLARE_DOMCTL;
     xc_dominfo_t info;
diff -r 38eb74c01d9d -r 9eaac880f504 tools/libxc/xc_domain_restore.c
--- a/tools/libxc/xc_domain_restore.c	Tue Dec 06 21:16:56 2011 +0000
+++ b/tools/libxc/xc_domain_restore.c	Wed Dec 07 09:36:07 2011 +0000
@@ -681,6 +681,7 @@ typedef struct {
     uint64_t console_pfn;
     uint64_t acpi_ioport_location;
     uint64_t viridian;
+    uint64_t vm_gid_addr;
 } pagebuf_t;
 
 static int pagebuf_init(pagebuf_t* buf)
@@ -860,6 +861,17 @@ static int pagebuf_get_one(xc_interface 
         }
         return compbuf_size;
 
+    case XC_SAVE_ID_HVM_GENERATION_ID_ADDR:
+        /* Skip padding 4 bytes then read the generation id buffer location. */
+        if ( RDEXACT(fd, &buf->vm_gid_addr, sizeof(uint32_t)) ||
+             RDEXACT(fd, &buf->vm_gid_addr, sizeof(uint64_t)) )
+        {
+            PERROR("error read the generation id buffer location");
+            return -1;
+        }
+        DPRINTF("read generation id buffer address");
+        return pagebuf_get_one(xch, ctx, buf, fd, dom);
+
     default:
         if ( (count > MAX_BATCH_SIZE) || (count < 0) ) {
             ERROR("Max batch size exceeded (%d). Giving up.", count);
@@ -1248,7 +1260,8 @@ static int apply_batch(xc_interface *xch
 int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
                       unsigned int store_evtchn, unsigned long *store_mfn,
                       unsigned int console_evtchn, unsigned long *console_mfn,
-                      unsigned int hvm, unsigned int pae, int superpages)
+                      unsigned int hvm, unsigned int pae, int superpages,
+                      int no_increment_gid, unsigned long *vm_gid_addr)
 {
     DECLARE_DOMCTL;
     int rc = 1, frc, i, j, n, m, pae_extended_cr3 = 0, ext_vcpucontext = 0;
@@ -1449,6 +1462,39 @@ int xc_domain_restore(xc_interface *xch,
                 xc_set_hvm_param(xch, dom, HVM_PARAM_VM86_TSS, pagebuf.vm86_tss);
             if ( pagebuf.console_pfn )
                 console_pfn = pagebuf.console_pfn;
+            if ( pagebuf.vm_gid_addr ) {
+                if ( !no_increment_gid ) {
+                    unsigned int offset;
+                    unsigned char *buf;
+                    unsigned long long gid;
+
+                    /*
+                     * Map the VM generation id buffer and inject the new value.
+                     */
+
+                    pfn = pagebuf.vm_gid_addr >> PAGE_SHIFT;
+                    offset = pagebuf.vm_gid_addr & (PAGE_SIZE - 1);
+                
+                    if ( (pfn >= dinfo->p2m_size) ||
+                         (pfn_type[pfn] != XEN_DOMCTL_PFINFO_NOTAB) )
+                    {
+                        ERROR("generation id buffer frame is bad");
+                        goto out;
+                    }
+
+                    mfn = ctx->p2m[pfn];
+                    buf = xc_map_foreign_range(xch, dom, PAGE_SIZE,
+                                               PROT_READ | PROT_WRITE, mfn);
+
+                    gid = *(unsigned long long *)(buf + offset);
+                    *(unsigned long long *)(buf + offset) = gid + 1;
+
+                    munmap(buf, PAGE_SIZE);
+                }
+
+                *vm_gid_addr = pagebuf.vm_gid_addr;
+            }
+
             break;  /* our work here is done */
         }
 
diff -r 38eb74c01d9d -r 9eaac880f504 tools/libxc/xc_domain_save.c
--- a/tools/libxc/xc_domain_save.c	Tue Dec 06 21:16:56 2011 +0000
+++ b/tools/libxc/xc_domain_save.c	Wed Dec 07 09:36:07 2011 +0000
@@ -804,7 +804,8 @@ static int save_tsc_info(xc_interface *x
 
 int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iters,
                    uint32_t max_factor, uint32_t flags,
-                   struct save_callbacks* callbacks, int hvm)
+                   struct save_callbacks* callbacks, int hvm,
+                   unsigned long vm_gid_addr)
 {
     xc_dominfo_t info;
     DECLARE_DOMCTL;
@@ -1616,6 +1617,16 @@ int xc_domain_save(xc_interface *xch, in
             uint64_t data;
         } chunk = { 0, };
 
+        chunk.id = XC_SAVE_ID_HVM_GENERATION_ID_ADDR;
+        chunk.data = vm_gid_addr;
+
+        if ( (chunk.data != 0) &&
+             wrexact(io_fd, &chunk, sizeof(chunk)) )
+        {
+            PERROR("Error when writing the generation id buffer location for guest");
+            goto out;
+        }
+
         chunk.id = XC_SAVE_ID_HVM_IDENT_PT;
         chunk.data = 0;
         xc_get_hvm_param(xch, dom, HVM_PARAM_IDENT_PT,
diff -r 38eb74c01d9d -r 9eaac880f504 tools/libxc/xenguest.h
--- a/tools/libxc/xenguest.h	Tue Dec 06 21:16:56 2011 +0000
+++ b/tools/libxc/xenguest.h	Wed Dec 07 09:36:07 2011 +0000
@@ -58,7 +58,8 @@ struct save_callbacks {
  */
 int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iters,
                    uint32_t max_factor, uint32_t flags /* XCFLAGS_xxx */,
-                   struct save_callbacks* callbacks, int hvm);
+                   struct save_callbacks* callbacks, int hvm,
+                   unsigned long vm_gid_addr);
 
 
 /**
@@ -72,12 +73,15 @@ int xc_domain_save(xc_interface *xch, in
  * @parm hvm non-zero if this is a HVM restore
  * @parm pae non-zero if this HVM domain has PAE support enabled
  * @parm superpages non-zero to allocate guest memory with superpages
+ * @parm gid the new generation id of the VM
+ * @parm vm_gid_addr returned with the address of the generation id buffer
  * @return 0 on success, -1 on failure
  */
 int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
                       unsigned int store_evtchn, unsigned long *store_mfn,
                       unsigned int console_evtchn, unsigned long *console_mfn,
-                      unsigned int hvm, unsigned int pae, int superpages);
+                      unsigned int hvm, unsigned int pae, int superpages,
+                      int increment_gid, unsigned long *vm_gid_addr);
 /**
  * xc_domain_restore writes a file to disk that contains the device
  * model saved state.
diff -r 38eb74c01d9d -r 9eaac880f504 tools/libxc/xg_save_restore.h
--- a/tools/libxc/xg_save_restore.h	Tue Dec 06 21:16:56 2011 +0000
+++ b/tools/libxc/xg_save_restore.h	Wed Dec 07 09:36:07 2011 +0000
@@ -253,6 +253,7 @@
 #define XC_SAVE_ID_HVM_VIRIDIAN       -11
 #define XC_SAVE_ID_COMPRESSED_DATA    -12 /* Marker to indicate arrival of compressed data */
 #define XC_SAVE_ID_ENABLE_COMPRESSION -13 /* Marker to enable compression logic at receiver side */
+#define XC_SAVE_ID_HVM_GENERATION_ID_ADDR -14
 
 /*
 ** We process save/restore/migrate in batches of pages; the below
diff -r 38eb74c01d9d -r 9eaac880f504 tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Tue Dec 06 21:16:56 2011 +0000
+++ b/tools/libxl/libxl_create.c	Wed Dec 07 09:36:07 2011 +0000
@@ -101,6 +101,7 @@ int libxl_init_build_info(libxl_ctx *ctx
         b_info->u.hvm.vpt_align = 1;
         b_info->u.hvm.timer_mode = 1;
         b_info->u.hvm.nested_hvm = 0;
+        b_info->u.hvm.no_increment_gid = 0;
         break;
     case LIBXL_DOMAIN_TYPE_PV:
         b_info->u.pv.slack_memkb = 8 * 1024;
diff -r 38eb74c01d9d -r 9eaac880f504 tools/libxl/libxl_dom.c
--- a/tools/libxl/libxl_dom.c	Tue Dec 06 21:16:56 2011 +0000
+++ b/tools/libxl/libxl_dom.c	Wed Dec 07 09:36:07 2011 +0000
@@ -125,7 +125,7 @@ int libxl__build_post(libxl__gc *gc, uin
     if (info->cpuid != NULL)
         libxl_cpuid_set(ctx, domid, info->cpuid);
 
-    ents = libxl__calloc(gc, 12 + (info->max_vcpus * 2) + 2, sizeof(char *));
+    ents = libxl__calloc(gc, 14 + (info->max_vcpus * 2) + 2, sizeof(char *));
     ents[0] = "memory/static-max";
     ents[1] = libxl__sprintf(gc, "%d", info->max_memkb);
     ents[2] = "memory/target";
@@ -138,9 +138,11 @@ int libxl__build_post(libxl__gc *gc, uin
     ents[9] = libxl__sprintf(gc, "%"PRIu32, state->store_port);
     ents[10] = "store/ring-ref";
     ents[11] = libxl__sprintf(gc, "%lu", state->store_mfn);
+    ents[12] = "data/generation-id";
+    ents[13] = libxl__sprintf(gc, "0x%lx", state->vm_gid_addr);
     for (i = 0; i < info->max_vcpus; i++) {
-        ents[12+(i*2)]   = libxl__sprintf(gc, "cpu/%d/availability", i);
-        ents[12+(i*2)+1] = (i && info->cur_vcpus && !(info->cur_vcpus & (1 << i)))
+        ents[14+(i*2)]   = libxl__sprintf(gc, "cpu/%d/availability", i);
+        ents[14+(i*2)+1] = (i && info->cur_vcpus && !(info->cur_vcpus & (1 << i)))
                             ? "offline" : "online";
     }
 
@@ -357,16 +359,19 @@ int libxl__domain_restore_common(libxl__
     /* read signature */
     int rc;
     int hvm, pae, superpages;
+    int no_increment_gid;
     switch (info->type) {
     case LIBXL_DOMAIN_TYPE_HVM:
         hvm = 1;
         superpages = 1;
         pae = info->u.hvm.pae;
+        no_increment_gid = info->u.hvm.no_increment_gid;
         break;
     case LIBXL_DOMAIN_TYPE_PV:
         hvm = 0;
         superpages = 0;
         pae = 1;
+        no_increment_gid = 0;
         break;
     default:
         return ERROR_INVAL;
@@ -374,7 +379,7 @@ int libxl__domain_restore_common(libxl__
     rc = xc_domain_restore(ctx->xch, fd, domid,
                            state->store_port, &state->store_mfn,
                            state->console_port, &state->console_mfn,
-                           hvm, pae, superpages);
+                           hvm, pae, superpages, no_increment_gid, &state->vm_gid_addr);
     if ( rc ) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "restoring domain");
         return ERROR_FAIL;
@@ -540,12 +545,22 @@ int libxl__domain_suspend_common(libxl__
     struct save_callbacks callbacks;
     struct suspendinfo si;
     int hvm, rc = ERROR_FAIL;
+    unsigned long vm_gid_addr;
 
     switch (type) {
-    case LIBXL_DOMAIN_TYPE_HVM:
+    case LIBXL_DOMAIN_TYPE_HVM: {
+        char *path;
+        char *addr;
+
+        path = libxl__sprintf(gc, "%s/data/generation-id", libxl__xs_get_dompath(gc, domid));
+        addr = libxl__xs_read(gc, XBT_NULL, path);
+
+        vm_gid_addr = (addr) ? strtoul(addr, NULL, 0) : 0;
         hvm = 1;
         break;
+    }
     case LIBXL_DOMAIN_TYPE_PV:
+        vm_gid_addr = 0;
         hvm = 0;
         break;
     default:
@@ -583,7 +598,8 @@ int libxl__domain_suspend_common(libxl__
     callbacks.switch_qemu_logdirty = libxl__domain_suspend_common_switch_qemu_logdirty;
     callbacks.data = &si;
 
-    rc = xc_domain_save(ctx->xch, fd, domid, 0, 0, flags, &callbacks, hvm);
+    rc = xc_domain_save(ctx->xch, fd, domid, 0, 0, flags, &callbacks,
+                        hvm, vm_gid_addr);
     if ( rc ) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "saving domain: %s",
                          si.guest_responded ?
diff -r 38eb74c01d9d -r 9eaac880f504 tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Tue Dec 06 21:16:56 2011 +0000
+++ b/tools/libxl/libxl_internal.h	Wed Dec 07 09:36:07 2011 +0000
@@ -199,6 +199,7 @@ typedef struct {
 
     uint32_t console_port;
     unsigned long console_mfn;
+    unsigned long vm_gid_addr;
 } libxl__domain_build_state;
 
 _hidden int libxl__build_pre(libxl__gc *gc, uint32_t domid,
diff -r 38eb74c01d9d -r 9eaac880f504 tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Tue Dec 06 21:16:56 2011 +0000
+++ b/tools/libxl/libxl_types.idl	Wed Dec 07 09:36:07 2011 +0000
@@ -184,6 +184,7 @@ libxl_domain_build_info = Struct("domain
                                        ("vpt_align", bool),
                                        ("timer_mode", integer),
                                        ("nested_hvm", bool),
+                                       ("no_increment_gid", bool),
                                        ])),
                  ("pv", Struct(None, [("kernel", libxl_file_reference),
                                       ("slack_memkb", uint32),
diff -r 38eb74c01d9d -r 9eaac880f504 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Tue Dec 06 21:16:56 2011 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Wed Dec 07 09:36:07 2011 +0000
@@ -360,6 +360,7 @@ static void printf_info(int domid,
         printf("\t\t\t(vpt_align %d)\n", b_info->u.hvm.vpt_align);
         printf("\t\t\t(timer_mode %d)\n", b_info->u.hvm.timer_mode);
         printf("\t\t\t(nestedhvm %d)\n", b_info->u.hvm.nested_hvm);
+        printf("\t\t\t(no_increment_gid %d)\n", b_info->u.hvm.no_increment_gid);
 
         printf("\t\t\t(device_model %s)\n", dm_info->device_model ? : "default");
         printf("\t\t\t(videoram %d)\n", dm_info->videoram);
@@ -1362,6 +1363,7 @@ struct domain_create {
     const char *restore_file;
     int migrate_fd; /* -1 means none */
     char **migration_domname_r; /* from malloc */
+    int no_increment_gid;
 };
 
 static int freemem(libxl_domain_build_info *b_info, libxl_device_model_info *dm_info)
@@ -1575,6 +1577,8 @@ static int create_domain(struct domain_c
         }
     }
 
+    d_config.b_info.u.hvm.no_increment_gid = dom_info->no_increment_gid;
+
     if (debug || dom_info->dryrun)
         printf_info(-1, &d_config, &d_config.dm_info);
 
@@ -2800,6 +2804,7 @@ static void migrate_receive(int debug, i
     dom_info.restore_file = "incoming migration stream";
     dom_info.migrate_fd = 0; /* stdin */
     dom_info.migration_domname_r = &migration_domname;
+    dom_info.no_increment_gid = 1;
 
     rc = create_domain(&dom_info);
     if (rc < 0) {
diff -r 38eb74c01d9d -r 9eaac880f504 tools/python/xen/lowlevel/checkpoint/libcheckpoint.c
--- a/tools/python/xen/lowlevel/checkpoint/libcheckpoint.c	Tue Dec 06 21:16:56 2011 +0000
+++ b/tools/python/xen/lowlevel/checkpoint/libcheckpoint.c	Wed Dec 07 09:36:07 2011 +0000
@@ -175,6 +175,7 @@ int checkpoint_start(checkpoint_state* s
 {
     int hvm, rc;
     int flags = XCFLAGS_LIVE;
+    unsigned long vm_gid_addr;
 
     if (!s->domid) {
        s->errstr = "checkpoint state not opened";
@@ -185,16 +186,27 @@ int checkpoint_start(checkpoint_state* s
 
     hvm = s->domtype > dt_pv;
     if (hvm) {
+       char path[128];
+       char *addr;
+
+       sprintf(path, "/local/domain/%u/data/generation-id", s->domid);
+       addr = xs_read(s->xsh, XBT_NULL, path, NULL);
+
+       vm_gid_addr = (addr) ? strtoul(addr, NULL, 0) : 0;
+       free(addr);
+
        flags |= XCFLAGS_HVM;
        if (switch_qemu_logdirty(s, 1))
            return -1;
+    } else {
+       vm_gid_addr = 0;
     }
     if (remus_flags & CHECKPOINT_FLAGS_COMPRESSION)
       flags |= XCFLAGS_CHECKPOINT_COMPRESS;
 
     callbacks->switch_qemu_logdirty = noop_switch_logdirty;
 
-    rc = xc_domain_save(s->xch, fd, s->domid, 0, 0, flags, callbacks, hvm);
+    rc = xc_domain_save(s->xch, fd, s->domid, 0, 0, flags, callbacks, hvm, vm_gid_addr);
 
     if (hvm)
        switch_qemu_logdirty(s, 0);
diff -r 38eb74c01d9d -r 9eaac880f504 tools/xcutils/xc_restore.c
--- a/tools/xcutils/xc_restore.c	Tue Dec 06 21:16:56 2011 +0000
+++ b/tools/xcutils/xc_restore.c	Wed Dec 07 09:36:07 2011 +0000
@@ -23,11 +23,12 @@ main(int argc, char **argv)
     xc_interface *xch;
     int io_fd, ret;
     int superpages;
-    unsigned long store_mfn, console_mfn;
+    unsigned long store_mfn, console_mfn, vm_gid_addr;
+    int no_increment_gid;
 
-    if ( (argc != 8) && (argc != 9) )
+    if ( (argc < 8) || (argc > 10) )
         errx(1, "usage: %s iofd domid store_evtchn "
-             "console_evtchn hvm pae apic [superpages]", argv[0]);
+             "console_evtchn hvm pae apic [superpages [no_increment_gid]]", argv[0]);
 
     xch = xc_interface_open(0,0,0);
     if ( !xch )
@@ -40,19 +41,25 @@ main(int argc, char **argv)
     hvm  = atoi(argv[5]);
     pae  = atoi(argv[6]);
     apic = atoi(argv[7]);
-    if ( argc == 9 )
+    if ( argc >= 9 )
 	    superpages = atoi(argv[8]);
     else
 	    superpages = !!hvm;
+    if ( argc >= 10 )
+	    no_increment_gid = !atoi(argv[9]);
+    else
+	    no_increment_gid = 0;
 
     ret = xc_domain_restore(xch, io_fd, domid, store_evtchn, &store_mfn,
-                            console_evtchn, &console_mfn, hvm, pae, superpages);
+                            console_evtchn, &console_mfn, hvm, pae, superpages,
+                            no_increment_gid, &vm_gid_addr);
 
     if ( ret == 0 )
     {
 	printf("store-mfn %li\n", store_mfn);
         if ( !hvm )
             printf("console-mfn %li\n", console_mfn);
+	printf("vm-gid-addr %lx\n", vm_gid_addr);
 	fflush(stdout);
     }
 
diff -r 38eb74c01d9d -r 9eaac880f504 tools/xcutils/xc_save.c
--- a/tools/xcutils/xc_save.c	Tue Dec 06 21:16:56 2011 +0000
+++ b/tools/xcutils/xc_save.c	Wed Dec 07 09:36:07 2011 +0000
@@ -169,6 +169,10 @@ main(int argc, char **argv)
     unsigned int maxit, max_f;
     int io_fd, ret, port;
     struct save_callbacks callbacks;
+    char path[128];
+    struct xs_handle *xs;
+    char *addr;
+    unsigned long vm_gid_addr;
 
     if (argc != 6)
         errx(1, "usage: %s iofd domid maxit maxf flags", argv[0]);
@@ -207,8 +211,21 @@ main(int argc, char **argv)
     memset(&callbacks, 0, sizeof(callbacks));
     callbacks.suspend = suspend;
     callbacks.switch_qemu_logdirty = switch_qemu_logdirty;
+
+    sprintf(path, "/local/domain/%d/data/generation-id", si.domid);
+
+    if ((xs = xs_daemon_open()) == NULL)
+        errx(1, "Couldn't contact xenstore");
+
+    addr = xs_read(xs, XBT_NULL, path, NULL);
+
+    xs_daemon_close(xs);
+
+    vm_gid_addr = (addr) ? strtoul(addr, NULL, 0) : 0;
+    free(addr);
+
     ret = xc_domain_save(si.xch, io_fd, si.domid, maxit, max_f, si.flags, 
-                         &callbacks, !!(si.flags & XCFLAGS_HVM));
+                         &callbacks, !!(si.flags & XCFLAGS_HVM), vm_gid_addr);
 
     if (si.suspend_evtchn > 0)
 	 xc_suspend_evtchn_release(si.xch, si.xce, si.domid, si.suspend_evtchn);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 09:40:18 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 09:40:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYDyk-0003yQ-H9; Wed, 07 Dec 2011 09:39:54 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RYDyi-0003yL-HL
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 09:39:53 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1323250743!6217730!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjk1NTQ=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24872 invoked from network); 7 Dec 2011 09:39:05 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Dec 2011 09:39:05 -0000
X-IronPort-AV: E=Sophos;i="4.71,313,1320642000"; d="scan'208";a="173207633"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Dec 2011 04:39:01 -0500
Received: from cosworth.uk.xensource.com (10.80.16.52) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 7 Dec 2011 04:39:01 -0500
MIME-Version: 1.0
X-Mercurial-Node: 9eaac880f504a12c145d72a96d789dbcff33d624
Message-ID: <9eaac880f504a12c145d.1323250728@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Wed, 7 Dec 2011 09:38:48 +0000
From: Paul Durrant <paul.durrant@citrix.com>
To: xen-devel@lists.xensource.com
Cc: paul.durrant@citrix.com
Subject: [Xen-devel] [PATCH] VM generation ID save/restore and migrate
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Paul Durrant <paul.durrant@citrix.com>
# Date 1323250567 0
# Node ID 9eaac880f504a12c145d72a96d789dbcff33d624
# Parent  38eb74c01d9d9afacdf0c79fcb5555d99719dfa5
VM generation ID save/restore and migrate.

Add code to track the address of the VM generation id buffer across a
save/restore or migrate and increment it as necessary.
The address of the buffer is written into xenstore by hvmloader at
boot time. It must be read from xenstore by the caller of
xc_domain_save() and then written back again by the caller of
xc_domain_restore().

Signed-off-by: Paul Durrant <paul.durrant@citrix.com>

diff -r 38eb74c01d9d -r 9eaac880f504 tools/libxc/ia64/xc_ia64_linux_restore.c
--- a/tools/libxc/ia64/xc_ia64_linux_restore.c	Tue Dec 06 21:16:56 2011 +0000
+++ b/tools/libxc/ia64/xc_ia64_linux_restore.c	Wed Dec 07 09:36:07 2011 +0000
@@ -548,7 +548,8 @@ int
 xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
                   unsigned int store_evtchn, unsigned long *store_mfn,
                   unsigned int console_evtchn, unsigned long *console_mfn,
-                  unsigned int hvm, unsigned int pae, int superpages)
+                  unsigned int hvm, unsigned int pae, int superpages,
+                  int increment_gid, unsigned long *vm_gid_addr)
 {
     DECLARE_DOMCTL;
     int rc = 1;
diff -r 38eb74c01d9d -r 9eaac880f504 tools/libxc/ia64/xc_ia64_linux_save.c
--- a/tools/libxc/ia64/xc_ia64_linux_save.c	Tue Dec 06 21:16:56 2011 +0000
+++ b/tools/libxc/ia64/xc_ia64_linux_save.c	Wed Dec 07 09:36:07 2011 +0000
@@ -382,7 +382,8 @@ out:
 int
 xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iters,
                uint32_t max_factor, uint32_t flags,
-               struct save_callbacks* callbacks, int hvm)
+               struct save_callbacks* callbacks, int hvm,
+               unsigned long vm_gid_addr)
 {
     DECLARE_DOMCTL;
     xc_dominfo_t info;
diff -r 38eb74c01d9d -r 9eaac880f504 tools/libxc/xc_domain_restore.c
--- a/tools/libxc/xc_domain_restore.c	Tue Dec 06 21:16:56 2011 +0000
+++ b/tools/libxc/xc_domain_restore.c	Wed Dec 07 09:36:07 2011 +0000
@@ -681,6 +681,7 @@ typedef struct {
     uint64_t console_pfn;
     uint64_t acpi_ioport_location;
     uint64_t viridian;
+    uint64_t vm_gid_addr;
 } pagebuf_t;
 
 static int pagebuf_init(pagebuf_t* buf)
@@ -860,6 +861,17 @@ static int pagebuf_get_one(xc_interface 
         }
         return compbuf_size;
 
+    case XC_SAVE_ID_HVM_GENERATION_ID_ADDR:
+        /* Skip padding 4 bytes then read the generation id buffer location. */
+        if ( RDEXACT(fd, &buf->vm_gid_addr, sizeof(uint32_t)) ||
+             RDEXACT(fd, &buf->vm_gid_addr, sizeof(uint64_t)) )
+        {
+            PERROR("error read the generation id buffer location");
+            return -1;
+        }
+        DPRINTF("read generation id buffer address");
+        return pagebuf_get_one(xch, ctx, buf, fd, dom);
+
     default:
         if ( (count > MAX_BATCH_SIZE) || (count < 0) ) {
             ERROR("Max batch size exceeded (%d). Giving up.", count);
@@ -1248,7 +1260,8 @@ static int apply_batch(xc_interface *xch
 int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
                       unsigned int store_evtchn, unsigned long *store_mfn,
                       unsigned int console_evtchn, unsigned long *console_mfn,
-                      unsigned int hvm, unsigned int pae, int superpages)
+                      unsigned int hvm, unsigned int pae, int superpages,
+                      int no_increment_gid, unsigned long *vm_gid_addr)
 {
     DECLARE_DOMCTL;
     int rc = 1, frc, i, j, n, m, pae_extended_cr3 = 0, ext_vcpucontext = 0;
@@ -1449,6 +1462,39 @@ int xc_domain_restore(xc_interface *xch,
                 xc_set_hvm_param(xch, dom, HVM_PARAM_VM86_TSS, pagebuf.vm86_tss);
             if ( pagebuf.console_pfn )
                 console_pfn = pagebuf.console_pfn;
+            if ( pagebuf.vm_gid_addr ) {
+                if ( !no_increment_gid ) {
+                    unsigned int offset;
+                    unsigned char *buf;
+                    unsigned long long gid;
+
+                    /*
+                     * Map the VM generation id buffer and inject the new value.
+                     */
+
+                    pfn = pagebuf.vm_gid_addr >> PAGE_SHIFT;
+                    offset = pagebuf.vm_gid_addr & (PAGE_SIZE - 1);
+                
+                    if ( (pfn >= dinfo->p2m_size) ||
+                         (pfn_type[pfn] != XEN_DOMCTL_PFINFO_NOTAB) )
+                    {
+                        ERROR("generation id buffer frame is bad");
+                        goto out;
+                    }
+
+                    mfn = ctx->p2m[pfn];
+                    buf = xc_map_foreign_range(xch, dom, PAGE_SIZE,
+                                               PROT_READ | PROT_WRITE, mfn);
+
+                    gid = *(unsigned long long *)(buf + offset);
+                    *(unsigned long long *)(buf + offset) = gid + 1;
+
+                    munmap(buf, PAGE_SIZE);
+                }
+
+                *vm_gid_addr = pagebuf.vm_gid_addr;
+            }
+
             break;  /* our work here is done */
         }
 
diff -r 38eb74c01d9d -r 9eaac880f504 tools/libxc/xc_domain_save.c
--- a/tools/libxc/xc_domain_save.c	Tue Dec 06 21:16:56 2011 +0000
+++ b/tools/libxc/xc_domain_save.c	Wed Dec 07 09:36:07 2011 +0000
@@ -804,7 +804,8 @@ static int save_tsc_info(xc_interface *x
 
 int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iters,
                    uint32_t max_factor, uint32_t flags,
-                   struct save_callbacks* callbacks, int hvm)
+                   struct save_callbacks* callbacks, int hvm,
+                   unsigned long vm_gid_addr)
 {
     xc_dominfo_t info;
     DECLARE_DOMCTL;
@@ -1616,6 +1617,16 @@ int xc_domain_save(xc_interface *xch, in
             uint64_t data;
         } chunk = { 0, };
 
+        chunk.id = XC_SAVE_ID_HVM_GENERATION_ID_ADDR;
+        chunk.data = vm_gid_addr;
+
+        if ( (chunk.data != 0) &&
+             wrexact(io_fd, &chunk, sizeof(chunk)) )
+        {
+            PERROR("Error when writing the generation id buffer location for guest");
+            goto out;
+        }
+
         chunk.id = XC_SAVE_ID_HVM_IDENT_PT;
         chunk.data = 0;
         xc_get_hvm_param(xch, dom, HVM_PARAM_IDENT_PT,
diff -r 38eb74c01d9d -r 9eaac880f504 tools/libxc/xenguest.h
--- a/tools/libxc/xenguest.h	Tue Dec 06 21:16:56 2011 +0000
+++ b/tools/libxc/xenguest.h	Wed Dec 07 09:36:07 2011 +0000
@@ -58,7 +58,8 @@ struct save_callbacks {
  */
 int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iters,
                    uint32_t max_factor, uint32_t flags /* XCFLAGS_xxx */,
-                   struct save_callbacks* callbacks, int hvm);
+                   struct save_callbacks* callbacks, int hvm,
+                   unsigned long vm_gid_addr);
 
 
 /**
@@ -72,12 +73,15 @@ int xc_domain_save(xc_interface *xch, in
  * @parm hvm non-zero if this is a HVM restore
  * @parm pae non-zero if this HVM domain has PAE support enabled
  * @parm superpages non-zero to allocate guest memory with superpages
+ * @parm gid the new generation id of the VM
+ * @parm vm_gid_addr returned with the address of the generation id buffer
  * @return 0 on success, -1 on failure
  */
 int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
                       unsigned int store_evtchn, unsigned long *store_mfn,
                       unsigned int console_evtchn, unsigned long *console_mfn,
-                      unsigned int hvm, unsigned int pae, int superpages);
+                      unsigned int hvm, unsigned int pae, int superpages,
+                      int increment_gid, unsigned long *vm_gid_addr);
 /**
  * xc_domain_restore writes a file to disk that contains the device
  * model saved state.
diff -r 38eb74c01d9d -r 9eaac880f504 tools/libxc/xg_save_restore.h
--- a/tools/libxc/xg_save_restore.h	Tue Dec 06 21:16:56 2011 +0000
+++ b/tools/libxc/xg_save_restore.h	Wed Dec 07 09:36:07 2011 +0000
@@ -253,6 +253,7 @@
 #define XC_SAVE_ID_HVM_VIRIDIAN       -11
 #define XC_SAVE_ID_COMPRESSED_DATA    -12 /* Marker to indicate arrival of compressed data */
 #define XC_SAVE_ID_ENABLE_COMPRESSION -13 /* Marker to enable compression logic at receiver side */
+#define XC_SAVE_ID_HVM_GENERATION_ID_ADDR -14
 
 /*
 ** We process save/restore/migrate in batches of pages; the below
diff -r 38eb74c01d9d -r 9eaac880f504 tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Tue Dec 06 21:16:56 2011 +0000
+++ b/tools/libxl/libxl_create.c	Wed Dec 07 09:36:07 2011 +0000
@@ -101,6 +101,7 @@ int libxl_init_build_info(libxl_ctx *ctx
         b_info->u.hvm.vpt_align = 1;
         b_info->u.hvm.timer_mode = 1;
         b_info->u.hvm.nested_hvm = 0;
+        b_info->u.hvm.no_increment_gid = 0;
         break;
     case LIBXL_DOMAIN_TYPE_PV:
         b_info->u.pv.slack_memkb = 8 * 1024;
diff -r 38eb74c01d9d -r 9eaac880f504 tools/libxl/libxl_dom.c
--- a/tools/libxl/libxl_dom.c	Tue Dec 06 21:16:56 2011 +0000
+++ b/tools/libxl/libxl_dom.c	Wed Dec 07 09:36:07 2011 +0000
@@ -125,7 +125,7 @@ int libxl__build_post(libxl__gc *gc, uin
     if (info->cpuid != NULL)
         libxl_cpuid_set(ctx, domid, info->cpuid);
 
-    ents = libxl__calloc(gc, 12 + (info->max_vcpus * 2) + 2, sizeof(char *));
+    ents = libxl__calloc(gc, 14 + (info->max_vcpus * 2) + 2, sizeof(char *));
     ents[0] = "memory/static-max";
     ents[1] = libxl__sprintf(gc, "%d", info->max_memkb);
     ents[2] = "memory/target";
@@ -138,9 +138,11 @@ int libxl__build_post(libxl__gc *gc, uin
     ents[9] = libxl__sprintf(gc, "%"PRIu32, state->store_port);
     ents[10] = "store/ring-ref";
     ents[11] = libxl__sprintf(gc, "%lu", state->store_mfn);
+    ents[12] = "data/generation-id";
+    ents[13] = libxl__sprintf(gc, "0x%lx", state->vm_gid_addr);
     for (i = 0; i < info->max_vcpus; i++) {
-        ents[12+(i*2)]   = libxl__sprintf(gc, "cpu/%d/availability", i);
-        ents[12+(i*2)+1] = (i && info->cur_vcpus && !(info->cur_vcpus & (1 << i)))
+        ents[14+(i*2)]   = libxl__sprintf(gc, "cpu/%d/availability", i);
+        ents[14+(i*2)+1] = (i && info->cur_vcpus && !(info->cur_vcpus & (1 << i)))
                             ? "offline" : "online";
     }
 
@@ -357,16 +359,19 @@ int libxl__domain_restore_common(libxl__
     /* read signature */
     int rc;
     int hvm, pae, superpages;
+    int no_increment_gid;
     switch (info->type) {
     case LIBXL_DOMAIN_TYPE_HVM:
         hvm = 1;
         superpages = 1;
         pae = info->u.hvm.pae;
+        no_increment_gid = info->u.hvm.no_increment_gid;
         break;
     case LIBXL_DOMAIN_TYPE_PV:
         hvm = 0;
         superpages = 0;
         pae = 1;
+        no_increment_gid = 0;
         break;
     default:
         return ERROR_INVAL;
@@ -374,7 +379,7 @@ int libxl__domain_restore_common(libxl__
     rc = xc_domain_restore(ctx->xch, fd, domid,
                            state->store_port, &state->store_mfn,
                            state->console_port, &state->console_mfn,
-                           hvm, pae, superpages);
+                           hvm, pae, superpages, no_increment_gid, &state->vm_gid_addr);
     if ( rc ) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "restoring domain");
         return ERROR_FAIL;
@@ -540,12 +545,22 @@ int libxl__domain_suspend_common(libxl__
     struct save_callbacks callbacks;
     struct suspendinfo si;
     int hvm, rc = ERROR_FAIL;
+    unsigned long vm_gid_addr;
 
     switch (type) {
-    case LIBXL_DOMAIN_TYPE_HVM:
+    case LIBXL_DOMAIN_TYPE_HVM: {
+        char *path;
+        char *addr;
+
+        path = libxl__sprintf(gc, "%s/data/generation-id", libxl__xs_get_dompath(gc, domid));
+        addr = libxl__xs_read(gc, XBT_NULL, path);
+
+        vm_gid_addr = (addr) ? strtoul(addr, NULL, 0) : 0;
         hvm = 1;
         break;
+    }
     case LIBXL_DOMAIN_TYPE_PV:
+        vm_gid_addr = 0;
         hvm = 0;
         break;
     default:
@@ -583,7 +598,8 @@ int libxl__domain_suspend_common(libxl__
     callbacks.switch_qemu_logdirty = libxl__domain_suspend_common_switch_qemu_logdirty;
     callbacks.data = &si;
 
-    rc = xc_domain_save(ctx->xch, fd, domid, 0, 0, flags, &callbacks, hvm);
+    rc = xc_domain_save(ctx->xch, fd, domid, 0, 0, flags, &callbacks,
+                        hvm, vm_gid_addr);
     if ( rc ) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "saving domain: %s",
                          si.guest_responded ?
diff -r 38eb74c01d9d -r 9eaac880f504 tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Tue Dec 06 21:16:56 2011 +0000
+++ b/tools/libxl/libxl_internal.h	Wed Dec 07 09:36:07 2011 +0000
@@ -199,6 +199,7 @@ typedef struct {
 
     uint32_t console_port;
     unsigned long console_mfn;
+    unsigned long vm_gid_addr;
 } libxl__domain_build_state;
 
 _hidden int libxl__build_pre(libxl__gc *gc, uint32_t domid,
diff -r 38eb74c01d9d -r 9eaac880f504 tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Tue Dec 06 21:16:56 2011 +0000
+++ b/tools/libxl/libxl_types.idl	Wed Dec 07 09:36:07 2011 +0000
@@ -184,6 +184,7 @@ libxl_domain_build_info = Struct("domain
                                        ("vpt_align", bool),
                                        ("timer_mode", integer),
                                        ("nested_hvm", bool),
+                                       ("no_increment_gid", bool),
                                        ])),
                  ("pv", Struct(None, [("kernel", libxl_file_reference),
                                       ("slack_memkb", uint32),
diff -r 38eb74c01d9d -r 9eaac880f504 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Tue Dec 06 21:16:56 2011 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Wed Dec 07 09:36:07 2011 +0000
@@ -360,6 +360,7 @@ static void printf_info(int domid,
         printf("\t\t\t(vpt_align %d)\n", b_info->u.hvm.vpt_align);
         printf("\t\t\t(timer_mode %d)\n", b_info->u.hvm.timer_mode);
         printf("\t\t\t(nestedhvm %d)\n", b_info->u.hvm.nested_hvm);
+        printf("\t\t\t(no_increment_gid %d)\n", b_info->u.hvm.no_increment_gid);
 
         printf("\t\t\t(device_model %s)\n", dm_info->device_model ? : "default");
         printf("\t\t\t(videoram %d)\n", dm_info->videoram);
@@ -1362,6 +1363,7 @@ struct domain_create {
     const char *restore_file;
     int migrate_fd; /* -1 means none */
     char **migration_domname_r; /* from malloc */
+    int no_increment_gid;
 };
 
 static int freemem(libxl_domain_build_info *b_info, libxl_device_model_info *dm_info)
@@ -1575,6 +1577,8 @@ static int create_domain(struct domain_c
         }
     }
 
+    d_config.b_info.u.hvm.no_increment_gid = dom_info->no_increment_gid;
+
     if (debug || dom_info->dryrun)
         printf_info(-1, &d_config, &d_config.dm_info);
 
@@ -2800,6 +2804,7 @@ static void migrate_receive(int debug, i
     dom_info.restore_file = "incoming migration stream";
     dom_info.migrate_fd = 0; /* stdin */
     dom_info.migration_domname_r = &migration_domname;
+    dom_info.no_increment_gid = 1;
 
     rc = create_domain(&dom_info);
     if (rc < 0) {
diff -r 38eb74c01d9d -r 9eaac880f504 tools/python/xen/lowlevel/checkpoint/libcheckpoint.c
--- a/tools/python/xen/lowlevel/checkpoint/libcheckpoint.c	Tue Dec 06 21:16:56 2011 +0000
+++ b/tools/python/xen/lowlevel/checkpoint/libcheckpoint.c	Wed Dec 07 09:36:07 2011 +0000
@@ -175,6 +175,7 @@ int checkpoint_start(checkpoint_state* s
 {
     int hvm, rc;
     int flags = XCFLAGS_LIVE;
+    unsigned long vm_gid_addr;
 
     if (!s->domid) {
        s->errstr = "checkpoint state not opened";
@@ -185,16 +186,27 @@ int checkpoint_start(checkpoint_state* s
 
     hvm = s->domtype > dt_pv;
     if (hvm) {
+       char path[128];
+       char *addr;
+
+       sprintf(path, "/local/domain/%u/data/generation-id", s->domid);
+       addr = xs_read(s->xsh, XBT_NULL, path, NULL);
+
+       vm_gid_addr = (addr) ? strtoul(addr, NULL, 0) : 0;
+       free(addr);
+
        flags |= XCFLAGS_HVM;
        if (switch_qemu_logdirty(s, 1))
            return -1;
+    } else {
+       vm_gid_addr = 0;
     }
     if (remus_flags & CHECKPOINT_FLAGS_COMPRESSION)
       flags |= XCFLAGS_CHECKPOINT_COMPRESS;
 
     callbacks->switch_qemu_logdirty = noop_switch_logdirty;
 
-    rc = xc_domain_save(s->xch, fd, s->domid, 0, 0, flags, callbacks, hvm);
+    rc = xc_domain_save(s->xch, fd, s->domid, 0, 0, flags, callbacks, hvm, vm_gid_addr);
 
     if (hvm)
        switch_qemu_logdirty(s, 0);
diff -r 38eb74c01d9d -r 9eaac880f504 tools/xcutils/xc_restore.c
--- a/tools/xcutils/xc_restore.c	Tue Dec 06 21:16:56 2011 +0000
+++ b/tools/xcutils/xc_restore.c	Wed Dec 07 09:36:07 2011 +0000
@@ -23,11 +23,12 @@ main(int argc, char **argv)
     xc_interface *xch;
     int io_fd, ret;
     int superpages;
-    unsigned long store_mfn, console_mfn;
+    unsigned long store_mfn, console_mfn, vm_gid_addr;
+    int no_increment_gid;
 
-    if ( (argc != 8) && (argc != 9) )
+    if ( (argc < 8) || (argc > 10) )
         errx(1, "usage: %s iofd domid store_evtchn "
-             "console_evtchn hvm pae apic [superpages]", argv[0]);
+             "console_evtchn hvm pae apic [superpages [no_increment_gid]]", argv[0]);
 
     xch = xc_interface_open(0,0,0);
     if ( !xch )
@@ -40,19 +41,25 @@ main(int argc, char **argv)
     hvm  = atoi(argv[5]);
     pae  = atoi(argv[6]);
     apic = atoi(argv[7]);
-    if ( argc == 9 )
+    if ( argc >= 9 )
 	    superpages = atoi(argv[8]);
     else
 	    superpages = !!hvm;
+    if ( argc >= 10 )
+	    no_increment_gid = !atoi(argv[9]);
+    else
+	    no_increment_gid = 0;
 
     ret = xc_domain_restore(xch, io_fd, domid, store_evtchn, &store_mfn,
-                            console_evtchn, &console_mfn, hvm, pae, superpages);
+                            console_evtchn, &console_mfn, hvm, pae, superpages,
+                            no_increment_gid, &vm_gid_addr);
 
     if ( ret == 0 )
     {
 	printf("store-mfn %li\n", store_mfn);
         if ( !hvm )
             printf("console-mfn %li\n", console_mfn);
+	printf("vm-gid-addr %lx\n", vm_gid_addr);
 	fflush(stdout);
     }
 
diff -r 38eb74c01d9d -r 9eaac880f504 tools/xcutils/xc_save.c
--- a/tools/xcutils/xc_save.c	Tue Dec 06 21:16:56 2011 +0000
+++ b/tools/xcutils/xc_save.c	Wed Dec 07 09:36:07 2011 +0000
@@ -169,6 +169,10 @@ main(int argc, char **argv)
     unsigned int maxit, max_f;
     int io_fd, ret, port;
     struct save_callbacks callbacks;
+    char path[128];
+    struct xs_handle *xs;
+    char *addr;
+    unsigned long vm_gid_addr;
 
     if (argc != 6)
         errx(1, "usage: %s iofd domid maxit maxf flags", argv[0]);
@@ -207,8 +211,21 @@ main(int argc, char **argv)
     memset(&callbacks, 0, sizeof(callbacks));
     callbacks.suspend = suspend;
     callbacks.switch_qemu_logdirty = switch_qemu_logdirty;
+
+    sprintf(path, "/local/domain/%d/data/generation-id", si.domid);
+
+    if ((xs = xs_daemon_open()) == NULL)
+        errx(1, "Couldn't contact xenstore");
+
+    addr = xs_read(xs, XBT_NULL, path, NULL);
+
+    xs_daemon_close(xs);
+
+    vm_gid_addr = (addr) ? strtoul(addr, NULL, 0) : 0;
+    free(addr);
+
     ret = xc_domain_save(si.xch, io_fd, si.domid, maxit, max_f, si.flags, 
-                         &callbacks, !!(si.flags & XCFLAGS_HVM));
+                         &callbacks, !!(si.flags & XCFLAGS_HVM), vm_gid_addr);
 
     if (si.suspend_evtchn > 0)
 	 xc_suspend_evtchn_release(si.xch, si.xce, si.domid, si.suspend_evtchn);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 09:43:42 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 09: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.xensource.com>)
	id 1RYE29-000481-Gz; Wed, 07 Dec 2011 09:43:25 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RYE27-00047t-GZ
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 09:43:23 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1323250956!6225335!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM1ODk=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7596 invoked from network); 7 Dec 2011 09:42:36 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-12.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 7 Dec 2011 09:42:36 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 07 Dec 2011 09:42:36 +0000
Message-Id: <4EDF43470200007800065E4E@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 07 Dec 2011 09:43:19 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Stefano Stabellini" <stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1112061753410.31179@kaball-desktop>
	<1323195609-17277-5-git-send-email-stefano.stabellini@eu.citrix.com>
In-Reply-To: <1323195609-17277-5-git-send-email-stefano.stabellini@eu.citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com, Ian.Campbell@citrix.com,
	Tim.Deegan@citrix.com
Subject: Re: [Xen-devel] [PATCH RFC 05/25] Introduce clear_user
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 06.12.11 at 19:19, <stefano.stabellini@eu.citrix.com> wrote:
> --- a/xen/arch/x86/usercopy.c
> +++ b/xen/arch/x86/usercopy.c
> @@ -110,6 +110,42 @@ copy_to_user(void __user *to, const void *from, unsigned 
> n)
>      return n;
>  }
>  
> +#define __do_clear_user(addr,size)					\
> +do {									\
> +	int __d0;							\

This should be 'long' to be forward compatible (current gcc likely doesn't
care), and to cope with eventual future compat mode users passing in a
32-bit 'addr'.

> +	__asm__ __volatile__(						\
> +		"0:	rep; stosl\n"					\
> +		"	movl %2,%0\n"					\
> +		"1:	rep; stosb\n"					\
> +		"2:\n"							\
> +		".section .fixup,\"ax\"\n"				\
> +		"3:	lea 0(%2,%0,4),%0\n"				\
> +		"	jmp 2b\n"					\
> +		".previous\n"						\
> +		_ASM_EXTABLE(0b,3b)					\
> +		_ASM_EXTABLE(1b,2b)					\
> +		: "=&c"(size), "=&D" (__d0)				\
> +		: "r"(size & 3), "0"(size / 4), "1"(addr), "a"(0));	\

For that latter case at least, casting 'addr' to long may also be necessary.

Jan

> +} while (0)



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 09:43:42 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 09: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.xensource.com>)
	id 1RYE29-000481-Gz; Wed, 07 Dec 2011 09:43:25 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RYE27-00047t-GZ
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 09:43:23 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1323250956!6225335!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM1ODk=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7596 invoked from network); 7 Dec 2011 09:42:36 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-12.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 7 Dec 2011 09:42:36 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 07 Dec 2011 09:42:36 +0000
Message-Id: <4EDF43470200007800065E4E@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 07 Dec 2011 09:43:19 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Stefano Stabellini" <stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1112061753410.31179@kaball-desktop>
	<1323195609-17277-5-git-send-email-stefano.stabellini@eu.citrix.com>
In-Reply-To: <1323195609-17277-5-git-send-email-stefano.stabellini@eu.citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com, Ian.Campbell@citrix.com,
	Tim.Deegan@citrix.com
Subject: Re: [Xen-devel] [PATCH RFC 05/25] Introduce clear_user
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 06.12.11 at 19:19, <stefano.stabellini@eu.citrix.com> wrote:
> --- a/xen/arch/x86/usercopy.c
> +++ b/xen/arch/x86/usercopy.c
> @@ -110,6 +110,42 @@ copy_to_user(void __user *to, const void *from, unsigned 
> n)
>      return n;
>  }
>  
> +#define __do_clear_user(addr,size)					\
> +do {									\
> +	int __d0;							\

This should be 'long' to be forward compatible (current gcc likely doesn't
care), and to cope with eventual future compat mode users passing in a
32-bit 'addr'.

> +	__asm__ __volatile__(						\
> +		"0:	rep; stosl\n"					\
> +		"	movl %2,%0\n"					\
> +		"1:	rep; stosb\n"					\
> +		"2:\n"							\
> +		".section .fixup,\"ax\"\n"				\
> +		"3:	lea 0(%2,%0,4),%0\n"				\
> +		"	jmp 2b\n"					\
> +		".previous\n"						\
> +		_ASM_EXTABLE(0b,3b)					\
> +		_ASM_EXTABLE(1b,2b)					\
> +		: "=&c"(size), "=&D" (__d0)				\
> +		: "r"(size & 3), "0"(size / 4), "1"(addr), "a"(0));	\

For that latter case at least, casting 'addr' to long may also be necessary.

Jan

> +} while (0)



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 09:57:28 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 09:57:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYEFH-0004LE-Ul; Wed, 07 Dec 2011 09:56:59 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RYEFG-0004L4-IN
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 09:56:58 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1323251753!48550033!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM1ODk=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18877 invoked from network); 7 Dec 2011 09:55:54 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-11.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 7 Dec 2011 09:55:54 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 07 Dec 2011 09:56:11 +0000
Message-Id: <4EDF46770200007800065E65@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 07 Dec 2011 09:56:55 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Stefano Stabellini" <stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1112061753410.31179@kaball-desktop>
	<1323195609-17277-6-git-send-email-stefano.stabellini@eu.citrix.com>
In-Reply-To: <1323195609-17277-6-git-send-email-stefano.stabellini@eu.citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com, Ian Campbell <ian.campbell@citrix.com>,
	Tim.Deegan@citrix.com
Subject: Re: [Xen-devel] [PATCH RFC 06/25] libelf-loader: introduce
 elf_load_image and CONFIG_KERNEL_NO_RELOC
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 06.12.11 at 19:19, <stefano.stabellini@eu.citrix.com> wrote:
> @@ -265,7 +278,11 @@ void elf_load_binary(struct elf_binary *elf)
>  
>  void *elf_get_ptr(struct elf_binary *elf, unsigned long addr)
>  {
> +#ifdef CONFIG_KERNEL_NO_RELOC
> +    return elf->dest + addr;

This looks more like a workaround than a proper solution. Kernels on x86
may not support relocation either (classic Xen kernels certainly don't),
yet this construct isn't needed.

Jan

> +#else
>      return elf->dest + addr - elf->pstart;
> +#endif
>  }
>  
>  uint64_t elf_lookup_addr(struct elf_binary * elf, const char *symbol)





_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 09:57:28 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 09:57:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYEFH-0004LE-Ul; Wed, 07 Dec 2011 09:56:59 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RYEFG-0004L4-IN
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 09:56:58 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1323251753!48550033!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM1ODk=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18877 invoked from network); 7 Dec 2011 09:55:54 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-11.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 7 Dec 2011 09:55:54 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 07 Dec 2011 09:56:11 +0000
Message-Id: <4EDF46770200007800065E65@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 07 Dec 2011 09:56:55 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Stefano Stabellini" <stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1112061753410.31179@kaball-desktop>
	<1323195609-17277-6-git-send-email-stefano.stabellini@eu.citrix.com>
In-Reply-To: <1323195609-17277-6-git-send-email-stefano.stabellini@eu.citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com, Ian Campbell <ian.campbell@citrix.com>,
	Tim.Deegan@citrix.com
Subject: Re: [Xen-devel] [PATCH RFC 06/25] libelf-loader: introduce
 elf_load_image and CONFIG_KERNEL_NO_RELOC
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 06.12.11 at 19:19, <stefano.stabellini@eu.citrix.com> wrote:
> @@ -265,7 +278,11 @@ void elf_load_binary(struct elf_binary *elf)
>  
>  void *elf_get_ptr(struct elf_binary *elf, unsigned long addr)
>  {
> +#ifdef CONFIG_KERNEL_NO_RELOC
> +    return elf->dest + addr;

This looks more like a workaround than a proper solution. Kernels on x86
may not support relocation either (classic Xen kernels certainly don't),
yet this construct isn't needed.

Jan

> +#else
>      return elf->dest + addr - elf->pstart;
> +#endif
>  }
>  
>  uint64_t elf_lookup_addr(struct elf_binary * elf, const char *symbol)





_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 09:57:30 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 09:57:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYEFW-0004M1-BN; Wed, 07 Dec 2011 09:57:14 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RYEFU-0004La-Cl
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 09:57:12 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1323251784!4580334!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjA3NQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16679 invoked from network); 7 Dec 2011 09:56:25 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Dec 2011 09:56:25 -0000
X-IronPort-AV: E=Sophos;i="4.71,313,1320624000"; 
   d="scan'208";a="9336749"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Dec 2011 09:56:24 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 7 Dec 2011
	09:56:24 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: ANNIE LI <annie.li@oracle.com>
Date: Wed, 7 Dec 2011 09:56:23 +0000
In-Reply-To: <4EDEDF2E.3040204@oracle.com>
References: <4EDDF41E.8070200@oracle.com>
	<1323168999-4434-1-git-send-email-annie.li@oracle.com>
	<1323171726.23681.65.camel@zakaz.uk.xensource.com>
	<4EDEDF2E.3040204@oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323251784.23681.126.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "jeremy@goop.org" <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	"kurt.hackel@oracle.com" <kurt.hackel@oracle.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Paul Durrant <Paul.Durrant@citrix.com>
Subject: Re: [Xen-devel] [PATCH 1/2] xen/granttable: Support sub-page grants
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2011-12-07 at 03:36 +0000, ANNIE LI wrote:
> Thanks for your reviewing, Ian.
> >>   EXPORT_SYMBOL_GPL(gnttab_grant_foreign_access);
> >>
> >> +int gnttab_grant_foreign_access_subpage_v2(domid_t domid, unsigned long frame,
> >> +					   int flags, unsigned page_off,
> >> +					   unsigned length)
> > Please drop the v2 suffixes on the public functions.
> OK, the initial interface is without v2 suffixes. It was added in order 
> to reminder user the interfaces are only available for grant table v2.
> But I am fine to remove it, and following ops fn pointers are better.
> > Any reason not to route these via the ops table for consistency with all
> > the other ops? Then your availability check becomes a test for NULL fn
> > pointer rather than a specific version.
> Ok, it is good.
> How about following implements?

Looks to be along the right lines. Thanks.

> gnttab_v1_ops = {
>   ...
> .access_subpage = NULL;
> .access_ref_subpage = NULL;
> .access_trans = NULL;
> .access_ref_trans = NULL;
> }

I think you can omit these since NULL is the default but perhaps
explicitly listing them is useful in a self documenting type way.

[...]
> 
> Same operations for access_ref_subpage, access_trans and access_ref_trans.
> 
> bool gnttab_subpage_available()
> {
>       return (gnttab_interface->access_subpage != NULL);
> }
> 
> bool gnttab_subpage_available()
Typo:       ..trans..
> {
>       return (gnttab_interface->access_trans != NULL);
> }

Ian.

> 
> Thanks
> Annie



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 09:57:30 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 09:57:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYEFW-0004M1-BN; Wed, 07 Dec 2011 09:57:14 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RYEFU-0004La-Cl
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 09:57:12 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1323251784!4580334!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjA3NQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16679 invoked from network); 7 Dec 2011 09:56:25 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Dec 2011 09:56:25 -0000
X-IronPort-AV: E=Sophos;i="4.71,313,1320624000"; 
   d="scan'208";a="9336749"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Dec 2011 09:56:24 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 7 Dec 2011
	09:56:24 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: ANNIE LI <annie.li@oracle.com>
Date: Wed, 7 Dec 2011 09:56:23 +0000
In-Reply-To: <4EDEDF2E.3040204@oracle.com>
References: <4EDDF41E.8070200@oracle.com>
	<1323168999-4434-1-git-send-email-annie.li@oracle.com>
	<1323171726.23681.65.camel@zakaz.uk.xensource.com>
	<4EDEDF2E.3040204@oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323251784.23681.126.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "jeremy@goop.org" <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	"kurt.hackel@oracle.com" <kurt.hackel@oracle.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Paul Durrant <Paul.Durrant@citrix.com>
Subject: Re: [Xen-devel] [PATCH 1/2] xen/granttable: Support sub-page grants
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2011-12-07 at 03:36 +0000, ANNIE LI wrote:
> Thanks for your reviewing, Ian.
> >>   EXPORT_SYMBOL_GPL(gnttab_grant_foreign_access);
> >>
> >> +int gnttab_grant_foreign_access_subpage_v2(domid_t domid, unsigned long frame,
> >> +					   int flags, unsigned page_off,
> >> +					   unsigned length)
> > Please drop the v2 suffixes on the public functions.
> OK, the initial interface is without v2 suffixes. It was added in order 
> to reminder user the interfaces are only available for grant table v2.
> But I am fine to remove it, and following ops fn pointers are better.
> > Any reason not to route these via the ops table for consistency with all
> > the other ops? Then your availability check becomes a test for NULL fn
> > pointer rather than a specific version.
> Ok, it is good.
> How about following implements?

Looks to be along the right lines. Thanks.

> gnttab_v1_ops = {
>   ...
> .access_subpage = NULL;
> .access_ref_subpage = NULL;
> .access_trans = NULL;
> .access_ref_trans = NULL;
> }

I think you can omit these since NULL is the default but perhaps
explicitly listing them is useful in a self documenting type way.

[...]
> 
> Same operations for access_ref_subpage, access_trans and access_ref_trans.
> 
> bool gnttab_subpage_available()
> {
>       return (gnttab_interface->access_subpage != NULL);
> }
> 
> bool gnttab_subpage_available()
Typo:       ..trans..
> {
>       return (gnttab_interface->access_trans != NULL);
> }

Ian.

> 
> Thanks
> Annie



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 09:58:30 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 09: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.xensource.com>)
	id 1RYEGX-0004Rm-QG; Wed, 07 Dec 2011 09:58:17 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RYEGW-0004RD-FE
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 09:58:16 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1323251817!51437485!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjA3NQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16660 invoked from network); 7 Dec 2011 09:56:57 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Dec 2011 09:56:57 -0000
X-IronPort-AV: E=Sophos;i="4.71,313,1320624000"; 
   d="scan'208";a="9336778"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Dec 2011 09:57:29 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 7 Dec 2011
	09:57:29 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Paul Durrant <Paul.Durrant@citrix.com>
Date: Wed, 7 Dec 2011 09:57:29 +0000
In-Reply-To: <291EDFCB1E9E224A99088639C4762022B5988E542E@LONPMAILBOX01.citrite.net>
References: <4EDDF41E.8070200@oracle.com>
	<1323168999-4434-1-git-send-email-annie.li@oracle.com>
	<1323171726.23681.65.camel@zakaz.uk.xensource.com>
	<4EDEDF2E.3040204@oracle.com>
	<291EDFCB1E9E224A99088639C4762022B5988E542E@LONPMAILBOX01.citrite.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323251849.23681.128.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "jeremy@goop.org" <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	"kurt.hackel@oracle.com" <kurt.hackel@oracle.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	ANNIE LI <annie.li@oracle.com>
Subject: Re: [Xen-devel] [PATCH 1/2] xen/granttable: Support sub-page grants
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2011-12-07 at 08:59 +0000, Paul Durrant wrote:
> > gnttab_v2_ops = {
> >   ...
> > .access_subpage = access_subpage_v2;
> > .access_ref_subpage = access_ref_subpage_v2; .access_trans =
> > access_trans_v2; .access_ref_trans = access_ref_trans_v2; }
> > 
> 
> 
> Do you need ops for the ref and non-ref functions? I would have
> thought you could just have the ref ones since the all the non-ref
> variants do is allocate and then call the ref variant.

Good point. It appears that all the existing ops are only present in the
ref form.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 09:58:30 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 09: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.xensource.com>)
	id 1RYEGX-0004Rm-QG; Wed, 07 Dec 2011 09:58:17 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RYEGW-0004RD-FE
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 09:58:16 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1323251817!51437485!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjA3NQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16660 invoked from network); 7 Dec 2011 09:56:57 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Dec 2011 09:56:57 -0000
X-IronPort-AV: E=Sophos;i="4.71,313,1320624000"; 
   d="scan'208";a="9336778"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Dec 2011 09:57:29 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 7 Dec 2011
	09:57:29 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Paul Durrant <Paul.Durrant@citrix.com>
Date: Wed, 7 Dec 2011 09:57:29 +0000
In-Reply-To: <291EDFCB1E9E224A99088639C4762022B5988E542E@LONPMAILBOX01.citrite.net>
References: <4EDDF41E.8070200@oracle.com>
	<1323168999-4434-1-git-send-email-annie.li@oracle.com>
	<1323171726.23681.65.camel@zakaz.uk.xensource.com>
	<4EDEDF2E.3040204@oracle.com>
	<291EDFCB1E9E224A99088639C4762022B5988E542E@LONPMAILBOX01.citrite.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323251849.23681.128.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "jeremy@goop.org" <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	"kurt.hackel@oracle.com" <kurt.hackel@oracle.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	ANNIE LI <annie.li@oracle.com>
Subject: Re: [Xen-devel] [PATCH 1/2] xen/granttable: Support sub-page grants
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2011-12-07 at 08:59 +0000, Paul Durrant wrote:
> > gnttab_v2_ops = {
> >   ...
> > .access_subpage = access_subpage_v2;
> > .access_ref_subpage = access_ref_subpage_v2; .access_trans =
> > access_trans_v2; .access_ref_trans = access_ref_trans_v2; }
> > 
> 
> 
> Do you need ops for the ref and non-ref functions? I would have
> thought you could just have the ref ones since the all the non-ref
> variants do is allocate and then call the ref variant.

Good point. It appears that all the existing ops are only present in the
ref form.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 10:00:26 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 10:00:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYEIK-0004g7-Bn; Wed, 07 Dec 2011 10:00:08 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RYEIJ-0004fv-KR
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 10:00:07 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1323251921!48850096!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM1ODk=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13874 invoked from network); 7 Dec 2011 09:58:41 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-3.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 7 Dec 2011 09:58:41 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 07 Dec 2011 09:59:22 +0000
Message-Id: <4EDF47360200007800065E7C@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 07 Dec 2011 10:00:06 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Stefano Stabellini" <stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1112061753410.31179@kaball-desktop>
	<1323195609-17277-7-git-send-email-stefano.stabellini@eu.citrix.com>
In-Reply-To: <1323195609-17277-7-git-send-email-stefano.stabellini@eu.citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com, Ian Campbell <ian.campbell@citrix.com>,
	Tim.Deegan@citrix.com
Subject: Re: [Xen-devel] [PATCH RFC 07/25] xen/common/Makefile: introduce
 HAS_CPUFREQ, HAS_PCI, HAS_PASSTHROUGH, HAS_NS16550
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 06.12.11 at 19:19, <stefano.stabellini@eu.citrix.com> wrote:
> From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> 
> - make the compilation of ns16550.c depend upon HAS_NS16550;
> 
> - make the compilation of cpufreq depend upon HAS_CPUFREQ;
> 
> - make the compilation of pci depend upon HAS_PCI;
> 
> - make the compilation of passthrough depend upon HAS_PASSTHROUGH;
> 
> - make the compilation of kexec.o depend on HAS_ACPI.

How are kexec and ACPI connected to one another?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 10:00:26 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 10:00:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYEIK-0004g7-Bn; Wed, 07 Dec 2011 10:00:08 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RYEIJ-0004fv-KR
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 10:00:07 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1323251921!48850096!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM1ODk=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13874 invoked from network); 7 Dec 2011 09:58:41 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-3.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 7 Dec 2011 09:58:41 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 07 Dec 2011 09:59:22 +0000
Message-Id: <4EDF47360200007800065E7C@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 07 Dec 2011 10:00:06 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Stefano Stabellini" <stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1112061753410.31179@kaball-desktop>
	<1323195609-17277-7-git-send-email-stefano.stabellini@eu.citrix.com>
In-Reply-To: <1323195609-17277-7-git-send-email-stefano.stabellini@eu.citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com, Ian Campbell <ian.campbell@citrix.com>,
	Tim.Deegan@citrix.com
Subject: Re: [Xen-devel] [PATCH RFC 07/25] xen/common/Makefile: introduce
 HAS_CPUFREQ, HAS_PCI, HAS_PASSTHROUGH, HAS_NS16550
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 06.12.11 at 19:19, <stefano.stabellini@eu.citrix.com> wrote:
> From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> 
> - make the compilation of ns16550.c depend upon HAS_NS16550;
> 
> - make the compilation of cpufreq depend upon HAS_CPUFREQ;
> 
> - make the compilation of pci depend upon HAS_PCI;
> 
> - make the compilation of passthrough depend upon HAS_PASSTHROUGH;
> 
> - make the compilation of kexec.o depend on HAS_ACPI.

How are kexec and ACPI connected to one another?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 10:29:05 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 10:29:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYEjx-0005Qb-OK; Wed, 07 Dec 2011 10:28:41 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <annie.li@oracle.com>) id 1RYEjw-0005QV-7m
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 10:28:40 +0000
X-Env-Sender: annie.li@oracle.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1323253671!4400785!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDM3NjQx\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10546 invoked from network); 7 Dec 2011 10:27:53 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-16.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 7 Dec 2011 10:27:53 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pB7ARlRN006816
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 7 Dec 2011 10:27:48 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pB7ARkkV025205
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 7 Dec 2011 10:27:47 GMT
Received: from abhmt116.oracle.com (abhmt116.oracle.com [141.146.116.68])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pB7AReIJ019550; Wed, 7 Dec 2011 04:27:40 -0600
Received: from [10.182.39.81] (/10.182.39.81)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 07 Dec 2011 02:27:39 -0800
Message-ID: <4EDF3F96.8030600@oracle.com>
Date: Wed, 07 Dec 2011 18:27:34 +0800
From: ANNIE LI <annie.li@oracle.com>
Organization: Oracle Corporation
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.9.2.23) Gecko/20110920 Thunderbird/3.1.15
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <4EDDF41E.8070200@oracle.com>	
	<1323168999-4434-1-git-send-email-annie.li@oracle.com>	
	<1323171726.23681.65.camel@zakaz.uk.xensource.com>	
	<4EDEDF2E.3040204@oracle.com>
	<1323251784.23681.126.camel@zakaz.uk.xensource.com>
In-Reply-To: <1323251784.23681.126.camel@zakaz.uk.xensource.com>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090206.4EDF3FA4.0132,ss=1,re=0.000,fgs=0
Cc: "jeremy@goop.org" <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	"kurt.hackel@oracle.com" <kurt.hackel@oracle.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Paul Durrant <Paul.Durrant@citrix.com>
Subject: Re: [Xen-devel] [PATCH 1/2] xen/granttable: Support sub-page grants
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com



On 2011-12-7 17:56, Ian Campbell wrote:
> On Wed, 2011-12-07 at 03:36 +0000, ANNIE LI wrote:
>> Thanks for your reviewing, Ian.
>>>>    EXPORT_SYMBOL_GPL(gnttab_grant_foreign_access);
>>>>
>>>> +int gnttab_grant_foreign_access_subpage_v2(domid_t domid, unsigned long frame,
>>>> +					   int flags, unsigned page_off,
>>>> +					   unsigned length)
>>> Please drop the v2 suffixes on the public functions.
>> OK, the initial interface is without v2 suffixes. It was added in order
>> to reminder user the interfaces are only available for grant table v2.
>> But I am fine to remove it, and following ops fn pointers are better.
>>> Any reason not to route these via the ops table for consistency with all
>>> the other ops? Then your availability check becomes a test for NULL fn
>>> pointer rather than a specific version.
>> Ok, it is good.
>> How about following implements?
> Looks to be along the right lines. Thanks.
>
>> gnttab_v1_ops = {
>>    ...
>> .access_subpage = NULL;
>> .access_ref_subpage = NULL;
>> .access_trans = NULL;
>> .access_ref_trans = NULL;
>> }
> I think you can omit these since NULL is the default but perhaps
> explicitly listing them is useful in a self documenting type way.
>
> [...]
OK, I can delete those.
>> Same operations for access_ref_subpage, access_trans and access_ref_trans.
>>
>> bool gnttab_subpage_available()
>> {
>>        return (gnttab_interface->access_subpage != NULL);
>> }
>>
>> bool gnttab_subpage_available()
> Typo:       ..trans..
Thanks for pointing out this.

Thanks
Annie
>> {
>>        return (gnttab_interface->access_trans != NULL);
>> }
> Ian.
>
>> Thanks
>> Annie
>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 10:29:05 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 10:29:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYEjx-0005Qb-OK; Wed, 07 Dec 2011 10:28:41 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <annie.li@oracle.com>) id 1RYEjw-0005QV-7m
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 10:28:40 +0000
X-Env-Sender: annie.li@oracle.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1323253671!4400785!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDM3NjQx\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10546 invoked from network); 7 Dec 2011 10:27:53 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-16.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 7 Dec 2011 10:27:53 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pB7ARlRN006816
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 7 Dec 2011 10:27:48 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pB7ARkkV025205
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 7 Dec 2011 10:27:47 GMT
Received: from abhmt116.oracle.com (abhmt116.oracle.com [141.146.116.68])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pB7AReIJ019550; Wed, 7 Dec 2011 04:27:40 -0600
Received: from [10.182.39.81] (/10.182.39.81)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 07 Dec 2011 02:27:39 -0800
Message-ID: <4EDF3F96.8030600@oracle.com>
Date: Wed, 07 Dec 2011 18:27:34 +0800
From: ANNIE LI <annie.li@oracle.com>
Organization: Oracle Corporation
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.9.2.23) Gecko/20110920 Thunderbird/3.1.15
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <4EDDF41E.8070200@oracle.com>	
	<1323168999-4434-1-git-send-email-annie.li@oracle.com>	
	<1323171726.23681.65.camel@zakaz.uk.xensource.com>	
	<4EDEDF2E.3040204@oracle.com>
	<1323251784.23681.126.camel@zakaz.uk.xensource.com>
In-Reply-To: <1323251784.23681.126.camel@zakaz.uk.xensource.com>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090206.4EDF3FA4.0132,ss=1,re=0.000,fgs=0
Cc: "jeremy@goop.org" <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	"kurt.hackel@oracle.com" <kurt.hackel@oracle.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Paul Durrant <Paul.Durrant@citrix.com>
Subject: Re: [Xen-devel] [PATCH 1/2] xen/granttable: Support sub-page grants
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com



On 2011-12-7 17:56, Ian Campbell wrote:
> On Wed, 2011-12-07 at 03:36 +0000, ANNIE LI wrote:
>> Thanks for your reviewing, Ian.
>>>>    EXPORT_SYMBOL_GPL(gnttab_grant_foreign_access);
>>>>
>>>> +int gnttab_grant_foreign_access_subpage_v2(domid_t domid, unsigned long frame,
>>>> +					   int flags, unsigned page_off,
>>>> +					   unsigned length)
>>> Please drop the v2 suffixes on the public functions.
>> OK, the initial interface is without v2 suffixes. It was added in order
>> to reminder user the interfaces are only available for grant table v2.
>> But I am fine to remove it, and following ops fn pointers are better.
>>> Any reason not to route these via the ops table for consistency with all
>>> the other ops? Then your availability check becomes a test for NULL fn
>>> pointer rather than a specific version.
>> Ok, it is good.
>> How about following implements?
> Looks to be along the right lines. Thanks.
>
>> gnttab_v1_ops = {
>>    ...
>> .access_subpage = NULL;
>> .access_ref_subpage = NULL;
>> .access_trans = NULL;
>> .access_ref_trans = NULL;
>> }
> I think you can omit these since NULL is the default but perhaps
> explicitly listing them is useful in a self documenting type way.
>
> [...]
OK, I can delete those.
>> Same operations for access_ref_subpage, access_trans and access_ref_trans.
>>
>> bool gnttab_subpage_available()
>> {
>>        return (gnttab_interface->access_subpage != NULL);
>> }
>>
>> bool gnttab_subpage_available()
> Typo:       ..trans..
Thanks for pointing out this.

Thanks
Annie
>> {
>>        return (gnttab_interface->access_trans != NULL);
>> }
> Ian.
>
>> Thanks
>> Annie
>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 10:29:06 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 10:29:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYEk0-0005Qm-51; Wed, 07 Dec 2011 10:28:44 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <annie.li@oracle.com>) id 1RYEjz-0005QW-Ac
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 10:28:43 +0000
X-Env-Sender: annie.li@oracle.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1323253675!4394556!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQzMzg5Nw==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5022 invoked from network); 7 Dec 2011 10:27:56 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-15.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 7 Dec 2011 10:27:56 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pB7ARp2L004967
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 7 Dec 2011 10:27:52 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pB7ARo5L009858
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 7 Dec 2011 10:27:51 GMT
Received: from abhmt108.oracle.com (abhmt108.oracle.com [141.146.116.60])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pB7ARhRK001456; Wed, 7 Dec 2011 04:27:43 -0600
Received: from [10.182.39.81] (/10.182.39.81)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 07 Dec 2011 02:27:43 -0800
Message-ID: <4EDF3F9B.4030407@oracle.com>
Date: Wed, 07 Dec 2011 18:27:39 +0800
From: ANNIE LI <annie.li@oracle.com>
Organization: Oracle Corporation
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.9.2.23) Gecko/20110920 Thunderbird/3.1.15
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <4EDDF41E.8070200@oracle.com>	
	<1323168999-4434-1-git-send-email-annie.li@oracle.com>	
	<1323171726.23681.65.camel@zakaz.uk.xensource.com>	
	<4EDEDF2E.3040204@oracle.com>	
	<291EDFCB1E9E224A99088639C4762022B5988E542E@LONPMAILBOX01.citrite.net>
	<1323251849.23681.128.camel@zakaz.uk.xensource.com>
In-Reply-To: <1323251849.23681.128.camel@zakaz.uk.xensource.com>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090203.4EDF3FA9.001D,ss=1,re=0.000,fgs=0
Cc: "jeremy@goop.org" <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	"kurt.hackel@oracle.com" <kurt.hackel@oracle.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Paul Durrant <Paul.Durrant@citrix.com>
Subject: Re: [Xen-devel] [PATCH 1/2] xen/granttable: Support sub-page grants
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com



On 2011-12-7 17:57, Ian Campbell wrote:
> On Wed, 2011-12-07 at 08:59 +0000, Paul Durrant wrote:
>>> gnttab_v2_ops = {
>>>    ...
>>> .access_subpage = access_subpage_v2;
>>> .access_ref_subpage = access_ref_subpage_v2; .access_trans =
>>> access_trans_v2; .access_ref_trans = access_ref_trans_v2; }
>>>
>>
>> Do you need ops for the ref and non-ref functions? I would have
>> thought you could just have the ref ones since the all the non-ref
>> variants do is allocate and then call the ref variant.
> Good point. It appears that all the existing ops are only present in the
> ref form.
So I will add two elements: access_ref_subpage and access_ref_trans into 
gnttab_v2_ops.

Thanks
Annie
> Ian.
>
>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 10:29:06 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 10:29:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYEk0-0005Qm-51; Wed, 07 Dec 2011 10:28:44 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <annie.li@oracle.com>) id 1RYEjz-0005QW-Ac
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 10:28:43 +0000
X-Env-Sender: annie.li@oracle.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1323253675!4394556!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQzMzg5Nw==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5022 invoked from network); 7 Dec 2011 10:27:56 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-15.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 7 Dec 2011 10:27:56 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pB7ARp2L004967
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 7 Dec 2011 10:27:52 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pB7ARo5L009858
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 7 Dec 2011 10:27:51 GMT
Received: from abhmt108.oracle.com (abhmt108.oracle.com [141.146.116.60])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pB7ARhRK001456; Wed, 7 Dec 2011 04:27:43 -0600
Received: from [10.182.39.81] (/10.182.39.81)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 07 Dec 2011 02:27:43 -0800
Message-ID: <4EDF3F9B.4030407@oracle.com>
Date: Wed, 07 Dec 2011 18:27:39 +0800
From: ANNIE LI <annie.li@oracle.com>
Organization: Oracle Corporation
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.9.2.23) Gecko/20110920 Thunderbird/3.1.15
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <4EDDF41E.8070200@oracle.com>	
	<1323168999-4434-1-git-send-email-annie.li@oracle.com>	
	<1323171726.23681.65.camel@zakaz.uk.xensource.com>	
	<4EDEDF2E.3040204@oracle.com>	
	<291EDFCB1E9E224A99088639C4762022B5988E542E@LONPMAILBOX01.citrite.net>
	<1323251849.23681.128.camel@zakaz.uk.xensource.com>
In-Reply-To: <1323251849.23681.128.camel@zakaz.uk.xensource.com>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090203.4EDF3FA9.001D,ss=1,re=0.000,fgs=0
Cc: "jeremy@goop.org" <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	"kurt.hackel@oracle.com" <kurt.hackel@oracle.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Paul Durrant <Paul.Durrant@citrix.com>
Subject: Re: [Xen-devel] [PATCH 1/2] xen/granttable: Support sub-page grants
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com



On 2011-12-7 17:57, Ian Campbell wrote:
> On Wed, 2011-12-07 at 08:59 +0000, Paul Durrant wrote:
>>> gnttab_v2_ops = {
>>>    ...
>>> .access_subpage = access_subpage_v2;
>>> .access_ref_subpage = access_ref_subpage_v2; .access_trans =
>>> access_trans_v2; .access_ref_trans = access_ref_trans_v2; }
>>>
>>
>> Do you need ops for the ref and non-ref functions? I would have
>> thought you could just have the ref ones since the all the non-ref
>> variants do is allocate and then call the ref variant.
> Good point. It appears that all the existing ops are only present in the
> ref form.
So I will add two elements: access_ref_subpage and access_ref_trans into 
gnttab_v2_ops.

Thanks
Annie
> Ian.
>
>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 10:35:07 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 10:35:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYEpp-0005jA-2E; Wed, 07 Dec 2011 10:34:45 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RYEpn-0005iy-UC
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 10:34:44 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1323254037!6497357!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjA3NQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5765 invoked from network); 7 Dec 2011 10:33:57 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Dec 2011 10:33:57 -0000
X-IronPort-AV: E=Sophos;i="4.71,313,1320624000"; 
   d="scan'208";a="9337742"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Dec 2011 10:33:57 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 7 Dec 2011
	10:33:56 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: ANNIE LI <annie.li@oracle.com>
Date: Wed, 7 Dec 2011 10:33:56 +0000
In-Reply-To: <4EDF3F9B.4030407@oracle.com>
References: <4EDDF41E.8070200@oracle.com>
	<1323168999-4434-1-git-send-email-annie.li@oracle.com>
	<1323171726.23681.65.camel@zakaz.uk.xensource.com>
	<4EDEDF2E.3040204@oracle.com>
	<291EDFCB1E9E224A99088639C4762022B5988E542E@LONPMAILBOX01.citrite.net>
	<1323251849.23681.128.camel@zakaz.uk.xensource.com>
	<4EDF3F9B.4030407@oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323254036.23681.142.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "jeremy@goop.org" <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	"kurt.hackel@oracle.com" <kurt.hackel@oracle.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Paul Durrant <Paul.Durrant@citrix.com>
Subject: Re: [Xen-devel] [PATCH 1/2] xen/granttable: Support sub-page grants
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2011-12-07 at 10:27 +0000, ANNIE LI wrote:
> 
> On 2011-12-7 17:57, Ian Campbell wrote:
> > On Wed, 2011-12-07 at 08:59 +0000, Paul Durrant wrote:
> >>> gnttab_v2_ops = {
> >>>    ...
> >>> .access_subpage = access_subpage_v2;
> >>> .access_ref_subpage = access_ref_subpage_v2; .access_trans =
> >>> access_trans_v2; .access_ref_trans = access_ref_trans_v2; }
> >>>
> >>
> >> Do you need ops for the ref and non-ref functions? I would have
> >> thought you could just have the ref ones since the all the non-ref
> >> variants do is allocate and then call the ref variant.
> > Good point. It appears that all the existing ops are only present in the
> > ref form.
> So I will add two elements: access_ref_subpage and access_ref_trans into 
> gnttab_v2_ops.

The existing convention seems to be for _ref to be a suffix, although
it's only actually used on the end_*_ref ones.
+       int (*end_foreign_access_ref)(grant_ref_t, int);
+       unsigned long (*end_foreign_transfer_ref)(grant_ref_t);

Also it occurs to me that access_* sounds like something which uses a
ref rather than something which sets one up. The existing hook to setup
a normal grant is called "update_entry". Perhaps
update_{subpage,transitive}_entry?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 10:35:07 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 10:35:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYEpp-0005jA-2E; Wed, 07 Dec 2011 10:34:45 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RYEpn-0005iy-UC
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 10:34:44 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1323254037!6497357!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjA3NQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5765 invoked from network); 7 Dec 2011 10:33:57 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Dec 2011 10:33:57 -0000
X-IronPort-AV: E=Sophos;i="4.71,313,1320624000"; 
   d="scan'208";a="9337742"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Dec 2011 10:33:57 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 7 Dec 2011
	10:33:56 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: ANNIE LI <annie.li@oracle.com>
Date: Wed, 7 Dec 2011 10:33:56 +0000
In-Reply-To: <4EDF3F9B.4030407@oracle.com>
References: <4EDDF41E.8070200@oracle.com>
	<1323168999-4434-1-git-send-email-annie.li@oracle.com>
	<1323171726.23681.65.camel@zakaz.uk.xensource.com>
	<4EDEDF2E.3040204@oracle.com>
	<291EDFCB1E9E224A99088639C4762022B5988E542E@LONPMAILBOX01.citrite.net>
	<1323251849.23681.128.camel@zakaz.uk.xensource.com>
	<4EDF3F9B.4030407@oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323254036.23681.142.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "jeremy@goop.org" <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	"kurt.hackel@oracle.com" <kurt.hackel@oracle.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Paul Durrant <Paul.Durrant@citrix.com>
Subject: Re: [Xen-devel] [PATCH 1/2] xen/granttable: Support sub-page grants
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2011-12-07 at 10:27 +0000, ANNIE LI wrote:
> 
> On 2011-12-7 17:57, Ian Campbell wrote:
> > On Wed, 2011-12-07 at 08:59 +0000, Paul Durrant wrote:
> >>> gnttab_v2_ops = {
> >>>    ...
> >>> .access_subpage = access_subpage_v2;
> >>> .access_ref_subpage = access_ref_subpage_v2; .access_trans =
> >>> access_trans_v2; .access_ref_trans = access_ref_trans_v2; }
> >>>
> >>
> >> Do you need ops for the ref and non-ref functions? I would have
> >> thought you could just have the ref ones since the all the non-ref
> >> variants do is allocate and then call the ref variant.
> > Good point. It appears that all the existing ops are only present in the
> > ref form.
> So I will add two elements: access_ref_subpage and access_ref_trans into 
> gnttab_v2_ops.

The existing convention seems to be for _ref to be a suffix, although
it's only actually used on the end_*_ref ones.
+       int (*end_foreign_access_ref)(grant_ref_t, int);
+       unsigned long (*end_foreign_transfer_ref)(grant_ref_t);

Also it occurs to me that access_* sounds like something which uses a
ref rather than something which sets one up. The existing hook to setup
a normal grant is called "update_entry". Perhaps
update_{subpage,transitive}_entry?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 10:38:20 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 10:38:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYEsx-0005rN-PX; Wed, 07 Dec 2011 10:37:59 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <annie.li@oracle.com>) id 1RYEsw-0005rH-EO
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 10:37:58 +0000
X-Env-Sender: annie.li@oracle.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1323254229!4537074!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQzMzg5Nw==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11449 invoked from network); 7 Dec 2011 10:37:11 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-12.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 7 Dec 2011 10:37:11 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pB7Ab6rK016901
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 7 Dec 2011 10:37:07 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pB7Ab5Fr023387
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 7 Dec 2011 10:37:05 GMT
Received: from abhmt107.oracle.com (abhmt107.oracle.com [141.146.116.59])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pB7Ab06C007966; Wed, 7 Dec 2011 04:37:00 -0600
Received: from [10.182.39.81] (/10.182.39.81)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 07 Dec 2011 02:36:59 -0800
Message-ID: <4EDF41C5.1030105@oracle.com>
Date: Wed, 07 Dec 2011 18:36:53 +0800
From: ANNIE LI <annie.li@oracle.com>
Organization: Oracle Corporation
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.9.2.23) Gecko/20110920 Thunderbird/3.1.15
MIME-Version: 1.0
To: jeremy@goop.org, paul.durrant@citrix.com, Ian.Campbell@citrix.com
References: <4EDDF41E.8070200@oracle.com>
	<1323168999-4434-1-git-send-email-annie.li@oracle.com>
In-Reply-To: <1323168999-4434-1-git-send-email-annie.li@oracle.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090208.4EDF41D3.00A2,ss=1,re=0.000,fgs=0
Cc: kurt.hackel@oracle.com, annie.li@oracle.com, xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org, konrad.wilk@oracle.com
Subject: Re: [Xen-devel] [PATCH 1/2] xen/granttable: Support sub-page grants
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


> +void gnttab_grant_foreign_access_ref_subpage_v2(grant_ref_t ref, domid_t domid,
> +						unsigned long frame, int flags,
> +						unsigned page_off,
> +						unsigned length)
> +{
> +	BUG_ON(flags&  (GTF_accept_transfer | GTF_reading |
> +			GTF_writing | GTF_transitive));
This is slightly changed from the initial code, welcome your suggestions.

Initial condition is:
BUG_ON(flags & (GTF_accept_transfer | GTF_reading | GTF_writing | 
GTF_sub_page | GTF_permit_access));

GTF_sub_page | GTF_permit_access will be set later in this function, so 
it is necessary to verify this flag here.
GTF_transitive and GTF_sub_page can not be enabled at same time, so 
GTF_transitive is checked here to avoid those two flags are both enabled.

Same code was changed in corresponding transitive function.

Thanks
Annie
> +	BUG_ON(grant_table_version == 1);
> +	gnttab_shared.v2[ref].sub_page.frame = frame;
> +	gnttab_shared.v2[ref].sub_page.page_off = page_off;
> +	gnttab_shared.v2[ref].sub_page.length = length;
> +	gnttab_shared.v2[ref].hdr.domid = domid;
> +	wmb();
> +	gnttab_shared.v2[ref].hdr.flags =
> +				GTF_permit_access | GTF_sub_page | flags;
> +}
>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 10:38:20 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 10:38:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYEsx-0005rN-PX; Wed, 07 Dec 2011 10:37:59 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <annie.li@oracle.com>) id 1RYEsw-0005rH-EO
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 10:37:58 +0000
X-Env-Sender: annie.li@oracle.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1323254229!4537074!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQzMzg5Nw==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11449 invoked from network); 7 Dec 2011 10:37:11 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-12.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 7 Dec 2011 10:37:11 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pB7Ab6rK016901
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 7 Dec 2011 10:37:07 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pB7Ab5Fr023387
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 7 Dec 2011 10:37:05 GMT
Received: from abhmt107.oracle.com (abhmt107.oracle.com [141.146.116.59])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pB7Ab06C007966; Wed, 7 Dec 2011 04:37:00 -0600
Received: from [10.182.39.81] (/10.182.39.81)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 07 Dec 2011 02:36:59 -0800
Message-ID: <4EDF41C5.1030105@oracle.com>
Date: Wed, 07 Dec 2011 18:36:53 +0800
From: ANNIE LI <annie.li@oracle.com>
Organization: Oracle Corporation
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.9.2.23) Gecko/20110920 Thunderbird/3.1.15
MIME-Version: 1.0
To: jeremy@goop.org, paul.durrant@citrix.com, Ian.Campbell@citrix.com
References: <4EDDF41E.8070200@oracle.com>
	<1323168999-4434-1-git-send-email-annie.li@oracle.com>
In-Reply-To: <1323168999-4434-1-git-send-email-annie.li@oracle.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090208.4EDF41D3.00A2,ss=1,re=0.000,fgs=0
Cc: kurt.hackel@oracle.com, annie.li@oracle.com, xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org, konrad.wilk@oracle.com
Subject: Re: [Xen-devel] [PATCH 1/2] xen/granttable: Support sub-page grants
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


> +void gnttab_grant_foreign_access_ref_subpage_v2(grant_ref_t ref, domid_t domid,
> +						unsigned long frame, int flags,
> +						unsigned page_off,
> +						unsigned length)
> +{
> +	BUG_ON(flags&  (GTF_accept_transfer | GTF_reading |
> +			GTF_writing | GTF_transitive));
This is slightly changed from the initial code, welcome your suggestions.

Initial condition is:
BUG_ON(flags & (GTF_accept_transfer | GTF_reading | GTF_writing | 
GTF_sub_page | GTF_permit_access));

GTF_sub_page | GTF_permit_access will be set later in this function, so 
it is necessary to verify this flag here.
GTF_transitive and GTF_sub_page can not be enabled at same time, so 
GTF_transitive is checked here to avoid those two flags are both enabled.

Same code was changed in corresponding transitive function.

Thanks
Annie
> +	BUG_ON(grant_table_version == 1);
> +	gnttab_shared.v2[ref].sub_page.frame = frame;
> +	gnttab_shared.v2[ref].sub_page.page_off = page_off;
> +	gnttab_shared.v2[ref].sub_page.length = length;
> +	gnttab_shared.v2[ref].hdr.domid = domid;
> +	wmb();
> +	gnttab_shared.v2[ref].hdr.flags =
> +				GTF_permit_access | GTF_sub_page | flags;
> +}
>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 10:54:44 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 10:54:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYF8j-00068A-PI; Wed, 07 Dec 2011 10:54:17 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <annie.li@oracle.com>) id 1RYF8i-000685-5E
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 10:54:16 +0000
X-Env-Sender: annie.li@oracle.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1323255047!7104123!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQzMzg5Nw==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1328 invoked from network); 7 Dec 2011 10:50:49 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-11.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 7 Dec 2011 10:50:49 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pB7AoixV032481
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 7 Dec 2011 10:50:45 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pB7Aoheh015433
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 7 Dec 2011 10:50:43 GMT
Received: from abhmt111.oracle.com (abhmt111.oracle.com [141.146.116.63])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pB7AobFu002516; Wed, 7 Dec 2011 04:50:37 -0600
Received: from [10.182.39.81] (/10.182.39.81)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 07 Dec 2011 02:50:37 -0800
Message-ID: <4EDF44F8.8060206@oracle.com>
Date: Wed, 07 Dec 2011 18:50:32 +0800
From: ANNIE LI <annie.li@oracle.com>
Organization: Oracle Corporation
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.9.2.23) Gecko/20110920 Thunderbird/3.1.15
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <4EDDF41E.8070200@oracle.com>	
	<1323168999-4434-1-git-send-email-annie.li@oracle.com>	
	<1323171726.23681.65.camel@zakaz.uk.xensource.com>	
	<4EDEDF2E.3040204@oracle.com>	
	<291EDFCB1E9E224A99088639C4762022B5988E542E@LONPMAILBOX01.citrite.net>	
	<1323251849.23681.128.camel@zakaz.uk.xensource.com>	
	<4EDF3F9B.4030407@oracle.com>
	<1323254036.23681.142.camel@zakaz.uk.xensource.com>
In-Reply-To: <1323254036.23681.142.camel@zakaz.uk.xensource.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090209.4EDF4505.00E6,ss=1,re=0.000,fgs=0
Cc: "jeremy@goop.org" <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	"kurt.hackel@oracle.com" <kurt.hackel@oracle.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Paul Durrant <Paul.Durrant@citrix.com>
Subject: Re: [Xen-devel] [PATCH 1/2] xen/granttable: Support sub-page grants
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


> The existing convention seems to be for _ref to be a suffix, although
> it's only actually used on the end_*_ref ones.
> +       int (*end_foreign_access_ref)(grant_ref_t, int);
> +       unsigned long (*end_foreign_transfer_ref)(grant_ref_t);
>
> Also it occurs to me that access_* sounds like something which uses a
> ref rather than something which sets one up. The existing hook to setup
> a normal grant is called "update_entry". Perhaps
> update_{subpage,transitive}_entry?
Yes, you are right.
Just like the existing code:
gnttab_grant_foreign_access   VS   gnttab_grant_foreign_access_subpage
update_entry in gnttab_grant_foreign_access_ref  VS  
update_{subpage,transitive}_entry in 
gnttab_grant_foreign_access_{subpage,trans}_ref

Thanks
Annie

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 10:54:44 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 10:54:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYF8j-00068A-PI; Wed, 07 Dec 2011 10:54:17 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <annie.li@oracle.com>) id 1RYF8i-000685-5E
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 10:54:16 +0000
X-Env-Sender: annie.li@oracle.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1323255047!7104123!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQzMzg5Nw==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1328 invoked from network); 7 Dec 2011 10:50:49 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-11.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 7 Dec 2011 10:50:49 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pB7AoixV032481
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 7 Dec 2011 10:50:45 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pB7Aoheh015433
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 7 Dec 2011 10:50:43 GMT
Received: from abhmt111.oracle.com (abhmt111.oracle.com [141.146.116.63])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pB7AobFu002516; Wed, 7 Dec 2011 04:50:37 -0600
Received: from [10.182.39.81] (/10.182.39.81)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 07 Dec 2011 02:50:37 -0800
Message-ID: <4EDF44F8.8060206@oracle.com>
Date: Wed, 07 Dec 2011 18:50:32 +0800
From: ANNIE LI <annie.li@oracle.com>
Organization: Oracle Corporation
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.9.2.23) Gecko/20110920 Thunderbird/3.1.15
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <4EDDF41E.8070200@oracle.com>	
	<1323168999-4434-1-git-send-email-annie.li@oracle.com>	
	<1323171726.23681.65.camel@zakaz.uk.xensource.com>	
	<4EDEDF2E.3040204@oracle.com>	
	<291EDFCB1E9E224A99088639C4762022B5988E542E@LONPMAILBOX01.citrite.net>	
	<1323251849.23681.128.camel@zakaz.uk.xensource.com>	
	<4EDF3F9B.4030407@oracle.com>
	<1323254036.23681.142.camel@zakaz.uk.xensource.com>
In-Reply-To: <1323254036.23681.142.camel@zakaz.uk.xensource.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090209.4EDF4505.00E6,ss=1,re=0.000,fgs=0
Cc: "jeremy@goop.org" <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	"kurt.hackel@oracle.com" <kurt.hackel@oracle.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Paul Durrant <Paul.Durrant@citrix.com>
Subject: Re: [Xen-devel] [PATCH 1/2] xen/granttable: Support sub-page grants
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


> The existing convention seems to be for _ref to be a suffix, although
> it's only actually used on the end_*_ref ones.
> +       int (*end_foreign_access_ref)(grant_ref_t, int);
> +       unsigned long (*end_foreign_transfer_ref)(grant_ref_t);
>
> Also it occurs to me that access_* sounds like something which uses a
> ref rather than something which sets one up. The existing hook to setup
> a normal grant is called "update_entry". Perhaps
> update_{subpage,transitive}_entry?
Yes, you are right.
Just like the existing code:
gnttab_grant_foreign_access   VS   gnttab_grant_foreign_access_subpage
update_entry in gnttab_grant_foreign_access_ref  VS  
update_{subpage,transitive}_entry in 
gnttab_grant_foreign_access_{subpage,trans}_ref

Thanks
Annie

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 11:02:19 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 11:02:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYFG4-0006M5-NN; Wed, 07 Dec 2011 11:01:52 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <shandivo@gmail.com>) id 1RYFG3-0006Lx-8G
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 11:01:51 +0000
X-Env-Sender: shandivo@gmail.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1323255662!997089!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14057 invoked from network); 7 Dec 2011 11:01:04 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-9.tower-21.messagelabs.com with AES256-SHA encrypted SMTP;
	7 Dec 2011 11:01:04 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <shandivo@gmail.com>) id 1RYFFG-0007By-3W
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 03:01:02 -0800
Date: Wed, 7 Dec 2011 03:01:02 -0800 (PST)
From: n4rC0t1C <shandivo@gmail.com>
To: xen-devel@lists.xensource.com
Message-ID: <1323255662102-5055204.post@n5.nabble.com>
In-Reply-To: <1323210509.34541.YahooMailNeo@web29813.mail.ird.yahoo.com>
References: <1319630071722-4939528.post@n5.nabble.com>
	<1319636130.20499.YahooMailNeo@web29808.mail.ird.yahoo.com>
	<1319695116310-4942047.post@n5.nabble.com>
	<1319710499.206.YahooMailNeo@web29804.mail.ird.yahoo.com>
	<1323123990448-5050354.post@n5.nabble.com>
	<1323170568.90631.YahooMailNeo@web29813.mail.ird.yahoo.com>
	<1323173094434-5051880.post@n5.nabble.com>
	<1323179850.78658.YahooMailNeo@web29801.mail.ird.yahoo.com>
	<201112061619.56224.tobias.geiger@vido.info>
	<1323210509.34541.YahooMailNeo@web29813.mail.ird.yahoo.com>
MIME-Version: 1.0
Subject: Re: [Xen-devel] Re : Re : Re : Re : Re : Re : Re : Re : Re : Re:
 Patches for VGA-Passthrough XEN 4.2 unstable
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Same happens to me, my domU freezes, dom0 is still usable. Sometimes domU
boots, but it's completely unusable due to graphics artifacts every time you
launch an application or move the mouse.

Ivo

--
View this message in context: http://xen.1045712.n5.nabble.com/Patches-for-VGA-Passthrough-XEN-4-2-unstable-tp4406265p5055204.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 11:02:19 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 11:02:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYFG4-0006M5-NN; Wed, 07 Dec 2011 11:01:52 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <shandivo@gmail.com>) id 1RYFG3-0006Lx-8G
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 11:01:51 +0000
X-Env-Sender: shandivo@gmail.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1323255662!997089!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14057 invoked from network); 7 Dec 2011 11:01:04 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-9.tower-21.messagelabs.com with AES256-SHA encrypted SMTP;
	7 Dec 2011 11:01:04 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <shandivo@gmail.com>) id 1RYFFG-0007By-3W
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 03:01:02 -0800
Date: Wed, 7 Dec 2011 03:01:02 -0800 (PST)
From: n4rC0t1C <shandivo@gmail.com>
To: xen-devel@lists.xensource.com
Message-ID: <1323255662102-5055204.post@n5.nabble.com>
In-Reply-To: <1323210509.34541.YahooMailNeo@web29813.mail.ird.yahoo.com>
References: <1319630071722-4939528.post@n5.nabble.com>
	<1319636130.20499.YahooMailNeo@web29808.mail.ird.yahoo.com>
	<1319695116310-4942047.post@n5.nabble.com>
	<1319710499.206.YahooMailNeo@web29804.mail.ird.yahoo.com>
	<1323123990448-5050354.post@n5.nabble.com>
	<1323170568.90631.YahooMailNeo@web29813.mail.ird.yahoo.com>
	<1323173094434-5051880.post@n5.nabble.com>
	<1323179850.78658.YahooMailNeo@web29801.mail.ird.yahoo.com>
	<201112061619.56224.tobias.geiger@vido.info>
	<1323210509.34541.YahooMailNeo@web29813.mail.ird.yahoo.com>
MIME-Version: 1.0
Subject: Re: [Xen-devel] Re : Re : Re : Re : Re : Re : Re : Re : Re : Re:
 Patches for VGA-Passthrough XEN 4.2 unstable
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Same happens to me, my domU freezes, dom0 is still usable. Sometimes domU
boots, but it's completely unusable due to graphics artifacts every time you
launch an application or move the mouse.

Ivo

--
View this message in context: http://xen.1045712.n5.nabble.com/Patches-for-VGA-Passthrough-XEN-4-2-unstable-tp4406265p5055204.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 11:02:55 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 11:02:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYFGs-0006PA-AA; Wed, 07 Dec 2011 11:02:42 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <mtosatti@redhat.com>) id 1RYF58-00067J-NI
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 10:50:34 +0000
X-Env-Sender: mtosatti@redhat.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1323254987!4568824!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDYzMzc=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8928 invoked from network); 7 Dec 2011 10:49:47 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-8.tower-174.messagelabs.com with SMTP;
	7 Dec 2011 10:49:47 -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 pB7AnOv8001939
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 7 Dec 2011 05:49:25 -0500
Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199])
	by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id pB7AnO87003663; Wed, 7 Dec 2011 05:49:24 -0500
Received: from amt.cnet (vpn-8-221.rdu.redhat.com [10.11.8.221])
	by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id pB7AnJ6i030295;
	Wed, 7 Dec 2011 05:49:19 -0500
Received: from amt.cnet (amt.cnet [127.0.0.1])
	by amt.cnet (Postfix) with ESMTP id 45BAE6521ED;
	Wed,  7 Dec 2011 08:48:57 -0200 (BRST)
Received: (from marcelo@localhost)
	by amt.cnet (8.14.5/8.14.5/Submit) id pB7AmnRg030742;
	Wed, 7 Dec 2011 08:48:49 -0200
Date: Wed, 7 Dec 2011 08:48:49 -0200
From: Marcelo Tosatti <mtosatti@redhat.com>
To: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
Message-ID: <20111207104849.GA24849@amt.cnet>
References: <20111130085921.23386.89708.sendpatchset@oc5400248562.ibm.com>
	<20111130085959.23386.69166.sendpatchset@oc5400248562.ibm.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20111130085959.23386.69166.sendpatchset@oc5400248562.ibm.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
X-Mailman-Approved-At: Wed, 07 Dec 2011 11:02:40 +0000
Cc: Gleb Natapov <gleb@redhat.com>, Peter Zijlstra <peterz@infradead.org>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>,
	Dave Jiang <dave.jiang@intel.com>, KVM <kvm@vger.kernel.org>,
	x86@kernel.org, Ingo Molnar <mingo@redhat.com>,
	Avi Kivity <avi@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Xen <xen-devel@lists.xensource.com>, Sasha Levin <levinsasha928@gmail.com>,
	Sedat Dilek <sedat.dilek@gmail.com>, Thomas Gleixner <tglx@linutronix.de>,
	Yinghai Lu <yinghai@kernel.org>, Greg Kroah-Hartman <gregkh@suse.de>,
	LKML <linux-kernel@vger.kernel.org>, Dave Hansen <dave@linux.vnet.ibm.com>,
	Suzuki Poulose <suzuki@linux.vnet.ibm.com>
Subject: Re: [Xen-devel] [PATCH RFC V3 2/4] kvm hypervisor : Add a hypercall
 to KVM hypervisor to support pv-ticketlocks
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Nov 30, 2011 at 02:29:59PM +0530, Raghavendra K T wrote:
> Add a hypercall to KVM hypervisor to support pv-ticketlocks 
> 
> KVM_HC_KICK_CPU allows the calling vcpu to kick another vcpu out of halt state.
>     
> The presence of these hypercalls is indicated to guest via
> KVM_FEATURE_KICK_VCPU/KVM_CAP_KICK_VCPU.
> 
> Qemu needs a corresponding patch to pass up the presence of this feature to 
> guest via cpuid. Patch to qemu will be sent separately.
> 
> There is no Xen/KVM hypercall interface to await kick from.
>     
> Signed-off-by: Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>
> Signed-off-by: Suzuki Poulose <suzuki@in.ibm.com>
> Signed-off-by: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
> ---
> diff --git a/arch/x86/include/asm/kvm_para.h b/arch/x86/include/asm/kvm_para.h
> index 734c376..8b1d65d 100644
> --- a/arch/x86/include/asm/kvm_para.h
> +++ b/arch/x86/include/asm/kvm_para.h
> @@ -16,12 +16,14 @@
>  #define KVM_FEATURE_CLOCKSOURCE		0
>  #define KVM_FEATURE_NOP_IO_DELAY	1
>  #define KVM_FEATURE_MMU_OP		2
> +
>  /* This indicates that the new set of kvmclock msrs
>   * are available. The use of 0x11 and 0x12 is deprecated
>   */
>  #define KVM_FEATURE_CLOCKSOURCE2        3
>  #define KVM_FEATURE_ASYNC_PF		4
>  #define KVM_FEATURE_STEAL_TIME		5
> +#define KVM_FEATURE_KICK_VCPU		6
>  
>  /* The last 8 bits are used to indicate how to interpret the flags field
>   * in pvclock structure. If no bits are set, all flags are ignored.
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index c38efd7..6e1c8b4 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -2103,6 +2103,7 @@ int kvm_dev_ioctl_check_extension(long ext)
>  	case KVM_CAP_XSAVE:
>  	case KVM_CAP_ASYNC_PF:
>  	case KVM_CAP_GET_TSC_KHZ:
> +	case KVM_CAP_KICK_VCPU:
>  		r = 1;
>  		break;
>  	case KVM_CAP_COALESCED_MMIO:
> @@ -2577,7 +2578,8 @@ static void do_cpuid_ent(struct kvm_cpuid_entry2 *entry, u32 function,
>  			     (1 << KVM_FEATURE_NOP_IO_DELAY) |
>  			     (1 << KVM_FEATURE_CLOCKSOURCE2) |
>  			     (1 << KVM_FEATURE_ASYNC_PF) |
> -			     (1 << KVM_FEATURE_CLOCKSOURCE_STABLE_BIT);
> +			     (1 << KVM_FEATURE_CLOCKSOURCE_STABLE_BIT) |
> +			     (1 << KVM_FEATURE_KICK_VCPU);
>  
>  		if (sched_info_on())
>  			entry->eax |= (1 << KVM_FEATURE_STEAL_TIME);
> @@ -5305,6 +5307,26 @@ int kvm_hv_hypercall(struct kvm_vcpu *vcpu)
>  	return 1;
>  }
>  
> +/*
> + * kvm_pv_kick_cpu_op:  Kick a vcpu.
> + *
> + * @cpu - vcpu to be kicked.
> + */
> +static void kvm_pv_kick_cpu_op(struct kvm *kvm, int cpu)
> +{
> +	struct kvm_vcpu *vcpu = kvm_get_vcpu(kvm, cpu);
> +	struct kvm_mp_state mp_state;
> +
> +	mp_state.mp_state = KVM_MP_STATE_RUNNABLE;

Since vcpu->mp_state is not protected by a lock, this is potentially racy. For example:

CPU0						CPU1
kvm_pv_kick_cpu_op				running vcpuN
vcpuN->mp_state = KVM_MP_STATE_RUNNABLE;
						kvm_emulate_halt
						vcpuN->mp_state = KVM_MP_STATE_HALTED

Is it harmless to lose a kick?


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 11:02:55 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 11:02:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYFGs-0006PA-AA; Wed, 07 Dec 2011 11:02:42 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <mtosatti@redhat.com>) id 1RYF58-00067J-NI
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 10:50:34 +0000
X-Env-Sender: mtosatti@redhat.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1323254987!4568824!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDYzMzc=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8928 invoked from network); 7 Dec 2011 10:49:47 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-8.tower-174.messagelabs.com with SMTP;
	7 Dec 2011 10:49:47 -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 pB7AnOv8001939
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 7 Dec 2011 05:49:25 -0500
Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199])
	by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id pB7AnO87003663; Wed, 7 Dec 2011 05:49:24 -0500
Received: from amt.cnet (vpn-8-221.rdu.redhat.com [10.11.8.221])
	by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id pB7AnJ6i030295;
	Wed, 7 Dec 2011 05:49:19 -0500
Received: from amt.cnet (amt.cnet [127.0.0.1])
	by amt.cnet (Postfix) with ESMTP id 45BAE6521ED;
	Wed,  7 Dec 2011 08:48:57 -0200 (BRST)
Received: (from marcelo@localhost)
	by amt.cnet (8.14.5/8.14.5/Submit) id pB7AmnRg030742;
	Wed, 7 Dec 2011 08:48:49 -0200
Date: Wed, 7 Dec 2011 08:48:49 -0200
From: Marcelo Tosatti <mtosatti@redhat.com>
To: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
Message-ID: <20111207104849.GA24849@amt.cnet>
References: <20111130085921.23386.89708.sendpatchset@oc5400248562.ibm.com>
	<20111130085959.23386.69166.sendpatchset@oc5400248562.ibm.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20111130085959.23386.69166.sendpatchset@oc5400248562.ibm.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
X-Mailman-Approved-At: Wed, 07 Dec 2011 11:02:40 +0000
Cc: Gleb Natapov <gleb@redhat.com>, Peter Zijlstra <peterz@infradead.org>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>,
	Dave Jiang <dave.jiang@intel.com>, KVM <kvm@vger.kernel.org>,
	x86@kernel.org, Ingo Molnar <mingo@redhat.com>,
	Avi Kivity <avi@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Xen <xen-devel@lists.xensource.com>, Sasha Levin <levinsasha928@gmail.com>,
	Sedat Dilek <sedat.dilek@gmail.com>, Thomas Gleixner <tglx@linutronix.de>,
	Yinghai Lu <yinghai@kernel.org>, Greg Kroah-Hartman <gregkh@suse.de>,
	LKML <linux-kernel@vger.kernel.org>, Dave Hansen <dave@linux.vnet.ibm.com>,
	Suzuki Poulose <suzuki@linux.vnet.ibm.com>
Subject: Re: [Xen-devel] [PATCH RFC V3 2/4] kvm hypervisor : Add a hypercall
 to KVM hypervisor to support pv-ticketlocks
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Nov 30, 2011 at 02:29:59PM +0530, Raghavendra K T wrote:
> Add a hypercall to KVM hypervisor to support pv-ticketlocks 
> 
> KVM_HC_KICK_CPU allows the calling vcpu to kick another vcpu out of halt state.
>     
> The presence of these hypercalls is indicated to guest via
> KVM_FEATURE_KICK_VCPU/KVM_CAP_KICK_VCPU.
> 
> Qemu needs a corresponding patch to pass up the presence of this feature to 
> guest via cpuid. Patch to qemu will be sent separately.
> 
> There is no Xen/KVM hypercall interface to await kick from.
>     
> Signed-off-by: Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>
> Signed-off-by: Suzuki Poulose <suzuki@in.ibm.com>
> Signed-off-by: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
> ---
> diff --git a/arch/x86/include/asm/kvm_para.h b/arch/x86/include/asm/kvm_para.h
> index 734c376..8b1d65d 100644
> --- a/arch/x86/include/asm/kvm_para.h
> +++ b/arch/x86/include/asm/kvm_para.h
> @@ -16,12 +16,14 @@
>  #define KVM_FEATURE_CLOCKSOURCE		0
>  #define KVM_FEATURE_NOP_IO_DELAY	1
>  #define KVM_FEATURE_MMU_OP		2
> +
>  /* This indicates that the new set of kvmclock msrs
>   * are available. The use of 0x11 and 0x12 is deprecated
>   */
>  #define KVM_FEATURE_CLOCKSOURCE2        3
>  #define KVM_FEATURE_ASYNC_PF		4
>  #define KVM_FEATURE_STEAL_TIME		5
> +#define KVM_FEATURE_KICK_VCPU		6
>  
>  /* The last 8 bits are used to indicate how to interpret the flags field
>   * in pvclock structure. If no bits are set, all flags are ignored.
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index c38efd7..6e1c8b4 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -2103,6 +2103,7 @@ int kvm_dev_ioctl_check_extension(long ext)
>  	case KVM_CAP_XSAVE:
>  	case KVM_CAP_ASYNC_PF:
>  	case KVM_CAP_GET_TSC_KHZ:
> +	case KVM_CAP_KICK_VCPU:
>  		r = 1;
>  		break;
>  	case KVM_CAP_COALESCED_MMIO:
> @@ -2577,7 +2578,8 @@ static void do_cpuid_ent(struct kvm_cpuid_entry2 *entry, u32 function,
>  			     (1 << KVM_FEATURE_NOP_IO_DELAY) |
>  			     (1 << KVM_FEATURE_CLOCKSOURCE2) |
>  			     (1 << KVM_FEATURE_ASYNC_PF) |
> -			     (1 << KVM_FEATURE_CLOCKSOURCE_STABLE_BIT);
> +			     (1 << KVM_FEATURE_CLOCKSOURCE_STABLE_BIT) |
> +			     (1 << KVM_FEATURE_KICK_VCPU);
>  
>  		if (sched_info_on())
>  			entry->eax |= (1 << KVM_FEATURE_STEAL_TIME);
> @@ -5305,6 +5307,26 @@ int kvm_hv_hypercall(struct kvm_vcpu *vcpu)
>  	return 1;
>  }
>  
> +/*
> + * kvm_pv_kick_cpu_op:  Kick a vcpu.
> + *
> + * @cpu - vcpu to be kicked.
> + */
> +static void kvm_pv_kick_cpu_op(struct kvm *kvm, int cpu)
> +{
> +	struct kvm_vcpu *vcpu = kvm_get_vcpu(kvm, cpu);
> +	struct kvm_mp_state mp_state;
> +
> +	mp_state.mp_state = KVM_MP_STATE_RUNNABLE;

Since vcpu->mp_state is not protected by a lock, this is potentially racy. For example:

CPU0						CPU1
kvm_pv_kick_cpu_op				running vcpuN
vcpuN->mp_state = KVM_MP_STATE_RUNNABLE;
						kvm_emulate_halt
						vcpuN->mp_state = KVM_MP_STATE_HALTED

Is it harmless to lose a kick?


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 11:02:56 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 11:02:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYFGr-0006Ou-Gv; Wed, 07 Dec 2011 11:02:41 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1RXyFN-0005H7-16
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 16:52:01 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-14.tower-174.messagelabs.com!1323190273!4295454!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15604 invoked from network); 6 Dec 2011 16:51:14 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-14.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 6 Dec 2011 16:51:14 -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
	pB6Gnu2a013297
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Tue, 6 Dec 2011 11:49:57 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pB6GnlW0013293;
	Tue, 6 Dec 2011 11:49:47 -0500
Date: Tue, 6 Dec 2011 12:49:47 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Raghavendra K T <raghukt@linux.vnet.ibm.com>
Message-ID: <20111206164947.GA13184@andromeda.dapyr.net>
References: <20111130085921.23386.89708.sendpatchset@oc5400248562.ibm.com>
	<20111130085959.23386.69166.sendpatchset@oc5400248562.ibm.com>
	<4ED760F1.6080804@redhat.com> <4ED7DA85.5080504@linux.vnet.ibm.com>
	<4EDBB6C2.9050303@linux.vnet.ibm.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4EDBB6C2.9050303@linux.vnet.ibm.com>
User-Agent: Mutt/1.5.9i
X-Mailman-Approved-At: Wed, 07 Dec 2011 11:02:40 +0000
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	Marcelo Tosatti <mtosatti@redhat.com>, KVM <kvm@vger.kernel.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	"H. Peter Anvin" <hpa@zytor.com>, Dave Hansen <dave@linux.vnet.ibm.com>,
	Xen <xen-devel@lists.xensource.com>, Dave Jiang <dave.jiang@intel.com>,
	Gleb Natapov <gleb@redhat.com>, x86@kernel.org,
	Ingo Molnar <mingo@redhat.com>, Avi Kivity <avi@redhat.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>,
	Sasha Levin <levinsasha928@gmail.com>, Sedat Dilek <sedat.dilek@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>, Yinghai Lu <yinghai@kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Greg Kroah-Hartman <gregkh@suse.de>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	LKML <linux-kernel@vger.kernel.org>,
	Suzuki Poulose <suzuki@linux.vnet.ibm.com>
Subject: Re: [Xen-devel] [PATCH RFC V3 2/4] kvm hypervisor : Add a hypercall
	to KVM hypervisor to support pv-ticketlocks
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Sun, Dec 04, 2011 at 11:36:58PM +0530, Raghavendra K T wrote:
> On 12/02/2011 01:20 AM, Raghavendra K T wrote:
> >>Have you tested it on AMD machines? There are some differences in the
> >>hypercall infrastructure there.
> >
> >Yes. 'll test on AMD machine and update on that.
> >
> 
> I tested the code on 64 bit Dual-Core AMD Opteron machine, and it is 
> working.

I am not that familiar with how KVM does migration, but do you need any
special flags in QEMU to when migrating a KVM-pv-spinlock enabled guest
to another machine?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 11:02:56 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 11:02:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYFGr-0006P2-Tv; Wed, 07 Dec 2011 11:02:41 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@cs.ubc.ca>) id 1RY19c-0004sS-T4
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 19:58:17 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-8.tower-27.messagelabs.com!1323201342!55110854!1
X-Originating-IP: [142.103.6.52]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20440 invoked from network); 6 Dec 2011 19:55:44 -0000
Received: from smtp.cs.ubc.ca (HELO smtp.cs.ubc.ca) (142.103.6.52)
	by server-8.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Dec 2011 19:55:44 -0000
Received: from mail-ee0-f43.google.com (mail-ee0-f43.google.com [74.125.83.43])
	(authenticated bits=0)
	by smtp.cs.ubc.ca (8.14.3/8.13.6) with ESMTP id pB6JvRAM020878
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL)
	for <xen-devel@lists.xensource.com>; Tue, 6 Dec 2011 11:57:29 -0800
Received: by eeaq46 with SMTP id q46so10462938eea.30
	for <xen-devel@lists.xensource.com>;
	Tue, 06 Dec 2011 11:57:26 -0800 (PST)
Received: by 10.213.2.75 with SMTP id 11mr2359174ebi.81.1323201446545; Tue, 06
	Dec 2011 11:57:26 -0800 (PST)
MIME-Version: 1.0
Received: by 10.204.179.10 with HTTP; Tue, 6 Dec 2011 11:56:45 -0800 (PST)
In-Reply-To: <152a79fbe918d8a6c63a.1323079622@cosworth.uk.xensource.com>
References: <152a79fbe918d8a6c63a.1323079622@cosworth.uk.xensource.com>
From: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Date: Tue, 6 Dec 2011 11:56:45 -0800
Message-ID: <CAP8mzPOSQePUySZirCLTh6K_uJ3pj3ws=4KR0y-ybFKObk0yGw@mail.gmail.com>
To: Paul Durrant <paul.durrant@citrix.com>
X-Mailman-Approved-At: Wed, 07 Dec 2011 11:02:40 +0000
Subject: Re: [Xen-devel] [PATCH] VM generation ID save/restore and migrate
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: rshriram@cs.ubc.ca
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============5659309165559095901=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============5659309165559095901==
Content-Type: multipart/alternative; boundary=0015174762f030084004b371d870

--0015174762f030084004b371d870
Content-Type: text/plain; charset=ISO-8859-1

On Mon, Dec 5, 2011 at 2:07 AM, Paul Durrant <paul.durrant@citrix.com>wrote:

> diff -r a4d7c27ec1f1 -r 152a79fbe918 tools/xcutils/xc_restore.c
> --- a/tools/xcutils/xc_restore.c        Fri Dec 02 13:51:17 2011 -0800
> +++ b/tools/xcutils/xc_restore.c        Mon Dec 05 10:01:30 2011 +0000
> @@ -23,7 +23,8 @@ main(int argc, char **argv)
>     xc_interface *xch;
>     int io_fd, ret;
>     int superpages;
> -    unsigned long store_mfn, console_mfn;
> +    unsigned long store_mfn, console_mfn, vm_gid_addr;
> +    int no_increment_gid;
>
>     if ( (argc != 8) && (argc != 9) )
>         errx(1, "usage: %s iofd domid store_evtchn "
> @@ -40,19 +41,25 @@ main(int argc, char **argv)
>     hvm  = atoi(argv[5]);
>     pae  = atoi(argv[6]);
>     apic = atoi(argv[7]);
> -    if ( argc == 9 )
> +    if ( argc >= 9 )
>            superpages = atoi(argv[8]);
>     else
>            superpages = !!hvm;
> +    if ( argc >= 10 )
> +           no_increment_gid = !atoi(argv[9]);
> +    else
> +           no_increment_gid = 0;
>
> There is a "if ( (argc != 8) && (argc != 9) ) err()" condition and then
there is "if (argc >= 10)".

shriram

--0015174762f030084004b371d870
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote">On Mon, Dec 5, 2011 at 2:07 AM, Paul Durrant <sp=
an dir=3D"ltr">&lt;<a href=3D"mailto:paul.durrant@citrix.com">paul.durrant@=
citrix.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; borde=
r-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">diff -r a4d7c27ec=
1f1 -r 152a79fbe918 tools/xcutils/xc_restore.c<br>
--- a/tools/xcutils/xc_restore.c =A0 =A0 =A0 =A0Fri Dec 02 13:51:17 2011 -0=
800<br>
+++ b/tools/xcutils/xc_restore.c =A0 =A0 =A0 =A0Mon Dec 05 10:01:30 2011 +0=
000<br>
<div><div class=3D"h5">@@ -23,7 +23,8 @@ main(int argc, char **argv)<br>
 =A0 =A0 xc_interface *xch;<br>
 =A0 =A0 int io_fd, ret;<br>
 =A0 =A0 int superpages;<br>
- =A0 =A0unsigned long store_mfn, console_mfn;<br>
+ =A0 =A0unsigned long store_mfn, console_mfn, vm_gid_addr;<br>
+ =A0 =A0int no_increment_gid;<br>
<br>
 =A0 =A0 if ( (argc !=3D 8) &amp;&amp; (argc !=3D 9) )<br>
 =A0 =A0 =A0 =A0 errx(1, &quot;usage: %s iofd domid store_evtchn &quot;<br>
@@ -40,19 +41,25 @@ main(int argc, char **argv)<br>
 =A0 =A0 hvm =A0=3D atoi(argv[5]);<br>
 =A0 =A0 pae =A0=3D atoi(argv[6]);<br>
 =A0 =A0 apic =3D atoi(argv[7]);<br>
- =A0 =A0if ( argc =3D=3D 9 )<br>
+ =A0 =A0if ( argc &gt;=3D 9 )<br>
 =A0 =A0 =A0 =A0 =A0 =A0superpages =3D atoi(argv[8]);<br>
 =A0 =A0 else<br>
 =A0 =A0 =A0 =A0 =A0 =A0superpages =3D !!hvm;<br>
+ =A0 =A0if ( argc &gt;=3D 10 )<br>
+ =A0 =A0 =A0 =A0 =A0 no_increment_gid =3D !atoi(argv[9]);<br>
+ =A0 =A0else<br>
+ =A0 =A0 =A0 =A0 =A0 no_increment_gid =3D 0;<br>
<br></div></div></blockquote><div>There is a &quot;if ( (argc !=3D 8) &amp;=
&amp; (argc !=3D 9) ) err()&quot; condition and then<br>there is &quot;if (=
argc &gt;=3D 10)&quot;.<br></div><br>shriram<br></div>

--0015174762f030084004b371d870--


--===============5659309165559095901==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============5659309165559095901==--


From xen-devel-bounces@lists.xensource.com Wed Dec 07 11:02:56 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 11:02:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYFGr-0006Ou-Gv; Wed, 07 Dec 2011 11:02:41 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1RXyFN-0005H7-16
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 16:52:01 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-14.tower-174.messagelabs.com!1323190273!4295454!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15604 invoked from network); 6 Dec 2011 16:51:14 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-14.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 6 Dec 2011 16:51:14 -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
	pB6Gnu2a013297
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Tue, 6 Dec 2011 11:49:57 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pB6GnlW0013293;
	Tue, 6 Dec 2011 11:49:47 -0500
Date: Tue, 6 Dec 2011 12:49:47 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Raghavendra K T <raghukt@linux.vnet.ibm.com>
Message-ID: <20111206164947.GA13184@andromeda.dapyr.net>
References: <20111130085921.23386.89708.sendpatchset@oc5400248562.ibm.com>
	<20111130085959.23386.69166.sendpatchset@oc5400248562.ibm.com>
	<4ED760F1.6080804@redhat.com> <4ED7DA85.5080504@linux.vnet.ibm.com>
	<4EDBB6C2.9050303@linux.vnet.ibm.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4EDBB6C2.9050303@linux.vnet.ibm.com>
User-Agent: Mutt/1.5.9i
X-Mailman-Approved-At: Wed, 07 Dec 2011 11:02:40 +0000
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	Marcelo Tosatti <mtosatti@redhat.com>, KVM <kvm@vger.kernel.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	"H. Peter Anvin" <hpa@zytor.com>, Dave Hansen <dave@linux.vnet.ibm.com>,
	Xen <xen-devel@lists.xensource.com>, Dave Jiang <dave.jiang@intel.com>,
	Gleb Natapov <gleb@redhat.com>, x86@kernel.org,
	Ingo Molnar <mingo@redhat.com>, Avi Kivity <avi@redhat.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>,
	Sasha Levin <levinsasha928@gmail.com>, Sedat Dilek <sedat.dilek@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>, Yinghai Lu <yinghai@kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Greg Kroah-Hartman <gregkh@suse.de>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	LKML <linux-kernel@vger.kernel.org>,
	Suzuki Poulose <suzuki@linux.vnet.ibm.com>
Subject: Re: [Xen-devel] [PATCH RFC V3 2/4] kvm hypervisor : Add a hypercall
	to KVM hypervisor to support pv-ticketlocks
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Sun, Dec 04, 2011 at 11:36:58PM +0530, Raghavendra K T wrote:
> On 12/02/2011 01:20 AM, Raghavendra K T wrote:
> >>Have you tested it on AMD machines? There are some differences in the
> >>hypercall infrastructure there.
> >
> >Yes. 'll test on AMD machine and update on that.
> >
> 
> I tested the code on 64 bit Dual-Core AMD Opteron machine, and it is 
> working.

I am not that familiar with how KVM does migration, but do you need any
special flags in QEMU to when migrating a KVM-pv-spinlock enabled guest
to another machine?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 11:02:56 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 11:02:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYFGr-0006P2-Tv; Wed, 07 Dec 2011 11:02:41 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@cs.ubc.ca>) id 1RY19c-0004sS-T4
	for xen-devel@lists.xensource.com; Tue, 06 Dec 2011 19:58:17 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-8.tower-27.messagelabs.com!1323201342!55110854!1
X-Originating-IP: [142.103.6.52]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20440 invoked from network); 6 Dec 2011 19:55:44 -0000
Received: from smtp.cs.ubc.ca (HELO smtp.cs.ubc.ca) (142.103.6.52)
	by server-8.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Dec 2011 19:55:44 -0000
Received: from mail-ee0-f43.google.com (mail-ee0-f43.google.com [74.125.83.43])
	(authenticated bits=0)
	by smtp.cs.ubc.ca (8.14.3/8.13.6) with ESMTP id pB6JvRAM020878
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL)
	for <xen-devel@lists.xensource.com>; Tue, 6 Dec 2011 11:57:29 -0800
Received: by eeaq46 with SMTP id q46so10462938eea.30
	for <xen-devel@lists.xensource.com>;
	Tue, 06 Dec 2011 11:57:26 -0800 (PST)
Received: by 10.213.2.75 with SMTP id 11mr2359174ebi.81.1323201446545; Tue, 06
	Dec 2011 11:57:26 -0800 (PST)
MIME-Version: 1.0
Received: by 10.204.179.10 with HTTP; Tue, 6 Dec 2011 11:56:45 -0800 (PST)
In-Reply-To: <152a79fbe918d8a6c63a.1323079622@cosworth.uk.xensource.com>
References: <152a79fbe918d8a6c63a.1323079622@cosworth.uk.xensource.com>
From: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Date: Tue, 6 Dec 2011 11:56:45 -0800
Message-ID: <CAP8mzPOSQePUySZirCLTh6K_uJ3pj3ws=4KR0y-ybFKObk0yGw@mail.gmail.com>
To: Paul Durrant <paul.durrant@citrix.com>
X-Mailman-Approved-At: Wed, 07 Dec 2011 11:02:40 +0000
Subject: Re: [Xen-devel] [PATCH] VM generation ID save/restore and migrate
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: rshriram@cs.ubc.ca
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============5659309165559095901=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============5659309165559095901==
Content-Type: multipart/alternative; boundary=0015174762f030084004b371d870

--0015174762f030084004b371d870
Content-Type: text/plain; charset=ISO-8859-1

On Mon, Dec 5, 2011 at 2:07 AM, Paul Durrant <paul.durrant@citrix.com>wrote:

> diff -r a4d7c27ec1f1 -r 152a79fbe918 tools/xcutils/xc_restore.c
> --- a/tools/xcutils/xc_restore.c        Fri Dec 02 13:51:17 2011 -0800
> +++ b/tools/xcutils/xc_restore.c        Mon Dec 05 10:01:30 2011 +0000
> @@ -23,7 +23,8 @@ main(int argc, char **argv)
>     xc_interface *xch;
>     int io_fd, ret;
>     int superpages;
> -    unsigned long store_mfn, console_mfn;
> +    unsigned long store_mfn, console_mfn, vm_gid_addr;
> +    int no_increment_gid;
>
>     if ( (argc != 8) && (argc != 9) )
>         errx(1, "usage: %s iofd domid store_evtchn "
> @@ -40,19 +41,25 @@ main(int argc, char **argv)
>     hvm  = atoi(argv[5]);
>     pae  = atoi(argv[6]);
>     apic = atoi(argv[7]);
> -    if ( argc == 9 )
> +    if ( argc >= 9 )
>            superpages = atoi(argv[8]);
>     else
>            superpages = !!hvm;
> +    if ( argc >= 10 )
> +           no_increment_gid = !atoi(argv[9]);
> +    else
> +           no_increment_gid = 0;
>
> There is a "if ( (argc != 8) && (argc != 9) ) err()" condition and then
there is "if (argc >= 10)".

shriram

--0015174762f030084004b371d870
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote">On Mon, Dec 5, 2011 at 2:07 AM, Paul Durrant <sp=
an dir=3D"ltr">&lt;<a href=3D"mailto:paul.durrant@citrix.com">paul.durrant@=
citrix.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; borde=
r-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">diff -r a4d7c27ec=
1f1 -r 152a79fbe918 tools/xcutils/xc_restore.c<br>
--- a/tools/xcutils/xc_restore.c =A0 =A0 =A0 =A0Fri Dec 02 13:51:17 2011 -0=
800<br>
+++ b/tools/xcutils/xc_restore.c =A0 =A0 =A0 =A0Mon Dec 05 10:01:30 2011 +0=
000<br>
<div><div class=3D"h5">@@ -23,7 +23,8 @@ main(int argc, char **argv)<br>
 =A0 =A0 xc_interface *xch;<br>
 =A0 =A0 int io_fd, ret;<br>
 =A0 =A0 int superpages;<br>
- =A0 =A0unsigned long store_mfn, console_mfn;<br>
+ =A0 =A0unsigned long store_mfn, console_mfn, vm_gid_addr;<br>
+ =A0 =A0int no_increment_gid;<br>
<br>
 =A0 =A0 if ( (argc !=3D 8) &amp;&amp; (argc !=3D 9) )<br>
 =A0 =A0 =A0 =A0 errx(1, &quot;usage: %s iofd domid store_evtchn &quot;<br>
@@ -40,19 +41,25 @@ main(int argc, char **argv)<br>
 =A0 =A0 hvm =A0=3D atoi(argv[5]);<br>
 =A0 =A0 pae =A0=3D atoi(argv[6]);<br>
 =A0 =A0 apic =3D atoi(argv[7]);<br>
- =A0 =A0if ( argc =3D=3D 9 )<br>
+ =A0 =A0if ( argc &gt;=3D 9 )<br>
 =A0 =A0 =A0 =A0 =A0 =A0superpages =3D atoi(argv[8]);<br>
 =A0 =A0 else<br>
 =A0 =A0 =A0 =A0 =A0 =A0superpages =3D !!hvm;<br>
+ =A0 =A0if ( argc &gt;=3D 10 )<br>
+ =A0 =A0 =A0 =A0 =A0 no_increment_gid =3D !atoi(argv[9]);<br>
+ =A0 =A0else<br>
+ =A0 =A0 =A0 =A0 =A0 no_increment_gid =3D 0;<br>
<br></div></div></blockquote><div>There is a &quot;if ( (argc !=3D 8) &amp;=
&amp; (argc !=3D 9) ) err()&quot; condition and then<br>there is &quot;if (=
argc &gt;=3D 10)&quot;.<br></div><br>shriram<br></div>

--0015174762f030084004b371d870--


--===============5659309165559095901==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============5659309165559095901==--


From xen-devel-bounces@lists.xensource.com Wed Dec 07 11:16:02 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 11:16:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYFTL-0007Yd-Cx; Wed, 07 Dec 2011 11:15:35 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1RYFTK-0007YT-4T
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 11:15:34 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1323256485!4579260!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22726 invoked from network); 7 Dec 2011 11:14:47 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Dec 2011 11:14:47 -0000
Received: by iaen33 with SMTP id n33so2625034iae.30
	for <xen-devel@lists.xensource.com>;
	Wed, 07 Dec 2011 03:14:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=7LULCX6F5Eb8uqCheAhch8dMSCoQN6UXcFJ5qEc2nJY=;
	b=PmURFudcJTZDQm+K/HPKcV9th/inKmOd9jyCdSUC1ho1dvzuilO7Bp9KiN2mx3Dom3
	us7UGCb3U9KURf0FxPGDlTgxSaGmsOyV7fMvqmkKnMwh3y8vqrDoYBkc3o1keu7ZBfTV
	FFCIrqq54O7RlZ1E/Q36aJ4x+jL9rVtUEYQ0g=
MIME-Version: 1.0
Received: by 10.50.169.99 with SMTP id ad3mr19391238igc.6.1323256485488; Wed,
	07 Dec 2011 03:14:45 -0800 (PST)
Received: by 10.231.80.201 with HTTP; Wed, 7 Dec 2011 03:14:45 -0800 (PST)
In-Reply-To: <4EDF39210200007800065E15@nat28.tlf.novell.com>
References: <alpine.DEB.2.00.1112061753410.31179@kaball-desktop>
	<1323195609-17277-2-git-send-email-stefano.stabellini@eu.citrix.com>
	<4EDF39210200007800065E15@nat28.tlf.novell.com>
Date: Wed, 7 Dec 2011 11:14:45 +0000
X-Google-Sender-Auth: nCqwTqIp7hEN6-pSm4wBlWEsMfU
Message-ID: <CAFLBxZbwuwb=BL6BXzVifaRpaX7j8vKbuK7Vun7J-0xu-s+Nzg@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: Tim.Deegan@citrix.com, xen-devel@lists.xensource.com,
	Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH RFC 02/25] A collection of fixes to Xen
	common files
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Dec 7, 2011 at 9:00 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>> On 06.12.11 at 19:19, <stefano.stabellini@eu.citrix.com> wrote:
>> - call free_xenoprof_pages only ifdef xenoprof;
>
> I can't find where this symbol would get defined, so effectively you're
> removing the call unconditionally.

And when we do define it, convention says it should be in capitals,
not lower-case.

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 11:16:02 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 11:16:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYFTL-0007Yd-Cx; Wed, 07 Dec 2011 11:15:35 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1RYFTK-0007YT-4T
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 11:15:34 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1323256485!4579260!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22726 invoked from network); 7 Dec 2011 11:14:47 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Dec 2011 11:14:47 -0000
Received: by iaen33 with SMTP id n33so2625034iae.30
	for <xen-devel@lists.xensource.com>;
	Wed, 07 Dec 2011 03:14:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=7LULCX6F5Eb8uqCheAhch8dMSCoQN6UXcFJ5qEc2nJY=;
	b=PmURFudcJTZDQm+K/HPKcV9th/inKmOd9jyCdSUC1ho1dvzuilO7Bp9KiN2mx3Dom3
	us7UGCb3U9KURf0FxPGDlTgxSaGmsOyV7fMvqmkKnMwh3y8vqrDoYBkc3o1keu7ZBfTV
	FFCIrqq54O7RlZ1E/Q36aJ4x+jL9rVtUEYQ0g=
MIME-Version: 1.0
Received: by 10.50.169.99 with SMTP id ad3mr19391238igc.6.1323256485488; Wed,
	07 Dec 2011 03:14:45 -0800 (PST)
Received: by 10.231.80.201 with HTTP; Wed, 7 Dec 2011 03:14:45 -0800 (PST)
In-Reply-To: <4EDF39210200007800065E15@nat28.tlf.novell.com>
References: <alpine.DEB.2.00.1112061753410.31179@kaball-desktop>
	<1323195609-17277-2-git-send-email-stefano.stabellini@eu.citrix.com>
	<4EDF39210200007800065E15@nat28.tlf.novell.com>
Date: Wed, 7 Dec 2011 11:14:45 +0000
X-Google-Sender-Auth: nCqwTqIp7hEN6-pSm4wBlWEsMfU
Message-ID: <CAFLBxZbwuwb=BL6BXzVifaRpaX7j8vKbuK7Vun7J-0xu-s+Nzg@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: Tim.Deegan@citrix.com, xen-devel@lists.xensource.com,
	Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH RFC 02/25] A collection of fixes to Xen
	common files
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Dec 7, 2011 at 9:00 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>> On 06.12.11 at 19:19, <stefano.stabellini@eu.citrix.com> wrote:
>> - call free_xenoprof_pages only ifdef xenoprof;
>
> I can't find where this symbol would get defined, so effectively you're
> removing the call unconditionally.

And when we do define it, convention says it should be in capitals,
not lower-case.

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 11:20:29 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 11:20:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYFXp-0007um-Pe; Wed, 07 Dec 2011 11:20:13 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RYFXo-0007uF-VF
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 11:20:13 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1323256731!49815304!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjA3NQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31006 invoked from network); 7 Dec 2011 11:18:51 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Dec 2011 11:18:51 -0000
X-IronPort-AV: E=Sophos;i="4.71,313,1320624000"; 
   d="scan'208";a="9338988"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Dec 2011 11:19:28 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 7 Dec 2011 11:19:27 +0000
Date: Wed, 7 Dec 2011 11:20:31 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Jan Beulich <JBeulich@suse.com>
In-Reply-To: <4EDF39210200007800065E15@nat28.tlf.novell.com>
Message-ID: <alpine.DEB.2.00.1112071111270.31179@kaball-desktop>
References: <alpine.DEB.2.00.1112061753410.31179@kaball-desktop>
	<1323195609-17277-2-git-send-email-stefano.stabellini@eu.citrix.com>
	<4EDF39210200007800065E15@nat28.tlf.novell.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "Tim Deegan \(3P\)" <Tim.Deegan@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH RFC 02/25] A collection of fixes to Xen
 common files
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 7 Dec 2011, Jan Beulich wrote:
> >>> On 06.12.11 at 19:19, <stefano.stabellini@eu.citrix.com> wrote:
> > - call free_xenoprof_pages only ifdef xenoprof;
> 
> I can't find where this symbol would get defined, so effectively you're
> removing the call unconditionally.

The symbol is already defined in xen/arch/x86/Rules.mk and
xen/arch/ia64/Rules.mk.


> > +extern char _srodata[], _erodata[];
> 
> While I realize that this isn't currently the case on e.g. the respective
> .text symbols, if you introduce new once, please add const to the
> declarations *at least* when the section contents really are read only
> (in many cases doing so even for writable sections is likely appropriate
> too).

OK


> > +#define is_kernel_rodata(p) ({                  \
> > +    char *__p = (char *)(unsigned long)(p);     \
> > +    (__p >= _srodata) && (__p < _erodata);      \
> 
> Obviously the above calls for adjustments here, too.

sorry I am not sure what you mean

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 11:20:29 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 11:20:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYFXp-0007um-Pe; Wed, 07 Dec 2011 11:20:13 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RYFXo-0007uF-VF
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 11:20:13 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1323256731!49815304!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjA3NQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31006 invoked from network); 7 Dec 2011 11:18:51 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Dec 2011 11:18:51 -0000
X-IronPort-AV: E=Sophos;i="4.71,313,1320624000"; 
   d="scan'208";a="9338988"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Dec 2011 11:19:28 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 7 Dec 2011 11:19:27 +0000
Date: Wed, 7 Dec 2011 11:20:31 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Jan Beulich <JBeulich@suse.com>
In-Reply-To: <4EDF39210200007800065E15@nat28.tlf.novell.com>
Message-ID: <alpine.DEB.2.00.1112071111270.31179@kaball-desktop>
References: <alpine.DEB.2.00.1112061753410.31179@kaball-desktop>
	<1323195609-17277-2-git-send-email-stefano.stabellini@eu.citrix.com>
	<4EDF39210200007800065E15@nat28.tlf.novell.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "Tim Deegan \(3P\)" <Tim.Deegan@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH RFC 02/25] A collection of fixes to Xen
 common files
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 7 Dec 2011, Jan Beulich wrote:
> >>> On 06.12.11 at 19:19, <stefano.stabellini@eu.citrix.com> wrote:
> > - call free_xenoprof_pages only ifdef xenoprof;
> 
> I can't find where this symbol would get defined, so effectively you're
> removing the call unconditionally.

The symbol is already defined in xen/arch/x86/Rules.mk and
xen/arch/ia64/Rules.mk.


> > +extern char _srodata[], _erodata[];
> 
> While I realize that this isn't currently the case on e.g. the respective
> .text symbols, if you introduce new once, please add const to the
> declarations *at least* when the section contents really are read only
> (in many cases doing so even for writable sections is likely appropriate
> too).

OK


> > +#define is_kernel_rodata(p) ({                  \
> > +    char *__p = (char *)(unsigned long)(p);     \
> > +    (__p >= _srodata) && (__p < _erodata);      \
> 
> Obviously the above calls for adjustments here, too.

sorry I am not sure what you mean

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 11:21:17 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 11:21:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYFYR-00080Z-F0; Wed, 07 Dec 2011 11:20:51 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RYFYP-0007zf-QM
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 11:20:50 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1323256802!6504954!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjA3NQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14657 invoked from network); 7 Dec 2011 11:20:03 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Dec 2011 11:20:03 -0000
X-IronPort-AV: E=Sophos;i="4.71,313,1320624000"; 
   d="scan'208";a="9338971"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Dec 2011 11:19:01 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 7 Dec 2011 11:19:01 +0000
Date: Wed, 7 Dec 2011 11:20:04 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Jan Beulich <JBeulich@suse.com>
In-Reply-To: <4EDF375E0200007800065E06@nat28.tlf.novell.com>
Message-ID: <alpine.DEB.2.00.1112071110360.31179@kaball-desktop>
References: <alpine.DEB.2.00.1112061753410.31179@kaball-desktop>
	<1323195609-17277-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<4EDF375E0200007800065E06@nat28.tlf.novell.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "Tim Deegan \(3P\)" <Tim.Deegan@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH RFC 01/25] Include some header files that
 are not automatically included on all archs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 7 Dec 2011, Jan Beulich wrote:
> >>> On 06.12.11 at 19:19, <stefano.stabellini@eu.citrix.com> wrote:
> > --- a/xen/common/grant_table.c
> > +++ b/xen/common/grant_table.c
> > @@ -24,6 +24,7 @@
> >   * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
> >   */
> >  
> > +#include <asm/flushtlb.h>
> 
> It's pretty uncommon to have asm/ headers included before xen/ ones,
> and it's definitely wrong to do so before xen/config.h.
> 
> >  #include <xen/config.h>
> >  #include <xen/iocap.h>
> >  #include <xen/lib.h>
> > --- a/xen/common/memory.c
> > +++ b/xen/common/memory.c
> > @@ -23,9 +23,7 @@
> >  #include <xen/tmem_xen.h>
> >  #include <asm/current.h>
> >  #include <asm/hardirq.h>
> > -#ifdef CONFIG_X86
> > -# include <asm/p2m.h>
> > -#endif
> > +#include <asm/p2m.h>
> 
> This header doesn't exist on ia64; if you had looked in the history
> why the #ifdef got introduced, you would have noticed. So either
> we need to introduce something like CONFIG_P2M, or ia64 needs
> to get a stub header, or the conditional above needs to simply be
> extended.
> 
> >  #include <xen/numa.h>
> >  #include <public/memory.h>
> >  #include <xsm/xsm.h>
> > --- a/xen/include/xen/tmem_xen.h
> > +++ b/xen/include/xen/tmem_xen.h
> > @@ -11,6 +11,7 @@
> >  
> >  #include <xen/config.h>
> >  #include <xen/mm.h> /* heap alloc/free */
> > +#include <xen/pfn.h> /* heap alloc/free */
> 
> The comment is certainly wrong - correct it or remove it.
> 

Thanks for the review, I agree with all your comments.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 11:21:17 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 11:21:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYFYR-00080Z-F0; Wed, 07 Dec 2011 11:20:51 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RYFYP-0007zf-QM
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 11:20:50 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1323256802!6504954!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjA3NQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14657 invoked from network); 7 Dec 2011 11:20:03 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Dec 2011 11:20:03 -0000
X-IronPort-AV: E=Sophos;i="4.71,313,1320624000"; 
   d="scan'208";a="9338971"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Dec 2011 11:19:01 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 7 Dec 2011 11:19:01 +0000
Date: Wed, 7 Dec 2011 11:20:04 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Jan Beulich <JBeulich@suse.com>
In-Reply-To: <4EDF375E0200007800065E06@nat28.tlf.novell.com>
Message-ID: <alpine.DEB.2.00.1112071110360.31179@kaball-desktop>
References: <alpine.DEB.2.00.1112061753410.31179@kaball-desktop>
	<1323195609-17277-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<4EDF375E0200007800065E06@nat28.tlf.novell.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "Tim Deegan \(3P\)" <Tim.Deegan@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH RFC 01/25] Include some header files that
 are not automatically included on all archs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 7 Dec 2011, Jan Beulich wrote:
> >>> On 06.12.11 at 19:19, <stefano.stabellini@eu.citrix.com> wrote:
> > --- a/xen/common/grant_table.c
> > +++ b/xen/common/grant_table.c
> > @@ -24,6 +24,7 @@
> >   * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
> >   */
> >  
> > +#include <asm/flushtlb.h>
> 
> It's pretty uncommon to have asm/ headers included before xen/ ones,
> and it's definitely wrong to do so before xen/config.h.
> 
> >  #include <xen/config.h>
> >  #include <xen/iocap.h>
> >  #include <xen/lib.h>
> > --- a/xen/common/memory.c
> > +++ b/xen/common/memory.c
> > @@ -23,9 +23,7 @@
> >  #include <xen/tmem_xen.h>
> >  #include <asm/current.h>
> >  #include <asm/hardirq.h>
> > -#ifdef CONFIG_X86
> > -# include <asm/p2m.h>
> > -#endif
> > +#include <asm/p2m.h>
> 
> This header doesn't exist on ia64; if you had looked in the history
> why the #ifdef got introduced, you would have noticed. So either
> we need to introduce something like CONFIG_P2M, or ia64 needs
> to get a stub header, or the conditional above needs to simply be
> extended.
> 
> >  #include <xen/numa.h>
> >  #include <public/memory.h>
> >  #include <xsm/xsm.h>
> > --- a/xen/include/xen/tmem_xen.h
> > +++ b/xen/include/xen/tmem_xen.h
> > @@ -11,6 +11,7 @@
> >  
> >  #include <xen/config.h>
> >  #include <xen/mm.h> /* heap alloc/free */
> > +#include <xen/pfn.h> /* heap alloc/free */
> 
> The comment is certainly wrong - correct it or remove it.
> 

Thanks for the review, I agree with all your comments.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 11:22:10 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 11:22:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYFZX-0008Cu-U6; Wed, 07 Dec 2011 11:21:59 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RYFZW-0008Bm-SN
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 11:21:58 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1323256871!4601798!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjA3NQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2270 invoked from network); 7 Dec 2011 11:21:11 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Dec 2011 11:21:11 -0000
X-IronPort-AV: E=Sophos;i="4.71,313,1320624000"; 
   d="scan'208";a="9339046"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Dec 2011 11:21:11 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 7 Dec 2011 11:21:10 +0000
Date: Wed, 7 Dec 2011 11:22:14 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Jan Beulich <JBeulich@suse.com>
In-Reply-To: <4EDF398C0200007800065E18@nat28.tlf.novell.com>
Message-ID: <alpine.DEB.2.00.1112071121030.31179@kaball-desktop>
References: <alpine.DEB.2.00.1112061753410.31179@kaball-desktop>
	<1323195609-17277-3-git-send-email-stefano.stabellini@eu.citrix.com>
	<4EDF398C0200007800065E18@nat28.tlf.novell.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "Tim Deegan \(3P\)" <Tim.Deegan@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH RFC 03/25] Move cpufreq option parsing to
 cpufreq.c
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 7 Dec 2011, Jan Beulich wrote:
> >>> On 06.12.11 at 19:19, <stefano.stabellini@eu.citrix.com> wrote:
> > From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > 
> > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> > Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
> 
> Acked-by: Jan Beulich <jbeulich@suse.com>
> 
> (perhaps as a standalone change, i.e. outside the whole series)

Thanks! I'll move it to the beginning of the series.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 11:22:10 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 11:22:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYFZX-0008Cu-U6; Wed, 07 Dec 2011 11:21:59 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RYFZW-0008Bm-SN
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 11:21:58 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1323256871!4601798!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjA3NQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2270 invoked from network); 7 Dec 2011 11:21:11 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Dec 2011 11:21:11 -0000
X-IronPort-AV: E=Sophos;i="4.71,313,1320624000"; 
   d="scan'208";a="9339046"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Dec 2011 11:21:11 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 7 Dec 2011 11:21:10 +0000
Date: Wed, 7 Dec 2011 11:22:14 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Jan Beulich <JBeulich@suse.com>
In-Reply-To: <4EDF398C0200007800065E18@nat28.tlf.novell.com>
Message-ID: <alpine.DEB.2.00.1112071121030.31179@kaball-desktop>
References: <alpine.DEB.2.00.1112061753410.31179@kaball-desktop>
	<1323195609-17277-3-git-send-email-stefano.stabellini@eu.citrix.com>
	<4EDF398C0200007800065E18@nat28.tlf.novell.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "Tim Deegan \(3P\)" <Tim.Deegan@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH RFC 03/25] Move cpufreq option parsing to
 cpufreq.c
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 7 Dec 2011, Jan Beulich wrote:
> >>> On 06.12.11 at 19:19, <stefano.stabellini@eu.citrix.com> wrote:
> > From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > 
> > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> > Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
> 
> Acked-by: Jan Beulich <jbeulich@suse.com>
> 
> (perhaps as a standalone change, i.e. outside the whole series)

Thanks! I'll move it to the beginning of the series.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 11:23:06 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 11: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.xensource.com>)
	id 1RYFaS-0008L6-Dx; Wed, 07 Dec 2011 11:22:56 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RYFaR-0008KE-EJ
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 11:22:55 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1323256925!6490861!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjA3NQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6695 invoked from network); 7 Dec 2011 11:22:08 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Dec 2011 11:22:08 -0000
X-IronPort-AV: E=Sophos;i="4.71,313,1320624000"; 
   d="scan'208";a="9339066"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Dec 2011 11:22:05 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 7 Dec 2011 11:22:05 +0000
Date: Wed, 7 Dec 2011 11:23:08 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Jan Beulich <JBeulich@suse.com>
In-Reply-To: <4EDF43470200007800065E4E@nat28.tlf.novell.com>
Message-ID: <alpine.DEB.2.00.1112071122510.31179@kaball-desktop>
References: <alpine.DEB.2.00.1112061753410.31179@kaball-desktop>
	<1323195609-17277-5-git-send-email-stefano.stabellini@eu.citrix.com>
	<4EDF43470200007800065E4E@nat28.tlf.novell.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "Tim Deegan \(3P\)" <Tim.Deegan@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH RFC 05/25] Introduce clear_user
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 7 Dec 2011, Jan Beulich wrote:
> >>> On 06.12.11 at 19:19, <stefano.stabellini@eu.citrix.com> wrote:
> > --- a/xen/arch/x86/usercopy.c
> > +++ b/xen/arch/x86/usercopy.c
> > @@ -110,6 +110,42 @@ copy_to_user(void __user *to, const void *from, unsigned 
> > n)
> >      return n;
> >  }
> >  
> > +#define __do_clear_user(addr,size)					\
> > +do {									\
> > +	int __d0;							\
> 
> This should be 'long' to be forward compatible (current gcc likely doesn't
> care), and to cope with eventual future compat mode users passing in a
> 32-bit 'addr'.
> 
> > +	__asm__ __volatile__(						\
> > +		"0:	rep; stosl\n"					\
> > +		"	movl %2,%0\n"					\
> > +		"1:	rep; stosb\n"					\
> > +		"2:\n"							\
> > +		".section .fixup,\"ax\"\n"				\
> > +		"3:	lea 0(%2,%0,4),%0\n"				\
> > +		"	jmp 2b\n"					\
> > +		".previous\n"						\
> > +		_ASM_EXTABLE(0b,3b)					\
> > +		_ASM_EXTABLE(1b,2b)					\
> > +		: "=&c"(size), "=&D" (__d0)				\
> > +		: "r"(size & 3), "0"(size / 4), "1"(addr), "a"(0));	\
> 
> For that latter case at least, casting 'addr' to long may also be necessary.

Good points, I'll make the changes

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 11:23:06 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 11: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.xensource.com>)
	id 1RYFaS-0008L6-Dx; Wed, 07 Dec 2011 11:22:56 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RYFaR-0008KE-EJ
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 11:22:55 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1323256925!6490861!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjA3NQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6695 invoked from network); 7 Dec 2011 11:22:08 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Dec 2011 11:22:08 -0000
X-IronPort-AV: E=Sophos;i="4.71,313,1320624000"; 
   d="scan'208";a="9339066"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Dec 2011 11:22:05 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 7 Dec 2011 11:22:05 +0000
Date: Wed, 7 Dec 2011 11:23:08 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Jan Beulich <JBeulich@suse.com>
In-Reply-To: <4EDF43470200007800065E4E@nat28.tlf.novell.com>
Message-ID: <alpine.DEB.2.00.1112071122510.31179@kaball-desktop>
References: <alpine.DEB.2.00.1112061753410.31179@kaball-desktop>
	<1323195609-17277-5-git-send-email-stefano.stabellini@eu.citrix.com>
	<4EDF43470200007800065E4E@nat28.tlf.novell.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "Tim Deegan \(3P\)" <Tim.Deegan@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH RFC 05/25] Introduce clear_user
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 7 Dec 2011, Jan Beulich wrote:
> >>> On 06.12.11 at 19:19, <stefano.stabellini@eu.citrix.com> wrote:
> > --- a/xen/arch/x86/usercopy.c
> > +++ b/xen/arch/x86/usercopy.c
> > @@ -110,6 +110,42 @@ copy_to_user(void __user *to, const void *from, unsigned 
> > n)
> >      return n;
> >  }
> >  
> > +#define __do_clear_user(addr,size)					\
> > +do {									\
> > +	int __d0;							\
> 
> This should be 'long' to be forward compatible (current gcc likely doesn't
> care), and to cope with eventual future compat mode users passing in a
> 32-bit 'addr'.
> 
> > +	__asm__ __volatile__(						\
> > +		"0:	rep; stosl\n"					\
> > +		"	movl %2,%0\n"					\
> > +		"1:	rep; stosb\n"					\
> > +		"2:\n"							\
> > +		".section .fixup,\"ax\"\n"				\
> > +		"3:	lea 0(%2,%0,4),%0\n"				\
> > +		"	jmp 2b\n"					\
> > +		".previous\n"						\
> > +		_ASM_EXTABLE(0b,3b)					\
> > +		_ASM_EXTABLE(1b,2b)					\
> > +		: "=&c"(size), "=&D" (__d0)				\
> > +		: "r"(size & 3), "0"(size / 4), "1"(addr), "a"(0));	\
> 
> For that latter case at least, casting 'addr' to long may also be necessary.

Good points, I'll make the changes

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 11:24:39 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 11:24:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYFbz-00006w-UD; Wed, 07 Dec 2011 11:24:31 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RYFby-00005u-19
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 11:24:30 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1323257022!7133208!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjA3NQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3479 invoked from network); 7 Dec 2011 11:23:43 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Dec 2011 11:23:43 -0000
X-IronPort-AV: E=Sophos;i="4.71,313,1320624000"; 
   d="scan'208";a="9339119"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Dec 2011 11:23:42 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 7 Dec 2011 11:23:42 +0000
Date: Wed, 7 Dec 2011 11:24:46 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Jan Beulich <JBeulich@suse.com>
In-Reply-To: <4EDF47360200007800065E7C@nat28.tlf.novell.com>
Message-ID: <alpine.DEB.2.00.1112071123360.31179@kaball-desktop>
References: <alpine.DEB.2.00.1112061753410.31179@kaball-desktop>
	<1323195609-17277-7-git-send-email-stefano.stabellini@eu.citrix.com>
	<4EDF47360200007800065E7C@nat28.tlf.novell.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "Tim Deegan \(3P\)" <Tim.Deegan@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH RFC 07/25] xen/common/Makefile: introduce
 HAS_CPUFREQ, HAS_PCI, HAS_PASSTHROUGH, HAS_NS16550
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 7 Dec 2011, Jan Beulich wrote:
> >>> On 06.12.11 at 19:19, <stefano.stabellini@eu.citrix.com> wrote:
> > From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > 
> > - make the compilation of ns16550.c depend upon HAS_NS16550;
> > 
> > - make the compilation of cpufreq depend upon HAS_CPUFREQ;
> > 
> > - make the compilation of pci depend upon HAS_PCI;
> > 
> > - make the compilation of passthrough depend upon HAS_PASSTHROUGH;
> > 
> > - make the compilation of kexec.o depend on HAS_ACPI.
> 
> How are kexec and ACPI connected to one another?

Today kexec implementation is dependent on ACPI.
Should I introduce a separate HAS_KEXEC config option, for the sake of
clarity?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 11:24:39 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 11:24:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYFbz-00006w-UD; Wed, 07 Dec 2011 11:24:31 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RYFby-00005u-19
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 11:24:30 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1323257022!7133208!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjA3NQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3479 invoked from network); 7 Dec 2011 11:23:43 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Dec 2011 11:23:43 -0000
X-IronPort-AV: E=Sophos;i="4.71,313,1320624000"; 
   d="scan'208";a="9339119"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Dec 2011 11:23:42 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 7 Dec 2011 11:23:42 +0000
Date: Wed, 7 Dec 2011 11:24:46 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Jan Beulich <JBeulich@suse.com>
In-Reply-To: <4EDF47360200007800065E7C@nat28.tlf.novell.com>
Message-ID: <alpine.DEB.2.00.1112071123360.31179@kaball-desktop>
References: <alpine.DEB.2.00.1112061753410.31179@kaball-desktop>
	<1323195609-17277-7-git-send-email-stefano.stabellini@eu.citrix.com>
	<4EDF47360200007800065E7C@nat28.tlf.novell.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "Tim Deegan \(3P\)" <Tim.Deegan@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH RFC 07/25] xen/common/Makefile: introduce
 HAS_CPUFREQ, HAS_PCI, HAS_PASSTHROUGH, HAS_NS16550
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 7 Dec 2011, Jan Beulich wrote:
> >>> On 06.12.11 at 19:19, <stefano.stabellini@eu.citrix.com> wrote:
> > From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > 
> > - make the compilation of ns16550.c depend upon HAS_NS16550;
> > 
> > - make the compilation of cpufreq depend upon HAS_CPUFREQ;
> > 
> > - make the compilation of pci depend upon HAS_PCI;
> > 
> > - make the compilation of passthrough depend upon HAS_PASSTHROUGH;
> > 
> > - make the compilation of kexec.o depend on HAS_ACPI.
> 
> How are kexec and ACPI connected to one another?

Today kexec implementation is dependent on ACPI.
Should I introduce a separate HAS_KEXEC config option, for the sake of
clarity?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 11:36:44 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 11:36:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYFnX-0000uG-Tp; Wed, 07 Dec 2011 11:36:27 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RYFnW-0000u4-DU
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 11:36:26 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1323257738!6240243!1
X-Originating-IP: [209.85.215.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21369 invoked from network); 7 Dec 2011 11:35:39 -0000
Received: from mail-ey0-f171.google.com (HELO mail-ey0-f171.google.com)
	(209.85.215.171)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Dec 2011 11:35:39 -0000
Received: by eaad12 with SMTP id d12so1847554eaa.30
	for <xen-devel@lists.xensource.com>;
	Wed, 07 Dec 2011 03:35:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=VWQPcJh+9wmW/oG/rKmrwGa6RZI/T/wLhJj3qiYHUNQ=;
	b=W/X/tK7h1urA8z55FKJDfE7TnQ0RtcHrjvxEefcgZWOCdth2ebt1CEnuQsukoPhIDz
	0Fwj5BwFAnSUStP+nNwWKXBEGJ9TtCUPBFOlXgwi3+IQ/3DZlb6uILYXuW9gMKQeYPx5
	XUIg0dQHA5yj6Q4qrPyD4efNDf0EQAFHnz3Vo=
Received: by 10.213.19.2 with SMTP id y2mr3313507eba.31.1323257738205;
	Wed, 07 Dec 2011 03:35:38 -0800 (PST)
Received: from [192.168.1.70]
	(host81-155-119-104.range81-155.btcentralplus.com. [81.155.119.104])
	by mx.google.com with ESMTPS id q6sm1947039bka.6.2011.12.07.03.35.34
	(version=SSLv3 cipher=OTHER); Wed, 07 Dec 2011 03:35:37 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Wed, 07 Dec 2011 11:35:30 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <CB050002.26A61%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH RFC 04/25] Replace "/" operand with div64
Thread-Index: Acy01FKsAt6nykKQpUO3ZfD1+egsSg==
In-Reply-To: <4EDF3EC70200007800065E3B@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: xen-devel@lists.xensource.com, Ian Campbell <ian.campbell@citrix.com>,
	Tim Deegan <Tim.Deegan@citrix.com>
Subject: Re: [Xen-devel] [PATCH RFC 04/25] Replace "/" operand with div64
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 07/12/2011 09:24, "Jan Beulich" <JBeulich@suse.com> wrote:

>>>> On 06.12.11 at 19:19, <stefano.stabellini@eu.citrix.com> wrote:
>> ARM does not have a division operator: division has to be implemented
>> in software.
>> On x86 and ia64 div64 falls back to a do_div based implementation.
> 
> But this needs to be done carefully and correctly - there's no
> one-fits-all div64() implementation.

I'm sure gcc-arm must emit lib calls for divisions. Maybe arch/arm needs to
implement some of those if arm doesn't support even 32-bit divide. Common
lib code covers only 64-bit divide.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 11:36:44 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 11:36:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYFnX-0000uG-Tp; Wed, 07 Dec 2011 11:36:27 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RYFnW-0000u4-DU
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 11:36:26 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1323257738!6240243!1
X-Originating-IP: [209.85.215.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21369 invoked from network); 7 Dec 2011 11:35:39 -0000
Received: from mail-ey0-f171.google.com (HELO mail-ey0-f171.google.com)
	(209.85.215.171)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Dec 2011 11:35:39 -0000
Received: by eaad12 with SMTP id d12so1847554eaa.30
	for <xen-devel@lists.xensource.com>;
	Wed, 07 Dec 2011 03:35:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=VWQPcJh+9wmW/oG/rKmrwGa6RZI/T/wLhJj3qiYHUNQ=;
	b=W/X/tK7h1urA8z55FKJDfE7TnQ0RtcHrjvxEefcgZWOCdth2ebt1CEnuQsukoPhIDz
	0Fwj5BwFAnSUStP+nNwWKXBEGJ9TtCUPBFOlXgwi3+IQ/3DZlb6uILYXuW9gMKQeYPx5
	XUIg0dQHA5yj6Q4qrPyD4efNDf0EQAFHnz3Vo=
Received: by 10.213.19.2 with SMTP id y2mr3313507eba.31.1323257738205;
	Wed, 07 Dec 2011 03:35:38 -0800 (PST)
Received: from [192.168.1.70]
	(host81-155-119-104.range81-155.btcentralplus.com. [81.155.119.104])
	by mx.google.com with ESMTPS id q6sm1947039bka.6.2011.12.07.03.35.34
	(version=SSLv3 cipher=OTHER); Wed, 07 Dec 2011 03:35:37 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Wed, 07 Dec 2011 11:35:30 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <CB050002.26A61%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH RFC 04/25] Replace "/" operand with div64
Thread-Index: Acy01FKsAt6nykKQpUO3ZfD1+egsSg==
In-Reply-To: <4EDF3EC70200007800065E3B@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: xen-devel@lists.xensource.com, Ian Campbell <ian.campbell@citrix.com>,
	Tim Deegan <Tim.Deegan@citrix.com>
Subject: Re: [Xen-devel] [PATCH RFC 04/25] Replace "/" operand with div64
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 07/12/2011 09:24, "Jan Beulich" <JBeulich@suse.com> wrote:

>>>> On 06.12.11 at 19:19, <stefano.stabellini@eu.citrix.com> wrote:
>> ARM does not have a division operator: division has to be implemented
>> in software.
>> On x86 and ia64 div64 falls back to a do_div based implementation.
> 
> But this needs to be done carefully and correctly - there's no
> one-fits-all div64() implementation.

I'm sure gcc-arm must emit lib calls for divisions. Maybe arch/arm needs to
implement some of those if arm doesn't support even 32-bit divide. Common
lib code covers only 64-bit divide.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 11:39:32 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 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.xensource.com>)
	id 1RYFpz-00018E-IX; Wed, 07 Dec 2011 11:38:59 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RYFpy-000177-1O
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 11:38:58 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1323257890!4398922!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjA3NQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26717 invoked from network); 7 Dec 2011 11:38:11 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Dec 2011 11:38:11 -0000
X-IronPort-AV: E=Sophos;i="4.71,313,1320624000"; 
   d="scan'208";a="9339564"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Dec 2011 11:38:05 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 7 Dec 2011
	11:38:04 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Date: Wed, 7 Dec 2011 11:38:04 +0000
In-Reply-To: <alpine.DEB.2.00.1112071111270.31179@kaball-desktop>
References: <alpine.DEB.2.00.1112061753410.31179@kaball-desktop>
	<1323195609-17277-2-git-send-email-stefano.stabellini@eu.citrix.com>
	<4EDF39210200007800065E15@nat28.tlf.novell.com>
	<alpine.DEB.2.00.1112071111270.31179@kaball-desktop>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323257884.23681.163.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Tim Deegan \(3P\)" <Tim.Deegan@citrix.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH RFC 02/25] A collection of fixes to Xen
 common files
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2011-12-07 at 11:20 +0000, Stefano Stabellini wrote:
> On Wed, 7 Dec 2011, Jan Beulich wrote:
> > >>> On 06.12.11 at 19:19, <stefano.stabellini@eu.citrix.com> wrote:
> > > - call free_xenoprof_pages only ifdef xenoprof;
> > 
> > I can't find where this symbol would get defined, so effectively you're
> > removing the call unconditionally.
> 
> The symbol is already defined in xen/arch/x86/Rules.mk and
> xen/arch/ia64/Rules.mk.

That's a Makefile variable -- it's not exposed to the C preprocessor, is
it?

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 11:39:32 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 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.xensource.com>)
	id 1RYFpz-00018E-IX; Wed, 07 Dec 2011 11:38:59 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RYFpy-000177-1O
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 11:38:58 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1323257890!4398922!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjA3NQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26717 invoked from network); 7 Dec 2011 11:38:11 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Dec 2011 11:38:11 -0000
X-IronPort-AV: E=Sophos;i="4.71,313,1320624000"; 
   d="scan'208";a="9339564"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Dec 2011 11:38:05 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 7 Dec 2011
	11:38:04 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Date: Wed, 7 Dec 2011 11:38:04 +0000
In-Reply-To: <alpine.DEB.2.00.1112071111270.31179@kaball-desktop>
References: <alpine.DEB.2.00.1112061753410.31179@kaball-desktop>
	<1323195609-17277-2-git-send-email-stefano.stabellini@eu.citrix.com>
	<4EDF39210200007800065E15@nat28.tlf.novell.com>
	<alpine.DEB.2.00.1112071111270.31179@kaball-desktop>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323257884.23681.163.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Tim Deegan \(3P\)" <Tim.Deegan@citrix.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH RFC 02/25] A collection of fixes to Xen
 common files
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2011-12-07 at 11:20 +0000, Stefano Stabellini wrote:
> On Wed, 7 Dec 2011, Jan Beulich wrote:
> > >>> On 06.12.11 at 19:19, <stefano.stabellini@eu.citrix.com> wrote:
> > > - call free_xenoprof_pages only ifdef xenoprof;
> > 
> > I can't find where this symbol would get defined, so effectively you're
> > removing the call unconditionally.
> 
> The symbol is already defined in xen/arch/x86/Rules.mk and
> xen/arch/ia64/Rules.mk.

That's a Makefile variable -- it's not exposed to the C preprocessor, is
it?

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 11:45:48 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 11:45:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYFwK-0001fR-Eg; Wed, 07 Dec 2011 11:45:32 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <tobias.geiger@vido.info>) id 1RYFwI-0001fH-Im
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 11:45:30 +0000
X-Env-Sender: tobias.geiger@vido.info
X-Msg-Ref: server-15.tower-216.messagelabs.com!1323258283!6487718!1
X-Originating-IP: [78.47.43.171]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5323 invoked from network); 7 Dec 2011 11:44:43 -0000
Received: from www.vido.info (HELO mail.vido.info) (78.47.43.171)
	by server-15.tower-216.messagelabs.com with SMTP;
	7 Dec 2011 11:44:43 -0000
Received: from localhost (ip6-localhost [127.0.0.1])
	by mail.vido.info (Postfix) with ESMTP id 4AD92D34669;
	Wed,  7 Dec 2011 12:44:43 +0100 (CET)
X-Virus-Scanned: by amavis at mail.vido.info
Received: from mail.vido.info ([127.0.0.1])
	by localhost (mail.vido.info [127.0.0.1]) (amavisd-new, port 10024)
	with LMTP id zB5y240z-gnr; Wed,  7 Dec 2011 12:44:37 +0100 (CET)
Received: from lxgeigert.localnet (et-1-10.gw-nat.bs.kae.de.oneandone.net
	[212.227.35.74])
	by mail.vido.info (Postfix) with ESMTPSA id 9911BD341A9;
	Wed,  7 Dec 2011 12:44:37 +0100 (CET)
From: Tobias Geiger <tobias.geiger@vido.info>
Organization: VIDO IT-Service
To: xen-devel@lists.xensource.com,
 allen.m.kay@intel.com
Date: Wed, 7 Dec 2011 12:44:33 +0100
User-Agent: KMail/1.13.7 (Linux/3.0.0-1-amd64; KDE/4.6.5; x86_64; ; )
References: <1318672856439-4904945.post@n5.nabble.com>
	<201112061619.56224.tobias.geiger@vido.info>
	<1323210509.34541.YahooMailNeo@web29813.mail.ird.yahoo.com>
In-Reply-To: <1323210509.34541.YahooMailNeo@web29813.mail.ird.yahoo.com>
MIME-Version: 1.0
Message-Id: <201112071244.33763.tobias.geiger@vido.info>
Cc: David TECHER <davidtecher@yahoo.fr>
Subject: Re: [Xen-devel] Re : Re : Re : Re : Re : Re : Re : Re : Re : Re:
	Patches for VGA-Passthrough XEN 4.2 unstable
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-15"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi David,

i tried it also (reboot DomU) and to my surprise it didnt crash anymore! :)

BUT the passed through Card in DomU has very decreased Performance after th=
e =

reboot - i guess that has someting to do with what Allen Kay mentions in hi=
s =

slides here: http://www.linux-kvm.org/wiki/images/b/be/2011-forum-%24graphi=
cs-
direct-assignment.pdf (Slide 11) ?!

@Allen : i hope you dont mind me setting you CC here =


Greetings!
Tobias


Am Dienstag, 6. Dezember 2011, 23:28:39 schrieb David TECHER:
> Tobias,
> =

> When I restart my domU, my domU freezes (the boot screen of Windows XP is
> frozen with blue progression bar). Only my dom0 is available.
> =

> David.
> =

> =

> =

> ________________________________
>  De : Tobias Geiger [via Xen] <ml-node+s1045712n5052398h36@n5.nabble.com>
> =C0 : David TECHER <davidtecher@yahoo.fr>
> Envoy=E9 le : Mardi 6 D=E9cembre 2011 16h21
> Objet : Re: Re : Re : Re : Re : Re : Re : Re : Re : Re: Patches for
> VGA-Passthrough XEN 4.2 unstable
> =

> =

> Hello,
> =

> glad to hear it works for you!
> =

> As i run a similar setup, perhaps you can share your experience regarding
> DomU-Reboot with a VGA Card passed through to it: Does a reboot work, i.e.
> does the passed-through VGA Card work after a DomU reboot?
> =

> My hole System (DomU + Dom0) freezes after a reboot of DomU (exaclty then,
> when the passed-through VGA Card is accessed...), therefore the question.
> =

> Thanks for your info!
> Greetings
> Tobias
> =

> Am Dienstag, 6. Dezember 2011, 14:57:30 schrieb David TECHER:
> > Hi
> > =

> > Thanks for these informations. I am on Debian. So it could be usefull f=
or
> > Ubuntu users.
> > =

> > Thanks.
> > =

> > David
> > =

> > =

> > =

> > ________________________________
> >  De : n4rC0t1C <[hidden email]>
> > =C0 : [hidden email]
> > Envoy=E9 le : Mardi 6 D=E9cembre 2011 13h04
> > Objet : Re: [Xen-devel] Re : Re : Re : Re : Re : Re : Re : Re: Patches
> > for VGA-Passthrough XEN 4.2 unstable
> > =

> > Iep I used your last patches, (your website it's at the top of my
> > bookmarks), and they apply to xen-unstable rev. 24341 as well (which i'm
> > using).
> > =

> > I forgot to mention that I had to make a couple of fix to xen tree, cau=
se
> > it wasn't compiling on my system due to  "error: format not a string
> > literal and no format arguments":
> > =

> > =

> > --- /usr/src/xen-unstable.hg-rev-24341-460gtx/tools/libxl/libxl_create.c
> > +++ /usr/src/xen-unstable.hg-rev-24341-460gtx/tools/libxl/libxl_create.c
> > @@ -462,7 +462,7 @@
> >      path =3D libxl__xs_libxl_path(gc, domid);
> >      path =3D libxl__sprintf(gc, "%s/dm-version", path);
> >      return libxl__xs_write(gc, XBT_NULL, path, libxl__strdup(gc,
> > -    =

> > libxl_device_model_version_to_string(dm_info->device_model_version)));
> > +    =

> > libxl_device_model_version_to_string(dm_info->device_model_version)),"%=
s"
> > ); }
> > =

> > static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_confi=
g,
> > =

> > =

> > --- /usr/src/xen-unstable.hg-rev-24341-460gtx/tools/libxl/libxl_device.c
> > +++ /usr/src/xen-unstable.hg-rev-24341-460gtx/tools/libxl/libxl_device.c
> > @@ -516,7 +516,7 @@
> >          for (j =3D 0; j < num_devs; j++) {
> >              path =3D libxl__sprintf(gc,
> > "/local/domain/%d/device/%s/%s/backend",
> >                                    domid, kinds[i], devs[j]);
> > -            path =3D libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc,
> > path)); +            path =3D libxl__xs_read(gc, XBT_NULL,
> > libxl__sprintf(gc, path,"%s"));
> >              if (path && libxl__parse_backend_path(gc, path, &dev) =3D=
=3D 0)
> > { dev.domid =3D domid;
> >                  dev.kind =3D kind;
> > =

> > and an due to an argument missing:
> > =

> > --- /usr/src/xen-unstable.hg-rev-24341-460gtx/tools/libxl/libxl_dom.c
> > +++ /usr/src/xen-unstable.hg-rev-24341-460gtx/tools/libxl/libxl_dom.c
> > @@ -625,7 +625,7 @@
> >          break;
> >      }
> >      case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
> > -        fd2 =3D open(filename, O_WRONLY | O_CREAT | O_TRUNC);
> > +        fd2 =3D open(filename, O_WRONLY | O_CREAT | O_TRUNC, 0644);
> >          if (fd2 < 0) {
> >              LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
> >                               "Unable to create a QEMU save file\n");
> > =

> > As far as I know those doesn't break anything, but dont take too
> > seriously, i'm not an experienced developer :)
> > =

> > =

> > Forgot 2:
> > Since I'm using an ubuntu kernel, the xen support is not integrated, but
> > you need to add xen modules at your inittrd file. I did this by adding
> > those:
> > =

> > xen-pciback passthrough=3D1
> > xen-blkback
> > xenfs
> > xen-netback
> > pci-stub
> > =

> > to /etc/xen/initramfs-tools/modules and the issuing update-initramfs.
> > =

> > In the future, I'll try to boot a linux domU, right now I'm still smili=
ng
> > cause I can fully wipe my Windows installation from the hard disk. And
> > I'm sure that in future Win7 will be supported too.
> > =

> > Thanks again David and everyone,
> > Ivo
> =

> _______________________________________________
> Xen-devel mailing list
> [hidden email]
> http://lists.xensource.com/xen-devel
> =

> =

> ________________________________
> =

> If you reply to this email, your message will be added to the discussion
> below:http://xen.1045712.n5.nabble.com/Patches-for-VGA-Passthrough-XEN-4-2
> -unstable-tp4406265p5052398.html To unsubscribe from Patches for
> VGA-Passthrough XEN 4.2 unstable, click here. NAML
> =

> --
> View this message in context:
> http://xen.1045712.n5.nabble.com/Patches-for-VGA-Passthrough-XEN-4-2-unsta
> ble-tp4406265p5053675.html Sent from the Xen - Dev mailing list archive at
> Nabble.com.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 11:45:48 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 11:45:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYFwK-0001fR-Eg; Wed, 07 Dec 2011 11:45:32 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <tobias.geiger@vido.info>) id 1RYFwI-0001fH-Im
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 11:45:30 +0000
X-Env-Sender: tobias.geiger@vido.info
X-Msg-Ref: server-15.tower-216.messagelabs.com!1323258283!6487718!1
X-Originating-IP: [78.47.43.171]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5323 invoked from network); 7 Dec 2011 11:44:43 -0000
Received: from www.vido.info (HELO mail.vido.info) (78.47.43.171)
	by server-15.tower-216.messagelabs.com with SMTP;
	7 Dec 2011 11:44:43 -0000
Received: from localhost (ip6-localhost [127.0.0.1])
	by mail.vido.info (Postfix) with ESMTP id 4AD92D34669;
	Wed,  7 Dec 2011 12:44:43 +0100 (CET)
X-Virus-Scanned: by amavis at mail.vido.info
Received: from mail.vido.info ([127.0.0.1])
	by localhost (mail.vido.info [127.0.0.1]) (amavisd-new, port 10024)
	with LMTP id zB5y240z-gnr; Wed,  7 Dec 2011 12:44:37 +0100 (CET)
Received: from lxgeigert.localnet (et-1-10.gw-nat.bs.kae.de.oneandone.net
	[212.227.35.74])
	by mail.vido.info (Postfix) with ESMTPSA id 9911BD341A9;
	Wed,  7 Dec 2011 12:44:37 +0100 (CET)
From: Tobias Geiger <tobias.geiger@vido.info>
Organization: VIDO IT-Service
To: xen-devel@lists.xensource.com,
 allen.m.kay@intel.com
Date: Wed, 7 Dec 2011 12:44:33 +0100
User-Agent: KMail/1.13.7 (Linux/3.0.0-1-amd64; KDE/4.6.5; x86_64; ; )
References: <1318672856439-4904945.post@n5.nabble.com>
	<201112061619.56224.tobias.geiger@vido.info>
	<1323210509.34541.YahooMailNeo@web29813.mail.ird.yahoo.com>
In-Reply-To: <1323210509.34541.YahooMailNeo@web29813.mail.ird.yahoo.com>
MIME-Version: 1.0
Message-Id: <201112071244.33763.tobias.geiger@vido.info>
Cc: David TECHER <davidtecher@yahoo.fr>
Subject: Re: [Xen-devel] Re : Re : Re : Re : Re : Re : Re : Re : Re : Re:
	Patches for VGA-Passthrough XEN 4.2 unstable
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-15"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi David,

i tried it also (reboot DomU) and to my surprise it didnt crash anymore! :)

BUT the passed through Card in DomU has very decreased Performance after th=
e =

reboot - i guess that has someting to do with what Allen Kay mentions in hi=
s =

slides here: http://www.linux-kvm.org/wiki/images/b/be/2011-forum-%24graphi=
cs-
direct-assignment.pdf (Slide 11) ?!

@Allen : i hope you dont mind me setting you CC here =


Greetings!
Tobias


Am Dienstag, 6. Dezember 2011, 23:28:39 schrieb David TECHER:
> Tobias,
> =

> When I restart my domU, my domU freezes (the boot screen of Windows XP is
> frozen with blue progression bar). Only my dom0 is available.
> =

> David.
> =

> =

> =

> ________________________________
>  De : Tobias Geiger [via Xen] <ml-node+s1045712n5052398h36@n5.nabble.com>
> =C0 : David TECHER <davidtecher@yahoo.fr>
> Envoy=E9 le : Mardi 6 D=E9cembre 2011 16h21
> Objet : Re: Re : Re : Re : Re : Re : Re : Re : Re : Re: Patches for
> VGA-Passthrough XEN 4.2 unstable
> =

> =

> Hello,
> =

> glad to hear it works for you!
> =

> As i run a similar setup, perhaps you can share your experience regarding
> DomU-Reboot with a VGA Card passed through to it: Does a reboot work, i.e.
> does the passed-through VGA Card work after a DomU reboot?
> =

> My hole System (DomU + Dom0) freezes after a reboot of DomU (exaclty then,
> when the passed-through VGA Card is accessed...), therefore the question.
> =

> Thanks for your info!
> Greetings
> Tobias
> =

> Am Dienstag, 6. Dezember 2011, 14:57:30 schrieb David TECHER:
> > Hi
> > =

> > Thanks for these informations. I am on Debian. So it could be usefull f=
or
> > Ubuntu users.
> > =

> > Thanks.
> > =

> > David
> > =

> > =

> > =

> > ________________________________
> >  De : n4rC0t1C <[hidden email]>
> > =C0 : [hidden email]
> > Envoy=E9 le : Mardi 6 D=E9cembre 2011 13h04
> > Objet : Re: [Xen-devel] Re : Re : Re : Re : Re : Re : Re : Re: Patches
> > for VGA-Passthrough XEN 4.2 unstable
> > =

> > Iep I used your last patches, (your website it's at the top of my
> > bookmarks), and they apply to xen-unstable rev. 24341 as well (which i'm
> > using).
> > =

> > I forgot to mention that I had to make a couple of fix to xen tree, cau=
se
> > it wasn't compiling on my system due to  "error: format not a string
> > literal and no format arguments":
> > =

> > =

> > --- /usr/src/xen-unstable.hg-rev-24341-460gtx/tools/libxl/libxl_create.c
> > +++ /usr/src/xen-unstable.hg-rev-24341-460gtx/tools/libxl/libxl_create.c
> > @@ -462,7 +462,7 @@
> >      path =3D libxl__xs_libxl_path(gc, domid);
> >      path =3D libxl__sprintf(gc, "%s/dm-version", path);
> >      return libxl__xs_write(gc, XBT_NULL, path, libxl__strdup(gc,
> > -    =

> > libxl_device_model_version_to_string(dm_info->device_model_version)));
> > +    =

> > libxl_device_model_version_to_string(dm_info->device_model_version)),"%=
s"
> > ); }
> > =

> > static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_confi=
g,
> > =

> > =

> > --- /usr/src/xen-unstable.hg-rev-24341-460gtx/tools/libxl/libxl_device.c
> > +++ /usr/src/xen-unstable.hg-rev-24341-460gtx/tools/libxl/libxl_device.c
> > @@ -516,7 +516,7 @@
> >          for (j =3D 0; j < num_devs; j++) {
> >              path =3D libxl__sprintf(gc,
> > "/local/domain/%d/device/%s/%s/backend",
> >                                    domid, kinds[i], devs[j]);
> > -            path =3D libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc,
> > path)); +            path =3D libxl__xs_read(gc, XBT_NULL,
> > libxl__sprintf(gc, path,"%s"));
> >              if (path && libxl__parse_backend_path(gc, path, &dev) =3D=
=3D 0)
> > { dev.domid =3D domid;
> >                  dev.kind =3D kind;
> > =

> > and an due to an argument missing:
> > =

> > --- /usr/src/xen-unstable.hg-rev-24341-460gtx/tools/libxl/libxl_dom.c
> > +++ /usr/src/xen-unstable.hg-rev-24341-460gtx/tools/libxl/libxl_dom.c
> > @@ -625,7 +625,7 @@
> >          break;
> >      }
> >      case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
> > -        fd2 =3D open(filename, O_WRONLY | O_CREAT | O_TRUNC);
> > +        fd2 =3D open(filename, O_WRONLY | O_CREAT | O_TRUNC, 0644);
> >          if (fd2 < 0) {
> >              LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
> >                               "Unable to create a QEMU save file\n");
> > =

> > As far as I know those doesn't break anything, but dont take too
> > seriously, i'm not an experienced developer :)
> > =

> > =

> > Forgot 2:
> > Since I'm using an ubuntu kernel, the xen support is not integrated, but
> > you need to add xen modules at your inittrd file. I did this by adding
> > those:
> > =

> > xen-pciback passthrough=3D1
> > xen-blkback
> > xenfs
> > xen-netback
> > pci-stub
> > =

> > to /etc/xen/initramfs-tools/modules and the issuing update-initramfs.
> > =

> > In the future, I'll try to boot a linux domU, right now I'm still smili=
ng
> > cause I can fully wipe my Windows installation from the hard disk. And
> > I'm sure that in future Win7 will be supported too.
> > =

> > Thanks again David and everyone,
> > Ivo
> =

> _______________________________________________
> Xen-devel mailing list
> [hidden email]
> http://lists.xensource.com/xen-devel
> =

> =

> ________________________________
> =

> If you reply to this email, your message will be added to the discussion
> below:http://xen.1045712.n5.nabble.com/Patches-for-VGA-Passthrough-XEN-4-2
> -unstable-tp4406265p5052398.html To unsubscribe from Patches for
> VGA-Passthrough XEN 4.2 unstable, click here. NAML
> =

> --
> View this message in context:
> http://xen.1045712.n5.nabble.com/Patches-for-VGA-Passthrough-XEN-4-2-unsta
> ble-tp4406265p5053675.html Sent from the Xen - Dev mailing list archive at
> Nabble.com.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 12:23:46 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 12: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.xensource.com>)
	id 1RYGWi-000266-TC; Wed, 07 Dec 2011 12:23:08 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RYGWh-000261-6o
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 12:23:07 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1323260540!7152432!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjA3NQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14207 invoked from network); 7 Dec 2011 12:22:20 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Dec 2011 12:22:20 -0000
X-IronPort-AV: E=Sophos;i="4.71,313,1320624000"; 
   d="scan'208";a="9340692"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Dec 2011 12:22:19 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 7 Dec 2011 12:22:19 +0000
Date: Wed, 7 Dec 2011 12:23:23 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: "Zhang, Xiantao" <xiantao.zhang@intel.com>
In-Reply-To: <BC00F5384FCFC9499AF06F92E8B78A9E287D4A0E53@shsmsx502.ccr.corp.intel.com>
Message-ID: <alpine.DEB.2.00.1112071222580.31179@kaball-desktop>
References: <alpine.DEB.2.00.1112061753410.31179@kaball-desktop>
	<1323195609-17277-4-git-send-email-stefano.stabellini@eu.citrix.com>
	<BC00F5384FCFC9499AF06F92E8B78A9E287D4A0E53@shsmsx502.ccr.corp.intel.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "Tim Deegan \(3P\)" <Tim.Deegan@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH RFC 04/25] Replace "/" operand with div64
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 7 Dec 2011, Zhang, Xiantao wrote:
> Hi, Stefano 
> Great work from you guys!  One quick comment:  Just found the below logic's change maybe wrong and probably  break current things. 
> Original logic is  A+B -(C%D), but it is changed to  (A+B-C)%D,  so if it is not an intended fix, it should be an issue. 
> Thanks!
> Xiantao  

True! Thanks for spotting this!

> >diff --git a/xen/common/timer.c b/xen/common/timer.c index 0547ea3..043250e 100644
> >--- a/xen/common/timer.c
> >+++ b/xen/common/timer.c
> >@@ -23,6 +23,7 @@
> >#include <xen/symbols.h>
> >#include <asm/system.h>
> >#include <asm/desc.h>
> >+#include <asm/div64.h>
> > #include <asm/atomic.h>
> > 
> > /* We program the time hardware this far behind the closest deadline. */ @@ -503,16 +504,18 @@ static void timer_softirq_action(void)
> > 
> > s_time_t align_timer(s_time_t firsttick, uint64_t period)  {
> >+    uint64_t n;
>  >    if ( !period )
>  >        return firsttick;
>  
> >-    return firsttick + (period - 1) - ((firsttick - 1) % period);
> >+    n = firsttick + (period - 1) - (firsttick - 1);
> >+    return do_div(n, period);
> > }
>  
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 12:23:46 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 12: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.xensource.com>)
	id 1RYGWi-000266-TC; Wed, 07 Dec 2011 12:23:08 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RYGWh-000261-6o
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 12:23:07 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1323260540!7152432!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjA3NQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14207 invoked from network); 7 Dec 2011 12:22:20 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Dec 2011 12:22:20 -0000
X-IronPort-AV: E=Sophos;i="4.71,313,1320624000"; 
   d="scan'208";a="9340692"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Dec 2011 12:22:19 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 7 Dec 2011 12:22:19 +0000
Date: Wed, 7 Dec 2011 12:23:23 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: "Zhang, Xiantao" <xiantao.zhang@intel.com>
In-Reply-To: <BC00F5384FCFC9499AF06F92E8B78A9E287D4A0E53@shsmsx502.ccr.corp.intel.com>
Message-ID: <alpine.DEB.2.00.1112071222580.31179@kaball-desktop>
References: <alpine.DEB.2.00.1112061753410.31179@kaball-desktop>
	<1323195609-17277-4-git-send-email-stefano.stabellini@eu.citrix.com>
	<BC00F5384FCFC9499AF06F92E8B78A9E287D4A0E53@shsmsx502.ccr.corp.intel.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "Tim Deegan \(3P\)" <Tim.Deegan@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH RFC 04/25] Replace "/" operand with div64
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 7 Dec 2011, Zhang, Xiantao wrote:
> Hi, Stefano 
> Great work from you guys!  One quick comment:  Just found the below logic's change maybe wrong and probably  break current things. 
> Original logic is  A+B -(C%D), but it is changed to  (A+B-C)%D,  so if it is not an intended fix, it should be an issue. 
> Thanks!
> Xiantao  

True! Thanks for spotting this!

> >diff --git a/xen/common/timer.c b/xen/common/timer.c index 0547ea3..043250e 100644
> >--- a/xen/common/timer.c
> >+++ b/xen/common/timer.c
> >@@ -23,6 +23,7 @@
> >#include <xen/symbols.h>
> >#include <asm/system.h>
> >#include <asm/desc.h>
> >+#include <asm/div64.h>
> > #include <asm/atomic.h>
> > 
> > /* We program the time hardware this far behind the closest deadline. */ @@ -503,16 +504,18 @@ static void timer_softirq_action(void)
> > 
> > s_time_t align_timer(s_time_t firsttick, uint64_t period)  {
> >+    uint64_t n;
>  >    if ( !period )
>  >        return firsttick;
>  
> >-    return firsttick + (period - 1) - ((firsttick - 1) % period);
> >+    n = firsttick + (period - 1) - (firsttick - 1);
> >+    return do_div(n, period);
> > }
>  
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 12:45:01 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 12:45:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYGrL-0002Nt-V2; Wed, 07 Dec 2011 12:44:27 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RYGrK-0002No-Ak
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 12:44:26 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-10.tower-216.messagelabs.com!1323261818!6416241!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13922 invoked from network); 7 Dec 2011 12:43:39 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-10.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 7 Dec 2011 12:43:39 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RYGqK-000EkW-QD; Wed, 07 Dec 2011 12:43:24 +0000
Date: Wed, 7 Dec 2011 12:43:24 +0000
From: Tim Deegan <tim@xen.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20111207124324.GF31448@ocelot.phlegethon.org>
References: <alpine.DEB.2.00.1112061753410.31179@kaball-desktop>
	<1323195609-17277-2-git-send-email-stefano.stabellini@eu.citrix.com>
	<4EDF39210200007800065E15@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4EDF39210200007800065E15@nat28.tlf.novell.com>
User-Agent: Mutt/1.4.2.1i
Cc: "Tim Deegan \(3P\)" <Tim.Deegan@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH RFC 02/25] A collection of fixes to Xen
	common files
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 09:00 +0000 on 07 Dec (1323248401), Jan Beulich wrote:
> >>> On 06.12.11 at 19:19, <stefano.stabellini@eu.citrix.com> wrote:
> > - call free_xenoprof_pages only ifdef xenoprof;
> 
> I can't find where this symbol would get defined, so effectively you're
> removing the call unconditionally.
> 
> > +extern char _srodata[], _erodata[];
> 
> While I realize that this isn't currently the case on e.g. the respective
> .text symbols, if you introduce new once, please add const to the
> declarations *at least* when the section contents really are read only
> (in many cases doing so even for writable sections is likely appropriate
> too).

Is this just a question of style or is there any practical consequence?
(not that I object to adding 'const' here; I'm just curious)

Tim.

> > +#define is_kernel_rodata(p) ({                  \
> > +    char *__p = (char *)(unsigned long)(p);     \
> > +    (__p >= _srodata) && (__p < _erodata);      \
> 
> Obviously the above calls for adjustments here, too.
> 
> Jan
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 12:45:01 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 12:45:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYGrL-0002Nt-V2; Wed, 07 Dec 2011 12:44:27 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RYGrK-0002No-Ak
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 12:44:26 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-10.tower-216.messagelabs.com!1323261818!6416241!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13922 invoked from network); 7 Dec 2011 12:43:39 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-10.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 7 Dec 2011 12:43:39 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RYGqK-000EkW-QD; Wed, 07 Dec 2011 12:43:24 +0000
Date: Wed, 7 Dec 2011 12:43:24 +0000
From: Tim Deegan <tim@xen.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20111207124324.GF31448@ocelot.phlegethon.org>
References: <alpine.DEB.2.00.1112061753410.31179@kaball-desktop>
	<1323195609-17277-2-git-send-email-stefano.stabellini@eu.citrix.com>
	<4EDF39210200007800065E15@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4EDF39210200007800065E15@nat28.tlf.novell.com>
User-Agent: Mutt/1.4.2.1i
Cc: "Tim Deegan \(3P\)" <Tim.Deegan@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH RFC 02/25] A collection of fixes to Xen
	common files
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 09:00 +0000 on 07 Dec (1323248401), Jan Beulich wrote:
> >>> On 06.12.11 at 19:19, <stefano.stabellini@eu.citrix.com> wrote:
> > - call free_xenoprof_pages only ifdef xenoprof;
> 
> I can't find where this symbol would get defined, so effectively you're
> removing the call unconditionally.
> 
> > +extern char _srodata[], _erodata[];
> 
> While I realize that this isn't currently the case on e.g. the respective
> .text symbols, if you introduce new once, please add const to the
> declarations *at least* when the section contents really are read only
> (in many cases doing so even for writable sections is likely appropriate
> too).

Is this just a question of style or is there any practical consequence?
(not that I object to adding 'const' here; I'm just curious)

Tim.

> > +#define is_kernel_rodata(p) ({                  \
> > +    char *__p = (char *)(unsigned long)(p);     \
> > +    (__p >= _srodata) && (__p < _erodata);      \
> 
> Obviously the above calls for adjustments here, too.
> 
> Jan
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 12:48:17 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 12:48:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYGue-0002UT-JA; Wed, 07 Dec 2011 12:47:52 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RYGuc-0002UE-O2
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 12:47:50 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1323262023!4589536!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM1ODk=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27733 invoked from network); 7 Dec 2011 12:47:03 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-8.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 7 Dec 2011 12:47:03 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 07 Dec 2011 12:47:02 +0000
Message-Id: <4EDF6E810200007800065F76@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 07 Dec 2011 12:47:45 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Stefano Stabellini" <stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1112061753410.31179@kaball-desktop>
	<1323195609-17277-2-git-send-email-stefano.stabellini@eu.citrix.com>
	<4EDF39210200007800065E15@nat28.tlf.novell.com>
	<alpine.DEB.2.00.1112071111270.31179@kaball-desktop>
In-Reply-To: <alpine.DEB.2.00.1112071111270.31179@kaball-desktop>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"Tim Deegan \(3P\)" <Tim.Deegan@citrix.com>
Subject: Re: [Xen-devel] [PATCH RFC 02/25] A collection of fixes to Xen
 common files
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 07.12.11 at 12:20, Stefano Stabellini <stefano.stabellini@eu.citrix.com>
wrote:
> On Wed, 7 Dec 2011, Jan Beulich wrote:
>> >>> On 06.12.11 at 19:19, <stefano.stabellini@eu.citrix.com> wrote:
>> > +extern char _srodata[], _erodata[];
>> 
>> While I realize that this isn't currently the case on e.g. the respective
>> .text symbols, if you introduce new once, please add const to the
>> declarations *at least* when the section contents really are read only
>> (in many cases doing so even for writable sections is likely appropriate
>> too).
> 
> OK
> 
> 
>> > +#define is_kernel_rodata(p) ({                  \
>> > +    char *__p = (char *)(unsigned long)(p);     \
>> > +    (__p >= _srodata) && (__p < _erodata);      \
>> 
>> Obviously the above calls for adjustments here, too.
> 
> sorry I am not sure what you mean

Should be 'const char *' at least in the declaration of 'p' (but perhaps
also in the cast).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 12:48:17 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 12:48:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYGue-0002UT-JA; Wed, 07 Dec 2011 12:47:52 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RYGuc-0002UE-O2
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 12:47:50 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1323262023!4589536!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM1ODk=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27733 invoked from network); 7 Dec 2011 12:47:03 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-8.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 7 Dec 2011 12:47:03 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 07 Dec 2011 12:47:02 +0000
Message-Id: <4EDF6E810200007800065F76@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 07 Dec 2011 12:47:45 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Stefano Stabellini" <stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1112061753410.31179@kaball-desktop>
	<1323195609-17277-2-git-send-email-stefano.stabellini@eu.citrix.com>
	<4EDF39210200007800065E15@nat28.tlf.novell.com>
	<alpine.DEB.2.00.1112071111270.31179@kaball-desktop>
In-Reply-To: <alpine.DEB.2.00.1112071111270.31179@kaball-desktop>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"Tim Deegan \(3P\)" <Tim.Deegan@citrix.com>
Subject: Re: [Xen-devel] [PATCH RFC 02/25] A collection of fixes to Xen
 common files
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 07.12.11 at 12:20, Stefano Stabellini <stefano.stabellini@eu.citrix.com>
wrote:
> On Wed, 7 Dec 2011, Jan Beulich wrote:
>> >>> On 06.12.11 at 19:19, <stefano.stabellini@eu.citrix.com> wrote:
>> > +extern char _srodata[], _erodata[];
>> 
>> While I realize that this isn't currently the case on e.g. the respective
>> .text symbols, if you introduce new once, please add const to the
>> declarations *at least* when the section contents really are read only
>> (in many cases doing so even for writable sections is likely appropriate
>> too).
> 
> OK
> 
> 
>> > +#define is_kernel_rodata(p) ({                  \
>> > +    char *__p = (char *)(unsigned long)(p);     \
>> > +    (__p >= _srodata) && (__p < _erodata);      \
>> 
>> Obviously the above calls for adjustments here, too.
> 
> sorry I am not sure what you mean

Should be 'const char *' at least in the declaration of 'p' (but perhaps
also in the cast).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 12:49:15 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 12:49:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYGvZ-0002YC-5w; Wed, 07 Dec 2011 12:48:49 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RYGvX-0002Xp-PP
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 12:48:47 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1323261509!6422858!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjA3NQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10559 invoked from network); 7 Dec 2011 12:38:29 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Dec 2011 12:38:29 -0000
X-IronPort-AV: E=Sophos;i="4.71,313,1320624000"; 
   d="scan'208";a="9341298"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Dec 2011 12:38:29 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 7 Dec 2011 12:38:29 +0000
Date: Wed, 7 Dec 2011 12:39:33 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1323257884.23681.163.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1112071232170.31179@kaball-desktop>
References: <alpine.DEB.2.00.1112061753410.31179@kaball-desktop>
	<1323195609-17277-2-git-send-email-stefano.stabellini@eu.citrix.com>
	<4EDF39210200007800065E15@nat28.tlf.novell.com>
	<alpine.DEB.2.00.1112071111270.31179@kaball-desktop>
	<1323257884.23681.163.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Tim Deegan \(3P\)" <Tim.Deegan@citrix.com>,
	Jan Beulich <JBeulich@suse.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH RFC 02/25] A collection of fixes to Xen
 common files
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 7 Dec 2011, Ian Campbell wrote:
> On Wed, 2011-12-07 at 11:20 +0000, Stefano Stabellini wrote:
> > On Wed, 7 Dec 2011, Jan Beulich wrote:
> > > >>> On 06.12.11 at 19:19, <stefano.stabellini@eu.citrix.com> wrote:
> > > > - call free_xenoprof_pages only ifdef xenoprof;
> > > 
> > > I can't find where this symbol would get defined, so effectively you're
> > > removing the call unconditionally.
> > 
> > The symbol is already defined in xen/arch/x86/Rules.mk and
> > xen/arch/ia64/Rules.mk.
> 
> That's a Makefile variable -- it's not exposed to the C preprocessor, is
> it?

Now I realize that I have made this mistake a few times: in this
patch and in patch #7.

I am going to add the missing symbols to config.h.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 12:49:15 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 12:49:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYGvZ-0002YC-5w; Wed, 07 Dec 2011 12:48:49 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RYGvX-0002Xp-PP
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 12:48:47 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1323261509!6422858!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjA3NQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10559 invoked from network); 7 Dec 2011 12:38:29 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Dec 2011 12:38:29 -0000
X-IronPort-AV: E=Sophos;i="4.71,313,1320624000"; 
   d="scan'208";a="9341298"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Dec 2011 12:38:29 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 7 Dec 2011 12:38:29 +0000
Date: Wed, 7 Dec 2011 12:39:33 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1323257884.23681.163.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1112071232170.31179@kaball-desktop>
References: <alpine.DEB.2.00.1112061753410.31179@kaball-desktop>
	<1323195609-17277-2-git-send-email-stefano.stabellini@eu.citrix.com>
	<4EDF39210200007800065E15@nat28.tlf.novell.com>
	<alpine.DEB.2.00.1112071111270.31179@kaball-desktop>
	<1323257884.23681.163.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Tim Deegan \(3P\)" <Tim.Deegan@citrix.com>,
	Jan Beulich <JBeulich@suse.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH RFC 02/25] A collection of fixes to Xen
 common files
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 7 Dec 2011, Ian Campbell wrote:
> On Wed, 2011-12-07 at 11:20 +0000, Stefano Stabellini wrote:
> > On Wed, 7 Dec 2011, Jan Beulich wrote:
> > > >>> On 06.12.11 at 19:19, <stefano.stabellini@eu.citrix.com> wrote:
> > > > - call free_xenoprof_pages only ifdef xenoprof;
> > > 
> > > I can't find where this symbol would get defined, so effectively you're
> > > removing the call unconditionally.
> > 
> > The symbol is already defined in xen/arch/x86/Rules.mk and
> > xen/arch/ia64/Rules.mk.
> 
> That's a Makefile variable -- it's not exposed to the C preprocessor, is
> it?

Now I realize that I have made this mistake a few times: in this
patch and in patch #7.

I am going to add the missing symbols to config.h.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 12:50:27 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 12:50:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYGwi-0002ey-Kr; Wed, 07 Dec 2011 12:50:00 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RYGwg-0002eH-MJ
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 12:49:58 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1323262150!4594575!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM1ODk=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7918 invoked from network); 7 Dec 2011 12:49:11 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-4.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 7 Dec 2011 12:49:11 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 07 Dec 2011 12:49:10 +0000
Message-Id: <4EDF6F010200007800065F79@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 07 Dec 2011 12:49:53 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tim Deegan" <tim@xen.org>
References: <alpine.DEB.2.00.1112061753410.31179@kaball-desktop>
	<1323195609-17277-2-git-send-email-stefano.stabellini@eu.citrix.com>
	<4EDF39210200007800065E15@nat28.tlf.novell.com>
	<20111207124324.GF31448@ocelot.phlegethon.org>
In-Reply-To: <20111207124324.GF31448@ocelot.phlegethon.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"Tim Deegan \(3P\)" <Tim.Deegan@citrix.com>
Subject: Re: [Xen-devel] [PATCH RFC 02/25] A collection of fixes to Xen
 common files
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 07.12.11 at 13:43, Tim Deegan <tim@xen.org> wrote:
> At 09:00 +0000 on 07 Dec (1323248401), Jan Beulich wrote:
>> >>> On 06.12.11 at 19:19, <stefano.stabellini@eu.citrix.com> wrote:
>> > - call free_xenoprof_pages only ifdef xenoprof;
>> 
>> I can't find where this symbol would get defined, so effectively you're
>> removing the call unconditionally.
>> 
>> > +extern char _srodata[], _erodata[];
>> 
>> While I realize that this isn't currently the case on e.g. the respective
>> .text symbols, if you introduce new once, please add const to the
>> declarations *at least* when the section contents really are read only
>> (in many cases doing so even for writable sections is likely appropriate
>> too).
> 
> Is this just a question of style or is there any practical consequence?
> (not that I object to adding 'const' here; I'm just curious)

Pointers to non-modifiable data should never lack const, to avoid them
accidentally (perhaps through several layers of functions) being passed
to something that does actually write through them. (This is on the
same page as avoiding casts in general when possible, but specifically
such that cast away const-ness.)

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 12:50:27 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 12:50:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYGwi-0002ey-Kr; Wed, 07 Dec 2011 12:50:00 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RYGwg-0002eH-MJ
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 12:49:58 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1323262150!4594575!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM1ODk=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7918 invoked from network); 7 Dec 2011 12:49:11 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-4.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 7 Dec 2011 12:49:11 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 07 Dec 2011 12:49:10 +0000
Message-Id: <4EDF6F010200007800065F79@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 07 Dec 2011 12:49:53 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tim Deegan" <tim@xen.org>
References: <alpine.DEB.2.00.1112061753410.31179@kaball-desktop>
	<1323195609-17277-2-git-send-email-stefano.stabellini@eu.citrix.com>
	<4EDF39210200007800065E15@nat28.tlf.novell.com>
	<20111207124324.GF31448@ocelot.phlegethon.org>
In-Reply-To: <20111207124324.GF31448@ocelot.phlegethon.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"Tim Deegan \(3P\)" <Tim.Deegan@citrix.com>
Subject: Re: [Xen-devel] [PATCH RFC 02/25] A collection of fixes to Xen
 common files
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 07.12.11 at 13:43, Tim Deegan <tim@xen.org> wrote:
> At 09:00 +0000 on 07 Dec (1323248401), Jan Beulich wrote:
>> >>> On 06.12.11 at 19:19, <stefano.stabellini@eu.citrix.com> wrote:
>> > - call free_xenoprof_pages only ifdef xenoprof;
>> 
>> I can't find where this symbol would get defined, so effectively you're
>> removing the call unconditionally.
>> 
>> > +extern char _srodata[], _erodata[];
>> 
>> While I realize that this isn't currently the case on e.g. the respective
>> .text symbols, if you introduce new once, please add const to the
>> declarations *at least* when the section contents really are read only
>> (in many cases doing so even for writable sections is likely appropriate
>> too).
> 
> Is this just a question of style or is there any practical consequence?
> (not that I object to adding 'const' here; I'm just curious)

Pointers to non-modifiable data should never lack const, to avoid them
accidentally (perhaps through several layers of functions) being passed
to something that does actually write through them. (This is on the
same page as avoiding casts in general when possible, but specifically
such that cast away const-ness.)

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 12:55:08 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 12:55:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYH1O-0002zO-HW; Wed, 07 Dec 2011 12:54:50 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1RYH1M-0002z9-KP
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 12:54:48 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1323262440!6535835!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjk1NTQ=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30517 invoked from network); 7 Dec 2011 12:54:01 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Dec 2011 12:54:01 -0000
X-IronPort-AV: E=Sophos;i="4.71,313,1320642000"; d="scan'208";a="173224356"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Dec 2011 07:53:56 -0500
Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX01.citrite.net
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Wed, 7 Dec 2011
	07:53:56 -0500
Message-ID: <4EDF61E2.20709@citrix.com>
Date: Wed, 7 Dec 2011 12:53:54 +0000
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20111110 Icedove/3.0.11
MIME-Version: 1.0
To: <stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1112061753410.31179@kaball-desktop>
	<1323195609-17277-2-git-send-email-stefano.stabellini@eu.citrix.com>
In-Reply-To: <1323195609-17277-2-git-send-email-stefano.stabellini@eu.citrix.com>
Cc: xen-devel@lists.xensource.com, Ian Campbell <ian.campbell@citrix.com>,
	Tim.Deegan@citrix.com
Subject: Re: [Xen-devel] [PATCH RFC 02/25] A collection of fixes to Xen
 common files
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 06/12/11 18:19, stefano.stabellini@eu.citrix.com wrote:
> From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> 
> - call free_xenoprof_pages only ifdef xenoprof;

I think you want empty inline stub functions on ARM instead of an #ifdef
here.

David


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 12:55:08 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 12:55:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYH1O-0002zO-HW; Wed, 07 Dec 2011 12:54:50 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1RYH1M-0002z9-KP
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 12:54:48 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1323262440!6535835!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjk1NTQ=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30517 invoked from network); 7 Dec 2011 12:54:01 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Dec 2011 12:54:01 -0000
X-IronPort-AV: E=Sophos;i="4.71,313,1320642000"; d="scan'208";a="173224356"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Dec 2011 07:53:56 -0500
Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX01.citrite.net
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Wed, 7 Dec 2011
	07:53:56 -0500
Message-ID: <4EDF61E2.20709@citrix.com>
Date: Wed, 7 Dec 2011 12:53:54 +0000
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20111110 Icedove/3.0.11
MIME-Version: 1.0
To: <stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1112061753410.31179@kaball-desktop>
	<1323195609-17277-2-git-send-email-stefano.stabellini@eu.citrix.com>
In-Reply-To: <1323195609-17277-2-git-send-email-stefano.stabellini@eu.citrix.com>
Cc: xen-devel@lists.xensource.com, Ian Campbell <ian.campbell@citrix.com>,
	Tim.Deegan@citrix.com
Subject: Re: [Xen-devel] [PATCH RFC 02/25] A collection of fixes to Xen
 common files
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 06/12/11 18:19, stefano.stabellini@eu.citrix.com wrote:
> From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> 
> - call free_xenoprof_pages only ifdef xenoprof;

I think you want empty inline stub functions on ARM instead of an #ifdef
here.

David


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 12:57:57 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 12:57:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYH47-0003E8-PY; Wed, 07 Dec 2011 12:57:39 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RYH46-0003Dg-B4
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 12:57:38 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1323262611!4614018!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM1ODk=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7359 invoked from network); 7 Dec 2011 12:56:51 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-6.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 7 Dec 2011 12:56:51 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 07 Dec 2011 12:56:50 +0000
Message-Id: <4EDF70CD0200007800065F91@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 07 Dec 2011 12:57:33 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Stefano Stabellini" <stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1112061753410.31179@kaball-desktop>
	<1323195609-17277-7-git-send-email-stefano.stabellini@eu.citrix.com>
	<4EDF47360200007800065E7C@nat28.tlf.novell.com>
	<alpine.DEB.2.00.1112071123360.31179@kaball-desktop>
In-Reply-To: <alpine.DEB.2.00.1112071123360.31179@kaball-desktop>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"Tim Deegan \(3P\)" <Tim.Deegan@citrix.com>
Subject: Re: [Xen-devel] [PATCH RFC 07/25] xen/common/Makefile: introduce
 HAS_CPUFREQ, HAS_PCI, HAS_PASSTHROUGH, HAS_NS16550
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 07.12.11 at 12:24, Stefano Stabellini <stefano.stabellini@eu.citrix.com>
wrote:
> On Wed, 7 Dec 2011, Jan Beulich wrote:
>> >>> On 06.12.11 at 19:19, <stefano.stabellini@eu.citrix.com> wrote:
>> > From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
>> > 
>> > - make the compilation of ns16550.c depend upon HAS_NS16550;
>> > 
>> > - make the compilation of cpufreq depend upon HAS_CPUFREQ;
>> > 
>> > - make the compilation of pci depend upon HAS_PCI;
>> > 
>> > - make the compilation of passthrough depend upon HAS_PASSTHROUGH;
>> > 
>> > - make the compilation of kexec.o depend on HAS_ACPI.
>> 
>> How are kexec and ACPI connected to one another?
> 
> Today kexec implementation is dependent on ACPI.

The only dependency I can spot is the call to acpi_dmar_reinstate(),
which could clearly get an inline stub on platforms that don't have
ACPI (or pass-through).

> Should I introduce a separate HAS_KEXEC config option, for the sake of
> clarity?

Yes, if you need it off for ARM.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 12:57:57 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 12:57:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYH47-0003E8-PY; Wed, 07 Dec 2011 12:57:39 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RYH46-0003Dg-B4
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 12:57:38 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1323262611!4614018!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM1ODk=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7359 invoked from network); 7 Dec 2011 12:56:51 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-6.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 7 Dec 2011 12:56:51 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 07 Dec 2011 12:56:50 +0000
Message-Id: <4EDF70CD0200007800065F91@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 07 Dec 2011 12:57:33 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Stefano Stabellini" <stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1112061753410.31179@kaball-desktop>
	<1323195609-17277-7-git-send-email-stefano.stabellini@eu.citrix.com>
	<4EDF47360200007800065E7C@nat28.tlf.novell.com>
	<alpine.DEB.2.00.1112071123360.31179@kaball-desktop>
In-Reply-To: <alpine.DEB.2.00.1112071123360.31179@kaball-desktop>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"Tim Deegan \(3P\)" <Tim.Deegan@citrix.com>
Subject: Re: [Xen-devel] [PATCH RFC 07/25] xen/common/Makefile: introduce
 HAS_CPUFREQ, HAS_PCI, HAS_PASSTHROUGH, HAS_NS16550
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 07.12.11 at 12:24, Stefano Stabellini <stefano.stabellini@eu.citrix.com>
wrote:
> On Wed, 7 Dec 2011, Jan Beulich wrote:
>> >>> On 06.12.11 at 19:19, <stefano.stabellini@eu.citrix.com> wrote:
>> > From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
>> > 
>> > - make the compilation of ns16550.c depend upon HAS_NS16550;
>> > 
>> > - make the compilation of cpufreq depend upon HAS_CPUFREQ;
>> > 
>> > - make the compilation of pci depend upon HAS_PCI;
>> > 
>> > - make the compilation of passthrough depend upon HAS_PASSTHROUGH;
>> > 
>> > - make the compilation of kexec.o depend on HAS_ACPI.
>> 
>> How are kexec and ACPI connected to one another?
> 
> Today kexec implementation is dependent on ACPI.

The only dependency I can spot is the call to acpi_dmar_reinstate(),
which could clearly get an inline stub on platforms that don't have
ACPI (or pass-through).

> Should I introduce a separate HAS_KEXEC config option, for the sake of
> clarity?

Yes, if you need it off for ARM.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 12:58:13 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 12:58:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYH4P-0003GS-6s; Wed, 07 Dec 2011 12:57:57 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RYH4N-0003FU-Od
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 12:57:55 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1323262628!6499522!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjA3NQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21366 invoked from network); 7 Dec 2011 12:57:08 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Dec 2011 12:57:08 -0000
X-IronPort-AV: E=Sophos;i="4.71,313,1320624000"; 
   d="scan'208";a="9341752"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Dec 2011 12:57:08 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 7 Dec 2011 12:57:08 +0000
Date: Wed, 7 Dec 2011 12:58:22 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: David Vrabel <david.vrabel@citrix.com>
In-Reply-To: <4EDF61E2.20709@citrix.com>
Message-ID: <alpine.DEB.2.00.1112071256490.31179@kaball-desktop>
References: <alpine.DEB.2.00.1112061753410.31179@kaball-desktop>
	<1323195609-17277-2-git-send-email-stefano.stabellini@eu.citrix.com>
	<4EDF61E2.20709@citrix.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "Tim Deegan \(3P\)" <Tim.Deegan@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH RFC 02/25] A collection of fixes to Xen
 common files
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 7 Dec 2011, David Vrabel wrote:
> On 06/12/11 18:19, stefano.stabellini@eu.citrix.com wrote:
> > From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > 
> > - call free_xenoprof_pages only ifdef xenoprof;
> 
> I think you want empty inline stub functions on ARM instead of an #ifdef
> here.
 
Generally I would prefer stub functions, but in this case, considering
that a makefile symbol already exists to avoid compiling xenoprof, I
think it is better to make sure xenoprof can actually be compiled out
successfully.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 12:58:13 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 12:58:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYH4P-0003GS-6s; Wed, 07 Dec 2011 12:57:57 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RYH4N-0003FU-Od
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 12:57:55 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1323262628!6499522!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjA3NQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21366 invoked from network); 7 Dec 2011 12:57:08 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Dec 2011 12:57:08 -0000
X-IronPort-AV: E=Sophos;i="4.71,313,1320624000"; 
   d="scan'208";a="9341752"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Dec 2011 12:57:08 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 7 Dec 2011 12:57:08 +0000
Date: Wed, 7 Dec 2011 12:58:22 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: David Vrabel <david.vrabel@citrix.com>
In-Reply-To: <4EDF61E2.20709@citrix.com>
Message-ID: <alpine.DEB.2.00.1112071256490.31179@kaball-desktop>
References: <alpine.DEB.2.00.1112061753410.31179@kaball-desktop>
	<1323195609-17277-2-git-send-email-stefano.stabellini@eu.citrix.com>
	<4EDF61E2.20709@citrix.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "Tim Deegan \(3P\)" <Tim.Deegan@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH RFC 02/25] A collection of fixes to Xen
 common files
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 7 Dec 2011, David Vrabel wrote:
> On 06/12/11 18:19, stefano.stabellini@eu.citrix.com wrote:
> > From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > 
> > - call free_xenoprof_pages only ifdef xenoprof;
> 
> I think you want empty inline stub functions on ARM instead of an #ifdef
> here.
 
Generally I would prefer stub functions, but in this case, considering
that a makefile symbol already exists to avoid compiling xenoprof, I
think it is better to make sure xenoprof can actually be compiled out
successfully.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 12:59:10 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 12:59:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYH5L-0003Qb-Mj; Wed, 07 Dec 2011 12:58:55 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RYH5K-0003PP-6a
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 12:58:54 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-9.tower-216.messagelabs.com!1323262687!6536632!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16195 invoked from network); 7 Dec 2011 12:58:07 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-9.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 7 Dec 2011 12:58:07 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RYH4X-000En6-Bc; Wed, 07 Dec 2011 12:58:05 +0000
Date: Wed, 7 Dec 2011 12:58:05 +0000
From: Tim Deegan <tim@xen.org>
To: Olaf Hering <olaf@aepfle.de>
Message-ID: <20111207125805.GG31448@ocelot.phlegethon.org>
References: <mailman.3467.1323191271.12970.xen-devel@lists.xensource.com>
	<78bcef1bbb35c6176c138c1a6089f034.squirrel@webmail.lagarcavilla.org>
	<20111207092737.GA24563@aepfle.de>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20111207092737.GA24563@aepfle.de>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>
Subject: Re: [Xen-devel] [PATCH 2 of 5] xenpaging: map gfn before nomination
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 10:27 +0100 on 07 Dec (1323253657), Olaf Hering wrote:
> On Tue, Dec 06, Andres Lagar-Cavilla wrote:
> 
> > Ouch! You're absolutely tying the user space pager with the underlying xen
> > paging code. Most of your patches change the tools and the hypervisor in
> > lockstep.
> 
> Yes, pager and hypervisor are bound closely together.
> 
> > Patch 4 in your series is one such case. Short-cutting the state machine:
> > great. But what is the gain for the hypervisor in *not* sending the
> > EVICT_FAIL event. It's a good thing. It keeps the same interface to
> > user-space. Xenpaging may not need it, but the Xen paging code does not
> > exist solely for xenpaging.
> 
> What IS the need to send yet another request? It adds just overhead for
> no obvious need. Please show the code that will benefit from the extra
> EVICT_FAIL message.

While in general it's good to keep backward compatibility, I don't think
this interface has ever had a stable, usable release (that didn't
involve the consumer at least carrying hypervisor patches of their own)
so I think it's OK to make fairly large changes in it. 

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 12:59:10 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 12:59:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYH5L-0003Qb-Mj; Wed, 07 Dec 2011 12:58:55 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RYH5K-0003PP-6a
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 12:58:54 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-9.tower-216.messagelabs.com!1323262687!6536632!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16195 invoked from network); 7 Dec 2011 12:58:07 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-9.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 7 Dec 2011 12:58:07 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RYH4X-000En6-Bc; Wed, 07 Dec 2011 12:58:05 +0000
Date: Wed, 7 Dec 2011 12:58:05 +0000
From: Tim Deegan <tim@xen.org>
To: Olaf Hering <olaf@aepfle.de>
Message-ID: <20111207125805.GG31448@ocelot.phlegethon.org>
References: <mailman.3467.1323191271.12970.xen-devel@lists.xensource.com>
	<78bcef1bbb35c6176c138c1a6089f034.squirrel@webmail.lagarcavilla.org>
	<20111207092737.GA24563@aepfle.de>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20111207092737.GA24563@aepfle.de>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>
Subject: Re: [Xen-devel] [PATCH 2 of 5] xenpaging: map gfn before nomination
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 10:27 +0100 on 07 Dec (1323253657), Olaf Hering wrote:
> On Tue, Dec 06, Andres Lagar-Cavilla wrote:
> 
> > Ouch! You're absolutely tying the user space pager with the underlying xen
> > paging code. Most of your patches change the tools and the hypervisor in
> > lockstep.
> 
> Yes, pager and hypervisor are bound closely together.
> 
> > Patch 4 in your series is one such case. Short-cutting the state machine:
> > great. But what is the gain for the hypervisor in *not* sending the
> > EVICT_FAIL event. It's a good thing. It keeps the same interface to
> > user-space. Xenpaging may not need it, but the Xen paging code does not
> > exist solely for xenpaging.
> 
> What IS the need to send yet another request? It adds just overhead for
> no obvious need. Please show the code that will benefit from the extra
> EVICT_FAIL message.

While in general it's good to keep backward compatibility, I don't think
this interface has ever had a stable, usable release (that didn't
involve the consumer at least carrying hypervisor patches of their own)
so I think it's OK to make fairly large changes in it. 

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 13:00:04 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 13: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.xensource.com>)
	id 1RYH6I-0003Zp-5J; Wed, 07 Dec 2011 12:59:54 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1RYH6H-0003Yg-1X
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 12:59:53 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1323262744!6241655!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDczNzc=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22156 invoked from network); 7 Dec 2011 12:59:06 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Dec 2011 12:59:06 -0000
X-IronPort-AV: E=Sophos;i="4.71,313,1320642000"; d="scan'208";a="19744300"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Dec 2011 07:59:04 -0500
Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX02.citrite.net
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Wed, 7 Dec 2011
	07:59:04 -0500
Message-ID: <4EDF6317.8010502@citrix.com>
Date: Wed, 7 Dec 2011 12:59:03 +0000
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20111110 Icedove/3.0.11
MIME-Version: 1.0
To: <stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1112061753410.31179@kaball-desktop>
	<1323195609-17277-8-git-send-email-stefano.stabellini@eu.citrix.com>
In-Reply-To: <1323195609-17277-8-git-send-email-stefano.stabellini@eu.citrix.com>
Cc: xen-devel@lists.xensource.com, Ian Campbell <ian.campbell@citrix.com>,
	Tim.Deegan@citrix.com
Subject: Re: [Xen-devel] [PATCH RFC 08/25] arm: makefiles
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 06/12/11 18:19, stefano.stabellini@eu.citrix.com wrote:
> From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> 
> Makefile and config options for the ARM architecture.

Should be the last patch so bisects don't break unnecessarily?  Although
its added a new arch so perhaps that's not an issue?

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 13:00:04 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 13: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.xensource.com>)
	id 1RYH6I-0003Zp-5J; Wed, 07 Dec 2011 12:59:54 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1RYH6H-0003Yg-1X
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 12:59:53 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1323262744!6241655!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDczNzc=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22156 invoked from network); 7 Dec 2011 12:59:06 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Dec 2011 12:59:06 -0000
X-IronPort-AV: E=Sophos;i="4.71,313,1320642000"; d="scan'208";a="19744300"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Dec 2011 07:59:04 -0500
Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX02.citrite.net
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Wed, 7 Dec 2011
	07:59:04 -0500
Message-ID: <4EDF6317.8010502@citrix.com>
Date: Wed, 7 Dec 2011 12:59:03 +0000
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20111110 Icedove/3.0.11
MIME-Version: 1.0
To: <stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1112061753410.31179@kaball-desktop>
	<1323195609-17277-8-git-send-email-stefano.stabellini@eu.citrix.com>
In-Reply-To: <1323195609-17277-8-git-send-email-stefano.stabellini@eu.citrix.com>
Cc: xen-devel@lists.xensource.com, Ian Campbell <ian.campbell@citrix.com>,
	Tim.Deegan@citrix.com
Subject: Re: [Xen-devel] [PATCH RFC 08/25] arm: makefiles
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 06/12/11 18:19, stefano.stabellini@eu.citrix.com wrote:
> From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> 
> Makefile and config options for the ARM architecture.

Should be the last patch so bisects don't break unnecessarily?  Although
its added a new arch so perhaps that's not an issue?

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 13:05:04 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 13:05:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYHB1-0004Cm-RI; Wed, 07 Dec 2011 13:04:47 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RYHB0-0004CF-Aj
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 13:04:46 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1323262991!59796875!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjA3NQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32382 invoked from network); 7 Dec 2011 13:03:12 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Dec 2011 13:03:12 -0000
X-IronPort-AV: E=Sophos;i="4.71,313,1320624000"; 
   d="scan'208";a="9341936"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Dec 2011 13:04:01 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 7 Dec 2011
	13:04:01 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
Date: Wed, 7 Dec 2011 13:04:00 +0000
In-Reply-To: <4EDF6317.8010502@citrix.com>
References: <alpine.DEB.2.00.1112061753410.31179@kaball-desktop>
	<1323195609-17277-8-git-send-email-stefano.stabellini@eu.citrix.com>
	<4EDF6317.8010502@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323263041.23681.176.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Tim Deegan \(3P\)" <Tim.Deegan@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH RFC 08/25] arm: makefiles
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2011-12-07 at 12:59 +0000, David Vrabel wrote:
> On 06/12/11 18:19, stefano.stabellini@eu.citrix.com wrote:
> > From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > 
> > Makefile and config options for the ARM architecture.
> 
> Should be the last patch so bisects don't break unnecessarily?  Although
> its added a new arch so perhaps that's not an issue?

We decided there was no point for a new arch since there would be no
working baseline until after the whole series anyway.

That said putting the Makefiles last is pretty trivial...

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 13:05:04 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 13:05:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYHB1-0004Cm-RI; Wed, 07 Dec 2011 13:04:47 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RYHB0-0004CF-Aj
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 13:04:46 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1323262991!59796875!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjA3NQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32382 invoked from network); 7 Dec 2011 13:03:12 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Dec 2011 13:03:12 -0000
X-IronPort-AV: E=Sophos;i="4.71,313,1320624000"; 
   d="scan'208";a="9341936"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Dec 2011 13:04:01 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 7 Dec 2011
	13:04:01 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
Date: Wed, 7 Dec 2011 13:04:00 +0000
In-Reply-To: <4EDF6317.8010502@citrix.com>
References: <alpine.DEB.2.00.1112061753410.31179@kaball-desktop>
	<1323195609-17277-8-git-send-email-stefano.stabellini@eu.citrix.com>
	<4EDF6317.8010502@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323263041.23681.176.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Tim Deegan \(3P\)" <Tim.Deegan@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH RFC 08/25] arm: makefiles
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2011-12-07 at 12:59 +0000, David Vrabel wrote:
> On 06/12/11 18:19, stefano.stabellini@eu.citrix.com wrote:
> > From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > 
> > Makefile and config options for the ARM architecture.
> 
> Should be the last patch so bisects don't break unnecessarily?  Although
> its added a new arch so perhaps that's not an issue?

We decided there was no point for a new arch since there would be no
working baseline until after the whole series anyway.

That said putting the Makefiles last is pretty trivial...

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 13:07:47 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 13:07:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYHDj-0004T1-Dh; Wed, 07 Dec 2011 13:07:35 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RYHDh-0004SU-8a
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 13:07:33 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-14.tower-21.messagelabs.com!1323263205!7316517!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNDE0ODA=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNDE0ODA=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10688 invoked from network); 7 Dec 2011 13:06:46 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-14.tower-21.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 7 Dec 2011 13:06:46 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1323263204; l=461;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=FIOyHXrSOrUbce3SWM0H7ZGYZPk=;
	b=T4Kuo+hOA0JvBj55BkDBb4hm2RN+LPNM0a3461PsjL+mo6yAlxncMPcbP0GGREE3/Ny
	jUBELMcrCGmQ1lKujbLBpgEQwUZzptQTOe5fw6DeduC4DCSVHNE7XQz4idzISOCdxqpHL
	jwEn+M8jBw+es0yEYJA9UZeN9rFqk7uzOAs=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/ll3s7qGpVx
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-087-188.pools.arcor-ip.net [84.57.87.188])
	by smtp.strato.de (klopstock mo9) (RZmta 26.10 AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id m05d01nB7Bkp5c ;
	Wed, 7 Dec 2011 14:05:38 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id D9E2418637; Wed,  7 Dec 2011 14:05:37 +0100 (CET)
Date: Wed, 7 Dec 2011 14:05:37 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Tim Deegan <tim@xen.org>
Message-ID: <20111207130537.GA27156@aepfle.de>
References: <mailman.3467.1323191271.12970.xen-devel@lists.xensource.com>
	<78bcef1bbb35c6176c138c1a6089f034.squirrel@webmail.lagarcavilla.org>
	<20111207092737.GA24563@aepfle.de>
	<20111207125805.GG31448@ocelot.phlegethon.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20111207125805.GG31448@ocelot.phlegethon.org>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: xen-devel@lists.xensource.com,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>
Subject: Re: [Xen-devel] [PATCH 2 of 5] xenpaging: map gfn before nomination
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Dec 07, Tim Deegan wrote:

> While in general it's good to keep backward compatibility, I don't think
> this interface has ever had a stable, usable release (that didn't
> involve the consumer at least carrying hypervisor patches of their own)
> so I think it's OK to make fairly large changes in it. 

Yes, that what I forgot to mention. 4.0 worked somehow, 4.1 was
unfortunately broken.
Hopefully everything will be ready by 4.2-rc1.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 13:07:47 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 13:07:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYHDj-0004T1-Dh; Wed, 07 Dec 2011 13:07:35 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RYHDh-0004SU-8a
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 13:07:33 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-14.tower-21.messagelabs.com!1323263205!7316517!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNDE0ODA=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNDE0ODA=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10688 invoked from network); 7 Dec 2011 13:06:46 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-14.tower-21.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 7 Dec 2011 13:06:46 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1323263204; l=461;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=FIOyHXrSOrUbce3SWM0H7ZGYZPk=;
	b=T4Kuo+hOA0JvBj55BkDBb4hm2RN+LPNM0a3461PsjL+mo6yAlxncMPcbP0GGREE3/Ny
	jUBELMcrCGmQ1lKujbLBpgEQwUZzptQTOe5fw6DeduC4DCSVHNE7XQz4idzISOCdxqpHL
	jwEn+M8jBw+es0yEYJA9UZeN9rFqk7uzOAs=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/ll3s7qGpVx
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-087-188.pools.arcor-ip.net [84.57.87.188])
	by smtp.strato.de (klopstock mo9) (RZmta 26.10 AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id m05d01nB7Bkp5c ;
	Wed, 7 Dec 2011 14:05:38 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id D9E2418637; Wed,  7 Dec 2011 14:05:37 +0100 (CET)
Date: Wed, 7 Dec 2011 14:05:37 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Tim Deegan <tim@xen.org>
Message-ID: <20111207130537.GA27156@aepfle.de>
References: <mailman.3467.1323191271.12970.xen-devel@lists.xensource.com>
	<78bcef1bbb35c6176c138c1a6089f034.squirrel@webmail.lagarcavilla.org>
	<20111207092737.GA24563@aepfle.de>
	<20111207125805.GG31448@ocelot.phlegethon.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20111207125805.GG31448@ocelot.phlegethon.org>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: xen-devel@lists.xensource.com,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>
Subject: Re: [Xen-devel] [PATCH 2 of 5] xenpaging: map gfn before nomination
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Dec 07, Tim Deegan wrote:

> While in general it's good to keep backward compatibility, I don't think
> this interface has ever had a stable, usable release (that didn't
> involve the consumer at least carrying hypervisor patches of their own)
> so I think it's OK to make fairly large changes in it. 

Yes, that what I forgot to mention. 4.0 worked somehow, 4.1 was
unfortunately broken.
Hopefully everything will be ready by 4.2-rc1.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 13:18:58 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 13:18:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYHOZ-0004y1-By; Wed, 07 Dec 2011 13:18:47 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RYHOY-0004xK-0S
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 13:18:46 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-11.tower-182.messagelabs.com!1323263878!6244910!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMzEwMTc=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMzEwMTc=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29076 invoked from network); 7 Dec 2011 13:17:59 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-11.tower-182.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 7 Dec 2011 13:17:59 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1323263878; l=444;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=9AiO9EuynR3h+XmgqKynxZOh7ao=;
	b=kpQVPlQy0H3G1zi6zlSnRmYJy9OM6fbAr5G8ZuCVFloqDaMl2jqbEyAnIHJI94+8BfC
	j/T7ij+lnVZvFF2gMPO/5as1wqXwN2qNIsK/rxhIXsmRSB2qVJrA4hEaVc+vwu8FIrFIi
	T3A+zoaUU1TceQPwQaaWmBFQBBOjnvgGAQA=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/ll3s7qGpVx
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-087-188.pools.arcor-ip.net [84.57.87.188])
	by smtp.strato.de (fruni mo52) (RZmta 26.10 AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id B07275nB7ChVmC ;
	Wed, 7 Dec 2011 14:17:54 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 907CD18637; Wed,  7 Dec 2011 14:17:53 +0100 (CET)
Date: Wed, 7 Dec 2011 14:17:53 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20111207131753.GA27309@aepfle.de>
References: <patchbomb.1323098647@xdev.gridcentric.ca>
	<20111206172605.GA18176@aepfle.de>
	<d33d99829ec12990334e271eeb36b06c.squirrel@webmail.lagarcavilla.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <d33d99829ec12990334e271eeb36b06c.squirrel@webmail.lagarcavilla.org>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com, tim@xen.org,
	keir.xen@gmail.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 0 of 2] Mem event ring management overhaul
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Dec 06, Andres Lagar-Cavilla wrote:

> If the request comes from the guest itself, and it requires
> paging_populate (!= p2m_query), the event is guaranteed to be put in the
> ring, and then the vcpu goes to sleep.
> 
> Easy-peasy

If everything were so easy. ;-)

I will try to combine your patch with my paging waitqueue change.
Perhaps your change should disallow paging if max_cpus is larger than
RING_SIZE().


Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 13:18:58 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 13:18:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYHOZ-0004y1-By; Wed, 07 Dec 2011 13:18:47 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RYHOY-0004xK-0S
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 13:18:46 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-11.tower-182.messagelabs.com!1323263878!6244910!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMzEwMTc=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMzEwMTc=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29076 invoked from network); 7 Dec 2011 13:17:59 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-11.tower-182.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 7 Dec 2011 13:17:59 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1323263878; l=444;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=9AiO9EuynR3h+XmgqKynxZOh7ao=;
	b=kpQVPlQy0H3G1zi6zlSnRmYJy9OM6fbAr5G8ZuCVFloqDaMl2jqbEyAnIHJI94+8BfC
	j/T7ij+lnVZvFF2gMPO/5as1wqXwN2qNIsK/rxhIXsmRSB2qVJrA4hEaVc+vwu8FIrFIi
	T3A+zoaUU1TceQPwQaaWmBFQBBOjnvgGAQA=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/ll3s7qGpVx
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-087-188.pools.arcor-ip.net [84.57.87.188])
	by smtp.strato.de (fruni mo52) (RZmta 26.10 AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id B07275nB7ChVmC ;
	Wed, 7 Dec 2011 14:17:54 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 907CD18637; Wed,  7 Dec 2011 14:17:53 +0100 (CET)
Date: Wed, 7 Dec 2011 14:17:53 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20111207131753.GA27309@aepfle.de>
References: <patchbomb.1323098647@xdev.gridcentric.ca>
	<20111206172605.GA18176@aepfle.de>
	<d33d99829ec12990334e271eeb36b06c.squirrel@webmail.lagarcavilla.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <d33d99829ec12990334e271eeb36b06c.squirrel@webmail.lagarcavilla.org>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com, tim@xen.org,
	keir.xen@gmail.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 0 of 2] Mem event ring management overhaul
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Dec 06, Andres Lagar-Cavilla wrote:

> If the request comes from the guest itself, and it requires
> paging_populate (!= p2m_query), the event is guaranteed to be put in the
> ring, and then the vcpu goes to sleep.
> 
> Easy-peasy

If everything were so easy. ;-)

I will try to combine your patch with my paging waitqueue change.
Perhaps your change should disallow paging if max_cpus is larger than
RING_SIZE().


Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 13:21:51 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 13: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.xensource.com>)
	id 1RYHRM-0005EL-0o; Wed, 07 Dec 2011 13:21:40 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RYHRJ-0005EB-Ol
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 13:21:38 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-6.tower-27.messagelabs.com!1323264018!49838278!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMzEwMTc=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMzEwMTc=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28774 invoked from network); 7 Dec 2011 13:20:19 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-6.tower-27.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 7 Dec 2011 13:20:19 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1323264055; l=1173;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=KbSDJgWYHqAnUPSOObv7dgXxLDE=;
	b=jatCrFS7o8JXloXKqWFp/v4L24wRTH+Z2kCNXHlMZ+1YE2iKw7UgRq1w9NjeImleV5T
	Z9mtNQje0CFYjnruK8zBBcETDpiVR1LI6lAXGCalet5rC43zTDiOfiOA0zj2OIpeyI1ax
	SjiNjAAIiJAX7H5H7kt/4BGGNTmdbG8DwK8=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/ll3s7qGpVx
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-087-188.pools.arcor-ip.net [84.57.87.188])
	by post.strato.de (mrclete mo39) (RZmta 26.10 AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id q026c9nB7COEYM ;
	Wed, 7 Dec 2011 14:20:45 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 2B20E18637; Wed,  7 Dec 2011 14:20:45 +0100 (CET)
Date: Wed, 7 Dec 2011 14:20:45 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20111207132044.GB27309@aepfle.de>
References: <mailman.3332.1323083995.12970.xen-devel@lists.xensource.com>
	<f5cf6ad4704fe70f3130b832e530e8b0.squirrel@webmail.lagarcavilla.org>
	<20111205162016.GA13352@aepfle.de>
	<c9d4c394e8c6806edd1b735a43d60ab7.squirrel@webmail.lagarcavilla.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <c9d4c394e8c6806edd1b735a43d60ab7.squirrel@webmail.lagarcavilla.org>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] mem_event: use wait queue when ring is full
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Dec 05, Andres Lagar-Cavilla wrote:

> > On Mon, Dec 05, Andres Lagar-Cavilla wrote:
> >
> >> > +    med->bit = bit;
> >> I think it's been asked before for this to have a more expressive name.
> >
> > I have to recheck, AFAIK it was the mem_bit where mem_ is redundant.
> how about pause_flag?

I made this change in my patch.

> > Before this patch, mem_event_unpause_vcpus() was used to resume waiters
> > for the ring itself and for room in the ring.
> > Now there is mem_event_wake_waiters(), which indicates the ring is
> > active, and there is mem_event_wake_requesters() which indicates the
> > ring has room to place guest requests.
> 
> I think that if there is no ring where one is expected, harsher actions
> should happen. That is what we do in our patch. e.g.
> p2m_mem_paging_populate -> no ring -> crash domain, or
> p2m_mem_access_check -> access_required -> no ring -> crash domain.
> 
> That would eliminate wake_waiters, methinks?

In p2m_mem_paging_populate() a sanity check could be added. I think it
would indicate bad p2mt state because nominate was called without ring.
How else can a gfn enter paging state?

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 13:21:51 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 13: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.xensource.com>)
	id 1RYHRM-0005EL-0o; Wed, 07 Dec 2011 13:21:40 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RYHRJ-0005EB-Ol
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 13:21:38 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-6.tower-27.messagelabs.com!1323264018!49838278!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMzEwMTc=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMzEwMTc=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28774 invoked from network); 7 Dec 2011 13:20:19 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-6.tower-27.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 7 Dec 2011 13:20:19 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1323264055; l=1173;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=KbSDJgWYHqAnUPSOObv7dgXxLDE=;
	b=jatCrFS7o8JXloXKqWFp/v4L24wRTH+Z2kCNXHlMZ+1YE2iKw7UgRq1w9NjeImleV5T
	Z9mtNQje0CFYjnruK8zBBcETDpiVR1LI6lAXGCalet5rC43zTDiOfiOA0zj2OIpeyI1ax
	SjiNjAAIiJAX7H5H7kt/4BGGNTmdbG8DwK8=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/ll3s7qGpVx
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-087-188.pools.arcor-ip.net [84.57.87.188])
	by post.strato.de (mrclete mo39) (RZmta 26.10 AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id q026c9nB7COEYM ;
	Wed, 7 Dec 2011 14:20:45 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 2B20E18637; Wed,  7 Dec 2011 14:20:45 +0100 (CET)
Date: Wed, 7 Dec 2011 14:20:45 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20111207132044.GB27309@aepfle.de>
References: <mailman.3332.1323083995.12970.xen-devel@lists.xensource.com>
	<f5cf6ad4704fe70f3130b832e530e8b0.squirrel@webmail.lagarcavilla.org>
	<20111205162016.GA13352@aepfle.de>
	<c9d4c394e8c6806edd1b735a43d60ab7.squirrel@webmail.lagarcavilla.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <c9d4c394e8c6806edd1b735a43d60ab7.squirrel@webmail.lagarcavilla.org>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] mem_event: use wait queue when ring is full
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Dec 05, Andres Lagar-Cavilla wrote:

> > On Mon, Dec 05, Andres Lagar-Cavilla wrote:
> >
> >> > +    med->bit = bit;
> >> I think it's been asked before for this to have a more expressive name.
> >
> > I have to recheck, AFAIK it was the mem_bit where mem_ is redundant.
> how about pause_flag?

I made this change in my patch.

> > Before this patch, mem_event_unpause_vcpus() was used to resume waiters
> > for the ring itself and for room in the ring.
> > Now there is mem_event_wake_waiters(), which indicates the ring is
> > active, and there is mem_event_wake_requesters() which indicates the
> > ring has room to place guest requests.
> 
> I think that if there is no ring where one is expected, harsher actions
> should happen. That is what we do in our patch. e.g.
> p2m_mem_paging_populate -> no ring -> crash domain, or
> p2m_mem_access_check -> access_required -> no ring -> crash domain.
> 
> That would eliminate wake_waiters, methinks?

In p2m_mem_paging_populate() a sanity check could be added. I think it
would indicate bad p2mt state because nominate was called without ring.
How else can a gfn enter paging state?

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 13:52:23 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 13: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.xensource.com>)
	id 1RYHud-0005lD-Lc; Wed, 07 Dec 2011 13:51:55 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RYHuc-0005l8-3y
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 13:51:54 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1323265757!55219297!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjA3NQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8927 invoked from network); 7 Dec 2011 13:49:18 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Dec 2011 13:49:18 -0000
X-IronPort-AV: E=Sophos;i="4.71,313,1320624000"; 
   d="scan'208";a="9343265"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Dec 2011 13:51:04 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 7 Dec 2011
	13:51:04 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Wed, 7 Dec 2011 13:51:04 +0000
In-Reply-To: <1323108621-22654-3-git-send-email-ian.jackson@eu.citrix.com>
References: <1323108621-22654-1-git-send-email-ian.jackson@eu.citrix.com>
	<1323108621-22654-3-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323265864.23681.180.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 02/15] libxenstore: Provide xs_check_watch
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2011-12-05 at 18:10 +0000, Ian Jackson wrote:
> Event-driven programs want to wait until the xs_fileno triggers for
> reading, and then repeatedly call xs_check_watch.
> 
> Also xs_read_watch exposes a useless "num" out parameter, which should
> always (if things aren't going hideously wrong) be at least 2 and
> which the caller shouldn't be interested in.  So xs_check_watch
> doesn't have one of those.
> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

Are we supposed to do something to the SONAME with this kind of change?
If not then:

Acked-by: Ian Campbell <ian.campbell@citrix.com>

---
>  tools/xenstore/xs.c |   89 ++++++++++++++++++++++++++++++++++++++++++++-------
>  tools/xenstore/xs.h |   16 +++++++++
>  2 files changed, 93 insertions(+), 12 deletions(-)
> 
> diff --git a/tools/xenstore/xs.c b/tools/xenstore/xs.c
> index df270f7..8e54fe0 100644
> --- a/tools/xenstore/xs.c
> +++ b/tools/xenstore/xs.c
> @@ -132,7 +132,23 @@ struct xs_handle {
>  
>  #endif
>  
> -static int read_message(struct xs_handle *h);
> +static int read_message(struct xs_handle *h, int nonblocking);
> +
> +static void setnonblock(int fd, int nonblock) {
> +	int esave = errno;
> +	int flags = fcntl(fd, F_GETFL);
> +	if (flags == -1)
> +		goto out;
> +
> +	if (nonblock)
> +		flags |= O_NONBLOCK;
> +	else
> +		flags &= ~O_NONBLOCK;
> +
> +	fcntl(fd, F_SETFL, flags);
> +out:
> +	errno = esave;
> +}
>  
>  int xs_fileno(struct xs_handle *h)
>  {
> @@ -325,8 +341,16 @@ void xs_close(struct xs_handle* xsh)
>  		xs_daemon_close(xsh);
>  }
>  
> -static bool read_all(int fd, void *data, unsigned int len)
> +static bool read_all(int fd, void *data, unsigned int len, int nonblocking)
> +	/* With nonblocking, either reads either everything requested,
> +	 * or nothing. */
>  {
> +	if (!len)
> +		return true;
> +
> +	if (nonblocking)
> +		setnonblock(fd, 1);
> +
>  	while (len) {
>  		int done;
>  
> @@ -334,18 +358,28 @@ static bool read_all(int fd, void *data, unsigned int len)
>  		if (done < 0) {
>  			if (errno == EINTR)
>  				continue;
> -			return false;
> +			goto out_false;
>  		}
>  		if (done == 0) {
>  			/* It closed fd on us?  EBADF is appropriate. */
>  			errno = EBADF;
> -			return false;
> +			goto out_false;
>  		}
>  		data += done;
>  		len -= done;
> +
> +		if (nonblocking) {
> +			setnonblock(fd, 0);
> +			nonblocking = 0;
> +		}
>  	}
>  
>  	return true;
> +
> +out_false:
> +	if (nonblocking)
> +		setnonblock(fd, 0);
> +	return false;
>  }
>  
>  #ifdef XSTEST
> @@ -374,7 +408,7 @@ static void *read_reply(
>  	read_from_thread = read_thread_exists(h);
>  
>  	/* Read from comms channel ourselves if there is no reader thread. */
> -	if (!read_from_thread && (read_message(h) == -1))
> +	if (!read_from_thread && (read_message(h, 0) == -1))
>  		return NULL;
>  
>  	mutex_lock(&h->reply_mutex);
> @@ -693,7 +727,8 @@ bool xs_watch(struct xs_handle *h, const char *path, const char *token)
>   * Returns array of two pointers: path and token, or NULL.
>   * Call free() after use.
>   */
> -char **xs_read_watch(struct xs_handle *h, unsigned int *num)
> +static char **read_watch_internal(struct xs_handle *h, unsigned int *num,
> +				  int nonblocking)
>  {
>  	struct xs_stored_msg *msg;
>  	char **ret, *strings, c = 0;
> @@ -707,14 +742,20 @@ char **xs_read_watch(struct xs_handle *h, unsigned int *num)
>  	 * we haven't called xs_watch.	Presumably the application
>  	 * will do so later; in the meantime we just block.
>  	 */
> -	while (list_empty(&h->watch_list) && h->fd != -1)
> +	while (list_empty(&h->watch_list) && h->fd != -1) {
> +		if (nonblocking) {
> +			mutex_unlock(&h->watch_mutex);
> +			errno = EAGAIN;
> +			return 0;
> +		}
>  		condvar_wait(&h->watch_condvar, &h->watch_mutex);
> +	}
>  #else /* !defined(USE_PTHREAD) */
>  	/* Read from comms channel ourselves if there are no threads
>  	 * and therefore no reader thread. */
>  
>  	assert(!read_thread_exists(h)); /* not threadsafe but worth a check */
> -	if ((read_message(h) == -1))
> +	if ((read_message(h, nonblocking) == -1))
>  		return NULL;
>  
>  #endif /* !defined(USE_PTHREAD) */
> @@ -760,6 +801,24 @@ char **xs_read_watch(struct xs_handle *h, unsigned int *num)
>  	return ret;
>  }
>  
> +char **xs_check_watch(struct xs_handle *h)
> +{
> +	unsigned int num;
> +	char **ret;
> +	ret = read_watch_internal(h, &num, 1);
> +	if (ret) assert(num >= 2);
> +	return ret;
> +}
> +
> +/* Find out what node change was on (will block if nothing pending).
> + * Returns array of two pointers: path and token, or NULL.
> + * Call free() after use.
> + */
> +char **xs_read_watch(struct xs_handle *h, unsigned int *num)
> +{
> +	return read_watch_internal(h, num, 0);
> +}
> +
>  /* Remove a watch on a node.
>   * Returns false on failure (no watch on that node).
>   */
> @@ -940,11 +999,17 @@ char *xs_debug_command(struct xs_handle *h, const char *cmd,
>  			ARRAY_SIZE(iov), NULL);
>  }
>  
> -static int read_message(struct xs_handle *h)
> +static int read_message(struct xs_handle *h, int nonblocking)
>  {
>  	/* IMPORTANT: It is forbidden to call this function without
>  	 * acquiring the request lock and checking that h->read_thr_exists
>  	 * is false.  See "Lock discipline" in struct xs_handle, above. */
> +
> +	/* If nonblocking==1, this function will always read either
> +	 * nothing, returning -1 and setting errno==EAGAIN, or we read
> +	 * whole amount requested.  Ie as soon as we have the start of
> +	 * the message we block until we get all of it.
> +	 */
>           
>  	struct xs_stored_msg *msg = NULL;
>  	char *body = NULL;
> @@ -956,7 +1021,7 @@ static int read_message(struct xs_handle *h)
>  	if (msg == NULL)
>  		goto error;
>  	cleanup_push(free, msg);
> -	if (!read_all(h->fd, &msg->hdr, sizeof(msg->hdr))) { /* Cancellation point */
> +	if (!read_all(h->fd, &msg->hdr, sizeof(msg->hdr), nonblocking)) { /* Cancellation point */
>  		saved_errno = errno;
>  		goto error_freemsg;
>  	}
> @@ -966,7 +1031,7 @@ static int read_message(struct xs_handle *h)
>  	if (body == NULL)
>  		goto error_freemsg;
>  	cleanup_push(free, body);
> -	if (!read_all(h->fd, body, msg->hdr.len)) { /* Cancellation point */
> +	if (!read_all(h->fd, body, msg->hdr.len, 0)) { /* Cancellation point */
>  		saved_errno = errno;
>  		goto error_freebody;
>  	}
> @@ -1021,7 +1086,7 @@ static void *read_thread(void *arg)
>  	struct xs_handle *h = arg;
>  	int fd;
>  
> -	while (read_message(h) != -1)
> +	while (read_message(h, 0) != -1)
>  		continue;
>  
>  	/* An error return from read_message leaves the socket in an undefined
> diff --git a/tools/xenstore/xs.h b/tools/xenstore/xs.h
> index 1cbe255..63f535d 100644
> --- a/tools/xenstore/xs.h
> +++ b/tools/xenstore/xs.h
> @@ -135,6 +135,22 @@ bool xs_watch(struct xs_handle *h, const char *path, const char *token);
>  /* Return the FD to poll on to see if a watch has fired. */
>  int xs_fileno(struct xs_handle *h);
>  
> +/* Check for node changes.  On success, returns a non-NULL pointer ret
> + * such that ret[0] and ret[1] are valid C strings, namely the
> + * triggering path (see docs/misc/xenstore.txt) and the token (from
> + * xs_watch).  On error return value is NULL setting errno.
> + * 
> + * Callers should, after xs_fileno has become readable, repeatedly
> + * call xs_check_watch until it returns NULL and sets errno to EAGAIN.
> + * (If the fd became readable, xs_check_watch is allowed to make it no
> + * longer show up as readable even if future calls to xs_check_watch
> + * will return more watch events.)
> + *
> + * After the caller is finished with the returned information it
> + * should be freed all in one go with free(ret).
> + */
> +char **xs_check_watch(struct xs_handle *h);
> +
>  /* Find out what node change was on (will block if nothing pending).
>   * Returns array containing the path and token. Use XS_WATCH_* to access these
>   * elements. Call free() after use.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 13:52:23 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 13: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.xensource.com>)
	id 1RYHud-0005lD-Lc; Wed, 07 Dec 2011 13:51:55 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RYHuc-0005l8-3y
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 13:51:54 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1323265757!55219297!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjA3NQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8927 invoked from network); 7 Dec 2011 13:49:18 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Dec 2011 13:49:18 -0000
X-IronPort-AV: E=Sophos;i="4.71,313,1320624000"; 
   d="scan'208";a="9343265"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Dec 2011 13:51:04 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 7 Dec 2011
	13:51:04 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Wed, 7 Dec 2011 13:51:04 +0000
In-Reply-To: <1323108621-22654-3-git-send-email-ian.jackson@eu.citrix.com>
References: <1323108621-22654-1-git-send-email-ian.jackson@eu.citrix.com>
	<1323108621-22654-3-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323265864.23681.180.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 02/15] libxenstore: Provide xs_check_watch
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2011-12-05 at 18:10 +0000, Ian Jackson wrote:
> Event-driven programs want to wait until the xs_fileno triggers for
> reading, and then repeatedly call xs_check_watch.
> 
> Also xs_read_watch exposes a useless "num" out parameter, which should
> always (if things aren't going hideously wrong) be at least 2 and
> which the caller shouldn't be interested in.  So xs_check_watch
> doesn't have one of those.
> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

Are we supposed to do something to the SONAME with this kind of change?
If not then:

Acked-by: Ian Campbell <ian.campbell@citrix.com>

---
>  tools/xenstore/xs.c |   89 ++++++++++++++++++++++++++++++++++++++++++++-------
>  tools/xenstore/xs.h |   16 +++++++++
>  2 files changed, 93 insertions(+), 12 deletions(-)
> 
> diff --git a/tools/xenstore/xs.c b/tools/xenstore/xs.c
> index df270f7..8e54fe0 100644
> --- a/tools/xenstore/xs.c
> +++ b/tools/xenstore/xs.c
> @@ -132,7 +132,23 @@ struct xs_handle {
>  
>  #endif
>  
> -static int read_message(struct xs_handle *h);
> +static int read_message(struct xs_handle *h, int nonblocking);
> +
> +static void setnonblock(int fd, int nonblock) {
> +	int esave = errno;
> +	int flags = fcntl(fd, F_GETFL);
> +	if (flags == -1)
> +		goto out;
> +
> +	if (nonblock)
> +		flags |= O_NONBLOCK;
> +	else
> +		flags &= ~O_NONBLOCK;
> +
> +	fcntl(fd, F_SETFL, flags);
> +out:
> +	errno = esave;
> +}
>  
>  int xs_fileno(struct xs_handle *h)
>  {
> @@ -325,8 +341,16 @@ void xs_close(struct xs_handle* xsh)
>  		xs_daemon_close(xsh);
>  }
>  
> -static bool read_all(int fd, void *data, unsigned int len)
> +static bool read_all(int fd, void *data, unsigned int len, int nonblocking)
> +	/* With nonblocking, either reads either everything requested,
> +	 * or nothing. */
>  {
> +	if (!len)
> +		return true;
> +
> +	if (nonblocking)
> +		setnonblock(fd, 1);
> +
>  	while (len) {
>  		int done;
>  
> @@ -334,18 +358,28 @@ static bool read_all(int fd, void *data, unsigned int len)
>  		if (done < 0) {
>  			if (errno == EINTR)
>  				continue;
> -			return false;
> +			goto out_false;
>  		}
>  		if (done == 0) {
>  			/* It closed fd on us?  EBADF is appropriate. */
>  			errno = EBADF;
> -			return false;
> +			goto out_false;
>  		}
>  		data += done;
>  		len -= done;
> +
> +		if (nonblocking) {
> +			setnonblock(fd, 0);
> +			nonblocking = 0;
> +		}
>  	}
>  
>  	return true;
> +
> +out_false:
> +	if (nonblocking)
> +		setnonblock(fd, 0);
> +	return false;
>  }
>  
>  #ifdef XSTEST
> @@ -374,7 +408,7 @@ static void *read_reply(
>  	read_from_thread = read_thread_exists(h);
>  
>  	/* Read from comms channel ourselves if there is no reader thread. */
> -	if (!read_from_thread && (read_message(h) == -1))
> +	if (!read_from_thread && (read_message(h, 0) == -1))
>  		return NULL;
>  
>  	mutex_lock(&h->reply_mutex);
> @@ -693,7 +727,8 @@ bool xs_watch(struct xs_handle *h, const char *path, const char *token)
>   * Returns array of two pointers: path and token, or NULL.
>   * Call free() after use.
>   */
> -char **xs_read_watch(struct xs_handle *h, unsigned int *num)
> +static char **read_watch_internal(struct xs_handle *h, unsigned int *num,
> +				  int nonblocking)
>  {
>  	struct xs_stored_msg *msg;
>  	char **ret, *strings, c = 0;
> @@ -707,14 +742,20 @@ char **xs_read_watch(struct xs_handle *h, unsigned int *num)
>  	 * we haven't called xs_watch.	Presumably the application
>  	 * will do so later; in the meantime we just block.
>  	 */
> -	while (list_empty(&h->watch_list) && h->fd != -1)
> +	while (list_empty(&h->watch_list) && h->fd != -1) {
> +		if (nonblocking) {
> +			mutex_unlock(&h->watch_mutex);
> +			errno = EAGAIN;
> +			return 0;
> +		}
>  		condvar_wait(&h->watch_condvar, &h->watch_mutex);
> +	}
>  #else /* !defined(USE_PTHREAD) */
>  	/* Read from comms channel ourselves if there are no threads
>  	 * and therefore no reader thread. */
>  
>  	assert(!read_thread_exists(h)); /* not threadsafe but worth a check */
> -	if ((read_message(h) == -1))
> +	if ((read_message(h, nonblocking) == -1))
>  		return NULL;
>  
>  #endif /* !defined(USE_PTHREAD) */
> @@ -760,6 +801,24 @@ char **xs_read_watch(struct xs_handle *h, unsigned int *num)
>  	return ret;
>  }
>  
> +char **xs_check_watch(struct xs_handle *h)
> +{
> +	unsigned int num;
> +	char **ret;
> +	ret = read_watch_internal(h, &num, 1);
> +	if (ret) assert(num >= 2);
> +	return ret;
> +}
> +
> +/* Find out what node change was on (will block if nothing pending).
> + * Returns array of two pointers: path and token, or NULL.
> + * Call free() after use.
> + */
> +char **xs_read_watch(struct xs_handle *h, unsigned int *num)
> +{
> +	return read_watch_internal(h, num, 0);
> +}
> +
>  /* Remove a watch on a node.
>   * Returns false on failure (no watch on that node).
>   */
> @@ -940,11 +999,17 @@ char *xs_debug_command(struct xs_handle *h, const char *cmd,
>  			ARRAY_SIZE(iov), NULL);
>  }
>  
> -static int read_message(struct xs_handle *h)
> +static int read_message(struct xs_handle *h, int nonblocking)
>  {
>  	/* IMPORTANT: It is forbidden to call this function without
>  	 * acquiring the request lock and checking that h->read_thr_exists
>  	 * is false.  See "Lock discipline" in struct xs_handle, above. */
> +
> +	/* If nonblocking==1, this function will always read either
> +	 * nothing, returning -1 and setting errno==EAGAIN, or we read
> +	 * whole amount requested.  Ie as soon as we have the start of
> +	 * the message we block until we get all of it.
> +	 */
>           
>  	struct xs_stored_msg *msg = NULL;
>  	char *body = NULL;
> @@ -956,7 +1021,7 @@ static int read_message(struct xs_handle *h)
>  	if (msg == NULL)
>  		goto error;
>  	cleanup_push(free, msg);
> -	if (!read_all(h->fd, &msg->hdr, sizeof(msg->hdr))) { /* Cancellation point */
> +	if (!read_all(h->fd, &msg->hdr, sizeof(msg->hdr), nonblocking)) { /* Cancellation point */
>  		saved_errno = errno;
>  		goto error_freemsg;
>  	}
> @@ -966,7 +1031,7 @@ static int read_message(struct xs_handle *h)
>  	if (body == NULL)
>  		goto error_freemsg;
>  	cleanup_push(free, body);
> -	if (!read_all(h->fd, body, msg->hdr.len)) { /* Cancellation point */
> +	if (!read_all(h->fd, body, msg->hdr.len, 0)) { /* Cancellation point */
>  		saved_errno = errno;
>  		goto error_freebody;
>  	}
> @@ -1021,7 +1086,7 @@ static void *read_thread(void *arg)
>  	struct xs_handle *h = arg;
>  	int fd;
>  
> -	while (read_message(h) != -1)
> +	while (read_message(h, 0) != -1)
>  		continue;
>  
>  	/* An error return from read_message leaves the socket in an undefined
> diff --git a/tools/xenstore/xs.h b/tools/xenstore/xs.h
> index 1cbe255..63f535d 100644
> --- a/tools/xenstore/xs.h
> +++ b/tools/xenstore/xs.h
> @@ -135,6 +135,22 @@ bool xs_watch(struct xs_handle *h, const char *path, const char *token);
>  /* Return the FD to poll on to see if a watch has fired. */
>  int xs_fileno(struct xs_handle *h);
>  
> +/* Check for node changes.  On success, returns a non-NULL pointer ret
> + * such that ret[0] and ret[1] are valid C strings, namely the
> + * triggering path (see docs/misc/xenstore.txt) and the token (from
> + * xs_watch).  On error return value is NULL setting errno.
> + * 
> + * Callers should, after xs_fileno has become readable, repeatedly
> + * call xs_check_watch until it returns NULL and sets errno to EAGAIN.
> + * (If the fd became readable, xs_check_watch is allowed to make it no
> + * longer show up as readable even if future calls to xs_check_watch
> + * will return more watch events.)
> + *
> + * After the caller is finished with the returned information it
> + * should be freed all in one go with free(ret).
> + */
> +char **xs_check_watch(struct xs_handle *h);
> +
>  /* Find out what node change was on (will block if nothing pending).
>   * Returns array containing the path and token. Use XS_WATCH_* to access these
>   * elements. Call free() after use.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 13:56:42 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 13:56:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYHyv-0005tF-CF; Wed, 07 Dec 2011 13:56:21 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RYHyu-0005t0-15
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 13:56:20 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1323266132!4613162!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjA3NQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9521 invoked from network); 7 Dec 2011 13:55:32 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Dec 2011 13:55:32 -0000
X-IronPort-AV: E=Sophos;i="4.71,313,1320624000"; 
   d="scan'208";a="9343364"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Dec 2011 13:55:32 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 7 Dec 2011
	13:55:32 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Wed, 7 Dec 2011 13:55:31 +0000
In-Reply-To: <1323108621-22654-5-git-send-email-ian.jackson@eu.citrix.com>
References: <1323108621-22654-1-git-send-email-ian.jackson@eu.citrix.com>
	<1323108621-22654-5-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323266132.23681.184.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 04/15] libxl: idl: support new "private"
 type attribute
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2011-12-05 at 18:10 +0000, Ian Jackson wrote:
> This provides for fields in libxl datatypes which are only present in
> the C version of structures and are used only by libxl itself.  This
> is useful when a libxl datatype wants to contain fields which are used
> by libxl internally and which are only present in the structure to
> avoid additional memory allocation inconvenience.
> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
iff you remove the stray print sys.stderr in the last hunk.

Ian.

> ---
>  tools/libxl/gentest.py    |    2 ++
>  tools/libxl/libxltypes.py |    4 +++-
>  tools/python/genwrap.py   |    7 +++++++
>  3 files changed, 12 insertions(+), 1 deletions(-)
> 
> diff --git a/tools/libxl/gentest.py b/tools/libxl/gentest.py
> index 05e77cc..ac7a400 100644
> --- a/tools/libxl/gentest.py
> +++ b/tools/libxl/gentest.py
> @@ -56,6 +56,8 @@ def gen_rand_init(ty, v, indent = "    ", parent = None):
>          s += "%s = rand() %% 2;\n" % v
>      elif ty.typename in ["char *"]:
>          s += "%s = rand_str();\n" % v
> +    elif ty.private:
> +        pass
>      elif ty.typename in handcoded:
>          raise Exception("Gen for handcoded %s" % ty.typename)
>      else:
> diff --git a/tools/libxl/libxltypes.py b/tools/libxl/libxltypes.py
> index 55056c2..450de88 100644
> --- a/tools/libxl/libxltypes.py
> +++ b/tools/libxl/libxltypes.py
> @@ -33,6 +33,8 @@ class Type(object):
>          if self.passby not in [PASS_BY_VALUE, PASS_BY_REFERENCE]:
>              raise ValueError
>  
> +        self.private = kwargs.setdefault('private', False)
> +
>          if typename is None: # Anonymous type
>              self.typename = None
>              self.rawname = None
> @@ -50,7 +52,7 @@ class Type(object):
>  
>          self.autogenerate_dispose_fn = kwargs.setdefault('autogenerate_dispose_fn', True)
>  
> -        if self.typename is not None:
> +        if self.typename is not None and not self.private:
>              self.json_fn = kwargs.setdefault('json_fn', self.typename + "_gen_json")
>          else:
>              self.json_fn = kwargs.setdefault('json_fn', None)
> diff --git a/tools/python/genwrap.py b/tools/python/genwrap.py
> index d0c193d..ecbec11 100644
> --- a/tools/python/genwrap.py
> +++ b/tools/python/genwrap.py
> @@ -129,6 +129,8 @@ static PyObject *Py%(rawname)s_new(PyTypeObject *type, PyObject *args, PyObject
>  
>      l.append('static PyGetSetDef Py%s_getset[] = {'%ty.rawname)
>      for f in ty.fields:
> +        if f.type.private:
> +            continue
>          l.append('    { .name = "%s", '%f.name)
>          if ty.marshal_out():
>              l.append('      .get = (getter)py_%s_%s_get, '%(ty.rawname, f.name))
> @@ -295,9 +297,14 @@ _hidden int genwrap__ll_set(PyObject *v, long long *val, long long mask);
>  
>  """ % tuple((' '.join(sys.argv),) + (os.path.split(decls)[-1:]),))
>      for ty in types:
> +        if ty.private:
> +            continue
>          if isinstance(ty, libxltypes.Aggregate):
>              f.write('/* Attribute get/set functions for %s */\n'%ty.typename)
>              for a in ty.fields:
> +                print >>sys.stderr, `a`, `ty`, `a.type`, `a.type.__dict__`
> +                if a.type.private:
> +                    continue
>                  if ty.marshal_out():
>                      f.write(py_attrib_get(ty,a))
>                  if ty.marshal_in():



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 13:56:42 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 13:56:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYHyv-0005tF-CF; Wed, 07 Dec 2011 13:56:21 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RYHyu-0005t0-15
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 13:56:20 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1323266132!4613162!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjA3NQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9521 invoked from network); 7 Dec 2011 13:55:32 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Dec 2011 13:55:32 -0000
X-IronPort-AV: E=Sophos;i="4.71,313,1320624000"; 
   d="scan'208";a="9343364"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Dec 2011 13:55:32 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 7 Dec 2011
	13:55:32 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Wed, 7 Dec 2011 13:55:31 +0000
In-Reply-To: <1323108621-22654-5-git-send-email-ian.jackson@eu.citrix.com>
References: <1323108621-22654-1-git-send-email-ian.jackson@eu.citrix.com>
	<1323108621-22654-5-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323266132.23681.184.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 04/15] libxl: idl: support new "private"
 type attribute
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2011-12-05 at 18:10 +0000, Ian Jackson wrote:
> This provides for fields in libxl datatypes which are only present in
> the C version of structures and are used only by libxl itself.  This
> is useful when a libxl datatype wants to contain fields which are used
> by libxl internally and which are only present in the structure to
> avoid additional memory allocation inconvenience.
> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
iff you remove the stray print sys.stderr in the last hunk.

Ian.

> ---
>  tools/libxl/gentest.py    |    2 ++
>  tools/libxl/libxltypes.py |    4 +++-
>  tools/python/genwrap.py   |    7 +++++++
>  3 files changed, 12 insertions(+), 1 deletions(-)
> 
> diff --git a/tools/libxl/gentest.py b/tools/libxl/gentest.py
> index 05e77cc..ac7a400 100644
> --- a/tools/libxl/gentest.py
> +++ b/tools/libxl/gentest.py
> @@ -56,6 +56,8 @@ def gen_rand_init(ty, v, indent = "    ", parent = None):
>          s += "%s = rand() %% 2;\n" % v
>      elif ty.typename in ["char *"]:
>          s += "%s = rand_str();\n" % v
> +    elif ty.private:
> +        pass
>      elif ty.typename in handcoded:
>          raise Exception("Gen for handcoded %s" % ty.typename)
>      else:
> diff --git a/tools/libxl/libxltypes.py b/tools/libxl/libxltypes.py
> index 55056c2..450de88 100644
> --- a/tools/libxl/libxltypes.py
> +++ b/tools/libxl/libxltypes.py
> @@ -33,6 +33,8 @@ class Type(object):
>          if self.passby not in [PASS_BY_VALUE, PASS_BY_REFERENCE]:
>              raise ValueError
>  
> +        self.private = kwargs.setdefault('private', False)
> +
>          if typename is None: # Anonymous type
>              self.typename = None
>              self.rawname = None
> @@ -50,7 +52,7 @@ class Type(object):
>  
>          self.autogenerate_dispose_fn = kwargs.setdefault('autogenerate_dispose_fn', True)
>  
> -        if self.typename is not None:
> +        if self.typename is not None and not self.private:
>              self.json_fn = kwargs.setdefault('json_fn', self.typename + "_gen_json")
>          else:
>              self.json_fn = kwargs.setdefault('json_fn', None)
> diff --git a/tools/python/genwrap.py b/tools/python/genwrap.py
> index d0c193d..ecbec11 100644
> --- a/tools/python/genwrap.py
> +++ b/tools/python/genwrap.py
> @@ -129,6 +129,8 @@ static PyObject *Py%(rawname)s_new(PyTypeObject *type, PyObject *args, PyObject
>  
>      l.append('static PyGetSetDef Py%s_getset[] = {'%ty.rawname)
>      for f in ty.fields:
> +        if f.type.private:
> +            continue
>          l.append('    { .name = "%s", '%f.name)
>          if ty.marshal_out():
>              l.append('      .get = (getter)py_%s_%s_get, '%(ty.rawname, f.name))
> @@ -295,9 +297,14 @@ _hidden int genwrap__ll_set(PyObject *v, long long *val, long long mask);
>  
>  """ % tuple((' '.join(sys.argv),) + (os.path.split(decls)[-1:]),))
>      for ty in types:
> +        if ty.private:
> +            continue
>          if isinstance(ty, libxltypes.Aggregate):
>              f.write('/* Attribute get/set functions for %s */\n'%ty.typename)
>              for a in ty.fields:
> +                print >>sys.stderr, `a`, `ty`, `a.type`, `a.type.__dict__`
> +                if a.type.private:
> +                    continue
>                  if ty.marshal_out():
>                      f.write(py_attrib_get(ty,a))
>                  if ty.marshal_in():



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 14:07:43 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 14: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.xensource.com>)
	id 1RYI9Q-0006Cd-Hw; Wed, 07 Dec 2011 14:07:12 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RYI9O-0006CY-O5
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 14:07:10 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1323266752!55748053!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM1ODk=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3572 invoked from network); 7 Dec 2011 14:05:53 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-9.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 7 Dec 2011 14:05:53 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 07 Dec 2011 14:06:25 +0000
Message-Id: <4EDF811C0200007800065FC3@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 07 Dec 2011 14:07:08 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Subject: [Xen-devel] [PATCH] linux-2.6.18/x86: refuse to initialize the
 microcode driver in DomU
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/arch/i386/kernel/microcode-xen.c
+++ b/arch/i386/kernel/microcode-xen.c
@@ -121,6 +121,9 @@ static int __init microcode_init (void)
 {
 	int error;
 
+	if (!is_initial_xendomain())
+		return -ENODEV;
+
 	error = misc_register(&microcode_dev);
 	if (error) {
 		printk(KERN_ERR




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 14:07:43 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 14: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.xensource.com>)
	id 1RYI9Q-0006Cd-Hw; Wed, 07 Dec 2011 14:07:12 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RYI9O-0006CY-O5
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 14:07:10 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1323266752!55748053!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM1ODk=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3572 invoked from network); 7 Dec 2011 14:05:53 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-9.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 7 Dec 2011 14:05:53 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 07 Dec 2011 14:06:25 +0000
Message-Id: <4EDF811C0200007800065FC3@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 07 Dec 2011 14:07:08 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Subject: [Xen-devel] [PATCH] linux-2.6.18/x86: refuse to initialize the
 microcode driver in DomU
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/arch/i386/kernel/microcode-xen.c
+++ b/arch/i386/kernel/microcode-xen.c
@@ -121,6 +121,9 @@ static int __init microcode_init (void)
 {
 	int error;
 
+	if (!is_initial_xendomain())
+		return -ENODEV;
+
 	error = misc_register(&microcode_dev);
 	if (error) {
 		printk(KERN_ERR




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 14:08:10 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 14:08:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYI9y-0006El-5W; Wed, 07 Dec 2011 14:07:46 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RYI9w-0006EM-SI
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 14:07:45 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1323266817!6487923!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjA3NQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32092 invoked from network); 7 Dec 2011 14:06:57 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Dec 2011 14:06:57 -0000
X-IronPort-AV: E=Sophos;i="4.71,313,1320624000"; 
   d="scan'208";a="9343636"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Dec 2011 14:06:56 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 7 Dec 2011
	14:06:56 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Wed, 7 Dec 2011 14:06:56 +0000
In-Reply-To: <1323108621-22654-7-git-send-email-ian.jackson@eu.citrix.com>
References: <1323108621-22654-1-git-send-email-ian.jackson@eu.citrix.com>
	<1323108621-22654-7-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323266816.23681.189.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 06/15] libxl: permit declaration after
 statement
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2011-12-05 at 18:10 +0000, Ian Jackson wrote:
> GCC and C99 allow declarations to be mixed with code.  This is a good
> idea because:
> 
>  * It allows variables to be more often initialised as they are
>    declared, thus reducing the occurrence of uninitialised variable
>    errors.
> 
>  * Certain alloca-like constructs (arrays allocated at runtime on the
>    stack) can more often be written without a spurious { } block.
>    Such blocks are confusing to read.
> 
>  * It makes it easier to write and use macros which declare and
>    initialise formulaic variables and do other function setup code,
>    because there is no need to worry that such macros might be
>    incompatible with each other or have strict ordering constraints.
> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

I'm happy with this so far as it goes but I was wondering where the
original -Wdeclaration-after-statement came from, do we actually mean
"-std=c99" or something along those lines?

Anyway I'm still ok with saying:
Acked-by: Ian Campbell <ian.campbell@citrix.com>

> ---
>  tools/libxl/Makefile |    3 ++-
>  1 files changed, 2 insertions(+), 1 deletions(-)
> 
> diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
> index f363da2..4e0f3fb 100644
> --- a/tools/libxl/Makefile
> +++ b/tools/libxl/Makefile
> @@ -11,7 +11,8 @@ MINOR = 0
>  XLUMAJOR = 1.0
>  XLUMINOR = 0
>  
> -CFLAGS += -Werror -Wno-format-zero-length -Wmissing-declarations
> +CFLAGS += -Werror -Wno-format-zero-length -Wmissing-declarations \
> +	-Wno-declaration-after-statement
>  CFLAGS += -I. -fPIC
>  
>  ifeq ($(CONFIG_Linux),y)



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 14:08:10 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 14:08:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYI9y-0006El-5W; Wed, 07 Dec 2011 14:07:46 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RYI9w-0006EM-SI
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 14:07:45 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1323266817!6487923!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjA3NQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32092 invoked from network); 7 Dec 2011 14:06:57 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Dec 2011 14:06:57 -0000
X-IronPort-AV: E=Sophos;i="4.71,313,1320624000"; 
   d="scan'208";a="9343636"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Dec 2011 14:06:56 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 7 Dec 2011
	14:06:56 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Wed, 7 Dec 2011 14:06:56 +0000
In-Reply-To: <1323108621-22654-7-git-send-email-ian.jackson@eu.citrix.com>
References: <1323108621-22654-1-git-send-email-ian.jackson@eu.citrix.com>
	<1323108621-22654-7-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323266816.23681.189.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 06/15] libxl: permit declaration after
 statement
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2011-12-05 at 18:10 +0000, Ian Jackson wrote:
> GCC and C99 allow declarations to be mixed with code.  This is a good
> idea because:
> 
>  * It allows variables to be more often initialised as they are
>    declared, thus reducing the occurrence of uninitialised variable
>    errors.
> 
>  * Certain alloca-like constructs (arrays allocated at runtime on the
>    stack) can more often be written without a spurious { } block.
>    Such blocks are confusing to read.
> 
>  * It makes it easier to write and use macros which declare and
>    initialise formulaic variables and do other function setup code,
>    because there is no need to worry that such macros might be
>    incompatible with each other or have strict ordering constraints.
> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

I'm happy with this so far as it goes but I was wondering where the
original -Wdeclaration-after-statement came from, do we actually mean
"-std=c99" or something along those lines?

Anyway I'm still ok with saying:
Acked-by: Ian Campbell <ian.campbell@citrix.com>

> ---
>  tools/libxl/Makefile |    3 ++-
>  1 files changed, 2 insertions(+), 1 deletions(-)
> 
> diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
> index f363da2..4e0f3fb 100644
> --- a/tools/libxl/Makefile
> +++ b/tools/libxl/Makefile
> @@ -11,7 +11,8 @@ MINOR = 0
>  XLUMAJOR = 1.0
>  XLUMINOR = 0
>  
> -CFLAGS += -Werror -Wno-format-zero-length -Wmissing-declarations
> +CFLAGS += -Werror -Wno-format-zero-length -Wmissing-declarations \
> +	-Wno-declaration-after-statement
>  CFLAGS += -I. -fPIC
>  
>  ifeq ($(CONFIG_Linux),y)



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 14:09:54 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 14:09:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYIBi-0006NU-O1; Wed, 07 Dec 2011 14:09:34 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RYIBh-0006NF-22
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 14:09:33 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1323266891!49847467!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM1ODk=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26819 invoked from network); 7 Dec 2011 14:08:11 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-6.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 7 Dec 2011 14:08:11 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 07 Dec 2011 14:08:47 +0000
Message-Id: <4EDF81AC0200007800065FD4@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 07 Dec 2011 14:09:32 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part06299A8C.0__="
Subject: [Xen-devel] [PATCH] linux-2.6.18/kexec: don't initialize when no
 crash area was reserved
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__Part06299A8C.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

While the waste of memory needed may not be significant, the amount of
additional but pointless entries in /proc/iomem certainly may be (on
large systems).

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/drivers/xen/core/machine_kexec.c
+++ b/drivers/xen/core/machine_kexec.c
@@ -34,6 +34,17 @@ void __init xen_machine_kexec_setup_reso
 	if (!is_initial_xendomain())
 		return;
=20
+	/* fill in crashk_res if range is reserved by hypervisor */
+	memset(&range, 0, sizeof(range));
+	range.range =3D KEXEC_RANGE_MA_CRASH;
+
+	if (HYPERVISOR_kexec_op(KEXEC_CMD_kexec_get_range, &range)
+	    || !range.size)
+		return;
+
+	crashk_res.start =3D range.start;
+	crashk_res.end =3D range.start + range.size - 1;
+
 	/* determine maximum number of physical cpus */
 	op.cmd =3D XENPF_get_cpuinfo;
 	op.u.pcpu_info.xen_cpuid =3D 0;
@@ -96,19 +107,6 @@ void __init xen_machine_kexec_setup_reso
 	xen_hypervisor_res.end =3D range.start + range.size - 1;
 	xen_hypervisor_res.flags =3D IORESOURCE_BUSY | IORESOURCE_MEM;
=20
-	/* fill in crashk_res if range is reserved by hypervisor */
-
-	memset(&range, 0, sizeof(range));
-	range.range =3D KEXEC_RANGE_MA_CRASH;
-
-	if (HYPERVISOR_kexec_op(KEXEC_CMD_kexec_get_range, &range))
-		goto free;
-
-	if (range.size) {
-		crashk_res.start =3D range.start;
-		crashk_res.end =3D range.start + range.size - 1;
-	}
-
 	/* get physical address of vmcoreinfo */
 	memset(&range, 0, sizeof(range));
 	range.range =3D KEXEC_RANGE_MA_VMCOREINFO;




--=__Part06299A8C.0__=
Content-Type: text/plain; name="xen-kexec-no-setup.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="xen-kexec-no-setup.patch"

kexec: don't initialize when no crash area was reserved=0A=0AWhile the =
waste of memory needed may not be significant, the amount of=0Aadditional =
but pointless entries in /proc/iomem certainly may be (on=0Alarge =
systems).=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=0A=0A--- =
a/drivers/xen/core/machine_kexec.c=0A+++ b/drivers/xen/core/machine_kexec.c=
=0A@@ -34,6 +34,17 @@ void __init xen_machine_kexec_setup_reso=0A 	if =
(!is_initial_xendomain())=0A 		return;=0A =0A+	/* fill in =
crashk_res if range is reserved by hypervisor */=0A+	memset(&range, 0, =
sizeof(range));=0A+	range.range =3D KEXEC_RANGE_MA_CRASH;=0A+=0A+	if =
(HYPERVISOR_kexec_op(KEXEC_CMD_kexec_get_range, &range)=0A+	    || =
!range.size)=0A+		return;=0A+=0A+	crashk_res.start =3D =
range.start;=0A+	crashk_res.end =3D range.start + range.size - =
1;=0A+=0A 	/* determine maximum number of physical cpus */=0A 	=
op.cmd =3D XENPF_get_cpuinfo;=0A 	op.u.pcpu_info.xen_cpuid =3D =
0;=0A@@ -96,19 +107,6 @@ void __init xen_machine_kexec_setup_reso=0A 	=
xen_hypervisor_res.end =3D range.start + range.size - 1;=0A 	xen_hypervi=
sor_res.flags =3D IORESOURCE_BUSY | IORESOURCE_MEM;=0A =0A-	/* fill in =
crashk_res if range is reserved by hypervisor */=0A-=0A-	memset(&ran=
ge, 0, sizeof(range));=0A-	range.range =3D KEXEC_RANGE_MA_CRASH;=0A-=
=0A-	if (HYPERVISOR_kexec_op(KEXEC_CMD_kexec_get_range, &range))=0A-		=
goto free;=0A-=0A-	if (range.size) {=0A-		crashk_res.start =
=3D range.start;=0A-		crashk_res.end =3D range.start + range.size=
 - 1;=0A-	}=0A-=0A 	/* get physical address of vmcoreinfo =
*/=0A 	memset(&range, 0, sizeof(range));=0A 	range.range =3D KEXEC_RANGE=
_MA_VMCOREINFO;=0A
--=__Part06299A8C.0__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--=__Part06299A8C.0__=--


From xen-devel-bounces@lists.xensource.com Wed Dec 07 14:09:54 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 14:09:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYIBi-0006NU-O1; Wed, 07 Dec 2011 14:09:34 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RYIBh-0006NF-22
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 14:09:33 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1323266891!49847467!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM1ODk=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26819 invoked from network); 7 Dec 2011 14:08:11 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-6.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 7 Dec 2011 14:08:11 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 07 Dec 2011 14:08:47 +0000
Message-Id: <4EDF81AC0200007800065FD4@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 07 Dec 2011 14:09:32 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part06299A8C.0__="
Subject: [Xen-devel] [PATCH] linux-2.6.18/kexec: don't initialize when no
 crash area was reserved
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__Part06299A8C.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

While the waste of memory needed may not be significant, the amount of
additional but pointless entries in /proc/iomem certainly may be (on
large systems).

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/drivers/xen/core/machine_kexec.c
+++ b/drivers/xen/core/machine_kexec.c
@@ -34,6 +34,17 @@ void __init xen_machine_kexec_setup_reso
 	if (!is_initial_xendomain())
 		return;
=20
+	/* fill in crashk_res if range is reserved by hypervisor */
+	memset(&range, 0, sizeof(range));
+	range.range =3D KEXEC_RANGE_MA_CRASH;
+
+	if (HYPERVISOR_kexec_op(KEXEC_CMD_kexec_get_range, &range)
+	    || !range.size)
+		return;
+
+	crashk_res.start =3D range.start;
+	crashk_res.end =3D range.start + range.size - 1;
+
 	/* determine maximum number of physical cpus */
 	op.cmd =3D XENPF_get_cpuinfo;
 	op.u.pcpu_info.xen_cpuid =3D 0;
@@ -96,19 +107,6 @@ void __init xen_machine_kexec_setup_reso
 	xen_hypervisor_res.end =3D range.start + range.size - 1;
 	xen_hypervisor_res.flags =3D IORESOURCE_BUSY | IORESOURCE_MEM;
=20
-	/* fill in crashk_res if range is reserved by hypervisor */
-
-	memset(&range, 0, sizeof(range));
-	range.range =3D KEXEC_RANGE_MA_CRASH;
-
-	if (HYPERVISOR_kexec_op(KEXEC_CMD_kexec_get_range, &range))
-		goto free;
-
-	if (range.size) {
-		crashk_res.start =3D range.start;
-		crashk_res.end =3D range.start + range.size - 1;
-	}
-
 	/* get physical address of vmcoreinfo */
 	memset(&range, 0, sizeof(range));
 	range.range =3D KEXEC_RANGE_MA_VMCOREINFO;




--=__Part06299A8C.0__=
Content-Type: text/plain; name="xen-kexec-no-setup.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="xen-kexec-no-setup.patch"

kexec: don't initialize when no crash area was reserved=0A=0AWhile the =
waste of memory needed may not be significant, the amount of=0Aadditional =
but pointless entries in /proc/iomem certainly may be (on=0Alarge =
systems).=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=0A=0A--- =
a/drivers/xen/core/machine_kexec.c=0A+++ b/drivers/xen/core/machine_kexec.c=
=0A@@ -34,6 +34,17 @@ void __init xen_machine_kexec_setup_reso=0A 	if =
(!is_initial_xendomain())=0A 		return;=0A =0A+	/* fill in =
crashk_res if range is reserved by hypervisor */=0A+	memset(&range, 0, =
sizeof(range));=0A+	range.range =3D KEXEC_RANGE_MA_CRASH;=0A+=0A+	if =
(HYPERVISOR_kexec_op(KEXEC_CMD_kexec_get_range, &range)=0A+	    || =
!range.size)=0A+		return;=0A+=0A+	crashk_res.start =3D =
range.start;=0A+	crashk_res.end =3D range.start + range.size - =
1;=0A+=0A 	/* determine maximum number of physical cpus */=0A 	=
op.cmd =3D XENPF_get_cpuinfo;=0A 	op.u.pcpu_info.xen_cpuid =3D =
0;=0A@@ -96,19 +107,6 @@ void __init xen_machine_kexec_setup_reso=0A 	=
xen_hypervisor_res.end =3D range.start + range.size - 1;=0A 	xen_hypervi=
sor_res.flags =3D IORESOURCE_BUSY | IORESOURCE_MEM;=0A =0A-	/* fill in =
crashk_res if range is reserved by hypervisor */=0A-=0A-	memset(&ran=
ge, 0, sizeof(range));=0A-	range.range =3D KEXEC_RANGE_MA_CRASH;=0A-=
=0A-	if (HYPERVISOR_kexec_op(KEXEC_CMD_kexec_get_range, &range))=0A-		=
goto free;=0A-=0A-	if (range.size) {=0A-		crashk_res.start =
=3D range.start;=0A-		crashk_res.end =3D range.start + range.size=
 - 1;=0A-	}=0A-=0A 	/* get physical address of vmcoreinfo =
*/=0A 	memset(&range, 0, sizeof(range));=0A 	range.range =3D KEXEC_RANGE=
_MA_VMCOREINFO;=0A
--=__Part06299A8C.0__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--=__Part06299A8C.0__=--


From xen-devel-bounces@lists.xensource.com Wed Dec 07 14:50:57 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 14: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.xensource.com>)
	id 1RYIpL-0006qw-50; Wed, 07 Dec 2011 14:50:31 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1RYIpJ-0006qr-6w
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 14:50:29 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-5.tower-174.messagelabs.com!1323269379!4634714!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18404 invoked from network); 7 Dec 2011 14:49:39 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-5.tower-174.messagelabs.com with SMTP;
	7 Dec 2011 14:49:39 -0000
Received: from [62.94.142.85] (account d.faggioli@sssup.it HELO [192.168.0.40])
	by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 73749691; Wed, 07 Dec 2011 15:49:32 +0100
Message-ID: <1323269351.22009.15.camel@Solace>
From: Dario Faggioli <raistlin@linux.it>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Wed, 07 Dec 2011 15:49:11 +0100
In-Reply-To: <1322065473.1005.151.camel@zakaz.uk.xensource.com>
References: <1322060131.30168.15.camel@Abyss> <1322060876.30168.18.camel@Abyss>
	<1322065473.1005.151.camel@zakaz.uk.xensource.com>
X-Mailer: Evolution 3.0.3-3 
Mime-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCHv2 0 of 1] Rework locking for sched_adjust.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============9030526257597187537=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--===============9030526257597187537==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-vp+evIGRiKfSyFLKUcqq"


--=-vp+evIGRiKfSyFLKUcqq
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi everyone,

Here it is v2 of the lock reworking around and within sched-adjust.

With respect to the first posting [1]:
 - I _did_not_ move the per-pluggable scheduler lock toward schedule.c,
   as agreed with George during review;
 - I fixed the bug in sedf spotted by Juergen the way he suggested;
 - I've finally been able to test it under all the three schedulers,=20
   and it is doing its job, at least here;

Notice the series "collapsed" in one signle patch, as it was being hard
to find a breakdown of it that does not introduce regressions and/or
transient deadlock situations worse than the ones it's trying to cure...
I hope it's still readable and comfortable to review. :-)

Thanks to everyone who provided his feedback on the first version of
this.

Regards,
Dario

[1] http://xen.1045712.n5.nabble.com/RFC-RFT-PATCH-0-of-3-rework-locking-in=
-sched-adjust-td5016899.html

--
 xen/common/sched_credit.c  |   10 ++++++--
 xen/common/sched_credit2.c |   21 ++++++++++---------
 xen/common/sched_sedf.c    |  156 ++++++++++++++++++++++++++++++++++++++++=
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++=
++++-----------------------------------
 xen/common/schedule.c      |   34 +-------------------------------
 4 files changed, 140 insertions(+), 81 deletions(-)

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-------------------------------------------------------------------
Dario Faggioli, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
PhD Candidate, ReTiS Lab, Scuola Superiore Sant'Anna, Pisa (Italy)



--=-vp+evIGRiKfSyFLKUcqq
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEABECAAYFAk7ffOcACgkQk4XaBE3IOsSVdgCdGBkXi865t9vTvqWkKx+dZ7VZ
ldMAoIeeab4df5Ltlp1rFiZXwXvliEnX
=XK9u
-----END PGP SIGNATURE-----

--=-vp+evIGRiKfSyFLKUcqq--



--===============9030526257597187537==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============9030526257597187537==--



From xen-devel-bounces@lists.xensource.com Wed Dec 07 14:50:57 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 14: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.xensource.com>)
	id 1RYIpL-0006qw-50; Wed, 07 Dec 2011 14:50:31 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1RYIpJ-0006qr-6w
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 14:50:29 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-5.tower-174.messagelabs.com!1323269379!4634714!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18404 invoked from network); 7 Dec 2011 14:49:39 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-5.tower-174.messagelabs.com with SMTP;
	7 Dec 2011 14:49:39 -0000
Received: from [62.94.142.85] (account d.faggioli@sssup.it HELO [192.168.0.40])
	by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 73749691; Wed, 07 Dec 2011 15:49:32 +0100
Message-ID: <1323269351.22009.15.camel@Solace>
From: Dario Faggioli <raistlin@linux.it>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Wed, 07 Dec 2011 15:49:11 +0100
In-Reply-To: <1322065473.1005.151.camel@zakaz.uk.xensource.com>
References: <1322060131.30168.15.camel@Abyss> <1322060876.30168.18.camel@Abyss>
	<1322065473.1005.151.camel@zakaz.uk.xensource.com>
X-Mailer: Evolution 3.0.3-3 
Mime-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCHv2 0 of 1] Rework locking for sched_adjust.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============9030526257597187537=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--===============9030526257597187537==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-vp+evIGRiKfSyFLKUcqq"


--=-vp+evIGRiKfSyFLKUcqq
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi everyone,

Here it is v2 of the lock reworking around and within sched-adjust.

With respect to the first posting [1]:
 - I _did_not_ move the per-pluggable scheduler lock toward schedule.c,
   as agreed with George during review;
 - I fixed the bug in sedf spotted by Juergen the way he suggested;
 - I've finally been able to test it under all the three schedulers,=20
   and it is doing its job, at least here;

Notice the series "collapsed" in one signle patch, as it was being hard
to find a breakdown of it that does not introduce regressions and/or
transient deadlock situations worse than the ones it's trying to cure...
I hope it's still readable and comfortable to review. :-)

Thanks to everyone who provided his feedback on the first version of
this.

Regards,
Dario

[1] http://xen.1045712.n5.nabble.com/RFC-RFT-PATCH-0-of-3-rework-locking-in=
-sched-adjust-td5016899.html

--
 xen/common/sched_credit.c  |   10 ++++++--
 xen/common/sched_credit2.c |   21 ++++++++++---------
 xen/common/sched_sedf.c    |  156 ++++++++++++++++++++++++++++++++++++++++=
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++=
++++-----------------------------------
 xen/common/schedule.c      |   34 +-------------------------------
 4 files changed, 140 insertions(+), 81 deletions(-)

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-------------------------------------------------------------------
Dario Faggioli, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
PhD Candidate, ReTiS Lab, Scuola Superiore Sant'Anna, Pisa (Italy)



--=-vp+evIGRiKfSyFLKUcqq
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEABECAAYFAk7ffOcACgkQk4XaBE3IOsSVdgCdGBkXi865t9vTvqWkKx+dZ7VZ
ldMAoIeeab4df5Ltlp1rFiZXwXvliEnX
=XK9u
-----END PGP SIGNATURE-----

--=-vp+evIGRiKfSyFLKUcqq--



--===============9030526257597187537==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============9030526257597187537==--



From xen-devel-bounces@lists.xensource.com Wed Dec 07 15:03:45 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 15:03:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYJ1k-00076h-G2; Wed, 07 Dec 2011 15:03:20 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1RYJ1i-00076c-FM
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 15:03:18 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-13.tower-27.messagelabs.com!1323270130!51253672!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=1.1 required=7.0 tests=BODY_RANDOM_LONG,DIET_1
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21609 invoked from network); 7 Dec 2011 15:02:10 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-13.tower-27.messagelabs.com with SMTP;
	7 Dec 2011 15:02:10 -0000
Received: from [62.94.142.85] (account d.faggioli@sssup.it HELO [192.168.0.40])
	by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 73750184; Wed, 07 Dec 2011 16:02:24 +0100
Message-ID: <1323270131.22009.18.camel@Solace>
From: Dario Faggioli <raistlin@linux.it>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Wed, 07 Dec 2011 16:02:11 +0100
In-Reply-To: <1323269351.22009.15.camel@Solace>
References: <1322060131.30168.15.camel@Abyss> <1322060876.30168.18.camel@Abyss>
	<1322065473.1005.151.camel@zakaz.uk.xensource.com>
	<1323269351.22009.15.camel@Solace>
X-Mailer: Evolution 3.0.3-3 
Mime-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>
Subject: [Xen-devel]  [PATCHv2 1 of 1] Rework locking for sched_adjust.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0144470413239263929=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--===============0144470413239263929==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-q3C0RM6deIxjXOsU2o/V"


--=-q3C0RM6deIxjXOsU2o/V
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

The main idea is to move (as much as possible) locking logic
from generic code to the various pluggable schedulers.

While at it, the following is also accomplished:
 - pausing all the non-current VCPUs of a domain while changing its
   scheduling parameters is not effective in avoiding races and it is
   prone to deadlock, so that is removed.
 - sedf needs a global lock for preventing races while adjusting
   domains' scheduling parameters (as it is for credit and credit2),
   so that is added.

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>

diff -r 38eb74c01d9d xen/common/sched_credit.c
--- a/xen/common/sched_credit.c	Tue Dec 06 21:16:56 2011 +0000
+++ b/xen/common/sched_credit.c	Wed Dec 07 15:45:55 2011 +0100
@@ -161,6 +161,7 @@ struct csched_dom {
  * System-wide private data
  */
 struct csched_private {
+    /* lock for the whole pluggable scheduler, nests inside cpupool_lock *=
/
     spinlock_t lock;
     struct list_head active_sdom;
     uint32_t ncpus;
@@ -800,6 +801,10 @@ csched_dom_cntl(
     struct csched_private *prv =3D CSCHED_PRIV(ops);
     unsigned long flags;
=20
+    /* Protect both get and put branches with the pluggable scheduler
+     * lock. Runq lock not needed anywhere in here. */
+    spin_lock_irqsave(&prv->lock, flags);
+
     if ( op->cmd =3D=3D XEN_DOMCTL_SCHEDOP_getinfo )
     {
         op->u.credit.weight =3D sdom->weight;
@@ -809,8 +814,6 @@ csched_dom_cntl(
     {
         ASSERT(op->cmd =3D=3D XEN_DOMCTL_SCHEDOP_putinfo);
=20
-        spin_lock_irqsave(&prv->lock, flags);
-
         if ( op->u.credit.weight !=3D 0 )
         {
             if ( !list_empty(&sdom->active_sdom_elem) )
@@ -824,9 +827,10 @@ csched_dom_cntl(
         if ( op->u.credit.cap !=3D (uint16_t)~0U )
             sdom->cap =3D op->u.credit.cap;
=20
-        spin_unlock_irqrestore(&prv->lock, flags);
     }
=20
+    spin_unlock_irqrestore(&prv->lock, flags);
+
     return 0;
 }
=20
diff -r 38eb74c01d9d xen/common/sched_credit2.c
--- a/xen/common/sched_credit2.c	Tue Dec 06 21:16:56 2011 +0000
+++ b/xen/common/sched_credit2.c	Wed Dec 07 15:45:55 2011 +0100
@@ -1384,6 +1384,10 @@ csched_dom_cntl(
     struct csched_private *prv =3D CSCHED_PRIV(ops);
     unsigned long flags;
=20
+    /* Must hold csched_priv lock to read and update sdom,
+     * runq lock to update csvcs. */
+    spin_lock_irqsave(&prv->lock, flags);
+
     if ( op->cmd =3D=3D XEN_DOMCTL_SCHEDOP_getinfo )
     {
         op->u.credit2.weight =3D sdom->weight;
@@ -1397,10 +1401,6 @@ csched_dom_cntl(
             struct list_head *iter;
             int old_weight;
=20
-            /* Must hold csched_priv lock to update sdom, runq lock to
-             * update csvcs. */
-            spin_lock_irqsave(&prv->lock, flags);
-
             old_weight =3D sdom->weight;
=20
             sdom->weight =3D op->u.credit2.weight;
@@ -1411,22 +1411,23 @@ csched_dom_cntl(
                 struct csched_vcpu *svc =3D list_entry(iter, struct csched=
_vcpu, sdom_elem);
=20
                 /* NB: Locking order is important here.  Because we grab t=
his lock here, we
-                 * must never lock csched_priv.lock if we're holding a run=
queue
-                 * lock. */
-                vcpu_schedule_lock_irq(svc->vcpu);
+                 * must never lock csched_priv.lock if we're holding a run=
queue lock.
+                 * Also, calling vcpu_schedule_lock() is enough, since IRQ=
s have already
+                 * been disabled. */
+                vcpu_schedule_lock(svc->vcpu);
=20
                 BUG_ON(svc->rqd !=3D RQD(ops, svc->vcpu->processor));
=20
                 svc->weight =3D sdom->weight;
                 update_max_weight(svc->rqd, svc->weight, old_weight);
=20
-                vcpu_schedule_unlock_irq(svc->vcpu);
+                vcpu_schedule_unlock(svc->vcpu);
             }
-
-            spin_unlock_irqrestore(&prv->lock, flags);
         }
     }
=20
+    spin_unlock_irqrestore(&prv->lock, flags);
+
     return 0;
 }
=20
diff -r 38eb74c01d9d xen/common/sched_sedf.c
--- a/xen/common/sched_sedf.c	Tue Dec 06 21:16:56 2011 +0000
+++ b/xen/common/sched_sedf.c	Wed Dec 07 15:45:55 2011 +0100
@@ -61,6 +61,11 @@ struct sedf_dom_info {
     struct domain  *domain;
 };
=20
+struct sedf_priv_info {
+    /* lock for the whole pluggable scheduler, nests inside cpupool_lock *=
/
+    spinlock_t lock;
+};
+
 struct sedf_vcpu_info {
     struct vcpu *vcpu;
     struct list_head list;
@@ -115,6 +120,8 @@ struct sedf_cpu_info {
     s_time_t         current_slice_expires;
 };
=20
+#define SEDF_PRIV(_ops) \
+    ((struct sedf_priv_info *)((_ops)->sched_data))
 #define EDOM_INFO(d)   ((struct sedf_vcpu_info *)((d)->sched_priv))
 #define CPU_INFO(cpu)  \
     ((struct sedf_cpu_info *)per_cpu(schedule_data, cpu).sched_priv)
@@ -772,6 +779,31 @@ static struct task_slice sedf_do_extra_s
 }
=20
=20
+static int sedf_init(struct scheduler *ops)
+{
+    struct sedf_priv_info *prv;
+
+    prv =3D xzalloc(struct sedf_priv_info);
+    if ( prv =3D=3D NULL )
+        return -ENOMEM;
+
+    ops->sched_data =3D prv;
+    spin_lock_init(&prv->lock);
+
+    return 0;
+}
+
+
+static void sedf_deinit(const struct scheduler *ops)
+{
+    struct sedf_priv_info *prv;
+
+    prv =3D SEDF_PRIV(ops);
+    if ( prv !=3D NULL )
+        xfree(prv);
+}
+
+
 /* Main scheduling function
    Reasons for calling this function are:
    -timeslice for the current period used up
@@ -1320,22 +1352,15 @@ static void sedf_dump_cpu_state(const st
=20
=20
 /* Adjusts periods and slices of the domains accordingly to their weights.=
 */
-static int sedf_adjust_weights(struct cpupool *c, struct xen_domctl_schedu=
ler_op *cmd)
+static int sedf_adjust_weights(struct cpupool *c, int nr_cpus, int *sumw, =
s_time_t *sumt)
 {
     struct vcpu *p;
     struct domain      *d;
-    unsigned int        cpu, nr_cpus =3D cpumask_last(&cpu_online_map) + 1=
;
-    int                *sumw =3D xzalloc_array(int, nr_cpus);
-    s_time_t           *sumt =3D xzalloc_array(s_time_t, nr_cpus);
+    unsigned int        cpu;
=20
-    if ( !sumw || !sumt )
-    {
-        xfree(sumt);
-        xfree(sumw);
-        return -ENOMEM;
-    }
-
-    /* Sum across all weights. */
+    /* Sum across all weights. Notice that no runq locking is needed
+     * here: the caller holds sedf_priv_info.lock and we're not changing
+     * anything that is accessed during scheduling. */
     rcu_read_lock(&domlist_read_lock);
     for_each_domain_in_cpupool( d, c )
     {
@@ -1365,7 +1390,9 @@ static int sedf_adjust_weights(struct cp
     }
     rcu_read_unlock(&domlist_read_lock);
=20
-    /* Adjust all slices (and periods) to the new weight. */
+    /* Adjust all slices (and periods) to the new weight. Unlike above, we
+     * need to take thr runq lock for the various VCPUs: we're modyfing
+     * slice and period which are referenced during scheduling. */
     rcu_read_lock(&domlist_read_lock);
     for_each_domain_in_cpupool( d, c )
     {
@@ -1375,20 +1402,20 @@ static int sedf_adjust_weights(struct cp
                 continue;
             if ( EDOM_INFO(p)->weight )
             {
+                /* Interrupts already off */
+                vcpu_schedule_lock(p);
                 EDOM_INFO(p)->period_orig =3D=20
                     EDOM_INFO(p)->period  =3D WEIGHT_PERIOD;
                 EDOM_INFO(p)->slice_orig  =3D
                     EDOM_INFO(p)->slice   =3D=20
                     (EDOM_INFO(p)->weight *
                      (WEIGHT_PERIOD - WEIGHT_SAFETY - sumt[cpu])) / sumw[c=
pu];
+                vcpu_schedule_unlock(p);
             }
         }
     }
     rcu_read_unlock(&domlist_read_lock);
=20
-    xfree(sumt);
-    xfree(sumw);
-
     return 0;
 }
=20
@@ -1396,19 +1423,45 @@ static int sedf_adjust_weights(struct cp
 /* set or fetch domain scheduling parameters */
 static int sedf_adjust(const struct scheduler *ops, struct domain *p, stru=
ct xen_domctl_scheduler_op *op)
 {
+    struct sedf_priv_info *prv =3D SEDF_PRIV(ops);
+    unsigned long flags;
+    unsigned int nr_cpus =3D cpumask_last(&cpu_online_map) + 1;
+    int *sumw =3D xzalloc_array(int, nr_cpus);
+    s_time_t *sumt =3D xzalloc_array(s_time_t, nr_cpus);
     struct vcpu *v;
-    int rc;
+    int rc =3D 0;
=20
     PRINT(2,"sedf_adjust was called, domain-id %i new period %"PRIu64" "
           "new slice %"PRIu64"\nlatency %"PRIu64" extra:%s\n",
           p->domain_id, op->u.sedf.period, op->u.sedf.slice,
           op->u.sedf.latency, (op->u.sedf.extratime)?"yes":"no");
=20
+    /* Serialize against the pluggable scheduler lock to protect from
+     * concurrent updates. We need to take the runq lock for the VCPUs
+     * as well, since we are touching extraweight, weight, slice and
+     * period. As in sched_credit2.c, runq locks nest inside the
+     * pluggable scheduler lock. */
+    spin_lock_irqsave(&prv->lock, flags);
+
     if ( op->cmd =3D=3D XEN_DOMCTL_SCHEDOP_putinfo )
     {
+        /* These are used in sedf_adjust_weights() but have to be allocate=
d in
+         * this function, as we need to avoid nesting xmem_pool_alloc's lo=
ck
+         * within our prv->lock. */
+        if ( !sumw || !sumt )
+        {
+            /* Check for errors here, the _getinfo branch doesn't care */
+            rc =3D -ENOMEM;
+            goto out;
+        }
+
         /* Check for sane parameters. */
         if ( !op->u.sedf.period && !op->u.sedf.weight )
-            return -EINVAL;
+        {
+            rc =3D -EINVAL;
+            goto out;
+        }
+
         if ( op->u.sedf.weight )
         {
             if ( (op->u.sedf.extratime & EXTRA_AWARE) &&
@@ -1417,59 +1470,78 @@ static int sedf_adjust(const struct sche
                 /* Weight-driven domains with extratime only. */
                 for_each_vcpu ( p, v )
                 {
+                    /* (Here and everywhere in the following) IRQs are alr=
eady off,
+                     * hence vcpu_spin_lock() is the one. */
+                    vcpu_schedule_lock(v);
                     EDOM_INFO(v)->extraweight =3D op->u.sedf.weight;
                     EDOM_INFO(v)->weight =3D 0;
                     EDOM_INFO(v)->slice =3D 0;
                     EDOM_INFO(v)->period =3D WEIGHT_PERIOD;
+                    vcpu_schedule_unlock(v);
                 }
             }
             else
             {
                 /* Weight-driven domains with real-time execution. */
-                for_each_vcpu ( p, v )
+                for_each_vcpu ( p, v ) {
+                    vcpu_schedule_lock(v);
                     EDOM_INFO(v)->weight =3D op->u.sedf.weight;
+                    vcpu_schedule_unlock(v);
+                }
             }
         }
         else
         {
+            /*
+             * Sanity checking: note that disabling extra weight requires
+             * that we set a non-zero slice.
+             */
+            if ( (op->u.sedf.period > PERIOD_MAX) ||
+                 (op->u.sedf.period < PERIOD_MIN) ||
+                 (op->u.sedf.slice  > op->u.sedf.period) ||
+                 (op->u.sedf.slice  < SLICE_MIN) )
+            {
+                rc =3D -EINVAL;
+                goto out;
+            }
+
             /* Time-driven domains. */
             for_each_vcpu ( p, v )
             {
-                /*
-                 * Sanity checking: note that disabling extra weight requi=
res
-                 * that we set a non-zero slice.
-                 */
-                if ( (op->u.sedf.period > PERIOD_MAX) ||
-                     (op->u.sedf.period < PERIOD_MIN) ||
-                     (op->u.sedf.slice  > op->u.sedf.period) ||
-                     (op->u.sedf.slice  < SLICE_MIN) )
-                    return -EINVAL;
+                vcpu_schedule_lock(v);
                 EDOM_INFO(v)->weight =3D 0;
                 EDOM_INFO(v)->extraweight =3D 0;
                 EDOM_INFO(v)->period_orig =3D=20
                     EDOM_INFO(v)->period  =3D op->u.sedf.period;
                 EDOM_INFO(v)->slice_orig  =3D=20
                     EDOM_INFO(v)->slice   =3D op->u.sedf.slice;
+                vcpu_schedule_unlock(v);
             }
         }
=20
-        rc =3D sedf_adjust_weights(p->cpupool, op);
+        rc =3D sedf_adjust_weights(p->cpupool, nr_cpus, sumw, sumt);
         if ( rc )
-            return rc;
+            goto out;
=20
         for_each_vcpu ( p, v )
         {
+            vcpu_schedule_lock(v);
             EDOM_INFO(v)->status  =3D=20
                 (EDOM_INFO(v)->status &
                  ~EXTRA_AWARE) | (op->u.sedf.extratime & EXTRA_AWARE);
             EDOM_INFO(v)->latency =3D op->u.sedf.latency;
             extraq_check(v);
+            vcpu_schedule_unlock(v);
         }
     }
     else if ( op->cmd =3D=3D XEN_DOMCTL_SCHEDOP_getinfo )
     {
         if ( p->vcpu[0] =3D=3D NULL )
-            return -EINVAL;
+        {
+            rc =3D -EINVAL;
+            goto out;
+        }
+
         op->u.sedf.period    =3D EDOM_INFO(p->vcpu[0])->period;
         op->u.sedf.slice     =3D EDOM_INFO(p->vcpu[0])->slice;
         op->u.sedf.extratime =3D EDOM_INFO(p->vcpu[0])->status & EXTRA_AWA=
RE;
@@ -1477,14 +1549,23 @@ static int sedf_adjust(const struct sche
         op->u.sedf.weight    =3D EDOM_INFO(p->vcpu[0])->weight;
     }
=20
-    PRINT(2,"sedf_adjust_finished\n");
-    return 0;
+out:
+    spin_unlock_irqrestore(&prv->lock, flags);
+
+    xfree(sumt);
+    xfree(sumw);
+
+    PRINT(2,"sedf_adjust_finished with return code %d\n", rc);
+    return rc;
 }
=20
+static struct sedf_priv_info _sedf_priv;
+
 const struct scheduler sched_sedf_def =3D {
-    .name     =3D "Simple EDF Scheduler",
-    .opt_name =3D "sedf",
-    .sched_id =3D XEN_SCHEDULER_SEDF,
+    .name           =3D "Simple EDF Scheduler",
+    .opt_name       =3D "sedf",
+    .sched_id       =3D XEN_SCHEDULER_SEDF,
+    .sched_data     =3D &_sedf_priv,
    =20
     .init_domain    =3D sedf_init_domain,
     .destroy_domain =3D sedf_destroy_domain,
@@ -1498,6 +1579,9 @@ const struct scheduler sched_sedf_def =3D=20
     .alloc_domdata  =3D sedf_alloc_domdata,
     .free_domdata   =3D sedf_free_domdata,
=20
+    .init           =3D sedf_init,
+    .deinit         =3D sedf_deinit,
+
     .do_schedule    =3D sedf_do_schedule,
     .pick_cpu       =3D sedf_pick_cpu,
     .dump_cpu_state =3D sedf_dump_cpu_state,
diff -r 38eb74c01d9d xen/common/schedule.c
--- a/xen/common/schedule.c	Tue Dec 06 21:16:56 2011 +0000
+++ b/xen/common/schedule.c	Wed Dec 07 15:45:55 2011 +0100
@@ -1005,7 +1005,6 @@ int sched_id(void)
 /* Adjust scheduling parameter for a given domain. */
 long sched_adjust(struct domain *d, struct xen_domctl_scheduler_op *op)
 {
-    struct vcpu *v;
     long ret;
    =20
     if ( (op->sched_id !=3D DOM2OP(d)->sched_id) ||
@@ -1013,40 +1012,11 @@ long sched_adjust(struct domain *d, stru
           (op->cmd !=3D XEN_DOMCTL_SCHEDOP_getinfo)) )
         return -EINVAL;
=20
-    /*
-     * Most VCPUs we can simply pause. If we are adjusting this VCPU then
-     * we acquire the local schedule_lock to guard against concurrent upda=
tes.
-     *
-     * We only acquire the local schedule lock after we have paused all ot=
her
-     * VCPUs in this domain. There are two reasons for this:
-     * 1- We don't want to hold up interrupts as pausing a VCPU can
-     *    trigger a tlb shootdown.
-     * 2- Pausing other VCPUs involves briefly locking the schedule
-     *    lock of the CPU they are running on. This CPU could be the
-     *    same as ours.
-     */
-
-    for_each_vcpu ( d, v )
-    {
-        if ( v !=3D current )
-            vcpu_pause(v);
-    }
-
-    if ( d =3D=3D current->domain )
-        vcpu_schedule_lock_irq(current);
-
+    /* NB: the pluggable scheduler code needs to take care
+     * of locking by itself. */
     if ( (ret =3D SCHED_OP(DOM2OP(d), adjust, d, op)) =3D=3D 0 )
         TRACE_1D(TRC_SCHED_ADJDOM, d->domain_id);
=20
-    if ( d =3D=3D current->domain )
-        vcpu_schedule_unlock_irq(current);
-
-    for_each_vcpu ( d, v )
-    {
-        if ( v !=3D current )
-            vcpu_unpause(v);
-    }
-
     return ret;
 }
=20

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-------------------------------------------------------------------
Dario Faggioli, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
PhD Candidate, ReTiS Lab, Scuola Superiore Sant'Anna, Pisa (Italy)


--=-q3C0RM6deIxjXOsU2o/V
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEABECAAYFAk7ff/MACgkQk4XaBE3IOsTMmQCfba0ErG7KDO1WJzflbOy289Z2
mZQAn01E9lHFuo6UD367Vv4Me2rW0fzz
=raBP
-----END PGP SIGNATURE-----

--=-q3C0RM6deIxjXOsU2o/V--



--===============0144470413239263929==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============0144470413239263929==--



From xen-devel-bounces@lists.xensource.com Wed Dec 07 15:03:45 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 15:03:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYJ1k-00076h-G2; Wed, 07 Dec 2011 15:03:20 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1RYJ1i-00076c-FM
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 15:03:18 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-13.tower-27.messagelabs.com!1323270130!51253672!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=1.1 required=7.0 tests=BODY_RANDOM_LONG,DIET_1
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21609 invoked from network); 7 Dec 2011 15:02:10 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-13.tower-27.messagelabs.com with SMTP;
	7 Dec 2011 15:02:10 -0000
Received: from [62.94.142.85] (account d.faggioli@sssup.it HELO [192.168.0.40])
	by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 73750184; Wed, 07 Dec 2011 16:02:24 +0100
Message-ID: <1323270131.22009.18.camel@Solace>
From: Dario Faggioli <raistlin@linux.it>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Wed, 07 Dec 2011 16:02:11 +0100
In-Reply-To: <1323269351.22009.15.camel@Solace>
References: <1322060131.30168.15.camel@Abyss> <1322060876.30168.18.camel@Abyss>
	<1322065473.1005.151.camel@zakaz.uk.xensource.com>
	<1323269351.22009.15.camel@Solace>
X-Mailer: Evolution 3.0.3-3 
Mime-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>
Subject: [Xen-devel]  [PATCHv2 1 of 1] Rework locking for sched_adjust.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0144470413239263929=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--===============0144470413239263929==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-q3C0RM6deIxjXOsU2o/V"


--=-q3C0RM6deIxjXOsU2o/V
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

The main idea is to move (as much as possible) locking logic
from generic code to the various pluggable schedulers.

While at it, the following is also accomplished:
 - pausing all the non-current VCPUs of a domain while changing its
   scheduling parameters is not effective in avoiding races and it is
   prone to deadlock, so that is removed.
 - sedf needs a global lock for preventing races while adjusting
   domains' scheduling parameters (as it is for credit and credit2),
   so that is added.

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>

diff -r 38eb74c01d9d xen/common/sched_credit.c
--- a/xen/common/sched_credit.c	Tue Dec 06 21:16:56 2011 +0000
+++ b/xen/common/sched_credit.c	Wed Dec 07 15:45:55 2011 +0100
@@ -161,6 +161,7 @@ struct csched_dom {
  * System-wide private data
  */
 struct csched_private {
+    /* lock for the whole pluggable scheduler, nests inside cpupool_lock *=
/
     spinlock_t lock;
     struct list_head active_sdom;
     uint32_t ncpus;
@@ -800,6 +801,10 @@ csched_dom_cntl(
     struct csched_private *prv =3D CSCHED_PRIV(ops);
     unsigned long flags;
=20
+    /* Protect both get and put branches with the pluggable scheduler
+     * lock. Runq lock not needed anywhere in here. */
+    spin_lock_irqsave(&prv->lock, flags);
+
     if ( op->cmd =3D=3D XEN_DOMCTL_SCHEDOP_getinfo )
     {
         op->u.credit.weight =3D sdom->weight;
@@ -809,8 +814,6 @@ csched_dom_cntl(
     {
         ASSERT(op->cmd =3D=3D XEN_DOMCTL_SCHEDOP_putinfo);
=20
-        spin_lock_irqsave(&prv->lock, flags);
-
         if ( op->u.credit.weight !=3D 0 )
         {
             if ( !list_empty(&sdom->active_sdom_elem) )
@@ -824,9 +827,10 @@ csched_dom_cntl(
         if ( op->u.credit.cap !=3D (uint16_t)~0U )
             sdom->cap =3D op->u.credit.cap;
=20
-        spin_unlock_irqrestore(&prv->lock, flags);
     }
=20
+    spin_unlock_irqrestore(&prv->lock, flags);
+
     return 0;
 }
=20
diff -r 38eb74c01d9d xen/common/sched_credit2.c
--- a/xen/common/sched_credit2.c	Tue Dec 06 21:16:56 2011 +0000
+++ b/xen/common/sched_credit2.c	Wed Dec 07 15:45:55 2011 +0100
@@ -1384,6 +1384,10 @@ csched_dom_cntl(
     struct csched_private *prv =3D CSCHED_PRIV(ops);
     unsigned long flags;
=20
+    /* Must hold csched_priv lock to read and update sdom,
+     * runq lock to update csvcs. */
+    spin_lock_irqsave(&prv->lock, flags);
+
     if ( op->cmd =3D=3D XEN_DOMCTL_SCHEDOP_getinfo )
     {
         op->u.credit2.weight =3D sdom->weight;
@@ -1397,10 +1401,6 @@ csched_dom_cntl(
             struct list_head *iter;
             int old_weight;
=20
-            /* Must hold csched_priv lock to update sdom, runq lock to
-             * update csvcs. */
-            spin_lock_irqsave(&prv->lock, flags);
-
             old_weight =3D sdom->weight;
=20
             sdom->weight =3D op->u.credit2.weight;
@@ -1411,22 +1411,23 @@ csched_dom_cntl(
                 struct csched_vcpu *svc =3D list_entry(iter, struct csched=
_vcpu, sdom_elem);
=20
                 /* NB: Locking order is important here.  Because we grab t=
his lock here, we
-                 * must never lock csched_priv.lock if we're holding a run=
queue
-                 * lock. */
-                vcpu_schedule_lock_irq(svc->vcpu);
+                 * must never lock csched_priv.lock if we're holding a run=
queue lock.
+                 * Also, calling vcpu_schedule_lock() is enough, since IRQ=
s have already
+                 * been disabled. */
+                vcpu_schedule_lock(svc->vcpu);
=20
                 BUG_ON(svc->rqd !=3D RQD(ops, svc->vcpu->processor));
=20
                 svc->weight =3D sdom->weight;
                 update_max_weight(svc->rqd, svc->weight, old_weight);
=20
-                vcpu_schedule_unlock_irq(svc->vcpu);
+                vcpu_schedule_unlock(svc->vcpu);
             }
-
-            spin_unlock_irqrestore(&prv->lock, flags);
         }
     }
=20
+    spin_unlock_irqrestore(&prv->lock, flags);
+
     return 0;
 }
=20
diff -r 38eb74c01d9d xen/common/sched_sedf.c
--- a/xen/common/sched_sedf.c	Tue Dec 06 21:16:56 2011 +0000
+++ b/xen/common/sched_sedf.c	Wed Dec 07 15:45:55 2011 +0100
@@ -61,6 +61,11 @@ struct sedf_dom_info {
     struct domain  *domain;
 };
=20
+struct sedf_priv_info {
+    /* lock for the whole pluggable scheduler, nests inside cpupool_lock *=
/
+    spinlock_t lock;
+};
+
 struct sedf_vcpu_info {
     struct vcpu *vcpu;
     struct list_head list;
@@ -115,6 +120,8 @@ struct sedf_cpu_info {
     s_time_t         current_slice_expires;
 };
=20
+#define SEDF_PRIV(_ops) \
+    ((struct sedf_priv_info *)((_ops)->sched_data))
 #define EDOM_INFO(d)   ((struct sedf_vcpu_info *)((d)->sched_priv))
 #define CPU_INFO(cpu)  \
     ((struct sedf_cpu_info *)per_cpu(schedule_data, cpu).sched_priv)
@@ -772,6 +779,31 @@ static struct task_slice sedf_do_extra_s
 }
=20
=20
+static int sedf_init(struct scheduler *ops)
+{
+    struct sedf_priv_info *prv;
+
+    prv =3D xzalloc(struct sedf_priv_info);
+    if ( prv =3D=3D NULL )
+        return -ENOMEM;
+
+    ops->sched_data =3D prv;
+    spin_lock_init(&prv->lock);
+
+    return 0;
+}
+
+
+static void sedf_deinit(const struct scheduler *ops)
+{
+    struct sedf_priv_info *prv;
+
+    prv =3D SEDF_PRIV(ops);
+    if ( prv !=3D NULL )
+        xfree(prv);
+}
+
+
 /* Main scheduling function
    Reasons for calling this function are:
    -timeslice for the current period used up
@@ -1320,22 +1352,15 @@ static void sedf_dump_cpu_state(const st
=20
=20
 /* Adjusts periods and slices of the domains accordingly to their weights.=
 */
-static int sedf_adjust_weights(struct cpupool *c, struct xen_domctl_schedu=
ler_op *cmd)
+static int sedf_adjust_weights(struct cpupool *c, int nr_cpus, int *sumw, =
s_time_t *sumt)
 {
     struct vcpu *p;
     struct domain      *d;
-    unsigned int        cpu, nr_cpus =3D cpumask_last(&cpu_online_map) + 1=
;
-    int                *sumw =3D xzalloc_array(int, nr_cpus);
-    s_time_t           *sumt =3D xzalloc_array(s_time_t, nr_cpus);
+    unsigned int        cpu;
=20
-    if ( !sumw || !sumt )
-    {
-        xfree(sumt);
-        xfree(sumw);
-        return -ENOMEM;
-    }
-
-    /* Sum across all weights. */
+    /* Sum across all weights. Notice that no runq locking is needed
+     * here: the caller holds sedf_priv_info.lock and we're not changing
+     * anything that is accessed during scheduling. */
     rcu_read_lock(&domlist_read_lock);
     for_each_domain_in_cpupool( d, c )
     {
@@ -1365,7 +1390,9 @@ static int sedf_adjust_weights(struct cp
     }
     rcu_read_unlock(&domlist_read_lock);
=20
-    /* Adjust all slices (and periods) to the new weight. */
+    /* Adjust all slices (and periods) to the new weight. Unlike above, we
+     * need to take thr runq lock for the various VCPUs: we're modyfing
+     * slice and period which are referenced during scheduling. */
     rcu_read_lock(&domlist_read_lock);
     for_each_domain_in_cpupool( d, c )
     {
@@ -1375,20 +1402,20 @@ static int sedf_adjust_weights(struct cp
                 continue;
             if ( EDOM_INFO(p)->weight )
             {
+                /* Interrupts already off */
+                vcpu_schedule_lock(p);
                 EDOM_INFO(p)->period_orig =3D=20
                     EDOM_INFO(p)->period  =3D WEIGHT_PERIOD;
                 EDOM_INFO(p)->slice_orig  =3D
                     EDOM_INFO(p)->slice   =3D=20
                     (EDOM_INFO(p)->weight *
                      (WEIGHT_PERIOD - WEIGHT_SAFETY - sumt[cpu])) / sumw[c=
pu];
+                vcpu_schedule_unlock(p);
             }
         }
     }
     rcu_read_unlock(&domlist_read_lock);
=20
-    xfree(sumt);
-    xfree(sumw);
-
     return 0;
 }
=20
@@ -1396,19 +1423,45 @@ static int sedf_adjust_weights(struct cp
 /* set or fetch domain scheduling parameters */
 static int sedf_adjust(const struct scheduler *ops, struct domain *p, stru=
ct xen_domctl_scheduler_op *op)
 {
+    struct sedf_priv_info *prv =3D SEDF_PRIV(ops);
+    unsigned long flags;
+    unsigned int nr_cpus =3D cpumask_last(&cpu_online_map) + 1;
+    int *sumw =3D xzalloc_array(int, nr_cpus);
+    s_time_t *sumt =3D xzalloc_array(s_time_t, nr_cpus);
     struct vcpu *v;
-    int rc;
+    int rc =3D 0;
=20
     PRINT(2,"sedf_adjust was called, domain-id %i new period %"PRIu64" "
           "new slice %"PRIu64"\nlatency %"PRIu64" extra:%s\n",
           p->domain_id, op->u.sedf.period, op->u.sedf.slice,
           op->u.sedf.latency, (op->u.sedf.extratime)?"yes":"no");
=20
+    /* Serialize against the pluggable scheduler lock to protect from
+     * concurrent updates. We need to take the runq lock for the VCPUs
+     * as well, since we are touching extraweight, weight, slice and
+     * period. As in sched_credit2.c, runq locks nest inside the
+     * pluggable scheduler lock. */
+    spin_lock_irqsave(&prv->lock, flags);
+
     if ( op->cmd =3D=3D XEN_DOMCTL_SCHEDOP_putinfo )
     {
+        /* These are used in sedf_adjust_weights() but have to be allocate=
d in
+         * this function, as we need to avoid nesting xmem_pool_alloc's lo=
ck
+         * within our prv->lock. */
+        if ( !sumw || !sumt )
+        {
+            /* Check for errors here, the _getinfo branch doesn't care */
+            rc =3D -ENOMEM;
+            goto out;
+        }
+
         /* Check for sane parameters. */
         if ( !op->u.sedf.period && !op->u.sedf.weight )
-            return -EINVAL;
+        {
+            rc =3D -EINVAL;
+            goto out;
+        }
+
         if ( op->u.sedf.weight )
         {
             if ( (op->u.sedf.extratime & EXTRA_AWARE) &&
@@ -1417,59 +1470,78 @@ static int sedf_adjust(const struct sche
                 /* Weight-driven domains with extratime only. */
                 for_each_vcpu ( p, v )
                 {
+                    /* (Here and everywhere in the following) IRQs are alr=
eady off,
+                     * hence vcpu_spin_lock() is the one. */
+                    vcpu_schedule_lock(v);
                     EDOM_INFO(v)->extraweight =3D op->u.sedf.weight;
                     EDOM_INFO(v)->weight =3D 0;
                     EDOM_INFO(v)->slice =3D 0;
                     EDOM_INFO(v)->period =3D WEIGHT_PERIOD;
+                    vcpu_schedule_unlock(v);
                 }
             }
             else
             {
                 /* Weight-driven domains with real-time execution. */
-                for_each_vcpu ( p, v )
+                for_each_vcpu ( p, v ) {
+                    vcpu_schedule_lock(v);
                     EDOM_INFO(v)->weight =3D op->u.sedf.weight;
+                    vcpu_schedule_unlock(v);
+                }
             }
         }
         else
         {
+            /*
+             * Sanity checking: note that disabling extra weight requires
+             * that we set a non-zero slice.
+             */
+            if ( (op->u.sedf.period > PERIOD_MAX) ||
+                 (op->u.sedf.period < PERIOD_MIN) ||
+                 (op->u.sedf.slice  > op->u.sedf.period) ||
+                 (op->u.sedf.slice  < SLICE_MIN) )
+            {
+                rc =3D -EINVAL;
+                goto out;
+            }
+
             /* Time-driven domains. */
             for_each_vcpu ( p, v )
             {
-                /*
-                 * Sanity checking: note that disabling extra weight requi=
res
-                 * that we set a non-zero slice.
-                 */
-                if ( (op->u.sedf.period > PERIOD_MAX) ||
-                     (op->u.sedf.period < PERIOD_MIN) ||
-                     (op->u.sedf.slice  > op->u.sedf.period) ||
-                     (op->u.sedf.slice  < SLICE_MIN) )
-                    return -EINVAL;
+                vcpu_schedule_lock(v);
                 EDOM_INFO(v)->weight =3D 0;
                 EDOM_INFO(v)->extraweight =3D 0;
                 EDOM_INFO(v)->period_orig =3D=20
                     EDOM_INFO(v)->period  =3D op->u.sedf.period;
                 EDOM_INFO(v)->slice_orig  =3D=20
                     EDOM_INFO(v)->slice   =3D op->u.sedf.slice;
+                vcpu_schedule_unlock(v);
             }
         }
=20
-        rc =3D sedf_adjust_weights(p->cpupool, op);
+        rc =3D sedf_adjust_weights(p->cpupool, nr_cpus, sumw, sumt);
         if ( rc )
-            return rc;
+            goto out;
=20
         for_each_vcpu ( p, v )
         {
+            vcpu_schedule_lock(v);
             EDOM_INFO(v)->status  =3D=20
                 (EDOM_INFO(v)->status &
                  ~EXTRA_AWARE) | (op->u.sedf.extratime & EXTRA_AWARE);
             EDOM_INFO(v)->latency =3D op->u.sedf.latency;
             extraq_check(v);
+            vcpu_schedule_unlock(v);
         }
     }
     else if ( op->cmd =3D=3D XEN_DOMCTL_SCHEDOP_getinfo )
     {
         if ( p->vcpu[0] =3D=3D NULL )
-            return -EINVAL;
+        {
+            rc =3D -EINVAL;
+            goto out;
+        }
+
         op->u.sedf.period    =3D EDOM_INFO(p->vcpu[0])->period;
         op->u.sedf.slice     =3D EDOM_INFO(p->vcpu[0])->slice;
         op->u.sedf.extratime =3D EDOM_INFO(p->vcpu[0])->status & EXTRA_AWA=
RE;
@@ -1477,14 +1549,23 @@ static int sedf_adjust(const struct sche
         op->u.sedf.weight    =3D EDOM_INFO(p->vcpu[0])->weight;
     }
=20
-    PRINT(2,"sedf_adjust_finished\n");
-    return 0;
+out:
+    spin_unlock_irqrestore(&prv->lock, flags);
+
+    xfree(sumt);
+    xfree(sumw);
+
+    PRINT(2,"sedf_adjust_finished with return code %d\n", rc);
+    return rc;
 }
=20
+static struct sedf_priv_info _sedf_priv;
+
 const struct scheduler sched_sedf_def =3D {
-    .name     =3D "Simple EDF Scheduler",
-    .opt_name =3D "sedf",
-    .sched_id =3D XEN_SCHEDULER_SEDF,
+    .name           =3D "Simple EDF Scheduler",
+    .opt_name       =3D "sedf",
+    .sched_id       =3D XEN_SCHEDULER_SEDF,
+    .sched_data     =3D &_sedf_priv,
    =20
     .init_domain    =3D sedf_init_domain,
     .destroy_domain =3D sedf_destroy_domain,
@@ -1498,6 +1579,9 @@ const struct scheduler sched_sedf_def =3D=20
     .alloc_domdata  =3D sedf_alloc_domdata,
     .free_domdata   =3D sedf_free_domdata,
=20
+    .init           =3D sedf_init,
+    .deinit         =3D sedf_deinit,
+
     .do_schedule    =3D sedf_do_schedule,
     .pick_cpu       =3D sedf_pick_cpu,
     .dump_cpu_state =3D sedf_dump_cpu_state,
diff -r 38eb74c01d9d xen/common/schedule.c
--- a/xen/common/schedule.c	Tue Dec 06 21:16:56 2011 +0000
+++ b/xen/common/schedule.c	Wed Dec 07 15:45:55 2011 +0100
@@ -1005,7 +1005,6 @@ int sched_id(void)
 /* Adjust scheduling parameter for a given domain. */
 long sched_adjust(struct domain *d, struct xen_domctl_scheduler_op *op)
 {
-    struct vcpu *v;
     long ret;
    =20
     if ( (op->sched_id !=3D DOM2OP(d)->sched_id) ||
@@ -1013,40 +1012,11 @@ long sched_adjust(struct domain *d, stru
           (op->cmd !=3D XEN_DOMCTL_SCHEDOP_getinfo)) )
         return -EINVAL;
=20
-    /*
-     * Most VCPUs we can simply pause. If we are adjusting this VCPU then
-     * we acquire the local schedule_lock to guard against concurrent upda=
tes.
-     *
-     * We only acquire the local schedule lock after we have paused all ot=
her
-     * VCPUs in this domain. There are two reasons for this:
-     * 1- We don't want to hold up interrupts as pausing a VCPU can
-     *    trigger a tlb shootdown.
-     * 2- Pausing other VCPUs involves briefly locking the schedule
-     *    lock of the CPU they are running on. This CPU could be the
-     *    same as ours.
-     */
-
-    for_each_vcpu ( d, v )
-    {
-        if ( v !=3D current )
-            vcpu_pause(v);
-    }
-
-    if ( d =3D=3D current->domain )
-        vcpu_schedule_lock_irq(current);
-
+    /* NB: the pluggable scheduler code needs to take care
+     * of locking by itself. */
     if ( (ret =3D SCHED_OP(DOM2OP(d), adjust, d, op)) =3D=3D 0 )
         TRACE_1D(TRC_SCHED_ADJDOM, d->domain_id);
=20
-    if ( d =3D=3D current->domain )
-        vcpu_schedule_unlock_irq(current);
-
-    for_each_vcpu ( d, v )
-    {
-        if ( v !=3D current )
-            vcpu_unpause(v);
-    }
-
     return ret;
 }
=20

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-------------------------------------------------------------------
Dario Faggioli, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
PhD Candidate, ReTiS Lab, Scuola Superiore Sant'Anna, Pisa (Italy)


--=-q3C0RM6deIxjXOsU2o/V
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEABECAAYFAk7ff/MACgkQk4XaBE3IOsTMmQCfba0ErG7KDO1WJzflbOy289Z2
mZQAn01E9lHFuo6UD367Vv4Me2rW0fzz
=raBP
-----END PGP SIGNATURE-----

--=-q3C0RM6deIxjXOsU2o/V--



--===============0144470413239263929==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============0144470413239263929==--



From xen-devel-bounces@lists.xensource.com Wed Dec 07 15:05:57 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 15:05:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYJ3n-0007CA-7v; Wed, 07 Dec 2011 15:05:27 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1RYJ3l-0007Br-Rf
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 15:05:26 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-7.tower-182.messagelabs.com!1323270278!6215114!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26104 invoked from network); 7 Dec 2011 15:04:38 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-7.tower-182.messagelabs.com with SMTP;
	7 Dec 2011 15:04:38 -0000
Received: from [62.94.142.85] (account d.faggioli@sssup.it HELO [192.168.0.40])
	by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 73750303; Wed, 07 Dec 2011 16:04:31 +0100
Message-ID: <1323270260.22009.20.camel@Solace>
From: Dario Faggioli <raistlin@linux.it>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Wed, 07 Dec 2011 16:04:20 +0100
In-Reply-To: <1323269351.22009.15.camel@Solace>
References: <1322060131.30168.15.camel@Abyss> <1322060876.30168.18.camel@Abyss>
	<1322065473.1005.151.camel@zakaz.uk.xensource.com>
	<1323269351.22009.15.camel@Solace>
X-Mailer: Evolution 3.0.3-3 
Mime-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCHv2 0 of 1] Rework locking for sched_adjust.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============2549411025965329084=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--===============2549411025965329084==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-C6w9hVOZsEEgsctzuZdP"


--=-C6w9hVOZsEEgsctzuZdP
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, 2011-12-07 at 15:49 +0100, Dario Faggioli wrote:
> Hi everyone,
>
Ok, apparently Evolution (with maybe a little help from me too! :-P)
messed up with threading... For the next time, I'll take a serious look
at that thing called patchbomb, I promise! :-P

Sorry for this,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-------------------------------------------------------------------
Dario Faggioli, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
PhD Candidate, ReTiS Lab, Scuola Superiore Sant'Anna, Pisa (Italy)


--=-C6w9hVOZsEEgsctzuZdP
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEABECAAYFAk7fgHQACgkQk4XaBE3IOsSHWgCfShvSD5X9fCCnEMaAmvlbNCAg
FM4AnjPT4BDtwumix8X4JPT4+6DwYIhy
=Sizu
-----END PGP SIGNATURE-----

--=-C6w9hVOZsEEgsctzuZdP--



--===============2549411025965329084==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============2549411025965329084==--



From xen-devel-bounces@lists.xensource.com Wed Dec 07 15:05:57 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 15:05:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYJ3n-0007CA-7v; Wed, 07 Dec 2011 15:05:27 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1RYJ3l-0007Br-Rf
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 15:05:26 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-7.tower-182.messagelabs.com!1323270278!6215114!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26104 invoked from network); 7 Dec 2011 15:04:38 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-7.tower-182.messagelabs.com with SMTP;
	7 Dec 2011 15:04:38 -0000
Received: from [62.94.142.85] (account d.faggioli@sssup.it HELO [192.168.0.40])
	by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 73750303; Wed, 07 Dec 2011 16:04:31 +0100
Message-ID: <1323270260.22009.20.camel@Solace>
From: Dario Faggioli <raistlin@linux.it>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Wed, 07 Dec 2011 16:04:20 +0100
In-Reply-To: <1323269351.22009.15.camel@Solace>
References: <1322060131.30168.15.camel@Abyss> <1322060876.30168.18.camel@Abyss>
	<1322065473.1005.151.camel@zakaz.uk.xensource.com>
	<1323269351.22009.15.camel@Solace>
X-Mailer: Evolution 3.0.3-3 
Mime-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCHv2 0 of 1] Rework locking for sched_adjust.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============2549411025965329084=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--===============2549411025965329084==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-C6w9hVOZsEEgsctzuZdP"


--=-C6w9hVOZsEEgsctzuZdP
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, 2011-12-07 at 15:49 +0100, Dario Faggioli wrote:
> Hi everyone,
>
Ok, apparently Evolution (with maybe a little help from me too! :-P)
messed up with threading... For the next time, I'll take a serious look
at that thing called patchbomb, I promise! :-P

Sorry for this,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-------------------------------------------------------------------
Dario Faggioli, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
PhD Candidate, ReTiS Lab, Scuola Superiore Sant'Anna, Pisa (Italy)


--=-C6w9hVOZsEEgsctzuZdP
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEABECAAYFAk7fgHQACgkQk4XaBE3IOsSHWgCfShvSD5X9fCCnEMaAmvlbNCAg
FM4AnjPT4BDtwumix8X4JPT4+6DwYIhy
=Sizu
-----END PGP SIGNATURE-----

--=-C6w9hVOZsEEgsctzuZdP--



--===============2549411025965329084==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============2549411025965329084==--



From xen-devel-bounces@lists.xensource.com Wed Dec 07 15:06:00 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 15:06:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYJ3x-0007DL-M3; Wed, 07 Dec 2011 15:05:37 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RYJ3w-0007Cc-Bi
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 15:05:36 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1323270289!7254806!1
X-Originating-IP: [209.85.214.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24828 invoked from network); 7 Dec 2011 15:04:49 -0000
Received: from mail-bw0-f43.google.com (HELO mail-bw0-f43.google.com)
	(209.85.214.43)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Dec 2011 15:04:49 -0000
Received: by bkbzs2 with SMTP id zs2so1740137bkb.30
	for <xen-devel@lists.xensource.com>;
	Wed, 07 Dec 2011 07:04:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=XqymrpIVi0gvtRPNDekiJdcDHR9sSs6mDy6S+Uon42w=;
	b=AJwagkLmmfUzqB8ESaZ1dAnOUsRKneeuX/ZXtt0mUB2cT0VRNqdkwdlsvg0CftjOh8
	MPyM7tmnHluEeeOI6v8NWnouNZIEaaNlDMUnOR5CcMOSjnhI1kXAf26WM/tizcSxyA88
	ZVMVDUbn8j4s6dlUS/vttg8T5NopM7T66DslE=
Received: by 10.180.95.170 with SMTP id dl10mr24656663wib.31.1323270288784;
	Wed, 07 Dec 2011 07:04:48 -0800 (PST)
Received: from [192.168.1.70]
	(host81-155-119-104.range81-155.btcentralplus.com. [81.155.119.104])
	by mx.google.com with ESMTPS id w8sm3191747wiz.4.2011.12.07.07.04.45
	(version=SSLv3 cipher=OTHER); Wed, 07 Dec 2011 07:04:47 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Wed, 07 Dec 2011 15:04:41 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	"Zhang, Xiantao" <xiantao.zhang@intel.com>
Message-ID: <CB053109.26BFC%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH RFC 04/25] Replace "/" operand with div64
Thread-Index: Acy08Yunsg6AnObTLEmiUuTE/oTIlg==
In-Reply-To: <alpine.DEB.2.00.1112071222580.31179@kaball-desktop>
Mime-version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Tim Deegan <Tim.Deegan@citrix.com>, Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH RFC 04/25] Replace "/" operand with div64
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 07/12/2011 12:23, "Stefano Stabellini" <stefano.stabellini@eu.citrix.com>
wrote:

> On Wed, 7 Dec 2011, Zhang, Xiantao wrote:
>> Hi, Stefano 
>> Great work from you guys!  One quick comment:  Just found the below logic's
>> change maybe wrong and probably  break current things.
>> Original logic is  A+B -(C%D), but it is changed to  (A+B-C)%D,  so if it is
>> not an intended fix, it should be an issue.
>> Thanks!
>> Xiantao  
> 
> True! Thanks for spotting this!

For the avoidance of doubt: this patch 04/25 is wrongheaded, and I will nack
it if it appears in the final patch series. You probably got this impression
from me already. ;-)

>>> diff --git a/xen/common/timer.c b/xen/common/timer.c index 0547ea3..043250e
>>> 100644
>>> --- a/xen/common/timer.c
>>> +++ b/xen/common/timer.c
>>> @@ -23,6 +23,7 @@
>>> #include <xen/symbols.h>
>>> #include <asm/system.h>
>>> #include <asm/desc.h>
>>> +#include <asm/div64.h>
>>> #include <asm/atomic.h>
>>> 
>>> /* We program the time hardware this far behind the closest deadline. */ @@
>>> -503,16 +504,18 @@ static void timer_softirq_action(void)
>>> 
>>> s_time_t align_timer(s_time_t firsttick, uint64_t period)  {
>>> +    uint64_t n;
>>>    if ( !period )
>>>        return firsttick;
>>  
>>> -    return firsttick + (period - 1) - ((firsttick - 1) % period);
>>> +    n = firsttick + (period - 1) - (firsttick - 1);
>>> +    return do_div(n, period);
>>> }
>>  
>> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 15:06:00 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 15:06:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYJ3x-0007DL-M3; Wed, 07 Dec 2011 15:05:37 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RYJ3w-0007Cc-Bi
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 15:05:36 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1323270289!7254806!1
X-Originating-IP: [209.85.214.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24828 invoked from network); 7 Dec 2011 15:04:49 -0000
Received: from mail-bw0-f43.google.com (HELO mail-bw0-f43.google.com)
	(209.85.214.43)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Dec 2011 15:04:49 -0000
Received: by bkbzs2 with SMTP id zs2so1740137bkb.30
	for <xen-devel@lists.xensource.com>;
	Wed, 07 Dec 2011 07:04:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=XqymrpIVi0gvtRPNDekiJdcDHR9sSs6mDy6S+Uon42w=;
	b=AJwagkLmmfUzqB8ESaZ1dAnOUsRKneeuX/ZXtt0mUB2cT0VRNqdkwdlsvg0CftjOh8
	MPyM7tmnHluEeeOI6v8NWnouNZIEaaNlDMUnOR5CcMOSjnhI1kXAf26WM/tizcSxyA88
	ZVMVDUbn8j4s6dlUS/vttg8T5NopM7T66DslE=
Received: by 10.180.95.170 with SMTP id dl10mr24656663wib.31.1323270288784;
	Wed, 07 Dec 2011 07:04:48 -0800 (PST)
Received: from [192.168.1.70]
	(host81-155-119-104.range81-155.btcentralplus.com. [81.155.119.104])
	by mx.google.com with ESMTPS id w8sm3191747wiz.4.2011.12.07.07.04.45
	(version=SSLv3 cipher=OTHER); Wed, 07 Dec 2011 07:04:47 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Wed, 07 Dec 2011 15:04:41 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	"Zhang, Xiantao" <xiantao.zhang@intel.com>
Message-ID: <CB053109.26BFC%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH RFC 04/25] Replace "/" operand with div64
Thread-Index: Acy08Yunsg6AnObTLEmiUuTE/oTIlg==
In-Reply-To: <alpine.DEB.2.00.1112071222580.31179@kaball-desktop>
Mime-version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Tim Deegan <Tim.Deegan@citrix.com>, Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH RFC 04/25] Replace "/" operand with div64
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 07/12/2011 12:23, "Stefano Stabellini" <stefano.stabellini@eu.citrix.com>
wrote:

> On Wed, 7 Dec 2011, Zhang, Xiantao wrote:
>> Hi, Stefano 
>> Great work from you guys!  One quick comment:  Just found the below logic's
>> change maybe wrong and probably  break current things.
>> Original logic is  A+B -(C%D), but it is changed to  (A+B-C)%D,  so if it is
>> not an intended fix, it should be an issue.
>> Thanks!
>> Xiantao  
> 
> True! Thanks for spotting this!

For the avoidance of doubt: this patch 04/25 is wrongheaded, and I will nack
it if it appears in the final patch series. You probably got this impression
from me already. ;-)

>>> diff --git a/xen/common/timer.c b/xen/common/timer.c index 0547ea3..043250e
>>> 100644
>>> --- a/xen/common/timer.c
>>> +++ b/xen/common/timer.c
>>> @@ -23,6 +23,7 @@
>>> #include <xen/symbols.h>
>>> #include <asm/system.h>
>>> #include <asm/desc.h>
>>> +#include <asm/div64.h>
>>> #include <asm/atomic.h>
>>> 
>>> /* We program the time hardware this far behind the closest deadline. */ @@
>>> -503,16 +504,18 @@ static void timer_softirq_action(void)
>>> 
>>> s_time_t align_timer(s_time_t firsttick, uint64_t period)  {
>>> +    uint64_t n;
>>>    if ( !period )
>>>        return firsttick;
>>  
>>> -    return firsttick + (period - 1) - ((firsttick - 1) % period);
>>> +    n = firsttick + (period - 1) - (firsttick - 1);
>>> +    return do_div(n, period);
>>> }
>>  
>> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 15:59:51 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 15:59:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYJtj-0007l2-5I; Wed, 07 Dec 2011 15:59:07 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RYJtg-0007kx-U0
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 15:59:05 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1323273496!4585090!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjA3NQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24080 invoked from network); 7 Dec 2011 15:58:17 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Dec 2011 15:58:17 -0000
X-IronPort-AV: E=Sophos;i="4.71,314,1320624000"; 
   d="scan'208";a="9346422"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Dec 2011 15:57:52 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 7 Dec 2011 15:57:52 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RYJsV-0002uE-PD;
	Wed, 07 Dec 2011 15:57:51 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RYJsV-0003PG-Nv;
	Wed, 07 Dec 2011 15:57:51 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10409-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 7 Dec 2011 15:57:51 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10409: regressions - trouble:
	broken/fail/pass
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10409 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10409/

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-i386-xl-win7-amd64  3 host-install(3)              broken
 test-amd64-amd64-xl-sedf      3 host-install(3)              broken
 test-amd64-i386-win           8 guest-saverestore         fail REGR. vs. 10201
 test-i386-i386-win            8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-amd64-xl-win       3 host-install(3)              broken
 test-amd64-i386-xl-win-vcpus1  8 guest-saverestore        fail REGR. vs. 10201
 test-i386-i386-xl-win         8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-i386-win-vcpus1   8 guest-saverestore fail in 10401 REGR. vs. 10201
 test-amd64-amd64-win         8 guest-saverestore fail in 10401 REGR. vs. 10201
 test-amd64-amd64-xl-win      8 guest-saverestore fail in 10401 REGR. vs. 10201

Tests which are failing intermittently (not blocking):
 test-amd64-i386-win-vcpus1    7 windows-install             fail pass in 10401
 test-amd64-amd64-win          7 windows-install             fail pass in 10401
 test-amd64-amd64-xl-sedf     11 guest-localmigrate fail in 10401 pass in 10397
 test-amd64-i386-xl-win-vcpus1  7 windows-install   fail in 10401 pass in 10409
 test-amd64-amd64-xl-win       7 windows-install    fail in 10397 pass in 10401

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-win7-amd64  7 windows-install              fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install          fail never pass
 test-i386-i386-xl-winxpsp3    7 windows-install              fail   never pass
 test-amd64-i386-xend-winxpsp3  7 windows-install              fail  never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   never pass
 test-amd64-i386-xl-win7-amd64  7 windows-install      fail in 10401 never pass

version targeted for testing:
 xen                  38eb74c01d9d
baseline version:
 xen                  62ff6a318c5d

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scanneel.ca>
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Andres Lagar-Cavilla <andres@lagarcavilla>
  Andrew Cooper <andrew.cooper3@citrix.com>
  Anthony PERARD <anthony.perard@citrix.com>
  Brendan Cully <brendan@cs.ubc.ca>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Haitao Shan <haitao.shan@intel.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@novell.com>
  Jan Beulich <jbeulich@suse.com>
  Jonathan Davies <jonathan.davies@citrix.com>
  juergen.gross@ts.fujitsu.com
  Keir Fraser <keir@xen.org>
  Liu, Jinsong <jinsong.liu@intel.com>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
  Philipp Hahn <hahn@univention.de>
  Shriram Rajagopalan <rshriram@cs.ubc.ca>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang2 <wei.wang2@amd.com>
  Xudong Hao <xudong.hao@intel.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                broken  
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     broken  
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      broken  
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 1493 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 15:59:51 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 15:59:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYJtj-0007l2-5I; Wed, 07 Dec 2011 15:59:07 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RYJtg-0007kx-U0
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 15:59:05 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1323273496!4585090!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjA3NQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24080 invoked from network); 7 Dec 2011 15:58:17 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Dec 2011 15:58:17 -0000
X-IronPort-AV: E=Sophos;i="4.71,314,1320624000"; 
   d="scan'208";a="9346422"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Dec 2011 15:57:52 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 7 Dec 2011 15:57:52 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RYJsV-0002uE-PD;
	Wed, 07 Dec 2011 15:57:51 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RYJsV-0003PG-Nv;
	Wed, 07 Dec 2011 15:57:51 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10409-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 7 Dec 2011 15:57:51 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10409: regressions - trouble:
	broken/fail/pass
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10409 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10409/

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-i386-xl-win7-amd64  3 host-install(3)              broken
 test-amd64-amd64-xl-sedf      3 host-install(3)              broken
 test-amd64-i386-win           8 guest-saverestore         fail REGR. vs. 10201
 test-i386-i386-win            8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-amd64-xl-win       3 host-install(3)              broken
 test-amd64-i386-xl-win-vcpus1  8 guest-saverestore        fail REGR. vs. 10201
 test-i386-i386-xl-win         8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-i386-win-vcpus1   8 guest-saverestore fail in 10401 REGR. vs. 10201
 test-amd64-amd64-win         8 guest-saverestore fail in 10401 REGR. vs. 10201
 test-amd64-amd64-xl-win      8 guest-saverestore fail in 10401 REGR. vs. 10201

Tests which are failing intermittently (not blocking):
 test-amd64-i386-win-vcpus1    7 windows-install             fail pass in 10401
 test-amd64-amd64-win          7 windows-install             fail pass in 10401
 test-amd64-amd64-xl-sedf     11 guest-localmigrate fail in 10401 pass in 10397
 test-amd64-i386-xl-win-vcpus1  7 windows-install   fail in 10401 pass in 10409
 test-amd64-amd64-xl-win       7 windows-install    fail in 10397 pass in 10401

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-win7-amd64  7 windows-install              fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install          fail never pass
 test-i386-i386-xl-winxpsp3    7 windows-install              fail   never pass
 test-amd64-i386-xend-winxpsp3  7 windows-install              fail  never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   never pass
 test-amd64-i386-xl-win7-amd64  7 windows-install      fail in 10401 never pass

version targeted for testing:
 xen                  38eb74c01d9d
baseline version:
 xen                  62ff6a318c5d

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scanneel.ca>
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Andres Lagar-Cavilla <andres@lagarcavilla>
  Andrew Cooper <andrew.cooper3@citrix.com>
  Anthony PERARD <anthony.perard@citrix.com>
  Brendan Cully <brendan@cs.ubc.ca>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Haitao Shan <haitao.shan@intel.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@novell.com>
  Jan Beulich <jbeulich@suse.com>
  Jonathan Davies <jonathan.davies@citrix.com>
  juergen.gross@ts.fujitsu.com
  Keir Fraser <keir@xen.org>
  Liu, Jinsong <jinsong.liu@intel.com>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
  Philipp Hahn <hahn@univention.de>
  Shriram Rajagopalan <rshriram@cs.ubc.ca>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang2 <wei.wang2@amd.com>
  Xudong Hao <xudong.hao@intel.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                broken  
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     broken  
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      broken  
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 1493 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 16:24:07 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 16:24:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYKHO-0008PI-8w; Wed, 07 Dec 2011 16:23:34 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RYKHN-0008PA-Kr
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 16:23:33 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-14.tower-182.messagelabs.com!1323274965!6288657!1
X-Originating-IP: [208.97.132.119]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xMTkgPT4gMTYyMjU=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5520 invoked from network); 7 Dec 2011 16:22:46 -0000
Received: from caiajhbdcbbj.dreamhost.com (HELO homiemail-a23.g.dreamhost.com)
	(208.97.132.119) by server-14.tower-182.messagelabs.com with SMTP;
	7 Dec 2011 16:22:46 -0000
Received: from homiemail-a23.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a23.g.dreamhost.com (Postfix) with ESMTP id 527A24B0089;
	Wed,  7 Dec 2011 08:22:43 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=gRDWTvXrsW+2+ykDNdQa4EG3fMJpxIKzEGdQEXPLLdlJ
	CMwMw00mryLN9dbwwLnpwduzmJkMpuP3Ucq5hgG+C5djqgT+Plvia3AdRwpkjT7V
	BRe2n7WEqi3boUgDQ9LmOi4i8OcEmQTVQassOip9WyJ5cAAtmL7fIrmOYueadG0=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=l6+gmas2zVw59umtLUykjiS6Lbg=; b=PvhtIx92
	lcTQDSGAkYC42lEdD37oLjfEcIF4QmOjv1VXA9YZUKP8JnyAZgEMHojP7vwuHnpV
	1hQoJazy9TWzmHHk27RAh4kjvHR9YtqlHb+Ov30b8j75eiN/0KSMOKZe43uDsEOS
	OqhSVVhcROq5peznoX37aOZmSIZDygPGZKQ=
Received: from webmail.lagarcavilla.org (ahfbbjcaiaae.dreamhost.com
	[75.119.208.4]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a23.g.dreamhost.com (Postfix) with ESMTPA id 5D9F84B0062; 
	Wed,  7 Dec 2011 08:22:42 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP; Wed, 7 Dec 2011 08:22:43 -0800
Message-ID: <32bd4bb0a16289aae52816d9cee2e7c8.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20111207092737.GA24563@aepfle.de>
References: <mailman.3467.1323191271.12970.xen-devel@lists.xensource.com>
	<78bcef1bbb35c6176c138c1a6089f034.squirrel@webmail.lagarcavilla.org>
	<20111207092737.GA24563@aepfle.de>
Date: Wed, 7 Dec 2011 08:22:43 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Olaf Hering" <olaf@aepfle.de>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 2 of 5] xenpaging: map gfn before nomination
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> On Tue, Dec 06, Andres Lagar-Cavilla wrote:
>
>> Ouch! You're absolutely tying the user space pager with the underlying
>> xen
>> paging code. Most of your patches change the tools and the hypervisor in
>> lockstep.
>
> Yes, pager and hypervisor are bound closely together.
>
>> Patch 4 in your series is one such case. Short-cutting the state
>> machine:
>> great. But what is the gain for the hypervisor in *not* sending the
>> EVICT_FAIL event. It's a good thing. It keeps the same interface to
>> user-space. Xenpaging may not need it, but the Xen paging code does not
>> exist solely for xenpaging.
>
> What IS the need to send yet another request? It adds just overhead for
> no obvious need. Please show the code that will benefit from the extra
> EVICT_FAIL message.

I have mentioned the reasoning in a previous email.

We need to look at the big picture when it comes to overhead. Sending an
event is, what, nanoseconds? -- particularly when guest events are
guaranteed to succeed and not perhaps go to sleep on a wait queue.

The I/O involved is an overhead orders of magnitude much larger. When you
have hundreds (thousands?) of VMs pounding your storage fabric, it becomes
germane to avoid unnecessary I/O.

A pager that performs a batch of nominations, I/O, and evictions, is not
at all unreasonable. It will benefit greatly from early "do not evict"
notices.

The cost/benefit equation here is drastically skewed in favor of one
event, versus one I/O.
>
>> Patch 1 is also a problem. I don't buy that we can number interfaces,
>> and
>> then only support the tip ("Sorry, ENOEXEC, dig out an older
>> hypervisor").
>> Either we bite the bullet of some level of backwards compatibility with
>> all its messiness, or we just keep it in flux until there is convergence
>> on a major "barrier".
>
> An out-of-tree pager can very well try to support a number of
> hypervisors, perhaps patch #1 can be extended to report the age in some
> way. But why would the upstream pager care about (development!) state
> from the past?
>
>
>> This current patch 2 is also rather gratuitous. The need to map before
>> nominate feels superfluous. If Xen cannot deal with nomination requests
>> on
>> pages that have not been mapped, then we've broken Xen.
>
> Why? It was broken (or rather: not optimal) in the first place.
> Any attempt to map a gfn in any  paging state has to return -ENOENT
> right away. The pager is certainly a special case, and thanks to this
> change, and your change for the page-in part, the special handling can now
> get removed.

If you're pushing for this change because you want to get rid from a few
lines of (correct) error checking in the hypervisor, that's not a good
reason imho.

If you have a more compelling reason, sure.

>
>> Anyway, I hope my message gets across. I'm not trying to organize a
>> blockade on your code. I'm trying to get to the best possible hypervisor
>> paging support we can.
>
> Great.
> Then please improve tools/xenpaging/, thats the cure for NIH.

Woaah. Please read my email carefully. This is not about NIH. This about
changes that bring no tangible benefits and break other people's code.

Andres
>
> Olaf
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 16:24:07 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 16:24:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYKHO-0008PI-8w; Wed, 07 Dec 2011 16:23:34 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RYKHN-0008PA-Kr
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 16:23:33 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-14.tower-182.messagelabs.com!1323274965!6288657!1
X-Originating-IP: [208.97.132.119]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xMTkgPT4gMTYyMjU=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5520 invoked from network); 7 Dec 2011 16:22:46 -0000
Received: from caiajhbdcbbj.dreamhost.com (HELO homiemail-a23.g.dreamhost.com)
	(208.97.132.119) by server-14.tower-182.messagelabs.com with SMTP;
	7 Dec 2011 16:22:46 -0000
Received: from homiemail-a23.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a23.g.dreamhost.com (Postfix) with ESMTP id 527A24B0089;
	Wed,  7 Dec 2011 08:22:43 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=gRDWTvXrsW+2+ykDNdQa4EG3fMJpxIKzEGdQEXPLLdlJ
	CMwMw00mryLN9dbwwLnpwduzmJkMpuP3Ucq5hgG+C5djqgT+Plvia3AdRwpkjT7V
	BRe2n7WEqi3boUgDQ9LmOi4i8OcEmQTVQassOip9WyJ5cAAtmL7fIrmOYueadG0=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=l6+gmas2zVw59umtLUykjiS6Lbg=; b=PvhtIx92
	lcTQDSGAkYC42lEdD37oLjfEcIF4QmOjv1VXA9YZUKP8JnyAZgEMHojP7vwuHnpV
	1hQoJazy9TWzmHHk27RAh4kjvHR9YtqlHb+Ov30b8j75eiN/0KSMOKZe43uDsEOS
	OqhSVVhcROq5peznoX37aOZmSIZDygPGZKQ=
Received: from webmail.lagarcavilla.org (ahfbbjcaiaae.dreamhost.com
	[75.119.208.4]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a23.g.dreamhost.com (Postfix) with ESMTPA id 5D9F84B0062; 
	Wed,  7 Dec 2011 08:22:42 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP; Wed, 7 Dec 2011 08:22:43 -0800
Message-ID: <32bd4bb0a16289aae52816d9cee2e7c8.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20111207092737.GA24563@aepfle.de>
References: <mailman.3467.1323191271.12970.xen-devel@lists.xensource.com>
	<78bcef1bbb35c6176c138c1a6089f034.squirrel@webmail.lagarcavilla.org>
	<20111207092737.GA24563@aepfle.de>
Date: Wed, 7 Dec 2011 08:22:43 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Olaf Hering" <olaf@aepfle.de>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 2 of 5] xenpaging: map gfn before nomination
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> On Tue, Dec 06, Andres Lagar-Cavilla wrote:
>
>> Ouch! You're absolutely tying the user space pager with the underlying
>> xen
>> paging code. Most of your patches change the tools and the hypervisor in
>> lockstep.
>
> Yes, pager and hypervisor are bound closely together.
>
>> Patch 4 in your series is one such case. Short-cutting the state
>> machine:
>> great. But what is the gain for the hypervisor in *not* sending the
>> EVICT_FAIL event. It's a good thing. It keeps the same interface to
>> user-space. Xenpaging may not need it, but the Xen paging code does not
>> exist solely for xenpaging.
>
> What IS the need to send yet another request? It adds just overhead for
> no obvious need. Please show the code that will benefit from the extra
> EVICT_FAIL message.

I have mentioned the reasoning in a previous email.

We need to look at the big picture when it comes to overhead. Sending an
event is, what, nanoseconds? -- particularly when guest events are
guaranteed to succeed and not perhaps go to sleep on a wait queue.

The I/O involved is an overhead orders of magnitude much larger. When you
have hundreds (thousands?) of VMs pounding your storage fabric, it becomes
germane to avoid unnecessary I/O.

A pager that performs a batch of nominations, I/O, and evictions, is not
at all unreasonable. It will benefit greatly from early "do not evict"
notices.

The cost/benefit equation here is drastically skewed in favor of one
event, versus one I/O.
>
>> Patch 1 is also a problem. I don't buy that we can number interfaces,
>> and
>> then only support the tip ("Sorry, ENOEXEC, dig out an older
>> hypervisor").
>> Either we bite the bullet of some level of backwards compatibility with
>> all its messiness, or we just keep it in flux until there is convergence
>> on a major "barrier".
>
> An out-of-tree pager can very well try to support a number of
> hypervisors, perhaps patch #1 can be extended to report the age in some
> way. But why would the upstream pager care about (development!) state
> from the past?
>
>
>> This current patch 2 is also rather gratuitous. The need to map before
>> nominate feels superfluous. If Xen cannot deal with nomination requests
>> on
>> pages that have not been mapped, then we've broken Xen.
>
> Why? It was broken (or rather: not optimal) in the first place.
> Any attempt to map a gfn in any  paging state has to return -ENOENT
> right away. The pager is certainly a special case, and thanks to this
> change, and your change for the page-in part, the special handling can now
> get removed.

If you're pushing for this change because you want to get rid from a few
lines of (correct) error checking in the hypervisor, that's not a good
reason imho.

If you have a more compelling reason, sure.

>
>> Anyway, I hope my message gets across. I'm not trying to organize a
>> blockade on your code. I'm trying to get to the best possible hypervisor
>> paging support we can.
>
> Great.
> Then please improve tools/xenpaging/, thats the cure for NIH.

Woaah. Please read my email carefully. This is not about NIH. This about
changes that bring no tangible benefits and break other people's code.

Andres
>
> Olaf
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 16:25:11 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 16: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.xensource.com>)
	id 1RYKIT-0008Rt-Nx; Wed, 07 Dec 2011 16:24:41 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RYKIS-0008Rg-FH
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 16:24:40 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-5.tower-21.messagelabs.com!1323275032!1040226!1
X-Originating-IP: [208.97.132.74]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi43NCA9PiAxNTc1OQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4004 invoked from network); 7 Dec 2011 16:23:52 -0000
Received: from caiajhbdcahe.dreamhost.com (HELO homiemail-a75.g.dreamhost.com)
	(208.97.132.74) by server-5.tower-21.messagelabs.com with SMTP;
	7 Dec 2011 16:23:52 -0000
Received: from homiemail-a75.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a75.g.dreamhost.com (Postfix) with ESMTP id 8C9AA5EC07E;
	Wed,  7 Dec 2011 08:23:51 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=UvFskf4wDjgOxx/viFkRDq1dh2GC5AR7cPmvbBwM/3Wr
	nKs7tnN/8z6ITHPWADscPyN/CbCwgu8WDNz54uH1uf9EComBJTcF6GBzzo93DGlg
	mH2cN8gQIuNu6feyWsz1j6UrGdgSb8k2Qb9uNyc+93ar82sPZ5epVhsqMtgwr/g=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=k/CzAeXqu7qEdw0LzZIyU+e4pZA=; b=Hwz4i/Sy
	VC5KV7f8bhyUyN/LNybVpnypuLXzRa34A5Kf16onfaCPVeTo2dih7Mowp4Xrt+FO
	YAwglmNNmKWbJ2+haXL3efs7cB8JFq6J77P67VNRjRQ0qK//JZ0UqrvVgqdiGqvK
	VD+QmTtXDU7VojbxMeZPNp0MEod/mV4H6Yk=
Received: from webmail.lagarcavilla.org (ahfbbjcaiaae.dreamhost.com
	[75.119.208.4]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a75.g.dreamhost.com (Postfix) with ESMTPA id 0683B5EC079; 
	Wed,  7 Dec 2011 08:23:50 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP; Wed, 7 Dec 2011 08:23:51 -0800
Message-ID: <a8e4c4283fb91e690e2b09a8640cd938.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20111207125805.GG31448@ocelot.phlegethon.org>
References: <mailman.3467.1323191271.12970.xen-devel@lists.xensource.com>
	<78bcef1bbb35c6176c138c1a6089f034.squirrel@webmail.lagarcavilla.org>
	<20111207092737.GA24563@aepfle.de>
	<20111207125805.GG31448@ocelot.phlegethon.org>
Date: Wed, 7 Dec 2011 08:23:51 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Tim Deegan" <tim@xen.org>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: Olaf Hering <olaf@aepfle.de>, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 2 of 5] xenpaging: map gfn before nomination
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> At 10:27 +0100 on 07 Dec (1323253657), Olaf Hering wrote:
>> On Tue, Dec 06, Andres Lagar-Cavilla wrote:
>>
>> > Ouch! You're absolutely tying the user space pager with the underlying
>> xen
>> > paging code. Most of your patches change the tools and the hypervisor
>> in
>> > lockstep.
>>
>> Yes, pager and hypervisor are bound closely together.
>>
>> > Patch 4 in your series is one such case. Short-cutting the state
>> machine:
>> > great. But what is the gain for the hypervisor in *not* sending the
>> > EVICT_FAIL event. It's a good thing. It keeps the same interface to
>> > user-space. Xenpaging may not need it, but the Xen paging code does
>> not
>> > exist solely for xenpaging.
>>
>> What IS the need to send yet another request? It adds just overhead for
>> no obvious need. Please show the code that will benefit from the extra
>> EVICT_FAIL message.
>
> While in general it's good to keep backward compatibility, I don't think
> this interface has ever had a stable, usable release (that didn't
> involve the consumer at least carrying hypervisor patches of their own)
> so I think it's OK to make fairly large changes in it.
Would you agree that targeting 4.2 as a reasonable long-term interface is
a. feasible? b. worthy?
Andres
>
> Tim.
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 16:25:11 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 16: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.xensource.com>)
	id 1RYKIT-0008Rt-Nx; Wed, 07 Dec 2011 16:24:41 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RYKIS-0008Rg-FH
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 16:24:40 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-5.tower-21.messagelabs.com!1323275032!1040226!1
X-Originating-IP: [208.97.132.74]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi43NCA9PiAxNTc1OQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4004 invoked from network); 7 Dec 2011 16:23:52 -0000
Received: from caiajhbdcahe.dreamhost.com (HELO homiemail-a75.g.dreamhost.com)
	(208.97.132.74) by server-5.tower-21.messagelabs.com with SMTP;
	7 Dec 2011 16:23:52 -0000
Received: from homiemail-a75.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a75.g.dreamhost.com (Postfix) with ESMTP id 8C9AA5EC07E;
	Wed,  7 Dec 2011 08:23:51 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=UvFskf4wDjgOxx/viFkRDq1dh2GC5AR7cPmvbBwM/3Wr
	nKs7tnN/8z6ITHPWADscPyN/CbCwgu8WDNz54uH1uf9EComBJTcF6GBzzo93DGlg
	mH2cN8gQIuNu6feyWsz1j6UrGdgSb8k2Qb9uNyc+93ar82sPZ5epVhsqMtgwr/g=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=k/CzAeXqu7qEdw0LzZIyU+e4pZA=; b=Hwz4i/Sy
	VC5KV7f8bhyUyN/LNybVpnypuLXzRa34A5Kf16onfaCPVeTo2dih7Mowp4Xrt+FO
	YAwglmNNmKWbJ2+haXL3efs7cB8JFq6J77P67VNRjRQ0qK//JZ0UqrvVgqdiGqvK
	VD+QmTtXDU7VojbxMeZPNp0MEod/mV4H6Yk=
Received: from webmail.lagarcavilla.org (ahfbbjcaiaae.dreamhost.com
	[75.119.208.4]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a75.g.dreamhost.com (Postfix) with ESMTPA id 0683B5EC079; 
	Wed,  7 Dec 2011 08:23:50 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP; Wed, 7 Dec 2011 08:23:51 -0800
Message-ID: <a8e4c4283fb91e690e2b09a8640cd938.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20111207125805.GG31448@ocelot.phlegethon.org>
References: <mailman.3467.1323191271.12970.xen-devel@lists.xensource.com>
	<78bcef1bbb35c6176c138c1a6089f034.squirrel@webmail.lagarcavilla.org>
	<20111207092737.GA24563@aepfle.de>
	<20111207125805.GG31448@ocelot.phlegethon.org>
Date: Wed, 7 Dec 2011 08:23:51 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Tim Deegan" <tim@xen.org>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: Olaf Hering <olaf@aepfle.de>, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 2 of 5] xenpaging: map gfn before nomination
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> At 10:27 +0100 on 07 Dec (1323253657), Olaf Hering wrote:
>> On Tue, Dec 06, Andres Lagar-Cavilla wrote:
>>
>> > Ouch! You're absolutely tying the user space pager with the underlying
>> xen
>> > paging code. Most of your patches change the tools and the hypervisor
>> in
>> > lockstep.
>>
>> Yes, pager and hypervisor are bound closely together.
>>
>> > Patch 4 in your series is one such case. Short-cutting the state
>> machine:
>> > great. But what is the gain for the hypervisor in *not* sending the
>> > EVICT_FAIL event. It's a good thing. It keeps the same interface to
>> > user-space. Xenpaging may not need it, but the Xen paging code does
>> not
>> > exist solely for xenpaging.
>>
>> What IS the need to send yet another request? It adds just overhead for
>> no obvious need. Please show the code that will benefit from the extra
>> EVICT_FAIL message.
>
> While in general it's good to keep backward compatibility, I don't think
> this interface has ever had a stable, usable release (that didn't
> involve the consumer at least carrying hypervisor patches of their own)
> so I think it's OK to make fairly large changes in it.
Would you agree that targeting 4.2 as a reasonable long-term interface is
a. feasible? b. worthy?
Andres
>
> Tim.
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 16:27:27 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 16:27:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYKKn-00009C-9t; Wed, 07 Dec 2011 16:27:05 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RYKKl-00008z-Nl
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 16:27:03 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-12.tower-174.messagelabs.com!1323275175!4598855!1
X-Originating-IP: [208.97.132.119]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xMTkgPT4gMTYyMjU=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7866 invoked from network); 7 Dec 2011 16:26:16 -0000
Received: from caiajhbdcbbj.dreamhost.com (HELO homiemail-a76.g.dreamhost.com)
	(208.97.132.119) by server-12.tower-174.messagelabs.com with SMTP;
	7 Dec 2011 16:26:16 -0000
Received: from homiemail-a76.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTP id 35534458083;
	Wed,  7 Dec 2011 08:26:14 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=impYrFXPmM/laDj+BYXZPiNA4THlaZtq7VSTlgXOP3ST
	KGh7XdnIZgeoERZC4no+31NKpVgZHFR2vUo2k2MYZV33HARnJu8HYhfsnP9sz8Yx
	cf2R+HiJw8miPwPHFNM8egfHo9AjZWNFo+SspBKtVE8k791rKp2HF+ID10ie/Ck=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=zsdvaLMQSKDxuCSALZEj6vHqWNw=; b=X4YTfVAL
	sdcwzRUlF09426ajmudWsvwpOJkOtOGrW4JtEIfH0JupUy4sNG7U6T/potdi2RQQ
	fosNLgTK9HT3nntdd7bMFA2WaI8ODdY769+dqKTgVXEqNmqtLos0a+W3gIdaJJxP
	eGR8SQAAsGyCYybKmeRk6GNpzuSfVsl95jg=
Received: from webmail.lagarcavilla.org (ahfbbjcaiaae.dreamhost.com
	[75.119.208.4]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTPA id C077E45807B; 
	Wed,  7 Dec 2011 08:26:13 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP; Wed, 7 Dec 2011 08:26:14 -0800
Message-ID: <04e50a9cc26a9e74fa1e3a259fa23d1c.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20111207131753.GA27309@aepfle.de>
References: <patchbomb.1323098647@xdev.gridcentric.ca>
	<20111206172605.GA18176@aepfle.de>
	<d33d99829ec12990334e271eeb36b06c.squirrel@webmail.lagarcavilla.org>
	<20111207131753.GA27309@aepfle.de>
Date: Wed, 7 Dec 2011 08:26:14 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Olaf Hering" <olaf@aepfle.de>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com, tim@xen.org,
	keir.xen@gmail.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 0 of 2] Mem event ring management overhaul
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> On Tue, Dec 06, Andres Lagar-Cavilla wrote:
>
>> If the request comes from the guest itself, and it requires
>> paging_populate (!= p2m_query), the event is guaranteed to be put in the
>> ring, and then the vcpu goes to sleep.
>>
>> Easy-peasy
>
> If everything were so easy. ;-)
>
> I will try to combine your patch with my paging waitqueue change.
> Perhaps your change should disallow paging if max_cpus is larger than
> RING_SIZE().
That sounds excellent. I can do those changes as well, if you don't want
to be burdened by that.

I think it's wise though, to suspend forward-motion on either "branch" of
ring management until we get a verdict. The fundamentals of each
philosophy have been exposed. Further code has a 50% of being throw-away.

Thanks
Andres
>
>
> Olaf
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 16:27:27 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 16:27:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYKKn-00009C-9t; Wed, 07 Dec 2011 16:27:05 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RYKKl-00008z-Nl
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 16:27:03 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-12.tower-174.messagelabs.com!1323275175!4598855!1
X-Originating-IP: [208.97.132.119]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xMTkgPT4gMTYyMjU=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7866 invoked from network); 7 Dec 2011 16:26:16 -0000
Received: from caiajhbdcbbj.dreamhost.com (HELO homiemail-a76.g.dreamhost.com)
	(208.97.132.119) by server-12.tower-174.messagelabs.com with SMTP;
	7 Dec 2011 16:26:16 -0000
Received: from homiemail-a76.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTP id 35534458083;
	Wed,  7 Dec 2011 08:26:14 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=impYrFXPmM/laDj+BYXZPiNA4THlaZtq7VSTlgXOP3ST
	KGh7XdnIZgeoERZC4no+31NKpVgZHFR2vUo2k2MYZV33HARnJu8HYhfsnP9sz8Yx
	cf2R+HiJw8miPwPHFNM8egfHo9AjZWNFo+SspBKtVE8k791rKp2HF+ID10ie/Ck=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=zsdvaLMQSKDxuCSALZEj6vHqWNw=; b=X4YTfVAL
	sdcwzRUlF09426ajmudWsvwpOJkOtOGrW4JtEIfH0JupUy4sNG7U6T/potdi2RQQ
	fosNLgTK9HT3nntdd7bMFA2WaI8ODdY769+dqKTgVXEqNmqtLos0a+W3gIdaJJxP
	eGR8SQAAsGyCYybKmeRk6GNpzuSfVsl95jg=
Received: from webmail.lagarcavilla.org (ahfbbjcaiaae.dreamhost.com
	[75.119.208.4]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTPA id C077E45807B; 
	Wed,  7 Dec 2011 08:26:13 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP; Wed, 7 Dec 2011 08:26:14 -0800
Message-ID: <04e50a9cc26a9e74fa1e3a259fa23d1c.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20111207131753.GA27309@aepfle.de>
References: <patchbomb.1323098647@xdev.gridcentric.ca>
	<20111206172605.GA18176@aepfle.de>
	<d33d99829ec12990334e271eeb36b06c.squirrel@webmail.lagarcavilla.org>
	<20111207131753.GA27309@aepfle.de>
Date: Wed, 7 Dec 2011 08:26:14 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Olaf Hering" <olaf@aepfle.de>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com, tim@xen.org,
	keir.xen@gmail.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 0 of 2] Mem event ring management overhaul
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> On Tue, Dec 06, Andres Lagar-Cavilla wrote:
>
>> If the request comes from the guest itself, and it requires
>> paging_populate (!= p2m_query), the event is guaranteed to be put in the
>> ring, and then the vcpu goes to sleep.
>>
>> Easy-peasy
>
> If everything were so easy. ;-)
>
> I will try to combine your patch with my paging waitqueue change.
> Perhaps your change should disallow paging if max_cpus is larger than
> RING_SIZE().
That sounds excellent. I can do those changes as well, if you don't want
to be burdened by that.

I think it's wise though, to suspend forward-motion on either "branch" of
ring management until we get a verdict. The fundamentals of each
philosophy have been exposed. Further code has a 50% of being throw-away.

Thanks
Andres
>
>
> Olaf
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 16:28:39 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 16: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.xensource.com>)
	id 1RYKLw-0000GP-Up; Wed, 07 Dec 2011 16:28:16 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RYKLw-0000Fl-77
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 16:28:16 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-14.tower-21.messagelabs.com!1323275247!7353016!1
X-Originating-IP: [208.97.132.66]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi42NiA9PiAxNTkxNQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26602 invoked from network); 7 Dec 2011 16:27:27 -0000
Received: from caiajhbdcagg.dreamhost.com (HELO homiemail-a21.g.dreamhost.com)
	(208.97.132.66) by server-14.tower-21.messagelabs.com with SMTP;
	7 Dec 2011 16:27:27 -0000
Received: from homiemail-a21.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTP id 5669D300074;
	Wed,  7 Dec 2011 08:27:26 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=eKWpAkMD5C0PhmjAiJLXuMpw7qPRzqBrdV7j7tN72uuz
	xtgLO+ou8R69mwnEOdrnVsDhwR4Co7qB3KEAtcykokDUt36+o+mojuUl6s6bWBam
	t3PoFS/Y9fsRnp40cwyeSymjiruXOtXzb+dcLYwdrT2HKWFuwseSyiiHnYZ5lDA=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=j4EopAg7f9oWfqt8V0/exKoRb5Q=; b=URBJcddf
	xsFoisweAviXwRwdyURVIUMfG9W5tEgHeExXbpKG4mZS8drQ8ebJ6hNw4+6bWntS
	eeWGf9qP3khP4lMw0c+yFakJ32eXNaJqK+1hCVnISK1zuwE4cxcjgh2FK02oowNi
	o4xYuLQAfWFrQDkn7vTnz52VY9kmtgzWpGA=
Received: from webmail.lagarcavilla.org (ahfbbjcaiaae.dreamhost.com
	[75.119.208.4]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTPA id C9A83300072; 
	Wed,  7 Dec 2011 08:27:25 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP; Wed, 7 Dec 2011 08:27:26 -0800
Message-ID: <7faf6e5ab8aba046eae7e0302fc5cce0.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20111207132044.GB27309@aepfle.de>
References: <mailman.3332.1323083995.12970.xen-devel@lists.xensource.com>
	<f5cf6ad4704fe70f3130b832e530e8b0.squirrel@webmail.lagarcavilla.org>
	<20111205162016.GA13352@aepfle.de>
	<c9d4c394e8c6806edd1b735a43d60ab7.squirrel@webmail.lagarcavilla.org>
	<20111207132044.GB27309@aepfle.de>
Date: Wed, 7 Dec 2011 08:27:26 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Olaf Hering" <olaf@aepfle.de>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] mem_event: use wait queue when ring is full
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> On Mon, Dec 05, Andres Lagar-Cavilla wrote:
>
>> > On Mon, Dec 05, Andres Lagar-Cavilla wrote:
>> >
>> >> > +    med->bit = bit;
>> >> I think it's been asked before for this to have a more expressive
>> name.
>> >
>> > I have to recheck, AFAIK it was the mem_bit where mem_ is redundant.
>> how about pause_flag?
>
> I made this change in my patch.
>
>> > Before this patch, mem_event_unpause_vcpus() was used to resume
>> waiters
>> > for the ring itself and for room in the ring.
>> > Now there is mem_event_wake_waiters(), which indicates the ring is
>> > active, and there is mem_event_wake_requesters() which indicates the
>> > ring has room to place guest requests.
>>
>> I think that if there is no ring where one is expected, harsher actions
>> should happen. That is what we do in our patch. e.g.
>> p2m_mem_paging_populate -> no ring -> crash domain, or
>> p2m_mem_access_check -> access_required -> no ring -> crash domain.
>>
>> That would eliminate wake_waiters, methinks?
>
> In p2m_mem_paging_populate() a sanity check could be added. I think it
> would indicate bad p2mt state because nominate was called without ring.
> How else can a gfn enter paging state?
Definitely. Crash that domain. Maybe the pager crashed and burned, or quit
carelessly.
Andres
>
> Olaf
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 16:28:39 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 16: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.xensource.com>)
	id 1RYKLw-0000GP-Up; Wed, 07 Dec 2011 16:28:16 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RYKLw-0000Fl-77
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 16:28:16 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-14.tower-21.messagelabs.com!1323275247!7353016!1
X-Originating-IP: [208.97.132.66]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi42NiA9PiAxNTkxNQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26602 invoked from network); 7 Dec 2011 16:27:27 -0000
Received: from caiajhbdcagg.dreamhost.com (HELO homiemail-a21.g.dreamhost.com)
	(208.97.132.66) by server-14.tower-21.messagelabs.com with SMTP;
	7 Dec 2011 16:27:27 -0000
Received: from homiemail-a21.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTP id 5669D300074;
	Wed,  7 Dec 2011 08:27:26 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=eKWpAkMD5C0PhmjAiJLXuMpw7qPRzqBrdV7j7tN72uuz
	xtgLO+ou8R69mwnEOdrnVsDhwR4Co7qB3KEAtcykokDUt36+o+mojuUl6s6bWBam
	t3PoFS/Y9fsRnp40cwyeSymjiruXOtXzb+dcLYwdrT2HKWFuwseSyiiHnYZ5lDA=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=j4EopAg7f9oWfqt8V0/exKoRb5Q=; b=URBJcddf
	xsFoisweAviXwRwdyURVIUMfG9W5tEgHeExXbpKG4mZS8drQ8ebJ6hNw4+6bWntS
	eeWGf9qP3khP4lMw0c+yFakJ32eXNaJqK+1hCVnISK1zuwE4cxcjgh2FK02oowNi
	o4xYuLQAfWFrQDkn7vTnz52VY9kmtgzWpGA=
Received: from webmail.lagarcavilla.org (ahfbbjcaiaae.dreamhost.com
	[75.119.208.4]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTPA id C9A83300072; 
	Wed,  7 Dec 2011 08:27:25 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP; Wed, 7 Dec 2011 08:27:26 -0800
Message-ID: <7faf6e5ab8aba046eae7e0302fc5cce0.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20111207132044.GB27309@aepfle.de>
References: <mailman.3332.1323083995.12970.xen-devel@lists.xensource.com>
	<f5cf6ad4704fe70f3130b832e530e8b0.squirrel@webmail.lagarcavilla.org>
	<20111205162016.GA13352@aepfle.de>
	<c9d4c394e8c6806edd1b735a43d60ab7.squirrel@webmail.lagarcavilla.org>
	<20111207132044.GB27309@aepfle.de>
Date: Wed, 7 Dec 2011 08:27:26 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Olaf Hering" <olaf@aepfle.de>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] mem_event: use wait queue when ring is full
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> On Mon, Dec 05, Andres Lagar-Cavilla wrote:
>
>> > On Mon, Dec 05, Andres Lagar-Cavilla wrote:
>> >
>> >> > +    med->bit = bit;
>> >> I think it's been asked before for this to have a more expressive
>> name.
>> >
>> > I have to recheck, AFAIK it was the mem_bit where mem_ is redundant.
>> how about pause_flag?
>
> I made this change in my patch.
>
>> > Before this patch, mem_event_unpause_vcpus() was used to resume
>> waiters
>> > for the ring itself and for room in the ring.
>> > Now there is mem_event_wake_waiters(), which indicates the ring is
>> > active, and there is mem_event_wake_requesters() which indicates the
>> > ring has room to place guest requests.
>>
>> I think that if there is no ring where one is expected, harsher actions
>> should happen. That is what we do in our patch. e.g.
>> p2m_mem_paging_populate -> no ring -> crash domain, or
>> p2m_mem_access_check -> access_required -> no ring -> crash domain.
>>
>> That would eliminate wake_waiters, methinks?
>
> In p2m_mem_paging_populate() a sanity check could be added. I think it
> would indicate bad p2mt state because nominate was called without ring.
> How else can a gfn enter paging state?
Definitely. Crash that domain. Maybe the pager crashed and burned, or quit
carelessly.
Andres
>
> Olaf
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 16:29:19 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 16:29:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYKMd-0000M5-DJ; Wed, 07 Dec 2011 16:28:59 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RYKMb-0000LG-Kk
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 16:28:58 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1323275290!7310616!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjA3NQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6068 invoked from network); 7 Dec 2011 16:28:10 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Dec 2011 16:28:10 -0000
X-IronPort-AV: E=Sophos;i="4.71,314,1320624000"; 
   d="scan'208";a="9347120"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Dec 2011 16:28:00 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 7 Dec 2011
	16:28:00 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Wed, 7 Dec 2011 16:28:00 +0000
In-Reply-To: <1323108621-22654-13-git-send-email-ian.jackson@eu.citrix.com>
References: <1323108621-22654-1-git-send-email-ian.jackson@eu.citrix.com>
	<1323108621-22654-13-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323275280.2969.3.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 12/15] libxl: Use GC_INIT and GC_FREE
 everywhere
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2011-12-05 at 18:10 +0000, Ian Jackson wrote:
> Replace
>     libxl__gc gc = LIBXL_INIT_GC(ctx);
>     ...
>     libxl__free_all(&gc);
> with
>     GC_INIT(ctx);
>     ...
>     GC_FREE;

I suppose this really relates to the earlier patch which adds these
macros but wouldn't "GC_FREE();" be nicer?

> throughout with a couple of perl runes.
> 
> We must then adjust uses of the resulting gc for pointerness, which is
> mostly just replacing all occurrences of "&gc" with "gc".

BTW I really like this aspect of the change since one big annoyance when
making an exiting internal function into an external one (or vice versa)
is the need to frob all the uses of gc...

Ian.

>   Also a
> couple of unusual uses of LIBXL_INIT_GC needed to be fixed up by hand.
> 
> Here are those runes:
>  perl -i -pe 's/\Q    libxl__gc gc = LIBXL_INIT_GC(ctx);/    GC_INIT(ctx);/' tools/libxl/*.c
>  perl -i -pe 's/\Q    libxl__free_all(&gc);/    GC_FREE;/' tools/libxl/*.c
> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
> ---
>  tools/libxl/libxl.c            |  590 ++++++++++++++++++++--------------------
>  tools/libxl/libxl_bootloader.c |   14 +-
>  tools/libxl/libxl_create.c     |   12 +-
>  tools/libxl/libxl_dom.c        |   16 +-
>  tools/libxl/libxl_pci.c        |   34 ++--
>  tools/libxl/libxl_qmp.c        |   32 +-
>  tools/libxl/libxl_utils.c      |   36 ++--
>  7 files changed, 367 insertions(+), 367 deletions(-)
> 
> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> index 7488538..3a8cfe3 100644
> --- a/tools/libxl/libxl.c
> +++ b/tools/libxl/libxl.c
> @@ -232,19 +232,19 @@ int libxl__domain_rename(libxl__gc *gc, uint32_t domid,
>  int libxl_domain_rename(libxl_ctx *ctx, uint32_t domid,
>                          const char *old_name, const char *new_name)
>  {
> -    libxl__gc gc = LIBXL_INIT_GC(ctx);
> +    GC_INIT(ctx);
>      int rc;
> -    rc = libxl__domain_rename(&gc, domid, old_name, new_name, XBT_NULL);
> -    libxl__free_all(&gc);
> +    rc = libxl__domain_rename(gc, domid, old_name, new_name, XBT_NULL);
> +    GC_FREE;
>      return rc;
>  }
> 
>  int libxl_domain_resume(libxl_ctx *ctx, uint32_t domid)
>  {
> -    libxl__gc gc = LIBXL_INIT_GC(ctx);
> +    GC_INIT(ctx);
>      int rc = 0;
> 
> -    if (LIBXL__DOMAIN_IS_TYPE(&gc,  domid, HVM)) {
> +    if (LIBXL__DOMAIN_IS_TYPE(gc,  domid, HVM)) {
>          LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Called domain_resume on "
>                  "non-cooperative hvm domain %u", domid);
>          rc = ERROR_NI;
> @@ -264,7 +264,7 @@ int libxl_domain_resume(libxl_ctx *ctx, uint32_t domid)
>          rc = ERROR_FAIL;
>      }
>  out:
> -    libxl__free_all(&gc);
> +    GC_FREE;
>      return rc;
>  }
> 
> @@ -277,7 +277,7 @@ out:
>  int libxl_domain_preserve(libxl_ctx *ctx, uint32_t domid,
>                            libxl_domain_create_info *info, const char *name_suffix, libxl_uuid new_uuid)
>  {
> -    libxl__gc gc = LIBXL_INIT_GC(ctx);
> +    GC_INIT(ctx);
>      struct xs_permissions roperm[2];
>      xs_transaction_t t;
>      char *preserved_name;
> @@ -287,27 +287,27 @@ int libxl_domain_preserve(libxl_ctx *ctx, uint32_t domid,
> 
>      int rc;
> 
> -    preserved_name = libxl__sprintf(&gc, "%s%s", info->name, name_suffix);
> +    preserved_name = libxl__sprintf(gc, "%s%s", info->name, name_suffix);
>      if (!preserved_name) {
> -        libxl__free_all(&gc);
> +        GC_FREE;
>          return ERROR_NOMEM;
>      }
> 
> -    uuid_string = libxl__uuid2string(&gc, new_uuid);
> +    uuid_string = libxl__uuid2string(gc, new_uuid);
>      if (!uuid_string) {
> -        libxl__free_all(&gc);
> +        GC_FREE;
>          return ERROR_NOMEM;
>      }
> 
> -    dom_path = libxl__xs_get_dompath(&gc, domid);
> +    dom_path = libxl__xs_get_dompath(gc, domid);
>      if (!dom_path) {
> -        libxl__free_all(&gc);
> +        GC_FREE;
>          return ERROR_FAIL;
>      }
> 
> -    vm_path = libxl__sprintf(&gc, "/vm/%s", uuid_string);
> +    vm_path = libxl__sprintf(gc, "/vm/%s", uuid_string);
>      if (!vm_path) {
> -        libxl__free_all(&gc);
> +        GC_FREE;
>          return ERROR_FAIL;
>      }
> 
> @@ -323,20 +323,20 @@ int libxl_domain_preserve(libxl_ctx *ctx, uint32_t domid,
>      xs_mkdir(ctx->xsh, t, vm_path);
>      xs_set_permissions(ctx->xsh, t, vm_path, roperm, ARRAY_SIZE(roperm));
> 
> -    xs_write(ctx->xsh, t, libxl__sprintf(&gc, "%s/vm", dom_path), vm_path, strlen(vm_path));
> -    rc = libxl__domain_rename(&gc, domid, info->name, preserved_name, t);
> +    xs_write(ctx->xsh, t, libxl__sprintf(gc, "%s/vm", dom_path), vm_path, strlen(vm_path));
> +    rc = libxl__domain_rename(gc, domid, info->name, preserved_name, t);
>      if (rc) {
> -        libxl__free_all(&gc);
> +        GC_FREE;
>          return rc;
>      }
> 
> -    xs_write(ctx->xsh, t, libxl__sprintf(&gc, "%s/uuid", vm_path), uuid_string, strlen(uuid_string));
> +    xs_write(ctx->xsh, t, libxl__sprintf(gc, "%s/uuid", vm_path), uuid_string, strlen(uuid_string));
> 
>      if (!xs_transaction_end(ctx->xsh, t, 0))
>          if (errno == EAGAIN)
>              goto retry_transaction;
> 
> -    libxl__free_all(&gc);
> +    GC_FREE;
>      return 0;
>  }
> 
> @@ -478,16 +478,16 @@ libxl_vminfo * libxl_list_vm(libxl_ctx *ctx, int *nb_vm)
>  int libxl_domain_suspend(libxl_ctx *ctx, libxl_domain_suspend_info *info,
>                           uint32_t domid, int fd)
>  {
> -    libxl__gc gc = LIBXL_INIT_GC(ctx);
> -    libxl_domain_type type = libxl__domain_type(&gc, domid);
> +    GC_INIT(ctx);
> +    libxl_domain_type type = libxl__domain_type(gc, domid);
>      int live = info != NULL && info->flags & XL_SUSPEND_LIVE;
>      int debug = info != NULL && info->flags & XL_SUSPEND_DEBUG;
>      int rc = 0;
> 
> -    rc = libxl__domain_suspend_common(&gc, domid, fd, type, live, debug);
> +    rc = libxl__domain_suspend_common(gc, domid, fd, type, live, debug);
>      if (!rc && type == LIBXL_DOMAIN_TYPE_HVM)
> -        rc = libxl__domain_save_device_model(&gc, domid, fd);
> -    libxl__free_all(&gc);
> +        rc = libxl__domain_save_device_model(gc, domid, fd);
> +    GC_FREE;
>      return rc;
>  }
> 
> @@ -517,17 +517,17 @@ int libxl_domain_core_dump(libxl_ctx *ctx, uint32_t domid,
> 
>  int libxl_domain_unpause(libxl_ctx *ctx, uint32_t domid)
>  {
> -    libxl__gc gc = LIBXL_INIT_GC(ctx);
> +    GC_INIT(ctx);
>      char *path;
>      char *state;
>      int ret, rc = 0;
> 
> -    if (LIBXL__DOMAIN_IS_TYPE(&gc,  domid, HVM)) {
> -        path = libxl__sprintf(&gc, "/local/domain/0/device-model/%d/state", domid);
> -        state = libxl__xs_read(&gc, XBT_NULL, path);
> +    if (LIBXL__DOMAIN_IS_TYPE(gc,  domid, HVM)) {
> +        path = libxl__sprintf(gc, "/local/domain/0/device-model/%d/state", domid);
> +        state = libxl__xs_read(gc, XBT_NULL, path);
>          if (state != NULL && !strcmp(state, "paused")) {
> -            libxl__xs_write(&gc, XBT_NULL, libxl__sprintf(&gc, "/local/domain/0/device-model/%d/command", domid), "continue");
> -            libxl__wait_for_device_model(&gc, domid, "running",
> +            libxl__xs_write(gc, XBT_NULL, libxl__sprintf(gc, "/local/domain/0/device-model/%d/command", domid), "continue");
> +            libxl__wait_for_device_model(gc, domid, "running",
>                                           NULL, NULL, NULL);
>          }
>      }
> @@ -536,7 +536,7 @@ int libxl_domain_unpause(libxl_ctx *ctx, uint32_t domid)
>          LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "unpausing domain %d", domid);
>          rc = ERROR_FAIL;
>      }
> -    libxl__free_all(&gc);
> +    GC_FREE;
>      return rc;
>  }
> 
> @@ -550,42 +550,42 @@ static char *req_table[] = {
> 
>  int libxl_domain_shutdown(libxl_ctx *ctx, uint32_t domid, int req)
>  {
> -    libxl__gc gc = LIBXL_INIT_GC(ctx);
> +    GC_INIT(ctx);
>      char *shutdown_path;
>      char *dom_path;
> 
>      if (req > ARRAY_SIZE(req_table)) {
> -        libxl__free_all(&gc);
> +        GC_FREE;
>          return ERROR_INVAL;
>      }
> 
> -    dom_path = libxl__xs_get_dompath(&gc, domid);
> +    dom_path = libxl__xs_get_dompath(gc, domid);
>      if (!dom_path) {
> -        libxl__free_all(&gc);
> +        GC_FREE;
>          return ERROR_FAIL;
>      }
> 
> -    if (LIBXL__DOMAIN_IS_TYPE(&gc,  domid, HVM)) {
> +    if (LIBXL__DOMAIN_IS_TYPE(gc,  domid, HVM)) {
>          unsigned long pvdriver = 0;
>          int ret;
>          ret = xc_get_hvm_param(ctx->xch, domid, HVM_PARAM_CALLBACK_IRQ, &pvdriver);
>          if (ret<0) {
>              LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "getting HVM callback IRQ");
> -            libxl__free_all(&gc);
> +            GC_FREE;
>              return ERROR_FAIL;
>          }
>          if (!pvdriver) {
>              LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "HVM domain without PV drivers:"
>                         " graceful shutdown not possible, use destroy");
> -            libxl__free_all(&gc);
> +            GC_FREE;
>              return ERROR_FAIL;
>          }
>      }
> 
> -    shutdown_path = libxl__sprintf(&gc, "%s/control/shutdown", dom_path);
> +    shutdown_path = libxl__sprintf(gc, "%s/control/shutdown", dom_path);
>      xs_write(ctx->xsh, XBT_NULL, shutdown_path, req_table[req], strlen(req_table[req]));
> 
> -    libxl__free_all(&gc);
> +    GC_FREE;
>      return 0;
>  }
> 
> @@ -607,7 +607,7 @@ int libxl_wait_for_domain_death(libxl_ctx *ctx, uint32_t domid, libxl_waiter *wa
> 
>  int libxl_wait_for_disk_ejects(libxl_ctx *ctx, uint32_t guest_domid, libxl_device_disk *disks, int num_disks, libxl_waiter *waiter)
>  {
> -    libxl__gc gc = LIBXL_INIT_GC(ctx);
> +    GC_INIT(ctx);
>      int i, rc = -1;
>      uint32_t domid = libxl_get_stubdom_id(ctx, guest_domid);
> 
> @@ -616,7 +616,7 @@ int libxl_wait_for_disk_ejects(libxl_ctx *ctx, uint32_t guest_domid, libxl_devic
> 
>      for (i = 0; i < num_disks; i++) {
>          if (asprintf(&(waiter[i].path), "%s/device/vbd/%d/eject",
> -                     libxl__xs_get_dompath(&gc, domid),
> +                     libxl__xs_get_dompath(gc, domid),
>                       libxl__device_disk_dev_number(disks[i].vdev,
>                                                     NULL, NULL)) < 0)
>              goto out;
> @@ -626,7 +626,7 @@ int libxl_wait_for_disk_ejects(libxl_ctx *ctx, uint32_t guest_domid, libxl_devic
>      }
>      rc = 0;
>  out:
> -    libxl__free_all(&gc);
> +    GC_FREE;
>      return rc;
>  }
> 
> @@ -680,22 +680,22 @@ int libxl_event_get_domain_death_info(libxl_ctx *ctx, uint32_t domid, libxl_even
> 
>  int libxl_event_get_disk_eject_info(libxl_ctx *ctx, uint32_t domid, libxl_event *event, libxl_device_disk *disk)
>  {
> -    libxl__gc gc = LIBXL_INIT_GC(ctx);
> +    GC_INIT(ctx);
>      char *path;
>      char *backend;
>      char *value;
>      char backend_type[BACKEND_STRING_SIZE+1];
> 
> -    value = libxl__xs_read(&gc, XBT_NULL, event->path);
> +    value = libxl__xs_read(gc, XBT_NULL, event->path);
> 
>      if (!value || strcmp(value,  "eject")) {
> -        libxl__free_all(&gc);
> +        GC_FREE;
>          return 0;
>      }
> 
>      path = strdup(event->path);
>      path[strlen(path) - 6] = '\0';
> -    backend = libxl__xs_read(&gc, XBT_NULL, libxl__sprintf(&gc, "%s/backend", path));
> +    backend = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/backend", path));
> 
>      sscanf(backend,
>              "/local/domain/%d/backend/%" TOSTRING(BACKEND_STRING_SIZE) "[a-z]/%*d/%*d",
> @@ -711,19 +711,19 @@ int libxl_event_get_disk_eject_info(libxl_ctx *ctx, uint32_t domid, libxl_event
>      disk->pdev_path = strdup("");
>      disk->format = LIBXL_DISK_FORMAT_EMPTY;
>      /* this value is returned to the user: do not free right away */
> -    disk->vdev = xs_read(ctx->xsh, XBT_NULL, libxl__sprintf(&gc, "%s/dev", backend), NULL);
> +    disk->vdev = xs_read(ctx->xsh, XBT_NULL, libxl__sprintf(gc, "%s/dev", backend), NULL);
>      disk->removable = 1;
>      disk->readwrite = 0;
>      disk->is_cdrom = 1;
> 
>      free(path);
> -    libxl__free_all(&gc);
> +    GC_FREE;
>      return 1;
>  }
> 
>  int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid, int force)
>  {
> -    libxl__gc gc = LIBXL_INIT_GC(ctx);
> +    GC_INIT(ctx);
>      libxl_dominfo dominfo;
>      char *dom_path;
>      char *vm_path;
> @@ -740,40 +740,40 @@ int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid, int force)
>          return rc;
>      }
> 
> -    switch (libxl__domain_type(&gc, domid)) {
> +    switch (libxl__domain_type(gc, domid)) {
>      case LIBXL_DOMAIN_TYPE_HVM:
>          dm_present = 1;
>          break;
>      case LIBXL_DOMAIN_TYPE_PV:
> -        pid = libxl__xs_read(&gc, XBT_NULL, libxl__sprintf(&gc, "/local/domain/%d/image/device-model-pid", domid));
> +        pid = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "/local/domain/%d/image/device-model-pid", domid));
>          dm_present = (pid != NULL);
>          break;
>      default:
>          abort();
>      }
> 
> -    dom_path = libxl__xs_get_dompath(&gc, domid);
> +    dom_path = libxl__xs_get_dompath(gc, domid);
>      if (!dom_path) {
>          rc = ERROR_FAIL;
>          goto out;
>      }
> 
> -    if (libxl__device_pci_destroy_all(&gc, domid) < 0)
> +    if (libxl__device_pci_destroy_all(gc, domid) < 0)
>          LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "pci shutdown failed for domid %d", domid);
>      rc = xc_domain_pause(ctx->xch, domid);
>      if (rc < 0) {
>          LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, rc, "xc_domain_pause failed for %d", domid);
>      }
>      if (dm_present) {
> -        if (libxl__destroy_device_model(&gc, domid) < 0)
> +        if (libxl__destroy_device_model(gc, domid) < 0)
>              LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "libxl__destroy_device_model failed for %d", domid);
> 
> -        libxl__qmp_cleanup(&gc, domid);
> +        libxl__qmp_cleanup(gc, domid);
>      }
> -    if (libxl__devices_destroy(&gc, domid, force) < 0)
> +    if (libxl__devices_destroy(gc, domid, force) < 0)
>          LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "libxl_devices_dispose failed for %d", domid);
> 
> -    vm_path = libxl__xs_read(&gc, XBT_NULL, libxl__sprintf(&gc, "%s/vm", dom_path));
> +    vm_path = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/vm", dom_path));
>      if (vm_path)
>          if (!xs_rm(ctx->xsh, XBT_NULL, vm_path))
>              LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "xs_rm failed for %s", vm_path);
> @@ -781,9 +781,9 @@ int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid, int force)
>      if (!xs_rm(ctx->xsh, XBT_NULL, dom_path))
>          LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "xs_rm failed for %s", dom_path);
> 
> -    xs_rm(ctx->xsh, XBT_NULL, libxl__xs_libxl_path(&gc, domid));
> +    xs_rm(ctx->xsh, XBT_NULL, libxl__xs_libxl_path(gc, domid));
> 
> -    libxl__userdata_destroyall(&gc, domid);
> +    libxl__userdata_destroyall(gc, domid);
> 
>      rc = xc_domain_destroy(ctx->xch, domid);
>      if (rc < 0) {
> @@ -793,16 +793,16 @@ int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid, int force)
>      }
>      rc = 0;
>  out:
> -    libxl__free_all(&gc);
> +    GC_FREE;
>      return rc;
>  }
> 
>  int libxl_console_exec(libxl_ctx *ctx, uint32_t domid, int cons_num, libxl_console_type type)
>  {
> -    libxl__gc gc = LIBXL_INIT_GC(ctx);
> -    char *p = libxl__sprintf(&gc, "%s/xenconsole", libxl_private_bindir_path());
> -    char *domid_s = libxl__sprintf(&gc, "%d", domid);
> -    char *cons_num_s = libxl__sprintf(&gc, "%d", cons_num);
> +    GC_INIT(ctx);
> +    char *p = libxl__sprintf(gc, "%s/xenconsole", libxl_private_bindir_path());
> +    char *domid_s = libxl__sprintf(gc, "%d", domid);
> +    char *cons_num_s = libxl__sprintf(gc, "%d", cons_num);
>      char *cons_type_s;
> 
>      switch (type) {
> @@ -819,20 +819,20 @@ int libxl_console_exec(libxl_ctx *ctx, uint32_t domid, int cons_num, libxl_conso
>      execl(p, p, domid_s, "--num", cons_num_s, "--type", cons_type_s, (void *)NULL);
> 
>  out:
> -    libxl__free_all(&gc);
> +    GC_FREE;
>      return ERROR_FAIL;
>  }
> 
>  int libxl_primary_console_exec(libxl_ctx *ctx, uint32_t domid_vm)
>  {
> -    libxl__gc gc = LIBXL_INIT_GC(ctx);
> +    GC_INIT(ctx);
>      uint32_t stubdomid = libxl_get_stubdom_id(ctx, domid_vm);
>      int rc;
>      if (stubdomid)
>          rc = libxl_console_exec(ctx, stubdomid,
>                                  STUBDOM_CONSOLE_SERIAL, LIBXL_CONSOLE_TYPE_PV);
>      else {
> -        switch (libxl__domain_type(&gc, domid_vm)) {
> +        switch (libxl__domain_type(gc, domid_vm)) {
>          case LIBXL_DOMAIN_TYPE_HVM:
>              rc = libxl_console_exec(ctx, domid_vm, 0, LIBXL_CONSOLE_TYPE_SERIAL);
>              break;
> @@ -843,13 +843,13 @@ int libxl_primary_console_exec(libxl_ctx *ctx, uint32_t domid_vm)
>              abort();
>          }
>      }
> -    libxl__free_all(&gc);
> +    GC_FREE;
>      return rc;
>  }
> 
>  int libxl_vncviewer_exec(libxl_ctx *ctx, uint32_t domid, int autopass)
>  {
> -    libxl__gc gc = LIBXL_INIT_GC(ctx);
> +    GC_INIT(ctx);
>      const char *vnc_port;
>      const char *vnc_listen = NULL, *vnc_pass = NULL;
>      int port = 0, autopass_fd = -1;
> @@ -860,19 +860,19 @@ int libxl_vncviewer_exec(libxl_ctx *ctx, uint32_t domid, int autopass)
>          NULL,
>      };
> 
> -    vnc_port = libxl__xs_read(&gc, XBT_NULL,
> -                            libxl__sprintf(&gc,
> +    vnc_port = libxl__xs_read(gc, XBT_NULL,
> +                            libxl__sprintf(gc,
>                              "/local/domain/%d/console/vnc-port", domid));
>      if ( vnc_port )
>          port = atoi(vnc_port) - 5900;
> 
> -    vnc_listen = libxl__xs_read(&gc, XBT_NULL,
> -                                libxl__sprintf(&gc,
> +    vnc_listen = libxl__xs_read(gc, XBT_NULL,
> +                                libxl__sprintf(gc,
>                              "/local/domain/%d/console/vnc-listen", domid));
> 
>      if ( autopass )
> -        vnc_pass = libxl__xs_read(&gc, XBT_NULL,
> -                                  libxl__sprintf(&gc,
> +        vnc_pass = libxl__xs_read(gc, XBT_NULL,
> +                                  libxl__sprintf(gc,
>                              "/local/domain/%d/console/vnc-pass", domid));
> 
>      if ( NULL == vnc_listen )
> @@ -881,7 +881,7 @@ int libxl_vncviewer_exec(libxl_ctx *ctx, uint32_t domid, int autopass)
>      if ( (vnc_bin = getenv("VNCVIEWER")) )
>          args[0] = vnc_bin;
> 
> -    args[1] = libxl__sprintf(&gc, "%s:%d", vnc_listen, port);
> +    args[1] = libxl__sprintf(gc, "%s:%d", vnc_listen, port);
> 
>      if ( vnc_pass ) {
>          char tmpname[] = "/tmp/vncautopass.XXXXXX";
> @@ -916,7 +916,7 @@ int libxl_vncviewer_exec(libxl_ctx *ctx, uint32_t domid, int autopass)
>      abort();
> 
>   x_fail:
> -    libxl__free_all(&gc);
> +    GC_FREE;
>      return ERROR_FAIL;
>  }
> 
> @@ -970,17 +970,17 @@ static int libxl__device_from_disk(libxl__gc *gc, uint32_t domid,
> 
>  int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *disk)
>  {
> -    libxl__gc gc = LIBXL_INIT_GC(ctx);
> +    GC_INIT(ctx);
>      flexarray_t *front;
>      flexarray_t *back;
>      char *dev;
>      libxl__device device;
>      int major, minor, rc;
> 
> -    rc = libxl__device_disk_set_backend(&gc, disk);
> +    rc = libxl__device_disk_set_backend(gc, disk);
>      if (rc) goto out;
> 
> -    rc = libxl__device_disk_set_backend(&gc, disk);
> +    rc = libxl__device_disk_set_backend(gc, disk);
>      if (rc) goto out;
> 
>      front = flexarray_make(16, 1);
> @@ -1001,7 +1001,7 @@ int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *dis
>          goto out_free;
>      }
> 
> -    rc = libxl__device_from_disk(&gc, domid, disk, &device);
> +    rc = libxl__device_from_disk(gc, domid, disk, &device);
>      if (rc != 0) {
>          LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Invalid or unsupported"
>                 " virtual disk identifier %s", disk->vdev);
> @@ -1014,7 +1014,7 @@ int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *dis
>      do_backend_phy:
>              libxl__device_physdisk_major_minor(dev, &major, &minor);
>              flexarray_append(back, "physical-device");
> -            flexarray_append(back, libxl__sprintf(&gc, "%x:%x", major, minor));
> +            flexarray_append(back, libxl__sprintf(gc, "%x:%x", major, minor));
> 
>              flexarray_append(back, "params");
>              flexarray_append(back, dev);
> @@ -1022,13 +1022,13 @@ int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *dis
>              assert(device.backend_kind == LIBXL__DEVICE_KIND_VBD);
>              break;
>          case LIBXL_DISK_BACKEND_TAP:
> -            dev = libxl__blktap_devpath(&gc, disk->pdev_path, disk->format);
> +            dev = libxl__blktap_devpath(gc, disk->pdev_path, disk->format);
>              if (!dev) {
>                  rc = ERROR_FAIL;
>                  goto out_free;
>              }
>              flexarray_append(back, "tapdisk-params");
> -            flexarray_append(back, libxl__sprintf(&gc, "%s:%s",
> +            flexarray_append(back, libxl__sprintf(gc, "%s:%s",
>                  libxl__device_disk_string_of_format(disk->format),
>                  disk->pdev_path));
> 
> @@ -1036,7 +1036,7 @@ int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *dis
>              goto do_backend_phy;
>          case LIBXL_DISK_BACKEND_QDISK:
>              flexarray_append(back, "params");
> -            flexarray_append(back, libxl__sprintf(&gc, "%s:%s",
> +            flexarray_append(back, libxl__sprintf(gc, "%s:%s",
>                            libxl__device_disk_string_of_format(disk->format), disk->pdev_path));
>              assert(device.backend_kind == LIBXL__DEVICE_KIND_QDISK);
>              break;
> @@ -1047,15 +1047,15 @@ int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *dis
>      }
> 
>      flexarray_append(back, "frontend-id");
> -    flexarray_append(back, libxl__sprintf(&gc, "%d", domid));
> +    flexarray_append(back, libxl__sprintf(gc, "%d", domid));
>      flexarray_append(back, "online");
>      flexarray_append(back, "1");
>      flexarray_append(back, "removable");
> -    flexarray_append(back, libxl__sprintf(&gc, "%d", (disk->removable) ? 1 : 0));
> +    flexarray_append(back, libxl__sprintf(gc, "%d", (disk->removable) ? 1 : 0));
>      flexarray_append(back, "bootable");
> -    flexarray_append(back, libxl__sprintf(&gc, "%d", 1));
> +    flexarray_append(back, libxl__sprintf(gc, "%d", 1));
>      flexarray_append(back, "state");
> -    flexarray_append(back, libxl__sprintf(&gc, "%d", 1));
> +    flexarray_append(back, libxl__sprintf(gc, "%d", 1));
>      flexarray_append(back, "dev");
>      flexarray_append(back, disk->vdev);
>      flexarray_append(back, "type");
> @@ -1066,17 +1066,17 @@ int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *dis
>      flexarray_append(back, disk->is_cdrom ? "cdrom" : "disk");
> 
>      flexarray_append(front, "backend-id");
> -    flexarray_append(front, libxl__sprintf(&gc, "%d", disk->backend_domid));
> +    flexarray_append(front, libxl__sprintf(gc, "%d", disk->backend_domid));
>      flexarray_append(front, "state");
> -    flexarray_append(front, libxl__sprintf(&gc, "%d", 1));
> +    flexarray_append(front, libxl__sprintf(gc, "%d", 1));
>      flexarray_append(front, "virtual-device");
> -    flexarray_append(front, libxl__sprintf(&gc, "%d", device.devid));
> +    flexarray_append(front, libxl__sprintf(gc, "%d", device.devid));
>      flexarray_append(front, "device-type");
>      flexarray_append(front, disk->is_cdrom ? "cdrom" : "disk");
> 
> -    libxl__device_generic_add(&gc, &device,
> -                             libxl__xs_kvs_of_flexarray(&gc, back, back->count),
> -                             libxl__xs_kvs_of_flexarray(&gc, front, front->count));
> +    libxl__device_generic_add(gc, &device,
> +                             libxl__xs_kvs_of_flexarray(gc, back, back->count),
> +                             libxl__xs_kvs_of_flexarray(gc, front, front->count));
> 
>      rc = 0;
> 
> @@ -1084,39 +1084,39 @@ out_free:
>      flexarray_free(back);
>      flexarray_free(front);
>  out:
> -    libxl__free_all(&gc);
> +    GC_FREE;
>      return rc;
>  }
> 
>  int libxl_device_disk_remove(libxl_ctx *ctx, uint32_t domid,
>                               libxl_device_disk *disk)
>  {
> -    libxl__gc gc = LIBXL_INIT_GC(ctx);
> +    GC_INIT(ctx);
>      libxl__device device;
>      int rc;
> 
> -    rc = libxl__device_from_disk(&gc, domid, disk, &device);
> +    rc = libxl__device_from_disk(gc, domid, disk, &device);
>      if (rc != 0) goto out;
> 
> -    rc = libxl__device_remove(&gc, &device, 1);
> +    rc = libxl__device_remove(gc, &device, 1);
>  out:
> -    libxl__free_all(&gc);
> +    GC_FREE;
>      return rc;
>  }
> 
>  int libxl_device_disk_destroy(libxl_ctx *ctx, uint32_t domid,
>                                libxl_device_disk *disk)
>  {
> -    libxl__gc gc = LIBXL_INIT_GC(ctx);
> +    GC_INIT(ctx);
>      libxl__device device;
>      int rc;
> 
> -    rc = libxl__device_from_disk(&gc, domid, disk, &device);
> +    rc = libxl__device_from_disk(gc, domid, disk, &device);
>      if (rc != 0) goto out;
> 
> -    rc = libxl__device_destroy(&gc, &device);
> +    rc = libxl__device_destroy(gc, &device);
>  out:
> -    libxl__free_all(&gc);
> +    GC_FREE;
>      return rc;
>  }
> 
> @@ -1168,27 +1168,27 @@ static void libxl__device_disk_from_xs_be(libxl__gc *gc,
>  int libxl_devid_to_device_disk(libxl_ctx *ctx, uint32_t domid,
>                                 int devid, libxl_device_disk *disk)
>  {
> -    libxl__gc gc = LIBXL_INIT_GC(ctx);
> +    GC_INIT(ctx);
>      char *dompath, *path;
>      int rc = ERROR_FAIL;
> 
>      libxl_device_disk_init(ctx, disk);
> 
> -    dompath = libxl__xs_get_dompath(&gc, domid);
> +    dompath = libxl__xs_get_dompath(gc, domid);
>      if (!dompath) {
>          goto out;
>      }
> -    path = libxl__xs_read(&gc, XBT_NULL,
> -                          libxl__sprintf(&gc, "%s/device/vbd/%d/backend",
> +    path = libxl__xs_read(gc, XBT_NULL,
> +                          libxl__sprintf(gc, "%s/device/vbd/%d/backend",
>                                           dompath, devid));
>      if (!path)
>          goto out;
> 
> -    libxl__device_disk_from_xs_be(&gc, path, disk);
> +    libxl__device_disk_from_xs_be(gc, path, disk);
> 
>      rc = 0;
>  out:
> -    libxl__free_all(&gc);
> +    GC_FREE;
>      return rc;
>  }
> 
> @@ -1228,22 +1228,22 @@ static int libxl__append_disk_list_of_type(libxl__gc *gc,
> 
>  libxl_device_disk *libxl_device_disk_list(libxl_ctx *ctx, uint32_t domid, int *num)
>  {
> -    libxl__gc gc = LIBXL_INIT_GC(ctx);
> +    GC_INIT(ctx);
>      libxl_device_disk *disks = NULL;
>      int rc;
> 
>      *num = 0;
> 
> -    rc = libxl__append_disk_list_of_type(&gc, domid, "vbd", &disks, num);
> +    rc = libxl__append_disk_list_of_type(gc, domid, "vbd", &disks, num);
>      if (rc) goto out_err;
> 
> -    rc = libxl__append_disk_list_of_type(&gc, domid, "tap", &disks, num);
> +    rc = libxl__append_disk_list_of_type(gc, domid, "tap", &disks, num);
>      if (rc) goto out_err;
> 
> -    rc = libxl__append_disk_list_of_type(&gc, domid, "qdisk", &disks, num);
> +    rc = libxl__append_disk_list_of_type(gc, domid, "qdisk", &disks, num);
>      if (rc) goto out_err;
> 
> -    libxl__free_all(&gc);
> +    GC_FREE;
>      return disks;
> 
>  out_err:
> @@ -1259,35 +1259,35 @@ out_err:
>  int libxl_device_disk_getinfo(libxl_ctx *ctx, uint32_t domid,
>                                libxl_device_disk *disk, libxl_diskinfo *diskinfo)
>  {
> -    libxl__gc gc = LIBXL_INIT_GC(ctx);
> +    GC_INIT(ctx);
>      char *dompath, *diskpath;
>      char *val;
> 
> -    dompath = libxl__xs_get_dompath(&gc, domid);
> +    dompath = libxl__xs_get_dompath(gc, domid);
>      diskinfo->devid = libxl__device_disk_dev_number(disk->vdev, NULL, NULL);
> 
>      /* tap devices entries in xenstore are written as vbd devices. */
> -    diskpath = libxl__sprintf(&gc, "%s/device/vbd/%d", dompath, diskinfo->devid);
> +    diskpath = libxl__sprintf(gc, "%s/device/vbd/%d", dompath, diskinfo->devid);
>      diskinfo->backend = xs_read(ctx->xsh, XBT_NULL,
> -                                libxl__sprintf(&gc, "%s/backend", diskpath), NULL);
> +                                libxl__sprintf(gc, "%s/backend", diskpath), NULL);
>      if (!diskinfo->backend) {
> -        libxl__free_all(&gc);
> +        GC_FREE;
>          return ERROR_FAIL;
>      }
> -    val = libxl__xs_read(&gc, XBT_NULL, libxl__sprintf(&gc, "%s/backend-id", diskpath));
> +    val = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/backend-id", diskpath));
>      diskinfo->backend_id = val ? strtoul(val, NULL, 10) : -1;
> -    val = libxl__xs_read(&gc, XBT_NULL, libxl__sprintf(&gc, "%s/state", diskpath));
> +    val = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/state", diskpath));
>      diskinfo->state = val ? strtoul(val, NULL, 10) : -1;
> -    val = libxl__xs_read(&gc, XBT_NULL, libxl__sprintf(&gc, "%s/event-channel", diskpath));
> +    val = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/event-channel", diskpath));
>      diskinfo->evtch = val ? strtoul(val, NULL, 10) : -1;
> -    val = libxl__xs_read(&gc, XBT_NULL, libxl__sprintf(&gc, "%s/ring-ref", diskpath));
> +    val = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/ring-ref", diskpath));
>      diskinfo->rref = val ? strtoul(val, NULL, 10) : -1;
>      diskinfo->frontend = xs_read(ctx->xsh, XBT_NULL,
> -                                 libxl__sprintf(&gc, "%s/frontend", diskinfo->backend), NULL);
> -    val = libxl__xs_read(&gc, XBT_NULL, libxl__sprintf(&gc, "%s/frontend-id", diskinfo->backend));
> +                                 libxl__sprintf(gc, "%s/frontend", diskinfo->backend), NULL);
> +    val = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/frontend-id", diskinfo->backend));
>      diskinfo->frontend_id = val ? strtoul(val, NULL, 10) : -1;
> 
> -    libxl__free_all(&gc);
> +    GC_FREE;
>      return 0;
>  }
> 
> @@ -1331,12 +1331,12 @@ out:
> 
>  char * libxl_device_disk_local_attach(libxl_ctx *ctx, libxl_device_disk *disk)
>  {
> -    libxl__gc gc = LIBXL_INIT_GC(ctx);
> +    GC_INIT(ctx);
>      char *dev = NULL;
>      char *ret = NULL;
>      int rc;
> 
> -    rc = libxl__device_disk_set_backend(&gc, disk);
> +    rc = libxl__device_disk_set_backend(gc, disk);
>      if (rc) goto out;
> 
>      switch (disk->backend) {
> @@ -1355,7 +1355,7 @@ char * libxl_device_disk_local_attach(libxl_ctx *ctx, libxl_device_disk *disk)
>                  dev = disk->pdev_path;
>                  break;
>              case LIBXL_DISK_FORMAT_VHD:
> -                dev = libxl__blktap_devpath(&gc, disk->pdev_path,
> +                dev = libxl__blktap_devpath(gc, disk->pdev_path,
>                                              disk->format);
>                  break;
>              case LIBXL_DISK_FORMAT_QCOW:
> @@ -1386,7 +1386,7 @@ char * libxl_device_disk_local_attach(libxl_ctx *ctx, libxl_device_disk *disk)
>   out:
>      if (dev != NULL)
>          ret = strdup(dev);
> -    libxl__free_all(&gc);
> +    GC_FREE;
>      return ret;
>  }
> 
> @@ -1448,7 +1448,7 @@ static int libxl__device_from_nic(libxl__gc *gc, uint32_t domid,
> 
>  int libxl_device_nic_add(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic)
>  {
> -    libxl__gc gc = LIBXL_INIT_GC(ctx);
> +    GC_INIT(ctx);
>      flexarray_t *front;
>      flexarray_t *back;
>      libxl__device device;
> @@ -1467,59 +1467,59 @@ int libxl_device_nic_add(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic)
>      }
> 
>      if (nic->devid == -1) {
> -        if (!(dompath = libxl__xs_get_dompath(&gc, domid))) {
> +        if (!(dompath = libxl__xs_get_dompath(gc, domid))) {
>              rc = ERROR_FAIL;
>              goto out_free;
>          }
> -        if (!(l = libxl__xs_directory(&gc, XBT_NULL,
> -                                     libxl__sprintf(&gc, "%s/device/vif", dompath), &nb))) {
> +        if (!(l = libxl__xs_directory(gc, XBT_NULL,
> +                                     libxl__sprintf(gc, "%s/device/vif", dompath), &nb))) {
>              nic->devid = 0;
>          } else {
>              nic->devid = strtoul(l[nb - 1], NULL, 10) + 1;
>          }
>      }
> 
> -    rc = libxl__device_from_nic(&gc, domid, nic, &device);
> +    rc = libxl__device_from_nic(gc, domid, nic, &device);
>      if ( rc != 0 ) goto out_free;
> 
>      flexarray_append(back, "frontend-id");
> -    flexarray_append(back, libxl__sprintf(&gc, "%d", domid));
> +    flexarray_append(back, libxl__sprintf(gc, "%d", domid));
>      flexarray_append(back, "online");
>      flexarray_append(back, "1");
>      flexarray_append(back, "state");
> -    flexarray_append(back, libxl__sprintf(&gc, "%d", 1));
> +    flexarray_append(back, libxl__sprintf(gc, "%d", 1));
>      if (nic->script) {
>          flexarray_append(back, "script");
>          flexarray_append(back, nic->script[0]=='/' ? nic->script
> -                         : libxl__sprintf(&gc, "%s/%s",
> +                         : libxl__sprintf(gc, "%s/%s",
>                                            libxl_xen_script_dir_path(),
>                                            nic->script));
>      }
>      flexarray_append(back, "mac");
> -    flexarray_append(back,libxl__sprintf(&gc,
> +    flexarray_append(back,libxl__sprintf(gc,
>                                      LIBXL_MAC_FMT, LIBXL_MAC_BYTES(nic->mac)));
>      if (nic->ip) {
>          flexarray_append(back, "ip");
> -        flexarray_append(back, libxl__strdup(&gc, nic->ip));
> +        flexarray_append(back, libxl__strdup(gc, nic->ip));
>      }
> 
>      flexarray_append(back, "bridge");
> -    flexarray_append(back, libxl__strdup(&gc, nic->bridge));
> +    flexarray_append(back, libxl__strdup(gc, nic->bridge));
>      flexarray_append(back, "handle");
> -    flexarray_append(back, libxl__sprintf(&gc, "%d", nic->devid));
> +    flexarray_append(back, libxl__sprintf(gc, "%d", nic->devid));
> 
>      flexarray_append(front, "backend-id");
> -    flexarray_append(front, libxl__sprintf(&gc, "%d", nic->backend_domid));
> +    flexarray_append(front, libxl__sprintf(gc, "%d", nic->backend_domid));
>      flexarray_append(front, "state");
> -    flexarray_append(front, libxl__sprintf(&gc, "%d", 1));
> +    flexarray_append(front, libxl__sprintf(gc, "%d", 1));
>      flexarray_append(front, "handle");
> -    flexarray_append(front, libxl__sprintf(&gc, "%d", nic->devid));
> +    flexarray_append(front, libxl__sprintf(gc, "%d", nic->devid));
>      flexarray_append(front, "mac");
> -    flexarray_append(front, libxl__sprintf(&gc,
> +    flexarray_append(front, libxl__sprintf(gc,
>                                      LIBXL_MAC_FMT, LIBXL_MAC_BYTES(nic->mac)));
> -    libxl__device_generic_add(&gc, &device,
> -                             libxl__xs_kvs_of_flexarray(&gc, back, back->count),
> -                             libxl__xs_kvs_of_flexarray(&gc, front, front->count));
> +    libxl__device_generic_add(gc, &device,
> +                             libxl__xs_kvs_of_flexarray(gc, back, back->count),
> +                             libxl__xs_kvs_of_flexarray(gc, front, front->count));
> 
>      /* FIXME: wait for plug */
>      rc = 0;
> @@ -1527,39 +1527,39 @@ out_free:
>      flexarray_free(back);
>      flexarray_free(front);
>  out:
> -    libxl__free_all(&gc);
> +    GC_FREE;
>      return rc;
>  }
> 
>  int libxl_device_nic_remove(libxl_ctx *ctx, uint32_t domid,
>                              libxl_device_nic *nic)
>  {
> -    libxl__gc gc = LIBXL_INIT_GC(ctx);
> +    GC_INIT(ctx);
>      libxl__device device;
>      int rc;
> 
> -    rc = libxl__device_from_nic(&gc, domid, nic, &device);
> +    rc = libxl__device_from_nic(gc, domid, nic, &device);
>      if (rc != 0) goto out;
> 
> -    rc = libxl__device_remove(&gc, &device, 1);
> +    rc = libxl__device_remove(gc, &device, 1);
>  out:
> -    libxl__free_all(&gc);
> +    GC_FREE;
>      return rc;
>  }
> 
>  int libxl_device_nic_destroy(libxl_ctx *ctx, uint32_t domid,
>                                    libxl_device_nic *nic)
>  {
> -    libxl__gc gc = LIBXL_INIT_GC(ctx);
> +    GC_INIT(ctx);
>      libxl__device device;
>      int rc;
> 
> -    rc = libxl__device_from_nic(&gc, domid, nic, &device);
> +    rc = libxl__device_from_nic(gc, domid, nic, &device);
>      if (rc != 0) goto out;
> 
> -    rc = libxl__device_destroy(&gc, &device);
> +    rc = libxl__device_destroy(gc, &device);
>  out:
> -    libxl__free_all(&gc);
> +    GC_FREE;
>      return rc;
>  }
> 
> @@ -1607,26 +1607,26 @@ static void libxl__device_nic_from_xs_be(libxl__gc *gc,
>  int libxl_devid_to_device_nic(libxl_ctx *ctx, uint32_t domid,
>                                int devid, libxl_device_nic *nic)
>  {
> -    libxl__gc gc = LIBXL_INIT_GC(ctx);
> +    GC_INIT(ctx);
>      char *dompath, *path;
>      int rc = ERROR_FAIL;
> 
>      memset(nic, 0, sizeof (libxl_device_nic));
> -    dompath = libxl__xs_get_dompath(&gc, domid);
> +    dompath = libxl__xs_get_dompath(gc, domid);
>      if (!dompath)
>          goto out;
> 
> -    path = libxl__xs_read(&gc, XBT_NULL,
> -                          libxl__sprintf(&gc, "%s/device/vif/%d/backend",
> +    path = libxl__xs_read(gc, XBT_NULL,
> +                          libxl__sprintf(gc, "%s/device/vif/%d/backend",
>                                           dompath, devid));
>      if (!path)
>          goto out;
> 
> -    libxl__device_nic_from_xs_be(&gc, path, nic);
> +    libxl__device_nic_from_xs_be(gc, path, nic);
> 
>      rc = 0;
>  out:
> -    libxl__free_all(&gc);
> +    GC_FREE;
>      return rc;
>  }
> 
> @@ -1665,16 +1665,16 @@ static int libxl__append_nic_list_of_type(libxl__gc *gc,
> 
>  libxl_device_nic *libxl_device_nic_list(libxl_ctx *ctx, uint32_t domid, int *num)
>  {
> -    libxl__gc gc = LIBXL_INIT_GC(ctx);
> +    GC_INIT(ctx);
>      libxl_device_nic *nics = NULL;
>      int rc;
> 
>      *num = 0;
> 
> -    rc = libxl__append_nic_list_of_type(&gc, domid, "vif", &nics, num);
> +    rc = libxl__append_nic_list_of_type(gc, domid, "vif", &nics, num);
>      if (rc) goto out_err;
> 
> -    libxl__free_all(&gc);
> +    GC_FREE;
>      return nics;
> 
>  out_err:
> @@ -1690,36 +1690,36 @@ out_err:
>  int libxl_device_nic_getinfo(libxl_ctx *ctx, uint32_t domid,
>                                libxl_device_nic *nic, libxl_nicinfo *nicinfo)
>  {
> -    libxl__gc gc = LIBXL_INIT_GC(ctx);
> +    GC_INIT(ctx);
>      char *dompath, *nicpath;
>      char *val;
> 
> -    dompath = libxl__xs_get_dompath(&gc, domid);
> +    dompath = libxl__xs_get_dompath(gc, domid);
>      nicinfo->devid = nic->devid;
> 
> -    nicpath = libxl__sprintf(&gc, "%s/device/vif/%d", dompath, nicinfo->devid);
> +    nicpath = libxl__sprintf(gc, "%s/device/vif/%d", dompath, nicinfo->devid);
>      nicinfo->backend = xs_read(ctx->xsh, XBT_NULL,
> -                                libxl__sprintf(&gc, "%s/backend", nicpath), NULL);
> +                                libxl__sprintf(gc, "%s/backend", nicpath), NULL);
>      if (!nicinfo->backend) {
> -        libxl__free_all(&gc);
> +        GC_FREE;
>          return ERROR_FAIL;
>      }
> -    val = libxl__xs_read(&gc, XBT_NULL, libxl__sprintf(&gc, "%s/backend-id", nicpath));
> +    val = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/backend-id", nicpath));
>      nicinfo->backend_id = val ? strtoul(val, NULL, 10) : -1;
> -    val = libxl__xs_read(&gc, XBT_NULL, libxl__sprintf(&gc, "%s/state", nicpath));
> +    val = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/state", nicpath));
>      nicinfo->state = val ? strtoul(val, NULL, 10) : -1;
> -    val = libxl__xs_read(&gc, XBT_NULL, libxl__sprintf(&gc, "%s/event-channel", nicpath));
> +    val = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/event-channel", nicpath));
>      nicinfo->evtch = val ? strtoul(val, NULL, 10) : -1;
> -    val = libxl__xs_read(&gc, XBT_NULL, libxl__sprintf(&gc, "%s/tx-ring-ref", nicpath));
> +    val = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/tx-ring-ref", nicpath));
>      nicinfo->rref_tx = val ? strtoul(val, NULL, 10) : -1;
> -    val = libxl__xs_read(&gc, XBT_NULL, libxl__sprintf(&gc, "%s/rx-ring-ref", nicpath));
> +    val = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/rx-ring-ref", nicpath));
>      nicinfo->rref_rx = val ? strtoul(val, NULL, 10) : -1;
>      nicinfo->frontend = xs_read(ctx->xsh, XBT_NULL,
> -                                 libxl__sprintf(&gc, "%s/frontend", nicinfo->backend), NULL);
> -    val = libxl__xs_read(&gc, XBT_NULL, libxl__sprintf(&gc, "%s/frontend-id", nicinfo->backend));
> +                                 libxl__sprintf(gc, "%s/frontend", nicinfo->backend), NULL);
> +    val = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/frontend-id", nicinfo->backend));
>      nicinfo->frontend_id = val ? strtoul(val, NULL, 10) : -1;
> 
> -    libxl__free_all(&gc);
> +    GC_FREE;
>      return 0;
>  }
> 
> @@ -1825,7 +1825,7 @@ static int libxl__device_from_vkb(libxl__gc *gc, uint32_t domid,
> 
>  int libxl_device_vkb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vkb *vkb)
>  {
> -    libxl__gc gc = LIBXL_INIT_GC(ctx);
> +    GC_INIT(ctx);
>      flexarray_t *front;
>      flexarray_t *back;
>      libxl__device device;
> @@ -1842,64 +1842,64 @@ int libxl_device_vkb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vkb *vkb)
>          goto out_free;
>      }
> 
> -    rc = libxl__device_from_vkb(&gc, domid, vkb, &device);
> +    rc = libxl__device_from_vkb(gc, domid, vkb, &device);
>      if (rc != 0) goto out_free;
> 
>      flexarray_append(back, "frontend-id");
> -    flexarray_append(back, libxl__sprintf(&gc, "%d", domid));
> +    flexarray_append(back, libxl__sprintf(gc, "%d", domid));
>      flexarray_append(back, "online");
>      flexarray_append(back, "1");
>      flexarray_append(back, "state");
> -    flexarray_append(back, libxl__sprintf(&gc, "%d", 1));
> +    flexarray_append(back, libxl__sprintf(gc, "%d", 1));
>      flexarray_append(back, "domain");
> -    flexarray_append(back, libxl__domid_to_name(&gc, domid));
> +    flexarray_append(back, libxl__domid_to_name(gc, domid));
> 
>      flexarray_append(front, "backend-id");
> -    flexarray_append(front, libxl__sprintf(&gc, "%d", vkb->backend_domid));
> +    flexarray_append(front, libxl__sprintf(gc, "%d", vkb->backend_domid));
>      flexarray_append(front, "state");
> -    flexarray_append(front, libxl__sprintf(&gc, "%d", 1));
> +    flexarray_append(front, libxl__sprintf(gc, "%d", 1));
> 
> -    libxl__device_generic_add(&gc, &device,
> -                             libxl__xs_kvs_of_flexarray(&gc, back, back->count),
> -                             libxl__xs_kvs_of_flexarray(&gc, front, front->count));
> +    libxl__device_generic_add(gc, &device,
> +                             libxl__xs_kvs_of_flexarray(gc, back, back->count),
> +                             libxl__xs_kvs_of_flexarray(gc, front, front->count));
>      rc = 0;
>  out_free:
>      flexarray_free(back);
>      flexarray_free(front);
>  out:
> -    libxl__free_all(&gc);
> +    GC_FREE;
>      return rc;
>  }
> 
>  int libxl_device_vkb_remove(libxl_ctx *ctx, uint32_t domid,
>                              libxl_device_vkb *vkb)
>  {
> -    libxl__gc gc = LIBXL_INIT_GC(ctx);
> +    GC_INIT(ctx);
>      libxl__device device;
>      int rc;
> 
> -    rc = libxl__device_from_vkb(&gc, domid, vkb, &device);
> +    rc = libxl__device_from_vkb(gc, domid, vkb, &device);
>      if (rc != 0) goto out;
> 
> -    rc = libxl__device_remove(&gc, &device, 1);
> +    rc = libxl__device_remove(gc, &device, 1);
>  out:
> -    libxl__free_all(&gc);
> +    GC_FREE;
>      return rc;
>  }
> 
>  int libxl_device_vkb_destroy(libxl_ctx *ctx, uint32_t domid,
>                                    libxl_device_vkb *vkb)
>  {
> -    libxl__gc gc = LIBXL_INIT_GC(ctx);
> +    GC_INIT(ctx);
>      libxl__device device;
>      int rc;
> 
> -    rc = libxl__device_from_vkb(&gc, domid, vkb, &device);
> +    rc = libxl__device_from_vkb(gc, domid, vkb, &device);
>      if (rc != 0) goto out;
> 
> -    rc = libxl__device_destroy(&gc, &device);
> +    rc = libxl__device_destroy(gc, &device);
>  out:
> -    libxl__free_all(&gc);
> +    GC_FREE;
>      return rc;
>  }
> 
> @@ -1935,7 +1935,7 @@ static int libxl__device_from_vfb(libxl__gc *gc, uint32_t domid,
> 
>  int libxl_device_vfb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vfb *vfb)
>  {
> -    libxl__gc gc = LIBXL_INIT_GC(ctx);
> +    GC_INIT(ctx);
>      flexarray_t *front;
>      flexarray_t *back;
>      libxl__device device;
> @@ -1952,20 +1952,20 @@ int libxl_device_vfb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vfb *vfb)
>          goto out_free;
>      }
> 
> -    rc = libxl__device_from_vfb(&gc, domid, vfb, &device);
> +    rc = libxl__device_from_vfb(gc, domid, vfb, &device);
>      if (rc != 0) goto out_free;
> 
> -    flexarray_append_pair(back, "frontend-id", libxl__sprintf(&gc, "%d", domid));
> +    flexarray_append_pair(back, "frontend-id", libxl__sprintf(gc, "%d", domid));
>      flexarray_append_pair(back, "online", "1");
> -    flexarray_append_pair(back, "state", libxl__sprintf(&gc, "%d", 1));
> -    flexarray_append_pair(back, "domain", libxl__domid_to_name(&gc, domid));
> -    flexarray_append_pair(back, "vnc", libxl__sprintf(&gc, "%d", vfb->vnc));
> +    flexarray_append_pair(back, "state", libxl__sprintf(gc, "%d", 1));
> +    flexarray_append_pair(back, "domain", libxl__domid_to_name(gc, domid));
> +    flexarray_append_pair(back, "vnc", libxl__sprintf(gc, "%d", vfb->vnc));
>      flexarray_append_pair(back, "vnclisten", vfb->vnclisten);
>      flexarray_append_pair(back, "vncpasswd", vfb->vncpasswd);
> -    flexarray_append_pair(back, "vncdisplay", libxl__sprintf(&gc, "%d", vfb->vncdisplay));
> -    flexarray_append_pair(back, "vncunused", libxl__sprintf(&gc, "%d", vfb->vncunused));
> -    flexarray_append_pair(back, "sdl", libxl__sprintf(&gc, "%d", vfb->sdl));
> -    flexarray_append_pair(back, "opengl", libxl__sprintf(&gc, "%d", vfb->opengl));
> +    flexarray_append_pair(back, "vncdisplay", libxl__sprintf(gc, "%d", vfb->vncdisplay));
> +    flexarray_append_pair(back, "vncunused", libxl__sprintf(gc, "%d", vfb->vncunused));
> +    flexarray_append_pair(back, "sdl", libxl__sprintf(gc, "%d", vfb->sdl));
> +    flexarray_append_pair(back, "opengl", libxl__sprintf(gc, "%d", vfb->opengl));
>      if (vfb->xauthority) {
>          flexarray_append_pair(back, "xauthority", vfb->xauthority);
>      }
> @@ -1973,50 +1973,50 @@ int libxl_device_vfb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vfb *vfb)
>          flexarray_append_pair(back, "display", vfb->display);
>      }
> 
> -    flexarray_append_pair(front, "backend-id", libxl__sprintf(&gc, "%d", vfb->backend_domid));
> -    flexarray_append_pair(front, "state", libxl__sprintf(&gc, "%d", 1));
> +    flexarray_append_pair(front, "backend-id", libxl__sprintf(gc, "%d", vfb->backend_domid));
> +    flexarray_append_pair(front, "state", libxl__sprintf(gc, "%d", 1));
> 
> -    libxl__device_generic_add(&gc, &device,
> -                             libxl__xs_kvs_of_flexarray(&gc, back, back->count),
> -                             libxl__xs_kvs_of_flexarray(&gc, front, front->count));
> +    libxl__device_generic_add(gc, &device,
> +                             libxl__xs_kvs_of_flexarray(gc, back, back->count),
> +                             libxl__xs_kvs_of_flexarray(gc, front, front->count));
>      rc = 0;
>  out_free:
>      flexarray_free(front);
>      flexarray_free(back);
>  out:
> -    libxl__free_all(&gc);
> +    GC_FREE;
>      return rc;
>  }
> 
>  int libxl_device_vfb_remove(libxl_ctx *ctx, uint32_t domid,
>                              libxl_device_vfb *vfb)
>  {
> -    libxl__gc gc = LIBXL_INIT_GC(ctx);
> +    GC_INIT(ctx);
>      libxl__device device;
>      int rc;
> 
> -    rc = libxl__device_from_vfb(&gc, domid, vfb, &device);
> +    rc = libxl__device_from_vfb(gc, domid, vfb, &device);
>      if (rc != 0) goto out;
> 
> -    rc = libxl__device_remove(&gc, &device, 1);
> +    rc = libxl__device_remove(gc, &device, 1);
>  out:
> -    libxl__free_all(&gc);
> +    GC_FREE;
>      return rc;
>  }
> 
>  int libxl_device_vfb_destroy(libxl_ctx *ctx, uint32_t domid,
>                                    libxl_device_vfb *vfb)
>  {
> -    libxl__gc gc = LIBXL_INIT_GC(ctx);
> +    GC_INIT(ctx);
>      libxl__device device;
>      int rc;
> 
> -    rc = libxl__device_from_vfb(&gc, domid, vfb, &device);
> +    rc = libxl__device_from_vfb(gc, domid, vfb, &device);
>      if (rc != 0) goto out;
> 
> -    rc = libxl__device_destroy(&gc, &device);
> +    rc = libxl__device_destroy(gc, &device);
>  out:
> -    libxl__free_all(&gc);
> +    GC_FREE;
>      return rc;
>  }
> 
> @@ -2024,13 +2024,13 @@ out:
> 
>  int libxl_domain_setmaxmem(libxl_ctx *ctx, uint32_t domid, uint32_t max_memkb)
>  {
> -    libxl__gc gc = LIBXL_INIT_GC(ctx);
> +    GC_INIT(ctx);
>      char *mem, *endptr;
>      uint32_t memorykb;
> -    char *dompath = libxl__xs_get_dompath(&gc, domid);
> +    char *dompath = libxl__xs_get_dompath(gc, domid);
>      int rc = 1;
> 
> -    mem = libxl__xs_read(&gc, XBT_NULL, libxl__sprintf(&gc, "%s/memory/target", dompath));
> +    mem = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/memory/target", dompath));
>      if (!mem) {
>          LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "cannot get memory info from %s/memory/target\n", dompath);
>          goto out;
> @@ -2055,7 +2055,7 @@ int libxl_domain_setmaxmem(libxl_ctx *ctx, uint32_t domid, uint32_t max_memkb)
> 
>      rc = 0;
>  out:
> -    libxl__free_all(&gc);
> +    GC_FREE;
>      return rc;
>  }
> 
> @@ -2163,12 +2163,12 @@ retry:
>  int libxl_set_memory_target(libxl_ctx *ctx, uint32_t domid,
>          int32_t target_memkb, int relative, int enforce)
>  {
> -    libxl__gc gc = LIBXL_INIT_GC(ctx);
> +    GC_INIT(ctx);
>      int rc = 1, abort = 0;
>      uint32_t memorykb = 0, videoram = 0;
>      uint32_t current_target_memkb = 0, new_target_memkb = 0;
>      char *memmax, *endptr, *videoram_s = NULL, *target = NULL;
> -    char *dompath = libxl__xs_get_dompath(&gc, domid);
> +    char *dompath = libxl__xs_get_dompath(gc, domid);
>      xc_domaininfo_t info;
>      libxl_dominfo ptr;
>      char *uuid;
> @@ -2177,11 +2177,11 @@ int libxl_set_memory_target(libxl_ctx *ctx, uint32_t domid,
>  retry_transaction:
>      t = xs_transaction_start(ctx->xsh);
> 
> -    target = libxl__xs_read(&gc, t, libxl__sprintf(&gc,
> +    target = libxl__xs_read(gc, t, libxl__sprintf(gc,
>                  "%s/memory/target", dompath));
>      if (!target && !domid) {
>          xs_transaction_end(ctx->xsh, t, 1);
> -        rc = libxl__fill_dom0_memory_info(&gc, &current_target_memkb);
> +        rc = libxl__fill_dom0_memory_info(gc, &current_target_memkb);
>          if (rc < 0) {
>              abort = 1;
>              goto out;
> @@ -2203,7 +2203,7 @@ retry_transaction:
>              goto out;
>          }
>      }
> -    memmax = libxl__xs_read(&gc, t, libxl__sprintf(&gc,
> +    memmax = libxl__xs_read(gc, t, libxl__sprintf(gc,
>                  "%s/memory/static-max", dompath));
>      if (!memmax) {
>          LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
> @@ -2243,7 +2243,7 @@ retry_transaction:
>          abort = 1;
>          goto out;
>      }
> -    videoram_s = libxl__xs_read(&gc, t, libxl__sprintf(&gc,
> +    videoram_s = libxl__xs_read(gc, t, libxl__sprintf(gc,
>                  "%s/memory/videoram", dompath));
>      videoram = videoram_s ? atoi(videoram_s) : 0;
> 
> @@ -2272,7 +2272,7 @@ retry_transaction:
>          goto out;
>      }
> 
> -    libxl__xs_write(&gc, t, libxl__sprintf(&gc, "%s/memory/target",
> +    libxl__xs_write(gc, t, libxl__sprintf(gc, "%s/memory/target",
>                  dompath), "%"PRIu32, new_target_memkb);
>      rc = xc_domain_getinfolist(ctx->xch, domid, 1, &info);
>      if (rc != 1 || info.domain != domid) {
> @@ -2280,8 +2280,8 @@ retry_transaction:
>          goto out;
>      }
>      xcinfo2xlinfo(&info, &ptr);
> -    uuid = libxl__uuid2string(&gc, ptr.uuid);
> -    libxl__xs_write(&gc, t, libxl__sprintf(&gc, "/vm/%s/memory", uuid),
> +    uuid = libxl__uuid2string(gc, ptr.uuid);
> +    libxl__xs_write(gc, t, libxl__sprintf(gc, "/vm/%s/memory", uuid),
>              "%"PRIu32, new_target_memkb / 1024);
> 
>  out:
> @@ -2289,22 +2289,22 @@ out:
>          if (errno == EAGAIN)
>              goto retry_transaction;
> 
> -    libxl__free_all(&gc);
> +    GC_FREE;
>      return rc;
>  }
> 
>  int libxl_get_memory_target(libxl_ctx *ctx, uint32_t domid, uint32_t *out_target)
>  {
> -    libxl__gc gc = LIBXL_INIT_GC(ctx);
> +    GC_INIT(ctx);
>      int rc = 1;
>      char *target = NULL, *endptr = NULL;
> -    char *dompath = libxl__xs_get_dompath(&gc, domid);
> +    char *dompath = libxl__xs_get_dompath(gc, domid);
>      uint32_t target_memkb;
> 
> -    target = libxl__xs_read(&gc, XBT_NULL, libxl__sprintf(&gc,
> +    target = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc,
>                  "%s/memory/target", dompath));
>      if (!target && !domid) {
> -        rc = libxl__fill_dom0_memory_info(&gc, &target_memkb);
> +        rc = libxl__fill_dom0_memory_info(gc, &target_memkb);
>          if (rc < 0)
>              goto out;
>      } else if (!target) {
> @@ -2325,14 +2325,14 @@ int libxl_get_memory_target(libxl_ctx *ctx, uint32_t domid, uint32_t *out_target
>      rc = 0;
> 
>  out:
> -    libxl__free_all(&gc);
> +    GC_FREE;
>      return rc;
>  }
> 
>  int libxl_domain_need_memory(libxl_ctx *ctx, libxl_domain_build_info *b_info,
>          libxl_device_model_info *dm_info, uint32_t *need_memkb)
>  {
> -    libxl__gc gc = LIBXL_INIT_GC(ctx);
> +    GC_INIT(ctx);
>      int rc = ERROR_INVAL;
>      *need_memkb = b_info->target_memkb;
>      switch (b_info->type) {
> @@ -2351,7 +2351,7 @@ int libxl_domain_need_memory(libxl_ctx *ctx, libxl_domain_build_info *b_info,
>          *need_memkb += (2 * 1024) - (*need_memkb % (2 * 1024));
>      rc = 0;
>  out:
> -    libxl__free_all(&gc);
> +    GC_FREE;
>      return rc;
> 
>  }
> @@ -2361,12 +2361,12 @@ int libxl_get_free_memory(libxl_ctx *ctx, uint32_t *memkb)
>      int rc = 0;
>      libxl_physinfo info;
>      uint32_t freemem_slack;
> -    libxl__gc gc = LIBXL_INIT_GC(ctx);
> +    GC_INIT(ctx);
> 
>      rc = libxl_get_physinfo(ctx, &info);
>      if (rc < 0)
>          goto out;
> -    rc = libxl__get_free_memory_slack(&gc, &freemem_slack);
> +    rc = libxl__get_free_memory_slack(gc, &freemem_slack);
>      if (rc < 0)
>          goto out;
> 
> @@ -2376,7 +2376,7 @@ int libxl_get_free_memory(libxl_ctx *ctx, uint32_t *memkb)
>          *memkb = 0;
> 
>  out:
> -    libxl__free_all(&gc);
> +    GC_FREE;
>      return rc;
>  }
> 
> @@ -2386,9 +2386,9 @@ int libxl_wait_for_free_memory(libxl_ctx *ctx, uint32_t domid, uint32_t
>      int rc = 0;
>      libxl_physinfo info;
>      uint32_t freemem_slack;
> -    libxl__gc gc = LIBXL_INIT_GC(ctx);
> +    GC_INIT(ctx);
> 
> -    rc = libxl__get_free_memory_slack(&gc, &freemem_slack);
> +    rc = libxl__get_free_memory_slack(gc, &freemem_slack);
>      if (rc < 0)
>          goto out;
>      while (wait_secs > 0) {
> @@ -2405,7 +2405,7 @@ int libxl_wait_for_free_memory(libxl_ctx *ctx, uint32_t domid, uint32_t
>      rc = ERROR_NOMEM;
> 
>  out:
> -    libxl__free_all(&gc);
> +    GC_FREE;
>      return rc;
>  }
> 
> @@ -2631,7 +2631,7 @@ int libxl_set_vcpuaffinity(libxl_ctx *ctx, uint32_t domid, uint32_t vcpuid,
> 
>  int libxl_set_vcpuonline(libxl_ctx *ctx, uint32_t domid, libxl_cpumap *cpumap)
>  {
> -    libxl__gc gc = LIBXL_INIT_GC(ctx);
> +    GC_INIT(ctx);
>      libxl_dominfo info;
>      char *dompath;
>      xs_transaction_t t;
> @@ -2641,14 +2641,14 @@ int libxl_set_vcpuonline(libxl_ctx *ctx, uint32_t domid, libxl_cpumap *cpumap)
>          LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "getting domain info list");
>          goto out;
>      }
> -    if (!(dompath = libxl__xs_get_dompath(&gc, domid)))
> +    if (!(dompath = libxl__xs_get_dompath(gc, domid)))
>          goto out;
> 
>  retry_transaction:
>      t = xs_transaction_start(ctx->xsh);
>      for (i = 0; i <= info.vcpu_max_id; i++)
> -        libxl__xs_write(&gc, t,
> -                       libxl__sprintf(&gc, "%s/cpu/%u/availability", dompath, i),
> +        libxl__xs_write(gc, t,
> +                       libxl__sprintf(gc, "%s/cpu/%u/availability", dompath, i),
>                         "%s", libxl_cpumap_test(cpumap, i) ? "online" : "offline");
>      if (!xs_transaction_end(ctx->xsh, t, 0)) {
>          if (errno == EAGAIN)
> @@ -2656,7 +2656,7 @@ retry_transaction:
>      } else
>          rc = 0;
>  out:
> -    libxl__free_all(&gc);
> +    GC_FREE;
>      return rc;
>  }
> 
> @@ -2776,12 +2776,12 @@ int libxl_send_trigger(libxl_ctx *ctx, uint32_t domid, char *trigger_name, uint3
> 
>  int libxl_send_sysrq(libxl_ctx *ctx, uint32_t domid, char sysrq)
>  {
> -    libxl__gc gc = LIBXL_INIT_GC(ctx);
> -    char *dompath = libxl__xs_get_dompath(&gc, domid);
> +    GC_INIT(ctx);
> +    char *dompath = libxl__xs_get_dompath(gc, domid);
> 
> -    libxl__xs_write(&gc, XBT_NULL, libxl__sprintf(&gc, "%s/control/sysrq", dompath), "%c", sysrq);
> +    libxl__xs_write(gc, XBT_NULL, libxl__sprintf(gc, "%s/control/sysrq", dompath), "%c", sysrq);
> 
> -    libxl__free_all(&gc);
> +    GC_FREE;
>      return 0;
>  }
> 
> @@ -2868,15 +2868,15 @@ void libxl_xen_console_read_finish(libxl_ctx *ctx,
> 
>  uint32_t libxl_vm_get_start_time(libxl_ctx *ctx, uint32_t domid)
>  {
> -    libxl__gc gc = LIBXL_INIT_GC(ctx);
> -    char *dompath = libxl__xs_get_dompath(&gc, domid);
> +    GC_INIT(ctx);
> +    char *dompath = libxl__xs_get_dompath(gc, domid);
>      char *vm_path, *start_time;
>      uint32_t ret;
> 
>      vm_path = libxl__xs_read(
> -        &gc, XBT_NULL, libxl__sprintf(&gc, "%s/vm", dompath));
> +        gc, XBT_NULL, libxl__sprintf(gc, "%s/vm", dompath));
>      start_time = libxl__xs_read(
> -        &gc, XBT_NULL, libxl__sprintf(&gc, "%s/start_time", vm_path));
> +        gc, XBT_NULL, libxl__sprintf(gc, "%s/start_time", vm_path));
>      if (start_time == NULL) {
>          LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, -1,
>                          "Can't get start time of domain '%d'", domid);
> @@ -2884,7 +2884,7 @@ uint32_t libxl_vm_get_start_time(libxl_ctx *ctx, uint32_t domid)
>      }else{
>          ret = strtoul(start_time, NULL, 10);
>      }
> -    libxl__free_all(&gc);
> +    GC_FREE;
>      return ret;
>  }
> 
> @@ -3037,15 +3037,15 @@ int libxl_create_cpupool(libxl_ctx *ctx, const char *name, int schedid,
>                           libxl_cpumap cpumap, libxl_uuid *uuid,
>                           uint32_t *poolid)
>  {
> -    libxl__gc gc = LIBXL_INIT_GC(ctx);
> +    GC_INIT(ctx);
>      int rc;
>      int i;
>      xs_transaction_t t;
>      char *uuid_string;
> 
> -    uuid_string = libxl__uuid2string(&gc, *uuid);
> +    uuid_string = libxl__uuid2string(gc, *uuid);
>      if (!uuid_string) {
> -        libxl__free_all(&gc);
> +        GC_FREE;
>          return ERROR_NOMEM;
>      }
> 
> @@ -3053,7 +3053,7 @@ int libxl_create_cpupool(libxl_ctx *ctx, const char *name, int schedid,
>      if (rc) {
>          LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, rc,
>             "Could not create cpupool");
> -        libxl__free_all(&gc);
> +        GC_FREE;
>          return ERROR_FAIL;
>      }
> 
> @@ -3064,7 +3064,7 @@ int libxl_create_cpupool(libxl_ctx *ctx, const char *name, int schedid,
>                  LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, rc,
>                      "Error moving cpu to cpupool");
>                  libxl_cpupool_destroy(ctx, *poolid);
> -                libxl__free_all(&gc);
> +                GC_FREE;
>                  return ERROR_FAIL;
>              }
>          }
> @@ -3072,16 +3072,16 @@ int libxl_create_cpupool(libxl_ctx *ctx, const char *name, int schedid,
>      for (;;) {
>          t = xs_transaction_start(ctx->xsh);
> 
> -        xs_mkdir(ctx->xsh, t, libxl__sprintf(&gc, "/local/pool/%d", *poolid));
> -        libxl__xs_write(&gc, t,
> -                        libxl__sprintf(&gc, "/local/pool/%d/uuid", *poolid),
> +        xs_mkdir(ctx->xsh, t, libxl__sprintf(gc, "/local/pool/%d", *poolid));
> +        libxl__xs_write(gc, t,
> +                        libxl__sprintf(gc, "/local/pool/%d/uuid", *poolid),
>                          "%s", uuid_string);
> -        libxl__xs_write(&gc, t,
> -                        libxl__sprintf(&gc, "/local/pool/%d/name", *poolid),
> +        libxl__xs_write(gc, t,
> +                        libxl__sprintf(gc, "/local/pool/%d/name", *poolid),
>                          "%s", name);
> 
>          if (xs_transaction_end(ctx->xsh, t, 0) || (errno != EAGAIN)) {
> -            libxl__free_all(&gc);
> +            GC_FREE;
>              return 0;
>          }
>      }
> @@ -3089,7 +3089,7 @@ int libxl_create_cpupool(libxl_ctx *ctx, const char *name, int schedid,
> 
>  int libxl_cpupool_destroy(libxl_ctx *ctx, uint32_t poolid)
>  {
> -    libxl__gc gc = LIBXL_INIT_GC(ctx);
> +    GC_INIT(ctx);
>      int rc, i;
>      xc_cpupoolinfo_t *info;
>      xs_transaction_t t;
> @@ -3097,7 +3097,7 @@ int libxl_cpupool_destroy(libxl_ctx *ctx, uint32_t poolid)
> 
>      info = xc_cpupool_getinfo(ctx->xch, poolid);
>      if (info == NULL) {
> -        libxl__free_all(&gc);
> +        GC_FREE;
>          return ERROR_NOMEM;
>      }
> 
> @@ -3131,7 +3131,7 @@ int libxl_cpupool_destroy(libxl_ctx *ctx, uint32_t poolid)
>      for (;;) {
>          t = xs_transaction_start(ctx->xsh);
> 
> -        xs_rm(ctx->xsh, XBT_NULL, libxl__sprintf(&gc, "/local/pool/%d", poolid));
> +        xs_rm(ctx->xsh, XBT_NULL, libxl__sprintf(gc, "/local/pool/%d", poolid));
> 
>          if (xs_transaction_end(ctx->xsh, t, 0) || (errno != EAGAIN))
>              break;
> @@ -3143,21 +3143,21 @@ out1:
>      libxl_cpumap_dispose(&cpumap);
>  out:
>      xc_cpupool_infofree(ctx->xch, info);
> -    libxl__free_all(&gc);
> +    GC_FREE;
> 
>      return rc;
>  }
> 
>  int libxl_cpupool_rename(libxl_ctx *ctx, const char *name, uint32_t poolid)
>  {
> -    libxl__gc gc = LIBXL_INIT_GC(ctx);
> +    GC_INIT(ctx);
>      xs_transaction_t t;
>      xc_cpupoolinfo_t *info;
>      int rc;
> 
>      info = xc_cpupool_getinfo(ctx->xch, poolid);
>      if (info == NULL) {
> -        libxl__free_all(&gc);
> +        GC_FREE;
>          return ERROR_NOMEM;
>      }
> 
> @@ -3170,8 +3170,8 @@ int libxl_cpupool_rename(libxl_ctx *ctx, const char *name, uint32_t poolid)
>      for (;;) {
>          t = xs_transaction_start(ctx->xsh);
> 
> -        libxl__xs_write(&gc, t,
> -                        libxl__sprintf(&gc, "/local/pool/%d/name", poolid),
> +        libxl__xs_write(gc, t,
> +                        libxl__sprintf(gc, "/local/pool/%d/name", poolid),
>                          "%s", name);
> 
>          if (xs_transaction_end(ctx->xsh, t, 0))
> @@ -3186,7 +3186,7 @@ int libxl_cpupool_rename(libxl_ctx *ctx, const char *name, uint32_t poolid)
> 
>  out:
>      xc_cpupool_infofree(ctx->xch, info);
> -    libxl__free_all(&gc);
> +    GC_FREE;
> 
>      return rc;
>  }
> @@ -3293,16 +3293,16 @@ out:
> 
>  int libxl_cpupool_movedomain(libxl_ctx *ctx, uint32_t poolid, uint32_t domid)
>  {
> -    libxl__gc gc = LIBXL_INIT_GC(ctx);
> +    GC_INIT(ctx);
>      int rc;
>      char *dom_path;
>      char *vm_path;
>      char *poolname;
>      xs_transaction_t t;
> 
> -    dom_path = libxl__xs_get_dompath(&gc, domid);
> +    dom_path = libxl__xs_get_dompath(gc, domid);
>      if (!dom_path) {
> -        libxl__free_all(&gc);
> +        GC_FREE;
>          return ERROR_FAIL;
>      }
> 
> @@ -3310,26 +3310,26 @@ int libxl_cpupool_movedomain(libxl_ctx *ctx, uint32_t poolid, uint32_t domid)
>      if (rc) {
>          LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, rc,
>              "Error moving domain to cpupool");
> -        libxl__free_all(&gc);
> +        GC_FREE;
>          return ERROR_FAIL;
>      }
> 
>      for (;;) {
>          t = xs_transaction_start(ctx->xsh);
> 
> -        poolname = libxl__cpupoolid_to_name(&gc, poolid);
> -        vm_path = libxl__xs_read(&gc, XBT_NULL, libxl__sprintf(&gc, "%s/vm", dom_path));
> +        poolname = libxl__cpupoolid_to_name(gc, poolid);
> +        vm_path = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/vm", dom_path));
>          if (!vm_path)
>              break;
> 
> -        libxl__xs_write(&gc, t, libxl__sprintf(&gc, "%s/pool_name", vm_path),
> +        libxl__xs_write(gc, t, libxl__sprintf(gc, "%s/pool_name", vm_path),
>                          "%s", poolname);
> 
>          if (xs_transaction_end(ctx->xsh, t, 0) || (errno != EAGAIN))
>              break;
>      }
> 
> -    libxl__free_all(&gc);
> +    GC_FREE;
>      return 0;
>  }
> 
> diff --git a/tools/libxl/libxl_bootloader.c b/tools/libxl/libxl_bootloader.c
> index b8399a1..ce83b8e 100644
> --- a/tools/libxl/libxl_bootloader.c
> +++ b/tools/libxl/libxl_bootloader.c
> @@ -328,7 +328,7 @@ int libxl_run_bootloader(libxl_ctx *ctx,
>                           libxl_device_disk *disk,
>                           uint32_t domid)
>  {
> -    libxl__gc gc = LIBXL_INIT_GC(ctx);
> +    GC_INIT(ctx);
>      int ret, rc = 0;
>      char *fifo = NULL;
>      char *diskpath = NULL;
> @@ -388,7 +388,7 @@ int libxl_run_bootloader(libxl_ctx *ctx,
>          goto out_close;
>      }
> 
> -    args = make_bootloader_args(&gc, info, domid, fifo, diskpath);
> +    args = make_bootloader_args(gc, info, domid, fifo, diskpath);
>      if (args == NULL) {
>          rc = ERROR_NOMEM;
>          goto out_close;
> @@ -411,8 +411,8 @@ int libxl_run_bootloader(libxl_ctx *ctx,
>          goto out_close;
>      }
> 
> -    dom_console_xs_path = libxl__sprintf(&gc, "%s/console/tty", libxl__xs_get_dompath(&gc, domid));
> -    libxl__xs_write(&gc, XBT_NULL, dom_console_xs_path, "%s", dom_console_slave_tty_path);
> +    dom_console_xs_path = libxl__sprintf(gc, "%s/console/tty", libxl__xs_get_dompath(gc, domid));
> +    libxl__xs_write(gc, XBT_NULL, dom_console_xs_path, "%s", dom_console_slave_tty_path);
> 
>      pid = fork_exec_bootloader(&bootloader_fd, info->u.pv.bootloader, args);
>      if (pid < 0) {
> @@ -435,7 +435,7 @@ int libxl_run_bootloader(libxl_ctx *ctx,
> 
>      fcntl(fifo_fd, F_SETFL, O_NDELAY);
> 
> -    blout = bootloader_interact(&gc, xenconsoled_fd, bootloader_fd, fifo_fd);
> +    blout = bootloader_interact(gc, xenconsoled_fd, bootloader_fd, fifo_fd);
>      if (blout == NULL) {
>          goto out_close;
>      }
> @@ -445,7 +445,7 @@ int libxl_run_bootloader(libxl_ctx *ctx,
>          goto out_close;
>      }
> 
> -    parse_bootloader_result(&gc, info, blout);
> +    parse_bootloader_result(gc, info, blout);
> 
>      rc = 0;
>  out_close:
> @@ -472,7 +472,7 @@ out_close:
>      free(args);
> 
>  out:
> -    libxl__free_all(&gc);
> +    GC_FREE;
>      return rc;
>  }
> 
> diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
> index ccb56c7..69f10fe 100644
> --- a/tools/libxl/libxl_create.c
> +++ b/tools/libxl/libxl_create.c
> @@ -670,20 +670,20 @@ error_out:
>  int libxl_domain_create_new(libxl_ctx *ctx, libxl_domain_config *d_config,
>                              libxl_console_ready cb, void *priv, uint32_t *domid)
>  {
> -    libxl__gc gc = LIBXL_INIT_GC(ctx);
> +    GC_INIT(ctx);
>      int rc;
> -    rc = do_domain_create(&gc, d_config, cb, priv, domid, -1);
> -    libxl__free_all(&gc);
> +    rc = do_domain_create(gc, d_config, cb, priv, domid, -1);
> +    GC_FREE;
>      return rc;
>  }
> 
>  int libxl_domain_create_restore(libxl_ctx *ctx, libxl_domain_config *d_config,
>                                  libxl_console_ready cb, void *priv, uint32_t *domid, int restore_fd)
>  {
> -    libxl__gc gc = LIBXL_INIT_GC(ctx);
> +    GC_INIT(ctx);
>      int rc;
> -    rc = do_domain_create(&gc, d_config, cb, priv, domid, restore_fd);
> -    libxl__free_all(&gc);
> +    rc = do_domain_create(gc, d_config, cb, priv, domid, restore_fd);
> +    GC_FREE;
>      return rc;
>  }
> 
> diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
> index 96098de..b1ff967 100644
> --- a/tools/libxl/libxl_dom.c
> +++ b/tools/libxl/libxl_dom.c
> @@ -730,7 +730,7 @@ int libxl_userdata_store(libxl_ctx *ctx, uint32_t domid,
>                                const char *userdata_userid,
>                                const uint8_t *data, int datalen)
>  {
> -    libxl__gc gc = LIBXL_INIT_GC(ctx);
> +    GC_INIT(ctx);
>      const char *filename;
>      const char *newfilename;
>      int e, rc;
> @@ -738,18 +738,18 @@ int libxl_userdata_store(libxl_ctx *ctx, uint32_t domid,
>      FILE *f = NULL;
>      size_t rs;
> 
> -    filename = userdata_path(&gc, domid, userdata_userid, "d");
> +    filename = userdata_path(gc, domid, userdata_userid, "d");
>      if (!filename) {
>          rc = ERROR_NOMEM;
>          goto out;
>      }
> 
>      if (!datalen) {
> -        rc = userdata_delete(&gc, filename);
> +        rc = userdata_delete(gc, filename);
>          goto out;
>      }
> 
> -    newfilename = userdata_path(&gc, domid, userdata_userid, "n");
> +    newfilename = userdata_path(gc, domid, userdata_userid, "n");
>      if (!newfilename) {
>          rc = ERROR_NOMEM;
>          goto out;
> @@ -791,7 +791,7 @@ err:
>          LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "cannot write %s for %s",
>                   newfilename, filename);
>  out:
> -    libxl__free_all(&gc);
> +    GC_FREE;
>      return rc;
>  }
> 
> @@ -799,13 +799,13 @@ int libxl_userdata_retrieve(libxl_ctx *ctx, uint32_t domid,
>                                   const char *userdata_userid,
>                                   uint8_t **data_r, int *datalen_r)
>  {
> -    libxl__gc gc = LIBXL_INIT_GC(ctx);
> +    GC_INIT(ctx);
>      const char *filename;
>      int e, rc;
>      int datalen = 0;
>      void *data = 0;
> 
> -    filename = userdata_path(&gc, domid, userdata_userid, "d");
> +    filename = userdata_path(gc, domid, userdata_userid, "d");
>      if (!filename) {
>          rc = ERROR_NOMEM;
>          goto out;
> @@ -827,7 +827,7 @@ int libxl_userdata_retrieve(libxl_ctx *ctx, uint32_t domid,
>      if (datalen_r) *datalen_r = datalen;
>      rc = 0;
>  out:
> -    libxl__free_all(&gc);
> +    GC_FREE;
>      return rc;
>  }
> 
> diff --git a/tools/libxl/libxl_pci.c b/tools/libxl/libxl_pci.c
> index 63c3050..120c239 100644
> --- a/tools/libxl/libxl_pci.c
> +++ b/tools/libxl/libxl_pci.c
> @@ -483,7 +483,7 @@ static int is_assigned(libxl_device_pci *assigned, int num_assigned,
> 
>  libxl_device_pci *libxl_device_pci_list_assignable(libxl_ctx *ctx, int *num)
>  {
> -    libxl__gc gc = LIBXL_INIT_GC(ctx);
> +    GC_INIT(ctx);
>      libxl_device_pci *pcidevs = NULL, *new, *assigned;
>      struct dirent *de;
>      DIR *dir;
> @@ -491,7 +491,7 @@ libxl_device_pci *libxl_device_pci_list_assignable(libxl_ctx *ctx, int *num)
> 
>      *num = 0;
> 
> -    rc = get_all_assigned_devices(&gc, &assigned, &num_assigned);
> +    rc = get_all_assigned_devices(gc, &assigned, &num_assigned);
>      if ( rc )
>          goto out;
> 
> @@ -528,7 +528,7 @@ libxl_device_pci *libxl_device_pci_list_assignable(libxl_ctx *ctx, int *num)
>  out_closedir:
>      closedir(dir);
>  out:
> -    libxl__free_all(&gc);
> +    GC_FREE;
>      return pcidevs;
>  }
> 
> @@ -782,10 +782,10 @@ static int libxl__device_pci_reset(libxl__gc *gc, unsigned int domain, unsigned
> 
>  int libxl_device_pci_add(libxl_ctx *ctx, uint32_t domid, libxl_device_pci *pcidev)
>  {
> -    libxl__gc gc = LIBXL_INIT_GC(ctx);
> +    GC_INIT(ctx);
>      int rc;
> -    rc = libxl__device_pci_add(&gc, domid, pcidev, 0);
> -    libxl__free_all(&gc);
> +    rc = libxl__device_pci_add(gc, domid, pcidev, 0);
> +    GC_FREE;
>      return rc;
>  }
> 
> @@ -1057,24 +1057,24 @@ out:
> 
>  int libxl_device_pci_remove(libxl_ctx *ctx, uint32_t domid, libxl_device_pci *pcidev)
>  {
> -    libxl__gc gc = LIBXL_INIT_GC(ctx);
> +    GC_INIT(ctx);
>      int rc;
> 
> -    rc = libxl__device_pci_remove_common(&gc, domid, pcidev, 0);
> +    rc = libxl__device_pci_remove_common(gc, domid, pcidev, 0);
> 
> -    libxl__free_all(&gc);
> +    GC_FREE;
>      return rc;
>  }
> 
>  int libxl_device_pci_destroy(libxl_ctx *ctx, uint32_t domid,
>                                    libxl_device_pci *pcidev)
>  {
> -    libxl__gc gc = LIBXL_INIT_GC(ctx);
> +    GC_INIT(ctx);
>      int rc;
> 
> -    rc = libxl__device_pci_remove_common(&gc, domid, pcidev, 1);
> +    rc = libxl__device_pci_remove_common(gc, domid, pcidev, 1);
> 
> -    libxl__free_all(&gc);
> +    GC_FREE;
>      return rc;
>  }
> 
> @@ -1115,15 +1115,15 @@ static void libxl__device_pci_from_xs_be(libxl__gc *gc,
> 
>  libxl_device_pci *libxl_device_pci_list(libxl_ctx *ctx, uint32_t domid, int *num)
>  {
> -    libxl__gc gc = LIBXL_INIT_GC(ctx);
> +    GC_INIT(ctx);
>      char *be_path, *num_devs;
>      int n, i;
>      libxl_device_pci *pcidevs = NULL;
> 
>      *num = 0;
> 
> -    be_path = libxl__sprintf(&gc, "%s/backend/pci/%d/0", libxl__xs_get_dompath(&gc, 0), domid);
> -    num_devs = libxl__xs_read(&gc, XBT_NULL, libxl__sprintf(&gc, "%s/num_devs", be_path));
> +    be_path = libxl__sprintf(gc, "%s/backend/pci/%d/0", libxl__xs_get_dompath(gc, 0), domid);
> +    num_devs = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/num_devs", be_path));
>      if (!num_devs)
>          goto out;
> 
> @@ -1131,11 +1131,11 @@ libxl_device_pci *libxl_device_pci_list(libxl_ctx *ctx, uint32_t domid, int *num
>      pcidevs = calloc(n, sizeof(libxl_device_pci));
> 
>      for (i = 0; i < n; i++)
> -        libxl__device_pci_from_xs_be(&gc, be_path, pcidevs + i, i);
> +        libxl__device_pci_from_xs_be(gc, be_path, pcidevs + i, i);
> 
>      *num = n;
>  out:
> -    libxl__free_all(&gc);
> +    GC_FREE;
>      return pcidevs;
>  }
> 
> diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
> index c7696d7..60af98c 100644
> --- a/tools/libxl/libxl_qmp.c
> +++ b/tools/libxl/libxl_qmp.c
> @@ -94,7 +94,7 @@ static int store_serial_port_info(libxl__qmp_handler *qmp,
>                                    const char *chardev,
>                                    int port)
>  {
> -    libxl__gc gc = LIBXL_INIT_GC(qmp->ctx);
> +    GC_INIT(qmp->ctx);
>      char *path = NULL;
>      int ret = 0;
> 
> @@ -102,12 +102,12 @@ static int store_serial_port_info(libxl__qmp_handler *qmp,
>          return 0;
>      }
> 
> -    path = libxl__xs_get_dompath(&gc, qmp->domid);
> -    path = libxl__sprintf(&gc, "%s/serial/%d/tty", path, port);
> +    path = libxl__xs_get_dompath(gc, qmp->domid);
> +    path = libxl__sprintf(gc, "%s/serial/%d/tty", path, port);
> 
> -    ret = libxl__xs_write(&gc, XBT_NULL, path, "%s", chardev + 4);
> +    ret = libxl__xs_write(gc, XBT_NULL, path, "%s", chardev + 4);
> 
> -    libxl__free_all(&gc);
> +    GC_FREE;
>      return ret;
>  }
> 
> @@ -521,7 +521,7 @@ static int qmp_synchronous_send(libxl__qmp_handler *qmp, const char *cmd,
>  {
>      int id = 0;
>      int ret = 0;
> -    libxl__gc gc = LIBXL_INIT_GC(qmp->ctx);
> +    GC_INIT(qmp->ctx);
>      qmp_request_context context = { .rc = 0 };
> 
>      id = qmp_send(qmp, cmd, args, callback, opaque, &context);
> @@ -531,7 +531,7 @@ static int qmp_synchronous_send(libxl__qmp_handler *qmp, const char *cmd,
>      qmp->wait_for_id = id;
> 
>      while (qmp->wait_for_id == id) {
> -        if ((ret = qmp_next(&gc, qmp)) < 0) {
> +        if ((ret = qmp_next(gc, qmp)) < 0) {
>              break;
>          }
>      }
> @@ -540,7 +540,7 @@ static int qmp_synchronous_send(libxl__qmp_handler *qmp, const char *cmd,
>          ret = context.rc;
>      }
> 
> -    libxl__free_all(&gc);
> +    GC_FREE;
> 
>      return ret;
>  }
> @@ -559,15 +559,15 @@ libxl__qmp_handler *libxl__qmp_initialize(libxl_ctx *ctx, uint32_t domid)
>      int ret = 0;
>      libxl__qmp_handler *qmp = NULL;
>      char *qmp_socket;
> -    libxl__gc gc = LIBXL_INIT_GC(ctx);
> +    GC_INIT(ctx);
> 
>      qmp = qmp_init_handler(ctx, domid);
> 
> -    qmp_socket = libxl__sprintf(&gc, "%s/qmp-libxl-%d",
> +    qmp_socket = libxl__sprintf(gc, "%s/qmp-libxl-%d",
>                                  libxl_run_dir_path(), domid);
>      if ((ret = qmp_open(qmp, qmp_socket, QMP_SOCKET_CONNECT_TIMEOUT)) < 0) {
>          LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "Connection error");
> -        libxl__free_all(&gc);
> +        GC_FREE;
>          qmp_free_handler(qmp);
>          return NULL;
>      }
> @@ -576,12 +576,12 @@ libxl__qmp_handler *libxl__qmp_initialize(libxl_ctx *ctx, uint32_t domid)
> 
>      /* Wait for the response to qmp_capabilities */
>      while (!qmp->connected) {
> -        if ((ret = qmp_next(&gc, qmp)) < 0) {
> +        if ((ret = qmp_next(gc, qmp)) < 0) {
>              break;
>          }
>      }
> 
> -    libxl__free_all(&gc);
> +    GC_FREE;
>      if (!qmp->connected) {
>          LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Failed to connect to QMP");
>          libxl__qmp_close(qmp);
> @@ -626,9 +626,9 @@ static int pci_add_callback(libxl__qmp_handler *qmp,
>  {
>      libxl_device_pci *pcidev = opaque;
>      const libxl__json_object *bus = NULL;
> -    libxl__gc gc = LIBXL_INIT_GC(qmp->ctx);
> +    GC_INIT(qmp->ctx);
>      int i, j, rc = -1;
> -    char *asked_id = libxl__sprintf(&gc, PCI_PT_QDEV_ID,
> +    char *asked_id = libxl__sprintf(gc, PCI_PT_QDEV_ID,
>                                      pcidev->bus, pcidev->dev, pcidev->func);
> 
>      for (i = 0; (bus = libxl__json_array_get(response, i)); i++) {
> @@ -665,7 +665,7 @@ static int pci_add_callback(libxl__qmp_handler *qmp,
> 
> 
>  out:
> -    libxl__free_all(&gc);
> +    GC_FREE;
>      return rc;
>  }
> 
> diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
> index f1f2a6d..d36c737 100644
> --- a/tools/libxl/libxl_utils.c
> +++ b/tools/libxl/libxl_utils.c
> @@ -186,29 +186,29 @@ char *libxl_schedid_to_name(libxl_ctx *ctx, int schedid)
> 
>  int libxl_get_stubdom_id(libxl_ctx *ctx, int guest_domid)
>  {
> -    libxl__gc gc = LIBXL_INIT_GC(ctx);
> +    GC_INIT(ctx);
>      char * stubdom_id_s;
>      int ret;
> 
> -    stubdom_id_s = libxl__xs_read(&gc, XBT_NULL,
> -                                 libxl__sprintf(&gc, "%s/image/device-model-domid",
> -                                               libxl__xs_get_dompath(&gc, guest_domid)));
> +    stubdom_id_s = libxl__xs_read(gc, XBT_NULL,
> +                                 libxl__sprintf(gc, "%s/image/device-model-domid",
> +                                               libxl__xs_get_dompath(gc, guest_domid)));
>      if (stubdom_id_s)
>          ret = atoi(stubdom_id_s);
>      else
>          ret = 0;
> -    libxl__free_all(&gc);
> +    GC_FREE;
>      return ret;
>  }
> 
>  int libxl_is_stubdom(libxl_ctx *ctx, uint32_t domid, uint32_t *target_domid)
>  {
> -    libxl__gc gc = LIBXL_INIT_GC(ctx);
> +    GC_INIT(ctx);
>      char *target, *endptr;
>      uint32_t value;
>      int ret = 0;
> 
> -    target = libxl__xs_read(&gc, XBT_NULL, libxl__sprintf(&gc, "%s/target", libxl__xs_get_dompath(&gc, domid)));
> +    target = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/target", libxl__xs_get_dompath(gc, domid)));
>      if (!target)
>          goto out;
>      value = strtol(target, &endptr, 10);
> @@ -218,7 +218,7 @@ int libxl_is_stubdom(libxl_ctx *ctx, uint32_t domid, uint32_t *target_domid)
>          *target_domid = value;
>      ret = 1;
>  out:
> -    libxl__free_all(&gc);
> +    GC_FREE;
>      return ret;
>  }
> 
> @@ -240,27 +240,27 @@ static int logrename(libxl__gc *gc, const char *old, const char *new)
> 
>  int libxl_create_logfile(libxl_ctx *ctx, char *name, char **full_name)
>  {
> -    libxl__gc gc = LIBXL_INIT_GC(ctx);
> +    GC_INIT(ctx);
>      struct stat stat_buf;
>      char *logfile, *logfile_new;
>      int i, rc;
> 
> -    logfile = libxl__sprintf(&gc, "/var/log/xen/%s.log", name);
> +    logfile = libxl__sprintf(gc, "/var/log/xen/%s.log", name);
>      if (stat(logfile, &stat_buf) == 0) {
>          /* file exists, rotate */
> -        logfile = libxl__sprintf(&gc, "/var/log/xen/%s.log.10", name);
> +        logfile = libxl__sprintf(gc, "/var/log/xen/%s.log.10", name);
>          unlink(logfile);
>          for (i = 9; i > 0; i--) {
> -            logfile = libxl__sprintf(&gc, "/var/log/xen/%s.log.%d", name, i);
> -            logfile_new = libxl__sprintf(&gc, "/var/log/xen/%s.log.%d", name, i + 1);
> -            rc = logrename(&gc, logfile, logfile_new);
> +            logfile = libxl__sprintf(gc, "/var/log/xen/%s.log.%d", name, i);
> +            logfile_new = libxl__sprintf(gc, "/var/log/xen/%s.log.%d", name, i + 1);
> +            rc = logrename(gc, logfile, logfile_new);
>              if (rc)
>                  goto out;
>          }
> -        logfile = libxl__sprintf(&gc, "/var/log/xen/%s.log", name);
> -        logfile_new = libxl__sprintf(&gc, "/var/log/xen/%s.log.1", name);
> +        logfile = libxl__sprintf(gc, "/var/log/xen/%s.log", name);
> +        logfile_new = libxl__sprintf(gc, "/var/log/xen/%s.log.1", name);
> 
> -        rc = logrename(&gc, logfile, logfile_new);
> +        rc = logrename(gc, logfile, logfile_new);
>          if (rc)
>              goto out;
>      } else {
> @@ -272,7 +272,7 @@ int libxl_create_logfile(libxl_ctx *ctx, char *name, char **full_name)
>      *full_name = strdup(logfile);
>      rc = 0;
>  out:
> -    libxl__free_all(&gc);
> +    GC_FREE;
>      return rc;
>  }
> 
> --
> 1.7.2.5
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 16:29:19 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 16:29:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYKMd-0000M5-DJ; Wed, 07 Dec 2011 16:28:59 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RYKMb-0000LG-Kk
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 16:28:58 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1323275290!7310616!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjA3NQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6068 invoked from network); 7 Dec 2011 16:28:10 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Dec 2011 16:28:10 -0000
X-IronPort-AV: E=Sophos;i="4.71,314,1320624000"; 
   d="scan'208";a="9347120"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Dec 2011 16:28:00 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 7 Dec 2011
	16:28:00 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Wed, 7 Dec 2011 16:28:00 +0000
In-Reply-To: <1323108621-22654-13-git-send-email-ian.jackson@eu.citrix.com>
References: <1323108621-22654-1-git-send-email-ian.jackson@eu.citrix.com>
	<1323108621-22654-13-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323275280.2969.3.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 12/15] libxl: Use GC_INIT and GC_FREE
 everywhere
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2011-12-05 at 18:10 +0000, Ian Jackson wrote:
> Replace
>     libxl__gc gc = LIBXL_INIT_GC(ctx);
>     ...
>     libxl__free_all(&gc);
> with
>     GC_INIT(ctx);
>     ...
>     GC_FREE;

I suppose this really relates to the earlier patch which adds these
macros but wouldn't "GC_FREE();" be nicer?

> throughout with a couple of perl runes.
> 
> We must then adjust uses of the resulting gc for pointerness, which is
> mostly just replacing all occurrences of "&gc" with "gc".

BTW I really like this aspect of the change since one big annoyance when
making an exiting internal function into an external one (or vice versa)
is the need to frob all the uses of gc...

Ian.

>   Also a
> couple of unusual uses of LIBXL_INIT_GC needed to be fixed up by hand.
> 
> Here are those runes:
>  perl -i -pe 's/\Q    libxl__gc gc = LIBXL_INIT_GC(ctx);/    GC_INIT(ctx);/' tools/libxl/*.c
>  perl -i -pe 's/\Q    libxl__free_all(&gc);/    GC_FREE;/' tools/libxl/*.c
> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
> ---
>  tools/libxl/libxl.c            |  590 ++++++++++++++++++++--------------------
>  tools/libxl/libxl_bootloader.c |   14 +-
>  tools/libxl/libxl_create.c     |   12 +-
>  tools/libxl/libxl_dom.c        |   16 +-
>  tools/libxl/libxl_pci.c        |   34 ++--
>  tools/libxl/libxl_qmp.c        |   32 +-
>  tools/libxl/libxl_utils.c      |   36 ++--
>  7 files changed, 367 insertions(+), 367 deletions(-)
> 
> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> index 7488538..3a8cfe3 100644
> --- a/tools/libxl/libxl.c
> +++ b/tools/libxl/libxl.c
> @@ -232,19 +232,19 @@ int libxl__domain_rename(libxl__gc *gc, uint32_t domid,
>  int libxl_domain_rename(libxl_ctx *ctx, uint32_t domid,
>                          const char *old_name, const char *new_name)
>  {
> -    libxl__gc gc = LIBXL_INIT_GC(ctx);
> +    GC_INIT(ctx);
>      int rc;
> -    rc = libxl__domain_rename(&gc, domid, old_name, new_name, XBT_NULL);
> -    libxl__free_all(&gc);
> +    rc = libxl__domain_rename(gc, domid, old_name, new_name, XBT_NULL);
> +    GC_FREE;
>      return rc;
>  }
> 
>  int libxl_domain_resume(libxl_ctx *ctx, uint32_t domid)
>  {
> -    libxl__gc gc = LIBXL_INIT_GC(ctx);
> +    GC_INIT(ctx);
>      int rc = 0;
> 
> -    if (LIBXL__DOMAIN_IS_TYPE(&gc,  domid, HVM)) {
> +    if (LIBXL__DOMAIN_IS_TYPE(gc,  domid, HVM)) {
>          LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Called domain_resume on "
>                  "non-cooperative hvm domain %u", domid);
>          rc = ERROR_NI;
> @@ -264,7 +264,7 @@ int libxl_domain_resume(libxl_ctx *ctx, uint32_t domid)
>          rc = ERROR_FAIL;
>      }
>  out:
> -    libxl__free_all(&gc);
> +    GC_FREE;
>      return rc;
>  }
> 
> @@ -277,7 +277,7 @@ out:
>  int libxl_domain_preserve(libxl_ctx *ctx, uint32_t domid,
>                            libxl_domain_create_info *info, const char *name_suffix, libxl_uuid new_uuid)
>  {
> -    libxl__gc gc = LIBXL_INIT_GC(ctx);
> +    GC_INIT(ctx);
>      struct xs_permissions roperm[2];
>      xs_transaction_t t;
>      char *preserved_name;
> @@ -287,27 +287,27 @@ int libxl_domain_preserve(libxl_ctx *ctx, uint32_t domid,
> 
>      int rc;
> 
> -    preserved_name = libxl__sprintf(&gc, "%s%s", info->name, name_suffix);
> +    preserved_name = libxl__sprintf(gc, "%s%s", info->name, name_suffix);
>      if (!preserved_name) {
> -        libxl__free_all(&gc);
> +        GC_FREE;
>          return ERROR_NOMEM;
>      }
> 
> -    uuid_string = libxl__uuid2string(&gc, new_uuid);
> +    uuid_string = libxl__uuid2string(gc, new_uuid);
>      if (!uuid_string) {
> -        libxl__free_all(&gc);
> +        GC_FREE;
>          return ERROR_NOMEM;
>      }
> 
> -    dom_path = libxl__xs_get_dompath(&gc, domid);
> +    dom_path = libxl__xs_get_dompath(gc, domid);
>      if (!dom_path) {
> -        libxl__free_all(&gc);
> +        GC_FREE;
>          return ERROR_FAIL;
>      }
> 
> -    vm_path = libxl__sprintf(&gc, "/vm/%s", uuid_string);
> +    vm_path = libxl__sprintf(gc, "/vm/%s", uuid_string);
>      if (!vm_path) {
> -        libxl__free_all(&gc);
> +        GC_FREE;
>          return ERROR_FAIL;
>      }
> 
> @@ -323,20 +323,20 @@ int libxl_domain_preserve(libxl_ctx *ctx, uint32_t domid,
>      xs_mkdir(ctx->xsh, t, vm_path);
>      xs_set_permissions(ctx->xsh, t, vm_path, roperm, ARRAY_SIZE(roperm));
> 
> -    xs_write(ctx->xsh, t, libxl__sprintf(&gc, "%s/vm", dom_path), vm_path, strlen(vm_path));
> -    rc = libxl__domain_rename(&gc, domid, info->name, preserved_name, t);
> +    xs_write(ctx->xsh, t, libxl__sprintf(gc, "%s/vm", dom_path), vm_path, strlen(vm_path));
> +    rc = libxl__domain_rename(gc, domid, info->name, preserved_name, t);
>      if (rc) {
> -        libxl__free_all(&gc);
> +        GC_FREE;
>          return rc;
>      }
> 
> -    xs_write(ctx->xsh, t, libxl__sprintf(&gc, "%s/uuid", vm_path), uuid_string, strlen(uuid_string));
> +    xs_write(ctx->xsh, t, libxl__sprintf(gc, "%s/uuid", vm_path), uuid_string, strlen(uuid_string));
> 
>      if (!xs_transaction_end(ctx->xsh, t, 0))
>          if (errno == EAGAIN)
>              goto retry_transaction;
> 
> -    libxl__free_all(&gc);
> +    GC_FREE;
>      return 0;
>  }
> 
> @@ -478,16 +478,16 @@ libxl_vminfo * libxl_list_vm(libxl_ctx *ctx, int *nb_vm)
>  int libxl_domain_suspend(libxl_ctx *ctx, libxl_domain_suspend_info *info,
>                           uint32_t domid, int fd)
>  {
> -    libxl__gc gc = LIBXL_INIT_GC(ctx);
> -    libxl_domain_type type = libxl__domain_type(&gc, domid);
> +    GC_INIT(ctx);
> +    libxl_domain_type type = libxl__domain_type(gc, domid);
>      int live = info != NULL && info->flags & XL_SUSPEND_LIVE;
>      int debug = info != NULL && info->flags & XL_SUSPEND_DEBUG;
>      int rc = 0;
> 
> -    rc = libxl__domain_suspend_common(&gc, domid, fd, type, live, debug);
> +    rc = libxl__domain_suspend_common(gc, domid, fd, type, live, debug);
>      if (!rc && type == LIBXL_DOMAIN_TYPE_HVM)
> -        rc = libxl__domain_save_device_model(&gc, domid, fd);
> -    libxl__free_all(&gc);
> +        rc = libxl__domain_save_device_model(gc, domid, fd);
> +    GC_FREE;
>      return rc;
>  }
> 
> @@ -517,17 +517,17 @@ int libxl_domain_core_dump(libxl_ctx *ctx, uint32_t domid,
> 
>  int libxl_domain_unpause(libxl_ctx *ctx, uint32_t domid)
>  {
> -    libxl__gc gc = LIBXL_INIT_GC(ctx);
> +    GC_INIT(ctx);
>      char *path;
>      char *state;
>      int ret, rc = 0;
> 
> -    if (LIBXL__DOMAIN_IS_TYPE(&gc,  domid, HVM)) {
> -        path = libxl__sprintf(&gc, "/local/domain/0/device-model/%d/state", domid);
> -        state = libxl__xs_read(&gc, XBT_NULL, path);
> +    if (LIBXL__DOMAIN_IS_TYPE(gc,  domid, HVM)) {
> +        path = libxl__sprintf(gc, "/local/domain/0/device-model/%d/state", domid);
> +        state = libxl__xs_read(gc, XBT_NULL, path);
>          if (state != NULL && !strcmp(state, "paused")) {
> -            libxl__xs_write(&gc, XBT_NULL, libxl__sprintf(&gc, "/local/domain/0/device-model/%d/command", domid), "continue");
> -            libxl__wait_for_device_model(&gc, domid, "running",
> +            libxl__xs_write(gc, XBT_NULL, libxl__sprintf(gc, "/local/domain/0/device-model/%d/command", domid), "continue");
> +            libxl__wait_for_device_model(gc, domid, "running",
>                                           NULL, NULL, NULL);
>          }
>      }
> @@ -536,7 +536,7 @@ int libxl_domain_unpause(libxl_ctx *ctx, uint32_t domid)
>          LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "unpausing domain %d", domid);
>          rc = ERROR_FAIL;
>      }
> -    libxl__free_all(&gc);
> +    GC_FREE;
>      return rc;
>  }
> 
> @@ -550,42 +550,42 @@ static char *req_table[] = {
> 
>  int libxl_domain_shutdown(libxl_ctx *ctx, uint32_t domid, int req)
>  {
> -    libxl__gc gc = LIBXL_INIT_GC(ctx);
> +    GC_INIT(ctx);
>      char *shutdown_path;
>      char *dom_path;
> 
>      if (req > ARRAY_SIZE(req_table)) {
> -        libxl__free_all(&gc);
> +        GC_FREE;
>          return ERROR_INVAL;
>      }
> 
> -    dom_path = libxl__xs_get_dompath(&gc, domid);
> +    dom_path = libxl__xs_get_dompath(gc, domid);
>      if (!dom_path) {
> -        libxl__free_all(&gc);
> +        GC_FREE;
>          return ERROR_FAIL;
>      }
> 
> -    if (LIBXL__DOMAIN_IS_TYPE(&gc,  domid, HVM)) {
> +    if (LIBXL__DOMAIN_IS_TYPE(gc,  domid, HVM)) {
>          unsigned long pvdriver = 0;
>          int ret;
>          ret = xc_get_hvm_param(ctx->xch, domid, HVM_PARAM_CALLBACK_IRQ, &pvdriver);
>          if (ret<0) {
>              LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "getting HVM callback IRQ");
> -            libxl__free_all(&gc);
> +            GC_FREE;
>              return ERROR_FAIL;
>          }
>          if (!pvdriver) {
>              LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "HVM domain without PV drivers:"
>                         " graceful shutdown not possible, use destroy");
> -            libxl__free_all(&gc);
> +            GC_FREE;
>              return ERROR_FAIL;
>          }
>      }
> 
> -    shutdown_path = libxl__sprintf(&gc, "%s/control/shutdown", dom_path);
> +    shutdown_path = libxl__sprintf(gc, "%s/control/shutdown", dom_path);
>      xs_write(ctx->xsh, XBT_NULL, shutdown_path, req_table[req], strlen(req_table[req]));
> 
> -    libxl__free_all(&gc);
> +    GC_FREE;
>      return 0;
>  }
> 
> @@ -607,7 +607,7 @@ int libxl_wait_for_domain_death(libxl_ctx *ctx, uint32_t domid, libxl_waiter *wa
> 
>  int libxl_wait_for_disk_ejects(libxl_ctx *ctx, uint32_t guest_domid, libxl_device_disk *disks, int num_disks, libxl_waiter *waiter)
>  {
> -    libxl__gc gc = LIBXL_INIT_GC(ctx);
> +    GC_INIT(ctx);
>      int i, rc = -1;
>      uint32_t domid = libxl_get_stubdom_id(ctx, guest_domid);
> 
> @@ -616,7 +616,7 @@ int libxl_wait_for_disk_ejects(libxl_ctx *ctx, uint32_t guest_domid, libxl_devic
> 
>      for (i = 0; i < num_disks; i++) {
>          if (asprintf(&(waiter[i].path), "%s/device/vbd/%d/eject",
> -                     libxl__xs_get_dompath(&gc, domid),
> +                     libxl__xs_get_dompath(gc, domid),
>                       libxl__device_disk_dev_number(disks[i].vdev,
>                                                     NULL, NULL)) < 0)
>              goto out;
> @@ -626,7 +626,7 @@ int libxl_wait_for_disk_ejects(libxl_ctx *ctx, uint32_t guest_domid, libxl_devic
>      }
>      rc = 0;
>  out:
> -    libxl__free_all(&gc);
> +    GC_FREE;
>      return rc;
>  }
> 
> @@ -680,22 +680,22 @@ int libxl_event_get_domain_death_info(libxl_ctx *ctx, uint32_t domid, libxl_even
> 
>  int libxl_event_get_disk_eject_info(libxl_ctx *ctx, uint32_t domid, libxl_event *event, libxl_device_disk *disk)
>  {
> -    libxl__gc gc = LIBXL_INIT_GC(ctx);
> +    GC_INIT(ctx);
>      char *path;
>      char *backend;
>      char *value;
>      char backend_type[BACKEND_STRING_SIZE+1];
> 
> -    value = libxl__xs_read(&gc, XBT_NULL, event->path);
> +    value = libxl__xs_read(gc, XBT_NULL, event->path);
> 
>      if (!value || strcmp(value,  "eject")) {
> -        libxl__free_all(&gc);
> +        GC_FREE;
>          return 0;
>      }
> 
>      path = strdup(event->path);
>      path[strlen(path) - 6] = '\0';
> -    backend = libxl__xs_read(&gc, XBT_NULL, libxl__sprintf(&gc, "%s/backend", path));
> +    backend = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/backend", path));
> 
>      sscanf(backend,
>              "/local/domain/%d/backend/%" TOSTRING(BACKEND_STRING_SIZE) "[a-z]/%*d/%*d",
> @@ -711,19 +711,19 @@ int libxl_event_get_disk_eject_info(libxl_ctx *ctx, uint32_t domid, libxl_event
>      disk->pdev_path = strdup("");
>      disk->format = LIBXL_DISK_FORMAT_EMPTY;
>      /* this value is returned to the user: do not free right away */
> -    disk->vdev = xs_read(ctx->xsh, XBT_NULL, libxl__sprintf(&gc, "%s/dev", backend), NULL);
> +    disk->vdev = xs_read(ctx->xsh, XBT_NULL, libxl__sprintf(gc, "%s/dev", backend), NULL);
>      disk->removable = 1;
>      disk->readwrite = 0;
>      disk->is_cdrom = 1;
> 
>      free(path);
> -    libxl__free_all(&gc);
> +    GC_FREE;
>      return 1;
>  }
> 
>  int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid, int force)
>  {
> -    libxl__gc gc = LIBXL_INIT_GC(ctx);
> +    GC_INIT(ctx);
>      libxl_dominfo dominfo;
>      char *dom_path;
>      char *vm_path;
> @@ -740,40 +740,40 @@ int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid, int force)
>          return rc;
>      }
> 
> -    switch (libxl__domain_type(&gc, domid)) {
> +    switch (libxl__domain_type(gc, domid)) {
>      case LIBXL_DOMAIN_TYPE_HVM:
>          dm_present = 1;
>          break;
>      case LIBXL_DOMAIN_TYPE_PV:
> -        pid = libxl__xs_read(&gc, XBT_NULL, libxl__sprintf(&gc, "/local/domain/%d/image/device-model-pid", domid));
> +        pid = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "/local/domain/%d/image/device-model-pid", domid));
>          dm_present = (pid != NULL);
>          break;
>      default:
>          abort();
>      }
> 
> -    dom_path = libxl__xs_get_dompath(&gc, domid);
> +    dom_path = libxl__xs_get_dompath(gc, domid);
>      if (!dom_path) {
>          rc = ERROR_FAIL;
>          goto out;
>      }
> 
> -    if (libxl__device_pci_destroy_all(&gc, domid) < 0)
> +    if (libxl__device_pci_destroy_all(gc, domid) < 0)
>          LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "pci shutdown failed for domid %d", domid);
>      rc = xc_domain_pause(ctx->xch, domid);
>      if (rc < 0) {
>          LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, rc, "xc_domain_pause failed for %d", domid);
>      }
>      if (dm_present) {
> -        if (libxl__destroy_device_model(&gc, domid) < 0)
> +        if (libxl__destroy_device_model(gc, domid) < 0)
>              LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "libxl__destroy_device_model failed for %d", domid);
> 
> -        libxl__qmp_cleanup(&gc, domid);
> +        libxl__qmp_cleanup(gc, domid);
>      }
> -    if (libxl__devices_destroy(&gc, domid, force) < 0)
> +    if (libxl__devices_destroy(gc, domid, force) < 0)
>          LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "libxl_devices_dispose failed for %d", domid);
> 
> -    vm_path = libxl__xs_read(&gc, XBT_NULL, libxl__sprintf(&gc, "%s/vm", dom_path));
> +    vm_path = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/vm", dom_path));
>      if (vm_path)
>          if (!xs_rm(ctx->xsh, XBT_NULL, vm_path))
>              LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "xs_rm failed for %s", vm_path);
> @@ -781,9 +781,9 @@ int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid, int force)
>      if (!xs_rm(ctx->xsh, XBT_NULL, dom_path))
>          LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "xs_rm failed for %s", dom_path);
> 
> -    xs_rm(ctx->xsh, XBT_NULL, libxl__xs_libxl_path(&gc, domid));
> +    xs_rm(ctx->xsh, XBT_NULL, libxl__xs_libxl_path(gc, domid));
> 
> -    libxl__userdata_destroyall(&gc, domid);
> +    libxl__userdata_destroyall(gc, domid);
> 
>      rc = xc_domain_destroy(ctx->xch, domid);
>      if (rc < 0) {
> @@ -793,16 +793,16 @@ int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid, int force)
>      }
>      rc = 0;
>  out:
> -    libxl__free_all(&gc);
> +    GC_FREE;
>      return rc;
>  }
> 
>  int libxl_console_exec(libxl_ctx *ctx, uint32_t domid, int cons_num, libxl_console_type type)
>  {
> -    libxl__gc gc = LIBXL_INIT_GC(ctx);
> -    char *p = libxl__sprintf(&gc, "%s/xenconsole", libxl_private_bindir_path());
> -    char *domid_s = libxl__sprintf(&gc, "%d", domid);
> -    char *cons_num_s = libxl__sprintf(&gc, "%d", cons_num);
> +    GC_INIT(ctx);
> +    char *p = libxl__sprintf(gc, "%s/xenconsole", libxl_private_bindir_path());
> +    char *domid_s = libxl__sprintf(gc, "%d", domid);
> +    char *cons_num_s = libxl__sprintf(gc, "%d", cons_num);
>      char *cons_type_s;
> 
>      switch (type) {
> @@ -819,20 +819,20 @@ int libxl_console_exec(libxl_ctx *ctx, uint32_t domid, int cons_num, libxl_conso
>      execl(p, p, domid_s, "--num", cons_num_s, "--type", cons_type_s, (void *)NULL);
> 
>  out:
> -    libxl__free_all(&gc);
> +    GC_FREE;
>      return ERROR_FAIL;
>  }
> 
>  int libxl_primary_console_exec(libxl_ctx *ctx, uint32_t domid_vm)
>  {
> -    libxl__gc gc = LIBXL_INIT_GC(ctx);
> +    GC_INIT(ctx);
>      uint32_t stubdomid = libxl_get_stubdom_id(ctx, domid_vm);
>      int rc;
>      if (stubdomid)
>          rc = libxl_console_exec(ctx, stubdomid,
>                                  STUBDOM_CONSOLE_SERIAL, LIBXL_CONSOLE_TYPE_PV);
>      else {
> -        switch (libxl__domain_type(&gc, domid_vm)) {
> +        switch (libxl__domain_type(gc, domid_vm)) {
>          case LIBXL_DOMAIN_TYPE_HVM:
>              rc = libxl_console_exec(ctx, domid_vm, 0, LIBXL_CONSOLE_TYPE_SERIAL);
>              break;
> @@ -843,13 +843,13 @@ int libxl_primary_console_exec(libxl_ctx *ctx, uint32_t domid_vm)
>              abort();
>          }
>      }
> -    libxl__free_all(&gc);
> +    GC_FREE;
>      return rc;
>  }
> 
>  int libxl_vncviewer_exec(libxl_ctx *ctx, uint32_t domid, int autopass)
>  {
> -    libxl__gc gc = LIBXL_INIT_GC(ctx);
> +    GC_INIT(ctx);
>      const char *vnc_port;
>      const char *vnc_listen = NULL, *vnc_pass = NULL;
>      int port = 0, autopass_fd = -1;
> @@ -860,19 +860,19 @@ int libxl_vncviewer_exec(libxl_ctx *ctx, uint32_t domid, int autopass)
>          NULL,
>      };
> 
> -    vnc_port = libxl__xs_read(&gc, XBT_NULL,
> -                            libxl__sprintf(&gc,
> +    vnc_port = libxl__xs_read(gc, XBT_NULL,
> +                            libxl__sprintf(gc,
>                              "/local/domain/%d/console/vnc-port", domid));
>      if ( vnc_port )
>          port = atoi(vnc_port) - 5900;
> 
> -    vnc_listen = libxl__xs_read(&gc, XBT_NULL,
> -                                libxl__sprintf(&gc,
> +    vnc_listen = libxl__xs_read(gc, XBT_NULL,
> +                                libxl__sprintf(gc,
>                              "/local/domain/%d/console/vnc-listen", domid));
> 
>      if ( autopass )
> -        vnc_pass = libxl__xs_read(&gc, XBT_NULL,
> -                                  libxl__sprintf(&gc,
> +        vnc_pass = libxl__xs_read(gc, XBT_NULL,
> +                                  libxl__sprintf(gc,
>                              "/local/domain/%d/console/vnc-pass", domid));
> 
>      if ( NULL == vnc_listen )
> @@ -881,7 +881,7 @@ int libxl_vncviewer_exec(libxl_ctx *ctx, uint32_t domid, int autopass)
>      if ( (vnc_bin = getenv("VNCVIEWER")) )
>          args[0] = vnc_bin;
> 
> -    args[1] = libxl__sprintf(&gc, "%s:%d", vnc_listen, port);
> +    args[1] = libxl__sprintf(gc, "%s:%d", vnc_listen, port);
> 
>      if ( vnc_pass ) {
>          char tmpname[] = "/tmp/vncautopass.XXXXXX";
> @@ -916,7 +916,7 @@ int libxl_vncviewer_exec(libxl_ctx *ctx, uint32_t domid, int autopass)
>      abort();
> 
>   x_fail:
> -    libxl__free_all(&gc);
> +    GC_FREE;
>      return ERROR_FAIL;
>  }
> 
> @@ -970,17 +970,17 @@ static int libxl__device_from_disk(libxl__gc *gc, uint32_t domid,
> 
>  int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *disk)
>  {
> -    libxl__gc gc = LIBXL_INIT_GC(ctx);
> +    GC_INIT(ctx);
>      flexarray_t *front;
>      flexarray_t *back;
>      char *dev;
>      libxl__device device;
>      int major, minor, rc;
> 
> -    rc = libxl__device_disk_set_backend(&gc, disk);
> +    rc = libxl__device_disk_set_backend(gc, disk);
>      if (rc) goto out;
> 
> -    rc = libxl__device_disk_set_backend(&gc, disk);
> +    rc = libxl__device_disk_set_backend(gc, disk);
>      if (rc) goto out;
> 
>      front = flexarray_make(16, 1);
> @@ -1001,7 +1001,7 @@ int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *dis
>          goto out_free;
>      }
> 
> -    rc = libxl__device_from_disk(&gc, domid, disk, &device);
> +    rc = libxl__device_from_disk(gc, domid, disk, &device);
>      if (rc != 0) {
>          LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Invalid or unsupported"
>                 " virtual disk identifier %s", disk->vdev);
> @@ -1014,7 +1014,7 @@ int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *dis
>      do_backend_phy:
>              libxl__device_physdisk_major_minor(dev, &major, &minor);
>              flexarray_append(back, "physical-device");
> -            flexarray_append(back, libxl__sprintf(&gc, "%x:%x", major, minor));
> +            flexarray_append(back, libxl__sprintf(gc, "%x:%x", major, minor));
> 
>              flexarray_append(back, "params");
>              flexarray_append(back, dev);
> @@ -1022,13 +1022,13 @@ int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *dis
>              assert(device.backend_kind == LIBXL__DEVICE_KIND_VBD);
>              break;
>          case LIBXL_DISK_BACKEND_TAP:
> -            dev = libxl__blktap_devpath(&gc, disk->pdev_path, disk->format);
> +            dev = libxl__blktap_devpath(gc, disk->pdev_path, disk->format);
>              if (!dev) {
>                  rc = ERROR_FAIL;
>                  goto out_free;
>              }
>              flexarray_append(back, "tapdisk-params");
> -            flexarray_append(back, libxl__sprintf(&gc, "%s:%s",
> +            flexarray_append(back, libxl__sprintf(gc, "%s:%s",
>                  libxl__device_disk_string_of_format(disk->format),
>                  disk->pdev_path));
> 
> @@ -1036,7 +1036,7 @@ int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *dis
>              goto do_backend_phy;
>          case LIBXL_DISK_BACKEND_QDISK:
>              flexarray_append(back, "params");
> -            flexarray_append(back, libxl__sprintf(&gc, "%s:%s",
> +            flexarray_append(back, libxl__sprintf(gc, "%s:%s",
>                            libxl__device_disk_string_of_format(disk->format), disk->pdev_path));
>              assert(device.backend_kind == LIBXL__DEVICE_KIND_QDISK);
>              break;
> @@ -1047,15 +1047,15 @@ int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *dis
>      }
> 
>      flexarray_append(back, "frontend-id");
> -    flexarray_append(back, libxl__sprintf(&gc, "%d", domid));
> +    flexarray_append(back, libxl__sprintf(gc, "%d", domid));
>      flexarray_append(back, "online");
>      flexarray_append(back, "1");
>      flexarray_append(back, "removable");
> -    flexarray_append(back, libxl__sprintf(&gc, "%d", (disk->removable) ? 1 : 0));
> +    flexarray_append(back, libxl__sprintf(gc, "%d", (disk->removable) ? 1 : 0));
>      flexarray_append(back, "bootable");
> -    flexarray_append(back, libxl__sprintf(&gc, "%d", 1));
> +    flexarray_append(back, libxl__sprintf(gc, "%d", 1));
>      flexarray_append(back, "state");
> -    flexarray_append(back, libxl__sprintf(&gc, "%d", 1));
> +    flexarray_append(back, libxl__sprintf(gc, "%d", 1));
>      flexarray_append(back, "dev");
>      flexarray_append(back, disk->vdev);
>      flexarray_append(back, "type");
> @@ -1066,17 +1066,17 @@ int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *dis
>      flexarray_append(back, disk->is_cdrom ? "cdrom" : "disk");
> 
>      flexarray_append(front, "backend-id");
> -    flexarray_append(front, libxl__sprintf(&gc, "%d", disk->backend_domid));
> +    flexarray_append(front, libxl__sprintf(gc, "%d", disk->backend_domid));
>      flexarray_append(front, "state");
> -    flexarray_append(front, libxl__sprintf(&gc, "%d", 1));
> +    flexarray_append(front, libxl__sprintf(gc, "%d", 1));
>      flexarray_append(front, "virtual-device");
> -    flexarray_append(front, libxl__sprintf(&gc, "%d", device.devid));
> +    flexarray_append(front, libxl__sprintf(gc, "%d", device.devid));
>      flexarray_append(front, "device-type");
>      flexarray_append(front, disk->is_cdrom ? "cdrom" : "disk");
> 
> -    libxl__device_generic_add(&gc, &device,
> -                             libxl__xs_kvs_of_flexarray(&gc, back, back->count),
> -                             libxl__xs_kvs_of_flexarray(&gc, front, front->count));
> +    libxl__device_generic_add(gc, &device,
> +                             libxl__xs_kvs_of_flexarray(gc, back, back->count),
> +                             libxl__xs_kvs_of_flexarray(gc, front, front->count));
> 
>      rc = 0;
> 
> @@ -1084,39 +1084,39 @@ out_free:
>      flexarray_free(back);
>      flexarray_free(front);
>  out:
> -    libxl__free_all(&gc);
> +    GC_FREE;
>      return rc;
>  }
> 
>  int libxl_device_disk_remove(libxl_ctx *ctx, uint32_t domid,
>                               libxl_device_disk *disk)
>  {
> -    libxl__gc gc = LIBXL_INIT_GC(ctx);
> +    GC_INIT(ctx);
>      libxl__device device;
>      int rc;
> 
> -    rc = libxl__device_from_disk(&gc, domid, disk, &device);
> +    rc = libxl__device_from_disk(gc, domid, disk, &device);
>      if (rc != 0) goto out;
> 
> -    rc = libxl__device_remove(&gc, &device, 1);
> +    rc = libxl__device_remove(gc, &device, 1);
>  out:
> -    libxl__free_all(&gc);
> +    GC_FREE;
>      return rc;
>  }
> 
>  int libxl_device_disk_destroy(libxl_ctx *ctx, uint32_t domid,
>                                libxl_device_disk *disk)
>  {
> -    libxl__gc gc = LIBXL_INIT_GC(ctx);
> +    GC_INIT(ctx);
>      libxl__device device;
>      int rc;
> 
> -    rc = libxl__device_from_disk(&gc, domid, disk, &device);
> +    rc = libxl__device_from_disk(gc, domid, disk, &device);
>      if (rc != 0) goto out;
> 
> -    rc = libxl__device_destroy(&gc, &device);
> +    rc = libxl__device_destroy(gc, &device);
>  out:
> -    libxl__free_all(&gc);
> +    GC_FREE;
>      return rc;
>  }
> 
> @@ -1168,27 +1168,27 @@ static void libxl__device_disk_from_xs_be(libxl__gc *gc,
>  int libxl_devid_to_device_disk(libxl_ctx *ctx, uint32_t domid,
>                                 int devid, libxl_device_disk *disk)
>  {
> -    libxl__gc gc = LIBXL_INIT_GC(ctx);
> +    GC_INIT(ctx);
>      char *dompath, *path;
>      int rc = ERROR_FAIL;
> 
>      libxl_device_disk_init(ctx, disk);
> 
> -    dompath = libxl__xs_get_dompath(&gc, domid);
> +    dompath = libxl__xs_get_dompath(gc, domid);
>      if (!dompath) {
>          goto out;
>      }
> -    path = libxl__xs_read(&gc, XBT_NULL,
> -                          libxl__sprintf(&gc, "%s/device/vbd/%d/backend",
> +    path = libxl__xs_read(gc, XBT_NULL,
> +                          libxl__sprintf(gc, "%s/device/vbd/%d/backend",
>                                           dompath, devid));
>      if (!path)
>          goto out;
> 
> -    libxl__device_disk_from_xs_be(&gc, path, disk);
> +    libxl__device_disk_from_xs_be(gc, path, disk);
> 
>      rc = 0;
>  out:
> -    libxl__free_all(&gc);
> +    GC_FREE;
>      return rc;
>  }
> 
> @@ -1228,22 +1228,22 @@ static int libxl__append_disk_list_of_type(libxl__gc *gc,
> 
>  libxl_device_disk *libxl_device_disk_list(libxl_ctx *ctx, uint32_t domid, int *num)
>  {
> -    libxl__gc gc = LIBXL_INIT_GC(ctx);
> +    GC_INIT(ctx);
>      libxl_device_disk *disks = NULL;
>      int rc;
> 
>      *num = 0;
> 
> -    rc = libxl__append_disk_list_of_type(&gc, domid, "vbd", &disks, num);
> +    rc = libxl__append_disk_list_of_type(gc, domid, "vbd", &disks, num);
>      if (rc) goto out_err;
> 
> -    rc = libxl__append_disk_list_of_type(&gc, domid, "tap", &disks, num);
> +    rc = libxl__append_disk_list_of_type(gc, domid, "tap", &disks, num);
>      if (rc) goto out_err;
> 
> -    rc = libxl__append_disk_list_of_type(&gc, domid, "qdisk", &disks, num);
> +    rc = libxl__append_disk_list_of_type(gc, domid, "qdisk", &disks, num);
>      if (rc) goto out_err;
> 
> -    libxl__free_all(&gc);
> +    GC_FREE;
>      return disks;
> 
>  out_err:
> @@ -1259,35 +1259,35 @@ out_err:
>  int libxl_device_disk_getinfo(libxl_ctx *ctx, uint32_t domid,
>                                libxl_device_disk *disk, libxl_diskinfo *diskinfo)
>  {
> -    libxl__gc gc = LIBXL_INIT_GC(ctx);
> +    GC_INIT(ctx);
>      char *dompath, *diskpath;
>      char *val;
> 
> -    dompath = libxl__xs_get_dompath(&gc, domid);
> +    dompath = libxl__xs_get_dompath(gc, domid);
>      diskinfo->devid = libxl__device_disk_dev_number(disk->vdev, NULL, NULL);
> 
>      /* tap devices entries in xenstore are written as vbd devices. */
> -    diskpath = libxl__sprintf(&gc, "%s/device/vbd/%d", dompath, diskinfo->devid);
> +    diskpath = libxl__sprintf(gc, "%s/device/vbd/%d", dompath, diskinfo->devid);
>      diskinfo->backend = xs_read(ctx->xsh, XBT_NULL,
> -                                libxl__sprintf(&gc, "%s/backend", diskpath), NULL);
> +                                libxl__sprintf(gc, "%s/backend", diskpath), NULL);
>      if (!diskinfo->backend) {
> -        libxl__free_all(&gc);
> +        GC_FREE;
>          return ERROR_FAIL;
>      }
> -    val = libxl__xs_read(&gc, XBT_NULL, libxl__sprintf(&gc, "%s/backend-id", diskpath));
> +    val = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/backend-id", diskpath));
>      diskinfo->backend_id = val ? strtoul(val, NULL, 10) : -1;
> -    val = libxl__xs_read(&gc, XBT_NULL, libxl__sprintf(&gc, "%s/state", diskpath));
> +    val = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/state", diskpath));
>      diskinfo->state = val ? strtoul(val, NULL, 10) : -1;
> -    val = libxl__xs_read(&gc, XBT_NULL, libxl__sprintf(&gc, "%s/event-channel", diskpath));
> +    val = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/event-channel", diskpath));
>      diskinfo->evtch = val ? strtoul(val, NULL, 10) : -1;
> -    val = libxl__xs_read(&gc, XBT_NULL, libxl__sprintf(&gc, "%s/ring-ref", diskpath));
> +    val = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/ring-ref", diskpath));
>      diskinfo->rref = val ? strtoul(val, NULL, 10) : -1;
>      diskinfo->frontend = xs_read(ctx->xsh, XBT_NULL,
> -                                 libxl__sprintf(&gc, "%s/frontend", diskinfo->backend), NULL);
> -    val = libxl__xs_read(&gc, XBT_NULL, libxl__sprintf(&gc, "%s/frontend-id", diskinfo->backend));
> +                                 libxl__sprintf(gc, "%s/frontend", diskinfo->backend), NULL);
> +    val = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/frontend-id", diskinfo->backend));
>      diskinfo->frontend_id = val ? strtoul(val, NULL, 10) : -1;
> 
> -    libxl__free_all(&gc);
> +    GC_FREE;
>      return 0;
>  }
> 
> @@ -1331,12 +1331,12 @@ out:
> 
>  char * libxl_device_disk_local_attach(libxl_ctx *ctx, libxl_device_disk *disk)
>  {
> -    libxl__gc gc = LIBXL_INIT_GC(ctx);
> +    GC_INIT(ctx);
>      char *dev = NULL;
>      char *ret = NULL;
>      int rc;
> 
> -    rc = libxl__device_disk_set_backend(&gc, disk);
> +    rc = libxl__device_disk_set_backend(gc, disk);
>      if (rc) goto out;
> 
>      switch (disk->backend) {
> @@ -1355,7 +1355,7 @@ char * libxl_device_disk_local_attach(libxl_ctx *ctx, libxl_device_disk *disk)
>                  dev = disk->pdev_path;
>                  break;
>              case LIBXL_DISK_FORMAT_VHD:
> -                dev = libxl__blktap_devpath(&gc, disk->pdev_path,
> +                dev = libxl__blktap_devpath(gc, disk->pdev_path,
>                                              disk->format);
>                  break;
>              case LIBXL_DISK_FORMAT_QCOW:
> @@ -1386,7 +1386,7 @@ char * libxl_device_disk_local_attach(libxl_ctx *ctx, libxl_device_disk *disk)
>   out:
>      if (dev != NULL)
>          ret = strdup(dev);
> -    libxl__free_all(&gc);
> +    GC_FREE;
>      return ret;
>  }
> 
> @@ -1448,7 +1448,7 @@ static int libxl__device_from_nic(libxl__gc *gc, uint32_t domid,
> 
>  int libxl_device_nic_add(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic)
>  {
> -    libxl__gc gc = LIBXL_INIT_GC(ctx);
> +    GC_INIT(ctx);
>      flexarray_t *front;
>      flexarray_t *back;
>      libxl__device device;
> @@ -1467,59 +1467,59 @@ int libxl_device_nic_add(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic)
>      }
> 
>      if (nic->devid == -1) {
> -        if (!(dompath = libxl__xs_get_dompath(&gc, domid))) {
> +        if (!(dompath = libxl__xs_get_dompath(gc, domid))) {
>              rc = ERROR_FAIL;
>              goto out_free;
>          }
> -        if (!(l = libxl__xs_directory(&gc, XBT_NULL,
> -                                     libxl__sprintf(&gc, "%s/device/vif", dompath), &nb))) {
> +        if (!(l = libxl__xs_directory(gc, XBT_NULL,
> +                                     libxl__sprintf(gc, "%s/device/vif", dompath), &nb))) {
>              nic->devid = 0;
>          } else {
>              nic->devid = strtoul(l[nb - 1], NULL, 10) + 1;
>          }
>      }
> 
> -    rc = libxl__device_from_nic(&gc, domid, nic, &device);
> +    rc = libxl__device_from_nic(gc, domid, nic, &device);
>      if ( rc != 0 ) goto out_free;
> 
>      flexarray_append(back, "frontend-id");
> -    flexarray_append(back, libxl__sprintf(&gc, "%d", domid));
> +    flexarray_append(back, libxl__sprintf(gc, "%d", domid));
>      flexarray_append(back, "online");
>      flexarray_append(back, "1");
>      flexarray_append(back, "state");
> -    flexarray_append(back, libxl__sprintf(&gc, "%d", 1));
> +    flexarray_append(back, libxl__sprintf(gc, "%d", 1));
>      if (nic->script) {
>          flexarray_append(back, "script");
>          flexarray_append(back, nic->script[0]=='/' ? nic->script
> -                         : libxl__sprintf(&gc, "%s/%s",
> +                         : libxl__sprintf(gc, "%s/%s",
>                                            libxl_xen_script_dir_path(),
>                                            nic->script));
>      }
>      flexarray_append(back, "mac");
> -    flexarray_append(back,libxl__sprintf(&gc,
> +    flexarray_append(back,libxl__sprintf(gc,
>                                      LIBXL_MAC_FMT, LIBXL_MAC_BYTES(nic->mac)));
>      if (nic->ip) {
>          flexarray_append(back, "ip");
> -        flexarray_append(back, libxl__strdup(&gc, nic->ip));
> +        flexarray_append(back, libxl__strdup(gc, nic->ip));
>      }
> 
>      flexarray_append(back, "bridge");
> -    flexarray_append(back, libxl__strdup(&gc, nic->bridge));
> +    flexarray_append(back, libxl__strdup(gc, nic->bridge));
>      flexarray_append(back, "handle");
> -    flexarray_append(back, libxl__sprintf(&gc, "%d", nic->devid));
> +    flexarray_append(back, libxl__sprintf(gc, "%d", nic->devid));
> 
>      flexarray_append(front, "backend-id");
> -    flexarray_append(front, libxl__sprintf(&gc, "%d", nic->backend_domid));
> +    flexarray_append(front, libxl__sprintf(gc, "%d", nic->backend_domid));
>      flexarray_append(front, "state");
> -    flexarray_append(front, libxl__sprintf(&gc, "%d", 1));
> +    flexarray_append(front, libxl__sprintf(gc, "%d", 1));
>      flexarray_append(front, "handle");
> -    flexarray_append(front, libxl__sprintf(&gc, "%d", nic->devid));
> +    flexarray_append(front, libxl__sprintf(gc, "%d", nic->devid));
>      flexarray_append(front, "mac");
> -    flexarray_append(front, libxl__sprintf(&gc,
> +    flexarray_append(front, libxl__sprintf(gc,
>                                      LIBXL_MAC_FMT, LIBXL_MAC_BYTES(nic->mac)));
> -    libxl__device_generic_add(&gc, &device,
> -                             libxl__xs_kvs_of_flexarray(&gc, back, back->count),
> -                             libxl__xs_kvs_of_flexarray(&gc, front, front->count));
> +    libxl__device_generic_add(gc, &device,
> +                             libxl__xs_kvs_of_flexarray(gc, back, back->count),
> +                             libxl__xs_kvs_of_flexarray(gc, front, front->count));
> 
>      /* FIXME: wait for plug */
>      rc = 0;
> @@ -1527,39 +1527,39 @@ out_free:
>      flexarray_free(back);
>      flexarray_free(front);
>  out:
> -    libxl__free_all(&gc);
> +    GC_FREE;
>      return rc;
>  }
> 
>  int libxl_device_nic_remove(libxl_ctx *ctx, uint32_t domid,
>                              libxl_device_nic *nic)
>  {
> -    libxl__gc gc = LIBXL_INIT_GC(ctx);
> +    GC_INIT(ctx);
>      libxl__device device;
>      int rc;
> 
> -    rc = libxl__device_from_nic(&gc, domid, nic, &device);
> +    rc = libxl__device_from_nic(gc, domid, nic, &device);
>      if (rc != 0) goto out;
> 
> -    rc = libxl__device_remove(&gc, &device, 1);
> +    rc = libxl__device_remove(gc, &device, 1);
>  out:
> -    libxl__free_all(&gc);
> +    GC_FREE;
>      return rc;
>  }
> 
>  int libxl_device_nic_destroy(libxl_ctx *ctx, uint32_t domid,
>                                    libxl_device_nic *nic)
>  {
> -    libxl__gc gc = LIBXL_INIT_GC(ctx);
> +    GC_INIT(ctx);
>      libxl__device device;
>      int rc;
> 
> -    rc = libxl__device_from_nic(&gc, domid, nic, &device);
> +    rc = libxl__device_from_nic(gc, domid, nic, &device);
>      if (rc != 0) goto out;
> 
> -    rc = libxl__device_destroy(&gc, &device);
> +    rc = libxl__device_destroy(gc, &device);
>  out:
> -    libxl__free_all(&gc);
> +    GC_FREE;
>      return rc;
>  }
> 
> @@ -1607,26 +1607,26 @@ static void libxl__device_nic_from_xs_be(libxl__gc *gc,
>  int libxl_devid_to_device_nic(libxl_ctx *ctx, uint32_t domid,
>                                int devid, libxl_device_nic *nic)
>  {
> -    libxl__gc gc = LIBXL_INIT_GC(ctx);
> +    GC_INIT(ctx);
>      char *dompath, *path;
>      int rc = ERROR_FAIL;
> 
>      memset(nic, 0, sizeof (libxl_device_nic));
> -    dompath = libxl__xs_get_dompath(&gc, domid);
> +    dompath = libxl__xs_get_dompath(gc, domid);
>      if (!dompath)
>          goto out;
> 
> -    path = libxl__xs_read(&gc, XBT_NULL,
> -                          libxl__sprintf(&gc, "%s/device/vif/%d/backend",
> +    path = libxl__xs_read(gc, XBT_NULL,
> +                          libxl__sprintf(gc, "%s/device/vif/%d/backend",
>                                           dompath, devid));
>      if (!path)
>          goto out;
> 
> -    libxl__device_nic_from_xs_be(&gc, path, nic);
> +    libxl__device_nic_from_xs_be(gc, path, nic);
> 
>      rc = 0;
>  out:
> -    libxl__free_all(&gc);
> +    GC_FREE;
>      return rc;
>  }
> 
> @@ -1665,16 +1665,16 @@ static int libxl__append_nic_list_of_type(libxl__gc *gc,
> 
>  libxl_device_nic *libxl_device_nic_list(libxl_ctx *ctx, uint32_t domid, int *num)
>  {
> -    libxl__gc gc = LIBXL_INIT_GC(ctx);
> +    GC_INIT(ctx);
>      libxl_device_nic *nics = NULL;
>      int rc;
> 
>      *num = 0;
> 
> -    rc = libxl__append_nic_list_of_type(&gc, domid, "vif", &nics, num);
> +    rc = libxl__append_nic_list_of_type(gc, domid, "vif", &nics, num);
>      if (rc) goto out_err;
> 
> -    libxl__free_all(&gc);
> +    GC_FREE;
>      return nics;
> 
>  out_err:
> @@ -1690,36 +1690,36 @@ out_err:
>  int libxl_device_nic_getinfo(libxl_ctx *ctx, uint32_t domid,
>                                libxl_device_nic *nic, libxl_nicinfo *nicinfo)
>  {
> -    libxl__gc gc = LIBXL_INIT_GC(ctx);
> +    GC_INIT(ctx);
>      char *dompath, *nicpath;
>      char *val;
> 
> -    dompath = libxl__xs_get_dompath(&gc, domid);
> +    dompath = libxl__xs_get_dompath(gc, domid);
>      nicinfo->devid = nic->devid;
> 
> -    nicpath = libxl__sprintf(&gc, "%s/device/vif/%d", dompath, nicinfo->devid);
> +    nicpath = libxl__sprintf(gc, "%s/device/vif/%d", dompath, nicinfo->devid);
>      nicinfo->backend = xs_read(ctx->xsh, XBT_NULL,
> -                                libxl__sprintf(&gc, "%s/backend", nicpath), NULL);
> +                                libxl__sprintf(gc, "%s/backend", nicpath), NULL);
>      if (!nicinfo->backend) {
> -        libxl__free_all(&gc);
> +        GC_FREE;
>          return ERROR_FAIL;
>      }
> -    val = libxl__xs_read(&gc, XBT_NULL, libxl__sprintf(&gc, "%s/backend-id", nicpath));
> +    val = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/backend-id", nicpath));
>      nicinfo->backend_id = val ? strtoul(val, NULL, 10) : -1;
> -    val = libxl__xs_read(&gc, XBT_NULL, libxl__sprintf(&gc, "%s/state", nicpath));
> +    val = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/state", nicpath));
>      nicinfo->state = val ? strtoul(val, NULL, 10) : -1;
> -    val = libxl__xs_read(&gc, XBT_NULL, libxl__sprintf(&gc, "%s/event-channel", nicpath));
> +    val = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/event-channel", nicpath));
>      nicinfo->evtch = val ? strtoul(val, NULL, 10) : -1;
> -    val = libxl__xs_read(&gc, XBT_NULL, libxl__sprintf(&gc, "%s/tx-ring-ref", nicpath));
> +    val = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/tx-ring-ref", nicpath));
>      nicinfo->rref_tx = val ? strtoul(val, NULL, 10) : -1;
> -    val = libxl__xs_read(&gc, XBT_NULL, libxl__sprintf(&gc, "%s/rx-ring-ref", nicpath));
> +    val = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/rx-ring-ref", nicpath));
>      nicinfo->rref_rx = val ? strtoul(val, NULL, 10) : -1;
>      nicinfo->frontend = xs_read(ctx->xsh, XBT_NULL,
> -                                 libxl__sprintf(&gc, "%s/frontend", nicinfo->backend), NULL);
> -    val = libxl__xs_read(&gc, XBT_NULL, libxl__sprintf(&gc, "%s/frontend-id", nicinfo->backend));
> +                                 libxl__sprintf(gc, "%s/frontend", nicinfo->backend), NULL);
> +    val = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/frontend-id", nicinfo->backend));
>      nicinfo->frontend_id = val ? strtoul(val, NULL, 10) : -1;
> 
> -    libxl__free_all(&gc);
> +    GC_FREE;
>      return 0;
>  }
> 
> @@ -1825,7 +1825,7 @@ static int libxl__device_from_vkb(libxl__gc *gc, uint32_t domid,
> 
>  int libxl_device_vkb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vkb *vkb)
>  {
> -    libxl__gc gc = LIBXL_INIT_GC(ctx);
> +    GC_INIT(ctx);
>      flexarray_t *front;
>      flexarray_t *back;
>      libxl__device device;
> @@ -1842,64 +1842,64 @@ int libxl_device_vkb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vkb *vkb)
>          goto out_free;
>      }
> 
> -    rc = libxl__device_from_vkb(&gc, domid, vkb, &device);
> +    rc = libxl__device_from_vkb(gc, domid, vkb, &device);
>      if (rc != 0) goto out_free;
> 
>      flexarray_append(back, "frontend-id");
> -    flexarray_append(back, libxl__sprintf(&gc, "%d", domid));
> +    flexarray_append(back, libxl__sprintf(gc, "%d", domid));
>      flexarray_append(back, "online");
>      flexarray_append(back, "1");
>      flexarray_append(back, "state");
> -    flexarray_append(back, libxl__sprintf(&gc, "%d", 1));
> +    flexarray_append(back, libxl__sprintf(gc, "%d", 1));
>      flexarray_append(back, "domain");
> -    flexarray_append(back, libxl__domid_to_name(&gc, domid));
> +    flexarray_append(back, libxl__domid_to_name(gc, domid));
> 
>      flexarray_append(front, "backend-id");
> -    flexarray_append(front, libxl__sprintf(&gc, "%d", vkb->backend_domid));
> +    flexarray_append(front, libxl__sprintf(gc, "%d", vkb->backend_domid));
>      flexarray_append(front, "state");
> -    flexarray_append(front, libxl__sprintf(&gc, "%d", 1));
> +    flexarray_append(front, libxl__sprintf(gc, "%d", 1));
> 
> -    libxl__device_generic_add(&gc, &device,
> -                             libxl__xs_kvs_of_flexarray(&gc, back, back->count),
> -                             libxl__xs_kvs_of_flexarray(&gc, front, front->count));
> +    libxl__device_generic_add(gc, &device,
> +                             libxl__xs_kvs_of_flexarray(gc, back, back->count),
> +                             libxl__xs_kvs_of_flexarray(gc, front, front->count));
>      rc = 0;
>  out_free:
>      flexarray_free(back);
>      flexarray_free(front);
>  out:
> -    libxl__free_all(&gc);
> +    GC_FREE;
>      return rc;
>  }
> 
>  int libxl_device_vkb_remove(libxl_ctx *ctx, uint32_t domid,
>                              libxl_device_vkb *vkb)
>  {
> -    libxl__gc gc = LIBXL_INIT_GC(ctx);
> +    GC_INIT(ctx);
>      libxl__device device;
>      int rc;
> 
> -    rc = libxl__device_from_vkb(&gc, domid, vkb, &device);
> +    rc = libxl__device_from_vkb(gc, domid, vkb, &device);
>      if (rc != 0) goto out;
> 
> -    rc = libxl__device_remove(&gc, &device, 1);
> +    rc = libxl__device_remove(gc, &device, 1);
>  out:
> -    libxl__free_all(&gc);
> +    GC_FREE;
>      return rc;
>  }
> 
>  int libxl_device_vkb_destroy(libxl_ctx *ctx, uint32_t domid,
>                                    libxl_device_vkb *vkb)
>  {
> -    libxl__gc gc = LIBXL_INIT_GC(ctx);
> +    GC_INIT(ctx);
>      libxl__device device;
>      int rc;
> 
> -    rc = libxl__device_from_vkb(&gc, domid, vkb, &device);
> +    rc = libxl__device_from_vkb(gc, domid, vkb, &device);
>      if (rc != 0) goto out;
> 
> -    rc = libxl__device_destroy(&gc, &device);
> +    rc = libxl__device_destroy(gc, &device);
>  out:
> -    libxl__free_all(&gc);
> +    GC_FREE;
>      return rc;
>  }
> 
> @@ -1935,7 +1935,7 @@ static int libxl__device_from_vfb(libxl__gc *gc, uint32_t domid,
> 
>  int libxl_device_vfb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vfb *vfb)
>  {
> -    libxl__gc gc = LIBXL_INIT_GC(ctx);
> +    GC_INIT(ctx);
>      flexarray_t *front;
>      flexarray_t *back;
>      libxl__device device;
> @@ -1952,20 +1952,20 @@ int libxl_device_vfb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vfb *vfb)
>          goto out_free;
>      }
> 
> -    rc = libxl__device_from_vfb(&gc, domid, vfb, &device);
> +    rc = libxl__device_from_vfb(gc, domid, vfb, &device);
>      if (rc != 0) goto out_free;
> 
> -    flexarray_append_pair(back, "frontend-id", libxl__sprintf(&gc, "%d", domid));
> +    flexarray_append_pair(back, "frontend-id", libxl__sprintf(gc, "%d", domid));
>      flexarray_append_pair(back, "online", "1");
> -    flexarray_append_pair(back, "state", libxl__sprintf(&gc, "%d", 1));
> -    flexarray_append_pair(back, "domain", libxl__domid_to_name(&gc, domid));
> -    flexarray_append_pair(back, "vnc", libxl__sprintf(&gc, "%d", vfb->vnc));
> +    flexarray_append_pair(back, "state", libxl__sprintf(gc, "%d", 1));
> +    flexarray_append_pair(back, "domain", libxl__domid_to_name(gc, domid));
> +    flexarray_append_pair(back, "vnc", libxl__sprintf(gc, "%d", vfb->vnc));
>      flexarray_append_pair(back, "vnclisten", vfb->vnclisten);
>      flexarray_append_pair(back, "vncpasswd", vfb->vncpasswd);
> -    flexarray_append_pair(back, "vncdisplay", libxl__sprintf(&gc, "%d", vfb->vncdisplay));
> -    flexarray_append_pair(back, "vncunused", libxl__sprintf(&gc, "%d", vfb->vncunused));
> -    flexarray_append_pair(back, "sdl", libxl__sprintf(&gc, "%d", vfb->sdl));
> -    flexarray_append_pair(back, "opengl", libxl__sprintf(&gc, "%d", vfb->opengl));
> +    flexarray_append_pair(back, "vncdisplay", libxl__sprintf(gc, "%d", vfb->vncdisplay));
> +    flexarray_append_pair(back, "vncunused", libxl__sprintf(gc, "%d", vfb->vncunused));
> +    flexarray_append_pair(back, "sdl", libxl__sprintf(gc, "%d", vfb->sdl));
> +    flexarray_append_pair(back, "opengl", libxl__sprintf(gc, "%d", vfb->opengl));
>      if (vfb->xauthority) {
>          flexarray_append_pair(back, "xauthority", vfb->xauthority);
>      }
> @@ -1973,50 +1973,50 @@ int libxl_device_vfb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vfb *vfb)
>          flexarray_append_pair(back, "display", vfb->display);
>      }
> 
> -    flexarray_append_pair(front, "backend-id", libxl__sprintf(&gc, "%d", vfb->backend_domid));
> -    flexarray_append_pair(front, "state", libxl__sprintf(&gc, "%d", 1));
> +    flexarray_append_pair(front, "backend-id", libxl__sprintf(gc, "%d", vfb->backend_domid));
> +    flexarray_append_pair(front, "state", libxl__sprintf(gc, "%d", 1));
> 
> -    libxl__device_generic_add(&gc, &device,
> -                             libxl__xs_kvs_of_flexarray(&gc, back, back->count),
> -                             libxl__xs_kvs_of_flexarray(&gc, front, front->count));
> +    libxl__device_generic_add(gc, &device,
> +                             libxl__xs_kvs_of_flexarray(gc, back, back->count),
> +                             libxl__xs_kvs_of_flexarray(gc, front, front->count));
>      rc = 0;
>  out_free:
>      flexarray_free(front);
>      flexarray_free(back);
>  out:
> -    libxl__free_all(&gc);
> +    GC_FREE;
>      return rc;
>  }
> 
>  int libxl_device_vfb_remove(libxl_ctx *ctx, uint32_t domid,
>                              libxl_device_vfb *vfb)
>  {
> -    libxl__gc gc = LIBXL_INIT_GC(ctx);
> +    GC_INIT(ctx);
>      libxl__device device;
>      int rc;
> 
> -    rc = libxl__device_from_vfb(&gc, domid, vfb, &device);
> +    rc = libxl__device_from_vfb(gc, domid, vfb, &device);
>      if (rc != 0) goto out;
> 
> -    rc = libxl__device_remove(&gc, &device, 1);
> +    rc = libxl__device_remove(gc, &device, 1);
>  out:
> -    libxl__free_all(&gc);
> +    GC_FREE;
>      return rc;
>  }
> 
>  int libxl_device_vfb_destroy(libxl_ctx *ctx, uint32_t domid,
>                                    libxl_device_vfb *vfb)
>  {
> -    libxl__gc gc = LIBXL_INIT_GC(ctx);
> +    GC_INIT(ctx);
>      libxl__device device;
>      int rc;
> 
> -    rc = libxl__device_from_vfb(&gc, domid, vfb, &device);
> +    rc = libxl__device_from_vfb(gc, domid, vfb, &device);
>      if (rc != 0) goto out;
> 
> -    rc = libxl__device_destroy(&gc, &device);
> +    rc = libxl__device_destroy(gc, &device);
>  out:
> -    libxl__free_all(&gc);
> +    GC_FREE;
>      return rc;
>  }
> 
> @@ -2024,13 +2024,13 @@ out:
> 
>  int libxl_domain_setmaxmem(libxl_ctx *ctx, uint32_t domid, uint32_t max_memkb)
>  {
> -    libxl__gc gc = LIBXL_INIT_GC(ctx);
> +    GC_INIT(ctx);
>      char *mem, *endptr;
>      uint32_t memorykb;
> -    char *dompath = libxl__xs_get_dompath(&gc, domid);
> +    char *dompath = libxl__xs_get_dompath(gc, domid);
>      int rc = 1;
> 
> -    mem = libxl__xs_read(&gc, XBT_NULL, libxl__sprintf(&gc, "%s/memory/target", dompath));
> +    mem = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/memory/target", dompath));
>      if (!mem) {
>          LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "cannot get memory info from %s/memory/target\n", dompath);
>          goto out;
> @@ -2055,7 +2055,7 @@ int libxl_domain_setmaxmem(libxl_ctx *ctx, uint32_t domid, uint32_t max_memkb)
> 
>      rc = 0;
>  out:
> -    libxl__free_all(&gc);
> +    GC_FREE;
>      return rc;
>  }
> 
> @@ -2163,12 +2163,12 @@ retry:
>  int libxl_set_memory_target(libxl_ctx *ctx, uint32_t domid,
>          int32_t target_memkb, int relative, int enforce)
>  {
> -    libxl__gc gc = LIBXL_INIT_GC(ctx);
> +    GC_INIT(ctx);
>      int rc = 1, abort = 0;
>      uint32_t memorykb = 0, videoram = 0;
>      uint32_t current_target_memkb = 0, new_target_memkb = 0;
>      char *memmax, *endptr, *videoram_s = NULL, *target = NULL;
> -    char *dompath = libxl__xs_get_dompath(&gc, domid);
> +    char *dompath = libxl__xs_get_dompath(gc, domid);
>      xc_domaininfo_t info;
>      libxl_dominfo ptr;
>      char *uuid;
> @@ -2177,11 +2177,11 @@ int libxl_set_memory_target(libxl_ctx *ctx, uint32_t domid,
>  retry_transaction:
>      t = xs_transaction_start(ctx->xsh);
> 
> -    target = libxl__xs_read(&gc, t, libxl__sprintf(&gc,
> +    target = libxl__xs_read(gc, t, libxl__sprintf(gc,
>                  "%s/memory/target", dompath));
>      if (!target && !domid) {
>          xs_transaction_end(ctx->xsh, t, 1);
> -        rc = libxl__fill_dom0_memory_info(&gc, &current_target_memkb);
> +        rc = libxl__fill_dom0_memory_info(gc, &current_target_memkb);
>          if (rc < 0) {
>              abort = 1;
>              goto out;
> @@ -2203,7 +2203,7 @@ retry_transaction:
>              goto out;
>          }
>      }
> -    memmax = libxl__xs_read(&gc, t, libxl__sprintf(&gc,
> +    memmax = libxl__xs_read(gc, t, libxl__sprintf(gc,
>                  "%s/memory/static-max", dompath));
>      if (!memmax) {
>          LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
> @@ -2243,7 +2243,7 @@ retry_transaction:
>          abort = 1;
>          goto out;
>      }
> -    videoram_s = libxl__xs_read(&gc, t, libxl__sprintf(&gc,
> +    videoram_s = libxl__xs_read(gc, t, libxl__sprintf(gc,
>                  "%s/memory/videoram", dompath));
>      videoram = videoram_s ? atoi(videoram_s) : 0;
> 
> @@ -2272,7 +2272,7 @@ retry_transaction:
>          goto out;
>      }
> 
> -    libxl__xs_write(&gc, t, libxl__sprintf(&gc, "%s/memory/target",
> +    libxl__xs_write(gc, t, libxl__sprintf(gc, "%s/memory/target",
>                  dompath), "%"PRIu32, new_target_memkb);
>      rc = xc_domain_getinfolist(ctx->xch, domid, 1, &info);
>      if (rc != 1 || info.domain != domid) {
> @@ -2280,8 +2280,8 @@ retry_transaction:
>          goto out;
>      }
>      xcinfo2xlinfo(&info, &ptr);
> -    uuid = libxl__uuid2string(&gc, ptr.uuid);
> -    libxl__xs_write(&gc, t, libxl__sprintf(&gc, "/vm/%s/memory", uuid),
> +    uuid = libxl__uuid2string(gc, ptr.uuid);
> +    libxl__xs_write(gc, t, libxl__sprintf(gc, "/vm/%s/memory", uuid),
>              "%"PRIu32, new_target_memkb / 1024);
> 
>  out:
> @@ -2289,22 +2289,22 @@ out:
>          if (errno == EAGAIN)
>              goto retry_transaction;
> 
> -    libxl__free_all(&gc);
> +    GC_FREE;
>      return rc;
>  }
> 
>  int libxl_get_memory_target(libxl_ctx *ctx, uint32_t domid, uint32_t *out_target)
>  {
> -    libxl__gc gc = LIBXL_INIT_GC(ctx);
> +    GC_INIT(ctx);
>      int rc = 1;
>      char *target = NULL, *endptr = NULL;
> -    char *dompath = libxl__xs_get_dompath(&gc, domid);
> +    char *dompath = libxl__xs_get_dompath(gc, domid);
>      uint32_t target_memkb;
> 
> -    target = libxl__xs_read(&gc, XBT_NULL, libxl__sprintf(&gc,
> +    target = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc,
>                  "%s/memory/target", dompath));
>      if (!target && !domid) {
> -        rc = libxl__fill_dom0_memory_info(&gc, &target_memkb);
> +        rc = libxl__fill_dom0_memory_info(gc, &target_memkb);
>          if (rc < 0)
>              goto out;
>      } else if (!target) {
> @@ -2325,14 +2325,14 @@ int libxl_get_memory_target(libxl_ctx *ctx, uint32_t domid, uint32_t *out_target
>      rc = 0;
> 
>  out:
> -    libxl__free_all(&gc);
> +    GC_FREE;
>      return rc;
>  }
> 
>  int libxl_domain_need_memory(libxl_ctx *ctx, libxl_domain_build_info *b_info,
>          libxl_device_model_info *dm_info, uint32_t *need_memkb)
>  {
> -    libxl__gc gc = LIBXL_INIT_GC(ctx);
> +    GC_INIT(ctx);
>      int rc = ERROR_INVAL;
>      *need_memkb = b_info->target_memkb;
>      switch (b_info->type) {
> @@ -2351,7 +2351,7 @@ int libxl_domain_need_memory(libxl_ctx *ctx, libxl_domain_build_info *b_info,
>          *need_memkb += (2 * 1024) - (*need_memkb % (2 * 1024));
>      rc = 0;
>  out:
> -    libxl__free_all(&gc);
> +    GC_FREE;
>      return rc;
> 
>  }
> @@ -2361,12 +2361,12 @@ int libxl_get_free_memory(libxl_ctx *ctx, uint32_t *memkb)
>      int rc = 0;
>      libxl_physinfo info;
>      uint32_t freemem_slack;
> -    libxl__gc gc = LIBXL_INIT_GC(ctx);
> +    GC_INIT(ctx);
> 
>      rc = libxl_get_physinfo(ctx, &info);
>      if (rc < 0)
>          goto out;
> -    rc = libxl__get_free_memory_slack(&gc, &freemem_slack);
> +    rc = libxl__get_free_memory_slack(gc, &freemem_slack);
>      if (rc < 0)
>          goto out;
> 
> @@ -2376,7 +2376,7 @@ int libxl_get_free_memory(libxl_ctx *ctx, uint32_t *memkb)
>          *memkb = 0;
> 
>  out:
> -    libxl__free_all(&gc);
> +    GC_FREE;
>      return rc;
>  }
> 
> @@ -2386,9 +2386,9 @@ int libxl_wait_for_free_memory(libxl_ctx *ctx, uint32_t domid, uint32_t
>      int rc = 0;
>      libxl_physinfo info;
>      uint32_t freemem_slack;
> -    libxl__gc gc = LIBXL_INIT_GC(ctx);
> +    GC_INIT(ctx);
> 
> -    rc = libxl__get_free_memory_slack(&gc, &freemem_slack);
> +    rc = libxl__get_free_memory_slack(gc, &freemem_slack);
>      if (rc < 0)
>          goto out;
>      while (wait_secs > 0) {
> @@ -2405,7 +2405,7 @@ int libxl_wait_for_free_memory(libxl_ctx *ctx, uint32_t domid, uint32_t
>      rc = ERROR_NOMEM;
> 
>  out:
> -    libxl__free_all(&gc);
> +    GC_FREE;
>      return rc;
>  }
> 
> @@ -2631,7 +2631,7 @@ int libxl_set_vcpuaffinity(libxl_ctx *ctx, uint32_t domid, uint32_t vcpuid,
> 
>  int libxl_set_vcpuonline(libxl_ctx *ctx, uint32_t domid, libxl_cpumap *cpumap)
>  {
> -    libxl__gc gc = LIBXL_INIT_GC(ctx);
> +    GC_INIT(ctx);
>      libxl_dominfo info;
>      char *dompath;
>      xs_transaction_t t;
> @@ -2641,14 +2641,14 @@ int libxl_set_vcpuonline(libxl_ctx *ctx, uint32_t domid, libxl_cpumap *cpumap)
>          LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "getting domain info list");
>          goto out;
>      }
> -    if (!(dompath = libxl__xs_get_dompath(&gc, domid)))
> +    if (!(dompath = libxl__xs_get_dompath(gc, domid)))
>          goto out;
> 
>  retry_transaction:
>      t = xs_transaction_start(ctx->xsh);
>      for (i = 0; i <= info.vcpu_max_id; i++)
> -        libxl__xs_write(&gc, t,
> -                       libxl__sprintf(&gc, "%s/cpu/%u/availability", dompath, i),
> +        libxl__xs_write(gc, t,
> +                       libxl__sprintf(gc, "%s/cpu/%u/availability", dompath, i),
>                         "%s", libxl_cpumap_test(cpumap, i) ? "online" : "offline");
>      if (!xs_transaction_end(ctx->xsh, t, 0)) {
>          if (errno == EAGAIN)
> @@ -2656,7 +2656,7 @@ retry_transaction:
>      } else
>          rc = 0;
>  out:
> -    libxl__free_all(&gc);
> +    GC_FREE;
>      return rc;
>  }
> 
> @@ -2776,12 +2776,12 @@ int libxl_send_trigger(libxl_ctx *ctx, uint32_t domid, char *trigger_name, uint3
> 
>  int libxl_send_sysrq(libxl_ctx *ctx, uint32_t domid, char sysrq)
>  {
> -    libxl__gc gc = LIBXL_INIT_GC(ctx);
> -    char *dompath = libxl__xs_get_dompath(&gc, domid);
> +    GC_INIT(ctx);
> +    char *dompath = libxl__xs_get_dompath(gc, domid);
> 
> -    libxl__xs_write(&gc, XBT_NULL, libxl__sprintf(&gc, "%s/control/sysrq", dompath), "%c", sysrq);
> +    libxl__xs_write(gc, XBT_NULL, libxl__sprintf(gc, "%s/control/sysrq", dompath), "%c", sysrq);
> 
> -    libxl__free_all(&gc);
> +    GC_FREE;
>      return 0;
>  }
> 
> @@ -2868,15 +2868,15 @@ void libxl_xen_console_read_finish(libxl_ctx *ctx,
> 
>  uint32_t libxl_vm_get_start_time(libxl_ctx *ctx, uint32_t domid)
>  {
> -    libxl__gc gc = LIBXL_INIT_GC(ctx);
> -    char *dompath = libxl__xs_get_dompath(&gc, domid);
> +    GC_INIT(ctx);
> +    char *dompath = libxl__xs_get_dompath(gc, domid);
>      char *vm_path, *start_time;
>      uint32_t ret;
> 
>      vm_path = libxl__xs_read(
> -        &gc, XBT_NULL, libxl__sprintf(&gc, "%s/vm", dompath));
> +        gc, XBT_NULL, libxl__sprintf(gc, "%s/vm", dompath));
>      start_time = libxl__xs_read(
> -        &gc, XBT_NULL, libxl__sprintf(&gc, "%s/start_time", vm_path));
> +        gc, XBT_NULL, libxl__sprintf(gc, "%s/start_time", vm_path));
>      if (start_time == NULL) {
>          LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, -1,
>                          "Can't get start time of domain '%d'", domid);
> @@ -2884,7 +2884,7 @@ uint32_t libxl_vm_get_start_time(libxl_ctx *ctx, uint32_t domid)
>      }else{
>          ret = strtoul(start_time, NULL, 10);
>      }
> -    libxl__free_all(&gc);
> +    GC_FREE;
>      return ret;
>  }
> 
> @@ -3037,15 +3037,15 @@ int libxl_create_cpupool(libxl_ctx *ctx, const char *name, int schedid,
>                           libxl_cpumap cpumap, libxl_uuid *uuid,
>                           uint32_t *poolid)
>  {
> -    libxl__gc gc = LIBXL_INIT_GC(ctx);
> +    GC_INIT(ctx);
>      int rc;
>      int i;
>      xs_transaction_t t;
>      char *uuid_string;
> 
> -    uuid_string = libxl__uuid2string(&gc, *uuid);
> +    uuid_string = libxl__uuid2string(gc, *uuid);
>      if (!uuid_string) {
> -        libxl__free_all(&gc);
> +        GC_FREE;
>          return ERROR_NOMEM;
>      }
> 
> @@ -3053,7 +3053,7 @@ int libxl_create_cpupool(libxl_ctx *ctx, const char *name, int schedid,
>      if (rc) {
>          LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, rc,
>             "Could not create cpupool");
> -        libxl__free_all(&gc);
> +        GC_FREE;
>          return ERROR_FAIL;
>      }
> 
> @@ -3064,7 +3064,7 @@ int libxl_create_cpupool(libxl_ctx *ctx, const char *name, int schedid,
>                  LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, rc,
>                      "Error moving cpu to cpupool");
>                  libxl_cpupool_destroy(ctx, *poolid);
> -                libxl__free_all(&gc);
> +                GC_FREE;
>                  return ERROR_FAIL;
>              }
>          }
> @@ -3072,16 +3072,16 @@ int libxl_create_cpupool(libxl_ctx *ctx, const char *name, int schedid,
>      for (;;) {
>          t = xs_transaction_start(ctx->xsh);
> 
> -        xs_mkdir(ctx->xsh, t, libxl__sprintf(&gc, "/local/pool/%d", *poolid));
> -        libxl__xs_write(&gc, t,
> -                        libxl__sprintf(&gc, "/local/pool/%d/uuid", *poolid),
> +        xs_mkdir(ctx->xsh, t, libxl__sprintf(gc, "/local/pool/%d", *poolid));
> +        libxl__xs_write(gc, t,
> +                        libxl__sprintf(gc, "/local/pool/%d/uuid", *poolid),
>                          "%s", uuid_string);
> -        libxl__xs_write(&gc, t,
> -                        libxl__sprintf(&gc, "/local/pool/%d/name", *poolid),
> +        libxl__xs_write(gc, t,
> +                        libxl__sprintf(gc, "/local/pool/%d/name", *poolid),
>                          "%s", name);
> 
>          if (xs_transaction_end(ctx->xsh, t, 0) || (errno != EAGAIN)) {
> -            libxl__free_all(&gc);
> +            GC_FREE;
>              return 0;
>          }
>      }
> @@ -3089,7 +3089,7 @@ int libxl_create_cpupool(libxl_ctx *ctx, const char *name, int schedid,
> 
>  int libxl_cpupool_destroy(libxl_ctx *ctx, uint32_t poolid)
>  {
> -    libxl__gc gc = LIBXL_INIT_GC(ctx);
> +    GC_INIT(ctx);
>      int rc, i;
>      xc_cpupoolinfo_t *info;
>      xs_transaction_t t;
> @@ -3097,7 +3097,7 @@ int libxl_cpupool_destroy(libxl_ctx *ctx, uint32_t poolid)
> 
>      info = xc_cpupool_getinfo(ctx->xch, poolid);
>      if (info == NULL) {
> -        libxl__free_all(&gc);
> +        GC_FREE;
>          return ERROR_NOMEM;
>      }
> 
> @@ -3131,7 +3131,7 @@ int libxl_cpupool_destroy(libxl_ctx *ctx, uint32_t poolid)
>      for (;;) {
>          t = xs_transaction_start(ctx->xsh);
> 
> -        xs_rm(ctx->xsh, XBT_NULL, libxl__sprintf(&gc, "/local/pool/%d", poolid));
> +        xs_rm(ctx->xsh, XBT_NULL, libxl__sprintf(gc, "/local/pool/%d", poolid));
> 
>          if (xs_transaction_end(ctx->xsh, t, 0) || (errno != EAGAIN))
>              break;
> @@ -3143,21 +3143,21 @@ out1:
>      libxl_cpumap_dispose(&cpumap);
>  out:
>      xc_cpupool_infofree(ctx->xch, info);
> -    libxl__free_all(&gc);
> +    GC_FREE;
> 
>      return rc;
>  }
> 
>  int libxl_cpupool_rename(libxl_ctx *ctx, const char *name, uint32_t poolid)
>  {
> -    libxl__gc gc = LIBXL_INIT_GC(ctx);
> +    GC_INIT(ctx);
>      xs_transaction_t t;
>      xc_cpupoolinfo_t *info;
>      int rc;
> 
>      info = xc_cpupool_getinfo(ctx->xch, poolid);
>      if (info == NULL) {
> -        libxl__free_all(&gc);
> +        GC_FREE;
>          return ERROR_NOMEM;
>      }
> 
> @@ -3170,8 +3170,8 @@ int libxl_cpupool_rename(libxl_ctx *ctx, const char *name, uint32_t poolid)
>      for (;;) {
>          t = xs_transaction_start(ctx->xsh);
> 
> -        libxl__xs_write(&gc, t,
> -                        libxl__sprintf(&gc, "/local/pool/%d/name", poolid),
> +        libxl__xs_write(gc, t,
> +                        libxl__sprintf(gc, "/local/pool/%d/name", poolid),
>                          "%s", name);
> 
>          if (xs_transaction_end(ctx->xsh, t, 0))
> @@ -3186,7 +3186,7 @@ int libxl_cpupool_rename(libxl_ctx *ctx, const char *name, uint32_t poolid)
> 
>  out:
>      xc_cpupool_infofree(ctx->xch, info);
> -    libxl__free_all(&gc);
> +    GC_FREE;
> 
>      return rc;
>  }
> @@ -3293,16 +3293,16 @@ out:
> 
>  int libxl_cpupool_movedomain(libxl_ctx *ctx, uint32_t poolid, uint32_t domid)
>  {
> -    libxl__gc gc = LIBXL_INIT_GC(ctx);
> +    GC_INIT(ctx);
>      int rc;
>      char *dom_path;
>      char *vm_path;
>      char *poolname;
>      xs_transaction_t t;
> 
> -    dom_path = libxl__xs_get_dompath(&gc, domid);
> +    dom_path = libxl__xs_get_dompath(gc, domid);
>      if (!dom_path) {
> -        libxl__free_all(&gc);
> +        GC_FREE;
>          return ERROR_FAIL;
>      }
> 
> @@ -3310,26 +3310,26 @@ int libxl_cpupool_movedomain(libxl_ctx *ctx, uint32_t poolid, uint32_t domid)
>      if (rc) {
>          LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, rc,
>              "Error moving domain to cpupool");
> -        libxl__free_all(&gc);
> +        GC_FREE;
>          return ERROR_FAIL;
>      }
> 
>      for (;;) {
>          t = xs_transaction_start(ctx->xsh);
> 
> -        poolname = libxl__cpupoolid_to_name(&gc, poolid);
> -        vm_path = libxl__xs_read(&gc, XBT_NULL, libxl__sprintf(&gc, "%s/vm", dom_path));
> +        poolname = libxl__cpupoolid_to_name(gc, poolid);
> +        vm_path = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/vm", dom_path));
>          if (!vm_path)
>              break;
> 
> -        libxl__xs_write(&gc, t, libxl__sprintf(&gc, "%s/pool_name", vm_path),
> +        libxl__xs_write(gc, t, libxl__sprintf(gc, "%s/pool_name", vm_path),
>                          "%s", poolname);
> 
>          if (xs_transaction_end(ctx->xsh, t, 0) || (errno != EAGAIN))
>              break;
>      }
> 
> -    libxl__free_all(&gc);
> +    GC_FREE;
>      return 0;
>  }
> 
> diff --git a/tools/libxl/libxl_bootloader.c b/tools/libxl/libxl_bootloader.c
> index b8399a1..ce83b8e 100644
> --- a/tools/libxl/libxl_bootloader.c
> +++ b/tools/libxl/libxl_bootloader.c
> @@ -328,7 +328,7 @@ int libxl_run_bootloader(libxl_ctx *ctx,
>                           libxl_device_disk *disk,
>                           uint32_t domid)
>  {
> -    libxl__gc gc = LIBXL_INIT_GC(ctx);
> +    GC_INIT(ctx);
>      int ret, rc = 0;
>      char *fifo = NULL;
>      char *diskpath = NULL;
> @@ -388,7 +388,7 @@ int libxl_run_bootloader(libxl_ctx *ctx,
>          goto out_close;
>      }
> 
> -    args = make_bootloader_args(&gc, info, domid, fifo, diskpath);
> +    args = make_bootloader_args(gc, info, domid, fifo, diskpath);
>      if (args == NULL) {
>          rc = ERROR_NOMEM;
>          goto out_close;
> @@ -411,8 +411,8 @@ int libxl_run_bootloader(libxl_ctx *ctx,
>          goto out_close;
>      }
> 
> -    dom_console_xs_path = libxl__sprintf(&gc, "%s/console/tty", libxl__xs_get_dompath(&gc, domid));
> -    libxl__xs_write(&gc, XBT_NULL, dom_console_xs_path, "%s", dom_console_slave_tty_path);
> +    dom_console_xs_path = libxl__sprintf(gc, "%s/console/tty", libxl__xs_get_dompath(gc, domid));
> +    libxl__xs_write(gc, XBT_NULL, dom_console_xs_path, "%s", dom_console_slave_tty_path);
> 
>      pid = fork_exec_bootloader(&bootloader_fd, info->u.pv.bootloader, args);
>      if (pid < 0) {
> @@ -435,7 +435,7 @@ int libxl_run_bootloader(libxl_ctx *ctx,
> 
>      fcntl(fifo_fd, F_SETFL, O_NDELAY);
> 
> -    blout = bootloader_interact(&gc, xenconsoled_fd, bootloader_fd, fifo_fd);
> +    blout = bootloader_interact(gc, xenconsoled_fd, bootloader_fd, fifo_fd);
>      if (blout == NULL) {
>          goto out_close;
>      }
> @@ -445,7 +445,7 @@ int libxl_run_bootloader(libxl_ctx *ctx,
>          goto out_close;
>      }
> 
> -    parse_bootloader_result(&gc, info, blout);
> +    parse_bootloader_result(gc, info, blout);
> 
>      rc = 0;
>  out_close:
> @@ -472,7 +472,7 @@ out_close:
>      free(args);
> 
>  out:
> -    libxl__free_all(&gc);
> +    GC_FREE;
>      return rc;
>  }
> 
> diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
> index ccb56c7..69f10fe 100644
> --- a/tools/libxl/libxl_create.c
> +++ b/tools/libxl/libxl_create.c
> @@ -670,20 +670,20 @@ error_out:
>  int libxl_domain_create_new(libxl_ctx *ctx, libxl_domain_config *d_config,
>                              libxl_console_ready cb, void *priv, uint32_t *domid)
>  {
> -    libxl__gc gc = LIBXL_INIT_GC(ctx);
> +    GC_INIT(ctx);
>      int rc;
> -    rc = do_domain_create(&gc, d_config, cb, priv, domid, -1);
> -    libxl__free_all(&gc);
> +    rc = do_domain_create(gc, d_config, cb, priv, domid, -1);
> +    GC_FREE;
>      return rc;
>  }
> 
>  int libxl_domain_create_restore(libxl_ctx *ctx, libxl_domain_config *d_config,
>                                  libxl_console_ready cb, void *priv, uint32_t *domid, int restore_fd)
>  {
> -    libxl__gc gc = LIBXL_INIT_GC(ctx);
> +    GC_INIT(ctx);
>      int rc;
> -    rc = do_domain_create(&gc, d_config, cb, priv, domid, restore_fd);
> -    libxl__free_all(&gc);
> +    rc = do_domain_create(gc, d_config, cb, priv, domid, restore_fd);
> +    GC_FREE;
>      return rc;
>  }
> 
> diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
> index 96098de..b1ff967 100644
> --- a/tools/libxl/libxl_dom.c
> +++ b/tools/libxl/libxl_dom.c
> @@ -730,7 +730,7 @@ int libxl_userdata_store(libxl_ctx *ctx, uint32_t domid,
>                                const char *userdata_userid,
>                                const uint8_t *data, int datalen)
>  {
> -    libxl__gc gc = LIBXL_INIT_GC(ctx);
> +    GC_INIT(ctx);
>      const char *filename;
>      const char *newfilename;
>      int e, rc;
> @@ -738,18 +738,18 @@ int libxl_userdata_store(libxl_ctx *ctx, uint32_t domid,
>      FILE *f = NULL;
>      size_t rs;
> 
> -    filename = userdata_path(&gc, domid, userdata_userid, "d");
> +    filename = userdata_path(gc, domid, userdata_userid, "d");
>      if (!filename) {
>          rc = ERROR_NOMEM;
>          goto out;
>      }
> 
>      if (!datalen) {
> -        rc = userdata_delete(&gc, filename);
> +        rc = userdata_delete(gc, filename);
>          goto out;
>      }
> 
> -    newfilename = userdata_path(&gc, domid, userdata_userid, "n");
> +    newfilename = userdata_path(gc, domid, userdata_userid, "n");
>      if (!newfilename) {
>          rc = ERROR_NOMEM;
>          goto out;
> @@ -791,7 +791,7 @@ err:
>          LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "cannot write %s for %s",
>                   newfilename, filename);
>  out:
> -    libxl__free_all(&gc);
> +    GC_FREE;
>      return rc;
>  }
> 
> @@ -799,13 +799,13 @@ int libxl_userdata_retrieve(libxl_ctx *ctx, uint32_t domid,
>                                   const char *userdata_userid,
>                                   uint8_t **data_r, int *datalen_r)
>  {
> -    libxl__gc gc = LIBXL_INIT_GC(ctx);
> +    GC_INIT(ctx);
>      const char *filename;
>      int e, rc;
>      int datalen = 0;
>      void *data = 0;
> 
> -    filename = userdata_path(&gc, domid, userdata_userid, "d");
> +    filename = userdata_path(gc, domid, userdata_userid, "d");
>      if (!filename) {
>          rc = ERROR_NOMEM;
>          goto out;
> @@ -827,7 +827,7 @@ int libxl_userdata_retrieve(libxl_ctx *ctx, uint32_t domid,
>      if (datalen_r) *datalen_r = datalen;
>      rc = 0;
>  out:
> -    libxl__free_all(&gc);
> +    GC_FREE;
>      return rc;
>  }
> 
> diff --git a/tools/libxl/libxl_pci.c b/tools/libxl/libxl_pci.c
> index 63c3050..120c239 100644
> --- a/tools/libxl/libxl_pci.c
> +++ b/tools/libxl/libxl_pci.c
> @@ -483,7 +483,7 @@ static int is_assigned(libxl_device_pci *assigned, int num_assigned,
> 
>  libxl_device_pci *libxl_device_pci_list_assignable(libxl_ctx *ctx, int *num)
>  {
> -    libxl__gc gc = LIBXL_INIT_GC(ctx);
> +    GC_INIT(ctx);
>      libxl_device_pci *pcidevs = NULL, *new, *assigned;
>      struct dirent *de;
>      DIR *dir;
> @@ -491,7 +491,7 @@ libxl_device_pci *libxl_device_pci_list_assignable(libxl_ctx *ctx, int *num)
> 
>      *num = 0;
> 
> -    rc = get_all_assigned_devices(&gc, &assigned, &num_assigned);
> +    rc = get_all_assigned_devices(gc, &assigned, &num_assigned);
>      if ( rc )
>          goto out;
> 
> @@ -528,7 +528,7 @@ libxl_device_pci *libxl_device_pci_list_assignable(libxl_ctx *ctx, int *num)
>  out_closedir:
>      closedir(dir);
>  out:
> -    libxl__free_all(&gc);
> +    GC_FREE;
>      return pcidevs;
>  }
> 
> @@ -782,10 +782,10 @@ static int libxl__device_pci_reset(libxl__gc *gc, unsigned int domain, unsigned
> 
>  int libxl_device_pci_add(libxl_ctx *ctx, uint32_t domid, libxl_device_pci *pcidev)
>  {
> -    libxl__gc gc = LIBXL_INIT_GC(ctx);
> +    GC_INIT(ctx);
>      int rc;
> -    rc = libxl__device_pci_add(&gc, domid, pcidev, 0);
> -    libxl__free_all(&gc);
> +    rc = libxl__device_pci_add(gc, domid, pcidev, 0);
> +    GC_FREE;
>      return rc;
>  }
> 
> @@ -1057,24 +1057,24 @@ out:
> 
>  int libxl_device_pci_remove(libxl_ctx *ctx, uint32_t domid, libxl_device_pci *pcidev)
>  {
> -    libxl__gc gc = LIBXL_INIT_GC(ctx);
> +    GC_INIT(ctx);
>      int rc;
> 
> -    rc = libxl__device_pci_remove_common(&gc, domid, pcidev, 0);
> +    rc = libxl__device_pci_remove_common(gc, domid, pcidev, 0);
> 
> -    libxl__free_all(&gc);
> +    GC_FREE;
>      return rc;
>  }
> 
>  int libxl_device_pci_destroy(libxl_ctx *ctx, uint32_t domid,
>                                    libxl_device_pci *pcidev)
>  {
> -    libxl__gc gc = LIBXL_INIT_GC(ctx);
> +    GC_INIT(ctx);
>      int rc;
> 
> -    rc = libxl__device_pci_remove_common(&gc, domid, pcidev, 1);
> +    rc = libxl__device_pci_remove_common(gc, domid, pcidev, 1);
> 
> -    libxl__free_all(&gc);
> +    GC_FREE;
>      return rc;
>  }
> 
> @@ -1115,15 +1115,15 @@ static void libxl__device_pci_from_xs_be(libxl__gc *gc,
> 
>  libxl_device_pci *libxl_device_pci_list(libxl_ctx *ctx, uint32_t domid, int *num)
>  {
> -    libxl__gc gc = LIBXL_INIT_GC(ctx);
> +    GC_INIT(ctx);
>      char *be_path, *num_devs;
>      int n, i;
>      libxl_device_pci *pcidevs = NULL;
> 
>      *num = 0;
> 
> -    be_path = libxl__sprintf(&gc, "%s/backend/pci/%d/0", libxl__xs_get_dompath(&gc, 0), domid);
> -    num_devs = libxl__xs_read(&gc, XBT_NULL, libxl__sprintf(&gc, "%s/num_devs", be_path));
> +    be_path = libxl__sprintf(gc, "%s/backend/pci/%d/0", libxl__xs_get_dompath(gc, 0), domid);
> +    num_devs = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/num_devs", be_path));
>      if (!num_devs)
>          goto out;
> 
> @@ -1131,11 +1131,11 @@ libxl_device_pci *libxl_device_pci_list(libxl_ctx *ctx, uint32_t domid, int *num
>      pcidevs = calloc(n, sizeof(libxl_device_pci));
> 
>      for (i = 0; i < n; i++)
> -        libxl__device_pci_from_xs_be(&gc, be_path, pcidevs + i, i);
> +        libxl__device_pci_from_xs_be(gc, be_path, pcidevs + i, i);
> 
>      *num = n;
>  out:
> -    libxl__free_all(&gc);
> +    GC_FREE;
>      return pcidevs;
>  }
> 
> diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
> index c7696d7..60af98c 100644
> --- a/tools/libxl/libxl_qmp.c
> +++ b/tools/libxl/libxl_qmp.c
> @@ -94,7 +94,7 @@ static int store_serial_port_info(libxl__qmp_handler *qmp,
>                                    const char *chardev,
>                                    int port)
>  {
> -    libxl__gc gc = LIBXL_INIT_GC(qmp->ctx);
> +    GC_INIT(qmp->ctx);
>      char *path = NULL;
>      int ret = 0;
> 
> @@ -102,12 +102,12 @@ static int store_serial_port_info(libxl__qmp_handler *qmp,
>          return 0;
>      }
> 
> -    path = libxl__xs_get_dompath(&gc, qmp->domid);
> -    path = libxl__sprintf(&gc, "%s/serial/%d/tty", path, port);
> +    path = libxl__xs_get_dompath(gc, qmp->domid);
> +    path = libxl__sprintf(gc, "%s/serial/%d/tty", path, port);
> 
> -    ret = libxl__xs_write(&gc, XBT_NULL, path, "%s", chardev + 4);
> +    ret = libxl__xs_write(gc, XBT_NULL, path, "%s", chardev + 4);
> 
> -    libxl__free_all(&gc);
> +    GC_FREE;
>      return ret;
>  }
> 
> @@ -521,7 +521,7 @@ static int qmp_synchronous_send(libxl__qmp_handler *qmp, const char *cmd,
>  {
>      int id = 0;
>      int ret = 0;
> -    libxl__gc gc = LIBXL_INIT_GC(qmp->ctx);
> +    GC_INIT(qmp->ctx);
>      qmp_request_context context = { .rc = 0 };
> 
>      id = qmp_send(qmp, cmd, args, callback, opaque, &context);
> @@ -531,7 +531,7 @@ static int qmp_synchronous_send(libxl__qmp_handler *qmp, const char *cmd,
>      qmp->wait_for_id = id;
> 
>      while (qmp->wait_for_id == id) {
> -        if ((ret = qmp_next(&gc, qmp)) < 0) {
> +        if ((ret = qmp_next(gc, qmp)) < 0) {
>              break;
>          }
>      }
> @@ -540,7 +540,7 @@ static int qmp_synchronous_send(libxl__qmp_handler *qmp, const char *cmd,
>          ret = context.rc;
>      }
> 
> -    libxl__free_all(&gc);
> +    GC_FREE;
> 
>      return ret;
>  }
> @@ -559,15 +559,15 @@ libxl__qmp_handler *libxl__qmp_initialize(libxl_ctx *ctx, uint32_t domid)
>      int ret = 0;
>      libxl__qmp_handler *qmp = NULL;
>      char *qmp_socket;
> -    libxl__gc gc = LIBXL_INIT_GC(ctx);
> +    GC_INIT(ctx);
> 
>      qmp = qmp_init_handler(ctx, domid);
> 
> -    qmp_socket = libxl__sprintf(&gc, "%s/qmp-libxl-%d",
> +    qmp_socket = libxl__sprintf(gc, "%s/qmp-libxl-%d",
>                                  libxl_run_dir_path(), domid);
>      if ((ret = qmp_open(qmp, qmp_socket, QMP_SOCKET_CONNECT_TIMEOUT)) < 0) {
>          LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "Connection error");
> -        libxl__free_all(&gc);
> +        GC_FREE;
>          qmp_free_handler(qmp);
>          return NULL;
>      }
> @@ -576,12 +576,12 @@ libxl__qmp_handler *libxl__qmp_initialize(libxl_ctx *ctx, uint32_t domid)
> 
>      /* Wait for the response to qmp_capabilities */
>      while (!qmp->connected) {
> -        if ((ret = qmp_next(&gc, qmp)) < 0) {
> +        if ((ret = qmp_next(gc, qmp)) < 0) {
>              break;
>          }
>      }
> 
> -    libxl__free_all(&gc);
> +    GC_FREE;
>      if (!qmp->connected) {
>          LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Failed to connect to QMP");
>          libxl__qmp_close(qmp);
> @@ -626,9 +626,9 @@ static int pci_add_callback(libxl__qmp_handler *qmp,
>  {
>      libxl_device_pci *pcidev = opaque;
>      const libxl__json_object *bus = NULL;
> -    libxl__gc gc = LIBXL_INIT_GC(qmp->ctx);
> +    GC_INIT(qmp->ctx);
>      int i, j, rc = -1;
> -    char *asked_id = libxl__sprintf(&gc, PCI_PT_QDEV_ID,
> +    char *asked_id = libxl__sprintf(gc, PCI_PT_QDEV_ID,
>                                      pcidev->bus, pcidev->dev, pcidev->func);
> 
>      for (i = 0; (bus = libxl__json_array_get(response, i)); i++) {
> @@ -665,7 +665,7 @@ static int pci_add_callback(libxl__qmp_handler *qmp,
> 
> 
>  out:
> -    libxl__free_all(&gc);
> +    GC_FREE;
>      return rc;
>  }
> 
> diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
> index f1f2a6d..d36c737 100644
> --- a/tools/libxl/libxl_utils.c
> +++ b/tools/libxl/libxl_utils.c
> @@ -186,29 +186,29 @@ char *libxl_schedid_to_name(libxl_ctx *ctx, int schedid)
> 
>  int libxl_get_stubdom_id(libxl_ctx *ctx, int guest_domid)
>  {
> -    libxl__gc gc = LIBXL_INIT_GC(ctx);
> +    GC_INIT(ctx);
>      char * stubdom_id_s;
>      int ret;
> 
> -    stubdom_id_s = libxl__xs_read(&gc, XBT_NULL,
> -                                 libxl__sprintf(&gc, "%s/image/device-model-domid",
> -                                               libxl__xs_get_dompath(&gc, guest_domid)));
> +    stubdom_id_s = libxl__xs_read(gc, XBT_NULL,
> +                                 libxl__sprintf(gc, "%s/image/device-model-domid",
> +                                               libxl__xs_get_dompath(gc, guest_domid)));
>      if (stubdom_id_s)
>          ret = atoi(stubdom_id_s);
>      else
>          ret = 0;
> -    libxl__free_all(&gc);
> +    GC_FREE;
>      return ret;
>  }
> 
>  int libxl_is_stubdom(libxl_ctx *ctx, uint32_t domid, uint32_t *target_domid)
>  {
> -    libxl__gc gc = LIBXL_INIT_GC(ctx);
> +    GC_INIT(ctx);
>      char *target, *endptr;
>      uint32_t value;
>      int ret = 0;
> 
> -    target = libxl__xs_read(&gc, XBT_NULL, libxl__sprintf(&gc, "%s/target", libxl__xs_get_dompath(&gc, domid)));
> +    target = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/target", libxl__xs_get_dompath(gc, domid)));
>      if (!target)
>          goto out;
>      value = strtol(target, &endptr, 10);
> @@ -218,7 +218,7 @@ int libxl_is_stubdom(libxl_ctx *ctx, uint32_t domid, uint32_t *target_domid)
>          *target_domid = value;
>      ret = 1;
>  out:
> -    libxl__free_all(&gc);
> +    GC_FREE;
>      return ret;
>  }
> 
> @@ -240,27 +240,27 @@ static int logrename(libxl__gc *gc, const char *old, const char *new)
> 
>  int libxl_create_logfile(libxl_ctx *ctx, char *name, char **full_name)
>  {
> -    libxl__gc gc = LIBXL_INIT_GC(ctx);
> +    GC_INIT(ctx);
>      struct stat stat_buf;
>      char *logfile, *logfile_new;
>      int i, rc;
> 
> -    logfile = libxl__sprintf(&gc, "/var/log/xen/%s.log", name);
> +    logfile = libxl__sprintf(gc, "/var/log/xen/%s.log", name);
>      if (stat(logfile, &stat_buf) == 0) {
>          /* file exists, rotate */
> -        logfile = libxl__sprintf(&gc, "/var/log/xen/%s.log.10", name);
> +        logfile = libxl__sprintf(gc, "/var/log/xen/%s.log.10", name);
>          unlink(logfile);
>          for (i = 9; i > 0; i--) {
> -            logfile = libxl__sprintf(&gc, "/var/log/xen/%s.log.%d", name, i);
> -            logfile_new = libxl__sprintf(&gc, "/var/log/xen/%s.log.%d", name, i + 1);
> -            rc = logrename(&gc, logfile, logfile_new);
> +            logfile = libxl__sprintf(gc, "/var/log/xen/%s.log.%d", name, i);
> +            logfile_new = libxl__sprintf(gc, "/var/log/xen/%s.log.%d", name, i + 1);
> +            rc = logrename(gc, logfile, logfile_new);
>              if (rc)
>                  goto out;
>          }
> -        logfile = libxl__sprintf(&gc, "/var/log/xen/%s.log", name);
> -        logfile_new = libxl__sprintf(&gc, "/var/log/xen/%s.log.1", name);
> +        logfile = libxl__sprintf(gc, "/var/log/xen/%s.log", name);
> +        logfile_new = libxl__sprintf(gc, "/var/log/xen/%s.log.1", name);
> 
> -        rc = logrename(&gc, logfile, logfile_new);
> +        rc = logrename(gc, logfile, logfile_new);
>          if (rc)
>              goto out;
>      } else {
> @@ -272,7 +272,7 @@ int libxl_create_logfile(libxl_ctx *ctx, char *name, char **full_name)
>      *full_name = strdup(logfile);
>      rc = 0;
>  out:
> -    libxl__free_all(&gc);
> +    GC_FREE;
>      return rc;
>  }
> 
> --
> 1.7.2.5
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 16:35:13 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 16: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.xensource.com>)
	id 1RYKSN-0000qB-K7; Wed, 07 Dec 2011 16:34:55 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RYKSM-0000q1-4z
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 16:34:54 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1323275646!4634529!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjA3NQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6135 invoked from network); 7 Dec 2011 16:34:07 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Dec 2011 16:34:07 -0000
X-IronPort-AV: E=Sophos;i="4.71,314,1320624000"; 
   d="scan'208";a="9347258"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Dec 2011 16:34:06 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 7 Dec 2011
	16:34:06 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Wed, 7 Dec 2011 16:34:06 +0000
In-Reply-To: <1323108621-22654-14-git-send-email-ian.jackson@eu.citrix.com>
References: <1323108621-22654-1-git-send-email-ian.jackson@eu.citrix.com>
	<1323108621-22654-14-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323275646.2969.5.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 13/15] libxl: make LIBXL_INIT_GC a statement,
 not an initialiser
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2011-12-05 at 18:10 +0000, Ian Jackson wrote:
> Previously LIBXL_INIT_GC was an initialiser, which you were expected
> to use like this:
>     libxl__gc gc = LIBXL_INIT_GC(ctx);
> 
> But we are going to want to put things in the gc which are to be
> initialised using other macros.  That means that LIBXL_INIT_GC has to
> become a statement too.  So instead, we make it so that it's used like this:
>     libxl_gc gc;
>     LIBXL_INIT_GC(gc,ctx);
> 
> In fact there is only one caller now, GC_INIT,

Maybe we should just fold LIBXL_INIT_GC into GC_INIT then?

>  which uses this trick:
>     libxl_gc gc[1];
>     LIBXL_INIT_GC(gc[0],ctx);

Ian.

> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
> ---
>  tools/libxl/libxl_internal.h |    9 +++++++--
>  1 files changed, 7 insertions(+), 2 deletions(-)
> 
> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> index 1d1dc35..d015c7c 100644
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
> @@ -145,7 +145,12 @@ typedef struct {
>      libxl_ctx *owner;
>  } libxl__gc;
>  
> -#define LIBXL_INIT_GC(ctx) (libxl__gc){ .alloc_maxsize = 0, .alloc_ptrs = 0, .owner = ctx }
> +#define LIBXL_INIT_GC(gc,ctx) do{               \
> +        (gc).alloc_maxsize = 0;                 \
> +        (gc).alloc_ptrs = 0;                    \
> +        (gc).owner = (ctx);                     \
> +    } while(0)
> +
>  static inline libxl_ctx *libxl__gc_owner(libxl__gc *gc)
>  {
>      return gc->owner;
> @@ -676,7 +681,7 @@ libxl__device_model_version_running(libxl__gc *gc, uint32_t domid);
>   * as a local variable.
>   */
>  
> -#define GC_INIT(ctx)  libxl__gc gc[1] = { LIBXL_INIT_GC(ctx) }
> +#define GC_INIT(ctx)  libxl__gc gc[1]; LIBXL_INIT_GC(gc[0],ctx)
>  #define GC_FREE       libxl__free_all(gc)
>  #define CTX           libxl__gc_owner(gc)
>  



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 16:35:13 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 16: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.xensource.com>)
	id 1RYKSN-0000qB-K7; Wed, 07 Dec 2011 16:34:55 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RYKSM-0000q1-4z
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 16:34:54 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1323275646!4634529!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjA3NQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6135 invoked from network); 7 Dec 2011 16:34:07 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Dec 2011 16:34:07 -0000
X-IronPort-AV: E=Sophos;i="4.71,314,1320624000"; 
   d="scan'208";a="9347258"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Dec 2011 16:34:06 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 7 Dec 2011
	16:34:06 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Wed, 7 Dec 2011 16:34:06 +0000
In-Reply-To: <1323108621-22654-14-git-send-email-ian.jackson@eu.citrix.com>
References: <1323108621-22654-1-git-send-email-ian.jackson@eu.citrix.com>
	<1323108621-22654-14-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323275646.2969.5.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 13/15] libxl: make LIBXL_INIT_GC a statement,
 not an initialiser
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2011-12-05 at 18:10 +0000, Ian Jackson wrote:
> Previously LIBXL_INIT_GC was an initialiser, which you were expected
> to use like this:
>     libxl__gc gc = LIBXL_INIT_GC(ctx);
> 
> But we are going to want to put things in the gc which are to be
> initialised using other macros.  That means that LIBXL_INIT_GC has to
> become a statement too.  So instead, we make it so that it's used like this:
>     libxl_gc gc;
>     LIBXL_INIT_GC(gc,ctx);
> 
> In fact there is only one caller now, GC_INIT,

Maybe we should just fold LIBXL_INIT_GC into GC_INIT then?

>  which uses this trick:
>     libxl_gc gc[1];
>     LIBXL_INIT_GC(gc[0],ctx);

Ian.

> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
> ---
>  tools/libxl/libxl_internal.h |    9 +++++++--
>  1 files changed, 7 insertions(+), 2 deletions(-)
> 
> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> index 1d1dc35..d015c7c 100644
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
> @@ -145,7 +145,12 @@ typedef struct {
>      libxl_ctx *owner;
>  } libxl__gc;
>  
> -#define LIBXL_INIT_GC(ctx) (libxl__gc){ .alloc_maxsize = 0, .alloc_ptrs = 0, .owner = ctx }
> +#define LIBXL_INIT_GC(gc,ctx) do{               \
> +        (gc).alloc_maxsize = 0;                 \
> +        (gc).alloc_ptrs = 0;                    \
> +        (gc).owner = (ctx);                     \
> +    } while(0)
> +
>  static inline libxl_ctx *libxl__gc_owner(libxl__gc *gc)
>  {
>      return gc->owner;
> @@ -676,7 +681,7 @@ libxl__device_model_version_running(libxl__gc *gc, uint32_t domid);
>   * as a local variable.
>   */
>  
> -#define GC_INIT(ctx)  libxl__gc gc[1] = { LIBXL_INIT_GC(ctx) }
> +#define GC_INIT(ctx)  libxl__gc gc[1]; LIBXL_INIT_GC(gc[0],ctx)
>  #define GC_FREE       libxl__free_all(gc)
>  #define CTX           libxl__gc_owner(gc)
>  



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 16:39:15 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 16:39:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYKWH-0000zE-9O; Wed, 07 Dec 2011 16:38:57 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RYKWG-0000yz-3U
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 16:38:56 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1323275888!7354540!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjA3NQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29260 invoked from network); 7 Dec 2011 16:38:09 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Dec 2011 16:38:09 -0000
X-IronPort-AV: E=Sophos;i="4.71,314,1320624000"; 
   d="scan'208";a="9347339"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Dec 2011 16:37:35 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 7 Dec 2011
	16:37:35 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Wed, 7 Dec 2011 16:37:35 +0000
In-Reply-To: <1323108621-22654-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1323108621-22654-1-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323275855.2969.9.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH v4 00/15] New event API
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2011-12-05 at 18:10 +0000, Ian Jackson wrote:
[...]
> Please review.  I would like to apply 12/15 in particular ASAP, as it
> is textually very intrusive.  I think 01-12 ought to be pretty
> uncontroversial by now, and I have now tested 02/15 so I think it's
> ready to go in.

I think I have now acked #1-11 either previously or just now, although
my comment on #12 really is about #7 so having either dismissed or
implemented that suggestion I've effectively acked #1-12.

> 14 and 15 have the meat.

I'll look at these next.

> 
> Ian.
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 16:39:15 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 16:39:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYKWH-0000zE-9O; Wed, 07 Dec 2011 16:38:57 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RYKWG-0000yz-3U
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 16:38:56 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1323275888!7354540!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjA3NQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29260 invoked from network); 7 Dec 2011 16:38:09 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Dec 2011 16:38:09 -0000
X-IronPort-AV: E=Sophos;i="4.71,314,1320624000"; 
   d="scan'208";a="9347339"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Dec 2011 16:37:35 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 7 Dec 2011
	16:37:35 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Wed, 7 Dec 2011 16:37:35 +0000
In-Reply-To: <1323108621-22654-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1323108621-22654-1-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323275855.2969.9.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH v4 00/15] New event API
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2011-12-05 at 18:10 +0000, Ian Jackson wrote:
[...]
> Please review.  I would like to apply 12/15 in particular ASAP, as it
> is textually very intrusive.  I think 01-12 ought to be pretty
> uncontroversial by now, and I have now tested 02/15 so I think it's
> ready to go in.

I think I have now acked #1-11 either previously or just now, although
my comment on #12 really is about #7 so having either dismissed or
implemented that suggestion I've effectively acked #1-12.

> 14 and 15 have the meat.

I'll look at these next.

> 
> Ian.
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 16:49:11 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 16:49:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYKfx-0001Ct-JM; Wed, 07 Dec 2011 16:48:57 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RYKfw-0001Ck-0W
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 16:48:56 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1323276451!45809857!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjA3NQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6295 invoked from network); 7 Dec 2011 16:47:32 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Dec 2011 16:47:32 -0000
X-IronPort-AV: E=Sophos;i="4.71,314,1320624000"; 
   d="scan'208";a="9347699"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Dec 2011 16:47:55 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 7 Dec 2011
	16:47:55 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Paul Durrant <Paul.Durrant@citrix.com>
Date: Wed, 7 Dec 2011 16:47:55 +0000
In-Reply-To: <291EDFCB1E9E224A99088639C4762022B5988E543C@LONPMAILBOX01.citrite.net>
References: <152a79fbe918d8a6c63a.1323079622@cosworth.uk.xensource.com>
	<CAP8mzPOSQePUySZirCLTh6K_uJ3pj3ws=4KR0y-ybFKObk0yGw@mail.gmail.com>
	<291EDFCB1E9E224A99088639C4762022B5988E543C@LONPMAILBOX01.citrite.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323276475.2969.12.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "rshriram@cs.ubc.ca" <rshriram@cs.ubc.ca>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] VM generation ID save/restore and migrate
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2011-12-07 at 09:17 +0000, Paul Durrant wrote:
> De-html-ing (again)...

It's Exchange which mangles mails in this way on the receiving end :-(

It appears that gmail sends out a multipart mail with a pretty HTML
version and a proper plain text part (e.g. using ">" style
quoting etc). For some reason Exchange throws away the plain text part and
rerenders the HTML part badly to form the unreadable plain text part you
see on your end.

AFAIK Citrix IT have raised a bug with MS about this.

A workaround might be to ask folks using gmail to turn off the HTML
option (assuming there is such), at least when posting to xen-devel. Not
ideal though.


Ian.

> 
> --
> There is a "if ( (argc != 8) && (argc != 9) ) err()" condition and then
> there is "if (argc >= 10)".
> --
> 
> Yes, good catch. I will fix and re-send.
> 
>   Paul
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 16:49:11 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 16:49:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYKfx-0001Ct-JM; Wed, 07 Dec 2011 16:48:57 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RYKfw-0001Ck-0W
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 16:48:56 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1323276451!45809857!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjA3NQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6295 invoked from network); 7 Dec 2011 16:47:32 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Dec 2011 16:47:32 -0000
X-IronPort-AV: E=Sophos;i="4.71,314,1320624000"; 
   d="scan'208";a="9347699"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Dec 2011 16:47:55 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 7 Dec 2011
	16:47:55 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Paul Durrant <Paul.Durrant@citrix.com>
Date: Wed, 7 Dec 2011 16:47:55 +0000
In-Reply-To: <291EDFCB1E9E224A99088639C4762022B5988E543C@LONPMAILBOX01.citrite.net>
References: <152a79fbe918d8a6c63a.1323079622@cosworth.uk.xensource.com>
	<CAP8mzPOSQePUySZirCLTh6K_uJ3pj3ws=4KR0y-ybFKObk0yGw@mail.gmail.com>
	<291EDFCB1E9E224A99088639C4762022B5988E543C@LONPMAILBOX01.citrite.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323276475.2969.12.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "rshriram@cs.ubc.ca" <rshriram@cs.ubc.ca>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] VM generation ID save/restore and migrate
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2011-12-07 at 09:17 +0000, Paul Durrant wrote:
> De-html-ing (again)...

It's Exchange which mangles mails in this way on the receiving end :-(

It appears that gmail sends out a multipart mail with a pretty HTML
version and a proper plain text part (e.g. using ">" style
quoting etc). For some reason Exchange throws away the plain text part and
rerenders the HTML part badly to form the unreadable plain text part you
see on your end.

AFAIK Citrix IT have raised a bug with MS about this.

A workaround might be to ask folks using gmail to turn off the HTML
option (assuming there is such), at least when posting to xen-devel. Not
ideal though.


Ian.

> 
> --
> There is a "if ( (argc != 8) && (argc != 9) ) err()" condition and then
> there is "if (argc >= 10)".
> --
> 
> Yes, good catch. I will fix and re-send.
> 
>   Paul
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 17:04:34 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 17: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.xensource.com>)
	id 1RYKui-0001t7-SC; Wed, 07 Dec 2011 17:04:12 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RYKuh-0001t2-LD
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 17:04:11 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1323277372!45812060!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjA3NQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23658 invoked from network); 7 Dec 2011 17:02:52 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Dec 2011 17:02:52 -0000
X-IronPort-AV: E=Sophos;i="4.71,314,1320624000"; 
   d="scan'208";a="9348157"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Dec 2011 17:03:29 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 7 Dec 2011 17:03:29 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RYKu0-0003Gj-Rl	for xen-devel@lists.xensource.com;
	Wed, 07 Dec 2011 17:03:28 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RYKu0-0000mA-PL	for
	xen-devel@lists.xensource.com; Wed, 07 Dec 2011 17:03:28 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20191.40032.612115.741853@mariner.uk.xensource.com>
Date: Wed, 7 Dec 2011 17:03:28 +0000
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
In-Reply-To: <osstest-10409-mainreport@xen.org>
References: <osstest-10409-mainreport@xen.org>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Subject: Re: [Xen-devel] [xen-unstable test] 10409: regressions - trouble:
	broken/fail/pass
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

xen.org writes ("[xen-unstable test] 10409: regressions - trouble: broken/fail/pass"):
>  test-i386-i386-xl-win         8 guest-saverestore      fail REGR. vs. 10201

FYI I'm holding off throwing more of the patch backlog into the tree,
until this is fixed.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 17:04:34 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 17: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.xensource.com>)
	id 1RYKui-0001t7-SC; Wed, 07 Dec 2011 17:04:12 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RYKuh-0001t2-LD
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 17:04:11 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1323277372!45812060!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjA3NQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23658 invoked from network); 7 Dec 2011 17:02:52 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Dec 2011 17:02:52 -0000
X-IronPort-AV: E=Sophos;i="4.71,314,1320624000"; 
   d="scan'208";a="9348157"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Dec 2011 17:03:29 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 7 Dec 2011 17:03:29 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RYKu0-0003Gj-Rl	for xen-devel@lists.xensource.com;
	Wed, 07 Dec 2011 17:03:28 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RYKu0-0000mA-PL	for
	xen-devel@lists.xensource.com; Wed, 07 Dec 2011 17:03:28 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20191.40032.612115.741853@mariner.uk.xensource.com>
Date: Wed, 7 Dec 2011 17:03:28 +0000
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
In-Reply-To: <osstest-10409-mainreport@xen.org>
References: <osstest-10409-mainreport@xen.org>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Subject: Re: [Xen-devel] [xen-unstable test] 10409: regressions - trouble:
	broken/fail/pass
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

xen.org writes ("[xen-unstable test] 10409: regressions - trouble: broken/fail/pass"):
>  test-i386-i386-xl-win         8 guest-saverestore      fail REGR. vs. 10201

FYI I'm holding off throwing more of the patch backlog into the tree,
until this is fixed.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 17:16:31 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 17: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.xensource.com>)
	id 1RYL6H-0002Ft-7q; Wed, 07 Dec 2011 17:16:09 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RYL6F-0002Fl-6V
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 17:16:07 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1323278105!58036134!1
X-Originating-IP: [74.125.82.41]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32459 invoked from network); 7 Dec 2011 17:15:05 -0000
Received: from mail-ww0-f41.google.com (HELO mail-ww0-f41.google.com)
	(74.125.82.41)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Dec 2011 17:15:05 -0000
Received: by wgbdt12 with SMTP id dt12so2162964wgb.0
	for <xen-devel@lists.xensource.com>;
	Wed, 07 Dec 2011 09:15:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=Tzd+q0t3PNuD74Mudo4Wsgk4r1OJoy/JgqU7T8SU9sY=;
	b=mU+c2E4WspOTSjH6icwPd6CqXZ1zoChSAAg0rRJcPnPyY/gfEnzohq/GtqkKElBZl3
	fESmaUtU98mfOqzI0RwjfpgsotJVRAEuh/QSCpGgCdlUANAV+Bhrt8MhFJiwHLNOoEwv
	TC/Ldiq5MqeSl6VinHHNeqX35BoCzZ/8Lk0hU=
Received: by 10.216.192.8 with SMTP id h8mr822070wen.4.1323278121864;
	Wed, 07 Dec 2011 09:15:21 -0800 (PST)
Received: from [192.168.1.70]
	(host81-155-119-104.range81-155.btcentralplus.com. [81.155.119.104])
	by mx.google.com with ESMTPS id 6sm3912781wby.22.2011.12.07.09.15.20
	(version=SSLv3 cipher=OTHER); Wed, 07 Dec 2011 09:15:21 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Wed, 07 Dec 2011 17:15:18 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Message-ID: <CB054FA6.26C26%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [xen-unstable test] 10409: regressions - trouble:
	broken/fail/pass
Thread-Index: Acy1A8reo/gTv+Zc8U6GnbBSIyK1sA==
In-Reply-To: <20191.40032.612115.741853@mariner.uk.xensource.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [xen-unstable test] 10409: regressions - trouble:
 broken/fail/pass
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 07/12/2011 17:03, "Ian Jackson" <Ian.Jackson@eu.citrix.com> wrote:

> xen.org writes ("[xen-unstable test] 10409: regressions - trouble:
> broken/fail/pass"):
>>  test-i386-i386-xl-win         8 guest-saverestore      fail REGR. vs. 10201
> 
> FYI I'm holding off throwing more of the patch backlog into the tree,
> until this is fixed.

Who's to blame?

> Ian.
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 17:16:31 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 17: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.xensource.com>)
	id 1RYL6H-0002Ft-7q; Wed, 07 Dec 2011 17:16:09 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RYL6F-0002Fl-6V
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 17:16:07 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1323278105!58036134!1
X-Originating-IP: [74.125.82.41]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32459 invoked from network); 7 Dec 2011 17:15:05 -0000
Received: from mail-ww0-f41.google.com (HELO mail-ww0-f41.google.com)
	(74.125.82.41)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Dec 2011 17:15:05 -0000
Received: by wgbdt12 with SMTP id dt12so2162964wgb.0
	for <xen-devel@lists.xensource.com>;
	Wed, 07 Dec 2011 09:15:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=Tzd+q0t3PNuD74Mudo4Wsgk4r1OJoy/JgqU7T8SU9sY=;
	b=mU+c2E4WspOTSjH6icwPd6CqXZ1zoChSAAg0rRJcPnPyY/gfEnzohq/GtqkKElBZl3
	fESmaUtU98mfOqzI0RwjfpgsotJVRAEuh/QSCpGgCdlUANAV+Bhrt8MhFJiwHLNOoEwv
	TC/Ldiq5MqeSl6VinHHNeqX35BoCzZ/8Lk0hU=
Received: by 10.216.192.8 with SMTP id h8mr822070wen.4.1323278121864;
	Wed, 07 Dec 2011 09:15:21 -0800 (PST)
Received: from [192.168.1.70]
	(host81-155-119-104.range81-155.btcentralplus.com. [81.155.119.104])
	by mx.google.com with ESMTPS id 6sm3912781wby.22.2011.12.07.09.15.20
	(version=SSLv3 cipher=OTHER); Wed, 07 Dec 2011 09:15:21 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Wed, 07 Dec 2011 17:15:18 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Message-ID: <CB054FA6.26C26%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [xen-unstable test] 10409: regressions - trouble:
	broken/fail/pass
Thread-Index: Acy1A8reo/gTv+Zc8U6GnbBSIyK1sA==
In-Reply-To: <20191.40032.612115.741853@mariner.uk.xensource.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [xen-unstable test] 10409: regressions - trouble:
 broken/fail/pass
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 07/12/2011 17:03, "Ian Jackson" <Ian.Jackson@eu.citrix.com> wrote:

> xen.org writes ("[xen-unstable test] 10409: regressions - trouble:
> broken/fail/pass"):
>>  test-i386-i386-xl-win         8 guest-saverestore      fail REGR. vs. 10201
> 
> FYI I'm holding off throwing more of the patch backlog into the tree,
> until this is fixed.

Who's to blame?

> Ian.
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 17:37:02 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 17:37:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYLQ3-0003J5-4G; Wed, 07 Dec 2011 17:36:35 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RYLQ0-0003It-4X
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 17:36:32 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1323279344!6581913!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjA3NQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29685 invoked from network); 7 Dec 2011 17:35:44 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Dec 2011 17:35:44 -0000
X-IronPort-AV: E=Sophos;i="4.71,315,1320624000"; 
   d="scan'208";a="9348751"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Dec 2011 17:35:43 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 7 Dec 2011
	17:35:44 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Wed, 7 Dec 2011 17:35:43 +0000
In-Reply-To: <1323108621-22654-15-git-send-email-ian.jackson@eu.citrix.com>
References: <1323108621-22654-1-git-send-email-ian.jackson@eu.citrix.com>
	<1323108621-22654-15-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323279343.2969.44.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 14/15] libxl: New API for providing OS
 events to libxl
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2011-12-05 at 18:10 +0000, Ian Jackson wrote:

> diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
> index 289dc85..654a5b0 100644
> --- a/tools/libxl/libxl.h
> +++ b/tools/libxl/libxl.h
> @@ -137,6 +137,7 @@
>  #include <xen/sysctl.h>
> 
>  #include <libxl_uuid.h>
> +#include <_libxl_list.h>

Do we expose the use of these to users anywhere? I've failed to spot it
if so (at least in this patch). If it is deliberate then #3 needs to
install this header.

> [...]
> @@ -635,6 +639,8 @@ const char *libxl_lock_dir_path(void);
>  const char *libxl_run_dir_path(void);
>  const char *libxl_xenpaging_dir_path(void);
> 
> +#include <libxl_event.h>
> +

Putting this at the end is a bit odd, I don't really object though. I
suppose it depends on stuff defined in this header and putting it half
way through is even more odd.

>  #endif /* LIBXL_H */
> 
>  /*
> diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
> new file mode 100644
> index 0000000..8d4dbf6
> --- /dev/null
> +++ b/tools/libxl/libxl_event.c
> @@ -0,0 +1,711 @@
> +/*
> + * Copyright (C) 2011      Citrix Ltd.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU Lesser General Public License as published
> + * by the Free Software Foundation; version 2.1 only. with the special
> + * exception on linking described in file LICENSE.

I've only just noticed this but it is present in some other libxl files
too. There is no LICENSE file in tools/libxl:
        $ find -name LICENSE
        ./tools/ioemu-remote/LICENSE
        ./tools/ioemu-remote/tcg/LICENSE
        ./tools/ocaml/LICENSE
        ./xen/tools/figlet/LICENSE

I suspect this is a cut-and-paste-o, probably from tools/ocaml?

> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU Lesser General Public License for more details.
> + */
> +/*
> + * Internal event machinery for use by other parts of libxl
> + */
> +
> +#include <poll.h>
> +
> +#include "libxl_internal.h"
> +
> +/*
> + * The counter osevent_in_hook is used to ensure that the application
> + * honours the reentrancy restriction documented in libxl_event.h.
> + *
> + * The application's registration hooks should be called ONLY via
> + * these macros, with the ctx locked.  Likewise all the "occurred"
> + * entrypoints from the application should assert(!in_hook);

In RFC speak you mean MUST rather than should both times here, right?

> + */
> +#define OSEVENT_HOOK_INTERN(defval, hookname, ...)                      \
> +    (CTX->osevent_hooks                                                 \
> +     ? (CTX->osevent_in_hook++,                                         \
> +        CTX->osevent_hooks->hookname(CTX->osevent_user, __VA_ARGS__),   \
> +        CTX->osevent_in_hook--)                                         \
> +     : defval)
> +
> +#define OSEVENT_HOOK(hookname,...)                      \
> +    OSEVENT_HOOK_INTERN(0, hookname, __VA_ARGS__)
> +
> +#define OSEVENT_HOOK_VOID(hookname,...)                 \
> +    OSEVENT_HOOK_INTERN((void)0, hookname, __VA_ARGS__)
> +
> +/*
> + * fd events
> + */
> +
> +int libxl__ev_fd_register(libxl__gc *gc, libxl__ev_fd *ev,
> +                          libxl__ev_fd_callback *func,
> +                          int fd, short events) {

Strictly speaking CODING_STYLE requires the { to be on the next line.

> +    int rc;
> +
> +    assert(fd >= 0);
> +
> +    CTX_LOCK;
> +
> +    rc = OSEVENT_HOOK(fd_register, fd, &ev->for_app_reg, events, ev);
> +    if (rc) goto out;
> +
> +    LIBXL_LIST_INSERT_HEAD(&CTX->efds, ev, entry);
> +
> +    ev->fd = fd;
> +    ev->events = events;
> +    ev->in_beforepolled = -1;
> +    ev->func = func;

Even though this is all locked correctly seeing the ev initialised after
it is already on the list has tweaked my "what's up" instinct such that
I've had to look twice both times I've looked at this patch.

> +
> +    rc = 0;
> +
> + out:
> +    CTX_UNLOCK;
> +    return rc;
> +}
> +
[...]
> +int libxl__ev_time_register_rel(libxl__gc *gc, libxl__ev_time *ev,
> +                                libxl__ev_time_callback *func,
> +                                int milliseconds /* as for poll(2) */) {
> +    struct timeval abs;
> +    int rc;
> +
> +    CTX_LOCK;
> +
> +    if (milliseconds < 0) {
> +        ev->infinite = 1;

diff has inconveniently chosen to present me with the implementation
before the interface. /me scurries off to read libxl_events.h. OK I see
why this == infinite now (it even tells me 5 lines before, oh well).

> +    } else {
> +        rc = time_rel_to_abs(gc, milliseconds, &abs);
> +        if (rc) goto out;
> +
> +        rc = time_register_finite(gc, ev, abs);
> +        if (rc) goto out;
> +    }
> +
> +    ev->func = func;
> +    rc = 0;
> +
> + out:
> +    CTX_UNLOCK;
> +    return 0;

You mean "return rc" here.

> +}
> +
> +int libxl__ev_time_modify_abs(libxl__gc *gc, libxl__ev_time *ev,
> +                              struct timeval abs) {
> +    int rc;
> +
> +    CTX_LOCK;
> +
> +    assert(libxl__ev_time_isregistered(ev));

Why is there no deregister here? Is libxl__ev_time_modify_rel the only
caller?

> +
> +    if (ev->infinite) {
> +        rc = time_register_finite(gc, ev, abs);
> +        if (rc) goto out;
> +    } else {
> +        rc = OSEVENT_HOOK(timeout_modify, &ev->for_app_reg, abs);
> +        if (rc) goto out;
> +
> +        LIBXL_TAILQ_REMOVE(&CTX->etimes, ev, entry);
> +        ev->abs = abs;
> +        time_insert_finite(gc, ev);
> +    }
> +
> +    rc = 0;
> + out:
> +    CTX_UNLOCK;
> +    return rc;
> +}
> +
> +int libxl__ev_time_modify_rel(libxl__gc *gc, libxl__ev_time *ev,
> +                              int milliseconds) {
> +    struct timeval abs;
> +    int rc;
> +
> +    CTX_LOCK;
> +
> +    assert(libxl__ev_time_isregistered(ev));
> +
> +    if (milliseconds < 0) {
> +        time_deregister(gc, ev);
> +        ev->infinite = 1;
> +        rc = 0;
> +        goto out;
> +    }
> +
> +    rc = time_rel_to_abs(gc, milliseconds, &abs);
> +    if (rc) goto out;
> +
> +    rc = libxl__ev_time_modify_abs(gc, ev, abs);
> +    if (rc) goto out;
> +
> +    rc = 0;
> + out:
> +    CTX_UNLOCK;
> +    return 0;

> [...]
> +
> +/*
> + * xenstore watches
> + */
> +[...]
> +
> +static void watchfd_callback(libxl__gc *gc, libxl__ev_fd *ev,
> +                             int fd, short events, short revents) {
> +    for (;;) {
> +        char **event = xs_check_watch(CTX->xsh);
> +        if (!event) {
> +            if (errno == EAGAIN) break;
> +            if (errno == EINTR) continue;
> +            LIBXL__EVENT_DISASTER(gc, "cannot check/read watches", errno, 0);
> +            return;
> +        }
> +
> +        const char *epath = event[0];
> +        const char *token = event[1];
> +        int slotnum;
> +        uint32_t counterval;
> +        int rc = sscanf(token, "%d/%"SCNx32, &slotnum, &counterval);

How have I never come across the SCNxxx counterpart to PRIxxx before!

> +        if (rc != 2) {
> +            LIBXL__LOG(CTX, LIBXL__LOG_ERROR,
> +                       "watch epath=%s token=%s: failed to parse token",
> +                       epath, token);
> +            /* oh well */
> +            goto ignore;
> +        }
> +        if (slotnum < 0 || slotnum >= CTX->watch_nslots) {
> +            /* perhaps in the future we will make the watchslots array shrink */
> +            LIBXL__LOG(CTX, LIBXL__LOG_DEBUG, "watch epath=%s token=%s:"
> +                       " slotnum %d out of range [0,%d>",
> +                       epath, token, slotnum, CTX->watch_nslots);
> +            goto ignore;
> +        }
> +
> +        libxl__ev_xswatch *w = libxl__watch_slot_contents(gc, slotnum);
> +
> +        if (!w) {
> +            LIBXL__LOG(CTX, LIBXL__LOG_DEBUG,
> +                       "watch epath=%s token=%s: empty slot",
> +                       epath, token);
> +            goto ignore;
> +        }
> +
> +        if (w->counterval != counterval) {
> +            LIBXL__LOG(CTX, LIBXL__LOG_DEBUG,
> +                       "watch epath=%s token=%s: counter != %"PRIx32,
> +                       epath, token, w->counterval);
> +            goto ignore;
> +        }
> +
> +        /* Now it's possible, though unlikely, that this was an event
> +         * from a previous use of the same slot with the same counterval.
> +         *
> +         * In that case either:
> +         *  - the event path is a child of the watch path, in
> +         *    which case this watch would really have generated this
> +         *    event if it had been registered soon enough and we are
> +         *    OK to give this possibly-spurious event to the caller; or
> +         * - it is not, in which case we must suppress it as the
> +         *   caller should not see events for unrelated paths.
> +         *
> +         * See also docs/misc/xenstore.txt.
> +         */
> +        size_t epathlen = strlen(epath);
> +        size_t wpathlen = strlen(w->path);
> +        if (epathlen < wpathlen ||
> +            memcmp(epath, w->path, wpathlen) ||
> +            (epathlen > wpathlen && epath[wpathlen] != '/')) {
> +            LIBXL__LOG(CTX, LIBXL__LOG_DEBUG,
> +                       "watch epath=%s token=%s: not child of wpath=%s",
> +                       epath, token, w->path);

It seems like this is worthy of a helper function of its own. Possibly
in libxenstore itself?

> +            goto ignore;
> +        }
> +
> +        /* At last, we have checked everything! */

Huzzah!

> +        LIBXL__LOG(CTX, LIBXL__LOG_DEBUG,
> +                   "watch event: epath=%s token=%s wpath=%s w=%p",
> +                   epath, token, w->path, w);

Aside: At some point we might want to have a way to configure classes of
debug log message on/off. I was just wondering if this message might be
a bit spammy but I suspect it is ok.

> +        w->callback(gc, w, w->path, epath);
> +
> +    ignore:
> +        free(event);
> +    }
> +}
[...]
> +int libxl__ev_xswatch_register(libxl__gc *gc, libxl__ev_xswatch *w,
> +                               libxl__ev_xswatch_callback *func,
> +                               const char *path /* copied */) {
> +    libxl__ev_watch_slot *use = NULL;
> +    char *path_copy = NULL;
> +    int rc;
> +
> +    CTX_LOCK;
> +
> +    if (!libxl__ev_fd_isregistered(&CTX->watch_efd)) {
> +        rc = libxl__ev_fd_register(gc, &CTX->watch_efd, watchfd_callback,
> +                                   xs_fileno(CTX->xsh), POLLIN);
> +        if (rc) goto out_rc;
> +    }
> +
> +    if (LIBXL_SLIST_EMPTY(&CTX->watch_freeslots)) {
> +        /* Free list is empty so there is not in fact a linked
> +         * free list in the array and we can safely realloc it */
> +        int newarraysize = (CTX->watch_nslots + 1) << 2;
> +        int i;
> +        libxl__ev_watch_slot *newarray =
> +            realloc(CTX->watch_slots, sizeof(*newarray) * newarraysize);
> +        if (!newarray) goto out_nomem;
> +        for (i=CTX->watch_nslots; i<newarraysize; i++)
> +            LIBXL_SLIST_INSERT_HEAD(&CTX->watch_freeslots,
> +                                    &newarray[i], empty);
> +        CTX->watch_slots = newarray;
> +        CTX->watch_nslots = newarraysize;
> +    }
> +    use = LIBXL_SLIST_FIRST(&CTX->watch_freeslots);
> +    assert(use);
> +    LIBXL_SLIST_REMOVE_HEAD(&CTX->watch_freeslots, empty);

I presume this is removing "use" from the list. It seems odd to refer to
that element of the list as HEAD and FIRST interchangeably since it
doesn't make this obvious but I guess we got this API from elsewhere.

There's no get-and-return function which combines the two operations?

> +
> +    path_copy = strdup(path);
> +    if (!path_copy) goto out_nomem;
> +
> +    int slotnum = use - CTX->watch_slots;
> +    w->counterval = CTX->watch_counter++;
> +
> +    if (!xs_watch(CTX->xsh, path, watch_token(gc, slotnum, w->counterval))) {
> +        LIBXL__LOG_ERRNOVAL(CTX, LIBXL__LOG_ERROR, errno,
> +                            "create watch for path %s", path);
> +        rc = ERROR_FAIL;
> +        goto out_rc;
> +    }
> +
> +    w->slotnum = slotnum;
> +    w->path = path_copy;
> +    w->callback = func;
> +    /* we look a bit behind the curtain of LIBXL_SLIST, to explictly

explicitly

> +     * assign to the pointer that's the next link.  See the comment
> +     * by the definitionn of libxl__ev_watch_slot */

definition.

I think this behind the curtain stuff would be better encapsulated in a
macro up somewhere near the comment and libxl__ev_watch_slot.

> +    use->empty.sle_next = (void*)w;


> +
> +    CTX_UNLOCK;
> +    return 0;
> +
> + out_nomem:
> +    rc = ERROR_NOMEM;
> + out_rc:
> +    if (use)
> +        LIBXL_SLIST_INSERT_HEAD(&CTX->watch_freeslots, use, empty);
> +    if (path_copy)
> +        free(path_copy);
> +    CTX_UNLOCK;
> +    return rc;
> +}
> +
> +void libxl__ev_xswatch_deregister(libxl__gc *gc, libxl__ev_xswatch *w) {
> +    /* it is legal to deregister from within _callback */

and CTX_LOCK is recursive so this is ok.

> +    CTX_LOCK;
> +
> +    if (w->slotnum >= 0) {
> +        char *token = watch_token(gc, w->slotnum, w->counterval);
> +        if (!xs_unwatch(CTX->xsh, w->path, token))
> +            /* Oh well, we will just get watch events forever more
> +             * and ignore them.  But we should complain to the log. */
> +            LIBXL__LOG_ERRNOVAL(CTX, LIBXL__LOG_ERROR, errno,
> +                                "remove watch for path %s", w->path);

Is it possible to also unwatch an unexpected watch at the point it
fires, IOW to try again later? I havn'et looked at the potential failure
cases of xs_unwatch so perhaps once it has failed there is no point in
trying again.

> +
> +        libxl__ev_watch_slot *slot = &CTX->watch_slots[w->slotnum];
> +        LIBXL_SLIST_INSERT_HEAD(&CTX->watch_freeslots, slot, empty);
> +    }
> +
> +    free(w->path);
> +    w->path = NULL;
> +
> +    CTX_UNLOCK;
> +}
> +
> +/*
> + * osevent poll
> + */

This seems like a good place to stop for the day. I'll pickup the rest
tomorrow.

[...]


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 17:37:02 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 17:37:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYLQ3-0003J5-4G; Wed, 07 Dec 2011 17:36:35 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RYLQ0-0003It-4X
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 17:36:32 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1323279344!6581913!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjA3NQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29685 invoked from network); 7 Dec 2011 17:35:44 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Dec 2011 17:35:44 -0000
X-IronPort-AV: E=Sophos;i="4.71,315,1320624000"; 
   d="scan'208";a="9348751"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Dec 2011 17:35:43 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 7 Dec 2011
	17:35:44 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Wed, 7 Dec 2011 17:35:43 +0000
In-Reply-To: <1323108621-22654-15-git-send-email-ian.jackson@eu.citrix.com>
References: <1323108621-22654-1-git-send-email-ian.jackson@eu.citrix.com>
	<1323108621-22654-15-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323279343.2969.44.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 14/15] libxl: New API for providing OS
 events to libxl
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2011-12-05 at 18:10 +0000, Ian Jackson wrote:

> diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
> index 289dc85..654a5b0 100644
> --- a/tools/libxl/libxl.h
> +++ b/tools/libxl/libxl.h
> @@ -137,6 +137,7 @@
>  #include <xen/sysctl.h>
> 
>  #include <libxl_uuid.h>
> +#include <_libxl_list.h>

Do we expose the use of these to users anywhere? I've failed to spot it
if so (at least in this patch). If it is deliberate then #3 needs to
install this header.

> [...]
> @@ -635,6 +639,8 @@ const char *libxl_lock_dir_path(void);
>  const char *libxl_run_dir_path(void);
>  const char *libxl_xenpaging_dir_path(void);
> 
> +#include <libxl_event.h>
> +

Putting this at the end is a bit odd, I don't really object though. I
suppose it depends on stuff defined in this header and putting it half
way through is even more odd.

>  #endif /* LIBXL_H */
> 
>  /*
> diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
> new file mode 100644
> index 0000000..8d4dbf6
> --- /dev/null
> +++ b/tools/libxl/libxl_event.c
> @@ -0,0 +1,711 @@
> +/*
> + * Copyright (C) 2011      Citrix Ltd.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU Lesser General Public License as published
> + * by the Free Software Foundation; version 2.1 only. with the special
> + * exception on linking described in file LICENSE.

I've only just noticed this but it is present in some other libxl files
too. There is no LICENSE file in tools/libxl:
        $ find -name LICENSE
        ./tools/ioemu-remote/LICENSE
        ./tools/ioemu-remote/tcg/LICENSE
        ./tools/ocaml/LICENSE
        ./xen/tools/figlet/LICENSE

I suspect this is a cut-and-paste-o, probably from tools/ocaml?

> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU Lesser General Public License for more details.
> + */
> +/*
> + * Internal event machinery for use by other parts of libxl
> + */
> +
> +#include <poll.h>
> +
> +#include "libxl_internal.h"
> +
> +/*
> + * The counter osevent_in_hook is used to ensure that the application
> + * honours the reentrancy restriction documented in libxl_event.h.
> + *
> + * The application's registration hooks should be called ONLY via
> + * these macros, with the ctx locked.  Likewise all the "occurred"
> + * entrypoints from the application should assert(!in_hook);

In RFC speak you mean MUST rather than should both times here, right?

> + */
> +#define OSEVENT_HOOK_INTERN(defval, hookname, ...)                      \
> +    (CTX->osevent_hooks                                                 \
> +     ? (CTX->osevent_in_hook++,                                         \
> +        CTX->osevent_hooks->hookname(CTX->osevent_user, __VA_ARGS__),   \
> +        CTX->osevent_in_hook--)                                         \
> +     : defval)
> +
> +#define OSEVENT_HOOK(hookname,...)                      \
> +    OSEVENT_HOOK_INTERN(0, hookname, __VA_ARGS__)
> +
> +#define OSEVENT_HOOK_VOID(hookname,...)                 \
> +    OSEVENT_HOOK_INTERN((void)0, hookname, __VA_ARGS__)
> +
> +/*
> + * fd events
> + */
> +
> +int libxl__ev_fd_register(libxl__gc *gc, libxl__ev_fd *ev,
> +                          libxl__ev_fd_callback *func,
> +                          int fd, short events) {

Strictly speaking CODING_STYLE requires the { to be on the next line.

> +    int rc;
> +
> +    assert(fd >= 0);
> +
> +    CTX_LOCK;
> +
> +    rc = OSEVENT_HOOK(fd_register, fd, &ev->for_app_reg, events, ev);
> +    if (rc) goto out;
> +
> +    LIBXL_LIST_INSERT_HEAD(&CTX->efds, ev, entry);
> +
> +    ev->fd = fd;
> +    ev->events = events;
> +    ev->in_beforepolled = -1;
> +    ev->func = func;

Even though this is all locked correctly seeing the ev initialised after
it is already on the list has tweaked my "what's up" instinct such that
I've had to look twice both times I've looked at this patch.

> +
> +    rc = 0;
> +
> + out:
> +    CTX_UNLOCK;
> +    return rc;
> +}
> +
[...]
> +int libxl__ev_time_register_rel(libxl__gc *gc, libxl__ev_time *ev,
> +                                libxl__ev_time_callback *func,
> +                                int milliseconds /* as for poll(2) */) {
> +    struct timeval abs;
> +    int rc;
> +
> +    CTX_LOCK;
> +
> +    if (milliseconds < 0) {
> +        ev->infinite = 1;

diff has inconveniently chosen to present me with the implementation
before the interface. /me scurries off to read libxl_events.h. OK I see
why this == infinite now (it even tells me 5 lines before, oh well).

> +    } else {
> +        rc = time_rel_to_abs(gc, milliseconds, &abs);
> +        if (rc) goto out;
> +
> +        rc = time_register_finite(gc, ev, abs);
> +        if (rc) goto out;
> +    }
> +
> +    ev->func = func;
> +    rc = 0;
> +
> + out:
> +    CTX_UNLOCK;
> +    return 0;

You mean "return rc" here.

> +}
> +
> +int libxl__ev_time_modify_abs(libxl__gc *gc, libxl__ev_time *ev,
> +                              struct timeval abs) {
> +    int rc;
> +
> +    CTX_LOCK;
> +
> +    assert(libxl__ev_time_isregistered(ev));

Why is there no deregister here? Is libxl__ev_time_modify_rel the only
caller?

> +
> +    if (ev->infinite) {
> +        rc = time_register_finite(gc, ev, abs);
> +        if (rc) goto out;
> +    } else {
> +        rc = OSEVENT_HOOK(timeout_modify, &ev->for_app_reg, abs);
> +        if (rc) goto out;
> +
> +        LIBXL_TAILQ_REMOVE(&CTX->etimes, ev, entry);
> +        ev->abs = abs;
> +        time_insert_finite(gc, ev);
> +    }
> +
> +    rc = 0;
> + out:
> +    CTX_UNLOCK;
> +    return rc;
> +}
> +
> +int libxl__ev_time_modify_rel(libxl__gc *gc, libxl__ev_time *ev,
> +                              int milliseconds) {
> +    struct timeval abs;
> +    int rc;
> +
> +    CTX_LOCK;
> +
> +    assert(libxl__ev_time_isregistered(ev));
> +
> +    if (milliseconds < 0) {
> +        time_deregister(gc, ev);
> +        ev->infinite = 1;
> +        rc = 0;
> +        goto out;
> +    }
> +
> +    rc = time_rel_to_abs(gc, milliseconds, &abs);
> +    if (rc) goto out;
> +
> +    rc = libxl__ev_time_modify_abs(gc, ev, abs);
> +    if (rc) goto out;
> +
> +    rc = 0;
> + out:
> +    CTX_UNLOCK;
> +    return 0;

> [...]
> +
> +/*
> + * xenstore watches
> + */
> +[...]
> +
> +static void watchfd_callback(libxl__gc *gc, libxl__ev_fd *ev,
> +                             int fd, short events, short revents) {
> +    for (;;) {
> +        char **event = xs_check_watch(CTX->xsh);
> +        if (!event) {
> +            if (errno == EAGAIN) break;
> +            if (errno == EINTR) continue;
> +            LIBXL__EVENT_DISASTER(gc, "cannot check/read watches", errno, 0);
> +            return;
> +        }
> +
> +        const char *epath = event[0];
> +        const char *token = event[1];
> +        int slotnum;
> +        uint32_t counterval;
> +        int rc = sscanf(token, "%d/%"SCNx32, &slotnum, &counterval);

How have I never come across the SCNxxx counterpart to PRIxxx before!

> +        if (rc != 2) {
> +            LIBXL__LOG(CTX, LIBXL__LOG_ERROR,
> +                       "watch epath=%s token=%s: failed to parse token",
> +                       epath, token);
> +            /* oh well */
> +            goto ignore;
> +        }
> +        if (slotnum < 0 || slotnum >= CTX->watch_nslots) {
> +            /* perhaps in the future we will make the watchslots array shrink */
> +            LIBXL__LOG(CTX, LIBXL__LOG_DEBUG, "watch epath=%s token=%s:"
> +                       " slotnum %d out of range [0,%d>",
> +                       epath, token, slotnum, CTX->watch_nslots);
> +            goto ignore;
> +        }
> +
> +        libxl__ev_xswatch *w = libxl__watch_slot_contents(gc, slotnum);
> +
> +        if (!w) {
> +            LIBXL__LOG(CTX, LIBXL__LOG_DEBUG,
> +                       "watch epath=%s token=%s: empty slot",
> +                       epath, token);
> +            goto ignore;
> +        }
> +
> +        if (w->counterval != counterval) {
> +            LIBXL__LOG(CTX, LIBXL__LOG_DEBUG,
> +                       "watch epath=%s token=%s: counter != %"PRIx32,
> +                       epath, token, w->counterval);
> +            goto ignore;
> +        }
> +
> +        /* Now it's possible, though unlikely, that this was an event
> +         * from a previous use of the same slot with the same counterval.
> +         *
> +         * In that case either:
> +         *  - the event path is a child of the watch path, in
> +         *    which case this watch would really have generated this
> +         *    event if it had been registered soon enough and we are
> +         *    OK to give this possibly-spurious event to the caller; or
> +         * - it is not, in which case we must suppress it as the
> +         *   caller should not see events for unrelated paths.
> +         *
> +         * See also docs/misc/xenstore.txt.
> +         */
> +        size_t epathlen = strlen(epath);
> +        size_t wpathlen = strlen(w->path);
> +        if (epathlen < wpathlen ||
> +            memcmp(epath, w->path, wpathlen) ||
> +            (epathlen > wpathlen && epath[wpathlen] != '/')) {
> +            LIBXL__LOG(CTX, LIBXL__LOG_DEBUG,
> +                       "watch epath=%s token=%s: not child of wpath=%s",
> +                       epath, token, w->path);

It seems like this is worthy of a helper function of its own. Possibly
in libxenstore itself?

> +            goto ignore;
> +        }
> +
> +        /* At last, we have checked everything! */

Huzzah!

> +        LIBXL__LOG(CTX, LIBXL__LOG_DEBUG,
> +                   "watch event: epath=%s token=%s wpath=%s w=%p",
> +                   epath, token, w->path, w);

Aside: At some point we might want to have a way to configure classes of
debug log message on/off. I was just wondering if this message might be
a bit spammy but I suspect it is ok.

> +        w->callback(gc, w, w->path, epath);
> +
> +    ignore:
> +        free(event);
> +    }
> +}
[...]
> +int libxl__ev_xswatch_register(libxl__gc *gc, libxl__ev_xswatch *w,
> +                               libxl__ev_xswatch_callback *func,
> +                               const char *path /* copied */) {
> +    libxl__ev_watch_slot *use = NULL;
> +    char *path_copy = NULL;
> +    int rc;
> +
> +    CTX_LOCK;
> +
> +    if (!libxl__ev_fd_isregistered(&CTX->watch_efd)) {
> +        rc = libxl__ev_fd_register(gc, &CTX->watch_efd, watchfd_callback,
> +                                   xs_fileno(CTX->xsh), POLLIN);
> +        if (rc) goto out_rc;
> +    }
> +
> +    if (LIBXL_SLIST_EMPTY(&CTX->watch_freeslots)) {
> +        /* Free list is empty so there is not in fact a linked
> +         * free list in the array and we can safely realloc it */
> +        int newarraysize = (CTX->watch_nslots + 1) << 2;
> +        int i;
> +        libxl__ev_watch_slot *newarray =
> +            realloc(CTX->watch_slots, sizeof(*newarray) * newarraysize);
> +        if (!newarray) goto out_nomem;
> +        for (i=CTX->watch_nslots; i<newarraysize; i++)
> +            LIBXL_SLIST_INSERT_HEAD(&CTX->watch_freeslots,
> +                                    &newarray[i], empty);
> +        CTX->watch_slots = newarray;
> +        CTX->watch_nslots = newarraysize;
> +    }
> +    use = LIBXL_SLIST_FIRST(&CTX->watch_freeslots);
> +    assert(use);
> +    LIBXL_SLIST_REMOVE_HEAD(&CTX->watch_freeslots, empty);

I presume this is removing "use" from the list. It seems odd to refer to
that element of the list as HEAD and FIRST interchangeably since it
doesn't make this obvious but I guess we got this API from elsewhere.

There's no get-and-return function which combines the two operations?

> +
> +    path_copy = strdup(path);
> +    if (!path_copy) goto out_nomem;
> +
> +    int slotnum = use - CTX->watch_slots;
> +    w->counterval = CTX->watch_counter++;
> +
> +    if (!xs_watch(CTX->xsh, path, watch_token(gc, slotnum, w->counterval))) {
> +        LIBXL__LOG_ERRNOVAL(CTX, LIBXL__LOG_ERROR, errno,
> +                            "create watch for path %s", path);
> +        rc = ERROR_FAIL;
> +        goto out_rc;
> +    }
> +
> +    w->slotnum = slotnum;
> +    w->path = path_copy;
> +    w->callback = func;
> +    /* we look a bit behind the curtain of LIBXL_SLIST, to explictly

explicitly

> +     * assign to the pointer that's the next link.  See the comment
> +     * by the definitionn of libxl__ev_watch_slot */

definition.

I think this behind the curtain stuff would be better encapsulated in a
macro up somewhere near the comment and libxl__ev_watch_slot.

> +    use->empty.sle_next = (void*)w;


> +
> +    CTX_UNLOCK;
> +    return 0;
> +
> + out_nomem:
> +    rc = ERROR_NOMEM;
> + out_rc:
> +    if (use)
> +        LIBXL_SLIST_INSERT_HEAD(&CTX->watch_freeslots, use, empty);
> +    if (path_copy)
> +        free(path_copy);
> +    CTX_UNLOCK;
> +    return rc;
> +}
> +
> +void libxl__ev_xswatch_deregister(libxl__gc *gc, libxl__ev_xswatch *w) {
> +    /* it is legal to deregister from within _callback */

and CTX_LOCK is recursive so this is ok.

> +    CTX_LOCK;
> +
> +    if (w->slotnum >= 0) {
> +        char *token = watch_token(gc, w->slotnum, w->counterval);
> +        if (!xs_unwatch(CTX->xsh, w->path, token))
> +            /* Oh well, we will just get watch events forever more
> +             * and ignore them.  But we should complain to the log. */
> +            LIBXL__LOG_ERRNOVAL(CTX, LIBXL__LOG_ERROR, errno,
> +                                "remove watch for path %s", w->path);

Is it possible to also unwatch an unexpected watch at the point it
fires, IOW to try again later? I havn'et looked at the potential failure
cases of xs_unwatch so perhaps once it has failed there is no point in
trying again.

> +
> +        libxl__ev_watch_slot *slot = &CTX->watch_slots[w->slotnum];
> +        LIBXL_SLIST_INSERT_HEAD(&CTX->watch_freeslots, slot, empty);
> +    }
> +
> +    free(w->path);
> +    w->path = NULL;
> +
> +    CTX_UNLOCK;
> +}
> +
> +/*
> + * osevent poll
> + */

This seems like a good place to stop for the day. I'll pickup the rest
tomorrow.

[...]


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 17:43:42 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 17: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.xensource.com>)
	id 1RYLWZ-0003ba-Us; Wed, 07 Dec 2011 17:43:19 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RYLWY-0003b6-E5
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 17:43:18 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-13.tower-174.messagelabs.com!1323279750!4650152!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19430 invoked from network); 7 Dec 2011 17:42:30 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-13.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 7 Dec 2011 17:42:30 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RYLVk-000FR4-BG; Wed, 07 Dec 2011 17:42:28 +0000
Date: Wed, 7 Dec 2011 17:42:28 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20111207174228.GH31448@ocelot.phlegethon.org>
References: <mailman.3467.1323191271.12970.xen-devel@lists.xensource.com>
	<78bcef1bbb35c6176c138c1a6089f034.squirrel@webmail.lagarcavilla.org>
	<20111207092737.GA24563@aepfle.de>
	<20111207125805.GG31448@ocelot.phlegethon.org>
	<a8e4c4283fb91e690e2b09a8640cd938.squirrel@webmail.lagarcavilla.org>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <a8e4c4283fb91e690e2b09a8640cd938.squirrel@webmail.lagarcavilla.org>
User-Agent: Mutt/1.4.2.1i
Cc: Olaf Hering <olaf@aepfle.de>, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 2 of 5] xenpaging: map gfn before nomination
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 08:23 -0800 on 07 Dec (1323246231), Andres Lagar-Cavilla wrote:
> > At 10:27 +0100 on 07 Dec (1323253657), Olaf Hering wrote:
> >> On Tue, Dec 06, Andres Lagar-Cavilla wrote:
> >>
> >> > Ouch! You're absolutely tying the user space pager with the underlying
> >> xen
> >> > paging code. Most of your patches change the tools and the hypervisor
> >> in
> >> > lockstep.
> >>
> >> Yes, pager and hypervisor are bound closely together.
> >>
> >> > Patch 4 in your series is one such case. Short-cutting the state
> >> machine:
> >> > great. But what is the gain for the hypervisor in *not* sending the
> >> > EVICT_FAIL event. It's a good thing. It keeps the same interface to
> >> > user-space. Xenpaging may not need it, but the Xen paging code does
> >> not
> >> > exist solely for xenpaging.
> >>
> >> What IS the need to send yet another request? It adds just overhead for
> >> no obvious need. Please show the code that will benefit from the extra
> >> EVICT_FAIL message.
> >
> > While in general it's good to keep backward compatibility, I don't think
> > this interface has ever had a stable, usable release (that didn't
> > involve the consumer at least carrying hypervisor patches of their own)
> > so I think it's OK to make fairly large changes in it.
> Would you agree that targeting 4.2 as a reasonable long-term interface is
> a. feasible? b. worthy?

Yes, and yes. 

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 17:43:42 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 17: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.xensource.com>)
	id 1RYLWZ-0003ba-Us; Wed, 07 Dec 2011 17:43:19 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RYLWY-0003b6-E5
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 17:43:18 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-13.tower-174.messagelabs.com!1323279750!4650152!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19430 invoked from network); 7 Dec 2011 17:42:30 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-13.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 7 Dec 2011 17:42:30 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RYLVk-000FR4-BG; Wed, 07 Dec 2011 17:42:28 +0000
Date: Wed, 7 Dec 2011 17:42:28 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20111207174228.GH31448@ocelot.phlegethon.org>
References: <mailman.3467.1323191271.12970.xen-devel@lists.xensource.com>
	<78bcef1bbb35c6176c138c1a6089f034.squirrel@webmail.lagarcavilla.org>
	<20111207092737.GA24563@aepfle.de>
	<20111207125805.GG31448@ocelot.phlegethon.org>
	<a8e4c4283fb91e690e2b09a8640cd938.squirrel@webmail.lagarcavilla.org>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <a8e4c4283fb91e690e2b09a8640cd938.squirrel@webmail.lagarcavilla.org>
User-Agent: Mutt/1.4.2.1i
Cc: Olaf Hering <olaf@aepfle.de>, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 2 of 5] xenpaging: map gfn before nomination
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 08:23 -0800 on 07 Dec (1323246231), Andres Lagar-Cavilla wrote:
> > At 10:27 +0100 on 07 Dec (1323253657), Olaf Hering wrote:
> >> On Tue, Dec 06, Andres Lagar-Cavilla wrote:
> >>
> >> > Ouch! You're absolutely tying the user space pager with the underlying
> >> xen
> >> > paging code. Most of your patches change the tools and the hypervisor
> >> in
> >> > lockstep.
> >>
> >> Yes, pager and hypervisor are bound closely together.
> >>
> >> > Patch 4 in your series is one such case. Short-cutting the state
> >> machine:
> >> > great. But what is the gain for the hypervisor in *not* sending the
> >> > EVICT_FAIL event. It's a good thing. It keeps the same interface to
> >> > user-space. Xenpaging may not need it, but the Xen paging code does
> >> not
> >> > exist solely for xenpaging.
> >>
> >> What IS the need to send yet another request? It adds just overhead for
> >> no obvious need. Please show the code that will benefit from the extra
> >> EVICT_FAIL message.
> >
> > While in general it's good to keep backward compatibility, I don't think
> > this interface has ever had a stable, usable release (that didn't
> > involve the consumer at least carrying hypervisor patches of their own)
> > so I think it's OK to make fairly large changes in it.
> Would you agree that targeting 4.2 as a reasonable long-term interface is
> a. feasible? b. worthy?

Yes, and yes. 

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 19:37:30 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 19:37:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYNIR-0005kA-0Y; Wed, 07 Dec 2011 19:36:51 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RYNIP-0005k5-IO
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 19:36:49 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1323286534!55794798!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjA3NQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26806 invoked from network); 7 Dec 2011 19:35:34 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Dec 2011 19:35:34 -0000
X-IronPort-AV: E=Sophos;i="4.71,315,1320624000"; 
   d="scan'208";a="9350416"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Dec 2011 19:36:06 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 7 Dec 2011 19:36:06 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RYNHh-000468-VY;
	Wed, 07 Dec 2011 19:36:06 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RYNHh-0005UB-V1;
	Wed, 07 Dec 2011 19:36:05 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10413-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 7 Dec 2011 19:36:05 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10413: regressions - trouble:
	broken/fail/pass
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10413 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10413/

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-i386-rhel6hvm-intel  3 host-install(3)              broken
 test-amd64-i386-win           8 guest-saverestore         fail REGR. vs. 10201
 test-i386-i386-win            8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-amd64-win          8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-amd64-xl-win       3 host-install(3)              broken
 test-i386-i386-xl-win         8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-i386-win-vcpus1   8 guest-saverestore fail in 10401 REGR. vs. 10201
 test-amd64-amd64-xl-win      8 guest-saverestore fail in 10401 REGR. vs. 10201
 test-amd64-i386-xl-win7-amd64  3 host-install(3)              broken  in 10409
 test-amd64-amd64-xl-sedf      3 host-install(3)              broken   in 10409
 test-amd64-i386-xl-win-vcpus1 8 guest-saverestore fail in 10409 REGR. vs. 10201

Tests which are failing intermittently (not blocking):
 test-amd64-i386-win-vcpus1    7 windows-install             fail pass in 10401
 test-amd64-i386-xl-win-vcpus1  7 windows-install            fail pass in 10409
 test-amd64-amd64-xl-sedf     11 guest-localmigrate fail in 10401 pass in 10413
 test-amd64-amd64-win          7 windows-install    fail in 10409 pass in 10413

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-win7-amd64  7 windows-install              fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install          fail never pass
 test-i386-i386-xl-winxpsp3    7 windows-install              fail   never pass
 test-amd64-i386-xend-winxpsp3  7 windows-install              fail  never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xl-win7-amd64  7 windows-install              fail  never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   never pass
 test-amd64-amd64-xl-sedf-pin 14 guest-localmigrate/x10   fail blocked in 10201
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2       fail in 10401 never pass

version targeted for testing:
 xen                  38eb74c01d9d
baseline version:
 xen                  62ff6a318c5d

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scanneel.ca>
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Andres Lagar-Cavilla <andres@lagarcavilla>
  Andrew Cooper <andrew.cooper3@citrix.com>
  Anthony PERARD <anthony.perard@citrix.com>
  Brendan Cully <brendan@cs.ubc.ca>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Haitao Shan <haitao.shan@intel.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@novell.com>
  Jan Beulich <jbeulich@suse.com>
  Jonathan Davies <jonathan.davies@citrix.com>
  juergen.gross@ts.fujitsu.com
  Keir Fraser <keir@xen.org>
  Liu, Jinsong <jinsong.liu@intel.com>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
  Philipp Hahn <hahn@univention.de>
  Shriram Rajagopalan <rshriram@cs.ubc.ca>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang2 <wei.wang2@amd.com>
  Xudong Hao <xudong.hao@intel.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               broken  
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      broken  
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 1493 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 19:37:30 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 19:37:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYNIR-0005kA-0Y; Wed, 07 Dec 2011 19:36:51 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RYNIP-0005k5-IO
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 19:36:49 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1323286534!55794798!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjA3NQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26806 invoked from network); 7 Dec 2011 19:35:34 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Dec 2011 19:35:34 -0000
X-IronPort-AV: E=Sophos;i="4.71,315,1320624000"; 
   d="scan'208";a="9350416"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Dec 2011 19:36:06 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 7 Dec 2011 19:36:06 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RYNHh-000468-VY;
	Wed, 07 Dec 2011 19:36:06 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RYNHh-0005UB-V1;
	Wed, 07 Dec 2011 19:36:05 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10413-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 7 Dec 2011 19:36:05 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10413: regressions - trouble:
	broken/fail/pass
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10413 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10413/

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-i386-rhel6hvm-intel  3 host-install(3)              broken
 test-amd64-i386-win           8 guest-saverestore         fail REGR. vs. 10201
 test-i386-i386-win            8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-amd64-win          8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-amd64-xl-win       3 host-install(3)              broken
 test-i386-i386-xl-win         8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-i386-win-vcpus1   8 guest-saverestore fail in 10401 REGR. vs. 10201
 test-amd64-amd64-xl-win      8 guest-saverestore fail in 10401 REGR. vs. 10201
 test-amd64-i386-xl-win7-amd64  3 host-install(3)              broken  in 10409
 test-amd64-amd64-xl-sedf      3 host-install(3)              broken   in 10409
 test-amd64-i386-xl-win-vcpus1 8 guest-saverestore fail in 10409 REGR. vs. 10201

Tests which are failing intermittently (not blocking):
 test-amd64-i386-win-vcpus1    7 windows-install             fail pass in 10401
 test-amd64-i386-xl-win-vcpus1  7 windows-install            fail pass in 10409
 test-amd64-amd64-xl-sedf     11 guest-localmigrate fail in 10401 pass in 10413
 test-amd64-amd64-win          7 windows-install    fail in 10409 pass in 10413

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-win7-amd64  7 windows-install              fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install          fail never pass
 test-i386-i386-xl-winxpsp3    7 windows-install              fail   never pass
 test-amd64-i386-xend-winxpsp3  7 windows-install              fail  never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xl-win7-amd64  7 windows-install              fail  never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   never pass
 test-amd64-amd64-xl-sedf-pin 14 guest-localmigrate/x10   fail blocked in 10201
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2       fail in 10401 never pass

version targeted for testing:
 xen                  38eb74c01d9d
baseline version:
 xen                  62ff6a318c5d

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scanneel.ca>
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Andres Lagar-Cavilla <andres@lagarcavilla>
  Andrew Cooper <andrew.cooper3@citrix.com>
  Anthony PERARD <anthony.perard@citrix.com>
  Brendan Cully <brendan@cs.ubc.ca>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Haitao Shan <haitao.shan@intel.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@novell.com>
  Jan Beulich <jbeulich@suse.com>
  Jonathan Davies <jonathan.davies@citrix.com>
  juergen.gross@ts.fujitsu.com
  Keir Fraser <keir@xen.org>
  Liu, Jinsong <jinsong.liu@intel.com>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
  Philipp Hahn <hahn@univention.de>
  Shriram Rajagopalan <rshriram@cs.ubc.ca>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang2 <wei.wang2@amd.com>
  Xudong Hao <xudong.hao@intel.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               broken  
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      broken  
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 1493 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 19:43:09 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 19:43:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYNNv-0005sk-Jm; Wed, 07 Dec 2011 19:42:31 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1RYNNu-0005sd-6L
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 19:42:30 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-13.tower-21.messagelabs.com!1323286901!5380577!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24015 invoked from network); 7 Dec 2011 19:41:42 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-13.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 7 Dec 2011 19:41:42 -0000
Received: from andromeda.dapyr.net (darnok@localhost [127.0.0.1])
	by andromeda.dapyr.net (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id
	pB7JfbG9012997
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Wed, 7 Dec 2011 14:41:37 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pB7JfYJl012991;
	Wed, 7 Dec 2011 14:41:35 -0500
Date: Wed, 7 Dec 2011 15:41:34 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Paul Durrant <Paul.Durrant@citrix.com>
Message-ID: <20111207194134.GA8812@andromeda.dapyr.net>
References: <4EDDF41E.8070200@oracle.com>
	<1323168999-4434-1-git-send-email-annie.li@oracle.com>
	<1323171726.23681.65.camel@zakaz.uk.xensource.com>
	<4EDEDF2E.3040204@oracle.com>
	<291EDFCB1E9E224A99088639C4762022B5988E542E@LONPMAILBOX01.citrite.net>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <291EDFCB1E9E224A99088639C4762022B5988E542E@LONPMAILBOX01.citrite.net>
User-Agent: Mutt/1.5.9i
Cc: "jeremy@goop.org" <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	"kurt.hackel@oracle.com" <kurt.hackel@oracle.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	ANNIE LI <annie.li@oracle.com>
Subject: Re: [Xen-devel] [PATCH 1/2] xen/granttable: Support sub-page grants
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> > 
> > gnttab_v1_ops = {
> >   ...
> > .access_subpage = NULL;
> > .access_ref_subpage = NULL;
> > .access_trans = NULL;
> > .access_ref_trans = NULL;
> > }

You don't really need that. If you just leave it empty, they are all set
to NULL.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 19:43:09 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 19:43:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYNNv-0005sk-Jm; Wed, 07 Dec 2011 19:42:31 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1RYNNu-0005sd-6L
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 19:42:30 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-13.tower-21.messagelabs.com!1323286901!5380577!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24015 invoked from network); 7 Dec 2011 19:41:42 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-13.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 7 Dec 2011 19:41:42 -0000
Received: from andromeda.dapyr.net (darnok@localhost [127.0.0.1])
	by andromeda.dapyr.net (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id
	pB7JfbG9012997
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Wed, 7 Dec 2011 14:41:37 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pB7JfYJl012991;
	Wed, 7 Dec 2011 14:41:35 -0500
Date: Wed, 7 Dec 2011 15:41:34 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Paul Durrant <Paul.Durrant@citrix.com>
Message-ID: <20111207194134.GA8812@andromeda.dapyr.net>
References: <4EDDF41E.8070200@oracle.com>
	<1323168999-4434-1-git-send-email-annie.li@oracle.com>
	<1323171726.23681.65.camel@zakaz.uk.xensource.com>
	<4EDEDF2E.3040204@oracle.com>
	<291EDFCB1E9E224A99088639C4762022B5988E542E@LONPMAILBOX01.citrite.net>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <291EDFCB1E9E224A99088639C4762022B5988E542E@LONPMAILBOX01.citrite.net>
User-Agent: Mutt/1.5.9i
Cc: "jeremy@goop.org" <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	"kurt.hackel@oracle.com" <kurt.hackel@oracle.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	ANNIE LI <annie.li@oracle.com>
Subject: Re: [Xen-devel] [PATCH 1/2] xen/granttable: Support sub-page grants
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> > 
> > gnttab_v1_ops = {
> >   ...
> > .access_subpage = NULL;
> > .access_ref_subpage = NULL;
> > .access_trans = NULL;
> > .access_ref_trans = NULL;
> > }

You don't really need that. If you just leave it empty, they are all set
to NULL.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 20:29:33 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 20:29:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYO6s-0006cm-5b; Wed, 07 Dec 2011 20:28:58 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RYO6r-0006cd-EM
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 20:28:57 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1323289689!6257311!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjA3NQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21212 invoked from network); 7 Dec 2011 20:28:09 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Dec 2011 20:28:09 -0000
X-IronPort-AV: E=Sophos;i="4.71,315,1320624000"; 
   d="scan'208";a="9350982"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Dec 2011 20:27:47 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 7 Dec 2011 20:27:47 +0000
Date: Wed, 7 Dec 2011 20:27:36 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Keir Fraser <keir.xen@gmail.com>
In-Reply-To: <CB053109.26BFC%keir.xen@gmail.com>
Message-ID: <alpine.DEB.2.00.1112071951530.3517@kaball-desktop>
References: <CB053109.26BFC%keir.xen@gmail.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Tim Deegan \(3P\)" <Tim.Deegan@citrix.com>, "Zhang,
	Xiantao" <xiantao.zhang@intel.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH RFC 04/25] Replace "/" operand with div64
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 7 Dec 2011, Keir Fraser wrote:
> On 07/12/2011 12:23, "Stefano Stabellini" <stefano.stabellini@eu.citrix.com>
> wrote:
> 
> > On Wed, 7 Dec 2011, Zhang, Xiantao wrote:
> >> Hi, Stefano 
> >> Great work from you guys!  One quick comment:  Just found the below logic's
> >> change maybe wrong and probably  break current things.
> >> Original logic is  A+B -(C%D), but it is changed to  (A+B-C)%D,  so if it is
> >> not an intended fix, it should be an issue.
> >> Thanks!
> >> Xiantao  
> > 
> > True! Thanks for spotting this!
> 
> For the avoidance of doubt: this patch 04/25 is wrongheaded, and I will nack
> it if it appears in the final patch series. You probably got this impression
> from me already. ;-)

Yes, I got it :)
I think that the right thing to do is removing this patch and
implementing __aeabi_ldivmod and __aeabi_uldivmod in assembly for ARM,
that would give gcc everything it needs to compile "/".
I have got a simple implementation based on __qdivrem and seems to work
OK.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 20:29:33 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 20:29:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYO6s-0006cm-5b; Wed, 07 Dec 2011 20:28:58 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RYO6r-0006cd-EM
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 20:28:57 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1323289689!6257311!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjA3NQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21212 invoked from network); 7 Dec 2011 20:28:09 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Dec 2011 20:28:09 -0000
X-IronPort-AV: E=Sophos;i="4.71,315,1320624000"; 
   d="scan'208";a="9350982"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Dec 2011 20:27:47 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 7 Dec 2011 20:27:47 +0000
Date: Wed, 7 Dec 2011 20:27:36 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Keir Fraser <keir.xen@gmail.com>
In-Reply-To: <CB053109.26BFC%keir.xen@gmail.com>
Message-ID: <alpine.DEB.2.00.1112071951530.3517@kaball-desktop>
References: <CB053109.26BFC%keir.xen@gmail.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Tim Deegan \(3P\)" <Tim.Deegan@citrix.com>, "Zhang,
	Xiantao" <xiantao.zhang@intel.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH RFC 04/25] Replace "/" operand with div64
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 7 Dec 2011, Keir Fraser wrote:
> On 07/12/2011 12:23, "Stefano Stabellini" <stefano.stabellini@eu.citrix.com>
> wrote:
> 
> > On Wed, 7 Dec 2011, Zhang, Xiantao wrote:
> >> Hi, Stefano 
> >> Great work from you guys!  One quick comment:  Just found the below logic's
> >> change maybe wrong and probably  break current things.
> >> Original logic is  A+B -(C%D), but it is changed to  (A+B-C)%D,  so if it is
> >> not an intended fix, it should be an issue.
> >> Thanks!
> >> Xiantao  
> > 
> > True! Thanks for spotting this!
> 
> For the avoidance of doubt: this patch 04/25 is wrongheaded, and I will nack
> it if it appears in the final patch series. You probably got this impression
> from me already. ;-)

Yes, I got it :)
I think that the right thing to do is removing this patch and
implementing __aeabi_ldivmod and __aeabi_uldivmod in assembly for ARM,
that would give gcc everything it needs to compile "/".
I have got a simple implementation based on __qdivrem and seems to work
OK.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 20:40:09 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 20:40:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYOH8-0006rw-9S; Wed, 07 Dec 2011 20:39:34 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.r.wilk@gmail.com>) id 1RYOH6-0006rr-VG
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 20:39:33 +0000
X-Env-Sender: konrad.r.wilk@gmail.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1323290325!4679795!1
X-Originating-IP: [209.85.161.43]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8153 invoked from network); 7 Dec 2011 20:38:45 -0000
Received: from mail-fx0-f43.google.com (HELO mail-fx0-f43.google.com)
	(209.85.161.43)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Dec 2011 20:38:45 -0000
Received: by fagn18 with SMTP id n18so738652fag.30
	for <xen-devel@lists.xensource.com>;
	Wed, 07 Dec 2011 12:38:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:reply-to:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=adkxxK2w/y+wRHfPqCJB44T5NJ26xXumpkWrR8Xu5Ug=;
	b=lvQEf1cFQS1y4w7AaMgI8UkJbcc99bisgSnjQzi/Yy4uQWcwONZQEz8vIK3fT35tDs
	2j8Mq1Z0zX7oSuYzwo9kXmRhmhUcYNAcuBB3bVn7SBQyQzNeYQpAFfUhSE0HMz7X/iM+
	6d9jypHSkEx+8rYQ27Q+ZzWOEUKvZewm1Ubz4=
MIME-Version: 1.0
Received: by 10.180.96.38 with SMTP id dp6mr140423wib.10.1323290325541; Wed,
	07 Dec 2011 12:38:45 -0800 (PST)
Received: by 10.180.78.8 with HTTP; Wed, 7 Dec 2011 12:38:45 -0800 (PST)
In-Reply-To: <CAEc3jaACffpr9D1Hq_012vHAGhPLEfvsZjh7YyJ=Q-3FdtHS0Q@mail.gmail.com>
References: <CAEc3jaBds7xmiKH8RMfmEHQumkEeZ3PopVfbZPs_B-Kz8-DsWw@mail.gmail.com>
	<4ED51291.1010308@hfp.de>
	<CAEc3jaAa7y8C2NNBn1=L3AhS0uuYFP6ze8o1cZ9yG2VYHx6qMA@mail.gmail.com>
	<4ED5215D.1010403@hfp.de>
	<20111129230212.GA23958@andromeda.dapyr.net>
	<CAEc3jaAO0JhtOt6phQHwtE_A+NF7uGHGZ8uJv3BirEYybfVceg@mail.gmail.com>
	<CAEc3jaACffpr9D1Hq_012vHAGhPLEfvsZjh7YyJ=Q-3FdtHS0Q@mail.gmail.com>
Date: Wed, 7 Dec 2011 15:38:45 -0500
X-Google-Sender-Auth: 74sArZJQfAcbl997QEhWwTAbHzw
Message-ID: <CAPbh3rtOQ1HTPReqYcpE3vzk+-na0MTLLHZD15=Fg4yxB+ypaA@mail.gmail.com>
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Roderick Colenbrander <thunderbird2k@gmail.com>
Cc: xen-devel@lists.xensource.com, Andreas Kinzler <ml-xen-devel@hfp.de>
Subject: Re: [Xen-devel] Questions about GPLPV stability tests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: konrad@darnok.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> It took about a week, but the systems went down again. Linux is down,
> but the hypervisor is still reachable on the serial console. Is there
> anything interesting to dump from there?
>
Just the interrupts information. I think that is Ctrl-A, Ctrl-A,
Ctrl-A, and then '*' to capture everything (I don't remember the right
one for just interrupts).

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 20:40:09 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 20:40:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYOH8-0006rw-9S; Wed, 07 Dec 2011 20:39:34 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.r.wilk@gmail.com>) id 1RYOH6-0006rr-VG
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 20:39:33 +0000
X-Env-Sender: konrad.r.wilk@gmail.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1323290325!4679795!1
X-Originating-IP: [209.85.161.43]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8153 invoked from network); 7 Dec 2011 20:38:45 -0000
Received: from mail-fx0-f43.google.com (HELO mail-fx0-f43.google.com)
	(209.85.161.43)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Dec 2011 20:38:45 -0000
Received: by fagn18 with SMTP id n18so738652fag.30
	for <xen-devel@lists.xensource.com>;
	Wed, 07 Dec 2011 12:38:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:reply-to:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=adkxxK2w/y+wRHfPqCJB44T5NJ26xXumpkWrR8Xu5Ug=;
	b=lvQEf1cFQS1y4w7AaMgI8UkJbcc99bisgSnjQzi/Yy4uQWcwONZQEz8vIK3fT35tDs
	2j8Mq1Z0zX7oSuYzwo9kXmRhmhUcYNAcuBB3bVn7SBQyQzNeYQpAFfUhSE0HMz7X/iM+
	6d9jypHSkEx+8rYQ27Q+ZzWOEUKvZewm1Ubz4=
MIME-Version: 1.0
Received: by 10.180.96.38 with SMTP id dp6mr140423wib.10.1323290325541; Wed,
	07 Dec 2011 12:38:45 -0800 (PST)
Received: by 10.180.78.8 with HTTP; Wed, 7 Dec 2011 12:38:45 -0800 (PST)
In-Reply-To: <CAEc3jaACffpr9D1Hq_012vHAGhPLEfvsZjh7YyJ=Q-3FdtHS0Q@mail.gmail.com>
References: <CAEc3jaBds7xmiKH8RMfmEHQumkEeZ3PopVfbZPs_B-Kz8-DsWw@mail.gmail.com>
	<4ED51291.1010308@hfp.de>
	<CAEc3jaAa7y8C2NNBn1=L3AhS0uuYFP6ze8o1cZ9yG2VYHx6qMA@mail.gmail.com>
	<4ED5215D.1010403@hfp.de>
	<20111129230212.GA23958@andromeda.dapyr.net>
	<CAEc3jaAO0JhtOt6phQHwtE_A+NF7uGHGZ8uJv3BirEYybfVceg@mail.gmail.com>
	<CAEc3jaACffpr9D1Hq_012vHAGhPLEfvsZjh7YyJ=Q-3FdtHS0Q@mail.gmail.com>
Date: Wed, 7 Dec 2011 15:38:45 -0500
X-Google-Sender-Auth: 74sArZJQfAcbl997QEhWwTAbHzw
Message-ID: <CAPbh3rtOQ1HTPReqYcpE3vzk+-na0MTLLHZD15=Fg4yxB+ypaA@mail.gmail.com>
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Roderick Colenbrander <thunderbird2k@gmail.com>
Cc: xen-devel@lists.xensource.com, Andreas Kinzler <ml-xen-devel@hfp.de>
Subject: Re: [Xen-devel] Questions about GPLPV stability tests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: konrad@darnok.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> It took about a week, but the systems went down again. Linux is down,
> but the hypervisor is still reachable on the serial console. Is there
> anything interesting to dump from there?
>
Just the interrupts information. I think that is Ctrl-A, Ctrl-A,
Ctrl-A, and then '*' to capture everything (I don't remember the right
one for just interrupts).

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 20:45:42 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 20:45:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYOMb-00070t-4o; Wed, 07 Dec 2011 20:45:13 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <thunderbird2k@gmail.com>) id 1RYOMZ-00070j-AU
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 20:45:11 +0000
X-Env-Sender: thunderbird2k@gmail.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1323290636!43981760!1
X-Originating-IP: [209.85.213.171]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9193 invoked from network); 7 Dec 2011 20:43:57 -0000
Received: from mail-yx0-f171.google.com (HELO mail-yx0-f171.google.com)
	(209.85.213.171)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Dec 2011 20:43:57 -0000
Received: by yenr9 with SMTP id r9so13101727yen.30
	for <xen-devel@lists.xensource.com>;
	Wed, 07 Dec 2011 12:44:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=LCX4bRHWJZA1e3dynHNXWIEzgwlDLG5wOJNEDCcBIzo=;
	b=deYYtuT+w+0rqQ4/qvSCVJkfr1xKqBd4ajTZpsF3OuhsYSkFUO3Ur0Zo6Y7LGXccns
	YsN4noD+Aptnq4AWkEzO+Ic9aD/v2y3irWU905RcUlKPaezx6T+MdBQl9LMR4s3EEr9g
	k3gjguhJGJ7koiBSP/5XFH7vHAPPAHnBh9vx0=
MIME-Version: 1.0
Received: by 10.236.155.170 with SMTP id j30mr93916yhk.56.1323290660051; Wed,
	07 Dec 2011 12:44:20 -0800 (PST)
Received: by 10.100.48.10 with HTTP; Wed, 7 Dec 2011 12:44:19 -0800 (PST)
In-Reply-To: <CAPbh3rtOQ1HTPReqYcpE3vzk+-na0MTLLHZD15=Fg4yxB+ypaA@mail.gmail.com>
References: <CAEc3jaBds7xmiKH8RMfmEHQumkEeZ3PopVfbZPs_B-Kz8-DsWw@mail.gmail.com>
	<4ED51291.1010308@hfp.de>
	<CAEc3jaAa7y8C2NNBn1=L3AhS0uuYFP6ze8o1cZ9yG2VYHx6qMA@mail.gmail.com>
	<4ED5215D.1010403@hfp.de>
	<20111129230212.GA23958@andromeda.dapyr.net>
	<CAEc3jaAO0JhtOt6phQHwtE_A+NF7uGHGZ8uJv3BirEYybfVceg@mail.gmail.com>
	<CAEc3jaACffpr9D1Hq_012vHAGhPLEfvsZjh7YyJ=Q-3FdtHS0Q@mail.gmail.com>
	<CAPbh3rtOQ1HTPReqYcpE3vzk+-na0MTLLHZD15=Fg4yxB+ypaA@mail.gmail.com>
Date: Wed, 7 Dec 2011 20:44:19 +0000
Message-ID: <CAEc3jaBdQKmVJToNZRf+25GtJXqGc274ieHf_yHKRJ+YOKWdgA@mail.gmail.com>
From: Roderick Colenbrander <thunderbird2k@gmail.com>
To: konrad@darnok.org
Cc: xen-devel@lists.xensource.com, Andreas Kinzler <ml-xen-devel@hfp.de>
Subject: Re: [Xen-devel] Questions about GPLPV stability tests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Dec 7, 2011 at 8:38 PM, Konrad Rzeszutek Wilk <konrad@darnok.org> wrote:
>> It took about a week, but the systems went down again. Linux is down,
>> but the hypervisor is still reachable on the serial console. Is there
>> anything interesting to dump from there?
>>
> Just the interrupts information. I think that is Ctrl-A, Ctrl-A,
> Ctrl-A, and then '*' to capture everything (I don't remember the right
> one for just interrupts).

Here's the interrupt information:
(XEN) [2011-12-06 19:13:37] [i: dump interrupt bindings]
(XEN) [2011-12-06 19:13:37] Guest interrupt information:
(XEN) [2011-12-06 19:13:37]    IRQ:   0
affinity:00000000,00000000,00000000,00000001 vec:f0 type=IO-APIC-edge
  status=00000000 mapped, unbound
(XEN) [2011-12-06 19:13:37]    IRQ:   1
affinity:00000000,00000000,00000000,00000001 vec:30 type=IO-APIC-edge
  status=00000014 in-flight=0 domain-list=0:  1(-S--),
(XEN) [2011-12-06 19:13:37]    IRQ:   2
affinity:ffffffff,ffffffff,ffffffff,ffffffff vec:e2 type=XT-PIC
  status=00000000 mapped, unbound
(XEN) [2011-12-06 19:13:37]    IRQ:   3
affinity:00000000,00000000,00000000,00000001 vec:38 type=IO-APIC-edge
  status=00000006 mapped, unbound
(XEN) [2011-12-06 19:13:37]    IRQ:   4
affinity:00000000,00000000,00000000,00000001 vec:40 type=IO-APIC-edge
  status=00000002 mapped, unbound
(XEN) [2011-12-06 19:13:37]    IRQ:   5
affinity:00000000,00000000,00000000,00000001 vec:f1 type=IO-APIC-edge
  status=00000000 mapped, unbound
(XEN) [2011-12-06 19:13:37]    IRQ:   6
affinity:00000000,00000000,00000000,00000001 vec:48 type=IO-APIC-edge
  status=00000002 mapped, unbound
(XEN) [2011-12-06 19:13:37]    IRQ:   7
affinity:00000000,00000000,00000000,00000001 vec:50 type=IO-APIC-edge
  status=00000002 mapped, unbound
(XEN) [2011-12-06 19:13:37]    IRQ:   8
affinity:00000000,00000000,00000000,00000001 vec:58 type=IO-APIC-edge
  status=00000010 in-flight=0 domain-list=0:  8(-S--),
(XEN) [2011-12-06 19:13:37]    IRQ:   9
affinity:00000000,00000000,00000000,00000001 vec:60 type=IO-APIC-level
  status=00000010 in-flight=0 domain-list=0:  9(-S--),
(XEN) [2011-12-06 19:13:37]    IRQ:  10
affinity:00000000,00000000,00000000,00000001 vec:68 type=IO-APIC-edge
  status=00000002 mapped, unbound
(XEN) [2011-12-06 19:13:37]    IRQ:  11
affinity:00000000,00000000,00000000,00000001 vec:70 type=IO-APIC-edge
  status=00000002 mapped, unbound
(XEN) [2011-12-06 19:13:37]    IRQ:  12
affinity:00000000,00000000,00000000,00000001 vec:78 type=IO-APIC-edge
  status=00000010 in-flight=0 domain-list=0: 12(-S--),
(XEN) [2011-12-06 19:13:37]    IRQ:  13
affinity:00000000,00000000,00000000,00000001 vec:88 type=IO-APIC-edge
  status=00000002 mapped, unbound
(XEN) [2011-12-06 19:13:37]    IRQ:  14
affinity:00000000,00000000,00000000,00000001 vec:90 type=IO-APIC-edge
  status=00000002 mapped, unbound
(XEN) [2011-12-06 19:13:37]    IRQ:  15
affinity:00000000,00000000,00000000,00000001 vec:98 type=IO-APIC-edge
  status=00000002 mapped, unbound
(XEN) [2011-12-06 19:13:37]    IRQ:  16
affinity:00000000,00000000,00000000,00000001 vec:c8 type=IO-APIC-level
  status=00000010 in-flight=0 domain-list=0: 16(-S--),1201: 16(--M-),
(XEN) [2011-12-06 19:13:37]    IRQ:  18
affinity:00000000,00000000,00000000,00000001 vec:51 type=IO-APIC-level
  status=00000010 in-flight=0 domain-list=0: 18(-S--),
(XEN) [2011-12-06 19:13:37]    IRQ:  19
affinity:00000000,00000000,00000000,00000001 vec:d0 type=IO-APIC-level
  status=00000010 in-flight=0 domain-list=0: 19(-S--),
(XEN) [2011-12-06 19:13:37]    IRQ:  21
affinity:00000000,00000000,00000000,00000001 vec:61 type=IO-APIC-level
  status=00000010 in-flight=0 domain-list=0: 21(-S--),
(XEN) [2011-12-06 19:13:37]    IRQ:  23
affinity:00000000,00000000,00000000,00000001 vec:59 type=IO-APIC-level
  status=00000010 in-flight=1 domain-list=0: 23(PS-M),
(XEN) [2011-12-06 19:13:37]    IRQ:  24
affinity:00000000,00000000,00000000,00000001 vec:28 type=DMA_MSI
  status=00000000 mapped, unbound
(XEN) [2011-12-06 19:13:38]    IRQ:  25
affinity:00000000,00000000,00000000,00000001 vec:a0 type=PCI-MSI
  status=00000002 mapped, unbound
(XEN) [2011-12-06 19:13:38]    IRQ:  26
affinity:00000000,00000000,00000000,00000001 vec:a8 type=PCI-MSI
  status=00000002 mapped, unbound
(XEN) [2011-12-06 19:13:38]    IRQ:  27
affinity:00000000,00000000,00000000,00000001 vec:b0 type=PCI-MSI
  status=00000002 mapped, unbound
(XEN) [2011-12-06 19:13:38]    IRQ:  28
affinity:00000000,00000000,00000000,00000001 vec:b8 type=PCI-MSI
  status=00000002 mapped, unbound
(XEN) [2011-12-06 19:13:38]    IRQ:  29
affinity:00000000,00000000,00000000,00000001 vec:c0 type=PCI-MSI
  status=00000002 mapped, unbound
(XEN) [2011-12-06 19:13:38]    IRQ:  30
affinity:00000000,00000000,00000000,00000001 vec:d8 type=PCI-MSI
  status=00000014 in-flight=0 domain-list=0:274(PS--),
(XEN) [2011-12-06 19:13:38]    IRQ:  31
affinity:00000000,00000000,00000000,00000001 vec:21 type=PCI-MSI
  status=00000010 in-flight=0 domain-list=0:273(PS--),
(XEN) [2011-12-06 19:13:38]    IRQ:  32
affinity:00000000,00000000,00000000,00000001 vec:29 type=PCI-MSI
  status=00000010 in-flight=0 domain-list=0:272(PS--),
(XEN) [2011-12-06 19:13:38]    IRQ:  33
affinity:00000000,00000000,00000000,00000001 vec:31 type=PCI-MSI
  status=00000010 in-flight=0 domain-list=0:271(PS--),
(XEN) [2011-12-06 19:13:38]    IRQ:  34
affinity:ffffffff,ffffffff,ffffffff,ffffffff vec:39 type=PCI-MSI
  status=00000002 mapped, unbound
(XEN) [2011-12-06 19:13:38]    IRQ:  35
affinity:ffffffff,ffffffff,ffffffff,ffffffff vec:41 type=PCI-MSI
  status=00000002 mapped, unbound
(XEN) [2011-12-06 19:13:38]    IRQ:  36
affinity:ffffffff,ffffffff,ffffffff,ffffffff vec:49 type=PCI-MSI
  status=00000002 mapped, unbound
(XEN) [2011-12-06 19:13:38]    IRQ:  37
affinity:00000000,00000000,00000000,00000010 vec:65 type=PCI-MSI
  status=00000010 in-flight=0 domain-list=1201: 55(--M-),
(XEN) [2011-12-06 19:13:38] IO-APIC interrupt information:
(XEN) [2011-12-06 19:13:38]     IRQ  0 Vec240:
(XEN) [2011-12-06 19:13:38]       Apic 0x00, Pin  2: vector=240,
delivery_mode=1, dest_mode=logical, delivery_status=0, polarity=0,
irr=0, trigger=edge, mask=0, dest_id:1
(XEN) [2011-12-06 19:13:38]     IRQ  1 Vec 48:
(XEN) [2011-12-06 19:13:38]       Apic 0x00, Pin  1: vector=48,
delivery_mode=1, dest_mode=logical, delivery_status=0, polarity=0,
irr=0, trigger=edge, mask=0, dest_id:1
(XEN) [2011-12-06 19:13:38]     IRQ  3 Vec 56:
(XEN) [2011-12-06 19:13:38]       Apic 0x00, Pin  3: vector=56,
delivery_mode=1, dest_mode=logical, delivery_status=0, polarity=0,
irr=0, trigger=edge, mask=0, dest_id:1
(XEN) [2011-12-06 19:13:38]     IRQ  4 Vec 64:
(XEN) [2011-12-06 19:13:38]       Apic 0x00, Pin  4: vector=64,
delivery_mode=1, dest_mode=logical, delivery_status=0, polarity=0,
irr=0, trigger=edge, mask=0, dest_id:1
(XEN) [2011-12-06 19:13:38]     IRQ  5 Vec241:
(XEN) [2011-12-06 19:13:38]       Apic 0x00, Pin  5: vector=241,
delivery_mode=1, dest_mode=logical, delivery_status=0, polarity=0,
irr=0, trigger=edge, mask=0, dest_id:1
(XEN) [2011-12-06 19:13:38]     IRQ  6 Vec 72:
(XEN) [2011-12-06 19:13:38]       Apic 0x00, Pin  6: vector=72,
delivery_mode=1, dest_mode=logical, delivery_status=0, polarity=0,
irr=0, trigger=edge, mask=0, dest_id:1
(XEN) [2011-12-06 19:13:38]     IRQ  7 Vec 80:
(XEN) [2011-12-06 19:13:38]       Apic 0x00, Pin  7: vector=80,
delivery_mode=1, dest_mode=logical, delivery_status=0, polarity=0,
irr=0, trigger=edge, mask=0, dest_id:1
(XEN) [2011-12-06 19:13:38]     IRQ  8 Vec 88:
(XEN) [2011-12-06 19:13:38]       Apic 0x00, Pin  8: vector=88,
delivery_mode=1, dest_mode=logical, delivery_status=0, polarity=0,
irr=0, trigger=edge, mask=0, dest_id:1
(XEN) [2011-12-06 19:13:38]     IRQ  9 Vec 96:
(XEN) [2011-12-06 19:13:38]       Apic 0x00, Pin  9: vector=96,
delivery_mode=1, dest_mode=logical, delivery_status=0, polarity=0,
irr=0, trigger=level, mask=0, dest_id:1
(XEN) [2011-12-06 19:13:38]     IRQ 10 Vec104:
(XEN) [2011-12-06 19:13:38]       Apic 0x00, Pin 10: vector=104,
delivery_mode=1, dest_mode=logical, delivery_status=0, polarity=0,
irr=0, trigger=edge, mask=0, dest_id:1
(XEN) [2011-12-06 19:13:38]     IRQ 11 Vec112:
(XEN) [2011-12-06 19:13:38]       Apic 0x00, Pin 11: vector=112,
delivery_mode=1, dest_mode=logical, delivery_status=0, polarity=0,
irr=0, trigger=edge, mask=0, dest_id:1
(XEN) [2011-12-06 19:13:38]     IRQ 12 Vec120:
(XEN) [2011-12-06 19:13:38]       Apic 0x00, Pin 12: vector=120,
delivery_mode=1, dest_mode=logical, delivery_status=0, polarity=0,
irr=0, trigger=edge, mask=0, dest_id:1
(XEN) [2011-12-06 19:13:38]     IRQ 13 Vec136:
(XEN) [2011-12-06 19:13:38]       Apic 0x00, Pin 13: vector=136,
delivery_mode=1, dest_mode=logical, delivery_status=0, polarity=0,
irr=0, trigger=edge, mask=0, dest_id:1
(XEN) [2011-12-06 19:13:38]     IRQ 14 Vec144:
(XEN) [2011-12-06 19:13:38]       Apic 0x00, Pin 14: vector=144,
delivery_mode=1, dest_mode=logical, delivery_status=0, polarity=0,
irr=0, trigger=edge, mask=0, dest_id:1
(XEN) [2011-12-06 19:13:38]     IRQ 15 Vec152:
(XEN) [2011-12-06 19:13:38]       Apic 0x00, Pin 15: vector=152,
delivery_mode=1, dest_mode=logical, delivery_status=0, polarity=0,
irr=0, trigger=edge, mask=0, dest_id:1
(XEN) [2011-12-06 19:13:38]     IRQ 16 Vec200:
(XEN) [2011-12-06 19:13:38]       Apic 0x00, Pin 16: vector=200,
delivery_mode=1, dest_mode=logical, delivery_status=0, polarity=1,
irr=0, trigger=level, mask=0, dest_id:1
(XEN) [2011-12-06 19:13:38]     IRQ 18 Vec 81:
(XEN) [2011-12-06 19:13:38]       Apic 0x00, Pin 18: vector=81,
delivery_mode=1, dest_mode=logical, delivery_status=0, polarity=1,
irr=0, trigger=level, mask=0, dest_id:1
(XEN) [2011-12-06 19:13:38]     IRQ 19 Vec208:
(XEN) [2011-12-06 19:13:38]       Apic 0x00, Pin 19: vector=208,
delivery_mode=1, dest_mode=logical, delivery_status=0, polarity=1,
irr=0, trigger=level, mask=0, dest_id:1
(XEN) [2011-12-06 19:13:38]     IRQ 21 Vec 97:
(XEN) [2011-12-06 19:13:38]       Apic 0x00, Pin 21: vector=97,
delivery_mode=1, dest_mode=logical, delivery_status=0, polarity=1,
irr=0, trigger=level, mask=0, dest_id:1
(XEN) [2011-12-06 19:13:38]     IRQ 23 Vec 89:
(XEN) [2011-12-06 19:13:38]       Apic 0x00, Pin 23: vector=89,
delivery_mode=1, dest_mode=logical, delivery_status=1, polarity=1,
irr=1, trigger=level, mask=0, dest_id:1

I noticed some potential interesting things. The system in question is
using PCI passthrough. On the serial console I remember seeing that
the PCI device got unmapped from DomU and got mapped again in Dom0.
The serial console log still had a lot of information about this DomU
which I guess was going down. I guess it wasn't fully down yet.

Thanks,
Roderick

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 20:45:42 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 20:45:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYOMb-00070t-4o; Wed, 07 Dec 2011 20:45:13 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <thunderbird2k@gmail.com>) id 1RYOMZ-00070j-AU
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 20:45:11 +0000
X-Env-Sender: thunderbird2k@gmail.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1323290636!43981760!1
X-Originating-IP: [209.85.213.171]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9193 invoked from network); 7 Dec 2011 20:43:57 -0000
Received: from mail-yx0-f171.google.com (HELO mail-yx0-f171.google.com)
	(209.85.213.171)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Dec 2011 20:43:57 -0000
Received: by yenr9 with SMTP id r9so13101727yen.30
	for <xen-devel@lists.xensource.com>;
	Wed, 07 Dec 2011 12:44:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=LCX4bRHWJZA1e3dynHNXWIEzgwlDLG5wOJNEDCcBIzo=;
	b=deYYtuT+w+0rqQ4/qvSCVJkfr1xKqBd4ajTZpsF3OuhsYSkFUO3Ur0Zo6Y7LGXccns
	YsN4noD+Aptnq4AWkEzO+Ic9aD/v2y3irWU905RcUlKPaezx6T+MdBQl9LMR4s3EEr9g
	k3gjguhJGJ7koiBSP/5XFH7vHAPPAHnBh9vx0=
MIME-Version: 1.0
Received: by 10.236.155.170 with SMTP id j30mr93916yhk.56.1323290660051; Wed,
	07 Dec 2011 12:44:20 -0800 (PST)
Received: by 10.100.48.10 with HTTP; Wed, 7 Dec 2011 12:44:19 -0800 (PST)
In-Reply-To: <CAPbh3rtOQ1HTPReqYcpE3vzk+-na0MTLLHZD15=Fg4yxB+ypaA@mail.gmail.com>
References: <CAEc3jaBds7xmiKH8RMfmEHQumkEeZ3PopVfbZPs_B-Kz8-DsWw@mail.gmail.com>
	<4ED51291.1010308@hfp.de>
	<CAEc3jaAa7y8C2NNBn1=L3AhS0uuYFP6ze8o1cZ9yG2VYHx6qMA@mail.gmail.com>
	<4ED5215D.1010403@hfp.de>
	<20111129230212.GA23958@andromeda.dapyr.net>
	<CAEc3jaAO0JhtOt6phQHwtE_A+NF7uGHGZ8uJv3BirEYybfVceg@mail.gmail.com>
	<CAEc3jaACffpr9D1Hq_012vHAGhPLEfvsZjh7YyJ=Q-3FdtHS0Q@mail.gmail.com>
	<CAPbh3rtOQ1HTPReqYcpE3vzk+-na0MTLLHZD15=Fg4yxB+ypaA@mail.gmail.com>
Date: Wed, 7 Dec 2011 20:44:19 +0000
Message-ID: <CAEc3jaBdQKmVJToNZRf+25GtJXqGc274ieHf_yHKRJ+YOKWdgA@mail.gmail.com>
From: Roderick Colenbrander <thunderbird2k@gmail.com>
To: konrad@darnok.org
Cc: xen-devel@lists.xensource.com, Andreas Kinzler <ml-xen-devel@hfp.de>
Subject: Re: [Xen-devel] Questions about GPLPV stability tests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Dec 7, 2011 at 8:38 PM, Konrad Rzeszutek Wilk <konrad@darnok.org> wrote:
>> It took about a week, but the systems went down again. Linux is down,
>> but the hypervisor is still reachable on the serial console. Is there
>> anything interesting to dump from there?
>>
> Just the interrupts information. I think that is Ctrl-A, Ctrl-A,
> Ctrl-A, and then '*' to capture everything (I don't remember the right
> one for just interrupts).

Here's the interrupt information:
(XEN) [2011-12-06 19:13:37] [i: dump interrupt bindings]
(XEN) [2011-12-06 19:13:37] Guest interrupt information:
(XEN) [2011-12-06 19:13:37]    IRQ:   0
affinity:00000000,00000000,00000000,00000001 vec:f0 type=IO-APIC-edge
  status=00000000 mapped, unbound
(XEN) [2011-12-06 19:13:37]    IRQ:   1
affinity:00000000,00000000,00000000,00000001 vec:30 type=IO-APIC-edge
  status=00000014 in-flight=0 domain-list=0:  1(-S--),
(XEN) [2011-12-06 19:13:37]    IRQ:   2
affinity:ffffffff,ffffffff,ffffffff,ffffffff vec:e2 type=XT-PIC
  status=00000000 mapped, unbound
(XEN) [2011-12-06 19:13:37]    IRQ:   3
affinity:00000000,00000000,00000000,00000001 vec:38 type=IO-APIC-edge
  status=00000006 mapped, unbound
(XEN) [2011-12-06 19:13:37]    IRQ:   4
affinity:00000000,00000000,00000000,00000001 vec:40 type=IO-APIC-edge
  status=00000002 mapped, unbound
(XEN) [2011-12-06 19:13:37]    IRQ:   5
affinity:00000000,00000000,00000000,00000001 vec:f1 type=IO-APIC-edge
  status=00000000 mapped, unbound
(XEN) [2011-12-06 19:13:37]    IRQ:   6
affinity:00000000,00000000,00000000,00000001 vec:48 type=IO-APIC-edge
  status=00000002 mapped, unbound
(XEN) [2011-12-06 19:13:37]    IRQ:   7
affinity:00000000,00000000,00000000,00000001 vec:50 type=IO-APIC-edge
  status=00000002 mapped, unbound
(XEN) [2011-12-06 19:13:37]    IRQ:   8
affinity:00000000,00000000,00000000,00000001 vec:58 type=IO-APIC-edge
  status=00000010 in-flight=0 domain-list=0:  8(-S--),
(XEN) [2011-12-06 19:13:37]    IRQ:   9
affinity:00000000,00000000,00000000,00000001 vec:60 type=IO-APIC-level
  status=00000010 in-flight=0 domain-list=0:  9(-S--),
(XEN) [2011-12-06 19:13:37]    IRQ:  10
affinity:00000000,00000000,00000000,00000001 vec:68 type=IO-APIC-edge
  status=00000002 mapped, unbound
(XEN) [2011-12-06 19:13:37]    IRQ:  11
affinity:00000000,00000000,00000000,00000001 vec:70 type=IO-APIC-edge
  status=00000002 mapped, unbound
(XEN) [2011-12-06 19:13:37]    IRQ:  12
affinity:00000000,00000000,00000000,00000001 vec:78 type=IO-APIC-edge
  status=00000010 in-flight=0 domain-list=0: 12(-S--),
(XEN) [2011-12-06 19:13:37]    IRQ:  13
affinity:00000000,00000000,00000000,00000001 vec:88 type=IO-APIC-edge
  status=00000002 mapped, unbound
(XEN) [2011-12-06 19:13:37]    IRQ:  14
affinity:00000000,00000000,00000000,00000001 vec:90 type=IO-APIC-edge
  status=00000002 mapped, unbound
(XEN) [2011-12-06 19:13:37]    IRQ:  15
affinity:00000000,00000000,00000000,00000001 vec:98 type=IO-APIC-edge
  status=00000002 mapped, unbound
(XEN) [2011-12-06 19:13:37]    IRQ:  16
affinity:00000000,00000000,00000000,00000001 vec:c8 type=IO-APIC-level
  status=00000010 in-flight=0 domain-list=0: 16(-S--),1201: 16(--M-),
(XEN) [2011-12-06 19:13:37]    IRQ:  18
affinity:00000000,00000000,00000000,00000001 vec:51 type=IO-APIC-level
  status=00000010 in-flight=0 domain-list=0: 18(-S--),
(XEN) [2011-12-06 19:13:37]    IRQ:  19
affinity:00000000,00000000,00000000,00000001 vec:d0 type=IO-APIC-level
  status=00000010 in-flight=0 domain-list=0: 19(-S--),
(XEN) [2011-12-06 19:13:37]    IRQ:  21
affinity:00000000,00000000,00000000,00000001 vec:61 type=IO-APIC-level
  status=00000010 in-flight=0 domain-list=0: 21(-S--),
(XEN) [2011-12-06 19:13:37]    IRQ:  23
affinity:00000000,00000000,00000000,00000001 vec:59 type=IO-APIC-level
  status=00000010 in-flight=1 domain-list=0: 23(PS-M),
(XEN) [2011-12-06 19:13:37]    IRQ:  24
affinity:00000000,00000000,00000000,00000001 vec:28 type=DMA_MSI
  status=00000000 mapped, unbound
(XEN) [2011-12-06 19:13:38]    IRQ:  25
affinity:00000000,00000000,00000000,00000001 vec:a0 type=PCI-MSI
  status=00000002 mapped, unbound
(XEN) [2011-12-06 19:13:38]    IRQ:  26
affinity:00000000,00000000,00000000,00000001 vec:a8 type=PCI-MSI
  status=00000002 mapped, unbound
(XEN) [2011-12-06 19:13:38]    IRQ:  27
affinity:00000000,00000000,00000000,00000001 vec:b0 type=PCI-MSI
  status=00000002 mapped, unbound
(XEN) [2011-12-06 19:13:38]    IRQ:  28
affinity:00000000,00000000,00000000,00000001 vec:b8 type=PCI-MSI
  status=00000002 mapped, unbound
(XEN) [2011-12-06 19:13:38]    IRQ:  29
affinity:00000000,00000000,00000000,00000001 vec:c0 type=PCI-MSI
  status=00000002 mapped, unbound
(XEN) [2011-12-06 19:13:38]    IRQ:  30
affinity:00000000,00000000,00000000,00000001 vec:d8 type=PCI-MSI
  status=00000014 in-flight=0 domain-list=0:274(PS--),
(XEN) [2011-12-06 19:13:38]    IRQ:  31
affinity:00000000,00000000,00000000,00000001 vec:21 type=PCI-MSI
  status=00000010 in-flight=0 domain-list=0:273(PS--),
(XEN) [2011-12-06 19:13:38]    IRQ:  32
affinity:00000000,00000000,00000000,00000001 vec:29 type=PCI-MSI
  status=00000010 in-flight=0 domain-list=0:272(PS--),
(XEN) [2011-12-06 19:13:38]    IRQ:  33
affinity:00000000,00000000,00000000,00000001 vec:31 type=PCI-MSI
  status=00000010 in-flight=0 domain-list=0:271(PS--),
(XEN) [2011-12-06 19:13:38]    IRQ:  34
affinity:ffffffff,ffffffff,ffffffff,ffffffff vec:39 type=PCI-MSI
  status=00000002 mapped, unbound
(XEN) [2011-12-06 19:13:38]    IRQ:  35
affinity:ffffffff,ffffffff,ffffffff,ffffffff vec:41 type=PCI-MSI
  status=00000002 mapped, unbound
(XEN) [2011-12-06 19:13:38]    IRQ:  36
affinity:ffffffff,ffffffff,ffffffff,ffffffff vec:49 type=PCI-MSI
  status=00000002 mapped, unbound
(XEN) [2011-12-06 19:13:38]    IRQ:  37
affinity:00000000,00000000,00000000,00000010 vec:65 type=PCI-MSI
  status=00000010 in-flight=0 domain-list=1201: 55(--M-),
(XEN) [2011-12-06 19:13:38] IO-APIC interrupt information:
(XEN) [2011-12-06 19:13:38]     IRQ  0 Vec240:
(XEN) [2011-12-06 19:13:38]       Apic 0x00, Pin  2: vector=240,
delivery_mode=1, dest_mode=logical, delivery_status=0, polarity=0,
irr=0, trigger=edge, mask=0, dest_id:1
(XEN) [2011-12-06 19:13:38]     IRQ  1 Vec 48:
(XEN) [2011-12-06 19:13:38]       Apic 0x00, Pin  1: vector=48,
delivery_mode=1, dest_mode=logical, delivery_status=0, polarity=0,
irr=0, trigger=edge, mask=0, dest_id:1
(XEN) [2011-12-06 19:13:38]     IRQ  3 Vec 56:
(XEN) [2011-12-06 19:13:38]       Apic 0x00, Pin  3: vector=56,
delivery_mode=1, dest_mode=logical, delivery_status=0, polarity=0,
irr=0, trigger=edge, mask=0, dest_id:1
(XEN) [2011-12-06 19:13:38]     IRQ  4 Vec 64:
(XEN) [2011-12-06 19:13:38]       Apic 0x00, Pin  4: vector=64,
delivery_mode=1, dest_mode=logical, delivery_status=0, polarity=0,
irr=0, trigger=edge, mask=0, dest_id:1
(XEN) [2011-12-06 19:13:38]     IRQ  5 Vec241:
(XEN) [2011-12-06 19:13:38]       Apic 0x00, Pin  5: vector=241,
delivery_mode=1, dest_mode=logical, delivery_status=0, polarity=0,
irr=0, trigger=edge, mask=0, dest_id:1
(XEN) [2011-12-06 19:13:38]     IRQ  6 Vec 72:
(XEN) [2011-12-06 19:13:38]       Apic 0x00, Pin  6: vector=72,
delivery_mode=1, dest_mode=logical, delivery_status=0, polarity=0,
irr=0, trigger=edge, mask=0, dest_id:1
(XEN) [2011-12-06 19:13:38]     IRQ  7 Vec 80:
(XEN) [2011-12-06 19:13:38]       Apic 0x00, Pin  7: vector=80,
delivery_mode=1, dest_mode=logical, delivery_status=0, polarity=0,
irr=0, trigger=edge, mask=0, dest_id:1
(XEN) [2011-12-06 19:13:38]     IRQ  8 Vec 88:
(XEN) [2011-12-06 19:13:38]       Apic 0x00, Pin  8: vector=88,
delivery_mode=1, dest_mode=logical, delivery_status=0, polarity=0,
irr=0, trigger=edge, mask=0, dest_id:1
(XEN) [2011-12-06 19:13:38]     IRQ  9 Vec 96:
(XEN) [2011-12-06 19:13:38]       Apic 0x00, Pin  9: vector=96,
delivery_mode=1, dest_mode=logical, delivery_status=0, polarity=0,
irr=0, trigger=level, mask=0, dest_id:1
(XEN) [2011-12-06 19:13:38]     IRQ 10 Vec104:
(XEN) [2011-12-06 19:13:38]       Apic 0x00, Pin 10: vector=104,
delivery_mode=1, dest_mode=logical, delivery_status=0, polarity=0,
irr=0, trigger=edge, mask=0, dest_id:1
(XEN) [2011-12-06 19:13:38]     IRQ 11 Vec112:
(XEN) [2011-12-06 19:13:38]       Apic 0x00, Pin 11: vector=112,
delivery_mode=1, dest_mode=logical, delivery_status=0, polarity=0,
irr=0, trigger=edge, mask=0, dest_id:1
(XEN) [2011-12-06 19:13:38]     IRQ 12 Vec120:
(XEN) [2011-12-06 19:13:38]       Apic 0x00, Pin 12: vector=120,
delivery_mode=1, dest_mode=logical, delivery_status=0, polarity=0,
irr=0, trigger=edge, mask=0, dest_id:1
(XEN) [2011-12-06 19:13:38]     IRQ 13 Vec136:
(XEN) [2011-12-06 19:13:38]       Apic 0x00, Pin 13: vector=136,
delivery_mode=1, dest_mode=logical, delivery_status=0, polarity=0,
irr=0, trigger=edge, mask=0, dest_id:1
(XEN) [2011-12-06 19:13:38]     IRQ 14 Vec144:
(XEN) [2011-12-06 19:13:38]       Apic 0x00, Pin 14: vector=144,
delivery_mode=1, dest_mode=logical, delivery_status=0, polarity=0,
irr=0, trigger=edge, mask=0, dest_id:1
(XEN) [2011-12-06 19:13:38]     IRQ 15 Vec152:
(XEN) [2011-12-06 19:13:38]       Apic 0x00, Pin 15: vector=152,
delivery_mode=1, dest_mode=logical, delivery_status=0, polarity=0,
irr=0, trigger=edge, mask=0, dest_id:1
(XEN) [2011-12-06 19:13:38]     IRQ 16 Vec200:
(XEN) [2011-12-06 19:13:38]       Apic 0x00, Pin 16: vector=200,
delivery_mode=1, dest_mode=logical, delivery_status=0, polarity=1,
irr=0, trigger=level, mask=0, dest_id:1
(XEN) [2011-12-06 19:13:38]     IRQ 18 Vec 81:
(XEN) [2011-12-06 19:13:38]       Apic 0x00, Pin 18: vector=81,
delivery_mode=1, dest_mode=logical, delivery_status=0, polarity=1,
irr=0, trigger=level, mask=0, dest_id:1
(XEN) [2011-12-06 19:13:38]     IRQ 19 Vec208:
(XEN) [2011-12-06 19:13:38]       Apic 0x00, Pin 19: vector=208,
delivery_mode=1, dest_mode=logical, delivery_status=0, polarity=1,
irr=0, trigger=level, mask=0, dest_id:1
(XEN) [2011-12-06 19:13:38]     IRQ 21 Vec 97:
(XEN) [2011-12-06 19:13:38]       Apic 0x00, Pin 21: vector=97,
delivery_mode=1, dest_mode=logical, delivery_status=0, polarity=1,
irr=0, trigger=level, mask=0, dest_id:1
(XEN) [2011-12-06 19:13:38]     IRQ 23 Vec 89:
(XEN) [2011-12-06 19:13:38]       Apic 0x00, Pin 23: vector=89,
delivery_mode=1, dest_mode=logical, delivery_status=1, polarity=1,
irr=1, trigger=level, mask=0, dest_id:1

I noticed some potential interesting things. The system in question is
using PCI passthrough. On the serial console I remember seeing that
the PCI device got unmapped from DomU and got mapped again in Dom0.
The serial console log still had a lot of information about this DomU
which I guess was going down. I guess it wasn't fully down yet.

Thanks,
Roderick

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 21:14:39 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 21:14:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYOod-0007Xs-St; Wed, 07 Dec 2011 21:14:11 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <bastian@waldi.eu.org>) id 1RYOod-0007Xh-2Y
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 21:14:11 +0000
X-Env-Sender: bastian@waldi.eu.org
X-Msg-Ref: server-10.tower-27.messagelabs.com!1323292370!46987735!1
X-Originating-IP: [82.139.201.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26036 invoked from network); 7 Dec 2011 21:12:50 -0000
Received: from wavehammer.waldi.eu.org (HELO wavehammer.waldi.eu.org)
	(82.139.201.20)
	by server-10.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 7 Dec 2011 21:12:50 -0000
Received: by wavehammer.waldi.eu.org (Postfix, from userid 1000)
	id CF7035403A; Wed,  7 Dec 2011 22:13:25 +0100 (CET)
From: Bastian Blank <waldi@debian.org>
To: xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org
Date: Wed,  7 Dec 2011 22:13:13 +0100
Message-Id: <1323292396-19523-2-git-send-email-waldi@debian.org>
X-Mailer: git-send-email 1.7.7.3
In-Reply-To: <1323292396-19523-1-git-send-email-waldi@debian.org>
References: <1323292396-19523-1-git-send-email-waldi@debian.org>
Cc: konrad.wilk@oracle.com
Subject: [Xen-devel] [PATCH 1/4] xen: Add privcmd device driver
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Access to arbitrary hypercalls is currently provided via xenfs. This
adds a standard character device to handle this. The support in xenfs
remains for backward compatibility and uses the device driver code.

Signed-off-by: Bastian Blank <waldi@debian.org>
---
 drivers/xen/Kconfig               |    7 ++++++
 drivers/xen/Makefile              |    2 +
 drivers/xen/{xenfs => }/privcmd.c |   39 ++++++++++++++++++++++++++++++++++++-
 drivers/xen/privcmd.h             |    3 ++
 drivers/xen/xenfs/Makefile        |    2 +-
 drivers/xen/xenfs/super.c         |    3 +-
 drivers/xen/xenfs/xenfs.h         |    1 -
 7 files changed, 53 insertions(+), 4 deletions(-)
 rename drivers/xen/{xenfs => }/privcmd.c (92%)
 create mode 100644 drivers/xen/privcmd.h

diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
index 8795480..a1ced52 100644
--- a/drivers/xen/Kconfig
+++ b/drivers/xen/Kconfig
@@ -86,6 +86,7 @@ config XEN_BACKEND
 
 config XENFS
 	tristate "Xen filesystem"
+	select XEN_PRIVCMD
 	default y
 	help
 	  The xen filesystem provides a way for domains to share
@@ -171,4 +172,10 @@ config XEN_PCIDEV_BACKEND
 	  xen-pciback.hide=(03:00.0)(04:00.0)
 
 	  If in doubt, say m.
+
+config XEN_PRIVCMD
+	tristate
+	depends on XEN
+	default m
+
 endmenu
diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
index 974fffd..aa31337 100644
--- a/drivers/xen/Makefile
+++ b/drivers/xen/Makefile
@@ -19,7 +19,9 @@ obj-$(CONFIG_XEN_TMEM)			+= tmem.o
 obj-$(CONFIG_SWIOTLB_XEN)		+= swiotlb-xen.o
 obj-$(CONFIG_XEN_DOM0)			+= pci.o
 obj-$(CONFIG_XEN_PCIDEV_BACKEND)	+= xen-pciback/
+obj-$(CONFIG_XEN_PRIVCMD)		+= xen-privcmd.o
 
 xen-evtchn-y				:= evtchn.o
 xen-gntdev-y				:= gntdev.o
 xen-gntalloc-y				:= gntalloc.o
+xen-privcmd-y				:= privcmd.o
diff --git a/drivers/xen/xenfs/privcmd.c b/drivers/xen/privcmd.c
similarity index 92%
rename from drivers/xen/xenfs/privcmd.c
rename to drivers/xen/privcmd.c
index dbd3b16..863fbd0 100644
--- a/drivers/xen/xenfs/privcmd.c
+++ b/drivers/xen/privcmd.c
@@ -7,6 +7,7 @@
  */
 
 #include <linux/kernel.h>
+#include <linux/module.h>
 #include <linux/sched.h>
 #include <linux/slab.h>
 #include <linux/string.h>
@@ -18,6 +19,7 @@
 #include <linux/highmem.h>
 #include <linux/pagemap.h>
 #include <linux/seq_file.h>
+#include <linux/miscdevice.h>
 
 #include <asm/pgalloc.h>
 #include <asm/pgtable.h>
@@ -32,6 +34,10 @@
 #include <xen/page.h>
 #include <xen/xen-ops.h>
 
+#include "privcmd.h"
+
+MODULE_LICENSE("GPL");
+
 #ifndef HAVE_ARCH_PRIVCMD_MMAP
 static int privcmd_enforce_singleshot_mapping(struct vm_area_struct *vma);
 #endif
@@ -394,7 +400,38 @@ static int privcmd_enforce_singleshot_mapping(struct vm_area_struct *vma)
 }
 #endif
 
-const struct file_operations privcmd_file_ops = {
+const struct file_operations xen_privcmd_fops = {
+	.owner = THIS_MODULE,
 	.unlocked_ioctl = privcmd_ioctl,
 	.mmap = privcmd_mmap,
 };
+EXPORT_SYMBOL_GPL(xen_privcmd_fops);
+
+static struct miscdevice privcmd_dev = {
+	.minor = MISC_DYNAMIC_MINOR,
+	.name = "xen/privcmd",
+	.fops = &xen_privcmd_fops,
+};
+
+static int __init privcmd_init(void)
+{
+	int err;
+
+	if (!xen_domain())
+		return -ENODEV;
+
+	err = misc_register(&privcmd_dev);
+	if (err != 0) {
+		printk(KERN_ERR "Could not register privcmd device\n");
+		return err;
+	}
+	return 0;
+}
+
+static void __exit privcmd_exit(void)
+{
+	misc_deregister(&privcmd_dev);
+}
+
+module_init(privcmd_init);
+module_exit(privcmd_exit);
diff --git a/drivers/xen/privcmd.h b/drivers/xen/privcmd.h
new file mode 100644
index 0000000..14facae
--- /dev/null
+++ b/drivers/xen/privcmd.h
@@ -0,0 +1,3 @@
+#include <linux/fs.h>
+
+extern const struct file_operations xen_privcmd_fops;
diff --git a/drivers/xen/xenfs/Makefile b/drivers/xen/xenfs/Makefile
index 4fde944..5d45ff1 100644
--- a/drivers/xen/xenfs/Makefile
+++ b/drivers/xen/xenfs/Makefile
@@ -1,4 +1,4 @@
 obj-$(CONFIG_XENFS) += xenfs.o
 
-xenfs-y			  = super.o xenbus.o privcmd.o
+xenfs-y			  = super.o xenbus.o
 xenfs-$(CONFIG_XEN_DOM0) += xenstored.o
diff --git a/drivers/xen/xenfs/super.c b/drivers/xen/xenfs/super.c
index 1aa3897..a55fbf9 100644
--- a/drivers/xen/xenfs/super.c
+++ b/drivers/xen/xenfs/super.c
@@ -16,6 +16,7 @@
 #include <xen/xen.h>
 
 #include "xenfs.h"
+#include "../privcmd.h"
 
 #include <asm/xen/hypervisor.h>
 
@@ -84,7 +85,7 @@ static int xenfs_fill_super(struct super_block *sb, void *data, int silent)
 		[1] = {},
 		{ "xenbus", &xenbus_file_ops, S_IRUSR|S_IWUSR },
 		{ "capabilities", &capabilities_file_ops, S_IRUGO },
-		{ "privcmd", &privcmd_file_ops, S_IRUSR|S_IWUSR },
+		{ "privcmd", &xen_privcmd_fops, S_IRUSR|S_IWUSR },
 		{""},
 	};
 	int rc;
diff --git a/drivers/xen/xenfs/xenfs.h b/drivers/xen/xenfs/xenfs.h
index b68aa62..5056306 100644
--- a/drivers/xen/xenfs/xenfs.h
+++ b/drivers/xen/xenfs/xenfs.h
@@ -2,7 +2,6 @@
 #define _XENFS_XENBUS_H
 
 extern const struct file_operations xenbus_file_ops;
-extern const struct file_operations privcmd_file_ops;
 extern const struct file_operations xsd_kva_file_ops;
 extern const struct file_operations xsd_port_file_ops;
 
-- 
1.7.7.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 21:14:39 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 21:14:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYOod-0007Xs-St; Wed, 07 Dec 2011 21:14:11 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <bastian@waldi.eu.org>) id 1RYOod-0007Xh-2Y
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 21:14:11 +0000
X-Env-Sender: bastian@waldi.eu.org
X-Msg-Ref: server-10.tower-27.messagelabs.com!1323292370!46987735!1
X-Originating-IP: [82.139.201.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26036 invoked from network); 7 Dec 2011 21:12:50 -0000
Received: from wavehammer.waldi.eu.org (HELO wavehammer.waldi.eu.org)
	(82.139.201.20)
	by server-10.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 7 Dec 2011 21:12:50 -0000
Received: by wavehammer.waldi.eu.org (Postfix, from userid 1000)
	id CF7035403A; Wed,  7 Dec 2011 22:13:25 +0100 (CET)
From: Bastian Blank <waldi@debian.org>
To: xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org
Date: Wed,  7 Dec 2011 22:13:13 +0100
Message-Id: <1323292396-19523-2-git-send-email-waldi@debian.org>
X-Mailer: git-send-email 1.7.7.3
In-Reply-To: <1323292396-19523-1-git-send-email-waldi@debian.org>
References: <1323292396-19523-1-git-send-email-waldi@debian.org>
Cc: konrad.wilk@oracle.com
Subject: [Xen-devel] [PATCH 1/4] xen: Add privcmd device driver
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Access to arbitrary hypercalls is currently provided via xenfs. This
adds a standard character device to handle this. The support in xenfs
remains for backward compatibility and uses the device driver code.

Signed-off-by: Bastian Blank <waldi@debian.org>
---
 drivers/xen/Kconfig               |    7 ++++++
 drivers/xen/Makefile              |    2 +
 drivers/xen/{xenfs => }/privcmd.c |   39 ++++++++++++++++++++++++++++++++++++-
 drivers/xen/privcmd.h             |    3 ++
 drivers/xen/xenfs/Makefile        |    2 +-
 drivers/xen/xenfs/super.c         |    3 +-
 drivers/xen/xenfs/xenfs.h         |    1 -
 7 files changed, 53 insertions(+), 4 deletions(-)
 rename drivers/xen/{xenfs => }/privcmd.c (92%)
 create mode 100644 drivers/xen/privcmd.h

diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
index 8795480..a1ced52 100644
--- a/drivers/xen/Kconfig
+++ b/drivers/xen/Kconfig
@@ -86,6 +86,7 @@ config XEN_BACKEND
 
 config XENFS
 	tristate "Xen filesystem"
+	select XEN_PRIVCMD
 	default y
 	help
 	  The xen filesystem provides a way for domains to share
@@ -171,4 +172,10 @@ config XEN_PCIDEV_BACKEND
 	  xen-pciback.hide=(03:00.0)(04:00.0)
 
 	  If in doubt, say m.
+
+config XEN_PRIVCMD
+	tristate
+	depends on XEN
+	default m
+
 endmenu
diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
index 974fffd..aa31337 100644
--- a/drivers/xen/Makefile
+++ b/drivers/xen/Makefile
@@ -19,7 +19,9 @@ obj-$(CONFIG_XEN_TMEM)			+= tmem.o
 obj-$(CONFIG_SWIOTLB_XEN)		+= swiotlb-xen.o
 obj-$(CONFIG_XEN_DOM0)			+= pci.o
 obj-$(CONFIG_XEN_PCIDEV_BACKEND)	+= xen-pciback/
+obj-$(CONFIG_XEN_PRIVCMD)		+= xen-privcmd.o
 
 xen-evtchn-y				:= evtchn.o
 xen-gntdev-y				:= gntdev.o
 xen-gntalloc-y				:= gntalloc.o
+xen-privcmd-y				:= privcmd.o
diff --git a/drivers/xen/xenfs/privcmd.c b/drivers/xen/privcmd.c
similarity index 92%
rename from drivers/xen/xenfs/privcmd.c
rename to drivers/xen/privcmd.c
index dbd3b16..863fbd0 100644
--- a/drivers/xen/xenfs/privcmd.c
+++ b/drivers/xen/privcmd.c
@@ -7,6 +7,7 @@
  */
 
 #include <linux/kernel.h>
+#include <linux/module.h>
 #include <linux/sched.h>
 #include <linux/slab.h>
 #include <linux/string.h>
@@ -18,6 +19,7 @@
 #include <linux/highmem.h>
 #include <linux/pagemap.h>
 #include <linux/seq_file.h>
+#include <linux/miscdevice.h>
 
 #include <asm/pgalloc.h>
 #include <asm/pgtable.h>
@@ -32,6 +34,10 @@
 #include <xen/page.h>
 #include <xen/xen-ops.h>
 
+#include "privcmd.h"
+
+MODULE_LICENSE("GPL");
+
 #ifndef HAVE_ARCH_PRIVCMD_MMAP
 static int privcmd_enforce_singleshot_mapping(struct vm_area_struct *vma);
 #endif
@@ -394,7 +400,38 @@ static int privcmd_enforce_singleshot_mapping(struct vm_area_struct *vma)
 }
 #endif
 
-const struct file_operations privcmd_file_ops = {
+const struct file_operations xen_privcmd_fops = {
+	.owner = THIS_MODULE,
 	.unlocked_ioctl = privcmd_ioctl,
 	.mmap = privcmd_mmap,
 };
+EXPORT_SYMBOL_GPL(xen_privcmd_fops);
+
+static struct miscdevice privcmd_dev = {
+	.minor = MISC_DYNAMIC_MINOR,
+	.name = "xen/privcmd",
+	.fops = &xen_privcmd_fops,
+};
+
+static int __init privcmd_init(void)
+{
+	int err;
+
+	if (!xen_domain())
+		return -ENODEV;
+
+	err = misc_register(&privcmd_dev);
+	if (err != 0) {
+		printk(KERN_ERR "Could not register privcmd device\n");
+		return err;
+	}
+	return 0;
+}
+
+static void __exit privcmd_exit(void)
+{
+	misc_deregister(&privcmd_dev);
+}
+
+module_init(privcmd_init);
+module_exit(privcmd_exit);
diff --git a/drivers/xen/privcmd.h b/drivers/xen/privcmd.h
new file mode 100644
index 0000000..14facae
--- /dev/null
+++ b/drivers/xen/privcmd.h
@@ -0,0 +1,3 @@
+#include <linux/fs.h>
+
+extern const struct file_operations xen_privcmd_fops;
diff --git a/drivers/xen/xenfs/Makefile b/drivers/xen/xenfs/Makefile
index 4fde944..5d45ff1 100644
--- a/drivers/xen/xenfs/Makefile
+++ b/drivers/xen/xenfs/Makefile
@@ -1,4 +1,4 @@
 obj-$(CONFIG_XENFS) += xenfs.o
 
-xenfs-y			  = super.o xenbus.o privcmd.o
+xenfs-y			  = super.o xenbus.o
 xenfs-$(CONFIG_XEN_DOM0) += xenstored.o
diff --git a/drivers/xen/xenfs/super.c b/drivers/xen/xenfs/super.c
index 1aa3897..a55fbf9 100644
--- a/drivers/xen/xenfs/super.c
+++ b/drivers/xen/xenfs/super.c
@@ -16,6 +16,7 @@
 #include <xen/xen.h>
 
 #include "xenfs.h"
+#include "../privcmd.h"
 
 #include <asm/xen/hypervisor.h>
 
@@ -84,7 +85,7 @@ static int xenfs_fill_super(struct super_block *sb, void *data, int silent)
 		[1] = {},
 		{ "xenbus", &xenbus_file_ops, S_IRUSR|S_IWUSR },
 		{ "capabilities", &capabilities_file_ops, S_IRUGO },
-		{ "privcmd", &privcmd_file_ops, S_IRUSR|S_IWUSR },
+		{ "privcmd", &xen_privcmd_fops, S_IRUSR|S_IWUSR },
 		{""},
 	};
 	int rc;
diff --git a/drivers/xen/xenfs/xenfs.h b/drivers/xen/xenfs/xenfs.h
index b68aa62..5056306 100644
--- a/drivers/xen/xenfs/xenfs.h
+++ b/drivers/xen/xenfs/xenfs.h
@@ -2,7 +2,6 @@
 #define _XENFS_XENBUS_H
 
 extern const struct file_operations xenbus_file_ops;
-extern const struct file_operations privcmd_file_ops;
 extern const struct file_operations xsd_kva_file_ops;
 extern const struct file_operations xsd_port_file_ops;
 
-- 
1.7.7.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 21:14:40 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 21:14:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYOol-0007Yh-3h; Wed, 07 Dec 2011 21:14:19 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <bastian@waldi.eu.org>) id 1RYOoj-0007Xr-4O
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 21:14:17 +0000
X-Env-Sender: bastian@waldi.eu.org
X-Msg-Ref: server-8.tower-21.messagelabs.com!1323292408!7324824!1
X-Originating-IP: [82.139.201.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10544 invoked from network); 7 Dec 2011 21:13:29 -0000
Received: from wavehammer.waldi.eu.org (HELO wavehammer.waldi.eu.org)
	(82.139.201.20)
	by server-8.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 7 Dec 2011 21:13:29 -0000
Received: by wavehammer.waldi.eu.org (Postfix, from userid 1000)
	id 1876B54229; Wed,  7 Dec 2011 22:13:25 +0100 (CET)
From: Bastian Blank <waldi@debian.org>
To: xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org
Date: Wed,  7 Dec 2011 22:13:14 +0100
Message-Id: <1323292396-19523-3-git-send-email-waldi@debian.org>
X-Mailer: git-send-email 1.7.7.3
In-Reply-To: <1323292396-19523-1-git-send-email-waldi@debian.org>
References: <1323292396-19523-1-git-send-email-waldi@debian.org>
Cc: konrad.wilk@oracle.com
Subject: [Xen-devel] [PATCH 2/4] xen: Add xenbus device driver
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Access to xenbus is currently handled via xenfs. This adds a device
driver for xenbus and makes xenfs use this code.

Signed-off-by: Bastian Blank <waldi@debian.org>
---
 drivers/xen/xenbus/Makefile                        |    1 +
 drivers/xen/xenbus/xenbus_comms.h                  |    4 ++
 .../xenbus.c => xenbus/xenbus_dev_frontend.c}      |   37 ++++++++++++++++++--
 drivers/xen/xenfs/Makefile                         |    2 +-
 drivers/xen/xenfs/super.c                          |    3 +-
 drivers/xen/xenfs/xenfs.h                          |    1 -
 6 files changed, 42 insertions(+), 6 deletions(-)
 rename drivers/xen/{xenfs/xenbus.c => xenbus/xenbus_dev_frontend.c} (95%)

diff --git a/drivers/xen/xenbus/Makefile b/drivers/xen/xenbus/Makefile
index 8dca685..a2ea363 100644
--- a/drivers/xen/xenbus/Makefile
+++ b/drivers/xen/xenbus/Makefile
@@ -1,4 +1,5 @@
 obj-y	+= xenbus.o
+obj-y	+= xenbus_dev_frontend.o
 
 xenbus-objs =
 xenbus-objs += xenbus_client.o
diff --git a/drivers/xen/xenbus/xenbus_comms.h b/drivers/xen/xenbus/xenbus_comms.h
index c21db75..6e42800 100644
--- a/drivers/xen/xenbus/xenbus_comms.h
+++ b/drivers/xen/xenbus/xenbus_comms.h
@@ -31,6 +31,8 @@
 #ifndef _XENBUS_COMMS_H
 #define _XENBUS_COMMS_H
 
+#include <linux/fs.h>
+
 int xs_init(void);
 int xb_init_comms(void);
 
@@ -43,4 +45,6 @@ int xs_input_avail(void);
 extern struct xenstore_domain_interface *xen_store_interface;
 extern int xen_store_evtchn;
 
+extern const struct file_operations xen_xenbus_fops;
+
 #endif /* _XENBUS_COMMS_H */
diff --git a/drivers/xen/xenfs/xenbus.c b/drivers/xen/xenbus/xenbus_dev_frontend.c
similarity index 95%
rename from drivers/xen/xenfs/xenbus.c
rename to drivers/xen/xenbus/xenbus_dev_frontend.c
index bbd000f..fb30cff 100644
--- a/drivers/xen/xenfs/xenbus.c
+++ b/drivers/xen/xenbus/xenbus_dev_frontend.c
@@ -52,13 +52,16 @@
 #include <linux/namei.h>
 #include <linux/string.h>
 #include <linux/slab.h>
+#include <linux/miscdevice.h>
+#include <linux/module.h>
 
-#include "xenfs.h"
-#include "../xenbus/xenbus_comms.h"
+#include "xenbus_comms.h"
 
 #include <xen/xenbus.h>
 #include <asm/xen/hypervisor.h>
 
+MODULE_LICENSE("GPL");
+
 /*
  * An element of a list of outstanding transactions, for which we're
  * still waiting a reply.
@@ -583,7 +586,7 @@ static unsigned int xenbus_file_poll(struct file *file, poll_table *wait)
 	return 0;
 }
 
-const struct file_operations xenbus_file_ops = {
+const struct file_operations xen_xenbus_fops = {
 	.read = xenbus_file_read,
 	.write = xenbus_file_write,
 	.open = xenbus_file_open,
@@ -591,3 +594,31 @@ const struct file_operations xenbus_file_ops = {
 	.poll = xenbus_file_poll,
 	.llseek = no_llseek,
 };
+EXPORT_SYMBOL_GPL(xen_xenbus_fops);
+
+static struct miscdevice xenbus_dev = {
+	.minor = MISC_DYNAMIC_MINOR,
+	.name = "xen/xenbus",
+	.fops = &xen_xenbus_fops,
+};
+
+static int __init xenbus_init(void)
+{
+	int err;
+
+	if (!xen_domain())
+		return -ENODEV;
+
+	err = misc_register(&xenbus_dev);
+	if (err)
+		printk(KERN_ERR "Could not register xenbus device\n");
+	return err;
+}
+
+static void __exit xenbus_exit(void)
+{
+	misc_deregister(&xenbus_dev);
+}
+
+module_init(xenbus_init);
+module_exit(xenbus_exit);
diff --git a/drivers/xen/xenfs/Makefile b/drivers/xen/xenfs/Makefile
index 5d45ff1..b019865 100644
--- a/drivers/xen/xenfs/Makefile
+++ b/drivers/xen/xenfs/Makefile
@@ -1,4 +1,4 @@
 obj-$(CONFIG_XENFS) += xenfs.o
 
-xenfs-y			  = super.o xenbus.o
+xenfs-y			  = super.o
 xenfs-$(CONFIG_XEN_DOM0) += xenstored.o
diff --git a/drivers/xen/xenfs/super.c b/drivers/xen/xenfs/super.c
index a55fbf9..a84b53c 100644
--- a/drivers/xen/xenfs/super.c
+++ b/drivers/xen/xenfs/super.c
@@ -17,6 +17,7 @@
 
 #include "xenfs.h"
 #include "../privcmd.h"
+#include "../xenbus/xenbus_comms.h"
 
 #include <asm/xen/hypervisor.h>
 
@@ -83,7 +84,7 @@ static int xenfs_fill_super(struct super_block *sb, void *data, int silent)
 {
 	static struct tree_descr xenfs_files[] = {
 		[1] = {},
-		{ "xenbus", &xenbus_file_ops, S_IRUSR|S_IWUSR },
+		{ "xenbus", &xen_xenbus_fops, S_IRUSR|S_IWUSR },
 		{ "capabilities", &capabilities_file_ops, S_IRUGO },
 		{ "privcmd", &xen_privcmd_fops, S_IRUSR|S_IWUSR },
 		{""},
diff --git a/drivers/xen/xenfs/xenfs.h b/drivers/xen/xenfs/xenfs.h
index 5056306..6b80c77 100644
--- a/drivers/xen/xenfs/xenfs.h
+++ b/drivers/xen/xenfs/xenfs.h
@@ -1,7 +1,6 @@
 #ifndef _XENFS_XENBUS_H
 #define _XENFS_XENBUS_H
 
-extern const struct file_operations xenbus_file_ops;
 extern const struct file_operations xsd_kva_file_ops;
 extern const struct file_operations xsd_port_file_ops;
 
-- 
1.7.7.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 21:14:40 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 21:14:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYOol-0007Yh-3h; Wed, 07 Dec 2011 21:14:19 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <bastian@waldi.eu.org>) id 1RYOoj-0007Xr-4O
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 21:14:17 +0000
X-Env-Sender: bastian@waldi.eu.org
X-Msg-Ref: server-8.tower-21.messagelabs.com!1323292408!7324824!1
X-Originating-IP: [82.139.201.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10544 invoked from network); 7 Dec 2011 21:13:29 -0000
Received: from wavehammer.waldi.eu.org (HELO wavehammer.waldi.eu.org)
	(82.139.201.20)
	by server-8.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 7 Dec 2011 21:13:29 -0000
Received: by wavehammer.waldi.eu.org (Postfix, from userid 1000)
	id 1876B54229; Wed,  7 Dec 2011 22:13:25 +0100 (CET)
From: Bastian Blank <waldi@debian.org>
To: xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org
Date: Wed,  7 Dec 2011 22:13:14 +0100
Message-Id: <1323292396-19523-3-git-send-email-waldi@debian.org>
X-Mailer: git-send-email 1.7.7.3
In-Reply-To: <1323292396-19523-1-git-send-email-waldi@debian.org>
References: <1323292396-19523-1-git-send-email-waldi@debian.org>
Cc: konrad.wilk@oracle.com
Subject: [Xen-devel] [PATCH 2/4] xen: Add xenbus device driver
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Access to xenbus is currently handled via xenfs. This adds a device
driver for xenbus and makes xenfs use this code.

Signed-off-by: Bastian Blank <waldi@debian.org>
---
 drivers/xen/xenbus/Makefile                        |    1 +
 drivers/xen/xenbus/xenbus_comms.h                  |    4 ++
 .../xenbus.c => xenbus/xenbus_dev_frontend.c}      |   37 ++++++++++++++++++--
 drivers/xen/xenfs/Makefile                         |    2 +-
 drivers/xen/xenfs/super.c                          |    3 +-
 drivers/xen/xenfs/xenfs.h                          |    1 -
 6 files changed, 42 insertions(+), 6 deletions(-)
 rename drivers/xen/{xenfs/xenbus.c => xenbus/xenbus_dev_frontend.c} (95%)

diff --git a/drivers/xen/xenbus/Makefile b/drivers/xen/xenbus/Makefile
index 8dca685..a2ea363 100644
--- a/drivers/xen/xenbus/Makefile
+++ b/drivers/xen/xenbus/Makefile
@@ -1,4 +1,5 @@
 obj-y	+= xenbus.o
+obj-y	+= xenbus_dev_frontend.o
 
 xenbus-objs =
 xenbus-objs += xenbus_client.o
diff --git a/drivers/xen/xenbus/xenbus_comms.h b/drivers/xen/xenbus/xenbus_comms.h
index c21db75..6e42800 100644
--- a/drivers/xen/xenbus/xenbus_comms.h
+++ b/drivers/xen/xenbus/xenbus_comms.h
@@ -31,6 +31,8 @@
 #ifndef _XENBUS_COMMS_H
 #define _XENBUS_COMMS_H
 
+#include <linux/fs.h>
+
 int xs_init(void);
 int xb_init_comms(void);
 
@@ -43,4 +45,6 @@ int xs_input_avail(void);
 extern struct xenstore_domain_interface *xen_store_interface;
 extern int xen_store_evtchn;
 
+extern const struct file_operations xen_xenbus_fops;
+
 #endif /* _XENBUS_COMMS_H */
diff --git a/drivers/xen/xenfs/xenbus.c b/drivers/xen/xenbus/xenbus_dev_frontend.c
similarity index 95%
rename from drivers/xen/xenfs/xenbus.c
rename to drivers/xen/xenbus/xenbus_dev_frontend.c
index bbd000f..fb30cff 100644
--- a/drivers/xen/xenfs/xenbus.c
+++ b/drivers/xen/xenbus/xenbus_dev_frontend.c
@@ -52,13 +52,16 @@
 #include <linux/namei.h>
 #include <linux/string.h>
 #include <linux/slab.h>
+#include <linux/miscdevice.h>
+#include <linux/module.h>
 
-#include "xenfs.h"
-#include "../xenbus/xenbus_comms.h"
+#include "xenbus_comms.h"
 
 #include <xen/xenbus.h>
 #include <asm/xen/hypervisor.h>
 
+MODULE_LICENSE("GPL");
+
 /*
  * An element of a list of outstanding transactions, for which we're
  * still waiting a reply.
@@ -583,7 +586,7 @@ static unsigned int xenbus_file_poll(struct file *file, poll_table *wait)
 	return 0;
 }
 
-const struct file_operations xenbus_file_ops = {
+const struct file_operations xen_xenbus_fops = {
 	.read = xenbus_file_read,
 	.write = xenbus_file_write,
 	.open = xenbus_file_open,
@@ -591,3 +594,31 @@ const struct file_operations xenbus_file_ops = {
 	.poll = xenbus_file_poll,
 	.llseek = no_llseek,
 };
+EXPORT_SYMBOL_GPL(xen_xenbus_fops);
+
+static struct miscdevice xenbus_dev = {
+	.minor = MISC_DYNAMIC_MINOR,
+	.name = "xen/xenbus",
+	.fops = &xen_xenbus_fops,
+};
+
+static int __init xenbus_init(void)
+{
+	int err;
+
+	if (!xen_domain())
+		return -ENODEV;
+
+	err = misc_register(&xenbus_dev);
+	if (err)
+		printk(KERN_ERR "Could not register xenbus device\n");
+	return err;
+}
+
+static void __exit xenbus_exit(void)
+{
+	misc_deregister(&xenbus_dev);
+}
+
+module_init(xenbus_init);
+module_exit(xenbus_exit);
diff --git a/drivers/xen/xenfs/Makefile b/drivers/xen/xenfs/Makefile
index 5d45ff1..b019865 100644
--- a/drivers/xen/xenfs/Makefile
+++ b/drivers/xen/xenfs/Makefile
@@ -1,4 +1,4 @@
 obj-$(CONFIG_XENFS) += xenfs.o
 
-xenfs-y			  = super.o xenbus.o
+xenfs-y			  = super.o
 xenfs-$(CONFIG_XEN_DOM0) += xenstored.o
diff --git a/drivers/xen/xenfs/super.c b/drivers/xen/xenfs/super.c
index a55fbf9..a84b53c 100644
--- a/drivers/xen/xenfs/super.c
+++ b/drivers/xen/xenfs/super.c
@@ -17,6 +17,7 @@
 
 #include "xenfs.h"
 #include "../privcmd.h"
+#include "../xenbus/xenbus_comms.h"
 
 #include <asm/xen/hypervisor.h>
 
@@ -83,7 +84,7 @@ static int xenfs_fill_super(struct super_block *sb, void *data, int silent)
 {
 	static struct tree_descr xenfs_files[] = {
 		[1] = {},
-		{ "xenbus", &xenbus_file_ops, S_IRUSR|S_IWUSR },
+		{ "xenbus", &xen_xenbus_fops, S_IRUSR|S_IWUSR },
 		{ "capabilities", &capabilities_file_ops, S_IRUGO },
 		{ "privcmd", &xen_privcmd_fops, S_IRUSR|S_IWUSR },
 		{""},
diff --git a/drivers/xen/xenfs/xenfs.h b/drivers/xen/xenfs/xenfs.h
index 5056306..6b80c77 100644
--- a/drivers/xen/xenfs/xenfs.h
+++ b/drivers/xen/xenfs/xenfs.h
@@ -1,7 +1,6 @@
 #ifndef _XENFS_XENBUS_H
 #define _XENFS_XENBUS_H
 
-extern const struct file_operations xenbus_file_ops;
 extern const struct file_operations xsd_kva_file_ops;
 extern const struct file_operations xsd_port_file_ops;
 
-- 
1.7.7.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 21:14:42 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 21:14:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYOoj-0007YK-9R; Wed, 07 Dec 2011 21:14:17 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <bastian@waldi.eu.org>) id 1RYOoh-0007Xg-LD
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 21:14:15 +0000
X-Env-Sender: bastian@waldi.eu.org
X-Msg-Ref: server-6.tower-182.messagelabs.com!1323292407!6325449!1
X-Originating-IP: [82.139.201.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26664 invoked from network); 7 Dec 2011 21:13:28 -0000
Received: from wavehammer.waldi.eu.org (HELO wavehammer.waldi.eu.org)
	(82.139.201.20)
	by server-6.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 7 Dec 2011 21:13:28 -0000
Received: by wavehammer.waldi.eu.org (Postfix, from userid 1000)
	id 4950C5426E; Wed,  7 Dec 2011 22:13:26 +0100 (CET)
From: Bastian Blank <waldi@debian.org>
To: xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org
Date: Wed,  7 Dec 2011 22:13:16 +0100
Message-Id: <1323292396-19523-5-git-send-email-waldi@debian.org>
X-Mailer: git-send-email 1.7.7.3
In-Reply-To: <1323292396-19523-1-git-send-email-waldi@debian.org>
References: <1323292396-19523-1-git-send-email-waldi@debian.org>
Cc: konrad.wilk@oracle.com
Subject: [Xen-devel] [PATCH 4/4] xen/privcmd: Remove unused support for arch
	specific privcmp mmap
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

---
 drivers/xen/privcmd.c |    2 --
 1 files changed, 0 insertions(+), 2 deletions(-)

diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
index 863fbd0..c13d26a 100644
--- a/drivers/xen/privcmd.c
+++ b/drivers/xen/privcmd.c
@@ -365,7 +365,6 @@ static long privcmd_ioctl(struct file *file,
 	return ret;
 }
 
-#ifndef HAVE_ARCH_PRIVCMD_MMAP
 static int privcmd_fault(struct vm_area_struct *vma, struct vm_fault *vmf)
 {
 	printk(KERN_DEBUG "privcmd_fault: vma=%p %lx-%lx, pgoff=%lx, uv=%p\n",
@@ -398,7 +397,6 @@ static int privcmd_enforce_singleshot_mapping(struct vm_area_struct *vma)
 {
 	return (xchg(&vma->vm_private_data, (void *)1) == NULL);
 }
-#endif
 
 const struct file_operations xen_privcmd_fops = {
 	.owner = THIS_MODULE,
-- 
1.7.7.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 21:14:42 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 21:14:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYOoj-0007YK-9R; Wed, 07 Dec 2011 21:14:17 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <bastian@waldi.eu.org>) id 1RYOoh-0007Xg-LD
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 21:14:15 +0000
X-Env-Sender: bastian@waldi.eu.org
X-Msg-Ref: server-6.tower-182.messagelabs.com!1323292407!6325449!1
X-Originating-IP: [82.139.201.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26664 invoked from network); 7 Dec 2011 21:13:28 -0000
Received: from wavehammer.waldi.eu.org (HELO wavehammer.waldi.eu.org)
	(82.139.201.20)
	by server-6.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 7 Dec 2011 21:13:28 -0000
Received: by wavehammer.waldi.eu.org (Postfix, from userid 1000)
	id 4950C5426E; Wed,  7 Dec 2011 22:13:26 +0100 (CET)
From: Bastian Blank <waldi@debian.org>
To: xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org
Date: Wed,  7 Dec 2011 22:13:16 +0100
Message-Id: <1323292396-19523-5-git-send-email-waldi@debian.org>
X-Mailer: git-send-email 1.7.7.3
In-Reply-To: <1323292396-19523-1-git-send-email-waldi@debian.org>
References: <1323292396-19523-1-git-send-email-waldi@debian.org>
Cc: konrad.wilk@oracle.com
Subject: [Xen-devel] [PATCH 4/4] xen/privcmd: Remove unused support for arch
	specific privcmp mmap
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

---
 drivers/xen/privcmd.c |    2 --
 1 files changed, 0 insertions(+), 2 deletions(-)

diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
index 863fbd0..c13d26a 100644
--- a/drivers/xen/privcmd.c
+++ b/drivers/xen/privcmd.c
@@ -365,7 +365,6 @@ static long privcmd_ioctl(struct file *file,
 	return ret;
 }
 
-#ifndef HAVE_ARCH_PRIVCMD_MMAP
 static int privcmd_fault(struct vm_area_struct *vma, struct vm_fault *vmf)
 {
 	printk(KERN_DEBUG "privcmd_fault: vma=%p %lx-%lx, pgoff=%lx, uv=%p\n",
@@ -398,7 +397,6 @@ static int privcmd_enforce_singleshot_mapping(struct vm_area_struct *vma)
 {
 	return (xchg(&vma->vm_private_data, (void *)1) == NULL);
 }
-#endif
 
 const struct file_operations xen_privcmd_fops = {
 	.owner = THIS_MODULE,
-- 
1.7.7.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 21:14:42 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 21:14:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYOok-0007Ya-N1; Wed, 07 Dec 2011 21:14:18 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <bastian@waldi.eu.org>) id 1RYOoi-0007Xk-J7
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 21:14:16 +0000
X-Env-Sender: bastian@waldi.eu.org
X-Msg-Ref: server-3.tower-216.messagelabs.com!1323292407!6541589!1
X-Originating-IP: [82.139.201.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26127 invoked from network); 7 Dec 2011 21:13:28 -0000
Received: from wavehammer.waldi.eu.org (HELO wavehammer.waldi.eu.org)
	(82.139.201.20)
	by server-3.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 7 Dec 2011 21:13:28 -0000
Received: by wavehammer.waldi.eu.org (Postfix, from userid 1000)
	id 2EE895426D; Wed,  7 Dec 2011 22:13:26 +0100 (CET)
From: Bastian Blank <waldi@debian.org>
To: xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org
Date: Wed,  7 Dec 2011 22:13:15 +0100
Message-Id: <1323292396-19523-4-git-send-email-waldi@debian.org>
X-Mailer: git-send-email 1.7.7.3
In-Reply-To: <1323292396-19523-1-git-send-email-waldi@debian.org>
References: <1323292396-19523-1-git-send-email-waldi@debian.org>
Cc: konrad.wilk@oracle.com
Subject: [Xen-devel] [PATCH 3/4] xen: Add xenbusd device driver
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Access for xenstored to the event channel and pre-allocated ring is
managed via xenfs.  This adds its own device driver featuring mmap for
the ring and an ioctl for the event channel.

Signed-off-by: Bastian Blank <waldi@debian.org>
---
 drivers/xen/xenbus/Makefile             |    1 +
 drivers/xen/xenbus/xenbus_dev_backend.c |   79 +++++++++++++++++++++++++++++++
 include/xen/xenbus_dev.h                |   41 ++++++++++++++++
 3 files changed, 121 insertions(+), 0 deletions(-)
 create mode 100644 drivers/xen/xenbus/xenbus_dev_backend.c
 create mode 100644 include/xen/xenbus_dev.h

diff --git a/drivers/xen/xenbus/Makefile b/drivers/xen/xenbus/Makefile
index a2ea363..31e2e90 100644
--- a/drivers/xen/xenbus/Makefile
+++ b/drivers/xen/xenbus/Makefile
@@ -10,4 +10,5 @@ xenbus-objs += xenbus_probe.o
 xenbus-be-objs-$(CONFIG_XEN_BACKEND) += xenbus_probe_backend.o
 xenbus-objs += $(xenbus-be-objs-y)
 
+obj-$(CONFIG_XEN_BACKEND) += xenbus_dev_backend.o
 obj-$(CONFIG_XEN_XENBUS_FRONTEND) += xenbus_probe_frontend.o
diff --git a/drivers/xen/xenbus/xenbus_dev_backend.c b/drivers/xen/xenbus/xenbus_dev_backend.c
new file mode 100644
index 0000000..58cf621
--- /dev/null
+++ b/drivers/xen/xenbus/xenbus_dev_backend.c
@@ -0,0 +1,79 @@
+#include <linux/slab.h>
+#include <linux/types.h>
+#include <linux/mm.h>
+#include <linux/fs.h>
+#include <linux/miscdevice.h>
+#include <linux/module.h>
+
+#include <xen/page.h>
+#include <xen/xenbus_dev.h>
+
+#include "xenbus_comms.h"
+
+MODULE_LICENSE("GPL");
+
+static long xenbusd_ioctl(struct file *file, unsigned int cmd, unsigned long data)
+{
+	if (!capable(CAP_SYS_ADMIN))
+		return -EACCES;
+
+	switch (cmd) {
+		case IOCTL_XENBUSD_EVTCHN:
+			if (xen_store_evtchn > 0)
+				return xen_store_evtchn;
+			return -ENODEV;
+
+		default:
+			return -ENOTTY;
+	}
+}
+
+static int xenbusd_mmap(struct file *file, struct vm_area_struct *vma)
+{
+	size_t size = vma->vm_end - vma->vm_start;
+
+	if (!capable(CAP_SYS_ADMIN))
+		return -EACCES;
+
+	if ((size > PAGE_SIZE) || (vma->vm_pgoff != 0))
+		return -EINVAL;
+
+	if (remap_pfn_range(vma, vma->vm_start,
+			    virt_to_pfn(xen_store_interface),
+			    size, vma->vm_page_prot))
+		return -EAGAIN;
+
+	return 0;
+}
+
+const struct file_operations xenbusd_fops = {
+	.mmap = xenbusd_mmap,
+	.unlocked_ioctl = xenbusd_ioctl,
+};
+
+static struct miscdevice xenbusd_dev = {
+	.minor = MISC_DYNAMIC_MINOR,
+	.name = "xen/xenbusd",
+	.fops = &xenbusd_fops,
+};
+
+static int __init xenbusd_init(void)
+{
+	int err;
+
+	if (!xen_initial_domain())
+		return -ENODEV;
+
+	err = misc_register(&xenbusd_dev);
+	if (err)
+		printk(KERN_ERR "Could not register xenbus device\n");
+	return err;
+}
+
+static void __exit xenbusd_exit(void)
+{
+	misc_deregister(&xenbusd_dev);
+}
+
+module_init(xenbusd_init);
+module_exit(xenbusd_exit);
diff --git a/include/xen/xenbus_dev.h b/include/xen/xenbus_dev.h
new file mode 100644
index 0000000..3008c03
--- /dev/null
+++ b/include/xen/xenbus_dev.h
@@ -0,0 +1,41 @@
+/******************************************************************************
+ * evtchn.h
+ *
+ * Interface to /dev/xen/xenbusd.
+ *
+ * Copyright (c) 2011 Bastian Blank <waldi@debian.org>
+ *
+ * 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 __LINUX_XEN_XENBUS_DEV_H__
+#define __LINUX_XEN_XENBUS_DEV_H__
+
+#include <linux/ioctl.h>
+
+#define IOCTL_XENBUSD_EVTCHN				\
+	_IOC(_IOC_NONE, 'B', 0, 0)
+
+#endif /* __LINUX_XEN_XENBUS_DEV_H__ */
-- 
1.7.7.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 21:14:42 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 21:14:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYOok-0007Ya-N1; Wed, 07 Dec 2011 21:14:18 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <bastian@waldi.eu.org>) id 1RYOoi-0007Xk-J7
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 21:14:16 +0000
X-Env-Sender: bastian@waldi.eu.org
X-Msg-Ref: server-3.tower-216.messagelabs.com!1323292407!6541589!1
X-Originating-IP: [82.139.201.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26127 invoked from network); 7 Dec 2011 21:13:28 -0000
Received: from wavehammer.waldi.eu.org (HELO wavehammer.waldi.eu.org)
	(82.139.201.20)
	by server-3.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 7 Dec 2011 21:13:28 -0000
Received: by wavehammer.waldi.eu.org (Postfix, from userid 1000)
	id 2EE895426D; Wed,  7 Dec 2011 22:13:26 +0100 (CET)
From: Bastian Blank <waldi@debian.org>
To: xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org
Date: Wed,  7 Dec 2011 22:13:15 +0100
Message-Id: <1323292396-19523-4-git-send-email-waldi@debian.org>
X-Mailer: git-send-email 1.7.7.3
In-Reply-To: <1323292396-19523-1-git-send-email-waldi@debian.org>
References: <1323292396-19523-1-git-send-email-waldi@debian.org>
Cc: konrad.wilk@oracle.com
Subject: [Xen-devel] [PATCH 3/4] xen: Add xenbusd device driver
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Access for xenstored to the event channel and pre-allocated ring is
managed via xenfs.  This adds its own device driver featuring mmap for
the ring and an ioctl for the event channel.

Signed-off-by: Bastian Blank <waldi@debian.org>
---
 drivers/xen/xenbus/Makefile             |    1 +
 drivers/xen/xenbus/xenbus_dev_backend.c |   79 +++++++++++++++++++++++++++++++
 include/xen/xenbus_dev.h                |   41 ++++++++++++++++
 3 files changed, 121 insertions(+), 0 deletions(-)
 create mode 100644 drivers/xen/xenbus/xenbus_dev_backend.c
 create mode 100644 include/xen/xenbus_dev.h

diff --git a/drivers/xen/xenbus/Makefile b/drivers/xen/xenbus/Makefile
index a2ea363..31e2e90 100644
--- a/drivers/xen/xenbus/Makefile
+++ b/drivers/xen/xenbus/Makefile
@@ -10,4 +10,5 @@ xenbus-objs += xenbus_probe.o
 xenbus-be-objs-$(CONFIG_XEN_BACKEND) += xenbus_probe_backend.o
 xenbus-objs += $(xenbus-be-objs-y)
 
+obj-$(CONFIG_XEN_BACKEND) += xenbus_dev_backend.o
 obj-$(CONFIG_XEN_XENBUS_FRONTEND) += xenbus_probe_frontend.o
diff --git a/drivers/xen/xenbus/xenbus_dev_backend.c b/drivers/xen/xenbus/xenbus_dev_backend.c
new file mode 100644
index 0000000..58cf621
--- /dev/null
+++ b/drivers/xen/xenbus/xenbus_dev_backend.c
@@ -0,0 +1,79 @@
+#include <linux/slab.h>
+#include <linux/types.h>
+#include <linux/mm.h>
+#include <linux/fs.h>
+#include <linux/miscdevice.h>
+#include <linux/module.h>
+
+#include <xen/page.h>
+#include <xen/xenbus_dev.h>
+
+#include "xenbus_comms.h"
+
+MODULE_LICENSE("GPL");
+
+static long xenbusd_ioctl(struct file *file, unsigned int cmd, unsigned long data)
+{
+	if (!capable(CAP_SYS_ADMIN))
+		return -EACCES;
+
+	switch (cmd) {
+		case IOCTL_XENBUSD_EVTCHN:
+			if (xen_store_evtchn > 0)
+				return xen_store_evtchn;
+			return -ENODEV;
+
+		default:
+			return -ENOTTY;
+	}
+}
+
+static int xenbusd_mmap(struct file *file, struct vm_area_struct *vma)
+{
+	size_t size = vma->vm_end - vma->vm_start;
+
+	if (!capable(CAP_SYS_ADMIN))
+		return -EACCES;
+
+	if ((size > PAGE_SIZE) || (vma->vm_pgoff != 0))
+		return -EINVAL;
+
+	if (remap_pfn_range(vma, vma->vm_start,
+			    virt_to_pfn(xen_store_interface),
+			    size, vma->vm_page_prot))
+		return -EAGAIN;
+
+	return 0;
+}
+
+const struct file_operations xenbusd_fops = {
+	.mmap = xenbusd_mmap,
+	.unlocked_ioctl = xenbusd_ioctl,
+};
+
+static struct miscdevice xenbusd_dev = {
+	.minor = MISC_DYNAMIC_MINOR,
+	.name = "xen/xenbusd",
+	.fops = &xenbusd_fops,
+};
+
+static int __init xenbusd_init(void)
+{
+	int err;
+
+	if (!xen_initial_domain())
+		return -ENODEV;
+
+	err = misc_register(&xenbusd_dev);
+	if (err)
+		printk(KERN_ERR "Could not register xenbus device\n");
+	return err;
+}
+
+static void __exit xenbusd_exit(void)
+{
+	misc_deregister(&xenbusd_dev);
+}
+
+module_init(xenbusd_init);
+module_exit(xenbusd_exit);
diff --git a/include/xen/xenbus_dev.h b/include/xen/xenbus_dev.h
new file mode 100644
index 0000000..3008c03
--- /dev/null
+++ b/include/xen/xenbus_dev.h
@@ -0,0 +1,41 @@
+/******************************************************************************
+ * evtchn.h
+ *
+ * Interface to /dev/xen/xenbusd.
+ *
+ * Copyright (c) 2011 Bastian Blank <waldi@debian.org>
+ *
+ * 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 __LINUX_XEN_XENBUS_DEV_H__
+#define __LINUX_XEN_XENBUS_DEV_H__
+
+#include <linux/ioctl.h>
+
+#define IOCTL_XENBUSD_EVTCHN				\
+	_IOC(_IOC_NONE, 'B', 0, 0)
+
+#endif /* __LINUX_XEN_XENBUS_DEV_H__ */
-- 
1.7.7.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 21:20:31 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 21:20:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYOuS-0008DH-V6; Wed, 07 Dec 2011 21:20:12 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <bastian@waldi.eu.org>) id 1RYOuR-0008Ct-F0
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 21:20:11 +0000
X-Env-Sender: bastian@waldi.eu.org
X-Msg-Ref: server-6.tower-216.messagelabs.com!1323292763!6562642!1
X-Originating-IP: [82.139.201.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18585 invoked from network); 7 Dec 2011 21:19:24 -0000
Received: from wavehammer.waldi.eu.org (HELO wavehammer.waldi.eu.org)
	(82.139.201.20)
	by server-6.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 7 Dec 2011 21:19:24 -0000
Received: by wavehammer.waldi.eu.org (Postfix, from userid 1000)
	id C50F35415A; Wed,  7 Dec 2011 22:13:25 +0100 (CET)
From: Bastian Blank <waldi@debian.org>
To: xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org
Date: Wed,  7 Dec 2011 22:13:12 +0100
Message-Id: <1323292396-19523-1-git-send-email-waldi@debian.org>
X-Mailer: git-send-email 1.7.7.3
Cc: konrad.wilk@oracle.com
Subject: [Xen-devel] [PATCH 0/4] V2, Move stuff out of xenfs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

In <20100605162947.GA31336@wavehammer.waldi.eu.org> I started the
discussion about xenfs and the usage of it. This is the second try to
move stuff over into normal device drivers.

Changes:
- Remove guest_capabilities stuff. It is only used to detect if the init
  scripts should start anything.
- Fix error values.

Bastian


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 21:20:31 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 21:20:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYOuS-0008DH-V6; Wed, 07 Dec 2011 21:20:12 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <bastian@waldi.eu.org>) id 1RYOuR-0008Ct-F0
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 21:20:11 +0000
X-Env-Sender: bastian@waldi.eu.org
X-Msg-Ref: server-6.tower-216.messagelabs.com!1323292763!6562642!1
X-Originating-IP: [82.139.201.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18585 invoked from network); 7 Dec 2011 21:19:24 -0000
Received: from wavehammer.waldi.eu.org (HELO wavehammer.waldi.eu.org)
	(82.139.201.20)
	by server-6.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 7 Dec 2011 21:19:24 -0000
Received: by wavehammer.waldi.eu.org (Postfix, from userid 1000)
	id C50F35415A; Wed,  7 Dec 2011 22:13:25 +0100 (CET)
From: Bastian Blank <waldi@debian.org>
To: xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org
Date: Wed,  7 Dec 2011 22:13:12 +0100
Message-Id: <1323292396-19523-1-git-send-email-waldi@debian.org>
X-Mailer: git-send-email 1.7.7.3
Cc: konrad.wilk@oracle.com
Subject: [Xen-devel] [PATCH 0/4] V2, Move stuff out of xenfs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

In <20100605162947.GA31336@wavehammer.waldi.eu.org> I started the
discussion about xenfs and the usage of it. This is the second try to
move stuff over into normal device drivers.

Changes:
- Remove guest_capabilities stuff. It is only used to detect if the init
  scripts should start anything.
- Fix error values.

Bastian


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 22:11:02 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 22:11:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYPhF-00025f-RZ; Wed, 07 Dec 2011 22:10:37 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@cs.ubc.ca>) id 1RYPhF-00025W-8G
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 22:10:37 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-12.tower-174.messagelabs.com!1323295787!4630671!1
X-Originating-IP: [142.103.6.52]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20650 invoked from network); 7 Dec 2011 22:09:49 -0000
Received: from smtp.cs.ubc.ca (HELO smtp.cs.ubc.ca) (142.103.6.52)
	by server-12.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 7 Dec 2011 22:09:49 -0000
Received: from mail-bw0-f43.google.com (mail-bw0-f43.google.com
	[209.85.214.43]) (authenticated bits=0)
	by smtp.cs.ubc.ca (8.14.3/8.13.6) with ESMTP id pB7M9ikf028217
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL)
	for <xen-devel@lists.xensource.com>; Wed, 7 Dec 2011 14:09:46 -0800
Received: by bkbzs2 with SMTP id zs2so2818351bkb.30
	for <xen-devel@lists.xensource.com>;
	Wed, 07 Dec 2011 14:09:43 -0800 (PST)
Received: by 10.205.118.12 with SMTP id fo12mr286955bkc.33.1323295783344; Wed,
	07 Dec 2011 14:09:43 -0800 (PST)
MIME-Version: 1.0
Received: by 10.204.179.10 with HTTP; Wed, 7 Dec 2011 14:09:02 -0800 (PST)
In-Reply-To: <9eaac880f504a12c145d.1323250728@cosworth.uk.xensource.com>
References: <9eaac880f504a12c145d.1323250728@cosworth.uk.xensource.com>
From: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Date: Wed, 7 Dec 2011 14:09:02 -0800
Message-ID: <CAP8mzPNQURKSnS27GPVws4d9RCwXGWLkNFVgneApNgavjSrh5g@mail.gmail.com>
To: Paul Durrant <paul.durrant@citrix.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] VM generation ID save/restore and migrate
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: rshriram@cs.ubc.ca
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Dec 7, 2011 at 1:38 AM, Paul Durrant <paul.durrant@citrix.com> wrot=
e:
>
> diff -r 38eb74c01d9d -r 9eaac880f504 tools/xcutils/xc_restore.c
> --- a/tools/xcutils/xc_restore.c =A0 =A0 =A0 =A0Tue Dec 06 21:16:56 2011 =
+0000
> +++ b/tools/xcutils/xc_restore.c =A0 =A0 =A0 =A0Wed Dec 07 09:36:07 2011 =
+0000
> @@ -23,11 +23,12 @@ main(int argc, char **argv)
> =A0 =A0 xc_interface *xch;
> =A0 =A0 int io_fd, ret;
> =A0 =A0 int superpages;
> - =A0 =A0unsigned long store_mfn, console_mfn;
> + =A0 =A0unsigned long store_mfn, console_mfn, vm_gid_addr;
> + =A0 =A0int no_increment_gid;
>
> - =A0 =A0if ( (argc !=3D 8) && (argc !=3D 9) )
> + =A0 =A0if ( (argc < 8) || (argc > 10) )
> =A0 =A0 =A0 =A0 errx(1, "usage: %s iofd domid store_evtchn "
> - =A0 =A0 =A0 =A0 =A0 =A0 "console_evtchn hvm pae apic [superpages]", arg=
v[0]);
> + =A0 =A0 =A0 =A0 =A0 =A0 "console_evtchn hvm pae apic [superpages [no_in=
crement_gid]]", argv[0]);
>
> =A0 =A0 xch =3D xc_interface_open(0,0,0);
> =A0 =A0 if ( !xch )
> @@ -40,19 +41,25 @@ main(int argc, char **argv)
> =A0 =A0 hvm =A0=3D atoi(argv[5]);
> =A0 =A0 pae =A0=3D atoi(argv[6]);
> =A0 =A0 apic =3D atoi(argv[7]);
> - =A0 =A0if ( argc =3D=3D 9 )
> + =A0 =A0if ( argc >=3D 9 )
> =A0 =A0 =A0 =A0 =A0 =A0superpages =3D atoi(argv[8]);
> =A0 =A0 else
> =A0 =A0 =A0 =A0 =A0 =A0superpages =3D !!hvm;
> + =A0 =A0if ( argc >=3D 10 )
> + =A0 =A0 =A0 =A0 =A0 no_increment_gid =3D !atoi(argv[9]);
> + =A0 =A0else
> + =A0 =A0 =A0 =A0 =A0 no_increment_gid =3D 0;
>

Just a nit:
It would be better if this was " if (argc =3D=3D 10) no_increment..." as the
current form contradicts with the previous check (if argc <8 || argc > 10),
but I guess there is no correctness issue since the first check would catch=
 any
extra args.

Anyway, I am okay with the patch.

Acked-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>
 for *sections I am responsible for* (tools/python/xen/lowlevel/checkpoint/=
*).


cheers
shriram

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 22:11:02 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 22:11:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYPhF-00025f-RZ; Wed, 07 Dec 2011 22:10:37 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@cs.ubc.ca>) id 1RYPhF-00025W-8G
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 22:10:37 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-12.tower-174.messagelabs.com!1323295787!4630671!1
X-Originating-IP: [142.103.6.52]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20650 invoked from network); 7 Dec 2011 22:09:49 -0000
Received: from smtp.cs.ubc.ca (HELO smtp.cs.ubc.ca) (142.103.6.52)
	by server-12.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 7 Dec 2011 22:09:49 -0000
Received: from mail-bw0-f43.google.com (mail-bw0-f43.google.com
	[209.85.214.43]) (authenticated bits=0)
	by smtp.cs.ubc.ca (8.14.3/8.13.6) with ESMTP id pB7M9ikf028217
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL)
	for <xen-devel@lists.xensource.com>; Wed, 7 Dec 2011 14:09:46 -0800
Received: by bkbzs2 with SMTP id zs2so2818351bkb.30
	for <xen-devel@lists.xensource.com>;
	Wed, 07 Dec 2011 14:09:43 -0800 (PST)
Received: by 10.205.118.12 with SMTP id fo12mr286955bkc.33.1323295783344; Wed,
	07 Dec 2011 14:09:43 -0800 (PST)
MIME-Version: 1.0
Received: by 10.204.179.10 with HTTP; Wed, 7 Dec 2011 14:09:02 -0800 (PST)
In-Reply-To: <9eaac880f504a12c145d.1323250728@cosworth.uk.xensource.com>
References: <9eaac880f504a12c145d.1323250728@cosworth.uk.xensource.com>
From: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Date: Wed, 7 Dec 2011 14:09:02 -0800
Message-ID: <CAP8mzPNQURKSnS27GPVws4d9RCwXGWLkNFVgneApNgavjSrh5g@mail.gmail.com>
To: Paul Durrant <paul.durrant@citrix.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] VM generation ID save/restore and migrate
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: rshriram@cs.ubc.ca
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Dec 7, 2011 at 1:38 AM, Paul Durrant <paul.durrant@citrix.com> wrot=
e:
>
> diff -r 38eb74c01d9d -r 9eaac880f504 tools/xcutils/xc_restore.c
> --- a/tools/xcutils/xc_restore.c =A0 =A0 =A0 =A0Tue Dec 06 21:16:56 2011 =
+0000
> +++ b/tools/xcutils/xc_restore.c =A0 =A0 =A0 =A0Wed Dec 07 09:36:07 2011 =
+0000
> @@ -23,11 +23,12 @@ main(int argc, char **argv)
> =A0 =A0 xc_interface *xch;
> =A0 =A0 int io_fd, ret;
> =A0 =A0 int superpages;
> - =A0 =A0unsigned long store_mfn, console_mfn;
> + =A0 =A0unsigned long store_mfn, console_mfn, vm_gid_addr;
> + =A0 =A0int no_increment_gid;
>
> - =A0 =A0if ( (argc !=3D 8) && (argc !=3D 9) )
> + =A0 =A0if ( (argc < 8) || (argc > 10) )
> =A0 =A0 =A0 =A0 errx(1, "usage: %s iofd domid store_evtchn "
> - =A0 =A0 =A0 =A0 =A0 =A0 "console_evtchn hvm pae apic [superpages]", arg=
v[0]);
> + =A0 =A0 =A0 =A0 =A0 =A0 "console_evtchn hvm pae apic [superpages [no_in=
crement_gid]]", argv[0]);
>
> =A0 =A0 xch =3D xc_interface_open(0,0,0);
> =A0 =A0 if ( !xch )
> @@ -40,19 +41,25 @@ main(int argc, char **argv)
> =A0 =A0 hvm =A0=3D atoi(argv[5]);
> =A0 =A0 pae =A0=3D atoi(argv[6]);
> =A0 =A0 apic =3D atoi(argv[7]);
> - =A0 =A0if ( argc =3D=3D 9 )
> + =A0 =A0if ( argc >=3D 9 )
> =A0 =A0 =A0 =A0 =A0 =A0superpages =3D atoi(argv[8]);
> =A0 =A0 else
> =A0 =A0 =A0 =A0 =A0 =A0superpages =3D !!hvm;
> + =A0 =A0if ( argc >=3D 10 )
> + =A0 =A0 =A0 =A0 =A0 no_increment_gid =3D !atoi(argv[9]);
> + =A0 =A0else
> + =A0 =A0 =A0 =A0 =A0 no_increment_gid =3D 0;
>

Just a nit:
It would be better if this was " if (argc =3D=3D 10) no_increment..." as the
current form contradicts with the previous check (if argc <8 || argc > 10),
but I guess there is no correctness issue since the first check would catch=
 any
extra args.

Anyway, I am okay with the patch.

Acked-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>
 for *sections I am responsible for* (tools/python/xen/lowlevel/checkpoint/=
*).


cheers
shriram

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 22:37:44 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 22:37:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYQ6x-0002SG-8a; Wed, 07 Dec 2011 22:37:11 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RYQ6v-0002SB-E4
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 22:37:09 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1323297381!6316852!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjA3NQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19643 invoked from network); 7 Dec 2011 22:36:21 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Dec 2011 22:36:21 -0000
X-IronPort-AV: E=Sophos;i="4.71,316,1320624000"; 
   d="scan'208";a="9352041"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Dec 2011 22:36:21 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 7 Dec 2011 22:36:21 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RYQ69-00055K-1O;
	Wed, 07 Dec 2011 22:36:21 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RYQ69-0003BD-0j;
	Wed, 07 Dec 2011 22:36:21 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10416-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 7 Dec 2011 22:36:21 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10416: regressions - trouble:
	broken/fail/pass
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10416 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10416/

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-amd64-xl-win7-amd64  3 host-install(3)              broken
 test-amd64-i386-rhel6hvm-intel  3 host-install(3)              broken
 test-i386-i386-xl             3 host-install(3)              broken
 test-amd64-i386-win           8 guest-saverestore         fail REGR. vs. 10201
 test-i386-i386-win            8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-i386-win-vcpus1    8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-amd64-win          8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-i386-xl-win-vcpus1  8 guest-saverestore        fail REGR. vs. 10201
 test-i386-i386-xl-win         8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-amd64-xl-win      8 guest-saverestore fail in 10401 REGR. vs. 10201

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-win       7 windows-install             fail pass in 10401
 test-amd64-amd64-xl-sedf     11 guest-localmigrate fail in 10401 pass in 10416
 test-amd64-i386-xl-win-vcpus1  7 windows-install   fail in 10401 pass in 10416

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install          fail never pass
 test-i386-i386-xl-winxpsp3    7 windows-install              fail   never pass
 test-amd64-i386-xend-winxpsp3  7 windows-install              fail  never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xl-win7-amd64  7 windows-install              fail  never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   never pass
 test-amd64-amd64-xl-win7-amd64  7 windows-install     fail in 10401 never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2       fail in 10401 never pass

version targeted for testing:
 xen                  38eb74c01d9d
baseline version:
 xen                  62ff6a318c5d

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scanneel.ca>
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Andres Lagar-Cavilla <andres@lagarcavilla>
  Andrew Cooper <andrew.cooper3@citrix.com>
  Anthony PERARD <anthony.perard@citrix.com>
  Brendan Cully <brendan@cs.ubc.ca>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Haitao Shan <haitao.shan@intel.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@novell.com>
  Jan Beulich <jbeulich@suse.com>
  Jonathan Davies <jonathan.davies@citrix.com>
  juergen.gross@ts.fujitsu.com
  Keir Fraser <keir@xen.org>
  Liu, Jinsong <jinsong.liu@intel.com>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
  Philipp Hahn <hahn@univention.de>
  Shriram Rajagopalan <rshriram@cs.ubc.ca>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang2 <wei.wang2@amd.com>
  Xudong Hao <xudong.hao@intel.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            broken  
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               broken  
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               broken  
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 1493 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 07 22:37:44 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 Dec 2011 22:37:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYQ6x-0002SG-8a; Wed, 07 Dec 2011 22:37:11 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RYQ6v-0002SB-E4
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 22:37:09 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1323297381!6316852!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MjA3NQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19643 invoked from network); 7 Dec 2011 22:36:21 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Dec 2011 22:36:21 -0000
X-IronPort-AV: E=Sophos;i="4.71,316,1320624000"; 
   d="scan'208";a="9352041"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Dec 2011 22:36:21 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 7 Dec 2011 22:36:21 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RYQ69-00055K-1O;
	Wed, 07 Dec 2011 22:36:21 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RYQ69-0003BD-0j;
	Wed, 07 Dec 2011 22:36:21 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10416-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 7 Dec 2011 22:36:21 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10416: regressions - trouble:
	broken/fail/pass
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10416 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10416/

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-amd64-xl-win7-amd64  3 host-install(3)              broken
 test-amd64-i386-rhel6hvm-intel  3 host-install(3)              broken
 test-i386-i386-xl             3 host-install(3)              broken
 test-amd64-i386-win           8 guest-saverestore         fail REGR. vs. 10201
 test-i386-i386-win            8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-i386-win-vcpus1    8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-amd64-win          8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-i386-xl-win-vcpus1  8 guest-saverestore        fail REGR. vs. 10201
 test-i386-i386-xl-win         8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-amd64-xl-win      8 guest-saverestore fail in 10401 REGR. vs. 10201

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-win       7 windows-install             fail pass in 10401
 test-amd64-amd64-xl-sedf     11 guest-localmigrate fail in 10401 pass in 10416
 test-amd64-i386-xl-win-vcpus1  7 windows-install   fail in 10401 pass in 10416

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install          fail never pass
 test-i386-i386-xl-winxpsp3    7 windows-install              fail   never pass
 test-amd64-i386-xend-winxpsp3  7 windows-install              fail  never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xl-win7-amd64  7 windows-install              fail  never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   never pass
 test-amd64-amd64-xl-win7-amd64  7 windows-install     fail in 10401 never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2       fail in 10401 never pass

version targeted for testing:
 xen                  38eb74c01d9d
baseline version:
 xen                  62ff6a318c5d

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scanneel.ca>
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Andres Lagar-Cavilla <andres@lagarcavilla>
  Andrew Cooper <andrew.cooper3@citrix.com>
  Anthony PERARD <anthony.perard@citrix.com>
  Brendan Cully <brendan@cs.ubc.ca>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Haitao Shan <haitao.shan@intel.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@novell.com>
  Jan Beulich <jbeulich@suse.com>
  Jonathan Davies <jonathan.davies@citrix.com>
  juergen.gross@ts.fujitsu.com
  Keir Fraser <keir@xen.org>
  Liu, Jinsong <jinsong.liu@intel.com>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
  Philipp Hahn <hahn@univention.de>
  Shriram Rajagopalan <rshriram@cs.ubc.ca>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang2 <wei.wang2@amd.com>
  Xudong Hao <xudong.hao@intel.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            broken  
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               broken  
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               broken  
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 1493 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 08 02:29:44 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 Dec 2011 02: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.xensource.com>)
	id 1RYTjH-00086w-6u; Thu, 08 Dec 2011 02:28:59 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RYTjE-00086o-KW
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 02:28:56 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1323311260!55819529!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTI0OA==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23038 invoked from network); 8 Dec 2011 02:27:40 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Dec 2011 02:27:40 -0000
X-IronPort-AV: E=Sophos;i="4.71,317,1320624000"; 
   d="scan'208";a="9353159"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Dec 2011 02:27:55 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 8 Dec 2011 02:27:55 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RYTiF-0006Lj-Ev;
	Thu, 08 Dec 2011 02:27:55 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RYTiF-000310-8f;
	Thu, 08 Dec 2011 02:27:55 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10420-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 8 Dec 2011 02:27:55 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10420: regressions - trouble:
	broken/fail/pass
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10420 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10420/

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-i386-xend-winxpsp3  3 host-install(3)              broken
 test-amd64-i386-win           8 guest-saverestore         fail REGR. vs. 10201
 test-i386-i386-win            8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-i386-win-vcpus1    8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-amd64-win          8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-amd64-xl-win       3 host-install(3)              broken
 test-amd64-i386-xl-win-vcpus1  3 host-install(3)              broken
 test-amd64-amd64-xl-win7-amd64  3 host-install(3)              broken in 10416
 test-amd64-i386-rhel6hvm-intel  3 host-install(3)              broken in 10416
 test-i386-i386-xl             3 host-install(3)              broken   in 10416
 test-amd64-i386-xl-win-vcpus1 8 guest-saverestore fail in 10416 REGR. vs. 10201
 test-i386-i386-xl-win        8 guest-saverestore fail in 10416 REGR. vs. 10201
 test-amd64-amd64-xl-win      8 guest-saverestore fail in 10401 REGR. vs. 10201

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf     14 guest-localmigrate/x10      fail pass in 10416
 test-i386-i386-xl-win         7 windows-install             fail pass in 10416
 test-amd64-amd64-xl-win       7 windows-install    fail in 10416 pass in 10401
 test-amd64-amd64-xl-sedf     11 guest-localmigrate fail in 10401 pass in 10420
 test-amd64-i386-xl-win-vcpus1  7 windows-install   fail in 10401 pass in 10416

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install          fail never pass
 test-i386-i386-xl-winxpsp3    7 windows-install              fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xl-win7-amd64  7 windows-install              fail  never pass
 test-amd64-amd64-xl-win7-amd64  7 windows-install              fail never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   never pass
 test-amd64-i386-xend-winxpsp3  7 windows-install      fail in 10416 never pass

version targeted for testing:
 xen                  38eb74c01d9d
baseline version:
 xen                  62ff6a318c5d

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scanneel.ca>
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Andres Lagar-Cavilla <andres@lagarcavilla>
  Andrew Cooper <andrew.cooper3@citrix.com>
  Anthony PERARD <anthony.perard@citrix.com>
  Brendan Cully <brendan@cs.ubc.ca>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Haitao Shan <haitao.shan@intel.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@novell.com>
  Jan Beulich <jbeulich@suse.com>
  Jonathan Davies <jonathan.davies@citrix.com>
  juergen.gross@ts.fujitsu.com
  Keir Fraser <keir@xen.org>
  Liu, Jinsong <jinsong.liu@intel.com>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
  Philipp Hahn <hahn@univention.de>
  Shriram Rajagopalan <rshriram@cs.ubc.ca>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang2 <wei.wang2@amd.com>
  Xudong Hao <xudong.hao@intel.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                broken  
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      broken  
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                broken  
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 1493 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 08 02:29:44 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 Dec 2011 02: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.xensource.com>)
	id 1RYTjH-00086w-6u; Thu, 08 Dec 2011 02:28:59 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RYTjE-00086o-KW
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 02:28:56 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1323311260!55819529!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTI0OA==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23038 invoked from network); 8 Dec 2011 02:27:40 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Dec 2011 02:27:40 -0000
X-IronPort-AV: E=Sophos;i="4.71,317,1320624000"; 
   d="scan'208";a="9353159"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Dec 2011 02:27:55 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 8 Dec 2011 02:27:55 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RYTiF-0006Lj-Ev;
	Thu, 08 Dec 2011 02:27:55 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RYTiF-000310-8f;
	Thu, 08 Dec 2011 02:27:55 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10420-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 8 Dec 2011 02:27:55 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10420: regressions - trouble:
	broken/fail/pass
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10420 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10420/

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-i386-xend-winxpsp3  3 host-install(3)              broken
 test-amd64-i386-win           8 guest-saverestore         fail REGR. vs. 10201
 test-i386-i386-win            8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-i386-win-vcpus1    8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-amd64-win          8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-amd64-xl-win       3 host-install(3)              broken
 test-amd64-i386-xl-win-vcpus1  3 host-install(3)              broken
 test-amd64-amd64-xl-win7-amd64  3 host-install(3)              broken in 10416
 test-amd64-i386-rhel6hvm-intel  3 host-install(3)              broken in 10416
 test-i386-i386-xl             3 host-install(3)              broken   in 10416
 test-amd64-i386-xl-win-vcpus1 8 guest-saverestore fail in 10416 REGR. vs. 10201
 test-i386-i386-xl-win        8 guest-saverestore fail in 10416 REGR. vs. 10201
 test-amd64-amd64-xl-win      8 guest-saverestore fail in 10401 REGR. vs. 10201

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf     14 guest-localmigrate/x10      fail pass in 10416
 test-i386-i386-xl-win         7 windows-install             fail pass in 10416
 test-amd64-amd64-xl-win       7 windows-install    fail in 10416 pass in 10401
 test-amd64-amd64-xl-sedf     11 guest-localmigrate fail in 10401 pass in 10420
 test-amd64-i386-xl-win-vcpus1  7 windows-install   fail in 10401 pass in 10416

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install          fail never pass
 test-i386-i386-xl-winxpsp3    7 windows-install              fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xl-win7-amd64  7 windows-install              fail  never pass
 test-amd64-amd64-xl-win7-amd64  7 windows-install              fail never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   never pass
 test-amd64-i386-xend-winxpsp3  7 windows-install      fail in 10416 never pass

version targeted for testing:
 xen                  38eb74c01d9d
baseline version:
 xen                  62ff6a318c5d

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scanneel.ca>
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Andres Lagar-Cavilla <andres@lagarcavilla>
  Andrew Cooper <andrew.cooper3@citrix.com>
  Anthony PERARD <anthony.perard@citrix.com>
  Brendan Cully <brendan@cs.ubc.ca>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Haitao Shan <haitao.shan@intel.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@novell.com>
  Jan Beulich <jbeulich@suse.com>
  Jonathan Davies <jonathan.davies@citrix.com>
  juergen.gross@ts.fujitsu.com
  Keir Fraser <keir@xen.org>
  Liu, Jinsong <jinsong.liu@intel.com>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
  Philipp Hahn <hahn@univention.de>
  Shriram Rajagopalan <rshriram@cs.ubc.ca>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang2 <wei.wang2@amd.com>
  Xudong Hao <xudong.hao@intel.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                broken  
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      broken  
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                broken  
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 1493 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 08 05:27:58 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 Dec 2011 05:27:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYWVm-0001re-Ft; Thu, 08 Dec 2011 05:27:14 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RYWVl-0001rV-Cq
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 05:27:13 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1323321985!6015614!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTI0OA==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30068 invoked from network); 8 Dec 2011 05:26:25 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Dec 2011 05:26:25 -0000
X-IronPort-AV: E=Sophos;i="4.71,318,1320624000"; 
   d="scan'208";a="9353892"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Dec 2011 05:26:25 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 8 Dec 2011 05:26:25 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RYWUz-0007KT-0f;
	Thu, 08 Dec 2011 05:26:25 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RYWUy-0000yI-WE;
	Thu, 08 Dec 2011 05:26:25 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10424-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 8 Dec 2011 05:26:24 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10424: regressions - trouble:
	broken/fail/pass
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10424 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10424/

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-amd64-xl-win7-amd64  3 host-install(3)              broken
 test-amd64-i386-rhel6hvm-intel  3 host-install(3)              broken
 test-amd64-i386-win           3 host-install(3)              broken
 test-i386-i386-win            8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-i386-win-vcpus1    8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-amd64-win          8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-i386-xl-win-vcpus1  8 guest-saverestore        fail REGR. vs. 10201
 test-i386-i386-xl-win         8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-i386-xend-winxpsp3  3 host-install(3)              broken  in 10420
 test-amd64-i386-win          8 guest-saverestore fail in 10420 REGR. vs. 10201
 test-amd64-amd64-xl-win       3 host-install(3)              broken   in 10420
 test-amd64-i386-xl-win-vcpus1  3 host-install(3)              broken  in 10420
 test-amd64-amd64-xl-win      8 guest-saverestore fail in 10401 REGR. vs. 10201

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-credit2    7 debian-install              fail pass in 10420
 test-amd64-amd64-xl-win       7 windows-install             fail pass in 10401
 test-amd64-amd64-xl-sedf 14 guest-localmigrate/x10 fail in 10420 pass in 10424
 test-i386-i386-xl-win         7 windows-install    fail in 10420 pass in 10424
 test-amd64-amd64-xl-sedf     11 guest-localmigrate fail in 10401 pass in 10424
 test-amd64-i386-xl-win-vcpus1  7 windows-install   fail in 10401 pass in 10424

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install          fail never pass
 test-i386-i386-xl-winxpsp3    7 windows-install              fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xl-win7-amd64  7 windows-install              fail  never pass
 test-amd64-i386-xend-winxpsp3  7 windows-install              fail  never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   never pass
 test-amd64-amd64-xl-win7-amd64  7 windows-install     fail in 10420 never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2       fail in 10420 never pass

version targeted for testing:
 xen                  38eb74c01d9d
baseline version:
 xen                  62ff6a318c5d

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scanneel.ca>
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Andres Lagar-Cavilla <andres@lagarcavilla>
  Andrew Cooper <andrew.cooper3@citrix.com>
  Anthony PERARD <anthony.perard@citrix.com>
  Brendan Cully <brendan@cs.ubc.ca>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Haitao Shan <haitao.shan@intel.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@novell.com>
  Jan Beulich <jbeulich@suse.com>
  Jonathan Davies <jonathan.davies@citrix.com>
  juergen.gross@ts.fujitsu.com
  Keir Fraser <keir@xen.org>
  Liu, Jinsong <jinsong.liu@intel.com>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
  Philipp Hahn <hahn@univention.de>
  Shriram Rajagopalan <rshriram@cs.ubc.ca>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang2 <wei.wang2@amd.com>
  Xudong Hao <xudong.hao@intel.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               broken  
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               broken  
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          broken  
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 1493 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 08 05:27:58 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 Dec 2011 05:27:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYWVm-0001re-Ft; Thu, 08 Dec 2011 05:27:14 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RYWVl-0001rV-Cq
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 05:27:13 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1323321985!6015614!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTI0OA==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30068 invoked from network); 8 Dec 2011 05:26:25 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Dec 2011 05:26:25 -0000
X-IronPort-AV: E=Sophos;i="4.71,318,1320624000"; 
   d="scan'208";a="9353892"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Dec 2011 05:26:25 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 8 Dec 2011 05:26:25 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RYWUz-0007KT-0f;
	Thu, 08 Dec 2011 05:26:25 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RYWUy-0000yI-WE;
	Thu, 08 Dec 2011 05:26:25 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10424-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 8 Dec 2011 05:26:24 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10424: regressions - trouble:
	broken/fail/pass
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10424 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10424/

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-amd64-xl-win7-amd64  3 host-install(3)              broken
 test-amd64-i386-rhel6hvm-intel  3 host-install(3)              broken
 test-amd64-i386-win           3 host-install(3)              broken
 test-i386-i386-win            8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-i386-win-vcpus1    8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-amd64-win          8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-i386-xl-win-vcpus1  8 guest-saverestore        fail REGR. vs. 10201
 test-i386-i386-xl-win         8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-i386-xend-winxpsp3  3 host-install(3)              broken  in 10420
 test-amd64-i386-win          8 guest-saverestore fail in 10420 REGR. vs. 10201
 test-amd64-amd64-xl-win       3 host-install(3)              broken   in 10420
 test-amd64-i386-xl-win-vcpus1  3 host-install(3)              broken  in 10420
 test-amd64-amd64-xl-win      8 guest-saverestore fail in 10401 REGR. vs. 10201

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-credit2    7 debian-install              fail pass in 10420
 test-amd64-amd64-xl-win       7 windows-install             fail pass in 10401
 test-amd64-amd64-xl-sedf 14 guest-localmigrate/x10 fail in 10420 pass in 10424
 test-i386-i386-xl-win         7 windows-install    fail in 10420 pass in 10424
 test-amd64-amd64-xl-sedf     11 guest-localmigrate fail in 10401 pass in 10424
 test-amd64-i386-xl-win-vcpus1  7 windows-install   fail in 10401 pass in 10424

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install          fail never pass
 test-i386-i386-xl-winxpsp3    7 windows-install              fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xl-win7-amd64  7 windows-install              fail  never pass
 test-amd64-i386-xend-winxpsp3  7 windows-install              fail  never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   never pass
 test-amd64-amd64-xl-win7-amd64  7 windows-install     fail in 10420 never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2       fail in 10420 never pass

version targeted for testing:
 xen                  38eb74c01d9d
baseline version:
 xen                  62ff6a318c5d

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scanneel.ca>
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Andres Lagar-Cavilla <andres@lagarcavilla>
  Andrew Cooper <andrew.cooper3@citrix.com>
  Anthony PERARD <anthony.perard@citrix.com>
  Brendan Cully <brendan@cs.ubc.ca>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Haitao Shan <haitao.shan@intel.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@novell.com>
  Jan Beulich <jbeulich@suse.com>
  Jonathan Davies <jonathan.davies@citrix.com>
  juergen.gross@ts.fujitsu.com
  Keir Fraser <keir@xen.org>
  Liu, Jinsong <jinsong.liu@intel.com>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
  Philipp Hahn <hahn@univention.de>
  Shriram Rajagopalan <rshriram@cs.ubc.ca>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang2 <wei.wang2@amd.com>
  Xudong Hao <xudong.hao@intel.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               broken  
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               broken  
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          broken  
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 1493 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 08 07:47:39 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 Dec 2011 07:47:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYYhK-0003JE-S5; Thu, 08 Dec 2011 07:47:18 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RYYhJ-0003Gz-3E
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 07:47:17 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-14.tower-182.messagelabs.com!1323330388!6360861!1
X-Originating-IP: [208.97.132.119]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xMTkgPT4gMTYxMzc=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4325 invoked from network); 8 Dec 2011 07:46:28 -0000
Received: from caiajhbdcbbj.dreamhost.com (HELO homiemail-a20.g.dreamhost.com)
	(208.97.132.119) by server-14.tower-182.messagelabs.com with SMTP;
	8 Dec 2011 07:46:28 -0000
Received: from homiemail-a20.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTP id 138CA7EC078;
	Wed,  7 Dec 2011 23:46:28 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=Z769I2kUcfI23jsM+uSs56MwdwS1jv5qm5eJeZZPjtfp
	mKGz7WpHcHlxGfE5uXR8m5LotWAx0NkCpyHlPG9CmMj6bn/wd4FPxwG7sVNmFGyO
	SOJh7mXL2p/+1vUGqPEotUre7zXDCHsOQvD6PujpoQG6UFHu3SAzB1gnB/zmHA4=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=sSCjQwfdjSHjn5JFQN4vLBnRHPg=; b=KC8U5bnmCDk
	+vKS8GkaZfNjx4gevcGZ3oQFDAO8jfMQf0n5IyOhy0foul3I+R/52PXuEAyKmFBl
	Wj1z2wEBiCnXjgWBiEYYtN85Nuv1QLF3GUtk6szD9qxEIyUXpCSrq5W03sDq6Dvr
	LDBfGl+T+TdbxnsV19/fpHsvoz2Zvlb4=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTPSA id 371807EC061; 
	Wed,  7 Dec 2011 23:46:27 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 6ad4a8da105e97d81fbedd9dc05cc387a10562e9
Message-Id: <6ad4a8da105e97d81fbe.1323330441@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1323330435@xdev.gridcentric.ca>
References: <patchbomb.1323330435@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Thu, 08 Dec 2011 02:47:21 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: ian.campbell@citrix.com, andres@gridcentric.ca, tim@xen.org,
	keir.xen@gmail.com, JBeulich@suse.com, ian.jackson@citrix.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 06 of 18] Tools: Update libxc mem sharing
	interface
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 tools/libxc/xc_memshr.c |  19 ++++++++++++++++++-
 tools/libxc/xenctrl.h   |   7 ++++++-
 2 files changed, 24 insertions(+), 2 deletions(-)


Previosuly, the mem sharing code would return an opaque handle
to index shared pages (and nominees) in its global hash table.
By removing the hash table, the handle becomes a version, to
avoid sharing a stale version of a page. Thus, libxc wrappers
need to be updated accordingly.

Signed-off-by: Adin Scannell <adin@scannell.ca>
Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r b398fc97ab19 -r 6ad4a8da105e tools/libxc/xc_memshr.c
--- a/tools/libxc/xc_memshr.c
+++ b/tools/libxc/xc_memshr.c
@@ -88,8 +88,13 @@ int xc_memshr_nominate_gref(xc_interface
 
 int xc_memshr_share(xc_interface *xch,
                     uint32_t source_domain,
+                    uint64_t source_gfn,
                     uint64_t source_handle,
-                    uint64_t client_handle)
+                    int source_is_gref,
+                    uint32_t client_domain,
+                    uint64_t client_gfn,
+                    uint64_t client_handle,
+                    int client_is_gref)
 {
     DECLARE_DOMCTL;
     struct xen_domctl_mem_sharing_op *op;
@@ -100,8 +105,20 @@ int xc_memshr_share(xc_interface *xch,
     op = &(domctl.u.mem_sharing_op);
     op->op = XEN_DOMCTL_MEM_EVENT_OP_SHARING_SHARE;
     op->u.share.source_handle = source_handle;
+    op->u.share.client_domain = (uint64_t) client_domain;
     op->u.share.client_handle = client_handle;
 
+    if (source_is_gref)
+        XEN_DOMCTL_MEM_SHARING_FIELD_MAKE_GREF(
+                op->u.share.source_gfn, source_gfn);
+    else
+        op->u.share.source_gfn = source_gfn;
+    if (client_is_gref)
+        XEN_DOMCTL_MEM_SHARING_FIELD_MAKE_GREF(
+                op->u.share.client_gfn, client_gfn);
+    else
+        op->u.share.client_gfn = client_gfn;
+
     return do_domctl(xch, &domctl);
 }
 
diff -r b398fc97ab19 -r 6ad4a8da105e tools/libxc/xenctrl.h
--- a/tools/libxc/xenctrl.h
+++ b/tools/libxc/xenctrl.h
@@ -1893,8 +1893,13 @@ int xc_memshr_nominate_gref(xc_interface
                             uint64_t *handle);
 int xc_memshr_share(xc_interface *xch,
                     uint32_t source_domain,
+                    uint64_t source_gfn,
                     uint64_t source_handle,
-                    uint64_t client_handle);
+                    int source_is_gref,
+                    uint32_t client_domain,
+                    uint64_t client_gfn,
+                    uint64_t client_handle,
+                    int dest_is_gref);
 int xc_memshr_domain_resume(xc_interface *xch,
                             uint32_t domid);
 int xc_memshr_debug_gfn(xc_interface *xch,

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 08 07:47:39 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 Dec 2011 07:47:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYYhK-0003JE-S5; Thu, 08 Dec 2011 07:47:18 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RYYhJ-0003Gz-3E
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 07:47:17 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-14.tower-182.messagelabs.com!1323330388!6360861!1
X-Originating-IP: [208.97.132.119]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xMTkgPT4gMTYxMzc=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4325 invoked from network); 8 Dec 2011 07:46:28 -0000
Received: from caiajhbdcbbj.dreamhost.com (HELO homiemail-a20.g.dreamhost.com)
	(208.97.132.119) by server-14.tower-182.messagelabs.com with SMTP;
	8 Dec 2011 07:46:28 -0000
Received: from homiemail-a20.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTP id 138CA7EC078;
	Wed,  7 Dec 2011 23:46:28 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=Z769I2kUcfI23jsM+uSs56MwdwS1jv5qm5eJeZZPjtfp
	mKGz7WpHcHlxGfE5uXR8m5LotWAx0NkCpyHlPG9CmMj6bn/wd4FPxwG7sVNmFGyO
	SOJh7mXL2p/+1vUGqPEotUre7zXDCHsOQvD6PujpoQG6UFHu3SAzB1gnB/zmHA4=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=sSCjQwfdjSHjn5JFQN4vLBnRHPg=; b=KC8U5bnmCDk
	+vKS8GkaZfNjx4gevcGZ3oQFDAO8jfMQf0n5IyOhy0foul3I+R/52PXuEAyKmFBl
	Wj1z2wEBiCnXjgWBiEYYtN85Nuv1QLF3GUtk6szD9qxEIyUXpCSrq5W03sDq6Dvr
	LDBfGl+T+TdbxnsV19/fpHsvoz2Zvlb4=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTPSA id 371807EC061; 
	Wed,  7 Dec 2011 23:46:27 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 6ad4a8da105e97d81fbedd9dc05cc387a10562e9
Message-Id: <6ad4a8da105e97d81fbe.1323330441@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1323330435@xdev.gridcentric.ca>
References: <patchbomb.1323330435@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Thu, 08 Dec 2011 02:47:21 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: ian.campbell@citrix.com, andres@gridcentric.ca, tim@xen.org,
	keir.xen@gmail.com, JBeulich@suse.com, ian.jackson@citrix.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 06 of 18] Tools: Update libxc mem sharing
	interface
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 tools/libxc/xc_memshr.c |  19 ++++++++++++++++++-
 tools/libxc/xenctrl.h   |   7 ++++++-
 2 files changed, 24 insertions(+), 2 deletions(-)


Previosuly, the mem sharing code would return an opaque handle
to index shared pages (and nominees) in its global hash table.
By removing the hash table, the handle becomes a version, to
avoid sharing a stale version of a page. Thus, libxc wrappers
need to be updated accordingly.

Signed-off-by: Adin Scannell <adin@scannell.ca>
Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r b398fc97ab19 -r 6ad4a8da105e tools/libxc/xc_memshr.c
--- a/tools/libxc/xc_memshr.c
+++ b/tools/libxc/xc_memshr.c
@@ -88,8 +88,13 @@ int xc_memshr_nominate_gref(xc_interface
 
 int xc_memshr_share(xc_interface *xch,
                     uint32_t source_domain,
+                    uint64_t source_gfn,
                     uint64_t source_handle,
-                    uint64_t client_handle)
+                    int source_is_gref,
+                    uint32_t client_domain,
+                    uint64_t client_gfn,
+                    uint64_t client_handle,
+                    int client_is_gref)
 {
     DECLARE_DOMCTL;
     struct xen_domctl_mem_sharing_op *op;
@@ -100,8 +105,20 @@ int xc_memshr_share(xc_interface *xch,
     op = &(domctl.u.mem_sharing_op);
     op->op = XEN_DOMCTL_MEM_EVENT_OP_SHARING_SHARE;
     op->u.share.source_handle = source_handle;
+    op->u.share.client_domain = (uint64_t) client_domain;
     op->u.share.client_handle = client_handle;
 
+    if (source_is_gref)
+        XEN_DOMCTL_MEM_SHARING_FIELD_MAKE_GREF(
+                op->u.share.source_gfn, source_gfn);
+    else
+        op->u.share.source_gfn = source_gfn;
+    if (client_is_gref)
+        XEN_DOMCTL_MEM_SHARING_FIELD_MAKE_GREF(
+                op->u.share.client_gfn, client_gfn);
+    else
+        op->u.share.client_gfn = client_gfn;
+
     return do_domctl(xch, &domctl);
 }
 
diff -r b398fc97ab19 -r 6ad4a8da105e tools/libxc/xenctrl.h
--- a/tools/libxc/xenctrl.h
+++ b/tools/libxc/xenctrl.h
@@ -1893,8 +1893,13 @@ int xc_memshr_nominate_gref(xc_interface
                             uint64_t *handle);
 int xc_memshr_share(xc_interface *xch,
                     uint32_t source_domain,
+                    uint64_t source_gfn,
                     uint64_t source_handle,
-                    uint64_t client_handle);
+                    int source_is_gref,
+                    uint32_t client_domain,
+                    uint64_t client_gfn,
+                    uint64_t client_handle,
+                    int dest_is_gref);
 int xc_memshr_domain_resume(xc_interface *xch,
                             uint32_t domid);
 int xc_memshr_debug_gfn(xc_interface *xch,

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 08 07:47:39 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 Dec 2011 07:47:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYYhA-0003GP-Gy; Thu, 08 Dec 2011 07:47:08 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RYYh8-0003GH-V5
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 07:47:07 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-3.tower-27.messagelabs.com!1323330341!48147527!1
X-Originating-IP: [208.97.132.145]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNDUgPT4gMTY3OTU=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6626 invoked from network); 8 Dec 2011 07:45:41 -0000
Received: from caiajhbdcbef.dreamhost.com (HELO homiemail-a20.g.dreamhost.com)
	(208.97.132.145) by server-3.tower-27.messagelabs.com with SMTP;
	8 Dec 2011 07:45:41 -0000
Received: from homiemail-a20.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTP id D25347EC064;
	Wed,  7 Dec 2011 23:46:22 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=m2lxSQ/jg3KUsUsYeD5OM8LjSAD3slnyDtI48Hv1tCcS
	CaPLVYs8+amg88WXXRccl2D1hCYbyYSA5ho7x7dMeqLz0Hp3qfyWgnTxYwOhooM9
	9bgCGfMhhf/fUAgibr7s04R/uRsB22Rq8Wb8e/ROBp2AlL7cT3nJ54w1UZE/fsg=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=DpeM43UnNvT+mpiANNwuNlLHt48=; b=bq+0BhaYh/j
	gZ4rJjuBK2bLUlBLSwKsJtHp2iwmKbC7HS/5CM+fN898fGzSXjxOQaMzHANRhEFk
	h+eEgh7zk59K5+zmHlQj+EXZWXk+Dky4XjgPwMLj5OvU4rjhA4E47sOs/fWaPukk
	6n5O6xBI6DK/Xrj0rLZn399cRlwOspww=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTPSA id E37CB7EC061; 
	Wed,  7 Dec 2011 23:46:21 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: aeebbff899ffa2328e3f9c1c9ecfd9b960b2c197
Message-Id: <aeebbff899ffa2328e3f.1323330436@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1323330435@xdev.gridcentric.ca>
References: <patchbomb.1323330435@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Thu, 08 Dec 2011 02:47:16 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: ian.campbell@citrix.com, andres@gridcentric.ca, tim@xen.org,
	keir.xen@gmail.com, JBeulich@suse.com, ian.jackson@citrix.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 01 of 18] x86/mm: Code style fixes in
	mem_sharing.c
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/mm.c             |   6 +-
 xen/arch/x86/mm/mem_sharing.c |  91 ++++++++++++++++++++++--------------------
 2 files changed, 50 insertions(+), 47 deletions(-)


Harmless patch, with no functional changes, only code style issues.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 62c342fd7b9c -r aeebbff899ff xen/arch/x86/mm.c
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -4321,9 +4321,9 @@ int page_make_sharable(struct domain *d,
         return -EEXIST;
     }
 
-    /* Check if the ref count is 2. The first from PGT_allocated, and
+    /* Check if the ref count is 2. The first from PGC_allocated, and
      * the second from get_page_and_type at the top of this function */
-    if(page->count_info != (PGC_allocated | (2 + expected_refcnt)))
+    if ( page->count_info != (PGC_allocated | (2 + expected_refcnt)) )
     {
         /* Return type count back to zero */
         put_page_and_type(page);
@@ -4340,7 +4340,7 @@ int page_make_sharable(struct domain *d,
 
 int page_make_private(struct domain *d, struct page_info *page)
 {
-    if(!get_page(page, dom_cow))
+    if ( !get_page(page, dom_cow) )
         return -EINVAL;
     
     spin_lock(&d->page_alloc_lock);
diff -r 62c342fd7b9c -r aeebbff899ff xen/arch/x86/mm/mem_sharing.c
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -35,14 +35,14 @@
 #include "mm-locks.h"
 
 /* Auditing of memory sharing code? */
-#define MEM_SHARING_AUDIT  0
+#define MEM_SHARING_AUDIT 0
 
 #if MEM_SHARING_AUDIT
 static void mem_sharing_audit(void);
 #define MEM_SHARING_DEBUG(_f, _a...)                                  \
     debugtrace_printk("mem_sharing_debug: %s(): " _f, __func__, ##_a)
 #else
-# define mem_sharing_audit() do {} while(0)
+#define mem_sharing_audit() do {} while(0)
 #endif /* MEM_SHARING_AUDIT */
 
 #define mem_sharing_enabled(d) \
@@ -56,7 +56,7 @@ static void mem_sharing_audit(void);
 #define page_to_mfn(_pg) _mfn(__page_to_mfn(_pg))
 
 static shr_handle_t next_handle = 1;
-static atomic_t nr_saved_mfns = ATOMIC_INIT(0); 
+static atomic_t nr_saved_mfns   = ATOMIC_INIT(0); 
 
 typedef struct shr_hash_entry 
 {
@@ -84,9 +84,9 @@ static inline int list_has_one_entry(str
     return (head->next != head) && (head->next->next == head);
 }
 
-static inline struct gfn_info* gfn_get_info(struct list_head *list)
+static inline gfn_info_t *gfn_get_info(struct list_head *list)
 {
-    return list_entry(list->next, struct gfn_info, list);
+    return list_entry(list->next, gfn_info_t, list);
 }
 
 static void __init mem_sharing_hash_init(void)
@@ -116,12 +116,12 @@ static gfn_info_t *mem_sharing_gfn_alloc
 static void mem_sharing_gfn_destroy(gfn_info_t *gfn, int was_shared)
 {
     /* Decrement the number of pages, if the gfn was shared before */
-    if(was_shared)
+    if ( was_shared )
     {
         struct domain *d = get_domain_by_id(gfn->domain);
-        /* Domain may have been destroyed by now, if we are called from
-         * p2m_teardown */
-        if(d)
+        /* Domain may have been destroyed by now *
+         * (if we are called from p2m_teardown)  */
+        if ( d )
         {
             atomic_dec(&d->shr_pages);
             put_domain(d);
@@ -261,7 +261,8 @@ static struct page_info* mem_sharing_all
     mem_event_request_t req;
 
     page = alloc_domheap_page(d, 0); 
-    if(page != NULL) return page;
+    if ( page != NULL )
+        return page;
 
     memset(&req, 0, sizeof(req));
     req.type = MEM_EVENT_TYPE_SHARED;
@@ -301,7 +302,7 @@ static struct page_info* mem_sharing_all
 
 unsigned int mem_sharing_get_nr_saved_mfns(void)
 {
-    return (unsigned int)atomic_read(&nr_saved_mfns);
+    return ((unsigned int)atomic_read(&nr_saved_mfns));
 }
 
 int mem_sharing_sharing_resume(struct domain *d)
@@ -328,14 +329,15 @@ int mem_sharing_debug_mfn(unsigned long 
 {
     struct page_info *page;
 
-    if(!mfn_valid(_mfn(mfn)))
+    if ( !mfn_valid(_mfn(mfn)) )
     {
-        printk("Invalid MFN=%lx\n", mfn);
+        gdprintk(XENLOG_ERR, "Invalid MFN=%lx\n", mfn);
         return -1;
     }
     page = mfn_to_page(_mfn(mfn));
 
-    printk("Debug page: MFN=%lx is ci=%lx, ti=%lx, owner_id=%d\n",
+    gdprintk(XENLOG_DEBUG, 
+            "Debug page: MFN=%lx is ci=%lx, ti=%lx, owner_id=%d\n",
             mfn_x(page_to_mfn(page)), 
             page->count_info, 
             page->u.inuse.type_info,
@@ -351,9 +353,9 @@ int mem_sharing_debug_gfn(struct domain 
 
     mfn = get_gfn_unlocked(d, gfn, &p2mt);
 
-    printk("Debug for domain=%d, gfn=%lx, ", 
-            d->domain_id, 
-            gfn);
+    gdprintk(XENLOG_DEBUG, "Debug for domain=%d, gfn=%lx, ", 
+               d->domain_id, 
+               gfn);
     return mem_sharing_debug_mfn(mfn_x(mfn));
 }
 
@@ -370,8 +372,8 @@ int mem_sharing_debug_gfn(struct domain 
 static grant_entry_header_t *
 shared_entry_header(struct grant_table *t, grant_ref_t ref)
 {
-    ASSERT(t->gt_version != 0);
-    if (t->gt_version == 1)
+    ASSERT (t->gt_version != 0);
+    if ( t->gt_version == 1 )
         return (grant_entry_header_t*)&shared_entry_v1(t, ref);
     else
         return &shared_entry_v2(t, ref).hdr;
@@ -381,25 +383,23 @@ static int mem_sharing_gref_to_gfn(struc
                                    grant_ref_t ref, 
                                    unsigned long *gfn)
 {
-    if(d->grant_table->gt_version < 1)
+    if ( d->grant_table->gt_version < 1 )
         return -1;
 
-    if (d->grant_table->gt_version == 1) 
+    if ( d->grant_table->gt_version == 1 ) 
     {
         grant_entry_v1_t *sha1;
         sha1 = &shared_entry_v1(d->grant_table, ref);
         *gfn = sha1->frame;
-        return 0;
     } 
     else 
     {
         grant_entry_v2_t *sha2;
         sha2 = &shared_entry_v2(d->grant_table, ref);
         *gfn = sha2->full_page.frame;
-        return 0;
     }
  
-    return -2;
+    return 0;
 }
 
 /* Account for a GFN being shared/unshared.
@@ -439,20 +439,22 @@ int mem_sharing_debug_gref(struct domain
     uint16_t status;
     unsigned long gfn;
 
-    if(d->grant_table->gt_version < 1)
+    if ( d->grant_table->gt_version < 1 )
     {
-        printk("Asked to debug [dom=%d,gref=%d], but not yet inited.\n",
+        gdprintk(XENLOG_ERR, 
+                "Asked to debug [dom=%d,gref=%d], but not yet inited.\n",
                 d->domain_id, ref);
         return -1;
     }
-    mem_sharing_gref_to_gfn(d, ref, &gfn); 
+    (void)mem_sharing_gref_to_gfn(d, ref, &gfn); 
     shah = shared_entry_header(d->grant_table, ref);
-    if (d->grant_table->gt_version == 1) 
+    if ( d->grant_table->gt_version == 1 ) 
         status = shah->flags;
     else 
         status = status_entry(d->grant_table, ref);
     
-    printk("==> Grant [dom=%d,ref=%d], status=%x. ", 
+    gdprintk(XENLOG_DEBUG,
+            "==> Grant [dom=%d,ref=%d], status=%x. ", 
             d->domain_id, ref, status);
 
     return mem_sharing_debug_gfn(d, gfn); 
@@ -478,24 +480,24 @@ int mem_sharing_nominate_page(struct dom
 
     /* Check if mfn is valid */
     ret = -EINVAL;
-    if (!mfn_valid(mfn))
+    if ( !mfn_valid(mfn) )
         goto out;
 
     /* Return the handle if the page is already shared */
     page = mfn_to_page(mfn);
-    if (p2m_is_shared(p2mt)) {
+    if ( p2m_is_shared(p2mt) ) {
         *phandle = page->shr_handle;
         ret = 0;
         goto out;
     }
 
     /* Check p2m type */
-    if (!p2m_is_sharable(p2mt))
+    if ( !p2m_is_sharable(p2mt) )
         goto out;
 
     /* Try to convert the mfn to the sharable type */
     ret = page_make_sharable(d, page, expected_refcnt); 
-    if(ret) 
+    if ( ret ) 
         goto out;
 
     /* Create the handle */
@@ -512,7 +514,7 @@ int mem_sharing_nominate_page(struct dom
     }
 
     /* Change the p2m type */
-    if(p2m_change_type(d, gfn, p2mt, p2m_ram_shared) != p2mt) 
+    if ( p2m_change_type(d, gfn, p2mt, p2m_ram_shared) != p2mt ) 
     {
         /* This is unlikely, as the type must have changed since we've checked
          * it a few lines above.
@@ -618,7 +620,7 @@ int mem_sharing_unshare_page(struct doma
     mfn = get_gfn(d, gfn, &p2mt);
     
     /* Has someone already unshared it? */
-    if (!p2m_is_shared(p2mt)) {
+    if ( !p2m_is_shared(p2mt) ) {
         put_gfn(d, gfn);
         shr_unlock();
         return 0;
@@ -631,10 +633,11 @@ int mem_sharing_unshare_page(struct doma
     list_for_each(le, &hash_entry->gfns)
     {
         gfn_info = list_entry(le, struct gfn_info, list);
-        if((gfn_info->gfn == gfn) && (gfn_info->domain == d->domain_id))
+        if ( (gfn_info->gfn == gfn) && (gfn_info->domain == d->domain_id) )
             goto gfn_found;
     }
-    printk("Could not find gfn_info for shared gfn: %lx\n", gfn);
+    gdprintk(XENLOG_ERR, "Could not find gfn_info for shared gfn: "
+                            "%lx\n", gfn);
     BUG();
 gfn_found: 
     /* Delete gfn_info from the list, but hold on to it, until we've allocated
@@ -644,7 +647,7 @@ gfn_found:
 
     /* If the GFN is getting destroyed drop the references to MFN 
      * (possibly freeing the page), and exit early */
-    if(flags & MEM_SHARING_DESTROY_GFN)
+    if ( flags & MEM_SHARING_DESTROY_GFN )
     {
         mem_sharing_gfn_destroy(gfn_info, !last_gfn);
         if(last_gfn) 
@@ -702,8 +705,8 @@ private_page_found:
     else
         atomic_dec(&nr_saved_mfns);
 
-    if(p2m_change_type(d, gfn, p2m_ram_shared, p2m_ram_rw) != 
-                                                p2m_ram_shared) 
+    if ( p2m_change_type(d, gfn, p2m_ram_shared, p2m_ram_rw) != 
+                                                p2m_ram_shared ) 
     {
         printk("Could not change p2m type.\n");
         BUG();
@@ -740,7 +743,7 @@ int mem_sharing_domctl(struct domain *d,
         {
             unsigned long gfn = mec->u.nominate.u.gfn;
             shr_handle_t handle;
-            if(!mem_sharing_enabled(d))
+            if ( !mem_sharing_enabled(d) )
                 return -EINVAL;
             rc = mem_sharing_nominate_page(d, gfn, 0, &handle);
             mec->u.nominate.handle = handle;
@@ -753,9 +756,9 @@ int mem_sharing_domctl(struct domain *d,
             unsigned long gfn;
             shr_handle_t handle;
 
-            if(!mem_sharing_enabled(d))
+            if ( !mem_sharing_enabled(d) )
                 return -EINVAL;
-            if(mem_sharing_gref_to_gfn(d, gref, &gfn) < 0)
+            if ( mem_sharing_gref_to_gfn(d, gref, &gfn) < 0 )
                 return -EINVAL;
             rc = mem_sharing_nominate_page(d, gfn, 3, &handle);
             mec->u.nominate.handle = handle;
@@ -772,7 +775,7 @@ int mem_sharing_domctl(struct domain *d,
 
         case XEN_DOMCTL_MEM_EVENT_OP_SHARING_RESUME:
         {
-            if(!mem_sharing_enabled(d))
+            if ( !mem_sharing_enabled(d) )
                 return -EINVAL;
             rc = mem_sharing_sharing_resume(d);
         }

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 08 07:47:39 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 Dec 2011 07:47:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYYhA-0003GP-Gy; Thu, 08 Dec 2011 07:47:08 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RYYh8-0003GH-V5
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 07:47:07 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-3.tower-27.messagelabs.com!1323330341!48147527!1
X-Originating-IP: [208.97.132.145]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNDUgPT4gMTY3OTU=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6626 invoked from network); 8 Dec 2011 07:45:41 -0000
Received: from caiajhbdcbef.dreamhost.com (HELO homiemail-a20.g.dreamhost.com)
	(208.97.132.145) by server-3.tower-27.messagelabs.com with SMTP;
	8 Dec 2011 07:45:41 -0000
Received: from homiemail-a20.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTP id D25347EC064;
	Wed,  7 Dec 2011 23:46:22 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=m2lxSQ/jg3KUsUsYeD5OM8LjSAD3slnyDtI48Hv1tCcS
	CaPLVYs8+amg88WXXRccl2D1hCYbyYSA5ho7x7dMeqLz0Hp3qfyWgnTxYwOhooM9
	9bgCGfMhhf/fUAgibr7s04R/uRsB22Rq8Wb8e/ROBp2AlL7cT3nJ54w1UZE/fsg=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=DpeM43UnNvT+mpiANNwuNlLHt48=; b=bq+0BhaYh/j
	gZ4rJjuBK2bLUlBLSwKsJtHp2iwmKbC7HS/5CM+fN898fGzSXjxOQaMzHANRhEFk
	h+eEgh7zk59K5+zmHlQj+EXZWXk+Dky4XjgPwMLj5OvU4rjhA4E47sOs/fWaPukk
	6n5O6xBI6DK/Xrj0rLZn399cRlwOspww=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTPSA id E37CB7EC061; 
	Wed,  7 Dec 2011 23:46:21 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: aeebbff899ffa2328e3f9c1c9ecfd9b960b2c197
Message-Id: <aeebbff899ffa2328e3f.1323330436@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1323330435@xdev.gridcentric.ca>
References: <patchbomb.1323330435@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Thu, 08 Dec 2011 02:47:16 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: ian.campbell@citrix.com, andres@gridcentric.ca, tim@xen.org,
	keir.xen@gmail.com, JBeulich@suse.com, ian.jackson@citrix.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 01 of 18] x86/mm: Code style fixes in
	mem_sharing.c
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/mm.c             |   6 +-
 xen/arch/x86/mm/mem_sharing.c |  91 ++++++++++++++++++++++--------------------
 2 files changed, 50 insertions(+), 47 deletions(-)


Harmless patch, with no functional changes, only code style issues.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 62c342fd7b9c -r aeebbff899ff xen/arch/x86/mm.c
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -4321,9 +4321,9 @@ int page_make_sharable(struct domain *d,
         return -EEXIST;
     }
 
-    /* Check if the ref count is 2. The first from PGT_allocated, and
+    /* Check if the ref count is 2. The first from PGC_allocated, and
      * the second from get_page_and_type at the top of this function */
-    if(page->count_info != (PGC_allocated | (2 + expected_refcnt)))
+    if ( page->count_info != (PGC_allocated | (2 + expected_refcnt)) )
     {
         /* Return type count back to zero */
         put_page_and_type(page);
@@ -4340,7 +4340,7 @@ int page_make_sharable(struct domain *d,
 
 int page_make_private(struct domain *d, struct page_info *page)
 {
-    if(!get_page(page, dom_cow))
+    if ( !get_page(page, dom_cow) )
         return -EINVAL;
     
     spin_lock(&d->page_alloc_lock);
diff -r 62c342fd7b9c -r aeebbff899ff xen/arch/x86/mm/mem_sharing.c
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -35,14 +35,14 @@
 #include "mm-locks.h"
 
 /* Auditing of memory sharing code? */
-#define MEM_SHARING_AUDIT  0
+#define MEM_SHARING_AUDIT 0
 
 #if MEM_SHARING_AUDIT
 static void mem_sharing_audit(void);
 #define MEM_SHARING_DEBUG(_f, _a...)                                  \
     debugtrace_printk("mem_sharing_debug: %s(): " _f, __func__, ##_a)
 #else
-# define mem_sharing_audit() do {} while(0)
+#define mem_sharing_audit() do {} while(0)
 #endif /* MEM_SHARING_AUDIT */
 
 #define mem_sharing_enabled(d) \
@@ -56,7 +56,7 @@ static void mem_sharing_audit(void);
 #define page_to_mfn(_pg) _mfn(__page_to_mfn(_pg))
 
 static shr_handle_t next_handle = 1;
-static atomic_t nr_saved_mfns = ATOMIC_INIT(0); 
+static atomic_t nr_saved_mfns   = ATOMIC_INIT(0); 
 
 typedef struct shr_hash_entry 
 {
@@ -84,9 +84,9 @@ static inline int list_has_one_entry(str
     return (head->next != head) && (head->next->next == head);
 }
 
-static inline struct gfn_info* gfn_get_info(struct list_head *list)
+static inline gfn_info_t *gfn_get_info(struct list_head *list)
 {
-    return list_entry(list->next, struct gfn_info, list);
+    return list_entry(list->next, gfn_info_t, list);
 }
 
 static void __init mem_sharing_hash_init(void)
@@ -116,12 +116,12 @@ static gfn_info_t *mem_sharing_gfn_alloc
 static void mem_sharing_gfn_destroy(gfn_info_t *gfn, int was_shared)
 {
     /* Decrement the number of pages, if the gfn was shared before */
-    if(was_shared)
+    if ( was_shared )
     {
         struct domain *d = get_domain_by_id(gfn->domain);
-        /* Domain may have been destroyed by now, if we are called from
-         * p2m_teardown */
-        if(d)
+        /* Domain may have been destroyed by now *
+         * (if we are called from p2m_teardown)  */
+        if ( d )
         {
             atomic_dec(&d->shr_pages);
             put_domain(d);
@@ -261,7 +261,8 @@ static struct page_info* mem_sharing_all
     mem_event_request_t req;
 
     page = alloc_domheap_page(d, 0); 
-    if(page != NULL) return page;
+    if ( page != NULL )
+        return page;
 
     memset(&req, 0, sizeof(req));
     req.type = MEM_EVENT_TYPE_SHARED;
@@ -301,7 +302,7 @@ static struct page_info* mem_sharing_all
 
 unsigned int mem_sharing_get_nr_saved_mfns(void)
 {
-    return (unsigned int)atomic_read(&nr_saved_mfns);
+    return ((unsigned int)atomic_read(&nr_saved_mfns));
 }
 
 int mem_sharing_sharing_resume(struct domain *d)
@@ -328,14 +329,15 @@ int mem_sharing_debug_mfn(unsigned long 
 {
     struct page_info *page;
 
-    if(!mfn_valid(_mfn(mfn)))
+    if ( !mfn_valid(_mfn(mfn)) )
     {
-        printk("Invalid MFN=%lx\n", mfn);
+        gdprintk(XENLOG_ERR, "Invalid MFN=%lx\n", mfn);
         return -1;
     }
     page = mfn_to_page(_mfn(mfn));
 
-    printk("Debug page: MFN=%lx is ci=%lx, ti=%lx, owner_id=%d\n",
+    gdprintk(XENLOG_DEBUG, 
+            "Debug page: MFN=%lx is ci=%lx, ti=%lx, owner_id=%d\n",
             mfn_x(page_to_mfn(page)), 
             page->count_info, 
             page->u.inuse.type_info,
@@ -351,9 +353,9 @@ int mem_sharing_debug_gfn(struct domain 
 
     mfn = get_gfn_unlocked(d, gfn, &p2mt);
 
-    printk("Debug for domain=%d, gfn=%lx, ", 
-            d->domain_id, 
-            gfn);
+    gdprintk(XENLOG_DEBUG, "Debug for domain=%d, gfn=%lx, ", 
+               d->domain_id, 
+               gfn);
     return mem_sharing_debug_mfn(mfn_x(mfn));
 }
 
@@ -370,8 +372,8 @@ int mem_sharing_debug_gfn(struct domain 
 static grant_entry_header_t *
 shared_entry_header(struct grant_table *t, grant_ref_t ref)
 {
-    ASSERT(t->gt_version != 0);
-    if (t->gt_version == 1)
+    ASSERT (t->gt_version != 0);
+    if ( t->gt_version == 1 )
         return (grant_entry_header_t*)&shared_entry_v1(t, ref);
     else
         return &shared_entry_v2(t, ref).hdr;
@@ -381,25 +383,23 @@ static int mem_sharing_gref_to_gfn(struc
                                    grant_ref_t ref, 
                                    unsigned long *gfn)
 {
-    if(d->grant_table->gt_version < 1)
+    if ( d->grant_table->gt_version < 1 )
         return -1;
 
-    if (d->grant_table->gt_version == 1) 
+    if ( d->grant_table->gt_version == 1 ) 
     {
         grant_entry_v1_t *sha1;
         sha1 = &shared_entry_v1(d->grant_table, ref);
         *gfn = sha1->frame;
-        return 0;
     } 
     else 
     {
         grant_entry_v2_t *sha2;
         sha2 = &shared_entry_v2(d->grant_table, ref);
         *gfn = sha2->full_page.frame;
-        return 0;
     }
  
-    return -2;
+    return 0;
 }
 
 /* Account for a GFN being shared/unshared.
@@ -439,20 +439,22 @@ int mem_sharing_debug_gref(struct domain
     uint16_t status;
     unsigned long gfn;
 
-    if(d->grant_table->gt_version < 1)
+    if ( d->grant_table->gt_version < 1 )
     {
-        printk("Asked to debug [dom=%d,gref=%d], but not yet inited.\n",
+        gdprintk(XENLOG_ERR, 
+                "Asked to debug [dom=%d,gref=%d], but not yet inited.\n",
                 d->domain_id, ref);
         return -1;
     }
-    mem_sharing_gref_to_gfn(d, ref, &gfn); 
+    (void)mem_sharing_gref_to_gfn(d, ref, &gfn); 
     shah = shared_entry_header(d->grant_table, ref);
-    if (d->grant_table->gt_version == 1) 
+    if ( d->grant_table->gt_version == 1 ) 
         status = shah->flags;
     else 
         status = status_entry(d->grant_table, ref);
     
-    printk("==> Grant [dom=%d,ref=%d], status=%x. ", 
+    gdprintk(XENLOG_DEBUG,
+            "==> Grant [dom=%d,ref=%d], status=%x. ", 
             d->domain_id, ref, status);
 
     return mem_sharing_debug_gfn(d, gfn); 
@@ -478,24 +480,24 @@ int mem_sharing_nominate_page(struct dom
 
     /* Check if mfn is valid */
     ret = -EINVAL;
-    if (!mfn_valid(mfn))
+    if ( !mfn_valid(mfn) )
         goto out;
 
     /* Return the handle if the page is already shared */
     page = mfn_to_page(mfn);
-    if (p2m_is_shared(p2mt)) {
+    if ( p2m_is_shared(p2mt) ) {
         *phandle = page->shr_handle;
         ret = 0;
         goto out;
     }
 
     /* Check p2m type */
-    if (!p2m_is_sharable(p2mt))
+    if ( !p2m_is_sharable(p2mt) )
         goto out;
 
     /* Try to convert the mfn to the sharable type */
     ret = page_make_sharable(d, page, expected_refcnt); 
-    if(ret) 
+    if ( ret ) 
         goto out;
 
     /* Create the handle */
@@ -512,7 +514,7 @@ int mem_sharing_nominate_page(struct dom
     }
 
     /* Change the p2m type */
-    if(p2m_change_type(d, gfn, p2mt, p2m_ram_shared) != p2mt) 
+    if ( p2m_change_type(d, gfn, p2mt, p2m_ram_shared) != p2mt ) 
     {
         /* This is unlikely, as the type must have changed since we've checked
          * it a few lines above.
@@ -618,7 +620,7 @@ int mem_sharing_unshare_page(struct doma
     mfn = get_gfn(d, gfn, &p2mt);
     
     /* Has someone already unshared it? */
-    if (!p2m_is_shared(p2mt)) {
+    if ( !p2m_is_shared(p2mt) ) {
         put_gfn(d, gfn);
         shr_unlock();
         return 0;
@@ -631,10 +633,11 @@ int mem_sharing_unshare_page(struct doma
     list_for_each(le, &hash_entry->gfns)
     {
         gfn_info = list_entry(le, struct gfn_info, list);
-        if((gfn_info->gfn == gfn) && (gfn_info->domain == d->domain_id))
+        if ( (gfn_info->gfn == gfn) && (gfn_info->domain == d->domain_id) )
             goto gfn_found;
     }
-    printk("Could not find gfn_info for shared gfn: %lx\n", gfn);
+    gdprintk(XENLOG_ERR, "Could not find gfn_info for shared gfn: "
+                            "%lx\n", gfn);
     BUG();
 gfn_found: 
     /* Delete gfn_info from the list, but hold on to it, until we've allocated
@@ -644,7 +647,7 @@ gfn_found:
 
     /* If the GFN is getting destroyed drop the references to MFN 
      * (possibly freeing the page), and exit early */
-    if(flags & MEM_SHARING_DESTROY_GFN)
+    if ( flags & MEM_SHARING_DESTROY_GFN )
     {
         mem_sharing_gfn_destroy(gfn_info, !last_gfn);
         if(last_gfn) 
@@ -702,8 +705,8 @@ private_page_found:
     else
         atomic_dec(&nr_saved_mfns);
 
-    if(p2m_change_type(d, gfn, p2m_ram_shared, p2m_ram_rw) != 
-                                                p2m_ram_shared) 
+    if ( p2m_change_type(d, gfn, p2m_ram_shared, p2m_ram_rw) != 
+                                                p2m_ram_shared ) 
     {
         printk("Could not change p2m type.\n");
         BUG();
@@ -740,7 +743,7 @@ int mem_sharing_domctl(struct domain *d,
         {
             unsigned long gfn = mec->u.nominate.u.gfn;
             shr_handle_t handle;
-            if(!mem_sharing_enabled(d))
+            if ( !mem_sharing_enabled(d) )
                 return -EINVAL;
             rc = mem_sharing_nominate_page(d, gfn, 0, &handle);
             mec->u.nominate.handle = handle;
@@ -753,9 +756,9 @@ int mem_sharing_domctl(struct domain *d,
             unsigned long gfn;
             shr_handle_t handle;
 
-            if(!mem_sharing_enabled(d))
+            if ( !mem_sharing_enabled(d) )
                 return -EINVAL;
-            if(mem_sharing_gref_to_gfn(d, gref, &gfn) < 0)
+            if ( mem_sharing_gref_to_gfn(d, gref, &gfn) < 0 )
                 return -EINVAL;
             rc = mem_sharing_nominate_page(d, gfn, 3, &handle);
             mec->u.nominate.handle = handle;
@@ -772,7 +775,7 @@ int mem_sharing_domctl(struct domain *d,
 
         case XEN_DOMCTL_MEM_EVENT_OP_SHARING_RESUME:
         {
-            if(!mem_sharing_enabled(d))
+            if ( !mem_sharing_enabled(d) )
                 return -EINVAL;
             rc = mem_sharing_sharing_resume(d);
         }

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 08 07:47:39 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 Dec 2011 07:47:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYYhO-0003Kh-2G; Thu, 08 Dec 2011 07:47:22 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RYYhM-0003Hq-Hv
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 07:47:20 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-3.tower-182.messagelabs.com!1323330390!6379726!2
X-Originating-IP: [208.97.132.66]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi42NiA9PiAxNTkwOQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15930 invoked from network); 8 Dec 2011 07:46:32 -0000
Received: from caiajhbdcagg.dreamhost.com (HELO homiemail-a20.g.dreamhost.com)
	(208.97.132.66) by server-3.tower-182.messagelabs.com with SMTP;
	8 Dec 2011 07:46:32 -0000
Received: from homiemail-a20.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTP id 7C89F7EC065;
	Wed,  7 Dec 2011 23:46:32 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=R+iRICUC/BUx4E3noz1EWuSLsI1Hl8XJ32xCNdBgS/pj
	f0ndyqcmyeBLWOHRdeJ+Ix2R513VYemdK4PlfMSbTu3QqXdLxRXqd1C+EDsVilbd
	Sv/8ralwn13H+aE1LOmISiRTQIPad+79LAyRqNaBNb2slsWk6UMCCItFhxHtAjI=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=m3ZoIiPKCbIPUokrjKMAO0BEuQs=; b=t7JhLGMqYiU
	cX72acHXnW9Qa4RVZnefUUUJIzCLG91Qlsg/eEazotEEMPucPxT6RNvLjLrlcnbR
	qUVaLgxXp+m7HgYdJGrs814+BhMNg0B98HitKGeG/1jv801kcyFS8wSesMi9Xwy9
	ZK98IV2yuSZIzxZanzrCo5jrHUrlA9yI=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTPSA id AD3C67EC07E; 
	Wed,  7 Dec 2011 23:46:31 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 6f489a294a766492226950fcb31e735855bfafb0
Message-Id: <6f489a294a7664922269.1323330445@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1323330435@xdev.gridcentric.ca>
References: <patchbomb.1323330435@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Thu, 08 Dec 2011 02:47:25 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: ian.campbell@citrix.com, andres@gridcentric.ca, tim@xen.org,
	keir.xen@gmail.com, JBeulich@suse.com, ian.jackson@citrix.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 10 of 18] Tools: Expose to libxc the total
 number of shared frames and space saved
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 tools/libxc/xc_private.c |  10 ++++++++++
 tools/libxc/xenctrl.h    |   4 ++++
 2 files changed, 14 insertions(+), 0 deletions(-)


Signed-off-by: Adin Scannell <adin@scannell.ca>

diff -r 65b32b391373 -r 6f489a294a76 tools/libxc/xc_private.c
--- a/tools/libxc/xc_private.c
+++ b/tools/libxc/xc_private.c
@@ -533,6 +533,16 @@ long xc_maximum_ram_page(xc_interface *x
     return do_memory_op(xch, XENMEM_maximum_ram_page, NULL, 0);
 }
 
+long xc_sharing_freed_pages(xc_interface *xch)
+{
+    return do_memory_op(xch, XENMEM_get_sharing_freed_pages, NULL, 0);
+}
+
+long xc_sharing_used_frames(xc_interface *xch)
+{
+    return do_memory_op(xch, XENMEM_get_sharing_shared_pages, NULL, 0);
+}
+
 long long xc_domain_get_cpu_usage( xc_interface *xch, domid_t domid, int vcpu )
 {
     DECLARE_DOMCTL;
diff -r 65b32b391373 -r 6f489a294a76 tools/libxc/xenctrl.h
--- a/tools/libxc/xenctrl.h
+++ b/tools/libxc/xenctrl.h
@@ -1227,6 +1227,10 @@ int xc_mmuext_op(xc_interface *xch, stru
 /* System wide memory properties */
 long xc_maximum_ram_page(xc_interface *xch);
 
+long xc_sharing_freed_pages(xc_interface *xch);
+
+long xc_sharing_used_frames(xc_interface *xch);
+
 /* Get current total pages allocated to a domain. */
 long xc_get_tot_pages(xc_interface *xch, uint32_t domid);
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 08 07:47:39 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 Dec 2011 07:47:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYYhQ-0003MH-3s; Thu, 08 Dec 2011 07:47:24 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RYYhO-0003Ie-7m
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 07:47:22 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-9.tower-21.messagelabs.com!1323330393!1124717!1
X-Originating-IP: [208.97.132.177]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNzcgPT4gMTQ2NDA=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14770 invoked from network); 8 Dec 2011 07:46:34 -0000
Received: from caiajhbdcbhh.dreamhost.com (HELO homiemail-a20.g.dreamhost.com)
	(208.97.132.177) by server-9.tower-21.messagelabs.com with SMTP;
	8 Dec 2011 07:46:34 -0000
Received: from homiemail-a20.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTP id 78AB17EC064;
	Wed,  7 Dec 2011 23:46:33 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=s9TC7ZcNf+gYSEr9rckiEhnKSVu7tRDQ8Z2cK7Pu1zvc
	ObH8auBnpSt1phIK8tHFRZptuQBt1T4rRsRm9KbEH7QAsm3R+VegsYsQ8mJM4Y22
	v+ZOP9GvUl8YGKP/kkCMUBFfhBCmrm0DB/olBiMBQRAonL2s9s9nAwYwhCNkm6k=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=Pq1Ejagb8DzzJqjsW5d8Ge/kLlI=; b=MfHaBmbFwmv
	Lb8T/EiwtQ0QMuxR5i3WTkIkyX8dtTIN8GlS+X/MrTVOhv36mCf9Nv3X4hTeYx/O
	Shjfj3lOJDeBUGiPiUdp1faa2Q/A0q53hTMhIMVRGjgEEfJSaEkHrzdiI/L8Lc7e
	DTaL4J8uvIq0E/6th4kbc0w/JoJnq8JI=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTPSA id A971E7EC063; 
	Wed,  7 Dec 2011 23:46:32 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: cde3529132c144e9788f2039126f7384694311eb
Message-Id: <cde3529132c144e9788f.1323330446@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1323330435@xdev.gridcentric.ca>
References: <patchbomb.1323330435@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Thu, 08 Dec 2011 02:47:26 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: ian.campbell@citrix.com, andres@gridcentric.ca, tim@xen.org,
	keir.xen@gmail.com, JBeulich@suse.com, ian.jackson@citrix.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 11 of 18] Tools: Allow libxl/xl to expose the
 total number of shared frames and space saved
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 tools/libxl/Makefile     |   2 +-
 tools/libxl/xl_cmdimpl.c |  13 ++++++++++---
 2 files changed, 11 insertions(+), 4 deletions(-)


Signed-off-by: Adin Scannell <adin@scannell.ca>

diff -r 6f489a294a76 -r cde3529132c1 tools/libxl/Makefile
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -89,7 +89,7 @@ libxl_internal.h: _libxl_types_internal.
 libxl_internal_json.h: _libxl_types_internal_json.h
 
 $(LIBXL_OBJS) $(LIBXLU_OBJS) $(XL_OBJS): libxl.h
-$(LIBXL_OBJS): libxl_internal.h
+$(LIBXL_OBJS) $(XL_OBJS): libxl_internal.h
 
 _libxl_type%.h _libxl_type%_json.h _libxl_type%.c: libxl_type%.idl gentypes.py libxltypes.py
 	$(PYTHON) gentypes.py libxl_type$*.idl __libxl_type$*.h __libxl_type$*_json.h __libxl_type$*.c
diff -r 6f489a294a76 -r cde3529132c1 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -38,6 +38,7 @@
 
 #include "libxl.h"
 #include "libxl_utils.h"
+#include "libxl_internal.h"
 #include "libxlutil.h"
 #include "xl.h"
 
@@ -3758,6 +3759,7 @@ int main_info(int argc, char **argv)
 static void sharing(int totals, const libxl_dominfo *info, int nb_domain)
 {
     int i;
+    const libxl_version_info *vinfo;
 
     printf("Name                                        ID   Mem Shared\n");
 
@@ -3774,9 +3776,14 @@ static void sharing(int totals, const li
         free(domname);
     }
 
-    if (totals)
-    {
-        /* To be added with a future patch. */
+    if (totals) {
+        vinfo = libxl_get_version_info(ctx);
+        if (vinfo) {
+            i = (1 << 20) / vinfo->pagesize;
+            printf("Freed with sharing: %ld  Total physical shared: %ld\n", 
+            xc_sharing_freed_pages(ctx->xch) / i,
+            xc_sharing_used_frames(ctx->xch) / i);
+        }
     }
 }
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 08 07:47:39 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 Dec 2011 07:47:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYYhO-0003Kh-2G; Thu, 08 Dec 2011 07:47:22 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RYYhM-0003Hq-Hv
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 07:47:20 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-3.tower-182.messagelabs.com!1323330390!6379726!2
X-Originating-IP: [208.97.132.66]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi42NiA9PiAxNTkwOQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15930 invoked from network); 8 Dec 2011 07:46:32 -0000
Received: from caiajhbdcagg.dreamhost.com (HELO homiemail-a20.g.dreamhost.com)
	(208.97.132.66) by server-3.tower-182.messagelabs.com with SMTP;
	8 Dec 2011 07:46:32 -0000
Received: from homiemail-a20.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTP id 7C89F7EC065;
	Wed,  7 Dec 2011 23:46:32 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=R+iRICUC/BUx4E3noz1EWuSLsI1Hl8XJ32xCNdBgS/pj
	f0ndyqcmyeBLWOHRdeJ+Ix2R513VYemdK4PlfMSbTu3QqXdLxRXqd1C+EDsVilbd
	Sv/8ralwn13H+aE1LOmISiRTQIPad+79LAyRqNaBNb2slsWk6UMCCItFhxHtAjI=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=m3ZoIiPKCbIPUokrjKMAO0BEuQs=; b=t7JhLGMqYiU
	cX72acHXnW9Qa4RVZnefUUUJIzCLG91Qlsg/eEazotEEMPucPxT6RNvLjLrlcnbR
	qUVaLgxXp+m7HgYdJGrs814+BhMNg0B98HitKGeG/1jv801kcyFS8wSesMi9Xwy9
	ZK98IV2yuSZIzxZanzrCo5jrHUrlA9yI=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTPSA id AD3C67EC07E; 
	Wed,  7 Dec 2011 23:46:31 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 6f489a294a766492226950fcb31e735855bfafb0
Message-Id: <6f489a294a7664922269.1323330445@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1323330435@xdev.gridcentric.ca>
References: <patchbomb.1323330435@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Thu, 08 Dec 2011 02:47:25 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: ian.campbell@citrix.com, andres@gridcentric.ca, tim@xen.org,
	keir.xen@gmail.com, JBeulich@suse.com, ian.jackson@citrix.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 10 of 18] Tools: Expose to libxc the total
 number of shared frames and space saved
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 tools/libxc/xc_private.c |  10 ++++++++++
 tools/libxc/xenctrl.h    |   4 ++++
 2 files changed, 14 insertions(+), 0 deletions(-)


Signed-off-by: Adin Scannell <adin@scannell.ca>

diff -r 65b32b391373 -r 6f489a294a76 tools/libxc/xc_private.c
--- a/tools/libxc/xc_private.c
+++ b/tools/libxc/xc_private.c
@@ -533,6 +533,16 @@ long xc_maximum_ram_page(xc_interface *x
     return do_memory_op(xch, XENMEM_maximum_ram_page, NULL, 0);
 }
 
+long xc_sharing_freed_pages(xc_interface *xch)
+{
+    return do_memory_op(xch, XENMEM_get_sharing_freed_pages, NULL, 0);
+}
+
+long xc_sharing_used_frames(xc_interface *xch)
+{
+    return do_memory_op(xch, XENMEM_get_sharing_shared_pages, NULL, 0);
+}
+
 long long xc_domain_get_cpu_usage( xc_interface *xch, domid_t domid, int vcpu )
 {
     DECLARE_DOMCTL;
diff -r 65b32b391373 -r 6f489a294a76 tools/libxc/xenctrl.h
--- a/tools/libxc/xenctrl.h
+++ b/tools/libxc/xenctrl.h
@@ -1227,6 +1227,10 @@ int xc_mmuext_op(xc_interface *xch, stru
 /* System wide memory properties */
 long xc_maximum_ram_page(xc_interface *xch);
 
+long xc_sharing_freed_pages(xc_interface *xch);
+
+long xc_sharing_used_frames(xc_interface *xch);
+
 /* Get current total pages allocated to a domain. */
 long xc_get_tot_pages(xc_interface *xch, uint32_t domid);
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 08 07:47:39 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 Dec 2011 07:47:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYYhQ-0003MH-3s; Thu, 08 Dec 2011 07:47:24 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RYYhO-0003Ie-7m
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 07:47:22 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-9.tower-21.messagelabs.com!1323330393!1124717!1
X-Originating-IP: [208.97.132.177]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNzcgPT4gMTQ2NDA=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14770 invoked from network); 8 Dec 2011 07:46:34 -0000
Received: from caiajhbdcbhh.dreamhost.com (HELO homiemail-a20.g.dreamhost.com)
	(208.97.132.177) by server-9.tower-21.messagelabs.com with SMTP;
	8 Dec 2011 07:46:34 -0000
Received: from homiemail-a20.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTP id 78AB17EC064;
	Wed,  7 Dec 2011 23:46:33 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=s9TC7ZcNf+gYSEr9rckiEhnKSVu7tRDQ8Z2cK7Pu1zvc
	ObH8auBnpSt1phIK8tHFRZptuQBt1T4rRsRm9KbEH7QAsm3R+VegsYsQ8mJM4Y22
	v+ZOP9GvUl8YGKP/kkCMUBFfhBCmrm0DB/olBiMBQRAonL2s9s9nAwYwhCNkm6k=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=Pq1Ejagb8DzzJqjsW5d8Ge/kLlI=; b=MfHaBmbFwmv
	Lb8T/EiwtQ0QMuxR5i3WTkIkyX8dtTIN8GlS+X/MrTVOhv36mCf9Nv3X4hTeYx/O
	Shjfj3lOJDeBUGiPiUdp1faa2Q/A0q53hTMhIMVRGjgEEfJSaEkHrzdiI/L8Lc7e
	DTaL4J8uvIq0E/6th4kbc0w/JoJnq8JI=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTPSA id A971E7EC063; 
	Wed,  7 Dec 2011 23:46:32 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: cde3529132c144e9788f2039126f7384694311eb
Message-Id: <cde3529132c144e9788f.1323330446@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1323330435@xdev.gridcentric.ca>
References: <patchbomb.1323330435@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Thu, 08 Dec 2011 02:47:26 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: ian.campbell@citrix.com, andres@gridcentric.ca, tim@xen.org,
	keir.xen@gmail.com, JBeulich@suse.com, ian.jackson@citrix.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 11 of 18] Tools: Allow libxl/xl to expose the
 total number of shared frames and space saved
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 tools/libxl/Makefile     |   2 +-
 tools/libxl/xl_cmdimpl.c |  13 ++++++++++---
 2 files changed, 11 insertions(+), 4 deletions(-)


Signed-off-by: Adin Scannell <adin@scannell.ca>

diff -r 6f489a294a76 -r cde3529132c1 tools/libxl/Makefile
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -89,7 +89,7 @@ libxl_internal.h: _libxl_types_internal.
 libxl_internal_json.h: _libxl_types_internal_json.h
 
 $(LIBXL_OBJS) $(LIBXLU_OBJS) $(XL_OBJS): libxl.h
-$(LIBXL_OBJS): libxl_internal.h
+$(LIBXL_OBJS) $(XL_OBJS): libxl_internal.h
 
 _libxl_type%.h _libxl_type%_json.h _libxl_type%.c: libxl_type%.idl gentypes.py libxltypes.py
 	$(PYTHON) gentypes.py libxl_type$*.idl __libxl_type$*.h __libxl_type$*_json.h __libxl_type$*.c
diff -r 6f489a294a76 -r cde3529132c1 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -38,6 +38,7 @@
 
 #include "libxl.h"
 #include "libxl_utils.h"
+#include "libxl_internal.h"
 #include "libxlutil.h"
 #include "xl.h"
 
@@ -3758,6 +3759,7 @@ int main_info(int argc, char **argv)
 static void sharing(int totals, const libxl_dominfo *info, int nb_domain)
 {
     int i;
+    const libxl_version_info *vinfo;
 
     printf("Name                                        ID   Mem Shared\n");
 
@@ -3774,9 +3776,14 @@ static void sharing(int totals, const li
         free(domname);
     }
 
-    if (totals)
-    {
-        /* To be added with a future patch. */
+    if (totals) {
+        vinfo = libxl_get_version_info(ctx);
+        if (vinfo) {
+            i = (1 << 20) / vinfo->pagesize;
+            printf("Freed with sharing: %ld  Total physical shared: %ld\n", 
+            xc_sharing_freed_pages(ctx->xch) / i,
+            xc_sharing_used_frames(ctx->xch) / i);
+        }
     }
 }
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 08 07:47:39 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 Dec 2011 07:47:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYYhG-0003Hf-Ud; Thu, 08 Dec 2011 07:47:14 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RYYhF-0003H6-CY
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 07:47:13 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-14.tower-27.messagelabs.com!1323330266!47440326!1
X-Originating-IP: [208.97.132.5]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi41ID0+IDE1NDE2\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5875 invoked from network); 8 Dec 2011 07:44:27 -0000
Received: from mailbigip.dreamhost.com (HELO homiemail-a20.g.dreamhost.com)
	(208.97.132.5) by server-14.tower-27.messagelabs.com with SMTP;
	8 Dec 2011 07:44:27 -0000
Received: from homiemail-a20.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTP id 4228A7EC061;
	Wed,  7 Dec 2011 23:46:29 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=LhrBc9XtMtMn2DKO7FsAZenPhAPp/YreLobygLtSC6YH
	1S1xbM88XlpS7Xz/d+AThj6tRA70poCBjWA7YlkyewoSNzR3ECcZQz/YqcNmujS+
	2A08S7O95hFJgFXIyQxrzC2p2a+E7y10/naQMzlMHejeWqpNYNkppnCsS7uv9Jo=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=4gMCrPUOJrt1adkCYuO/C1752lY=; b=bs0KKs/xnOg
	Io4dXcfVKFaZZ1KcxEH25jLRJq0QXcE4N8RdZ+ysOimYt0jwpBLwNOs8eGMLBKjZ
	+LHteSkg1KSiAW4y/B+G/mqm2SbwX8kpA+QY3DlS8OWiAE6cpS9VRNujknSD/fbV
	zbFWbZqRWR47+q6r3atwoI50sNtW5gP8=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTPSA id 41FA97EC07A; 
	Wed,  7 Dec 2011 23:46:28 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 8d2a8094ace5c80f16858b5eab251ecc71b94f4f
Message-Id: <8d2a8094ace5c80f1685.1323330442@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1323330435@xdev.gridcentric.ca>
References: <patchbomb.1323330435@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Thu, 08 Dec 2011 02:47:22 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: ian.campbell@citrix.com, andres@gridcentric.ca, tim@xen.org,
	keir.xen@gmail.com, JBeulich@suse.com, ian.jackson@citrix.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 07 of 18] Tools: Update memshr tool to use new
	sharing API
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 tools/blktap2/drivers/Makefile        |   2 +-
 tools/blktap2/drivers/tapdisk-image.c |   2 +-
 tools/blktap2/drivers/tapdisk-vbd.c   |   6 +++---
 tools/blktap2/drivers/tapdisk.h       |   6 +++++-
 tools/memshr/bidir-daemon.c           |   4 ++++
 tools/memshr/bidir-hash.h             |  13 ++++++++-----
 tools/memshr/interface.c              |  31 +++++++++++++++++++------------
 tools/memshr/memshr.h                 |  11 +++++++++--
 8 files changed, 50 insertions(+), 25 deletions(-)


The only (in-tree, that we know of) consumer of the mem sharing API
is the memshr tool (conditionally linked into blktap2). Update it to
use the new API.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 6ad4a8da105e -r 8d2a8094ace5 tools/blktap2/drivers/Makefile
--- a/tools/blktap2/drivers/Makefile
+++ b/tools/blktap2/drivers/Makefile
@@ -43,7 +43,7 @@ MEMSHR_DIR = $(XEN_ROOT)/tools/memshr
 MEMSHRLIBS :=
 ifeq ($(CONFIG_Linux), __fixme__)
 CFLAGS += -DMEMSHR
-MEMSHRLIBS += $(MEMSHR_DIR)/libmemshr.a
+MEMSHRLIBS += -L$(XEN_ROOT)/tools/libxc -lxenctrl $(MEMSHR_DIR)/libmemshr.a
 endif
 
 ifeq ($(VHD_STATIC),y)
diff -r 6ad4a8da105e -r 8d2a8094ace5 tools/blktap2/drivers/tapdisk-image.c
--- a/tools/blktap2/drivers/tapdisk-image.c
+++ b/tools/blktap2/drivers/tapdisk-image.c
@@ -60,7 +60,7 @@ tapdisk_image_allocate(const char *file,
 	image->storage   = storage;
 	image->private   = private;
 #ifdef MEMSHR
-	image->memshr_id = memshr_vbd_image_get(file);
+	image->memshr_id = memshr_vbd_image_get((char *)file);
 #endif
 	INIT_LIST_HEAD(&image->next);
 
diff -r 6ad4a8da105e -r 8d2a8094ace5 tools/blktap2/drivers/tapdisk-vbd.c
--- a/tools/blktap2/drivers/tapdisk-vbd.c
+++ b/tools/blktap2/drivers/tapdisk-vbd.c
@@ -1218,14 +1218,14 @@ __tapdisk_vbd_complete_td_request(td_vbd
 #ifdef MEMSHR
 		if (treq.op == TD_OP_READ
 		   && td_flag_test(image->flags, TD_OPEN_RDONLY)) {
-			uint64_t hnd  = treq.memshr_hnd;
+			share_tuple_t hnd = treq.memshr_hnd;
 			uint16_t uid  = image->memshr_id;
 			blkif_request_t *breq = &vreq->req;
 			uint64_t sec  = tapdisk_vbd_breq_get_sector(breq, treq);
 			int secs = breq->seg[treq.sidx].last_sect -
 			    breq->seg[treq.sidx].first_sect + 1;
 
-			if (hnd != 0)
+			if (hnd.handle != 0)
 				memshr_vbd_complete_ro_request(hnd, uid,
 								sec, secs);
 		}
@@ -1297,7 +1297,7 @@ __tapdisk_vbd_reissue_td_request(td_vbd_
 				/* Reset memshr handle. This'll prevent
 				 * memshr_vbd_complete_ro_request being called
 				 */
-				treq.memshr_hnd = 0;
+				treq.memshr_hnd.handle = 0;
 				td_complete_request(treq, 0);
 			} else
 				td_queue_read(parent, treq);
diff -r 6ad4a8da105e -r 8d2a8094ace5 tools/blktap2/drivers/tapdisk.h
--- a/tools/blktap2/drivers/tapdisk.h
+++ b/tools/blktap2/drivers/tapdisk.h
@@ -64,6 +64,10 @@
 #include "tapdisk-log.h"
 #include "tapdisk-utils.h"
 
+#ifdef MEMSHR
+#include "memshr.h"
+#endif
+
 #define DPRINTF(_f, _a...)           syslog(LOG_INFO, _f, ##_a)
 #define EPRINTF(_f, _a...)           syslog(LOG_ERR, "tap-err:%s: " _f, __func__, ##_a)
 #define PERROR(_f, _a...)            EPRINTF(_f ": %s", ##_a, strerror(errno))
@@ -136,7 +140,7 @@ struct td_request {
 	void                        *private;
     
 #ifdef MEMSHR
-	uint64_t                     memshr_hnd;
+	share_tuple_t                memshr_hnd;
 #endif
 };
 
diff -r 6ad4a8da105e -r 8d2a8094ace5 tools/memshr/bidir-daemon.c
--- a/tools/memshr/bidir-daemon.c
+++ b/tools/memshr/bidir-daemon.c
@@ -48,7 +48,11 @@ void* bidir_daemon(void *unused)
             to_remove = 0.1 * max_nr_ent; 
             while(to_remove > 0) 
             {
+#if 0
                 ret = blockshr_shrhnd_remove(blks_hash, next_remove, NULL);
+#else
+                ret = -1;
+#endif
                 if(ret < 0)
                 {
                     /* We failed to remove an entry, because of a serious hash
diff -r 6ad4a8da105e -r 8d2a8094ace5 tools/memshr/bidir-hash.h
--- a/tools/memshr/bidir-hash.h
+++ b/tools/memshr/bidir-hash.h
@@ -81,15 +81,16 @@ static int fgprtshr_mfn_cmp(uint32_t m1,
 #undef BIDIR_VALUE
 #undef BIDIR_KEY_T
 #undef BIDIR_VALUE_T
+
 /* TODO better hashes! */
 static inline uint32_t blockshr_block_hash(vbdblk_t block)
 {
     return (uint32_t)(block.sec) ^ (uint32_t)(block.disk_id);
 }
 
-static inline uint32_t blockshr_shrhnd_hash(uint64_t shrhnd)
+static inline uint32_t blockshr_shrhnd_hash(share_tuple_t shrhnd)
 {
-    return (uint32_t)shrhnd;
+    return ((uint32_t) shrhnd.handle);
 }
 
 static inline int blockshr_block_cmp(vbdblk_t b1, vbdblk_t b2)
@@ -97,15 +98,17 @@ static inline int blockshr_block_cmp(vbd
     return (b1.sec == b2.sec) && (b1.disk_id == b2.disk_id);
 }
 
-static inline int blockshr_shrhnd_cmp(uint64_t h1, uint64_t h2)
+static inline int blockshr_shrhnd_cmp(share_tuple_t h1, share_tuple_t h2)
 {
-    return (h1 == h2);
+    return ( (h1.domain == h2.domain) &&
+             (h1.frame  == h2.frame) &&
+             (h1.handle == h2.handle) );
 }
 #define BIDIR_NAME_PREFIX       blockshr
 #define BIDIR_KEY               block
 #define BIDIR_VALUE             shrhnd
 #define BIDIR_KEY_T             vbdblk_t
-#define BIDIR_VALUE_T           uint64_t
+#define BIDIR_VALUE_T           share_tuple_t
 #include "bidir-namedefs.h"
 
 #endif /* BLOCK_MAP */
diff -r 6ad4a8da105e -r 8d2a8094ace5 tools/memshr/interface.c
--- a/tools/memshr/interface.c
+++ b/tools/memshr/interface.c
@@ -145,16 +145,17 @@ void memshr_vbd_image_put(uint16_t memsh
     
 int memshr_vbd_issue_ro_request(char *buf,
                                 grant_ref_t gref,
-                                uint16_t file_id, 
+                                uint16_t file_id,
                                 uint64_t sec, 
                                 int secs,
-                                uint64_t *hnd)
+                                share_tuple_t *hnd)
 {
     vbdblk_t blk;
-    uint64_t s_hnd, c_hnd;
+    share_tuple_t source_st, client_st;
+    uint64_t c_hnd;
     int ret;
 
-    *hnd = 0;
+    *hnd = (share_tuple_t){ 0, 0, 0 };
     if(!vbd_info.enabled) 
         return -1;
 
@@ -169,26 +170,31 @@ int memshr_vbd_issue_ro_request(char *bu
     /* If page couldn't be made sharable, we cannot do anything about it */
     if(ret != 0)
         return -3;
-    *hnd = c_hnd;
+
+    *(&client_st) = (share_tuple_t){ vbd_info.domid, gref, c_hnd };
+    *hnd = client_st;
 
     /* Check if we've read matching disk block previously */
     blk.sec     = sec;
     blk.disk_id = file_id;
-    if(blockshr_block_lookup(memshr.blks, blk, &s_hnd) > 0)
+    if(blockshr_block_lookup(memshr.blks, blk, &source_st) > 0)
     {
-        ret = xc_memshr_share(vbd_info.xc_handle, s_hnd, c_hnd);
+        ret = xc_memshr_share(vbd_info.xc_handle, source_st.domain, source_st.frame, 1, 
+                                source_st.handle, vbd_info.domid, gref, c_hnd, 1);
         if(!ret) return 0;
         /* Handles failed to be shared => at least one of them must be invalid,
            remove the relevant ones from the map */
         switch(ret)
         {
             case XEN_DOMCTL_MEM_SHARING_S_HANDLE_INVALID:
-                ret = blockshr_shrhnd_remove(memshr.blks, s_hnd, NULL);
-                if(ret) DPRINTF("Could not rm invl s_hnd: %"PRId64"\n", s_hnd);
+                ret = blockshr_shrhnd_remove(memshr.blks, source_st, NULL);
+                if(ret) DPRINTF("Could not rm invl s_hnd: %u %"PRId64" %"PRId64"\n", 
+                                    source_st.domain, source_st.frame, source_st.handle);
                 break;
             case XEN_DOMCTL_MEM_SHARING_C_HANDLE_INVALID:
-                ret = blockshr_shrhnd_remove(memshr.blks, c_hnd, NULL);
-                if(ret) DPRINTF("Could not rm invl c_hnd: %"PRId64"\n", c_hnd);
+                ret = blockshr_shrhnd_remove(memshr.blks, client_st, NULL);
+                if(ret) DPRINTF("Could not rm invl c_hnd: %u %"PRId64" %"PRId64"\n", 
+                                    client_st.domain, client_st.frame, client_st.handle);
                 break;
             default:
                 break;
@@ -199,12 +205,13 @@ int memshr_vbd_issue_ro_request(char *bu
     return -4;
 }
 
-void memshr_vbd_complete_ro_request(uint64_t hnd,
+void memshr_vbd_complete_ro_request(share_tuple_t hnd,
                                     uint16_t file_id, 
                                     uint64_t sec, 
                                     int secs)
 {
     vbdblk_t blk;
+    share_tuple_t shr_tuple;
     
     if(!vbd_info.enabled) 
         return;
diff -r 6ad4a8da105e -r 8d2a8094ace5 tools/memshr/memshr.h
--- a/tools/memshr/memshr.h
+++ b/tools/memshr/memshr.h
@@ -25,6 +25,13 @@
 
 typedef uint64_t xen_mfn_t;
 
+typedef struct share_tuple 
+{
+    uint32_t domain;
+    uint64_t frame;
+    uint64_t handle;
+} share_tuple_t;
+
 extern void memshr_set_domid(int domid);
 extern void memshr_daemon_initialize(void);
 extern void memshr_vbd_initialize(void);
@@ -35,9 +42,9 @@ extern int memshr_vbd_issue_ro_request(c
                                        uint16_t file_id, 
                                        uint64_t sec, 
                                        int secs,
-                                       uint64_t *hnd);
+                                       share_tuple_t *hnd);
 extern void memshr_vbd_complete_ro_request(
-                                       uint64_t hnd,
+                                       share_tuple_t hnd,
                                        uint16_t file_id, 
                                        uint64_t sec, 
                                        int secs);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 08 07:47:39 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 Dec 2011 07:47:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYYhG-0003Hf-Ud; Thu, 08 Dec 2011 07:47:14 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RYYhF-0003H6-CY
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 07:47:13 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-14.tower-27.messagelabs.com!1323330266!47440326!1
X-Originating-IP: [208.97.132.5]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi41ID0+IDE1NDE2\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5875 invoked from network); 8 Dec 2011 07:44:27 -0000
Received: from mailbigip.dreamhost.com (HELO homiemail-a20.g.dreamhost.com)
	(208.97.132.5) by server-14.tower-27.messagelabs.com with SMTP;
	8 Dec 2011 07:44:27 -0000
Received: from homiemail-a20.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTP id 4228A7EC061;
	Wed,  7 Dec 2011 23:46:29 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=LhrBc9XtMtMn2DKO7FsAZenPhAPp/YreLobygLtSC6YH
	1S1xbM88XlpS7Xz/d+AThj6tRA70poCBjWA7YlkyewoSNzR3ECcZQz/YqcNmujS+
	2A08S7O95hFJgFXIyQxrzC2p2a+E7y10/naQMzlMHejeWqpNYNkppnCsS7uv9Jo=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=4gMCrPUOJrt1adkCYuO/C1752lY=; b=bs0KKs/xnOg
	Io4dXcfVKFaZZ1KcxEH25jLRJq0QXcE4N8RdZ+ysOimYt0jwpBLwNOs8eGMLBKjZ
	+LHteSkg1KSiAW4y/B+G/mqm2SbwX8kpA+QY3DlS8OWiAE6cpS9VRNujknSD/fbV
	zbFWbZqRWR47+q6r3atwoI50sNtW5gP8=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTPSA id 41FA97EC07A; 
	Wed,  7 Dec 2011 23:46:28 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 8d2a8094ace5c80f16858b5eab251ecc71b94f4f
Message-Id: <8d2a8094ace5c80f1685.1323330442@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1323330435@xdev.gridcentric.ca>
References: <patchbomb.1323330435@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Thu, 08 Dec 2011 02:47:22 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: ian.campbell@citrix.com, andres@gridcentric.ca, tim@xen.org,
	keir.xen@gmail.com, JBeulich@suse.com, ian.jackson@citrix.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 07 of 18] Tools: Update memshr tool to use new
	sharing API
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 tools/blktap2/drivers/Makefile        |   2 +-
 tools/blktap2/drivers/tapdisk-image.c |   2 +-
 tools/blktap2/drivers/tapdisk-vbd.c   |   6 +++---
 tools/blktap2/drivers/tapdisk.h       |   6 +++++-
 tools/memshr/bidir-daemon.c           |   4 ++++
 tools/memshr/bidir-hash.h             |  13 ++++++++-----
 tools/memshr/interface.c              |  31 +++++++++++++++++++------------
 tools/memshr/memshr.h                 |  11 +++++++++--
 8 files changed, 50 insertions(+), 25 deletions(-)


The only (in-tree, that we know of) consumer of the mem sharing API
is the memshr tool (conditionally linked into blktap2). Update it to
use the new API.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 6ad4a8da105e -r 8d2a8094ace5 tools/blktap2/drivers/Makefile
--- a/tools/blktap2/drivers/Makefile
+++ b/tools/blktap2/drivers/Makefile
@@ -43,7 +43,7 @@ MEMSHR_DIR = $(XEN_ROOT)/tools/memshr
 MEMSHRLIBS :=
 ifeq ($(CONFIG_Linux), __fixme__)
 CFLAGS += -DMEMSHR
-MEMSHRLIBS += $(MEMSHR_DIR)/libmemshr.a
+MEMSHRLIBS += -L$(XEN_ROOT)/tools/libxc -lxenctrl $(MEMSHR_DIR)/libmemshr.a
 endif
 
 ifeq ($(VHD_STATIC),y)
diff -r 6ad4a8da105e -r 8d2a8094ace5 tools/blktap2/drivers/tapdisk-image.c
--- a/tools/blktap2/drivers/tapdisk-image.c
+++ b/tools/blktap2/drivers/tapdisk-image.c
@@ -60,7 +60,7 @@ tapdisk_image_allocate(const char *file,
 	image->storage   = storage;
 	image->private   = private;
 #ifdef MEMSHR
-	image->memshr_id = memshr_vbd_image_get(file);
+	image->memshr_id = memshr_vbd_image_get((char *)file);
 #endif
 	INIT_LIST_HEAD(&image->next);
 
diff -r 6ad4a8da105e -r 8d2a8094ace5 tools/blktap2/drivers/tapdisk-vbd.c
--- a/tools/blktap2/drivers/tapdisk-vbd.c
+++ b/tools/blktap2/drivers/tapdisk-vbd.c
@@ -1218,14 +1218,14 @@ __tapdisk_vbd_complete_td_request(td_vbd
 #ifdef MEMSHR
 		if (treq.op == TD_OP_READ
 		   && td_flag_test(image->flags, TD_OPEN_RDONLY)) {
-			uint64_t hnd  = treq.memshr_hnd;
+			share_tuple_t hnd = treq.memshr_hnd;
 			uint16_t uid  = image->memshr_id;
 			blkif_request_t *breq = &vreq->req;
 			uint64_t sec  = tapdisk_vbd_breq_get_sector(breq, treq);
 			int secs = breq->seg[treq.sidx].last_sect -
 			    breq->seg[treq.sidx].first_sect + 1;
 
-			if (hnd != 0)
+			if (hnd.handle != 0)
 				memshr_vbd_complete_ro_request(hnd, uid,
 								sec, secs);
 		}
@@ -1297,7 +1297,7 @@ __tapdisk_vbd_reissue_td_request(td_vbd_
 				/* Reset memshr handle. This'll prevent
 				 * memshr_vbd_complete_ro_request being called
 				 */
-				treq.memshr_hnd = 0;
+				treq.memshr_hnd.handle = 0;
 				td_complete_request(treq, 0);
 			} else
 				td_queue_read(parent, treq);
diff -r 6ad4a8da105e -r 8d2a8094ace5 tools/blktap2/drivers/tapdisk.h
--- a/tools/blktap2/drivers/tapdisk.h
+++ b/tools/blktap2/drivers/tapdisk.h
@@ -64,6 +64,10 @@
 #include "tapdisk-log.h"
 #include "tapdisk-utils.h"
 
+#ifdef MEMSHR
+#include "memshr.h"
+#endif
+
 #define DPRINTF(_f, _a...)           syslog(LOG_INFO, _f, ##_a)
 #define EPRINTF(_f, _a...)           syslog(LOG_ERR, "tap-err:%s: " _f, __func__, ##_a)
 #define PERROR(_f, _a...)            EPRINTF(_f ": %s", ##_a, strerror(errno))
@@ -136,7 +140,7 @@ struct td_request {
 	void                        *private;
     
 #ifdef MEMSHR
-	uint64_t                     memshr_hnd;
+	share_tuple_t                memshr_hnd;
 #endif
 };
 
diff -r 6ad4a8da105e -r 8d2a8094ace5 tools/memshr/bidir-daemon.c
--- a/tools/memshr/bidir-daemon.c
+++ b/tools/memshr/bidir-daemon.c
@@ -48,7 +48,11 @@ void* bidir_daemon(void *unused)
             to_remove = 0.1 * max_nr_ent; 
             while(to_remove > 0) 
             {
+#if 0
                 ret = blockshr_shrhnd_remove(blks_hash, next_remove, NULL);
+#else
+                ret = -1;
+#endif
                 if(ret < 0)
                 {
                     /* We failed to remove an entry, because of a serious hash
diff -r 6ad4a8da105e -r 8d2a8094ace5 tools/memshr/bidir-hash.h
--- a/tools/memshr/bidir-hash.h
+++ b/tools/memshr/bidir-hash.h
@@ -81,15 +81,16 @@ static int fgprtshr_mfn_cmp(uint32_t m1,
 #undef BIDIR_VALUE
 #undef BIDIR_KEY_T
 #undef BIDIR_VALUE_T
+
 /* TODO better hashes! */
 static inline uint32_t blockshr_block_hash(vbdblk_t block)
 {
     return (uint32_t)(block.sec) ^ (uint32_t)(block.disk_id);
 }
 
-static inline uint32_t blockshr_shrhnd_hash(uint64_t shrhnd)
+static inline uint32_t blockshr_shrhnd_hash(share_tuple_t shrhnd)
 {
-    return (uint32_t)shrhnd;
+    return ((uint32_t) shrhnd.handle);
 }
 
 static inline int blockshr_block_cmp(vbdblk_t b1, vbdblk_t b2)
@@ -97,15 +98,17 @@ static inline int blockshr_block_cmp(vbd
     return (b1.sec == b2.sec) && (b1.disk_id == b2.disk_id);
 }
 
-static inline int blockshr_shrhnd_cmp(uint64_t h1, uint64_t h2)
+static inline int blockshr_shrhnd_cmp(share_tuple_t h1, share_tuple_t h2)
 {
-    return (h1 == h2);
+    return ( (h1.domain == h2.domain) &&
+             (h1.frame  == h2.frame) &&
+             (h1.handle == h2.handle) );
 }
 #define BIDIR_NAME_PREFIX       blockshr
 #define BIDIR_KEY               block
 #define BIDIR_VALUE             shrhnd
 #define BIDIR_KEY_T             vbdblk_t
-#define BIDIR_VALUE_T           uint64_t
+#define BIDIR_VALUE_T           share_tuple_t
 #include "bidir-namedefs.h"
 
 #endif /* BLOCK_MAP */
diff -r 6ad4a8da105e -r 8d2a8094ace5 tools/memshr/interface.c
--- a/tools/memshr/interface.c
+++ b/tools/memshr/interface.c
@@ -145,16 +145,17 @@ void memshr_vbd_image_put(uint16_t memsh
     
 int memshr_vbd_issue_ro_request(char *buf,
                                 grant_ref_t gref,
-                                uint16_t file_id, 
+                                uint16_t file_id,
                                 uint64_t sec, 
                                 int secs,
-                                uint64_t *hnd)
+                                share_tuple_t *hnd)
 {
     vbdblk_t blk;
-    uint64_t s_hnd, c_hnd;
+    share_tuple_t source_st, client_st;
+    uint64_t c_hnd;
     int ret;
 
-    *hnd = 0;
+    *hnd = (share_tuple_t){ 0, 0, 0 };
     if(!vbd_info.enabled) 
         return -1;
 
@@ -169,26 +170,31 @@ int memshr_vbd_issue_ro_request(char *bu
     /* If page couldn't be made sharable, we cannot do anything about it */
     if(ret != 0)
         return -3;
-    *hnd = c_hnd;
+
+    *(&client_st) = (share_tuple_t){ vbd_info.domid, gref, c_hnd };
+    *hnd = client_st;
 
     /* Check if we've read matching disk block previously */
     blk.sec     = sec;
     blk.disk_id = file_id;
-    if(blockshr_block_lookup(memshr.blks, blk, &s_hnd) > 0)
+    if(blockshr_block_lookup(memshr.blks, blk, &source_st) > 0)
     {
-        ret = xc_memshr_share(vbd_info.xc_handle, s_hnd, c_hnd);
+        ret = xc_memshr_share(vbd_info.xc_handle, source_st.domain, source_st.frame, 1, 
+                                source_st.handle, vbd_info.domid, gref, c_hnd, 1);
         if(!ret) return 0;
         /* Handles failed to be shared => at least one of them must be invalid,
            remove the relevant ones from the map */
         switch(ret)
         {
             case XEN_DOMCTL_MEM_SHARING_S_HANDLE_INVALID:
-                ret = blockshr_shrhnd_remove(memshr.blks, s_hnd, NULL);
-                if(ret) DPRINTF("Could not rm invl s_hnd: %"PRId64"\n", s_hnd);
+                ret = blockshr_shrhnd_remove(memshr.blks, source_st, NULL);
+                if(ret) DPRINTF("Could not rm invl s_hnd: %u %"PRId64" %"PRId64"\n", 
+                                    source_st.domain, source_st.frame, source_st.handle);
                 break;
             case XEN_DOMCTL_MEM_SHARING_C_HANDLE_INVALID:
-                ret = blockshr_shrhnd_remove(memshr.blks, c_hnd, NULL);
-                if(ret) DPRINTF("Could not rm invl c_hnd: %"PRId64"\n", c_hnd);
+                ret = blockshr_shrhnd_remove(memshr.blks, client_st, NULL);
+                if(ret) DPRINTF("Could not rm invl c_hnd: %u %"PRId64" %"PRId64"\n", 
+                                    client_st.domain, client_st.frame, client_st.handle);
                 break;
             default:
                 break;
@@ -199,12 +205,13 @@ int memshr_vbd_issue_ro_request(char *bu
     return -4;
 }
 
-void memshr_vbd_complete_ro_request(uint64_t hnd,
+void memshr_vbd_complete_ro_request(share_tuple_t hnd,
                                     uint16_t file_id, 
                                     uint64_t sec, 
                                     int secs)
 {
     vbdblk_t blk;
+    share_tuple_t shr_tuple;
     
     if(!vbd_info.enabled) 
         return;
diff -r 6ad4a8da105e -r 8d2a8094ace5 tools/memshr/memshr.h
--- a/tools/memshr/memshr.h
+++ b/tools/memshr/memshr.h
@@ -25,6 +25,13 @@
 
 typedef uint64_t xen_mfn_t;
 
+typedef struct share_tuple 
+{
+    uint32_t domain;
+    uint64_t frame;
+    uint64_t handle;
+} share_tuple_t;
+
 extern void memshr_set_domid(int domid);
 extern void memshr_daemon_initialize(void);
 extern void memshr_vbd_initialize(void);
@@ -35,9 +42,9 @@ extern int memshr_vbd_issue_ro_request(c
                                        uint16_t file_id, 
                                        uint64_t sec, 
                                        int secs,
-                                       uint64_t *hnd);
+                                       share_tuple_t *hnd);
 extern void memshr_vbd_complete_ro_request(
-                                       uint64_t hnd,
+                                       share_tuple_t hnd,
                                        uint16_t file_id, 
                                        uint64_t sec, 
                                        int secs);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 08 07:47:40 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 Dec 2011 07:47:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYYhH-0003Hw-C8; Thu, 08 Dec 2011 07:47:15 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RYYhF-0003GO-Kz
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 07:47:14 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-14.tower-182.messagelabs.com!1323330384!6360852!2
X-Originating-IP: [208.97.132.74]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi43NCA9PiAxNTI1Nw==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4170 invoked from network); 8 Dec 2011 07:46:25 -0000
Received: from caiajhbdcahe.dreamhost.com (HELO homiemail-a20.g.dreamhost.com)
	(208.97.132.74) by server-14.tower-182.messagelabs.com with SMTP;
	8 Dec 2011 07:46:25 -0000
Received: from homiemail-a20.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTP id E77487EC069;
	Wed,  7 Dec 2011 23:46:24 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=c+C9VISBuoB1AQYjNNQyvshxCHJK0EvITOJHsx3z+pXB
	8fs609CQCJhTd23u9/7WtQqPT+kxljD79hCQ6efh6pwBpqa3u2XUwySiFw3Ye4E4
	6kJJNBss3ZJA2rBf2e2fK63qJZc7JWk3nG2dJ8yuK1upikjoqcgHjDliGRSM1vA=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=TzrQOrIR4QFi258W+IH8Rkazg9M=; b=r7srf0qxXNh
	Z0a7saXok2sU0bynV+1QfMCJEynqYWEMY0O5Mw7mcv6rK2ua9UKaDS2Y9FdJAyYK
	Ciofa3EoQ/eabzXIF2rbAL9a7g5vK8yglY4XnP2W3BTX8UaeQeRlST7VPnuETruY
	Z3xdbz7eIsMfHG3vWt1UkbPNMHFojSNU=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTPSA id 0690E7EC061; 
	Wed,  7 Dec 2011 23:46:23 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 3038770886aa0654d73a62b22a82aa196c343595
Message-Id: <3038770886aa0654d73a.1323330438@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1323330435@xdev.gridcentric.ca>
References: <patchbomb.1323330435@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Thu, 08 Dec 2011 02:47:18 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: ian.campbell@citrix.com, andres@gridcentric.ca, tim@xen.org,
	keir.xen@gmail.com, JBeulich@suse.com, ian.jackson@citrix.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 03 of 18] x86/mm: Eliminate hash table in
 sharing code as index of shared mfns
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/mm/mem_sharing.c     |  526 +++++++++++++++++++------------------
 xen/include/asm-x86/mem_sharing.h |   15 +-
 xen/include/asm-x86/mm.h          |   11 +-
 xen/include/public/domctl.h       |    3 +
 4 files changed, 296 insertions(+), 259 deletions(-)


The hashtable mechanism used by the sharing code is a bit odd.  It seems
unnecessary and adds complexity.  Instead, we replace this by storing a list
head directly in the page info for the case when the page is shared.  This does
not add any extra space to the page_info and serves to remove significant
complexity from sharing.

Signed-off-by: Adin Scannell <adin@scannell.ca>
Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 61da3fc46f06 -r 3038770886aa xen/arch/x86/mm/mem_sharing.c
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -3,6 +3,7 @@
  *
  * Memory sharing support.
  *
+ * Copyright (c) 2011 GridCentric, Inc. (Adin Scannell & Andres Lagar-Cavilla)
  * Copyright (c) 2009 Citrix Systems, Inc. (Grzegorz Milos)
  *
  * This program is free software; you can redistribute it and/or modify
@@ -38,11 +39,28 @@
 #define MEM_SHARING_AUDIT 0
 
 #if MEM_SHARING_AUDIT
-static void mem_sharing_audit(void);
+static int mem_sharing_audit(void);
 #define MEM_SHARING_DEBUG(_f, _a...)                                  \
     debugtrace_printk("mem_sharing_debug: %s(): " _f, __func__, ##_a)
+static struct list_head shr_audit_list;
+
+static inline void audit_add_list(struct page_info *page)
+{
+    list_add(&page->shared_info->entry, &shr_audit_list);
+}
+
+static inline void audit_del_list(struct page_info *page)
+{
+    list_del(&page->shared_info->entry);
+}
 #else
-#define mem_sharing_audit() do {} while(0)
+static inline int mem_sharing_audit(void)
+{
+    return 0;
+}
+
+#define audit_add_list(p)  ((void)0)
+#define audit_del_list(p)  ((void)0)
 #endif /* MEM_SHARING_AUDIT */
 
 #define mem_sharing_enabled(d) \
@@ -58,17 +76,6 @@ static void mem_sharing_audit(void);
 static shr_handle_t next_handle = 1;
 static atomic_t nr_saved_mfns   = ATOMIC_INIT(0); 
 
-typedef struct shr_hash_entry 
-{
-    shr_handle_t handle;
-    mfn_t mfn; 
-    struct shr_hash_entry *next;
-    struct list_head gfns;
-} shr_hash_entry_t;
-
-#define SHR_HASH_LENGTH 1000
-static shr_hash_entry_t *shr_hash[SHR_HASH_LENGTH];
-
 typedef struct gfn_info
 {
     unsigned long gfn;
@@ -89,36 +96,30 @@ static inline gfn_info_t *gfn_get_info(s
     return list_entry(list->next, gfn_info_t, list);
 }
 
-static void __init mem_sharing_hash_init(void)
+static inline gfn_info_t *mem_sharing_gfn_alloc(struct page_info *page,
+                                         struct domain *d,
+                                         unsigned long gfn)
 {
-    int i;
+    gfn_info_t *gfn_info = xmalloc(gfn_info_t);
 
-    mm_lock_init(&shr_lock);
-    for(i=0; i<SHR_HASH_LENGTH; i++)
-        shr_hash[i] = NULL;
+    if ( gfn_info == NULL )
+        return NULL; 
+
+    gfn_info->gfn = gfn;
+    gfn_info->domain = d->domain_id;
+    INIT_LIST_HEAD(&gfn_info->list);
+    list_add(&gfn_info->list, &page->shared_info->gfns);
+
+    return gfn_info;
 }
 
-static shr_hash_entry_t *mem_sharing_hash_alloc(void)
-{
-    return xmalloc(shr_hash_entry_t); 
-}
-
-static void mem_sharing_hash_destroy(shr_hash_entry_t *e)
-{
-    xfree(e);
-}
-
-static gfn_info_t *mem_sharing_gfn_alloc(void)
-{
-    return xmalloc(gfn_info_t); 
-}
-
-static void mem_sharing_gfn_destroy(gfn_info_t *gfn, int was_shared)
+static inline void mem_sharing_gfn_destroy(gfn_info_t *gfn_info,
+                                    int was_shared)
 {
     /* Decrement the number of pages, if the gfn was shared before */
     if ( was_shared )
     {
-        struct domain *d = get_domain_by_id(gfn->domain);
+        struct domain *d = get_domain_by_id(gfn_info->domain);
         /* Domain may have been destroyed by now *
          * (if we are called from p2m_teardown)  */
         if ( d )
@@ -127,128 +128,118 @@ static void mem_sharing_gfn_destroy(gfn_
             put_domain(d);
         }
     }
-    xfree(gfn);
+
+    list_del(&gfn_info->list);
+    xfree(gfn_info);
 }
 
-static shr_hash_entry_t* mem_sharing_hash_lookup(shr_handle_t handle)
+static struct page_info* mem_sharing_lookup(unsigned long mfn)
 {
-    shr_hash_entry_t *e;
-    
-    e = shr_hash[handle % SHR_HASH_LENGTH]; 
-    while(e != NULL)
+    if ( mfn_valid(_mfn(mfn)) )
     {
-        if(e->handle == handle)
-            return e;
-        e = e->next;
+        struct page_info* page = mfn_to_page(_mfn(mfn));
+        if ( page_get_owner(page) == dom_cow )
+        {
+            ASSERT(page->u.inuse.type_info & PGT_type_mask); 
+            ASSERT(get_gpfn_from_mfn(mfn) == SHARED_M2P_ENTRY); 
+            return page;
+        }
     }
 
     return NULL;
 }
 
-static shr_hash_entry_t* mem_sharing_hash_insert(shr_handle_t handle, mfn_t mfn)
+#if MEM_SHARING_AUDIT
+static int mem_sharing_audit(void)
 {
-    shr_hash_entry_t *e, **ee;
-    
-    e = mem_sharing_hash_alloc();
-    if(e == NULL) return NULL;
-    e->handle = handle;
-    e->mfn = mfn;
-    ee = &shr_hash[handle % SHR_HASH_LENGTH]; 
-    e->next = *ee;
-    *ee = e;
-    return e;
-}
-
-static void mem_sharing_hash_delete(shr_handle_t handle)
-{
-    shr_hash_entry_t **pprev, *e;  
-
-    pprev = &shr_hash[handle % SHR_HASH_LENGTH];
-    e = *pprev;
-    while(e != NULL)
-    {
-        if(e->handle == handle)
-        {
-            *pprev = e->next;
-            mem_sharing_hash_destroy(e);
-            return;
-        }
-        pprev = &e->next;
-        e = e->next;
-    }
-    printk("Could not find shr entry for handle %"PRIx64"\n", handle);
-    BUG();
-} 
-
-#if MEM_SHARING_AUDIT
-static void mem_sharing_audit(void)
-{
-    shr_hash_entry_t *e;
-    struct list_head *le;
-    gfn_info_t *g;
-    int bucket;
-    struct page_info *pg;
+    int errors = 0;
+    struct list_head *ae;
 
     ASSERT(shr_locked_by_me());
 
-    for(bucket=0; bucket < SHR_HASH_LENGTH; bucket++)
+    list_for_each(ae, &shr_audit_list)
     {
-        e = shr_hash[bucket];    
-        /* Loop over all shr_hash_entries */ 
-        while(e != NULL)
+        struct page_sharing_info *shared_info;
+        unsigned long nr_gfns = 0;
+        struct page_info *pg;
+        struct list_head *le;
+        mfn_t mfn;
+
+        shared_info = list_entry(ae, struct page_sharing_info, entry);
+        pg = shared_info->pg;
+        mfn = page_to_mfn(pg);
+
+        /* Check if the MFN has correct type, owner and handle. */ 
+        if ( !(pg->u.inuse.type_info & PGT_shared_page) )
         {
-            int nr_gfns=0;
+           MEM_SHARING_DEBUG("mfn %lx in audit list, but not PGT_shared_page (%d)!\n",
+                              mfn_x(mfn), pg->u.inuse.type_info & PGT_type_mask);
+           errors++;
+           continue;
+        }
 
-            /* Check if the MFN has correct type, owner and handle */ 
-            pg = mfn_to_page(e->mfn);
-            if((pg->u.inuse.type_info & PGT_type_mask) != PGT_shared_page)
-                MEM_SHARING_DEBUG("mfn %lx not shared, but in the hash!\n",
-                                   mfn_x(e->mfn));
-            if(page_get_owner(pg) != dom_cow)
-                MEM_SHARING_DEBUG("mfn %lx shared, but wrong owner (%d)!\n",
-                                   mfn_x(e->mfn), 
-                                   page_get_owner(pg)->domain_id);
-            if(e->handle != pg->shr_handle)
-                MEM_SHARING_DEBUG("mfn %lx shared, but wrong handle "
-                                  "(%ld != %ld)!\n",
-                                   mfn_x(e->mfn), pg->shr_handle, e->handle);
-            /* Check if all GFNs map to the MFN, and the p2m types */
-            list_for_each(le, &e->gfns)
+        /* Check the page owner. */
+        if ( page_get_owner(pg) != dom_cow )
+        {
+           MEM_SHARING_DEBUG("mfn %lx shared, but wrong owner (%d)!\n",
+                             mfn_x(mfn), page_get_owner(pg)->domain_id);
+           errors++;
+        }
+
+        /* Check the m2p entry */
+        if ( get_gpfn_from_mfn(mfn_x(mfn)) != SHARED_M2P_ENTRY )
+        {
+           MEM_SHARING_DEBUG("mfn %lx shared, but wrong m2p entry (%lx)!\n",
+                             mfn_x(mfn), get_gpfn_from_mfn(mfn_x(mfn)));
+           errors++;
+        }
+
+        /* Check if all GFNs map to the MFN, and the p2m types */
+        list_for_each(le, &pg->shared_info->gfns)
+        {
+            struct domain *d;
+            p2m_type_t t;
+            mfn_t o_mfn;
+            gfn_info_t *g;
+
+            g = list_entry(le, gfn_info_t, list);
+            d = get_domain_by_id(g->domain);
+            if ( d == NULL )
             {
-                struct domain *d;
-                p2m_type_t t;
-                mfn_t mfn;
-
-                g = list_entry(le, struct gfn_info, list);
-                d = get_domain_by_id(g->domain);
-                if(d == NULL)
-                {
-                    MEM_SHARING_DEBUG("Unknow dom: %d, for PFN=%lx, MFN=%lx\n",
-                            g->domain, g->gfn, mfn_x(e->mfn));
-                    continue;
-                }
-                mfn = get_gfn_unlocked(d, g->gfn, &t); 
-                if(mfn_x(mfn) != mfn_x(e->mfn))
-                    MEM_SHARING_DEBUG("Incorrect P2M for d=%d, PFN=%lx."
-                                      "Expecting MFN=%ld, got %ld\n",
-                                      g->domain, g->gfn, mfn_x(e->mfn),
-                                      mfn_x(mfn));
-                if(t != p2m_ram_shared)
-                    MEM_SHARING_DEBUG("Incorrect P2M type for d=%d, PFN=%lx."
-                                      "Expecting t=%d, got %d\n",
-                                      g->domain, g->gfn, mfn_x(e->mfn),
-                                      p2m_ram_shared, t);
-                put_domain(d);
-                nr_gfns++;
-            } 
-            if(nr_gfns != (pg->u.inuse.type_info & PGT_count_mask))
-                MEM_SHARING_DEBUG("Mismatched counts for MFN=%lx."
-                                  "nr_gfns in hash %d, in type_info %d\n",
-                                  mfn_x(e->mfn), nr_gfns, 
-                                 (pg->u.inuse.type_info & PGT_count_mask));
-            e = e->next;
+                MEM_SHARING_DEBUG("Unknown dom: %d, for PFN=%lx, MFN=%lx\n",
+                                  g->domain, g->gfn, mfn);
+                errors++;
+                continue;
+            }
+            o_mfn = get_gfn_query_unlocked(d, g->gfn, &t); 
+            if ( mfn_x(o_mfn) != mfn_x(mfn) )
+            {
+                MEM_SHARING_DEBUG("Incorrect P2M for d=%d, PFN=%lx."
+                                  "Expecting MFN=%ld, got %ld\n",
+                                  g->domain, g->gfn, mfn, mfn_x(o_mfn));
+                errors++;
+            }
+            if ( t != p2m_ram_shared )
+            {
+                MEM_SHARING_DEBUG("Incorrect P2M type for d=%d, PFN=%lx."
+                                  "Expecting t=%d, got %d\n",
+                                  g->domain, g->gfn, mfn, p2m_ram_shared, t);
+                errors++;
+            }
+            put_domain(d);
+            nr_gfns++;
+        }
+        if ( nr_gfns != (pg->u.inuse.type_info & PGT_count_mask) )
+        {
+            MEM_SHARING_DEBUG("Mismatched counts for MFN=%lx."
+                              "nr_gfns in hash %d, in type_info %d\n",
+                              mfn_x(mfn), nr_gfns, 
+                              (pg->u.inuse.type_info & PGT_count_mask));
+            errors++;
         }
     }
+
+    return errors;
 }
 #endif
 
@@ -402,36 +393,6 @@ static int mem_sharing_gref_to_gfn(struc
     return 0;
 }
 
-/* Account for a GFN being shared/unshared.
- * When sharing this function needs to be called _before_ gfn lists are merged
- * together, but _after_ gfn is removed from the list when unsharing.
- */
-static int mem_sharing_gfn_account(struct gfn_info *gfn, int sharing)
-{
-    struct domain *d;
-
-    /* A) When sharing:
-     * if the gfn being shared is in > 1 long list, its already been 
-     * accounted for
-     * B) When unsharing:
-     * if the list is longer than > 1, we don't have to account yet. 
-     */
-    if(list_has_one_entry(&gfn->list))
-    {
-        d = get_domain_by_id(gfn->domain);
-        BUG_ON(!d);
-        if(sharing) 
-            atomic_inc(&d->shr_pages);
-        else
-            atomic_dec(&d->shr_pages);
-        put_domain(d);
-
-        return 1;
-    }
-    mem_sharing_audit();
-
-    return 0;
-}
 
 int mem_sharing_debug_gref(struct domain *d, grant_ref_t ref)
 {
@@ -469,8 +430,6 @@ int mem_sharing_nominate_page(struct dom
     mfn_t mfn;
     struct page_info *page;
     int ret;
-    shr_handle_t handle;
-    shr_hash_entry_t *hash_entry;
     struct gfn_info *gfn_info;
 
     *phandle = 0UL;
@@ -486,7 +445,7 @@ int mem_sharing_nominate_page(struct dom
     /* Return the handle if the page is already shared */
     page = mfn_to_page(mfn);
     if ( p2m_is_shared(p2mt) ) {
-        *phandle = page->shr_handle;
+        *phandle = page->shared_info->handle;
         ret = 0;
         goto out;
     }
@@ -500,16 +459,27 @@ int mem_sharing_nominate_page(struct dom
     if ( ret ) 
         goto out;
 
-    /* Create the handle */
+    /* Initialize the shared state */
     ret = -ENOMEM;
-    handle = next_handle++;  
-    if((hash_entry = mem_sharing_hash_insert(handle, mfn)) == NULL)
+    if ( (page->shared_info = 
+            xmalloc(struct page_sharing_info)) == NULL )
     {
+        BUG_ON(page_make_private(d, page) != 0);
         goto out;
     }
-    if((gfn_info = mem_sharing_gfn_alloc()) == NULL)
+    page->shared_info->pg = page;
+    INIT_LIST_HEAD(&page->shared_info->gfns);
+    INIT_LIST_HEAD(&page->shared_info->entry);
+
+    /* Create the handle */
+    page->shared_info->handle = next_handle++;  
+
+    /* Create the local gfn info */
+    if ( (gfn_info = mem_sharing_gfn_alloc(page, d, gfn)) == NULL )
     {
-        mem_sharing_hash_destroy(hash_entry);
+        xfree(page->shared_info);
+        page->shared_info = NULL;
+        BUG_ON(page_make_private(d, page) != 0);
         goto out;
     }
 
@@ -520,23 +490,19 @@ int mem_sharing_nominate_page(struct dom
          * it a few lines above.
          * The mfn needs to revert back to rw type. This should never fail,
          * since no-one knew that the mfn was temporarily sharable */
+        mem_sharing_gfn_destroy(gfn_info, 0);
+        xfree(page->shared_info);
+        page->shared_info = NULL;
+        /* NOTE: We haven't yet added this to the audit list. */
         BUG_ON(page_make_private(d, page) != 0);
-        mem_sharing_hash_destroy(hash_entry);
-        mem_sharing_gfn_destroy(gfn_info, 0);
         goto out;
     }
 
     /* Update m2p entry to SHARED_M2P_ENTRY */
     set_gpfn_from_mfn(mfn_x(mfn), SHARED_M2P_ENTRY);
 
-    INIT_LIST_HEAD(&hash_entry->gfns);
-    INIT_LIST_HEAD(&gfn_info->list);
-    list_add(&gfn_info->list, &hash_entry->gfns);
-    gfn_info->gfn = gfn;
-    gfn_info->domain = d->domain_id;
-    page->shr_handle = handle;
-    *phandle = handle;
-
+    *phandle = page->shared_info->handle;
+    audit_add_list(page);
     ret = 0;
 
 out:
@@ -545,54 +511,92 @@ out:
     return ret;
 }
 
-int mem_sharing_share_pages(shr_handle_t sh, shr_handle_t ch) 
+int mem_sharing_share_pages(struct domain *sd, unsigned long sgfn, shr_handle_t sh,
+                            struct domain *cd, unsigned long cgfn, shr_handle_t ch) 
 {
-    shr_hash_entry_t *se, *ce;
     struct page_info *spage, *cpage;
     struct list_head *le, *te;
-    struct gfn_info *gfn;
+    gfn_info_t *gfn;
     struct domain *d;
-    int ret;
+    int ret = -EINVAL, single_client_gfn, single_source_gfn;
+    mfn_t smfn, cmfn;
+    p2m_type_t smfn_type, cmfn_type;
 
     shr_lock();
 
+    /* XXX if sd == cd handle potential deadlock by ordering
+     * the get_ and put_gfn's */
+    smfn = get_gfn(sd, sgfn, &smfn_type);
+    cmfn = get_gfn(cd, cgfn, &cmfn_type);
+
     ret = XEN_DOMCTL_MEM_SHARING_S_HANDLE_INVALID;
-    se = mem_sharing_hash_lookup(sh);
-    if(se == NULL) goto err_out;
+    spage = mem_sharing_lookup(mfn_x(smfn));
+    if ( spage == NULL )
+        goto err_out;
+    ASSERT(smfn_type == p2m_ram_shared);
     ret = XEN_DOMCTL_MEM_SHARING_C_HANDLE_INVALID;
-    ce = mem_sharing_hash_lookup(ch);
-    if(ce == NULL) goto err_out;
-    spage = mfn_to_page(se->mfn); 
-    cpage = mfn_to_page(ce->mfn); 
-    /* gfn lists always have at least one entry => save to call list_entry */
-    mem_sharing_gfn_account(gfn_get_info(&ce->gfns), 1);
-    mem_sharing_gfn_account(gfn_get_info(&se->gfns), 1);
-    list_for_each_safe(le, te, &ce->gfns)
+    cpage = mem_sharing_lookup(mfn_x(cmfn));
+    if ( cpage == NULL )
+        goto err_out;
+    ASSERT(cmfn_type == p2m_ram_shared);
+
+    /* Check that the handles match */
+    if ( spage->shared_info->handle != sh )
     {
-        gfn = list_entry(le, struct gfn_info, list);
-        /* Get the source page and type, this should never fail 
-         * because we are under shr lock, and got non-null se */
+        ret = XEN_DOMCTL_MEM_SHARING_S_HANDLE_INVALID;
+        goto err_out;
+    }
+    if ( cpage->shared_info->handle != ch )
+    {
+        ret = XEN_DOMCTL_MEM_SHARING_C_HANDLE_INVALID;
+        goto err_out;
+    }
+
+    /* Merge the lists together */
+    single_source_gfn = list_has_one_entry(&spage->shared_info->gfns);
+    single_client_gfn = list_has_one_entry(&cpage->shared_info->gfns);
+    list_for_each_safe(le, te, &cpage->shared_info->gfns)
+    {
+        gfn = list_entry(le, gfn_info_t, list);
+        /* Get the source page and type, this should never fail: 
+         * we are under shr lock, and got a successful lookup */
         BUG_ON(!get_page_and_type(spage, dom_cow, PGT_shared_page));
-        /* Move the gfn_info from ce list to se list */
+        /* Move the gfn_info from client list to source list */
         list_del(&gfn->list);
+        list_add(&gfn->list, &spage->shared_info->gfns);
+        put_page_and_type(cpage);
         d = get_domain_by_id(gfn->domain);
         BUG_ON(!d);
-        BUG_ON(set_shared_p2m_entry(d, gfn->gfn, se->mfn) == 0);
+        BUG_ON(set_shared_p2m_entry(d, gfn->gfn, smfn) == 0);
+        if ( single_client_gfn )
+        {
+            /* Only increase the per-domain count when we are actually
+             * sharing. And don't increase it should we ever re-share */
+            atomic_inc(&d->shr_pages);
+            ASSERT( cd == d );
+        }
         put_domain(d);
-        list_add(&gfn->list, &se->gfns);
-        put_page_and_type(cpage);
-    } 
-    ASSERT(list_empty(&ce->gfns));
-    mem_sharing_hash_delete(ch);
-    atomic_inc(&nr_saved_mfns);
+    }
+    ASSERT(list_empty(&cpage->shared_info->gfns));
+    if ( single_source_gfn )
+        atomic_inc(&sd->shr_pages);
+
+    /* Clear the rest of the shared state */
+    audit_del_list(cpage);
+    xfree(cpage->shared_info);
+    cpage->shared_info = NULL;
+
     /* Free the client page */
     if(test_and_clear_bit(_PGC_allocated, &cpage->count_info))
         put_page(cpage);
+
+    atomic_inc(&nr_saved_mfns);
     ret = 0;
     
 err_out:
+    put_gfn(cd, cgfn);
+    put_gfn(sd, sgfn);
     shr_unlock();
-
     return ret;
 }
 
@@ -604,13 +608,9 @@ int mem_sharing_unshare_page(struct doma
     mfn_t mfn;
     struct page_info *page, *old_page;
     void *s, *t;
-    int ret, last_gfn;
-    shr_hash_entry_t *hash_entry;
-    struct gfn_info *gfn_info = NULL;
-    shr_handle_t handle;
+    int last_gfn;
+    gfn_info_t *gfn_info = NULL;
     struct list_head *le;
-
-    /* Remove the gfn_info from the list */
    
     /* This is one of the reasons why we can't enforce ordering
      * between shr_lock and p2m fine-grained locks in mm-lock. 
@@ -626,56 +626,70 @@ int mem_sharing_unshare_page(struct doma
         return 0;
     }
 
-    page = mfn_to_page(mfn);
-    handle = page->shr_handle;
- 
-    hash_entry = mem_sharing_hash_lookup(handle); 
-    list_for_each(le, &hash_entry->gfns)
+    page = mem_sharing_lookup(mfn_x(mfn));
+    if ( page == NULL )
     {
-        gfn_info = list_entry(le, struct gfn_info, list);
+        gdprintk(XENLOG_ERR, "Domain p2m is shared, but page is not: "
+                                "%lx\n", gfn);
+        BUG();
+    }
+
+    list_for_each(le, &page->shared_info->gfns)
+    {
+        gfn_info = list_entry(le, gfn_info_t, list);
         if ( (gfn_info->gfn == gfn) && (gfn_info->domain == d->domain_id) )
             goto gfn_found;
     }
     gdprintk(XENLOG_ERR, "Could not find gfn_info for shared gfn: "
                             "%lx\n", gfn);
     BUG();
+
 gfn_found: 
     /* Delete gfn_info from the list, but hold on to it, until we've allocated
      * memory to make a copy */
-    list_del(&gfn_info->list);
-    last_gfn = list_empty(&hash_entry->gfns);
+    last_gfn = list_has_one_entry(&page->shared_info->gfns);
 
     /* If the GFN is getting destroyed drop the references to MFN 
      * (possibly freeing the page), and exit early */
     if ( flags & MEM_SHARING_DESTROY_GFN )
     {
         mem_sharing_gfn_destroy(gfn_info, !last_gfn);
-        if(last_gfn) 
-            mem_sharing_hash_delete(handle);
-        else 
+        if ( !last_gfn ) 
             /* Even though we don't allocate a private page, we have to account
              * for the MFN that originally backed this PFN. */
             atomic_dec(&nr_saved_mfns);
+
+        if ( last_gfn )
+        {
+            audit_del_list(page);
+            xfree(page->shared_info);
+            page->shared_info = NULL;
+        }
+
         put_gfn(d, gfn);
         shr_unlock();
         put_page_and_type(page);
-        if(last_gfn && 
-           test_and_clear_bit(_PGC_allocated, &page->count_info)) 
+        if( last_gfn && 
+            test_and_clear_bit(_PGC_allocated, &page->count_info)) 
             put_page(page);
+
         return 0;
     }
  
-    ret = page_make_private(d, page);
-    BUG_ON(last_gfn & ret);
-    if(ret == 0) goto private_page_found;
+    if ( last_gfn )
+    {
+        audit_del_list(page);
+        mem_sharing_gfn_destroy(gfn_info, !last_gfn);
+        xfree(page->shared_info);
+        page->shared_info = NULL;
+        BUG_ON(page_make_private(d, page) != 0);
+        goto private_page_found;
+    }
         
     old_page = page;
     page = mem_sharing_alloc_page(d, gfn);
-    if(!page) 
+    if ( !page ) 
     {
-        /* We've failed to obtain memory for private page. Need to re-add the
-         * gfn_info to relevant list */
-        list_add(&gfn_info->list, &hash_entry->gfns);
         put_gfn(d, gfn);
         shr_unlock();
         return -ENOMEM;
@@ -687,30 +701,23 @@ gfn_found:
     unmap_domain_page(s);
     unmap_domain_page(t);
 
-    /* NOTE: set_shared_p2m_entry will switch the underlying mfn. If
-     * we do get_page withing get_gfn, the correct sequence here
-     * should be
-       get_page(page);
-       put_page(old_page);
-     * so that the ref to the old page is dropped, and a ref to
-     * the new page is obtained to later be dropped in put_gfn */
     BUG_ON(set_shared_p2m_entry(d, gfn, page_to_mfn(page)) == 0);
+    /* We've got a private page, we can commit the gfn destruction */
+    mem_sharing_gfn_destroy(gfn_info, !last_gfn);
     put_page_and_type(old_page);
 
 private_page_found:    
-    /* We've got a private page, we can commit the gfn destruction */
-    mem_sharing_gfn_destroy(gfn_info, !last_gfn);
-    if(last_gfn) 
-        mem_sharing_hash_delete(handle);
-    else
+    if ( !last_gfn ) 
         atomic_dec(&nr_saved_mfns);
 
     if ( p2m_change_type(d, gfn, p2m_ram_shared, p2m_ram_rw) != 
                                                 p2m_ram_shared ) 
     {
-        printk("Could not change p2m type.\n");
+        gdprintk(XENLOG_ERR, "Could not change p2m type d %hu gfn %lx.\n", 
+                                d->domain_id, gfn);
         BUG();
     }
+
     /* Update m2p entry */
     set_gpfn_from_mfn(mfn_x(page_to_mfn(page)), gfn);
 
@@ -767,9 +774,18 @@ int mem_sharing_domctl(struct domain *d,
 
         case XEN_DOMCTL_MEM_EVENT_OP_SHARING_SHARE:
         {
-            shr_handle_t sh = mec->u.share.source_handle;
-            shr_handle_t ch = mec->u.share.client_handle;
-            rc = mem_sharing_share_pages(sh, ch); 
+            unsigned long sgfn  = mec->u.share.source_gfn;
+            shr_handle_t sh     = mec->u.share.source_handle;
+            struct domain *cd   = get_domain_by_id(mec->u.share.client_domain);
+            if ( cd )
+            {
+                unsigned long cgfn  = mec->u.share.client_gfn;
+                shr_handle_t ch     = mec->u.share.client_handle;
+                rc = mem_sharing_share_pages(d, sgfn, sh, cd, cgfn, ch); 
+                put_domain(cd);
+            }
+            else
+                return -EEXIST;
         }
         break;
 
@@ -817,6 +833,6 @@ int mem_sharing_domctl(struct domain *d,
 void __init mem_sharing_init(void)
 {
     printk("Initing memory sharing.\n");
-    mem_sharing_hash_init();
+    mm_lock_init(&shr_lock);
 }
 
diff -r 61da3fc46f06 -r 3038770886aa xen/include/asm-x86/mem_sharing.h
--- a/xen/include/asm-x86/mem_sharing.h
+++ b/xen/include/asm-x86/mem_sharing.h
@@ -22,13 +22,23 @@
 #ifndef __MEM_SHARING_H__
 #define __MEM_SHARING_H__
 
+#include <public/domctl.h>
+
+typedef uint64_t shr_handle_t; 
+
+struct page_sharing_info
+{
+    struct page_info *pg;   /* Back pointer to the page. */
+    shr_handle_t handle;    /* Globally unique version / handle. */
+    struct list_head entry; /* List of all shared pages (entry). */
+    struct list_head gfns;  /* List of domains and gfns for this page (head). */
+};
+
 #ifdef __x86_64__
 
 #define sharing_supported(_d) \
     (is_hvm_domain(_d) && paging_mode_hap(_d)) 
 
-typedef uint64_t shr_handle_t; 
-
 unsigned int mem_sharing_get_nr_saved_mfns(void);
 int mem_sharing_nominate_page(struct domain *d, 
                               unsigned long gfn,
@@ -41,6 +51,7 @@ int mem_sharing_unshare_page(struct doma
 int mem_sharing_sharing_resume(struct domain *d);
 int mem_sharing_domctl(struct domain *d, 
                        xen_domctl_mem_sharing_op_t *mec);
+
 void mem_sharing_init(void);
 
 #else 
diff -r 61da3fc46f06 -r 3038770886aa xen/include/asm-x86/mm.h
--- a/xen/include/asm-x86/mm.h
+++ b/xen/include/asm-x86/mm.h
@@ -31,6 +31,8 @@ struct page_list_entry
     __pdx_t next, prev;
 };
 
+struct page_sharing_info;
+
 struct page_info
 {
     union {
@@ -49,8 +51,13 @@ struct page_info
         /* For non-pinnable single-page shadows, a higher entry that points
          * at us. */
         paddr_t up;
-        /* For shared/sharable pages the sharing handle */
-        uint64_t shr_handle; 
+        /* For shared/sharable pages, we use a doubly-linked list
+         * of all the {pfn,domain} pairs that map this page. We also include
+         * an opaque handle, which is effectively a version, so that clients
+         * of sharing share the version they expect to.
+         * This list is allocated and freed when a page is shared/unshared.
+         */
+        struct page_sharing_info *shared_info;
     };
 
     /* Reference count and various PGC_xxx flags and fields. */
diff -r 61da3fc46f06 -r 3038770886aa xen/include/public/domctl.h
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -789,7 +789,10 @@ struct xen_domctl_mem_sharing_op {
             uint64_aligned_t  handle;     /* OUT: the handle           */
         } nominate;
         struct mem_sharing_op_share {     /* OP_SHARE */
+            uint64_aligned_t source_gfn;    /* IN: the gfn of the source page */
             uint64_aligned_t source_handle; /* IN: handle to the source page */
+            uint64_aligned_t client_domain; /* IN: the client domain id */
+            uint64_aligned_t client_gfn;    /* IN: the client gfn */
             uint64_aligned_t client_handle; /* IN: handle to the client page */
         } share; 
         struct mem_sharing_op_debug {     /* OP_DEBUG_xxx */

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 08 07:47:40 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 Dec 2011 07:47:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYYhH-0003Hw-C8; Thu, 08 Dec 2011 07:47:15 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RYYhF-0003GO-Kz
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 07:47:14 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-14.tower-182.messagelabs.com!1323330384!6360852!2
X-Originating-IP: [208.97.132.74]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi43NCA9PiAxNTI1Nw==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4170 invoked from network); 8 Dec 2011 07:46:25 -0000
Received: from caiajhbdcahe.dreamhost.com (HELO homiemail-a20.g.dreamhost.com)
	(208.97.132.74) by server-14.tower-182.messagelabs.com with SMTP;
	8 Dec 2011 07:46:25 -0000
Received: from homiemail-a20.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTP id E77487EC069;
	Wed,  7 Dec 2011 23:46:24 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=c+C9VISBuoB1AQYjNNQyvshxCHJK0EvITOJHsx3z+pXB
	8fs609CQCJhTd23u9/7WtQqPT+kxljD79hCQ6efh6pwBpqa3u2XUwySiFw3Ye4E4
	6kJJNBss3ZJA2rBf2e2fK63qJZc7JWk3nG2dJ8yuK1upikjoqcgHjDliGRSM1vA=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=TzrQOrIR4QFi258W+IH8Rkazg9M=; b=r7srf0qxXNh
	Z0a7saXok2sU0bynV+1QfMCJEynqYWEMY0O5Mw7mcv6rK2ua9UKaDS2Y9FdJAyYK
	Ciofa3EoQ/eabzXIF2rbAL9a7g5vK8yglY4XnP2W3BTX8UaeQeRlST7VPnuETruY
	Z3xdbz7eIsMfHG3vWt1UkbPNMHFojSNU=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTPSA id 0690E7EC061; 
	Wed,  7 Dec 2011 23:46:23 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 3038770886aa0654d73a62b22a82aa196c343595
Message-Id: <3038770886aa0654d73a.1323330438@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1323330435@xdev.gridcentric.ca>
References: <patchbomb.1323330435@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Thu, 08 Dec 2011 02:47:18 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: ian.campbell@citrix.com, andres@gridcentric.ca, tim@xen.org,
	keir.xen@gmail.com, JBeulich@suse.com, ian.jackson@citrix.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 03 of 18] x86/mm: Eliminate hash table in
 sharing code as index of shared mfns
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/mm/mem_sharing.c     |  526 +++++++++++++++++++------------------
 xen/include/asm-x86/mem_sharing.h |   15 +-
 xen/include/asm-x86/mm.h          |   11 +-
 xen/include/public/domctl.h       |    3 +
 4 files changed, 296 insertions(+), 259 deletions(-)


The hashtable mechanism used by the sharing code is a bit odd.  It seems
unnecessary and adds complexity.  Instead, we replace this by storing a list
head directly in the page info for the case when the page is shared.  This does
not add any extra space to the page_info and serves to remove significant
complexity from sharing.

Signed-off-by: Adin Scannell <adin@scannell.ca>
Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 61da3fc46f06 -r 3038770886aa xen/arch/x86/mm/mem_sharing.c
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -3,6 +3,7 @@
  *
  * Memory sharing support.
  *
+ * Copyright (c) 2011 GridCentric, Inc. (Adin Scannell & Andres Lagar-Cavilla)
  * Copyright (c) 2009 Citrix Systems, Inc. (Grzegorz Milos)
  *
  * This program is free software; you can redistribute it and/or modify
@@ -38,11 +39,28 @@
 #define MEM_SHARING_AUDIT 0
 
 #if MEM_SHARING_AUDIT
-static void mem_sharing_audit(void);
+static int mem_sharing_audit(void);
 #define MEM_SHARING_DEBUG(_f, _a...)                                  \
     debugtrace_printk("mem_sharing_debug: %s(): " _f, __func__, ##_a)
+static struct list_head shr_audit_list;
+
+static inline void audit_add_list(struct page_info *page)
+{
+    list_add(&page->shared_info->entry, &shr_audit_list);
+}
+
+static inline void audit_del_list(struct page_info *page)
+{
+    list_del(&page->shared_info->entry);
+}
 #else
-#define mem_sharing_audit() do {} while(0)
+static inline int mem_sharing_audit(void)
+{
+    return 0;
+}
+
+#define audit_add_list(p)  ((void)0)
+#define audit_del_list(p)  ((void)0)
 #endif /* MEM_SHARING_AUDIT */
 
 #define mem_sharing_enabled(d) \
@@ -58,17 +76,6 @@ static void mem_sharing_audit(void);
 static shr_handle_t next_handle = 1;
 static atomic_t nr_saved_mfns   = ATOMIC_INIT(0); 
 
-typedef struct shr_hash_entry 
-{
-    shr_handle_t handle;
-    mfn_t mfn; 
-    struct shr_hash_entry *next;
-    struct list_head gfns;
-} shr_hash_entry_t;
-
-#define SHR_HASH_LENGTH 1000
-static shr_hash_entry_t *shr_hash[SHR_HASH_LENGTH];
-
 typedef struct gfn_info
 {
     unsigned long gfn;
@@ -89,36 +96,30 @@ static inline gfn_info_t *gfn_get_info(s
     return list_entry(list->next, gfn_info_t, list);
 }
 
-static void __init mem_sharing_hash_init(void)
+static inline gfn_info_t *mem_sharing_gfn_alloc(struct page_info *page,
+                                         struct domain *d,
+                                         unsigned long gfn)
 {
-    int i;
+    gfn_info_t *gfn_info = xmalloc(gfn_info_t);
 
-    mm_lock_init(&shr_lock);
-    for(i=0; i<SHR_HASH_LENGTH; i++)
-        shr_hash[i] = NULL;
+    if ( gfn_info == NULL )
+        return NULL; 
+
+    gfn_info->gfn = gfn;
+    gfn_info->domain = d->domain_id;
+    INIT_LIST_HEAD(&gfn_info->list);
+    list_add(&gfn_info->list, &page->shared_info->gfns);
+
+    return gfn_info;
 }
 
-static shr_hash_entry_t *mem_sharing_hash_alloc(void)
-{
-    return xmalloc(shr_hash_entry_t); 
-}
-
-static void mem_sharing_hash_destroy(shr_hash_entry_t *e)
-{
-    xfree(e);
-}
-
-static gfn_info_t *mem_sharing_gfn_alloc(void)
-{
-    return xmalloc(gfn_info_t); 
-}
-
-static void mem_sharing_gfn_destroy(gfn_info_t *gfn, int was_shared)
+static inline void mem_sharing_gfn_destroy(gfn_info_t *gfn_info,
+                                    int was_shared)
 {
     /* Decrement the number of pages, if the gfn was shared before */
     if ( was_shared )
     {
-        struct domain *d = get_domain_by_id(gfn->domain);
+        struct domain *d = get_domain_by_id(gfn_info->domain);
         /* Domain may have been destroyed by now *
          * (if we are called from p2m_teardown)  */
         if ( d )
@@ -127,128 +128,118 @@ static void mem_sharing_gfn_destroy(gfn_
             put_domain(d);
         }
     }
-    xfree(gfn);
+
+    list_del(&gfn_info->list);
+    xfree(gfn_info);
 }
 
-static shr_hash_entry_t* mem_sharing_hash_lookup(shr_handle_t handle)
+static struct page_info* mem_sharing_lookup(unsigned long mfn)
 {
-    shr_hash_entry_t *e;
-    
-    e = shr_hash[handle % SHR_HASH_LENGTH]; 
-    while(e != NULL)
+    if ( mfn_valid(_mfn(mfn)) )
     {
-        if(e->handle == handle)
-            return e;
-        e = e->next;
+        struct page_info* page = mfn_to_page(_mfn(mfn));
+        if ( page_get_owner(page) == dom_cow )
+        {
+            ASSERT(page->u.inuse.type_info & PGT_type_mask); 
+            ASSERT(get_gpfn_from_mfn(mfn) == SHARED_M2P_ENTRY); 
+            return page;
+        }
     }
 
     return NULL;
 }
 
-static shr_hash_entry_t* mem_sharing_hash_insert(shr_handle_t handle, mfn_t mfn)
+#if MEM_SHARING_AUDIT
+static int mem_sharing_audit(void)
 {
-    shr_hash_entry_t *e, **ee;
-    
-    e = mem_sharing_hash_alloc();
-    if(e == NULL) return NULL;
-    e->handle = handle;
-    e->mfn = mfn;
-    ee = &shr_hash[handle % SHR_HASH_LENGTH]; 
-    e->next = *ee;
-    *ee = e;
-    return e;
-}
-
-static void mem_sharing_hash_delete(shr_handle_t handle)
-{
-    shr_hash_entry_t **pprev, *e;  
-
-    pprev = &shr_hash[handle % SHR_HASH_LENGTH];
-    e = *pprev;
-    while(e != NULL)
-    {
-        if(e->handle == handle)
-        {
-            *pprev = e->next;
-            mem_sharing_hash_destroy(e);
-            return;
-        }
-        pprev = &e->next;
-        e = e->next;
-    }
-    printk("Could not find shr entry for handle %"PRIx64"\n", handle);
-    BUG();
-} 
-
-#if MEM_SHARING_AUDIT
-static void mem_sharing_audit(void)
-{
-    shr_hash_entry_t *e;
-    struct list_head *le;
-    gfn_info_t *g;
-    int bucket;
-    struct page_info *pg;
+    int errors = 0;
+    struct list_head *ae;
 
     ASSERT(shr_locked_by_me());
 
-    for(bucket=0; bucket < SHR_HASH_LENGTH; bucket++)
+    list_for_each(ae, &shr_audit_list)
     {
-        e = shr_hash[bucket];    
-        /* Loop over all shr_hash_entries */ 
-        while(e != NULL)
+        struct page_sharing_info *shared_info;
+        unsigned long nr_gfns = 0;
+        struct page_info *pg;
+        struct list_head *le;
+        mfn_t mfn;
+
+        shared_info = list_entry(ae, struct page_sharing_info, entry);
+        pg = shared_info->pg;
+        mfn = page_to_mfn(pg);
+
+        /* Check if the MFN has correct type, owner and handle. */ 
+        if ( !(pg->u.inuse.type_info & PGT_shared_page) )
         {
-            int nr_gfns=0;
+           MEM_SHARING_DEBUG("mfn %lx in audit list, but not PGT_shared_page (%d)!\n",
+                              mfn_x(mfn), pg->u.inuse.type_info & PGT_type_mask);
+           errors++;
+           continue;
+        }
 
-            /* Check if the MFN has correct type, owner and handle */ 
-            pg = mfn_to_page(e->mfn);
-            if((pg->u.inuse.type_info & PGT_type_mask) != PGT_shared_page)
-                MEM_SHARING_DEBUG("mfn %lx not shared, but in the hash!\n",
-                                   mfn_x(e->mfn));
-            if(page_get_owner(pg) != dom_cow)
-                MEM_SHARING_DEBUG("mfn %lx shared, but wrong owner (%d)!\n",
-                                   mfn_x(e->mfn), 
-                                   page_get_owner(pg)->domain_id);
-            if(e->handle != pg->shr_handle)
-                MEM_SHARING_DEBUG("mfn %lx shared, but wrong handle "
-                                  "(%ld != %ld)!\n",
-                                   mfn_x(e->mfn), pg->shr_handle, e->handle);
-            /* Check if all GFNs map to the MFN, and the p2m types */
-            list_for_each(le, &e->gfns)
+        /* Check the page owner. */
+        if ( page_get_owner(pg) != dom_cow )
+        {
+           MEM_SHARING_DEBUG("mfn %lx shared, but wrong owner (%d)!\n",
+                             mfn_x(mfn), page_get_owner(pg)->domain_id);
+           errors++;
+        }
+
+        /* Check the m2p entry */
+        if ( get_gpfn_from_mfn(mfn_x(mfn)) != SHARED_M2P_ENTRY )
+        {
+           MEM_SHARING_DEBUG("mfn %lx shared, but wrong m2p entry (%lx)!\n",
+                             mfn_x(mfn), get_gpfn_from_mfn(mfn_x(mfn)));
+           errors++;
+        }
+
+        /* Check if all GFNs map to the MFN, and the p2m types */
+        list_for_each(le, &pg->shared_info->gfns)
+        {
+            struct domain *d;
+            p2m_type_t t;
+            mfn_t o_mfn;
+            gfn_info_t *g;
+
+            g = list_entry(le, gfn_info_t, list);
+            d = get_domain_by_id(g->domain);
+            if ( d == NULL )
             {
-                struct domain *d;
-                p2m_type_t t;
-                mfn_t mfn;
-
-                g = list_entry(le, struct gfn_info, list);
-                d = get_domain_by_id(g->domain);
-                if(d == NULL)
-                {
-                    MEM_SHARING_DEBUG("Unknow dom: %d, for PFN=%lx, MFN=%lx\n",
-                            g->domain, g->gfn, mfn_x(e->mfn));
-                    continue;
-                }
-                mfn = get_gfn_unlocked(d, g->gfn, &t); 
-                if(mfn_x(mfn) != mfn_x(e->mfn))
-                    MEM_SHARING_DEBUG("Incorrect P2M for d=%d, PFN=%lx."
-                                      "Expecting MFN=%ld, got %ld\n",
-                                      g->domain, g->gfn, mfn_x(e->mfn),
-                                      mfn_x(mfn));
-                if(t != p2m_ram_shared)
-                    MEM_SHARING_DEBUG("Incorrect P2M type for d=%d, PFN=%lx."
-                                      "Expecting t=%d, got %d\n",
-                                      g->domain, g->gfn, mfn_x(e->mfn),
-                                      p2m_ram_shared, t);
-                put_domain(d);
-                nr_gfns++;
-            } 
-            if(nr_gfns != (pg->u.inuse.type_info & PGT_count_mask))
-                MEM_SHARING_DEBUG("Mismatched counts for MFN=%lx."
-                                  "nr_gfns in hash %d, in type_info %d\n",
-                                  mfn_x(e->mfn), nr_gfns, 
-                                 (pg->u.inuse.type_info & PGT_count_mask));
-            e = e->next;
+                MEM_SHARING_DEBUG("Unknown dom: %d, for PFN=%lx, MFN=%lx\n",
+                                  g->domain, g->gfn, mfn);
+                errors++;
+                continue;
+            }
+            o_mfn = get_gfn_query_unlocked(d, g->gfn, &t); 
+            if ( mfn_x(o_mfn) != mfn_x(mfn) )
+            {
+                MEM_SHARING_DEBUG("Incorrect P2M for d=%d, PFN=%lx."
+                                  "Expecting MFN=%ld, got %ld\n",
+                                  g->domain, g->gfn, mfn, mfn_x(o_mfn));
+                errors++;
+            }
+            if ( t != p2m_ram_shared )
+            {
+                MEM_SHARING_DEBUG("Incorrect P2M type for d=%d, PFN=%lx."
+                                  "Expecting t=%d, got %d\n",
+                                  g->domain, g->gfn, mfn, p2m_ram_shared, t);
+                errors++;
+            }
+            put_domain(d);
+            nr_gfns++;
+        }
+        if ( nr_gfns != (pg->u.inuse.type_info & PGT_count_mask) )
+        {
+            MEM_SHARING_DEBUG("Mismatched counts for MFN=%lx."
+                              "nr_gfns in hash %d, in type_info %d\n",
+                              mfn_x(mfn), nr_gfns, 
+                              (pg->u.inuse.type_info & PGT_count_mask));
+            errors++;
         }
     }
+
+    return errors;
 }
 #endif
 
@@ -402,36 +393,6 @@ static int mem_sharing_gref_to_gfn(struc
     return 0;
 }
 
-/* Account for a GFN being shared/unshared.
- * When sharing this function needs to be called _before_ gfn lists are merged
- * together, but _after_ gfn is removed from the list when unsharing.
- */
-static int mem_sharing_gfn_account(struct gfn_info *gfn, int sharing)
-{
-    struct domain *d;
-
-    /* A) When sharing:
-     * if the gfn being shared is in > 1 long list, its already been 
-     * accounted for
-     * B) When unsharing:
-     * if the list is longer than > 1, we don't have to account yet. 
-     */
-    if(list_has_one_entry(&gfn->list))
-    {
-        d = get_domain_by_id(gfn->domain);
-        BUG_ON(!d);
-        if(sharing) 
-            atomic_inc(&d->shr_pages);
-        else
-            atomic_dec(&d->shr_pages);
-        put_domain(d);
-
-        return 1;
-    }
-    mem_sharing_audit();
-
-    return 0;
-}
 
 int mem_sharing_debug_gref(struct domain *d, grant_ref_t ref)
 {
@@ -469,8 +430,6 @@ int mem_sharing_nominate_page(struct dom
     mfn_t mfn;
     struct page_info *page;
     int ret;
-    shr_handle_t handle;
-    shr_hash_entry_t *hash_entry;
     struct gfn_info *gfn_info;
 
     *phandle = 0UL;
@@ -486,7 +445,7 @@ int mem_sharing_nominate_page(struct dom
     /* Return the handle if the page is already shared */
     page = mfn_to_page(mfn);
     if ( p2m_is_shared(p2mt) ) {
-        *phandle = page->shr_handle;
+        *phandle = page->shared_info->handle;
         ret = 0;
         goto out;
     }
@@ -500,16 +459,27 @@ int mem_sharing_nominate_page(struct dom
     if ( ret ) 
         goto out;
 
-    /* Create the handle */
+    /* Initialize the shared state */
     ret = -ENOMEM;
-    handle = next_handle++;  
-    if((hash_entry = mem_sharing_hash_insert(handle, mfn)) == NULL)
+    if ( (page->shared_info = 
+            xmalloc(struct page_sharing_info)) == NULL )
     {
+        BUG_ON(page_make_private(d, page) != 0);
         goto out;
     }
-    if((gfn_info = mem_sharing_gfn_alloc()) == NULL)
+    page->shared_info->pg = page;
+    INIT_LIST_HEAD(&page->shared_info->gfns);
+    INIT_LIST_HEAD(&page->shared_info->entry);
+
+    /* Create the handle */
+    page->shared_info->handle = next_handle++;  
+
+    /* Create the local gfn info */
+    if ( (gfn_info = mem_sharing_gfn_alloc(page, d, gfn)) == NULL )
     {
-        mem_sharing_hash_destroy(hash_entry);
+        xfree(page->shared_info);
+        page->shared_info = NULL;
+        BUG_ON(page_make_private(d, page) != 0);
         goto out;
     }
 
@@ -520,23 +490,19 @@ int mem_sharing_nominate_page(struct dom
          * it a few lines above.
          * The mfn needs to revert back to rw type. This should never fail,
          * since no-one knew that the mfn was temporarily sharable */
+        mem_sharing_gfn_destroy(gfn_info, 0);
+        xfree(page->shared_info);
+        page->shared_info = NULL;
+        /* NOTE: We haven't yet added this to the audit list. */
         BUG_ON(page_make_private(d, page) != 0);
-        mem_sharing_hash_destroy(hash_entry);
-        mem_sharing_gfn_destroy(gfn_info, 0);
         goto out;
     }
 
     /* Update m2p entry to SHARED_M2P_ENTRY */
     set_gpfn_from_mfn(mfn_x(mfn), SHARED_M2P_ENTRY);
 
-    INIT_LIST_HEAD(&hash_entry->gfns);
-    INIT_LIST_HEAD(&gfn_info->list);
-    list_add(&gfn_info->list, &hash_entry->gfns);
-    gfn_info->gfn = gfn;
-    gfn_info->domain = d->domain_id;
-    page->shr_handle = handle;
-    *phandle = handle;
-
+    *phandle = page->shared_info->handle;
+    audit_add_list(page);
     ret = 0;
 
 out:
@@ -545,54 +511,92 @@ out:
     return ret;
 }
 
-int mem_sharing_share_pages(shr_handle_t sh, shr_handle_t ch) 
+int mem_sharing_share_pages(struct domain *sd, unsigned long sgfn, shr_handle_t sh,
+                            struct domain *cd, unsigned long cgfn, shr_handle_t ch) 
 {
-    shr_hash_entry_t *se, *ce;
     struct page_info *spage, *cpage;
     struct list_head *le, *te;
-    struct gfn_info *gfn;
+    gfn_info_t *gfn;
     struct domain *d;
-    int ret;
+    int ret = -EINVAL, single_client_gfn, single_source_gfn;
+    mfn_t smfn, cmfn;
+    p2m_type_t smfn_type, cmfn_type;
 
     shr_lock();
 
+    /* XXX if sd == cd handle potential deadlock by ordering
+     * the get_ and put_gfn's */
+    smfn = get_gfn(sd, sgfn, &smfn_type);
+    cmfn = get_gfn(cd, cgfn, &cmfn_type);
+
     ret = XEN_DOMCTL_MEM_SHARING_S_HANDLE_INVALID;
-    se = mem_sharing_hash_lookup(sh);
-    if(se == NULL) goto err_out;
+    spage = mem_sharing_lookup(mfn_x(smfn));
+    if ( spage == NULL )
+        goto err_out;
+    ASSERT(smfn_type == p2m_ram_shared);
     ret = XEN_DOMCTL_MEM_SHARING_C_HANDLE_INVALID;
-    ce = mem_sharing_hash_lookup(ch);
-    if(ce == NULL) goto err_out;
-    spage = mfn_to_page(se->mfn); 
-    cpage = mfn_to_page(ce->mfn); 
-    /* gfn lists always have at least one entry => save to call list_entry */
-    mem_sharing_gfn_account(gfn_get_info(&ce->gfns), 1);
-    mem_sharing_gfn_account(gfn_get_info(&se->gfns), 1);
-    list_for_each_safe(le, te, &ce->gfns)
+    cpage = mem_sharing_lookup(mfn_x(cmfn));
+    if ( cpage == NULL )
+        goto err_out;
+    ASSERT(cmfn_type == p2m_ram_shared);
+
+    /* Check that the handles match */
+    if ( spage->shared_info->handle != sh )
     {
-        gfn = list_entry(le, struct gfn_info, list);
-        /* Get the source page and type, this should never fail 
-         * because we are under shr lock, and got non-null se */
+        ret = XEN_DOMCTL_MEM_SHARING_S_HANDLE_INVALID;
+        goto err_out;
+    }
+    if ( cpage->shared_info->handle != ch )
+    {
+        ret = XEN_DOMCTL_MEM_SHARING_C_HANDLE_INVALID;
+        goto err_out;
+    }
+
+    /* Merge the lists together */
+    single_source_gfn = list_has_one_entry(&spage->shared_info->gfns);
+    single_client_gfn = list_has_one_entry(&cpage->shared_info->gfns);
+    list_for_each_safe(le, te, &cpage->shared_info->gfns)
+    {
+        gfn = list_entry(le, gfn_info_t, list);
+        /* Get the source page and type, this should never fail: 
+         * we are under shr lock, and got a successful lookup */
         BUG_ON(!get_page_and_type(spage, dom_cow, PGT_shared_page));
-        /* Move the gfn_info from ce list to se list */
+        /* Move the gfn_info from client list to source list */
         list_del(&gfn->list);
+        list_add(&gfn->list, &spage->shared_info->gfns);
+        put_page_and_type(cpage);
         d = get_domain_by_id(gfn->domain);
         BUG_ON(!d);
-        BUG_ON(set_shared_p2m_entry(d, gfn->gfn, se->mfn) == 0);
+        BUG_ON(set_shared_p2m_entry(d, gfn->gfn, smfn) == 0);
+        if ( single_client_gfn )
+        {
+            /* Only increase the per-domain count when we are actually
+             * sharing. And don't increase it should we ever re-share */
+            atomic_inc(&d->shr_pages);
+            ASSERT( cd == d );
+        }
         put_domain(d);
-        list_add(&gfn->list, &se->gfns);
-        put_page_and_type(cpage);
-    } 
-    ASSERT(list_empty(&ce->gfns));
-    mem_sharing_hash_delete(ch);
-    atomic_inc(&nr_saved_mfns);
+    }
+    ASSERT(list_empty(&cpage->shared_info->gfns));
+    if ( single_source_gfn )
+        atomic_inc(&sd->shr_pages);
+
+    /* Clear the rest of the shared state */
+    audit_del_list(cpage);
+    xfree(cpage->shared_info);
+    cpage->shared_info = NULL;
+
     /* Free the client page */
     if(test_and_clear_bit(_PGC_allocated, &cpage->count_info))
         put_page(cpage);
+
+    atomic_inc(&nr_saved_mfns);
     ret = 0;
     
 err_out:
+    put_gfn(cd, cgfn);
+    put_gfn(sd, sgfn);
     shr_unlock();
-
     return ret;
 }
 
@@ -604,13 +608,9 @@ int mem_sharing_unshare_page(struct doma
     mfn_t mfn;
     struct page_info *page, *old_page;
     void *s, *t;
-    int ret, last_gfn;
-    shr_hash_entry_t *hash_entry;
-    struct gfn_info *gfn_info = NULL;
-    shr_handle_t handle;
+    int last_gfn;
+    gfn_info_t *gfn_info = NULL;
     struct list_head *le;
-
-    /* Remove the gfn_info from the list */
    
     /* This is one of the reasons why we can't enforce ordering
      * between shr_lock and p2m fine-grained locks in mm-lock. 
@@ -626,56 +626,70 @@ int mem_sharing_unshare_page(struct doma
         return 0;
     }
 
-    page = mfn_to_page(mfn);
-    handle = page->shr_handle;
- 
-    hash_entry = mem_sharing_hash_lookup(handle); 
-    list_for_each(le, &hash_entry->gfns)
+    page = mem_sharing_lookup(mfn_x(mfn));
+    if ( page == NULL )
     {
-        gfn_info = list_entry(le, struct gfn_info, list);
+        gdprintk(XENLOG_ERR, "Domain p2m is shared, but page is not: "
+                                "%lx\n", gfn);
+        BUG();
+    }
+
+    list_for_each(le, &page->shared_info->gfns)
+    {
+        gfn_info = list_entry(le, gfn_info_t, list);
         if ( (gfn_info->gfn == gfn) && (gfn_info->domain == d->domain_id) )
             goto gfn_found;
     }
     gdprintk(XENLOG_ERR, "Could not find gfn_info for shared gfn: "
                             "%lx\n", gfn);
     BUG();
+
 gfn_found: 
     /* Delete gfn_info from the list, but hold on to it, until we've allocated
      * memory to make a copy */
-    list_del(&gfn_info->list);
-    last_gfn = list_empty(&hash_entry->gfns);
+    last_gfn = list_has_one_entry(&page->shared_info->gfns);
 
     /* If the GFN is getting destroyed drop the references to MFN 
      * (possibly freeing the page), and exit early */
     if ( flags & MEM_SHARING_DESTROY_GFN )
     {
         mem_sharing_gfn_destroy(gfn_info, !last_gfn);
-        if(last_gfn) 
-            mem_sharing_hash_delete(handle);
-        else 
+        if ( !last_gfn ) 
             /* Even though we don't allocate a private page, we have to account
              * for the MFN that originally backed this PFN. */
             atomic_dec(&nr_saved_mfns);
+
+        if ( last_gfn )
+        {
+            audit_del_list(page);
+            xfree(page->shared_info);
+            page->shared_info = NULL;
+        }
+
         put_gfn(d, gfn);
         shr_unlock();
         put_page_and_type(page);
-        if(last_gfn && 
-           test_and_clear_bit(_PGC_allocated, &page->count_info)) 
+        if( last_gfn && 
+            test_and_clear_bit(_PGC_allocated, &page->count_info)) 
             put_page(page);
+
         return 0;
     }
  
-    ret = page_make_private(d, page);
-    BUG_ON(last_gfn & ret);
-    if(ret == 0) goto private_page_found;
+    if ( last_gfn )
+    {
+        audit_del_list(page);
+        mem_sharing_gfn_destroy(gfn_info, !last_gfn);
+        xfree(page->shared_info);
+        page->shared_info = NULL;
+        BUG_ON(page_make_private(d, page) != 0);
+        goto private_page_found;
+    }
         
     old_page = page;
     page = mem_sharing_alloc_page(d, gfn);
-    if(!page) 
+    if ( !page ) 
     {
-        /* We've failed to obtain memory for private page. Need to re-add the
-         * gfn_info to relevant list */
-        list_add(&gfn_info->list, &hash_entry->gfns);
         put_gfn(d, gfn);
         shr_unlock();
         return -ENOMEM;
@@ -687,30 +701,23 @@ gfn_found:
     unmap_domain_page(s);
     unmap_domain_page(t);
 
-    /* NOTE: set_shared_p2m_entry will switch the underlying mfn. If
-     * we do get_page withing get_gfn, the correct sequence here
-     * should be
-       get_page(page);
-       put_page(old_page);
-     * so that the ref to the old page is dropped, and a ref to
-     * the new page is obtained to later be dropped in put_gfn */
     BUG_ON(set_shared_p2m_entry(d, gfn, page_to_mfn(page)) == 0);
+    /* We've got a private page, we can commit the gfn destruction */
+    mem_sharing_gfn_destroy(gfn_info, !last_gfn);
     put_page_and_type(old_page);
 
 private_page_found:    
-    /* We've got a private page, we can commit the gfn destruction */
-    mem_sharing_gfn_destroy(gfn_info, !last_gfn);
-    if(last_gfn) 
-        mem_sharing_hash_delete(handle);
-    else
+    if ( !last_gfn ) 
         atomic_dec(&nr_saved_mfns);
 
     if ( p2m_change_type(d, gfn, p2m_ram_shared, p2m_ram_rw) != 
                                                 p2m_ram_shared ) 
     {
-        printk("Could not change p2m type.\n");
+        gdprintk(XENLOG_ERR, "Could not change p2m type d %hu gfn %lx.\n", 
+                                d->domain_id, gfn);
         BUG();
     }
+
     /* Update m2p entry */
     set_gpfn_from_mfn(mfn_x(page_to_mfn(page)), gfn);
 
@@ -767,9 +774,18 @@ int mem_sharing_domctl(struct domain *d,
 
         case XEN_DOMCTL_MEM_EVENT_OP_SHARING_SHARE:
         {
-            shr_handle_t sh = mec->u.share.source_handle;
-            shr_handle_t ch = mec->u.share.client_handle;
-            rc = mem_sharing_share_pages(sh, ch); 
+            unsigned long sgfn  = mec->u.share.source_gfn;
+            shr_handle_t sh     = mec->u.share.source_handle;
+            struct domain *cd   = get_domain_by_id(mec->u.share.client_domain);
+            if ( cd )
+            {
+                unsigned long cgfn  = mec->u.share.client_gfn;
+                shr_handle_t ch     = mec->u.share.client_handle;
+                rc = mem_sharing_share_pages(d, sgfn, sh, cd, cgfn, ch); 
+                put_domain(cd);
+            }
+            else
+                return -EEXIST;
         }
         break;
 
@@ -817,6 +833,6 @@ int mem_sharing_domctl(struct domain *d,
 void __init mem_sharing_init(void)
 {
     printk("Initing memory sharing.\n");
-    mem_sharing_hash_init();
+    mm_lock_init(&shr_lock);
 }
 
diff -r 61da3fc46f06 -r 3038770886aa xen/include/asm-x86/mem_sharing.h
--- a/xen/include/asm-x86/mem_sharing.h
+++ b/xen/include/asm-x86/mem_sharing.h
@@ -22,13 +22,23 @@
 #ifndef __MEM_SHARING_H__
 #define __MEM_SHARING_H__
 
+#include <public/domctl.h>
+
+typedef uint64_t shr_handle_t; 
+
+struct page_sharing_info
+{
+    struct page_info *pg;   /* Back pointer to the page. */
+    shr_handle_t handle;    /* Globally unique version / handle. */
+    struct list_head entry; /* List of all shared pages (entry). */
+    struct list_head gfns;  /* List of domains and gfns for this page (head). */
+};
+
 #ifdef __x86_64__
 
 #define sharing_supported(_d) \
     (is_hvm_domain(_d) && paging_mode_hap(_d)) 
 
-typedef uint64_t shr_handle_t; 
-
 unsigned int mem_sharing_get_nr_saved_mfns(void);
 int mem_sharing_nominate_page(struct domain *d, 
                               unsigned long gfn,
@@ -41,6 +51,7 @@ int mem_sharing_unshare_page(struct doma
 int mem_sharing_sharing_resume(struct domain *d);
 int mem_sharing_domctl(struct domain *d, 
                        xen_domctl_mem_sharing_op_t *mec);
+
 void mem_sharing_init(void);
 
 #else 
diff -r 61da3fc46f06 -r 3038770886aa xen/include/asm-x86/mm.h
--- a/xen/include/asm-x86/mm.h
+++ b/xen/include/asm-x86/mm.h
@@ -31,6 +31,8 @@ struct page_list_entry
     __pdx_t next, prev;
 };
 
+struct page_sharing_info;
+
 struct page_info
 {
     union {
@@ -49,8 +51,13 @@ struct page_info
         /* For non-pinnable single-page shadows, a higher entry that points
          * at us. */
         paddr_t up;
-        /* For shared/sharable pages the sharing handle */
-        uint64_t shr_handle; 
+        /* For shared/sharable pages, we use a doubly-linked list
+         * of all the {pfn,domain} pairs that map this page. We also include
+         * an opaque handle, which is effectively a version, so that clients
+         * of sharing share the version they expect to.
+         * This list is allocated and freed when a page is shared/unshared.
+         */
+        struct page_sharing_info *shared_info;
     };
 
     /* Reference count and various PGC_xxx flags and fields. */
diff -r 61da3fc46f06 -r 3038770886aa xen/include/public/domctl.h
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -789,7 +789,10 @@ struct xen_domctl_mem_sharing_op {
             uint64_aligned_t  handle;     /* OUT: the handle           */
         } nominate;
         struct mem_sharing_op_share {     /* OP_SHARE */
+            uint64_aligned_t source_gfn;    /* IN: the gfn of the source page */
             uint64_aligned_t source_handle; /* IN: handle to the source page */
+            uint64_aligned_t client_domain; /* IN: the client domain id */
+            uint64_aligned_t client_gfn;    /* IN: the client gfn */
             uint64_aligned_t client_handle; /* IN: handle to the client page */
         } share; 
         struct mem_sharing_op_debug {     /* OP_DEBUG_xxx */

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 08 07:47:40 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 Dec 2011 07:47:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYYhH-0003IK-Ve; Thu, 08 Dec 2011 07:47:15 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RYYhG-0003Gg-Je
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 07:47:14 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-11.tower-21.messagelabs.com!1323330384!7191489!2
X-Originating-IP: [208.97.132.145]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNDUgPT4gMTY3OTU=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15889 invoked from network); 8 Dec 2011 07:46:26 -0000
Received: from caiajhbdcbef.dreamhost.com (HELO homiemail-a20.g.dreamhost.com)
	(208.97.132.145) by server-11.tower-21.messagelabs.com with SMTP;
	8 Dec 2011 07:46:26 -0000
Received: from homiemail-a20.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTP id E37037EC074;
	Wed,  7 Dec 2011 23:46:25 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=l2JMwgA0x8Kxruqh14AYbEDQgvSfteg3I4IpnR9uEyMK
	b0J//cMAZzkTYRT71xu9Q4TXeJYOvmseiG/9feIw+yQwJvbjyWiRpCdB2+HpV6E4
	yg1wqeF5T1Hi9gD/8/Y5MyB/8LPFFt3T+7g1AJGqdnZ5njrVoW5UQSa7jsz4Usk=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=EqGuVYNitvbgkGsw+0TzpCxmlkE=; b=eoFZvjSMcSk
	Q0V71vaFHlDlkjcCvWPi0tABPMCEFaN6xLQLLWC3bOMrNzk/6maOkjB2e7mMvHs8
	AB37koP/Z7cBvN9HtE1Y2WJL1Y+cfia6Vk2InkqqxO8JJ82i9WFqAO3HHKJwu4Tm
	3ryFFWGeV1OuKlOqrFVigGL8nnFbjw1I=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTPSA id 1FD0A7EC061; 
	Wed,  7 Dec 2011 23:46:25 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 2e8d5702f4c17d0af9f35054730245889af582f4
Message-Id: <2e8d5702f4c17d0af9f3.1323330439@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1323330435@xdev.gridcentric.ca>
References: <patchbomb.1323330435@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Thu, 08 Dec 2011 02:47:19 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: ian.campbell@citrix.com, andres@gridcentric.ca, tim@xen.org,
	keir.xen@gmail.com, JBeulich@suse.com, ian.jackson@citrix.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 04 of 18] x86/mm: Update mem sharing interface
 to (re)allow sharing of grants
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/mm/mem_sharing.c |  65 +++++++++++++++++++++++++++++++++++++-----
 xen/include/public/domctl.h   |   9 +++++
 2 files changed, 65 insertions(+), 9 deletions(-)


Previosuly, the mem sharing code would return an opaque handle
to index shared pages (and nominees) in its global hash table.
By removing the hash table, the new interfaces requires a gfn
and a version. However, when sharing grants, the caller only
has a grant ref and a version. Update interface to handle this
case.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 3038770886aa -r 2e8d5702f4c1 xen/arch/x86/mm/mem_sharing.c
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -774,18 +774,65 @@ int mem_sharing_domctl(struct domain *d,
 
         case XEN_DOMCTL_MEM_EVENT_OP_SHARING_SHARE:
         {
-            unsigned long sgfn  = mec->u.share.source_gfn;
-            shr_handle_t sh     = mec->u.share.source_handle;
-            struct domain *cd   = get_domain_by_id(mec->u.share.client_domain);
-            if ( cd )
+            unsigned long sgfn, cgfn;
+            struct domain *cd;
+            shr_handle_t sh, ch;
+            int source_is_gref = 0;
+
+            if ( !mem_sharing_enabled(d) )
+                return -EINVAL;
+
+            cd = get_domain_by_id(mec->u.share.client_domain);
+            if ( !cd )
+                return -ESRCH;
+
+            if ( !mem_sharing_enabled(cd) )
             {
-                unsigned long cgfn  = mec->u.share.client_gfn;
-                shr_handle_t ch     = mec->u.share.client_handle;
-                rc = mem_sharing_share_pages(d, sgfn, sh, cd, cgfn, ch); 
                 put_domain(cd);
+                return -EINVAL;
             }
-            else
-                return -EEXIST;
+
+            if ( XEN_DOMCTL_MEM_SHARING_FIELD_IS_GREF(mec->u.share.source_gfn) )
+            {
+                grant_ref_t gref = (grant_ref_t) 
+                                    (XEN_DOMCTL_MEM_SHARING_FIELD_GET_GREF(
+                                        mec->u.share.source_gfn));
+                if ( mem_sharing_gref_to_gfn(d, gref, &sgfn) < 0 )
+                {
+                    put_domain(cd);
+                    return -EINVAL;
+                }
+                source_is_gref = 1;
+            } else {
+                sgfn  = mec->u.share.source_gfn;
+            }
+
+            if ( XEN_DOMCTL_MEM_SHARING_FIELD_IS_GREF(mec->u.share.client_gfn) )
+            {
+                grant_ref_t gref = (grant_ref_t) 
+                                    (XEN_DOMCTL_MEM_SHARING_FIELD_GET_GREF(
+                                        mec->u.share.client_gfn));
+                if ( (!source_is_gref) || 
+                     (mem_sharing_gref_to_gfn(cd, gref, &cgfn) < 0) )
+                {
+                    put_domain(cd);
+                    return -EINVAL;
+                }
+            } else {
+                if ( source_is_gref )
+                {
+                    put_domain(cd);
+                    return -EINVAL;
+                }
+                cgfn  = mec->u.share.client_gfn;
+            }
+
+            sh = mec->u.share.source_handle;
+            ch = mec->u.share.client_handle;
+
+            rc = mem_sharing_share_pages(d, sgfn, sh, cd, cgfn, ch); 
+
+            put_domain(cd);
         }
         break;
 
diff -r 3038770886aa -r 2e8d5702f4c1 xen/include/public/domctl.h
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -775,6 +775,15 @@ DEFINE_XEN_GUEST_HANDLE(xen_domctl_mem_e
 #define XEN_DOMCTL_MEM_SHARING_S_HANDLE_INVALID  (-10)
 #define XEN_DOMCTL_MEM_SHARING_C_HANDLE_INVALID  (-9)
 
+#define XEN_DOMCTL_MEM_SHARING_FIELD_IS_GREF_FLAG   (1ULL << 62)
+
+#define XEN_DOMCTL_MEM_SHARING_FIELD_MAKE_GREF(field, val)  \
+    (field) = (XEN_DOMCTL_MEM_SHARING_FIELD_IS_GREF_FLAG | val)
+#define XEN_DOMCTL_MEM_SHARING_FIELD_IS_GREF(field)         \
+    ((field) & XEN_DOMCTL_MEM_SHARING_FIELD_IS_GREF_FLAG)
+#define XEN_DOMCTL_MEM_SHARING_FIELD_GET_GREF(field)        \
+    ((field) & (~XEN_DOMCTL_MEM_SHARING_FIELD_IS_GREF_FLAG))
+
 struct xen_domctl_mem_sharing_op {
     uint8_t op; /* XEN_DOMCTL_MEM_EVENT_OP_* */
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 08 07:47:40 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 Dec 2011 07:47:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYYhH-0003IK-Ve; Thu, 08 Dec 2011 07:47:15 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RYYhG-0003Gg-Je
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 07:47:14 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-11.tower-21.messagelabs.com!1323330384!7191489!2
X-Originating-IP: [208.97.132.145]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNDUgPT4gMTY3OTU=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15889 invoked from network); 8 Dec 2011 07:46:26 -0000
Received: from caiajhbdcbef.dreamhost.com (HELO homiemail-a20.g.dreamhost.com)
	(208.97.132.145) by server-11.tower-21.messagelabs.com with SMTP;
	8 Dec 2011 07:46:26 -0000
Received: from homiemail-a20.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTP id E37037EC074;
	Wed,  7 Dec 2011 23:46:25 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=l2JMwgA0x8Kxruqh14AYbEDQgvSfteg3I4IpnR9uEyMK
	b0J//cMAZzkTYRT71xu9Q4TXeJYOvmseiG/9feIw+yQwJvbjyWiRpCdB2+HpV6E4
	yg1wqeF5T1Hi9gD/8/Y5MyB/8LPFFt3T+7g1AJGqdnZ5njrVoW5UQSa7jsz4Usk=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=EqGuVYNitvbgkGsw+0TzpCxmlkE=; b=eoFZvjSMcSk
	Q0V71vaFHlDlkjcCvWPi0tABPMCEFaN6xLQLLWC3bOMrNzk/6maOkjB2e7mMvHs8
	AB37koP/Z7cBvN9HtE1Y2WJL1Y+cfia6Vk2InkqqxO8JJ82i9WFqAO3HHKJwu4Tm
	3ryFFWGeV1OuKlOqrFVigGL8nnFbjw1I=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTPSA id 1FD0A7EC061; 
	Wed,  7 Dec 2011 23:46:25 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 2e8d5702f4c17d0af9f35054730245889af582f4
Message-Id: <2e8d5702f4c17d0af9f3.1323330439@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1323330435@xdev.gridcentric.ca>
References: <patchbomb.1323330435@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Thu, 08 Dec 2011 02:47:19 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: ian.campbell@citrix.com, andres@gridcentric.ca, tim@xen.org,
	keir.xen@gmail.com, JBeulich@suse.com, ian.jackson@citrix.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 04 of 18] x86/mm: Update mem sharing interface
 to (re)allow sharing of grants
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/mm/mem_sharing.c |  65 +++++++++++++++++++++++++++++++++++++-----
 xen/include/public/domctl.h   |   9 +++++
 2 files changed, 65 insertions(+), 9 deletions(-)


Previosuly, the mem sharing code would return an opaque handle
to index shared pages (and nominees) in its global hash table.
By removing the hash table, the new interfaces requires a gfn
and a version. However, when sharing grants, the caller only
has a grant ref and a version. Update interface to handle this
case.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 3038770886aa -r 2e8d5702f4c1 xen/arch/x86/mm/mem_sharing.c
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -774,18 +774,65 @@ int mem_sharing_domctl(struct domain *d,
 
         case XEN_DOMCTL_MEM_EVENT_OP_SHARING_SHARE:
         {
-            unsigned long sgfn  = mec->u.share.source_gfn;
-            shr_handle_t sh     = mec->u.share.source_handle;
-            struct domain *cd   = get_domain_by_id(mec->u.share.client_domain);
-            if ( cd )
+            unsigned long sgfn, cgfn;
+            struct domain *cd;
+            shr_handle_t sh, ch;
+            int source_is_gref = 0;
+
+            if ( !mem_sharing_enabled(d) )
+                return -EINVAL;
+
+            cd = get_domain_by_id(mec->u.share.client_domain);
+            if ( !cd )
+                return -ESRCH;
+
+            if ( !mem_sharing_enabled(cd) )
             {
-                unsigned long cgfn  = mec->u.share.client_gfn;
-                shr_handle_t ch     = mec->u.share.client_handle;
-                rc = mem_sharing_share_pages(d, sgfn, sh, cd, cgfn, ch); 
                 put_domain(cd);
+                return -EINVAL;
             }
-            else
-                return -EEXIST;
+
+            if ( XEN_DOMCTL_MEM_SHARING_FIELD_IS_GREF(mec->u.share.source_gfn) )
+            {
+                grant_ref_t gref = (grant_ref_t) 
+                                    (XEN_DOMCTL_MEM_SHARING_FIELD_GET_GREF(
+                                        mec->u.share.source_gfn));
+                if ( mem_sharing_gref_to_gfn(d, gref, &sgfn) < 0 )
+                {
+                    put_domain(cd);
+                    return -EINVAL;
+                }
+                source_is_gref = 1;
+            } else {
+                sgfn  = mec->u.share.source_gfn;
+            }
+
+            if ( XEN_DOMCTL_MEM_SHARING_FIELD_IS_GREF(mec->u.share.client_gfn) )
+            {
+                grant_ref_t gref = (grant_ref_t) 
+                                    (XEN_DOMCTL_MEM_SHARING_FIELD_GET_GREF(
+                                        mec->u.share.client_gfn));
+                if ( (!source_is_gref) || 
+                     (mem_sharing_gref_to_gfn(cd, gref, &cgfn) < 0) )
+                {
+                    put_domain(cd);
+                    return -EINVAL;
+                }
+            } else {
+                if ( source_is_gref )
+                {
+                    put_domain(cd);
+                    return -EINVAL;
+                }
+                cgfn  = mec->u.share.client_gfn;
+            }
+
+            sh = mec->u.share.source_handle;
+            ch = mec->u.share.client_handle;
+
+            rc = mem_sharing_share_pages(d, sgfn, sh, cd, cgfn, ch); 
+
+            put_domain(cd);
         }
         break;
 
diff -r 3038770886aa -r 2e8d5702f4c1 xen/include/public/domctl.h
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -775,6 +775,15 @@ DEFINE_XEN_GUEST_HANDLE(xen_domctl_mem_e
 #define XEN_DOMCTL_MEM_SHARING_S_HANDLE_INVALID  (-10)
 #define XEN_DOMCTL_MEM_SHARING_C_HANDLE_INVALID  (-9)
 
+#define XEN_DOMCTL_MEM_SHARING_FIELD_IS_GREF_FLAG   (1ULL << 62)
+
+#define XEN_DOMCTL_MEM_SHARING_FIELD_MAKE_GREF(field, val)  \
+    (field) = (XEN_DOMCTL_MEM_SHARING_FIELD_IS_GREF_FLAG | val)
+#define XEN_DOMCTL_MEM_SHARING_FIELD_IS_GREF(field)         \
+    ((field) & XEN_DOMCTL_MEM_SHARING_FIELD_IS_GREF_FLAG)
+#define XEN_DOMCTL_MEM_SHARING_FIELD_GET_GREF(field)        \
+    ((field) & (~XEN_DOMCTL_MEM_SHARING_FIELD_IS_GREF_FLAG))
+
 struct xen_domctl_mem_sharing_op {
     uint8_t op; /* XEN_DOMCTL_MEM_EVENT_OP_* */
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 08 07:47:40 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 Dec 2011 07:47:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYYhP-0003M0-N2; Thu, 08 Dec 2011 07:47:23 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RYYhN-0003IL-Cr
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 07:47:21 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-9.tower-174.messagelabs.com!1323330392!4722130!1
X-Originating-IP: [208.97.132.202]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4yMDIgPT4gMTY1MzI=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7067 invoked from network); 8 Dec 2011 07:46:32 -0000
Received: from caiajhbdccac.dreamhost.com (HELO homiemail-a20.g.dreamhost.com)
	(208.97.132.202) by server-9.tower-174.messagelabs.com with SMTP;
	8 Dec 2011 07:46:32 -0000
Received: from homiemail-a20.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTP id 7FF937EC07D;
	Wed,  7 Dec 2011 23:46:31 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=TwCXeSa+TEN3R+1bWO3kYFLLBDkTCWNY1vMig4nCdkIk
	m+1H2ZfVAp4QU6HpxWaFl3y0CrBOepwvnxYqRE73dnJRFA8sKozhZZGFgEHlG4W3
	P4oZwvHjZeDY0MOf/dHsrxRReLRKAcID/eP4fLvg3D1MPLnIluvdiCKC9KBxgIk=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=fNNNsxEJVAn5+8UAXvthqFC8jbU=; b=o948aEmS+Gw
	wetfMY1TVTMrsK/4Hd47TFGEdTw5RLrBia8J51i6yFH16M4TZHYfVFI5Wr7oc7SF
	3q4wtBkvkVbg+IMm7TwWIb2c9IF8zjXLoFC7gI8YA0+WWxoZHsLfGSv8+PZCjuPL
	uQapz+g8TFAd73aws3AqviiqlllRgcVg=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTPSA id B93137EC07A; 
	Wed,  7 Dec 2011 23:46:30 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 65b32b3913736cd743af32227dd7b78103507ed9
Message-Id: <65b32b3913736cd743af.1323330444@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1323330435@xdev.gridcentric.ca>
References: <patchbomb.1323330435@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Thu, 08 Dec 2011 02:47:24 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: ian.campbell@citrix.com, andres@gridcentric.ca, tim@xen.org,
	keir.xen@gmail.com, JBeulich@suse.com, ian.jackson@citrix.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 09 of 18] x86/mm: Check how many mfns are shared,
 in addition to how many are saved
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/mm.c                 |   6 ------
 xen/arch/x86/mm/mem_sharing.c     |  31 ++++++++++++++++++++++++++++---
 xen/arch/x86/x86_64/compat/mm.c   |   6 ++++++
 xen/arch/x86/x86_64/mm.c          |   7 +++++++
 xen/include/asm-x86/mem_sharing.h |   1 +
 xen/include/public/memory.h       |   1 +
 6 files changed, 43 insertions(+), 9 deletions(-)


This patch also moves the existing sharing-related memory op to the
correct location, and adds logic to the audit() method that uses the
new information.

This patch only provides the Xen implementation of the domctls.

Signed-off-by: Adin Scannell <adin@scannell.ca>

diff -r 24d514cd4dee -r 65b32b391373 xen/arch/x86/mm.c
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -119,7 +119,6 @@
 #include <xen/trace.h>
 #include <asm/setup.h>
 #include <asm/fixmap.h>
-#include <asm/mem_sharing.h>
 
 /*
  * Mapping of first 2 or 4 megabytes of memory. This is mapped with 4kB
@@ -5093,11 +5092,6 @@ long arch_memory_op(int op, XEN_GUEST_HA
         return rc;
     }
 
-#ifdef __x86_64__
-    case XENMEM_get_sharing_freed_pages:
-        return mem_sharing_get_nr_saved_mfns();
-#endif
-
     default:
         return subarch_memory_op(op, arg);
     }
diff -r 24d514cd4dee -r 65b32b391373 xen/arch/x86/mm/mem_sharing.c
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -75,6 +75,7 @@ static inline int mem_sharing_audit(void
 
 static shr_handle_t next_handle = 1;
 static atomic_t nr_saved_mfns   = ATOMIC_INIT(0); 
+static atomic_t nr_shared_mfns  = ATOMIC_INIT(0);
 
 typedef struct gfn_info
 {
@@ -153,9 +154,12 @@ static struct page_info* mem_sharing_loo
 static int mem_sharing_audit(void)
 {
     int errors = 0;
+    unsigned long count_expected;
+    unsigned long count_found = 0;
     struct list_head *ae;
 
     ASSERT(shr_locked_by_me());
+    count_expected = atomic_read(&nr_shared_mfns);
 
     list_for_each(ae, &shr_audit_list)
     {
@@ -194,6 +198,7 @@ static int mem_sharing_audit(void)
            errors++;
         }
 
+        count_found++;
         /* Check if all GFNs map to the MFN, and the p2m types */
         list_for_each(le, &pg->shared_info->gfns)
         {
@@ -239,6 +244,13 @@ static int mem_sharing_audit(void)
         }
     }
 
+    if ( count_found != count_expected )
+    {
+        MEM_SHARING_DEBUG("Expected %ld shared mfns, found %ld.",
+                          count_expected, count_found);
+        errors++;
+    }
+
     return errors;
 }
 #endif
@@ -296,6 +308,11 @@ unsigned int mem_sharing_get_nr_saved_mf
     return ((unsigned int)atomic_read(&nr_saved_mfns));
 }
 
+unsigned int mem_sharing_get_nr_shared_mfns(void)
+{
+    return (unsigned int)atomic_read(&nr_shared_mfns);
+}
+
 int mem_sharing_sharing_resume(struct domain *d)
 {
     mem_event_response_t rsp;
@@ -570,10 +587,11 @@ int mem_sharing_share_pages(struct domai
         BUG_ON(set_shared_p2m_entry(d, gfn->gfn, smfn) == 0);
         if ( single_client_gfn )
         {
-            /* Only increase the per-domain count when we are actually
+            /* Only increase the stats counts when we are actually
              * sharing. And don't increase it should we ever re-share */
             atomic_inc(&d->shr_pages);
             ASSERT( cd == d );
+            atomic_inc(&nr_shared_mfns);
         }
         put_domain(d);
     }
@@ -654,10 +672,14 @@ gfn_found:
     if ( flags & MEM_SHARING_DESTROY_GFN )
     {
         mem_sharing_gfn_destroy(gfn_info, !last_gfn);
-        if ( !last_gfn ) 
+        if ( last_gfn )
+        {
+            atomic_dec(&nr_shared_mfns);
+        } else {
             /* Even though we don't allocate a private page, we have to account
              * for the MFN that originally backed this PFN. */
             atomic_dec(&nr_saved_mfns);
+        }
 
         if ( last_gfn )
         {
@@ -707,8 +729,11 @@ gfn_found:
     put_page_and_type(old_page);
 
 private_page_found:    
-    if ( !last_gfn ) 
+    if ( last_gfn ) {
+        atomic_dec(&nr_shared_mfns);
+    } else {
         atomic_dec(&nr_saved_mfns);
+    }
 
     if ( p2m_change_type(d, gfn, p2m_ram_shared, p2m_ram_rw) != 
                                                 p2m_ram_shared ) 
diff -r 24d514cd4dee -r 65b32b391373 xen/arch/x86/x86_64/compat/mm.c
--- a/xen/arch/x86/x86_64/compat/mm.c
+++ b/xen/arch/x86/x86_64/compat/mm.c
@@ -205,6 +205,12 @@ int compat_arch_memory_op(int op, XEN_GU
         break;
     }
 
+    case XENMEM_get_sharing_freed_pages:
+        return mem_sharing_get_nr_saved_mfns();
+
+    case XENMEM_get_sharing_shared_pages:
+        return mem_sharing_get_nr_shared_mfns();
+
     default:
         rc = -ENOSYS;
         break;
diff -r 24d514cd4dee -r 65b32b391373 xen/arch/x86/x86_64/mm.c
--- a/xen/arch/x86/x86_64/mm.c
+++ b/xen/arch/x86/x86_64/mm.c
@@ -34,6 +34,7 @@
 #include <asm/msr.h>
 #include <asm/setup.h>
 #include <asm/numa.h>
+#include <asm/mem_sharing.h>
 #include <public/memory.h>
 
 /* Parameters for PFN/MADDR compression. */
@@ -1090,6 +1091,12 @@ long subarch_memory_op(int op, XEN_GUEST
 
         break;
 
+    case XENMEM_get_sharing_freed_pages:
+        return mem_sharing_get_nr_saved_mfns();
+
+    case XENMEM_get_sharing_shared_pages:
+        return mem_sharing_get_nr_shared_mfns();
+
     default:
         rc = -ENOSYS;
         break;
diff -r 24d514cd4dee -r 65b32b391373 xen/include/asm-x86/mem_sharing.h
--- a/xen/include/asm-x86/mem_sharing.h
+++ b/xen/include/asm-x86/mem_sharing.h
@@ -40,6 +40,7 @@ struct page_sharing_info
     (is_hvm_domain(_d) && paging_mode_hap(_d)) 
 
 unsigned int mem_sharing_get_nr_saved_mfns(void);
+unsigned int mem_sharing_get_nr_shared_mfns(void);
 int mem_sharing_nominate_page(struct domain *d, 
                               unsigned long gfn,
                               int expected_refcnt,
diff -r 24d514cd4dee -r 65b32b391373 xen/include/public/memory.h
--- a/xen/include/public/memory.h
+++ b/xen/include/public/memory.h
@@ -294,6 +294,7 @@ typedef struct xen_pod_target xen_pod_ta
  * The call never fails. 
  */
 #define XENMEM_get_sharing_freed_pages    18
+#define XENMEM_get_sharing_shared_pages   19
 
 #endif /* __XEN_PUBLIC_MEMORY_H__ */
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 08 07:47:40 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 Dec 2011 07:47:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYYhP-0003M0-N2; Thu, 08 Dec 2011 07:47:23 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RYYhN-0003IL-Cr
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 07:47:21 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-9.tower-174.messagelabs.com!1323330392!4722130!1
X-Originating-IP: [208.97.132.202]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4yMDIgPT4gMTY1MzI=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7067 invoked from network); 8 Dec 2011 07:46:32 -0000
Received: from caiajhbdccac.dreamhost.com (HELO homiemail-a20.g.dreamhost.com)
	(208.97.132.202) by server-9.tower-174.messagelabs.com with SMTP;
	8 Dec 2011 07:46:32 -0000
Received: from homiemail-a20.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTP id 7FF937EC07D;
	Wed,  7 Dec 2011 23:46:31 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=TwCXeSa+TEN3R+1bWO3kYFLLBDkTCWNY1vMig4nCdkIk
	m+1H2ZfVAp4QU6HpxWaFl3y0CrBOepwvnxYqRE73dnJRFA8sKozhZZGFgEHlG4W3
	P4oZwvHjZeDY0MOf/dHsrxRReLRKAcID/eP4fLvg3D1MPLnIluvdiCKC9KBxgIk=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=fNNNsxEJVAn5+8UAXvthqFC8jbU=; b=o948aEmS+Gw
	wetfMY1TVTMrsK/4Hd47TFGEdTw5RLrBia8J51i6yFH16M4TZHYfVFI5Wr7oc7SF
	3q4wtBkvkVbg+IMm7TwWIb2c9IF8zjXLoFC7gI8YA0+WWxoZHsLfGSv8+PZCjuPL
	uQapz+g8TFAd73aws3AqviiqlllRgcVg=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTPSA id B93137EC07A; 
	Wed,  7 Dec 2011 23:46:30 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 65b32b3913736cd743af32227dd7b78103507ed9
Message-Id: <65b32b3913736cd743af.1323330444@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1323330435@xdev.gridcentric.ca>
References: <patchbomb.1323330435@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Thu, 08 Dec 2011 02:47:24 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: ian.campbell@citrix.com, andres@gridcentric.ca, tim@xen.org,
	keir.xen@gmail.com, JBeulich@suse.com, ian.jackson@citrix.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 09 of 18] x86/mm: Check how many mfns are shared,
 in addition to how many are saved
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/mm.c                 |   6 ------
 xen/arch/x86/mm/mem_sharing.c     |  31 ++++++++++++++++++++++++++++---
 xen/arch/x86/x86_64/compat/mm.c   |   6 ++++++
 xen/arch/x86/x86_64/mm.c          |   7 +++++++
 xen/include/asm-x86/mem_sharing.h |   1 +
 xen/include/public/memory.h       |   1 +
 6 files changed, 43 insertions(+), 9 deletions(-)


This patch also moves the existing sharing-related memory op to the
correct location, and adds logic to the audit() method that uses the
new information.

This patch only provides the Xen implementation of the domctls.

Signed-off-by: Adin Scannell <adin@scannell.ca>

diff -r 24d514cd4dee -r 65b32b391373 xen/arch/x86/mm.c
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -119,7 +119,6 @@
 #include <xen/trace.h>
 #include <asm/setup.h>
 #include <asm/fixmap.h>
-#include <asm/mem_sharing.h>
 
 /*
  * Mapping of first 2 or 4 megabytes of memory. This is mapped with 4kB
@@ -5093,11 +5092,6 @@ long arch_memory_op(int op, XEN_GUEST_HA
         return rc;
     }
 
-#ifdef __x86_64__
-    case XENMEM_get_sharing_freed_pages:
-        return mem_sharing_get_nr_saved_mfns();
-#endif
-
     default:
         return subarch_memory_op(op, arg);
     }
diff -r 24d514cd4dee -r 65b32b391373 xen/arch/x86/mm/mem_sharing.c
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -75,6 +75,7 @@ static inline int mem_sharing_audit(void
 
 static shr_handle_t next_handle = 1;
 static atomic_t nr_saved_mfns   = ATOMIC_INIT(0); 
+static atomic_t nr_shared_mfns  = ATOMIC_INIT(0);
 
 typedef struct gfn_info
 {
@@ -153,9 +154,12 @@ static struct page_info* mem_sharing_loo
 static int mem_sharing_audit(void)
 {
     int errors = 0;
+    unsigned long count_expected;
+    unsigned long count_found = 0;
     struct list_head *ae;
 
     ASSERT(shr_locked_by_me());
+    count_expected = atomic_read(&nr_shared_mfns);
 
     list_for_each(ae, &shr_audit_list)
     {
@@ -194,6 +198,7 @@ static int mem_sharing_audit(void)
            errors++;
         }
 
+        count_found++;
         /* Check if all GFNs map to the MFN, and the p2m types */
         list_for_each(le, &pg->shared_info->gfns)
         {
@@ -239,6 +244,13 @@ static int mem_sharing_audit(void)
         }
     }
 
+    if ( count_found != count_expected )
+    {
+        MEM_SHARING_DEBUG("Expected %ld shared mfns, found %ld.",
+                          count_expected, count_found);
+        errors++;
+    }
+
     return errors;
 }
 #endif
@@ -296,6 +308,11 @@ unsigned int mem_sharing_get_nr_saved_mf
     return ((unsigned int)atomic_read(&nr_saved_mfns));
 }
 
+unsigned int mem_sharing_get_nr_shared_mfns(void)
+{
+    return (unsigned int)atomic_read(&nr_shared_mfns);
+}
+
 int mem_sharing_sharing_resume(struct domain *d)
 {
     mem_event_response_t rsp;
@@ -570,10 +587,11 @@ int mem_sharing_share_pages(struct domai
         BUG_ON(set_shared_p2m_entry(d, gfn->gfn, smfn) == 0);
         if ( single_client_gfn )
         {
-            /* Only increase the per-domain count when we are actually
+            /* Only increase the stats counts when we are actually
              * sharing. And don't increase it should we ever re-share */
             atomic_inc(&d->shr_pages);
             ASSERT( cd == d );
+            atomic_inc(&nr_shared_mfns);
         }
         put_domain(d);
     }
@@ -654,10 +672,14 @@ gfn_found:
     if ( flags & MEM_SHARING_DESTROY_GFN )
     {
         mem_sharing_gfn_destroy(gfn_info, !last_gfn);
-        if ( !last_gfn ) 
+        if ( last_gfn )
+        {
+            atomic_dec(&nr_shared_mfns);
+        } else {
             /* Even though we don't allocate a private page, we have to account
              * for the MFN that originally backed this PFN. */
             atomic_dec(&nr_saved_mfns);
+        }
 
         if ( last_gfn )
         {
@@ -707,8 +729,11 @@ gfn_found:
     put_page_and_type(old_page);
 
 private_page_found:    
-    if ( !last_gfn ) 
+    if ( last_gfn ) {
+        atomic_dec(&nr_shared_mfns);
+    } else {
         atomic_dec(&nr_saved_mfns);
+    }
 
     if ( p2m_change_type(d, gfn, p2m_ram_shared, p2m_ram_rw) != 
                                                 p2m_ram_shared ) 
diff -r 24d514cd4dee -r 65b32b391373 xen/arch/x86/x86_64/compat/mm.c
--- a/xen/arch/x86/x86_64/compat/mm.c
+++ b/xen/arch/x86/x86_64/compat/mm.c
@@ -205,6 +205,12 @@ int compat_arch_memory_op(int op, XEN_GU
         break;
     }
 
+    case XENMEM_get_sharing_freed_pages:
+        return mem_sharing_get_nr_saved_mfns();
+
+    case XENMEM_get_sharing_shared_pages:
+        return mem_sharing_get_nr_shared_mfns();
+
     default:
         rc = -ENOSYS;
         break;
diff -r 24d514cd4dee -r 65b32b391373 xen/arch/x86/x86_64/mm.c
--- a/xen/arch/x86/x86_64/mm.c
+++ b/xen/arch/x86/x86_64/mm.c
@@ -34,6 +34,7 @@
 #include <asm/msr.h>
 #include <asm/setup.h>
 #include <asm/numa.h>
+#include <asm/mem_sharing.h>
 #include <public/memory.h>
 
 /* Parameters for PFN/MADDR compression. */
@@ -1090,6 +1091,12 @@ long subarch_memory_op(int op, XEN_GUEST
 
         break;
 
+    case XENMEM_get_sharing_freed_pages:
+        return mem_sharing_get_nr_saved_mfns();
+
+    case XENMEM_get_sharing_shared_pages:
+        return mem_sharing_get_nr_shared_mfns();
+
     default:
         rc = -ENOSYS;
         break;
diff -r 24d514cd4dee -r 65b32b391373 xen/include/asm-x86/mem_sharing.h
--- a/xen/include/asm-x86/mem_sharing.h
+++ b/xen/include/asm-x86/mem_sharing.h
@@ -40,6 +40,7 @@ struct page_sharing_info
     (is_hvm_domain(_d) && paging_mode_hap(_d)) 
 
 unsigned int mem_sharing_get_nr_saved_mfns(void);
+unsigned int mem_sharing_get_nr_shared_mfns(void);
 int mem_sharing_nominate_page(struct domain *d, 
                               unsigned long gfn,
                               int expected_refcnt,
diff -r 24d514cd4dee -r 65b32b391373 xen/include/public/memory.h
--- a/xen/include/public/memory.h
+++ b/xen/include/public/memory.h
@@ -294,6 +294,7 @@ typedef struct xen_pod_target xen_pod_ta
  * The call never fails. 
  */
 #define XENMEM_get_sharing_freed_pages    18
+#define XENMEM_get_sharing_shared_pages   19
 
 #endif /* __XEN_PUBLIC_MEMORY_H__ */
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 08 07:47:40 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 Dec 2011 07:47:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYYhD-0003Gq-2h; Thu, 08 Dec 2011 07:47:11 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RYYhA-0003GG-Vj
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 07:47:09 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-7.tower-27.messagelabs.com!1323330332!59899794!1
X-Originating-IP: [208.97.132.145]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNDUgPT4gMTY3OTU=\n
X-StarScan-Version: 6.4.2; banners=-,-,lists.xensource.com
X-VirusChecked: Checked
Received: (qmail 16788 invoked from network); 8 Dec 2011 07:45:33 -0000
Received: from caiajhbdcbef.dreamhost.com (HELO homiemail-a20.g.dreamhost.com)
	(208.97.132.145) by server-7.tower-27.messagelabs.com with SMTP;
	8 Dec 2011 07:45:33 -0000
Received: from homiemail-a20.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTP id B6C9C7EC063;
	Wed,  7 Dec 2011 23:46:21 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id:date
	:from:to:cc; q=dns; s=lagarcavilla.org; b=mU74OBwBAuWSzIWCHoYNHB
	SXViLAEG2RznGJBXMLFq7mjZtSAz5CZLpS/6LOywJ7QZ7SggYdc54pJ7leHUcC9P
	Vr7fI5yRPm/CmDO42Tyf0nj8W8xzTCTXJyskz86Phhyma46B9s0bkA/jrMudsGw5
	QdPvEHB84pge7pZnAseZk=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:date:from:to:cc; s=lagarcavilla.org; bh=j7VTq0LDOzTs
	Z1ceyBaOtPSx6xo=; b=bDTe2bxNcvMDxcN7P+tMSNOAuZmhaqqGqAodJyTBA1UY
	BKLa/ihDGR8eA8sWOVUIbzlM439E084METx5iuzu7OfeZX99i0C7DcLBBxjsgiHq
	71WmYO8mGVVetaXFSOD9kRgWnu0fTETziWYOYoqYpADLZJFoR+PlHv5/raF7vig=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTPSA id DA80B7EC061; 
	Wed,  7 Dec 2011 23:46:20 -0800 (PST)
MIME-Version: 1.0
Message-Id: <patchbomb.1323330435@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Thu, 08 Dec 2011 02:47:15 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: ian.campbell@citrix.com, andres@gridcentric.ca, tim@xen.org,
	keir.xen@gmail.com, JBeulich@suse.com, ian.jackson@citrix.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 00 of 18] Memory sharing overhaul
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This patch series proposes an overhaul of the memory sharing code.

Aside from bug fixes and cleanups, the main features are:
- Polling of stats via libxc, libxl and console
- Removal of global sharing hashtable and global sharing lock 
 (if audit disabled)
- Turned sharing audits into a domctl
- New domctl to populate vacant physmap entries with shared 
 pages.

As a result, the domctl interface to sharing changes. The only in-tree
consumer of this interface is updated in the current series. It is 
important that if any out-of-tree consumer exists, that they state
their opinion on this interface change.

Patches 5 to 8, 10, 11, 15 and 18 are tools patches.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Signed-off-by: Adin Scannell <adin@scannell.ca>

 xen/arch/x86/mm.c                     |    6 +-
 xen/arch/x86/mm/mem_sharing.c         |   91 +++--
 xen/arch/x86/mm.c                     |    2 +-
 xen/arch/x86/mm/mem_sharing.c         |  526 +++++++++++++++++----------------
 xen/include/asm-x86/mem_sharing.h     |   15 +-
 xen/include/asm-x86/mm.h              |   11 +-
 xen/include/public/domctl.h           |    3 +
 xen/arch/x86/mm/mem_sharing.c         |   65 +++-
 xen/include/public/domctl.h           |    9 +
 tools/libxc/xc_memshr.c               |    3 +-
 tools/libxc/xenctrl.h                 |    1 +
 tools/libxc/xc_memshr.c               |   19 +-
 tools/libxc/xenctrl.h                 |    7 +-
 tools/blktap2/drivers/Makefile        |    2 +-
 tools/blktap2/drivers/tapdisk-image.c |    2 +-
 tools/blktap2/drivers/tapdisk-vbd.c   |    6 +-
 tools/blktap2/drivers/tapdisk.h       |    6 +-
 tools/memshr/bidir-daemon.c           |    4 +
 tools/memshr/bidir-hash.h             |   13 +-
 tools/memshr/interface.c              |   31 +-
 tools/memshr/memshr.h                 |   11 +-
 tools/libxl/xl.h                      |    1 +
 tools/libxl/xl_cmdimpl.c              |   85 +++++
 tools/libxl/xl_cmdtable.c             |    6 +
 xen/arch/x86/mm.c                     |    6 -
 xen/arch/x86/mm/mem_sharing.c         |   31 +-
 xen/arch/x86/x86_64/compat/mm.c       |    6 +
 xen/arch/x86/x86_64/mm.c              |    7 +
 xen/include/asm-x86/mem_sharing.h     |    1 +
 xen/include/public/memory.h           |    1 +
 tools/libxc/xc_private.c              |   10 +
 tools/libxc/xenctrl.h                 |    4 +
 tools/libxl/Makefile                  |    2 +-
 tools/libxl/xl_cmdimpl.c              |   13 +-
 xen/arch/x86/mm.c                     |    4 +-
 xen/include/asm-x86/mm.h              |    3 +
 xen/arch/x86/mm.c                     |   16 +-
 xen/arch/x86/mm/mem_sharing.c         |  169 +++++++++-
 xen/arch/x86/mm/mm-locks.h            |    6 +-
 xen/include/asm-x86/mm.h              |    2 +-
 xen/arch/x86/mm/mem_sharing.c         |  106 ++++++
 xen/include/public/domctl.h           |    3 +-
 tools/libxc/xc_memshr.c               |   23 +
 tools/libxc/xenctrl.h                 |    6 +
 xen/arch/ia64/xen/mm.c                |    6 +
 xen/arch/x86/mm/mem_sharing.c         |    8 +
 xen/common/keyhandler.c               |    7 +-
 xen/include/xen/mm.h                  |    3 +
 xen/arch/x86/mm/mem_sharing.c         |   17 +-
 xen/include/public/domctl.h           |    1 +
 tools/libxc/xc_memshr.c               |   14 +
 tools/libxc/xenctrl.h                 |    2 +
 52 files changed, 1005 insertions(+), 397 deletions(-)

______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
______________________________________________________________________

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 08 07:47:40 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 Dec 2011 07:47:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYYhN-0003KG-9Q; Thu, 08 Dec 2011 07:47:21 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RYYhM-0003Ho-Dd
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 07:47:20 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-3.tower-182.messagelabs.com!1323330390!6379726!1
X-Originating-IP: [208.97.132.66]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi42NiA9PiAxNTkwOQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15853 invoked from network); 8 Dec 2011 07:46:31 -0000
Received: from caiajhbdcagg.dreamhost.com (HELO homiemail-a20.g.dreamhost.com)
	(208.97.132.66) by server-3.tower-182.messagelabs.com with SMTP;
	8 Dec 2011 07:46:31 -0000
Received: from homiemail-a20.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTP id 8CEE67EC07B;
	Wed,  7 Dec 2011 23:46:30 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=BS7FgNl8LYtHEKo+sooBEUM5ZUyip3K3hZ8iYYhxbQtN
	Hlog7w1WwDimIyWnnIUDKZB1xc0r1OnzztfqejIoNSw4PFqCQdQkYpK6CtyVeW9s
	m3kkj3UrXmD0YXm6r9pTaaj36ybj3hPiKG1FN5bdw6g1aHAo7Fnlq4pUHUiCnGQ=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=vqpupc0EvGkLn/bG6WGNkUm9cao=; b=cgZWdmOrLtk
	vQ9gGz1ojBNTaMm52iS/CwmweCA2lYttCaj6/ZmZmplIlcCzmlH0tuHyEqNzEcSQ
	7nFe74KDV2Joedfbj9cLPUi8Ozkw+vOOVcgAX8HvS9BoxC6uunv0snqOWkUw+Ddr
	q3yrwOj+zoTPDREcreUtzEr3wS5bKb/0=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTPSA id 6FF467EC07A; 
	Wed,  7 Dec 2011 23:46:29 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 24d514cd4dee7d0d0cc924cf4db15b33449ce2c4
Message-Id: <24d514cd4dee7d0d0cc9.1323330443@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1323330435@xdev.gridcentric.ca>
References: <patchbomb.1323330435@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Thu, 08 Dec 2011 02:47:23 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: ian.campbell@citrix.com, andres@gridcentric.ca, tim@xen.org,
	keir.xen@gmail.com, JBeulich@suse.com, ian.jackson@citrix.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 08 of 18] Tools: Add a sharing command to xl for
 information about shared pages
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 tools/libxl/xl.h          |   1 +
 tools/libxl/xl_cmdimpl.c  |  85 +++++++++++++++++++++++++++++++++++++++++++++++
 tools/libxl/xl_cmdtable.c |   6 +++
 3 files changed, 92 insertions(+), 0 deletions(-)


Signed-off-by: Adin Scannell <adin@scannell.ca>

diff -r 8d2a8094ace5 -r 24d514cd4dee tools/libxl/xl.h
--- a/tools/libxl/xl.h
+++ b/tools/libxl/xl.h
@@ -28,6 +28,7 @@ struct cmd_spec {
 
 int main_vcpulist(int argc, char **argv);
 int main_info(int argc, char **argv);
+int main_sharing(int argc, char **argv);
 int main_cd_eject(int argc, char **argv);
 int main_cd_insert(int argc, char **argv);
 int main_console(int argc, char **argv);
diff -r 8d2a8094ace5 -r 24d514cd4dee tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -3755,6 +3755,91 @@ int main_info(int argc, char **argv)
     return 0;
 }
 
+static void sharing(int totals, const libxl_dominfo *info, int nb_domain)
+{
+    int i;
+
+    printf("Name                                        ID   Mem Shared\n");
+
+    for (i = 0; i < nb_domain; i++) {
+        char *domname;
+        unsigned shutdown_reason;
+        domname = libxl_domid_to_name(ctx, info[i].domid);
+        shutdown_reason = info[i].shutdown ? info[i].shutdown_reason : 0;
+        printf("%-40s %5d %5lu  %5lu\n",
+                domname,
+                info[i].domid,
+                (unsigned long) (info[i].current_memkb / 1024),
+                (unsigned long) (info[i].shared_memkb / 1024));
+        free(domname);
+    }
+
+    if (totals)
+    {
+        /* To be added with a future patch. */
+    }
+}
+
+int main_sharing(int argc, char **argv)
+{
+    int opt;
+    int option_index = 0;
+    static struct option long_options[] = {
+        {"help", 0, 0, 'h'},
+        {"totals", 0, 0, 't'},
+        {0, 0, 0, 0}
+    };
+    int totals = 0;
+
+    libxl_dominfo info_buf;
+    libxl_dominfo *info, *info_free=0;
+    int nb_domain, rc;
+
+    while ((opt = getopt_long(argc, argv, "ht", long_options, &option_index)) != -1) {
+        switch (opt) {
+        case 'h':
+            help("sharing");
+            return 0;
+        case 't':
+            totals = 1;
+            break;
+        default:
+            fprintf(stderr, "option `%c' not supported.\n", optopt);
+            break;
+        }
+    }
+
+    if (optind >= argc) {
+        info = libxl_list_domain(ctx, &nb_domain);
+        if (!info) {
+            fprintf(stderr, "libxl_domain_infolist failed.\n");
+            return 1;
+        }
+        info_free = info;
+    } else if (optind == argc-1) {
+        find_domain(argv[optind]);
+        rc = libxl_domain_info(ctx, &info_buf, domid);
+        if (rc == ERROR_INVAL) {
+            fprintf(stderr, "Error: Domain \'%s\' does not exist.\n",
+                argv[optind]);
+            return -rc;
+        }
+        if (rc) {
+            fprintf(stderr, "libxl_domain_info failed (code %d).\n", rc);
+            return -rc;
+        }
+        info = &info_buf;
+        nb_domain = 1;
+    } else {
+        help("sharing");
+        return 2;
+    }
+
+    sharing(totals, info, nb_domain);
+
+    return 0;
+}
+
 static int sched_credit_domain_get(
     int domid, libxl_sched_credit *scinfo)
 {
diff -r 8d2a8094ace5 -r 24d514cd4dee tools/libxl/xl_cmdtable.c
--- a/tools/libxl/xl_cmdtable.c
+++ b/tools/libxl/xl_cmdtable.c
@@ -189,6 +189,12 @@ struct cmd_spec cmd_table[] = {
       "Get information about Xen host",
       "-n, --numa         List host NUMA topology information",
     },
+    { "sharing",
+      &main_sharing, 0,
+      "Get information about page sharing",
+      "[options] [Domain]", 
+      "-t, --totals              Include host totals in the output",
+    },
     { "sched-credit",
       &main_sched_credit, 0,
       "Get/set credit scheduler parameters",

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 08 07:47:40 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 Dec 2011 07:47:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYYhD-0003Gq-2h; Thu, 08 Dec 2011 07:47:11 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RYYhA-0003GG-Vj
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 07:47:09 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-7.tower-27.messagelabs.com!1323330332!59899794!1
X-Originating-IP: [208.97.132.145]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNDUgPT4gMTY3OTU=\n
X-StarScan-Version: 6.4.2; banners=-,-,lists.xensource.com
X-VirusChecked: Checked
Received: (qmail 16788 invoked from network); 8 Dec 2011 07:45:33 -0000
Received: from caiajhbdcbef.dreamhost.com (HELO homiemail-a20.g.dreamhost.com)
	(208.97.132.145) by server-7.tower-27.messagelabs.com with SMTP;
	8 Dec 2011 07:45:33 -0000
Received: from homiemail-a20.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTP id B6C9C7EC063;
	Wed,  7 Dec 2011 23:46:21 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id:date
	:from:to:cc; q=dns; s=lagarcavilla.org; b=mU74OBwBAuWSzIWCHoYNHB
	SXViLAEG2RznGJBXMLFq7mjZtSAz5CZLpS/6LOywJ7QZ7SggYdc54pJ7leHUcC9P
	Vr7fI5yRPm/CmDO42Tyf0nj8W8xzTCTXJyskz86Phhyma46B9s0bkA/jrMudsGw5
	QdPvEHB84pge7pZnAseZk=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:date:from:to:cc; s=lagarcavilla.org; bh=j7VTq0LDOzTs
	Z1ceyBaOtPSx6xo=; b=bDTe2bxNcvMDxcN7P+tMSNOAuZmhaqqGqAodJyTBA1UY
	BKLa/ihDGR8eA8sWOVUIbzlM439E084METx5iuzu7OfeZX99i0C7DcLBBxjsgiHq
	71WmYO8mGVVetaXFSOD9kRgWnu0fTETziWYOYoqYpADLZJFoR+PlHv5/raF7vig=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTPSA id DA80B7EC061; 
	Wed,  7 Dec 2011 23:46:20 -0800 (PST)
MIME-Version: 1.0
Message-Id: <patchbomb.1323330435@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Thu, 08 Dec 2011 02:47:15 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: ian.campbell@citrix.com, andres@gridcentric.ca, tim@xen.org,
	keir.xen@gmail.com, JBeulich@suse.com, ian.jackson@citrix.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 00 of 18] Memory sharing overhaul
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This patch series proposes an overhaul of the memory sharing code.

Aside from bug fixes and cleanups, the main features are:
- Polling of stats via libxc, libxl and console
- Removal of global sharing hashtable and global sharing lock 
 (if audit disabled)
- Turned sharing audits into a domctl
- New domctl to populate vacant physmap entries with shared 
 pages.

As a result, the domctl interface to sharing changes. The only in-tree
consumer of this interface is updated in the current series. It is 
important that if any out-of-tree consumer exists, that they state
their opinion on this interface change.

Patches 5 to 8, 10, 11, 15 and 18 are tools patches.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Signed-off-by: Adin Scannell <adin@scannell.ca>

 xen/arch/x86/mm.c                     |    6 +-
 xen/arch/x86/mm/mem_sharing.c         |   91 +++--
 xen/arch/x86/mm.c                     |    2 +-
 xen/arch/x86/mm/mem_sharing.c         |  526 +++++++++++++++++----------------
 xen/include/asm-x86/mem_sharing.h     |   15 +-
 xen/include/asm-x86/mm.h              |   11 +-
 xen/include/public/domctl.h           |    3 +
 xen/arch/x86/mm/mem_sharing.c         |   65 +++-
 xen/include/public/domctl.h           |    9 +
 tools/libxc/xc_memshr.c               |    3 +-
 tools/libxc/xenctrl.h                 |    1 +
 tools/libxc/xc_memshr.c               |   19 +-
 tools/libxc/xenctrl.h                 |    7 +-
 tools/blktap2/drivers/Makefile        |    2 +-
 tools/blktap2/drivers/tapdisk-image.c |    2 +-
 tools/blktap2/drivers/tapdisk-vbd.c   |    6 +-
 tools/blktap2/drivers/tapdisk.h       |    6 +-
 tools/memshr/bidir-daemon.c           |    4 +
 tools/memshr/bidir-hash.h             |   13 +-
 tools/memshr/interface.c              |   31 +-
 tools/memshr/memshr.h                 |   11 +-
 tools/libxl/xl.h                      |    1 +
 tools/libxl/xl_cmdimpl.c              |   85 +++++
 tools/libxl/xl_cmdtable.c             |    6 +
 xen/arch/x86/mm.c                     |    6 -
 xen/arch/x86/mm/mem_sharing.c         |   31 +-
 xen/arch/x86/x86_64/compat/mm.c       |    6 +
 xen/arch/x86/x86_64/mm.c              |    7 +
 xen/include/asm-x86/mem_sharing.h     |    1 +
 xen/include/public/memory.h           |    1 +
 tools/libxc/xc_private.c              |   10 +
 tools/libxc/xenctrl.h                 |    4 +
 tools/libxl/Makefile                  |    2 +-
 tools/libxl/xl_cmdimpl.c              |   13 +-
 xen/arch/x86/mm.c                     |    4 +-
 xen/include/asm-x86/mm.h              |    3 +
 xen/arch/x86/mm.c                     |   16 +-
 xen/arch/x86/mm/mem_sharing.c         |  169 +++++++++-
 xen/arch/x86/mm/mm-locks.h            |    6 +-
 xen/include/asm-x86/mm.h              |    2 +-
 xen/arch/x86/mm/mem_sharing.c         |  106 ++++++
 xen/include/public/domctl.h           |    3 +-
 tools/libxc/xc_memshr.c               |   23 +
 tools/libxc/xenctrl.h                 |    6 +
 xen/arch/ia64/xen/mm.c                |    6 +
 xen/arch/x86/mm/mem_sharing.c         |    8 +
 xen/common/keyhandler.c               |    7 +-
 xen/include/xen/mm.h                  |    3 +
 xen/arch/x86/mm/mem_sharing.c         |   17 +-
 xen/include/public/domctl.h           |    1 +
 tools/libxc/xc_memshr.c               |   14 +
 tools/libxc/xenctrl.h                 |    2 +
 52 files changed, 1005 insertions(+), 397 deletions(-)

______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
______________________________________________________________________

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 08 07:47:40 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 Dec 2011 07:47:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYYhN-0003KG-9Q; Thu, 08 Dec 2011 07:47:21 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RYYhM-0003Ho-Dd
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 07:47:20 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-3.tower-182.messagelabs.com!1323330390!6379726!1
X-Originating-IP: [208.97.132.66]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi42NiA9PiAxNTkwOQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15853 invoked from network); 8 Dec 2011 07:46:31 -0000
Received: from caiajhbdcagg.dreamhost.com (HELO homiemail-a20.g.dreamhost.com)
	(208.97.132.66) by server-3.tower-182.messagelabs.com with SMTP;
	8 Dec 2011 07:46:31 -0000
Received: from homiemail-a20.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTP id 8CEE67EC07B;
	Wed,  7 Dec 2011 23:46:30 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=BS7FgNl8LYtHEKo+sooBEUM5ZUyip3K3hZ8iYYhxbQtN
	Hlog7w1WwDimIyWnnIUDKZB1xc0r1OnzztfqejIoNSw4PFqCQdQkYpK6CtyVeW9s
	m3kkj3UrXmD0YXm6r9pTaaj36ybj3hPiKG1FN5bdw6g1aHAo7Fnlq4pUHUiCnGQ=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=vqpupc0EvGkLn/bG6WGNkUm9cao=; b=cgZWdmOrLtk
	vQ9gGz1ojBNTaMm52iS/CwmweCA2lYttCaj6/ZmZmplIlcCzmlH0tuHyEqNzEcSQ
	7nFe74KDV2Joedfbj9cLPUi8Ozkw+vOOVcgAX8HvS9BoxC6uunv0snqOWkUw+Ddr
	q3yrwOj+zoTPDREcreUtzEr3wS5bKb/0=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTPSA id 6FF467EC07A; 
	Wed,  7 Dec 2011 23:46:29 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 24d514cd4dee7d0d0cc924cf4db15b33449ce2c4
Message-Id: <24d514cd4dee7d0d0cc9.1323330443@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1323330435@xdev.gridcentric.ca>
References: <patchbomb.1323330435@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Thu, 08 Dec 2011 02:47:23 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: ian.campbell@citrix.com, andres@gridcentric.ca, tim@xen.org,
	keir.xen@gmail.com, JBeulich@suse.com, ian.jackson@citrix.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 08 of 18] Tools: Add a sharing command to xl for
 information about shared pages
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 tools/libxl/xl.h          |   1 +
 tools/libxl/xl_cmdimpl.c  |  85 +++++++++++++++++++++++++++++++++++++++++++++++
 tools/libxl/xl_cmdtable.c |   6 +++
 3 files changed, 92 insertions(+), 0 deletions(-)


Signed-off-by: Adin Scannell <adin@scannell.ca>

diff -r 8d2a8094ace5 -r 24d514cd4dee tools/libxl/xl.h
--- a/tools/libxl/xl.h
+++ b/tools/libxl/xl.h
@@ -28,6 +28,7 @@ struct cmd_spec {
 
 int main_vcpulist(int argc, char **argv);
 int main_info(int argc, char **argv);
+int main_sharing(int argc, char **argv);
 int main_cd_eject(int argc, char **argv);
 int main_cd_insert(int argc, char **argv);
 int main_console(int argc, char **argv);
diff -r 8d2a8094ace5 -r 24d514cd4dee tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -3755,6 +3755,91 @@ int main_info(int argc, char **argv)
     return 0;
 }
 
+static void sharing(int totals, const libxl_dominfo *info, int nb_domain)
+{
+    int i;
+
+    printf("Name                                        ID   Mem Shared\n");
+
+    for (i = 0; i < nb_domain; i++) {
+        char *domname;
+        unsigned shutdown_reason;
+        domname = libxl_domid_to_name(ctx, info[i].domid);
+        shutdown_reason = info[i].shutdown ? info[i].shutdown_reason : 0;
+        printf("%-40s %5d %5lu  %5lu\n",
+                domname,
+                info[i].domid,
+                (unsigned long) (info[i].current_memkb / 1024),
+                (unsigned long) (info[i].shared_memkb / 1024));
+        free(domname);
+    }
+
+    if (totals)
+    {
+        /* To be added with a future patch. */
+    }
+}
+
+int main_sharing(int argc, char **argv)
+{
+    int opt;
+    int option_index = 0;
+    static struct option long_options[] = {
+        {"help", 0, 0, 'h'},
+        {"totals", 0, 0, 't'},
+        {0, 0, 0, 0}
+    };
+    int totals = 0;
+
+    libxl_dominfo info_buf;
+    libxl_dominfo *info, *info_free=0;
+    int nb_domain, rc;
+
+    while ((opt = getopt_long(argc, argv, "ht", long_options, &option_index)) != -1) {
+        switch (opt) {
+        case 'h':
+            help("sharing");
+            return 0;
+        case 't':
+            totals = 1;
+            break;
+        default:
+            fprintf(stderr, "option `%c' not supported.\n", optopt);
+            break;
+        }
+    }
+
+    if (optind >= argc) {
+        info = libxl_list_domain(ctx, &nb_domain);
+        if (!info) {
+            fprintf(stderr, "libxl_domain_infolist failed.\n");
+            return 1;
+        }
+        info_free = info;
+    } else if (optind == argc-1) {
+        find_domain(argv[optind]);
+        rc = libxl_domain_info(ctx, &info_buf, domid);
+        if (rc == ERROR_INVAL) {
+            fprintf(stderr, "Error: Domain \'%s\' does not exist.\n",
+                argv[optind]);
+            return -rc;
+        }
+        if (rc) {
+            fprintf(stderr, "libxl_domain_info failed (code %d).\n", rc);
+            return -rc;
+        }
+        info = &info_buf;
+        nb_domain = 1;
+    } else {
+        help("sharing");
+        return 2;
+    }
+
+    sharing(totals, info, nb_domain);
+
+    return 0;
+}
+
 static int sched_credit_domain_get(
     int domid, libxl_sched_credit *scinfo)
 {
diff -r 8d2a8094ace5 -r 24d514cd4dee tools/libxl/xl_cmdtable.c
--- a/tools/libxl/xl_cmdtable.c
+++ b/tools/libxl/xl_cmdtable.c
@@ -189,6 +189,12 @@ struct cmd_spec cmd_table[] = {
       "Get information about Xen host",
       "-n, --numa         List host NUMA topology information",
     },
+    { "sharing",
+      &main_sharing, 0,
+      "Get information about page sharing",
+      "[options] [Domain]", 
+      "-t, --totals              Include host totals in the output",
+    },
     { "sched-credit",
       &main_sched_credit, 0,
       "Get/set credit scheduler parameters",

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 08 07:47:40 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 Dec 2011 07:47:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYYhF-0003HE-GR; Thu, 08 Dec 2011 07:47:13 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RYYhE-0003GJ-TI
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 07:47:13 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-11.tower-21.messagelabs.com!1323330384!7191489!1
X-Originating-IP: [208.97.132.145]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNDUgPT4gMTY3OTU=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15824 invoked from network); 8 Dec 2011 07:46:24 -0000
Received: from caiajhbdcbef.dreamhost.com (HELO homiemail-a20.g.dreamhost.com)
	(208.97.132.145) by server-11.tower-21.messagelabs.com with SMTP;
	8 Dec 2011 07:46:24 -0000
Received: from homiemail-a20.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTP id CDA7B7EC065;
	Wed,  7 Dec 2011 23:46:23 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=UxaDVCwyWVrc8eG7rSlwUz4xZnTbtgQTKPJFmNHhAlA2
	mNE8mZ4QOM6s6FeknQ+ShSr7Q+UCT2rggfa1zI/njSZJCI6SHUzj97ORFeRsFDOA
	CbOzDCJi3J6zBfy6P0zSA4VCquUCMtN+CJNrIeerBZ2OB2MhJ7wfUemuutezx3w=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=n3JvKOudhDf2A/MhQNoamo5uzSs=; b=RtXjt03kSKu
	WxeVjgC468RlufYvloZoXfKfGSJqnN5cb2wW0EfbsZMCk+YWD4+R7Ml+qbAed77o
	IS31/j8nAgp70lc7E1IfkVzKXcfWPSMjXHrC3tmEs9B7Q0Jj5MSTJjg3IyWgxezV
	b32cR0WM+iQ85AIUYFIxVYuOArINOPl8=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTPSA id 0AB427EC061; 
	Wed,  7 Dec 2011 23:46:22 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 61da3fc46f0681c0d1be2912daf2ea96dd88ce63
Message-Id: <61da3fc46f0681c0d1be.1323330437@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1323330435@xdev.gridcentric.ca>
References: <patchbomb.1323330435@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Thu, 08 Dec 2011 02:47:17 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: ian.campbell@citrix.com, andres@gridcentric.ca, tim@xen.org,
	keir.xen@gmail.com, JBeulich@suse.com, ian.jackson@citrix.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 02 of 18] x86/mm: Making a page sharable sets
 PGT_validated, but making a page private doesn't expect it
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/mm.c |  2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)


Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r aeebbff899ff -r 61da3fc46f06 xen/arch/x86/mm.c
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -4347,7 +4347,7 @@ int page_make_private(struct domain *d, 
 
     /* We can only change the type if count is one */
     if ( (page->u.inuse.type_info & (PGT_type_mask | PGT_count_mask))
-         != (PGT_shared_page | 1) )
+         != (PGT_shared_page | PGT_validated | 1) )
     {
         put_page(page);
         spin_unlock(&d->page_alloc_lock);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 08 07:47:40 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 Dec 2011 07:47:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYYhF-0003HE-GR; Thu, 08 Dec 2011 07:47:13 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RYYhE-0003GJ-TI
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 07:47:13 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-11.tower-21.messagelabs.com!1323330384!7191489!1
X-Originating-IP: [208.97.132.145]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNDUgPT4gMTY3OTU=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15824 invoked from network); 8 Dec 2011 07:46:24 -0000
Received: from caiajhbdcbef.dreamhost.com (HELO homiemail-a20.g.dreamhost.com)
	(208.97.132.145) by server-11.tower-21.messagelabs.com with SMTP;
	8 Dec 2011 07:46:24 -0000
Received: from homiemail-a20.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTP id CDA7B7EC065;
	Wed,  7 Dec 2011 23:46:23 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=UxaDVCwyWVrc8eG7rSlwUz4xZnTbtgQTKPJFmNHhAlA2
	mNE8mZ4QOM6s6FeknQ+ShSr7Q+UCT2rggfa1zI/njSZJCI6SHUzj97ORFeRsFDOA
	CbOzDCJi3J6zBfy6P0zSA4VCquUCMtN+CJNrIeerBZ2OB2MhJ7wfUemuutezx3w=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=n3JvKOudhDf2A/MhQNoamo5uzSs=; b=RtXjt03kSKu
	WxeVjgC468RlufYvloZoXfKfGSJqnN5cb2wW0EfbsZMCk+YWD4+R7Ml+qbAed77o
	IS31/j8nAgp70lc7E1IfkVzKXcfWPSMjXHrC3tmEs9B7Q0Jj5MSTJjg3IyWgxezV
	b32cR0WM+iQ85AIUYFIxVYuOArINOPl8=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTPSA id 0AB427EC061; 
	Wed,  7 Dec 2011 23:46:22 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 61da3fc46f0681c0d1be2912daf2ea96dd88ce63
Message-Id: <61da3fc46f0681c0d1be.1323330437@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1323330435@xdev.gridcentric.ca>
References: <patchbomb.1323330435@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Thu, 08 Dec 2011 02:47:17 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: ian.campbell@citrix.com, andres@gridcentric.ca, tim@xen.org,
	keir.xen@gmail.com, JBeulich@suse.com, ian.jackson@citrix.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 02 of 18] x86/mm: Making a page sharable sets
 PGT_validated, but making a page private doesn't expect it
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/mm.c |  2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)


Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r aeebbff899ff -r 61da3fc46f06 xen/arch/x86/mm.c
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -4347,7 +4347,7 @@ int page_make_private(struct domain *d, 
 
     /* We can only change the type if count is one */
     if ( (page->u.inuse.type_info & (PGT_type_mask | PGT_count_mask))
-         != (PGT_shared_page | 1) )
+         != (PGT_shared_page | PGT_validated | 1) )
     {
         put_page(page);
         spin_unlock(&d->page_alloc_lock);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 08 07:47:41 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 Dec 2011 07: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.xensource.com>)
	id 1RYYhJ-0003Ip-Dn; Thu, 08 Dec 2011 07:47:17 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RYYhH-0003Gp-Ip
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 07:47:15 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-15.tower-182.messagelabs.com!1323330387!6302568!1
X-Originating-IP: [208.97.132.83]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi44MyA9PiAxNjMzMw==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13273 invoked from network); 8 Dec 2011 07:46:27 -0000
Received: from caiajhbdcaid.dreamhost.com (HELO homiemail-a20.g.dreamhost.com)
	(208.97.132.83) by server-15.tower-182.messagelabs.com with SMTP;
	8 Dec 2011 07:46:27 -0000
Received: from homiemail-a20.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTP id 0470B7EC076;
	Wed,  7 Dec 2011 23:46:27 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=P5W0sDf6cLhmEEXwRDcKCaXpnx8AJ1GKolQP3z6DD7fT
	P1BOqjgV6mLoU4KZnV3NIMpBjefYljHYLQM5+rwV0AfSm+1Kc+2HDLebfcFwNmPW
	WTrh81NhH3av/WXYusAEU6sD4rkV75v8DkWQ7CfzIZwyNjoW/0RQBrMfo3QyV/c=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=BUOqA9+mrFTv5X5/dxGgckkizX0=; b=fzXD8aM1DeY
	kHoV8z/JLDe0HUrUOHVY2VyuY4CtaOYj2FdpEsaqNYBPL0V+lUw6+5i5RBRD6/qP
	UTrFOwQLJHruxBYy5U0WfGxUfNvprrnyoNDfFcNgjXysfUp1qFxI7c/1yvHu7pGW
	Fc8ArHc8DJNV40nNtnwfB/wT6+zu4VpM=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTPSA id 1CC9A7EC061; 
	Wed,  7 Dec 2011 23:46:26 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: b398fc97ab19818b7a22f80d5162c25a25b88ba6
Message-Id: <b398fc97ab19818b7a22.1323330440@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1323330435@xdev.gridcentric.ca>
References: <patchbomb.1323330435@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Thu, 08 Dec 2011 02:47:20 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: ian.campbell@citrix.com, andres@gridcentric.ca, tim@xen.org,
	keir.xen@gmail.com, JBeulich@suse.com, ian.jackson@citrix.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 05 of 18] Tools: Do not assume sharing target is
 dom0 in libxc wrappers
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 tools/libxc/xc_memshr.c |  3 ++-
 tools/libxc/xenctrl.h   |  1 +
 2 files changed, 3 insertions(+), 1 deletions(-)


The libxc wrapper that shares two pages always assumed one
of the pages was mapped by dom0. Expand the API to specify
both sharing domains.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 2e8d5702f4c1 -r b398fc97ab19 tools/libxc/xc_memshr.c
--- a/tools/libxc/xc_memshr.c
+++ b/tools/libxc/xc_memshr.c
@@ -87,6 +87,7 @@ int xc_memshr_nominate_gref(xc_interface
 }
 
 int xc_memshr_share(xc_interface *xch,
+                    uint32_t source_domain,
                     uint64_t source_handle,
                     uint64_t client_handle)
 {
@@ -95,7 +96,7 @@ int xc_memshr_share(xc_interface *xch,
 
     domctl.cmd = XEN_DOMCTL_mem_sharing_op;
     domctl.interface_version = XEN_DOMCTL_INTERFACE_VERSION;
-    domctl.domain = 0;
+    domctl.domain = (domid_t) source_domain;
     op = &(domctl.u.mem_sharing_op);
     op->op = XEN_DOMCTL_MEM_EVENT_OP_SHARING_SHARE;
     op->u.share.source_handle = source_handle;
diff -r 2e8d5702f4c1 -r b398fc97ab19 tools/libxc/xenctrl.h
--- a/tools/libxc/xenctrl.h
+++ b/tools/libxc/xenctrl.h
@@ -1892,6 +1892,7 @@ int xc_memshr_nominate_gref(xc_interface
                             grant_ref_t gref,
                             uint64_t *handle);
 int xc_memshr_share(xc_interface *xch,
+                    uint32_t source_domain,
                     uint64_t source_handle,
                     uint64_t client_handle);
 int xc_memshr_domain_resume(xc_interface *xch,

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 08 07:47:41 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 Dec 2011 07: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.xensource.com>)
	id 1RYYhJ-0003Ip-Dn; Thu, 08 Dec 2011 07:47:17 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RYYhH-0003Gp-Ip
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 07:47:15 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-15.tower-182.messagelabs.com!1323330387!6302568!1
X-Originating-IP: [208.97.132.83]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi44MyA9PiAxNjMzMw==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13273 invoked from network); 8 Dec 2011 07:46:27 -0000
Received: from caiajhbdcaid.dreamhost.com (HELO homiemail-a20.g.dreamhost.com)
	(208.97.132.83) by server-15.tower-182.messagelabs.com with SMTP;
	8 Dec 2011 07:46:27 -0000
Received: from homiemail-a20.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTP id 0470B7EC076;
	Wed,  7 Dec 2011 23:46:27 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=P5W0sDf6cLhmEEXwRDcKCaXpnx8AJ1GKolQP3z6DD7fT
	P1BOqjgV6mLoU4KZnV3NIMpBjefYljHYLQM5+rwV0AfSm+1Kc+2HDLebfcFwNmPW
	WTrh81NhH3av/WXYusAEU6sD4rkV75v8DkWQ7CfzIZwyNjoW/0RQBrMfo3QyV/c=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=BUOqA9+mrFTv5X5/dxGgckkizX0=; b=fzXD8aM1DeY
	kHoV8z/JLDe0HUrUOHVY2VyuY4CtaOYj2FdpEsaqNYBPL0V+lUw6+5i5RBRD6/qP
	UTrFOwQLJHruxBYy5U0WfGxUfNvprrnyoNDfFcNgjXysfUp1qFxI7c/1yvHu7pGW
	Fc8ArHc8DJNV40nNtnwfB/wT6+zu4VpM=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTPSA id 1CC9A7EC061; 
	Wed,  7 Dec 2011 23:46:26 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: b398fc97ab19818b7a22f80d5162c25a25b88ba6
Message-Id: <b398fc97ab19818b7a22.1323330440@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1323330435@xdev.gridcentric.ca>
References: <patchbomb.1323330435@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Thu, 08 Dec 2011 02:47:20 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: ian.campbell@citrix.com, andres@gridcentric.ca, tim@xen.org,
	keir.xen@gmail.com, JBeulich@suse.com, ian.jackson@citrix.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 05 of 18] Tools: Do not assume sharing target is
 dom0 in libxc wrappers
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 tools/libxc/xc_memshr.c |  3 ++-
 tools/libxc/xenctrl.h   |  1 +
 2 files changed, 3 insertions(+), 1 deletions(-)


The libxc wrapper that shares two pages always assumed one
of the pages was mapped by dom0. Expand the API to specify
both sharing domains.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 2e8d5702f4c1 -r b398fc97ab19 tools/libxc/xc_memshr.c
--- a/tools/libxc/xc_memshr.c
+++ b/tools/libxc/xc_memshr.c
@@ -87,6 +87,7 @@ int xc_memshr_nominate_gref(xc_interface
 }
 
 int xc_memshr_share(xc_interface *xch,
+                    uint32_t source_domain,
                     uint64_t source_handle,
                     uint64_t client_handle)
 {
@@ -95,7 +96,7 @@ int xc_memshr_share(xc_interface *xch,
 
     domctl.cmd = XEN_DOMCTL_mem_sharing_op;
     domctl.interface_version = XEN_DOMCTL_INTERFACE_VERSION;
-    domctl.domain = 0;
+    domctl.domain = (domid_t) source_domain;
     op = &(domctl.u.mem_sharing_op);
     op->op = XEN_DOMCTL_MEM_EVENT_OP_SHARING_SHARE;
     op->u.share.source_handle = source_handle;
diff -r 2e8d5702f4c1 -r b398fc97ab19 tools/libxc/xenctrl.h
--- a/tools/libxc/xenctrl.h
+++ b/tools/libxc/xenctrl.h
@@ -1892,6 +1892,7 @@ int xc_memshr_nominate_gref(xc_interface
                             grant_ref_t gref,
                             uint64_t *handle);
 int xc_memshr_share(xc_interface *xch,
+                    uint32_t source_domain,
                     uint64_t source_handle,
                     uint64_t client_handle);
 int xc_memshr_domain_resume(xc_interface *xch,

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 08 07:47:41 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 Dec 2011 07: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.xensource.com>)
	id 1RYYhQ-0003Md-Gg; Thu, 08 Dec 2011 07:47:24 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RYYhP-0003Iz-69
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 07:47:23 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-10.tower-216.messagelabs.com!1323330394!6518719!1
X-Originating-IP: [208.97.132.145]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNDUgPT4gMTY3OTU=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21143 invoked from network); 8 Dec 2011 07:46:35 -0000
Received: from caiajhbdcbef.dreamhost.com (HELO homiemail-a20.g.dreamhost.com)
	(208.97.132.145) by server-10.tower-216.messagelabs.com with SMTP;
	8 Dec 2011 07:46:35 -0000
Received: from homiemail-a20.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTP id 71CD67EC065;
	Wed,  7 Dec 2011 23:46:34 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=uDwzSoDfNuusGOX1HHrJ0tD5HI0CZMmLC78O9F2lFzoC
	5W/ThXop26jnUAfJ1R6i2uioLyM4armlRo6QTNR80jkz0rgUYk0AoZLBh/U4kOEv
	nZKMnezKkVY4WIgJVa37A8i/ggCYupKUecmFHReswui97JOO6ah/9wtmxHYGOyE=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=H42d9RVM+GT4UaqbLIzkihnaOus=; b=m3k368rgioX
	I0XUK2vLltsx9EUhpXkk+XX619z4Pa8CG+deY9ejkGiuNIbN6OhPVR7yYkdHVk7M
	DLoyfHAxahCGB9/OaxLKpTW39ARhvQIYmjjbriZ3g1edvDgZf8AwavzqFZzx1+0t
	xk9is/jtnDvFQLiNqFD8EZkghUE9gGJQ=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTPSA id A599B7EC063; 
	Wed,  7 Dec 2011 23:46:33 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: ecf95feef9ac5a7d0b794c0b463fd4f6ec99d1ab
Message-Id: <ecf95feef9ac5a7d0b79.1323330447@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1323330435@xdev.gridcentric.ca>
References: <patchbomb.1323330435@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Thu, 08 Dec 2011 02:47:27 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: ian.campbell@citrix.com, andres@gridcentric.ca, tim@xen.org,
	keir.xen@gmail.com, JBeulich@suse.com, ian.jackson@citrix.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 12 of 18] x86/mm: Make page_lock/unlock() in
 arch/x86/mm.c externally callable
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/mm.c        |  4 ++--
 xen/include/asm-x86/mm.h |  3 +++
 2 files changed, 5 insertions(+), 2 deletions(-)


This is necessary for a new consumer of page_lock/unlock to follow in
the series.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r cde3529132c1 -r ecf95feef9ac xen/arch/x86/mm.c
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -1718,7 +1718,7 @@ static int free_l4_table(struct page_inf
 #define free_l4_table(page, preemptible) (-EINVAL)
 #endif
 
-static int page_lock(struct page_info *page)
+int page_lock(struct page_info *page)
 {
     unsigned long x, nx;
 
@@ -1735,7 +1735,7 @@ static int page_lock(struct page_info *p
     return 1;
 }
 
-static void page_unlock(struct page_info *page)
+void page_unlock(struct page_info *page)
 {
     unsigned long x, nx, y = page->u.inuse.type_info;
 
diff -r cde3529132c1 -r ecf95feef9ac xen/include/asm-x86/mm.h
--- a/xen/include/asm-x86/mm.h
+++ b/xen/include/asm-x86/mm.h
@@ -337,6 +337,9 @@ int is_iomem_page(unsigned long mfn);
 
 void clear_superpage_mark(struct page_info *page);
 
+int page_lock(struct page_info *page);
+void page_unlock(struct page_info *page);
+
 struct domain *page_get_owner_and_reference(struct page_info *page);
 void put_page(struct page_info *page);
 int  get_page(struct page_info *page, struct domain *domain);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 08 07:47:41 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 Dec 2011 07: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.xensource.com>)
	id 1RYYhQ-0003Md-Gg; Thu, 08 Dec 2011 07:47:24 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RYYhP-0003Iz-69
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 07:47:23 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-10.tower-216.messagelabs.com!1323330394!6518719!1
X-Originating-IP: [208.97.132.145]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNDUgPT4gMTY3OTU=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21143 invoked from network); 8 Dec 2011 07:46:35 -0000
Received: from caiajhbdcbef.dreamhost.com (HELO homiemail-a20.g.dreamhost.com)
	(208.97.132.145) by server-10.tower-216.messagelabs.com with SMTP;
	8 Dec 2011 07:46:35 -0000
Received: from homiemail-a20.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTP id 71CD67EC065;
	Wed,  7 Dec 2011 23:46:34 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=uDwzSoDfNuusGOX1HHrJ0tD5HI0CZMmLC78O9F2lFzoC
	5W/ThXop26jnUAfJ1R6i2uioLyM4armlRo6QTNR80jkz0rgUYk0AoZLBh/U4kOEv
	nZKMnezKkVY4WIgJVa37A8i/ggCYupKUecmFHReswui97JOO6ah/9wtmxHYGOyE=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=H42d9RVM+GT4UaqbLIzkihnaOus=; b=m3k368rgioX
	I0XUK2vLltsx9EUhpXkk+XX619z4Pa8CG+deY9ejkGiuNIbN6OhPVR7yYkdHVk7M
	DLoyfHAxahCGB9/OaxLKpTW39ARhvQIYmjjbriZ3g1edvDgZf8AwavzqFZzx1+0t
	xk9is/jtnDvFQLiNqFD8EZkghUE9gGJQ=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTPSA id A599B7EC063; 
	Wed,  7 Dec 2011 23:46:33 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: ecf95feef9ac5a7d0b794c0b463fd4f6ec99d1ab
Message-Id: <ecf95feef9ac5a7d0b79.1323330447@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1323330435@xdev.gridcentric.ca>
References: <patchbomb.1323330435@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Thu, 08 Dec 2011 02:47:27 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: ian.campbell@citrix.com, andres@gridcentric.ca, tim@xen.org,
	keir.xen@gmail.com, JBeulich@suse.com, ian.jackson@citrix.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 12 of 18] x86/mm: Make page_lock/unlock() in
 arch/x86/mm.c externally callable
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/mm.c        |  4 ++--
 xen/include/asm-x86/mm.h |  3 +++
 2 files changed, 5 insertions(+), 2 deletions(-)


This is necessary for a new consumer of page_lock/unlock to follow in
the series.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r cde3529132c1 -r ecf95feef9ac xen/arch/x86/mm.c
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -1718,7 +1718,7 @@ static int free_l4_table(struct page_inf
 #define free_l4_table(page, preemptible) (-EINVAL)
 #endif
 
-static int page_lock(struct page_info *page)
+int page_lock(struct page_info *page)
 {
     unsigned long x, nx;
 
@@ -1735,7 +1735,7 @@ static int page_lock(struct page_info *p
     return 1;
 }
 
-static void page_unlock(struct page_info *page)
+void page_unlock(struct page_info *page)
 {
     unsigned long x, nx, y = page->u.inuse.type_info;
 
diff -r cde3529132c1 -r ecf95feef9ac xen/include/asm-x86/mm.h
--- a/xen/include/asm-x86/mm.h
+++ b/xen/include/asm-x86/mm.h
@@ -337,6 +337,9 @@ int is_iomem_page(unsigned long mfn);
 
 void clear_superpage_mark(struct page_info *page);
 
+int page_lock(struct page_info *page);
+void page_unlock(struct page_info *page);
+
 struct domain *page_get_owner_and_reference(struct page_info *page);
 void put_page(struct page_info *page);
 int  get_page(struct page_info *page, struct domain *domain);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 08 08:13:28 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 Dec 2011 08:13:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYZ68-0005xF-Cj; Thu, 08 Dec 2011 08:12:56 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RYZ66-0005x7-Nk
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 08:12:54 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1323331926!5833644!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM2NTQ=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11326 invoked from network); 8 Dec 2011 08:12:07 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-13.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 8 Dec 2011 08:12:07 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 08 Dec 2011 08:12:06 +0000
Message-Id: <4EE07F910200007800066299@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 08 Dec 2011 08:12:49 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: <ian.jackson@eu.citrix.com>
References: <osstest-10409-mainreport@xen.org>
In-Reply-To: <osstest-10409-mainreport@xen.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [xen-unstable test] 10409: regressions - trouble:
 broken/fail/pass
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 07.12.11 at 16:57, xen.org <ian.jackson@eu.citrix.com> wrote:
> flight 10409 xen-unstable real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/10409/ 
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking:
>  test-amd64-i386-xl-win7-amd64  3 host-install(3)              broken

earwig was supposed to be removed from the test pool - it's
apparently back in, again running on c/s 24069:801ca6c0fbfa
instead of the claimed

> version targeted for testing:
>  xen                  38eb74c01d9d
> baseline version:
>  xen                  62ff6a318c5d

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 08 08:13:28 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 Dec 2011 08:13:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYZ68-0005xF-Cj; Thu, 08 Dec 2011 08:12:56 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RYZ66-0005x7-Nk
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 08:12:54 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1323331926!5833644!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM2NTQ=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11326 invoked from network); 8 Dec 2011 08:12:07 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-13.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 8 Dec 2011 08:12:07 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 08 Dec 2011 08:12:06 +0000
Message-Id: <4EE07F910200007800066299@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 08 Dec 2011 08:12:49 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: <ian.jackson@eu.citrix.com>
References: <osstest-10409-mainreport@xen.org>
In-Reply-To: <osstest-10409-mainreport@xen.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [xen-unstable test] 10409: regressions - trouble:
 broken/fail/pass
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 07.12.11 at 16:57, xen.org <ian.jackson@eu.citrix.com> wrote:
> flight 10409 xen-unstable real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/10409/ 
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking:
>  test-amd64-i386-xl-win7-amd64  3 host-install(3)              broken

earwig was supposed to be removed from the test pool - it's
apparently back in, again running on c/s 24069:801ca6c0fbfa
instead of the claimed

> version targeted for testing:
>  xen                  38eb74c01d9d
> baseline version:
>  xen                  62ff6a318c5d

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 08 08:20:48 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 Dec 2011 08:20:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYZDX-0006A9-B1; Thu, 08 Dec 2011 08:20:35 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RYZDV-0006A3-VM
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 08:20:34 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1323332386!699874!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTI0OA==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23390 invoked from network); 8 Dec 2011 08:19:46 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Dec 2011 08:19:46 -0000
X-IronPort-AV: E=Sophos;i="4.71,319,1320624000"; 
   d="scan'208";a="9355623"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Dec 2011 08:19:46 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 8 Dec 2011
	08:19:45 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Bastian Blank <waldi@debian.org>
Date: Thu, 8 Dec 2011 08:19:45 +0000
In-Reply-To: <1323292396-19523-2-git-send-email-waldi@debian.org>
References: <1323292396-19523-1-git-send-email-waldi@debian.org>
	<1323292396-19523-2-git-send-email-waldi@debian.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323332385.2969.46.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH 1/4] xen: Add privcmd device driver
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2011-12-07 at 21:13 +0000, Bastian Blank wrote:
> +static int __init privcmd_init(void)
> +{
> +       int err;
> +
> +       if (!xen_domain())
> +               return -ENODEV;
> +
> +       err = misc_register(&privcmd_dev);
> +       if (err != 0) {
> +               printk(KERN_ERR "Could not register privcmd device\n"); 

Should say "...register Xen privcmd device". Otherwise:

Acked-by: Ian Campbell <ian.campbell@citrix.com>




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 08 08:20:48 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 Dec 2011 08:20:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYZDX-0006A9-B1; Thu, 08 Dec 2011 08:20:35 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RYZDV-0006A3-VM
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 08:20:34 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1323332386!699874!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTI0OA==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23390 invoked from network); 8 Dec 2011 08:19:46 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Dec 2011 08:19:46 -0000
X-IronPort-AV: E=Sophos;i="4.71,319,1320624000"; 
   d="scan'208";a="9355623"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Dec 2011 08:19:46 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 8 Dec 2011
	08:19:45 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Bastian Blank <waldi@debian.org>
Date: Thu, 8 Dec 2011 08:19:45 +0000
In-Reply-To: <1323292396-19523-2-git-send-email-waldi@debian.org>
References: <1323292396-19523-1-git-send-email-waldi@debian.org>
	<1323292396-19523-2-git-send-email-waldi@debian.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323332385.2969.46.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH 1/4] xen: Add privcmd device driver
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2011-12-07 at 21:13 +0000, Bastian Blank wrote:
> +static int __init privcmd_init(void)
> +{
> +       int err;
> +
> +       if (!xen_domain())
> +               return -ENODEV;
> +
> +       err = misc_register(&privcmd_dev);
> +       if (err != 0) {
> +               printk(KERN_ERR "Could not register privcmd device\n"); 

Should say "...register Xen privcmd device". Otherwise:

Acked-by: Ian Campbell <ian.campbell@citrix.com>




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 08 08:21:46 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 Dec 2011 08:21:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYZET-0006D5-Pu; Thu, 08 Dec 2011 08:21:33 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RYZES-0006Cn-5V
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 08:21:32 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1323332443!6605109!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTI0OA==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22416 invoked from network); 8 Dec 2011 08:20:43 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Dec 2011 08:20:43 -0000
X-IronPort-AV: E=Sophos;i="4.71,319,1320624000"; 
   d="scan'208";a="9355651"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Dec 2011 08:20:43 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 8 Dec 2011
	08:20:43 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Bastian Blank <waldi@debian.org>
Date: Thu, 8 Dec 2011 08:20:42 +0000
In-Reply-To: <1323292396-19523-3-git-send-email-waldi@debian.org>
References: <1323292396-19523-1-git-send-email-waldi@debian.org>
	<1323292396-19523-3-git-send-email-waldi@debian.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323332442.2969.47.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH 2/4] xen: Add xenbus device driver
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2011-12-07 at 21:13 +0000, Bastian Blank wrote:
> Access to xenbus is currently handled via xenfs. This adds a device
> driver for xenbus and makes xenfs use this code.
> 
> Signed-off-by: Bastian Blank <waldi@debian.org>
Acked-by: Ian Campbell <ian.campbell@citrix.com>

> ---
>  drivers/xen/xenbus/Makefile                        |    1 +
>  drivers/xen/xenbus/xenbus_comms.h                  |    4 ++
>  .../xenbus.c => xenbus/xenbus_dev_frontend.c}      |   37 ++++++++++++++++++--
>  drivers/xen/xenfs/Makefile                         |    2 +-
>  drivers/xen/xenfs/super.c                          |    3 +-
>  drivers/xen/xenfs/xenfs.h                          |    1 -
>  6 files changed, 42 insertions(+), 6 deletions(-)
>  rename drivers/xen/{xenfs/xenbus.c => xenbus/xenbus_dev_frontend.c} (95%)
> 
> diff --git a/drivers/xen/xenbus/Makefile b/drivers/xen/xenbus/Makefile
> index 8dca685..a2ea363 100644
> --- a/drivers/xen/xenbus/Makefile
> +++ b/drivers/xen/xenbus/Makefile
> @@ -1,4 +1,5 @@
>  obj-y	+= xenbus.o
> +obj-y	+= xenbus_dev_frontend.o
>  
>  xenbus-objs =
>  xenbus-objs += xenbus_client.o
> diff --git a/drivers/xen/xenbus/xenbus_comms.h b/drivers/xen/xenbus/xenbus_comms.h
> index c21db75..6e42800 100644
> --- a/drivers/xen/xenbus/xenbus_comms.h
> +++ b/drivers/xen/xenbus/xenbus_comms.h
> @@ -31,6 +31,8 @@
>  #ifndef _XENBUS_COMMS_H
>  #define _XENBUS_COMMS_H
>  
> +#include <linux/fs.h>
> +
>  int xs_init(void);
>  int xb_init_comms(void);
>  
> @@ -43,4 +45,6 @@ int xs_input_avail(void);
>  extern struct xenstore_domain_interface *xen_store_interface;
>  extern int xen_store_evtchn;
>  
> +extern const struct file_operations xen_xenbus_fops;
> +
>  #endif /* _XENBUS_COMMS_H */
> diff --git a/drivers/xen/xenfs/xenbus.c b/drivers/xen/xenbus/xenbus_dev_frontend.c
> similarity index 95%
> rename from drivers/xen/xenfs/xenbus.c
> rename to drivers/xen/xenbus/xenbus_dev_frontend.c
> index bbd000f..fb30cff 100644
> --- a/drivers/xen/xenfs/xenbus.c
> +++ b/drivers/xen/xenbus/xenbus_dev_frontend.c
> @@ -52,13 +52,16 @@
>  #include <linux/namei.h>
>  #include <linux/string.h>
>  #include <linux/slab.h>
> +#include <linux/miscdevice.h>
> +#include <linux/module.h>
>  
> -#include "xenfs.h"
> -#include "../xenbus/xenbus_comms.h"
> +#include "xenbus_comms.h"
>  
>  #include <xen/xenbus.h>
>  #include <asm/xen/hypervisor.h>
>  
> +MODULE_LICENSE("GPL");
> +
>  /*
>   * An element of a list of outstanding transactions, for which we're
>   * still waiting a reply.
> @@ -583,7 +586,7 @@ static unsigned int xenbus_file_poll(struct file *file, poll_table *wait)
>  	return 0;
>  }
>  
> -const struct file_operations xenbus_file_ops = {
> +const struct file_operations xen_xenbus_fops = {
>  	.read = xenbus_file_read,
>  	.write = xenbus_file_write,
>  	.open = xenbus_file_open,
> @@ -591,3 +594,31 @@ const struct file_operations xenbus_file_ops = {
>  	.poll = xenbus_file_poll,
>  	.llseek = no_llseek,
>  };
> +EXPORT_SYMBOL_GPL(xen_xenbus_fops);
> +
> +static struct miscdevice xenbus_dev = {
> +	.minor = MISC_DYNAMIC_MINOR,
> +	.name = "xen/xenbus",
> +	.fops = &xen_xenbus_fops,
> +};
> +
> +static int __init xenbus_init(void)
> +{
> +	int err;
> +
> +	if (!xen_domain())
> +		return -ENODEV;
> +
> +	err = misc_register(&xenbus_dev);
> +	if (err)
> +		printk(KERN_ERR "Could not register xenbus device\n");
> +	return err;
> +}
> +
> +static void __exit xenbus_exit(void)
> +{
> +	misc_deregister(&xenbus_dev);
> +}
> +
> +module_init(xenbus_init);
> +module_exit(xenbus_exit);
> diff --git a/drivers/xen/xenfs/Makefile b/drivers/xen/xenfs/Makefile
> index 5d45ff1..b019865 100644
> --- a/drivers/xen/xenfs/Makefile
> +++ b/drivers/xen/xenfs/Makefile
> @@ -1,4 +1,4 @@
>  obj-$(CONFIG_XENFS) += xenfs.o
>  
> -xenfs-y			  = super.o xenbus.o
> +xenfs-y			  = super.o
>  xenfs-$(CONFIG_XEN_DOM0) += xenstored.o
> diff --git a/drivers/xen/xenfs/super.c b/drivers/xen/xenfs/super.c
> index a55fbf9..a84b53c 100644
> --- a/drivers/xen/xenfs/super.c
> +++ b/drivers/xen/xenfs/super.c
> @@ -17,6 +17,7 @@
>  
>  #include "xenfs.h"
>  #include "../privcmd.h"
> +#include "../xenbus/xenbus_comms.h"
>  
>  #include <asm/xen/hypervisor.h>
>  
> @@ -83,7 +84,7 @@ static int xenfs_fill_super(struct super_block *sb, void *data, int silent)
>  {
>  	static struct tree_descr xenfs_files[] = {
>  		[1] = {},
> -		{ "xenbus", &xenbus_file_ops, S_IRUSR|S_IWUSR },
> +		{ "xenbus", &xen_xenbus_fops, S_IRUSR|S_IWUSR },
>  		{ "capabilities", &capabilities_file_ops, S_IRUGO },
>  		{ "privcmd", &xen_privcmd_fops, S_IRUSR|S_IWUSR },
>  		{""},
> diff --git a/drivers/xen/xenfs/xenfs.h b/drivers/xen/xenfs/xenfs.h
> index 5056306..6b80c77 100644
> --- a/drivers/xen/xenfs/xenfs.h
> +++ b/drivers/xen/xenfs/xenfs.h
> @@ -1,7 +1,6 @@
>  #ifndef _XENFS_XENBUS_H
>  #define _XENFS_XENBUS_H
>  
> -extern const struct file_operations xenbus_file_ops;
>  extern const struct file_operations xsd_kva_file_ops;
>  extern const struct file_operations xsd_port_file_ops;
>  



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 08 08:21:46 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 Dec 2011 08:21:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYZET-0006D5-Pu; Thu, 08 Dec 2011 08:21:33 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RYZES-0006Cn-5V
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 08:21:32 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1323332443!6605109!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTI0OA==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22416 invoked from network); 8 Dec 2011 08:20:43 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Dec 2011 08:20:43 -0000
X-IronPort-AV: E=Sophos;i="4.71,319,1320624000"; 
   d="scan'208";a="9355651"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Dec 2011 08:20:43 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 8 Dec 2011
	08:20:43 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Bastian Blank <waldi@debian.org>
Date: Thu, 8 Dec 2011 08:20:42 +0000
In-Reply-To: <1323292396-19523-3-git-send-email-waldi@debian.org>
References: <1323292396-19523-1-git-send-email-waldi@debian.org>
	<1323292396-19523-3-git-send-email-waldi@debian.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323332442.2969.47.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH 2/4] xen: Add xenbus device driver
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2011-12-07 at 21:13 +0000, Bastian Blank wrote:
> Access to xenbus is currently handled via xenfs. This adds a device
> driver for xenbus and makes xenfs use this code.
> 
> Signed-off-by: Bastian Blank <waldi@debian.org>
Acked-by: Ian Campbell <ian.campbell@citrix.com>

> ---
>  drivers/xen/xenbus/Makefile                        |    1 +
>  drivers/xen/xenbus/xenbus_comms.h                  |    4 ++
>  .../xenbus.c => xenbus/xenbus_dev_frontend.c}      |   37 ++++++++++++++++++--
>  drivers/xen/xenfs/Makefile                         |    2 +-
>  drivers/xen/xenfs/super.c                          |    3 +-
>  drivers/xen/xenfs/xenfs.h                          |    1 -
>  6 files changed, 42 insertions(+), 6 deletions(-)
>  rename drivers/xen/{xenfs/xenbus.c => xenbus/xenbus_dev_frontend.c} (95%)
> 
> diff --git a/drivers/xen/xenbus/Makefile b/drivers/xen/xenbus/Makefile
> index 8dca685..a2ea363 100644
> --- a/drivers/xen/xenbus/Makefile
> +++ b/drivers/xen/xenbus/Makefile
> @@ -1,4 +1,5 @@
>  obj-y	+= xenbus.o
> +obj-y	+= xenbus_dev_frontend.o
>  
>  xenbus-objs =
>  xenbus-objs += xenbus_client.o
> diff --git a/drivers/xen/xenbus/xenbus_comms.h b/drivers/xen/xenbus/xenbus_comms.h
> index c21db75..6e42800 100644
> --- a/drivers/xen/xenbus/xenbus_comms.h
> +++ b/drivers/xen/xenbus/xenbus_comms.h
> @@ -31,6 +31,8 @@
>  #ifndef _XENBUS_COMMS_H
>  #define _XENBUS_COMMS_H
>  
> +#include <linux/fs.h>
> +
>  int xs_init(void);
>  int xb_init_comms(void);
>  
> @@ -43,4 +45,6 @@ int xs_input_avail(void);
>  extern struct xenstore_domain_interface *xen_store_interface;
>  extern int xen_store_evtchn;
>  
> +extern const struct file_operations xen_xenbus_fops;
> +
>  #endif /* _XENBUS_COMMS_H */
> diff --git a/drivers/xen/xenfs/xenbus.c b/drivers/xen/xenbus/xenbus_dev_frontend.c
> similarity index 95%
> rename from drivers/xen/xenfs/xenbus.c
> rename to drivers/xen/xenbus/xenbus_dev_frontend.c
> index bbd000f..fb30cff 100644
> --- a/drivers/xen/xenfs/xenbus.c
> +++ b/drivers/xen/xenbus/xenbus_dev_frontend.c
> @@ -52,13 +52,16 @@
>  #include <linux/namei.h>
>  #include <linux/string.h>
>  #include <linux/slab.h>
> +#include <linux/miscdevice.h>
> +#include <linux/module.h>
>  
> -#include "xenfs.h"
> -#include "../xenbus/xenbus_comms.h"
> +#include "xenbus_comms.h"
>  
>  #include <xen/xenbus.h>
>  #include <asm/xen/hypervisor.h>
>  
> +MODULE_LICENSE("GPL");
> +
>  /*
>   * An element of a list of outstanding transactions, for which we're
>   * still waiting a reply.
> @@ -583,7 +586,7 @@ static unsigned int xenbus_file_poll(struct file *file, poll_table *wait)
>  	return 0;
>  }
>  
> -const struct file_operations xenbus_file_ops = {
> +const struct file_operations xen_xenbus_fops = {
>  	.read = xenbus_file_read,
>  	.write = xenbus_file_write,
>  	.open = xenbus_file_open,
> @@ -591,3 +594,31 @@ const struct file_operations xenbus_file_ops = {
>  	.poll = xenbus_file_poll,
>  	.llseek = no_llseek,
>  };
> +EXPORT_SYMBOL_GPL(xen_xenbus_fops);
> +
> +static struct miscdevice xenbus_dev = {
> +	.minor = MISC_DYNAMIC_MINOR,
> +	.name = "xen/xenbus",
> +	.fops = &xen_xenbus_fops,
> +};
> +
> +static int __init xenbus_init(void)
> +{
> +	int err;
> +
> +	if (!xen_domain())
> +		return -ENODEV;
> +
> +	err = misc_register(&xenbus_dev);
> +	if (err)
> +		printk(KERN_ERR "Could not register xenbus device\n");
> +	return err;
> +}
> +
> +static void __exit xenbus_exit(void)
> +{
> +	misc_deregister(&xenbus_dev);
> +}
> +
> +module_init(xenbus_init);
> +module_exit(xenbus_exit);
> diff --git a/drivers/xen/xenfs/Makefile b/drivers/xen/xenfs/Makefile
> index 5d45ff1..b019865 100644
> --- a/drivers/xen/xenfs/Makefile
> +++ b/drivers/xen/xenfs/Makefile
> @@ -1,4 +1,4 @@
>  obj-$(CONFIG_XENFS) += xenfs.o
>  
> -xenfs-y			  = super.o xenbus.o
> +xenfs-y			  = super.o
>  xenfs-$(CONFIG_XEN_DOM0) += xenstored.o
> diff --git a/drivers/xen/xenfs/super.c b/drivers/xen/xenfs/super.c
> index a55fbf9..a84b53c 100644
> --- a/drivers/xen/xenfs/super.c
> +++ b/drivers/xen/xenfs/super.c
> @@ -17,6 +17,7 @@
>  
>  #include "xenfs.h"
>  #include "../privcmd.h"
> +#include "../xenbus/xenbus_comms.h"
>  
>  #include <asm/xen/hypervisor.h>
>  
> @@ -83,7 +84,7 @@ static int xenfs_fill_super(struct super_block *sb, void *data, int silent)
>  {
>  	static struct tree_descr xenfs_files[] = {
>  		[1] = {},
> -		{ "xenbus", &xenbus_file_ops, S_IRUSR|S_IWUSR },
> +		{ "xenbus", &xen_xenbus_fops, S_IRUSR|S_IWUSR },
>  		{ "capabilities", &capabilities_file_ops, S_IRUGO },
>  		{ "privcmd", &xen_privcmd_fops, S_IRUSR|S_IWUSR },
>  		{""},
> diff --git a/drivers/xen/xenfs/xenfs.h b/drivers/xen/xenfs/xenfs.h
> index 5056306..6b80c77 100644
> --- a/drivers/xen/xenfs/xenfs.h
> +++ b/drivers/xen/xenfs/xenfs.h
> @@ -1,7 +1,6 @@
>  #ifndef _XENFS_XENBUS_H
>  #define _XENFS_XENBUS_H
>  
> -extern const struct file_operations xenbus_file_ops;
>  extern const struct file_operations xsd_kva_file_ops;
>  extern const struct file_operations xsd_port_file_ops;
>  



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 08 08:25:49 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 Dec 2011 08: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.xensource.com>)
	id 1RYZIN-0006dQ-HG; Thu, 08 Dec 2011 08:25:35 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RYZIL-0006d9-QC
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 08:25:34 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1323332672!48686351!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTI0OA==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27944 invoked from network); 8 Dec 2011 08:24:33 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Dec 2011 08:24:33 -0000
X-IronPort-AV: E=Sophos;i="4.71,319,1320624000"; 
   d="scan'208";a="9355721"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Dec 2011 08:24:47 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 8 Dec 2011
	08:24:46 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Bastian Blank <waldi@debian.org>
Date: Thu, 8 Dec 2011 08:24:46 +0000
In-Reply-To: <1323292396-19523-4-git-send-email-waldi@debian.org>
References: <1323292396-19523-1-git-send-email-waldi@debian.org>
	<1323292396-19523-4-git-send-email-waldi@debian.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323332686.2969.49.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH 3/4] xen: Add xenbusd device driver
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2011-12-07 at 21:13 +0000, Bastian Blank wrote:
> Access for xenstored to the event channel and pre-allocated ring is
> managed via xenfs.  This adds its own device driver featuring mmap for
> the ring and an ioctl for the event channel.
> 
> Signed-off-by: Bastian Blank <waldi@debian.org>
> ---
>  drivers/xen/xenbus/Makefile             |    1 +
>  drivers/xen/xenbus/xenbus_dev_backend.c |   79 +++++++++++++++++++++++++++++++
>  include/xen/xenbus_dev.h                |   41 ++++++++++++++++
>  3 files changed, 121 insertions(+), 0 deletions(-)
>  create mode 100644 drivers/xen/xenbus/xenbus_dev_backend.c
>  create mode 100644 include/xen/xenbus_dev.h
> 
> diff --git a/drivers/xen/xenbus/Makefile b/drivers/xen/xenbus/Makefile
> index a2ea363..31e2e90 100644
> --- a/drivers/xen/xenbus/Makefile
> +++ b/drivers/xen/xenbus/Makefile
> @@ -10,4 +10,5 @@ xenbus-objs += xenbus_probe.o
>  xenbus-be-objs-$(CONFIG_XEN_BACKEND) += xenbus_probe_backend.o
>  xenbus-objs += $(xenbus-be-objs-y)
>  
> +obj-$(CONFIG_XEN_BACKEND) += xenbus_dev_backend.o

In principal this could be its own module which does not depend on any
of the backend stuff but I think this is fine for now.

> [...]

> +static int __init xenbusd_init(void)
> +{
> +	int err;
> +
> +	if (!xen_initial_domain())
> +		return -ENODEV;
> +
> +	err = misc_register(&xenbusd_dev);
> +	if (err)
> +		printk(KERN_ERR "Could not register xenbus device\n");

"Could not register xenbus backend device" to distinguish from the f.e.
failure message, you could also add "frontend" there I suppose. Other
than that:

Acked-by: Ian Campbell <ian.campbell@citrix.com>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 08 08:25:49 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 Dec 2011 08: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.xensource.com>)
	id 1RYZIN-0006dQ-HG; Thu, 08 Dec 2011 08:25:35 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RYZIL-0006d9-QC
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 08:25:34 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1323332672!48686351!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTI0OA==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27944 invoked from network); 8 Dec 2011 08:24:33 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Dec 2011 08:24:33 -0000
X-IronPort-AV: E=Sophos;i="4.71,319,1320624000"; 
   d="scan'208";a="9355721"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Dec 2011 08:24:47 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 8 Dec 2011
	08:24:46 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Bastian Blank <waldi@debian.org>
Date: Thu, 8 Dec 2011 08:24:46 +0000
In-Reply-To: <1323292396-19523-4-git-send-email-waldi@debian.org>
References: <1323292396-19523-1-git-send-email-waldi@debian.org>
	<1323292396-19523-4-git-send-email-waldi@debian.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323332686.2969.49.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH 3/4] xen: Add xenbusd device driver
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2011-12-07 at 21:13 +0000, Bastian Blank wrote:
> Access for xenstored to the event channel and pre-allocated ring is
> managed via xenfs.  This adds its own device driver featuring mmap for
> the ring and an ioctl for the event channel.
> 
> Signed-off-by: Bastian Blank <waldi@debian.org>
> ---
>  drivers/xen/xenbus/Makefile             |    1 +
>  drivers/xen/xenbus/xenbus_dev_backend.c |   79 +++++++++++++++++++++++++++++++
>  include/xen/xenbus_dev.h                |   41 ++++++++++++++++
>  3 files changed, 121 insertions(+), 0 deletions(-)
>  create mode 100644 drivers/xen/xenbus/xenbus_dev_backend.c
>  create mode 100644 include/xen/xenbus_dev.h
> 
> diff --git a/drivers/xen/xenbus/Makefile b/drivers/xen/xenbus/Makefile
> index a2ea363..31e2e90 100644
> --- a/drivers/xen/xenbus/Makefile
> +++ b/drivers/xen/xenbus/Makefile
> @@ -10,4 +10,5 @@ xenbus-objs += xenbus_probe.o
>  xenbus-be-objs-$(CONFIG_XEN_BACKEND) += xenbus_probe_backend.o
>  xenbus-objs += $(xenbus-be-objs-y)
>  
> +obj-$(CONFIG_XEN_BACKEND) += xenbus_dev_backend.o

In principal this could be its own module which does not depend on any
of the backend stuff but I think this is fine for now.

> [...]

> +static int __init xenbusd_init(void)
> +{
> +	int err;
> +
> +	if (!xen_initial_domain())
> +		return -ENODEV;
> +
> +	err = misc_register(&xenbusd_dev);
> +	if (err)
> +		printk(KERN_ERR "Could not register xenbus device\n");

"Could not register xenbus backend device" to distinguish from the f.e.
failure message, you could also add "frontend" there I suppose. Other
than that:

Acked-by: Ian Campbell <ian.campbell@citrix.com>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 08 08:33:18 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 Dec 2011 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.xensource.com>)
	id 1RYZPa-0006zo-JL; Thu, 08 Dec 2011 08:33:02 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RYZPZ-0006zX-9I
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 08:33:01 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1323333133!1113599!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTI0OA==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16587 invoked from network); 8 Dec 2011 08:32:13 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Dec 2011 08:32:13 -0000
X-IronPort-AV: E=Sophos;i="4.71,319,1320624000"; 
   d="scan'208";a="9355864"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Dec 2011 08:32:13 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 8 Dec 2011
	08:32:13 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Bastian Blank <waldi@debian.org>
Date: Thu, 8 Dec 2011 08:32:13 +0000
In-Reply-To: <1323292396-19523-5-git-send-email-waldi@debian.org>
References: <1323292396-19523-1-git-send-email-waldi@debian.org>
	<1323292396-19523-5-git-send-email-waldi@debian.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323333133.2969.55.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH 4/4] xen/privcmd: Remove unused support for
 arch specific privcmp mmap
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2011-12-07 at 21:13 +0000, Bastian Blank wrote:
> ---

You've forgotten the S-o-b for this patch.

Once upon a time this was used by the ia64 privcmd support[0] but since
no one appears to be working on ia64 dom0 support for upstream I'm not
sure if this is an issue or not. I lean towards "not", this can always
be put back as necessary.

Acked-by: Ian Campbell <ian.campbell@citrix.com>

[0]
http://xenbits.xen.org/hg/linux-2.6.18-xen.hg/file/bffd07392da5/arch/ia64/xen/hypervisor.c#l659
http://xenbits.xen.org/hg/linux-2.6.18-xen.hg/file/bffd07392da5/include/asm-ia64/hypervisor.h#l132

>  drivers/xen/privcmd.c |    2 --
>  1 files changed, 0 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
> index 863fbd0..c13d26a 100644
> --- a/drivers/xen/privcmd.c
> +++ b/drivers/xen/privcmd.c
> @@ -365,7 +365,6 @@ static long privcmd_ioctl(struct file *file,
>  	return ret;
>  }
>  
> -#ifndef HAVE_ARCH_PRIVCMD_MMAP
>  static int privcmd_fault(struct vm_area_struct *vma, struct vm_fault *vmf)
>  {
>  	printk(KERN_DEBUG "privcmd_fault: vma=%p %lx-%lx, pgoff=%lx, uv=%p\n",
> @@ -398,7 +397,6 @@ static int privcmd_enforce_singleshot_mapping(struct vm_area_struct *vma)
>  {
>  	return (xchg(&vma->vm_private_data, (void *)1) == NULL);
>  }
> -#endif
>  
>  const struct file_operations xen_privcmd_fops = {
>  	.owner = THIS_MODULE,



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 08 08:33:18 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 Dec 2011 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.xensource.com>)
	id 1RYZPa-0006zo-JL; Thu, 08 Dec 2011 08:33:02 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RYZPZ-0006zX-9I
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 08:33:01 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1323333133!1113599!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTI0OA==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16587 invoked from network); 8 Dec 2011 08:32:13 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Dec 2011 08:32:13 -0000
X-IronPort-AV: E=Sophos;i="4.71,319,1320624000"; 
   d="scan'208";a="9355864"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Dec 2011 08:32:13 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 8 Dec 2011
	08:32:13 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Bastian Blank <waldi@debian.org>
Date: Thu, 8 Dec 2011 08:32:13 +0000
In-Reply-To: <1323292396-19523-5-git-send-email-waldi@debian.org>
References: <1323292396-19523-1-git-send-email-waldi@debian.org>
	<1323292396-19523-5-git-send-email-waldi@debian.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323333133.2969.55.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH 4/4] xen/privcmd: Remove unused support for
 arch specific privcmp mmap
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2011-12-07 at 21:13 +0000, Bastian Blank wrote:
> ---

You've forgotten the S-o-b for this patch.

Once upon a time this was used by the ia64 privcmd support[0] but since
no one appears to be working on ia64 dom0 support for upstream I'm not
sure if this is an issue or not. I lean towards "not", this can always
be put back as necessary.

Acked-by: Ian Campbell <ian.campbell@citrix.com>

[0]
http://xenbits.xen.org/hg/linux-2.6.18-xen.hg/file/bffd07392da5/arch/ia64/xen/hypervisor.c#l659
http://xenbits.xen.org/hg/linux-2.6.18-xen.hg/file/bffd07392da5/include/asm-ia64/hypervisor.h#l132

>  drivers/xen/privcmd.c |    2 --
>  1 files changed, 0 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
> index 863fbd0..c13d26a 100644
> --- a/drivers/xen/privcmd.c
> +++ b/drivers/xen/privcmd.c
> @@ -365,7 +365,6 @@ static long privcmd_ioctl(struct file *file,
>  	return ret;
>  }
>  
> -#ifndef HAVE_ARCH_PRIVCMD_MMAP
>  static int privcmd_fault(struct vm_area_struct *vma, struct vm_fault *vmf)
>  {
>  	printk(KERN_DEBUG "privcmd_fault: vma=%p %lx-%lx, pgoff=%lx, uv=%p\n",
> @@ -398,7 +397,6 @@ static int privcmd_enforce_singleshot_mapping(struct vm_area_struct *vma)
>  {
>  	return (xchg(&vma->vm_private_data, (void *)1) == NULL);
>  }
> -#endif
>  
>  const struct file_operations xen_privcmd_fops = {
>  	.owner = THIS_MODULE,



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 08 08:35:22 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 Dec 2011 08: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.xensource.com>)
	id 1RYZRd-00077S-AJ; Thu, 08 Dec 2011 08:35:09 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RYZRc-00076z-37
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 08:35:08 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1323333259!6063390!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTI0OA==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15030 invoked from network); 8 Dec 2011 08:34:20 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Dec 2011 08:34:20 -0000
X-IronPort-AV: E=Sophos;i="4.71,319,1320624000"; 
   d="scan'208";a="9355906"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Dec 2011 08:34:19 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 8 Dec 2011
	08:34:19 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Bastian Blank <waldi@debian.org>
Date: Thu, 8 Dec 2011 08:34:19 +0000
In-Reply-To: <1323292396-19523-1-git-send-email-waldi@debian.org>
References: <1323292396-19523-1-git-send-email-waldi@debian.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323333259.2969.56.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH 0/4] V2, Move stuff out of xenfs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2011-12-07 at 21:13 +0000, Bastian Blank wrote:
> In <20100605162947.GA31336@wavehammer.waldi.eu.org> I started the
> discussion about xenfs and the usage of it. This is the second try to
> move stuff over into normal device drivers.

I had a few nit picks about error messages but otherwise I'm happy with
this.

How are we doing on the corresponding toolstack changes?

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 08 08:35:22 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 Dec 2011 08: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.xensource.com>)
	id 1RYZRd-00077S-AJ; Thu, 08 Dec 2011 08:35:09 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RYZRc-00076z-37
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 08:35:08 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1323333259!6063390!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTI0OA==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15030 invoked from network); 8 Dec 2011 08:34:20 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Dec 2011 08:34:20 -0000
X-IronPort-AV: E=Sophos;i="4.71,319,1320624000"; 
   d="scan'208";a="9355906"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Dec 2011 08:34:19 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 8 Dec 2011
	08:34:19 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Bastian Blank <waldi@debian.org>
Date: Thu, 8 Dec 2011 08:34:19 +0000
In-Reply-To: <1323292396-19523-1-git-send-email-waldi@debian.org>
References: <1323292396-19523-1-git-send-email-waldi@debian.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323333259.2969.56.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH 0/4] V2, Move stuff out of xenfs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2011-12-07 at 21:13 +0000, Bastian Blank wrote:
> In <20100605162947.GA31336@wavehammer.waldi.eu.org> I started the
> discussion about xenfs and the usage of it. This is the second try to
> move stuff over into normal device drivers.

I had a few nit picks about error messages but otherwise I'm happy with
this.

How are we doing on the corresponding toolstack changes?

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 08 09:12:46 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 Dec 2011 09: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.xensource.com>)
	id 1RYa1b-0007ck-57; Thu, 08 Dec 2011 09:12:19 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RYa1Z-0007cf-9z
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 09:12:17 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1323335488!6037914!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTI0OA==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29202 invoked from network); 8 Dec 2011 09:11:29 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Dec 2011 09:11:29 -0000
X-IronPort-AV: E=Sophos;i="4.71,319,1320624000"; 
   d="scan'208";a="9356720"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Dec 2011 09:11:28 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.161]) by
	LONPMAILMX01.citrite.net ([10.30.203.162]) with mapi; Thu, 8 Dec 2011
	09:11:28 +0000
From: Paul Durrant <Paul.Durrant@citrix.com>
To: "rshriram@cs.ubc.ca" <rshriram@cs.ubc.ca>
Date: Thu, 8 Dec 2011 09:11:35 +0000
Thread-Topic: [Xen-devel] [PATCH] VM generation ID save/restore and migrate
Thread-Index: Acy1LP9AlWgweiqfQHiJaLyT9BXLxwAXBdSQ
Message-ID: <291EDFCB1E9E224A99088639C4762022B5988E5523@LONPMAILBOX01.citrite.net>
References: <9eaac880f504a12c145d.1323250728@cosworth.uk.xensource.com>
	<CAP8mzPNQURKSnS27GPVws4d9RCwXGWLkNFVgneApNgavjSrh5g@mail.gmail.com>
In-Reply-To: <CAP8mzPNQURKSnS27GPVws4d9RCwXGWLkNFVgneApNgavjSrh5g@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] VM generation ID save/restore and migrate
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com



> -----Original Message-----
> From: Shriram Rajagopalan [mailto:rshriram@cs.ubc.ca]
> Sent: 07 December 2011 22:09
> To: Paul Durrant
> Cc: xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] [PATCH] VM generation ID save/restore and
> migrate
> =

> On Wed, Dec 7, 2011 at 1:38 AM, Paul Durrant
> <paul.durrant@citrix.com> wrote:
> >
> > diff -r 38eb74c01d9d -r 9eaac880f504 tools/xcutils/xc_restore.c
> > --- a/tools/xcutils/xc_restore.c =A0 =A0 =A0 =A0Tue Dec 06 21:16:56 2011
> +0000
> > +++ b/tools/xcutils/xc_restore.c =A0 =A0 =A0 =A0Wed Dec 07 09:36:07 2011
> +0000
> > @@ -23,11 +23,12 @@ main(int argc, char **argv)
> > =A0 =A0 xc_interface *xch;
> > =A0 =A0 int io_fd, ret;
> > =A0 =A0 int superpages;
> > - =A0 =A0unsigned long store_mfn, console_mfn;
> > + =A0 =A0unsigned long store_mfn, console_mfn, vm_gid_addr;
> > + =A0 =A0int no_increment_gid;
> >
> > - =A0 =A0if ( (argc !=3D 8) && (argc !=3D 9) )
> > + =A0 =A0if ( (argc < 8) || (argc > 10) )
> > =A0 =A0 =A0 =A0 errx(1, "usage: %s iofd domid store_evtchn "
> > - =A0 =A0 =A0 =A0 =A0 =A0 "console_evtchn hvm pae apic [superpages]",
> argv[0]);
> > + =A0 =A0 =A0 =A0 =A0 =A0 "console_evtchn hvm pae apic [superpages
> > + [no_increment_gid]]", argv[0]);
> >
> > =A0 =A0 xch =3D xc_interface_open(0,0,0);
> > =A0 =A0 if ( !xch )
> > @@ -40,19 +41,25 @@ main(int argc, char **argv)
> > =A0 =A0 hvm =A0=3D atoi(argv[5]);
> > =A0 =A0 pae =A0=3D atoi(argv[6]);
> > =A0 =A0 apic =3D atoi(argv[7]);
> > - =A0 =A0if ( argc =3D=3D 9 )
> > + =A0 =A0if ( argc >=3D 9 )
> > =A0 =A0 =A0 =A0 =A0 =A0superpages =3D atoi(argv[8]);
> > =A0 =A0 else
> > =A0 =A0 =A0 =A0 =A0 =A0superpages =3D !!hvm;
> > + =A0 =A0if ( argc >=3D 10 )
> > + =A0 =A0 =A0 =A0 =A0 no_increment_gid =3D !atoi(argv[9]);
> > + =A0 =A0else
> > + =A0 =A0 =A0 =A0 =A0 no_increment_gid =3D 0;
> >
> =

> Just a nit:
> It would be better if this was " if (argc =3D=3D 10) no_increment..." as
> the current form contradicts with the previous check (if argc <8 ||
> argc > 10), but I guess there is no correctness issue since the
> first check would catch any extra args.
> =

> Anyway, I am okay with the patch.
> =

> Acked-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>  for *sections I
> am responsible for* (tools/python/xen/lowlevel/checkpoint/*).
> =


No html this time :-)

Thanks for the ack Shriram. Agreed that the >=3D check could now be =3D=3D =
but, as you say, there's no correctness issue so I'll leave the patch alone=
 this time.

  Cheers,

    Paul

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 08 09:12:46 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 Dec 2011 09: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.xensource.com>)
	id 1RYa1b-0007ck-57; Thu, 08 Dec 2011 09:12:19 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RYa1Z-0007cf-9z
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 09:12:17 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1323335488!6037914!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTI0OA==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29202 invoked from network); 8 Dec 2011 09:11:29 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Dec 2011 09:11:29 -0000
X-IronPort-AV: E=Sophos;i="4.71,319,1320624000"; 
   d="scan'208";a="9356720"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Dec 2011 09:11:28 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.161]) by
	LONPMAILMX01.citrite.net ([10.30.203.162]) with mapi; Thu, 8 Dec 2011
	09:11:28 +0000
From: Paul Durrant <Paul.Durrant@citrix.com>
To: "rshriram@cs.ubc.ca" <rshriram@cs.ubc.ca>
Date: Thu, 8 Dec 2011 09:11:35 +0000
Thread-Topic: [Xen-devel] [PATCH] VM generation ID save/restore and migrate
Thread-Index: Acy1LP9AlWgweiqfQHiJaLyT9BXLxwAXBdSQ
Message-ID: <291EDFCB1E9E224A99088639C4762022B5988E5523@LONPMAILBOX01.citrite.net>
References: <9eaac880f504a12c145d.1323250728@cosworth.uk.xensource.com>
	<CAP8mzPNQURKSnS27GPVws4d9RCwXGWLkNFVgneApNgavjSrh5g@mail.gmail.com>
In-Reply-To: <CAP8mzPNQURKSnS27GPVws4d9RCwXGWLkNFVgneApNgavjSrh5g@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] VM generation ID save/restore and migrate
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com



> -----Original Message-----
> From: Shriram Rajagopalan [mailto:rshriram@cs.ubc.ca]
> Sent: 07 December 2011 22:09
> To: Paul Durrant
> Cc: xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] [PATCH] VM generation ID save/restore and
> migrate
> =

> On Wed, Dec 7, 2011 at 1:38 AM, Paul Durrant
> <paul.durrant@citrix.com> wrote:
> >
> > diff -r 38eb74c01d9d -r 9eaac880f504 tools/xcutils/xc_restore.c
> > --- a/tools/xcutils/xc_restore.c =A0 =A0 =A0 =A0Tue Dec 06 21:16:56 2011
> +0000
> > +++ b/tools/xcutils/xc_restore.c =A0 =A0 =A0 =A0Wed Dec 07 09:36:07 2011
> +0000
> > @@ -23,11 +23,12 @@ main(int argc, char **argv)
> > =A0 =A0 xc_interface *xch;
> > =A0 =A0 int io_fd, ret;
> > =A0 =A0 int superpages;
> > - =A0 =A0unsigned long store_mfn, console_mfn;
> > + =A0 =A0unsigned long store_mfn, console_mfn, vm_gid_addr;
> > + =A0 =A0int no_increment_gid;
> >
> > - =A0 =A0if ( (argc !=3D 8) && (argc !=3D 9) )
> > + =A0 =A0if ( (argc < 8) || (argc > 10) )
> > =A0 =A0 =A0 =A0 errx(1, "usage: %s iofd domid store_evtchn "
> > - =A0 =A0 =A0 =A0 =A0 =A0 "console_evtchn hvm pae apic [superpages]",
> argv[0]);
> > + =A0 =A0 =A0 =A0 =A0 =A0 "console_evtchn hvm pae apic [superpages
> > + [no_increment_gid]]", argv[0]);
> >
> > =A0 =A0 xch =3D xc_interface_open(0,0,0);
> > =A0 =A0 if ( !xch )
> > @@ -40,19 +41,25 @@ main(int argc, char **argv)
> > =A0 =A0 hvm =A0=3D atoi(argv[5]);
> > =A0 =A0 pae =A0=3D atoi(argv[6]);
> > =A0 =A0 apic =3D atoi(argv[7]);
> > - =A0 =A0if ( argc =3D=3D 9 )
> > + =A0 =A0if ( argc >=3D 9 )
> > =A0 =A0 =A0 =A0 =A0 =A0superpages =3D atoi(argv[8]);
> > =A0 =A0 else
> > =A0 =A0 =A0 =A0 =A0 =A0superpages =3D !!hvm;
> > + =A0 =A0if ( argc >=3D 10 )
> > + =A0 =A0 =A0 =A0 =A0 no_increment_gid =3D !atoi(argv[9]);
> > + =A0 =A0else
> > + =A0 =A0 =A0 =A0 =A0 no_increment_gid =3D 0;
> >
> =

> Just a nit:
> It would be better if this was " if (argc =3D=3D 10) no_increment..." as
> the current form contradicts with the previous check (if argc <8 ||
> argc > 10), but I guess there is no correctness issue since the
> first check would catch any extra args.
> =

> Anyway, I am okay with the patch.
> =

> Acked-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>  for *sections I
> am responsible for* (tools/python/xen/lowlevel/checkpoint/*).
> =


No html this time :-)

Thanks for the ack Shriram. Agreed that the >=3D check could now be =3D=3D =
but, as you say, there's no correctness issue so I'll leave the patch alone=
 this time.

  Cheers,

    Paul

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 08 09:29:28 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 Dec 2011 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.xensource.com>)
	id 1RYaHa-0007nr-3O; Thu, 08 Dec 2011 09:28:50 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <waldi@debian.org>) id 1RYaHY-0007nm-9q
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 09:28:48 +0000
X-Env-Sender: waldi@debian.org
X-Msg-Ref: server-11.tower-216.messagelabs.com!1323336479!6568693!1
X-Originating-IP: [82.139.201.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14174 invoked from network); 8 Dec 2011 09:28:00 -0000
Received: from wavehammer.waldi.eu.org (HELO wavehammer.waldi.eu.org)
	(82.139.201.20)
	by server-11.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 8 Dec 2011 09:28:00 -0000
Received: by wavehammer.waldi.eu.org (Postfix, from userid 1000)
	id 495C95415B; Thu,  8 Dec 2011 10:27:58 +0100 (CET)
Date: Thu, 8 Dec 2011 10:27:58 +0100
From: Bastian Blank <waldi@debian.org>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20111208092757.GA22678@wavehammer.waldi.eu.org>
Mail-Followup-To: Bastian Blank <waldi@debian.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
References: <1323292396-19523-1-git-send-email-waldi@debian.org>
	<1323292396-19523-4-git-send-email-waldi@debian.org>
	<1323332686.2969.49.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1323332686.2969.49.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH 3/4] xen: Add xenbusd device driver
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Dec 08, 2011 at 08:24:46AM +0000, Ian Campbell wrote:
> On Wed, 2011-12-07 at 21:13 +0000, Bastian Blank wrote:
> > +obj-$(CONFIG_XEN_BACKEND) += xenbus_dev_backend.o
> In principal this could be its own module which does not depend on any
> of the backend stuff but I think this is fine for now.

I even think about registering this device from xenstored_local_init in
xenbus_probe.c. Then it will be available only if the kernel also owns
the communcation ring.

> "Could not register xenbus backend device" to distinguish from the f.e.
> failure message, you could also add "frontend" there I suppose. Other
> than that:

Yep.

Will someone mind if I rename this device to xenbus_backend? It's more
clear.

Bastian

-- 
Deflector shields just came on, Captain.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 08 09:29:28 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 Dec 2011 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.xensource.com>)
	id 1RYaHa-0007nr-3O; Thu, 08 Dec 2011 09:28:50 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <waldi@debian.org>) id 1RYaHY-0007nm-9q
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 09:28:48 +0000
X-Env-Sender: waldi@debian.org
X-Msg-Ref: server-11.tower-216.messagelabs.com!1323336479!6568693!1
X-Originating-IP: [82.139.201.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14174 invoked from network); 8 Dec 2011 09:28:00 -0000
Received: from wavehammer.waldi.eu.org (HELO wavehammer.waldi.eu.org)
	(82.139.201.20)
	by server-11.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 8 Dec 2011 09:28:00 -0000
Received: by wavehammer.waldi.eu.org (Postfix, from userid 1000)
	id 495C95415B; Thu,  8 Dec 2011 10:27:58 +0100 (CET)
Date: Thu, 8 Dec 2011 10:27:58 +0100
From: Bastian Blank <waldi@debian.org>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20111208092757.GA22678@wavehammer.waldi.eu.org>
Mail-Followup-To: Bastian Blank <waldi@debian.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
References: <1323292396-19523-1-git-send-email-waldi@debian.org>
	<1323292396-19523-4-git-send-email-waldi@debian.org>
	<1323332686.2969.49.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1323332686.2969.49.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH 3/4] xen: Add xenbusd device driver
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Dec 08, 2011 at 08:24:46AM +0000, Ian Campbell wrote:
> On Wed, 2011-12-07 at 21:13 +0000, Bastian Blank wrote:
> > +obj-$(CONFIG_XEN_BACKEND) += xenbus_dev_backend.o
> In principal this could be its own module which does not depend on any
> of the backend stuff but I think this is fine for now.

I even think about registering this device from xenstored_local_init in
xenbus_probe.c. Then it will be available only if the kernel also owns
the communcation ring.

> "Could not register xenbus backend device" to distinguish from the f.e.
> failure message, you could also add "frontend" there I suppose. Other
> than that:

Yep.

Will someone mind if I rename this device to xenbus_backend? It's more
clear.

Bastian

-- 
Deflector shields just came on, Captain.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 08 09:30:29 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 Dec 2011 09:30:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYaIT-0007q9-Hq; Thu, 08 Dec 2011 09:29:45 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <waldi@debian.org>) id 1RYaIS-0007pv-AA
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 09:29:44 +0000
X-Env-Sender: waldi@debian.org
X-Msg-Ref: server-3.tower-182.messagelabs.com!1323336536!6393939!1
X-Originating-IP: [82.139.201.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19532 invoked from network); 8 Dec 2011 09:28:56 -0000
Received: from wavehammer.waldi.eu.org (HELO wavehammer.waldi.eu.org)
	(82.139.201.20)
	by server-3.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 8 Dec 2011 09:28:56 -0000
Received: by wavehammer.waldi.eu.org (Postfix, from userid 1000)
	id C2C3B5415B; Thu,  8 Dec 2011 10:28:55 +0100 (CET)
Date: Thu, 8 Dec 2011 10:28:55 +0100
From: Bastian Blank <waldi@debian.org>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20111208092855.GB22678@wavehammer.waldi.eu.org>
Mail-Followup-To: Bastian Blank <waldi@debian.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
References: <1323292396-19523-1-git-send-email-waldi@debian.org>
	<1323333259.2969.56.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1323333259.2969.56.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH 0/4] V2, Move stuff out of xenfs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Dec 08, 2011 at 08:34:19AM +0000, Ian Campbell wrote:
> How are we doing on the corresponding toolstack changes?

I have at least parts of it somewhere on my workstation. I'll polish and
submit them also.

Bastian

-- 
Witch!  Witch!  They'll burn ya!
		-- Hag, "Tomorrow is Yesterday", stardate unknown

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 08 09:30:29 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 Dec 2011 09:30:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYaIT-0007q9-Hq; Thu, 08 Dec 2011 09:29:45 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <waldi@debian.org>) id 1RYaIS-0007pv-AA
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 09:29:44 +0000
X-Env-Sender: waldi@debian.org
X-Msg-Ref: server-3.tower-182.messagelabs.com!1323336536!6393939!1
X-Originating-IP: [82.139.201.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19532 invoked from network); 8 Dec 2011 09:28:56 -0000
Received: from wavehammer.waldi.eu.org (HELO wavehammer.waldi.eu.org)
	(82.139.201.20)
	by server-3.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 8 Dec 2011 09:28:56 -0000
Received: by wavehammer.waldi.eu.org (Postfix, from userid 1000)
	id C2C3B5415B; Thu,  8 Dec 2011 10:28:55 +0100 (CET)
Date: Thu, 8 Dec 2011 10:28:55 +0100
From: Bastian Blank <waldi@debian.org>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20111208092855.GB22678@wavehammer.waldi.eu.org>
Mail-Followup-To: Bastian Blank <waldi@debian.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
References: <1323292396-19523-1-git-send-email-waldi@debian.org>
	<1323333259.2969.56.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1323333259.2969.56.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH 0/4] V2, Move stuff out of xenfs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Dec 08, 2011 at 08:34:19AM +0000, Ian Campbell wrote:
> How are we doing on the corresponding toolstack changes?

I have at least parts of it somewhere on my workstation. I'll polish and
submit them also.

Bastian

-- 
Witch!  Witch!  They'll burn ya!
		-- Hag, "Tomorrow is Yesterday", stardate unknown

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 08 09:34:17 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 Dec 2011 09: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.xensource.com>)
	id 1RYaMd-0008NA-21; Thu, 08 Dec 2011 09:34:03 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RYaMc-0008Mc-0T
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 09:34:02 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1323336743!59915710!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDg5NQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20038 invoked from network); 8 Dec 2011 09:32:24 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Dec 2011 09:32:24 -0000
X-IronPort-AV: E=Sophos;i="4.71,319,1320624000"; 
   d="scan'208";a="9357371"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Dec 2011 09:32:58 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 8 Dec 2011
	09:32:58 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Bastian Blank <waldi@debian.org>
Date: Thu, 8 Dec 2011 09:32:57 +0000
In-Reply-To: <20111208092757.GA22678@wavehammer.waldi.eu.org>
References: <1323292396-19523-1-git-send-email-waldi@debian.org>
	<1323292396-19523-4-git-send-email-waldi@debian.org>
	<1323332686.2969.49.camel@zakaz.uk.xensource.com>
	<20111208092757.GA22678@wavehammer.waldi.eu.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323336777.2969.73.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH 3/4] xen: Add xenbusd device driver
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2011-12-08 at 09:27 +0000, Bastian Blank wrote:
> On Thu, Dec 08, 2011 at 08:24:46AM +0000, Ian Campbell wrote:
> > On Wed, 2011-12-07 at 21:13 +0000, Bastian Blank wrote:
> > > +obj-$(CONFIG_XEN_BACKEND) += xenbus_dev_backend.o
> > In principal this could be its own module which does not depend on any
> > of the backend stuff but I think this is fine for now.
> 
> I even think about registering this device from xenstored_local_init in
> xenbus_probe.c. Then it will be available only if the kernel also owns
> the communcation ring.

That sounds like a good idea.

> > "Could not register xenbus backend device" to distinguish from the f.e.
> > failure message, you could also add "frontend" there I suppose. Other
> > than that:
> 
> Yep.
> 
> Will someone mind if I rename this device to xenbus_backend? It's more
> clear.

It's ok by me. You could even use "xenstored"?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 08 09:34:17 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 Dec 2011 09: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.xensource.com>)
	id 1RYaMd-0008NA-21; Thu, 08 Dec 2011 09:34:03 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RYaMc-0008Mc-0T
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 09:34:02 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1323336743!59915710!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDg5NQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20038 invoked from network); 8 Dec 2011 09:32:24 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Dec 2011 09:32:24 -0000
X-IronPort-AV: E=Sophos;i="4.71,319,1320624000"; 
   d="scan'208";a="9357371"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Dec 2011 09:32:58 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 8 Dec 2011
	09:32:58 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Bastian Blank <waldi@debian.org>
Date: Thu, 8 Dec 2011 09:32:57 +0000
In-Reply-To: <20111208092757.GA22678@wavehammer.waldi.eu.org>
References: <1323292396-19523-1-git-send-email-waldi@debian.org>
	<1323292396-19523-4-git-send-email-waldi@debian.org>
	<1323332686.2969.49.camel@zakaz.uk.xensource.com>
	<20111208092757.GA22678@wavehammer.waldi.eu.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323336777.2969.73.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH 3/4] xen: Add xenbusd device driver
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2011-12-08 at 09:27 +0000, Bastian Blank wrote:
> On Thu, Dec 08, 2011 at 08:24:46AM +0000, Ian Campbell wrote:
> > On Wed, 2011-12-07 at 21:13 +0000, Bastian Blank wrote:
> > > +obj-$(CONFIG_XEN_BACKEND) += xenbus_dev_backend.o
> > In principal this could be its own module which does not depend on any
> > of the backend stuff but I think this is fine for now.
> 
> I even think about registering this device from xenstored_local_init in
> xenbus_probe.c. Then it will be available only if the kernel also owns
> the communcation ring.

That sounds like a good idea.

> > "Could not register xenbus backend device" to distinguish from the f.e.
> > failure message, you could also add "frontend" there I suppose. Other
> > than that:
> 
> Yep.
> 
> Will someone mind if I rename this device to xenbus_backend? It's more
> clear.

It's ok by me. You could even use "xenstored"?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 08 09:37:02 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 Dec 2011 09:37:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYaPE-00008E-BM; Thu, 08 Dec 2011 09:36:44 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <annie.li@oracle.com>) id 1RYaPB-00007v-HJ
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 09:36:41 +0000
X-Env-Sender: annie.li@oracle.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1323336951!7379126!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQyMjA1NA==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16446 invoked from network); 8 Dec 2011 09:35:52 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-8.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 8 Dec 2011 09:35:52 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pB89ZlxL015737
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 8 Dec 2011 09:35:48 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pB89Zj3D009879
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 8 Dec 2011 09:35:46 GMT
Received: from abhmt111.oracle.com (abhmt111.oracle.com [141.146.116.63])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pB89ZcXl002076; Thu, 8 Dec 2011 03:35:38 -0600
Received: from annie2.cn.oracle.com.com (/10.182.37.169)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 08 Dec 2011 01:35:37 -0800
From: annie.li@oracle.com
To: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org,
	konrad.wilk@oracle.com, jeremy@goop.org, paul.durrant@citrix.com,
	Ian.Campbell@citrix.com
Date: Thu,  8 Dec 2011 17:35:40 +0800
Message-Id: <1323336940-5382-1-git-send-email-annie.li@oracle.com>
X-Mailer: git-send-email 1.7.6.4
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A02020B.4EE084F4.00C4,ss=1,re=0.000,fgs=0
Cc: kurt.hackel@oracle.com, annie.li@oracle.com
Subject: [Xen-devel] [PATCH V2 0/2] xen: patches for supporting sub-page and
	transitive grants
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi

Following two patches introduce and implement interfaces for sub-page and transitive grants, and they are based on linux-next branch of linux/kernel/git/konrad/xen.git(3.2.0-rc2+). Sub-page and transitive grants are new types of grant table V2.

Descriptions for those patches:

Through sub-page grant table interfaces, a domain can grant another domain access to a range of bytes within a page, and Xen will then prevent the grantee domain accessing outside that range.  For obvious reasons, it isn't possible to map these grant references, and domains are expected to use the grant copy hypercall instead.

Through transitive grant interfaces,  a domain can create grant reference which redirects to another grant reference, so that any attempt to access the first grant reference will be redirected to the second one.  This is used to implement receiver-side copy on inter-domain traffic: rather than copying the packet in dom0, dom0 creates a transitive grant referencing the original transmit buffer, and passes that to the receiving domain.

Annie Li (2):
  xen/granttable: Support sub-page grants
  xen/granttable: Support transitive grants

 drivers/xen/grant-table.c |  147 +++++++++++++++++++++++++++++++++++++++++++++
 include/xen/grant_table.h |   25 ++++++++
 2 files changed, 172 insertions(+), 0 deletions(-)

Thanks
Annie

-- 
1.7.6.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 08 09:37:02 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 Dec 2011 09:37:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYaPE-00008E-BM; Thu, 08 Dec 2011 09:36:44 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <annie.li@oracle.com>) id 1RYaPB-00007v-HJ
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 09:36:41 +0000
X-Env-Sender: annie.li@oracle.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1323336951!7379126!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQyMjA1NA==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16446 invoked from network); 8 Dec 2011 09:35:52 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-8.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 8 Dec 2011 09:35:52 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pB89ZlxL015737
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 8 Dec 2011 09:35:48 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pB89Zj3D009879
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 8 Dec 2011 09:35:46 GMT
Received: from abhmt111.oracle.com (abhmt111.oracle.com [141.146.116.63])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pB89ZcXl002076; Thu, 8 Dec 2011 03:35:38 -0600
Received: from annie2.cn.oracle.com.com (/10.182.37.169)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 08 Dec 2011 01:35:37 -0800
From: annie.li@oracle.com
To: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org,
	konrad.wilk@oracle.com, jeremy@goop.org, paul.durrant@citrix.com,
	Ian.Campbell@citrix.com
Date: Thu,  8 Dec 2011 17:35:40 +0800
Message-Id: <1323336940-5382-1-git-send-email-annie.li@oracle.com>
X-Mailer: git-send-email 1.7.6.4
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A02020B.4EE084F4.00C4,ss=1,re=0.000,fgs=0
Cc: kurt.hackel@oracle.com, annie.li@oracle.com
Subject: [Xen-devel] [PATCH V2 0/2] xen: patches for supporting sub-page and
	transitive grants
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi

Following two patches introduce and implement interfaces for sub-page and transitive grants, and they are based on linux-next branch of linux/kernel/git/konrad/xen.git(3.2.0-rc2+). Sub-page and transitive grants are new types of grant table V2.

Descriptions for those patches:

Through sub-page grant table interfaces, a domain can grant another domain access to a range of bytes within a page, and Xen will then prevent the grantee domain accessing outside that range.  For obvious reasons, it isn't possible to map these grant references, and domains are expected to use the grant copy hypercall instead.

Through transitive grant interfaces,  a domain can create grant reference which redirects to another grant reference, so that any attempt to access the first grant reference will be redirected to the second one.  This is used to implement receiver-side copy on inter-domain traffic: rather than copying the packet in dom0, dom0 creates a transitive grant referencing the original transmit buffer, and passes that to the receiving domain.

Annie Li (2):
  xen/granttable: Support sub-page grants
  xen/granttable: Support transitive grants

 drivers/xen/grant-table.c |  147 +++++++++++++++++++++++++++++++++++++++++++++
 include/xen/grant_table.h |   25 ++++++++
 2 files changed, 172 insertions(+), 0 deletions(-)

Thanks
Annie

-- 
1.7.6.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 08 09:38:39 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 Dec 2011 09:38:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYaQo-0000HF-SZ; Thu, 08 Dec 2011 09:38:22 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <annie.li@oracle.com>) id 1RYaQn-0000Gp-4r
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 09:38:21 +0000
X-Env-Sender: annie.li@oracle.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1323337051!7271598!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQyMjA1NA==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18445 invoked from network); 8 Dec 2011 09:37:33 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-6.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 8 Dec 2011 09:37:33 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pB89bTq9017872
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 8 Dec 2011 09:37:29 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pB89bSUD000753
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 8 Dec 2011 09:37:28 GMT
Received: from abhmt105.oracle.com (abhmt105.oracle.com [141.146.116.57])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pB89bNlO020838; Thu, 8 Dec 2011 03:37:23 -0600
Received: from annie2.cn.oracle.com.com (/10.182.37.169)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 08 Dec 2011 01:37:23 -0800
From: annie.li@oracle.com
To: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org,
	konrad.wilk@oracle.com, jeremy@goop.org, paul.durrant@citrix.com,
	Ian.Campbell@citrix.com
Date: Thu,  8 Dec 2011 17:37:28 +0800
Message-Id: <1323337048-5426-1-git-send-email-annie.li@oracle.com>
X-Mailer: git-send-email 1.7.6.4
In-Reply-To: <1323336940-5382-1-git-send-email-annie.li@oracle.com>
References: <1323336940-5382-1-git-send-email-annie.li@oracle.com>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A02020B.4EE0855A.002F,ss=1,re=0.000,fgs=0
Cc: kurt.hackel@oracle.com, annie.li@oracle.com
Subject: [Xen-devel] [PATCH V2 1/2] xen/granttable: Support sub-page grants
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

    -- They can't be used to map the page (so can only be used in a GNTTABOP_copy
       hypercall).
    -- It's possible to grant access with a finer granularity than whole pages.
    -- Xen guarantees that they can be revoked quickly (a normal map grant can
       only be revoked with the cooperation of the domain which has been granted
       access).

Signed-off-by: Annie Li <annie.li@oracle.com>
---
 drivers/xen/grant-table.c |   74 +++++++++++++++++++++++++++++++++++++++++++++
 include/xen/grant_table.h |   13 ++++++++
 2 files changed, 87 insertions(+), 0 deletions(-)

diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
index bd325fd..4a10e3f 100644
--- a/drivers/xen/grant-table.c
+++ b/drivers/xen/grant-table.c
@@ -120,6 +120,16 @@ struct gnttab_ops {
 	 * by bit operations.
 	 */
 	int (*query_foreign_access)(grant_ref_t);
+	/*
+	 * Grant a domain to access a range of bytes within the page referred by
+	 * an available grant entry. First parameter is grant entry reference
+	 * number, second one is id of grantee domain, third one is frame
+	 * address of subpage grant, forth one is grant type and flag
+	 * information, fifth one is offset of the range of bytes, and last one
+	 * is length of bytes to be accessed.
+	 */
+	void (*update_subpage_entry)(grant_ref_t, domid_t, unsigned long, int,
+				     unsigned, unsigned);
 };
 
 static struct gnttab_ops *gnttab_interface;
@@ -261,6 +271,69 @@ int gnttab_grant_foreign_access(domid_t domid, unsigned long frame,
 }
 EXPORT_SYMBOL_GPL(gnttab_grant_foreign_access);
 
+void gnttab_update_subpage_entry_v2(grant_ref_t ref, domid_t domid,
+				    unsigned long frame, int flags,
+				    unsigned page_off,
+				    unsigned length)
+{
+	gnttab_shared.v2[ref].sub_page.frame = frame;
+	gnttab_shared.v2[ref].sub_page.page_off = page_off;
+	gnttab_shared.v2[ref].sub_page.length = length;
+	gnttab_shared.v2[ref].hdr.domid = domid;
+	wmb();
+	gnttab_shared.v2[ref].hdr.flags =
+				GTF_permit_access | GTF_sub_page | flags;
+}
+
+int gnttab_grant_foreign_access_subpage_ref(grant_ref_t ref, domid_t domid,
+					    unsigned long frame, int flags,
+					    unsigned page_off,
+					    unsigned length)
+{
+	if (flags & (GTF_accept_transfer | GTF_reading |
+		     GTF_writing | GTF_transitive))
+		return -EPERM;
+
+	if (gnttab_interface->update_subpage_entry == NULL)
+		return -ENOSYS;
+
+	gnttab_interface->update_subpage_entry(ref, domid, frame, flags,
+					       page_off, length);
+
+	return 0;
+}
+EXPORT_SYMBOL_GPL(gnttab_grant_foreign_access_subpage_ref);
+
+int gnttab_grant_foreign_access_subpage(domid_t domid, unsigned long frame,
+					int flags, unsigned page_off,
+					unsigned length)
+{
+	int ref;
+
+	if (flags & (GTF_accept_transfer | GTF_reading |
+		     GTF_writing | GTF_transitive))
+		return -EPERM;
+
+	if (gnttab_interface->update_subpage_entry == NULL)
+		return -ENOSYS;
+
+	ref = get_free_entries(1);
+	if (unlikely(ref < 0))
+		return -ENOSPC;
+
+	gnttab_interface->update_subpage_entry(ref, domid, frame, flags,
+					       page_off, length);
+
+	return ref;
+}
+EXPORT_SYMBOL_GPL(gnttab_grant_foreign_access_subpage);
+
+bool gnttab_subpage_grants_available(void)
+{
+	return gnttab_interface->update_subpage_entry != NULL;
+}
+EXPORT_SYMBOL_GPL(gnttab_subpage_grants_available);
+
 static int gnttab_query_foreign_access_v1(grant_ref_t ref)
 {
 	return gnttab_shared.v1[ref].flags & (GTF_reading|GTF_writing);
@@ -813,6 +886,7 @@ static struct gnttab_ops gnttab_v2_ops = {
 	.end_foreign_access_ref		= gnttab_end_foreign_access_ref_v2,
 	.end_foreign_transfer_ref	= gnttab_end_foreign_transfer_ref_v2,
 	.query_foreign_access		= gnttab_query_foreign_access_v2,
+	.update_subpage_entry		= gnttab_update_subpage_entry_v2,
 };
 
 static void gnttab_request_version(void)
diff --git a/include/xen/grant_table.h b/include/xen/grant_table.h
index fea4954..2b492b9 100644
--- a/include/xen/grant_table.h
+++ b/include/xen/grant_table.h
@@ -62,6 +62,15 @@ int gnttab_resume(void);
 
 int gnttab_grant_foreign_access(domid_t domid, unsigned long frame,
 				int readonly);
+int gnttab_grant_foreign_access_subpage(domid_t domid, unsigned long frame,
+					int flags, unsigned page_off,
+					unsigned length);
+
+/*
+ * Are sub-page grants available on this version of Xen?  Returns true if they
+ * are, and false if they're not.
+ */
+bool gnttab_subpage_grants_available(void);
 
 /*
  * End access through the given grant reference, iff the grant entry is no
@@ -108,6 +117,10 @@ void gnttab_cancel_free_callback(struct gnttab_free_callback *callback);
 
 void gnttab_grant_foreign_access_ref(grant_ref_t ref, domid_t domid,
 				     unsigned long frame, int readonly);
+int gnttab_grant_foreign_access_subpage_ref(grant_ref_t ref, domid_t domid,
+					    unsigned long frame, int flags,
+					    unsigned page_off,
+					    unsigned length);
 
 void gnttab_grant_foreign_transfer_ref(grant_ref_t, domid_t domid,
 				       unsigned long pfn);
-- 
1.7.6.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 08 09:38:39 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 Dec 2011 09:38:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYaQo-0000HF-SZ; Thu, 08 Dec 2011 09:38:22 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <annie.li@oracle.com>) id 1RYaQn-0000Gp-4r
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 09:38:21 +0000
X-Env-Sender: annie.li@oracle.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1323337051!7271598!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQyMjA1NA==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18445 invoked from network); 8 Dec 2011 09:37:33 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-6.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 8 Dec 2011 09:37:33 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pB89bTq9017872
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 8 Dec 2011 09:37:29 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pB89bSUD000753
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 8 Dec 2011 09:37:28 GMT
Received: from abhmt105.oracle.com (abhmt105.oracle.com [141.146.116.57])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pB89bNlO020838; Thu, 8 Dec 2011 03:37:23 -0600
Received: from annie2.cn.oracle.com.com (/10.182.37.169)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 08 Dec 2011 01:37:23 -0800
From: annie.li@oracle.com
To: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org,
	konrad.wilk@oracle.com, jeremy@goop.org, paul.durrant@citrix.com,
	Ian.Campbell@citrix.com
Date: Thu,  8 Dec 2011 17:37:28 +0800
Message-Id: <1323337048-5426-1-git-send-email-annie.li@oracle.com>
X-Mailer: git-send-email 1.7.6.4
In-Reply-To: <1323336940-5382-1-git-send-email-annie.li@oracle.com>
References: <1323336940-5382-1-git-send-email-annie.li@oracle.com>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A02020B.4EE0855A.002F,ss=1,re=0.000,fgs=0
Cc: kurt.hackel@oracle.com, annie.li@oracle.com
Subject: [Xen-devel] [PATCH V2 1/2] xen/granttable: Support sub-page grants
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

    -- They can't be used to map the page (so can only be used in a GNTTABOP_copy
       hypercall).
    -- It's possible to grant access with a finer granularity than whole pages.
    -- Xen guarantees that they can be revoked quickly (a normal map grant can
       only be revoked with the cooperation of the domain which has been granted
       access).

Signed-off-by: Annie Li <annie.li@oracle.com>
---
 drivers/xen/grant-table.c |   74 +++++++++++++++++++++++++++++++++++++++++++++
 include/xen/grant_table.h |   13 ++++++++
 2 files changed, 87 insertions(+), 0 deletions(-)

diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
index bd325fd..4a10e3f 100644
--- a/drivers/xen/grant-table.c
+++ b/drivers/xen/grant-table.c
@@ -120,6 +120,16 @@ struct gnttab_ops {
 	 * by bit operations.
 	 */
 	int (*query_foreign_access)(grant_ref_t);
+	/*
+	 * Grant a domain to access a range of bytes within the page referred by
+	 * an available grant entry. First parameter is grant entry reference
+	 * number, second one is id of grantee domain, third one is frame
+	 * address of subpage grant, forth one is grant type and flag
+	 * information, fifth one is offset of the range of bytes, and last one
+	 * is length of bytes to be accessed.
+	 */
+	void (*update_subpage_entry)(grant_ref_t, domid_t, unsigned long, int,
+				     unsigned, unsigned);
 };
 
 static struct gnttab_ops *gnttab_interface;
@@ -261,6 +271,69 @@ int gnttab_grant_foreign_access(domid_t domid, unsigned long frame,
 }
 EXPORT_SYMBOL_GPL(gnttab_grant_foreign_access);
 
+void gnttab_update_subpage_entry_v2(grant_ref_t ref, domid_t domid,
+				    unsigned long frame, int flags,
+				    unsigned page_off,
+				    unsigned length)
+{
+	gnttab_shared.v2[ref].sub_page.frame = frame;
+	gnttab_shared.v2[ref].sub_page.page_off = page_off;
+	gnttab_shared.v2[ref].sub_page.length = length;
+	gnttab_shared.v2[ref].hdr.domid = domid;
+	wmb();
+	gnttab_shared.v2[ref].hdr.flags =
+				GTF_permit_access | GTF_sub_page | flags;
+}
+
+int gnttab_grant_foreign_access_subpage_ref(grant_ref_t ref, domid_t domid,
+					    unsigned long frame, int flags,
+					    unsigned page_off,
+					    unsigned length)
+{
+	if (flags & (GTF_accept_transfer | GTF_reading |
+		     GTF_writing | GTF_transitive))
+		return -EPERM;
+
+	if (gnttab_interface->update_subpage_entry == NULL)
+		return -ENOSYS;
+
+	gnttab_interface->update_subpage_entry(ref, domid, frame, flags,
+					       page_off, length);
+
+	return 0;
+}
+EXPORT_SYMBOL_GPL(gnttab_grant_foreign_access_subpage_ref);
+
+int gnttab_grant_foreign_access_subpage(domid_t domid, unsigned long frame,
+					int flags, unsigned page_off,
+					unsigned length)
+{
+	int ref;
+
+	if (flags & (GTF_accept_transfer | GTF_reading |
+		     GTF_writing | GTF_transitive))
+		return -EPERM;
+
+	if (gnttab_interface->update_subpage_entry == NULL)
+		return -ENOSYS;
+
+	ref = get_free_entries(1);
+	if (unlikely(ref < 0))
+		return -ENOSPC;
+
+	gnttab_interface->update_subpage_entry(ref, domid, frame, flags,
+					       page_off, length);
+
+	return ref;
+}
+EXPORT_SYMBOL_GPL(gnttab_grant_foreign_access_subpage);
+
+bool gnttab_subpage_grants_available(void)
+{
+	return gnttab_interface->update_subpage_entry != NULL;
+}
+EXPORT_SYMBOL_GPL(gnttab_subpage_grants_available);
+
 static int gnttab_query_foreign_access_v1(grant_ref_t ref)
 {
 	return gnttab_shared.v1[ref].flags & (GTF_reading|GTF_writing);
@@ -813,6 +886,7 @@ static struct gnttab_ops gnttab_v2_ops = {
 	.end_foreign_access_ref		= gnttab_end_foreign_access_ref_v2,
 	.end_foreign_transfer_ref	= gnttab_end_foreign_transfer_ref_v2,
 	.query_foreign_access		= gnttab_query_foreign_access_v2,
+	.update_subpage_entry		= gnttab_update_subpage_entry_v2,
 };
 
 static void gnttab_request_version(void)
diff --git a/include/xen/grant_table.h b/include/xen/grant_table.h
index fea4954..2b492b9 100644
--- a/include/xen/grant_table.h
+++ b/include/xen/grant_table.h
@@ -62,6 +62,15 @@ int gnttab_resume(void);
 
 int gnttab_grant_foreign_access(domid_t domid, unsigned long frame,
 				int readonly);
+int gnttab_grant_foreign_access_subpage(domid_t domid, unsigned long frame,
+					int flags, unsigned page_off,
+					unsigned length);
+
+/*
+ * Are sub-page grants available on this version of Xen?  Returns true if they
+ * are, and false if they're not.
+ */
+bool gnttab_subpage_grants_available(void);
 
 /*
  * End access through the given grant reference, iff the grant entry is no
@@ -108,6 +117,10 @@ void gnttab_cancel_free_callback(struct gnttab_free_callback *callback);
 
 void gnttab_grant_foreign_access_ref(grant_ref_t ref, domid_t domid,
 				     unsigned long frame, int readonly);
+int gnttab_grant_foreign_access_subpage_ref(grant_ref_t ref, domid_t domid,
+					    unsigned long frame, int flags,
+					    unsigned page_off,
+					    unsigned length);
 
 void gnttab_grant_foreign_transfer_ref(grant_ref_t, domid_t domid,
 				       unsigned long pfn);
-- 
1.7.6.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 08 09:39:00 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 Dec 2011 09:39:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYaRD-0000K2-GX; Thu, 08 Dec 2011 09:38:47 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <annie.li@oracle.com>) id 1RYaRB-0000Jn-PN
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 09:38:46 +0000
X-Env-Sender: annie.li@oracle.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1323337048!55854791!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDI1MDU3\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9438 invoked from network); 8 Dec 2011 09:37:29 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-9.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 8 Dec 2011 09:37:29 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pB89bwlw013472
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 8 Dec 2011 09:37:58 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pB89bvp6004832
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 8 Dec 2011 09:37:57 GMT
Received: from abhmt104.oracle.com (abhmt104.oracle.com [141.146.116.56])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pB89bqK1003598; Thu, 8 Dec 2011 03:37:52 -0600
Received: from annie2.cn.oracle.com.com (/10.182.37.169)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 08 Dec 2011 01:37:51 -0800
From: annie.li@oracle.com
To: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org,
	konrad.wilk@oracle.com, jeremy@goop.org, paul.durrant@citrix.com,
	Ian.Campbell@citrix.com
Date: Thu,  8 Dec 2011 17:37:57 +0800
Message-Id: <1323337077-5457-1-git-send-email-annie.li@oracle.com>
X-Mailer: git-send-email 1.7.6.4
In-Reply-To: <1323336940-5382-1-git-send-email-annie.li@oracle.com>
References: <1323336940-5382-1-git-send-email-annie.li@oracle.com>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090202.4EE08577.0047,ss=1,re=0.000,fgs=0
Cc: kurt.hackel@oracle.com, annie.li@oracle.com
Subject: [Xen-devel] [PATCH V2 2/2] xen/granttable: Support transitive grants
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

These allow a domain A which has been granted access on a page of domain B's
memory to issue domain C with a copy-grant on the same page.  This is useful
e.g. for forwarding packets between domains.

Signed-off-by: Annie Li <annie.li@oracle.com>
---
 drivers/xen/grant-table.c |   73 +++++++++++++++++++++++++++++++++++++++++++++
 include/xen/grant_table.h |   12 +++++++
 2 files changed, 85 insertions(+), 0 deletions(-)

diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
index 4a10e3f..db3e7c0 100644
--- a/drivers/xen/grant-table.c
+++ b/drivers/xen/grant-table.c
@@ -130,6 +130,18 @@ struct gnttab_ops {
 	 */
 	void (*update_subpage_entry)(grant_ref_t, domid_t, unsigned long, int,
 				     unsigned, unsigned);
+	/*
+	 * Redirect an available grant entry on domain A to another grant
+	 * reference of domain B, then allow domain C to use grant reference
+	 * of domain B transitively. First parameter is an available grant entry
+	 * reference on domain A, second one is id of domain C which accesses
+	 * grant entry transitively, third one is grant type and flag
+	 * information, forth one is id of domain B whose grant entry is finally
+	 * accessed transitively, last one is grant entry transitive reference
+	 * of domain B.
+	 */
+	void (*update_trans_entry)(grant_ref_t, domid_t, int, domid_t,
+				   grant_ref_t);
 };
 
 static struct gnttab_ops *gnttab_interface;
@@ -334,6 +346,66 @@ bool gnttab_subpage_grants_available(void)
 }
 EXPORT_SYMBOL_GPL(gnttab_subpage_grants_available);
 
+void gnttab_update_trans_entry_v2(grant_ref_t ref, domid_t domid,
+				  int flags, domid_t trans_domid,
+				  grant_ref_t trans_gref)
+{
+	gnttab_shared.v2[ref].transitive.trans_domid = trans_domid;
+	gnttab_shared.v2[ref].transitive.gref = trans_gref;
+	gnttab_shared.v2[ref].hdr.domid = domid;
+	wmb();
+	gnttab_shared.v2[ref].hdr.flags =
+				GTF_permit_access | GTF_transitive | flags;
+}
+
+int gnttab_grant_foreign_access_trans_ref(grant_ref_t ref, domid_t domid,
+					  int flags, domid_t trans_domid,
+					  grant_ref_t trans_gref)
+{
+	if (flags & (GTF_accept_transfer | GTF_reading |
+		     GTF_writing | GTF_sub_page))
+		return -EPERM;
+
+	if (gnttab_interface->update_trans_entry == NULL)
+		return -ENOSYS;
+
+	gnttab_interface->update_trans_entry(ref, domid, flags, trans_domid,
+					     trans_gref);
+
+	return 0;
+}
+EXPORT_SYMBOL_GPL(gnttab_grant_foreign_access_trans_ref);
+
+int gnttab_grant_foreign_access_trans(domid_t domid, int flags,
+				      domid_t trans_domid,
+				      grant_ref_t trans_gref)
+{
+	int ref;
+
+	if (flags & (GTF_accept_transfer | GTF_reading |
+		     GTF_writing | GTF_sub_page))
+		return -EPERM;
+
+	if (gnttab_interface->update_trans_entry == NULL)
+		return -ENOSYS;
+
+	ref = get_free_entries(1);
+	if (unlikely(ref < 0))
+		return -ENOSPC;
+
+	gnttab_interface->update_trans_entry(ref, domid, flags, trans_domid,
+					     trans_gref);
+
+	return ref;
+}
+EXPORT_SYMBOL_GPL(gnttab_grant_foreign_access_trans);
+
+bool gnttab_trans_grants_available(void)
+{
+	return gnttab_interface->update_trans_entry != NULL;
+}
+EXPORT_SYMBOL_GPL(gnttab_trans_grants_available);
+
 static int gnttab_query_foreign_access_v1(grant_ref_t ref)
 {
 	return gnttab_shared.v1[ref].flags & (GTF_reading|GTF_writing);
@@ -887,6 +959,7 @@ static struct gnttab_ops gnttab_v2_ops = {
 	.end_foreign_transfer_ref	= gnttab_end_foreign_transfer_ref_v2,
 	.query_foreign_access		= gnttab_query_foreign_access_v2,
 	.update_subpage_entry		= gnttab_update_subpage_entry_v2,
+	.update_trans_entry		= gnttab_update_trans_entry_v2,
 };
 
 static void gnttab_request_version(void)
diff --git a/include/xen/grant_table.h b/include/xen/grant_table.h
index 2b492b9..f1e17b7 100644
--- a/include/xen/grant_table.h
+++ b/include/xen/grant_table.h
@@ -65,6 +65,9 @@ int gnttab_grant_foreign_access(domid_t domid, unsigned long frame,
 int gnttab_grant_foreign_access_subpage(domid_t domid, unsigned long frame,
 					int flags, unsigned page_off,
 					unsigned length);
+int gnttab_grant_foreign_access_trans(domid_t domid, int flags,
+				      domid_t trans_domid,
+				      grant_ref_t trans_gref);
 
 /*
  * Are sub-page grants available on this version of Xen?  Returns true if they
@@ -73,6 +76,12 @@ int gnttab_grant_foreign_access_subpage(domid_t domid, unsigned long frame,
 bool gnttab_subpage_grants_available(void);
 
 /*
+ * Are transitive grants available on this version of Xen?  Returns true if they
+ * are, and false if they're not.
+ */
+bool gnttab_trans_grants_available(void);
+
+/*
  * End access through the given grant reference, iff the grant entry is no
  * longer in use.  Return 1 if the grant entry was freed, 0 if it is still in
  * use.
@@ -121,6 +130,9 @@ int gnttab_grant_foreign_access_subpage_ref(grant_ref_t ref, domid_t domid,
 					    unsigned long frame, int flags,
 					    unsigned page_off,
 					    unsigned length);
+int gnttab_grant_foreign_access_trans_ref(grant_ref_t ref, domid_t domid,
+					  int flags, domid_t trans_domid,
+					  grant_ref_t trans_gref);
 
 void gnttab_grant_foreign_transfer_ref(grant_ref_t, domid_t domid,
 				       unsigned long pfn);
-- 
1.7.6.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 08 09:39:00 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 Dec 2011 09:39:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYaRD-0000K2-GX; Thu, 08 Dec 2011 09:38:47 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <annie.li@oracle.com>) id 1RYaRB-0000Jn-PN
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 09:38:46 +0000
X-Env-Sender: annie.li@oracle.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1323337048!55854791!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDI1MDU3\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9438 invoked from network); 8 Dec 2011 09:37:29 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-9.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 8 Dec 2011 09:37:29 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pB89bwlw013472
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 8 Dec 2011 09:37:58 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pB89bvp6004832
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 8 Dec 2011 09:37:57 GMT
Received: from abhmt104.oracle.com (abhmt104.oracle.com [141.146.116.56])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pB89bqK1003598; Thu, 8 Dec 2011 03:37:52 -0600
Received: from annie2.cn.oracle.com.com (/10.182.37.169)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 08 Dec 2011 01:37:51 -0800
From: annie.li@oracle.com
To: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org,
	konrad.wilk@oracle.com, jeremy@goop.org, paul.durrant@citrix.com,
	Ian.Campbell@citrix.com
Date: Thu,  8 Dec 2011 17:37:57 +0800
Message-Id: <1323337077-5457-1-git-send-email-annie.li@oracle.com>
X-Mailer: git-send-email 1.7.6.4
In-Reply-To: <1323336940-5382-1-git-send-email-annie.li@oracle.com>
References: <1323336940-5382-1-git-send-email-annie.li@oracle.com>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090202.4EE08577.0047,ss=1,re=0.000,fgs=0
Cc: kurt.hackel@oracle.com, annie.li@oracle.com
Subject: [Xen-devel] [PATCH V2 2/2] xen/granttable: Support transitive grants
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

These allow a domain A which has been granted access on a page of domain B's
memory to issue domain C with a copy-grant on the same page.  This is useful
e.g. for forwarding packets between domains.

Signed-off-by: Annie Li <annie.li@oracle.com>
---
 drivers/xen/grant-table.c |   73 +++++++++++++++++++++++++++++++++++++++++++++
 include/xen/grant_table.h |   12 +++++++
 2 files changed, 85 insertions(+), 0 deletions(-)

diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
index 4a10e3f..db3e7c0 100644
--- a/drivers/xen/grant-table.c
+++ b/drivers/xen/grant-table.c
@@ -130,6 +130,18 @@ struct gnttab_ops {
 	 */
 	void (*update_subpage_entry)(grant_ref_t, domid_t, unsigned long, int,
 				     unsigned, unsigned);
+	/*
+	 * Redirect an available grant entry on domain A to another grant
+	 * reference of domain B, then allow domain C to use grant reference
+	 * of domain B transitively. First parameter is an available grant entry
+	 * reference on domain A, second one is id of domain C which accesses
+	 * grant entry transitively, third one is grant type and flag
+	 * information, forth one is id of domain B whose grant entry is finally
+	 * accessed transitively, last one is grant entry transitive reference
+	 * of domain B.
+	 */
+	void (*update_trans_entry)(grant_ref_t, domid_t, int, domid_t,
+				   grant_ref_t);
 };
 
 static struct gnttab_ops *gnttab_interface;
@@ -334,6 +346,66 @@ bool gnttab_subpage_grants_available(void)
 }
 EXPORT_SYMBOL_GPL(gnttab_subpage_grants_available);
 
+void gnttab_update_trans_entry_v2(grant_ref_t ref, domid_t domid,
+				  int flags, domid_t trans_domid,
+				  grant_ref_t trans_gref)
+{
+	gnttab_shared.v2[ref].transitive.trans_domid = trans_domid;
+	gnttab_shared.v2[ref].transitive.gref = trans_gref;
+	gnttab_shared.v2[ref].hdr.domid = domid;
+	wmb();
+	gnttab_shared.v2[ref].hdr.flags =
+				GTF_permit_access | GTF_transitive | flags;
+}
+
+int gnttab_grant_foreign_access_trans_ref(grant_ref_t ref, domid_t domid,
+					  int flags, domid_t trans_domid,
+					  grant_ref_t trans_gref)
+{
+	if (flags & (GTF_accept_transfer | GTF_reading |
+		     GTF_writing | GTF_sub_page))
+		return -EPERM;
+
+	if (gnttab_interface->update_trans_entry == NULL)
+		return -ENOSYS;
+
+	gnttab_interface->update_trans_entry(ref, domid, flags, trans_domid,
+					     trans_gref);
+
+	return 0;
+}
+EXPORT_SYMBOL_GPL(gnttab_grant_foreign_access_trans_ref);
+
+int gnttab_grant_foreign_access_trans(domid_t domid, int flags,
+				      domid_t trans_domid,
+				      grant_ref_t trans_gref)
+{
+	int ref;
+
+	if (flags & (GTF_accept_transfer | GTF_reading |
+		     GTF_writing | GTF_sub_page))
+		return -EPERM;
+
+	if (gnttab_interface->update_trans_entry == NULL)
+		return -ENOSYS;
+
+	ref = get_free_entries(1);
+	if (unlikely(ref < 0))
+		return -ENOSPC;
+
+	gnttab_interface->update_trans_entry(ref, domid, flags, trans_domid,
+					     trans_gref);
+
+	return ref;
+}
+EXPORT_SYMBOL_GPL(gnttab_grant_foreign_access_trans);
+
+bool gnttab_trans_grants_available(void)
+{
+	return gnttab_interface->update_trans_entry != NULL;
+}
+EXPORT_SYMBOL_GPL(gnttab_trans_grants_available);
+
 static int gnttab_query_foreign_access_v1(grant_ref_t ref)
 {
 	return gnttab_shared.v1[ref].flags & (GTF_reading|GTF_writing);
@@ -887,6 +959,7 @@ static struct gnttab_ops gnttab_v2_ops = {
 	.end_foreign_transfer_ref	= gnttab_end_foreign_transfer_ref_v2,
 	.query_foreign_access		= gnttab_query_foreign_access_v2,
 	.update_subpage_entry		= gnttab_update_subpage_entry_v2,
+	.update_trans_entry		= gnttab_update_trans_entry_v2,
 };
 
 static void gnttab_request_version(void)
diff --git a/include/xen/grant_table.h b/include/xen/grant_table.h
index 2b492b9..f1e17b7 100644
--- a/include/xen/grant_table.h
+++ b/include/xen/grant_table.h
@@ -65,6 +65,9 @@ int gnttab_grant_foreign_access(domid_t domid, unsigned long frame,
 int gnttab_grant_foreign_access_subpage(domid_t domid, unsigned long frame,
 					int flags, unsigned page_off,
 					unsigned length);
+int gnttab_grant_foreign_access_trans(domid_t domid, int flags,
+				      domid_t trans_domid,
+				      grant_ref_t trans_gref);
 
 /*
  * Are sub-page grants available on this version of Xen?  Returns true if they
@@ -73,6 +76,12 @@ int gnttab_grant_foreign_access_subpage(domid_t domid, unsigned long frame,
 bool gnttab_subpage_grants_available(void);
 
 /*
+ * Are transitive grants available on this version of Xen?  Returns true if they
+ * are, and false if they're not.
+ */
+bool gnttab_trans_grants_available(void);
+
+/*
  * End access through the given grant reference, iff the grant entry is no
  * longer in use.  Return 1 if the grant entry was freed, 0 if it is still in
  * use.
@@ -121,6 +130,9 @@ int gnttab_grant_foreign_access_subpage_ref(grant_ref_t ref, domid_t domid,
 					    unsigned long frame, int flags,
 					    unsigned page_off,
 					    unsigned length);
+int gnttab_grant_foreign_access_trans_ref(grant_ref_t ref, domid_t domid,
+					  int flags, domid_t trans_domid,
+					  grant_ref_t trans_gref);
 
 void gnttab_grant_foreign_transfer_ref(grant_ref_t, domid_t domid,
 				       unsigned long pfn);
-- 
1.7.6.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 08 09:48:39 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 Dec 2011 09:48:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYaaV-00017n-Nn; Thu, 08 Dec 2011 09:48:23 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RYaaT-00017g-Ox
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 09:48:22 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1323337652!7281320!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDg5NQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16276 invoked from network); 8 Dec 2011 09:47:32 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Dec 2011 09:47:32 -0000
X-IronPort-AV: E=Sophos;i="4.71,319,1320624000"; 
   d="scan'208";a="9357829"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Dec 2011 09:47:32 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 8 Dec 2011
	09:47:32 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Thu, 8 Dec 2011 09:47:32 +0000
In-Reply-To: <1323108621-22654-15-git-send-email-ian.jackson@eu.citrix.com>
References: <1323108621-22654-1-git-send-email-ian.jackson@eu.citrix.com>
	<1323108621-22654-15-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323337652.2969.80.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 14/15] libxl: New API for providing OS
 events to libxl
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> [...snip already reviewed bits...]
> +/*
> + * osevent poll
> + */
> +
> +int libxl_osevent_beforepoll(libxl_ctx *ctx, int *nfds_io,
> +                             struct pollfd *fds, int *timeout_upd,
> +                             struct timeval now) {
> +    libxl__ev_fd *efd;
> +    int i;
> +
> +    /*
> +     * In order to be able to efficiently find the libxl__ev_fd
> +     * for a struct poll during _afterpoll, we maintain a shadow
> +     * data structure in CTX->fd_beforepolled: each slot in
> +     * the fds array corresponds to a slot in fd_beforepolled.
> +     */
> +
> +    GC_INIT(ctx);
> +    CTX_LOCK;
> +
> +    if (*nfds_io) {
> +        /*
> +         * As an optimisation, we don't touch fd_beforepolled_used
> +         * if *nfds_io is zero on entry, since in that case the
> +         * caller just wanted to know how big an array to give us.
> +         *
> +         * If !*nfds_io, the unconditional parts below are guaranteed
> +         * not to mess with fd_beforepolled... or any in_beforepolled.
> +         */
> +
> +        /* Remove all the old references into beforepolled */
> +        for (i = 0; i < CTX->fd_beforepolled_used; i++) {
> +            efd = CTX->fd_beforepolled[i];
> +            if (efd) {
> +                assert(efd->in_beforepolled == i);
> +                efd->in_beforepolled = -1;
> +                CTX->fd_beforepolled[i] = NULL;
> +            }
> +        }
> +        CTX->fd_beforepolled_used = 0;
> +
> +        /* make sure our array is as big as *nfds_io */
> +        if (CTX->fd_beforepolled_allocd < *nfds_io) {
> +            assert(*nfds_io < INT_MAX / sizeof(libxl__ev_fd*) / 2);

What is the /2 for?

> +            libxl__ev_fd **newarray =
> +                realloc(CTX->fd_beforepolled, sizeof(*newarray) * *nfds_io);
> +            if (!newarray)
> +                return ERROR_NOMEM;

Need to CTX_UNLOCK here.

> +            CTX->fd_beforepolled = newarray;
> +            CTX->fd_beforepolled_allocd = *nfds_io;
> +        }
> +    }
> +
> +    int used = 0;
> +    LIBXL_LIST_FOREACH(efd, &CTX->efds, entry) {
> +        if (used < *nfds_io) {
> +            fds[used].fd = efd->fd;
> +            fds[used].events = efd->events;
> +            fds[used].revents = 0;
> +            CTX->fd_beforepolled[used] = efd;
> +            efd->in_beforepolled = used;
> +        }
> +        used++;
> +    }
> +    int rc = used <= *nfds_io ? 0 : ERROR_BUFFERFULL;
> +
> +    if (*nfds_io) {
> +        CTX->fd_beforepolled_used = used;
> +    }
> +
> +    *nfds_io = used;
> +
> +    libxl__ev_time *etime = LIBXL_TAILQ_FIRST(&CTX->etimes);
> +    if (etime) {
> +        int our_timeout;
> +        struct timeval rel;
> +        static struct timeval zero;
> +
> +        timersub(&etime->abs, &now, &rel);
> +
> +        if (timercmp(&rel, &zero, <)) {
> +            our_timeout = 0;
> +        } else if (rel.tv_sec >= 2000000) {
> +            our_timeout = 2000000000;
> +        } else {
> +            our_timeout = rel.tv_sec * 1000 + (rel.tv_usec + 999) / 1000;
> +        }
> +        if (*timeout_upd < 0 || our_timeout < *timeout_upd)
> +            *timeout_upd = our_timeout;
> +    }
> +
> +    CTX_UNLOCK;
> +    GC_FREE;
> +    return rc;
> +}
> +
> +void libxl_osevent_afterpoll(libxl_ctx *ctx, int nfds, const struct pollfd *fds,
> +                             struct timeval now) {
> +    int i;
> +    GC_INIT(ctx);
> +    CTX_LOCK;
> +
> +    assert(nfds <= CTX->fd_beforepolled_used);
> +
> +    for (i = 0; i < nfds; i++) {
> +        if (!fds[i].revents)
> +            continue;
> +
> +        libxl__ev_fd *efd = CTX->fd_beforepolled[i];
> +        if (!efd)
> +            continue;

Would this be a bug? If we've set it up for polling how can it be NULL?

> +
> +        assert(efd->in_beforepolled == i);
> +        assert(fds[i].fd == efd->fd);
> +
> +        int revents = fds[i].revents & efd->events;
> +        if (!revents)
> +            continue;
> +
> +        efd->func(gc, efd, efd->fd, efd->events, revents);
> +    }
> +
> +    for (;;) {
> +        libxl__ev_time *etime = LIBXL_TAILQ_FIRST(&CTX->etimes);
> +        if (!etime)
> +            break;
> +
> +        assert(!etime->infinite);
> +
> +        if (timercmp(&etime->abs, &now, >))
> +            break;
> +
> +        time_deregister(gc, etime);
> +
> +        etime->func(gc, etime, &etime->abs);
> +    }
> +
> +    CTX_UNLOCK;
> +    GC_FREE;
> +}
> +
> +
> +/*
> + * osevent hook and callback machinery
> + */
> +
> +void libxl_osevent_register_hooks(libxl_ctx *ctx,
> +                                  const libxl_osevent_hooks *hooks,
> +                                  void *user) {
> +    GC_INIT(ctx);

I nearly said, "there's no gc used in this function" but actually it is
artfully concealed in CTX_LOCK.

I wonder if CTX_LOCK should take the context, e.g. either CTX_LOCK(CTX)
or CTX_LOCK(ctx)?

Another alternative would be to have CTX_INIT to parallel GC_INIT which
creates a local *ctx instead of having CTX. This would also avoid the
need to s/CTX/ctx/ if you make an internal function into an external one
and vice versa.

> +    CTX_LOCK;
> +    ctx->osevent_hooks = hooks;
> +    ctx->osevent_user = user;
> +    CTX_UNLOCK;
> +    GC_FREE;
> +}
> +
> +
[...]
> diff --git a/tools/libxl/libxl_event.h b/tools/libxl/libxl_event.h
> new file mode 100644
> index 0000000..25efbdf
> --- /dev/null
> +++ b/tools/libxl/libxl_event.h
> @@ -0,0 +1,199 @@
[...]
> +int libxl_osevent_beforepoll(libxl_ctx *ctx, int *nfds_io,
> +                             struct pollfd *fds, int *timeout_upd,
> +                             struct timeval now);
> +  /* The caller should provide beforepoll with some space for libxl's
> +   * fds, and tell libxl how much space is available by setting *nfds_io.
> +   * fds points to the start of this space (and fds may be a pointer into
> +   * a larger array, for example, if the application has some fds of
> +   * its own that it is interested in).
> +   *
> +   * On return *nfds_io will in any case have been updated by libxl
> +   * according to how many fds libxl wants to poll on.
> +   *
> +   * If the space was sufficient, libxl fills in fds[0..<new
> +   * *nfds_io>] suitably for poll(2), updates *timeout_upd if needed,
> +   * and returns ok.
> +   *
> +   * If space was insufficient, fds[0..<old *nfds_io>] is undefined on
> +   * return; *nfds_io on return will be greater than the value on
> +   * entry; *timeout_upd may or may not have been updated; and
> +   * libxl_osevent_beforepoll returns ERROR_BUFERFULL.  In this case

                                         ERROR_BUFFERFULL
[...]

> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> index d015c7c..88e7dbb 100644
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
[...]
> @@ -138,12 +218,12 @@ typedef struct {
> 
>  #define PRINTF_ATTRIBUTE(x, y) __attribute__((format(printf, x, y)))
> 
> -typedef struct {
> +struct libxl__gc {
>      /* mini-GC */
>      int alloc_maxsize;
>      void **alloc_ptrs;
>      libxl_ctx *owner;
> -} libxl__gc;
> +};

Is this an unrelated change which has snuck in? I'd hack expected an
equivalent change to GC_INIT if not.

[...]
> --
> 1.7.2.5

Phew!



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 08 09:48:39 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 Dec 2011 09:48:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYaaV-00017n-Nn; Thu, 08 Dec 2011 09:48:23 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RYaaT-00017g-Ox
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 09:48:22 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1323337652!7281320!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDg5NQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16276 invoked from network); 8 Dec 2011 09:47:32 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Dec 2011 09:47:32 -0000
X-IronPort-AV: E=Sophos;i="4.71,319,1320624000"; 
   d="scan'208";a="9357829"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Dec 2011 09:47:32 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 8 Dec 2011
	09:47:32 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Thu, 8 Dec 2011 09:47:32 +0000
In-Reply-To: <1323108621-22654-15-git-send-email-ian.jackson@eu.citrix.com>
References: <1323108621-22654-1-git-send-email-ian.jackson@eu.citrix.com>
	<1323108621-22654-15-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323337652.2969.80.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 14/15] libxl: New API for providing OS
 events to libxl
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> [...snip already reviewed bits...]
> +/*
> + * osevent poll
> + */
> +
> +int libxl_osevent_beforepoll(libxl_ctx *ctx, int *nfds_io,
> +                             struct pollfd *fds, int *timeout_upd,
> +                             struct timeval now) {
> +    libxl__ev_fd *efd;
> +    int i;
> +
> +    /*
> +     * In order to be able to efficiently find the libxl__ev_fd
> +     * for a struct poll during _afterpoll, we maintain a shadow
> +     * data structure in CTX->fd_beforepolled: each slot in
> +     * the fds array corresponds to a slot in fd_beforepolled.
> +     */
> +
> +    GC_INIT(ctx);
> +    CTX_LOCK;
> +
> +    if (*nfds_io) {
> +        /*
> +         * As an optimisation, we don't touch fd_beforepolled_used
> +         * if *nfds_io is zero on entry, since in that case the
> +         * caller just wanted to know how big an array to give us.
> +         *
> +         * If !*nfds_io, the unconditional parts below are guaranteed
> +         * not to mess with fd_beforepolled... or any in_beforepolled.
> +         */
> +
> +        /* Remove all the old references into beforepolled */
> +        for (i = 0; i < CTX->fd_beforepolled_used; i++) {
> +            efd = CTX->fd_beforepolled[i];
> +            if (efd) {
> +                assert(efd->in_beforepolled == i);
> +                efd->in_beforepolled = -1;
> +                CTX->fd_beforepolled[i] = NULL;
> +            }
> +        }
> +        CTX->fd_beforepolled_used = 0;
> +
> +        /* make sure our array is as big as *nfds_io */
> +        if (CTX->fd_beforepolled_allocd < *nfds_io) {
> +            assert(*nfds_io < INT_MAX / sizeof(libxl__ev_fd*) / 2);

What is the /2 for?

> +            libxl__ev_fd **newarray =
> +                realloc(CTX->fd_beforepolled, sizeof(*newarray) * *nfds_io);
> +            if (!newarray)
> +                return ERROR_NOMEM;

Need to CTX_UNLOCK here.

> +            CTX->fd_beforepolled = newarray;
> +            CTX->fd_beforepolled_allocd = *nfds_io;
> +        }
> +    }
> +
> +    int used = 0;
> +    LIBXL_LIST_FOREACH(efd, &CTX->efds, entry) {
> +        if (used < *nfds_io) {
> +            fds[used].fd = efd->fd;
> +            fds[used].events = efd->events;
> +            fds[used].revents = 0;
> +            CTX->fd_beforepolled[used] = efd;
> +            efd->in_beforepolled = used;
> +        }
> +        used++;
> +    }
> +    int rc = used <= *nfds_io ? 0 : ERROR_BUFFERFULL;
> +
> +    if (*nfds_io) {
> +        CTX->fd_beforepolled_used = used;
> +    }
> +
> +    *nfds_io = used;
> +
> +    libxl__ev_time *etime = LIBXL_TAILQ_FIRST(&CTX->etimes);
> +    if (etime) {
> +        int our_timeout;
> +        struct timeval rel;
> +        static struct timeval zero;
> +
> +        timersub(&etime->abs, &now, &rel);
> +
> +        if (timercmp(&rel, &zero, <)) {
> +            our_timeout = 0;
> +        } else if (rel.tv_sec >= 2000000) {
> +            our_timeout = 2000000000;
> +        } else {
> +            our_timeout = rel.tv_sec * 1000 + (rel.tv_usec + 999) / 1000;
> +        }
> +        if (*timeout_upd < 0 || our_timeout < *timeout_upd)
> +            *timeout_upd = our_timeout;
> +    }
> +
> +    CTX_UNLOCK;
> +    GC_FREE;
> +    return rc;
> +}
> +
> +void libxl_osevent_afterpoll(libxl_ctx *ctx, int nfds, const struct pollfd *fds,
> +                             struct timeval now) {
> +    int i;
> +    GC_INIT(ctx);
> +    CTX_LOCK;
> +
> +    assert(nfds <= CTX->fd_beforepolled_used);
> +
> +    for (i = 0; i < nfds; i++) {
> +        if (!fds[i].revents)
> +            continue;
> +
> +        libxl__ev_fd *efd = CTX->fd_beforepolled[i];
> +        if (!efd)
> +            continue;

Would this be a bug? If we've set it up for polling how can it be NULL?

> +
> +        assert(efd->in_beforepolled == i);
> +        assert(fds[i].fd == efd->fd);
> +
> +        int revents = fds[i].revents & efd->events;
> +        if (!revents)
> +            continue;
> +
> +        efd->func(gc, efd, efd->fd, efd->events, revents);
> +    }
> +
> +    for (;;) {
> +        libxl__ev_time *etime = LIBXL_TAILQ_FIRST(&CTX->etimes);
> +        if (!etime)
> +            break;
> +
> +        assert(!etime->infinite);
> +
> +        if (timercmp(&etime->abs, &now, >))
> +            break;
> +
> +        time_deregister(gc, etime);
> +
> +        etime->func(gc, etime, &etime->abs);
> +    }
> +
> +    CTX_UNLOCK;
> +    GC_FREE;
> +}
> +
> +
> +/*
> + * osevent hook and callback machinery
> + */
> +
> +void libxl_osevent_register_hooks(libxl_ctx *ctx,
> +                                  const libxl_osevent_hooks *hooks,
> +                                  void *user) {
> +    GC_INIT(ctx);

I nearly said, "there's no gc used in this function" but actually it is
artfully concealed in CTX_LOCK.

I wonder if CTX_LOCK should take the context, e.g. either CTX_LOCK(CTX)
or CTX_LOCK(ctx)?

Another alternative would be to have CTX_INIT to parallel GC_INIT which
creates a local *ctx instead of having CTX. This would also avoid the
need to s/CTX/ctx/ if you make an internal function into an external one
and vice versa.

> +    CTX_LOCK;
> +    ctx->osevent_hooks = hooks;
> +    ctx->osevent_user = user;
> +    CTX_UNLOCK;
> +    GC_FREE;
> +}
> +
> +
[...]
> diff --git a/tools/libxl/libxl_event.h b/tools/libxl/libxl_event.h
> new file mode 100644
> index 0000000..25efbdf
> --- /dev/null
> +++ b/tools/libxl/libxl_event.h
> @@ -0,0 +1,199 @@
[...]
> +int libxl_osevent_beforepoll(libxl_ctx *ctx, int *nfds_io,
> +                             struct pollfd *fds, int *timeout_upd,
> +                             struct timeval now);
> +  /* The caller should provide beforepoll with some space for libxl's
> +   * fds, and tell libxl how much space is available by setting *nfds_io.
> +   * fds points to the start of this space (and fds may be a pointer into
> +   * a larger array, for example, if the application has some fds of
> +   * its own that it is interested in).
> +   *
> +   * On return *nfds_io will in any case have been updated by libxl
> +   * according to how many fds libxl wants to poll on.
> +   *
> +   * If the space was sufficient, libxl fills in fds[0..<new
> +   * *nfds_io>] suitably for poll(2), updates *timeout_upd if needed,
> +   * and returns ok.
> +   *
> +   * If space was insufficient, fds[0..<old *nfds_io>] is undefined on
> +   * return; *nfds_io on return will be greater than the value on
> +   * entry; *timeout_upd may or may not have been updated; and
> +   * libxl_osevent_beforepoll returns ERROR_BUFERFULL.  In this case

                                         ERROR_BUFFERFULL
[...]

> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> index d015c7c..88e7dbb 100644
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
[...]
> @@ -138,12 +218,12 @@ typedef struct {
> 
>  #define PRINTF_ATTRIBUTE(x, y) __attribute__((format(printf, x, y)))
> 
> -typedef struct {
> +struct libxl__gc {
>      /* mini-GC */
>      int alloc_maxsize;
>      void **alloc_ptrs;
>      libxl_ctx *owner;
> -} libxl__gc;
> +};

Is this an unrelated change which has snuck in? I'd hack expected an
equivalent change to GC_INIT if not.

[...]
> --
> 1.7.2.5

Phew!



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 08 09:50:21 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 Dec 2011 09:50:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYacB-0001Dd-86; Thu, 08 Dec 2011 09:50:07 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RYac9-0001DS-QP
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 09:50:06 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1323337654!55330088!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDg5NQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14438 invoked from network); 8 Dec 2011 09:47:34 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Dec 2011 09:47:34 -0000
X-IronPort-AV: E=Sophos;i="4.71,319,1320624000"; 
   d="scan'208";a="9357866"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Dec 2011 09:49:22 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.161]) by
	LONPMAILMX01.citrite.net ([10.30.203.162]) with mapi; Thu, 8 Dec 2011
	09:49:22 +0000
From: Paul Durrant <Paul.Durrant@citrix.com>
To: "annie.li@oracle.com" <annie.li@oracle.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>, "jeremy@goop.org"
	<jeremy@goop.org>, Ian Campbell <Ian.Campbell@citrix.com>
Date: Thu, 8 Dec 2011 09:49:31 +0000
Thread-Topic: [PATCH V2 1/2] xen/granttable: Support sub-page grants
Thread-Index: Acy1jQLJQf54ufTdTwud/abmTvIfzgAAKUiQ
Message-ID: <291EDFCB1E9E224A99088639C4762022B5988E5528@LONPMAILBOX01.citrite.net>
References: <1323336940-5382-1-git-send-email-annie.li@oracle.com>
	<1323337048-5426-1-git-send-email-annie.li@oracle.com>
In-Reply-To: <1323337048-5426-1-git-send-email-annie.li@oracle.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "kurt.hackel@oracle.com" <kurt.hackel@oracle.com>
Subject: Re: [Xen-devel] [PATCH V2 1/2] xen/granttable: Support sub-page
	grants
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com



> -----Original Message-----
> From: annie.li@oracle.com [mailto:annie.li@oracle.com]
> Sent: 08 December 2011 09:37
> To: xen-devel@lists.xensource.com; linux-kernel@vger.kernel.org;
> konrad.wilk@oracle.com; jeremy@goop.org; Paul Durrant; Ian Campbell
> Cc: kurt.hackel@oracle.com; annie.li@oracle.com
> Subject: [PATCH V2 1/2] xen/granttable: Support sub-page grants
> 
>     -- They can't be used to map the page (so can only be used in a
> GNTTABOP_copy
>        hypercall).
>     -- It's possible to grant access with a finer granularity than
> whole pages.
>     -- Xen guarantees that they can be revoked quickly (a normal map
> grant can
>        only be revoked with the cooperation of the domain which has
> been granted
>        access).
> 
> Signed-off-by: Annie Li <annie.li@oracle.com>
> ---
>  drivers/xen/grant-table.c |   74
> +++++++++++++++++++++++++++++++++++++++++++++
>  include/xen/grant_table.h |   13 ++++++++
>  2 files changed, 87 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
> index bd325fd..4a10e3f 100644
> --- a/drivers/xen/grant-table.c
> +++ b/drivers/xen/grant-table.c
> @@ -120,6 +120,16 @@ struct gnttab_ops {
>  	 * by bit operations.
>  	 */
>  	int (*query_foreign_access)(grant_ref_t);
> +	/*
> +	 * Grant a domain to access a range of bytes within the page
> referred by
> +	 * an available grant entry. First parameter is grant entry
> reference
> +	 * number, second one is id of grantee domain, third one is
> frame
> +	 * address of subpage grant, forth one is grant type and flag
> +	 * information, fifth one is offset of the range of bytes,
> and last one
> +	 * is length of bytes to be accessed.
> +	 */
> +	void (*update_subpage_entry)(grant_ref_t, domid_t, unsigned
> long, int,
> +				     unsigned, unsigned);
>  };
> 
>  static struct gnttab_ops *gnttab_interface; @@ -261,6 +271,69 @@
> int gnttab_grant_foreign_access(domid_t domid, unsigned long frame,
> }  EXPORT_SYMBOL_GPL(gnttab_grant_foreign_access);
> 
> +void gnttab_update_subpage_entry_v2(grant_ref_t ref, domid_t domid,
> +				    unsigned long frame, int flags,
> +				    unsigned page_off,
> +				    unsigned length)
> +{
> +	gnttab_shared.v2[ref].sub_page.frame = frame;
> +	gnttab_shared.v2[ref].sub_page.page_off = page_off;
> +	gnttab_shared.v2[ref].sub_page.length = length;
> +	gnttab_shared.v2[ref].hdr.domid = domid;
> +	wmb();
> +	gnttab_shared.v2[ref].hdr.flags =
> +				GTF_permit_access | GTF_sub_page |
> flags; }
> +
> +int gnttab_grant_foreign_access_subpage_ref(grant_ref_t ref,
> domid_t domid,
> +					    unsigned long frame, int
> flags,
> +					    unsigned page_off,
> +					    unsigned length)
> +{
> +	if (flags & (GTF_accept_transfer | GTF_reading |
> +		     GTF_writing | GTF_transitive))
> +		return -EPERM;
> +
> +	if (gnttab_interface->update_subpage_entry == NULL)
> +		return -ENOSYS;
> +
> +	gnttab_interface->update_subpage_entry(ref, domid, frame,
> flags,
> +					       page_off, length);
> +
> +	return 0;
> +}
> +EXPORT_SYMBOL_GPL(gnttab_grant_foreign_access_subpage_ref);
> +
> +int gnttab_grant_foreign_access_subpage(domid_t domid, unsigned
> long frame,
> +					int flags, unsigned page_off,
> +					unsigned length)
> +{
> +	int ref;
> +
> +	if (flags & (GTF_accept_transfer | GTF_reading |
> +		     GTF_writing | GTF_transitive))
> +		return -EPERM;
> +
> +	if (gnttab_interface->update_subpage_entry == NULL)
> +		return -ENOSYS;
> +
> +	ref = get_free_entries(1);
> +	if (unlikely(ref < 0))
> +		return -ENOSPC;
> +
> +	gnttab_interface->update_subpage_entry(ref, domid, frame,
> flags,
> +					       page_off, length);
> +
> +	return ref;
> +}
> +EXPORT_SYMBOL_GPL(gnttab_grant_foreign_access_subpage);

There's quite a lot of duplicated code here. What about something along the lines of:

#define get_free_entry()	get_free_entries(1)

int gnttab_grant_foreign_access_subpage(domid_t domid, unsigned long frame,
					int flags, unsigned page_off,
					unsigned length)
{
	int ref;

	ref = get_free_entry();
	if (unlikely(ref < 0))
		return -ENOSPC;

	rc = gnttab_grant_foreign_access_subpage_ref(ref, domid, frame, flags, page_off, length);
	if (rc < 0)
		put_free_entry(ref);

	return (rc < 0) rc : ref;
}
EXPORT_SYMBOL_GPL(gnttab_grant_foreign_access_subpage);

I think this is more akin to the format for existing non-ref variants.

> +
> +bool gnttab_subpage_grants_available(void)
> +{
> +	return gnttab_interface->update_subpage_entry != NULL; }
> +EXPORT_SYMBOL_GPL(gnttab_subpage_grants_available);
> +
>  static int gnttab_query_foreign_access_v1(grant_ref_t ref)  {
>  	return gnttab_shared.v1[ref].flags &
> (GTF_reading|GTF_writing); @@ -813,6 +886,7 @@ static struct
> gnttab_ops gnttab_v2_ops = {
>  	.end_foreign_access_ref		=
> gnttab_end_foreign_access_ref_v2,
>  	.end_foreign_transfer_ref	=
> gnttab_end_foreign_transfer_ref_v2,
>  	.query_foreign_access		=
> gnttab_query_foreign_access_v2,
> +	.update_subpage_entry		=
> gnttab_update_subpage_entry_v2,
>  };
> 
>  static void gnttab_request_version(void) diff --git
> a/include/xen/grant_table.h b/include/xen/grant_table.h index
> fea4954..2b492b9 100644
> --- a/include/xen/grant_table.h
> +++ b/include/xen/grant_table.h
> @@ -62,6 +62,15 @@ int gnttab_resume(void);
> 
>  int gnttab_grant_foreign_access(domid_t domid, unsigned long frame,
>  				int readonly);
> +int gnttab_grant_foreign_access_subpage(domid_t domid, unsigned
> long frame,
> +					int flags, unsigned page_off,
> +					unsigned length);
> +
> +/*
> + * Are sub-page grants available on this version of Xen?  Returns
> true
> +if they
> + * are, and false if they're not.
> + */
> +bool gnttab_subpage_grants_available(void);
> 
>  /*
>   * End access through the given grant reference, iff the grant
> entry is no @@ -108,6 +117,10 @@ void
> gnttab_cancel_free_callback(struct gnttab_free_callback *callback);
> 
>  void gnttab_grant_foreign_access_ref(grant_ref_t ref, domid_t
> domid,
>  				     unsigned long frame, int readonly);
> +int gnttab_grant_foreign_access_subpage_ref(grant_ref_t ref,
> domid_t domid,
> +					    unsigned long frame, int
> flags,
> +					    unsigned page_off,
> +					    unsigned length);
> 
>  void gnttab_grant_foreign_transfer_ref(grant_ref_t, domid_t domid,
>  				       unsigned long pfn);
> --
> 1.7.6.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 08 09:50:21 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 Dec 2011 09:50:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYacB-0001Dd-86; Thu, 08 Dec 2011 09:50:07 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RYac9-0001DS-QP
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 09:50:06 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1323337654!55330088!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDg5NQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14438 invoked from network); 8 Dec 2011 09:47:34 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Dec 2011 09:47:34 -0000
X-IronPort-AV: E=Sophos;i="4.71,319,1320624000"; 
   d="scan'208";a="9357866"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Dec 2011 09:49:22 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.161]) by
	LONPMAILMX01.citrite.net ([10.30.203.162]) with mapi; Thu, 8 Dec 2011
	09:49:22 +0000
From: Paul Durrant <Paul.Durrant@citrix.com>
To: "annie.li@oracle.com" <annie.li@oracle.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>, "jeremy@goop.org"
	<jeremy@goop.org>, Ian Campbell <Ian.Campbell@citrix.com>
Date: Thu, 8 Dec 2011 09:49:31 +0000
Thread-Topic: [PATCH V2 1/2] xen/granttable: Support sub-page grants
Thread-Index: Acy1jQLJQf54ufTdTwud/abmTvIfzgAAKUiQ
Message-ID: <291EDFCB1E9E224A99088639C4762022B5988E5528@LONPMAILBOX01.citrite.net>
References: <1323336940-5382-1-git-send-email-annie.li@oracle.com>
	<1323337048-5426-1-git-send-email-annie.li@oracle.com>
In-Reply-To: <1323337048-5426-1-git-send-email-annie.li@oracle.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "kurt.hackel@oracle.com" <kurt.hackel@oracle.com>
Subject: Re: [Xen-devel] [PATCH V2 1/2] xen/granttable: Support sub-page
	grants
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com



> -----Original Message-----
> From: annie.li@oracle.com [mailto:annie.li@oracle.com]
> Sent: 08 December 2011 09:37
> To: xen-devel@lists.xensource.com; linux-kernel@vger.kernel.org;
> konrad.wilk@oracle.com; jeremy@goop.org; Paul Durrant; Ian Campbell
> Cc: kurt.hackel@oracle.com; annie.li@oracle.com
> Subject: [PATCH V2 1/2] xen/granttable: Support sub-page grants
> 
>     -- They can't be used to map the page (so can only be used in a
> GNTTABOP_copy
>        hypercall).
>     -- It's possible to grant access with a finer granularity than
> whole pages.
>     -- Xen guarantees that they can be revoked quickly (a normal map
> grant can
>        only be revoked with the cooperation of the domain which has
> been granted
>        access).
> 
> Signed-off-by: Annie Li <annie.li@oracle.com>
> ---
>  drivers/xen/grant-table.c |   74
> +++++++++++++++++++++++++++++++++++++++++++++
>  include/xen/grant_table.h |   13 ++++++++
>  2 files changed, 87 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
> index bd325fd..4a10e3f 100644
> --- a/drivers/xen/grant-table.c
> +++ b/drivers/xen/grant-table.c
> @@ -120,6 +120,16 @@ struct gnttab_ops {
>  	 * by bit operations.
>  	 */
>  	int (*query_foreign_access)(grant_ref_t);
> +	/*
> +	 * Grant a domain to access a range of bytes within the page
> referred by
> +	 * an available grant entry. First parameter is grant entry
> reference
> +	 * number, second one is id of grantee domain, third one is
> frame
> +	 * address of subpage grant, forth one is grant type and flag
> +	 * information, fifth one is offset of the range of bytes,
> and last one
> +	 * is length of bytes to be accessed.
> +	 */
> +	void (*update_subpage_entry)(grant_ref_t, domid_t, unsigned
> long, int,
> +				     unsigned, unsigned);
>  };
> 
>  static struct gnttab_ops *gnttab_interface; @@ -261,6 +271,69 @@
> int gnttab_grant_foreign_access(domid_t domid, unsigned long frame,
> }  EXPORT_SYMBOL_GPL(gnttab_grant_foreign_access);
> 
> +void gnttab_update_subpage_entry_v2(grant_ref_t ref, domid_t domid,
> +				    unsigned long frame, int flags,
> +				    unsigned page_off,
> +				    unsigned length)
> +{
> +	gnttab_shared.v2[ref].sub_page.frame = frame;
> +	gnttab_shared.v2[ref].sub_page.page_off = page_off;
> +	gnttab_shared.v2[ref].sub_page.length = length;
> +	gnttab_shared.v2[ref].hdr.domid = domid;
> +	wmb();
> +	gnttab_shared.v2[ref].hdr.flags =
> +				GTF_permit_access | GTF_sub_page |
> flags; }
> +
> +int gnttab_grant_foreign_access_subpage_ref(grant_ref_t ref,
> domid_t domid,
> +					    unsigned long frame, int
> flags,
> +					    unsigned page_off,
> +					    unsigned length)
> +{
> +	if (flags & (GTF_accept_transfer | GTF_reading |
> +		     GTF_writing | GTF_transitive))
> +		return -EPERM;
> +
> +	if (gnttab_interface->update_subpage_entry == NULL)
> +		return -ENOSYS;
> +
> +	gnttab_interface->update_subpage_entry(ref, domid, frame,
> flags,
> +					       page_off, length);
> +
> +	return 0;
> +}
> +EXPORT_SYMBOL_GPL(gnttab_grant_foreign_access_subpage_ref);
> +
> +int gnttab_grant_foreign_access_subpage(domid_t domid, unsigned
> long frame,
> +					int flags, unsigned page_off,
> +					unsigned length)
> +{
> +	int ref;
> +
> +	if (flags & (GTF_accept_transfer | GTF_reading |
> +		     GTF_writing | GTF_transitive))
> +		return -EPERM;
> +
> +	if (gnttab_interface->update_subpage_entry == NULL)
> +		return -ENOSYS;
> +
> +	ref = get_free_entries(1);
> +	if (unlikely(ref < 0))
> +		return -ENOSPC;
> +
> +	gnttab_interface->update_subpage_entry(ref, domid, frame,
> flags,
> +					       page_off, length);
> +
> +	return ref;
> +}
> +EXPORT_SYMBOL_GPL(gnttab_grant_foreign_access_subpage);

There's quite a lot of duplicated code here. What about something along the lines of:

#define get_free_entry()	get_free_entries(1)

int gnttab_grant_foreign_access_subpage(domid_t domid, unsigned long frame,
					int flags, unsigned page_off,
					unsigned length)
{
	int ref;

	ref = get_free_entry();
	if (unlikely(ref < 0))
		return -ENOSPC;

	rc = gnttab_grant_foreign_access_subpage_ref(ref, domid, frame, flags, page_off, length);
	if (rc < 0)
		put_free_entry(ref);

	return (rc < 0) rc : ref;
}
EXPORT_SYMBOL_GPL(gnttab_grant_foreign_access_subpage);

I think this is more akin to the format for existing non-ref variants.

> +
> +bool gnttab_subpage_grants_available(void)
> +{
> +	return gnttab_interface->update_subpage_entry != NULL; }
> +EXPORT_SYMBOL_GPL(gnttab_subpage_grants_available);
> +
>  static int gnttab_query_foreign_access_v1(grant_ref_t ref)  {
>  	return gnttab_shared.v1[ref].flags &
> (GTF_reading|GTF_writing); @@ -813,6 +886,7 @@ static struct
> gnttab_ops gnttab_v2_ops = {
>  	.end_foreign_access_ref		=
> gnttab_end_foreign_access_ref_v2,
>  	.end_foreign_transfer_ref	=
> gnttab_end_foreign_transfer_ref_v2,
>  	.query_foreign_access		=
> gnttab_query_foreign_access_v2,
> +	.update_subpage_entry		=
> gnttab_update_subpage_entry_v2,
>  };
> 
>  static void gnttab_request_version(void) diff --git
> a/include/xen/grant_table.h b/include/xen/grant_table.h index
> fea4954..2b492b9 100644
> --- a/include/xen/grant_table.h
> +++ b/include/xen/grant_table.h
> @@ -62,6 +62,15 @@ int gnttab_resume(void);
> 
>  int gnttab_grant_foreign_access(domid_t domid, unsigned long frame,
>  				int readonly);
> +int gnttab_grant_foreign_access_subpage(domid_t domid, unsigned
> long frame,
> +					int flags, unsigned page_off,
> +					unsigned length);
> +
> +/*
> + * Are sub-page grants available on this version of Xen?  Returns
> true
> +if they
> + * are, and false if they're not.
> + */
> +bool gnttab_subpage_grants_available(void);
> 
>  /*
>   * End access through the given grant reference, iff the grant
> entry is no @@ -108,6 +117,10 @@ void
> gnttab_cancel_free_callback(struct gnttab_free_callback *callback);
> 
>  void gnttab_grant_foreign_access_ref(grant_ref_t ref, domid_t
> domid,
>  				     unsigned long frame, int readonly);
> +int gnttab_grant_foreign_access_subpage_ref(grant_ref_t ref,
> domid_t domid,
> +					    unsigned long frame, int
> flags,
> +					    unsigned page_off,
> +					    unsigned length);
> 
>  void gnttab_grant_foreign_transfer_ref(grant_ref_t, domid_t domid,
>  				       unsigned long pfn);
> --
> 1.7.6.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 08 09:52:19 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 Dec 2011 09:52:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYae7-0001NX-Qs; Thu, 08 Dec 2011 09:52:07 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RYae5-0001Mr-8N
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 09:52:05 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1323337877!6405582!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDg5NQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12251 invoked from network); 8 Dec 2011 09:51:17 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Dec 2011 09:51:17 -0000
X-IronPort-AV: E=Sophos;i="4.71,319,1320624000"; 
   d="scan'208";a="9357920"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Dec 2011 09:51:16 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.161]) by
	LONPMAILMX01.citrite.net ([10.30.203.162]) with mapi; Thu, 8 Dec 2011
	09:51:16 +0000
From: Paul Durrant <Paul.Durrant@citrix.com>
To: "annie.li@oracle.com" <annie.li@oracle.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>, "jeremy@goop.org"
	<jeremy@goop.org>, Ian Campbell <Ian.Campbell@citrix.com>
Date: Thu, 8 Dec 2011 09:51:25 +0000
Thread-Topic: [PATCH V2 2/2] xen/granttable: Support transitive grants
Thread-Index: Acy1jRQAKqiqmVv8RmuoLn/MJZ/b7wAAaspQ
Message-ID: <291EDFCB1E9E224A99088639C4762022B5988E5529@LONPMAILBOX01.citrite.net>
References: <1323336940-5382-1-git-send-email-annie.li@oracle.com>
	<1323337077-5457-1-git-send-email-annie.li@oracle.com>
In-Reply-To: <1323337077-5457-1-git-send-email-annie.li@oracle.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "kurt.hackel@oracle.com" <kurt.hackel@oracle.com>
Subject: Re: [Xen-devel] [PATCH V2 2/2] xen/granttable: Support transitive
	grants
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> -----Original Message-----
> From: annie.li@oracle.com [mailto:annie.li@oracle.com]
> Sent: 08 December 2011 09:38
> To: xen-devel@lists.xensource.com; linux-kernel@vger.kernel.org;
> konrad.wilk@oracle.com; jeremy@goop.org; Paul Durrant; Ian Campbell
> Cc: kurt.hackel@oracle.com; annie.li@oracle.com
> Subject: [PATCH V2 2/2] xen/granttable: Support transitive grants
> 
> These allow a domain A which has been granted access on a page of
> domain B's memory to issue domain C with a copy-grant on the same
> page.  This is useful e.g. for forwarding packets between domains.
> 
> Signed-off-by: Annie Li <annie.li@oracle.com>
> ---
>  drivers/xen/grant-table.c |   73
> +++++++++++++++++++++++++++++++++++++++++++++
>  include/xen/grant_table.h |   12 +++++++
>  2 files changed, 85 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
> index 4a10e3f..db3e7c0 100644
> --- a/drivers/xen/grant-table.c
> +++ b/drivers/xen/grant-table.c
> @@ -130,6 +130,18 @@ struct gnttab_ops {
>  	 */
>  	void (*update_subpage_entry)(grant_ref_t, domid_t, unsigned
> long, int,
>  				     unsigned, unsigned);
> +	/*
> +	 * Redirect an available grant entry on domain A to another
> grant
> +	 * reference of domain B, then allow domain C to use grant
> reference
> +	 * of domain B transitively. First parameter is an available
> grant entry
> +	 * reference on domain A, second one is id of domain C which
> accesses
> +	 * grant entry transitively, third one is grant type and flag
> +	 * information, forth one is id of domain B whose grant entry
> is finally
> +	 * accessed transitively, last one is grant entry transitive
> reference
> +	 * of domain B.
> +	 */
> +	void (*update_trans_entry)(grant_ref_t, domid_t, int,
> domid_t,
> +				   grant_ref_t);
>  };
> 
>  static struct gnttab_ops *gnttab_interface; @@ -334,6 +346,66 @@
> bool gnttab_subpage_grants_available(void)
>  }
>  EXPORT_SYMBOL_GPL(gnttab_subpage_grants_available);
> 
> +void gnttab_update_trans_entry_v2(grant_ref_t ref, domid_t domid,
> +				  int flags, domid_t trans_domid,
> +				  grant_ref_t trans_gref)
> +{
> +	gnttab_shared.v2[ref].transitive.trans_domid = trans_domid;
> +	gnttab_shared.v2[ref].transitive.gref = trans_gref;
> +	gnttab_shared.v2[ref].hdr.domid = domid;
> +	wmb();
> +	gnttab_shared.v2[ref].hdr.flags =
> +				GTF_permit_access | GTF_transitive |
> flags; }
> +
> +int gnttab_grant_foreign_access_trans_ref(grant_ref_t ref, domid_t
> domid,
> +					  int flags, domid_t trans_domid,
> +					  grant_ref_t trans_gref)
> +{
> +	if (flags & (GTF_accept_transfer | GTF_reading |
> +		     GTF_writing | GTF_sub_page))
> +		return -EPERM;
> +
> +	if (gnttab_interface->update_trans_entry == NULL)
> +		return -ENOSYS;
> +
> +	gnttab_interface->update_trans_entry(ref, domid, flags,
> trans_domid,
> +					     trans_gref);
> +
> +	return 0;
> +}
> +EXPORT_SYMBOL_GPL(gnttab_grant_foreign_access_trans_ref);
> +
> +int gnttab_grant_foreign_access_trans(domid_t domid, int flags,
> +				      domid_t trans_domid,
> +				      grant_ref_t trans_gref)
> +{
> +	int ref;
> +
> +	if (flags & (GTF_accept_transfer | GTF_reading |
> +		     GTF_writing | GTF_sub_page))
> +		return -EPERM;
> +
> +	if (gnttab_interface->update_trans_entry == NULL)
> +		return -ENOSYS;
> +
> +	ref = get_free_entries(1);
> +	if (unlikely(ref < 0))
> +		return -ENOSPC;
> +
> +	gnttab_interface->update_trans_entry(ref, domid, flags,
> trans_domid,
> +					     trans_gref);
> +
> +	return ref;
> +}
> +EXPORT_SYMBOL_GPL(gnttab_grant_foreign_access_trans);
> +

I have the same opinion here as with the other patch. The non-ref variant should allocate and then call the ref variant.

> +bool gnttab_trans_grants_available(void)
> +{
> +	return gnttab_interface->update_trans_entry != NULL; }
> +EXPORT_SYMBOL_GPL(gnttab_trans_grants_available);
> +
>  static int gnttab_query_foreign_access_v1(grant_ref_t ref)  {
>  	return gnttab_shared.v1[ref].flags &
> (GTF_reading|GTF_writing); @@ -887,6 +959,7 @@ static struct
> gnttab_ops gnttab_v2_ops = {
>  	.end_foreign_transfer_ref	=
> gnttab_end_foreign_transfer_ref_v2,
>  	.query_foreign_access		=
> gnttab_query_foreign_access_v2,
>  	.update_subpage_entry		=
> gnttab_update_subpage_entry_v2,
> +	.update_trans_entry		= gnttab_update_trans_entry_v2,
>  };
> 
>  static void gnttab_request_version(void) diff --git
> a/include/xen/grant_table.h b/include/xen/grant_table.h index
> 2b492b9..f1e17b7 100644
> --- a/include/xen/grant_table.h
> +++ b/include/xen/grant_table.h
> @@ -65,6 +65,9 @@ int gnttab_grant_foreign_access(domid_t domid,
> unsigned long frame,  int
> gnttab_grant_foreign_access_subpage(domid_t domid, unsigned long
> frame,
>  					int flags, unsigned page_off,
>  					unsigned length);
> +int gnttab_grant_foreign_access_trans(domid_t domid, int flags,
> +				      domid_t trans_domid,
> +				      grant_ref_t trans_gref);
> 
>  /*
>   * Are sub-page grants available on this version of Xen?  Returns
> true if they @@ -73,6 +76,12 @@ int
> gnttab_grant_foreign_access_subpage(domid_t domid, unsigned long
> frame,  bool gnttab_subpage_grants_available(void);
> 
>  /*
> + * Are transitive grants available on this version of Xen?  Returns
> +true if they
> + * are, and false if they're not.
> + */
> +bool gnttab_trans_grants_available(void);
> +
> +/*
>   * End access through the given grant reference, iff the grant
> entry is no
>   * longer in use.  Return 1 if the grant entry was freed, 0 if it
> is still in
>   * use.
> @@ -121,6 +130,9 @@ int
> gnttab_grant_foreign_access_subpage_ref(grant_ref_t ref, domid_t
> domid,
>  					    unsigned long frame, int
> flags,
>  					    unsigned page_off,
>  					    unsigned length);
> +int gnttab_grant_foreign_access_trans_ref(grant_ref_t ref, domid_t
> domid,
> +					  int flags, domid_t trans_domid,
> +					  grant_ref_t trans_gref);
> 
>  void gnttab_grant_foreign_transfer_ref(grant_ref_t, domid_t domid,
>  				       unsigned long pfn);
> --
> 1.7.6.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 08 09:52:19 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 Dec 2011 09:52:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYae7-0001NX-Qs; Thu, 08 Dec 2011 09:52:07 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RYae5-0001Mr-8N
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 09:52:05 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1323337877!6405582!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDg5NQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12251 invoked from network); 8 Dec 2011 09:51:17 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Dec 2011 09:51:17 -0000
X-IronPort-AV: E=Sophos;i="4.71,319,1320624000"; 
   d="scan'208";a="9357920"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Dec 2011 09:51:16 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.161]) by
	LONPMAILMX01.citrite.net ([10.30.203.162]) with mapi; Thu, 8 Dec 2011
	09:51:16 +0000
From: Paul Durrant <Paul.Durrant@citrix.com>
To: "annie.li@oracle.com" <annie.li@oracle.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>, "jeremy@goop.org"
	<jeremy@goop.org>, Ian Campbell <Ian.Campbell@citrix.com>
Date: Thu, 8 Dec 2011 09:51:25 +0000
Thread-Topic: [PATCH V2 2/2] xen/granttable: Support transitive grants
Thread-Index: Acy1jRQAKqiqmVv8RmuoLn/MJZ/b7wAAaspQ
Message-ID: <291EDFCB1E9E224A99088639C4762022B5988E5529@LONPMAILBOX01.citrite.net>
References: <1323336940-5382-1-git-send-email-annie.li@oracle.com>
	<1323337077-5457-1-git-send-email-annie.li@oracle.com>
In-Reply-To: <1323337077-5457-1-git-send-email-annie.li@oracle.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "kurt.hackel@oracle.com" <kurt.hackel@oracle.com>
Subject: Re: [Xen-devel] [PATCH V2 2/2] xen/granttable: Support transitive
	grants
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> -----Original Message-----
> From: annie.li@oracle.com [mailto:annie.li@oracle.com]
> Sent: 08 December 2011 09:38
> To: xen-devel@lists.xensource.com; linux-kernel@vger.kernel.org;
> konrad.wilk@oracle.com; jeremy@goop.org; Paul Durrant; Ian Campbell
> Cc: kurt.hackel@oracle.com; annie.li@oracle.com
> Subject: [PATCH V2 2/2] xen/granttable: Support transitive grants
> 
> These allow a domain A which has been granted access on a page of
> domain B's memory to issue domain C with a copy-grant on the same
> page.  This is useful e.g. for forwarding packets between domains.
> 
> Signed-off-by: Annie Li <annie.li@oracle.com>
> ---
>  drivers/xen/grant-table.c |   73
> +++++++++++++++++++++++++++++++++++++++++++++
>  include/xen/grant_table.h |   12 +++++++
>  2 files changed, 85 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
> index 4a10e3f..db3e7c0 100644
> --- a/drivers/xen/grant-table.c
> +++ b/drivers/xen/grant-table.c
> @@ -130,6 +130,18 @@ struct gnttab_ops {
>  	 */
>  	void (*update_subpage_entry)(grant_ref_t, domid_t, unsigned
> long, int,
>  				     unsigned, unsigned);
> +	/*
> +	 * Redirect an available grant entry on domain A to another
> grant
> +	 * reference of domain B, then allow domain C to use grant
> reference
> +	 * of domain B transitively. First parameter is an available
> grant entry
> +	 * reference on domain A, second one is id of domain C which
> accesses
> +	 * grant entry transitively, third one is grant type and flag
> +	 * information, forth one is id of domain B whose grant entry
> is finally
> +	 * accessed transitively, last one is grant entry transitive
> reference
> +	 * of domain B.
> +	 */
> +	void (*update_trans_entry)(grant_ref_t, domid_t, int,
> domid_t,
> +				   grant_ref_t);
>  };
> 
>  static struct gnttab_ops *gnttab_interface; @@ -334,6 +346,66 @@
> bool gnttab_subpage_grants_available(void)
>  }
>  EXPORT_SYMBOL_GPL(gnttab_subpage_grants_available);
> 
> +void gnttab_update_trans_entry_v2(grant_ref_t ref, domid_t domid,
> +				  int flags, domid_t trans_domid,
> +				  grant_ref_t trans_gref)
> +{
> +	gnttab_shared.v2[ref].transitive.trans_domid = trans_domid;
> +	gnttab_shared.v2[ref].transitive.gref = trans_gref;
> +	gnttab_shared.v2[ref].hdr.domid = domid;
> +	wmb();
> +	gnttab_shared.v2[ref].hdr.flags =
> +				GTF_permit_access | GTF_transitive |
> flags; }
> +
> +int gnttab_grant_foreign_access_trans_ref(grant_ref_t ref, domid_t
> domid,
> +					  int flags, domid_t trans_domid,
> +					  grant_ref_t trans_gref)
> +{
> +	if (flags & (GTF_accept_transfer | GTF_reading |
> +		     GTF_writing | GTF_sub_page))
> +		return -EPERM;
> +
> +	if (gnttab_interface->update_trans_entry == NULL)
> +		return -ENOSYS;
> +
> +	gnttab_interface->update_trans_entry(ref, domid, flags,
> trans_domid,
> +					     trans_gref);
> +
> +	return 0;
> +}
> +EXPORT_SYMBOL_GPL(gnttab_grant_foreign_access_trans_ref);
> +
> +int gnttab_grant_foreign_access_trans(domid_t domid, int flags,
> +				      domid_t trans_domid,
> +				      grant_ref_t trans_gref)
> +{
> +	int ref;
> +
> +	if (flags & (GTF_accept_transfer | GTF_reading |
> +		     GTF_writing | GTF_sub_page))
> +		return -EPERM;
> +
> +	if (gnttab_interface->update_trans_entry == NULL)
> +		return -ENOSYS;
> +
> +	ref = get_free_entries(1);
> +	if (unlikely(ref < 0))
> +		return -ENOSPC;
> +
> +	gnttab_interface->update_trans_entry(ref, domid, flags,
> trans_domid,
> +					     trans_gref);
> +
> +	return ref;
> +}
> +EXPORT_SYMBOL_GPL(gnttab_grant_foreign_access_trans);
> +

I have the same opinion here as with the other patch. The non-ref variant should allocate and then call the ref variant.

> +bool gnttab_trans_grants_available(void)
> +{
> +	return gnttab_interface->update_trans_entry != NULL; }
> +EXPORT_SYMBOL_GPL(gnttab_trans_grants_available);
> +
>  static int gnttab_query_foreign_access_v1(grant_ref_t ref)  {
>  	return gnttab_shared.v1[ref].flags &
> (GTF_reading|GTF_writing); @@ -887,6 +959,7 @@ static struct
> gnttab_ops gnttab_v2_ops = {
>  	.end_foreign_transfer_ref	=
> gnttab_end_foreign_transfer_ref_v2,
>  	.query_foreign_access		=
> gnttab_query_foreign_access_v2,
>  	.update_subpage_entry		=
> gnttab_update_subpage_entry_v2,
> +	.update_trans_entry		= gnttab_update_trans_entry_v2,
>  };
> 
>  static void gnttab_request_version(void) diff --git
> a/include/xen/grant_table.h b/include/xen/grant_table.h index
> 2b492b9..f1e17b7 100644
> --- a/include/xen/grant_table.h
> +++ b/include/xen/grant_table.h
> @@ -65,6 +65,9 @@ int gnttab_grant_foreign_access(domid_t domid,
> unsigned long frame,  int
> gnttab_grant_foreign_access_subpage(domid_t domid, unsigned long
> frame,
>  					int flags, unsigned page_off,
>  					unsigned length);
> +int gnttab_grant_foreign_access_trans(domid_t domid, int flags,
> +				      domid_t trans_domid,
> +				      grant_ref_t trans_gref);
> 
>  /*
>   * Are sub-page grants available on this version of Xen?  Returns
> true if they @@ -73,6 +76,12 @@ int
> gnttab_grant_foreign_access_subpage(domid_t domid, unsigned long
> frame,  bool gnttab_subpage_grants_available(void);
> 
>  /*
> + * Are transitive grants available on this version of Xen?  Returns
> +true if they
> + * are, and false if they're not.
> + */
> +bool gnttab_trans_grants_available(void);
> +
> +/*
>   * End access through the given grant reference, iff the grant
> entry is no
>   * longer in use.  Return 1 if the grant entry was freed, 0 if it
> is still in
>   * use.
> @@ -121,6 +130,9 @@ int
> gnttab_grant_foreign_access_subpage_ref(grant_ref_t ref, domid_t
> domid,
>  					    unsigned long frame, int
> flags,
>  					    unsigned page_off,
>  					    unsigned length);
> +int gnttab_grant_foreign_access_trans_ref(grant_ref_t ref, domid_t
> domid,
> +					  int flags, domid_t trans_domid,
> +					  grant_ref_t trans_gref);
> 
>  void gnttab_grant_foreign_transfer_ref(grant_ref_t, domid_t domid,
>  				       unsigned long pfn);
> --
> 1.7.6.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 08 10:03:12 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 Dec 2011 10:03:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYaoX-0001oP-7V; Thu, 08 Dec 2011 10:02:53 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <annie.li@oracle.com>) id 1RYaoW-0001oC-7m
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 10:02:52 +0000
X-Env-Sender: annie.li@oracle.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1323338483!48168988!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQyMjA1NA==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28792 invoked from network); 8 Dec 2011 10:01:24 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-3.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 8 Dec 2011 10:01:24 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pB8A214c015434
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 8 Dec 2011 10:02:02 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pB8A20Lv011432
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 8 Dec 2011 10:02:00 GMT
Received: from abhmt119.oracle.com (abhmt119.oracle.com [141.146.116.71])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pB8A1sZs023227; Thu, 8 Dec 2011 04:01:54 -0600
Received: from [10.182.39.81] (/10.182.39.81)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 08 Dec 2011 02:01:54 -0800
Message-ID: <4EE08B0D.80504@oracle.com>
Date: Thu, 08 Dec 2011 18:01:49 +0800
From: ANNIE LI <annie.li@oracle.com>
Organization: Oracle Corporation
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.9.2.23) Gecko/20110920 Thunderbird/3.1.15
MIME-Version: 1.0
To: Paul Durrant <Paul.Durrant@citrix.com>
References: <1323336940-5382-1-git-send-email-annie.li@oracle.com>
	<1323337048-5426-1-git-send-email-annie.li@oracle.com>
	<291EDFCB1E9E224A99088639C4762022B5988E5528@LONPMAILBOX01.citrite.net>
In-Reply-To: <291EDFCB1E9E224A99088639C4762022B5988E5528@LONPMAILBOX01.citrite.net>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090201.4EE08B1A.009E,ss=1,re=0.000,fgs=0
Cc: "jeremy@goop.org" <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	"kurt.hackel@oracle.com" <kurt.hackel@oracle.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [Xen-devel] [PATCH V2 1/2] xen/granttable: Support sub-page
	grants
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


>> +
>> +int gnttab_grant_foreign_access_subpage(domid_t domid, unsigned
>> long frame,
>> +					int flags, unsigned page_off,
>> +					unsigned length)
>> +{
>> +	int ref;
>> +
>> +	if (flags&  (GTF_accept_transfer | GTF_reading |
>> +		     GTF_writing | GTF_transitive))
>> +		return -EPERM;
>> +
>> +	if (gnttab_interface->update_subpage_entry == NULL)
>> +		return -ENOSYS;
>> +
>> +	ref = get_free_entries(1);
>> +	if (unlikely(ref<  0))
>> +		return -ENOSPC;
>> +
>> +	gnttab_interface->update_subpage_entry(ref, domid, frame,
>> flags,
>> +					       page_off, length);
>> +
>> +	return ref;
>> +}
>> +EXPORT_SYMBOL_GPL(gnttab_grant_foreign_access_subpage);
> There's quite a lot of duplicated code here. What about something along the lines of:
>
> #define get_free_entry()	get_free_entries(1)
>
> int gnttab_grant_foreign_access_subpage(domid_t domid, unsigned long frame,
> 					int flags, unsigned page_off,
> 					unsigned length)
> {
> 	int ref;
>
> 	ref = get_free_entry();
> 	if (unlikely(ref<  0))
> 		return -ENOSPC;
>
> 	rc = gnttab_grant_foreign_access_subpage_ref(ref, domid, frame, flags, page_off, length);
> 	if (rc<  0)
> 		put_free_entry(ref);
>
> 	return (rc<  0) rc : ref;
> }
> EXPORT_SYMBOL_GPL(gnttab_grant_foreign_access_subpage);
>
> I think this is more akin to the format for existing non-ref variants.
>
I hesitated between those two implement ways before sending them out. 
Those two ways all have shortcoming, one has duplicated code, but is 
simple when condition does not meet. The other way you pointed out added 
more put_free_entry process when _ref function fails.

Thanks
Annie

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 08 10:03:12 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 Dec 2011 10:03:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYaoX-0001oP-7V; Thu, 08 Dec 2011 10:02:53 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <annie.li@oracle.com>) id 1RYaoW-0001oC-7m
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 10:02:52 +0000
X-Env-Sender: annie.li@oracle.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1323338483!48168988!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQyMjA1NA==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28792 invoked from network); 8 Dec 2011 10:01:24 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-3.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 8 Dec 2011 10:01:24 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pB8A214c015434
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 8 Dec 2011 10:02:02 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pB8A20Lv011432
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 8 Dec 2011 10:02:00 GMT
Received: from abhmt119.oracle.com (abhmt119.oracle.com [141.146.116.71])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pB8A1sZs023227; Thu, 8 Dec 2011 04:01:54 -0600
Received: from [10.182.39.81] (/10.182.39.81)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 08 Dec 2011 02:01:54 -0800
Message-ID: <4EE08B0D.80504@oracle.com>
Date: Thu, 08 Dec 2011 18:01:49 +0800
From: ANNIE LI <annie.li@oracle.com>
Organization: Oracle Corporation
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.9.2.23) Gecko/20110920 Thunderbird/3.1.15
MIME-Version: 1.0
To: Paul Durrant <Paul.Durrant@citrix.com>
References: <1323336940-5382-1-git-send-email-annie.li@oracle.com>
	<1323337048-5426-1-git-send-email-annie.li@oracle.com>
	<291EDFCB1E9E224A99088639C4762022B5988E5528@LONPMAILBOX01.citrite.net>
In-Reply-To: <291EDFCB1E9E224A99088639C4762022B5988E5528@LONPMAILBOX01.citrite.net>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090201.4EE08B1A.009E,ss=1,re=0.000,fgs=0
Cc: "jeremy@goop.org" <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	"kurt.hackel@oracle.com" <kurt.hackel@oracle.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [Xen-devel] [PATCH V2 1/2] xen/granttable: Support sub-page
	grants
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


>> +
>> +int gnttab_grant_foreign_access_subpage(domid_t domid, unsigned
>> long frame,
>> +					int flags, unsigned page_off,
>> +					unsigned length)
>> +{
>> +	int ref;
>> +
>> +	if (flags&  (GTF_accept_transfer | GTF_reading |
>> +		     GTF_writing | GTF_transitive))
>> +		return -EPERM;
>> +
>> +	if (gnttab_interface->update_subpage_entry == NULL)
>> +		return -ENOSYS;
>> +
>> +	ref = get_free_entries(1);
>> +	if (unlikely(ref<  0))
>> +		return -ENOSPC;
>> +
>> +	gnttab_interface->update_subpage_entry(ref, domid, frame,
>> flags,
>> +					       page_off, length);
>> +
>> +	return ref;
>> +}
>> +EXPORT_SYMBOL_GPL(gnttab_grant_foreign_access_subpage);
> There's quite a lot of duplicated code here. What about something along the lines of:
>
> #define get_free_entry()	get_free_entries(1)
>
> int gnttab_grant_foreign_access_subpage(domid_t domid, unsigned long frame,
> 					int flags, unsigned page_off,
> 					unsigned length)
> {
> 	int ref;
>
> 	ref = get_free_entry();
> 	if (unlikely(ref<  0))
> 		return -ENOSPC;
>
> 	rc = gnttab_grant_foreign_access_subpage_ref(ref, domid, frame, flags, page_off, length);
> 	if (rc<  0)
> 		put_free_entry(ref);
>
> 	return (rc<  0) rc : ref;
> }
> EXPORT_SYMBOL_GPL(gnttab_grant_foreign_access_subpage);
>
> I think this is more akin to the format for existing non-ref variants.
>
I hesitated between those two implement ways before sending them out. 
Those two ways all have shortcoming, one has duplicated code, but is 
simple when condition does not meet. The other way you pointed out added 
more put_free_entry process when _ref function fails.

Thanks
Annie

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 08 10:05:52 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 Dec 2011 10: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.xensource.com>)
	id 1RYarC-0001xF-SL; Thu, 08 Dec 2011 10:05:38 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RYarB-0001wz-7p
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 10:05:37 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1323338689!6600433!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDg5NQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9319 invoked from network); 8 Dec 2011 10:04:49 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Dec 2011 10:04:49 -0000
X-IronPort-AV: E=Sophos;i="4.71,319,1320624000"; 
   d="scan'208";a="9358303"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Dec 2011 10:04:49 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.161]) by
	LONPMAILMX01.citrite.net ([10.30.203.162]) with mapi; Thu, 8 Dec 2011
	10:04:49 +0000
From: Paul Durrant <Paul.Durrant@citrix.com>
To: ANNIE LI <annie.li@oracle.com>
Date: Thu, 8 Dec 2011 10:04:57 +0000
Thread-Topic: [PATCH V2 1/2] xen/granttable: Support sub-page grants
Thread-Index: Acy1kHCd7Z+Z9eCOTU6spp2HTbgTwwAAD44Q
Message-ID: <291EDFCB1E9E224A99088639C4762022B5988E552D@LONPMAILBOX01.citrite.net>
References: <1323336940-5382-1-git-send-email-annie.li@oracle.com>
	<1323337048-5426-1-git-send-email-annie.li@oracle.com>
	<291EDFCB1E9E224A99088639C4762022B5988E5528@LONPMAILBOX01.citrite.net>
	<4EE08B0D.80504@oracle.com>
In-Reply-To: <4EE08B0D.80504@oracle.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "jeremy@goop.org" <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	"kurt.hackel@oracle.com" <kurt.hackel@oracle.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [Xen-devel] [PATCH V2 1/2] xen/granttable: Support sub-page
	grants
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> -----Original Message-----
> From: ANNIE LI [mailto:annie.li@oracle.com]
> Sent: 08 December 2011 10:02
> To: Paul Durrant
> Cc: xen-devel@lists.xensource.com; linux-kernel@vger.kernel.org;
> konrad.wilk@oracle.com; jeremy@goop.org; Ian Campbell;
> kurt.hackel@oracle.com
> Subject: Re: [PATCH V2 1/2] xen/granttable: Support sub-page grants
> 
> 
> >> +
> >> +int gnttab_grant_foreign_access_subpage(domid_t domid, unsigned
> >> long frame,
> >> +					int flags, unsigned page_off,
> >> +					unsigned length)
> >> +{
> >> +	int ref;
> >> +
> >> +	if (flags&  (GTF_accept_transfer | GTF_reading |
> >> +		     GTF_writing | GTF_transitive))
> >> +		return -EPERM;
> >> +
> >> +	if (gnttab_interface->update_subpage_entry == NULL)
> >> +		return -ENOSYS;
> >> +
> >> +	ref = get_free_entries(1);
> >> +	if (unlikely(ref<  0))
> >> +		return -ENOSPC;
> >> +
> >> +	gnttab_interface->update_subpage_entry(ref, domid, frame,
> >> flags,
> >> +					       page_off, length);
> >> +
> >> +	return ref;
> >> +}
> >> +EXPORT_SYMBOL_GPL(gnttab_grant_foreign_access_subpage);
> > There's quite a lot of duplicated code here. What about something
> along the lines of:
> >
> > #define get_free_entry()	get_free_entries(1)
> >
> > int gnttab_grant_foreign_access_subpage(domid_t domid, unsigned
> long frame,
> > 					int flags, unsigned page_off,
> > 					unsigned length)
> > {
> > 	int ref;
> >
> > 	ref = get_free_entry();
> > 	if (unlikely(ref<  0))
> > 		return -ENOSPC;
> >
> > 	rc = gnttab_grant_foreign_access_subpage_ref(ref, domid,
> frame, flags, page_off, length);
> > 	if (rc<  0)
> > 		put_free_entry(ref);
> >
> > 	return (rc<  0) rc : ref;
> > }
> > EXPORT_SYMBOL_GPL(gnttab_grant_foreign_access_subpage);
> >
> > I think this is more akin to the format for existing non-ref
> variants.
> >
> I hesitated between those two implement ways before sending them
> out.
> Those two ways all have shortcoming, one has duplicated code, but is
> simple when condition does not meet. The other way you pointed out
> added more put_free_entry process when _ref function fails.
> 

I say let's be optimistic :-) Yes, there's more overhead in the failure case, but that's not what we should be optimising for.

  Paul

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 08 10:05:52 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 Dec 2011 10: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.xensource.com>)
	id 1RYarC-0001xF-SL; Thu, 08 Dec 2011 10:05:38 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RYarB-0001wz-7p
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 10:05:37 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1323338689!6600433!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDg5NQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9319 invoked from network); 8 Dec 2011 10:04:49 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Dec 2011 10:04:49 -0000
X-IronPort-AV: E=Sophos;i="4.71,319,1320624000"; 
   d="scan'208";a="9358303"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Dec 2011 10:04:49 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.161]) by
	LONPMAILMX01.citrite.net ([10.30.203.162]) with mapi; Thu, 8 Dec 2011
	10:04:49 +0000
From: Paul Durrant <Paul.Durrant@citrix.com>
To: ANNIE LI <annie.li@oracle.com>
Date: Thu, 8 Dec 2011 10:04:57 +0000
Thread-Topic: [PATCH V2 1/2] xen/granttable: Support sub-page grants
Thread-Index: Acy1kHCd7Z+Z9eCOTU6spp2HTbgTwwAAD44Q
Message-ID: <291EDFCB1E9E224A99088639C4762022B5988E552D@LONPMAILBOX01.citrite.net>
References: <1323336940-5382-1-git-send-email-annie.li@oracle.com>
	<1323337048-5426-1-git-send-email-annie.li@oracle.com>
	<291EDFCB1E9E224A99088639C4762022B5988E5528@LONPMAILBOX01.citrite.net>
	<4EE08B0D.80504@oracle.com>
In-Reply-To: <4EE08B0D.80504@oracle.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "jeremy@goop.org" <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	"kurt.hackel@oracle.com" <kurt.hackel@oracle.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [Xen-devel] [PATCH V2 1/2] xen/granttable: Support sub-page
	grants
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> -----Original Message-----
> From: ANNIE LI [mailto:annie.li@oracle.com]
> Sent: 08 December 2011 10:02
> To: Paul Durrant
> Cc: xen-devel@lists.xensource.com; linux-kernel@vger.kernel.org;
> konrad.wilk@oracle.com; jeremy@goop.org; Ian Campbell;
> kurt.hackel@oracle.com
> Subject: Re: [PATCH V2 1/2] xen/granttable: Support sub-page grants
> 
> 
> >> +
> >> +int gnttab_grant_foreign_access_subpage(domid_t domid, unsigned
> >> long frame,
> >> +					int flags, unsigned page_off,
> >> +					unsigned length)
> >> +{
> >> +	int ref;
> >> +
> >> +	if (flags&  (GTF_accept_transfer | GTF_reading |
> >> +		     GTF_writing | GTF_transitive))
> >> +		return -EPERM;
> >> +
> >> +	if (gnttab_interface->update_subpage_entry == NULL)
> >> +		return -ENOSYS;
> >> +
> >> +	ref = get_free_entries(1);
> >> +	if (unlikely(ref<  0))
> >> +		return -ENOSPC;
> >> +
> >> +	gnttab_interface->update_subpage_entry(ref, domid, frame,
> >> flags,
> >> +					       page_off, length);
> >> +
> >> +	return ref;
> >> +}
> >> +EXPORT_SYMBOL_GPL(gnttab_grant_foreign_access_subpage);
> > There's quite a lot of duplicated code here. What about something
> along the lines of:
> >
> > #define get_free_entry()	get_free_entries(1)
> >
> > int gnttab_grant_foreign_access_subpage(domid_t domid, unsigned
> long frame,
> > 					int flags, unsigned page_off,
> > 					unsigned length)
> > {
> > 	int ref;
> >
> > 	ref = get_free_entry();
> > 	if (unlikely(ref<  0))
> > 		return -ENOSPC;
> >
> > 	rc = gnttab_grant_foreign_access_subpage_ref(ref, domid,
> frame, flags, page_off, length);
> > 	if (rc<  0)
> > 		put_free_entry(ref);
> >
> > 	return (rc<  0) rc : ref;
> > }
> > EXPORT_SYMBOL_GPL(gnttab_grant_foreign_access_subpage);
> >
> > I think this is more akin to the format for existing non-ref
> variants.
> >
> I hesitated between those two implement ways before sending them
> out.
> Those two ways all have shortcoming, one has duplicated code, but is
> simple when condition does not meet. The other way you pointed out
> added more put_free_entry process when _ref function fails.
> 

I say let's be optimistic :-) Yes, there's more overhead in the failure case, but that's not what we should be optimising for.

  Paul

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 08 11:09:58 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 Dec 2011 11: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.xensource.com>)
	id 1RYbqo-0002rt-JW; Thu, 08 Dec 2011 11:09:18 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <bastian@waldi.eu.org>) id 1RYbqn-0002ro-9D
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 11:09:17 +0000
X-Env-Sender: bastian@waldi.eu.org
X-Msg-Ref: server-9.tower-21.messagelabs.com!1323342508!1154780!1
X-Originating-IP: [82.139.201.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32517 invoked from network); 8 Dec 2011 11:08:29 -0000
Received: from wavehammer.waldi.eu.org (HELO wavehammer.waldi.eu.org)
	(82.139.201.20)
	by server-9.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 8 Dec 2011 11:08:29 -0000
Received: by wavehammer.waldi.eu.org (Postfix, from userid 1000)
	id 8F3CD5415B; Thu,  8 Dec 2011 12:08:27 +0100 (CET)
Date: Thu, 8 Dec 2011 12:08:27 +0100
From: Bastian Blank <bastian@waldi.eu.org>
To: Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
Message-ID: <20111208110827.GA32300@wavehammer.waldi.eu.org>
Mail-Followup-To: Bastian Blank <bastian@waldi.eu.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
References: <1323292396-19523-1-git-send-email-waldi@debian.org>
	<1323292396-19523-4-git-send-email-waldi@debian.org>
	<1323332686.2969.49.camel@zakaz.uk.xensource.com>
	<20111208092757.GA22678@wavehammer.waldi.eu.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20111208092757.GA22678@wavehammer.waldi.eu.org>
User-Agent: Mutt/1.5.20 (2009-06-14)
Subject: Re: [Xen-devel] [PATCH 3/4] xen: Add xenbusd device driver
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Dec 08, 2011 at 10:27:58AM +0100, Bastian Blank wrote:
> I even think about registering this device from xenstored_local_init in
> xenbus_probe.c. Then it will be available only if the kernel also owns
> the communcation ring.

I'm not sure if I'm allowed to register character devices from a
postcore_initcall. Isn't this function called a bit early anyway?

Bastian

-- 
Each kiss is as the first.
		-- Miramanee, Kirk's wife, "The Paradise Syndrome",
		   stardate 4842.6

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 08 11:09:58 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 Dec 2011 11: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.xensource.com>)
	id 1RYbqo-0002rt-JW; Thu, 08 Dec 2011 11:09:18 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <bastian@waldi.eu.org>) id 1RYbqn-0002ro-9D
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 11:09:17 +0000
X-Env-Sender: bastian@waldi.eu.org
X-Msg-Ref: server-9.tower-21.messagelabs.com!1323342508!1154780!1
X-Originating-IP: [82.139.201.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32517 invoked from network); 8 Dec 2011 11:08:29 -0000
Received: from wavehammer.waldi.eu.org (HELO wavehammer.waldi.eu.org)
	(82.139.201.20)
	by server-9.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 8 Dec 2011 11:08:29 -0000
Received: by wavehammer.waldi.eu.org (Postfix, from userid 1000)
	id 8F3CD5415B; Thu,  8 Dec 2011 12:08:27 +0100 (CET)
Date: Thu, 8 Dec 2011 12:08:27 +0100
From: Bastian Blank <bastian@waldi.eu.org>
To: Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
Message-ID: <20111208110827.GA32300@wavehammer.waldi.eu.org>
Mail-Followup-To: Bastian Blank <bastian@waldi.eu.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
References: <1323292396-19523-1-git-send-email-waldi@debian.org>
	<1323292396-19523-4-git-send-email-waldi@debian.org>
	<1323332686.2969.49.camel@zakaz.uk.xensource.com>
	<20111208092757.GA22678@wavehammer.waldi.eu.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20111208092757.GA22678@wavehammer.waldi.eu.org>
User-Agent: Mutt/1.5.20 (2009-06-14)
Subject: Re: [Xen-devel] [PATCH 3/4] xen: Add xenbusd device driver
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Dec 08, 2011 at 10:27:58AM +0100, Bastian Blank wrote:
> I even think about registering this device from xenstored_local_init in
> xenbus_probe.c. Then it will be available only if the kernel also owns
> the communcation ring.

I'm not sure if I'm allowed to register character devices from a
postcore_initcall. Isn't this function called a bit early anyway?

Bastian

-- 
Each kiss is as the first.
		-- Miramanee, Kirk's wife, "The Paradise Syndrome",
		   stardate 4842.6

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 08 11:10:48 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 Dec 2011 11:10:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYbrk-0002ty-2A; Thu, 08 Dec 2011 11:10:16 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1RYbrh-0002tb-ML
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 11:10:13 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1323342563!4748683!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDQzMDM=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29215 invoked from network); 8 Dec 2011 11:09:25 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Dec 2011 11:09:25 -0000
X-IronPort-AV: E=Sophos;i="4.71,319,1320642000"; d="scan'208";a="19774090"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Dec 2011 06:09:22 -0500
Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX01.citrite.net
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Thu, 8 Dec 2011
	06:09:22 -0500
Message-ID: <4EE09AE1.3080703@citrix.com>
Date: Thu, 8 Dec 2011 11:09:21 +0000
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20111110 Icedove/3.0.11
MIME-Version: 1.0
To: Bastian Blank <waldi@debian.org>
References: <1323292396-19523-1-git-send-email-waldi@debian.org>
In-Reply-To: <1323292396-19523-1-git-send-email-waldi@debian.org>
Cc: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org,
	konrad.wilk@oracle.com
Subject: Re: [Xen-devel] [PATCH 0/4] V2, Move stuff out of xenfs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 07/12/2011 21:13, Bastian Blank wrote:
> In<20100605162947.GA31336@wavehammer.waldi.eu.org>  I started the
> discussion about xenfs and the usage of it. This is the second try to
> move stuff over into normal device drivers.

You still don't say why this is needed in the commit messages.  I can't
find the message you refer to in the previous thread (the mail archives
don't let you search by message-id).

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 08 11:10:48 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 Dec 2011 11:10:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYbrk-0002ty-2A; Thu, 08 Dec 2011 11:10:16 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1RYbrh-0002tb-ML
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 11:10:13 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1323342563!4748683!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDQzMDM=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29215 invoked from network); 8 Dec 2011 11:09:25 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Dec 2011 11:09:25 -0000
X-IronPort-AV: E=Sophos;i="4.71,319,1320642000"; d="scan'208";a="19774090"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Dec 2011 06:09:22 -0500
Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX01.citrite.net
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Thu, 8 Dec 2011
	06:09:22 -0500
Message-ID: <4EE09AE1.3080703@citrix.com>
Date: Thu, 8 Dec 2011 11:09:21 +0000
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20111110 Icedove/3.0.11
MIME-Version: 1.0
To: Bastian Blank <waldi@debian.org>
References: <1323292396-19523-1-git-send-email-waldi@debian.org>
In-Reply-To: <1323292396-19523-1-git-send-email-waldi@debian.org>
Cc: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org,
	konrad.wilk@oracle.com
Subject: Re: [Xen-devel] [PATCH 0/4] V2, Move stuff out of xenfs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 07/12/2011 21:13, Bastian Blank wrote:
> In<20100605162947.GA31336@wavehammer.waldi.eu.org>  I started the
> discussion about xenfs and the usage of it. This is the second try to
> move stuff over into normal device drivers.

You still don't say why this is needed in the commit messages.  I can't
find the message you refer to in the previous thread (the mail archives
don't let you search by message-id).

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 08 11:12:18 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 Dec 2011 11:12:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYbtH-000309-J9; Thu, 08 Dec 2011 11:11:51 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1RYbtG-0002zn-35
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 11:11:50 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1323342660!4749010!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDQzMDM=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4383 invoked from network); 8 Dec 2011 11:11:01 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Dec 2011 11:11:01 -0000
X-IronPort-AV: E=Sophos;i="4.71,319,1320642000"; d="scan'208";a="19774159"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Dec 2011 06:11:00 -0500
Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX01.citrite.net
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Thu, 8 Dec 2011
	06:10:59 -0500
Message-ID: <4EE09B42.4090801@citrix.com>
Date: Thu, 8 Dec 2011 11:10:58 +0000
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20111110 Icedove/3.0.11
MIME-Version: 1.0
To: Bastian Blank <waldi@debian.org>, Ian Campbell <Ian.Campbell@citrix.com>, 
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
References: <1323292396-19523-1-git-send-email-waldi@debian.org>	<1323333259.2969.56.camel@zakaz.uk.xensource.com>
	<20111208092855.GB22678@wavehammer.waldi.eu.org>
In-Reply-To: <20111208092855.GB22678@wavehammer.waldi.eu.org>
Subject: Re: [Xen-devel] [PATCH 0/4] V2, Move stuff out of xenfs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 08/12/11 09:28, Bastian Blank wrote:
> On Thu, Dec 08, 2011 at 08:34:19AM +0000, Ian Campbell wrote:
>> How are we doing on the corresponding toolstack changes?
> 
> I have at least parts of it somewhere on my workstation. I'll polish and
> submit them also.

I assume the toolstack will fall back to xenfs if the devices don't exist?

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 08 11:12:18 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 Dec 2011 11:12:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYbtH-000309-J9; Thu, 08 Dec 2011 11:11:51 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1RYbtG-0002zn-35
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 11:11:50 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1323342660!4749010!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDQzMDM=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4383 invoked from network); 8 Dec 2011 11:11:01 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Dec 2011 11:11:01 -0000
X-IronPort-AV: E=Sophos;i="4.71,319,1320642000"; d="scan'208";a="19774159"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Dec 2011 06:11:00 -0500
Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX01.citrite.net
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Thu, 8 Dec 2011
	06:10:59 -0500
Message-ID: <4EE09B42.4090801@citrix.com>
Date: Thu, 8 Dec 2011 11:10:58 +0000
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20111110 Icedove/3.0.11
MIME-Version: 1.0
To: Bastian Blank <waldi@debian.org>, Ian Campbell <Ian.Campbell@citrix.com>, 
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
References: <1323292396-19523-1-git-send-email-waldi@debian.org>	<1323333259.2969.56.camel@zakaz.uk.xensource.com>
	<20111208092855.GB22678@wavehammer.waldi.eu.org>
In-Reply-To: <20111208092855.GB22678@wavehammer.waldi.eu.org>
Subject: Re: [Xen-devel] [PATCH 0/4] V2, Move stuff out of xenfs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 08/12/11 09:28, Bastian Blank wrote:
> On Thu, Dec 08, 2011 at 08:34:19AM +0000, Ian Campbell wrote:
>> How are we doing on the corresponding toolstack changes?
> 
> I have at least parts of it somewhere on my workstation. I'll polish and
> submit them also.

I assume the toolstack will fall back to xenfs if the devices don't exist?

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 08 11:12:38 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 Dec 2011 11:12:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYbtf-00033C-0V; Thu, 08 Dec 2011 11:12:15 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RYbtd-00032U-I8
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 11:12:13 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-16.tower-174.messagelabs.com!1323342684!4565214!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22603 invoked from network); 8 Dec 2011 11:11:25 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-16.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 8 Dec 2011 11:11:25 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RYbsl-000LV1-Kp; Thu, 08 Dec 2011 11:11:19 +0000
Date: Thu, 8 Dec 2011 11:11:18 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20111208111118.GA82565@ocelot.phlegethon.org>
References: <patchbomb.1323330435@xdev.gridcentric.ca>
	<aeebbff899ffa2328e3f.1323330436@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <aeebbff899ffa2328e3f.1323330436@xdev.gridcentric.ca>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com, ian.campbell@citrix.com,
	andres@gridcentric.ca, keir.xen@gmail.com, JBeulich@suse.com,
	ian.jackson@citrix.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 01 of 18] x86/mm: Code style fixes in
	mem_sharing.c
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 02:47 -0500 on 08 Dec (1323312436), Andres Lagar-Cavilla wrote:
> Harmless patch, with no functional changes, only code style issues.
> 
> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

...

> -    return -2;
> +    return 0;

Ahem. :)

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 08 11:12:38 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 Dec 2011 11:12:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYbtf-00033C-0V; Thu, 08 Dec 2011 11:12:15 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RYbtd-00032U-I8
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 11:12:13 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-16.tower-174.messagelabs.com!1323342684!4565214!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22603 invoked from network); 8 Dec 2011 11:11:25 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-16.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 8 Dec 2011 11:11:25 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RYbsl-000LV1-Kp; Thu, 08 Dec 2011 11:11:19 +0000
Date: Thu, 8 Dec 2011 11:11:18 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20111208111118.GA82565@ocelot.phlegethon.org>
References: <patchbomb.1323330435@xdev.gridcentric.ca>
	<aeebbff899ffa2328e3f.1323330436@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <aeebbff899ffa2328e3f.1323330436@xdev.gridcentric.ca>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com, ian.campbell@citrix.com,
	andres@gridcentric.ca, keir.xen@gmail.com, JBeulich@suse.com,
	ian.jackson@citrix.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 01 of 18] x86/mm: Code style fixes in
	mem_sharing.c
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 02:47 -0500 on 08 Dec (1323312436), Andres Lagar-Cavilla wrote:
> Harmless patch, with no functional changes, only code style issues.
> 
> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

...

> -    return -2;
> +    return 0;

Ahem. :)

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 08 11:18:10 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 Dec 2011 11:18:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYbz3-0003Sd-Qb; Thu, 08 Dec 2011 11:17:49 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RYbz2-0003SF-1x
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 11:17:48 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-12.tower-182.messagelabs.com!1323343018!6407470!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13563 invoked from network); 8 Dec 2011 11:16:59 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-12.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 8 Dec 2011 11:16:59 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RYbyB-000LWr-Ql; Thu, 08 Dec 2011 11:16:56 +0000
Date: Thu, 8 Dec 2011 11:16:54 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20111208111654.GB82565@ocelot.phlegethon.org>
References: <patchbomb.1323330435@xdev.gridcentric.ca>
	<61da3fc46f0681c0d1be.1323330437@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <61da3fc46f0681c0d1be.1323330437@xdev.gridcentric.ca>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com, ian.campbell@citrix.com,
	andres@gridcentric.ca, keir.xen@gmail.com, JBeulich@suse.com,
	ian.jackson@citrix.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 02 of 18] x86/mm: Making a page sharable
	sets PGT_validated, but making a page private doesn't expect it
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 02:47 -0500 on 08 Dec (1323312437), Andres Lagar-Cavilla wrote:
> diff -r aeebbff899ff -r 61da3fc46f06 xen/arch/x86/mm.c
> --- a/xen/arch/x86/mm.c
> +++ b/xen/arch/x86/mm.c
> @@ -4347,7 +4347,7 @@ int page_make_private(struct domain *d, 
>  
>      /* We can only change the type if count is one */
>      if ( (page->u.inuse.type_info & (PGT_type_mask | PGT_count_mask))
> -         != (PGT_shared_page | 1) )
> +         != (PGT_shared_page | PGT_validated | 1) )

This seems wrong - surely PGT_validated isn't in (PGT_type_mask |
PGT_count_mask).

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 08 11:18:10 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 Dec 2011 11:18:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYbz3-0003Sd-Qb; Thu, 08 Dec 2011 11:17:49 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RYbz2-0003SF-1x
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 11:17:48 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-12.tower-182.messagelabs.com!1323343018!6407470!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13563 invoked from network); 8 Dec 2011 11:16:59 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-12.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 8 Dec 2011 11:16:59 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RYbyB-000LWr-Ql; Thu, 08 Dec 2011 11:16:56 +0000
Date: Thu, 8 Dec 2011 11:16:54 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20111208111654.GB82565@ocelot.phlegethon.org>
References: <patchbomb.1323330435@xdev.gridcentric.ca>
	<61da3fc46f0681c0d1be.1323330437@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <61da3fc46f0681c0d1be.1323330437@xdev.gridcentric.ca>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com, ian.campbell@citrix.com,
	andres@gridcentric.ca, keir.xen@gmail.com, JBeulich@suse.com,
	ian.jackson@citrix.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 02 of 18] x86/mm: Making a page sharable
	sets PGT_validated, but making a page private doesn't expect it
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 02:47 -0500 on 08 Dec (1323312437), Andres Lagar-Cavilla wrote:
> diff -r aeebbff899ff -r 61da3fc46f06 xen/arch/x86/mm.c
> --- a/xen/arch/x86/mm.c
> +++ b/xen/arch/x86/mm.c
> @@ -4347,7 +4347,7 @@ int page_make_private(struct domain *d, 
>  
>      /* We can only change the type if count is one */
>      if ( (page->u.inuse.type_info & (PGT_type_mask | PGT_count_mask))
> -         != (PGT_shared_page | 1) )
> +         != (PGT_shared_page | PGT_validated | 1) )

This seems wrong - surely PGT_validated isn't in (PGT_type_mask |
PGT_count_mask).

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 08 11:54:56 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 Dec 2011 11: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.xensource.com>)
	id 1RYcYR-0003lj-Ro; Thu, 08 Dec 2011 11:54:23 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RYcYP-0003le-SV
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 11:54:22 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1323345180!55880091!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDg5NQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3366 invoked from network); 8 Dec 2011 11:53:00 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Dec 2011 11:53:00 -0000
X-IronPort-AV: E=Sophos;i="4.71,319,1320624000"; 
   d="scan'208";a="9361239"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Dec 2011 11:53:04 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 8 Dec 2011
	11:53:04 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Thu, 8 Dec 2011 11:53:03 +0000
In-Reply-To: <1323108621-22654-16-git-send-email-ian.jackson@eu.citrix.com>
References: <1323108621-22654-1-git-send-email-ian.jackson@eu.citrix.com>
	<1323108621-22654-16-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323345183.2969.125.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 15/15] libxl: New event generation API
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2011-12-05 at 18:10 +0000, Ian Jackson wrote:
> Replace the existing API for retrieving high-level events (events
> about domains, etc.) from libxl with a new one.
> 
> This changes the definition and semantics of the `libxl_event'
> structure, and replaces the calls for obtaining information about
> domain death and disk eject events.
> 
> This is an incompatible change, sorry.  The alternative was to try to
> provide both the previous horrid API and the new one, and would also
> involve never using the name `libxl_event' for the new interface.
> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
> ---
>  tools/libxl/libxl.c          |  302 ++++++++++++++++++++++++++++++------------
>  tools/libxl/libxl.h          |   55 ++-------
>  tools/libxl/libxl_event.c    |  188 ++++++++++++++++++++++++---
>  tools/libxl/libxl_event.h    |  180 ++++++++++++++++++++++++-
>  tools/libxl/libxl_internal.c |    6 +
>  tools/libxl/libxl_internal.h |   81 +++++++++++-
>  tools/libxl/libxl_types.idl  |   35 ++++-
>  tools/libxl/xl_cmdimpl.c     |  270 ++++++++++++++++++++++----------------
>  8 files changed, 839 insertions(+), 278 deletions(-)
> 
> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> index 58f280c..ba9293b 100644
> --- a/tools/libxl/libxl.c
> +++ b/tools/libxl/libxl.c
> @@ -614,117 +631,173 @@ int libxl_domain_shutdown(libxl_ctx *ctx, uint32_t domid, int req)
>      return 0;
>  }
> 
> -int libxl_get_wait_fd(libxl_ctx *ctx, int *fd)
> -{
> -    *fd = xs_fileno(ctx->xsh);
> -    return 0;
> -}
> +static void domain_death_xswatch_callback(libxl__gc *gc, libxl__ev_xswatch *w,
> +                                        const char *wpath, const char *epath) {
> +    libxl_evgen_domain_death *evg;
> +    uint32_t domid;
> +    int rc;

Ugh, diff has made some very unhelpful choices about how to display this
change. Oh well. I've snipped all the - bits to try and make it easier
to follow.

[...]
> +    CTX_LOCK;
[...]
> +    uint32_t domid = libxl_get_stubdom_id(ctx, guest_domid);
> +    evg = LIBXL_TAILQ_FIRST(&CTX->death_list);
> +    if (!evg) goto out;
> 
> +    domid = evg->domid;
> 
[...]
> +    for (;;) {
> +        int nentries = LIBXL_TAILQ_NEXT(evg, entry) ? 200 : 1;
> +        xc_domaininfo_t domaininfos[nentries];
> +        const xc_domaininfo_t *got = domaininfos, *gotend;
> +
> +        rc = xc_domain_getinfolist(CTX->xch, domid, nentries, domaininfos);
> +        if (rc == -1) {
> +            LIBXL__EVENT_DISASTER(gc, "xc_domain_getinfolist failed while"
> +                                  " processing @releaseDomain watch event",
> +                                  errno, 0);
>              goto out;
[...]
> +        }
> +        gotend = &domaininfos[rc];
> +
> +        for (;;) {
> +            if (!evg)
> +                goto all_reported;
> +
> +            if (!rc || got->domain > evg->domid) {
> +                /* ie, the list doesn't contain evg->domid any more so
> +                 * the domain has been destroyed */
> +                libxl_evgen_domain_death *evg_next;
> +
> +                libxl_event *ev = NEW_EVENT(gc, DOMAIN_DESTROY, evg->domid);
> +                if (!ev) goto out;
> +
> +                libxl__event_occurred(gc, ev);
> +
> +                evg->death_reported = 1;
> +                evg_next = LIBXL_TAILQ_NEXT(evg, entry);
> +                LIBXL_TAILQ_REMOVE(&CTX->death_list, evg, entry);
> +                LIBXL_TAILQ_INSERT_HEAD(&CTX->death_reported, evg, entry);
> +                evg = evg_next;
> +
> +                continue;
> +            }
> +
> +            if (got == gotend)
> +                break;
> +
> +            if (got->domain < evg->domid) {
> +                got++;
> +                continue;
> +            }
> +
> +            assert(evg->domid == got->domain);
> +
> +            if (!evg->shutdown_reported &&
> +                (got->flags & XEN_DOMINF_shutdown)) {
> +                libxl_event *ev = NEW_EVENT(gc, DOMAIN_SHUTDOWN, got->domain);
> +                if (!ev) goto out;
> +
> +                ev->u.domain_shutdown.shutdown_reason =
> +                    (got->flags >> XEN_DOMINF_shutdownshift) &
> +                    XEN_DOMINF_shutdownmask;
> +                libxl__event_occurred(gc, ev);
> +
> +                evg->shutdown_reported = 1;
> +            }
> +            evg = LIBXL_TAILQ_NEXT(evg, entry);
> +        }
> +
> +        assert(rc); /* rc==0 results in us eating all evgs and quitting */
> +        domid = gotend[-1].domain;
>      }
[...]
> + all_reported:
> + out:
> +
> +    CTX_UNLOCK;
>  }
> 
[...]
> +int libxl_evenable_domain_death(libxl_ctx *ctx, uint32_t domid,
> +                libxl_ev_user user, libxl_evgen_domain_death **evgen_out) {
> +    GC_INIT(ctx);
> +    libxl_evgen_domain_death *evg, *evg_search;
> +    int rc;
> +
> +    CTX_LOCK;
> +
> +    evg = malloc(sizeof(*evg));  if (!evg) { rc = ERROR_NOMEM; goto out; }

CODING_STYLE?

> +    memset(evg, 0, sizeof(*evg));
> +    evg->domid = domid;
> +    evg->user = user;
> +
> +    LIBXL_TAILQ_INSERT_SORTED(&ctx->death_list, entry, evg, evg_search, ,
> +                              evg->domid > evg_search->domid);
> +
> +    if (!libxl__ev_xswatch_isregistered(&ctx->death_watch)) {
> +        rc = libxl__ev_xswatch_register(gc, &ctx->death_watch,
> +                        domain_death_xswatch_callback, "@releaseDomain");
> +        if (rc) { libxl__evdisable_domain_death(gc, evg); goto out; }
>      }
[...]
> +    rc = 0;
> 
[...]
> + out:
> +    CTX_UNLOCK;
> +    return rc;
> +};
> 
[...]
> +void libxl__evdisable_domain_death(libxl__gc *gc,
> +                                   libxl_evgen_domain_death *evg) {
> +    CTX_LOCK;
> 
[...]
> +    if (!evg->death_reported)
> +        LIBXL_TAILQ_REMOVE(&CTX->death_list, evg, entry);
> +    else
> +        LIBXL_TAILQ_REMOVE(&CTX->death_reported, evg, entry);
> 
[...]
> +    free(evg);
> +
> +    if (!LIBXL_TAILQ_FIRST(&CTX->death_list) &&
> +        libxl__ev_xswatch_isregistered(&CTX->death_watch))
> +        libxl__ev_xswatch_deregister(gc, &CTX->death_watch);
> 
[...]
> +    CTX_UNLOCK;
>  }
> 
[...]
> +void libxl_evdisable_domain_death(libxl_ctx *ctx,
> +                                  libxl_evgen_domain_death *evg) {
>      GC_INIT(ctx);
[...]
> +    libxl__evdisable_domain_death(gc, evg);
> +    GC_FREE;
> +}
> +
> +static void disk_eject_xswatch_callback(libxl__gc *gc, libxl__ev_xswatch *watch,
> +                                        const char *wpath, const char *epath) {
> +    libxl_evgen_disk_eject *evg = (void*)watch;
>      char *backend;
>      char *value;
>      char backend_type[BACKEND_STRING_SIZE+1];
> 
[...]
> +    value = libxl__xs_read(gc, XBT_NULL, wpath);
> 
[...]
> +    if (!value || strcmp(value,  "eject"))
> +        return;
> +
> +    if (libxl__xs_write(gc, XBT_NULL, wpath, "")) {
> +        LIBXL__EVENT_DISASTER(gc, "xs_write failed acknowledging eject",
> +                              errno, LIBXL_EVENT_TYPE_DISK_EJECT);
> +        return;
>      }
> 
> -    path = strdup(event->path);
[...]
> +    libxl_event *ev = NEW_EVENT(gc, DISK_EJECT, evg->domid);
> +    libxl_device_disk *disk = &ev->u.disk_eject.disk;
> +
> +    backend = libxl__xs_read(gc, XBT_NULL,
> +                             libxl__sprintf(gc, "%.*s/backend",
> +                                            (int)strlen(wpath)-6, wpath));

This pattern crops up a lot in libxl. I keep wondering if libxl__xs_read
shouldn't take a fmt string and varargs. Not sure how you would do that
in a way which allowed libxl__xs_write to have an orthogonal (and still
sane) interface though.

> 
>      sscanf(backend,
[...]
> +            "/local/domain/%d/backend/%" TOSTRING(BACKEND_STRING_SIZE)
> +           "[a-z]/%*d/%*d",
> +           &disk->backend_domid, backend_type);
>      if (!strcmp(backend_type, "tap") || !strcmp(backend_type, "vbd")) {
>          disk->backend = LIBXL_DISK_BACKEND_TAP;
>      } else if (!strcmp(backend_type, "qdisk")) {
> @@ -733,19 +806,72 @@ int libxl_event_get_disk_eject_info(libxl_ctx *ctx, uint32_t domid, libxl_event
>          disk->backend = LIBXL_DISK_BACKEND_UNKNOWN;
>      }
> 
[...]
> +    disk->pdev_path = strdup(""); /* xxx fixme malloc failure */
>      disk->format = LIBXL_DISK_FORMAT_EMPTY;
>      /* this value is returned to the user: do not free right away */
[...]
> +    disk->vdev = xs_read(CTX->xsh, XBT_NULL,
> +                         libxl__sprintf(gc, "%s/dev", backend), NULL);
>      disk->removable = 1;
>      disk->readwrite = 0;
>      disk->is_cdrom = 1;
> 
[...]
> +    libxl__event_occurred(gc, ev);
> +}
> +
[...]
> diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
> index 654a5b0..17b15a6 100644
> --- a/tools/libxl/libxl.h
> +++ b/tools/libxl/libxl.h
> @@ -53,7 +53,10 @@
>   *    A public function may be called from within libxl; the call
>   *    context initialisation macros will make sure that the internal
>   *    caller's context is reused (eg, so that the same xenstore
> - *    transaction is used).
> + *    transaction is used).  But in-libxl callers of libxl public
> + *    functions should note that any libxl public function may cause
> + *    recursively reentry into libxl via the application's event
> + *    callback hook.
>   *
>   *    Public functions have names like libxl_foobar.
>   *
> @@ -152,6 +155,8 @@ void libxl_key_value_list_dispose(libxl_key_value_list *kvl);
> 
>  typedef uint32_t libxl_hwcap[8];
> 
> +typedef uint64_t libxl_ev_user;
> +
>  typedef struct {
>      uint32_t size;          /* number of bytes in map */
>      uint8_t *map;
> @@ -200,6 +205,9 @@ typedef struct {
>      int v;
>  } libxl_enum_string_table;
> 
> +struct libxl_event;
> +typedef LIBXL_TAILQ_ENTRY(struct libxl_event) libxl_ev_link;

I think I made a comment on an earlier patch about why the list stuff
was exposed to the user. I guess I now have my answer.

[...]
> diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
> index 8d4dbf6..ec5c25e 100644
> --- a/tools/libxl/libxl_event.c
> +++ b/tools/libxl/libxl_event.c
[...]
> @@ -703,6 +713,152 @@ void libxl__event_disaster(libxl__gc *gc, const char *msg, int errnoval,
>  }
> 
>  /*
> + * Event retrieval etc.
> + */
> +
> +void libxl_event_register_callbacks(libxl_ctx *ctx,
> +                  const libxl_event_hooks *hooks, void *user) {
> +    ctx->event_hooks = hooks;
> +    ctx->event_hooks_user = user;

Does this either need locking or a check that there are no events in
flight? Or is it invalid to change hooks once they are registered?

> +}
> +
> +void libxl__event_occurred(libxl__gc *gc, libxl_event *event) {
> +    if (CTX->event_hooks &&
> +        (CTX->event_hooks->event_occurs_mask & (1UL << event->type))) {
> +        /* libxl__free_all will call the callback, just before exit
> +         * from libxl.  This helps avoid reentrancy bugs: parts of
> +         * libxl that call libxl__event_occurred do not have to worry
> +         * that libxl might be reentered at that point. */
> +        LIBXL_TAILQ_INSERT_TAIL(&gc->occurred_for_callback, event, link);
> +        return;

This return seem surplus to requirements.

> +    } else {
> +        LIBXL_TAILQ_INSERT_TAIL(&CTX->occurred, event, link);
> +    }
> +}
> +
> +void libxl_event_free(libxl_ctx *ctx, libxl_event *event) {
> +    libxl_event_dispose(event);
> +    free(event);
> +}
> +
> +libxl_event *libxl__event_new(libxl__gc *gc,
> +                              libxl_event_type type, uint32_t domid) {
> +    libxl_event *ev;
> +
> +    ev = malloc(sizeof(*ev));
> +    if (!ev) {
> +        LIBXL__EVENT_DISASTER(gc, "allocate new event", errno, type);
> +        return NULL;
> +    }
> +
> +    memset(ev, 0, sizeof(*ev));
> +    ev->type = type;
> +    ev->domid = domid;
> +
> +    return ev;
> +}
> +
> +static int event_check_unlocked(libxl__gc *gc, libxl_event **event_r,

The *_unlocked functions are slightly confusing, since what it really
means is "caller must have taken the lock already" rather than "you can
call this unlocked". I'm not sure what would be better though.

> +                                unsigned long typemask,
> +                                libxl_event_predicate *pred, void *pred_user) {
> +    libxl_event *ev;
> +    int rc;
> +
> +    LIBXL_TAILQ_FOREACH(ev, &CTX->occurred, link) {
> +        if (!(typemask & (1UL << ev->type)))
> +            continue;
> +
> +        if (pred && !pred(ev, pred_user))
> +            continue;
> +
> +        /* got one! */
> +        LIBXL_TAILQ_REMOVE(&CTX->occurred, ev, link);
> +        *event_r = ev;
> +        rc = 0;
> +        goto out;
> +    }
> +    rc = ERROR_NOT_READY;
> +
> + out:
> +    return rc;
> +}
> +
> +int libxl_event_check(libxl_ctx *ctx, libxl_event **event_r,
> +                      unsigned long typemask,
> +                      libxl_event_predicate *pred, void *pred_user) {
> +    GC_INIT(ctx);
> +    CTX_LOCK;
> +    int rc = event_check_unlocked(gc, event_r, typemask, pred, pred_user);
> +    CTX_UNLOCK;
> +    GC_FREE;
> +    return rc;
> +}
> +
> +int libxl_event_wait(libxl_ctx *ctx, libxl_event **event_r,
> +                     unsigned long typemask,
> +                     libxl_event_predicate *pred, void *pred_user) {
> +    int rc;
> +    struct timeval now;
> +
> +    GC_INIT(ctx);
> +    CTX_LOCK;
> +
> +    for (;;) {
> +        rc = event_check_unlocked(gc, event_r, typemask, pred, pred_user);
> +        if (rc != ERROR_NOT_READY) goto out;
> +
> +        rc = libxl__gettimeofday(gc, &now);
> +        if (rc) goto out;
> +
> +        int timeout;
> +
> +        for (;;) {
> +            int nfds = CTX->fd_polls_allocd;
> +            timeout = -1;
> +            rc = beforepoll_unlocked(gc, &nfds, CTX->fd_polls, &timeout, now);
> +            if (!rc) break;
> +            if (rc != ERROR_BUFFERFULL) goto out;
> +
> +            struct pollfd *newarray =
> +                (nfds > INT_MAX / sizeof(struct pollfd) / 2) ? 0 :

I think I've seen this construct before. I think it's worth a #define.

Hrm, was the other one a different struct in the sizeof? *scrobbles
around*. Yes, it was libxl__ev_fd* in that case and we were setting up
the before polled array.

However aren't these two arrays related (one is a shadow of the other)?
IOW isn't the real limit the minimum of the two cases?

> +                realloc(CTX->fd_polls, sizeof(*newarray) * nfds);
> +
> +            if (!newarray) { rc = ERROR_NOMEM; goto out; }
> +
> +            CTX->fd_polls = newarray;
> +            CTX->fd_polls_allocd = nfds;
> +        }
> +
> +        rc = poll(CTX->fd_polls, CTX->fd_polls_allocd, timeout);
> +        if (rc < 0) {
> +            if (errno == EINTR) continue;
> +            LIBXL__LOG_ERRNOVAL(CTX, LIBXL__LOG_ERROR, errno, "poll failed");
> +            rc = ERROR_FAIL;
> +            goto out;
> +        }
> +
> +        rc = libxl__gettimeofday(gc, &now);
> +        if (rc) goto out;
> +
> +        afterpoll_unlocked(gc, CTX->fd_polls_allocd, CTX->fd_polls, now);
> +
> +        /* we unlock and free the gc each time we go through this loop,
> +         * so that (a) we don't accumulate garbage and (b) any events
> +         * which are to be dispatched by callback are actually delivered
> +         * in a timely fashion.
> +         */
> +        CTX_UNLOCK;
> +        libxl__free_all(gc);
> +        CTX_LOCK;
> +    }
> +
> + out:
> +    CTX_UNLOCK;
> +    GC_FREE;
> +    return rc;
> +}
> +
> +/*
>   * Local variables:
>   * mode: C
>   * c-basic-offset: 4
> diff --git a/tools/libxl/libxl_event.h b/tools/libxl/libxl_event.h
> index 25efbdf..bbe1ed0 100644
> --- a/tools/libxl/libxl_event.h
> +++ b/tools/libxl/libxl_event.h
[...]
> +/* Alternatively or additionally, the application may also use this: */
> +
> +typedef struct libxl_event_hooks {
> +    uint64_t event_occurs_mask;
> +    void (*event_occurs)(void *user, const libxl_event *event);
> +    void (*disaster)(void *user, libxl_event_type type,
> +                     const char *msg, int errnoval);
> +} libxl_event_hooks;
> +
> +void libxl_event_register_callbacks(libxl_ctx *ctx,
> +                                    const libxl_event_hooks *hooks, void *user);
> +  /*
> +   * Arranges that libxl will henceforth call event_occurs for any
> +   * events whose type is set in event_occurs_mask, rather than
> +   * queueing the event for retrieval by libxl_event_check/wait.
> +   * Events whose bit is clear in mask are not affected.

Earlier on you said that applications can mix and match the style of
event retrieval they use. Is it the case that for any given event type
it will be delivered by exactly of the two mechanisms? IOW if an event
type is in event_occurs_mask it will never be delivered via
libxl_event_check/wait and vice versa?

> +   *
> +   * event becomes owned by the application and must be freed, either
> +   * by event_occurs or later.
> +   *
[...]
> + * Applications should ensure that they eventually retrieve every
> + * event using libxl_event_check or libxl_event_wait, since events
> + * which occur but are not retreived by the application will be queued

                              retrieved

> + * inside libxl indefinitely.

Which is inevitably going to lead to disaster being called...

This only applies to every enabled event which is not delivered via the
callback mechanism, correct?

>   libxl_event_check/_wait may be O(n)
> + * where n is the number of queued events which do not match the
> + * criteria specified in the arguments to check/wait.
> + */
> +
> +typedef struct libxl__evgen_domain_death libxl_evgen_domain_death;
> +int libxl_evenable_domain_death(libxl_ctx *ctx, uint32_t domid,
> +                         libxl_ev_user, libxl_evgen_domain_death **evgen_out);
> +void libxl_evdisable_domain_death(libxl_ctx *ctx, libxl_evgen_domain_death*);
> +  /* Arranges for the generation of DOMAIN_SHUTDOWN and DOMAIN_DESTROY
> +   * events.  A domain which is destroyed before it shuts down
> +   * may generate only a DESTROY event.
> +   */
> +
> +typedef struct libxl__evgen_disk_eject libxl_evgen_disk_eject;
> +int libxl_evenable_disk_eject(libxl_ctx *ctx, uint32_t domid, const char *vdev,
> +                        libxl_ev_user, libxl_evgen_disk_eject **evgen_out);
> +void libxl_evdisable_disk_eject(libxl_ctx *ctx, libxl_evgen_disk_eject*);
> +  /* Arranges for the generation of DISK_EJECT events.  A copy of the
> +   * string *vdev will be made for libxl's internal use, and a pointer
> +   * to this (or some other) copy will be returned as the vdev
> +   * member of event.u.

Should event.u.vdev therefore be const? (skipping forward to the IDL
addition it seems not to be)

> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> index 88e7dbb..518a06d 100644
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
> @@ -154,11 +154,44 @@ typedef struct libxl__ev_watch_slot {
> 
>  libxl__ev_xswatch *libxl__watch_slot_contents(libxl__gc *gc, int slotnum);
> 
> +
> +/*
> + * evgen structures, which are the state we use for generating
> + * events for the caller.
> + *
> + * In general in each case there's an internal and an external
> + * version of the _evdisable_FOO function; the internal one is
> + * used during cleanup.
> + */
> +
> +struct libxl__evgen_domain_death {
> +    uint32_t domid;
> +    unsigned shutdown_reported:1, death_reported:1;
> +    LIBXL_TAILQ_ENTRY(libxl_evgen_domain_death) entry;
> +        /* on list .death_reported ? CTX->death_list : CTX->death_reported */

Isn't this the other way round?

> +    libxl_ev_user user;
> +};
> +_hidden void
> +libxl__evdisable_domain_death(libxl__gc*, libxl_evgen_domain_death*);
> +
[...]
> @@ -250,7 +295,9 @@ static inline libxl_ctx *libxl__gc_owner(libxl__gc *gc)
>   */
>  /* register @ptr in @gc for free on exit from outermost libxl callframe. */
>  _hidden int libxl__ptr_add(libxl__gc *gc, void *ptr);
> -/* if this is the outermost libxl callframe then free all pointers in @gc */
> +/* if this is the outermost libxl callframe then free all pointers in @gc
> + *  and report all occurred events via callback, if applicable.
> + * May reenters the application so must not be called with ctx locked. */

reenter

>  _hidden void libxl__free_all(libxl__gc *gc);
>  /* allocate and zero @bytes. (similar to a gc'd malloc(3)+memzero()) */
>  _hidden void *libxl__zalloc(libxl__gc *gc, int bytes);
[...]
> diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
> index d59d2cb..5a713f0 100644
> --- a/tools/libxl/libxl_types.idl
> +++ b/tools/libxl/libxl_types.idl
> @@ -75,11 +75,6 @@ libxl_action_on_shutdown = Enumeration("action_on_shutdown", [
>      (6, "COREDUMP_RESTART"),
>      ])
> 
> -libxl_event_type = Enumeration("event_type", [
> -    (1, "DOMAIN_DEATH"),
> -    (2, "DISK_EJECT"),
> -    ])
> -
>  libxl_button = Enumeration("button", [
>      (1, "POWER"),
>      (2, "SLEEP"),
> @@ -381,3 +376,33 @@ libxl_sched_credit = Struct("sched_credit", [
>      ("weight", integer),
>      ("cap", integer),
>      ], dispose_fn=None)
> +
> +libxl_event_type = Enumeration("event_type", [
> +    (1, "DOMAIN_SHUTDOWN"),
> +    (2, "DOMAIN_DESTROY"),
> +    (3, "DISK_EJECT"),
> +    ])
> +
> +libxl_ev_user = Number("libxl_ev_user")
> +
> +libxl_ev_link = Builtin("ev_link", passby=PASS_BY_REFERENCE, private=True)
> +
> +libxl_event = Struct("event",[
> +    ("link",     libxl_ev_link,0,

The third member here is supposed to be a bool hence "False". I guess
python lets you get away with that.

(this aspect of the IDL sucks, it should allow for named parameters
instead of an opaque, variably size, tuple)

> +     "for use by libxl; caller may use this once the event has been"
> +     " returned by libxl_event_{check,wait}"),
> +    ("domid",    libxl_domid),
> +    ("domuuid",  libxl_uuid),
> +    ("for_user", libxl_ev_user),
> +    ("type",     libxl_event_type),
> +    ("u", KeyedUnion(None, libxl_event_type, "type",
> +          [("domain_shutdown", Struct(None, [
> +                                             ("shutdown_reason", uint8),
> +                                      ])),
> +           ("domain_destroy", Struct(None, [])),
> +           ("disk_eject", Struct(None, [
> +                                        ("vdev", string),
> +                                        ("disk", libxl_device_disk),
> +                                 ])),
> +           ]))])
> +
> diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
> index f1e729c..e5738b7 100644
> --- a/tools/libxl/xl_cmdimpl.c
> +++ b/tools/libxl/xl_cmdimpl.c

[...]
> @@ -1439,10 +1465,11 @@ static int create_domain(struct domain_create *dom_info)
>      const char *restore_file = dom_info->restore_file;
>      int migrate_fd = dom_info->migrate_fd;
> 
> -    int fd, i;
> +    int i;
>      int need_daemon = daemonize;
>      int ret, rc;
> -    libxl_waiter *w1 = NULL, *w2 = NULL;
> +    libxl_evgen_domain_death *deathw = NULL;
> +    libxl_evgen_disk_eject **diskws = NULL; /* one per disk */
>      void *config_data = 0;
>      int config_len = 0;
>      int restore_fd = -1;
> @@ -1647,14 +1674,14 @@ start:
>                  if (errno != EINTR) {
>                      perror("failed to wait for daemonizing child");
>                      ret = ERROR_FAIL;
> -                    goto error_out;
> +                    goto out;
>                  }
>              }
>              if (status) {
>                  libxl_report_child_exitstatus(ctx, XTL_ERROR,
>                             "daemonizing child", child1, status);
>                  ret = ERROR_FAIL;
> -                goto error_out;
> +                goto out;
>              }
>              ret = domid;
>              goto out;
> @@ -1691,92 +1718,106 @@ start:
>      }
>      LOG("Waiting for domain %s (domid %d) to die [pid %ld]",
>          d_config.c_info.name, domid, (long)getpid());
[...]
> +    ret = libxl_evenable_domain_death(ctx, domid, 0, &deathw);
> +    if (ret) goto out;
> 
[...]
> +    if (!diskws) {
> +        diskws = xmalloc(sizeof(*diskws) * d_config.num_disks);
> +        for (i = 0; i < d_config.num_disks; i++)
> +            diskws[i] = NULL;
> +    }
> +    for (i = 0; i < d_config.num_disks; i++) {
> +        ret = libxl_evenable_disk_eject(ctx, domid, d_config.disks[i].vdev,
> +                                        0, &diskws[i]);
> +        if (ret) goto out;
> +    }

Are all disks ejectable? I think only emulated CDROM devices are and
emulated disks and all PV devices are not. Should libxl provide a
predicate?

Of course it is harmless to wait for an eject on a device which can't...


> +    while (1) {
> +        libxl_event *event;
> +        ret = domain_wait_event(&event);
> +        if (ret) goto out;
> +
> +        switch (event->type) {
> +
> +        case LIBXL_EVENT_TYPE_DOMAIN_SHUTDOWN:
> +            LOG("Domain %d has shut down, reason code %d 0x%x", domid,
> +                event->u.domain_shutdown.shutdown_reason,
> +                event->u.domain_shutdown.shutdown_reason);
> +            switch (handle_domain_death(ctx, domid, event, &d_config)) {
> +            case 2:
> +                if (!preserve_domain(ctx, domid, event, &d_config)) {
> +                    /* If we fail then exit leaving the old domain in place. */
> +                    ret = -1;
> +                    goto out;
>                  }
> 
[...]
> +                /* Otherwise fall through and restart. */
> +            case 1:
> +                libxl_event_free(ctx, event);
> +                libxl_evdisable_domain_death(ctx, deathw);
> +                deathw = NULL;
> +                for (i = 0; i < d_config.num_disks; i++) {
> +                    libxl_evdisable_disk_eject(ctx, diskws[i]);
> +                    diskws[i] = NULL;
>                  }
[...]
> +                /* discard any other events which may have been generated */
> +                while (!(ret = libxl_event_check(ctx, &event,
> +                                                 LIBXL_EVENTMASK_ALL, 0,0))) {
> +                    libxl_event_free(ctx, event);
>                  }
[...]
> +                if (ret != ERROR_NOT_READY) {
> +                    LOG("warning, libxl_event_check (cleanup) failed (rc=%d)",
> +                        ret);
> +                }

This sees likely to be a commonly wanted pattern. Perhaps libxl could
provide a helper (or several) to disable all events and drain the queue?

[...]
> +                /*
> +                 * XXX FIXME: If this sleep is not there then domain
> +                 * re-creation fails sometimes.
> +                 */
> +                LOG("Done. Rebooting now");
> +                sleep(2);

The optimistic part of me wonders if this is still the case...

> +                goto start;
> +
> +            case 0:
> +                LOG("Done. Exiting now");
> +                ret = 0;
> +                goto out;
> +
> +            default:
> +                abort();
> +            }
> +
> +        case LIBXL_EVENT_TYPE_DOMAIN_DESTROY:
> +            LOG("Domain %d has been destroyed.", domid);
> +            ret = 0;
> +            goto out;
> +
> +        case LIBXL_EVENT_TYPE_DISK_EJECT:
> +            /* XXX what is this for? */
> +            libxl_cdrom_insert(ctx, domid, &event->u.disk_eject.disk);

Assuming &event->u.disk_eject.disk is an empty variant of the ejected
disk (like libxl_event_get_disk_eject_info used to return) then I think
this is "inserting" and empty device, i.e. ejecting it.

It might be more obvious to have libxl_cdrom_eject which takes the
"full" version of the disk and does the obvious thing (modifying the
disk to be empty)?

> +            break;
> +
> +        default:;
> +            char *evstr = libxl_event_to_json(ctx, event);
> +            LOG("warning, got unexpected event type %d, event=%s",
> +                event->type, evstr);
> +            free(evstr);
>          }
[...]
> +
> +        libxl_event_free(ctx, event);
>      }
> 
>  error_out:
> @@ -2259,43 +2300,46 @@ static void destroy_domain(const char *p)
>  static void shutdown_domain(const char *p, int wait)
>  {
>      int rc;
> +    libxl_event *event;
> 
>      find_domain(p);
>      rc=libxl_domain_shutdown(ctx, domid, 0);
>      if (rc) { fprintf(stderr,"shutdown failed (rc=%d)\n",rc);exit(-1); }
> 
>      if (wait) {
[...]
> +        libxl_evgen_domain_death *deathw;
> 
[...]
> +        rc = libxl_evenable_domain_death(ctx, domid, 0, &deathw);
> +        if (rc) {
> +            fprintf(stderr,"wait for death failed (evgen, rc=%d)\n",rc);
> +            exit(-1);
> +        }
> 
[...]
> +        for (;;) {
> +            rc = domain_wait_event(&event);
> +            if (rc) exit(-1);
> 
[...]
> +            switch (event->type) {
> 
[...]
> +            case LIBXL_EVENT_TYPE_DOMAIN_DESTROY:
> +                LOG("Domain %d has been destroyed", domid);
> +                goto done;
> 
[...]
> +            case LIBXL_EVENT_TYPE_DOMAIN_SHUTDOWN:
> +                LOG("Domain %d has been shut down, reason code %d %x", domid,
> +                    event->u.domain_shutdown.shutdown_reason,
> +                    event->u.domain_shutdown.shutdown_reason);
> +                goto done;
> 
[...]
> +            default:
> +                LOG("Unexpected event type %d", event->type);
> +                break;
>              }
[...]
> +            libxl_event_free(ctx, event);
>          }
[...]
> +    done:
> +        libxl_event_free(ctx, event);
> +        libxl_evdisable_domain_death(ctx, deathw);
>      }
>  }
> 
> --
> 1.7.2.5
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 08 11:54:56 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 Dec 2011 11: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.xensource.com>)
	id 1RYcYR-0003lj-Ro; Thu, 08 Dec 2011 11:54:23 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RYcYP-0003le-SV
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 11:54:22 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1323345180!55880091!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDg5NQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3366 invoked from network); 8 Dec 2011 11:53:00 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Dec 2011 11:53:00 -0000
X-IronPort-AV: E=Sophos;i="4.71,319,1320624000"; 
   d="scan'208";a="9361239"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Dec 2011 11:53:04 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 8 Dec 2011
	11:53:04 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Thu, 8 Dec 2011 11:53:03 +0000
In-Reply-To: <1323108621-22654-16-git-send-email-ian.jackson@eu.citrix.com>
References: <1323108621-22654-1-git-send-email-ian.jackson@eu.citrix.com>
	<1323108621-22654-16-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323345183.2969.125.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 15/15] libxl: New event generation API
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2011-12-05 at 18:10 +0000, Ian Jackson wrote:
> Replace the existing API for retrieving high-level events (events
> about domains, etc.) from libxl with a new one.
> 
> This changes the definition and semantics of the `libxl_event'
> structure, and replaces the calls for obtaining information about
> domain death and disk eject events.
> 
> This is an incompatible change, sorry.  The alternative was to try to
> provide both the previous horrid API and the new one, and would also
> involve never using the name `libxl_event' for the new interface.
> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
> ---
>  tools/libxl/libxl.c          |  302 ++++++++++++++++++++++++++++++------------
>  tools/libxl/libxl.h          |   55 ++-------
>  tools/libxl/libxl_event.c    |  188 ++++++++++++++++++++++++---
>  tools/libxl/libxl_event.h    |  180 ++++++++++++++++++++++++-
>  tools/libxl/libxl_internal.c |    6 +
>  tools/libxl/libxl_internal.h |   81 +++++++++++-
>  tools/libxl/libxl_types.idl  |   35 ++++-
>  tools/libxl/xl_cmdimpl.c     |  270 ++++++++++++++++++++++----------------
>  8 files changed, 839 insertions(+), 278 deletions(-)
> 
> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> index 58f280c..ba9293b 100644
> --- a/tools/libxl/libxl.c
> +++ b/tools/libxl/libxl.c
> @@ -614,117 +631,173 @@ int libxl_domain_shutdown(libxl_ctx *ctx, uint32_t domid, int req)
>      return 0;
>  }
> 
> -int libxl_get_wait_fd(libxl_ctx *ctx, int *fd)
> -{
> -    *fd = xs_fileno(ctx->xsh);
> -    return 0;
> -}
> +static void domain_death_xswatch_callback(libxl__gc *gc, libxl__ev_xswatch *w,
> +                                        const char *wpath, const char *epath) {
> +    libxl_evgen_domain_death *evg;
> +    uint32_t domid;
> +    int rc;

Ugh, diff has made some very unhelpful choices about how to display this
change. Oh well. I've snipped all the - bits to try and make it easier
to follow.

[...]
> +    CTX_LOCK;
[...]
> +    uint32_t domid = libxl_get_stubdom_id(ctx, guest_domid);
> +    evg = LIBXL_TAILQ_FIRST(&CTX->death_list);
> +    if (!evg) goto out;
> 
> +    domid = evg->domid;
> 
[...]
> +    for (;;) {
> +        int nentries = LIBXL_TAILQ_NEXT(evg, entry) ? 200 : 1;
> +        xc_domaininfo_t domaininfos[nentries];
> +        const xc_domaininfo_t *got = domaininfos, *gotend;
> +
> +        rc = xc_domain_getinfolist(CTX->xch, domid, nentries, domaininfos);
> +        if (rc == -1) {
> +            LIBXL__EVENT_DISASTER(gc, "xc_domain_getinfolist failed while"
> +                                  " processing @releaseDomain watch event",
> +                                  errno, 0);
>              goto out;
[...]
> +        }
> +        gotend = &domaininfos[rc];
> +
> +        for (;;) {
> +            if (!evg)
> +                goto all_reported;
> +
> +            if (!rc || got->domain > evg->domid) {
> +                /* ie, the list doesn't contain evg->domid any more so
> +                 * the domain has been destroyed */
> +                libxl_evgen_domain_death *evg_next;
> +
> +                libxl_event *ev = NEW_EVENT(gc, DOMAIN_DESTROY, evg->domid);
> +                if (!ev) goto out;
> +
> +                libxl__event_occurred(gc, ev);
> +
> +                evg->death_reported = 1;
> +                evg_next = LIBXL_TAILQ_NEXT(evg, entry);
> +                LIBXL_TAILQ_REMOVE(&CTX->death_list, evg, entry);
> +                LIBXL_TAILQ_INSERT_HEAD(&CTX->death_reported, evg, entry);
> +                evg = evg_next;
> +
> +                continue;
> +            }
> +
> +            if (got == gotend)
> +                break;
> +
> +            if (got->domain < evg->domid) {
> +                got++;
> +                continue;
> +            }
> +
> +            assert(evg->domid == got->domain);
> +
> +            if (!evg->shutdown_reported &&
> +                (got->flags & XEN_DOMINF_shutdown)) {
> +                libxl_event *ev = NEW_EVENT(gc, DOMAIN_SHUTDOWN, got->domain);
> +                if (!ev) goto out;
> +
> +                ev->u.domain_shutdown.shutdown_reason =
> +                    (got->flags >> XEN_DOMINF_shutdownshift) &
> +                    XEN_DOMINF_shutdownmask;
> +                libxl__event_occurred(gc, ev);
> +
> +                evg->shutdown_reported = 1;
> +            }
> +            evg = LIBXL_TAILQ_NEXT(evg, entry);
> +        }
> +
> +        assert(rc); /* rc==0 results in us eating all evgs and quitting */
> +        domid = gotend[-1].domain;
>      }
[...]
> + all_reported:
> + out:
> +
> +    CTX_UNLOCK;
>  }
> 
[...]
> +int libxl_evenable_domain_death(libxl_ctx *ctx, uint32_t domid,
> +                libxl_ev_user user, libxl_evgen_domain_death **evgen_out) {
> +    GC_INIT(ctx);
> +    libxl_evgen_domain_death *evg, *evg_search;
> +    int rc;
> +
> +    CTX_LOCK;
> +
> +    evg = malloc(sizeof(*evg));  if (!evg) { rc = ERROR_NOMEM; goto out; }

CODING_STYLE?

> +    memset(evg, 0, sizeof(*evg));
> +    evg->domid = domid;
> +    evg->user = user;
> +
> +    LIBXL_TAILQ_INSERT_SORTED(&ctx->death_list, entry, evg, evg_search, ,
> +                              evg->domid > evg_search->domid);
> +
> +    if (!libxl__ev_xswatch_isregistered(&ctx->death_watch)) {
> +        rc = libxl__ev_xswatch_register(gc, &ctx->death_watch,
> +                        domain_death_xswatch_callback, "@releaseDomain");
> +        if (rc) { libxl__evdisable_domain_death(gc, evg); goto out; }
>      }
[...]
> +    rc = 0;
> 
[...]
> + out:
> +    CTX_UNLOCK;
> +    return rc;
> +};
> 
[...]
> +void libxl__evdisable_domain_death(libxl__gc *gc,
> +                                   libxl_evgen_domain_death *evg) {
> +    CTX_LOCK;
> 
[...]
> +    if (!evg->death_reported)
> +        LIBXL_TAILQ_REMOVE(&CTX->death_list, evg, entry);
> +    else
> +        LIBXL_TAILQ_REMOVE(&CTX->death_reported, evg, entry);
> 
[...]
> +    free(evg);
> +
> +    if (!LIBXL_TAILQ_FIRST(&CTX->death_list) &&
> +        libxl__ev_xswatch_isregistered(&CTX->death_watch))
> +        libxl__ev_xswatch_deregister(gc, &CTX->death_watch);
> 
[...]
> +    CTX_UNLOCK;
>  }
> 
[...]
> +void libxl_evdisable_domain_death(libxl_ctx *ctx,
> +                                  libxl_evgen_domain_death *evg) {
>      GC_INIT(ctx);
[...]
> +    libxl__evdisable_domain_death(gc, evg);
> +    GC_FREE;
> +}
> +
> +static void disk_eject_xswatch_callback(libxl__gc *gc, libxl__ev_xswatch *watch,
> +                                        const char *wpath, const char *epath) {
> +    libxl_evgen_disk_eject *evg = (void*)watch;
>      char *backend;
>      char *value;
>      char backend_type[BACKEND_STRING_SIZE+1];
> 
[...]
> +    value = libxl__xs_read(gc, XBT_NULL, wpath);
> 
[...]
> +    if (!value || strcmp(value,  "eject"))
> +        return;
> +
> +    if (libxl__xs_write(gc, XBT_NULL, wpath, "")) {
> +        LIBXL__EVENT_DISASTER(gc, "xs_write failed acknowledging eject",
> +                              errno, LIBXL_EVENT_TYPE_DISK_EJECT);
> +        return;
>      }
> 
> -    path = strdup(event->path);
[...]
> +    libxl_event *ev = NEW_EVENT(gc, DISK_EJECT, evg->domid);
> +    libxl_device_disk *disk = &ev->u.disk_eject.disk;
> +
> +    backend = libxl__xs_read(gc, XBT_NULL,
> +                             libxl__sprintf(gc, "%.*s/backend",
> +                                            (int)strlen(wpath)-6, wpath));

This pattern crops up a lot in libxl. I keep wondering if libxl__xs_read
shouldn't take a fmt string and varargs. Not sure how you would do that
in a way which allowed libxl__xs_write to have an orthogonal (and still
sane) interface though.

> 
>      sscanf(backend,
[...]
> +            "/local/domain/%d/backend/%" TOSTRING(BACKEND_STRING_SIZE)
> +           "[a-z]/%*d/%*d",
> +           &disk->backend_domid, backend_type);
>      if (!strcmp(backend_type, "tap") || !strcmp(backend_type, "vbd")) {
>          disk->backend = LIBXL_DISK_BACKEND_TAP;
>      } else if (!strcmp(backend_type, "qdisk")) {
> @@ -733,19 +806,72 @@ int libxl_event_get_disk_eject_info(libxl_ctx *ctx, uint32_t domid, libxl_event
>          disk->backend = LIBXL_DISK_BACKEND_UNKNOWN;
>      }
> 
[...]
> +    disk->pdev_path = strdup(""); /* xxx fixme malloc failure */
>      disk->format = LIBXL_DISK_FORMAT_EMPTY;
>      /* this value is returned to the user: do not free right away */
[...]
> +    disk->vdev = xs_read(CTX->xsh, XBT_NULL,
> +                         libxl__sprintf(gc, "%s/dev", backend), NULL);
>      disk->removable = 1;
>      disk->readwrite = 0;
>      disk->is_cdrom = 1;
> 
[...]
> +    libxl__event_occurred(gc, ev);
> +}
> +
[...]
> diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
> index 654a5b0..17b15a6 100644
> --- a/tools/libxl/libxl.h
> +++ b/tools/libxl/libxl.h
> @@ -53,7 +53,10 @@
>   *    A public function may be called from within libxl; the call
>   *    context initialisation macros will make sure that the internal
>   *    caller's context is reused (eg, so that the same xenstore
> - *    transaction is used).
> + *    transaction is used).  But in-libxl callers of libxl public
> + *    functions should note that any libxl public function may cause
> + *    recursively reentry into libxl via the application's event
> + *    callback hook.
>   *
>   *    Public functions have names like libxl_foobar.
>   *
> @@ -152,6 +155,8 @@ void libxl_key_value_list_dispose(libxl_key_value_list *kvl);
> 
>  typedef uint32_t libxl_hwcap[8];
> 
> +typedef uint64_t libxl_ev_user;
> +
>  typedef struct {
>      uint32_t size;          /* number of bytes in map */
>      uint8_t *map;
> @@ -200,6 +205,9 @@ typedef struct {
>      int v;
>  } libxl_enum_string_table;
> 
> +struct libxl_event;
> +typedef LIBXL_TAILQ_ENTRY(struct libxl_event) libxl_ev_link;

I think I made a comment on an earlier patch about why the list stuff
was exposed to the user. I guess I now have my answer.

[...]
> diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
> index 8d4dbf6..ec5c25e 100644
> --- a/tools/libxl/libxl_event.c
> +++ b/tools/libxl/libxl_event.c
[...]
> @@ -703,6 +713,152 @@ void libxl__event_disaster(libxl__gc *gc, const char *msg, int errnoval,
>  }
> 
>  /*
> + * Event retrieval etc.
> + */
> +
> +void libxl_event_register_callbacks(libxl_ctx *ctx,
> +                  const libxl_event_hooks *hooks, void *user) {
> +    ctx->event_hooks = hooks;
> +    ctx->event_hooks_user = user;

Does this either need locking or a check that there are no events in
flight? Or is it invalid to change hooks once they are registered?

> +}
> +
> +void libxl__event_occurred(libxl__gc *gc, libxl_event *event) {
> +    if (CTX->event_hooks &&
> +        (CTX->event_hooks->event_occurs_mask & (1UL << event->type))) {
> +        /* libxl__free_all will call the callback, just before exit
> +         * from libxl.  This helps avoid reentrancy bugs: parts of
> +         * libxl that call libxl__event_occurred do not have to worry
> +         * that libxl might be reentered at that point. */
> +        LIBXL_TAILQ_INSERT_TAIL(&gc->occurred_for_callback, event, link);
> +        return;

This return seem surplus to requirements.

> +    } else {
> +        LIBXL_TAILQ_INSERT_TAIL(&CTX->occurred, event, link);
> +    }
> +}
> +
> +void libxl_event_free(libxl_ctx *ctx, libxl_event *event) {
> +    libxl_event_dispose(event);
> +    free(event);
> +}
> +
> +libxl_event *libxl__event_new(libxl__gc *gc,
> +                              libxl_event_type type, uint32_t domid) {
> +    libxl_event *ev;
> +
> +    ev = malloc(sizeof(*ev));
> +    if (!ev) {
> +        LIBXL__EVENT_DISASTER(gc, "allocate new event", errno, type);
> +        return NULL;
> +    }
> +
> +    memset(ev, 0, sizeof(*ev));
> +    ev->type = type;
> +    ev->domid = domid;
> +
> +    return ev;
> +}
> +
> +static int event_check_unlocked(libxl__gc *gc, libxl_event **event_r,

The *_unlocked functions are slightly confusing, since what it really
means is "caller must have taken the lock already" rather than "you can
call this unlocked". I'm not sure what would be better though.

> +                                unsigned long typemask,
> +                                libxl_event_predicate *pred, void *pred_user) {
> +    libxl_event *ev;
> +    int rc;
> +
> +    LIBXL_TAILQ_FOREACH(ev, &CTX->occurred, link) {
> +        if (!(typemask & (1UL << ev->type)))
> +            continue;
> +
> +        if (pred && !pred(ev, pred_user))
> +            continue;
> +
> +        /* got one! */
> +        LIBXL_TAILQ_REMOVE(&CTX->occurred, ev, link);
> +        *event_r = ev;
> +        rc = 0;
> +        goto out;
> +    }
> +    rc = ERROR_NOT_READY;
> +
> + out:
> +    return rc;
> +}
> +
> +int libxl_event_check(libxl_ctx *ctx, libxl_event **event_r,
> +                      unsigned long typemask,
> +                      libxl_event_predicate *pred, void *pred_user) {
> +    GC_INIT(ctx);
> +    CTX_LOCK;
> +    int rc = event_check_unlocked(gc, event_r, typemask, pred, pred_user);
> +    CTX_UNLOCK;
> +    GC_FREE;
> +    return rc;
> +}
> +
> +int libxl_event_wait(libxl_ctx *ctx, libxl_event **event_r,
> +                     unsigned long typemask,
> +                     libxl_event_predicate *pred, void *pred_user) {
> +    int rc;
> +    struct timeval now;
> +
> +    GC_INIT(ctx);
> +    CTX_LOCK;
> +
> +    for (;;) {
> +        rc = event_check_unlocked(gc, event_r, typemask, pred, pred_user);
> +        if (rc != ERROR_NOT_READY) goto out;
> +
> +        rc = libxl__gettimeofday(gc, &now);
> +        if (rc) goto out;
> +
> +        int timeout;
> +
> +        for (;;) {
> +            int nfds = CTX->fd_polls_allocd;
> +            timeout = -1;
> +            rc = beforepoll_unlocked(gc, &nfds, CTX->fd_polls, &timeout, now);
> +            if (!rc) break;
> +            if (rc != ERROR_BUFFERFULL) goto out;
> +
> +            struct pollfd *newarray =
> +                (nfds > INT_MAX / sizeof(struct pollfd) / 2) ? 0 :

I think I've seen this construct before. I think it's worth a #define.

Hrm, was the other one a different struct in the sizeof? *scrobbles
around*. Yes, it was libxl__ev_fd* in that case and we were setting up
the before polled array.

However aren't these two arrays related (one is a shadow of the other)?
IOW isn't the real limit the minimum of the two cases?

> +                realloc(CTX->fd_polls, sizeof(*newarray) * nfds);
> +
> +            if (!newarray) { rc = ERROR_NOMEM; goto out; }
> +
> +            CTX->fd_polls = newarray;
> +            CTX->fd_polls_allocd = nfds;
> +        }
> +
> +        rc = poll(CTX->fd_polls, CTX->fd_polls_allocd, timeout);
> +        if (rc < 0) {
> +            if (errno == EINTR) continue;
> +            LIBXL__LOG_ERRNOVAL(CTX, LIBXL__LOG_ERROR, errno, "poll failed");
> +            rc = ERROR_FAIL;
> +            goto out;
> +        }
> +
> +        rc = libxl__gettimeofday(gc, &now);
> +        if (rc) goto out;
> +
> +        afterpoll_unlocked(gc, CTX->fd_polls_allocd, CTX->fd_polls, now);
> +
> +        /* we unlock and free the gc each time we go through this loop,
> +         * so that (a) we don't accumulate garbage and (b) any events
> +         * which are to be dispatched by callback are actually delivered
> +         * in a timely fashion.
> +         */
> +        CTX_UNLOCK;
> +        libxl__free_all(gc);
> +        CTX_LOCK;
> +    }
> +
> + out:
> +    CTX_UNLOCK;
> +    GC_FREE;
> +    return rc;
> +}
> +
> +/*
>   * Local variables:
>   * mode: C
>   * c-basic-offset: 4
> diff --git a/tools/libxl/libxl_event.h b/tools/libxl/libxl_event.h
> index 25efbdf..bbe1ed0 100644
> --- a/tools/libxl/libxl_event.h
> +++ b/tools/libxl/libxl_event.h
[...]
> +/* Alternatively or additionally, the application may also use this: */
> +
> +typedef struct libxl_event_hooks {
> +    uint64_t event_occurs_mask;
> +    void (*event_occurs)(void *user, const libxl_event *event);
> +    void (*disaster)(void *user, libxl_event_type type,
> +                     const char *msg, int errnoval);
> +} libxl_event_hooks;
> +
> +void libxl_event_register_callbacks(libxl_ctx *ctx,
> +                                    const libxl_event_hooks *hooks, void *user);
> +  /*
> +   * Arranges that libxl will henceforth call event_occurs for any
> +   * events whose type is set in event_occurs_mask, rather than
> +   * queueing the event for retrieval by libxl_event_check/wait.
> +   * Events whose bit is clear in mask are not affected.

Earlier on you said that applications can mix and match the style of
event retrieval they use. Is it the case that for any given event type
it will be delivered by exactly of the two mechanisms? IOW if an event
type is in event_occurs_mask it will never be delivered via
libxl_event_check/wait and vice versa?

> +   *
> +   * event becomes owned by the application and must be freed, either
> +   * by event_occurs or later.
> +   *
[...]
> + * Applications should ensure that they eventually retrieve every
> + * event using libxl_event_check or libxl_event_wait, since events
> + * which occur but are not retreived by the application will be queued

                              retrieved

> + * inside libxl indefinitely.

Which is inevitably going to lead to disaster being called...

This only applies to every enabled event which is not delivered via the
callback mechanism, correct?

>   libxl_event_check/_wait may be O(n)
> + * where n is the number of queued events which do not match the
> + * criteria specified in the arguments to check/wait.
> + */
> +
> +typedef struct libxl__evgen_domain_death libxl_evgen_domain_death;
> +int libxl_evenable_domain_death(libxl_ctx *ctx, uint32_t domid,
> +                         libxl_ev_user, libxl_evgen_domain_death **evgen_out);
> +void libxl_evdisable_domain_death(libxl_ctx *ctx, libxl_evgen_domain_death*);
> +  /* Arranges for the generation of DOMAIN_SHUTDOWN and DOMAIN_DESTROY
> +   * events.  A domain which is destroyed before it shuts down
> +   * may generate only a DESTROY event.
> +   */
> +
> +typedef struct libxl__evgen_disk_eject libxl_evgen_disk_eject;
> +int libxl_evenable_disk_eject(libxl_ctx *ctx, uint32_t domid, const char *vdev,
> +                        libxl_ev_user, libxl_evgen_disk_eject **evgen_out);
> +void libxl_evdisable_disk_eject(libxl_ctx *ctx, libxl_evgen_disk_eject*);
> +  /* Arranges for the generation of DISK_EJECT events.  A copy of the
> +   * string *vdev will be made for libxl's internal use, and a pointer
> +   * to this (or some other) copy will be returned as the vdev
> +   * member of event.u.

Should event.u.vdev therefore be const? (skipping forward to the IDL
addition it seems not to be)

> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> index 88e7dbb..518a06d 100644
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
> @@ -154,11 +154,44 @@ typedef struct libxl__ev_watch_slot {
> 
>  libxl__ev_xswatch *libxl__watch_slot_contents(libxl__gc *gc, int slotnum);
> 
> +
> +/*
> + * evgen structures, which are the state we use for generating
> + * events for the caller.
> + *
> + * In general in each case there's an internal and an external
> + * version of the _evdisable_FOO function; the internal one is
> + * used during cleanup.
> + */
> +
> +struct libxl__evgen_domain_death {
> +    uint32_t domid;
> +    unsigned shutdown_reported:1, death_reported:1;
> +    LIBXL_TAILQ_ENTRY(libxl_evgen_domain_death) entry;
> +        /* on list .death_reported ? CTX->death_list : CTX->death_reported */

Isn't this the other way round?

> +    libxl_ev_user user;
> +};
> +_hidden void
> +libxl__evdisable_domain_death(libxl__gc*, libxl_evgen_domain_death*);
> +
[...]
> @@ -250,7 +295,9 @@ static inline libxl_ctx *libxl__gc_owner(libxl__gc *gc)
>   */
>  /* register @ptr in @gc for free on exit from outermost libxl callframe. */
>  _hidden int libxl__ptr_add(libxl__gc *gc, void *ptr);
> -/* if this is the outermost libxl callframe then free all pointers in @gc */
> +/* if this is the outermost libxl callframe then free all pointers in @gc
> + *  and report all occurred events via callback, if applicable.
> + * May reenters the application so must not be called with ctx locked. */

reenter

>  _hidden void libxl__free_all(libxl__gc *gc);
>  /* allocate and zero @bytes. (similar to a gc'd malloc(3)+memzero()) */
>  _hidden void *libxl__zalloc(libxl__gc *gc, int bytes);
[...]
> diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
> index d59d2cb..5a713f0 100644
> --- a/tools/libxl/libxl_types.idl
> +++ b/tools/libxl/libxl_types.idl
> @@ -75,11 +75,6 @@ libxl_action_on_shutdown = Enumeration("action_on_shutdown", [
>      (6, "COREDUMP_RESTART"),
>      ])
> 
> -libxl_event_type = Enumeration("event_type", [
> -    (1, "DOMAIN_DEATH"),
> -    (2, "DISK_EJECT"),
> -    ])
> -
>  libxl_button = Enumeration("button", [
>      (1, "POWER"),
>      (2, "SLEEP"),
> @@ -381,3 +376,33 @@ libxl_sched_credit = Struct("sched_credit", [
>      ("weight", integer),
>      ("cap", integer),
>      ], dispose_fn=None)
> +
> +libxl_event_type = Enumeration("event_type", [
> +    (1, "DOMAIN_SHUTDOWN"),
> +    (2, "DOMAIN_DESTROY"),
> +    (3, "DISK_EJECT"),
> +    ])
> +
> +libxl_ev_user = Number("libxl_ev_user")
> +
> +libxl_ev_link = Builtin("ev_link", passby=PASS_BY_REFERENCE, private=True)
> +
> +libxl_event = Struct("event",[
> +    ("link",     libxl_ev_link,0,

The third member here is supposed to be a bool hence "False". I guess
python lets you get away with that.

(this aspect of the IDL sucks, it should allow for named parameters
instead of an opaque, variably size, tuple)

> +     "for use by libxl; caller may use this once the event has been"
> +     " returned by libxl_event_{check,wait}"),
> +    ("domid",    libxl_domid),
> +    ("domuuid",  libxl_uuid),
> +    ("for_user", libxl_ev_user),
> +    ("type",     libxl_event_type),
> +    ("u", KeyedUnion(None, libxl_event_type, "type",
> +          [("domain_shutdown", Struct(None, [
> +                                             ("shutdown_reason", uint8),
> +                                      ])),
> +           ("domain_destroy", Struct(None, [])),
> +           ("disk_eject", Struct(None, [
> +                                        ("vdev", string),
> +                                        ("disk", libxl_device_disk),
> +                                 ])),
> +           ]))])
> +
> diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
> index f1e729c..e5738b7 100644
> --- a/tools/libxl/xl_cmdimpl.c
> +++ b/tools/libxl/xl_cmdimpl.c

[...]
> @@ -1439,10 +1465,11 @@ static int create_domain(struct domain_create *dom_info)
>      const char *restore_file = dom_info->restore_file;
>      int migrate_fd = dom_info->migrate_fd;
> 
> -    int fd, i;
> +    int i;
>      int need_daemon = daemonize;
>      int ret, rc;
> -    libxl_waiter *w1 = NULL, *w2 = NULL;
> +    libxl_evgen_domain_death *deathw = NULL;
> +    libxl_evgen_disk_eject **diskws = NULL; /* one per disk */
>      void *config_data = 0;
>      int config_len = 0;
>      int restore_fd = -1;
> @@ -1647,14 +1674,14 @@ start:
>                  if (errno != EINTR) {
>                      perror("failed to wait for daemonizing child");
>                      ret = ERROR_FAIL;
> -                    goto error_out;
> +                    goto out;
>                  }
>              }
>              if (status) {
>                  libxl_report_child_exitstatus(ctx, XTL_ERROR,
>                             "daemonizing child", child1, status);
>                  ret = ERROR_FAIL;
> -                goto error_out;
> +                goto out;
>              }
>              ret = domid;
>              goto out;
> @@ -1691,92 +1718,106 @@ start:
>      }
>      LOG("Waiting for domain %s (domid %d) to die [pid %ld]",
>          d_config.c_info.name, domid, (long)getpid());
[...]
> +    ret = libxl_evenable_domain_death(ctx, domid, 0, &deathw);
> +    if (ret) goto out;
> 
[...]
> +    if (!diskws) {
> +        diskws = xmalloc(sizeof(*diskws) * d_config.num_disks);
> +        for (i = 0; i < d_config.num_disks; i++)
> +            diskws[i] = NULL;
> +    }
> +    for (i = 0; i < d_config.num_disks; i++) {
> +        ret = libxl_evenable_disk_eject(ctx, domid, d_config.disks[i].vdev,
> +                                        0, &diskws[i]);
> +        if (ret) goto out;
> +    }

Are all disks ejectable? I think only emulated CDROM devices are and
emulated disks and all PV devices are not. Should libxl provide a
predicate?

Of course it is harmless to wait for an eject on a device which can't...


> +    while (1) {
> +        libxl_event *event;
> +        ret = domain_wait_event(&event);
> +        if (ret) goto out;
> +
> +        switch (event->type) {
> +
> +        case LIBXL_EVENT_TYPE_DOMAIN_SHUTDOWN:
> +            LOG("Domain %d has shut down, reason code %d 0x%x", domid,
> +                event->u.domain_shutdown.shutdown_reason,
> +                event->u.domain_shutdown.shutdown_reason);
> +            switch (handle_domain_death(ctx, domid, event, &d_config)) {
> +            case 2:
> +                if (!preserve_domain(ctx, domid, event, &d_config)) {
> +                    /* If we fail then exit leaving the old domain in place. */
> +                    ret = -1;
> +                    goto out;
>                  }
> 
[...]
> +                /* Otherwise fall through and restart. */
> +            case 1:
> +                libxl_event_free(ctx, event);
> +                libxl_evdisable_domain_death(ctx, deathw);
> +                deathw = NULL;
> +                for (i = 0; i < d_config.num_disks; i++) {
> +                    libxl_evdisable_disk_eject(ctx, diskws[i]);
> +                    diskws[i] = NULL;
>                  }
[...]
> +                /* discard any other events which may have been generated */
> +                while (!(ret = libxl_event_check(ctx, &event,
> +                                                 LIBXL_EVENTMASK_ALL, 0,0))) {
> +                    libxl_event_free(ctx, event);
>                  }
[...]
> +                if (ret != ERROR_NOT_READY) {
> +                    LOG("warning, libxl_event_check (cleanup) failed (rc=%d)",
> +                        ret);
> +                }

This sees likely to be a commonly wanted pattern. Perhaps libxl could
provide a helper (or several) to disable all events and drain the queue?

[...]
> +                /*
> +                 * XXX FIXME: If this sleep is not there then domain
> +                 * re-creation fails sometimes.
> +                 */
> +                LOG("Done. Rebooting now");
> +                sleep(2);

The optimistic part of me wonders if this is still the case...

> +                goto start;
> +
> +            case 0:
> +                LOG("Done. Exiting now");
> +                ret = 0;
> +                goto out;
> +
> +            default:
> +                abort();
> +            }
> +
> +        case LIBXL_EVENT_TYPE_DOMAIN_DESTROY:
> +            LOG("Domain %d has been destroyed.", domid);
> +            ret = 0;
> +            goto out;
> +
> +        case LIBXL_EVENT_TYPE_DISK_EJECT:
> +            /* XXX what is this for? */
> +            libxl_cdrom_insert(ctx, domid, &event->u.disk_eject.disk);

Assuming &event->u.disk_eject.disk is an empty variant of the ejected
disk (like libxl_event_get_disk_eject_info used to return) then I think
this is "inserting" and empty device, i.e. ejecting it.

It might be more obvious to have libxl_cdrom_eject which takes the
"full" version of the disk and does the obvious thing (modifying the
disk to be empty)?

> +            break;
> +
> +        default:;
> +            char *evstr = libxl_event_to_json(ctx, event);
> +            LOG("warning, got unexpected event type %d, event=%s",
> +                event->type, evstr);
> +            free(evstr);
>          }
[...]
> +
> +        libxl_event_free(ctx, event);
>      }
> 
>  error_out:
> @@ -2259,43 +2300,46 @@ static void destroy_domain(const char *p)
>  static void shutdown_domain(const char *p, int wait)
>  {
>      int rc;
> +    libxl_event *event;
> 
>      find_domain(p);
>      rc=libxl_domain_shutdown(ctx, domid, 0);
>      if (rc) { fprintf(stderr,"shutdown failed (rc=%d)\n",rc);exit(-1); }
> 
>      if (wait) {
[...]
> +        libxl_evgen_domain_death *deathw;
> 
[...]
> +        rc = libxl_evenable_domain_death(ctx, domid, 0, &deathw);
> +        if (rc) {
> +            fprintf(stderr,"wait for death failed (evgen, rc=%d)\n",rc);
> +            exit(-1);
> +        }
> 
[...]
> +        for (;;) {
> +            rc = domain_wait_event(&event);
> +            if (rc) exit(-1);
> 
[...]
> +            switch (event->type) {
> 
[...]
> +            case LIBXL_EVENT_TYPE_DOMAIN_DESTROY:
> +                LOG("Domain %d has been destroyed", domid);
> +                goto done;
> 
[...]
> +            case LIBXL_EVENT_TYPE_DOMAIN_SHUTDOWN:
> +                LOG("Domain %d has been shut down, reason code %d %x", domid,
> +                    event->u.domain_shutdown.shutdown_reason,
> +                    event->u.domain_shutdown.shutdown_reason);
> +                goto done;
> 
[...]
> +            default:
> +                LOG("Unexpected event type %d", event->type);
> +                break;
>              }
[...]
> +            libxl_event_free(ctx, event);
>          }
[...]
> +    done:
> +        libxl_event_free(ctx, event);
> +        libxl_evdisable_domain_death(ctx, deathw);
>      }
>  }
> 
> --
> 1.7.2.5
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 08 12:01:55 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 Dec 2011 12: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.xensource.com>)
	id 1RYcfC-00044W-Ie; Thu, 08 Dec 2011 12:01:22 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <anthony@overnetdata.com>) id 1RYcfB-00043z-BK
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 12:01:21 +0000
X-Env-Sender: anthony@overnetdata.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1323345625!4565372!1
X-Originating-IP: [81.137.131.225]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16361 invoked from network); 8 Dec 2011 12:00:26 -0000
Received: from host81-137-131-225.in-addr.btopenworld.com (HELO
	zimbra.overnetdata.com) (81.137.131.225)
	by server-15.tower-174.messagelabs.com with SMTP;
	8 Dec 2011 12:00:26 -0000
Received: from localhost (localhost.localdomain [127.0.0.1])
	by zimbra.overnetdata.com (Postfix) with ESMTP id 1BF24160C84
	for <xen-devel@lists.xensource.com>;
	Thu,  8 Dec 2011 12:00:18 +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 vg5ZMiF2wkRw for <xen-devel@lists.xensource.com>;
	Thu,  8 Dec 2011 12:00:10 +0000 (GMT)
Received: from [192.168.1.55] (unknown [192.168.1.55])
	by zimbra.overnetdata.com (Postfix) with ESMTPSA id 8901A160B15
	for <xen-devel@lists.xensource.com>;
	Thu,  8 Dec 2011 12:00:10 +0000 (GMT)
Message-ID: <4EE0A6C7.9080603@overnetdata.com>
Date: Thu, 08 Dec 2011 12:00:07 +0000
From: Anthony Wright <anthony@overnetdata.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
X-Enigmail-Version: 1.3.3
Subject: [Xen-devel] VGA Passthrough crashes machine
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

I've just had my first attempt at getting VGA passthrough to work, and
it crashed the machine. I'm trying to understand whether this is a
problem with my hardware, configuration or a software problem.

I'm running Xen 4.1.2 with Linux 3.1.2


The CPU is an Intel Core i5-650
http://ark.intel.com/products/43546/Intel-Core-i5-650-Processor-%284M-Cache-3_20-GHz%29

The Video Card is and Intel Core Processor Integrated Graphics Controller
PCI ID: 8086 0042


I have hidden the vga device with xen-pciback.hide=(00:02.0) on the
kernel command line

The xen config file is:
name        = '11-1'
kernel            = '/usr/lib/xen/boot/hvmloader'
builder           = 'hvm'
device_model      = '/usr/lib/xen/bin/qemu-dm'
boot              = 'c'
serial            = 'pty'
usbdevice         = 'tablet'
disk        = [ 'phy:/dev/Master/Root-11-0001,hda,w' ]
memory      = 1000
vif         = [
'bridge=br-internal,mac=04:fb:7a:22:e8:4a','bridge=br-dmz,mac=04:fb:7a:22:e8:4b','bridge=br-local,mac=04:fb:7a:22:e8:4c'
]
vcpus       = 1
on_poweroff = 'destroy'
on_reboot   = 'destroy'
on_crash    = 'destroy'

gfx_passthru=1
pci=['00:02.0']

When I try to start the DomU I get the following output, I get the
prompt back and then the system reboots.

Parsing config file xen-config
xc: info: VIRTUAL MEMORY ARRANGEMENT:
  Loader:        0000000000100000->00000000001795d0
  TOTAL:         0000000000000000->000000003e000000
  ENTRY ADDRESS: 0000000000100000
xc: info: PHYSICAL MEMORY ALLOCATION:
  4KB PAGES: 0x0000000000000200
  2MB PAGES: 0x00000000000001ef
  1GB PAGES: 0x0000000000000000
libxl: error: libxl_pci.c:712:do_pci_add xc_assign_device failed
Daemon running with PID 2050


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 08 12:01:55 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 Dec 2011 12: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.xensource.com>)
	id 1RYcfC-00044W-Ie; Thu, 08 Dec 2011 12:01:22 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <anthony@overnetdata.com>) id 1RYcfB-00043z-BK
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 12:01:21 +0000
X-Env-Sender: anthony@overnetdata.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1323345625!4565372!1
X-Originating-IP: [81.137.131.225]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16361 invoked from network); 8 Dec 2011 12:00:26 -0000
Received: from host81-137-131-225.in-addr.btopenworld.com (HELO
	zimbra.overnetdata.com) (81.137.131.225)
	by server-15.tower-174.messagelabs.com with SMTP;
	8 Dec 2011 12:00:26 -0000
Received: from localhost (localhost.localdomain [127.0.0.1])
	by zimbra.overnetdata.com (Postfix) with ESMTP id 1BF24160C84
	for <xen-devel@lists.xensource.com>;
	Thu,  8 Dec 2011 12:00:18 +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 vg5ZMiF2wkRw for <xen-devel@lists.xensource.com>;
	Thu,  8 Dec 2011 12:00:10 +0000 (GMT)
Received: from [192.168.1.55] (unknown [192.168.1.55])
	by zimbra.overnetdata.com (Postfix) with ESMTPSA id 8901A160B15
	for <xen-devel@lists.xensource.com>;
	Thu,  8 Dec 2011 12:00:10 +0000 (GMT)
Message-ID: <4EE0A6C7.9080603@overnetdata.com>
Date: Thu, 08 Dec 2011 12:00:07 +0000
From: Anthony Wright <anthony@overnetdata.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
X-Enigmail-Version: 1.3.3
Subject: [Xen-devel] VGA Passthrough crashes machine
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

I've just had my first attempt at getting VGA passthrough to work, and
it crashed the machine. I'm trying to understand whether this is a
problem with my hardware, configuration or a software problem.

I'm running Xen 4.1.2 with Linux 3.1.2


The CPU is an Intel Core i5-650
http://ark.intel.com/products/43546/Intel-Core-i5-650-Processor-%284M-Cache-3_20-GHz%29

The Video Card is and Intel Core Processor Integrated Graphics Controller
PCI ID: 8086 0042


I have hidden the vga device with xen-pciback.hide=(00:02.0) on the
kernel command line

The xen config file is:
name        = '11-1'
kernel            = '/usr/lib/xen/boot/hvmloader'
builder           = 'hvm'
device_model      = '/usr/lib/xen/bin/qemu-dm'
boot              = 'c'
serial            = 'pty'
usbdevice         = 'tablet'
disk        = [ 'phy:/dev/Master/Root-11-0001,hda,w' ]
memory      = 1000
vif         = [
'bridge=br-internal,mac=04:fb:7a:22:e8:4a','bridge=br-dmz,mac=04:fb:7a:22:e8:4b','bridge=br-local,mac=04:fb:7a:22:e8:4c'
]
vcpus       = 1
on_poweroff = 'destroy'
on_reboot   = 'destroy'
on_crash    = 'destroy'

gfx_passthru=1
pci=['00:02.0']

When I try to start the DomU I get the following output, I get the
prompt back and then the system reboots.

Parsing config file xen-config
xc: info: VIRTUAL MEMORY ARRANGEMENT:
  Loader:        0000000000100000->00000000001795d0
  TOTAL:         0000000000000000->000000003e000000
  ENTRY ADDRESS: 0000000000100000
xc: info: PHYSICAL MEMORY ALLOCATION:
  4KB PAGES: 0x0000000000000200
  2MB PAGES: 0x00000000000001ef
  1GB PAGES: 0x0000000000000000
libxl: error: libxl_pci.c:712:do_pci_add xc_assign_device failed
Daemon running with PID 2050


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 08 12:09:43 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 Dec 2011 12:09:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYcmu-0004Nl-If; Thu, 08 Dec 2011 12:09:20 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <amit.shah@redhat.com>) id 1RYcmt-0004Ng-FM
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 12:09:19 +0000
X-Env-Sender: amit.shah@redhat.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1323346110!6416339!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDYzNjI=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9081 invoked from network); 8 Dec 2011 12:08:31 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-12.tower-182.messagelabs.com with SMTP;
	8 Dec 2011 12:08:31 -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 pB8C88IP000968
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 8 Dec 2011 07:08:08 -0500
Received: from localhost (ovpn-113-27.phx2.redhat.com [10.3.113.27])
	by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id pB8C85OS000466; Thu, 8 Dec 2011 07:08:07 -0500
Date: Thu, 8 Dec 2011 17:38:04 +0530
From: Amit Shah <amit.shah@redhat.com>
To: Miche Baker-Harvey <miche@google.com>
Message-ID: <20111208120804.GF23531@amit-x200.redhat.com>
References: <20111108214504.28884.61814.stgit@miche.sea.corp.google.com>
	<874nybqo0o.fsf@rustcorp.com.au>
	<CAB8RdapbaueyWLJuJDE_ZdvLkRNM4sQHTxgmgO=jrnXZ6YPSmA@mail.gmail.com>
	<20111123103852.GG16665@amit-x200.redhat.com>
	<CAB8RdaoDxMCgTjuGP70bGrsrtgh=USYtU3Spo5OPtVMYAM5EzQ@mail.gmail.com>
	<20111129142149.GE2822@amit-x200.redhat.com>
	<CAB8RdapuPRym2dH_9mgmGdzpCxnP1KpS+hS8JJ-geVkga5fMcw@mail.gmail.com>
	<CAB8Rdapfuf5XH+X9gsUL+CJ9gTQcSNfq4Dj9DoYWQeFgD04ODQ@mail.gmail.com>
	<20111205105452.GB27683@amit-x200.redhat.com>
	<CAB8Rdar=qOokxZkjQVRmo=zN_f75jPwzU+6=WBRo0g+P7w+pAw@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAB8Rdar=qOokxZkjQVRmo=zN_f75jPwzU+6=WBRo0g+P7w+pAw@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
Cc: Stephen Rothwell <sfr@canb.auug.org.au>, xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Rusty Russell <rusty@rustcorp.com.au>, linux-kernel@vger.kernel.org,
	virtualization@lists.linux-foundation.org,
	Anton Blanchard <anton@samba.org>, Mike Waychison <mikew@google.com>,
	ppc-dev <linuxppc-dev@lists.ozlabs.org>,
	Greg Kroah-Hartman <gregkh@suse.de>, Eric Northrup <digitaleric@google.com>
Subject: Re: [Xen-devel] [PATCH v3 2/3] hvc_init(): Enforce one-time
	initialization.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On (Tue) 06 Dec 2011 [09:05:38], Miche Baker-Harvey wrote:
> Amit,
> 
> Ah, indeed.  I am not using MSI-X, so virtio_pci::vp_try_to_find_vqs()
> calls vp_request_intx() and sets up an interrupt callback.  From
> there, when an interrupt occurs, the stack looks something like this:
> 
> virtio_pci::vp_interrupt()
>   virtio_pci::vp_vring_interrupt()
>     virtio_ring::vring_interrupt()
>       vq->vq.callback()  <-- in this case, that's virtio_console::control_intr()
>         workqueue::schedule_work()
>           workqueue::queue_work()
>             queue_work_on(get_cpu())  <-- queues the work on the current CPU.
> 
> I'm not doing anything to keep multiple control message from being
> sent concurrently to the guest, and we will take those interrupts on
> any CPU. I've confirmed that the two instances of
> handle_control_message() are occurring on different CPUs.

So let's have a new helper, port_lock() that takes the port-specific
spinlock.  There has to be a new helper, since the port lock should
depend on the portdev lock being taken too.  For the port addition
case, just the portdev lock should be taken.  For any other
operations, the port lock should be taken.

My assumption was that we would be able to serialise the work items,
but that will be too restrictive.  Taking port locks sounds like a
better idea.

We'd definitely need the port lock in the control work handler.  We
might need it in a few more places (like module removal), but we'll
worry about that later.

Does this sound fine?

		Amit

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 08 12:09:43 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 Dec 2011 12:09:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYcmu-0004Nl-If; Thu, 08 Dec 2011 12:09:20 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <amit.shah@redhat.com>) id 1RYcmt-0004Ng-FM
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 12:09:19 +0000
X-Env-Sender: amit.shah@redhat.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1323346110!6416339!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDYzNjI=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9081 invoked from network); 8 Dec 2011 12:08:31 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-12.tower-182.messagelabs.com with SMTP;
	8 Dec 2011 12:08:31 -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 pB8C88IP000968
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 8 Dec 2011 07:08:08 -0500
Received: from localhost (ovpn-113-27.phx2.redhat.com [10.3.113.27])
	by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id pB8C85OS000466; Thu, 8 Dec 2011 07:08:07 -0500
Date: Thu, 8 Dec 2011 17:38:04 +0530
From: Amit Shah <amit.shah@redhat.com>
To: Miche Baker-Harvey <miche@google.com>
Message-ID: <20111208120804.GF23531@amit-x200.redhat.com>
References: <20111108214504.28884.61814.stgit@miche.sea.corp.google.com>
	<874nybqo0o.fsf@rustcorp.com.au>
	<CAB8RdapbaueyWLJuJDE_ZdvLkRNM4sQHTxgmgO=jrnXZ6YPSmA@mail.gmail.com>
	<20111123103852.GG16665@amit-x200.redhat.com>
	<CAB8RdaoDxMCgTjuGP70bGrsrtgh=USYtU3Spo5OPtVMYAM5EzQ@mail.gmail.com>
	<20111129142149.GE2822@amit-x200.redhat.com>
	<CAB8RdapuPRym2dH_9mgmGdzpCxnP1KpS+hS8JJ-geVkga5fMcw@mail.gmail.com>
	<CAB8Rdapfuf5XH+X9gsUL+CJ9gTQcSNfq4Dj9DoYWQeFgD04ODQ@mail.gmail.com>
	<20111205105452.GB27683@amit-x200.redhat.com>
	<CAB8Rdar=qOokxZkjQVRmo=zN_f75jPwzU+6=WBRo0g+P7w+pAw@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAB8Rdar=qOokxZkjQVRmo=zN_f75jPwzU+6=WBRo0g+P7w+pAw@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
Cc: Stephen Rothwell <sfr@canb.auug.org.au>, xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Rusty Russell <rusty@rustcorp.com.au>, linux-kernel@vger.kernel.org,
	virtualization@lists.linux-foundation.org,
	Anton Blanchard <anton@samba.org>, Mike Waychison <mikew@google.com>,
	ppc-dev <linuxppc-dev@lists.ozlabs.org>,
	Greg Kroah-Hartman <gregkh@suse.de>, Eric Northrup <digitaleric@google.com>
Subject: Re: [Xen-devel] [PATCH v3 2/3] hvc_init(): Enforce one-time
	initialization.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On (Tue) 06 Dec 2011 [09:05:38], Miche Baker-Harvey wrote:
> Amit,
> 
> Ah, indeed.  I am not using MSI-X, so virtio_pci::vp_try_to_find_vqs()
> calls vp_request_intx() and sets up an interrupt callback.  From
> there, when an interrupt occurs, the stack looks something like this:
> 
> virtio_pci::vp_interrupt()
>   virtio_pci::vp_vring_interrupt()
>     virtio_ring::vring_interrupt()
>       vq->vq.callback()  <-- in this case, that's virtio_console::control_intr()
>         workqueue::schedule_work()
>           workqueue::queue_work()
>             queue_work_on(get_cpu())  <-- queues the work on the current CPU.
> 
> I'm not doing anything to keep multiple control message from being
> sent concurrently to the guest, and we will take those interrupts on
> any CPU. I've confirmed that the two instances of
> handle_control_message() are occurring on different CPUs.

So let's have a new helper, port_lock() that takes the port-specific
spinlock.  There has to be a new helper, since the port lock should
depend on the portdev lock being taken too.  For the port addition
case, just the portdev lock should be taken.  For any other
operations, the port lock should be taken.

My assumption was that we would be able to serialise the work items,
but that will be too restrictive.  Taking port locks sounds like a
better idea.

We'd definitely need the port lock in the control work handler.  We
might need it in a few more places (like module removal), but we'll
worry about that later.

Does this sound fine?

		Amit

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 08 13:48:55 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 Dec 2011 13:48:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYeKg-0005Hm-On; Thu, 08 Dec 2011 13:48:18 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <annie.li@oracle.com>) id 1RYeKf-0005He-65
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 13:48:17 +0000
X-Env-Sender: annie.li@oracle.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1323352047!6081962!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQyMjA1NA==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17924 invoked from network); 8 Dec 2011 13:47:29 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-13.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 8 Dec 2011 13:47:29 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pB8DlOPP003612
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 8 Dec 2011 13:47:25 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pB8DlMG5003978
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 8 Dec 2011 13:47:22 GMT
Received: from abhmt102.oracle.com (abhmt102.oracle.com [141.146.116.54])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pB8DlFaS016519; Thu, 8 Dec 2011 07:47:15 -0600
Received: from [114.253.100.94] (/114.253.100.94)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 08 Dec 2011 05:47:14 -0800
Message-ID: <4EE0BFCA.7010208@oracle.com>
Date: Thu, 08 Dec 2011 21:46:50 +0800
From: annie li <annie.li@oracle.com>
Organization: Oracle Corporation
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
MIME-Version: 1.0
To: Paul Durrant <Paul.Durrant@citrix.com>
References: <1323336940-5382-1-git-send-email-annie.li@oracle.com>
	<1323337048-5426-1-git-send-email-annie.li@oracle.com>
	<291EDFCB1E9E224A99088639C4762022B5988E5528@LONPMAILBOX01.citrite.net>
	<4EE08B0D.80504@oracle.com>
	<291EDFCB1E9E224A99088639C4762022B5988E552D@LONPMAILBOX01.citrite.net>
In-Reply-To: <291EDFCB1E9E224A99088639C4762022B5988E552D@LONPMAILBOX01.citrite.net>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A020202.4EE0BFED.00CF,ss=1,re=0.000,fgs=0
Cc: "jeremy@goop.org" <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	"kurt.hackel@oracle.com" <kurt.hackel@oracle.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [Xen-devel] [PATCH V2 1/2] xen/granttable: Support sub-page
	grants
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>
>
> I say let's be optimistic :-) Yes, there's more overhead in the failure case, but that's not what we should be optimising for.
>   
>From positive side, it is OK. I agree with you since the failure case does not occurs frequently, the other goodness is the code style can keep identical with gnttab_grant_foreign_access and gnttab_grant_foreign_access_ref. thanks.

Thanks
Annie


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 08 13:48:55 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 Dec 2011 13:48:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYeKg-0005Hm-On; Thu, 08 Dec 2011 13:48:18 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <annie.li@oracle.com>) id 1RYeKf-0005He-65
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 13:48:17 +0000
X-Env-Sender: annie.li@oracle.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1323352047!6081962!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQyMjA1NA==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17924 invoked from network); 8 Dec 2011 13:47:29 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-13.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 8 Dec 2011 13:47:29 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pB8DlOPP003612
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 8 Dec 2011 13:47:25 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pB8DlMG5003978
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 8 Dec 2011 13:47:22 GMT
Received: from abhmt102.oracle.com (abhmt102.oracle.com [141.146.116.54])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pB8DlFaS016519; Thu, 8 Dec 2011 07:47:15 -0600
Received: from [114.253.100.94] (/114.253.100.94)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 08 Dec 2011 05:47:14 -0800
Message-ID: <4EE0BFCA.7010208@oracle.com>
Date: Thu, 08 Dec 2011 21:46:50 +0800
From: annie li <annie.li@oracle.com>
Organization: Oracle Corporation
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
MIME-Version: 1.0
To: Paul Durrant <Paul.Durrant@citrix.com>
References: <1323336940-5382-1-git-send-email-annie.li@oracle.com>
	<1323337048-5426-1-git-send-email-annie.li@oracle.com>
	<291EDFCB1E9E224A99088639C4762022B5988E5528@LONPMAILBOX01.citrite.net>
	<4EE08B0D.80504@oracle.com>
	<291EDFCB1E9E224A99088639C4762022B5988E552D@LONPMAILBOX01.citrite.net>
In-Reply-To: <291EDFCB1E9E224A99088639C4762022B5988E552D@LONPMAILBOX01.citrite.net>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A020202.4EE0BFED.00CF,ss=1,re=0.000,fgs=0
Cc: "jeremy@goop.org" <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	"kurt.hackel@oracle.com" <kurt.hackel@oracle.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [Xen-devel] [PATCH V2 1/2] xen/granttable: Support sub-page
	grants
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>
>
> I say let's be optimistic :-) Yes, there's more overhead in the failure case, but that's not what we should be optimising for.
>   
>From positive side, it is OK. I agree with you since the failure case does not occurs frequently, the other goodness is the code style can keep identical with gnttab_grant_foreign_access and gnttab_grant_foreign_access_ref. thanks.

Thanks
Annie


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 08 13:55:30 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 Dec 2011 13:55:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYeRG-0005V6-Tm; Thu, 08 Dec 2011 13:55:06 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RYeRF-0005U9-RX
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 13:55:06 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-4.tower-216.messagelabs.com!1323352456!6666281!1
X-Originating-IP: [208.97.132.66]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi42NiA9PiAxNTcxMg==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29379 invoked from network); 8 Dec 2011 13:54:17 -0000
Received: from caiajhbdcagg.dreamhost.com (HELO homiemail-a23.g.dreamhost.com)
	(208.97.132.66) by server-4.tower-216.messagelabs.com with SMTP;
	8 Dec 2011 13:54:17 -0000
Received: from homiemail-a23.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a23.g.dreamhost.com (Postfix) with ESMTP id 79A054B0097;
	Thu,  8 Dec 2011 05:54:16 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=ncNFqVIy6fY+zdgUUKtSj6FxTenwFg3+9mzZzCQxOT59
	uNsShbpQQMX9dRBszRqGiKPnvbt3+nEx7jUAVVVE8e8pDdJtE8OahGrJJe+IJ4IN
	UiFkD4V88iUOQOM0vLHNrWPKHvJjmE2ellYrHzXt+mvg1qi6u3m9bwxUnm/Eelo=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=mKzBuCx2d1ciBCPR7V97QNi6wNA=; b=iS4+DVWyjRr
	p23Vq9xyXCIVZW7Aau884BIw5Mqh+inaaPMRzEl7yXVYQYD8pWHcRDJXXYg7XdLt
	1rzuFqClF3cz1Mw3t8q8en+M4Ob+TijD2959m6tPdBex8vb5BJ8DHtoe9rfNt0jm
	DHasIO0JQKHjjMYGEH1s5h61JevJQzWs=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a23.g.dreamhost.com (Postfix) with ESMTPSA id 614DE4B0062; 
	Thu,  8 Dec 2011 05:54:15 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 14f08673af6addc25054467b1274b47757fe7562
Message-Id: <14f08673af6addc25054.1323352478@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1323352476@xdev.gridcentric.ca>
References: <patchbomb.1323352476@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Thu, 08 Dec 2011 08:54:38 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: ian.campbell@citrix.com, andres@gridcentric.ca, tim@xen.org,
	keir.xen@gmail.com, JBeulich@suse.com, ian.jackson@citrix.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 2 of 5] Tools: Libxc wrappers to add shared
	pages to physmap
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 tools/libxc/xc_memshr.c |  23 +++++++++++++++++++++++
 tools/libxc/xenctrl.h   |   6 ++++++
 2 files changed, 29 insertions(+), 0 deletions(-)


Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r b8be3a08e628 -r 14f08673af6a tools/libxc/xc_memshr.c
--- a/tools/libxc/xc_memshr.c
+++ b/tools/libxc/xc_memshr.c
@@ -86,6 +86,29 @@ int xc_memshr_nominate_gref(xc_interface
     return ret;
 }
 
+int xc_memshr_add_to_physmap(xc_interface *xch,
+                    uint32_t source_domain,
+                    uint64_t source_gfn,
+                    uint64_t source_handle,
+                    uint32_t client_domain,
+                    uint64_t client_gfn)
+{
+    DECLARE_DOMCTL;
+    struct xen_domctl_mem_sharing_op *op;
+
+    domctl.cmd                  = XEN_DOMCTL_mem_sharing_op;
+    domctl.interface_version    = XEN_DOMCTL_INTERFACE_VERSION;
+    domctl.domain               = (domid_t) source_domain;
+    op = &(domctl.u.mem_sharing_op);
+    op->op = XEN_DOMCTL_MEM_EVENT_OP_SHARING_ADD_PHYSMAP;
+    op->u.share.source_gfn      = source_gfn;
+    op->u.share.source_handle   = source_handle;
+    op->u.share.client_gfn      = client_gfn;
+    op->u.share.client_domain   = (uint64_t) client_domain;
+
+    return do_domctl(xch, &domctl);
+}
+
 int xc_memshr_share(xc_interface *xch,
                     uint32_t source_domain,
                     uint64_t source_gfn,
diff -r b8be3a08e628 -r 14f08673af6a tools/libxc/xenctrl.h
--- a/tools/libxc/xenctrl.h
+++ b/tools/libxc/xenctrl.h
@@ -1895,6 +1895,12 @@ int xc_memshr_nominate_gref(xc_interface
                             uint32_t domid,
                             grant_ref_t gref,
                             uint64_t *handle);
+int xc_memshr_add_to_physmap(xc_interface *xch,
+                    uint32_t source_domain,
+                    uint64_t source_gfn,
+                    uint64_t source_handle,
+                    uint32_t client_domain,
+                    uint64_t client_gfn);
 int xc_memshr_share(xc_interface *xch,
                     uint32_t source_domain,
                     uint64_t source_gfn,

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 08 13:55:30 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 Dec 2011 13:55:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYeRG-0005V6-Tm; Thu, 08 Dec 2011 13:55:06 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RYeRF-0005U9-RX
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 13:55:06 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-4.tower-216.messagelabs.com!1323352456!6666281!1
X-Originating-IP: [208.97.132.66]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi42NiA9PiAxNTcxMg==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29379 invoked from network); 8 Dec 2011 13:54:17 -0000
Received: from caiajhbdcagg.dreamhost.com (HELO homiemail-a23.g.dreamhost.com)
	(208.97.132.66) by server-4.tower-216.messagelabs.com with SMTP;
	8 Dec 2011 13:54:17 -0000
Received: from homiemail-a23.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a23.g.dreamhost.com (Postfix) with ESMTP id 79A054B0097;
	Thu,  8 Dec 2011 05:54:16 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=ncNFqVIy6fY+zdgUUKtSj6FxTenwFg3+9mzZzCQxOT59
	uNsShbpQQMX9dRBszRqGiKPnvbt3+nEx7jUAVVVE8e8pDdJtE8OahGrJJe+IJ4IN
	UiFkD4V88iUOQOM0vLHNrWPKHvJjmE2ellYrHzXt+mvg1qi6u3m9bwxUnm/Eelo=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=mKzBuCx2d1ciBCPR7V97QNi6wNA=; b=iS4+DVWyjRr
	p23Vq9xyXCIVZW7Aau884BIw5Mqh+inaaPMRzEl7yXVYQYD8pWHcRDJXXYg7XdLt
	1rzuFqClF3cz1Mw3t8q8en+M4Ob+TijD2959m6tPdBex8vb5BJ8DHtoe9rfNt0jm
	DHasIO0JQKHjjMYGEH1s5h61JevJQzWs=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a23.g.dreamhost.com (Postfix) with ESMTPSA id 614DE4B0062; 
	Thu,  8 Dec 2011 05:54:15 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 14f08673af6addc25054467b1274b47757fe7562
Message-Id: <14f08673af6addc25054.1323352478@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1323352476@xdev.gridcentric.ca>
References: <patchbomb.1323352476@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Thu, 08 Dec 2011 08:54:38 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: ian.campbell@citrix.com, andres@gridcentric.ca, tim@xen.org,
	keir.xen@gmail.com, JBeulich@suse.com, ian.jackson@citrix.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 2 of 5] Tools: Libxc wrappers to add shared
	pages to physmap
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 tools/libxc/xc_memshr.c |  23 +++++++++++++++++++++++
 tools/libxc/xenctrl.h   |   6 ++++++
 2 files changed, 29 insertions(+), 0 deletions(-)


Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r b8be3a08e628 -r 14f08673af6a tools/libxc/xc_memshr.c
--- a/tools/libxc/xc_memshr.c
+++ b/tools/libxc/xc_memshr.c
@@ -86,6 +86,29 @@ int xc_memshr_nominate_gref(xc_interface
     return ret;
 }
 
+int xc_memshr_add_to_physmap(xc_interface *xch,
+                    uint32_t source_domain,
+                    uint64_t source_gfn,
+                    uint64_t source_handle,
+                    uint32_t client_domain,
+                    uint64_t client_gfn)
+{
+    DECLARE_DOMCTL;
+    struct xen_domctl_mem_sharing_op *op;
+
+    domctl.cmd                  = XEN_DOMCTL_mem_sharing_op;
+    domctl.interface_version    = XEN_DOMCTL_INTERFACE_VERSION;
+    domctl.domain               = (domid_t) source_domain;
+    op = &(domctl.u.mem_sharing_op);
+    op->op = XEN_DOMCTL_MEM_EVENT_OP_SHARING_ADD_PHYSMAP;
+    op->u.share.source_gfn      = source_gfn;
+    op->u.share.source_handle   = source_handle;
+    op->u.share.client_gfn      = client_gfn;
+    op->u.share.client_domain   = (uint64_t) client_domain;
+
+    return do_domctl(xch, &domctl);
+}
+
 int xc_memshr_share(xc_interface *xch,
                     uint32_t source_domain,
                     uint64_t source_gfn,
diff -r b8be3a08e628 -r 14f08673af6a tools/libxc/xenctrl.h
--- a/tools/libxc/xenctrl.h
+++ b/tools/libxc/xenctrl.h
@@ -1895,6 +1895,12 @@ int xc_memshr_nominate_gref(xc_interface
                             uint32_t domid,
                             grant_ref_t gref,
                             uint64_t *handle);
+int xc_memshr_add_to_physmap(xc_interface *xch,
+                    uint32_t source_domain,
+                    uint64_t source_gfn,
+                    uint64_t source_handle,
+                    uint32_t client_domain,
+                    uint64_t client_gfn);
 int xc_memshr_share(xc_interface *xch,
                     uint32_t source_domain,
                     uint64_t source_gfn,

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 08 13:55:30 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 Dec 2011 13:55:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYeRF-0005Ui-Bo; Thu, 08 Dec 2011 13:55:05 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RYeRE-0005U7-MB
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 13:55:05 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-14.tower-216.messagelabs.com!1323352455!6114906!1
X-Originating-IP: [208.97.132.145]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNDUgPT4gMTcwNzU=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26923 invoked from network); 8 Dec 2011 13:54:15 -0000
Received: from caiajhbdcbef.dreamhost.com (HELO homiemail-a23.g.dreamhost.com)
	(208.97.132.145) by server-14.tower-216.messagelabs.com with SMTP;
	8 Dec 2011 13:54:15 -0000
Received: from homiemail-a23.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a23.g.dreamhost.com (Postfix) with ESMTP id 35E144B0089;
	Thu,  8 Dec 2011 05:54:15 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=o/yXQLT+riHtn4ScPXLwC9LEydxZbajA0jk1jW93dpQB
	fbOmCHepfyBypjtBQJEjzTSFq1RhHyppeUKbfkBLyJVCKw4U5I97+v2dd0OxoF9D
	ota9qlQ1o3XEC7SAPM3O8CwxH2uAa/juu+41r9Hj8ddKUqJrZ8xGJovi3EUgfkk=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=DOro9quFq94186Navzi1hpKbYbo=; b=Kj+HqtbIsYG
	B0ldjn3n09auNJzsAEcis5E/0+RIbWWycHoDNdi656imIk124vvAkywRl1YVuBjf
	8KwenjrseAUYvKDFvS/NAz3A2VVCBOhCr5shOsKFkzacAHg9bnBoxyZTCG394O7H
	p5uZObHNOjl6sxU1jK7ljOi4fJckCUJ0=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a23.g.dreamhost.com (Postfix) with ESMTPSA id 339084B0062; 
	Thu,  8 Dec 2011 05:54:14 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: b8be3a08e6288bef84e672aac6c4b9ba66489b98
Message-Id: <b8be3a08e6288bef84e6.1323352477@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1323352476@xdev.gridcentric.ca>
References: <patchbomb.1323352476@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Thu, 08 Dec 2011 08:54:37 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: ian.campbell@citrix.com, andres@gridcentric.ca, tim@xen.org,
	keir.xen@gmail.com, JBeulich@suse.com, ian.jackson@citrix.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 1 of 5] Add a shared page to the physmap
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/mm/mem_sharing.c |  106 ++++++++++++++++++++++++++++++++++++++++++
 xen/include/public/domctl.h   |    3 +-
 2 files changed, 108 insertions(+), 1 deletions(-)


This domctl is useful to, for example, populate parts of a domain's
physmap with shared frames, directly.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 62ea5c05ae7b -r b8be3a08e628 xen/arch/x86/mm/mem_sharing.c
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -734,6 +734,76 @@ err_out:
     return ret;
 }
 
+int mem_sharing_add_to_physmap(struct domain *sd, unsigned long sgfn, shr_handle_t sh,
+                            struct domain *cd, unsigned long cgfn) 
+{
+    struct page_info *spage;
+    int ret = -EINVAL;
+    mfn_t smfn, cmfn;
+    p2m_type_t smfn_type, cmfn_type;
+    struct gfn_info *gfn_info;
+    struct p2m_domain *p2m = p2m_get_hostp2m(cd);
+    p2m_access_t a;
+
+    shr_lock();
+    p2m_lock(p2m);
+    
+    /* XXX if sd == cd handle potential deadlock by ordering
+     * the get_ and put_gfn's */
+    smfn = get_gfn_query(sd, sgfn, &smfn_type);
+    cmfn = get_gfn_type_access(p2m, cgfn, &cmfn_type, &a, p2m_query, NULL);
+
+    /* Get the source shared page, check and lock */
+    ret = XEN_DOMCTL_MEM_SHARING_S_HANDLE_INVALID;
+    spage = __grab_shared_page(smfn);
+    if ( spage == NULL )
+        goto err_out;
+    ASSERT(smfn_type == p2m_ram_shared);
+
+    /* Check that the handles match */
+    if ( spage->shared_info->handle != sh )
+        goto err_unlock;
+
+    /* Make sure the target page is a hole in the physmap */
+    if ( mfn_valid(cmfn) ||
+         (!(p2m_is_ram(cmfn_type))) )
+    {
+        ret = XEN_DOMCTL_MEM_SHARING_C_HANDLE_INVALID;
+        goto err_unlock;
+    }
+
+    /* This is simpler than regular sharing */
+    BUG_ON(!get_page_and_type(spage, dom_cow, PGT_shared_page));
+    if ( (gfn_info = mem_sharing_gfn_alloc(spage, cd, cgfn)) == NULL )
+    {
+        put_page_and_type(spage);
+        ret = -ENOMEM;
+        goto err_unlock;
+    }
+
+    ret = set_p2m_entry(p2m, cgfn, smfn, PAGE_ORDER_4K, p2m_ram_shared, a);
+
+    /* Tempted to turn this into an assert */
+    if ( !ret ) {
+        ret = -ENOENT;
+        mem_sharing_gfn_destroy(gfn_info, 0);
+        put_page_and_type(spage);
+    } else {
+        atomic_inc(&cd->shr_pages);
+        atomic_inc(&nr_shared_mfns);
+        ret = 0;
+    }
+
+err_unlock:
+    mem_sharing_page_unlock(spage);
+err_out:
+    put_gfn(cd, cgfn);
+    put_gfn(sd, sgfn);
+    p2m_unlock(p2m);
+    shr_unlock();
+    return ret;
+}
+
 int mem_sharing_unshare_page(struct domain *d,
                              unsigned long gfn, 
                              uint16_t flags)
@@ -982,6 +1052,42 @@ int mem_sharing_domctl(struct domain *d,
         }
         break;
 
+        case XEN_DOMCTL_MEM_EVENT_OP_SHARING_ADD_PHYSMAP:
+        {
+            unsigned long sgfn, cgfn;
+            struct domain *cd;
+            shr_handle_t sh;
+
+            if ( !mem_sharing_enabled(d) )
+                return -EINVAL;
+
+            cd = get_domain_by_id(mec->u.share.client_domain);
+            if ( !cd )
+                return -ESRCH;
+
+            if ( !mem_sharing_enabled(cd) )
+            {
+                put_domain(cd);
+                return -EINVAL;
+            }
+
+            if ( XEN_DOMCTL_MEM_SHARING_FIELD_IS_GREF(mec->u.share.source_gfn) )
+            {
+                /* Cannot add a gref to the physmap */
+                put_domain(cd);
+                return -EINVAL;
+            }
+
+            sgfn    = mec->u.share.source_gfn;
+            sh      = mec->u.share.source_handle;
+            cgfn    = mec->u.share.client_gfn;
+
+            rc = mem_sharing_add_to_physmap(d, sgfn, sh, cd, cgfn); 
+
+            put_domain(cd);
+        }
+        break;
+
         case XEN_DOMCTL_MEM_EVENT_OP_SHARING_RESUME:
         {
             if ( !mem_sharing_enabled(d) )
diff -r 62ea5c05ae7b -r b8be3a08e628 xen/include/public/domctl.h
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -771,6 +771,7 @@ DEFINE_XEN_GUEST_HANDLE(xen_domctl_mem_e
 #define XEN_DOMCTL_MEM_EVENT_OP_SHARING_DEBUG_GFN      5
 #define XEN_DOMCTL_MEM_EVENT_OP_SHARING_DEBUG_MFN      6
 #define XEN_DOMCTL_MEM_EVENT_OP_SHARING_DEBUG_GREF     7
+#define XEN_DOMCTL_MEM_EVENT_OP_SHARING_ADD_PHYSMAP    8
 
 #define XEN_DOMCTL_MEM_SHARING_S_HANDLE_INVALID  (-10)
 #define XEN_DOMCTL_MEM_SHARING_C_HANDLE_INVALID  (-9)
@@ -797,7 +798,7 @@ struct xen_domctl_mem_sharing_op {
             } u;
             uint64_aligned_t  handle;     /* OUT: the handle           */
         } nominate;
-        struct mem_sharing_op_share {     /* OP_SHARE */
+        struct mem_sharing_op_share {     /* OP_SHARE/ADD_PHYSMAP */
             uint64_aligned_t source_gfn;    /* IN: the gfn of the source page */
             uint64_aligned_t source_handle; /* IN: handle to the source page */
             uint64_aligned_t client_domain; /* IN: the client domain id */

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 08 13:55:30 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 Dec 2011 13:55:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYeRF-0005Ui-Bo; Thu, 08 Dec 2011 13:55:05 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RYeRE-0005U7-MB
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 13:55:05 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-14.tower-216.messagelabs.com!1323352455!6114906!1
X-Originating-IP: [208.97.132.145]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNDUgPT4gMTcwNzU=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26923 invoked from network); 8 Dec 2011 13:54:15 -0000
Received: from caiajhbdcbef.dreamhost.com (HELO homiemail-a23.g.dreamhost.com)
	(208.97.132.145) by server-14.tower-216.messagelabs.com with SMTP;
	8 Dec 2011 13:54:15 -0000
Received: from homiemail-a23.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a23.g.dreamhost.com (Postfix) with ESMTP id 35E144B0089;
	Thu,  8 Dec 2011 05:54:15 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=o/yXQLT+riHtn4ScPXLwC9LEydxZbajA0jk1jW93dpQB
	fbOmCHepfyBypjtBQJEjzTSFq1RhHyppeUKbfkBLyJVCKw4U5I97+v2dd0OxoF9D
	ota9qlQ1o3XEC7SAPM3O8CwxH2uAa/juu+41r9Hj8ddKUqJrZ8xGJovi3EUgfkk=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=DOro9quFq94186Navzi1hpKbYbo=; b=Kj+HqtbIsYG
	B0ldjn3n09auNJzsAEcis5E/0+RIbWWycHoDNdi656imIk124vvAkywRl1YVuBjf
	8KwenjrseAUYvKDFvS/NAz3A2VVCBOhCr5shOsKFkzacAHg9bnBoxyZTCG394O7H
	p5uZObHNOjl6sxU1jK7ljOi4fJckCUJ0=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a23.g.dreamhost.com (Postfix) with ESMTPSA id 339084B0062; 
	Thu,  8 Dec 2011 05:54:14 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: b8be3a08e6288bef84e672aac6c4b9ba66489b98
Message-Id: <b8be3a08e6288bef84e6.1323352477@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1323352476@xdev.gridcentric.ca>
References: <patchbomb.1323352476@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Thu, 08 Dec 2011 08:54:37 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: ian.campbell@citrix.com, andres@gridcentric.ca, tim@xen.org,
	keir.xen@gmail.com, JBeulich@suse.com, ian.jackson@citrix.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 1 of 5] Add a shared page to the physmap
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/mm/mem_sharing.c |  106 ++++++++++++++++++++++++++++++++++++++++++
 xen/include/public/domctl.h   |    3 +-
 2 files changed, 108 insertions(+), 1 deletions(-)


This domctl is useful to, for example, populate parts of a domain's
physmap with shared frames, directly.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 62ea5c05ae7b -r b8be3a08e628 xen/arch/x86/mm/mem_sharing.c
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -734,6 +734,76 @@ err_out:
     return ret;
 }
 
+int mem_sharing_add_to_physmap(struct domain *sd, unsigned long sgfn, shr_handle_t sh,
+                            struct domain *cd, unsigned long cgfn) 
+{
+    struct page_info *spage;
+    int ret = -EINVAL;
+    mfn_t smfn, cmfn;
+    p2m_type_t smfn_type, cmfn_type;
+    struct gfn_info *gfn_info;
+    struct p2m_domain *p2m = p2m_get_hostp2m(cd);
+    p2m_access_t a;
+
+    shr_lock();
+    p2m_lock(p2m);
+    
+    /* XXX if sd == cd handle potential deadlock by ordering
+     * the get_ and put_gfn's */
+    smfn = get_gfn_query(sd, sgfn, &smfn_type);
+    cmfn = get_gfn_type_access(p2m, cgfn, &cmfn_type, &a, p2m_query, NULL);
+
+    /* Get the source shared page, check and lock */
+    ret = XEN_DOMCTL_MEM_SHARING_S_HANDLE_INVALID;
+    spage = __grab_shared_page(smfn);
+    if ( spage == NULL )
+        goto err_out;
+    ASSERT(smfn_type == p2m_ram_shared);
+
+    /* Check that the handles match */
+    if ( spage->shared_info->handle != sh )
+        goto err_unlock;
+
+    /* Make sure the target page is a hole in the physmap */
+    if ( mfn_valid(cmfn) ||
+         (!(p2m_is_ram(cmfn_type))) )
+    {
+        ret = XEN_DOMCTL_MEM_SHARING_C_HANDLE_INVALID;
+        goto err_unlock;
+    }
+
+    /* This is simpler than regular sharing */
+    BUG_ON(!get_page_and_type(spage, dom_cow, PGT_shared_page));
+    if ( (gfn_info = mem_sharing_gfn_alloc(spage, cd, cgfn)) == NULL )
+    {
+        put_page_and_type(spage);
+        ret = -ENOMEM;
+        goto err_unlock;
+    }
+
+    ret = set_p2m_entry(p2m, cgfn, smfn, PAGE_ORDER_4K, p2m_ram_shared, a);
+
+    /* Tempted to turn this into an assert */
+    if ( !ret ) {
+        ret = -ENOENT;
+        mem_sharing_gfn_destroy(gfn_info, 0);
+        put_page_and_type(spage);
+    } else {
+        atomic_inc(&cd->shr_pages);
+        atomic_inc(&nr_shared_mfns);
+        ret = 0;
+    }
+
+err_unlock:
+    mem_sharing_page_unlock(spage);
+err_out:
+    put_gfn(cd, cgfn);
+    put_gfn(sd, sgfn);
+    p2m_unlock(p2m);
+    shr_unlock();
+    return ret;
+}
+
 int mem_sharing_unshare_page(struct domain *d,
                              unsigned long gfn, 
                              uint16_t flags)
@@ -982,6 +1052,42 @@ int mem_sharing_domctl(struct domain *d,
         }
         break;
 
+        case XEN_DOMCTL_MEM_EVENT_OP_SHARING_ADD_PHYSMAP:
+        {
+            unsigned long sgfn, cgfn;
+            struct domain *cd;
+            shr_handle_t sh;
+
+            if ( !mem_sharing_enabled(d) )
+                return -EINVAL;
+
+            cd = get_domain_by_id(mec->u.share.client_domain);
+            if ( !cd )
+                return -ESRCH;
+
+            if ( !mem_sharing_enabled(cd) )
+            {
+                put_domain(cd);
+                return -EINVAL;
+            }
+
+            if ( XEN_DOMCTL_MEM_SHARING_FIELD_IS_GREF(mec->u.share.source_gfn) )
+            {
+                /* Cannot add a gref to the physmap */
+                put_domain(cd);
+                return -EINVAL;
+            }
+
+            sgfn    = mec->u.share.source_gfn;
+            sh      = mec->u.share.source_handle;
+            cgfn    = mec->u.share.client_gfn;
+
+            rc = mem_sharing_add_to_physmap(d, sgfn, sh, cd, cgfn); 
+
+            put_domain(cd);
+        }
+        break;
+
         case XEN_DOMCTL_MEM_EVENT_OP_SHARING_RESUME:
         {
             if ( !mem_sharing_enabled(d) )
diff -r 62ea5c05ae7b -r b8be3a08e628 xen/include/public/domctl.h
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -771,6 +771,7 @@ DEFINE_XEN_GUEST_HANDLE(xen_domctl_mem_e
 #define XEN_DOMCTL_MEM_EVENT_OP_SHARING_DEBUG_GFN      5
 #define XEN_DOMCTL_MEM_EVENT_OP_SHARING_DEBUG_MFN      6
 #define XEN_DOMCTL_MEM_EVENT_OP_SHARING_DEBUG_GREF     7
+#define XEN_DOMCTL_MEM_EVENT_OP_SHARING_ADD_PHYSMAP    8
 
 #define XEN_DOMCTL_MEM_SHARING_S_HANDLE_INVALID  (-10)
 #define XEN_DOMCTL_MEM_SHARING_C_HANDLE_INVALID  (-9)
@@ -797,7 +798,7 @@ struct xen_domctl_mem_sharing_op {
             } u;
             uint64_aligned_t  handle;     /* OUT: the handle           */
         } nominate;
-        struct mem_sharing_op_share {     /* OP_SHARE */
+        struct mem_sharing_op_share {     /* OP_SHARE/ADD_PHYSMAP */
             uint64_aligned_t source_gfn;    /* IN: the gfn of the source page */
             uint64_aligned_t source_handle; /* IN: handle to the source page */
             uint64_aligned_t client_domain; /* IN: the client domain id */

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 08 13:55:31 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 Dec 2011 13:55:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYeRE-0005UQ-KU; Thu, 08 Dec 2011 13:55:04 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RYeRC-0005UD-Sf
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 13:55:03 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-4.tower-27.messagelabs.com!1323352426!51636324!1
X-Originating-IP: [208.97.132.83]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi44MyA9PiAxNTk2Mw==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4196 invoked from network); 8 Dec 2011 13:53:47 -0000
Received: from caiajhbdcaid.dreamhost.com (HELO homiemail-a23.g.dreamhost.com)
	(208.97.132.83) by server-4.tower-27.messagelabs.com with SMTP;
	8 Dec 2011 13:53:47 -0000
Received: from homiemail-a23.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a23.g.dreamhost.com (Postfix) with ESMTP id BD1E94B0089;
	Thu,  8 Dec 2011 05:54:18 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=Czy+ml4bO2be+wegbvVHL7XRb8vu8vwPCh2+OfIc+YNn
	puzEYTAVE8rjozZGBxVTQBCl+F5cTKSKfs3ikdr0xhnnqBmrRudfTcQdd4cE99ck
	0AnQDdirMNAQXVGYCYuDQlXQFVdJjW/IsaenZrXfunK69ZIalBIxQYoRSH2voHI=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=thGltmpzny9vbmUltDfwatdi2Jw=; b=jM47lRQpNBS
	b0ohwPBsLfymQfV75domkSbpQrkGmRZhVQw+3n+AEOPANjkAWEt5i1MCmmEtOBYb
	yNVSl1/Z0Pq9JEqADDbNe0JFjY2FkRnLKCzoPIsjjJ6TJQ4mkmfJ/DTfQd+z7ttE
	KRjangxRCs7j32+kFJrQDglpEFoKudJs=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a23.g.dreamhost.com (Postfix) with ESMTPSA id D3F3C4B0062; 
	Thu,  8 Dec 2011 05:54:17 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: a79bb54cb4dc76b33e61d9e8966a35586da8be6c
Message-Id: <a79bb54cb4dc76b33e61.1323352480@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1323352476@xdev.gridcentric.ca>
References: <patchbomb.1323352476@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Thu, 08 Dec 2011 08:54:40 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: ian.campbell@citrix.com, andres@gridcentric.ca, tim@xen.org,
	keir.xen@gmail.com, JBeulich@suse.com, ian.jackson@citrix.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 4 of 5] Adds a separate domctl for performing
	sharing audits
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/mm/mem_sharing.c |  17 ++++++++++++-----
 xen/include/public/domctl.h   |   1 +
 2 files changed, 13 insertions(+), 5 deletions(-)


Sharing audits are heavyweight, so instead of performing them inline,
we make them callable via a domctl.

Signed-off-by: Adin Scannell <adin@scannell.ca>

diff -r 536da18b7ab6 -r a79bb54cb4dc xen/arch/x86/mm/mem_sharing.c
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -820,7 +820,6 @@ int mem_sharing_unshare_page(struct doma
      * between shr_lock and p2m fine-grained locks in mm-lock. 
      * Callers may walk in here already holding the lock for this gfn */
     shr_lock();
-    mem_sharing_audit();
     mfn = get_gfn(d, gfn, &p2mt);
     
     /* Has someone already unshared it? */
@@ -1117,15 +1116,23 @@ int mem_sharing_domctl(struct domain *d,
         }
         break;
 
+        case XEN_DOMCTL_MEM_EVENT_OP_SHARING_AUDIT:
+        {
+#if MEM_SHARING_AUDIT
+            shr_lock();
+            rc = mem_sharing_audit();
+            shr_unlock();
+#else
+            rc = -ENOSYS;
+#endif
+            break;
+        }
+
         default:
             rc = -ENOSYS;
             break;
     }
 
-    shr_lock();
-    mem_sharing_audit();
-    shr_unlock();
-
     return rc;
 }
 
diff -r 536da18b7ab6 -r a79bb54cb4dc xen/include/public/domctl.h
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -772,6 +772,7 @@ DEFINE_XEN_GUEST_HANDLE(xen_domctl_mem_e
 #define XEN_DOMCTL_MEM_EVENT_OP_SHARING_DEBUG_MFN      6
 #define XEN_DOMCTL_MEM_EVENT_OP_SHARING_DEBUG_GREF     7
 #define XEN_DOMCTL_MEM_EVENT_OP_SHARING_ADD_PHYSMAP    8
+#define XEN_DOMCTL_MEM_EVENT_OP_SHARING_AUDIT          9
 
 #define XEN_DOMCTL_MEM_SHARING_S_HANDLE_INVALID  (-10)
 #define XEN_DOMCTL_MEM_SHARING_C_HANDLE_INVALID  (-9)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 08 13:55:31 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 Dec 2011 13:55:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYeRE-0005UQ-KU; Thu, 08 Dec 2011 13:55:04 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RYeRC-0005UD-Sf
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 13:55:03 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-4.tower-27.messagelabs.com!1323352426!51636324!1
X-Originating-IP: [208.97.132.83]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi44MyA9PiAxNTk2Mw==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4196 invoked from network); 8 Dec 2011 13:53:47 -0000
Received: from caiajhbdcaid.dreamhost.com (HELO homiemail-a23.g.dreamhost.com)
	(208.97.132.83) by server-4.tower-27.messagelabs.com with SMTP;
	8 Dec 2011 13:53:47 -0000
Received: from homiemail-a23.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a23.g.dreamhost.com (Postfix) with ESMTP id BD1E94B0089;
	Thu,  8 Dec 2011 05:54:18 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=Czy+ml4bO2be+wegbvVHL7XRb8vu8vwPCh2+OfIc+YNn
	puzEYTAVE8rjozZGBxVTQBCl+F5cTKSKfs3ikdr0xhnnqBmrRudfTcQdd4cE99ck
	0AnQDdirMNAQXVGYCYuDQlXQFVdJjW/IsaenZrXfunK69ZIalBIxQYoRSH2voHI=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=thGltmpzny9vbmUltDfwatdi2Jw=; b=jM47lRQpNBS
	b0ohwPBsLfymQfV75domkSbpQrkGmRZhVQw+3n+AEOPANjkAWEt5i1MCmmEtOBYb
	yNVSl1/Z0Pq9JEqADDbNe0JFjY2FkRnLKCzoPIsjjJ6TJQ4mkmfJ/DTfQd+z7ttE
	KRjangxRCs7j32+kFJrQDglpEFoKudJs=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a23.g.dreamhost.com (Postfix) with ESMTPSA id D3F3C4B0062; 
	Thu,  8 Dec 2011 05:54:17 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: a79bb54cb4dc76b33e61d9e8966a35586da8be6c
Message-Id: <a79bb54cb4dc76b33e61.1323352480@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1323352476@xdev.gridcentric.ca>
References: <patchbomb.1323352476@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Thu, 08 Dec 2011 08:54:40 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: ian.campbell@citrix.com, andres@gridcentric.ca, tim@xen.org,
	keir.xen@gmail.com, JBeulich@suse.com, ian.jackson@citrix.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 4 of 5] Adds a separate domctl for performing
	sharing audits
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/mm/mem_sharing.c |  17 ++++++++++++-----
 xen/include/public/domctl.h   |   1 +
 2 files changed, 13 insertions(+), 5 deletions(-)


Sharing audits are heavyweight, so instead of performing them inline,
we make them callable via a domctl.

Signed-off-by: Adin Scannell <adin@scannell.ca>

diff -r 536da18b7ab6 -r a79bb54cb4dc xen/arch/x86/mm/mem_sharing.c
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -820,7 +820,6 @@ int mem_sharing_unshare_page(struct doma
      * between shr_lock and p2m fine-grained locks in mm-lock. 
      * Callers may walk in here already holding the lock for this gfn */
     shr_lock();
-    mem_sharing_audit();
     mfn = get_gfn(d, gfn, &p2mt);
     
     /* Has someone already unshared it? */
@@ -1117,15 +1116,23 @@ int mem_sharing_domctl(struct domain *d,
         }
         break;
 
+        case XEN_DOMCTL_MEM_EVENT_OP_SHARING_AUDIT:
+        {
+#if MEM_SHARING_AUDIT
+            shr_lock();
+            rc = mem_sharing_audit();
+            shr_unlock();
+#else
+            rc = -ENOSYS;
+#endif
+            break;
+        }
+
         default:
             rc = -ENOSYS;
             break;
     }
 
-    shr_lock();
-    mem_sharing_audit();
-    shr_unlock();
-
     return rc;
 }
 
diff -r 536da18b7ab6 -r a79bb54cb4dc xen/include/public/domctl.h
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -772,6 +772,7 @@ DEFINE_XEN_GUEST_HANDLE(xen_domctl_mem_e
 #define XEN_DOMCTL_MEM_EVENT_OP_SHARING_DEBUG_MFN      6
 #define XEN_DOMCTL_MEM_EVENT_OP_SHARING_DEBUG_GREF     7
 #define XEN_DOMCTL_MEM_EVENT_OP_SHARING_ADD_PHYSMAP    8
+#define XEN_DOMCTL_MEM_EVENT_OP_SHARING_AUDIT          9
 
 #define XEN_DOMCTL_MEM_SHARING_S_HANDLE_INVALID  (-10)
 #define XEN_DOMCTL_MEM_SHARING_C_HANDLE_INVALID  (-9)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 08 13:55:31 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 Dec 2011 13:55:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYeRJ-0005Vb-At; Thu, 08 Dec 2011 13:55:09 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RYeRH-0005UC-5p
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 13:55:07 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-6.tower-216.messagelabs.com!1323352457!6658074!1
X-Originating-IP: [208.97.132.66]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi42NiA9PiAxNTcxMg==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22168 invoked from network); 8 Dec 2011 13:54:18 -0000
Received: from caiajhbdcagg.dreamhost.com (HELO homiemail-a23.g.dreamhost.com)
	(208.97.132.66) by server-6.tower-216.messagelabs.com with SMTP;
	8 Dec 2011 13:54:18 -0000
Received: from homiemail-a23.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a23.g.dreamhost.com (Postfix) with ESMTP id 9764B4B0099;
	Thu,  8 Dec 2011 05:54:17 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=mdOaWsCmD4qNXqga4A2tBtNKOEBaY8WMeqiR22mWka5L
	BO6RVM/SaJ7vVqtXKZJNgbsK5CgqkuCLIGcMG7iKCNXd1GgV6PfqG0ElnFStfZFC
	kwY/0BhhD0da+kdbhiFhhU5pZ8b99CKIPjRrPFMHketspW56agc/2J+322Fn7So=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=6AMFBU/7fwmC33FHWIzorHBvkrg=; b=OBLLtkGBpSu
	9j8jEQMPqw1QgJ/MrcTGeWf8nJW/1s4hQu2IYL81O1NhSZ43eB6WOWkENs+ZqKZv
	s6EguYFUlDnK1HSSTIffrrzSOIUUByaVbC6NiPWPiaYq1nukPPVt0Ipj2NQLKePP
	8dVZ0GMr2RYvB+3j6J02RKVHnvKWnadU=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a23.g.dreamhost.com (Postfix) with ESMTPSA id A12844B0062; 
	Thu,  8 Dec 2011 05:54:16 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 536da18b7ab6e46d9dfa7890bb6bf71dfe151133
Message-Id: <536da18b7ab6e46d9dfa.1323352479@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1323352476@xdev.gridcentric.ca>
References: <patchbomb.1323352476@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Thu, 08 Dec 2011 08:54:39 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: ian.campbell@citrix.com, andres@gridcentric.ca, tim@xen.org,
	keir.xen@gmail.com, JBeulich@suse.com, ian.jackson@citrix.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 3 of 5] Add the ability to poll stats about
 shared memory via the console
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/ia64/xen/mm.c        |  6 ++++++
 xen/arch/x86/mm/mem_sharing.c |  8 ++++++++
 xen/common/keyhandler.c       |  7 +++++--
 xen/include/xen/mm.h          |  3 +++
 4 files changed, 22 insertions(+), 2 deletions(-)


Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 14f08673af6a -r 536da18b7ab6 xen/arch/ia64/xen/mm.c
--- a/xen/arch/ia64/xen/mm.c
+++ b/xen/arch/ia64/xen/mm.c
@@ -3565,6 +3565,12 @@ p2m_pod_decrease_reservation(struct doma
     return 0;
 }
 
+/* Simple no-op */
+void arch_dump_shared_mem_info(void)
+{
+    printk("Shared memory not supported yet\n");
+}
+
 /*
  * Local variables:
  * mode: C
diff -r 14f08673af6a -r 536da18b7ab6 xen/arch/x86/mm/mem_sharing.c
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -1129,6 +1129,14 @@ int mem_sharing_domctl(struct domain *d,
     return rc;
 }
 
+void arch_dump_shared_mem_info(void)
+{
+    printk("Shared pages %u -- Saved frames %u -- Dom CoW footprintf %u\n",
+            mem_sharing_get_nr_shared_mfns(),
+            mem_sharing_get_nr_saved_mfns(),
+            dom_cow->tot_pages);
+}
+
 void __init mem_sharing_init(void)
 {
     printk("Initing memory sharing.\n");
diff -r 14f08673af6a -r 536da18b7ab6 xen/common/keyhandler.c
--- a/xen/common/keyhandler.c
+++ b/xen/common/keyhandler.c
@@ -15,6 +15,7 @@
 #include <xen/compat.h>
 #include <xen/ctype.h>
 #include <xen/perfc.h>
+#include <xen/mm.h>
 #include <asm/debugger.h>
 #include <asm/div64.h>
 
@@ -248,8 +249,8 @@ static void dump_domains(unsigned char k
         printk("    refcnt=%d dying=%d pause_count=%d\n",
                atomic_read(&d->refcnt), d->is_dying,
                atomic_read(&d->pause_count));
-        printk("    nr_pages=%d xenheap_pages=%d dirty_cpus=%s max_pages=%u\n",
-               d->tot_pages, d->xenheap_pages, tmpstr, d->max_pages);
+        printk("    nr_pages=%d xenheap_pages=%d shared_pages=%u dirty_cpus=%s max_pages=%u\n",
+               d->tot_pages, d->xenheap_pages, atomic_read(&d->shr_pages), tmpstr, d->max_pages);
         printk("    handle=%02x%02x%02x%02x-%02x%02x-%02x%02x-"
                "%02x%02x-%02x%02x%02x%02x%02x%02x vm_assist=%08lx\n",
                d->handle[ 0], d->handle[ 1], d->handle[ 2], d->handle[ 3],
@@ -308,6 +309,8 @@ static void dump_domains(unsigned char k
         }
     }
 
+    arch_dump_shared_mem_info();
+
     rcu_read_unlock(&domlist_read_lock);
 #undef tmpstr
 }
diff -r 14f08673af6a -r 536da18b7ab6 xen/include/xen/mm.h
--- a/xen/include/xen/mm.h
+++ b/xen/include/xen/mm.h
@@ -73,6 +73,9 @@ int assign_pages(
     unsigned int order,
     unsigned int memflags);
 
+/* Dump info to serial console */
+void arch_dump_shared_mem_info(void);
+
 /* memflags: */
 #define _MEMF_no_refcount 0
 #define  MEMF_no_refcount (1U<<_MEMF_no_refcount)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 08 13:55:31 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 Dec 2011 13:55:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYeRJ-0005Vb-At; Thu, 08 Dec 2011 13:55:09 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RYeRH-0005UC-5p
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 13:55:07 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-6.tower-216.messagelabs.com!1323352457!6658074!1
X-Originating-IP: [208.97.132.66]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi42NiA9PiAxNTcxMg==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22168 invoked from network); 8 Dec 2011 13:54:18 -0000
Received: from caiajhbdcagg.dreamhost.com (HELO homiemail-a23.g.dreamhost.com)
	(208.97.132.66) by server-6.tower-216.messagelabs.com with SMTP;
	8 Dec 2011 13:54:18 -0000
Received: from homiemail-a23.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a23.g.dreamhost.com (Postfix) with ESMTP id 9764B4B0099;
	Thu,  8 Dec 2011 05:54:17 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=mdOaWsCmD4qNXqga4A2tBtNKOEBaY8WMeqiR22mWka5L
	BO6RVM/SaJ7vVqtXKZJNgbsK5CgqkuCLIGcMG7iKCNXd1GgV6PfqG0ElnFStfZFC
	kwY/0BhhD0da+kdbhiFhhU5pZ8b99CKIPjRrPFMHketspW56agc/2J+322Fn7So=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=6AMFBU/7fwmC33FHWIzorHBvkrg=; b=OBLLtkGBpSu
	9j8jEQMPqw1QgJ/MrcTGeWf8nJW/1s4hQu2IYL81O1NhSZ43eB6WOWkENs+ZqKZv
	s6EguYFUlDnK1HSSTIffrrzSOIUUByaVbC6NiPWPiaYq1nukPPVt0Ipj2NQLKePP
	8dVZ0GMr2RYvB+3j6J02RKVHnvKWnadU=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a23.g.dreamhost.com (Postfix) with ESMTPSA id A12844B0062; 
	Thu,  8 Dec 2011 05:54:16 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 536da18b7ab6e46d9dfa7890bb6bf71dfe151133
Message-Id: <536da18b7ab6e46d9dfa.1323352479@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1323352476@xdev.gridcentric.ca>
References: <patchbomb.1323352476@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Thu, 08 Dec 2011 08:54:39 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: ian.campbell@citrix.com, andres@gridcentric.ca, tim@xen.org,
	keir.xen@gmail.com, JBeulich@suse.com, ian.jackson@citrix.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 3 of 5] Add the ability to poll stats about
 shared memory via the console
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/ia64/xen/mm.c        |  6 ++++++
 xen/arch/x86/mm/mem_sharing.c |  8 ++++++++
 xen/common/keyhandler.c       |  7 +++++--
 xen/include/xen/mm.h          |  3 +++
 4 files changed, 22 insertions(+), 2 deletions(-)


Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 14f08673af6a -r 536da18b7ab6 xen/arch/ia64/xen/mm.c
--- a/xen/arch/ia64/xen/mm.c
+++ b/xen/arch/ia64/xen/mm.c
@@ -3565,6 +3565,12 @@ p2m_pod_decrease_reservation(struct doma
     return 0;
 }
 
+/* Simple no-op */
+void arch_dump_shared_mem_info(void)
+{
+    printk("Shared memory not supported yet\n");
+}
+
 /*
  * Local variables:
  * mode: C
diff -r 14f08673af6a -r 536da18b7ab6 xen/arch/x86/mm/mem_sharing.c
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -1129,6 +1129,14 @@ int mem_sharing_domctl(struct domain *d,
     return rc;
 }
 
+void arch_dump_shared_mem_info(void)
+{
+    printk("Shared pages %u -- Saved frames %u -- Dom CoW footprintf %u\n",
+            mem_sharing_get_nr_shared_mfns(),
+            mem_sharing_get_nr_saved_mfns(),
+            dom_cow->tot_pages);
+}
+
 void __init mem_sharing_init(void)
 {
     printk("Initing memory sharing.\n");
diff -r 14f08673af6a -r 536da18b7ab6 xen/common/keyhandler.c
--- a/xen/common/keyhandler.c
+++ b/xen/common/keyhandler.c
@@ -15,6 +15,7 @@
 #include <xen/compat.h>
 #include <xen/ctype.h>
 #include <xen/perfc.h>
+#include <xen/mm.h>
 #include <asm/debugger.h>
 #include <asm/div64.h>
 
@@ -248,8 +249,8 @@ static void dump_domains(unsigned char k
         printk("    refcnt=%d dying=%d pause_count=%d\n",
                atomic_read(&d->refcnt), d->is_dying,
                atomic_read(&d->pause_count));
-        printk("    nr_pages=%d xenheap_pages=%d dirty_cpus=%s max_pages=%u\n",
-               d->tot_pages, d->xenheap_pages, tmpstr, d->max_pages);
+        printk("    nr_pages=%d xenheap_pages=%d shared_pages=%u dirty_cpus=%s max_pages=%u\n",
+               d->tot_pages, d->xenheap_pages, atomic_read(&d->shr_pages), tmpstr, d->max_pages);
         printk("    handle=%02x%02x%02x%02x-%02x%02x-%02x%02x-"
                "%02x%02x-%02x%02x%02x%02x%02x%02x vm_assist=%08lx\n",
                d->handle[ 0], d->handle[ 1], d->handle[ 2], d->handle[ 3],
@@ -308,6 +309,8 @@ static void dump_domains(unsigned char k
         }
     }
 
+    arch_dump_shared_mem_info();
+
     rcu_read_unlock(&domlist_read_lock);
 #undef tmpstr
 }
diff -r 14f08673af6a -r 536da18b7ab6 xen/include/xen/mm.h
--- a/xen/include/xen/mm.h
+++ b/xen/include/xen/mm.h
@@ -73,6 +73,9 @@ int assign_pages(
     unsigned int order,
     unsigned int memflags);
 
+/* Dump info to serial console */
+void arch_dump_shared_mem_info(void);
+
 /* memflags: */
 #define _MEMF_no_refcount 0
 #define  MEMF_no_refcount (1U<<_MEMF_no_refcount)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 08 13:55:32 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 Dec 2011 13: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.xensource.com>)
	id 1RYeRJ-0005Vk-Ns; Thu, 08 Dec 2011 13:55:09 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RYeRI-0005UJ-N6
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 13:55:08 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-11.tower-216.messagelabs.com!1323352460!6612689!1
X-Originating-IP: [208.97.132.119]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xMTkgPT4gMTYwMzU=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32494 invoked from network); 8 Dec 2011 13:54:20 -0000
Received: from caiajhbdcbbj.dreamhost.com (HELO homiemail-a23.g.dreamhost.com)
	(208.97.132.119) by server-11.tower-216.messagelabs.com with SMTP;
	8 Dec 2011 13:54:20 -0000
Received: from homiemail-a23.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a23.g.dreamhost.com (Postfix) with ESMTP id D85514B0097;
	Thu,  8 Dec 2011 05:54:19 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=gZuo0k0qeqQYXnQHBP4wMQIzu/H0ELY7ynZLvSuGTH2X
	kqAXj4tBexBFPmmND8/S5FTZJIg8Jkqondaaf5WFArVsHI60x0e15MOfRoHMFYt9
	6RYseyqGLDMXOrXiqn7kFaJc7/eT0znrNOda20x8GBmdzxgW+bzykrqz3Zdi6lo=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=Yn42qwaFMkImcQDbAaW1N02XU08=; b=KShUjaZIBD6
	gECmy3px5TA6YZysnhUwLjzPcPNgJs9U0lv4sDzDBR8P6A2/JhqXrKRekERjBffz
	zjDiefNbGiat0F0SklTowGfjtcPzCOMUpuSPuVRQK1GucakaFljtKOq1bUSAlbUD
	cixb6q6hUUlIMvZsBG7mLaYc7J4iA91Y=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a23.g.dreamhost.com (Postfix) with ESMTPSA id E85BE4B0062; 
	Thu,  8 Dec 2011 05:54:18 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 6da10b1102042c2ebd33282da8f472620d8d400e
Message-Id: <6da10b1102042c2ebd33.1323352481@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1323352476@xdev.gridcentric.ca>
References: <patchbomb.1323352476@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Thu, 08 Dec 2011 08:54:41 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: ian.campbell@citrix.com, andres@gridcentric.ca, tim@xen.org,
	keir.xen@gmail.com, JBeulich@suse.com, ian.jackson@citrix.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 5 of 5] Tools: Libxc wrapper for the new sharing
	audit domctl
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 tools/libxc/xc_memshr.c |  14 ++++++++++++++
 tools/libxc/xenctrl.h   |   2 ++
 2 files changed, 16 insertions(+), 0 deletions(-)


Signed-off-by: Adin Scannell <adin@scannell.ca>

diff -r a79bb54cb4dc -r 6da10b110204 tools/libxc/xc_memshr.c
--- a/tools/libxc/xc_memshr.c
+++ b/tools/libxc/xc_memshr.c
@@ -211,3 +211,17 @@ int xc_memshr_debug_gref(xc_interface *x
     return do_domctl(xch, &domctl);
 }
 
+int xc_memshr_audit(xc_interface *xch,
+                    uint32_t domid)
+{
+    DECLARE_DOMCTL;
+    struct xen_domctl_mem_sharing_op *op;
+
+    domctl.cmd = XEN_DOMCTL_mem_sharing_op;
+    domctl.interface_version = XEN_DOMCTL_INTERFACE_VERSION;
+    domctl.domain = (domid_t)domid;
+    op = &(domctl.u.mem_sharing_op);
+    op->op = XEN_DOMCTL_MEM_EVENT_OP_SHARING_AUDIT;
+
+    return do_domctl(xch, &domctl);
+}
diff -r a79bb54cb4dc -r 6da10b110204 tools/libxc/xenctrl.h
--- a/tools/libxc/xenctrl.h
+++ b/tools/libxc/xenctrl.h
@@ -1921,6 +1921,8 @@ int xc_memshr_debug_mfn(xc_interface *xc
 int xc_memshr_debug_gref(xc_interface *xch,
                          uint32_t domid,
                          grant_ref_t gref);
+int xc_memshr_audit(xc_interface *xch,
+                    uint32_t domid);
 
 int xc_flask_load(xc_interface *xc_handle, char *buf, uint32_t size);
 int xc_flask_context_to_sid(xc_interface *xc_handle, char *buf, uint32_t size, uint32_t *sid);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 08 13:55:32 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 Dec 2011 13: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.xensource.com>)
	id 1RYeRE-0005UX-W5; Thu, 08 Dec 2011 13:55:04 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RYeRD-0005U0-Bn
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 13:55:03 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-10.tower-216.messagelabs.com!1323352454!6574669!1
X-Originating-IP: [208.97.132.83]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi44MyA9PiAxNTk2Mw==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8490 invoked from network); 8 Dec 2011 13:54:14 -0000
Received: from caiajhbdcaid.dreamhost.com (HELO homiemail-a23.g.dreamhost.com)
	(208.97.132.83) by server-10.tower-216.messagelabs.com with SMTP;
	8 Dec 2011 13:54:14 -0000
Received: from homiemail-a23.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a23.g.dreamhost.com (Postfix) with ESMTP id 02EEA4B0090;
	Thu,  8 Dec 2011 05:54:14 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id:date
	:from:to:cc; q=dns; s=lagarcavilla.org; b=jwS7KkBSpZhYZVhEvmoMx3
	8esFVd8MPmRIzGumATh+L+FDYYcHMpAFogNw/8rU4RwfvScLX2Gc5ZmbXNOkgxzi
	nyIKXybLXzo8lYy9Cgn4PXkv6B+L6RG6CtG0PRO6iozf0WCQgVnBorrNyDIxrV9z
	siqTDulnGggiTf0lWmXOw=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:date:from:to:cc; s=lagarcavilla.org; bh=fH98PXK3rO/7
	UoG8/5+Cpp3fUyA=; b=di+3x6+MAC9uVPQzztp7z3yhGsLTc1Y855zucpJ/OGUK
	cUI0cVCy4s5uLWSKEs0wtMkO28NhLIKkHMV0Y988l7J19ALhMhor4jjjn/XN8F5+
	mtK/RWIGzoNfbWxWO6GN1iJQWq3SZI9hivCFs60qtJuY7lGQPDELZAlEQCO/ic4=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a23.g.dreamhost.com (Postfix) with ESMTPSA id EF22A4B0062; 
	Thu,  8 Dec 2011 05:54:12 -0800 (PST)
MIME-Version: 1.0
Message-Id: <patchbomb.1323352476@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Thu, 08 Dec 2011 08:54:36 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: ian.campbell@citrix.com, andres@gridcentric.ca, tim@xen.org,
	keir.xen@gmail.com, JBeulich@suse.com, ian.jackson@citrix.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 0 of 5] Memory sharing overhaul part 2
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

(Sigh, the previous pachbomb got truncated by an smtp quota in my 
provider... remaining patches in this series)

This patch series proposes an overhaul of the memory sharing code.

Aside from bug fixes and cleanups, the main features are:
- Polling of stats via libxc, libxl and console
- Removal of global sharing hashtable and global sharing lock 
(if audit disabled)
- Turned sharing audits into a domctl
- New domctl to populate vacant physmap entries with shared 
pages.

As a result, the domctl interface to sharing changes. The only in-tree
consumer of this interface is updated in the current series. It is 
important that if any out-of-tree consumer exists, that they state
their opinion on this interface change.

Patches 5 to 8, 10, 11, 15 and 18 are tools patches.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Signed-off-by: Adin Scannell <adin@scannell.ca>

 xen/arch/x86/mm/mem_sharing.c |  106 ++++++++++++++++++++++++++++++++++++++++++
 xen/include/public/domctl.h   |    3 +-
 tools/libxc/xc_memshr.c       |   23 +++++++++
 tools/libxc/xenctrl.h         |    6 ++
 xen/arch/ia64/xen/mm.c        |    6 ++
 xen/arch/x86/mm/mem_sharing.c |    8 +++
 xen/common/keyhandler.c       |    7 +-
 xen/include/xen/mm.h          |    3 +
 xen/arch/x86/mm/mem_sharing.c |   17 ++++-
 xen/include/public/domctl.h   |    1 +
 tools/libxc/xc_memshr.c       |   14 +++++
 tools/libxc/xenctrl.h         |    2 +
 12 files changed, 188 insertions(+), 8 deletions(-)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 08 13:55:32 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 Dec 2011 13: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.xensource.com>)
	id 1RYeRJ-0005Vk-Ns; Thu, 08 Dec 2011 13:55:09 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RYeRI-0005UJ-N6
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 13:55:08 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-11.tower-216.messagelabs.com!1323352460!6612689!1
X-Originating-IP: [208.97.132.119]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xMTkgPT4gMTYwMzU=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32494 invoked from network); 8 Dec 2011 13:54:20 -0000
Received: from caiajhbdcbbj.dreamhost.com (HELO homiemail-a23.g.dreamhost.com)
	(208.97.132.119) by server-11.tower-216.messagelabs.com with SMTP;
	8 Dec 2011 13:54:20 -0000
Received: from homiemail-a23.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a23.g.dreamhost.com (Postfix) with ESMTP id D85514B0097;
	Thu,  8 Dec 2011 05:54:19 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=gZuo0k0qeqQYXnQHBP4wMQIzu/H0ELY7ynZLvSuGTH2X
	kqAXj4tBexBFPmmND8/S5FTZJIg8Jkqondaaf5WFArVsHI60x0e15MOfRoHMFYt9
	6RYseyqGLDMXOrXiqn7kFaJc7/eT0znrNOda20x8GBmdzxgW+bzykrqz3Zdi6lo=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=Yn42qwaFMkImcQDbAaW1N02XU08=; b=KShUjaZIBD6
	gECmy3px5TA6YZysnhUwLjzPcPNgJs9U0lv4sDzDBR8P6A2/JhqXrKRekERjBffz
	zjDiefNbGiat0F0SklTowGfjtcPzCOMUpuSPuVRQK1GucakaFljtKOq1bUSAlbUD
	cixb6q6hUUlIMvZsBG7mLaYc7J4iA91Y=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a23.g.dreamhost.com (Postfix) with ESMTPSA id E85BE4B0062; 
	Thu,  8 Dec 2011 05:54:18 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 6da10b1102042c2ebd33282da8f472620d8d400e
Message-Id: <6da10b1102042c2ebd33.1323352481@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1323352476@xdev.gridcentric.ca>
References: <patchbomb.1323352476@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Thu, 08 Dec 2011 08:54:41 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: ian.campbell@citrix.com, andres@gridcentric.ca, tim@xen.org,
	keir.xen@gmail.com, JBeulich@suse.com, ian.jackson@citrix.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 5 of 5] Tools: Libxc wrapper for the new sharing
	audit domctl
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 tools/libxc/xc_memshr.c |  14 ++++++++++++++
 tools/libxc/xenctrl.h   |   2 ++
 2 files changed, 16 insertions(+), 0 deletions(-)


Signed-off-by: Adin Scannell <adin@scannell.ca>

diff -r a79bb54cb4dc -r 6da10b110204 tools/libxc/xc_memshr.c
--- a/tools/libxc/xc_memshr.c
+++ b/tools/libxc/xc_memshr.c
@@ -211,3 +211,17 @@ int xc_memshr_debug_gref(xc_interface *x
     return do_domctl(xch, &domctl);
 }
 
+int xc_memshr_audit(xc_interface *xch,
+                    uint32_t domid)
+{
+    DECLARE_DOMCTL;
+    struct xen_domctl_mem_sharing_op *op;
+
+    domctl.cmd = XEN_DOMCTL_mem_sharing_op;
+    domctl.interface_version = XEN_DOMCTL_INTERFACE_VERSION;
+    domctl.domain = (domid_t)domid;
+    op = &(domctl.u.mem_sharing_op);
+    op->op = XEN_DOMCTL_MEM_EVENT_OP_SHARING_AUDIT;
+
+    return do_domctl(xch, &domctl);
+}
diff -r a79bb54cb4dc -r 6da10b110204 tools/libxc/xenctrl.h
--- a/tools/libxc/xenctrl.h
+++ b/tools/libxc/xenctrl.h
@@ -1921,6 +1921,8 @@ int xc_memshr_debug_mfn(xc_interface *xc
 int xc_memshr_debug_gref(xc_interface *xch,
                          uint32_t domid,
                          grant_ref_t gref);
+int xc_memshr_audit(xc_interface *xch,
+                    uint32_t domid);
 
 int xc_flask_load(xc_interface *xc_handle, char *buf, uint32_t size);
 int xc_flask_context_to_sid(xc_interface *xc_handle, char *buf, uint32_t size, uint32_t *sid);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 08 13:55:32 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 Dec 2011 13: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.xensource.com>)
	id 1RYeRE-0005UX-W5; Thu, 08 Dec 2011 13:55:04 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RYeRD-0005U0-Bn
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 13:55:03 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-10.tower-216.messagelabs.com!1323352454!6574669!1
X-Originating-IP: [208.97.132.83]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi44MyA9PiAxNTk2Mw==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8490 invoked from network); 8 Dec 2011 13:54:14 -0000
Received: from caiajhbdcaid.dreamhost.com (HELO homiemail-a23.g.dreamhost.com)
	(208.97.132.83) by server-10.tower-216.messagelabs.com with SMTP;
	8 Dec 2011 13:54:14 -0000
Received: from homiemail-a23.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a23.g.dreamhost.com (Postfix) with ESMTP id 02EEA4B0090;
	Thu,  8 Dec 2011 05:54:14 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id:date
	:from:to:cc; q=dns; s=lagarcavilla.org; b=jwS7KkBSpZhYZVhEvmoMx3
	8esFVd8MPmRIzGumATh+L+FDYYcHMpAFogNw/8rU4RwfvScLX2Gc5ZmbXNOkgxzi
	nyIKXybLXzo8lYy9Cgn4PXkv6B+L6RG6CtG0PRO6iozf0WCQgVnBorrNyDIxrV9z
	siqTDulnGggiTf0lWmXOw=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:date:from:to:cc; s=lagarcavilla.org; bh=fH98PXK3rO/7
	UoG8/5+Cpp3fUyA=; b=di+3x6+MAC9uVPQzztp7z3yhGsLTc1Y855zucpJ/OGUK
	cUI0cVCy4s5uLWSKEs0wtMkO28NhLIKkHMV0Y988l7J19ALhMhor4jjjn/XN8F5+
	mtK/RWIGzoNfbWxWO6GN1iJQWq3SZI9hivCFs60qtJuY7lGQPDELZAlEQCO/ic4=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a23.g.dreamhost.com (Postfix) with ESMTPSA id EF22A4B0062; 
	Thu,  8 Dec 2011 05:54:12 -0800 (PST)
MIME-Version: 1.0
Message-Id: <patchbomb.1323352476@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Thu, 08 Dec 2011 08:54:36 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: ian.campbell@citrix.com, andres@gridcentric.ca, tim@xen.org,
	keir.xen@gmail.com, JBeulich@suse.com, ian.jackson@citrix.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 0 of 5] Memory sharing overhaul part 2
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

(Sigh, the previous pachbomb got truncated by an smtp quota in my 
provider... remaining patches in this series)

This patch series proposes an overhaul of the memory sharing code.

Aside from bug fixes and cleanups, the main features are:
- Polling of stats via libxc, libxl and console
- Removal of global sharing hashtable and global sharing lock 
(if audit disabled)
- Turned sharing audits into a domctl
- New domctl to populate vacant physmap entries with shared 
pages.

As a result, the domctl interface to sharing changes. The only in-tree
consumer of this interface is updated in the current series. It is 
important that if any out-of-tree consumer exists, that they state
their opinion on this interface change.

Patches 5 to 8, 10, 11, 15 and 18 are tools patches.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Signed-off-by: Adin Scannell <adin@scannell.ca>

 xen/arch/x86/mm/mem_sharing.c |  106 ++++++++++++++++++++++++++++++++++++++++++
 xen/include/public/domctl.h   |    3 +-
 tools/libxc/xc_memshr.c       |   23 +++++++++
 tools/libxc/xenctrl.h         |    6 ++
 xen/arch/ia64/xen/mm.c        |    6 ++
 xen/arch/x86/mm/mem_sharing.c |    8 +++
 xen/common/keyhandler.c       |    7 +-
 xen/include/xen/mm.h          |    3 +
 xen/arch/x86/mm/mem_sharing.c |   17 ++++-
 xen/include/public/domctl.h   |    1 +
 tools/libxc/xc_memshr.c       |   14 +++++
 tools/libxc/xenctrl.h         |    2 +
 12 files changed, 188 insertions(+), 8 deletions(-)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 08 13:57:22 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 Dec 2011 13: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.xensource.com>)
	id 1RYeTD-0005zj-9u; Thu, 08 Dec 2011 13:57:07 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RYeTB-0005y1-Oz
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 13:57:06 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-11.tower-174.messagelabs.com!1323352576!4773966!1
X-Originating-IP: [208.97.132.177]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNzcgPT4gMTQyMzc=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 823 invoked from network); 8 Dec 2011 13:56:16 -0000
Received: from caiajhbdcbhh.dreamhost.com (HELO homiemail-a22.g.dreamhost.com)
	(208.97.132.177) by server-11.tower-174.messagelabs.com with SMTP;
	8 Dec 2011 13:56:16 -0000
Received: from homiemail-a22.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a22.g.dreamhost.com (Postfix) with ESMTP id DFCD71A808B;
	Thu,  8 Dec 2011 05:56:15 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id:date
	:from:to:cc; q=dns; s=lagarcavilla.org; b=pSE3lI+xUMCrL+hXYV5cqe
	Jxj6Q8h/F1ME5QWthCCBlUFmMzL940fsMidvLJBtG7DmF0IfVtS4GuPjdrcF15uO
	6A4dRip2+Ev1MnV7XZD7enKYvtLrCMnyXy1fA73dIxuvyyFdtCyiQz/QEbHN+r0U
	pWVZcl7Ip5l3xH2GnVJ3k=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:date:from:to:cc; s=lagarcavilla.org; bh=lPd2GOpbZ43N
	mTy9EfyK5cidIwU=; b=jvw6M/AAHuw96hzymdZHd07xeYl4qKpHrO8Rd3gVICr0
	u/gyNyCdhiBSXU1D8y9iqCC7RLxuXEP6vS0uzR2RqgtQHf6U7jUkGmeQ+KdVp6d3
	6JaM18AErR1aN7TDr6BVyff9Qp15zjsDP+CNSYnIA7fUGxGFwc/ED9lZh6ecMmw=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a22.g.dreamhost.com (Postfix) with ESMTPSA id A1E221A8083; 
	Thu,  8 Dec 2011 05:56:14 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 62ea5c05ae7b5f5c70262093c90777fcf439ee6f
Message-Id: <62ea5c05ae7b5f5c7026.1323352652@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Thu, 08 Dec 2011 08:57:32 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: ian.campbell@citrix.com, andres@gridcentric.ca, tim@xen.org,
	keir.xen@gmail.com, JBeulich@suse.com, ian.jackson@citrix.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH] x86/mm: Eliminate global lock in mem sharing
	code
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/mm.c             |   16 +++-
 xen/arch/x86/mm/mem_sharing.c |  169 ++++++++++++++++++++++++++++++++++++-----
 xen/arch/x86/mm/mm-locks.h    |    6 +-
 xen/include/asm-x86/mm.h      |    2 +-
 4 files changed, 163 insertions(+), 30 deletions(-)


With the removal of the hash table, all that is needed now is locking
of individual shared pages, as new (gfn,domain) pairs are removed or
added from the list of mappings.

The global lock remains for the benefit of the auditing code, and is
thus enabled only as a compile-time option.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r ecf95feef9ac -r 62ea5c05ae7b xen/arch/x86/mm.c
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -4337,16 +4337,22 @@ int page_make_sharable(struct domain *d,
     return 0;
 }
 
-int page_make_private(struct domain *d, struct page_info *page)
+int page_make_private(struct domain *d, struct page_info *page,
+                        int unlocked)
 {
+    unsigned long expected_type;
+
     if ( !get_page(page, dom_cow) )
         return -EINVAL;
     
     spin_lock(&d->page_alloc_lock);
 
     /* We can only change the type if count is one */
-    if ( (page->u.inuse.type_info & (PGT_type_mask | PGT_count_mask))
-         != (PGT_shared_page | PGT_validated | 1) )
+    /* If we are locking pages individually, then we need to drop
+     * the lock here, while the page is typed */
+    expected_type = (unlocked) ? (PGT_shared_page | PGT_validated | 1)
+                    : (PGT_shared_page | PGT_validated | PGT_locked | 2);
+    if ( page->u.inuse.type_info != expected_type )
     {
         put_page(page);
         spin_unlock(&d->page_alloc_lock);
@@ -4356,6 +4362,10 @@ int page_make_private(struct domain *d, 
     /* Drop the final typecount */
     put_page_and_type(page);
 
+    if ( !unlocked )
+        /* Now that we've dropped the type, we can unlock */
+        page_unlock(page);
+
     /* Change the owner */
     ASSERT(page_get_owner(page) == dom_cow);
     page_set_owner(page, d);
diff -r ecf95feef9ac -r 62ea5c05ae7b xen/arch/x86/mm/mem_sharing.c
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -35,13 +35,24 @@
 
 #include "mm-locks.h"
 
+static shr_handle_t next_handle = 1;
+
 /* Auditing of memory sharing code? */
 #define MEM_SHARING_AUDIT 0
 
 #if MEM_SHARING_AUDIT
+
+static mm_lock_t shr_lock;
+
+#define shr_lock()          _shr_lock()
+#define shr_unlock()        _shr_unlock()
+#define shr_locked_by_me()  _shr_locked_by_me()
+
 static int mem_sharing_audit(void);
+
 #define MEM_SHARING_DEBUG(_f, _a...)                                  \
     debugtrace_printk("mem_sharing_debug: %s(): " _f, __func__, ##_a)
+
 static struct list_head shr_audit_list;
 
 static inline void audit_add_list(struct page_info *page)
@@ -53,7 +64,21 @@ static inline void audit_del_list(struct
 {
     list_del(&page->shared_info->entry);
 }
+
+static inline int mem_sharing_page_lock(struct page_info *p)
+{
+    return 1;
+}
+#define mem_sharing_page_unlock(p)  ((void)0)
+
+#define get_next_handle()   next_handle++;
 #else
+
+#define shr_lock()          ((void)0)
+#define shr_unlock()        ((void)0)
+/* Only used inside audit code */
+//#define shr_locked_by_me()  ((void)0)
+
 static inline int mem_sharing_audit(void)
 {
     return 0;
@@ -61,6 +86,31 @@ static inline int mem_sharing_audit(void
 
 #define audit_add_list(p)  ((void)0)
 #define audit_del_list(p)  ((void)0)
+
+static inline int mem_sharing_page_lock(struct page_info *pg)
+{
+    int rc = page_lock(pg);
+    if ( rc )
+        preempt_disable();
+    return rc;
+}
+
+static inline void mem_sharing_page_unlock(struct page_info *pg)
+{
+    preempt_enable();
+    page_unlock(pg);
+}
+
+static inline shr_handle_t get_next_handle(void)
+{
+    /* Get the next handle get_page style */ 
+    uint64_t x, y = next_handle;
+    do {
+        x = y;
+    }
+    while ( (y = cmpxchg(&next_handle, x, x + 1)) != x );
+    return x + 1;
+}
 #endif /* MEM_SHARING_AUDIT */
 
 #define mem_sharing_enabled(d) \
@@ -73,7 +123,6 @@ static inline int mem_sharing_audit(void
 #undef page_to_mfn
 #define page_to_mfn(_pg) _mfn(__page_to_mfn(_pg))
 
-static shr_handle_t next_handle = 1;
 static atomic_t nr_saved_mfns   = ATOMIC_INIT(0); 
 static atomic_t nr_shared_mfns  = ATOMIC_INIT(0);
 
@@ -84,8 +133,6 @@ typedef struct gfn_info
     struct list_head list;
 } gfn_info_t;
 
-static mm_lock_t shr_lock;
-
 /* Returns true if list has only one entry. O(1) complexity. */
 static inline int list_has_one_entry(struct list_head *head)
 {
@@ -438,6 +485,28 @@ int mem_sharing_debug_gref(struct domain
     return mem_sharing_debug_gfn(d, gfn); 
 }
 
+static inline struct page_info *__grab_shared_page(mfn_t mfn)
+{
+    struct page_info *pg = NULL;
+
+    if ( !mfn_valid(mfn) )
+        return NULL;
+    pg = mfn_to_page(mfn);
+
+    /* If the page is not validated we can't lock it, and if it's  
+     * not validated it's obviously not shared. */
+    if ( !mem_sharing_page_lock(pg) )
+        return NULL;
+
+    if ( mem_sharing_lookup(mfn_x(mfn)) == NULL )
+    {
+        mem_sharing_page_unlock(pg);
+        return NULL;
+    }
+
+    return pg;
+}
+
 int mem_sharing_nominate_page(struct domain *d,
                               unsigned long gfn,
                               int expected_refcnt,
@@ -445,7 +514,7 @@ int mem_sharing_nominate_page(struct dom
 {
     p2m_type_t p2mt;
     mfn_t mfn;
-    struct page_info *page;
+    struct page_info *page = NULL; /* gcc... */
     int ret;
     struct gfn_info *gfn_info;
 
@@ -460,10 +529,17 @@ int mem_sharing_nominate_page(struct dom
         goto out;
 
     /* Return the handle if the page is already shared */
-    page = mfn_to_page(mfn);
     if ( p2m_is_shared(p2mt) ) {
-        *phandle = page->shared_info->handle;
+        struct page_info *pg = __grab_shared_page(mfn);
+        if ( !pg )
+        {
+            gdprintk(XENLOG_ERR, "Shared p2m entry gfn %lx, but could not "
+                        "grab page %lx dom %d\n", gfn, mfn_x(mfn), d->domain_id);
+            BUG();
+        }
+        *phandle = pg->shared_info->handle;
         ret = 0;
+        mem_sharing_page_unlock(pg);
         goto out;
     }
 
@@ -472,16 +548,25 @@ int mem_sharing_nominate_page(struct dom
         goto out;
 
     /* Try to convert the mfn to the sharable type */
+    page = mfn_to_page(mfn);
     ret = page_make_sharable(d, page, expected_refcnt); 
     if ( ret ) 
         goto out;
 
+    /* Now that the page is typed, we can lock it. There is no race
+     * because we're holding the p2m entry, so no one else could be
+     * nominating this gfn */
+    ret = -ENOENT;
+    if ( !mem_sharing_page_lock(page) )
+        goto out;
+
     /* Initialize the shared state */
     ret = -ENOMEM;
     if ( (page->shared_info = 
             xmalloc(struct page_sharing_info)) == NULL )
     {
-        BUG_ON(page_make_private(d, page) != 0);
+        /* Making a page private atomically unlocks it */
+        BUG_ON(page_make_private(d, page, MEM_SHARING_AUDIT) != 0);
         goto out;
     }
     page->shared_info->pg = page;
@@ -489,14 +574,14 @@ int mem_sharing_nominate_page(struct dom
     INIT_LIST_HEAD(&page->shared_info->entry);
 
     /* Create the handle */
-    page->shared_info->handle = next_handle++;  
+    page->shared_info->handle = get_next_handle();  
 
     /* Create the local gfn info */
     if ( (gfn_info = mem_sharing_gfn_alloc(page, d, gfn)) == NULL )
     {
         xfree(page->shared_info);
         page->shared_info = NULL;
-        BUG_ON(page_make_private(d, page) != 0);
+        BUG_ON(page_make_private(d, page, MEM_SHARING_AUDIT) != 0);
         goto out;
     }
 
@@ -511,7 +596,7 @@ int mem_sharing_nominate_page(struct dom
         xfree(page->shared_info);
         page->shared_info = NULL;
         /* NOTE: We haven't yet added this to the audit list. */
-        BUG_ON(page_make_private(d, page) != 0);
+        BUG_ON(page_make_private(d, page, MEM_SHARING_AUDIT) != 0);
         goto out;
     }
 
@@ -520,6 +605,7 @@ int mem_sharing_nominate_page(struct dom
 
     *phandle = page->shared_info->handle;
     audit_add_list(page);
+    mem_sharing_page_unlock(page);
     ret = 0;
 
 out:
@@ -531,7 +617,7 @@ out:
 int mem_sharing_share_pages(struct domain *sd, unsigned long sgfn, shr_handle_t sh,
                             struct domain *cd, unsigned long cgfn, shr_handle_t ch) 
 {
-    struct page_info *spage, *cpage;
+    struct page_info *spage, *cpage, *firstpg, *secondpg;
     struct list_head *le, *te;
     gfn_info_t *gfn;
     struct domain *d;
@@ -546,26 +632,53 @@ int mem_sharing_share_pages(struct domai
     smfn = get_gfn(sd, sgfn, &smfn_type);
     cmfn = get_gfn(cd, cgfn, &cmfn_type);
 
-    ret = XEN_DOMCTL_MEM_SHARING_S_HANDLE_INVALID;
-    spage = mem_sharing_lookup(mfn_x(smfn));
-    if ( spage == NULL )
-        goto err_out;
+    /* This tricky business is to avoid two callers deadlocking if 
+     * grabbing pages in opposite client/source order */
+    if ( mfn_x(smfn) < mfn_x(cmfn) )
+    {
+        ret = XEN_DOMCTL_MEM_SHARING_S_HANDLE_INVALID;
+        spage = firstpg = __grab_shared_page(smfn);
+        if ( spage == NULL )
+            goto err_out;
+
+        ret = XEN_DOMCTL_MEM_SHARING_C_HANDLE_INVALID;
+        cpage = secondpg = __grab_shared_page(cmfn);
+        if ( cpage == NULL )
+        {
+            mem_sharing_page_unlock(spage);
+            goto err_out;
+        }
+    } else {
+        ret = XEN_DOMCTL_MEM_SHARING_C_HANDLE_INVALID;
+        cpage = firstpg = __grab_shared_page(cmfn);
+        if ( cpage == NULL )
+            goto err_out;
+
+        ret = XEN_DOMCTL_MEM_SHARING_S_HANDLE_INVALID;
+        spage = secondpg = __grab_shared_page(smfn);
+        if ( spage == NULL )
+        {
+            mem_sharing_page_unlock(cpage);
+            goto err_out;
+        }
+    }
+
     ASSERT(smfn_type == p2m_ram_shared);
-    ret = XEN_DOMCTL_MEM_SHARING_C_HANDLE_INVALID;
-    cpage = mem_sharing_lookup(mfn_x(cmfn));
-    if ( cpage == NULL )
-        goto err_out;
     ASSERT(cmfn_type == p2m_ram_shared);
 
     /* Check that the handles match */
     if ( spage->shared_info->handle != sh )
     {
         ret = XEN_DOMCTL_MEM_SHARING_S_HANDLE_INVALID;
+        mem_sharing_page_unlock(secondpg);
+        mem_sharing_page_unlock(firstpg);
         goto err_out;
     }
     if ( cpage->shared_info->handle != ch )
     {
         ret = XEN_DOMCTL_MEM_SHARING_C_HANDLE_INVALID;
+        mem_sharing_page_unlock(secondpg);
+        mem_sharing_page_unlock(firstpg);
         goto err_out;
     }
 
@@ -604,6 +717,9 @@ int mem_sharing_share_pages(struct domai
     xfree(cpage->shared_info);
     cpage->shared_info = NULL;
 
+    mem_sharing_page_unlock(secondpg);
+    mem_sharing_page_unlock(firstpg);
+
     /* Free the client page */
     if(test_and_clear_bit(_PGC_allocated, &cpage->count_info))
         put_page(cpage);
@@ -644,7 +760,7 @@ int mem_sharing_unshare_page(struct doma
         return 0;
     }
 
-    page = mem_sharing_lookup(mfn_x(mfn));
+    page = __grab_shared_page(mfn);
     if ( page == NULL )
     {
         gdprintk(XENLOG_ERR, "Domain p2m is shared, but page is not: "
@@ -688,12 +804,13 @@ gfn_found:
             page->shared_info = NULL;
         }
 
-        put_gfn(d, gfn);
-        shr_unlock();
         put_page_and_type(page);
+        mem_sharing_page_unlock(page);
         if( last_gfn && 
             test_and_clear_bit(_PGC_allocated, &page->count_info)) 
             put_page(page);
+        put_gfn(d, gfn);
+        shr_unlock();
 
         return 0;
     }
@@ -704,7 +821,8 @@ gfn_found:
         mem_sharing_gfn_destroy(gfn_info, !last_gfn);
         xfree(page->shared_info);
         page->shared_info = NULL;
-        BUG_ON(page_make_private(d, page) != 0);
+        /* Making a page private atomically unlocks it */
+        BUG_ON(page_make_private(d, page, MEM_SHARING_AUDIT) != 0);
         goto private_page_found;
     }
         
@@ -712,6 +830,7 @@ gfn_found:
     page = mem_sharing_alloc_page(d, gfn);
     if ( !page ) 
     {
+        mem_sharing_page_unlock(old_page);
         put_gfn(d, gfn);
         shr_unlock();
         return -ENOMEM;
@@ -726,6 +845,7 @@ gfn_found:
     BUG_ON(set_shared_p2m_entry(d, gfn, page_to_mfn(page)) == 0);
     /* We've got a private page, we can commit the gfn destruction */
     mem_sharing_gfn_destroy(gfn_info, !last_gfn);
+    mem_sharing_page_unlock(old_page);
     put_page_and_type(old_page);
 
 private_page_found:    
@@ -749,6 +869,7 @@ private_page_found:
     /* Now that the gfn<->mfn map is properly established,
      * marking dirty is feasible */
     paging_mark_dirty(d, mfn_x(page_to_mfn(page)));
+    /* We do not need to unlock a private page */
     put_gfn(d, gfn);
     shr_unlock();
     return 0;
@@ -905,6 +1026,8 @@ int mem_sharing_domctl(struct domain *d,
 void __init mem_sharing_init(void)
 {
     printk("Initing memory sharing.\n");
+#if MEM_SHARING_AUDIT
     mm_lock_init(&shr_lock);
+#endif
 }
 
diff -r ecf95feef9ac -r 62ea5c05ae7b xen/arch/x86/mm/mm-locks.h
--- a/xen/arch/x86/mm/mm-locks.h
+++ b/xen/arch/x86/mm/mm-locks.h
@@ -147,9 +147,9 @@ static inline void mm_enforce_order_unlo
  * hash tables. */
 
 declare_mm_lock(shr)
-#define shr_lock()         mm_lock(shr, &shr_lock)
-#define shr_unlock()       mm_unlock(&shr_lock)
-#define shr_locked_by_me() mm_locked_by_me(&shr_lock)
+#define _shr_lock()         mm_lock(shr, &shr_lock)
+#define _shr_unlock()       mm_unlock(&shr_lock)
+#define _shr_locked_by_me() mm_locked_by_me(&shr_lock)
 
 /* Nested P2M lock (per-domain)
  *
diff -r ecf95feef9ac -r 62ea5c05ae7b xen/include/asm-x86/mm.h
--- a/xen/include/asm-x86/mm.h
+++ b/xen/include/asm-x86/mm.h
@@ -594,7 +594,7 @@ int donate_page(
 int page_make_sharable(struct domain *d, 
                        struct page_info *page, 
                        int expected_refcnt);
-int page_make_private(struct domain *d, struct page_info *page);
+int page_make_private(struct domain *d, struct page_info *page, int unlocked);
 
 int map_ldt_shadow_page(unsigned int);
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 08 13:57:22 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 Dec 2011 13: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.xensource.com>)
	id 1RYeTD-0005zj-9u; Thu, 08 Dec 2011 13:57:07 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RYeTB-0005y1-Oz
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 13:57:06 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-11.tower-174.messagelabs.com!1323352576!4773966!1
X-Originating-IP: [208.97.132.177]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNzcgPT4gMTQyMzc=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 823 invoked from network); 8 Dec 2011 13:56:16 -0000
Received: from caiajhbdcbhh.dreamhost.com (HELO homiemail-a22.g.dreamhost.com)
	(208.97.132.177) by server-11.tower-174.messagelabs.com with SMTP;
	8 Dec 2011 13:56:16 -0000
Received: from homiemail-a22.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a22.g.dreamhost.com (Postfix) with ESMTP id DFCD71A808B;
	Thu,  8 Dec 2011 05:56:15 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id:date
	:from:to:cc; q=dns; s=lagarcavilla.org; b=pSE3lI+xUMCrL+hXYV5cqe
	Jxj6Q8h/F1ME5QWthCCBlUFmMzL940fsMidvLJBtG7DmF0IfVtS4GuPjdrcF15uO
	6A4dRip2+Ev1MnV7XZD7enKYvtLrCMnyXy1fA73dIxuvyyFdtCyiQz/QEbHN+r0U
	pWVZcl7Ip5l3xH2GnVJ3k=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:date:from:to:cc; s=lagarcavilla.org; bh=lPd2GOpbZ43N
	mTy9EfyK5cidIwU=; b=jvw6M/AAHuw96hzymdZHd07xeYl4qKpHrO8Rd3gVICr0
	u/gyNyCdhiBSXU1D8y9iqCC7RLxuXEP6vS0uzR2RqgtQHf6U7jUkGmeQ+KdVp6d3
	6JaM18AErR1aN7TDr6BVyff9Qp15zjsDP+CNSYnIA7fUGxGFwc/ED9lZh6ecMmw=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a22.g.dreamhost.com (Postfix) with ESMTPSA id A1E221A8083; 
	Thu,  8 Dec 2011 05:56:14 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 62ea5c05ae7b5f5c70262093c90777fcf439ee6f
Message-Id: <62ea5c05ae7b5f5c7026.1323352652@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Thu, 08 Dec 2011 08:57:32 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: ian.campbell@citrix.com, andres@gridcentric.ca, tim@xen.org,
	keir.xen@gmail.com, JBeulich@suse.com, ian.jackson@citrix.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH] x86/mm: Eliminate global lock in mem sharing
	code
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/mm.c             |   16 +++-
 xen/arch/x86/mm/mem_sharing.c |  169 ++++++++++++++++++++++++++++++++++++-----
 xen/arch/x86/mm/mm-locks.h    |    6 +-
 xen/include/asm-x86/mm.h      |    2 +-
 4 files changed, 163 insertions(+), 30 deletions(-)


With the removal of the hash table, all that is needed now is locking
of individual shared pages, as new (gfn,domain) pairs are removed or
added from the list of mappings.

The global lock remains for the benefit of the auditing code, and is
thus enabled only as a compile-time option.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r ecf95feef9ac -r 62ea5c05ae7b xen/arch/x86/mm.c
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -4337,16 +4337,22 @@ int page_make_sharable(struct domain *d,
     return 0;
 }
 
-int page_make_private(struct domain *d, struct page_info *page)
+int page_make_private(struct domain *d, struct page_info *page,
+                        int unlocked)
 {
+    unsigned long expected_type;
+
     if ( !get_page(page, dom_cow) )
         return -EINVAL;
     
     spin_lock(&d->page_alloc_lock);
 
     /* We can only change the type if count is one */
-    if ( (page->u.inuse.type_info & (PGT_type_mask | PGT_count_mask))
-         != (PGT_shared_page | PGT_validated | 1) )
+    /* If we are locking pages individually, then we need to drop
+     * the lock here, while the page is typed */
+    expected_type = (unlocked) ? (PGT_shared_page | PGT_validated | 1)
+                    : (PGT_shared_page | PGT_validated | PGT_locked | 2);
+    if ( page->u.inuse.type_info != expected_type )
     {
         put_page(page);
         spin_unlock(&d->page_alloc_lock);
@@ -4356,6 +4362,10 @@ int page_make_private(struct domain *d, 
     /* Drop the final typecount */
     put_page_and_type(page);
 
+    if ( !unlocked )
+        /* Now that we've dropped the type, we can unlock */
+        page_unlock(page);
+
     /* Change the owner */
     ASSERT(page_get_owner(page) == dom_cow);
     page_set_owner(page, d);
diff -r ecf95feef9ac -r 62ea5c05ae7b xen/arch/x86/mm/mem_sharing.c
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -35,13 +35,24 @@
 
 #include "mm-locks.h"
 
+static shr_handle_t next_handle = 1;
+
 /* Auditing of memory sharing code? */
 #define MEM_SHARING_AUDIT 0
 
 #if MEM_SHARING_AUDIT
+
+static mm_lock_t shr_lock;
+
+#define shr_lock()          _shr_lock()
+#define shr_unlock()        _shr_unlock()
+#define shr_locked_by_me()  _shr_locked_by_me()
+
 static int mem_sharing_audit(void);
+
 #define MEM_SHARING_DEBUG(_f, _a...)                                  \
     debugtrace_printk("mem_sharing_debug: %s(): " _f, __func__, ##_a)
+
 static struct list_head shr_audit_list;
 
 static inline void audit_add_list(struct page_info *page)
@@ -53,7 +64,21 @@ static inline void audit_del_list(struct
 {
     list_del(&page->shared_info->entry);
 }
+
+static inline int mem_sharing_page_lock(struct page_info *p)
+{
+    return 1;
+}
+#define mem_sharing_page_unlock(p)  ((void)0)
+
+#define get_next_handle()   next_handle++;
 #else
+
+#define shr_lock()          ((void)0)
+#define shr_unlock()        ((void)0)
+/* Only used inside audit code */
+//#define shr_locked_by_me()  ((void)0)
+
 static inline int mem_sharing_audit(void)
 {
     return 0;
@@ -61,6 +86,31 @@ static inline int mem_sharing_audit(void
 
 #define audit_add_list(p)  ((void)0)
 #define audit_del_list(p)  ((void)0)
+
+static inline int mem_sharing_page_lock(struct page_info *pg)
+{
+    int rc = page_lock(pg);
+    if ( rc )
+        preempt_disable();
+    return rc;
+}
+
+static inline void mem_sharing_page_unlock(struct page_info *pg)
+{
+    preempt_enable();
+    page_unlock(pg);
+}
+
+static inline shr_handle_t get_next_handle(void)
+{
+    /* Get the next handle get_page style */ 
+    uint64_t x, y = next_handle;
+    do {
+        x = y;
+    }
+    while ( (y = cmpxchg(&next_handle, x, x + 1)) != x );
+    return x + 1;
+}
 #endif /* MEM_SHARING_AUDIT */
 
 #define mem_sharing_enabled(d) \
@@ -73,7 +123,6 @@ static inline int mem_sharing_audit(void
 #undef page_to_mfn
 #define page_to_mfn(_pg) _mfn(__page_to_mfn(_pg))
 
-static shr_handle_t next_handle = 1;
 static atomic_t nr_saved_mfns   = ATOMIC_INIT(0); 
 static atomic_t nr_shared_mfns  = ATOMIC_INIT(0);
 
@@ -84,8 +133,6 @@ typedef struct gfn_info
     struct list_head list;
 } gfn_info_t;
 
-static mm_lock_t shr_lock;
-
 /* Returns true if list has only one entry. O(1) complexity. */
 static inline int list_has_one_entry(struct list_head *head)
 {
@@ -438,6 +485,28 @@ int mem_sharing_debug_gref(struct domain
     return mem_sharing_debug_gfn(d, gfn); 
 }
 
+static inline struct page_info *__grab_shared_page(mfn_t mfn)
+{
+    struct page_info *pg = NULL;
+
+    if ( !mfn_valid(mfn) )
+        return NULL;
+    pg = mfn_to_page(mfn);
+
+    /* If the page is not validated we can't lock it, and if it's  
+     * not validated it's obviously not shared. */
+    if ( !mem_sharing_page_lock(pg) )
+        return NULL;
+
+    if ( mem_sharing_lookup(mfn_x(mfn)) == NULL )
+    {
+        mem_sharing_page_unlock(pg);
+        return NULL;
+    }
+
+    return pg;
+}
+
 int mem_sharing_nominate_page(struct domain *d,
                               unsigned long gfn,
                               int expected_refcnt,
@@ -445,7 +514,7 @@ int mem_sharing_nominate_page(struct dom
 {
     p2m_type_t p2mt;
     mfn_t mfn;
-    struct page_info *page;
+    struct page_info *page = NULL; /* gcc... */
     int ret;
     struct gfn_info *gfn_info;
 
@@ -460,10 +529,17 @@ int mem_sharing_nominate_page(struct dom
         goto out;
 
     /* Return the handle if the page is already shared */
-    page = mfn_to_page(mfn);
     if ( p2m_is_shared(p2mt) ) {
-        *phandle = page->shared_info->handle;
+        struct page_info *pg = __grab_shared_page(mfn);
+        if ( !pg )
+        {
+            gdprintk(XENLOG_ERR, "Shared p2m entry gfn %lx, but could not "
+                        "grab page %lx dom %d\n", gfn, mfn_x(mfn), d->domain_id);
+            BUG();
+        }
+        *phandle = pg->shared_info->handle;
         ret = 0;
+        mem_sharing_page_unlock(pg);
         goto out;
     }
 
@@ -472,16 +548,25 @@ int mem_sharing_nominate_page(struct dom
         goto out;
 
     /* Try to convert the mfn to the sharable type */
+    page = mfn_to_page(mfn);
     ret = page_make_sharable(d, page, expected_refcnt); 
     if ( ret ) 
         goto out;
 
+    /* Now that the page is typed, we can lock it. There is no race
+     * because we're holding the p2m entry, so no one else could be
+     * nominating this gfn */
+    ret = -ENOENT;
+    if ( !mem_sharing_page_lock(page) )
+        goto out;
+
     /* Initialize the shared state */
     ret = -ENOMEM;
     if ( (page->shared_info = 
             xmalloc(struct page_sharing_info)) == NULL )
     {
-        BUG_ON(page_make_private(d, page) != 0);
+        /* Making a page private atomically unlocks it */
+        BUG_ON(page_make_private(d, page, MEM_SHARING_AUDIT) != 0);
         goto out;
     }
     page->shared_info->pg = page;
@@ -489,14 +574,14 @@ int mem_sharing_nominate_page(struct dom
     INIT_LIST_HEAD(&page->shared_info->entry);
 
     /* Create the handle */
-    page->shared_info->handle = next_handle++;  
+    page->shared_info->handle = get_next_handle();  
 
     /* Create the local gfn info */
     if ( (gfn_info = mem_sharing_gfn_alloc(page, d, gfn)) == NULL )
     {
         xfree(page->shared_info);
         page->shared_info = NULL;
-        BUG_ON(page_make_private(d, page) != 0);
+        BUG_ON(page_make_private(d, page, MEM_SHARING_AUDIT) != 0);
         goto out;
     }
 
@@ -511,7 +596,7 @@ int mem_sharing_nominate_page(struct dom
         xfree(page->shared_info);
         page->shared_info = NULL;
         /* NOTE: We haven't yet added this to the audit list. */
-        BUG_ON(page_make_private(d, page) != 0);
+        BUG_ON(page_make_private(d, page, MEM_SHARING_AUDIT) != 0);
         goto out;
     }
 
@@ -520,6 +605,7 @@ int mem_sharing_nominate_page(struct dom
 
     *phandle = page->shared_info->handle;
     audit_add_list(page);
+    mem_sharing_page_unlock(page);
     ret = 0;
 
 out:
@@ -531,7 +617,7 @@ out:
 int mem_sharing_share_pages(struct domain *sd, unsigned long sgfn, shr_handle_t sh,
                             struct domain *cd, unsigned long cgfn, shr_handle_t ch) 
 {
-    struct page_info *spage, *cpage;
+    struct page_info *spage, *cpage, *firstpg, *secondpg;
     struct list_head *le, *te;
     gfn_info_t *gfn;
     struct domain *d;
@@ -546,26 +632,53 @@ int mem_sharing_share_pages(struct domai
     smfn = get_gfn(sd, sgfn, &smfn_type);
     cmfn = get_gfn(cd, cgfn, &cmfn_type);
 
-    ret = XEN_DOMCTL_MEM_SHARING_S_HANDLE_INVALID;
-    spage = mem_sharing_lookup(mfn_x(smfn));
-    if ( spage == NULL )
-        goto err_out;
+    /* This tricky business is to avoid two callers deadlocking if 
+     * grabbing pages in opposite client/source order */
+    if ( mfn_x(smfn) < mfn_x(cmfn) )
+    {
+        ret = XEN_DOMCTL_MEM_SHARING_S_HANDLE_INVALID;
+        spage = firstpg = __grab_shared_page(smfn);
+        if ( spage == NULL )
+            goto err_out;
+
+        ret = XEN_DOMCTL_MEM_SHARING_C_HANDLE_INVALID;
+        cpage = secondpg = __grab_shared_page(cmfn);
+        if ( cpage == NULL )
+        {
+            mem_sharing_page_unlock(spage);
+            goto err_out;
+        }
+    } else {
+        ret = XEN_DOMCTL_MEM_SHARING_C_HANDLE_INVALID;
+        cpage = firstpg = __grab_shared_page(cmfn);
+        if ( cpage == NULL )
+            goto err_out;
+
+        ret = XEN_DOMCTL_MEM_SHARING_S_HANDLE_INVALID;
+        spage = secondpg = __grab_shared_page(smfn);
+        if ( spage == NULL )
+        {
+            mem_sharing_page_unlock(cpage);
+            goto err_out;
+        }
+    }
+
     ASSERT(smfn_type == p2m_ram_shared);
-    ret = XEN_DOMCTL_MEM_SHARING_C_HANDLE_INVALID;
-    cpage = mem_sharing_lookup(mfn_x(cmfn));
-    if ( cpage == NULL )
-        goto err_out;
     ASSERT(cmfn_type == p2m_ram_shared);
 
     /* Check that the handles match */
     if ( spage->shared_info->handle != sh )
     {
         ret = XEN_DOMCTL_MEM_SHARING_S_HANDLE_INVALID;
+        mem_sharing_page_unlock(secondpg);
+        mem_sharing_page_unlock(firstpg);
         goto err_out;
     }
     if ( cpage->shared_info->handle != ch )
     {
         ret = XEN_DOMCTL_MEM_SHARING_C_HANDLE_INVALID;
+        mem_sharing_page_unlock(secondpg);
+        mem_sharing_page_unlock(firstpg);
         goto err_out;
     }
 
@@ -604,6 +717,9 @@ int mem_sharing_share_pages(struct domai
     xfree(cpage->shared_info);
     cpage->shared_info = NULL;
 
+    mem_sharing_page_unlock(secondpg);
+    mem_sharing_page_unlock(firstpg);
+
     /* Free the client page */
     if(test_and_clear_bit(_PGC_allocated, &cpage->count_info))
         put_page(cpage);
@@ -644,7 +760,7 @@ int mem_sharing_unshare_page(struct doma
         return 0;
     }
 
-    page = mem_sharing_lookup(mfn_x(mfn));
+    page = __grab_shared_page(mfn);
     if ( page == NULL )
     {
         gdprintk(XENLOG_ERR, "Domain p2m is shared, but page is not: "
@@ -688,12 +804,13 @@ gfn_found:
             page->shared_info = NULL;
         }
 
-        put_gfn(d, gfn);
-        shr_unlock();
         put_page_and_type(page);
+        mem_sharing_page_unlock(page);
         if( last_gfn && 
             test_and_clear_bit(_PGC_allocated, &page->count_info)) 
             put_page(page);
+        put_gfn(d, gfn);
+        shr_unlock();
 
         return 0;
     }
@@ -704,7 +821,8 @@ gfn_found:
         mem_sharing_gfn_destroy(gfn_info, !last_gfn);
         xfree(page->shared_info);
         page->shared_info = NULL;
-        BUG_ON(page_make_private(d, page) != 0);
+        /* Making a page private atomically unlocks it */
+        BUG_ON(page_make_private(d, page, MEM_SHARING_AUDIT) != 0);
         goto private_page_found;
     }
         
@@ -712,6 +830,7 @@ gfn_found:
     page = mem_sharing_alloc_page(d, gfn);
     if ( !page ) 
     {
+        mem_sharing_page_unlock(old_page);
         put_gfn(d, gfn);
         shr_unlock();
         return -ENOMEM;
@@ -726,6 +845,7 @@ gfn_found:
     BUG_ON(set_shared_p2m_entry(d, gfn, page_to_mfn(page)) == 0);
     /* We've got a private page, we can commit the gfn destruction */
     mem_sharing_gfn_destroy(gfn_info, !last_gfn);
+    mem_sharing_page_unlock(old_page);
     put_page_and_type(old_page);
 
 private_page_found:    
@@ -749,6 +869,7 @@ private_page_found:
     /* Now that the gfn<->mfn map is properly established,
      * marking dirty is feasible */
     paging_mark_dirty(d, mfn_x(page_to_mfn(page)));
+    /* We do not need to unlock a private page */
     put_gfn(d, gfn);
     shr_unlock();
     return 0;
@@ -905,6 +1026,8 @@ int mem_sharing_domctl(struct domain *d,
 void __init mem_sharing_init(void)
 {
     printk("Initing memory sharing.\n");
+#if MEM_SHARING_AUDIT
     mm_lock_init(&shr_lock);
+#endif
 }
 
diff -r ecf95feef9ac -r 62ea5c05ae7b xen/arch/x86/mm/mm-locks.h
--- a/xen/arch/x86/mm/mm-locks.h
+++ b/xen/arch/x86/mm/mm-locks.h
@@ -147,9 +147,9 @@ static inline void mm_enforce_order_unlo
  * hash tables. */
 
 declare_mm_lock(shr)
-#define shr_lock()         mm_lock(shr, &shr_lock)
-#define shr_unlock()       mm_unlock(&shr_lock)
-#define shr_locked_by_me() mm_locked_by_me(&shr_lock)
+#define _shr_lock()         mm_lock(shr, &shr_lock)
+#define _shr_unlock()       mm_unlock(&shr_lock)
+#define _shr_locked_by_me() mm_locked_by_me(&shr_lock)
 
 /* Nested P2M lock (per-domain)
  *
diff -r ecf95feef9ac -r 62ea5c05ae7b xen/include/asm-x86/mm.h
--- a/xen/include/asm-x86/mm.h
+++ b/xen/include/asm-x86/mm.h
@@ -594,7 +594,7 @@ int donate_page(
 int page_make_sharable(struct domain *d, 
                        struct page_info *page, 
                        int expected_refcnt);
-int page_make_private(struct domain *d, struct page_info *page);
+int page_make_private(struct domain *d, struct page_info *page, int unlocked);
 
 int map_ldt_shadow_page(unsigned int);
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 08 14:40:18 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 Dec 2011 14:40:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYf8a-0006tB-7O; Thu, 08 Dec 2011 14:39:52 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RYf8Y-0006t6-LM
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 14:39:50 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-3.tower-182.messagelabs.com!1323355141!6447052!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11818 invoked from network); 8 Dec 2011 14:39:01 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-3.tower-182.messagelabs.com with SMTP;
	8 Dec 2011 14:39:01 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea01.nsa.gov (8.12.10/8.12.10) with ESMTP id
	pB8Ed0Aa029648
	for <xen-devel@lists.xensource.com>; Thu, 8 Dec 2011 14:39:00 GMT
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id pB8EcxDL003258
	for <xen-devel@lists.xensource.com>; Thu, 8 Dec 2011 09:39:00 -0500
Message-ID: <4EE0CC19.8040905@tycho.nsa.gov>
Date: Thu, 08 Dec 2011 09:39:21 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:7.0.1) Gecko/20110930 Thunderbird/7.0.1
MIME-Version: 1.0
To: xen-devel <xen-devel@lists.xensource.com>
X-Enigmail-Version: 1.3.2
Subject: [Xen-devel] memory map issues with PV PCI passthrough
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

I have a system with several reserved ranges low in the e820 map which
cause problems when starting PV domains with PCI devices. The machine
memory map looks like:

(XEN)  0000000000000000 - 0000000000060000 (usable)
(XEN)  0000000000060000 - 0000000000068000 (reserved)
(XEN)  0000000000068000 - 000000000009ac00 (usable)
(XEN)  000000000009ac00 - 00000000000a0000 (reserved)
(XEN)  00000000000e0000 - 0000000000100000 (reserved)
(XEN)  0000000000100000 - 0000000000800000 (usable)
(XEN)  0000000000800000 - 000000000087d000 (unusable)
(XEN)  000000000087d000 - 0000000000f00000 (usable)
(XEN)  0000000000f00000 - 0000000001000000 (reserved)
(XEN)  0000000001000000 - 0000000020000000 (usable)
(XEN)  0000000020000000 - 0000000020200000 (reserved)
(XEN)  0000000020200000 - 0000000040000000 (usable)
(XEN)  0000000040000000 - 0000000040200000 (reserved)
(XEN)  0000000040200000 - 00000000c95d6000 (usable)
(XEN)  00000000c95d6000 - 00000000c961a000 (reserved)
(XEN)  00000000c961a000 - 00000000c99b7000 (usable)
(XEN)  00000000c99b7000 - 00000000c99e7000 (reserved)
(XEN)  00000000c99e7000 - 00000000c9be7000 (ACPI NVS)
(XEN)  00000000c9be7000 - 00000000c9bff000 (ACPI data)
(XEN)  00000000c9bff000 - 00000000c9c00000 (usable)
(XEN)  00000000c9f00000 - 00000000ca000000 (reserved)
(XEN)  00000000cb000000 - 00000000cf200000 (reserved)
(XEN)  00000000fed1c000 - 00000000fed30000 (reserved)
(XEN)  00000000ffc00000 - 00000000ffc20000 (reserved)
(XEN)  0000000100000000 - 000000042e000000 (usable)

When e820_sanitize is called on this memory map to create a PV domain, the
resulting map has only one usable region (0-0xf00000) below 4GB, and Linux
will not boot with this memory map.

I have a patch that reworks e820_sanitize to include later RAM regions as
valid RAM, which works as long as the domain being booted has permission
to map the PFNs from 0x20000-0x20200 and 0x40000-0x40200. If the domain is
not given this permission (the default, since these regions are not part of
the PCI device being passed to the guest) then the hypervisor crashes the
domain when it attempts to map these regions (during init_memory_mapping).

The domain will boot when these regions are not marked as reserved in the
e820 map or when the PFNs 0x20200-0x40000 and 0x40200-0xc95d6 are marked
as unusable. However, it is difficult to make this happen in any general
case without knowing what reserved regions actually need to be marked as
reserved in the guest.

If PCI hot-add is not needed, the problem becomes simpler: the PCI regions
for assigned devices can be included in the e820 map and other regions can
be ignored (marking as RAM so that the guest does not attempt direct map).

Any suggestions on the best way to resolve this?

-- 
Daniel De Graaf
National Security Agency

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 08 14:40:18 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 Dec 2011 14:40:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYf8a-0006tB-7O; Thu, 08 Dec 2011 14:39:52 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RYf8Y-0006t6-LM
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 14:39:50 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-3.tower-182.messagelabs.com!1323355141!6447052!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11818 invoked from network); 8 Dec 2011 14:39:01 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-3.tower-182.messagelabs.com with SMTP;
	8 Dec 2011 14:39:01 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea01.nsa.gov (8.12.10/8.12.10) with ESMTP id
	pB8Ed0Aa029648
	for <xen-devel@lists.xensource.com>; Thu, 8 Dec 2011 14:39:00 GMT
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id pB8EcxDL003258
	for <xen-devel@lists.xensource.com>; Thu, 8 Dec 2011 09:39:00 -0500
Message-ID: <4EE0CC19.8040905@tycho.nsa.gov>
Date: Thu, 08 Dec 2011 09:39:21 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:7.0.1) Gecko/20110930 Thunderbird/7.0.1
MIME-Version: 1.0
To: xen-devel <xen-devel@lists.xensource.com>
X-Enigmail-Version: 1.3.2
Subject: [Xen-devel] memory map issues with PV PCI passthrough
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

I have a system with several reserved ranges low in the e820 map which
cause problems when starting PV domains with PCI devices. The machine
memory map looks like:

(XEN)  0000000000000000 - 0000000000060000 (usable)
(XEN)  0000000000060000 - 0000000000068000 (reserved)
(XEN)  0000000000068000 - 000000000009ac00 (usable)
(XEN)  000000000009ac00 - 00000000000a0000 (reserved)
(XEN)  00000000000e0000 - 0000000000100000 (reserved)
(XEN)  0000000000100000 - 0000000000800000 (usable)
(XEN)  0000000000800000 - 000000000087d000 (unusable)
(XEN)  000000000087d000 - 0000000000f00000 (usable)
(XEN)  0000000000f00000 - 0000000001000000 (reserved)
(XEN)  0000000001000000 - 0000000020000000 (usable)
(XEN)  0000000020000000 - 0000000020200000 (reserved)
(XEN)  0000000020200000 - 0000000040000000 (usable)
(XEN)  0000000040000000 - 0000000040200000 (reserved)
(XEN)  0000000040200000 - 00000000c95d6000 (usable)
(XEN)  00000000c95d6000 - 00000000c961a000 (reserved)
(XEN)  00000000c961a000 - 00000000c99b7000 (usable)
(XEN)  00000000c99b7000 - 00000000c99e7000 (reserved)
(XEN)  00000000c99e7000 - 00000000c9be7000 (ACPI NVS)
(XEN)  00000000c9be7000 - 00000000c9bff000 (ACPI data)
(XEN)  00000000c9bff000 - 00000000c9c00000 (usable)
(XEN)  00000000c9f00000 - 00000000ca000000 (reserved)
(XEN)  00000000cb000000 - 00000000cf200000 (reserved)
(XEN)  00000000fed1c000 - 00000000fed30000 (reserved)
(XEN)  00000000ffc00000 - 00000000ffc20000 (reserved)
(XEN)  0000000100000000 - 000000042e000000 (usable)

When e820_sanitize is called on this memory map to create a PV domain, the
resulting map has only one usable region (0-0xf00000) below 4GB, and Linux
will not boot with this memory map.

I have a patch that reworks e820_sanitize to include later RAM regions as
valid RAM, which works as long as the domain being booted has permission
to map the PFNs from 0x20000-0x20200 and 0x40000-0x40200. If the domain is
not given this permission (the default, since these regions are not part of
the PCI device being passed to the guest) then the hypervisor crashes the
domain when it attempts to map these regions (during init_memory_mapping).

The domain will boot when these regions are not marked as reserved in the
e820 map or when the PFNs 0x20200-0x40000 and 0x40200-0xc95d6 are marked
as unusable. However, it is difficult to make this happen in any general
case without knowing what reserved regions actually need to be marked as
reserved in the guest.

If PCI hot-add is not needed, the problem becomes simpler: the PCI regions
for assigned devices can be included in the e820 map and other regions can
be ignored (marking as RAM so that the guest does not attempt direct map).

Any suggestions on the best way to resolve this?

-- 
Daniel De Graaf
National Security Agency

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 08 14:40:54 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 Dec 2011 14: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.xensource.com>)
	id 1RYf9B-0006ub-Ku; Thu, 08 Dec 2011 14:40:29 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RYf9A-0006uG-AH
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 14:40:28 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1323355180!7438709!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM1NDY=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18208 invoked from network); 8 Dec 2011 14:39:40 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-15.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 8 Dec 2011 14:39:40 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 08 Dec 2011 14:39:39 +0000
Message-Id: <4EE0DA64020000780006638F@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 08 Dec 2011 14:40:20 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
References: <patchbomb.1323352476@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1323352476@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com, ian.campbell@citrix.com,
	andres@gridcentric.ca, tim@xen.org, keir.xen@gmail.com,
	ian.jackson@citrix.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 0 of 5] Memory sharing overhaul part 2
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 08.12.11 at 14:54, Andres Lagar-Cavilla <andres@lagarcavilla.org> wrote:
>...
>  xen/arch/x86/mm/mem_sharing.c |  106 ++++++++++++++++++++++++++++++++++++++++++
>  xen/include/public/domctl.h   |    3 +-
>  tools/libxc/xc_memshr.c       |   23 +++++++++
>  tools/libxc/xenctrl.h         |    6 ++
>  xen/arch/ia64/xen/mm.c        |    6 ++
>  xen/arch/x86/mm/mem_sharing.c |    8 +++
>  xen/common/keyhandler.c       |    7 +-
>  xen/include/xen/mm.h          |    3 +
>  xen/arch/x86/mm/mem_sharing.c |   17 ++++-
>  xen/include/public/domctl.h   |    1 +
>  tools/libxc/xc_memshr.c       |   14 +++++
>  tools/libxc/xenctrl.h         |    2 +
>  12 files changed, 188 insertions(+), 8 deletions(-)

As this isn't the first time with your patch submissions - I'm not sure what
you use to generate these stats, but in order to be useful I would
generally expect this to be a list with duplicate entries folded rather than
a mere concatenation of those from the individual patches (leaving doing
the arithmetic to the reader/reviewer).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 08 14:40:54 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 Dec 2011 14: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.xensource.com>)
	id 1RYf9B-0006ub-Ku; Thu, 08 Dec 2011 14:40:29 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RYf9A-0006uG-AH
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 14:40:28 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1323355180!7438709!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM1NDY=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18208 invoked from network); 8 Dec 2011 14:39:40 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-15.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 8 Dec 2011 14:39:40 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 08 Dec 2011 14:39:39 +0000
Message-Id: <4EE0DA64020000780006638F@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 08 Dec 2011 14:40:20 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
References: <patchbomb.1323352476@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1323352476@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com, ian.campbell@citrix.com,
	andres@gridcentric.ca, tim@xen.org, keir.xen@gmail.com,
	ian.jackson@citrix.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 0 of 5] Memory sharing overhaul part 2
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 08.12.11 at 14:54, Andres Lagar-Cavilla <andres@lagarcavilla.org> wrote:
>...
>  xen/arch/x86/mm/mem_sharing.c |  106 ++++++++++++++++++++++++++++++++++++++++++
>  xen/include/public/domctl.h   |    3 +-
>  tools/libxc/xc_memshr.c       |   23 +++++++++
>  tools/libxc/xenctrl.h         |    6 ++
>  xen/arch/ia64/xen/mm.c        |    6 ++
>  xen/arch/x86/mm/mem_sharing.c |    8 +++
>  xen/common/keyhandler.c       |    7 +-
>  xen/include/xen/mm.h          |    3 +
>  xen/arch/x86/mm/mem_sharing.c |   17 ++++-
>  xen/include/public/domctl.h   |    1 +
>  tools/libxc/xc_memshr.c       |   14 +++++
>  tools/libxc/xenctrl.h         |    2 +
>  12 files changed, 188 insertions(+), 8 deletions(-)

As this isn't the first time with your patch submissions - I'm not sure what
you use to generate these stats, but in order to be useful I would
generally expect this to be a list with duplicate entries folded rather than
a mere concatenation of those from the individual patches (leaving doing
the arithmetic to the reader/reviewer).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 08 14:46:41 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 Dec 2011 14:46:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYfEm-0007Cf-Er; Thu, 08 Dec 2011 14:46:16 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RYfEk-0007Ca-Rg
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 14:46:15 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1323355526!4781860!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM1NDY=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21170 invoked from network); 8 Dec 2011 14:45:26 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-11.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 8 Dec 2011 14:45:26 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 08 Dec 2011 14:45:25 +0000
Message-Id: <4EE0DBBE02000078000663B1@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 08 Dec 2011 14:46:06 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
References: <patchbomb.1323352476@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1323352476@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com, ian.campbell@citrix.com,
	andres@gridcentric.ca, tim@xen.org, keir.xen@gmail.com,
	ian.jackson@citrix.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 0 of 5] Memory sharing overhaul part 2
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 08.12.11 at 14:54, Andres Lagar-Cavilla <andres@lagarcavilla.org> wrote:
> (Sigh, the previous pachbomb got truncated by an smtp quota in my 
> provider... remaining patches in this series)

But you also didn't re-write the description for this shorter series:

> This patch series proposes an overhaul of the memory sharing code.
> 
> Aside from bug fixes and cleanups, the main features are:

I wasn't able to spot any bug fixes or cleanups, and apart from
patch 3 all others merely add dead code. I'm therefore tempted to
nak 1, 2, 4, and 5 unless you come forward with code that actually
uses these new bits.

> - Polling of stats via libxc, libxl and console
> - Removal of global sharing hashtable and global sharing lock 
> (if audit disabled)
> - Turned sharing audits into a domctl
> - New domctl to populate vacant physmap entries with shared 
> pages.
> 
> As a result, the domctl interface to sharing changes. The only in-tree
> consumer of this interface is updated in the current series. It is 
> important that if any out-of-tree consumer exists, that they state
> their opinion on this interface change.
> 
> Patches 5 to 8, 10, 11, 15 and 18 are tools patches.

There's no patch 8 and higher here.

Jan



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 08 14:46:41 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 Dec 2011 14:46:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYfEm-0007Cf-Er; Thu, 08 Dec 2011 14:46:16 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RYfEk-0007Ca-Rg
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 14:46:15 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1323355526!4781860!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM1NDY=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21170 invoked from network); 8 Dec 2011 14:45:26 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-11.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 8 Dec 2011 14:45:26 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 08 Dec 2011 14:45:25 +0000
Message-Id: <4EE0DBBE02000078000663B1@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 08 Dec 2011 14:46:06 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
References: <patchbomb.1323352476@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1323352476@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com, ian.campbell@citrix.com,
	andres@gridcentric.ca, tim@xen.org, keir.xen@gmail.com,
	ian.jackson@citrix.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 0 of 5] Memory sharing overhaul part 2
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 08.12.11 at 14:54, Andres Lagar-Cavilla <andres@lagarcavilla.org> wrote:
> (Sigh, the previous pachbomb got truncated by an smtp quota in my 
> provider... remaining patches in this series)

But you also didn't re-write the description for this shorter series:

> This patch series proposes an overhaul of the memory sharing code.
> 
> Aside from bug fixes and cleanups, the main features are:

I wasn't able to spot any bug fixes or cleanups, and apart from
patch 3 all others merely add dead code. I'm therefore tempted to
nak 1, 2, 4, and 5 unless you come forward with code that actually
uses these new bits.

> - Polling of stats via libxc, libxl and console
> - Removal of global sharing hashtable and global sharing lock 
> (if audit disabled)
> - Turned sharing audits into a domctl
> - New domctl to populate vacant physmap entries with shared 
> pages.
> 
> As a result, the domctl interface to sharing changes. The only in-tree
> consumer of this interface is updated in the current series. It is 
> important that if any out-of-tree consumer exists, that they state
> their opinion on this interface change.
> 
> Patches 5 to 8, 10, 11, 15 and 18 are tools patches.

There's no patch 8 and higher here.

Jan



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 08 14:48:12 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 Dec 2011 14:48:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYfGK-0007JK-Uk; Thu, 08 Dec 2011 14:47:52 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RYfGI-0007JE-Th
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 14:47:51 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1323355586!48219919!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDg5NQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13428 invoked from network); 8 Dec 2011 14:46:26 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Dec 2011 14:46:26 -0000
X-IronPort-AV: E=Sophos;i="4.71,320,1320624000"; 
   d="scan'208";a="9365495"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Dec 2011 14:47:04 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 8 Dec 2011
	14:47:04 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Date: Thu, 8 Dec 2011 14:47:04 +0000
In-Reply-To: <4EE0CC19.8040905@tycho.nsa.gov>
References: <4EE0CC19.8040905@tycho.nsa.gov>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323355624.12878.1.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] memory map issues with PV PCI passthrough
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2011-12-08 at 14:39 +0000, Daniel De Graaf wrote:
> I have a system with several reserved ranges low in the e820 map which
> cause problems when starting PV domains with PCI devices. The machine
> memory map looks like:
> 
> (XEN)  0000000000000000 - 0000000000060000 (usable)
> (XEN)  0000000000060000 - 0000000000068000 (reserved)
> (XEN)  0000000000068000 - 000000000009ac00 (usable)
> (XEN)  000000000009ac00 - 00000000000a0000 (reserved)
> (XEN)  00000000000e0000 - 0000000000100000 (reserved)
> (XEN)  0000000000100000 - 0000000000800000 (usable)
> (XEN)  0000000000800000 - 000000000087d000 (unusable)
> (XEN)  000000000087d000 - 0000000000f00000 (usable)
> (XEN)  0000000000f00000 - 0000000001000000 (reserved)
> (XEN)  0000000001000000 - 0000000020000000 (usable)
> (XEN)  0000000020000000 - 0000000020200000 (reserved)
> (XEN)  0000000020200000 - 0000000040000000 (usable)
> (XEN)  0000000040000000 - 0000000040200000 (reserved)
> (XEN)  0000000040200000 - 00000000c95d6000 (usable)
> (XEN)  00000000c95d6000 - 00000000c961a000 (reserved)
> (XEN)  00000000c961a000 - 00000000c99b7000 (usable)
> (XEN)  00000000c99b7000 - 00000000c99e7000 (reserved)
> (XEN)  00000000c99e7000 - 00000000c9be7000 (ACPI NVS)
> (XEN)  00000000c9be7000 - 00000000c9bff000 (ACPI data)
> (XEN)  00000000c9bff000 - 00000000c9c00000 (usable)
> (XEN)  00000000c9f00000 - 00000000ca000000 (reserved)
> (XEN)  00000000cb000000 - 00000000cf200000 (reserved)
> (XEN)  00000000fed1c000 - 00000000fed30000 (reserved)
> (XEN)  00000000ffc00000 - 00000000ffc20000 (reserved)
> (XEN)  0000000100000000 - 000000042e000000 (usable)
> 
> When e820_sanitize is called on this memory map to create a PV domain, the
> resulting map has only one usable region (0-0xf00000) below 4GB, and Linux
> will not boot with this memory map.

Are you using xl's e820_host option?

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 08 14:48:12 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 Dec 2011 14:48:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYfGK-0007JK-Uk; Thu, 08 Dec 2011 14:47:52 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RYfGI-0007JE-Th
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 14:47:51 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1323355586!48219919!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDg5NQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13428 invoked from network); 8 Dec 2011 14:46:26 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Dec 2011 14:46:26 -0000
X-IronPort-AV: E=Sophos;i="4.71,320,1320624000"; 
   d="scan'208";a="9365495"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Dec 2011 14:47:04 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 8 Dec 2011
	14:47:04 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Date: Thu, 8 Dec 2011 14:47:04 +0000
In-Reply-To: <4EE0CC19.8040905@tycho.nsa.gov>
References: <4EE0CC19.8040905@tycho.nsa.gov>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323355624.12878.1.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] memory map issues with PV PCI passthrough
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2011-12-08 at 14:39 +0000, Daniel De Graaf wrote:
> I have a system with several reserved ranges low in the e820 map which
> cause problems when starting PV domains with PCI devices. The machine
> memory map looks like:
> 
> (XEN)  0000000000000000 - 0000000000060000 (usable)
> (XEN)  0000000000060000 - 0000000000068000 (reserved)
> (XEN)  0000000000068000 - 000000000009ac00 (usable)
> (XEN)  000000000009ac00 - 00000000000a0000 (reserved)
> (XEN)  00000000000e0000 - 0000000000100000 (reserved)
> (XEN)  0000000000100000 - 0000000000800000 (usable)
> (XEN)  0000000000800000 - 000000000087d000 (unusable)
> (XEN)  000000000087d000 - 0000000000f00000 (usable)
> (XEN)  0000000000f00000 - 0000000001000000 (reserved)
> (XEN)  0000000001000000 - 0000000020000000 (usable)
> (XEN)  0000000020000000 - 0000000020200000 (reserved)
> (XEN)  0000000020200000 - 0000000040000000 (usable)
> (XEN)  0000000040000000 - 0000000040200000 (reserved)
> (XEN)  0000000040200000 - 00000000c95d6000 (usable)
> (XEN)  00000000c95d6000 - 00000000c961a000 (reserved)
> (XEN)  00000000c961a000 - 00000000c99b7000 (usable)
> (XEN)  00000000c99b7000 - 00000000c99e7000 (reserved)
> (XEN)  00000000c99e7000 - 00000000c9be7000 (ACPI NVS)
> (XEN)  00000000c9be7000 - 00000000c9bff000 (ACPI data)
> (XEN)  00000000c9bff000 - 00000000c9c00000 (usable)
> (XEN)  00000000c9f00000 - 00000000ca000000 (reserved)
> (XEN)  00000000cb000000 - 00000000cf200000 (reserved)
> (XEN)  00000000fed1c000 - 00000000fed30000 (reserved)
> (XEN)  00000000ffc00000 - 00000000ffc20000 (reserved)
> (XEN)  0000000100000000 - 000000042e000000 (usable)
> 
> When e820_sanitize is called on this memory map to create a PV domain, the
> resulting map has only one usable region (0-0xf00000) below 4GB, and Linux
> will not boot with this memory map.

Are you using xl's e820_host option?

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 08 14:55:03 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 Dec 2011 14:55:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYfMw-0007aK-U5; Thu, 08 Dec 2011 14:54:42 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RYfMv-0007aF-LE
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 14:54:41 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-4.tower-27.messagelabs.com!1323356000!51647007!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26227 invoked from network); 8 Dec 2011 14:53:20 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-4.tower-27.messagelabs.com with SMTP;
	8 Dec 2011 14:53:20 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea01.nsa.gov (8.12.10/8.12.10) with ESMTP id
	pB8ErpAa001156; Thu, 8 Dec 2011 14:53:51 GMT
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id pB8ErpDB004682; 
	Thu, 8 Dec 2011 09:53:51 -0500
Message-ID: <4EE0CF95.8030102@tycho.nsa.gov>
Date: Thu, 08 Dec 2011 09:54:13 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:7.0.1) Gecko/20110930 Thunderbird/7.0.1
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <4EE0CC19.8040905@tycho.nsa.gov>
	<1323355624.12878.1.camel@zakaz.uk.xensource.com>
In-Reply-To: <1323355624.12878.1.camel@zakaz.uk.xensource.com>
X-Enigmail-Version: 1.3.2
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] memory map issues with PV PCI passthrough
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 12/08/2011 09:47 AM, Ian Campbell wrote:
> On Thu, 2011-12-08 at 14:39 +0000, Daniel De Graaf wrote:
>> I have a system with several reserved ranges low in the e820 map which
>> cause problems when starting PV domains with PCI devices. The machine
>> memory map looks like:
>>
>> (XEN)  0000000000000000 - 0000000000060000 (usable)
>> (XEN)  0000000000060000 - 0000000000068000 (reserved)
>> (XEN)  0000000000068000 - 000000000009ac00 (usable)
>> (XEN)  000000000009ac00 - 00000000000a0000 (reserved)
>> (XEN)  00000000000e0000 - 0000000000100000 (reserved)
>> (XEN)  0000000000100000 - 0000000000800000 (usable)
>> (XEN)  0000000000800000 - 000000000087d000 (unusable)
>> (XEN)  000000000087d000 - 0000000000f00000 (usable)
>> (XEN)  0000000000f00000 - 0000000001000000 (reserved)
>> (XEN)  0000000001000000 - 0000000020000000 (usable)
>> (XEN)  0000000020000000 - 0000000020200000 (reserved)
>> (XEN)  0000000020200000 - 0000000040000000 (usable)
>> (XEN)  0000000040000000 - 0000000040200000 (reserved)
>> (XEN)  0000000040200000 - 00000000c95d6000 (usable)
>> (XEN)  00000000c95d6000 - 00000000c961a000 (reserved)
>> (XEN)  00000000c961a000 - 00000000c99b7000 (usable)
>> (XEN)  00000000c99b7000 - 00000000c99e7000 (reserved)
>> (XEN)  00000000c99e7000 - 00000000c9be7000 (ACPI NVS)
>> (XEN)  00000000c9be7000 - 00000000c9bff000 (ACPI data)
>> (XEN)  00000000c9bff000 - 00000000c9c00000 (usable)
>> (XEN)  00000000c9f00000 - 00000000ca000000 (reserved)
>> (XEN)  00000000cb000000 - 00000000cf200000 (reserved)
>> (XEN)  00000000fed1c000 - 00000000fed30000 (reserved)
>> (XEN)  00000000ffc00000 - 00000000ffc20000 (reserved)
>> (XEN)  0000000100000000 - 000000042e000000 (usable)
>>
>> When e820_sanitize is called on this memory map to create a PV domain, the
>> resulting map has only one usable region (0-0xf00000) below 4GB, and Linux
>> will not boot with this memory map.
> 
> Are you using xl's e820_host option?
> 
> Ian.
> 
> 
Yes, since enabling PCI passthrough in a PV guest enables this.

-- 
Daniel De Graaf
National Security Agency

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 08 14:55:03 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 Dec 2011 14:55:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYfMw-0007aK-U5; Thu, 08 Dec 2011 14:54:42 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RYfMv-0007aF-LE
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 14:54:41 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-4.tower-27.messagelabs.com!1323356000!51647007!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26227 invoked from network); 8 Dec 2011 14:53:20 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-4.tower-27.messagelabs.com with SMTP;
	8 Dec 2011 14:53:20 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea01.nsa.gov (8.12.10/8.12.10) with ESMTP id
	pB8ErpAa001156; Thu, 8 Dec 2011 14:53:51 GMT
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id pB8ErpDB004682; 
	Thu, 8 Dec 2011 09:53:51 -0500
Message-ID: <4EE0CF95.8030102@tycho.nsa.gov>
Date: Thu, 08 Dec 2011 09:54:13 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:7.0.1) Gecko/20110930 Thunderbird/7.0.1
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <4EE0CC19.8040905@tycho.nsa.gov>
	<1323355624.12878.1.camel@zakaz.uk.xensource.com>
In-Reply-To: <1323355624.12878.1.camel@zakaz.uk.xensource.com>
X-Enigmail-Version: 1.3.2
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] memory map issues with PV PCI passthrough
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 12/08/2011 09:47 AM, Ian Campbell wrote:
> On Thu, 2011-12-08 at 14:39 +0000, Daniel De Graaf wrote:
>> I have a system with several reserved ranges low in the e820 map which
>> cause problems when starting PV domains with PCI devices. The machine
>> memory map looks like:
>>
>> (XEN)  0000000000000000 - 0000000000060000 (usable)
>> (XEN)  0000000000060000 - 0000000000068000 (reserved)
>> (XEN)  0000000000068000 - 000000000009ac00 (usable)
>> (XEN)  000000000009ac00 - 00000000000a0000 (reserved)
>> (XEN)  00000000000e0000 - 0000000000100000 (reserved)
>> (XEN)  0000000000100000 - 0000000000800000 (usable)
>> (XEN)  0000000000800000 - 000000000087d000 (unusable)
>> (XEN)  000000000087d000 - 0000000000f00000 (usable)
>> (XEN)  0000000000f00000 - 0000000001000000 (reserved)
>> (XEN)  0000000001000000 - 0000000020000000 (usable)
>> (XEN)  0000000020000000 - 0000000020200000 (reserved)
>> (XEN)  0000000020200000 - 0000000040000000 (usable)
>> (XEN)  0000000040000000 - 0000000040200000 (reserved)
>> (XEN)  0000000040200000 - 00000000c95d6000 (usable)
>> (XEN)  00000000c95d6000 - 00000000c961a000 (reserved)
>> (XEN)  00000000c961a000 - 00000000c99b7000 (usable)
>> (XEN)  00000000c99b7000 - 00000000c99e7000 (reserved)
>> (XEN)  00000000c99e7000 - 00000000c9be7000 (ACPI NVS)
>> (XEN)  00000000c9be7000 - 00000000c9bff000 (ACPI data)
>> (XEN)  00000000c9bff000 - 00000000c9c00000 (usable)
>> (XEN)  00000000c9f00000 - 00000000ca000000 (reserved)
>> (XEN)  00000000cb000000 - 00000000cf200000 (reserved)
>> (XEN)  00000000fed1c000 - 00000000fed30000 (reserved)
>> (XEN)  00000000ffc00000 - 00000000ffc20000 (reserved)
>> (XEN)  0000000100000000 - 000000042e000000 (usable)
>>
>> When e820_sanitize is called on this memory map to create a PV domain, the
>> resulting map has only one usable region (0-0xf00000) below 4GB, and Linux
>> will not boot with this memory map.
> 
> Are you using xl's e820_host option?
> 
> Ian.
> 
> 
Yes, since enabling PCI passthrough in a PV guest enables this.

-- 
Daniel De Graaf
National Security Agency

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 08 15:41:41 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 Dec 2011 15:41:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYg5u-000851-6E; Thu, 08 Dec 2011 15:41:10 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RYg5s-00084t-HB
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 15:41:08 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1323358818!6705172!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDg5NQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28929 invoked from network); 8 Dec 2011 15:40:19 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Dec 2011 15:40:19 -0000
X-IronPort-AV: E=Sophos;i="4.71,320,1320624000"; 
   d="scan'208";a="9366954"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Dec 2011 15:40:18 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 8 Dec 2011 15:40:18 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RYg54-0002D4-A5;
	Thu, 08 Dec 2011 15:40:18 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RYg54-0001c4-8l;
	Thu, 08 Dec 2011 15:40:18 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10435-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 8 Dec 2011 15:40:18 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10435: regressions - trouble:
	broken/fail/pass
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10435 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10435/

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-i386-xl-winxpsp3-vcpus1  3 host-install(3)              broken
 test-amd64-i386-rhel6hvm-intel  3 host-install(3)              broken
 test-amd64-i386-win           8 guest-saverestore         fail REGR. vs. 10201
 test-i386-i386-win            8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-i386-win-vcpus1    8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-amd64-win          8 guest-saverestore         fail REGR. vs. 10201
 test-i386-i386-xl-win         8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-amd64-xl-win      8 guest-saverestore fail in 10401 REGR. vs. 10201
 test-amd64-amd64-xl-win7-amd64  3 host-install(3)              broken in 10424
 test-amd64-i386-win           3 host-install(3)              broken   in 10424
 test-amd64-i386-xl-win-vcpus1 8 guest-saverestore fail in 10424 REGR. vs. 10201

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-win       7 windows-install             fail pass in 10401
 test-amd64-i386-xl-win-vcpus1  7 windows-install            fail pass in 10424
 test-amd64-amd64-xl-sedf     11 guest-localmigrate fail in 10401 pass in 10435
 test-amd64-i386-xl-credit2    7 debian-install     fail in 10424 pass in 10435

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-i386-i386-xl-winxpsp3    7 windows-install              fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xl-win7-amd64  7 windows-install              fail  never pass
 test-amd64-i386-xend-winxpsp3  7 windows-install              fail  never pass
 test-amd64-amd64-xl-win7-amd64  7 windows-install              fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   never pass
 test-amd64-amd64-xl-sedf-pin 13 guest-localmigrate.2     fail blocked in 10201
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install fail in 10401 never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2       fail in 10401 never pass

version targeted for testing:
 xen                  38eb74c01d9d
baseline version:
 xen                  62ff6a318c5d

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scanneel.ca>
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Andres Lagar-Cavilla <andres@lagarcavilla>
  Andrew Cooper <andrew.cooper3@citrix.com>
  Anthony PERARD <anthony.perard@citrix.com>
  Brendan Cully <brendan@cs.ubc.ca>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Haitao Shan <haitao.shan@intel.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@novell.com>
  Jan Beulich <jbeulich@suse.com>
  Jonathan Davies <jonathan.davies@citrix.com>
  juergen.gross@ts.fujitsu.com
  Keir Fraser <keir@xen.org>
  Liu, Jinsong <jinsong.liu@intel.com>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
  Philipp Hahn <hahn@univention.de>
  Shriram Rajagopalan <rshriram@cs.ubc.ca>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang2 <wei.wang2@amd.com>
  Xudong Hao <xudong.hao@intel.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               broken  
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           broken  
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 1493 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 08 15:41:41 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 Dec 2011 15:41:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYg5u-000851-6E; Thu, 08 Dec 2011 15:41:10 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RYg5s-00084t-HB
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 15:41:08 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1323358818!6705172!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDg5NQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28929 invoked from network); 8 Dec 2011 15:40:19 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Dec 2011 15:40:19 -0000
X-IronPort-AV: E=Sophos;i="4.71,320,1320624000"; 
   d="scan'208";a="9366954"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Dec 2011 15:40:18 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 8 Dec 2011 15:40:18 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RYg54-0002D4-A5;
	Thu, 08 Dec 2011 15:40:18 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RYg54-0001c4-8l;
	Thu, 08 Dec 2011 15:40:18 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10435-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 8 Dec 2011 15:40:18 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10435: regressions - trouble:
	broken/fail/pass
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10435 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10435/

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-i386-xl-winxpsp3-vcpus1  3 host-install(3)              broken
 test-amd64-i386-rhel6hvm-intel  3 host-install(3)              broken
 test-amd64-i386-win           8 guest-saverestore         fail REGR. vs. 10201
 test-i386-i386-win            8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-i386-win-vcpus1    8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-amd64-win          8 guest-saverestore         fail REGR. vs. 10201
 test-i386-i386-xl-win         8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-amd64-xl-win      8 guest-saverestore fail in 10401 REGR. vs. 10201
 test-amd64-amd64-xl-win7-amd64  3 host-install(3)              broken in 10424
 test-amd64-i386-win           3 host-install(3)              broken   in 10424
 test-amd64-i386-xl-win-vcpus1 8 guest-saverestore fail in 10424 REGR. vs. 10201

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-win       7 windows-install             fail pass in 10401
 test-amd64-i386-xl-win-vcpus1  7 windows-install            fail pass in 10424
 test-amd64-amd64-xl-sedf     11 guest-localmigrate fail in 10401 pass in 10435
 test-amd64-i386-xl-credit2    7 debian-install     fail in 10424 pass in 10435

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-i386-i386-xl-winxpsp3    7 windows-install              fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xl-win7-amd64  7 windows-install              fail  never pass
 test-amd64-i386-xend-winxpsp3  7 windows-install              fail  never pass
 test-amd64-amd64-xl-win7-amd64  7 windows-install              fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   never pass
 test-amd64-amd64-xl-sedf-pin 13 guest-localmigrate.2     fail blocked in 10201
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install fail in 10401 never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2       fail in 10401 never pass

version targeted for testing:
 xen                  38eb74c01d9d
baseline version:
 xen                  62ff6a318c5d

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scanneel.ca>
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Andres Lagar-Cavilla <andres@lagarcavilla>
  Andrew Cooper <andrew.cooper3@citrix.com>
  Anthony PERARD <anthony.perard@citrix.com>
  Brendan Cully <brendan@cs.ubc.ca>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Haitao Shan <haitao.shan@intel.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@novell.com>
  Jan Beulich <jbeulich@suse.com>
  Jonathan Davies <jonathan.davies@citrix.com>
  juergen.gross@ts.fujitsu.com
  Keir Fraser <keir@xen.org>
  Liu, Jinsong <jinsong.liu@intel.com>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
  Philipp Hahn <hahn@univention.de>
  Shriram Rajagopalan <rshriram@cs.ubc.ca>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang2 <wei.wang2@amd.com>
  Xudong Hao <xudong.hao@intel.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               broken  
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           broken  
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 1493 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 08 16:07:06 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 Dec 2011 16:07:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYgUW-0000V2-1h; Thu, 08 Dec 2011 16:06:36 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RYgUU-0000Us-V4
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 16:06:35 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-4.tower-27.messagelabs.com!1323360313!51658613!1
X-Originating-IP: [208.97.132.145]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNDUgPT4gMTcwNzU=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26123 invoked from network); 8 Dec 2011 16:05:14 -0000
Received: from caiajhbdcbef.dreamhost.com (HELO homiemail-a75.g.dreamhost.com)
	(208.97.132.145) by server-4.tower-27.messagelabs.com with SMTP;
	8 Dec 2011 16:05:14 -0000
Received: from homiemail-a75.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a75.g.dreamhost.com (Postfix) with ESMTP id B0D195EC07E;
	Thu,  8 Dec 2011 08:05:45 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=BlbY/eTRs7sT4iQ92YnzJc4fl0l2bQsTtBvTf2/pW7bZ
	TT+lFeQULeK74ZR/tVUyNtKribAgQsfdQNdM3S757pcJXYIWSkIOFsbW1IPPiKqE
	2MG6ynIzzgW97djvIJGuPuygIW5sIJz3whuen5Ew4gYPUEVtMvN28e9CaVvkWgg=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=3yE8Ue0A4ImrUXrZ8HvXUX91pfw=; b=e4LDhg+w
	2Xt7x77DJcHs6oDsXvjHR5Q2fUJRVb0hA3f5J6Hc2d3nt6aNkVjgnEfSowKW4CVf
	BPwUxmfELCIG+juwF5458+t9rFv6Y5cN27+7C4ajg37bCRtaTtLxtR6ihcLKqx5b
	1Mk0PLOTMqc1NM5TNeIDH1jAqUL2A5B7p/4=
Received: from webmail.lagarcavilla.org (ahfbbjcaiaae.dreamhost.com
	[75.119.208.4]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a75.g.dreamhost.com (Postfix) with ESMTPA id 0A52C5EC079; 
	Thu,  8 Dec 2011 08:05:44 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP; Thu, 8 Dec 2011 08:05:45 -0800
Message-ID: <8dce6f5c4987a768004b68ac66ba4bd1.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <4EE0DA64020000780006638F@nat28.tlf.novell.com>
References: <patchbomb.1323352476@xdev.gridcentric.ca>
	<4EE0DA64020000780006638F@nat28.tlf.novell.com>
Date: Thu, 8 Dec 2011 08:05:45 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Jan Beulich" <JBeulich@suse.com>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, ian.campbell@citrix.com,
	andres@gridcentric.ca, tim@xen.org, keir.xen@gmail.com,
	ian.jackson@citrix.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 0 of 5] Memory sharing overhaul part 2
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>>> On 08.12.11 at 14:54, Andres Lagar-Cavilla <andres@lagarcavilla.org>
>>>> wrote:
>>...
>>  xen/arch/x86/mm/mem_sharing.c |  106
>> ++++++++++++++++++++++++++++++++++++++++++
>>  xen/include/public/domctl.h   |    3 +-
>>  tools/libxc/xc_memshr.c       |   23 +++++++++
>>  tools/libxc/xenctrl.h         |    6 ++
>>  xen/arch/ia64/xen/mm.c        |    6 ++
>>  xen/arch/x86/mm/mem_sharing.c |    8 +++
>>  xen/common/keyhandler.c       |    7 +-
>>  xen/include/xen/mm.h          |    3 +
>>  xen/arch/x86/mm/mem_sharing.c |   17 ++++-
>>  xen/include/public/domctl.h   |    1 +
>>  tools/libxc/xc_memshr.c       |   14 +++++
>>  tools/libxc/xenctrl.h         |    2 +
>>  12 files changed, 188 insertions(+), 8 deletions(-)
>
> As this isn't the first time with your patch submissions - I'm not sure
> what
> you use to generate these stats, but in order to be useful I would
> generally expect this to be a list with duplicate entries folded rather
> than
> a mere concatenation of those from the individual patches (leaving doing
> the arithmetic to the reader/reviewer).
I apologize. I am also frustrated by this. Hugely.
Andres
>
> Jan
>
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 08 16:07:06 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 Dec 2011 16:07:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYgUW-0000V2-1h; Thu, 08 Dec 2011 16:06:36 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RYgUU-0000Us-V4
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 16:06:35 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-4.tower-27.messagelabs.com!1323360313!51658613!1
X-Originating-IP: [208.97.132.145]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNDUgPT4gMTcwNzU=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26123 invoked from network); 8 Dec 2011 16:05:14 -0000
Received: from caiajhbdcbef.dreamhost.com (HELO homiemail-a75.g.dreamhost.com)
	(208.97.132.145) by server-4.tower-27.messagelabs.com with SMTP;
	8 Dec 2011 16:05:14 -0000
Received: from homiemail-a75.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a75.g.dreamhost.com (Postfix) with ESMTP id B0D195EC07E;
	Thu,  8 Dec 2011 08:05:45 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=BlbY/eTRs7sT4iQ92YnzJc4fl0l2bQsTtBvTf2/pW7bZ
	TT+lFeQULeK74ZR/tVUyNtKribAgQsfdQNdM3S757pcJXYIWSkIOFsbW1IPPiKqE
	2MG6ynIzzgW97djvIJGuPuygIW5sIJz3whuen5Ew4gYPUEVtMvN28e9CaVvkWgg=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=3yE8Ue0A4ImrUXrZ8HvXUX91pfw=; b=e4LDhg+w
	2Xt7x77DJcHs6oDsXvjHR5Q2fUJRVb0hA3f5J6Hc2d3nt6aNkVjgnEfSowKW4CVf
	BPwUxmfELCIG+juwF5458+t9rFv6Y5cN27+7C4ajg37bCRtaTtLxtR6ihcLKqx5b
	1Mk0PLOTMqc1NM5TNeIDH1jAqUL2A5B7p/4=
Received: from webmail.lagarcavilla.org (ahfbbjcaiaae.dreamhost.com
	[75.119.208.4]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a75.g.dreamhost.com (Postfix) with ESMTPA id 0A52C5EC079; 
	Thu,  8 Dec 2011 08:05:44 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP; Thu, 8 Dec 2011 08:05:45 -0800
Message-ID: <8dce6f5c4987a768004b68ac66ba4bd1.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <4EE0DA64020000780006638F@nat28.tlf.novell.com>
References: <patchbomb.1323352476@xdev.gridcentric.ca>
	<4EE0DA64020000780006638F@nat28.tlf.novell.com>
Date: Thu, 8 Dec 2011 08:05:45 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Jan Beulich" <JBeulich@suse.com>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, ian.campbell@citrix.com,
	andres@gridcentric.ca, tim@xen.org, keir.xen@gmail.com,
	ian.jackson@citrix.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 0 of 5] Memory sharing overhaul part 2
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>>> On 08.12.11 at 14:54, Andres Lagar-Cavilla <andres@lagarcavilla.org>
>>>> wrote:
>>...
>>  xen/arch/x86/mm/mem_sharing.c |  106
>> ++++++++++++++++++++++++++++++++++++++++++
>>  xen/include/public/domctl.h   |    3 +-
>>  tools/libxc/xc_memshr.c       |   23 +++++++++
>>  tools/libxc/xenctrl.h         |    6 ++
>>  xen/arch/ia64/xen/mm.c        |    6 ++
>>  xen/arch/x86/mm/mem_sharing.c |    8 +++
>>  xen/common/keyhandler.c       |    7 +-
>>  xen/include/xen/mm.h          |    3 +
>>  xen/arch/x86/mm/mem_sharing.c |   17 ++++-
>>  xen/include/public/domctl.h   |    1 +
>>  tools/libxc/xc_memshr.c       |   14 +++++
>>  tools/libxc/xenctrl.h         |    2 +
>>  12 files changed, 188 insertions(+), 8 deletions(-)
>
> As this isn't the first time with your patch submissions - I'm not sure
> what
> you use to generate these stats, but in order to be useful I would
> generally expect this to be a list with duplicate entries folded rather
> than
> a mere concatenation of those from the individual patches (leaving doing
> the arithmetic to the reader/reviewer).
I apologize. I am also frustrated by this. Hugely.
Andres
>
> Jan
>
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 08 16:17:51 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 Dec 2011 16:17:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYget-0000n4-D2; Thu, 08 Dec 2011 16:17:19 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RYger-0000mw-TJ
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 16:17:18 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-15.tower-216.messagelabs.com!1323360988!6677222!1
X-Originating-IP: [208.97.132.202]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4yMDIgPT4gMTYxMzg=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21104 invoked from network); 8 Dec 2011 16:16:29 -0000
Received: from caiajhbdccac.dreamhost.com (HELO homiemail-a75.g.dreamhost.com)
	(208.97.132.202) by server-15.tower-216.messagelabs.com with SMTP;
	8 Dec 2011 16:16:29 -0000
Received: from homiemail-a75.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a75.g.dreamhost.com (Postfix) with ESMTP id B64445EC084;
	Thu,  8 Dec 2011 08:16:27 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=GPnCyOEV/rK5gBJ8GbaHz/VWJOWK8HUAv04yAol2kJX/
	XOuKQ6bQH+RHAxaoljg5hJMD0tHGt5ozg5uOhKhBBHn2jYWjP/M7Je6WIgiC/ZZn
	8bKoB8XUpuhuPbpuuckgI74gqc5BMHcUeSJJ64l2NPvfrQGOhLlrthqYaYWHtYY=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=hyDj5AeokLBYti68blV6or0Jnhc=; b=ht1R66sa
	KelenlG5AzsrunkK7xPd9H3p8KzneypvDjJqrVmslHF8uG82slm3F8jqmvvPiW3k
	Fh8zHbQvz9XVl20I9aKl1e6vzO9o8SFL1SwKPd/sfQH14UqLzSTctGKPcsolyqOo
	P3WSV7qHl+bzlGNi1T8oiPy5rFOogBj02zs=
Received: from webmail.lagarcavilla.org (ahfbbjcaiaae.dreamhost.com
	[75.119.208.4]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a75.g.dreamhost.com (Postfix) with ESMTPA id 1F0A65EC079; 
	Thu,  8 Dec 2011 08:16:27 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP; Thu, 8 Dec 2011 08:16:27 -0800
Message-ID: <22f47878379138be5d645f48b4db9ed3.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20111208111118.GA82565@ocelot.phlegethon.org>
References: <patchbomb.1323330435@xdev.gridcentric.ca>
	<aeebbff899ffa2328e3f.1323330436@xdev.gridcentric.ca>
	<20111208111118.GA82565@ocelot.phlegethon.org>
Date: Thu, 8 Dec 2011 08:16:27 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Tim Deegan" <tim@xen.org>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, ian.campbell@citrix.com,
	andres@gridcentric.ca, keir.xen@gmail.com, jbeulich@suse.com,
	ian.jackson@citrix.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 01 of 18] x86/mm: Code style fixes in
 mem_sharing.c
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> At 02:47 -0500 on 08 Dec (1323312436), Andres Lagar-Cavilla wrote:
>> Harmless patch, with no functional changes, only code style issues.
>>
>> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
>
> ...
>
>> -    return -2;
>> +    return 0;
>
> Ahem. :)
>
> Tim.
Borderline, I'll admit. I can play down the tone of the header -- nothing
is really harmless :)

The function will still produce the same outputs on the same inputs, with
cleaner code.

Thanks
Andres
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 08 16:17:51 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 Dec 2011 16:17:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYget-0000n4-D2; Thu, 08 Dec 2011 16:17:19 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RYger-0000mw-TJ
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 16:17:18 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-15.tower-216.messagelabs.com!1323360988!6677222!1
X-Originating-IP: [208.97.132.202]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4yMDIgPT4gMTYxMzg=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21104 invoked from network); 8 Dec 2011 16:16:29 -0000
Received: from caiajhbdccac.dreamhost.com (HELO homiemail-a75.g.dreamhost.com)
	(208.97.132.202) by server-15.tower-216.messagelabs.com with SMTP;
	8 Dec 2011 16:16:29 -0000
Received: from homiemail-a75.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a75.g.dreamhost.com (Postfix) with ESMTP id B64445EC084;
	Thu,  8 Dec 2011 08:16:27 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=GPnCyOEV/rK5gBJ8GbaHz/VWJOWK8HUAv04yAol2kJX/
	XOuKQ6bQH+RHAxaoljg5hJMD0tHGt5ozg5uOhKhBBHn2jYWjP/M7Je6WIgiC/ZZn
	8bKoB8XUpuhuPbpuuckgI74gqc5BMHcUeSJJ64l2NPvfrQGOhLlrthqYaYWHtYY=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=hyDj5AeokLBYti68blV6or0Jnhc=; b=ht1R66sa
	KelenlG5AzsrunkK7xPd9H3p8KzneypvDjJqrVmslHF8uG82slm3F8jqmvvPiW3k
	Fh8zHbQvz9XVl20I9aKl1e6vzO9o8SFL1SwKPd/sfQH14UqLzSTctGKPcsolyqOo
	P3WSV7qHl+bzlGNi1T8oiPy5rFOogBj02zs=
Received: from webmail.lagarcavilla.org (ahfbbjcaiaae.dreamhost.com
	[75.119.208.4]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a75.g.dreamhost.com (Postfix) with ESMTPA id 1F0A65EC079; 
	Thu,  8 Dec 2011 08:16:27 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP; Thu, 8 Dec 2011 08:16:27 -0800
Message-ID: <22f47878379138be5d645f48b4db9ed3.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20111208111118.GA82565@ocelot.phlegethon.org>
References: <patchbomb.1323330435@xdev.gridcentric.ca>
	<aeebbff899ffa2328e3f.1323330436@xdev.gridcentric.ca>
	<20111208111118.GA82565@ocelot.phlegethon.org>
Date: Thu, 8 Dec 2011 08:16:27 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Tim Deegan" <tim@xen.org>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, ian.campbell@citrix.com,
	andres@gridcentric.ca, keir.xen@gmail.com, jbeulich@suse.com,
	ian.jackson@citrix.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 01 of 18] x86/mm: Code style fixes in
 mem_sharing.c
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> At 02:47 -0500 on 08 Dec (1323312436), Andres Lagar-Cavilla wrote:
>> Harmless patch, with no functional changes, only code style issues.
>>
>> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
>
> ...
>
>> -    return -2;
>> +    return 0;
>
> Ahem. :)
>
> Tim.
Borderline, I'll admit. I can play down the tone of the header -- nothing
is really harmless :)

The function will still produce the same outputs on the same inputs, with
cleaner code.

Thanks
Andres
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 08 16:18:11 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 Dec 2011 16: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.xensource.com>)
	id 1RYgfM-0000oM-Q0; Thu, 08 Dec 2011 16:17:48 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RYgfM-0000oA-4l
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 16:17:48 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1323361018!7451854!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDg5NQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29311 invoked from network); 8 Dec 2011 16:16:58 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Dec 2011 16:16:58 -0000
X-IronPort-AV: E=Sophos;i="4.71,320,1320624000"; 
   d="scan'208";a="9367834"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Dec 2011 16:16:57 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 8 Dec 2011 16:16:57 +0000
Date: Thu, 8 Dec 2011 16:17:13 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: <xen-devel@lists.xensource.com>
Message-ID: <alpine.DEB.2.00.1112081614520.3517@kaball-desktop>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH] qemu_get_timer: always read the 64 bit value
 from the savefile
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

qemu_get_timer: the 64 bit value needs to be read from the save file
even when the timer is not initialized otherwise following reads from
the savefile will read the wrong fields.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

diff --git a/vl.c b/vl.c
index f3b3d02..9e0a556 100644
--- a/vl.c
+++ b/vl.c
@@ -1276,10 +1276,10 @@ void qemu_get_timer(QEMUFile *f, QEMUTimer *ts)
 {
     uint64_t expire_time;
 
+    expire_time = qemu_get_be64(f);
+
     if (ts == NULL)
         return;
-
-    expire_time = qemu_get_be64(f);
     if (expire_time != -1) {
         qemu_mod_timer(ts, expire_time);
     } else {

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 08 16:18:11 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 Dec 2011 16: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.xensource.com>)
	id 1RYgfM-0000oM-Q0; Thu, 08 Dec 2011 16:17:48 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RYgfM-0000oA-4l
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 16:17:48 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1323361018!7451854!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDg5NQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29311 invoked from network); 8 Dec 2011 16:16:58 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Dec 2011 16:16:58 -0000
X-IronPort-AV: E=Sophos;i="4.71,320,1320624000"; 
   d="scan'208";a="9367834"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Dec 2011 16:16:57 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 8 Dec 2011 16:16:57 +0000
Date: Thu, 8 Dec 2011 16:17:13 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: <xen-devel@lists.xensource.com>
Message-ID: <alpine.DEB.2.00.1112081614520.3517@kaball-desktop>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH] qemu_get_timer: always read the 64 bit value
 from the savefile
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

qemu_get_timer: the 64 bit value needs to be read from the save file
even when the timer is not initialized otherwise following reads from
the savefile will read the wrong fields.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

diff --git a/vl.c b/vl.c
index f3b3d02..9e0a556 100644
--- a/vl.c
+++ b/vl.c
@@ -1276,10 +1276,10 @@ void qemu_get_timer(QEMUFile *f, QEMUTimer *ts)
 {
     uint64_t expire_time;
 
+    expire_time = qemu_get_be64(f);
+
     if (ts == NULL)
         return;
-
-    expire_time = qemu_get_be64(f);
     if (expire_time != -1) {
         qemu_mod_timer(ts, expire_time);
     } else {

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 08 16:41:45 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 Dec 2011 16:41:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYh25-0001C1-Tm; Thu, 08 Dec 2011 16:41:17 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RYh24-0001Bw-QP
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 16:41:17 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1323362426!7481869!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDg5NQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2882 invoked from network); 8 Dec 2011 16:40:27 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Dec 2011 16:40:27 -0000
X-IronPort-AV: E=Sophos;i="4.71,320,1320624000"; 
   d="scan'208";a="9368526"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Dec 2011 16:40:26 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 8 Dec 2011 16:40:26 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RYh1G-0002Xa-3e; Thu, 08 Dec 2011 16:40:26 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RYh1G-0002cH-2F;
	Thu, 08 Dec 2011 16:40:26 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20192.59514.57110.244714@mariner.uk.xensource.com>
Date: Thu, 8 Dec 2011 16:40:26 +0000
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <alpine.DEB.2.00.1112081614520.3517@kaball-desktop>
References: <alpine.DEB.2.00.1112081614520.3517@kaball-desktop>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] qemu_get_timer: always read the 64 bit
 value from the savefile
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Stefano Stabellini writes ("[Xen-devel] [PATCH] qemu_get_timer: always read the 64 bit value from the savefile"):
> qemu_get_timer: the 64 bit value needs to be read from the save file
> even when the timer is not initialized otherwise following reads from
> the savefile will read the wrong fields.
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 08 16:41:45 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 Dec 2011 16:41:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYh25-0001C1-Tm; Thu, 08 Dec 2011 16:41:17 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RYh24-0001Bw-QP
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 16:41:17 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1323362426!7481869!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDg5NQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2882 invoked from network); 8 Dec 2011 16:40:27 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Dec 2011 16:40:27 -0000
X-IronPort-AV: E=Sophos;i="4.71,320,1320624000"; 
   d="scan'208";a="9368526"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Dec 2011 16:40:26 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 8 Dec 2011 16:40:26 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RYh1G-0002Xa-3e; Thu, 08 Dec 2011 16:40:26 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RYh1G-0002cH-2F;
	Thu, 08 Dec 2011 16:40:26 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20192.59514.57110.244714@mariner.uk.xensource.com>
Date: Thu, 8 Dec 2011 16:40:26 +0000
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <alpine.DEB.2.00.1112081614520.3517@kaball-desktop>
References: <alpine.DEB.2.00.1112081614520.3517@kaball-desktop>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] qemu_get_timer: always read the 64 bit
 value from the savefile
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Stefano Stabellini writes ("[Xen-devel] [PATCH] qemu_get_timer: always read the 64 bit value from the savefile"):
> qemu_get_timer: the 64 bit value needs to be read from the save file
> even when the timer is not initialized otherwise following reads from
> the savefile will read the wrong fields.
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 08 16:48:10 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 Dec 2011 16:48:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYh8O-0001Lv-QE; Thu, 08 Dec 2011 16:47:48 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RYh8M-0001Lp-Vx
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 16:47:47 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1323362786!51664531!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDg5NQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15767 invoked from network); 8 Dec 2011 16:46:26 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Dec 2011 16:46:26 -0000
X-IronPort-AV: E=Sophos;i="4.71,320,1320624000"; 
   d="scan'208";a="9368675"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Dec 2011 16:46:58 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 8 Dec 2011 16:46:58 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RYh7a-0002Zf-B7; Thu, 08 Dec 2011 16:46:58 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RYh7a-0002cu-AG;
	Thu, 08 Dec 2011 16:46:58 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20192.59906.297014.643665@mariner.uk.xensource.com>
Date: Thu, 8 Dec 2011 16:46:58 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1323100671.23681.3.camel@zakaz.uk.xensource.com>
References: <alpine.DEB.2.00.1112051053180.31179@kaball-desktop>
	<1323093585.29870.192.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1112051440170.31179@kaball-desktop>
	<1323100671.23681.3.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] qemu_timer_pending/qemu_get_timer: cope with NULL
	timers
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("Re: [Xen-devel] qemu_timer_pending/qemu_get_timer: cope with NULL timers"):
> It sounds to me like the NULL check should have been in the save/restore
> code but the patch is in so lets not worry about it.

We now know that while this patch was attempting to fix the hvm
save/restore regression, it introduced a new bug of its own, now
thankfully fixed (we think!)

I think if the patch author had taken the trouble to write a comment
explaining the new behaviour, there would have been a better chance of
someone realising that turning an existing restore-read function into
a no-op wasn't a sound thing to do.  So your criticism was right.

Of course this patch was itself intended as a fix for a regression -
so I applied it with perhaps less time for review than usual.  Perhaps
the lesson for me is that I should have been more ready to revert the
original patch and wait for a corrected version.

Given the new state of the code I don't think it's plausible to move
the null check into the caller, but the resulting arrangements are
definitely tangled.  If this weren't a maintenance-only branch, I
would want to see some cleanup but I think this rather messy approach
is OK in this case.

But I have added a comment on the new semantics of the qemu_get_timer.

Thanks,
Ian.

commit 54e24021005458ad0a361c1d83011b751726a94b
Author: Ian Jackson <ian.jackson@eu.citrix.com>
Date:   Thu Dec 8 16:38:06 2011 +0000

    qemu_get_timer: Provide a comment about the behaviour on ts==NULL
    
    Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

diff --git a/vl.c b/vl.c
index 9e0a556..be8587a 100644
--- a/vl.c
+++ b/vl.c
@@ -1274,6 +1274,8 @@ void qemu_put_timer(QEMUFile *f, QEMUTimer *ts)
 
 void qemu_get_timer(QEMUFile *f, QEMUTimer *ts)
 {
+    /* If ts==NULL, reads the relevant amount of data from the
+       savefile but discards it */
     uint64_t expire_time;
 
     expire_time = qemu_get_be64(f);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 08 16:48:10 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 Dec 2011 16:48:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYh8O-0001Lv-QE; Thu, 08 Dec 2011 16:47:48 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RYh8M-0001Lp-Vx
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 16:47:47 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1323362786!51664531!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDg5NQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15767 invoked from network); 8 Dec 2011 16:46:26 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Dec 2011 16:46:26 -0000
X-IronPort-AV: E=Sophos;i="4.71,320,1320624000"; 
   d="scan'208";a="9368675"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Dec 2011 16:46:58 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 8 Dec 2011 16:46:58 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RYh7a-0002Zf-B7; Thu, 08 Dec 2011 16:46:58 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RYh7a-0002cu-AG;
	Thu, 08 Dec 2011 16:46:58 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20192.59906.297014.643665@mariner.uk.xensource.com>
Date: Thu, 8 Dec 2011 16:46:58 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1323100671.23681.3.camel@zakaz.uk.xensource.com>
References: <alpine.DEB.2.00.1112051053180.31179@kaball-desktop>
	<1323093585.29870.192.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1112051440170.31179@kaball-desktop>
	<1323100671.23681.3.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] qemu_timer_pending/qemu_get_timer: cope with NULL
	timers
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("Re: [Xen-devel] qemu_timer_pending/qemu_get_timer: cope with NULL timers"):
> It sounds to me like the NULL check should have been in the save/restore
> code but the patch is in so lets not worry about it.

We now know that while this patch was attempting to fix the hvm
save/restore regression, it introduced a new bug of its own, now
thankfully fixed (we think!)

I think if the patch author had taken the trouble to write a comment
explaining the new behaviour, there would have been a better chance of
someone realising that turning an existing restore-read function into
a no-op wasn't a sound thing to do.  So your criticism was right.

Of course this patch was itself intended as a fix for a regression -
so I applied it with perhaps less time for review than usual.  Perhaps
the lesson for me is that I should have been more ready to revert the
original patch and wait for a corrected version.

Given the new state of the code I don't think it's plausible to move
the null check into the caller, but the resulting arrangements are
definitely tangled.  If this weren't a maintenance-only branch, I
would want to see some cleanup but I think this rather messy approach
is OK in this case.

But I have added a comment on the new semantics of the qemu_get_timer.

Thanks,
Ian.

commit 54e24021005458ad0a361c1d83011b751726a94b
Author: Ian Jackson <ian.jackson@eu.citrix.com>
Date:   Thu Dec 8 16:38:06 2011 +0000

    qemu_get_timer: Provide a comment about the behaviour on ts==NULL
    
    Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

diff --git a/vl.c b/vl.c
index 9e0a556..be8587a 100644
--- a/vl.c
+++ b/vl.c
@@ -1274,6 +1274,8 @@ void qemu_put_timer(QEMUFile *f, QEMUTimer *ts)
 
 void qemu_get_timer(QEMUFile *f, QEMUTimer *ts)
 {
+    /* If ts==NULL, reads the relevant amount of data from the
+       savefile but discards it */
     uint64_t expire_time;
 
     expire_time = qemu_get_be64(f);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 08 16:54:37 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 Dec 2011 16: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.xensource.com>)
	id 1RYhEe-0001WP-LN; Thu, 08 Dec 2011 16:54:16 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RYhEd-0001WD-3z
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 16:54:15 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1323363171!45960025!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDg5NQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2647 invoked from network); 8 Dec 2011 16:52:51 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Dec 2011 16:52:51 -0000
X-IronPort-AV: E=Sophos;i="4.71,320,1320624000"; 
   d="scan'208";a="9368825"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Dec 2011 16:53:28 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 8 Dec 2011 16:53:27 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RYhDr-0002c5-Hz; Thu, 08 Dec 2011 16:53:27 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RYhDr-0002fY-H9;
	Thu, 08 Dec 2011 16:53:27 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20192.60295.521123.995556@mariner.uk.xensource.com>
Date: Thu, 8 Dec 2011 16:53:27 +0000
To: Olaf Hering <olaf@aepfle.de>
In-Reply-To: <20111201184834.GB17010@aepfle.de>
References: <patchbomb.1322228345@probook.site>
	<20183.51028.504634.590709@mariner.uk.xensource.com>
	<20111201184834.GB17010@aepfle.de>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 0 of 2] tools/hotplug fixes for xen-unstable
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Olaf Hering writes ("Re: [Xen-devel] [PATCH 0 of 2] tools/hotplug fixes for xen-unstable"):
> could the modprobe change be backported to 4.1 and maybe even 4.0?

Yes, I think it has been in unstable long enough.  I have cherry
picked it into to 4.1, whose xencommons is identical to unstable's.

As regards 4.0: the xencommons script there is substantially
different, as the toolstack startup arrangements don't match
4.1/unstable.  If someone wants to provide a (tested!) backport then
we'll consider it.

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 08 16:54:37 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 Dec 2011 16: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.xensource.com>)
	id 1RYhEe-0001WP-LN; Thu, 08 Dec 2011 16:54:16 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RYhEd-0001WD-3z
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 16:54:15 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1323363171!45960025!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDg5NQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2647 invoked from network); 8 Dec 2011 16:52:51 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Dec 2011 16:52:51 -0000
X-IronPort-AV: E=Sophos;i="4.71,320,1320624000"; 
   d="scan'208";a="9368825"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Dec 2011 16:53:28 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 8 Dec 2011 16:53:27 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RYhDr-0002c5-Hz; Thu, 08 Dec 2011 16:53:27 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RYhDr-0002fY-H9;
	Thu, 08 Dec 2011 16:53:27 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20192.60295.521123.995556@mariner.uk.xensource.com>
Date: Thu, 8 Dec 2011 16:53:27 +0000
To: Olaf Hering <olaf@aepfle.de>
In-Reply-To: <20111201184834.GB17010@aepfle.de>
References: <patchbomb.1322228345@probook.site>
	<20183.51028.504634.590709@mariner.uk.xensource.com>
	<20111201184834.GB17010@aepfle.de>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 0 of 2] tools/hotplug fixes for xen-unstable
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Olaf Hering writes ("Re: [Xen-devel] [PATCH 0 of 2] tools/hotplug fixes for xen-unstable"):
> could the modprobe change be backported to 4.1 and maybe even 4.0?

Yes, I think it has been in unstable long enough.  I have cherry
picked it into to 4.1, whose xencommons is identical to unstable's.

As regards 4.0: the xencommons script there is substantially
different, as the toolstack startup arrangements don't match
4.1/unstable.  If someone wants to provide a (tested!) backport then
we'll consider it.

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 08 16:56:32 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 Dec 2011 16:56:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYhGV-0001gU-Gn; Thu, 08 Dec 2011 16:56:11 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RYhGU-0001g8-7c
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 16:56:10 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1323363284!47110658!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDg5NQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24851 invoked from network); 8 Dec 2011 16:54:44 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Dec 2011 16:54:44 -0000
X-IronPort-AV: E=Sophos;i="4.71,320,1320624000"; 
   d="scan'208";a="9368868"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Dec 2011 16:55:22 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 8 Dec 2011 16:55:21 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RYhFh-0002d1-Mo; Thu, 08 Dec 2011 16:55:21 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RYhFh-0002g2-M3;
	Thu, 08 Dec 2011 16:55:21 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20192.60409.671198.164743@mariner.uk.xensource.com>
Date: Thu, 8 Dec 2011 16:55:21 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1322767629.7376.28.camel@dagon.hellion.org.uk>
References: <20183.49416.735231.548215@mariner.uk.xensource.com>
	<1322767629.7376.28.camel@dagon.hellion.org.uk>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] docs: Say in xm(1) that xm is obsolete
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("Re: [Xen-devel] [PATCH] docs: Say in xm(1) that xm is obsolete"):
> On Thu, 2011-12-01 at 18:01 +0000, Ian Jackson wrote:
> > +backwards-compatible with B<sm>.
> 
> Typo                           ^
> 
> o/w Acked-by: Ian Campbell <ian.campbell@citrix.com>

Thanks, fixed and applied.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 08 16:56:32 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 Dec 2011 16:56:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYhGV-0001gU-Gn; Thu, 08 Dec 2011 16:56:11 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RYhGU-0001g8-7c
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 16:56:10 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1323363284!47110658!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDg5NQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24851 invoked from network); 8 Dec 2011 16:54:44 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Dec 2011 16:54:44 -0000
X-IronPort-AV: E=Sophos;i="4.71,320,1320624000"; 
   d="scan'208";a="9368868"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Dec 2011 16:55:22 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 8 Dec 2011 16:55:21 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RYhFh-0002d1-Mo; Thu, 08 Dec 2011 16:55:21 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RYhFh-0002g2-M3;
	Thu, 08 Dec 2011 16:55:21 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20192.60409.671198.164743@mariner.uk.xensource.com>
Date: Thu, 8 Dec 2011 16:55:21 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1322767629.7376.28.camel@dagon.hellion.org.uk>
References: <20183.49416.735231.548215@mariner.uk.xensource.com>
	<1322767629.7376.28.camel@dagon.hellion.org.uk>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] docs: Say in xm(1) that xm is obsolete
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("Re: [Xen-devel] [PATCH] docs: Say in xm(1) that xm is obsolete"):
> On Thu, 2011-12-01 at 18:01 +0000, Ian Jackson wrote:
> > +backwards-compatible with B<sm>.
> 
> Typo                           ^
> 
> o/w Acked-by: Ian Campbell <ian.campbell@citrix.com>

Thanks, fixed and applied.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 08 17:04:32 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 Dec 2011 17:04:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYhOB-000250-Fm; Thu, 08 Dec 2011 17:04:07 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RYhO9-00024s-MB
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 17:04:05 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1323363764!45961325!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDg5NQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1770 invoked from network); 8 Dec 2011 17:02:44 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Dec 2011 17:02:44 -0000
X-IronPort-AV: E=Sophos;i="4.71,320,1320624000"; 
   d="scan'208";a="9369038"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Dec 2011 17:03:22 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 8 Dec 2011
	17:03:22 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Thu, 8 Dec 2011 17:03:21 +0000
In-Reply-To: <20183.49416.735231.548215@mariner.uk.xensource.com>
References: <20183.49416.735231.548215@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323363801.12878.11.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] docs: Say in xm(1) that xm is obsolete
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2011-12-01 at 18:01 +0000, Ian Jackson wrote:
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
> 
> diff -r 3b409f65abae docs/man/xm.pod.1
> --- a/docs/man/xm.pod.1	Thu Dec 01 17:26:48 2011 +0000
> +++ b/docs/man/xm.pod.1	Thu Dec 01 18:01:35 2011 +0000
> @@ -1,6 +1,6 @@
>  =head1 NAME
>  
> -xm - Xen management user interface
> +xm - Obsolete xen management user interface
>  
>  =head1 SYNOPSIS
>  
> @@ -8,10 +8,14 @@ B<xm> I<subcommand> [I<args>]
>  
>  =head1 DESCRIPTION
>  
> -The B<xm> program is the main interface for managing Xen guest
> -domains. The program can be used to create, pause, and shutdown
> -domains. It can also be used to list current domains, enable or pin
> -VCPUs, and attach or detach virtual block devices.
> +This program is now superseded by B<xl>, which should be largely
> +backwards-compatible with B<sm>.

We should remember to make this part of our 4.2 release notes as well.

Ian.

> +
> +The B<xm> program is the main interface for managing Xen guest domains
> +when the obsolete Xend toolstack is in use. The program can be used to
> +create, pause, and shutdown domains. It can also be used to list
> +current domains, enable or pin VCPUs, and attach or detach virtual
> +block devices.
>  
>  The basic structure of every B<xm> command is almost always:
>  
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 08 17:04:32 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 Dec 2011 17:04:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYhOB-000250-Fm; Thu, 08 Dec 2011 17:04:07 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RYhO9-00024s-MB
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 17:04:05 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1323363764!45961325!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDg5NQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1770 invoked from network); 8 Dec 2011 17:02:44 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Dec 2011 17:02:44 -0000
X-IronPort-AV: E=Sophos;i="4.71,320,1320624000"; 
   d="scan'208";a="9369038"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Dec 2011 17:03:22 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 8 Dec 2011
	17:03:22 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Thu, 8 Dec 2011 17:03:21 +0000
In-Reply-To: <20183.49416.735231.548215@mariner.uk.xensource.com>
References: <20183.49416.735231.548215@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323363801.12878.11.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] docs: Say in xm(1) that xm is obsolete
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2011-12-01 at 18:01 +0000, Ian Jackson wrote:
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
> 
> diff -r 3b409f65abae docs/man/xm.pod.1
> --- a/docs/man/xm.pod.1	Thu Dec 01 17:26:48 2011 +0000
> +++ b/docs/man/xm.pod.1	Thu Dec 01 18:01:35 2011 +0000
> @@ -1,6 +1,6 @@
>  =head1 NAME
>  
> -xm - Xen management user interface
> +xm - Obsolete xen management user interface
>  
>  =head1 SYNOPSIS
>  
> @@ -8,10 +8,14 @@ B<xm> I<subcommand> [I<args>]
>  
>  =head1 DESCRIPTION
>  
> -The B<xm> program is the main interface for managing Xen guest
> -domains. The program can be used to create, pause, and shutdown
> -domains. It can also be used to list current domains, enable or pin
> -VCPUs, and attach or detach virtual block devices.
> +This program is now superseded by B<xl>, which should be largely
> +backwards-compatible with B<sm>.

We should remember to make this part of our 4.2 release notes as well.

Ian.

> +
> +The B<xm> program is the main interface for managing Xen guest domains
> +when the obsolete Xend toolstack is in use. The program can be used to
> +create, pause, and shutdown domains. It can also be used to list
> +current domains, enable or pin VCPUs, and attach or detach virtual
> +block devices.
>  
>  The basic structure of every B<xm> command is almost always:
>  
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 08 17:19:22 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 Dec 2011 17:19:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYhbK-0002NG-RG; Thu, 08 Dec 2011 17:17:42 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RYhbJ-0002N7-Jk
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 17:17:41 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1323364613!6465295!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDg5NQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30286 invoked from network); 8 Dec 2011 17:16:53 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Dec 2011 17:16:53 -0000
X-IronPort-AV: E=Sophos;i="4.71,320,1320624000"; 
   d="scan'208";a="9369376"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Dec 2011 17:16:52 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 8 Dec 2011 17:16:52 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RYhaW-0002k9-5z; Thu, 08 Dec 2011 17:16:52 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RYhaW-0002hr-5B;
	Thu, 08 Dec 2011 17:16:52 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20192.61699.932997.208965@mariner.uk.xensource.com>
Date: Thu, 8 Dec 2011 17:16:51 +0000
To: Philipp Hahn <hahn@univention.de>
In-Reply-To: <201112032142.56295.hahn@univention.de>
References: <201111251721.12753.hahn@univention.de>
	<201111252057.31649.hahn@univention.de>
	<20183.51176.909813.103305@mariner.uk.xensource.com>
	<201112032142.56295.hahn@univention.de>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCHv2] insufficient quoting between "tap-ctl
 list" and xend/server/BlktapController.py
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Philipp Hahn writes ("Re: [PATCHv2] insufficient quoting between "tap-ctl list" and xend/server/BlktapController.py"):
> Argh, I submitted the wrong patch. The "line.split(None, 4)" needs to be 
> a "3", because 3 splits needs to be done to get the 4 parts.

Oops.  Thanks for submitting the fix.  I have applied it.

But please remember next time to include a proper signed-off-by.  In
this case, since it was only a single-character change, I applied it
anyway (the interdiff, since the previous version went in already).

Also this kind of thing shows how little review xend patches get
nowadays.  Users of xend are well-advised to switch away before they
trip over some rotting code...

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 08 17:19:22 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 Dec 2011 17:19:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYhbK-0002NG-RG; Thu, 08 Dec 2011 17:17:42 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RYhbJ-0002N7-Jk
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 17:17:41 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1323364613!6465295!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDg5NQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30286 invoked from network); 8 Dec 2011 17:16:53 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Dec 2011 17:16:53 -0000
X-IronPort-AV: E=Sophos;i="4.71,320,1320624000"; 
   d="scan'208";a="9369376"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Dec 2011 17:16:52 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 8 Dec 2011 17:16:52 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RYhaW-0002k9-5z; Thu, 08 Dec 2011 17:16:52 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RYhaW-0002hr-5B;
	Thu, 08 Dec 2011 17:16:52 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20192.61699.932997.208965@mariner.uk.xensource.com>
Date: Thu, 8 Dec 2011 17:16:51 +0000
To: Philipp Hahn <hahn@univention.de>
In-Reply-To: <201112032142.56295.hahn@univention.de>
References: <201111251721.12753.hahn@univention.de>
	<201111252057.31649.hahn@univention.de>
	<20183.51176.909813.103305@mariner.uk.xensource.com>
	<201112032142.56295.hahn@univention.de>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCHv2] insufficient quoting between "tap-ctl
 list" and xend/server/BlktapController.py
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Philipp Hahn writes ("Re: [PATCHv2] insufficient quoting between "tap-ctl list" and xend/server/BlktapController.py"):
> Argh, I submitted the wrong patch. The "line.split(None, 4)" needs to be 
> a "3", because 3 splits needs to be done to get the 4 parts.

Oops.  Thanks for submitting the fix.  I have applied it.

But please remember next time to include a proper signed-off-by.  In
this case, since it was only a single-character change, I applied it
anyway (the interdiff, since the previous version went in already).

Also this kind of thing shows how little review xend patches get
nowadays.  Users of xend are well-advised to switch away before they
trip over some rotting code...

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 08 17:32:19 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 Dec 2011 17:32:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYhoe-0002cw-0s; Thu, 08 Dec 2011 17:31:28 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RYhoc-0002cH-Jl
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 17:31:26 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1323365396!48244163!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDg5NQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31771 invoked from network); 8 Dec 2011 17:29:56 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Dec 2011 17:29:56 -0000
X-IronPort-AV: E=Sophos;i="4.71,320,1320624000"; 
   d="scan'208";a="9369608"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Dec 2011 17:30:38 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 8 Dec 2011 17:30:38 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RYhnp-0002oq-Tb; Thu, 08 Dec 2011 17:30:37 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RYhnp-0006fe-Qp;
	Thu, 08 Dec 2011 17:30:37 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20192.62525.820432.299314@mariner.uk.xensource.com>
Date: Thu, 8 Dec 2011 17:30:37 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1323265864.23681.180.camel@zakaz.uk.xensource.com>
References: <1323108621-22654-1-git-send-email-ian.jackson@eu.citrix.com>
	<1323108621-22654-3-git-send-email-ian.jackson@eu.citrix.com>
	<1323265864.23681.180.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 02/15] libxenstore: Provide xs_check_watch
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("Re: [Xen-devel] [PATCH 02/15] libxenstore: Provide xs_check_watch"):
> Are we supposed to do something to the SONAME with this kind of change?

Good point.  I think that the MINOR should change since the change is
backwards- but not forwards-compatible.

So I have updated (in my tree) the MINOR and will add your ack.

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 08 17:32:19 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 Dec 2011 17:32:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYhoe-0002cw-0s; Thu, 08 Dec 2011 17:31:28 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RYhoc-0002cH-Jl
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 17:31:26 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1323365396!48244163!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDg5NQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31771 invoked from network); 8 Dec 2011 17:29:56 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Dec 2011 17:29:56 -0000
X-IronPort-AV: E=Sophos;i="4.71,320,1320624000"; 
   d="scan'208";a="9369608"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Dec 2011 17:30:38 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 8 Dec 2011 17:30:38 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RYhnp-0002oq-Tb; Thu, 08 Dec 2011 17:30:37 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RYhnp-0006fe-Qp;
	Thu, 08 Dec 2011 17:30:37 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20192.62525.820432.299314@mariner.uk.xensource.com>
Date: Thu, 8 Dec 2011 17:30:37 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1323265864.23681.180.camel@zakaz.uk.xensource.com>
References: <1323108621-22654-1-git-send-email-ian.jackson@eu.citrix.com>
	<1323108621-22654-3-git-send-email-ian.jackson@eu.citrix.com>
	<1323265864.23681.180.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 02/15] libxenstore: Provide xs_check_watch
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("Re: [Xen-devel] [PATCH 02/15] libxenstore: Provide xs_check_watch"):
> Are we supposed to do something to the SONAME with this kind of change?

Good point.  I think that the MINOR should change since the change is
backwards- but not forwards-compatible.

So I have updated (in my tree) the MINOR and will add your ack.

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 08 17:33:33 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 Dec 2011 17:33:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYhq4-0002mp-MH; Thu, 08 Dec 2011 17:32:56 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RYhq3-0002m7-T8
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 17:32:56 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1323365527!6396410!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDg5NQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31345 invoked from network); 8 Dec 2011 17:32:07 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Dec 2011 17:32:07 -0000
X-IronPort-AV: E=Sophos;i="4.71,320,1320624000"; 
   d="scan'208";a="9369633"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Dec 2011 17:32:07 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 8 Dec 2011 17:32:07 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RYhpG-0002pO-Rx; Thu, 08 Dec 2011 17:32:06 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RYhpG-0006hE-RH;
	Thu, 08 Dec 2011 17:32:06 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20192.62614.834620.854206@mariner.uk.xensource.com>
Date: Thu, 8 Dec 2011 17:32:06 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1323266132.23681.184.camel@zakaz.uk.xensource.com>
References: <1323108621-22654-1-git-send-email-ian.jackson@eu.citrix.com>
	<1323108621-22654-5-git-send-email-ian.jackson@eu.citrix.com>
	<1323266132.23681.184.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 04/15] libxl: idl: support new "private"
 type attribute
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("Re: [Xen-devel] [PATCH 04/15] libxl: idl: support new "private" type attribute"):
> Acked-by: Ian Campbell <ian.campbell@citrix.com>
>
> iff you remove the stray print sys.stderr in the last hunk.

Oops, done, thanks.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 08 17:33:33 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 Dec 2011 17:33:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYhq4-0002mp-MH; Thu, 08 Dec 2011 17:32:56 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RYhq3-0002m7-T8
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 17:32:56 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1323365527!6396410!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDg5NQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31345 invoked from network); 8 Dec 2011 17:32:07 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Dec 2011 17:32:07 -0000
X-IronPort-AV: E=Sophos;i="4.71,320,1320624000"; 
   d="scan'208";a="9369633"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Dec 2011 17:32:07 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 8 Dec 2011 17:32:07 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RYhpG-0002pO-Rx; Thu, 08 Dec 2011 17:32:06 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RYhpG-0006hE-RH;
	Thu, 08 Dec 2011 17:32:06 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20192.62614.834620.854206@mariner.uk.xensource.com>
Date: Thu, 8 Dec 2011 17:32:06 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1323266132.23681.184.camel@zakaz.uk.xensource.com>
References: <1323108621-22654-1-git-send-email-ian.jackson@eu.citrix.com>
	<1323108621-22654-5-git-send-email-ian.jackson@eu.citrix.com>
	<1323266132.23681.184.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 04/15] libxl: idl: support new "private"
 type attribute
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("Re: [Xen-devel] [PATCH 04/15] libxl: idl: support new "private" type attribute"):
> Acked-by: Ian Campbell <ian.campbell@citrix.com>
>
> iff you remove the stray print sys.stderr in the last hunk.

Oops, done, thanks.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 08 17:47:23 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 Dec 2011 17:47:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYi3S-0003HZ-7R; Thu, 08 Dec 2011 17:46:46 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RYi3Q-0003HO-RK
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 17:46:45 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1323366356!6401030!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDg5NQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9801 invoked from network); 8 Dec 2011 17:45:56 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Dec 2011 17:45:56 -0000
X-IronPort-AV: E=Sophos;i="4.71,320,1320624000"; 
   d="scan'208";a="9369784"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Dec 2011 17:45:56 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 8 Dec 2011 17:45:56 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RYi2d-0002u1-TA;
	Thu, 08 Dec 2011 17:45:55 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RYi2d-0000oW-J9;
	Thu, 08 Dec 2011 17:45:55 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <E1RYi2d-0000oW-J9@woking.xci-test.com>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 8 Dec 2011 17:45:55 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com, keir@xen.org, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [xen-unstable bisection] complete test-amd64-i386-win
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

branch xen-unstable
xen branch xen-unstable
job test-amd64-i386-win
test guest-saverestore

Tree: linux git://github.com/jsgf/linux-xen.git
Tree: qemu git://hg.uk.xensource.com/HG/qemu-xen-unstable.git
Tree: xen http://xenbits.xen.org/staging/xen-unstable.hg

*** Found and reproduced problem changeset ***

  Bug is in tree:  qemu git://hg.uk.xensource.com/HG/qemu-xen-unstable.git
  Bug introduced:  13b06e700528b1c4258ce5d768d69b0d499f75ca
  Bug not present: 89daacab7035d408f32f2cb1acf68c96d6cbefed


  commit 13b06e700528b1c4258ce5d768d69b0d499f75ca
  Author: Sefano Stabellini <stefano.stabellini@eu.citrix.com>
  Date:   Thu Dec 1 17:52:01 2011 +0000
  
      xen: don't initialize the RTC timers if xen is available
      
      Xen doesn't need full RTC emulation in Qemu because the RTC is already
      emulated by the hypervisor. Hence don't initialize the RTC timers when Xen is
      available so that Qemu doesn't need to wake up needlessly.
      
      Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>


For bisection revision-tuple graph see:
   http://www.chiark.greenend.org.uk/~xensrcts/results/bisect.xen-unstable.test-amd64-i386-win.guest-saverestore.html
Revision IDs in each graph node refer, respectively, to the Trees above.

----------------------------------------
Searching for failure / basis pass:
 10401 fail [host=gall-mite] / 10202 [host=potato-beetle] 10201 [host=itch-mite] 10195 [host=leaf-beetle] 10192 [host=field-cricket] 10191 [host=bush-cricket] 10190 ok.
Failure / basis pass flights: 10401 / 10190
Tree: linux git://github.com/jsgf/linux-xen.git
Tree: qemu git://hg.uk.xensource.com/HG/qemu-xen-unstable.git
Tree: xen http://xenbits.xen.org/staging/xen-unstable.hg
Latest 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 68af5b5191593223709680b89951dfc84a32bee8 38eb74c01d9d
Basis pass 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 89daacab7035d408f32f2cb1acf68c96d6cbefed 64088ba60263
Generating revisions with ./adhoc-revtuple-generator  git://github.com/jsgf/linux-xen.git#6bec8b4a4c14095d0b7ce424db9d583c3decae6c-6bec8b4a4c14095d0b7ce424db9d583c3decae6c git://hg.uk.xensource.com/HG/qemu-xen-unstable.git#89daacab7035d408f32f2cb1acf68c96d6cbefed-68af5b5191593223709680b89951dfc84a32bee8 http://xenbits.xen.org/staging/xen-unstable.hg#64088ba60263-38eb74c01d9d
using cache /export/home/osstest/repos/git-cache...
using cache /export/home/osstest/repos/git-cache...
locked cache /export/home/osstest/repos/git-cache...
processing ./cacheing-git clone --bare git://hg.uk.xensource.com/HG/qemu-xen-unstable.git /export/home/osstest/repos/qemu-xen-unstable...
Initialized empty Git repository in /export/home/osstest/repos/qemu-xen-unstable/
Initialized empty Git repository in /export/home/osstest/repos/qemu-xen-unstable/
updating cache /export/home/osstest/repos/git-cache qemu-xen-unstable...
pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
searching for changes
adding changesets
adding manifests
adding file changes
added 3 changesets with 3 changes to 3 files
3 files updated, 0 files merged, 0 files removed, 0 files unresolved
using cache /export/home/osstest/repos/git-cache...
using cache /export/home/osstest/repos/git-cache...
locked cache /export/home/osstest/repos/git-cache...
processing ./cacheing-git clone --bare git://hg.uk.xensource.com/HG/qemu-xen-unstable.git /export/home/osstest/repos/qemu-xen-unstable...
Initialized empty Git repository in /export/home/osstest/repos/qemu-xen-unstable/
updating cache /export/home/osstest/repos/git-cache qemu-xen-unstable...
pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
searching for changes
no changes found
Loaded 1018 nodes in revision graph
Searching for test results:
 10231 [host=moss-bug]
 10244 []
 10195 [host=leaf-beetle]
 10201 [host=itch-mite]
 10202 [host=potato-beetle]
 10190 pass 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 89daacab7035d408f32f2cb1acf68c96d6cbefed 64088ba60263
 10191 [host=bush-cricket]
 10192 [host=field-cricket]
 10214 [host=bush-cricket]
 10257 [host=bush-cricket]
 10239 [host=field-cricket]
 10246 fail 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 65b27b1dd6f205835aa8174031eea057c75f8afb 491c3ebf1d37
 10264 [host=bush-cricket]
 10313 [host=bush-cricket]
 10289 [host=potato-beetle]
 10332 [host=field-cricket]
 10294 [host=leaf-beetle]
 10298 [host=bush-cricket]
 10347 [host=lace-bug]
 10300 [host=field-cricket]
 10317 [host=potato-beetle]
 10305 [host=bush-cricket]
 10322 [host=itch-mite]
 10325 [host=bush-cricket]
 10344 [host=itch-mite]
 10360 [host=itch-mite]
 10353 fail 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 68af5b5191593223709680b89951dfc84a32bee8 9961a6d5356a
 10371 [host=itch-mite]
 10390 [host=bush-cricket]
 10393 [host=field-cricket]
 10397 [host=itch-mite]
 10398 [host=field-cricket]
 10426 pass 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 89daacab7035d408f32f2cb1acf68c96d6cbefed ad5941e51c87
 10399 [host=field-cricket]
 10400 [host=field-cricket]
 10402 [host=itch-mite]
 10403 [host=itch-mite]
 10404 [host=itch-mite]
 10401 fail 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 68af5b5191593223709680b89951dfc84a32bee8 38eb74c01d9d
 10405 [host=itch-mite]
 10406 pass 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 89daacab7035d408f32f2cb1acf68c96d6cbefed 64088ba60263
 10407 fail 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 68af5b5191593223709680b89951dfc84a32bee8 38eb74c01d9d
 10408 fail 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 9fa2794d45ba915b42b77d4762dfa607d5587dfc b776fcd4a15c
 10410 pass 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 89daacab7035d408f32f2cb1acf68c96d6cbefed 3e5683b6b37f
 10411 pass 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 89daacab7035d408f32f2cb1acf68c96d6cbefed d1b9700fa239
 10412 blocked 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 89daacab7035d408f32f2cb1acf68c96d6cbefed 284ae13b2e54
 10414 pass 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 89daacab7035d408f32f2cb1acf68c96d6cbefed 62ff6a318c5d
 10415 pass 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 89daacab7035d408f32f2cb1acf68c96d6cbefed f30a33c5b5bd
 10417 pass 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 89daacab7035d408f32f2cb1acf68c96d6cbefed b6962c4b0dfd
 10418 fail 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 13b06e700528b1c4258ce5d768d69b0d499f75ca ad5941e51c87
 10419 pass 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 89daacab7035d408f32f2cb1acf68c96d6cbefed 6bac46816504
 10421 pass 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 89daacab7035d408f32f2cb1acf68c96d6cbefed ad5941e51c87
 10422 fail 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 13b06e700528b1c4258ce5d768d69b0d499f75ca ad5941e51c87
 10423 pass 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 89daacab7035d408f32f2cb1acf68c96d6cbefed ad5941e51c87
 10425 fail 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 13b06e700528b1c4258ce5d768d69b0d499f75ca ad5941e51c87
 10441 fail 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 13b06e700528b1c4258ce5d768d69b0d499f75ca ad5941e51c87
Searching for interesting versions
 Result found: flight 10190 (pass), for basis pass
 Result found: flight 10401 (fail), for basis failure
 Repro found: flight 10406 (pass), for basis pass
 Repro found: flight 10407 (fail), for basis failure
 0 revisions at 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 89daacab7035d408f32f2cb1acf68c96d6cbefed ad5941e51c87
No revisions left to test, checking graph state.
 Result found: flight 10421 (pass), for last pass
 Result found: flight 10422 (fail), for first failure
 Repro found: flight 10423 (pass), for last pass
 Repro found: flight 10425 (fail), for first failure
 Repro found: flight 10426 (pass), for last pass
 Repro found: flight 10441 (fail), for first failure

*** Found and reproduced problem changeset ***

  Bug is in tree:  qemu git://hg.uk.xensource.com/HG/qemu-xen-unstable.git
  Bug introduced:  13b06e700528b1c4258ce5d768d69b0d499f75ca
  Bug not present: 89daacab7035d408f32f2cb1acf68c96d6cbefed

using cache /export/home/osstest/repos/git-cache...
using cache /export/home/osstest/repos/git-cache...
locked cache /export/home/osstest/repos/git-cache...
processing ./cacheing-git clone --bare git://hg.uk.xensource.com/HG/qemu-xen-unstable.git /export/home/osstest/repos/qemu-xen-unstable...
Initialized empty Git repository in /export/home/osstest/repos/qemu-xen-unstable/
updating cache /export/home/osstest/repos/git-cache qemu-xen-unstable...

  commit 13b06e700528b1c4258ce5d768d69b0d499f75ca
  Author: Sefano Stabellini <stefano.stabellini@eu.citrix.com>
  Date:   Thu Dec 1 17:52:01 2011 +0000
  
      xen: don't initialize the RTC timers if xen is available
      
      Xen doesn't need full RTC emulation in Qemu because the RTC is already
      emulated by the hypervisor. Hence don't initialize the RTC timers when Xen is
      available so that Qemu doesn't need to wake up needlessly.
      
      Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Revision graph left in /home/xc_osstest/results/bisect.xen-unstable.test-amd64-i386-win.guest-saverestore.{dot,ps,png,html}.
----------------------------------------
10441: ALL FAIL

flight 10441 xen-unstable real-bisect [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10441/


jobs:
 test-amd64-i386-win                                          fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 08 17:47:23 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 Dec 2011 17:47:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYi3S-0003HZ-7R; Thu, 08 Dec 2011 17:46:46 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RYi3Q-0003HO-RK
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 17:46:45 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1323366356!6401030!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDg5NQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9801 invoked from network); 8 Dec 2011 17:45:56 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Dec 2011 17:45:56 -0000
X-IronPort-AV: E=Sophos;i="4.71,320,1320624000"; 
   d="scan'208";a="9369784"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Dec 2011 17:45:56 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 8 Dec 2011 17:45:56 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RYi2d-0002u1-TA;
	Thu, 08 Dec 2011 17:45:55 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RYi2d-0000oW-J9;
	Thu, 08 Dec 2011 17:45:55 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <E1RYi2d-0000oW-J9@woking.xci-test.com>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 8 Dec 2011 17:45:55 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com, keir@xen.org, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [xen-unstable bisection] complete test-amd64-i386-win
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

branch xen-unstable
xen branch xen-unstable
job test-amd64-i386-win
test guest-saverestore

Tree: linux git://github.com/jsgf/linux-xen.git
Tree: qemu git://hg.uk.xensource.com/HG/qemu-xen-unstable.git
Tree: xen http://xenbits.xen.org/staging/xen-unstable.hg

*** Found and reproduced problem changeset ***

  Bug is in tree:  qemu git://hg.uk.xensource.com/HG/qemu-xen-unstable.git
  Bug introduced:  13b06e700528b1c4258ce5d768d69b0d499f75ca
  Bug not present: 89daacab7035d408f32f2cb1acf68c96d6cbefed


  commit 13b06e700528b1c4258ce5d768d69b0d499f75ca
  Author: Sefano Stabellini <stefano.stabellini@eu.citrix.com>
  Date:   Thu Dec 1 17:52:01 2011 +0000
  
      xen: don't initialize the RTC timers if xen is available
      
      Xen doesn't need full RTC emulation in Qemu because the RTC is already
      emulated by the hypervisor. Hence don't initialize the RTC timers when Xen is
      available so that Qemu doesn't need to wake up needlessly.
      
      Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>


For bisection revision-tuple graph see:
   http://www.chiark.greenend.org.uk/~xensrcts/results/bisect.xen-unstable.test-amd64-i386-win.guest-saverestore.html
Revision IDs in each graph node refer, respectively, to the Trees above.

----------------------------------------
Searching for failure / basis pass:
 10401 fail [host=gall-mite] / 10202 [host=potato-beetle] 10201 [host=itch-mite] 10195 [host=leaf-beetle] 10192 [host=field-cricket] 10191 [host=bush-cricket] 10190 ok.
Failure / basis pass flights: 10401 / 10190
Tree: linux git://github.com/jsgf/linux-xen.git
Tree: qemu git://hg.uk.xensource.com/HG/qemu-xen-unstable.git
Tree: xen http://xenbits.xen.org/staging/xen-unstable.hg
Latest 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 68af5b5191593223709680b89951dfc84a32bee8 38eb74c01d9d
Basis pass 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 89daacab7035d408f32f2cb1acf68c96d6cbefed 64088ba60263
Generating revisions with ./adhoc-revtuple-generator  git://github.com/jsgf/linux-xen.git#6bec8b4a4c14095d0b7ce424db9d583c3decae6c-6bec8b4a4c14095d0b7ce424db9d583c3decae6c git://hg.uk.xensource.com/HG/qemu-xen-unstable.git#89daacab7035d408f32f2cb1acf68c96d6cbefed-68af5b5191593223709680b89951dfc84a32bee8 http://xenbits.xen.org/staging/xen-unstable.hg#64088ba60263-38eb74c01d9d
using cache /export/home/osstest/repos/git-cache...
using cache /export/home/osstest/repos/git-cache...
locked cache /export/home/osstest/repos/git-cache...
processing ./cacheing-git clone --bare git://hg.uk.xensource.com/HG/qemu-xen-unstable.git /export/home/osstest/repos/qemu-xen-unstable...
Initialized empty Git repository in /export/home/osstest/repos/qemu-xen-unstable/
Initialized empty Git repository in /export/home/osstest/repos/qemu-xen-unstable/
updating cache /export/home/osstest/repos/git-cache qemu-xen-unstable...
pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
searching for changes
adding changesets
adding manifests
adding file changes
added 3 changesets with 3 changes to 3 files
3 files updated, 0 files merged, 0 files removed, 0 files unresolved
using cache /export/home/osstest/repos/git-cache...
using cache /export/home/osstest/repos/git-cache...
locked cache /export/home/osstest/repos/git-cache...
processing ./cacheing-git clone --bare git://hg.uk.xensource.com/HG/qemu-xen-unstable.git /export/home/osstest/repos/qemu-xen-unstable...
Initialized empty Git repository in /export/home/osstest/repos/qemu-xen-unstable/
updating cache /export/home/osstest/repos/git-cache qemu-xen-unstable...
pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
searching for changes
no changes found
Loaded 1018 nodes in revision graph
Searching for test results:
 10231 [host=moss-bug]
 10244 []
 10195 [host=leaf-beetle]
 10201 [host=itch-mite]
 10202 [host=potato-beetle]
 10190 pass 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 89daacab7035d408f32f2cb1acf68c96d6cbefed 64088ba60263
 10191 [host=bush-cricket]
 10192 [host=field-cricket]
 10214 [host=bush-cricket]
 10257 [host=bush-cricket]
 10239 [host=field-cricket]
 10246 fail 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 65b27b1dd6f205835aa8174031eea057c75f8afb 491c3ebf1d37
 10264 [host=bush-cricket]
 10313 [host=bush-cricket]
 10289 [host=potato-beetle]
 10332 [host=field-cricket]
 10294 [host=leaf-beetle]
 10298 [host=bush-cricket]
 10347 [host=lace-bug]
 10300 [host=field-cricket]
 10317 [host=potato-beetle]
 10305 [host=bush-cricket]
 10322 [host=itch-mite]
 10325 [host=bush-cricket]
 10344 [host=itch-mite]
 10360 [host=itch-mite]
 10353 fail 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 68af5b5191593223709680b89951dfc84a32bee8 9961a6d5356a
 10371 [host=itch-mite]
 10390 [host=bush-cricket]
 10393 [host=field-cricket]
 10397 [host=itch-mite]
 10398 [host=field-cricket]
 10426 pass 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 89daacab7035d408f32f2cb1acf68c96d6cbefed ad5941e51c87
 10399 [host=field-cricket]
 10400 [host=field-cricket]
 10402 [host=itch-mite]
 10403 [host=itch-mite]
 10404 [host=itch-mite]
 10401 fail 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 68af5b5191593223709680b89951dfc84a32bee8 38eb74c01d9d
 10405 [host=itch-mite]
 10406 pass 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 89daacab7035d408f32f2cb1acf68c96d6cbefed 64088ba60263
 10407 fail 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 68af5b5191593223709680b89951dfc84a32bee8 38eb74c01d9d
 10408 fail 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 9fa2794d45ba915b42b77d4762dfa607d5587dfc b776fcd4a15c
 10410 pass 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 89daacab7035d408f32f2cb1acf68c96d6cbefed 3e5683b6b37f
 10411 pass 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 89daacab7035d408f32f2cb1acf68c96d6cbefed d1b9700fa239
 10412 blocked 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 89daacab7035d408f32f2cb1acf68c96d6cbefed 284ae13b2e54
 10414 pass 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 89daacab7035d408f32f2cb1acf68c96d6cbefed 62ff6a318c5d
 10415 pass 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 89daacab7035d408f32f2cb1acf68c96d6cbefed f30a33c5b5bd
 10417 pass 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 89daacab7035d408f32f2cb1acf68c96d6cbefed b6962c4b0dfd
 10418 fail 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 13b06e700528b1c4258ce5d768d69b0d499f75ca ad5941e51c87
 10419 pass 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 89daacab7035d408f32f2cb1acf68c96d6cbefed 6bac46816504
 10421 pass 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 89daacab7035d408f32f2cb1acf68c96d6cbefed ad5941e51c87
 10422 fail 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 13b06e700528b1c4258ce5d768d69b0d499f75ca ad5941e51c87
 10423 pass 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 89daacab7035d408f32f2cb1acf68c96d6cbefed ad5941e51c87
 10425 fail 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 13b06e700528b1c4258ce5d768d69b0d499f75ca ad5941e51c87
 10441 fail 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 13b06e700528b1c4258ce5d768d69b0d499f75ca ad5941e51c87
Searching for interesting versions
 Result found: flight 10190 (pass), for basis pass
 Result found: flight 10401 (fail), for basis failure
 Repro found: flight 10406 (pass), for basis pass
 Repro found: flight 10407 (fail), for basis failure
 0 revisions at 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 89daacab7035d408f32f2cb1acf68c96d6cbefed ad5941e51c87
No revisions left to test, checking graph state.
 Result found: flight 10421 (pass), for last pass
 Result found: flight 10422 (fail), for first failure
 Repro found: flight 10423 (pass), for last pass
 Repro found: flight 10425 (fail), for first failure
 Repro found: flight 10426 (pass), for last pass
 Repro found: flight 10441 (fail), for first failure

*** Found and reproduced problem changeset ***

  Bug is in tree:  qemu git://hg.uk.xensource.com/HG/qemu-xen-unstable.git
  Bug introduced:  13b06e700528b1c4258ce5d768d69b0d499f75ca
  Bug not present: 89daacab7035d408f32f2cb1acf68c96d6cbefed

using cache /export/home/osstest/repos/git-cache...
using cache /export/home/osstest/repos/git-cache...
locked cache /export/home/osstest/repos/git-cache...
processing ./cacheing-git clone --bare git://hg.uk.xensource.com/HG/qemu-xen-unstable.git /export/home/osstest/repos/qemu-xen-unstable...
Initialized empty Git repository in /export/home/osstest/repos/qemu-xen-unstable/
updating cache /export/home/osstest/repos/git-cache qemu-xen-unstable...

  commit 13b06e700528b1c4258ce5d768d69b0d499f75ca
  Author: Sefano Stabellini <stefano.stabellini@eu.citrix.com>
  Date:   Thu Dec 1 17:52:01 2011 +0000
  
      xen: don't initialize the RTC timers if xen is available
      
      Xen doesn't need full RTC emulation in Qemu because the RTC is already
      emulated by the hypervisor. Hence don't initialize the RTC timers when Xen is
      available so that Qemu doesn't need to wake up needlessly.
      
      Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Revision graph left in /home/xc_osstest/results/bisect.xen-unstable.test-amd64-i386-win.guest-saverestore.{dot,ps,png,html}.
----------------------------------------
10441: ALL FAIL

flight 10441 xen-unstable real-bisect [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10441/


jobs:
 test-amd64-i386-win                                          fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 08 18:17:43 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 Dec 2011 18:17:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYiWy-0004HV-5g; Thu, 08 Dec 2011 18:17:16 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RYiWw-0004HO-TM
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 18:17:15 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1323368186!6727850!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDg5NQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31995 invoked from network); 8 Dec 2011 18:16:26 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Dec 2011 18:16:26 -0000
X-IronPort-AV: E=Sophos;i="4.71,320,1320624000"; 
   d="scan'208";a="9370341"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Dec 2011 18:16:26 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 8 Dec 2011 18:16:26 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RYiWA-00034T-5l; Thu, 08 Dec 2011 18:16:26 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RYiWA-00069H-2V;
	Thu, 08 Dec 2011 18:16:26 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20192.65274.13650.451424@mariner.uk.xensource.com>
Date: Thu, 8 Dec 2011 18:16:26 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1323266816.23681.189.camel@zakaz.uk.xensource.com>
References: <1323108621-22654-1-git-send-email-ian.jackson@eu.citrix.com>
	<1323108621-22654-7-git-send-email-ian.jackson@eu.citrix.com>
	<1323266816.23681.189.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 06/15] libxl: permit declaration after
 statement
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("Re: [Xen-devel] [PATCH 06/15] libxl: permit declaration after statement"):
> I'm happy with this so far as it goes but I was wondering where the
> original -Wdeclaration-after-statement came from, do we actually mean
> "-std=c99" or something along those lines?

 gcc  -O1 -fno-omit-frame-pointer -m32 -march=i686 -g -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wno-unused-value -Wdeclaration-after-statement   -D__XEN_TOOLS__ -MMD -MF .libxl.o.d -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -fno-optimize-sibling-calls -mno-tls-direct-seg-refs -Werror -Wno-format-zero-length -Wmissing-declarations -I. -fPIC -I/u/iwj/work/2/xen-unstable.git/tools/libxl/../../tools/libxc -I/u/iwj/work/2/xen-unstable.git/tools/libxl/../../tools/include -I/u/iwj/work/2/xen-unstable.git/tools/libxl/../../tools/libxc -I/u/iwj/work/2/xen-unstable.git/tools/libxl/../../tools/include -I/u/iwj/work/2/xen-unstable.git/tools/libxl/../../tools/xenstore -I/u/iwj/work/2/xen-unstable.git/tools/libxl/../../tools/include -I/u/iwj/work/2/xen-unstable.git/tools/libxl/../../tools/blktap2/control -I/u/iwj/work/2/xen-unstable.git/tools/libxl/../../tools/blktap2/include -I/u/iwj/work/2/xen-unstable.git/tools/libxl/../../tools/include  -c -o libxl.o libxl.c  

So cutting that down to the relevant bits:

 gcc ... -std=gnu99 -Wall ... -Wdeclaration-after-statement ... -Werror ...

The -Wdeclaration-after-statement comes from Config.mk:

 $(call cc-option-add,HOSTCFLAGS,HOSTCC,-Wdeclaration-after-statement)
 $(call cc-option-add,CFLAGS,CC,-Wdeclaration-after-statement)

So I think that since what we're doing is having a different rule for
libxl, it's right to put it in libxl's makefile.

Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 08 18:17:43 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 Dec 2011 18:17:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYiWy-0004HV-5g; Thu, 08 Dec 2011 18:17:16 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RYiWw-0004HO-TM
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 18:17:15 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1323368186!6727850!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDg5NQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31995 invoked from network); 8 Dec 2011 18:16:26 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Dec 2011 18:16:26 -0000
X-IronPort-AV: E=Sophos;i="4.71,320,1320624000"; 
   d="scan'208";a="9370341"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Dec 2011 18:16:26 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 8 Dec 2011 18:16:26 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RYiWA-00034T-5l; Thu, 08 Dec 2011 18:16:26 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RYiWA-00069H-2V;
	Thu, 08 Dec 2011 18:16:26 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20192.65274.13650.451424@mariner.uk.xensource.com>
Date: Thu, 8 Dec 2011 18:16:26 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1323266816.23681.189.camel@zakaz.uk.xensource.com>
References: <1323108621-22654-1-git-send-email-ian.jackson@eu.citrix.com>
	<1323108621-22654-7-git-send-email-ian.jackson@eu.citrix.com>
	<1323266816.23681.189.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 06/15] libxl: permit declaration after
 statement
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("Re: [Xen-devel] [PATCH 06/15] libxl: permit declaration after statement"):
> I'm happy with this so far as it goes but I was wondering where the
> original -Wdeclaration-after-statement came from, do we actually mean
> "-std=c99" or something along those lines?

 gcc  -O1 -fno-omit-frame-pointer -m32 -march=i686 -g -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wno-unused-value -Wdeclaration-after-statement   -D__XEN_TOOLS__ -MMD -MF .libxl.o.d -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -fno-optimize-sibling-calls -mno-tls-direct-seg-refs -Werror -Wno-format-zero-length -Wmissing-declarations -I. -fPIC -I/u/iwj/work/2/xen-unstable.git/tools/libxl/../../tools/libxc -I/u/iwj/work/2/xen-unstable.git/tools/libxl/../../tools/include -I/u/iwj/work/2/xen-unstable.git/tools/libxl/../../tools/libxc -I/u/iwj/work/2/xen-unstable.git/tools/libxl/../../tools/include -I/u/iwj/work/2/xen-unstable.git/tools/libxl/../../tools/xenstore -I/u/iwj/work/2/xen-unstable.git/tools/libxl/../../tools/include -I/u/iwj/work/2/xen-unstable.git/tools/libxl/../../tools/blktap2/control -I/u/iwj/work/2/xen-unstable.git/tools/libxl/../../tools/blktap2/include -I/u/iwj/work/2/xen-unstable.git/tools/libxl/../../tools/include  -c -o libxl.o libxl.c  

So cutting that down to the relevant bits:

 gcc ... -std=gnu99 -Wall ... -Wdeclaration-after-statement ... -Werror ...

The -Wdeclaration-after-statement comes from Config.mk:

 $(call cc-option-add,HOSTCFLAGS,HOSTCC,-Wdeclaration-after-statement)
 $(call cc-option-add,CFLAGS,CC,-Wdeclaration-after-statement)

So I think that since what we're doing is having a different rule for
libxl, it's right to put it in libxl's makefile.

Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 08 19:14:53 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 Dec 2011 19:14:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYjQ8-0005Qt-0m; Thu, 08 Dec 2011 19:14:16 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RYjQ6-0005Qo-Pj
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 19:14:14 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1323371498!55413716!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDg5NQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13440 invoked from network); 8 Dec 2011 19:11:38 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Dec 2011 19:11:38 -0000
X-IronPort-AV: E=Sophos;i="4.71,321,1320624000"; 
   d="scan'208";a="9370909"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Dec 2011 19:13:26 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 8 Dec 2011 19:13:26 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RYjPJ-0003Ne-Sz; Thu, 08 Dec 2011 19:13:25 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RYjPJ-0006Fy-RW;
	Thu, 08 Dec 2011 19:13:25 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20193.3157.842173.339205@mariner.uk.xensource.com>
Date: Thu, 8 Dec 2011 19:13:25 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1323275280.2969.3.camel@zakaz.uk.xensource.com>
References: <1323108621-22654-1-git-send-email-ian.jackson@eu.citrix.com>
	<1323108621-22654-13-git-send-email-ian.jackson@eu.citrix.com>
	<1323275280.2969.3.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 12/15] libxl: Use GC_INIT and GC_FREE
 everywhere
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("Re: [Xen-devel] [PATCH 12/15] libxl: Use GC_INIT and GC_FREE everywhere"):
> On Mon, 2011-12-05 at 18:10 +0000, Ian Jackson wrote:
> >     GC_FREE;
> 
> I suppose this really relates to the earlier patch which adds these
> macros but wouldn't "GC_FREE();" be nicer?

I don't normally write zero-adic statement macros that way.  I guess
this is just one of those stylistic points like whether to put parens
around the argument to return.

We don't currently have any other zero-adic statement macros in libxl,
nor any macros which depend on or introduce names in the caller's
namespace, apart from those we inherit from flex.

My personal view is that non-hygienic statement macros are unusual
enough that it's worth drawing attention to them by using a special
syntax.  After all, their semantics are not normally very like
functions because they refer to objects, including local variables,
not explicitly named in the call.  Often they declare variables or
labels, and those kinds of statements don't contain any ().  So I
think the empty () are misleading - they hint that the thing is a
function, when it really isn't enough like a function.

In the rest of the xen tree we seem to have these without the "()" [1]:
    tools/libxen/test/test_event_handling.c:        CLEANUP;
    tools/blktap2/drivers/lock.c:                XSLEEP;
and these with the "()" [2]:
    xen/drivers/acpi/osl.c:         BUG();
    xen/arch/ia64/asm-offsets.c:    BLANK();
    xen/common/inflate.c:    NEXTBYTE();

Of these:

 CLEANUP    non-hygienic block
 NEXTBYTE() non-hygienic block wrapped up in () to make it an expression
 XSLEEP     hygienic expression (a call to usleep)
 BUG()      hygienic expression (a call to asm)
 BLANK()    something in some kind of table, not really relevant here

This doesn't seem to provide any consistent rule.

Perhaps the right answer is a patch to the coding standard.  One
option for this below.  This is a bit of a bikeshed issue of course.

Ian.

[1] find * -name \*.c | xargs egrep '^[   ]*[A-Z][A-Z]*\;' |less
[2] find * -name \*.c | xargs egrep '^[   ]*[A-Z][A-Z]*\(\)' |less
  in both cases only one hit per macro mentioned


diff --git a/tools/libxl/CODING_STYLE b/tools/libxl/CODING_STYLE
index 110a48f..69fedb9 100644
--- a/tools/libxl/CODING_STYLE
+++ b/tools/libxl/CODING_STYLE
@@ -133,3 +133,25 @@ Rationale: a consistent (except for functions...) bracing style reduces
 ambiguity and avoids needless churn when lines are added or removed.
 Furthermore, it is the libxenlight coding style.
 
+
+6. Macros
+
+Naturally, macros (other than function-like ones which can be used
+just like functions eg evaluate their arguments each exactly once
+etc.) should be named in ALL_CAPITALS.  Expansions, and references to
+arguments should be protected with appropriate ( ), and code
+with appropriate do{ ... }while(0) blocks.
+
+A zero-argument macro which expands to a non-constant expression, or
+to an ordinary block, should be defined with empty parens like this:
+  #define MACRO() ....
+
+A zero-argument macro which expands to a constant expression; or whose
+expansion relies on (or introduces) declarations, labels, etc., in the
+containing scope; or which expands to another kind of code fragment,
+should be defined like this:
+  #define MACRO ...
+
+Macros expanding to declarations and/or statements should not include
+any trailing ";" so that they may be used like this:
+  MACRO(arguments);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 08 19:14:53 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 Dec 2011 19:14:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYjQ8-0005Qt-0m; Thu, 08 Dec 2011 19:14:16 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RYjQ6-0005Qo-Pj
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 19:14:14 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1323371498!55413716!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDg5NQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13440 invoked from network); 8 Dec 2011 19:11:38 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Dec 2011 19:11:38 -0000
X-IronPort-AV: E=Sophos;i="4.71,321,1320624000"; 
   d="scan'208";a="9370909"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Dec 2011 19:13:26 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 8 Dec 2011 19:13:26 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RYjPJ-0003Ne-Sz; Thu, 08 Dec 2011 19:13:25 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RYjPJ-0006Fy-RW;
	Thu, 08 Dec 2011 19:13:25 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20193.3157.842173.339205@mariner.uk.xensource.com>
Date: Thu, 8 Dec 2011 19:13:25 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1323275280.2969.3.camel@zakaz.uk.xensource.com>
References: <1323108621-22654-1-git-send-email-ian.jackson@eu.citrix.com>
	<1323108621-22654-13-git-send-email-ian.jackson@eu.citrix.com>
	<1323275280.2969.3.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 12/15] libxl: Use GC_INIT and GC_FREE
 everywhere
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("Re: [Xen-devel] [PATCH 12/15] libxl: Use GC_INIT and GC_FREE everywhere"):
> On Mon, 2011-12-05 at 18:10 +0000, Ian Jackson wrote:
> >     GC_FREE;
> 
> I suppose this really relates to the earlier patch which adds these
> macros but wouldn't "GC_FREE();" be nicer?

I don't normally write zero-adic statement macros that way.  I guess
this is just one of those stylistic points like whether to put parens
around the argument to return.

We don't currently have any other zero-adic statement macros in libxl,
nor any macros which depend on or introduce names in the caller's
namespace, apart from those we inherit from flex.

My personal view is that non-hygienic statement macros are unusual
enough that it's worth drawing attention to them by using a special
syntax.  After all, their semantics are not normally very like
functions because they refer to objects, including local variables,
not explicitly named in the call.  Often they declare variables or
labels, and those kinds of statements don't contain any ().  So I
think the empty () are misleading - they hint that the thing is a
function, when it really isn't enough like a function.

In the rest of the xen tree we seem to have these without the "()" [1]:
    tools/libxen/test/test_event_handling.c:        CLEANUP;
    tools/blktap2/drivers/lock.c:                XSLEEP;
and these with the "()" [2]:
    xen/drivers/acpi/osl.c:         BUG();
    xen/arch/ia64/asm-offsets.c:    BLANK();
    xen/common/inflate.c:    NEXTBYTE();

Of these:

 CLEANUP    non-hygienic block
 NEXTBYTE() non-hygienic block wrapped up in () to make it an expression
 XSLEEP     hygienic expression (a call to usleep)
 BUG()      hygienic expression (a call to asm)
 BLANK()    something in some kind of table, not really relevant here

This doesn't seem to provide any consistent rule.

Perhaps the right answer is a patch to the coding standard.  One
option for this below.  This is a bit of a bikeshed issue of course.

Ian.

[1] find * -name \*.c | xargs egrep '^[   ]*[A-Z][A-Z]*\;' |less
[2] find * -name \*.c | xargs egrep '^[   ]*[A-Z][A-Z]*\(\)' |less
  in both cases only one hit per macro mentioned


diff --git a/tools/libxl/CODING_STYLE b/tools/libxl/CODING_STYLE
index 110a48f..69fedb9 100644
--- a/tools/libxl/CODING_STYLE
+++ b/tools/libxl/CODING_STYLE
@@ -133,3 +133,25 @@ Rationale: a consistent (except for functions...) bracing style reduces
 ambiguity and avoids needless churn when lines are added or removed.
 Furthermore, it is the libxenlight coding style.
 
+
+6. Macros
+
+Naturally, macros (other than function-like ones which can be used
+just like functions eg evaluate their arguments each exactly once
+etc.) should be named in ALL_CAPITALS.  Expansions, and references to
+arguments should be protected with appropriate ( ), and code
+with appropriate do{ ... }while(0) blocks.
+
+A zero-argument macro which expands to a non-constant expression, or
+to an ordinary block, should be defined with empty parens like this:
+  #define MACRO() ....
+
+A zero-argument macro which expands to a constant expression; or whose
+expansion relies on (or introduces) declarations, labels, etc., in the
+containing scope; or which expands to another kind of code fragment,
+should be defined like this:
+  #define MACRO ...
+
+Macros expanding to declarations and/or statements should not include
+any trailing ";" so that they may be used like this:
+  MACRO(arguments);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 08 19:16:51 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 Dec 2011 19:16:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYjS6-0005VD-Hs; Thu, 08 Dec 2011 19:16:18 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RYjS5-0005V1-DY
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 19:16:17 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1323371693!50041400!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDg5NQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5336 invoked from network); 8 Dec 2011 19:14:54 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Dec 2011 19:14:54 -0000
X-IronPort-AV: E=Sophos;i="4.71,321,1320624000"; 
   d="scan'208";a="9370938"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Dec 2011 19:15:30 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 8 Dec 2011 19:15:30 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RYjRK-0003OG-DN; Thu, 08 Dec 2011 19:15:30 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RYjRK-0006G8-CU;
	Thu, 08 Dec 2011 19:15:30 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20193.3282.375698.782405@mariner.uk.xensource.com>
Date: Thu, 8 Dec 2011 19:15:30 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1323275646.2969.5.camel@zakaz.uk.xensource.com>
References: <1323108621-22654-1-git-send-email-ian.jackson@eu.citrix.com>
	<1323108621-22654-14-git-send-email-ian.jackson@eu.citrix.com>
	<1323275646.2969.5.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 13/15] libxl: make LIBXL_INIT_GC a statement,
 not an initialiser
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("Re: [Xen-devel] [PATCH 13/15] libxl: make LIBXL_INIT_GC a statement, not an initialiser"):
> On Mon, 2011-12-05 at 18:10 +0000, Ian Jackson wrote:
> > In fact there is only one caller now, GC_INIT,
> 
> Maybe we should just fold LIBXL_INIT_GC into GC_INIT then?

No, because GC_INIT is a non-hygienic convenience macro.  Such things
should never be the only implementation of some important interface,
because then if for any reason the lack of hygiene is a problem for
you you are stuck.

LIBXL_INIT_GC is the underlying functionality which may need to be
used in those other, less usual cases, and therefore still needs to
exist as a separate interface.

Indeed in my asynchronous operations code (patch(es) still very much a
work in progress) I will need to call LIBXL_INIT_GC outside GC_INIT.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 08 19:16:51 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 Dec 2011 19:16:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYjS6-0005VD-Hs; Thu, 08 Dec 2011 19:16:18 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RYjS5-0005V1-DY
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 19:16:17 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1323371693!50041400!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDg5NQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5336 invoked from network); 8 Dec 2011 19:14:54 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Dec 2011 19:14:54 -0000
X-IronPort-AV: E=Sophos;i="4.71,321,1320624000"; 
   d="scan'208";a="9370938"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Dec 2011 19:15:30 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 8 Dec 2011 19:15:30 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RYjRK-0003OG-DN; Thu, 08 Dec 2011 19:15:30 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RYjRK-0006G8-CU;
	Thu, 08 Dec 2011 19:15:30 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20193.3282.375698.782405@mariner.uk.xensource.com>
Date: Thu, 8 Dec 2011 19:15:30 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1323275646.2969.5.camel@zakaz.uk.xensource.com>
References: <1323108621-22654-1-git-send-email-ian.jackson@eu.citrix.com>
	<1323108621-22654-14-git-send-email-ian.jackson@eu.citrix.com>
	<1323275646.2969.5.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 13/15] libxl: make LIBXL_INIT_GC a statement,
 not an initialiser
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("Re: [Xen-devel] [PATCH 13/15] libxl: make LIBXL_INIT_GC a statement, not an initialiser"):
> On Mon, 2011-12-05 at 18:10 +0000, Ian Jackson wrote:
> > In fact there is only one caller now, GC_INIT,
> 
> Maybe we should just fold LIBXL_INIT_GC into GC_INIT then?

No, because GC_INIT is a non-hygienic convenience macro.  Such things
should never be the only implementation of some important interface,
because then if for any reason the lack of hygiene is a problem for
you you are stuck.

LIBXL_INIT_GC is the underlying functionality which may need to be
used in those other, less usual cases, and therefore still needs to
exist as a separate interface.

Indeed in my asynchronous operations code (patch(es) still very much a
work in progress) I will need to call LIBXL_INIT_GC outside GC_INIT.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 08 19:17:16 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 Dec 2011 19:17:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYjSb-0005XW-4K; Thu, 08 Dec 2011 19:16:49 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RYjSZ-0005X4-7S
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 19:16:47 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1323371757!4803542!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDg5NQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23647 invoked from network); 8 Dec 2011 19:15:57 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Dec 2011 19:15:57 -0000
X-IronPort-AV: E=Sophos;i="4.71,321,1320624000"; 
   d="scan'208";a="9370943"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Dec 2011 19:15:56 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 8 Dec 2011 19:15:56 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RYjRk-0003OU-L5;
	Thu, 08 Dec 2011 19:15:56 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RYjRk-0006gA-JN;
	Thu, 08 Dec 2011 19:15:56 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10440-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 8 Dec 2011 19:15:56 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10440: regressions - trouble:
	broken/fail/pass
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10440 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10440/

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-amd64-xl-win7-amd64  3 host-install(3)              broken
 test-i386-i386-pv             3 host-install(3)              broken
 test-amd64-i386-win           8 guest-saverestore         fail REGR. vs. 10201
 test-i386-i386-win            8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-i386-win-vcpus1    8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-amd64-win          8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-amd64-xl-win       3 host-install(3)              broken
 test-i386-i386-xl-win         8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-i386-xl-winxpsp3-vcpus1  3 host-install(3)          broken in 10435
 test-amd64-i386-rhel6hvm-intel  3 host-install(3)              broken in 10435
 test-amd64-amd64-xl-win      8 guest-saverestore fail in 10401 REGR. vs. 10201
 test-amd64-i386-win           3 host-install(3)              broken   in 10424
 test-amd64-i386-xl-win-vcpus1 8 guest-saverestore fail in 10424 REGR. vs. 10201

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf     14 guest-localmigrate/x10      fail pass in 10435
 test-amd64-i386-xl-win-vcpus1  7 windows-install            fail pass in 10424
 test-amd64-amd64-xl-win       7 windows-install    fail in 10435 pass in 10401
 test-amd64-amd64-xl-sedf     11 guest-localmigrate fail in 10401 pass in 10440
 test-amd64-i386-xl-credit2    7 debian-install     fail in 10424 pass in 10440

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-i386-i386-xl-winxpsp3    7 windows-install              fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install          fail never pass
 test-amd64-i386-xl-win7-amd64  7 windows-install              fail  never pass
 test-amd64-i386-xend-winxpsp3  7 windows-install              fail  never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   never pass
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore        fail blocked in 10201
 test-amd64-amd64-xl-win7-amd64  7 windows-install     fail in 10435 never pass
 test-amd64-amd64-xl-sedf-pin 13 guest-localmigrate.2 fail in 10435 blocked in 10201

version targeted for testing:
 xen                  38eb74c01d9d
baseline version:
 xen                  62ff6a318c5d

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scanneel.ca>
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Andres Lagar-Cavilla <andres@lagarcavilla>
  Andrew Cooper <andrew.cooper3@citrix.com>
  Anthony PERARD <anthony.perard@citrix.com>
  Brendan Cully <brendan@cs.ubc.ca>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Haitao Shan <haitao.shan@intel.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@novell.com>
  Jan Beulich <jbeulich@suse.com>
  Jonathan Davies <jonathan.davies@citrix.com>
  juergen.gross@ts.fujitsu.com
  Keir Fraser <keir@xen.org>
  Liu, Jinsong <jinsong.liu@intel.com>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
  Philipp Hahn <hahn@univention.de>
  Shriram Rajagopalan <rshriram@cs.ubc.ca>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang2 <wei.wang2@amd.com>
  Xudong Hao <xudong.hao@intel.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               broken  
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            broken  
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      broken  
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 1493 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 08 19:17:16 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 Dec 2011 19:17:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYjSb-0005XW-4K; Thu, 08 Dec 2011 19:16:49 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RYjSZ-0005X4-7S
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 19:16:47 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1323371757!4803542!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDg5NQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23647 invoked from network); 8 Dec 2011 19:15:57 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Dec 2011 19:15:57 -0000
X-IronPort-AV: E=Sophos;i="4.71,321,1320624000"; 
   d="scan'208";a="9370943"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Dec 2011 19:15:56 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 8 Dec 2011 19:15:56 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RYjRk-0003OU-L5;
	Thu, 08 Dec 2011 19:15:56 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RYjRk-0006gA-JN;
	Thu, 08 Dec 2011 19:15:56 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10440-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 8 Dec 2011 19:15:56 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10440: regressions - trouble:
	broken/fail/pass
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10440 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10440/

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-amd64-xl-win7-amd64  3 host-install(3)              broken
 test-i386-i386-pv             3 host-install(3)              broken
 test-amd64-i386-win           8 guest-saverestore         fail REGR. vs. 10201
 test-i386-i386-win            8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-i386-win-vcpus1    8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-amd64-win          8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-amd64-xl-win       3 host-install(3)              broken
 test-i386-i386-xl-win         8 guest-saverestore         fail REGR. vs. 10201
 test-amd64-i386-xl-winxpsp3-vcpus1  3 host-install(3)          broken in 10435
 test-amd64-i386-rhel6hvm-intel  3 host-install(3)              broken in 10435
 test-amd64-amd64-xl-win      8 guest-saverestore fail in 10401 REGR. vs. 10201
 test-amd64-i386-win           3 host-install(3)              broken   in 10424
 test-amd64-i386-xl-win-vcpus1 8 guest-saverestore fail in 10424 REGR. vs. 10201

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf     14 guest-localmigrate/x10      fail pass in 10435
 test-amd64-i386-xl-win-vcpus1  7 windows-install            fail pass in 10424
 test-amd64-amd64-xl-win       7 windows-install    fail in 10435 pass in 10401
 test-amd64-amd64-xl-sedf     11 guest-localmigrate fail in 10401 pass in 10440
 test-amd64-i386-xl-credit2    7 debian-install     fail in 10424 pass in 10440

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-i386-i386-xl-winxpsp3    7 windows-install              fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install          fail never pass
 test-amd64-i386-xl-win7-amd64  7 windows-install              fail  never pass
 test-amd64-i386-xend-winxpsp3  7 windows-install              fail  never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   never pass
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore        fail blocked in 10201
 test-amd64-amd64-xl-win7-amd64  7 windows-install     fail in 10435 never pass
 test-amd64-amd64-xl-sedf-pin 13 guest-localmigrate.2 fail in 10435 blocked in 10201

version targeted for testing:
 xen                  38eb74c01d9d
baseline version:
 xen                  62ff6a318c5d

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scanneel.ca>
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Andres Lagar-Cavilla <andres@lagarcavilla>
  Andrew Cooper <andrew.cooper3@citrix.com>
  Anthony PERARD <anthony.perard@citrix.com>
  Brendan Cully <brendan@cs.ubc.ca>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Haitao Shan <haitao.shan@intel.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@novell.com>
  Jan Beulich <jbeulich@suse.com>
  Jonathan Davies <jonathan.davies@citrix.com>
  juergen.gross@ts.fujitsu.com
  Keir Fraser <keir@xen.org>
  Liu, Jinsong <jinsong.liu@intel.com>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
  Philipp Hahn <hahn@univention.de>
  Shriram Rajagopalan <rshriram@cs.ubc.ca>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang2 <wei.wang2@amd.com>
  Xudong Hao <xudong.hao@intel.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               broken  
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            broken  
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      broken  
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 1493 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 08 19:26:35 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 Dec 2011 19:26:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYjbe-0005vg-7w; Thu, 08 Dec 2011 19:26:10 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RYjbd-0005vb-54
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 19:26:09 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1323372320!6407986!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDg5NQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22969 invoked from network); 8 Dec 2011 19:25:20 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Dec 2011 19:25:20 -0000
X-IronPort-AV: E=Sophos;i="4.71,321,1320624000"; 
   d="scan'208";a="9371010"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Dec 2011 19:25:20 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 8 Dec 2011 19:25:19 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RYjap-0003Rz-LO; Thu, 08 Dec 2011 19:25:19 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RYjap-0006PB-KN;
	Thu, 08 Dec 2011 19:25:19 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20193.3871.620073.668955@mariner.uk.xensource.com>
Date: Thu, 8 Dec 2011 19:25:19 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1323275855.2969.9.camel@zakaz.uk.xensource.com>
References: <1323108621-22654-1-git-send-email-ian.jackson@eu.citrix.com>
	<1323275855.2969.9.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH v4 00/15] New event API
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("Re: [Xen-devel] [PATCH v4 00/15] New event API"):
> I think I have now acked #1-11 either previously or just now, although
> my comment on #12 really is about #7 so having either dismissed or
> implemented that suggestion I've effectively acked #1-12.

Given the bikeshed nature of your comment on #7 (GC_FREE) I'll wait
and see what develops from my recent posting.  I'd rather not go
through and commit another seddery in xen-unstable mainline...

I'll repost 01-06 in their now-hopefully-final form and hopefully
apply them along with some of the rest of the backlog tomorrow.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 08 19:26:35 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 Dec 2011 19:26:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYjbe-0005vg-7w; Thu, 08 Dec 2011 19:26:10 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RYjbd-0005vb-54
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 19:26:09 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1323372320!6407986!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDg5NQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22969 invoked from network); 8 Dec 2011 19:25:20 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Dec 2011 19:25:20 -0000
X-IronPort-AV: E=Sophos;i="4.71,321,1320624000"; 
   d="scan'208";a="9371010"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Dec 2011 19:25:20 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 8 Dec 2011 19:25:19 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RYjap-0003Rz-LO; Thu, 08 Dec 2011 19:25:19 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RYjap-0006PB-KN;
	Thu, 08 Dec 2011 19:25:19 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20193.3871.620073.668955@mariner.uk.xensource.com>
Date: Thu, 8 Dec 2011 19:25:19 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1323275855.2969.9.camel@zakaz.uk.xensource.com>
References: <1323108621-22654-1-git-send-email-ian.jackson@eu.citrix.com>
	<1323275855.2969.9.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH v4 00/15] New event API
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("Re: [Xen-devel] [PATCH v4 00/15] New event API"):
> I think I have now acked #1-11 either previously or just now, although
> my comment on #12 really is about #7 so having either dismissed or
> implemented that suggestion I've effectively acked #1-12.

Given the bikeshed nature of your comment on #7 (GC_FREE) I'll wait
and see what develops from my recent posting.  I'd rather not go
through and commit another seddery in xen-unstable mainline...

I'll repost 01-06 in their now-hopefully-final form and hopefully
apply them along with some of the rest of the backlog tomorrow.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 08 19:55:07 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 Dec 2011 19:55:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYk3E-0006BS-Ov; Thu, 08 Dec 2011 19:54:40 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RYk3D-0006BM-M1
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 19:54:40 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1323374031!6709512!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDg5NQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25288 invoked from network); 8 Dec 2011 19:53:51 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Dec 2011 19:53:51 -0000
X-IronPort-AV: E=Sophos;i="4.71,321,1320624000"; 
   d="scan'208";a="9371420"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Dec 2011 19:53:50 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 8 Dec 2011 19:53:50 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RYk2Q-0003bR-6e; Thu, 08 Dec 2011 19:53:50 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RYk2Q-0000J1-5c;
	Thu, 08 Dec 2011 19:53:50 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20193.5581.714247.641528@mariner.uk.xensource.com>
Date: Thu, 8 Dec 2011 19:53:49 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1323279343.2969.44.camel@zakaz.uk.xensource.com>
References: <1323108621-22654-1-git-send-email-ian.jackson@eu.citrix.com>
	<1323108621-22654-15-git-send-email-ian.jackson@eu.citrix.com>
	<1323279343.2969.44.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 14/15] libxl: New API for providing OS
 events to libxl
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("Re: [Xen-devel] [PATCH 14/15] libxl: New API for providing OS events to libxl"):
> On Mon, 2011-12-05 at 18:10 +0000, Ian Jackson wrote:
> >  #include <libxl_uuid.h>
> > +#include <_libxl_list.h>
> 
> Do we expose the use of these to users anywhere? I've failed to spot it
> if so (at least in this patch). If it is deliberate then #3 needs to
> install this header.

Oh.  Yes, it is deliberate.  There is a list link in libxl_event.
I will arrange to install the header.

> > +#include <libxl_event.h>
> 
> Putting this at the end is a bit odd, I don't really object though. I
> suppose it depends on stuff defined in this header and putting it half
> way through is even more odd.

Exactly.  This seems the best approach.

> > @@ -0,0 +1,711 @@
> > +/*
> > + * Copyright (C) 2011      Citrix Ltd.
> > + *
> > + * This program is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU Lesser General Public License as published
> > + * by the Free Software Foundation; version 2.1 only. with the special
> > + * exception on linking described in file LICENSE.
> 
> I've only just noticed this but it is present in some other libxl files
> too. There is no LICENSE file in tools/libxl:
>         $ find -name LICENSE
>         ./tools/ioemu-remote/LICENSE
>         ./tools/ioemu-remote/tcg/LICENSE
>         ./tools/ocaml/LICENSE
>         ./xen/tools/figlet/LICENSE
> 
> I suspect this is a cut-and-paste-o, probably from tools/ocaml?

All the existing files in libxl/ mention this nonexistent file
LICENCE.  I think we should fix this in a separate patch.  I'd argue
that my copying of the existing text isn't making the situation worse.

> > + * The application's registration hooks should be called ONLY via
> > + * these macros, with the ctx locked.  Likewise all the "occurred"
> > + * entrypoints from the application should assert(!in_hook);
> 
> In RFC speak you mean MUST rather than should both times here, right?

In the immortal words of RFC2181:

  3. Terminology

     This memo does not use the oft used expressions MUST, SHOULD, MAY, or
     their negative forms.  In some sections it may seem that a
     specification is worded mildly, and hence some may infer that the
     specification is optional.  That is not correct.  Anywhere that this
     memo suggests that some action should be carried out, or must be
     carried out, or that some behaviour is acceptable, or not, that is to
     be considered as a fundamental aspect of this specification,
     regardless of the specific words used.  If some behaviour or action
     is truly optional, that will be clearly specified by the text.

If you think this is confusing I can change it to "must"...

> > +int libxl__ev_fd_register(libxl__gc *gc, libxl__ev_fd *ev,
> > +                          libxl__ev_fd_callback *func,
> > +                          int fd, short events) {
> 
> Strictly speaking CODING_STYLE requires the { to be on the next line.

Oh, I probably have a lot of those.  Damn.  I'll try to remember to
fix this up with some seddery somehow.

> > +    LIBXL_LIST_INSERT_HEAD(&CTX->efds, ev, entry);
> > +
> > +    ev->fd = fd;
> > +    ev->events = events;
> > +    ev->in_beforepolled = -1;
> > +    ev->func = func;
> 
> Even though this is all locked correctly seeing the ev initialised after
> it is already on the list has tweaked my "what's up" instinct such that
> I've had to look twice both times I've looked at this patch.

I'll swap it round.

> > + out:
> > +    CTX_UNLOCK;
> > +    return 0;
> 
> You mean "return rc" here.

So I do.  Fixed here and in libxl__ev_time_modify_rel.

> > +int libxl__ev_time_modify_abs(libxl__gc *gc, libxl__ev_time *ev,
> > +                              struct timeval abs) {
> > +    int rc;
> > +
> > +    CTX_LOCK;
> > +
> > +    assert(libxl__ev_time_isregistered(ev));
> 
> Why is there no deregister here? Is libxl__ev_time_modify_rel the only
> caller?

It's currently the only caller but other bits of libxl are entitled to
call it.  It's part of the facilities supplied to the rest of libxl.

There is no deregister because (a) we don't want to do that until
we've called the hook, if necessary, in case the hook fails and (b) we
have to explicitly deal with the two different cases:
   1. existing event was infinite timeout, so not on queue, just
      call register_finite which will do everything needed
   2. existing event _wasn't_ infinite timeout, first call modify
      hook, then fiddle about with the queue

> > +        const char *epath = event[0];
> > +        const char *token = event[1];
> > +        int slotnum;
> > +        uint32_t counterval;
> > +        int rc = sscanf(token, "%d/%"SCNx32, &slotnum, &counterval);
> 
> How have I never come across the SCNxxx counterpart to PRIxxx before!

Hardly anyone ever uses scanf.

> > +        /* Now it's possible, though unlikely, that this was an event
> > +         * from a previous use of the same slot with the same counterval.
> > +         *
> > +         * In that case either:
> > +         *  - the event path is a child of the watch path, in
> > +         *    which case this watch would really have generated this
> > +         *    event if it had been registered soon enough and we are
> > +         *    OK to give this possibly-spurious event to the caller; or
> > +         * - it is not, in which case we must suppress it as the
> > +         *   caller should not see events for unrelated paths.
> > +         *
> > +         * See also docs/misc/xenstore.txt.
> > +         */
> > +        size_t epathlen = strlen(epath);
> > +        size_t wpathlen = strlen(w->path);
> > +        if (epathlen < wpathlen ||
> > +            memcmp(epath, w->path, wpathlen) ||
> > +            (epathlen > wpathlen && epath[wpathlen] != '/')) {
> > +            LIBXL__LOG(CTX, LIBXL__LOG_DEBUG,
> > +                       "watch epath=%s token=%s: not child of wpath=%s",
> > +                       epath, token, w->path);
> 
> It seems like this is worthy of a helper function of its own. Possibly
> in libxenstore itself?

You mean "int xs_path_is_subpath_p(const char *parent, const char *child)" ?

Possibly.  I wouldn't be opposed to putting those 5 lines in
libxenstore it there but AFAIK only this place in libxl needs it.

> > +        LIBXL__LOG(CTX, LIBXL__LOG_DEBUG,
> > +                   "watch event: epath=%s token=%s wpath=%s w=%p",
> > +                   epath, token, w->path, w);
> 
> Aside: At some point we might want to have a way to configure classes of
> debug log message on/off. I was just wondering if this message might be
> a bit spammy but I suspect it is ok.

I don't think there will be that many of these.  If so then yes we may
need a more sophisticated debug framework.

> > +    use = LIBXL_SLIST_FIRST(&CTX->watch_freeslots);
> > +    assert(use);
> > +    LIBXL_SLIST_REMOVE_HEAD(&CTX->watch_freeslots, empty);
> 
> I presume this is removing "use" from the list. It seems odd to refer to
> that element of the list as HEAD and FIRST interchangeably since it
> doesn't make this obvious but I guess we got this API from elsewhere.

Yes, FreeBSD.

> There's no get-and-return function which combines the two operations?

Not in this pile of macros, I'm afraid.

> > +    w->slotnum = slotnum;
> > +    w->path = path_copy;
> > +    w->callback = func;
> > +    /* we look a bit behind the curtain of LIBXL_SLIST, to explictly
> 
> explicitly

Fixed.

> > +     * assign to the pointer that's the next link.  See the comment
> > +     * by the definitionn of libxl__ev_watch_slot */
> 
> definition.

Fixed.

> I think this behind the curtain stuff would be better encapsulated in a
> macro up somewhere near the comment and libxl__ev_watch_slot.
> 
> > +    use->empty.sle_next = (void*)w;

How about:

  static void libxl__set_watch_slot_contents(libxl__ev_watch_slot *slot,
                                             libxl__ev_xswatch *w) {
      /* we look a bit behind the curtain of LIBXL_SLIST, to explicitly
       * assign to the pointer that's the next link.  See the comment
       * by the definition of libxl__ev_watch_slot */
      slot->empty.sle_next = (void*)w;
  }

Just below the the definition of libxl__watch_slot_contents.  That
puts it near the other big comment and it's essentially the sister
function.

> > +    CTX_LOCK;
> > +
> > +    if (w->slotnum >= 0) {
> > +        char *token = watch_token(gc, w->slotnum, w->counterval);
> > +        if (!xs_unwatch(CTX->xsh, w->path, token))
> > +            /* Oh well, we will just get watch events forever more
> > +             * and ignore them.  But we should complain to the log. */
> > +            LIBXL__LOG_ERRNOVAL(CTX, LIBXL__LOG_ERROR, errno,
> > +                                "remove watch for path %s", w->path);
> 
> Is it possible to also unwatch an unexpected watch at the point it
> fires, IOW to try again later? I havn'et looked at the potential failure
> cases of xs_unwatch so perhaps once it has failed there is no point in
> trying again.

Offhand I think it can fail because:
  - communication with xenstore has broken down, in which case trying
    again is pretty pointless
  - xenstore didn't recognise the watch (ie we or xenstore have a bug)
    in which case trying to remove it is not sensible
I'm also not sure exactly about the race implications.  What if you
add and remove watches in different threads simultaneously ?

So I think this is probably best - and it's probably best not to do
additional complicated flailing when either (a) things are already
going wrong or (b) we just got a harmless lost race.

> This seems like a good place to stop for the day. I'll pickup the rest
> tomorrow.

Heh.  I should go to the pub :-).

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 08 19:55:07 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 Dec 2011 19:55:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYk3E-0006BS-Ov; Thu, 08 Dec 2011 19:54:40 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RYk3D-0006BM-M1
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 19:54:40 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1323374031!6709512!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDg5NQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25288 invoked from network); 8 Dec 2011 19:53:51 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Dec 2011 19:53:51 -0000
X-IronPort-AV: E=Sophos;i="4.71,321,1320624000"; 
   d="scan'208";a="9371420"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Dec 2011 19:53:50 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 8 Dec 2011 19:53:50 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RYk2Q-0003bR-6e; Thu, 08 Dec 2011 19:53:50 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RYk2Q-0000J1-5c;
	Thu, 08 Dec 2011 19:53:50 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20193.5581.714247.641528@mariner.uk.xensource.com>
Date: Thu, 8 Dec 2011 19:53:49 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1323279343.2969.44.camel@zakaz.uk.xensource.com>
References: <1323108621-22654-1-git-send-email-ian.jackson@eu.citrix.com>
	<1323108621-22654-15-git-send-email-ian.jackson@eu.citrix.com>
	<1323279343.2969.44.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 14/15] libxl: New API for providing OS
 events to libxl
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("Re: [Xen-devel] [PATCH 14/15] libxl: New API for providing OS events to libxl"):
> On Mon, 2011-12-05 at 18:10 +0000, Ian Jackson wrote:
> >  #include <libxl_uuid.h>
> > +#include <_libxl_list.h>
> 
> Do we expose the use of these to users anywhere? I've failed to spot it
> if so (at least in this patch). If it is deliberate then #3 needs to
> install this header.

Oh.  Yes, it is deliberate.  There is a list link in libxl_event.
I will arrange to install the header.

> > +#include <libxl_event.h>
> 
> Putting this at the end is a bit odd, I don't really object though. I
> suppose it depends on stuff defined in this header and putting it half
> way through is even more odd.

Exactly.  This seems the best approach.

> > @@ -0,0 +1,711 @@
> > +/*
> > + * Copyright (C) 2011      Citrix Ltd.
> > + *
> > + * This program is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU Lesser General Public License as published
> > + * by the Free Software Foundation; version 2.1 only. with the special
> > + * exception on linking described in file LICENSE.
> 
> I've only just noticed this but it is present in some other libxl files
> too. There is no LICENSE file in tools/libxl:
>         $ find -name LICENSE
>         ./tools/ioemu-remote/LICENSE
>         ./tools/ioemu-remote/tcg/LICENSE
>         ./tools/ocaml/LICENSE
>         ./xen/tools/figlet/LICENSE
> 
> I suspect this is a cut-and-paste-o, probably from tools/ocaml?

All the existing files in libxl/ mention this nonexistent file
LICENCE.  I think we should fix this in a separate patch.  I'd argue
that my copying of the existing text isn't making the situation worse.

> > + * The application's registration hooks should be called ONLY via
> > + * these macros, with the ctx locked.  Likewise all the "occurred"
> > + * entrypoints from the application should assert(!in_hook);
> 
> In RFC speak you mean MUST rather than should both times here, right?

In the immortal words of RFC2181:

  3. Terminology

     This memo does not use the oft used expressions MUST, SHOULD, MAY, or
     their negative forms.  In some sections it may seem that a
     specification is worded mildly, and hence some may infer that the
     specification is optional.  That is not correct.  Anywhere that this
     memo suggests that some action should be carried out, or must be
     carried out, or that some behaviour is acceptable, or not, that is to
     be considered as a fundamental aspect of this specification,
     regardless of the specific words used.  If some behaviour or action
     is truly optional, that will be clearly specified by the text.

If you think this is confusing I can change it to "must"...

> > +int libxl__ev_fd_register(libxl__gc *gc, libxl__ev_fd *ev,
> > +                          libxl__ev_fd_callback *func,
> > +                          int fd, short events) {
> 
> Strictly speaking CODING_STYLE requires the { to be on the next line.

Oh, I probably have a lot of those.  Damn.  I'll try to remember to
fix this up with some seddery somehow.

> > +    LIBXL_LIST_INSERT_HEAD(&CTX->efds, ev, entry);
> > +
> > +    ev->fd = fd;
> > +    ev->events = events;
> > +    ev->in_beforepolled = -1;
> > +    ev->func = func;
> 
> Even though this is all locked correctly seeing the ev initialised after
> it is already on the list has tweaked my "what's up" instinct such that
> I've had to look twice both times I've looked at this patch.

I'll swap it round.

> > + out:
> > +    CTX_UNLOCK;
> > +    return 0;
> 
> You mean "return rc" here.

So I do.  Fixed here and in libxl__ev_time_modify_rel.

> > +int libxl__ev_time_modify_abs(libxl__gc *gc, libxl__ev_time *ev,
> > +                              struct timeval abs) {
> > +    int rc;
> > +
> > +    CTX_LOCK;
> > +
> > +    assert(libxl__ev_time_isregistered(ev));
> 
> Why is there no deregister here? Is libxl__ev_time_modify_rel the only
> caller?

It's currently the only caller but other bits of libxl are entitled to
call it.  It's part of the facilities supplied to the rest of libxl.

There is no deregister because (a) we don't want to do that until
we've called the hook, if necessary, in case the hook fails and (b) we
have to explicitly deal with the two different cases:
   1. existing event was infinite timeout, so not on queue, just
      call register_finite which will do everything needed
   2. existing event _wasn't_ infinite timeout, first call modify
      hook, then fiddle about with the queue

> > +        const char *epath = event[0];
> > +        const char *token = event[1];
> > +        int slotnum;
> > +        uint32_t counterval;
> > +        int rc = sscanf(token, "%d/%"SCNx32, &slotnum, &counterval);
> 
> How have I never come across the SCNxxx counterpart to PRIxxx before!

Hardly anyone ever uses scanf.

> > +        /* Now it's possible, though unlikely, that this was an event
> > +         * from a previous use of the same slot with the same counterval.
> > +         *
> > +         * In that case either:
> > +         *  - the event path is a child of the watch path, in
> > +         *    which case this watch would really have generated this
> > +         *    event if it had been registered soon enough and we are
> > +         *    OK to give this possibly-spurious event to the caller; or
> > +         * - it is not, in which case we must suppress it as the
> > +         *   caller should not see events for unrelated paths.
> > +         *
> > +         * See also docs/misc/xenstore.txt.
> > +         */
> > +        size_t epathlen = strlen(epath);
> > +        size_t wpathlen = strlen(w->path);
> > +        if (epathlen < wpathlen ||
> > +            memcmp(epath, w->path, wpathlen) ||
> > +            (epathlen > wpathlen && epath[wpathlen] != '/')) {
> > +            LIBXL__LOG(CTX, LIBXL__LOG_DEBUG,
> > +                       "watch epath=%s token=%s: not child of wpath=%s",
> > +                       epath, token, w->path);
> 
> It seems like this is worthy of a helper function of its own. Possibly
> in libxenstore itself?

You mean "int xs_path_is_subpath_p(const char *parent, const char *child)" ?

Possibly.  I wouldn't be opposed to putting those 5 lines in
libxenstore it there but AFAIK only this place in libxl needs it.

> > +        LIBXL__LOG(CTX, LIBXL__LOG_DEBUG,
> > +                   "watch event: epath=%s token=%s wpath=%s w=%p",
> > +                   epath, token, w->path, w);
> 
> Aside: At some point we might want to have a way to configure classes of
> debug log message on/off. I was just wondering if this message might be
> a bit spammy but I suspect it is ok.

I don't think there will be that many of these.  If so then yes we may
need a more sophisticated debug framework.

> > +    use = LIBXL_SLIST_FIRST(&CTX->watch_freeslots);
> > +    assert(use);
> > +    LIBXL_SLIST_REMOVE_HEAD(&CTX->watch_freeslots, empty);
> 
> I presume this is removing "use" from the list. It seems odd to refer to
> that element of the list as HEAD and FIRST interchangeably since it
> doesn't make this obvious but I guess we got this API from elsewhere.

Yes, FreeBSD.

> There's no get-and-return function which combines the two operations?

Not in this pile of macros, I'm afraid.

> > +    w->slotnum = slotnum;
> > +    w->path = path_copy;
> > +    w->callback = func;
> > +    /* we look a bit behind the curtain of LIBXL_SLIST, to explictly
> 
> explicitly

Fixed.

> > +     * assign to the pointer that's the next link.  See the comment
> > +     * by the definitionn of libxl__ev_watch_slot */
> 
> definition.

Fixed.

> I think this behind the curtain stuff would be better encapsulated in a
> macro up somewhere near the comment and libxl__ev_watch_slot.
> 
> > +    use->empty.sle_next = (void*)w;

How about:

  static void libxl__set_watch_slot_contents(libxl__ev_watch_slot *slot,
                                             libxl__ev_xswatch *w) {
      /* we look a bit behind the curtain of LIBXL_SLIST, to explicitly
       * assign to the pointer that's the next link.  See the comment
       * by the definition of libxl__ev_watch_slot */
      slot->empty.sle_next = (void*)w;
  }

Just below the the definition of libxl__watch_slot_contents.  That
puts it near the other big comment and it's essentially the sister
function.

> > +    CTX_LOCK;
> > +
> > +    if (w->slotnum >= 0) {
> > +        char *token = watch_token(gc, w->slotnum, w->counterval);
> > +        if (!xs_unwatch(CTX->xsh, w->path, token))
> > +            /* Oh well, we will just get watch events forever more
> > +             * and ignore them.  But we should complain to the log. */
> > +            LIBXL__LOG_ERRNOVAL(CTX, LIBXL__LOG_ERROR, errno,
> > +                                "remove watch for path %s", w->path);
> 
> Is it possible to also unwatch an unexpected watch at the point it
> fires, IOW to try again later? I havn'et looked at the potential failure
> cases of xs_unwatch so perhaps once it has failed there is no point in
> trying again.

Offhand I think it can fail because:
  - communication with xenstore has broken down, in which case trying
    again is pretty pointless
  - xenstore didn't recognise the watch (ie we or xenstore have a bug)
    in which case trying to remove it is not sensible
I'm also not sure exactly about the race implications.  What if you
add and remove watches in different threads simultaneously ?

So I think this is probably best - and it's probably best not to do
additional complicated flailing when either (a) things are already
going wrong or (b) we just got a harmless lost race.

> This seems like a good place to stop for the day. I'll pickup the rest
> tomorrow.

Heh.  I should go to the pub :-).

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 08 20:41:04 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 Dec 2011 20:41:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYklZ-0006m1-D0; Thu, 08 Dec 2011 20:40:29 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RYklX-0006lq-Gc
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 20:40:27 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1323376761!51438769!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDg5NQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24822 invoked from network); 8 Dec 2011 20:39:21 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Dec 2011 20:39:21 -0000
X-IronPort-AV: E=Sophos;i="4.71,321,1320624000"; 
   d="scan'208";a="9371841"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Dec 2011 20:39:43 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 8 Dec 2011
	20:39:43 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
In-Reply-To: <20193.3871.620073.668955@mariner.uk.xensource.com>
References: <1323108621-22654-1-git-send-email-ian.jackson@eu.citrix.com>
	<1323275855.2969.9.camel@zakaz.uk.xensource.com>
	<20193.3871.620073.668955@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
Date: Thu, 8 Dec 2011 20:39:42 +0000
Message-ID: <1323376782.20936.2.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
X-Mailer: Evolution 2.32.3 
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH v4 00/15] New event API
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2011-12-08 at 19:25 +0000, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [PATCH v4 00/15] New event API"):
> > I think I have now acked #1-11 either previously or just now, although
> > my comment on #12 really is about #7 so having either dismissed or
> > implemented that suggestion I've effectively acked #1-12.
> 
> Given the bikeshed nature of your comment on #7 (GC_FREE) I'll wait
> and see what develops from my recent posting.  I'd rather not go
> through and commit another seddery in xen-unstable mainline...

You replies to #12 & #13 seem reasonable to me so you can consider
#1-#13 acked.

> I'll repost 01-06 in their now-hopefully-final form and hopefully
> apply them along with some of the rest of the backlog tomorrow.
> 
> Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 08 20:41:04 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 Dec 2011 20:41:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYklZ-0006m1-D0; Thu, 08 Dec 2011 20:40:29 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RYklX-0006lq-Gc
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 20:40:27 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1323376761!51438769!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDg5NQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24822 invoked from network); 8 Dec 2011 20:39:21 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Dec 2011 20:39:21 -0000
X-IronPort-AV: E=Sophos;i="4.71,321,1320624000"; 
   d="scan'208";a="9371841"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Dec 2011 20:39:43 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 8 Dec 2011
	20:39:43 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
In-Reply-To: <20193.3871.620073.668955@mariner.uk.xensource.com>
References: <1323108621-22654-1-git-send-email-ian.jackson@eu.citrix.com>
	<1323275855.2969.9.camel@zakaz.uk.xensource.com>
	<20193.3871.620073.668955@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
Date: Thu, 8 Dec 2011 20:39:42 +0000
Message-ID: <1323376782.20936.2.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
X-Mailer: Evolution 2.32.3 
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH v4 00/15] New event API
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2011-12-08 at 19:25 +0000, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [PATCH v4 00/15] New event API"):
> > I think I have now acked #1-11 either previously or just now, although
> > my comment on #12 really is about #7 so having either dismissed or
> > implemented that suggestion I've effectively acked #1-12.
> 
> Given the bikeshed nature of your comment on #7 (GC_FREE) I'll wait
> and see what develops from my recent posting.  I'd rather not go
> through and commit another seddery in xen-unstable mainline...

You replies to #12 & #13 seem reasonable to me so you can consider
#1-#13 acked.

> I'll repost 01-06 in their now-hopefully-final form and hopefully
> apply them along with some of the rest of the backlog tomorrow.
> 
> Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 08 20:41:54 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 Dec 2011 20:41:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYkmV-0006rI-Sd; Thu, 08 Dec 2011 20:41:27 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RYkmU-0006qh-52
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 20:41:26 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1323376789!60007451!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDg5NQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27095 invoked from network); 8 Dec 2011 20:39:49 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Dec 2011 20:39:49 -0000
X-IronPort-AV: E=Sophos;i="4.71,321,1320624000"; 
   d="scan'208";a="9371844"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Dec 2011 20:40:39 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 8 Dec 2011
	20:40:39 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
In-Reply-To: <20192.65274.13650.451424@mariner.uk.xensource.com>
References: <1323108621-22654-1-git-send-email-ian.jackson@eu.citrix.com>
	<1323108621-22654-7-git-send-email-ian.jackson@eu.citrix.com>
	<1323266816.23681.189.camel@zakaz.uk.xensource.com>
	<20192.65274.13650.451424@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
Date: Thu, 8 Dec 2011 20:40:38 +0000
Message-ID: <1323376838.20936.3.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
X-Mailer: Evolution 2.32.3 
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 06/15] libxl: permit declaration after
 statement
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2011-12-08 at 18:16 +0000, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [PATCH 06/15] libxl: permit declaration after statement"):
> > I'm happy with this so far as it goes but I was wondering where the
> > original -Wdeclaration-after-statement came from, do we actually mean
> > "-std=c99" or something along those lines?
> 
>  gcc  -O1 -fno-omit-frame-pointer -m32 -march=i686 -g -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wno-unused-value -Wdeclaration-after-statement   -D__XEN_TOOLS__ -MMD -MF .libxl.o.d -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -fno-optimize-sibling-calls -mno-tls-direct-seg-refs -Werror -Wno-format-zero-length -Wmissing-declarations -I. -fPIC -I/u/iwj/work/2/xen-unstable.git/tools/libxl/../../tools/libxc -I/u/iwj/work/2/xen-unstable.git/tools/libxl/../../tools/include -I/u/iwj/work/2/xen-unstable.git/tools/libxl/../../tools/libxc -I/u/iwj/work/2/xen-unstable.git/tools/libxl/../../tools/include -I/u/iwj/work/2/xen-unstable.git/tools/libxl/../../tools/xenstore -I/u/iwj/work/2/xen-unstable.git/tools/libxl/../../tools/include -I/u/iwj/work/2/xen-unstable.git/tools/libxl/../../tools/blktap2/control -I/u/iwj/work/2/xen-unstable.git/tools/libxl/../../tools/blktap2/include -I/u/iwj/work/2/xen-unstable.git/tools/libxl/../../tools/include  -c -o libxl.o libxl.c  
> 
> So cutting that down to the relevant bits:
> 
>  gcc ... -std=gnu99 -Wall ... -Wdeclaration-after-statement ... -Werror ...
> 
> The -Wdeclaration-after-statement comes from Config.mk:
> 
>  $(call cc-option-add,HOSTCFLAGS,HOSTCC,-Wdeclaration-after-statement)
>  $(call cc-option-add,CFLAGS,CC,-Wdeclaration-after-statement)
> 
> So I think that since what we're doing is having a different rule for
> libxl, it's right to put it in libxl's makefile.

Agreed, I didn't realise this warning came from a different bit of Xen's
build machinery.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 08 20:41:54 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 Dec 2011 20:41:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYkmV-0006rI-Sd; Thu, 08 Dec 2011 20:41:27 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RYkmU-0006qh-52
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 20:41:26 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1323376789!60007451!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDg5NQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27095 invoked from network); 8 Dec 2011 20:39:49 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Dec 2011 20:39:49 -0000
X-IronPort-AV: E=Sophos;i="4.71,321,1320624000"; 
   d="scan'208";a="9371844"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Dec 2011 20:40:39 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 8 Dec 2011
	20:40:39 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
In-Reply-To: <20192.65274.13650.451424@mariner.uk.xensource.com>
References: <1323108621-22654-1-git-send-email-ian.jackson@eu.citrix.com>
	<1323108621-22654-7-git-send-email-ian.jackson@eu.citrix.com>
	<1323266816.23681.189.camel@zakaz.uk.xensource.com>
	<20192.65274.13650.451424@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
Date: Thu, 8 Dec 2011 20:40:38 +0000
Message-ID: <1323376838.20936.3.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
X-Mailer: Evolution 2.32.3 
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 06/15] libxl: permit declaration after
 statement
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2011-12-08 at 18:16 +0000, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [PATCH 06/15] libxl: permit declaration after statement"):
> > I'm happy with this so far as it goes but I was wondering where the
> > original -Wdeclaration-after-statement came from, do we actually mean
> > "-std=c99" or something along those lines?
> 
>  gcc  -O1 -fno-omit-frame-pointer -m32 -march=i686 -g -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wno-unused-value -Wdeclaration-after-statement   -D__XEN_TOOLS__ -MMD -MF .libxl.o.d -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -fno-optimize-sibling-calls -mno-tls-direct-seg-refs -Werror -Wno-format-zero-length -Wmissing-declarations -I. -fPIC -I/u/iwj/work/2/xen-unstable.git/tools/libxl/../../tools/libxc -I/u/iwj/work/2/xen-unstable.git/tools/libxl/../../tools/include -I/u/iwj/work/2/xen-unstable.git/tools/libxl/../../tools/libxc -I/u/iwj/work/2/xen-unstable.git/tools/libxl/../../tools/include -I/u/iwj/work/2/xen-unstable.git/tools/libxl/../../tools/xenstore -I/u/iwj/work/2/xen-unstable.git/tools/libxl/../../tools/include -I/u/iwj/work/2/xen-unstable.git/tools/libxl/../../tools/blktap2/control -I/u/iwj/work/2/xen-unstable.git/tools/libxl/../../tools/blktap2/include -I/u/iwj/work/2/xen-unstable.git/tools/libxl/../../tools/include  -c -o libxl.o libxl.c  
> 
> So cutting that down to the relevant bits:
> 
>  gcc ... -std=gnu99 -Wall ... -Wdeclaration-after-statement ... -Werror ...
> 
> The -Wdeclaration-after-statement comes from Config.mk:
> 
>  $(call cc-option-add,HOSTCFLAGS,HOSTCC,-Wdeclaration-after-statement)
>  $(call cc-option-add,CFLAGS,CC,-Wdeclaration-after-statement)
> 
> So I think that since what we're doing is having a different rule for
> libxl, it's right to put it in libxl's makefile.

Agreed, I didn't realise this warning came from a different bit of Xen's
build machinery.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 08 21:55:50 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 Dec 2011 21: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.xensource.com>)
	id 1RYlvp-0007us-SE; Thu, 08 Dec 2011 21:55:09 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RYlvo-0007un-C4
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 21:55:08 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-4.tower-182.messagelabs.com!1323381259!6482474!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18481 invoked from network); 8 Dec 2011 21:54:19 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-4.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 8 Dec 2011 21:54:19 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RYluu-000NQ1-KJ; Thu, 08 Dec 2011 21:54:12 +0000
Date: Thu, 8 Dec 2011 21:54:12 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20111208215412.GD87836@ocelot.phlegethon.org>
References: <patchbomb.1323330435@xdev.gridcentric.ca>
	<aeebbff899ffa2328e3f.1323330436@xdev.gridcentric.ca>
	<20111208111118.GA82565@ocelot.phlegethon.org>
	<22f47878379138be5d645f48b4db9ed3.squirrel@webmail.lagarcavilla.org>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <22f47878379138be5d645f48b4db9ed3.squirrel@webmail.lagarcavilla.org>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com, ian.campbell@citrix.com,
	andres@gridcentric.ca, keir.xen@gmail.com, jbeulich@suse.com,
	ian.jackson@citrix.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 01 of 18] x86/mm: Code style fixes in
	mem_sharing.c
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 08:16 -0800 on 08 Dec (1323332187), Andres Lagar-Cavilla wrote:
> > At 02:47 -0500 on 08 Dec (1323312436), Andres Lagar-Cavilla wrote:
> >> Harmless patch, with no functional changes, only code style issues.
> >>
> >> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
> >
> > ...
> >
> >> -    return -2;
> >> +    return 0;
> >
> > Ahem. :)
> >
> > Tim.
> Borderline, I'll admit. I can play down the tone of the header -- nothing
> is really harmless :)
> 
> The function will still produce the same outputs on the same inputs, with
> cleaner code.

Ah, so it will.  I'll apply this, but in future I'd like long patches
that do tedious whitespace fixups to _just_ have whitespace fixups. 
It reduces the chance of nasty surprises (and the chance that I'll have
to read a long patch of tedious whitespace fixups more than once!)

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 08 21:55:50 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 Dec 2011 21: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.xensource.com>)
	id 1RYlvp-0007us-SE; Thu, 08 Dec 2011 21:55:09 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RYlvo-0007un-C4
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 21:55:08 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-4.tower-182.messagelabs.com!1323381259!6482474!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18481 invoked from network); 8 Dec 2011 21:54:19 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-4.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 8 Dec 2011 21:54:19 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RYluu-000NQ1-KJ; Thu, 08 Dec 2011 21:54:12 +0000
Date: Thu, 8 Dec 2011 21:54:12 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20111208215412.GD87836@ocelot.phlegethon.org>
References: <patchbomb.1323330435@xdev.gridcentric.ca>
	<aeebbff899ffa2328e3f.1323330436@xdev.gridcentric.ca>
	<20111208111118.GA82565@ocelot.phlegethon.org>
	<22f47878379138be5d645f48b4db9ed3.squirrel@webmail.lagarcavilla.org>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <22f47878379138be5d645f48b4db9ed3.squirrel@webmail.lagarcavilla.org>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com, ian.campbell@citrix.com,
	andres@gridcentric.ca, keir.xen@gmail.com, jbeulich@suse.com,
	ian.jackson@citrix.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 01 of 18] x86/mm: Code style fixes in
	mem_sharing.c
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 08:16 -0800 on 08 Dec (1323332187), Andres Lagar-Cavilla wrote:
> > At 02:47 -0500 on 08 Dec (1323312436), Andres Lagar-Cavilla wrote:
> >> Harmless patch, with no functional changes, only code style issues.
> >>
> >> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
> >
> > ...
> >
> >> -    return -2;
> >> +    return 0;
> >
> > Ahem. :)
> >
> > Tim.
> Borderline, I'll admit. I can play down the tone of the header -- nothing
> is really harmless :)
> 
> The function will still produce the same outputs on the same inputs, with
> cleaner code.

Ah, so it will.  I'll apply this, but in future I'd like long patches
that do tedious whitespace fixups to _just_ have whitespace fixups. 
It reduces the chance of nasty surprises (and the chance that I'll have
to read a long patch of tedious whitespace fixups more than once!)

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 08 22:14:47 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 Dec 2011 22: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.xensource.com>)
	id 1RYmEH-0008LJ-CP; Thu, 08 Dec 2011 22:14:13 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RYmEG-0008Kr-6U
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 22:14:12 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-11.tower-182.messagelabs.com!1323382402!6467920!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21888 invoked from network); 8 Dec 2011 22:13:23 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-11.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 8 Dec 2011 22:13:23 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RYmDP-000NTL-Us; Thu, 08 Dec 2011 22:13:19 +0000
Date: Thu, 8 Dec 2011 22:13:19 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20111208221319.GE87836@ocelot.phlegethon.org>
References: <patchbomb.1323330435@xdev.gridcentric.ca>
	<3038770886aa0654d73a.1323330438@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <3038770886aa0654d73a.1323330438@xdev.gridcentric.ca>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com, ian.campbell@citrix.com,
	andres@gridcentric.ca, keir.xen@gmail.com, JBeulich@suse.com,
	ian.jackson@citrix.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 03 of 18] x86/mm: Eliminate hash table in
	sharing code as index of shared mfns
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 02:47 -0500 on 08 Dec (1323312438), Andres Lagar-Cavilla wrote:
>  xen/arch/x86/mm/mem_sharing.c     |  526 +++++++++++++++++++------------------
>  xen/include/asm-x86/mem_sharing.h |   15 +-
>  xen/include/asm-x86/mm.h          |   11 +-
>  xen/include/public/domctl.h       |    3 +
>  4 files changed, 296 insertions(+), 259 deletions(-)
> 
> 
> The hashtable mechanism used by the sharing code is a bit odd.  It seems
> unnecessary and adds complexity.  Instead, we replace this by storing a list
> head directly in the page info for the case when the page is shared.  This does
> not add any extra space to the page_info and serves to remove significant
> complexity from sharing.
> 
> Signed-off-by: Adin Scannell <adin@scannell.ca>
> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

I like the look of this but I won't apply until Olaf is happy with the
interface changes.

One nit: 

> diff -r 61da3fc46f06 -r 3038770886aa xen/include/asm-x86/mem_sharing.h
> --- a/xen/include/asm-x86/mem_sharing.h
> +++ b/xen/include/asm-x86/mem_sharing.h
> @@ -22,13 +22,23 @@
>  #ifndef __MEM_SHARING_H__
>  #define __MEM_SHARING_H__
>  
> +#include <public/domctl.h>
> +
> +typedef uint64_t shr_handle_t; 
> +
> +struct page_sharing_info
> +{
> +    struct page_info *pg;   /* Back pointer to the page. */
> +    shr_handle_t handle;    /* Globally unique version / handle. */
> +    struct list_head entry; /* List of all shared pages (entry). */

IIUC this list is only used if the sharing audit code is anabled, so
it should probably be appropritaely #ifdeffed out to save space in the
non-audit case. 

Cheers,

Tim.

> +    struct list_head gfns;  /* List of domains and gfns for this page (head). */
> +};
> +
>  #ifdef __x86_64__
>  


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 08 22:14:47 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 Dec 2011 22: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.xensource.com>)
	id 1RYmEH-0008LJ-CP; Thu, 08 Dec 2011 22:14:13 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RYmEG-0008Kr-6U
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 22:14:12 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-11.tower-182.messagelabs.com!1323382402!6467920!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21888 invoked from network); 8 Dec 2011 22:13:23 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-11.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 8 Dec 2011 22:13:23 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RYmDP-000NTL-Us; Thu, 08 Dec 2011 22:13:19 +0000
Date: Thu, 8 Dec 2011 22:13:19 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20111208221319.GE87836@ocelot.phlegethon.org>
References: <patchbomb.1323330435@xdev.gridcentric.ca>
	<3038770886aa0654d73a.1323330438@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <3038770886aa0654d73a.1323330438@xdev.gridcentric.ca>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com, ian.campbell@citrix.com,
	andres@gridcentric.ca, keir.xen@gmail.com, JBeulich@suse.com,
	ian.jackson@citrix.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 03 of 18] x86/mm: Eliminate hash table in
	sharing code as index of shared mfns
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 02:47 -0500 on 08 Dec (1323312438), Andres Lagar-Cavilla wrote:
>  xen/arch/x86/mm/mem_sharing.c     |  526 +++++++++++++++++++------------------
>  xen/include/asm-x86/mem_sharing.h |   15 +-
>  xen/include/asm-x86/mm.h          |   11 +-
>  xen/include/public/domctl.h       |    3 +
>  4 files changed, 296 insertions(+), 259 deletions(-)
> 
> 
> The hashtable mechanism used by the sharing code is a bit odd.  It seems
> unnecessary and adds complexity.  Instead, we replace this by storing a list
> head directly in the page info for the case when the page is shared.  This does
> not add any extra space to the page_info and serves to remove significant
> complexity from sharing.
> 
> Signed-off-by: Adin Scannell <adin@scannell.ca>
> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

I like the look of this but I won't apply until Olaf is happy with the
interface changes.

One nit: 

> diff -r 61da3fc46f06 -r 3038770886aa xen/include/asm-x86/mem_sharing.h
> --- a/xen/include/asm-x86/mem_sharing.h
> +++ b/xen/include/asm-x86/mem_sharing.h
> @@ -22,13 +22,23 @@
>  #ifndef __MEM_SHARING_H__
>  #define __MEM_SHARING_H__
>  
> +#include <public/domctl.h>
> +
> +typedef uint64_t shr_handle_t; 
> +
> +struct page_sharing_info
> +{
> +    struct page_info *pg;   /* Back pointer to the page. */
> +    shr_handle_t handle;    /* Globally unique version / handle. */
> +    struct list_head entry; /* List of all shared pages (entry). */

IIUC this list is only used if the sharing audit code is anabled, so
it should probably be appropritaely #ifdeffed out to save space in the
non-audit case. 

Cheers,

Tim.

> +    struct list_head gfns;  /* List of domains and gfns for this page (head). */
> +};
> +
>  #ifdef __x86_64__
>  


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 08 22:21:43 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 Dec 2011 22:21:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYmL7-0000Si-5r; Thu, 08 Dec 2011 22:21:17 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RYmL5-0000SG-S2
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 22:21:16 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-14.tower-174.messagelabs.com!1323382826!4624220!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17259 invoked from network); 8 Dec 2011 22:20:27 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-14.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 8 Dec 2011 22:20:27 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RYmKG-000NUS-3j; Thu, 08 Dec 2011 22:20:24 +0000
Date: Thu, 8 Dec 2011 22:20:24 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20111208222024.GF87836@ocelot.phlegethon.org>
References: <patchbomb.1323330435@xdev.gridcentric.ca>
	<2e8d5702f4c17d0af9f3.1323330439@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <2e8d5702f4c17d0af9f3.1323330439@xdev.gridcentric.ca>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com, ian.campbell@citrix.com,
	andres@gridcentric.ca, keir.xen@gmail.com, JBeulich@suse.com,
	ian.jackson@citrix.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 04 of 18] x86/mm: Update mem sharing
	interface to (re)allow sharing of grants
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi, 

At 02:47 -0500 on 08 Dec (1323312439), Andres Lagar-Cavilla wrote:
> +            if ( XEN_DOMCTL_MEM_SHARING_FIELD_IS_GREF(mec->u.share.client_gfn) )
> +            {
> +                grant_ref_t gref = (grant_ref_t) 
> +                                    (XEN_DOMCTL_MEM_SHARING_FIELD_GET_GREF(
> +                                        mec->u.share.client_gfn));
> +                if ( (!source_is_gref) || 
> +                     (mem_sharing_gref_to_gfn(cd, gref, &cgfn) < 0) )
> +                {
> +                    put_domain(cd);
> +                    return -EINVAL;
> +                }
> +            } else {
> +                if ( source_is_gref )
> +                {
> +                    put_domain(cd);
> +                    return -EINVAL;
> +                }

Why can't one input be a grant and the other not?  If there's a problem
with that it should probably be documented in the hypercall interface. 

Cheers,

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 08 22:21:43 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 Dec 2011 22:21:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYmL7-0000Si-5r; Thu, 08 Dec 2011 22:21:17 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RYmL5-0000SG-S2
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 22:21:16 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-14.tower-174.messagelabs.com!1323382826!4624220!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17259 invoked from network); 8 Dec 2011 22:20:27 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-14.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 8 Dec 2011 22:20:27 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RYmKG-000NUS-3j; Thu, 08 Dec 2011 22:20:24 +0000
Date: Thu, 8 Dec 2011 22:20:24 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20111208222024.GF87836@ocelot.phlegethon.org>
References: <patchbomb.1323330435@xdev.gridcentric.ca>
	<2e8d5702f4c17d0af9f3.1323330439@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <2e8d5702f4c17d0af9f3.1323330439@xdev.gridcentric.ca>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com, ian.campbell@citrix.com,
	andres@gridcentric.ca, keir.xen@gmail.com, JBeulich@suse.com,
	ian.jackson@citrix.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 04 of 18] x86/mm: Update mem sharing
	interface to (re)allow sharing of grants
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi, 

At 02:47 -0500 on 08 Dec (1323312439), Andres Lagar-Cavilla wrote:
> +            if ( XEN_DOMCTL_MEM_SHARING_FIELD_IS_GREF(mec->u.share.client_gfn) )
> +            {
> +                grant_ref_t gref = (grant_ref_t) 
> +                                    (XEN_DOMCTL_MEM_SHARING_FIELD_GET_GREF(
> +                                        mec->u.share.client_gfn));
> +                if ( (!source_is_gref) || 
> +                     (mem_sharing_gref_to_gfn(cd, gref, &cgfn) < 0) )
> +                {
> +                    put_domain(cd);
> +                    return -EINVAL;
> +                }
> +            } else {
> +                if ( source_is_gref )
> +                {
> +                    put_domain(cd);
> +                    return -EINVAL;
> +                }

Why can't one input be a grant and the other not?  If there's a problem
with that it should probably be documented in the hypercall interface. 

Cheers,

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 08 22:28:58 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 Dec 2011 22:28:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYmSB-0000rp-7B; Thu, 08 Dec 2011 22:28:35 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RYmS9-0000rY-TR
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 22:28:34 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-13.tower-182.messagelabs.com!1323383264!5949496!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9200 invoked from network); 8 Dec 2011 22:27:45 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-13.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 8 Dec 2011 22:27:45 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RYmRL-000NW9-7s; Thu, 08 Dec 2011 22:27:43 +0000
Date: Thu, 8 Dec 2011 22:27:43 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20111208222743.GG87836@ocelot.phlegethon.org>
References: <patchbomb.1323330435@xdev.gridcentric.ca>
	<65b32b3913736cd743af.1323330444@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <65b32b3913736cd743af.1323330444@xdev.gridcentric.ca>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com, ian.campbell@citrix.com,
	andres@gridcentric.ca, keir.xen@gmail.com, JBeulich@suse.com,
	ian.jackson@citrix.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 09 of 18] x86/mm: Check how many mfns are
	shared, in addition to how many are saved
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 02:47 -0500 on 08 Dec (1323312444), Andres Lagar-Cavilla wrote:
> This patch also moves the existing sharing-related memory op to the
> correct location, and adds logic to the audit() method that uses the
> new information.
> 
> This patch only provides the Xen implementation of the domctls.
> 
> Signed-off-by: Adin Scannell <adin@scannell.ca>

Acked-by: Tim Deegan <tim@xen.org>  (once patches #3 and #4 are in).

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 08 22:28:58 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 Dec 2011 22:28:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYmSB-0000rp-7B; Thu, 08 Dec 2011 22:28:35 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RYmS9-0000rY-TR
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 22:28:34 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-13.tower-182.messagelabs.com!1323383264!5949496!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9200 invoked from network); 8 Dec 2011 22:27:45 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-13.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 8 Dec 2011 22:27:45 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RYmRL-000NW9-7s; Thu, 08 Dec 2011 22:27:43 +0000
Date: Thu, 8 Dec 2011 22:27:43 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20111208222743.GG87836@ocelot.phlegethon.org>
References: <patchbomb.1323330435@xdev.gridcentric.ca>
	<65b32b3913736cd743af.1323330444@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <65b32b3913736cd743af.1323330444@xdev.gridcentric.ca>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com, ian.campbell@citrix.com,
	andres@gridcentric.ca, keir.xen@gmail.com, JBeulich@suse.com,
	ian.jackson@citrix.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 09 of 18] x86/mm: Check how many mfns are
	shared, in addition to how many are saved
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 02:47 -0500 on 08 Dec (1323312444), Andres Lagar-Cavilla wrote:
> This patch also moves the existing sharing-related memory op to the
> correct location, and adds logic to the audit() method that uses the
> new information.
> 
> This patch only provides the Xen implementation of the domctls.
> 
> Signed-off-by: Adin Scannell <adin@scannell.ca>

Acked-by: Tim Deegan <tim@xen.org>  (once patches #3 and #4 are in).

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 08 22:34:54 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 Dec 2011 22:34:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYmXx-000187-1R; Thu, 08 Dec 2011 22:34:33 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RYmXv-00017t-Ee
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 22:34:31 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1323383622!6745689!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDg5NQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16241 invoked from network); 8 Dec 2011 22:33:42 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Dec 2011 22:33:42 -0000
X-IronPort-AV: E=Sophos;i="4.71,322,1320624000"; 
   d="scan'208";a="9372924"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Dec 2011 22:33:41 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 8 Dec 2011 22:33:41 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RYmX7-0004TX-4i;
	Thu, 08 Dec 2011 22:33:41 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RYmX7-0005EY-2m;
	Thu, 08 Dec 2011 22:33:41 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10444-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 8 Dec 2011 22:33:41 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing test] 10444: trouble: broken/fail/pass
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10444 xen-4.1-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10444/

Failures and problems with tests :-(

Tests which did not succeed and are blocking:
 test-amd64-i386-xl-credit2    3 host-install(3)              broken
 test-amd64-amd64-xl-winxpsp3  3 host-install(3)              broken
 test-amd64-i386-pv            3 host-install(3)              broken
 test-i386-i386-win            3 host-install(3)              broken

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-i386-xend-winxpsp3  7 windows-install              fail  never pass
 test-i386-i386-xl-winxpsp3    7 windows-install              fail   never pass
 test-amd64-amd64-xl-win7-amd64  7 windows-install              fail never pass
 test-amd64-i386-xl-win7-amd64  7 windows-install              fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install          fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  1c89f7d29fbb
baseline version:
 xen                  d9f8316a8291

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   broken  
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           broken  
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           broken  
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 broken  
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   23201:1c89f7d29fbb
tag:         tip
user:        Olaf Hering <olaf@aepfle.de>
date:        Thu Dec 08 16:50:28 2011 +0000
    
    tools: init.d/Linux/xencommons: load evtchn and gntdev modules
    
    There is currently no code in the kernel to trigger autoload of the
    evtchn or gntdev drivers. Load them manually during xencommons start.
    Handle both pvops and xenlinux module names.
    
    Signed-off-by: Olaf Hering <olaf@aepfle.de>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    xen-unstable changeset: 24334:9c8aff308002
    Backport-requested-by: Olaf Hering <olaf@aepfle.de>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   23200:7a4fad2d4b05
user:        Olaf Hering <olaf@aepfle.de>
date:        Thu Dec 08 16:50:16 2011 +0000
    
    tools: init.d/Linux/xencommons: run script only when needed
    
    Currently xencommons prints an error that /proc/xen/capabilities does
    not exist when started on a non-xen kernel.
    
    Update the xencommons script to run only when needed:
    - do not run if /proc/xen does not exist
    - check if /proc/xen/capabilities exists before doing the grep for dom0
    
    Signed-off-by: Olaf Hering <olaf@aepfle.de>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    xen-unstable changeset: 24333:4002e63b188a
    Backport-requested-by: Olaf Hering <olaf@aepfle.de>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   23199:d9f8316a8291
user:        Andrew Cooper <andrew.cooper3@citrix.com>
date:        Tue Dec 06 10:53:12 2011 +0000
    
    KEXEC: fix kexec_get_range_compat to fail vocally.
    
    Fail with -ERANGE rather than silently truncating 64bit values (a
    physical address and size) into 32bit integers for dom0 to consume.
    
    Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
    
    Simplify the bitwise arithmetic a bit.
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    xen-unstable changeset:   24358:9961a6d5356a
    xen-unstable date:        Mon Dec 05 19:42:46 2011 +0000
    
    
========================================
commit 3981d218912e186cb4205ee6732f446c177a36a2
Author: Jean Guyader <jean.guyader@eu.citrix.com>
Date:   Tue Nov 22 18:49:15 2011 +0000

    qemu-xen: Don't redefine libpci (3.1.7) defines.
    
    These values are already defined by the libpci heders in the version
    3.1.7.
    
    PCI_STATUS_66MHZ
    PCI_STATUS_RESERVED2
    PCI_STATUS_FAST_BACK
    PCI_MSIX_TABSIZE
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    (cherry picked from commit 174d92a73a5d5e67c49501383a519021b72a2468)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 08 22:34:54 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 Dec 2011 22:34:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYmXx-000187-1R; Thu, 08 Dec 2011 22:34:33 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RYmXv-00017t-Ee
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 22:34:31 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1323383622!6745689!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDg5NQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16241 invoked from network); 8 Dec 2011 22:33:42 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Dec 2011 22:33:42 -0000
X-IronPort-AV: E=Sophos;i="4.71,322,1320624000"; 
   d="scan'208";a="9372924"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Dec 2011 22:33:41 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 8 Dec 2011 22:33:41 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RYmX7-0004TX-4i;
	Thu, 08 Dec 2011 22:33:41 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RYmX7-0005EY-2m;
	Thu, 08 Dec 2011 22:33:41 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10444-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 8 Dec 2011 22:33:41 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing test] 10444: trouble: broken/fail/pass
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10444 xen-4.1-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10444/

Failures and problems with tests :-(

Tests which did not succeed and are blocking:
 test-amd64-i386-xl-credit2    3 host-install(3)              broken
 test-amd64-amd64-xl-winxpsp3  3 host-install(3)              broken
 test-amd64-i386-pv            3 host-install(3)              broken
 test-i386-i386-win            3 host-install(3)              broken

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-i386-xend-winxpsp3  7 windows-install              fail  never pass
 test-i386-i386-xl-winxpsp3    7 windows-install              fail   never pass
 test-amd64-amd64-xl-win7-amd64  7 windows-install              fail never pass
 test-amd64-i386-xl-win7-amd64  7 windows-install              fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install          fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  1c89f7d29fbb
baseline version:
 xen                  d9f8316a8291

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   broken  
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           broken  
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           broken  
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 broken  
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   23201:1c89f7d29fbb
tag:         tip
user:        Olaf Hering <olaf@aepfle.de>
date:        Thu Dec 08 16:50:28 2011 +0000
    
    tools: init.d/Linux/xencommons: load evtchn and gntdev modules
    
    There is currently no code in the kernel to trigger autoload of the
    evtchn or gntdev drivers. Load them manually during xencommons start.
    Handle both pvops and xenlinux module names.
    
    Signed-off-by: Olaf Hering <olaf@aepfle.de>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    xen-unstable changeset: 24334:9c8aff308002
    Backport-requested-by: Olaf Hering <olaf@aepfle.de>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   23200:7a4fad2d4b05
user:        Olaf Hering <olaf@aepfle.de>
date:        Thu Dec 08 16:50:16 2011 +0000
    
    tools: init.d/Linux/xencommons: run script only when needed
    
    Currently xencommons prints an error that /proc/xen/capabilities does
    not exist when started on a non-xen kernel.
    
    Update the xencommons script to run only when needed:
    - do not run if /proc/xen does not exist
    - check if /proc/xen/capabilities exists before doing the grep for dom0
    
    Signed-off-by: Olaf Hering <olaf@aepfle.de>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    xen-unstable changeset: 24333:4002e63b188a
    Backport-requested-by: Olaf Hering <olaf@aepfle.de>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   23199:d9f8316a8291
user:        Andrew Cooper <andrew.cooper3@citrix.com>
date:        Tue Dec 06 10:53:12 2011 +0000
    
    KEXEC: fix kexec_get_range_compat to fail vocally.
    
    Fail with -ERANGE rather than silently truncating 64bit values (a
    physical address and size) into 32bit integers for dom0 to consume.
    
    Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
    
    Simplify the bitwise arithmetic a bit.
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    xen-unstable changeset:   24358:9961a6d5356a
    xen-unstable date:        Mon Dec 05 19:42:46 2011 +0000
    
    
========================================
commit 3981d218912e186cb4205ee6732f446c177a36a2
Author: Jean Guyader <jean.guyader@eu.citrix.com>
Date:   Tue Nov 22 18:49:15 2011 +0000

    qemu-xen: Don't redefine libpci (3.1.7) defines.
    
    These values are already defined by the libpci heders in the version
    3.1.7.
    
    PCI_STATUS_66MHZ
    PCI_STATUS_RESERVED2
    PCI_STATUS_FAST_BACK
    PCI_MSIX_TABSIZE
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    (cherry picked from commit 174d92a73a5d5e67c49501383a519021b72a2468)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 08 22:35:41 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 Dec 2011 22: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.xensource.com>)
	id 1RYmYl-0001Az-GJ; Thu, 08 Dec 2011 22:35:23 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RYmYj-0001At-VV
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 22:35:22 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1323383660!48797047!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDIwNw==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11280 invoked from network); 8 Dec 2011 22:34:20 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Dec 2011 22:34:20 -0000
X-IronPort-AV: E=Sophos;i="4.71,322,1320624000"; 
   d="scan'208";a="9372932"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Dec 2011 22:34:37 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 8 Dec 2011 22:34:37 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RYmY1-0004U2-HF;
	Thu, 08 Dec 2011 22:34:37 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RYmY1-0005ON-Dp;
	Thu, 08 Dec 2011 22:34:37 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <E1RYmY1-0005ON-Dp@woking.xci-test.com>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 8 Dec 2011 22:34:37 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com, keir@xen.org, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [xen-unstable bisection] complete test-i386-i386-win
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

branch xen-unstable
xen branch xen-unstable
job test-i386-i386-win
test guest-saverestore

Tree: linux git://github.com/jsgf/linux-xen.git
Tree: qemu git://hg.uk.xensource.com/HG/qemu-xen-unstable.git
Tree: xen http://xenbits.xen.org/staging/xen-unstable.hg

*** Found and reproduced problem changeset ***

  Bug is in tree:  qemu git://hg.uk.xensource.com/HG/qemu-xen-unstable.git
  Bug introduced:  13b06e700528b1c4258ce5d768d69b0d499f75ca
  Bug not present: 89daacab7035d408f32f2cb1acf68c96d6cbefed


  commit 13b06e700528b1c4258ce5d768d69b0d499f75ca
  Author: Sefano Stabellini <stefano.stabellini@eu.citrix.com>
  Date:   Thu Dec 1 17:52:01 2011 +0000
  
      xen: don't initialize the RTC timers if xen is available
      
      Xen doesn't need full RTC emulation in Qemu because the RTC is already
      emulated by the hypervisor. Hence don't initialize the RTC timers when Xen is
      available so that Qemu doesn't need to wake up needlessly.
      
      Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>


For bisection revision-tuple graph see:
   http://www.chiark.greenend.org.uk/~xensrcts/results/bisect.xen-unstable.test-i386-i386-win.guest-saverestore.html
Revision IDs in each graph node refer, respectively, to the Trees above.

----------------------------------------
Searching for failure / basis pass:
 10401 fail [host=field-cricket] / 10202 [host=gall-mite] 10201 [host=leaf-beetle] 10195 [host=itch-mite] 10192 [host=lace-bug] 10191 [host=potato-beetle] 10190 [host=moss-bug] 10189 [host=lace-bug] 10185 [host=bush-cricket] 10183 [host=leaf-beetle] 10182 ok.
Failure / basis pass flights: 10401 / 10182
Tree: linux git://github.com/jsgf/linux-xen.git
Tree: qemu git://hg.uk.xensource.com/HG/qemu-xen-unstable.git
Tree: xen http://xenbits.xen.org/staging/xen-unstable.hg
Latest 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 68af5b5191593223709680b89951dfc84a32bee8 38eb74c01d9d
Basis pass 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 89daacab7035d408f32f2cb1acf68c96d6cbefed a2cb7ed6d0a2
Generating revisions with ./adhoc-revtuple-generator  git://github.com/jsgf/linux-xen.git#6bec8b4a4c14095d0b7ce424db9d583c3decae6c-6bec8b4a4c14095d0b7ce424db9d583c3decae6c git://hg.uk.xensource.com/HG/qemu-xen-unstable.git#89daacab7035d408f32f2cb1acf68c96d6cbefed-68af5b5191593223709680b89951dfc84a32bee8 http://xenbits.xen.org/staging/xen-unstable.hg#a2cb7ed6d0a2-38eb74c01d9d
using cache /export/home/osstest/repos/git-cache...
using cache /export/home/osstest/repos/git-cache...
locked cache /export/home/osstest/repos/git-cache...
processing ./cacheing-git clone --bare git://hg.uk.xensource.com/HG/qemu-xen-unstable.git /export/home/osstest/repos/qemu-xen-unstable...
Initialized empty Git repository in /export/home/osstest/repos/qemu-xen-unstable/
updating cache /export/home/osstest/repos/git-cache qemu-xen-unstable...
pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
searching for changes
no changes found
using cache /export/home/osstest/repos/git-cache...
using cache /export/home/osstest/repos/git-cache...
locked cache /export/home/osstest/repos/git-cache...
processing ./cacheing-git clone --bare git://hg.uk.xensource.com/HG/qemu-xen-unstable.git /export/home/osstest/repos/qemu-xen-unstable...
Initialized empty Git repository in /export/home/osstest/repos/qemu-xen-unstable/
updating cache /export/home/osstest/repos/git-cache qemu-xen-unstable...
pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
searching for changes
no changes found
Loaded 1018 nodes in revision graph
Searching for test results:
 10231 [host=bush-cricket]
 10244 []
 10195 [host=itch-mite]
 10201 [host=leaf-beetle]
 10202 [host=gall-mite]
 10176 [host=potato-beetle]
 10182 pass 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 89daacab7035d408f32f2cb1acf68c96d6cbefed a2cb7ed6d0a2
 10183 [host=leaf-beetle]
 10185 [host=bush-cricket]
 10189 [host=lace-bug]
 10190 [host=moss-bug]
 10191 [host=potato-beetle]
 10192 [host=lace-bug]
 10214 fail 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 65b27b1dd6f205835aa8174031eea057c75f8afb 3f815406feb2
 10257 [host=itch-mite]
 10239 [host=leaf-beetle]
 10246 [host=lace-bug]
 10264 []
 10313 []
 10289 []
 10332 []
 10294 []
 10298 []
 10347 []
 10300 []
 10317 []
 10305 []
 10322 []
 10325 []
 10344 []
 10360 [host=itch-mite]
 10353 fail 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 68af5b5191593223709680b89951dfc84a32bee8 9961a6d5356a
 10371 [host=gall-mite]
 10390 [host=bush-cricket]
 10393 fail 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 68af5b5191593223709680b89951dfc84a32bee8 38eb74c01d9d
 10397 [host=itch-mite]
 10427 pass 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 89daacab7035d408f32f2cb1acf68c96d6cbefed a2cb7ed6d0a2
 10428 fail 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 68af5b5191593223709680b89951dfc84a32bee8 38eb74c01d9d
 10447 pass 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 89daacab7035d408f32f2cb1acf68c96d6cbefed ad5941e51c87
 10429 fail 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 9fa2794d45ba915b42b77d4762dfa607d5587dfc b776fcd4a15c
 10401 fail 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 68af5b5191593223709680b89951dfc84a32bee8 38eb74c01d9d
 10430 pass 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 89daacab7035d408f32f2cb1acf68c96d6cbefed 3e5683b6b37f
 10449 fail 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 13b06e700528b1c4258ce5d768d69b0d499f75ca ad5941e51c87
 10431 pass 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 89daacab7035d408f32f2cb1acf68c96d6cbefed d1b9700fa239
 10432 pass 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 89daacab7035d408f32f2cb1acf68c96d6cbefed 3c4c29899d8a
 10433 pass 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 89daacab7035d408f32f2cb1acf68c96d6cbefed 3075955bbea4
 10434 pass 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 89daacab7035d408f32f2cb1acf68c96d6cbefed b6962c4b0dfd
 10436 pass 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 89daacab7035d408f32f2cb1acf68c96d6cbefed 6bac46816504
 10437 fail 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 9fa2794d45ba915b42b77d4762dfa607d5587dfc ad5941e51c87
 10438 pass 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 89daacab7035d408f32f2cb1acf68c96d6cbefed ad5941e51c87
 10439 fail 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 13b06e700528b1c4258ce5d768d69b0d499f75ca ad5941e51c87
 10442 pass 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 89daacab7035d408f32f2cb1acf68c96d6cbefed ad5941e51c87
 10445 fail 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 13b06e700528b1c4258ce5d768d69b0d499f75ca ad5941e51c87
Searching for interesting versions
 Result found: flight 10182 (pass), for basis pass
 Result found: flight 10393 (fail), for basis failure
 Repro found: flight 10427 (pass), for basis pass
 Repro found: flight 10428 (fail), for basis failure
 0 revisions at 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 89daacab7035d408f32f2cb1acf68c96d6cbefed ad5941e51c87
No revisions left to test, checking graph state.
 Result found: flight 10438 (pass), for last pass
 Result found: flight 10439 (fail), for first failure
 Repro found: flight 10442 (pass), for last pass
 Repro found: flight 10445 (fail), for first failure
 Repro found: flight 10447 (pass), for last pass
 Repro found: flight 10449 (fail), for first failure

*** Found and reproduced problem changeset ***

  Bug is in tree:  qemu git://hg.uk.xensource.com/HG/qemu-xen-unstable.git
  Bug introduced:  13b06e700528b1c4258ce5d768d69b0d499f75ca
  Bug not present: 89daacab7035d408f32f2cb1acf68c96d6cbefed

using cache /export/home/osstest/repos/git-cache...
using cache /export/home/osstest/repos/git-cache...
locked cache /export/home/osstest/repos/git-cache...
processing ./cacheing-git clone --bare git://hg.uk.xensource.com/HG/qemu-xen-unstable.git /export/home/osstest/repos/qemu-xen-unstable...
Initialized empty Git repository in /export/home/osstest/repos/qemu-xen-unstable/
updating cache /export/home/osstest/repos/git-cache qemu-xen-unstable...

  commit 13b06e700528b1c4258ce5d768d69b0d499f75ca
  Author: Sefano Stabellini <stefano.stabellini@eu.citrix.com>
  Date:   Thu Dec 1 17:52:01 2011 +0000
  
      xen: don't initialize the RTC timers if xen is available
      
      Xen doesn't need full RTC emulation in Qemu because the RTC is already
      emulated by the hypervisor. Hence don't initialize the RTC timers when Xen is
      available so that Qemu doesn't need to wake up needlessly.
      
      Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Revision graph left in /home/xc_osstest/results/bisect.xen-unstable.test-i386-i386-win.guest-saverestore.{dot,ps,png,html}.
----------------------------------------
10449: ALL FAIL

flight 10449 xen-unstable real-bisect [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10449/


jobs:
 test-i386-i386-win                                           fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 08 22:35:41 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 Dec 2011 22: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.xensource.com>)
	id 1RYmYl-0001Az-GJ; Thu, 08 Dec 2011 22:35:23 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RYmYj-0001At-VV
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 22:35:22 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1323383660!48797047!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDIwNw==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11280 invoked from network); 8 Dec 2011 22:34:20 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Dec 2011 22:34:20 -0000
X-IronPort-AV: E=Sophos;i="4.71,322,1320624000"; 
   d="scan'208";a="9372932"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Dec 2011 22:34:37 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 8 Dec 2011 22:34:37 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RYmY1-0004U2-HF;
	Thu, 08 Dec 2011 22:34:37 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RYmY1-0005ON-Dp;
	Thu, 08 Dec 2011 22:34:37 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <E1RYmY1-0005ON-Dp@woking.xci-test.com>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 8 Dec 2011 22:34:37 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com, keir@xen.org, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [xen-unstable bisection] complete test-i386-i386-win
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

branch xen-unstable
xen branch xen-unstable
job test-i386-i386-win
test guest-saverestore

Tree: linux git://github.com/jsgf/linux-xen.git
Tree: qemu git://hg.uk.xensource.com/HG/qemu-xen-unstable.git
Tree: xen http://xenbits.xen.org/staging/xen-unstable.hg

*** Found and reproduced problem changeset ***

  Bug is in tree:  qemu git://hg.uk.xensource.com/HG/qemu-xen-unstable.git
  Bug introduced:  13b06e700528b1c4258ce5d768d69b0d499f75ca
  Bug not present: 89daacab7035d408f32f2cb1acf68c96d6cbefed


  commit 13b06e700528b1c4258ce5d768d69b0d499f75ca
  Author: Sefano Stabellini <stefano.stabellini@eu.citrix.com>
  Date:   Thu Dec 1 17:52:01 2011 +0000
  
      xen: don't initialize the RTC timers if xen is available
      
      Xen doesn't need full RTC emulation in Qemu because the RTC is already
      emulated by the hypervisor. Hence don't initialize the RTC timers when Xen is
      available so that Qemu doesn't need to wake up needlessly.
      
      Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>


For bisection revision-tuple graph see:
   http://www.chiark.greenend.org.uk/~xensrcts/results/bisect.xen-unstable.test-i386-i386-win.guest-saverestore.html
Revision IDs in each graph node refer, respectively, to the Trees above.

----------------------------------------
Searching for failure / basis pass:
 10401 fail [host=field-cricket] / 10202 [host=gall-mite] 10201 [host=leaf-beetle] 10195 [host=itch-mite] 10192 [host=lace-bug] 10191 [host=potato-beetle] 10190 [host=moss-bug] 10189 [host=lace-bug] 10185 [host=bush-cricket] 10183 [host=leaf-beetle] 10182 ok.
Failure / basis pass flights: 10401 / 10182
Tree: linux git://github.com/jsgf/linux-xen.git
Tree: qemu git://hg.uk.xensource.com/HG/qemu-xen-unstable.git
Tree: xen http://xenbits.xen.org/staging/xen-unstable.hg
Latest 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 68af5b5191593223709680b89951dfc84a32bee8 38eb74c01d9d
Basis pass 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 89daacab7035d408f32f2cb1acf68c96d6cbefed a2cb7ed6d0a2
Generating revisions with ./adhoc-revtuple-generator  git://github.com/jsgf/linux-xen.git#6bec8b4a4c14095d0b7ce424db9d583c3decae6c-6bec8b4a4c14095d0b7ce424db9d583c3decae6c git://hg.uk.xensource.com/HG/qemu-xen-unstable.git#89daacab7035d408f32f2cb1acf68c96d6cbefed-68af5b5191593223709680b89951dfc84a32bee8 http://xenbits.xen.org/staging/xen-unstable.hg#a2cb7ed6d0a2-38eb74c01d9d
using cache /export/home/osstest/repos/git-cache...
using cache /export/home/osstest/repos/git-cache...
locked cache /export/home/osstest/repos/git-cache...
processing ./cacheing-git clone --bare git://hg.uk.xensource.com/HG/qemu-xen-unstable.git /export/home/osstest/repos/qemu-xen-unstable...
Initialized empty Git repository in /export/home/osstest/repos/qemu-xen-unstable/
updating cache /export/home/osstest/repos/git-cache qemu-xen-unstable...
pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
searching for changes
no changes found
using cache /export/home/osstest/repos/git-cache...
using cache /export/home/osstest/repos/git-cache...
locked cache /export/home/osstest/repos/git-cache...
processing ./cacheing-git clone --bare git://hg.uk.xensource.com/HG/qemu-xen-unstable.git /export/home/osstest/repos/qemu-xen-unstable...
Initialized empty Git repository in /export/home/osstest/repos/qemu-xen-unstable/
updating cache /export/home/osstest/repos/git-cache qemu-xen-unstable...
pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
searching for changes
no changes found
Loaded 1018 nodes in revision graph
Searching for test results:
 10231 [host=bush-cricket]
 10244 []
 10195 [host=itch-mite]
 10201 [host=leaf-beetle]
 10202 [host=gall-mite]
 10176 [host=potato-beetle]
 10182 pass 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 89daacab7035d408f32f2cb1acf68c96d6cbefed a2cb7ed6d0a2
 10183 [host=leaf-beetle]
 10185 [host=bush-cricket]
 10189 [host=lace-bug]
 10190 [host=moss-bug]
 10191 [host=potato-beetle]
 10192 [host=lace-bug]
 10214 fail 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 65b27b1dd6f205835aa8174031eea057c75f8afb 3f815406feb2
 10257 [host=itch-mite]
 10239 [host=leaf-beetle]
 10246 [host=lace-bug]
 10264 []
 10313 []
 10289 []
 10332 []
 10294 []
 10298 []
 10347 []
 10300 []
 10317 []
 10305 []
 10322 []
 10325 []
 10344 []
 10360 [host=itch-mite]
 10353 fail 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 68af5b5191593223709680b89951dfc84a32bee8 9961a6d5356a
 10371 [host=gall-mite]
 10390 [host=bush-cricket]
 10393 fail 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 68af5b5191593223709680b89951dfc84a32bee8 38eb74c01d9d
 10397 [host=itch-mite]
 10427 pass 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 89daacab7035d408f32f2cb1acf68c96d6cbefed a2cb7ed6d0a2
 10428 fail 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 68af5b5191593223709680b89951dfc84a32bee8 38eb74c01d9d
 10447 pass 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 89daacab7035d408f32f2cb1acf68c96d6cbefed ad5941e51c87
 10429 fail 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 9fa2794d45ba915b42b77d4762dfa607d5587dfc b776fcd4a15c
 10401 fail 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 68af5b5191593223709680b89951dfc84a32bee8 38eb74c01d9d
 10430 pass 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 89daacab7035d408f32f2cb1acf68c96d6cbefed 3e5683b6b37f
 10449 fail 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 13b06e700528b1c4258ce5d768d69b0d499f75ca ad5941e51c87
 10431 pass 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 89daacab7035d408f32f2cb1acf68c96d6cbefed d1b9700fa239
 10432 pass 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 89daacab7035d408f32f2cb1acf68c96d6cbefed 3c4c29899d8a
 10433 pass 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 89daacab7035d408f32f2cb1acf68c96d6cbefed 3075955bbea4
 10434 pass 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 89daacab7035d408f32f2cb1acf68c96d6cbefed b6962c4b0dfd
 10436 pass 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 89daacab7035d408f32f2cb1acf68c96d6cbefed 6bac46816504
 10437 fail 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 9fa2794d45ba915b42b77d4762dfa607d5587dfc ad5941e51c87
 10438 pass 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 89daacab7035d408f32f2cb1acf68c96d6cbefed ad5941e51c87
 10439 fail 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 13b06e700528b1c4258ce5d768d69b0d499f75ca ad5941e51c87
 10442 pass 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 89daacab7035d408f32f2cb1acf68c96d6cbefed ad5941e51c87
 10445 fail 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 13b06e700528b1c4258ce5d768d69b0d499f75ca ad5941e51c87
Searching for interesting versions
 Result found: flight 10182 (pass), for basis pass
 Result found: flight 10393 (fail), for basis failure
 Repro found: flight 10427 (pass), for basis pass
 Repro found: flight 10428 (fail), for basis failure
 0 revisions at 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 89daacab7035d408f32f2cb1acf68c96d6cbefed ad5941e51c87
No revisions left to test, checking graph state.
 Result found: flight 10438 (pass), for last pass
 Result found: flight 10439 (fail), for first failure
 Repro found: flight 10442 (pass), for last pass
 Repro found: flight 10445 (fail), for first failure
 Repro found: flight 10447 (pass), for last pass
 Repro found: flight 10449 (fail), for first failure

*** Found and reproduced problem changeset ***

  Bug is in tree:  qemu git://hg.uk.xensource.com/HG/qemu-xen-unstable.git
  Bug introduced:  13b06e700528b1c4258ce5d768d69b0d499f75ca
  Bug not present: 89daacab7035d408f32f2cb1acf68c96d6cbefed

using cache /export/home/osstest/repos/git-cache...
using cache /export/home/osstest/repos/git-cache...
locked cache /export/home/osstest/repos/git-cache...
processing ./cacheing-git clone --bare git://hg.uk.xensource.com/HG/qemu-xen-unstable.git /export/home/osstest/repos/qemu-xen-unstable...
Initialized empty Git repository in /export/home/osstest/repos/qemu-xen-unstable/
updating cache /export/home/osstest/repos/git-cache qemu-xen-unstable...

  commit 13b06e700528b1c4258ce5d768d69b0d499f75ca
  Author: Sefano Stabellini <stefano.stabellini@eu.citrix.com>
  Date:   Thu Dec 1 17:52:01 2011 +0000
  
      xen: don't initialize the RTC timers if xen is available
      
      Xen doesn't need full RTC emulation in Qemu because the RTC is already
      emulated by the hypervisor. Hence don't initialize the RTC timers when Xen is
      available so that Qemu doesn't need to wake up needlessly.
      
      Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Revision graph left in /home/xc_osstest/results/bisect.xen-unstable.test-i386-i386-win.guest-saverestore.{dot,ps,png,html}.
----------------------------------------
10449: ALL FAIL

flight 10449 xen-unstable real-bisect [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10449/


jobs:
 test-i386-i386-win                                           fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 08 22:39:29 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 Dec 2011 22: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.xensource.com>)
	id 1RYmcW-0001RE-BL; Thu, 08 Dec 2011 22:39:16 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RYmcV-0001Qv-Ko
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 22:39:15 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-4.tower-174.messagelabs.com!1323383906!4810874!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17479 invoked from network); 8 Dec 2011 22:38:26 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-4.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 8 Dec 2011 22:38:26 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RYmbe-000NYK-SH; Thu, 08 Dec 2011 22:38:22 +0000
Date: Thu, 8 Dec 2011 22:38:22 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20111208223822.GH87836@ocelot.phlegethon.org>
References: <patchbomb.1323330435@xdev.gridcentric.ca>
	<ecf95feef9ac5a7d0b79.1323330447@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <ecf95feef9ac5a7d0b79.1323330447@xdev.gridcentric.ca>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com, ian.campbell@citrix.com,
	andres@gridcentric.ca, keir.xen@gmail.com, JBeulich@suse.com,
	ian.jackson@citrix.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 12 of 18] x86/mm: Make page_lock/unlock() in
	arch/x86/mm.c externally callable
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 02:47 -0500 on 08 Dec (1323312447), Andres Lagar-Cavilla wrote:
> This is necessary for a new consumer of page_lock/unlock to follow in
> the series.
> 
> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

Nak, I'm afraid. 

These were OK as local functions but if they're going to be made
generally visible, they need clear comments describing what this
locking protects and what the discipline is for avoiding deadlocks.

Perhaps Jan or Keir can supply appropriate words.  The locking was
introduce in this cset:

    changeset:   17846:09dd5999401b
    user:        Keir Fraser <keir.fraser@citrix.com>
    date:        Thu Jun 12 18:14:00 2008 +0100
    files:       xen/arch/x86/domain.c xen/arch/x86/domain_build.c
    xen/arch/x86/mm.c
    description:
    x86: remove use of per-domain lock from page table entry handling
    
    This change results in a 5% performance improvement for kernel builds
    on dual-socket quad-core systems (which is what I used for reference
    for both 32- and 64-bit). Along with that, the amount of time reported
    as spent in the kernel gets reduced by almost 25% (the fraction of
    time spent in the kernel is generally reported significantly higher
    under Xen than with a native kernel).
    
    Signed-off-by: Jan Beulich <jbeulich@novell.com>
    Signed-off-by: Keir Fraser <keir.fraser@citrix.com>    

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 08 22:39:29 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 Dec 2011 22: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.xensource.com>)
	id 1RYmcW-0001RE-BL; Thu, 08 Dec 2011 22:39:16 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RYmcV-0001Qv-Ko
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 22:39:15 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-4.tower-174.messagelabs.com!1323383906!4810874!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17479 invoked from network); 8 Dec 2011 22:38:26 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-4.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 8 Dec 2011 22:38:26 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RYmbe-000NYK-SH; Thu, 08 Dec 2011 22:38:22 +0000
Date: Thu, 8 Dec 2011 22:38:22 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20111208223822.GH87836@ocelot.phlegethon.org>
References: <patchbomb.1323330435@xdev.gridcentric.ca>
	<ecf95feef9ac5a7d0b79.1323330447@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <ecf95feef9ac5a7d0b79.1323330447@xdev.gridcentric.ca>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com, ian.campbell@citrix.com,
	andres@gridcentric.ca, keir.xen@gmail.com, JBeulich@suse.com,
	ian.jackson@citrix.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 12 of 18] x86/mm: Make page_lock/unlock() in
	arch/x86/mm.c externally callable
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 02:47 -0500 on 08 Dec (1323312447), Andres Lagar-Cavilla wrote:
> This is necessary for a new consumer of page_lock/unlock to follow in
> the series.
> 
> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

Nak, I'm afraid. 

These were OK as local functions but if they're going to be made
generally visible, they need clear comments describing what this
locking protects and what the discipline is for avoiding deadlocks.

Perhaps Jan or Keir can supply appropriate words.  The locking was
introduce in this cset:

    changeset:   17846:09dd5999401b
    user:        Keir Fraser <keir.fraser@citrix.com>
    date:        Thu Jun 12 18:14:00 2008 +0100
    files:       xen/arch/x86/domain.c xen/arch/x86/domain_build.c
    xen/arch/x86/mm.c
    description:
    x86: remove use of per-domain lock from page table entry handling
    
    This change results in a 5% performance improvement for kernel builds
    on dual-socket quad-core systems (which is what I used for reference
    for both 32- and 64-bit). Along with that, the amount of time reported
    as spent in the kernel gets reduced by almost 25% (the fraction of
    time spent in the kernel is generally reported significantly higher
    under Xen than with a native kernel).
    
    Signed-off-by: Jan Beulich <jbeulich@novell.com>
    Signed-off-by: Keir Fraser <keir.fraser@citrix.com>    

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 08 22:41:21 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 Dec 2011 22:41:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYmeE-0001YN-SX; Thu, 08 Dec 2011 22:41:02 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RYmeD-0001Xu-Dr
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 22:41:01 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-13.tower-21.messagelabs.com!1323384011!5536647!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25684 invoked from network); 8 Dec 2011 22:40:11 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-13.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 8 Dec 2011 22:40:11 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RYmdO-000NYy-Ml; Thu, 08 Dec 2011 22:40:10 +0000
Date: Thu, 8 Dec 2011 22:40:10 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20111208224010.GI87836@ocelot.phlegethon.org>
References: <patchbomb.1323352476@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <patchbomb.1323352476@xdev.gridcentric.ca>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com, ian.campbell@citrix.com,
	andres@gridcentric.ca, keir.xen@gmail.com, JBeulich@suse.com,
	ian.jackson@citrix.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 0 of 5] Memory sharing overhaul part 2
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 08:54 -0500 on 08 Dec (1323334476), Andres Lagar-Cavilla wrote:
> (Sigh, the previous pachbomb got truncated by an smtp quota in my 
> provider... remaining patches in this series)

I only got up to #12/18 in the previous round, so by my count I'm still
one short.  

Cheers,

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 08 22:41:21 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 Dec 2011 22:41:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYmeE-0001YN-SX; Thu, 08 Dec 2011 22:41:02 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RYmeD-0001Xu-Dr
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 22:41:01 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-13.tower-21.messagelabs.com!1323384011!5536647!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25684 invoked from network); 8 Dec 2011 22:40:11 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-13.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 8 Dec 2011 22:40:11 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RYmdO-000NYy-Ml; Thu, 08 Dec 2011 22:40:10 +0000
Date: Thu, 8 Dec 2011 22:40:10 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20111208224010.GI87836@ocelot.phlegethon.org>
References: <patchbomb.1323352476@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <patchbomb.1323352476@xdev.gridcentric.ca>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com, ian.campbell@citrix.com,
	andres@gridcentric.ca, keir.xen@gmail.com, JBeulich@suse.com,
	ian.jackson@citrix.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 0 of 5] Memory sharing overhaul part 2
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 08:54 -0500 on 08 Dec (1323334476), Andres Lagar-Cavilla wrote:
> (Sigh, the previous pachbomb got truncated by an smtp quota in my 
> provider... remaining patches in this series)

I only got up to #12/18 in the previous round, so by my count I'm still
one short.  

Cheers,

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 08 23:08:08 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 Dec 2011 23:08:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYn48-0001sp-Ax; Thu, 08 Dec 2011 23:07:48 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RYn47-0001sj-8M
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 23:07:47 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1323385618!7512387!1
X-Originating-IP: [209.85.214.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12892 invoked from network); 8 Dec 2011 23:06:58 -0000
Received: from mail-bw0-f43.google.com (HELO mail-bw0-f43.google.com)
	(209.85.214.43)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Dec 2011 23:06:58 -0000
Received: by bkbzs2 with SMTP id zs2so6657578bkb.30
	for <xen-devel@lists.xensource.com>;
	Thu, 08 Dec 2011 15:06:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=b1hcieamqifF7CSxleNzWVonGn9HyQGfwzZKbJja4WY=;
	b=XmKjzAs/8Q9Lk3yIS3+/Pa35rP6hp1zTTBC6Z2hmqVUpv+d3rgUumEvQpyJZyaAdBi
	x+7G2d3mh46ZJBpScafO6BbpJyY8tAdsfpvxZNepUJjJpu4lBVb5OX30uEetUFxZxmTo
	E7jziP31qqimDe3A6TOetJvM01QXW54mC1LBU=
Received: by 10.180.88.66 with SMTP id be2mr7936986wib.54.1323385618017;
	Thu, 08 Dec 2011 15:06:58 -0800 (PST)
Received: from [192.168.1.70]
	(host81-155-119-104.range81-155.btcentralplus.com. [81.155.119.104])
	by mx.google.com with ESMTPS id fk3sm10453475wbb.10.2011.12.08.15.06.54
	(version=SSLv3 cipher=OTHER); Thu, 08 Dec 2011 15:06:57 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Thu, 08 Dec 2011 23:06:45 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Tim Deegan <tim@xen.org>,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <CB06F385.26D54%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH 12 of 18] x86/mm: Make page_lock/unlock() in
	arch/x86/mm.c externally callable
Thread-Index: Acy1/g4cLQR/43XB+UmWmzRY6Ny0wg==
In-Reply-To: <20111208223822.GH87836@ocelot.phlegethon.org>
Mime-version: 1.0
Cc: xen-devel@lists.xensource.com, ian.campbell@citrix.com,
	andres@gridcentric.ca, JBeulich@suse.com, ian.jackson@citrix.com,
	adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 12 of 18] x86/mm: Make page_lock/unlock() in
 arch/x86/mm.c externally callable
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 08/12/2011 22:38, "Tim Deegan" <tim@xen.org> wrote:

> At 02:47 -0500 on 08 Dec (1323312447), Andres Lagar-Cavilla wrote:
>> This is necessary for a new consumer of page_lock/unlock to follow in
>> the series.
>> 
>> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
> 
> Nak, I'm afraid. 
> 
> These were OK as local functions but if they're going to be made
> generally visible, they need clear comments describing what this
> locking protects and what the discipline is for avoiding deadlocks.
> 
> Perhaps Jan or Keir can supply appropriate words.  The locking was
> introduce in this cset:

It's Jan's work originally, but the basic intention of page_lock is to
serialise pte updates. To aid with this, a page's type cannot change while
its lock is held. No lock nests inside a page lock (not even other page
locks) so there is no deadlock risk.

>     changeset:   17846:09dd5999401b
>     user:        Keir Fraser <keir.fraser@citrix.com>
>     date:        Thu Jun 12 18:14:00 2008 +0100
>     files:       xen/arch/x86/domain.c xen/arch/x86/domain_build.c
>     xen/arch/x86/mm.c
>     description:
>     x86: remove use of per-domain lock from page table entry handling
>     
>     This change results in a 5% performance improvement for kernel builds
>     on dual-socket quad-core systems (which is what I used for reference
>     for both 32- and 64-bit). Along with that, the amount of time reported
>     as spent in the kernel gets reduced by almost 25% (the fraction of
>     time spent in the kernel is generally reported significantly higher
>     under Xen than with a native kernel).
>     
>     Signed-off-by: Jan Beulich <jbeulich@novell.com>
>     Signed-off-by: Keir Fraser <keir.fraser@citrix.com>
> 
> Tim.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 08 23:08:08 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 Dec 2011 23:08:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYn48-0001sp-Ax; Thu, 08 Dec 2011 23:07:48 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RYn47-0001sj-8M
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 23:07:47 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1323385618!7512387!1
X-Originating-IP: [209.85.214.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12892 invoked from network); 8 Dec 2011 23:06:58 -0000
Received: from mail-bw0-f43.google.com (HELO mail-bw0-f43.google.com)
	(209.85.214.43)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Dec 2011 23:06:58 -0000
Received: by bkbzs2 with SMTP id zs2so6657578bkb.30
	for <xen-devel@lists.xensource.com>;
	Thu, 08 Dec 2011 15:06:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=b1hcieamqifF7CSxleNzWVonGn9HyQGfwzZKbJja4WY=;
	b=XmKjzAs/8Q9Lk3yIS3+/Pa35rP6hp1zTTBC6Z2hmqVUpv+d3rgUumEvQpyJZyaAdBi
	x+7G2d3mh46ZJBpScafO6BbpJyY8tAdsfpvxZNepUJjJpu4lBVb5OX30uEetUFxZxmTo
	E7jziP31qqimDe3A6TOetJvM01QXW54mC1LBU=
Received: by 10.180.88.66 with SMTP id be2mr7936986wib.54.1323385618017;
	Thu, 08 Dec 2011 15:06:58 -0800 (PST)
Received: from [192.168.1.70]
	(host81-155-119-104.range81-155.btcentralplus.com. [81.155.119.104])
	by mx.google.com with ESMTPS id fk3sm10453475wbb.10.2011.12.08.15.06.54
	(version=SSLv3 cipher=OTHER); Thu, 08 Dec 2011 15:06:57 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Thu, 08 Dec 2011 23:06:45 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Tim Deegan <tim@xen.org>,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <CB06F385.26D54%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH 12 of 18] x86/mm: Make page_lock/unlock() in
	arch/x86/mm.c externally callable
Thread-Index: Acy1/g4cLQR/43XB+UmWmzRY6Ny0wg==
In-Reply-To: <20111208223822.GH87836@ocelot.phlegethon.org>
Mime-version: 1.0
Cc: xen-devel@lists.xensource.com, ian.campbell@citrix.com,
	andres@gridcentric.ca, JBeulich@suse.com, ian.jackson@citrix.com,
	adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 12 of 18] x86/mm: Make page_lock/unlock() in
 arch/x86/mm.c externally callable
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 08/12/2011 22:38, "Tim Deegan" <tim@xen.org> wrote:

> At 02:47 -0500 on 08 Dec (1323312447), Andres Lagar-Cavilla wrote:
>> This is necessary for a new consumer of page_lock/unlock to follow in
>> the series.
>> 
>> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
> 
> Nak, I'm afraid. 
> 
> These were OK as local functions but if they're going to be made
> generally visible, they need clear comments describing what this
> locking protects and what the discipline is for avoiding deadlocks.
> 
> Perhaps Jan or Keir can supply appropriate words.  The locking was
> introduce in this cset:

It's Jan's work originally, but the basic intention of page_lock is to
serialise pte updates. To aid with this, a page's type cannot change while
its lock is held. No lock nests inside a page lock (not even other page
locks) so there is no deadlock risk.

>     changeset:   17846:09dd5999401b
>     user:        Keir Fraser <keir.fraser@citrix.com>
>     date:        Thu Jun 12 18:14:00 2008 +0100
>     files:       xen/arch/x86/domain.c xen/arch/x86/domain_build.c
>     xen/arch/x86/mm.c
>     description:
>     x86: remove use of per-domain lock from page table entry handling
>     
>     This change results in a 5% performance improvement for kernel builds
>     on dual-socket quad-core systems (which is what I used for reference
>     for both 32- and 64-bit). Along with that, the amount of time reported
>     as spent in the kernel gets reduced by almost 25% (the fraction of
>     time spent in the kernel is generally reported significantly higher
>     under Xen than with a native kernel).
>     
>     Signed-off-by: Jan Beulich <jbeulich@novell.com>
>     Signed-off-by: Keir Fraser <keir.fraser@citrix.com>
> 
> Tim.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 08 23:47:54 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 Dec 2011 23:47:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYngO-0002WN-5v; Thu, 08 Dec 2011 23:47:20 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.r.wilk@gmail.com>) id 1RYngL-0002WI-I9
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 23:47:17 +0000
X-Env-Sender: konrad.r.wilk@gmail.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1323387951!47139991!1
X-Originating-IP: [209.85.216.171]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26591 invoked from network); 8 Dec 2011 23:45:52 -0000
Received: from mail-qy0-f171.google.com (HELO mail-qy0-f171.google.com)
	(209.85.216.171)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Dec 2011 23:45:52 -0000
Received: by qcsc20 with SMTP id c20so18064714qcs.30
	for <xen-devel@lists.xensource.com>;
	Thu, 08 Dec 2011 15:46:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:date:from:to:cc:subject:message-id:references:mime-version
	:content-type:content-disposition:in-reply-to:user-agent;
	bh=vecwLqpacNAUKdXseqk/OEhmKvw0b/ajkMBALi4mOtk=;
	b=np8ar+VEiB8HBX2UfVhQNN4AlQEZ8vkt27byHXSmCdlcslzoNbYXV3I3ZaKu7fNcGS
	2NbBIdUKZ3qbnpxvsjUHAl/Rw8fDyaF0LDYox1izBURxLps6X4ngOVdFEbPWl59ik/7E
	JhtSaKHY365MKZsNBUblAs7rJuEneZqiSnu1I=
Received: by 10.229.24.139 with SMTP id v11mr1338592qcb.175.1323387988623;
	Thu, 08 Dec 2011 15:46:28 -0800 (PST)
Received: from konrad-lan (209-6-85-33.c3-0.smr-ubr2.sbo-smr.ma.cable.rcn.com.
	[209.6.85.33])
	by mx.google.com with ESMTPS id df3sm12793829qab.6.2011.12.08.15.46.27
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 08 Dec 2011 15:46:28 -0800 (PST)
Date: Thu, 8 Dec 2011 18:46:24 -0500
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Roderick Colenbrander <thunderbird2k@gmail.com>
Message-ID: <20111208234624.GD32474@konrad-lan>
References: <CAEc3jaBds7xmiKH8RMfmEHQumkEeZ3PopVfbZPs_B-Kz8-DsWw@mail.gmail.com>
	<4ED51291.1010308@hfp.de>
	<CAEc3jaAa7y8C2NNBn1=L3AhS0uuYFP6ze8o1cZ9yG2VYHx6qMA@mail.gmail.com>
	<4ED5215D.1010403@hfp.de>
	<20111129230212.GA23958@andromeda.dapyr.net>
	<CAEc3jaAO0JhtOt6phQHwtE_A+NF7uGHGZ8uJv3BirEYybfVceg@mail.gmail.com>
	<CAEc3jaACffpr9D1Hq_012vHAGhPLEfvsZjh7YyJ=Q-3FdtHS0Q@mail.gmail.com>
	<CAPbh3rtOQ1HTPReqYcpE3vzk+-na0MTLLHZD15=Fg4yxB+ypaA@mail.gmail.com>
	<CAEc3jaBdQKmVJToNZRf+25GtJXqGc274ieHf_yHKRJ+YOKWdgA@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAEc3jaBdQKmVJToNZRf+25GtJXqGc274ieHf_yHKRJ+YOKWdgA@mail.gmail.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: xen-devel@lists.xensource.com, Andreas Kinzler <ml-xen-devel@hfp.de>
Subject: Re: [Xen-devel] Questions about GPLPV stability tests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Dec 07, 2011 at 08:44:19PM +0000, Roderick Colenbrander wrote:
> On Wed, Dec 7, 2011 at 8:38 PM, Konrad Rzeszutek Wilk <konrad@darnok.org> wrote:
> >> It took about a week, but the systems went down again. Linux is down,
> >> but the hypervisor is still reachable on the serial console. Is there
> >> anything interesting to dump from there?
> >>
> > Just the interrupts information. I think that is Ctrl-A, Ctrl-A,
> > Ctrl-A, and then '*' to capture everything (I don't remember the right
> > one for just interrupts).
> 
> Here's the interrupt information:
> (XEN) [2011-12-06 19:13:37] [i: dump interrupt bindings]
> (XEN) [2011-12-06 19:13:37] Guest interrupt information:
> (XEN) [2011-12-06 19:13:37]    IRQ:   0
> affinity:00000000,00000000,00000000,00000001 vec:f0 type=IO-APIC-edge
>   status=00000000 mapped, unbound
> (XEN) [2011-12-06 19:13:37]    IRQ:   1
> affinity:00000000,00000000,00000000,00000001 vec:30 type=IO-APIC-edge
>   status=00000014 in-flight=0 domain-list=0:  1(-S--),
> (XEN) [2011-12-06 19:13:37]    IRQ:   2
> affinity:ffffffff,ffffffff,ffffffff,ffffffff vec:e2 type=XT-PIC
>   status=00000000 mapped, unbound
> (XEN) [2011-12-06 19:13:37]    IRQ:   3
> affinity:00000000,00000000,00000000,00000001 vec:38 type=IO-APIC-edge
>   status=00000006 mapped, unbound
> (XEN) [2011-12-06 19:13:37]    IRQ:   4
> affinity:00000000,00000000,00000000,00000001 vec:40 type=IO-APIC-edge
>   status=00000002 mapped, unbound
> (XEN) [2011-12-06 19:13:37]    IRQ:   5
> affinity:00000000,00000000,00000000,00000001 vec:f1 type=IO-APIC-edge
>   status=00000000 mapped, unbound
> (XEN) [2011-12-06 19:13:37]    IRQ:   6
> affinity:00000000,00000000,00000000,00000001 vec:48 type=IO-APIC-edge
>   status=00000002 mapped, unbound
> (XEN) [2011-12-06 19:13:37]    IRQ:   7
> affinity:00000000,00000000,00000000,00000001 vec:50 type=IO-APIC-edge
>   status=00000002 mapped, unbound
> (XEN) [2011-12-06 19:13:37]    IRQ:   8
> affinity:00000000,00000000,00000000,00000001 vec:58 type=IO-APIC-edge
>   status=00000010 in-flight=0 domain-list=0:  8(-S--),
> (XEN) [2011-12-06 19:13:37]    IRQ:   9
> affinity:00000000,00000000,00000000,00000001 vec:60 type=IO-APIC-level
>   status=00000010 in-flight=0 domain-list=0:  9(-S--),
> (XEN) [2011-12-06 19:13:37]    IRQ:  10
> affinity:00000000,00000000,00000000,00000001 vec:68 type=IO-APIC-edge
>   status=00000002 mapped, unbound
> (XEN) [2011-12-06 19:13:37]    IRQ:  11
> affinity:00000000,00000000,00000000,00000001 vec:70 type=IO-APIC-edge
>   status=00000002 mapped, unbound
> (XEN) [2011-12-06 19:13:37]    IRQ:  12
> affinity:00000000,00000000,00000000,00000001 vec:78 type=IO-APIC-edge
>   status=00000010 in-flight=0 domain-list=0: 12(-S--),
> (XEN) [2011-12-06 19:13:37]    IRQ:  13
> affinity:00000000,00000000,00000000,00000001 vec:88 type=IO-APIC-edge
>   status=00000002 mapped, unbound
> (XEN) [2011-12-06 19:13:37]    IRQ:  14
> affinity:00000000,00000000,00000000,00000001 vec:90 type=IO-APIC-edge
>   status=00000002 mapped, unbound
> (XEN) [2011-12-06 19:13:37]    IRQ:  15
> affinity:00000000,00000000,00000000,00000001 vec:98 type=IO-APIC-edge
>   status=00000002 mapped, unbound
> (XEN) [2011-12-06 19:13:37]    IRQ:  16
> affinity:00000000,00000000,00000000,00000001 vec:c8 type=IO-APIC-level
>   status=00000010 in-flight=0 domain-list=0: 16(-S--),1201: 16(--M-),
> (XEN) [2011-12-06 19:13:37]    IRQ:  18
> affinity:00000000,00000000,00000000,00000001 vec:51 type=IO-APIC-level
>   status=00000010 in-flight=0 domain-list=0: 18(-S--),
> (XEN) [2011-12-06 19:13:37]    IRQ:  19
> affinity:00000000,00000000,00000000,00000001 vec:d0 type=IO-APIC-level
>   status=00000010 in-flight=0 domain-list=0: 19(-S--),
> (XEN) [2011-12-06 19:13:37]    IRQ:  21
> affinity:00000000,00000000,00000000,00000001 vec:61 type=IO-APIC-level
>   status=00000010 in-flight=0 domain-list=0: 21(-S--),
> (XEN) [2011-12-06 19:13:37]    IRQ:  23
> affinity:00000000,00000000,00000000,00000001 vec:59 type=IO-APIC-level
>   status=00000010 in-flight=1 domain-list=0: 23(PS-M),
> (XEN) [2011-12-06 19:13:37]    IRQ:  24
> affinity:00000000,00000000,00000000,00000001 vec:28 type=DMA_MSI
>   status=00000000 mapped, unbound
> (XEN) [2011-12-06 19:13:38]    IRQ:  25
> affinity:00000000,00000000,00000000,00000001 vec:a0 type=PCI-MSI
>   status=00000002 mapped, unbound
> (XEN) [2011-12-06 19:13:38]    IRQ:  26
> affinity:00000000,00000000,00000000,00000001 vec:a8 type=PCI-MSI
>   status=00000002 mapped, unbound
> (XEN) [2011-12-06 19:13:38]    IRQ:  27
> affinity:00000000,00000000,00000000,00000001 vec:b0 type=PCI-MSI
>   status=00000002 mapped, unbound
> (XEN) [2011-12-06 19:13:38]    IRQ:  28
> affinity:00000000,00000000,00000000,00000001 vec:b8 type=PCI-MSI
>   status=00000002 mapped, unbound
> (XEN) [2011-12-06 19:13:38]    IRQ:  29
> affinity:00000000,00000000,00000000,00000001 vec:c0 type=PCI-MSI
>   status=00000002 mapped, unbound
> (XEN) [2011-12-06 19:13:38]    IRQ:  30
> affinity:00000000,00000000,00000000,00000001 vec:d8 type=PCI-MSI
>   status=00000014 in-flight=0 domain-list=0:274(PS--),
> (XEN) [2011-12-06 19:13:38]    IRQ:  31
> affinity:00000000,00000000,00000000,00000001 vec:21 type=PCI-MSI
>   status=00000010 in-flight=0 domain-list=0:273(PS--),
> (XEN) [2011-12-06 19:13:38]    IRQ:  32
> affinity:00000000,00000000,00000000,00000001 vec:29 type=PCI-MSI
>   status=00000010 in-flight=0 domain-list=0:272(PS--),
> (XEN) [2011-12-06 19:13:38]    IRQ:  33
> affinity:00000000,00000000,00000000,00000001 vec:31 type=PCI-MSI
>   status=00000010 in-flight=0 domain-list=0:271(PS--),
> (XEN) [2011-12-06 19:13:38]    IRQ:  34
> affinity:ffffffff,ffffffff,ffffffff,ffffffff vec:39 type=PCI-MSI
>   status=00000002 mapped, unbound
> (XEN) [2011-12-06 19:13:38]    IRQ:  35
> affinity:ffffffff,ffffffff,ffffffff,ffffffff vec:41 type=PCI-MSI
>   status=00000002 mapped, unbound
> (XEN) [2011-12-06 19:13:38]    IRQ:  36
> affinity:ffffffff,ffffffff,ffffffff,ffffffff vec:49 type=PCI-MSI
>   status=00000002 mapped, unbound
> (XEN) [2011-12-06 19:13:38]    IRQ:  37
> affinity:00000000,00000000,00000000,00000010 vec:65 type=PCI-MSI
>   status=00000010 in-flight=0 domain-list=1201: 55(--M-),
> (XEN) [2011-12-06 19:13:38] IO-APIC interrupt information:
> (XEN) [2011-12-06 19:13:38]     IRQ  0 Vec240:
> (XEN) [2011-12-06 19:13:38]       Apic 0x00, Pin  2: vector=240,
> delivery_mode=1, dest_mode=logical, delivery_status=0, polarity=0,
> irr=0, trigger=edge, mask=0, dest_id:1
> (XEN) [2011-12-06 19:13:38]     IRQ  1 Vec 48:
> (XEN) [2011-12-06 19:13:38]       Apic 0x00, Pin  1: vector=48,
> delivery_mode=1, dest_mode=logical, delivery_status=0, polarity=0,
> irr=0, trigger=edge, mask=0, dest_id:1
> (XEN) [2011-12-06 19:13:38]     IRQ  3 Vec 56:
> (XEN) [2011-12-06 19:13:38]       Apic 0x00, Pin  3: vector=56,
> delivery_mode=1, dest_mode=logical, delivery_status=0, polarity=0,
> irr=0, trigger=edge, mask=0, dest_id:1
> (XEN) [2011-12-06 19:13:38]     IRQ  4 Vec 64:
> (XEN) [2011-12-06 19:13:38]       Apic 0x00, Pin  4: vector=64,
> delivery_mode=1, dest_mode=logical, delivery_status=0, polarity=0,
> irr=0, trigger=edge, mask=0, dest_id:1
> (XEN) [2011-12-06 19:13:38]     IRQ  5 Vec241:
> (XEN) [2011-12-06 19:13:38]       Apic 0x00, Pin  5: vector=241,
> delivery_mode=1, dest_mode=logical, delivery_status=0, polarity=0,
> irr=0, trigger=edge, mask=0, dest_id:1
> (XEN) [2011-12-06 19:13:38]     IRQ  6 Vec 72:
> (XEN) [2011-12-06 19:13:38]       Apic 0x00, Pin  6: vector=72,
> delivery_mode=1, dest_mode=logical, delivery_status=0, polarity=0,
> irr=0, trigger=edge, mask=0, dest_id:1
> (XEN) [2011-12-06 19:13:38]     IRQ  7 Vec 80:
> (XEN) [2011-12-06 19:13:38]       Apic 0x00, Pin  7: vector=80,
> delivery_mode=1, dest_mode=logical, delivery_status=0, polarity=0,
> irr=0, trigger=edge, mask=0, dest_id:1
> (XEN) [2011-12-06 19:13:38]     IRQ  8 Vec 88:
> (XEN) [2011-12-06 19:13:38]       Apic 0x00, Pin  8: vector=88,
> delivery_mode=1, dest_mode=logical, delivery_status=0, polarity=0,
> irr=0, trigger=edge, mask=0, dest_id:1
> (XEN) [2011-12-06 19:13:38]     IRQ  9 Vec 96:
> (XEN) [2011-12-06 19:13:38]       Apic 0x00, Pin  9: vector=96,
> delivery_mode=1, dest_mode=logical, delivery_status=0, polarity=0,
> irr=0, trigger=level, mask=0, dest_id:1
> (XEN) [2011-12-06 19:13:38]     IRQ 10 Vec104:
> (XEN) [2011-12-06 19:13:38]       Apic 0x00, Pin 10: vector=104,
> delivery_mode=1, dest_mode=logical, delivery_status=0, polarity=0,
> irr=0, trigger=edge, mask=0, dest_id:1
> (XEN) [2011-12-06 19:13:38]     IRQ 11 Vec112:
> (XEN) [2011-12-06 19:13:38]       Apic 0x00, Pin 11: vector=112,
> delivery_mode=1, dest_mode=logical, delivery_status=0, polarity=0,
> irr=0, trigger=edge, mask=0, dest_id:1
> (XEN) [2011-12-06 19:13:38]     IRQ 12 Vec120:
> (XEN) [2011-12-06 19:13:38]       Apic 0x00, Pin 12: vector=120,
> delivery_mode=1, dest_mode=logical, delivery_status=0, polarity=0,
> irr=0, trigger=edge, mask=0, dest_id:1
> (XEN) [2011-12-06 19:13:38]     IRQ 13 Vec136:
> (XEN) [2011-12-06 19:13:38]       Apic 0x00, Pin 13: vector=136,
> delivery_mode=1, dest_mode=logical, delivery_status=0, polarity=0,
> irr=0, trigger=edge, mask=0, dest_id:1
> (XEN) [2011-12-06 19:13:38]     IRQ 14 Vec144:
> (XEN) [2011-12-06 19:13:38]       Apic 0x00, Pin 14: vector=144,
> delivery_mode=1, dest_mode=logical, delivery_status=0, polarity=0,
> irr=0, trigger=edge, mask=0, dest_id:1
> (XEN) [2011-12-06 19:13:38]     IRQ 15 Vec152:
> (XEN) [2011-12-06 19:13:38]       Apic 0x00, Pin 15: vector=152,
> delivery_mode=1, dest_mode=logical, delivery_status=0, polarity=0,
> irr=0, trigger=edge, mask=0, dest_id:1
> (XEN) [2011-12-06 19:13:38]     IRQ 16 Vec200:
> (XEN) [2011-12-06 19:13:38]       Apic 0x00, Pin 16: vector=200,
> delivery_mode=1, dest_mode=logical, delivery_status=0, polarity=1,
> irr=0, trigger=level, mask=0, dest_id:1
> (XEN) [2011-12-06 19:13:38]     IRQ 18 Vec 81:
> (XEN) [2011-12-06 19:13:38]       Apic 0x00, Pin 18: vector=81,
> delivery_mode=1, dest_mode=logical, delivery_status=0, polarity=1,
> irr=0, trigger=level, mask=0, dest_id:1
> (XEN) [2011-12-06 19:13:38]     IRQ 19 Vec208:
> (XEN) [2011-12-06 19:13:38]       Apic 0x00, Pin 19: vector=208,
> delivery_mode=1, dest_mode=logical, delivery_status=0, polarity=1,
> irr=0, trigger=level, mask=0, dest_id:1
> (XEN) [2011-12-06 19:13:38]     IRQ 21 Vec 97:
> (XEN) [2011-12-06 19:13:38]       Apic 0x00, Pin 21: vector=97,
> delivery_mode=1, dest_mode=logical, delivery_status=0, polarity=1,
> irr=0, trigger=level, mask=0, dest_id:1
> (XEN) [2011-12-06 19:13:38]     IRQ 23 Vec 89:
> (XEN) [2011-12-06 19:13:38]       Apic 0x00, Pin 23: vector=89,
> delivery_mode=1, dest_mode=logical, delivery_status=1, polarity=1,
> irr=1, trigger=level, mask=0, dest_id:1
> 
> I noticed some potential interesting things. The system in question is
> using PCI passthrough. On the serial console I remember seeing that
> the PCI device got unmapped from DomU and got mapped again in Dom0.
> The serial console log still had a lot of information about this DomU
> which I guess was going down. I guess it wasn't fully down yet.

One of the debug informations that gets printed with '*' is the guest
PCI passthrough data. Such as which IRQ, BAR, etc are mapped in. Did any
of those exist?

My original thought of what is going on is that the interrupts either
stopped completly working (does not look like - it looks like the
interrupts are firring and the event channels that are bound to it have
the bits set saying - hey I am pending). Oddly there are bunch of MSI
ones that are masked which usually means they are disabled.

Then there is the 
 affinity:00000000,00000000,00000000,00000001 vec:c8 type=IO-APIC-level
   status=00000010 in-flight=0 domain-list=0: 16(-S--),1201: 16(--M-),
 affinity:00000000,00000000,00000000,00000010 vec:65 type=PCI-MSI
   status=00000010 in-flight=0 domain-list=1201: 55(--M-),

The guest has masked both interrupts - so it is off//dying, but somehow
the unmapping has not happend. In other words, what you just analyzed
and found out.

Sadly, there is no smoking gun..

So a couple of things that I would do is to ensure that the Xen
hypervisor boots with 'sync_console console_to_ring' and when this
crash happens see if I can get a stack trace from both the Xen
hypervisor (there are some debug parameters to get that - I think it is
'r'?), and also from the Linux kernel.

But also see if the problem disappears with the latest 4.1.x hypervisor.
And it might also be worth upgrading the dom0 to a 3.0. Hmm, it would be
very interesting to see where the dom0 _is_ stuck at. The hypervisor is
running fine so it all points to dom0 crashing somewhere..

Can you make sure that dom0 runs with 'debug loglevel=8' as well. That
should give some wealth of information when/if a crash happens.
Oh, and try to pass in Ctrl-Alt-SysRQ-t (on serial concentrators I think
you just need to type 'break' on the telnet line)and then t. But I am
not entirely sure about it - might want to double check Google and see
how to enable Alt-SysRQ.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 08 23:47:54 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 Dec 2011 23:47:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYngO-0002WN-5v; Thu, 08 Dec 2011 23:47:20 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.r.wilk@gmail.com>) id 1RYngL-0002WI-I9
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 23:47:17 +0000
X-Env-Sender: konrad.r.wilk@gmail.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1323387951!47139991!1
X-Originating-IP: [209.85.216.171]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26591 invoked from network); 8 Dec 2011 23:45:52 -0000
Received: from mail-qy0-f171.google.com (HELO mail-qy0-f171.google.com)
	(209.85.216.171)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Dec 2011 23:45:52 -0000
Received: by qcsc20 with SMTP id c20so18064714qcs.30
	for <xen-devel@lists.xensource.com>;
	Thu, 08 Dec 2011 15:46:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:date:from:to:cc:subject:message-id:references:mime-version
	:content-type:content-disposition:in-reply-to:user-agent;
	bh=vecwLqpacNAUKdXseqk/OEhmKvw0b/ajkMBALi4mOtk=;
	b=np8ar+VEiB8HBX2UfVhQNN4AlQEZ8vkt27byHXSmCdlcslzoNbYXV3I3ZaKu7fNcGS
	2NbBIdUKZ3qbnpxvsjUHAl/Rw8fDyaF0LDYox1izBURxLps6X4ngOVdFEbPWl59ik/7E
	JhtSaKHY365MKZsNBUblAs7rJuEneZqiSnu1I=
Received: by 10.229.24.139 with SMTP id v11mr1338592qcb.175.1323387988623;
	Thu, 08 Dec 2011 15:46:28 -0800 (PST)
Received: from konrad-lan (209-6-85-33.c3-0.smr-ubr2.sbo-smr.ma.cable.rcn.com.
	[209.6.85.33])
	by mx.google.com with ESMTPS id df3sm12793829qab.6.2011.12.08.15.46.27
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 08 Dec 2011 15:46:28 -0800 (PST)
Date: Thu, 8 Dec 2011 18:46:24 -0500
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Roderick Colenbrander <thunderbird2k@gmail.com>
Message-ID: <20111208234624.GD32474@konrad-lan>
References: <CAEc3jaBds7xmiKH8RMfmEHQumkEeZ3PopVfbZPs_B-Kz8-DsWw@mail.gmail.com>
	<4ED51291.1010308@hfp.de>
	<CAEc3jaAa7y8C2NNBn1=L3AhS0uuYFP6ze8o1cZ9yG2VYHx6qMA@mail.gmail.com>
	<4ED5215D.1010403@hfp.de>
	<20111129230212.GA23958@andromeda.dapyr.net>
	<CAEc3jaAO0JhtOt6phQHwtE_A+NF7uGHGZ8uJv3BirEYybfVceg@mail.gmail.com>
	<CAEc3jaACffpr9D1Hq_012vHAGhPLEfvsZjh7YyJ=Q-3FdtHS0Q@mail.gmail.com>
	<CAPbh3rtOQ1HTPReqYcpE3vzk+-na0MTLLHZD15=Fg4yxB+ypaA@mail.gmail.com>
	<CAEc3jaBdQKmVJToNZRf+25GtJXqGc274ieHf_yHKRJ+YOKWdgA@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAEc3jaBdQKmVJToNZRf+25GtJXqGc274ieHf_yHKRJ+YOKWdgA@mail.gmail.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: xen-devel@lists.xensource.com, Andreas Kinzler <ml-xen-devel@hfp.de>
Subject: Re: [Xen-devel] Questions about GPLPV stability tests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Dec 07, 2011 at 08:44:19PM +0000, Roderick Colenbrander wrote:
> On Wed, Dec 7, 2011 at 8:38 PM, Konrad Rzeszutek Wilk <konrad@darnok.org> wrote:
> >> It took about a week, but the systems went down again. Linux is down,
> >> but the hypervisor is still reachable on the serial console. Is there
> >> anything interesting to dump from there?
> >>
> > Just the interrupts information. I think that is Ctrl-A, Ctrl-A,
> > Ctrl-A, and then '*' to capture everything (I don't remember the right
> > one for just interrupts).
> 
> Here's the interrupt information:
> (XEN) [2011-12-06 19:13:37] [i: dump interrupt bindings]
> (XEN) [2011-12-06 19:13:37] Guest interrupt information:
> (XEN) [2011-12-06 19:13:37]    IRQ:   0
> affinity:00000000,00000000,00000000,00000001 vec:f0 type=IO-APIC-edge
>   status=00000000 mapped, unbound
> (XEN) [2011-12-06 19:13:37]    IRQ:   1
> affinity:00000000,00000000,00000000,00000001 vec:30 type=IO-APIC-edge
>   status=00000014 in-flight=0 domain-list=0:  1(-S--),
> (XEN) [2011-12-06 19:13:37]    IRQ:   2
> affinity:ffffffff,ffffffff,ffffffff,ffffffff vec:e2 type=XT-PIC
>   status=00000000 mapped, unbound
> (XEN) [2011-12-06 19:13:37]    IRQ:   3
> affinity:00000000,00000000,00000000,00000001 vec:38 type=IO-APIC-edge
>   status=00000006 mapped, unbound
> (XEN) [2011-12-06 19:13:37]    IRQ:   4
> affinity:00000000,00000000,00000000,00000001 vec:40 type=IO-APIC-edge
>   status=00000002 mapped, unbound
> (XEN) [2011-12-06 19:13:37]    IRQ:   5
> affinity:00000000,00000000,00000000,00000001 vec:f1 type=IO-APIC-edge
>   status=00000000 mapped, unbound
> (XEN) [2011-12-06 19:13:37]    IRQ:   6
> affinity:00000000,00000000,00000000,00000001 vec:48 type=IO-APIC-edge
>   status=00000002 mapped, unbound
> (XEN) [2011-12-06 19:13:37]    IRQ:   7
> affinity:00000000,00000000,00000000,00000001 vec:50 type=IO-APIC-edge
>   status=00000002 mapped, unbound
> (XEN) [2011-12-06 19:13:37]    IRQ:   8
> affinity:00000000,00000000,00000000,00000001 vec:58 type=IO-APIC-edge
>   status=00000010 in-flight=0 domain-list=0:  8(-S--),
> (XEN) [2011-12-06 19:13:37]    IRQ:   9
> affinity:00000000,00000000,00000000,00000001 vec:60 type=IO-APIC-level
>   status=00000010 in-flight=0 domain-list=0:  9(-S--),
> (XEN) [2011-12-06 19:13:37]    IRQ:  10
> affinity:00000000,00000000,00000000,00000001 vec:68 type=IO-APIC-edge
>   status=00000002 mapped, unbound
> (XEN) [2011-12-06 19:13:37]    IRQ:  11
> affinity:00000000,00000000,00000000,00000001 vec:70 type=IO-APIC-edge
>   status=00000002 mapped, unbound
> (XEN) [2011-12-06 19:13:37]    IRQ:  12
> affinity:00000000,00000000,00000000,00000001 vec:78 type=IO-APIC-edge
>   status=00000010 in-flight=0 domain-list=0: 12(-S--),
> (XEN) [2011-12-06 19:13:37]    IRQ:  13
> affinity:00000000,00000000,00000000,00000001 vec:88 type=IO-APIC-edge
>   status=00000002 mapped, unbound
> (XEN) [2011-12-06 19:13:37]    IRQ:  14
> affinity:00000000,00000000,00000000,00000001 vec:90 type=IO-APIC-edge
>   status=00000002 mapped, unbound
> (XEN) [2011-12-06 19:13:37]    IRQ:  15
> affinity:00000000,00000000,00000000,00000001 vec:98 type=IO-APIC-edge
>   status=00000002 mapped, unbound
> (XEN) [2011-12-06 19:13:37]    IRQ:  16
> affinity:00000000,00000000,00000000,00000001 vec:c8 type=IO-APIC-level
>   status=00000010 in-flight=0 domain-list=0: 16(-S--),1201: 16(--M-),
> (XEN) [2011-12-06 19:13:37]    IRQ:  18
> affinity:00000000,00000000,00000000,00000001 vec:51 type=IO-APIC-level
>   status=00000010 in-flight=0 domain-list=0: 18(-S--),
> (XEN) [2011-12-06 19:13:37]    IRQ:  19
> affinity:00000000,00000000,00000000,00000001 vec:d0 type=IO-APIC-level
>   status=00000010 in-flight=0 domain-list=0: 19(-S--),
> (XEN) [2011-12-06 19:13:37]    IRQ:  21
> affinity:00000000,00000000,00000000,00000001 vec:61 type=IO-APIC-level
>   status=00000010 in-flight=0 domain-list=0: 21(-S--),
> (XEN) [2011-12-06 19:13:37]    IRQ:  23
> affinity:00000000,00000000,00000000,00000001 vec:59 type=IO-APIC-level
>   status=00000010 in-flight=1 domain-list=0: 23(PS-M),
> (XEN) [2011-12-06 19:13:37]    IRQ:  24
> affinity:00000000,00000000,00000000,00000001 vec:28 type=DMA_MSI
>   status=00000000 mapped, unbound
> (XEN) [2011-12-06 19:13:38]    IRQ:  25
> affinity:00000000,00000000,00000000,00000001 vec:a0 type=PCI-MSI
>   status=00000002 mapped, unbound
> (XEN) [2011-12-06 19:13:38]    IRQ:  26
> affinity:00000000,00000000,00000000,00000001 vec:a8 type=PCI-MSI
>   status=00000002 mapped, unbound
> (XEN) [2011-12-06 19:13:38]    IRQ:  27
> affinity:00000000,00000000,00000000,00000001 vec:b0 type=PCI-MSI
>   status=00000002 mapped, unbound
> (XEN) [2011-12-06 19:13:38]    IRQ:  28
> affinity:00000000,00000000,00000000,00000001 vec:b8 type=PCI-MSI
>   status=00000002 mapped, unbound
> (XEN) [2011-12-06 19:13:38]    IRQ:  29
> affinity:00000000,00000000,00000000,00000001 vec:c0 type=PCI-MSI
>   status=00000002 mapped, unbound
> (XEN) [2011-12-06 19:13:38]    IRQ:  30
> affinity:00000000,00000000,00000000,00000001 vec:d8 type=PCI-MSI
>   status=00000014 in-flight=0 domain-list=0:274(PS--),
> (XEN) [2011-12-06 19:13:38]    IRQ:  31
> affinity:00000000,00000000,00000000,00000001 vec:21 type=PCI-MSI
>   status=00000010 in-flight=0 domain-list=0:273(PS--),
> (XEN) [2011-12-06 19:13:38]    IRQ:  32
> affinity:00000000,00000000,00000000,00000001 vec:29 type=PCI-MSI
>   status=00000010 in-flight=0 domain-list=0:272(PS--),
> (XEN) [2011-12-06 19:13:38]    IRQ:  33
> affinity:00000000,00000000,00000000,00000001 vec:31 type=PCI-MSI
>   status=00000010 in-flight=0 domain-list=0:271(PS--),
> (XEN) [2011-12-06 19:13:38]    IRQ:  34
> affinity:ffffffff,ffffffff,ffffffff,ffffffff vec:39 type=PCI-MSI
>   status=00000002 mapped, unbound
> (XEN) [2011-12-06 19:13:38]    IRQ:  35
> affinity:ffffffff,ffffffff,ffffffff,ffffffff vec:41 type=PCI-MSI
>   status=00000002 mapped, unbound
> (XEN) [2011-12-06 19:13:38]    IRQ:  36
> affinity:ffffffff,ffffffff,ffffffff,ffffffff vec:49 type=PCI-MSI
>   status=00000002 mapped, unbound
> (XEN) [2011-12-06 19:13:38]    IRQ:  37
> affinity:00000000,00000000,00000000,00000010 vec:65 type=PCI-MSI
>   status=00000010 in-flight=0 domain-list=1201: 55(--M-),
> (XEN) [2011-12-06 19:13:38] IO-APIC interrupt information:
> (XEN) [2011-12-06 19:13:38]     IRQ  0 Vec240:
> (XEN) [2011-12-06 19:13:38]       Apic 0x00, Pin  2: vector=240,
> delivery_mode=1, dest_mode=logical, delivery_status=0, polarity=0,
> irr=0, trigger=edge, mask=0, dest_id:1
> (XEN) [2011-12-06 19:13:38]     IRQ  1 Vec 48:
> (XEN) [2011-12-06 19:13:38]       Apic 0x00, Pin  1: vector=48,
> delivery_mode=1, dest_mode=logical, delivery_status=0, polarity=0,
> irr=0, trigger=edge, mask=0, dest_id:1
> (XEN) [2011-12-06 19:13:38]     IRQ  3 Vec 56:
> (XEN) [2011-12-06 19:13:38]       Apic 0x00, Pin  3: vector=56,
> delivery_mode=1, dest_mode=logical, delivery_status=0, polarity=0,
> irr=0, trigger=edge, mask=0, dest_id:1
> (XEN) [2011-12-06 19:13:38]     IRQ  4 Vec 64:
> (XEN) [2011-12-06 19:13:38]       Apic 0x00, Pin  4: vector=64,
> delivery_mode=1, dest_mode=logical, delivery_status=0, polarity=0,
> irr=0, trigger=edge, mask=0, dest_id:1
> (XEN) [2011-12-06 19:13:38]     IRQ  5 Vec241:
> (XEN) [2011-12-06 19:13:38]       Apic 0x00, Pin  5: vector=241,
> delivery_mode=1, dest_mode=logical, delivery_status=0, polarity=0,
> irr=0, trigger=edge, mask=0, dest_id:1
> (XEN) [2011-12-06 19:13:38]     IRQ  6 Vec 72:
> (XEN) [2011-12-06 19:13:38]       Apic 0x00, Pin  6: vector=72,
> delivery_mode=1, dest_mode=logical, delivery_status=0, polarity=0,
> irr=0, trigger=edge, mask=0, dest_id:1
> (XEN) [2011-12-06 19:13:38]     IRQ  7 Vec 80:
> (XEN) [2011-12-06 19:13:38]       Apic 0x00, Pin  7: vector=80,
> delivery_mode=1, dest_mode=logical, delivery_status=0, polarity=0,
> irr=0, trigger=edge, mask=0, dest_id:1
> (XEN) [2011-12-06 19:13:38]     IRQ  8 Vec 88:
> (XEN) [2011-12-06 19:13:38]       Apic 0x00, Pin  8: vector=88,
> delivery_mode=1, dest_mode=logical, delivery_status=0, polarity=0,
> irr=0, trigger=edge, mask=0, dest_id:1
> (XEN) [2011-12-06 19:13:38]     IRQ  9 Vec 96:
> (XEN) [2011-12-06 19:13:38]       Apic 0x00, Pin  9: vector=96,
> delivery_mode=1, dest_mode=logical, delivery_status=0, polarity=0,
> irr=0, trigger=level, mask=0, dest_id:1
> (XEN) [2011-12-06 19:13:38]     IRQ 10 Vec104:
> (XEN) [2011-12-06 19:13:38]       Apic 0x00, Pin 10: vector=104,
> delivery_mode=1, dest_mode=logical, delivery_status=0, polarity=0,
> irr=0, trigger=edge, mask=0, dest_id:1
> (XEN) [2011-12-06 19:13:38]     IRQ 11 Vec112:
> (XEN) [2011-12-06 19:13:38]       Apic 0x00, Pin 11: vector=112,
> delivery_mode=1, dest_mode=logical, delivery_status=0, polarity=0,
> irr=0, trigger=edge, mask=0, dest_id:1
> (XEN) [2011-12-06 19:13:38]     IRQ 12 Vec120:
> (XEN) [2011-12-06 19:13:38]       Apic 0x00, Pin 12: vector=120,
> delivery_mode=1, dest_mode=logical, delivery_status=0, polarity=0,
> irr=0, trigger=edge, mask=0, dest_id:1
> (XEN) [2011-12-06 19:13:38]     IRQ 13 Vec136:
> (XEN) [2011-12-06 19:13:38]       Apic 0x00, Pin 13: vector=136,
> delivery_mode=1, dest_mode=logical, delivery_status=0, polarity=0,
> irr=0, trigger=edge, mask=0, dest_id:1
> (XEN) [2011-12-06 19:13:38]     IRQ 14 Vec144:
> (XEN) [2011-12-06 19:13:38]       Apic 0x00, Pin 14: vector=144,
> delivery_mode=1, dest_mode=logical, delivery_status=0, polarity=0,
> irr=0, trigger=edge, mask=0, dest_id:1
> (XEN) [2011-12-06 19:13:38]     IRQ 15 Vec152:
> (XEN) [2011-12-06 19:13:38]       Apic 0x00, Pin 15: vector=152,
> delivery_mode=1, dest_mode=logical, delivery_status=0, polarity=0,
> irr=0, trigger=edge, mask=0, dest_id:1
> (XEN) [2011-12-06 19:13:38]     IRQ 16 Vec200:
> (XEN) [2011-12-06 19:13:38]       Apic 0x00, Pin 16: vector=200,
> delivery_mode=1, dest_mode=logical, delivery_status=0, polarity=1,
> irr=0, trigger=level, mask=0, dest_id:1
> (XEN) [2011-12-06 19:13:38]     IRQ 18 Vec 81:
> (XEN) [2011-12-06 19:13:38]       Apic 0x00, Pin 18: vector=81,
> delivery_mode=1, dest_mode=logical, delivery_status=0, polarity=1,
> irr=0, trigger=level, mask=0, dest_id:1
> (XEN) [2011-12-06 19:13:38]     IRQ 19 Vec208:
> (XEN) [2011-12-06 19:13:38]       Apic 0x00, Pin 19: vector=208,
> delivery_mode=1, dest_mode=logical, delivery_status=0, polarity=1,
> irr=0, trigger=level, mask=0, dest_id:1
> (XEN) [2011-12-06 19:13:38]     IRQ 21 Vec 97:
> (XEN) [2011-12-06 19:13:38]       Apic 0x00, Pin 21: vector=97,
> delivery_mode=1, dest_mode=logical, delivery_status=0, polarity=1,
> irr=0, trigger=level, mask=0, dest_id:1
> (XEN) [2011-12-06 19:13:38]     IRQ 23 Vec 89:
> (XEN) [2011-12-06 19:13:38]       Apic 0x00, Pin 23: vector=89,
> delivery_mode=1, dest_mode=logical, delivery_status=1, polarity=1,
> irr=1, trigger=level, mask=0, dest_id:1
> 
> I noticed some potential interesting things. The system in question is
> using PCI passthrough. On the serial console I remember seeing that
> the PCI device got unmapped from DomU and got mapped again in Dom0.
> The serial console log still had a lot of information about this DomU
> which I guess was going down. I guess it wasn't fully down yet.

One of the debug informations that gets printed with '*' is the guest
PCI passthrough data. Such as which IRQ, BAR, etc are mapped in. Did any
of those exist?

My original thought of what is going on is that the interrupts either
stopped completly working (does not look like - it looks like the
interrupts are firring and the event channels that are bound to it have
the bits set saying - hey I am pending). Oddly there are bunch of MSI
ones that are masked which usually means they are disabled.

Then there is the 
 affinity:00000000,00000000,00000000,00000001 vec:c8 type=IO-APIC-level
   status=00000010 in-flight=0 domain-list=0: 16(-S--),1201: 16(--M-),
 affinity:00000000,00000000,00000000,00000010 vec:65 type=PCI-MSI
   status=00000010 in-flight=0 domain-list=1201: 55(--M-),

The guest has masked both interrupts - so it is off//dying, but somehow
the unmapping has not happend. In other words, what you just analyzed
and found out.

Sadly, there is no smoking gun..

So a couple of things that I would do is to ensure that the Xen
hypervisor boots with 'sync_console console_to_ring' and when this
crash happens see if I can get a stack trace from both the Xen
hypervisor (there are some debug parameters to get that - I think it is
'r'?), and also from the Linux kernel.

But also see if the problem disappears with the latest 4.1.x hypervisor.
And it might also be worth upgrading the dom0 to a 3.0. Hmm, it would be
very interesting to see where the dom0 _is_ stuck at. The hypervisor is
running fine so it all points to dom0 crashing somewhere..

Can you make sure that dom0 runs with 'debug loglevel=8' as well. That
should give some wealth of information when/if a crash happens.
Oh, and try to pass in Ctrl-Alt-SysRQ-t (on serial concentrators I think
you just need to type 'break' on the telnet line)and then t. But I am
not entirely sure about it - might want to double check Google and see
how to enable Alt-SysRQ.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 01:31:04 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 01: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.xensource.com>)
	id 1RYpI8-00076g-4z; Fri, 09 Dec 2011 01:30:24 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RYpI6-00076G-Fl
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 01:30:22 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1323394168!6144227!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDg5NQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8331 invoked from network); 9 Dec 2011 01:29:29 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 01:29:29 -0000
X-IronPort-AV: E=Sophos;i="4.71,322,1320624000"; 
   d="scan'208";a="9374114"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 01:28:06 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 01:28:06 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RYpFu-0005R7-Hg;
	Fri, 09 Dec 2011 01:28:06 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RYpFu-0001Bl-H7;
	Fri, 09 Dec 2011 01:28:06 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10446-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 9 Dec 2011 01:28:06 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10446: regressions - trouble:
	broken/fail/pass
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10446 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10446/

Regressions :-(

Tests which did not succeed and are blocking:
 test-i386-i386-xl-winxpsp3    3 host-install(3)              broken
 test-amd64-i386-rhel6hvm-intel  3 host-install(3)              broken
 test-amd64-i386-xl-multivcpu  3 host-install(3)              broken
 test-amd64-amd64-xl-sedf      3 host-install(3)              broken
 test-amd64-amd64-xl-win       7 windows-install           fail REGR. vs. 10201
 test-amd64-i386-xl-win-vcpus1  7 windows-install          fail REGR. vs. 10201
 test-i386-i386-xl-win         7 windows-install           fail REGR. vs. 10201

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install          fail never pass
 test-amd64-i386-xl-win7-amd64  7 windows-install              fail  never pass
 test-amd64-i386-xend-winxpsp3  7 windows-install              fail  never pass
 test-amd64-amd64-xl-win7-amd64  7 windows-install              fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  1c58bb664d8d
baseline version:
 xen                  62ff6a318c5d

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scanneel.ca>
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Andres Lagar-Cavilla <andres@lagarcavilla>
  Andrew Cooper <andrew.cooper3@citrix.com>
  Anthony PERARD <anthony.perard@citrix.com>
  Brendan Cully <brendan@cs.ubc.ca>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Haitao Shan <haitao.shan@intel.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@novell.com>
  Jan Beulich <jbeulich@suse.com>
  Jonathan Davies <jonathan.davies@citrix.com>
  juergen.gross@ts.fujitsu.com
  Keir Fraser <keir@xen.org>
  Liu, Jinsong <jinsong.liu@intel.com>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
  Philipp Hahn <hahn@univention.de>
  Shriram Rajagopalan <rshriram@cs.ubc.ca>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang2 <wei.wang2@amd.com>
  Xudong Hao <xudong.hao@intel.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               broken  
 test-amd64-i386-xl-multivcpu                                 broken  
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     broken  
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   broken  


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 1522 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 01:31:04 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 01: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.xensource.com>)
	id 1RYpI8-00076g-4z; Fri, 09 Dec 2011 01:30:24 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RYpI6-00076G-Fl
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 01:30:22 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1323394168!6144227!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDg5NQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8331 invoked from network); 9 Dec 2011 01:29:29 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 01:29:29 -0000
X-IronPort-AV: E=Sophos;i="4.71,322,1320624000"; 
   d="scan'208";a="9374114"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 01:28:06 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 01:28:06 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RYpFu-0005R7-Hg;
	Fri, 09 Dec 2011 01:28:06 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RYpFu-0001Bl-H7;
	Fri, 09 Dec 2011 01:28:06 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10446-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 9 Dec 2011 01:28:06 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10446: regressions - trouble:
	broken/fail/pass
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10446 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10446/

Regressions :-(

Tests which did not succeed and are blocking:
 test-i386-i386-xl-winxpsp3    3 host-install(3)              broken
 test-amd64-i386-rhel6hvm-intel  3 host-install(3)              broken
 test-amd64-i386-xl-multivcpu  3 host-install(3)              broken
 test-amd64-amd64-xl-sedf      3 host-install(3)              broken
 test-amd64-amd64-xl-win       7 windows-install           fail REGR. vs. 10201
 test-amd64-i386-xl-win-vcpus1  7 windows-install          fail REGR. vs. 10201
 test-i386-i386-xl-win         7 windows-install           fail REGR. vs. 10201

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install          fail never pass
 test-amd64-i386-xl-win7-amd64  7 windows-install              fail  never pass
 test-amd64-i386-xend-winxpsp3  7 windows-install              fail  never pass
 test-amd64-amd64-xl-win7-amd64  7 windows-install              fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  1c58bb664d8d
baseline version:
 xen                  62ff6a318c5d

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scanneel.ca>
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Andres Lagar-Cavilla <andres@lagarcavilla>
  Andrew Cooper <andrew.cooper3@citrix.com>
  Anthony PERARD <anthony.perard@citrix.com>
  Brendan Cully <brendan@cs.ubc.ca>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Haitao Shan <haitao.shan@intel.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@novell.com>
  Jan Beulich <jbeulich@suse.com>
  Jonathan Davies <jonathan.davies@citrix.com>
  juergen.gross@ts.fujitsu.com
  Keir Fraser <keir@xen.org>
  Liu, Jinsong <jinsong.liu@intel.com>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
  Philipp Hahn <hahn@univention.de>
  Shriram Rajagopalan <rshriram@cs.ubc.ca>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang2 <wei.wang2@amd.com>
  Xudong Hao <xudong.hao@intel.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               broken  
 test-amd64-i386-xl-multivcpu                                 broken  
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     broken  
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   broken  


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 1522 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 01:35:20 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 01:35:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYpMN-0007GT-5V; Fri, 09 Dec 2011 01:34:47 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <thunderbird2k@gmail.com>) id 1RYpML-0007GB-8m
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 01:34:45 +0000
X-Env-Sender: thunderbird2k@gmail.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1323394433!7492263!1
X-Originating-IP: [209.85.213.171]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9469 invoked from network); 9 Dec 2011 01:33:55 -0000
Received: from mail-yx0-f171.google.com (HELO mail-yx0-f171.google.com)
	(209.85.213.171)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 01:33:55 -0000
Received: by yenr9 with SMTP id r9so34879153yen.30
	for <xen-devel@lists.xensource.com>;
	Thu, 08 Dec 2011 17:33:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	bh=OEkBL7cA1Gbf3vGFXWTlxjF8gcFcwJOEYiRMnStgu6Q=;
	b=OIRocSyCFbm+pL3T3w2Q0oMlitoDLypyaMUQg+jJkFDzEv/WFldIqTypwOenhbp9en
	yFZT7RVNOk5R+8QemUv0Ydw89p47ZkutSLU50EdMXGyBn64aEw2O84FxzinmV7kpC0eR
	BeLbQ0C7+Z2uT3GV5GktjAHV3JaL2FBV/xzHU=
MIME-Version: 1.0
Received: by 10.236.181.164 with SMTP id l24mr8858068yhm.22.1323394433555;
	Thu, 08 Dec 2011 17:33:53 -0800 (PST)
Received: by 10.100.48.10 with HTTP; Thu, 8 Dec 2011 17:33:53 -0800 (PST)
In-Reply-To: <20111208234624.GD32474@konrad-lan>
References: <CAEc3jaBds7xmiKH8RMfmEHQumkEeZ3PopVfbZPs_B-Kz8-DsWw@mail.gmail.com>
	<4ED51291.1010308@hfp.de>
	<CAEc3jaAa7y8C2NNBn1=L3AhS0uuYFP6ze8o1cZ9yG2VYHx6qMA@mail.gmail.com>
	<4ED5215D.1010403@hfp.de>
	<20111129230212.GA23958@andromeda.dapyr.net>
	<CAEc3jaAO0JhtOt6phQHwtE_A+NF7uGHGZ8uJv3BirEYybfVceg@mail.gmail.com>
	<CAEc3jaACffpr9D1Hq_012vHAGhPLEfvsZjh7YyJ=Q-3FdtHS0Q@mail.gmail.com>
	<CAPbh3rtOQ1HTPReqYcpE3vzk+-na0MTLLHZD15=Fg4yxB+ypaA@mail.gmail.com>
	<CAEc3jaBdQKmVJToNZRf+25GtJXqGc274ieHf_yHKRJ+YOKWdgA@mail.gmail.com>
	<20111208234624.GD32474@konrad-lan>
Date: Fri, 9 Dec 2011 01:33:53 +0000
Message-ID: <CAEc3jaC9=HiMoxSYZmXKRzoFcMYRaT9jrX3m1ZQO+M8CrH35Fg@mail.gmail.com>
From: Roderick Colenbrander <thunderbird2k@gmail.com>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
Cc: xen-devel@lists.xensource.com, Andreas Kinzler <ml-xen-devel@hfp.de>
Subject: Re: [Xen-devel] Questions about GPLPV stability tests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Dec 8, 2011 at 11:46 PM, Konrad Rzeszutek Wilk
<konrad@darnok.org> wrote:
> On Wed, Dec 07, 2011 at 08:44:19PM +0000, Roderick Colenbrander wrote:
>> On Wed, Dec 7, 2011 at 8:38 PM, Konrad Rzeszutek Wilk <konrad@darnok.org=
> wrote:
>> >> It took about a week, but the systems went down again. Linux is down,
>> >> but the hypervisor is still reachable on the serial console. Is there
>> >> anything interesting to dump from there?
>> >>
>> > Just the interrupts information. I think that is Ctrl-A, Ctrl-A,
>> > Ctrl-A, and then '*' to capture everything (I don't remember the right
>> > one for just interrupts).
>>
>> Here's the interrupt information:
>> (XEN) [2011-12-06 19:13:37] [i: dump interrupt bindings]
>> (XEN) [2011-12-06 19:13:37] Guest interrupt information:
>> (XEN) [2011-12-06 19:13:37] =A0 =A0IRQ: =A0 0
>> affinity:00000000,00000000,00000000,00000001 vec:f0 type=3DIO-APIC-edge
>> =A0 status=3D00000000 mapped, unbound
>> (XEN) [2011-12-06 19:13:37] =A0 =A0IRQ: =A0 1
>> affinity:00000000,00000000,00000000,00000001 vec:30 type=3DIO-APIC-edge
>> =A0 status=3D00000014 in-flight=3D0 domain-list=3D0: =A01(-S--),
>> (XEN) [2011-12-06 19:13:37] =A0 =A0IRQ: =A0 2
>> affinity:ffffffff,ffffffff,ffffffff,ffffffff vec:e2 type=3DXT-PIC
>> =A0 status=3D00000000 mapped, unbound
>> (XEN) [2011-12-06 19:13:37] =A0 =A0IRQ: =A0 3
>> affinity:00000000,00000000,00000000,00000001 vec:38 type=3DIO-APIC-edge
>> =A0 status=3D00000006 mapped, unbound
>> (XEN) [2011-12-06 19:13:37] =A0 =A0IRQ: =A0 4
>> affinity:00000000,00000000,00000000,00000001 vec:40 type=3DIO-APIC-edge
>> =A0 status=3D00000002 mapped, unbound
>> (XEN) [2011-12-06 19:13:37] =A0 =A0IRQ: =A0 5
>> affinity:00000000,00000000,00000000,00000001 vec:f1 type=3DIO-APIC-edge
>> =A0 status=3D00000000 mapped, unbound
>> (XEN) [2011-12-06 19:13:37] =A0 =A0IRQ: =A0 6
>> affinity:00000000,00000000,00000000,00000001 vec:48 type=3DIO-APIC-edge
>> =A0 status=3D00000002 mapped, unbound
>> (XEN) [2011-12-06 19:13:37] =A0 =A0IRQ: =A0 7
>> affinity:00000000,00000000,00000000,00000001 vec:50 type=3DIO-APIC-edge
>> =A0 status=3D00000002 mapped, unbound
>> (XEN) [2011-12-06 19:13:37] =A0 =A0IRQ: =A0 8
>> affinity:00000000,00000000,00000000,00000001 vec:58 type=3DIO-APIC-edge
>> =A0 status=3D00000010 in-flight=3D0 domain-list=3D0: =A08(-S--),
>> (XEN) [2011-12-06 19:13:37] =A0 =A0IRQ: =A0 9
>> affinity:00000000,00000000,00000000,00000001 vec:60 type=3DIO-APIC-level
>> =A0 status=3D00000010 in-flight=3D0 domain-list=3D0: =A09(-S--),
>> (XEN) [2011-12-06 19:13:37] =A0 =A0IRQ: =A010
>> affinity:00000000,00000000,00000000,00000001 vec:68 type=3DIO-APIC-edge
>> =A0 status=3D00000002 mapped, unbound
>> (XEN) [2011-12-06 19:13:37] =A0 =A0IRQ: =A011
>> affinity:00000000,00000000,00000000,00000001 vec:70 type=3DIO-APIC-edge
>> =A0 status=3D00000002 mapped, unbound
>> (XEN) [2011-12-06 19:13:37] =A0 =A0IRQ: =A012
>> affinity:00000000,00000000,00000000,00000001 vec:78 type=3DIO-APIC-edge
>> =A0 status=3D00000010 in-flight=3D0 domain-list=3D0: 12(-S--),
>> (XEN) [2011-12-06 19:13:37] =A0 =A0IRQ: =A013
>> affinity:00000000,00000000,00000000,00000001 vec:88 type=3DIO-APIC-edge
>> =A0 status=3D00000002 mapped, unbound
>> (XEN) [2011-12-06 19:13:37] =A0 =A0IRQ: =A014
>> affinity:00000000,00000000,00000000,00000001 vec:90 type=3DIO-APIC-edge
>> =A0 status=3D00000002 mapped, unbound
>> (XEN) [2011-12-06 19:13:37] =A0 =A0IRQ: =A015
>> affinity:00000000,00000000,00000000,00000001 vec:98 type=3DIO-APIC-edge
>> =A0 status=3D00000002 mapped, unbound
>> (XEN) [2011-12-06 19:13:37] =A0 =A0IRQ: =A016
>> affinity:00000000,00000000,00000000,00000001 vec:c8 type=3DIO-APIC-level
>> =A0 status=3D00000010 in-flight=3D0 domain-list=3D0: 16(-S--),1201: 16(-=
-M-),
>> (XEN) [2011-12-06 19:13:37] =A0 =A0IRQ: =A018
>> affinity:00000000,00000000,00000000,00000001 vec:51 type=3DIO-APIC-level
>> =A0 status=3D00000010 in-flight=3D0 domain-list=3D0: 18(-S--),
>> (XEN) [2011-12-06 19:13:37] =A0 =A0IRQ: =A019
>> affinity:00000000,00000000,00000000,00000001 vec:d0 type=3DIO-APIC-level
>> =A0 status=3D00000010 in-flight=3D0 domain-list=3D0: 19(-S--),
>> (XEN) [2011-12-06 19:13:37] =A0 =A0IRQ: =A021
>> affinity:00000000,00000000,00000000,00000001 vec:61 type=3DIO-APIC-level
>> =A0 status=3D00000010 in-flight=3D0 domain-list=3D0: 21(-S--),
>> (XEN) [2011-12-06 19:13:37] =A0 =A0IRQ: =A023
>> affinity:00000000,00000000,00000000,00000001 vec:59 type=3DIO-APIC-level
>> =A0 status=3D00000010 in-flight=3D1 domain-list=3D0: 23(PS-M),
>> (XEN) [2011-12-06 19:13:37] =A0 =A0IRQ: =A024
>> affinity:00000000,00000000,00000000,00000001 vec:28 type=3DDMA_MSI
>> =A0 status=3D00000000 mapped, unbound
>> (XEN) [2011-12-06 19:13:38] =A0 =A0IRQ: =A025
>> affinity:00000000,00000000,00000000,00000001 vec:a0 type=3DPCI-MSI
>> =A0 status=3D00000002 mapped, unbound
>> (XEN) [2011-12-06 19:13:38] =A0 =A0IRQ: =A026
>> affinity:00000000,00000000,00000000,00000001 vec:a8 type=3DPCI-MSI
>> =A0 status=3D00000002 mapped, unbound
>> (XEN) [2011-12-06 19:13:38] =A0 =A0IRQ: =A027
>> affinity:00000000,00000000,00000000,00000001 vec:b0 type=3DPCI-MSI
>> =A0 status=3D00000002 mapped, unbound
>> (XEN) [2011-12-06 19:13:38] =A0 =A0IRQ: =A028
>> affinity:00000000,00000000,00000000,00000001 vec:b8 type=3DPCI-MSI
>> =A0 status=3D00000002 mapped, unbound
>> (XEN) [2011-12-06 19:13:38] =A0 =A0IRQ: =A029
>> affinity:00000000,00000000,00000000,00000001 vec:c0 type=3DPCI-MSI
>> =A0 status=3D00000002 mapped, unbound
>> (XEN) [2011-12-06 19:13:38] =A0 =A0IRQ: =A030
>> affinity:00000000,00000000,00000000,00000001 vec:d8 type=3DPCI-MSI
>> =A0 status=3D00000014 in-flight=3D0 domain-list=3D0:274(PS--),
>> (XEN) [2011-12-06 19:13:38] =A0 =A0IRQ: =A031
>> affinity:00000000,00000000,00000000,00000001 vec:21 type=3DPCI-MSI
>> =A0 status=3D00000010 in-flight=3D0 domain-list=3D0:273(PS--),
>> (XEN) [2011-12-06 19:13:38] =A0 =A0IRQ: =A032
>> affinity:00000000,00000000,00000000,00000001 vec:29 type=3DPCI-MSI
>> =A0 status=3D00000010 in-flight=3D0 domain-list=3D0:272(PS--),
>> (XEN) [2011-12-06 19:13:38] =A0 =A0IRQ: =A033
>> affinity:00000000,00000000,00000000,00000001 vec:31 type=3DPCI-MSI
>> =A0 status=3D00000010 in-flight=3D0 domain-list=3D0:271(PS--),
>> (XEN) [2011-12-06 19:13:38] =A0 =A0IRQ: =A034
>> affinity:ffffffff,ffffffff,ffffffff,ffffffff vec:39 type=3DPCI-MSI
>> =A0 status=3D00000002 mapped, unbound
>> (XEN) [2011-12-06 19:13:38] =A0 =A0IRQ: =A035
>> affinity:ffffffff,ffffffff,ffffffff,ffffffff vec:41 type=3DPCI-MSI
>> =A0 status=3D00000002 mapped, unbound
>> (XEN) [2011-12-06 19:13:38] =A0 =A0IRQ: =A036
>> affinity:ffffffff,ffffffff,ffffffff,ffffffff vec:49 type=3DPCI-MSI
>> =A0 status=3D00000002 mapped, unbound
>> (XEN) [2011-12-06 19:13:38] =A0 =A0IRQ: =A037
>> affinity:00000000,00000000,00000000,00000010 vec:65 type=3DPCI-MSI
>> =A0 status=3D00000010 in-flight=3D0 domain-list=3D1201: 55(--M-),
>> (XEN) [2011-12-06 19:13:38] IO-APIC interrupt information:
>> (XEN) [2011-12-06 19:13:38] =A0 =A0 IRQ =A00 Vec240:
>> (XEN) [2011-12-06 19:13:38] =A0 =A0 =A0 Apic 0x00, Pin =A02: vector=3D24=
0,
>> delivery_mode=3D1, dest_mode=3Dlogical, delivery_status=3D0, polarity=3D=
0,
>> irr=3D0, trigger=3Dedge, mask=3D0, dest_id:1
>> (XEN) [2011-12-06 19:13:38] =A0 =A0 IRQ =A01 Vec 48:
>> (XEN) [2011-12-06 19:13:38] =A0 =A0 =A0 Apic 0x00, Pin =A01: vector=3D48,
>> delivery_mode=3D1, dest_mode=3Dlogical, delivery_status=3D0, polarity=3D=
0,
>> irr=3D0, trigger=3Dedge, mask=3D0, dest_id:1
>> (XEN) [2011-12-06 19:13:38] =A0 =A0 IRQ =A03 Vec 56:
>> (XEN) [2011-12-06 19:13:38] =A0 =A0 =A0 Apic 0x00, Pin =A03: vector=3D56,
>> delivery_mode=3D1, dest_mode=3Dlogical, delivery_status=3D0, polarity=3D=
0,
>> irr=3D0, trigger=3Dedge, mask=3D0, dest_id:1
>> (XEN) [2011-12-06 19:13:38] =A0 =A0 IRQ =A04 Vec 64:
>> (XEN) [2011-12-06 19:13:38] =A0 =A0 =A0 Apic 0x00, Pin =A04: vector=3D64,
>> delivery_mode=3D1, dest_mode=3Dlogical, delivery_status=3D0, polarity=3D=
0,
>> irr=3D0, trigger=3Dedge, mask=3D0, dest_id:1
>> (XEN) [2011-12-06 19:13:38] =A0 =A0 IRQ =A05 Vec241:
>> (XEN) [2011-12-06 19:13:38] =A0 =A0 =A0 Apic 0x00, Pin =A05: vector=3D24=
1,
>> delivery_mode=3D1, dest_mode=3Dlogical, delivery_status=3D0, polarity=3D=
0,
>> irr=3D0, trigger=3Dedge, mask=3D0, dest_id:1
>> (XEN) [2011-12-06 19:13:38] =A0 =A0 IRQ =A06 Vec 72:
>> (XEN) [2011-12-06 19:13:38] =A0 =A0 =A0 Apic 0x00, Pin =A06: vector=3D72,
>> delivery_mode=3D1, dest_mode=3Dlogical, delivery_status=3D0, polarity=3D=
0,
>> irr=3D0, trigger=3Dedge, mask=3D0, dest_id:1
>> (XEN) [2011-12-06 19:13:38] =A0 =A0 IRQ =A07 Vec 80:
>> (XEN) [2011-12-06 19:13:38] =A0 =A0 =A0 Apic 0x00, Pin =A07: vector=3D80,
>> delivery_mode=3D1, dest_mode=3Dlogical, delivery_status=3D0, polarity=3D=
0,
>> irr=3D0, trigger=3Dedge, mask=3D0, dest_id:1
>> (XEN) [2011-12-06 19:13:38] =A0 =A0 IRQ =A08 Vec 88:
>> (XEN) [2011-12-06 19:13:38] =A0 =A0 =A0 Apic 0x00, Pin =A08: vector=3D88,
>> delivery_mode=3D1, dest_mode=3Dlogical, delivery_status=3D0, polarity=3D=
0,
>> irr=3D0, trigger=3Dedge, mask=3D0, dest_id:1
>> (XEN) [2011-12-06 19:13:38] =A0 =A0 IRQ =A09 Vec 96:
>> (XEN) [2011-12-06 19:13:38] =A0 =A0 =A0 Apic 0x00, Pin =A09: vector=3D96,
>> delivery_mode=3D1, dest_mode=3Dlogical, delivery_status=3D0, polarity=3D=
0,
>> irr=3D0, trigger=3Dlevel, mask=3D0, dest_id:1
>> (XEN) [2011-12-06 19:13:38] =A0 =A0 IRQ 10 Vec104:
>> (XEN) [2011-12-06 19:13:38] =A0 =A0 =A0 Apic 0x00, Pin 10: vector=3D104,
>> delivery_mode=3D1, dest_mode=3Dlogical, delivery_status=3D0, polarity=3D=
0,
>> irr=3D0, trigger=3Dedge, mask=3D0, dest_id:1
>> (XEN) [2011-12-06 19:13:38] =A0 =A0 IRQ 11 Vec112:
>> (XEN) [2011-12-06 19:13:38] =A0 =A0 =A0 Apic 0x00, Pin 11: vector=3D112,
>> delivery_mode=3D1, dest_mode=3Dlogical, delivery_status=3D0, polarity=3D=
0,
>> irr=3D0, trigger=3Dedge, mask=3D0, dest_id:1
>> (XEN) [2011-12-06 19:13:38] =A0 =A0 IRQ 12 Vec120:
>> (XEN) [2011-12-06 19:13:38] =A0 =A0 =A0 Apic 0x00, Pin 12: vector=3D120,
>> delivery_mode=3D1, dest_mode=3Dlogical, delivery_status=3D0, polarity=3D=
0,
>> irr=3D0, trigger=3Dedge, mask=3D0, dest_id:1
>> (XEN) [2011-12-06 19:13:38] =A0 =A0 IRQ 13 Vec136:
>> (XEN) [2011-12-06 19:13:38] =A0 =A0 =A0 Apic 0x00, Pin 13: vector=3D136,
>> delivery_mode=3D1, dest_mode=3Dlogical, delivery_status=3D0, polarity=3D=
0,
>> irr=3D0, trigger=3Dedge, mask=3D0, dest_id:1
>> (XEN) [2011-12-06 19:13:38] =A0 =A0 IRQ 14 Vec144:
>> (XEN) [2011-12-06 19:13:38] =A0 =A0 =A0 Apic 0x00, Pin 14: vector=3D144,
>> delivery_mode=3D1, dest_mode=3Dlogical, delivery_status=3D0, polarity=3D=
0,
>> irr=3D0, trigger=3Dedge, mask=3D0, dest_id:1
>> (XEN) [2011-12-06 19:13:38] =A0 =A0 IRQ 15 Vec152:
>> (XEN) [2011-12-06 19:13:38] =A0 =A0 =A0 Apic 0x00, Pin 15: vector=3D152,
>> delivery_mode=3D1, dest_mode=3Dlogical, delivery_status=3D0, polarity=3D=
0,
>> irr=3D0, trigger=3Dedge, mask=3D0, dest_id:1
>> (XEN) [2011-12-06 19:13:38] =A0 =A0 IRQ 16 Vec200:
>> (XEN) [2011-12-06 19:13:38] =A0 =A0 =A0 Apic 0x00, Pin 16: vector=3D200,
>> delivery_mode=3D1, dest_mode=3Dlogical, delivery_status=3D0, polarity=3D=
1,
>> irr=3D0, trigger=3Dlevel, mask=3D0, dest_id:1
>> (XEN) [2011-12-06 19:13:38] =A0 =A0 IRQ 18 Vec 81:
>> (XEN) [2011-12-06 19:13:38] =A0 =A0 =A0 Apic 0x00, Pin 18: vector=3D81,
>> delivery_mode=3D1, dest_mode=3Dlogical, delivery_status=3D0, polarity=3D=
1,
>> irr=3D0, trigger=3Dlevel, mask=3D0, dest_id:1
>> (XEN) [2011-12-06 19:13:38] =A0 =A0 IRQ 19 Vec208:
>> (XEN) [2011-12-06 19:13:38] =A0 =A0 =A0 Apic 0x00, Pin 19: vector=3D208,
>> delivery_mode=3D1, dest_mode=3Dlogical, delivery_status=3D0, polarity=3D=
1,
>> irr=3D0, trigger=3Dlevel, mask=3D0, dest_id:1
>> (XEN) [2011-12-06 19:13:38] =A0 =A0 IRQ 21 Vec 97:
>> (XEN) [2011-12-06 19:13:38] =A0 =A0 =A0 Apic 0x00, Pin 21: vector=3D97,
>> delivery_mode=3D1, dest_mode=3Dlogical, delivery_status=3D0, polarity=3D=
1,
>> irr=3D0, trigger=3Dlevel, mask=3D0, dest_id:1
>> (XEN) [2011-12-06 19:13:38] =A0 =A0 IRQ 23 Vec 89:
>> (XEN) [2011-12-06 19:13:38] =A0 =A0 =A0 Apic 0x00, Pin 23: vector=3D89,
>> delivery_mode=3D1, dest_mode=3Dlogical, delivery_status=3D1, polarity=3D=
1,
>> irr=3D1, trigger=3Dlevel, mask=3D0, dest_id:1
>>
>> I noticed some potential interesting things. The system in question is
>> using PCI passthrough. On the serial console I remember seeing that
>> the PCI device got unmapped from DomU and got mapped again in Dom0.
>> The serial console log still had a lot of information about this DomU
>> which I guess was going down. I guess it wasn't fully down yet.
>
> One of the debug informations that gets printed with '*' is the guest
> PCI passthrough data. Such as which IRQ, BAR, etc are mapped in. Did any
> of those exist?

There is not much PCI related information. Just interrupt stuff, no
PCI BARs or other interesting PCI stuff:
(XEN) [2011-12-06 19:13:20] 03:00.0 - dom 1201 - MSIs < 37 >
(XEN) [2011-12-06 19:13:20]  MSI    37 vec=3D65 lowest  edge   assert
log lowest dest=3D00000010 mask=3D0/0/-1


> My original thought of what is going on is that the interrupts either
> stopped completly working (does not look like - it looks like the
> interrupts are firring and the event channels that are bound to it have
> the bits set saying - hey I am pending). Oddly there are bunch of MSI
> ones that are masked which usually means they are disabled.
>
> Then there is the
> =A0affinity:00000000,00000000,00000000,00000001 vec:c8 type=3DIO-APIC-lev=
el
> =A0 status=3D00000010 in-flight=3D0 domain-list=3D0: 16(-S--),1201: 16(--=
M-),
> =A0affinity:00000000,00000000,00000000,00000010 vec:65 type=3DPCI-MSI
> =A0 status=3D00000010 in-flight=3D0 domain-list=3D1201: 55(--M-),
>
> The guest has masked both interrupts - so it is off//dying, but somehow
> the unmapping has not happend. In other words, what you just analyzed
> and found out.
>
> Sadly, there is no smoking gun..
>
> So a couple of things that I would do is to ensure that the Xen
> hypervisor boots with 'sync_console console_to_ring' and when this
> crash happens see if I can get a stack trace from both the Xen
> hypervisor (there are some debug parameters to get that - I think it is
> 'r'?), and also from the Linux kernel.

I set up some new tests, so that will take some days to get a crash.
For what it is worth, I do have a '*' log left from this system and it
has some stack trace. If you think it is useful, I could send it
gzipped, but I don't want to spam this list if it may not be useful.

One thing I did notice was the following:
(XEN) [2011-12-06 19:13:39] active vcpus:
(XEN) [2011-12-06 19:13:39]       1: [1201.2] pri=3D-2 flags=3D0 cpu=3D6
credit=3D-2411 [w=3D256]
(XEN) [2011-12-06 19:13:39]       2: [1201.1] pri=3D-2 flags=3D0 cpu=3D5
credit=3D-2460 [w=3D256]
(XEN) [2011-12-06 19:13:39]       3: [0.2] pri=3D0 flags=3D0 cpu=3D2
credit=3D142 [w=3D256]
(XEN) [2011-12-06 19:13:39]       4: [0.1] pri=3D-2 flags=3D0 cpu=3D1
credit=3D-2612 [w=3D256]
(XEN) [2011-12-06 19:13:39] CPU[00]  sort=3D12511062,
sibling=3D00000000,00000000,00000000,00000003,
core=3D00000000,00000000,00000000,000000ff
(XEN) [2011-12-06 19:13:39]     run: [32767.0] pri=3D0 flags=3D0 cpu=3D0
(XEN) [2011-12-06 19:13:39]       1: [0.0] pri=3D-1 flags=3D0 cpu=3D0
credit=3D333 [w=3D256]
(XEN) [2011-12-06 19:13:39] CPU[01]  sort=3D12511063,
sibling=3D00000000,00000000,00000000,00000003,
core=3D00000000,00000000,00000000,000000ff
(XEN) [2011-12-06 19:13:39]     run: [0.1] pri=3D-2 flags=3D0 cpu=3D1
credit=3D-2914 [w=3D256]
(XEN) [2011-12-06 19:13:39]       1: [32767.1] pri=3D-64 flags=3D0 cpu=3D1
(XEN) [2011-12-06 19:13:39] CPU[02]  sort=3D12511063,
sibling=3D00000000,00000000,00000000,0000000c,
core=3D00000000,00000000,00000000,000000ff
(XEN) [2011-12-06 19:13:39]     run: [32767.2] pri=3D-64 flags=3D0 cpu=3D2
(XEN) [2011-12-06 19:13:39] CPU[03]  sort=3D12511063,
sibling=3D00000000,00000000,00000000,0000000c,
core=3D00000000,00000000,00000000,000000ff
(XEN) [2011-12-06 19:13:39]     run: [32767.3] pri=3D-64 flags=3D0 cpu=3D3
(XEN) [2011-12-06 19:13:39] CPU[04]  sort=3D12511063,
sibling=3D00000000,00000000,00000000,00000030,
core=3D00000000,00000000,00000000,000000ff
(XEN) [2011-12-06 19:13:39]     run: [32767.4] pri=3D-64 flags=3D0 cpu=3D4
(XEN) [2011-12-06 19:13:39] CPU[05]  sort=3D12511063,
sibling=3D00000000,00000000,00000000,00000030,
core=3D00000000,00000000,00000000,000000ff
(XEN) [2011-12-06 19:13:39]     run: [1201.1] pri=3D-2 flags=3D0 cpu=3D5
credit=3D-3617 [w=3D256]
(XEN) [2011-12-06 19:13:39]       1: [32767.5] pri=3D-64 flags=3D0 cpu=3D5
(XEN) [2011-12-06 19:13:39] CPU[06]  sort=3D12511063,
sibling=3D00000000,00000000,00000000,000000c0,
core=3D00000000,00000000,00000000,000000ff
(XEN) [2011-12-06 19:13:39]     run: [1201.2] pri=3D-2 flags=3D0 cpu=3D6
credit=3D-3918 [w=3D256]
(XEN) [2011-12-06 19:13:39]       1: [32767.6] pri=3D-64 flags=3D0 cpu=3D6
(XEN) [2011-12-06 19:13:39] CPU[07]  sort=3D12511063,
sibling=3D00000000,00000000,00000000,000000c0,
core=3D00000000,00000000,00000000,000000ff
(XEN) [2011-12-06 19:13:39]     run: [32767.7] pri=3D-64 flags=3D0 cpu=3D7

The system in question has a 4-core i7 CPU where Dom0 is pinned to
core 0-3 and DomU is pinned 4-7. Aren't the negative credit numbers
quite big?

>
> But also see if the problem disappears with the latest 4.1.x hypervisor.
> And it might also be worth upgrading the dom0 to a 3.0. Hmm, it would be
> very interesting to see where the dom0 _is_ stuck at. The hypervisor is
> running fine so it all points to dom0 crashing somewhere..
>
> Can you make sure that dom0 runs with 'debug loglevel=3D8' as well. That
> should give some wealth of information when/if a crash happens.
> Oh, and try to pass in Ctrl-Alt-SysRQ-t (on serial concentrators I think
> you just need to type 'break' on the telnet line)and then t. But I am
> not entirely sure about it - might want to double check Google and see
> how to enable Alt-SysRQ.

I tried to get SysRq working. It worked fine on some of my other
machines (sysrq=3D 'shift-control-o'), but not on this broken box.
Apparently the kernel is stuck in some place where SysRq doesn't work.

I'm going to retest with the relevant logging turned on. I also
upgraded to the latest 2.6.32 kernel (.48 I think). I will also
upgrade to the latest 4.1.x build from the mercurial repository. It
will take a few days before I get crash.

Thanks so far!
Roderick

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 01:35:20 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 01:35:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYpMN-0007GT-5V; Fri, 09 Dec 2011 01:34:47 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <thunderbird2k@gmail.com>) id 1RYpML-0007GB-8m
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 01:34:45 +0000
X-Env-Sender: thunderbird2k@gmail.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1323394433!7492263!1
X-Originating-IP: [209.85.213.171]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9469 invoked from network); 9 Dec 2011 01:33:55 -0000
Received: from mail-yx0-f171.google.com (HELO mail-yx0-f171.google.com)
	(209.85.213.171)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 01:33:55 -0000
Received: by yenr9 with SMTP id r9so34879153yen.30
	for <xen-devel@lists.xensource.com>;
	Thu, 08 Dec 2011 17:33:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	bh=OEkBL7cA1Gbf3vGFXWTlxjF8gcFcwJOEYiRMnStgu6Q=;
	b=OIRocSyCFbm+pL3T3w2Q0oMlitoDLypyaMUQg+jJkFDzEv/WFldIqTypwOenhbp9en
	yFZT7RVNOk5R+8QemUv0Ydw89p47ZkutSLU50EdMXGyBn64aEw2O84FxzinmV7kpC0eR
	BeLbQ0C7+Z2uT3GV5GktjAHV3JaL2FBV/xzHU=
MIME-Version: 1.0
Received: by 10.236.181.164 with SMTP id l24mr8858068yhm.22.1323394433555;
	Thu, 08 Dec 2011 17:33:53 -0800 (PST)
Received: by 10.100.48.10 with HTTP; Thu, 8 Dec 2011 17:33:53 -0800 (PST)
In-Reply-To: <20111208234624.GD32474@konrad-lan>
References: <CAEc3jaBds7xmiKH8RMfmEHQumkEeZ3PopVfbZPs_B-Kz8-DsWw@mail.gmail.com>
	<4ED51291.1010308@hfp.de>
	<CAEc3jaAa7y8C2NNBn1=L3AhS0uuYFP6ze8o1cZ9yG2VYHx6qMA@mail.gmail.com>
	<4ED5215D.1010403@hfp.de>
	<20111129230212.GA23958@andromeda.dapyr.net>
	<CAEc3jaAO0JhtOt6phQHwtE_A+NF7uGHGZ8uJv3BirEYybfVceg@mail.gmail.com>
	<CAEc3jaACffpr9D1Hq_012vHAGhPLEfvsZjh7YyJ=Q-3FdtHS0Q@mail.gmail.com>
	<CAPbh3rtOQ1HTPReqYcpE3vzk+-na0MTLLHZD15=Fg4yxB+ypaA@mail.gmail.com>
	<CAEc3jaBdQKmVJToNZRf+25GtJXqGc274ieHf_yHKRJ+YOKWdgA@mail.gmail.com>
	<20111208234624.GD32474@konrad-lan>
Date: Fri, 9 Dec 2011 01:33:53 +0000
Message-ID: <CAEc3jaC9=HiMoxSYZmXKRzoFcMYRaT9jrX3m1ZQO+M8CrH35Fg@mail.gmail.com>
From: Roderick Colenbrander <thunderbird2k@gmail.com>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
Cc: xen-devel@lists.xensource.com, Andreas Kinzler <ml-xen-devel@hfp.de>
Subject: Re: [Xen-devel] Questions about GPLPV stability tests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Dec 8, 2011 at 11:46 PM, Konrad Rzeszutek Wilk
<konrad@darnok.org> wrote:
> On Wed, Dec 07, 2011 at 08:44:19PM +0000, Roderick Colenbrander wrote:
>> On Wed, Dec 7, 2011 at 8:38 PM, Konrad Rzeszutek Wilk <konrad@darnok.org=
> wrote:
>> >> It took about a week, but the systems went down again. Linux is down,
>> >> but the hypervisor is still reachable on the serial console. Is there
>> >> anything interesting to dump from there?
>> >>
>> > Just the interrupts information. I think that is Ctrl-A, Ctrl-A,
>> > Ctrl-A, and then '*' to capture everything (I don't remember the right
>> > one for just interrupts).
>>
>> Here's the interrupt information:
>> (XEN) [2011-12-06 19:13:37] [i: dump interrupt bindings]
>> (XEN) [2011-12-06 19:13:37] Guest interrupt information:
>> (XEN) [2011-12-06 19:13:37] =A0 =A0IRQ: =A0 0
>> affinity:00000000,00000000,00000000,00000001 vec:f0 type=3DIO-APIC-edge
>> =A0 status=3D00000000 mapped, unbound
>> (XEN) [2011-12-06 19:13:37] =A0 =A0IRQ: =A0 1
>> affinity:00000000,00000000,00000000,00000001 vec:30 type=3DIO-APIC-edge
>> =A0 status=3D00000014 in-flight=3D0 domain-list=3D0: =A01(-S--),
>> (XEN) [2011-12-06 19:13:37] =A0 =A0IRQ: =A0 2
>> affinity:ffffffff,ffffffff,ffffffff,ffffffff vec:e2 type=3DXT-PIC
>> =A0 status=3D00000000 mapped, unbound
>> (XEN) [2011-12-06 19:13:37] =A0 =A0IRQ: =A0 3
>> affinity:00000000,00000000,00000000,00000001 vec:38 type=3DIO-APIC-edge
>> =A0 status=3D00000006 mapped, unbound
>> (XEN) [2011-12-06 19:13:37] =A0 =A0IRQ: =A0 4
>> affinity:00000000,00000000,00000000,00000001 vec:40 type=3DIO-APIC-edge
>> =A0 status=3D00000002 mapped, unbound
>> (XEN) [2011-12-06 19:13:37] =A0 =A0IRQ: =A0 5
>> affinity:00000000,00000000,00000000,00000001 vec:f1 type=3DIO-APIC-edge
>> =A0 status=3D00000000 mapped, unbound
>> (XEN) [2011-12-06 19:13:37] =A0 =A0IRQ: =A0 6
>> affinity:00000000,00000000,00000000,00000001 vec:48 type=3DIO-APIC-edge
>> =A0 status=3D00000002 mapped, unbound
>> (XEN) [2011-12-06 19:13:37] =A0 =A0IRQ: =A0 7
>> affinity:00000000,00000000,00000000,00000001 vec:50 type=3DIO-APIC-edge
>> =A0 status=3D00000002 mapped, unbound
>> (XEN) [2011-12-06 19:13:37] =A0 =A0IRQ: =A0 8
>> affinity:00000000,00000000,00000000,00000001 vec:58 type=3DIO-APIC-edge
>> =A0 status=3D00000010 in-flight=3D0 domain-list=3D0: =A08(-S--),
>> (XEN) [2011-12-06 19:13:37] =A0 =A0IRQ: =A0 9
>> affinity:00000000,00000000,00000000,00000001 vec:60 type=3DIO-APIC-level
>> =A0 status=3D00000010 in-flight=3D0 domain-list=3D0: =A09(-S--),
>> (XEN) [2011-12-06 19:13:37] =A0 =A0IRQ: =A010
>> affinity:00000000,00000000,00000000,00000001 vec:68 type=3DIO-APIC-edge
>> =A0 status=3D00000002 mapped, unbound
>> (XEN) [2011-12-06 19:13:37] =A0 =A0IRQ: =A011
>> affinity:00000000,00000000,00000000,00000001 vec:70 type=3DIO-APIC-edge
>> =A0 status=3D00000002 mapped, unbound
>> (XEN) [2011-12-06 19:13:37] =A0 =A0IRQ: =A012
>> affinity:00000000,00000000,00000000,00000001 vec:78 type=3DIO-APIC-edge
>> =A0 status=3D00000010 in-flight=3D0 domain-list=3D0: 12(-S--),
>> (XEN) [2011-12-06 19:13:37] =A0 =A0IRQ: =A013
>> affinity:00000000,00000000,00000000,00000001 vec:88 type=3DIO-APIC-edge
>> =A0 status=3D00000002 mapped, unbound
>> (XEN) [2011-12-06 19:13:37] =A0 =A0IRQ: =A014
>> affinity:00000000,00000000,00000000,00000001 vec:90 type=3DIO-APIC-edge
>> =A0 status=3D00000002 mapped, unbound
>> (XEN) [2011-12-06 19:13:37] =A0 =A0IRQ: =A015
>> affinity:00000000,00000000,00000000,00000001 vec:98 type=3DIO-APIC-edge
>> =A0 status=3D00000002 mapped, unbound
>> (XEN) [2011-12-06 19:13:37] =A0 =A0IRQ: =A016
>> affinity:00000000,00000000,00000000,00000001 vec:c8 type=3DIO-APIC-level
>> =A0 status=3D00000010 in-flight=3D0 domain-list=3D0: 16(-S--),1201: 16(-=
-M-),
>> (XEN) [2011-12-06 19:13:37] =A0 =A0IRQ: =A018
>> affinity:00000000,00000000,00000000,00000001 vec:51 type=3DIO-APIC-level
>> =A0 status=3D00000010 in-flight=3D0 domain-list=3D0: 18(-S--),
>> (XEN) [2011-12-06 19:13:37] =A0 =A0IRQ: =A019
>> affinity:00000000,00000000,00000000,00000001 vec:d0 type=3DIO-APIC-level
>> =A0 status=3D00000010 in-flight=3D0 domain-list=3D0: 19(-S--),
>> (XEN) [2011-12-06 19:13:37] =A0 =A0IRQ: =A021
>> affinity:00000000,00000000,00000000,00000001 vec:61 type=3DIO-APIC-level
>> =A0 status=3D00000010 in-flight=3D0 domain-list=3D0: 21(-S--),
>> (XEN) [2011-12-06 19:13:37] =A0 =A0IRQ: =A023
>> affinity:00000000,00000000,00000000,00000001 vec:59 type=3DIO-APIC-level
>> =A0 status=3D00000010 in-flight=3D1 domain-list=3D0: 23(PS-M),
>> (XEN) [2011-12-06 19:13:37] =A0 =A0IRQ: =A024
>> affinity:00000000,00000000,00000000,00000001 vec:28 type=3DDMA_MSI
>> =A0 status=3D00000000 mapped, unbound
>> (XEN) [2011-12-06 19:13:38] =A0 =A0IRQ: =A025
>> affinity:00000000,00000000,00000000,00000001 vec:a0 type=3DPCI-MSI
>> =A0 status=3D00000002 mapped, unbound
>> (XEN) [2011-12-06 19:13:38] =A0 =A0IRQ: =A026
>> affinity:00000000,00000000,00000000,00000001 vec:a8 type=3DPCI-MSI
>> =A0 status=3D00000002 mapped, unbound
>> (XEN) [2011-12-06 19:13:38] =A0 =A0IRQ: =A027
>> affinity:00000000,00000000,00000000,00000001 vec:b0 type=3DPCI-MSI
>> =A0 status=3D00000002 mapped, unbound
>> (XEN) [2011-12-06 19:13:38] =A0 =A0IRQ: =A028
>> affinity:00000000,00000000,00000000,00000001 vec:b8 type=3DPCI-MSI
>> =A0 status=3D00000002 mapped, unbound
>> (XEN) [2011-12-06 19:13:38] =A0 =A0IRQ: =A029
>> affinity:00000000,00000000,00000000,00000001 vec:c0 type=3DPCI-MSI
>> =A0 status=3D00000002 mapped, unbound
>> (XEN) [2011-12-06 19:13:38] =A0 =A0IRQ: =A030
>> affinity:00000000,00000000,00000000,00000001 vec:d8 type=3DPCI-MSI
>> =A0 status=3D00000014 in-flight=3D0 domain-list=3D0:274(PS--),
>> (XEN) [2011-12-06 19:13:38] =A0 =A0IRQ: =A031
>> affinity:00000000,00000000,00000000,00000001 vec:21 type=3DPCI-MSI
>> =A0 status=3D00000010 in-flight=3D0 domain-list=3D0:273(PS--),
>> (XEN) [2011-12-06 19:13:38] =A0 =A0IRQ: =A032
>> affinity:00000000,00000000,00000000,00000001 vec:29 type=3DPCI-MSI
>> =A0 status=3D00000010 in-flight=3D0 domain-list=3D0:272(PS--),
>> (XEN) [2011-12-06 19:13:38] =A0 =A0IRQ: =A033
>> affinity:00000000,00000000,00000000,00000001 vec:31 type=3DPCI-MSI
>> =A0 status=3D00000010 in-flight=3D0 domain-list=3D0:271(PS--),
>> (XEN) [2011-12-06 19:13:38] =A0 =A0IRQ: =A034
>> affinity:ffffffff,ffffffff,ffffffff,ffffffff vec:39 type=3DPCI-MSI
>> =A0 status=3D00000002 mapped, unbound
>> (XEN) [2011-12-06 19:13:38] =A0 =A0IRQ: =A035
>> affinity:ffffffff,ffffffff,ffffffff,ffffffff vec:41 type=3DPCI-MSI
>> =A0 status=3D00000002 mapped, unbound
>> (XEN) [2011-12-06 19:13:38] =A0 =A0IRQ: =A036
>> affinity:ffffffff,ffffffff,ffffffff,ffffffff vec:49 type=3DPCI-MSI
>> =A0 status=3D00000002 mapped, unbound
>> (XEN) [2011-12-06 19:13:38] =A0 =A0IRQ: =A037
>> affinity:00000000,00000000,00000000,00000010 vec:65 type=3DPCI-MSI
>> =A0 status=3D00000010 in-flight=3D0 domain-list=3D1201: 55(--M-),
>> (XEN) [2011-12-06 19:13:38] IO-APIC interrupt information:
>> (XEN) [2011-12-06 19:13:38] =A0 =A0 IRQ =A00 Vec240:
>> (XEN) [2011-12-06 19:13:38] =A0 =A0 =A0 Apic 0x00, Pin =A02: vector=3D24=
0,
>> delivery_mode=3D1, dest_mode=3Dlogical, delivery_status=3D0, polarity=3D=
0,
>> irr=3D0, trigger=3Dedge, mask=3D0, dest_id:1
>> (XEN) [2011-12-06 19:13:38] =A0 =A0 IRQ =A01 Vec 48:
>> (XEN) [2011-12-06 19:13:38] =A0 =A0 =A0 Apic 0x00, Pin =A01: vector=3D48,
>> delivery_mode=3D1, dest_mode=3Dlogical, delivery_status=3D0, polarity=3D=
0,
>> irr=3D0, trigger=3Dedge, mask=3D0, dest_id:1
>> (XEN) [2011-12-06 19:13:38] =A0 =A0 IRQ =A03 Vec 56:
>> (XEN) [2011-12-06 19:13:38] =A0 =A0 =A0 Apic 0x00, Pin =A03: vector=3D56,
>> delivery_mode=3D1, dest_mode=3Dlogical, delivery_status=3D0, polarity=3D=
0,
>> irr=3D0, trigger=3Dedge, mask=3D0, dest_id:1
>> (XEN) [2011-12-06 19:13:38] =A0 =A0 IRQ =A04 Vec 64:
>> (XEN) [2011-12-06 19:13:38] =A0 =A0 =A0 Apic 0x00, Pin =A04: vector=3D64,
>> delivery_mode=3D1, dest_mode=3Dlogical, delivery_status=3D0, polarity=3D=
0,
>> irr=3D0, trigger=3Dedge, mask=3D0, dest_id:1
>> (XEN) [2011-12-06 19:13:38] =A0 =A0 IRQ =A05 Vec241:
>> (XEN) [2011-12-06 19:13:38] =A0 =A0 =A0 Apic 0x00, Pin =A05: vector=3D24=
1,
>> delivery_mode=3D1, dest_mode=3Dlogical, delivery_status=3D0, polarity=3D=
0,
>> irr=3D0, trigger=3Dedge, mask=3D0, dest_id:1
>> (XEN) [2011-12-06 19:13:38] =A0 =A0 IRQ =A06 Vec 72:
>> (XEN) [2011-12-06 19:13:38] =A0 =A0 =A0 Apic 0x00, Pin =A06: vector=3D72,
>> delivery_mode=3D1, dest_mode=3Dlogical, delivery_status=3D0, polarity=3D=
0,
>> irr=3D0, trigger=3Dedge, mask=3D0, dest_id:1
>> (XEN) [2011-12-06 19:13:38] =A0 =A0 IRQ =A07 Vec 80:
>> (XEN) [2011-12-06 19:13:38] =A0 =A0 =A0 Apic 0x00, Pin =A07: vector=3D80,
>> delivery_mode=3D1, dest_mode=3Dlogical, delivery_status=3D0, polarity=3D=
0,
>> irr=3D0, trigger=3Dedge, mask=3D0, dest_id:1
>> (XEN) [2011-12-06 19:13:38] =A0 =A0 IRQ =A08 Vec 88:
>> (XEN) [2011-12-06 19:13:38] =A0 =A0 =A0 Apic 0x00, Pin =A08: vector=3D88,
>> delivery_mode=3D1, dest_mode=3Dlogical, delivery_status=3D0, polarity=3D=
0,
>> irr=3D0, trigger=3Dedge, mask=3D0, dest_id:1
>> (XEN) [2011-12-06 19:13:38] =A0 =A0 IRQ =A09 Vec 96:
>> (XEN) [2011-12-06 19:13:38] =A0 =A0 =A0 Apic 0x00, Pin =A09: vector=3D96,
>> delivery_mode=3D1, dest_mode=3Dlogical, delivery_status=3D0, polarity=3D=
0,
>> irr=3D0, trigger=3Dlevel, mask=3D0, dest_id:1
>> (XEN) [2011-12-06 19:13:38] =A0 =A0 IRQ 10 Vec104:
>> (XEN) [2011-12-06 19:13:38] =A0 =A0 =A0 Apic 0x00, Pin 10: vector=3D104,
>> delivery_mode=3D1, dest_mode=3Dlogical, delivery_status=3D0, polarity=3D=
0,
>> irr=3D0, trigger=3Dedge, mask=3D0, dest_id:1
>> (XEN) [2011-12-06 19:13:38] =A0 =A0 IRQ 11 Vec112:
>> (XEN) [2011-12-06 19:13:38] =A0 =A0 =A0 Apic 0x00, Pin 11: vector=3D112,
>> delivery_mode=3D1, dest_mode=3Dlogical, delivery_status=3D0, polarity=3D=
0,
>> irr=3D0, trigger=3Dedge, mask=3D0, dest_id:1
>> (XEN) [2011-12-06 19:13:38] =A0 =A0 IRQ 12 Vec120:
>> (XEN) [2011-12-06 19:13:38] =A0 =A0 =A0 Apic 0x00, Pin 12: vector=3D120,
>> delivery_mode=3D1, dest_mode=3Dlogical, delivery_status=3D0, polarity=3D=
0,
>> irr=3D0, trigger=3Dedge, mask=3D0, dest_id:1
>> (XEN) [2011-12-06 19:13:38] =A0 =A0 IRQ 13 Vec136:
>> (XEN) [2011-12-06 19:13:38] =A0 =A0 =A0 Apic 0x00, Pin 13: vector=3D136,
>> delivery_mode=3D1, dest_mode=3Dlogical, delivery_status=3D0, polarity=3D=
0,
>> irr=3D0, trigger=3Dedge, mask=3D0, dest_id:1
>> (XEN) [2011-12-06 19:13:38] =A0 =A0 IRQ 14 Vec144:
>> (XEN) [2011-12-06 19:13:38] =A0 =A0 =A0 Apic 0x00, Pin 14: vector=3D144,
>> delivery_mode=3D1, dest_mode=3Dlogical, delivery_status=3D0, polarity=3D=
0,
>> irr=3D0, trigger=3Dedge, mask=3D0, dest_id:1
>> (XEN) [2011-12-06 19:13:38] =A0 =A0 IRQ 15 Vec152:
>> (XEN) [2011-12-06 19:13:38] =A0 =A0 =A0 Apic 0x00, Pin 15: vector=3D152,
>> delivery_mode=3D1, dest_mode=3Dlogical, delivery_status=3D0, polarity=3D=
0,
>> irr=3D0, trigger=3Dedge, mask=3D0, dest_id:1
>> (XEN) [2011-12-06 19:13:38] =A0 =A0 IRQ 16 Vec200:
>> (XEN) [2011-12-06 19:13:38] =A0 =A0 =A0 Apic 0x00, Pin 16: vector=3D200,
>> delivery_mode=3D1, dest_mode=3Dlogical, delivery_status=3D0, polarity=3D=
1,
>> irr=3D0, trigger=3Dlevel, mask=3D0, dest_id:1
>> (XEN) [2011-12-06 19:13:38] =A0 =A0 IRQ 18 Vec 81:
>> (XEN) [2011-12-06 19:13:38] =A0 =A0 =A0 Apic 0x00, Pin 18: vector=3D81,
>> delivery_mode=3D1, dest_mode=3Dlogical, delivery_status=3D0, polarity=3D=
1,
>> irr=3D0, trigger=3Dlevel, mask=3D0, dest_id:1
>> (XEN) [2011-12-06 19:13:38] =A0 =A0 IRQ 19 Vec208:
>> (XEN) [2011-12-06 19:13:38] =A0 =A0 =A0 Apic 0x00, Pin 19: vector=3D208,
>> delivery_mode=3D1, dest_mode=3Dlogical, delivery_status=3D0, polarity=3D=
1,
>> irr=3D0, trigger=3Dlevel, mask=3D0, dest_id:1
>> (XEN) [2011-12-06 19:13:38] =A0 =A0 IRQ 21 Vec 97:
>> (XEN) [2011-12-06 19:13:38] =A0 =A0 =A0 Apic 0x00, Pin 21: vector=3D97,
>> delivery_mode=3D1, dest_mode=3Dlogical, delivery_status=3D0, polarity=3D=
1,
>> irr=3D0, trigger=3Dlevel, mask=3D0, dest_id:1
>> (XEN) [2011-12-06 19:13:38] =A0 =A0 IRQ 23 Vec 89:
>> (XEN) [2011-12-06 19:13:38] =A0 =A0 =A0 Apic 0x00, Pin 23: vector=3D89,
>> delivery_mode=3D1, dest_mode=3Dlogical, delivery_status=3D1, polarity=3D=
1,
>> irr=3D1, trigger=3Dlevel, mask=3D0, dest_id:1
>>
>> I noticed some potential interesting things. The system in question is
>> using PCI passthrough. On the serial console I remember seeing that
>> the PCI device got unmapped from DomU and got mapped again in Dom0.
>> The serial console log still had a lot of information about this DomU
>> which I guess was going down. I guess it wasn't fully down yet.
>
> One of the debug informations that gets printed with '*' is the guest
> PCI passthrough data. Such as which IRQ, BAR, etc are mapped in. Did any
> of those exist?

There is not much PCI related information. Just interrupt stuff, no
PCI BARs or other interesting PCI stuff:
(XEN) [2011-12-06 19:13:20] 03:00.0 - dom 1201 - MSIs < 37 >
(XEN) [2011-12-06 19:13:20]  MSI    37 vec=3D65 lowest  edge   assert
log lowest dest=3D00000010 mask=3D0/0/-1


> My original thought of what is going on is that the interrupts either
> stopped completly working (does not look like - it looks like the
> interrupts are firring and the event channels that are bound to it have
> the bits set saying - hey I am pending). Oddly there are bunch of MSI
> ones that are masked which usually means they are disabled.
>
> Then there is the
> =A0affinity:00000000,00000000,00000000,00000001 vec:c8 type=3DIO-APIC-lev=
el
> =A0 status=3D00000010 in-flight=3D0 domain-list=3D0: 16(-S--),1201: 16(--=
M-),
> =A0affinity:00000000,00000000,00000000,00000010 vec:65 type=3DPCI-MSI
> =A0 status=3D00000010 in-flight=3D0 domain-list=3D1201: 55(--M-),
>
> The guest has masked both interrupts - so it is off//dying, but somehow
> the unmapping has not happend. In other words, what you just analyzed
> and found out.
>
> Sadly, there is no smoking gun..
>
> So a couple of things that I would do is to ensure that the Xen
> hypervisor boots with 'sync_console console_to_ring' and when this
> crash happens see if I can get a stack trace from both the Xen
> hypervisor (there are some debug parameters to get that - I think it is
> 'r'?), and also from the Linux kernel.

I set up some new tests, so that will take some days to get a crash.
For what it is worth, I do have a '*' log left from this system and it
has some stack trace. If you think it is useful, I could send it
gzipped, but I don't want to spam this list if it may not be useful.

One thing I did notice was the following:
(XEN) [2011-12-06 19:13:39] active vcpus:
(XEN) [2011-12-06 19:13:39]       1: [1201.2] pri=3D-2 flags=3D0 cpu=3D6
credit=3D-2411 [w=3D256]
(XEN) [2011-12-06 19:13:39]       2: [1201.1] pri=3D-2 flags=3D0 cpu=3D5
credit=3D-2460 [w=3D256]
(XEN) [2011-12-06 19:13:39]       3: [0.2] pri=3D0 flags=3D0 cpu=3D2
credit=3D142 [w=3D256]
(XEN) [2011-12-06 19:13:39]       4: [0.1] pri=3D-2 flags=3D0 cpu=3D1
credit=3D-2612 [w=3D256]
(XEN) [2011-12-06 19:13:39] CPU[00]  sort=3D12511062,
sibling=3D00000000,00000000,00000000,00000003,
core=3D00000000,00000000,00000000,000000ff
(XEN) [2011-12-06 19:13:39]     run: [32767.0] pri=3D0 flags=3D0 cpu=3D0
(XEN) [2011-12-06 19:13:39]       1: [0.0] pri=3D-1 flags=3D0 cpu=3D0
credit=3D333 [w=3D256]
(XEN) [2011-12-06 19:13:39] CPU[01]  sort=3D12511063,
sibling=3D00000000,00000000,00000000,00000003,
core=3D00000000,00000000,00000000,000000ff
(XEN) [2011-12-06 19:13:39]     run: [0.1] pri=3D-2 flags=3D0 cpu=3D1
credit=3D-2914 [w=3D256]
(XEN) [2011-12-06 19:13:39]       1: [32767.1] pri=3D-64 flags=3D0 cpu=3D1
(XEN) [2011-12-06 19:13:39] CPU[02]  sort=3D12511063,
sibling=3D00000000,00000000,00000000,0000000c,
core=3D00000000,00000000,00000000,000000ff
(XEN) [2011-12-06 19:13:39]     run: [32767.2] pri=3D-64 flags=3D0 cpu=3D2
(XEN) [2011-12-06 19:13:39] CPU[03]  sort=3D12511063,
sibling=3D00000000,00000000,00000000,0000000c,
core=3D00000000,00000000,00000000,000000ff
(XEN) [2011-12-06 19:13:39]     run: [32767.3] pri=3D-64 flags=3D0 cpu=3D3
(XEN) [2011-12-06 19:13:39] CPU[04]  sort=3D12511063,
sibling=3D00000000,00000000,00000000,00000030,
core=3D00000000,00000000,00000000,000000ff
(XEN) [2011-12-06 19:13:39]     run: [32767.4] pri=3D-64 flags=3D0 cpu=3D4
(XEN) [2011-12-06 19:13:39] CPU[05]  sort=3D12511063,
sibling=3D00000000,00000000,00000000,00000030,
core=3D00000000,00000000,00000000,000000ff
(XEN) [2011-12-06 19:13:39]     run: [1201.1] pri=3D-2 flags=3D0 cpu=3D5
credit=3D-3617 [w=3D256]
(XEN) [2011-12-06 19:13:39]       1: [32767.5] pri=3D-64 flags=3D0 cpu=3D5
(XEN) [2011-12-06 19:13:39] CPU[06]  sort=3D12511063,
sibling=3D00000000,00000000,00000000,000000c0,
core=3D00000000,00000000,00000000,000000ff
(XEN) [2011-12-06 19:13:39]     run: [1201.2] pri=3D-2 flags=3D0 cpu=3D6
credit=3D-3918 [w=3D256]
(XEN) [2011-12-06 19:13:39]       1: [32767.6] pri=3D-64 flags=3D0 cpu=3D6
(XEN) [2011-12-06 19:13:39] CPU[07]  sort=3D12511063,
sibling=3D00000000,00000000,00000000,000000c0,
core=3D00000000,00000000,00000000,000000ff
(XEN) [2011-12-06 19:13:39]     run: [32767.7] pri=3D-64 flags=3D0 cpu=3D7

The system in question has a 4-core i7 CPU where Dom0 is pinned to
core 0-3 and DomU is pinned 4-7. Aren't the negative credit numbers
quite big?

>
> But also see if the problem disappears with the latest 4.1.x hypervisor.
> And it might also be worth upgrading the dom0 to a 3.0. Hmm, it would be
> very interesting to see where the dom0 _is_ stuck at. The hypervisor is
> running fine so it all points to dom0 crashing somewhere..
>
> Can you make sure that dom0 runs with 'debug loglevel=3D8' as well. That
> should give some wealth of information when/if a crash happens.
> Oh, and try to pass in Ctrl-Alt-SysRQ-t (on serial concentrators I think
> you just need to type 'break' on the telnet line)and then t. But I am
> not entirely sure about it - might want to double check Google and see
> how to enable Alt-SysRQ.

I tried to get SysRq working. It worked fine on some of my other
machines (sysrq=3D 'shift-control-o'), but not on this broken box.
Apparently the kernel is stuck in some place where SysRq doesn't work.

I'm going to retest with the relevant logging turned on. I also
upgraded to the latest 2.6.32 kernel (.48 I think). I will also
upgrade to the latest 4.1.x build from the mercurial repository. It
will take a few days before I get crash.

Thanks so far!
Roderick

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 02:55:42 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 02: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.xensource.com>)
	id 1RYqc1-0007zd-Cd; Fri, 09 Dec 2011 02:55:01 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RYqbz-0007zV-KS
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 02:55:00 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-10.tower-174.messagelabs.com!1323399250!4839651!1
X-Originating-IP: [208.97.132.66]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi42NiA9PiAxNTc5MQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11133 invoked from network); 9 Dec 2011 02:54:10 -0000
Received: from caiajhbdcagg.dreamhost.com (HELO homiemail-a23.g.dreamhost.com)
	(208.97.132.66) by server-10.tower-174.messagelabs.com with SMTP;
	9 Dec 2011 02:54:10 -0000
Received: from homiemail-a23.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a23.g.dreamhost.com (Postfix) with ESMTP id 3DD114B006D;
	Thu,  8 Dec 2011 18:54:09 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=tgyQcCZzYX3Nawu/I70d30zW7IUO29fNd4kLSf06buB6
	209BWyxNg3ReKOMAhvjLkRouXZFcVcpahAby1vA9TeDLY3koWkC1JXmLvOA3y784
	l2ycEs4o+HMqAQnqWFtCB6okIxZ/CVPmE4yd0N7OCPafl31lZLaQfvVQ/uNkoPc=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=LLs7NFgxTbnbADdTEWU42w1yXrQ=; b=RAbTuTvd
	q0ul5vCFvSgzeOLU1oR06L4RCBIuvlhU7+nHhFVS24DNizIPGgD4tcpJaoy/tVv/
	JjPsye6xIaZ1ZnucAoNQBGFu/xg+xwogXHdeNkGNRjCwzSRsxY0OAfwNm4QsvJDT
	ALF86d8N5AhWH9N7keHo8zzc2XQ8cOFj5mI=
Received: from webmail.lagarcavilla.org (ahfbbjcaiaae.dreamhost.com
	[75.119.208.4]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a23.g.dreamhost.com (Postfix) with ESMTPA id D0F924B0062; 
	Thu,  8 Dec 2011 18:54:08 -0800 (PST)
Received: from 69.196.182.137 (proxying for 69.196.182.137)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP; Thu, 8 Dec 2011 18:54:09 -0800
Message-ID: <cba5ca07476cc5619c84113b26325886.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20111208223822.GH87836@ocelot.phlegethon.org>
References: <patchbomb.1323330435@xdev.gridcentric.ca>
	<ecf95feef9ac5a7d0b79.1323330447@xdev.gridcentric.ca>
	<20111208223822.GH87836@ocelot.phlegethon.org>
Date: Thu, 8 Dec 2011 18:54:09 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Tim Deegan" <tim@xen.org>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, ian.campbell@citrix.com,
	andres@gridcentric.ca, keir.xen@gmail.com, jbeulich@suse.com,
	ian.jackson@citrix.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 12 of 18] x86/mm: Make page_lock/unlock() in
 arch/x86/mm.c externally callable
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> At 02:47 -0500 on 08 Dec (1323312447), Andres Lagar-Cavilla wrote:
>> This is necessary for a new consumer of page_lock/unlock to follow in
>> the series.
>>
>> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
>
> Nak, I'm afraid.
>
> These were OK as local functions but if they're going to be made
> generally visible, they need clear comments describing what this
> locking protects and what the discipline is for avoiding deadlocks.

How about something along the lines of
"page_lock() is used for two purposes: pte serialization, and memory
sharing. All users of page lock for pte serialization live in mm.c, use it
to lock a page table page during pte updates, do not take other locks
within the critical section delimited by page_lock/unlock, and perform no
nesting. All users of page lock for memory sharing live in
mm/mem_sharing.c. For memory sharing, nesting may happen when sharing (and
locking) two pages -- deadlock is avoided by locking pages in increasing
order. Memory sharing may take the p2m_lock within a page_lock/unlock
critical section. These two users (pte serialization and memory sharing)
should never collide, as long as page table pages are properly unshared
prior to updating."

Now those are all pretty words, but here are the two things I (think I)
need to do:
- Prior to updating pte's, we do get_gfn on the page table page. We should
be using get_gfn_unshare. Regardless of this patch. It's likely never
going to trigger an actual unshare, yet better safe than sorry.
- I can wrap uses of page_lock in mm sharing in an "external"
order-enforcing construct from mm-locks.h. And use that to scream deadlock
between page_lock and p2m_lock.

The code that actually uses page_lock()s in the memory sharing code can be
found in "[PATCH] x86/mm: Eliminate global lock in mem sharing code". It
already orders locking of individual pages in ascending order.

Andres

>
> Perhaps Jan or Keir can supply appropriate words.  The locking was
> introduce in this cset:
>
>     changeset:   17846:09dd5999401b
>     user:        Keir Fraser <keir.fraser@citrix.com>
>     date:        Thu Jun 12 18:14:00 2008 +0100
>     files:       xen/arch/x86/domain.c xen/arch/x86/domain_build.c
>     xen/arch/x86/mm.c
>     description:
>     x86: remove use of per-domain lock from page table entry handling
>
>     This change results in a 5% performance improvement for kernel builds
>     on dual-socket quad-core systems (which is what I used for reference
>     for both 32- and 64-bit). Along with that, the amount of time reported
>     as spent in the kernel gets reduced by almost 25% (the fraction of
>     time spent in the kernel is generally reported significantly higher
>     under Xen than with a native kernel).
>
>     Signed-off-by: Jan Beulich <jbeulich@novell.com>
>     Signed-off-by: Keir Fraser <keir.fraser@citrix.com>
>
> Tim.
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 02:55:42 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 02: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.xensource.com>)
	id 1RYqc1-0007zd-Cd; Fri, 09 Dec 2011 02:55:01 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RYqbz-0007zV-KS
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 02:55:00 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-10.tower-174.messagelabs.com!1323399250!4839651!1
X-Originating-IP: [208.97.132.66]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi42NiA9PiAxNTc5MQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11133 invoked from network); 9 Dec 2011 02:54:10 -0000
Received: from caiajhbdcagg.dreamhost.com (HELO homiemail-a23.g.dreamhost.com)
	(208.97.132.66) by server-10.tower-174.messagelabs.com with SMTP;
	9 Dec 2011 02:54:10 -0000
Received: from homiemail-a23.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a23.g.dreamhost.com (Postfix) with ESMTP id 3DD114B006D;
	Thu,  8 Dec 2011 18:54:09 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=tgyQcCZzYX3Nawu/I70d30zW7IUO29fNd4kLSf06buB6
	209BWyxNg3ReKOMAhvjLkRouXZFcVcpahAby1vA9TeDLY3koWkC1JXmLvOA3y784
	l2ycEs4o+HMqAQnqWFtCB6okIxZ/CVPmE4yd0N7OCPafl31lZLaQfvVQ/uNkoPc=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=LLs7NFgxTbnbADdTEWU42w1yXrQ=; b=RAbTuTvd
	q0ul5vCFvSgzeOLU1oR06L4RCBIuvlhU7+nHhFVS24DNizIPGgD4tcpJaoy/tVv/
	JjPsye6xIaZ1ZnucAoNQBGFu/xg+xwogXHdeNkGNRjCwzSRsxY0OAfwNm4QsvJDT
	ALF86d8N5AhWH9N7keHo8zzc2XQ8cOFj5mI=
Received: from webmail.lagarcavilla.org (ahfbbjcaiaae.dreamhost.com
	[75.119.208.4]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a23.g.dreamhost.com (Postfix) with ESMTPA id D0F924B0062; 
	Thu,  8 Dec 2011 18:54:08 -0800 (PST)
Received: from 69.196.182.137 (proxying for 69.196.182.137)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP; Thu, 8 Dec 2011 18:54:09 -0800
Message-ID: <cba5ca07476cc5619c84113b26325886.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20111208223822.GH87836@ocelot.phlegethon.org>
References: <patchbomb.1323330435@xdev.gridcentric.ca>
	<ecf95feef9ac5a7d0b79.1323330447@xdev.gridcentric.ca>
	<20111208223822.GH87836@ocelot.phlegethon.org>
Date: Thu, 8 Dec 2011 18:54:09 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Tim Deegan" <tim@xen.org>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, ian.campbell@citrix.com,
	andres@gridcentric.ca, keir.xen@gmail.com, jbeulich@suse.com,
	ian.jackson@citrix.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 12 of 18] x86/mm: Make page_lock/unlock() in
 arch/x86/mm.c externally callable
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> At 02:47 -0500 on 08 Dec (1323312447), Andres Lagar-Cavilla wrote:
>> This is necessary for a new consumer of page_lock/unlock to follow in
>> the series.
>>
>> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
>
> Nak, I'm afraid.
>
> These were OK as local functions but if they're going to be made
> generally visible, they need clear comments describing what this
> locking protects and what the discipline is for avoiding deadlocks.

How about something along the lines of
"page_lock() is used for two purposes: pte serialization, and memory
sharing. All users of page lock for pte serialization live in mm.c, use it
to lock a page table page during pte updates, do not take other locks
within the critical section delimited by page_lock/unlock, and perform no
nesting. All users of page lock for memory sharing live in
mm/mem_sharing.c. For memory sharing, nesting may happen when sharing (and
locking) two pages -- deadlock is avoided by locking pages in increasing
order. Memory sharing may take the p2m_lock within a page_lock/unlock
critical section. These two users (pte serialization and memory sharing)
should never collide, as long as page table pages are properly unshared
prior to updating."

Now those are all pretty words, but here are the two things I (think I)
need to do:
- Prior to updating pte's, we do get_gfn on the page table page. We should
be using get_gfn_unshare. Regardless of this patch. It's likely never
going to trigger an actual unshare, yet better safe than sorry.
- I can wrap uses of page_lock in mm sharing in an "external"
order-enforcing construct from mm-locks.h. And use that to scream deadlock
between page_lock and p2m_lock.

The code that actually uses page_lock()s in the memory sharing code can be
found in "[PATCH] x86/mm: Eliminate global lock in mem sharing code". It
already orders locking of individual pages in ascending order.

Andres

>
> Perhaps Jan or Keir can supply appropriate words.  The locking was
> introduce in this cset:
>
>     changeset:   17846:09dd5999401b
>     user:        Keir Fraser <keir.fraser@citrix.com>
>     date:        Thu Jun 12 18:14:00 2008 +0100
>     files:       xen/arch/x86/domain.c xen/arch/x86/domain_build.c
>     xen/arch/x86/mm.c
>     description:
>     x86: remove use of per-domain lock from page table entry handling
>
>     This change results in a 5% performance improvement for kernel builds
>     on dual-socket quad-core systems (which is what I used for reference
>     for both 32- and 64-bit). Along with that, the amount of time reported
>     as spent in the kernel gets reduced by almost 25% (the fraction of
>     time spent in the kernel is generally reported significantly higher
>     under Xen than with a native kernel).
>
>     Signed-off-by: Jan Beulich <jbeulich@novell.com>
>     Signed-off-by: Keir Fraser <keir.fraser@citrix.com>
>
> Tim.
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 02:59:04 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 02: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.xensource.com>)
	id 1RYqfS-00085j-0U; Fri, 09 Dec 2011 02:58:34 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RYqfR-00085c-A3
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 02:58:33 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-4.tower-27.messagelabs.com!1323399436!51705654!1
X-Originating-IP: [208.97.132.5]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi41ID0+IDE1NDY4\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30765 invoked from network); 9 Dec 2011 02:57:16 -0000
Received: from mailbigip.dreamhost.com (HELO homiemail-a75.g.dreamhost.com)
	(208.97.132.5) by server-4.tower-27.messagelabs.com with SMTP;
	9 Dec 2011 02:57:16 -0000
Received: from homiemail-a75.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a75.g.dreamhost.com (Postfix) with ESMTP id 5DC055EC07E;
	Thu,  8 Dec 2011 18:57:48 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=r6Rhd8FIcq3BeqeNFMk7roGGpCfdPIFIVhWVaAmOzMFL
	InbLDa4bVuR3GUAgc1w+m6qpBPEmP9mS0eDehX6S0TQKUwfspMSBOli5Whh+LmwM
	qGlnFdgodcgr1QJre8CWgjz8ck7JyvDsDOPLn/1W+DkqGGX9NrNn/M1lyceKVeg=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=ffFR7nHzYHwBvlrk8ooUa5IddE8=; b=D6jhh2m9
	RPBhHS/5mndGqbJ4rWPMZTN5Sns5fo34vredOWFu4bDtjOQsKn57VdTeWSwDhknW
	ggf7lDZyEdsj+8z3ZshLkwDRg+23ovzY1Dy5K9q6WkCZ8Lyu2W8bjqlez4rNNJ2p
	XNorLP9PZgJV7bKMdc/82OrdBrAPKgf5BMs=
Received: from webmail.lagarcavilla.org (ahfbbjcaiaae.dreamhost.com
	[75.119.208.4]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a75.g.dreamhost.com (Postfix) with ESMTPA id EA1F35EC07C; 
	Thu,  8 Dec 2011 18:57:47 -0800 (PST)
Received: from 69.196.182.137 (proxying for 69.196.182.137)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP; Thu, 8 Dec 2011 18:57:48 -0800
Message-ID: <e84a61ddcda40f45447595d12994de40.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20111208222024.GF87836@ocelot.phlegethon.org>
References: <patchbomb.1323330435@xdev.gridcentric.ca>
	<2e8d5702f4c17d0af9f3.1323330439@xdev.gridcentric.ca>
	<20111208222024.GF87836@ocelot.phlegethon.org>
Date: Thu, 8 Dec 2011 18:57:48 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Tim Deegan" <tim@xen.org>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, ian.campbell@citrix.com,
	andres@gridcentric.ca, keir.xen@gmail.com, jbeulich@suse.com,
	ian.jackson@citrix.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 04 of 18] x86/mm: Update mem sharing
 interface to (re)allow sharing of grants
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> Hi,
>
> At 02:47 -0500 on 08 Dec (1323312439), Andres Lagar-Cavilla wrote:
>> +            if (
>> XEN_DOMCTL_MEM_SHARING_FIELD_IS_GREF(mec->u.share.client_gfn) )
>> +            {
>> +                grant_ref_t gref = (grant_ref_t)
>> +
>> (XEN_DOMCTL_MEM_SHARING_FIELD_GET_GREF(
>> +                                        mec->u.share.client_gfn));
>> +                if ( (!source_is_gref) ||
>> +                     (mem_sharing_gref_to_gfn(cd, gref, &cgfn) < 0) )
>> +                {
>> +                    put_domain(cd);
>> +                    return -EINVAL;
>> +                }
>> +            } else {
>> +                if ( source_is_gref )
>> +                {
>> +                    put_domain(cd);
>> +                    return -EINVAL;
>> +                }
>
> Why can't one input be a grant and the other not?  If there's a problem
> with that it should probably be documented in the hypercall interface.
>
No particular problem. The gref use case is the current target of
tools/memshr, which always does gref-to-gref sharing. I imagine
gref-to-gfn sharing to be extremely unlikely.

But there is no need to disallow it.

Andres
> Cheers,
>
> Tim.
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 02:59:04 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 02: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.xensource.com>)
	id 1RYqfS-00085j-0U; Fri, 09 Dec 2011 02:58:34 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RYqfR-00085c-A3
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 02:58:33 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-4.tower-27.messagelabs.com!1323399436!51705654!1
X-Originating-IP: [208.97.132.5]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi41ID0+IDE1NDY4\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30765 invoked from network); 9 Dec 2011 02:57:16 -0000
Received: from mailbigip.dreamhost.com (HELO homiemail-a75.g.dreamhost.com)
	(208.97.132.5) by server-4.tower-27.messagelabs.com with SMTP;
	9 Dec 2011 02:57:16 -0000
Received: from homiemail-a75.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a75.g.dreamhost.com (Postfix) with ESMTP id 5DC055EC07E;
	Thu,  8 Dec 2011 18:57:48 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=r6Rhd8FIcq3BeqeNFMk7roGGpCfdPIFIVhWVaAmOzMFL
	InbLDa4bVuR3GUAgc1w+m6qpBPEmP9mS0eDehX6S0TQKUwfspMSBOli5Whh+LmwM
	qGlnFdgodcgr1QJre8CWgjz8ck7JyvDsDOPLn/1W+DkqGGX9NrNn/M1lyceKVeg=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=ffFR7nHzYHwBvlrk8ooUa5IddE8=; b=D6jhh2m9
	RPBhHS/5mndGqbJ4rWPMZTN5Sns5fo34vredOWFu4bDtjOQsKn57VdTeWSwDhknW
	ggf7lDZyEdsj+8z3ZshLkwDRg+23ovzY1Dy5K9q6WkCZ8Lyu2W8bjqlez4rNNJ2p
	XNorLP9PZgJV7bKMdc/82OrdBrAPKgf5BMs=
Received: from webmail.lagarcavilla.org (ahfbbjcaiaae.dreamhost.com
	[75.119.208.4]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a75.g.dreamhost.com (Postfix) with ESMTPA id EA1F35EC07C; 
	Thu,  8 Dec 2011 18:57:47 -0800 (PST)
Received: from 69.196.182.137 (proxying for 69.196.182.137)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP; Thu, 8 Dec 2011 18:57:48 -0800
Message-ID: <e84a61ddcda40f45447595d12994de40.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20111208222024.GF87836@ocelot.phlegethon.org>
References: <patchbomb.1323330435@xdev.gridcentric.ca>
	<2e8d5702f4c17d0af9f3.1323330439@xdev.gridcentric.ca>
	<20111208222024.GF87836@ocelot.phlegethon.org>
Date: Thu, 8 Dec 2011 18:57:48 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Tim Deegan" <tim@xen.org>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, ian.campbell@citrix.com,
	andres@gridcentric.ca, keir.xen@gmail.com, jbeulich@suse.com,
	ian.jackson@citrix.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 04 of 18] x86/mm: Update mem sharing
 interface to (re)allow sharing of grants
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> Hi,
>
> At 02:47 -0500 on 08 Dec (1323312439), Andres Lagar-Cavilla wrote:
>> +            if (
>> XEN_DOMCTL_MEM_SHARING_FIELD_IS_GREF(mec->u.share.client_gfn) )
>> +            {
>> +                grant_ref_t gref = (grant_ref_t)
>> +
>> (XEN_DOMCTL_MEM_SHARING_FIELD_GET_GREF(
>> +                                        mec->u.share.client_gfn));
>> +                if ( (!source_is_gref) ||
>> +                     (mem_sharing_gref_to_gfn(cd, gref, &cgfn) < 0) )
>> +                {
>> +                    put_domain(cd);
>> +                    return -EINVAL;
>> +                }
>> +            } else {
>> +                if ( source_is_gref )
>> +                {
>> +                    put_domain(cd);
>> +                    return -EINVAL;
>> +                }
>
> Why can't one input be a grant and the other not?  If there's a problem
> with that it should probably be documented in the hypercall interface.
>
No particular problem. The gref use case is the current target of
tools/memshr, which always does gref-to-gref sharing. I imagine
gref-to-gfn sharing to be extremely unlikely.

But there is no need to disallow it.

Andres
> Cheers,
>
> Tim.
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 03:02:36 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 03: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.xensource.com>)
	id 1RYqiw-0008LB-Tf; Fri, 09 Dec 2011 03:02:10 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RYqiv-0008Ks-2F
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 03:02:09 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-6.tower-174.messagelabs.com!1323399679!4840412!1
X-Originating-IP: [208.97.132.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMDguOTcuMTMyLjgxID0+IDE3MjQy\n,sa_preprocessor: 
	QmFkIElQOiAyMDguOTcuMTMyLjgxID0+IDE3MjQy\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22329 invoked from network); 9 Dec 2011 03:01:19 -0000
Received: from caiajhbdcaib.dreamhost.com (HELO homiemail-a22.g.dreamhost.com)
	(208.97.132.81) by server-6.tower-174.messagelabs.com with SMTP;
	9 Dec 2011 03:01:19 -0000
Received: from homiemail-a22.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a22.g.dreamhost.com (Postfix) with ESMTP id 5027B1A8093;
	Thu,  8 Dec 2011 19:01:18 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=c0wRYUgzaqu3bBvY+lRR40j6hQ7F26NqnUOFnxT4Nozv
	XhVOTl92ngvE4cMIBEoKOvGHZ9928jAvXElwIcnPfubSizVJAfTpVMiUSDWl8BqJ
	x4xGe1glZnwwQbGtJ76e5BQpU9cAAGiXQwwmTiKqxaaIgvQ2s2R1L9AkUAMJQDg=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=n6h0UgTb39cP2NirEFgxbLn65Ew=; b=bhLLKinU
	F33QBwl8zZnitcE7I2vXyEs+1n1bTu3trjgrpj1GycUgi4jhwANFJBtmjDRh4Kv1
	kvC/wJXsVeN9c0uZBOSaa+KyP/icAfJa4P3TTKE8GCnm23Km2Lv2Vbytj4NLcFvK
	b0dGO9mNq4UHzOVvF03eSdvCLkJGMEpI7O4=
Received: from webmail.lagarcavilla.org (ahfbbjcaiaae.dreamhost.com
	[75.119.208.4]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a22.g.dreamhost.com (Postfix) with ESMTPA id 14D291A8091; 
	Thu,  8 Dec 2011 19:01:18 -0800 (PST)
Received: from 69.196.182.137 (proxying for 69.196.182.137)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP; Thu, 8 Dec 2011 19:01:18 -0800
Message-ID: <123ea80c57135b138f37258fd7c9c8a0.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <CB06F385.26D54%keir.xen@gmail.com>
References: <CB06F385.26D54%keir.xen@gmail.com>
Date: Thu, 8 Dec 2011 19:01:18 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Keir Fraser" <keir.xen@gmail.com>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, ian.campbell@citrix.com,
	andres@gridcentric.ca, Tim Deegan <tim@xen.org>,
	jbeulich@suse.com, ian.jackson@citrix.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 12 of 18] x86/mm: Make page_lock/unlock() in
 arch/x86/mm.c externally callable
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> On 08/12/2011 22:38, "Tim Deegan" <tim@xen.org> wrote:
>
>> At 02:47 -0500 on 08 Dec (1323312447), Andres Lagar-Cavilla wrote:
>>> This is necessary for a new consumer of page_lock/unlock to follow in
>>> the series.
>>>
>>> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
>>
>> Nak, I'm afraid.
>>
>> These were OK as local functions but if they're going to be made
>> generally visible, they need clear comments describing what this
>> locking protects and what the discipline is for avoiding deadlocks.
>>
>> Perhaps Jan or Keir can supply appropriate words.  The locking was
>> introduce in this cset:
>
> It's Jan's work originally, but the basic intention of page_lock is to
> serialise pte updates. To aid with this, a page's type cannot change while
> its lock is held.
That's definitely a property I want to leverage.

> No lock nests inside a page lock (not even other page
> locks) so there is no deadlock risk.
There's no way to not nest when sharing two pages, but I always make sure
I lock in ascending order.

Thanks,
Andres
>
>>     changeset:   17846:09dd5999401b
>>     user:        Keir Fraser <keir.fraser@citrix.com>
>>     date:        Thu Jun 12 18:14:00 2008 +0100
>>     files:       xen/arch/x86/domain.c xen/arch/x86/domain_build.c
>>     xen/arch/x86/mm.c
>>     description:
>>     x86: remove use of per-domain lock from page table entry handling
>>
>>     This change results in a 5% performance improvement for kernel
>> builds
>>     on dual-socket quad-core systems (which is what I used for reference
>>     for both 32- and 64-bit). Along with that, the amount of time
>> reported
>>     as spent in the kernel gets reduced by almost 25% (the fraction of
>>     time spent in the kernel is generally reported significantly higher
>>     under Xen than with a native kernel).
>>
>>     Signed-off-by: Jan Beulich <jbeulich@novell.com>
>>     Signed-off-by: Keir Fraser <keir.fraser@citrix.com>
>>
>> Tim.
>
>
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 03:02:36 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 03: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.xensource.com>)
	id 1RYqiw-0008LB-Tf; Fri, 09 Dec 2011 03:02:10 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RYqiv-0008Ks-2F
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 03:02:09 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-6.tower-174.messagelabs.com!1323399679!4840412!1
X-Originating-IP: [208.97.132.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMDguOTcuMTMyLjgxID0+IDE3MjQy\n,sa_preprocessor: 
	QmFkIElQOiAyMDguOTcuMTMyLjgxID0+IDE3MjQy\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22329 invoked from network); 9 Dec 2011 03:01:19 -0000
Received: from caiajhbdcaib.dreamhost.com (HELO homiemail-a22.g.dreamhost.com)
	(208.97.132.81) by server-6.tower-174.messagelabs.com with SMTP;
	9 Dec 2011 03:01:19 -0000
Received: from homiemail-a22.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a22.g.dreamhost.com (Postfix) with ESMTP id 5027B1A8093;
	Thu,  8 Dec 2011 19:01:18 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=c0wRYUgzaqu3bBvY+lRR40j6hQ7F26NqnUOFnxT4Nozv
	XhVOTl92ngvE4cMIBEoKOvGHZ9928jAvXElwIcnPfubSizVJAfTpVMiUSDWl8BqJ
	x4xGe1glZnwwQbGtJ76e5BQpU9cAAGiXQwwmTiKqxaaIgvQ2s2R1L9AkUAMJQDg=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=n6h0UgTb39cP2NirEFgxbLn65Ew=; b=bhLLKinU
	F33QBwl8zZnitcE7I2vXyEs+1n1bTu3trjgrpj1GycUgi4jhwANFJBtmjDRh4Kv1
	kvC/wJXsVeN9c0uZBOSaa+KyP/icAfJa4P3TTKE8GCnm23Km2Lv2Vbytj4NLcFvK
	b0dGO9mNq4UHzOVvF03eSdvCLkJGMEpI7O4=
Received: from webmail.lagarcavilla.org (ahfbbjcaiaae.dreamhost.com
	[75.119.208.4]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a22.g.dreamhost.com (Postfix) with ESMTPA id 14D291A8091; 
	Thu,  8 Dec 2011 19:01:18 -0800 (PST)
Received: from 69.196.182.137 (proxying for 69.196.182.137)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP; Thu, 8 Dec 2011 19:01:18 -0800
Message-ID: <123ea80c57135b138f37258fd7c9c8a0.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <CB06F385.26D54%keir.xen@gmail.com>
References: <CB06F385.26D54%keir.xen@gmail.com>
Date: Thu, 8 Dec 2011 19:01:18 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Keir Fraser" <keir.xen@gmail.com>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, ian.campbell@citrix.com,
	andres@gridcentric.ca, Tim Deegan <tim@xen.org>,
	jbeulich@suse.com, ian.jackson@citrix.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 12 of 18] x86/mm: Make page_lock/unlock() in
 arch/x86/mm.c externally callable
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> On 08/12/2011 22:38, "Tim Deegan" <tim@xen.org> wrote:
>
>> At 02:47 -0500 on 08 Dec (1323312447), Andres Lagar-Cavilla wrote:
>>> This is necessary for a new consumer of page_lock/unlock to follow in
>>> the series.
>>>
>>> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
>>
>> Nak, I'm afraid.
>>
>> These were OK as local functions but if they're going to be made
>> generally visible, they need clear comments describing what this
>> locking protects and what the discipline is for avoiding deadlocks.
>>
>> Perhaps Jan or Keir can supply appropriate words.  The locking was
>> introduce in this cset:
>
> It's Jan's work originally, but the basic intention of page_lock is to
> serialise pte updates. To aid with this, a page's type cannot change while
> its lock is held.
That's definitely a property I want to leverage.

> No lock nests inside a page lock (not even other page
> locks) so there is no deadlock risk.
There's no way to not nest when sharing two pages, but I always make sure
I lock in ascending order.

Thanks,
Andres
>
>>     changeset:   17846:09dd5999401b
>>     user:        Keir Fraser <keir.fraser@citrix.com>
>>     date:        Thu Jun 12 18:14:00 2008 +0100
>>     files:       xen/arch/x86/domain.c xen/arch/x86/domain_build.c
>>     xen/arch/x86/mm.c
>>     description:
>>     x86: remove use of per-domain lock from page table entry handling
>>
>>     This change results in a 5% performance improvement for kernel
>> builds
>>     on dual-socket quad-core systems (which is what I used for reference
>>     for both 32- and 64-bit). Along with that, the amount of time
>> reported
>>     as spent in the kernel gets reduced by almost 25% (the fraction of
>>     time spent in the kernel is generally reported significantly higher
>>     under Xen than with a native kernel).
>>
>>     Signed-off-by: Jan Beulich <jbeulich@novell.com>
>>     Signed-off-by: Keir Fraser <keir.fraser@citrix.com>
>>
>> Tim.
>
>
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 03:38:11 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 03: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.xensource.com>)
	id 1RYrHL-0000Bk-Tb; Fri, 09 Dec 2011 03:37:43 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <shijie1234321@gmail.com>) id 1RYrHK-0000Bb-FO
	for Xen-devel@lists.xensource.com; Fri, 09 Dec 2011 03:37:42 +0000
X-Env-Sender: shijie1234321@gmail.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1323401811!6501235!1
X-Originating-IP: [209.85.161.171]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_10_20,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18025 invoked from network); 9 Dec 2011 03:36:53 -0000
Received: from mail-gx0-f171.google.com (HELO mail-gx0-f171.google.com)
	(209.85.161.171)
	by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 03:36:53 -0000
Received: by ggnh4 with SMTP id h4so8182814ggn.30
	for <Xen-devel@lists.xensource.com>;
	Thu, 08 Dec 2011 19:36:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=Z2ccs9cehTa7FEC5AYA5u0ZlfUzvh4c8By+CG/PbYUQ=;
	b=GO4+WHuY9NUYgXnhBxhEhys1X77MjyeHSWsRsc1tMYy2++bgN9w/BWCEeHXzN2U7xd
	OX/YvVf4BoTI52dIZPXUHqwLddG7w5EXkWVKzAmsc7clTWvg1wTQ7w5xXlXs/UKjB88l
	s68V1qh0MmeMAtq31f+8dtQKOepyEkth+87wE=
MIME-Version: 1.0
Received: by 10.182.145.2 with SMTP id sq2mr96036obb.51.1323401811430; Thu, 08
	Dec 2011 19:36:51 -0800 (PST)
Received: by 10.182.15.193 with HTTP; Thu, 8 Dec 2011 19:36:51 -0800 (PST)
Date: Fri, 9 Dec 2011 11:36:51 +0800
Message-ID: <CADur4tkixSsqbMDudi2n0JgNitJ_ANWDbcp9jJ6QNN12DgM+BQ@mail.gmail.com>
From: Bryant Kobe <shijie1234321@gmail.com>
To: Xen-devel@lists.xensource.com
Subject: [Xen-devel] how to start vms concurrently and how to add a event ?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============7702662628576339473=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============7702662628576339473==
Content-Type: multipart/alternative; boundary=f46d044786dfdd8d4004b3a07e6b

--f46d044786dfdd8d4004b3a07e6b
Content-Type: text/plain; charset=ISO-8859-1

Hello  list ,

1.   I find that some errors would be raised when to start vms concurrently
,
and find there is a coarse-grain lock in start code of xend written in
python,
but in XendBootloader.py there is a little time to release and then
re-aquire
the lock .
I want to know whether which is why errors occur when starting
concurrently .
and how to solve these problems ?  just to modify the coarse-grain lock of
xen source code in the part to fine-grain lock ?
if so there will be a long time and hard work.

2.    when I start a vm using vhd , it should mount the vhd file to
/dev/xvdp in
dom0 and then this virtual device is encapsulated to a vbd object ,finally
which
is installed in xenstore by backend process before pygrub is working .
This set-up procedure would cost some time , so if the device have not
prepared when pygrub continues to work , some errors take place .
I want to know whether i could add a event to notify the frontend that the
device is completely prepared ?
and where is the backend code related ?

--f46d044786dfdd8d4004b3a07e6b
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hello =A0list ,<div><br></div><div>1. =A0 I find that some errors would be =
raised when to start vms concurrently ,=A0</div><div>and find there is a co=
arse-grain lock in start code of xend written in python,</div><div>but in X=
endBootloader.py there is a little time to release and then re-aquire</div>

<div>the lock .</div><div>I want to know whether which is why errors occur =
when starting=A0</div><div>concurrently .=A0</div><div>and how to solve the=
se problems ? =A0just to modify the coarse-grain lock of=A0</div><div>xen s=
ource code in the part to fine-grain lock ?</div>

<div>if so there will be a long time and hard work.</div><div><br></div><di=
v>2. =A0 =A0when I start a vm using vhd , it should mount the vhd file to /=
dev/xvdp in=A0</div><div>dom0 and then this virtual device is encapsulated =
to a vbd object ,finally which</div>

<div>is installed in xenstore by backend process before pygrub is working .=
=A0</div><div>This set-up procedure would=A0cost some time , so if the devi=
ce have not=A0</div><div>prepared when pygrub continues to work , some erro=
rs take place .=A0</div>

<div>I want to know whether i could add a event to notify the frontend that=
 the=A0</div><div>device is completely prepared ?</div><div>and where is th=
e backend code related ?</div>

--f46d044786dfdd8d4004b3a07e6b--


--===============7702662628576339473==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============7702662628576339473==--


From xen-devel-bounces@lists.xensource.com Fri Dec 09 03:38:11 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 03: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.xensource.com>)
	id 1RYrHL-0000Bk-Tb; Fri, 09 Dec 2011 03:37:43 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <shijie1234321@gmail.com>) id 1RYrHK-0000Bb-FO
	for Xen-devel@lists.xensource.com; Fri, 09 Dec 2011 03:37:42 +0000
X-Env-Sender: shijie1234321@gmail.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1323401811!6501235!1
X-Originating-IP: [209.85.161.171]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_10_20,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18025 invoked from network); 9 Dec 2011 03:36:53 -0000
Received: from mail-gx0-f171.google.com (HELO mail-gx0-f171.google.com)
	(209.85.161.171)
	by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 03:36:53 -0000
Received: by ggnh4 with SMTP id h4so8182814ggn.30
	for <Xen-devel@lists.xensource.com>;
	Thu, 08 Dec 2011 19:36:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=Z2ccs9cehTa7FEC5AYA5u0ZlfUzvh4c8By+CG/PbYUQ=;
	b=GO4+WHuY9NUYgXnhBxhEhys1X77MjyeHSWsRsc1tMYy2++bgN9w/BWCEeHXzN2U7xd
	OX/YvVf4BoTI52dIZPXUHqwLddG7w5EXkWVKzAmsc7clTWvg1wTQ7w5xXlXs/UKjB88l
	s68V1qh0MmeMAtq31f+8dtQKOepyEkth+87wE=
MIME-Version: 1.0
Received: by 10.182.145.2 with SMTP id sq2mr96036obb.51.1323401811430; Thu, 08
	Dec 2011 19:36:51 -0800 (PST)
Received: by 10.182.15.193 with HTTP; Thu, 8 Dec 2011 19:36:51 -0800 (PST)
Date: Fri, 9 Dec 2011 11:36:51 +0800
Message-ID: <CADur4tkixSsqbMDudi2n0JgNitJ_ANWDbcp9jJ6QNN12DgM+BQ@mail.gmail.com>
From: Bryant Kobe <shijie1234321@gmail.com>
To: Xen-devel@lists.xensource.com
Subject: [Xen-devel] how to start vms concurrently and how to add a event ?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============7702662628576339473=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============7702662628576339473==
Content-Type: multipart/alternative; boundary=f46d044786dfdd8d4004b3a07e6b

--f46d044786dfdd8d4004b3a07e6b
Content-Type: text/plain; charset=ISO-8859-1

Hello  list ,

1.   I find that some errors would be raised when to start vms concurrently
,
and find there is a coarse-grain lock in start code of xend written in
python,
but in XendBootloader.py there is a little time to release and then
re-aquire
the lock .
I want to know whether which is why errors occur when starting
concurrently .
and how to solve these problems ?  just to modify the coarse-grain lock of
xen source code in the part to fine-grain lock ?
if so there will be a long time and hard work.

2.    when I start a vm using vhd , it should mount the vhd file to
/dev/xvdp in
dom0 and then this virtual device is encapsulated to a vbd object ,finally
which
is installed in xenstore by backend process before pygrub is working .
This set-up procedure would cost some time , so if the device have not
prepared when pygrub continues to work , some errors take place .
I want to know whether i could add a event to notify the frontend that the
device is completely prepared ?
and where is the backend code related ?

--f46d044786dfdd8d4004b3a07e6b
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hello =A0list ,<div><br></div><div>1. =A0 I find that some errors would be =
raised when to start vms concurrently ,=A0</div><div>and find there is a co=
arse-grain lock in start code of xend written in python,</div><div>but in X=
endBootloader.py there is a little time to release and then re-aquire</div>

<div>the lock .</div><div>I want to know whether which is why errors occur =
when starting=A0</div><div>concurrently .=A0</div><div>and how to solve the=
se problems ? =A0just to modify the coarse-grain lock of=A0</div><div>xen s=
ource code in the part to fine-grain lock ?</div>

<div>if so there will be a long time and hard work.</div><div><br></div><di=
v>2. =A0 =A0when I start a vm using vhd , it should mount the vhd file to /=
dev/xvdp in=A0</div><div>dom0 and then this virtual device is encapsulated =
to a vbd object ,finally which</div>

<div>is installed in xenstore by backend process before pygrub is working .=
=A0</div><div>This set-up procedure would=A0cost some time , so if the devi=
ce have not=A0</div><div>prepared when pygrub continues to work , some erro=
rs take place .=A0</div>

<div>I want to know whether i could add a event to notify the frontend that=
 the=A0</div><div>device is completely prepared ?</div><div>and where is th=
e backend code related ?</div>

--f46d044786dfdd8d4004b3a07e6b--


--===============7702662628576339473==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============7702662628576339473==--


From xen-devel-bounces@lists.xensource.com Fri Dec 09 04:26:29 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 04:26:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYs1x-0000Ui-Oe; Fri, 09 Dec 2011 04:25:53 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RYs1w-0000Ud-J5
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 04:25:52 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1323404703!4844756!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDIwNw==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28445 invoked from network); 9 Dec 2011 04:25:03 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 04:25:03 -0000
X-IronPort-AV: E=Sophos;i="4.71,324,1320624000"; 
   d="scan'208";a="9374879"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 04:25:02 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 04:25:02 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RYs18-0006Oi-GI;
	Fri, 09 Dec 2011 04:25:02 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RYs18-0003ZF-9W;
	Fri, 09 Dec 2011 04:25:02 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10450-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 9 Dec 2011 04:25:02 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing test] 10450: trouble: broken/fail/pass
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10450 xen-4.1-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10450/

Failures and problems with tests :-(

Tests which did not succeed and are blocking:
 test-amd64-i386-rhel6hvm-intel  3 host-install(3)              broken
 test-amd64-amd64-pv           3 host-install(3)              broken
 test-i386-i386-xl-win         3 host-install(3)              broken
 test-amd64-i386-xl-credit2    3 host-install(3)              broken   in 10444
 test-amd64-amd64-xl-winxpsp3  3 host-install(3)              broken   in 10444
 test-amd64-i386-pv            3 host-install(3)              broken   in 10444
 test-i386-i386-win            3 host-install(3)              broken   in 10444

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf      5 xen-boot                    fail pass in 10444
 test-amd64-amd64-xl-sedf-pin 14 guest-localmigrate/x10      fail pass in 10444

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-i386-xend-winxpsp3  7 windows-install              fail  never pass
 test-i386-i386-xl-winxpsp3    7 windows-install              fail   never pass
 test-amd64-i386-xl-win7-amd64  7 windows-install              fail  never pass
 test-amd64-amd64-xl-win7-amd64  7 windows-install              fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install          fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2       fail in 10444 never pass
 test-i386-i386-xl-win        13 guest-stop            fail in 10444 never pass

version targeted for testing:
 xen                  1c89f7d29fbb
baseline version:
 xen                  d9f8316a8291

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               broken  
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          broken  
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        broken  
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   23201:1c89f7d29fbb
tag:         tip
user:        Olaf Hering <olaf@aepfle.de>
date:        Thu Dec 08 16:50:28 2011 +0000
    
    tools: init.d/Linux/xencommons: load evtchn and gntdev modules
    
    There is currently no code in the kernel to trigger autoload of the
    evtchn or gntdev drivers. Load them manually during xencommons start.
    Handle both pvops and xenlinux module names.
    
    Signed-off-by: Olaf Hering <olaf@aepfle.de>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    xen-unstable changeset: 24334:9c8aff308002
    Backport-requested-by: Olaf Hering <olaf@aepfle.de>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   23200:7a4fad2d4b05
user:        Olaf Hering <olaf@aepfle.de>
date:        Thu Dec 08 16:50:16 2011 +0000
    
    tools: init.d/Linux/xencommons: run script only when needed
    
    Currently xencommons prints an error that /proc/xen/capabilities does
    not exist when started on a non-xen kernel.
    
    Update the xencommons script to run only when needed:
    - do not run if /proc/xen does not exist
    - check if /proc/xen/capabilities exists before doing the grep for dom0
    
    Signed-off-by: Olaf Hering <olaf@aepfle.de>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    xen-unstable changeset: 24333:4002e63b188a
    Backport-requested-by: Olaf Hering <olaf@aepfle.de>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   23199:d9f8316a8291
user:        Andrew Cooper <andrew.cooper3@citrix.com>
date:        Tue Dec 06 10:53:12 2011 +0000
    
    KEXEC: fix kexec_get_range_compat to fail vocally.
    
    Fail with -ERANGE rather than silently truncating 64bit values (a
    physical address and size) into 32bit integers for dom0 to consume.
    
    Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
    
    Simplify the bitwise arithmetic a bit.
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    xen-unstable changeset:   24358:9961a6d5356a
    xen-unstable date:        Mon Dec 05 19:42:46 2011 +0000
    
    
========================================
commit 3981d218912e186cb4205ee6732f446c177a36a2
Author: Jean Guyader <jean.guyader@eu.citrix.com>
Date:   Tue Nov 22 18:49:15 2011 +0000

    qemu-xen: Don't redefine libpci (3.1.7) defines.
    
    These values are already defined by the libpci heders in the version
    3.1.7.
    
    PCI_STATUS_66MHZ
    PCI_STATUS_RESERVED2
    PCI_STATUS_FAST_BACK
    PCI_MSIX_TABSIZE
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    (cherry picked from commit 174d92a73a5d5e67c49501383a519021b72a2468)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 04:26:29 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 04:26:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYs1x-0000Ui-Oe; Fri, 09 Dec 2011 04:25:53 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RYs1w-0000Ud-J5
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 04:25:52 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1323404703!4844756!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDIwNw==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28445 invoked from network); 9 Dec 2011 04:25:03 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 04:25:03 -0000
X-IronPort-AV: E=Sophos;i="4.71,324,1320624000"; 
   d="scan'208";a="9374879"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 04:25:02 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 04:25:02 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RYs18-0006Oi-GI;
	Fri, 09 Dec 2011 04:25:02 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RYs18-0003ZF-9W;
	Fri, 09 Dec 2011 04:25:02 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10450-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 9 Dec 2011 04:25:02 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing test] 10450: trouble: broken/fail/pass
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10450 xen-4.1-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10450/

Failures and problems with tests :-(

Tests which did not succeed and are blocking:
 test-amd64-i386-rhel6hvm-intel  3 host-install(3)              broken
 test-amd64-amd64-pv           3 host-install(3)              broken
 test-i386-i386-xl-win         3 host-install(3)              broken
 test-amd64-i386-xl-credit2    3 host-install(3)              broken   in 10444
 test-amd64-amd64-xl-winxpsp3  3 host-install(3)              broken   in 10444
 test-amd64-i386-pv            3 host-install(3)              broken   in 10444
 test-i386-i386-win            3 host-install(3)              broken   in 10444

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf      5 xen-boot                    fail pass in 10444
 test-amd64-amd64-xl-sedf-pin 14 guest-localmigrate/x10      fail pass in 10444

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-i386-xend-winxpsp3  7 windows-install              fail  never pass
 test-i386-i386-xl-winxpsp3    7 windows-install              fail   never pass
 test-amd64-i386-xl-win7-amd64  7 windows-install              fail  never pass
 test-amd64-amd64-xl-win7-amd64  7 windows-install              fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install          fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2       fail in 10444 never pass
 test-i386-i386-xl-win        13 guest-stop            fail in 10444 never pass

version targeted for testing:
 xen                  1c89f7d29fbb
baseline version:
 xen                  d9f8316a8291

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               broken  
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          broken  
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        broken  
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   23201:1c89f7d29fbb
tag:         tip
user:        Olaf Hering <olaf@aepfle.de>
date:        Thu Dec 08 16:50:28 2011 +0000
    
    tools: init.d/Linux/xencommons: load evtchn and gntdev modules
    
    There is currently no code in the kernel to trigger autoload of the
    evtchn or gntdev drivers. Load them manually during xencommons start.
    Handle both pvops and xenlinux module names.
    
    Signed-off-by: Olaf Hering <olaf@aepfle.de>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    xen-unstable changeset: 24334:9c8aff308002
    Backport-requested-by: Olaf Hering <olaf@aepfle.de>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   23200:7a4fad2d4b05
user:        Olaf Hering <olaf@aepfle.de>
date:        Thu Dec 08 16:50:16 2011 +0000
    
    tools: init.d/Linux/xencommons: run script only when needed
    
    Currently xencommons prints an error that /proc/xen/capabilities does
    not exist when started on a non-xen kernel.
    
    Update the xencommons script to run only when needed:
    - do not run if /proc/xen does not exist
    - check if /proc/xen/capabilities exists before doing the grep for dom0
    
    Signed-off-by: Olaf Hering <olaf@aepfle.de>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    xen-unstable changeset: 24333:4002e63b188a
    Backport-requested-by: Olaf Hering <olaf@aepfle.de>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   23199:d9f8316a8291
user:        Andrew Cooper <andrew.cooper3@citrix.com>
date:        Tue Dec 06 10:53:12 2011 +0000
    
    KEXEC: fix kexec_get_range_compat to fail vocally.
    
    Fail with -ERANGE rather than silently truncating 64bit values (a
    physical address and size) into 32bit integers for dom0 to consume.
    
    Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
    
    Simplify the bitwise arithmetic a bit.
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    xen-unstable changeset:   24358:9961a6d5356a
    xen-unstable date:        Mon Dec 05 19:42:46 2011 +0000
    
    
========================================
commit 3981d218912e186cb4205ee6732f446c177a36a2
Author: Jean Guyader <jean.guyader@eu.citrix.com>
Date:   Tue Nov 22 18:49:15 2011 +0000

    qemu-xen: Don't redefine libpci (3.1.7) defines.
    
    These values are already defined by the libpci heders in the version
    3.1.7.
    
    PCI_STATUS_66MHZ
    PCI_STATUS_RESERVED2
    PCI_STATUS_FAST_BACK
    PCI_MSIX_TABSIZE
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    (cherry picked from commit 174d92a73a5d5e67c49501383a519021b72a2468)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 05:21:37 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 05:21:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYssp-0000ye-V7; Fri, 09 Dec 2011 05:20:31 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <annie.li@oracle.com>) id 1RYsso-0000yZ-6o
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 05:20:30 +0000
X-Env-Sender: annie.li@oracle.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1323407979!1944773!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDI1MDkx\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32710 invoked from network); 9 Dec 2011 05:19:41 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-8.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 9 Dec 2011 05:19:41 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pB95JahE018874
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 9 Dec 2011 05:19:37 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pB95JXOm011616
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 9 Dec 2011 05:19:34 GMT
Received: from abhmt117.oracle.com (abhmt117.oracle.com [141.146.116.69])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pB95JQRF016051; Thu, 8 Dec 2011 23:19:26 -0600
Received: from [10.191.9.5] (/10.191.9.5)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 08 Dec 2011 21:19:26 -0800
Message-ID: <4EE19A4D.9030500@oracle.com>
Date: Fri, 09 Dec 2011 13:19:09 +0800
From: annie li <annie.li@oracle.com>
Organization: Oracle Corporation
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
MIME-Version: 1.0
To: Paul Durrant <Paul.Durrant@citrix.com>
References: <1323336940-5382-1-git-send-email-annie.li@oracle.com>
	<1323337048-5426-1-git-send-email-annie.li@oracle.com>
	<291EDFCB1E9E224A99088639C4762022B5988E5528@LONPMAILBOX01.citrite.net>
	<4EE08B0D.80504@oracle.com>
	<291EDFCB1E9E224A99088639C4762022B5988E552D@LONPMAILBOX01.citrite.net>
In-Reply-To: <291EDFCB1E9E224A99088639C4762022B5988E552D@LONPMAILBOX01.citrite.net>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090208.4EE19A69.0064,ss=1,re=0.000,fgs=0
Cc: "jeremy@goop.org" <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	"kurt.hackel@oracle.com" <kurt.hackel@oracle.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [Xen-devel] [PATCH V2 1/2] xen/granttable: Support sub-page
	grants
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi Paul,

>>> #define get_free_entry()	get_free_entries(1)
Is this necessary? Maybe you defined this to keep consistence with 
put_free_entry(ref)?
But other functions such as gnttab_grant_foreign_transfer and 
gnttab_grant_foreign_access all call get_free_entries(1). Maybe it is 
better to keep initial get_free_entries(1) code?

Thanks
Annie

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 05:21:37 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 05:21:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYssp-0000ye-V7; Fri, 09 Dec 2011 05:20:31 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <annie.li@oracle.com>) id 1RYsso-0000yZ-6o
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 05:20:30 +0000
X-Env-Sender: annie.li@oracle.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1323407979!1944773!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDI1MDkx\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32710 invoked from network); 9 Dec 2011 05:19:41 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-8.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 9 Dec 2011 05:19:41 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pB95JahE018874
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 9 Dec 2011 05:19:37 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pB95JXOm011616
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 9 Dec 2011 05:19:34 GMT
Received: from abhmt117.oracle.com (abhmt117.oracle.com [141.146.116.69])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pB95JQRF016051; Thu, 8 Dec 2011 23:19:26 -0600
Received: from [10.191.9.5] (/10.191.9.5)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 08 Dec 2011 21:19:26 -0800
Message-ID: <4EE19A4D.9030500@oracle.com>
Date: Fri, 09 Dec 2011 13:19:09 +0800
From: annie li <annie.li@oracle.com>
Organization: Oracle Corporation
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
MIME-Version: 1.0
To: Paul Durrant <Paul.Durrant@citrix.com>
References: <1323336940-5382-1-git-send-email-annie.li@oracle.com>
	<1323337048-5426-1-git-send-email-annie.li@oracle.com>
	<291EDFCB1E9E224A99088639C4762022B5988E5528@LONPMAILBOX01.citrite.net>
	<4EE08B0D.80504@oracle.com>
	<291EDFCB1E9E224A99088639C4762022B5988E552D@LONPMAILBOX01.citrite.net>
In-Reply-To: <291EDFCB1E9E224A99088639C4762022B5988E552D@LONPMAILBOX01.citrite.net>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090208.4EE19A69.0064,ss=1,re=0.000,fgs=0
Cc: "jeremy@goop.org" <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	"kurt.hackel@oracle.com" <kurt.hackel@oracle.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [Xen-devel] [PATCH V2 1/2] xen/granttable: Support sub-page
	grants
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi Paul,

>>> #define get_free_entry()	get_free_entries(1)
Is this necessary? Maybe you defined this to keep consistence with 
put_free_entry(ref)?
But other functions such as gnttab_grant_foreign_transfer and 
gnttab_grant_foreign_access all call get_free_entries(1). Maybe it is 
better to keep initial get_free_entries(1) code?

Thanks
Annie

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 05:23:29 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 05:23:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYsuw-00013B-HD; Fri, 09 Dec 2011 05:22:42 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RYsuv-00012t-1l
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 05:22:41 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1323408111!6730611!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDIwNw==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17410 invoked from network); 9 Dec 2011 05:21:52 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 05:21:52 -0000
X-IronPort-AV: E=Sophos;i="4.71,324,1320624000"; 
   d="scan'208";a="9375310"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 05:21:51 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 05:21:51 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RYsu7-0006hf-BQ;
	Fri, 09 Dec 2011 05:21:51 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RYsu7-0005TD-Ar;
	Fri, 09 Dec 2011 05:21:51 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10454-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 9 Dec 2011 05:21:51 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10454: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10454 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10454/

Regressions :-(

Tests which did not succeed and are blocking:
 test-i386-i386-xl-winxpsp3    3 host-install(3)              broken   in 10446
 test-amd64-i386-rhel6hvm-intel  3 host-install(3)              broken in 10446
 test-amd64-i386-xl-multivcpu  3 host-install(3)              broken   in 10446
 test-amd64-amd64-xl-sedf      3 host-install(3)              broken   in 10446
 test-amd64-amd64-xl-win       7 windows-install  fail in 10446 REGR. vs. 10201
 test-amd64-i386-xl-win-vcpus1  7 windows-install fail in 10446 REGR. vs. 10201

Tests which are failing intermittently (not blocking):
 build-amd64-oldkern           4 xen-build                   fail pass in 10446
 build-amd64                   4 xen-build                   fail pass in 10446
 build-amd64-pvops             4 kernel-build                fail pass in 10446
 test-i386-i386-xl-win         7 windows-install    fail in 10446 pass in 10454

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-winxpsp3    7 windows-install              fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf-pin  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win       1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start        fail in 10446 never pass
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install fail in 10446 never pass
 test-amd64-i386-xl-win7-amd64  7 windows-install      fail in 10446 never pass
 test-amd64-i386-xend-winxpsp3  7 windows-install      fail in 10446 never pass
 test-amd64-amd64-xl-win7-amd64  7 windows-install     fail in 10446 never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2         fail in 10446 never pass
 test-amd64-amd64-xl-winxpsp3  7 windows-install       fail in 10446 never pass
 test-amd64-i386-win          16 leak-check/check      fail in 10446 never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check      fail in 10446 never pass
 test-amd64-amd64-win         16 leak-check/check      fail in 10446 never pass

version targeted for testing:
 xen                  1c58bb664d8d
baseline version:
 xen                  62ff6a318c5d

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scanneel.ca>
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Andres Lagar-Cavilla <andres@lagarcavilla>
  Andrew Cooper <andrew.cooper3@citrix.com>
  Anthony PERARD <anthony.perard@citrix.com>
  Brendan Cully <brendan@cs.ubc.ca>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Haitao Shan <haitao.shan@intel.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@novell.com>
  Jan Beulich <jbeulich@suse.com>
  Jonathan Davies <jonathan.davies@citrix.com>
  juergen.gross@ts.fujitsu.com
  Keir Fraser <keir@xen.org>
  Liu, Jinsong <jinsong.liu@intel.com>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
  Philipp Hahn <hahn@univention.de>
  Shriram Rajagopalan <rshriram@cs.ubc.ca>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang2 <wei.wang2@amd.com>
  Xudong Hao <xudong.hao@intel.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  fail    
 build-i386                                                   pass    
 build-amd64-oldkern                                          fail    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            fail    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          blocked 
 test-amd64-i386-xl                                           blocked 
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-amd64-xl-win7-amd64                               blocked 
 test-amd64-i386-xl-win7-amd64                                blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-amd64-xl-pcipt-intel                              blocked 
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        blocked 
 test-amd64-i386-pair                                         blocked 
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 blocked 
 test-amd64-amd64-pv                                          blocked 
 test-amd64-i386-pv                                           blocked 
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     blocked 
 test-amd64-i386-win-vcpus1                                   blocked 
 test-amd64-i386-xl-win-vcpus1                                blocked 
 test-amd64-i386-xl-winxpsp3-vcpus1                           blocked 
 test-amd64-amd64-win                                         blocked 
 test-amd64-i386-win                                          blocked 
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      blocked 
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-xl-winxpsp3                                 blocked 
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 1522 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 05:23:29 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 05:23:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYsuw-00013B-HD; Fri, 09 Dec 2011 05:22:42 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RYsuv-00012t-1l
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 05:22:41 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1323408111!6730611!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDIwNw==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17410 invoked from network); 9 Dec 2011 05:21:52 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 05:21:52 -0000
X-IronPort-AV: E=Sophos;i="4.71,324,1320624000"; 
   d="scan'208";a="9375310"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 05:21:51 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 05:21:51 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RYsu7-0006hf-BQ;
	Fri, 09 Dec 2011 05:21:51 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RYsu7-0005TD-Ar;
	Fri, 09 Dec 2011 05:21:51 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10454-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 9 Dec 2011 05:21:51 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10454: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10454 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10454/

Regressions :-(

Tests which did not succeed and are blocking:
 test-i386-i386-xl-winxpsp3    3 host-install(3)              broken   in 10446
 test-amd64-i386-rhel6hvm-intel  3 host-install(3)              broken in 10446
 test-amd64-i386-xl-multivcpu  3 host-install(3)              broken   in 10446
 test-amd64-amd64-xl-sedf      3 host-install(3)              broken   in 10446
 test-amd64-amd64-xl-win       7 windows-install  fail in 10446 REGR. vs. 10201
 test-amd64-i386-xl-win-vcpus1  7 windows-install fail in 10446 REGR. vs. 10201

Tests which are failing intermittently (not blocking):
 build-amd64-oldkern           4 xen-build                   fail pass in 10446
 build-amd64                   4 xen-build                   fail pass in 10446
 build-amd64-pvops             4 kernel-build                fail pass in 10446
 test-i386-i386-xl-win         7 windows-install    fail in 10446 pass in 10454

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-winxpsp3    7 windows-install              fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf-pin  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win       1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start        fail in 10446 never pass
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install fail in 10446 never pass
 test-amd64-i386-xl-win7-amd64  7 windows-install      fail in 10446 never pass
 test-amd64-i386-xend-winxpsp3  7 windows-install      fail in 10446 never pass
 test-amd64-amd64-xl-win7-amd64  7 windows-install     fail in 10446 never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2         fail in 10446 never pass
 test-amd64-amd64-xl-winxpsp3  7 windows-install       fail in 10446 never pass
 test-amd64-i386-win          16 leak-check/check      fail in 10446 never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check      fail in 10446 never pass
 test-amd64-amd64-win         16 leak-check/check      fail in 10446 never pass

version targeted for testing:
 xen                  1c58bb664d8d
baseline version:
 xen                  62ff6a318c5d

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scanneel.ca>
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Andres Lagar-Cavilla <andres@lagarcavilla>
  Andrew Cooper <andrew.cooper3@citrix.com>
  Anthony PERARD <anthony.perard@citrix.com>
  Brendan Cully <brendan@cs.ubc.ca>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Haitao Shan <haitao.shan@intel.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@novell.com>
  Jan Beulich <jbeulich@suse.com>
  Jonathan Davies <jonathan.davies@citrix.com>
  juergen.gross@ts.fujitsu.com
  Keir Fraser <keir@xen.org>
  Liu, Jinsong <jinsong.liu@intel.com>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
  Philipp Hahn <hahn@univention.de>
  Shriram Rajagopalan <rshriram@cs.ubc.ca>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang2 <wei.wang2@amd.com>
  Xudong Hao <xudong.hao@intel.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  fail    
 build-i386                                                   pass    
 build-amd64-oldkern                                          fail    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            fail    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          blocked 
 test-amd64-i386-xl                                           blocked 
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-amd64-xl-win7-amd64                               blocked 
 test-amd64-i386-xl-win7-amd64                                blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-amd64-xl-pcipt-intel                              blocked 
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        blocked 
 test-amd64-i386-pair                                         blocked 
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 blocked 
 test-amd64-amd64-pv                                          blocked 
 test-amd64-i386-pv                                           blocked 
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     blocked 
 test-amd64-i386-win-vcpus1                                   blocked 
 test-amd64-i386-xl-win-vcpus1                                blocked 
 test-amd64-i386-xl-winxpsp3-vcpus1                           blocked 
 test-amd64-amd64-win                                         blocked 
 test-amd64-i386-win                                          blocked 
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      blocked 
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-xl-winxpsp3                                 blocked 
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 1522 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 06:04:12 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 06:04:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYtYX-0001UF-28; Fri, 09 Dec 2011 06:03:37 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <haitao.shan@intel.com>) id 1RYtYV-0001U7-Q8
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 06:03:36 +0000
X-Env-Sender: haitao.shan@intel.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1323410543!6505981!1
X-Originating-IP: [143.182.124.37]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjA3NjE4\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14948 invoked from network); 9 Dec 2011 06:02:24 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37)
	by server-14.tower-182.messagelabs.com with SMTP;
	9 Dec 2011 06:02:24 -0000
Received: from azsmga002.ch.intel.com ([10.2.17.35])
	by azsmga102.ch.intel.com with ESMTP; 08 Dec 2011 22:02:22 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; 
	d="p7s'?scan'208";a="45503139"
Received: from pgsmsx602.gar.corp.intel.com ([10.221.43.81])
	by AZSMGA002.ch.intel.com with ESMTP; 08 Dec 2011 22:02:20 -0800
Received: from shsmsx602.ccr.corp.intel.com (10.239.4.104) by
	pgsmsx602.gar.corp.intel.com (10.221.43.81) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Fri, 9 Dec 2011 14:01:58 +0800
Received: from shsmsx502.ccr.corp.intel.com ([10.239.4.96]) by
	SHSMSX602.ccr.corp.intel.com ([10.239.4.104]) with mapi; Fri, 9 Dec 2011
	14:01:57 +0800
From: "Shan, Haitao" <haitao.shan@intel.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>, Jan Beulich
	<JBeulich@suse.com>
Date: Fri, 9 Dec 2011 14:01:56 +0800
Thread-Topic: [Xen-devel] [PATCH] Qemu MSI Cleaning Up
Thread-Index: Acy0SjR4SbYOllHxS6uDPoGOn5Jx2gB7c3Bg
Message-ID: <04F972F38B3C4E4E91C4697DA8BF9F52846C7517E8@shsmsx502.ccr.corp.intel.com>
References: <CAFQ2Z+fpR1UkxFEAYTD6irBUBeA3c7eJ3x1bXE0jzpdfQtH64w@mail.gmail.com>
	<alpine.DEB.2.00.1112021223190.31179@kaball-desktop>
	<4EDE367D0200007800065B6B@nat28.tlf.novell.com>
	<alpine.DEB.2.00.1112061906550.31179@kaball-desktop>
In-Reply-To: <alpine.DEB.2.00.1112061906550.31179@kaball-desktop>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: Haitao Shan <maillists.shan@gmail.com>, "Keir \(Xen.org\)" <keir@xen.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] Qemu MSI Cleaning Up
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3012934755746700410=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============3012934755746700410==
Content-Language: en-US
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature";
	micalg=SHA1; boundary="----=_NextPart_000_00C7_01CCB67B.1C5AFF20"

------=_NextPart_000_00C7_01CCB67B.1C5AFF20
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Fine to me! Thanks, Jan!

Shan Haitao

> -----Original Message-----
> From: Stefano Stabellini [mailto:stefano.stabellini@eu.citrix.com]
> Sent: Wednesday, December 07, 2011 3:08 AM
> To: Jan Beulich
> Cc: Stefano Stabellini; Haitao Shan; Ian Jackson; Shan, Haitao; xen-
> devel@lists.xensource.com; Keir (Xen.org)
> Subject: Re: [Xen-devel] [PATCH] Qemu MSI Cleaning Up
> 
> On Tue, 6 Dec 2011, Jan Beulich wrote:
> > >>> On 02.12.11 at 13:40, Stefano Stabellini
> <stefano.stabellini@eu.citrix.com> wrote:
> > > The two mapping and unmapping big chuncks of code looks very similar
> > > apart from the DPCI_ADD_MAPPING/DPCI_REMOVE_MAPPING
> parameter.
> > > Could they be refactored into a single function called
> > > "change_msix_mappings"?
> > > This is more or less what I have in mind:
> > >
> > > change_msix_mappings(assigned_device, DPCI_REMOVE_MAPPING);
> > >
> > > update mmio_base_addr
> > >
> > > change_msix_mappings(assigned_device, DPCI_ADD_MAPPING);
> >
> > Please see below/attached for the outcome. Without MSI-X capable
> > devices to pass through, I have to rely on others to do some testing
> > on this.
> 
> It looks fine.
> Haitao, are you happy with the new patch?

------=_NextPart_000_00C7_01CCB67B.1C5AFF20
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIYUDCCAyAw
ggKJoAMCAQICBDXe9M8wDQYJKoZIhvcNAQEFBQAwTjELMAkGA1UEBhMCVVMxEDAOBgNVBAoTB0Vx
dWlmYXgxLTArBgNVBAsTJEVxdWlmYXggU2VjdXJlIENlcnRpZmljYXRlIEF1dGhvcml0eTAeFw05
ODA4MjIxNjQxNTFaFw0xODA4MjIxNjQxNTFaME4xCzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVp
ZmF4MS0wKwYDVQQLEyRFcXVpZmF4IFNlY3VyZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwgZ8wDQYJ
KoZIhvcNAQEBBQADgY0AMIGJAoGBAMFdsVhnCGLuoJotHwhtkRRomAoe/toEbxOEYiHD0XzOnwXg
uAHwTjTs4oqVBGSs8WtTXwWzy2eAv0ICjv7dAQns4QAUT/z78AzdQ7pbK+EfgHCZFVeTFvEPl2q3
wmgjHMxNWTCsUR47ryvW7mNFe8XZX1DS41APOojnvxT94Me5AgMBAAGjggEJMIIBBTBwBgNVHR8E
aTBnMGWgY6BhpF8wXTELMAkGA1UEBhMCVVMxEDAOBgNVBAoTB0VxdWlmYXgxLTArBgNVBAsTJEVx
dWlmYXggU2VjdXJlIENlcnRpZmljYXRlIEF1dGhvcml0eTENMAsGA1UEAxMEQ1JMMTAaBgNVHRAE
EzARgQ8yMDE4MDgyMjE2NDE1MVowCwYDVR0PBAQDAgEGMB8GA1UdIwQYMBaAFEjmaPkr0rKV10fY
IyAQTzOYkJ/UMB0GA1UdDgQWBBRI5mj5K9KylddH2CMgEE8zmJCf1DAMBgNVHRMEBTADAQH/MBoG
CSqGSIb2fQdBAAQNMAsbBVYzLjBjAwIGwDANBgkqhkiG9w0BAQUFAAOBgQBYzinq/Pfetc4CuRe1
hdG54+CVzCUxDQCmkm5/tpJjnlCV0Zpv5BHeY4VumO6o/1rI01WyZnFX3sAh6z0qpyNJAQSGQnv8
7n+iFlK1Z2fTQNs7JliyKHc9rhR3Ydb6KmYnoA36p3Nc6nDxlCFlRF/6/O8paKmih3nvee9PrAd3
ODCCAz0wggKmoAMCAQICAwWw/zANBgkqhkiG9w0BAQUFADBOMQswCQYDVQQGEwJVUzEQMA4GA1UE
ChMHRXF1aWZheDEtMCsGA1UECxMkRXF1aWZheCBTZWN1cmUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5
MB4XDTA2MDIxNjE4MDEzMFoXDTE2MDIxOTE4MDEzMFowUjELMAkGA1UEBhMCVVMxGjAYBgNVBAoT
EUludGVsIENvcnBvcmF0aW9uMScwJQYDVQQDEx5JbnRlbCBFeHRlcm5hbCBCYXNpYyBQb2xpY3kg
Q0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDBpd/XOb9QVqEZ8mQ1042TdOIq3ATD
IsV2xDyt30yLyMR5Wjtus0bn3B+he89BiNO/LP6+rFzEwlD55PlX+HLGIKeNNG97dqyc30FElEUj
ZzTZFq2N4e3kVJ/XAEEgANzV8v9qp7qWwxugPgfc3z9BkYot+CifozexHLb/hEZj+yISCU61kRZv
uSQ0E11yYL4dRgcglJeaHo3oX57rvIckaLsYV5/1Aj+R8DM1Ppk965XQAKsHfnyT7C4S50T4lVn4
lz36wOdNZn/zegG1zp41lnoTFfT4KuKVJH5x7YD1p6KbgJCKLovnujGuohquBNfdXKpZkvz6pGv+
iC1HawJdAgMBAAGjgaAwgZ0wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBQaxgxKxEdvqNutK/D0
Vgaj7TdUDDA6BgNVHR8EMzAxMC+gLaArhilodHRwOi8vY3JsLmdlb3RydXN0LmNvbS9jcmxzL3Nl
Y3VyZWNhLmNybDAfBgNVHSMEGDAWgBRI5mj5K9KylddH2CMgEE8zmJCf1DAPBgNVHRMBAf8EBTAD
AQH/MA0GCSqGSIb3DQEBBQUAA4GBABMQOK2kVKVIlUWwLTdywJ+e2O+PC/uQltK2F3lRyrPfBn69
tOkIP4SgDJOfsxyobIrPLe75kBLw+Dom13OBDp/EMZJZ1CglQfVV8co9mT3aZMjSGGQiMgkJLR3j
Mfr900fXZKj5XeqCJ+JP0mEhJGEdVCY+FFlksJjV86fDrq1QMIIFijCCBHKgAwIBAgIKYSCKYgAA
AAAACDANBgkqhkiG9w0BAQUFADBSMQswCQYDVQQGEwJVUzEaMBgGA1UEChMRSW50ZWwgQ29ycG9y
YXRpb24xJzAlBgNVBAMTHkludGVsIEV4dGVybmFsIEJhc2ljIFBvbGljeSBDQTAeFw0wOTA1MTUx
OTI3MjZaFw0xNTA1MTUxOTM3MjZaMFYxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFJbnRlbCBDb3Jw
b3JhdGlvbjErMCkGA1UEAxMiSW50ZWwgRXh0ZXJuYWwgQmFzaWMgSXNzdWluZyBDQSAzQjCCASIw
DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKQEM1Wn9TU9vc9C+/Tc7KB+eiYElmrcEWE32WUd
HvWG+IcQHVQsikTmMyKKojNLw2B5s6Iekc8ivDo/wCfjZzX9JyftMnc+AArc0la87Olybzm8K9jX
EfTBvTnUSFSiI9ZYefITdiUgqlAFuljFZEHYKYtLuhrRacpmQfP4mV63NKdc2bT804HRf6YptZFa
4k6YN94zlrGNrBuQQ74WFzz/jLBusbUpEkro6Mu/ZYFOFWQrV9lBhF9Ruk8yN+3N6n9fUo/qBigi
F2kEn9xVh1ykl7SCGL2jBUkXx4qgV27a6Si8lRRdgrHGtN/HWnSWlLXTH5l575H4Lq++77OFv38C
AwEAAaOCAlwwggJYMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFA7GKvdZsggQkCVvw939imYx
MCvFMAsGA1UdDwQEAwIBhjASBgkrBgEEAYI3FQEEBQIDAQABMCMGCSsGAQQBgjcVAgQWBBQ5oFY2
ekKQ/5Ktim+VdMeSWb4QWTAZBgkrBgEEAYI3FAIEDB4KAFMAdQBiAEMAQTAfBgNVHSMEGDAWgBQa
xgxKxEdvqNutK/D0Vgaj7TdUDDCBvQYDVR0fBIG1MIGyMIGvoIGsoIGphk5odHRwOi8vd3d3Lmlu
dGVsLmNvbS9yZXBvc2l0b3J5L0NSTC9JbnRlbCUyMEV4dGVybmFsJTIwQmFzaWMlMjBQb2xpY3kl
MjBDQS5jcmyGV2h0dHA6Ly9jZXJ0aWZpY2F0ZXMuaW50ZWwuY29tL3JlcG9zaXRvcnkvQ1JML0lu
dGVsJTIwRXh0ZXJuYWwlMjBCYXNpYyUyMFBvbGljeSUyMENBLmNybDCB4wYIKwYBBQUHAQEEgdYw
gdMwYwYIKwYBBQUHMAKGV2h0dHA6Ly93d3cuaW50ZWwuY29tL3JlcG9zaXRvcnkvY2VydGlmaWNh
dGVzL0ludGVsJTIwRXh0ZXJuYWwlMjBCYXNpYyUyMFBvbGljeSUyMENBLmNydDBsBggrBgEFBQcw
AoZgaHR0cDovL2NlcnRpZmljYXRlcy5pbnRlbC5jb20vcmVwb3NpdG9yeS9jZXJ0aWZpY2F0ZXMv
SW50ZWwlMjBFeHRlcm5hbCUyMEJhc2ljJTIwUG9saWN5JTIwQ0EuY3J0MA0GCSqGSIb3DQEBBQUA
A4IBAQCxtQEHchVQhXyjEqtMVUMe6gkmPsIczHxSeqNbo9dsD+6xbT65JT+oYgpIAtfEsYXeUJu1
cChqpb22U5bMAz7eaQcW5bzefufWvA6lg2048B8oczBj/q+5P5NpYrUO8jOmN4jTjfJq3ElZ7yFW
py7rB3Vm/aN6ATYqWfMbS/xfh+JCxmH3droUmMJI0/aZJHsLtjbjFnNsHDNrJZX1vxlM78Lb1hjs
kTENPmhbVbfTj5i/ZGnhv4tmI8QZPCNtcegXJrfhRl2D9bWpdTOPrWiLDUqzy1Z6KL7TcOS/PCl8
RHCJXkPau/thTQCpIoDa2+c+3XA++gRTfAQ4svTO260NMIIGBzCCBO+gAwIBAgIKEx06gQABAAB7
rTANBgkqhkiG9w0BAQUFADBWMQswCQYDVQQGEwJVUzEaMBgGA1UEChMRSW50ZWwgQ29ycG9yYXRp
b24xKzApBgNVBAMTIkludGVsIEV4dGVybmFsIEJhc2ljIElzc3VpbmcgQ0EgM0IwHhcNMTExMDEy
MDEyNDIwWhcNMTQwOTI2MDEyNDIwWjA9MRUwEwYDVQQDEwxTaGFuLCBIYWl0YW8xJDAiBgkqhkiG
9w0BCQEWFWhhaXRhby5zaGFuQGludGVsLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC
ggEBALpHYbXkMy06K6Pl9IGxbsKl0zT/OYd523Rh3CX7tHG/80ZGcPeLlzFK+l+30Fhpzf8fsFwG
l5fX2pRtWqT96BUWecXEVJhisfa1Wrq7DBC6coxEnExFADU+2UsBQ/ACKFSCiq/fADojyFWJgPKv
4PLDKJ9LU23Q+g1WRruGHfBnhCMv0KxnkE7pTk3cFRXtNUSUnYLqcvrZwt9VogQNiNNw3jMlDb8t
bJjMsXdhrwqFGW49z/gAJ2Mnr6/lNnqBdcKF2Qm28SfYXRohGrmam3KReM49ZG0+J/+JPF5drbiw
UAV++PMHA3IXIvZF2c66jQM5BzbF93SkoZXmrQZA2jMCAwEAAaOCAu4wggLqMAsGA1UdDwQEAwIH
gDA8BgkrBgEEAYI3FQcELzAtBiUrBgEEAYI3FQiGw4x1hJnlUYP9gSiFjp9TgpHACWeB3r05lfBD
AgFkAgEIMB0GA1UdDgQWBBQ/OInBCgrko9ziRWiEhjM+SyeeoDAfBgNVHSMEGDAWgBQOxir3WbII
EJAlb8Pd/YpmMTArxTCBzwYDVR0fBIHHMIHEMIHBoIG+oIG7hldodHRwOi8vd3d3LmludGVsLmNv
bS9yZXBvc2l0b3J5L0NSTC9JbnRlbCUyMEV4dGVybmFsJTIwQmFzaWMlMjBJc3N1aW5nJTIwQ0El
MjAzQigxKS5jcmyGYGh0dHA6Ly9jZXJ0aWZpY2F0ZXMuaW50ZWwuY29tL3JlcG9zaXRvcnkvQ1JM
L0ludGVsJTIwRXh0ZXJuYWwlMjBCYXNpYyUyMElzc3VpbmclMjBDQSUyMDNCKDEpLmNybDCB9QYI
KwYBBQUHAQEEgegwgeUwbAYIKwYBBQUHMAKGYGh0dHA6Ly93d3cuaW50ZWwuY29tL3JlcG9zaXRv
cnkvY2VydGlmaWNhdGVzL0ludGVsJTIwRXh0ZXJuYWwlMjBCYXNpYyUyMElzc3VpbmclMjBDQSUy
MDNCKDEpLmNydDB1BggrBgEFBQcwAoZpaHR0cDovL2NlcnRpZmljYXRlcy5pbnRlbC5jb20vcmVw
b3NpdG9yeS9jZXJ0aWZpY2F0ZXMvSW50ZWwlMjBFeHRlcm5hbCUyMEJhc2ljJTIwSXNzdWluZyUy
MENBJTIwM0IoMSkuY3J0MB8GA1UdJQQYMBYGCCsGAQUFBwMEBgorBgEEAYI3CgMMMCkGCSsGAQQB
gjcVCgQcMBowCgYIKwYBBQUHAwQwDAYKKwYBBAGCNwoDDDBHBgNVHREEQDA+oCUGCisGAQQBgjcU
AgOgFwwVaGFpdGFvLnNoYW5AaW50ZWwuY29tgRVoYWl0YW8uc2hhbkBpbnRlbC5jb20wDQYJKoZI
hvcNAQEFBQADggEBAG5Us26ruu8jKt3RhZuirjqgF61p+wZer/xV6BTABUx5++DhWXslTztavsvy
JZ5WsZ7xaijBUO3UQViWTylwmSyGwbhEwreu3XRNGlMOnRk+sH7JGiXZJIpqoD/jtRWp0ypHG2g3
nDqAQ1/j4wUgcI0b12KUJyYAeN6cwEeAqIV4mdD8GpH3DS2nZbEZjTNhkaeJuT7lO1jRqzEGOSCk
KDHPfqUtqpw+wZa6mFbzSso9swc4ypgRIl4l5i/4OwNMQazHm2O6Ov91aDJs6j3DCdALzP736hmF
QFfHWL34GFQMRdpO/OI6z/Q0VYm/6N9o4SD/s4J9Edq8zyYNQxBR03QwggZOMIIFNqADAgECAgoT
I00xAAEAAHuuMA0GCSqGSIb3DQEBBQUAMFYxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFJbnRlbCBD
b3Jwb3JhdGlvbjErMCkGA1UEAxMiSW50ZWwgRXh0ZXJuYWwgQmFzaWMgSXNzdWluZyBDQSAzQjAe
Fw0xMTEwMTIwMTMwNTZaFw0xNDA5MjYwMTMwNTZaMD0xFTATBgNVBAMTDFNoYW4sIEhhaXRhbzEk
MCIGCSqGSIb3DQEJARYVaGFpdGFvLnNoYW5AaW50ZWwuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOC
AQ8AMIIBCgKCAQEApaOcuQtYCobUiLQTadd0Hi+U/ausgzeSE59iUrc57VUzvLsLNnKRxLPm+T26
KN9fMDAS3/MZOl5tf+9mKEwrergim5GzwJpfZWPLAyK2Gs57+F+BMgtX6DT0eh4sGQLQDahPZDhy
Ubo420AiTGuTA9/L22B/qbPNuDRNMMJoreAZeSNBSVPa7Q+Y0oXcfKpAmKzHH2Y+WAzupN5jfxhJ
6yb7MpsPDqoU0Ek4VttgUIl4AQlRFMI18ScKvAG2p9kWSSgq+Z9xdQl7F/3ASkXlQMKEOHCDw8E7
XUzqy4pOoXGaI3FVI4AerPeLgz2SkNINfqLnxdhN+BQ6iuRgsOeyIwIDAQABo4IDNTCCAzEwCwYD
VR0PBAQDAgQwMD0GCSsGAQQBgjcVBwQwMC4GJisGAQQBgjcVCIbDjHWEmeVRg/2BKIWOn1OCkcAJ
Z4S52UGHhP9OAgFkAgEMMEQGCSqGSIb3DQEJDwQ3MDUwDgYIKoZIhvcNAwICAgCAMA4GCCqGSIb3
DQMEAgIAgDAHBgUrDgMCBzAKBggqhkiG9w0DBzAdBgNVHQ4EFgQU/+6IdpvPrUveCml7StYwqL40
iqMwHwYDVR0jBBgwFoAUDsYq91myCBCQJW/D3f2KZjEwK8Uwgc8GA1UdHwSBxzCBxDCBwaCBvqCB
u4ZXaHR0cDovL3d3dy5pbnRlbC5jb20vcmVwb3NpdG9yeS9DUkwvSW50ZWwlMjBFeHRlcm5hbCUy
MEJhc2ljJTIwSXNzdWluZyUyMENBJTIwM0IoMSkuY3JshmBodHRwOi8vY2VydGlmaWNhdGVzLmlu
dGVsLmNvbS9yZXBvc2l0b3J5L0NSTC9JbnRlbCUyMEV4dGVybmFsJTIwQmFzaWMlMjBJc3N1aW5n
JTIwQ0ElMjAzQigxKS5jcmwwgfUGCCsGAQUFBwEBBIHoMIHlMGwGCCsGAQUFBzAChmBodHRwOi8v
d3d3LmludGVsLmNvbS9yZXBvc2l0b3J5L2NlcnRpZmljYXRlcy9JbnRlbCUyMEV4dGVybmFsJTIw
QmFzaWMlMjBJc3N1aW5nJTIwQ0ElMjAzQigxKS5jcnQwdQYIKwYBBQUHMAKGaWh0dHA6Ly9jZXJ0
aWZpY2F0ZXMuaW50ZWwuY29tL3JlcG9zaXRvcnkvY2VydGlmaWNhdGVzL0ludGVsJTIwRXh0ZXJu
YWwlMjBCYXNpYyUyMElzc3VpbmclMjBDQSUyMDNCKDEpLmNydDAfBgNVHSUEGDAWBggrBgEFBQcD
BAYKKwYBBAGCNwoDBDApBgkrBgEEAYI3FQoEHDAaMAoGCCsGAQUFBwMEMAwGCisGAQQBgjcKAwQw
RwYDVR0RBEAwPqAlBgorBgEEAYI3FAIDoBcMFWhhaXRhby5zaGFuQGludGVsLmNvbYEVaGFpdGFv
LnNoYW5AaW50ZWwuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQAqWvSRW8jKGuWVwUKo/+QRxKvuT3cv
/975omnwo7QeOj78XruY/Wsl6/tnzI8jgf6ZE5SRoj5sSGBHmy7qHSZNWodLuJgjN+a0Fk2hy0jB
wX2UJLS3ctijemo4e4u8/YFebLVXCzy81lWa7dZcidebnslLlcQXHNzl8hhFAfQwhcCXMAiA89NO
3uJqd9Sk/PSfG90b/f+1u2xIthxQmeh7u1yuiHZrf1u/e6rJWS50iW+LWmrH0c70XN8voHpLXVDo
09C9DETzJOUrhr1BqLVSxKjNn/uhCOcQxNYM3CYsgQBwVogKsGj59xeGFA5iWPKGRj7SfUXH0m3T
kiSaWLnWMYIDhjCCA4ICAQEwZDBWMQswCQYDVQQGEwJVUzEaMBgGA1UEChMRSW50ZWwgQ29ycG9y
YXRpb24xKzApBgNVBAMTIkludGVsIEV4dGVybmFsIEJhc2ljIElzc3VpbmcgQ0EgM0ICChMdOoEA
AQAAe60wCQYFKw4DAhoFAKCCAfcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0B
CQUxDxcNMTExMjA5MDYwMTU1WjAjBgkqhkiG9w0BCQQxFgQUu3q047OS/bBhVaw6f1U4vFfcrr4w
cwYJKwYBBAGCNxAEMWYwZDBWMQswCQYDVQQGEwJVUzEaMBgGA1UEChMRSW50ZWwgQ29ycG9yYXRp
b24xKzApBgNVBAMTIkludGVsIEV4dGVybmFsIEJhc2ljIElzc3VpbmcgQ0EgM0ICChMjTTEAAQAA
e64wdQYLKoZIhvcNAQkQAgsxZqBkMFYxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFJbnRlbCBDb3Jw
b3JhdGlvbjErMCkGA1UEAxMiSW50ZWwgRXh0ZXJuYWwgQmFzaWMgSXNzdWluZyBDQSAzQgIKEyNN
MQABAAB7rjCBqwYJKoZIhvcNAQkPMYGdMIGaMAoGCCqGSIb3DQMHMAsGCWCGSAFlAwQBKjALBglg
hkgBZQMEARYwCwYJYIZIAWUDBAECMA4GCCqGSIb3DQMCAgIAgDAHBgUrDgMCBzANBggqhkiG9w0D
AgIBQDANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAsG
CWCGSAFlAwQCATANBgkqhkiG9w0BAQEFAASCAQBqar77/ls2zd78NRW1XUzrKCSGvnNUsX45UsWf
GQQBytnd4ickR7JEDeNYH2hsbV/GBxClizV6lyW/BF/sabZZa6LtjkWY5QZwF5EmEdt2JpDwZ20o
7oVx8/kIClg8IvQQ3UIl39XYN8jA6a1hG2Dzvf4sr5GXR2A2II/5tuAusz1RQky2uhgo9bdky2cP
ISFZNEDNgI3YZw76R9lu0lDuEQkGRuZ08G1TBOGaszQhl6tvpaehe7Ae2uPZfsxAHaI93xc9Y5Zs
rQsZF3Afijx1UVpWz0pEs+rPtEOpPj2kRghZQQIoD6hXNJji0+mOpYHdxvphR+fguFQzXP2/cmwl
AAAAAAAA

------=_NextPart_000_00C7_01CCB67B.1C5AFF20--


--===============3012934755746700410==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============3012934755746700410==--


From xen-devel-bounces@lists.xensource.com Fri Dec 09 06:04:12 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 06:04:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYtYX-0001UF-28; Fri, 09 Dec 2011 06:03:37 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <haitao.shan@intel.com>) id 1RYtYV-0001U7-Q8
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 06:03:36 +0000
X-Env-Sender: haitao.shan@intel.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1323410543!6505981!1
X-Originating-IP: [143.182.124.37]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjA3NjE4\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14948 invoked from network); 9 Dec 2011 06:02:24 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37)
	by server-14.tower-182.messagelabs.com with SMTP;
	9 Dec 2011 06:02:24 -0000
Received: from azsmga002.ch.intel.com ([10.2.17.35])
	by azsmga102.ch.intel.com with ESMTP; 08 Dec 2011 22:02:22 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; 
	d="p7s'?scan'208";a="45503139"
Received: from pgsmsx602.gar.corp.intel.com ([10.221.43.81])
	by AZSMGA002.ch.intel.com with ESMTP; 08 Dec 2011 22:02:20 -0800
Received: from shsmsx602.ccr.corp.intel.com (10.239.4.104) by
	pgsmsx602.gar.corp.intel.com (10.221.43.81) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Fri, 9 Dec 2011 14:01:58 +0800
Received: from shsmsx502.ccr.corp.intel.com ([10.239.4.96]) by
	SHSMSX602.ccr.corp.intel.com ([10.239.4.104]) with mapi; Fri, 9 Dec 2011
	14:01:57 +0800
From: "Shan, Haitao" <haitao.shan@intel.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>, Jan Beulich
	<JBeulich@suse.com>
Date: Fri, 9 Dec 2011 14:01:56 +0800
Thread-Topic: [Xen-devel] [PATCH] Qemu MSI Cleaning Up
Thread-Index: Acy0SjR4SbYOllHxS6uDPoGOn5Jx2gB7c3Bg
Message-ID: <04F972F38B3C4E4E91C4697DA8BF9F52846C7517E8@shsmsx502.ccr.corp.intel.com>
References: <CAFQ2Z+fpR1UkxFEAYTD6irBUBeA3c7eJ3x1bXE0jzpdfQtH64w@mail.gmail.com>
	<alpine.DEB.2.00.1112021223190.31179@kaball-desktop>
	<4EDE367D0200007800065B6B@nat28.tlf.novell.com>
	<alpine.DEB.2.00.1112061906550.31179@kaball-desktop>
In-Reply-To: <alpine.DEB.2.00.1112061906550.31179@kaball-desktop>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: Haitao Shan <maillists.shan@gmail.com>, "Keir \(Xen.org\)" <keir@xen.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] Qemu MSI Cleaning Up
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3012934755746700410=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============3012934755746700410==
Content-Language: en-US
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature";
	micalg=SHA1; boundary="----=_NextPart_000_00C7_01CCB67B.1C5AFF20"

------=_NextPart_000_00C7_01CCB67B.1C5AFF20
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Fine to me! Thanks, Jan!

Shan Haitao

> -----Original Message-----
> From: Stefano Stabellini [mailto:stefano.stabellini@eu.citrix.com]
> Sent: Wednesday, December 07, 2011 3:08 AM
> To: Jan Beulich
> Cc: Stefano Stabellini; Haitao Shan; Ian Jackson; Shan, Haitao; xen-
> devel@lists.xensource.com; Keir (Xen.org)
> Subject: Re: [Xen-devel] [PATCH] Qemu MSI Cleaning Up
> 
> On Tue, 6 Dec 2011, Jan Beulich wrote:
> > >>> On 02.12.11 at 13:40, Stefano Stabellini
> <stefano.stabellini@eu.citrix.com> wrote:
> > > The two mapping and unmapping big chuncks of code looks very similar
> > > apart from the DPCI_ADD_MAPPING/DPCI_REMOVE_MAPPING
> parameter.
> > > Could they be refactored into a single function called
> > > "change_msix_mappings"?
> > > This is more or less what I have in mind:
> > >
> > > change_msix_mappings(assigned_device, DPCI_REMOVE_MAPPING);
> > >
> > > update mmio_base_addr
> > >
> > > change_msix_mappings(assigned_device, DPCI_ADD_MAPPING);
> >
> > Please see below/attached for the outcome. Without MSI-X capable
> > devices to pass through, I have to rely on others to do some testing
> > on this.
> 
> It looks fine.
> Haitao, are you happy with the new patch?

------=_NextPart_000_00C7_01CCB67B.1C5AFF20
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIYUDCCAyAw
ggKJoAMCAQICBDXe9M8wDQYJKoZIhvcNAQEFBQAwTjELMAkGA1UEBhMCVVMxEDAOBgNVBAoTB0Vx
dWlmYXgxLTArBgNVBAsTJEVxdWlmYXggU2VjdXJlIENlcnRpZmljYXRlIEF1dGhvcml0eTAeFw05
ODA4MjIxNjQxNTFaFw0xODA4MjIxNjQxNTFaME4xCzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVp
ZmF4MS0wKwYDVQQLEyRFcXVpZmF4IFNlY3VyZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwgZ8wDQYJ
KoZIhvcNAQEBBQADgY0AMIGJAoGBAMFdsVhnCGLuoJotHwhtkRRomAoe/toEbxOEYiHD0XzOnwXg
uAHwTjTs4oqVBGSs8WtTXwWzy2eAv0ICjv7dAQns4QAUT/z78AzdQ7pbK+EfgHCZFVeTFvEPl2q3
wmgjHMxNWTCsUR47ryvW7mNFe8XZX1DS41APOojnvxT94Me5AgMBAAGjggEJMIIBBTBwBgNVHR8E
aTBnMGWgY6BhpF8wXTELMAkGA1UEBhMCVVMxEDAOBgNVBAoTB0VxdWlmYXgxLTArBgNVBAsTJEVx
dWlmYXggU2VjdXJlIENlcnRpZmljYXRlIEF1dGhvcml0eTENMAsGA1UEAxMEQ1JMMTAaBgNVHRAE
EzARgQ8yMDE4MDgyMjE2NDE1MVowCwYDVR0PBAQDAgEGMB8GA1UdIwQYMBaAFEjmaPkr0rKV10fY
IyAQTzOYkJ/UMB0GA1UdDgQWBBRI5mj5K9KylddH2CMgEE8zmJCf1DAMBgNVHRMEBTADAQH/MBoG
CSqGSIb2fQdBAAQNMAsbBVYzLjBjAwIGwDANBgkqhkiG9w0BAQUFAAOBgQBYzinq/Pfetc4CuRe1
hdG54+CVzCUxDQCmkm5/tpJjnlCV0Zpv5BHeY4VumO6o/1rI01WyZnFX3sAh6z0qpyNJAQSGQnv8
7n+iFlK1Z2fTQNs7JliyKHc9rhR3Ydb6KmYnoA36p3Nc6nDxlCFlRF/6/O8paKmih3nvee9PrAd3
ODCCAz0wggKmoAMCAQICAwWw/zANBgkqhkiG9w0BAQUFADBOMQswCQYDVQQGEwJVUzEQMA4GA1UE
ChMHRXF1aWZheDEtMCsGA1UECxMkRXF1aWZheCBTZWN1cmUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5
MB4XDTA2MDIxNjE4MDEzMFoXDTE2MDIxOTE4MDEzMFowUjELMAkGA1UEBhMCVVMxGjAYBgNVBAoT
EUludGVsIENvcnBvcmF0aW9uMScwJQYDVQQDEx5JbnRlbCBFeHRlcm5hbCBCYXNpYyBQb2xpY3kg
Q0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDBpd/XOb9QVqEZ8mQ1042TdOIq3ATD
IsV2xDyt30yLyMR5Wjtus0bn3B+he89BiNO/LP6+rFzEwlD55PlX+HLGIKeNNG97dqyc30FElEUj
ZzTZFq2N4e3kVJ/XAEEgANzV8v9qp7qWwxugPgfc3z9BkYot+CifozexHLb/hEZj+yISCU61kRZv
uSQ0E11yYL4dRgcglJeaHo3oX57rvIckaLsYV5/1Aj+R8DM1Ppk965XQAKsHfnyT7C4S50T4lVn4
lz36wOdNZn/zegG1zp41lnoTFfT4KuKVJH5x7YD1p6KbgJCKLovnujGuohquBNfdXKpZkvz6pGv+
iC1HawJdAgMBAAGjgaAwgZ0wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBQaxgxKxEdvqNutK/D0
Vgaj7TdUDDA6BgNVHR8EMzAxMC+gLaArhilodHRwOi8vY3JsLmdlb3RydXN0LmNvbS9jcmxzL3Nl
Y3VyZWNhLmNybDAfBgNVHSMEGDAWgBRI5mj5K9KylddH2CMgEE8zmJCf1DAPBgNVHRMBAf8EBTAD
AQH/MA0GCSqGSIb3DQEBBQUAA4GBABMQOK2kVKVIlUWwLTdywJ+e2O+PC/uQltK2F3lRyrPfBn69
tOkIP4SgDJOfsxyobIrPLe75kBLw+Dom13OBDp/EMZJZ1CglQfVV8co9mT3aZMjSGGQiMgkJLR3j
Mfr900fXZKj5XeqCJ+JP0mEhJGEdVCY+FFlksJjV86fDrq1QMIIFijCCBHKgAwIBAgIKYSCKYgAA
AAAACDANBgkqhkiG9w0BAQUFADBSMQswCQYDVQQGEwJVUzEaMBgGA1UEChMRSW50ZWwgQ29ycG9y
YXRpb24xJzAlBgNVBAMTHkludGVsIEV4dGVybmFsIEJhc2ljIFBvbGljeSBDQTAeFw0wOTA1MTUx
OTI3MjZaFw0xNTA1MTUxOTM3MjZaMFYxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFJbnRlbCBDb3Jw
b3JhdGlvbjErMCkGA1UEAxMiSW50ZWwgRXh0ZXJuYWwgQmFzaWMgSXNzdWluZyBDQSAzQjCCASIw
DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKQEM1Wn9TU9vc9C+/Tc7KB+eiYElmrcEWE32WUd
HvWG+IcQHVQsikTmMyKKojNLw2B5s6Iekc8ivDo/wCfjZzX9JyftMnc+AArc0la87Olybzm8K9jX
EfTBvTnUSFSiI9ZYefITdiUgqlAFuljFZEHYKYtLuhrRacpmQfP4mV63NKdc2bT804HRf6YptZFa
4k6YN94zlrGNrBuQQ74WFzz/jLBusbUpEkro6Mu/ZYFOFWQrV9lBhF9Ruk8yN+3N6n9fUo/qBigi
F2kEn9xVh1ykl7SCGL2jBUkXx4qgV27a6Si8lRRdgrHGtN/HWnSWlLXTH5l575H4Lq++77OFv38C
AwEAAaOCAlwwggJYMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFA7GKvdZsggQkCVvw939imYx
MCvFMAsGA1UdDwQEAwIBhjASBgkrBgEEAYI3FQEEBQIDAQABMCMGCSsGAQQBgjcVAgQWBBQ5oFY2
ekKQ/5Ktim+VdMeSWb4QWTAZBgkrBgEEAYI3FAIEDB4KAFMAdQBiAEMAQTAfBgNVHSMEGDAWgBQa
xgxKxEdvqNutK/D0Vgaj7TdUDDCBvQYDVR0fBIG1MIGyMIGvoIGsoIGphk5odHRwOi8vd3d3Lmlu
dGVsLmNvbS9yZXBvc2l0b3J5L0NSTC9JbnRlbCUyMEV4dGVybmFsJTIwQmFzaWMlMjBQb2xpY3kl
MjBDQS5jcmyGV2h0dHA6Ly9jZXJ0aWZpY2F0ZXMuaW50ZWwuY29tL3JlcG9zaXRvcnkvQ1JML0lu
dGVsJTIwRXh0ZXJuYWwlMjBCYXNpYyUyMFBvbGljeSUyMENBLmNybDCB4wYIKwYBBQUHAQEEgdYw
gdMwYwYIKwYBBQUHMAKGV2h0dHA6Ly93d3cuaW50ZWwuY29tL3JlcG9zaXRvcnkvY2VydGlmaWNh
dGVzL0ludGVsJTIwRXh0ZXJuYWwlMjBCYXNpYyUyMFBvbGljeSUyMENBLmNydDBsBggrBgEFBQcw
AoZgaHR0cDovL2NlcnRpZmljYXRlcy5pbnRlbC5jb20vcmVwb3NpdG9yeS9jZXJ0aWZpY2F0ZXMv
SW50ZWwlMjBFeHRlcm5hbCUyMEJhc2ljJTIwUG9saWN5JTIwQ0EuY3J0MA0GCSqGSIb3DQEBBQUA
A4IBAQCxtQEHchVQhXyjEqtMVUMe6gkmPsIczHxSeqNbo9dsD+6xbT65JT+oYgpIAtfEsYXeUJu1
cChqpb22U5bMAz7eaQcW5bzefufWvA6lg2048B8oczBj/q+5P5NpYrUO8jOmN4jTjfJq3ElZ7yFW
py7rB3Vm/aN6ATYqWfMbS/xfh+JCxmH3droUmMJI0/aZJHsLtjbjFnNsHDNrJZX1vxlM78Lb1hjs
kTENPmhbVbfTj5i/ZGnhv4tmI8QZPCNtcegXJrfhRl2D9bWpdTOPrWiLDUqzy1Z6KL7TcOS/PCl8
RHCJXkPau/thTQCpIoDa2+c+3XA++gRTfAQ4svTO260NMIIGBzCCBO+gAwIBAgIKEx06gQABAAB7
rTANBgkqhkiG9w0BAQUFADBWMQswCQYDVQQGEwJVUzEaMBgGA1UEChMRSW50ZWwgQ29ycG9yYXRp
b24xKzApBgNVBAMTIkludGVsIEV4dGVybmFsIEJhc2ljIElzc3VpbmcgQ0EgM0IwHhcNMTExMDEy
MDEyNDIwWhcNMTQwOTI2MDEyNDIwWjA9MRUwEwYDVQQDEwxTaGFuLCBIYWl0YW8xJDAiBgkqhkiG
9w0BCQEWFWhhaXRhby5zaGFuQGludGVsLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC
ggEBALpHYbXkMy06K6Pl9IGxbsKl0zT/OYd523Rh3CX7tHG/80ZGcPeLlzFK+l+30Fhpzf8fsFwG
l5fX2pRtWqT96BUWecXEVJhisfa1Wrq7DBC6coxEnExFADU+2UsBQ/ACKFSCiq/fADojyFWJgPKv
4PLDKJ9LU23Q+g1WRruGHfBnhCMv0KxnkE7pTk3cFRXtNUSUnYLqcvrZwt9VogQNiNNw3jMlDb8t
bJjMsXdhrwqFGW49z/gAJ2Mnr6/lNnqBdcKF2Qm28SfYXRohGrmam3KReM49ZG0+J/+JPF5drbiw
UAV++PMHA3IXIvZF2c66jQM5BzbF93SkoZXmrQZA2jMCAwEAAaOCAu4wggLqMAsGA1UdDwQEAwIH
gDA8BgkrBgEEAYI3FQcELzAtBiUrBgEEAYI3FQiGw4x1hJnlUYP9gSiFjp9TgpHACWeB3r05lfBD
AgFkAgEIMB0GA1UdDgQWBBQ/OInBCgrko9ziRWiEhjM+SyeeoDAfBgNVHSMEGDAWgBQOxir3WbII
EJAlb8Pd/YpmMTArxTCBzwYDVR0fBIHHMIHEMIHBoIG+oIG7hldodHRwOi8vd3d3LmludGVsLmNv
bS9yZXBvc2l0b3J5L0NSTC9JbnRlbCUyMEV4dGVybmFsJTIwQmFzaWMlMjBJc3N1aW5nJTIwQ0El
MjAzQigxKS5jcmyGYGh0dHA6Ly9jZXJ0aWZpY2F0ZXMuaW50ZWwuY29tL3JlcG9zaXRvcnkvQ1JM
L0ludGVsJTIwRXh0ZXJuYWwlMjBCYXNpYyUyMElzc3VpbmclMjBDQSUyMDNCKDEpLmNybDCB9QYI
KwYBBQUHAQEEgegwgeUwbAYIKwYBBQUHMAKGYGh0dHA6Ly93d3cuaW50ZWwuY29tL3JlcG9zaXRv
cnkvY2VydGlmaWNhdGVzL0ludGVsJTIwRXh0ZXJuYWwlMjBCYXNpYyUyMElzc3VpbmclMjBDQSUy
MDNCKDEpLmNydDB1BggrBgEFBQcwAoZpaHR0cDovL2NlcnRpZmljYXRlcy5pbnRlbC5jb20vcmVw
b3NpdG9yeS9jZXJ0aWZpY2F0ZXMvSW50ZWwlMjBFeHRlcm5hbCUyMEJhc2ljJTIwSXNzdWluZyUy
MENBJTIwM0IoMSkuY3J0MB8GA1UdJQQYMBYGCCsGAQUFBwMEBgorBgEEAYI3CgMMMCkGCSsGAQQB
gjcVCgQcMBowCgYIKwYBBQUHAwQwDAYKKwYBBAGCNwoDDDBHBgNVHREEQDA+oCUGCisGAQQBgjcU
AgOgFwwVaGFpdGFvLnNoYW5AaW50ZWwuY29tgRVoYWl0YW8uc2hhbkBpbnRlbC5jb20wDQYJKoZI
hvcNAQEFBQADggEBAG5Us26ruu8jKt3RhZuirjqgF61p+wZer/xV6BTABUx5++DhWXslTztavsvy
JZ5WsZ7xaijBUO3UQViWTylwmSyGwbhEwreu3XRNGlMOnRk+sH7JGiXZJIpqoD/jtRWp0ypHG2g3
nDqAQ1/j4wUgcI0b12KUJyYAeN6cwEeAqIV4mdD8GpH3DS2nZbEZjTNhkaeJuT7lO1jRqzEGOSCk
KDHPfqUtqpw+wZa6mFbzSso9swc4ypgRIl4l5i/4OwNMQazHm2O6Ov91aDJs6j3DCdALzP736hmF
QFfHWL34GFQMRdpO/OI6z/Q0VYm/6N9o4SD/s4J9Edq8zyYNQxBR03QwggZOMIIFNqADAgECAgoT
I00xAAEAAHuuMA0GCSqGSIb3DQEBBQUAMFYxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFJbnRlbCBD
b3Jwb3JhdGlvbjErMCkGA1UEAxMiSW50ZWwgRXh0ZXJuYWwgQmFzaWMgSXNzdWluZyBDQSAzQjAe
Fw0xMTEwMTIwMTMwNTZaFw0xNDA5MjYwMTMwNTZaMD0xFTATBgNVBAMTDFNoYW4sIEhhaXRhbzEk
MCIGCSqGSIb3DQEJARYVaGFpdGFvLnNoYW5AaW50ZWwuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOC
AQ8AMIIBCgKCAQEApaOcuQtYCobUiLQTadd0Hi+U/ausgzeSE59iUrc57VUzvLsLNnKRxLPm+T26
KN9fMDAS3/MZOl5tf+9mKEwrergim5GzwJpfZWPLAyK2Gs57+F+BMgtX6DT0eh4sGQLQDahPZDhy
Ubo420AiTGuTA9/L22B/qbPNuDRNMMJoreAZeSNBSVPa7Q+Y0oXcfKpAmKzHH2Y+WAzupN5jfxhJ
6yb7MpsPDqoU0Ek4VttgUIl4AQlRFMI18ScKvAG2p9kWSSgq+Z9xdQl7F/3ASkXlQMKEOHCDw8E7
XUzqy4pOoXGaI3FVI4AerPeLgz2SkNINfqLnxdhN+BQ6iuRgsOeyIwIDAQABo4IDNTCCAzEwCwYD
VR0PBAQDAgQwMD0GCSsGAQQBgjcVBwQwMC4GJisGAQQBgjcVCIbDjHWEmeVRg/2BKIWOn1OCkcAJ
Z4S52UGHhP9OAgFkAgEMMEQGCSqGSIb3DQEJDwQ3MDUwDgYIKoZIhvcNAwICAgCAMA4GCCqGSIb3
DQMEAgIAgDAHBgUrDgMCBzAKBggqhkiG9w0DBzAdBgNVHQ4EFgQU/+6IdpvPrUveCml7StYwqL40
iqMwHwYDVR0jBBgwFoAUDsYq91myCBCQJW/D3f2KZjEwK8Uwgc8GA1UdHwSBxzCBxDCBwaCBvqCB
u4ZXaHR0cDovL3d3dy5pbnRlbC5jb20vcmVwb3NpdG9yeS9DUkwvSW50ZWwlMjBFeHRlcm5hbCUy
MEJhc2ljJTIwSXNzdWluZyUyMENBJTIwM0IoMSkuY3JshmBodHRwOi8vY2VydGlmaWNhdGVzLmlu
dGVsLmNvbS9yZXBvc2l0b3J5L0NSTC9JbnRlbCUyMEV4dGVybmFsJTIwQmFzaWMlMjBJc3N1aW5n
JTIwQ0ElMjAzQigxKS5jcmwwgfUGCCsGAQUFBwEBBIHoMIHlMGwGCCsGAQUFBzAChmBodHRwOi8v
d3d3LmludGVsLmNvbS9yZXBvc2l0b3J5L2NlcnRpZmljYXRlcy9JbnRlbCUyMEV4dGVybmFsJTIw
QmFzaWMlMjBJc3N1aW5nJTIwQ0ElMjAzQigxKS5jcnQwdQYIKwYBBQUHMAKGaWh0dHA6Ly9jZXJ0
aWZpY2F0ZXMuaW50ZWwuY29tL3JlcG9zaXRvcnkvY2VydGlmaWNhdGVzL0ludGVsJTIwRXh0ZXJu
YWwlMjBCYXNpYyUyMElzc3VpbmclMjBDQSUyMDNCKDEpLmNydDAfBgNVHSUEGDAWBggrBgEFBQcD
BAYKKwYBBAGCNwoDBDApBgkrBgEEAYI3FQoEHDAaMAoGCCsGAQUFBwMEMAwGCisGAQQBgjcKAwQw
RwYDVR0RBEAwPqAlBgorBgEEAYI3FAIDoBcMFWhhaXRhby5zaGFuQGludGVsLmNvbYEVaGFpdGFv
LnNoYW5AaW50ZWwuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQAqWvSRW8jKGuWVwUKo/+QRxKvuT3cv
/975omnwo7QeOj78XruY/Wsl6/tnzI8jgf6ZE5SRoj5sSGBHmy7qHSZNWodLuJgjN+a0Fk2hy0jB
wX2UJLS3ctijemo4e4u8/YFebLVXCzy81lWa7dZcidebnslLlcQXHNzl8hhFAfQwhcCXMAiA89NO
3uJqd9Sk/PSfG90b/f+1u2xIthxQmeh7u1yuiHZrf1u/e6rJWS50iW+LWmrH0c70XN8voHpLXVDo
09C9DETzJOUrhr1BqLVSxKjNn/uhCOcQxNYM3CYsgQBwVogKsGj59xeGFA5iWPKGRj7SfUXH0m3T
kiSaWLnWMYIDhjCCA4ICAQEwZDBWMQswCQYDVQQGEwJVUzEaMBgGA1UEChMRSW50ZWwgQ29ycG9y
YXRpb24xKzApBgNVBAMTIkludGVsIEV4dGVybmFsIEJhc2ljIElzc3VpbmcgQ0EgM0ICChMdOoEA
AQAAe60wCQYFKw4DAhoFAKCCAfcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0B
CQUxDxcNMTExMjA5MDYwMTU1WjAjBgkqhkiG9w0BCQQxFgQUu3q047OS/bBhVaw6f1U4vFfcrr4w
cwYJKwYBBAGCNxAEMWYwZDBWMQswCQYDVQQGEwJVUzEaMBgGA1UEChMRSW50ZWwgQ29ycG9yYXRp
b24xKzApBgNVBAMTIkludGVsIEV4dGVybmFsIEJhc2ljIElzc3VpbmcgQ0EgM0ICChMjTTEAAQAA
e64wdQYLKoZIhvcNAQkQAgsxZqBkMFYxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFJbnRlbCBDb3Jw
b3JhdGlvbjErMCkGA1UEAxMiSW50ZWwgRXh0ZXJuYWwgQmFzaWMgSXNzdWluZyBDQSAzQgIKEyNN
MQABAAB7rjCBqwYJKoZIhvcNAQkPMYGdMIGaMAoGCCqGSIb3DQMHMAsGCWCGSAFlAwQBKjALBglg
hkgBZQMEARYwCwYJYIZIAWUDBAECMA4GCCqGSIb3DQMCAgIAgDAHBgUrDgMCBzANBggqhkiG9w0D
AgIBQDANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAsG
CWCGSAFlAwQCATANBgkqhkiG9w0BAQEFAASCAQBqar77/ls2zd78NRW1XUzrKCSGvnNUsX45UsWf
GQQBytnd4ickR7JEDeNYH2hsbV/GBxClizV6lyW/BF/sabZZa6LtjkWY5QZwF5EmEdt2JpDwZ20o
7oVx8/kIClg8IvQQ3UIl39XYN8jA6a1hG2Dzvf4sr5GXR2A2II/5tuAusz1RQky2uhgo9bdky2cP
ISFZNEDNgI3YZw76R9lu0lDuEQkGRuZ08G1TBOGaszQhl6tvpaehe7Ae2uPZfsxAHaI93xc9Y5Zs
rQsZF3Afijx1UVpWz0pEs+rPtEOpPj2kRghZQQIoD6hXNJji0+mOpYHdxvphR+fguFQzXP2/cmwl
AAAAAAAA

------=_NextPart_000_00C7_01CCB67B.1C5AFF20--


--===============3012934755746700410==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============3012934755746700410==--


From xen-devel-bounces@lists.xensource.com Fri Dec 09 07:46:58 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 07:46:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYv9v-00024A-22; Fri, 09 Dec 2011 07:46:19 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <annie.li@oracle.com>) id 1RYv9u-00023k-3g
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 07:46:18 +0000
X-Env-Sender: annie.li@oracle.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1323416679!60044790!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDI1MDkx\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19530 invoked from network); 9 Dec 2011 07:44:40 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-7.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 9 Dec 2011 07:44:40 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pB97jOhS027902
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 9 Dec 2011 07:45:25 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pB97jOqh026198
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 9 Dec 2011 07:45:24 GMT
Received: from abhmt103.oracle.com (abhmt103.oracle.com [141.146.116.55])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pB97jGmd022006; Fri, 9 Dec 2011 01:45:16 -0600
Received: from [10.191.9.5] (/10.191.9.5)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 08 Dec 2011 23:45:16 -0800
Message-ID: <4EE1BC7E.3060904@oracle.com>
Date: Fri, 09 Dec 2011 15:45:02 +0800
From: annie li <annie.li@oracle.com>
Organization: Oracle Corporation
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
MIME-Version: 1.0
To: Paul Durrant <Paul.Durrant@citrix.com>
References: <1323336940-5382-1-git-send-email-annie.li@oracle.com>
	<1323337048-5426-1-git-send-email-annie.li@oracle.com>
	<291EDFCB1E9E224A99088639C4762022B5988E5528@LONPMAILBOX01.citrite.net>
	<4EE08B0D.80504@oracle.com>
	<291EDFCB1E9E224A99088639C4762022B5988E552D@LONPMAILBOX01.citrite.net>
	<4EE19A4D.9030500@oracle.com>
In-Reply-To: <4EE19A4D.9030500@oracle.com>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090201.4EE1BC97.0018,ss=1,re=0.000,fgs=0
Cc: "jeremy@goop.org" <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	"kurt.hackel@oracle.com" <kurt.hackel@oracle.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	annie li <annie.li@oracle.com>
Subject: Re: [Xen-devel] [PATCH V2 1/2] xen/granttable: Support sub-page
	grants
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com



On 2011-12-9 13:19, annie li wrote:
> Hi Paul,
>
>>>> #define get_free_entry()    get_free_entries(1)
> Is this necessary? Maybe you defined this to keep consistence with 
> put_free_entry(ref)?
> But other functions such as gnttab_grant_foreign_transfer and 
> gnttab_grant_foreign_access all call get_free_entries(1). Maybe it is 
> better to keep initial get_free_entries(1) code?
Another approach is doing those work in a separate patch -- changing 
get_free_entries to get_free_entry in following 4 functions:
gnttab_grant_foreign_access
gnttab_grant_foreign_access_subpage
gnttab_grant_foreign_access_trans
gnttab_grant_foreign_transfer

Thanks
Annie

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 07:46:58 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 07:46:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYv9v-00024A-22; Fri, 09 Dec 2011 07:46:19 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <annie.li@oracle.com>) id 1RYv9u-00023k-3g
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 07:46:18 +0000
X-Env-Sender: annie.li@oracle.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1323416679!60044790!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDI1MDkx\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19530 invoked from network); 9 Dec 2011 07:44:40 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-7.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 9 Dec 2011 07:44:40 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pB97jOhS027902
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 9 Dec 2011 07:45:25 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pB97jOqh026198
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 9 Dec 2011 07:45:24 GMT
Received: from abhmt103.oracle.com (abhmt103.oracle.com [141.146.116.55])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pB97jGmd022006; Fri, 9 Dec 2011 01:45:16 -0600
Received: from [10.191.9.5] (/10.191.9.5)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 08 Dec 2011 23:45:16 -0800
Message-ID: <4EE1BC7E.3060904@oracle.com>
Date: Fri, 09 Dec 2011 15:45:02 +0800
From: annie li <annie.li@oracle.com>
Organization: Oracle Corporation
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
MIME-Version: 1.0
To: Paul Durrant <Paul.Durrant@citrix.com>
References: <1323336940-5382-1-git-send-email-annie.li@oracle.com>
	<1323337048-5426-1-git-send-email-annie.li@oracle.com>
	<291EDFCB1E9E224A99088639C4762022B5988E5528@LONPMAILBOX01.citrite.net>
	<4EE08B0D.80504@oracle.com>
	<291EDFCB1E9E224A99088639C4762022B5988E552D@LONPMAILBOX01.citrite.net>
	<4EE19A4D.9030500@oracle.com>
In-Reply-To: <4EE19A4D.9030500@oracle.com>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090201.4EE1BC97.0018,ss=1,re=0.000,fgs=0
Cc: "jeremy@goop.org" <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	"kurt.hackel@oracle.com" <kurt.hackel@oracle.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	annie li <annie.li@oracle.com>
Subject: Re: [Xen-devel] [PATCH V2 1/2] xen/granttable: Support sub-page
	grants
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com



On 2011-12-9 13:19, annie li wrote:
> Hi Paul,
>
>>>> #define get_free_entry()    get_free_entries(1)
> Is this necessary? Maybe you defined this to keep consistence with 
> put_free_entry(ref)?
> But other functions such as gnttab_grant_foreign_transfer and 
> gnttab_grant_foreign_access all call get_free_entries(1). Maybe it is 
> better to keep initial get_free_entries(1) code?
Another approach is doing those work in a separate patch -- changing 
get_free_entries to get_free_entry in following 4 functions:
gnttab_grant_foreign_access
gnttab_grant_foreign_access_subpage
gnttab_grant_foreign_access_trans
gnttab_grant_foreign_transfer

Thanks
Annie

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 08:18:56 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 08:18:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYves-00036M-Rt; Fri, 09 Dec 2011 08:18:18 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RYver-00036H-3x
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 08:18:17 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1323418630!51479372!1
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28354 invoked from network); 9 Dec 2011 08:17:10 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 08:17:10 -0000
Received: by wgbds11 with SMTP id ds11so4436984wgb.24
	for <xen-devel@lists.xensource.com>;
	Fri, 09 Dec 2011 00:17:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=xaAJ3NQ2ZwuEDVS0fVVLhyhwfWOLF2ozKbl8Ot54T9w=;
	b=SnpdvH+vqZkWLoSoXNmGf3qerYx2cCOaBXtKqCtbOE2cWMmBbzGfni/hC0ZOjnNH86
	ReP7gts6YowkxiJmQCI5NxCP3OsZtxdKE/l0OnUdu0i58JVaz6eAX7A56hJ+4UqWuxM6
	wEixUeUAs3EI390Qc1r++0n1IF23nMc9w78vQ=
Received: by 10.180.75.204 with SMTP id e12mr9407461wiw.61.1323418652656;
	Fri, 09 Dec 2011 00:17:32 -0800 (PST)
Received: from [192.168.1.70]
	(host81-155-119-104.range81-155.btcentralplus.com. [81.155.119.104])
	by mx.google.com with ESMTPS id fi11sm11808549wbb.9.2011.12.09.00.17.29
	(version=SSLv3 cipher=OTHER); Fri, 09 Dec 2011 00:17:31 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Fri, 09 Dec 2011 08:17:27 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <CB077497.26D84%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH 12 of 18] x86/mm: Make page_lock/unlock() in
	arch/x86/mm.c externally callable
Thread-Index: Acy2Svyu63sbGPdG+06G8BOaYsNI2w==
In-Reply-To: <123ea80c57135b138f37258fd7c9c8a0.squirrel@webmail.lagarcavilla.org>
Mime-version: 1.0
Cc: xen-devel@lists.xensource.com, ian.campbell@citrix.com,
	andres@gridcentric.ca, Tim Deegan <tim@xen.org>,
	jbeulich@suse.com, ian.jackson@citrix.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 12 of 18] x86/mm: Make page_lock/unlock() in
 arch/x86/mm.c externally callable
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 09/12/2011 03:01, "Andres Lagar-Cavilla" <andres@lagarcavilla.org> wrote:

>> On 08/12/2011 22:38, "Tim Deegan" <tim@xen.org> wrote:
>> 
>>> At 02:47 -0500 on 08 Dec (1323312447), Andres Lagar-Cavilla wrote:
>>>> This is necessary for a new consumer of page_lock/unlock to follow in
>>>> the series.
>>>> 
>>>> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
>>> 
>>> Nak, I'm afraid.
>>> 
>>> These were OK as local functions but if they're going to be made
>>> generally visible, they need clear comments describing what this
>>> locking protects and what the discipline is for avoiding deadlocks.
>>> 
>>> Perhaps Jan or Keir can supply appropriate words.  The locking was
>>> introduce in this cset:
>> 
>> It's Jan's work originally, but the basic intention of page_lock is to
>> serialise pte updates. To aid with this, a page's type cannot change while
>> its lock is held.
> That's definitely a property I want to leverage.
> 
>> No lock nests inside a page lock (not even other page
>> locks) so there is no deadlock risk.
> There's no way to not nest when sharing two pages, but I always make sure
> I lock in ascending order.

The fact there is currently no nesting gives you some freedom. Ordered
locking of other page locks is obviously going to be safe. So is taking a
page lock inside any other lock. Taking some other lock inside a page lock
is all that needs care, but there probably aren't many locks that currently
can have page locks nested inside them (and hence you would risk deadlock by
nesting the other way).

 -- Keir

> Thanks,
> Andres
>> 
>>>     changeset:   17846:09dd5999401b
>>>     user:        Keir Fraser <keir.fraser@citrix.com>
>>>     date:        Thu Jun 12 18:14:00 2008 +0100
>>>     files:       xen/arch/x86/domain.c xen/arch/x86/domain_build.c
>>>     xen/arch/x86/mm.c
>>>     description:
>>>     x86: remove use of per-domain lock from page table entry handling
>>> 
>>>     This change results in a 5% performance improvement for kernel
>>> builds
>>>     on dual-socket quad-core systems (which is what I used for reference
>>>     for both 32- and 64-bit). Along with that, the amount of time
>>> reported
>>>     as spent in the kernel gets reduced by almost 25% (the fraction of
>>>     time spent in the kernel is generally reported significantly higher
>>>     under Xen than with a native kernel).
>>> 
>>>     Signed-off-by: Jan Beulich <jbeulich@novell.com>
>>>     Signed-off-by: Keir Fraser <keir.fraser@citrix.com>
>>> 
>>> Tim.
>> 
>> 
>> 
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 08:18:56 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 08:18:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYves-00036M-Rt; Fri, 09 Dec 2011 08:18:18 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RYver-00036H-3x
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 08:18:17 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1323418630!51479372!1
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28354 invoked from network); 9 Dec 2011 08:17:10 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 08:17:10 -0000
Received: by wgbds11 with SMTP id ds11so4436984wgb.24
	for <xen-devel@lists.xensource.com>;
	Fri, 09 Dec 2011 00:17:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=xaAJ3NQ2ZwuEDVS0fVVLhyhwfWOLF2ozKbl8Ot54T9w=;
	b=SnpdvH+vqZkWLoSoXNmGf3qerYx2cCOaBXtKqCtbOE2cWMmBbzGfni/hC0ZOjnNH86
	ReP7gts6YowkxiJmQCI5NxCP3OsZtxdKE/l0OnUdu0i58JVaz6eAX7A56hJ+4UqWuxM6
	wEixUeUAs3EI390Qc1r++0n1IF23nMc9w78vQ=
Received: by 10.180.75.204 with SMTP id e12mr9407461wiw.61.1323418652656;
	Fri, 09 Dec 2011 00:17:32 -0800 (PST)
Received: from [192.168.1.70]
	(host81-155-119-104.range81-155.btcentralplus.com. [81.155.119.104])
	by mx.google.com with ESMTPS id fi11sm11808549wbb.9.2011.12.09.00.17.29
	(version=SSLv3 cipher=OTHER); Fri, 09 Dec 2011 00:17:31 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Fri, 09 Dec 2011 08:17:27 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <CB077497.26D84%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH 12 of 18] x86/mm: Make page_lock/unlock() in
	arch/x86/mm.c externally callable
Thread-Index: Acy2Svyu63sbGPdG+06G8BOaYsNI2w==
In-Reply-To: <123ea80c57135b138f37258fd7c9c8a0.squirrel@webmail.lagarcavilla.org>
Mime-version: 1.0
Cc: xen-devel@lists.xensource.com, ian.campbell@citrix.com,
	andres@gridcentric.ca, Tim Deegan <tim@xen.org>,
	jbeulich@suse.com, ian.jackson@citrix.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 12 of 18] x86/mm: Make page_lock/unlock() in
 arch/x86/mm.c externally callable
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 09/12/2011 03:01, "Andres Lagar-Cavilla" <andres@lagarcavilla.org> wrote:

>> On 08/12/2011 22:38, "Tim Deegan" <tim@xen.org> wrote:
>> 
>>> At 02:47 -0500 on 08 Dec (1323312447), Andres Lagar-Cavilla wrote:
>>>> This is necessary for a new consumer of page_lock/unlock to follow in
>>>> the series.
>>>> 
>>>> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
>>> 
>>> Nak, I'm afraid.
>>> 
>>> These were OK as local functions but if they're going to be made
>>> generally visible, they need clear comments describing what this
>>> locking protects and what the discipline is for avoiding deadlocks.
>>> 
>>> Perhaps Jan or Keir can supply appropriate words.  The locking was
>>> introduce in this cset:
>> 
>> It's Jan's work originally, but the basic intention of page_lock is to
>> serialise pte updates. To aid with this, a page's type cannot change while
>> its lock is held.
> That's definitely a property I want to leverage.
> 
>> No lock nests inside a page lock (not even other page
>> locks) so there is no deadlock risk.
> There's no way to not nest when sharing two pages, but I always make sure
> I lock in ascending order.

The fact there is currently no nesting gives you some freedom. Ordered
locking of other page locks is obviously going to be safe. So is taking a
page lock inside any other lock. Taking some other lock inside a page lock
is all that needs care, but there probably aren't many locks that currently
can have page locks nested inside them (and hence you would risk deadlock by
nesting the other way).

 -- Keir

> Thanks,
> Andres
>> 
>>>     changeset:   17846:09dd5999401b
>>>     user:        Keir Fraser <keir.fraser@citrix.com>
>>>     date:        Thu Jun 12 18:14:00 2008 +0100
>>>     files:       xen/arch/x86/domain.c xen/arch/x86/domain_build.c
>>>     xen/arch/x86/mm.c
>>>     description:
>>>     x86: remove use of per-domain lock from page table entry handling
>>> 
>>>     This change results in a 5% performance improvement for kernel
>>> builds
>>>     on dual-socket quad-core systems (which is what I used for reference
>>>     for both 32- and 64-bit). Along with that, the amount of time
>>> reported
>>>     as spent in the kernel gets reduced by almost 25% (the fraction of
>>>     time spent in the kernel is generally reported significantly higher
>>>     under Xen than with a native kernel).
>>> 
>>>     Signed-off-by: Jan Beulich <jbeulich@novell.com>
>>>     Signed-off-by: Keir Fraser <keir.fraser@citrix.com>
>>> 
>>> Tim.
>> 
>> 
>> 
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 08:19:56 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 08:19:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYvg3-00039G-Al; Fri, 09 Dec 2011 08:19:31 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RYvg1-00038u-DC
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 08:19:29 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1323418720!6745763!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDIwNw==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31824 invoked from network); 9 Dec 2011 08:18:40 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 08:18:40 -0000
X-IronPort-AV: E=Sophos;i="4.71,325,1320624000"; 
   d="scan'208";a="9376767"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 08:18:39 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 08:18:38 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RYvfC-0007hd-SM;
	Fri, 09 Dec 2011 08:18:38 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RYvfC-0001am-Mi;
	Fri, 09 Dec 2011 08:18:38 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10458-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 9 Dec 2011 08:18:38 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing test] 10458: trouble: broken/fail/pass
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10458 xen-4.1-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10458/

Failures and problems with tests :-(

Tests which did not succeed and are blocking:
 test-amd64-i386-xl-credit2    3 host-install(3)              broken
 test-amd64-amd64-xl-sedf      3 host-install(3)              broken
 test-amd64-amd64-xl-winxpsp3  3 host-install(3)              broken
 test-amd64-amd64-pv           3 host-install(3)              broken
 test-amd64-i386-win-vcpus1    3 host-install(3)              broken
 test-amd64-i386-pv            3 host-install(3)              broken   in 10444
 test-i386-i386-win            3 host-install(3)              broken   in 10444

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf-pin 14 guest-localmigrate/x10      fail pass in 10444

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-i386-xend-winxpsp3  7 windows-install              fail  never pass
 test-i386-i386-xl-winxpsp3    7 windows-install              fail   never pass
 test-amd64-amd64-xl-win7-amd64  7 windows-install              fail never pass
 test-amd64-i386-xl-win7-amd64  7 windows-install              fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install          fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check      fail in 10444 never pass

version targeted for testing:
 xen                  1c89f7d29fbb
baseline version:
 xen                  d9f8316a8291

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   broken  
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          broken  
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     broken  
 test-amd64-i386-win-vcpus1                                   broken  
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 broken  
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   23201:1c89f7d29fbb
tag:         tip
user:        Olaf Hering <olaf@aepfle.de>
date:        Thu Dec 08 16:50:28 2011 +0000
    
    tools: init.d/Linux/xencommons: load evtchn and gntdev modules
    
    There is currently no code in the kernel to trigger autoload of the
    evtchn or gntdev drivers. Load them manually during xencommons start.
    Handle both pvops and xenlinux module names.
    
    Signed-off-by: Olaf Hering <olaf@aepfle.de>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    xen-unstable changeset: 24334:9c8aff308002
    Backport-requested-by: Olaf Hering <olaf@aepfle.de>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   23200:7a4fad2d4b05
user:        Olaf Hering <olaf@aepfle.de>
date:        Thu Dec 08 16:50:16 2011 +0000
    
    tools: init.d/Linux/xencommons: run script only when needed
    
    Currently xencommons prints an error that /proc/xen/capabilities does
    not exist when started on a non-xen kernel.
    
    Update the xencommons script to run only when needed:
    - do not run if /proc/xen does not exist
    - check if /proc/xen/capabilities exists before doing the grep for dom0
    
    Signed-off-by: Olaf Hering <olaf@aepfle.de>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    xen-unstable changeset: 24333:4002e63b188a
    Backport-requested-by: Olaf Hering <olaf@aepfle.de>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   23199:d9f8316a8291
user:        Andrew Cooper <andrew.cooper3@citrix.com>
date:        Tue Dec 06 10:53:12 2011 +0000
    
    KEXEC: fix kexec_get_range_compat to fail vocally.
    
    Fail with -ERANGE rather than silently truncating 64bit values (a
    physical address and size) into 32bit integers for dom0 to consume.
    
    Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
    
    Simplify the bitwise arithmetic a bit.
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    xen-unstable changeset:   24358:9961a6d5356a
    xen-unstable date:        Mon Dec 05 19:42:46 2011 +0000
    
    
========================================
commit 3981d218912e186cb4205ee6732f446c177a36a2
Author: Jean Guyader <jean.guyader@eu.citrix.com>
Date:   Tue Nov 22 18:49:15 2011 +0000

    qemu-xen: Don't redefine libpci (3.1.7) defines.
    
    These values are already defined by the libpci heders in the version
    3.1.7.
    
    PCI_STATUS_66MHZ
    PCI_STATUS_RESERVED2
    PCI_STATUS_FAST_BACK
    PCI_MSIX_TABSIZE
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    (cherry picked from commit 174d92a73a5d5e67c49501383a519021b72a2468)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 08:19:56 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 08:19:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYvg3-00039G-Al; Fri, 09 Dec 2011 08:19:31 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RYvg1-00038u-DC
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 08:19:29 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1323418720!6745763!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDIwNw==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31824 invoked from network); 9 Dec 2011 08:18:40 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 08:18:40 -0000
X-IronPort-AV: E=Sophos;i="4.71,325,1320624000"; 
   d="scan'208";a="9376767"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 08:18:39 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 08:18:38 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RYvfC-0007hd-SM;
	Fri, 09 Dec 2011 08:18:38 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RYvfC-0001am-Mi;
	Fri, 09 Dec 2011 08:18:38 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10458-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 9 Dec 2011 08:18:38 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing test] 10458: trouble: broken/fail/pass
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10458 xen-4.1-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10458/

Failures and problems with tests :-(

Tests which did not succeed and are blocking:
 test-amd64-i386-xl-credit2    3 host-install(3)              broken
 test-amd64-amd64-xl-sedf      3 host-install(3)              broken
 test-amd64-amd64-xl-winxpsp3  3 host-install(3)              broken
 test-amd64-amd64-pv           3 host-install(3)              broken
 test-amd64-i386-win-vcpus1    3 host-install(3)              broken
 test-amd64-i386-pv            3 host-install(3)              broken   in 10444
 test-i386-i386-win            3 host-install(3)              broken   in 10444

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf-pin 14 guest-localmigrate/x10      fail pass in 10444

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-i386-xend-winxpsp3  7 windows-install              fail  never pass
 test-i386-i386-xl-winxpsp3    7 windows-install              fail   never pass
 test-amd64-amd64-xl-win7-amd64  7 windows-install              fail never pass
 test-amd64-i386-xl-win7-amd64  7 windows-install              fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install          fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check      fail in 10444 never pass

version targeted for testing:
 xen                  1c89f7d29fbb
baseline version:
 xen                  d9f8316a8291

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   broken  
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          broken  
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     broken  
 test-amd64-i386-win-vcpus1                                   broken  
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 broken  
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   23201:1c89f7d29fbb
tag:         tip
user:        Olaf Hering <olaf@aepfle.de>
date:        Thu Dec 08 16:50:28 2011 +0000
    
    tools: init.d/Linux/xencommons: load evtchn and gntdev modules
    
    There is currently no code in the kernel to trigger autoload of the
    evtchn or gntdev drivers. Load them manually during xencommons start.
    Handle both pvops and xenlinux module names.
    
    Signed-off-by: Olaf Hering <olaf@aepfle.de>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    xen-unstable changeset: 24334:9c8aff308002
    Backport-requested-by: Olaf Hering <olaf@aepfle.de>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   23200:7a4fad2d4b05
user:        Olaf Hering <olaf@aepfle.de>
date:        Thu Dec 08 16:50:16 2011 +0000
    
    tools: init.d/Linux/xencommons: run script only when needed
    
    Currently xencommons prints an error that /proc/xen/capabilities does
    not exist when started on a non-xen kernel.
    
    Update the xencommons script to run only when needed:
    - do not run if /proc/xen does not exist
    - check if /proc/xen/capabilities exists before doing the grep for dom0
    
    Signed-off-by: Olaf Hering <olaf@aepfle.de>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    xen-unstable changeset: 24333:4002e63b188a
    Backport-requested-by: Olaf Hering <olaf@aepfle.de>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   23199:d9f8316a8291
user:        Andrew Cooper <andrew.cooper3@citrix.com>
date:        Tue Dec 06 10:53:12 2011 +0000
    
    KEXEC: fix kexec_get_range_compat to fail vocally.
    
    Fail with -ERANGE rather than silently truncating 64bit values (a
    physical address and size) into 32bit integers for dom0 to consume.
    
    Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
    
    Simplify the bitwise arithmetic a bit.
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    xen-unstable changeset:   24358:9961a6d5356a
    xen-unstable date:        Mon Dec 05 19:42:46 2011 +0000
    
    
========================================
commit 3981d218912e186cb4205ee6732f446c177a36a2
Author: Jean Guyader <jean.guyader@eu.citrix.com>
Date:   Tue Nov 22 18:49:15 2011 +0000

    qemu-xen: Don't redefine libpci (3.1.7) defines.
    
    These values are already defined by the libpci heders in the version
    3.1.7.
    
    PCI_STATUS_66MHZ
    PCI_STATUS_RESERVED2
    PCI_STATUS_FAST_BACK
    PCI_MSIX_TABSIZE
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    (cherry picked from commit 174d92a73a5d5e67c49501383a519021b72a2468)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 08:39:16 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 08: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.xensource.com>)
	id 1RYvxu-0003Vg-8F; Fri, 09 Dec 2011 08:37:58 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RYvxt-0003Vb-IS
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 08:37:57 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1323419828!6694841!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDIwNw==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5682 invoked from network); 9 Dec 2011 08:37:08 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 08:37:08 -0000
X-IronPort-AV: E=Sophos;i="4.71,325,1320624000"; 
   d="scan'208";a="9377047"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 08:37:08 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 9 Dec 2011
	08:37:07 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: annie li <annie.li@oracle.com>
Date: Fri, 9 Dec 2011 08:37:04 +0000
In-Reply-To: <4EE1BC7E.3060904@oracle.com>
References: <1323336940-5382-1-git-send-email-annie.li@oracle.com>
	<1323337048-5426-1-git-send-email-annie.li@oracle.com>
	<291EDFCB1E9E224A99088639C4762022B5988E5528@LONPMAILBOX01.citrite.net>
	<4EE08B0D.80504@oracle.com>
	<291EDFCB1E9E224A99088639C4762022B5988E552D@LONPMAILBOX01.citrite.net>
	<4EE19A4D.9030500@oracle.com> <4EE1BC7E.3060904@oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323419827.20077.3.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "jeremy@goop.org" <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	"kurt.hackel@oracle.com" <kurt.hackel@oracle.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Paul Durrant <Paul.Durrant@citrix.com>
Subject: Re: [Xen-devel] [PATCH V2 1/2] xen/granttable: Support sub-page
	grants
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2011-12-09 at 07:45 +0000, annie li wrote:
> 
> On 2011-12-9 13:19, annie li wrote:
> > Hi Paul,
> >
> >>>> #define get_free_entry()    get_free_entries(1)
> > Is this necessary? Maybe you defined this to keep consistence with 
> > put_free_entry(ref)?
> > But other functions such as gnttab_grant_foreign_transfer and 
> > gnttab_grant_foreign_access all call get_free_entries(1). Maybe it is 
> > better to keep initial get_free_entries(1) code?
> Another approach is doing those work in a separate patch -- changing 
> get_free_entries to get_free_entry in following 4 functions:

I think you shouldn't get too bogged down in get_free_entry() vs
get_free_entries(1) for the purposes of this patch series.

Ian.

> gnttab_grant_foreign_access
> gnttab_grant_foreign_access_subpage
> gnttab_grant_foreign_access_trans
> gnttab_grant_foreign_transfer
> 
> Thanks
> Annie



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 08:39:16 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 08: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.xensource.com>)
	id 1RYvxu-0003Vg-8F; Fri, 09 Dec 2011 08:37:58 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RYvxt-0003Vb-IS
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 08:37:57 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1323419828!6694841!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDIwNw==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5682 invoked from network); 9 Dec 2011 08:37:08 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 08:37:08 -0000
X-IronPort-AV: E=Sophos;i="4.71,325,1320624000"; 
   d="scan'208";a="9377047"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 08:37:08 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 9 Dec 2011
	08:37:07 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: annie li <annie.li@oracle.com>
Date: Fri, 9 Dec 2011 08:37:04 +0000
In-Reply-To: <4EE1BC7E.3060904@oracle.com>
References: <1323336940-5382-1-git-send-email-annie.li@oracle.com>
	<1323337048-5426-1-git-send-email-annie.li@oracle.com>
	<291EDFCB1E9E224A99088639C4762022B5988E5528@LONPMAILBOX01.citrite.net>
	<4EE08B0D.80504@oracle.com>
	<291EDFCB1E9E224A99088639C4762022B5988E552D@LONPMAILBOX01.citrite.net>
	<4EE19A4D.9030500@oracle.com> <4EE1BC7E.3060904@oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323419827.20077.3.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "jeremy@goop.org" <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	"kurt.hackel@oracle.com" <kurt.hackel@oracle.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Paul Durrant <Paul.Durrant@citrix.com>
Subject: Re: [Xen-devel] [PATCH V2 1/2] xen/granttable: Support sub-page
	grants
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2011-12-09 at 07:45 +0000, annie li wrote:
> 
> On 2011-12-9 13:19, annie li wrote:
> > Hi Paul,
> >
> >>>> #define get_free_entry()    get_free_entries(1)
> > Is this necessary? Maybe you defined this to keep consistence with 
> > put_free_entry(ref)?
> > But other functions such as gnttab_grant_foreign_transfer and 
> > gnttab_grant_foreign_access all call get_free_entries(1). Maybe it is 
> > better to keep initial get_free_entries(1) code?
> Another approach is doing those work in a separate patch -- changing 
> get_free_entries to get_free_entry in following 4 functions:

I think you shouldn't get too bogged down in get_free_entry() vs
get_free_entries(1) for the purposes of this patch series.

Ian.

> gnttab_grant_foreign_access
> gnttab_grant_foreign_access_subpage
> gnttab_grant_foreign_access_trans
> gnttab_grant_foreign_transfer
> 
> Thanks
> Annie



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 08:45:49 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 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.xensource.com>)
	id 1RYw55-0003ft-5R; Fri, 09 Dec 2011 08:45:23 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RYw53-0003fi-7x
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 08:45:21 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1323420271!6174675!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDIwNw==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32739 invoked from network); 9 Dec 2011 08:44:31 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 08:44:31 -0000
X-IronPort-AV: E=Sophos;i="4.71,325,1320624000"; 
   d="scan'208";a="9377252"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 08:43:29 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 9 Dec 2011
	08:43:28 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 9 Dec 2011 08:43:28 +0000
In-Reply-To: <osstest-10458-mainreport@xen.org>
References: <osstest-10458-mainreport@xen.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323420208.20077.6.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [xen-4.1-testing test] 10458: trouble:
 broken/fail/pass
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2011-12-09 at 08:18 +0000, xen.org wrote:
> flight 10458 xen-4.1-testing real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/10458/


> Failures and problems with tests :-(
> 
> Tests which did not succeed and are blocking:
>  test-amd64-i386-xl-credit2    3 host-install(3)              broken
>  test-amd64-amd64-xl-sedf      3 host-install(3)              broken
>  test-amd64-amd64-xl-winxpsp3  3 host-install(3)              broken
>  test-amd64-amd64-pv           3 host-install(3)              broken
>  test-amd64-i386-win-vcpus1    3 host-install(3)              broken

These host-install failures and the ones in xen-unstable flight 10458
are all on "earwig" which was supposed to have been removed from the
pool due to being dodgy.

>  test-amd64-i386-pv            3 host-install(3)              broken   in 10444
>  test-i386-i386-win            3 host-install(3)              broken   in 10444

Confused by these since the URL above seems to suggest these passed...

Ian.

> Tests which are failing intermittently (not blocking):
>  test-amd64-amd64-xl-sedf-pin 14 guest-localmigrate/x10      fail pass in 10444
> 
> Tests which did not succeed, but are not blocking,
> including regressions (tests previously passed) regarded as allowable:
>  test-amd64-i386-xend-winxpsp3  7 windows-install              fail  never pass
>  test-i386-i386-xl-winxpsp3    7 windows-install              fail   never pass
>  test-amd64-amd64-xl-win7-amd64  7 windows-install              fail never pass
>  test-amd64-i386-xl-win7-amd64  7 windows-install              fail  never pass
>  test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install          fail never pass
>  test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
>  test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
>  test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
>  test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
>  test-i386-i386-xl-win        13 guest-stop                   fail   never pass
>  test-amd64-i386-win          16 leak-check/check             fail   never pass
>  test-amd64-amd64-win         16 leak-check/check             fail   never pass
>  test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
>  test-i386-i386-win           16 leak-check/check             fail   never pass
>  test-amd64-i386-win-vcpus1   16 leak-check/check      fail in 10444 never pass
> 
> version targeted for testing:
>  xen                  1c89f7d29fbb
> baseline version:
>  xen                  d9f8316a8291
> 
> ------------------------------------------------------------
> People who touched revisions under test:
>   Andrew Cooper <andrew.cooper3@citrix.com>
>   Ian Jackson <ian.jackson@eu.citrix.com>
>   Jean Guyader <jean.guyader@eu.citrix.com>
>   Keir Fraser <keir@xen.org>
>   Olaf Hering <olaf@aepfle.de>
> ------------------------------------------------------------
> 
> jobs:
>  build-amd64                                                  pass    
>  build-i386                                                   pass    
>  build-amd64-oldkern                                          pass    
>  build-i386-oldkern                                           pass    
>  build-amd64-pvops                                            pass    
>  build-i386-pvops                                             pass    
>  test-amd64-amd64-xl                                          pass    
>  test-amd64-i386-xl                                           pass    
>  test-i386-i386-xl                                            pass    
>  test-amd64-i386-rhel6hvm-amd                                 fail    
>  test-amd64-amd64-xl-win7-amd64                               fail    
>  test-amd64-i386-xl-win7-amd64                                fail    
>  test-amd64-i386-xl-credit2                                   broken  
>  test-amd64-amd64-xl-pcipt-intel                              fail    
>  test-amd64-i386-rhel6hvm-intel                               fail    
>  test-amd64-i386-xl-multivcpu                                 pass    
>  test-amd64-amd64-pair                                        pass    
>  test-amd64-i386-pair                                         pass    
>  test-i386-i386-pair                                          pass    
>  test-amd64-amd64-xl-sedf-pin                                 fail    
>  test-amd64-amd64-pv                                          broken  
>  test-amd64-i386-pv                                           pass    
>  test-i386-i386-pv                                            pass    
>  test-amd64-amd64-xl-sedf                                     broken  
>  test-amd64-i386-win-vcpus1                                   broken  
>  test-amd64-i386-xl-win-vcpus1                                fail    
>  test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
>  test-amd64-amd64-win                                         fail    
>  test-amd64-i386-win                                          fail    
>  test-i386-i386-win                                           fail    
>  test-amd64-amd64-xl-win                                      fail    
>  test-i386-i386-xl-win                                        fail    
>  test-amd64-i386-xend-winxpsp3                                fail    
>  test-amd64-amd64-xl-winxpsp3                                 broken  
>  test-i386-i386-xl-winxpsp3                                   fail    
> 
> 
> ------------------------------------------------------------
> sg-report-flight on woking.cam.xci-test.com
> logs: /home/xc_osstest/logs
> images: /home/xc_osstest/images
> 
> Logs, config files, etc. are available at
>     http://www.chiark.greenend.org.uk/~xensrcts/logs
> 
> Test harness code can be found at
>     http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary
> 
> 
> Not pushing.
> 
> ------------------------------------------------------------
> changeset:   23201:1c89f7d29fbb
> tag:         tip
> user:        Olaf Hering <olaf@aepfle.de>
> date:        Thu Dec 08 16:50:28 2011 +0000
>     
>     tools: init.d/Linux/xencommons: load evtchn and gntdev modules
>     
>     There is currently no code in the kernel to trigger autoload of the
>     evtchn or gntdev drivers. Load them manually during xencommons start.
>     Handle both pvops and xenlinux module names.
>     
>     Signed-off-by: Olaf Hering <olaf@aepfle.de>
>     Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
>     Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
>     
>     xen-unstable changeset: 24334:9c8aff308002
>     Backport-requested-by: Olaf Hering <olaf@aepfle.de>
>     Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
>     
>     
> changeset:   23200:7a4fad2d4b05
> user:        Olaf Hering <olaf@aepfle.de>
> date:        Thu Dec 08 16:50:16 2011 +0000
>     
>     tools: init.d/Linux/xencommons: run script only when needed
>     
>     Currently xencommons prints an error that /proc/xen/capabilities does
>     not exist when started on a non-xen kernel.
>     
>     Update the xencommons script to run only when needed:
>     - do not run if /proc/xen does not exist
>     - check if /proc/xen/capabilities exists before doing the grep for dom0
>     
>     Signed-off-by: Olaf Hering <olaf@aepfle.de>
>     Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
>     Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
>     
>     xen-unstable changeset: 24333:4002e63b188a
>     Backport-requested-by: Olaf Hering <olaf@aepfle.de>
>     Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
>     
>     
> changeset:   23199:d9f8316a8291
> user:        Andrew Cooper <andrew.cooper3@citrix.com>
> date:        Tue Dec 06 10:53:12 2011 +0000
>     
>     KEXEC: fix kexec_get_range_compat to fail vocally.
>     
>     Fail with -ERANGE rather than silently truncating 64bit values (a
>     physical address and size) into 32bit integers for dom0 to consume.
>     
>     Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
>     
>     Simplify the bitwise arithmetic a bit.
>     
>     Signed-off-by: Keir Fraser <keir@xen.org>
>     xen-unstable changeset:   24358:9961a6d5356a
>     xen-unstable date:        Mon Dec 05 19:42:46 2011 +0000
>     
>     
> ========================================
> commit 3981d218912e186cb4205ee6732f446c177a36a2
> Author: Jean Guyader <jean.guyader@eu.citrix.com>
> Date:   Tue Nov 22 18:49:15 2011 +0000
> 
>     qemu-xen: Don't redefine libpci (3.1.7) defines.
>     
>     These values are already defined by the libpci heders in the version
>     3.1.7.
>     
>     PCI_STATUS_66MHZ
>     PCI_STATUS_RESERVED2
>     PCI_STATUS_FAST_BACK
>     PCI_MSIX_TABSIZE
>     
>     Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
>     (cherry picked from commit 174d92a73a5d5e67c49501383a519021b72a2468)
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 08:45:49 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 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.xensource.com>)
	id 1RYw55-0003ft-5R; Fri, 09 Dec 2011 08:45:23 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RYw53-0003fi-7x
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 08:45:21 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1323420271!6174675!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDIwNw==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32739 invoked from network); 9 Dec 2011 08:44:31 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 08:44:31 -0000
X-IronPort-AV: E=Sophos;i="4.71,325,1320624000"; 
   d="scan'208";a="9377252"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 08:43:29 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 9 Dec 2011
	08:43:28 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 9 Dec 2011 08:43:28 +0000
In-Reply-To: <osstest-10458-mainreport@xen.org>
References: <osstest-10458-mainreport@xen.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323420208.20077.6.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [xen-4.1-testing test] 10458: trouble:
 broken/fail/pass
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2011-12-09 at 08:18 +0000, xen.org wrote:
> flight 10458 xen-4.1-testing real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/10458/


> Failures and problems with tests :-(
> 
> Tests which did not succeed and are blocking:
>  test-amd64-i386-xl-credit2    3 host-install(3)              broken
>  test-amd64-amd64-xl-sedf      3 host-install(3)              broken
>  test-amd64-amd64-xl-winxpsp3  3 host-install(3)              broken
>  test-amd64-amd64-pv           3 host-install(3)              broken
>  test-amd64-i386-win-vcpus1    3 host-install(3)              broken

These host-install failures and the ones in xen-unstable flight 10458
are all on "earwig" which was supposed to have been removed from the
pool due to being dodgy.

>  test-amd64-i386-pv            3 host-install(3)              broken   in 10444
>  test-i386-i386-win            3 host-install(3)              broken   in 10444

Confused by these since the URL above seems to suggest these passed...

Ian.

> Tests which are failing intermittently (not blocking):
>  test-amd64-amd64-xl-sedf-pin 14 guest-localmigrate/x10      fail pass in 10444
> 
> Tests which did not succeed, but are not blocking,
> including regressions (tests previously passed) regarded as allowable:
>  test-amd64-i386-xend-winxpsp3  7 windows-install              fail  never pass
>  test-i386-i386-xl-winxpsp3    7 windows-install              fail   never pass
>  test-amd64-amd64-xl-win7-amd64  7 windows-install              fail never pass
>  test-amd64-i386-xl-win7-amd64  7 windows-install              fail  never pass
>  test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install          fail never pass
>  test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
>  test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
>  test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
>  test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
>  test-i386-i386-xl-win        13 guest-stop                   fail   never pass
>  test-amd64-i386-win          16 leak-check/check             fail   never pass
>  test-amd64-amd64-win         16 leak-check/check             fail   never pass
>  test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
>  test-i386-i386-win           16 leak-check/check             fail   never pass
>  test-amd64-i386-win-vcpus1   16 leak-check/check      fail in 10444 never pass
> 
> version targeted for testing:
>  xen                  1c89f7d29fbb
> baseline version:
>  xen                  d9f8316a8291
> 
> ------------------------------------------------------------
> People who touched revisions under test:
>   Andrew Cooper <andrew.cooper3@citrix.com>
>   Ian Jackson <ian.jackson@eu.citrix.com>
>   Jean Guyader <jean.guyader@eu.citrix.com>
>   Keir Fraser <keir@xen.org>
>   Olaf Hering <olaf@aepfle.de>
> ------------------------------------------------------------
> 
> jobs:
>  build-amd64                                                  pass    
>  build-i386                                                   pass    
>  build-amd64-oldkern                                          pass    
>  build-i386-oldkern                                           pass    
>  build-amd64-pvops                                            pass    
>  build-i386-pvops                                             pass    
>  test-amd64-amd64-xl                                          pass    
>  test-amd64-i386-xl                                           pass    
>  test-i386-i386-xl                                            pass    
>  test-amd64-i386-rhel6hvm-amd                                 fail    
>  test-amd64-amd64-xl-win7-amd64                               fail    
>  test-amd64-i386-xl-win7-amd64                                fail    
>  test-amd64-i386-xl-credit2                                   broken  
>  test-amd64-amd64-xl-pcipt-intel                              fail    
>  test-amd64-i386-rhel6hvm-intel                               fail    
>  test-amd64-i386-xl-multivcpu                                 pass    
>  test-amd64-amd64-pair                                        pass    
>  test-amd64-i386-pair                                         pass    
>  test-i386-i386-pair                                          pass    
>  test-amd64-amd64-xl-sedf-pin                                 fail    
>  test-amd64-amd64-pv                                          broken  
>  test-amd64-i386-pv                                           pass    
>  test-i386-i386-pv                                            pass    
>  test-amd64-amd64-xl-sedf                                     broken  
>  test-amd64-i386-win-vcpus1                                   broken  
>  test-amd64-i386-xl-win-vcpus1                                fail    
>  test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
>  test-amd64-amd64-win                                         fail    
>  test-amd64-i386-win                                          fail    
>  test-i386-i386-win                                           fail    
>  test-amd64-amd64-xl-win                                      fail    
>  test-i386-i386-xl-win                                        fail    
>  test-amd64-i386-xend-winxpsp3                                fail    
>  test-amd64-amd64-xl-winxpsp3                                 broken  
>  test-i386-i386-xl-winxpsp3                                   fail    
> 
> 
> ------------------------------------------------------------
> sg-report-flight on woking.cam.xci-test.com
> logs: /home/xc_osstest/logs
> images: /home/xc_osstest/images
> 
> Logs, config files, etc. are available at
>     http://www.chiark.greenend.org.uk/~xensrcts/logs
> 
> Test harness code can be found at
>     http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary
> 
> 
> Not pushing.
> 
> ------------------------------------------------------------
> changeset:   23201:1c89f7d29fbb
> tag:         tip
> user:        Olaf Hering <olaf@aepfle.de>
> date:        Thu Dec 08 16:50:28 2011 +0000
>     
>     tools: init.d/Linux/xencommons: load evtchn and gntdev modules
>     
>     There is currently no code in the kernel to trigger autoload of the
>     evtchn or gntdev drivers. Load them manually during xencommons start.
>     Handle both pvops and xenlinux module names.
>     
>     Signed-off-by: Olaf Hering <olaf@aepfle.de>
>     Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
>     Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
>     
>     xen-unstable changeset: 24334:9c8aff308002
>     Backport-requested-by: Olaf Hering <olaf@aepfle.de>
>     Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
>     
>     
> changeset:   23200:7a4fad2d4b05
> user:        Olaf Hering <olaf@aepfle.de>
> date:        Thu Dec 08 16:50:16 2011 +0000
>     
>     tools: init.d/Linux/xencommons: run script only when needed
>     
>     Currently xencommons prints an error that /proc/xen/capabilities does
>     not exist when started on a non-xen kernel.
>     
>     Update the xencommons script to run only when needed:
>     - do not run if /proc/xen does not exist
>     - check if /proc/xen/capabilities exists before doing the grep for dom0
>     
>     Signed-off-by: Olaf Hering <olaf@aepfle.de>
>     Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
>     Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
>     
>     xen-unstable changeset: 24333:4002e63b188a
>     Backport-requested-by: Olaf Hering <olaf@aepfle.de>
>     Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
>     
>     
> changeset:   23199:d9f8316a8291
> user:        Andrew Cooper <andrew.cooper3@citrix.com>
> date:        Tue Dec 06 10:53:12 2011 +0000
>     
>     KEXEC: fix kexec_get_range_compat to fail vocally.
>     
>     Fail with -ERANGE rather than silently truncating 64bit values (a
>     physical address and size) into 32bit integers for dom0 to consume.
>     
>     Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
>     
>     Simplify the bitwise arithmetic a bit.
>     
>     Signed-off-by: Keir Fraser <keir@xen.org>
>     xen-unstable changeset:   24358:9961a6d5356a
>     xen-unstable date:        Mon Dec 05 19:42:46 2011 +0000
>     
>     
> ========================================
> commit 3981d218912e186cb4205ee6732f446c177a36a2
> Author: Jean Guyader <jean.guyader@eu.citrix.com>
> Date:   Tue Nov 22 18:49:15 2011 +0000
> 
>     qemu-xen: Don't redefine libpci (3.1.7) defines.
>     
>     These values are already defined by the libpci heders in the version
>     3.1.7.
>     
>     PCI_STATUS_66MHZ
>     PCI_STATUS_RESERVED2
>     PCI_STATUS_FAST_BACK
>     PCI_MSIX_TABSIZE
>     
>     Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
>     (cherry picked from commit 174d92a73a5d5e67c49501383a519021b72a2468)
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 08:49:38 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 08:49:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYw8o-0003nI-Ss; Fri, 09 Dec 2011 08:49:14 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RYw8n-0003n6-4e
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 08:49:13 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1323420503!4677092!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDIwNw==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4807 invoked from network); 9 Dec 2011 08:48:24 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 08:48:24 -0000
X-IronPort-AV: E=Sophos;i="4.71,325,1320624000"; 
   d="scan'208";a="9377373"
Received: from lonpmailmx02.citrite.net ([10.30.203.163])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 08:48:23 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.161]) by
	LONPMAILMX02.citrite.net ([10.30.203.163]) with mapi; Fri, 9 Dec 2011
	08:48:23 +0000
From: Paul Durrant <Paul.Durrant@citrix.com>
To: annie li <annie.li@oracle.com>
Date: Fri, 9 Dec 2011 08:48:32 +0000
Thread-Topic: [PATCH V2 1/2] xen/granttable: Support sub-page grants
Thread-Index: Acy2Tbyz/Cu3TveaSASWwXUnags4QwAAV9Sw
Message-ID: <291EDFCB1E9E224A99088639C4762022B5988E55CE@LONPMAILBOX01.citrite.net>
References: <1323336940-5382-1-git-send-email-annie.li@oracle.com>
	<1323337048-5426-1-git-send-email-annie.li@oracle.com>
	<291EDFCB1E9E224A99088639C4762022B5988E5528@LONPMAILBOX01.citrite.net>
	<4EE08B0D.80504@oracle.com>
	<291EDFCB1E9E224A99088639C4762022B5988E552D@LONPMAILBOX01.citrite.net>
	<4EE19A4D.9030500@oracle.com> <4EE1BC7E.3060904@oracle.com>
	<1323419827.20077.3.camel@zakaz.uk.xensource.com>
In-Reply-To: <1323419827.20077.3.camel@zakaz.uk.xensource.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "jeremy@goop.org" <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	"kurt.hackel@oracle.com" <kurt.hackel@oracle.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [Xen-devel] [PATCH V2 1/2] xen/granttable: Support sub-page
	grants
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> -----Original Message-----
> From: Ian Campbell
> Sent: 09 December 2011 08:37
> To: annie li
> Cc: Paul Durrant; xen-devel@lists.xensource.com; linux-
> kernel@vger.kernel.org; konrad.wilk@oracle.com; jeremy@goop.org;
> kurt.hackel@oracle.com
> Subject: Re: [PATCH V2 1/2] xen/granttable: Support sub-page grants
> 
> On Fri, 2011-12-09 at 07:45 +0000, annie li wrote:
> >
> > On 2011-12-9 13:19, annie li wrote:
> > > Hi Paul,
> > >
> > >>>> #define get_free_entry()    get_free_entries(1)
> > > Is this necessary? Maybe you defined this to keep consistence
> with
> > > put_free_entry(ref)?
> > > But other functions such as gnttab_grant_foreign_transfer and
> > > gnttab_grant_foreign_access all call get_free_entries(1). Maybe
> it
> > > is better to keep initial get_free_entries(1) code?
> > Another approach is doing those work in a separate patch --
> changing
> > get_free_entries to get_free_entry in following 4 functions:
> 
> I think you shouldn't get too bogged down in get_free_entry() vs
> get_free_entries(1) for the purposes of this patch series.
> 

Annie,

  Yes, don't worry about get_free_entry(). I only defined it for the sake of symmetry in the code I posted.

  Paul
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 08:49:38 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 08:49:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYw8o-0003nI-Ss; Fri, 09 Dec 2011 08:49:14 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RYw8n-0003n6-4e
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 08:49:13 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1323420503!4677092!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDIwNw==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4807 invoked from network); 9 Dec 2011 08:48:24 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 08:48:24 -0000
X-IronPort-AV: E=Sophos;i="4.71,325,1320624000"; 
   d="scan'208";a="9377373"
Received: from lonpmailmx02.citrite.net ([10.30.203.163])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 08:48:23 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.161]) by
	LONPMAILMX02.citrite.net ([10.30.203.163]) with mapi; Fri, 9 Dec 2011
	08:48:23 +0000
From: Paul Durrant <Paul.Durrant@citrix.com>
To: annie li <annie.li@oracle.com>
Date: Fri, 9 Dec 2011 08:48:32 +0000
Thread-Topic: [PATCH V2 1/2] xen/granttable: Support sub-page grants
Thread-Index: Acy2Tbyz/Cu3TveaSASWwXUnags4QwAAV9Sw
Message-ID: <291EDFCB1E9E224A99088639C4762022B5988E55CE@LONPMAILBOX01.citrite.net>
References: <1323336940-5382-1-git-send-email-annie.li@oracle.com>
	<1323337048-5426-1-git-send-email-annie.li@oracle.com>
	<291EDFCB1E9E224A99088639C4762022B5988E5528@LONPMAILBOX01.citrite.net>
	<4EE08B0D.80504@oracle.com>
	<291EDFCB1E9E224A99088639C4762022B5988E552D@LONPMAILBOX01.citrite.net>
	<4EE19A4D.9030500@oracle.com> <4EE1BC7E.3060904@oracle.com>
	<1323419827.20077.3.camel@zakaz.uk.xensource.com>
In-Reply-To: <1323419827.20077.3.camel@zakaz.uk.xensource.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "jeremy@goop.org" <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	"kurt.hackel@oracle.com" <kurt.hackel@oracle.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [Xen-devel] [PATCH V2 1/2] xen/granttable: Support sub-page
	grants
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> -----Original Message-----
> From: Ian Campbell
> Sent: 09 December 2011 08:37
> To: annie li
> Cc: Paul Durrant; xen-devel@lists.xensource.com; linux-
> kernel@vger.kernel.org; konrad.wilk@oracle.com; jeremy@goop.org;
> kurt.hackel@oracle.com
> Subject: Re: [PATCH V2 1/2] xen/granttable: Support sub-page grants
> 
> On Fri, 2011-12-09 at 07:45 +0000, annie li wrote:
> >
> > On 2011-12-9 13:19, annie li wrote:
> > > Hi Paul,
> > >
> > >>>> #define get_free_entry()    get_free_entries(1)
> > > Is this necessary? Maybe you defined this to keep consistence
> with
> > > put_free_entry(ref)?
> > > But other functions such as gnttab_grant_foreign_transfer and
> > > gnttab_grant_foreign_access all call get_free_entries(1). Maybe
> it
> > > is better to keep initial get_free_entries(1) code?
> > Another approach is doing those work in a separate patch --
> changing
> > get_free_entries to get_free_entry in following 4 functions:
> 
> I think you shouldn't get too bogged down in get_free_entry() vs
> get_free_entries(1) for the purposes of this patch series.
> 

Annie,

  Yes, don't worry about get_free_entry(). I only defined it for the sake of symmetry in the code I posted.

  Paul
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 09:17:39 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 09:17:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYwZs-00048B-OQ; Fri, 09 Dec 2011 09:17:12 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RYwZq-000484-Mw
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 09:17:11 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1323422157!44181258!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI2MQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27650 invoked from network); 9 Dec 2011 09:15:57 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 09:15:57 -0000
X-IronPort-AV: E=Sophos;i="4.71,325,1320624000"; 
   d="scan'208";a="9378003"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 09:16:26 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 9 Dec 2011
	09:16:26 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Fri, 9 Dec 2011 09:16:26 +0000
In-Reply-To: <20193.5581.714247.641528@mariner.uk.xensource.com>
References: <1323108621-22654-1-git-send-email-ian.jackson@eu.citrix.com>
	<1323108621-22654-15-git-send-email-ian.jackson@eu.citrix.com>
	<1323279343.2969.44.camel@zakaz.uk.xensource.com>
	<20193.5581.714247.641528@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323422186.20077.28.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 14/15] libxl: New API for providing OS
 events to libxl
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2011-12-08 at 19:53 +0000, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [PATCH 14/15] libxl: New API for providing OS events to libxl"):
> > > @@ -0,0 +1,711 @@
> > > +/*
> > > + * Copyright (C) 2011      Citrix Ltd.
> > > + *
> > > + * This program is free software; you can redistribute it and/or modify
> > > + * it under the terms of the GNU Lesser General Public License as published
> > > + * by the Free Software Foundation; version 2.1 only. with the special
> > > + * exception on linking described in file LICENSE.
> > 
> > I've only just noticed this but it is present in some other libxl files
> > too. There is no LICENSE file in tools/libxl:
> >         $ find -name LICENSE
> >         ./tools/ioemu-remote/LICENSE
> >         ./tools/ioemu-remote/tcg/LICENSE
> >         ./tools/ocaml/LICENSE
> >         ./xen/tools/figlet/LICENSE
> > 
> > I suspect this is a cut-and-paste-o, probably from tools/ocaml?
> 
> All the existing files in libxl/ mention this nonexistent file
> LICENCE.  I think we should fix this in a separate patch.  I'd argue
> that my copying of the existing text isn't making the situation worse.

Sure, I didn't mean to suggest you needed to fix this in this series, I
just happened to observe it here.

> > > + * The application's registration hooks should be called ONLY via
> > > + * these macros, with the ctx locked.  Likewise all the "occurred"
> > > + * entrypoints from the application should assert(!in_hook);
> > 
> > In RFC speak you mean MUST rather than should both times here, right?
> 
> In the immortal words of RFC2181:
> 
>   3. Terminology
> 
>      This memo does not use the oft used expressions MUST, SHOULD, MAY, or
>      their negative forms.  In some sections it may seem that a
>      specification is worded mildly, and hence some may infer that the
>      specification is optional.  That is not correct.  Anywhere that this
>      memo suggests that some action should be carried out, or must be
>      carried out, or that some behaviour is acceptable, or not, that is to
>      be considered as a fundamental aspect of this specification,
>      regardless of the specific words used.  If some behaviour or action
>      is truly optional, that will be clearly specified by the text.
> 
> If you think this is confusing I can change it to "must"...

I was mainly asking just to clarify my own understanding, as you point
out we don't use those "oft used expressions" in our comments.

> > > +int libxl__ev_fd_register(libxl__gc *gc, libxl__ev_fd *ev,
> > > +                          libxl__ev_fd_callback *func,
> > > +                          int fd, short events) {
> > 
> > Strictly speaking CODING_STYLE requires the { to be on the next line.
> 
> Oh, I probably have a lot of those.  Damn.

Yeah, I refrained from commenting every time ;-)

>   I'll try to remember to
> fix this up with some seddery somehow.

[...]
> > > +int libxl__ev_time_modify_abs(libxl__gc *gc, libxl__ev_time *ev,
> > > +                              struct timeval abs) {
> > > +    int rc;
> > > +
> > > +    CTX_LOCK;
> > > +
> > > +    assert(libxl__ev_time_isregistered(ev));
> > 
> > Why is there no deregister here? Is libxl__ev_time_modify_rel the only
> > caller?
> 
> It's currently the only caller but other bits of libxl are entitled to
> call it.  It's part of the facilities supplied to the rest of libxl.
> 
> There is no deregister because (a) we don't want to do that until
> we've called the hook, if necessary, in case the hook fails and (b) we
> have to explicitly deal with the two different cases:
>    1. existing event was infinite timeout, so not on queue, just
>       call register_finite which will do everything needed
>    2. existing event _wasn't_ infinite timeout, first call modify
>       hook, then fiddle about with the queue

Thanks, I was confused by the presence of a register/insert without a
corresponding unregister/delete but I see now that in one case the ev
isn't registered by definition (the infinite->finite case) and the other
you do actually remove it from the list (I missed that somehow).

[...]

> > > +        /* Now it's possible, though unlikely, that this was an event
> > > +         * from a previous use of the same slot with the same counterval.
> > > +         *
> > > +         * In that case either:
> > > +         *  - the event path is a child of the watch path, in
> > > +         *    which case this watch would really have generated this
> > > +         *    event if it had been registered soon enough and we are
> > > +         *    OK to give this possibly-spurious event to the caller; or
> > > +         * - it is not, in which case we must suppress it as the
> > > +         *   caller should not see events for unrelated paths.
> > > +         *
> > > +         * See also docs/misc/xenstore.txt.
> > > +         */
> > > +        size_t epathlen = strlen(epath);
> > > +        size_t wpathlen = strlen(w->path);
> > > +        if (epathlen < wpathlen ||
> > > +            memcmp(epath, w->path, wpathlen) ||
> > > +            (epathlen > wpathlen && epath[wpathlen] != '/')) {
> > > +            LIBXL__LOG(CTX, LIBXL__LOG_DEBUG,
> > > +                       "watch epath=%s token=%s: not child of wpath=%s",
> > > +                       epath, token, w->path);
> > 
> > It seems like this is worthy of a helper function of its own. Possibly
> > in libxenstore itself?
> 
> You mean "int xs_path_is_subpath_p(const char *parent, const char *child)" ?
> 
> Possibly.  I wouldn't be opposed to putting those 5 lines in
> libxenstore it there but AFAIK only this place in libxl needs it.

Wouldn't most users of libxenstore doing watches need something like
this (and probably either open code it or erroneously omit it)?

Regardless of where it goes moving that logic into a helper function
will make it clearer what is going on, both by having a descriptive name
and allowing the logic to be a bit more spaced out / commented, the last
clause in particular is slightly subtle.

> > > +    use = LIBXL_SLIST_FIRST(&CTX->watch_freeslots);
> > > +    assert(use);
> > > +    LIBXL_SLIST_REMOVE_HEAD(&CTX->watch_freeslots, empty);
> > 
> > I presume this is removing "use" from the list. It seems odd to refer to
> > that element of the list as HEAD and FIRST interchangeably since it
> > doesn't make this obvious but I guess we got this API from elsewhere.
> 
> Yes, FreeBSD.

Sorry, I knew that, I was trying to say "we got this API from elsewhere
so I guess we have to live with its quirks".

> > I think this behind the curtain stuff would be better encapsulated in a
> > macro up somewhere near the comment and libxl__ev_watch_slot.
> > 
> > > +    use->empty.sle_next = (void*)w;
> 
> How about:
> 
>   static void libxl__set_watch_slot_contents(libxl__ev_watch_slot *slot,
>                                              libxl__ev_xswatch *w) {
>       /* we look a bit behind the curtain of LIBXL_SLIST, to explicitly
>        * assign to the pointer that's the next link.  See the comment
>        * by the definition of libxl__ev_watch_slot */
>       slot->empty.sle_next = (void*)w;
>   }
> 
> Just below the the definition of libxl__watch_slot_contents.  That
> puts it near the other big comment and it's essentially the sister
> function.

Works for me.

> 
> > > +    CTX_LOCK;
> > > +
> > > +    if (w->slotnum >= 0) {
> > > +        char *token = watch_token(gc, w->slotnum, w->counterval);
> > > +        if (!xs_unwatch(CTX->xsh, w->path, token))
> > > +            /* Oh well, we will just get watch events forever more
> > > +             * and ignore them.  But we should complain to the log. */
> > > +            LIBXL__LOG_ERRNOVAL(CTX, LIBXL__LOG_ERROR, errno,
> > > +                                "remove watch for path %s", w->path);
> > 
> > Is it possible to also unwatch an unexpected watch at the point it
> > fires, IOW to try again later? I havn'et looked at the potential failure
> > cases of xs_unwatch so perhaps once it has failed there is no point in
> > trying again.
> 
> Offhand I think it can fail because:
>   - communication with xenstore has broken down, in which case trying
>     again is pretty pointless
>   - xenstore didn't recognise the watch (ie we or xenstore have a bug)
>     in which case trying to remove it is not sensible
> I'm also not sure exactly about the race implications.  What if you
> add and remove watches in different threads simultaneously ?

We are holding a lock at this point, I'm not sure if this is just
because of the associated datastructure frobbing or if their is an
(implicit or explicit) policy of holding the lock when adding or
removing watches.

> So I think this is probably best - and it's probably best not to do
> additional complicated flailing when either (a) things are already
> going wrong or (b) we just got a harmless lost race.

I'm convinced, thanks.

> > This seems like a good place to stop for the day. I'll pickup the rest
> > tomorrow.
> 
> Heh.  I should go to the pub :-).

Always a good call.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 09:17:39 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 09:17:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYwZs-00048B-OQ; Fri, 09 Dec 2011 09:17:12 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RYwZq-000484-Mw
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 09:17:11 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1323422157!44181258!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI2MQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27650 invoked from network); 9 Dec 2011 09:15:57 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 09:15:57 -0000
X-IronPort-AV: E=Sophos;i="4.71,325,1320624000"; 
   d="scan'208";a="9378003"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 09:16:26 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 9 Dec 2011
	09:16:26 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Fri, 9 Dec 2011 09:16:26 +0000
In-Reply-To: <20193.5581.714247.641528@mariner.uk.xensource.com>
References: <1323108621-22654-1-git-send-email-ian.jackson@eu.citrix.com>
	<1323108621-22654-15-git-send-email-ian.jackson@eu.citrix.com>
	<1323279343.2969.44.camel@zakaz.uk.xensource.com>
	<20193.5581.714247.641528@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323422186.20077.28.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 14/15] libxl: New API for providing OS
 events to libxl
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2011-12-08 at 19:53 +0000, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [PATCH 14/15] libxl: New API for providing OS events to libxl"):
> > > @@ -0,0 +1,711 @@
> > > +/*
> > > + * Copyright (C) 2011      Citrix Ltd.
> > > + *
> > > + * This program is free software; you can redistribute it and/or modify
> > > + * it under the terms of the GNU Lesser General Public License as published
> > > + * by the Free Software Foundation; version 2.1 only. with the special
> > > + * exception on linking described in file LICENSE.
> > 
> > I've only just noticed this but it is present in some other libxl files
> > too. There is no LICENSE file in tools/libxl:
> >         $ find -name LICENSE
> >         ./tools/ioemu-remote/LICENSE
> >         ./tools/ioemu-remote/tcg/LICENSE
> >         ./tools/ocaml/LICENSE
> >         ./xen/tools/figlet/LICENSE
> > 
> > I suspect this is a cut-and-paste-o, probably from tools/ocaml?
> 
> All the existing files in libxl/ mention this nonexistent file
> LICENCE.  I think we should fix this in a separate patch.  I'd argue
> that my copying of the existing text isn't making the situation worse.

Sure, I didn't mean to suggest you needed to fix this in this series, I
just happened to observe it here.

> > > + * The application's registration hooks should be called ONLY via
> > > + * these macros, with the ctx locked.  Likewise all the "occurred"
> > > + * entrypoints from the application should assert(!in_hook);
> > 
> > In RFC speak you mean MUST rather than should both times here, right?
> 
> In the immortal words of RFC2181:
> 
>   3. Terminology
> 
>      This memo does not use the oft used expressions MUST, SHOULD, MAY, or
>      their negative forms.  In some sections it may seem that a
>      specification is worded mildly, and hence some may infer that the
>      specification is optional.  That is not correct.  Anywhere that this
>      memo suggests that some action should be carried out, or must be
>      carried out, or that some behaviour is acceptable, or not, that is to
>      be considered as a fundamental aspect of this specification,
>      regardless of the specific words used.  If some behaviour or action
>      is truly optional, that will be clearly specified by the text.
> 
> If you think this is confusing I can change it to "must"...

I was mainly asking just to clarify my own understanding, as you point
out we don't use those "oft used expressions" in our comments.

> > > +int libxl__ev_fd_register(libxl__gc *gc, libxl__ev_fd *ev,
> > > +                          libxl__ev_fd_callback *func,
> > > +                          int fd, short events) {
> > 
> > Strictly speaking CODING_STYLE requires the { to be on the next line.
> 
> Oh, I probably have a lot of those.  Damn.

Yeah, I refrained from commenting every time ;-)

>   I'll try to remember to
> fix this up with some seddery somehow.

[...]
> > > +int libxl__ev_time_modify_abs(libxl__gc *gc, libxl__ev_time *ev,
> > > +                              struct timeval abs) {
> > > +    int rc;
> > > +
> > > +    CTX_LOCK;
> > > +
> > > +    assert(libxl__ev_time_isregistered(ev));
> > 
> > Why is there no deregister here? Is libxl__ev_time_modify_rel the only
> > caller?
> 
> It's currently the only caller but other bits of libxl are entitled to
> call it.  It's part of the facilities supplied to the rest of libxl.
> 
> There is no deregister because (a) we don't want to do that until
> we've called the hook, if necessary, in case the hook fails and (b) we
> have to explicitly deal with the two different cases:
>    1. existing event was infinite timeout, so not on queue, just
>       call register_finite which will do everything needed
>    2. existing event _wasn't_ infinite timeout, first call modify
>       hook, then fiddle about with the queue

Thanks, I was confused by the presence of a register/insert without a
corresponding unregister/delete but I see now that in one case the ev
isn't registered by definition (the infinite->finite case) and the other
you do actually remove it from the list (I missed that somehow).

[...]

> > > +        /* Now it's possible, though unlikely, that this was an event
> > > +         * from a previous use of the same slot with the same counterval.
> > > +         *
> > > +         * In that case either:
> > > +         *  - the event path is a child of the watch path, in
> > > +         *    which case this watch would really have generated this
> > > +         *    event if it had been registered soon enough and we are
> > > +         *    OK to give this possibly-spurious event to the caller; or
> > > +         * - it is not, in which case we must suppress it as the
> > > +         *   caller should not see events for unrelated paths.
> > > +         *
> > > +         * See also docs/misc/xenstore.txt.
> > > +         */
> > > +        size_t epathlen = strlen(epath);
> > > +        size_t wpathlen = strlen(w->path);
> > > +        if (epathlen < wpathlen ||
> > > +            memcmp(epath, w->path, wpathlen) ||
> > > +            (epathlen > wpathlen && epath[wpathlen] != '/')) {
> > > +            LIBXL__LOG(CTX, LIBXL__LOG_DEBUG,
> > > +                       "watch epath=%s token=%s: not child of wpath=%s",
> > > +                       epath, token, w->path);
> > 
> > It seems like this is worthy of a helper function of its own. Possibly
> > in libxenstore itself?
> 
> You mean "int xs_path_is_subpath_p(const char *parent, const char *child)" ?
> 
> Possibly.  I wouldn't be opposed to putting those 5 lines in
> libxenstore it there but AFAIK only this place in libxl needs it.

Wouldn't most users of libxenstore doing watches need something like
this (and probably either open code it or erroneously omit it)?

Regardless of where it goes moving that logic into a helper function
will make it clearer what is going on, both by having a descriptive name
and allowing the logic to be a bit more spaced out / commented, the last
clause in particular is slightly subtle.

> > > +    use = LIBXL_SLIST_FIRST(&CTX->watch_freeslots);
> > > +    assert(use);
> > > +    LIBXL_SLIST_REMOVE_HEAD(&CTX->watch_freeslots, empty);
> > 
> > I presume this is removing "use" from the list. It seems odd to refer to
> > that element of the list as HEAD and FIRST interchangeably since it
> > doesn't make this obvious but I guess we got this API from elsewhere.
> 
> Yes, FreeBSD.

Sorry, I knew that, I was trying to say "we got this API from elsewhere
so I guess we have to live with its quirks".

> > I think this behind the curtain stuff would be better encapsulated in a
> > macro up somewhere near the comment and libxl__ev_watch_slot.
> > 
> > > +    use->empty.sle_next = (void*)w;
> 
> How about:
> 
>   static void libxl__set_watch_slot_contents(libxl__ev_watch_slot *slot,
>                                              libxl__ev_xswatch *w) {
>       /* we look a bit behind the curtain of LIBXL_SLIST, to explicitly
>        * assign to the pointer that's the next link.  See the comment
>        * by the definition of libxl__ev_watch_slot */
>       slot->empty.sle_next = (void*)w;
>   }
> 
> Just below the the definition of libxl__watch_slot_contents.  That
> puts it near the other big comment and it's essentially the sister
> function.

Works for me.

> 
> > > +    CTX_LOCK;
> > > +
> > > +    if (w->slotnum >= 0) {
> > > +        char *token = watch_token(gc, w->slotnum, w->counterval);
> > > +        if (!xs_unwatch(CTX->xsh, w->path, token))
> > > +            /* Oh well, we will just get watch events forever more
> > > +             * and ignore them.  But we should complain to the log. */
> > > +            LIBXL__LOG_ERRNOVAL(CTX, LIBXL__LOG_ERROR, errno,
> > > +                                "remove watch for path %s", w->path);
> > 
> > Is it possible to also unwatch an unexpected watch at the point it
> > fires, IOW to try again later? I havn'et looked at the potential failure
> > cases of xs_unwatch so perhaps once it has failed there is no point in
> > trying again.
> 
> Offhand I think it can fail because:
>   - communication with xenstore has broken down, in which case trying
>     again is pretty pointless
>   - xenstore didn't recognise the watch (ie we or xenstore have a bug)
>     in which case trying to remove it is not sensible
> I'm also not sure exactly about the race implications.  What if you
> add and remove watches in different threads simultaneously ?

We are holding a lock at this point, I'm not sure if this is just
because of the associated datastructure frobbing or if their is an
(implicit or explicit) policy of holding the lock when adding or
removing watches.

> So I think this is probably best - and it's probably best not to do
> additional complicated flailing when either (a) things are already
> going wrong or (b) we just got a harmless lost race.

I'm convinced, thanks.

> > This seems like a good place to stop for the day. I'll pickup the rest
> > tomorrow.
> 
> Heh.  I should go to the pub :-).

Always a good call.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 09:58:03 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 09: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.xensource.com>)
	id 1RYxCk-0005OJ-RD; Fri, 09 Dec 2011 09:57:22 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RYxCj-0005Ny-Qg
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 09:57:22 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1323424592!6536594!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI2MQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2810 invoked from network); 9 Dec 2011 09:56:32 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 09:56:32 -0000
X-IronPort-AV: E=Sophos;i="4.71,325,1320624000"; 
   d="scan'208";a="9378971"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 09:56:32 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 09:56:32 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RYxBw-0008DK-8P; Fri, 09 Dec 2011 09:56:32 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RYxBw-0003nT-51;
	Fri, 09 Dec 2011 09:56:32 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20193.56141.873830.341444@mariner.uk.xensource.com>
Date: Fri, 9 Dec 2011 09:56:29 +0000
To: Jan Beulich <JBeulich@suse.com>
In-Reply-To: <4EE07F910200007800066299@nat28.tlf.novell.com>
References: <osstest-10409-mainreport@xen.org>
	<4EE07F910200007800066299@nat28.tlf.novell.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [xen-unstable test] 10409: regressions - trouble:
 broken/fail/pass
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Jan Beulich writes ("Re: [Xen-devel] [xen-unstable test] 10409: regressions - trouble: broken/fail/pass"):
...
> > Tests which did not succeed and are blocking:
> >  test-amd64-i386-xl-win7-amd64  3 host-install(3)              broken
> 
> earwig was supposed to be removed from the test pool - it's
> apparently back in,

Yes.  It seems one of my maintenance scripts which I ran recently has
a bug which caused earwig to be returned to the test pool.  I have
fixed this more properly this time.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 09:58:03 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 09: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.xensource.com>)
	id 1RYxCk-0005OJ-RD; Fri, 09 Dec 2011 09:57:22 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RYxCj-0005Ny-Qg
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 09:57:22 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1323424592!6536594!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI2MQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2810 invoked from network); 9 Dec 2011 09:56:32 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 09:56:32 -0000
X-IronPort-AV: E=Sophos;i="4.71,325,1320624000"; 
   d="scan'208";a="9378971"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 09:56:32 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 09:56:32 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RYxBw-0008DK-8P; Fri, 09 Dec 2011 09:56:32 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RYxBw-0003nT-51;
	Fri, 09 Dec 2011 09:56:32 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20193.56141.873830.341444@mariner.uk.xensource.com>
Date: Fri, 9 Dec 2011 09:56:29 +0000
To: Jan Beulich <JBeulich@suse.com>
In-Reply-To: <4EE07F910200007800066299@nat28.tlf.novell.com>
References: <osstest-10409-mainreport@xen.org>
	<4EE07F910200007800066299@nat28.tlf.novell.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [xen-unstable test] 10409: regressions - trouble:
 broken/fail/pass
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Jan Beulich writes ("Re: [Xen-devel] [xen-unstable test] 10409: regressions - trouble: broken/fail/pass"):
...
> > Tests which did not succeed and are blocking:
> >  test-amd64-i386-xl-win7-amd64  3 host-install(3)              broken
> 
> earwig was supposed to be removed from the test pool - it's
> apparently back in,

Yes.  It seems one of my maintenance scripts which I ran recently has
a bug which caused earwig to be returned to the test pool.  I have
fixed this more properly this time.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 10:00:53 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 10: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.xensource.com>)
	id 1RYxFE-0005XM-DV; Fri, 09 Dec 2011 09:59:56 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RYxFC-0005X8-SG
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 09:59:55 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1323424712!47189416!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI2MQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1459 invoked from network); 9 Dec 2011 09:58:32 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 09:58:32 -0000
X-IronPort-AV: E=Sophos;i="4.71,325,1320624000"; 
   d="scan'208";a="9379043"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 09:59:10 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 09:59:09 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RYxET-0008Dh-I3; Fri, 09 Dec 2011 09:59:09 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RYxET-0003nq-Gi;
	Fri, 09 Dec 2011 09:59:09 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20193.56301.505836.911066@mariner.uk.xensource.com>
Date: Fri, 9 Dec 2011 09:59:09 +0000
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
In-Reply-To: <6ad4a8da105e97d81fbe.1323330441@xdev.gridcentric.ca>
References: <patchbomb.1323330435@xdev.gridcentric.ca>
	<6ad4a8da105e97d81fbe.1323330441@xdev.gridcentric.ca>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"andres@gridcentric.ca" <andres@gridcentric.ca>, "Tim
	\(Xen.org\)" <tim@xen.org>, "keir.xen@gmail.com" <keir.xen@gmail.com>,
	"JBeulich@suse.com" <JBeulich@suse.com>,
	"adin@gridcentric.ca" <adin@gridcentric.ca>
Subject: Re: [Xen-devel] [PATCH 06 of 18] Tools: Update libxc mem sharing
	interface
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Andres Lagar-Cavilla writes ("[PATCH 06 of 18] Tools: Update libxc mem sharing interface"):
>  tools/libxc/xc_memshr.c |  19 ++++++++++++++++++-
>  tools/libxc/xenctrl.h   |   7 ++++++-
>  2 files changed, 24 insertions(+), 2 deletions(-)
> 
> 
> Previosuly, the mem sharing code would return an opaque handle
> to index shared pages (and nominees) in its global hash table.
> By removing the hash table, the handle becomes a version, to
> avoid sharing a stale version of a page. Thus, libxc wrappers
> need to be updated accordingly.
> 
> Signed-off-by: Adin Scannell <adin@scannell.ca>
> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

(assuming the hypervisor changes are OK, obviously)

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 10:00:53 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 10: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.xensource.com>)
	id 1RYxFE-0005XM-DV; Fri, 09 Dec 2011 09:59:56 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RYxFC-0005X8-SG
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 09:59:55 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1323424712!47189416!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI2MQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1459 invoked from network); 9 Dec 2011 09:58:32 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 09:58:32 -0000
X-IronPort-AV: E=Sophos;i="4.71,325,1320624000"; 
   d="scan'208";a="9379043"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 09:59:10 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 09:59:09 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RYxET-0008Dh-I3; Fri, 09 Dec 2011 09:59:09 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RYxET-0003nq-Gi;
	Fri, 09 Dec 2011 09:59:09 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20193.56301.505836.911066@mariner.uk.xensource.com>
Date: Fri, 9 Dec 2011 09:59:09 +0000
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
In-Reply-To: <6ad4a8da105e97d81fbe.1323330441@xdev.gridcentric.ca>
References: <patchbomb.1323330435@xdev.gridcentric.ca>
	<6ad4a8da105e97d81fbe.1323330441@xdev.gridcentric.ca>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"andres@gridcentric.ca" <andres@gridcentric.ca>, "Tim
	\(Xen.org\)" <tim@xen.org>, "keir.xen@gmail.com" <keir.xen@gmail.com>,
	"JBeulich@suse.com" <JBeulich@suse.com>,
	"adin@gridcentric.ca" <adin@gridcentric.ca>
Subject: Re: [Xen-devel] [PATCH 06 of 18] Tools: Update libxc mem sharing
	interface
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Andres Lagar-Cavilla writes ("[PATCH 06 of 18] Tools: Update libxc mem sharing interface"):
>  tools/libxc/xc_memshr.c |  19 ++++++++++++++++++-
>  tools/libxc/xenctrl.h   |   7 ++++++-
>  2 files changed, 24 insertions(+), 2 deletions(-)
> 
> 
> Previosuly, the mem sharing code would return an opaque handle
> to index shared pages (and nominees) in its global hash table.
> By removing the hash table, the handle becomes a version, to
> avoid sharing a stale version of a page. Thus, libxc wrappers
> need to be updated accordingly.
> 
> Signed-off-by: Adin Scannell <adin@scannell.ca>
> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

(assuming the hypervisor changes are OK, obviously)

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 10:01:16 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 10:01:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYxG4-0005eM-Sm; Fri, 09 Dec 2011 10:00:48 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RYxG3-0005dy-OL
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 10:00:47 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1323424798!7533615!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI2MQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29111 invoked from network); 9 Dec 2011 09:59:58 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 09:59:58 -0000
X-IronPort-AV: E=Sophos;i="4.71,325,1320624000"; 
   d="scan'208";a="9379065"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 09:59:58 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 09:59:58 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RYxFG-0008Du-6f; Fri, 09 Dec 2011 09:59:58 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RYxFG-0003nu-5p;
	Fri, 09 Dec 2011 09:59:58 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20193.56350.169825.516321@mariner.uk.xensource.com>
Date: Fri, 9 Dec 2011 09:59:58 +0000
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
In-Reply-To: <8d2a8094ace5c80f1685.1323330442@xdev.gridcentric.ca>
References: <patchbomb.1323330435@xdev.gridcentric.ca>
	<8d2a8094ace5c80f1685.1323330442@xdev.gridcentric.ca>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"andres@gridcentric.ca" <andres@gridcentric.ca>, "Tim
	\(Xen.org\)" <tim@xen.org>, "keir.xen@gmail.com" <keir.xen@gmail.com>,
	"JBeulich@suse.com" <JBeulich@suse.com>,
	"adin@gridcentric.ca" <adin@gridcentric.ca>
Subject: Re: [Xen-devel] [PATCH 07 of 18] Tools: Update memshr tool to use
	new sharing API
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Andres Lagar-Cavilla writes ("[PATCH 07 of 18] Tools: Update memshr tool to use new sharing API"):
> The only (in-tree, that we know of) consumer of the mem sharing API
> is the memshr tool (conditionally linked into blktap2). Update it to
> use the new API.
> 
> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 10:01:16 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 10:01:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYxG4-0005eM-Sm; Fri, 09 Dec 2011 10:00:48 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RYxG3-0005dy-OL
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 10:00:47 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1323424798!7533615!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI2MQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29111 invoked from network); 9 Dec 2011 09:59:58 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 09:59:58 -0000
X-IronPort-AV: E=Sophos;i="4.71,325,1320624000"; 
   d="scan'208";a="9379065"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 09:59:58 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 09:59:58 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RYxFG-0008Du-6f; Fri, 09 Dec 2011 09:59:58 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RYxFG-0003nu-5p;
	Fri, 09 Dec 2011 09:59:58 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20193.56350.169825.516321@mariner.uk.xensource.com>
Date: Fri, 9 Dec 2011 09:59:58 +0000
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
In-Reply-To: <8d2a8094ace5c80f1685.1323330442@xdev.gridcentric.ca>
References: <patchbomb.1323330435@xdev.gridcentric.ca>
	<8d2a8094ace5c80f1685.1323330442@xdev.gridcentric.ca>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"andres@gridcentric.ca" <andres@gridcentric.ca>, "Tim
	\(Xen.org\)" <tim@xen.org>, "keir.xen@gmail.com" <keir.xen@gmail.com>,
	"JBeulich@suse.com" <JBeulich@suse.com>,
	"adin@gridcentric.ca" <adin@gridcentric.ca>
Subject: Re: [Xen-devel] [PATCH 07 of 18] Tools: Update memshr tool to use
	new sharing API
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Andres Lagar-Cavilla writes ("[PATCH 07 of 18] Tools: Update memshr tool to use new sharing API"):
> The only (in-tree, that we know of) consumer of the mem sharing API
> is the memshr tool (conditionally linked into blktap2). Update it to
> use the new API.
> 
> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 10:02:33 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 10: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.xensource.com>)
	id 1RYxHN-0005p2-CX; Fri, 09 Dec 2011 10:02:09 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RYxHL-0005oO-1K
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 10:02:07 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1323424877!6563731!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI2MQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31943 invoked from network); 9 Dec 2011 10:01:18 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 10:01:18 -0000
X-IronPort-AV: E=Sophos;i="4.71,325,1320624000"; 
   d="scan'208";a="9379101"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 10:01:17 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 10:01:17 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RYxGX-0008ED-9B; Fri, 09 Dec 2011 10:01:17 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RYxGX-0003o0-8G;
	Fri, 09 Dec 2011 10:01:17 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20193.56429.242433.459883@mariner.uk.xensource.com>
Date: Fri, 9 Dec 2011 10:01:17 +0000
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
In-Reply-To: <b398fc97ab19818b7a22.1323330440@xdev.gridcentric.ca>
References: <patchbomb.1323330435@xdev.gridcentric.ca>
	<b398fc97ab19818b7a22.1323330440@xdev.gridcentric.ca>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"andres@gridcentric.ca" <andres@gridcentric.ca>, "Tim
	\(Xen.org\)" <tim@xen.org>, "keir.xen@gmail.com" <keir.xen@gmail.com>,
	"JBeulich@suse.com" <JBeulich@suse.com>,
	"adin@gridcentric.ca" <adin@gridcentric.ca>
Subject: Re: [Xen-devel] [PATCH 05 of 18] Tools: Do not assume sharing
 target is dom0 in libxc wrappers
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Andres Lagar-Cavilla writes ("[PATCH 05 of 18] Tools: Do not assume sharing target is dom0 in libxc wrappers"):
> The libxc wrapper that shares two pages always assumed one
> of the pages was mapped by dom0. Expand the API to specify
> both sharing domains.
> 
> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 10:02:33 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 10: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.xensource.com>)
	id 1RYxHN-0005p2-CX; Fri, 09 Dec 2011 10:02:09 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RYxHL-0005oO-1K
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 10:02:07 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1323424877!6563731!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI2MQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31943 invoked from network); 9 Dec 2011 10:01:18 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 10:01:18 -0000
X-IronPort-AV: E=Sophos;i="4.71,325,1320624000"; 
   d="scan'208";a="9379101"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 10:01:17 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 10:01:17 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RYxGX-0008ED-9B; Fri, 09 Dec 2011 10:01:17 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RYxGX-0003o0-8G;
	Fri, 09 Dec 2011 10:01:17 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20193.56429.242433.459883@mariner.uk.xensource.com>
Date: Fri, 9 Dec 2011 10:01:17 +0000
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
In-Reply-To: <b398fc97ab19818b7a22.1323330440@xdev.gridcentric.ca>
References: <patchbomb.1323330435@xdev.gridcentric.ca>
	<b398fc97ab19818b7a22.1323330440@xdev.gridcentric.ca>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"andres@gridcentric.ca" <andres@gridcentric.ca>, "Tim
	\(Xen.org\)" <tim@xen.org>, "keir.xen@gmail.com" <keir.xen@gmail.com>,
	"JBeulich@suse.com" <JBeulich@suse.com>,
	"adin@gridcentric.ca" <adin@gridcentric.ca>
Subject: Re: [Xen-devel] [PATCH 05 of 18] Tools: Do not assume sharing
 target is dom0 in libxc wrappers
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Andres Lagar-Cavilla writes ("[PATCH 05 of 18] Tools: Do not assume sharing target is dom0 in libxc wrappers"):
> The libxc wrapper that shares two pages always assumed one
> of the pages was mapped by dom0. Expand the API to specify
> both sharing domains.
> 
> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 10:03:55 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 10:03:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYxIl-0005yC-Sp; Fri, 09 Dec 2011 10:03:35 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RYxIl-0005xn-1m
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 10:03:35 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1323424965!6795293!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI2MQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4372 invoked from network); 9 Dec 2011 10:02:46 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 10:02:46 -0000
X-IronPort-AV: E=Sophos;i="4.71,325,1320624000"; 
   d="scan'208";a="9379138"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 10:02:45 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 10:02:45 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RYxHx-0008Eq-HI; Fri, 09 Dec 2011 10:02:45 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RYxHx-0003o8-GC;
	Fri, 09 Dec 2011 10:02:45 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20193.56517.489854.53690@mariner.uk.xensource.com>
Date: Fri, 9 Dec 2011 10:02:45 +0000
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
In-Reply-To: <cde3529132c144e9788f.1323330446@xdev.gridcentric.ca>
References: <patchbomb.1323330435@xdev.gridcentric.ca>
	<cde3529132c144e9788f.1323330446@xdev.gridcentric.ca>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"andres@gridcentric.ca" <andres@gridcentric.ca>, "Tim
	\(Xen.org\)" <tim@xen.org>, "keir.xen@gmail.com" <keir.xen@gmail.com>,
	"JBeulich@suse.com" <JBeulich@suse.com>,
	"adin@gridcentric.ca" <adin@gridcentric.ca>
Subject: Re: [Xen-devel] [PATCH 11 of 18] Tools: Allow libxl/xl to expose
 the total number of shared frames and space saved
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Andres Lagar-Cavilla writes ("[PATCH 11 of 18] Tools: Allow libxl/xl to expose the total number of shared frames and space saved"):
> diff -r 6f489a294a76 -r cde3529132c1 tools/libxl/xl_cmdimpl.c
> --- a/tools/libxl/xl_cmdimpl.c
> +++ b/tools/libxl/xl_cmdimpl.c
> @@ -38,6 +38,7 @@
>  
>  #include "libxl.h"
>  #include "libxl_utils.h"
> +#include "libxl_internal.h"

No, this is not correct.  xl should not include libxl_internal.h.  Nor
should it make libxc calls directly.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 10:03:55 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 10:03:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYxIl-0005yC-Sp; Fri, 09 Dec 2011 10:03:35 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RYxIl-0005xn-1m
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 10:03:35 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1323424965!6795293!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI2MQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4372 invoked from network); 9 Dec 2011 10:02:46 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 10:02:46 -0000
X-IronPort-AV: E=Sophos;i="4.71,325,1320624000"; 
   d="scan'208";a="9379138"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 10:02:45 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 10:02:45 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RYxHx-0008Eq-HI; Fri, 09 Dec 2011 10:02:45 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RYxHx-0003o8-GC;
	Fri, 09 Dec 2011 10:02:45 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20193.56517.489854.53690@mariner.uk.xensource.com>
Date: Fri, 9 Dec 2011 10:02:45 +0000
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
In-Reply-To: <cde3529132c144e9788f.1323330446@xdev.gridcentric.ca>
References: <patchbomb.1323330435@xdev.gridcentric.ca>
	<cde3529132c144e9788f.1323330446@xdev.gridcentric.ca>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"andres@gridcentric.ca" <andres@gridcentric.ca>, "Tim
	\(Xen.org\)" <tim@xen.org>, "keir.xen@gmail.com" <keir.xen@gmail.com>,
	"JBeulich@suse.com" <JBeulich@suse.com>,
	"adin@gridcentric.ca" <adin@gridcentric.ca>
Subject: Re: [Xen-devel] [PATCH 11 of 18] Tools: Allow libxl/xl to expose
 the total number of shared frames and space saved
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Andres Lagar-Cavilla writes ("[PATCH 11 of 18] Tools: Allow libxl/xl to expose the total number of shared frames and space saved"):
> diff -r 6f489a294a76 -r cde3529132c1 tools/libxl/xl_cmdimpl.c
> --- a/tools/libxl/xl_cmdimpl.c
> +++ b/tools/libxl/xl_cmdimpl.c
> @@ -38,6 +38,7 @@
>  
>  #include "libxl.h"
>  #include "libxl_utils.h"
> +#include "libxl_internal.h"

No, this is not correct.  xl should not include libxl_internal.h.  Nor
should it make libxc calls directly.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 10:09:47 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 10:09:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYxOU-0006N7-NL; Fri, 09 Dec 2011 10:09:30 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RYxOT-0006Mv-3h
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 10:09:29 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1323425319!6539087!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI2MQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22363 invoked from network); 9 Dec 2011 10:08:39 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 10:08:39 -0000
X-IronPort-AV: E=Sophos;i="4.71,325,1320624000"; 
   d="scan'208";a="9379284"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 10:08:38 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 10:08:37 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RYxNd-0008Gt-NM; Fri, 09 Dec 2011 10:08:37 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RYxNd-0003oI-MM;
	Fri, 09 Dec 2011 10:08:37 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20193.56869.681835.810233@mariner.uk.xensource.com>
Date: Fri, 9 Dec 2011 10:08:37 +0000
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
In-Reply-To: <24d514cd4dee7d0d0cc9.1323330443@xdev.gridcentric.ca>
References: <patchbomb.1323330435@xdev.gridcentric.ca>
	<24d514cd4dee7d0d0cc9.1323330443@xdev.gridcentric.ca>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"andres@gridcentric.ca" <andres@gridcentric.ca>, "Tim
	\(Xen.org\)" <tim@xen.org>, "keir.xen@gmail.com" <keir.xen@gmail.com>,
	"JBeulich@suse.com" <JBeulich@suse.com>,
	"adin@gridcentric.ca" <adin@gridcentric.ca>
Subject: Re: [Xen-devel] [PATCH 08 of 18] Tools: Add a sharing command to xl
 for information about shared pages
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Andres Lagar-Cavilla writes ("[PATCH 08 of 18] Tools: Add a sharing command to xl for information about shared pages"):
> +static void sharing(int totals, const libxl_dominfo *info, int nb_domain)
> +{
> +    int i;
> +
> +    printf("Name                                        ID   Mem Shared\n");
> +
> +    for (i = 0; i < nb_domain; i++) {
> +        char *domname;
> +        unsigned shutdown_reason;
> +        domname = libxl_domid_to_name(ctx, info[i].domid);
> +        shutdown_reason = info[i].shutdown ? info[i].shutdown_reason : 0;
> +        printf("%-40s %5d %5lu  %5lu\n",
> +                domname,
> +                info[i].domid,
> +                (unsigned long) (info[i].current_memkb / 1024),
> +                (unsigned long) (info[i].shared_memkb / 1024));
> +        free(domname);
> +    }
> +
> +    if (totals)
> +    {
> +        /* To be added with a future patch. */
> +    }
> +}

Is this analogous to an "xm sharing" command ?

Perhaps we should try to integrate this information in the output of
"xl list" (although we do have some backward compatibility issues
there).

Maybe we need to invent "xl llist" or "xl list -v" or something.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 10:09:47 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 10:09:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYxOU-0006N7-NL; Fri, 09 Dec 2011 10:09:30 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RYxOT-0006Mv-3h
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 10:09:29 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1323425319!6539087!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI2MQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22363 invoked from network); 9 Dec 2011 10:08:39 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 10:08:39 -0000
X-IronPort-AV: E=Sophos;i="4.71,325,1320624000"; 
   d="scan'208";a="9379284"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 10:08:38 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 10:08:37 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RYxNd-0008Gt-NM; Fri, 09 Dec 2011 10:08:37 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RYxNd-0003oI-MM;
	Fri, 09 Dec 2011 10:08:37 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20193.56869.681835.810233@mariner.uk.xensource.com>
Date: Fri, 9 Dec 2011 10:08:37 +0000
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
In-Reply-To: <24d514cd4dee7d0d0cc9.1323330443@xdev.gridcentric.ca>
References: <patchbomb.1323330435@xdev.gridcentric.ca>
	<24d514cd4dee7d0d0cc9.1323330443@xdev.gridcentric.ca>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"andres@gridcentric.ca" <andres@gridcentric.ca>, "Tim
	\(Xen.org\)" <tim@xen.org>, "keir.xen@gmail.com" <keir.xen@gmail.com>,
	"JBeulich@suse.com" <JBeulich@suse.com>,
	"adin@gridcentric.ca" <adin@gridcentric.ca>
Subject: Re: [Xen-devel] [PATCH 08 of 18] Tools: Add a sharing command to xl
 for information about shared pages
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Andres Lagar-Cavilla writes ("[PATCH 08 of 18] Tools: Add a sharing command to xl for information about shared pages"):
> +static void sharing(int totals, const libxl_dominfo *info, int nb_domain)
> +{
> +    int i;
> +
> +    printf("Name                                        ID   Mem Shared\n");
> +
> +    for (i = 0; i < nb_domain; i++) {
> +        char *domname;
> +        unsigned shutdown_reason;
> +        domname = libxl_domid_to_name(ctx, info[i].domid);
> +        shutdown_reason = info[i].shutdown ? info[i].shutdown_reason : 0;
> +        printf("%-40s %5d %5lu  %5lu\n",
> +                domname,
> +                info[i].domid,
> +                (unsigned long) (info[i].current_memkb / 1024),
> +                (unsigned long) (info[i].shared_memkb / 1024));
> +        free(domname);
> +    }
> +
> +    if (totals)
> +    {
> +        /* To be added with a future patch. */
> +    }
> +}

Is this analogous to an "xm sharing" command ?

Perhaps we should try to integrate this information in the output of
"xl list" (although we do have some backward compatibility issues
there).

Maybe we need to invent "xl llist" or "xl list -v" or something.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 10:11:20 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 10:11:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYxQ1-0006ST-6u; Fri, 09 Dec 2011 10:11:05 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RYxPz-0006S7-Fn
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 10:11:03 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1323425414!6799668!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI2MQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19598 invoked from network); 9 Dec 2011 10:10:14 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 10:10:14 -0000
X-IronPort-AV: E=Sophos;i="4.71,325,1320624000"; 
   d="scan'208";a="9379328"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 10:10:13 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 9 Dec 2011
	10:10:13 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Date: Fri, 9 Dec 2011 10:10:13 +0000
In-Reply-To: <24d514cd4dee7d0d0cc9.1323330443@xdev.gridcentric.ca>
References: <patchbomb.1323330435@xdev.gridcentric.ca>
	<24d514cd4dee7d0d0cc9.1323330443@xdev.gridcentric.ca>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323425413.20077.29.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Tim
	\(Xen.org\)" <tim@xen.org>,
	"andres@gridcentric.ca" <andres@gridcentric.ca>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"keir.xen@gmail.com" <keir.xen@gmail.com>,
	"JBeulich@suse.com" <JBeulich@suse.com>,
	"adin@gridcentric.ca" <adin@gridcentric.ca>
Subject: Re: [Xen-devel] [PATCH 08 of 18] Tools: Add a sharing command to xl
 for information about shared pages
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2011-12-08 at 07:47 +0000, Andres Lagar-Cavilla wrote:
> diff -r 8d2a8094ace5 -r 24d514cd4dee tools/libxl/xl_cmdtable.c
> --- a/tools/libxl/xl_cmdtable.c
> +++ b/tools/libxl/xl_cmdtable.c
> @@ -189,6 +189,12 @@ struct cmd_spec cmd_table[] = {
>        "Get information about Xen host",
>        "-n, --numa         List host NUMA topology information",
>      },
> +    { "sharing",
> +      &main_sharing, 0,
> +      "Get information about page sharing",
> +      "[options] [Domain]", 
> +      "-t, --totals              Include host totals in the output",
> +    },
>      { "sched-credit",
>        &main_sched_credit, 0,
>        "Get/set credit scheduler parameters",

Please also patch docs/man/xl.pod.1 when adding new commands.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 10:11:20 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 10:11:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYxQ1-0006ST-6u; Fri, 09 Dec 2011 10:11:05 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RYxPz-0006S7-Fn
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 10:11:03 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1323425414!6799668!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI2MQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19598 invoked from network); 9 Dec 2011 10:10:14 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 10:10:14 -0000
X-IronPort-AV: E=Sophos;i="4.71,325,1320624000"; 
   d="scan'208";a="9379328"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 10:10:13 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 9 Dec 2011
	10:10:13 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Date: Fri, 9 Dec 2011 10:10:13 +0000
In-Reply-To: <24d514cd4dee7d0d0cc9.1323330443@xdev.gridcentric.ca>
References: <patchbomb.1323330435@xdev.gridcentric.ca>
	<24d514cd4dee7d0d0cc9.1323330443@xdev.gridcentric.ca>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323425413.20077.29.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Tim
	\(Xen.org\)" <tim@xen.org>,
	"andres@gridcentric.ca" <andres@gridcentric.ca>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"keir.xen@gmail.com" <keir.xen@gmail.com>,
	"JBeulich@suse.com" <JBeulich@suse.com>,
	"adin@gridcentric.ca" <adin@gridcentric.ca>
Subject: Re: [Xen-devel] [PATCH 08 of 18] Tools: Add a sharing command to xl
 for information about shared pages
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2011-12-08 at 07:47 +0000, Andres Lagar-Cavilla wrote:
> diff -r 8d2a8094ace5 -r 24d514cd4dee tools/libxl/xl_cmdtable.c
> --- a/tools/libxl/xl_cmdtable.c
> +++ b/tools/libxl/xl_cmdtable.c
> @@ -189,6 +189,12 @@ struct cmd_spec cmd_table[] = {
>        "Get information about Xen host",
>        "-n, --numa         List host NUMA topology information",
>      },
> +    { "sharing",
> +      &main_sharing, 0,
> +      "Get information about page sharing",
> +      "[options] [Domain]", 
> +      "-t, --totals              Include host totals in the output",
> +    },
>      { "sched-credit",
>        &main_sched_credit, 0,
>        "Get/set credit scheduler parameters",

Please also patch docs/man/xl.pod.1 when adding new commands.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 10:28:04 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 10:28:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYxgC-0006jd-RG; Fri, 09 Dec 2011 10:27:48 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RYxgB-0006jY-J9
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 10:27:47 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1323426417!4822023!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI2MQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16893 invoked from network); 9 Dec 2011 10:26:57 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 10:26:57 -0000
X-IronPort-AV: E=Sophos;i="4.71,325,1320624000"; 
   d="scan'208";a="9379748"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 10:26:57 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 10:26:56 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RYxfM-0008Lw-Kb;
	Fri, 09 Dec 2011 10:26:56 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RYxfM-0007OZ-K3;
	Fri, 09 Dec 2011 10:26:56 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10460-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 9 Dec 2011 10:26:56 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10460: regressions - trouble:
	broken/fail/pass
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10460 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10460/

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-i386-rhel6hvm-intel  3 host-install(3)              broken
 test-i386-i386-pv             3 host-install(3)              broken
 test-amd64-amd64-xl-sedf      3 host-install(3)              broken
 test-amd64-amd64-xl-win       7 windows-install           fail REGR. vs. 10201
 test-i386-i386-xl-winxpsp3    3 host-install(3)              broken   in 10446
 test-amd64-i386-xl-multivcpu  3 host-install(3)              broken   in 10446

Tests which are failing intermittently (not blocking):
 test-amd64-i386-win-vcpus1    7 windows-install             fail pass in 10446
 test-i386-i386-xl-win         7 windows-install             fail pass in 10454
 test-amd64-i386-xl-win-vcpus1  7 windows-install   fail in 10446 pass in 10460
 build-amd64                   4 xen-build          fail in 10454 pass in 10460
 build-amd64-oldkern           4 xen-build          fail in 10454 pass in 10460
 build-amd64-pvops             4 kernel-build       fail in 10454 pass in 10460

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-i386-i386-xl-winxpsp3    7 windows-install              fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install          fail never pass
 test-amd64-i386-xl-win7-amd64  7 windows-install              fail  never pass
 test-amd64-i386-xend-winxpsp3  7 windows-install              fail  never pass
 test-amd64-amd64-xl-win7-amd64  7 windows-install              fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check      fail in 10446 never pass
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)     blocked in 10454 n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)  blocked in 10454 n/a
 test-amd64-i386-xl-win7-amd64  1 xen-build-check(1)       blocked in 10454 n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)       blocked in 10454 n/a
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)      blocked in 10454 n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)      blocked in 10454 n/a
 test-amd64-i386-pv            1 xen-build-check(1)        blocked in 10454 n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)        blocked in 10454 n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)        blocked in 10454 n/a
 test-amd64-i386-xl            1 xen-build-check(1)        blocked in 10454 n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)        blocked in 10454 n/a
 test-amd64-i386-pair          1 xen-build-check(1)        blocked in 10454 n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)        blocked in 10454 n/a
 test-amd64-amd64-xl-winxpsp3  1 xen-build-check(1)        blocked in 10454 n/a
 test-amd64-amd64-xl-sedf-pin  1 xen-build-check(1)        blocked in 10454 n/a
 test-amd64-amd64-pv           1 xen-build-check(1)        blocked in 10454 n/a
 test-amd64-amd64-xl           1 xen-build-check(1)        blocked in 10454 n/a
 test-amd64-i386-win           1 xen-build-check(1)        blocked in 10454 n/a
 test-amd64-amd64-pair         1 xen-build-check(1)        blocked in 10454 n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)        blocked in 10454 n/a
 test-amd64-amd64-win          1 xen-build-check(1)        blocked in 10454 n/a
 test-amd64-amd64-xl-win       1 xen-build-check(1)        blocked in 10454 n/a
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)       blocked in 10454 n/a
 test-i386-i386-xl-win        13 guest-stop            fail in 10454 never pass

version targeted for testing:
 xen                  1c58bb664d8d
baseline version:
 xen                  62ff6a318c5d

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scanneel.ca>
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Andres Lagar-Cavilla <andres@lagarcavilla>
  Andrew Cooper <andrew.cooper3@citrix.com>
  Anthony PERARD <anthony.perard@citrix.com>
  Brendan Cully <brendan@cs.ubc.ca>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Haitao Shan <haitao.shan@intel.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@novell.com>
  Jan Beulich <jbeulich@suse.com>
  Jonathan Davies <jonathan.davies@citrix.com>
  juergen.gross@ts.fujitsu.com
  Keir Fraser <keir@xen.org>
  Liu, Jinsong <jinsong.liu@intel.com>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
  Philipp Hahn <hahn@univention.de>
  Shriram Rajagopalan <rshriram@cs.ubc.ca>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang2 <wei.wang2@amd.com>
  Xudong Hao <xudong.hao@intel.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               broken  
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            broken  
 test-amd64-amd64-xl-sedf                                     broken  
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 1522 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 10:28:04 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 10:28:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYxgC-0006jd-RG; Fri, 09 Dec 2011 10:27:48 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RYxgB-0006jY-J9
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 10:27:47 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1323426417!4822023!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI2MQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16893 invoked from network); 9 Dec 2011 10:26:57 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 10:26:57 -0000
X-IronPort-AV: E=Sophos;i="4.71,325,1320624000"; 
   d="scan'208";a="9379748"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 10:26:57 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 10:26:56 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RYxfM-0008Lw-Kb;
	Fri, 09 Dec 2011 10:26:56 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RYxfM-0007OZ-K3;
	Fri, 09 Dec 2011 10:26:56 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10460-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 9 Dec 2011 10:26:56 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10460: regressions - trouble:
	broken/fail/pass
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10460 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10460/

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-i386-rhel6hvm-intel  3 host-install(3)              broken
 test-i386-i386-pv             3 host-install(3)              broken
 test-amd64-amd64-xl-sedf      3 host-install(3)              broken
 test-amd64-amd64-xl-win       7 windows-install           fail REGR. vs. 10201
 test-i386-i386-xl-winxpsp3    3 host-install(3)              broken   in 10446
 test-amd64-i386-xl-multivcpu  3 host-install(3)              broken   in 10446

Tests which are failing intermittently (not blocking):
 test-amd64-i386-win-vcpus1    7 windows-install             fail pass in 10446
 test-i386-i386-xl-win         7 windows-install             fail pass in 10454
 test-amd64-i386-xl-win-vcpus1  7 windows-install   fail in 10446 pass in 10460
 build-amd64                   4 xen-build          fail in 10454 pass in 10460
 build-amd64-oldkern           4 xen-build          fail in 10454 pass in 10460
 build-amd64-pvops             4 kernel-build       fail in 10454 pass in 10460

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-i386-i386-xl-winxpsp3    7 windows-install              fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install          fail never pass
 test-amd64-i386-xl-win7-amd64  7 windows-install              fail  never pass
 test-amd64-i386-xend-winxpsp3  7 windows-install              fail  never pass
 test-amd64-amd64-xl-win7-amd64  7 windows-install              fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check      fail in 10446 never pass
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)     blocked in 10454 n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)  blocked in 10454 n/a
 test-amd64-i386-xl-win7-amd64  1 xen-build-check(1)       blocked in 10454 n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)       blocked in 10454 n/a
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)      blocked in 10454 n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)      blocked in 10454 n/a
 test-amd64-i386-pv            1 xen-build-check(1)        blocked in 10454 n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)        blocked in 10454 n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)        blocked in 10454 n/a
 test-amd64-i386-xl            1 xen-build-check(1)        blocked in 10454 n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)        blocked in 10454 n/a
 test-amd64-i386-pair          1 xen-build-check(1)        blocked in 10454 n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)        blocked in 10454 n/a
 test-amd64-amd64-xl-winxpsp3  1 xen-build-check(1)        blocked in 10454 n/a
 test-amd64-amd64-xl-sedf-pin  1 xen-build-check(1)        blocked in 10454 n/a
 test-amd64-amd64-pv           1 xen-build-check(1)        blocked in 10454 n/a
 test-amd64-amd64-xl           1 xen-build-check(1)        blocked in 10454 n/a
 test-amd64-i386-win           1 xen-build-check(1)        blocked in 10454 n/a
 test-amd64-amd64-pair         1 xen-build-check(1)        blocked in 10454 n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)        blocked in 10454 n/a
 test-amd64-amd64-win          1 xen-build-check(1)        blocked in 10454 n/a
 test-amd64-amd64-xl-win       1 xen-build-check(1)        blocked in 10454 n/a
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)       blocked in 10454 n/a
 test-i386-i386-xl-win        13 guest-stop            fail in 10454 never pass

version targeted for testing:
 xen                  1c58bb664d8d
baseline version:
 xen                  62ff6a318c5d

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scanneel.ca>
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Andres Lagar-Cavilla <andres@lagarcavilla>
  Andrew Cooper <andrew.cooper3@citrix.com>
  Anthony PERARD <anthony.perard@citrix.com>
  Brendan Cully <brendan@cs.ubc.ca>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Haitao Shan <haitao.shan@intel.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@novell.com>
  Jan Beulich <jbeulich@suse.com>
  Jonathan Davies <jonathan.davies@citrix.com>
  juergen.gross@ts.fujitsu.com
  Keir Fraser <keir@xen.org>
  Liu, Jinsong <jinsong.liu@intel.com>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
  Philipp Hahn <hahn@univention.de>
  Shriram Rajagopalan <rshriram@cs.ubc.ca>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang2 <wei.wang2@amd.com>
  Xudong Hao <xudong.hao@intel.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               broken  
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            broken  
 test-amd64-amd64-xl-sedf                                     broken  
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 1522 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 10:28:45 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 10:28:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYxgs-0006mH-Fu; Fri, 09 Dec 2011 10:28:30 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RYxgq-0006lv-NC
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 10:28:28 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1323426438!51501651!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26835 invoked from network); 9 Dec 2011 10:27:19 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-13.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 9 Dec 2011 10:27:19 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 09 Dec 2011 10:27:37 +0000
Message-Id: <4EE1DA1B020000780006663E@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 09 Dec 2011 08:51:23 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: <andres@lagarcavilla.org>
References: <patchbomb.1323330435@xdev.gridcentric.ca>
	<ecf95feef9ac5a7d0b79.1323330447@xdev.gridcentric.ca>
	<20111208223822.GH87836@ocelot.phlegethon.org>
	<cba5ca07476cc5619c84113b26325886.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <cba5ca07476cc5619c84113b26325886.squirrel@webmail.lagarcavilla.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com, ian.campbell@citrix.com,
	andres@gridcentric.ca, Tim Deegan <tim@xen.org>,
	keir.xen@gmail.com, ian.jackson@citrix.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 12 of 18] x86/mm: Make page_lock/unlock() in
 arch/x86/mm.c externally callable
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 09.12.11 at 03:54, "Andres Lagar-Cavilla" <andres@lagarcavilla.org> wrote:
>>  At 02:47 -0500 on 08 Dec (1323312447), Andres Lagar-Cavilla wrote:
>>> This is necessary for a new consumer of page_lock/unlock to follow in
>>> the series.
>>>
>>> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
>>
>> Nak, I'm afraid.
>>
>> These were OK as local functions but if they're going to be made
>> generally visible, they need clear comments describing what this
>> locking protects and what the discipline is for avoiding deadlocks.
> 
> How about something along the lines of
> "page_lock() is used for two purposes: pte serialization, and memory
> sharing. All users of page lock for pte serialization live in mm.c, use it
> to lock a page table page during pte updates, do not take other locks
> within the critical section delimited by page_lock/unlock, and perform no
> nesting. All users of page lock for memory sharing live in
> mm/mem_sharing.c. For memory sharing, nesting may happen when sharing (and
> locking) two pages -- deadlock is avoided by locking pages in increasing
> order. Memory sharing may take the p2m_lock within a page_lock/unlock
> critical section. These two users (pte serialization and memory sharing)
> should never collide, as long as page table pages are properly unshared
> prior to updating."

This would seem to me like very undesirable lock ordering - a very
coarse (per-domain) lock taken inside a very fine grained (per-page)
one.

> Now those are all pretty words, but here are the two things I (think I)
> need to do:
> - Prior to updating pte's, we do get_gfn on the page table page. We should
> be using get_gfn_unshare. Regardless of this patch. It's likely never
> going to trigger an actual unshare, yet better safe than sorry.

Does memory sharing work on pv domains at all?

> - I can wrap uses of page_lock in mm sharing in an "external"
> order-enforcing construct from mm-locks.h. And use that to scream deadlock
> between page_lock and p2m_lock.
> 
> The code that actually uses page_lock()s in the memory sharing code can be
> found in "[PATCH] x86/mm: Eliminate global lock in mem sharing code". It
> already orders locking of individual pages in ascending order.

It should be this patch to make the functions externally visible, not a
separate one (or at the very minimum the two ought to be in the same
series, back to back). Which is not to say that I'm fully convinced this
is a good idea.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 10:28:45 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 10:28:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYxgs-0006mH-Fu; Fri, 09 Dec 2011 10:28:30 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RYxgq-0006lv-NC
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 10:28:28 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1323426438!51501651!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26835 invoked from network); 9 Dec 2011 10:27:19 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-13.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 9 Dec 2011 10:27:19 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 09 Dec 2011 10:27:37 +0000
Message-Id: <4EE1DA1B020000780006663E@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 09 Dec 2011 08:51:23 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: <andres@lagarcavilla.org>
References: <patchbomb.1323330435@xdev.gridcentric.ca>
	<ecf95feef9ac5a7d0b79.1323330447@xdev.gridcentric.ca>
	<20111208223822.GH87836@ocelot.phlegethon.org>
	<cba5ca07476cc5619c84113b26325886.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <cba5ca07476cc5619c84113b26325886.squirrel@webmail.lagarcavilla.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com, ian.campbell@citrix.com,
	andres@gridcentric.ca, Tim Deegan <tim@xen.org>,
	keir.xen@gmail.com, ian.jackson@citrix.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 12 of 18] x86/mm: Make page_lock/unlock() in
 arch/x86/mm.c externally callable
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 09.12.11 at 03:54, "Andres Lagar-Cavilla" <andres@lagarcavilla.org> wrote:
>>  At 02:47 -0500 on 08 Dec (1323312447), Andres Lagar-Cavilla wrote:
>>> This is necessary for a new consumer of page_lock/unlock to follow in
>>> the series.
>>>
>>> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
>>
>> Nak, I'm afraid.
>>
>> These were OK as local functions but if they're going to be made
>> generally visible, they need clear comments describing what this
>> locking protects and what the discipline is for avoiding deadlocks.
> 
> How about something along the lines of
> "page_lock() is used for two purposes: pte serialization, and memory
> sharing. All users of page lock for pte serialization live in mm.c, use it
> to lock a page table page during pte updates, do not take other locks
> within the critical section delimited by page_lock/unlock, and perform no
> nesting. All users of page lock for memory sharing live in
> mm/mem_sharing.c. For memory sharing, nesting may happen when sharing (and
> locking) two pages -- deadlock is avoided by locking pages in increasing
> order. Memory sharing may take the p2m_lock within a page_lock/unlock
> critical section. These two users (pte serialization and memory sharing)
> should never collide, as long as page table pages are properly unshared
> prior to updating."

This would seem to me like very undesirable lock ordering - a very
coarse (per-domain) lock taken inside a very fine grained (per-page)
one.

> Now those are all pretty words, but here are the two things I (think I)
> need to do:
> - Prior to updating pte's, we do get_gfn on the page table page. We should
> be using get_gfn_unshare. Regardless of this patch. It's likely never
> going to trigger an actual unshare, yet better safe than sorry.

Does memory sharing work on pv domains at all?

> - I can wrap uses of page_lock in mm sharing in an "external"
> order-enforcing construct from mm-locks.h. And use that to scream deadlock
> between page_lock and p2m_lock.
> 
> The code that actually uses page_lock()s in the memory sharing code can be
> found in "[PATCH] x86/mm: Eliminate global lock in mem sharing code". It
> already orders locking of individual pages in ascending order.

It should be this patch to make the functions externally visible, not a
separate one (or at the very minimum the two ought to be in the same
series, back to back). Which is not to say that I'm fully convinced this
is a good idea.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 11:29:26 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 11: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.xensource.com>)
	id 1RYydG-0007dQ-17; Fri, 09 Dec 2011 11:28:50 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <annie.li@oracle.com>) id 1RYydE-0007dH-2P
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 11:28:48 +0000
X-Env-Sender: annie.li@oracle.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1323430077!7576495!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQyNDQ0Nw==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9724 invoked from network); 9 Dec 2011 11:27:58 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-3.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 9 Dec 2011 11:27:58 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pB9BRrRq003674
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 9 Dec 2011 11:27:54 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pB9BRpfk003969
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 9 Dec 2011 11:27:52 GMT
Received: from abhmt108.oracle.com (abhmt108.oracle.com [141.146.116.60])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pB9BRj1q002161; Fri, 9 Dec 2011 05:27:45 -0600
Received: from [10.191.7.169] (/10.191.7.169)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 09 Dec 2011 03:27:44 -0800
Message-ID: <4EE1F0A6.1090704@oracle.com>
Date: Fri, 09 Dec 2011 19:27:34 +0800
From: annie li <annie.li@oracle.com>
Organization: Oracle Corporation
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
MIME-Version: 1.0
To: Paul Durrant <Paul.Durrant@citrix.com>
References: <1323336940-5382-1-git-send-email-annie.li@oracle.com>	
	<1323337048-5426-1-git-send-email-annie.li@oracle.com>	
	<291EDFCB1E9E224A99088639C4762022B5988E5528@LONPMAILBOX01.citrite.net>	
	<4EE08B0D.80504@oracle.com>	
	<291EDFCB1E9E224A99088639C4762022B5988E552D@LONPMAILBOX01.citrite.net>	
	<4EE19A4D.9030500@oracle.com> <4EE1BC7E.3060904@oracle.com>
	<1323419827.20077.3.camel@zakaz.uk.xensource.com>
	<291EDFCB1E9E224A99088639C4762022B5988E55CE@LONPMAILBOX01.citrite.net>
In-Reply-To: <291EDFCB1E9E224A99088639C4762022B5988E55CE@LONPMAILBOX01.citrite.net>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090202.4EE1F0BA.00BF,ss=1,re=0.000,fgs=0
Cc: "jeremy@goop.org" <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	"kurt.hackel@oracle.com" <kurt.hackel@oracle.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [Xen-devel] [PATCH V2 1/2] xen/granttable: Support sub-page
	grants
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com



On 2011-12-9 16:48, Paul Durrant wrote:
>> -----Original Message-----
>> From: Ian Campbell
>> Sent: 09 December 2011 08:37
>> To: annie li
>> Cc: Paul Durrant; xen-devel@lists.xensource.com; linux-
>> kernel@vger.kernel.org; konrad.wilk@oracle.com; jeremy@goop.org;
>> kurt.hackel@oracle.com
>> Subject: Re: [PATCH V2 1/2] xen/granttable: Support sub-page grants
>>
>> On Fri, 2011-12-09 at 07:45 +0000, annie li wrote:
>>     
>>> On 2011-12-9 13:19, annie li wrote:
>>>       
>>>> Hi Paul,
>>>>
>>>>         
>>>>>>> #define get_free_entry()    get_free_entries(1)
>>>>>>>               
>>>> Is this necessary? Maybe you defined this to keep consistence
>>>>         
>> with
>>     
>>>> put_free_entry(ref)?
>>>> But other functions such as gnttab_grant_foreign_transfer and
>>>> gnttab_grant_foreign_access all call get_free_entries(1). Maybe
>>>>         
>> it
>>     
>>>> is better to keep initial get_free_entries(1) code?
>>>>         
>>> Another approach is doing those work in a separate patch --
>>>       
>> changing
>>     
>>> get_free_entries to get_free_entry in following 4 functions:
>>>       
>> I think you shouldn't get too bogged down in get_free_entry() vs
>> get_free_entries(1) for the purposes of this patch series.
>>
>>     
>
> Annie,
>
>   Yes, don't worry about get_free_entry(). I only defined it for the sake of symmetry in the code I posted.
>   
OK, will keep get_free_entries(1) unchanged.

Thanks
Annie
>   Paul
>   

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 11:29:26 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 11: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.xensource.com>)
	id 1RYydG-0007dQ-17; Fri, 09 Dec 2011 11:28:50 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <annie.li@oracle.com>) id 1RYydE-0007dH-2P
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 11:28:48 +0000
X-Env-Sender: annie.li@oracle.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1323430077!7576495!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQyNDQ0Nw==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9724 invoked from network); 9 Dec 2011 11:27:58 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-3.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 9 Dec 2011 11:27:58 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pB9BRrRq003674
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 9 Dec 2011 11:27:54 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pB9BRpfk003969
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 9 Dec 2011 11:27:52 GMT
Received: from abhmt108.oracle.com (abhmt108.oracle.com [141.146.116.60])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pB9BRj1q002161; Fri, 9 Dec 2011 05:27:45 -0600
Received: from [10.191.7.169] (/10.191.7.169)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 09 Dec 2011 03:27:44 -0800
Message-ID: <4EE1F0A6.1090704@oracle.com>
Date: Fri, 09 Dec 2011 19:27:34 +0800
From: annie li <annie.li@oracle.com>
Organization: Oracle Corporation
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
MIME-Version: 1.0
To: Paul Durrant <Paul.Durrant@citrix.com>
References: <1323336940-5382-1-git-send-email-annie.li@oracle.com>	
	<1323337048-5426-1-git-send-email-annie.li@oracle.com>	
	<291EDFCB1E9E224A99088639C4762022B5988E5528@LONPMAILBOX01.citrite.net>	
	<4EE08B0D.80504@oracle.com>	
	<291EDFCB1E9E224A99088639C4762022B5988E552D@LONPMAILBOX01.citrite.net>	
	<4EE19A4D.9030500@oracle.com> <4EE1BC7E.3060904@oracle.com>
	<1323419827.20077.3.camel@zakaz.uk.xensource.com>
	<291EDFCB1E9E224A99088639C4762022B5988E55CE@LONPMAILBOX01.citrite.net>
In-Reply-To: <291EDFCB1E9E224A99088639C4762022B5988E55CE@LONPMAILBOX01.citrite.net>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090202.4EE1F0BA.00BF,ss=1,re=0.000,fgs=0
Cc: "jeremy@goop.org" <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	"kurt.hackel@oracle.com" <kurt.hackel@oracle.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [Xen-devel] [PATCH V2 1/2] xen/granttable: Support sub-page
	grants
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com



On 2011-12-9 16:48, Paul Durrant wrote:
>> -----Original Message-----
>> From: Ian Campbell
>> Sent: 09 December 2011 08:37
>> To: annie li
>> Cc: Paul Durrant; xen-devel@lists.xensource.com; linux-
>> kernel@vger.kernel.org; konrad.wilk@oracle.com; jeremy@goop.org;
>> kurt.hackel@oracle.com
>> Subject: Re: [PATCH V2 1/2] xen/granttable: Support sub-page grants
>>
>> On Fri, 2011-12-09 at 07:45 +0000, annie li wrote:
>>     
>>> On 2011-12-9 13:19, annie li wrote:
>>>       
>>>> Hi Paul,
>>>>
>>>>         
>>>>>>> #define get_free_entry()    get_free_entries(1)
>>>>>>>               
>>>> Is this necessary? Maybe you defined this to keep consistence
>>>>         
>> with
>>     
>>>> put_free_entry(ref)?
>>>> But other functions such as gnttab_grant_foreign_transfer and
>>>> gnttab_grant_foreign_access all call get_free_entries(1). Maybe
>>>>         
>> it
>>     
>>>> is better to keep initial get_free_entries(1) code?
>>>>         
>>> Another approach is doing those work in a separate patch --
>>>       
>> changing
>>     
>>> get_free_entries to get_free_entry in following 4 functions:
>>>       
>> I think you shouldn't get too bogged down in get_free_entry() vs
>> get_free_entries(1) for the purposes of this patch series.
>>
>>     
>
> Annie,
>
>   Yes, don't worry about get_free_entry(). I only defined it for the sake of symmetry in the code I posted.
>   
OK, will keep get_free_entries(1) unchanged.

Thanks
Annie
>   Paul
>   

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 11:31:07 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 11:31:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYyez-0007iq-Hj; Fri, 09 Dec 2011 11:30:37 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RYyex-0007iW-9V
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 11:30:35 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1323430140!60079667!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI2MQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1117 invoked from network); 9 Dec 2011 11:29:00 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 11:29:00 -0000
X-IronPort-AV: E=Sophos;i="4.71,325,1320624000"; 
   d="scan'208";a="9381510"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 11:29:50 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 11:29:50 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RYyeE-0000DW-Bx; Fri, 09 Dec 2011 11:29:50 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RYyeE-0003qt-B3;
	Fri, 09 Dec 2011 11:29:50 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20193.61742.329900.870600@mariner.uk.xensource.com>
Date: Fri, 9 Dec 2011 11:29:50 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1323425413.20077.29.camel@zakaz.uk.xensource.com>
References: <patchbomb.1323330435@xdev.gridcentric.ca>
	<24d514cd4dee7d0d0cc9.1323330443@xdev.gridcentric.ca>
	<1323425413.20077.29.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"andres@gridcentric.ca" <andres@gridcentric.ca>, "Tim
	\(Xen.org\)" <tim@xen.org>, "keir.xen@gmail.com" <keir.xen@gmail.com>,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>,
	"JBeulich@suse.com" <JBeulich@suse.com>,
	"adin@gridcentric.ca" <adin@gridcentric.ca>
Subject: Re: [Xen-devel] [PATCH 08 of 18] Tools: Add a sharing command to xl
 for information about shared pages
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("Re: [PATCH 08 of 18] Tools: Add a sharing command to xl for information about shared pages"):
> Please also patch docs/man/xl.pod.1 when adding new commands.

Oh, good point, yes.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 11:31:07 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 11:31:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYyez-0007iq-Hj; Fri, 09 Dec 2011 11:30:37 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RYyex-0007iW-9V
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 11:30:35 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1323430140!60079667!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI2MQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1117 invoked from network); 9 Dec 2011 11:29:00 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 11:29:00 -0000
X-IronPort-AV: E=Sophos;i="4.71,325,1320624000"; 
   d="scan'208";a="9381510"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 11:29:50 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 11:29:50 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RYyeE-0000DW-Bx; Fri, 09 Dec 2011 11:29:50 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RYyeE-0003qt-B3;
	Fri, 09 Dec 2011 11:29:50 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20193.61742.329900.870600@mariner.uk.xensource.com>
Date: Fri, 9 Dec 2011 11:29:50 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1323425413.20077.29.camel@zakaz.uk.xensource.com>
References: <patchbomb.1323330435@xdev.gridcentric.ca>
	<24d514cd4dee7d0d0cc9.1323330443@xdev.gridcentric.ca>
	<1323425413.20077.29.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"andres@gridcentric.ca" <andres@gridcentric.ca>, "Tim
	\(Xen.org\)" <tim@xen.org>, "keir.xen@gmail.com" <keir.xen@gmail.com>,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>,
	"JBeulich@suse.com" <JBeulich@suse.com>,
	"adin@gridcentric.ca" <adin@gridcentric.ca>
Subject: Re: [Xen-devel] [PATCH 08 of 18] Tools: Add a sharing command to xl
 for information about shared pages
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("Re: [PATCH 08 of 18] Tools: Add a sharing command to xl for information about shared pages"):
> Please also patch docs/man/xl.pod.1 when adding new commands.

Oh, good point, yes.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 11:33:32 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 11:33:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYyhL-0007vC-4D; Fri, 09 Dec 2011 11:33:03 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <annie.li@oracle.com>) id 1RYyhJ-0007ug-L3
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 11:33:01 +0000
X-Env-Sender: annie.li@oracle.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1323430330!1994259!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDI3NDYz\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10145 invoked from network); 9 Dec 2011 11:32:12 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-8.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 9 Dec 2011 11:32:12 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pB9BW6Mg015980
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 9 Dec 2011 11:32:07 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pB9BW5aX010591
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 9 Dec 2011 11:32:06 GMT
Received: from abhmt110.oracle.com (abhmt110.oracle.com [141.146.116.62])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pB9BW0v7010341; Fri, 9 Dec 2011 05:32:00 -0600
Received: from annie2.cn.oracle.com.com (/10.182.37.169)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 09 Dec 2011 03:31:59 -0800
From: annie.li@oracle.com
To: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org,
	konrad.wilk@oracle.com, jeremy@goop.org, paul.durrant@citrix.com,
	Ian.Campbell@citrix.com, annie.li@oracle.com
Date: Fri,  9 Dec 2011 19:32:01 +0800
Message-Id: <1323430321-5465-1-git-send-email-annie.li@oracle.com>
X-Mailer: git-send-email 1.7.6.4
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090202.4EE1F1B8.0026,ss=1,re=0.000,fgs=0
Cc: kurt.hackel@oracle.com
Subject: [Xen-devel] [PATCH V3 0/2] xen: patches for supporting sub-page and
	transitive grants
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi

Following two patches introduce and implement interfaces for sub-page and transitive grants, and they are based on linux-next branch of linux/kernel/git/konrad/xen.git(3.2.0-rc2+). Sub-page and transitive grants are new types of grant table V2.

Descriptions for those patches:

Through sub-page grant table interfaces, a domain can grant another domain access to a range of bytes within a page, and Xen will then prevent the grantee domain accessing outside that range.  For obvious reasons, it isn't possible to map these grant references, and domains are expected to use the grant copy hypercall instead.

Through transitive grant interfaces,  a domain can create grant reference which redirects to another grant reference, so that any attempt to access the first grant reference will be redirected to the second one.  This is used to implement receiver-side copy on inter-domain traffic: rather than copying the packet in dom0, dom0 creates a transitive grant referencing the original transmit buffer, and passes that to the receiving domain.

Annie Li (2):
  xen/granttable: Support sub-page grants
  xen/granttable: Support transitive grants

 drivers/xen/grant-table.c |  141 +++++++++++++++++++++++++++++++++++++++++++++
 include/xen/grant_table.h |   25 ++++++++
 2 files changed, 166 insertions(+), 0 deletions(-)

Thanks
Annie
-- 
1.7.6.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 11:33:32 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 11:33:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYyhL-0007vC-4D; Fri, 09 Dec 2011 11:33:03 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <annie.li@oracle.com>) id 1RYyhJ-0007ug-L3
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 11:33:01 +0000
X-Env-Sender: annie.li@oracle.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1323430330!1994259!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDI3NDYz\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10145 invoked from network); 9 Dec 2011 11:32:12 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-8.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 9 Dec 2011 11:32:12 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pB9BW6Mg015980
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 9 Dec 2011 11:32:07 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pB9BW5aX010591
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 9 Dec 2011 11:32:06 GMT
Received: from abhmt110.oracle.com (abhmt110.oracle.com [141.146.116.62])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pB9BW0v7010341; Fri, 9 Dec 2011 05:32:00 -0600
Received: from annie2.cn.oracle.com.com (/10.182.37.169)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 09 Dec 2011 03:31:59 -0800
From: annie.li@oracle.com
To: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org,
	konrad.wilk@oracle.com, jeremy@goop.org, paul.durrant@citrix.com,
	Ian.Campbell@citrix.com, annie.li@oracle.com
Date: Fri,  9 Dec 2011 19:32:01 +0800
Message-Id: <1323430321-5465-1-git-send-email-annie.li@oracle.com>
X-Mailer: git-send-email 1.7.6.4
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090202.4EE1F1B8.0026,ss=1,re=0.000,fgs=0
Cc: kurt.hackel@oracle.com
Subject: [Xen-devel] [PATCH V3 0/2] xen: patches for supporting sub-page and
	transitive grants
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi

Following two patches introduce and implement interfaces for sub-page and transitive grants, and they are based on linux-next branch of linux/kernel/git/konrad/xen.git(3.2.0-rc2+). Sub-page and transitive grants are new types of grant table V2.

Descriptions for those patches:

Through sub-page grant table interfaces, a domain can grant another domain access to a range of bytes within a page, and Xen will then prevent the grantee domain accessing outside that range.  For obvious reasons, it isn't possible to map these grant references, and domains are expected to use the grant copy hypercall instead.

Through transitive grant interfaces,  a domain can create grant reference which redirects to another grant reference, so that any attempt to access the first grant reference will be redirected to the second one.  This is used to implement receiver-side copy on inter-domain traffic: rather than copying the packet in dom0, dom0 creates a transitive grant referencing the original transmit buffer, and passes that to the receiving domain.

Annie Li (2):
  xen/granttable: Support sub-page grants
  xen/granttable: Support transitive grants

 drivers/xen/grant-table.c |  141 +++++++++++++++++++++++++++++++++++++++++++++
 include/xen/grant_table.h |   25 ++++++++
 2 files changed, 166 insertions(+), 0 deletions(-)

Thanks
Annie
-- 
1.7.6.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 11:34:14 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 11:34:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYyi6-0007zQ-Ih; Fri, 09 Dec 2011 11:33:50 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <annie.li@oracle.com>) id 1RYyi5-0007yi-AM
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 11:33:49 +0000
X-Env-Sender: annie.li@oracle.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1323430378!4871061!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQyNDQ0Nw==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26143 invoked from network); 9 Dec 2011 11:32:59 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-8.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 9 Dec 2011 11:32:59 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pB9BWtMw009039
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 9 Dec 2011 11:32:56 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pB9BWsIr001155
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 9 Dec 2011 11:32:55 GMT
Received: from abhmt117.oracle.com (abhmt117.oracle.com [141.146.116.69])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pB9BWnBg010757; Fri, 9 Dec 2011 05:32:49 -0600
Received: from annie2.cn.oracle.com.com (/10.182.37.169)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 09 Dec 2011 03:32:48 -0800
From: annie.li@oracle.com
To: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org,
	konrad.wilk@oracle.com, jeremy@goop.org, paul.durrant@citrix.com,
	Ian.Campbell@citrix.com, annie.li@oracle.com
Date: Fri,  9 Dec 2011 19:32:52 +0800
Message-Id: <1323430372-5503-1-git-send-email-annie.li@oracle.com>
X-Mailer: git-send-email 1.7.6.4
In-Reply-To: <1323430321-5465-1-git-send-email-annie.li@oracle.com>
References: <1323430321-5465-1-git-send-email-annie.li@oracle.com>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090203.4EE1F1E8.00D0,ss=1,re=0.000,fgs=0
Cc: kurt.hackel@oracle.com
Subject: [Xen-devel] [PATCH V3 1/2] xen/granttable: Support sub-page grants
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

    -- They can't be used to map the page (so can only be used in a GNTTABOP_copy
       hypercall).
    -- It's possible to grant access with a finer granularity than whole pages.
    -- Xen guarantees that they can be revoked quickly (a normal map grant can
       only be revoked with the cooperation of the domain which has been granted
       access).

Signed-off-by: Annie Li <annie.li@oracle.com>
---
 drivers/xen/grant-table.c |   71 +++++++++++++++++++++++++++++++++++++++++++++
 include/xen/grant_table.h |   13 ++++++++
 2 files changed, 84 insertions(+), 0 deletions(-)

diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
index bd325fd..0ac16fa 100644
--- a/drivers/xen/grant-table.c
+++ b/drivers/xen/grant-table.c
@@ -120,6 +120,16 @@ struct gnttab_ops {
 	 * by bit operations.
 	 */
 	int (*query_foreign_access)(grant_ref_t);
+	/*
+	 * Grant a domain to access a range of bytes within the page referred by
+	 * an available grant entry. First parameter is grant entry reference
+	 * number, second one is id of grantee domain, third one is frame
+	 * address of subpage grant, forth one is grant type and flag
+	 * information, fifth one is offset of the range of bytes, and last one
+	 * is length of bytes to be accessed.
+	 */
+	void (*update_subpage_entry)(grant_ref_t, domid_t, unsigned long, int,
+				     unsigned, unsigned);
 };
 
 static struct gnttab_ops *gnttab_interface;
@@ -261,6 +271,66 @@ int gnttab_grant_foreign_access(domid_t domid, unsigned long frame,
 }
 EXPORT_SYMBOL_GPL(gnttab_grant_foreign_access);
 
+void gnttab_update_subpage_entry_v2(grant_ref_t ref, domid_t domid,
+				    unsigned long frame, int flags,
+				    unsigned page_off,
+				    unsigned length)
+{
+	gnttab_shared.v2[ref].sub_page.frame = frame;
+	gnttab_shared.v2[ref].sub_page.page_off = page_off;
+	gnttab_shared.v2[ref].sub_page.length = length;
+	gnttab_shared.v2[ref].hdr.domid = domid;
+	wmb();
+	gnttab_shared.v2[ref].hdr.flags =
+				GTF_permit_access | GTF_sub_page | flags;
+}
+
+int gnttab_grant_foreign_access_subpage_ref(grant_ref_t ref, domid_t domid,
+					    unsigned long frame, int flags,
+					    unsigned page_off,
+					    unsigned length)
+{
+	if (flags & (GTF_accept_transfer | GTF_reading |
+		     GTF_writing | GTF_transitive))
+		return -EPERM;
+
+	if (gnttab_interface->update_subpage_entry == NULL)
+		return -ENOSYS;
+
+	gnttab_interface->update_subpage_entry(ref, domid, frame, flags,
+					       page_off, length);
+
+	return 0;
+}
+EXPORT_SYMBOL_GPL(gnttab_grant_foreign_access_subpage_ref);
+
+int gnttab_grant_foreign_access_subpage(domid_t domid, unsigned long frame,
+					int flags, unsigned page_off,
+					unsigned length)
+{
+	int ref, rc;
+
+	ref = get_free_entries(1);
+	if (unlikely(ref < 0))
+		return -ENOSPC;
+
+	rc = gnttab_grant_foreign_access_subpage_ref(ref, domid, frame, flags,
+						     page_off, length);
+	if (rc < 0) {
+		put_free_entry(ref);
+		return rc;
+	}
+
+	return ref;
+}
+EXPORT_SYMBOL_GPL(gnttab_grant_foreign_access_subpage);
+
+bool gnttab_subpage_grants_available(void)
+{
+	return gnttab_interface->update_subpage_entry != NULL;
+}
+EXPORT_SYMBOL_GPL(gnttab_subpage_grants_available);
+
 static int gnttab_query_foreign_access_v1(grant_ref_t ref)
 {
 	return gnttab_shared.v1[ref].flags & (GTF_reading|GTF_writing);
@@ -813,6 +883,7 @@ static struct gnttab_ops gnttab_v2_ops = {
 	.end_foreign_access_ref		= gnttab_end_foreign_access_ref_v2,
 	.end_foreign_transfer_ref	= gnttab_end_foreign_transfer_ref_v2,
 	.query_foreign_access		= gnttab_query_foreign_access_v2,
+	.update_subpage_entry		= gnttab_update_subpage_entry_v2,
 };
 
 static void gnttab_request_version(void)
diff --git a/include/xen/grant_table.h b/include/xen/grant_table.h
index fea4954..2b492b9 100644
--- a/include/xen/grant_table.h
+++ b/include/xen/grant_table.h
@@ -62,6 +62,15 @@ int gnttab_resume(void);
 
 int gnttab_grant_foreign_access(domid_t domid, unsigned long frame,
 				int readonly);
+int gnttab_grant_foreign_access_subpage(domid_t domid, unsigned long frame,
+					int flags, unsigned page_off,
+					unsigned length);
+
+/*
+ * Are sub-page grants available on this version of Xen?  Returns true if they
+ * are, and false if they're not.
+ */
+bool gnttab_subpage_grants_available(void);
 
 /*
  * End access through the given grant reference, iff the grant entry is no
@@ -108,6 +117,10 @@ void gnttab_cancel_free_callback(struct gnttab_free_callback *callback);
 
 void gnttab_grant_foreign_access_ref(grant_ref_t ref, domid_t domid,
 				     unsigned long frame, int readonly);
+int gnttab_grant_foreign_access_subpage_ref(grant_ref_t ref, domid_t domid,
+					    unsigned long frame, int flags,
+					    unsigned page_off,
+					    unsigned length);
 
 void gnttab_grant_foreign_transfer_ref(grant_ref_t, domid_t domid,
 				       unsigned long pfn);
-- 
1.7.6.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 11:34:14 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 11:34:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYyi6-0007zQ-Ih; Fri, 09 Dec 2011 11:33:50 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <annie.li@oracle.com>) id 1RYyi5-0007yi-AM
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 11:33:49 +0000
X-Env-Sender: annie.li@oracle.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1323430378!4871061!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQyNDQ0Nw==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26143 invoked from network); 9 Dec 2011 11:32:59 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-8.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 9 Dec 2011 11:32:59 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pB9BWtMw009039
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 9 Dec 2011 11:32:56 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pB9BWsIr001155
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 9 Dec 2011 11:32:55 GMT
Received: from abhmt117.oracle.com (abhmt117.oracle.com [141.146.116.69])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pB9BWnBg010757; Fri, 9 Dec 2011 05:32:49 -0600
Received: from annie2.cn.oracle.com.com (/10.182.37.169)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 09 Dec 2011 03:32:48 -0800
From: annie.li@oracle.com
To: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org,
	konrad.wilk@oracle.com, jeremy@goop.org, paul.durrant@citrix.com,
	Ian.Campbell@citrix.com, annie.li@oracle.com
Date: Fri,  9 Dec 2011 19:32:52 +0800
Message-Id: <1323430372-5503-1-git-send-email-annie.li@oracle.com>
X-Mailer: git-send-email 1.7.6.4
In-Reply-To: <1323430321-5465-1-git-send-email-annie.li@oracle.com>
References: <1323430321-5465-1-git-send-email-annie.li@oracle.com>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090203.4EE1F1E8.00D0,ss=1,re=0.000,fgs=0
Cc: kurt.hackel@oracle.com
Subject: [Xen-devel] [PATCH V3 1/2] xen/granttable: Support sub-page grants
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

    -- They can't be used to map the page (so can only be used in a GNTTABOP_copy
       hypercall).
    -- It's possible to grant access with a finer granularity than whole pages.
    -- Xen guarantees that they can be revoked quickly (a normal map grant can
       only be revoked with the cooperation of the domain which has been granted
       access).

Signed-off-by: Annie Li <annie.li@oracle.com>
---
 drivers/xen/grant-table.c |   71 +++++++++++++++++++++++++++++++++++++++++++++
 include/xen/grant_table.h |   13 ++++++++
 2 files changed, 84 insertions(+), 0 deletions(-)

diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
index bd325fd..0ac16fa 100644
--- a/drivers/xen/grant-table.c
+++ b/drivers/xen/grant-table.c
@@ -120,6 +120,16 @@ struct gnttab_ops {
 	 * by bit operations.
 	 */
 	int (*query_foreign_access)(grant_ref_t);
+	/*
+	 * Grant a domain to access a range of bytes within the page referred by
+	 * an available grant entry. First parameter is grant entry reference
+	 * number, second one is id of grantee domain, third one is frame
+	 * address of subpage grant, forth one is grant type and flag
+	 * information, fifth one is offset of the range of bytes, and last one
+	 * is length of bytes to be accessed.
+	 */
+	void (*update_subpage_entry)(grant_ref_t, domid_t, unsigned long, int,
+				     unsigned, unsigned);
 };
 
 static struct gnttab_ops *gnttab_interface;
@@ -261,6 +271,66 @@ int gnttab_grant_foreign_access(domid_t domid, unsigned long frame,
 }
 EXPORT_SYMBOL_GPL(gnttab_grant_foreign_access);
 
+void gnttab_update_subpage_entry_v2(grant_ref_t ref, domid_t domid,
+				    unsigned long frame, int flags,
+				    unsigned page_off,
+				    unsigned length)
+{
+	gnttab_shared.v2[ref].sub_page.frame = frame;
+	gnttab_shared.v2[ref].sub_page.page_off = page_off;
+	gnttab_shared.v2[ref].sub_page.length = length;
+	gnttab_shared.v2[ref].hdr.domid = domid;
+	wmb();
+	gnttab_shared.v2[ref].hdr.flags =
+				GTF_permit_access | GTF_sub_page | flags;
+}
+
+int gnttab_grant_foreign_access_subpage_ref(grant_ref_t ref, domid_t domid,
+					    unsigned long frame, int flags,
+					    unsigned page_off,
+					    unsigned length)
+{
+	if (flags & (GTF_accept_transfer | GTF_reading |
+		     GTF_writing | GTF_transitive))
+		return -EPERM;
+
+	if (gnttab_interface->update_subpage_entry == NULL)
+		return -ENOSYS;
+
+	gnttab_interface->update_subpage_entry(ref, domid, frame, flags,
+					       page_off, length);
+
+	return 0;
+}
+EXPORT_SYMBOL_GPL(gnttab_grant_foreign_access_subpage_ref);
+
+int gnttab_grant_foreign_access_subpage(domid_t domid, unsigned long frame,
+					int flags, unsigned page_off,
+					unsigned length)
+{
+	int ref, rc;
+
+	ref = get_free_entries(1);
+	if (unlikely(ref < 0))
+		return -ENOSPC;
+
+	rc = gnttab_grant_foreign_access_subpage_ref(ref, domid, frame, flags,
+						     page_off, length);
+	if (rc < 0) {
+		put_free_entry(ref);
+		return rc;
+	}
+
+	return ref;
+}
+EXPORT_SYMBOL_GPL(gnttab_grant_foreign_access_subpage);
+
+bool gnttab_subpage_grants_available(void)
+{
+	return gnttab_interface->update_subpage_entry != NULL;
+}
+EXPORT_SYMBOL_GPL(gnttab_subpage_grants_available);
+
 static int gnttab_query_foreign_access_v1(grant_ref_t ref)
 {
 	return gnttab_shared.v1[ref].flags & (GTF_reading|GTF_writing);
@@ -813,6 +883,7 @@ static struct gnttab_ops gnttab_v2_ops = {
 	.end_foreign_access_ref		= gnttab_end_foreign_access_ref_v2,
 	.end_foreign_transfer_ref	= gnttab_end_foreign_transfer_ref_v2,
 	.query_foreign_access		= gnttab_query_foreign_access_v2,
+	.update_subpage_entry		= gnttab_update_subpage_entry_v2,
 };
 
 static void gnttab_request_version(void)
diff --git a/include/xen/grant_table.h b/include/xen/grant_table.h
index fea4954..2b492b9 100644
--- a/include/xen/grant_table.h
+++ b/include/xen/grant_table.h
@@ -62,6 +62,15 @@ int gnttab_resume(void);
 
 int gnttab_grant_foreign_access(domid_t domid, unsigned long frame,
 				int readonly);
+int gnttab_grant_foreign_access_subpage(domid_t domid, unsigned long frame,
+					int flags, unsigned page_off,
+					unsigned length);
+
+/*
+ * Are sub-page grants available on this version of Xen?  Returns true if they
+ * are, and false if they're not.
+ */
+bool gnttab_subpage_grants_available(void);
 
 /*
  * End access through the given grant reference, iff the grant entry is no
@@ -108,6 +117,10 @@ void gnttab_cancel_free_callback(struct gnttab_free_callback *callback);
 
 void gnttab_grant_foreign_access_ref(grant_ref_t ref, domid_t domid,
 				     unsigned long frame, int readonly);
+int gnttab_grant_foreign_access_subpage_ref(grant_ref_t ref, domid_t domid,
+					    unsigned long frame, int flags,
+					    unsigned page_off,
+					    unsigned length);
 
 void gnttab_grant_foreign_transfer_ref(grant_ref_t, domid_t domid,
 				       unsigned long pfn);
-- 
1.7.6.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 11:34:43 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 11:34:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYyij-00085U-KK; Fri, 09 Dec 2011 11:34:29 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RYyih-00084l-VQ
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 11:34:28 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1323430381!48335566!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI2MQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1539 invoked from network); 9 Dec 2011 11:33:01 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 11:33:01 -0000
X-IronPort-AV: E=Sophos;i="4.71,325,1320624000"; 
   d="scan'208";a="9381590"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 11:33:43 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 11:33:43 +0000
Date: Fri, 9 Dec 2011 11:34:15 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1323266816.23681.189.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1112091131240.3517@kaball-desktop>
References: <1323108621-22654-1-git-send-email-ian.jackson@eu.citrix.com>
	<1323108621-22654-7-git-send-email-ian.jackson@eu.citrix.com>
	<1323266816.23681.189.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 06/15] libxl: permit declaration after
 statement
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 7 Dec 2011, Ian Campbell wrote:
> On Mon, 2011-12-05 at 18:10 +0000, Ian Jackson wrote:
> > GCC and C99 allow declarations to be mixed with code.  This is a good
> > idea because:
> > 
> >  * It allows variables to be more often initialised as they are
> >    declared, thus reducing the occurrence of uninitialised variable
> >    errors.
> > 
> >  * Certain alloca-like constructs (arrays allocated at runtime on the
> >    stack) can more often be written without a spurious { } block.
> >    Such blocks are confusing to read.
> > 
> >  * It makes it easier to write and use macros which declare and
> >    initialise formulaic variables and do other function setup code,
> >    because there is no need to worry that such macros might be
> >    incompatible with each other or have strict ordering constraints.
> > 
> > Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
> 
> I'm happy with this so far as it goes but I was wondering where the
> original -Wdeclaration-after-statement came from, do we actually mean
> "-std=c99" or something along those lines?
> 
> Anyway I'm still ok with saying:
> Acked-by: Ian Campbell <ian.campbell@citrix.com>

Of course I still think that it is the wrong decision, but unfortunately
it seems that I am outnumbered on this.

Policy changes like this one, do the need the majority or unanimity?
:-)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 11:34:43 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 11:34:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYyij-00085U-KK; Fri, 09 Dec 2011 11:34:29 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RYyih-00084l-VQ
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 11:34:28 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1323430381!48335566!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI2MQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1539 invoked from network); 9 Dec 2011 11:33:01 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 11:33:01 -0000
X-IronPort-AV: E=Sophos;i="4.71,325,1320624000"; 
   d="scan'208";a="9381590"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 11:33:43 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 11:33:43 +0000
Date: Fri, 9 Dec 2011 11:34:15 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1323266816.23681.189.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1112091131240.3517@kaball-desktop>
References: <1323108621-22654-1-git-send-email-ian.jackson@eu.citrix.com>
	<1323108621-22654-7-git-send-email-ian.jackson@eu.citrix.com>
	<1323266816.23681.189.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 06/15] libxl: permit declaration after
 statement
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 7 Dec 2011, Ian Campbell wrote:
> On Mon, 2011-12-05 at 18:10 +0000, Ian Jackson wrote:
> > GCC and C99 allow declarations to be mixed with code.  This is a good
> > idea because:
> > 
> >  * It allows variables to be more often initialised as they are
> >    declared, thus reducing the occurrence of uninitialised variable
> >    errors.
> > 
> >  * Certain alloca-like constructs (arrays allocated at runtime on the
> >    stack) can more often be written without a spurious { } block.
> >    Such blocks are confusing to read.
> > 
> >  * It makes it easier to write and use macros which declare and
> >    initialise formulaic variables and do other function setup code,
> >    because there is no need to worry that such macros might be
> >    incompatible with each other or have strict ordering constraints.
> > 
> > Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
> 
> I'm happy with this so far as it goes but I was wondering where the
> original -Wdeclaration-after-statement came from, do we actually mean
> "-std=c99" or something along those lines?
> 
> Anyway I'm still ok with saying:
> Acked-by: Ian Campbell <ian.campbell@citrix.com>

Of course I still think that it is the wrong decision, but unfortunately
it seems that I am outnumbered on this.

Policy changes like this one, do the need the majority or unanimity?
:-)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 11:34:43 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 11:34:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYyid-00083e-08; Fri, 09 Dec 2011 11:34:23 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <annie.li@oracle.com>) id 1RYyia-00082j-RZ
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 11:34:21 +0000
X-Env-Sender: annie.li@oracle.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1323430410!6811241!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQyNDQ0Nw==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5511 invoked from network); 9 Dec 2011 11:33:31 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-8.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 9 Dec 2011 11:33:31 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pB9BXREF009852
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 9 Dec 2011 11:33:27 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pB9BXPld008096
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 9 Dec 2011 11:33:26 GMT
Received: from abhmt109.oracle.com (abhmt109.oracle.com [141.146.116.61])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pB9BXKMm005818; Fri, 9 Dec 2011 05:33:20 -0600
Received: from annie2.cn.oracle.com.com (/10.182.37.169)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 09 Dec 2011 03:33:20 -0800
From: annie.li@oracle.com
To: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org,
	konrad.wilk@oracle.com, jeremy@goop.org, paul.durrant@citrix.com,
	Ian.Campbell@citrix.com, annie.li@oracle.com
Date: Fri,  9 Dec 2011 19:33:24 +0800
Message-Id: <1323430404-5540-1-git-send-email-annie.li@oracle.com>
X-Mailer: git-send-email 1.7.6.4
In-Reply-To: <1323430321-5465-1-git-send-email-annie.li@oracle.com>
References: <1323430321-5465-1-git-send-email-annie.li@oracle.com>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090207.4EE1F208.0090,ss=1,re=0.000,fgs=0
Cc: kurt.hackel@oracle.com
Subject: [Xen-devel] [PATCH V3 2/2] xen/granttable: Support transitive grants
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

These allow a domain A which has been granted access on a page of domain B's
memory to issue domain C with a copy-grant on the same page.  This is useful
e.g. for forwarding packets between domains.

Signed-off-by: Annie Li <annie.li@oracle.com>
---
 drivers/xen/grant-table.c |   70 +++++++++++++++++++++++++++++++++++++++++++++
 include/xen/grant_table.h |   12 ++++++++
 2 files changed, 82 insertions(+), 0 deletions(-)

diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
index 0ac16fa..7835ffc 100644
--- a/drivers/xen/grant-table.c
+++ b/drivers/xen/grant-table.c
@@ -130,6 +130,18 @@ struct gnttab_ops {
 	 */
 	void (*update_subpage_entry)(grant_ref_t, domid_t, unsigned long, int,
 				     unsigned, unsigned);
+	/*
+	 * Redirect an available grant entry on domain A to another grant
+	 * reference of domain B, then allow domain C to use grant reference
+	 * of domain B transitively. First parameter is an available grant entry
+	 * reference on domain A, second one is id of domain C which accesses
+	 * grant entry transitively, third one is grant type and flag
+	 * information, forth one is id of domain B whose grant entry is finally
+	 * accessed transitively, last one is grant entry transitive reference
+	 * of domain B.
+	 */
+	void (*update_trans_entry)(grant_ref_t, domid_t, int, domid_t,
+				   grant_ref_t);
 };
 
 static struct gnttab_ops *gnttab_interface;
@@ -331,6 +343,63 @@ bool gnttab_subpage_grants_available(void)
 }
 EXPORT_SYMBOL_GPL(gnttab_subpage_grants_available);
 
+void gnttab_update_trans_entry_v2(grant_ref_t ref, domid_t domid,
+				  int flags, domid_t trans_domid,
+				  grant_ref_t trans_gref)
+{
+	gnttab_shared.v2[ref].transitive.trans_domid = trans_domid;
+	gnttab_shared.v2[ref].transitive.gref = trans_gref;
+	gnttab_shared.v2[ref].hdr.domid = domid;
+	wmb();
+	gnttab_shared.v2[ref].hdr.flags =
+				GTF_permit_access | GTF_transitive | flags;
+}
+
+int gnttab_grant_foreign_access_trans_ref(grant_ref_t ref, domid_t domid,
+					  int flags, domid_t trans_domid,
+					  grant_ref_t trans_gref)
+{
+	if (flags & (GTF_accept_transfer | GTF_reading |
+		     GTF_writing | GTF_sub_page))
+		return -EPERM;
+
+	if (gnttab_interface->update_trans_entry == NULL)
+		return -ENOSYS;
+
+	gnttab_interface->update_trans_entry(ref, domid, flags, trans_domid,
+					     trans_gref);
+
+	return 0;
+}
+EXPORT_SYMBOL_GPL(gnttab_grant_foreign_access_trans_ref);
+
+int gnttab_grant_foreign_access_trans(domid_t domid, int flags,
+				      domid_t trans_domid,
+				      grant_ref_t trans_gref)
+{
+	int ref, rc;
+
+	ref = get_free_entries(1);
+	if (unlikely(ref < 0))
+		return -ENOSPC;
+
+	rc = gnttab_grant_foreign_access_trans_ref(ref, domid, flags,
+						   trans_domid, trans_gref);
+	if (rc < 0) {
+		put_free_entry(ref);
+		return rc;
+	}
+
+	return ref;
+}
+EXPORT_SYMBOL_GPL(gnttab_grant_foreign_access_trans);
+
+bool gnttab_trans_grants_available(void)
+{
+	return gnttab_interface->update_trans_entry != NULL;
+}
+EXPORT_SYMBOL_GPL(gnttab_trans_grants_available);
+
 static int gnttab_query_foreign_access_v1(grant_ref_t ref)
 {
 	return gnttab_shared.v1[ref].flags & (GTF_reading|GTF_writing);
@@ -884,6 +953,7 @@ static struct gnttab_ops gnttab_v2_ops = {
 	.end_foreign_transfer_ref	= gnttab_end_foreign_transfer_ref_v2,
 	.query_foreign_access		= gnttab_query_foreign_access_v2,
 	.update_subpage_entry		= gnttab_update_subpage_entry_v2,
+	.update_trans_entry		= gnttab_update_trans_entry_v2,
 };
 
 static void gnttab_request_version(void)
diff --git a/include/xen/grant_table.h b/include/xen/grant_table.h
index 2b492b9..f1e17b7 100644
--- a/include/xen/grant_table.h
+++ b/include/xen/grant_table.h
@@ -65,6 +65,9 @@ int gnttab_grant_foreign_access(domid_t domid, unsigned long frame,
 int gnttab_grant_foreign_access_subpage(domid_t domid, unsigned long frame,
 					int flags, unsigned page_off,
 					unsigned length);
+int gnttab_grant_foreign_access_trans(domid_t domid, int flags,
+				      domid_t trans_domid,
+				      grant_ref_t trans_gref);
 
 /*
  * Are sub-page grants available on this version of Xen?  Returns true if they
@@ -73,6 +76,12 @@ int gnttab_grant_foreign_access_subpage(domid_t domid, unsigned long frame,
 bool gnttab_subpage_grants_available(void);
 
 /*
+ * Are transitive grants available on this version of Xen?  Returns true if they
+ * are, and false if they're not.
+ */
+bool gnttab_trans_grants_available(void);
+
+/*
  * End access through the given grant reference, iff the grant entry is no
  * longer in use.  Return 1 if the grant entry was freed, 0 if it is still in
  * use.
@@ -121,6 +130,9 @@ int gnttab_grant_foreign_access_subpage_ref(grant_ref_t ref, domid_t domid,
 					    unsigned long frame, int flags,
 					    unsigned page_off,
 					    unsigned length);
+int gnttab_grant_foreign_access_trans_ref(grant_ref_t ref, domid_t domid,
+					  int flags, domid_t trans_domid,
+					  grant_ref_t trans_gref);
 
 void gnttab_grant_foreign_transfer_ref(grant_ref_t, domid_t domid,
 				       unsigned long pfn);
-- 
1.7.6.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 11:34:43 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 11:34:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYyid-00083e-08; Fri, 09 Dec 2011 11:34:23 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <annie.li@oracle.com>) id 1RYyia-00082j-RZ
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 11:34:21 +0000
X-Env-Sender: annie.li@oracle.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1323430410!6811241!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQyNDQ0Nw==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5511 invoked from network); 9 Dec 2011 11:33:31 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-8.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 9 Dec 2011 11:33:31 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pB9BXREF009852
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 9 Dec 2011 11:33:27 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pB9BXPld008096
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 9 Dec 2011 11:33:26 GMT
Received: from abhmt109.oracle.com (abhmt109.oracle.com [141.146.116.61])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pB9BXKMm005818; Fri, 9 Dec 2011 05:33:20 -0600
Received: from annie2.cn.oracle.com.com (/10.182.37.169)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 09 Dec 2011 03:33:20 -0800
From: annie.li@oracle.com
To: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org,
	konrad.wilk@oracle.com, jeremy@goop.org, paul.durrant@citrix.com,
	Ian.Campbell@citrix.com, annie.li@oracle.com
Date: Fri,  9 Dec 2011 19:33:24 +0800
Message-Id: <1323430404-5540-1-git-send-email-annie.li@oracle.com>
X-Mailer: git-send-email 1.7.6.4
In-Reply-To: <1323430321-5465-1-git-send-email-annie.li@oracle.com>
References: <1323430321-5465-1-git-send-email-annie.li@oracle.com>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090207.4EE1F208.0090,ss=1,re=0.000,fgs=0
Cc: kurt.hackel@oracle.com
Subject: [Xen-devel] [PATCH V3 2/2] xen/granttable: Support transitive grants
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

These allow a domain A which has been granted access on a page of domain B's
memory to issue domain C with a copy-grant on the same page.  This is useful
e.g. for forwarding packets between domains.

Signed-off-by: Annie Li <annie.li@oracle.com>
---
 drivers/xen/grant-table.c |   70 +++++++++++++++++++++++++++++++++++++++++++++
 include/xen/grant_table.h |   12 ++++++++
 2 files changed, 82 insertions(+), 0 deletions(-)

diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
index 0ac16fa..7835ffc 100644
--- a/drivers/xen/grant-table.c
+++ b/drivers/xen/grant-table.c
@@ -130,6 +130,18 @@ struct gnttab_ops {
 	 */
 	void (*update_subpage_entry)(grant_ref_t, domid_t, unsigned long, int,
 				     unsigned, unsigned);
+	/*
+	 * Redirect an available grant entry on domain A to another grant
+	 * reference of domain B, then allow domain C to use grant reference
+	 * of domain B transitively. First parameter is an available grant entry
+	 * reference on domain A, second one is id of domain C which accesses
+	 * grant entry transitively, third one is grant type and flag
+	 * information, forth one is id of domain B whose grant entry is finally
+	 * accessed transitively, last one is grant entry transitive reference
+	 * of domain B.
+	 */
+	void (*update_trans_entry)(grant_ref_t, domid_t, int, domid_t,
+				   grant_ref_t);
 };
 
 static struct gnttab_ops *gnttab_interface;
@@ -331,6 +343,63 @@ bool gnttab_subpage_grants_available(void)
 }
 EXPORT_SYMBOL_GPL(gnttab_subpage_grants_available);
 
+void gnttab_update_trans_entry_v2(grant_ref_t ref, domid_t domid,
+				  int flags, domid_t trans_domid,
+				  grant_ref_t trans_gref)
+{
+	gnttab_shared.v2[ref].transitive.trans_domid = trans_domid;
+	gnttab_shared.v2[ref].transitive.gref = trans_gref;
+	gnttab_shared.v2[ref].hdr.domid = domid;
+	wmb();
+	gnttab_shared.v2[ref].hdr.flags =
+				GTF_permit_access | GTF_transitive | flags;
+}
+
+int gnttab_grant_foreign_access_trans_ref(grant_ref_t ref, domid_t domid,
+					  int flags, domid_t trans_domid,
+					  grant_ref_t trans_gref)
+{
+	if (flags & (GTF_accept_transfer | GTF_reading |
+		     GTF_writing | GTF_sub_page))
+		return -EPERM;
+
+	if (gnttab_interface->update_trans_entry == NULL)
+		return -ENOSYS;
+
+	gnttab_interface->update_trans_entry(ref, domid, flags, trans_domid,
+					     trans_gref);
+
+	return 0;
+}
+EXPORT_SYMBOL_GPL(gnttab_grant_foreign_access_trans_ref);
+
+int gnttab_grant_foreign_access_trans(domid_t domid, int flags,
+				      domid_t trans_domid,
+				      grant_ref_t trans_gref)
+{
+	int ref, rc;
+
+	ref = get_free_entries(1);
+	if (unlikely(ref < 0))
+		return -ENOSPC;
+
+	rc = gnttab_grant_foreign_access_trans_ref(ref, domid, flags,
+						   trans_domid, trans_gref);
+	if (rc < 0) {
+		put_free_entry(ref);
+		return rc;
+	}
+
+	return ref;
+}
+EXPORT_SYMBOL_GPL(gnttab_grant_foreign_access_trans);
+
+bool gnttab_trans_grants_available(void)
+{
+	return gnttab_interface->update_trans_entry != NULL;
+}
+EXPORT_SYMBOL_GPL(gnttab_trans_grants_available);
+
 static int gnttab_query_foreign_access_v1(grant_ref_t ref)
 {
 	return gnttab_shared.v1[ref].flags & (GTF_reading|GTF_writing);
@@ -884,6 +953,7 @@ static struct gnttab_ops gnttab_v2_ops = {
 	.end_foreign_transfer_ref	= gnttab_end_foreign_transfer_ref_v2,
 	.query_foreign_access		= gnttab_query_foreign_access_v2,
 	.update_subpage_entry		= gnttab_update_subpage_entry_v2,
+	.update_trans_entry		= gnttab_update_trans_entry_v2,
 };
 
 static void gnttab_request_version(void)
diff --git a/include/xen/grant_table.h b/include/xen/grant_table.h
index 2b492b9..f1e17b7 100644
--- a/include/xen/grant_table.h
+++ b/include/xen/grant_table.h
@@ -65,6 +65,9 @@ int gnttab_grant_foreign_access(domid_t domid, unsigned long frame,
 int gnttab_grant_foreign_access_subpage(domid_t domid, unsigned long frame,
 					int flags, unsigned page_off,
 					unsigned length);
+int gnttab_grant_foreign_access_trans(domid_t domid, int flags,
+				      domid_t trans_domid,
+				      grant_ref_t trans_gref);
 
 /*
  * Are sub-page grants available on this version of Xen?  Returns true if they
@@ -73,6 +76,12 @@ int gnttab_grant_foreign_access_subpage(domid_t domid, unsigned long frame,
 bool gnttab_subpage_grants_available(void);
 
 /*
+ * Are transitive grants available on this version of Xen?  Returns true if they
+ * are, and false if they're not.
+ */
+bool gnttab_trans_grants_available(void);
+
+/*
  * End access through the given grant reference, iff the grant entry is no
  * longer in use.  Return 1 if the grant entry was freed, 0 if it is still in
  * use.
@@ -121,6 +130,9 @@ int gnttab_grant_foreign_access_subpage_ref(grant_ref_t ref, domid_t domid,
 					    unsigned long frame, int flags,
 					    unsigned page_off,
 					    unsigned length);
+int gnttab_grant_foreign_access_trans_ref(grant_ref_t ref, domid_t domid,
+					  int flags, domid_t trans_domid,
+					  grant_ref_t trans_gref);
 
 void gnttab_grant_foreign_transfer_ref(grant_ref_t, domid_t domid,
 				       unsigned long pfn);
-- 
1.7.6.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 11:38:18 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 11:38:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYymB-0000B0-B5; Fri, 09 Dec 2011 11:38:03 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <lersek@redhat.com>) id 1RYymA-0000AE-3Z
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 11:38:02 +0000
X-Env-Sender: lersek@redhat.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1323430631!4885296!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDYyODg=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15898 invoked from network); 9 Dec 2011 11:37:12 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-13.tower-174.messagelabs.com with SMTP;
	9 Dec 2011 11:37:12 -0000
Received: from int-mx12.intmail.prod.int.phx2.redhat.com
	(int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id pB9Bb6bm003429
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 9 Dec 2011 06:37:06 -0500
Received: from lacos-laptop.brq.redhat.com (dhcp-1-169.brq.redhat.com
	[10.34.1.169])
	by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id pB9Bb3Kv004802; Fri, 9 Dec 2011 06:37:04 -0500
From: Laszlo Ersek <lersek@redhat.com>
To: ian.campbell@citrix.com, konrad.wilk@oracle.com, jeremy@goop.org,
	xen-devel@lists.xensource.com,
	virtualization@lists.linux-foundation.org, netdev@vger.kernel.org,
	linux-kernel@vger.kernel.org
Date: Fri,  9 Dec 2011 12:38:58 +0100
Message-Id: <1323430738-3798-1-git-send-email-lersek@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.25
Subject: [Xen-devel] [PATCH v3 REPOST] xen-netfront: delay gARP until
	backend switches to Connected
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

After a guest is live migrated, the xen-netfront driver emits a gratuitous
ARP message, so that networking hardware on the target host's subnet can
take notice, and public routing to the guest is re-established. However,
if the packet appears on the backend interface before the backend is added
to the target host's bridge, the packet is lost, and the migrated guest's
peers become unable to talk to the guest.

A sufficient two-parts condition to prevent the above is:

(1) ensure that the backend only moves to Connected xenbus state after its
hotplug scripts completed, ie. the netback interface got added to the
bridge; and

(2) ensure the frontend only queues the gARP when it sees the backend move
to Connected.

These two together provide complete ordering. Sub-condition (1) is
satisfied by pvops commit 43223efd9bfd.

In general, the full condition is sufficient, not necessary, because,
according to [1], live migration has been working for a long time without
satisfying sub-condition (2). However, after 43223efd9bfd was backported
to the RHEL-5 host to ensure (1), (2) still proved necessary in the RHEL-6
guest. This patch intends to provide (2) for upstream.

The Reviewed-by line comes from [2].

[1] http://old-list-archives.xen.org/xen-devel/2011-06/msg01969.html
[2] http://old-list-archives.xen.org/xen-devel/2011-07/msg00484.html

Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ian Campbell <ian.campbell@citrix.com>
---
 drivers/net/xen-netfront.c |    4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
index d29365a..f033656 100644
--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -1646,7 +1646,6 @@ static void netback_changed(struct xenbus_device *dev,
 	case XenbusStateInitialised:
 	case XenbusStateReconfiguring:
 	case XenbusStateReconfigured:
-	case XenbusStateConnected:
 	case XenbusStateUnknown:
 	case XenbusStateClosed:
 		break;
@@ -1657,6 +1656,9 @@ static void netback_changed(struct xenbus_device *dev,
 		if (xennet_connect(netdev) != 0)
 			break;
 		xenbus_switch_state(dev, XenbusStateConnected);
+		break;
+
+	case XenbusStateConnected:
 		netif_notify_peers(netdev);
 		break;
 
-- 
1.7.4.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 11:38:18 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 11:38:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYymB-0000B0-B5; Fri, 09 Dec 2011 11:38:03 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <lersek@redhat.com>) id 1RYymA-0000AE-3Z
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 11:38:02 +0000
X-Env-Sender: lersek@redhat.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1323430631!4885296!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDYyODg=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15898 invoked from network); 9 Dec 2011 11:37:12 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-13.tower-174.messagelabs.com with SMTP;
	9 Dec 2011 11:37:12 -0000
Received: from int-mx12.intmail.prod.int.phx2.redhat.com
	(int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id pB9Bb6bm003429
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 9 Dec 2011 06:37:06 -0500
Received: from lacos-laptop.brq.redhat.com (dhcp-1-169.brq.redhat.com
	[10.34.1.169])
	by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id pB9Bb3Kv004802; Fri, 9 Dec 2011 06:37:04 -0500
From: Laszlo Ersek <lersek@redhat.com>
To: ian.campbell@citrix.com, konrad.wilk@oracle.com, jeremy@goop.org,
	xen-devel@lists.xensource.com,
	virtualization@lists.linux-foundation.org, netdev@vger.kernel.org,
	linux-kernel@vger.kernel.org
Date: Fri,  9 Dec 2011 12:38:58 +0100
Message-Id: <1323430738-3798-1-git-send-email-lersek@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.25
Subject: [Xen-devel] [PATCH v3 REPOST] xen-netfront: delay gARP until
	backend switches to Connected
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

After a guest is live migrated, the xen-netfront driver emits a gratuitous
ARP message, so that networking hardware on the target host's subnet can
take notice, and public routing to the guest is re-established. However,
if the packet appears on the backend interface before the backend is added
to the target host's bridge, the packet is lost, and the migrated guest's
peers become unable to talk to the guest.

A sufficient two-parts condition to prevent the above is:

(1) ensure that the backend only moves to Connected xenbus state after its
hotplug scripts completed, ie. the netback interface got added to the
bridge; and

(2) ensure the frontend only queues the gARP when it sees the backend move
to Connected.

These two together provide complete ordering. Sub-condition (1) is
satisfied by pvops commit 43223efd9bfd.

In general, the full condition is sufficient, not necessary, because,
according to [1], live migration has been working for a long time without
satisfying sub-condition (2). However, after 43223efd9bfd was backported
to the RHEL-5 host to ensure (1), (2) still proved necessary in the RHEL-6
guest. This patch intends to provide (2) for upstream.

The Reviewed-by line comes from [2].

[1] http://old-list-archives.xen.org/xen-devel/2011-06/msg01969.html
[2] http://old-list-archives.xen.org/xen-devel/2011-07/msg00484.html

Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ian Campbell <ian.campbell@citrix.com>
---
 drivers/net/xen-netfront.c |    4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
index d29365a..f033656 100644
--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -1646,7 +1646,6 @@ static void netback_changed(struct xenbus_device *dev,
 	case XenbusStateInitialised:
 	case XenbusStateReconfiguring:
 	case XenbusStateReconfigured:
-	case XenbusStateConnected:
 	case XenbusStateUnknown:
 	case XenbusStateClosed:
 		break;
@@ -1657,6 +1656,9 @@ static void netback_changed(struct xenbus_device *dev,
 		if (xennet_connect(netdev) != 0)
 			break;
 		xenbus_switch_state(dev, XenbusStateConnected);
+		break;
+
+	case XenbusStateConnected:
 		netif_notify_peers(netdev);
 		break;
 
-- 
1.7.4.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 12:02:53 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 12:02:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYz9t-0000rm-FE; Fri, 09 Dec 2011 12:02:33 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RYz9r-0000rF-6X
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 12:02:31 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1323432101!6568636!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI2MQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17390 invoked from network); 9 Dec 2011 12:01:42 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 12:01:42 -0000
X-IronPort-AV: E=Sophos;i="4.71,325,1320624000"; 
   d="scan'208";a="9382221"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 12:01:41 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 12:01:41 +0000
Date: Fri, 9 Dec 2011 12:02:02 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Jan Beulich <JBeulich@suse.com>
In-Reply-To: <4EDF46770200007800065E65@nat28.tlf.novell.com>
Message-ID: <alpine.DEB.2.00.1112091201290.3517@kaball-desktop>
References: <alpine.DEB.2.00.1112061753410.31179@kaball-desktop>
	<1323195609-17277-6-git-send-email-stefano.stabellini@eu.citrix.com>
	<4EDF46770200007800065E65@nat28.tlf.novell.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "Tim Deegan \(3P\)" <Tim.Deegan@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH RFC 06/25] libelf-loader: introduce
 elf_load_image and CONFIG_KERNEL_NO_RELOC
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 7 Dec 2011, Jan Beulich wrote:
> >>> On 06.12.11 at 19:19, <stefano.stabellini@eu.citrix.com> wrote:
> > @@ -265,7 +278,11 @@ void elf_load_binary(struct elf_binary *elf)
> >  
> >  void *elf_get_ptr(struct elf_binary *elf, unsigned long addr)
> >  {
> > +#ifdef CONFIG_KERNEL_NO_RELOC
> > +    return elf->dest + addr;
> 
> This looks more like a workaround than a proper solution. Kernels on x86
> may not support relocation either (classic Xen kernels certainly don't),
> yet this construct isn't needed.

you are right: I forgot to set elf->dest appropriately, I'll remove this
change from this patch.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 12:02:53 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 12:02:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYz9t-0000rm-FE; Fri, 09 Dec 2011 12:02:33 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RYz9r-0000rF-6X
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 12:02:31 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1323432101!6568636!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI2MQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17390 invoked from network); 9 Dec 2011 12:01:42 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 12:01:42 -0000
X-IronPort-AV: E=Sophos;i="4.71,325,1320624000"; 
   d="scan'208";a="9382221"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 12:01:41 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 12:01:41 +0000
Date: Fri, 9 Dec 2011 12:02:02 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Jan Beulich <JBeulich@suse.com>
In-Reply-To: <4EDF46770200007800065E65@nat28.tlf.novell.com>
Message-ID: <alpine.DEB.2.00.1112091201290.3517@kaball-desktop>
References: <alpine.DEB.2.00.1112061753410.31179@kaball-desktop>
	<1323195609-17277-6-git-send-email-stefano.stabellini@eu.citrix.com>
	<4EDF46770200007800065E65@nat28.tlf.novell.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "Tim Deegan \(3P\)" <Tim.Deegan@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH RFC 06/25] libelf-loader: introduce
 elf_load_image and CONFIG_KERNEL_NO_RELOC
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 7 Dec 2011, Jan Beulich wrote:
> >>> On 06.12.11 at 19:19, <stefano.stabellini@eu.citrix.com> wrote:
> > @@ -265,7 +278,11 @@ void elf_load_binary(struct elf_binary *elf)
> >  
> >  void *elf_get_ptr(struct elf_binary *elf, unsigned long addr)
> >  {
> > +#ifdef CONFIG_KERNEL_NO_RELOC
> > +    return elf->dest + addr;
> 
> This looks more like a workaround than a proper solution. Kernels on x86
> may not support relocation either (classic Xen kernels certainly don't),
> yet this construct isn't needed.

you are right: I forgot to set elf->dest appropriately, I'll remove this
change from this patch.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 12:03:55 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 12:03:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYzAy-0000xG-B3; Fri, 09 Dec 2011 12:03:40 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RYzAx-0000wZ-8p
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 12:03:39 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1323432044!47631781!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDQ0MTg=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16357 invoked from network); 9 Dec 2011 12:00:46 -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;
	9 Dec 2011 12:00:46 -0000
X-IronPort-AV: E=Sophos;i="4.71,325,1320642000"; d="scan'208";a="19807446"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 07:02:49 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 07:02:49 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pB9C2jZ6007879;	Fri, 9 Dec 2011 04:02:48 -0800
MIME-Version: 1.0
X-Mercurial-Node: d50241faddf372f2262627b9b2071d2a077e8151
Message-ID: <d50241faddf372f22626.1323432166@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1323432164@cosworth.uk.xensource.com>
References: <patchbomb.1323432164@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 9 Dec 2011 12:02:46 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 2 of 2] mini-os: do not wait for pci backend in
	pcifront_scan
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1323432077 0
# Node ID d50241faddf372f2262627b9b2071d2a077e8151
# Parent  9c1b223e152eaaa3861f9b6132590de0b4f6cb7e
mini-os: do not wait for pci backend in pcifront_scan

This blocks the main thread indefinitely if there is no PCI backend present in
xenstore.

Even in the case where there are passthrough devices configured libxl creates
the stubdom and waits for it to startup _before_ adding the backend. Since the
stub domains main thread is blocked before it can write the "running" state to
xenstore the toolstack eventually times out and kills everything.

There is already a separate pcifront thread which waits for the backend to
appear and calls init_pcifront at the appropriate time should a backend ever
appear.

Unfortunately I don't have any free test boxes with VT-d so I haven't been able
to test the cases where PCI deivces are passed through but I obviously have
tested that I can now start an HVM domain with stub qemu without PCI devices
passed through which I couldn't do before so this is an improvement. This stuff
is a bit like pushing the lump around the carpet :-/

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 9c1b223e152e -r d50241faddf3 extras/mini-os/kernel.c
--- a/extras/mini-os/kernel.c	Fri Dec 09 12:01:16 2011 +0000
+++ b/extras/mini-os/kernel.c	Fri Dec 09 12:01:17 2011 +0000
@@ -448,6 +448,7 @@ static void print_pcidev(unsigned int do
 
 static void pcifront_thread(void *p)
 {
+    pcifront_watches(NULL);
     pci_dev = init_pcifront(NULL);
     if (!pci_dev)
         return;
diff -r 9c1b223e152e -r d50241faddf3 extras/mini-os/pcifront.c
--- a/extras/mini-os/pcifront.c	Fri Dec 09 12:01:16 2011 +0000
+++ b/extras/mini-os/pcifront.c	Fri Dec 09 12:01:17 2011 +0000
@@ -280,23 +280,14 @@ void pcifront_scan(struct pcifront_dev *
 {
     char *path;
     int i, n, len;
-    char *s, *msg = NULL, *err = NULL;
+    char *s, *msg = NULL;
     unsigned int domain, bus, slot, fun;
 
     if (!dev)
         dev = pcidev;
     if (!dev) {
-        xenbus_event_queue events = NULL;
-        char *fe_state = "device/pci/0/state";
-        xenbus_watch_path_token(XBT_NIL, fe_state, fe_state, &events);
-        while ((err = xenbus_read(XBT_NIL, fe_state, &msg)) != NULL || msg[0] != '4') {
-            free(msg);
-            free(err);
-            printk("pcifront_scan: waiting for pcifront to become ready\n");
-            xenbus_wait_for_watch(&events);
-        }
-        xenbus_unwatch_path_token(XBT_NIL, fe_state, fe_state);
-        dev = pcidev;
+	printk("pcifront_scan: device or bus\n");
+	return;
     }
 
     len = strlen(dev->backend) + 1 + 5 + 10 + 1;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 12:03:55 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 12:03:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYzAy-0000xG-B3; Fri, 09 Dec 2011 12:03:40 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RYzAx-0000wZ-8p
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 12:03:39 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1323432044!47631781!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDQ0MTg=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16357 invoked from network); 9 Dec 2011 12:00:46 -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;
	9 Dec 2011 12:00:46 -0000
X-IronPort-AV: E=Sophos;i="4.71,325,1320642000"; d="scan'208";a="19807446"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 07:02:49 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 07:02:49 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pB9C2jZ6007879;	Fri, 9 Dec 2011 04:02:48 -0800
MIME-Version: 1.0
X-Mercurial-Node: d50241faddf372f2262627b9b2071d2a077e8151
Message-ID: <d50241faddf372f22626.1323432166@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1323432164@cosworth.uk.xensource.com>
References: <patchbomb.1323432164@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 9 Dec 2011 12:02:46 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 2 of 2] mini-os: do not wait for pci backend in
	pcifront_scan
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1323432077 0
# Node ID d50241faddf372f2262627b9b2071d2a077e8151
# Parent  9c1b223e152eaaa3861f9b6132590de0b4f6cb7e
mini-os: do not wait for pci backend in pcifront_scan

This blocks the main thread indefinitely if there is no PCI backend present in
xenstore.

Even in the case where there are passthrough devices configured libxl creates
the stubdom and waits for it to startup _before_ adding the backend. Since the
stub domains main thread is blocked before it can write the "running" state to
xenstore the toolstack eventually times out and kills everything.

There is already a separate pcifront thread which waits for the backend to
appear and calls init_pcifront at the appropriate time should a backend ever
appear.

Unfortunately I don't have any free test boxes with VT-d so I haven't been able
to test the cases where PCI deivces are passed through but I obviously have
tested that I can now start an HVM domain with stub qemu without PCI devices
passed through which I couldn't do before so this is an improvement. This stuff
is a bit like pushing the lump around the carpet :-/

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 9c1b223e152e -r d50241faddf3 extras/mini-os/kernel.c
--- a/extras/mini-os/kernel.c	Fri Dec 09 12:01:16 2011 +0000
+++ b/extras/mini-os/kernel.c	Fri Dec 09 12:01:17 2011 +0000
@@ -448,6 +448,7 @@ static void print_pcidev(unsigned int do
 
 static void pcifront_thread(void *p)
 {
+    pcifront_watches(NULL);
     pci_dev = init_pcifront(NULL);
     if (!pci_dev)
         return;
diff -r 9c1b223e152e -r d50241faddf3 extras/mini-os/pcifront.c
--- a/extras/mini-os/pcifront.c	Fri Dec 09 12:01:16 2011 +0000
+++ b/extras/mini-os/pcifront.c	Fri Dec 09 12:01:17 2011 +0000
@@ -280,23 +280,14 @@ void pcifront_scan(struct pcifront_dev *
 {
     char *path;
     int i, n, len;
-    char *s, *msg = NULL, *err = NULL;
+    char *s, *msg = NULL;
     unsigned int domain, bus, slot, fun;
 
     if (!dev)
         dev = pcidev;
     if (!dev) {
-        xenbus_event_queue events = NULL;
-        char *fe_state = "device/pci/0/state";
-        xenbus_watch_path_token(XBT_NIL, fe_state, fe_state, &events);
-        while ((err = xenbus_read(XBT_NIL, fe_state, &msg)) != NULL || msg[0] != '4') {
-            free(msg);
-            free(err);
-            printk("pcifront_scan: waiting for pcifront to become ready\n");
-            xenbus_wait_for_watch(&events);
-        }
-        xenbus_unwatch_path_token(XBT_NIL, fe_state, fe_state);
-        dev = pcidev;
+	printk("pcifront_scan: device or bus\n");
+	return;
     }
 
     len = strlen(dev->backend) + 1 + 5 + 10 + 1;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 12:03:56 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 12:03:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYzAz-0000xT-OZ; Fri, 09 Dec 2011 12:03:41 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RYzAx-0000wc-Rb
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 12:03:40 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1323432169!1999563!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMTkxNzY=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9204 invoked from network); 9 Dec 2011 12:02:50 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 12:02:50 -0000
X-IronPort-AV: E=Sophos;i="4.71,325,1320642000"; d="scan'208";a="173539389"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 07:02:48 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 07:02:48 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pB9C2jZ5007879;	Fri, 9 Dec 2011 04:02:47 -0800
MIME-Version: 1.0
X-Mercurial-Node: 9c1b223e152eaaa3861f9b6132590de0b4f6cb7e
Message-ID: <9c1b223e152eaaa3861f.1323432165@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1323432164@cosworth.uk.xensource.com>
References: <patchbomb.1323432164@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 9 Dec 2011 12:02:45 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 1 of 2] libxl: fix cold plugged PCI devices with
	stubdomains
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1323432076 0
# Node ID 9c1b223e152eaaa3861f9b6132590de0b4f6cb7e
# Parent  d8c390192ad1147d7202cf04be090478f1810a5d
libxl: fix cold plugged PCI devices with stubdomains

Since 23565:72eafe80ebc1 the xenstore entries for the stubdomain's PCI were
never created and therefore the stubdom ends up waiting forever for the devices
which it has been asked to insert to show up.

Since the stubdomain is already running when we call the libxl_device_pci_add
loop in do_domain_create we should treat it as if "starting == 0".

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r d8c390192ad1 -r 9c1b223e152e tools/libxl/libxl_pci.c
--- a/tools/libxl/libxl_pci.c	Thu Dec 08 17:43:29 2011 +0000
+++ b/tools/libxl/libxl_pci.c	Fri Dec 09 12:01:16 2011 +0000
@@ -819,7 +819,8 @@ int libxl__device_pci_add(libxl__gc *gc,
     stubdomid = libxl_get_stubdom_id(ctx, domid);
     if (stubdomid != 0) {
         libxl_device_pci pcidev_s = *pcidev;
-        rc = do_pci_add(gc, stubdomid, &pcidev_s, starting);
+        /* stubdomain is always running by now, even at create time */
+        rc = do_pci_add(gc, stubdomid, &pcidev_s, 0);
         if ( rc )
             goto out;
     }

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 12:03:56 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 12:03:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYzAw-0000wx-Un; Fri, 09 Dec 2011 12:03:38 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RYzAw-0000wR-87
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 12:03:38 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1323432044!47631781!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDQ0MTg=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16327 invoked from network); 9 Dec 2011 12:00:45 -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;
	9 Dec 2011 12:00:45 -0000
X-IronPort-AV: E=Sophos;i="4.71,325,1320642000"; d="scan'208";a="19807445"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 07:02:47 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 07:02:47 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pB9C2jZ4007879;	Fri, 9 Dec 2011 04:02:46 -0800
MIME-Version: 1.0
Message-ID: <patchbomb.1323432164@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 9 Dec 2011 12:02:44 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 0 of 2] Qemu stubdom PCI fixlets
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 12:03:56 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 12:03:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYzAz-0000xT-OZ; Fri, 09 Dec 2011 12:03:41 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RYzAx-0000wc-Rb
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 12:03:40 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1323432169!1999563!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMTkxNzY=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9204 invoked from network); 9 Dec 2011 12:02:50 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 12:02:50 -0000
X-IronPort-AV: E=Sophos;i="4.71,325,1320642000"; d="scan'208";a="173539389"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 07:02:48 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 07:02:48 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pB9C2jZ5007879;	Fri, 9 Dec 2011 04:02:47 -0800
MIME-Version: 1.0
X-Mercurial-Node: 9c1b223e152eaaa3861f9b6132590de0b4f6cb7e
Message-ID: <9c1b223e152eaaa3861f.1323432165@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1323432164@cosworth.uk.xensource.com>
References: <patchbomb.1323432164@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 9 Dec 2011 12:02:45 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 1 of 2] libxl: fix cold plugged PCI devices with
	stubdomains
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1323432076 0
# Node ID 9c1b223e152eaaa3861f9b6132590de0b4f6cb7e
# Parent  d8c390192ad1147d7202cf04be090478f1810a5d
libxl: fix cold plugged PCI devices with stubdomains

Since 23565:72eafe80ebc1 the xenstore entries for the stubdomain's PCI were
never created and therefore the stubdom ends up waiting forever for the devices
which it has been asked to insert to show up.

Since the stubdomain is already running when we call the libxl_device_pci_add
loop in do_domain_create we should treat it as if "starting == 0".

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r d8c390192ad1 -r 9c1b223e152e tools/libxl/libxl_pci.c
--- a/tools/libxl/libxl_pci.c	Thu Dec 08 17:43:29 2011 +0000
+++ b/tools/libxl/libxl_pci.c	Fri Dec 09 12:01:16 2011 +0000
@@ -819,7 +819,8 @@ int libxl__device_pci_add(libxl__gc *gc,
     stubdomid = libxl_get_stubdom_id(ctx, domid);
     if (stubdomid != 0) {
         libxl_device_pci pcidev_s = *pcidev;
-        rc = do_pci_add(gc, stubdomid, &pcidev_s, starting);
+        /* stubdomain is always running by now, even at create time */
+        rc = do_pci_add(gc, stubdomid, &pcidev_s, 0);
         if ( rc )
             goto out;
     }

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 12:03:56 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 12:03:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYzAw-0000wx-Un; Fri, 09 Dec 2011 12:03:38 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RYzAw-0000wR-87
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 12:03:38 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1323432044!47631781!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDQ0MTg=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16327 invoked from network); 9 Dec 2011 12:00:45 -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;
	9 Dec 2011 12:00:45 -0000
X-IronPort-AV: E=Sophos;i="4.71,325,1320642000"; d="scan'208";a="19807445"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 07:02:47 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 07:02:47 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pB9C2jZ4007879;	Fri, 9 Dec 2011 04:02:46 -0800
MIME-Version: 1.0
Message-ID: <patchbomb.1323432164@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 9 Dec 2011 12:02:44 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 0 of 2] Qemu stubdom PCI fixlets
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 12:06:36 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 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.xensource.com>)
	id 1RYzDX-0001Mc-Gb; Fri, 09 Dec 2011 12:06:19 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RYzDW-0001Ln-3h
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 12:06:18 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1323432328!6700393!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI2MQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20507 invoked from network); 9 Dec 2011 12:05:28 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 12:05:28 -0000
X-IronPort-AV: E=Sophos;i="4.71,325,1320624000"; 
   d="scan'208";a="9382326"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 12:05:28 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 12:05:28 +0000
Date: Fri, 9 Dec 2011 12:05:50 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Jan Beulich <JBeulich@suse.com>
In-Reply-To: <4EDF70CD0200007800065F91@nat28.tlf.novell.com>
Message-ID: <alpine.DEB.2.00.1112091205100.3517@kaball-desktop>
References: <alpine.DEB.2.00.1112061753410.31179@kaball-desktop>
	<1323195609-17277-7-git-send-email-stefano.stabellini@eu.citrix.com>
	<4EDF47360200007800065E7C@nat28.tlf.novell.com>
	<alpine.DEB.2.00.1112071123360.31179@kaball-desktop>
	<4EDF70CD0200007800065F91@nat28.tlf.novell.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "Tim Deegan \(3P\)" <Tim.Deegan@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH RFC 07/25] xen/common/Makefile: introduce
 HAS_CPUFREQ, HAS_PCI, HAS_PASSTHROUGH, HAS_NS16550
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 7 Dec 2011, Jan Beulich wrote:
> >>> On 07.12.11 at 12:24, Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> wrote:
> > On Wed, 7 Dec 2011, Jan Beulich wrote:
> >> >>> On 06.12.11 at 19:19, <stefano.stabellini@eu.citrix.com> wrote:
> >> > From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> >> > 
> >> > - make the compilation of ns16550.c depend upon HAS_NS16550;
> >> > 
> >> > - make the compilation of cpufreq depend upon HAS_CPUFREQ;
> >> > 
> >> > - make the compilation of pci depend upon HAS_PCI;
> >> > 
> >> > - make the compilation of passthrough depend upon HAS_PASSTHROUGH;
> >> > 
> >> > - make the compilation of kexec.o depend on HAS_ACPI.
> >> 
> >> How are kexec and ACPI connected to one another?
> > 
> > Today kexec implementation is dependent on ACPI.
> 
> The only dependency I can spot is the call to acpi_dmar_reinstate(),
> which could clearly get an inline stub on platforms that don't have
> ACPI (or pass-through).

It is better than I thought. I am compiling kexec too now.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 12:06:36 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 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.xensource.com>)
	id 1RYzDX-0001Mc-Gb; Fri, 09 Dec 2011 12:06:19 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RYzDW-0001Ln-3h
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 12:06:18 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1323432328!6700393!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI2MQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20507 invoked from network); 9 Dec 2011 12:05:28 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 12:05:28 -0000
X-IronPort-AV: E=Sophos;i="4.71,325,1320624000"; 
   d="scan'208";a="9382326"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 12:05:28 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 12:05:28 +0000
Date: Fri, 9 Dec 2011 12:05:50 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Jan Beulich <JBeulich@suse.com>
In-Reply-To: <4EDF70CD0200007800065F91@nat28.tlf.novell.com>
Message-ID: <alpine.DEB.2.00.1112091205100.3517@kaball-desktop>
References: <alpine.DEB.2.00.1112061753410.31179@kaball-desktop>
	<1323195609-17277-7-git-send-email-stefano.stabellini@eu.citrix.com>
	<4EDF47360200007800065E7C@nat28.tlf.novell.com>
	<alpine.DEB.2.00.1112071123360.31179@kaball-desktop>
	<4EDF70CD0200007800065F91@nat28.tlf.novell.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "Tim Deegan \(3P\)" <Tim.Deegan@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH RFC 07/25] xen/common/Makefile: introduce
 HAS_CPUFREQ, HAS_PCI, HAS_PASSTHROUGH, HAS_NS16550
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 7 Dec 2011, Jan Beulich wrote:
> >>> On 07.12.11 at 12:24, Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> wrote:
> > On Wed, 7 Dec 2011, Jan Beulich wrote:
> >> >>> On 06.12.11 at 19:19, <stefano.stabellini@eu.citrix.com> wrote:
> >> > From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> >> > 
> >> > - make the compilation of ns16550.c depend upon HAS_NS16550;
> >> > 
> >> > - make the compilation of cpufreq depend upon HAS_CPUFREQ;
> >> > 
> >> > - make the compilation of pci depend upon HAS_PCI;
> >> > 
> >> > - make the compilation of passthrough depend upon HAS_PASSTHROUGH;
> >> > 
> >> > - make the compilation of kexec.o depend on HAS_ACPI.
> >> 
> >> How are kexec and ACPI connected to one another?
> > 
> > Today kexec implementation is dependent on ACPI.
> 
> The only dependency I can spot is the call to acpi_dmar_reinstate(),
> which could clearly get an inline stub on platforms that don't have
> ACPI (or pass-through).

It is better than I thought. I am compiling kexec too now.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 12:39:48 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 12:39:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYzjV-0001s9-Bg; Fri, 09 Dec 2011 12:39:21 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RYzjT-0001s4-Qh
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 12:39:20 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1323434310!6746476!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI2MQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9517 invoked from network); 9 Dec 2011 12:38:30 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 12:38:30 -0000
X-IronPort-AV: E=Sophos;i="4.71,325,1320624000"; 
   d="scan'208";a="9383076"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 12:38:29 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 9 Dec 2011
	12:38:29 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Date: Fri, 9 Dec 2011 12:38:29 +0000
In-Reply-To: <alpine.DEB.2.00.1112091205100.3517@kaball-desktop>
References: <alpine.DEB.2.00.1112061753410.31179@kaball-desktop>
	<1323195609-17277-7-git-send-email-stefano.stabellini@eu.citrix.com>
	<4EDF47360200007800065E7C@nat28.tlf.novell.com>
	<alpine.DEB.2.00.1112071123360.31179@kaball-desktop>
	<4EDF70CD0200007800065F91@nat28.tlf.novell.com>
	<alpine.DEB.2.00.1112091205100.3517@kaball-desktop>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323434309.20077.35.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Tim Deegan \(3P\)" <Tim.Deegan@citrix.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH RFC 07/25] xen/common/Makefile: introduce
 HAS_CPUFREQ, HAS_PCI, HAS_PASSTHROUGH, HAS_NS16550
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2011-12-09 at 12:05 +0000, Stefano Stabellini wrote:
> On Wed, 7 Dec 2011, Jan Beulich wrote:
> > >>> On 07.12.11 at 12:24, Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > wrote:
> > > On Wed, 7 Dec 2011, Jan Beulich wrote:
> > >> >>> On 06.12.11 at 19:19, <stefano.stabellini@eu.citrix.com> wrote:
> > >> > From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > >> > 
> > >> > - make the compilation of ns16550.c depend upon HAS_NS16550;
> > >> > 
> > >> > - make the compilation of cpufreq depend upon HAS_CPUFREQ;
> > >> > 
> > >> > - make the compilation of pci depend upon HAS_PCI;
> > >> > 
> > >> > - make the compilation of passthrough depend upon HAS_PASSTHROUGH;
> > >> > 
> > >> > - make the compilation of kexec.o depend on HAS_ACPI.
> > >> 
> > >> How are kexec and ACPI connected to one another?
> > > 
> > > Today kexec implementation is dependent on ACPI.
> > 
> > The only dependency I can spot is the call to acpi_dmar_reinstate(),
> > which could clearly get an inline stub on platforms that don't have
> > ACPI (or pass-through).
> 
> It is better than I thought. I am compiling kexec too now.

Even if it can be made to compile it can't work unless someone writes
the actual moving parts which is a fair bit of work. I suggest we leave
this to one side for now and define HAS_KEXEC as False.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 12:39:48 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 12:39:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RYzjV-0001s9-Bg; Fri, 09 Dec 2011 12:39:21 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RYzjT-0001s4-Qh
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 12:39:20 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1323434310!6746476!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI2MQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9517 invoked from network); 9 Dec 2011 12:38:30 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 12:38:30 -0000
X-IronPort-AV: E=Sophos;i="4.71,325,1320624000"; 
   d="scan'208";a="9383076"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 12:38:29 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 9 Dec 2011
	12:38:29 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Date: Fri, 9 Dec 2011 12:38:29 +0000
In-Reply-To: <alpine.DEB.2.00.1112091205100.3517@kaball-desktop>
References: <alpine.DEB.2.00.1112061753410.31179@kaball-desktop>
	<1323195609-17277-7-git-send-email-stefano.stabellini@eu.citrix.com>
	<4EDF47360200007800065E7C@nat28.tlf.novell.com>
	<alpine.DEB.2.00.1112071123360.31179@kaball-desktop>
	<4EDF70CD0200007800065F91@nat28.tlf.novell.com>
	<alpine.DEB.2.00.1112091205100.3517@kaball-desktop>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323434309.20077.35.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Tim Deegan \(3P\)" <Tim.Deegan@citrix.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH RFC 07/25] xen/common/Makefile: introduce
 HAS_CPUFREQ, HAS_PCI, HAS_PASSTHROUGH, HAS_NS16550
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2011-12-09 at 12:05 +0000, Stefano Stabellini wrote:
> On Wed, 7 Dec 2011, Jan Beulich wrote:
> > >>> On 07.12.11 at 12:24, Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > wrote:
> > > On Wed, 7 Dec 2011, Jan Beulich wrote:
> > >> >>> On 06.12.11 at 19:19, <stefano.stabellini@eu.citrix.com> wrote:
> > >> > From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > >> > 
> > >> > - make the compilation of ns16550.c depend upon HAS_NS16550;
> > >> > 
> > >> > - make the compilation of cpufreq depend upon HAS_CPUFREQ;
> > >> > 
> > >> > - make the compilation of pci depend upon HAS_PCI;
> > >> > 
> > >> > - make the compilation of passthrough depend upon HAS_PASSTHROUGH;
> > >> > 
> > >> > - make the compilation of kexec.o depend on HAS_ACPI.
> > >> 
> > >> How are kexec and ACPI connected to one another?
> > > 
> > > Today kexec implementation is dependent on ACPI.
> > 
> > The only dependency I can spot is the call to acpi_dmar_reinstate(),
> > which could clearly get an inline stub on platforms that don't have
> > ACPI (or pass-through).
> 
> It is better than I thought. I am compiling kexec too now.

Even if it can be made to compile it can't work unless someone writes
the actual moving parts which is a fair bit of work. I suggest we leave
this to one side for now and define HAS_KEXEC as False.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 13:13:34 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 13:13:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZ0FT-0002Az-8W; Fri, 09 Dec 2011 13:12:23 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RZ0FR-0002Ae-W1
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 13:12:22 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1323436292!4908091!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI2MQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23563 invoked from network); 9 Dec 2011 13:11:32 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 13:11:32 -0000
X-IronPort-AV: E=Sophos;i="4.71,325,1320624000"; 
   d="scan'208";a="9383804"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 13:11:32 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 13:11:32 +0000
Date: Fri, 9 Dec 2011 13:12:05 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Message-ID: <alpine.DEB.2.00.1112091208420.3517@kaball-desktop>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"Tim Deegan \(3P\)" <Tim.Deegan@citrix.com>
Subject: [Xen-devel] [PATCH v2 00/25] xen: ARMv7 with virtualization
	extensions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hello everyone,
this is the second version of the patch series that introduces ARMv7
with virtualization extensions support in Xen.
The series allows Xen and Dom0 to boot on a Cortex-A15 based Versatile
Express simulator.
See the following announce email for more informations about what we
are trying to achieve, as well as the original git history:

See http://marc.info/?l=xen-devel&m=132257857628098&w=2


The first 7 patches affect generic Xen code and are not ARM specific;
often they fix real issues, hidden in the default X86 configuration.

The following 18 patches introduce ARMv7 with virtualization extensions
support: makefiles first, then the asm-arm header files and finally
everything else, ordered in a way that should make the patches easier
to read.


Changes in v2:

- introduce CONFIG_XENOPROF;

- make _srodata and  _erodata const char[];

- do not include p2m.h ifdef __ia64__;

- remove wrong comment about pfn.h;

- introduce HAS_KEXEC and CONFIG_KEXEC;

- use long in __do_clear_user;

- remove the div64 patch, implement __aeabi_ldivmod and __aeabi_uldivmod
instead;

- move "arm: makefiles" at the end of the series.


Stefano Stabellini (25):
      Move cpufreq option parsing to cpufreq.c
      Include some header files that are not automatically included on all archs
      A collection of fixes to Xen common files
      xen: implement an signed 64 bit division helper function
      Introduce clear_user
      libelf-loader: introduce elf_load_image
      xen/common/Makefile: introduce HAS_CPUFREQ, HAS_PCI, HAS_PASSTHROUGH, HAS_NS16550, HAS_KEXEC
      arm: compile tmem
      arm: header files
      arm: bit manipulation, copy and division libraries
      arm: entry.S and head.S
      arm: domain
      arm: domain_build
      arm: driver for CoreLink GIC-400 Generic Interrupt Controller
      arm: mmio handlers
      arm: irq
      arm: mm and p2m
      arm: pl011 UART driver
      arm: early setup code
      arm: shutdown, smp and smpboot
      arm: driver for the generic timer for ARMv7
      arm: trap handlers
      arm: vgic emulation
      arm: vtimer
      arm: makefiles

 config/arm.mk                      |   18 +
 xen/arch/arm/Makefile              |   76 +++++
 xen/arch/arm/Rules.mk              |   29 ++
 xen/arch/arm/asm-offsets.c         |   76 +++++
 xen/arch/arm/domain.c              |  269 ++++++++++++++++
 xen/arch/arm/domain_build.c        |  212 +++++++++++++
 xen/arch/arm/dummy.S               |   72 +++++
 xen/arch/arm/entry.S               |  107 +++++++
 xen/arch/arm/gic.c                 |  473 ++++++++++++++++++++++++++++
 xen/arch/arm/gic.h                 |  154 +++++++++
 xen/arch/arm/head.S                |  298 ++++++++++++++++++
 xen/arch/arm/io.c                  |   51 +++
 xen/arch/arm/io.h                  |   55 ++++
 xen/arch/arm/irq.c                 |  180 +++++++++++
 xen/arch/arm/lib/Makefile          |    5 +
 xen/arch/arm/lib/assembler.h       |   49 +++
 xen/arch/arm/lib/bitops.h          |   36 +++
 xen/arch/arm/lib/changebit.S       |   18 +
 xen/arch/arm/lib/clearbit.S        |   19 ++
 xen/arch/arm/lib/copy_template.S   |  266 ++++++++++++++++
 xen/arch/arm/lib/div64.S           |  149 +++++++++
 xen/arch/arm/lib/findbit.S         |  115 +++++++
 xen/arch/arm/lib/lib1funcs.S       |  302 ++++++++++++++++++
 xen/arch/arm/lib/memcpy.S          |   64 ++++
 xen/arch/arm/lib/memmove.S         |  200 ++++++++++++
 xen/arch/arm/lib/memset.S          |  129 ++++++++
 xen/arch/arm/lib/memzero.S         |  127 ++++++++
 xen/arch/arm/lib/setbit.S          |   18 +
 xen/arch/arm/lib/testchangebit.S   |   18 +
 xen/arch/arm/lib/testclearbit.S    |   18 +
 xen/arch/arm/lib/testsetbit.S      |   18 +
 xen/arch/arm/mm.c                  |  321 +++++++++++++++++++
 xen/arch/arm/p2m.c                 |  214 +++++++++++++
 xen/arch/arm/setup.c               |  206 ++++++++++++
 xen/arch/arm/shutdown.c            |   23 ++
 xen/arch/arm/smp.c                 |   29 ++
 xen/arch/arm/smpboot.c             |   50 +++
 xen/arch/arm/time.c                |  181 +++++++++++
 xen/arch/arm/traps.c               |  609 ++++++++++++++++++++++++++++++++++++
 xen/arch/arm/usercopy.c            |   81 +++++
 xen/arch/arm/vgic.c                |  605 +++++++++++++++++++++++++++++++++++
 xen/arch/arm/vtimer.c              |  148 +++++++++
 xen/arch/arm/vtimer.h              |   35 ++
 xen/arch/arm/xen.lds.S             |  141 +++++++++
 xen/arch/ia64/Rules.mk             |    5 +
 xen/arch/ia64/linux/memcpy_mck.S   |  177 +++++++++++
 xen/arch/x86/Rules.mk              |    5 +
 xen/arch/x86/usercopy.c            |   36 +++
 xen/common/Makefile                |    2 +-
 xen/common/domain.c                |   37 +--
 xen/common/domctl.c                |    1 +
 xen/common/grant_table.c           |    1 +
 xen/common/irq.c                   |    1 +
 xen/common/kernel.c                |    2 +-
 xen/common/keyhandler.c            |    1 +
 xen/common/lib.c                   |   19 ++
 xen/common/libelf/libelf-dominfo.c |    6 +
 xen/common/libelf/libelf-loader.c  |   17 +-
 xen/common/memory.c                |    4 +-
 xen/common/sched_credit2.c         |    6 -
 xen/common/shutdown.c              |    4 +
 xen/common/spinlock.c              |    1 +
 xen/common/tmem.c                  |    3 +-
 xen/common/tmem_xen.c              |    6 +-
 xen/common/wait.c                  |    1 +
 xen/drivers/Makefile               |    6 +-
 xen/drivers/char/Makefile          |    3 +-
 xen/drivers/char/console.c         |    5 +
 xen/drivers/char/pl011.c           |  266 ++++++++++++++++
 xen/drivers/cpufreq/cpufreq.c      |   31 ++
 xen/include/asm-arm/asm_defns.h    |   18 +
 xen/include/asm-arm/atomic.h       |  212 +++++++++++++
 xen/include/asm-arm/bitops.h       |  195 ++++++++++++
 xen/include/asm-arm/bug.h          |   15 +
 xen/include/asm-arm/byteorder.h    |   16 +
 xen/include/asm-arm/cache.h        |   20 ++
 xen/include/asm-arm/config.h       |  122 +++++++
 xen/include/asm-arm/cpregs.h       |  207 ++++++++++++
 xen/include/asm-arm/current.h      |   60 ++++
 xen/include/asm-arm/debugger.h     |   15 +
 xen/include/asm-arm/delay.h        |   15 +
 xen/include/asm-arm/desc.h         |   12 +
 xen/include/asm-arm/div64.h        |  235 ++++++++++++++
 xen/include/asm-arm/domain.h       |   82 +++++
 xen/include/asm-arm/elf.h          |   33 ++
 xen/include/asm-arm/event.h        |   41 +++
 xen/include/asm-arm/flushtlb.h     |   31 ++
 xen/include/asm-arm/grant_table.h  |   35 ++
 xen/include/asm-arm/guest_access.h |  125 ++++++++
 xen/include/asm-arm/hardirq.h      |   28 ++
 xen/include/asm-arm/hypercall.h    |   24 ++
 xen/include/asm-arm/init.h         |   12 +
 xen/include/asm-arm/io.h           |   12 +
 xen/include/asm-arm/iocap.h        |   20 ++
 xen/include/asm-arm/irq.h          |   30 ++
 xen/include/asm-arm/mm.h           |  315 +++++++++++++++++++
 xen/include/asm-arm/multicall.h    |   23 ++
 xen/include/asm-arm/nmi.h          |   15 +
 xen/include/asm-arm/numa.h         |   21 ++
 xen/include/asm-arm/p2m.h          |   88 ++++++
 xen/include/asm-arm/page.h         |  335 ++++++++++++++++++++
 xen/include/asm-arm/paging.h       |   13 +
 xen/include/asm-arm/percpu.h       |   28 ++
 xen/include/asm-arm/processor.h    |  269 ++++++++++++++++
 xen/include/asm-arm/regs.h         |   43 +++
 xen/include/asm-arm/setup.h        |   20 ++
 xen/include/asm-arm/smp.h          |   25 ++
 xen/include/asm-arm/softirq.h      |   15 +
 xen/include/asm-arm/spinlock.h     |  144 +++++++++
 xen/include/asm-arm/string.h       |   38 +++
 xen/include/asm-arm/system.h       |  202 ++++++++++++
 xen/include/asm-arm/time.h         |   26 ++
 xen/include/asm-arm/trace.h        |   12 +
 xen/include/asm-arm/types.h        |   57 ++++
 xen/include/asm-arm/xenoprof.h     |   12 +
 xen/include/asm-ia64/config.h      |    2 +
 xen/include/asm-ia64/uaccess.h     |   12 +
 xen/include/asm-x86/config.h       |    3 +
 xen/include/asm-x86/uaccess.h      |    1 +
 xen/include/public/arch-arm.h      |  125 ++++++++
 xen/include/public/xen.h           |    2 +
 xen/include/xen/domain.h           |    2 +
 xen/include/xen/grant_table.h      |    1 +
 xen/include/xen/irq.h              |   13 +
 xen/include/xen/kernel.h           |   12 +-
 xen/include/xen/libelf.h           |    2 +-
 xen/include/xen/list.h             |    1 +
 xen/include/xen/sched.h            |    4 +
 xen/include/xen/serial.h           |    2 +
 xen/include/xen/time.h             |    1 +
 xen/include/xen/timer.h            |    1 +
 xen/include/xen/tmem_xen.h         |    1 +
 132 files changed, 10355 insertions(+), 56 deletions(-)


A git branch is available here, based on xen-unstable (git CS
367ababd691a023944d648a6d980ccf866b01169):

git://xenbits.xen.org/people/sstabellini/xen-unstable.git arm-v2


Cheers,

Stefano

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 13:13:34 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 13:13:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZ0FT-0002Az-8W; Fri, 09 Dec 2011 13:12:23 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RZ0FR-0002Ae-W1
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 13:12:22 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1323436292!4908091!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI2MQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23563 invoked from network); 9 Dec 2011 13:11:32 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 13:11:32 -0000
X-IronPort-AV: E=Sophos;i="4.71,325,1320624000"; 
   d="scan'208";a="9383804"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 13:11:32 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 13:11:32 +0000
Date: Fri, 9 Dec 2011 13:12:05 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Message-ID: <alpine.DEB.2.00.1112091208420.3517@kaball-desktop>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"Tim Deegan \(3P\)" <Tim.Deegan@citrix.com>
Subject: [Xen-devel] [PATCH v2 00/25] xen: ARMv7 with virtualization
	extensions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hello everyone,
this is the second version of the patch series that introduces ARMv7
with virtualization extensions support in Xen.
The series allows Xen and Dom0 to boot on a Cortex-A15 based Versatile
Express simulator.
See the following announce email for more informations about what we
are trying to achieve, as well as the original git history:

See http://marc.info/?l=xen-devel&m=132257857628098&w=2


The first 7 patches affect generic Xen code and are not ARM specific;
often they fix real issues, hidden in the default X86 configuration.

The following 18 patches introduce ARMv7 with virtualization extensions
support: makefiles first, then the asm-arm header files and finally
everything else, ordered in a way that should make the patches easier
to read.


Changes in v2:

- introduce CONFIG_XENOPROF;

- make _srodata and  _erodata const char[];

- do not include p2m.h ifdef __ia64__;

- remove wrong comment about pfn.h;

- introduce HAS_KEXEC and CONFIG_KEXEC;

- use long in __do_clear_user;

- remove the div64 patch, implement __aeabi_ldivmod and __aeabi_uldivmod
instead;

- move "arm: makefiles" at the end of the series.


Stefano Stabellini (25):
      Move cpufreq option parsing to cpufreq.c
      Include some header files that are not automatically included on all archs
      A collection of fixes to Xen common files
      xen: implement an signed 64 bit division helper function
      Introduce clear_user
      libelf-loader: introduce elf_load_image
      xen/common/Makefile: introduce HAS_CPUFREQ, HAS_PCI, HAS_PASSTHROUGH, HAS_NS16550, HAS_KEXEC
      arm: compile tmem
      arm: header files
      arm: bit manipulation, copy and division libraries
      arm: entry.S and head.S
      arm: domain
      arm: domain_build
      arm: driver for CoreLink GIC-400 Generic Interrupt Controller
      arm: mmio handlers
      arm: irq
      arm: mm and p2m
      arm: pl011 UART driver
      arm: early setup code
      arm: shutdown, smp and smpboot
      arm: driver for the generic timer for ARMv7
      arm: trap handlers
      arm: vgic emulation
      arm: vtimer
      arm: makefiles

 config/arm.mk                      |   18 +
 xen/arch/arm/Makefile              |   76 +++++
 xen/arch/arm/Rules.mk              |   29 ++
 xen/arch/arm/asm-offsets.c         |   76 +++++
 xen/arch/arm/domain.c              |  269 ++++++++++++++++
 xen/arch/arm/domain_build.c        |  212 +++++++++++++
 xen/arch/arm/dummy.S               |   72 +++++
 xen/arch/arm/entry.S               |  107 +++++++
 xen/arch/arm/gic.c                 |  473 ++++++++++++++++++++++++++++
 xen/arch/arm/gic.h                 |  154 +++++++++
 xen/arch/arm/head.S                |  298 ++++++++++++++++++
 xen/arch/arm/io.c                  |   51 +++
 xen/arch/arm/io.h                  |   55 ++++
 xen/arch/arm/irq.c                 |  180 +++++++++++
 xen/arch/arm/lib/Makefile          |    5 +
 xen/arch/arm/lib/assembler.h       |   49 +++
 xen/arch/arm/lib/bitops.h          |   36 +++
 xen/arch/arm/lib/changebit.S       |   18 +
 xen/arch/arm/lib/clearbit.S        |   19 ++
 xen/arch/arm/lib/copy_template.S   |  266 ++++++++++++++++
 xen/arch/arm/lib/div64.S           |  149 +++++++++
 xen/arch/arm/lib/findbit.S         |  115 +++++++
 xen/arch/arm/lib/lib1funcs.S       |  302 ++++++++++++++++++
 xen/arch/arm/lib/memcpy.S          |   64 ++++
 xen/arch/arm/lib/memmove.S         |  200 ++++++++++++
 xen/arch/arm/lib/memset.S          |  129 ++++++++
 xen/arch/arm/lib/memzero.S         |  127 ++++++++
 xen/arch/arm/lib/setbit.S          |   18 +
 xen/arch/arm/lib/testchangebit.S   |   18 +
 xen/arch/arm/lib/testclearbit.S    |   18 +
 xen/arch/arm/lib/testsetbit.S      |   18 +
 xen/arch/arm/mm.c                  |  321 +++++++++++++++++++
 xen/arch/arm/p2m.c                 |  214 +++++++++++++
 xen/arch/arm/setup.c               |  206 ++++++++++++
 xen/arch/arm/shutdown.c            |   23 ++
 xen/arch/arm/smp.c                 |   29 ++
 xen/arch/arm/smpboot.c             |   50 +++
 xen/arch/arm/time.c                |  181 +++++++++++
 xen/arch/arm/traps.c               |  609 ++++++++++++++++++++++++++++++++++++
 xen/arch/arm/usercopy.c            |   81 +++++
 xen/arch/arm/vgic.c                |  605 +++++++++++++++++++++++++++++++++++
 xen/arch/arm/vtimer.c              |  148 +++++++++
 xen/arch/arm/vtimer.h              |   35 ++
 xen/arch/arm/xen.lds.S             |  141 +++++++++
 xen/arch/ia64/Rules.mk             |    5 +
 xen/arch/ia64/linux/memcpy_mck.S   |  177 +++++++++++
 xen/arch/x86/Rules.mk              |    5 +
 xen/arch/x86/usercopy.c            |   36 +++
 xen/common/Makefile                |    2 +-
 xen/common/domain.c                |   37 +--
 xen/common/domctl.c                |    1 +
 xen/common/grant_table.c           |    1 +
 xen/common/irq.c                   |    1 +
 xen/common/kernel.c                |    2 +-
 xen/common/keyhandler.c            |    1 +
 xen/common/lib.c                   |   19 ++
 xen/common/libelf/libelf-dominfo.c |    6 +
 xen/common/libelf/libelf-loader.c  |   17 +-
 xen/common/memory.c                |    4 +-
 xen/common/sched_credit2.c         |    6 -
 xen/common/shutdown.c              |    4 +
 xen/common/spinlock.c              |    1 +
 xen/common/tmem.c                  |    3 +-
 xen/common/tmem_xen.c              |    6 +-
 xen/common/wait.c                  |    1 +
 xen/drivers/Makefile               |    6 +-
 xen/drivers/char/Makefile          |    3 +-
 xen/drivers/char/console.c         |    5 +
 xen/drivers/char/pl011.c           |  266 ++++++++++++++++
 xen/drivers/cpufreq/cpufreq.c      |   31 ++
 xen/include/asm-arm/asm_defns.h    |   18 +
 xen/include/asm-arm/atomic.h       |  212 +++++++++++++
 xen/include/asm-arm/bitops.h       |  195 ++++++++++++
 xen/include/asm-arm/bug.h          |   15 +
 xen/include/asm-arm/byteorder.h    |   16 +
 xen/include/asm-arm/cache.h        |   20 ++
 xen/include/asm-arm/config.h       |  122 +++++++
 xen/include/asm-arm/cpregs.h       |  207 ++++++++++++
 xen/include/asm-arm/current.h      |   60 ++++
 xen/include/asm-arm/debugger.h     |   15 +
 xen/include/asm-arm/delay.h        |   15 +
 xen/include/asm-arm/desc.h         |   12 +
 xen/include/asm-arm/div64.h        |  235 ++++++++++++++
 xen/include/asm-arm/domain.h       |   82 +++++
 xen/include/asm-arm/elf.h          |   33 ++
 xen/include/asm-arm/event.h        |   41 +++
 xen/include/asm-arm/flushtlb.h     |   31 ++
 xen/include/asm-arm/grant_table.h  |   35 ++
 xen/include/asm-arm/guest_access.h |  125 ++++++++
 xen/include/asm-arm/hardirq.h      |   28 ++
 xen/include/asm-arm/hypercall.h    |   24 ++
 xen/include/asm-arm/init.h         |   12 +
 xen/include/asm-arm/io.h           |   12 +
 xen/include/asm-arm/iocap.h        |   20 ++
 xen/include/asm-arm/irq.h          |   30 ++
 xen/include/asm-arm/mm.h           |  315 +++++++++++++++++++
 xen/include/asm-arm/multicall.h    |   23 ++
 xen/include/asm-arm/nmi.h          |   15 +
 xen/include/asm-arm/numa.h         |   21 ++
 xen/include/asm-arm/p2m.h          |   88 ++++++
 xen/include/asm-arm/page.h         |  335 ++++++++++++++++++++
 xen/include/asm-arm/paging.h       |   13 +
 xen/include/asm-arm/percpu.h       |   28 ++
 xen/include/asm-arm/processor.h    |  269 ++++++++++++++++
 xen/include/asm-arm/regs.h         |   43 +++
 xen/include/asm-arm/setup.h        |   20 ++
 xen/include/asm-arm/smp.h          |   25 ++
 xen/include/asm-arm/softirq.h      |   15 +
 xen/include/asm-arm/spinlock.h     |  144 +++++++++
 xen/include/asm-arm/string.h       |   38 +++
 xen/include/asm-arm/system.h       |  202 ++++++++++++
 xen/include/asm-arm/time.h         |   26 ++
 xen/include/asm-arm/trace.h        |   12 +
 xen/include/asm-arm/types.h        |   57 ++++
 xen/include/asm-arm/xenoprof.h     |   12 +
 xen/include/asm-ia64/config.h      |    2 +
 xen/include/asm-ia64/uaccess.h     |   12 +
 xen/include/asm-x86/config.h       |    3 +
 xen/include/asm-x86/uaccess.h      |    1 +
 xen/include/public/arch-arm.h      |  125 ++++++++
 xen/include/public/xen.h           |    2 +
 xen/include/xen/domain.h           |    2 +
 xen/include/xen/grant_table.h      |    1 +
 xen/include/xen/irq.h              |   13 +
 xen/include/xen/kernel.h           |   12 +-
 xen/include/xen/libelf.h           |    2 +-
 xen/include/xen/list.h             |    1 +
 xen/include/xen/sched.h            |    4 +
 xen/include/xen/serial.h           |    2 +
 xen/include/xen/time.h             |    1 +
 xen/include/xen/timer.h            |    1 +
 xen/include/xen/tmem_xen.h         |    1 +
 132 files changed, 10355 insertions(+), 56 deletions(-)


A git branch is available here, based on xen-unstable (git CS
367ababd691a023944d648a6d980ccf866b01169):

git://xenbits.xen.org/people/sstabellini/xen-unstable.git arm-v2


Cheers,

Stefano

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 13:14:28 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 13:14:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZ0H2-0002H6-Nc; Fri, 09 Dec 2011 13:14:00 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RZ0H1-0002GI-Fm
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 13:13:59 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1323436384!4910711!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMTkxNzY=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30231 invoked from network); 9 Dec 2011 13:13:10 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 13:13:10 -0000
X-IronPort-AV: E=Sophos;i="4.71,325,1320642000"; d="scan'208";a="173546228"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 08:13:09 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 08:13:09 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pB9DCpDo008248;
	Fri, 9 Dec 2011 05:12:57 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 9 Dec 2011 13:13:07 +0000
Message-ID: <1323436408-16335-4-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1112091208420.3517@kaball-desktop>
References: <alpine.DEB.2.00.1112091208420.3517@kaball-desktop>
MIME-Version: 1.0
Cc: keir.xen@gmail.com, Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian.Campbell@citrix.com, JBeulich@suse.com, Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v2 04/25] xen: implement an signed 64 bit
	division helper function
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Implement a C function to perform 64 bit signed division and return both
quotient and remainder.
Useful as an helper function to implement __aeabi_ldivmod.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen/common/lib.c |   19 +++++++++++++++++++
 1 files changed, 19 insertions(+), 0 deletions(-)

diff --git a/xen/common/lib.c b/xen/common/lib.c
index 4ae637c..fe831a3 100644
--- a/xen/common/lib.c
+++ b/xen/common/lib.c
@@ -399,6 +399,25 @@ s64 __moddi3(s64 a, s64 b)
     return (neg ? -urem : urem);
 }
 
+/*
+ * Quotient and remainder of unsigned long long division
+ */
+s64 __ldivmod_helper(s64 a, s64 b, s64 *r)
+{
+    u64 ua, ub, rem, quot;
+
+    ua = (a < 0) ? -(u64)a : a;
+    ub = (b < 0) ? -(u64)b : b;
+    quot = __qdivrem(ua, ub, &rem);
+    if ( a < 0 )
+        *r = -rem;
+    else
+        *r = rem;
+    if ( (a < 0) ^ (b < 0) )
+        return -quot;
+    else
+        return quot;
+}
 #endif /* BITS_PER_LONG == 32 */
 
 /* Compute with 96 bit intermediate result: (a*b)/c */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 13:14:28 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 13:14:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZ0H2-0002H6-Nc; Fri, 09 Dec 2011 13:14:00 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RZ0H1-0002GI-Fm
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 13:13:59 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1323436384!4910711!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMTkxNzY=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30231 invoked from network); 9 Dec 2011 13:13:10 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 13:13:10 -0000
X-IronPort-AV: E=Sophos;i="4.71,325,1320642000"; d="scan'208";a="173546228"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 08:13:09 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 08:13:09 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pB9DCpDo008248;
	Fri, 9 Dec 2011 05:12:57 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 9 Dec 2011 13:13:07 +0000
Message-ID: <1323436408-16335-4-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1112091208420.3517@kaball-desktop>
References: <alpine.DEB.2.00.1112091208420.3517@kaball-desktop>
MIME-Version: 1.0
Cc: keir.xen@gmail.com, Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian.Campbell@citrix.com, JBeulich@suse.com, Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v2 04/25] xen: implement an signed 64 bit
	division helper function
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Implement a C function to perform 64 bit signed division and return both
quotient and remainder.
Useful as an helper function to implement __aeabi_ldivmod.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen/common/lib.c |   19 +++++++++++++++++++
 1 files changed, 19 insertions(+), 0 deletions(-)

diff --git a/xen/common/lib.c b/xen/common/lib.c
index 4ae637c..fe831a3 100644
--- a/xen/common/lib.c
+++ b/xen/common/lib.c
@@ -399,6 +399,25 @@ s64 __moddi3(s64 a, s64 b)
     return (neg ? -urem : urem);
 }
 
+/*
+ * Quotient and remainder of unsigned long long division
+ */
+s64 __ldivmod_helper(s64 a, s64 b, s64 *r)
+{
+    u64 ua, ub, rem, quot;
+
+    ua = (a < 0) ? -(u64)a : a;
+    ub = (b < 0) ? -(u64)b : b;
+    quot = __qdivrem(ua, ub, &rem);
+    if ( a < 0 )
+        *r = -rem;
+    else
+        *r = rem;
+    if ( (a < 0) ^ (b < 0) )
+        return -quot;
+    else
+        return quot;
+}
 #endif /* BITS_PER_LONG == 32 */
 
 /* Compute with 96 bit intermediate result: (a*b)/c */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 13:14:29 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 13:14:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZ0H9-0002Jw-Tw; Fri, 09 Dec 2011 13:14:07 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RZ0H6-0002Gm-Ts
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 13:14:05 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1323436384!4910711!4
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMTkxNzY=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30446 invoked from network); 9 Dec 2011 13:13:14 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 13:13:14 -0000
X-IronPort-AV: E=Sophos;i="4.71,325,1320642000"; d="scan'208";a="173546241"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 08:13:14 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 08:13:14 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pB9DCpDr008248;
	Fri, 9 Dec 2011 05:13:02 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 9 Dec 2011 13:13:10 +0000
Message-ID: <1323436408-16335-7-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1112091208420.3517@kaball-desktop>
References: <alpine.DEB.2.00.1112091208420.3517@kaball-desktop>
MIME-Version: 1.0
Cc: keir.xen@gmail.com, Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, JBeulich@suse.com,
	Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v2 07/25] xen/common/Makefile: introduce
	HAS_CPUFREQ, HAS_PCI, HAS_PASSTHROUGH, HAS_NS16550, HAS_KEXEC
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

- make the compilation of ns16550.c depend upon HAS_NS16550;

- make the compilation of cpufreq depend upon HAS_CPUFREQ;

- make the compilation of pci depend upon HAS_PCI;

- make the compilation of passthrough depend upon HAS_PASSTHROUGH;

- make the compilation of kexec depend upon HAS_KEXEC.


Changes in v2:

- introduce HAS_KEXEC and CONFIG_KEXEC kexec.


Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
---
 xen/arch/ia64/Rules.mk        |    5 +++++
 xen/arch/x86/Rules.mk         |    5 +++++
 xen/common/Makefile           |    2 +-
 xen/common/shutdown.c         |    4 ++++
 xen/drivers/Makefile          |    6 +++---
 xen/drivers/char/Makefile     |    2 +-
 xen/drivers/char/console.c    |    4 ++++
 xen/include/asm-ia64/config.h |    1 +
 xen/include/asm-x86/config.h  |    1 +
 9 files changed, 25 insertions(+), 5 deletions(-)

diff --git a/xen/arch/ia64/Rules.mk b/xen/arch/ia64/Rules.mk
index bef11c3..054b4de 100644
--- a/xen/arch/ia64/Rules.mk
+++ b/xen/arch/ia64/Rules.mk
@@ -4,6 +4,11 @@
 ia64 := y
 HAS_ACPI := y
 HAS_VGA  := y
+HAS_CPUFREQ := y
+HAS_PCI := y
+HAS_PASSTHROUGH := y
+HAS_NS16550 := y
+HAS_KEXEC := y
 xenoprof := y
 no_warns ?= n
 vti_debug ?= n
diff --git a/xen/arch/x86/Rules.mk b/xen/arch/x86/Rules.mk
index bf77aef..1e48877 100644
--- a/xen/arch/x86/Rules.mk
+++ b/xen/arch/x86/Rules.mk
@@ -3,6 +3,11 @@
 
 HAS_ACPI := y
 HAS_VGA  := y
+HAS_CPUFREQ := y
+HAS_PCI := y
+HAS_PASSTHROUGH := y
+HAS_NS16550 := y
+HAS_KEXEC := y
 xenoprof := y
 
 #
diff --git a/xen/common/Makefile b/xen/common/Makefile
index 1d85e65..9249845 100644
--- a/xen/common/Makefile
+++ b/xen/common/Makefile
@@ -8,7 +8,7 @@ obj-y += grant_table.o
 obj-y += irq.o
 obj-y += kernel.o
 obj-y += keyhandler.o
-obj-y += kexec.o
+obj-$(HAS_KEXEC) += kexec.o
 obj-y += lib.o
 obj-y += memory.o
 obj-y += multicall.o
diff --git a/xen/common/shutdown.c b/xen/common/shutdown.c
index e356e86..b18ef5d 100644
--- a/xen/common/shutdown.c
+++ b/xen/common/shutdown.c
@@ -6,7 +6,9 @@
 #include <xen/delay.h>
 #include <xen/shutdown.h>
 #include <xen/console.h>
+#ifdef CONFIG_KEXEC
 #include <xen/kexec.h>
+#endif
 #include <asm/debugger.h>
 #include <public/sched.h>
 
@@ -58,7 +60,9 @@ void dom0_shutdown(u8 reason)
     case SHUTDOWN_watchdog:
     {
         printk("Domain 0 shutdown: watchdog rebooting machine.\n");
+#ifdef CONFIG_KEXEC
         kexec_crash();
+#endif
         machine_restart(0);
         break; /* not reached */
     }
diff --git a/xen/drivers/Makefile b/xen/drivers/Makefile
index eb4fb61..7239375 100644
--- a/xen/drivers/Makefile
+++ b/xen/drivers/Makefile
@@ -1,6 +1,6 @@
 subdir-y += char
-subdir-y += cpufreq
-subdir-y += pci
-subdir-y += passthrough
+subdir-$(HAS_CPUFREQ) += cpufreq
+subdir-$(HAS_PCI) += pci
+subdir-$(HAS_PASSTHROUGH) += passthrough
 subdir-$(HAS_ACPI) += acpi
 subdir-$(HAS_VGA) += video
diff --git a/xen/drivers/char/Makefile b/xen/drivers/char/Makefile
index ded9a94..19250c8 100644
--- a/xen/drivers/char/Makefile
+++ b/xen/drivers/char/Makefile
@@ -1,3 +1,3 @@
 obj-y += console.o
-obj-y += ns16550.o
+obj-$(HAS_NS16550) += ns16550.o
 obj-y += serial.o
diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
index 89cf4f8..19f021c 100644
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -22,7 +22,9 @@
 #include <xen/guest_access.h>
 #include <xen/shutdown.h>
 #include <xen/vga.h>
+#ifdef CONFIG_KEXEC
 #include <xen/kexec.h>
+#endif
 #include <asm/debugger.h>
 #include <asm/div64.h>
 #include <xen/hypercall.h> /* for do_console_io */
@@ -961,7 +963,9 @@ void panic(const char *fmt, ...)
 
     debugger_trap_immediate();
 
+#ifdef CONFIG_KEXEC
     kexec_crash();
+#endif
 
     if ( opt_noreboot )
     {
diff --git a/xen/include/asm-ia64/config.h b/xen/include/asm-ia64/config.h
index 0173487..6e9fc98 100644
--- a/xen/include/asm-ia64/config.h
+++ b/xen/include/asm-ia64/config.h
@@ -20,6 +20,7 @@
 #define CONFIG_EFI
 #define CONFIG_EFI_PCDP
 #define CONFIG_SERIAL_SGI_L1_CONSOLE
+#define CONFIG_KEXEC 1
 #define CONFIG_XENOPROF 1
 
 #define CONFIG_XEN_SMP
diff --git a/xen/include/asm-x86/config.h b/xen/include/asm-x86/config.h
index 905c0f8..cf6a4cc 100644
--- a/xen/include/asm-x86/config.h
+++ b/xen/include/asm-x86/config.h
@@ -44,6 +44,7 @@
 #define CONFIG_HOTPLUG_CPU 1
 
 #define CONFIG_XENOPROF 1
+#define CONFIG_KEXEC 1
 
 #define HZ 100
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 13:14:29 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 13:14:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZ0H9-0002Jw-Tw; Fri, 09 Dec 2011 13:14:07 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RZ0H6-0002Gm-Ts
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 13:14:05 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1323436384!4910711!4
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMTkxNzY=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30446 invoked from network); 9 Dec 2011 13:13:14 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 13:13:14 -0000
X-IronPort-AV: E=Sophos;i="4.71,325,1320642000"; d="scan'208";a="173546241"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 08:13:14 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 08:13:14 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pB9DCpDr008248;
	Fri, 9 Dec 2011 05:13:02 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 9 Dec 2011 13:13:10 +0000
Message-ID: <1323436408-16335-7-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1112091208420.3517@kaball-desktop>
References: <alpine.DEB.2.00.1112091208420.3517@kaball-desktop>
MIME-Version: 1.0
Cc: keir.xen@gmail.com, Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, JBeulich@suse.com,
	Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v2 07/25] xen/common/Makefile: introduce
	HAS_CPUFREQ, HAS_PCI, HAS_PASSTHROUGH, HAS_NS16550, HAS_KEXEC
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

- make the compilation of ns16550.c depend upon HAS_NS16550;

- make the compilation of cpufreq depend upon HAS_CPUFREQ;

- make the compilation of pci depend upon HAS_PCI;

- make the compilation of passthrough depend upon HAS_PASSTHROUGH;

- make the compilation of kexec depend upon HAS_KEXEC.


Changes in v2:

- introduce HAS_KEXEC and CONFIG_KEXEC kexec.


Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
---
 xen/arch/ia64/Rules.mk        |    5 +++++
 xen/arch/x86/Rules.mk         |    5 +++++
 xen/common/Makefile           |    2 +-
 xen/common/shutdown.c         |    4 ++++
 xen/drivers/Makefile          |    6 +++---
 xen/drivers/char/Makefile     |    2 +-
 xen/drivers/char/console.c    |    4 ++++
 xen/include/asm-ia64/config.h |    1 +
 xen/include/asm-x86/config.h  |    1 +
 9 files changed, 25 insertions(+), 5 deletions(-)

diff --git a/xen/arch/ia64/Rules.mk b/xen/arch/ia64/Rules.mk
index bef11c3..054b4de 100644
--- a/xen/arch/ia64/Rules.mk
+++ b/xen/arch/ia64/Rules.mk
@@ -4,6 +4,11 @@
 ia64 := y
 HAS_ACPI := y
 HAS_VGA  := y
+HAS_CPUFREQ := y
+HAS_PCI := y
+HAS_PASSTHROUGH := y
+HAS_NS16550 := y
+HAS_KEXEC := y
 xenoprof := y
 no_warns ?= n
 vti_debug ?= n
diff --git a/xen/arch/x86/Rules.mk b/xen/arch/x86/Rules.mk
index bf77aef..1e48877 100644
--- a/xen/arch/x86/Rules.mk
+++ b/xen/arch/x86/Rules.mk
@@ -3,6 +3,11 @@
 
 HAS_ACPI := y
 HAS_VGA  := y
+HAS_CPUFREQ := y
+HAS_PCI := y
+HAS_PASSTHROUGH := y
+HAS_NS16550 := y
+HAS_KEXEC := y
 xenoprof := y
 
 #
diff --git a/xen/common/Makefile b/xen/common/Makefile
index 1d85e65..9249845 100644
--- a/xen/common/Makefile
+++ b/xen/common/Makefile
@@ -8,7 +8,7 @@ obj-y += grant_table.o
 obj-y += irq.o
 obj-y += kernel.o
 obj-y += keyhandler.o
-obj-y += kexec.o
+obj-$(HAS_KEXEC) += kexec.o
 obj-y += lib.o
 obj-y += memory.o
 obj-y += multicall.o
diff --git a/xen/common/shutdown.c b/xen/common/shutdown.c
index e356e86..b18ef5d 100644
--- a/xen/common/shutdown.c
+++ b/xen/common/shutdown.c
@@ -6,7 +6,9 @@
 #include <xen/delay.h>
 #include <xen/shutdown.h>
 #include <xen/console.h>
+#ifdef CONFIG_KEXEC
 #include <xen/kexec.h>
+#endif
 #include <asm/debugger.h>
 #include <public/sched.h>
 
@@ -58,7 +60,9 @@ void dom0_shutdown(u8 reason)
     case SHUTDOWN_watchdog:
     {
         printk("Domain 0 shutdown: watchdog rebooting machine.\n");
+#ifdef CONFIG_KEXEC
         kexec_crash();
+#endif
         machine_restart(0);
         break; /* not reached */
     }
diff --git a/xen/drivers/Makefile b/xen/drivers/Makefile
index eb4fb61..7239375 100644
--- a/xen/drivers/Makefile
+++ b/xen/drivers/Makefile
@@ -1,6 +1,6 @@
 subdir-y += char
-subdir-y += cpufreq
-subdir-y += pci
-subdir-y += passthrough
+subdir-$(HAS_CPUFREQ) += cpufreq
+subdir-$(HAS_PCI) += pci
+subdir-$(HAS_PASSTHROUGH) += passthrough
 subdir-$(HAS_ACPI) += acpi
 subdir-$(HAS_VGA) += video
diff --git a/xen/drivers/char/Makefile b/xen/drivers/char/Makefile
index ded9a94..19250c8 100644
--- a/xen/drivers/char/Makefile
+++ b/xen/drivers/char/Makefile
@@ -1,3 +1,3 @@
 obj-y += console.o
-obj-y += ns16550.o
+obj-$(HAS_NS16550) += ns16550.o
 obj-y += serial.o
diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
index 89cf4f8..19f021c 100644
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -22,7 +22,9 @@
 #include <xen/guest_access.h>
 #include <xen/shutdown.h>
 #include <xen/vga.h>
+#ifdef CONFIG_KEXEC
 #include <xen/kexec.h>
+#endif
 #include <asm/debugger.h>
 #include <asm/div64.h>
 #include <xen/hypercall.h> /* for do_console_io */
@@ -961,7 +963,9 @@ void panic(const char *fmt, ...)
 
     debugger_trap_immediate();
 
+#ifdef CONFIG_KEXEC
     kexec_crash();
+#endif
 
     if ( opt_noreboot )
     {
diff --git a/xen/include/asm-ia64/config.h b/xen/include/asm-ia64/config.h
index 0173487..6e9fc98 100644
--- a/xen/include/asm-ia64/config.h
+++ b/xen/include/asm-ia64/config.h
@@ -20,6 +20,7 @@
 #define CONFIG_EFI
 #define CONFIG_EFI_PCDP
 #define CONFIG_SERIAL_SGI_L1_CONSOLE
+#define CONFIG_KEXEC 1
 #define CONFIG_XENOPROF 1
 
 #define CONFIG_XEN_SMP
diff --git a/xen/include/asm-x86/config.h b/xen/include/asm-x86/config.h
index 905c0f8..cf6a4cc 100644
--- a/xen/include/asm-x86/config.h
+++ b/xen/include/asm-x86/config.h
@@ -44,6 +44,7 @@
 #define CONFIG_HOTPLUG_CPU 1
 
 #define CONFIG_XENOPROF 1
+#define CONFIG_KEXEC 1
 
 #define HZ 100
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 13:14:30 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 13: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.xensource.com>)
	id 1RZ0H2-0002Gz-BO; Fri, 09 Dec 2011 13:14:00 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RZ0H0-0002Gf-Sb
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 13:13:59 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1323436346!56653758!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDQ0MTg=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7159 invoked from network); 9 Dec 2011 13:12:27 -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 2011 13:12:27 -0000
X-IronPort-AV: E=Sophos;i="4.71,325,1320642000"; d="scan'208";a="19808896"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 08:13:10 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 08:13:10 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pB9DCpDp008248;
	Fri, 9 Dec 2011 05:12:59 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 9 Dec 2011 13:13:08 +0000
Message-ID: <1323436408-16335-5-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1112091208420.3517@kaball-desktop>
References: <alpine.DEB.2.00.1112091208420.3517@kaball-desktop>
MIME-Version: 1.0
Cc: keir.xen@gmail.com, Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian.Campbell@citrix.com, JBeulich@suse.com, Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v2 05/25] Introduce clear_user
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Introduce clear_user for x86 and ia64, shamelessly taken from Linux.
The x86 version is the 32 bit clear_user implementation.


Changes in v2:

- change d0 to be a long;

- cast addr to long.


Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen/arch/ia64/linux/memcpy_mck.S |  177 ++++++++++++++++++++++++++++++++++++++
 xen/arch/x86/usercopy.c          |   36 ++++++++
 xen/include/asm-ia64/uaccess.h   |   12 +++
 xen/include/asm-x86/uaccess.h    |    1 +
 4 files changed, 226 insertions(+), 0 deletions(-)

diff --git a/xen/arch/ia64/linux/memcpy_mck.S b/xen/arch/ia64/linux/memcpy_mck.S
index 6f308e6..8b07006 100644
--- a/xen/arch/ia64/linux/memcpy_mck.S
+++ b/xen/arch/ia64/linux/memcpy_mck.S
@@ -659,3 +659,180 @@ EK(.ex_handler,  (p17)	st8	[dst1]=r39,8);						\
 
 /* end of McKinley specific optimization */
 END(__copy_user)
+
+/*
+ * Theory of operations:
+ *	- we check whether or not the buffer is small, i.e., less than 17
+ *	  in which case we do the byte by byte loop.
+ *
+ *	- Otherwise we go progressively from 1 byte store to 8byte store in
+ *	  the head part, the body is a 16byte store loop and we finish we the
+ *	  tail for the last 15 bytes.
+ *	  The good point about this breakdown is that the long buffer handling
+ *	  contains only 2 branches.
+ *
+ *	The reason for not using shifting & masking for both the head and the
+ *	tail is to stay semantically correct. This routine is not supposed
+ *	to write bytes outside of the buffer. While most of the time this would
+ *	be ok, we can't tolerate a mistake. A classical example is the case
+ *	of multithreaded code were to the extra bytes touched is actually owned
+ *	by another thread which runs concurrently to ours. Another, less likely,
+ *	example is with device drivers where reading an I/O mapped location may
+ *	have side effects (same thing for writing).
+ */
+GLOBAL_ENTRY(__do_clear_user)
+	.prologue
+	.save ar.pfs, saved_pfs
+	alloc	saved_pfs=ar.pfs,2,0,0,0
+	cmp.eq p6,p0=r0,len		// check for zero length
+	.save ar.lc, saved_lc
+	mov saved_lc=ar.lc		// preserve ar.lc (slow)
+	.body
+	;;				// avoid WAW on CFM
+	adds tmp=-1,len			// br.ctop is repeat/until
+	mov ret0=len			// return value is length at this point
+(p6)	br.ret.spnt.many rp
+	;;
+	cmp.lt p6,p0=16,len		// if len > 16 then long memset
+	mov ar.lc=tmp			// initialize lc for small count
+(p6)	br.cond.dptk .long_do_clear
+	;;				// WAR on ar.lc
+	//
+	// worst case 16 iterations, avg 8 iterations
+	//
+	// We could have played with the predicates to use the extra
+	// M slot for 2 stores/iteration but the cost the initialization
+	// the various counters compared to how long the loop is supposed
+	// to last on average does not make this solution viable.
+	//
+1:
+	EX( .Lexit1, st1 [buf]=r0,1 )
+	adds len=-1,len			// countdown length using len
+	br.cloop.dptk 1b
+	;;				// avoid RAW on ar.lc
+	//
+	// .Lexit4: comes from byte by byte loop
+	//	    len contains bytes left
+.Lexit1:
+	mov ret0=len			// faster than using ar.lc
+	mov ar.lc=saved_lc
+	br.ret.sptk.many rp		// end of short clear_user
+
+
+	//
+	// At this point we know we have more than 16 bytes to copy
+	// so we focus on alignment (no branches required)
+	//
+	// The use of len/len2 for countdown of the number of bytes left
+	// instead of ret0 is due to the fact that the exception code
+	// changes the values of r8.
+	//
+.long_do_clear:
+	tbit.nz p6,p0=buf,0		// odd alignment (for long_do_clear)
+	;;
+	EX( .Lexit3, (p6) st1 [buf]=r0,1 )	// 1-byte aligned
+(p6)	adds len=-1,len;;		// sync because buf is modified
+	tbit.nz p6,p0=buf,1
+	;;
+	EX( .Lexit3, (p6) st2 [buf]=r0,2 )	// 2-byte aligned
+(p6)	adds len=-2,len;;
+	tbit.nz p6,p0=buf,2
+	;;
+	EX( .Lexit3, (p6) st4 [buf]=r0,4 )	// 4-byte aligned
+(p6)	adds len=-4,len;;
+	tbit.nz p6,p0=buf,3
+	;;
+	EX( .Lexit3, (p6) st8 [buf]=r0,8 )	// 8-byte aligned
+(p6)	adds len=-8,len;;
+	shr.u cnt=len,4		// number of 128-bit (2x64bit) words
+	;;
+	cmp.eq p6,p0=r0,cnt
+	adds tmp=-1,cnt
+(p6)	br.cond.dpnt .dotail		// we have less than 16 bytes left
+	;;
+	adds buf2=8,buf			// setup second base pointer
+	mov ar.lc=tmp
+	;;
+
+	//
+	// 16bytes/iteration core loop
+	//
+	// The second store can never generate a fault because
+	// we come into the loop only when we are 16-byte aligned.
+	// This means that if we cross a page then it will always be
+	// in the first store and never in the second.
+	//
+	//
+	// We need to keep track of the remaining length. A possible (optimistic)
+	// way would be to use ar.lc and derive how many byte were left by
+	// doing : left= 16*ar.lc + 16.  this would avoid the addition at
+	// every iteration.
+	// However we need to keep the synchronization point. A template
+	// M;;MB does not exist and thus we can keep the addition at no
+	// extra cycle cost (use a nop slot anyway). It also simplifies the
+	// (unlikely)  error recovery code
+	//
+
+2:	EX(.Lexit3, st8 [buf]=r0,16 )
+	;;				// needed to get len correct when error
+	st8 [buf2]=r0,16
+	adds len=-16,len
+	br.cloop.dptk 2b
+	;;
+	mov ar.lc=saved_lc
+	//
+	// tail correction based on len only
+	//
+	// We alternate the use of len3,len2 to allow parallelism and correct
+	// error handling. We also reuse p6/p7 to return correct value.
+	// The addition of len2/len3 does not cost anything more compared to
+	// the regular memset as we had empty slots.
+	//
+.dotail:
+	mov len2=len			// for parallelization of error handling
+	mov len3=len
+	tbit.nz p6,p0=len,3
+	;;
+	EX( .Lexit2, (p6) st8 [buf]=r0,8 )	// at least 8 bytes
+(p6)	adds len3=-8,len2
+	tbit.nz p7,p6=len,2
+	;;
+	EX( .Lexit2, (p7) st4 [buf]=r0,4 )	// at least 4 bytes
+(p7)	adds len2=-4,len3
+	tbit.nz p6,p7=len,1
+	;;
+	EX( .Lexit2, (p6) st2 [buf]=r0,2 )	// at least 2 bytes
+(p6)	adds len3=-2,len2
+	tbit.nz p7,p6=len,0
+	;;
+	EX( .Lexit2, (p7) st1 [buf]=r0 )	// only 1 byte left
+	mov ret0=r0				// success
+	br.ret.sptk.many rp			// end of most likely path
+
+	//
+	// Outlined error handling code
+	//
+
+	//
+	// .Lexit3: comes from core loop, need restore pr/lc
+	//	    len contains bytes left
+	//
+	//
+	// .Lexit2:
+	//	if p6 -> coming from st8 or st2 : len2 contains what's left
+	//	if p7 -> coming from st4 or st1 : len3 contains what's left
+	// We must restore lc/pr even though might not have been used.
+.Lexit2:
+	.pred.rel "mutex", p6, p7
+(p6)	mov len=len2
+(p7)	mov len=len3
+	;;
+	//
+	// .Lexit4: comes from head, need not restore pr/lc
+	//	    len contains bytes left
+	//
+.Lexit3:
+	mov ret0=len
+	mov ar.lc=saved_lc
+	br.ret.sptk.many rp
+END(__do_clear_user)
diff --git a/xen/arch/x86/usercopy.c b/xen/arch/x86/usercopy.c
index d88e635..47dadae 100644
--- a/xen/arch/x86/usercopy.c
+++ b/xen/arch/x86/usercopy.c
@@ -110,6 +110,42 @@ copy_to_user(void __user *to, const void *from, unsigned n)
     return n;
 }
 
+#define __do_clear_user(addr,size)					\
+do {									\
+	long __d0;							\
+	__asm__ __volatile__(						\
+		"0:	rep; stosl\n"					\
+		"	movl %2,%0\n"					\
+		"1:	rep; stosb\n"					\
+		"2:\n"							\
+		".section .fixup,\"ax\"\n"				\
+		"3:	lea 0(%2,%0,4),%0\n"				\
+		"	jmp 2b\n"					\
+		".previous\n"						\
+		_ASM_EXTABLE(0b,3b)					\
+		_ASM_EXTABLE(1b,2b)					\
+		: "=&c"(size), "=&D" (__d0)				\
+		: "r"(size & 3), "0"(size / 4), "1"((long)addr), "a"(0));	\
+} while (0)
+
+/**
+ * clear_user: - Zero a block of memory in user space.
+ * @to:   Destination address, in user space.
+ * @n:    Number of bytes to zero.
+ *
+ * Zero a block of memory in user space.
+ *
+ * Returns number of bytes that could not be cleared.
+ * On success, this will be zero.
+ */
+unsigned long
+clear_user(void __user *to, unsigned n)
+{
+	if ( access_ok(to, n) )
+		__do_clear_user(to, n);
+	return n;
+}
+
 /**
  * copy_from_user: - Copy a block of data from user space.
  * @to:   Destination address, in kernel space.
diff --git a/xen/include/asm-ia64/uaccess.h b/xen/include/asm-ia64/uaccess.h
index 32ef415..2ececb1 100644
--- a/xen/include/asm-ia64/uaccess.h
+++ b/xen/include/asm-ia64/uaccess.h
@@ -236,6 +236,18 @@ __copy_from_user (void *to, const void __user *from, unsigned long count)
 	__cu_len;									\
 })
 
+extern unsigned long __do_clear_user (void __user * to, unsigned long count);
+
+#define clear_user(to, n)					\
+({								\
+	void __user *__cu_to = (to);							\
+	long __cu_len = (n);								\
+											\
+	if (__access_ok(__cu_to))							\
+		__cu_len = __do_clear_user(__cu_to, __cu_len);	\
+	__cu_len;						\
+})
+
 #define copy_from_user(to, from, n)							\
 ({											\
 	void *__cu_to = (to);								\
diff --git a/xen/include/asm-x86/uaccess.h b/xen/include/asm-x86/uaccess.h
index e3e541b..d6f4458 100644
--- a/xen/include/asm-x86/uaccess.h
+++ b/xen/include/asm-x86/uaccess.h
@@ -16,6 +16,7 @@
 #endif
 
 unsigned long copy_to_user(void *to, const void *from, unsigned len);
+unsigned long clear_user(void *to, unsigned len);
 unsigned long copy_from_user(void *to, const void *from, unsigned len);
 /* Handles exceptions in both to and from, but doesn't do access_ok */
 unsigned long __copy_to_user_ll(void *to, const void *from, unsigned n);
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 13:14:30 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 13: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.xensource.com>)
	id 1RZ0H2-0002Gz-BO; Fri, 09 Dec 2011 13:14:00 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RZ0H0-0002Gf-Sb
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 13:13:59 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1323436346!56653758!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDQ0MTg=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7159 invoked from network); 9 Dec 2011 13:12:27 -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 2011 13:12:27 -0000
X-IronPort-AV: E=Sophos;i="4.71,325,1320642000"; d="scan'208";a="19808896"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 08:13:10 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 08:13:10 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pB9DCpDp008248;
	Fri, 9 Dec 2011 05:12:59 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 9 Dec 2011 13:13:08 +0000
Message-ID: <1323436408-16335-5-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1112091208420.3517@kaball-desktop>
References: <alpine.DEB.2.00.1112091208420.3517@kaball-desktop>
MIME-Version: 1.0
Cc: keir.xen@gmail.com, Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian.Campbell@citrix.com, JBeulich@suse.com, Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v2 05/25] Introduce clear_user
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Introduce clear_user for x86 and ia64, shamelessly taken from Linux.
The x86 version is the 32 bit clear_user implementation.


Changes in v2:

- change d0 to be a long;

- cast addr to long.


Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen/arch/ia64/linux/memcpy_mck.S |  177 ++++++++++++++++++++++++++++++++++++++
 xen/arch/x86/usercopy.c          |   36 ++++++++
 xen/include/asm-ia64/uaccess.h   |   12 +++
 xen/include/asm-x86/uaccess.h    |    1 +
 4 files changed, 226 insertions(+), 0 deletions(-)

diff --git a/xen/arch/ia64/linux/memcpy_mck.S b/xen/arch/ia64/linux/memcpy_mck.S
index 6f308e6..8b07006 100644
--- a/xen/arch/ia64/linux/memcpy_mck.S
+++ b/xen/arch/ia64/linux/memcpy_mck.S
@@ -659,3 +659,180 @@ EK(.ex_handler,  (p17)	st8	[dst1]=r39,8);						\
 
 /* end of McKinley specific optimization */
 END(__copy_user)
+
+/*
+ * Theory of operations:
+ *	- we check whether or not the buffer is small, i.e., less than 17
+ *	  in which case we do the byte by byte loop.
+ *
+ *	- Otherwise we go progressively from 1 byte store to 8byte store in
+ *	  the head part, the body is a 16byte store loop and we finish we the
+ *	  tail for the last 15 bytes.
+ *	  The good point about this breakdown is that the long buffer handling
+ *	  contains only 2 branches.
+ *
+ *	The reason for not using shifting & masking for both the head and the
+ *	tail is to stay semantically correct. This routine is not supposed
+ *	to write bytes outside of the buffer. While most of the time this would
+ *	be ok, we can't tolerate a mistake. A classical example is the case
+ *	of multithreaded code were to the extra bytes touched is actually owned
+ *	by another thread which runs concurrently to ours. Another, less likely,
+ *	example is with device drivers where reading an I/O mapped location may
+ *	have side effects (same thing for writing).
+ */
+GLOBAL_ENTRY(__do_clear_user)
+	.prologue
+	.save ar.pfs, saved_pfs
+	alloc	saved_pfs=ar.pfs,2,0,0,0
+	cmp.eq p6,p0=r0,len		// check for zero length
+	.save ar.lc, saved_lc
+	mov saved_lc=ar.lc		// preserve ar.lc (slow)
+	.body
+	;;				// avoid WAW on CFM
+	adds tmp=-1,len			// br.ctop is repeat/until
+	mov ret0=len			// return value is length at this point
+(p6)	br.ret.spnt.many rp
+	;;
+	cmp.lt p6,p0=16,len		// if len > 16 then long memset
+	mov ar.lc=tmp			// initialize lc for small count
+(p6)	br.cond.dptk .long_do_clear
+	;;				// WAR on ar.lc
+	//
+	// worst case 16 iterations, avg 8 iterations
+	//
+	// We could have played with the predicates to use the extra
+	// M slot for 2 stores/iteration but the cost the initialization
+	// the various counters compared to how long the loop is supposed
+	// to last on average does not make this solution viable.
+	//
+1:
+	EX( .Lexit1, st1 [buf]=r0,1 )
+	adds len=-1,len			// countdown length using len
+	br.cloop.dptk 1b
+	;;				// avoid RAW on ar.lc
+	//
+	// .Lexit4: comes from byte by byte loop
+	//	    len contains bytes left
+.Lexit1:
+	mov ret0=len			// faster than using ar.lc
+	mov ar.lc=saved_lc
+	br.ret.sptk.many rp		// end of short clear_user
+
+
+	//
+	// At this point we know we have more than 16 bytes to copy
+	// so we focus on alignment (no branches required)
+	//
+	// The use of len/len2 for countdown of the number of bytes left
+	// instead of ret0 is due to the fact that the exception code
+	// changes the values of r8.
+	//
+.long_do_clear:
+	tbit.nz p6,p0=buf,0		// odd alignment (for long_do_clear)
+	;;
+	EX( .Lexit3, (p6) st1 [buf]=r0,1 )	// 1-byte aligned
+(p6)	adds len=-1,len;;		// sync because buf is modified
+	tbit.nz p6,p0=buf,1
+	;;
+	EX( .Lexit3, (p6) st2 [buf]=r0,2 )	// 2-byte aligned
+(p6)	adds len=-2,len;;
+	tbit.nz p6,p0=buf,2
+	;;
+	EX( .Lexit3, (p6) st4 [buf]=r0,4 )	// 4-byte aligned
+(p6)	adds len=-4,len;;
+	tbit.nz p6,p0=buf,3
+	;;
+	EX( .Lexit3, (p6) st8 [buf]=r0,8 )	// 8-byte aligned
+(p6)	adds len=-8,len;;
+	shr.u cnt=len,4		// number of 128-bit (2x64bit) words
+	;;
+	cmp.eq p6,p0=r0,cnt
+	adds tmp=-1,cnt
+(p6)	br.cond.dpnt .dotail		// we have less than 16 bytes left
+	;;
+	adds buf2=8,buf			// setup second base pointer
+	mov ar.lc=tmp
+	;;
+
+	//
+	// 16bytes/iteration core loop
+	//
+	// The second store can never generate a fault because
+	// we come into the loop only when we are 16-byte aligned.
+	// This means that if we cross a page then it will always be
+	// in the first store and never in the second.
+	//
+	//
+	// We need to keep track of the remaining length. A possible (optimistic)
+	// way would be to use ar.lc and derive how many byte were left by
+	// doing : left= 16*ar.lc + 16.  this would avoid the addition at
+	// every iteration.
+	// However we need to keep the synchronization point. A template
+	// M;;MB does not exist and thus we can keep the addition at no
+	// extra cycle cost (use a nop slot anyway). It also simplifies the
+	// (unlikely)  error recovery code
+	//
+
+2:	EX(.Lexit3, st8 [buf]=r0,16 )
+	;;				// needed to get len correct when error
+	st8 [buf2]=r0,16
+	adds len=-16,len
+	br.cloop.dptk 2b
+	;;
+	mov ar.lc=saved_lc
+	//
+	// tail correction based on len only
+	//
+	// We alternate the use of len3,len2 to allow parallelism and correct
+	// error handling. We also reuse p6/p7 to return correct value.
+	// The addition of len2/len3 does not cost anything more compared to
+	// the regular memset as we had empty slots.
+	//
+.dotail:
+	mov len2=len			// for parallelization of error handling
+	mov len3=len
+	tbit.nz p6,p0=len,3
+	;;
+	EX( .Lexit2, (p6) st8 [buf]=r0,8 )	// at least 8 bytes
+(p6)	adds len3=-8,len2
+	tbit.nz p7,p6=len,2
+	;;
+	EX( .Lexit2, (p7) st4 [buf]=r0,4 )	// at least 4 bytes
+(p7)	adds len2=-4,len3
+	tbit.nz p6,p7=len,1
+	;;
+	EX( .Lexit2, (p6) st2 [buf]=r0,2 )	// at least 2 bytes
+(p6)	adds len3=-2,len2
+	tbit.nz p7,p6=len,0
+	;;
+	EX( .Lexit2, (p7) st1 [buf]=r0 )	// only 1 byte left
+	mov ret0=r0				// success
+	br.ret.sptk.many rp			// end of most likely path
+
+	//
+	// Outlined error handling code
+	//
+
+	//
+	// .Lexit3: comes from core loop, need restore pr/lc
+	//	    len contains bytes left
+	//
+	//
+	// .Lexit2:
+	//	if p6 -> coming from st8 or st2 : len2 contains what's left
+	//	if p7 -> coming from st4 or st1 : len3 contains what's left
+	// We must restore lc/pr even though might not have been used.
+.Lexit2:
+	.pred.rel "mutex", p6, p7
+(p6)	mov len=len2
+(p7)	mov len=len3
+	;;
+	//
+	// .Lexit4: comes from head, need not restore pr/lc
+	//	    len contains bytes left
+	//
+.Lexit3:
+	mov ret0=len
+	mov ar.lc=saved_lc
+	br.ret.sptk.many rp
+END(__do_clear_user)
diff --git a/xen/arch/x86/usercopy.c b/xen/arch/x86/usercopy.c
index d88e635..47dadae 100644
--- a/xen/arch/x86/usercopy.c
+++ b/xen/arch/x86/usercopy.c
@@ -110,6 +110,42 @@ copy_to_user(void __user *to, const void *from, unsigned n)
     return n;
 }
 
+#define __do_clear_user(addr,size)					\
+do {									\
+	long __d0;							\
+	__asm__ __volatile__(						\
+		"0:	rep; stosl\n"					\
+		"	movl %2,%0\n"					\
+		"1:	rep; stosb\n"					\
+		"2:\n"							\
+		".section .fixup,\"ax\"\n"				\
+		"3:	lea 0(%2,%0,4),%0\n"				\
+		"	jmp 2b\n"					\
+		".previous\n"						\
+		_ASM_EXTABLE(0b,3b)					\
+		_ASM_EXTABLE(1b,2b)					\
+		: "=&c"(size), "=&D" (__d0)				\
+		: "r"(size & 3), "0"(size / 4), "1"((long)addr), "a"(0));	\
+} while (0)
+
+/**
+ * clear_user: - Zero a block of memory in user space.
+ * @to:   Destination address, in user space.
+ * @n:    Number of bytes to zero.
+ *
+ * Zero a block of memory in user space.
+ *
+ * Returns number of bytes that could not be cleared.
+ * On success, this will be zero.
+ */
+unsigned long
+clear_user(void __user *to, unsigned n)
+{
+	if ( access_ok(to, n) )
+		__do_clear_user(to, n);
+	return n;
+}
+
 /**
  * copy_from_user: - Copy a block of data from user space.
  * @to:   Destination address, in kernel space.
diff --git a/xen/include/asm-ia64/uaccess.h b/xen/include/asm-ia64/uaccess.h
index 32ef415..2ececb1 100644
--- a/xen/include/asm-ia64/uaccess.h
+++ b/xen/include/asm-ia64/uaccess.h
@@ -236,6 +236,18 @@ __copy_from_user (void *to, const void __user *from, unsigned long count)
 	__cu_len;									\
 })
 
+extern unsigned long __do_clear_user (void __user * to, unsigned long count);
+
+#define clear_user(to, n)					\
+({								\
+	void __user *__cu_to = (to);							\
+	long __cu_len = (n);								\
+											\
+	if (__access_ok(__cu_to))							\
+		__cu_len = __do_clear_user(__cu_to, __cu_len);	\
+	__cu_len;						\
+})
+
 #define copy_from_user(to, from, n)							\
 ({											\
 	void *__cu_to = (to);								\
diff --git a/xen/include/asm-x86/uaccess.h b/xen/include/asm-x86/uaccess.h
index e3e541b..d6f4458 100644
--- a/xen/include/asm-x86/uaccess.h
+++ b/xen/include/asm-x86/uaccess.h
@@ -16,6 +16,7 @@
 #endif
 
 unsigned long copy_to_user(void *to, const void *from, unsigned len);
+unsigned long clear_user(void *to, unsigned len);
 unsigned long copy_from_user(void *to, const void *from, unsigned len);
 /* Handles exceptions in both to and from, but doesn't do access_ok */
 unsigned long __copy_to_user_ll(void *to, const void *from, unsigned n);
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 13:14:30 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 13: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.xensource.com>)
	id 1RZ0HQ-0002Ux-C9; Fri, 09 Dec 2011 13:14:24 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RZ0HO-0002QG-3g
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 13:14:22 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1323436410!4910460!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDQ0MTg=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9910 invoked from network); 9 Dec 2011 13:13:32 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 13:13:32 -0000
X-IronPort-AV: E=Sophos;i="4.71,325,1320642000"; d="scan'208";a="19808903"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 08:13:29 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 08:13:29 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pB9DCpE2008248;
	Fri, 9 Dec 2011 05:13:18 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 9 Dec 2011 13:13:19 +0000
Message-ID: <1323436408-16335-16-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1112091208420.3517@kaball-desktop>
References: <alpine.DEB.2.00.1112091208420.3517@kaball-desktop>
MIME-Version: 1.0
Cc: keir.xen@gmail.com, Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, JBeulich@suse.com,
	Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v2 16/25] arm: irq
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

A simple do_IRQ and request_irq implementation for ARM.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
---
 xen/arch/arm/irq.c          |  179 +++++++++++++++++++++++++++++++++++++++++++
 xen/include/asm-arm/irq.h   |   30 +++++++
 xen/include/asm-arm/setup.h |    2 +
 xen/include/xen/irq.h       |   13 +++
 4 files changed, 224 insertions(+), 0 deletions(-)
 create mode 100644 xen/arch/arm/irq.c
 create mode 100644 xen/include/asm-arm/irq.h

diff --git a/xen/arch/arm/irq.c b/xen/arch/arm/irq.c
new file mode 100644
index 0000000..5663762
--- /dev/null
+++ b/xen/arch/arm/irq.c
@@ -0,0 +1,179 @@
+/*
+ * xen/arch/arm/irq.c
+ *
+ * ARM Interrupt support
+ *
+ * Ian Campbell <ian.campbell@citrix.com>
+ * Copyright (c) 2011 Citrix Systems.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include <xen/config.h>
+#include <xen/lib.h>
+#include <xen/spinlock.h>
+#include <xen/irq.h>
+#include <xen/init.h>
+#include <xen/errno.h>
+#include <xen/sched.h>
+
+#include "gic.h"
+
+static void enable_none(struct irq_desc *irq) { }
+static unsigned int startup_none(struct irq_desc *irq) { return 0; }
+static void disable_none(struct irq_desc *irq) { }
+static void ack_none(struct irq_desc *irq)
+{
+    printk("unexpected IRQ trap at irq %02x\n", irq->irq);
+}
+
+#define shutdown_none   disable_none
+#define end_none        enable_none
+
+hw_irq_controller no_irq_type = {
+    .typename = "none",
+    .startup = startup_none,
+    .shutdown = shutdown_none,
+    .enable = enable_none,
+    .disable = disable_none,
+    .ack = ack_none,
+    .end = end_none
+};
+
+int __init arch_init_one_irq_desc(struct irq_desc *desc)
+{
+	return 0;
+}
+
+
+static int __init init_irq_data(void)
+{
+    int irq;
+
+    for (irq = 0; irq < NR_IRQS; irq++) {
+        struct irq_desc *desc = irq_to_desc(irq);
+        init_one_irq_desc(desc);
+        desc->irq = irq;
+        desc->action  = NULL;
+    }
+    return 0;
+}
+
+void __init init_IRQ(void)
+{
+    BUG_ON(init_irq_data() < 0);
+}
+
+int __init request_irq(unsigned int irq,
+        void (*handler)(int, void *, struct cpu_user_regs *),
+        unsigned long irqflags, const char * devname, void *dev_id)
+{
+    struct irqaction *action;
+    int retval;
+
+    /*
+     * Sanity-check: shared interrupts must pass in a real dev-ID,
+     * otherwise we'll have trouble later trying to figure out
+     * which interrupt is which (messes up the interrupt freeing
+     * logic etc).
+     */
+    if (irq >= nr_irqs)
+        return -EINVAL;
+    if (!handler)
+        return -EINVAL;
+
+    action = xmalloc(struct irqaction);
+    if (!action)
+        return -ENOMEM;
+
+    action->handler = handler;
+    action->name = devname;
+    action->dev_id = dev_id;
+    action->free_on_release = 1;
+
+    retval = setup_irq(irq, action);
+    if (retval)
+        xfree(action);
+
+    return retval;
+}
+
+/* Dispatch an interrupt */
+void do_IRQ(struct cpu_user_regs *regs, unsigned int irq, int is_fiq)
+{
+    struct irq_desc *desc = irq_to_desc(irq);
+    struct irqaction *action = desc->action;
+
+    /* TODO: perfc_incr(irqs); */
+
+    /* TODO: this_cpu(irq_count)++; */
+
+    irq_enter();
+
+    spin_lock(&desc->lock);
+    desc->handler->ack(desc);
+
+    if ( action == NULL )
+    {
+        printk("Unknown %s %#3.3x\n",
+               is_fiq ? "FIQ" : "IRQ", irq);
+        goto out;
+    }
+
+    if ( desc->status & IRQ_GUEST )
+    {
+        struct domain *d = action->dev_id;
+
+        desc->handler->end(desc);
+
+        desc->status |= IRQ_INPROGRESS;
+
+        /* XXX: inject irq into the guest */
+        goto out_no_end;
+    }
+
+    desc->status |= IRQ_PENDING;
+
+    /*
+     * Since we set PENDING, if another processor is handling a different
+     * instance of this same irq, the other processor will take care of it.
+     */
+    if ( desc->status & (IRQ_DISABLED | IRQ_INPROGRESS) )
+        goto out;
+
+    desc->status |= IRQ_INPROGRESS;
+
+    action = desc->action;
+    while ( desc->status & IRQ_PENDING )
+    {
+        desc->status &= ~IRQ_PENDING;
+        spin_unlock_irq(&desc->lock);
+        action->handler(irq, action->dev_id, regs);
+        spin_lock_irq(&desc->lock);
+    }
+
+    desc->status &= ~IRQ_INPROGRESS;
+
+out:
+    desc->handler->end(desc);
+out_no_end:
+    spin_unlock(&desc->lock);
+    irq_exit();
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/irq.h b/xen/include/asm-arm/irq.h
new file mode 100644
index 0000000..8e65a2e
--- /dev/null
+++ b/xen/include/asm-arm/irq.h
@@ -0,0 +1,30 @@
+#ifndef _ASM_HW_IRQ_H
+#define _ASM_HW_IRQ_H
+
+#include <xen/config.h>
+
+#define NR_VECTORS 256 /* XXX */
+
+typedef struct {
+    DECLARE_BITMAP(_bits,NR_VECTORS);
+} vmask_t;
+
+struct arch_pirq
+{
+};
+
+struct irq_cfg {
+#define arch_irq_desc irq_cfg
+};
+
+void do_IRQ(struct cpu_user_regs *regs, unsigned int irq, int is_fiq);
+
+#endif /* _ASM_HW_IRQ_H */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/setup.h b/xen/include/asm-arm/setup.h
index 1dc3f97..2041f06 100644
--- a/xen/include/asm-arm/setup.h
+++ b/xen/include/asm-arm/setup.h
@@ -7,6 +7,8 @@ void arch_get_xen_caps(xen_capabilities_info_t *info);
 
 int construct_dom0(struct domain *d);
 
+void init_IRQ(void);
+
 #endif
 /*
  * Local variables:
diff --git a/xen/include/xen/irq.h b/xen/include/xen/irq.h
index a2a90e1..5a711cc 100644
--- a/xen/include/xen/irq.h
+++ b/xen/include/xen/irq.h
@@ -107,6 +107,19 @@ extern irq_desc_t irq_desc[NR_VECTORS];
 
 #define request_irq(irq, handler, irqflags, devname, devid) \
     request_irq_vector(irq_to_vector(irq), handler, irqflags, devname, devid)
+
+#elif defined(__arm__)
+
+#define NR_IRQS		1024
+#define nr_irqs NR_IRQS
+extern irq_desc_t irq_desc[NR_IRQS];
+
+extern int setup_irq(unsigned int irq, struct irqaction *);
+extern void release_irq(unsigned int irq);
+extern int request_irq(unsigned int irq,
+               void (*handler)(int, void *, struct cpu_user_regs *),
+               unsigned long irqflags, const char * devname, void *dev_id);
+
 #else
 extern int setup_irq(unsigned int irq, struct irqaction *);
 extern void release_irq(unsigned int irq);
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 13:14:30 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 13: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.xensource.com>)
	id 1RZ0HQ-0002Ux-C9; Fri, 09 Dec 2011 13:14:24 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RZ0HO-0002QG-3g
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 13:14:22 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1323436410!4910460!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDQ0MTg=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9910 invoked from network); 9 Dec 2011 13:13:32 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 13:13:32 -0000
X-IronPort-AV: E=Sophos;i="4.71,325,1320642000"; d="scan'208";a="19808903"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 08:13:29 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 08:13:29 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pB9DCpE2008248;
	Fri, 9 Dec 2011 05:13:18 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 9 Dec 2011 13:13:19 +0000
Message-ID: <1323436408-16335-16-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1112091208420.3517@kaball-desktop>
References: <alpine.DEB.2.00.1112091208420.3517@kaball-desktop>
MIME-Version: 1.0
Cc: keir.xen@gmail.com, Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, JBeulich@suse.com,
	Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v2 16/25] arm: irq
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

A simple do_IRQ and request_irq implementation for ARM.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
---
 xen/arch/arm/irq.c          |  179 +++++++++++++++++++++++++++++++++++++++++++
 xen/include/asm-arm/irq.h   |   30 +++++++
 xen/include/asm-arm/setup.h |    2 +
 xen/include/xen/irq.h       |   13 +++
 4 files changed, 224 insertions(+), 0 deletions(-)
 create mode 100644 xen/arch/arm/irq.c
 create mode 100644 xen/include/asm-arm/irq.h

diff --git a/xen/arch/arm/irq.c b/xen/arch/arm/irq.c
new file mode 100644
index 0000000..5663762
--- /dev/null
+++ b/xen/arch/arm/irq.c
@@ -0,0 +1,179 @@
+/*
+ * xen/arch/arm/irq.c
+ *
+ * ARM Interrupt support
+ *
+ * Ian Campbell <ian.campbell@citrix.com>
+ * Copyright (c) 2011 Citrix Systems.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include <xen/config.h>
+#include <xen/lib.h>
+#include <xen/spinlock.h>
+#include <xen/irq.h>
+#include <xen/init.h>
+#include <xen/errno.h>
+#include <xen/sched.h>
+
+#include "gic.h"
+
+static void enable_none(struct irq_desc *irq) { }
+static unsigned int startup_none(struct irq_desc *irq) { return 0; }
+static void disable_none(struct irq_desc *irq) { }
+static void ack_none(struct irq_desc *irq)
+{
+    printk("unexpected IRQ trap at irq %02x\n", irq->irq);
+}
+
+#define shutdown_none   disable_none
+#define end_none        enable_none
+
+hw_irq_controller no_irq_type = {
+    .typename = "none",
+    .startup = startup_none,
+    .shutdown = shutdown_none,
+    .enable = enable_none,
+    .disable = disable_none,
+    .ack = ack_none,
+    .end = end_none
+};
+
+int __init arch_init_one_irq_desc(struct irq_desc *desc)
+{
+	return 0;
+}
+
+
+static int __init init_irq_data(void)
+{
+    int irq;
+
+    for (irq = 0; irq < NR_IRQS; irq++) {
+        struct irq_desc *desc = irq_to_desc(irq);
+        init_one_irq_desc(desc);
+        desc->irq = irq;
+        desc->action  = NULL;
+    }
+    return 0;
+}
+
+void __init init_IRQ(void)
+{
+    BUG_ON(init_irq_data() < 0);
+}
+
+int __init request_irq(unsigned int irq,
+        void (*handler)(int, void *, struct cpu_user_regs *),
+        unsigned long irqflags, const char * devname, void *dev_id)
+{
+    struct irqaction *action;
+    int retval;
+
+    /*
+     * Sanity-check: shared interrupts must pass in a real dev-ID,
+     * otherwise we'll have trouble later trying to figure out
+     * which interrupt is which (messes up the interrupt freeing
+     * logic etc).
+     */
+    if (irq >= nr_irqs)
+        return -EINVAL;
+    if (!handler)
+        return -EINVAL;
+
+    action = xmalloc(struct irqaction);
+    if (!action)
+        return -ENOMEM;
+
+    action->handler = handler;
+    action->name = devname;
+    action->dev_id = dev_id;
+    action->free_on_release = 1;
+
+    retval = setup_irq(irq, action);
+    if (retval)
+        xfree(action);
+
+    return retval;
+}
+
+/* Dispatch an interrupt */
+void do_IRQ(struct cpu_user_regs *regs, unsigned int irq, int is_fiq)
+{
+    struct irq_desc *desc = irq_to_desc(irq);
+    struct irqaction *action = desc->action;
+
+    /* TODO: perfc_incr(irqs); */
+
+    /* TODO: this_cpu(irq_count)++; */
+
+    irq_enter();
+
+    spin_lock(&desc->lock);
+    desc->handler->ack(desc);
+
+    if ( action == NULL )
+    {
+        printk("Unknown %s %#3.3x\n",
+               is_fiq ? "FIQ" : "IRQ", irq);
+        goto out;
+    }
+
+    if ( desc->status & IRQ_GUEST )
+    {
+        struct domain *d = action->dev_id;
+
+        desc->handler->end(desc);
+
+        desc->status |= IRQ_INPROGRESS;
+
+        /* XXX: inject irq into the guest */
+        goto out_no_end;
+    }
+
+    desc->status |= IRQ_PENDING;
+
+    /*
+     * Since we set PENDING, if another processor is handling a different
+     * instance of this same irq, the other processor will take care of it.
+     */
+    if ( desc->status & (IRQ_DISABLED | IRQ_INPROGRESS) )
+        goto out;
+
+    desc->status |= IRQ_INPROGRESS;
+
+    action = desc->action;
+    while ( desc->status & IRQ_PENDING )
+    {
+        desc->status &= ~IRQ_PENDING;
+        spin_unlock_irq(&desc->lock);
+        action->handler(irq, action->dev_id, regs);
+        spin_lock_irq(&desc->lock);
+    }
+
+    desc->status &= ~IRQ_INPROGRESS;
+
+out:
+    desc->handler->end(desc);
+out_no_end:
+    spin_unlock(&desc->lock);
+    irq_exit();
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/irq.h b/xen/include/asm-arm/irq.h
new file mode 100644
index 0000000..8e65a2e
--- /dev/null
+++ b/xen/include/asm-arm/irq.h
@@ -0,0 +1,30 @@
+#ifndef _ASM_HW_IRQ_H
+#define _ASM_HW_IRQ_H
+
+#include <xen/config.h>
+
+#define NR_VECTORS 256 /* XXX */
+
+typedef struct {
+    DECLARE_BITMAP(_bits,NR_VECTORS);
+} vmask_t;
+
+struct arch_pirq
+{
+};
+
+struct irq_cfg {
+#define arch_irq_desc irq_cfg
+};
+
+void do_IRQ(struct cpu_user_regs *regs, unsigned int irq, int is_fiq);
+
+#endif /* _ASM_HW_IRQ_H */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/setup.h b/xen/include/asm-arm/setup.h
index 1dc3f97..2041f06 100644
--- a/xen/include/asm-arm/setup.h
+++ b/xen/include/asm-arm/setup.h
@@ -7,6 +7,8 @@ void arch_get_xen_caps(xen_capabilities_info_t *info);
 
 int construct_dom0(struct domain *d);
 
+void init_IRQ(void);
+
 #endif
 /*
  * Local variables:
diff --git a/xen/include/xen/irq.h b/xen/include/xen/irq.h
index a2a90e1..5a711cc 100644
--- a/xen/include/xen/irq.h
+++ b/xen/include/xen/irq.h
@@ -107,6 +107,19 @@ extern irq_desc_t irq_desc[NR_VECTORS];
 
 #define request_irq(irq, handler, irqflags, devname, devid) \
     request_irq_vector(irq_to_vector(irq), handler, irqflags, devname, devid)
+
+#elif defined(__arm__)
+
+#define NR_IRQS		1024
+#define nr_irqs NR_IRQS
+extern irq_desc_t irq_desc[NR_IRQS];
+
+extern int setup_irq(unsigned int irq, struct irqaction *);
+extern void release_irq(unsigned int irq);
+extern int request_irq(unsigned int irq,
+               void (*handler)(int, void *, struct cpu_user_regs *),
+               unsigned long irqflags, const char * devname, void *dev_id);
+
 #else
 extern int setup_irq(unsigned int irq, struct irqaction *);
 extern void release_irq(unsigned int irq);
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 13:14:30 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 13: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.xensource.com>)
	id 1RZ0Gy-0002GV-Tq; Fri, 09 Dec 2011 13:13:56 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RZ0Gx-0002G4-IK
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 13:13:55 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1323436384!4910711!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMTkxNzY=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29570 invoked from network); 9 Dec 2011 13:13:06 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 13:13:06 -0000
X-IronPort-AV: E=Sophos;i="4.71,325,1320642000"; d="scan'208";a="173546215"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 08:13:04 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 08:13:04 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pB9DCpDl008248;
	Fri, 9 Dec 2011 05:12:52 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 9 Dec 2011 13:13:04 +0000
Message-ID: <1323436408-16335-1-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1112091208420.3517@kaball-desktop>
References: <alpine.DEB.2.00.1112091208420.3517@kaball-desktop>
MIME-Version: 1.0
Cc: keir.xen@gmail.com, Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, JBeulich@suse.com,
	Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v2 01/25] Move cpufreq option parsing to
	cpufreq.c
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
---
 xen/common/domain.c           |   35 ++---------------------------------
 xen/drivers/cpufreq/cpufreq.c |   31 +++++++++++++++++++++++++++++++
 xen/include/xen/domain.h      |    2 ++
 3 files changed, 35 insertions(+), 33 deletions(-)

diff --git a/xen/common/domain.c b/xen/common/domain.c
index 9e355c8..6505572 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -31,8 +31,8 @@
 #include <xen/grant_table.h>
 #include <xen/xenoprof.h>
 #include <xen/irq.h>
-#include <acpi/cpufreq/cpufreq.h>
 #include <asm/debugger.h>
+#include <asm/processor.h>
 #include <public/sched.h>
 #include <public/sysctl.h>
 #include <public/vcpu.h>
@@ -45,40 +45,9 @@
 unsigned int xen_processor_pmbits = XEN_PROCESSOR_PM_PX;
 
 /* opt_dom0_vcpus_pin: If true, dom0 VCPUs are pinned. */
-static bool_t opt_dom0_vcpus_pin;
+bool_t opt_dom0_vcpus_pin;
 boolean_param("dom0_vcpus_pin", opt_dom0_vcpus_pin);
 
-/* set xen as default cpufreq */
-enum cpufreq_controller cpufreq_controller = FREQCTL_xen;
-
-static void __init setup_cpufreq_option(char *str)
-{
-    char *arg;
-
-    if ( !strcmp(str, "dom0-kernel") )
-    {
-        xen_processor_pmbits &= ~XEN_PROCESSOR_PM_PX;
-        cpufreq_controller = FREQCTL_dom0_kernel;
-        opt_dom0_vcpus_pin = 1;
-        return;
-    }
-
-    if ( !strcmp(str, "none") )
-    {
-        xen_processor_pmbits &= ~XEN_PROCESSOR_PM_PX;
-        cpufreq_controller = FREQCTL_none;
-        return;
-    }
-
-    if ( (arg = strpbrk(str, ",:")) != NULL )
-        *arg++ = '\0';
-
-    if ( !strcmp(str, "xen") )
-        if ( arg && *arg )
-            cpufreq_cmdline_parse(arg);
-}
-custom_param("cpufreq", setup_cpufreq_option);
-
 /* Protect updates/reads (resp.) of domain_list and domain_hash. */
 DEFINE_SPINLOCK(domlist_update_lock);
 DEFINE_RCU_READ_LOCK(domlist_read_lock);
diff --git a/xen/drivers/cpufreq/cpufreq.c b/xen/drivers/cpufreq/cpufreq.c
index f49ea1c..34ea2a9 100644
--- a/xen/drivers/cpufreq/cpufreq.c
+++ b/xen/drivers/cpufreq/cpufreq.c
@@ -61,6 +61,37 @@ static LIST_HEAD_READ_MOSTLY(cpufreq_dom_list_head);
 struct cpufreq_governor *__read_mostly cpufreq_opt_governor;
 LIST_HEAD_READ_MOSTLY(cpufreq_governor_list);
 
+/* set xen as default cpufreq */
+enum cpufreq_controller cpufreq_controller = FREQCTL_xen;
+
+static void __init setup_cpufreq_option(char *str)
+{
+    char *arg;
+
+    if ( !strcmp(str, "dom0-kernel") )
+    {
+        xen_processor_pmbits &= ~XEN_PROCESSOR_PM_PX;
+        cpufreq_controller = FREQCTL_dom0_kernel;
+        opt_dom0_vcpus_pin = 1;
+        return;
+    }
+
+    if ( !strcmp(str, "none") )
+    {
+        xen_processor_pmbits &= ~XEN_PROCESSOR_PM_PX;
+        cpufreq_controller = FREQCTL_none;
+        return;
+    }
+
+    if ( (arg = strpbrk(str, ",:")) != NULL )
+        *arg++ = '\0';
+
+    if ( !strcmp(str, "xen") )
+        if ( arg && *arg )
+            cpufreq_cmdline_parse(arg);
+}
+custom_param("cpufreq", setup_cpufreq_option);
+
 bool_t __read_mostly cpufreq_verbose;
 
 struct cpufreq_governor *__find_governor(const char *governor)
diff --git a/xen/include/xen/domain.h b/xen/include/xen/domain.h
index 765e132..de3e8db 100644
--- a/xen/include/xen/domain.h
+++ b/xen/include/xen/domain.h
@@ -85,4 +85,6 @@ int continue_hypercall_on_cpu(
 
 extern unsigned int xen_processor_pmbits;
 
+extern bool_t opt_dom0_vcpus_pin;
+
 #endif /* __XEN_DOMAIN_H__ */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 13:14:30 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 13: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.xensource.com>)
	id 1RZ0Gy-0002GV-Tq; Fri, 09 Dec 2011 13:13:56 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RZ0Gx-0002G4-IK
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 13:13:55 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1323436384!4910711!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMTkxNzY=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29570 invoked from network); 9 Dec 2011 13:13:06 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 13:13:06 -0000
X-IronPort-AV: E=Sophos;i="4.71,325,1320642000"; d="scan'208";a="173546215"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 08:13:04 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 08:13:04 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pB9DCpDl008248;
	Fri, 9 Dec 2011 05:12:52 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 9 Dec 2011 13:13:04 +0000
Message-ID: <1323436408-16335-1-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1112091208420.3517@kaball-desktop>
References: <alpine.DEB.2.00.1112091208420.3517@kaball-desktop>
MIME-Version: 1.0
Cc: keir.xen@gmail.com, Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, JBeulich@suse.com,
	Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v2 01/25] Move cpufreq option parsing to
	cpufreq.c
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
---
 xen/common/domain.c           |   35 ++---------------------------------
 xen/drivers/cpufreq/cpufreq.c |   31 +++++++++++++++++++++++++++++++
 xen/include/xen/domain.h      |    2 ++
 3 files changed, 35 insertions(+), 33 deletions(-)

diff --git a/xen/common/domain.c b/xen/common/domain.c
index 9e355c8..6505572 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -31,8 +31,8 @@
 #include <xen/grant_table.h>
 #include <xen/xenoprof.h>
 #include <xen/irq.h>
-#include <acpi/cpufreq/cpufreq.h>
 #include <asm/debugger.h>
+#include <asm/processor.h>
 #include <public/sched.h>
 #include <public/sysctl.h>
 #include <public/vcpu.h>
@@ -45,40 +45,9 @@
 unsigned int xen_processor_pmbits = XEN_PROCESSOR_PM_PX;
 
 /* opt_dom0_vcpus_pin: If true, dom0 VCPUs are pinned. */
-static bool_t opt_dom0_vcpus_pin;
+bool_t opt_dom0_vcpus_pin;
 boolean_param("dom0_vcpus_pin", opt_dom0_vcpus_pin);
 
-/* set xen as default cpufreq */
-enum cpufreq_controller cpufreq_controller = FREQCTL_xen;
-
-static void __init setup_cpufreq_option(char *str)
-{
-    char *arg;
-
-    if ( !strcmp(str, "dom0-kernel") )
-    {
-        xen_processor_pmbits &= ~XEN_PROCESSOR_PM_PX;
-        cpufreq_controller = FREQCTL_dom0_kernel;
-        opt_dom0_vcpus_pin = 1;
-        return;
-    }
-
-    if ( !strcmp(str, "none") )
-    {
-        xen_processor_pmbits &= ~XEN_PROCESSOR_PM_PX;
-        cpufreq_controller = FREQCTL_none;
-        return;
-    }
-
-    if ( (arg = strpbrk(str, ",:")) != NULL )
-        *arg++ = '\0';
-
-    if ( !strcmp(str, "xen") )
-        if ( arg && *arg )
-            cpufreq_cmdline_parse(arg);
-}
-custom_param("cpufreq", setup_cpufreq_option);
-
 /* Protect updates/reads (resp.) of domain_list and domain_hash. */
 DEFINE_SPINLOCK(domlist_update_lock);
 DEFINE_RCU_READ_LOCK(domlist_read_lock);
diff --git a/xen/drivers/cpufreq/cpufreq.c b/xen/drivers/cpufreq/cpufreq.c
index f49ea1c..34ea2a9 100644
--- a/xen/drivers/cpufreq/cpufreq.c
+++ b/xen/drivers/cpufreq/cpufreq.c
@@ -61,6 +61,37 @@ static LIST_HEAD_READ_MOSTLY(cpufreq_dom_list_head);
 struct cpufreq_governor *__read_mostly cpufreq_opt_governor;
 LIST_HEAD_READ_MOSTLY(cpufreq_governor_list);
 
+/* set xen as default cpufreq */
+enum cpufreq_controller cpufreq_controller = FREQCTL_xen;
+
+static void __init setup_cpufreq_option(char *str)
+{
+    char *arg;
+
+    if ( !strcmp(str, "dom0-kernel") )
+    {
+        xen_processor_pmbits &= ~XEN_PROCESSOR_PM_PX;
+        cpufreq_controller = FREQCTL_dom0_kernel;
+        opt_dom0_vcpus_pin = 1;
+        return;
+    }
+
+    if ( !strcmp(str, "none") )
+    {
+        xen_processor_pmbits &= ~XEN_PROCESSOR_PM_PX;
+        cpufreq_controller = FREQCTL_none;
+        return;
+    }
+
+    if ( (arg = strpbrk(str, ",:")) != NULL )
+        *arg++ = '\0';
+
+    if ( !strcmp(str, "xen") )
+        if ( arg && *arg )
+            cpufreq_cmdline_parse(arg);
+}
+custom_param("cpufreq", setup_cpufreq_option);
+
 bool_t __read_mostly cpufreq_verbose;
 
 struct cpufreq_governor *__find_governor(const char *governor)
diff --git a/xen/include/xen/domain.h b/xen/include/xen/domain.h
index 765e132..de3e8db 100644
--- a/xen/include/xen/domain.h
+++ b/xen/include/xen/domain.h
@@ -85,4 +85,6 @@ int continue_hypercall_on_cpu(
 
 extern unsigned int xen_processor_pmbits;
 
+extern bool_t opt_dom0_vcpus_pin;
+
 #endif /* __XEN_DOMAIN_H__ */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 13:14:30 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 13: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.xensource.com>)
	id 1RZ0HC-0002LP-H8; Fri, 09 Dec 2011 13:14:10 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RZ0HB-0002He-3z
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 13:14:09 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1323436384!4910711!5
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMTkxNzY=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30680 invoked from network); 9 Dec 2011 13:13:19 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 13:13:19 -0000
X-IronPort-AV: E=Sophos;i="4.71,325,1320642000"; d="scan'208";a="173546258"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 08:13:17 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 08:13:17 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pB9DCpDq008248;
	Fri, 9 Dec 2011 05:13:00 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 9 Dec 2011 13:13:09 +0000
Message-ID: <1323436408-16335-6-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1112091208420.3517@kaball-desktop>
References: <alpine.DEB.2.00.1112091208420.3517@kaball-desktop>
MIME-Version: 1.0
Cc: keir.xen@gmail.com, Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, JBeulich@suse.com,
	Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v2 06/25] libelf-loader: introduce elf_load_image
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Implement a new function, called elf_load_image, to perform the actually
copy of the elf image and clearing the padding.
The function is implemented as memcpy and memset when the library is
built as part of the tools, but it is implemented as copy_to_user and
clear_user when built as part of Xen, so that it can be safely called
with an HVM style dom0.


Changes in v2:

- remove CONFIG_KERNEL_NO_RELOC.


Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
---
 xen/common/libelf/libelf-loader.c |   17 +++++++++++++++--
 1 files changed, 15 insertions(+), 2 deletions(-)

diff --git a/xen/common/libelf/libelf-loader.c b/xen/common/libelf/libelf-loader.c
index 1ccf7d3..eec7e7b 100644
--- a/xen/common/libelf/libelf-loader.c
+++ b/xen/common/libelf/libelf-loader.c
@@ -107,11 +107,25 @@ void elf_set_log(struct elf_binary *elf, elf_log_callback *log_callback,
     elf->log_caller_data = log_caller_data;
     elf->verbose = verbose;
 }
+
+static void elf_load_image(void *dst, const void *src, uint64_t filesz, uint64_t memsz)
+{
+    memcpy(dst, src, filesz);
+    memset(dst + filesz, 0, memsz - filesz);
+}
 #else
+#include <asm/guest_access.h>
+
 void elf_set_verbose(struct elf_binary *elf)
 {
     elf->verbose = 1;
 }
+
+static void elf_load_image(void *dst, const void *src, uint64_t filesz, uint64_t memsz)
+{
+    copy_to_user(dst, src, filesz);
+    clear_user(dst + filesz, memsz - filesz);
+}
 #endif
 
 /* Calculate the required additional kernel space for the elf image */
@@ -256,8 +270,7 @@ void elf_load_binary(struct elf_binary *elf)
         dest = elf_get_ptr(elf, paddr);
         elf_msg(elf, "%s: phdr %" PRIu64 " at 0x%p -> 0x%p\n",
                 __func__, i, dest, dest + filesz);
-        memcpy(dest, elf->image + offset, filesz);
-        memset(dest + filesz, 0, memsz - filesz);
+        elf_load_image(dest, elf->image + offset, filesz, memsz);
     }
 
     elf_load_bsdsyms(elf);
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 13:14:30 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 13: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.xensource.com>)
	id 1RZ0HC-0002LP-H8; Fri, 09 Dec 2011 13:14:10 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RZ0HB-0002He-3z
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 13:14:09 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1323436384!4910711!5
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMTkxNzY=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30680 invoked from network); 9 Dec 2011 13:13:19 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 13:13:19 -0000
X-IronPort-AV: E=Sophos;i="4.71,325,1320642000"; d="scan'208";a="173546258"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 08:13:17 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 08:13:17 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pB9DCpDq008248;
	Fri, 9 Dec 2011 05:13:00 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 9 Dec 2011 13:13:09 +0000
Message-ID: <1323436408-16335-6-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1112091208420.3517@kaball-desktop>
References: <alpine.DEB.2.00.1112091208420.3517@kaball-desktop>
MIME-Version: 1.0
Cc: keir.xen@gmail.com, Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, JBeulich@suse.com,
	Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v2 06/25] libelf-loader: introduce elf_load_image
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Implement a new function, called elf_load_image, to perform the actually
copy of the elf image and clearing the padding.
The function is implemented as memcpy and memset when the library is
built as part of the tools, but it is implemented as copy_to_user and
clear_user when built as part of Xen, so that it can be safely called
with an HVM style dom0.


Changes in v2:

- remove CONFIG_KERNEL_NO_RELOC.


Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
---
 xen/common/libelf/libelf-loader.c |   17 +++++++++++++++--
 1 files changed, 15 insertions(+), 2 deletions(-)

diff --git a/xen/common/libelf/libelf-loader.c b/xen/common/libelf/libelf-loader.c
index 1ccf7d3..eec7e7b 100644
--- a/xen/common/libelf/libelf-loader.c
+++ b/xen/common/libelf/libelf-loader.c
@@ -107,11 +107,25 @@ void elf_set_log(struct elf_binary *elf, elf_log_callback *log_callback,
     elf->log_caller_data = log_caller_data;
     elf->verbose = verbose;
 }
+
+static void elf_load_image(void *dst, const void *src, uint64_t filesz, uint64_t memsz)
+{
+    memcpy(dst, src, filesz);
+    memset(dst + filesz, 0, memsz - filesz);
+}
 #else
+#include <asm/guest_access.h>
+
 void elf_set_verbose(struct elf_binary *elf)
 {
     elf->verbose = 1;
 }
+
+static void elf_load_image(void *dst, const void *src, uint64_t filesz, uint64_t memsz)
+{
+    copy_to_user(dst, src, filesz);
+    clear_user(dst + filesz, memsz - filesz);
+}
 #endif
 
 /* Calculate the required additional kernel space for the elf image */
@@ -256,8 +270,7 @@ void elf_load_binary(struct elf_binary *elf)
         dest = elf_get_ptr(elf, paddr);
         elf_msg(elf, "%s: phdr %" PRIu64 " at 0x%p -> 0x%p\n",
                 __func__, i, dest, dest + filesz);
-        memcpy(dest, elf->image + offset, filesz);
-        memset(dest + filesz, 0, memsz - filesz);
+        elf_load_image(dest, elf->image + offset, filesz, memsz);
     }
 
     elf_load_bsdsyms(elf);
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 13:14:30 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 13: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.xensource.com>)
	id 1RZ0HE-0002Mh-5W; Fri, 09 Dec 2011 13:14:12 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RZ0HC-0002I6-Gv
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 13:14:11 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1323436384!4910711!6
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMTkxNzY=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30724 invoked from network); 9 Dec 2011 13:13:19 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 13:13:19 -0000
X-IronPort-AV: E=Sophos;i="4.71,325,1320642000"; d="scan'208";a="173546260"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 08:13:18 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 08:13:17 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pB9DCpDt008248;
	Fri, 9 Dec 2011 05:13:05 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 9 Dec 2011 13:13:12 +0000
Message-ID: <1323436408-16335-9-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1112091208420.3517@kaball-desktop>
References: <alpine.DEB.2.00.1112091208420.3517@kaball-desktop>
MIME-Version: 1.0
Cc: keir.xen@gmail.com, Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, JBeulich@suse.com,
	Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v2 09/25] arm: header files
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

A simple implementation of everything under asm-arm and arch-arm.h; some
of these files are shamelessly taken from Linux.


Changes in v2:

- remove div64.


Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
---
 xen/include/asm-arm/atomic.h      |  212 +++++++++++++++++++++++++++++
 xen/include/asm-arm/bitops.h      |  195 +++++++++++++++++++++++++++
 xen/include/asm-arm/bug.h         |   15 ++
 xen/include/asm-arm/byteorder.h   |   16 +++
 xen/include/asm-arm/cache.h       |   20 +++
 xen/include/asm-arm/config.h      |  122 +++++++++++++++++
 xen/include/asm-arm/cpregs.h      |  207 ++++++++++++++++++++++++++++
 xen/include/asm-arm/current.h     |   60 ++++++++
 xen/include/asm-arm/debugger.h    |   15 ++
 xen/include/asm-arm/delay.h       |   15 ++
 xen/include/asm-arm/desc.h        |   12 ++
 xen/include/asm-arm/div64.h       |  235 ++++++++++++++++++++++++++++++++
 xen/include/asm-arm/elf.h         |   33 +++++
 xen/include/asm-arm/event.h       |   41 ++++++
 xen/include/asm-arm/flushtlb.h    |   31 +++++
 xen/include/asm-arm/grant_table.h |   35 +++++
 xen/include/asm-arm/hardirq.h     |   28 ++++
 xen/include/asm-arm/hypercall.h   |   24 ++++
 xen/include/asm-arm/init.h        |   12 ++
 xen/include/asm-arm/io.h          |   12 ++
 xen/include/asm-arm/iocap.h       |   20 +++
 xen/include/asm-arm/multicall.h   |   23 +++
 xen/include/asm-arm/nmi.h         |   15 ++
 xen/include/asm-arm/numa.h        |   21 +++
 xen/include/asm-arm/paging.h      |   13 ++
 xen/include/asm-arm/percpu.h      |   28 ++++
 xen/include/asm-arm/processor.h   |  269 +++++++++++++++++++++++++++++++++++++
 xen/include/asm-arm/regs.h        |   43 ++++++
 xen/include/asm-arm/setup.h       |   16 +++
 xen/include/asm-arm/smp.h         |   25 ++++
 xen/include/asm-arm/softirq.h     |   15 ++
 xen/include/asm-arm/spinlock.h    |  144 ++++++++++++++++++++
 xen/include/asm-arm/string.h      |   38 +++++
 xen/include/asm-arm/system.h      |  202 ++++++++++++++++++++++++++++
 xen/include/asm-arm/trace.h       |   12 ++
 xen/include/asm-arm/types.h       |   57 ++++++++
 xen/include/asm-arm/xenoprof.h    |   12 ++
 xen/include/public/arch-arm.h     |  125 +++++++++++++++++
 xen/include/public/xen.h          |    2 +
 39 files changed, 2420 insertions(+), 0 deletions(-)
 create mode 100644 xen/include/asm-arm/atomic.h
 create mode 100644 xen/include/asm-arm/bitops.h
 create mode 100644 xen/include/asm-arm/bug.h
 create mode 100644 xen/include/asm-arm/byteorder.h
 create mode 100644 xen/include/asm-arm/cache.h
 create mode 100644 xen/include/asm-arm/config.h
 create mode 100644 xen/include/asm-arm/cpregs.h
 create mode 100644 xen/include/asm-arm/current.h
 create mode 100644 xen/include/asm-arm/debugger.h
 create mode 100644 xen/include/asm-arm/delay.h
 create mode 100644 xen/include/asm-arm/desc.h
 create mode 100644 xen/include/asm-arm/div64.h
 create mode 100644 xen/include/asm-arm/elf.h
 create mode 100644 xen/include/asm-arm/event.h
 create mode 100644 xen/include/asm-arm/flushtlb.h
 create mode 100644 xen/include/asm-arm/grant_table.h
 create mode 100644 xen/include/asm-arm/hardirq.h
 create mode 100644 xen/include/asm-arm/hypercall.h
 create mode 100644 xen/include/asm-arm/init.h
 create mode 100644 xen/include/asm-arm/io.h
 create mode 100644 xen/include/asm-arm/iocap.h
 create mode 100644 xen/include/asm-arm/multicall.h
 create mode 100644 xen/include/asm-arm/nmi.h
 create mode 100644 xen/include/asm-arm/numa.h
 create mode 100644 xen/include/asm-arm/paging.h
 create mode 100644 xen/include/asm-arm/percpu.h
 create mode 100644 xen/include/asm-arm/processor.h
 create mode 100644 xen/include/asm-arm/regs.h
 create mode 100644 xen/include/asm-arm/setup.h
 create mode 100644 xen/include/asm-arm/smp.h
 create mode 100644 xen/include/asm-arm/softirq.h
 create mode 100644 xen/include/asm-arm/spinlock.h
 create mode 100644 xen/include/asm-arm/string.h
 create mode 100644 xen/include/asm-arm/system.h
 create mode 100644 xen/include/asm-arm/trace.h
 create mode 100644 xen/include/asm-arm/types.h
 create mode 100644 xen/include/asm-arm/xenoprof.h
 create mode 100644 xen/include/public/arch-arm.h

diff --git a/xen/include/asm-arm/atomic.h b/xen/include/asm-arm/atomic.h
new file mode 100644
index 0000000..2b9ce0e
--- /dev/null
+++ b/xen/include/asm-arm/atomic.h
@@ -0,0 +1,212 @@
+/*
+ *  arch/arm/include/asm/atomic.h
+ *
+ *  Copyright (C) 1996 Russell King.
+ *  Copyright (C) 2002 Deep Blue Solutions Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#ifndef __ARCH_ARM_ATOMIC__
+#define __ARCH_ARM_ATOMIC__
+
+#include <xen/config.h>
+#include <asm/system.h>
+
+#define build_atomic_read(name, size, type, reg)   \
+static inline type name(const volatile type *addr) \
+{                                                  \
+    type ret;                                      \
+    asm volatile("ldr" size " %0,%1"               \
+                 : reg (ret)                       \
+                 : "m" (*(volatile type *)addr));  \
+    return ret;                                    \
+}
+
+#define build_atomic_write(name, size, type, reg)      \
+static inline void name(volatile type *addr, type val) \
+{                                                      \
+    asm volatile("str" size " %1,%0"                   \
+                 : "=m" (*(volatile type *)addr)       \
+                 : reg (val));                         \
+}
+
+build_atomic_read(atomic_read8, "b", uint8_t, "=q")
+build_atomic_read(atomic_read16, "h", uint16_t, "=r")
+build_atomic_read(atomic_read32, "", uint32_t, "=r")
+//build_atomic_read(atomic_read64, "d", uint64_t, "=r")
+build_atomic_read(atomic_read_int, "", int, "=r")
+
+build_atomic_write(atomic_write8, "b", uint8_t, "q")
+build_atomic_write(atomic_write16, "h", uint16_t, "r")
+build_atomic_write(atomic_write32, "", uint32_t, "r")
+//build_atomic_write(atomic_write64, "d", uint64_t, "r")
+build_atomic_write(atomic_write_int, "", int, "r")
+
+/*
+ * NB. I've pushed the volatile qualifier into the operations. This allows
+ * fast accessors such as _atomic_read() and _atomic_set() which don't give
+ * the compiler a fit.
+ */
+typedef struct { int counter; } atomic_t;
+
+#define ATOMIC_INIT(i) { (i) }
+
+/*
+ * On ARM, ordinary assignment (str instruction) doesn't clear the local
+ * strex/ldrex monitor on some implementations. The reason we can use it for
+ * atomic_set() is the clrex or dummy strex done on every exception return.
+ */
+#define _atomic_read(v) ((v).counter)
+#define atomic_read(v)  (*(volatile int *)&(v)->counter)
+
+#define _atomic_set(v,i) (((v).counter) = (i))
+#define atomic_set(v,i) (((v)->counter) = (i))
+
+/*
+ * ARMv6 UP and SMP safe atomic ops.  We use load exclusive and
+ * store exclusive to ensure that these are atomic.  We may loop
+ * to ensure that the update happens.
+ */
+static inline void atomic_add(int i, atomic_t *v)
+{
+        unsigned long tmp;
+        int result;
+
+        __asm__ __volatile__("@ atomic_add\n"
+"1:     ldrex   %0, [%3]\n"
+"       add     %0, %0, %4\n"
+"       strex   %1, %0, [%3]\n"
+"       teq     %1, #0\n"
+"       bne     1b"
+        : "=&r" (result), "=&r" (tmp), "+Qo" (v->counter)
+        : "r" (&v->counter), "Ir" (i)
+        : "cc");
+}
+
+static inline int atomic_add_return(int i, atomic_t *v)
+{
+        unsigned long tmp;
+        int result;
+
+        smp_mb();
+
+        __asm__ __volatile__("@ atomic_add_return\n"
+"1:     ldrex   %0, [%3]\n"
+"       add     %0, %0, %4\n"
+"       strex   %1, %0, [%3]\n"
+"       teq     %1, #0\n"
+"       bne     1b"
+        : "=&r" (result), "=&r" (tmp), "+Qo" (v->counter)
+        : "r" (&v->counter), "Ir" (i)
+        : "cc");
+
+        smp_mb();
+
+        return result;
+}
+
+static inline void atomic_sub(int i, atomic_t *v)
+{
+        unsigned long tmp;
+        int result;
+
+        __asm__ __volatile__("@ atomic_sub\n"
+"1:     ldrex   %0, [%3]\n"
+"       sub     %0, %0, %4\n"
+"       strex   %1, %0, [%3]\n"
+"       teq     %1, #0\n"
+"       bne     1b"
+        : "=&r" (result), "=&r" (tmp), "+Qo" (v->counter)
+        : "r" (&v->counter), "Ir" (i)
+        : "cc");
+}
+
+static inline int atomic_sub_return(int i, atomic_t *v)
+{
+        unsigned long tmp;
+        int result;
+
+        smp_mb();
+
+        __asm__ __volatile__("@ atomic_sub_return\n"
+"1:     ldrex   %0, [%3]\n"
+"       sub     %0, %0, %4\n"
+"       strex   %1, %0, [%3]\n"
+"       teq     %1, #0\n"
+"       bne     1b"
+        : "=&r" (result), "=&r" (tmp), "+Qo" (v->counter)
+        : "r" (&v->counter), "Ir" (i)
+        : "cc");
+
+        smp_mb();
+
+        return result;
+}
+
+static inline int atomic_cmpxchg(atomic_t *ptr, int old, int new)
+{
+        unsigned long oldval, res;
+
+        smp_mb();
+
+        do {
+                __asm__ __volatile__("@ atomic_cmpxchg\n"
+                "ldrex  %1, [%3]\n"
+                "mov    %0, #0\n"
+                "teq    %1, %4\n"
+                "strexeq %0, %5, [%3]\n"
+                    : "=&r" (res), "=&r" (oldval), "+Qo" (ptr->counter)
+                    : "r" (&ptr->counter), "Ir" (old), "r" (new)
+                    : "cc");
+        } while (res);
+
+        smp_mb();
+
+        return oldval;
+}
+
+static inline void atomic_clear_mask(unsigned long mask, unsigned long *addr)
+{
+        unsigned long tmp, tmp2;
+
+        __asm__ __volatile__("@ atomic_clear_mask\n"
+"1:     ldrex   %0, [%3]\n"
+"       bic     %0, %0, %4\n"
+"       strex   %1, %0, [%3]\n"
+"       teq     %1, #0\n"
+"       bne     1b"
+        : "=&r" (tmp), "=&r" (tmp2), "+Qo" (*addr)
+        : "r" (addr), "Ir" (mask)
+        : "cc");
+}
+
+#define atomic_inc(v)           atomic_add(1, v)
+#define atomic_dec(v)           atomic_sub(1, v)
+
+#define atomic_inc_and_test(v)  (atomic_add_return(1, v) == 0)
+#define atomic_dec_and_test(v)  (atomic_sub_return(1, v) == 0)
+#define atomic_inc_return(v)    (atomic_add_return(1, v))
+#define atomic_dec_return(v)    (atomic_sub_return(1, v))
+#define atomic_sub_and_test(i, v) (atomic_sub_return(i, v) == 0)
+
+#define atomic_add_negative(i,v) (atomic_add_return(i, v) < 0)
+
+static inline atomic_t atomic_compareandswap(
+    atomic_t old, atomic_t new, atomic_t *v)
+{
+    atomic_t rc;
+    rc.counter = __cmpxchg(&v->counter, old.counter, new.counter, sizeof(int));
+    return rc;
+}
+
+#endif /* __ARCH_ARM_ATOMIC__ */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/bitops.h b/xen/include/asm-arm/bitops.h
new file mode 100644
index 0000000..3d6b30b
--- /dev/null
+++ b/xen/include/asm-arm/bitops.h
@@ -0,0 +1,195 @@
+/*
+ * Copyright 1995, Russell King.
+ * Various bits and pieces copyrights include:
+ *  Linus Torvalds (test_bit).
+ * Big endian support: Copyright 2001, Nicolas Pitre
+ *  reworked by rmk.
+ */
+
+#ifndef _ARM_BITOPS_H
+#define _ARM_BITOPS_H
+
+extern void _set_bit(int nr, volatile void * p);
+extern void _clear_bit(int nr, volatile void * p);
+extern void _change_bit(int nr, volatile void * p);
+extern int _test_and_set_bit(int nr, volatile void * p);
+extern int _test_and_clear_bit(int nr, volatile void * p);
+extern int _test_and_change_bit(int nr, volatile void * p);
+
+#define set_bit(n,p)              _set_bit(n,p)
+#define clear_bit(n,p)            _clear_bit(n,p)
+#define change_bit(n,p)           _change_bit(n,p)
+#define test_and_set_bit(n,p)     _test_and_set_bit(n,p)
+#define test_and_clear_bit(n,p)   _test_and_clear_bit(n,p)
+#define test_and_change_bit(n,p)  _test_and_change_bit(n,p)
+
+#define BIT(nr)                 (1UL << (nr))
+#define BIT_MASK(nr)            (1UL << ((nr) % BITS_PER_LONG))
+#define BIT_WORD(nr)            ((nr) / BITS_PER_LONG)
+#define BITS_PER_BYTE           8
+
+#define ADDR (*(volatile long *) addr)
+#define CONST_ADDR (*(const volatile long *) addr)
+
+/**
+ * __test_and_set_bit - Set a bit and return its old value
+ * @nr: Bit to set
+ * @addr: Address to count from
+ *
+ * This operation is non-atomic and can be reordered.
+ * If two examples of this operation race, one can appear to succeed
+ * but actually fail.  You must protect multiple accesses with a lock.
+ */
+static inline int __test_and_set_bit(int nr, volatile void *addr)
+{
+        unsigned long mask = BIT_MASK(nr);
+        volatile unsigned long *p =
+                ((volatile unsigned long *)addr) + BIT_WORD(nr);
+        unsigned long old = *p;
+
+        *p = old | mask;
+        return (old & mask) != 0;
+}
+
+/**
+ * __test_and_clear_bit - Clear a bit and return its old value
+ * @nr: Bit to clear
+ * @addr: Address to count from
+ *
+ * This operation is non-atomic and can be reordered.
+ * If two examples of this operation race, one can appear to succeed
+ * but actually fail.  You must protect multiple accesses with a lock.
+ */
+static inline int __test_and_clear_bit(int nr, volatile void *addr)
+{
+        unsigned long mask = BIT_MASK(nr);
+        volatile unsigned long *p =
+                ((volatile unsigned long *)addr) + BIT_WORD(nr);
+        unsigned long old = *p;
+
+        *p = old & ~mask;
+        return (old & mask) != 0;
+}
+
+/* WARNING: non atomic and it can be reordered! */
+static inline int __test_and_change_bit(int nr,
+                                            volatile void *addr)
+{
+        unsigned long mask = BIT_MASK(nr);
+        volatile unsigned long *p =
+                ((volatile unsigned long *)addr) + BIT_WORD(nr);
+        unsigned long old = *p;
+
+        *p = old ^ mask;
+        return (old & mask) != 0;
+}
+
+/**
+ * test_bit - Determine whether a bit is set
+ * @nr: bit number to test
+ * @addr: Address to start counting from
+ */
+static inline int test_bit(int nr, const volatile void *addr)
+{
+        const volatile unsigned long *p = (const volatile unsigned long *)addr;
+        return 1UL & (p[BIT_WORD(nr)] >> (nr & (BITS_PER_LONG-1)));
+}
+
+
+extern unsigned int _find_first_bit(
+    const unsigned long *addr, unsigned int size);
+extern unsigned int _find_next_bit(
+    const unsigned long *addr, unsigned int size, unsigned int offset);
+extern unsigned int _find_first_zero_bit(
+    const unsigned long *addr, unsigned int size);
+extern unsigned int _find_next_zero_bit(
+    const unsigned long *addr, unsigned int size, unsigned int offset);
+
+/*
+ * These are the little endian, atomic definitions.
+ */
+#define find_first_zero_bit(p,sz)       _find_first_zero_bit(p,sz)
+#define find_next_zero_bit(p,sz,off)    _find_next_zero_bit(p,sz,off)
+#define find_first_bit(p,sz)            _find_first_bit(p,sz)
+#define find_next_bit(p,sz,off)         _find_next_bit(p,sz,off)
+
+static inline int constant_fls(int x)
+{
+        int r = 32;
+
+        if (!x)
+                return 0;
+        if (!(x & 0xffff0000u)) {
+                x <<= 16;
+                r -= 16;
+        }
+        if (!(x & 0xff000000u)) {
+                x <<= 8;
+                r -= 8;
+        }
+        if (!(x & 0xf0000000u)) {
+                x <<= 4;
+                r -= 4;
+        }
+        if (!(x & 0xc0000000u)) {
+                x <<= 2;
+                r -= 2;
+        }
+        if (!(x & 0x80000000u)) {
+                x <<= 1;
+                r -= 1;
+        }
+        return r;
+}
+
+/*
+ * On ARMv5 and above those functions can be implemented around
+ * the clz instruction for much better code efficiency.
+ */
+
+static inline int fls(int x)
+{
+        int ret;
+
+        if (__builtin_constant_p(x))
+               return constant_fls(x);
+
+        asm("clz\t%0, %1" : "=r" (ret) : "r" (x));
+        ret = 32 - ret;
+        return ret;
+}
+
+#define ffs(x) ({ unsigned long __t = (x); fls(__t & -__t); })
+
+/**
+ * find_first_set_bit - find the first set bit in @word
+ * @word: the word to search
+ *
+ * Returns the bit-number of the first set bit (first bit being 0).
+ * The input must *not* be zero.
+ */
+static inline unsigned int find_first_set_bit(unsigned long word)
+{
+        return ffs(word) - 1;
+}
+
+/**
+ * hweightN - returns the hamming weight of a N-bit word
+ * @x: the word to weigh
+ *
+ * The Hamming Weight of a number is the total number of bits set in it.
+ */
+#define hweight64(x) generic_hweight64(x)
+#define hweight32(x) generic_hweight32(x)
+#define hweight16(x) generic_hweight16(x)
+#define hweight8(x) generic_hweight8(x)
+
+#endif /* _ARM_BITOPS_H */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/bug.h b/xen/include/asm-arm/bug.h
new file mode 100644
index 0000000..bc2532c
--- /dev/null
+++ b/xen/include/asm-arm/bug.h
@@ -0,0 +1,15 @@
+#ifndef __ARM_BUG_H__
+#define __ARM_BUG_H__
+
+#define BUG() __bug(__FILE__, __LINE__)
+#define WARN() __warn(__FILE__, __LINE__)
+
+#endif /* __X86_BUG_H__ */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/byteorder.h b/xen/include/asm-arm/byteorder.h
new file mode 100644
index 0000000..f6ad883
--- /dev/null
+++ b/xen/include/asm-arm/byteorder.h
@@ -0,0 +1,16 @@
+#ifndef __ASM_ARM_BYTEORDER_H__
+#define __ASM_ARM_BYTEORDER_H__
+
+#define __BYTEORDER_HAS_U64__
+
+#include <xen/byteorder/little_endian.h>
+
+#endif /* __ASM_ARM_BYTEORDER_H__ */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/cache.h b/xen/include/asm-arm/cache.h
new file mode 100644
index 0000000..41b6291
--- /dev/null
+++ b/xen/include/asm-arm/cache.h
@@ -0,0 +1,20 @@
+#ifndef __ARCH_ARM_CACHE_H
+#define __ARCH_ARM_CACHE_H
+
+#include <xen/config.h>
+
+/* L1 cache line size */
+#define L1_CACHE_SHIFT  (CONFIG_ARM_L1_CACHE_SHIFT)
+#define L1_CACHE_BYTES  (1 << L1_CACHE_SHIFT)
+
+#define __read_mostly __attribute__((__section__(".data.read_mostly")))
+
+#endif
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/config.h b/xen/include/asm-arm/config.h
new file mode 100644
index 0000000..12285dd
--- /dev/null
+++ b/xen/include/asm-arm/config.h
@@ -0,0 +1,122 @@
+/******************************************************************************
+ * config.h
+ *
+ * A Linux-style configuration list.
+ */
+
+#ifndef __ARM_CONFIG_H__
+#define __ARM_CONFIG_H__
+
+#define CONFIG_PAGING_LEVELS 3
+
+#define CONFIG_ARM 1
+
+#define CONFIG_ARM_L1_CACHE_SHIFT 7 /* XXX */
+
+#define CONFIG_SMP 1
+
+#define CONFIG_DOMAIN_PAGE 1
+
+#define OPT_CONSOLE_STR "com1"
+
+#ifdef MAX_PHYS_CPUS
+#define NR_CPUS MAX_PHYS_CPUS
+#else
+#define NR_CPUS 128
+#endif
+
+#define MAX_VIRT_CPUS 128 /* XXX */
+#define MAX_HVM_VCPUS MAX_VIRT_CPUS
+
+#define asmlinkage /* Nothing needed */
+
+/* Linkage for ARM */
+#define __ALIGN .align 2
+#define __ALIGN_STR ".align 2"
+#ifdef __ASSEMBLY__
+#define ALIGN __ALIGN
+#define ALIGN_STR __ALIGN_STR
+#define ENTRY(name)                             \
+  .globl name;                                  \
+  ALIGN;                                        \
+  name:
+#define END(name) \
+  .size name, .-name
+#define ENDPROC(name) \
+  .type name, %function; \
+  END(name)
+#endif
+
+/*
+ * Memory layout:
+ *  0  -   2M   Unmapped
+ *  2M -   4M   Xen text, data, bss
+ *  4M -   6M   Fixmap: special-purpose 4K mapping slots
+ *
+ * 32M - 128M   Frametable: 24 bytes per page for 16GB of RAM
+ *
+ *  1G -   2G   Xenheap: always-mapped memory
+ *  2G -   4G   Domheap: on-demand-mapped
+ */
+
+#define XEN_VIRT_START         0x00200000
+#define FIXMAP_ADDR(n)        (0x00400000 + (n) * PAGE_SIZE)
+#define FRAMETABLE_VIRT_START  0x02000000
+#define XENHEAP_VIRT_START     0x40000000
+#define DOMHEAP_VIRT_START     0x80000000
+
+#define HYPERVISOR_VIRT_START mk_unsigned_long(XEN_VIRT_START)
+
+#define DOMHEAP_ENTRIES        1024  /* 1024 2MB mapping slots */
+
+/* Fixmap slots */
+#define FIXMAP_CONSOLE  0  /* The primary UART */
+#define FIXMAP_PT       1  /* Temporary mappings of pagetable pages */
+#define FIXMAP_MISC     2  /* Ephemeral mappings of hardware */
+#define FIXMAP_GICD     3  /* Interrupt controller: distributor registers */
+#define FIXMAP_GICC1    4  /* Interrupt controller: CPU registers (first page) */
+#define FIXMAP_GICC2    5  /* Interrupt controller: CPU registers (second page) */
+#define FIXMAP_GICH     6  /* Interrupt controller: virtual interface control registers */
+
+#define PAGE_SHIFT              12
+
+#ifndef __ASSEMBLY__
+#define PAGE_SIZE           (1L << PAGE_SHIFT)
+#else
+#define PAGE_SIZE           (1 << PAGE_SHIFT)
+#endif
+#define PAGE_MASK           (~(PAGE_SIZE-1))
+#define PAGE_FLAG_MASK      (~0)
+
+#define STACK_ORDER 3
+#define STACK_SIZE  (PAGE_SIZE << STACK_ORDER)
+
+#ifndef __ASSEMBLY__
+extern unsigned long xen_phys_start;
+extern unsigned long xenheap_phys_end;
+extern unsigned long frametable_virt_end;
+#endif
+
+#define supervisor_mode_kernel (0)
+
+#define watchdog_disable() ((void)0)
+#define watchdog_enable()  ((void)0)
+
+/* Board-specific: base address of PL011 UART */
+#define EARLY_UART_ADDRESS 0x1c090000
+/* Board-specific: base address of GIC + its regs */
+#define GIC_BASE_ADDRESS 0x2c000000
+#define GIC_DR_OFFSET 0x1000
+#define GIC_CR_OFFSET 0x2000
+#define GIC_HR_OFFSET 0x4000 /* Guess work http://lists.infradead.org/pipermail/linux-arm-kernel/2011-September/064219.html */
+#define GIC_VR_OFFSET 0x6000 /* Virtual Machine CPU interface) */
+
+#endif /* __ARM_CONFIG_H__ */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/cpregs.h b/xen/include/asm-arm/cpregs.h
new file mode 100644
index 0000000..3a4028d
--- /dev/null
+++ b/xen/include/asm-arm/cpregs.h
@@ -0,0 +1,207 @@
+#ifndef __ASM_ARM_CPREGS_H
+#define __ASM_ARM_CPREGS_H
+
+#include <xen/stringify.h>
+
+/* Co-processor registers */
+
+/* Layout as used in assembly, with src/dest registers mixed in */
+#define __CP32(r, coproc, opc1, crn, crm, opc2) coproc, opc1, r, crn, crm, opc2
+#define __CP64(r1, r2, coproc, opc, crm) coproc, opc, r1, r2, crm
+#define CP32(r, name...) __CP32(r, name)
+#define CP64(r, name...) __CP64(r, name)
+
+/* Stringified for inline assembly */
+#define LOAD_CP32(r, name...)  "mrc " __stringify(CP32(%r, name)) ";"
+#define STORE_CP32(r, name...) "mcr " __stringify(CP32(%r, name)) ";"
+#define LOAD_CP64(r, name...)  "mrrc " __stringify(CP64(%r, %H##r, name)) ";"
+#define STORE_CP64(r, name...) "mcrr " __stringify(CP64(%r, %H##r, name)) ";"
+
+/* C wrappers */
+#define READ_CP32(name...) ({                                   \
+    register uint32_t _r;                                       \
+    asm volatile(LOAD_CP32(0, name) : "=r" (_r));               \
+    _r; })
+
+#define WRITE_CP32(v, name...) do {                             \
+    register uint32_t _r = (v);                                 \
+    asm volatile(STORE_CP32(0, name) : : "r" (_r));             \
+} while (0)
+
+#define READ_CP64(name...) ({                                   \
+    register uint64_t _r;                                       \
+    asm volatile(LOAD_CP64(0, name) : "=r" (_r));               \
+    _r; })
+
+#define WRITE_CP64(v, name...) do {                             \
+    register uint64_t _r = (v);                                 \
+    asm volatile(STORE_CP64(0, name) : : "r" (_r));             \
+} while (0)
+
+#define __HSR_CPREG_c0  0
+#define __HSR_CPREG_c1  1
+#define __HSR_CPREG_c2  2
+#define __HSR_CPREG_c3  3
+#define __HSR_CPREG_c4  4
+#define __HSR_CPREG_c5  5
+#define __HSR_CPREG_c6  6
+#define __HSR_CPREG_c7  7
+#define __HSR_CPREG_c8  8
+#define __HSR_CPREG_c9  9
+#define __HSR_CPREG_c10 10
+#define __HSR_CPREG_c11 11
+#define __HSR_CPREG_c12 12
+#define __HSR_CPREG_c13 13
+#define __HSR_CPREG_c14 14
+#define __HSR_CPREG_c15 15
+
+#define __HSR_CPREG_0   0
+#define __HSR_CPREG_1   1
+#define __HSR_CPREG_2   2
+#define __HSR_CPREG_3   3
+#define __HSR_CPREG_4   4
+#define __HSR_CPREG_5   5
+#define __HSR_CPREG_6   6
+#define __HSR_CPREG_7   7
+
+#define _HSR_CPREG32(cp,op1,crn,crm,op2) \
+    ((__HSR_CPREG_##crn) << HSR_CP32_CRN_SHIFT) | \
+    ((__HSR_CPREG_##crm) << HSR_CP32_CRM_SHIFT) | \
+    ((__HSR_CPREG_##op1) << HSR_CP32_OP1_SHIFT) | \
+    ((__HSR_CPREG_##op2) << HSR_CP32_OP2_SHIFT)
+
+#define _HSR_CPREG64(cp,op1,crm) \
+    ((__HSR_CPREG_##crm) << HSR_CP64_CRM_SHIFT) | \
+    ((__HSR_CPREG_##op1) << HSR_CP64_OP1_SHIFT)
+
+/* Encode a register as per HSR ISS pattern */
+#define HSR_CPREG32(X) _HSR_CPREG32(X)
+#define HSR_CPREG64(X) _HSR_CPREG64(X)
+
+/*
+ * Order registers by Coprocessor-> CRn-> Opcode 1-> CRm-> Opcode 2
+ *
+ * This matches the ordering used in the ARM as well as the groupings
+ * which the CP registers are allocated in.
+ *
+ * This is slightly different to the form of the instruction
+ * arguments, which are cp,opc1,crn,crm,opc2.
+ */
+
+/* Coprocessor 15 */
+
+/* CP15 CR0: CPUID and Cache Type Registers */
+#define ID_PFR0         p15,0,c0,c1,0   /* Processor Feature Register 0 */
+#define ID_PFR1         p15,0,c0,c1,1   /* Processor Feature Register 1 */
+#define CCSIDR          p15,1,c0,c0,0   /* Cache Size ID Registers */
+#define CLIDR           p15,1,c0,c0,1   /* Cache Level ID Register */
+#define CSSELR          p15,2,c0,c0,0   /* Cache Size Selection Register */
+
+/* CP15 CR1: System Control Registers */
+#define SCTLR           p15,0,c1,c0,0   /* System Control Register */
+#define SCR             p15,0,c1,c1,0   /* Secure Configuration Register */
+#define NSACR           p15,0,c1,c1,2   /* Non-Secure Access Control Register */
+#define HSCTLR          p15,4,c1,c0,0   /* Hyp. System Control Register */
+#define HCR             p15,4,c1,c1,0   /* Hyp. Configuration Register */
+
+/* CP15 CR2: Translation Table Base and Control Registers */
+#define TTBR0           p15,0,c2,c0,0   /* Translation Table Base Reg. 0 */
+#define TTBR1           p15,0,c2,c0,1   /* Translation Table Base Reg. 1 */
+#define TTBCR           p15,0,c2,c0,2   /* Translatation Table Base Control Register */
+#define HTTBR           p15,4,c2        /* Hyp. Translation Table Base Register */
+#define HTCR            p15,4,c2,c0,2   /* Hyp. Translation Control Register */
+#define VTCR            p15,4,c2,c1,2   /* Virtualization Translation Control Register */
+#define VTTBR           p15,6,c2        /* Virtualization Translation Table Base Register */
+
+/* CP15 CR3: Domain Access Control Register */
+
+/* CP15 CR4: */
+
+/* CP15 CR5: Fault Status Registers */
+#define DFSR            p15,0,c5,c0,0   /* Data Fault Status Register */
+#define IFSR            p15,0,c5,c0,1   /* Instruction Fault Status Register */
+#define HSR             p15,4,c5,c2,0   /* Hyp. Syndrome Register */
+
+/* CP15 CR6: Fault Address Registers */
+#define DFAR            p15,0,c6,c0,0   /* Data Fault Address Register  */
+#define IFAR            p15,0,c6,c0,2   /* Instruction Fault Address Register */
+#define HDFAR           p15,4,c6,c0,0   /* Hyp. Data Fault Address Register */
+#define HIFAR           p15,4,c6,c0,2   /* Hyp. Instruction Fault Address Register */
+#define HPFAR           p15,4,c6,c0,4   /* Hyp. IPA Fault Address Register */
+
+/* CP15 CR7: Cache and address translation operations */
+#define PAR             p15,0,c7        /* Physical Address Register */
+#define ICIALLUIS       p15,0,c7,c1,0   /* Invalidate all instruction caches to PoU inner shareable */
+#define BPIALLIS        p15,0,c7,c1,6   /* Invalidate entire branch predictor array inner shareable */
+#define ICIALLU         p15,0,c7,c5,0   /* Invalidate all instruction caches to PoU */
+#define BPIALL          p15,0,c7,c5,6   /* Invalidate entire branch predictor array */
+#define ATS1CPR         p15,0,c7,c8,0   /* Address Translation Stage 1. Non-Secure Kernel Read */
+#define ATS1CPW         p15,0,c7,c8,1   /* Address Translation Stage 1. Non-Secure Kernel Write */
+#define ATS1CUR         p15,0,c7,c8,2   /* Address Translation Stage 1. Non-Secure User Read */
+#define ATS1CUW         p15,0,c7,c8,3   /* Address Translation Stage 1. Non-Secure User Write */
+#define ATS12NSOPR      p15,0,c7,c8,4   /* Address Translation Stage 1+2 Non-Secure Kernel Read */
+#define ATS12NSOPW      p15,0,c7,c8,5   /* Address Translation Stage 1+2 Non-Secure Kernel Write */
+#define ATS12NSOUR      p15,0,c7,c8,6   /* Address Translation Stage 1+2 Non-Secure User Read */
+#define ATS12NSOUW      p15,0,c7,c8,7   /* Address Translation Stage 1+2 Non-Secure User Write */
+#define DCCMVAC         p15,0,c7,c10,1  /* Clean data or unified cache line by MVA to PoC */
+#define DCCISW          p15,0,c7,c14,2  /* Clean and invalidate data cache line by set/way */
+#define ATS1HR          p15,4,c7,c8,0   /* Address Translation Stage 1 Hyp. Read */
+#define ATS1HW          p15,4,c7,c8,1   /* Address Translation Stage 1 Hyp. Write */
+
+/* CP15 CR8: TLB maintenance operations */
+#define TLBIALLIS       p15,0,c8,c3,0   /* Invalidate entire TLB innrer shareable */
+#define TLBIMVAIS       p15,0,c8,c3,1   /* Invalidate unified TLB entry by MVA inner shareable */
+#define TLBIASIDIS      p15,0,c8,c3,2   /* Invalidate unified TLB by ASID match inner shareable */
+#define TLBIMVAAIS      p15,0,c8,c3,3   /* Invalidate unified TLB entry by MVA all ASID inner shareable */
+#define DTLBIALL        p15,0,c8,c6,0   /* Invalidate data TLB */
+#define DTLBIMVA        p15,0,c8,c6,1   /* Invalidate data TLB entry by MVA */
+#define DTLBIASID       p15,0,c8,c6,2   /* Invalidate data TLB by ASID match */
+#define TLBILLHIS       p15,4,c8,c3,0   /* Invalidate Entire Hyp. Unified TLB inner shareable */
+#define TLBIMVAHIS      p15,4,c8,c3,1   /* Invalidate Unified Hyp. TLB by MVA inner shareable */
+#define TLBIALLNSNHIS   p15,4,c8,c7,4   /* Invalidate Entire Non-Secure Non-Hyp. Unified TLB inner shareable */
+#define TLBIALLH        p15,4,c8,c7,0   /* Invalidate Entire Hyp. Unified TLB */
+#define TLBIMVAH        p15,4,c8,c7,1   /* Invalidate Unified Hyp. TLB by MVA */
+#define TLBIALLNSNH     p15,4,c8,c7,4   /* Invalidate Entire Non-Secure Non-Hyp. Unified TLB */
+
+/* CP15 CR9: */
+
+/* CP15 CR10: */
+#define MAIR0           p15,0,c10,c2,0  /* Memory Attribute Indirection Register 0 */
+#define MAIR1           p15,0,c10,c2,1  /* Memory Attribute Indirection Register 1 */
+#define HMAIR0          p15,4,c10,c2,0  /* Hyp. Memory Attribute Indirection Register 0 */
+#define HMAIR1          p15,4,c10,c2,1  /* Hyp. Memory Attribute Indirection Register 1 */
+
+/* CP15 CR11: DMA Operations for TCM Access */
+
+/* CP15 CR12:  */
+#define HVBAR           p15,4,c12,c0,0  /* Hyp. Vector Base Address Register */
+
+/* CP15 CR13:  */
+#define FCSEIDR         p15,0,c13,c0,0  /* FCSE Process ID Register */
+#define CONTEXTIDR      p15,0,c13,c0,1  /* Context ID Register */
+
+/* CP15 CR14:  */
+#define CNTPCT          p15,0,c14       /* Time counter value */
+#define CNTFRQ          p15,0,c14,c0,0  /* Time counter frequency */
+#define CNTKCTL         p15,0,c14,c1,0  /* Time counter kernel control */
+#define CNTP_TVAL       p15,0,c14,c2,0  /* Physical Timer value */
+#define CNTP_CTL        p15,0,c14,c2,1  /* Physical Timer control register */
+#define CNTVCT          p15,1,c14       /* Time counter value + offset */
+#define CNTP_CVAL       p15,2,c14       /* Physical Timer comparator */
+#define CNTVOFF         p15,4,c14       /* Time counter offset */
+#define CNTHCTL         p15,4,c14,c1,0  /* Time counter hyp. control */
+#define CNTHP_TVAL      p15,4,c14,c2,0  /* Hyp. Timer value */
+#define CNTHP_CTL       p15,4,c14,c2,1  /* Hyp. Timer control register */
+#define CNTHP_CVAL      p15,6,c14       /* Hyp. Timer comparator */
+
+/* CP15 CR15: Implementation Defined Registers */
+
+#endif
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/current.h b/xen/include/asm-arm/current.h
new file mode 100644
index 0000000..826efa5
--- /dev/null
+++ b/xen/include/asm-arm/current.h
@@ -0,0 +1,60 @@
+#ifndef __ARM_CURRENT_H__
+#define __ARM_CURRENT_H__
+
+#include <xen/config.h>
+#include <xen/percpu.h>
+#include <public/xen.h>
+
+#ifndef __ASSEMBLY__
+
+struct vcpu;
+
+struct cpu_info {
+    struct cpu_user_regs guest_cpu_user_regs;
+    unsigned long elr;
+    unsigned int processor_id;
+    struct vcpu *current_vcpu;
+    unsigned long per_cpu_offset;
+};
+
+static inline struct cpu_info *get_cpu_info(void)
+{
+        register unsigned long sp asm ("sp");
+        return (struct cpu_info *)((sp & ~(STACK_SIZE - 1)) + STACK_SIZE - sizeof(struct cpu_info));
+}
+
+#define get_current()         (get_cpu_info()->current_vcpu)
+#define set_current(vcpu)     (get_cpu_info()->current_vcpu = (vcpu))
+#define current               (get_current())
+
+#define get_processor_id()    (get_cpu_info()->processor_id)
+#define set_processor_id(id)  do {                                      \
+    struct cpu_info *ci__ = get_cpu_info();                             \
+    ci__->per_cpu_offset = __per_cpu_offset[ci__->processor_id = (id)]; \
+} while (0)
+
+#define guest_cpu_user_regs() (&get_cpu_info()->guest_cpu_user_regs)
+
+#define reset_stack_and_jump(__fn)              \
+    __asm__ __volatile__ (                      \
+        "mov sp,%0; b "STR(__fn)      \
+        : : "r" (guest_cpu_user_regs()) : "memory" )
+#endif
+
+
+/*
+ * Which VCPU's state is currently running on each CPU?
+ * This is not necesasrily the same as 'current' as a CPU may be
+ * executing a lazy state switch.
+ */
+DECLARE_PER_CPU(struct vcpu *, curr_vcpu);
+
+#endif /* __ARM_CURRENT_H__ */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/debugger.h b/xen/include/asm-arm/debugger.h
new file mode 100644
index 0000000..84b2eec
--- /dev/null
+++ b/xen/include/asm-arm/debugger.h
@@ -0,0 +1,15 @@
+#ifndef __ARM_DEBUGGER_H__
+#define __ARM_DEBUGGER_H__
+
+#define debugger_trap_fatal(v, r) (0)
+#define debugger_trap_immediate() (0)
+
+#endif /* __ARM_DEBUGGER_H__ */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/delay.h b/xen/include/asm-arm/delay.h
new file mode 100644
index 0000000..6250774
--- /dev/null
+++ b/xen/include/asm-arm/delay.h
@@ -0,0 +1,15 @@
+#ifndef _ARM_DELAY_H
+#define _ARM_DELAY_H
+
+extern void __udelay(unsigned long usecs);
+#define udelay(n) __udelay(n)
+
+#endif /* defined(_ARM_DELAY_H) */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/desc.h b/xen/include/asm-arm/desc.h
new file mode 100644
index 0000000..3989e8a
--- /dev/null
+++ b/xen/include/asm-arm/desc.h
@@ -0,0 +1,12 @@
+#ifndef __ARCH_DESC_H
+#define __ARCH_DESC_H
+
+#endif /* __ARCH_DESC_H */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/div64.h b/xen/include/asm-arm/div64.h
new file mode 100644
index 0000000..7b00808
--- /dev/null
+++ b/xen/include/asm-arm/div64.h
@@ -0,0 +1,235 @@
+/* Taken from Linux arch/arm */
+#ifndef __ASM_ARM_DIV64
+#define __ASM_ARM_DIV64
+
+#include <asm/system.h>
+#include <xen/types.h>
+
+/*
+ * The semantics of do_div() are:
+ *
+ * uint32_t do_div(uint64_t *n, uint32_t base)
+ * {
+ * 	uint32_t remainder = *n % base;
+ * 	*n = *n / base;
+ * 	return remainder;
+ * }
+ *
+ * In other words, a 64-bit dividend with a 32-bit divisor producing
+ * a 64-bit result and a 32-bit remainder.  To accomplish this optimally
+ * we call a special __do_div64 helper with completely non standard
+ * calling convention for arguments and results (beware).
+ */
+
+#ifdef __ARMEB__
+#define __xh "r0"
+#define __xl "r1"
+#else
+#define __xl "r0"
+#define __xh "r1"
+#endif
+
+#define __do_div_asm(n, base)					\
+({								\
+	register unsigned int __base      asm("r4") = base;	\
+	register unsigned long long __n   asm("r0") = n;	\
+	register unsigned long long __res asm("r2");		\
+	register unsigned int __rem       asm(__xh);		\
+	asm(	__asmeq("%0", __xh)				\
+		__asmeq("%1", "r2")				\
+		__asmeq("%2", "r0")				\
+		__asmeq("%3", "r4")				\
+		"bl	__do_div64"				\
+		: "=r" (__rem), "=r" (__res)			\
+		: "r" (__n), "r" (__base)			\
+		: "ip", "lr", "cc");				\
+	n = __res;						\
+	__rem;							\
+})
+
+#if __GNUC__ < 4
+
+/*
+ * gcc versions earlier than 4.0 are simply too problematic for the
+ * optimized implementation below. First there is gcc PR 15089 that
+ * tend to trig on more complex constructs, spurious .global __udivsi3
+ * are inserted even if none of those symbols are referenced in the
+ * generated code, and those gcc versions are not able to do constant
+ * propagation on long long values anyway.
+ */
+#define do_div(n, base) __do_div_asm(n, base)
+
+#elif __GNUC__ >= 4
+
+#include <asm/bug.h>
+
+/*
+ * If the divisor happens to be constant, we determine the appropriate
+ * inverse at compile time to turn the division into a few inline
+ * multiplications instead which is much faster. And yet only if compiling
+ * for ARMv4 or higher (we need umull/umlal) and if the gcc version is
+ * sufficiently recent to perform proper long long constant propagation.
+ * (It is unfortunate that gcc doesn't perform all this internally.)
+ */
+#define do_div(n, base)							\
+({									\
+	unsigned int __r, __b = (base);					\
+	if (!__builtin_constant_p(__b) || __b == 0) {			\
+		/* non-constant divisor (or zero): slow path */		\
+		__r = __do_div_asm(n, __b);				\
+	} else if ((__b & (__b - 1)) == 0) {				\
+		/* Trivial: __b is constant and a power of 2 */		\
+		/* gcc does the right thing with this code.  */		\
+		__r = n;						\
+		__r &= (__b - 1);					\
+		n /= __b;						\
+	} else {							\
+		/* Multiply by inverse of __b: n/b = n*(p/b)/p       */	\
+		/* We rely on the fact that most of this code gets   */	\
+		/* optimized away at compile time due to constant    */	\
+		/* propagation and only a couple inline assembly     */	\
+		/* instructions should remain. Better avoid any      */	\
+		/* code construct that might prevent that.           */	\
+		unsigned long long __res, __x, __t, __m, __n = n;	\
+		unsigned int __c, __p, __z = 0;				\
+		/* preserve low part of n for reminder computation */	\
+		__r = __n;						\
+		/* determine number of bits to represent __b */		\
+		__p = 1 << __div64_fls(__b);				\
+		/* compute __m = ((__p << 64) + __b - 1) / __b */	\
+		__m = (~0ULL / __b) * __p;				\
+		__m += (((~0ULL % __b + 1) * __p) + __b - 1) / __b;	\
+		/* compute __res = __m*(~0ULL/__b*__b-1)/(__p << 64) */	\
+		__x = ~0ULL / __b * __b - 1;				\
+		__res = (__m & 0xffffffff) * (__x & 0xffffffff);	\
+		__res >>= 32;						\
+		__res += (__m & 0xffffffff) * (__x >> 32);		\
+		__t = __res;						\
+		__res += (__x & 0xffffffff) * (__m >> 32);		\
+		__t = (__res < __t) ? (1ULL << 32) : 0;			\
+		__res = (__res >> 32) + __t;				\
+		__res += (__m >> 32) * (__x >> 32);			\
+		__res /= __p;						\
+		/* Now sanitize and optimize what we've got. */		\
+		if (~0ULL % (__b / (__b & -__b)) == 0) {		\
+			/* those cases can be simplified with: */	\
+			__n /= (__b & -__b);				\
+			__m = ~0ULL / (__b / (__b & -__b));		\
+			__p = 1;					\
+			__c = 1;					\
+		} else if (__res != __x / __b) {			\
+			/* We can't get away without a correction    */	\
+			/* to compensate for bit truncation errors.  */	\
+			/* To avoid it we'd need an additional bit   */	\
+			/* to represent __m which would overflow it. */	\
+			/* Instead we do m=p/b and n/b=(n*m+m)/p.    */	\
+			__c = 1;					\
+			/* Compute __m = (__p << 64) / __b */		\
+			__m = (~0ULL / __b) * __p;			\
+			__m += ((~0ULL % __b + 1) * __p) / __b;		\
+		} else {						\
+			/* Reduce __m/__p, and try to clear bit 31   */	\
+			/* of __m when possible otherwise that'll    */	\
+			/* need extra overflow handling later.       */	\
+			unsigned int __bits = -(__m & -__m);		\
+			__bits |= __m >> 32;				\
+			__bits = (~__bits) << 1;			\
+			/* If __bits == 0 then setting bit 31 is     */	\
+			/* unavoidable.  Simply apply the maximum    */	\
+			/* possible reduction in that case.          */	\
+			/* Otherwise the MSB of __bits indicates the */	\
+			/* best reduction we should apply.           */	\
+			if (!__bits) {					\
+				__p /= (__m & -__m);			\
+				__m /= (__m & -__m);			\
+			} else {					\
+				__p >>= __div64_fls(__bits);		\
+				__m >>= __div64_fls(__bits);		\
+			}						\
+			/* No correction needed. */			\
+			__c = 0;					\
+		}							\
+		/* Now we have a combination of 2 conditions:        */	\
+		/* 1) whether or not we need a correction (__c), and */	\
+		/* 2) whether or not there might be an overflow in   */	\
+		/*    the cross product (__m & ((1<<63) | (1<<31)))  */	\
+		/* Select the best insn combination to perform the   */	\
+		/* actual __m * __n / (__p << 64) operation.         */	\
+		if (!__c) {						\
+			asm (	"umull	%Q0, %R0, %1, %Q2\n\t"		\
+				"mov	%Q0, #0"			\
+				: "=&r" (__res)				\
+				: "r" (__m), "r" (__n)			\
+				: "cc" );				\
+		} else if (!(__m & ((1ULL << 63) | (1ULL << 31)))) {	\
+			__res = __m;					\
+			asm (	"umlal	%Q0, %R0, %Q1, %Q2\n\t"		\
+				"mov	%Q0, #0"			\
+				: "+&r" (__res)				\
+				: "r" (__m), "r" (__n)			\
+				: "cc" );				\
+		} else {						\
+			asm (	"umull	%Q0, %R0, %Q1, %Q2\n\t"		\
+				"cmn	%Q0, %Q1\n\t"			\
+				"adcs	%R0, %R0, %R1\n\t"		\
+				"adc	%Q0, %3, #0"			\
+				: "=&r" (__res)				\
+				: "r" (__m), "r" (__n), "r" (__z)	\
+				: "cc" );				\
+		}							\
+		if (!(__m & ((1ULL << 63) | (1ULL << 31)))) {		\
+			asm (	"umlal	%R0, %Q0, %R1, %Q2\n\t"		\
+				"umlal	%R0, %Q0, %Q1, %R2\n\t"		\
+				"mov	%R0, #0\n\t"			\
+				"umlal	%Q0, %R0, %R1, %R2"		\
+				: "+&r" (__res)				\
+				: "r" (__m), "r" (__n)			\
+				: "cc" );				\
+		} else {						\
+			asm (	"umlal	%R0, %Q0, %R2, %Q3\n\t"		\
+				"umlal	%R0, %1, %Q2, %R3\n\t"		\
+				"mov	%R0, #0\n\t"			\
+				"adds	%Q0, %1, %Q0\n\t"		\
+				"adc	%R0, %R0, #0\n\t"		\
+				"umlal	%Q0, %R0, %R2, %R3"		\
+				: "+&r" (__res), "+&r" (__z)		\
+				: "r" (__m), "r" (__n)			\
+				: "cc" );				\
+		}							\
+		__res /= __p;						\
+		/* The reminder can be computed with 32-bit regs     */	\
+		/* only, and gcc is good at that.                    */	\
+		{							\
+			unsigned int __res0 = __res;			\
+			unsigned int __b0 = __b;			\
+			__r -= __res0 * __b0;				\
+		}							\
+		/* BUG_ON(__r >= __b || __res * __b + __r != n); */	\
+		n = __res;						\
+	}								\
+	__r;								\
+})
+
+/* our own fls implementation to make sure constant propagation is fine */
+#define __div64_fls(bits)						\
+({									\
+	unsigned int __left = (bits), __nr = 0;				\
+	if (__left & 0xffff0000) __nr += 16, __left >>= 16;		\
+	if (__left & 0x0000ff00) __nr +=  8, __left >>=  8;		\
+	if (__left & 0x000000f0) __nr +=  4, __left >>=  4;		\
+	if (__left & 0x0000000c) __nr +=  2, __left >>=  2;		\
+	if (__left & 0x00000002) __nr +=  1;				\
+	__nr;								\
+})
+
+#endif
+
+#endif
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/elf.h b/xen/include/asm-arm/elf.h
new file mode 100644
index 0000000..12d487c
--- /dev/null
+++ b/xen/include/asm-arm/elf.h
@@ -0,0 +1,33 @@
+#ifndef __ARM_ELF_H__
+#define __ARM_ELF_H__
+
+typedef struct {
+    unsigned long r0;
+    unsigned long r1;
+    unsigned long r2;
+    unsigned long r3;
+    unsigned long r4;
+    unsigned long r5;
+    unsigned long r6;
+    unsigned long r7;
+    unsigned long r8;
+    unsigned long r9;
+    unsigned long r10;
+    unsigned long r11;
+    unsigned long r12;
+    unsigned long sp;
+    unsigned long lr;
+    unsigned long pc;
+} ELF_Gregset;
+
+#endif /* __ARM_ELF_H__ */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/event.h b/xen/include/asm-arm/event.h
new file mode 100644
index 0000000..6b2fb7c
--- /dev/null
+++ b/xen/include/asm-arm/event.h
@@ -0,0 +1,41 @@
+#ifndef __ASM_EVENT_H__
+#define __ASM_EVENT_H__
+
+void vcpu_kick(struct vcpu *v);
+void vcpu_mark_events_pending(struct vcpu *v);
+
+static inline int local_events_need_delivery(void)
+{
+    /* TODO
+     * return (vcpu_info(v, evtchn_upcall_pending) &&
+                        !vcpu_info(v, evtchn_upcall_mask)); */
+        return 0;
+}
+
+int local_event_delivery_is_enabled(void);
+
+static inline void local_event_delivery_disable(void)
+{
+    /* TODO current->vcpu_info->evtchn_upcall_mask = 1; */
+}
+
+static inline void local_event_delivery_enable(void)
+{
+    /* TODO current->vcpu_info->evtchn_upcall_mask = 0; */
+}
+
+/* No arch specific virq definition now. Default to global. */
+static inline int arch_virq_is_global(int virq)
+{
+    return 1;
+}
+
+#endif
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/flushtlb.h b/xen/include/asm-arm/flushtlb.h
new file mode 100644
index 0000000..c8486fc
--- /dev/null
+++ b/xen/include/asm-arm/flushtlb.h
@@ -0,0 +1,31 @@
+#ifndef __FLUSHTLB_H__
+#define __FLUSHTLB_H__
+
+#include <xen/cpumask.h>
+
+/*
+ * Filter the given set of CPUs, removing those that definitely flushed their
+ * TLB since @page_timestamp.
+ */
+/* XXX lazy implementation just doesn't clear anything.... */
+#define tlbflush_filter(mask, page_timestamp)                           \
+do {                                                                    \
+} while ( 0 )
+
+#define tlbflush_current_time()                 (0)
+
+/* Flush local TLBs */
+void flush_tlb_local(void);
+
+/* Flush specified CPUs' TLBs */
+void flush_tlb_mask(const cpumask_t *mask);
+
+#endif /* __FLUSHTLB_H__ */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/grant_table.h b/xen/include/asm-arm/grant_table.h
new file mode 100644
index 0000000..8f6ffd8
--- /dev/null
+++ b/xen/include/asm-arm/grant_table.h
@@ -0,0 +1,35 @@
+#ifndef __ASM_GRANT_TABLE_H__
+#define __ASM_GRANT_TABLE_H__
+
+#include <xen/grant_table.h>
+
+#define INVALID_GFN (-1UL)
+#define INITIAL_NR_GRANT_FRAMES 1
+
+void gnttab_clear_flag(unsigned long nr, uint16_t *addr);
+int create_grant_host_mapping(unsigned long gpaddr,
+		unsigned long mfn, unsigned int flags, unsigned int
+		cache_flags);
+#define gnttab_host_mapping_get_page_type(op, d, rd) (0)
+int replace_grant_host_mapping(unsigned long gpaddr, unsigned long mfn,
+		unsigned long new_gpaddr, unsigned int flags);
+void gnttab_mark_dirty(struct domain *d, unsigned long l);
+#define gnttab_create_status_page(d, t, i) (0)
+#define gnttab_create_shared_page(d, t, i) (0)
+#define gnttab_shared_gmfn(d, t, i) (0)
+#define gnttab_status_gmfn(d, t, i) (0)
+#define gnttab_release_host_mappings(domain) 1
+static inline int replace_grant_supported(void)
+{
+    return 1;
+}
+
+#endif /* __ASM_GRANT_TABLE_H__ */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/hardirq.h b/xen/include/asm-arm/hardirq.h
new file mode 100644
index 0000000..9c031a8
--- /dev/null
+++ b/xen/include/asm-arm/hardirq.h
@@ -0,0 +1,28 @@
+#ifndef __ASM_HARDIRQ_H
+#define __ASM_HARDIRQ_H
+
+#include <xen/config.h>
+#include <xen/cache.h>
+#include <xen/smp.h>
+
+typedef struct {
+        unsigned long __softirq_pending;
+        unsigned int __local_irq_count;
+} __cacheline_aligned irq_cpustat_t;
+
+#include <xen/irq_cpustat.h>    /* Standard mappings for irq_cpustat_t above */
+
+#define in_irq() (local_irq_count(smp_processor_id()) != 0)
+
+#define irq_enter()     (local_irq_count(smp_processor_id())++)
+#define irq_exit()      (local_irq_count(smp_processor_id())--)
+
+#endif /* __ASM_HARDIRQ_H */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/hypercall.h b/xen/include/asm-arm/hypercall.h
new file mode 100644
index 0000000..90a87ef
--- /dev/null
+++ b/xen/include/asm-arm/hypercall.h
@@ -0,0 +1,24 @@
+#ifndef __ASM_ARM_HYPERCALL_H__
+#define __ASM_ARM_HYPERCALL_H__
+
+#include <public/domctl.h> /* for arch_do_domctl */
+
+struct vcpu;
+extern long
+arch_do_vcpu_op(
+    int cmd, struct vcpu *v, XEN_GUEST_HANDLE(void) arg);
+
+extern long
+arch_do_sysctl(
+    struct xen_sysctl *op,
+    XEN_GUEST_HANDLE(xen_sysctl_t) u_sysctl);
+
+#endif /* __ASM_ARM_HYPERCALL_H__ */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/init.h b/xen/include/asm-arm/init.h
new file mode 100644
index 0000000..5f44929
--- /dev/null
+++ b/xen/include/asm-arm/init.h
@@ -0,0 +1,12 @@
+#ifndef _XEN_ASM_INIT_H
+#define _XEN_ASM_INIT_H
+
+#endif /* _XEN_ASM_INIT_H */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/io.h b/xen/include/asm-arm/io.h
new file mode 100644
index 0000000..1babbab
--- /dev/null
+++ b/xen/include/asm-arm/io.h
@@ -0,0 +1,12 @@
+#ifndef _ASM_IO_H
+#define _ASM_IO_H
+
+#endif
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/iocap.h b/xen/include/asm-arm/iocap.h
new file mode 100644
index 0000000..f647f30
--- /dev/null
+++ b/xen/include/asm-arm/iocap.h
@@ -0,0 +1,20 @@
+#ifndef __X86_IOCAP_H__
+#define __X86_IOCAP_H__
+
+#define cache_flush_permitted(d)                        \
+    (!rangeset_is_empty((d)->iomem_caps))
+
+#define multipage_allocation_permitted(d, order)        \
+    (((order) <= 9) || /* allow 2MB superpages */       \
+     !rangeset_is_empty((d)->iomem_caps))
+
+#endif
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/multicall.h b/xen/include/asm-arm/multicall.h
new file mode 100644
index 0000000..c800940
--- /dev/null
+++ b/xen/include/asm-arm/multicall.h
@@ -0,0 +1,23 @@
+#ifndef __ASM_ARM_MULTICALL_H__
+#define __ASM_ARM_MULTICALL_H__
+
+#define do_multicall_call(_call)                             \
+    do {                                                     \
+        __asm__ __volatile__ (                               \
+            ".word 0xe7f000f0@; do_multicall_call\n"         \
+            "    mov r0,#0; @ do_multicall_call\n"           \
+            "    str r0, [r0];\n"                            \
+            :                                                \
+            :                                                \
+            : );                                             \
+    } while ( 0 )
+
+#endif /* __ASM_ARM_MULTICALL_H__ */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/nmi.h b/xen/include/asm-arm/nmi.h
new file mode 100644
index 0000000..e0f19f9
--- /dev/null
+++ b/xen/include/asm-arm/nmi.h
@@ -0,0 +1,15 @@
+#ifndef ASM_NMI_H
+#define ASM_NMI_H
+
+#define register_guest_nmi_callback(a)  (-ENOSYS)
+#define unregister_guest_nmi_callback() (-ENOSYS)
+
+#endif /* ASM_NMI_H */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/numa.h b/xen/include/asm-arm/numa.h
new file mode 100644
index 0000000..cffee5c
--- /dev/null
+++ b/xen/include/asm-arm/numa.h
@@ -0,0 +1,21 @@
+#ifndef __ARCH_ARM_NUMA_H
+#define __ARCH_ARM_NUMA_H
+
+/* Fake one node for now... */
+#define cpu_to_node(cpu) 0
+#define node_to_cpumask(node)	(cpu_online_map)
+
+static inline __attribute__((pure)) int phys_to_nid(paddr_t addr)
+{
+        return 0;
+}
+
+#endif /* __ARCH_ARM_NUMA_H */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/paging.h b/xen/include/asm-arm/paging.h
new file mode 100644
index 0000000..4dc340f
--- /dev/null
+++ b/xen/include/asm-arm/paging.h
@@ -0,0 +1,13 @@
+#ifndef _XEN_PAGING_H
+#define _XEN_PAGING_H
+
+#endif /* XEN_PAGING_H */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/percpu.h b/xen/include/asm-arm/percpu.h
new file mode 100644
index 0000000..9d369eb
--- /dev/null
+++ b/xen/include/asm-arm/percpu.h
@@ -0,0 +1,28 @@
+#ifndef __ARM_PERCPU_H__
+#define __ARM_PERCPU_H__
+
+#ifndef __ASSEMBLY__
+extern char __per_cpu_start[], __per_cpu_data_end[];
+extern unsigned long __per_cpu_offset[NR_CPUS];
+void percpu_init_areas(void);
+#endif
+
+/* Separate out the type, so (int[3], foo) works. */
+#define __DEFINE_PER_CPU(type, name, suffix)                    \
+    __attribute__((__section__(".bss.percpu" #suffix)))         \
+    __typeof__(type) per_cpu_##name
+
+#define per_cpu(var, cpu) ((&per_cpu__##var)[cpu?0:0])
+#define __get_cpu_var(var) per_cpu__##var
+
+#define DECLARE_PER_CPU(type, name) extern __typeof__(type) per_cpu__##name
+
+#endif /* __ARM_PERCPU_H__ */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/processor.h b/xen/include/asm-arm/processor.h
new file mode 100644
index 0000000..1f85d31
--- /dev/null
+++ b/xen/include/asm-arm/processor.h
@@ -0,0 +1,269 @@
+#ifndef __ASM_ARM_PROCESSOR_H
+#define __ASM_ARM_PROCESSOR_H
+
+#include <asm/cpregs.h>
+
+/* PSR bits (CPSR, SPSR)*/
+
+/* 0-4: Mode */
+#define PSR_MODE_MASK 0x1f
+#define PSR_MODE_USR 0x10
+#define PSR_MODE_FIQ 0x11
+#define PSR_MODE_IRQ 0x12
+#define PSR_MODE_SVC 0x13
+#define PSR_MODE_MON 0x16
+#define PSR_MODE_ABT 0x17
+#define PSR_MODE_HYP 0x1a
+#define PSR_MODE_UND 0x1b
+#define PSR_MODE_SYS 0x1f
+
+#define PSR_THUMB        (1<<5)        /* Thumb Mode enable */
+#define PSR_FIQ_MASK        (1<<6)        /* Fast Interrupt mask */
+#define PSR_IRQ_MASK        (1<<7)        /* Interrupt mask */
+#define PSR_ABT_MASK         (1<<8)        /* Asynchronous Abort mask */
+#define PSR_BIG_ENDIAN        (1<<9)        /* Big Endian Mode */
+#define PSR_JAZELLE        (1<<24)        /* Jazelle Mode */
+
+/* TTBCR Translation Table Base Control Register */
+#define TTBCR_N_MASK 0x07
+#define TTBCR_N_16KB 0x00
+#define TTBCR_N_8KB  0x01
+#define TTBCR_N_4KB  0x02
+#define TTBCR_N_2KB  0x03
+#define TTBCR_N_1KB  0x04
+
+/* SCTLR System Control Register. */
+/* HSCTLR is a subset of this. */
+#define SCTLR_TE        (1<<30)
+#define SCTLR_AFE        (1<<29)
+#define SCTLR_TRE        (1<<28)
+#define SCTLR_NMFI        (1<<27)
+#define SCTLR_EE        (1<<25)
+#define SCTLR_VE        (1<<24)
+#define SCTLR_U                (1<<22)
+#define SCTLR_FI        (1<<21)
+#define SCTLR_WXN        (1<<19)
+#define SCTLR_HA        (1<<17)
+#define SCTLR_RR        (1<<14)
+#define SCTLR_V                (1<<13)
+#define SCTLR_I                (1<<12)
+#define SCTLR_Z                (1<<11)
+#define SCTLR_SW        (1<<10)
+#define SCTLR_B                (1<<7)
+#define SCTLR_C                (1<<2)
+#define SCTLR_A                (1<<1)
+#define SCTLR_M                (1<<0)
+
+#define SCTLR_BASE        0x00c50078
+#define HSCTLR_BASE        0x30c51878
+
+/* HCR Hyp Configuration Register */
+#define HCR_TGE                (1<<27)
+#define HCR_TVM                (1<<26)
+#define HCR_TTLB        (1<<25)
+#define HCR_TPU                (1<<24)
+#define HCR_TPC                (1<<23)
+#define HCR_TSW                (1<<22)
+#define HCR_TAC                (1<<21)
+#define HCR_TIDCP        (1<<20)
+#define HCR_TSC                (1<<19)
+#define HCR_TID3        (1<<18)
+#define HCR_TID2        (1<<17)
+#define HCR_TID1        (1<<16)
+#define HCR_TID0        (1<<15)
+#define HCR_TWE                (1<<14)
+#define HCR_TWI                (1<<13)
+#define HCR_DC                (1<<12)
+#define HCR_BSU_MASK        (3<<10)
+#define HCR_FB                (1<<9)
+#define HCR_VA                (1<<8)
+#define HCR_VI                (1<<7)
+#define HCR_VF                (1<<6)
+#define HCR_AMO                (1<<5)
+#define HCR_IMO                (1<<4)
+#define HCR_FMO                (1<<3)
+#define HCR_PTW                (1<<2)
+#define HCR_SWIO        (1<<1)
+#define HCR_VM                (1<<0)
+
+#define HSR_EC_WFI_WFE              0x01
+#define HSR_EC_CP15_32              0x03
+#define HSR_EC_CP15_64              0x04
+#define HSR_EC_CP14_32              0x05
+#define HSR_EC_CP14_DBG             0x06
+#define HSR_EC_CP                   0x07
+#define HSR_EC_CP10                 0x08
+#define HSR_EC_JAZELLE              0x09
+#define HSR_EC_BXJ                  0x0a
+#define HSR_EC_CP14_64              0x0c
+#define HSR_EC_SVC                  0x11
+#define HSR_EC_HVC                  0x12
+#define HSR_EC_INSTR_ABORT_GUEST    0x20
+#define HSR_EC_INSTR_ABORT_HYP      0x21
+#define HSR_EC_DATA_ABORT_GUEST     0x24
+#define HSR_EC_DATA_ABORT_HYP       0x25
+
+#ifndef __ASSEMBLY__
+union hsr {
+    uint32_t bits;
+    struct {
+        unsigned long iss:25;  /* Instruction Specific Syndrome */
+        unsigned long len:1;   /* Instruction length */
+        unsigned long ec:6;    /* Exception Class */
+    };
+
+    struct hsr_cp32 {
+        unsigned long read:1;  /* Direction */
+        unsigned long crm:4;   /* CRm */
+        unsigned long reg:4;   /* Rt */
+        unsigned long sbzp:1;
+        unsigned long crn:4;   /* CRn */
+        unsigned long op1:3;   /* Op1 */
+        unsigned long op2:3;   /* Op2 */
+        unsigned long cc:4;    /* Condition Code */
+        unsigned long ccvalid:1;/* CC Valid */
+        unsigned long len:1;   /* Instruction length */
+        unsigned long ec:6;    /* Exception Class */
+    } cp32; /* HSR_EC_CP15_32, CP14_32, CP10 */
+
+    struct hsr_cp64 {
+        unsigned long read:1;   /* Direction */
+        unsigned long crm:4;    /* CRm */
+        unsigned long reg1:4;   /* Rt1 */
+        unsigned long sbzp1:1;
+        unsigned long reg2:4;   /* Rt2 */
+        unsigned long sbzp2:2;
+        unsigned long op1:4;   /* Op1 */
+        unsigned long cc:4;    /* Condition Code */
+        unsigned long ccvalid:1;/* CC Valid */
+        unsigned long len:1;   /* Instruction length */
+        unsigned long ec:6;    /* Exception Class */
+    } cp64; /* HSR_EC_CP15_64, HSR_EC_CP14_64 */
+
+    struct hsr_dabt {
+        unsigned long dfsc:6;  /* Data Fault Status Code */
+        unsigned long write:1; /* Write / not Read */
+        unsigned long s1ptw:1; /* */
+        unsigned long cache:1; /* Cache Maintenance */
+        unsigned long eat:1;   /* External Abort Type */
+        unsigned long sbzp0:6;
+        unsigned long reg:4;   /* Register */
+        unsigned long sbzp1:1;
+        unsigned long sign:1;  /* Sign extend */
+        unsigned long size:2;  /* Access Size */
+        unsigned long valid:1; /* Syndrome Valid */
+        unsigned long len:1;   /* Instruction length */
+        unsigned long ec:6;    /* Exception Class */
+    } dabt; /* HSR_EC_DATA_ABORT_* */
+};
+#endif
+
+/* HSR.EC == HSR_CP{15,14,10}_32 */
+#define HSR_CP32_OP2_MASK (0x000e0000)
+#define HSR_CP32_OP2_SHIFT (17)
+#define HSR_CP32_OP1_MASK (0x0001c000)
+#define HSR_CP32_OP1_SHIFT (14)
+#define HSR_CP32_CRN_MASK (0x00003c00)
+#define HSR_CP32_CRN_SHIFT (10)
+#define HSR_CP32_CRM_MASK (0x0000001e)
+#define HSR_CP32_CRM_SHIFT (1)
+#define HSR_CP32_REGS_MASK (HSR_CP32_OP1_MASK|HSR_CP32_OP2_MASK|\
+                            HSR_CP32_CRN_MASK|HSR_CP32_CRM_MASK)
+
+/* HSR.EC == HSR_CP{15,14}_64 */
+#define HSR_CP64_OP1_MASK (0x000f0000)
+#define HSR_CP64_OP1_SHIFT (16)
+#define HSR_CP64_CRM_MASK (0x0000001e)
+#define HSR_CP64_CRM_SHIFT (1)
+#define HSR_CP64_REGS_MASK (HSR_CP64_OP1_MASK|HSR_CP64_CRM_MASK)
+
+/* Physical Address Register */
+#define PAR_F           (1<<0)
+
+/* .... If F == 1 */
+#define PAR_FSC_SHIFT   (1)
+#define PAR_FSC_MASK    (0x3f<<PAR_FSC_SHIFT)
+#define PAR_STAGE21     (1<<8)     /* Stage 2 Fault During Stage 1 Walk */
+#define PAR_STAGE2      (1<<9)     /* Stage 2 Fault */
+
+/* If F == 0 */
+#define PAR_MAIR_SHIFT  56                       /* Memory Attributes */
+#define PAR_MAIR_MASK   (0xffLL<<PAR_MAIR_SHIFT)
+#define PAR_NS          (1<<9)                   /* Non-Secure */
+#define PAR_SH_SHIFT    7                        /* Shareability */
+#define PAR_SH_MASK     (3<<PAR_SH_SHIFT)
+
+/* Fault Status Register */
+/*
+ * 543210 BIT
+ * 00XXLL -- XX Fault Level LL
+ * ..01LL -- Translation Fault LL
+ * ..10LL -- Access Fault LL
+ * ..11LL -- Permission Fault LL
+ * 01xxxx -- Abort/Parity
+ * 10xxxx -- Other
+ * 11xxxx -- Implementation Defined
+ */
+#define FSC_TYPE_MASK (0x3<<4)
+#define FSC_TYPE_FAULT (0x00<<4)
+#define FSC_TYPE_ABT   (0x01<<4)
+#define FSC_TYPE_OTH   (0x02<<4)
+#define FSC_TYPE_IMPL  (0x03<<4)
+
+#define FSC_FLT_TRANS  (0x04)
+#define FSC_FLT_ACCESS (0x08)
+#define FSC_FLT_PERM   (0x0c)
+#define FSC_SEA        (0x10) /* Synchronous External Abort */
+#define FSC_SPE        (0x18) /* Memory Access Synchronous Parity Error */
+#define FSC_APE        (0x11) /* Memory Access Asynchronous Parity Error */
+#define FSC_SEATT      (0x14) /* Sync. Ext. Abort Translation Table */
+#define FSC_SPETT      (0x1c) /* Sync. Parity. Error Translation Table */
+#define FSC_AF         (0x21) /* Alignment Fault */
+#define FSC_DE         (0x22) /* Debug Event */
+#define FSC_LKD        (0x34) /* Lockdown Abort */
+#define FSC_CPR        (0x3a) /* Coprocossor Abort */
+
+#define FSC_LL_MASK    (0x03<<0)
+
+/* Time counter hypervisor control register */
+#define CNTHCTL_PA      (1u<<0)  /* Kernel/user access to physical counter */
+#define CNTHCTL_TA      (1u<<1)  /* Kernel/user access to CNTP timer */
+
+/* Timer control registers */
+#define CNTx_CTL_ENABLE   (1u<<0)  /* Enable timer */
+#define CNTx_CTL_MASK     (1u<<1)  /* Mask IRQ */
+#define CNTx_CTL_PENDING  (1u<<2)  /* IRQ pending */
+
+/* CPUID bits */
+#define ID_PFR1_GT_MASK  0x000F0000  /* Generic Timer interface support */
+#define ID_PFR1_GT_v1    0x00010000
+
+#define MSR(reg,val)        asm volatile ("msr "#reg", %0\n" : : "r" (val))
+#define MRS(val,reg)        asm volatile ("mrs %0,"#reg"\n" : "=r" (v))
+
+#ifndef __ASSEMBLY__
+extern uint32_t hyp_traps_vector[8];
+
+void panic_PAR(uint64_t par, const char *when);
+
+void show_execution_state(struct cpu_user_regs *regs);
+void show_registers(struct cpu_user_regs *regs);
+//#define dump_execution_state() run_in_exception_handler(show_execution_state)
+#define dump_execution_state() asm volatile (".word 0xe7f000f0\n"); /* XXX */
+
+#define cpu_relax() barrier() /* Could yield? */
+
+/* All a bit UP for the moment */
+#define cpu_to_core(_cpu)   (0)
+#define cpu_to_socket(_cpu) (0)
+
+#endif /* __ASSEMBLY__ */
+#endif /* __ASM_ARM_PROCESSOR_H */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/regs.h b/xen/include/asm-arm/regs.h
new file mode 100644
index 0000000..ee095bf
--- /dev/null
+++ b/xen/include/asm-arm/regs.h
@@ -0,0 +1,43 @@
+#ifndef __ARM_REGS_H__
+#define __ARM_REGS_H__
+
+#include <xen/types.h>
+#include <public/xen.h>
+#include <asm/processor.h>
+
+#define psr_mode(psr,m) (((psr) & PSR_MODE_MASK) == m)
+
+#define usr_mode(r)     psr_mode((r)->cpsr,PSR_MODE_USR)
+#define fiq_mode(r)     psr_mode((r)->cpsr,PSR_MODE_FIQ)
+#define irq_mode(r)     psr_mode((r)->cpsr,PSR_MODE_IRQ)
+#define svc_mode(r)     psr_mode((r)->cpsr,PSR_MODE_SVC)
+#define mon_mode(r)     psr_mode((r)->cpsr,PSR_MODE_MON)
+#define abt_mode(r)     psr_mode((r)->cpsr,PSR_MODE_ABT)
+#define hyp_mode(r)     psr_mode((r)->cpsr,PSR_MODE_HYP)
+#define und_mode(r)     psr_mode((r)->cpsr,PSR_MODE_UND)
+#define sys_mode(r)     psr_mode((r)->cpsr,PSR_MODE_SYS)
+
+#define guest_mode(r)                                                         \
+({                                                                            \
+    unsigned long diff = (char *)guest_cpu_user_regs() - (char *)(r);         \
+    /* Frame pointer must point into current CPU stack. */                    \
+    ASSERT(diff < STACK_SIZE);                                                \
+    /* If not a guest frame, it must be a hypervisor frame. */                \
+    ASSERT((diff == 0) || hyp_mode(r));                                       \
+    /* Return TRUE if it's a guest frame. */                                  \
+    (diff == 0);                                                              \
+})
+
+#define return_reg(v) ((v)->arch.user_regs.r0)
+
+#define CTXT_SWITCH_STACK_BYTES (sizeof(struct cpu_user_regs))
+
+#endif /* __ARM_REGS_H__ */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/setup.h b/xen/include/asm-arm/setup.h
new file mode 100644
index 0000000..c27d438
--- /dev/null
+++ b/xen/include/asm-arm/setup.h
@@ -0,0 +1,16 @@
+#ifndef __ARM_SETUP_H_
+#define __ARM_SETUP_H_
+
+#include <public/version.h>
+
+void arch_get_xen_caps(xen_capabilities_info_t *info);
+
+#endif
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/smp.h b/xen/include/asm-arm/smp.h
new file mode 100644
index 0000000..9cdd87f
--- /dev/null
+++ b/xen/include/asm-arm/smp.h
@@ -0,0 +1,25 @@
+#ifndef __ASM_SMP_H
+#define __ASM_SMP_H
+
+#ifndef __ASSEMBLY__
+#include <xen/config.h>
+#include <xen/cpumask.h>
+#include <asm/current.h>
+#endif
+
+DECLARE_PER_CPU(cpumask_var_t, cpu_sibling_mask);
+DECLARE_PER_CPU(cpumask_var_t, cpu_core_mask);
+
+#define cpu_is_offline(cpu) unlikely(!cpu_online(cpu))
+
+#define raw_smp_processor_id() (get_processor_id())
+
+#endif
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/softirq.h b/xen/include/asm-arm/softirq.h
new file mode 100644
index 0000000..536af38
--- /dev/null
+++ b/xen/include/asm-arm/softirq.h
@@ -0,0 +1,15 @@
+#ifndef __ASM_SOFTIRQ_H__
+#define __ASM_SOFTIRQ_H__
+
+#define VGIC_SOFTIRQ        (NR_COMMON_SOFTIRQS + 0)
+#define NR_ARCH_SOFTIRQS       1
+
+#endif /* __ASM_SOFTIRQ_H__ */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/spinlock.h b/xen/include/asm-arm/spinlock.h
new file mode 100644
index 0000000..b1825c9
--- /dev/null
+++ b/xen/include/asm-arm/spinlock.h
@@ -0,0 +1,144 @@
+#ifndef __ASM_SPINLOCK_H
+#define __ASM_SPINLOCK_H
+
+#include <xen/config.h>
+#include <xen/lib.h>
+
+static inline void dsb_sev(void)
+{
+    __asm__ __volatile__ (
+        "dsb\n"
+        "sev\n"
+        );
+}
+
+typedef struct {
+    volatile unsigned int lock;
+} raw_spinlock_t;
+
+#define _RAW_SPIN_LOCK_UNLOCKED { 0 }
+
+#define _raw_spin_is_locked(x)          ((x)->lock != 0)
+
+static always_inline void _raw_spin_unlock(raw_spinlock_t *lock)
+{
+    ASSERT(_raw_spin_is_locked(lock));
+
+    smp_mb();
+
+    __asm__ __volatile__(
+"   str     %1, [%0]\n"
+    :
+    : "r" (&lock->lock), "r" (0)
+    : "cc");
+
+    dsb_sev();
+}
+
+static always_inline int _raw_spin_trylock(raw_spinlock_t *lock)
+{
+    unsigned long tmp;
+
+    __asm__ __volatile__(
+"   ldrex   %0, [%1]\n"
+"   teq     %0, #0\n"
+"   strexeq %0, %2, [%1]"
+    : "=&r" (tmp)
+    : "r" (&lock->lock), "r" (1)
+    : "cc");
+
+    if (tmp == 0) {
+        smp_mb();
+        return 1;
+    } else {
+        return 0;
+    }
+}
+
+typedef struct {
+    volatile unsigned int lock;
+} raw_rwlock_t;
+
+#define _RAW_RW_LOCK_UNLOCKED { 0 }
+
+static always_inline int _raw_read_trylock(raw_rwlock_t *rw)
+{
+    unsigned long tmp, tmp2 = 1;
+
+    __asm__ __volatile__(
+"1: ldrex   %0, [%2]\n"
+"   adds    %0, %0, #1\n"
+"   strexpl %1, %0, [%2]\n"
+    : "=&r" (tmp), "+r" (tmp2)
+    : "r" (&rw->lock)
+    : "cc");
+
+    smp_mb();
+    return tmp2 == 0;
+}
+
+static always_inline int _raw_write_trylock(raw_rwlock_t *rw)
+{
+    unsigned long tmp;
+
+    __asm__ __volatile__(
+"1: ldrex   %0, [%1]\n"
+"   teq     %0, #0\n"
+"   strexeq %0, %2, [%1]"
+    : "=&r" (tmp)
+    : "r" (&rw->lock), "r" (0x80000000)
+    : "cc");
+
+    if (tmp == 0) {
+        smp_mb();
+        return 1;
+    } else {
+        return 0;
+    }
+}
+
+static inline void _raw_read_unlock(raw_rwlock_t *rw)
+{
+    unsigned long tmp, tmp2;
+
+    smp_mb();
+
+    __asm__ __volatile__(
+"1: ldrex   %0, [%2]\n"
+"   sub     %0, %0, #1\n"
+"   strex   %1, %0, [%2]\n"
+"   teq     %1, #0\n"
+"   bne     1b"
+    : "=&r" (tmp), "=&r" (tmp2)
+    : "r" (&rw->lock)
+    : "cc");
+
+    if (tmp == 0)
+        dsb_sev();
+}
+
+static inline void _raw_write_unlock(raw_rwlock_t *rw)
+{
+    smp_mb();
+
+    __asm__ __volatile__(
+    "str    %1, [%0]\n"
+    :
+    : "r" (&rw->lock), "r" (0)
+    : "cc");
+
+    dsb_sev();
+}
+
+#define _raw_rw_is_locked(x) ((x)->lock != 0)
+#define _raw_rw_is_write_locked(x) ((x)->lock == 0x80000000)
+
+#endif /* __ASM_SPINLOCK_H */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/string.h b/xen/include/asm-arm/string.h
new file mode 100644
index 0000000..f2d643d
--- /dev/null
+++ b/xen/include/asm-arm/string.h
@@ -0,0 +1,38 @@
+#ifndef __ARM_STRING_H__
+#define __ARM_STRING_H__
+
+#include <xen/config.h>
+
+#define __HAVE_ARCH_MEMCPY
+extern void * memcpy(void *, const void *, __kernel_size_t);
+
+/* Some versions of gcc don't have this builtin. It's non-critical anyway. */
+#define __HAVE_ARCH_MEMMOVE
+extern void *memmove(void *dest, const void *src, size_t n);
+
+#define __HAVE_ARCH_MEMSET
+extern void * memset(void *, int, __kernel_size_t);
+
+extern void __memzero(void *ptr, __kernel_size_t n);
+
+#define memset(p,v,n)                                                   \
+        ({                                                              \
+                void *__p = (p); size_t __n = n;                        \
+                if ((__n) != 0) {                                       \
+                        if (__builtin_constant_p((v)) && (v) == 0)      \
+                                __memzero((__p),(__n));                 \
+                        else                                            \
+                                memset((__p),(v),(__n));                \
+                }                                                       \
+                (__p);                                                  \
+        })
+
+#endif /* __ARM_STRING_H__ */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/system.h b/xen/include/asm-arm/system.h
new file mode 100644
index 0000000..731d89f
--- /dev/null
+++ b/xen/include/asm-arm/system.h
@@ -0,0 +1,202 @@
+/* Portions taken from Linux arch arm */
+#ifndef __ASM_SYSTEM_H
+#define __ASM_SYSTEM_H
+
+#include <xen/lib.h>
+#include <asm/processor.h>
+
+#define nop() \
+    asm volatile ( "nop" )
+
+#define xchg(ptr,x) \
+        ((__typeof__(*(ptr)))__xchg((unsigned long)(x),(ptr),sizeof(*(ptr))))
+
+#define isb() __asm__ __volatile__ ("isb" : : : "memory")
+#define dsb() __asm__ __volatile__ ("dsb" : : : "memory")
+#define dmb() __asm__ __volatile__ ("dmb" : : : "memory")
+
+#define mb()            dsb()
+#define rmb()           dsb()
+#define wmb()           mb()
+
+#define smp_mb()        dmb()
+#define smp_rmb()       dmb()
+#define smp_wmb()       dmb()
+
+/*
+ * This is used to ensure the compiler did actually allocate the register we
+ * asked it for some inline assembly sequences.  Apparently we can't trust
+ * the compiler from one version to another so a bit of paranoia won't hurt.
+ * This string is meant to be concatenated with the inline asm string and
+ * will cause compilation to stop on mismatch.
+ * (for details, see gcc PR 15089)
+ */
+#define __asmeq(x, y)  ".ifnc " x "," y " ; .err ; .endif\n\t"
+
+extern void __bad_xchg(volatile void *, int);
+
+static inline unsigned long __xchg(unsigned long x, volatile void *ptr, int size)
+{
+        unsigned long ret;
+        unsigned int tmp;
+
+        smp_mb();
+
+        switch (size) {
+        case 1:
+                asm volatile("@ __xchg1\n"
+                "1:     ldrexb  %0, [%3]\n"
+                "       strexb  %1, %2, [%3]\n"
+                "       teq     %1, #0\n"
+                "       bne     1b"
+                        : "=&r" (ret), "=&r" (tmp)
+                        : "r" (x), "r" (ptr)
+                        : "memory", "cc");
+                break;
+        case 4:
+                asm volatile("@ __xchg4\n"
+                "1:     ldrex   %0, [%3]\n"
+                "       strex   %1, %2, [%3]\n"
+                "       teq     %1, #0\n"
+                "       bne     1b"
+                        : "=&r" (ret), "=&r" (tmp)
+                        : "r" (x), "r" (ptr)
+                        : "memory", "cc");
+                break;
+        default:
+                __bad_xchg(ptr, size), ret = 0;
+                break;
+        }
+        smp_mb();
+
+        return ret;
+}
+
+/*
+ * Atomic compare and exchange.  Compare OLD with MEM, if identical,
+ * store NEW in MEM.  Return the initial value in MEM.  Success is
+ * indicated by comparing RETURN with OLD.
+ */
+
+extern void __bad_cmpxchg(volatile void *ptr, int size);
+
+static always_inline unsigned long __cmpxchg(
+    volatile void *ptr, unsigned long old, unsigned long new, int size)
+{
+    unsigned long /*long*/ oldval, res;
+
+    switch (size) {
+    case 1:
+        do {
+            asm volatile("@ __cmpxchg1\n"
+                         "       ldrexb  %1, [%2]\n"
+                         "       mov     %0, #0\n"
+                         "       teq     %1, %3\n"
+                         "       strexbeq %0, %4, [%2]\n"
+                         : "=&r" (res), "=&r" (oldval)
+                         : "r" (ptr), "Ir" (old), "r" (new)
+                         : "memory", "cc");
+        } while (res);
+        break;
+    case 2:
+        do {
+            asm volatile("@ __cmpxchg2\n"
+                         "       ldrexh  %1, [%2]\n"
+                         "       mov     %0, #0\n"
+                         "       teq     %1, %3\n"
+                         "       strexheq %0, %4, [%2]\n"
+                         : "=&r" (res), "=&r" (oldval)
+                         : "r" (ptr), "Ir" (old), "r" (new)
+                         : "memory", "cc");
+        } while (res);
+        break;
+    case 4:
+        do {
+            asm volatile("@ __cmpxchg4\n"
+                         "       ldrex   %1, [%2]\n"
+                         "       mov     %0, #0\n"
+                         "       teq     %1, %3\n"
+                         "       strexeq %0, %4, [%2]\n"
+                         : "=&r" (res), "=&r" (oldval)
+                         : "r" (ptr), "Ir" (old), "r" (new)
+                         : "memory", "cc");
+        } while (res);
+        break;
+#if 0
+    case 8:
+        do {
+            asm volatile("@ __cmpxchg8\n"
+                         "       ldrexd   %1, [%2]\n"
+                         "       mov      %0, #0\n"
+                         "       teq      %1, %3\n"
+                         "       strexdeq %0, %4, [%2]\n"
+                         : "=&r" (res), "=&r" (oldval)
+                         : "r" (ptr), "Ir" (old), "r" (new)
+                         : "memory", "cc");
+        } while (res);
+        break;
+#endif
+    default:
+        __bad_cmpxchg(ptr, size);
+        oldval = 0;
+    }
+
+    return oldval;
+}
+#define cmpxchg(ptr,o,n)                                                \
+    ((__typeof__(*(ptr)))__cmpxchg((ptr),(unsigned long)(o),            \
+                                   (unsigned long)(n),sizeof(*(ptr))))
+
+#define local_irq_disable() asm volatile ( "cpsid i @ local_irq_disable\n" : : : "cc" )
+#define local_irq_enable()  asm volatile ( "cpsie i @ local_irq_enable\n" : : : "cc" )
+
+#define local_save_flags(x)                                      \
+({                                                               \
+    BUILD_BUG_ON(sizeof(x) != sizeof(long));                     \
+    asm volatile ( "mrs %0, cpsr     @ local_save_flags\n"       \
+                  : "=r" (x) :: "memory", "cc" );                \
+})
+#define local_irq_save(x)                                        \
+({                                                               \
+    local_save_flags(x);                                         \
+    local_irq_disable();                                         \
+})
+#define local_irq_restore(x)                                     \
+({                                                               \
+    BUILD_BUG_ON(sizeof(x) != sizeof(long));                     \
+    asm volatile (                                               \
+            "msr     cpsr_c, %0      @ local_irq_restore\n"      \
+            :                                                    \
+            : "r" (flags)                                        \
+            : "memory", "cc");                                   \
+})
+
+static inline int local_irq_is_enabled(void)
+{
+    unsigned long flags;
+    local_save_flags(flags);
+    return !(flags & PSR_IRQ_MASK);
+}
+
+#define local_fiq_enable()  __asm__("cpsie f   @ __stf\n" : : : "memory", "cc")
+#define local_fiq_disable() __asm__("cpsid f   @ __clf\n" : : : "memory", "cc")
+
+#define local_abort_enable() __asm__("cpsie a  @ __sta\n" : : : "memory", "cc")
+#define local_abort_disable() __asm__("cpsid a @ __sta\n" : : : "memory", "cc")
+
+static inline int local_fiq_is_enabled(void)
+{
+    unsigned long flags;
+    local_save_flags(flags);
+    return !!(flags & PSR_FIQ_MASK);
+}
+
+#endif
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/trace.h b/xen/include/asm-arm/trace.h
new file mode 100644
index 0000000..db84541
--- /dev/null
+++ b/xen/include/asm-arm/trace.h
@@ -0,0 +1,12 @@
+#ifndef __ASM_TRACE_H__
+#define __ASM_TRACE_H__
+
+#endif /* __ASM_TRACE_H__ */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/types.h b/xen/include/asm-arm/types.h
new file mode 100644
index 0000000..48864f9
--- /dev/null
+++ b/xen/include/asm-arm/types.h
@@ -0,0 +1,57 @@
+#ifndef __ARM_TYPES_H__
+#define __ARM_TYPES_H__
+
+#ifndef __ASSEMBLY__
+
+#include <xen/config.h>
+
+typedef __signed__ char __s8;
+typedef unsigned char __u8;
+
+typedef __signed__ short __s16;
+typedef unsigned short __u16;
+
+typedef __signed__ int __s32;
+typedef unsigned int __u32;
+
+#if defined(__GNUC__) && !defined(__STRICT_ANSI__)
+typedef __signed__ long long __s64;
+typedef unsigned long long __u64;
+#endif
+
+typedef signed char s8;
+typedef unsigned char u8;
+
+typedef signed short s16;
+typedef unsigned short u16;
+
+typedef signed int s32;
+typedef unsigned int u32;
+
+typedef signed long long s64;
+typedef unsigned long long u64;
+typedef u64 paddr_t;
+#define INVALID_PADDR (~0ULL)
+#define PRIpaddr "016llx"
+
+typedef unsigned long size_t;
+
+typedef char bool_t;
+#define test_and_set_bool(b)   xchg(&(b), 1)
+#define test_and_clear_bool(b) xchg(&(b), 0)
+
+#endif /* __ASSEMBLY__ */
+
+#define BITS_PER_LONG 32
+#define BYTES_PER_LONG 4
+#define LONG_BYTEORDER 2
+
+#endif /* __ARM_TYPES_H__ */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/xenoprof.h b/xen/include/asm-arm/xenoprof.h
new file mode 100644
index 0000000..131ac13
--- /dev/null
+++ b/xen/include/asm-arm/xenoprof.h
@@ -0,0 +1,12 @@
+#ifndef __ASM_XENOPROF_H__
+#define __ASM_XENOPROF_H__
+
+#endif /* __ASM_XENOPROF_H__ */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
new file mode 100644
index 0000000..4d1daa9
--- /dev/null
+++ b/xen/include/public/arch-arm.h
@@ -0,0 +1,125 @@
+/******************************************************************************
+ * arch-arm.h
+ *
+ * Guest OS interface to ARM 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 2011 (C) Citrix Systems
+ */
+
+#ifndef __XEN_PUBLIC_ARCH_ARM_H__
+#define __XEN_PUBLIC_ARCH_ARM_H__
+
+#ifndef __ASSEMBLY__
+#define ___DEFINE_XEN_GUEST_HANDLE(name, type) \
+    typedef struct { type *p; } __guest_handle_ ## name
+
+#define __DEFINE_XEN_GUEST_HANDLE(name, type) \
+    ___DEFINE_XEN_GUEST_HANDLE(name, type);   \
+    ___DEFINE_XEN_GUEST_HANDLE(const_##name, const type)
+#define DEFINE_XEN_GUEST_HANDLE(name)   __DEFINE_XEN_GUEST_HANDLE(name, name)
+#define __XEN_GUEST_HANDLE(name)        __guest_handle_ ## name
+#define XEN_GUEST_HANDLE(name)          __XEN_GUEST_HANDLE(name)
+#define set_xen_guest_handle_raw(hnd, val)  do { (hnd).p = val; } while (0)
+#ifdef __XEN_TOOLS__
+#define get_xen_guest_handle(val, hnd)  do { val = (hnd).p; } while (0)
+#endif
+#define set_xen_guest_handle(hnd, val) set_xen_guest_handle_raw(hnd, val)
+
+struct cpu_user_regs
+{
+    uint32_t r0;
+    uint32_t r1;
+    uint32_t r2;
+    uint32_t r3;
+    uint32_t r4;
+    uint32_t r5;
+    uint32_t r6;
+    uint32_t r7;
+    uint32_t r8;
+    uint32_t r9;
+    uint32_t r10;
+    union {
+	uint32_t r11;
+	uint32_t fp;
+    };
+    uint32_t r12;
+
+    uint32_t sp; /* r13 - SP: Valid for Hyp. frames only, o/w banked (see below) */
+    uint32_t lr; /* r14 - LR: Valid for Hyp. Same physical register as lr_usr. */
+
+    uint32_t pc; /* Return IP */
+    uint32_t cpsr; /* Return mode */
+    uint32_t pad0; /* Doubleword-align the kernel half of the frame */
+
+    /* Outer guest frame only from here on... */
+
+    uint32_t r8_fiq, r9_fiq, r10_fiq, r11_fiq, r12_fiq;
+
+    uint32_t sp_usr, sp_svc, sp_abt, sp_und, sp_irq, sp_fiq;
+    uint32_t lr_usr, lr_svc, lr_abt, lr_und, lr_irq, lr_fiq;
+
+    uint32_t spsr_svc, spsr_abt, spsr_und, spsr_irq, spsr_fiq;
+};
+typedef struct cpu_user_regs cpu_user_regs_t;
+DEFINE_XEN_GUEST_HANDLE(cpu_user_regs_t);
+
+typedef uint64_t xen_pfn_t;
+#define PRI_xen_pfn PRIx64
+
+/* Maximum number of virtual CPUs in legacy multi-processor guests. */
+/* Only one. All other VCPUS must use VCPUOP_register_vcpu_info */
+#define XEN_LEGACY_MAX_VCPUS 1
+
+typedef uint32_t xen_ulong_t;
+
+struct vcpu_guest_context {
+    struct cpu_user_regs user_regs;         /* User-level CPU registers     */
+    union {
+	uint32_t reg[16];
+	struct {
+	    uint32_t __pad[12];
+	    uint32_t sp; /* r13 */
+	    uint32_t lr; /* r14 */
+	    uint32_t pc; /* r15 */
+	};
+    };
+};
+typedef struct vcpu_guest_context vcpu_guest_context_t;
+DEFINE_XEN_GUEST_HANDLE(vcpu_guest_context_t);
+
+struct arch_vcpu_info { };
+typedef struct arch_vcpu_info arch_vcpu_info_t;
+
+struct arch_shared_info { };
+typedef struct arch_shared_info arch_shared_info_t;
+#endif
+
+#endif /*  __XEN_PUBLIC_ARCH_ARM_H__ */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
index fde9fa5..7196400 100644
--- a/xen/include/public/xen.h
+++ b/xen/include/public/xen.h
@@ -33,6 +33,8 @@
 #include "arch-x86/xen.h"
 #elif defined(__ia64__)
 #include "arch-ia64.h"
+#elif defined(__arm__)
+#include "arch-arm.h"
 #else
 #error "Unsupported architecture"
 #endif
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 13:14:30 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 13: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.xensource.com>)
	id 1RZ0HE-0002Mh-5W; Fri, 09 Dec 2011 13:14:12 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RZ0HC-0002I6-Gv
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 13:14:11 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1323436384!4910711!6
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMTkxNzY=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30724 invoked from network); 9 Dec 2011 13:13:19 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 13:13:19 -0000
X-IronPort-AV: E=Sophos;i="4.71,325,1320642000"; d="scan'208";a="173546260"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 08:13:18 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 08:13:17 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pB9DCpDt008248;
	Fri, 9 Dec 2011 05:13:05 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 9 Dec 2011 13:13:12 +0000
Message-ID: <1323436408-16335-9-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1112091208420.3517@kaball-desktop>
References: <alpine.DEB.2.00.1112091208420.3517@kaball-desktop>
MIME-Version: 1.0
Cc: keir.xen@gmail.com, Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, JBeulich@suse.com,
	Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v2 09/25] arm: header files
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

A simple implementation of everything under asm-arm and arch-arm.h; some
of these files are shamelessly taken from Linux.


Changes in v2:

- remove div64.


Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
---
 xen/include/asm-arm/atomic.h      |  212 +++++++++++++++++++++++++++++
 xen/include/asm-arm/bitops.h      |  195 +++++++++++++++++++++++++++
 xen/include/asm-arm/bug.h         |   15 ++
 xen/include/asm-arm/byteorder.h   |   16 +++
 xen/include/asm-arm/cache.h       |   20 +++
 xen/include/asm-arm/config.h      |  122 +++++++++++++++++
 xen/include/asm-arm/cpregs.h      |  207 ++++++++++++++++++++++++++++
 xen/include/asm-arm/current.h     |   60 ++++++++
 xen/include/asm-arm/debugger.h    |   15 ++
 xen/include/asm-arm/delay.h       |   15 ++
 xen/include/asm-arm/desc.h        |   12 ++
 xen/include/asm-arm/div64.h       |  235 ++++++++++++++++++++++++++++++++
 xen/include/asm-arm/elf.h         |   33 +++++
 xen/include/asm-arm/event.h       |   41 ++++++
 xen/include/asm-arm/flushtlb.h    |   31 +++++
 xen/include/asm-arm/grant_table.h |   35 +++++
 xen/include/asm-arm/hardirq.h     |   28 ++++
 xen/include/asm-arm/hypercall.h   |   24 ++++
 xen/include/asm-arm/init.h        |   12 ++
 xen/include/asm-arm/io.h          |   12 ++
 xen/include/asm-arm/iocap.h       |   20 +++
 xen/include/asm-arm/multicall.h   |   23 +++
 xen/include/asm-arm/nmi.h         |   15 ++
 xen/include/asm-arm/numa.h        |   21 +++
 xen/include/asm-arm/paging.h      |   13 ++
 xen/include/asm-arm/percpu.h      |   28 ++++
 xen/include/asm-arm/processor.h   |  269 +++++++++++++++++++++++++++++++++++++
 xen/include/asm-arm/regs.h        |   43 ++++++
 xen/include/asm-arm/setup.h       |   16 +++
 xen/include/asm-arm/smp.h         |   25 ++++
 xen/include/asm-arm/softirq.h     |   15 ++
 xen/include/asm-arm/spinlock.h    |  144 ++++++++++++++++++++
 xen/include/asm-arm/string.h      |   38 +++++
 xen/include/asm-arm/system.h      |  202 ++++++++++++++++++++++++++++
 xen/include/asm-arm/trace.h       |   12 ++
 xen/include/asm-arm/types.h       |   57 ++++++++
 xen/include/asm-arm/xenoprof.h    |   12 ++
 xen/include/public/arch-arm.h     |  125 +++++++++++++++++
 xen/include/public/xen.h          |    2 +
 39 files changed, 2420 insertions(+), 0 deletions(-)
 create mode 100644 xen/include/asm-arm/atomic.h
 create mode 100644 xen/include/asm-arm/bitops.h
 create mode 100644 xen/include/asm-arm/bug.h
 create mode 100644 xen/include/asm-arm/byteorder.h
 create mode 100644 xen/include/asm-arm/cache.h
 create mode 100644 xen/include/asm-arm/config.h
 create mode 100644 xen/include/asm-arm/cpregs.h
 create mode 100644 xen/include/asm-arm/current.h
 create mode 100644 xen/include/asm-arm/debugger.h
 create mode 100644 xen/include/asm-arm/delay.h
 create mode 100644 xen/include/asm-arm/desc.h
 create mode 100644 xen/include/asm-arm/div64.h
 create mode 100644 xen/include/asm-arm/elf.h
 create mode 100644 xen/include/asm-arm/event.h
 create mode 100644 xen/include/asm-arm/flushtlb.h
 create mode 100644 xen/include/asm-arm/grant_table.h
 create mode 100644 xen/include/asm-arm/hardirq.h
 create mode 100644 xen/include/asm-arm/hypercall.h
 create mode 100644 xen/include/asm-arm/init.h
 create mode 100644 xen/include/asm-arm/io.h
 create mode 100644 xen/include/asm-arm/iocap.h
 create mode 100644 xen/include/asm-arm/multicall.h
 create mode 100644 xen/include/asm-arm/nmi.h
 create mode 100644 xen/include/asm-arm/numa.h
 create mode 100644 xen/include/asm-arm/paging.h
 create mode 100644 xen/include/asm-arm/percpu.h
 create mode 100644 xen/include/asm-arm/processor.h
 create mode 100644 xen/include/asm-arm/regs.h
 create mode 100644 xen/include/asm-arm/setup.h
 create mode 100644 xen/include/asm-arm/smp.h
 create mode 100644 xen/include/asm-arm/softirq.h
 create mode 100644 xen/include/asm-arm/spinlock.h
 create mode 100644 xen/include/asm-arm/string.h
 create mode 100644 xen/include/asm-arm/system.h
 create mode 100644 xen/include/asm-arm/trace.h
 create mode 100644 xen/include/asm-arm/types.h
 create mode 100644 xen/include/asm-arm/xenoprof.h
 create mode 100644 xen/include/public/arch-arm.h

diff --git a/xen/include/asm-arm/atomic.h b/xen/include/asm-arm/atomic.h
new file mode 100644
index 0000000..2b9ce0e
--- /dev/null
+++ b/xen/include/asm-arm/atomic.h
@@ -0,0 +1,212 @@
+/*
+ *  arch/arm/include/asm/atomic.h
+ *
+ *  Copyright (C) 1996 Russell King.
+ *  Copyright (C) 2002 Deep Blue Solutions Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#ifndef __ARCH_ARM_ATOMIC__
+#define __ARCH_ARM_ATOMIC__
+
+#include <xen/config.h>
+#include <asm/system.h>
+
+#define build_atomic_read(name, size, type, reg)   \
+static inline type name(const volatile type *addr) \
+{                                                  \
+    type ret;                                      \
+    asm volatile("ldr" size " %0,%1"               \
+                 : reg (ret)                       \
+                 : "m" (*(volatile type *)addr));  \
+    return ret;                                    \
+}
+
+#define build_atomic_write(name, size, type, reg)      \
+static inline void name(volatile type *addr, type val) \
+{                                                      \
+    asm volatile("str" size " %1,%0"                   \
+                 : "=m" (*(volatile type *)addr)       \
+                 : reg (val));                         \
+}
+
+build_atomic_read(atomic_read8, "b", uint8_t, "=q")
+build_atomic_read(atomic_read16, "h", uint16_t, "=r")
+build_atomic_read(atomic_read32, "", uint32_t, "=r")
+//build_atomic_read(atomic_read64, "d", uint64_t, "=r")
+build_atomic_read(atomic_read_int, "", int, "=r")
+
+build_atomic_write(atomic_write8, "b", uint8_t, "q")
+build_atomic_write(atomic_write16, "h", uint16_t, "r")
+build_atomic_write(atomic_write32, "", uint32_t, "r")
+//build_atomic_write(atomic_write64, "d", uint64_t, "r")
+build_atomic_write(atomic_write_int, "", int, "r")
+
+/*
+ * NB. I've pushed the volatile qualifier into the operations. This allows
+ * fast accessors such as _atomic_read() and _atomic_set() which don't give
+ * the compiler a fit.
+ */
+typedef struct { int counter; } atomic_t;
+
+#define ATOMIC_INIT(i) { (i) }
+
+/*
+ * On ARM, ordinary assignment (str instruction) doesn't clear the local
+ * strex/ldrex monitor on some implementations. The reason we can use it for
+ * atomic_set() is the clrex or dummy strex done on every exception return.
+ */
+#define _atomic_read(v) ((v).counter)
+#define atomic_read(v)  (*(volatile int *)&(v)->counter)
+
+#define _atomic_set(v,i) (((v).counter) = (i))
+#define atomic_set(v,i) (((v)->counter) = (i))
+
+/*
+ * ARMv6 UP and SMP safe atomic ops.  We use load exclusive and
+ * store exclusive to ensure that these are atomic.  We may loop
+ * to ensure that the update happens.
+ */
+static inline void atomic_add(int i, atomic_t *v)
+{
+        unsigned long tmp;
+        int result;
+
+        __asm__ __volatile__("@ atomic_add\n"
+"1:     ldrex   %0, [%3]\n"
+"       add     %0, %0, %4\n"
+"       strex   %1, %0, [%3]\n"
+"       teq     %1, #0\n"
+"       bne     1b"
+        : "=&r" (result), "=&r" (tmp), "+Qo" (v->counter)
+        : "r" (&v->counter), "Ir" (i)
+        : "cc");
+}
+
+static inline int atomic_add_return(int i, atomic_t *v)
+{
+        unsigned long tmp;
+        int result;
+
+        smp_mb();
+
+        __asm__ __volatile__("@ atomic_add_return\n"
+"1:     ldrex   %0, [%3]\n"
+"       add     %0, %0, %4\n"
+"       strex   %1, %0, [%3]\n"
+"       teq     %1, #0\n"
+"       bne     1b"
+        : "=&r" (result), "=&r" (tmp), "+Qo" (v->counter)
+        : "r" (&v->counter), "Ir" (i)
+        : "cc");
+
+        smp_mb();
+
+        return result;
+}
+
+static inline void atomic_sub(int i, atomic_t *v)
+{
+        unsigned long tmp;
+        int result;
+
+        __asm__ __volatile__("@ atomic_sub\n"
+"1:     ldrex   %0, [%3]\n"
+"       sub     %0, %0, %4\n"
+"       strex   %1, %0, [%3]\n"
+"       teq     %1, #0\n"
+"       bne     1b"
+        : "=&r" (result), "=&r" (tmp), "+Qo" (v->counter)
+        : "r" (&v->counter), "Ir" (i)
+        : "cc");
+}
+
+static inline int atomic_sub_return(int i, atomic_t *v)
+{
+        unsigned long tmp;
+        int result;
+
+        smp_mb();
+
+        __asm__ __volatile__("@ atomic_sub_return\n"
+"1:     ldrex   %0, [%3]\n"
+"       sub     %0, %0, %4\n"
+"       strex   %1, %0, [%3]\n"
+"       teq     %1, #0\n"
+"       bne     1b"
+        : "=&r" (result), "=&r" (tmp), "+Qo" (v->counter)
+        : "r" (&v->counter), "Ir" (i)
+        : "cc");
+
+        smp_mb();
+
+        return result;
+}
+
+static inline int atomic_cmpxchg(atomic_t *ptr, int old, int new)
+{
+        unsigned long oldval, res;
+
+        smp_mb();
+
+        do {
+                __asm__ __volatile__("@ atomic_cmpxchg\n"
+                "ldrex  %1, [%3]\n"
+                "mov    %0, #0\n"
+                "teq    %1, %4\n"
+                "strexeq %0, %5, [%3]\n"
+                    : "=&r" (res), "=&r" (oldval), "+Qo" (ptr->counter)
+                    : "r" (&ptr->counter), "Ir" (old), "r" (new)
+                    : "cc");
+        } while (res);
+
+        smp_mb();
+
+        return oldval;
+}
+
+static inline void atomic_clear_mask(unsigned long mask, unsigned long *addr)
+{
+        unsigned long tmp, tmp2;
+
+        __asm__ __volatile__("@ atomic_clear_mask\n"
+"1:     ldrex   %0, [%3]\n"
+"       bic     %0, %0, %4\n"
+"       strex   %1, %0, [%3]\n"
+"       teq     %1, #0\n"
+"       bne     1b"
+        : "=&r" (tmp), "=&r" (tmp2), "+Qo" (*addr)
+        : "r" (addr), "Ir" (mask)
+        : "cc");
+}
+
+#define atomic_inc(v)           atomic_add(1, v)
+#define atomic_dec(v)           atomic_sub(1, v)
+
+#define atomic_inc_and_test(v)  (atomic_add_return(1, v) == 0)
+#define atomic_dec_and_test(v)  (atomic_sub_return(1, v) == 0)
+#define atomic_inc_return(v)    (atomic_add_return(1, v))
+#define atomic_dec_return(v)    (atomic_sub_return(1, v))
+#define atomic_sub_and_test(i, v) (atomic_sub_return(i, v) == 0)
+
+#define atomic_add_negative(i,v) (atomic_add_return(i, v) < 0)
+
+static inline atomic_t atomic_compareandswap(
+    atomic_t old, atomic_t new, atomic_t *v)
+{
+    atomic_t rc;
+    rc.counter = __cmpxchg(&v->counter, old.counter, new.counter, sizeof(int));
+    return rc;
+}
+
+#endif /* __ARCH_ARM_ATOMIC__ */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/bitops.h b/xen/include/asm-arm/bitops.h
new file mode 100644
index 0000000..3d6b30b
--- /dev/null
+++ b/xen/include/asm-arm/bitops.h
@@ -0,0 +1,195 @@
+/*
+ * Copyright 1995, Russell King.
+ * Various bits and pieces copyrights include:
+ *  Linus Torvalds (test_bit).
+ * Big endian support: Copyright 2001, Nicolas Pitre
+ *  reworked by rmk.
+ */
+
+#ifndef _ARM_BITOPS_H
+#define _ARM_BITOPS_H
+
+extern void _set_bit(int nr, volatile void * p);
+extern void _clear_bit(int nr, volatile void * p);
+extern void _change_bit(int nr, volatile void * p);
+extern int _test_and_set_bit(int nr, volatile void * p);
+extern int _test_and_clear_bit(int nr, volatile void * p);
+extern int _test_and_change_bit(int nr, volatile void * p);
+
+#define set_bit(n,p)              _set_bit(n,p)
+#define clear_bit(n,p)            _clear_bit(n,p)
+#define change_bit(n,p)           _change_bit(n,p)
+#define test_and_set_bit(n,p)     _test_and_set_bit(n,p)
+#define test_and_clear_bit(n,p)   _test_and_clear_bit(n,p)
+#define test_and_change_bit(n,p)  _test_and_change_bit(n,p)
+
+#define BIT(nr)                 (1UL << (nr))
+#define BIT_MASK(nr)            (1UL << ((nr) % BITS_PER_LONG))
+#define BIT_WORD(nr)            ((nr) / BITS_PER_LONG)
+#define BITS_PER_BYTE           8
+
+#define ADDR (*(volatile long *) addr)
+#define CONST_ADDR (*(const volatile long *) addr)
+
+/**
+ * __test_and_set_bit - Set a bit and return its old value
+ * @nr: Bit to set
+ * @addr: Address to count from
+ *
+ * This operation is non-atomic and can be reordered.
+ * If two examples of this operation race, one can appear to succeed
+ * but actually fail.  You must protect multiple accesses with a lock.
+ */
+static inline int __test_and_set_bit(int nr, volatile void *addr)
+{
+        unsigned long mask = BIT_MASK(nr);
+        volatile unsigned long *p =
+                ((volatile unsigned long *)addr) + BIT_WORD(nr);
+        unsigned long old = *p;
+
+        *p = old | mask;
+        return (old & mask) != 0;
+}
+
+/**
+ * __test_and_clear_bit - Clear a bit and return its old value
+ * @nr: Bit to clear
+ * @addr: Address to count from
+ *
+ * This operation is non-atomic and can be reordered.
+ * If two examples of this operation race, one can appear to succeed
+ * but actually fail.  You must protect multiple accesses with a lock.
+ */
+static inline int __test_and_clear_bit(int nr, volatile void *addr)
+{
+        unsigned long mask = BIT_MASK(nr);
+        volatile unsigned long *p =
+                ((volatile unsigned long *)addr) + BIT_WORD(nr);
+        unsigned long old = *p;
+
+        *p = old & ~mask;
+        return (old & mask) != 0;
+}
+
+/* WARNING: non atomic and it can be reordered! */
+static inline int __test_and_change_bit(int nr,
+                                            volatile void *addr)
+{
+        unsigned long mask = BIT_MASK(nr);
+        volatile unsigned long *p =
+                ((volatile unsigned long *)addr) + BIT_WORD(nr);
+        unsigned long old = *p;
+
+        *p = old ^ mask;
+        return (old & mask) != 0;
+}
+
+/**
+ * test_bit - Determine whether a bit is set
+ * @nr: bit number to test
+ * @addr: Address to start counting from
+ */
+static inline int test_bit(int nr, const volatile void *addr)
+{
+        const volatile unsigned long *p = (const volatile unsigned long *)addr;
+        return 1UL & (p[BIT_WORD(nr)] >> (nr & (BITS_PER_LONG-1)));
+}
+
+
+extern unsigned int _find_first_bit(
+    const unsigned long *addr, unsigned int size);
+extern unsigned int _find_next_bit(
+    const unsigned long *addr, unsigned int size, unsigned int offset);
+extern unsigned int _find_first_zero_bit(
+    const unsigned long *addr, unsigned int size);
+extern unsigned int _find_next_zero_bit(
+    const unsigned long *addr, unsigned int size, unsigned int offset);
+
+/*
+ * These are the little endian, atomic definitions.
+ */
+#define find_first_zero_bit(p,sz)       _find_first_zero_bit(p,sz)
+#define find_next_zero_bit(p,sz,off)    _find_next_zero_bit(p,sz,off)
+#define find_first_bit(p,sz)            _find_first_bit(p,sz)
+#define find_next_bit(p,sz,off)         _find_next_bit(p,sz,off)
+
+static inline int constant_fls(int x)
+{
+        int r = 32;
+
+        if (!x)
+                return 0;
+        if (!(x & 0xffff0000u)) {
+                x <<= 16;
+                r -= 16;
+        }
+        if (!(x & 0xff000000u)) {
+                x <<= 8;
+                r -= 8;
+        }
+        if (!(x & 0xf0000000u)) {
+                x <<= 4;
+                r -= 4;
+        }
+        if (!(x & 0xc0000000u)) {
+                x <<= 2;
+                r -= 2;
+        }
+        if (!(x & 0x80000000u)) {
+                x <<= 1;
+                r -= 1;
+        }
+        return r;
+}
+
+/*
+ * On ARMv5 and above those functions can be implemented around
+ * the clz instruction for much better code efficiency.
+ */
+
+static inline int fls(int x)
+{
+        int ret;
+
+        if (__builtin_constant_p(x))
+               return constant_fls(x);
+
+        asm("clz\t%0, %1" : "=r" (ret) : "r" (x));
+        ret = 32 - ret;
+        return ret;
+}
+
+#define ffs(x) ({ unsigned long __t = (x); fls(__t & -__t); })
+
+/**
+ * find_first_set_bit - find the first set bit in @word
+ * @word: the word to search
+ *
+ * Returns the bit-number of the first set bit (first bit being 0).
+ * The input must *not* be zero.
+ */
+static inline unsigned int find_first_set_bit(unsigned long word)
+{
+        return ffs(word) - 1;
+}
+
+/**
+ * hweightN - returns the hamming weight of a N-bit word
+ * @x: the word to weigh
+ *
+ * The Hamming Weight of a number is the total number of bits set in it.
+ */
+#define hweight64(x) generic_hweight64(x)
+#define hweight32(x) generic_hweight32(x)
+#define hweight16(x) generic_hweight16(x)
+#define hweight8(x) generic_hweight8(x)
+
+#endif /* _ARM_BITOPS_H */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/bug.h b/xen/include/asm-arm/bug.h
new file mode 100644
index 0000000..bc2532c
--- /dev/null
+++ b/xen/include/asm-arm/bug.h
@@ -0,0 +1,15 @@
+#ifndef __ARM_BUG_H__
+#define __ARM_BUG_H__
+
+#define BUG() __bug(__FILE__, __LINE__)
+#define WARN() __warn(__FILE__, __LINE__)
+
+#endif /* __X86_BUG_H__ */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/byteorder.h b/xen/include/asm-arm/byteorder.h
new file mode 100644
index 0000000..f6ad883
--- /dev/null
+++ b/xen/include/asm-arm/byteorder.h
@@ -0,0 +1,16 @@
+#ifndef __ASM_ARM_BYTEORDER_H__
+#define __ASM_ARM_BYTEORDER_H__
+
+#define __BYTEORDER_HAS_U64__
+
+#include <xen/byteorder/little_endian.h>
+
+#endif /* __ASM_ARM_BYTEORDER_H__ */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/cache.h b/xen/include/asm-arm/cache.h
new file mode 100644
index 0000000..41b6291
--- /dev/null
+++ b/xen/include/asm-arm/cache.h
@@ -0,0 +1,20 @@
+#ifndef __ARCH_ARM_CACHE_H
+#define __ARCH_ARM_CACHE_H
+
+#include <xen/config.h>
+
+/* L1 cache line size */
+#define L1_CACHE_SHIFT  (CONFIG_ARM_L1_CACHE_SHIFT)
+#define L1_CACHE_BYTES  (1 << L1_CACHE_SHIFT)
+
+#define __read_mostly __attribute__((__section__(".data.read_mostly")))
+
+#endif
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/config.h b/xen/include/asm-arm/config.h
new file mode 100644
index 0000000..12285dd
--- /dev/null
+++ b/xen/include/asm-arm/config.h
@@ -0,0 +1,122 @@
+/******************************************************************************
+ * config.h
+ *
+ * A Linux-style configuration list.
+ */
+
+#ifndef __ARM_CONFIG_H__
+#define __ARM_CONFIG_H__
+
+#define CONFIG_PAGING_LEVELS 3
+
+#define CONFIG_ARM 1
+
+#define CONFIG_ARM_L1_CACHE_SHIFT 7 /* XXX */
+
+#define CONFIG_SMP 1
+
+#define CONFIG_DOMAIN_PAGE 1
+
+#define OPT_CONSOLE_STR "com1"
+
+#ifdef MAX_PHYS_CPUS
+#define NR_CPUS MAX_PHYS_CPUS
+#else
+#define NR_CPUS 128
+#endif
+
+#define MAX_VIRT_CPUS 128 /* XXX */
+#define MAX_HVM_VCPUS MAX_VIRT_CPUS
+
+#define asmlinkage /* Nothing needed */
+
+/* Linkage for ARM */
+#define __ALIGN .align 2
+#define __ALIGN_STR ".align 2"
+#ifdef __ASSEMBLY__
+#define ALIGN __ALIGN
+#define ALIGN_STR __ALIGN_STR
+#define ENTRY(name)                             \
+  .globl name;                                  \
+  ALIGN;                                        \
+  name:
+#define END(name) \
+  .size name, .-name
+#define ENDPROC(name) \
+  .type name, %function; \
+  END(name)
+#endif
+
+/*
+ * Memory layout:
+ *  0  -   2M   Unmapped
+ *  2M -   4M   Xen text, data, bss
+ *  4M -   6M   Fixmap: special-purpose 4K mapping slots
+ *
+ * 32M - 128M   Frametable: 24 bytes per page for 16GB of RAM
+ *
+ *  1G -   2G   Xenheap: always-mapped memory
+ *  2G -   4G   Domheap: on-demand-mapped
+ */
+
+#define XEN_VIRT_START         0x00200000
+#define FIXMAP_ADDR(n)        (0x00400000 + (n) * PAGE_SIZE)
+#define FRAMETABLE_VIRT_START  0x02000000
+#define XENHEAP_VIRT_START     0x40000000
+#define DOMHEAP_VIRT_START     0x80000000
+
+#define HYPERVISOR_VIRT_START mk_unsigned_long(XEN_VIRT_START)
+
+#define DOMHEAP_ENTRIES        1024  /* 1024 2MB mapping slots */
+
+/* Fixmap slots */
+#define FIXMAP_CONSOLE  0  /* The primary UART */
+#define FIXMAP_PT       1  /* Temporary mappings of pagetable pages */
+#define FIXMAP_MISC     2  /* Ephemeral mappings of hardware */
+#define FIXMAP_GICD     3  /* Interrupt controller: distributor registers */
+#define FIXMAP_GICC1    4  /* Interrupt controller: CPU registers (first page) */
+#define FIXMAP_GICC2    5  /* Interrupt controller: CPU registers (second page) */
+#define FIXMAP_GICH     6  /* Interrupt controller: virtual interface control registers */
+
+#define PAGE_SHIFT              12
+
+#ifndef __ASSEMBLY__
+#define PAGE_SIZE           (1L << PAGE_SHIFT)
+#else
+#define PAGE_SIZE           (1 << PAGE_SHIFT)
+#endif
+#define PAGE_MASK           (~(PAGE_SIZE-1))
+#define PAGE_FLAG_MASK      (~0)
+
+#define STACK_ORDER 3
+#define STACK_SIZE  (PAGE_SIZE << STACK_ORDER)
+
+#ifndef __ASSEMBLY__
+extern unsigned long xen_phys_start;
+extern unsigned long xenheap_phys_end;
+extern unsigned long frametable_virt_end;
+#endif
+
+#define supervisor_mode_kernel (0)
+
+#define watchdog_disable() ((void)0)
+#define watchdog_enable()  ((void)0)
+
+/* Board-specific: base address of PL011 UART */
+#define EARLY_UART_ADDRESS 0x1c090000
+/* Board-specific: base address of GIC + its regs */
+#define GIC_BASE_ADDRESS 0x2c000000
+#define GIC_DR_OFFSET 0x1000
+#define GIC_CR_OFFSET 0x2000
+#define GIC_HR_OFFSET 0x4000 /* Guess work http://lists.infradead.org/pipermail/linux-arm-kernel/2011-September/064219.html */
+#define GIC_VR_OFFSET 0x6000 /* Virtual Machine CPU interface) */
+
+#endif /* __ARM_CONFIG_H__ */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/cpregs.h b/xen/include/asm-arm/cpregs.h
new file mode 100644
index 0000000..3a4028d
--- /dev/null
+++ b/xen/include/asm-arm/cpregs.h
@@ -0,0 +1,207 @@
+#ifndef __ASM_ARM_CPREGS_H
+#define __ASM_ARM_CPREGS_H
+
+#include <xen/stringify.h>
+
+/* Co-processor registers */
+
+/* Layout as used in assembly, with src/dest registers mixed in */
+#define __CP32(r, coproc, opc1, crn, crm, opc2) coproc, opc1, r, crn, crm, opc2
+#define __CP64(r1, r2, coproc, opc, crm) coproc, opc, r1, r2, crm
+#define CP32(r, name...) __CP32(r, name)
+#define CP64(r, name...) __CP64(r, name)
+
+/* Stringified for inline assembly */
+#define LOAD_CP32(r, name...)  "mrc " __stringify(CP32(%r, name)) ";"
+#define STORE_CP32(r, name...) "mcr " __stringify(CP32(%r, name)) ";"
+#define LOAD_CP64(r, name...)  "mrrc " __stringify(CP64(%r, %H##r, name)) ";"
+#define STORE_CP64(r, name...) "mcrr " __stringify(CP64(%r, %H##r, name)) ";"
+
+/* C wrappers */
+#define READ_CP32(name...) ({                                   \
+    register uint32_t _r;                                       \
+    asm volatile(LOAD_CP32(0, name) : "=r" (_r));               \
+    _r; })
+
+#define WRITE_CP32(v, name...) do {                             \
+    register uint32_t _r = (v);                                 \
+    asm volatile(STORE_CP32(0, name) : : "r" (_r));             \
+} while (0)
+
+#define READ_CP64(name...) ({                                   \
+    register uint64_t _r;                                       \
+    asm volatile(LOAD_CP64(0, name) : "=r" (_r));               \
+    _r; })
+
+#define WRITE_CP64(v, name...) do {                             \
+    register uint64_t _r = (v);                                 \
+    asm volatile(STORE_CP64(0, name) : : "r" (_r));             \
+} while (0)
+
+#define __HSR_CPREG_c0  0
+#define __HSR_CPREG_c1  1
+#define __HSR_CPREG_c2  2
+#define __HSR_CPREG_c3  3
+#define __HSR_CPREG_c4  4
+#define __HSR_CPREG_c5  5
+#define __HSR_CPREG_c6  6
+#define __HSR_CPREG_c7  7
+#define __HSR_CPREG_c8  8
+#define __HSR_CPREG_c9  9
+#define __HSR_CPREG_c10 10
+#define __HSR_CPREG_c11 11
+#define __HSR_CPREG_c12 12
+#define __HSR_CPREG_c13 13
+#define __HSR_CPREG_c14 14
+#define __HSR_CPREG_c15 15
+
+#define __HSR_CPREG_0   0
+#define __HSR_CPREG_1   1
+#define __HSR_CPREG_2   2
+#define __HSR_CPREG_3   3
+#define __HSR_CPREG_4   4
+#define __HSR_CPREG_5   5
+#define __HSR_CPREG_6   6
+#define __HSR_CPREG_7   7
+
+#define _HSR_CPREG32(cp,op1,crn,crm,op2) \
+    ((__HSR_CPREG_##crn) << HSR_CP32_CRN_SHIFT) | \
+    ((__HSR_CPREG_##crm) << HSR_CP32_CRM_SHIFT) | \
+    ((__HSR_CPREG_##op1) << HSR_CP32_OP1_SHIFT) | \
+    ((__HSR_CPREG_##op2) << HSR_CP32_OP2_SHIFT)
+
+#define _HSR_CPREG64(cp,op1,crm) \
+    ((__HSR_CPREG_##crm) << HSR_CP64_CRM_SHIFT) | \
+    ((__HSR_CPREG_##op1) << HSR_CP64_OP1_SHIFT)
+
+/* Encode a register as per HSR ISS pattern */
+#define HSR_CPREG32(X) _HSR_CPREG32(X)
+#define HSR_CPREG64(X) _HSR_CPREG64(X)
+
+/*
+ * Order registers by Coprocessor-> CRn-> Opcode 1-> CRm-> Opcode 2
+ *
+ * This matches the ordering used in the ARM as well as the groupings
+ * which the CP registers are allocated in.
+ *
+ * This is slightly different to the form of the instruction
+ * arguments, which are cp,opc1,crn,crm,opc2.
+ */
+
+/* Coprocessor 15 */
+
+/* CP15 CR0: CPUID and Cache Type Registers */
+#define ID_PFR0         p15,0,c0,c1,0   /* Processor Feature Register 0 */
+#define ID_PFR1         p15,0,c0,c1,1   /* Processor Feature Register 1 */
+#define CCSIDR          p15,1,c0,c0,0   /* Cache Size ID Registers */
+#define CLIDR           p15,1,c0,c0,1   /* Cache Level ID Register */
+#define CSSELR          p15,2,c0,c0,0   /* Cache Size Selection Register */
+
+/* CP15 CR1: System Control Registers */
+#define SCTLR           p15,0,c1,c0,0   /* System Control Register */
+#define SCR             p15,0,c1,c1,0   /* Secure Configuration Register */
+#define NSACR           p15,0,c1,c1,2   /* Non-Secure Access Control Register */
+#define HSCTLR          p15,4,c1,c0,0   /* Hyp. System Control Register */
+#define HCR             p15,4,c1,c1,0   /* Hyp. Configuration Register */
+
+/* CP15 CR2: Translation Table Base and Control Registers */
+#define TTBR0           p15,0,c2,c0,0   /* Translation Table Base Reg. 0 */
+#define TTBR1           p15,0,c2,c0,1   /* Translation Table Base Reg. 1 */
+#define TTBCR           p15,0,c2,c0,2   /* Translatation Table Base Control Register */
+#define HTTBR           p15,4,c2        /* Hyp. Translation Table Base Register */
+#define HTCR            p15,4,c2,c0,2   /* Hyp. Translation Control Register */
+#define VTCR            p15,4,c2,c1,2   /* Virtualization Translation Control Register */
+#define VTTBR           p15,6,c2        /* Virtualization Translation Table Base Register */
+
+/* CP15 CR3: Domain Access Control Register */
+
+/* CP15 CR4: */
+
+/* CP15 CR5: Fault Status Registers */
+#define DFSR            p15,0,c5,c0,0   /* Data Fault Status Register */
+#define IFSR            p15,0,c5,c0,1   /* Instruction Fault Status Register */
+#define HSR             p15,4,c5,c2,0   /* Hyp. Syndrome Register */
+
+/* CP15 CR6: Fault Address Registers */
+#define DFAR            p15,0,c6,c0,0   /* Data Fault Address Register  */
+#define IFAR            p15,0,c6,c0,2   /* Instruction Fault Address Register */
+#define HDFAR           p15,4,c6,c0,0   /* Hyp. Data Fault Address Register */
+#define HIFAR           p15,4,c6,c0,2   /* Hyp. Instruction Fault Address Register */
+#define HPFAR           p15,4,c6,c0,4   /* Hyp. IPA Fault Address Register */
+
+/* CP15 CR7: Cache and address translation operations */
+#define PAR             p15,0,c7        /* Physical Address Register */
+#define ICIALLUIS       p15,0,c7,c1,0   /* Invalidate all instruction caches to PoU inner shareable */
+#define BPIALLIS        p15,0,c7,c1,6   /* Invalidate entire branch predictor array inner shareable */
+#define ICIALLU         p15,0,c7,c5,0   /* Invalidate all instruction caches to PoU */
+#define BPIALL          p15,0,c7,c5,6   /* Invalidate entire branch predictor array */
+#define ATS1CPR         p15,0,c7,c8,0   /* Address Translation Stage 1. Non-Secure Kernel Read */
+#define ATS1CPW         p15,0,c7,c8,1   /* Address Translation Stage 1. Non-Secure Kernel Write */
+#define ATS1CUR         p15,0,c7,c8,2   /* Address Translation Stage 1. Non-Secure User Read */
+#define ATS1CUW         p15,0,c7,c8,3   /* Address Translation Stage 1. Non-Secure User Write */
+#define ATS12NSOPR      p15,0,c7,c8,4   /* Address Translation Stage 1+2 Non-Secure Kernel Read */
+#define ATS12NSOPW      p15,0,c7,c8,5   /* Address Translation Stage 1+2 Non-Secure Kernel Write */
+#define ATS12NSOUR      p15,0,c7,c8,6   /* Address Translation Stage 1+2 Non-Secure User Read */
+#define ATS12NSOUW      p15,0,c7,c8,7   /* Address Translation Stage 1+2 Non-Secure User Write */
+#define DCCMVAC         p15,0,c7,c10,1  /* Clean data or unified cache line by MVA to PoC */
+#define DCCISW          p15,0,c7,c14,2  /* Clean and invalidate data cache line by set/way */
+#define ATS1HR          p15,4,c7,c8,0   /* Address Translation Stage 1 Hyp. Read */
+#define ATS1HW          p15,4,c7,c8,1   /* Address Translation Stage 1 Hyp. Write */
+
+/* CP15 CR8: TLB maintenance operations */
+#define TLBIALLIS       p15,0,c8,c3,0   /* Invalidate entire TLB innrer shareable */
+#define TLBIMVAIS       p15,0,c8,c3,1   /* Invalidate unified TLB entry by MVA inner shareable */
+#define TLBIASIDIS      p15,0,c8,c3,2   /* Invalidate unified TLB by ASID match inner shareable */
+#define TLBIMVAAIS      p15,0,c8,c3,3   /* Invalidate unified TLB entry by MVA all ASID inner shareable */
+#define DTLBIALL        p15,0,c8,c6,0   /* Invalidate data TLB */
+#define DTLBIMVA        p15,0,c8,c6,1   /* Invalidate data TLB entry by MVA */
+#define DTLBIASID       p15,0,c8,c6,2   /* Invalidate data TLB by ASID match */
+#define TLBILLHIS       p15,4,c8,c3,0   /* Invalidate Entire Hyp. Unified TLB inner shareable */
+#define TLBIMVAHIS      p15,4,c8,c3,1   /* Invalidate Unified Hyp. TLB by MVA inner shareable */
+#define TLBIALLNSNHIS   p15,4,c8,c7,4   /* Invalidate Entire Non-Secure Non-Hyp. Unified TLB inner shareable */
+#define TLBIALLH        p15,4,c8,c7,0   /* Invalidate Entire Hyp. Unified TLB */
+#define TLBIMVAH        p15,4,c8,c7,1   /* Invalidate Unified Hyp. TLB by MVA */
+#define TLBIALLNSNH     p15,4,c8,c7,4   /* Invalidate Entire Non-Secure Non-Hyp. Unified TLB */
+
+/* CP15 CR9: */
+
+/* CP15 CR10: */
+#define MAIR0           p15,0,c10,c2,0  /* Memory Attribute Indirection Register 0 */
+#define MAIR1           p15,0,c10,c2,1  /* Memory Attribute Indirection Register 1 */
+#define HMAIR0          p15,4,c10,c2,0  /* Hyp. Memory Attribute Indirection Register 0 */
+#define HMAIR1          p15,4,c10,c2,1  /* Hyp. Memory Attribute Indirection Register 1 */
+
+/* CP15 CR11: DMA Operations for TCM Access */
+
+/* CP15 CR12:  */
+#define HVBAR           p15,4,c12,c0,0  /* Hyp. Vector Base Address Register */
+
+/* CP15 CR13:  */
+#define FCSEIDR         p15,0,c13,c0,0  /* FCSE Process ID Register */
+#define CONTEXTIDR      p15,0,c13,c0,1  /* Context ID Register */
+
+/* CP15 CR14:  */
+#define CNTPCT          p15,0,c14       /* Time counter value */
+#define CNTFRQ          p15,0,c14,c0,0  /* Time counter frequency */
+#define CNTKCTL         p15,0,c14,c1,0  /* Time counter kernel control */
+#define CNTP_TVAL       p15,0,c14,c2,0  /* Physical Timer value */
+#define CNTP_CTL        p15,0,c14,c2,1  /* Physical Timer control register */
+#define CNTVCT          p15,1,c14       /* Time counter value + offset */
+#define CNTP_CVAL       p15,2,c14       /* Physical Timer comparator */
+#define CNTVOFF         p15,4,c14       /* Time counter offset */
+#define CNTHCTL         p15,4,c14,c1,0  /* Time counter hyp. control */
+#define CNTHP_TVAL      p15,4,c14,c2,0  /* Hyp. Timer value */
+#define CNTHP_CTL       p15,4,c14,c2,1  /* Hyp. Timer control register */
+#define CNTHP_CVAL      p15,6,c14       /* Hyp. Timer comparator */
+
+/* CP15 CR15: Implementation Defined Registers */
+
+#endif
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/current.h b/xen/include/asm-arm/current.h
new file mode 100644
index 0000000..826efa5
--- /dev/null
+++ b/xen/include/asm-arm/current.h
@@ -0,0 +1,60 @@
+#ifndef __ARM_CURRENT_H__
+#define __ARM_CURRENT_H__
+
+#include <xen/config.h>
+#include <xen/percpu.h>
+#include <public/xen.h>
+
+#ifndef __ASSEMBLY__
+
+struct vcpu;
+
+struct cpu_info {
+    struct cpu_user_regs guest_cpu_user_regs;
+    unsigned long elr;
+    unsigned int processor_id;
+    struct vcpu *current_vcpu;
+    unsigned long per_cpu_offset;
+};
+
+static inline struct cpu_info *get_cpu_info(void)
+{
+        register unsigned long sp asm ("sp");
+        return (struct cpu_info *)((sp & ~(STACK_SIZE - 1)) + STACK_SIZE - sizeof(struct cpu_info));
+}
+
+#define get_current()         (get_cpu_info()->current_vcpu)
+#define set_current(vcpu)     (get_cpu_info()->current_vcpu = (vcpu))
+#define current               (get_current())
+
+#define get_processor_id()    (get_cpu_info()->processor_id)
+#define set_processor_id(id)  do {                                      \
+    struct cpu_info *ci__ = get_cpu_info();                             \
+    ci__->per_cpu_offset = __per_cpu_offset[ci__->processor_id = (id)]; \
+} while (0)
+
+#define guest_cpu_user_regs() (&get_cpu_info()->guest_cpu_user_regs)
+
+#define reset_stack_and_jump(__fn)              \
+    __asm__ __volatile__ (                      \
+        "mov sp,%0; b "STR(__fn)      \
+        : : "r" (guest_cpu_user_regs()) : "memory" )
+#endif
+
+
+/*
+ * Which VCPU's state is currently running on each CPU?
+ * This is not necesasrily the same as 'current' as a CPU may be
+ * executing a lazy state switch.
+ */
+DECLARE_PER_CPU(struct vcpu *, curr_vcpu);
+
+#endif /* __ARM_CURRENT_H__ */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/debugger.h b/xen/include/asm-arm/debugger.h
new file mode 100644
index 0000000..84b2eec
--- /dev/null
+++ b/xen/include/asm-arm/debugger.h
@@ -0,0 +1,15 @@
+#ifndef __ARM_DEBUGGER_H__
+#define __ARM_DEBUGGER_H__
+
+#define debugger_trap_fatal(v, r) (0)
+#define debugger_trap_immediate() (0)
+
+#endif /* __ARM_DEBUGGER_H__ */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/delay.h b/xen/include/asm-arm/delay.h
new file mode 100644
index 0000000..6250774
--- /dev/null
+++ b/xen/include/asm-arm/delay.h
@@ -0,0 +1,15 @@
+#ifndef _ARM_DELAY_H
+#define _ARM_DELAY_H
+
+extern void __udelay(unsigned long usecs);
+#define udelay(n) __udelay(n)
+
+#endif /* defined(_ARM_DELAY_H) */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/desc.h b/xen/include/asm-arm/desc.h
new file mode 100644
index 0000000..3989e8a
--- /dev/null
+++ b/xen/include/asm-arm/desc.h
@@ -0,0 +1,12 @@
+#ifndef __ARCH_DESC_H
+#define __ARCH_DESC_H
+
+#endif /* __ARCH_DESC_H */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/div64.h b/xen/include/asm-arm/div64.h
new file mode 100644
index 0000000..7b00808
--- /dev/null
+++ b/xen/include/asm-arm/div64.h
@@ -0,0 +1,235 @@
+/* Taken from Linux arch/arm */
+#ifndef __ASM_ARM_DIV64
+#define __ASM_ARM_DIV64
+
+#include <asm/system.h>
+#include <xen/types.h>
+
+/*
+ * The semantics of do_div() are:
+ *
+ * uint32_t do_div(uint64_t *n, uint32_t base)
+ * {
+ * 	uint32_t remainder = *n % base;
+ * 	*n = *n / base;
+ * 	return remainder;
+ * }
+ *
+ * In other words, a 64-bit dividend with a 32-bit divisor producing
+ * a 64-bit result and a 32-bit remainder.  To accomplish this optimally
+ * we call a special __do_div64 helper with completely non standard
+ * calling convention for arguments and results (beware).
+ */
+
+#ifdef __ARMEB__
+#define __xh "r0"
+#define __xl "r1"
+#else
+#define __xl "r0"
+#define __xh "r1"
+#endif
+
+#define __do_div_asm(n, base)					\
+({								\
+	register unsigned int __base      asm("r4") = base;	\
+	register unsigned long long __n   asm("r0") = n;	\
+	register unsigned long long __res asm("r2");		\
+	register unsigned int __rem       asm(__xh);		\
+	asm(	__asmeq("%0", __xh)				\
+		__asmeq("%1", "r2")				\
+		__asmeq("%2", "r0")				\
+		__asmeq("%3", "r4")				\
+		"bl	__do_div64"				\
+		: "=r" (__rem), "=r" (__res)			\
+		: "r" (__n), "r" (__base)			\
+		: "ip", "lr", "cc");				\
+	n = __res;						\
+	__rem;							\
+})
+
+#if __GNUC__ < 4
+
+/*
+ * gcc versions earlier than 4.0 are simply too problematic for the
+ * optimized implementation below. First there is gcc PR 15089 that
+ * tend to trig on more complex constructs, spurious .global __udivsi3
+ * are inserted even if none of those symbols are referenced in the
+ * generated code, and those gcc versions are not able to do constant
+ * propagation on long long values anyway.
+ */
+#define do_div(n, base) __do_div_asm(n, base)
+
+#elif __GNUC__ >= 4
+
+#include <asm/bug.h>
+
+/*
+ * If the divisor happens to be constant, we determine the appropriate
+ * inverse at compile time to turn the division into a few inline
+ * multiplications instead which is much faster. And yet only if compiling
+ * for ARMv4 or higher (we need umull/umlal) and if the gcc version is
+ * sufficiently recent to perform proper long long constant propagation.
+ * (It is unfortunate that gcc doesn't perform all this internally.)
+ */
+#define do_div(n, base)							\
+({									\
+	unsigned int __r, __b = (base);					\
+	if (!__builtin_constant_p(__b) || __b == 0) {			\
+		/* non-constant divisor (or zero): slow path */		\
+		__r = __do_div_asm(n, __b);				\
+	} else if ((__b & (__b - 1)) == 0) {				\
+		/* Trivial: __b is constant and a power of 2 */		\
+		/* gcc does the right thing with this code.  */		\
+		__r = n;						\
+		__r &= (__b - 1);					\
+		n /= __b;						\
+	} else {							\
+		/* Multiply by inverse of __b: n/b = n*(p/b)/p       */	\
+		/* We rely on the fact that most of this code gets   */	\
+		/* optimized away at compile time due to constant    */	\
+		/* propagation and only a couple inline assembly     */	\
+		/* instructions should remain. Better avoid any      */	\
+		/* code construct that might prevent that.           */	\
+		unsigned long long __res, __x, __t, __m, __n = n;	\
+		unsigned int __c, __p, __z = 0;				\
+		/* preserve low part of n for reminder computation */	\
+		__r = __n;						\
+		/* determine number of bits to represent __b */		\
+		__p = 1 << __div64_fls(__b);				\
+		/* compute __m = ((__p << 64) + __b - 1) / __b */	\
+		__m = (~0ULL / __b) * __p;				\
+		__m += (((~0ULL % __b + 1) * __p) + __b - 1) / __b;	\
+		/* compute __res = __m*(~0ULL/__b*__b-1)/(__p << 64) */	\
+		__x = ~0ULL / __b * __b - 1;				\
+		__res = (__m & 0xffffffff) * (__x & 0xffffffff);	\
+		__res >>= 32;						\
+		__res += (__m & 0xffffffff) * (__x >> 32);		\
+		__t = __res;						\
+		__res += (__x & 0xffffffff) * (__m >> 32);		\
+		__t = (__res < __t) ? (1ULL << 32) : 0;			\
+		__res = (__res >> 32) + __t;				\
+		__res += (__m >> 32) * (__x >> 32);			\
+		__res /= __p;						\
+		/* Now sanitize and optimize what we've got. */		\
+		if (~0ULL % (__b / (__b & -__b)) == 0) {		\
+			/* those cases can be simplified with: */	\
+			__n /= (__b & -__b);				\
+			__m = ~0ULL / (__b / (__b & -__b));		\
+			__p = 1;					\
+			__c = 1;					\
+		} else if (__res != __x / __b) {			\
+			/* We can't get away without a correction    */	\
+			/* to compensate for bit truncation errors.  */	\
+			/* To avoid it we'd need an additional bit   */	\
+			/* to represent __m which would overflow it. */	\
+			/* Instead we do m=p/b and n/b=(n*m+m)/p.    */	\
+			__c = 1;					\
+			/* Compute __m = (__p << 64) / __b */		\
+			__m = (~0ULL / __b) * __p;			\
+			__m += ((~0ULL % __b + 1) * __p) / __b;		\
+		} else {						\
+			/* Reduce __m/__p, and try to clear bit 31   */	\
+			/* of __m when possible otherwise that'll    */	\
+			/* need extra overflow handling later.       */	\
+			unsigned int __bits = -(__m & -__m);		\
+			__bits |= __m >> 32;				\
+			__bits = (~__bits) << 1;			\
+			/* If __bits == 0 then setting bit 31 is     */	\
+			/* unavoidable.  Simply apply the maximum    */	\
+			/* possible reduction in that case.          */	\
+			/* Otherwise the MSB of __bits indicates the */	\
+			/* best reduction we should apply.           */	\
+			if (!__bits) {					\
+				__p /= (__m & -__m);			\
+				__m /= (__m & -__m);			\
+			} else {					\
+				__p >>= __div64_fls(__bits);		\
+				__m >>= __div64_fls(__bits);		\
+			}						\
+			/* No correction needed. */			\
+			__c = 0;					\
+		}							\
+		/* Now we have a combination of 2 conditions:        */	\
+		/* 1) whether or not we need a correction (__c), and */	\
+		/* 2) whether or not there might be an overflow in   */	\
+		/*    the cross product (__m & ((1<<63) | (1<<31)))  */	\
+		/* Select the best insn combination to perform the   */	\
+		/* actual __m * __n / (__p << 64) operation.         */	\
+		if (!__c) {						\
+			asm (	"umull	%Q0, %R0, %1, %Q2\n\t"		\
+				"mov	%Q0, #0"			\
+				: "=&r" (__res)				\
+				: "r" (__m), "r" (__n)			\
+				: "cc" );				\
+		} else if (!(__m & ((1ULL << 63) | (1ULL << 31)))) {	\
+			__res = __m;					\
+			asm (	"umlal	%Q0, %R0, %Q1, %Q2\n\t"		\
+				"mov	%Q0, #0"			\
+				: "+&r" (__res)				\
+				: "r" (__m), "r" (__n)			\
+				: "cc" );				\
+		} else {						\
+			asm (	"umull	%Q0, %R0, %Q1, %Q2\n\t"		\
+				"cmn	%Q0, %Q1\n\t"			\
+				"adcs	%R0, %R0, %R1\n\t"		\
+				"adc	%Q0, %3, #0"			\
+				: "=&r" (__res)				\
+				: "r" (__m), "r" (__n), "r" (__z)	\
+				: "cc" );				\
+		}							\
+		if (!(__m & ((1ULL << 63) | (1ULL << 31)))) {		\
+			asm (	"umlal	%R0, %Q0, %R1, %Q2\n\t"		\
+				"umlal	%R0, %Q0, %Q1, %R2\n\t"		\
+				"mov	%R0, #0\n\t"			\
+				"umlal	%Q0, %R0, %R1, %R2"		\
+				: "+&r" (__res)				\
+				: "r" (__m), "r" (__n)			\
+				: "cc" );				\
+		} else {						\
+			asm (	"umlal	%R0, %Q0, %R2, %Q3\n\t"		\
+				"umlal	%R0, %1, %Q2, %R3\n\t"		\
+				"mov	%R0, #0\n\t"			\
+				"adds	%Q0, %1, %Q0\n\t"		\
+				"adc	%R0, %R0, #0\n\t"		\
+				"umlal	%Q0, %R0, %R2, %R3"		\
+				: "+&r" (__res), "+&r" (__z)		\
+				: "r" (__m), "r" (__n)			\
+				: "cc" );				\
+		}							\
+		__res /= __p;						\
+		/* The reminder can be computed with 32-bit regs     */	\
+		/* only, and gcc is good at that.                    */	\
+		{							\
+			unsigned int __res0 = __res;			\
+			unsigned int __b0 = __b;			\
+			__r -= __res0 * __b0;				\
+		}							\
+		/* BUG_ON(__r >= __b || __res * __b + __r != n); */	\
+		n = __res;						\
+	}								\
+	__r;								\
+})
+
+/* our own fls implementation to make sure constant propagation is fine */
+#define __div64_fls(bits)						\
+({									\
+	unsigned int __left = (bits), __nr = 0;				\
+	if (__left & 0xffff0000) __nr += 16, __left >>= 16;		\
+	if (__left & 0x0000ff00) __nr +=  8, __left >>=  8;		\
+	if (__left & 0x000000f0) __nr +=  4, __left >>=  4;		\
+	if (__left & 0x0000000c) __nr +=  2, __left >>=  2;		\
+	if (__left & 0x00000002) __nr +=  1;				\
+	__nr;								\
+})
+
+#endif
+
+#endif
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/elf.h b/xen/include/asm-arm/elf.h
new file mode 100644
index 0000000..12d487c
--- /dev/null
+++ b/xen/include/asm-arm/elf.h
@@ -0,0 +1,33 @@
+#ifndef __ARM_ELF_H__
+#define __ARM_ELF_H__
+
+typedef struct {
+    unsigned long r0;
+    unsigned long r1;
+    unsigned long r2;
+    unsigned long r3;
+    unsigned long r4;
+    unsigned long r5;
+    unsigned long r6;
+    unsigned long r7;
+    unsigned long r8;
+    unsigned long r9;
+    unsigned long r10;
+    unsigned long r11;
+    unsigned long r12;
+    unsigned long sp;
+    unsigned long lr;
+    unsigned long pc;
+} ELF_Gregset;
+
+#endif /* __ARM_ELF_H__ */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/event.h b/xen/include/asm-arm/event.h
new file mode 100644
index 0000000..6b2fb7c
--- /dev/null
+++ b/xen/include/asm-arm/event.h
@@ -0,0 +1,41 @@
+#ifndef __ASM_EVENT_H__
+#define __ASM_EVENT_H__
+
+void vcpu_kick(struct vcpu *v);
+void vcpu_mark_events_pending(struct vcpu *v);
+
+static inline int local_events_need_delivery(void)
+{
+    /* TODO
+     * return (vcpu_info(v, evtchn_upcall_pending) &&
+                        !vcpu_info(v, evtchn_upcall_mask)); */
+        return 0;
+}
+
+int local_event_delivery_is_enabled(void);
+
+static inline void local_event_delivery_disable(void)
+{
+    /* TODO current->vcpu_info->evtchn_upcall_mask = 1; */
+}
+
+static inline void local_event_delivery_enable(void)
+{
+    /* TODO current->vcpu_info->evtchn_upcall_mask = 0; */
+}
+
+/* No arch specific virq definition now. Default to global. */
+static inline int arch_virq_is_global(int virq)
+{
+    return 1;
+}
+
+#endif
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/flushtlb.h b/xen/include/asm-arm/flushtlb.h
new file mode 100644
index 0000000..c8486fc
--- /dev/null
+++ b/xen/include/asm-arm/flushtlb.h
@@ -0,0 +1,31 @@
+#ifndef __FLUSHTLB_H__
+#define __FLUSHTLB_H__
+
+#include <xen/cpumask.h>
+
+/*
+ * Filter the given set of CPUs, removing those that definitely flushed their
+ * TLB since @page_timestamp.
+ */
+/* XXX lazy implementation just doesn't clear anything.... */
+#define tlbflush_filter(mask, page_timestamp)                           \
+do {                                                                    \
+} while ( 0 )
+
+#define tlbflush_current_time()                 (0)
+
+/* Flush local TLBs */
+void flush_tlb_local(void);
+
+/* Flush specified CPUs' TLBs */
+void flush_tlb_mask(const cpumask_t *mask);
+
+#endif /* __FLUSHTLB_H__ */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/grant_table.h b/xen/include/asm-arm/grant_table.h
new file mode 100644
index 0000000..8f6ffd8
--- /dev/null
+++ b/xen/include/asm-arm/grant_table.h
@@ -0,0 +1,35 @@
+#ifndef __ASM_GRANT_TABLE_H__
+#define __ASM_GRANT_TABLE_H__
+
+#include <xen/grant_table.h>
+
+#define INVALID_GFN (-1UL)
+#define INITIAL_NR_GRANT_FRAMES 1
+
+void gnttab_clear_flag(unsigned long nr, uint16_t *addr);
+int create_grant_host_mapping(unsigned long gpaddr,
+		unsigned long mfn, unsigned int flags, unsigned int
+		cache_flags);
+#define gnttab_host_mapping_get_page_type(op, d, rd) (0)
+int replace_grant_host_mapping(unsigned long gpaddr, unsigned long mfn,
+		unsigned long new_gpaddr, unsigned int flags);
+void gnttab_mark_dirty(struct domain *d, unsigned long l);
+#define gnttab_create_status_page(d, t, i) (0)
+#define gnttab_create_shared_page(d, t, i) (0)
+#define gnttab_shared_gmfn(d, t, i) (0)
+#define gnttab_status_gmfn(d, t, i) (0)
+#define gnttab_release_host_mappings(domain) 1
+static inline int replace_grant_supported(void)
+{
+    return 1;
+}
+
+#endif /* __ASM_GRANT_TABLE_H__ */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/hardirq.h b/xen/include/asm-arm/hardirq.h
new file mode 100644
index 0000000..9c031a8
--- /dev/null
+++ b/xen/include/asm-arm/hardirq.h
@@ -0,0 +1,28 @@
+#ifndef __ASM_HARDIRQ_H
+#define __ASM_HARDIRQ_H
+
+#include <xen/config.h>
+#include <xen/cache.h>
+#include <xen/smp.h>
+
+typedef struct {
+        unsigned long __softirq_pending;
+        unsigned int __local_irq_count;
+} __cacheline_aligned irq_cpustat_t;
+
+#include <xen/irq_cpustat.h>    /* Standard mappings for irq_cpustat_t above */
+
+#define in_irq() (local_irq_count(smp_processor_id()) != 0)
+
+#define irq_enter()     (local_irq_count(smp_processor_id())++)
+#define irq_exit()      (local_irq_count(smp_processor_id())--)
+
+#endif /* __ASM_HARDIRQ_H */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/hypercall.h b/xen/include/asm-arm/hypercall.h
new file mode 100644
index 0000000..90a87ef
--- /dev/null
+++ b/xen/include/asm-arm/hypercall.h
@@ -0,0 +1,24 @@
+#ifndef __ASM_ARM_HYPERCALL_H__
+#define __ASM_ARM_HYPERCALL_H__
+
+#include <public/domctl.h> /* for arch_do_domctl */
+
+struct vcpu;
+extern long
+arch_do_vcpu_op(
+    int cmd, struct vcpu *v, XEN_GUEST_HANDLE(void) arg);
+
+extern long
+arch_do_sysctl(
+    struct xen_sysctl *op,
+    XEN_GUEST_HANDLE(xen_sysctl_t) u_sysctl);
+
+#endif /* __ASM_ARM_HYPERCALL_H__ */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/init.h b/xen/include/asm-arm/init.h
new file mode 100644
index 0000000..5f44929
--- /dev/null
+++ b/xen/include/asm-arm/init.h
@@ -0,0 +1,12 @@
+#ifndef _XEN_ASM_INIT_H
+#define _XEN_ASM_INIT_H
+
+#endif /* _XEN_ASM_INIT_H */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/io.h b/xen/include/asm-arm/io.h
new file mode 100644
index 0000000..1babbab
--- /dev/null
+++ b/xen/include/asm-arm/io.h
@@ -0,0 +1,12 @@
+#ifndef _ASM_IO_H
+#define _ASM_IO_H
+
+#endif
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/iocap.h b/xen/include/asm-arm/iocap.h
new file mode 100644
index 0000000..f647f30
--- /dev/null
+++ b/xen/include/asm-arm/iocap.h
@@ -0,0 +1,20 @@
+#ifndef __X86_IOCAP_H__
+#define __X86_IOCAP_H__
+
+#define cache_flush_permitted(d)                        \
+    (!rangeset_is_empty((d)->iomem_caps))
+
+#define multipage_allocation_permitted(d, order)        \
+    (((order) <= 9) || /* allow 2MB superpages */       \
+     !rangeset_is_empty((d)->iomem_caps))
+
+#endif
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/multicall.h b/xen/include/asm-arm/multicall.h
new file mode 100644
index 0000000..c800940
--- /dev/null
+++ b/xen/include/asm-arm/multicall.h
@@ -0,0 +1,23 @@
+#ifndef __ASM_ARM_MULTICALL_H__
+#define __ASM_ARM_MULTICALL_H__
+
+#define do_multicall_call(_call)                             \
+    do {                                                     \
+        __asm__ __volatile__ (                               \
+            ".word 0xe7f000f0@; do_multicall_call\n"         \
+            "    mov r0,#0; @ do_multicall_call\n"           \
+            "    str r0, [r0];\n"                            \
+            :                                                \
+            :                                                \
+            : );                                             \
+    } while ( 0 )
+
+#endif /* __ASM_ARM_MULTICALL_H__ */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/nmi.h b/xen/include/asm-arm/nmi.h
new file mode 100644
index 0000000..e0f19f9
--- /dev/null
+++ b/xen/include/asm-arm/nmi.h
@@ -0,0 +1,15 @@
+#ifndef ASM_NMI_H
+#define ASM_NMI_H
+
+#define register_guest_nmi_callback(a)  (-ENOSYS)
+#define unregister_guest_nmi_callback() (-ENOSYS)
+
+#endif /* ASM_NMI_H */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/numa.h b/xen/include/asm-arm/numa.h
new file mode 100644
index 0000000..cffee5c
--- /dev/null
+++ b/xen/include/asm-arm/numa.h
@@ -0,0 +1,21 @@
+#ifndef __ARCH_ARM_NUMA_H
+#define __ARCH_ARM_NUMA_H
+
+/* Fake one node for now... */
+#define cpu_to_node(cpu) 0
+#define node_to_cpumask(node)	(cpu_online_map)
+
+static inline __attribute__((pure)) int phys_to_nid(paddr_t addr)
+{
+        return 0;
+}
+
+#endif /* __ARCH_ARM_NUMA_H */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/paging.h b/xen/include/asm-arm/paging.h
new file mode 100644
index 0000000..4dc340f
--- /dev/null
+++ b/xen/include/asm-arm/paging.h
@@ -0,0 +1,13 @@
+#ifndef _XEN_PAGING_H
+#define _XEN_PAGING_H
+
+#endif /* XEN_PAGING_H */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/percpu.h b/xen/include/asm-arm/percpu.h
new file mode 100644
index 0000000..9d369eb
--- /dev/null
+++ b/xen/include/asm-arm/percpu.h
@@ -0,0 +1,28 @@
+#ifndef __ARM_PERCPU_H__
+#define __ARM_PERCPU_H__
+
+#ifndef __ASSEMBLY__
+extern char __per_cpu_start[], __per_cpu_data_end[];
+extern unsigned long __per_cpu_offset[NR_CPUS];
+void percpu_init_areas(void);
+#endif
+
+/* Separate out the type, so (int[3], foo) works. */
+#define __DEFINE_PER_CPU(type, name, suffix)                    \
+    __attribute__((__section__(".bss.percpu" #suffix)))         \
+    __typeof__(type) per_cpu_##name
+
+#define per_cpu(var, cpu) ((&per_cpu__##var)[cpu?0:0])
+#define __get_cpu_var(var) per_cpu__##var
+
+#define DECLARE_PER_CPU(type, name) extern __typeof__(type) per_cpu__##name
+
+#endif /* __ARM_PERCPU_H__ */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/processor.h b/xen/include/asm-arm/processor.h
new file mode 100644
index 0000000..1f85d31
--- /dev/null
+++ b/xen/include/asm-arm/processor.h
@@ -0,0 +1,269 @@
+#ifndef __ASM_ARM_PROCESSOR_H
+#define __ASM_ARM_PROCESSOR_H
+
+#include <asm/cpregs.h>
+
+/* PSR bits (CPSR, SPSR)*/
+
+/* 0-4: Mode */
+#define PSR_MODE_MASK 0x1f
+#define PSR_MODE_USR 0x10
+#define PSR_MODE_FIQ 0x11
+#define PSR_MODE_IRQ 0x12
+#define PSR_MODE_SVC 0x13
+#define PSR_MODE_MON 0x16
+#define PSR_MODE_ABT 0x17
+#define PSR_MODE_HYP 0x1a
+#define PSR_MODE_UND 0x1b
+#define PSR_MODE_SYS 0x1f
+
+#define PSR_THUMB        (1<<5)        /* Thumb Mode enable */
+#define PSR_FIQ_MASK        (1<<6)        /* Fast Interrupt mask */
+#define PSR_IRQ_MASK        (1<<7)        /* Interrupt mask */
+#define PSR_ABT_MASK         (1<<8)        /* Asynchronous Abort mask */
+#define PSR_BIG_ENDIAN        (1<<9)        /* Big Endian Mode */
+#define PSR_JAZELLE        (1<<24)        /* Jazelle Mode */
+
+/* TTBCR Translation Table Base Control Register */
+#define TTBCR_N_MASK 0x07
+#define TTBCR_N_16KB 0x00
+#define TTBCR_N_8KB  0x01
+#define TTBCR_N_4KB  0x02
+#define TTBCR_N_2KB  0x03
+#define TTBCR_N_1KB  0x04
+
+/* SCTLR System Control Register. */
+/* HSCTLR is a subset of this. */
+#define SCTLR_TE        (1<<30)
+#define SCTLR_AFE        (1<<29)
+#define SCTLR_TRE        (1<<28)
+#define SCTLR_NMFI        (1<<27)
+#define SCTLR_EE        (1<<25)
+#define SCTLR_VE        (1<<24)
+#define SCTLR_U                (1<<22)
+#define SCTLR_FI        (1<<21)
+#define SCTLR_WXN        (1<<19)
+#define SCTLR_HA        (1<<17)
+#define SCTLR_RR        (1<<14)
+#define SCTLR_V                (1<<13)
+#define SCTLR_I                (1<<12)
+#define SCTLR_Z                (1<<11)
+#define SCTLR_SW        (1<<10)
+#define SCTLR_B                (1<<7)
+#define SCTLR_C                (1<<2)
+#define SCTLR_A                (1<<1)
+#define SCTLR_M                (1<<0)
+
+#define SCTLR_BASE        0x00c50078
+#define HSCTLR_BASE        0x30c51878
+
+/* HCR Hyp Configuration Register */
+#define HCR_TGE                (1<<27)
+#define HCR_TVM                (1<<26)
+#define HCR_TTLB        (1<<25)
+#define HCR_TPU                (1<<24)
+#define HCR_TPC                (1<<23)
+#define HCR_TSW                (1<<22)
+#define HCR_TAC                (1<<21)
+#define HCR_TIDCP        (1<<20)
+#define HCR_TSC                (1<<19)
+#define HCR_TID3        (1<<18)
+#define HCR_TID2        (1<<17)
+#define HCR_TID1        (1<<16)
+#define HCR_TID0        (1<<15)
+#define HCR_TWE                (1<<14)
+#define HCR_TWI                (1<<13)
+#define HCR_DC                (1<<12)
+#define HCR_BSU_MASK        (3<<10)
+#define HCR_FB                (1<<9)
+#define HCR_VA                (1<<8)
+#define HCR_VI                (1<<7)
+#define HCR_VF                (1<<6)
+#define HCR_AMO                (1<<5)
+#define HCR_IMO                (1<<4)
+#define HCR_FMO                (1<<3)
+#define HCR_PTW                (1<<2)
+#define HCR_SWIO        (1<<1)
+#define HCR_VM                (1<<0)
+
+#define HSR_EC_WFI_WFE              0x01
+#define HSR_EC_CP15_32              0x03
+#define HSR_EC_CP15_64              0x04
+#define HSR_EC_CP14_32              0x05
+#define HSR_EC_CP14_DBG             0x06
+#define HSR_EC_CP                   0x07
+#define HSR_EC_CP10                 0x08
+#define HSR_EC_JAZELLE              0x09
+#define HSR_EC_BXJ                  0x0a
+#define HSR_EC_CP14_64              0x0c
+#define HSR_EC_SVC                  0x11
+#define HSR_EC_HVC                  0x12
+#define HSR_EC_INSTR_ABORT_GUEST    0x20
+#define HSR_EC_INSTR_ABORT_HYP      0x21
+#define HSR_EC_DATA_ABORT_GUEST     0x24
+#define HSR_EC_DATA_ABORT_HYP       0x25
+
+#ifndef __ASSEMBLY__
+union hsr {
+    uint32_t bits;
+    struct {
+        unsigned long iss:25;  /* Instruction Specific Syndrome */
+        unsigned long len:1;   /* Instruction length */
+        unsigned long ec:6;    /* Exception Class */
+    };
+
+    struct hsr_cp32 {
+        unsigned long read:1;  /* Direction */
+        unsigned long crm:4;   /* CRm */
+        unsigned long reg:4;   /* Rt */
+        unsigned long sbzp:1;
+        unsigned long crn:4;   /* CRn */
+        unsigned long op1:3;   /* Op1 */
+        unsigned long op2:3;   /* Op2 */
+        unsigned long cc:4;    /* Condition Code */
+        unsigned long ccvalid:1;/* CC Valid */
+        unsigned long len:1;   /* Instruction length */
+        unsigned long ec:6;    /* Exception Class */
+    } cp32; /* HSR_EC_CP15_32, CP14_32, CP10 */
+
+    struct hsr_cp64 {
+        unsigned long read:1;   /* Direction */
+        unsigned long crm:4;    /* CRm */
+        unsigned long reg1:4;   /* Rt1 */
+        unsigned long sbzp1:1;
+        unsigned long reg2:4;   /* Rt2 */
+        unsigned long sbzp2:2;
+        unsigned long op1:4;   /* Op1 */
+        unsigned long cc:4;    /* Condition Code */
+        unsigned long ccvalid:1;/* CC Valid */
+        unsigned long len:1;   /* Instruction length */
+        unsigned long ec:6;    /* Exception Class */
+    } cp64; /* HSR_EC_CP15_64, HSR_EC_CP14_64 */
+
+    struct hsr_dabt {
+        unsigned long dfsc:6;  /* Data Fault Status Code */
+        unsigned long write:1; /* Write / not Read */
+        unsigned long s1ptw:1; /* */
+        unsigned long cache:1; /* Cache Maintenance */
+        unsigned long eat:1;   /* External Abort Type */
+        unsigned long sbzp0:6;
+        unsigned long reg:4;   /* Register */
+        unsigned long sbzp1:1;
+        unsigned long sign:1;  /* Sign extend */
+        unsigned long size:2;  /* Access Size */
+        unsigned long valid:1; /* Syndrome Valid */
+        unsigned long len:1;   /* Instruction length */
+        unsigned long ec:6;    /* Exception Class */
+    } dabt; /* HSR_EC_DATA_ABORT_* */
+};
+#endif
+
+/* HSR.EC == HSR_CP{15,14,10}_32 */
+#define HSR_CP32_OP2_MASK (0x000e0000)
+#define HSR_CP32_OP2_SHIFT (17)
+#define HSR_CP32_OP1_MASK (0x0001c000)
+#define HSR_CP32_OP1_SHIFT (14)
+#define HSR_CP32_CRN_MASK (0x00003c00)
+#define HSR_CP32_CRN_SHIFT (10)
+#define HSR_CP32_CRM_MASK (0x0000001e)
+#define HSR_CP32_CRM_SHIFT (1)
+#define HSR_CP32_REGS_MASK (HSR_CP32_OP1_MASK|HSR_CP32_OP2_MASK|\
+                            HSR_CP32_CRN_MASK|HSR_CP32_CRM_MASK)
+
+/* HSR.EC == HSR_CP{15,14}_64 */
+#define HSR_CP64_OP1_MASK (0x000f0000)
+#define HSR_CP64_OP1_SHIFT (16)
+#define HSR_CP64_CRM_MASK (0x0000001e)
+#define HSR_CP64_CRM_SHIFT (1)
+#define HSR_CP64_REGS_MASK (HSR_CP64_OP1_MASK|HSR_CP64_CRM_MASK)
+
+/* Physical Address Register */
+#define PAR_F           (1<<0)
+
+/* .... If F == 1 */
+#define PAR_FSC_SHIFT   (1)
+#define PAR_FSC_MASK    (0x3f<<PAR_FSC_SHIFT)
+#define PAR_STAGE21     (1<<8)     /* Stage 2 Fault During Stage 1 Walk */
+#define PAR_STAGE2      (1<<9)     /* Stage 2 Fault */
+
+/* If F == 0 */
+#define PAR_MAIR_SHIFT  56                       /* Memory Attributes */
+#define PAR_MAIR_MASK   (0xffLL<<PAR_MAIR_SHIFT)
+#define PAR_NS          (1<<9)                   /* Non-Secure */
+#define PAR_SH_SHIFT    7                        /* Shareability */
+#define PAR_SH_MASK     (3<<PAR_SH_SHIFT)
+
+/* Fault Status Register */
+/*
+ * 543210 BIT
+ * 00XXLL -- XX Fault Level LL
+ * ..01LL -- Translation Fault LL
+ * ..10LL -- Access Fault LL
+ * ..11LL -- Permission Fault LL
+ * 01xxxx -- Abort/Parity
+ * 10xxxx -- Other
+ * 11xxxx -- Implementation Defined
+ */
+#define FSC_TYPE_MASK (0x3<<4)
+#define FSC_TYPE_FAULT (0x00<<4)
+#define FSC_TYPE_ABT   (0x01<<4)
+#define FSC_TYPE_OTH   (0x02<<4)
+#define FSC_TYPE_IMPL  (0x03<<4)
+
+#define FSC_FLT_TRANS  (0x04)
+#define FSC_FLT_ACCESS (0x08)
+#define FSC_FLT_PERM   (0x0c)
+#define FSC_SEA        (0x10) /* Synchronous External Abort */
+#define FSC_SPE        (0x18) /* Memory Access Synchronous Parity Error */
+#define FSC_APE        (0x11) /* Memory Access Asynchronous Parity Error */
+#define FSC_SEATT      (0x14) /* Sync. Ext. Abort Translation Table */
+#define FSC_SPETT      (0x1c) /* Sync. Parity. Error Translation Table */
+#define FSC_AF         (0x21) /* Alignment Fault */
+#define FSC_DE         (0x22) /* Debug Event */
+#define FSC_LKD        (0x34) /* Lockdown Abort */
+#define FSC_CPR        (0x3a) /* Coprocossor Abort */
+
+#define FSC_LL_MASK    (0x03<<0)
+
+/* Time counter hypervisor control register */
+#define CNTHCTL_PA      (1u<<0)  /* Kernel/user access to physical counter */
+#define CNTHCTL_TA      (1u<<1)  /* Kernel/user access to CNTP timer */
+
+/* Timer control registers */
+#define CNTx_CTL_ENABLE   (1u<<0)  /* Enable timer */
+#define CNTx_CTL_MASK     (1u<<1)  /* Mask IRQ */
+#define CNTx_CTL_PENDING  (1u<<2)  /* IRQ pending */
+
+/* CPUID bits */
+#define ID_PFR1_GT_MASK  0x000F0000  /* Generic Timer interface support */
+#define ID_PFR1_GT_v1    0x00010000
+
+#define MSR(reg,val)        asm volatile ("msr "#reg", %0\n" : : "r" (val))
+#define MRS(val,reg)        asm volatile ("mrs %0,"#reg"\n" : "=r" (v))
+
+#ifndef __ASSEMBLY__
+extern uint32_t hyp_traps_vector[8];
+
+void panic_PAR(uint64_t par, const char *when);
+
+void show_execution_state(struct cpu_user_regs *regs);
+void show_registers(struct cpu_user_regs *regs);
+//#define dump_execution_state() run_in_exception_handler(show_execution_state)
+#define dump_execution_state() asm volatile (".word 0xe7f000f0\n"); /* XXX */
+
+#define cpu_relax() barrier() /* Could yield? */
+
+/* All a bit UP for the moment */
+#define cpu_to_core(_cpu)   (0)
+#define cpu_to_socket(_cpu) (0)
+
+#endif /* __ASSEMBLY__ */
+#endif /* __ASM_ARM_PROCESSOR_H */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/regs.h b/xen/include/asm-arm/regs.h
new file mode 100644
index 0000000..ee095bf
--- /dev/null
+++ b/xen/include/asm-arm/regs.h
@@ -0,0 +1,43 @@
+#ifndef __ARM_REGS_H__
+#define __ARM_REGS_H__
+
+#include <xen/types.h>
+#include <public/xen.h>
+#include <asm/processor.h>
+
+#define psr_mode(psr,m) (((psr) & PSR_MODE_MASK) == m)
+
+#define usr_mode(r)     psr_mode((r)->cpsr,PSR_MODE_USR)
+#define fiq_mode(r)     psr_mode((r)->cpsr,PSR_MODE_FIQ)
+#define irq_mode(r)     psr_mode((r)->cpsr,PSR_MODE_IRQ)
+#define svc_mode(r)     psr_mode((r)->cpsr,PSR_MODE_SVC)
+#define mon_mode(r)     psr_mode((r)->cpsr,PSR_MODE_MON)
+#define abt_mode(r)     psr_mode((r)->cpsr,PSR_MODE_ABT)
+#define hyp_mode(r)     psr_mode((r)->cpsr,PSR_MODE_HYP)
+#define und_mode(r)     psr_mode((r)->cpsr,PSR_MODE_UND)
+#define sys_mode(r)     psr_mode((r)->cpsr,PSR_MODE_SYS)
+
+#define guest_mode(r)                                                         \
+({                                                                            \
+    unsigned long diff = (char *)guest_cpu_user_regs() - (char *)(r);         \
+    /* Frame pointer must point into current CPU stack. */                    \
+    ASSERT(diff < STACK_SIZE);                                                \
+    /* If not a guest frame, it must be a hypervisor frame. */                \
+    ASSERT((diff == 0) || hyp_mode(r));                                       \
+    /* Return TRUE if it's a guest frame. */                                  \
+    (diff == 0);                                                              \
+})
+
+#define return_reg(v) ((v)->arch.user_regs.r0)
+
+#define CTXT_SWITCH_STACK_BYTES (sizeof(struct cpu_user_regs))
+
+#endif /* __ARM_REGS_H__ */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/setup.h b/xen/include/asm-arm/setup.h
new file mode 100644
index 0000000..c27d438
--- /dev/null
+++ b/xen/include/asm-arm/setup.h
@@ -0,0 +1,16 @@
+#ifndef __ARM_SETUP_H_
+#define __ARM_SETUP_H_
+
+#include <public/version.h>
+
+void arch_get_xen_caps(xen_capabilities_info_t *info);
+
+#endif
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/smp.h b/xen/include/asm-arm/smp.h
new file mode 100644
index 0000000..9cdd87f
--- /dev/null
+++ b/xen/include/asm-arm/smp.h
@@ -0,0 +1,25 @@
+#ifndef __ASM_SMP_H
+#define __ASM_SMP_H
+
+#ifndef __ASSEMBLY__
+#include <xen/config.h>
+#include <xen/cpumask.h>
+#include <asm/current.h>
+#endif
+
+DECLARE_PER_CPU(cpumask_var_t, cpu_sibling_mask);
+DECLARE_PER_CPU(cpumask_var_t, cpu_core_mask);
+
+#define cpu_is_offline(cpu) unlikely(!cpu_online(cpu))
+
+#define raw_smp_processor_id() (get_processor_id())
+
+#endif
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/softirq.h b/xen/include/asm-arm/softirq.h
new file mode 100644
index 0000000..536af38
--- /dev/null
+++ b/xen/include/asm-arm/softirq.h
@@ -0,0 +1,15 @@
+#ifndef __ASM_SOFTIRQ_H__
+#define __ASM_SOFTIRQ_H__
+
+#define VGIC_SOFTIRQ        (NR_COMMON_SOFTIRQS + 0)
+#define NR_ARCH_SOFTIRQS       1
+
+#endif /* __ASM_SOFTIRQ_H__ */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/spinlock.h b/xen/include/asm-arm/spinlock.h
new file mode 100644
index 0000000..b1825c9
--- /dev/null
+++ b/xen/include/asm-arm/spinlock.h
@@ -0,0 +1,144 @@
+#ifndef __ASM_SPINLOCK_H
+#define __ASM_SPINLOCK_H
+
+#include <xen/config.h>
+#include <xen/lib.h>
+
+static inline void dsb_sev(void)
+{
+    __asm__ __volatile__ (
+        "dsb\n"
+        "sev\n"
+        );
+}
+
+typedef struct {
+    volatile unsigned int lock;
+} raw_spinlock_t;
+
+#define _RAW_SPIN_LOCK_UNLOCKED { 0 }
+
+#define _raw_spin_is_locked(x)          ((x)->lock != 0)
+
+static always_inline void _raw_spin_unlock(raw_spinlock_t *lock)
+{
+    ASSERT(_raw_spin_is_locked(lock));
+
+    smp_mb();
+
+    __asm__ __volatile__(
+"   str     %1, [%0]\n"
+    :
+    : "r" (&lock->lock), "r" (0)
+    : "cc");
+
+    dsb_sev();
+}
+
+static always_inline int _raw_spin_trylock(raw_spinlock_t *lock)
+{
+    unsigned long tmp;
+
+    __asm__ __volatile__(
+"   ldrex   %0, [%1]\n"
+"   teq     %0, #0\n"
+"   strexeq %0, %2, [%1]"
+    : "=&r" (tmp)
+    : "r" (&lock->lock), "r" (1)
+    : "cc");
+
+    if (tmp == 0) {
+        smp_mb();
+        return 1;
+    } else {
+        return 0;
+    }
+}
+
+typedef struct {
+    volatile unsigned int lock;
+} raw_rwlock_t;
+
+#define _RAW_RW_LOCK_UNLOCKED { 0 }
+
+static always_inline int _raw_read_trylock(raw_rwlock_t *rw)
+{
+    unsigned long tmp, tmp2 = 1;
+
+    __asm__ __volatile__(
+"1: ldrex   %0, [%2]\n"
+"   adds    %0, %0, #1\n"
+"   strexpl %1, %0, [%2]\n"
+    : "=&r" (tmp), "+r" (tmp2)
+    : "r" (&rw->lock)
+    : "cc");
+
+    smp_mb();
+    return tmp2 == 0;
+}
+
+static always_inline int _raw_write_trylock(raw_rwlock_t *rw)
+{
+    unsigned long tmp;
+
+    __asm__ __volatile__(
+"1: ldrex   %0, [%1]\n"
+"   teq     %0, #0\n"
+"   strexeq %0, %2, [%1]"
+    : "=&r" (tmp)
+    : "r" (&rw->lock), "r" (0x80000000)
+    : "cc");
+
+    if (tmp == 0) {
+        smp_mb();
+        return 1;
+    } else {
+        return 0;
+    }
+}
+
+static inline void _raw_read_unlock(raw_rwlock_t *rw)
+{
+    unsigned long tmp, tmp2;
+
+    smp_mb();
+
+    __asm__ __volatile__(
+"1: ldrex   %0, [%2]\n"
+"   sub     %0, %0, #1\n"
+"   strex   %1, %0, [%2]\n"
+"   teq     %1, #0\n"
+"   bne     1b"
+    : "=&r" (tmp), "=&r" (tmp2)
+    : "r" (&rw->lock)
+    : "cc");
+
+    if (tmp == 0)
+        dsb_sev();
+}
+
+static inline void _raw_write_unlock(raw_rwlock_t *rw)
+{
+    smp_mb();
+
+    __asm__ __volatile__(
+    "str    %1, [%0]\n"
+    :
+    : "r" (&rw->lock), "r" (0)
+    : "cc");
+
+    dsb_sev();
+}
+
+#define _raw_rw_is_locked(x) ((x)->lock != 0)
+#define _raw_rw_is_write_locked(x) ((x)->lock == 0x80000000)
+
+#endif /* __ASM_SPINLOCK_H */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/string.h b/xen/include/asm-arm/string.h
new file mode 100644
index 0000000..f2d643d
--- /dev/null
+++ b/xen/include/asm-arm/string.h
@@ -0,0 +1,38 @@
+#ifndef __ARM_STRING_H__
+#define __ARM_STRING_H__
+
+#include <xen/config.h>
+
+#define __HAVE_ARCH_MEMCPY
+extern void * memcpy(void *, const void *, __kernel_size_t);
+
+/* Some versions of gcc don't have this builtin. It's non-critical anyway. */
+#define __HAVE_ARCH_MEMMOVE
+extern void *memmove(void *dest, const void *src, size_t n);
+
+#define __HAVE_ARCH_MEMSET
+extern void * memset(void *, int, __kernel_size_t);
+
+extern void __memzero(void *ptr, __kernel_size_t n);
+
+#define memset(p,v,n)                                                   \
+        ({                                                              \
+                void *__p = (p); size_t __n = n;                        \
+                if ((__n) != 0) {                                       \
+                        if (__builtin_constant_p((v)) && (v) == 0)      \
+                                __memzero((__p),(__n));                 \
+                        else                                            \
+                                memset((__p),(v),(__n));                \
+                }                                                       \
+                (__p);                                                  \
+        })
+
+#endif /* __ARM_STRING_H__ */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/system.h b/xen/include/asm-arm/system.h
new file mode 100644
index 0000000..731d89f
--- /dev/null
+++ b/xen/include/asm-arm/system.h
@@ -0,0 +1,202 @@
+/* Portions taken from Linux arch arm */
+#ifndef __ASM_SYSTEM_H
+#define __ASM_SYSTEM_H
+
+#include <xen/lib.h>
+#include <asm/processor.h>
+
+#define nop() \
+    asm volatile ( "nop" )
+
+#define xchg(ptr,x) \
+        ((__typeof__(*(ptr)))__xchg((unsigned long)(x),(ptr),sizeof(*(ptr))))
+
+#define isb() __asm__ __volatile__ ("isb" : : : "memory")
+#define dsb() __asm__ __volatile__ ("dsb" : : : "memory")
+#define dmb() __asm__ __volatile__ ("dmb" : : : "memory")
+
+#define mb()            dsb()
+#define rmb()           dsb()
+#define wmb()           mb()
+
+#define smp_mb()        dmb()
+#define smp_rmb()       dmb()
+#define smp_wmb()       dmb()
+
+/*
+ * This is used to ensure the compiler did actually allocate the register we
+ * asked it for some inline assembly sequences.  Apparently we can't trust
+ * the compiler from one version to another so a bit of paranoia won't hurt.
+ * This string is meant to be concatenated with the inline asm string and
+ * will cause compilation to stop on mismatch.
+ * (for details, see gcc PR 15089)
+ */
+#define __asmeq(x, y)  ".ifnc " x "," y " ; .err ; .endif\n\t"
+
+extern void __bad_xchg(volatile void *, int);
+
+static inline unsigned long __xchg(unsigned long x, volatile void *ptr, int size)
+{
+        unsigned long ret;
+        unsigned int tmp;
+
+        smp_mb();
+
+        switch (size) {
+        case 1:
+                asm volatile("@ __xchg1\n"
+                "1:     ldrexb  %0, [%3]\n"
+                "       strexb  %1, %2, [%3]\n"
+                "       teq     %1, #0\n"
+                "       bne     1b"
+                        : "=&r" (ret), "=&r" (tmp)
+                        : "r" (x), "r" (ptr)
+                        : "memory", "cc");
+                break;
+        case 4:
+                asm volatile("@ __xchg4\n"
+                "1:     ldrex   %0, [%3]\n"
+                "       strex   %1, %2, [%3]\n"
+                "       teq     %1, #0\n"
+                "       bne     1b"
+                        : "=&r" (ret), "=&r" (tmp)
+                        : "r" (x), "r" (ptr)
+                        : "memory", "cc");
+                break;
+        default:
+                __bad_xchg(ptr, size), ret = 0;
+                break;
+        }
+        smp_mb();
+
+        return ret;
+}
+
+/*
+ * Atomic compare and exchange.  Compare OLD with MEM, if identical,
+ * store NEW in MEM.  Return the initial value in MEM.  Success is
+ * indicated by comparing RETURN with OLD.
+ */
+
+extern void __bad_cmpxchg(volatile void *ptr, int size);
+
+static always_inline unsigned long __cmpxchg(
+    volatile void *ptr, unsigned long old, unsigned long new, int size)
+{
+    unsigned long /*long*/ oldval, res;
+
+    switch (size) {
+    case 1:
+        do {
+            asm volatile("@ __cmpxchg1\n"
+                         "       ldrexb  %1, [%2]\n"
+                         "       mov     %0, #0\n"
+                         "       teq     %1, %3\n"
+                         "       strexbeq %0, %4, [%2]\n"
+                         : "=&r" (res), "=&r" (oldval)
+                         : "r" (ptr), "Ir" (old), "r" (new)
+                         : "memory", "cc");
+        } while (res);
+        break;
+    case 2:
+        do {
+            asm volatile("@ __cmpxchg2\n"
+                         "       ldrexh  %1, [%2]\n"
+                         "       mov     %0, #0\n"
+                         "       teq     %1, %3\n"
+                         "       strexheq %0, %4, [%2]\n"
+                         : "=&r" (res), "=&r" (oldval)
+                         : "r" (ptr), "Ir" (old), "r" (new)
+                         : "memory", "cc");
+        } while (res);
+        break;
+    case 4:
+        do {
+            asm volatile("@ __cmpxchg4\n"
+                         "       ldrex   %1, [%2]\n"
+                         "       mov     %0, #0\n"
+                         "       teq     %1, %3\n"
+                         "       strexeq %0, %4, [%2]\n"
+                         : "=&r" (res), "=&r" (oldval)
+                         : "r" (ptr), "Ir" (old), "r" (new)
+                         : "memory", "cc");
+        } while (res);
+        break;
+#if 0
+    case 8:
+        do {
+            asm volatile("@ __cmpxchg8\n"
+                         "       ldrexd   %1, [%2]\n"
+                         "       mov      %0, #0\n"
+                         "       teq      %1, %3\n"
+                         "       strexdeq %0, %4, [%2]\n"
+                         : "=&r" (res), "=&r" (oldval)
+                         : "r" (ptr), "Ir" (old), "r" (new)
+                         : "memory", "cc");
+        } while (res);
+        break;
+#endif
+    default:
+        __bad_cmpxchg(ptr, size);
+        oldval = 0;
+    }
+
+    return oldval;
+}
+#define cmpxchg(ptr,o,n)                                                \
+    ((__typeof__(*(ptr)))__cmpxchg((ptr),(unsigned long)(o),            \
+                                   (unsigned long)(n),sizeof(*(ptr))))
+
+#define local_irq_disable() asm volatile ( "cpsid i @ local_irq_disable\n" : : : "cc" )
+#define local_irq_enable()  asm volatile ( "cpsie i @ local_irq_enable\n" : : : "cc" )
+
+#define local_save_flags(x)                                      \
+({                                                               \
+    BUILD_BUG_ON(sizeof(x) != sizeof(long));                     \
+    asm volatile ( "mrs %0, cpsr     @ local_save_flags\n"       \
+                  : "=r" (x) :: "memory", "cc" );                \
+})
+#define local_irq_save(x)                                        \
+({                                                               \
+    local_save_flags(x);                                         \
+    local_irq_disable();                                         \
+})
+#define local_irq_restore(x)                                     \
+({                                                               \
+    BUILD_BUG_ON(sizeof(x) != sizeof(long));                     \
+    asm volatile (                                               \
+            "msr     cpsr_c, %0      @ local_irq_restore\n"      \
+            :                                                    \
+            : "r" (flags)                                        \
+            : "memory", "cc");                                   \
+})
+
+static inline int local_irq_is_enabled(void)
+{
+    unsigned long flags;
+    local_save_flags(flags);
+    return !(flags & PSR_IRQ_MASK);
+}
+
+#define local_fiq_enable()  __asm__("cpsie f   @ __stf\n" : : : "memory", "cc")
+#define local_fiq_disable() __asm__("cpsid f   @ __clf\n" : : : "memory", "cc")
+
+#define local_abort_enable() __asm__("cpsie a  @ __sta\n" : : : "memory", "cc")
+#define local_abort_disable() __asm__("cpsid a @ __sta\n" : : : "memory", "cc")
+
+static inline int local_fiq_is_enabled(void)
+{
+    unsigned long flags;
+    local_save_flags(flags);
+    return !!(flags & PSR_FIQ_MASK);
+}
+
+#endif
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/trace.h b/xen/include/asm-arm/trace.h
new file mode 100644
index 0000000..db84541
--- /dev/null
+++ b/xen/include/asm-arm/trace.h
@@ -0,0 +1,12 @@
+#ifndef __ASM_TRACE_H__
+#define __ASM_TRACE_H__
+
+#endif /* __ASM_TRACE_H__ */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/types.h b/xen/include/asm-arm/types.h
new file mode 100644
index 0000000..48864f9
--- /dev/null
+++ b/xen/include/asm-arm/types.h
@@ -0,0 +1,57 @@
+#ifndef __ARM_TYPES_H__
+#define __ARM_TYPES_H__
+
+#ifndef __ASSEMBLY__
+
+#include <xen/config.h>
+
+typedef __signed__ char __s8;
+typedef unsigned char __u8;
+
+typedef __signed__ short __s16;
+typedef unsigned short __u16;
+
+typedef __signed__ int __s32;
+typedef unsigned int __u32;
+
+#if defined(__GNUC__) && !defined(__STRICT_ANSI__)
+typedef __signed__ long long __s64;
+typedef unsigned long long __u64;
+#endif
+
+typedef signed char s8;
+typedef unsigned char u8;
+
+typedef signed short s16;
+typedef unsigned short u16;
+
+typedef signed int s32;
+typedef unsigned int u32;
+
+typedef signed long long s64;
+typedef unsigned long long u64;
+typedef u64 paddr_t;
+#define INVALID_PADDR (~0ULL)
+#define PRIpaddr "016llx"
+
+typedef unsigned long size_t;
+
+typedef char bool_t;
+#define test_and_set_bool(b)   xchg(&(b), 1)
+#define test_and_clear_bool(b) xchg(&(b), 0)
+
+#endif /* __ASSEMBLY__ */
+
+#define BITS_PER_LONG 32
+#define BYTES_PER_LONG 4
+#define LONG_BYTEORDER 2
+
+#endif /* __ARM_TYPES_H__ */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/xenoprof.h b/xen/include/asm-arm/xenoprof.h
new file mode 100644
index 0000000..131ac13
--- /dev/null
+++ b/xen/include/asm-arm/xenoprof.h
@@ -0,0 +1,12 @@
+#ifndef __ASM_XENOPROF_H__
+#define __ASM_XENOPROF_H__
+
+#endif /* __ASM_XENOPROF_H__ */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
new file mode 100644
index 0000000..4d1daa9
--- /dev/null
+++ b/xen/include/public/arch-arm.h
@@ -0,0 +1,125 @@
+/******************************************************************************
+ * arch-arm.h
+ *
+ * Guest OS interface to ARM 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 2011 (C) Citrix Systems
+ */
+
+#ifndef __XEN_PUBLIC_ARCH_ARM_H__
+#define __XEN_PUBLIC_ARCH_ARM_H__
+
+#ifndef __ASSEMBLY__
+#define ___DEFINE_XEN_GUEST_HANDLE(name, type) \
+    typedef struct { type *p; } __guest_handle_ ## name
+
+#define __DEFINE_XEN_GUEST_HANDLE(name, type) \
+    ___DEFINE_XEN_GUEST_HANDLE(name, type);   \
+    ___DEFINE_XEN_GUEST_HANDLE(const_##name, const type)
+#define DEFINE_XEN_GUEST_HANDLE(name)   __DEFINE_XEN_GUEST_HANDLE(name, name)
+#define __XEN_GUEST_HANDLE(name)        __guest_handle_ ## name
+#define XEN_GUEST_HANDLE(name)          __XEN_GUEST_HANDLE(name)
+#define set_xen_guest_handle_raw(hnd, val)  do { (hnd).p = val; } while (0)
+#ifdef __XEN_TOOLS__
+#define get_xen_guest_handle(val, hnd)  do { val = (hnd).p; } while (0)
+#endif
+#define set_xen_guest_handle(hnd, val) set_xen_guest_handle_raw(hnd, val)
+
+struct cpu_user_regs
+{
+    uint32_t r0;
+    uint32_t r1;
+    uint32_t r2;
+    uint32_t r3;
+    uint32_t r4;
+    uint32_t r5;
+    uint32_t r6;
+    uint32_t r7;
+    uint32_t r8;
+    uint32_t r9;
+    uint32_t r10;
+    union {
+	uint32_t r11;
+	uint32_t fp;
+    };
+    uint32_t r12;
+
+    uint32_t sp; /* r13 - SP: Valid for Hyp. frames only, o/w banked (see below) */
+    uint32_t lr; /* r14 - LR: Valid for Hyp. Same physical register as lr_usr. */
+
+    uint32_t pc; /* Return IP */
+    uint32_t cpsr; /* Return mode */
+    uint32_t pad0; /* Doubleword-align the kernel half of the frame */
+
+    /* Outer guest frame only from here on... */
+
+    uint32_t r8_fiq, r9_fiq, r10_fiq, r11_fiq, r12_fiq;
+
+    uint32_t sp_usr, sp_svc, sp_abt, sp_und, sp_irq, sp_fiq;
+    uint32_t lr_usr, lr_svc, lr_abt, lr_und, lr_irq, lr_fiq;
+
+    uint32_t spsr_svc, spsr_abt, spsr_und, spsr_irq, spsr_fiq;
+};
+typedef struct cpu_user_regs cpu_user_regs_t;
+DEFINE_XEN_GUEST_HANDLE(cpu_user_regs_t);
+
+typedef uint64_t xen_pfn_t;
+#define PRI_xen_pfn PRIx64
+
+/* Maximum number of virtual CPUs in legacy multi-processor guests. */
+/* Only one. All other VCPUS must use VCPUOP_register_vcpu_info */
+#define XEN_LEGACY_MAX_VCPUS 1
+
+typedef uint32_t xen_ulong_t;
+
+struct vcpu_guest_context {
+    struct cpu_user_regs user_regs;         /* User-level CPU registers     */
+    union {
+	uint32_t reg[16];
+	struct {
+	    uint32_t __pad[12];
+	    uint32_t sp; /* r13 */
+	    uint32_t lr; /* r14 */
+	    uint32_t pc; /* r15 */
+	};
+    };
+};
+typedef struct vcpu_guest_context vcpu_guest_context_t;
+DEFINE_XEN_GUEST_HANDLE(vcpu_guest_context_t);
+
+struct arch_vcpu_info { };
+typedef struct arch_vcpu_info arch_vcpu_info_t;
+
+struct arch_shared_info { };
+typedef struct arch_shared_info arch_shared_info_t;
+#endif
+
+#endif /*  __XEN_PUBLIC_ARCH_ARM_H__ */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
index fde9fa5..7196400 100644
--- a/xen/include/public/xen.h
+++ b/xen/include/public/xen.h
@@ -33,6 +33,8 @@
 #include "arch-x86/xen.h"
 #elif defined(__ia64__)
 #include "arch-ia64.h"
+#elif defined(__arm__)
+#include "arch-arm.h"
 #else
 #error "Unsupported architecture"
 #endif
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 13:14:32 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 13:14:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZ0HA-0002K8-Cx; Fri, 09 Dec 2011 13:14:08 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RZ0H7-0002I7-My
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 13:14:06 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1323436276!47643481!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMTkxNzY=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30516 invoked from network); 9 Dec 2011 13:11:17 -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 2011 13:11:17 -0000
X-IronPort-AV: E=Sophos;i="4.71,325,1320642000"; d="scan'208";a="173546263"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 08:13:19 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 08:13:19 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pB9DCpDu008248;
	Fri, 9 Dec 2011 05:13:07 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 9 Dec 2011 13:13:13 +0000
Message-ID: <1323436408-16335-10-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1112091208420.3517@kaball-desktop>
References: <alpine.DEB.2.00.1112091208420.3517@kaball-desktop>
MIME-Version: 1.0
Cc: keir.xen@gmail.com, Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, JBeulich@suse.com,
	Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v2 10/25] arm: bit manipulation,
	copy and division libraries
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Bit manipulation, division and memcpy & friends implementations for the
ARM architecture, shamelessly taken from Linux.


Changes in v2:

- implement __aeabi_uldivmod and __aeabi_ldivmod.


Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
---
 xen/arch/arm/lib/Makefile        |    5 +
 xen/arch/arm/lib/assembler.h     |   49 ++++++
 xen/arch/arm/lib/bitops.h        |   36 +++++
 xen/arch/arm/lib/changebit.S     |   18 +++
 xen/arch/arm/lib/clearbit.S      |   19 +++
 xen/arch/arm/lib/copy_template.S |  266 +++++++++++++++++++++++++++++++++
 xen/arch/arm/lib/div64.S         |  149 +++++++++++++++++++
 xen/arch/arm/lib/findbit.S       |  115 +++++++++++++++
 xen/arch/arm/lib/lib1funcs.S     |  302 ++++++++++++++++++++++++++++++++++++++
 xen/arch/arm/lib/memcpy.S        |   64 ++++++++
 xen/arch/arm/lib/memmove.S       |  200 +++++++++++++++++++++++++
 xen/arch/arm/lib/memset.S        |  129 ++++++++++++++++
 xen/arch/arm/lib/memzero.S       |  127 ++++++++++++++++
 xen/arch/arm/lib/setbit.S        |   18 +++
 xen/arch/arm/lib/testchangebit.S |   18 +++
 xen/arch/arm/lib/testclearbit.S  |   18 +++
 xen/arch/arm/lib/testsetbit.S    |   18 +++
 17 files changed, 1551 insertions(+), 0 deletions(-)
 create mode 100644 xen/arch/arm/lib/Makefile
 create mode 100644 xen/arch/arm/lib/assembler.h
 create mode 100644 xen/arch/arm/lib/bitops.h
 create mode 100644 xen/arch/arm/lib/changebit.S
 create mode 100644 xen/arch/arm/lib/clearbit.S
 create mode 100644 xen/arch/arm/lib/copy_template.S
 create mode 100644 xen/arch/arm/lib/div64.S
 create mode 100644 xen/arch/arm/lib/findbit.S
 create mode 100644 xen/arch/arm/lib/lib1funcs.S
 create mode 100644 xen/arch/arm/lib/memcpy.S
 create mode 100644 xen/arch/arm/lib/memmove.S
 create mode 100644 xen/arch/arm/lib/memset.S
 create mode 100644 xen/arch/arm/lib/memzero.S
 create mode 100644 xen/arch/arm/lib/setbit.S
 create mode 100644 xen/arch/arm/lib/testchangebit.S
 create mode 100644 xen/arch/arm/lib/testclearbit.S
 create mode 100644 xen/arch/arm/lib/testsetbit.S

diff --git a/xen/arch/arm/lib/Makefile b/xen/arch/arm/lib/Makefile
new file mode 100644
index 0000000..cbbed68
--- /dev/null
+++ b/xen/arch/arm/lib/Makefile
@@ -0,0 +1,5 @@
+obj-y += memcpy.o memmove.o memset.o memzero.o
+obj-y += findbit.o setbit.o
+obj-y += setbit.o clearbit.o changebit.o
+obj-y += testsetbit.o testclearbit.o testchangebit.o
+obj-y += lib1funcs.o div64.o
diff --git a/xen/arch/arm/lib/assembler.h b/xen/arch/arm/lib/assembler.h
new file mode 100644
index 0000000..f8f0961
--- /dev/null
+++ b/xen/arch/arm/lib/assembler.h
@@ -0,0 +1,49 @@
+#ifndef __ARCH_ARM_LIB_ASSEMBLER_H__
+#define __ARCH_ARM_LIB_ASSEMBLER_H__
+
+/* From Linux arch/arm/include/asm/assembler.h */
+/*
+ * Data preload for architectures that support it
+ */
+#define PLD(code...)    code
+
+/*
+ * This can be used to enable code to cacheline align the destination
+ * pointer when bulk writing to memory.  Experiments on StrongARM and
+ * XScale didn't show this a worthwhile thing to do when the cache is not
+ * set to write-allocate (this would need further testing on XScale when WA
+ * is used).
+ *
+ * On Feroceon there is much to gain however, regardless of cache mode.
+ */
+#ifdef CONFIG_CPU_FEROCEON /* Not in Xen... */
+#define CALGN(code...) code
+#else
+#define CALGN(code...)
+#endif
+
+// No Thumb, hence:
+#define W(instr)        instr
+#define ARM(instr...)   instr
+#define THUMB(instr...)
+
+#ifdef CONFIG_ARM_UNWIND
+#define UNWIND(code...)         code
+#else
+#define UNWIND(code...)
+#endif
+
+#define pull            lsl
+#define push            lsr
+#define get_byte_0      lsr #24
+#define get_byte_1      lsr #16
+#define get_byte_2      lsr #8
+#define get_byte_3      lsl #0
+#define put_byte_0      lsl #24
+#define put_byte_1      lsl #16
+#define put_byte_2      lsl #8
+#define put_byte_3      lsl #0
+
+#define smp_dmb dmb
+
+#endif /*  __ARCH_ARM_LIB_ASSEMBLER_H__ */
diff --git a/xen/arch/arm/lib/bitops.h b/xen/arch/arm/lib/bitops.h
new file mode 100644
index 0000000..e56d4e8
--- /dev/null
+++ b/xen/arch/arm/lib/bitops.h
@@ -0,0 +1,36 @@
+	.macro	bitop, instr
+	ands	ip, r1, #3
+	strneb	r1, [ip]		@ assert word-aligned
+	mov	r2, #1
+	and	r3, r0, #31		@ Get bit offset
+	mov	r0, r0, lsr #5
+	add	r1, r1, r0, lsl #2	@ Get word offset
+	mov	r3, r2, lsl r3
+1:	ldrex	r2, [r1]
+	\instr	r2, r2, r3
+	strex	r0, r2, [r1]
+	cmp	r0, #0
+	bne	1b
+	bx	lr
+	.endm
+
+	.macro	testop, instr, store
+	ands	ip, r1, #3
+	strneb	r1, [ip]		@ assert word-aligned
+	mov	r2, #1
+	and	r3, r0, #31		@ Get bit offset
+	mov	r0, r0, lsr #5
+	add	r1, r1, r0, lsl #2	@ Get word offset
+	mov	r3, r2, lsl r3		@ create mask
+	smp_dmb
+1:	ldrex	r2, [r1]
+	ands	r0, r2, r3		@ save old value of bit
+	\instr	r2, r2, r3		@ toggle bit
+	strex	ip, r2, [r1]
+	cmp	ip, #0
+	bne	1b
+	smp_dmb
+	cmp	r0, #0
+	movne	r0, #1
+2:	bx	lr
+	.endm
diff --git a/xen/arch/arm/lib/changebit.S b/xen/arch/arm/lib/changebit.S
new file mode 100644
index 0000000..62954bc
--- /dev/null
+++ b/xen/arch/arm/lib/changebit.S
@@ -0,0 +1,18 @@
+/*
+ *  linux/arch/arm/lib/changebit.S
+ *
+ *  Copyright (C) 1995-1996 Russell King
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#include <xen/config.h>
+
+#include "assembler.h"
+#include "bitops.h"
+                .text
+
+ENTRY(_change_bit)
+	bitop	eor
+ENDPROC(_change_bit)
diff --git a/xen/arch/arm/lib/clearbit.S b/xen/arch/arm/lib/clearbit.S
new file mode 100644
index 0000000..42ce416
--- /dev/null
+++ b/xen/arch/arm/lib/clearbit.S
@@ -0,0 +1,19 @@
+/*
+ *  linux/arch/arm/lib/clearbit.S
+ *
+ *  Copyright (C) 1995-1996 Russell King
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <xen/config.h>
+
+#include "assembler.h"
+#include "bitops.h"
+                .text
+
+ENTRY(_clear_bit)
+	bitop	bic
+ENDPROC(_clear_bit)
diff --git a/xen/arch/arm/lib/copy_template.S b/xen/arch/arm/lib/copy_template.S
new file mode 100644
index 0000000..7f7f4d5
--- /dev/null
+++ b/xen/arch/arm/lib/copy_template.S
@@ -0,0 +1,266 @@
+/*
+ *  linux/arch/arm/lib/copy_template.s
+ *
+ *  Code template for optimized memory copy functions
+ *
+ *  Author:	Nicolas Pitre
+ *  Created:	Sep 28, 2005
+ *  Copyright:	MontaVista Software, Inc.
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License version 2 as
+ *  published by the Free Software Foundation.
+ */
+
+/*
+ * Theory of operation
+ * -------------------
+ *
+ * This file provides the core code for a forward memory copy used in
+ * the implementation of memcopy(), copy_to_user() and copy_from_user().
+ *
+ * The including file must define the following accessor macros
+ * according to the need of the given function:
+ *
+ * ldr1w ptr reg abort
+ *
+ *	This loads one word from 'ptr', stores it in 'reg' and increments
+ *	'ptr' to the next word. The 'abort' argument is used for fixup tables.
+ *
+ * ldr4w ptr reg1 reg2 reg3 reg4 abort
+ * ldr8w ptr, reg1 reg2 reg3 reg4 reg5 reg6 reg7 reg8 abort
+ *
+ *	This loads four or eight words starting from 'ptr', stores them
+ *	in provided registers and increments 'ptr' past those words.
+ *	The'abort' argument is used for fixup tables.
+ *
+ * ldr1b ptr reg cond abort
+ *
+ *	Similar to ldr1w, but it loads a byte and increments 'ptr' one byte.
+ *	It also must apply the condition code if provided, otherwise the
+ *	"al" condition is assumed by default.
+ *
+ * str1w ptr reg abort
+ * str8w ptr reg1 reg2 reg3 reg4 reg5 reg6 reg7 reg8 abort
+ * str1b ptr reg cond abort
+ *
+ *	Same as their ldr* counterparts, but data is stored to 'ptr' location
+ *	rather than being loaded.
+ *
+ * enter reg1 reg2
+ *
+ *	Preserve the provided registers on the stack plus any additional
+ *	data as needed by the implementation including this code. Called
+ *	upon code entry.
+ *
+ * exit reg1 reg2
+ *
+ *	Restore registers with the values previously saved with the
+ *	'preserv' macro. Called upon code termination.
+ *
+ * LDR1W_SHIFT
+ * STR1W_SHIFT
+ *
+ *	Correction to be applied to the "ip" register when branching into
+ *	the ldr1w or str1w instructions (some of these macros may expand to
+ *	than one 32bit instruction in Thumb-2)
+ */
+
+		enter	r4, lr
+
+		subs	r2, r2, #4
+		blt	8f
+		ands	ip, r0, #3
+	PLD(	pld	[r1, #0]		)
+		bne	9f
+		ands	ip, r1, #3
+		bne	10f
+
+1:		subs	r2, r2, #(28)
+		stmfd	sp!, {r5 - r8}
+		blt	5f
+
+	CALGN(	ands	ip, r0, #31		)
+	CALGN(	rsb	r3, ip, #32		)
+	CALGN(	sbcnes	r4, r3, r2		)  @ C is always set here
+	CALGN(	bcs	2f			)
+	CALGN(	adr	r4, 6f			)
+	CALGN(	subs	r2, r2, r3		)  @ C gets set
+	CALGN(	add	pc, r4, ip		)
+
+	PLD(	pld	[r1, #0]		)
+2:	PLD(	subs	r2, r2, #96		)
+	PLD(	pld	[r1, #28]		)
+	PLD(	blt	4f			)
+	PLD(	pld	[r1, #60]		)
+	PLD(	pld	[r1, #92]		)
+
+3:	PLD(	pld	[r1, #124]		)
+4:		ldr8w	r1, r3, r4, r5, r6, r7, r8, ip, lr, abort=20f
+		subs	r2, r2, #32
+		str8w	r0, r3, r4, r5, r6, r7, r8, ip, lr, abort=20f
+		bge	3b
+	PLD(	cmn	r2, #96			)
+	PLD(	bge	4b			)
+
+5:		ands	ip, r2, #28
+		rsb	ip, ip, #32
+#if LDR1W_SHIFT > 0
+		lsl	ip, ip, #LDR1W_SHIFT
+#endif
+		addne	pc, pc, ip		@ C is always clear here
+		b	7f
+6:
+		.rept	(1 << LDR1W_SHIFT)
+		W(nop)
+		.endr
+		ldr1w	r1, r3, abort=20f
+		ldr1w	r1, r4, abort=20f
+		ldr1w	r1, r5, abort=20f
+		ldr1w	r1, r6, abort=20f
+		ldr1w	r1, r7, abort=20f
+		ldr1w	r1, r8, abort=20f
+		ldr1w	r1, lr, abort=20f
+
+#if LDR1W_SHIFT < STR1W_SHIFT
+		lsl	ip, ip, #STR1W_SHIFT - LDR1W_SHIFT
+#elif LDR1W_SHIFT > STR1W_SHIFT
+		lsr	ip, ip, #LDR1W_SHIFT - STR1W_SHIFT
+#endif
+		add	pc, pc, ip
+		nop
+		.rept	(1 << STR1W_SHIFT)
+		W(nop)
+		.endr
+		str1w	r0, r3, abort=20f
+		str1w	r0, r4, abort=20f
+		str1w	r0, r5, abort=20f
+		str1w	r0, r6, abort=20f
+		str1w	r0, r7, abort=20f
+		str1w	r0, r8, abort=20f
+		str1w	r0, lr, abort=20f
+
+	CALGN(	bcs	2b			)
+
+7:		ldmfd	sp!, {r5 - r8}
+
+8:		movs	r2, r2, lsl #31
+		ldr1b	r1, r3, ne, abort=21f
+		ldr1b	r1, r4, cs, abort=21f
+		ldr1b	r1, ip, cs, abort=21f
+		str1b	r0, r3, ne, abort=21f
+		str1b	r0, r4, cs, abort=21f
+		str1b	r0, ip, cs, abort=21f
+
+		exit	r4, pc
+
+9:		rsb	ip, ip, #4
+		cmp	ip, #2
+		ldr1b	r1, r3, gt, abort=21f
+		ldr1b	r1, r4, ge, abort=21f
+		ldr1b	r1, lr, abort=21f
+		str1b	r0, r3, gt, abort=21f
+		str1b	r0, r4, ge, abort=21f
+		subs	r2, r2, ip
+		str1b	r0, lr, abort=21f
+		blt	8b
+		ands	ip, r1, #3
+		beq	1b
+
+10:		bic	r1, r1, #3
+		cmp	ip, #2
+		ldr1w	r1, lr, abort=21f
+		beq	17f
+		bgt	18f
+
+
+		.macro	forward_copy_shift pull push
+
+		subs	r2, r2, #28
+		blt	14f
+
+	CALGN(	ands	ip, r0, #31		)
+	CALGN(	rsb	ip, ip, #32		)
+	CALGN(	sbcnes	r4, ip, r2		)  @ C is always set here
+	CALGN(	subcc	r2, r2, ip		)
+	CALGN(	bcc	15f			)
+
+11:		stmfd	sp!, {r5 - r9}
+
+	PLD(	pld	[r1, #0]		)
+	PLD(	subs	r2, r2, #96		)
+	PLD(	pld	[r1, #28]		)
+	PLD(	blt	13f			)
+	PLD(	pld	[r1, #60]		)
+	PLD(	pld	[r1, #92]		)
+
+12:	PLD(	pld	[r1, #124]		)
+13:		ldr4w	r1, r4, r5, r6, r7, abort=19f
+		mov	r3, lr, pull #\pull
+		subs	r2, r2, #32
+		ldr4w	r1, r8, r9, ip, lr, abort=19f
+		orr	r3, r3, r4, push #\push
+		mov	r4, r4, pull #\pull
+		orr	r4, r4, r5, push #\push
+		mov	r5, r5, pull #\pull
+		orr	r5, r5, r6, push #\push
+		mov	r6, r6, pull #\pull
+		orr	r6, r6, r7, push #\push
+		mov	r7, r7, pull #\pull
+		orr	r7, r7, r8, push #\push
+		mov	r8, r8, pull #\pull
+		orr	r8, r8, r9, push #\push
+		mov	r9, r9, pull #\pull
+		orr	r9, r9, ip, push #\push
+		mov	ip, ip, pull #\pull
+		orr	ip, ip, lr, push #\push
+		str8w	r0, r3, r4, r5, r6, r7, r8, r9, ip, , abort=19f
+		bge	12b
+	PLD(	cmn	r2, #96			)
+	PLD(	bge	13b			)
+
+		ldmfd	sp!, {r5 - r9}
+
+14:		ands	ip, r2, #28
+		beq	16f
+
+15:		mov	r3, lr, pull #\pull
+		ldr1w	r1, lr, abort=21f
+		subs	ip, ip, #4
+		orr	r3, r3, lr, push #\push
+		str1w	r0, r3, abort=21f
+		bgt	15b
+	CALGN(	cmp	r2, #0			)
+	CALGN(	bge	11b			)
+
+16:		sub	r1, r1, #(\push / 8)
+		b	8b
+
+		.endm
+
+
+		forward_copy_shift	pull=8	push=24
+
+17:		forward_copy_shift	pull=16	push=16
+
+18:		forward_copy_shift	pull=24	push=8
+
+
+/*
+ * Abort preamble and completion macros.
+ * If a fixup handler is required then those macros must surround it.
+ * It is assumed that the fixup code will handle the private part of
+ * the exit macro.
+ */
+
+	.macro	copy_abort_preamble
+19:	ldmfd	sp!, {r5 - r9}
+	b	21f
+20:	ldmfd	sp!, {r5 - r8}
+21:
+	.endm
+
+	.macro	copy_abort_end
+	ldmfd	sp!, {r4, pc}
+	.endm
+
diff --git a/xen/arch/arm/lib/div64.S b/xen/arch/arm/lib/div64.S
new file mode 100644
index 0000000..2584772
--- /dev/null
+++ b/xen/arch/arm/lib/div64.S
@@ -0,0 +1,149 @@
+/*
+ *  linux/arch/arm/lib/div64.S
+ *
+ *  Optimized computation of 64-bit dividend / 32-bit divisor
+ *
+ *  Author:	Nicolas Pitre
+ *  Created:	Oct 5, 2003
+ *  Copyright:	Monta Vista Software, Inc.
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License version 2 as
+ *  published by the Free Software Foundation.
+ */
+
+#include <xen/config.h>
+#include "assembler.h"
+	
+#define xl r0
+#define xh r1
+#define yl r2
+#define yh r3
+
+/*
+ * __do_div64: perform a division with 64-bit dividend and 32-bit divisor.
+ *
+ * Note: Calling convention is totally non standard for optimal code.
+ *       This is meant to be used by do_div() from include/asm/div64.h only.
+ *
+ * Input parameters:
+ * 	xh-xl	= dividend (clobbered)
+ * 	r4	= divisor (preserved)
+ *
+ * Output values:
+ * 	yh-yl	= result
+ * 	xh	= remainder
+ *
+ * Clobbered regs: xl, ip
+ */
+
+ENTRY(__do_div64)
+
+	@ Test for easy paths first.
+	subs	ip, r4, #1
+	bls	9f			@ divisor is 0 or 1
+	tst	ip, r4
+	beq	8f			@ divisor is power of 2
+
+	@ See if we need to handle upper 32-bit result.
+	cmp	xh, r4
+	mov	yh, #0
+	blo	3f
+
+	@ Align divisor with upper part of dividend.
+	@ The aligned divisor is stored in yl preserving the original.
+	@ The bit position is stored in ip.
+
+	clz	yl, r4
+	clz	ip, xh
+	sub	yl, yl, ip
+	mov	ip, #1
+	mov	ip, ip, lsl yl
+	mov	yl, r4, lsl yl
+
+	@ The division loop for needed upper bit positions.
+ 	@ Break out early if dividend reaches 0.
+2:	cmp	xh, yl
+	orrcs	yh, yh, ip
+	subcss	xh, xh, yl
+	movnes	ip, ip, lsr #1
+	mov	yl, yl, lsr #1
+	bne	2b
+
+	@ See if we need to handle lower 32-bit result.
+3:	cmp	xh, #0
+	mov	yl, #0
+	cmpeq	xl, r4
+	movlo	xh, xl
+	movlo	pc, lr
+
+	@ The division loop for lower bit positions.
+	@ Here we shift remainer bits leftwards rather than moving the
+	@ divisor for comparisons, considering the carry-out bit as well.
+	mov	ip, #0x80000000
+4:	movs	xl, xl, lsl #1
+	adcs	xh, xh, xh
+	beq	6f
+	cmpcc	xh, r4
+5:	orrcs	yl, yl, ip
+	subcs	xh, xh, r4
+	movs	ip, ip, lsr #1
+	bne	4b
+	mov	pc, lr
+
+	@ The top part of remainder became zero.  If carry is set
+	@ (the 33th bit) this is a false positive so resume the loop.
+	@ Otherwise, if lower part is also null then we are done.
+6:	bcs	5b
+	cmp	xl, #0
+	moveq	pc, lr
+
+	@ We still have remainer bits in the low part.  Bring them up.
+
+	clz	xh, xl			@ we know xh is zero here so...
+	add	xh, xh, #1
+	mov	xl, xl, lsl xh
+	mov	ip, ip, lsr xh
+
+	@ Current remainder is now 1.  It is worthless to compare with
+	@ divisor at this point since divisor can not be smaller than 3 here.
+	@ If possible, branch for another shift in the division loop.
+	@ If no bit position left then we are done.
+	movs	ip, ip, lsr #1
+	mov	xh, #1
+	bne	4b
+	mov	pc, lr
+
+8:	@ Division by a power of 2: determine what that divisor order is
+	@ then simply shift values around
+
+	clz	ip, r4
+	rsb	ip, ip, #31
+
+	mov	yh, xh, lsr ip
+	mov	yl, xl, lsr ip
+	rsb	ip, ip, #32
+ ARM(	orr	yl, yl, xh, lsl ip	)
+ THUMB(	lsl	xh, xh, ip		)
+ THUMB(	orr	yl, yl, xh		)
+	mov	xh, xl, lsl ip
+	mov	xh, xh, lsr ip
+	mov	pc, lr
+
+	@ eq -> division by 1: obvious enough...
+9:	moveq	yl, xl
+	moveq	yh, xh
+	moveq	xh, #0
+	moveq	pc, lr
+
+	@ Division by 0:
+	str	lr, [sp, #-8]!
+	bl	__div0
+
+	@ as wrong as it could be...
+	mov	yl, #0
+	mov	yh, #0
+	mov	xh, #0
+	ldr	pc, [sp], #8
+
+ENDPROC(__do_div64)
diff --git a/xen/arch/arm/lib/findbit.S b/xen/arch/arm/lib/findbit.S
new file mode 100644
index 0000000..5669b91
--- /dev/null
+++ b/xen/arch/arm/lib/findbit.S
@@ -0,0 +1,115 @@
+/*
+ *  linux/arch/arm/lib/findbit.S
+ *
+ *  Copyright (C) 1995-2000 Russell King
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * 16th March 2001 - John Ripley <jripley@sonicblue.com>
+ *   Fixed so that "size" is an exclusive not an inclusive quantity.
+ *   All users of these functions expect exclusive sizes, and may
+ *   also call with zero size.
+ * Reworked by rmk.
+ */
+
+#include <xen/config.h>
+
+#include "assembler.h"
+                .text
+
+/*
+ * Purpose  : Find a 'zero' bit
+ * Prototype: int find_first_zero_bit(void *addr, unsigned int maxbit);
+ */
+ENTRY(_find_first_zero_bit)
+		teq	r1, #0	
+		beq	3f
+		mov	r2, #0
+1:
+ ARM(		ldrb	r3, [r0, r2, lsr #3]	)
+ THUMB(		lsr	r3, r2, #3		)
+ THUMB(		ldrb	r3, [r0, r3]		)
+		eors	r3, r3, #0xff		@ invert bits
+		bne	.L_found		@ any now set - found zero bit
+		add	r2, r2, #8		@ next bit pointer
+2:		cmp	r2, r1			@ any more?
+		blo	1b
+3:		mov	r0, r1			@ no free bits
+		mov	pc, lr
+ENDPROC(_find_first_zero_bit)
+
+/*
+ * Purpose  : Find next 'zero' bit
+ * Prototype: int find_next_zero_bit(void *addr, unsigned int maxbit, int offset)
+ */
+ENTRY(_find_next_zero_bit)
+		teq	r1, #0
+		beq	3b
+		ands	ip, r2, #7
+		beq	1b			@ If new byte, goto old routine
+ ARM(		ldrb	r3, [r0, r2, lsr #3]	)
+ THUMB(		lsr	r3, r2, #3		)
+ THUMB(		ldrb	r3, [r0, r3]		)
+		eor	r3, r3, #0xff		@ now looking for a 1 bit
+		movs	r3, r3, lsr ip		@ shift off unused bits
+		bne	.L_found
+		orr	r2, r2, #7		@ if zero, then no bits here
+		add	r2, r2, #1		@ align bit pointer
+		b	2b			@ loop for next bit
+ENDPROC(_find_next_zero_bit)
+
+/*
+ * Purpose  : Find a 'one' bit
+ * Prototype: int find_first_bit(const unsigned long *addr, unsigned int maxbit);
+ */
+ENTRY(_find_first_bit)
+		teq	r1, #0	
+		beq	3f
+		mov	r2, #0
+1:
+ ARM(		ldrb	r3, [r0, r2, lsr #3]	)
+ THUMB(		lsr	r3, r2, #3		)
+ THUMB(		ldrb	r3, [r0, r3]		)
+		movs	r3, r3
+		bne	.L_found		@ any now set - found zero bit
+		add	r2, r2, #8		@ next bit pointer
+2:		cmp	r2, r1			@ any more?
+		blo	1b
+3:		mov	r0, r1			@ no free bits
+		mov	pc, lr
+ENDPROC(_find_first_bit)
+
+/*
+ * Purpose  : Find next 'one' bit
+ * Prototype: int find_next_zero_bit(void *addr, unsigned int maxbit, int offset)
+ */
+ENTRY(_find_next_bit)
+		teq	r1, #0
+		beq	3b
+		ands	ip, r2, #7
+		beq	1b			@ If new byte, goto old routine
+ ARM(		ldrb	r3, [r0, r2, lsr #3]	)
+ THUMB(		lsr	r3, r2, #3		)
+ THUMB(		ldrb	r3, [r0, r3]		)
+		movs	r3, r3, lsr ip		@ shift off unused bits
+		bne	.L_found
+		orr	r2, r2, #7		@ if zero, then no bits here
+		add	r2, r2, #1		@ align bit pointer
+		b	2b			@ loop for next bit
+ENDPROC(_find_next_bit)
+
+/*
+ * One or more bits in the LSB of r3 are assumed to be set.
+ */
+.L_found:
+		rsb	r0, r3, #0
+		and	r3, r3, r0
+		clz	r3, r3
+		rsb	r3, r3, #31
+		add	r0, r2, r3
+		cmp	r1, r0			@ Clamp to maxbit
+		movlo	r0, r1
+		mov	pc, lr
+
diff --git a/xen/arch/arm/lib/lib1funcs.S b/xen/arch/arm/lib/lib1funcs.S
new file mode 100644
index 0000000..828e688
--- /dev/null
+++ b/xen/arch/arm/lib/lib1funcs.S
@@ -0,0 +1,302 @@
+/*
+ * linux/arch/arm/lib/lib1funcs.S: Optimized ARM division routines
+ *
+ * Author: Nicolas Pitre <nico@fluxnic.net>
+ *   - contributed to gcc-3.4 on Sep 30, 2003
+ *   - adapted for the Linux kernel on Oct 2, 2003
+ */
+
+/* Copyright 1995, 1996, 1998, 1999, 2000, 2003 Free Software Foundation, Inc.
+
+This file 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, or (at your option) any
+later version.
+
+In addition to the permissions in the GNU General Public License, the
+Free Software Foundation gives you unlimited permission to link the
+compiled version of this file into combinations with other programs,
+and to distribute those combinations without any restriction coming
+from the use of this file.  (The General Public License restrictions
+do apply in other respects; for example, they cover modification of
+the file, and distribution when not linked into a combine
+executable.)
+
+This file is distributed in the hope that it will be useful, but
+WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  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; see the file COPYING.  If not, write to
+the Free Software Foundation, 59 Temple Place - Suite 330,
+Boston, MA 02111-1307, USA.  */
+
+
+#include <xen/config.h>
+#include "assembler.h"
+
+.macro ARM_DIV_BODY dividend, divisor, result, curbit
+
+	clz	\curbit, \divisor
+	clz	\result, \dividend
+	sub	\result, \curbit, \result
+	mov	\curbit, #1
+	mov	\divisor, \divisor, lsl \result
+	mov	\curbit, \curbit, lsl \result
+	mov	\result, #0
+	
+	@ Division loop
+1:	cmp	\dividend, \divisor
+	subhs	\dividend, \dividend, \divisor
+	orrhs	\result,   \result,   \curbit
+	cmp	\dividend, \divisor,  lsr #1
+	subhs	\dividend, \dividend, \divisor, lsr #1
+	orrhs	\result,   \result,   \curbit,  lsr #1
+	cmp	\dividend, \divisor,  lsr #2
+	subhs	\dividend, \dividend, \divisor, lsr #2
+	orrhs	\result,   \result,   \curbit,  lsr #2
+	cmp	\dividend, \divisor,  lsr #3
+	subhs	\dividend, \dividend, \divisor, lsr #3
+	orrhs	\result,   \result,   \curbit,  lsr #3
+	cmp	\dividend, #0			@ Early termination?
+	movnes	\curbit,   \curbit,  lsr #4	@ No, any more bits to do?
+	movne	\divisor,  \divisor, lsr #4
+	bne	1b
+
+.endm
+
+
+.macro ARM_DIV2_ORDER divisor, order
+
+	clz	\order, \divisor
+	rsb	\order, \order, #31
+
+.endm
+
+
+.macro ARM_MOD_BODY dividend, divisor, order, spare
+
+	clz	\order, \divisor
+	clz	\spare, \dividend
+	sub	\order, \order, \spare
+	mov	\divisor, \divisor, lsl \order
+
+	@ Perform all needed substractions to keep only the reminder.
+	@ Do comparisons in batch of 4 first.
+	subs	\order, \order, #3		@ yes, 3 is intended here
+	blt	2f
+
+1:	cmp	\dividend, \divisor
+	subhs	\dividend, \dividend, \divisor
+	cmp	\dividend, \divisor,  lsr #1
+	subhs	\dividend, \dividend, \divisor, lsr #1
+	cmp	\dividend, \divisor,  lsr #2
+	subhs	\dividend, \dividend, \divisor, lsr #2
+	cmp	\dividend, \divisor,  lsr #3
+	subhs	\dividend, \dividend, \divisor, lsr #3
+	cmp	\dividend, #1
+	mov	\divisor, \divisor, lsr #4
+	subges	\order, \order, #4
+	bge	1b
+
+	tst	\order, #3
+	teqne	\dividend, #0
+	beq	5f
+
+	@ Either 1, 2 or 3 comparison/substractions are left.
+2:	cmn	\order, #2
+	blt	4f
+	beq	3f
+	cmp	\dividend, \divisor
+	subhs	\dividend, \dividend, \divisor
+	mov	\divisor,  \divisor,  lsr #1
+3:	cmp	\dividend, \divisor
+	subhs	\dividend, \dividend, \divisor
+	mov	\divisor,  \divisor,  lsr #1
+4:	cmp	\dividend, \divisor
+	subhs	\dividend, \dividend, \divisor
+5:
+.endm
+
+
+ENTRY(__udivsi3)
+ENTRY(__aeabi_uidiv)
+UNWIND(.fnstart)
+
+	subs	r2, r1, #1
+	moveq	pc, lr
+	bcc	Ldiv0
+	cmp	r0, r1
+	bls	11f
+	tst	r1, r2
+	beq	12f
+
+	ARM_DIV_BODY r0, r1, r2, r3
+
+	mov	r0, r2
+	mov	pc, lr
+
+11:	moveq	r0, #1
+	movne	r0, #0
+	mov	pc, lr
+
+12:	ARM_DIV2_ORDER r1, r2
+
+	mov	r0, r0, lsr r2
+	mov	pc, lr
+
+UNWIND(.fnend)
+ENDPROC(__udivsi3)
+ENDPROC(__aeabi_uidiv)
+
+ENTRY(__umodsi3)
+UNWIND(.fnstart)
+
+	subs	r2, r1, #1			@ compare divisor with 1
+	bcc	Ldiv0
+	cmpne	r0, r1				@ compare dividend with divisor
+	moveq   r0, #0
+	tsthi	r1, r2				@ see if divisor is power of 2
+	andeq	r0, r0, r2
+	movls	pc, lr
+
+	ARM_MOD_BODY r0, r1, r2, r3
+
+	mov	pc, lr
+
+UNWIND(.fnend)
+ENDPROC(__umodsi3)
+
+ENTRY(__divsi3)
+ENTRY(__aeabi_idiv)
+UNWIND(.fnstart)
+
+	cmp	r1, #0
+	eor	ip, r0, r1			@ save the sign of the result.
+	beq	Ldiv0
+	rsbmi	r1, r1, #0			@ loops below use unsigned.
+	subs	r2, r1, #1			@ division by 1 or -1 ?
+	beq	10f
+	movs	r3, r0
+	rsbmi	r3, r0, #0			@ positive dividend value
+	cmp	r3, r1
+	bls	11f
+	tst	r1, r2				@ divisor is power of 2 ?
+	beq	12f
+
+	ARM_DIV_BODY r3, r1, r0, r2
+
+	cmp	ip, #0
+	rsbmi	r0, r0, #0
+	mov	pc, lr
+
+10:	teq	ip, r0				@ same sign ?
+	rsbmi	r0, r0, #0
+	mov	pc, lr
+
+11:	movlo	r0, #0
+	moveq	r0, ip, asr #31
+	orreq	r0, r0, #1
+	mov	pc, lr
+
+12:	ARM_DIV2_ORDER r1, r2
+
+	cmp	ip, #0
+	mov	r0, r3, lsr r2
+	rsbmi	r0, r0, #0
+	mov	pc, lr
+
+UNWIND(.fnend)
+ENDPROC(__divsi3)
+ENDPROC(__aeabi_idiv)
+
+ENTRY(__modsi3)
+UNWIND(.fnstart)
+
+	cmp	r1, #0
+	beq	Ldiv0
+	rsbmi	r1, r1, #0			@ loops below use unsigned.
+	movs	ip, r0				@ preserve sign of dividend
+	rsbmi	r0, r0, #0			@ if negative make positive
+	subs	r2, r1, #1			@ compare divisor with 1
+	cmpne	r0, r1				@ compare dividend with divisor
+	moveq	r0, #0
+	tsthi	r1, r2				@ see if divisor is power of 2
+	andeq	r0, r0, r2
+	bls	10f
+
+	ARM_MOD_BODY r0, r1, r2, r3
+
+10:	cmp	ip, #0
+	rsbmi	r0, r0, #0
+	mov	pc, lr
+
+UNWIND(.fnend)
+ENDPROC(__modsi3)
+
+ENTRY(__aeabi_uidivmod)
+UNWIND(.fnstart)
+UNWIND(.save {r0, r1, ip, lr}	)
+
+	stmfd	sp!, {r0, r1, ip, lr}
+	bl	__aeabi_uidiv
+	ldmfd	sp!, {r1, r2, ip, lr}
+	mul	r3, r0, r2
+	sub	r1, r1, r3
+	mov	pc, lr
+
+UNWIND(.fnend)
+ENDPROC(__aeabi_uidivmod)
+
+ENTRY(__aeabi_idivmod)
+UNWIND(.fnstart)
+UNWIND(.save {r0, r1, ip, lr}	)
+	stmfd	sp!, {r0, r1, ip, lr}
+	bl	__aeabi_idiv
+	ldmfd	sp!, {r1, r2, ip, lr}
+	mul	r3, r0, r2
+	sub	r1, r1, r3
+	mov	pc, lr
+
+UNWIND(.fnend)
+ENDPROC(__aeabi_idivmod)
+
+ENTRY(__aeabi_uldivmod)
+UNWIND(.fnstart)
+UNWIND(.save {lr}	)
+	sub sp, sp, #8
+	stmfd   sp!, {sp, lr}
+	bl __qdivrem
+	ldr lr, [sp, #4]
+	add sp, sp, #8
+	ldmfd sp!, {r2, r3}
+	mov	pc, lr
+
+UNWIND(.fnend)
+ENDPROC(__aeabi_uldivmod)
+
+ENTRY(__aeabi_ldivmod)
+UNWIND(.fnstart)
+UNWIND(.save {lr}	)
+	sub sp, sp, #16
+	stmfd   sp!, {sp, lr}
+	bl __ldivmod_helper
+	ldr lr, [sp, #4]
+	add sp, sp, #16
+	ldmfd	sp!, {r2, r3}
+	mov	pc, lr
+	
+UNWIND(.fnend)
+ENDPROC(__aeabi_uldivmod)
+
+Ldiv0:
+UNWIND(.fnstart)
+UNWIND(.pad #4)
+UNWIND(.save {lr})
+	str	lr, [sp, #-8]!
+	bl	__div0
+	mov	r0, #0			@ About as wrong as it could be.
+	ldr	pc, [sp], #8
+UNWIND(.fnend)
+ENDPROC(Ldiv0)
diff --git a/xen/arch/arm/lib/memcpy.S b/xen/arch/arm/lib/memcpy.S
new file mode 100644
index 0000000..f4bad5c
--- /dev/null
+++ b/xen/arch/arm/lib/memcpy.S
@@ -0,0 +1,64 @@
+/*
+ *  linux/arch/arm/lib/memcpy.S
+ *
+ *  Author:     Nicolas Pitre
+ *  Created:    Sep 28, 2005
+ *  Copyright:  MontaVista Software, Inc.
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License version 2 as
+ *  published by the Free Software Foundation.
+ */
+
+#include <xen/config.h>
+
+#include "assembler.h"
+
+#define LDR1W_SHIFT     0
+#define STR1W_SHIFT     0
+
+        .macro ldr1w ptr reg abort
+        W(ldr) \reg, [\ptr], #4
+        .endm
+
+        .macro ldr4w ptr reg1 reg2 reg3 reg4 abort
+        ldmia \ptr!, {\reg1, \reg2, \reg3, \reg4}
+        .endm
+
+        .macro ldr8w ptr reg1 reg2 reg3 reg4 reg5 reg6 reg7 reg8 abort
+        ldmia \ptr!, {\reg1, \reg2, \reg3, \reg4, \reg5, \reg6, \reg7, \reg8}
+        .endm
+
+        .macro ldr1b ptr reg cond=al abort
+        ldr\cond\()b \reg, [\ptr], #1
+        .endm
+
+        .macro str1w ptr reg abort
+        W(str) \reg, [\ptr], #4
+        .endm
+
+        .macro str8w ptr reg1 reg2 reg3 reg4 reg5 reg6 reg7 reg8 abort
+        stmia \ptr!, {\reg1, \reg2, \reg3, \reg4, \reg5, \reg6, \reg7, \reg8}
+        .endm
+
+        .macro str1b ptr reg cond=al abort
+        str\cond\()b \reg, [\ptr], #1
+        .endm
+
+        .macro enter reg1 reg2
+        stmdb sp!, {r0, \reg1, \reg2}
+        .endm
+
+        .macro exit reg1 reg2
+        ldmfd sp!, {r0, \reg1, \reg2}
+        .endm
+
+        .text
+
+/* Prototype: void *memcpy(void *dest, const void *src, size_t n); */
+
+ENTRY(memcpy)
+
+#include "copy_template.S"
+
+ENDPROC(memcpy)
diff --git a/xen/arch/arm/lib/memmove.S b/xen/arch/arm/lib/memmove.S
new file mode 100644
index 0000000..4e142b8
--- /dev/null
+++ b/xen/arch/arm/lib/memmove.S
@@ -0,0 +1,200 @@
+/*
+ *  linux/arch/arm/lib/memmove.S
+ *
+ *  Author:	Nicolas Pitre
+ *  Created:	Sep 28, 2005
+ *  Copyright:	(C) MontaVista Software Inc.
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License version 2 as
+ *  published by the Free Software Foundation.
+ */
+
+#include <xen/config.h>
+
+#include "assembler.h"
+
+		.text
+
+/*
+ * Prototype: void *memmove(void *dest, const void *src, size_t n);
+ *
+ * Note:
+ *
+ * If the memory regions don't overlap, we simply branch to memcpy which is
+ * normally a bit faster. Otherwise the copy is done going downwards.  This
+ * is a transposition of the code from copy_template.S but with the copy
+ * occurring in the opposite direction.
+ */
+
+ENTRY(memmove)
+
+		subs	ip, r0, r1
+		cmphi	r2, ip
+		bls	memcpy
+
+		stmfd	sp!, {r0, r4, lr}
+		add	r1, r1, r2
+		add	r0, r0, r2
+		subs	r2, r2, #4
+		blt	8f
+		ands	ip, r0, #3
+	PLD(	pld	[r1, #-4]		)
+		bne	9f
+		ands	ip, r1, #3
+		bne	10f
+
+1:		subs	r2, r2, #(28)
+		stmfd	sp!, {r5 - r8}
+		blt	5f
+
+	CALGN(	ands	ip, r0, #31		)
+	CALGN(	sbcnes	r4, ip, r2		)  @ C is always set here
+	CALGN(	bcs	2f			)
+	CALGN(	adr	r4, 6f			)
+	CALGN(	subs	r2, r2, ip		)  @ C is set here
+	CALGN(	rsb	ip, ip, #32		)
+	CALGN(	add	pc, r4, ip		)
+
+	PLD(	pld	[r1, #-4]		)
+2:	PLD(	subs	r2, r2, #96		)
+	PLD(	pld	[r1, #-32]		)
+	PLD(	blt	4f			)
+	PLD(	pld	[r1, #-64]		)
+	PLD(	pld	[r1, #-96]		)
+
+3:	PLD(	pld	[r1, #-128]		)
+4:		ldmdb	r1!, {r3, r4, r5, r6, r7, r8, ip, lr}
+		subs	r2, r2, #32
+		stmdb	r0!, {r3, r4, r5, r6, r7, r8, ip, lr}
+		bge	3b
+	PLD(	cmn	r2, #96			)
+	PLD(	bge	4b			)
+
+5:		ands	ip, r2, #28
+		rsb	ip, ip, #32
+		addne	pc, pc, ip		@ C is always clear here
+		b	7f
+6:		W(nop)
+		W(ldr)	r3, [r1, #-4]!
+		W(ldr)	r4, [r1, #-4]!
+		W(ldr)	r5, [r1, #-4]!
+		W(ldr)	r6, [r1, #-4]!
+		W(ldr)	r7, [r1, #-4]!
+		W(ldr)	r8, [r1, #-4]!
+		W(ldr)	lr, [r1, #-4]!
+
+		add	pc, pc, ip
+		nop
+		W(nop)
+		W(str)	r3, [r0, #-4]!
+		W(str)	r4, [r0, #-4]!
+		W(str)	r5, [r0, #-4]!
+		W(str)	r6, [r0, #-4]!
+		W(str)	r7, [r0, #-4]!
+		W(str)	r8, [r0, #-4]!
+		W(str)	lr, [r0, #-4]!
+
+	CALGN(	bcs	2b			)
+
+7:		ldmfd	sp!, {r5 - r8}
+
+8:		movs	r2, r2, lsl #31
+		ldrneb	r3, [r1, #-1]!
+		ldrcsb	r4, [r1, #-1]!
+		ldrcsb	ip, [r1, #-1]
+		strneb	r3, [r0, #-1]!
+		strcsb	r4, [r0, #-1]!
+		strcsb	ip, [r0, #-1]
+		ldmfd	sp!, {r0, r4, pc}
+
+9:		cmp	ip, #2
+		ldrgtb	r3, [r1, #-1]!
+		ldrgeb	r4, [r1, #-1]!
+		ldrb	lr, [r1, #-1]!
+		strgtb	r3, [r0, #-1]!
+		strgeb	r4, [r0, #-1]!
+		subs	r2, r2, ip
+		strb	lr, [r0, #-1]!
+		blt	8b
+		ands	ip, r1, #3
+		beq	1b
+
+10:		bic	r1, r1, #3
+		cmp	ip, #2
+		ldr	r3, [r1, #0]
+		beq	17f
+		blt	18f
+
+
+		.macro	backward_copy_shift push pull
+
+		subs	r2, r2, #28
+		blt	14f
+
+	CALGN(	ands	ip, r0, #31		)
+	CALGN(	sbcnes	r4, ip, r2		)  @ C is always set here
+	CALGN(	subcc	r2, r2, ip		)
+	CALGN(	bcc	15f			)
+
+11:		stmfd	sp!, {r5 - r9}
+
+	PLD(	pld	[r1, #-4]		)
+	PLD(	subs	r2, r2, #96		)
+	PLD(	pld	[r1, #-32]		)
+	PLD(	blt	13f			)
+	PLD(	pld	[r1, #-64]		)
+	PLD(	pld	[r1, #-96]		)
+
+12:	PLD(	pld	[r1, #-128]		)
+13:		ldmdb   r1!, {r7, r8, r9, ip}
+		mov     lr, r3, push #\push
+		subs    r2, r2, #32
+		ldmdb   r1!, {r3, r4, r5, r6}
+		orr     lr, lr, ip, pull #\pull
+		mov     ip, ip, push #\push
+		orr     ip, ip, r9, pull #\pull
+		mov     r9, r9, push #\push
+		orr     r9, r9, r8, pull #\pull
+		mov     r8, r8, push #\push
+		orr     r8, r8, r7, pull #\pull
+		mov     r7, r7, push #\push
+		orr     r7, r7, r6, pull #\pull
+		mov     r6, r6, push #\push
+		orr     r6, r6, r5, pull #\pull
+		mov     r5, r5, push #\push
+		orr     r5, r5, r4, pull #\pull
+		mov     r4, r4, push #\push
+		orr     r4, r4, r3, pull #\pull
+		stmdb   r0!, {r4 - r9, ip, lr}
+		bge	12b
+	PLD(	cmn	r2, #96			)
+	PLD(	bge	13b			)
+
+		ldmfd	sp!, {r5 - r9}
+
+14:		ands	ip, r2, #28
+		beq	16f
+
+15:		mov     lr, r3, push #\push
+		ldr	r3, [r1, #-4]!
+		subs	ip, ip, #4
+		orr	lr, lr, r3, pull #\pull
+		str	lr, [r0, #-4]!
+		bgt	15b
+	CALGN(	cmp	r2, #0			)
+	CALGN(	bge	11b			)
+
+16:		add	r1, r1, #(\pull / 8)
+		b	8b
+
+		.endm
+
+
+		backward_copy_shift	push=8	pull=24
+
+17:		backward_copy_shift	push=16	pull=16
+
+18:		backward_copy_shift	push=24	pull=8
+
+ENDPROC(memmove)
diff --git a/xen/arch/arm/lib/memset.S b/xen/arch/arm/lib/memset.S
new file mode 100644
index 0000000..d2937a3
--- /dev/null
+++ b/xen/arch/arm/lib/memset.S
@@ -0,0 +1,129 @@
+/*
+ *  linux/arch/arm/lib/memset.S
+ *
+ *  Copyright (C) 1995-2000 Russell King
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ *  ASM optimised string functions
+ */
+
+#include <xen/config.h>
+
+#include "assembler.h"
+
+	.text
+	.align	5
+	.word	0
+
+1:	subs	r2, r2, #4		@ 1 do we have enough
+	blt	5f			@ 1 bytes to align with?
+	cmp	r3, #2			@ 1
+	strltb	r1, [r0], #1		@ 1
+	strleb	r1, [r0], #1		@ 1
+	strb	r1, [r0], #1		@ 1
+	add	r2, r2, r3		@ 1 (r2 = r2 - (4 - r3))
+/*
+ * The pointer is now aligned and the length is adjusted.  Try doing the
+ * memset again.
+ */
+
+ENTRY(memset)
+	ands	r3, r0, #3		@ 1 unaligned?
+	bne	1b			@ 1
+/*
+ * we know that the pointer in r0 is aligned to a word boundary.
+ */
+	orr	r1, r1, r1, lsl #8
+	orr	r1, r1, r1, lsl #16
+	mov	r3, r1
+	cmp	r2, #16
+	blt	4f
+
+#if ! CALGN(1)+0
+
+/*
+ * We need an extra register for this loop - save the return address and
+ * use the LR
+ */
+	str	lr, [sp, #-4]!
+	mov	ip, r1
+	mov	lr, r1
+
+2:	subs	r2, r2, #64
+	stmgeia	r0!, {r1, r3, ip, lr}	@ 64 bytes at a time.
+	stmgeia	r0!, {r1, r3, ip, lr}
+	stmgeia	r0!, {r1, r3, ip, lr}
+	stmgeia	r0!, {r1, r3, ip, lr}
+	bgt	2b
+	ldmeqfd	sp!, {pc}		@ Now <64 bytes to go.
+/*
+ * No need to correct the count; we're only testing bits from now on
+ */
+	tst	r2, #32
+	stmneia	r0!, {r1, r3, ip, lr}
+	stmneia	r0!, {r1, r3, ip, lr}
+	tst	r2, #16
+	stmneia	r0!, {r1, r3, ip, lr}
+	ldr	lr, [sp], #4
+
+#else
+
+/*
+ * This version aligns the destination pointer in order to write
+ * whole cache lines at once.
+ */
+
+	stmfd	sp!, {r4-r7, lr}
+	mov	r4, r1
+	mov	r5, r1
+	mov	r6, r1
+	mov	r7, r1
+	mov	ip, r1
+	mov	lr, r1
+
+	cmp	r2, #96
+	tstgt	r0, #31
+	ble	3f
+
+	and	ip, r0, #31
+	rsb	ip, ip, #32
+	sub	r2, r2, ip
+	movs	ip, ip, lsl #(32 - 4)
+	stmcsia	r0!, {r4, r5, r6, r7}
+	stmmiia	r0!, {r4, r5}
+	tst	ip, #(1 << 30)
+	mov	ip, r1
+	strne	r1, [r0], #4
+
+3:	subs	r2, r2, #64
+	stmgeia	r0!, {r1, r3-r7, ip, lr}
+	stmgeia	r0!, {r1, r3-r7, ip, lr}
+	bgt	3b
+	ldmeqfd	sp!, {r4-r7, pc}
+
+	tst	r2, #32
+	stmneia	r0!, {r1, r3-r7, ip, lr}
+	tst	r2, #16
+	stmneia	r0!, {r4-r7}
+	ldmfd	sp!, {r4-r7, lr}
+
+#endif
+
+4:	tst	r2, #8
+	stmneia	r0!, {r1, r3}
+	tst	r2, #4
+	strne	r1, [r0], #4
+/*
+ * When we get here, we've got less than 4 bytes to zero.  We
+ * may have an unaligned pointer as well.
+ */
+5:	tst	r2, #2
+	strneb	r1, [r0], #1
+	strneb	r1, [r0], #1
+	tst	r2, #1
+	strneb	r1, [r0], #1
+	mov	pc, lr
+ENDPROC(memset)
diff --git a/xen/arch/arm/lib/memzero.S b/xen/arch/arm/lib/memzero.S
new file mode 100644
index 0000000..ce25aca
--- /dev/null
+++ b/xen/arch/arm/lib/memzero.S
@@ -0,0 +1,127 @@
+/*
+ *  linux/arch/arm/lib/memzero.S
+ *
+ *  Copyright (C) 1995-2000 Russell King
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <xen/config.h>
+
+#include "assembler.h"
+
+	.text
+	.align	5
+	.word	0
+/*
+ * Align the pointer in r0.  r3 contains the number of bytes that we are
+ * mis-aligned by, and r1 is the number of bytes.  If r1 < 4, then we
+ * don't bother; we use byte stores instead.
+ */
+1:	subs	r1, r1, #4		@ 1 do we have enough
+	blt	5f			@ 1 bytes to align with?
+	cmp	r3, #2			@ 1
+	strltb	r2, [r0], #1		@ 1
+	strleb	r2, [r0], #1		@ 1
+	strb	r2, [r0], #1		@ 1
+	add	r1, r1, r3		@ 1 (r1 = r1 - (4 - r3))
+/*
+ * The pointer is now aligned and the length is adjusted.  Try doing the
+ * memzero again.
+ */
+
+ENTRY(__memzero)
+	mov	r2, #0			@ 1
+	ands	r3, r0, #3		@ 1 unaligned?
+	bne	1b			@ 1
+/*
+ * r3 = 0, and we know that the pointer in r0 is aligned to a word boundary.
+ */
+	cmp	r1, #16			@ 1 we can skip this chunk if we
+	blt	4f			@ 1 have < 16 bytes
+
+#if ! CALGN(1)+0
+
+/*
+ * We need an extra register for this loop - save the return address and
+ * use the LR
+ */
+	str	lr, [sp, #-4]!		@ 1
+	mov	ip, r2			@ 1
+	mov	lr, r2			@ 1
+
+3:	subs	r1, r1, #64		@ 1 write 32 bytes out per loop
+	stmgeia	r0!, {r2, r3, ip, lr}	@ 4
+	stmgeia	r0!, {r2, r3, ip, lr}	@ 4
+	stmgeia	r0!, {r2, r3, ip, lr}	@ 4
+	stmgeia	r0!, {r2, r3, ip, lr}	@ 4
+	bgt	3b			@ 1
+	ldmeqfd	sp!, {pc}		@ 1/2 quick exit
+/*
+ * No need to correct the count; we're only testing bits from now on
+ */
+	tst	r1, #32			@ 1
+	stmneia	r0!, {r2, r3, ip, lr}	@ 4
+	stmneia	r0!, {r2, r3, ip, lr}	@ 4
+	tst	r1, #16			@ 1 16 bytes or more?
+	stmneia	r0!, {r2, r3, ip, lr}	@ 4
+	ldr	lr, [sp], #4		@ 1
+
+#else
+
+/*
+ * This version aligns the destination pointer in order to write
+ * whole cache lines at once.
+ */
+
+	stmfd	sp!, {r4-r7, lr}
+	mov	r4, r2
+	mov	r5, r2
+	mov	r6, r2
+	mov	r7, r2
+	mov	ip, r2
+	mov	lr, r2
+
+	cmp	r1, #96
+	andgts	ip, r0, #31
+	ble	3f
+
+	rsb	ip, ip, #32
+	sub	r1, r1, ip
+	movs	ip, ip, lsl #(32 - 4)
+	stmcsia	r0!, {r4, r5, r6, r7}
+	stmmiia	r0!, {r4, r5}
+	movs	ip, ip, lsl #2
+	strcs	r2, [r0], #4
+
+3:	subs	r1, r1, #64
+	stmgeia	r0!, {r2-r7, ip, lr}
+	stmgeia	r0!, {r2-r7, ip, lr}
+	bgt	3b
+	ldmeqfd	sp!, {r4-r7, pc}
+
+	tst	r1, #32
+	stmneia	r0!, {r2-r7, ip, lr}
+	tst	r1, #16
+	stmneia	r0!, {r4-r7}
+	ldmfd	sp!, {r4-r7, lr}
+
+#endif
+
+4:	tst	r1, #8			@ 1 8 bytes or more?
+	stmneia	r0!, {r2, r3}		@ 2
+	tst	r1, #4			@ 1 4 bytes or more?
+	strne	r2, [r0], #4		@ 1
+/*
+ * When we get here, we've got less than 4 bytes to zero.  We
+ * may have an unaligned pointer as well.
+ */
+5:	tst	r1, #2			@ 1 2 bytes or more?
+	strneb	r2, [r0], #1		@ 1
+	strneb	r2, [r0], #1		@ 1
+	tst	r1, #1			@ 1 a byte left over
+	strneb	r2, [r0], #1		@ 1
+	mov	pc, lr			@ 1
+ENDPROC(__memzero)
diff --git a/xen/arch/arm/lib/setbit.S b/xen/arch/arm/lib/setbit.S
new file mode 100644
index 0000000..c828851
--- /dev/null
+++ b/xen/arch/arm/lib/setbit.S
@@ -0,0 +1,18 @@
+/*
+ *  linux/arch/arm/lib/setbit.S
+ *
+ *  Copyright (C) 1995-1996 Russell King
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#include <xen/config.h>
+
+#include "assembler.h"
+#include "bitops.h"
+	.text
+
+ENTRY(_set_bit)
+	bitop	orr
+ENDPROC(_set_bit)
diff --git a/xen/arch/arm/lib/testchangebit.S b/xen/arch/arm/lib/testchangebit.S
new file mode 100644
index 0000000..a7f527c
--- /dev/null
+++ b/xen/arch/arm/lib/testchangebit.S
@@ -0,0 +1,18 @@
+/*
+ *  linux/arch/arm/lib/testchangebit.S
+ *
+ *  Copyright (C) 1995-1996 Russell King
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#include <xen/config.h>
+
+#include "assembler.h"
+#include "bitops.h"
+                .text
+
+ENTRY(_test_and_change_bit)
+	testop	eor, str
+ENDPROC(_test_and_change_bit)
diff --git a/xen/arch/arm/lib/testclearbit.S b/xen/arch/arm/lib/testclearbit.S
new file mode 100644
index 0000000..8f39c72
--- /dev/null
+++ b/xen/arch/arm/lib/testclearbit.S
@@ -0,0 +1,18 @@
+/*
+ *  linux/arch/arm/lib/testclearbit.S
+ *
+ *  Copyright (C) 1995-1996 Russell King
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#include <xen/config.h>
+
+#include "assembler.h"
+#include "bitops.h"
+                .text
+
+ENTRY(_test_and_clear_bit)
+	testop	bicne, strne
+ENDPROC(_test_and_clear_bit)
diff --git a/xen/arch/arm/lib/testsetbit.S b/xen/arch/arm/lib/testsetbit.S
new file mode 100644
index 0000000..1b8d273
--- /dev/null
+++ b/xen/arch/arm/lib/testsetbit.S
@@ -0,0 +1,18 @@
+/*
+ *  linux/arch/arm/lib/testsetbit.S
+ *
+ *  Copyright (C) 1995-1996 Russell King
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#include <xen/config.h>
+
+#include "assembler.h"
+#include "bitops.h"
+                .text
+
+ENTRY(_test_and_set_bit)
+	testop	orreq, streq
+ENDPROC(_test_and_set_bit)
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 13:14:32 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 13:14:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZ0HA-0002K8-Cx; Fri, 09 Dec 2011 13:14:08 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RZ0H7-0002I7-My
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 13:14:06 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1323436276!47643481!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMTkxNzY=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30516 invoked from network); 9 Dec 2011 13:11:17 -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 2011 13:11:17 -0000
X-IronPort-AV: E=Sophos;i="4.71,325,1320642000"; d="scan'208";a="173546263"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 08:13:19 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 08:13:19 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pB9DCpDu008248;
	Fri, 9 Dec 2011 05:13:07 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 9 Dec 2011 13:13:13 +0000
Message-ID: <1323436408-16335-10-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1112091208420.3517@kaball-desktop>
References: <alpine.DEB.2.00.1112091208420.3517@kaball-desktop>
MIME-Version: 1.0
Cc: keir.xen@gmail.com, Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, JBeulich@suse.com,
	Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v2 10/25] arm: bit manipulation,
	copy and division libraries
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Bit manipulation, division and memcpy & friends implementations for the
ARM architecture, shamelessly taken from Linux.


Changes in v2:

- implement __aeabi_uldivmod and __aeabi_ldivmod.


Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
---
 xen/arch/arm/lib/Makefile        |    5 +
 xen/arch/arm/lib/assembler.h     |   49 ++++++
 xen/arch/arm/lib/bitops.h        |   36 +++++
 xen/arch/arm/lib/changebit.S     |   18 +++
 xen/arch/arm/lib/clearbit.S      |   19 +++
 xen/arch/arm/lib/copy_template.S |  266 +++++++++++++++++++++++++++++++++
 xen/arch/arm/lib/div64.S         |  149 +++++++++++++++++++
 xen/arch/arm/lib/findbit.S       |  115 +++++++++++++++
 xen/arch/arm/lib/lib1funcs.S     |  302 ++++++++++++++++++++++++++++++++++++++
 xen/arch/arm/lib/memcpy.S        |   64 ++++++++
 xen/arch/arm/lib/memmove.S       |  200 +++++++++++++++++++++++++
 xen/arch/arm/lib/memset.S        |  129 ++++++++++++++++
 xen/arch/arm/lib/memzero.S       |  127 ++++++++++++++++
 xen/arch/arm/lib/setbit.S        |   18 +++
 xen/arch/arm/lib/testchangebit.S |   18 +++
 xen/arch/arm/lib/testclearbit.S  |   18 +++
 xen/arch/arm/lib/testsetbit.S    |   18 +++
 17 files changed, 1551 insertions(+), 0 deletions(-)
 create mode 100644 xen/arch/arm/lib/Makefile
 create mode 100644 xen/arch/arm/lib/assembler.h
 create mode 100644 xen/arch/arm/lib/bitops.h
 create mode 100644 xen/arch/arm/lib/changebit.S
 create mode 100644 xen/arch/arm/lib/clearbit.S
 create mode 100644 xen/arch/arm/lib/copy_template.S
 create mode 100644 xen/arch/arm/lib/div64.S
 create mode 100644 xen/arch/arm/lib/findbit.S
 create mode 100644 xen/arch/arm/lib/lib1funcs.S
 create mode 100644 xen/arch/arm/lib/memcpy.S
 create mode 100644 xen/arch/arm/lib/memmove.S
 create mode 100644 xen/arch/arm/lib/memset.S
 create mode 100644 xen/arch/arm/lib/memzero.S
 create mode 100644 xen/arch/arm/lib/setbit.S
 create mode 100644 xen/arch/arm/lib/testchangebit.S
 create mode 100644 xen/arch/arm/lib/testclearbit.S
 create mode 100644 xen/arch/arm/lib/testsetbit.S

diff --git a/xen/arch/arm/lib/Makefile b/xen/arch/arm/lib/Makefile
new file mode 100644
index 0000000..cbbed68
--- /dev/null
+++ b/xen/arch/arm/lib/Makefile
@@ -0,0 +1,5 @@
+obj-y += memcpy.o memmove.o memset.o memzero.o
+obj-y += findbit.o setbit.o
+obj-y += setbit.o clearbit.o changebit.o
+obj-y += testsetbit.o testclearbit.o testchangebit.o
+obj-y += lib1funcs.o div64.o
diff --git a/xen/arch/arm/lib/assembler.h b/xen/arch/arm/lib/assembler.h
new file mode 100644
index 0000000..f8f0961
--- /dev/null
+++ b/xen/arch/arm/lib/assembler.h
@@ -0,0 +1,49 @@
+#ifndef __ARCH_ARM_LIB_ASSEMBLER_H__
+#define __ARCH_ARM_LIB_ASSEMBLER_H__
+
+/* From Linux arch/arm/include/asm/assembler.h */
+/*
+ * Data preload for architectures that support it
+ */
+#define PLD(code...)    code
+
+/*
+ * This can be used to enable code to cacheline align the destination
+ * pointer when bulk writing to memory.  Experiments on StrongARM and
+ * XScale didn't show this a worthwhile thing to do when the cache is not
+ * set to write-allocate (this would need further testing on XScale when WA
+ * is used).
+ *
+ * On Feroceon there is much to gain however, regardless of cache mode.
+ */
+#ifdef CONFIG_CPU_FEROCEON /* Not in Xen... */
+#define CALGN(code...) code
+#else
+#define CALGN(code...)
+#endif
+
+// No Thumb, hence:
+#define W(instr)        instr
+#define ARM(instr...)   instr
+#define THUMB(instr...)
+
+#ifdef CONFIG_ARM_UNWIND
+#define UNWIND(code...)         code
+#else
+#define UNWIND(code...)
+#endif
+
+#define pull            lsl
+#define push            lsr
+#define get_byte_0      lsr #24
+#define get_byte_1      lsr #16
+#define get_byte_2      lsr #8
+#define get_byte_3      lsl #0
+#define put_byte_0      lsl #24
+#define put_byte_1      lsl #16
+#define put_byte_2      lsl #8
+#define put_byte_3      lsl #0
+
+#define smp_dmb dmb
+
+#endif /*  __ARCH_ARM_LIB_ASSEMBLER_H__ */
diff --git a/xen/arch/arm/lib/bitops.h b/xen/arch/arm/lib/bitops.h
new file mode 100644
index 0000000..e56d4e8
--- /dev/null
+++ b/xen/arch/arm/lib/bitops.h
@@ -0,0 +1,36 @@
+	.macro	bitop, instr
+	ands	ip, r1, #3
+	strneb	r1, [ip]		@ assert word-aligned
+	mov	r2, #1
+	and	r3, r0, #31		@ Get bit offset
+	mov	r0, r0, lsr #5
+	add	r1, r1, r0, lsl #2	@ Get word offset
+	mov	r3, r2, lsl r3
+1:	ldrex	r2, [r1]
+	\instr	r2, r2, r3
+	strex	r0, r2, [r1]
+	cmp	r0, #0
+	bne	1b
+	bx	lr
+	.endm
+
+	.macro	testop, instr, store
+	ands	ip, r1, #3
+	strneb	r1, [ip]		@ assert word-aligned
+	mov	r2, #1
+	and	r3, r0, #31		@ Get bit offset
+	mov	r0, r0, lsr #5
+	add	r1, r1, r0, lsl #2	@ Get word offset
+	mov	r3, r2, lsl r3		@ create mask
+	smp_dmb
+1:	ldrex	r2, [r1]
+	ands	r0, r2, r3		@ save old value of bit
+	\instr	r2, r2, r3		@ toggle bit
+	strex	ip, r2, [r1]
+	cmp	ip, #0
+	bne	1b
+	smp_dmb
+	cmp	r0, #0
+	movne	r0, #1
+2:	bx	lr
+	.endm
diff --git a/xen/arch/arm/lib/changebit.S b/xen/arch/arm/lib/changebit.S
new file mode 100644
index 0000000..62954bc
--- /dev/null
+++ b/xen/arch/arm/lib/changebit.S
@@ -0,0 +1,18 @@
+/*
+ *  linux/arch/arm/lib/changebit.S
+ *
+ *  Copyright (C) 1995-1996 Russell King
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#include <xen/config.h>
+
+#include "assembler.h"
+#include "bitops.h"
+                .text
+
+ENTRY(_change_bit)
+	bitop	eor
+ENDPROC(_change_bit)
diff --git a/xen/arch/arm/lib/clearbit.S b/xen/arch/arm/lib/clearbit.S
new file mode 100644
index 0000000..42ce416
--- /dev/null
+++ b/xen/arch/arm/lib/clearbit.S
@@ -0,0 +1,19 @@
+/*
+ *  linux/arch/arm/lib/clearbit.S
+ *
+ *  Copyright (C) 1995-1996 Russell King
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <xen/config.h>
+
+#include "assembler.h"
+#include "bitops.h"
+                .text
+
+ENTRY(_clear_bit)
+	bitop	bic
+ENDPROC(_clear_bit)
diff --git a/xen/arch/arm/lib/copy_template.S b/xen/arch/arm/lib/copy_template.S
new file mode 100644
index 0000000..7f7f4d5
--- /dev/null
+++ b/xen/arch/arm/lib/copy_template.S
@@ -0,0 +1,266 @@
+/*
+ *  linux/arch/arm/lib/copy_template.s
+ *
+ *  Code template for optimized memory copy functions
+ *
+ *  Author:	Nicolas Pitre
+ *  Created:	Sep 28, 2005
+ *  Copyright:	MontaVista Software, Inc.
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License version 2 as
+ *  published by the Free Software Foundation.
+ */
+
+/*
+ * Theory of operation
+ * -------------------
+ *
+ * This file provides the core code for a forward memory copy used in
+ * the implementation of memcopy(), copy_to_user() and copy_from_user().
+ *
+ * The including file must define the following accessor macros
+ * according to the need of the given function:
+ *
+ * ldr1w ptr reg abort
+ *
+ *	This loads one word from 'ptr', stores it in 'reg' and increments
+ *	'ptr' to the next word. The 'abort' argument is used for fixup tables.
+ *
+ * ldr4w ptr reg1 reg2 reg3 reg4 abort
+ * ldr8w ptr, reg1 reg2 reg3 reg4 reg5 reg6 reg7 reg8 abort
+ *
+ *	This loads four or eight words starting from 'ptr', stores them
+ *	in provided registers and increments 'ptr' past those words.
+ *	The'abort' argument is used for fixup tables.
+ *
+ * ldr1b ptr reg cond abort
+ *
+ *	Similar to ldr1w, but it loads a byte and increments 'ptr' one byte.
+ *	It also must apply the condition code if provided, otherwise the
+ *	"al" condition is assumed by default.
+ *
+ * str1w ptr reg abort
+ * str8w ptr reg1 reg2 reg3 reg4 reg5 reg6 reg7 reg8 abort
+ * str1b ptr reg cond abort
+ *
+ *	Same as their ldr* counterparts, but data is stored to 'ptr' location
+ *	rather than being loaded.
+ *
+ * enter reg1 reg2
+ *
+ *	Preserve the provided registers on the stack plus any additional
+ *	data as needed by the implementation including this code. Called
+ *	upon code entry.
+ *
+ * exit reg1 reg2
+ *
+ *	Restore registers with the values previously saved with the
+ *	'preserv' macro. Called upon code termination.
+ *
+ * LDR1W_SHIFT
+ * STR1W_SHIFT
+ *
+ *	Correction to be applied to the "ip" register when branching into
+ *	the ldr1w or str1w instructions (some of these macros may expand to
+ *	than one 32bit instruction in Thumb-2)
+ */
+
+		enter	r4, lr
+
+		subs	r2, r2, #4
+		blt	8f
+		ands	ip, r0, #3
+	PLD(	pld	[r1, #0]		)
+		bne	9f
+		ands	ip, r1, #3
+		bne	10f
+
+1:		subs	r2, r2, #(28)
+		stmfd	sp!, {r5 - r8}
+		blt	5f
+
+	CALGN(	ands	ip, r0, #31		)
+	CALGN(	rsb	r3, ip, #32		)
+	CALGN(	sbcnes	r4, r3, r2		)  @ C is always set here
+	CALGN(	bcs	2f			)
+	CALGN(	adr	r4, 6f			)
+	CALGN(	subs	r2, r2, r3		)  @ C gets set
+	CALGN(	add	pc, r4, ip		)
+
+	PLD(	pld	[r1, #0]		)
+2:	PLD(	subs	r2, r2, #96		)
+	PLD(	pld	[r1, #28]		)
+	PLD(	blt	4f			)
+	PLD(	pld	[r1, #60]		)
+	PLD(	pld	[r1, #92]		)
+
+3:	PLD(	pld	[r1, #124]		)
+4:		ldr8w	r1, r3, r4, r5, r6, r7, r8, ip, lr, abort=20f
+		subs	r2, r2, #32
+		str8w	r0, r3, r4, r5, r6, r7, r8, ip, lr, abort=20f
+		bge	3b
+	PLD(	cmn	r2, #96			)
+	PLD(	bge	4b			)
+
+5:		ands	ip, r2, #28
+		rsb	ip, ip, #32
+#if LDR1W_SHIFT > 0
+		lsl	ip, ip, #LDR1W_SHIFT
+#endif
+		addne	pc, pc, ip		@ C is always clear here
+		b	7f
+6:
+		.rept	(1 << LDR1W_SHIFT)
+		W(nop)
+		.endr
+		ldr1w	r1, r3, abort=20f
+		ldr1w	r1, r4, abort=20f
+		ldr1w	r1, r5, abort=20f
+		ldr1w	r1, r6, abort=20f
+		ldr1w	r1, r7, abort=20f
+		ldr1w	r1, r8, abort=20f
+		ldr1w	r1, lr, abort=20f
+
+#if LDR1W_SHIFT < STR1W_SHIFT
+		lsl	ip, ip, #STR1W_SHIFT - LDR1W_SHIFT
+#elif LDR1W_SHIFT > STR1W_SHIFT
+		lsr	ip, ip, #LDR1W_SHIFT - STR1W_SHIFT
+#endif
+		add	pc, pc, ip
+		nop
+		.rept	(1 << STR1W_SHIFT)
+		W(nop)
+		.endr
+		str1w	r0, r3, abort=20f
+		str1w	r0, r4, abort=20f
+		str1w	r0, r5, abort=20f
+		str1w	r0, r6, abort=20f
+		str1w	r0, r7, abort=20f
+		str1w	r0, r8, abort=20f
+		str1w	r0, lr, abort=20f
+
+	CALGN(	bcs	2b			)
+
+7:		ldmfd	sp!, {r5 - r8}
+
+8:		movs	r2, r2, lsl #31
+		ldr1b	r1, r3, ne, abort=21f
+		ldr1b	r1, r4, cs, abort=21f
+		ldr1b	r1, ip, cs, abort=21f
+		str1b	r0, r3, ne, abort=21f
+		str1b	r0, r4, cs, abort=21f
+		str1b	r0, ip, cs, abort=21f
+
+		exit	r4, pc
+
+9:		rsb	ip, ip, #4
+		cmp	ip, #2
+		ldr1b	r1, r3, gt, abort=21f
+		ldr1b	r1, r4, ge, abort=21f
+		ldr1b	r1, lr, abort=21f
+		str1b	r0, r3, gt, abort=21f
+		str1b	r0, r4, ge, abort=21f
+		subs	r2, r2, ip
+		str1b	r0, lr, abort=21f
+		blt	8b
+		ands	ip, r1, #3
+		beq	1b
+
+10:		bic	r1, r1, #3
+		cmp	ip, #2
+		ldr1w	r1, lr, abort=21f
+		beq	17f
+		bgt	18f
+
+
+		.macro	forward_copy_shift pull push
+
+		subs	r2, r2, #28
+		blt	14f
+
+	CALGN(	ands	ip, r0, #31		)
+	CALGN(	rsb	ip, ip, #32		)
+	CALGN(	sbcnes	r4, ip, r2		)  @ C is always set here
+	CALGN(	subcc	r2, r2, ip		)
+	CALGN(	bcc	15f			)
+
+11:		stmfd	sp!, {r5 - r9}
+
+	PLD(	pld	[r1, #0]		)
+	PLD(	subs	r2, r2, #96		)
+	PLD(	pld	[r1, #28]		)
+	PLD(	blt	13f			)
+	PLD(	pld	[r1, #60]		)
+	PLD(	pld	[r1, #92]		)
+
+12:	PLD(	pld	[r1, #124]		)
+13:		ldr4w	r1, r4, r5, r6, r7, abort=19f
+		mov	r3, lr, pull #\pull
+		subs	r2, r2, #32
+		ldr4w	r1, r8, r9, ip, lr, abort=19f
+		orr	r3, r3, r4, push #\push
+		mov	r4, r4, pull #\pull
+		orr	r4, r4, r5, push #\push
+		mov	r5, r5, pull #\pull
+		orr	r5, r5, r6, push #\push
+		mov	r6, r6, pull #\pull
+		orr	r6, r6, r7, push #\push
+		mov	r7, r7, pull #\pull
+		orr	r7, r7, r8, push #\push
+		mov	r8, r8, pull #\pull
+		orr	r8, r8, r9, push #\push
+		mov	r9, r9, pull #\pull
+		orr	r9, r9, ip, push #\push
+		mov	ip, ip, pull #\pull
+		orr	ip, ip, lr, push #\push
+		str8w	r0, r3, r4, r5, r6, r7, r8, r9, ip, , abort=19f
+		bge	12b
+	PLD(	cmn	r2, #96			)
+	PLD(	bge	13b			)
+
+		ldmfd	sp!, {r5 - r9}
+
+14:		ands	ip, r2, #28
+		beq	16f
+
+15:		mov	r3, lr, pull #\pull
+		ldr1w	r1, lr, abort=21f
+		subs	ip, ip, #4
+		orr	r3, r3, lr, push #\push
+		str1w	r0, r3, abort=21f
+		bgt	15b
+	CALGN(	cmp	r2, #0			)
+	CALGN(	bge	11b			)
+
+16:		sub	r1, r1, #(\push / 8)
+		b	8b
+
+		.endm
+
+
+		forward_copy_shift	pull=8	push=24
+
+17:		forward_copy_shift	pull=16	push=16
+
+18:		forward_copy_shift	pull=24	push=8
+
+
+/*
+ * Abort preamble and completion macros.
+ * If a fixup handler is required then those macros must surround it.
+ * It is assumed that the fixup code will handle the private part of
+ * the exit macro.
+ */
+
+	.macro	copy_abort_preamble
+19:	ldmfd	sp!, {r5 - r9}
+	b	21f
+20:	ldmfd	sp!, {r5 - r8}
+21:
+	.endm
+
+	.macro	copy_abort_end
+	ldmfd	sp!, {r4, pc}
+	.endm
+
diff --git a/xen/arch/arm/lib/div64.S b/xen/arch/arm/lib/div64.S
new file mode 100644
index 0000000..2584772
--- /dev/null
+++ b/xen/arch/arm/lib/div64.S
@@ -0,0 +1,149 @@
+/*
+ *  linux/arch/arm/lib/div64.S
+ *
+ *  Optimized computation of 64-bit dividend / 32-bit divisor
+ *
+ *  Author:	Nicolas Pitre
+ *  Created:	Oct 5, 2003
+ *  Copyright:	Monta Vista Software, Inc.
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License version 2 as
+ *  published by the Free Software Foundation.
+ */
+
+#include <xen/config.h>
+#include "assembler.h"
+	
+#define xl r0
+#define xh r1
+#define yl r2
+#define yh r3
+
+/*
+ * __do_div64: perform a division with 64-bit dividend and 32-bit divisor.
+ *
+ * Note: Calling convention is totally non standard for optimal code.
+ *       This is meant to be used by do_div() from include/asm/div64.h only.
+ *
+ * Input parameters:
+ * 	xh-xl	= dividend (clobbered)
+ * 	r4	= divisor (preserved)
+ *
+ * Output values:
+ * 	yh-yl	= result
+ * 	xh	= remainder
+ *
+ * Clobbered regs: xl, ip
+ */
+
+ENTRY(__do_div64)
+
+	@ Test for easy paths first.
+	subs	ip, r4, #1
+	bls	9f			@ divisor is 0 or 1
+	tst	ip, r4
+	beq	8f			@ divisor is power of 2
+
+	@ See if we need to handle upper 32-bit result.
+	cmp	xh, r4
+	mov	yh, #0
+	blo	3f
+
+	@ Align divisor with upper part of dividend.
+	@ The aligned divisor is stored in yl preserving the original.
+	@ The bit position is stored in ip.
+
+	clz	yl, r4
+	clz	ip, xh
+	sub	yl, yl, ip
+	mov	ip, #1
+	mov	ip, ip, lsl yl
+	mov	yl, r4, lsl yl
+
+	@ The division loop for needed upper bit positions.
+ 	@ Break out early if dividend reaches 0.
+2:	cmp	xh, yl
+	orrcs	yh, yh, ip
+	subcss	xh, xh, yl
+	movnes	ip, ip, lsr #1
+	mov	yl, yl, lsr #1
+	bne	2b
+
+	@ See if we need to handle lower 32-bit result.
+3:	cmp	xh, #0
+	mov	yl, #0
+	cmpeq	xl, r4
+	movlo	xh, xl
+	movlo	pc, lr
+
+	@ The division loop for lower bit positions.
+	@ Here we shift remainer bits leftwards rather than moving the
+	@ divisor for comparisons, considering the carry-out bit as well.
+	mov	ip, #0x80000000
+4:	movs	xl, xl, lsl #1
+	adcs	xh, xh, xh
+	beq	6f
+	cmpcc	xh, r4
+5:	orrcs	yl, yl, ip
+	subcs	xh, xh, r4
+	movs	ip, ip, lsr #1
+	bne	4b
+	mov	pc, lr
+
+	@ The top part of remainder became zero.  If carry is set
+	@ (the 33th bit) this is a false positive so resume the loop.
+	@ Otherwise, if lower part is also null then we are done.
+6:	bcs	5b
+	cmp	xl, #0
+	moveq	pc, lr
+
+	@ We still have remainer bits in the low part.  Bring them up.
+
+	clz	xh, xl			@ we know xh is zero here so...
+	add	xh, xh, #1
+	mov	xl, xl, lsl xh
+	mov	ip, ip, lsr xh
+
+	@ Current remainder is now 1.  It is worthless to compare with
+	@ divisor at this point since divisor can not be smaller than 3 here.
+	@ If possible, branch for another shift in the division loop.
+	@ If no bit position left then we are done.
+	movs	ip, ip, lsr #1
+	mov	xh, #1
+	bne	4b
+	mov	pc, lr
+
+8:	@ Division by a power of 2: determine what that divisor order is
+	@ then simply shift values around
+
+	clz	ip, r4
+	rsb	ip, ip, #31
+
+	mov	yh, xh, lsr ip
+	mov	yl, xl, lsr ip
+	rsb	ip, ip, #32
+ ARM(	orr	yl, yl, xh, lsl ip	)
+ THUMB(	lsl	xh, xh, ip		)
+ THUMB(	orr	yl, yl, xh		)
+	mov	xh, xl, lsl ip
+	mov	xh, xh, lsr ip
+	mov	pc, lr
+
+	@ eq -> division by 1: obvious enough...
+9:	moveq	yl, xl
+	moveq	yh, xh
+	moveq	xh, #0
+	moveq	pc, lr
+
+	@ Division by 0:
+	str	lr, [sp, #-8]!
+	bl	__div0
+
+	@ as wrong as it could be...
+	mov	yl, #0
+	mov	yh, #0
+	mov	xh, #0
+	ldr	pc, [sp], #8
+
+ENDPROC(__do_div64)
diff --git a/xen/arch/arm/lib/findbit.S b/xen/arch/arm/lib/findbit.S
new file mode 100644
index 0000000..5669b91
--- /dev/null
+++ b/xen/arch/arm/lib/findbit.S
@@ -0,0 +1,115 @@
+/*
+ *  linux/arch/arm/lib/findbit.S
+ *
+ *  Copyright (C) 1995-2000 Russell King
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * 16th March 2001 - John Ripley <jripley@sonicblue.com>
+ *   Fixed so that "size" is an exclusive not an inclusive quantity.
+ *   All users of these functions expect exclusive sizes, and may
+ *   also call with zero size.
+ * Reworked by rmk.
+ */
+
+#include <xen/config.h>
+
+#include "assembler.h"
+                .text
+
+/*
+ * Purpose  : Find a 'zero' bit
+ * Prototype: int find_first_zero_bit(void *addr, unsigned int maxbit);
+ */
+ENTRY(_find_first_zero_bit)
+		teq	r1, #0	
+		beq	3f
+		mov	r2, #0
+1:
+ ARM(		ldrb	r3, [r0, r2, lsr #3]	)
+ THUMB(		lsr	r3, r2, #3		)
+ THUMB(		ldrb	r3, [r0, r3]		)
+		eors	r3, r3, #0xff		@ invert bits
+		bne	.L_found		@ any now set - found zero bit
+		add	r2, r2, #8		@ next bit pointer
+2:		cmp	r2, r1			@ any more?
+		blo	1b
+3:		mov	r0, r1			@ no free bits
+		mov	pc, lr
+ENDPROC(_find_first_zero_bit)
+
+/*
+ * Purpose  : Find next 'zero' bit
+ * Prototype: int find_next_zero_bit(void *addr, unsigned int maxbit, int offset)
+ */
+ENTRY(_find_next_zero_bit)
+		teq	r1, #0
+		beq	3b
+		ands	ip, r2, #7
+		beq	1b			@ If new byte, goto old routine
+ ARM(		ldrb	r3, [r0, r2, lsr #3]	)
+ THUMB(		lsr	r3, r2, #3		)
+ THUMB(		ldrb	r3, [r0, r3]		)
+		eor	r3, r3, #0xff		@ now looking for a 1 bit
+		movs	r3, r3, lsr ip		@ shift off unused bits
+		bne	.L_found
+		orr	r2, r2, #7		@ if zero, then no bits here
+		add	r2, r2, #1		@ align bit pointer
+		b	2b			@ loop for next bit
+ENDPROC(_find_next_zero_bit)
+
+/*
+ * Purpose  : Find a 'one' bit
+ * Prototype: int find_first_bit(const unsigned long *addr, unsigned int maxbit);
+ */
+ENTRY(_find_first_bit)
+		teq	r1, #0	
+		beq	3f
+		mov	r2, #0
+1:
+ ARM(		ldrb	r3, [r0, r2, lsr #3]	)
+ THUMB(		lsr	r3, r2, #3		)
+ THUMB(		ldrb	r3, [r0, r3]		)
+		movs	r3, r3
+		bne	.L_found		@ any now set - found zero bit
+		add	r2, r2, #8		@ next bit pointer
+2:		cmp	r2, r1			@ any more?
+		blo	1b
+3:		mov	r0, r1			@ no free bits
+		mov	pc, lr
+ENDPROC(_find_first_bit)
+
+/*
+ * Purpose  : Find next 'one' bit
+ * Prototype: int find_next_zero_bit(void *addr, unsigned int maxbit, int offset)
+ */
+ENTRY(_find_next_bit)
+		teq	r1, #0
+		beq	3b
+		ands	ip, r2, #7
+		beq	1b			@ If new byte, goto old routine
+ ARM(		ldrb	r3, [r0, r2, lsr #3]	)
+ THUMB(		lsr	r3, r2, #3		)
+ THUMB(		ldrb	r3, [r0, r3]		)
+		movs	r3, r3, lsr ip		@ shift off unused bits
+		bne	.L_found
+		orr	r2, r2, #7		@ if zero, then no bits here
+		add	r2, r2, #1		@ align bit pointer
+		b	2b			@ loop for next bit
+ENDPROC(_find_next_bit)
+
+/*
+ * One or more bits in the LSB of r3 are assumed to be set.
+ */
+.L_found:
+		rsb	r0, r3, #0
+		and	r3, r3, r0
+		clz	r3, r3
+		rsb	r3, r3, #31
+		add	r0, r2, r3
+		cmp	r1, r0			@ Clamp to maxbit
+		movlo	r0, r1
+		mov	pc, lr
+
diff --git a/xen/arch/arm/lib/lib1funcs.S b/xen/arch/arm/lib/lib1funcs.S
new file mode 100644
index 0000000..828e688
--- /dev/null
+++ b/xen/arch/arm/lib/lib1funcs.S
@@ -0,0 +1,302 @@
+/*
+ * linux/arch/arm/lib/lib1funcs.S: Optimized ARM division routines
+ *
+ * Author: Nicolas Pitre <nico@fluxnic.net>
+ *   - contributed to gcc-3.4 on Sep 30, 2003
+ *   - adapted for the Linux kernel on Oct 2, 2003
+ */
+
+/* Copyright 1995, 1996, 1998, 1999, 2000, 2003 Free Software Foundation, Inc.
+
+This file 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, or (at your option) any
+later version.
+
+In addition to the permissions in the GNU General Public License, the
+Free Software Foundation gives you unlimited permission to link the
+compiled version of this file into combinations with other programs,
+and to distribute those combinations without any restriction coming
+from the use of this file.  (The General Public License restrictions
+do apply in other respects; for example, they cover modification of
+the file, and distribution when not linked into a combine
+executable.)
+
+This file is distributed in the hope that it will be useful, but
+WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  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; see the file COPYING.  If not, write to
+the Free Software Foundation, 59 Temple Place - Suite 330,
+Boston, MA 02111-1307, USA.  */
+
+
+#include <xen/config.h>
+#include "assembler.h"
+
+.macro ARM_DIV_BODY dividend, divisor, result, curbit
+
+	clz	\curbit, \divisor
+	clz	\result, \dividend
+	sub	\result, \curbit, \result
+	mov	\curbit, #1
+	mov	\divisor, \divisor, lsl \result
+	mov	\curbit, \curbit, lsl \result
+	mov	\result, #0
+	
+	@ Division loop
+1:	cmp	\dividend, \divisor
+	subhs	\dividend, \dividend, \divisor
+	orrhs	\result,   \result,   \curbit
+	cmp	\dividend, \divisor,  lsr #1
+	subhs	\dividend, \dividend, \divisor, lsr #1
+	orrhs	\result,   \result,   \curbit,  lsr #1
+	cmp	\dividend, \divisor,  lsr #2
+	subhs	\dividend, \dividend, \divisor, lsr #2
+	orrhs	\result,   \result,   \curbit,  lsr #2
+	cmp	\dividend, \divisor,  lsr #3
+	subhs	\dividend, \dividend, \divisor, lsr #3
+	orrhs	\result,   \result,   \curbit,  lsr #3
+	cmp	\dividend, #0			@ Early termination?
+	movnes	\curbit,   \curbit,  lsr #4	@ No, any more bits to do?
+	movne	\divisor,  \divisor, lsr #4
+	bne	1b
+
+.endm
+
+
+.macro ARM_DIV2_ORDER divisor, order
+
+	clz	\order, \divisor
+	rsb	\order, \order, #31
+
+.endm
+
+
+.macro ARM_MOD_BODY dividend, divisor, order, spare
+
+	clz	\order, \divisor
+	clz	\spare, \dividend
+	sub	\order, \order, \spare
+	mov	\divisor, \divisor, lsl \order
+
+	@ Perform all needed substractions to keep only the reminder.
+	@ Do comparisons in batch of 4 first.
+	subs	\order, \order, #3		@ yes, 3 is intended here
+	blt	2f
+
+1:	cmp	\dividend, \divisor
+	subhs	\dividend, \dividend, \divisor
+	cmp	\dividend, \divisor,  lsr #1
+	subhs	\dividend, \dividend, \divisor, lsr #1
+	cmp	\dividend, \divisor,  lsr #2
+	subhs	\dividend, \dividend, \divisor, lsr #2
+	cmp	\dividend, \divisor,  lsr #3
+	subhs	\dividend, \dividend, \divisor, lsr #3
+	cmp	\dividend, #1
+	mov	\divisor, \divisor, lsr #4
+	subges	\order, \order, #4
+	bge	1b
+
+	tst	\order, #3
+	teqne	\dividend, #0
+	beq	5f
+
+	@ Either 1, 2 or 3 comparison/substractions are left.
+2:	cmn	\order, #2
+	blt	4f
+	beq	3f
+	cmp	\dividend, \divisor
+	subhs	\dividend, \dividend, \divisor
+	mov	\divisor,  \divisor,  lsr #1
+3:	cmp	\dividend, \divisor
+	subhs	\dividend, \dividend, \divisor
+	mov	\divisor,  \divisor,  lsr #1
+4:	cmp	\dividend, \divisor
+	subhs	\dividend, \dividend, \divisor
+5:
+.endm
+
+
+ENTRY(__udivsi3)
+ENTRY(__aeabi_uidiv)
+UNWIND(.fnstart)
+
+	subs	r2, r1, #1
+	moveq	pc, lr
+	bcc	Ldiv0
+	cmp	r0, r1
+	bls	11f
+	tst	r1, r2
+	beq	12f
+
+	ARM_DIV_BODY r0, r1, r2, r3
+
+	mov	r0, r2
+	mov	pc, lr
+
+11:	moveq	r0, #1
+	movne	r0, #0
+	mov	pc, lr
+
+12:	ARM_DIV2_ORDER r1, r2
+
+	mov	r0, r0, lsr r2
+	mov	pc, lr
+
+UNWIND(.fnend)
+ENDPROC(__udivsi3)
+ENDPROC(__aeabi_uidiv)
+
+ENTRY(__umodsi3)
+UNWIND(.fnstart)
+
+	subs	r2, r1, #1			@ compare divisor with 1
+	bcc	Ldiv0
+	cmpne	r0, r1				@ compare dividend with divisor
+	moveq   r0, #0
+	tsthi	r1, r2				@ see if divisor is power of 2
+	andeq	r0, r0, r2
+	movls	pc, lr
+
+	ARM_MOD_BODY r0, r1, r2, r3
+
+	mov	pc, lr
+
+UNWIND(.fnend)
+ENDPROC(__umodsi3)
+
+ENTRY(__divsi3)
+ENTRY(__aeabi_idiv)
+UNWIND(.fnstart)
+
+	cmp	r1, #0
+	eor	ip, r0, r1			@ save the sign of the result.
+	beq	Ldiv0
+	rsbmi	r1, r1, #0			@ loops below use unsigned.
+	subs	r2, r1, #1			@ division by 1 or -1 ?
+	beq	10f
+	movs	r3, r0
+	rsbmi	r3, r0, #0			@ positive dividend value
+	cmp	r3, r1
+	bls	11f
+	tst	r1, r2				@ divisor is power of 2 ?
+	beq	12f
+
+	ARM_DIV_BODY r3, r1, r0, r2
+
+	cmp	ip, #0
+	rsbmi	r0, r0, #0
+	mov	pc, lr
+
+10:	teq	ip, r0				@ same sign ?
+	rsbmi	r0, r0, #0
+	mov	pc, lr
+
+11:	movlo	r0, #0
+	moveq	r0, ip, asr #31
+	orreq	r0, r0, #1
+	mov	pc, lr
+
+12:	ARM_DIV2_ORDER r1, r2
+
+	cmp	ip, #0
+	mov	r0, r3, lsr r2
+	rsbmi	r0, r0, #0
+	mov	pc, lr
+
+UNWIND(.fnend)
+ENDPROC(__divsi3)
+ENDPROC(__aeabi_idiv)
+
+ENTRY(__modsi3)
+UNWIND(.fnstart)
+
+	cmp	r1, #0
+	beq	Ldiv0
+	rsbmi	r1, r1, #0			@ loops below use unsigned.
+	movs	ip, r0				@ preserve sign of dividend
+	rsbmi	r0, r0, #0			@ if negative make positive
+	subs	r2, r1, #1			@ compare divisor with 1
+	cmpne	r0, r1				@ compare dividend with divisor
+	moveq	r0, #0
+	tsthi	r1, r2				@ see if divisor is power of 2
+	andeq	r0, r0, r2
+	bls	10f
+
+	ARM_MOD_BODY r0, r1, r2, r3
+
+10:	cmp	ip, #0
+	rsbmi	r0, r0, #0
+	mov	pc, lr
+
+UNWIND(.fnend)
+ENDPROC(__modsi3)
+
+ENTRY(__aeabi_uidivmod)
+UNWIND(.fnstart)
+UNWIND(.save {r0, r1, ip, lr}	)
+
+	stmfd	sp!, {r0, r1, ip, lr}
+	bl	__aeabi_uidiv
+	ldmfd	sp!, {r1, r2, ip, lr}
+	mul	r3, r0, r2
+	sub	r1, r1, r3
+	mov	pc, lr
+
+UNWIND(.fnend)
+ENDPROC(__aeabi_uidivmod)
+
+ENTRY(__aeabi_idivmod)
+UNWIND(.fnstart)
+UNWIND(.save {r0, r1, ip, lr}	)
+	stmfd	sp!, {r0, r1, ip, lr}
+	bl	__aeabi_idiv
+	ldmfd	sp!, {r1, r2, ip, lr}
+	mul	r3, r0, r2
+	sub	r1, r1, r3
+	mov	pc, lr
+
+UNWIND(.fnend)
+ENDPROC(__aeabi_idivmod)
+
+ENTRY(__aeabi_uldivmod)
+UNWIND(.fnstart)
+UNWIND(.save {lr}	)
+	sub sp, sp, #8
+	stmfd   sp!, {sp, lr}
+	bl __qdivrem
+	ldr lr, [sp, #4]
+	add sp, sp, #8
+	ldmfd sp!, {r2, r3}
+	mov	pc, lr
+
+UNWIND(.fnend)
+ENDPROC(__aeabi_uldivmod)
+
+ENTRY(__aeabi_ldivmod)
+UNWIND(.fnstart)
+UNWIND(.save {lr}	)
+	sub sp, sp, #16
+	stmfd   sp!, {sp, lr}
+	bl __ldivmod_helper
+	ldr lr, [sp, #4]
+	add sp, sp, #16
+	ldmfd	sp!, {r2, r3}
+	mov	pc, lr
+	
+UNWIND(.fnend)
+ENDPROC(__aeabi_uldivmod)
+
+Ldiv0:
+UNWIND(.fnstart)
+UNWIND(.pad #4)
+UNWIND(.save {lr})
+	str	lr, [sp, #-8]!
+	bl	__div0
+	mov	r0, #0			@ About as wrong as it could be.
+	ldr	pc, [sp], #8
+UNWIND(.fnend)
+ENDPROC(Ldiv0)
diff --git a/xen/arch/arm/lib/memcpy.S b/xen/arch/arm/lib/memcpy.S
new file mode 100644
index 0000000..f4bad5c
--- /dev/null
+++ b/xen/arch/arm/lib/memcpy.S
@@ -0,0 +1,64 @@
+/*
+ *  linux/arch/arm/lib/memcpy.S
+ *
+ *  Author:     Nicolas Pitre
+ *  Created:    Sep 28, 2005
+ *  Copyright:  MontaVista Software, Inc.
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License version 2 as
+ *  published by the Free Software Foundation.
+ */
+
+#include <xen/config.h>
+
+#include "assembler.h"
+
+#define LDR1W_SHIFT     0
+#define STR1W_SHIFT     0
+
+        .macro ldr1w ptr reg abort
+        W(ldr) \reg, [\ptr], #4
+        .endm
+
+        .macro ldr4w ptr reg1 reg2 reg3 reg4 abort
+        ldmia \ptr!, {\reg1, \reg2, \reg3, \reg4}
+        .endm
+
+        .macro ldr8w ptr reg1 reg2 reg3 reg4 reg5 reg6 reg7 reg8 abort
+        ldmia \ptr!, {\reg1, \reg2, \reg3, \reg4, \reg5, \reg6, \reg7, \reg8}
+        .endm
+
+        .macro ldr1b ptr reg cond=al abort
+        ldr\cond\()b \reg, [\ptr], #1
+        .endm
+
+        .macro str1w ptr reg abort
+        W(str) \reg, [\ptr], #4
+        .endm
+
+        .macro str8w ptr reg1 reg2 reg3 reg4 reg5 reg6 reg7 reg8 abort
+        stmia \ptr!, {\reg1, \reg2, \reg3, \reg4, \reg5, \reg6, \reg7, \reg8}
+        .endm
+
+        .macro str1b ptr reg cond=al abort
+        str\cond\()b \reg, [\ptr], #1
+        .endm
+
+        .macro enter reg1 reg2
+        stmdb sp!, {r0, \reg1, \reg2}
+        .endm
+
+        .macro exit reg1 reg2
+        ldmfd sp!, {r0, \reg1, \reg2}
+        .endm
+
+        .text
+
+/* Prototype: void *memcpy(void *dest, const void *src, size_t n); */
+
+ENTRY(memcpy)
+
+#include "copy_template.S"
+
+ENDPROC(memcpy)
diff --git a/xen/arch/arm/lib/memmove.S b/xen/arch/arm/lib/memmove.S
new file mode 100644
index 0000000..4e142b8
--- /dev/null
+++ b/xen/arch/arm/lib/memmove.S
@@ -0,0 +1,200 @@
+/*
+ *  linux/arch/arm/lib/memmove.S
+ *
+ *  Author:	Nicolas Pitre
+ *  Created:	Sep 28, 2005
+ *  Copyright:	(C) MontaVista Software Inc.
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License version 2 as
+ *  published by the Free Software Foundation.
+ */
+
+#include <xen/config.h>
+
+#include "assembler.h"
+
+		.text
+
+/*
+ * Prototype: void *memmove(void *dest, const void *src, size_t n);
+ *
+ * Note:
+ *
+ * If the memory regions don't overlap, we simply branch to memcpy which is
+ * normally a bit faster. Otherwise the copy is done going downwards.  This
+ * is a transposition of the code from copy_template.S but with the copy
+ * occurring in the opposite direction.
+ */
+
+ENTRY(memmove)
+
+		subs	ip, r0, r1
+		cmphi	r2, ip
+		bls	memcpy
+
+		stmfd	sp!, {r0, r4, lr}
+		add	r1, r1, r2
+		add	r0, r0, r2
+		subs	r2, r2, #4
+		blt	8f
+		ands	ip, r0, #3
+	PLD(	pld	[r1, #-4]		)
+		bne	9f
+		ands	ip, r1, #3
+		bne	10f
+
+1:		subs	r2, r2, #(28)
+		stmfd	sp!, {r5 - r8}
+		blt	5f
+
+	CALGN(	ands	ip, r0, #31		)
+	CALGN(	sbcnes	r4, ip, r2		)  @ C is always set here
+	CALGN(	bcs	2f			)
+	CALGN(	adr	r4, 6f			)
+	CALGN(	subs	r2, r2, ip		)  @ C is set here
+	CALGN(	rsb	ip, ip, #32		)
+	CALGN(	add	pc, r4, ip		)
+
+	PLD(	pld	[r1, #-4]		)
+2:	PLD(	subs	r2, r2, #96		)
+	PLD(	pld	[r1, #-32]		)
+	PLD(	blt	4f			)
+	PLD(	pld	[r1, #-64]		)
+	PLD(	pld	[r1, #-96]		)
+
+3:	PLD(	pld	[r1, #-128]		)
+4:		ldmdb	r1!, {r3, r4, r5, r6, r7, r8, ip, lr}
+		subs	r2, r2, #32
+		stmdb	r0!, {r3, r4, r5, r6, r7, r8, ip, lr}
+		bge	3b
+	PLD(	cmn	r2, #96			)
+	PLD(	bge	4b			)
+
+5:		ands	ip, r2, #28
+		rsb	ip, ip, #32
+		addne	pc, pc, ip		@ C is always clear here
+		b	7f
+6:		W(nop)
+		W(ldr)	r3, [r1, #-4]!
+		W(ldr)	r4, [r1, #-4]!
+		W(ldr)	r5, [r1, #-4]!
+		W(ldr)	r6, [r1, #-4]!
+		W(ldr)	r7, [r1, #-4]!
+		W(ldr)	r8, [r1, #-4]!
+		W(ldr)	lr, [r1, #-4]!
+
+		add	pc, pc, ip
+		nop
+		W(nop)
+		W(str)	r3, [r0, #-4]!
+		W(str)	r4, [r0, #-4]!
+		W(str)	r5, [r0, #-4]!
+		W(str)	r6, [r0, #-4]!
+		W(str)	r7, [r0, #-4]!
+		W(str)	r8, [r0, #-4]!
+		W(str)	lr, [r0, #-4]!
+
+	CALGN(	bcs	2b			)
+
+7:		ldmfd	sp!, {r5 - r8}
+
+8:		movs	r2, r2, lsl #31
+		ldrneb	r3, [r1, #-1]!
+		ldrcsb	r4, [r1, #-1]!
+		ldrcsb	ip, [r1, #-1]
+		strneb	r3, [r0, #-1]!
+		strcsb	r4, [r0, #-1]!
+		strcsb	ip, [r0, #-1]
+		ldmfd	sp!, {r0, r4, pc}
+
+9:		cmp	ip, #2
+		ldrgtb	r3, [r1, #-1]!
+		ldrgeb	r4, [r1, #-1]!
+		ldrb	lr, [r1, #-1]!
+		strgtb	r3, [r0, #-1]!
+		strgeb	r4, [r0, #-1]!
+		subs	r2, r2, ip
+		strb	lr, [r0, #-1]!
+		blt	8b
+		ands	ip, r1, #3
+		beq	1b
+
+10:		bic	r1, r1, #3
+		cmp	ip, #2
+		ldr	r3, [r1, #0]
+		beq	17f
+		blt	18f
+
+
+		.macro	backward_copy_shift push pull
+
+		subs	r2, r2, #28
+		blt	14f
+
+	CALGN(	ands	ip, r0, #31		)
+	CALGN(	sbcnes	r4, ip, r2		)  @ C is always set here
+	CALGN(	subcc	r2, r2, ip		)
+	CALGN(	bcc	15f			)
+
+11:		stmfd	sp!, {r5 - r9}
+
+	PLD(	pld	[r1, #-4]		)
+	PLD(	subs	r2, r2, #96		)
+	PLD(	pld	[r1, #-32]		)
+	PLD(	blt	13f			)
+	PLD(	pld	[r1, #-64]		)
+	PLD(	pld	[r1, #-96]		)
+
+12:	PLD(	pld	[r1, #-128]		)
+13:		ldmdb   r1!, {r7, r8, r9, ip}
+		mov     lr, r3, push #\push
+		subs    r2, r2, #32
+		ldmdb   r1!, {r3, r4, r5, r6}
+		orr     lr, lr, ip, pull #\pull
+		mov     ip, ip, push #\push
+		orr     ip, ip, r9, pull #\pull
+		mov     r9, r9, push #\push
+		orr     r9, r9, r8, pull #\pull
+		mov     r8, r8, push #\push
+		orr     r8, r8, r7, pull #\pull
+		mov     r7, r7, push #\push
+		orr     r7, r7, r6, pull #\pull
+		mov     r6, r6, push #\push
+		orr     r6, r6, r5, pull #\pull
+		mov     r5, r5, push #\push
+		orr     r5, r5, r4, pull #\pull
+		mov     r4, r4, push #\push
+		orr     r4, r4, r3, pull #\pull
+		stmdb   r0!, {r4 - r9, ip, lr}
+		bge	12b
+	PLD(	cmn	r2, #96			)
+	PLD(	bge	13b			)
+
+		ldmfd	sp!, {r5 - r9}
+
+14:		ands	ip, r2, #28
+		beq	16f
+
+15:		mov     lr, r3, push #\push
+		ldr	r3, [r1, #-4]!
+		subs	ip, ip, #4
+		orr	lr, lr, r3, pull #\pull
+		str	lr, [r0, #-4]!
+		bgt	15b
+	CALGN(	cmp	r2, #0			)
+	CALGN(	bge	11b			)
+
+16:		add	r1, r1, #(\pull / 8)
+		b	8b
+
+		.endm
+
+
+		backward_copy_shift	push=8	pull=24
+
+17:		backward_copy_shift	push=16	pull=16
+
+18:		backward_copy_shift	push=24	pull=8
+
+ENDPROC(memmove)
diff --git a/xen/arch/arm/lib/memset.S b/xen/arch/arm/lib/memset.S
new file mode 100644
index 0000000..d2937a3
--- /dev/null
+++ b/xen/arch/arm/lib/memset.S
@@ -0,0 +1,129 @@
+/*
+ *  linux/arch/arm/lib/memset.S
+ *
+ *  Copyright (C) 1995-2000 Russell King
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ *  ASM optimised string functions
+ */
+
+#include <xen/config.h>
+
+#include "assembler.h"
+
+	.text
+	.align	5
+	.word	0
+
+1:	subs	r2, r2, #4		@ 1 do we have enough
+	blt	5f			@ 1 bytes to align with?
+	cmp	r3, #2			@ 1
+	strltb	r1, [r0], #1		@ 1
+	strleb	r1, [r0], #1		@ 1
+	strb	r1, [r0], #1		@ 1
+	add	r2, r2, r3		@ 1 (r2 = r2 - (4 - r3))
+/*
+ * The pointer is now aligned and the length is adjusted.  Try doing the
+ * memset again.
+ */
+
+ENTRY(memset)
+	ands	r3, r0, #3		@ 1 unaligned?
+	bne	1b			@ 1
+/*
+ * we know that the pointer in r0 is aligned to a word boundary.
+ */
+	orr	r1, r1, r1, lsl #8
+	orr	r1, r1, r1, lsl #16
+	mov	r3, r1
+	cmp	r2, #16
+	blt	4f
+
+#if ! CALGN(1)+0
+
+/*
+ * We need an extra register for this loop - save the return address and
+ * use the LR
+ */
+	str	lr, [sp, #-4]!
+	mov	ip, r1
+	mov	lr, r1
+
+2:	subs	r2, r2, #64
+	stmgeia	r0!, {r1, r3, ip, lr}	@ 64 bytes at a time.
+	stmgeia	r0!, {r1, r3, ip, lr}
+	stmgeia	r0!, {r1, r3, ip, lr}
+	stmgeia	r0!, {r1, r3, ip, lr}
+	bgt	2b
+	ldmeqfd	sp!, {pc}		@ Now <64 bytes to go.
+/*
+ * No need to correct the count; we're only testing bits from now on
+ */
+	tst	r2, #32
+	stmneia	r0!, {r1, r3, ip, lr}
+	stmneia	r0!, {r1, r3, ip, lr}
+	tst	r2, #16
+	stmneia	r0!, {r1, r3, ip, lr}
+	ldr	lr, [sp], #4
+
+#else
+
+/*
+ * This version aligns the destination pointer in order to write
+ * whole cache lines at once.
+ */
+
+	stmfd	sp!, {r4-r7, lr}
+	mov	r4, r1
+	mov	r5, r1
+	mov	r6, r1
+	mov	r7, r1
+	mov	ip, r1
+	mov	lr, r1
+
+	cmp	r2, #96
+	tstgt	r0, #31
+	ble	3f
+
+	and	ip, r0, #31
+	rsb	ip, ip, #32
+	sub	r2, r2, ip
+	movs	ip, ip, lsl #(32 - 4)
+	stmcsia	r0!, {r4, r5, r6, r7}
+	stmmiia	r0!, {r4, r5}
+	tst	ip, #(1 << 30)
+	mov	ip, r1
+	strne	r1, [r0], #4
+
+3:	subs	r2, r2, #64
+	stmgeia	r0!, {r1, r3-r7, ip, lr}
+	stmgeia	r0!, {r1, r3-r7, ip, lr}
+	bgt	3b
+	ldmeqfd	sp!, {r4-r7, pc}
+
+	tst	r2, #32
+	stmneia	r0!, {r1, r3-r7, ip, lr}
+	tst	r2, #16
+	stmneia	r0!, {r4-r7}
+	ldmfd	sp!, {r4-r7, lr}
+
+#endif
+
+4:	tst	r2, #8
+	stmneia	r0!, {r1, r3}
+	tst	r2, #4
+	strne	r1, [r0], #4
+/*
+ * When we get here, we've got less than 4 bytes to zero.  We
+ * may have an unaligned pointer as well.
+ */
+5:	tst	r2, #2
+	strneb	r1, [r0], #1
+	strneb	r1, [r0], #1
+	tst	r2, #1
+	strneb	r1, [r0], #1
+	mov	pc, lr
+ENDPROC(memset)
diff --git a/xen/arch/arm/lib/memzero.S b/xen/arch/arm/lib/memzero.S
new file mode 100644
index 0000000..ce25aca
--- /dev/null
+++ b/xen/arch/arm/lib/memzero.S
@@ -0,0 +1,127 @@
+/*
+ *  linux/arch/arm/lib/memzero.S
+ *
+ *  Copyright (C) 1995-2000 Russell King
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <xen/config.h>
+
+#include "assembler.h"
+
+	.text
+	.align	5
+	.word	0
+/*
+ * Align the pointer in r0.  r3 contains the number of bytes that we are
+ * mis-aligned by, and r1 is the number of bytes.  If r1 < 4, then we
+ * don't bother; we use byte stores instead.
+ */
+1:	subs	r1, r1, #4		@ 1 do we have enough
+	blt	5f			@ 1 bytes to align with?
+	cmp	r3, #2			@ 1
+	strltb	r2, [r0], #1		@ 1
+	strleb	r2, [r0], #1		@ 1
+	strb	r2, [r0], #1		@ 1
+	add	r1, r1, r3		@ 1 (r1 = r1 - (4 - r3))
+/*
+ * The pointer is now aligned and the length is adjusted.  Try doing the
+ * memzero again.
+ */
+
+ENTRY(__memzero)
+	mov	r2, #0			@ 1
+	ands	r3, r0, #3		@ 1 unaligned?
+	bne	1b			@ 1
+/*
+ * r3 = 0, and we know that the pointer in r0 is aligned to a word boundary.
+ */
+	cmp	r1, #16			@ 1 we can skip this chunk if we
+	blt	4f			@ 1 have < 16 bytes
+
+#if ! CALGN(1)+0
+
+/*
+ * We need an extra register for this loop - save the return address and
+ * use the LR
+ */
+	str	lr, [sp, #-4]!		@ 1
+	mov	ip, r2			@ 1
+	mov	lr, r2			@ 1
+
+3:	subs	r1, r1, #64		@ 1 write 32 bytes out per loop
+	stmgeia	r0!, {r2, r3, ip, lr}	@ 4
+	stmgeia	r0!, {r2, r3, ip, lr}	@ 4
+	stmgeia	r0!, {r2, r3, ip, lr}	@ 4
+	stmgeia	r0!, {r2, r3, ip, lr}	@ 4
+	bgt	3b			@ 1
+	ldmeqfd	sp!, {pc}		@ 1/2 quick exit
+/*
+ * No need to correct the count; we're only testing bits from now on
+ */
+	tst	r1, #32			@ 1
+	stmneia	r0!, {r2, r3, ip, lr}	@ 4
+	stmneia	r0!, {r2, r3, ip, lr}	@ 4
+	tst	r1, #16			@ 1 16 bytes or more?
+	stmneia	r0!, {r2, r3, ip, lr}	@ 4
+	ldr	lr, [sp], #4		@ 1
+
+#else
+
+/*
+ * This version aligns the destination pointer in order to write
+ * whole cache lines at once.
+ */
+
+	stmfd	sp!, {r4-r7, lr}
+	mov	r4, r2
+	mov	r5, r2
+	mov	r6, r2
+	mov	r7, r2
+	mov	ip, r2
+	mov	lr, r2
+
+	cmp	r1, #96
+	andgts	ip, r0, #31
+	ble	3f
+
+	rsb	ip, ip, #32
+	sub	r1, r1, ip
+	movs	ip, ip, lsl #(32 - 4)
+	stmcsia	r0!, {r4, r5, r6, r7}
+	stmmiia	r0!, {r4, r5}
+	movs	ip, ip, lsl #2
+	strcs	r2, [r0], #4
+
+3:	subs	r1, r1, #64
+	stmgeia	r0!, {r2-r7, ip, lr}
+	stmgeia	r0!, {r2-r7, ip, lr}
+	bgt	3b
+	ldmeqfd	sp!, {r4-r7, pc}
+
+	tst	r1, #32
+	stmneia	r0!, {r2-r7, ip, lr}
+	tst	r1, #16
+	stmneia	r0!, {r4-r7}
+	ldmfd	sp!, {r4-r7, lr}
+
+#endif
+
+4:	tst	r1, #8			@ 1 8 bytes or more?
+	stmneia	r0!, {r2, r3}		@ 2
+	tst	r1, #4			@ 1 4 bytes or more?
+	strne	r2, [r0], #4		@ 1
+/*
+ * When we get here, we've got less than 4 bytes to zero.  We
+ * may have an unaligned pointer as well.
+ */
+5:	tst	r1, #2			@ 1 2 bytes or more?
+	strneb	r2, [r0], #1		@ 1
+	strneb	r2, [r0], #1		@ 1
+	tst	r1, #1			@ 1 a byte left over
+	strneb	r2, [r0], #1		@ 1
+	mov	pc, lr			@ 1
+ENDPROC(__memzero)
diff --git a/xen/arch/arm/lib/setbit.S b/xen/arch/arm/lib/setbit.S
new file mode 100644
index 0000000..c828851
--- /dev/null
+++ b/xen/arch/arm/lib/setbit.S
@@ -0,0 +1,18 @@
+/*
+ *  linux/arch/arm/lib/setbit.S
+ *
+ *  Copyright (C) 1995-1996 Russell King
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#include <xen/config.h>
+
+#include "assembler.h"
+#include "bitops.h"
+	.text
+
+ENTRY(_set_bit)
+	bitop	orr
+ENDPROC(_set_bit)
diff --git a/xen/arch/arm/lib/testchangebit.S b/xen/arch/arm/lib/testchangebit.S
new file mode 100644
index 0000000..a7f527c
--- /dev/null
+++ b/xen/arch/arm/lib/testchangebit.S
@@ -0,0 +1,18 @@
+/*
+ *  linux/arch/arm/lib/testchangebit.S
+ *
+ *  Copyright (C) 1995-1996 Russell King
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#include <xen/config.h>
+
+#include "assembler.h"
+#include "bitops.h"
+                .text
+
+ENTRY(_test_and_change_bit)
+	testop	eor, str
+ENDPROC(_test_and_change_bit)
diff --git a/xen/arch/arm/lib/testclearbit.S b/xen/arch/arm/lib/testclearbit.S
new file mode 100644
index 0000000..8f39c72
--- /dev/null
+++ b/xen/arch/arm/lib/testclearbit.S
@@ -0,0 +1,18 @@
+/*
+ *  linux/arch/arm/lib/testclearbit.S
+ *
+ *  Copyright (C) 1995-1996 Russell King
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#include <xen/config.h>
+
+#include "assembler.h"
+#include "bitops.h"
+                .text
+
+ENTRY(_test_and_clear_bit)
+	testop	bicne, strne
+ENDPROC(_test_and_clear_bit)
diff --git a/xen/arch/arm/lib/testsetbit.S b/xen/arch/arm/lib/testsetbit.S
new file mode 100644
index 0000000..1b8d273
--- /dev/null
+++ b/xen/arch/arm/lib/testsetbit.S
@@ -0,0 +1,18 @@
+/*
+ *  linux/arch/arm/lib/testsetbit.S
+ *
+ *  Copyright (C) 1995-1996 Russell King
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#include <xen/config.h>
+
+#include "assembler.h"
+#include "bitops.h"
+                .text
+
+ENTRY(_test_and_set_bit)
+	testop	orreq, streq
+ENDPROC(_test_and_set_bit)
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 13:14:35 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 13: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.xensource.com>)
	id 1RZ0HB-0002Ka-2V; Fri, 09 Dec 2011 13:14:09 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RZ0H8-0002IW-Uo
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 13:14:07 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1323436346!56653758!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDQ0MTg=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7559 invoked from network); 9 Dec 2011 13:12:35 -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 2011 13:12:35 -0000
X-IronPort-AV: E=Sophos;i="4.71,325,1320642000"; d="scan'208";a="19808900"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 08:13:21 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 08:13:21 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pB9DCpDv008248;
	Fri, 9 Dec 2011 05:13:09 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 9 Dec 2011 13:13:14 +0000
Message-ID: <1323436408-16335-11-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1112091208420.3517@kaball-desktop>
References: <alpine.DEB.2.00.1112091208420.3517@kaball-desktop>
MIME-Version: 1.0
Cc: keir.xen@gmail.com, Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, JBeulich@suse.com,
	Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v2 11/25] arm: entry.S and head.S
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Low level assembly routines, including entry.S and head.S.
Also the linker script and a collection of dummy functions that we plan
to reduce to zero as soon as possible.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
---
 xen/arch/arm/asm-offsets.c      |   76 ++++++++++
 xen/arch/arm/dummy.S            |   72 ++++++++++
 xen/arch/arm/entry.S            |  107 ++++++++++++++
 xen/arch/arm/head.S             |  298 +++++++++++++++++++++++++++++++++++++++
 xen/arch/arm/xen.lds.S          |  141 ++++++++++++++++++
 xen/include/asm-arm/asm_defns.h |   18 +++
 6 files changed, 712 insertions(+), 0 deletions(-)
 create mode 100644 xen/arch/arm/asm-offsets.c
 create mode 100644 xen/arch/arm/dummy.S
 create mode 100644 xen/arch/arm/entry.S
 create mode 100644 xen/arch/arm/head.S
 create mode 100644 xen/arch/arm/xen.lds.S
 create mode 100644 xen/include/asm-arm/asm_defns.h

diff --git a/xen/arch/arm/asm-offsets.c b/xen/arch/arm/asm-offsets.c
new file mode 100644
index 0000000..ee5d5d4
--- /dev/null
+++ b/xen/arch/arm/asm-offsets.c
@@ -0,0 +1,76 @@
+/*
+ * Generate definitions needed by assembly language modules.
+ * This code generates raw asm output which is post-processed
+ * to extract and format the required data.
+ */
+#define COMPILE_OFFSETS
+
+#include <xen/config.h>
+#include <xen/types.h>
+#include <public/xen.h>
+#include <asm/current.h>
+
+#define DEFINE(_sym, _val) \
+    __asm__ __volatile__ ( "\n->" #_sym " %0 " #_val : : "i" (_val) )
+#define BLANK() \
+    __asm__ __volatile__ ( "\n->" : : )
+#define OFFSET(_sym, _str, _mem) \
+    DEFINE(_sym, offsetof(_str, _mem));
+
+/* base-2 logarithm */
+#define __L2(_x)  (((_x) & 0x00000002) ?   1 : 0)
+#define __L4(_x)  (((_x) & 0x0000000c) ? ( 2 + __L2( (_x)>> 2)) : __L2( _x))
+#define __L8(_x)  (((_x) & 0x000000f0) ? ( 4 + __L4( (_x)>> 4)) : __L4( _x))
+#define __L16(_x) (((_x) & 0x0000ff00) ? ( 8 + __L8( (_x)>> 8)) : __L8( _x))
+#define LOG_2(_x) (((_x) & 0xffff0000) ? (16 + __L16((_x)>>16)) : __L16(_x))
+
+void __dummy__(void)
+{
+   OFFSET(UREGS_sp, struct cpu_user_regs, sp);
+   OFFSET(UREGS_lr, struct cpu_user_regs, lr);
+   OFFSET(UREGS_pc, struct cpu_user_regs, pc);
+   OFFSET(UREGS_cpsr, struct cpu_user_regs, cpsr);
+
+   OFFSET(UREGS_LR_usr, struct cpu_user_regs, lr_usr);
+   OFFSET(UREGS_SP_usr, struct cpu_user_regs, sp_usr);
+
+   OFFSET(UREGS_SP_svc, struct cpu_user_regs, sp_svc);
+   OFFSET(UREGS_LR_svc, struct cpu_user_regs, lr_svc);
+   OFFSET(UREGS_SPSR_svc, struct cpu_user_regs, spsr_svc);
+
+   OFFSET(UREGS_SP_abt, struct cpu_user_regs, sp_abt);
+   OFFSET(UREGS_LR_abt, struct cpu_user_regs, lr_abt);
+   OFFSET(UREGS_SPSR_abt, struct cpu_user_regs, spsr_abt);
+
+   OFFSET(UREGS_SP_und, struct cpu_user_regs, sp_und);
+   OFFSET(UREGS_LR_und, struct cpu_user_regs, lr_und);
+   OFFSET(UREGS_SPSR_und, struct cpu_user_regs, spsr_und);
+
+   OFFSET(UREGS_SP_irq, struct cpu_user_regs, sp_irq);
+   OFFSET(UREGS_LR_irq, struct cpu_user_regs, lr_irq);
+   OFFSET(UREGS_SPSR_irq, struct cpu_user_regs, spsr_irq);
+
+   OFFSET(UREGS_SP_fiq, struct cpu_user_regs, sp_fiq);
+   OFFSET(UREGS_LR_fiq, struct cpu_user_regs, lr_fiq);
+   OFFSET(UREGS_SPSR_fiq, struct cpu_user_regs, spsr_fiq);
+
+   OFFSET(UREGS_R8_fiq, struct cpu_user_regs, r8_fiq);
+   OFFSET(UREGS_R9_fiq, struct cpu_user_regs, r9_fiq);
+   OFFSET(UREGS_R10_fiq, struct cpu_user_regs, r10_fiq);
+   OFFSET(UREGS_R11_fiq, struct cpu_user_regs, r11_fiq);
+   OFFSET(UREGS_R12_fiq, struct cpu_user_regs, r12_fiq);
+
+   OFFSET(UREGS_kernel_sizeof, struct cpu_user_regs, cpsr);
+   DEFINE(UREGS_user_sizeof, sizeof(struct cpu_user_regs));
+   BLANK();
+
+   DEFINE(CPUINFO_sizeof, sizeof(struct cpu_info));
+}
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/arch/arm/dummy.S b/xen/arch/arm/dummy.S
new file mode 100644
index 0000000..5bc4f21
--- /dev/null
+++ b/xen/arch/arm/dummy.S
@@ -0,0 +1,72 @@
+/* Nothing is mapped at 1G, for the moment */
+#define DUMMY(x) \
+	.globl x; \
+x:	.word 0xe7f000f0
+/* x:	mov r0, #0x40000000 ; str r0, [r0]; b x */
+
+#define  NOP(x) \
+	.globl x; \
+x:	mov pc, lr
+	
+DUMMY(alloc_pirq_struct);
+DUMMY(alloc_vcpu_guest_context);
+DUMMY(arch_do_domctl);
+DUMMY(arch_do_sysctl);
+DUMMY(arch_do_vcpu_op);
+DUMMY(arch_get_info_guest);
+DUMMY(arch_get_xen_caps);
+DUMMY(arch_memory_op);
+DUMMY(arch_set_info_guest);
+DUMMY(arch_vcpu_reset);
+DUMMY(create_grant_host_mapping);
+DUMMY(__cpu_die);
+DUMMY(__cpu_disable);
+DUMMY(__cpu_up);
+DUMMY(do_get_pm_info);
+DUMMY(domain_get_maximum_gpfn);
+DUMMY(domain_relinquish_resources);
+DUMMY(domain_set_time_offset);
+DUMMY(dom_cow);
+DUMMY(donate_page);
+DUMMY(do_pm_op);
+DUMMY(flush_tlb_mask);
+DUMMY(free_vcpu_guest_context);
+DUMMY(get_page);
+DUMMY(get_page_type);
+DUMMY(gmfn_to_mfn);
+DUMMY(gnttab_clear_flag);
+DUMMY(gnttab_host_mapping_get_page_type);
+DUMMY(gnttab_mark_dirty);
+DUMMY(hypercall_create_continuation);
+DUMMY(iommu_map_page);
+DUMMY(iommu_unmap_page);
+DUMMY(is_iomem_page);
+DUMMY(local_event_delivery_enable);
+DUMMY(local_events_need_delivery);
+DUMMY(machine_to_phys_mapping_valid);
+DUMMY(max_page);
+DUMMY(node_online_map);
+DUMMY(nr_irqs_gsi);
+DUMMY(p2m_pod_decrease_reservation);
+DUMMY(guest_physmap_mark_populate_on_demand);
+DUMMY(page_get_owner_and_reference);
+DUMMY(page_is_ram_type);
+DUMMY(per_cpu__cpu_core_mask);
+DUMMY(per_cpu__cpu_sibling_mask);
+DUMMY(__per_cpu_offset);
+DUMMY(pirq_guest_bind);
+DUMMY(pirq_guest_unbind);
+DUMMY(pirq_set_affinity);
+DUMMY(put_page);
+DUMMY(put_page_type);
+DUMMY(replace_grant_host_mapping);
+DUMMY(send_timer_event);
+DUMMY(share_xen_page_with_privileged_guests);
+DUMMY(smp_send_state_dump);
+DUMMY(steal_page);
+DUMMY(sync_vcpu_execstate);
+DUMMY(__udelay);
+NOP(update_vcpu_system_time);
+DUMMY(vcpu_mark_events_pending);
+DUMMY(vcpu_show_execution_state);
+DUMMY(wallclock_time);
diff --git a/xen/arch/arm/entry.S b/xen/arch/arm/entry.S
new file mode 100644
index 0000000..16a8f36
--- /dev/null
+++ b/xen/arch/arm/entry.S
@@ -0,0 +1,107 @@
+#include <xen/config.h>
+#include <asm/asm_defns.h>
+
+#define SAVE_ONE_BANKED(reg)	mrs r11, reg; str r11, [sp, #UREGS_##reg]
+#define RESTORE_ONE_BANKED(reg)	ldr r11, [sp, #UREGS_##reg]; msr reg, r11
+
+#define SAVE_BANKED(mode) \
+	SAVE_ONE_BANKED(SP_##mode) ; SAVE_ONE_BANKED(LR_##mode) ; SAVE_ONE_BANKED(SPSR_##mode)
+
+#define RESTORE_BANKED(mode) \
+	RESTORE_ONE_BANKED(SP_##mode) ; RESTORE_ONE_BANKED(LR_##mode) ; RESTORE_ONE_BANKED(SPSR_##mode)
+
+#define SAVE_ALL											\
+	sub sp, #(UREGS_R8_fiq - UREGS_sp); /* SP, LR, SPSR, PC */					\
+	push {r0-r12}; /* Save R0-R12 */								\
+													\
+	mrs r11, ELR_hyp;		/* ELR_hyp is return address. */				\
+	str r11, [sp, #UREGS_pc];									\
+													\
+	str lr, [sp, #UREGS_lr];									\
+													\
+	add r11, sp, #UREGS_kernel_sizeof+4;								\
+	str r11, [sp, #UREGS_sp];									\
+													\
+	mrs r11, SPSR_hyp;										\
+	str r11, [sp, #UREGS_cpsr];									\
+	and r11, #PSR_MODE_MASK;									\
+	cmp r11, #PSR_MODE_HYP;										\
+	blne save_guest_regs
+
+save_guest_regs:
+	ldr r11, [sp, #UREGS_lr]
+	str r11, [sp, #UREGS_LR_usr]
+	ldr r11, =0xffffffff  /* Clobber SP which is only valid for hypervisor frames. */
+	str r11, [sp, #UREGS_sp]
+	SAVE_ONE_BANKED(SP_usr)
+	SAVE_BANKED(svc)
+	SAVE_BANKED(abt)
+	SAVE_BANKED(und)
+	SAVE_BANKED(irq)
+	SAVE_BANKED(fiq)
+	SAVE_ONE_BANKED(R8_fiq); SAVE_ONE_BANKED(R9_fiq); SAVE_ONE_BANKED(R10_fiq)
+	SAVE_ONE_BANKED(R11_fiq); SAVE_ONE_BANKED(R12_fiq);
+	mov pc, lr
+
+#define DEFINE_TRAP_ENTRY(trap)										\
+	ALIGN;												\
+trap_##trap:												\
+	SAVE_ALL;											\
+	adr lr, return_from_trap;									\
+	mov r0, sp;											\
+	mov r11, sp;											\
+	bic sp, #7; /* Align the stack pointer (noop on guest trap) */					\
+	b do_trap_##trap
+
+.globl hyp_traps_vector
+	.align 5
+hyp_traps_vector:
+	.word 0				/* 0x00 - Reset */
+	b trap_undefined_instruction	/* 0x04 - Undefined Instruction */
+	b trap_supervisor_call		/* 0x08 - Supervisor Call */
+	b trap_prefetch_abort		/* 0x0c - Prefetch Abort */
+	b trap_data_abort		/* 0x10 - Data Abort */
+	b trap_hypervisor		/* 0x14 - Hypervisor */
+	b trap_irq			/* 0x18 - IRQ */
+	b trap_fiq			/* 0x1c - FIQ */
+
+DEFINE_TRAP_ENTRY(undefined_instruction)
+DEFINE_TRAP_ENTRY(supervisor_call)
+DEFINE_TRAP_ENTRY(prefetch_abort)
+DEFINE_TRAP_ENTRY(data_abort)
+DEFINE_TRAP_ENTRY(hypervisor)
+DEFINE_TRAP_ENTRY(irq)
+DEFINE_TRAP_ENTRY(fiq)
+
+ENTRY(return_from_trap)
+	ldr r11, [sp, #UREGS_cpsr]
+	and r11, #PSR_MODE_MASK
+	cmp r11, #PSR_MODE_HYP
+	beq return_to_hypervisor
+
+ENTRY(return_to_guest)
+	mov r11, sp
+	bic sp, #7 /* Align the stack pointer */
+	bl leave_hypervisor_tail
+	ldr r11, [sp, #UREGS_pc]
+	msr ELR_hyp, r11
+	ldr r11, [sp, #UREGS_cpsr]
+	msr SPSR_hyp, r11
+	RESTORE_ONE_BANKED(SP_usr)
+	RESTORE_BANKED(svc)
+	RESTORE_BANKED(abt)
+	RESTORE_BANKED(und)
+	RESTORE_BANKED(irq)
+	RESTORE_BANKED(fiq)
+	RESTORE_ONE_BANKED(R8_fiq); RESTORE_ONE_BANKED(R9_fiq); RESTORE_ONE_BANKED(R10_fiq)
+	RESTORE_ONE_BANKED(R11_fiq); RESTORE_ONE_BANKED(R12_fiq);
+	ldr lr, [sp, #UREGS_LR_usr]
+	pop {r0-r12}
+	add sp, #(UREGS_R8_fiq - UREGS_sp); /* SP, LR, SPSR, PC */
+	eret
+
+ENTRY(return_to_hypervisor)
+	ldr lr, [sp, #UREGS_lr]
+	pop {r0-r12}
+	add sp, #(UREGS_R8_fiq - UREGS_sp); /* SP, LR, SPSR, PC */
+	eret
diff --git a/xen/arch/arm/head.S b/xen/arch/arm/head.S
new file mode 100644
index 0000000..b98c921
--- /dev/null
+++ b/xen/arch/arm/head.S
@@ -0,0 +1,298 @@
+/*
+ * xen/arch/arm/head.S
+ *
+ * Start-of-day code for an ARMv7-A with virt extensions.
+ *
+ * Tim Deegan <tim@xen.org>
+ * Copyright (c) 2011 Citrix Systems.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include <asm/config.h>
+#include <asm/page.h>
+#include <asm/asm_defns.h>
+
+
+/* Macro to print a string to the UART, if there is one.
+ * Clobbers r0-r3. */
+#ifdef EARLY_UART_ADDRESS
+#define PRINT(_s)       \
+	adr   r0, 98f ; \
+	bl    puts    ; \
+	b     99f     ; \
+98:	.asciz _s     ; \
+	.align 2      ; \
+99:
+#else
+#define PRINT(s)
+#endif
+
+	.arm
+
+	/* This must be the very first address in the loaded image.
+	 * It should be linked at XEN_VIRT_START, and loaded at any
+	 * 2MB-aligned address.  All of text+data+bss must fit in 2MB,
+	 * or the initial pagetable code below will need adjustment. */
+	.global start
+start:
+	cpsid aif                    /* Disable all interrupts */
+
+	/* Save the bootloader arguments in less-clobberable registers */
+	mov   r7, r1                 /* r7 := ARM-linux machine type */
+	mov   r8, r2                 /* r8 := ATAG base address */
+
+	/* Find out where we are */
+	ldr   r0, =start
+	adr   r9, start              /* r9  := paddr (start) */
+	sub   r10, r9, r0            /* r10 := phys-offset */
+
+#ifdef EARLY_UART_ADDRESS
+	/* Say hello */
+	ldr   r11, =EARLY_UART_ADDRESS  /* r11 := UART base address */
+	bl    init_uart
+#endif
+
+	/* Check that this CPU has Hyp mode */
+	mrc   CP32(r0, ID_PFR1)
+	and   r0, r0, #0xf000        /* Bits 12-15 define virt extensions */
+	teq   r0, #0x1000            /* Must == 0x1 or may be incompatible */
+	beq   1f
+	bl    putn
+	PRINT("- CPU doesn't support the virtualization extensions -\r\n")
+	b     fail
+1:
+	/* Check if we're already in it */
+	mrs   r0, cpsr
+	and   r0, r0, #0x1f          /* Mode is in the low 5 bits of CPSR */
+	teq   r0, #0x1a              /* Hyp Mode? */
+	bne   1f
+	PRINT("- Started in Hyp mode -\r\n")
+	b     hyp
+1:
+	/* Otherwise, it must have been Secure Supervisor mode */
+	mrc   CP32(r0, SCR)
+	tst   r0, #0x1               /* Not-Secure bit set? */
+	beq   1f
+	PRINT("- CPU is not in Hyp mode or Secure state -\r\n")
+	b     fail
+1:
+	/* OK, we're in Secure state. */
+	PRINT("- Started in Secure state -\r\n- Entering Hyp mode -\r\n")
+
+	/* Dance into Hyp mode */
+	cpsid aif, #0x16             /* Enter Monitor mode */
+	mrc   CP32(r0, SCR)
+	orr   r0, r0, #0x100         /* Set HCE */
+	orr   r0, r0, #0xb1          /* Set SCD, AW, FW and NS */
+	bic   r0, r0, #0xe           /* Clear EA, FIQ and IRQ */
+	mcr   CP32(r0, SCR)
+	/* Ugly: the system timer's frequency register is only
+	 * programmable in Secure state.  Since we don't know where its
+	 * memory-mapped control registers live, we can't find out the
+	 * right frequency.  Use the VE model's default frequency here. */
+	ldr   r0, =0x5f5e100         /* 100 MHz */
+	mcr   CP32(r0, CNTFRQ)
+	ldr   r0, =0x40c00           /* SMP, c11, c10 in non-secure mode */
+	mcr   CP32(r0, NSACR)
+	/* Continuing ugliness: Set up the GIC so NS state owns interrupts */
+	mov   r0, #GIC_BASE_ADDRESS
+	add   r0, r0, #GIC_DR_OFFSET
+	mov   r1, #0
+	str   r1, [r0]               /* Disable delivery in the distributor */
+	add   r0, r0, #0x80          /* GICD_IGROUP0 */
+	mov   r2, #0xffffffff        /* All interrupts to group 1 */
+	str   r2, [r0]
+	str   r2, [r0, #4]
+	str   r2, [r0, #8]
+	/* Must drop priority mask below 0x80 before entering NS state */
+	mov   r0, #GIC_BASE_ADDRESS
+	add   r0, r0, #GIC_CR_OFFSET
+	ldr   r1, =0xff
+	str   r1, [r0, #0x4]         /* -> GICC_PMR */
+	/* Reset a few config registers */
+	mov   r0, #0
+	mcr   CP32(r0, FCSEIDR)
+	mcr   CP32(r0, CONTEXTIDR)
+	/* FIXME: ought to reset some other NS control regs here */
+	adr   r1, 1f
+	adr   r0, hyp                /* Store paddr (hyp entry point) */
+	str   r0, [r1]               /* where we can use it for RFE */
+	isb                          /* Ensure we see the stored target address */
+	rfeia r1                     /* Enter Hyp mode */
+
+1:	.word 0                      /* PC to enter Hyp mode at */
+	.word 0x000001da             /* CPSR: LE, Abort/IRQ/FIQ off, Hyp */
+
+hyp:
+	PRINT("- Setting up control registers -\r\n")
+
+	/* Set up memory attribute type tables */
+	ldr   r0, =MAIR0VAL
+	ldr   r1, =MAIR1VAL
+	mcr   CP32(r0, MAIR0)
+	mcr   CP32(r1, MAIR1)
+	mcr   CP32(r0, HMAIR0)
+	mcr   CP32(r1, HMAIR1)
+
+	/* Set up the HTCR:
+	 * PT walks use Outer-Shareable accesses,
+	 * PT walks are write-back, no-write-allocate in both cache levels,
+	 * Full 32-bit address space goes through this table. */
+	ldr   r0, =0x80002500
+	mcr   CP32(r0, HTCR)
+
+	/* Set up the HSCTLR:
+	 * Exceptions in LE ARM,
+	 * Low-latency IRQs disabled,
+	 * Write-implies-XN disabled (for now),
+	 * I-cache and d-cache enabled,
+	 * Alignment checking enabled,
+	 * MMU translation disabled (for now). */
+	ldr   r0, =(HSCTLR_BASE|SCTLR_A|SCTLR_C)
+	mcr   CP32(r0, HSCTLR)
+
+	/* Write Xen's PT's paddr into the HTTBR */
+	ldr   r4, =xen_pgtable
+	add   r4, r4, r10            /* r4 := paddr (xen_pagetable) */
+	mov   r5, #0                 /* r4:r5 is paddr (xen_pagetable) */
+	mcrr  CP64(r4, r5, HTTBR)
+
+	/* Build the baseline idle pagetable's first-level entries */
+	ldr   r1, =xen_second
+	add   r1, r1, r10            /* r1 := paddr (xen_second) */
+	mov   r3, #0x0
+	orr   r2, r1, #0xe00         /* r2:r3 := table map of xen_second */
+	orr   r2, r2, #0x07f         /* (+ rights for linear PT) */
+	strd  r2, r3, [r4, #0]       /* Map it in slot 0 */
+	add   r2, r2, #0x1000
+	strd  r2, r3, [r4, #8]       /* Map 2nd page in slot 1 */
+	add   r2, r2, #0x1000
+	strd  r2, r3, [r4, #16]      /* Map 3rd page in slot 2 */
+	add   r2, r2, #0x1000
+	strd  r2, r3, [r4, #24]      /* Map 4th page in slot 3 */
+
+	/* Now set up the second-level entries */
+	orr   r2, r9, #0xe00
+	orr   r2, r2, #0x07d         /* r2:r3 := 2MB normal map of Xen */
+	mov   r4, r9, lsr #18        /* Slot for paddr(start) */
+	strd  r2, r3, [r1, r4]       /* Map Xen there */
+	ldr   r4, =start
+	lsr   r4, #18                /* Slot for vaddr(start) */
+	strd  r2, r3, [r1, r4]       /* Map Xen there too */
+#ifdef EARLY_UART_ADDRESS
+	ldr   r3, =(1<<(54-32))      /* NS for device mapping */
+	lsr   r2, r11, #21
+	lsl   r2, r2, #21            /* 2MB-aligned paddr of UART */
+	orr   r2, r2, #0xe00
+	orr   r2, r2, #0x071         /* r2:r3 := 2MB dev map including UART */
+	add   r4, r4, #8
+	strd  r2, r3, [r1, r4]       /* Map it in the fixmap's slot */
+#endif
+
+	PRINT("- Turning on paging -\r\n")
+
+	ldr   r1, =paging            /* Explicit vaddr, not RIP-relative */
+	mrc   CP32(r0, HSCTLR)
+	orr   r0, r0, #0x1           /* Add in the MMU enable bit */
+	dsb                          /* Flush PTE writes and finish reads */
+	mcr   CP32(r0, HSCTLR)       /* now paging is enabled */
+	isb                          /* Now, flush the icache */
+	mov   pc, r1                 /* Get a proper vaddr into PC */
+paging:
+
+#ifdef EARLY_UART_ADDRESS
+	/* Recover the UART address in the new address space */
+	lsl   r11, #11
+	lsr   r11, #11               /* UART base's offset from 2MB base */
+	adr   r0, start
+	add   r0, r0, #0x200000      /* vaddr of the fixmap's 2MB slot */
+	add   r11, r11, r0           /* r11 := vaddr (UART base address) */
+#endif
+
+	PRINT("- Entering C -\r\n")
+
+	ldr   sp, =init_stack        /* Supply a stack */
+	add   sp, #STACK_SIZE        /* (which grows down from the top). */
+	sub   sp, #CPUINFO_sizeof    /* Make room for CPU save record */
+	mov   r0, r10                /* Marshal args: - phys_offset */
+	mov   r1, r7                 /*               - machine type */
+	mov   r2, r8                 /*               - ATAG address */
+	b     start_xen              /* and disappear into the land of C */
+
+/* Fail-stop
+ * r0: string explaining why */
+fail:	PRINT("- Boot failed -\r\n")
+1:	wfe
+	b     1b
+
+#ifdef EARLY_UART_ADDRESS
+
+/* Bring up the UART. Specific to the PL011 UART.
+ * Clobbers r0-r2 */
+init_uart:
+	mov   r1, #0x0
+	str   r1, [r11, #0x24]       /* -> UARTIBRD (Baud divisor fraction) */
+	mov   r1, #0x4               /* 7.3728MHz / 0x4 == 16 * 115200 */
+	str   r1, [r11, #0x24]       /* -> UARTIBRD (Baud divisor integer) */
+	mov   r1, #0x60              /* 8n1 */
+	str   r1, [r11, #0x24]       /* -> UARTLCR_H (Line control) */
+	ldr   r1, =0x00000301        /* RXE | TXE | UARTEN */
+	str   r1, [r11, #0x30]       /* -> UARTCR (Control Register) */
+	adr   r0, 1f
+	b     puts
+1:	.asciz "- UART enabled -\r\n"
+	.align 4
+
+/* Print early debug messages.  Specific to the PL011 UART.
+ * r0: Nul-terminated string to print.
+ * Clobbers r0-r2 */
+puts:
+	ldr   r2, [r11, #0x18]       /* <- UARTFR (Flag register) */
+	tst   r2, #0x8               /* Check BUSY bit */
+	bne   puts                   /* Wait for the UART to be ready */
+	ldrb  r2, [r0], #1           /* Load next char */
+	teq   r2, #0                 /* Exit on nul*/
+	moveq pc, lr
+	str   r2, [r11]              /* -> UARTDR (Data Register) */
+	b     puts
+
+/* Print a 32-bit number in hex.  Specific to the PL011 UART.
+ * r0: Number to print.
+ * clobbers r0-r3 */
+putn:
+	adr   r1, hex
+	mov   r3, #8
+1:	ldr   r2, [r11, #0x18]       /* <- UARTFR (Flag register) */
+	tst   r2, #0x8               /* Check BUSY bit */
+	bne   1b                     /* Wait for the UART to be ready */
+	and   r2, r0, #0xf0000000    /* Mask off the top nybble */
+	ldrb  r2, [r1, r2, lsr #28]  /* Convert to a char */
+	str   r2, [r11]              /* -> UARTDR (Data Register) */
+	lsl   r0, #4                 /* Roll it through one nybble at a time */
+	subs  r3, r3, #1
+	bne   1b
+	adr   r0, crlf               /* Finish with a newline */
+	b     puts
+
+crlf:	.asciz "\r\n"
+hex:	.ascii "0123456789abcdef"
+	.align 2
+
+#else  /* EARLY_UART_ADDRESS */
+
+init_uart:
+.global early_puts
+early_puts:
+puts:
+putn:	mov   pc, lr
+
+#endif /* EARLY_UART_ADDRESS */
diff --git a/xen/arch/arm/xen.lds.S b/xen/arch/arm/xen.lds.S
new file mode 100644
index 0000000..5a62e2c
--- /dev/null
+++ b/xen/arch/arm/xen.lds.S
@@ -0,0 +1,141 @@
+/* Excerpts written by Martin Mares <mj@atrey.karlin.mff.cuni.cz> */
+/* Modified for i386/x86-64 Xen by Keir Fraser */
+/* Modified for ARM Xen by Ian Campbell */
+
+#include <xen/config.h>
+#include <xen/cache.h>
+#include <asm/page.h>
+#include <asm/percpu.h>
+#undef ENTRY
+#undef ALIGN
+
+ENTRY(start)
+
+OUTPUT_ARCH(arm)
+
+PHDRS
+{
+  text PT_LOAD /* XXX should be AT ( XEN_PHYS_START ) */ ;
+}
+SECTIONS
+{
+  . = XEN_VIRT_START;
+  _start = .;
+  .text : /* XXX should be AT ( XEN_PHYS_START ) */ {
+        _stext = .;            /* Text section */
+       *(.text)
+       *(.fixup)
+       *(.gnu.warning)
+       _etext = .;             /* End of text section */
+  } :text = 0x9090
+
+  . = ALIGN(PAGE_SIZE);
+  .rodata : {
+        _srodata = .;          /* Read-only data */
+       *(.rodata)
+       *(.rodata.*)
+        _erodata = .;          /* End of read-only data */
+  } :text
+
+  .data : {                    /* Data */
+       . = ALIGN(PAGE_SIZE);
+       *(.data.page_aligned)
+       *(.data)
+       *(.data.rel)
+       *(.data.rel.*)
+       CONSTRUCTORS
+  } :text
+
+  . = ALIGN(SMP_CACHE_BYTES);
+  .data.read_mostly : {
+       /* Exception table */
+       __start___ex_table = .;
+       *(.ex_table)
+       __stop___ex_table = .;
+
+       /* Pre-exception table */
+       __start___pre_ex_table = .;
+       *(.ex_table.pre)
+       __stop___pre_ex_table = .;
+
+       *(.data.read_mostly)
+       *(.data.rel.ro)
+       *(.data.rel.ro.*)
+  } :text
+
+#ifdef LOCK_PROFILE
+  . = ALIGN(32);
+  __lock_profile_start = .;
+  .lockprofile.data : { *(.lockprofile.data) } :text
+  __lock_profile_end = .;
+#endif
+
+  . = ALIGN(PAGE_SIZE);             /* Init code and data */
+  __init_begin = .;
+  .init.text : {
+       _sinittext = .;
+       *(.init.text)
+       _einittext = .;
+  } :text
+  . = ALIGN(PAGE_SIZE);
+  .init.data : {
+       *(.init.rodata)
+       *(.init.rodata.str*)
+       *(.init.data)
+       *(.init.data.rel)
+       *(.init.data.rel.*)
+  } :text
+  . = ALIGN(32);
+  .init.setup : {
+       __setup_start = .;
+       *(.init.setup)
+       __setup_end = .;
+  } :text
+  .initcall.init : {
+       __initcall_start = .;
+       *(.initcallpresmp.init)
+       __presmp_initcall_end = .;
+       *(.initcall1.init)
+       __initcall_end = .;
+  } :text
+  .xsm_initcall.init : {
+       __xsm_initcall_start = .;
+       *(.xsm_initcall.init)
+       __xsm_initcall_end = .;
+  } :text
+  . = ALIGN(STACK_SIZE);
+  __init_end = .;
+
+  .bss : {                     /* BSS */
+       __bss_start = .;
+       *(.bss.stack_aligned)
+       . = ALIGN(PAGE_SIZE);
+       *(.bss.page_aligned)
+       *(.bss)
+       . = ALIGN(SMP_CACHE_BYTES);
+       __per_cpu_start = .;
+       *(.bss.percpu)
+       . = ALIGN(SMP_CACHE_BYTES);
+       *(.bss.percpu.read_mostly)
+       . = ALIGN(SMP_CACHE_BYTES);
+       __per_cpu_data_end = .;
+  } :text
+  _end = . ;
+
+  /* Sections to be discarded */
+  /DISCARD/ : {
+       *(.exit.text)
+       *(.exit.data)
+       *(.exitcall.exit)
+       *(.eh_frame)
+  }
+
+  /* Stabs debugging sections.  */
+  .stab 0 : { *(.stab) }
+  .stabstr 0 : { *(.stabstr) }
+  .stab.excl 0 : { *(.stab.excl) }
+  .stab.exclstr 0 : { *(.stab.exclstr) }
+  .stab.index 0 : { *(.stab.index) }
+  .stab.indexstr 0 : { *(.stab.indexstr) }
+  .comment 0 : { *(.comment) }
+}
diff --git a/xen/include/asm-arm/asm_defns.h b/xen/include/asm-arm/asm_defns.h
new file mode 100644
index 0000000..c59fb6c
--- /dev/null
+++ b/xen/include/asm-arm/asm_defns.h
@@ -0,0 +1,18 @@
+#ifndef __ARM_ASM_DEFNS_H__
+#define __ARM_ASM_DEFNS_H__
+
+#ifndef COMPILE_OFFSETS
+/* NB. Auto-generated from arch/.../asm-offsets.c */
+#include <asm/asm-offsets.h>
+#endif
+#include <asm/processor.h>
+
+#endif /* __ARM_ASM_DEFNS_H__ */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 13:14:35 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 13: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.xensource.com>)
	id 1RZ0HB-0002Ka-2V; Fri, 09 Dec 2011 13:14:09 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RZ0H8-0002IW-Uo
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 13:14:07 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1323436346!56653758!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDQ0MTg=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7559 invoked from network); 9 Dec 2011 13:12:35 -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 2011 13:12:35 -0000
X-IronPort-AV: E=Sophos;i="4.71,325,1320642000"; d="scan'208";a="19808900"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 08:13:21 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 08:13:21 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pB9DCpDv008248;
	Fri, 9 Dec 2011 05:13:09 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 9 Dec 2011 13:13:14 +0000
Message-ID: <1323436408-16335-11-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1112091208420.3517@kaball-desktop>
References: <alpine.DEB.2.00.1112091208420.3517@kaball-desktop>
MIME-Version: 1.0
Cc: keir.xen@gmail.com, Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, JBeulich@suse.com,
	Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v2 11/25] arm: entry.S and head.S
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Low level assembly routines, including entry.S and head.S.
Also the linker script and a collection of dummy functions that we plan
to reduce to zero as soon as possible.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
---
 xen/arch/arm/asm-offsets.c      |   76 ++++++++++
 xen/arch/arm/dummy.S            |   72 ++++++++++
 xen/arch/arm/entry.S            |  107 ++++++++++++++
 xen/arch/arm/head.S             |  298 +++++++++++++++++++++++++++++++++++++++
 xen/arch/arm/xen.lds.S          |  141 ++++++++++++++++++
 xen/include/asm-arm/asm_defns.h |   18 +++
 6 files changed, 712 insertions(+), 0 deletions(-)
 create mode 100644 xen/arch/arm/asm-offsets.c
 create mode 100644 xen/arch/arm/dummy.S
 create mode 100644 xen/arch/arm/entry.S
 create mode 100644 xen/arch/arm/head.S
 create mode 100644 xen/arch/arm/xen.lds.S
 create mode 100644 xen/include/asm-arm/asm_defns.h

diff --git a/xen/arch/arm/asm-offsets.c b/xen/arch/arm/asm-offsets.c
new file mode 100644
index 0000000..ee5d5d4
--- /dev/null
+++ b/xen/arch/arm/asm-offsets.c
@@ -0,0 +1,76 @@
+/*
+ * Generate definitions needed by assembly language modules.
+ * This code generates raw asm output which is post-processed
+ * to extract and format the required data.
+ */
+#define COMPILE_OFFSETS
+
+#include <xen/config.h>
+#include <xen/types.h>
+#include <public/xen.h>
+#include <asm/current.h>
+
+#define DEFINE(_sym, _val) \
+    __asm__ __volatile__ ( "\n->" #_sym " %0 " #_val : : "i" (_val) )
+#define BLANK() \
+    __asm__ __volatile__ ( "\n->" : : )
+#define OFFSET(_sym, _str, _mem) \
+    DEFINE(_sym, offsetof(_str, _mem));
+
+/* base-2 logarithm */
+#define __L2(_x)  (((_x) & 0x00000002) ?   1 : 0)
+#define __L4(_x)  (((_x) & 0x0000000c) ? ( 2 + __L2( (_x)>> 2)) : __L2( _x))
+#define __L8(_x)  (((_x) & 0x000000f0) ? ( 4 + __L4( (_x)>> 4)) : __L4( _x))
+#define __L16(_x) (((_x) & 0x0000ff00) ? ( 8 + __L8( (_x)>> 8)) : __L8( _x))
+#define LOG_2(_x) (((_x) & 0xffff0000) ? (16 + __L16((_x)>>16)) : __L16(_x))
+
+void __dummy__(void)
+{
+   OFFSET(UREGS_sp, struct cpu_user_regs, sp);
+   OFFSET(UREGS_lr, struct cpu_user_regs, lr);
+   OFFSET(UREGS_pc, struct cpu_user_regs, pc);
+   OFFSET(UREGS_cpsr, struct cpu_user_regs, cpsr);
+
+   OFFSET(UREGS_LR_usr, struct cpu_user_regs, lr_usr);
+   OFFSET(UREGS_SP_usr, struct cpu_user_regs, sp_usr);
+
+   OFFSET(UREGS_SP_svc, struct cpu_user_regs, sp_svc);
+   OFFSET(UREGS_LR_svc, struct cpu_user_regs, lr_svc);
+   OFFSET(UREGS_SPSR_svc, struct cpu_user_regs, spsr_svc);
+
+   OFFSET(UREGS_SP_abt, struct cpu_user_regs, sp_abt);
+   OFFSET(UREGS_LR_abt, struct cpu_user_regs, lr_abt);
+   OFFSET(UREGS_SPSR_abt, struct cpu_user_regs, spsr_abt);
+
+   OFFSET(UREGS_SP_und, struct cpu_user_regs, sp_und);
+   OFFSET(UREGS_LR_und, struct cpu_user_regs, lr_und);
+   OFFSET(UREGS_SPSR_und, struct cpu_user_regs, spsr_und);
+
+   OFFSET(UREGS_SP_irq, struct cpu_user_regs, sp_irq);
+   OFFSET(UREGS_LR_irq, struct cpu_user_regs, lr_irq);
+   OFFSET(UREGS_SPSR_irq, struct cpu_user_regs, spsr_irq);
+
+   OFFSET(UREGS_SP_fiq, struct cpu_user_regs, sp_fiq);
+   OFFSET(UREGS_LR_fiq, struct cpu_user_regs, lr_fiq);
+   OFFSET(UREGS_SPSR_fiq, struct cpu_user_regs, spsr_fiq);
+
+   OFFSET(UREGS_R8_fiq, struct cpu_user_regs, r8_fiq);
+   OFFSET(UREGS_R9_fiq, struct cpu_user_regs, r9_fiq);
+   OFFSET(UREGS_R10_fiq, struct cpu_user_regs, r10_fiq);
+   OFFSET(UREGS_R11_fiq, struct cpu_user_regs, r11_fiq);
+   OFFSET(UREGS_R12_fiq, struct cpu_user_regs, r12_fiq);
+
+   OFFSET(UREGS_kernel_sizeof, struct cpu_user_regs, cpsr);
+   DEFINE(UREGS_user_sizeof, sizeof(struct cpu_user_regs));
+   BLANK();
+
+   DEFINE(CPUINFO_sizeof, sizeof(struct cpu_info));
+}
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/arch/arm/dummy.S b/xen/arch/arm/dummy.S
new file mode 100644
index 0000000..5bc4f21
--- /dev/null
+++ b/xen/arch/arm/dummy.S
@@ -0,0 +1,72 @@
+/* Nothing is mapped at 1G, for the moment */
+#define DUMMY(x) \
+	.globl x; \
+x:	.word 0xe7f000f0
+/* x:	mov r0, #0x40000000 ; str r0, [r0]; b x */
+
+#define  NOP(x) \
+	.globl x; \
+x:	mov pc, lr
+	
+DUMMY(alloc_pirq_struct);
+DUMMY(alloc_vcpu_guest_context);
+DUMMY(arch_do_domctl);
+DUMMY(arch_do_sysctl);
+DUMMY(arch_do_vcpu_op);
+DUMMY(arch_get_info_guest);
+DUMMY(arch_get_xen_caps);
+DUMMY(arch_memory_op);
+DUMMY(arch_set_info_guest);
+DUMMY(arch_vcpu_reset);
+DUMMY(create_grant_host_mapping);
+DUMMY(__cpu_die);
+DUMMY(__cpu_disable);
+DUMMY(__cpu_up);
+DUMMY(do_get_pm_info);
+DUMMY(domain_get_maximum_gpfn);
+DUMMY(domain_relinquish_resources);
+DUMMY(domain_set_time_offset);
+DUMMY(dom_cow);
+DUMMY(donate_page);
+DUMMY(do_pm_op);
+DUMMY(flush_tlb_mask);
+DUMMY(free_vcpu_guest_context);
+DUMMY(get_page);
+DUMMY(get_page_type);
+DUMMY(gmfn_to_mfn);
+DUMMY(gnttab_clear_flag);
+DUMMY(gnttab_host_mapping_get_page_type);
+DUMMY(gnttab_mark_dirty);
+DUMMY(hypercall_create_continuation);
+DUMMY(iommu_map_page);
+DUMMY(iommu_unmap_page);
+DUMMY(is_iomem_page);
+DUMMY(local_event_delivery_enable);
+DUMMY(local_events_need_delivery);
+DUMMY(machine_to_phys_mapping_valid);
+DUMMY(max_page);
+DUMMY(node_online_map);
+DUMMY(nr_irqs_gsi);
+DUMMY(p2m_pod_decrease_reservation);
+DUMMY(guest_physmap_mark_populate_on_demand);
+DUMMY(page_get_owner_and_reference);
+DUMMY(page_is_ram_type);
+DUMMY(per_cpu__cpu_core_mask);
+DUMMY(per_cpu__cpu_sibling_mask);
+DUMMY(__per_cpu_offset);
+DUMMY(pirq_guest_bind);
+DUMMY(pirq_guest_unbind);
+DUMMY(pirq_set_affinity);
+DUMMY(put_page);
+DUMMY(put_page_type);
+DUMMY(replace_grant_host_mapping);
+DUMMY(send_timer_event);
+DUMMY(share_xen_page_with_privileged_guests);
+DUMMY(smp_send_state_dump);
+DUMMY(steal_page);
+DUMMY(sync_vcpu_execstate);
+DUMMY(__udelay);
+NOP(update_vcpu_system_time);
+DUMMY(vcpu_mark_events_pending);
+DUMMY(vcpu_show_execution_state);
+DUMMY(wallclock_time);
diff --git a/xen/arch/arm/entry.S b/xen/arch/arm/entry.S
new file mode 100644
index 0000000..16a8f36
--- /dev/null
+++ b/xen/arch/arm/entry.S
@@ -0,0 +1,107 @@
+#include <xen/config.h>
+#include <asm/asm_defns.h>
+
+#define SAVE_ONE_BANKED(reg)	mrs r11, reg; str r11, [sp, #UREGS_##reg]
+#define RESTORE_ONE_BANKED(reg)	ldr r11, [sp, #UREGS_##reg]; msr reg, r11
+
+#define SAVE_BANKED(mode) \
+	SAVE_ONE_BANKED(SP_##mode) ; SAVE_ONE_BANKED(LR_##mode) ; SAVE_ONE_BANKED(SPSR_##mode)
+
+#define RESTORE_BANKED(mode) \
+	RESTORE_ONE_BANKED(SP_##mode) ; RESTORE_ONE_BANKED(LR_##mode) ; RESTORE_ONE_BANKED(SPSR_##mode)
+
+#define SAVE_ALL											\
+	sub sp, #(UREGS_R8_fiq - UREGS_sp); /* SP, LR, SPSR, PC */					\
+	push {r0-r12}; /* Save R0-R12 */								\
+													\
+	mrs r11, ELR_hyp;		/* ELR_hyp is return address. */				\
+	str r11, [sp, #UREGS_pc];									\
+													\
+	str lr, [sp, #UREGS_lr];									\
+													\
+	add r11, sp, #UREGS_kernel_sizeof+4;								\
+	str r11, [sp, #UREGS_sp];									\
+													\
+	mrs r11, SPSR_hyp;										\
+	str r11, [sp, #UREGS_cpsr];									\
+	and r11, #PSR_MODE_MASK;									\
+	cmp r11, #PSR_MODE_HYP;										\
+	blne save_guest_regs
+
+save_guest_regs:
+	ldr r11, [sp, #UREGS_lr]
+	str r11, [sp, #UREGS_LR_usr]
+	ldr r11, =0xffffffff  /* Clobber SP which is only valid for hypervisor frames. */
+	str r11, [sp, #UREGS_sp]
+	SAVE_ONE_BANKED(SP_usr)
+	SAVE_BANKED(svc)
+	SAVE_BANKED(abt)
+	SAVE_BANKED(und)
+	SAVE_BANKED(irq)
+	SAVE_BANKED(fiq)
+	SAVE_ONE_BANKED(R8_fiq); SAVE_ONE_BANKED(R9_fiq); SAVE_ONE_BANKED(R10_fiq)
+	SAVE_ONE_BANKED(R11_fiq); SAVE_ONE_BANKED(R12_fiq);
+	mov pc, lr
+
+#define DEFINE_TRAP_ENTRY(trap)										\
+	ALIGN;												\
+trap_##trap:												\
+	SAVE_ALL;											\
+	adr lr, return_from_trap;									\
+	mov r0, sp;											\
+	mov r11, sp;											\
+	bic sp, #7; /* Align the stack pointer (noop on guest trap) */					\
+	b do_trap_##trap
+
+.globl hyp_traps_vector
+	.align 5
+hyp_traps_vector:
+	.word 0				/* 0x00 - Reset */
+	b trap_undefined_instruction	/* 0x04 - Undefined Instruction */
+	b trap_supervisor_call		/* 0x08 - Supervisor Call */
+	b trap_prefetch_abort		/* 0x0c - Prefetch Abort */
+	b trap_data_abort		/* 0x10 - Data Abort */
+	b trap_hypervisor		/* 0x14 - Hypervisor */
+	b trap_irq			/* 0x18 - IRQ */
+	b trap_fiq			/* 0x1c - FIQ */
+
+DEFINE_TRAP_ENTRY(undefined_instruction)
+DEFINE_TRAP_ENTRY(supervisor_call)
+DEFINE_TRAP_ENTRY(prefetch_abort)
+DEFINE_TRAP_ENTRY(data_abort)
+DEFINE_TRAP_ENTRY(hypervisor)
+DEFINE_TRAP_ENTRY(irq)
+DEFINE_TRAP_ENTRY(fiq)
+
+ENTRY(return_from_trap)
+	ldr r11, [sp, #UREGS_cpsr]
+	and r11, #PSR_MODE_MASK
+	cmp r11, #PSR_MODE_HYP
+	beq return_to_hypervisor
+
+ENTRY(return_to_guest)
+	mov r11, sp
+	bic sp, #7 /* Align the stack pointer */
+	bl leave_hypervisor_tail
+	ldr r11, [sp, #UREGS_pc]
+	msr ELR_hyp, r11
+	ldr r11, [sp, #UREGS_cpsr]
+	msr SPSR_hyp, r11
+	RESTORE_ONE_BANKED(SP_usr)
+	RESTORE_BANKED(svc)
+	RESTORE_BANKED(abt)
+	RESTORE_BANKED(und)
+	RESTORE_BANKED(irq)
+	RESTORE_BANKED(fiq)
+	RESTORE_ONE_BANKED(R8_fiq); RESTORE_ONE_BANKED(R9_fiq); RESTORE_ONE_BANKED(R10_fiq)
+	RESTORE_ONE_BANKED(R11_fiq); RESTORE_ONE_BANKED(R12_fiq);
+	ldr lr, [sp, #UREGS_LR_usr]
+	pop {r0-r12}
+	add sp, #(UREGS_R8_fiq - UREGS_sp); /* SP, LR, SPSR, PC */
+	eret
+
+ENTRY(return_to_hypervisor)
+	ldr lr, [sp, #UREGS_lr]
+	pop {r0-r12}
+	add sp, #(UREGS_R8_fiq - UREGS_sp); /* SP, LR, SPSR, PC */
+	eret
diff --git a/xen/arch/arm/head.S b/xen/arch/arm/head.S
new file mode 100644
index 0000000..b98c921
--- /dev/null
+++ b/xen/arch/arm/head.S
@@ -0,0 +1,298 @@
+/*
+ * xen/arch/arm/head.S
+ *
+ * Start-of-day code for an ARMv7-A with virt extensions.
+ *
+ * Tim Deegan <tim@xen.org>
+ * Copyright (c) 2011 Citrix Systems.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include <asm/config.h>
+#include <asm/page.h>
+#include <asm/asm_defns.h>
+
+
+/* Macro to print a string to the UART, if there is one.
+ * Clobbers r0-r3. */
+#ifdef EARLY_UART_ADDRESS
+#define PRINT(_s)       \
+	adr   r0, 98f ; \
+	bl    puts    ; \
+	b     99f     ; \
+98:	.asciz _s     ; \
+	.align 2      ; \
+99:
+#else
+#define PRINT(s)
+#endif
+
+	.arm
+
+	/* This must be the very first address in the loaded image.
+	 * It should be linked at XEN_VIRT_START, and loaded at any
+	 * 2MB-aligned address.  All of text+data+bss must fit in 2MB,
+	 * or the initial pagetable code below will need adjustment. */
+	.global start
+start:
+	cpsid aif                    /* Disable all interrupts */
+
+	/* Save the bootloader arguments in less-clobberable registers */
+	mov   r7, r1                 /* r7 := ARM-linux machine type */
+	mov   r8, r2                 /* r8 := ATAG base address */
+
+	/* Find out where we are */
+	ldr   r0, =start
+	adr   r9, start              /* r9  := paddr (start) */
+	sub   r10, r9, r0            /* r10 := phys-offset */
+
+#ifdef EARLY_UART_ADDRESS
+	/* Say hello */
+	ldr   r11, =EARLY_UART_ADDRESS  /* r11 := UART base address */
+	bl    init_uart
+#endif
+
+	/* Check that this CPU has Hyp mode */
+	mrc   CP32(r0, ID_PFR1)
+	and   r0, r0, #0xf000        /* Bits 12-15 define virt extensions */
+	teq   r0, #0x1000            /* Must == 0x1 or may be incompatible */
+	beq   1f
+	bl    putn
+	PRINT("- CPU doesn't support the virtualization extensions -\r\n")
+	b     fail
+1:
+	/* Check if we're already in it */
+	mrs   r0, cpsr
+	and   r0, r0, #0x1f          /* Mode is in the low 5 bits of CPSR */
+	teq   r0, #0x1a              /* Hyp Mode? */
+	bne   1f
+	PRINT("- Started in Hyp mode -\r\n")
+	b     hyp
+1:
+	/* Otherwise, it must have been Secure Supervisor mode */
+	mrc   CP32(r0, SCR)
+	tst   r0, #0x1               /* Not-Secure bit set? */
+	beq   1f
+	PRINT("- CPU is not in Hyp mode or Secure state -\r\n")
+	b     fail
+1:
+	/* OK, we're in Secure state. */
+	PRINT("- Started in Secure state -\r\n- Entering Hyp mode -\r\n")
+
+	/* Dance into Hyp mode */
+	cpsid aif, #0x16             /* Enter Monitor mode */
+	mrc   CP32(r0, SCR)
+	orr   r0, r0, #0x100         /* Set HCE */
+	orr   r0, r0, #0xb1          /* Set SCD, AW, FW and NS */
+	bic   r0, r0, #0xe           /* Clear EA, FIQ and IRQ */
+	mcr   CP32(r0, SCR)
+	/* Ugly: the system timer's frequency register is only
+	 * programmable in Secure state.  Since we don't know where its
+	 * memory-mapped control registers live, we can't find out the
+	 * right frequency.  Use the VE model's default frequency here. */
+	ldr   r0, =0x5f5e100         /* 100 MHz */
+	mcr   CP32(r0, CNTFRQ)
+	ldr   r0, =0x40c00           /* SMP, c11, c10 in non-secure mode */
+	mcr   CP32(r0, NSACR)
+	/* Continuing ugliness: Set up the GIC so NS state owns interrupts */
+	mov   r0, #GIC_BASE_ADDRESS
+	add   r0, r0, #GIC_DR_OFFSET
+	mov   r1, #0
+	str   r1, [r0]               /* Disable delivery in the distributor */
+	add   r0, r0, #0x80          /* GICD_IGROUP0 */
+	mov   r2, #0xffffffff        /* All interrupts to group 1 */
+	str   r2, [r0]
+	str   r2, [r0, #4]
+	str   r2, [r0, #8]
+	/* Must drop priority mask below 0x80 before entering NS state */
+	mov   r0, #GIC_BASE_ADDRESS
+	add   r0, r0, #GIC_CR_OFFSET
+	ldr   r1, =0xff
+	str   r1, [r0, #0x4]         /* -> GICC_PMR */
+	/* Reset a few config registers */
+	mov   r0, #0
+	mcr   CP32(r0, FCSEIDR)
+	mcr   CP32(r0, CONTEXTIDR)
+	/* FIXME: ought to reset some other NS control regs here */
+	adr   r1, 1f
+	adr   r0, hyp                /* Store paddr (hyp entry point) */
+	str   r0, [r1]               /* where we can use it for RFE */
+	isb                          /* Ensure we see the stored target address */
+	rfeia r1                     /* Enter Hyp mode */
+
+1:	.word 0                      /* PC to enter Hyp mode at */
+	.word 0x000001da             /* CPSR: LE, Abort/IRQ/FIQ off, Hyp */
+
+hyp:
+	PRINT("- Setting up control registers -\r\n")
+
+	/* Set up memory attribute type tables */
+	ldr   r0, =MAIR0VAL
+	ldr   r1, =MAIR1VAL
+	mcr   CP32(r0, MAIR0)
+	mcr   CP32(r1, MAIR1)
+	mcr   CP32(r0, HMAIR0)
+	mcr   CP32(r1, HMAIR1)
+
+	/* Set up the HTCR:
+	 * PT walks use Outer-Shareable accesses,
+	 * PT walks are write-back, no-write-allocate in both cache levels,
+	 * Full 32-bit address space goes through this table. */
+	ldr   r0, =0x80002500
+	mcr   CP32(r0, HTCR)
+
+	/* Set up the HSCTLR:
+	 * Exceptions in LE ARM,
+	 * Low-latency IRQs disabled,
+	 * Write-implies-XN disabled (for now),
+	 * I-cache and d-cache enabled,
+	 * Alignment checking enabled,
+	 * MMU translation disabled (for now). */
+	ldr   r0, =(HSCTLR_BASE|SCTLR_A|SCTLR_C)
+	mcr   CP32(r0, HSCTLR)
+
+	/* Write Xen's PT's paddr into the HTTBR */
+	ldr   r4, =xen_pgtable
+	add   r4, r4, r10            /* r4 := paddr (xen_pagetable) */
+	mov   r5, #0                 /* r4:r5 is paddr (xen_pagetable) */
+	mcrr  CP64(r4, r5, HTTBR)
+
+	/* Build the baseline idle pagetable's first-level entries */
+	ldr   r1, =xen_second
+	add   r1, r1, r10            /* r1 := paddr (xen_second) */
+	mov   r3, #0x0
+	orr   r2, r1, #0xe00         /* r2:r3 := table map of xen_second */
+	orr   r2, r2, #0x07f         /* (+ rights for linear PT) */
+	strd  r2, r3, [r4, #0]       /* Map it in slot 0 */
+	add   r2, r2, #0x1000
+	strd  r2, r3, [r4, #8]       /* Map 2nd page in slot 1 */
+	add   r2, r2, #0x1000
+	strd  r2, r3, [r4, #16]      /* Map 3rd page in slot 2 */
+	add   r2, r2, #0x1000
+	strd  r2, r3, [r4, #24]      /* Map 4th page in slot 3 */
+
+	/* Now set up the second-level entries */
+	orr   r2, r9, #0xe00
+	orr   r2, r2, #0x07d         /* r2:r3 := 2MB normal map of Xen */
+	mov   r4, r9, lsr #18        /* Slot for paddr(start) */
+	strd  r2, r3, [r1, r4]       /* Map Xen there */
+	ldr   r4, =start
+	lsr   r4, #18                /* Slot for vaddr(start) */
+	strd  r2, r3, [r1, r4]       /* Map Xen there too */
+#ifdef EARLY_UART_ADDRESS
+	ldr   r3, =(1<<(54-32))      /* NS for device mapping */
+	lsr   r2, r11, #21
+	lsl   r2, r2, #21            /* 2MB-aligned paddr of UART */
+	orr   r2, r2, #0xe00
+	orr   r2, r2, #0x071         /* r2:r3 := 2MB dev map including UART */
+	add   r4, r4, #8
+	strd  r2, r3, [r1, r4]       /* Map it in the fixmap's slot */
+#endif
+
+	PRINT("- Turning on paging -\r\n")
+
+	ldr   r1, =paging            /* Explicit vaddr, not RIP-relative */
+	mrc   CP32(r0, HSCTLR)
+	orr   r0, r0, #0x1           /* Add in the MMU enable bit */
+	dsb                          /* Flush PTE writes and finish reads */
+	mcr   CP32(r0, HSCTLR)       /* now paging is enabled */
+	isb                          /* Now, flush the icache */
+	mov   pc, r1                 /* Get a proper vaddr into PC */
+paging:
+
+#ifdef EARLY_UART_ADDRESS
+	/* Recover the UART address in the new address space */
+	lsl   r11, #11
+	lsr   r11, #11               /* UART base's offset from 2MB base */
+	adr   r0, start
+	add   r0, r0, #0x200000      /* vaddr of the fixmap's 2MB slot */
+	add   r11, r11, r0           /* r11 := vaddr (UART base address) */
+#endif
+
+	PRINT("- Entering C -\r\n")
+
+	ldr   sp, =init_stack        /* Supply a stack */
+	add   sp, #STACK_SIZE        /* (which grows down from the top). */
+	sub   sp, #CPUINFO_sizeof    /* Make room for CPU save record */
+	mov   r0, r10                /* Marshal args: - phys_offset */
+	mov   r1, r7                 /*               - machine type */
+	mov   r2, r8                 /*               - ATAG address */
+	b     start_xen              /* and disappear into the land of C */
+
+/* Fail-stop
+ * r0: string explaining why */
+fail:	PRINT("- Boot failed -\r\n")
+1:	wfe
+	b     1b
+
+#ifdef EARLY_UART_ADDRESS
+
+/* Bring up the UART. Specific to the PL011 UART.
+ * Clobbers r0-r2 */
+init_uart:
+	mov   r1, #0x0
+	str   r1, [r11, #0x24]       /* -> UARTIBRD (Baud divisor fraction) */
+	mov   r1, #0x4               /* 7.3728MHz / 0x4 == 16 * 115200 */
+	str   r1, [r11, #0x24]       /* -> UARTIBRD (Baud divisor integer) */
+	mov   r1, #0x60              /* 8n1 */
+	str   r1, [r11, #0x24]       /* -> UARTLCR_H (Line control) */
+	ldr   r1, =0x00000301        /* RXE | TXE | UARTEN */
+	str   r1, [r11, #0x30]       /* -> UARTCR (Control Register) */
+	adr   r0, 1f
+	b     puts
+1:	.asciz "- UART enabled -\r\n"
+	.align 4
+
+/* Print early debug messages.  Specific to the PL011 UART.
+ * r0: Nul-terminated string to print.
+ * Clobbers r0-r2 */
+puts:
+	ldr   r2, [r11, #0x18]       /* <- UARTFR (Flag register) */
+	tst   r2, #0x8               /* Check BUSY bit */
+	bne   puts                   /* Wait for the UART to be ready */
+	ldrb  r2, [r0], #1           /* Load next char */
+	teq   r2, #0                 /* Exit on nul*/
+	moveq pc, lr
+	str   r2, [r11]              /* -> UARTDR (Data Register) */
+	b     puts
+
+/* Print a 32-bit number in hex.  Specific to the PL011 UART.
+ * r0: Number to print.
+ * clobbers r0-r3 */
+putn:
+	adr   r1, hex
+	mov   r3, #8
+1:	ldr   r2, [r11, #0x18]       /* <- UARTFR (Flag register) */
+	tst   r2, #0x8               /* Check BUSY bit */
+	bne   1b                     /* Wait for the UART to be ready */
+	and   r2, r0, #0xf0000000    /* Mask off the top nybble */
+	ldrb  r2, [r1, r2, lsr #28]  /* Convert to a char */
+	str   r2, [r11]              /* -> UARTDR (Data Register) */
+	lsl   r0, #4                 /* Roll it through one nybble at a time */
+	subs  r3, r3, #1
+	bne   1b
+	adr   r0, crlf               /* Finish with a newline */
+	b     puts
+
+crlf:	.asciz "\r\n"
+hex:	.ascii "0123456789abcdef"
+	.align 2
+
+#else  /* EARLY_UART_ADDRESS */
+
+init_uart:
+.global early_puts
+early_puts:
+puts:
+putn:	mov   pc, lr
+
+#endif /* EARLY_UART_ADDRESS */
diff --git a/xen/arch/arm/xen.lds.S b/xen/arch/arm/xen.lds.S
new file mode 100644
index 0000000..5a62e2c
--- /dev/null
+++ b/xen/arch/arm/xen.lds.S
@@ -0,0 +1,141 @@
+/* Excerpts written by Martin Mares <mj@atrey.karlin.mff.cuni.cz> */
+/* Modified for i386/x86-64 Xen by Keir Fraser */
+/* Modified for ARM Xen by Ian Campbell */
+
+#include <xen/config.h>
+#include <xen/cache.h>
+#include <asm/page.h>
+#include <asm/percpu.h>
+#undef ENTRY
+#undef ALIGN
+
+ENTRY(start)
+
+OUTPUT_ARCH(arm)
+
+PHDRS
+{
+  text PT_LOAD /* XXX should be AT ( XEN_PHYS_START ) */ ;
+}
+SECTIONS
+{
+  . = XEN_VIRT_START;
+  _start = .;
+  .text : /* XXX should be AT ( XEN_PHYS_START ) */ {
+        _stext = .;            /* Text section */
+       *(.text)
+       *(.fixup)
+       *(.gnu.warning)
+       _etext = .;             /* End of text section */
+  } :text = 0x9090
+
+  . = ALIGN(PAGE_SIZE);
+  .rodata : {
+        _srodata = .;          /* Read-only data */
+       *(.rodata)
+       *(.rodata.*)
+        _erodata = .;          /* End of read-only data */
+  } :text
+
+  .data : {                    /* Data */
+       . = ALIGN(PAGE_SIZE);
+       *(.data.page_aligned)
+       *(.data)
+       *(.data.rel)
+       *(.data.rel.*)
+       CONSTRUCTORS
+  } :text
+
+  . = ALIGN(SMP_CACHE_BYTES);
+  .data.read_mostly : {
+       /* Exception table */
+       __start___ex_table = .;
+       *(.ex_table)
+       __stop___ex_table = .;
+
+       /* Pre-exception table */
+       __start___pre_ex_table = .;
+       *(.ex_table.pre)
+       __stop___pre_ex_table = .;
+
+       *(.data.read_mostly)
+       *(.data.rel.ro)
+       *(.data.rel.ro.*)
+  } :text
+
+#ifdef LOCK_PROFILE
+  . = ALIGN(32);
+  __lock_profile_start = .;
+  .lockprofile.data : { *(.lockprofile.data) } :text
+  __lock_profile_end = .;
+#endif
+
+  . = ALIGN(PAGE_SIZE);             /* Init code and data */
+  __init_begin = .;
+  .init.text : {
+       _sinittext = .;
+       *(.init.text)
+       _einittext = .;
+  } :text
+  . = ALIGN(PAGE_SIZE);
+  .init.data : {
+       *(.init.rodata)
+       *(.init.rodata.str*)
+       *(.init.data)
+       *(.init.data.rel)
+       *(.init.data.rel.*)
+  } :text
+  . = ALIGN(32);
+  .init.setup : {
+       __setup_start = .;
+       *(.init.setup)
+       __setup_end = .;
+  } :text
+  .initcall.init : {
+       __initcall_start = .;
+       *(.initcallpresmp.init)
+       __presmp_initcall_end = .;
+       *(.initcall1.init)
+       __initcall_end = .;
+  } :text
+  .xsm_initcall.init : {
+       __xsm_initcall_start = .;
+       *(.xsm_initcall.init)
+       __xsm_initcall_end = .;
+  } :text
+  . = ALIGN(STACK_SIZE);
+  __init_end = .;
+
+  .bss : {                     /* BSS */
+       __bss_start = .;
+       *(.bss.stack_aligned)
+       . = ALIGN(PAGE_SIZE);
+       *(.bss.page_aligned)
+       *(.bss)
+       . = ALIGN(SMP_CACHE_BYTES);
+       __per_cpu_start = .;
+       *(.bss.percpu)
+       . = ALIGN(SMP_CACHE_BYTES);
+       *(.bss.percpu.read_mostly)
+       . = ALIGN(SMP_CACHE_BYTES);
+       __per_cpu_data_end = .;
+  } :text
+  _end = . ;
+
+  /* Sections to be discarded */
+  /DISCARD/ : {
+       *(.exit.text)
+       *(.exit.data)
+       *(.exitcall.exit)
+       *(.eh_frame)
+  }
+
+  /* Stabs debugging sections.  */
+  .stab 0 : { *(.stab) }
+  .stabstr 0 : { *(.stabstr) }
+  .stab.excl 0 : { *(.stab.excl) }
+  .stab.exclstr 0 : { *(.stab.exclstr) }
+  .stab.index 0 : { *(.stab.index) }
+  .stab.indexstr 0 : { *(.stab.indexstr) }
+  .comment 0 : { *(.comment) }
+}
diff --git a/xen/include/asm-arm/asm_defns.h b/xen/include/asm-arm/asm_defns.h
new file mode 100644
index 0000000..c59fb6c
--- /dev/null
+++ b/xen/include/asm-arm/asm_defns.h
@@ -0,0 +1,18 @@
+#ifndef __ARM_ASM_DEFNS_H__
+#define __ARM_ASM_DEFNS_H__
+
+#ifndef COMPILE_OFFSETS
+/* NB. Auto-generated from arch/.../asm-offsets.c */
+#include <asm/asm-offsets.h>
+#endif
+#include <asm/processor.h>
+
+#endif /* __ARM_ASM_DEFNS_H__ */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 13:14:35 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 13: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.xensource.com>)
	id 1RZ0HR-0002Vs-JZ; Fri, 09 Dec 2011 13:14:25 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RZ0HO-0002Qv-Ue
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 13:14:23 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1323436410!4910460!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDQ0MTg=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9936 invoked from network); 9 Dec 2011 13:13:32 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 13:13:32 -0000
X-IronPort-AV: E=Sophos;i="4.71,325,1320642000"; d="scan'208";a="19808904"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 08:13:29 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 08:13:29 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pB9DCpDx008248;
	Fri, 9 Dec 2011 05:13:12 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 9 Dec 2011 13:13:16 +0000
Message-ID: <1323436408-16335-13-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1112091208420.3517@kaball-desktop>
References: <alpine.DEB.2.00.1112091208420.3517@kaball-desktop>
MIME-Version: 1.0
Cc: keir.xen@gmail.com, Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, JBeulich@suse.com,
	Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v2 13/25] arm: domain_build
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Functions to build dom0: memory allocation, p2m construction, mappings
of the MMIO regions, ATAG setup.


Changes in v2:

- set elf.dest.


Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
---
 xen/arch/arm/domain_build.c        |  212 ++++++++++++++++++++++++++++++++++++
 xen/common/libelf/libelf-dominfo.c |    6 +
 xen/include/asm-arm/setup.h        |    2 +
 xen/include/xen/libelf.h           |    2 +-
 4 files changed, 221 insertions(+), 1 deletions(-)
 create mode 100644 xen/arch/arm/domain_build.c

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
new file mode 100644
index 0000000..b4e0aaa
--- /dev/null
+++ b/xen/arch/arm/domain_build.c
@@ -0,0 +1,212 @@
+#include <xen/config.h>
+#include <xen/init.h>
+#include <xen/lib.h>
+#include <xen/mm.h>
+#include <xen/domain_page.h>
+#include <xen/sched.h>
+#include <xen/libelf.h>
+#include <asm/irq.h>
+
+#include "gic.h"
+
+static unsigned int __initdata opt_dom0_max_vcpus;
+integer_param("dom0_max_vcpus", opt_dom0_max_vcpus);
+
+struct vcpu *__init alloc_dom0_vcpu0(void)
+{
+    dom0->vcpu = xmalloc_array(struct vcpu *, opt_dom0_max_vcpus);
+    if ( !dom0->vcpu )
+    {
+            printk("failed to alloc dom0->vccpu\n");
+        return NULL;
+    }
+    memset(dom0->vcpu, 0, opt_dom0_max_vcpus * sizeof(*dom0->vcpu));
+    dom0->max_vcpus = opt_dom0_max_vcpus;
+
+    return alloc_vcpu(dom0, 0, 0);
+}
+
+extern void guest_mode_entry(void);
+
+static void copy_from_flash(void *dst, paddr_t flash, unsigned long len)
+{
+    void *src = (void *)FIXMAP_ADDR(FIXMAP_MISC);
+    unsigned long offs;
+
+    printk("Copying %#lx bytes from flash %"PRIpaddr" to %p-%p: [",
+           len, flash, dst, dst+(1<<23));
+    for ( offs = 0; offs < len ; offs += PAGE_SIZE )
+    {
+        if ( ( offs % (1<<20) ) == 0 )
+            printk(".");
+        set_fixmap(FIXMAP_MISC, (flash+offs) >> PAGE_SHIFT, DEV_SHARED);
+        memcpy(dst+offs, src, PAGE_SIZE);
+    }
+    printk("]\n");
+
+    clear_fixmap(FIXMAP_MISC);
+}
+
+static void setup_linux_atag(paddr_t tags, paddr_t ram_s, paddr_t ram_e)
+{
+    paddr_t ma = gvirt_to_maddr(tags);
+    void *map = map_domain_page(ma>>PAGE_SHIFT);
+    void *p = map + (tags & (PAGE_SIZE - 1));
+    char cmdline[] = "earlyprintk=xenboot console=ttyAMA1 root=/dev/mmcblk0 debug rw";
+
+    /* not enough room on this page for all the tags */
+    BUG_ON(PAGE_SIZE - (tags & (PAGE_SIZE - 1)) < 8 * sizeof(uint32_t));
+
+#define TAG(type, val) *(type*)p = val; p+= sizeof(type)
+
+    /* ATAG_CORE */
+    TAG(uint32_t, 2);
+    TAG(uint32_t, 0x54410001);
+
+    /* ATAG_MEM */
+    TAG(uint32_t, 4);
+    TAG(uint32_t, 0x54410002);
+    TAG(uint32_t, (ram_e - ram_s) & 0xFFFFFFFF);
+    TAG(uint32_t, ram_s & 0xFFFFFFFF);
+
+    /* ATAG_CMDLINE */
+    TAG(uint32_t, 2 + ((strlen(cmdline) + 4) >> 2));
+    TAG(uint32_t, 0x54410009);
+    memcpy(p, cmdline, strlen(cmdline) + 1);
+    p += ((strlen(cmdline) + 4) >> 2) << 2;
+
+    /* ATAG_NONE */
+    TAG(uint32_t, 0);
+    TAG(uint32_t, 0);
+
+#undef TAG
+
+    unmap_domain_page(map);
+}
+
+/* Store kernel in first 8M of flash */
+#define KERNEL_FLASH_ADDRESS 0x00000000UL
+#define KERNEL_FLASH_SIZE    0x00800000UL
+
+int construct_dom0(struct domain *d)
+{
+    int rc, kernel_order;
+    void *kernel_img;
+
+    struct vcpu *v = d->vcpu[0];
+    struct cpu_user_regs *regs = &v->arch.user_regs;
+
+    struct elf_binary elf;
+    struct elf_dom_parms parms;
+
+    /* Sanity! */
+    BUG_ON(d->domain_id != 0);
+    BUG_ON(d->vcpu[0] == NULL);
+    BUG_ON(v->is_initialised);
+
+    printk("*** LOADING DOMAIN 0 ***\n");
+
+    kernel_order = get_order_from_bytes(KERNEL_FLASH_SIZE);
+    kernel_img = alloc_xenheap_pages(kernel_order, 0);
+    if ( kernel_img == NULL )
+        panic("Cannot allocate temporary buffer for kernel.\n");
+
+    copy_from_flash(kernel_img, KERNEL_FLASH_ADDRESS, KERNEL_FLASH_SIZE);
+
+    d->max_pages = ~0U;
+
+    if ( (rc = elf_init(&elf, kernel_img, KERNEL_FLASH_SIZE )) != 0 )
+        return rc;  memset(regs, 0, sizeof(*regs));
+#ifdef VERBOSE
+    elf_set_verbose(&elf);
+#endif
+    elf_parse_binary(&elf);
+    if ( (rc = elf_xen_parse(&elf, &parms)) != 0 )
+        return rc;
+
+    if ( (rc = p2m_alloc_table(d)) != 0 )
+        return rc;
+
+    /* 128M at 3G physical */
+    /* TODO size and location according to platform info */
+    printk("Populate P2M %#llx->%#llx\n", 0xc0000000ULL, 0xc8000000ULL);
+    p2m_populate_ram(d, 0xc0000000ULL, 0xc8000000ULL);
+
+    printk("Map CS2 MMIO regions 1:1 in the P2M %#llx->%#llx\n", 0x18000000ULL, 0x1BFFFFFFULL);
+    map_mmio_regions(d, 0x18000000, 0x1BFFFFFF, 0x18000000);
+    printk("Map CS3 MMIO regions 1:1 in the P2M %#llx->%#llx\n", 0x1C000000ULL, 0x1FFFFFFFULL);
+    map_mmio_regions(d, 0x1C000000, 0x1FFFFFFF, 0x1C000000);
+    printk("Map VGIC MMIO regions 1:1 in the P2M %#llx->%#llx\n", 0x2C008000ULL, 0x2DFFFFFFULL);
+    map_mmio_regions(d, 0x2C008000, 0x2DFFFFFF, 0x2C008000);
+
+    gicv_setup(d);
+
+    printk("Routing peripheral interrupts to guest\n");
+    /* TODO Get from device tree */
+    /*gic_route_irq_to_guest(d, 37, "uart0"); -- XXX used by Xen*/
+    gic_route_irq_to_guest(d, 38, "uart1");
+    gic_route_irq_to_guest(d, 39, "uart2");
+    gic_route_irq_to_guest(d, 40, "uart3");
+    gic_route_irq_to_guest(d, 41, "mmc0-1");
+    gic_route_irq_to_guest(d, 42, "mmc0-2");
+    gic_route_irq_to_guest(d, 44, "keyboard");
+    gic_route_irq_to_guest(d, 45, "mouse");
+    gic_route_irq_to_guest(d, 46, "lcd");
+    gic_route_irq_to_guest(d, 47, "eth");
+
+    /* Enable second stage translation */
+    WRITE_CP32(READ_CP32(HCR) | HCR_VM, HCR); isb();
+
+    /* The following load uses domain's p2m */
+    p2m_load_VTTBR(d);
+
+    printk("Loading ELF image into guest memory\n");
+    elf.dest = (void*)(unsigned long)parms.virt_kstart;
+    elf_load_binary(&elf);
+
+    printk("Free temporary kernel buffer\n");
+    free_xenheap_pages(kernel_img, kernel_order);
+
+    setup_linux_atag(0xc0000100ULL, 0xc0000000ULL, 0xc8000000ULL);
+
+    clear_bit(_VPF_down, &v->pause_flags);
+
+    memset(regs, 0, sizeof(*regs));
+
+    regs->pc = (uint32_t)parms.virt_entry;
+
+    regs->cpsr = PSR_ABT_MASK|PSR_FIQ_MASK|PSR_IRQ_MASK|PSR_MODE_SVC;
+
+/* FROM LINUX head.S
+
+ * Kernel startup entry point.
+ * ---------------------------
+ *
+ * This is normally called from the decompressor code.  The requirements
+ * are: MMU = off, D-cache = off, I-cache = dont care, r0 = 0,
+ * r1 = machine nr, r2 = atags or dtb pointer.
+ *...
+ */
+
+    regs->r0 = 0; /* SBZ */
+    regs->r1 = 2272; /* Machine NR: Versatile Express */
+    regs->r2 = 0xc0000100; /* ATAGS */
+
+    WRITE_CP32(SCTLR_BASE, SCTLR);
+
+    WRITE_CP32(HCR_AMO|HCR_IMO|HCR_VM, HCR);
+    isb();
+
+    local_abort_enable();
+
+    return 0;
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/common/libelf/libelf-dominfo.c b/xen/common/libelf/libelf-dominfo.c
index c569a48..523837f 100644
--- a/xen/common/libelf/libelf-dominfo.c
+++ b/xen/common/libelf/libelf-dominfo.c
@@ -341,6 +341,12 @@ static int elf_xen_note_check(struct elf_binary *elf,
         return 0;
     }
 
+    if ( elf_uval(elf, elf->ehdr, e_machine) == EM_ARM )
+    {
+         elf_msg(elf, "%s: Not bothering with notes on ARM\n", __FUNCTION__);
+         return 0;
+    }
+
     /* Check the contents of the Xen notes or guest string. */
     if ( ((strlen(parms->loader) == 0) ||
           strncmp(parms->loader, "generic", 7)) &&
diff --git a/xen/include/asm-arm/setup.h b/xen/include/asm-arm/setup.h
index c27d438..1dc3f97 100644
--- a/xen/include/asm-arm/setup.h
+++ b/xen/include/asm-arm/setup.h
@@ -5,6 +5,8 @@
 
 void arch_get_xen_caps(xen_capabilities_info_t *info);
 
+int construct_dom0(struct domain *d);
+
 #endif
 /*
  * Local variables:
diff --git a/xen/include/xen/libelf.h b/xen/include/xen/libelf.h
index 9de84eb..d799a80 100644
--- a/xen/include/xen/libelf.h
+++ b/xen/include/xen/libelf.h
@@ -23,7 +23,7 @@
 #ifndef __XEN_LIBELF_H__
 #define __XEN_LIBELF_H__
 
-#if defined(__i386__) || defined(__x86_64__) || defined(__ia64__)
+#if defined(__i386__) || defined(__x86_64__) || defined(__ia64__) || defined(__arm__)
 #define XEN_ELF_LITTLE_ENDIAN
 #else
 #error define architectural endianness
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 13:14:35 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 13: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.xensource.com>)
	id 1RZ0HR-0002Vs-JZ; Fri, 09 Dec 2011 13:14:25 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RZ0HO-0002Qv-Ue
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 13:14:23 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1323436410!4910460!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDQ0MTg=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9936 invoked from network); 9 Dec 2011 13:13:32 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 13:13:32 -0000
X-IronPort-AV: E=Sophos;i="4.71,325,1320642000"; d="scan'208";a="19808904"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 08:13:29 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 08:13:29 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pB9DCpDx008248;
	Fri, 9 Dec 2011 05:13:12 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 9 Dec 2011 13:13:16 +0000
Message-ID: <1323436408-16335-13-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1112091208420.3517@kaball-desktop>
References: <alpine.DEB.2.00.1112091208420.3517@kaball-desktop>
MIME-Version: 1.0
Cc: keir.xen@gmail.com, Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, JBeulich@suse.com,
	Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v2 13/25] arm: domain_build
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Functions to build dom0: memory allocation, p2m construction, mappings
of the MMIO regions, ATAG setup.


Changes in v2:

- set elf.dest.


Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
---
 xen/arch/arm/domain_build.c        |  212 ++++++++++++++++++++++++++++++++++++
 xen/common/libelf/libelf-dominfo.c |    6 +
 xen/include/asm-arm/setup.h        |    2 +
 xen/include/xen/libelf.h           |    2 +-
 4 files changed, 221 insertions(+), 1 deletions(-)
 create mode 100644 xen/arch/arm/domain_build.c

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
new file mode 100644
index 0000000..b4e0aaa
--- /dev/null
+++ b/xen/arch/arm/domain_build.c
@@ -0,0 +1,212 @@
+#include <xen/config.h>
+#include <xen/init.h>
+#include <xen/lib.h>
+#include <xen/mm.h>
+#include <xen/domain_page.h>
+#include <xen/sched.h>
+#include <xen/libelf.h>
+#include <asm/irq.h>
+
+#include "gic.h"
+
+static unsigned int __initdata opt_dom0_max_vcpus;
+integer_param("dom0_max_vcpus", opt_dom0_max_vcpus);
+
+struct vcpu *__init alloc_dom0_vcpu0(void)
+{
+    dom0->vcpu = xmalloc_array(struct vcpu *, opt_dom0_max_vcpus);
+    if ( !dom0->vcpu )
+    {
+            printk("failed to alloc dom0->vccpu\n");
+        return NULL;
+    }
+    memset(dom0->vcpu, 0, opt_dom0_max_vcpus * sizeof(*dom0->vcpu));
+    dom0->max_vcpus = opt_dom0_max_vcpus;
+
+    return alloc_vcpu(dom0, 0, 0);
+}
+
+extern void guest_mode_entry(void);
+
+static void copy_from_flash(void *dst, paddr_t flash, unsigned long len)
+{
+    void *src = (void *)FIXMAP_ADDR(FIXMAP_MISC);
+    unsigned long offs;
+
+    printk("Copying %#lx bytes from flash %"PRIpaddr" to %p-%p: [",
+           len, flash, dst, dst+(1<<23));
+    for ( offs = 0; offs < len ; offs += PAGE_SIZE )
+    {
+        if ( ( offs % (1<<20) ) == 0 )
+            printk(".");
+        set_fixmap(FIXMAP_MISC, (flash+offs) >> PAGE_SHIFT, DEV_SHARED);
+        memcpy(dst+offs, src, PAGE_SIZE);
+    }
+    printk("]\n");
+
+    clear_fixmap(FIXMAP_MISC);
+}
+
+static void setup_linux_atag(paddr_t tags, paddr_t ram_s, paddr_t ram_e)
+{
+    paddr_t ma = gvirt_to_maddr(tags);
+    void *map = map_domain_page(ma>>PAGE_SHIFT);
+    void *p = map + (tags & (PAGE_SIZE - 1));
+    char cmdline[] = "earlyprintk=xenboot console=ttyAMA1 root=/dev/mmcblk0 debug rw";
+
+    /* not enough room on this page for all the tags */
+    BUG_ON(PAGE_SIZE - (tags & (PAGE_SIZE - 1)) < 8 * sizeof(uint32_t));
+
+#define TAG(type, val) *(type*)p = val; p+= sizeof(type)
+
+    /* ATAG_CORE */
+    TAG(uint32_t, 2);
+    TAG(uint32_t, 0x54410001);
+
+    /* ATAG_MEM */
+    TAG(uint32_t, 4);
+    TAG(uint32_t, 0x54410002);
+    TAG(uint32_t, (ram_e - ram_s) & 0xFFFFFFFF);
+    TAG(uint32_t, ram_s & 0xFFFFFFFF);
+
+    /* ATAG_CMDLINE */
+    TAG(uint32_t, 2 + ((strlen(cmdline) + 4) >> 2));
+    TAG(uint32_t, 0x54410009);
+    memcpy(p, cmdline, strlen(cmdline) + 1);
+    p += ((strlen(cmdline) + 4) >> 2) << 2;
+
+    /* ATAG_NONE */
+    TAG(uint32_t, 0);
+    TAG(uint32_t, 0);
+
+#undef TAG
+
+    unmap_domain_page(map);
+}
+
+/* Store kernel in first 8M of flash */
+#define KERNEL_FLASH_ADDRESS 0x00000000UL
+#define KERNEL_FLASH_SIZE    0x00800000UL
+
+int construct_dom0(struct domain *d)
+{
+    int rc, kernel_order;
+    void *kernel_img;
+
+    struct vcpu *v = d->vcpu[0];
+    struct cpu_user_regs *regs = &v->arch.user_regs;
+
+    struct elf_binary elf;
+    struct elf_dom_parms parms;
+
+    /* Sanity! */
+    BUG_ON(d->domain_id != 0);
+    BUG_ON(d->vcpu[0] == NULL);
+    BUG_ON(v->is_initialised);
+
+    printk("*** LOADING DOMAIN 0 ***\n");
+
+    kernel_order = get_order_from_bytes(KERNEL_FLASH_SIZE);
+    kernel_img = alloc_xenheap_pages(kernel_order, 0);
+    if ( kernel_img == NULL )
+        panic("Cannot allocate temporary buffer for kernel.\n");
+
+    copy_from_flash(kernel_img, KERNEL_FLASH_ADDRESS, KERNEL_FLASH_SIZE);
+
+    d->max_pages = ~0U;
+
+    if ( (rc = elf_init(&elf, kernel_img, KERNEL_FLASH_SIZE )) != 0 )
+        return rc;  memset(regs, 0, sizeof(*regs));
+#ifdef VERBOSE
+    elf_set_verbose(&elf);
+#endif
+    elf_parse_binary(&elf);
+    if ( (rc = elf_xen_parse(&elf, &parms)) != 0 )
+        return rc;
+
+    if ( (rc = p2m_alloc_table(d)) != 0 )
+        return rc;
+
+    /* 128M at 3G physical */
+    /* TODO size and location according to platform info */
+    printk("Populate P2M %#llx->%#llx\n", 0xc0000000ULL, 0xc8000000ULL);
+    p2m_populate_ram(d, 0xc0000000ULL, 0xc8000000ULL);
+
+    printk("Map CS2 MMIO regions 1:1 in the P2M %#llx->%#llx\n", 0x18000000ULL, 0x1BFFFFFFULL);
+    map_mmio_regions(d, 0x18000000, 0x1BFFFFFF, 0x18000000);
+    printk("Map CS3 MMIO regions 1:1 in the P2M %#llx->%#llx\n", 0x1C000000ULL, 0x1FFFFFFFULL);
+    map_mmio_regions(d, 0x1C000000, 0x1FFFFFFF, 0x1C000000);
+    printk("Map VGIC MMIO regions 1:1 in the P2M %#llx->%#llx\n", 0x2C008000ULL, 0x2DFFFFFFULL);
+    map_mmio_regions(d, 0x2C008000, 0x2DFFFFFF, 0x2C008000);
+
+    gicv_setup(d);
+
+    printk("Routing peripheral interrupts to guest\n");
+    /* TODO Get from device tree */
+    /*gic_route_irq_to_guest(d, 37, "uart0"); -- XXX used by Xen*/
+    gic_route_irq_to_guest(d, 38, "uart1");
+    gic_route_irq_to_guest(d, 39, "uart2");
+    gic_route_irq_to_guest(d, 40, "uart3");
+    gic_route_irq_to_guest(d, 41, "mmc0-1");
+    gic_route_irq_to_guest(d, 42, "mmc0-2");
+    gic_route_irq_to_guest(d, 44, "keyboard");
+    gic_route_irq_to_guest(d, 45, "mouse");
+    gic_route_irq_to_guest(d, 46, "lcd");
+    gic_route_irq_to_guest(d, 47, "eth");
+
+    /* Enable second stage translation */
+    WRITE_CP32(READ_CP32(HCR) | HCR_VM, HCR); isb();
+
+    /* The following load uses domain's p2m */
+    p2m_load_VTTBR(d);
+
+    printk("Loading ELF image into guest memory\n");
+    elf.dest = (void*)(unsigned long)parms.virt_kstart;
+    elf_load_binary(&elf);
+
+    printk("Free temporary kernel buffer\n");
+    free_xenheap_pages(kernel_img, kernel_order);
+
+    setup_linux_atag(0xc0000100ULL, 0xc0000000ULL, 0xc8000000ULL);
+
+    clear_bit(_VPF_down, &v->pause_flags);
+
+    memset(regs, 0, sizeof(*regs));
+
+    regs->pc = (uint32_t)parms.virt_entry;
+
+    regs->cpsr = PSR_ABT_MASK|PSR_FIQ_MASK|PSR_IRQ_MASK|PSR_MODE_SVC;
+
+/* FROM LINUX head.S
+
+ * Kernel startup entry point.
+ * ---------------------------
+ *
+ * This is normally called from the decompressor code.  The requirements
+ * are: MMU = off, D-cache = off, I-cache = dont care, r0 = 0,
+ * r1 = machine nr, r2 = atags or dtb pointer.
+ *...
+ */
+
+    regs->r0 = 0; /* SBZ */
+    regs->r1 = 2272; /* Machine NR: Versatile Express */
+    regs->r2 = 0xc0000100; /* ATAGS */
+
+    WRITE_CP32(SCTLR_BASE, SCTLR);
+
+    WRITE_CP32(HCR_AMO|HCR_IMO|HCR_VM, HCR);
+    isb();
+
+    local_abort_enable();
+
+    return 0;
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/common/libelf/libelf-dominfo.c b/xen/common/libelf/libelf-dominfo.c
index c569a48..523837f 100644
--- a/xen/common/libelf/libelf-dominfo.c
+++ b/xen/common/libelf/libelf-dominfo.c
@@ -341,6 +341,12 @@ static int elf_xen_note_check(struct elf_binary *elf,
         return 0;
     }
 
+    if ( elf_uval(elf, elf->ehdr, e_machine) == EM_ARM )
+    {
+         elf_msg(elf, "%s: Not bothering with notes on ARM\n", __FUNCTION__);
+         return 0;
+    }
+
     /* Check the contents of the Xen notes or guest string. */
     if ( ((strlen(parms->loader) == 0) ||
           strncmp(parms->loader, "generic", 7)) &&
diff --git a/xen/include/asm-arm/setup.h b/xen/include/asm-arm/setup.h
index c27d438..1dc3f97 100644
--- a/xen/include/asm-arm/setup.h
+++ b/xen/include/asm-arm/setup.h
@@ -5,6 +5,8 @@
 
 void arch_get_xen_caps(xen_capabilities_info_t *info);
 
+int construct_dom0(struct domain *d);
+
 #endif
 /*
  * Local variables:
diff --git a/xen/include/xen/libelf.h b/xen/include/xen/libelf.h
index 9de84eb..d799a80 100644
--- a/xen/include/xen/libelf.h
+++ b/xen/include/xen/libelf.h
@@ -23,7 +23,7 @@
 #ifndef __XEN_LIBELF_H__
 #define __XEN_LIBELF_H__
 
-#if defined(__i386__) || defined(__x86_64__) || defined(__ia64__)
+#if defined(__i386__) || defined(__x86_64__) || defined(__ia64__) || defined(__arm__)
 #define XEN_ELF_LITTLE_ENDIAN
 #else
 #error define architectural endianness
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 13:14:35 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 13: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.xensource.com>)
	id 1RZ0HN-0002Tg-Tz; Fri, 09 Dec 2011 13:14:21 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RZ0HL-0002OV-Ua
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 13:14:20 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1323436408!4727117!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMTkxNzY=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27282 invoked from network); 9 Dec 2011 13:13:30 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 13:13:30 -0000
X-IronPort-AV: E=Sophos;i="4.71,325,1320642000"; d="scan'208";a="173546292"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 08:13:28 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 08:13:27 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pB9DCpDw008248;
	Fri, 9 Dec 2011 05:13:11 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 9 Dec 2011 13:13:15 +0000
Message-ID: <1323436408-16335-12-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1112091208420.3517@kaball-desktop>
References: <alpine.DEB.2.00.1112091208420.3517@kaball-desktop>
MIME-Version: 1.0
Cc: keir.xen@gmail.com, Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, JBeulich@suse.com,
	Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v2 12/25] arm: domain
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Domain creation and destruction, vcpu initialization and destruction,
arch specific scheduling functions called by common code.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
---
 xen/arch/arm/domain.c        |  253 ++++++++++++++++++++++++++++++++++++++++++
 xen/include/asm-arm/domain.h |   43 +++++++
 2 files changed, 296 insertions(+), 0 deletions(-)
 create mode 100644 xen/arch/arm/domain.c
 create mode 100644 xen/include/asm-arm/domain.h

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
new file mode 100644
index 0000000..d706b5f
--- /dev/null
+++ b/xen/arch/arm/domain.c
@@ -0,0 +1,253 @@
+#include <xen/config.h>
+#include <xen/init.h>
+#include <xen/lib.h>
+#include <xen/sched.h>
+#include <xen/softirq.h>
+#include <xen/wait.h>
+#include <xen/errno.h>
+
+#include <asm/current.h>
+#include <asm/regs.h>
+#include <asm/p2m.h>
+#include <asm/irq.h>
+
+DEFINE_PER_CPU(struct vcpu *, curr_vcpu);
+
+static void continue_idle_domain(struct vcpu *v)
+{
+    reset_stack_and_jump(idle_loop);
+}
+
+static void continue_nonidle_domain(struct vcpu *v)
+{
+    /* check_wakeup_from_wait(); */
+    reset_stack_and_jump(return_from_trap);
+}
+
+void idle_loop(void)
+{
+    for ( ; ; )
+    {
+		/* TODO
+		   if ( cpu_is_offline(smp_processor_id()) )
+		   play_dead();
+		   (*pm_idle)();
+		   BUG();
+		*/
+        do_tasklet();
+        do_softirq();
+    }
+}
+
+static void ctxt_switch_from(struct vcpu *p)
+{
+
+}
+
+static void ctxt_switch_to(struct vcpu *n)
+{
+    p2m_load_VTTBR(n->domain);
+}
+
+static void __context_switch(void)
+{
+    struct cpu_user_regs *stack_regs = guest_cpu_user_regs();
+    unsigned int          cpu = smp_processor_id();
+    struct vcpu          *p = per_cpu(curr_vcpu, cpu);
+    struct vcpu          *n = current;
+
+    ASSERT(p != n);
+    ASSERT(cpumask_empty(n->vcpu_dirty_cpumask));
+
+    if ( !is_idle_vcpu(p) )
+    {
+        memcpy(&p->arch.user_regs, stack_regs, CTXT_SWITCH_STACK_BYTES);
+        ctxt_switch_from(p);
+    }
+
+    if ( !is_idle_vcpu(n) )
+    {
+        memcpy(stack_regs, &n->arch.user_regs, CTXT_SWITCH_STACK_BYTES);
+        ctxt_switch_to(n);
+    }
+
+    per_cpu(curr_vcpu, cpu) = n;
+
+}
+
+static void schedule_tail(struct vcpu *v)
+{
+    if ( is_idle_vcpu(v) )
+        continue_idle_domain(v);
+    else
+        continue_nonidle_domain(v);
+}
+
+void context_switch(struct vcpu *prev, struct vcpu *next)
+{
+    unsigned int cpu = smp_processor_id();
+
+    ASSERT(local_irq_is_enabled());
+
+    printk("context switch %d:%d%s -> %d:%d%s\n",
+           prev->domain->domain_id, prev->vcpu_id, is_idle_vcpu(prev) ? " (idle)" : "",
+           next->domain->domain_id, next->vcpu_id, is_idle_vcpu(next) ? " (idle)" : "");
+
+	/* TODO
+	   if (prev != next)
+	   update_runstate_area(prev);
+	*/
+
+    local_irq_disable();
+
+    set_current(next);
+
+    if ( (per_cpu(curr_vcpu, cpu) == next) ||
+         (is_idle_vcpu(next) && cpu_online(cpu)) )
+    {
+        local_irq_enable();
+    }
+    else
+    {
+        __context_switch();
+
+        /* Re-enable interrupts before restoring state which may fault. */
+        local_irq_enable();
+    }
+
+    context_saved(prev);
+
+	/* TODO
+	   if (prev != next)
+	   update_runstate_area(next);
+	*/
+
+    schedule_tail(next);
+    BUG();
+
+}
+
+void continue_running(struct vcpu *same)
+{
+    schedule_tail(same);
+    BUG();
+}
+
+int __sync_local_execstate(void)
+{
+    unsigned long flags;
+    int switch_required;
+
+    local_irq_save(flags);
+
+    switch_required = (this_cpu(curr_vcpu) != current);
+
+    if ( switch_required )
+    {
+        ASSERT(current == idle_vcpu[smp_processor_id()]);
+        __context_switch();
+    }
+
+    local_irq_restore(flags);
+
+    return switch_required;
+}
+
+void sync_local_execstate(void)
+{
+    (void)__sync_local_execstate();
+}
+
+void startup_cpu_idle_loop(void)
+{
+        struct vcpu *v = current;
+
+        ASSERT(is_idle_vcpu(v));
+		/* TODO
+		   cpumask_set_cpu(v->processor, v->domain->domain_dirty_cpumask);
+		   cpumask_set_cpu(v->processor, v->vcpu_dirty_cpumask);
+		*/
+
+        reset_stack_and_jump(idle_loop);
+}
+
+struct domain *alloc_domain_struct(void)
+{
+    struct domain *d;
+    BUILD_BUG_ON(sizeof(*d) > PAGE_SIZE);
+    d = alloc_xenheap_pages(0, 0);
+    if ( d != NULL )
+        clear_page(d);
+    return d;
+}
+
+void free_domain_struct(struct domain *d)
+{
+    free_xenheap_page(d);
+}
+
+void dump_pageframe_info(struct domain *d)
+{
+
+}
+
+struct vcpu *alloc_vcpu_struct(void)
+{
+    struct vcpu *v;
+    BUILD_BUG_ON(sizeof(*v) > PAGE_SIZE);
+    v = alloc_xenheap_pages(0, 0);
+    if ( v != NULL )
+        clear_page(v);
+    return v;
+}
+
+void free_vcpu_struct(struct vcpu *v)
+{
+    free_xenheap_page(v);
+}
+
+int vcpu_initialise(struct vcpu *v)
+{
+    int rc = 0;
+
+    return rc;
+}
+
+void vcpu_destroy(struct vcpu *v)
+{
+
+}
+
+int arch_domain_create(struct domain *d, unsigned int domcr_flags)
+{
+    int rc;
+
+    d->max_vcpus = 8;
+
+    rc = 0;
+fail:
+    return rc;
+}
+
+void arch_domain_destroy(struct domain *d)
+{
+    /* p2m_destroy */
+    /* domain_vgic_destroy */
+}
+
+void arch_dump_domain_info(struct domain *d)
+{
+}
+
+void arch_dump_vcpu_info(struct vcpu *v)
+{
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
new file mode 100644
index 0000000..c226bdf
--- /dev/null
+++ b/xen/include/asm-arm/domain.h
@@ -0,0 +1,43 @@
+#ifndef __ASM_DOMAIN_H__
+#define __ASM_DOMAIN_H__
+
+#include <xen/config.h>
+#include <xen/cache.h>
+#include <asm/page.h>
+#include <asm/p2m.h>
+
+struct pending_irq
+{
+    int irq;
+    struct irq_desc *desc; /* only set it the irq corresponds to a physical irq */
+    uint8_t priority;
+    struct list_head link;
+};
+
+struct arch_domain
+{
+}  __cacheline_aligned;
+
+struct arch_vcpu
+{
+    struct cpu_user_regs user_regs;
+
+    uint32_t sctlr;
+    uint32_t ttbr0, ttbr1, ttbcr;
+
+}  __cacheline_aligned;
+
+void vcpu_show_execution_state(struct vcpu *);
+void vcpu_show_registers(const struct vcpu *);
+
+#endif /* __ASM_DOMAIN_H__ */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 13:14:35 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 13: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.xensource.com>)
	id 1RZ0HN-0002Tg-Tz; Fri, 09 Dec 2011 13:14:21 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RZ0HL-0002OV-Ua
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 13:14:20 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1323436408!4727117!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMTkxNzY=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27282 invoked from network); 9 Dec 2011 13:13:30 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 13:13:30 -0000
X-IronPort-AV: E=Sophos;i="4.71,325,1320642000"; d="scan'208";a="173546292"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 08:13:28 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 08:13:27 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pB9DCpDw008248;
	Fri, 9 Dec 2011 05:13:11 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 9 Dec 2011 13:13:15 +0000
Message-ID: <1323436408-16335-12-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1112091208420.3517@kaball-desktop>
References: <alpine.DEB.2.00.1112091208420.3517@kaball-desktop>
MIME-Version: 1.0
Cc: keir.xen@gmail.com, Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, JBeulich@suse.com,
	Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v2 12/25] arm: domain
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Domain creation and destruction, vcpu initialization and destruction,
arch specific scheduling functions called by common code.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
---
 xen/arch/arm/domain.c        |  253 ++++++++++++++++++++++++++++++++++++++++++
 xen/include/asm-arm/domain.h |   43 +++++++
 2 files changed, 296 insertions(+), 0 deletions(-)
 create mode 100644 xen/arch/arm/domain.c
 create mode 100644 xen/include/asm-arm/domain.h

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
new file mode 100644
index 0000000..d706b5f
--- /dev/null
+++ b/xen/arch/arm/domain.c
@@ -0,0 +1,253 @@
+#include <xen/config.h>
+#include <xen/init.h>
+#include <xen/lib.h>
+#include <xen/sched.h>
+#include <xen/softirq.h>
+#include <xen/wait.h>
+#include <xen/errno.h>
+
+#include <asm/current.h>
+#include <asm/regs.h>
+#include <asm/p2m.h>
+#include <asm/irq.h>
+
+DEFINE_PER_CPU(struct vcpu *, curr_vcpu);
+
+static void continue_idle_domain(struct vcpu *v)
+{
+    reset_stack_and_jump(idle_loop);
+}
+
+static void continue_nonidle_domain(struct vcpu *v)
+{
+    /* check_wakeup_from_wait(); */
+    reset_stack_and_jump(return_from_trap);
+}
+
+void idle_loop(void)
+{
+    for ( ; ; )
+    {
+		/* TODO
+		   if ( cpu_is_offline(smp_processor_id()) )
+		   play_dead();
+		   (*pm_idle)();
+		   BUG();
+		*/
+        do_tasklet();
+        do_softirq();
+    }
+}
+
+static void ctxt_switch_from(struct vcpu *p)
+{
+
+}
+
+static void ctxt_switch_to(struct vcpu *n)
+{
+    p2m_load_VTTBR(n->domain);
+}
+
+static void __context_switch(void)
+{
+    struct cpu_user_regs *stack_regs = guest_cpu_user_regs();
+    unsigned int          cpu = smp_processor_id();
+    struct vcpu          *p = per_cpu(curr_vcpu, cpu);
+    struct vcpu          *n = current;
+
+    ASSERT(p != n);
+    ASSERT(cpumask_empty(n->vcpu_dirty_cpumask));
+
+    if ( !is_idle_vcpu(p) )
+    {
+        memcpy(&p->arch.user_regs, stack_regs, CTXT_SWITCH_STACK_BYTES);
+        ctxt_switch_from(p);
+    }
+
+    if ( !is_idle_vcpu(n) )
+    {
+        memcpy(stack_regs, &n->arch.user_regs, CTXT_SWITCH_STACK_BYTES);
+        ctxt_switch_to(n);
+    }
+
+    per_cpu(curr_vcpu, cpu) = n;
+
+}
+
+static void schedule_tail(struct vcpu *v)
+{
+    if ( is_idle_vcpu(v) )
+        continue_idle_domain(v);
+    else
+        continue_nonidle_domain(v);
+}
+
+void context_switch(struct vcpu *prev, struct vcpu *next)
+{
+    unsigned int cpu = smp_processor_id();
+
+    ASSERT(local_irq_is_enabled());
+
+    printk("context switch %d:%d%s -> %d:%d%s\n",
+           prev->domain->domain_id, prev->vcpu_id, is_idle_vcpu(prev) ? " (idle)" : "",
+           next->domain->domain_id, next->vcpu_id, is_idle_vcpu(next) ? " (idle)" : "");
+
+	/* TODO
+	   if (prev != next)
+	   update_runstate_area(prev);
+	*/
+
+    local_irq_disable();
+
+    set_current(next);
+
+    if ( (per_cpu(curr_vcpu, cpu) == next) ||
+         (is_idle_vcpu(next) && cpu_online(cpu)) )
+    {
+        local_irq_enable();
+    }
+    else
+    {
+        __context_switch();
+
+        /* Re-enable interrupts before restoring state which may fault. */
+        local_irq_enable();
+    }
+
+    context_saved(prev);
+
+	/* TODO
+	   if (prev != next)
+	   update_runstate_area(next);
+	*/
+
+    schedule_tail(next);
+    BUG();
+
+}
+
+void continue_running(struct vcpu *same)
+{
+    schedule_tail(same);
+    BUG();
+}
+
+int __sync_local_execstate(void)
+{
+    unsigned long flags;
+    int switch_required;
+
+    local_irq_save(flags);
+
+    switch_required = (this_cpu(curr_vcpu) != current);
+
+    if ( switch_required )
+    {
+        ASSERT(current == idle_vcpu[smp_processor_id()]);
+        __context_switch();
+    }
+
+    local_irq_restore(flags);
+
+    return switch_required;
+}
+
+void sync_local_execstate(void)
+{
+    (void)__sync_local_execstate();
+}
+
+void startup_cpu_idle_loop(void)
+{
+        struct vcpu *v = current;
+
+        ASSERT(is_idle_vcpu(v));
+		/* TODO
+		   cpumask_set_cpu(v->processor, v->domain->domain_dirty_cpumask);
+		   cpumask_set_cpu(v->processor, v->vcpu_dirty_cpumask);
+		*/
+
+        reset_stack_and_jump(idle_loop);
+}
+
+struct domain *alloc_domain_struct(void)
+{
+    struct domain *d;
+    BUILD_BUG_ON(sizeof(*d) > PAGE_SIZE);
+    d = alloc_xenheap_pages(0, 0);
+    if ( d != NULL )
+        clear_page(d);
+    return d;
+}
+
+void free_domain_struct(struct domain *d)
+{
+    free_xenheap_page(d);
+}
+
+void dump_pageframe_info(struct domain *d)
+{
+
+}
+
+struct vcpu *alloc_vcpu_struct(void)
+{
+    struct vcpu *v;
+    BUILD_BUG_ON(sizeof(*v) > PAGE_SIZE);
+    v = alloc_xenheap_pages(0, 0);
+    if ( v != NULL )
+        clear_page(v);
+    return v;
+}
+
+void free_vcpu_struct(struct vcpu *v)
+{
+    free_xenheap_page(v);
+}
+
+int vcpu_initialise(struct vcpu *v)
+{
+    int rc = 0;
+
+    return rc;
+}
+
+void vcpu_destroy(struct vcpu *v)
+{
+
+}
+
+int arch_domain_create(struct domain *d, unsigned int domcr_flags)
+{
+    int rc;
+
+    d->max_vcpus = 8;
+
+    rc = 0;
+fail:
+    return rc;
+}
+
+void arch_domain_destroy(struct domain *d)
+{
+    /* p2m_destroy */
+    /* domain_vgic_destroy */
+}
+
+void arch_dump_domain_info(struct domain *d)
+{
+}
+
+void arch_dump_vcpu_info(struct vcpu *v)
+{
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
new file mode 100644
index 0000000..c226bdf
--- /dev/null
+++ b/xen/include/asm-arm/domain.h
@@ -0,0 +1,43 @@
+#ifndef __ASM_DOMAIN_H__
+#define __ASM_DOMAIN_H__
+
+#include <xen/config.h>
+#include <xen/cache.h>
+#include <asm/page.h>
+#include <asm/p2m.h>
+
+struct pending_irq
+{
+    int irq;
+    struct irq_desc *desc; /* only set it the irq corresponds to a physical irq */
+    uint8_t priority;
+    struct list_head link;
+};
+
+struct arch_domain
+{
+}  __cacheline_aligned;
+
+struct arch_vcpu
+{
+    struct cpu_user_regs user_regs;
+
+    uint32_t sctlr;
+    uint32_t ttbr0, ttbr1, ttbcr;
+
+}  __cacheline_aligned;
+
+void vcpu_show_execution_state(struct vcpu *);
+void vcpu_show_registers(const struct vcpu *);
+
+#endif /* __ASM_DOMAIN_H__ */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 13:14:43 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 13:14:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZ0HZ-0002ei-NK; Fri, 09 Dec 2011 13:14:33 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RZ0HY-0002X8-Bx
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 13:14:32 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1323436421!7564857!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMTkxNzY=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18160 invoked from network); 9 Dec 2011 13:13:43 -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;
	9 Dec 2011 13:13:43 -0000
X-IronPort-AV: E=Sophos;i="4.71,325,1320642000"; d="scan'208";a="173546328"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 08:13:41 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 08:13:41 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pB9DCpE6008248;
	Fri, 9 Dec 2011 05:13:24 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 9 Dec 2011 13:13:23 +0000
Message-ID: <1323436408-16335-20-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1112091208420.3517@kaball-desktop>
References: <alpine.DEB.2.00.1112091208420.3517@kaball-desktop>
MIME-Version: 1.0
Cc: keir.xen@gmail.com, Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, JBeulich@suse.com,
	Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v2 20/25] arm: shutdown, smp and smpboot
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Dummy implementation of machine_* and smp_*

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
---
 xen/arch/arm/shutdown.c |   23 +++++++++++++++++++++
 xen/arch/arm/smp.c      |   29 +++++++++++++++++++++++++++
 xen/arch/arm/smpboot.c  |   50 +++++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 102 insertions(+), 0 deletions(-)
 create mode 100644 xen/arch/arm/shutdown.c
 create mode 100644 xen/arch/arm/smp.c
 create mode 100644 xen/arch/arm/smpboot.c

diff --git a/xen/arch/arm/shutdown.c b/xen/arch/arm/shutdown.c
new file mode 100644
index 0000000..2e35d2d
--- /dev/null
+++ b/xen/arch/arm/shutdown.c
@@ -0,0 +1,23 @@
+#include <xen/config.h>
+#include <xen/lib.h>
+
+void machine_halt(void)
+{
+        /* TODO: halt */
+        while(1) ;
+}
+
+void machine_restart(unsigned int delay_millisecs)
+{
+        /* TODO: restart */
+        printk("Cannot restart yet\n");
+        while(1);
+}
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/arch/arm/smp.c b/xen/arch/arm/smp.c
new file mode 100644
index 0000000..677c71a
--- /dev/null
+++ b/xen/arch/arm/smp.c
@@ -0,0 +1,29 @@
+#include <xen/config.h>
+#include <asm/smp.h>
+
+void smp_call_function(
+    void (*func) (void *info),
+    void *info,
+    int wait)
+{
+	/* TODO: No SMP just now, does not include self so nothing to do.
+	   cpumask_t allbutself = cpu_online_map;
+	   cpu_clear(smp_processor_id(), allbutself);
+	   on_selected_cpus(&allbutself, func, info, wait);
+	*/
+}
+void smp_send_event_check_mask(const cpumask_t *mask)
+{
+    /* TODO: No SMP just now, does not include self so nothing to do.
+	   send_IPI_mask(mask, EVENT_CHECK_VECTOR);
+	*/
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c
new file mode 100644
index 0000000..8287473
--- /dev/null
+++ b/xen/arch/arm/smpboot.c
@@ -0,0 +1,50 @@
+/*
+ * xen/arch/arm/smpboot.c
+ *
+ * Dummy smpboot support
+ *
+ * Copyright (c) 2011 Citrix Systems.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include <xen/cpumask.h>
+#include <xen/smp.h>
+#include <xen/init.h>
+
+cpumask_t cpu_online_map;
+EXPORT_SYMBOL(cpu_online_map);
+cpumask_t cpu_present_map;
+EXPORT_SYMBOL(cpu_online_map);
+cpumask_t cpu_possible_map;
+EXPORT_SYMBOL(cpu_possible_map);
+
+void __init
+smp_prepare_cpus (unsigned int max_cpus)
+{
+        set_processor_id(0); /* needed early, for smp_processor_id() */
+
+        cpumask_clear(&cpu_online_map);
+        cpumask_clear(&cpu_present_map);
+        cpumask_clear(&cpu_possible_map);
+        cpumask_set_cpu(0, &cpu_online_map);
+        cpumask_set_cpu(0, &cpu_present_map);
+        cpumask_set_cpu(0, &cpu_possible_map);
+        return;
+}
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 13:14:43 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 13:14:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZ0H7-0002IH-IT; Fri, 09 Dec 2011 13:14:05 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RZ0H5-0002Gy-RA
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 13:14:04 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1323436346!56653758!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDQ0MTg=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7214 invoked from network); 9 Dec 2011 13:12:29 -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 2011 13:12:29 -0000
X-IronPort-AV: E=Sophos;i="4.71,325,1320642000"; d="scan'208";a="19808898"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 08:13:15 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 08:13:15 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pB9DCpDs008248;
	Fri, 9 Dec 2011 05:13:04 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 9 Dec 2011 13:13:11 +0000
Message-ID: <1323436408-16335-8-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1112091208420.3517@kaball-desktop>
References: <alpine.DEB.2.00.1112091208420.3517@kaball-desktop>
MIME-Version: 1.0
Cc: keir.xen@gmail.com, Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian.Campbell@citrix.com, JBeulich@suse.com, Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v2 08/25] arm: compile tmem
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Include few missing header files; fix the definition of cli_put_page;
introduce defined(CONFIG_ARM) where required.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen/common/tmem.c     |    3 ++-
 xen/common/tmem_xen.c |    6 ++++--
 2 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/xen/common/tmem.c b/xen/common/tmem.c
index 115465b..dd276df 100644
--- a/xen/common/tmem.c
+++ b/xen/common/tmem.c
@@ -22,6 +22,7 @@
 #include <xen/rbtree.h>
 #include <xen/radix-tree.h>
 #include <xen/list.h>
+#include <xen/init.h>
 
 #define EXPORT /* indicates code other modules are dependent upon */
 #define FORWARD
@@ -49,7 +50,7 @@
 #define INVERT_SENTINEL(_x,_y) _x->sentinel = ~_y##_SENTINEL
 #define ASSERT_SENTINEL(_x,_y) \
     ASSERT(_x->sentinel != ~_y##_SENTINEL);ASSERT(_x->sentinel == _y##_SENTINEL)
-#ifdef __i386__
+#if defined(__i386__) || defined(CONFIG_ARM)
 #define POOL_SENTINEL 0x87658765
 #define OBJ_SENTINEL 0x12345678
 #define OBJNODE_SENTINEL 0xfedcba09
diff --git a/xen/common/tmem_xen.c b/xen/common/tmem_xen.c
index c094095..9b2a22c 100644
--- a/xen/common/tmem_xen.c
+++ b/xen/common/tmem_xen.c
@@ -12,6 +12,8 @@
 #include <xen/paging.h>
 #include <xen/domain_page.h>
 #include <xen/cpu.h>
+#include <xen/init.h>
+#include <asm/p2m.h>
 
 #define EXPORT /* indicates code other modules are dependent upon */
 
@@ -87,7 +89,7 @@ void tmh_copy_page(char *to, char*from)
 #endif
 }
 
-#ifdef __ia64__
+#if defined(__ia64__) || defined (CONFIG_ARM)
 static inline void *cli_get_page(tmem_cli_mfn_t cmfn, unsigned long *pcli_mfn,
                                  pfp_t **pcli_pfp, bool_t cli_write)
 {
@@ -95,7 +97,7 @@ static inline void *cli_get_page(tmem_cli_mfn_t cmfn, unsigned long *pcli_mfn,
     return NULL;
 }
 
-static inline void cli_put_page(void *cli_va, pfp_t *cli_pfp,
+static inline void cli_put_page(tmem_cli_mfn_t cmfn, void *cli_va, pfp_t *cli_pfp,
                                 unsigned long cli_mfn, bool_t mark_dirty)
 {
     ASSERT(0);
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 13:14:43 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 13:14:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZ0HZ-0002ei-NK; Fri, 09 Dec 2011 13:14:33 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RZ0HY-0002X8-Bx
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 13:14:32 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1323436421!7564857!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMTkxNzY=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18160 invoked from network); 9 Dec 2011 13:13:43 -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;
	9 Dec 2011 13:13:43 -0000
X-IronPort-AV: E=Sophos;i="4.71,325,1320642000"; d="scan'208";a="173546328"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 08:13:41 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 08:13:41 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pB9DCpE6008248;
	Fri, 9 Dec 2011 05:13:24 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 9 Dec 2011 13:13:23 +0000
Message-ID: <1323436408-16335-20-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1112091208420.3517@kaball-desktop>
References: <alpine.DEB.2.00.1112091208420.3517@kaball-desktop>
MIME-Version: 1.0
Cc: keir.xen@gmail.com, Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, JBeulich@suse.com,
	Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v2 20/25] arm: shutdown, smp and smpboot
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Dummy implementation of machine_* and smp_*

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
---
 xen/arch/arm/shutdown.c |   23 +++++++++++++++++++++
 xen/arch/arm/smp.c      |   29 +++++++++++++++++++++++++++
 xen/arch/arm/smpboot.c  |   50 +++++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 102 insertions(+), 0 deletions(-)
 create mode 100644 xen/arch/arm/shutdown.c
 create mode 100644 xen/arch/arm/smp.c
 create mode 100644 xen/arch/arm/smpboot.c

diff --git a/xen/arch/arm/shutdown.c b/xen/arch/arm/shutdown.c
new file mode 100644
index 0000000..2e35d2d
--- /dev/null
+++ b/xen/arch/arm/shutdown.c
@@ -0,0 +1,23 @@
+#include <xen/config.h>
+#include <xen/lib.h>
+
+void machine_halt(void)
+{
+        /* TODO: halt */
+        while(1) ;
+}
+
+void machine_restart(unsigned int delay_millisecs)
+{
+        /* TODO: restart */
+        printk("Cannot restart yet\n");
+        while(1);
+}
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/arch/arm/smp.c b/xen/arch/arm/smp.c
new file mode 100644
index 0000000..677c71a
--- /dev/null
+++ b/xen/arch/arm/smp.c
@@ -0,0 +1,29 @@
+#include <xen/config.h>
+#include <asm/smp.h>
+
+void smp_call_function(
+    void (*func) (void *info),
+    void *info,
+    int wait)
+{
+	/* TODO: No SMP just now, does not include self so nothing to do.
+	   cpumask_t allbutself = cpu_online_map;
+	   cpu_clear(smp_processor_id(), allbutself);
+	   on_selected_cpus(&allbutself, func, info, wait);
+	*/
+}
+void smp_send_event_check_mask(const cpumask_t *mask)
+{
+    /* TODO: No SMP just now, does not include self so nothing to do.
+	   send_IPI_mask(mask, EVENT_CHECK_VECTOR);
+	*/
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c
new file mode 100644
index 0000000..8287473
--- /dev/null
+++ b/xen/arch/arm/smpboot.c
@@ -0,0 +1,50 @@
+/*
+ * xen/arch/arm/smpboot.c
+ *
+ * Dummy smpboot support
+ *
+ * Copyright (c) 2011 Citrix Systems.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include <xen/cpumask.h>
+#include <xen/smp.h>
+#include <xen/init.h>
+
+cpumask_t cpu_online_map;
+EXPORT_SYMBOL(cpu_online_map);
+cpumask_t cpu_present_map;
+EXPORT_SYMBOL(cpu_online_map);
+cpumask_t cpu_possible_map;
+EXPORT_SYMBOL(cpu_possible_map);
+
+void __init
+smp_prepare_cpus (unsigned int max_cpus)
+{
+        set_processor_id(0); /* needed early, for smp_processor_id() */
+
+        cpumask_clear(&cpu_online_map);
+        cpumask_clear(&cpu_present_map);
+        cpumask_clear(&cpu_possible_map);
+        cpumask_set_cpu(0, &cpu_online_map);
+        cpumask_set_cpu(0, &cpu_present_map);
+        cpumask_set_cpu(0, &cpu_possible_map);
+        return;
+}
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 13:14:43 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 13:14:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZ0H7-0002IH-IT; Fri, 09 Dec 2011 13:14:05 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RZ0H5-0002Gy-RA
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 13:14:04 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1323436346!56653758!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDQ0MTg=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7214 invoked from network); 9 Dec 2011 13:12:29 -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 2011 13:12:29 -0000
X-IronPort-AV: E=Sophos;i="4.71,325,1320642000"; d="scan'208";a="19808898"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 08:13:15 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 08:13:15 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pB9DCpDs008248;
	Fri, 9 Dec 2011 05:13:04 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 9 Dec 2011 13:13:11 +0000
Message-ID: <1323436408-16335-8-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1112091208420.3517@kaball-desktop>
References: <alpine.DEB.2.00.1112091208420.3517@kaball-desktop>
MIME-Version: 1.0
Cc: keir.xen@gmail.com, Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian.Campbell@citrix.com, JBeulich@suse.com, Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v2 08/25] arm: compile tmem
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Include few missing header files; fix the definition of cli_put_page;
introduce defined(CONFIG_ARM) where required.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen/common/tmem.c     |    3 ++-
 xen/common/tmem_xen.c |    6 ++++--
 2 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/xen/common/tmem.c b/xen/common/tmem.c
index 115465b..dd276df 100644
--- a/xen/common/tmem.c
+++ b/xen/common/tmem.c
@@ -22,6 +22,7 @@
 #include <xen/rbtree.h>
 #include <xen/radix-tree.h>
 #include <xen/list.h>
+#include <xen/init.h>
 
 #define EXPORT /* indicates code other modules are dependent upon */
 #define FORWARD
@@ -49,7 +50,7 @@
 #define INVERT_SENTINEL(_x,_y) _x->sentinel = ~_y##_SENTINEL
 #define ASSERT_SENTINEL(_x,_y) \
     ASSERT(_x->sentinel != ~_y##_SENTINEL);ASSERT(_x->sentinel == _y##_SENTINEL)
-#ifdef __i386__
+#if defined(__i386__) || defined(CONFIG_ARM)
 #define POOL_SENTINEL 0x87658765
 #define OBJ_SENTINEL 0x12345678
 #define OBJNODE_SENTINEL 0xfedcba09
diff --git a/xen/common/tmem_xen.c b/xen/common/tmem_xen.c
index c094095..9b2a22c 100644
--- a/xen/common/tmem_xen.c
+++ b/xen/common/tmem_xen.c
@@ -12,6 +12,8 @@
 #include <xen/paging.h>
 #include <xen/domain_page.h>
 #include <xen/cpu.h>
+#include <xen/init.h>
+#include <asm/p2m.h>
 
 #define EXPORT /* indicates code other modules are dependent upon */
 
@@ -87,7 +89,7 @@ void tmh_copy_page(char *to, char*from)
 #endif
 }
 
-#ifdef __ia64__
+#if defined(__ia64__) || defined (CONFIG_ARM)
 static inline void *cli_get_page(tmem_cli_mfn_t cmfn, unsigned long *pcli_mfn,
                                  pfp_t **pcli_pfp, bool_t cli_write)
 {
@@ -95,7 +97,7 @@ static inline void *cli_get_page(tmem_cli_mfn_t cmfn, unsigned long *pcli_mfn,
     return NULL;
 }
 
-static inline void cli_put_page(void *cli_va, pfp_t *cli_pfp,
+static inline void cli_put_page(tmem_cli_mfn_t cmfn, void *cli_va, pfp_t *cli_pfp,
                                 unsigned long cli_mfn, bool_t mark_dirty)
 {
     ASSERT(0);
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 13:14:44 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 13:14:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZ0Hd-0002kv-VP; Fri, 09 Dec 2011 13:14:37 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RZ0Hb-0002ah-SK
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 13:14:36 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1323436424!6039693!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMTkxNzY=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23214 invoked from network); 9 Dec 2011 13:13:46 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 13:13:46 -0000
X-IronPort-AV: E=Sophos;i="4.71,325,1320642000"; d="scan'208";a="173546334"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 08:13:43 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 08:13:43 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pB9DCpEA008248;
	Fri, 9 Dec 2011 05:13:31 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 9 Dec 2011 13:13:27 +0000
Message-ID: <1323436408-16335-24-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1112091208420.3517@kaball-desktop>
References: <alpine.DEB.2.00.1112091208420.3517@kaball-desktop>
MIME-Version: 1.0
Cc: keir.xen@gmail.com, Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, JBeulich@suse.com,
	Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v2 24/25] arm: vtimer
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Emulation of the generic timer kernel registers.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
---
 xen/arch/arm/domain.c        |    4 +
 xen/arch/arm/traps.c         |    4 +-
 xen/arch/arm/vtimer.c        |  148 ++++++++++++++++++++++++++++++++++++++++++
 xen/arch/arm/vtimer.h        |   35 ++++++++++
 xen/include/asm-arm/domain.h |    7 ++
 5 files changed, 196 insertions(+), 2 deletions(-)
 create mode 100644 xen/arch/arm/vtimer.c
 create mode 100644 xen/arch/arm/vtimer.h

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 7e681ab..70f71c3 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -12,6 +12,7 @@
 #include <asm/irq.h>
 
 #include "gic.h"
+#include "vtimer.h"
 
 DEFINE_PER_CPU(struct vcpu *, curr_vcpu);
 
@@ -215,6 +216,9 @@ int vcpu_initialise(struct vcpu *v)
     if ( (rc = vcpu_vgic_init(v)) != 0 )
         return rc;
 
+    if ( (rc = vcpu_vtimer_init(v)) != 0 )
+        return rc;
+
     return rc;
 }
 
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 4346dd7..395d0af 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -468,7 +468,7 @@ static void do_cp15_32(struct cpu_user_regs *regs,
         break;
     case HSR_CPREG32(CNTP_CTL):
     case HSR_CPREG32(CNTP_TVAL):
-        /* emulate timer */
+        BUG_ON(!vtimer_emulate(regs, hsr));
         break;
     default:
         printk("%s p15, %d, r%d, cr%d, cr%d, %d @ %#08x\n",
@@ -498,7 +498,7 @@ static void do_cp15_64(struct cpu_user_regs *regs,
     switch ( hsr.bits & HSR_CP64_REGS_MASK )
     {
     case HSR_CPREG64(CNTPCT):
-        /* emulate timer */
+        BUG_ON(!vtimer_emulate(regs, hsr));
         break;
     default:
         printk("%s p15, %d, r%d, r%d, cr%d @ %#08x\n",
diff --git a/xen/arch/arm/vtimer.c b/xen/arch/arm/vtimer.c
new file mode 100644
index 0000000..3ebf5b1
--- /dev/null
+++ b/xen/arch/arm/vtimer.c
@@ -0,0 +1,148 @@
+/*
+ * xen/arch/arm/vtimer.c
+ *
+ * ARM Virtual Timer emulation support
+ *
+ * Ian Campbell <ian.campbell@citrix.com>
+ * Copyright (c) 2011 Citrix Systems.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include <xen/config.h>
+#include <xen/lib.h>
+#include <xen/timer.h>
+#include <xen/sched.h>
+#include "gic.h"
+
+extern s_time_t ticks_to_ns(uint64_t ticks);
+extern uint64_t ns_to_ticks(s_time_t ns);
+
+static void vtimer_expired(void *data)
+{
+    struct vcpu *v = data;
+    v->arch.vtimer.ctl |= CNTx_CTL_PENDING;
+    v->arch.vtimer.ctl &= ~CNTx_CTL_MASK;
+    vgic_vcpu_inject_irq(v, 30, 1);
+}
+
+int vcpu_vtimer_init(struct vcpu *v)
+{
+    init_timer(&v->arch.vtimer.timer,
+               vtimer_expired, v,
+               smp_processor_id());
+    v->arch.vtimer.ctl = 0;
+    v->arch.vtimer.offset = NOW();
+    v->arch.vtimer.cval = NOW();
+    return 0;
+}
+
+static int vtimer_emulate_32(struct cpu_user_regs *regs, union hsr hsr)
+{
+    struct vcpu *v = current;
+    struct hsr_cp32 cp32 = hsr.cp32;
+    uint32_t *r = &regs->r0 + cp32.reg;
+    s_time_t now;
+
+    switch ( hsr.bits & HSR_CP32_REGS_MASK )
+    {
+    case HSR_CPREG32(CNTP_CTL):
+        if ( cp32.read )
+        {
+            *r = v->arch.vtimer.ctl;
+        }
+        else
+        {
+            v->arch.vtimer.ctl = *r;
+
+            if ( v->arch.vtimer.ctl & CNTx_CTL_ENABLE )
+            {
+                set_timer(&v->arch.vtimer.timer,
+                          v->arch.vtimer.cval + v->arch.vtimer.offset);
+            }
+            else
+                stop_timer(&v->arch.vtimer.timer);
+        }
+
+        return 1;
+
+    case HSR_CPREG32(CNTP_TVAL):
+        now = NOW() - v->arch.vtimer.offset;
+        if ( cp32.read )
+        {
+            *r = (uint32_t)(ns_to_ticks(v->arch.vtimer.cval - now) & 0xffffffffull);
+        }
+        else
+	{
+            v->arch.vtimer.cval = now + ticks_to_ns(*r);
+	    if ( v->arch.vtimer.ctl & CNTx_CTL_ENABLE )
+            {
+                set_timer(&v->arch.vtimer.timer,
+                          v->arch.vtimer.cval + v->arch.vtimer.offset);
+            }
+        }
+
+        return 1;
+
+    default:
+        return 0;
+    }
+}
+
+static int vtimer_emulate_64(struct cpu_user_regs *regs, union hsr hsr)
+{
+    struct vcpu *v = current;
+    struct hsr_cp64 cp64 = hsr.cp64;
+    uint32_t *r1 = &regs->r0 + cp64.reg1;
+    uint32_t *r2 = &regs->r0 + cp64.reg2;
+    s_time_t now;
+
+    switch ( hsr.bits & HSR_CP64_REGS_MASK )
+    {
+    case HSR_CPREG64(CNTPCT):
+        if ( cp64.read )
+        {
+            now = NOW() - v->arch.vtimer.offset;
+            *r1 = (uint32_t)(now & 0xffffffff);
+            *r2 = (uint32_t)(now >> 32);
+            return 1;
+        }
+        else
+        {
+            printk("READ from R/O CNTPCT\n");
+            return 0;
+        }
+
+    default:
+        return 0;
+    }
+}
+
+int vtimer_emulate(struct cpu_user_regs *regs, union hsr hsr)
+{
+    switch (hsr.ec) {
+    case HSR_EC_CP15_32:
+        return vtimer_emulate_32(regs, hsr);
+    case HSR_EC_CP15_64:
+        return vtimer_emulate_64(regs, hsr);
+    default:
+        return 0;
+    }
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/arch/arm/vtimer.h b/xen/arch/arm/vtimer.h
new file mode 100644
index 0000000..d87bb25
--- /dev/null
+++ b/xen/arch/arm/vtimer.h
@@ -0,0 +1,35 @@
+/*
+ * xen/arch/arm/vtimer.h
+ *
+ * ARM Virtual Timer emulation support
+ *
+ * Ian Campbell <ian.campbell@citrix.com>
+ * Copyright (c) 2011 Citrix Systems.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#ifndef __ARCH_ARM_VTIMER_H__
+#define __ARCH_ARM_VTIMER_H__
+
+extern int vcpu_vtimer_init(struct vcpu *v);
+extern int vtimer_emulate(struct cpu_user_regs *regs, union hsr hsr);
+
+#endif
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
index 2cd0bd3..3372d14 100644
--- a/xen/include/asm-arm/domain.h
+++ b/xen/include/asm-arm/domain.h
@@ -57,6 +57,13 @@ struct arch_vcpu
         struct list_head inflight_irqs;
         spinlock_t lock;
     } vgic;
+
+    struct {
+        struct timer timer;
+        uint32_t ctl;
+        s_time_t offset;
+        s_time_t cval;
+    } vtimer;
 }  __cacheline_aligned;
 
 void vcpu_show_execution_state(struct vcpu *);
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 13:14:44 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 13:14:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZ0Hd-0002kv-VP; Fri, 09 Dec 2011 13:14:37 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RZ0Hb-0002ah-SK
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 13:14:36 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1323436424!6039693!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMTkxNzY=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23214 invoked from network); 9 Dec 2011 13:13:46 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 13:13:46 -0000
X-IronPort-AV: E=Sophos;i="4.71,325,1320642000"; d="scan'208";a="173546334"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 08:13:43 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 08:13:43 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pB9DCpEA008248;
	Fri, 9 Dec 2011 05:13:31 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 9 Dec 2011 13:13:27 +0000
Message-ID: <1323436408-16335-24-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1112091208420.3517@kaball-desktop>
References: <alpine.DEB.2.00.1112091208420.3517@kaball-desktop>
MIME-Version: 1.0
Cc: keir.xen@gmail.com, Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, JBeulich@suse.com,
	Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v2 24/25] arm: vtimer
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Emulation of the generic timer kernel registers.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
---
 xen/arch/arm/domain.c        |    4 +
 xen/arch/arm/traps.c         |    4 +-
 xen/arch/arm/vtimer.c        |  148 ++++++++++++++++++++++++++++++++++++++++++
 xen/arch/arm/vtimer.h        |   35 ++++++++++
 xen/include/asm-arm/domain.h |    7 ++
 5 files changed, 196 insertions(+), 2 deletions(-)
 create mode 100644 xen/arch/arm/vtimer.c
 create mode 100644 xen/arch/arm/vtimer.h

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 7e681ab..70f71c3 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -12,6 +12,7 @@
 #include <asm/irq.h>
 
 #include "gic.h"
+#include "vtimer.h"
 
 DEFINE_PER_CPU(struct vcpu *, curr_vcpu);
 
@@ -215,6 +216,9 @@ int vcpu_initialise(struct vcpu *v)
     if ( (rc = vcpu_vgic_init(v)) != 0 )
         return rc;
 
+    if ( (rc = vcpu_vtimer_init(v)) != 0 )
+        return rc;
+
     return rc;
 }
 
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 4346dd7..395d0af 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -468,7 +468,7 @@ static void do_cp15_32(struct cpu_user_regs *regs,
         break;
     case HSR_CPREG32(CNTP_CTL):
     case HSR_CPREG32(CNTP_TVAL):
-        /* emulate timer */
+        BUG_ON(!vtimer_emulate(regs, hsr));
         break;
     default:
         printk("%s p15, %d, r%d, cr%d, cr%d, %d @ %#08x\n",
@@ -498,7 +498,7 @@ static void do_cp15_64(struct cpu_user_regs *regs,
     switch ( hsr.bits & HSR_CP64_REGS_MASK )
     {
     case HSR_CPREG64(CNTPCT):
-        /* emulate timer */
+        BUG_ON(!vtimer_emulate(regs, hsr));
         break;
     default:
         printk("%s p15, %d, r%d, r%d, cr%d @ %#08x\n",
diff --git a/xen/arch/arm/vtimer.c b/xen/arch/arm/vtimer.c
new file mode 100644
index 0000000..3ebf5b1
--- /dev/null
+++ b/xen/arch/arm/vtimer.c
@@ -0,0 +1,148 @@
+/*
+ * xen/arch/arm/vtimer.c
+ *
+ * ARM Virtual Timer emulation support
+ *
+ * Ian Campbell <ian.campbell@citrix.com>
+ * Copyright (c) 2011 Citrix Systems.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include <xen/config.h>
+#include <xen/lib.h>
+#include <xen/timer.h>
+#include <xen/sched.h>
+#include "gic.h"
+
+extern s_time_t ticks_to_ns(uint64_t ticks);
+extern uint64_t ns_to_ticks(s_time_t ns);
+
+static void vtimer_expired(void *data)
+{
+    struct vcpu *v = data;
+    v->arch.vtimer.ctl |= CNTx_CTL_PENDING;
+    v->arch.vtimer.ctl &= ~CNTx_CTL_MASK;
+    vgic_vcpu_inject_irq(v, 30, 1);
+}
+
+int vcpu_vtimer_init(struct vcpu *v)
+{
+    init_timer(&v->arch.vtimer.timer,
+               vtimer_expired, v,
+               smp_processor_id());
+    v->arch.vtimer.ctl = 0;
+    v->arch.vtimer.offset = NOW();
+    v->arch.vtimer.cval = NOW();
+    return 0;
+}
+
+static int vtimer_emulate_32(struct cpu_user_regs *regs, union hsr hsr)
+{
+    struct vcpu *v = current;
+    struct hsr_cp32 cp32 = hsr.cp32;
+    uint32_t *r = &regs->r0 + cp32.reg;
+    s_time_t now;
+
+    switch ( hsr.bits & HSR_CP32_REGS_MASK )
+    {
+    case HSR_CPREG32(CNTP_CTL):
+        if ( cp32.read )
+        {
+            *r = v->arch.vtimer.ctl;
+        }
+        else
+        {
+            v->arch.vtimer.ctl = *r;
+
+            if ( v->arch.vtimer.ctl & CNTx_CTL_ENABLE )
+            {
+                set_timer(&v->arch.vtimer.timer,
+                          v->arch.vtimer.cval + v->arch.vtimer.offset);
+            }
+            else
+                stop_timer(&v->arch.vtimer.timer);
+        }
+
+        return 1;
+
+    case HSR_CPREG32(CNTP_TVAL):
+        now = NOW() - v->arch.vtimer.offset;
+        if ( cp32.read )
+        {
+            *r = (uint32_t)(ns_to_ticks(v->arch.vtimer.cval - now) & 0xffffffffull);
+        }
+        else
+	{
+            v->arch.vtimer.cval = now + ticks_to_ns(*r);
+	    if ( v->arch.vtimer.ctl & CNTx_CTL_ENABLE )
+            {
+                set_timer(&v->arch.vtimer.timer,
+                          v->arch.vtimer.cval + v->arch.vtimer.offset);
+            }
+        }
+
+        return 1;
+
+    default:
+        return 0;
+    }
+}
+
+static int vtimer_emulate_64(struct cpu_user_regs *regs, union hsr hsr)
+{
+    struct vcpu *v = current;
+    struct hsr_cp64 cp64 = hsr.cp64;
+    uint32_t *r1 = &regs->r0 + cp64.reg1;
+    uint32_t *r2 = &regs->r0 + cp64.reg2;
+    s_time_t now;
+
+    switch ( hsr.bits & HSR_CP64_REGS_MASK )
+    {
+    case HSR_CPREG64(CNTPCT):
+        if ( cp64.read )
+        {
+            now = NOW() - v->arch.vtimer.offset;
+            *r1 = (uint32_t)(now & 0xffffffff);
+            *r2 = (uint32_t)(now >> 32);
+            return 1;
+        }
+        else
+        {
+            printk("READ from R/O CNTPCT\n");
+            return 0;
+        }
+
+    default:
+        return 0;
+    }
+}
+
+int vtimer_emulate(struct cpu_user_regs *regs, union hsr hsr)
+{
+    switch (hsr.ec) {
+    case HSR_EC_CP15_32:
+        return vtimer_emulate_32(regs, hsr);
+    case HSR_EC_CP15_64:
+        return vtimer_emulate_64(regs, hsr);
+    default:
+        return 0;
+    }
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/arch/arm/vtimer.h b/xen/arch/arm/vtimer.h
new file mode 100644
index 0000000..d87bb25
--- /dev/null
+++ b/xen/arch/arm/vtimer.h
@@ -0,0 +1,35 @@
+/*
+ * xen/arch/arm/vtimer.h
+ *
+ * ARM Virtual Timer emulation support
+ *
+ * Ian Campbell <ian.campbell@citrix.com>
+ * Copyright (c) 2011 Citrix Systems.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#ifndef __ARCH_ARM_VTIMER_H__
+#define __ARCH_ARM_VTIMER_H__
+
+extern int vcpu_vtimer_init(struct vcpu *v);
+extern int vtimer_emulate(struct cpu_user_regs *regs, union hsr hsr);
+
+#endif
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
index 2cd0bd3..3372d14 100644
--- a/xen/include/asm-arm/domain.h
+++ b/xen/include/asm-arm/domain.h
@@ -57,6 +57,13 @@ struct arch_vcpu
         struct list_head inflight_irqs;
         spinlock_t lock;
     } vgic;
+
+    struct {
+        struct timer timer;
+        uint32_t ctl;
+        s_time_t offset;
+        s_time_t cval;
+    } vtimer;
 }  __cacheline_aligned;
 
 void vcpu_show_execution_state(struct vcpu *);
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 13:14:44 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 13:14:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZ0H6-0002Ho-5N; Fri, 09 Dec 2011 13:14:04 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RZ0H4-0002Gc-Ta
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 13:14:03 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1323436384!4910711!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMTkxNzY=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30417 invoked from network); 9 Dec 2011 13:13:13 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 13:13:13 -0000
X-IronPort-AV: E=Sophos;i="4.71,325,1320642000"; d="scan'208";a="173546237"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 08:13:12 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 08:13:12 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pB9DCpDn008248;
	Fri, 9 Dec 2011 05:12:55 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 9 Dec 2011 13:13:06 +0000
Message-ID: <1323436408-16335-3-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1112091208420.3517@kaball-desktop>
References: <alpine.DEB.2.00.1112091208420.3517@kaball-desktop>
MIME-Version: 1.0
Cc: keir.xen@gmail.com, Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, JBeulich@suse.com,
	Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v2 03/25] A collection of fixes to Xen common
	files
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

- call free_xenoprof_pages only ifdef CONFIG_XENOPROF;

- define PRI_stime as PRId64 in an header file;

- respect boundaries in is_kernel_*;

- implement is_kernel_rodata.


Changes in v2:

- introduce CONFIG_XENOPROF;

- define _srodata and _erodata as const char*.


Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
---
 xen/common/domain.c           |    2 ++
 xen/common/sched_credit2.c    |    6 ------
 xen/include/asm-ia64/config.h |    1 +
 xen/include/asm-x86/config.h  |    2 ++
 xen/include/xen/kernel.h      |   12 +++++++++---
 xen/include/xen/time.h        |    1 +
 6 files changed, 15 insertions(+), 9 deletions(-)

diff --git a/xen/common/domain.c b/xen/common/domain.c
index 6505572..e5dc88f 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -630,7 +630,9 @@ static void complete_domain_destroy(struct rcu_head *head)
     sched_destroy_domain(d);
 
     /* Free page used by xen oprofile buffer. */
+#ifdef CONFIG_XENOPROF
     free_xenoprof_pages(d);
+#endif
 
     for ( i = d->max_vcpus - 1; i >= 0; i-- )
         if ( (v = d->vcpu[i]) != NULL )
diff --git a/xen/common/sched_credit2.c b/xen/common/sched_credit2.c
index 86c4439..73f7138 100644
--- a/xen/common/sched_credit2.c
+++ b/xen/common/sched_credit2.c
@@ -26,12 +26,6 @@
 #include <xen/trace.h>
 #include <xen/cpu.h>
 
-#if __i386__
-#define PRI_stime "lld"
-#else
-#define PRI_stime "ld"
-#endif
-
 #define d2printk(x...)
 //#define d2printk printk
 
diff --git a/xen/include/asm-ia64/config.h b/xen/include/asm-ia64/config.h
index be94b48..0173487 100644
--- a/xen/include/asm-ia64/config.h
+++ b/xen/include/asm-ia64/config.h
@@ -20,6 +20,7 @@
 #define CONFIG_EFI
 #define CONFIG_EFI_PCDP
 #define CONFIG_SERIAL_SGI_L1_CONSOLE
+#define CONFIG_XENOPROF 1
 
 #define CONFIG_XEN_SMP
 
diff --git a/xen/include/asm-x86/config.h b/xen/include/asm-x86/config.h
index 40a7b8c..905c0f8 100644
--- a/xen/include/asm-x86/config.h
+++ b/xen/include/asm-x86/config.h
@@ -43,6 +43,8 @@
 #define CONFIG_HOTPLUG 1
 #define CONFIG_HOTPLUG_CPU 1
 
+#define CONFIG_XENOPROF 1
+
 #define HZ 100
 
 #define OPT_CONSOLE_STR "vga"
diff --git a/xen/include/xen/kernel.h b/xen/include/xen/kernel.h
index fd03f74..92de428 100644
--- a/xen/include/xen/kernel.h
+++ b/xen/include/xen/kernel.h
@@ -66,19 +66,25 @@
 extern char _start[], _end[];
 #define is_kernel(p) ({                         \
     char *__p = (char *)(unsigned long)(p);     \
-    (__p >= _start) && (__p <= _end);           \
+    (__p >= _start) && (__p < _end);            \
 })
 
 extern char _stext[], _etext[];
 #define is_kernel_text(p) ({                    \
     char *__p = (char *)(unsigned long)(p);     \
-    (__p >= _stext) && (__p <= _etext);         \
+    (__p >= _stext) && (__p < _etext);          \
+})
+
+extern const char _srodata[], _erodata[];
+#define is_kernel_rodata(p) ({                  \
+    const char *__p = (const char *)(unsigned long)(p);     \
+    (__p >= _srodata) && (__p < _erodata);      \
 })
 
 extern char _sinittext[], _einittext[];
 #define is_kernel_inittext(p) ({                \
     char *__p = (char *)(unsigned long)(p);     \
-    (__p >= _sinittext) && (__p <= _einittext); \
+    (__p >= _sinittext) && (__p < _einittext);  \
 })
 
 #endif /* _LINUX_KERNEL_H */
diff --git a/xen/include/xen/time.h b/xen/include/xen/time.h
index a194340..31c9ce5 100644
--- a/xen/include/xen/time.h
+++ b/xen/include/xen/time.h
@@ -30,6 +30,7 @@ struct vcpu;
  */
 
 typedef s64 s_time_t;
+#define PRI_stime PRId64
 
 s_time_t get_s_time(void);
 unsigned long get_localtime(struct domain *d);
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 13:14:44 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 13:14:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZ0H6-0002Ho-5N; Fri, 09 Dec 2011 13:14:04 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RZ0H4-0002Gc-Ta
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 13:14:03 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1323436384!4910711!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMTkxNzY=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30417 invoked from network); 9 Dec 2011 13:13:13 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 13:13:13 -0000
X-IronPort-AV: E=Sophos;i="4.71,325,1320642000"; d="scan'208";a="173546237"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 08:13:12 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 08:13:12 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pB9DCpDn008248;
	Fri, 9 Dec 2011 05:12:55 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 9 Dec 2011 13:13:06 +0000
Message-ID: <1323436408-16335-3-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1112091208420.3517@kaball-desktop>
References: <alpine.DEB.2.00.1112091208420.3517@kaball-desktop>
MIME-Version: 1.0
Cc: keir.xen@gmail.com, Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, JBeulich@suse.com,
	Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v2 03/25] A collection of fixes to Xen common
	files
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

- call free_xenoprof_pages only ifdef CONFIG_XENOPROF;

- define PRI_stime as PRId64 in an header file;

- respect boundaries in is_kernel_*;

- implement is_kernel_rodata.


Changes in v2:

- introduce CONFIG_XENOPROF;

- define _srodata and _erodata as const char*.


Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
---
 xen/common/domain.c           |    2 ++
 xen/common/sched_credit2.c    |    6 ------
 xen/include/asm-ia64/config.h |    1 +
 xen/include/asm-x86/config.h  |    2 ++
 xen/include/xen/kernel.h      |   12 +++++++++---
 xen/include/xen/time.h        |    1 +
 6 files changed, 15 insertions(+), 9 deletions(-)

diff --git a/xen/common/domain.c b/xen/common/domain.c
index 6505572..e5dc88f 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -630,7 +630,9 @@ static void complete_domain_destroy(struct rcu_head *head)
     sched_destroy_domain(d);
 
     /* Free page used by xen oprofile buffer. */
+#ifdef CONFIG_XENOPROF
     free_xenoprof_pages(d);
+#endif
 
     for ( i = d->max_vcpus - 1; i >= 0; i-- )
         if ( (v = d->vcpu[i]) != NULL )
diff --git a/xen/common/sched_credit2.c b/xen/common/sched_credit2.c
index 86c4439..73f7138 100644
--- a/xen/common/sched_credit2.c
+++ b/xen/common/sched_credit2.c
@@ -26,12 +26,6 @@
 #include <xen/trace.h>
 #include <xen/cpu.h>
 
-#if __i386__
-#define PRI_stime "lld"
-#else
-#define PRI_stime "ld"
-#endif
-
 #define d2printk(x...)
 //#define d2printk printk
 
diff --git a/xen/include/asm-ia64/config.h b/xen/include/asm-ia64/config.h
index be94b48..0173487 100644
--- a/xen/include/asm-ia64/config.h
+++ b/xen/include/asm-ia64/config.h
@@ -20,6 +20,7 @@
 #define CONFIG_EFI
 #define CONFIG_EFI_PCDP
 #define CONFIG_SERIAL_SGI_L1_CONSOLE
+#define CONFIG_XENOPROF 1
 
 #define CONFIG_XEN_SMP
 
diff --git a/xen/include/asm-x86/config.h b/xen/include/asm-x86/config.h
index 40a7b8c..905c0f8 100644
--- a/xen/include/asm-x86/config.h
+++ b/xen/include/asm-x86/config.h
@@ -43,6 +43,8 @@
 #define CONFIG_HOTPLUG 1
 #define CONFIG_HOTPLUG_CPU 1
 
+#define CONFIG_XENOPROF 1
+
 #define HZ 100
 
 #define OPT_CONSOLE_STR "vga"
diff --git a/xen/include/xen/kernel.h b/xen/include/xen/kernel.h
index fd03f74..92de428 100644
--- a/xen/include/xen/kernel.h
+++ b/xen/include/xen/kernel.h
@@ -66,19 +66,25 @@
 extern char _start[], _end[];
 #define is_kernel(p) ({                         \
     char *__p = (char *)(unsigned long)(p);     \
-    (__p >= _start) && (__p <= _end);           \
+    (__p >= _start) && (__p < _end);            \
 })
 
 extern char _stext[], _etext[];
 #define is_kernel_text(p) ({                    \
     char *__p = (char *)(unsigned long)(p);     \
-    (__p >= _stext) && (__p <= _etext);         \
+    (__p >= _stext) && (__p < _etext);          \
+})
+
+extern const char _srodata[], _erodata[];
+#define is_kernel_rodata(p) ({                  \
+    const char *__p = (const char *)(unsigned long)(p);     \
+    (__p >= _srodata) && (__p < _erodata);      \
 })
 
 extern char _sinittext[], _einittext[];
 #define is_kernel_inittext(p) ({                \
     char *__p = (char *)(unsigned long)(p);     \
-    (__p >= _sinittext) && (__p <= _einittext); \
+    (__p >= _sinittext) && (__p < _einittext);  \
 })
 
 #endif /* _LINUX_KERNEL_H */
diff --git a/xen/include/xen/time.h b/xen/include/xen/time.h
index a194340..31c9ce5 100644
--- a/xen/include/xen/time.h
+++ b/xen/include/xen/time.h
@@ -30,6 +30,7 @@ struct vcpu;
  */
 
 typedef s64 s_time_t;
+#define PRI_stime PRId64
 
 s_time_t get_s_time(void);
 unsigned long get_localtime(struct domain *d);
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 13:14:44 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 13:14:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZ0HS-0002Wo-JE; Fri, 09 Dec 2011 13:14:26 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RZ0HQ-0002Rp-2i
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 13:14:24 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1323436412!7454574!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDQ0MTg=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1851 invoked from network); 9 Dec 2011 13:13:33 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 13:13:33 -0000
X-IronPort-AV: E=Sophos;i="4.71,325,1320642000"; d="scan'208";a="19808906"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 08:13:31 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 08:13:31 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pB9DCpE3008248;
	Fri, 9 Dec 2011 05:13:19 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 9 Dec 2011 13:13:20 +0000
Message-ID: <1323436408-16335-17-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1112091208420.3517@kaball-desktop>
References: <alpine.DEB.2.00.1112091208420.3517@kaball-desktop>
MIME-Version: 1.0
Cc: keir.xen@gmail.com, Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, JBeulich@suse.com,
	Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v2 17/25] arm: mm and p2m
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Functions to setup pagetables, handle the p2m, map and unmap domain
pages, copy data to/from guest addresses.
The implementation is based on the LPAE extension for ARMv7 and makes
use of the two level transtion mechanism.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
---
 xen/arch/arm/domain.c              |    4 +
 xen/arch/arm/mm.c                  |  321 ++++++++++++++++++++++++++++++++++
 xen/arch/arm/p2m.c                 |  214 +++++++++++++++++++++++
 xen/arch/arm/usercopy.c            |   81 +++++++++
 xen/include/asm-arm/domain.h       |    2 +
 xen/include/asm-arm/guest_access.h |  125 +++++++++++++
 xen/include/asm-arm/mm.h           |  315 +++++++++++++++++++++++++++++++++
 xen/include/asm-arm/p2m.h          |   88 ++++++++++
 xen/include/asm-arm/page.h         |  335 ++++++++++++++++++++++++++++++++++++
 9 files changed, 1485 insertions(+), 0 deletions(-)
 create mode 100644 xen/arch/arm/mm.c
 create mode 100644 xen/arch/arm/p2m.c
 create mode 100644 xen/arch/arm/usercopy.c
 create mode 100644 xen/include/asm-arm/guest_access.h
 create mode 100644 xen/include/asm-arm/mm.h
 create mode 100644 xen/include/asm-arm/p2m.h
 create mode 100644 xen/include/asm-arm/page.h

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index ecbc5b7..0844b37 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -224,6 +224,10 @@ int arch_domain_create(struct domain *d, unsigned int domcr_flags)
 {
     int rc;
 
+    rc = -ENOMEM;
+    if ( (rc = p2m_init(d)) != 0 )
+        goto fail;
+
     d->max_vcpus = 8;
 
     rc = 0;
diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
new file mode 100644
index 0000000..613d084
--- /dev/null
+++ b/xen/arch/arm/mm.c
@@ -0,0 +1,321 @@
+/*
+ * xen/arch/arm/mm.c
+ *
+ * MMU code for an ARMv7-A with virt extensions.
+ *
+ * Tim Deegan <tim@xen.org>
+ * Copyright (c) 2011 Citrix Systems.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include <xen/config.h>
+#include <xen/compile.h>
+#include <xen/types.h>
+#include <xen/init.h>
+#include <xen/mm.h>
+#include <xen/preempt.h>
+#include <asm/page.h>
+#include <asm/current.h>
+
+struct domain *dom_xen, *dom_io;
+
+/* Static start-of-day pagetables that we use before the allocators are up */
+lpae_t xen_pgtable[LPAE_ENTRIES] __attribute__((__aligned__(4096)));
+lpae_t xen_second[LPAE_ENTRIES*4] __attribute__((__aligned__(4096*4)));
+static lpae_t xen_fixmap[LPAE_ENTRIES] __attribute__((__aligned__(4096)));
+static lpae_t xen_xenmap[LPAE_ENTRIES] __attribute__((__aligned__(4096)));
+
+/* Limits of the Xen heap */
+unsigned long xenheap_mfn_start, xenheap_mfn_end;
+unsigned long xenheap_virt_end;
+
+unsigned long frametable_virt_end;
+
+/* Map a 4k page in a fixmap entry */
+void set_fixmap(unsigned map, unsigned long mfn, unsigned attributes)
+{
+    lpae_t pte = mfn_to_xen_entry(mfn);
+    pte.pt.table = 1; /* 4k mappings always have this bit set */
+    pte.pt.ai = attributes;
+    write_pte(xen_fixmap + third_table_offset(FIXMAP_ADDR(map)), pte);
+    flush_xen_data_tlb_va(FIXMAP_ADDR(map));
+}
+
+/* Remove a mapping from a fixmap entry */
+void clear_fixmap(unsigned map)
+{
+    lpae_t pte = {0};
+    write_pte(xen_fixmap + third_table_offset(FIXMAP_ADDR(map)), pte);
+    flush_xen_data_tlb_va(FIXMAP_ADDR(map));
+}
+
+/* Map a page of domheap memory */
+void *map_domain_page(unsigned long mfn)
+{
+    unsigned long flags;
+    lpae_t *map = xen_second + second_linear_offset(DOMHEAP_VIRT_START);
+    unsigned long slot_mfn = mfn & ~LPAE_ENTRY_MASK;
+    uint32_t va;
+    lpae_t pte;
+    int i, slot;
+
+    local_irq_save(flags);
+
+    /* The map is laid out as an open-addressed hash table where each
+     * entry is a 2MB superpage pte.  We use the available bits of each
+     * PTE as a reference count; when the refcount is zero the slot can
+     * be reused. */
+    for ( slot = (slot_mfn >> LPAE_SHIFT) % DOMHEAP_ENTRIES, i = 0;
+          i < DOMHEAP_ENTRIES;
+          slot = (slot + 1) % DOMHEAP_ENTRIES, i++ )
+    {
+        if ( map[slot].pt.avail == 0 )
+        {
+            /* Commandeer this 2MB slot */
+            pte = mfn_to_xen_entry(slot_mfn);
+            pte.pt.avail = 1;
+            write_pte(map + slot, pte);
+            break;
+        }
+        else if ( map[slot].pt.avail < 0xf && map[slot].pt.base == slot_mfn )
+        {
+            /* This slot already points to the right place; reuse it */
+            map[slot].pt.avail++;
+            break;
+        }
+    }
+    /* If the map fills up, the callers have misbehaved. */
+    BUG_ON(i == DOMHEAP_ENTRIES);
+
+#ifndef NDEBUG
+    /* Searching the hash could get slow if the map starts filling up.
+     * Cross that bridge when we come to it */
+    {
+        static int max_tries = 32;
+        if ( i >= max_tries )
+        {
+            dprintk(XENLOG_WARNING, "Domheap map is filling: %i tries\n", i);
+            max_tries *= 2;
+        }
+    }
+#endif
+
+    local_irq_restore(flags);
+
+    va = (DOMHEAP_VIRT_START
+          + (slot << SECOND_SHIFT)
+          + ((mfn & LPAE_ENTRY_MASK) << THIRD_SHIFT));
+
+    /*
+     * We may not have flushed this specific subpage at map time,
+     * since we only flush the 4k page not the superpage
+     */
+    flush_xen_data_tlb_va(va);
+
+    return (void *)va;
+}
+
+/* Release a mapping taken with map_domain_page() */
+void unmap_domain_page(const void *va)
+{
+    unsigned long flags;
+    lpae_t *map = xen_second + second_linear_offset(DOMHEAP_VIRT_START);
+    int slot = ((unsigned long) va - DOMHEAP_VIRT_START) >> SECOND_SHIFT;
+
+    local_irq_save(flags);
+
+    ASSERT(slot >= 0 && slot < DOMHEAP_ENTRIES);
+    ASSERT(map[slot].pt.avail != 0);
+
+    map[slot].pt.avail--;
+
+    local_irq_restore(flags);
+}
+
+
+/* Boot-time pagetable setup.
+ * Changes here may need matching changes in head.S */
+void __init setup_pagetables(unsigned long boot_phys_offset)
+{
+    paddr_t xen_paddr, phys_offset;
+    unsigned long dest_va;
+    lpae_t pte, *p;
+    int i;
+
+    if ( boot_phys_offset != 0 )
+    {
+        /* Remove the old identity mapping of the boot paddr */
+        pte.bits = 0;
+        dest_va = (unsigned long)_start + boot_phys_offset;
+        write_pte(xen_second + second_linear_offset(dest_va), pte);
+    }
+
+    xen_paddr = XEN_PADDR;
+
+    /* Map the destination in the empty L2 above the fixmap */
+    dest_va = FIXMAP_ADDR(0) + (1u << SECOND_SHIFT);
+    pte = mfn_to_xen_entry(xen_paddr >> PAGE_SHIFT);
+    write_pte(xen_second + second_table_offset(dest_va), pte);
+
+    /* Calculate virt-to-phys offset for the new location */
+    phys_offset = xen_paddr - (unsigned long) _start;
+
+    /* Copy */
+    memcpy((void *) dest_va, _start, _end - _start);
+
+    /* Beware!  Any state we modify between now and the PT switch may be
+     * discarded when we switch over to the copy. */
+
+    /* Update the copy of xen_pgtable to use the new paddrs */
+    p = (void *) xen_pgtable + dest_va - (unsigned long) _start;
+    for ( i = 0; i < 4; i++)
+        p[i].pt.base += (phys_offset - boot_phys_offset) >> PAGE_SHIFT;
+    p = (void *) xen_second + dest_va - (unsigned long) _start;
+    for ( i = 0; i < 4 * LPAE_ENTRIES; i++)
+        if ( p[i].pt.valid )
+                p[i].pt.base += (phys_offset - boot_phys_offset) >> PAGE_SHIFT;
+
+    /* Change pagetables to the copy in the relocated Xen */
+    asm volatile (
+        STORE_CP64(0, HTTBR)          /* Change translation base */
+        "dsb;"                        /* Ensure visibility of HTTBR update */
+        STORE_CP32(0, TLBIALLH)       /* Flush hypervisor TLB */
+        STORE_CP32(0, BPIALL)         /* Flush branch predictor */
+        "dsb;"                        /* Ensure completion of TLB+BP flush */
+        "isb;"
+        : : "r" ((unsigned long) xen_pgtable + phys_offset) : "memory");
+
+    /* Undo the temporary map */
+    pte.bits = 0;
+    write_pte(xen_second + second_table_offset(dest_va), pte);
+    /*
+     * Have removed a mapping previously used for .text. Flush everything
+     * for safety.
+     */
+    asm volatile (
+        "dsb;"                        /* Ensure visibility of PTE write */
+        STORE_CP32(0, TLBIALLH)       /* Flush hypervisor TLB */
+        STORE_CP32(0, BPIALL)         /* Flush branch predictor */
+        "dsb;"                        /* Ensure completion of TLB+BP flush */
+        "isb;"
+        : : "r" (i /*dummy*/) : "memory");
+
+    /* Link in the fixmap pagetable */
+    pte = mfn_to_xen_entry((((unsigned long) xen_fixmap) + phys_offset)
+                           >> PAGE_SHIFT);
+    pte.pt.table = 1;
+    write_pte(xen_second + second_table_offset(FIXMAP_ADDR(0)), pte);
+    /*
+     * No flush required here. Individual flushes are done in
+     * set_fixmap as entries are used.
+     */
+
+    /* Break up the Xen mapping into 4k pages and protect them separately. */
+    for ( i = 0; i < LPAE_ENTRIES; i++ )
+    {
+        unsigned long mfn = paddr_to_pfn(xen_paddr) + i;
+        unsigned long va = XEN_VIRT_START + (i << PAGE_SHIFT);
+        if ( !is_kernel(va) )
+            break;
+        pte = mfn_to_xen_entry(mfn);
+        pte.pt.table = 1; /* 4k mappings always have this bit set */
+        if ( is_kernel_text(va) || is_kernel_inittext(va) )
+        {
+            pte.pt.xn = 0;
+            pte.pt.ro = 1;
+        }
+        if ( is_kernel_rodata(va) )
+            pte.pt.ro = 1;
+        write_pte(xen_xenmap + i, pte);
+        /* No flush required here as page table is not hooked in yet. */
+    }
+    pte = mfn_to_xen_entry((((unsigned long) xen_xenmap) + phys_offset)
+                           >> PAGE_SHIFT);
+    pte.pt.table = 1;
+    write_pte(xen_second + second_linear_offset(XEN_VIRT_START), pte);
+    /* Have changed a mapping used for .text. Flush everything for safety. */
+    asm volatile (
+        "dsb;"                        /* Ensure visibility of PTE write */
+        STORE_CP32(0, TLBIALLH)       /* Flush hypervisor TLB */
+        STORE_CP32(0, BPIALL)         /* Flush branch predictor */
+        "dsb;"                        /* Ensure completion of TLB+BP flush */
+        "isb;"
+        : : "r" (i /*dummy*/) : "memory");
+
+    /* From now on, no mapping may be both writable and executable. */
+    WRITE_CP32(READ_CP32(HSCTLR) | SCTLR_WXN, HSCTLR);
+}
+
+/* Create Xen's mappings of memory.
+ * Base and virt must be 32MB aligned and size a multiple of 32MB. */
+static void __init create_mappings(unsigned long virt,
+                                   unsigned long base_mfn,
+                                   unsigned long nr_mfns)
+{
+    unsigned long i, count;
+    lpae_t pte, *p;
+
+    ASSERT(!((virt >> PAGE_SHIFT) % (16 * LPAE_ENTRIES)));
+    ASSERT(!(base_mfn % (16 * LPAE_ENTRIES)));
+    ASSERT(!(nr_mfns % (16 * LPAE_ENTRIES)));
+
+    count = nr_mfns / LPAE_ENTRIES;
+    p = xen_second + second_linear_offset(virt);
+    pte = mfn_to_xen_entry(base_mfn);
+    pte.pt.hint = 1;  /* These maps are in 16-entry contiguous chunks. */
+    for ( i = 0; i < count; i++ )
+    {
+        write_pte(p + i, pte);
+        pte.pt.base += 1 << LPAE_SHIFT;
+    }
+    flush_xen_data_tlb();
+}
+
+/* Set up the xenheap: up to 1GB of contiguous, always-mapped memory. */
+void __init setup_xenheap_mappings(unsigned long base_mfn,
+                                   unsigned long nr_mfns)
+{
+    create_mappings(XENHEAP_VIRT_START, base_mfn, nr_mfns);
+
+    /* Record where the xenheap is, for translation routines. */
+    xenheap_virt_end = XENHEAP_VIRT_START + nr_mfns * PAGE_SIZE;
+    xenheap_mfn_start = base_mfn;
+    xenheap_mfn_end = base_mfn + nr_mfns;
+}
+
+/* Map a frame table to cover physical addresses ps through pe */
+void __init setup_frametable_mappings(paddr_t ps, paddr_t pe)
+{
+    unsigned long nr_pages = (pe - ps) >> PAGE_SHIFT;
+    unsigned long frametable_size = nr_pages * sizeof(struct page_info);
+    unsigned long base_mfn;
+
+    /* Round up to 32M boundary */
+    frametable_size = (frametable_size + 0x1ffffff) & ~0x1ffffff;
+    base_mfn = alloc_boot_pages(frametable_size >> PAGE_SHIFT, 5);
+    create_mappings(FRAMETABLE_VIRT_START, base_mfn, frametable_size >> PAGE_SHIFT);
+
+    memset(&frame_table[0], 0, nr_pages * sizeof(struct page_info));
+    memset(&frame_table[nr_pages], -1,
+           frametable_size - (nr_pages * sizeof(struct page_info)));
+
+    frametable_virt_end = FRAMETABLE_VIRT_START + (nr_pages * sizeof(struct page_info));
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
new file mode 100644
index 0000000..a1d026d
--- /dev/null
+++ b/xen/arch/arm/p2m.c
@@ -0,0 +1,214 @@
+#include <xen/config.h>
+#include <xen/sched.h>
+#include <xen/lib.h>
+#include <xen/errno.h>
+#include <xen/domain_page.h>
+
+void p2m_load_VTTBR(struct domain *d)
+{
+    struct p2m_domain *p2m = &d->arch.p2m;
+    paddr_t maddr = page_to_maddr(p2m->first_level);
+    uint64_t vttbr = maddr;
+
+    vttbr |= ((uint64_t)p2m->vmid&0xff)<<48;
+
+    printk("VTTBR dom%d = %"PRIx64"\n", d->domain_id, vttbr);
+
+    WRITE_CP64(vttbr, VTTBR);
+    isb(); /* Ensure update is visible */
+}
+
+static int p2m_create_entry(struct domain *d,
+                            lpae_t *entry)
+{
+    struct p2m_domain *p2m = &d->arch.p2m;
+    struct page_info *page;
+    void *p;
+    lpae_t pte;
+
+    BUG_ON(entry->p2m.valid);
+
+    page = alloc_domheap_page(d, 0);
+    if ( page == NULL )
+        return -ENOMEM;
+
+    page_list_add(page, &p2m->pages);
+
+    p = __map_domain_page(page);
+    clear_page(p);
+    unmap_domain_page(p);
+
+    pte = mfn_to_p2m_entry(page_to_mfn(page));
+
+    write_pte(entry, pte);
+
+    return 0;
+}
+
+static int create_p2m_entries(struct domain *d,
+                     int alloc,
+                     paddr_t start_gpaddr,
+                     paddr_t end_gpaddr,
+                     paddr_t maddr)
+{
+    int rc;
+    struct p2m_domain *p2m = &d->arch.p2m;
+    lpae_t *first = NULL, *second = NULL, *third = NULL;
+    paddr_t addr;
+    unsigned long cur_first_offset = ~0, cur_second_offset = ~0;
+
+    /* XXX Don't actually handle 40 bit guest physical addresses */
+    BUG_ON(start_gpaddr & 0x8000000000ULL);
+    BUG_ON(end_gpaddr   & 0x8000000000ULL);
+
+    first = __map_domain_page(p2m->first_level);
+
+    for(addr = start_gpaddr; addr < end_gpaddr; addr += PAGE_SIZE)
+    {
+        if ( !first[first_table_offset(addr)].p2m.valid )
+        {
+            rc = p2m_create_entry(d, &first[first_table_offset(addr)]);
+            if ( rc < 0 ) {
+                printk("p2m_populate_ram: L1 failed\n");
+                goto out;
+            }
+        }
+
+        BUG_ON(!first[first_table_offset(addr)].p2m.valid);
+
+        if ( cur_first_offset != first_table_offset(addr) )
+        {
+            if (second) unmap_domain_page(second);
+            second = map_domain_page(first[first_table_offset(addr)].p2m.base);
+            cur_first_offset = first_table_offset(addr);
+        }
+        /* else: second already valid */
+
+        if ( !second[second_table_offset(addr)].p2m.valid )
+        {
+            rc = p2m_create_entry(d, &second[second_table_offset(addr)]);
+            if ( rc < 0 ) {
+                printk("p2m_populate_ram: L2 failed\n");
+                goto out;
+            }
+        }
+
+        BUG_ON(!second[second_table_offset(addr)].p2m.valid);
+
+        if ( cur_second_offset != second_table_offset(addr) )
+        {
+            /* map third level */
+            if (third) unmap_domain_page(third);
+            third = map_domain_page(second[second_table_offset(addr)].p2m.base);
+            cur_second_offset = second_table_offset(addr);
+        }
+        /* else: third already valid */
+
+        BUG_ON(third[third_table_offset(addr)].p2m.valid);
+
+        /* Allocate a new RAM page and attach */
+        if (alloc)
+        {
+            struct page_info *page;
+            lpae_t pte;
+
+            rc = -ENOMEM;
+            page = alloc_domheap_page(d, 0);
+            if ( page == NULL ) {
+                printk("p2m_populate_ram: failed to allocate page\n");
+                goto out;
+            }
+
+            pte = mfn_to_p2m_entry(page_to_mfn(page));
+
+            write_pte(&third[third_table_offset(addr)], pte);
+        } else {
+            lpae_t pte = mfn_to_p2m_entry(maddr >> PAGE_SHIFT);
+            write_pte(&third[third_table_offset(addr)], pte);
+            maddr += PAGE_SIZE;
+        }
+    }
+
+    rc = 0;
+
+out:
+    spin_lock(&p2m->lock);
+
+    if (third) unmap_domain_page(third);
+    if (second) unmap_domain_page(second);
+    if (first) unmap_domain_page(first);
+
+    spin_unlock(&p2m->lock);
+
+    return rc;
+}
+
+int p2m_populate_ram(struct domain *d,
+                     paddr_t start,
+                     paddr_t end)
+{
+    return create_p2m_entries(d, 1, start, end, 0);
+}
+
+int map_mmio_regions(struct domain *d,
+                     paddr_t start_gaddr,
+                     paddr_t end_gaddr,
+                     paddr_t maddr)
+{
+    return create_p2m_entries(d, 0, start_gaddr, end_gaddr, maddr);
+}
+
+int p2m_alloc_table(struct domain *d)
+{
+    struct p2m_domain *p2m = &d->arch.p2m;
+    struct page_info *page;
+    void *p;
+
+    /* First level P2M is 2 consecutive pages */
+    page = alloc_domheap_pages(d, 1, 0);
+    if ( page == NULL )
+        return -ENOMEM;
+
+    spin_lock(&p2m->lock);
+
+    page_list_add(page, &p2m->pages);
+
+    /* Clear both first level pages */
+    p = __map_domain_page(page);
+    clear_page(p);
+    unmap_domain_page(p);
+
+    p = __map_domain_page(page + 1);
+    clear_page(p);
+    unmap_domain_page(p);
+
+    p2m->first_level = page;
+
+    spin_unlock(&p2m->lock);
+
+    return 0;
+}
+
+int p2m_init(struct domain *d)
+{
+    struct p2m_domain *p2m = &d->arch.p2m;
+
+    spin_lock_init(&p2m->lock);
+    INIT_PAGE_LIST_HEAD(&p2m->pages);
+
+    /* XXX allocate properly */
+    /* Zero is reserved */
+    p2m->vmid = d->domain_id + 1;
+
+    p2m->first_level = NULL;
+
+    return 0;
+}
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/arch/arm/usercopy.c b/xen/arch/arm/usercopy.c
new file mode 100644
index 0000000..6f51e0f
--- /dev/null
+++ b/xen/arch/arm/usercopy.c
@@ -0,0 +1,81 @@
+#include <xen/config.h>
+#include <xen/lib.h>
+#include <xen/domain_page.h>
+
+#include <asm/mm.h>
+#include <asm/guest_access.h>
+
+unsigned long copy_to_user(void __user *to, const void *from, unsigned len)
+{
+    /* XXX needs to handle faults */
+    unsigned offset = ((unsigned long)to & ~PAGE_MASK);
+
+    while ( len )
+    {
+        paddr_t g = gvirt_to_maddr((uint32_t) to);
+        void *p = map_domain_page(g>>PAGE_SHIFT);
+        unsigned size = min(len, (unsigned)PAGE_SIZE - offset);
+
+        p += offset;
+        memcpy(p, from, size);
+
+        unmap_domain_page(p - offset);
+        len -= size;
+        from += size;
+        to += size;
+        offset = 0;
+    }
+
+    return 0;
+}
+
+unsigned long clear_user(void __user *to, unsigned len)
+{
+    /* XXX needs to handle faults */
+    unsigned offset = ((unsigned long)to & ~PAGE_MASK);
+
+    while ( len )
+    {
+        paddr_t g = gvirt_to_maddr((uint32_t) to);
+        void *p = map_domain_page(g>>PAGE_SHIFT);
+        unsigned size = min(len, (unsigned)PAGE_SIZE - offset);
+
+        p += offset;
+        memset(p, 0x00, size);
+
+        unmap_domain_page(p - offset);
+        len -= size;
+        to += size;
+        offset = 0;
+    }
+
+    return 0;
+}
+
+unsigned long copy_from_user(void *to, const void __user *from, unsigned len)
+{
+    while ( len )
+    {
+        paddr_t g = gvirt_to_maddr((uint32_t) from & PAGE_MASK);
+        void *p = map_domain_page(g>>PAGE_SHIFT);
+        unsigned size = min(len, (unsigned)(PAGE_SIZE - ((unsigned)from & (~PAGE_MASK))));
+
+        p += ((unsigned long)from & (~PAGE_MASK));
+
+        memcpy(to, p, size);
+
+        unmap_domain_page(p);
+        len -= size;
+        from += size;
+        to += size;
+    }
+    return 0;
+}
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
index c226bdf..2226a24 100644
--- a/xen/include/asm-arm/domain.h
+++ b/xen/include/asm-arm/domain.h
@@ -16,6 +16,8 @@ struct pending_irq
 
 struct arch_domain
 {
+    struct p2m_domain p2m;
+
 }  __cacheline_aligned;
 
 struct arch_vcpu
diff --git a/xen/include/asm-arm/guest_access.h b/xen/include/asm-arm/guest_access.h
new file mode 100644
index 0000000..b8d4e63
--- /dev/null
+++ b/xen/include/asm-arm/guest_access.h
@@ -0,0 +1,125 @@
+#ifndef __ASM_ARM_GUEST_ACCESS_H__
+#define __ASM_ARM_GUEST_ACCESS_H__
+
+#include <xen/errno.h>
+
+/* Guests have their own comlete address space */
+#define access_ok(addr,size) (1)
+
+#define array_access_ok(addr,count,size) \
+    (likely(count < (~0UL/size)) && access_ok(addr,count*size))
+
+unsigned long copy_to_user(void *to, const void *from, unsigned len);
+unsigned long copy_from_user(void *to, const void *from, unsigned len);
+unsigned long clear_user(void *to, unsigned len);
+
+/* Raw access functions: no type checking. */
+/* All accesses are HVM type in ARM */
+#define raw_copy_to_guest(dst, src, len)        \
+    copy_to_user((dst), (src), (len))
+#define raw_copy_from_guest(dst, src, len)      \
+    copy_from_user((dst), (src), (len))
+#define __raw_copy_to_guest(dst, src, len)      \
+    copy_to_user((dst), (src), (len))
+#define __raw_copy_from_guest(dst, src, len)    \
+    copy_from_user((dst), (src), (len))
+
+/* Remainder copied from x86 -- could be common? */
+
+/* Is the guest handle a NULL reference? */
+#define guest_handle_is_null(hnd)        ((hnd).p == NULL)
+
+/* Offset the given guest handle into the array it refers to. */
+#define guest_handle_add_offset(hnd, nr) ((hnd).p += (nr))
+#define guest_handle_subtract_offset(hnd, nr) ((hnd).p -= (nr))
+
+/* Cast a guest handle to the specified type of handle. */
+#define guest_handle_cast(hnd, type) ({         \
+    type *_x = (hnd).p;                         \
+    (XEN_GUEST_HANDLE(type)) { _x };            \
+})
+
+#define guest_handle_from_ptr(ptr, type)        \
+    ((XEN_GUEST_HANDLE(type)) { (type *)ptr })
+#define const_guest_handle_from_ptr(ptr, type)  \
+    ((XEN_GUEST_HANDLE(const_##type)) { (const type *)ptr })
+
+/*
+ * Copy an array of objects to guest context via a guest handle,
+ * specifying an offset into the guest array.
+ */
+#define copy_to_guest_offset(hnd, off, ptr, nr) ({      \
+    const typeof(*(ptr)) *_s = (ptr);                   \
+    char (*_d)[sizeof(*_s)] = (void *)(hnd).p;          \
+    ((void)((hnd).p == (ptr)));                         \
+    raw_copy_to_guest(_d+(off), _s, sizeof(*_s)*(nr));  \
+})
+
+/*
+ * Copy an array of objects from guest context via a guest handle,
+ * specifying an offset into the guest array.
+ */
+#define copy_from_guest_offset(ptr, hnd, off, nr) ({    \
+    const typeof(*(ptr)) *_s = (hnd).p;                 \
+    typeof(*(ptr)) *_d = (ptr);                         \
+    raw_copy_from_guest(_d, _s+(off), sizeof(*_d)*(nr));\
+})
+
+/* Copy sub-field of a structure to guest context via a guest handle. */
+#define copy_field_to_guest(hnd, ptr, field) ({         \
+    const typeof(&(ptr)->field) _s = &(ptr)->field;     \
+    void *_d = &(hnd).p->field;                         \
+    ((void)(&(hnd).p->field == &(ptr)->field));         \
+    raw_copy_to_guest(_d, _s, sizeof(*_s));             \
+})
+
+/* Copy sub-field of a structure from guest context via a guest handle. */
+#define copy_field_from_guest(ptr, hnd, field) ({       \
+    const typeof(&(ptr)->field) _s = &(hnd).p->field;   \
+    typeof(&(ptr)->field) _d = &(ptr)->field;           \
+    raw_copy_from_guest(_d, _s, sizeof(*_d));           \
+})
+
+/*
+ * Pre-validate a guest handle.
+ * Allows use of faster __copy_* functions.
+ */
+/* All ARM guests are paging mode external and hence safe */
+#define guest_handle_okay(hnd, nr) (1)
+#define guest_handle_subrange_okay(hnd, first, last) (1)
+
+#define __copy_to_guest_offset(hnd, off, ptr, nr) ({    \
+    const typeof(*(ptr)) *_s = (ptr);                   \
+    char (*_d)[sizeof(*_s)] = (void *)(hnd).p;          \
+    ((void)((hnd).p == (ptr)));                         \
+    __raw_copy_to_guest(_d+(off), _s, sizeof(*_s)*(nr));\
+})
+
+#define __copy_from_guest_offset(ptr, hnd, off, nr) ({  \
+    const typeof(*(ptr)) *_s = (hnd).p;                 \
+    typeof(*(ptr)) *_d = (ptr);                         \
+    __raw_copy_from_guest(_d, _s+(off), sizeof(*_d)*(nr));\
+})
+
+#define __copy_field_to_guest(hnd, ptr, field) ({       \
+    const typeof(&(ptr)->field) _s = &(ptr)->field;     \
+    void *_d = &(hnd).p->field;                         \
+    ((void)(&(hnd).p->field == &(ptr)->field));         \
+    __raw_copy_to_guest(_d, _s, sizeof(*_s));           \
+})
+
+#define __copy_field_from_guest(ptr, hnd, field) ({     \
+    const typeof(&(ptr)->field) _s = &(hnd).p->field;   \
+    typeof(&(ptr)->field) _d = &(ptr)->field;           \
+    __raw_copy_from_guest(_d, _s, sizeof(*_d));         \
+})
+
+#endif /* __ASM_ARM_GUEST_ACCESS_H__ */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/mm.h b/xen/include/asm-arm/mm.h
new file mode 100644
index 0000000..ead6e0c
--- /dev/null
+++ b/xen/include/asm-arm/mm.h
@@ -0,0 +1,315 @@
+#ifndef __ARCH_ARM_MM__
+#define __ARCH_ARM_MM__
+
+#include <xen/config.h>
+#include <xen/kernel.h>
+#include <asm/page.h>
+#include <public/xen.h>
+
+/* Find a suitable place at the top of memory for Xen to live */
+/* XXX For now, use the top of the VE's 4GB RAM, at a 40-bit alias */
+#define XEN_PADDR 0x80ffe00000ull
+
+/*
+ * Per-page-frame information.
+ *
+ * Every architecture must ensure the following:
+ *  1. 'struct page_info' contains a 'struct page_list_entry list'.
+ *  2. Provide a PFN_ORDER() macro for accessing the order of a free page.
+ */
+#define PFN_ORDER(_pfn) ((_pfn)->v.free.order)
+
+struct page_info
+{
+    /* Each frame can be threaded onto a doubly-linked list. */
+    struct page_list_entry list;
+
+    /* Reference count and various PGC_xxx flags and fields. */
+    unsigned long count_info;
+
+    /* Context-dependent fields follow... */
+    union {
+        /* Page is in use: ((count_info & PGC_count_mask) != 0). */
+        struct {
+            /* Type reference count and various PGT_xxx flags and fields. */
+            unsigned long type_info;
+        } inuse;
+        /* Page is on a free list: ((count_info & PGC_count_mask) == 0). */
+        struct {
+            /* Do TLBs need flushing for safety before next page use? */
+            bool_t need_tlbflush;
+        } free;
+
+    } u;
+
+    union {
+        /* Page is in use, but not as a shadow. */
+        struct {
+            /* Owner of this page (zero if page is anonymous). */
+            struct domain *domain;
+        } inuse;
+
+        /* Page is on a free list. */
+        struct {
+            /* Order-size of the free chunk this page is the head of. */
+            unsigned int order;
+        } free;
+
+    } v;
+
+    union {
+        /*
+         * Timestamp from 'TLB clock', used to avoid extra safety flushes.
+         * Only valid for: a) free pages, and b) pages with zero type count
+         */
+        u32 tlbflush_timestamp;
+    };
+    u64 pad;
+};
+
+#define PG_shift(idx)   (BITS_PER_LONG - (idx))
+#define PG_mask(x, idx) (x ## UL << PG_shift(idx))
+
+#define PGT_none          PG_mask(0, 4)  /* no special uses of this page   */
+#define PGT_writable_page PG_mask(7, 4)  /* has writable mappings?         */
+#define PGT_shared_page   PG_mask(8, 4)  /* CoW sharable page              */
+#define PGT_type_mask     PG_mask(15, 4) /* Bits 28-31 or 60-63.           */
+
+ /* Owning guest has pinned this page to its current type? */
+#define _PGT_pinned       PG_shift(5)
+#define PGT_pinned        PG_mask(1, 5)
+
+ /* Count of uses of this frame as its current type. */
+#define PGT_count_width   PG_shift(9)
+#define PGT_count_mask    ((1UL<<PGT_count_width)-1)
+
+ /* Cleared when the owning guest 'frees' this page. */
+#define _PGC_allocated    PG_shift(1)
+#define PGC_allocated     PG_mask(1, 1)
+  /* Page is Xen heap? */
+#define _PGC_xen_heap     PG_shift(2)
+#define PGC_xen_heap      PG_mask(1, 2)
+/* ... */
+/* Page is broken? */
+#define _PGC_broken       PG_shift(7)
+#define PGC_broken        PG_mask(1, 7)
+ /* Mutually-exclusive page states: { inuse, offlining, offlined, free }. */
+#define PGC_state         PG_mask(3, 9)
+#define PGC_state_inuse   PG_mask(0, 9)
+#define PGC_state_offlining PG_mask(1, 9)
+#define PGC_state_offlined PG_mask(2, 9)
+#define PGC_state_free    PG_mask(3, 9)
+#define page_state_is(pg, st) (((pg)->count_info&PGC_state) == PGC_state_##st)
+
+/* Count of references to this frame. */
+#define PGC_count_width   PG_shift(9)
+#define PGC_count_mask    ((1UL<<PGC_count_width)-1)
+
+extern unsigned long xenheap_mfn_start, xenheap_mfn_end;
+extern unsigned long xenheap_virt_end;
+
+#define is_xen_heap_page(page) is_xen_heap_mfn(page_to_mfn(page))
+#define is_xen_heap_mfn(mfn) ({                                 \
+    unsigned long _mfn = (mfn);                                 \
+    (_mfn >= xenheap_mfn_start && _mfn < xenheap_mfn_end);      \
+})
+#define is_xen_fixed_mfn(mfn) is_xen_heap_mfn(mfn)
+
+#define page_get_owner(_p)    (_p)->v.inuse.domain
+#define page_set_owner(_p,_d) ((_p)->v.inuse.domain = (_d))
+
+#define maddr_get_owner(ma)   (page_get_owner(maddr_to_page((ma))))
+#define vaddr_get_owner(va)   (page_get_owner(virt_to_page((va))))
+
+#define XENSHARE_writable 0
+#define XENSHARE_readonly 1
+extern void share_xen_page_with_guest(
+    struct page_info *page, struct domain *d, int readonly);
+extern void share_xen_page_with_privileged_guests(
+    struct page_info *page, int readonly);
+
+#define frame_table ((struct page_info *)FRAMETABLE_VIRT_START)
+
+extern unsigned long max_page;
+extern unsigned long total_pages;
+
+/* Boot-time pagetable setup */
+extern void setup_pagetables(unsigned long boot_phys_offset);
+/* Set up the xenheap: up to 1GB of contiguous, always-mapped memory.
+ * Base must be 32MB aligned and size a multiple of 32MB. */
+extern void setup_xenheap_mappings(unsigned long base_mfn, unsigned long nr_mfns);
+/* Map a frame table to cover physical addresses ps through pe */
+extern void setup_frametable_mappings(paddr_t ps, paddr_t pe);
+/* Map a 4k page in a fixmap entry */
+extern void set_fixmap(unsigned map, unsigned long mfn, unsigned attributes);
+/* Remove a mapping from a fixmap entry */
+extern void clear_fixmap(unsigned map);
+
+
+#define mfn_valid(mfn)        ({                                              \
+    unsigned long __m_f_n = (mfn);                                            \
+    likely(__m_f_n < max_page);                                               \
+})
+
+#define max_pdx                 max_page
+/* XXX Assume everything in the 40-bit physical alias 0x8000000000 for now */
+#define pfn_to_pdx(pfn)         ((pfn) - 0x8000000UL)
+#define pdx_to_pfn(pdx)         ((pdx) + 0x8000000UL)
+#define virt_to_pdx(va)         virt_to_mfn(va)
+#define pdx_to_virt(pdx)        mfn_to_virt(pdx)
+
+/* Convert between machine frame numbers and page-info structures. */
+#define mfn_to_page(mfn)  (frame_table + pfn_to_pdx(mfn))
+#define page_to_mfn(pg)   pdx_to_pfn((unsigned long)((pg) - frame_table))
+#define __page_to_mfn(pg)  page_to_mfn(pg)
+#define __mfn_to_page(mfn) mfn_to_page(mfn)
+
+/* Convert between machine addresses and page-info structures. */
+#define maddr_to_page(ma) __mfn_to_page((ma) >> PAGE_SHIFT)
+#define page_to_maddr(pg) ((paddr_t)__page_to_mfn(pg) << PAGE_SHIFT)
+
+/* Convert between frame number and address formats.  */
+#define pfn_to_paddr(pfn) ((paddr_t)(pfn) << PAGE_SHIFT)
+#define paddr_to_pfn(pa)  ((unsigned long)((pa) >> PAGE_SHIFT))
+#define paddr_to_pdx(pa)    pfn_to_pdx(paddr_to_pfn(pa))
+
+
+static inline paddr_t virt_to_maddr(void *va)
+{
+    uint64_t par = va_to_par((uint32_t)va);
+    return (par & PADDR_MASK & PAGE_MASK) | ((unsigned long) va & ~PAGE_MASK);
+}
+
+static inline void *maddr_to_virt(paddr_t ma)
+{
+    ASSERT(is_xen_heap_mfn(ma >> PAGE_SHIFT));
+    ma -= pfn_to_paddr(xenheap_mfn_start);
+    return (void *)(unsigned long) ma + XENHEAP_VIRT_START;
+}
+
+static inline paddr_t gvirt_to_maddr(uint32_t va)
+{
+    uint64_t par = gva_to_par(va);
+    return (par & PADDR_MASK & PAGE_MASK) | ((unsigned long) va & ~PAGE_MASK);
+}
+
+/* Convert between Xen-heap virtual addresses and machine addresses. */
+#define __pa(x)             (virt_to_maddr(x))
+#define __va(x)             (maddr_to_virt(x))
+
+/* Convert between Xen-heap virtual addresses and machine frame numbers. */
+#define virt_to_mfn(va)   (virt_to_maddr(va) >> PAGE_SHIFT)
+#define mfn_to_virt(mfn)  (maddr_to_virt((paddr_t)(mfn) << PAGE_SHIFT))
+
+
+static inline int get_order_from_bytes(paddr_t size)
+{
+    int order;
+    size = (size-1) >> PAGE_SHIFT;
+    for ( order = 0; size; order++ )
+        size >>= 1;
+    return order;
+}
+
+static inline int get_order_from_pages(unsigned long nr_pages)
+{
+    int order;
+    nr_pages--;
+    for ( order = 0; nr_pages; order++ )
+        nr_pages >>= 1;
+    return order;
+}
+
+
+/* Convert between Xen-heap virtual addresses and page-info structures. */
+static inline struct page_info *virt_to_page(const void *v)
+{
+    unsigned long va = (unsigned long)v;
+    ASSERT(va >= XENHEAP_VIRT_START);
+    ASSERT(va < xenheap_virt_end);
+
+    return frame_table + ((va - XENHEAP_VIRT_START) >> PAGE_SHIFT);
+}
+
+static inline void *page_to_virt(const struct page_info *pg)
+{
+    ASSERT((unsigned long)pg - FRAMETABLE_VIRT_START < frametable_virt_end);
+    return (void *)(XENHEAP_VIRT_START +
+                    ((unsigned long)pg - FRAMETABLE_VIRT_START) /
+                    (sizeof(*pg) / (sizeof(*pg) & -sizeof(*pg))) *
+                    (PAGE_SIZE / (sizeof(*pg) & -sizeof(*pg))));
+
+}
+
+struct domain *page_get_owner_and_reference(struct page_info *page);
+void put_page(struct page_info *page);
+int  get_page(struct page_info *page, struct domain *domain);
+
+/*
+ * The MPT (machine->physical mapping table) is an array of word-sized
+ * values, indexed on machine frame number. It is expected that guest OSes
+ * will use it to store a "physical" frame number to give the appearance of
+ * contiguous (or near contiguous) physical memory.
+ */
+#undef  machine_to_phys_mapping
+#define machine_to_phys_mapping  ((unsigned long *)RDWR_MPT_VIRT_START)
+#define INVALID_M2P_ENTRY        (~0UL)
+#define VALID_M2P(_e)            (!((_e) & (1UL<<(BITS_PER_LONG-1))))
+#define SHARED_M2P_ENTRY         (~0UL - 1UL)
+#define SHARED_M2P(_e)           ((_e) == SHARED_M2P_ENTRY)
+
+#define _set_gpfn_from_mfn(mfn, pfn) ({                        \
+    struct domain *d = page_get_owner(__mfn_to_page(mfn));     \
+    if(d && (d == dom_cow))                                    \
+        machine_to_phys_mapping[(mfn)] = SHARED_M2P_ENTRY;     \
+    else                                                       \
+        machine_to_phys_mapping[(mfn)] = (pfn);                \
+    })
+
+#define put_gfn(d, g)   ((void)0)
+
+#define INVALID_MFN             (~0UL)
+
+/* Xen always owns P2M on ARM */
+#define set_gpfn_from_mfn(mfn, pfn) do { (void) (mfn),(pfn); } while (0)
+#define mfn_to_gmfn(_d, mfn)  (mfn)
+
+
+/* Arch-specific portion of memory_op hypercall. */
+long arch_memory_op(int op, XEN_GUEST_HANDLE(void) arg);
+
+int steal_page(
+    struct domain *d, struct page_info *page, unsigned int memflags);
+int donate_page(
+    struct domain *d, struct page_info *page, unsigned int memflags);
+
+#define domain_set_alloc_bitsize(d) ((void)0)
+#define domain_clamp_alloc_bitsize(d, b) (b)
+
+unsigned long domain_get_maximum_gpfn(struct domain *d);
+
+extern struct domain *dom_xen, *dom_io, *dom_cow;
+
+#define memguard_init(_s)              (_s)
+#define memguard_guard_stack(_p)       ((void)0)
+#define memguard_guard_range(_p,_l)    ((void)0)
+#define memguard_unguard_range(_p,_l)  ((void)0)
+int guest_physmap_mark_populate_on_demand(struct domain *d, unsigned long gfn,
+                                          unsigned int order);
+
+extern void put_page_type(struct page_info *page);
+static inline void put_page_and_type(struct page_info *page)
+{
+    put_page_type(page);
+    put_page(page);
+}
+
+#endif /*  __ARCH_ARM_MM__ */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/p2m.h b/xen/include/asm-arm/p2m.h
new file mode 100644
index 0000000..aec52f7
--- /dev/null
+++ b/xen/include/asm-arm/p2m.h
@@ -0,0 +1,88 @@
+#ifndef _XEN_P2M_H
+#define _XEN_P2M_H
+
+#include <xen/mm.h>
+
+struct domain;
+
+/* Per-p2m-table state */
+struct p2m_domain {
+    /* Lock that protects updates to the p2m */
+    spinlock_t lock;
+
+    /* Pages used to construct the p2m */
+    struct page_list_head pages;
+
+    /* Root of p2m page tables, 2 contiguous pages */
+    struct page_info *first_level;
+
+    /* Current VMID in use */
+    uint8_t vmid;
+};
+
+/* Init the datastructures for later use by the p2m code */
+int p2m_init(struct domain *d);
+
+/* Allocate a new p2m table for a domain.
+ *
+ * Returns 0 for success or -errno.
+ */
+int p2m_alloc_table(struct domain *d);
+
+/* */
+void p2m_load_VTTBR(struct domain *d);
+
+/* Setup p2m RAM mapping for domain d from start-end. */
+int p2m_populate_ram(struct domain *d, paddr_t start, paddr_t end);
+/* Map MMIO regions in the p2m: start_gaddr and end_gaddr is the range
+ * in the guest physical address space to map, starting from the machine
+ * address maddr. */
+int map_mmio_regions(struct domain *d, paddr_t start_gaddr,
+                     paddr_t end_gaddr, paddr_t maddr);
+
+unsigned long gmfn_to_mfn(struct domain *d, unsigned long gpfn);
+
+/*
+ * Populate-on-demand
+ */
+
+/* Call when decreasing memory reservation to handle PoD entries properly.
+ * Will return '1' if all entries were handled and nothing more need be done.*/
+int
+p2m_pod_decrease_reservation(struct domain *d,
+                             xen_pfn_t gpfn,
+                             unsigned int order);
+
+/* Compatibility function exporting the old untyped interface */
+static inline unsigned long get_gfn_untyped(struct domain *d, unsigned long gpfn)
+{
+    return gmfn_to_mfn(d, gpfn);
+}
+
+int get_page_type(struct page_info *page, unsigned long type);
+int is_iomem_page(unsigned long mfn);
+static inline int get_page_and_type(struct page_info *page,
+                                    struct domain *domain,
+                                    unsigned long type)
+{
+    int rc = get_page(page, domain);
+
+    if ( likely(rc) && unlikely(!get_page_type(page, type)) )
+    {
+        put_page(page);
+        rc = 0;
+    }
+
+    return rc;
+}
+
+#endif /* _XEN_P2M_H */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/page.h b/xen/include/asm-arm/page.h
new file mode 100644
index 0000000..6dc1659
--- /dev/null
+++ b/xen/include/asm-arm/page.h
@@ -0,0 +1,335 @@
+#ifndef __ARM_PAGE_H__
+#define __ARM_PAGE_H__
+
+#include <xen/config.h>
+
+#define PADDR_BITS              40
+#define PADDR_MASK              ((1ULL << PADDR_BITS)-1)
+
+#define VADDR_BITS              32
+#define VADDR_MASK              (~0UL)
+
+/* Shareability values for the LPAE entries */
+#define LPAE_SH_NON_SHAREABLE 0x0
+#define LPAE_SH_UNPREDICTALE  0x1
+#define LPAE_SH_OUTER         0x2
+#define LPAE_SH_INNER         0x3
+
+/* LPAE Memory region attributes, to match Linux's (non-LPAE) choices.
+ * Indexed by the AttrIndex bits of a LPAE entry;
+ * the 8-bit fields are packed little-endian into MAIR0 and MAIR1
+ *
+ *                 ai    encoding
+ *   UNCACHED      000   0000 0000  -- Strongly Ordered
+ *   BUFFERABLE    001   0100 0100  -- Non-Cacheable
+ *   WRITETHROUGH  010   1010 1010  -- Write-through
+ *   WRITEBACK     011   1110 1110  -- Write-back
+ *   DEV_SHARED    100   0000 0100  -- Device
+ *   ??            101
+ *   reserved      110
+ *   WRITEALLOC    111   1111 1111  -- Write-back write-allocate
+ *
+ *   DEV_NONSHARED 100   (== DEV_SHARED)
+ *   DEV_WC        001   (== BUFFERABLE)
+ *   DEV_CACHED    011   (== WRITEBACK)
+ */
+#define MAIR0VAL 0xeeaa4400
+#define MAIR1VAL 0xff000004
+
+#define UNCACHED      0x0
+#define BUFFERABLE    0x1
+#define WRITETHROUGH  0x2
+#define WRITEBACK     0x3
+#define DEV_SHARED    0x4
+#define WRITEALLOC    0x7
+#define DEV_NONSHARED DEV_SHARED
+#define DEV_WC        BUFFERABLE
+#define DEV_CACHED    WRITEBACK
+
+
+#ifndef __ASSEMBLY__
+
+#include <xen/types.h>
+#include <xen/lib.h>
+
+/* WARNING!  Unlike the Intel pagetable code, where l1 is the lowest
+ * level and l4 is the root of the trie, the ARM pagetables follow ARM's
+ * documentation: the levels are called first, second &c in the order
+ * that the MMU walks them (i.e. "first" is the root of the trie). */
+
+/******************************************************************************
+ * ARMv7-A LPAE pagetables: 3-level trie, mapping 40-bit input to
+ * 40-bit output addresses.  Tables at all levels have 512 64-bit entries
+ * (i.e. are 4Kb long).
+ *
+ * The bit-shuffling that has the permission bits in branch nodes in a
+ * different place from those in leaf nodes seems to be to allow linear
+ * pagetable tricks.  If we're not doing that then the set of permission
+ * bits that's not in use in a given node type can be used as
+ * extra software-defined bits. */
+
+typedef struct {
+    /* These are used in all kinds of entry. */
+    unsigned long valid:1;      /* Valid mapping */
+    unsigned long table:1;      /* == 1 in 4k map entries too */
+
+    /* These ten bits are only used in Block entries and are ignored
+     * in Table entries. */
+    unsigned long ai:3;         /* Attribute Index */
+    unsigned long ns:1;         /* Not-Secure */
+    unsigned long user:1;       /* User-visible */
+    unsigned long ro:1;         /* Read-Only */
+    unsigned long sh:2;         /* Shareability */
+    unsigned long af:1;         /* Access Flag */
+    unsigned long ng:1;         /* Not-Global */
+
+    /* The base address must be approprately aligned for Block entries */
+    unsigned long base:28;      /* Base address of block or next table */
+    unsigned long sbz:12;       /* Must be zero */
+
+    /* These seven bits are only used in Block entries and are ignored
+     * in Table entries. */
+    unsigned long hint:1;       /* In a block of 16 contiguous entries */
+    unsigned long pxn:1;        /* Privileged-XN */
+    unsigned long xn:1;         /* eXecute-Never */
+    unsigned long avail:4;      /* Ignored by hardware */
+
+    /* These 5 bits are only used in Table entries and are ignored in
+     * Block entries */
+    unsigned long pxnt:1;       /* Privileged-XN */
+    unsigned long xnt:1;        /* eXecute-Never */
+    unsigned long apt:2;        /* Access Permissions */
+    unsigned long nst:1;        /* Not-Secure */
+} __attribute__((__packed__)) lpae_pt_t;
+
+/* The p2m tables have almost the same layout, but some of the permission
+ * and cache-control bits are laid out differently (or missing) */
+typedef struct {
+    /* These are used in all kinds of entry. */
+    unsigned long valid:1;      /* Valid mapping */
+    unsigned long table:1;      /* == 1 in 4k map entries too */
+
+    /* These ten bits are only used in Block entries and are ignored
+     * in Table entries. */
+    unsigned long mattr:4;      /* Memory Attributes */
+    unsigned long read:1;       /* Read access */
+    unsigned long write:1;      /* Write access */
+    unsigned long sh:2;         /* Shareability */
+    unsigned long af:1;         /* Access Flag */
+    unsigned long sbz4:1;
+
+    /* The base address must be approprately aligned for Block entries */
+    unsigned long base:28;      /* Base address of block or next table */
+    unsigned long sbz3:12;
+
+    /* These seven bits are only used in Block entries and are ignored
+     * in Table entries. */
+    unsigned long hint:1;       /* In a block of 16 contiguous entries */
+    unsigned long sbz2:1;
+    unsigned long xn:1;         /* eXecute-Never */
+    unsigned long avail:4;      /* Ignored by hardware */
+
+    unsigned long sbz1:5;
+} __attribute__((__packed__)) lpae_p2m_t;
+
+typedef union {
+    uint64_t bits;
+    lpae_pt_t pt;
+    lpae_p2m_t p2m;
+} lpae_t;
+
+/* Standard entry type that we'll use to build Xen's own pagetables.
+ * We put the same permissions at every level, because they're ignored
+ * by the walker in non-leaf entries. */
+static inline lpae_t mfn_to_xen_entry(unsigned long mfn)
+{
+    paddr_t pa = ((paddr_t) mfn) << PAGE_SHIFT;
+    lpae_t e = (lpae_t) {
+        .pt = {
+            .xn = 1,              /* No need to execute outside .text */
+            .ng = 1,              /* Makes TLB flushes easier */
+            .af = 1,              /* No need for access tracking */
+            .sh = LPAE_SH_OUTER,  /* Xen mappings are globally coherent */
+            .ns = 1,              /* Hyp mode is in the non-secure world */
+            .user = 1,            /* See below */
+            .ai = WRITEALLOC,
+            .table = 0,           /* Set to 1 for links and 4k maps */
+            .valid = 1,           /* Mappings are present */
+        }};;
+    /* Setting the User bit is strange, but the ATS1H[RW] instructions
+     * don't seem to work otherwise, and since we never run on Xen
+     * pagetables un User mode it's OK.  If this changes, remember
+     * to update the hard-coded values in head.S too */
+
+    ASSERT(!(pa & ~PAGE_MASK));
+    ASSERT(!(pa & ~PADDR_MASK));
+
+    // XXX shifts
+    e.bits |= pa;
+    return e;
+}
+
+static inline lpae_t mfn_to_p2m_entry(unsigned long mfn)
+{
+    paddr_t pa = ((paddr_t) mfn) << PAGE_SHIFT;
+    lpae_t e = (lpae_t) {
+        .p2m.xn = 0,
+        .p2m.af = 1,
+        .p2m.sh = LPAE_SH_OUTER,
+        .p2m.write = 1,
+        .p2m.read = 1,
+        .p2m.mattr = 0xf,
+        .p2m.table = 1,
+        .p2m.valid = 1,
+    };
+
+    ASSERT(!(pa & ~PAGE_MASK));
+    ASSERT(!(pa & ~PADDR_MASK));
+
+    e.bits |= pa;
+
+    return e;
+}
+
+/* Write a pagetable entry */
+static inline void write_pte(lpae_t *p, lpae_t pte)
+{
+    asm volatile (
+        /* Safely write the entry (STRD is atomic on CPUs that support LPAE) */
+        "strd %0, %H0, [%1];"
+        /* Push this cacheline to the PoC so the rest of the system sees it. */
+        STORE_CP32(1, DCCMVAC)
+        : : "r" (pte.bits), "r" (p) : "memory");
+}
+
+/*
+ * Flush all hypervisor mappings from the data TLB. This is not
+ * sufficient when changing code mappings or for self modifying code.
+ */
+static inline void flush_xen_data_tlb(void)
+{
+    register unsigned long r0 asm ("r0");
+    asm volatile("dsb;" /* Ensure preceding are visible */
+                 STORE_CP32(0, TLBIALLH)
+                 "dsb;" /* Ensure completion of the TLB flush */
+                 "isb;"
+                 : : "r" (r0) /* dummy */: "memory");
+}
+
+/*
+ * Flush one VA's hypervisor mappings from the data TLB. This is not
+ * sufficient when changing code mappings or for self modifying code.
+ */
+static inline void flush_xen_data_tlb_va(unsigned long va)
+{
+    asm volatile("dsb;" /* Ensure preceding are visible */
+                 STORE_CP32(0, TLBIMVAH)
+                 "dsb;" /* Ensure completion of the TLB flush */
+                 "isb;"
+                 : : "r" (va) : "memory");
+}
+
+/* Flush all non-hypervisor mappings from the TLB */
+static inline void flush_guest_tlb(void)
+{
+    register unsigned long r0 asm ("r0");
+    WRITE_CP32(r0 /* dummy */, TLBIALLNSNH);
+}
+
+/* Ask the MMU to translate a VA for us */
+static inline uint64_t __va_to_par(uint32_t va)
+{
+    uint64_t par, tmp;
+    tmp = READ_CP64(PAR);
+    WRITE_CP32(va, ATS1HR);
+    isb(); /* Ensure result is available. */
+    par = READ_CP64(PAR);
+    WRITE_CP64(tmp, PAR);
+    return par;
+}
+
+static inline uint64_t va_to_par(uint32_t va)
+{
+    uint64_t par = __va_to_par(va);
+    /* It is not OK to call this with an invalid VA */
+    if ( par & PAR_F ) panic_PAR(par, "Hypervisor");
+    return par;
+}
+
+/* Ask the MMU to translate a Guest VA for us */
+static inline uint64_t __gva_to_par(uint32_t va)
+{
+    uint64_t par, tmp;
+    tmp = READ_CP64(PAR);
+    WRITE_CP32(va, ATS12NSOPR);
+    isb(); /* Ensure result is available. */
+    par = READ_CP64(PAR);
+    WRITE_CP64(tmp, PAR);
+    return par;
+}
+static inline uint64_t gva_to_par(uint32_t va)
+{
+    uint64_t par = __gva_to_par(va);
+    /* It is not OK to call this with an invalid VA */
+    /* XXX harsh for a guest address... */
+    if ( par & PAR_F ) panic_PAR(par, "Guest");
+    return par;
+}
+static inline uint64_t __gva_to_ipa(uint32_t va)
+{
+    uint64_t par, tmp;
+    tmp = READ_CP64(PAR);
+    WRITE_CP32(va, ATS1CPR);
+    isb(); /* Ensure result is available. */
+    par = READ_CP64(PAR);
+    WRITE_CP64(tmp, PAR);
+    return par;
+}
+static inline uint64_t gva_to_ipa(uint32_t va)
+{
+    uint64_t par = __gva_to_ipa(va);
+    /* It is not OK to call this with an invalid VA */
+    /* XXX harsh for a guest address... */
+    if ( par & PAR_F ) panic_PAR(par, "Guest");
+    return (par & PADDR_MASK & PAGE_MASK) | ((unsigned long) va & ~PAGE_MASK);
+}
+/* Bits in the PAR returned by va_to_par */
+#define PAR_FAULT 0x1
+
+#endif /* __ASSEMBLY__ */
+
+/* These numbers add up to a 39-bit input address space.  The  ARMv7-A
+ * architecture actually specifies a 40-bit input address space for the p2m,
+ * with an 8K (1024-entry) top-level table. */
+
+#define LPAE_SHIFT      9
+#define LPAE_ENTRIES    (1u << LPAE_SHIFT)
+#define LPAE_ENTRY_MASK (LPAE_ENTRIES - 1)
+
+#define THIRD_SHIFT  PAGE_SHIFT
+#define SECOND_SHIFT (THIRD_SHIFT + LPAE_SHIFT)
+#define FIRST_SHIFT  (SECOND_SHIFT + LPAE_SHIFT)
+
+/* Calculate the offsets into the pagetables for a given VA */
+#define first_linear_offset(va) (va >> FIRST_SHIFT)
+#define second_linear_offset(va) (va >> SECOND_SHIFT)
+#define third_linear_offset(va) (va >> THIRD_SHIFT)
+#define first_table_offset(va) (first_linear_offset(va))
+#define second_table_offset(va) (second_linear_offset(va) & LPAE_ENTRY_MASK)
+#define third_table_offset(va) (third_linear_offset(va) & LPAE_ENTRY_MASK)
+
+#define clear_page(page)memset((void *)(page), 0, PAGE_SIZE)
+
+#define PAGE_ALIGN(x) (((x) + PAGE_SIZE - 1) & PAGE_MASK)
+
+#endif /* __ARM_PAGE_H__ */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 13:14:44 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 13:14:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZ0HS-0002Wo-JE; Fri, 09 Dec 2011 13:14:26 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RZ0HQ-0002Rp-2i
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 13:14:24 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1323436412!7454574!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDQ0MTg=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1851 invoked from network); 9 Dec 2011 13:13:33 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 13:13:33 -0000
X-IronPort-AV: E=Sophos;i="4.71,325,1320642000"; d="scan'208";a="19808906"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 08:13:31 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 08:13:31 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pB9DCpE3008248;
	Fri, 9 Dec 2011 05:13:19 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 9 Dec 2011 13:13:20 +0000
Message-ID: <1323436408-16335-17-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1112091208420.3517@kaball-desktop>
References: <alpine.DEB.2.00.1112091208420.3517@kaball-desktop>
MIME-Version: 1.0
Cc: keir.xen@gmail.com, Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, JBeulich@suse.com,
	Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v2 17/25] arm: mm and p2m
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Functions to setup pagetables, handle the p2m, map and unmap domain
pages, copy data to/from guest addresses.
The implementation is based on the LPAE extension for ARMv7 and makes
use of the two level transtion mechanism.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
---
 xen/arch/arm/domain.c              |    4 +
 xen/arch/arm/mm.c                  |  321 ++++++++++++++++++++++++++++++++++
 xen/arch/arm/p2m.c                 |  214 +++++++++++++++++++++++
 xen/arch/arm/usercopy.c            |   81 +++++++++
 xen/include/asm-arm/domain.h       |    2 +
 xen/include/asm-arm/guest_access.h |  125 +++++++++++++
 xen/include/asm-arm/mm.h           |  315 +++++++++++++++++++++++++++++++++
 xen/include/asm-arm/p2m.h          |   88 ++++++++++
 xen/include/asm-arm/page.h         |  335 ++++++++++++++++++++++++++++++++++++
 9 files changed, 1485 insertions(+), 0 deletions(-)
 create mode 100644 xen/arch/arm/mm.c
 create mode 100644 xen/arch/arm/p2m.c
 create mode 100644 xen/arch/arm/usercopy.c
 create mode 100644 xen/include/asm-arm/guest_access.h
 create mode 100644 xen/include/asm-arm/mm.h
 create mode 100644 xen/include/asm-arm/p2m.h
 create mode 100644 xen/include/asm-arm/page.h

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index ecbc5b7..0844b37 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -224,6 +224,10 @@ int arch_domain_create(struct domain *d, unsigned int domcr_flags)
 {
     int rc;
 
+    rc = -ENOMEM;
+    if ( (rc = p2m_init(d)) != 0 )
+        goto fail;
+
     d->max_vcpus = 8;
 
     rc = 0;
diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
new file mode 100644
index 0000000..613d084
--- /dev/null
+++ b/xen/arch/arm/mm.c
@@ -0,0 +1,321 @@
+/*
+ * xen/arch/arm/mm.c
+ *
+ * MMU code for an ARMv7-A with virt extensions.
+ *
+ * Tim Deegan <tim@xen.org>
+ * Copyright (c) 2011 Citrix Systems.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include <xen/config.h>
+#include <xen/compile.h>
+#include <xen/types.h>
+#include <xen/init.h>
+#include <xen/mm.h>
+#include <xen/preempt.h>
+#include <asm/page.h>
+#include <asm/current.h>
+
+struct domain *dom_xen, *dom_io;
+
+/* Static start-of-day pagetables that we use before the allocators are up */
+lpae_t xen_pgtable[LPAE_ENTRIES] __attribute__((__aligned__(4096)));
+lpae_t xen_second[LPAE_ENTRIES*4] __attribute__((__aligned__(4096*4)));
+static lpae_t xen_fixmap[LPAE_ENTRIES] __attribute__((__aligned__(4096)));
+static lpae_t xen_xenmap[LPAE_ENTRIES] __attribute__((__aligned__(4096)));
+
+/* Limits of the Xen heap */
+unsigned long xenheap_mfn_start, xenheap_mfn_end;
+unsigned long xenheap_virt_end;
+
+unsigned long frametable_virt_end;
+
+/* Map a 4k page in a fixmap entry */
+void set_fixmap(unsigned map, unsigned long mfn, unsigned attributes)
+{
+    lpae_t pte = mfn_to_xen_entry(mfn);
+    pte.pt.table = 1; /* 4k mappings always have this bit set */
+    pte.pt.ai = attributes;
+    write_pte(xen_fixmap + third_table_offset(FIXMAP_ADDR(map)), pte);
+    flush_xen_data_tlb_va(FIXMAP_ADDR(map));
+}
+
+/* Remove a mapping from a fixmap entry */
+void clear_fixmap(unsigned map)
+{
+    lpae_t pte = {0};
+    write_pte(xen_fixmap + third_table_offset(FIXMAP_ADDR(map)), pte);
+    flush_xen_data_tlb_va(FIXMAP_ADDR(map));
+}
+
+/* Map a page of domheap memory */
+void *map_domain_page(unsigned long mfn)
+{
+    unsigned long flags;
+    lpae_t *map = xen_second + second_linear_offset(DOMHEAP_VIRT_START);
+    unsigned long slot_mfn = mfn & ~LPAE_ENTRY_MASK;
+    uint32_t va;
+    lpae_t pte;
+    int i, slot;
+
+    local_irq_save(flags);
+
+    /* The map is laid out as an open-addressed hash table where each
+     * entry is a 2MB superpage pte.  We use the available bits of each
+     * PTE as a reference count; when the refcount is zero the slot can
+     * be reused. */
+    for ( slot = (slot_mfn >> LPAE_SHIFT) % DOMHEAP_ENTRIES, i = 0;
+          i < DOMHEAP_ENTRIES;
+          slot = (slot + 1) % DOMHEAP_ENTRIES, i++ )
+    {
+        if ( map[slot].pt.avail == 0 )
+        {
+            /* Commandeer this 2MB slot */
+            pte = mfn_to_xen_entry(slot_mfn);
+            pte.pt.avail = 1;
+            write_pte(map + slot, pte);
+            break;
+        }
+        else if ( map[slot].pt.avail < 0xf && map[slot].pt.base == slot_mfn )
+        {
+            /* This slot already points to the right place; reuse it */
+            map[slot].pt.avail++;
+            break;
+        }
+    }
+    /* If the map fills up, the callers have misbehaved. */
+    BUG_ON(i == DOMHEAP_ENTRIES);
+
+#ifndef NDEBUG
+    /* Searching the hash could get slow if the map starts filling up.
+     * Cross that bridge when we come to it */
+    {
+        static int max_tries = 32;
+        if ( i >= max_tries )
+        {
+            dprintk(XENLOG_WARNING, "Domheap map is filling: %i tries\n", i);
+            max_tries *= 2;
+        }
+    }
+#endif
+
+    local_irq_restore(flags);
+
+    va = (DOMHEAP_VIRT_START
+          + (slot << SECOND_SHIFT)
+          + ((mfn & LPAE_ENTRY_MASK) << THIRD_SHIFT));
+
+    /*
+     * We may not have flushed this specific subpage at map time,
+     * since we only flush the 4k page not the superpage
+     */
+    flush_xen_data_tlb_va(va);
+
+    return (void *)va;
+}
+
+/* Release a mapping taken with map_domain_page() */
+void unmap_domain_page(const void *va)
+{
+    unsigned long flags;
+    lpae_t *map = xen_second + second_linear_offset(DOMHEAP_VIRT_START);
+    int slot = ((unsigned long) va - DOMHEAP_VIRT_START) >> SECOND_SHIFT;
+
+    local_irq_save(flags);
+
+    ASSERT(slot >= 0 && slot < DOMHEAP_ENTRIES);
+    ASSERT(map[slot].pt.avail != 0);
+
+    map[slot].pt.avail--;
+
+    local_irq_restore(flags);
+}
+
+
+/* Boot-time pagetable setup.
+ * Changes here may need matching changes in head.S */
+void __init setup_pagetables(unsigned long boot_phys_offset)
+{
+    paddr_t xen_paddr, phys_offset;
+    unsigned long dest_va;
+    lpae_t pte, *p;
+    int i;
+
+    if ( boot_phys_offset != 0 )
+    {
+        /* Remove the old identity mapping of the boot paddr */
+        pte.bits = 0;
+        dest_va = (unsigned long)_start + boot_phys_offset;
+        write_pte(xen_second + second_linear_offset(dest_va), pte);
+    }
+
+    xen_paddr = XEN_PADDR;
+
+    /* Map the destination in the empty L2 above the fixmap */
+    dest_va = FIXMAP_ADDR(0) + (1u << SECOND_SHIFT);
+    pte = mfn_to_xen_entry(xen_paddr >> PAGE_SHIFT);
+    write_pte(xen_second + second_table_offset(dest_va), pte);
+
+    /* Calculate virt-to-phys offset for the new location */
+    phys_offset = xen_paddr - (unsigned long) _start;
+
+    /* Copy */
+    memcpy((void *) dest_va, _start, _end - _start);
+
+    /* Beware!  Any state we modify between now and the PT switch may be
+     * discarded when we switch over to the copy. */
+
+    /* Update the copy of xen_pgtable to use the new paddrs */
+    p = (void *) xen_pgtable + dest_va - (unsigned long) _start;
+    for ( i = 0; i < 4; i++)
+        p[i].pt.base += (phys_offset - boot_phys_offset) >> PAGE_SHIFT;
+    p = (void *) xen_second + dest_va - (unsigned long) _start;
+    for ( i = 0; i < 4 * LPAE_ENTRIES; i++)
+        if ( p[i].pt.valid )
+                p[i].pt.base += (phys_offset - boot_phys_offset) >> PAGE_SHIFT;
+
+    /* Change pagetables to the copy in the relocated Xen */
+    asm volatile (
+        STORE_CP64(0, HTTBR)          /* Change translation base */
+        "dsb;"                        /* Ensure visibility of HTTBR update */
+        STORE_CP32(0, TLBIALLH)       /* Flush hypervisor TLB */
+        STORE_CP32(0, BPIALL)         /* Flush branch predictor */
+        "dsb;"                        /* Ensure completion of TLB+BP flush */
+        "isb;"
+        : : "r" ((unsigned long) xen_pgtable + phys_offset) : "memory");
+
+    /* Undo the temporary map */
+    pte.bits = 0;
+    write_pte(xen_second + second_table_offset(dest_va), pte);
+    /*
+     * Have removed a mapping previously used for .text. Flush everything
+     * for safety.
+     */
+    asm volatile (
+        "dsb;"                        /* Ensure visibility of PTE write */
+        STORE_CP32(0, TLBIALLH)       /* Flush hypervisor TLB */
+        STORE_CP32(0, BPIALL)         /* Flush branch predictor */
+        "dsb;"                        /* Ensure completion of TLB+BP flush */
+        "isb;"
+        : : "r" (i /*dummy*/) : "memory");
+
+    /* Link in the fixmap pagetable */
+    pte = mfn_to_xen_entry((((unsigned long) xen_fixmap) + phys_offset)
+                           >> PAGE_SHIFT);
+    pte.pt.table = 1;
+    write_pte(xen_second + second_table_offset(FIXMAP_ADDR(0)), pte);
+    /*
+     * No flush required here. Individual flushes are done in
+     * set_fixmap as entries are used.
+     */
+
+    /* Break up the Xen mapping into 4k pages and protect them separately. */
+    for ( i = 0; i < LPAE_ENTRIES; i++ )
+    {
+        unsigned long mfn = paddr_to_pfn(xen_paddr) + i;
+        unsigned long va = XEN_VIRT_START + (i << PAGE_SHIFT);
+        if ( !is_kernel(va) )
+            break;
+        pte = mfn_to_xen_entry(mfn);
+        pte.pt.table = 1; /* 4k mappings always have this bit set */
+        if ( is_kernel_text(va) || is_kernel_inittext(va) )
+        {
+            pte.pt.xn = 0;
+            pte.pt.ro = 1;
+        }
+        if ( is_kernel_rodata(va) )
+            pte.pt.ro = 1;
+        write_pte(xen_xenmap + i, pte);
+        /* No flush required here as page table is not hooked in yet. */
+    }
+    pte = mfn_to_xen_entry((((unsigned long) xen_xenmap) + phys_offset)
+                           >> PAGE_SHIFT);
+    pte.pt.table = 1;
+    write_pte(xen_second + second_linear_offset(XEN_VIRT_START), pte);
+    /* Have changed a mapping used for .text. Flush everything for safety. */
+    asm volatile (
+        "dsb;"                        /* Ensure visibility of PTE write */
+        STORE_CP32(0, TLBIALLH)       /* Flush hypervisor TLB */
+        STORE_CP32(0, BPIALL)         /* Flush branch predictor */
+        "dsb;"                        /* Ensure completion of TLB+BP flush */
+        "isb;"
+        : : "r" (i /*dummy*/) : "memory");
+
+    /* From now on, no mapping may be both writable and executable. */
+    WRITE_CP32(READ_CP32(HSCTLR) | SCTLR_WXN, HSCTLR);
+}
+
+/* Create Xen's mappings of memory.
+ * Base and virt must be 32MB aligned and size a multiple of 32MB. */
+static void __init create_mappings(unsigned long virt,
+                                   unsigned long base_mfn,
+                                   unsigned long nr_mfns)
+{
+    unsigned long i, count;
+    lpae_t pte, *p;
+
+    ASSERT(!((virt >> PAGE_SHIFT) % (16 * LPAE_ENTRIES)));
+    ASSERT(!(base_mfn % (16 * LPAE_ENTRIES)));
+    ASSERT(!(nr_mfns % (16 * LPAE_ENTRIES)));
+
+    count = nr_mfns / LPAE_ENTRIES;
+    p = xen_second + second_linear_offset(virt);
+    pte = mfn_to_xen_entry(base_mfn);
+    pte.pt.hint = 1;  /* These maps are in 16-entry contiguous chunks. */
+    for ( i = 0; i < count; i++ )
+    {
+        write_pte(p + i, pte);
+        pte.pt.base += 1 << LPAE_SHIFT;
+    }
+    flush_xen_data_tlb();
+}
+
+/* Set up the xenheap: up to 1GB of contiguous, always-mapped memory. */
+void __init setup_xenheap_mappings(unsigned long base_mfn,
+                                   unsigned long nr_mfns)
+{
+    create_mappings(XENHEAP_VIRT_START, base_mfn, nr_mfns);
+
+    /* Record where the xenheap is, for translation routines. */
+    xenheap_virt_end = XENHEAP_VIRT_START + nr_mfns * PAGE_SIZE;
+    xenheap_mfn_start = base_mfn;
+    xenheap_mfn_end = base_mfn + nr_mfns;
+}
+
+/* Map a frame table to cover physical addresses ps through pe */
+void __init setup_frametable_mappings(paddr_t ps, paddr_t pe)
+{
+    unsigned long nr_pages = (pe - ps) >> PAGE_SHIFT;
+    unsigned long frametable_size = nr_pages * sizeof(struct page_info);
+    unsigned long base_mfn;
+
+    /* Round up to 32M boundary */
+    frametable_size = (frametable_size + 0x1ffffff) & ~0x1ffffff;
+    base_mfn = alloc_boot_pages(frametable_size >> PAGE_SHIFT, 5);
+    create_mappings(FRAMETABLE_VIRT_START, base_mfn, frametable_size >> PAGE_SHIFT);
+
+    memset(&frame_table[0], 0, nr_pages * sizeof(struct page_info));
+    memset(&frame_table[nr_pages], -1,
+           frametable_size - (nr_pages * sizeof(struct page_info)));
+
+    frametable_virt_end = FRAMETABLE_VIRT_START + (nr_pages * sizeof(struct page_info));
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
new file mode 100644
index 0000000..a1d026d
--- /dev/null
+++ b/xen/arch/arm/p2m.c
@@ -0,0 +1,214 @@
+#include <xen/config.h>
+#include <xen/sched.h>
+#include <xen/lib.h>
+#include <xen/errno.h>
+#include <xen/domain_page.h>
+
+void p2m_load_VTTBR(struct domain *d)
+{
+    struct p2m_domain *p2m = &d->arch.p2m;
+    paddr_t maddr = page_to_maddr(p2m->first_level);
+    uint64_t vttbr = maddr;
+
+    vttbr |= ((uint64_t)p2m->vmid&0xff)<<48;
+
+    printk("VTTBR dom%d = %"PRIx64"\n", d->domain_id, vttbr);
+
+    WRITE_CP64(vttbr, VTTBR);
+    isb(); /* Ensure update is visible */
+}
+
+static int p2m_create_entry(struct domain *d,
+                            lpae_t *entry)
+{
+    struct p2m_domain *p2m = &d->arch.p2m;
+    struct page_info *page;
+    void *p;
+    lpae_t pte;
+
+    BUG_ON(entry->p2m.valid);
+
+    page = alloc_domheap_page(d, 0);
+    if ( page == NULL )
+        return -ENOMEM;
+
+    page_list_add(page, &p2m->pages);
+
+    p = __map_domain_page(page);
+    clear_page(p);
+    unmap_domain_page(p);
+
+    pte = mfn_to_p2m_entry(page_to_mfn(page));
+
+    write_pte(entry, pte);
+
+    return 0;
+}
+
+static int create_p2m_entries(struct domain *d,
+                     int alloc,
+                     paddr_t start_gpaddr,
+                     paddr_t end_gpaddr,
+                     paddr_t maddr)
+{
+    int rc;
+    struct p2m_domain *p2m = &d->arch.p2m;
+    lpae_t *first = NULL, *second = NULL, *third = NULL;
+    paddr_t addr;
+    unsigned long cur_first_offset = ~0, cur_second_offset = ~0;
+
+    /* XXX Don't actually handle 40 bit guest physical addresses */
+    BUG_ON(start_gpaddr & 0x8000000000ULL);
+    BUG_ON(end_gpaddr   & 0x8000000000ULL);
+
+    first = __map_domain_page(p2m->first_level);
+
+    for(addr = start_gpaddr; addr < end_gpaddr; addr += PAGE_SIZE)
+    {
+        if ( !first[first_table_offset(addr)].p2m.valid )
+        {
+            rc = p2m_create_entry(d, &first[first_table_offset(addr)]);
+            if ( rc < 0 ) {
+                printk("p2m_populate_ram: L1 failed\n");
+                goto out;
+            }
+        }
+
+        BUG_ON(!first[first_table_offset(addr)].p2m.valid);
+
+        if ( cur_first_offset != first_table_offset(addr) )
+        {
+            if (second) unmap_domain_page(second);
+            second = map_domain_page(first[first_table_offset(addr)].p2m.base);
+            cur_first_offset = first_table_offset(addr);
+        }
+        /* else: second already valid */
+
+        if ( !second[second_table_offset(addr)].p2m.valid )
+        {
+            rc = p2m_create_entry(d, &second[second_table_offset(addr)]);
+            if ( rc < 0 ) {
+                printk("p2m_populate_ram: L2 failed\n");
+                goto out;
+            }
+        }
+
+        BUG_ON(!second[second_table_offset(addr)].p2m.valid);
+
+        if ( cur_second_offset != second_table_offset(addr) )
+        {
+            /* map third level */
+            if (third) unmap_domain_page(third);
+            third = map_domain_page(second[second_table_offset(addr)].p2m.base);
+            cur_second_offset = second_table_offset(addr);
+        }
+        /* else: third already valid */
+
+        BUG_ON(third[third_table_offset(addr)].p2m.valid);
+
+        /* Allocate a new RAM page and attach */
+        if (alloc)
+        {
+            struct page_info *page;
+            lpae_t pte;
+
+            rc = -ENOMEM;
+            page = alloc_domheap_page(d, 0);
+            if ( page == NULL ) {
+                printk("p2m_populate_ram: failed to allocate page\n");
+                goto out;
+            }
+
+            pte = mfn_to_p2m_entry(page_to_mfn(page));
+
+            write_pte(&third[third_table_offset(addr)], pte);
+        } else {
+            lpae_t pte = mfn_to_p2m_entry(maddr >> PAGE_SHIFT);
+            write_pte(&third[third_table_offset(addr)], pte);
+            maddr += PAGE_SIZE;
+        }
+    }
+
+    rc = 0;
+
+out:
+    spin_lock(&p2m->lock);
+
+    if (third) unmap_domain_page(third);
+    if (second) unmap_domain_page(second);
+    if (first) unmap_domain_page(first);
+
+    spin_unlock(&p2m->lock);
+
+    return rc;
+}
+
+int p2m_populate_ram(struct domain *d,
+                     paddr_t start,
+                     paddr_t end)
+{
+    return create_p2m_entries(d, 1, start, end, 0);
+}
+
+int map_mmio_regions(struct domain *d,
+                     paddr_t start_gaddr,
+                     paddr_t end_gaddr,
+                     paddr_t maddr)
+{
+    return create_p2m_entries(d, 0, start_gaddr, end_gaddr, maddr);
+}
+
+int p2m_alloc_table(struct domain *d)
+{
+    struct p2m_domain *p2m = &d->arch.p2m;
+    struct page_info *page;
+    void *p;
+
+    /* First level P2M is 2 consecutive pages */
+    page = alloc_domheap_pages(d, 1, 0);
+    if ( page == NULL )
+        return -ENOMEM;
+
+    spin_lock(&p2m->lock);
+
+    page_list_add(page, &p2m->pages);
+
+    /* Clear both first level pages */
+    p = __map_domain_page(page);
+    clear_page(p);
+    unmap_domain_page(p);
+
+    p = __map_domain_page(page + 1);
+    clear_page(p);
+    unmap_domain_page(p);
+
+    p2m->first_level = page;
+
+    spin_unlock(&p2m->lock);
+
+    return 0;
+}
+
+int p2m_init(struct domain *d)
+{
+    struct p2m_domain *p2m = &d->arch.p2m;
+
+    spin_lock_init(&p2m->lock);
+    INIT_PAGE_LIST_HEAD(&p2m->pages);
+
+    /* XXX allocate properly */
+    /* Zero is reserved */
+    p2m->vmid = d->domain_id + 1;
+
+    p2m->first_level = NULL;
+
+    return 0;
+}
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/arch/arm/usercopy.c b/xen/arch/arm/usercopy.c
new file mode 100644
index 0000000..6f51e0f
--- /dev/null
+++ b/xen/arch/arm/usercopy.c
@@ -0,0 +1,81 @@
+#include <xen/config.h>
+#include <xen/lib.h>
+#include <xen/domain_page.h>
+
+#include <asm/mm.h>
+#include <asm/guest_access.h>
+
+unsigned long copy_to_user(void __user *to, const void *from, unsigned len)
+{
+    /* XXX needs to handle faults */
+    unsigned offset = ((unsigned long)to & ~PAGE_MASK);
+
+    while ( len )
+    {
+        paddr_t g = gvirt_to_maddr((uint32_t) to);
+        void *p = map_domain_page(g>>PAGE_SHIFT);
+        unsigned size = min(len, (unsigned)PAGE_SIZE - offset);
+
+        p += offset;
+        memcpy(p, from, size);
+
+        unmap_domain_page(p - offset);
+        len -= size;
+        from += size;
+        to += size;
+        offset = 0;
+    }
+
+    return 0;
+}
+
+unsigned long clear_user(void __user *to, unsigned len)
+{
+    /* XXX needs to handle faults */
+    unsigned offset = ((unsigned long)to & ~PAGE_MASK);
+
+    while ( len )
+    {
+        paddr_t g = gvirt_to_maddr((uint32_t) to);
+        void *p = map_domain_page(g>>PAGE_SHIFT);
+        unsigned size = min(len, (unsigned)PAGE_SIZE - offset);
+
+        p += offset;
+        memset(p, 0x00, size);
+
+        unmap_domain_page(p - offset);
+        len -= size;
+        to += size;
+        offset = 0;
+    }
+
+    return 0;
+}
+
+unsigned long copy_from_user(void *to, const void __user *from, unsigned len)
+{
+    while ( len )
+    {
+        paddr_t g = gvirt_to_maddr((uint32_t) from & PAGE_MASK);
+        void *p = map_domain_page(g>>PAGE_SHIFT);
+        unsigned size = min(len, (unsigned)(PAGE_SIZE - ((unsigned)from & (~PAGE_MASK))));
+
+        p += ((unsigned long)from & (~PAGE_MASK));
+
+        memcpy(to, p, size);
+
+        unmap_domain_page(p);
+        len -= size;
+        from += size;
+        to += size;
+    }
+    return 0;
+}
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
index c226bdf..2226a24 100644
--- a/xen/include/asm-arm/domain.h
+++ b/xen/include/asm-arm/domain.h
@@ -16,6 +16,8 @@ struct pending_irq
 
 struct arch_domain
 {
+    struct p2m_domain p2m;
+
 }  __cacheline_aligned;
 
 struct arch_vcpu
diff --git a/xen/include/asm-arm/guest_access.h b/xen/include/asm-arm/guest_access.h
new file mode 100644
index 0000000..b8d4e63
--- /dev/null
+++ b/xen/include/asm-arm/guest_access.h
@@ -0,0 +1,125 @@
+#ifndef __ASM_ARM_GUEST_ACCESS_H__
+#define __ASM_ARM_GUEST_ACCESS_H__
+
+#include <xen/errno.h>
+
+/* Guests have their own comlete address space */
+#define access_ok(addr,size) (1)
+
+#define array_access_ok(addr,count,size) \
+    (likely(count < (~0UL/size)) && access_ok(addr,count*size))
+
+unsigned long copy_to_user(void *to, const void *from, unsigned len);
+unsigned long copy_from_user(void *to, const void *from, unsigned len);
+unsigned long clear_user(void *to, unsigned len);
+
+/* Raw access functions: no type checking. */
+/* All accesses are HVM type in ARM */
+#define raw_copy_to_guest(dst, src, len)        \
+    copy_to_user((dst), (src), (len))
+#define raw_copy_from_guest(dst, src, len)      \
+    copy_from_user((dst), (src), (len))
+#define __raw_copy_to_guest(dst, src, len)      \
+    copy_to_user((dst), (src), (len))
+#define __raw_copy_from_guest(dst, src, len)    \
+    copy_from_user((dst), (src), (len))
+
+/* Remainder copied from x86 -- could be common? */
+
+/* Is the guest handle a NULL reference? */
+#define guest_handle_is_null(hnd)        ((hnd).p == NULL)
+
+/* Offset the given guest handle into the array it refers to. */
+#define guest_handle_add_offset(hnd, nr) ((hnd).p += (nr))
+#define guest_handle_subtract_offset(hnd, nr) ((hnd).p -= (nr))
+
+/* Cast a guest handle to the specified type of handle. */
+#define guest_handle_cast(hnd, type) ({         \
+    type *_x = (hnd).p;                         \
+    (XEN_GUEST_HANDLE(type)) { _x };            \
+})
+
+#define guest_handle_from_ptr(ptr, type)        \
+    ((XEN_GUEST_HANDLE(type)) { (type *)ptr })
+#define const_guest_handle_from_ptr(ptr, type)  \
+    ((XEN_GUEST_HANDLE(const_##type)) { (const type *)ptr })
+
+/*
+ * Copy an array of objects to guest context via a guest handle,
+ * specifying an offset into the guest array.
+ */
+#define copy_to_guest_offset(hnd, off, ptr, nr) ({      \
+    const typeof(*(ptr)) *_s = (ptr);                   \
+    char (*_d)[sizeof(*_s)] = (void *)(hnd).p;          \
+    ((void)((hnd).p == (ptr)));                         \
+    raw_copy_to_guest(_d+(off), _s, sizeof(*_s)*(nr));  \
+})
+
+/*
+ * Copy an array of objects from guest context via a guest handle,
+ * specifying an offset into the guest array.
+ */
+#define copy_from_guest_offset(ptr, hnd, off, nr) ({    \
+    const typeof(*(ptr)) *_s = (hnd).p;                 \
+    typeof(*(ptr)) *_d = (ptr);                         \
+    raw_copy_from_guest(_d, _s+(off), sizeof(*_d)*(nr));\
+})
+
+/* Copy sub-field of a structure to guest context via a guest handle. */
+#define copy_field_to_guest(hnd, ptr, field) ({         \
+    const typeof(&(ptr)->field) _s = &(ptr)->field;     \
+    void *_d = &(hnd).p->field;                         \
+    ((void)(&(hnd).p->field == &(ptr)->field));         \
+    raw_copy_to_guest(_d, _s, sizeof(*_s));             \
+})
+
+/* Copy sub-field of a structure from guest context via a guest handle. */
+#define copy_field_from_guest(ptr, hnd, field) ({       \
+    const typeof(&(ptr)->field) _s = &(hnd).p->field;   \
+    typeof(&(ptr)->field) _d = &(ptr)->field;           \
+    raw_copy_from_guest(_d, _s, sizeof(*_d));           \
+})
+
+/*
+ * Pre-validate a guest handle.
+ * Allows use of faster __copy_* functions.
+ */
+/* All ARM guests are paging mode external and hence safe */
+#define guest_handle_okay(hnd, nr) (1)
+#define guest_handle_subrange_okay(hnd, first, last) (1)
+
+#define __copy_to_guest_offset(hnd, off, ptr, nr) ({    \
+    const typeof(*(ptr)) *_s = (ptr);                   \
+    char (*_d)[sizeof(*_s)] = (void *)(hnd).p;          \
+    ((void)((hnd).p == (ptr)));                         \
+    __raw_copy_to_guest(_d+(off), _s, sizeof(*_s)*(nr));\
+})
+
+#define __copy_from_guest_offset(ptr, hnd, off, nr) ({  \
+    const typeof(*(ptr)) *_s = (hnd).p;                 \
+    typeof(*(ptr)) *_d = (ptr);                         \
+    __raw_copy_from_guest(_d, _s+(off), sizeof(*_d)*(nr));\
+})
+
+#define __copy_field_to_guest(hnd, ptr, field) ({       \
+    const typeof(&(ptr)->field) _s = &(ptr)->field;     \
+    void *_d = &(hnd).p->field;                         \
+    ((void)(&(hnd).p->field == &(ptr)->field));         \
+    __raw_copy_to_guest(_d, _s, sizeof(*_s));           \
+})
+
+#define __copy_field_from_guest(ptr, hnd, field) ({     \
+    const typeof(&(ptr)->field) _s = &(hnd).p->field;   \
+    typeof(&(ptr)->field) _d = &(ptr)->field;           \
+    __raw_copy_from_guest(_d, _s, sizeof(*_d));         \
+})
+
+#endif /* __ASM_ARM_GUEST_ACCESS_H__ */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/mm.h b/xen/include/asm-arm/mm.h
new file mode 100644
index 0000000..ead6e0c
--- /dev/null
+++ b/xen/include/asm-arm/mm.h
@@ -0,0 +1,315 @@
+#ifndef __ARCH_ARM_MM__
+#define __ARCH_ARM_MM__
+
+#include <xen/config.h>
+#include <xen/kernel.h>
+#include <asm/page.h>
+#include <public/xen.h>
+
+/* Find a suitable place at the top of memory for Xen to live */
+/* XXX For now, use the top of the VE's 4GB RAM, at a 40-bit alias */
+#define XEN_PADDR 0x80ffe00000ull
+
+/*
+ * Per-page-frame information.
+ *
+ * Every architecture must ensure the following:
+ *  1. 'struct page_info' contains a 'struct page_list_entry list'.
+ *  2. Provide a PFN_ORDER() macro for accessing the order of a free page.
+ */
+#define PFN_ORDER(_pfn) ((_pfn)->v.free.order)
+
+struct page_info
+{
+    /* Each frame can be threaded onto a doubly-linked list. */
+    struct page_list_entry list;
+
+    /* Reference count and various PGC_xxx flags and fields. */
+    unsigned long count_info;
+
+    /* Context-dependent fields follow... */
+    union {
+        /* Page is in use: ((count_info & PGC_count_mask) != 0). */
+        struct {
+            /* Type reference count and various PGT_xxx flags and fields. */
+            unsigned long type_info;
+        } inuse;
+        /* Page is on a free list: ((count_info & PGC_count_mask) == 0). */
+        struct {
+            /* Do TLBs need flushing for safety before next page use? */
+            bool_t need_tlbflush;
+        } free;
+
+    } u;
+
+    union {
+        /* Page is in use, but not as a shadow. */
+        struct {
+            /* Owner of this page (zero if page is anonymous). */
+            struct domain *domain;
+        } inuse;
+
+        /* Page is on a free list. */
+        struct {
+            /* Order-size of the free chunk this page is the head of. */
+            unsigned int order;
+        } free;
+
+    } v;
+
+    union {
+        /*
+         * Timestamp from 'TLB clock', used to avoid extra safety flushes.
+         * Only valid for: a) free pages, and b) pages with zero type count
+         */
+        u32 tlbflush_timestamp;
+    };
+    u64 pad;
+};
+
+#define PG_shift(idx)   (BITS_PER_LONG - (idx))
+#define PG_mask(x, idx) (x ## UL << PG_shift(idx))
+
+#define PGT_none          PG_mask(0, 4)  /* no special uses of this page   */
+#define PGT_writable_page PG_mask(7, 4)  /* has writable mappings?         */
+#define PGT_shared_page   PG_mask(8, 4)  /* CoW sharable page              */
+#define PGT_type_mask     PG_mask(15, 4) /* Bits 28-31 or 60-63.           */
+
+ /* Owning guest has pinned this page to its current type? */
+#define _PGT_pinned       PG_shift(5)
+#define PGT_pinned        PG_mask(1, 5)
+
+ /* Count of uses of this frame as its current type. */
+#define PGT_count_width   PG_shift(9)
+#define PGT_count_mask    ((1UL<<PGT_count_width)-1)
+
+ /* Cleared when the owning guest 'frees' this page. */
+#define _PGC_allocated    PG_shift(1)
+#define PGC_allocated     PG_mask(1, 1)
+  /* Page is Xen heap? */
+#define _PGC_xen_heap     PG_shift(2)
+#define PGC_xen_heap      PG_mask(1, 2)
+/* ... */
+/* Page is broken? */
+#define _PGC_broken       PG_shift(7)
+#define PGC_broken        PG_mask(1, 7)
+ /* Mutually-exclusive page states: { inuse, offlining, offlined, free }. */
+#define PGC_state         PG_mask(3, 9)
+#define PGC_state_inuse   PG_mask(0, 9)
+#define PGC_state_offlining PG_mask(1, 9)
+#define PGC_state_offlined PG_mask(2, 9)
+#define PGC_state_free    PG_mask(3, 9)
+#define page_state_is(pg, st) (((pg)->count_info&PGC_state) == PGC_state_##st)
+
+/* Count of references to this frame. */
+#define PGC_count_width   PG_shift(9)
+#define PGC_count_mask    ((1UL<<PGC_count_width)-1)
+
+extern unsigned long xenheap_mfn_start, xenheap_mfn_end;
+extern unsigned long xenheap_virt_end;
+
+#define is_xen_heap_page(page) is_xen_heap_mfn(page_to_mfn(page))
+#define is_xen_heap_mfn(mfn) ({                                 \
+    unsigned long _mfn = (mfn);                                 \
+    (_mfn >= xenheap_mfn_start && _mfn < xenheap_mfn_end);      \
+})
+#define is_xen_fixed_mfn(mfn) is_xen_heap_mfn(mfn)
+
+#define page_get_owner(_p)    (_p)->v.inuse.domain
+#define page_set_owner(_p,_d) ((_p)->v.inuse.domain = (_d))
+
+#define maddr_get_owner(ma)   (page_get_owner(maddr_to_page((ma))))
+#define vaddr_get_owner(va)   (page_get_owner(virt_to_page((va))))
+
+#define XENSHARE_writable 0
+#define XENSHARE_readonly 1
+extern void share_xen_page_with_guest(
+    struct page_info *page, struct domain *d, int readonly);
+extern void share_xen_page_with_privileged_guests(
+    struct page_info *page, int readonly);
+
+#define frame_table ((struct page_info *)FRAMETABLE_VIRT_START)
+
+extern unsigned long max_page;
+extern unsigned long total_pages;
+
+/* Boot-time pagetable setup */
+extern void setup_pagetables(unsigned long boot_phys_offset);
+/* Set up the xenheap: up to 1GB of contiguous, always-mapped memory.
+ * Base must be 32MB aligned and size a multiple of 32MB. */
+extern void setup_xenheap_mappings(unsigned long base_mfn, unsigned long nr_mfns);
+/* Map a frame table to cover physical addresses ps through pe */
+extern void setup_frametable_mappings(paddr_t ps, paddr_t pe);
+/* Map a 4k page in a fixmap entry */
+extern void set_fixmap(unsigned map, unsigned long mfn, unsigned attributes);
+/* Remove a mapping from a fixmap entry */
+extern void clear_fixmap(unsigned map);
+
+
+#define mfn_valid(mfn)        ({                                              \
+    unsigned long __m_f_n = (mfn);                                            \
+    likely(__m_f_n < max_page);                                               \
+})
+
+#define max_pdx                 max_page
+/* XXX Assume everything in the 40-bit physical alias 0x8000000000 for now */
+#define pfn_to_pdx(pfn)         ((pfn) - 0x8000000UL)
+#define pdx_to_pfn(pdx)         ((pdx) + 0x8000000UL)
+#define virt_to_pdx(va)         virt_to_mfn(va)
+#define pdx_to_virt(pdx)        mfn_to_virt(pdx)
+
+/* Convert between machine frame numbers and page-info structures. */
+#define mfn_to_page(mfn)  (frame_table + pfn_to_pdx(mfn))
+#define page_to_mfn(pg)   pdx_to_pfn((unsigned long)((pg) - frame_table))
+#define __page_to_mfn(pg)  page_to_mfn(pg)
+#define __mfn_to_page(mfn) mfn_to_page(mfn)
+
+/* Convert between machine addresses and page-info structures. */
+#define maddr_to_page(ma) __mfn_to_page((ma) >> PAGE_SHIFT)
+#define page_to_maddr(pg) ((paddr_t)__page_to_mfn(pg) << PAGE_SHIFT)
+
+/* Convert between frame number and address formats.  */
+#define pfn_to_paddr(pfn) ((paddr_t)(pfn) << PAGE_SHIFT)
+#define paddr_to_pfn(pa)  ((unsigned long)((pa) >> PAGE_SHIFT))
+#define paddr_to_pdx(pa)    pfn_to_pdx(paddr_to_pfn(pa))
+
+
+static inline paddr_t virt_to_maddr(void *va)
+{
+    uint64_t par = va_to_par((uint32_t)va);
+    return (par & PADDR_MASK & PAGE_MASK) | ((unsigned long) va & ~PAGE_MASK);
+}
+
+static inline void *maddr_to_virt(paddr_t ma)
+{
+    ASSERT(is_xen_heap_mfn(ma >> PAGE_SHIFT));
+    ma -= pfn_to_paddr(xenheap_mfn_start);
+    return (void *)(unsigned long) ma + XENHEAP_VIRT_START;
+}
+
+static inline paddr_t gvirt_to_maddr(uint32_t va)
+{
+    uint64_t par = gva_to_par(va);
+    return (par & PADDR_MASK & PAGE_MASK) | ((unsigned long) va & ~PAGE_MASK);
+}
+
+/* Convert between Xen-heap virtual addresses and machine addresses. */
+#define __pa(x)             (virt_to_maddr(x))
+#define __va(x)             (maddr_to_virt(x))
+
+/* Convert between Xen-heap virtual addresses and machine frame numbers. */
+#define virt_to_mfn(va)   (virt_to_maddr(va) >> PAGE_SHIFT)
+#define mfn_to_virt(mfn)  (maddr_to_virt((paddr_t)(mfn) << PAGE_SHIFT))
+
+
+static inline int get_order_from_bytes(paddr_t size)
+{
+    int order;
+    size = (size-1) >> PAGE_SHIFT;
+    for ( order = 0; size; order++ )
+        size >>= 1;
+    return order;
+}
+
+static inline int get_order_from_pages(unsigned long nr_pages)
+{
+    int order;
+    nr_pages--;
+    for ( order = 0; nr_pages; order++ )
+        nr_pages >>= 1;
+    return order;
+}
+
+
+/* Convert between Xen-heap virtual addresses and page-info structures. */
+static inline struct page_info *virt_to_page(const void *v)
+{
+    unsigned long va = (unsigned long)v;
+    ASSERT(va >= XENHEAP_VIRT_START);
+    ASSERT(va < xenheap_virt_end);
+
+    return frame_table + ((va - XENHEAP_VIRT_START) >> PAGE_SHIFT);
+}
+
+static inline void *page_to_virt(const struct page_info *pg)
+{
+    ASSERT((unsigned long)pg - FRAMETABLE_VIRT_START < frametable_virt_end);
+    return (void *)(XENHEAP_VIRT_START +
+                    ((unsigned long)pg - FRAMETABLE_VIRT_START) /
+                    (sizeof(*pg) / (sizeof(*pg) & -sizeof(*pg))) *
+                    (PAGE_SIZE / (sizeof(*pg) & -sizeof(*pg))));
+
+}
+
+struct domain *page_get_owner_and_reference(struct page_info *page);
+void put_page(struct page_info *page);
+int  get_page(struct page_info *page, struct domain *domain);
+
+/*
+ * The MPT (machine->physical mapping table) is an array of word-sized
+ * values, indexed on machine frame number. It is expected that guest OSes
+ * will use it to store a "physical" frame number to give the appearance of
+ * contiguous (or near contiguous) physical memory.
+ */
+#undef  machine_to_phys_mapping
+#define machine_to_phys_mapping  ((unsigned long *)RDWR_MPT_VIRT_START)
+#define INVALID_M2P_ENTRY        (~0UL)
+#define VALID_M2P(_e)            (!((_e) & (1UL<<(BITS_PER_LONG-1))))
+#define SHARED_M2P_ENTRY         (~0UL - 1UL)
+#define SHARED_M2P(_e)           ((_e) == SHARED_M2P_ENTRY)
+
+#define _set_gpfn_from_mfn(mfn, pfn) ({                        \
+    struct domain *d = page_get_owner(__mfn_to_page(mfn));     \
+    if(d && (d == dom_cow))                                    \
+        machine_to_phys_mapping[(mfn)] = SHARED_M2P_ENTRY;     \
+    else                                                       \
+        machine_to_phys_mapping[(mfn)] = (pfn);                \
+    })
+
+#define put_gfn(d, g)   ((void)0)
+
+#define INVALID_MFN             (~0UL)
+
+/* Xen always owns P2M on ARM */
+#define set_gpfn_from_mfn(mfn, pfn) do { (void) (mfn),(pfn); } while (0)
+#define mfn_to_gmfn(_d, mfn)  (mfn)
+
+
+/* Arch-specific portion of memory_op hypercall. */
+long arch_memory_op(int op, XEN_GUEST_HANDLE(void) arg);
+
+int steal_page(
+    struct domain *d, struct page_info *page, unsigned int memflags);
+int donate_page(
+    struct domain *d, struct page_info *page, unsigned int memflags);
+
+#define domain_set_alloc_bitsize(d) ((void)0)
+#define domain_clamp_alloc_bitsize(d, b) (b)
+
+unsigned long domain_get_maximum_gpfn(struct domain *d);
+
+extern struct domain *dom_xen, *dom_io, *dom_cow;
+
+#define memguard_init(_s)              (_s)
+#define memguard_guard_stack(_p)       ((void)0)
+#define memguard_guard_range(_p,_l)    ((void)0)
+#define memguard_unguard_range(_p,_l)  ((void)0)
+int guest_physmap_mark_populate_on_demand(struct domain *d, unsigned long gfn,
+                                          unsigned int order);
+
+extern void put_page_type(struct page_info *page);
+static inline void put_page_and_type(struct page_info *page)
+{
+    put_page_type(page);
+    put_page(page);
+}
+
+#endif /*  __ARCH_ARM_MM__ */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/p2m.h b/xen/include/asm-arm/p2m.h
new file mode 100644
index 0000000..aec52f7
--- /dev/null
+++ b/xen/include/asm-arm/p2m.h
@@ -0,0 +1,88 @@
+#ifndef _XEN_P2M_H
+#define _XEN_P2M_H
+
+#include <xen/mm.h>
+
+struct domain;
+
+/* Per-p2m-table state */
+struct p2m_domain {
+    /* Lock that protects updates to the p2m */
+    spinlock_t lock;
+
+    /* Pages used to construct the p2m */
+    struct page_list_head pages;
+
+    /* Root of p2m page tables, 2 contiguous pages */
+    struct page_info *first_level;
+
+    /* Current VMID in use */
+    uint8_t vmid;
+};
+
+/* Init the datastructures for later use by the p2m code */
+int p2m_init(struct domain *d);
+
+/* Allocate a new p2m table for a domain.
+ *
+ * Returns 0 for success or -errno.
+ */
+int p2m_alloc_table(struct domain *d);
+
+/* */
+void p2m_load_VTTBR(struct domain *d);
+
+/* Setup p2m RAM mapping for domain d from start-end. */
+int p2m_populate_ram(struct domain *d, paddr_t start, paddr_t end);
+/* Map MMIO regions in the p2m: start_gaddr and end_gaddr is the range
+ * in the guest physical address space to map, starting from the machine
+ * address maddr. */
+int map_mmio_regions(struct domain *d, paddr_t start_gaddr,
+                     paddr_t end_gaddr, paddr_t maddr);
+
+unsigned long gmfn_to_mfn(struct domain *d, unsigned long gpfn);
+
+/*
+ * Populate-on-demand
+ */
+
+/* Call when decreasing memory reservation to handle PoD entries properly.
+ * Will return '1' if all entries were handled and nothing more need be done.*/
+int
+p2m_pod_decrease_reservation(struct domain *d,
+                             xen_pfn_t gpfn,
+                             unsigned int order);
+
+/* Compatibility function exporting the old untyped interface */
+static inline unsigned long get_gfn_untyped(struct domain *d, unsigned long gpfn)
+{
+    return gmfn_to_mfn(d, gpfn);
+}
+
+int get_page_type(struct page_info *page, unsigned long type);
+int is_iomem_page(unsigned long mfn);
+static inline int get_page_and_type(struct page_info *page,
+                                    struct domain *domain,
+                                    unsigned long type)
+{
+    int rc = get_page(page, domain);
+
+    if ( likely(rc) && unlikely(!get_page_type(page, type)) )
+    {
+        put_page(page);
+        rc = 0;
+    }
+
+    return rc;
+}
+
+#endif /* _XEN_P2M_H */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/page.h b/xen/include/asm-arm/page.h
new file mode 100644
index 0000000..6dc1659
--- /dev/null
+++ b/xen/include/asm-arm/page.h
@@ -0,0 +1,335 @@
+#ifndef __ARM_PAGE_H__
+#define __ARM_PAGE_H__
+
+#include <xen/config.h>
+
+#define PADDR_BITS              40
+#define PADDR_MASK              ((1ULL << PADDR_BITS)-1)
+
+#define VADDR_BITS              32
+#define VADDR_MASK              (~0UL)
+
+/* Shareability values for the LPAE entries */
+#define LPAE_SH_NON_SHAREABLE 0x0
+#define LPAE_SH_UNPREDICTALE  0x1
+#define LPAE_SH_OUTER         0x2
+#define LPAE_SH_INNER         0x3
+
+/* LPAE Memory region attributes, to match Linux's (non-LPAE) choices.
+ * Indexed by the AttrIndex bits of a LPAE entry;
+ * the 8-bit fields are packed little-endian into MAIR0 and MAIR1
+ *
+ *                 ai    encoding
+ *   UNCACHED      000   0000 0000  -- Strongly Ordered
+ *   BUFFERABLE    001   0100 0100  -- Non-Cacheable
+ *   WRITETHROUGH  010   1010 1010  -- Write-through
+ *   WRITEBACK     011   1110 1110  -- Write-back
+ *   DEV_SHARED    100   0000 0100  -- Device
+ *   ??            101
+ *   reserved      110
+ *   WRITEALLOC    111   1111 1111  -- Write-back write-allocate
+ *
+ *   DEV_NONSHARED 100   (== DEV_SHARED)
+ *   DEV_WC        001   (== BUFFERABLE)
+ *   DEV_CACHED    011   (== WRITEBACK)
+ */
+#define MAIR0VAL 0xeeaa4400
+#define MAIR1VAL 0xff000004
+
+#define UNCACHED      0x0
+#define BUFFERABLE    0x1
+#define WRITETHROUGH  0x2
+#define WRITEBACK     0x3
+#define DEV_SHARED    0x4
+#define WRITEALLOC    0x7
+#define DEV_NONSHARED DEV_SHARED
+#define DEV_WC        BUFFERABLE
+#define DEV_CACHED    WRITEBACK
+
+
+#ifndef __ASSEMBLY__
+
+#include <xen/types.h>
+#include <xen/lib.h>
+
+/* WARNING!  Unlike the Intel pagetable code, where l1 is the lowest
+ * level and l4 is the root of the trie, the ARM pagetables follow ARM's
+ * documentation: the levels are called first, second &c in the order
+ * that the MMU walks them (i.e. "first" is the root of the trie). */
+
+/******************************************************************************
+ * ARMv7-A LPAE pagetables: 3-level trie, mapping 40-bit input to
+ * 40-bit output addresses.  Tables at all levels have 512 64-bit entries
+ * (i.e. are 4Kb long).
+ *
+ * The bit-shuffling that has the permission bits in branch nodes in a
+ * different place from those in leaf nodes seems to be to allow linear
+ * pagetable tricks.  If we're not doing that then the set of permission
+ * bits that's not in use in a given node type can be used as
+ * extra software-defined bits. */
+
+typedef struct {
+    /* These are used in all kinds of entry. */
+    unsigned long valid:1;      /* Valid mapping */
+    unsigned long table:1;      /* == 1 in 4k map entries too */
+
+    /* These ten bits are only used in Block entries and are ignored
+     * in Table entries. */
+    unsigned long ai:3;         /* Attribute Index */
+    unsigned long ns:1;         /* Not-Secure */
+    unsigned long user:1;       /* User-visible */
+    unsigned long ro:1;         /* Read-Only */
+    unsigned long sh:2;         /* Shareability */
+    unsigned long af:1;         /* Access Flag */
+    unsigned long ng:1;         /* Not-Global */
+
+    /* The base address must be approprately aligned for Block entries */
+    unsigned long base:28;      /* Base address of block or next table */
+    unsigned long sbz:12;       /* Must be zero */
+
+    /* These seven bits are only used in Block entries and are ignored
+     * in Table entries. */
+    unsigned long hint:1;       /* In a block of 16 contiguous entries */
+    unsigned long pxn:1;        /* Privileged-XN */
+    unsigned long xn:1;         /* eXecute-Never */
+    unsigned long avail:4;      /* Ignored by hardware */
+
+    /* These 5 bits are only used in Table entries and are ignored in
+     * Block entries */
+    unsigned long pxnt:1;       /* Privileged-XN */
+    unsigned long xnt:1;        /* eXecute-Never */
+    unsigned long apt:2;        /* Access Permissions */
+    unsigned long nst:1;        /* Not-Secure */
+} __attribute__((__packed__)) lpae_pt_t;
+
+/* The p2m tables have almost the same layout, but some of the permission
+ * and cache-control bits are laid out differently (or missing) */
+typedef struct {
+    /* These are used in all kinds of entry. */
+    unsigned long valid:1;      /* Valid mapping */
+    unsigned long table:1;      /* == 1 in 4k map entries too */
+
+    /* These ten bits are only used in Block entries and are ignored
+     * in Table entries. */
+    unsigned long mattr:4;      /* Memory Attributes */
+    unsigned long read:1;       /* Read access */
+    unsigned long write:1;      /* Write access */
+    unsigned long sh:2;         /* Shareability */
+    unsigned long af:1;         /* Access Flag */
+    unsigned long sbz4:1;
+
+    /* The base address must be approprately aligned for Block entries */
+    unsigned long base:28;      /* Base address of block or next table */
+    unsigned long sbz3:12;
+
+    /* These seven bits are only used in Block entries and are ignored
+     * in Table entries. */
+    unsigned long hint:1;       /* In a block of 16 contiguous entries */
+    unsigned long sbz2:1;
+    unsigned long xn:1;         /* eXecute-Never */
+    unsigned long avail:4;      /* Ignored by hardware */
+
+    unsigned long sbz1:5;
+} __attribute__((__packed__)) lpae_p2m_t;
+
+typedef union {
+    uint64_t bits;
+    lpae_pt_t pt;
+    lpae_p2m_t p2m;
+} lpae_t;
+
+/* Standard entry type that we'll use to build Xen's own pagetables.
+ * We put the same permissions at every level, because they're ignored
+ * by the walker in non-leaf entries. */
+static inline lpae_t mfn_to_xen_entry(unsigned long mfn)
+{
+    paddr_t pa = ((paddr_t) mfn) << PAGE_SHIFT;
+    lpae_t e = (lpae_t) {
+        .pt = {
+            .xn = 1,              /* No need to execute outside .text */
+            .ng = 1,              /* Makes TLB flushes easier */
+            .af = 1,              /* No need for access tracking */
+            .sh = LPAE_SH_OUTER,  /* Xen mappings are globally coherent */
+            .ns = 1,              /* Hyp mode is in the non-secure world */
+            .user = 1,            /* See below */
+            .ai = WRITEALLOC,
+            .table = 0,           /* Set to 1 for links and 4k maps */
+            .valid = 1,           /* Mappings are present */
+        }};;
+    /* Setting the User bit is strange, but the ATS1H[RW] instructions
+     * don't seem to work otherwise, and since we never run on Xen
+     * pagetables un User mode it's OK.  If this changes, remember
+     * to update the hard-coded values in head.S too */
+
+    ASSERT(!(pa & ~PAGE_MASK));
+    ASSERT(!(pa & ~PADDR_MASK));
+
+    // XXX shifts
+    e.bits |= pa;
+    return e;
+}
+
+static inline lpae_t mfn_to_p2m_entry(unsigned long mfn)
+{
+    paddr_t pa = ((paddr_t) mfn) << PAGE_SHIFT;
+    lpae_t e = (lpae_t) {
+        .p2m.xn = 0,
+        .p2m.af = 1,
+        .p2m.sh = LPAE_SH_OUTER,
+        .p2m.write = 1,
+        .p2m.read = 1,
+        .p2m.mattr = 0xf,
+        .p2m.table = 1,
+        .p2m.valid = 1,
+    };
+
+    ASSERT(!(pa & ~PAGE_MASK));
+    ASSERT(!(pa & ~PADDR_MASK));
+
+    e.bits |= pa;
+
+    return e;
+}
+
+/* Write a pagetable entry */
+static inline void write_pte(lpae_t *p, lpae_t pte)
+{
+    asm volatile (
+        /* Safely write the entry (STRD is atomic on CPUs that support LPAE) */
+        "strd %0, %H0, [%1];"
+        /* Push this cacheline to the PoC so the rest of the system sees it. */
+        STORE_CP32(1, DCCMVAC)
+        : : "r" (pte.bits), "r" (p) : "memory");
+}
+
+/*
+ * Flush all hypervisor mappings from the data TLB. This is not
+ * sufficient when changing code mappings or for self modifying code.
+ */
+static inline void flush_xen_data_tlb(void)
+{
+    register unsigned long r0 asm ("r0");
+    asm volatile("dsb;" /* Ensure preceding are visible */
+                 STORE_CP32(0, TLBIALLH)
+                 "dsb;" /* Ensure completion of the TLB flush */
+                 "isb;"
+                 : : "r" (r0) /* dummy */: "memory");
+}
+
+/*
+ * Flush one VA's hypervisor mappings from the data TLB. This is not
+ * sufficient when changing code mappings or for self modifying code.
+ */
+static inline void flush_xen_data_tlb_va(unsigned long va)
+{
+    asm volatile("dsb;" /* Ensure preceding are visible */
+                 STORE_CP32(0, TLBIMVAH)
+                 "dsb;" /* Ensure completion of the TLB flush */
+                 "isb;"
+                 : : "r" (va) : "memory");
+}
+
+/* Flush all non-hypervisor mappings from the TLB */
+static inline void flush_guest_tlb(void)
+{
+    register unsigned long r0 asm ("r0");
+    WRITE_CP32(r0 /* dummy */, TLBIALLNSNH);
+}
+
+/* Ask the MMU to translate a VA for us */
+static inline uint64_t __va_to_par(uint32_t va)
+{
+    uint64_t par, tmp;
+    tmp = READ_CP64(PAR);
+    WRITE_CP32(va, ATS1HR);
+    isb(); /* Ensure result is available. */
+    par = READ_CP64(PAR);
+    WRITE_CP64(tmp, PAR);
+    return par;
+}
+
+static inline uint64_t va_to_par(uint32_t va)
+{
+    uint64_t par = __va_to_par(va);
+    /* It is not OK to call this with an invalid VA */
+    if ( par & PAR_F ) panic_PAR(par, "Hypervisor");
+    return par;
+}
+
+/* Ask the MMU to translate a Guest VA for us */
+static inline uint64_t __gva_to_par(uint32_t va)
+{
+    uint64_t par, tmp;
+    tmp = READ_CP64(PAR);
+    WRITE_CP32(va, ATS12NSOPR);
+    isb(); /* Ensure result is available. */
+    par = READ_CP64(PAR);
+    WRITE_CP64(tmp, PAR);
+    return par;
+}
+static inline uint64_t gva_to_par(uint32_t va)
+{
+    uint64_t par = __gva_to_par(va);
+    /* It is not OK to call this with an invalid VA */
+    /* XXX harsh for a guest address... */
+    if ( par & PAR_F ) panic_PAR(par, "Guest");
+    return par;
+}
+static inline uint64_t __gva_to_ipa(uint32_t va)
+{
+    uint64_t par, tmp;
+    tmp = READ_CP64(PAR);
+    WRITE_CP32(va, ATS1CPR);
+    isb(); /* Ensure result is available. */
+    par = READ_CP64(PAR);
+    WRITE_CP64(tmp, PAR);
+    return par;
+}
+static inline uint64_t gva_to_ipa(uint32_t va)
+{
+    uint64_t par = __gva_to_ipa(va);
+    /* It is not OK to call this with an invalid VA */
+    /* XXX harsh for a guest address... */
+    if ( par & PAR_F ) panic_PAR(par, "Guest");
+    return (par & PADDR_MASK & PAGE_MASK) | ((unsigned long) va & ~PAGE_MASK);
+}
+/* Bits in the PAR returned by va_to_par */
+#define PAR_FAULT 0x1
+
+#endif /* __ASSEMBLY__ */
+
+/* These numbers add up to a 39-bit input address space.  The  ARMv7-A
+ * architecture actually specifies a 40-bit input address space for the p2m,
+ * with an 8K (1024-entry) top-level table. */
+
+#define LPAE_SHIFT      9
+#define LPAE_ENTRIES    (1u << LPAE_SHIFT)
+#define LPAE_ENTRY_MASK (LPAE_ENTRIES - 1)
+
+#define THIRD_SHIFT  PAGE_SHIFT
+#define SECOND_SHIFT (THIRD_SHIFT + LPAE_SHIFT)
+#define FIRST_SHIFT  (SECOND_SHIFT + LPAE_SHIFT)
+
+/* Calculate the offsets into the pagetables for a given VA */
+#define first_linear_offset(va) (va >> FIRST_SHIFT)
+#define second_linear_offset(va) (va >> SECOND_SHIFT)
+#define third_linear_offset(va) (va >> THIRD_SHIFT)
+#define first_table_offset(va) (first_linear_offset(va))
+#define second_table_offset(va) (second_linear_offset(va) & LPAE_ENTRY_MASK)
+#define third_table_offset(va) (third_linear_offset(va) & LPAE_ENTRY_MASK)
+
+#define clear_page(page)memset((void *)(page), 0, PAGE_SIZE)
+
+#define PAGE_ALIGN(x) (((x) + PAGE_SIZE - 1) & PAGE_MASK)
+
+#endif /* __ARM_PAGE_H__ */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 13:14:45 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 13:14:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZ0HZ-0002eH-As; Fri, 09 Dec 2011 13:14:33 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RZ0HY-0002Wk-0X
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 13:14:32 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1323436421!7564857!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMTkxNzY=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18097 invoked from network); 9 Dec 2011 13:13:42 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 13:13:42 -0000
X-IronPort-AV: E=Sophos;i="4.71,325,1320642000"; d="scan'208";a="173546324"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 08:13:40 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 08:13:40 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pB9DCpE8008248;
	Fri, 9 Dec 2011 05:13:28 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 9 Dec 2011 13:13:25 +0000
Message-ID: <1323436408-16335-22-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1112091208420.3517@kaball-desktop>
References: <alpine.DEB.2.00.1112091208420.3517@kaball-desktop>
MIME-Version: 1.0
Cc: keir.xen@gmail.com, Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, JBeulich@suse.com,
	Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v2 22/25] arm: trap handlers
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Functions executed exiting from the guest and returning to the guest:
trap and hypercall handlers and leave_hypervisor_tail.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
---
 xen/arch/arm/traps.c |  609 ++++++++++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 609 insertions(+), 0 deletions(-)
 create mode 100644 xen/arch/arm/traps.c

diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
new file mode 100644
index 0000000..4346dd7
--- /dev/null
+++ b/xen/arch/arm/traps.c
@@ -0,0 +1,609 @@
+/*
+ * xen/arch/arm/traps.c
+ *
+ * ARM Trap handlers
+ *
+ * Copyright (c) 2011 Citrix Systems.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include <xen/config.h>
+#include <xen/init.h>
+#include <xen/string.h>
+#include <xen/version.h>
+#include <xen/smp.h>
+#include <xen/symbols.h>
+#include <xen/irq.h>
+#include <xen/lib.h>
+#include <xen/mm.h>
+#include <xen/errno.h>
+#include <xen/hypercall.h>
+#include <xen/softirq.h>
+#include <public/xen.h>
+#include <asm/regs.h>
+#include <asm/cpregs.h>
+
+#include "io.h"
+#include "vtimer.h"
+#include "gic.h"
+
+/* The base of the stack must always be double-word aligned, which means
+ * that both the kernel half of struct cpu_user_regs (which is pushed in
+ * entry.S) and struct cpu_info (which lives at the bottom of a Xen
+ * stack) must be doubleword-aligned in size.  */
+static inline void check_stack_alignment_constraints(void) {
+    BUILD_BUG_ON((sizeof (struct cpu_user_regs)) & 0x7);
+    BUILD_BUG_ON((offsetof(struct cpu_user_regs, r8_fiq)) & 0x7);
+    BUILD_BUG_ON((sizeof (struct cpu_info)) & 0x7);
+}
+
+static int debug_stack_lines = 20;
+integer_param("debug_stack_lines", debug_stack_lines);
+
+#define stack_words_per_line 8
+
+asmlinkage void __div0(void)
+{
+    printk("Division by zero in hypervisor.\n");
+    BUG();
+}
+
+/* XXX could/should be common code */
+static void print_xen_info(void)
+{
+    char taint_str[TAINT_STRING_MAX_LEN];
+    char debug = 'n';
+
+#ifndef NDEBUG
+    debug = 'y';
+#endif
+
+    printk("----[ Xen-%d.%d%s  x86_64  debug=%c  %s ]----\n",
+           xen_major_version(), xen_minor_version(), xen_extra_version(),
+           debug, print_tainted(taint_str));
+}
+
+static const char *decode_fsc(uint32_t fsc, int *level)
+{
+    const char *msg = NULL;
+
+    switch ( fsc & 0x3f )
+    {
+    case FSC_FLT_TRANS ... FSC_FLT_TRANS + 3:
+        msg = "Translation fault";
+        *level = fsc & FSC_LL_MASK;
+        break;
+    case FSC_FLT_ACCESS ... FSC_FLT_ACCESS + 3:
+        msg = "Access fault";
+        *level = fsc & FSC_LL_MASK;
+        break;
+    case FSC_FLT_PERM ... FSC_FLT_PERM + 3:
+        msg = "Permission fault";
+        *level = fsc & FSC_LL_MASK;
+        break;
+
+    case FSC_SEA:
+        msg = "Synchronous External Abort";
+        break;
+    case FSC_SPE:
+        msg = "Memory Access Synchronous Parity Error";
+        break;
+    case FSC_APE:
+        msg = "Memory Access Asynchronous Parity Error";
+        break;
+    case FSC_SEATT ... FSC_SEATT + 3:
+        msg = "Sync. Ext. Abort Translation Table";
+        *level = fsc & FSC_LL_MASK;
+        break;
+    case FSC_SPETT ... FSC_SPETT + 3:
+        msg = "Sync. Parity. Error Translation Table";
+        *level = fsc & FSC_LL_MASK;
+        break;
+    case FSC_AF:
+        msg = "Alignment Fault";
+        break;
+    case FSC_DE:
+        msg = "Debug Event";
+        break;
+
+    case FSC_LKD:
+        msg = "Implementation Fault: Lockdown Abort";
+        break;
+    case FSC_CPR:
+        msg = "Implementation Fault: Coprocossor Abort";
+        break;
+
+    default:
+        msg = "Unknown Failure";
+        break;
+    }
+    return msg;
+}
+
+static const char *fsc_level_str(int level)
+{
+    switch ( level )
+    {
+    case -1: return "";
+    case 1:  return " at level 1";
+    case 2:  return " at level 2";
+    case 3:  return " at level 3";
+    default: return " (level invalid)";
+    }
+}
+
+void panic_PAR(uint64_t par, const char *when)
+{
+    if ( par & PAR_F )
+    {
+        const char *msg;
+        int level = -1;
+        int stage = par & PAR_STAGE2 ? 2 : 1;
+        int second_in_first = !!(par & PAR_STAGE21);
+
+        msg = decode_fsc( (par&PAR_FSC_MASK) >> PAR_FSC_SHIFT, &level);
+
+        printk("PAR: %010"PRIx64": %s stage %d%s%s\n",
+               par, msg,
+               stage,
+               second_in_first ? " during second stage lookup" : "",
+               fsc_level_str(level));
+    }
+    else
+    {
+        printk("PAR: %010"PRIx64": paddr:%010"PRIx64
+               " attr %"PRIx64" sh %"PRIx64" %s\n",
+               par, par & PADDR_MASK, par >> PAR_MAIR_SHIFT,
+               (par & PAR_SH_MASK) >> PAR_SH_SHIFT,
+               (par & PAR_NS) ? "Non-Secure" : "Secure");
+    }
+    panic("Error during %s-to-physical address translation\n", when);
+}
+
+void show_registers(struct cpu_user_regs *regs)
+{
+    static const char *mode_strings[] = {
+       [PSR_MODE_USR] = "USR",
+       [PSR_MODE_FIQ] = "FIQ",
+       [PSR_MODE_IRQ] = "IRQ",
+       [PSR_MODE_SVC] = "SVC",
+       [PSR_MODE_MON] = "MON",
+       [PSR_MODE_ABT] = "ABT",
+       [PSR_MODE_HYP] = "HYP",
+       [PSR_MODE_UND] = "UND",
+       [PSR_MODE_SYS] = "SYS"
+    };
+
+    print_xen_info();
+    printk("CPU:    %d\n", smp_processor_id());
+    printk("PC:     %08"PRIx32, regs->pc);
+    if ( !guest_mode(regs) )
+            print_symbol(" %s", regs->pc);
+    printk("\n");
+    printk("CPSR:   %08"PRIx32" MODE:%s\n", regs->cpsr,
+           mode_strings[regs->cpsr & PSR_MODE_MASK]);
+    printk("     R0: %08"PRIx32" R1: %08"PRIx32" R2: %08"PRIx32" R3: %08"PRIx32"\n",
+           regs->r0, regs->r1, regs->r2, regs->r3);
+    printk("     R4: %08"PRIx32" R5: %08"PRIx32" R6: %08"PRIx32" R7: %08"PRIx32"\n",
+           regs->r4, regs->r5, regs->r6, regs->r7);
+    printk("     R8: %08"PRIx32" R9: %08"PRIx32" R10:%08"PRIx32" R11:%08"PRIx32" R12:%08"PRIx32"\n",
+           regs->r8, regs->r9, regs->r10, regs->r11, regs->r12);
+
+    if ( guest_mode(regs) )
+    {
+        printk("USR: SP: %08"PRIx32" LR: %08"PRIx32" CPSR:%08"PRIx32"\n",
+               regs->sp_usr, regs->lr_usr, regs->cpsr);
+        printk("SVC: SP: %08"PRIx32" LR: %08"PRIx32" SPSR:%08"PRIx32"\n",
+               regs->sp_svc, regs->lr_svc, regs->spsr_svc);
+        printk("ABT: SP: %08"PRIx32" LR: %08"PRIx32" SPSR:%08"PRIx32"\n",
+               regs->sp_abt, regs->lr_abt, regs->spsr_abt);
+        printk("UND: SP: %08"PRIx32" LR: %08"PRIx32" SPSR:%08"PRIx32"\n",
+               regs->sp_und, regs->lr_und, regs->spsr_und);
+        printk("IRQ: SP: %08"PRIx32" LR: %08"PRIx32" SPSR:%08"PRIx32"\n",
+               regs->sp_irq, regs->lr_irq, regs->spsr_irq);
+        printk("FIQ: SP: %08"PRIx32" LR: %08"PRIx32" SPSR:%08"PRIx32"\n",
+               regs->sp_fiq, regs->lr_fiq, regs->spsr_fiq);
+        printk("FIQ: R8: %08"PRIx32" R9: %08"PRIx32" R10:%08"PRIx32" R11:%08"PRIx32" R12:%08"PRIx32"\n",
+               regs->r8_fiq, regs->r9_fiq, regs->r10_fiq, regs->r11_fiq, regs->r11_fiq);
+        printk("\n");
+        printk("TTBR0 %08"PRIx32" TTBR1 %08"PRIx32" TTBCR %08"PRIx32"\n",
+               READ_CP32(TTBR0), READ_CP32(TTBR1), READ_CP32(TTBCR));
+        printk("SCTLR %08"PRIx32"\n", READ_CP32(SCTLR));
+        printk("VTTBR %010"PRIx64"\n", READ_CP64(VTTBR));
+        printk("\n");
+    }
+    else
+    {
+        printk("     SP: %08"PRIx32" LR: %08"PRIx32"\n", regs->sp, regs->lr);
+        printk("\n");
+    }
+
+    printk("HTTBR %"PRIx64"\n", READ_CP64(HTTBR));
+    printk("HDFAR %"PRIx32"\n", READ_CP32(HDFAR));
+    printk("HIFAR %"PRIx32"\n", READ_CP32(HIFAR));
+    printk("HPFAR %"PRIx32"\n", READ_CP32(HPFAR));
+    printk("HCR %08"PRIx32"\n", READ_CP32(HCR));
+    printk("HSR   %"PRIx32"\n", READ_CP32(HSR));
+    printk("\n");
+
+    printk("DFSR %"PRIx32" DFAR %"PRIx32"\n", READ_CP32(DFSR), READ_CP32(DFAR));
+    printk("IFSR %"PRIx32" IFAR %"PRIx32"\n", READ_CP32(IFSR), READ_CP32(IFAR));
+    printk("\n");
+}
+
+static void show_guest_stack(struct cpu_user_regs *regs)
+{
+    printk("GUEST STACK GOES HERE\n");
+}
+
+#define STACK_BEFORE_EXCEPTION(regs) ((uint32_t*)(regs)->sp)
+
+static void show_trace(struct cpu_user_regs *regs)
+{
+    uint32_t *frame, next, addr, low, high;
+
+    printk("Xen call trace:\n   ");
+
+    printk("[<%p>]", _p(regs->pc));
+    print_symbol(" %s\n   ", regs->pc);
+
+    /* Bounds for range of valid frame pointer. */
+    low  = (uint32_t)(STACK_BEFORE_EXCEPTION(regs)/* - 2*/);
+    high = (low & ~(STACK_SIZE - 1)) +
+        (STACK_SIZE - sizeof(struct cpu_info));
+
+    /* Frame:
+     * (largest address)
+     * | cpu_info
+     * | [...]                                   |
+     * | return addr      <-----------------,    |
+     * | fp --------------------------------+----'
+     * | [...]                              |
+     * | return addr      <------------,    |
+     * | fp ---------------------------+----'
+     * | [...]                         |
+     * | return addr      <- regs->fp  |
+     * | fp ---------------------------'
+     * |
+     * v (smallest address, sp)
+     */
+
+    /* The initial frame pointer. */
+    next = regs->fp;
+
+    for ( ; ; )
+    {
+        if ( (next < low) || (next >= high) )
+            break;
+        {
+            /* Ordinary stack frame. */
+            frame = (uint32_t *)next;
+            next  = frame[-1];
+            addr  = frame[0];
+        }
+
+        printk("[<%p>]", _p(addr));
+        print_symbol(" %s\n   ", addr);
+
+        low = (uint32_t)&frame[1];
+    }
+
+    printk("\n");
+}
+
+void show_stack(struct cpu_user_regs *regs)
+{
+    uint32_t *stack = STACK_BEFORE_EXCEPTION(regs), addr;
+    int i;
+
+    if ( guest_mode(regs) )
+        return show_guest_stack(regs);
+
+    printk("Xen stack trace from sp=%p:\n  ", stack);
+
+    for ( i = 0; i < (debug_stack_lines*stack_words_per_line); i++ )
+    {
+        if ( ((long)stack & (STACK_SIZE-BYTES_PER_LONG)) == 0 )
+            break;
+        if ( (i != 0) && ((i % stack_words_per_line) == 0) )
+            printk("\n  ");
+
+        addr = *stack++;
+        printk(" %p", _p(addr));
+    }
+    if ( i == 0 )
+        printk("Stack empty.");
+    printk("\n");
+
+    show_trace(regs);
+}
+
+void show_execution_state(struct cpu_user_regs *regs)
+{
+    show_registers(regs);
+    show_stack(regs);
+}
+
+static void do_unexpected_trap(const char *msg, struct cpu_user_regs *regs)
+{
+    printk("Unexpected Trap: %s\n", msg);
+    show_execution_state(regs);
+    while(1);
+}
+
+asmlinkage void do_trap_undefined_instruction(struct cpu_user_regs *regs)
+{
+    do_unexpected_trap("Undefined Instruction", regs);
+}
+
+asmlinkage void do_trap_supervisor_call(struct cpu_user_regs *regs)
+{
+    do_unexpected_trap("Supervisor Call", regs);
+}
+
+asmlinkage void do_trap_prefetch_abort(struct cpu_user_regs *regs)
+{
+    do_unexpected_trap("Prefetch Abort", regs);
+}
+
+asmlinkage void do_trap_data_abort(struct cpu_user_regs *regs)
+{
+    do_unexpected_trap("Data Abort", regs);
+}
+
+unsigned long do_arch_0(unsigned int cmd, unsigned long long value)
+{
+        printk("do_arch_0 cmd=%x arg=%llx\n", cmd, value);
+        return 0;
+}
+
+typedef unsigned long arm_hypercall_t(
+    unsigned int, unsigned int, unsigned int, unsigned int, unsigned int,
+    unsigned int, unsigned int, unsigned int, unsigned int, unsigned int);
+
+#define HYPERCALL(x)                                        \
+    [ __HYPERVISOR_ ## x ] = (arm_hypercall_t *) do_ ## x
+
+static arm_hypercall_t *arm_hypercall_table[] = {
+    HYPERCALL(arch_0),
+    HYPERCALL(sched_op),
+    HYPERCALL(console_io),
+};
+
+static void do_debug_trap(struct cpu_user_regs *regs, unsigned int code)
+{
+    uint32_t reg, *r;
+
+    switch ( code ) {
+    case 0xe0 ... 0xef:
+        reg = code - 0xe0;
+        r = &regs->r0 + reg;
+        printk("R%d = %#010"PRIx32" at %#010"PRIx32"\n", reg, *r, regs->pc);
+        break;
+    case 0xfd:
+        printk("Reached %08"PRIx32"\n", regs->pc);
+        break;
+    case 0xfe:
+        printk("%c", (char)(regs->r0 & 0xff));
+        break;
+    case 0xff:
+        printk("DEBUG\n");
+        show_execution_state(regs);
+        break;
+    default:
+        panic("Unhandled debug trap %#x\n", code);
+        break;
+    }
+}
+
+static void do_trap_hypercall(struct cpu_user_regs *regs, unsigned long iss)
+{
+    local_irq_enable();
+
+    regs->r0 = arm_hypercall_table[iss](regs->r0,
+                             regs->r1,
+                             regs->r2,
+                             regs->r3,
+                             regs->r4,
+                             regs->r5,
+                             regs->r6,
+                             regs->r7,
+                             regs->r8,
+                             regs->r9);
+}
+
+static void do_cp15_32(struct cpu_user_regs *regs,
+                       union hsr hsr)
+{
+    struct hsr_cp32 cp32 = hsr.cp32;
+    uint32_t *r = &regs->r0 + cp32.reg;
+
+    if ( !cp32.ccvalid ) {
+        dprintk(XENLOG_ERR, "cp_15(32): need to handle invalid condition codes\n");
+        domain_crash_synchronous();
+    }
+    if ( cp32.cc != 0xe ) {
+        dprintk(XENLOG_ERR, "cp_15(32): need to handle condition codes %x\n",
+                cp32.cc);
+        domain_crash_synchronous();
+    }
+
+    switch ( hsr.bits & HSR_CP32_REGS_MASK )
+    {
+    case HSR_CPREG32(CLIDR):
+        if ( !cp32.read )
+        {
+            dprintk(XENLOG_ERR,
+                    "attempt to write to read-only register CLIDR\n");
+            domain_crash_synchronous();
+        }
+        *r = READ_CP32(CLIDR);
+        break;
+    case HSR_CPREG32(CCSIDR):
+        if ( !cp32.read )
+        {
+            dprintk(XENLOG_ERR,
+                    "attempt to write to read-only register CSSIDR\n");
+            domain_crash_synchronous();
+        }
+        *r = READ_CP32(CCSIDR);
+        break;
+    case HSR_CPREG32(DCCISW):
+        if ( cp32.read )
+        {
+            dprintk(XENLOG_ERR,
+                    "attempt to read from write-only register DCCISW\n");
+            domain_crash_synchronous();
+        }
+        WRITE_CP32(*r, DCCISW);
+        break;
+    case HSR_CPREG32(CNTP_CTL):
+    case HSR_CPREG32(CNTP_TVAL):
+        /* emulate timer */
+        break;
+    default:
+        printk("%s p15, %d, r%d, cr%d, cr%d, %d @ %#08x\n",
+               cp32.read ? "mrc" : "mcr",
+               cp32.op1, cp32.reg, cp32.crn, cp32.crm, cp32.op2, regs->pc);
+        panic("unhandled 32-bit CP15 access %#x\n", hsr.bits & HSR_CP32_REGS_MASK);
+    }
+    regs->pc += cp32.len ? 4 : 2;
+
+}
+
+static void do_cp15_64(struct cpu_user_regs *regs,
+                       union hsr hsr)
+{
+    struct hsr_cp64 cp64 = hsr.cp64;
+
+    if ( !cp64.ccvalid ) {
+        dprintk(XENLOG_ERR, "cp_15(64): need to handle invalid condition codes\n");
+        domain_crash_synchronous();
+    }
+    if ( cp64.cc != 0xe ) {
+        dprintk(XENLOG_ERR, "cp_15(64): need to handle condition codes %x\n",
+                cp64.cc);
+        domain_crash_synchronous();
+    }
+
+    switch ( hsr.bits & HSR_CP64_REGS_MASK )
+    {
+    case HSR_CPREG64(CNTPCT):
+        /* emulate timer */
+        break;
+    default:
+        printk("%s p15, %d, r%d, r%d, cr%d @ %#08x\n",
+               cp64.read ? "mrrc" : "mcrr",
+               cp64.op1, cp64.reg1, cp64.reg2, cp64.crm, regs->pc);
+        panic("unhandled 64-bit CP15 access %#x\n", hsr.bits & HSR_CP64_REGS_MASK);
+    }
+    regs->pc += cp64.len ? 4 : 2;
+
+}
+
+static void do_trap_data_abort_guest(struct cpu_user_regs *regs,
+                                     struct hsr_dabt dabt)
+{
+    const char *msg;
+    int level = -1;
+    mmio_info_t info;
+
+    if (dabt.s1ptw)
+        goto bad_data_abort;
+
+    info.dabt = dabt;
+    info.gva = READ_CP32(HDFAR);
+    info.gpa = gva_to_ipa(info.gva);
+
+    if (handle_mmio(&info))
+    {
+        regs->pc += dabt.len ? 4 : 2;
+        return;
+    }
+
+bad_data_abort:
+
+    msg = decode_fsc( dabt.dfsc, &level);
+
+    printk("Guest data abort: %s%s%s\n"
+           "    gva=%"PRIx32" gpa=%"PRIpaddr"\n",
+           msg, dabt.s1ptw ? " S2 during S1" : "",
+           fsc_level_str(level),
+           info.gva, info.gpa);
+    if (dabt.valid)
+        printk("    size=%d sign=%d write=%d reg=%d\n",
+               dabt.size, dabt.sign, dabt.write, dabt.reg);
+    else
+        printk("    instruction syndrome invalid\n");
+    printk("    eat=%d cm=%d s1ptw=%d dfsc=%d\n",
+           dabt.eat, dabt.cache, dabt.s1ptw, dabt.dfsc);
+
+    show_execution_state(regs);
+    panic("Unhandled guest data abort\n");
+}
+
+asmlinkage void do_trap_hypervisor(struct cpu_user_regs *regs)
+{
+    union hsr hsr = { .bits = READ_CP32(HSR) };
+
+    switch (hsr.ec) {
+    case HSR_EC_CP15_32:
+        do_cp15_32(regs, hsr);
+        break;
+    case HSR_EC_CP15_64:
+        do_cp15_64(regs, hsr);
+        break;
+    case HSR_EC_HVC:
+        if ( (hsr.iss & 0xff00) == 0xff00 )
+            return do_debug_trap(regs, hsr.iss & 0x00ff);
+        do_trap_hypercall(regs, hsr.iss);
+        break;
+    case HSR_EC_DATA_ABORT_GUEST:
+        do_trap_data_abort_guest(regs, hsr.dabt);
+        break;
+    default:
+        printk("Hypervisor Trap. HSR=0x%x EC=0x%x IL=%x Syndrome=%"PRIx32"\n",
+               hsr.bits, hsr.ec, hsr.len, hsr.iss);
+        do_unexpected_trap("Hypervisor", regs);
+    }
+}
+
+asmlinkage void do_trap_irq(struct cpu_user_regs *regs)
+{
+    gic_interrupt(regs, 0);
+}
+
+asmlinkage void do_trap_fiq(struct cpu_user_regs *regs)
+{
+    gic_interrupt(regs, 1);
+}
+
+asmlinkage void leave_hypervisor_tail(void)
+{
+    while (1)
+    {
+        local_irq_disable();
+        if (!softirq_pending(smp_processor_id()))
+            return;
+        local_irq_enable();
+        do_softirq();
+    }
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 13:14:45 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 13:14:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZ0HZ-0002eH-As; Fri, 09 Dec 2011 13:14:33 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RZ0HY-0002Wk-0X
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 13:14:32 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1323436421!7564857!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMTkxNzY=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18097 invoked from network); 9 Dec 2011 13:13:42 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 13:13:42 -0000
X-IronPort-AV: E=Sophos;i="4.71,325,1320642000"; d="scan'208";a="173546324"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 08:13:40 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 08:13:40 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pB9DCpE8008248;
	Fri, 9 Dec 2011 05:13:28 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 9 Dec 2011 13:13:25 +0000
Message-ID: <1323436408-16335-22-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1112091208420.3517@kaball-desktop>
References: <alpine.DEB.2.00.1112091208420.3517@kaball-desktop>
MIME-Version: 1.0
Cc: keir.xen@gmail.com, Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, JBeulich@suse.com,
	Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v2 22/25] arm: trap handlers
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Functions executed exiting from the guest and returning to the guest:
trap and hypercall handlers and leave_hypervisor_tail.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
---
 xen/arch/arm/traps.c |  609 ++++++++++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 609 insertions(+), 0 deletions(-)
 create mode 100644 xen/arch/arm/traps.c

diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
new file mode 100644
index 0000000..4346dd7
--- /dev/null
+++ b/xen/arch/arm/traps.c
@@ -0,0 +1,609 @@
+/*
+ * xen/arch/arm/traps.c
+ *
+ * ARM Trap handlers
+ *
+ * Copyright (c) 2011 Citrix Systems.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include <xen/config.h>
+#include <xen/init.h>
+#include <xen/string.h>
+#include <xen/version.h>
+#include <xen/smp.h>
+#include <xen/symbols.h>
+#include <xen/irq.h>
+#include <xen/lib.h>
+#include <xen/mm.h>
+#include <xen/errno.h>
+#include <xen/hypercall.h>
+#include <xen/softirq.h>
+#include <public/xen.h>
+#include <asm/regs.h>
+#include <asm/cpregs.h>
+
+#include "io.h"
+#include "vtimer.h"
+#include "gic.h"
+
+/* The base of the stack must always be double-word aligned, which means
+ * that both the kernel half of struct cpu_user_regs (which is pushed in
+ * entry.S) and struct cpu_info (which lives at the bottom of a Xen
+ * stack) must be doubleword-aligned in size.  */
+static inline void check_stack_alignment_constraints(void) {
+    BUILD_BUG_ON((sizeof (struct cpu_user_regs)) & 0x7);
+    BUILD_BUG_ON((offsetof(struct cpu_user_regs, r8_fiq)) & 0x7);
+    BUILD_BUG_ON((sizeof (struct cpu_info)) & 0x7);
+}
+
+static int debug_stack_lines = 20;
+integer_param("debug_stack_lines", debug_stack_lines);
+
+#define stack_words_per_line 8
+
+asmlinkage void __div0(void)
+{
+    printk("Division by zero in hypervisor.\n");
+    BUG();
+}
+
+/* XXX could/should be common code */
+static void print_xen_info(void)
+{
+    char taint_str[TAINT_STRING_MAX_LEN];
+    char debug = 'n';
+
+#ifndef NDEBUG
+    debug = 'y';
+#endif
+
+    printk("----[ Xen-%d.%d%s  x86_64  debug=%c  %s ]----\n",
+           xen_major_version(), xen_minor_version(), xen_extra_version(),
+           debug, print_tainted(taint_str));
+}
+
+static const char *decode_fsc(uint32_t fsc, int *level)
+{
+    const char *msg = NULL;
+
+    switch ( fsc & 0x3f )
+    {
+    case FSC_FLT_TRANS ... FSC_FLT_TRANS + 3:
+        msg = "Translation fault";
+        *level = fsc & FSC_LL_MASK;
+        break;
+    case FSC_FLT_ACCESS ... FSC_FLT_ACCESS + 3:
+        msg = "Access fault";
+        *level = fsc & FSC_LL_MASK;
+        break;
+    case FSC_FLT_PERM ... FSC_FLT_PERM + 3:
+        msg = "Permission fault";
+        *level = fsc & FSC_LL_MASK;
+        break;
+
+    case FSC_SEA:
+        msg = "Synchronous External Abort";
+        break;
+    case FSC_SPE:
+        msg = "Memory Access Synchronous Parity Error";
+        break;
+    case FSC_APE:
+        msg = "Memory Access Asynchronous Parity Error";
+        break;
+    case FSC_SEATT ... FSC_SEATT + 3:
+        msg = "Sync. Ext. Abort Translation Table";
+        *level = fsc & FSC_LL_MASK;
+        break;
+    case FSC_SPETT ... FSC_SPETT + 3:
+        msg = "Sync. Parity. Error Translation Table";
+        *level = fsc & FSC_LL_MASK;
+        break;
+    case FSC_AF:
+        msg = "Alignment Fault";
+        break;
+    case FSC_DE:
+        msg = "Debug Event";
+        break;
+
+    case FSC_LKD:
+        msg = "Implementation Fault: Lockdown Abort";
+        break;
+    case FSC_CPR:
+        msg = "Implementation Fault: Coprocossor Abort";
+        break;
+
+    default:
+        msg = "Unknown Failure";
+        break;
+    }
+    return msg;
+}
+
+static const char *fsc_level_str(int level)
+{
+    switch ( level )
+    {
+    case -1: return "";
+    case 1:  return " at level 1";
+    case 2:  return " at level 2";
+    case 3:  return " at level 3";
+    default: return " (level invalid)";
+    }
+}
+
+void panic_PAR(uint64_t par, const char *when)
+{
+    if ( par & PAR_F )
+    {
+        const char *msg;
+        int level = -1;
+        int stage = par & PAR_STAGE2 ? 2 : 1;
+        int second_in_first = !!(par & PAR_STAGE21);
+
+        msg = decode_fsc( (par&PAR_FSC_MASK) >> PAR_FSC_SHIFT, &level);
+
+        printk("PAR: %010"PRIx64": %s stage %d%s%s\n",
+               par, msg,
+               stage,
+               second_in_first ? " during second stage lookup" : "",
+               fsc_level_str(level));
+    }
+    else
+    {
+        printk("PAR: %010"PRIx64": paddr:%010"PRIx64
+               " attr %"PRIx64" sh %"PRIx64" %s\n",
+               par, par & PADDR_MASK, par >> PAR_MAIR_SHIFT,
+               (par & PAR_SH_MASK) >> PAR_SH_SHIFT,
+               (par & PAR_NS) ? "Non-Secure" : "Secure");
+    }
+    panic("Error during %s-to-physical address translation\n", when);
+}
+
+void show_registers(struct cpu_user_regs *regs)
+{
+    static const char *mode_strings[] = {
+       [PSR_MODE_USR] = "USR",
+       [PSR_MODE_FIQ] = "FIQ",
+       [PSR_MODE_IRQ] = "IRQ",
+       [PSR_MODE_SVC] = "SVC",
+       [PSR_MODE_MON] = "MON",
+       [PSR_MODE_ABT] = "ABT",
+       [PSR_MODE_HYP] = "HYP",
+       [PSR_MODE_UND] = "UND",
+       [PSR_MODE_SYS] = "SYS"
+    };
+
+    print_xen_info();
+    printk("CPU:    %d\n", smp_processor_id());
+    printk("PC:     %08"PRIx32, regs->pc);
+    if ( !guest_mode(regs) )
+            print_symbol(" %s", regs->pc);
+    printk("\n");
+    printk("CPSR:   %08"PRIx32" MODE:%s\n", regs->cpsr,
+           mode_strings[regs->cpsr & PSR_MODE_MASK]);
+    printk("     R0: %08"PRIx32" R1: %08"PRIx32" R2: %08"PRIx32" R3: %08"PRIx32"\n",
+           regs->r0, regs->r1, regs->r2, regs->r3);
+    printk("     R4: %08"PRIx32" R5: %08"PRIx32" R6: %08"PRIx32" R7: %08"PRIx32"\n",
+           regs->r4, regs->r5, regs->r6, regs->r7);
+    printk("     R8: %08"PRIx32" R9: %08"PRIx32" R10:%08"PRIx32" R11:%08"PRIx32" R12:%08"PRIx32"\n",
+           regs->r8, regs->r9, regs->r10, regs->r11, regs->r12);
+
+    if ( guest_mode(regs) )
+    {
+        printk("USR: SP: %08"PRIx32" LR: %08"PRIx32" CPSR:%08"PRIx32"\n",
+               regs->sp_usr, regs->lr_usr, regs->cpsr);
+        printk("SVC: SP: %08"PRIx32" LR: %08"PRIx32" SPSR:%08"PRIx32"\n",
+               regs->sp_svc, regs->lr_svc, regs->spsr_svc);
+        printk("ABT: SP: %08"PRIx32" LR: %08"PRIx32" SPSR:%08"PRIx32"\n",
+               regs->sp_abt, regs->lr_abt, regs->spsr_abt);
+        printk("UND: SP: %08"PRIx32" LR: %08"PRIx32" SPSR:%08"PRIx32"\n",
+               regs->sp_und, regs->lr_und, regs->spsr_und);
+        printk("IRQ: SP: %08"PRIx32" LR: %08"PRIx32" SPSR:%08"PRIx32"\n",
+               regs->sp_irq, regs->lr_irq, regs->spsr_irq);
+        printk("FIQ: SP: %08"PRIx32" LR: %08"PRIx32" SPSR:%08"PRIx32"\n",
+               regs->sp_fiq, regs->lr_fiq, regs->spsr_fiq);
+        printk("FIQ: R8: %08"PRIx32" R9: %08"PRIx32" R10:%08"PRIx32" R11:%08"PRIx32" R12:%08"PRIx32"\n",
+               regs->r8_fiq, regs->r9_fiq, regs->r10_fiq, regs->r11_fiq, regs->r11_fiq);
+        printk("\n");
+        printk("TTBR0 %08"PRIx32" TTBR1 %08"PRIx32" TTBCR %08"PRIx32"\n",
+               READ_CP32(TTBR0), READ_CP32(TTBR1), READ_CP32(TTBCR));
+        printk("SCTLR %08"PRIx32"\n", READ_CP32(SCTLR));
+        printk("VTTBR %010"PRIx64"\n", READ_CP64(VTTBR));
+        printk("\n");
+    }
+    else
+    {
+        printk("     SP: %08"PRIx32" LR: %08"PRIx32"\n", regs->sp, regs->lr);
+        printk("\n");
+    }
+
+    printk("HTTBR %"PRIx64"\n", READ_CP64(HTTBR));
+    printk("HDFAR %"PRIx32"\n", READ_CP32(HDFAR));
+    printk("HIFAR %"PRIx32"\n", READ_CP32(HIFAR));
+    printk("HPFAR %"PRIx32"\n", READ_CP32(HPFAR));
+    printk("HCR %08"PRIx32"\n", READ_CP32(HCR));
+    printk("HSR   %"PRIx32"\n", READ_CP32(HSR));
+    printk("\n");
+
+    printk("DFSR %"PRIx32" DFAR %"PRIx32"\n", READ_CP32(DFSR), READ_CP32(DFAR));
+    printk("IFSR %"PRIx32" IFAR %"PRIx32"\n", READ_CP32(IFSR), READ_CP32(IFAR));
+    printk("\n");
+}
+
+static void show_guest_stack(struct cpu_user_regs *regs)
+{
+    printk("GUEST STACK GOES HERE\n");
+}
+
+#define STACK_BEFORE_EXCEPTION(regs) ((uint32_t*)(regs)->sp)
+
+static void show_trace(struct cpu_user_regs *regs)
+{
+    uint32_t *frame, next, addr, low, high;
+
+    printk("Xen call trace:\n   ");
+
+    printk("[<%p>]", _p(regs->pc));
+    print_symbol(" %s\n   ", regs->pc);
+
+    /* Bounds for range of valid frame pointer. */
+    low  = (uint32_t)(STACK_BEFORE_EXCEPTION(regs)/* - 2*/);
+    high = (low & ~(STACK_SIZE - 1)) +
+        (STACK_SIZE - sizeof(struct cpu_info));
+
+    /* Frame:
+     * (largest address)
+     * | cpu_info
+     * | [...]                                   |
+     * | return addr      <-----------------,    |
+     * | fp --------------------------------+----'
+     * | [...]                              |
+     * | return addr      <------------,    |
+     * | fp ---------------------------+----'
+     * | [...]                         |
+     * | return addr      <- regs->fp  |
+     * | fp ---------------------------'
+     * |
+     * v (smallest address, sp)
+     */
+
+    /* The initial frame pointer. */
+    next = regs->fp;
+
+    for ( ; ; )
+    {
+        if ( (next < low) || (next >= high) )
+            break;
+        {
+            /* Ordinary stack frame. */
+            frame = (uint32_t *)next;
+            next  = frame[-1];
+            addr  = frame[0];
+        }
+
+        printk("[<%p>]", _p(addr));
+        print_symbol(" %s\n   ", addr);
+
+        low = (uint32_t)&frame[1];
+    }
+
+    printk("\n");
+}
+
+void show_stack(struct cpu_user_regs *regs)
+{
+    uint32_t *stack = STACK_BEFORE_EXCEPTION(regs), addr;
+    int i;
+
+    if ( guest_mode(regs) )
+        return show_guest_stack(regs);
+
+    printk("Xen stack trace from sp=%p:\n  ", stack);
+
+    for ( i = 0; i < (debug_stack_lines*stack_words_per_line); i++ )
+    {
+        if ( ((long)stack & (STACK_SIZE-BYTES_PER_LONG)) == 0 )
+            break;
+        if ( (i != 0) && ((i % stack_words_per_line) == 0) )
+            printk("\n  ");
+
+        addr = *stack++;
+        printk(" %p", _p(addr));
+    }
+    if ( i == 0 )
+        printk("Stack empty.");
+    printk("\n");
+
+    show_trace(regs);
+}
+
+void show_execution_state(struct cpu_user_regs *regs)
+{
+    show_registers(regs);
+    show_stack(regs);
+}
+
+static void do_unexpected_trap(const char *msg, struct cpu_user_regs *regs)
+{
+    printk("Unexpected Trap: %s\n", msg);
+    show_execution_state(regs);
+    while(1);
+}
+
+asmlinkage void do_trap_undefined_instruction(struct cpu_user_regs *regs)
+{
+    do_unexpected_trap("Undefined Instruction", regs);
+}
+
+asmlinkage void do_trap_supervisor_call(struct cpu_user_regs *regs)
+{
+    do_unexpected_trap("Supervisor Call", regs);
+}
+
+asmlinkage void do_trap_prefetch_abort(struct cpu_user_regs *regs)
+{
+    do_unexpected_trap("Prefetch Abort", regs);
+}
+
+asmlinkage void do_trap_data_abort(struct cpu_user_regs *regs)
+{
+    do_unexpected_trap("Data Abort", regs);
+}
+
+unsigned long do_arch_0(unsigned int cmd, unsigned long long value)
+{
+        printk("do_arch_0 cmd=%x arg=%llx\n", cmd, value);
+        return 0;
+}
+
+typedef unsigned long arm_hypercall_t(
+    unsigned int, unsigned int, unsigned int, unsigned int, unsigned int,
+    unsigned int, unsigned int, unsigned int, unsigned int, unsigned int);
+
+#define HYPERCALL(x)                                        \
+    [ __HYPERVISOR_ ## x ] = (arm_hypercall_t *) do_ ## x
+
+static arm_hypercall_t *arm_hypercall_table[] = {
+    HYPERCALL(arch_0),
+    HYPERCALL(sched_op),
+    HYPERCALL(console_io),
+};
+
+static void do_debug_trap(struct cpu_user_regs *regs, unsigned int code)
+{
+    uint32_t reg, *r;
+
+    switch ( code ) {
+    case 0xe0 ... 0xef:
+        reg = code - 0xe0;
+        r = &regs->r0 + reg;
+        printk("R%d = %#010"PRIx32" at %#010"PRIx32"\n", reg, *r, regs->pc);
+        break;
+    case 0xfd:
+        printk("Reached %08"PRIx32"\n", regs->pc);
+        break;
+    case 0xfe:
+        printk("%c", (char)(regs->r0 & 0xff));
+        break;
+    case 0xff:
+        printk("DEBUG\n");
+        show_execution_state(regs);
+        break;
+    default:
+        panic("Unhandled debug trap %#x\n", code);
+        break;
+    }
+}
+
+static void do_trap_hypercall(struct cpu_user_regs *regs, unsigned long iss)
+{
+    local_irq_enable();
+
+    regs->r0 = arm_hypercall_table[iss](regs->r0,
+                             regs->r1,
+                             regs->r2,
+                             regs->r3,
+                             regs->r4,
+                             regs->r5,
+                             regs->r6,
+                             regs->r7,
+                             regs->r8,
+                             regs->r9);
+}
+
+static void do_cp15_32(struct cpu_user_regs *regs,
+                       union hsr hsr)
+{
+    struct hsr_cp32 cp32 = hsr.cp32;
+    uint32_t *r = &regs->r0 + cp32.reg;
+
+    if ( !cp32.ccvalid ) {
+        dprintk(XENLOG_ERR, "cp_15(32): need to handle invalid condition codes\n");
+        domain_crash_synchronous();
+    }
+    if ( cp32.cc != 0xe ) {
+        dprintk(XENLOG_ERR, "cp_15(32): need to handle condition codes %x\n",
+                cp32.cc);
+        domain_crash_synchronous();
+    }
+
+    switch ( hsr.bits & HSR_CP32_REGS_MASK )
+    {
+    case HSR_CPREG32(CLIDR):
+        if ( !cp32.read )
+        {
+            dprintk(XENLOG_ERR,
+                    "attempt to write to read-only register CLIDR\n");
+            domain_crash_synchronous();
+        }
+        *r = READ_CP32(CLIDR);
+        break;
+    case HSR_CPREG32(CCSIDR):
+        if ( !cp32.read )
+        {
+            dprintk(XENLOG_ERR,
+                    "attempt to write to read-only register CSSIDR\n");
+            domain_crash_synchronous();
+        }
+        *r = READ_CP32(CCSIDR);
+        break;
+    case HSR_CPREG32(DCCISW):
+        if ( cp32.read )
+        {
+            dprintk(XENLOG_ERR,
+                    "attempt to read from write-only register DCCISW\n");
+            domain_crash_synchronous();
+        }
+        WRITE_CP32(*r, DCCISW);
+        break;
+    case HSR_CPREG32(CNTP_CTL):
+    case HSR_CPREG32(CNTP_TVAL):
+        /* emulate timer */
+        break;
+    default:
+        printk("%s p15, %d, r%d, cr%d, cr%d, %d @ %#08x\n",
+               cp32.read ? "mrc" : "mcr",
+               cp32.op1, cp32.reg, cp32.crn, cp32.crm, cp32.op2, regs->pc);
+        panic("unhandled 32-bit CP15 access %#x\n", hsr.bits & HSR_CP32_REGS_MASK);
+    }
+    regs->pc += cp32.len ? 4 : 2;
+
+}
+
+static void do_cp15_64(struct cpu_user_regs *regs,
+                       union hsr hsr)
+{
+    struct hsr_cp64 cp64 = hsr.cp64;
+
+    if ( !cp64.ccvalid ) {
+        dprintk(XENLOG_ERR, "cp_15(64): need to handle invalid condition codes\n");
+        domain_crash_synchronous();
+    }
+    if ( cp64.cc != 0xe ) {
+        dprintk(XENLOG_ERR, "cp_15(64): need to handle condition codes %x\n",
+                cp64.cc);
+        domain_crash_synchronous();
+    }
+
+    switch ( hsr.bits & HSR_CP64_REGS_MASK )
+    {
+    case HSR_CPREG64(CNTPCT):
+        /* emulate timer */
+        break;
+    default:
+        printk("%s p15, %d, r%d, r%d, cr%d @ %#08x\n",
+               cp64.read ? "mrrc" : "mcrr",
+               cp64.op1, cp64.reg1, cp64.reg2, cp64.crm, regs->pc);
+        panic("unhandled 64-bit CP15 access %#x\n", hsr.bits & HSR_CP64_REGS_MASK);
+    }
+    regs->pc += cp64.len ? 4 : 2;
+
+}
+
+static void do_trap_data_abort_guest(struct cpu_user_regs *regs,
+                                     struct hsr_dabt dabt)
+{
+    const char *msg;
+    int level = -1;
+    mmio_info_t info;
+
+    if (dabt.s1ptw)
+        goto bad_data_abort;
+
+    info.dabt = dabt;
+    info.gva = READ_CP32(HDFAR);
+    info.gpa = gva_to_ipa(info.gva);
+
+    if (handle_mmio(&info))
+    {
+        regs->pc += dabt.len ? 4 : 2;
+        return;
+    }
+
+bad_data_abort:
+
+    msg = decode_fsc( dabt.dfsc, &level);
+
+    printk("Guest data abort: %s%s%s\n"
+           "    gva=%"PRIx32" gpa=%"PRIpaddr"\n",
+           msg, dabt.s1ptw ? " S2 during S1" : "",
+           fsc_level_str(level),
+           info.gva, info.gpa);
+    if (dabt.valid)
+        printk("    size=%d sign=%d write=%d reg=%d\n",
+               dabt.size, dabt.sign, dabt.write, dabt.reg);
+    else
+        printk("    instruction syndrome invalid\n");
+    printk("    eat=%d cm=%d s1ptw=%d dfsc=%d\n",
+           dabt.eat, dabt.cache, dabt.s1ptw, dabt.dfsc);
+
+    show_execution_state(regs);
+    panic("Unhandled guest data abort\n");
+}
+
+asmlinkage void do_trap_hypervisor(struct cpu_user_regs *regs)
+{
+    union hsr hsr = { .bits = READ_CP32(HSR) };
+
+    switch (hsr.ec) {
+    case HSR_EC_CP15_32:
+        do_cp15_32(regs, hsr);
+        break;
+    case HSR_EC_CP15_64:
+        do_cp15_64(regs, hsr);
+        break;
+    case HSR_EC_HVC:
+        if ( (hsr.iss & 0xff00) == 0xff00 )
+            return do_debug_trap(regs, hsr.iss & 0x00ff);
+        do_trap_hypercall(regs, hsr.iss);
+        break;
+    case HSR_EC_DATA_ABORT_GUEST:
+        do_trap_data_abort_guest(regs, hsr.dabt);
+        break;
+    default:
+        printk("Hypervisor Trap. HSR=0x%x EC=0x%x IL=%x Syndrome=%"PRIx32"\n",
+               hsr.bits, hsr.ec, hsr.len, hsr.iss);
+        do_unexpected_trap("Hypervisor", regs);
+    }
+}
+
+asmlinkage void do_trap_irq(struct cpu_user_regs *regs)
+{
+    gic_interrupt(regs, 0);
+}
+
+asmlinkage void do_trap_fiq(struct cpu_user_regs *regs)
+{
+    gic_interrupt(regs, 1);
+}
+
+asmlinkage void leave_hypervisor_tail(void)
+{
+    while (1)
+    {
+        local_irq_disable();
+        if (!softirq_pending(smp_processor_id()))
+            return;
+        local_irq_enable();
+        do_softirq();
+    }
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 13:14:46 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 13:14:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZ0Hd-0002jR-55; Fri, 09 Dec 2011 13:14:37 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RZ0Hb-0002Za-0k
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 13:14:35 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1323436424!6039693!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMTkxNzY=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23166 invoked from network); 9 Dec 2011 13:13:45 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 13:13:45 -0000
X-IronPort-AV: E=Sophos;i="4.71,325,1320642000"; d="scan'208";a="173546333"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 08:13:43 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 08:13:43 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pB9DCpE7008248;
	Fri, 9 Dec 2011 05:13:26 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 9 Dec 2011 13:13:24 +0000
Message-ID: <1323436408-16335-21-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1112091208420.3517@kaball-desktop>
References: <alpine.DEB.2.00.1112091208420.3517@kaball-desktop>
MIME-Version: 1.0
Cc: keir.xen@gmail.com, Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, JBeulich@suse.com,
	Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v2 21/25] arm: driver for the generic timer for
	ARMv7
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Driver for the generic timer for ARMv7 with virtualization extensions.
Currently it is based on the kernel timer rather than the hypervisor timer
because the latter does not work correctly on our test environment.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
---
 xen/arch/arm/time.c        |  181 ++++++++++++++++++++++++++++++++++++++++++++
 xen/include/asm-arm/time.h |   26 ++++++
 2 files changed, 207 insertions(+), 0 deletions(-)
 create mode 100644 xen/arch/arm/time.c
 create mode 100644 xen/include/asm-arm/time.h

diff --git a/xen/arch/arm/time.c b/xen/arch/arm/time.c
new file mode 100644
index 0000000..13c1254
--- /dev/null
+++ b/xen/arch/arm/time.c
@@ -0,0 +1,181 @@
+/*
+ * xen/arch/arm/time.c
+ *
+ * Time and timer support, using the ARM Generic Timer interfaces
+ *
+ * Tim Deegan <tim@xen.org>
+ * Copyright (c) 2011 Citrix Systems.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include <xen/config.h>
+#include <xen/console.h>
+#include <xen/init.h>
+#include <xen/irq.h>
+#include <xen/lib.h>
+#include <xen/mm.h>
+#include <xen/softirq.h>
+#include <xen/time.h>
+#include <asm/system.h>
+
+/* Unfortunately the hypervisor timer interrupt appears to be buggy */
+#define USE_HYP_TIMER 0
+
+/* For fine-grained timekeeping, we use the ARM "Generic Timer", a
+ * register-mapped time source in the SoC. */
+static uint32_t __read_mostly cntfrq;      /* Ticks per second */
+static uint64_t __read_mostly boot_count;  /* Counter value at boot time */
+
+/*static inline*/ s_time_t ticks_to_ns(uint64_t ticks)
+{
+    return muldiv64(ticks, SECONDS(1), cntfrq);
+}
+
+/*static inline*/ uint64_t ns_to_ticks(s_time_t ns)
+{
+    return muldiv64(ns, cntfrq, SECONDS(1));
+}
+
+/* TODO: On a real system the firmware would have set the frequency in
+   the CNTFRQ register.  Also we'd need to use devicetree to find
+   the RTC.  When we've seen some real systems, we can delete this.
+static uint32_t calibrate_timer(void)
+{
+    uint32_t sec;
+    uint64_t start, end;
+    paddr_t rtc_base = 0x1C170000ull;
+    volatile uint32_t *rtc;
+
+    ASSERT(!local_irq_is_enabled());
+    set_fixmap(FIXMAP_MISC, rtc_base >> PAGE_SHIFT, DEV_SHARED);
+    rtc = (uint32_t *) FIXMAP_ADDR(FIXMAP_MISC);
+
+    printk("Calibrating timer against RTC...");
+    // Turn on the RTC
+    rtc[3] = 1;
+    // Wait for an edge
+    sec = rtc[0] + 1;
+    do {} while ( rtc[0] != sec );
+    // Now time a few seconds
+    start = READ_CP64(CNTPCT);
+    do {} while ( rtc[0] < sec + 32 );
+    end = READ_CP64(CNTPCT);
+    printk("done.\n");
+
+    clear_fixmap(FIXMAP_MISC);
+    return (end - start) / 32;
+}
+*/
+
+/* Set up the timer on the boot CPU */
+int __init init_xen_time(void)
+{
+    /* Check that this CPU supports the Generic Timer interface */
+    if ( (READ_CP32(ID_PFR1) & ID_PFR1_GT_MASK) != ID_PFR1_GT_v1 )
+        panic("CPU does not support the Generic Timer v1 interface.\n");
+
+    cntfrq = READ_CP32(CNTFRQ);
+    boot_count = READ_CP64(CNTPCT);
+    printk("Using generic timer at %"PRIu32" Hz\n", cntfrq);
+
+    return 0;
+}
+
+/* Return number of nanoseconds since boot */
+s_time_t get_s_time(void)
+{
+    uint64_t ticks = READ_CP64(CNTPCT) - boot_count;
+    return ticks_to_ns(ticks);
+}
+
+/* Set the timer to wake us up at a particular time.
+ * Timeout is a Xen system time (nanoseconds since boot); 0 disables the timer.
+ * Returns 1 on success; 0 if the timeout is too soon or is in the past. */
+int reprogram_timer(s_time_t timeout)
+{
+    uint64_t deadline;
+
+    if ( timeout == 0 )
+    {
+#if USE_HYP_TIMER
+        WRITE_CP32(0, CNTHP_CTL);
+#else
+        WRITE_CP32(0, CNTP_CTL);
+#endif
+        return 1;
+    }
+
+    deadline = ns_to_ticks(timeout) + boot_count;
+#if USE_HYP_TIMER
+    WRITE_CP64(deadline, CNTHP_CVAL);
+    WRITE_CP32(CNTx_CTL_ENABLE, CNTHP_CTL);
+#else
+    WRITE_CP64(deadline, CNTP_CVAL);
+    WRITE_CP32(CNTx_CTL_ENABLE, CNTP_CTL);
+#endif
+    isb();
+
+    /* No need to check for timers in the past; the Generic Timer fires
+     * on a signed 63-bit comparison. */
+    return 1;
+}
+
+/* Handle the firing timer */
+static void timer_interrupt(int irq, void *dev_id, struct cpu_user_regs *regs)
+{
+    if ( irq == 26 && READ_CP32(CNTHP_CTL) & CNTx_CTL_PENDING )
+    {
+        /* Signal the generic timer code to do its work */
+        raise_softirq(TIMER_SOFTIRQ);
+        /* Disable the timer to avoid more interrupts */
+        WRITE_CP32(0, CNTHP_CTL);
+    }
+
+    if (irq == 30 && READ_CP32(CNTP_CTL) & CNTx_CTL_PENDING )
+    {
+        /* Signal the generic timer code to do its work */
+        raise_softirq(TIMER_SOFTIRQ);
+        /* Disable the timer to avoid more interrupts */
+        WRITE_CP32(0, CNTP_CTL);
+    }
+}
+
+/* Set up the timer interrupt on this CPU */
+void __cpuinit init_timer_interrupt(void)
+{
+    /* Sensible defaults */
+    WRITE_CP64(0, CNTVOFF);     /* No VM-specific offset */
+    WRITE_CP32(0, CNTKCTL);     /* No user-mode access */
+#if USE_HYP_TIMER
+    /* Let the VMs read the physical counter and timer so they can tell time */
+    WRITE_CP32(CNTHCTL_PA|CNTHCTL_TA, CNTHCTL);
+#else
+    /* Cannot let VMs access physical counter if we are using it */
+    WRITE_CP32(0, CNTHCTL);
+#endif
+    WRITE_CP32(0, CNTP_CTL);    /* Physical timer disabled */
+    WRITE_CP32(0, CNTHP_CTL);   /* Hypervisor's timer disabled */
+    isb();
+
+    /* XXX Need to find this IRQ number from devicetree? */
+    request_irq(26, timer_interrupt, 0, "hyptimer", NULL);
+    request_irq(30, timer_interrupt, 0, "phytimer", NULL);
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/time.h b/xen/include/asm-arm/time.h
new file mode 100644
index 0000000..8cc9e78
--- /dev/null
+++ b/xen/include/asm-arm/time.h
@@ -0,0 +1,26 @@
+#ifndef __ARM_TIME_H__
+#define __ARM_TIME_H__
+
+typedef unsigned long cycles_t;
+
+static inline cycles_t get_cycles (void)
+{
+        return 0;
+}
+
+struct tm;
+struct tm wallclock_time(void);
+
+
+/* Set up the timer interrupt on this CPU */
+extern void __cpuinit init_timer_interrupt(void);
+
+#endif /* __ARM_TIME_H__ */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 13:14:46 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 13:14:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZ0Hd-0002jR-55; Fri, 09 Dec 2011 13:14:37 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RZ0Hb-0002Za-0k
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 13:14:35 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1323436424!6039693!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMTkxNzY=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23166 invoked from network); 9 Dec 2011 13:13:45 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 13:13:45 -0000
X-IronPort-AV: E=Sophos;i="4.71,325,1320642000"; d="scan'208";a="173546333"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 08:13:43 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 08:13:43 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pB9DCpE7008248;
	Fri, 9 Dec 2011 05:13:26 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 9 Dec 2011 13:13:24 +0000
Message-ID: <1323436408-16335-21-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1112091208420.3517@kaball-desktop>
References: <alpine.DEB.2.00.1112091208420.3517@kaball-desktop>
MIME-Version: 1.0
Cc: keir.xen@gmail.com, Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, JBeulich@suse.com,
	Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v2 21/25] arm: driver for the generic timer for
	ARMv7
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Driver for the generic timer for ARMv7 with virtualization extensions.
Currently it is based on the kernel timer rather than the hypervisor timer
because the latter does not work correctly on our test environment.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
---
 xen/arch/arm/time.c        |  181 ++++++++++++++++++++++++++++++++++++++++++++
 xen/include/asm-arm/time.h |   26 ++++++
 2 files changed, 207 insertions(+), 0 deletions(-)
 create mode 100644 xen/arch/arm/time.c
 create mode 100644 xen/include/asm-arm/time.h

diff --git a/xen/arch/arm/time.c b/xen/arch/arm/time.c
new file mode 100644
index 0000000..13c1254
--- /dev/null
+++ b/xen/arch/arm/time.c
@@ -0,0 +1,181 @@
+/*
+ * xen/arch/arm/time.c
+ *
+ * Time and timer support, using the ARM Generic Timer interfaces
+ *
+ * Tim Deegan <tim@xen.org>
+ * Copyright (c) 2011 Citrix Systems.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include <xen/config.h>
+#include <xen/console.h>
+#include <xen/init.h>
+#include <xen/irq.h>
+#include <xen/lib.h>
+#include <xen/mm.h>
+#include <xen/softirq.h>
+#include <xen/time.h>
+#include <asm/system.h>
+
+/* Unfortunately the hypervisor timer interrupt appears to be buggy */
+#define USE_HYP_TIMER 0
+
+/* For fine-grained timekeeping, we use the ARM "Generic Timer", a
+ * register-mapped time source in the SoC. */
+static uint32_t __read_mostly cntfrq;      /* Ticks per second */
+static uint64_t __read_mostly boot_count;  /* Counter value at boot time */
+
+/*static inline*/ s_time_t ticks_to_ns(uint64_t ticks)
+{
+    return muldiv64(ticks, SECONDS(1), cntfrq);
+}
+
+/*static inline*/ uint64_t ns_to_ticks(s_time_t ns)
+{
+    return muldiv64(ns, cntfrq, SECONDS(1));
+}
+
+/* TODO: On a real system the firmware would have set the frequency in
+   the CNTFRQ register.  Also we'd need to use devicetree to find
+   the RTC.  When we've seen some real systems, we can delete this.
+static uint32_t calibrate_timer(void)
+{
+    uint32_t sec;
+    uint64_t start, end;
+    paddr_t rtc_base = 0x1C170000ull;
+    volatile uint32_t *rtc;
+
+    ASSERT(!local_irq_is_enabled());
+    set_fixmap(FIXMAP_MISC, rtc_base >> PAGE_SHIFT, DEV_SHARED);
+    rtc = (uint32_t *) FIXMAP_ADDR(FIXMAP_MISC);
+
+    printk("Calibrating timer against RTC...");
+    // Turn on the RTC
+    rtc[3] = 1;
+    // Wait for an edge
+    sec = rtc[0] + 1;
+    do {} while ( rtc[0] != sec );
+    // Now time a few seconds
+    start = READ_CP64(CNTPCT);
+    do {} while ( rtc[0] < sec + 32 );
+    end = READ_CP64(CNTPCT);
+    printk("done.\n");
+
+    clear_fixmap(FIXMAP_MISC);
+    return (end - start) / 32;
+}
+*/
+
+/* Set up the timer on the boot CPU */
+int __init init_xen_time(void)
+{
+    /* Check that this CPU supports the Generic Timer interface */
+    if ( (READ_CP32(ID_PFR1) & ID_PFR1_GT_MASK) != ID_PFR1_GT_v1 )
+        panic("CPU does not support the Generic Timer v1 interface.\n");
+
+    cntfrq = READ_CP32(CNTFRQ);
+    boot_count = READ_CP64(CNTPCT);
+    printk("Using generic timer at %"PRIu32" Hz\n", cntfrq);
+
+    return 0;
+}
+
+/* Return number of nanoseconds since boot */
+s_time_t get_s_time(void)
+{
+    uint64_t ticks = READ_CP64(CNTPCT) - boot_count;
+    return ticks_to_ns(ticks);
+}
+
+/* Set the timer to wake us up at a particular time.
+ * Timeout is a Xen system time (nanoseconds since boot); 0 disables the timer.
+ * Returns 1 on success; 0 if the timeout is too soon or is in the past. */
+int reprogram_timer(s_time_t timeout)
+{
+    uint64_t deadline;
+
+    if ( timeout == 0 )
+    {
+#if USE_HYP_TIMER
+        WRITE_CP32(0, CNTHP_CTL);
+#else
+        WRITE_CP32(0, CNTP_CTL);
+#endif
+        return 1;
+    }
+
+    deadline = ns_to_ticks(timeout) + boot_count;
+#if USE_HYP_TIMER
+    WRITE_CP64(deadline, CNTHP_CVAL);
+    WRITE_CP32(CNTx_CTL_ENABLE, CNTHP_CTL);
+#else
+    WRITE_CP64(deadline, CNTP_CVAL);
+    WRITE_CP32(CNTx_CTL_ENABLE, CNTP_CTL);
+#endif
+    isb();
+
+    /* No need to check for timers in the past; the Generic Timer fires
+     * on a signed 63-bit comparison. */
+    return 1;
+}
+
+/* Handle the firing timer */
+static void timer_interrupt(int irq, void *dev_id, struct cpu_user_regs *regs)
+{
+    if ( irq == 26 && READ_CP32(CNTHP_CTL) & CNTx_CTL_PENDING )
+    {
+        /* Signal the generic timer code to do its work */
+        raise_softirq(TIMER_SOFTIRQ);
+        /* Disable the timer to avoid more interrupts */
+        WRITE_CP32(0, CNTHP_CTL);
+    }
+
+    if (irq == 30 && READ_CP32(CNTP_CTL) & CNTx_CTL_PENDING )
+    {
+        /* Signal the generic timer code to do its work */
+        raise_softirq(TIMER_SOFTIRQ);
+        /* Disable the timer to avoid more interrupts */
+        WRITE_CP32(0, CNTP_CTL);
+    }
+}
+
+/* Set up the timer interrupt on this CPU */
+void __cpuinit init_timer_interrupt(void)
+{
+    /* Sensible defaults */
+    WRITE_CP64(0, CNTVOFF);     /* No VM-specific offset */
+    WRITE_CP32(0, CNTKCTL);     /* No user-mode access */
+#if USE_HYP_TIMER
+    /* Let the VMs read the physical counter and timer so they can tell time */
+    WRITE_CP32(CNTHCTL_PA|CNTHCTL_TA, CNTHCTL);
+#else
+    /* Cannot let VMs access physical counter if we are using it */
+    WRITE_CP32(0, CNTHCTL);
+#endif
+    WRITE_CP32(0, CNTP_CTL);    /* Physical timer disabled */
+    WRITE_CP32(0, CNTHP_CTL);   /* Hypervisor's timer disabled */
+    isb();
+
+    /* XXX Need to find this IRQ number from devicetree? */
+    request_irq(26, timer_interrupt, 0, "hyptimer", NULL);
+    request_irq(30, timer_interrupt, 0, "phytimer", NULL);
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/time.h b/xen/include/asm-arm/time.h
new file mode 100644
index 0000000..8cc9e78
--- /dev/null
+++ b/xen/include/asm-arm/time.h
@@ -0,0 +1,26 @@
+#ifndef __ARM_TIME_H__
+#define __ARM_TIME_H__
+
+typedef unsigned long cycles_t;
+
+static inline cycles_t get_cycles (void)
+{
+        return 0;
+}
+
+struct tm;
+struct tm wallclock_time(void);
+
+
+/* Set up the timer interrupt on this CPU */
+extern void __cpuinit init_timer_interrupt(void);
+
+#endif /* __ARM_TIME_H__ */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 13:14:46 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 13:14:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZ0HQ-0002VE-Qf; Fri, 09 Dec 2011 13:14:24 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RZ0HO-0002QT-Gv
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 13:14:23 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1323436408!4727117!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMTkxNzY=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27345 invoked from network); 9 Dec 2011 13:13:32 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 13:13:32 -0000
X-IronPort-AV: E=Sophos;i="4.71,325,1320642000"; d="scan'208";a="173546299"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 08:13:31 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 08:13:31 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pB9DCpE0008248;
	Fri, 9 Dec 2011 05:13:14 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 9 Dec 2011 13:13:17 +0000
Message-ID: <1323436408-16335-14-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1112091208420.3517@kaball-desktop>
References: <alpine.DEB.2.00.1112091208420.3517@kaball-desktop>
MIME-Version: 1.0
Cc: keir.xen@gmail.com, Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, JBeulich@suse.com,
	Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v2 14/25] arm: driver for CoreLink GIC-400
	Generic Interrupt Controller
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

- GICC, GICD and GICH initialization;

- interrupts routing, acking and EOI;

- interrupt injection into guests;

- maintenance interrupt handler, that takes care of EOI physical
  interrupts on behalf of the guest;

- a function to remap the virtual cpu interface into the guest address
  space, where the guest expect the GICC to be.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
---
 xen/arch/arm/domain.c |    2 +
 xen/arch/arm/gic.c    |  473 +++++++++++++++++++++++++++++++++++++++++++++++++
 xen/arch/arm/gic.h    |  151 ++++++++++++++++
 3 files changed, 626 insertions(+), 0 deletions(-)
 create mode 100644 xen/arch/arm/gic.c
 create mode 100644 xen/arch/arm/gic.h

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index d706b5f..ecbc5b7 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -11,6 +11,8 @@
 #include <asm/p2m.h>
 #include <asm/irq.h>
 
+#include "gic.h"
+
 DEFINE_PER_CPU(struct vcpu *, curr_vcpu);
 
 static void continue_idle_domain(struct vcpu *v)
diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
new file mode 100644
index 0000000..9643a7d
--- /dev/null
+++ b/xen/arch/arm/gic.c
@@ -0,0 +1,473 @@
+/*
+ * xen/arch/arm/gic.c
+ *
+ * ARM Generic Interrupt Controller support
+ *
+ * Tim Deegan <tim@xen.org>
+ * Copyright (c) 2011 Citrix Systems.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include <xen/config.h>
+#include <xen/lib.h>
+#include <xen/init.h>
+#include <xen/mm.h>
+#include <xen/irq.h>
+#include <xen/sched.h>
+#include <xen/errno.h>
+#include <xen/softirq.h>
+#include <asm/p2m.h>
+#include <asm/domain.h>
+
+#include "gic.h"
+
+/* Access to the GIC Distributor registers through the fixmap */
+#define GICD ((volatile uint32_t *) FIXMAP_ADDR(FIXMAP_GICD))
+#define GICC ((volatile uint32_t *) (FIXMAP_ADDR(FIXMAP_GICC1)  \
+                                     + (GIC_CR_OFFSET & 0xfff)))
+#define GICH ((volatile uint32_t *) (FIXMAP_ADDR(FIXMAP_GICH)  \
+                                     + (GIC_HR_OFFSET & 0xfff)))
+
+/* Global state */
+static struct {
+    paddr_t dbase;       /* Address of distributor registers */
+    paddr_t cbase;       /* Address of CPU interface registers */
+    paddr_t hbase;       /* Address of virtual interface registers */
+    unsigned int lines;
+    unsigned int cpus;
+    spinlock_t lock;
+} gic;
+
+irq_desc_t irq_desc[NR_IRQS];
+unsigned nr_lrs;
+
+static unsigned int gic_irq_startup(struct irq_desc *desc)
+{
+    uint32_t enabler;
+	int irq = desc->irq;
+
+    /* Enable routing */
+    enabler = GICD[GICD_ISENABLER + irq / 32];
+    GICD[GICD_ISENABLER + irq / 32] = enabler | (1u << (irq % 32));
+
+    return 0;
+}
+
+static void gic_irq_shutdown(struct irq_desc *desc)
+{
+    uint32_t enabler;
+	int irq = desc->irq;
+
+    /* Disable routing */
+    enabler = GICD[GICD_ICENABLER + irq / 32];
+    GICD[GICD_ICENABLER + irq / 32] = enabler | (1u << (irq % 32));
+}
+
+static void gic_irq_enable(struct irq_desc *desc)
+{
+
+}
+
+static void gic_irq_disable(struct irq_desc *desc)
+{
+
+}
+
+static void gic_irq_ack(struct irq_desc *desc)
+{
+    /* No ACK -- reading IAR has done this for us */
+}
+
+static void gic_host_irq_end(struct irq_desc *desc)
+{
+	int irq = desc->irq;
+    /* Lower the priority */
+    GICC[GICC_EOIR] = irq;
+    /* Deactivate */
+    GICC[GICC_DIR] = irq;
+}
+
+static void gic_guest_irq_end(struct irq_desc *desc)
+{
+	int irq = desc->irq;
+    /* Lower the priority of the IRQ */
+    GICC[GICC_EOIR] = irq;
+    /* Deactivation happens in maintenance interrupt / via GICV */
+}
+
+static void gic_irq_set_affinity(struct irq_desc *desc, const cpumask_t *mask)
+{
+    BUG();
+}
+
+/* XXX different for level vs edge */
+static hw_irq_controller gic_host_irq_type = {
+    .typename = "gic",
+    .startup = gic_irq_startup,
+    .shutdown = gic_irq_shutdown,
+    .enable = gic_irq_enable,
+    .disable = gic_irq_disable,
+    .ack = gic_irq_ack,
+    .end = gic_host_irq_end,
+    .set_affinity = gic_irq_set_affinity,
+};
+static hw_irq_controller gic_guest_irq_type = {
+    .typename = "gic",
+    .startup = gic_irq_startup,
+    .shutdown = gic_irq_shutdown,
+    .enable = gic_irq_enable,
+    .disable = gic_irq_disable,
+    .ack = gic_irq_ack,
+    .end = gic_guest_irq_end,
+    .set_affinity = gic_irq_set_affinity,
+};
+
+/* Program the GIC to route an interrupt */
+static int gic_route_irq(unsigned int irq, bool_t level,
+                         unsigned int cpu_mask, unsigned int priority)
+{
+    volatile unsigned char *bytereg;
+    uint32_t cfg, edgebit;
+    struct irq_desc *desc = irq_to_desc(irq);
+    unsigned long flags;
+
+    ASSERT(!(cpu_mask & ~0xff));  /* Targets bitmap only supports 8 CPUs */
+    ASSERT(priority <= 0xff);     /* Only 8 bits of priority */
+    ASSERT(irq < gic.lines + 32); /* Can't route interrupts that don't exist */
+
+    spin_lock_irqsave(&desc->lock, flags);
+    spin_lock(&gic.lock);
+
+    if ( desc->action != NULL )
+    {
+        spin_unlock(&desc->lock);
+        return -EBUSY;
+    }
+
+    desc->handler = &gic_host_irq_type;
+
+    /* Disable interrupt */
+    desc->handler->shutdown(desc);
+
+    /* Set edge / level */
+    cfg = GICD[GICD_ICFGR + irq / 16];
+    edgebit = 2u << (2 * (irq % 16));
+    if ( level )
+        cfg &= ~edgebit;
+    else
+        cfg |= edgebit;
+    GICD[GICD_ICFGR + irq / 16] = cfg;
+
+    /* Set target CPU mask (RAZ/WI on uniprocessor) */
+    bytereg = (unsigned char *) (GICD + GICD_ITARGETSR);
+    bytereg[irq] = cpu_mask;
+
+    /* Set priority */
+    bytereg = (unsigned char *) (GICD + GICD_IPRIORITYR);
+    bytereg[irq] = priority;
+
+    spin_unlock(&gic.lock);
+    spin_unlock_irqrestore(&desc->lock, flags);
+    return 0;
+}
+
+static void __init gic_dist_init(void)
+{
+    uint32_t type;
+    uint32_t cpumask = 1 << smp_processor_id();
+    int i;
+
+    cpumask |= cpumask << 8;
+    cpumask |= cpumask << 16;
+
+    /* Disable the distributor */
+    GICD[GICD_CTLR] = 0;
+
+    type = GICD[GICD_TYPER];
+    gic.lines = 32 * (type & GICD_TYPE_LINES);
+    gic.cpus = 1 + ((type & GICD_TYPE_CPUS) >> 5);
+    printk("GIC: %d lines, %d cpu%s%s (IID %8.8x).\n",
+           gic.lines, gic.cpus, (gic.cpus == 1) ? "" : "s",
+           (type & GICD_TYPE_SEC) ? ", secure" : "",
+           GICD[GICD_IIDR]);
+
+    /* Default all global IRQs to level, active low */
+    for ( i = 32; i < gic.lines; i += 16 )
+        GICD[GICD_ICFGR + i / 16] = 0x0;
+
+    /* Route all global IRQs to this CPU */
+    for ( i = 32; i < gic.lines; i += 4 )
+        GICD[GICD_ICFGR + i / 4] = cpumask;
+
+    /* Default priority for global interrupts */
+    for ( i = 32; i < gic.lines; i += 4 )
+        GICD[GICD_IPRIORITYR + i / 4] = 0xa0a0a0a0;
+
+    /* Disable all global interrupts */
+    for ( i = 32; i < gic.lines; i += 32 )
+        GICD[GICD_ICENABLER + i / 32] = ~0ul;
+
+    /* Turn on the distributor */
+    GICD[GICD_CTLR] = GICD_CTL_ENABLE;
+}
+
+static void __cpuinit gic_cpu_init(void)
+{
+    int i;
+
+    /* Disable all PPI and enable all SGI */
+    GICD[GICD_ICENABLER] = 0xffff0000; /* Disable all PPI */
+    GICD[GICD_ISENABLER] = 0x0000ffff; /* Enable all SGI */
+    /* Set PPI and SGI priorities */
+    for (i = 0; i < 32; i += 4)
+        GICD[GICD_IPRIORITYR + i / 4] = 0xa0a0a0a0;
+
+    /* Local settings: interface controller */
+    GICC[GICC_PMR] = 0xff;                /* Don't mask by priority */
+    GICC[GICC_BPR] = 0;                   /* Finest granularity of priority */
+    GICC[GICC_CTLR] = GICC_CTL_ENABLE|GICC_CTL_EOI;    /* Turn on delivery */
+}
+
+static void __cpuinit gic_hyp_init(void)
+{
+    uint32_t vtr;
+
+    vtr = GICH[GICH_VTR];
+    nr_lrs  = (vtr & GICH_VTR_NRLRGS) + 1;
+    printk("GICH: %d list registers available\n", nr_lrs);
+
+    GICH[GICH_HCR] = GICH_HCR_EN;
+    GICH[GICH_MISR] = GICH_MISR_EOI;
+}
+
+/* Set up the GIC */
+void gic_init(void)
+{
+    /* XXX FIXME get this from devicetree */
+    gic.dbase = GIC_BASE_ADDRESS + GIC_DR_OFFSET;
+    gic.cbase = GIC_BASE_ADDRESS + GIC_CR_OFFSET;
+    gic.hbase = GIC_BASE_ADDRESS + GIC_HR_OFFSET;
+    set_fixmap(FIXMAP_GICD, gic.dbase >> PAGE_SHIFT, DEV_SHARED);
+    BUILD_BUG_ON(FIXMAP_ADDR(FIXMAP_GICC1) !=
+                 FIXMAP_ADDR(FIXMAP_GICC2)-PAGE_SIZE);
+    set_fixmap(FIXMAP_GICC1, gic.cbase >> PAGE_SHIFT, DEV_SHARED);
+    set_fixmap(FIXMAP_GICC2, (gic.cbase >> PAGE_SHIFT) + 1, DEV_SHARED);
+    set_fixmap(FIXMAP_GICH, gic.hbase >> PAGE_SHIFT, DEV_SHARED);
+
+    /* Global settings: interrupt distributor */
+    spin_lock_init(&gic.lock);
+    spin_lock(&gic.lock);
+
+    gic_dist_init();
+    gic_cpu_init();
+    gic_hyp_init();
+
+    spin_unlock(&gic.lock);
+}
+
+void gic_route_irqs(void)
+{
+    /* XXX should get these from DT */
+    /* GIC maintenance */
+    gic_route_irq(25, 1, 1u << smp_processor_id(), 0xa0);
+    /* Hypervisor Timer */
+    gic_route_irq(26, 1, 1u << smp_processor_id(), 0xa0);
+    /* Timer */
+    gic_route_irq(30, 1, 1u << smp_processor_id(), 0xa0);
+    /* UART */
+    gic_route_irq(37, 0, 1u << smp_processor_id(), 0xa0);
+}
+
+void __init release_irq(unsigned int irq)
+{
+    struct irq_desc *desc;
+    unsigned long flags;
+   struct irqaction *action;
+
+    desc = irq_to_desc(irq);
+
+    spin_lock_irqsave(&desc->lock,flags);
+    action = desc->action;
+    desc->action  = NULL;
+    desc->status |= IRQ_DISABLED;
+
+    spin_lock(&gic.lock);
+    desc->handler->shutdown(desc);
+    spin_unlock(&gic.lock);
+
+    spin_unlock_irqrestore(&desc->lock,flags);
+
+    /* Wait to make sure it's not being used on another CPU */
+    do { smp_mb(); } while ( desc->status & IRQ_INPROGRESS );
+
+    if (action && action->free_on_release)
+        xfree(action);
+}
+
+static int __setup_irq(struct irq_desc *desc, unsigned int irq,
+                       struct irqaction *new)
+{
+    if ( desc->action != NULL )
+        return -EBUSY;
+
+    desc->action  = new;
+    desc->status &= ~IRQ_DISABLED;
+    dsb();
+
+    desc->handler->startup(desc);
+
+    return 0;
+}
+
+int __init setup_irq(unsigned int irq, struct irqaction *new)
+{
+    int rc;
+    unsigned long flags;
+    struct irq_desc *desc;
+
+    desc = irq_to_desc(irq);
+
+    spin_lock_irqsave(&desc->lock, flags);
+
+    rc = __setup_irq(desc, irq, new);
+
+    spin_unlock_irqrestore(&desc->lock,flags);
+
+    return rc;
+}
+
+void gic_set_guest_irq(unsigned int virtual_irq,
+        unsigned int state, unsigned int priority)
+{
+    BUG_ON(virtual_irq > nr_lrs);
+    GICH[GICH_LR + virtual_irq] = state |
+        GICH_LR_MAINTENANCE_IRQ |
+        ((priority >> 3) << GICH_LR_PRIORITY_SHIFT) |
+        ((virtual_irq & GICH_LR_VIRTUAL_MASK) << GICH_LR_VIRTUAL_SHIFT);
+}
+
+void gic_inject_irq_start(void)
+{
+    uint32_t hcr;
+    hcr = READ_CP32(HCR);
+    WRITE_CP32(hcr | HCR_VI, HCR);
+    isb();
+}
+
+void gic_inject_irq_stop(void)
+{
+    uint32_t hcr;
+    hcr = READ_CP32(HCR);
+    if (hcr & HCR_VI) {
+        WRITE_CP32(hcr & ~HCR_VI, HCR);
+        isb();
+    }
+}
+
+int gic_route_irq_to_guest(struct domain *d, unsigned int irq,
+                           const char * devname)
+{
+    struct irqaction *action;
+    struct irq_desc *desc = irq_to_desc(irq);
+    unsigned long flags;
+    int retval;
+
+    action = xmalloc(struct irqaction);
+    if (!action)
+        return -ENOMEM;
+
+    action->dev_id = d;
+    action->name = devname;
+
+    spin_lock_irqsave(&desc->lock, flags);
+
+    desc->handler = &gic_guest_irq_type;
+    desc->status |= IRQ_GUEST;
+
+    retval = __setup_irq(desc, irq, action);
+    if (retval) {
+        xfree(action);
+        goto out;
+    }
+
+out:
+    spin_unlock_irqrestore(&desc->lock, flags);
+    return retval;
+}
+
+/* Accept an interrupt from the GIC and dispatch its handler */
+void gic_interrupt(struct cpu_user_regs *regs, int is_fiq)
+{
+    uint32_t intack = GICC[GICC_IAR];
+    unsigned int irq = intack & GICC_IA_IRQ;
+
+    if ( irq == 1023 )
+        /* Spurious interrupt */
+        return;
+
+    do_IRQ(regs, irq, is_fiq);
+}
+
+void gicv_setup(struct domain *d)
+{
+    /* map the gic virtual cpu interface in the gic cpu interface region of
+     * the guest */
+    printk("mapping GICC at %#"PRIx32" to %#"PRIx32"\n",
+           GIC_BASE_ADDRESS + GIC_CR_OFFSET,
+           GIC_BASE_ADDRESS + GIC_VR_OFFSET);
+    map_mmio_regions(d, GIC_BASE_ADDRESS + GIC_CR_OFFSET,
+                        GIC_BASE_ADDRESS + GIC_CR_OFFSET + (2 * PAGE_SIZE) - 1,
+                        GIC_BASE_ADDRESS + GIC_VR_OFFSET);
+}
+
+static void maintenance_interrupt(int irq, void *dev_id, struct cpu_user_regs *regs)
+{
+    int i, virq;
+    uint32_t lr;
+    uint64_t eisr = GICH[GICH_EISR0] | (((uint64_t) GICH[GICH_EISR1]) << 32);
+
+    for ( i = 0; i < 64; i++ ) {
+        if ( eisr & ((uint64_t)1 << i) ) {
+            struct pending_irq *p;
+
+            lr = GICH[GICH_LR + i];
+            virq = lr & GICH_LR_VIRTUAL_MASK;
+            GICH[GICH_LR + i] = 0;
+
+            spin_lock(&current->arch.vgic.lock);
+            p = irq_to_pending(current, virq);
+            if ( p->desc != NULL ) {
+                p->desc->status &= ~IRQ_INPROGRESS;
+                GICC[GICC_DIR] = virq;
+            }
+            gic_inject_irq_stop();
+            list_del(&p->link);
+            INIT_LIST_HEAD(&p->link);
+            cpu_raise_softirq(current->processor, VGIC_SOFTIRQ);
+            spin_unlock(&current->arch.vgic.lock);
+        }
+    }
+}
+
+void __cpuinit init_maintenance_interrupt(void)
+{
+    request_irq(25, maintenance_interrupt, 0, "irq-maintenance", NULL);
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/arch/arm/gic.h b/xen/arch/arm/gic.h
new file mode 100644
index 0000000..63b6648
--- /dev/null
+++ b/xen/arch/arm/gic.h
@@ -0,0 +1,151 @@
+/*
+ * xen/arch/arm/gic.h
+ *
+ * ARM Generic Interrupt Controller support
+ *
+ * Tim Deegan <tim@xen.org>
+ * Copyright (c) 2011 Citrix Systems.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#ifndef __ARCH_ARM_GIC_H__
+#define __ARCH_ARM_GIC_H__
+
+#define GICD_CTLR       (0x000/4)
+#define GICD_TYPER      (0x004/4)
+#define GICD_IIDR       (0x008/4)
+#define GICD_IGROUPR    (0x080/4)
+#define GICD_IGROUPRN   (0x0FC/4)
+#define GICD_ISENABLER  (0x100/4)
+#define GICD_ISENABLERN (0x17C/4)
+#define GICD_ICENABLER  (0x180/4)
+#define GICD_ICENABLERN (0x1fC/4)
+#define GICD_ISPENDR    (0x200/4)
+#define GICD_ISPENDRN   (0x27C/4)
+#define GICD_ICPENDR    (0x280/4)
+#define GICD_ICPENDRN   (0x2FC/4)
+#define GICD_ISACTIVER  (0x300/4)
+#define GICD_ISACTIVERN (0x37C/4)
+#define GICD_ICACTIVER  (0x380/4)
+#define GICD_ICACTIVERN (0x3FC/4)
+#define GICD_IPRIORITYR (0x400/4)
+#define GICD_IPRIORITYRN (0x7F8/4)
+#define GICD_ITARGETSR  (0x800/4)
+#define GICD_ITARGETSRN (0xBF8/4)
+#define GICD_ICFGR      (0xC00/4)
+#define GICD_ICFGRN     (0xCFC/4)
+#define GICD_NSACR      (0xE00/4)
+#define GICD_NSACRN     (0xEFC/4)
+#define GICD_ICPIDR2    (0xFE8/4)
+#define GICD_SGIR       (0xF00/4)
+#define GICD_CPENDSGIR  (0xF10/4)
+#define GICD_CPENDSGIRN (0xF1C/4)
+#define GICD_SPENDSGIR  (0xF20/4)
+#define GICD_SPENDSGIRN (0xF2C/4)
+#define GICD_ICPIDR2    (0xFE8/4)
+
+#define GICC_CTLR       (0x0000/4)
+#define GICC_PMR        (0x0004/4)
+#define GICC_BPR        (0x0008/4)
+#define GICC_IAR        (0x000C/4)
+#define GICC_EOIR       (0x0010/4)
+#define GICC_RPR        (0x0014/4)
+#define GICC_HPPIR      (0x0018/4)
+#define GICC_APR        (0x00D0/4)
+#define GICC_NSAPR      (0x00E0/4)
+#define GICC_DIR        (0x1000/4)
+
+#define GICH_HCR        (0x00/4)
+#define GICH_VTR        (0x04/4)
+#define GICH_VMCR       (0x08/4)
+#define GICH_MISR       (0x10/4)
+#define GICH_EISR0      (0x20/4)
+#define GICH_EISR1      (0x24/4)
+#define GICH_ELRSR0     (0x30/4)
+#define GICH_ELRSR1     (0x34/4)
+#define GICH_APR        (0xF0/4)
+#define GICH_LR         (0x100/4)
+
+/* Register bits */
+#define GICD_CTL_ENABLE 0x1
+
+#define GICD_TYPE_LINES 0x01f
+#define GICD_TYPE_CPUS  0x0e0
+#define GICD_TYPE_SEC   0x400
+
+#define GICC_CTL_ENABLE 0x1
+#define GICC_CTL_EOI    (0x1 << 9)
+
+#define GICC_IA_IRQ     0x03ff
+#define GICC_IA_CPU     0x1c00
+
+#define GICH_HCR_EN       (1 << 0)
+#define GICH_HCR_UIE      (1 << 1)
+#define GICH_HCR_LRENPIE  (1 << 2)
+#define GICH_HCR_NPIE     (1 << 3)
+#define GICH_HCR_VGRP0EIE (1 << 4)
+#define GICH_HCR_VGRP0DIE (1 << 5)
+#define GICH_HCR_VGRP1EIE (1 << 6)
+#define GICH_HCR_VGRP1DIE (1 << 7)
+
+#define GICH_MISR_EOI     (1 << 0)
+#define GICH_MISR_U       (1 << 1)
+#define GICH_MISR_LRENP   (1 << 2)
+#define GICH_MISR_NP      (1 << 3)
+#define GICH_MISR_VGRP0E  (1 << 4)
+#define GICH_MISR_VGRP0D  (1 << 5)
+#define GICH_MISR_VGRP1E  (1 << 6)
+#define GICH_MISR_VGRP1D  (1 << 7)
+
+#define GICH_LR_VIRTUAL_MASK    0x3ff
+#define GICH_LR_VIRTUAL_SHIFT   0
+#define GICH_LR_PHYSICAL_MASK   0x3ff
+#define GICH_LR_PHYSICAL_SHIFT  10
+#define GICH_LR_STATE_MASK      0x3
+#define GICH_LR_STATE_SHIFT     28
+#define GICH_LR_PRIORITY_SHIFT  23
+#define GICH_LR_MAINTENANCE_IRQ (1<<19)
+#define GICH_LR_PENDING         (1<<28)
+#define GICH_LR_ACTIVE          (1<<29)
+#define GICH_LR_GRP1            (1<<30)
+#define GICH_LR_HW              (1<<31)
+#define GICH_LR_CPUID_SHIFT     9
+#define GICH_VTR_NRLRGS         0x3f
+
+extern struct pending_irq *irq_to_pending(struct vcpu *v, unsigned int irq);
+
+extern void gic_route_irqs(void);
+
+extern void __cpuinit init_maintenance_interrupt(void);
+extern void gic_set_guest_irq(unsigned int irq,
+        unsigned int state, unsigned int priority);
+extern void gic_inject_irq_start(void);
+extern void gic_inject_irq_stop(void);
+extern int gic_route_irq_to_guest(struct domain *d, unsigned int irq,
+                                  const char * devname);
+
+/* Accept an interrupt from the GIC and dispatch its handler */
+extern void gic_interrupt(struct cpu_user_regs *regs, int is_fiq);
+/* Bring up the interrupt controller */
+extern void gic_init(void);
+/* setup the gic virtual interface for a guest */
+extern void gicv_setup(struct domain *d);
+#endif
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 13:14:46 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 13:14:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZ0HQ-0002VE-Qf; Fri, 09 Dec 2011 13:14:24 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RZ0HO-0002QT-Gv
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 13:14:23 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1323436408!4727117!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMTkxNzY=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27345 invoked from network); 9 Dec 2011 13:13:32 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 13:13:32 -0000
X-IronPort-AV: E=Sophos;i="4.71,325,1320642000"; d="scan'208";a="173546299"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 08:13:31 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 08:13:31 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pB9DCpE0008248;
	Fri, 9 Dec 2011 05:13:14 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 9 Dec 2011 13:13:17 +0000
Message-ID: <1323436408-16335-14-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1112091208420.3517@kaball-desktop>
References: <alpine.DEB.2.00.1112091208420.3517@kaball-desktop>
MIME-Version: 1.0
Cc: keir.xen@gmail.com, Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, JBeulich@suse.com,
	Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v2 14/25] arm: driver for CoreLink GIC-400
	Generic Interrupt Controller
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

- GICC, GICD and GICH initialization;

- interrupts routing, acking and EOI;

- interrupt injection into guests;

- maintenance interrupt handler, that takes care of EOI physical
  interrupts on behalf of the guest;

- a function to remap the virtual cpu interface into the guest address
  space, where the guest expect the GICC to be.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
---
 xen/arch/arm/domain.c |    2 +
 xen/arch/arm/gic.c    |  473 +++++++++++++++++++++++++++++++++++++++++++++++++
 xen/arch/arm/gic.h    |  151 ++++++++++++++++
 3 files changed, 626 insertions(+), 0 deletions(-)
 create mode 100644 xen/arch/arm/gic.c
 create mode 100644 xen/arch/arm/gic.h

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index d706b5f..ecbc5b7 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -11,6 +11,8 @@
 #include <asm/p2m.h>
 #include <asm/irq.h>
 
+#include "gic.h"
+
 DEFINE_PER_CPU(struct vcpu *, curr_vcpu);
 
 static void continue_idle_domain(struct vcpu *v)
diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
new file mode 100644
index 0000000..9643a7d
--- /dev/null
+++ b/xen/arch/arm/gic.c
@@ -0,0 +1,473 @@
+/*
+ * xen/arch/arm/gic.c
+ *
+ * ARM Generic Interrupt Controller support
+ *
+ * Tim Deegan <tim@xen.org>
+ * Copyright (c) 2011 Citrix Systems.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include <xen/config.h>
+#include <xen/lib.h>
+#include <xen/init.h>
+#include <xen/mm.h>
+#include <xen/irq.h>
+#include <xen/sched.h>
+#include <xen/errno.h>
+#include <xen/softirq.h>
+#include <asm/p2m.h>
+#include <asm/domain.h>
+
+#include "gic.h"
+
+/* Access to the GIC Distributor registers through the fixmap */
+#define GICD ((volatile uint32_t *) FIXMAP_ADDR(FIXMAP_GICD))
+#define GICC ((volatile uint32_t *) (FIXMAP_ADDR(FIXMAP_GICC1)  \
+                                     + (GIC_CR_OFFSET & 0xfff)))
+#define GICH ((volatile uint32_t *) (FIXMAP_ADDR(FIXMAP_GICH)  \
+                                     + (GIC_HR_OFFSET & 0xfff)))
+
+/* Global state */
+static struct {
+    paddr_t dbase;       /* Address of distributor registers */
+    paddr_t cbase;       /* Address of CPU interface registers */
+    paddr_t hbase;       /* Address of virtual interface registers */
+    unsigned int lines;
+    unsigned int cpus;
+    spinlock_t lock;
+} gic;
+
+irq_desc_t irq_desc[NR_IRQS];
+unsigned nr_lrs;
+
+static unsigned int gic_irq_startup(struct irq_desc *desc)
+{
+    uint32_t enabler;
+	int irq = desc->irq;
+
+    /* Enable routing */
+    enabler = GICD[GICD_ISENABLER + irq / 32];
+    GICD[GICD_ISENABLER + irq / 32] = enabler | (1u << (irq % 32));
+
+    return 0;
+}
+
+static void gic_irq_shutdown(struct irq_desc *desc)
+{
+    uint32_t enabler;
+	int irq = desc->irq;
+
+    /* Disable routing */
+    enabler = GICD[GICD_ICENABLER + irq / 32];
+    GICD[GICD_ICENABLER + irq / 32] = enabler | (1u << (irq % 32));
+}
+
+static void gic_irq_enable(struct irq_desc *desc)
+{
+
+}
+
+static void gic_irq_disable(struct irq_desc *desc)
+{
+
+}
+
+static void gic_irq_ack(struct irq_desc *desc)
+{
+    /* No ACK -- reading IAR has done this for us */
+}
+
+static void gic_host_irq_end(struct irq_desc *desc)
+{
+	int irq = desc->irq;
+    /* Lower the priority */
+    GICC[GICC_EOIR] = irq;
+    /* Deactivate */
+    GICC[GICC_DIR] = irq;
+}
+
+static void gic_guest_irq_end(struct irq_desc *desc)
+{
+	int irq = desc->irq;
+    /* Lower the priority of the IRQ */
+    GICC[GICC_EOIR] = irq;
+    /* Deactivation happens in maintenance interrupt / via GICV */
+}
+
+static void gic_irq_set_affinity(struct irq_desc *desc, const cpumask_t *mask)
+{
+    BUG();
+}
+
+/* XXX different for level vs edge */
+static hw_irq_controller gic_host_irq_type = {
+    .typename = "gic",
+    .startup = gic_irq_startup,
+    .shutdown = gic_irq_shutdown,
+    .enable = gic_irq_enable,
+    .disable = gic_irq_disable,
+    .ack = gic_irq_ack,
+    .end = gic_host_irq_end,
+    .set_affinity = gic_irq_set_affinity,
+};
+static hw_irq_controller gic_guest_irq_type = {
+    .typename = "gic",
+    .startup = gic_irq_startup,
+    .shutdown = gic_irq_shutdown,
+    .enable = gic_irq_enable,
+    .disable = gic_irq_disable,
+    .ack = gic_irq_ack,
+    .end = gic_guest_irq_end,
+    .set_affinity = gic_irq_set_affinity,
+};
+
+/* Program the GIC to route an interrupt */
+static int gic_route_irq(unsigned int irq, bool_t level,
+                         unsigned int cpu_mask, unsigned int priority)
+{
+    volatile unsigned char *bytereg;
+    uint32_t cfg, edgebit;
+    struct irq_desc *desc = irq_to_desc(irq);
+    unsigned long flags;
+
+    ASSERT(!(cpu_mask & ~0xff));  /* Targets bitmap only supports 8 CPUs */
+    ASSERT(priority <= 0xff);     /* Only 8 bits of priority */
+    ASSERT(irq < gic.lines + 32); /* Can't route interrupts that don't exist */
+
+    spin_lock_irqsave(&desc->lock, flags);
+    spin_lock(&gic.lock);
+
+    if ( desc->action != NULL )
+    {
+        spin_unlock(&desc->lock);
+        return -EBUSY;
+    }
+
+    desc->handler = &gic_host_irq_type;
+
+    /* Disable interrupt */
+    desc->handler->shutdown(desc);
+
+    /* Set edge / level */
+    cfg = GICD[GICD_ICFGR + irq / 16];
+    edgebit = 2u << (2 * (irq % 16));
+    if ( level )
+        cfg &= ~edgebit;
+    else
+        cfg |= edgebit;
+    GICD[GICD_ICFGR + irq / 16] = cfg;
+
+    /* Set target CPU mask (RAZ/WI on uniprocessor) */
+    bytereg = (unsigned char *) (GICD + GICD_ITARGETSR);
+    bytereg[irq] = cpu_mask;
+
+    /* Set priority */
+    bytereg = (unsigned char *) (GICD + GICD_IPRIORITYR);
+    bytereg[irq] = priority;
+
+    spin_unlock(&gic.lock);
+    spin_unlock_irqrestore(&desc->lock, flags);
+    return 0;
+}
+
+static void __init gic_dist_init(void)
+{
+    uint32_t type;
+    uint32_t cpumask = 1 << smp_processor_id();
+    int i;
+
+    cpumask |= cpumask << 8;
+    cpumask |= cpumask << 16;
+
+    /* Disable the distributor */
+    GICD[GICD_CTLR] = 0;
+
+    type = GICD[GICD_TYPER];
+    gic.lines = 32 * (type & GICD_TYPE_LINES);
+    gic.cpus = 1 + ((type & GICD_TYPE_CPUS) >> 5);
+    printk("GIC: %d lines, %d cpu%s%s (IID %8.8x).\n",
+           gic.lines, gic.cpus, (gic.cpus == 1) ? "" : "s",
+           (type & GICD_TYPE_SEC) ? ", secure" : "",
+           GICD[GICD_IIDR]);
+
+    /* Default all global IRQs to level, active low */
+    for ( i = 32; i < gic.lines; i += 16 )
+        GICD[GICD_ICFGR + i / 16] = 0x0;
+
+    /* Route all global IRQs to this CPU */
+    for ( i = 32; i < gic.lines; i += 4 )
+        GICD[GICD_ICFGR + i / 4] = cpumask;
+
+    /* Default priority for global interrupts */
+    for ( i = 32; i < gic.lines; i += 4 )
+        GICD[GICD_IPRIORITYR + i / 4] = 0xa0a0a0a0;
+
+    /* Disable all global interrupts */
+    for ( i = 32; i < gic.lines; i += 32 )
+        GICD[GICD_ICENABLER + i / 32] = ~0ul;
+
+    /* Turn on the distributor */
+    GICD[GICD_CTLR] = GICD_CTL_ENABLE;
+}
+
+static void __cpuinit gic_cpu_init(void)
+{
+    int i;
+
+    /* Disable all PPI and enable all SGI */
+    GICD[GICD_ICENABLER] = 0xffff0000; /* Disable all PPI */
+    GICD[GICD_ISENABLER] = 0x0000ffff; /* Enable all SGI */
+    /* Set PPI and SGI priorities */
+    for (i = 0; i < 32; i += 4)
+        GICD[GICD_IPRIORITYR + i / 4] = 0xa0a0a0a0;
+
+    /* Local settings: interface controller */
+    GICC[GICC_PMR] = 0xff;                /* Don't mask by priority */
+    GICC[GICC_BPR] = 0;                   /* Finest granularity of priority */
+    GICC[GICC_CTLR] = GICC_CTL_ENABLE|GICC_CTL_EOI;    /* Turn on delivery */
+}
+
+static void __cpuinit gic_hyp_init(void)
+{
+    uint32_t vtr;
+
+    vtr = GICH[GICH_VTR];
+    nr_lrs  = (vtr & GICH_VTR_NRLRGS) + 1;
+    printk("GICH: %d list registers available\n", nr_lrs);
+
+    GICH[GICH_HCR] = GICH_HCR_EN;
+    GICH[GICH_MISR] = GICH_MISR_EOI;
+}
+
+/* Set up the GIC */
+void gic_init(void)
+{
+    /* XXX FIXME get this from devicetree */
+    gic.dbase = GIC_BASE_ADDRESS + GIC_DR_OFFSET;
+    gic.cbase = GIC_BASE_ADDRESS + GIC_CR_OFFSET;
+    gic.hbase = GIC_BASE_ADDRESS + GIC_HR_OFFSET;
+    set_fixmap(FIXMAP_GICD, gic.dbase >> PAGE_SHIFT, DEV_SHARED);
+    BUILD_BUG_ON(FIXMAP_ADDR(FIXMAP_GICC1) !=
+                 FIXMAP_ADDR(FIXMAP_GICC2)-PAGE_SIZE);
+    set_fixmap(FIXMAP_GICC1, gic.cbase >> PAGE_SHIFT, DEV_SHARED);
+    set_fixmap(FIXMAP_GICC2, (gic.cbase >> PAGE_SHIFT) + 1, DEV_SHARED);
+    set_fixmap(FIXMAP_GICH, gic.hbase >> PAGE_SHIFT, DEV_SHARED);
+
+    /* Global settings: interrupt distributor */
+    spin_lock_init(&gic.lock);
+    spin_lock(&gic.lock);
+
+    gic_dist_init();
+    gic_cpu_init();
+    gic_hyp_init();
+
+    spin_unlock(&gic.lock);
+}
+
+void gic_route_irqs(void)
+{
+    /* XXX should get these from DT */
+    /* GIC maintenance */
+    gic_route_irq(25, 1, 1u << smp_processor_id(), 0xa0);
+    /* Hypervisor Timer */
+    gic_route_irq(26, 1, 1u << smp_processor_id(), 0xa0);
+    /* Timer */
+    gic_route_irq(30, 1, 1u << smp_processor_id(), 0xa0);
+    /* UART */
+    gic_route_irq(37, 0, 1u << smp_processor_id(), 0xa0);
+}
+
+void __init release_irq(unsigned int irq)
+{
+    struct irq_desc *desc;
+    unsigned long flags;
+   struct irqaction *action;
+
+    desc = irq_to_desc(irq);
+
+    spin_lock_irqsave(&desc->lock,flags);
+    action = desc->action;
+    desc->action  = NULL;
+    desc->status |= IRQ_DISABLED;
+
+    spin_lock(&gic.lock);
+    desc->handler->shutdown(desc);
+    spin_unlock(&gic.lock);
+
+    spin_unlock_irqrestore(&desc->lock,flags);
+
+    /* Wait to make sure it's not being used on another CPU */
+    do { smp_mb(); } while ( desc->status & IRQ_INPROGRESS );
+
+    if (action && action->free_on_release)
+        xfree(action);
+}
+
+static int __setup_irq(struct irq_desc *desc, unsigned int irq,
+                       struct irqaction *new)
+{
+    if ( desc->action != NULL )
+        return -EBUSY;
+
+    desc->action  = new;
+    desc->status &= ~IRQ_DISABLED;
+    dsb();
+
+    desc->handler->startup(desc);
+
+    return 0;
+}
+
+int __init setup_irq(unsigned int irq, struct irqaction *new)
+{
+    int rc;
+    unsigned long flags;
+    struct irq_desc *desc;
+
+    desc = irq_to_desc(irq);
+
+    spin_lock_irqsave(&desc->lock, flags);
+
+    rc = __setup_irq(desc, irq, new);
+
+    spin_unlock_irqrestore(&desc->lock,flags);
+
+    return rc;
+}
+
+void gic_set_guest_irq(unsigned int virtual_irq,
+        unsigned int state, unsigned int priority)
+{
+    BUG_ON(virtual_irq > nr_lrs);
+    GICH[GICH_LR + virtual_irq] = state |
+        GICH_LR_MAINTENANCE_IRQ |
+        ((priority >> 3) << GICH_LR_PRIORITY_SHIFT) |
+        ((virtual_irq & GICH_LR_VIRTUAL_MASK) << GICH_LR_VIRTUAL_SHIFT);
+}
+
+void gic_inject_irq_start(void)
+{
+    uint32_t hcr;
+    hcr = READ_CP32(HCR);
+    WRITE_CP32(hcr | HCR_VI, HCR);
+    isb();
+}
+
+void gic_inject_irq_stop(void)
+{
+    uint32_t hcr;
+    hcr = READ_CP32(HCR);
+    if (hcr & HCR_VI) {
+        WRITE_CP32(hcr & ~HCR_VI, HCR);
+        isb();
+    }
+}
+
+int gic_route_irq_to_guest(struct domain *d, unsigned int irq,
+                           const char * devname)
+{
+    struct irqaction *action;
+    struct irq_desc *desc = irq_to_desc(irq);
+    unsigned long flags;
+    int retval;
+
+    action = xmalloc(struct irqaction);
+    if (!action)
+        return -ENOMEM;
+
+    action->dev_id = d;
+    action->name = devname;
+
+    spin_lock_irqsave(&desc->lock, flags);
+
+    desc->handler = &gic_guest_irq_type;
+    desc->status |= IRQ_GUEST;
+
+    retval = __setup_irq(desc, irq, action);
+    if (retval) {
+        xfree(action);
+        goto out;
+    }
+
+out:
+    spin_unlock_irqrestore(&desc->lock, flags);
+    return retval;
+}
+
+/* Accept an interrupt from the GIC and dispatch its handler */
+void gic_interrupt(struct cpu_user_regs *regs, int is_fiq)
+{
+    uint32_t intack = GICC[GICC_IAR];
+    unsigned int irq = intack & GICC_IA_IRQ;
+
+    if ( irq == 1023 )
+        /* Spurious interrupt */
+        return;
+
+    do_IRQ(regs, irq, is_fiq);
+}
+
+void gicv_setup(struct domain *d)
+{
+    /* map the gic virtual cpu interface in the gic cpu interface region of
+     * the guest */
+    printk("mapping GICC at %#"PRIx32" to %#"PRIx32"\n",
+           GIC_BASE_ADDRESS + GIC_CR_OFFSET,
+           GIC_BASE_ADDRESS + GIC_VR_OFFSET);
+    map_mmio_regions(d, GIC_BASE_ADDRESS + GIC_CR_OFFSET,
+                        GIC_BASE_ADDRESS + GIC_CR_OFFSET + (2 * PAGE_SIZE) - 1,
+                        GIC_BASE_ADDRESS + GIC_VR_OFFSET);
+}
+
+static void maintenance_interrupt(int irq, void *dev_id, struct cpu_user_regs *regs)
+{
+    int i, virq;
+    uint32_t lr;
+    uint64_t eisr = GICH[GICH_EISR0] | (((uint64_t) GICH[GICH_EISR1]) << 32);
+
+    for ( i = 0; i < 64; i++ ) {
+        if ( eisr & ((uint64_t)1 << i) ) {
+            struct pending_irq *p;
+
+            lr = GICH[GICH_LR + i];
+            virq = lr & GICH_LR_VIRTUAL_MASK;
+            GICH[GICH_LR + i] = 0;
+
+            spin_lock(&current->arch.vgic.lock);
+            p = irq_to_pending(current, virq);
+            if ( p->desc != NULL ) {
+                p->desc->status &= ~IRQ_INPROGRESS;
+                GICC[GICC_DIR] = virq;
+            }
+            gic_inject_irq_stop();
+            list_del(&p->link);
+            INIT_LIST_HEAD(&p->link);
+            cpu_raise_softirq(current->processor, VGIC_SOFTIRQ);
+            spin_unlock(&current->arch.vgic.lock);
+        }
+    }
+}
+
+void __cpuinit init_maintenance_interrupt(void)
+{
+    request_irq(25, maintenance_interrupt, 0, "irq-maintenance", NULL);
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/arch/arm/gic.h b/xen/arch/arm/gic.h
new file mode 100644
index 0000000..63b6648
--- /dev/null
+++ b/xen/arch/arm/gic.h
@@ -0,0 +1,151 @@
+/*
+ * xen/arch/arm/gic.h
+ *
+ * ARM Generic Interrupt Controller support
+ *
+ * Tim Deegan <tim@xen.org>
+ * Copyright (c) 2011 Citrix Systems.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#ifndef __ARCH_ARM_GIC_H__
+#define __ARCH_ARM_GIC_H__
+
+#define GICD_CTLR       (0x000/4)
+#define GICD_TYPER      (0x004/4)
+#define GICD_IIDR       (0x008/4)
+#define GICD_IGROUPR    (0x080/4)
+#define GICD_IGROUPRN   (0x0FC/4)
+#define GICD_ISENABLER  (0x100/4)
+#define GICD_ISENABLERN (0x17C/4)
+#define GICD_ICENABLER  (0x180/4)
+#define GICD_ICENABLERN (0x1fC/4)
+#define GICD_ISPENDR    (0x200/4)
+#define GICD_ISPENDRN   (0x27C/4)
+#define GICD_ICPENDR    (0x280/4)
+#define GICD_ICPENDRN   (0x2FC/4)
+#define GICD_ISACTIVER  (0x300/4)
+#define GICD_ISACTIVERN (0x37C/4)
+#define GICD_ICACTIVER  (0x380/4)
+#define GICD_ICACTIVERN (0x3FC/4)
+#define GICD_IPRIORITYR (0x400/4)
+#define GICD_IPRIORITYRN (0x7F8/4)
+#define GICD_ITARGETSR  (0x800/4)
+#define GICD_ITARGETSRN (0xBF8/4)
+#define GICD_ICFGR      (0xC00/4)
+#define GICD_ICFGRN     (0xCFC/4)
+#define GICD_NSACR      (0xE00/4)
+#define GICD_NSACRN     (0xEFC/4)
+#define GICD_ICPIDR2    (0xFE8/4)
+#define GICD_SGIR       (0xF00/4)
+#define GICD_CPENDSGIR  (0xF10/4)
+#define GICD_CPENDSGIRN (0xF1C/4)
+#define GICD_SPENDSGIR  (0xF20/4)
+#define GICD_SPENDSGIRN (0xF2C/4)
+#define GICD_ICPIDR2    (0xFE8/4)
+
+#define GICC_CTLR       (0x0000/4)
+#define GICC_PMR        (0x0004/4)
+#define GICC_BPR        (0x0008/4)
+#define GICC_IAR        (0x000C/4)
+#define GICC_EOIR       (0x0010/4)
+#define GICC_RPR        (0x0014/4)
+#define GICC_HPPIR      (0x0018/4)
+#define GICC_APR        (0x00D0/4)
+#define GICC_NSAPR      (0x00E0/4)
+#define GICC_DIR        (0x1000/4)
+
+#define GICH_HCR        (0x00/4)
+#define GICH_VTR        (0x04/4)
+#define GICH_VMCR       (0x08/4)
+#define GICH_MISR       (0x10/4)
+#define GICH_EISR0      (0x20/4)
+#define GICH_EISR1      (0x24/4)
+#define GICH_ELRSR0     (0x30/4)
+#define GICH_ELRSR1     (0x34/4)
+#define GICH_APR        (0xF0/4)
+#define GICH_LR         (0x100/4)
+
+/* Register bits */
+#define GICD_CTL_ENABLE 0x1
+
+#define GICD_TYPE_LINES 0x01f
+#define GICD_TYPE_CPUS  0x0e0
+#define GICD_TYPE_SEC   0x400
+
+#define GICC_CTL_ENABLE 0x1
+#define GICC_CTL_EOI    (0x1 << 9)
+
+#define GICC_IA_IRQ     0x03ff
+#define GICC_IA_CPU     0x1c00
+
+#define GICH_HCR_EN       (1 << 0)
+#define GICH_HCR_UIE      (1 << 1)
+#define GICH_HCR_LRENPIE  (1 << 2)
+#define GICH_HCR_NPIE     (1 << 3)
+#define GICH_HCR_VGRP0EIE (1 << 4)
+#define GICH_HCR_VGRP0DIE (1 << 5)
+#define GICH_HCR_VGRP1EIE (1 << 6)
+#define GICH_HCR_VGRP1DIE (1 << 7)
+
+#define GICH_MISR_EOI     (1 << 0)
+#define GICH_MISR_U       (1 << 1)
+#define GICH_MISR_LRENP   (1 << 2)
+#define GICH_MISR_NP      (1 << 3)
+#define GICH_MISR_VGRP0E  (1 << 4)
+#define GICH_MISR_VGRP0D  (1 << 5)
+#define GICH_MISR_VGRP1E  (1 << 6)
+#define GICH_MISR_VGRP1D  (1 << 7)
+
+#define GICH_LR_VIRTUAL_MASK    0x3ff
+#define GICH_LR_VIRTUAL_SHIFT   0
+#define GICH_LR_PHYSICAL_MASK   0x3ff
+#define GICH_LR_PHYSICAL_SHIFT  10
+#define GICH_LR_STATE_MASK      0x3
+#define GICH_LR_STATE_SHIFT     28
+#define GICH_LR_PRIORITY_SHIFT  23
+#define GICH_LR_MAINTENANCE_IRQ (1<<19)
+#define GICH_LR_PENDING         (1<<28)
+#define GICH_LR_ACTIVE          (1<<29)
+#define GICH_LR_GRP1            (1<<30)
+#define GICH_LR_HW              (1<<31)
+#define GICH_LR_CPUID_SHIFT     9
+#define GICH_VTR_NRLRGS         0x3f
+
+extern struct pending_irq *irq_to_pending(struct vcpu *v, unsigned int irq);
+
+extern void gic_route_irqs(void);
+
+extern void __cpuinit init_maintenance_interrupt(void);
+extern void gic_set_guest_irq(unsigned int irq,
+        unsigned int state, unsigned int priority);
+extern void gic_inject_irq_start(void);
+extern void gic_inject_irq_stop(void);
+extern int gic_route_irq_to_guest(struct domain *d, unsigned int irq,
+                                  const char * devname);
+
+/* Accept an interrupt from the GIC and dispatch its handler */
+extern void gic_interrupt(struct cpu_user_regs *regs, int is_fiq);
+/* Bring up the interrupt controller */
+extern void gic_init(void);
+/* setup the gic virtual interface for a guest */
+extern void gicv_setup(struct domain *d);
+#endif
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 13:14:46 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 13:14:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZ0HS-0002WQ-69; Fri, 09 Dec 2011 13:14:26 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RZ0HP-0002Rg-QD
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 13:14:24 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1323436410!4910460!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDQ0MTg=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9972 invoked from network); 9 Dec 2011 13:13:33 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 13:13:33 -0000
X-IronPort-AV: E=Sophos;i="4.71,325,1320642000"; d="scan'208";a="19808907"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 08:13:33 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 08:13:33 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pB9DCpE1008248;
	Fri, 9 Dec 2011 05:13:16 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 9 Dec 2011 13:13:18 +0000
Message-ID: <1323436408-16335-15-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1112091208420.3517@kaball-desktop>
References: <alpine.DEB.2.00.1112091208420.3517@kaball-desktop>
MIME-Version: 1.0
Cc: keir.xen@gmail.com, Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, JBeulich@suse.com,
	Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v2 15/25] arm: mmio handlers
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Basic infrastructure to emulate mmio reads and writes.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
---
 xen/arch/arm/io.c |   50 ++++++++++++++++++++++++++++++++++++++++++++++++++
 xen/arch/arm/io.h |   53 +++++++++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 103 insertions(+), 0 deletions(-)
 create mode 100644 xen/arch/arm/io.c
 create mode 100644 xen/arch/arm/io.h

diff --git a/xen/arch/arm/io.c b/xen/arch/arm/io.c
new file mode 100644
index 0000000..8789705
--- /dev/null
+++ b/xen/arch/arm/io.c
@@ -0,0 +1,50 @@
+/*
+ * xen/arch/arm/io.h
+ *
+ * ARM I/O handlers
+ *
+ * Copyright (c) 2011 Citrix Systems.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include <xen/config.h>
+#include <xen/lib.h>
+#include <asm/current.h>
+
+#include "io.h"
+
+static const struct mmio_handler *const mmio_handlers[] =
+{
+};
+#define MMIO_HANDLER_NR ARRAY_SIZE(mmio_handlers)
+
+int handle_mmio(mmio_info_t *info)
+{
+    struct vcpu *v = current;
+    int i;
+
+    for ( i = 0; i < MMIO_HANDLER_NR; i++ )
+        if ( mmio_handlers[i]->check_handler(v, info->gpa) )
+            return info->dabt.write ?
+                mmio_handlers[i]->write_handler(v, info) :
+                mmio_handlers[i]->read_handler(v, info);
+
+    return 0;
+}
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/arch/arm/io.h b/xen/arch/arm/io.h
new file mode 100644
index 0000000..d7847e3
--- /dev/null
+++ b/xen/arch/arm/io.h
@@ -0,0 +1,53 @@
+/*
+ * xen/arch/arm/io.h
+ *
+ * ARM I/O handlers
+ *
+ * Copyright (c) 2011 Citrix Systems.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#ifndef __ARCH_ARM_IO_H__
+#define __ARCH_ARM_IO_H__
+
+#include <xen/lib.h>
+#include <asm/processor.h>
+
+typedef struct
+{
+    struct hsr_dabt dabt;
+    uint32_t gva;
+    paddr_t gpa;
+} mmio_info_t;
+
+typedef int (*mmio_read_t)(struct vcpu *v, mmio_info_t *info);
+typedef int (*mmio_write_t)(struct vcpu *v, mmio_info_t *info);
+typedef int (*mmio_check_t)(struct vcpu *v, paddr_t addr);
+
+struct mmio_handler {
+    mmio_check_t check_handler;
+    mmio_read_t read_handler;
+    mmio_write_t write_handler;
+};
+
+extern int handle_mmio(mmio_info_t *info);
+
+#endif
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 13:14:46 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 13:14:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZ0HS-0002WQ-69; Fri, 09 Dec 2011 13:14:26 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RZ0HP-0002Rg-QD
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 13:14:24 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1323436410!4910460!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDQ0MTg=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9972 invoked from network); 9 Dec 2011 13:13:33 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 13:13:33 -0000
X-IronPort-AV: E=Sophos;i="4.71,325,1320642000"; d="scan'208";a="19808907"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 08:13:33 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 08:13:33 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pB9DCpE1008248;
	Fri, 9 Dec 2011 05:13:16 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 9 Dec 2011 13:13:18 +0000
Message-ID: <1323436408-16335-15-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1112091208420.3517@kaball-desktop>
References: <alpine.DEB.2.00.1112091208420.3517@kaball-desktop>
MIME-Version: 1.0
Cc: keir.xen@gmail.com, Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, JBeulich@suse.com,
	Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v2 15/25] arm: mmio handlers
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Basic infrastructure to emulate mmio reads and writes.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
---
 xen/arch/arm/io.c |   50 ++++++++++++++++++++++++++++++++++++++++++++++++++
 xen/arch/arm/io.h |   53 +++++++++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 103 insertions(+), 0 deletions(-)
 create mode 100644 xen/arch/arm/io.c
 create mode 100644 xen/arch/arm/io.h

diff --git a/xen/arch/arm/io.c b/xen/arch/arm/io.c
new file mode 100644
index 0000000..8789705
--- /dev/null
+++ b/xen/arch/arm/io.c
@@ -0,0 +1,50 @@
+/*
+ * xen/arch/arm/io.h
+ *
+ * ARM I/O handlers
+ *
+ * Copyright (c) 2011 Citrix Systems.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include <xen/config.h>
+#include <xen/lib.h>
+#include <asm/current.h>
+
+#include "io.h"
+
+static const struct mmio_handler *const mmio_handlers[] =
+{
+};
+#define MMIO_HANDLER_NR ARRAY_SIZE(mmio_handlers)
+
+int handle_mmio(mmio_info_t *info)
+{
+    struct vcpu *v = current;
+    int i;
+
+    for ( i = 0; i < MMIO_HANDLER_NR; i++ )
+        if ( mmio_handlers[i]->check_handler(v, info->gpa) )
+            return info->dabt.write ?
+                mmio_handlers[i]->write_handler(v, info) :
+                mmio_handlers[i]->read_handler(v, info);
+
+    return 0;
+}
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/arch/arm/io.h b/xen/arch/arm/io.h
new file mode 100644
index 0000000..d7847e3
--- /dev/null
+++ b/xen/arch/arm/io.h
@@ -0,0 +1,53 @@
+/*
+ * xen/arch/arm/io.h
+ *
+ * ARM I/O handlers
+ *
+ * Copyright (c) 2011 Citrix Systems.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#ifndef __ARCH_ARM_IO_H__
+#define __ARCH_ARM_IO_H__
+
+#include <xen/lib.h>
+#include <asm/processor.h>
+
+typedef struct
+{
+    struct hsr_dabt dabt;
+    uint32_t gva;
+    paddr_t gpa;
+} mmio_info_t;
+
+typedef int (*mmio_read_t)(struct vcpu *v, mmio_info_t *info);
+typedef int (*mmio_write_t)(struct vcpu *v, mmio_info_t *info);
+typedef int (*mmio_check_t)(struct vcpu *v, paddr_t addr);
+
+struct mmio_handler {
+    mmio_check_t check_handler;
+    mmio_read_t read_handler;
+    mmio_write_t write_handler;
+};
+
+extern int handle_mmio(mmio_info_t *info);
+
+#endif
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 13:14:47 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 13:14:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZ0Hb-0002hi-V4; Fri, 09 Dec 2011 13:14:35 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RZ0HZ-0002Xu-8h
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 13:14:33 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1323436420!6775414!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDQ0MTg=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8974 invoked from network); 9 Dec 2011 13:13:42 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 13:13:42 -0000
X-IronPort-AV: E=Sophos;i="4.71,325,1320642000"; d="scan'208";a="19808911"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 08:13:42 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 08:13:41 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pB9DCpE9008248;
	Fri, 9 Dec 2011 05:13:30 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 9 Dec 2011 13:13:26 +0000
Message-ID: <1323436408-16335-23-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1112091208420.3517@kaball-desktop>
References: <alpine.DEB.2.00.1112091208420.3517@kaball-desktop>
MIME-Version: 1.0
Cc: keir.xen@gmail.com, Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, JBeulich@suse.com,
	Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v2 23/25] arm: vgic emulation
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

- emulation of the GICD interface for the guest;

- interrupt injection into the guest;

- keep track of inflight irqs using a list, ordered by priority.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
---
 xen/arch/arm/domain.c        |    6 +
 xen/arch/arm/gic.h           |    3 +
 xen/arch/arm/io.c            |    1 +
 xen/arch/arm/io.h            |    2 +
 xen/arch/arm/irq.c           |    3 +-
 xen/arch/arm/vgic.c          |  605 ++++++++++++++++++++++++++++++++++++++++++
 xen/include/asm-arm/domain.h |   30 ++
 7 files changed, 649 insertions(+), 1 deletions(-)
 create mode 100644 xen/arch/arm/vgic.c

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 0844b37..7e681ab 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -212,6 +212,9 @@ int vcpu_initialise(struct vcpu *v)
 {
     int rc = 0;
 
+    if ( (rc = vcpu_vgic_init(v)) != 0 )
+        return rc;
+
     return rc;
 }
 
@@ -230,6 +233,9 @@ int arch_domain_create(struct domain *d, unsigned int domcr_flags)
 
     d->max_vcpus = 8;
 
+    if ( (rc = domain_vgic_init(d)) != 0 )
+        goto fail;
+
     rc = 0;
 fail:
     return rc;
diff --git a/xen/arch/arm/gic.h b/xen/arch/arm/gic.h
index 63b6648..81c388d 100644
--- a/xen/arch/arm/gic.h
+++ b/xen/arch/arm/gic.h
@@ -121,6 +121,9 @@
 #define GICH_LR_CPUID_SHIFT     9
 #define GICH_VTR_NRLRGS         0x3f
 
+extern int domain_vgic_init(struct domain *d);
+extern int vcpu_vgic_init(struct vcpu *v);
+extern void vgic_vcpu_inject_irq(struct vcpu *v, unsigned int irq,int virtual);
 extern struct pending_irq *irq_to_pending(struct vcpu *v, unsigned int irq);
 
 extern void gic_route_irqs(void);
diff --git a/xen/arch/arm/io.c b/xen/arch/arm/io.c
index 8789705..4461225 100644
--- a/xen/arch/arm/io.c
+++ b/xen/arch/arm/io.c
@@ -24,6 +24,7 @@
 
 static const struct mmio_handler *const mmio_handlers[] =
 {
+    &vgic_distr_mmio_handler,
 };
 #define MMIO_HANDLER_NR ARRAY_SIZE(mmio_handlers)
 
diff --git a/xen/arch/arm/io.h b/xen/arch/arm/io.h
index d7847e3..8cc5ca7 100644
--- a/xen/arch/arm/io.h
+++ b/xen/arch/arm/io.h
@@ -39,6 +39,8 @@ struct mmio_handler {
     mmio_write_t write_handler;
 };
 
+extern const struct mmio_handler vgic_distr_mmio_handler;
+
 extern int handle_mmio(mmio_info_t *info);
 
 #endif
diff --git a/xen/arch/arm/irq.c b/xen/arch/arm/irq.c
index 5663762..7820310 100644
--- a/xen/arch/arm/irq.c
+++ b/xen/arch/arm/irq.c
@@ -136,7 +136,8 @@ void do_IRQ(struct cpu_user_regs *regs, unsigned int irq, int is_fiq)
 
         desc->status |= IRQ_INPROGRESS;
 
-        /* XXX: inject irq into the guest */
+        /* XXX: inject irq into all guest vcpus */
+        vgic_vcpu_inject_irq(d->vcpu[0], irq, 0);
         goto out_no_end;
     }
 
diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
new file mode 100644
index 0000000..26eae55
--- /dev/null
+++ b/xen/arch/arm/vgic.c
@@ -0,0 +1,605 @@
+/*
+ * xen/arch/arm/vgic.c
+ *
+ * ARM Virtual Generic Interrupt Controller support
+ *
+ * Ian Campbell <ian.campbell@citrix.com>
+ * Copyright (c) 2011 Citrix Systems.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include <xen/config.h>
+#include <xen/lib.h>
+#include <xen/init.h>
+#include <xen/softirq.h>
+#include <xen/irq.h>
+#include <xen/sched.h>
+
+#include <asm/current.h>
+
+#include "io.h"
+#include "gic.h"
+
+#define VGIC_DISTR_BASE_ADDRESS 0x000000002c001000
+
+#define REG(n) (n/4)
+
+/* Number of ranks of interrupt registers for a domain */
+#define DOMAIN_NR_RANKS(d) (((d)->arch.vgic.nr_lines+31)/32)
+
+/*
+ * Rank containing GICD_<FOO><n> for GICD_<FOO> with
+ * <b>-bits-per-interrupt
+ */
+static inline int REG_RANK_NR(int b, uint32_t n)
+{
+    switch ( b )
+    {
+    case 8: return n >> 3;
+    case 4: return n >> 2;
+    case 2: return n >> 1;
+    default: BUG();
+    }
+}
+
+/*
+ * Offset of GICD_<FOO><n> with its rank, for GICD_<FOO> with
+ * <b>-bits-per-interrupt.
+ */
+#define REG_RANK_INDEX(b, n) ((n) & ((b)-1))
+
+/*
+ * Returns rank corresponding to a GICD_<FOO><n> register for
+ * GICD_<FOO> with <b>-bits-per-interrupt.
+ */
+static struct vgic_irq_rank *vgic_irq_rank(struct vcpu *v, int b, int n)
+{
+    int rank = REG_RANK_NR(b, n);
+
+    if ( rank == 0 )
+        return &v->arch.vgic.private_irqs;
+    else if ( rank <= DOMAIN_NR_RANKS(v->domain) )
+        return &v->domain->arch.vgic.shared_irqs[rank - 1];
+    else
+        return NULL;
+}
+
+int domain_vgic_init(struct domain *d)
+{
+    int i;
+
+    d->arch.vgic.ctlr = 0;
+    d->arch.vgic.nr_lines = 32;
+    d->arch.vgic.shared_irqs =
+        xmalloc_array(struct vgic_irq_rank, DOMAIN_NR_RANKS(d));
+    d->arch.vgic.pending_irqs =
+        xmalloc_array(struct pending_irq,
+                d->arch.vgic.nr_lines + (32 * d->max_vcpus));
+    for (i=0; i<d->arch.vgic.nr_lines + (32 * d->max_vcpus); i++)
+        INIT_LIST_HEAD(&d->arch.vgic.pending_irqs[i].link);
+    for (i=0; i<DOMAIN_NR_RANKS(d); i++)
+        spin_lock_init(&d->arch.vgic.shared_irqs[i].lock);
+    return 0;
+}
+
+int vcpu_vgic_init(struct vcpu *v)
+{
+    int i;
+    memset(&v->arch.vgic.private_irqs, 0, sizeof(v->arch.vgic.private_irqs));
+
+    spin_lock_init(&v->arch.vgic.private_irqs.lock);
+
+    /* For SGI and PPI the target is always this CPU */
+    for ( i = 0 ; i < 8 ; i++ )
+        v->arch.vgic.private_irqs.itargets[i] =
+              (1<<(v->vcpu_id+0))
+            | (1<<(v->vcpu_id+8))
+            | (1<<(v->vcpu_id+16))
+            | (1<<(v->vcpu_id+24));
+    INIT_LIST_HEAD(&v->arch.vgic.inflight_irqs);
+    spin_lock_init(&v->arch.vgic.lock);
+
+    return 0;
+}
+
+#define vgic_lock(v)   spin_lock(&(v)->domain->arch.vgic.lock)
+#define vgic_unlock(v) spin_unlock(&(v)->domain->arch.vgic.lock)
+
+#define vgic_lock_rank(v, r) spin_lock(&(r)->lock)
+#define vgic_unlock_rank(v, r) spin_unlock(&(r)->lock)
+
+static uint32_t byte_read(uint32_t val, int sign, int offset)
+{
+    int byte = offset & 0x3;
+
+    val = val >> (8*byte);
+    if ( sign && (val & 0x80) )
+        val |= 0xffffff00;
+    else
+        val &= 0x000000ff;
+    return val;
+}
+
+static void byte_write(uint32_t *reg, uint32_t var, int offset)
+{
+    int byte = offset & 0x3;
+
+    var &= (0xff << (8*byte));
+
+    *reg &= ~(0xff << (8*byte));
+    *reg |= var;
+}
+
+static int vgic_distr_mmio_read(struct vcpu *v, mmio_info_t *info)
+{
+    struct hsr_dabt dabt = info->dabt;
+    struct cpu_user_regs *regs = guest_cpu_user_regs();
+    uint32_t *r = &regs->r0 + dabt.reg;
+    struct vgic_irq_rank *rank;
+    int offset = (int)(info->gpa - VGIC_DISTR_BASE_ADDRESS);
+    int gicd_reg = REG(offset);
+
+    switch ( gicd_reg )
+    {
+    case GICD_CTLR:
+        if ( dabt.size != 2 ) goto bad_width;
+        vgic_lock(v);
+        *r = v->domain->arch.vgic.ctlr;
+        vgic_unlock(v);
+        return 1;
+    case GICD_TYPER:
+        if ( dabt.size != 2 ) goto bad_width;
+        /* 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 );
+        vgic_unlock(v);
+        return 1;
+    case GICD_IIDR:
+        if ( dabt.size != 2 ) goto bad_width;
+        /*
+         * XXX Do we need a JEP106 manufacturer ID?
+         * Just use the physical h/w value for now
+         */
+        *r = 0x0000043b;
+        return 1;
+
+    /* Implementation defined -- read as zero */
+    case REG(0x020) ... REG(0x03c):
+        goto read_as_zero;
+
+    case GICD_IGROUPR ... GICD_IGROUPRN:
+        /* We do not implement security extensions for guests, read zero */
+        goto read_as_zero;
+
+    case GICD_ISENABLER ... GICD_ISENABLERN:
+        if ( dabt.size != 2 ) goto bad_width;
+        rank = vgic_irq_rank(v, 8, gicd_reg - GICD_ISENABLER);
+        if ( rank == NULL) goto read_as_zero;
+        vgic_lock_rank(v, rank);
+        *r = rank->ienable;
+        vgic_unlock_rank(v, rank);
+        return 1;
+
+    case GICD_ICENABLER ... GICD_ICENABLERN:
+        if ( dabt.size != 2 ) goto bad_width;
+        rank = vgic_irq_rank(v, 8, gicd_reg - GICD_ICENABLER);
+        if ( rank == NULL) goto read_as_zero;
+        vgic_lock_rank(v, rank);
+        *r = rank->ienable;
+        vgic_unlock_rank(v, rank);
+        return 1;
+
+    case GICD_ISPENDR ... GICD_ISPENDRN:
+        if ( dabt.size != 0 && dabt.size != 2 ) goto bad_width;
+        rank = vgic_irq_rank(v, 8, gicd_reg - GICD_ISPENDR);
+        if ( rank == NULL) goto read_as_zero;
+        vgic_lock_rank(v, rank);
+        *r = byte_read(rank->ipend, dabt.sign, offset);
+        vgic_unlock_rank(v, rank);
+        return 1;
+
+    case GICD_ICPENDR ... GICD_ICPENDRN:
+        if ( dabt.size != 0 && dabt.size != 2 ) goto bad_width;
+        rank = vgic_irq_rank(v, 8, gicd_reg - GICD_ICPENDR);
+        if ( rank == NULL) goto read_as_zero;
+        vgic_lock_rank(v, rank);
+        *r = byte_read(rank->ipend, dabt.sign, offset);
+        vgic_unlock_rank(v, rank);
+        return 1;
+
+    case GICD_ISACTIVER ... GICD_ISACTIVERN:
+        if ( dabt.size != 2 ) goto bad_width;
+        rank = vgic_irq_rank(v, 8, gicd_reg - GICD_ISACTIVER);
+        if ( rank == NULL) goto read_as_zero;
+        vgic_lock_rank(v, rank);
+        *r = rank->iactive;
+        vgic_unlock_rank(v, rank);
+        return 1;
+
+    case GICD_ICACTIVER ... GICD_ICACTIVERN:
+        if ( dabt.size != 2 ) goto bad_width;
+        rank = vgic_irq_rank(v, 8, gicd_reg - GICD_ICACTIVER);
+        if ( rank == NULL) goto read_as_zero;
+        vgic_lock_rank(v, rank);
+        *r = rank->iactive;
+        vgic_unlock_rank(v, rank);
+        return 1;
+
+    case GICD_ITARGETSR ... GICD_ITARGETSRN:
+        if ( dabt.size != 0 && dabt.size != 2 ) goto bad_width;
+        rank = vgic_irq_rank(v, 8, gicd_reg - GICD_ITARGETSR);
+        if ( rank == NULL) goto read_as_zero;
+
+        vgic_lock_rank(v, rank);
+        *r = rank->itargets[REG_RANK_INDEX(8, gicd_reg - GICD_ITARGETSR)];
+        if ( dabt.size == 0 )
+            *r = byte_read(*r, dabt.sign, offset);
+        vgic_unlock_rank(v, rank);
+        return 1;
+
+    case GICD_IPRIORITYR ... GICD_IPRIORITYRN:
+        if ( dabt.size != 0 && dabt.size != 2 ) goto bad_width;
+        rank = vgic_irq_rank(v, 8, gicd_reg - GICD_IPRIORITYR);
+        if ( rank == NULL) goto read_as_zero;
+
+        vgic_lock_rank(v, rank);
+        *r = rank->ipriority[REG_RANK_INDEX(8, gicd_reg - GICD_IPRIORITYR)];
+        if ( dabt.size == 0 )
+            *r = byte_read(*r, dabt.sign, offset);
+        vgic_unlock_rank(v, rank);
+        return 1;
+
+    case GICD_ICFGR ... GICD_ICFGRN:
+        if ( dabt.size != 2 ) goto bad_width;
+        rank = vgic_irq_rank(v, 2, gicd_reg - GICD_ICFGR);
+        if ( rank == NULL) goto read_as_zero;
+        vgic_lock_rank(v, rank);
+        *r = rank->icfg[REG_RANK_INDEX(2, gicd_reg - GICD_ICFGR)];
+        vgic_unlock_rank(v, rank);
+        return 0;
+
+    case GICD_NSACR ... GICD_NSACRN:
+        /* We do not implement securty extensions for guests, read zero */
+        goto read_as_zero;
+
+    case GICD_SGIR:
+        if ( dabt.size != 2 ) goto bad_width;
+        /* Write only -- read unknown */
+        *r = 0xdeadbeef;
+        return 1;
+
+    case GICD_CPENDSGIR ... GICD_CPENDSGIRN:
+        if ( dabt.size != 0 && dabt.size != 2 ) goto bad_width;
+        rank = vgic_irq_rank(v, 8, gicd_reg - GICD_CPENDSGIR);
+        if ( rank == NULL) goto read_as_zero;
+        vgic_lock_rank(v, rank);
+        *r = byte_read(rank->pendsgi, dabt.sign, offset);
+        vgic_unlock_rank(v, rank);
+        return 1;
+
+    case GICD_SPENDSGIR ... GICD_SPENDSGIRN:
+        if ( dabt.size != 0 && dabt.size != 2 ) goto bad_width;
+        rank = vgic_irq_rank(v, 8, gicd_reg - GICD_SPENDSGIR);
+        if ( rank == NULL) goto read_as_zero;
+        vgic_lock_rank(v, rank);
+        *r = byte_read(rank->pendsgi, dabt.sign, offset);
+        vgic_unlock_rank(v, rank);
+        return 1;
+
+    /* Implementation defined -- read as zero */
+    case REG(0xfd0) ... REG(0xfe4):
+        goto read_as_zero;
+
+    case GICD_ICPIDR2:
+        if ( dabt.size != 2 ) goto bad_width;
+        printk("vGICD: unhandled read from ICPIDR2\n");
+        return 0;
+
+    /* Implementation defined -- read as zero */
+    case REG(0xfec) ... REG(0xffc):
+        goto read_as_zero;
+
+    /* Reserved -- read as zero */
+    case REG(0x00c) ... REG(0x01c):
+    case REG(0x040) ... REG(0x07c):
+    case REG(0x7fc):
+    case REG(0xbfc):
+    case REG(0xf04) ... REG(0xf0c):
+    case REG(0xf30) ... REG(0xfcc):
+        goto read_as_zero;
+
+    default:
+        printk("vGICD: unhandled read r%d offset %#08x\n",
+               dabt.reg, offset);
+        return 0;
+    }
+
+bad_width:
+    printk("vGICD: bad read width %d r%d offset %#08x\n",
+           dabt.size, dabt.reg, offset);
+    domain_crash_synchronous();
+    return 0;
+
+read_as_zero:
+    if ( dabt.size != 2 ) goto bad_width;
+    *r = 0;
+    return 1;
+}
+
+static int vgic_distr_mmio_write(struct vcpu *v, mmio_info_t *info)
+{
+    struct hsr_dabt dabt = info->dabt;
+    struct cpu_user_regs *regs = guest_cpu_user_regs();
+    uint32_t *r = &regs->r0 + dabt.reg;
+    struct vgic_irq_rank *rank;
+    int offset = (int)(info->gpa - VGIC_DISTR_BASE_ADDRESS);
+    int gicd_reg = REG(offset);
+
+    switch ( gicd_reg )
+    {
+    case GICD_CTLR:
+        if ( dabt.size != 2 ) goto bad_width;
+        /* Ignore all but the enable bit */
+        v->domain->arch.vgic.ctlr = (*r) & GICD_CTL_ENABLE;
+        return 1;
+
+    /* R/O -- write ignored */
+    case GICD_TYPER:
+    case GICD_IIDR:
+        goto write_ignore;
+
+    /* Implementation defined -- write ignored */
+    case REG(0x020) ... REG(0x03c):
+        goto write_ignore;
+
+    case GICD_IGROUPR ... GICD_IGROUPRN:
+        /* We do not implement securty extensions for guests, write ignore */
+        goto write_ignore;
+
+    case GICD_ISENABLER ... GICD_ISENABLERN:
+        if ( dabt.size != 2 ) goto bad_width;
+        rank = vgic_irq_rank(v, 8, gicd_reg - GICD_ISENABLER);
+        if ( rank == NULL) goto write_ignore;
+        vgic_lock_rank(v, rank);
+        rank->ienable |= *r;
+        vgic_unlock_rank(v, rank);
+        return 1;
+
+    case GICD_ICENABLER ... GICD_ICENABLERN:
+        if ( dabt.size != 2 ) goto bad_width;
+        rank = vgic_irq_rank(v, 8, gicd_reg - GICD_ICENABLER);
+        if ( rank == NULL) goto write_ignore;
+        vgic_lock_rank(v, rank);
+        rank->ienable &= ~*r;
+        vgic_unlock_rank(v, rank);
+        return 1;
+
+    case GICD_ISPENDR ... GICD_ISPENDRN:
+        if ( dabt.size != 0 && dabt.size != 2 ) goto bad_width;
+        printk("vGICD: unhandled %s write %#"PRIx32" to ISPENDR%d\n",
+               dabt.size ? "word" : "byte", *r, gicd_reg - GICD_ISPENDR);
+        return 0;
+
+    case GICD_ICPENDR ... GICD_ICPENDRN:
+        if ( dabt.size != 0 && dabt.size != 2 ) goto bad_width;
+        printk("vGICD: unhandled %s write %#"PRIx32" to ICPENDR%d\n",
+               dabt.size ? "word" : "byte", *r, gicd_reg - GICD_ICPENDR);
+        return 0;
+
+    case GICD_ISACTIVER ... GICD_ISACTIVERN:
+        if ( dabt.size != 2 ) goto bad_width;
+        rank = vgic_irq_rank(v, 8, gicd_reg - GICD_ISACTIVER);
+        if ( rank == NULL) goto write_ignore;
+        vgic_lock_rank(v, rank);
+        rank->iactive &= ~*r;
+        vgic_unlock_rank(v, rank);
+        return 1;
+
+    case GICD_ICACTIVER ... GICD_ICACTIVERN:
+        if ( dabt.size != 2 ) goto bad_width;
+        rank = vgic_irq_rank(v, 8, gicd_reg - GICD_ICACTIVER);
+        if ( rank == NULL) goto write_ignore;
+        vgic_lock_rank(v, rank);
+        rank->iactive &= ~*r;
+        vgic_unlock_rank(v, rank);
+        return 1;
+
+    case GICD_ITARGETSR ... GICD_ITARGETSR + 7:
+        /* SGI/PPI target is read only */
+        goto write_ignore;
+
+    case GICD_ITARGETSR + 8 ... GICD_ITARGETSRN:
+        if ( dabt.size != 0 && dabt.size != 2 ) goto bad_width;
+        rank = vgic_irq_rank(v, 8, gicd_reg - GICD_ITARGETSR);
+        if ( rank == NULL) goto write_ignore;
+        vgic_lock_rank(v, rank);
+        if ( dabt.size == 2 )
+            rank->itargets[REG_RANK_INDEX(8, gicd_reg - GICD_ITARGETSR)] = *r;
+        else
+            byte_write(&rank->itargets[REG_RANK_INDEX(8, gicd_reg - GICD_ITARGETSR)],
+                       *r, offset);
+        vgic_unlock_rank(v, rank);
+        return 1;
+
+    case GICD_IPRIORITYR ... GICD_IPRIORITYRN:
+        if ( dabt.size != 0 && dabt.size != 2 ) goto bad_width;
+        rank = vgic_irq_rank(v, 8, gicd_reg - GICD_IPRIORITYR);
+        if ( rank == NULL) goto write_ignore;
+        vgic_lock_rank(v, rank);
+        if ( dabt.size == 2 )
+            rank->ipriority[REG_RANK_INDEX(8, gicd_reg - GICD_IPRIORITYR)] = *r;
+        else
+            byte_write(&rank->ipriority[REG_RANK_INDEX(8, gicd_reg - GICD_IPRIORITYR)],
+                       *r, offset);
+        vgic_unlock_rank(v, rank);
+        return 1;
+
+    case GICD_ICFGR: /* SGIs */
+        goto write_ignore;
+    case GICD_ICFGR + 1: /* PPIs */
+        /* It is implementation defined if these are writeable. We chose not */
+        goto write_ignore;
+    case GICD_ICFGR + 2 ... GICD_ICFGRN: /* SPIs */
+        if ( dabt.size != 2 ) goto bad_width;
+        rank = vgic_irq_rank(v, 2, gicd_reg - GICD_ICFGR);
+        vgic_lock_rank(v, rank);
+        if ( rank == NULL) goto write_ignore;
+        rank->icfg[REG_RANK_INDEX(2, gicd_reg - GICD_ICFGR)] = *r;
+        vgic_unlock_rank(v, rank);
+        return 1;
+
+    case GICD_NSACR ... GICD_NSACRN:
+        /* We do not implement securty extensions for guests, write ignore */
+        goto write_ignore;
+
+    case GICD_SGIR:
+        if ( dabt.size != 2 ) goto bad_width;
+        printk("vGICD: unhandled write %#"PRIx32" to ICFGR%d\n",
+               *r, gicd_reg - GICD_ICFGR);
+        return 0;
+
+    case GICD_CPENDSGIR ... GICD_CPENDSGIRN:
+        if ( dabt.size != 0 && dabt.size != 2 ) goto bad_width;
+        printk("vGICD: unhandled %s write %#"PRIx32" to ICPENDSGIR%d\n",
+               dabt.size ? "word" : "byte", *r, gicd_reg - GICD_CPENDSGIR);
+        return 0;
+
+    case GICD_SPENDSGIR ... GICD_SPENDSGIRN:
+        if ( dabt.size != 0 && dabt.size != 2 ) goto bad_width;
+        printk("vGICD: unhandled %s write %#"PRIx32" to ISPENDSGIR%d\n",
+               dabt.size ? "word" : "byte", *r, gicd_reg - GICD_SPENDSGIR);
+        return 0;
+
+    /* Implementation defined -- write ignored */
+    case REG(0xfd0) ... REG(0xfe4):
+        goto write_ignore;
+
+    /* R/O -- write ignore */
+    case GICD_ICPIDR2:
+        goto write_ignore;
+
+    /* Implementation defined -- write ignored */
+    case REG(0xfec) ... REG(0xffc):
+        goto write_ignore;
+
+    /* Reserved -- write ignored */
+    case REG(0x00c) ... REG(0x01c):
+    case REG(0x040) ... REG(0x07c):
+    case REG(0x7fc):
+    case REG(0xbfc):
+    case REG(0xf04) ... REG(0xf0c):
+    case REG(0xf30) ... REG(0xfcc):
+        goto write_ignore;
+
+    default:
+        printk("vGICD: unhandled write r%d=%"PRIx32" offset %#08x\n",
+               dabt.reg, *r, offset);
+        return 0;
+    }
+
+bad_width:
+    printk("vGICD: bad write width %d r%d=%"PRIx32" offset %#08x\n",
+           dabt.size, dabt.reg, *r, offset);
+    domain_crash_synchronous();
+    return 0;
+
+write_ignore:
+    if ( dabt.size != 2 ) goto bad_width;
+    return 0;
+}
+
+static int vgic_distr_mmio_check(struct vcpu *v, paddr_t addr)
+{
+    return addr >= VGIC_DISTR_BASE_ADDRESS && addr < (VGIC_DISTR_BASE_ADDRESS+PAGE_SIZE);
+}
+
+const struct mmio_handler vgic_distr_mmio_handler = {
+    .check_handler = vgic_distr_mmio_check,
+    .read_handler  = vgic_distr_mmio_read,
+    .write_handler = vgic_distr_mmio_write,
+};
+
+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
+     * are used for SPIs; the rests are used for per cpu irqs */
+    if ( irq < 32 )
+        n = &v->domain->arch.vgic.pending_irqs[irq + (v->vcpu_id * 32)
+            + v->domain->arch.vgic.nr_lines];
+    else
+        n = &v->domain->arch.vgic.pending_irqs[irq - 32];
+    return n;
+}
+
+void vgic_vcpu_inject_irq(struct vcpu *v, unsigned int irq, int virtual)
+{
+    int idx = irq >> 2, byte = irq & 0x3;
+    uint8_t priority;
+    struct vgic_irq_rank *rank = vgic_irq_rank(v, 8, idx);
+    struct pending_irq *iter, *n = irq_to_pending(v, irq);
+
+    /* irq still pending */
+    if (!list_empty(&n->link))
+        return;
+
+    priority = byte_read(rank->ipriority[REG_RANK_INDEX(8, idx)], 0, byte);
+
+    n->irq = irq;
+    n->priority = priority;
+    if (!virtual)
+        n->desc = irq_to_desc(irq);
+    else
+        n->desc = NULL;
+
+    gic_set_guest_irq(irq, GICH_LR_PENDING, priority);
+
+    spin_lock(&v->arch.vgic.lock);
+    list_for_each_entry ( iter, &v->arch.vgic.inflight_irqs, link )
+    {
+        if ( iter->priority < priority )
+        {
+            list_add_tail(&n->link, &iter->link);
+            spin_unlock(&v->arch.vgic.lock);
+            return;
+        }
+    }
+    list_add(&n->link, &v->arch.vgic.inflight_irqs);
+    spin_unlock(&v->arch.vgic.lock);
+    /* we have a new higher priority irq, inject it into the guest */
+    cpu_raise_softirq(v->processor, VGIC_SOFTIRQ);
+}
+
+static void vgic_softirq(void)
+{
+    if (list_empty(&current->arch.vgic.inflight_irqs))
+        return;
+
+    gic_inject_irq_start();
+}
+
+static int __init init_vgic_softirq(void)
+{
+    open_softirq(VGIC_SOFTIRQ, vgic_softirq);
+    return 0;
+}
+__initcall(init_vgic_softirq);
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
+
diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
index 2226a24..2cd0bd3 100644
--- a/xen/include/asm-arm/domain.h
+++ b/xen/include/asm-arm/domain.h
@@ -6,6 +6,15 @@
 #include <asm/page.h>
 #include <asm/p2m.h>
 
+/* Represents state corresponding to a block of 32 interrupts */
+struct vgic_irq_rank {
+    spinlock_t lock; /* Covers access to all other members of this struct */
+    uint32_t ienable, iactive, ipend, pendsgi;
+    uint32_t icfg[2];
+    uint32_t ipriority[8];
+    uint32_t itargets[8];
+};
+
 struct pending_irq
 {
     int irq;
@@ -18,6 +27,22 @@ struct arch_domain
 {
     struct p2m_domain p2m;
 
+    struct {
+        /*
+         * Covers access to other members of this struct _except_ for
+         * shared_irqs where each member contains its own locking.
+         *
+         * If both class of lock is required then this lock must be
+         * taken first. If multiple rank locks are required (including
+         * the per-vcpu private_irqs rank) then they must be taken in
+         * rank order.
+         */
+        spinlock_t lock;
+        int ctlr;
+        int nr_lines;
+        struct vgic_irq_rank *shared_irqs;
+        struct pending_irq *pending_irqs;
+    } vgic;
 }  __cacheline_aligned;
 
 struct arch_vcpu
@@ -27,6 +52,11 @@ struct arch_vcpu
     uint32_t sctlr;
     uint32_t ttbr0, ttbr1, ttbcr;
 
+    struct {
+        struct vgic_irq_rank private_irqs;
+        struct list_head inflight_irqs;
+        spinlock_t lock;
+    } vgic;
 }  __cacheline_aligned;
 
 void vcpu_show_execution_state(struct vcpu *);
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 13:14:47 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 13:14:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZ0Hb-0002hi-V4; Fri, 09 Dec 2011 13:14:35 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RZ0HZ-0002Xu-8h
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 13:14:33 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1323436420!6775414!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDQ0MTg=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8974 invoked from network); 9 Dec 2011 13:13:42 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 13:13:42 -0000
X-IronPort-AV: E=Sophos;i="4.71,325,1320642000"; d="scan'208";a="19808911"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 08:13:42 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 08:13:41 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pB9DCpE9008248;
	Fri, 9 Dec 2011 05:13:30 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 9 Dec 2011 13:13:26 +0000
Message-ID: <1323436408-16335-23-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1112091208420.3517@kaball-desktop>
References: <alpine.DEB.2.00.1112091208420.3517@kaball-desktop>
MIME-Version: 1.0
Cc: keir.xen@gmail.com, Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, JBeulich@suse.com,
	Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v2 23/25] arm: vgic emulation
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

- emulation of the GICD interface for the guest;

- interrupt injection into the guest;

- keep track of inflight irqs using a list, ordered by priority.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
---
 xen/arch/arm/domain.c        |    6 +
 xen/arch/arm/gic.h           |    3 +
 xen/arch/arm/io.c            |    1 +
 xen/arch/arm/io.h            |    2 +
 xen/arch/arm/irq.c           |    3 +-
 xen/arch/arm/vgic.c          |  605 ++++++++++++++++++++++++++++++++++++++++++
 xen/include/asm-arm/domain.h |   30 ++
 7 files changed, 649 insertions(+), 1 deletions(-)
 create mode 100644 xen/arch/arm/vgic.c

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 0844b37..7e681ab 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -212,6 +212,9 @@ int vcpu_initialise(struct vcpu *v)
 {
     int rc = 0;
 
+    if ( (rc = vcpu_vgic_init(v)) != 0 )
+        return rc;
+
     return rc;
 }
 
@@ -230,6 +233,9 @@ int arch_domain_create(struct domain *d, unsigned int domcr_flags)
 
     d->max_vcpus = 8;
 
+    if ( (rc = domain_vgic_init(d)) != 0 )
+        goto fail;
+
     rc = 0;
 fail:
     return rc;
diff --git a/xen/arch/arm/gic.h b/xen/arch/arm/gic.h
index 63b6648..81c388d 100644
--- a/xen/arch/arm/gic.h
+++ b/xen/arch/arm/gic.h
@@ -121,6 +121,9 @@
 #define GICH_LR_CPUID_SHIFT     9
 #define GICH_VTR_NRLRGS         0x3f
 
+extern int domain_vgic_init(struct domain *d);
+extern int vcpu_vgic_init(struct vcpu *v);
+extern void vgic_vcpu_inject_irq(struct vcpu *v, unsigned int irq,int virtual);
 extern struct pending_irq *irq_to_pending(struct vcpu *v, unsigned int irq);
 
 extern void gic_route_irqs(void);
diff --git a/xen/arch/arm/io.c b/xen/arch/arm/io.c
index 8789705..4461225 100644
--- a/xen/arch/arm/io.c
+++ b/xen/arch/arm/io.c
@@ -24,6 +24,7 @@
 
 static const struct mmio_handler *const mmio_handlers[] =
 {
+    &vgic_distr_mmio_handler,
 };
 #define MMIO_HANDLER_NR ARRAY_SIZE(mmio_handlers)
 
diff --git a/xen/arch/arm/io.h b/xen/arch/arm/io.h
index d7847e3..8cc5ca7 100644
--- a/xen/arch/arm/io.h
+++ b/xen/arch/arm/io.h
@@ -39,6 +39,8 @@ struct mmio_handler {
     mmio_write_t write_handler;
 };
 
+extern const struct mmio_handler vgic_distr_mmio_handler;
+
 extern int handle_mmio(mmio_info_t *info);
 
 #endif
diff --git a/xen/arch/arm/irq.c b/xen/arch/arm/irq.c
index 5663762..7820310 100644
--- a/xen/arch/arm/irq.c
+++ b/xen/arch/arm/irq.c
@@ -136,7 +136,8 @@ void do_IRQ(struct cpu_user_regs *regs, unsigned int irq, int is_fiq)
 
         desc->status |= IRQ_INPROGRESS;
 
-        /* XXX: inject irq into the guest */
+        /* XXX: inject irq into all guest vcpus */
+        vgic_vcpu_inject_irq(d->vcpu[0], irq, 0);
         goto out_no_end;
     }
 
diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
new file mode 100644
index 0000000..26eae55
--- /dev/null
+++ b/xen/arch/arm/vgic.c
@@ -0,0 +1,605 @@
+/*
+ * xen/arch/arm/vgic.c
+ *
+ * ARM Virtual Generic Interrupt Controller support
+ *
+ * Ian Campbell <ian.campbell@citrix.com>
+ * Copyright (c) 2011 Citrix Systems.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include <xen/config.h>
+#include <xen/lib.h>
+#include <xen/init.h>
+#include <xen/softirq.h>
+#include <xen/irq.h>
+#include <xen/sched.h>
+
+#include <asm/current.h>
+
+#include "io.h"
+#include "gic.h"
+
+#define VGIC_DISTR_BASE_ADDRESS 0x000000002c001000
+
+#define REG(n) (n/4)
+
+/* Number of ranks of interrupt registers for a domain */
+#define DOMAIN_NR_RANKS(d) (((d)->arch.vgic.nr_lines+31)/32)
+
+/*
+ * Rank containing GICD_<FOO><n> for GICD_<FOO> with
+ * <b>-bits-per-interrupt
+ */
+static inline int REG_RANK_NR(int b, uint32_t n)
+{
+    switch ( b )
+    {
+    case 8: return n >> 3;
+    case 4: return n >> 2;
+    case 2: return n >> 1;
+    default: BUG();
+    }
+}
+
+/*
+ * Offset of GICD_<FOO><n> with its rank, for GICD_<FOO> with
+ * <b>-bits-per-interrupt.
+ */
+#define REG_RANK_INDEX(b, n) ((n) & ((b)-1))
+
+/*
+ * Returns rank corresponding to a GICD_<FOO><n> register for
+ * GICD_<FOO> with <b>-bits-per-interrupt.
+ */
+static struct vgic_irq_rank *vgic_irq_rank(struct vcpu *v, int b, int n)
+{
+    int rank = REG_RANK_NR(b, n);
+
+    if ( rank == 0 )
+        return &v->arch.vgic.private_irqs;
+    else if ( rank <= DOMAIN_NR_RANKS(v->domain) )
+        return &v->domain->arch.vgic.shared_irqs[rank - 1];
+    else
+        return NULL;
+}
+
+int domain_vgic_init(struct domain *d)
+{
+    int i;
+
+    d->arch.vgic.ctlr = 0;
+    d->arch.vgic.nr_lines = 32;
+    d->arch.vgic.shared_irqs =
+        xmalloc_array(struct vgic_irq_rank, DOMAIN_NR_RANKS(d));
+    d->arch.vgic.pending_irqs =
+        xmalloc_array(struct pending_irq,
+                d->arch.vgic.nr_lines + (32 * d->max_vcpus));
+    for (i=0; i<d->arch.vgic.nr_lines + (32 * d->max_vcpus); i++)
+        INIT_LIST_HEAD(&d->arch.vgic.pending_irqs[i].link);
+    for (i=0; i<DOMAIN_NR_RANKS(d); i++)
+        spin_lock_init(&d->arch.vgic.shared_irqs[i].lock);
+    return 0;
+}
+
+int vcpu_vgic_init(struct vcpu *v)
+{
+    int i;
+    memset(&v->arch.vgic.private_irqs, 0, sizeof(v->arch.vgic.private_irqs));
+
+    spin_lock_init(&v->arch.vgic.private_irqs.lock);
+
+    /* For SGI and PPI the target is always this CPU */
+    for ( i = 0 ; i < 8 ; i++ )
+        v->arch.vgic.private_irqs.itargets[i] =
+              (1<<(v->vcpu_id+0))
+            | (1<<(v->vcpu_id+8))
+            | (1<<(v->vcpu_id+16))
+            | (1<<(v->vcpu_id+24));
+    INIT_LIST_HEAD(&v->arch.vgic.inflight_irqs);
+    spin_lock_init(&v->arch.vgic.lock);
+
+    return 0;
+}
+
+#define vgic_lock(v)   spin_lock(&(v)->domain->arch.vgic.lock)
+#define vgic_unlock(v) spin_unlock(&(v)->domain->arch.vgic.lock)
+
+#define vgic_lock_rank(v, r) spin_lock(&(r)->lock)
+#define vgic_unlock_rank(v, r) spin_unlock(&(r)->lock)
+
+static uint32_t byte_read(uint32_t val, int sign, int offset)
+{
+    int byte = offset & 0x3;
+
+    val = val >> (8*byte);
+    if ( sign && (val & 0x80) )
+        val |= 0xffffff00;
+    else
+        val &= 0x000000ff;
+    return val;
+}
+
+static void byte_write(uint32_t *reg, uint32_t var, int offset)
+{
+    int byte = offset & 0x3;
+
+    var &= (0xff << (8*byte));
+
+    *reg &= ~(0xff << (8*byte));
+    *reg |= var;
+}
+
+static int vgic_distr_mmio_read(struct vcpu *v, mmio_info_t *info)
+{
+    struct hsr_dabt dabt = info->dabt;
+    struct cpu_user_regs *regs = guest_cpu_user_regs();
+    uint32_t *r = &regs->r0 + dabt.reg;
+    struct vgic_irq_rank *rank;
+    int offset = (int)(info->gpa - VGIC_DISTR_BASE_ADDRESS);
+    int gicd_reg = REG(offset);
+
+    switch ( gicd_reg )
+    {
+    case GICD_CTLR:
+        if ( dabt.size != 2 ) goto bad_width;
+        vgic_lock(v);
+        *r = v->domain->arch.vgic.ctlr;
+        vgic_unlock(v);
+        return 1;
+    case GICD_TYPER:
+        if ( dabt.size != 2 ) goto bad_width;
+        /* 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 );
+        vgic_unlock(v);
+        return 1;
+    case GICD_IIDR:
+        if ( dabt.size != 2 ) goto bad_width;
+        /*
+         * XXX Do we need a JEP106 manufacturer ID?
+         * Just use the physical h/w value for now
+         */
+        *r = 0x0000043b;
+        return 1;
+
+    /* Implementation defined -- read as zero */
+    case REG(0x020) ... REG(0x03c):
+        goto read_as_zero;
+
+    case GICD_IGROUPR ... GICD_IGROUPRN:
+        /* We do not implement security extensions for guests, read zero */
+        goto read_as_zero;
+
+    case GICD_ISENABLER ... GICD_ISENABLERN:
+        if ( dabt.size != 2 ) goto bad_width;
+        rank = vgic_irq_rank(v, 8, gicd_reg - GICD_ISENABLER);
+        if ( rank == NULL) goto read_as_zero;
+        vgic_lock_rank(v, rank);
+        *r = rank->ienable;
+        vgic_unlock_rank(v, rank);
+        return 1;
+
+    case GICD_ICENABLER ... GICD_ICENABLERN:
+        if ( dabt.size != 2 ) goto bad_width;
+        rank = vgic_irq_rank(v, 8, gicd_reg - GICD_ICENABLER);
+        if ( rank == NULL) goto read_as_zero;
+        vgic_lock_rank(v, rank);
+        *r = rank->ienable;
+        vgic_unlock_rank(v, rank);
+        return 1;
+
+    case GICD_ISPENDR ... GICD_ISPENDRN:
+        if ( dabt.size != 0 && dabt.size != 2 ) goto bad_width;
+        rank = vgic_irq_rank(v, 8, gicd_reg - GICD_ISPENDR);
+        if ( rank == NULL) goto read_as_zero;
+        vgic_lock_rank(v, rank);
+        *r = byte_read(rank->ipend, dabt.sign, offset);
+        vgic_unlock_rank(v, rank);
+        return 1;
+
+    case GICD_ICPENDR ... GICD_ICPENDRN:
+        if ( dabt.size != 0 && dabt.size != 2 ) goto bad_width;
+        rank = vgic_irq_rank(v, 8, gicd_reg - GICD_ICPENDR);
+        if ( rank == NULL) goto read_as_zero;
+        vgic_lock_rank(v, rank);
+        *r = byte_read(rank->ipend, dabt.sign, offset);
+        vgic_unlock_rank(v, rank);
+        return 1;
+
+    case GICD_ISACTIVER ... GICD_ISACTIVERN:
+        if ( dabt.size != 2 ) goto bad_width;
+        rank = vgic_irq_rank(v, 8, gicd_reg - GICD_ISACTIVER);
+        if ( rank == NULL) goto read_as_zero;
+        vgic_lock_rank(v, rank);
+        *r = rank->iactive;
+        vgic_unlock_rank(v, rank);
+        return 1;
+
+    case GICD_ICACTIVER ... GICD_ICACTIVERN:
+        if ( dabt.size != 2 ) goto bad_width;
+        rank = vgic_irq_rank(v, 8, gicd_reg - GICD_ICACTIVER);
+        if ( rank == NULL) goto read_as_zero;
+        vgic_lock_rank(v, rank);
+        *r = rank->iactive;
+        vgic_unlock_rank(v, rank);
+        return 1;
+
+    case GICD_ITARGETSR ... GICD_ITARGETSRN:
+        if ( dabt.size != 0 && dabt.size != 2 ) goto bad_width;
+        rank = vgic_irq_rank(v, 8, gicd_reg - GICD_ITARGETSR);
+        if ( rank == NULL) goto read_as_zero;
+
+        vgic_lock_rank(v, rank);
+        *r = rank->itargets[REG_RANK_INDEX(8, gicd_reg - GICD_ITARGETSR)];
+        if ( dabt.size == 0 )
+            *r = byte_read(*r, dabt.sign, offset);
+        vgic_unlock_rank(v, rank);
+        return 1;
+
+    case GICD_IPRIORITYR ... GICD_IPRIORITYRN:
+        if ( dabt.size != 0 && dabt.size != 2 ) goto bad_width;
+        rank = vgic_irq_rank(v, 8, gicd_reg - GICD_IPRIORITYR);
+        if ( rank == NULL) goto read_as_zero;
+
+        vgic_lock_rank(v, rank);
+        *r = rank->ipriority[REG_RANK_INDEX(8, gicd_reg - GICD_IPRIORITYR)];
+        if ( dabt.size == 0 )
+            *r = byte_read(*r, dabt.sign, offset);
+        vgic_unlock_rank(v, rank);
+        return 1;
+
+    case GICD_ICFGR ... GICD_ICFGRN:
+        if ( dabt.size != 2 ) goto bad_width;
+        rank = vgic_irq_rank(v, 2, gicd_reg - GICD_ICFGR);
+        if ( rank == NULL) goto read_as_zero;
+        vgic_lock_rank(v, rank);
+        *r = rank->icfg[REG_RANK_INDEX(2, gicd_reg - GICD_ICFGR)];
+        vgic_unlock_rank(v, rank);
+        return 0;
+
+    case GICD_NSACR ... GICD_NSACRN:
+        /* We do not implement securty extensions for guests, read zero */
+        goto read_as_zero;
+
+    case GICD_SGIR:
+        if ( dabt.size != 2 ) goto bad_width;
+        /* Write only -- read unknown */
+        *r = 0xdeadbeef;
+        return 1;
+
+    case GICD_CPENDSGIR ... GICD_CPENDSGIRN:
+        if ( dabt.size != 0 && dabt.size != 2 ) goto bad_width;
+        rank = vgic_irq_rank(v, 8, gicd_reg - GICD_CPENDSGIR);
+        if ( rank == NULL) goto read_as_zero;
+        vgic_lock_rank(v, rank);
+        *r = byte_read(rank->pendsgi, dabt.sign, offset);
+        vgic_unlock_rank(v, rank);
+        return 1;
+
+    case GICD_SPENDSGIR ... GICD_SPENDSGIRN:
+        if ( dabt.size != 0 && dabt.size != 2 ) goto bad_width;
+        rank = vgic_irq_rank(v, 8, gicd_reg - GICD_SPENDSGIR);
+        if ( rank == NULL) goto read_as_zero;
+        vgic_lock_rank(v, rank);
+        *r = byte_read(rank->pendsgi, dabt.sign, offset);
+        vgic_unlock_rank(v, rank);
+        return 1;
+
+    /* Implementation defined -- read as zero */
+    case REG(0xfd0) ... REG(0xfe4):
+        goto read_as_zero;
+
+    case GICD_ICPIDR2:
+        if ( dabt.size != 2 ) goto bad_width;
+        printk("vGICD: unhandled read from ICPIDR2\n");
+        return 0;
+
+    /* Implementation defined -- read as zero */
+    case REG(0xfec) ... REG(0xffc):
+        goto read_as_zero;
+
+    /* Reserved -- read as zero */
+    case REG(0x00c) ... REG(0x01c):
+    case REG(0x040) ... REG(0x07c):
+    case REG(0x7fc):
+    case REG(0xbfc):
+    case REG(0xf04) ... REG(0xf0c):
+    case REG(0xf30) ... REG(0xfcc):
+        goto read_as_zero;
+
+    default:
+        printk("vGICD: unhandled read r%d offset %#08x\n",
+               dabt.reg, offset);
+        return 0;
+    }
+
+bad_width:
+    printk("vGICD: bad read width %d r%d offset %#08x\n",
+           dabt.size, dabt.reg, offset);
+    domain_crash_synchronous();
+    return 0;
+
+read_as_zero:
+    if ( dabt.size != 2 ) goto bad_width;
+    *r = 0;
+    return 1;
+}
+
+static int vgic_distr_mmio_write(struct vcpu *v, mmio_info_t *info)
+{
+    struct hsr_dabt dabt = info->dabt;
+    struct cpu_user_regs *regs = guest_cpu_user_regs();
+    uint32_t *r = &regs->r0 + dabt.reg;
+    struct vgic_irq_rank *rank;
+    int offset = (int)(info->gpa - VGIC_DISTR_BASE_ADDRESS);
+    int gicd_reg = REG(offset);
+
+    switch ( gicd_reg )
+    {
+    case GICD_CTLR:
+        if ( dabt.size != 2 ) goto bad_width;
+        /* Ignore all but the enable bit */
+        v->domain->arch.vgic.ctlr = (*r) & GICD_CTL_ENABLE;
+        return 1;
+
+    /* R/O -- write ignored */
+    case GICD_TYPER:
+    case GICD_IIDR:
+        goto write_ignore;
+
+    /* Implementation defined -- write ignored */
+    case REG(0x020) ... REG(0x03c):
+        goto write_ignore;
+
+    case GICD_IGROUPR ... GICD_IGROUPRN:
+        /* We do not implement securty extensions for guests, write ignore */
+        goto write_ignore;
+
+    case GICD_ISENABLER ... GICD_ISENABLERN:
+        if ( dabt.size != 2 ) goto bad_width;
+        rank = vgic_irq_rank(v, 8, gicd_reg - GICD_ISENABLER);
+        if ( rank == NULL) goto write_ignore;
+        vgic_lock_rank(v, rank);
+        rank->ienable |= *r;
+        vgic_unlock_rank(v, rank);
+        return 1;
+
+    case GICD_ICENABLER ... GICD_ICENABLERN:
+        if ( dabt.size != 2 ) goto bad_width;
+        rank = vgic_irq_rank(v, 8, gicd_reg - GICD_ICENABLER);
+        if ( rank == NULL) goto write_ignore;
+        vgic_lock_rank(v, rank);
+        rank->ienable &= ~*r;
+        vgic_unlock_rank(v, rank);
+        return 1;
+
+    case GICD_ISPENDR ... GICD_ISPENDRN:
+        if ( dabt.size != 0 && dabt.size != 2 ) goto bad_width;
+        printk("vGICD: unhandled %s write %#"PRIx32" to ISPENDR%d\n",
+               dabt.size ? "word" : "byte", *r, gicd_reg - GICD_ISPENDR);
+        return 0;
+
+    case GICD_ICPENDR ... GICD_ICPENDRN:
+        if ( dabt.size != 0 && dabt.size != 2 ) goto bad_width;
+        printk("vGICD: unhandled %s write %#"PRIx32" to ICPENDR%d\n",
+               dabt.size ? "word" : "byte", *r, gicd_reg - GICD_ICPENDR);
+        return 0;
+
+    case GICD_ISACTIVER ... GICD_ISACTIVERN:
+        if ( dabt.size != 2 ) goto bad_width;
+        rank = vgic_irq_rank(v, 8, gicd_reg - GICD_ISACTIVER);
+        if ( rank == NULL) goto write_ignore;
+        vgic_lock_rank(v, rank);
+        rank->iactive &= ~*r;
+        vgic_unlock_rank(v, rank);
+        return 1;
+
+    case GICD_ICACTIVER ... GICD_ICACTIVERN:
+        if ( dabt.size != 2 ) goto bad_width;
+        rank = vgic_irq_rank(v, 8, gicd_reg - GICD_ICACTIVER);
+        if ( rank == NULL) goto write_ignore;
+        vgic_lock_rank(v, rank);
+        rank->iactive &= ~*r;
+        vgic_unlock_rank(v, rank);
+        return 1;
+
+    case GICD_ITARGETSR ... GICD_ITARGETSR + 7:
+        /* SGI/PPI target is read only */
+        goto write_ignore;
+
+    case GICD_ITARGETSR + 8 ... GICD_ITARGETSRN:
+        if ( dabt.size != 0 && dabt.size != 2 ) goto bad_width;
+        rank = vgic_irq_rank(v, 8, gicd_reg - GICD_ITARGETSR);
+        if ( rank == NULL) goto write_ignore;
+        vgic_lock_rank(v, rank);
+        if ( dabt.size == 2 )
+            rank->itargets[REG_RANK_INDEX(8, gicd_reg - GICD_ITARGETSR)] = *r;
+        else
+            byte_write(&rank->itargets[REG_RANK_INDEX(8, gicd_reg - GICD_ITARGETSR)],
+                       *r, offset);
+        vgic_unlock_rank(v, rank);
+        return 1;
+
+    case GICD_IPRIORITYR ... GICD_IPRIORITYRN:
+        if ( dabt.size != 0 && dabt.size != 2 ) goto bad_width;
+        rank = vgic_irq_rank(v, 8, gicd_reg - GICD_IPRIORITYR);
+        if ( rank == NULL) goto write_ignore;
+        vgic_lock_rank(v, rank);
+        if ( dabt.size == 2 )
+            rank->ipriority[REG_RANK_INDEX(8, gicd_reg - GICD_IPRIORITYR)] = *r;
+        else
+            byte_write(&rank->ipriority[REG_RANK_INDEX(8, gicd_reg - GICD_IPRIORITYR)],
+                       *r, offset);
+        vgic_unlock_rank(v, rank);
+        return 1;
+
+    case GICD_ICFGR: /* SGIs */
+        goto write_ignore;
+    case GICD_ICFGR + 1: /* PPIs */
+        /* It is implementation defined if these are writeable. We chose not */
+        goto write_ignore;
+    case GICD_ICFGR + 2 ... GICD_ICFGRN: /* SPIs */
+        if ( dabt.size != 2 ) goto bad_width;
+        rank = vgic_irq_rank(v, 2, gicd_reg - GICD_ICFGR);
+        vgic_lock_rank(v, rank);
+        if ( rank == NULL) goto write_ignore;
+        rank->icfg[REG_RANK_INDEX(2, gicd_reg - GICD_ICFGR)] = *r;
+        vgic_unlock_rank(v, rank);
+        return 1;
+
+    case GICD_NSACR ... GICD_NSACRN:
+        /* We do not implement securty extensions for guests, write ignore */
+        goto write_ignore;
+
+    case GICD_SGIR:
+        if ( dabt.size != 2 ) goto bad_width;
+        printk("vGICD: unhandled write %#"PRIx32" to ICFGR%d\n",
+               *r, gicd_reg - GICD_ICFGR);
+        return 0;
+
+    case GICD_CPENDSGIR ... GICD_CPENDSGIRN:
+        if ( dabt.size != 0 && dabt.size != 2 ) goto bad_width;
+        printk("vGICD: unhandled %s write %#"PRIx32" to ICPENDSGIR%d\n",
+               dabt.size ? "word" : "byte", *r, gicd_reg - GICD_CPENDSGIR);
+        return 0;
+
+    case GICD_SPENDSGIR ... GICD_SPENDSGIRN:
+        if ( dabt.size != 0 && dabt.size != 2 ) goto bad_width;
+        printk("vGICD: unhandled %s write %#"PRIx32" to ISPENDSGIR%d\n",
+               dabt.size ? "word" : "byte", *r, gicd_reg - GICD_SPENDSGIR);
+        return 0;
+
+    /* Implementation defined -- write ignored */
+    case REG(0xfd0) ... REG(0xfe4):
+        goto write_ignore;
+
+    /* R/O -- write ignore */
+    case GICD_ICPIDR2:
+        goto write_ignore;
+
+    /* Implementation defined -- write ignored */
+    case REG(0xfec) ... REG(0xffc):
+        goto write_ignore;
+
+    /* Reserved -- write ignored */
+    case REG(0x00c) ... REG(0x01c):
+    case REG(0x040) ... REG(0x07c):
+    case REG(0x7fc):
+    case REG(0xbfc):
+    case REG(0xf04) ... REG(0xf0c):
+    case REG(0xf30) ... REG(0xfcc):
+        goto write_ignore;
+
+    default:
+        printk("vGICD: unhandled write r%d=%"PRIx32" offset %#08x\n",
+               dabt.reg, *r, offset);
+        return 0;
+    }
+
+bad_width:
+    printk("vGICD: bad write width %d r%d=%"PRIx32" offset %#08x\n",
+           dabt.size, dabt.reg, *r, offset);
+    domain_crash_synchronous();
+    return 0;
+
+write_ignore:
+    if ( dabt.size != 2 ) goto bad_width;
+    return 0;
+}
+
+static int vgic_distr_mmio_check(struct vcpu *v, paddr_t addr)
+{
+    return addr >= VGIC_DISTR_BASE_ADDRESS && addr < (VGIC_DISTR_BASE_ADDRESS+PAGE_SIZE);
+}
+
+const struct mmio_handler vgic_distr_mmio_handler = {
+    .check_handler = vgic_distr_mmio_check,
+    .read_handler  = vgic_distr_mmio_read,
+    .write_handler = vgic_distr_mmio_write,
+};
+
+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
+     * are used for SPIs; the rests are used for per cpu irqs */
+    if ( irq < 32 )
+        n = &v->domain->arch.vgic.pending_irqs[irq + (v->vcpu_id * 32)
+            + v->domain->arch.vgic.nr_lines];
+    else
+        n = &v->domain->arch.vgic.pending_irqs[irq - 32];
+    return n;
+}
+
+void vgic_vcpu_inject_irq(struct vcpu *v, unsigned int irq, int virtual)
+{
+    int idx = irq >> 2, byte = irq & 0x3;
+    uint8_t priority;
+    struct vgic_irq_rank *rank = vgic_irq_rank(v, 8, idx);
+    struct pending_irq *iter, *n = irq_to_pending(v, irq);
+
+    /* irq still pending */
+    if (!list_empty(&n->link))
+        return;
+
+    priority = byte_read(rank->ipriority[REG_RANK_INDEX(8, idx)], 0, byte);
+
+    n->irq = irq;
+    n->priority = priority;
+    if (!virtual)
+        n->desc = irq_to_desc(irq);
+    else
+        n->desc = NULL;
+
+    gic_set_guest_irq(irq, GICH_LR_PENDING, priority);
+
+    spin_lock(&v->arch.vgic.lock);
+    list_for_each_entry ( iter, &v->arch.vgic.inflight_irqs, link )
+    {
+        if ( iter->priority < priority )
+        {
+            list_add_tail(&n->link, &iter->link);
+            spin_unlock(&v->arch.vgic.lock);
+            return;
+        }
+    }
+    list_add(&n->link, &v->arch.vgic.inflight_irqs);
+    spin_unlock(&v->arch.vgic.lock);
+    /* we have a new higher priority irq, inject it into the guest */
+    cpu_raise_softirq(v->processor, VGIC_SOFTIRQ);
+}
+
+static void vgic_softirq(void)
+{
+    if (list_empty(&current->arch.vgic.inflight_irqs))
+        return;
+
+    gic_inject_irq_start();
+}
+
+static int __init init_vgic_softirq(void)
+{
+    open_softirq(VGIC_SOFTIRQ, vgic_softirq);
+    return 0;
+}
+__initcall(init_vgic_softirq);
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
+
diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
index 2226a24..2cd0bd3 100644
--- a/xen/include/asm-arm/domain.h
+++ b/xen/include/asm-arm/domain.h
@@ -6,6 +6,15 @@
 #include <asm/page.h>
 #include <asm/p2m.h>
 
+/* Represents state corresponding to a block of 32 interrupts */
+struct vgic_irq_rank {
+    spinlock_t lock; /* Covers access to all other members of this struct */
+    uint32_t ienable, iactive, ipend, pendsgi;
+    uint32_t icfg[2];
+    uint32_t ipriority[8];
+    uint32_t itargets[8];
+};
+
 struct pending_irq
 {
     int irq;
@@ -18,6 +27,22 @@ struct arch_domain
 {
     struct p2m_domain p2m;
 
+    struct {
+        /*
+         * Covers access to other members of this struct _except_ for
+         * shared_irqs where each member contains its own locking.
+         *
+         * If both class of lock is required then this lock must be
+         * taken first. If multiple rank locks are required (including
+         * the per-vcpu private_irqs rank) then they must be taken in
+         * rank order.
+         */
+        spinlock_t lock;
+        int ctlr;
+        int nr_lines;
+        struct vgic_irq_rank *shared_irqs;
+        struct pending_irq *pending_irqs;
+    } vgic;
 }  __cacheline_aligned;
 
 struct arch_vcpu
@@ -27,6 +52,11 @@ struct arch_vcpu
     uint32_t sctlr;
     uint32_t ttbr0, ttbr1, ttbcr;
 
+    struct {
+        struct vgic_irq_rank private_irqs;
+        struct list_head inflight_irqs;
+        spinlock_t lock;
+    } vgic;
 }  __cacheline_aligned;
 
 void vcpu_show_execution_state(struct vcpu *);
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 13:14:48 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 13:14:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZ0Ha-0002fU-8L; Fri, 09 Dec 2011 13:14:34 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RZ0HY-0002X1-BH
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 13:14:32 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1323436420!6775414!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDQ0MTg=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8957 invoked from network); 9 Dec 2011 13:13:42 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 13:13:42 -0000
X-IronPort-AV: E=Sophos;i="4.71,325,1320642000"; d="scan'208";a="19808909"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 08:13:40 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 08:13:39 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pB9DCpE5008248;
	Fri, 9 Dec 2011 05:13:23 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 9 Dec 2011 13:13:22 +0000
Message-ID: <1323436408-16335-19-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1112091208420.3517@kaball-desktop>
References: <alpine.DEB.2.00.1112091208420.3517@kaball-desktop>
MIME-Version: 1.0
Cc: keir.xen@gmail.com, Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, JBeulich@suse.com,
	Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v2 19/25] arm: early setup code
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
---
 xen/arch/arm/setup.c |  206 ++++++++++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 206 insertions(+), 0 deletions(-)
 create mode 100644 xen/arch/arm/setup.c

diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
new file mode 100644
index 0000000..33c880e
--- /dev/null
+++ b/xen/arch/arm/setup.c
@@ -0,0 +1,206 @@
+/*
+ * xen/arch/arm/setup.c
+ *
+ * Early bringup code for an ARMv7-A with virt extensions.
+ *
+ * Tim Deegan <tim@xen.org>
+ * Copyright (c) 2011 Citrix Systems.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include <xen/config.h>
+#include <xen/compile.h>
+#include <xen/domain_page.h>
+#include <xen/types.h>
+#include <xen/string.h>
+#include <xen/serial.h>
+#include <xen/sched.h>
+#include <xen/console.h>
+#include <xen/init.h>
+#include <xen/irq.h>
+#include <xen/mm.h>
+#include <xen/softirq.h>
+#include <xen/keyhandler.h>
+#include <xen/cpu.h>
+#include <asm/page.h>
+#include <asm/current.h>
+#include <asm/setup.h>
+#include "gic.h"
+
+/* maxcpus: maximum number of CPUs to activate. */
+static unsigned int __initdata max_cpus = NR_CPUS;
+
+/* Xen stack for bringing up the first CPU. */
+unsigned char init_stack[STACK_SIZE] __attribute__((__aligned__(STACK_SIZE)));
+
+extern char __init_begin[], __init_end[], __bss_start[];
+
+static __attribute_used__ void init_done(void)
+{
+	/* TODO: free (or page-protect) the init areas.
+	   memset(__init_begin, 0xcc, __init_end - __init_begin);
+	   free_xen_data(__init_begin, __init_end);
+	*/
+    printk("Freed %ldkB init memory.\n", (long)(__init_end-__init_begin)>>10);
+
+    startup_cpu_idle_loop();
+}
+
+static void __init init_idle_domain(void)
+{
+        scheduler_init();
+        set_current(idle_vcpu[0]);
+        this_cpu(curr_vcpu) = current;
+        /* TODO: setup_idle_pagetable(); */
+}
+
+void __init start_xen(unsigned long boot_phys_offset,
+                      unsigned long arm_type,
+                      unsigned long atag_paddr)
+
+{
+    int i;
+
+    setup_pagetables(boot_phys_offset);
+
+#ifdef EARLY_UART_ADDRESS
+    /* Map the UART */
+    /* TODO Need to get device tree or command line for UART address */
+    set_fixmap(FIXMAP_CONSOLE, EARLY_UART_ADDRESS >> PAGE_SHIFT, DEV_SHARED);
+    pl011_init(0, FIXMAP_ADDR(FIXMAP_CONSOLE));
+    console_init_preirq();
+#endif
+
+    set_current((struct vcpu *)0xfffff000); /* debug sanity */
+    idle_vcpu[0] = current;
+    set_processor_id(0); /* needed early, for smp_processor_id() */
+
+    /* TODO: smp_prepare_boot_cpu(void) */
+    cpumask_set_cpu(smp_processor_id(), &cpu_online_map);
+    cpumask_set_cpu(smp_processor_id(), &cpu_present_map);
+
+    smp_prepare_cpus(max_cpus);
+
+    init_xen_time();
+
+    /* TODO: This needs some thought, as well as device-tree mapping.
+     * For testing, assume that the whole xenheap is contiguous in RAM */
+    setup_xenheap_mappings(0x8000000, 0x40000); /* 1 GB @ 512GB */
+    /* Must pass a single mapped page for populating bootmem_region_list. */
+    init_boot_pages(pfn_to_paddr(xenheap_mfn_start),
+                    pfn_to_paddr(xenheap_mfn_start+1));
+
+    /* Add non-xenheap memory */
+    init_boot_pages(0x8040000000, 0x80c0000000); /* 2 GB @513GB */
+
+    /* TODO Make sure Xen's own pages aren't added
+     *     -- the memory above doesn't include our relocation target.  */
+    /* TODO Handle payloads too */
+
+    /* TODO Need to find actual memory, for now use 4GB at 512GB */
+    setup_frametable_mappings(0x8000000000ULL, 0x8100000000UL);
+
+    /* Add xenheap memory */
+    init_xenheap_pages(pfn_to_paddr(xenheap_mfn_start+1),
+                       pfn_to_paddr(xenheap_mfn_end));
+
+    end_boot_allocator();
+
+    /* Setup Hyp vector base */
+    WRITE_CP32((uint32_t) hyp_traps_vector, HVBAR);
+    printk("Set hyp vector base to %"PRIx32" (expected %p)\n",
+           READ_CP32(HVBAR), hyp_traps_vector);
+
+    /* Setup Stage 2 address translation */
+    /* SH0=00, ORGN0=IRGN0=01
+     * SL0=01 (Level-1)
+     * T0SZ=(1)1000 = -8 (40 bit physical addresses)
+     */
+    WRITE_CP32(0x80002558, VTCR); isb();
+
+    softirq_init();
+    tasklet_subsys_init();
+
+    init_IRQ();
+
+    gic_init();
+
+    gic_route_irqs();
+
+    init_maintenance_interrupt();
+    init_timer_interrupt();
+
+    timer_init();
+
+    init_idle_domain();
+
+    rcu_init();
+
+    local_irq_enable();
+
+    initialize_keytable();
+
+    console_init_postirq();
+
+    do_presmp_initcalls();
+
+    for_each_present_cpu ( i )
+    {
+        if ( (num_online_cpus() < max_cpus) && !cpu_online(i) )
+        {
+            int ret = cpu_up(i);
+            if ( ret != 0 )
+                printk("Failed to bring up CPU %u (error %d)\n", i, ret);
+        }
+    }
+
+    printk("Brought up %ld CPUs\n", (long)num_online_cpus());
+    /* TODO: smp_cpus_done(); */
+
+    do_initcalls();
+
+    /* Create initial domain 0. */
+    dom0 = domain_create(0, 0, 0);
+    if ( dom0 == NULL )
+            printk("domain_create failed\n");
+    if ( (dom0 == NULL) || (alloc_dom0_vcpu0() == NULL) )
+            panic("Error creating domain 0\n");
+
+    dom0->is_privileged = 1;
+    dom0->target = NULL;
+
+    if ( construct_dom0(dom0) != 0)
+            panic("Could not set up DOM0 guest OS\n");
+
+    /* Scrub RAM that is still free and so may go to an unprivileged domain.
+       XXX too slow in simulator
+       scrub_heap_pages();
+    */
+
+    console_endboot();
+
+    /* Hide UART from DOM0 if we're using it */
+    serial_endboot();
+
+    domain_unpause_by_systemcontroller(dom0);
+
+    reset_stack_and_jump(init_done);
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 13:14:48 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 13:14:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZ0Ha-0002fU-8L; Fri, 09 Dec 2011 13:14:34 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RZ0HY-0002X1-BH
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 13:14:32 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1323436420!6775414!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDQ0MTg=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8957 invoked from network); 9 Dec 2011 13:13:42 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 13:13:42 -0000
X-IronPort-AV: E=Sophos;i="4.71,325,1320642000"; d="scan'208";a="19808909"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 08:13:40 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 08:13:39 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pB9DCpE5008248;
	Fri, 9 Dec 2011 05:13:23 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 9 Dec 2011 13:13:22 +0000
Message-ID: <1323436408-16335-19-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1112091208420.3517@kaball-desktop>
References: <alpine.DEB.2.00.1112091208420.3517@kaball-desktop>
MIME-Version: 1.0
Cc: keir.xen@gmail.com, Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, JBeulich@suse.com,
	Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v2 19/25] arm: early setup code
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
---
 xen/arch/arm/setup.c |  206 ++++++++++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 206 insertions(+), 0 deletions(-)
 create mode 100644 xen/arch/arm/setup.c

diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
new file mode 100644
index 0000000..33c880e
--- /dev/null
+++ b/xen/arch/arm/setup.c
@@ -0,0 +1,206 @@
+/*
+ * xen/arch/arm/setup.c
+ *
+ * Early bringup code for an ARMv7-A with virt extensions.
+ *
+ * Tim Deegan <tim@xen.org>
+ * Copyright (c) 2011 Citrix Systems.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include <xen/config.h>
+#include <xen/compile.h>
+#include <xen/domain_page.h>
+#include <xen/types.h>
+#include <xen/string.h>
+#include <xen/serial.h>
+#include <xen/sched.h>
+#include <xen/console.h>
+#include <xen/init.h>
+#include <xen/irq.h>
+#include <xen/mm.h>
+#include <xen/softirq.h>
+#include <xen/keyhandler.h>
+#include <xen/cpu.h>
+#include <asm/page.h>
+#include <asm/current.h>
+#include <asm/setup.h>
+#include "gic.h"
+
+/* maxcpus: maximum number of CPUs to activate. */
+static unsigned int __initdata max_cpus = NR_CPUS;
+
+/* Xen stack for bringing up the first CPU. */
+unsigned char init_stack[STACK_SIZE] __attribute__((__aligned__(STACK_SIZE)));
+
+extern char __init_begin[], __init_end[], __bss_start[];
+
+static __attribute_used__ void init_done(void)
+{
+	/* TODO: free (or page-protect) the init areas.
+	   memset(__init_begin, 0xcc, __init_end - __init_begin);
+	   free_xen_data(__init_begin, __init_end);
+	*/
+    printk("Freed %ldkB init memory.\n", (long)(__init_end-__init_begin)>>10);
+
+    startup_cpu_idle_loop();
+}
+
+static void __init init_idle_domain(void)
+{
+        scheduler_init();
+        set_current(idle_vcpu[0]);
+        this_cpu(curr_vcpu) = current;
+        /* TODO: setup_idle_pagetable(); */
+}
+
+void __init start_xen(unsigned long boot_phys_offset,
+                      unsigned long arm_type,
+                      unsigned long atag_paddr)
+
+{
+    int i;
+
+    setup_pagetables(boot_phys_offset);
+
+#ifdef EARLY_UART_ADDRESS
+    /* Map the UART */
+    /* TODO Need to get device tree or command line for UART address */
+    set_fixmap(FIXMAP_CONSOLE, EARLY_UART_ADDRESS >> PAGE_SHIFT, DEV_SHARED);
+    pl011_init(0, FIXMAP_ADDR(FIXMAP_CONSOLE));
+    console_init_preirq();
+#endif
+
+    set_current((struct vcpu *)0xfffff000); /* debug sanity */
+    idle_vcpu[0] = current;
+    set_processor_id(0); /* needed early, for smp_processor_id() */
+
+    /* TODO: smp_prepare_boot_cpu(void) */
+    cpumask_set_cpu(smp_processor_id(), &cpu_online_map);
+    cpumask_set_cpu(smp_processor_id(), &cpu_present_map);
+
+    smp_prepare_cpus(max_cpus);
+
+    init_xen_time();
+
+    /* TODO: This needs some thought, as well as device-tree mapping.
+     * For testing, assume that the whole xenheap is contiguous in RAM */
+    setup_xenheap_mappings(0x8000000, 0x40000); /* 1 GB @ 512GB */
+    /* Must pass a single mapped page for populating bootmem_region_list. */
+    init_boot_pages(pfn_to_paddr(xenheap_mfn_start),
+                    pfn_to_paddr(xenheap_mfn_start+1));
+
+    /* Add non-xenheap memory */
+    init_boot_pages(0x8040000000, 0x80c0000000); /* 2 GB @513GB */
+
+    /* TODO Make sure Xen's own pages aren't added
+     *     -- the memory above doesn't include our relocation target.  */
+    /* TODO Handle payloads too */
+
+    /* TODO Need to find actual memory, for now use 4GB at 512GB */
+    setup_frametable_mappings(0x8000000000ULL, 0x8100000000UL);
+
+    /* Add xenheap memory */
+    init_xenheap_pages(pfn_to_paddr(xenheap_mfn_start+1),
+                       pfn_to_paddr(xenheap_mfn_end));
+
+    end_boot_allocator();
+
+    /* Setup Hyp vector base */
+    WRITE_CP32((uint32_t) hyp_traps_vector, HVBAR);
+    printk("Set hyp vector base to %"PRIx32" (expected %p)\n",
+           READ_CP32(HVBAR), hyp_traps_vector);
+
+    /* Setup Stage 2 address translation */
+    /* SH0=00, ORGN0=IRGN0=01
+     * SL0=01 (Level-1)
+     * T0SZ=(1)1000 = -8 (40 bit physical addresses)
+     */
+    WRITE_CP32(0x80002558, VTCR); isb();
+
+    softirq_init();
+    tasklet_subsys_init();
+
+    init_IRQ();
+
+    gic_init();
+
+    gic_route_irqs();
+
+    init_maintenance_interrupt();
+    init_timer_interrupt();
+
+    timer_init();
+
+    init_idle_domain();
+
+    rcu_init();
+
+    local_irq_enable();
+
+    initialize_keytable();
+
+    console_init_postirq();
+
+    do_presmp_initcalls();
+
+    for_each_present_cpu ( i )
+    {
+        if ( (num_online_cpus() < max_cpus) && !cpu_online(i) )
+        {
+            int ret = cpu_up(i);
+            if ( ret != 0 )
+                printk("Failed to bring up CPU %u (error %d)\n", i, ret);
+        }
+    }
+
+    printk("Brought up %ld CPUs\n", (long)num_online_cpus());
+    /* TODO: smp_cpus_done(); */
+
+    do_initcalls();
+
+    /* Create initial domain 0. */
+    dom0 = domain_create(0, 0, 0);
+    if ( dom0 == NULL )
+            printk("domain_create failed\n");
+    if ( (dom0 == NULL) || (alloc_dom0_vcpu0() == NULL) )
+            panic("Error creating domain 0\n");
+
+    dom0->is_privileged = 1;
+    dom0->target = NULL;
+
+    if ( construct_dom0(dom0) != 0)
+            panic("Could not set up DOM0 guest OS\n");
+
+    /* Scrub RAM that is still free and so may go to an unprivileged domain.
+       XXX too slow in simulator
+       scrub_heap_pages();
+    */
+
+    console_endboot();
+
+    /* Hide UART from DOM0 if we're using it */
+    serial_endboot();
+
+    domain_unpause_by_systemcontroller(dom0);
+
+    reset_stack_and_jump(init_done);
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 13:14:48 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 13:14:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZ0Hi-0002qx-DH; Fri, 09 Dec 2011 13:14:42 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RZ0Hh-0002hk-AK
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 13:14:41 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1323436430!1302365!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDQ0MTg=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28599 invoked from network); 9 Dec 2011 13:13:51 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 13:13:51 -0000
X-IronPort-AV: E=Sophos;i="4.71,325,1320642000"; d="scan'208";a="19808913"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 08:13:50 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 08:13:50 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pB9DCpEB008248;
	Fri, 9 Dec 2011 05:13:33 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 9 Dec 2011 13:13:28 +0000
Message-ID: <1323436408-16335-25-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1112091208420.3517@kaball-desktop>
References: <alpine.DEB.2.00.1112091208420.3517@kaball-desktop>
MIME-Version: 1.0
Cc: keir.xen@gmail.com, Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, JBeulich@suse.com,
	Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v2 25/25] arm: makefiles
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Makefile and config options for the ARM architecture.


Changes in v2:

- move patch at the end of the series.


Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
---
 config/arm.mk         |   18 +++++++++++
 xen/arch/arm/Makefile |   76 +++++++++++++++++++++++++++++++++++++++++++++++++
 xen/arch/arm/Rules.mk |   29 ++++++++++++++++++
 3 files changed, 123 insertions(+), 0 deletions(-)
 create mode 100644 config/arm.mk
 create mode 100644 xen/arch/arm/Makefile
 create mode 100644 xen/arch/arm/Rules.mk

diff --git a/config/arm.mk b/config/arm.mk
new file mode 100644
index 0000000..f64f0c1
--- /dev/null
+++ b/config/arm.mk
@@ -0,0 +1,18 @@
+CONFIG_ARM := y
+CONFIG_ARM_32 := y
+CONFIG_ARM_$(XEN_OS) := y
+
+# -march= -mcpu=
+
+# Explicitly specifiy 32-bit ARM ISA since toolchain default can be -mthumb:
+CFLAGS += -marm
+
+HAS_PL011 := y
+
+# Use only if calling $(LD) directly.
+#LDFLAGS_DIRECT_OpenBSD = _obsd
+#LDFLAGS_DIRECT_FreeBSD = _fbsd
+LDFLAGS_DIRECT_Linux = _linux
+LDFLAGS_DIRECT += -marmelf$(LDFLAGS_DIRECT_$(XEN_OS))_eabi
+
+CONFIG_LOAD_ADDRESS ?= 0x80000000
diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
new file mode 100644
index 0000000..517c720
--- /dev/null
+++ b/xen/arch/arm/Makefile
@@ -0,0 +1,76 @@
+subdir-y += lib
+
+obj-y += dummy.o
+obj-y += entry.o
+obj-y += domain.o
+obj-y += domain_build.o
+obj-y += gic.o
+obj-y += io.o
+obj-y += irq.o
+obj-y += mm.o
+obj-y += p2m.o
+obj-y += usercopy.o
+obj-y += setup.o
+obj-y += time.o
+obj-y += smpboot.o
+obj-y += smp.o
+obj-y += shutdown.o
+obj-y += traps.o
+obj-y += vgic.o
+obj-y += vtimer.o
+
+#obj-bin-y += ....o
+
+ALL_OBJS := head.o $(ALL_OBJS)
+
+$(TARGET): $(TARGET)-syms
+	# XXX: VE model loads by VMA so instead of
+	# making a proper ELF we link with LMA == VMA and adjust crudely
+	$(OBJCOPY) --change-addresses +0x7fe00000 $< $@
+	# XXX strip it
+
+#$(TARGET): $(TARGET)-syms $(efi-y) boot/mkelf32
+#	./boot/mkelf32 $(TARGET)-syms $(TARGET) 0x100000 \
+#	`$(NM) -nr $(TARGET)-syms | head -n 1 | sed -e 's/^\([^ ]*\).*/0x\1/'`
+
+ifeq ($(lto),y)
+# Gather all LTO objects together
+prelink_lto.o: $(ALL_OBJS)
+	$(LD_LTO) -r -o $@ $^
+
+# Link it with all the binary objects
+prelink.o: $(patsubst %/built_in.o,%/built_in_bin.o,$(ALL_OBJS)) prelink_lto.o
+	$(LD) $(LDFLAGS) -r -o $@ $^
+else
+prelink.o: $(ALL_OBJS)
+	$(LD) $(LDFLAGS) -r -o $@ $^
+endif
+
+$(BASEDIR)/common/symbols-dummy.o:
+	$(MAKE) -f $(BASEDIR)/Rules.mk -C $(BASEDIR)/common symbols-dummy.o
+
+$(TARGET)-syms: prelink.o xen.lds $(BASEDIR)/common/symbols-dummy.o
+	$(LD) $(LDFLAGS) -T xen.lds -N prelink.o \
+	    $(BASEDIR)/common/symbols-dummy.o -o $(@D)/.$(@F).0
+	$(NM) -n $(@D)/.$(@F).0 | $(BASEDIR)/tools/symbols >$(@D)/.$(@F).0.S
+	$(MAKE) -f $(BASEDIR)/Rules.mk $(@D)/.$(@F).0.o
+	$(LD) $(LDFLAGS) -T xen.lds -N prelink.o \
+	    $(@D)/.$(@F).0.o -o $(@D)/.$(@F).1
+	$(NM) -n $(@D)/.$(@F).1 | $(BASEDIR)/tools/symbols >$(@D)/.$(@F).1.S
+	$(MAKE) -f $(BASEDIR)/Rules.mk $(@D)/.$(@F).1.o
+	$(LD) $(LDFLAGS) -T xen.lds -N prelink.o \
+	    $(@D)/.$(@F).1.o -o $@
+	rm -f $(@D)/.$(@F).[0-9]*
+
+asm-offsets.s: asm-offsets.c
+	$(CC) $(filter-out -flto,$(CFLAGS)) -S -o $@ $<
+
+xen.lds: xen.lds.S
+	$(CC) -P -E -Ui386 $(AFLAGS) -DXEN_PHYS_START=$(CONFIG_LOAD_ADDRESS) -o $@ $<
+	sed -e 's/xen\.lds\.o:/xen\.lds:/g' <.xen.lds.d >.xen.lds.d.new
+	mv -f .xen.lds.d.new .xen.lds.d
+
+.PHONY: clean
+clean::
+	rm -f asm-offsets.s xen.lds
+	rm -f $(BASEDIR)/.xen-syms.[0-9]*
diff --git a/xen/arch/arm/Rules.mk b/xen/arch/arm/Rules.mk
new file mode 100644
index 0000000..336e209
--- /dev/null
+++ b/xen/arch/arm/Rules.mk
@@ -0,0 +1,29 @@
+########################################
+# arm-specific definitions
+
+#
+# If you change any of these configuration options then you must
+# 'make clean' before rebuilding.
+#
+
+CFLAGS += -fno-builtin -fno-common -Wredundant-decls
+CFLAGS += -iwithprefix include -Werror -Wno-pointer-arith -pipe
+CFLAGS += -I$(BASEDIR)/include
+
+# Prevent floating-point variables from creeping into Xen.
+CFLAGS += -msoft-float
+
+$(call cc-options-add,CFLAGS,CC,$(EMBEDDED_EXTRA_CFLAGS))
+$(call cc-option-add,CFLAGS,CC,-Wnested-externs)
+
+arm := y
+
+ifneq ($(call cc-option,$(CC),-fvisibility=hidden,n),n)
+CFLAGS += -DGCC_HAS_VISIBILITY_ATTRIBUTE
+endif
+
+CFLAGS += -march=armv7-a -mcpu=cortex-a15
+
+# Require GCC v3.4+ (to avoid issues with alignment constraints in Xen headers)
+check-$(gcc) = $(call cc-ver-check,CC,0x030400,"Xen requires at least gcc-3.4")
+$(eval $(check-y))
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 13:14:48 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 13:14:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZ0Hi-0002qx-DH; Fri, 09 Dec 2011 13:14:42 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RZ0Hh-0002hk-AK
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 13:14:41 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1323436430!1302365!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDQ0MTg=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28599 invoked from network); 9 Dec 2011 13:13:51 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 13:13:51 -0000
X-IronPort-AV: E=Sophos;i="4.71,325,1320642000"; d="scan'208";a="19808913"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 08:13:50 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 08:13:50 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pB9DCpEB008248;
	Fri, 9 Dec 2011 05:13:33 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 9 Dec 2011 13:13:28 +0000
Message-ID: <1323436408-16335-25-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1112091208420.3517@kaball-desktop>
References: <alpine.DEB.2.00.1112091208420.3517@kaball-desktop>
MIME-Version: 1.0
Cc: keir.xen@gmail.com, Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, JBeulich@suse.com,
	Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v2 25/25] arm: makefiles
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Makefile and config options for the ARM architecture.


Changes in v2:

- move patch at the end of the series.


Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
---
 config/arm.mk         |   18 +++++++++++
 xen/arch/arm/Makefile |   76 +++++++++++++++++++++++++++++++++++++++++++++++++
 xen/arch/arm/Rules.mk |   29 ++++++++++++++++++
 3 files changed, 123 insertions(+), 0 deletions(-)
 create mode 100644 config/arm.mk
 create mode 100644 xen/arch/arm/Makefile
 create mode 100644 xen/arch/arm/Rules.mk

diff --git a/config/arm.mk b/config/arm.mk
new file mode 100644
index 0000000..f64f0c1
--- /dev/null
+++ b/config/arm.mk
@@ -0,0 +1,18 @@
+CONFIG_ARM := y
+CONFIG_ARM_32 := y
+CONFIG_ARM_$(XEN_OS) := y
+
+# -march= -mcpu=
+
+# Explicitly specifiy 32-bit ARM ISA since toolchain default can be -mthumb:
+CFLAGS += -marm
+
+HAS_PL011 := y
+
+# Use only if calling $(LD) directly.
+#LDFLAGS_DIRECT_OpenBSD = _obsd
+#LDFLAGS_DIRECT_FreeBSD = _fbsd
+LDFLAGS_DIRECT_Linux = _linux
+LDFLAGS_DIRECT += -marmelf$(LDFLAGS_DIRECT_$(XEN_OS))_eabi
+
+CONFIG_LOAD_ADDRESS ?= 0x80000000
diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
new file mode 100644
index 0000000..517c720
--- /dev/null
+++ b/xen/arch/arm/Makefile
@@ -0,0 +1,76 @@
+subdir-y += lib
+
+obj-y += dummy.o
+obj-y += entry.o
+obj-y += domain.o
+obj-y += domain_build.o
+obj-y += gic.o
+obj-y += io.o
+obj-y += irq.o
+obj-y += mm.o
+obj-y += p2m.o
+obj-y += usercopy.o
+obj-y += setup.o
+obj-y += time.o
+obj-y += smpboot.o
+obj-y += smp.o
+obj-y += shutdown.o
+obj-y += traps.o
+obj-y += vgic.o
+obj-y += vtimer.o
+
+#obj-bin-y += ....o
+
+ALL_OBJS := head.o $(ALL_OBJS)
+
+$(TARGET): $(TARGET)-syms
+	# XXX: VE model loads by VMA so instead of
+	# making a proper ELF we link with LMA == VMA and adjust crudely
+	$(OBJCOPY) --change-addresses +0x7fe00000 $< $@
+	# XXX strip it
+
+#$(TARGET): $(TARGET)-syms $(efi-y) boot/mkelf32
+#	./boot/mkelf32 $(TARGET)-syms $(TARGET) 0x100000 \
+#	`$(NM) -nr $(TARGET)-syms | head -n 1 | sed -e 's/^\([^ ]*\).*/0x\1/'`
+
+ifeq ($(lto),y)
+# Gather all LTO objects together
+prelink_lto.o: $(ALL_OBJS)
+	$(LD_LTO) -r -o $@ $^
+
+# Link it with all the binary objects
+prelink.o: $(patsubst %/built_in.o,%/built_in_bin.o,$(ALL_OBJS)) prelink_lto.o
+	$(LD) $(LDFLAGS) -r -o $@ $^
+else
+prelink.o: $(ALL_OBJS)
+	$(LD) $(LDFLAGS) -r -o $@ $^
+endif
+
+$(BASEDIR)/common/symbols-dummy.o:
+	$(MAKE) -f $(BASEDIR)/Rules.mk -C $(BASEDIR)/common symbols-dummy.o
+
+$(TARGET)-syms: prelink.o xen.lds $(BASEDIR)/common/symbols-dummy.o
+	$(LD) $(LDFLAGS) -T xen.lds -N prelink.o \
+	    $(BASEDIR)/common/symbols-dummy.o -o $(@D)/.$(@F).0
+	$(NM) -n $(@D)/.$(@F).0 | $(BASEDIR)/tools/symbols >$(@D)/.$(@F).0.S
+	$(MAKE) -f $(BASEDIR)/Rules.mk $(@D)/.$(@F).0.o
+	$(LD) $(LDFLAGS) -T xen.lds -N prelink.o \
+	    $(@D)/.$(@F).0.o -o $(@D)/.$(@F).1
+	$(NM) -n $(@D)/.$(@F).1 | $(BASEDIR)/tools/symbols >$(@D)/.$(@F).1.S
+	$(MAKE) -f $(BASEDIR)/Rules.mk $(@D)/.$(@F).1.o
+	$(LD) $(LDFLAGS) -T xen.lds -N prelink.o \
+	    $(@D)/.$(@F).1.o -o $@
+	rm -f $(@D)/.$(@F).[0-9]*
+
+asm-offsets.s: asm-offsets.c
+	$(CC) $(filter-out -flto,$(CFLAGS)) -S -o $@ $<
+
+xen.lds: xen.lds.S
+	$(CC) -P -E -Ui386 $(AFLAGS) -DXEN_PHYS_START=$(CONFIG_LOAD_ADDRESS) -o $@ $<
+	sed -e 's/xen\.lds\.o:/xen\.lds:/g' <.xen.lds.d >.xen.lds.d.new
+	mv -f .xen.lds.d.new .xen.lds.d
+
+.PHONY: clean
+clean::
+	rm -f asm-offsets.s xen.lds
+	rm -f $(BASEDIR)/.xen-syms.[0-9]*
diff --git a/xen/arch/arm/Rules.mk b/xen/arch/arm/Rules.mk
new file mode 100644
index 0000000..336e209
--- /dev/null
+++ b/xen/arch/arm/Rules.mk
@@ -0,0 +1,29 @@
+########################################
+# arm-specific definitions
+
+#
+# If you change any of these configuration options then you must
+# 'make clean' before rebuilding.
+#
+
+CFLAGS += -fno-builtin -fno-common -Wredundant-decls
+CFLAGS += -iwithprefix include -Werror -Wno-pointer-arith -pipe
+CFLAGS += -I$(BASEDIR)/include
+
+# Prevent floating-point variables from creeping into Xen.
+CFLAGS += -msoft-float
+
+$(call cc-options-add,CFLAGS,CC,$(EMBEDDED_EXTRA_CFLAGS))
+$(call cc-option-add,CFLAGS,CC,-Wnested-externs)
+
+arm := y
+
+ifneq ($(call cc-option,$(CC),-fvisibility=hidden,n),n)
+CFLAGS += -DGCC_HAS_VISIBILITY_ATTRIBUTE
+endif
+
+CFLAGS += -march=armv7-a -mcpu=cortex-a15
+
+# Require GCC v3.4+ (to avoid issues with alignment constraints in Xen headers)
+check-$(gcc) = $(call cc-ver-check,CC,0x030400,"Xen requires at least gcc-3.4")
+$(eval $(check-y))
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 13:15:09 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 13:15:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZ0I7-0003Pc-Uh; Fri, 09 Dec 2011 13:15:07 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RZ0I5-0003Fh-JX
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 13:15:05 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1323436454!6512338!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDQ0MTg=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15823 invoked from network); 9 Dec 2011 13:14:16 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 13:14:16 -0000
X-IronPort-AV: E=Sophos;i="4.71,325,1320642000"; d="scan'208";a="19808895"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 08:13:10 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 08:13:10 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pB9DCpDm008248;
	Fri, 9 Dec 2011 05:12:54 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 9 Dec 2011 13:13:05 +0000
Message-ID: <1323436408-16335-2-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1112091208420.3517@kaball-desktop>
References: <alpine.DEB.2.00.1112091208420.3517@kaball-desktop>
MIME-Version: 1.0
Cc: keir.xen@gmail.com, Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, JBeulich@suse.com,
	Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v2 02/25] Include some header files that are not
	automatically included on all archs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Changes in v2:

- include asm header files after xen header files;

- remove incorrect comment;

- do not include asm/p2m.h under ia64.


Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
---
 xen/common/domctl.c           |    1 +
 xen/common/grant_table.c      |    1 +
 xen/common/irq.c              |    1 +
 xen/common/kernel.c           |    2 +-
 xen/common/keyhandler.c       |    1 +
 xen/common/memory.c           |    4 ++--
 xen/common/spinlock.c         |    1 +
 xen/common/wait.c             |    1 +
 xen/drivers/char/console.c    |    1 +
 xen/include/xen/grant_table.h |    1 +
 xen/include/xen/list.h        |    1 +
 xen/include/xen/sched.h       |    4 ++++
 xen/include/xen/timer.h       |    1 +
 xen/include/xen/tmem_xen.h    |    1 +
 14 files changed, 18 insertions(+), 3 deletions(-)

diff --git a/xen/common/domctl.c b/xen/common/domctl.c
index 6705a57..397f774 100644
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -24,6 +24,7 @@
 #include <xen/paging.h>
 #include <xen/hypercall.h>
 #include <asm/current.h>
+#include <asm/page.h>
 #include <public/domctl.h>
 #include <xsm/xsm.h>
 
diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c
index c80a359..de3a076 100644
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -38,6 +38,7 @@
 #include <xen/paging.h>
 #include <xen/keyhandler.h>
 #include <xsm/xsm.h>
+#include <asm/flushtlb.h>
 
 #ifndef max_nr_grant_frames
 unsigned int max_nr_grant_frames = DEFAULT_MAX_NR_GRANT_FRAMES;
diff --git a/xen/common/irq.c b/xen/common/irq.c
index 6d37dd4..3e55dfa 100644
--- a/xen/common/irq.c
+++ b/xen/common/irq.c
@@ -1,5 +1,6 @@
 #include <xen/config.h>
 #include <xen/irq.h>
+#include <xen/errno.h>
 
 int init_one_irq_desc(struct irq_desc *desc)
 {
diff --git a/xen/common/kernel.c b/xen/common/kernel.c
index 7decc1d..f51d387 100644
--- a/xen/common/kernel.c
+++ b/xen/common/kernel.c
@@ -18,8 +18,8 @@
 #include <public/version.h>
 #ifdef CONFIG_X86
 #include <asm/shared.h>
-#include <asm/setup.h>
 #endif
+#include <asm/setup.h>
 
 #ifndef COMPAT
 
diff --git a/xen/common/keyhandler.c b/xen/common/keyhandler.c
index a8f256a..6071f09 100644
--- a/xen/common/keyhandler.c
+++ b/xen/common/keyhandler.c
@@ -15,6 +15,7 @@
 #include <xen/compat.h>
 #include <xen/ctype.h>
 #include <xen/perfc.h>
+#include <xen/init.h>
 #include <asm/debugger.h>
 #include <asm/div64.h>
 
diff --git a/xen/common/memory.c b/xen/common/memory.c
index aefb706..52e2466 100644
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -23,8 +23,8 @@
 #include <xen/tmem_xen.h>
 #include <asm/current.h>
 #include <asm/hardirq.h>
-#ifdef CONFIG_X86
-# include <asm/p2m.h>
+#ifndef __ia64__
+#include <asm/p2m.h>
 #endif
 #include <xen/numa.h>
 #include <public/memory.h>
diff --git a/xen/common/spinlock.c b/xen/common/spinlock.c
index ecf5b44..bfb9670 100644
--- a/xen/common/spinlock.c
+++ b/xen/common/spinlock.c
@@ -8,6 +8,7 @@
 #include <xen/preempt.h>
 #include <public/sysctl.h>
 #include <asm/processor.h>
+#include <asm/atomic.h>
 
 #ifndef NDEBUG
 
diff --git a/xen/common/wait.c b/xen/common/wait.c
index a2c7640..0410c98 100644
--- a/xen/common/wait.c
+++ b/xen/common/wait.c
@@ -23,6 +23,7 @@
 #include <xen/config.h>
 #include <xen/sched.h>
 #include <xen/wait.h>
+#include <xen/errno.h>
 
 struct waitqueue_vcpu {
     struct list_head list;
diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
index 8a4c684..89cf4f8 100644
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -12,6 +12,7 @@
 
 #include <xen/version.h>
 #include <xen/lib.h>
+#include <xen/init.h>
 #include <xen/event.h>
 #include <xen/console.h>
 #include <xen/serial.h>
diff --git a/xen/include/xen/grant_table.h b/xen/include/xen/grant_table.h
index c161705..cb0596a 100644
--- a/xen/include/xen/grant_table.h
+++ b/xen/include/xen/grant_table.h
@@ -26,6 +26,7 @@
 
 #include <xen/config.h>
 #include <public/grant_table.h>
+#include <asm/page.h>
 #include <asm/grant_table.h>
 
 /* Active grant entry - used for shadowing GTF_permit_access grants. */
diff --git a/xen/include/xen/list.h b/xen/include/xen/list.h
index b87682f..18443a4 100644
--- a/xen/include/xen/list.h
+++ b/xen/include/xen/list.h
@@ -8,6 +8,7 @@
 #define __XEN_LIST_H__
 
 #include <xen/lib.h>
+#include <xen/prefetch.h>
 #include <asm/system.h>
 
 /* These are non-NULL pointers that will result in page faults
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index e12293c..832ca6f 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -14,6 +14,10 @@
 #include <xen/nodemask.h>
 #include <xen/radix-tree.h>
 #include <xen/multicall.h>
+#include <xen/tasklet.h>
+#include <xen/mm.h>
+#include <xen/smp.h>
+#include <asm/atomic.h>
 #include <public/xen.h>
 #include <public/domctl.h>
 #include <public/sysctl.h>
diff --git a/xen/include/xen/timer.h b/xen/include/xen/timer.h
index d209142..7c465fb 100644
--- a/xen/include/xen/timer.h
+++ b/xen/include/xen/timer.h
@@ -12,6 +12,7 @@
 #include <xen/time.h>
 #include <xen/string.h>
 #include <xen/list.h>
+#include <xen/percpu.h>
 
 struct timer {
     /* System time expiry value (nanoseconds since boot). */
diff --git a/xen/include/xen/tmem_xen.h b/xen/include/xen/tmem_xen.h
index 3dbf6f8..7ce9677 100644
--- a/xen/include/xen/tmem_xen.h
+++ b/xen/include/xen/tmem_xen.h
@@ -11,6 +11,7 @@
 
 #include <xen/config.h>
 #include <xen/mm.h> /* heap alloc/free */
+#include <xen/pfn.h>
 #include <xen/xmalloc.h> /* xmalloc/xfree */
 #include <xen/sched.h>  /* struct domain */
 #include <xen/guest_access.h> /* copy_from_guest */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 13:15:09 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 13:15:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZ0I7-0003Pc-Uh; Fri, 09 Dec 2011 13:15:07 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RZ0I5-0003Fh-JX
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 13:15:05 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1323436454!6512338!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDQ0MTg=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15823 invoked from network); 9 Dec 2011 13:14:16 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 13:14:16 -0000
X-IronPort-AV: E=Sophos;i="4.71,325,1320642000"; d="scan'208";a="19808895"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 08:13:10 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 08:13:10 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pB9DCpDm008248;
	Fri, 9 Dec 2011 05:12:54 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 9 Dec 2011 13:13:05 +0000
Message-ID: <1323436408-16335-2-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1112091208420.3517@kaball-desktop>
References: <alpine.DEB.2.00.1112091208420.3517@kaball-desktop>
MIME-Version: 1.0
Cc: keir.xen@gmail.com, Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, JBeulich@suse.com,
	Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v2 02/25] Include some header files that are not
	automatically included on all archs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Changes in v2:

- include asm header files after xen header files;

- remove incorrect comment;

- do not include asm/p2m.h under ia64.


Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
---
 xen/common/domctl.c           |    1 +
 xen/common/grant_table.c      |    1 +
 xen/common/irq.c              |    1 +
 xen/common/kernel.c           |    2 +-
 xen/common/keyhandler.c       |    1 +
 xen/common/memory.c           |    4 ++--
 xen/common/spinlock.c         |    1 +
 xen/common/wait.c             |    1 +
 xen/drivers/char/console.c    |    1 +
 xen/include/xen/grant_table.h |    1 +
 xen/include/xen/list.h        |    1 +
 xen/include/xen/sched.h       |    4 ++++
 xen/include/xen/timer.h       |    1 +
 xen/include/xen/tmem_xen.h    |    1 +
 14 files changed, 18 insertions(+), 3 deletions(-)

diff --git a/xen/common/domctl.c b/xen/common/domctl.c
index 6705a57..397f774 100644
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -24,6 +24,7 @@
 #include <xen/paging.h>
 #include <xen/hypercall.h>
 #include <asm/current.h>
+#include <asm/page.h>
 #include <public/domctl.h>
 #include <xsm/xsm.h>
 
diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c
index c80a359..de3a076 100644
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -38,6 +38,7 @@
 #include <xen/paging.h>
 #include <xen/keyhandler.h>
 #include <xsm/xsm.h>
+#include <asm/flushtlb.h>
 
 #ifndef max_nr_grant_frames
 unsigned int max_nr_grant_frames = DEFAULT_MAX_NR_GRANT_FRAMES;
diff --git a/xen/common/irq.c b/xen/common/irq.c
index 6d37dd4..3e55dfa 100644
--- a/xen/common/irq.c
+++ b/xen/common/irq.c
@@ -1,5 +1,6 @@
 #include <xen/config.h>
 #include <xen/irq.h>
+#include <xen/errno.h>
 
 int init_one_irq_desc(struct irq_desc *desc)
 {
diff --git a/xen/common/kernel.c b/xen/common/kernel.c
index 7decc1d..f51d387 100644
--- a/xen/common/kernel.c
+++ b/xen/common/kernel.c
@@ -18,8 +18,8 @@
 #include <public/version.h>
 #ifdef CONFIG_X86
 #include <asm/shared.h>
-#include <asm/setup.h>
 #endif
+#include <asm/setup.h>
 
 #ifndef COMPAT
 
diff --git a/xen/common/keyhandler.c b/xen/common/keyhandler.c
index a8f256a..6071f09 100644
--- a/xen/common/keyhandler.c
+++ b/xen/common/keyhandler.c
@@ -15,6 +15,7 @@
 #include <xen/compat.h>
 #include <xen/ctype.h>
 #include <xen/perfc.h>
+#include <xen/init.h>
 #include <asm/debugger.h>
 #include <asm/div64.h>
 
diff --git a/xen/common/memory.c b/xen/common/memory.c
index aefb706..52e2466 100644
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -23,8 +23,8 @@
 #include <xen/tmem_xen.h>
 #include <asm/current.h>
 #include <asm/hardirq.h>
-#ifdef CONFIG_X86
-# include <asm/p2m.h>
+#ifndef __ia64__
+#include <asm/p2m.h>
 #endif
 #include <xen/numa.h>
 #include <public/memory.h>
diff --git a/xen/common/spinlock.c b/xen/common/spinlock.c
index ecf5b44..bfb9670 100644
--- a/xen/common/spinlock.c
+++ b/xen/common/spinlock.c
@@ -8,6 +8,7 @@
 #include <xen/preempt.h>
 #include <public/sysctl.h>
 #include <asm/processor.h>
+#include <asm/atomic.h>
 
 #ifndef NDEBUG
 
diff --git a/xen/common/wait.c b/xen/common/wait.c
index a2c7640..0410c98 100644
--- a/xen/common/wait.c
+++ b/xen/common/wait.c
@@ -23,6 +23,7 @@
 #include <xen/config.h>
 #include <xen/sched.h>
 #include <xen/wait.h>
+#include <xen/errno.h>
 
 struct waitqueue_vcpu {
     struct list_head list;
diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
index 8a4c684..89cf4f8 100644
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -12,6 +12,7 @@
 
 #include <xen/version.h>
 #include <xen/lib.h>
+#include <xen/init.h>
 #include <xen/event.h>
 #include <xen/console.h>
 #include <xen/serial.h>
diff --git a/xen/include/xen/grant_table.h b/xen/include/xen/grant_table.h
index c161705..cb0596a 100644
--- a/xen/include/xen/grant_table.h
+++ b/xen/include/xen/grant_table.h
@@ -26,6 +26,7 @@
 
 #include <xen/config.h>
 #include <public/grant_table.h>
+#include <asm/page.h>
 #include <asm/grant_table.h>
 
 /* Active grant entry - used for shadowing GTF_permit_access grants. */
diff --git a/xen/include/xen/list.h b/xen/include/xen/list.h
index b87682f..18443a4 100644
--- a/xen/include/xen/list.h
+++ b/xen/include/xen/list.h
@@ -8,6 +8,7 @@
 #define __XEN_LIST_H__
 
 #include <xen/lib.h>
+#include <xen/prefetch.h>
 #include <asm/system.h>
 
 /* These are non-NULL pointers that will result in page faults
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index e12293c..832ca6f 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -14,6 +14,10 @@
 #include <xen/nodemask.h>
 #include <xen/radix-tree.h>
 #include <xen/multicall.h>
+#include <xen/tasklet.h>
+#include <xen/mm.h>
+#include <xen/smp.h>
+#include <asm/atomic.h>
 #include <public/xen.h>
 #include <public/domctl.h>
 #include <public/sysctl.h>
diff --git a/xen/include/xen/timer.h b/xen/include/xen/timer.h
index d209142..7c465fb 100644
--- a/xen/include/xen/timer.h
+++ b/xen/include/xen/timer.h
@@ -12,6 +12,7 @@
 #include <xen/time.h>
 #include <xen/string.h>
 #include <xen/list.h>
+#include <xen/percpu.h>
 
 struct timer {
     /* System time expiry value (nanoseconds since boot). */
diff --git a/xen/include/xen/tmem_xen.h b/xen/include/xen/tmem_xen.h
index 3dbf6f8..7ce9677 100644
--- a/xen/include/xen/tmem_xen.h
+++ b/xen/include/xen/tmem_xen.h
@@ -11,6 +11,7 @@
 
 #include <xen/config.h>
 #include <xen/mm.h> /* heap alloc/free */
+#include <xen/pfn.h>
 #include <xen/xmalloc.h> /* xmalloc/xfree */
 #include <xen/sched.h>  /* struct domain */
 #include <xen/guest_access.h> /* copy_from_guest */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 13:27:05 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 13: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.xensource.com>)
	id 1RZ0TY-0006Gy-Md; Fri, 09 Dec 2011 13:26:56 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RZ0TX-0006Gs-61
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 13:26:55 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1323437164!4910417!1
X-Originating-IP: [209.85.214.43]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11598 invoked from network); 9 Dec 2011 13:26:05 -0000
Received: from mail-bw0-f43.google.com (HELO mail-bw0-f43.google.com)
	(209.85.214.43)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 13:26:05 -0000
Received: by bkbzs2 with SMTP id zs2so8656497bkb.30
	for <xen-devel@lists.xensource.com>;
	Fri, 09 Dec 2011 05:26:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=vOV9C+kNB73BJFQ+NQF7+J+79vuUjfAFyGX/2YNfdJ4=;
	b=mQ3HE6Zj/YBEZ0fBZAeXvp6LCp/1hZquZd8XovnVTlc0dzPLk+vEE9meFsvU76o5Va
	sjk++2eGoLjgBe/nWBUIqCwGYVVoudPrCgmj7WOtBo1t7EHLIKlxxkKpcpLHs07JcNC9
	s8kZVGQV4sIluRlGt829+W+3TrjhU7ubX0PZc=
Received: by 10.204.154.136 with SMTP id o8mr3898198bkw.112.1323437164239;
	Fri, 09 Dec 2011 05:26:04 -0800 (PST)
Received: from [192.168.1.70]
	(host81-155-119-104.range81-155.btcentralplus.com. [81.155.119.104])
	by mx.google.com with ESMTPS id l5sm9798257bkv.9.2011.12.09.05.26.02
	(version=SSLv3 cipher=OTHER); Fri, 09 Dec 2011 05:26:02 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Fri, 09 Dec 2011 13:26:01 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: <stefano.stabellini@eu.citrix.com>,
	<xen-devel@lists.xensource.com>
Message-ID: <CB07BCE9.26E48%keir.xen@gmail.com>
Thread-Topic: [PATCH v2 12/25] arm: domain
Thread-Index: Acy2dhfiE/AxIdq0CEOMyNMuOfPGgA==
In-Reply-To: <1323436408-16335-12-git-send-email-stefano.stabellini@eu.citrix.com>
Mime-version: 1.0
Cc: Ian.Campbell@citrix.com, JBeulich@suse.com,
	Tim Deegan <Tim.Deegan@citrix.com>
Subject: Re: [Xen-devel] [PATCH v2 12/25] arm: domain
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 09/12/2011 13:13, "stefano.stabellini@eu.citrix.com"
<stefano.stabellini@eu.citrix.com> wrote:

> From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> 
> Domain creation and destruction, vcpu initialization and destruction,
> arch specific scheduling functions called by common code.

It would be nice if xen-arm had per-vcpu stacks (and, optionally, per-cpu
irq stacks) off the bat. However I won't make it a strict requirement while
xen-x86 is lagging in this area. That's where you cribbed this logic from
after all.

 -- Keir

> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
> ---
>  xen/arch/arm/domain.c        |  253
> ++++++++++++++++++++++++++++++++++++++++++
>  xen/include/asm-arm/domain.h |   43 +++++++
>  2 files changed, 296 insertions(+), 0 deletions(-)
>  create mode 100644 xen/arch/arm/domain.c
>  create mode 100644 xen/include/asm-arm/domain.h
> 
> diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
> new file mode 100644
> index 0000000..d706b5f
> --- /dev/null
> +++ b/xen/arch/arm/domain.c
> @@ -0,0 +1,253 @@
> +#include <xen/config.h>
> +#include <xen/init.h>
> +#include <xen/lib.h>
> +#include <xen/sched.h>
> +#include <xen/softirq.h>
> +#include <xen/wait.h>
> +#include <xen/errno.h>
> +
> +#include <asm/current.h>
> +#include <asm/regs.h>
> +#include <asm/p2m.h>
> +#include <asm/irq.h>
> +
> +DEFINE_PER_CPU(struct vcpu *, curr_vcpu);
> +
> +static void continue_idle_domain(struct vcpu *v)
> +{
> +    reset_stack_and_jump(idle_loop);
> +}
> +
> +static void continue_nonidle_domain(struct vcpu *v)
> +{
> +    /* check_wakeup_from_wait(); */
> +    reset_stack_and_jump(return_from_trap);
> +}
> +
> +void idle_loop(void)
> +{
> +    for ( ; ; )
> +    {
> +  /* TODO
> +     if ( cpu_is_offline(smp_processor_id()) )
> +     play_dead();
> +     (*pm_idle)();
> +     BUG();
> +  */
> +        do_tasklet();
> +        do_softirq();
> +    }
> +}
> +
> +static void ctxt_switch_from(struct vcpu *p)
> +{
> +
> +}
> +
> +static void ctxt_switch_to(struct vcpu *n)
> +{
> +    p2m_load_VTTBR(n->domain);
> +}
> +
> +static void __context_switch(void)
> +{
> +    struct cpu_user_regs *stack_regs = guest_cpu_user_regs();
> +    unsigned int          cpu = smp_processor_id();
> +    struct vcpu          *p = per_cpu(curr_vcpu, cpu);
> +    struct vcpu          *n = current;
> +
> +    ASSERT(p != n);
> +    ASSERT(cpumask_empty(n->vcpu_dirty_cpumask));
> +
> +    if ( !is_idle_vcpu(p) )
> +    {
> +        memcpy(&p->arch.user_regs, stack_regs, CTXT_SWITCH_STACK_BYTES);
> +        ctxt_switch_from(p);
> +    }
> +
> +    if ( !is_idle_vcpu(n) )
> +    {
> +        memcpy(stack_regs, &n->arch.user_regs, CTXT_SWITCH_STACK_BYTES);
> +        ctxt_switch_to(n);
> +    }
> +
> +    per_cpu(curr_vcpu, cpu) = n;
> +
> +}
> +
> +static void schedule_tail(struct vcpu *v)
> +{
> +    if ( is_idle_vcpu(v) )
> +        continue_idle_domain(v);
> +    else
> +        continue_nonidle_domain(v);
> +}
> +
> +void context_switch(struct vcpu *prev, struct vcpu *next)
> +{
> +    unsigned int cpu = smp_processor_id();
> +
> +    ASSERT(local_irq_is_enabled());
> +
> +    printk("context switch %d:%d%s -> %d:%d%s\n",
> +           prev->domain->domain_id, prev->vcpu_id, is_idle_vcpu(prev) ? "
> (idle)" : "",
> +           next->domain->domain_id, next->vcpu_id, is_idle_vcpu(next) ? "
> (idle)" : "");
> +
> + /* TODO
> +    if (prev != next)
> +    update_runstate_area(prev);
> + */
> +
> +    local_irq_disable();
> +
> +    set_current(next);
> +
> +    if ( (per_cpu(curr_vcpu, cpu) == next) ||
> +         (is_idle_vcpu(next) && cpu_online(cpu)) )
> +    {
> +        local_irq_enable();
> +    }
> +    else
> +    {
> +        __context_switch();
> +
> +        /* Re-enable interrupts before restoring state which may fault. */
> +        local_irq_enable();
> +    }
> +
> +    context_saved(prev);
> +
> + /* TODO
> +    if (prev != next)
> +    update_runstate_area(next);
> + */
> +
> +    schedule_tail(next);
> +    BUG();
> +
> +}
> +
> +void continue_running(struct vcpu *same)
> +{
> +    schedule_tail(same);
> +    BUG();
> +}
> +
> +int __sync_local_execstate(void)
> +{
> +    unsigned long flags;
> +    int switch_required;
> +
> +    local_irq_save(flags);
> +
> +    switch_required = (this_cpu(curr_vcpu) != current);
> +
> +    if ( switch_required )
> +    {
> +        ASSERT(current == idle_vcpu[smp_processor_id()]);
> +        __context_switch();
> +    }
> +
> +    local_irq_restore(flags);
> +
> +    return switch_required;
> +}
> +
> +void sync_local_execstate(void)
> +{
> +    (void)__sync_local_execstate();
> +}
> +
> +void startup_cpu_idle_loop(void)
> +{
> +        struct vcpu *v = current;
> +
> +        ASSERT(is_idle_vcpu(v));
> +  /* TODO
> +     cpumask_set_cpu(v->processor, v->domain->domain_dirty_cpumask);
> +     cpumask_set_cpu(v->processor, v->vcpu_dirty_cpumask);
> +  */
> +
> +        reset_stack_and_jump(idle_loop);
> +}
> +
> +struct domain *alloc_domain_struct(void)
> +{
> +    struct domain *d;
> +    BUILD_BUG_ON(sizeof(*d) > PAGE_SIZE);
> +    d = alloc_xenheap_pages(0, 0);
> +    if ( d != NULL )
> +        clear_page(d);
> +    return d;
> +}
> +
> +void free_domain_struct(struct domain *d)
> +{
> +    free_xenheap_page(d);
> +}
> +
> +void dump_pageframe_info(struct domain *d)
> +{
> +
> +}
> +
> +struct vcpu *alloc_vcpu_struct(void)
> +{
> +    struct vcpu *v;
> +    BUILD_BUG_ON(sizeof(*v) > PAGE_SIZE);
> +    v = alloc_xenheap_pages(0, 0);
> +    if ( v != NULL )
> +        clear_page(v);
> +    return v;
> +}
> +
> +void free_vcpu_struct(struct vcpu *v)
> +{
> +    free_xenheap_page(v);
> +}
> +
> +int vcpu_initialise(struct vcpu *v)
> +{
> +    int rc = 0;
> +
> +    return rc;
> +}
> +
> +void vcpu_destroy(struct vcpu *v)
> +{
> +
> +}
> +
> +int arch_domain_create(struct domain *d, unsigned int domcr_flags)
> +{
> +    int rc;
> +
> +    d->max_vcpus = 8;
> +
> +    rc = 0;
> +fail:
> +    return rc;
> +}
> +
> +void arch_domain_destroy(struct domain *d)
> +{
> +    /* p2m_destroy */
> +    /* domain_vgic_destroy */
> +}
> +
> +void arch_dump_domain_info(struct domain *d)
> +{
> +}
> +
> +void arch_dump_vcpu_info(struct vcpu *v)
> +{
> +}
> +
> +/*
> + * Local variables:
> + * mode: C
> + * c-set-style: "BSD"
> + * c-basic-offset: 4
> + * indent-tabs-mode: nil
> + * End:
> + */
> diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
> new file mode 100644
> index 0000000..c226bdf
> --- /dev/null
> +++ b/xen/include/asm-arm/domain.h
> @@ -0,0 +1,43 @@
> +#ifndef __ASM_DOMAIN_H__
> +#define __ASM_DOMAIN_H__
> +
> +#include <xen/config.h>
> +#include <xen/cache.h>
> +#include <asm/page.h>
> +#include <asm/p2m.h>
> +
> +struct pending_irq
> +{
> +    int irq;
> +    struct irq_desc *desc; /* only set it the irq corresponds to a physical
> irq */
> +    uint8_t priority;
> +    struct list_head link;
> +};
> +
> +struct arch_domain
> +{
> +}  __cacheline_aligned;
> +
> +struct arch_vcpu
> +{
> +    struct cpu_user_regs user_regs;
> +
> +    uint32_t sctlr;
> +    uint32_t ttbr0, ttbr1, ttbcr;
> +
> +}  __cacheline_aligned;
> +
> +void vcpu_show_execution_state(struct vcpu *);
> +void vcpu_show_registers(const struct vcpu *);
> +
> +#endif /* __ASM_DOMAIN_H__ */
> +
> +/*
> + * Local variables:
> + * mode: C
> + * c-set-style: "BSD"
> + * c-basic-offset: 4
> + * tab-width: 4
> + * indent-tabs-mode: nil
> + * End:
> + */



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 13:27:05 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 13: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.xensource.com>)
	id 1RZ0TY-0006Gy-Md; Fri, 09 Dec 2011 13:26:56 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RZ0TX-0006Gs-61
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 13:26:55 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1323437164!4910417!1
X-Originating-IP: [209.85.214.43]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11598 invoked from network); 9 Dec 2011 13:26:05 -0000
Received: from mail-bw0-f43.google.com (HELO mail-bw0-f43.google.com)
	(209.85.214.43)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 13:26:05 -0000
Received: by bkbzs2 with SMTP id zs2so8656497bkb.30
	for <xen-devel@lists.xensource.com>;
	Fri, 09 Dec 2011 05:26:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=vOV9C+kNB73BJFQ+NQF7+J+79vuUjfAFyGX/2YNfdJ4=;
	b=mQ3HE6Zj/YBEZ0fBZAeXvp6LCp/1hZquZd8XovnVTlc0dzPLk+vEE9meFsvU76o5Va
	sjk++2eGoLjgBe/nWBUIqCwGYVVoudPrCgmj7WOtBo1t7EHLIKlxxkKpcpLHs07JcNC9
	s8kZVGQV4sIluRlGt829+W+3TrjhU7ubX0PZc=
Received: by 10.204.154.136 with SMTP id o8mr3898198bkw.112.1323437164239;
	Fri, 09 Dec 2011 05:26:04 -0800 (PST)
Received: from [192.168.1.70]
	(host81-155-119-104.range81-155.btcentralplus.com. [81.155.119.104])
	by mx.google.com with ESMTPS id l5sm9798257bkv.9.2011.12.09.05.26.02
	(version=SSLv3 cipher=OTHER); Fri, 09 Dec 2011 05:26:02 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Fri, 09 Dec 2011 13:26:01 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: <stefano.stabellini@eu.citrix.com>,
	<xen-devel@lists.xensource.com>
Message-ID: <CB07BCE9.26E48%keir.xen@gmail.com>
Thread-Topic: [PATCH v2 12/25] arm: domain
Thread-Index: Acy2dhfiE/AxIdq0CEOMyNMuOfPGgA==
In-Reply-To: <1323436408-16335-12-git-send-email-stefano.stabellini@eu.citrix.com>
Mime-version: 1.0
Cc: Ian.Campbell@citrix.com, JBeulich@suse.com,
	Tim Deegan <Tim.Deegan@citrix.com>
Subject: Re: [Xen-devel] [PATCH v2 12/25] arm: domain
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 09/12/2011 13:13, "stefano.stabellini@eu.citrix.com"
<stefano.stabellini@eu.citrix.com> wrote:

> From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> 
> Domain creation and destruction, vcpu initialization and destruction,
> arch specific scheduling functions called by common code.

It would be nice if xen-arm had per-vcpu stacks (and, optionally, per-cpu
irq stacks) off the bat. However I won't make it a strict requirement while
xen-x86 is lagging in this area. That's where you cribbed this logic from
after all.

 -- Keir

> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
> ---
>  xen/arch/arm/domain.c        |  253
> ++++++++++++++++++++++++++++++++++++++++++
>  xen/include/asm-arm/domain.h |   43 +++++++
>  2 files changed, 296 insertions(+), 0 deletions(-)
>  create mode 100644 xen/arch/arm/domain.c
>  create mode 100644 xen/include/asm-arm/domain.h
> 
> diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
> new file mode 100644
> index 0000000..d706b5f
> --- /dev/null
> +++ b/xen/arch/arm/domain.c
> @@ -0,0 +1,253 @@
> +#include <xen/config.h>
> +#include <xen/init.h>
> +#include <xen/lib.h>
> +#include <xen/sched.h>
> +#include <xen/softirq.h>
> +#include <xen/wait.h>
> +#include <xen/errno.h>
> +
> +#include <asm/current.h>
> +#include <asm/regs.h>
> +#include <asm/p2m.h>
> +#include <asm/irq.h>
> +
> +DEFINE_PER_CPU(struct vcpu *, curr_vcpu);
> +
> +static void continue_idle_domain(struct vcpu *v)
> +{
> +    reset_stack_and_jump(idle_loop);
> +}
> +
> +static void continue_nonidle_domain(struct vcpu *v)
> +{
> +    /* check_wakeup_from_wait(); */
> +    reset_stack_and_jump(return_from_trap);
> +}
> +
> +void idle_loop(void)
> +{
> +    for ( ; ; )
> +    {
> +  /* TODO
> +     if ( cpu_is_offline(smp_processor_id()) )
> +     play_dead();
> +     (*pm_idle)();
> +     BUG();
> +  */
> +        do_tasklet();
> +        do_softirq();
> +    }
> +}
> +
> +static void ctxt_switch_from(struct vcpu *p)
> +{
> +
> +}
> +
> +static void ctxt_switch_to(struct vcpu *n)
> +{
> +    p2m_load_VTTBR(n->domain);
> +}
> +
> +static void __context_switch(void)
> +{
> +    struct cpu_user_regs *stack_regs = guest_cpu_user_regs();
> +    unsigned int          cpu = smp_processor_id();
> +    struct vcpu          *p = per_cpu(curr_vcpu, cpu);
> +    struct vcpu          *n = current;
> +
> +    ASSERT(p != n);
> +    ASSERT(cpumask_empty(n->vcpu_dirty_cpumask));
> +
> +    if ( !is_idle_vcpu(p) )
> +    {
> +        memcpy(&p->arch.user_regs, stack_regs, CTXT_SWITCH_STACK_BYTES);
> +        ctxt_switch_from(p);
> +    }
> +
> +    if ( !is_idle_vcpu(n) )
> +    {
> +        memcpy(stack_regs, &n->arch.user_regs, CTXT_SWITCH_STACK_BYTES);
> +        ctxt_switch_to(n);
> +    }
> +
> +    per_cpu(curr_vcpu, cpu) = n;
> +
> +}
> +
> +static void schedule_tail(struct vcpu *v)
> +{
> +    if ( is_idle_vcpu(v) )
> +        continue_idle_domain(v);
> +    else
> +        continue_nonidle_domain(v);
> +}
> +
> +void context_switch(struct vcpu *prev, struct vcpu *next)
> +{
> +    unsigned int cpu = smp_processor_id();
> +
> +    ASSERT(local_irq_is_enabled());
> +
> +    printk("context switch %d:%d%s -> %d:%d%s\n",
> +           prev->domain->domain_id, prev->vcpu_id, is_idle_vcpu(prev) ? "
> (idle)" : "",
> +           next->domain->domain_id, next->vcpu_id, is_idle_vcpu(next) ? "
> (idle)" : "");
> +
> + /* TODO
> +    if (prev != next)
> +    update_runstate_area(prev);
> + */
> +
> +    local_irq_disable();
> +
> +    set_current(next);
> +
> +    if ( (per_cpu(curr_vcpu, cpu) == next) ||
> +         (is_idle_vcpu(next) && cpu_online(cpu)) )
> +    {
> +        local_irq_enable();
> +    }
> +    else
> +    {
> +        __context_switch();
> +
> +        /* Re-enable interrupts before restoring state which may fault. */
> +        local_irq_enable();
> +    }
> +
> +    context_saved(prev);
> +
> + /* TODO
> +    if (prev != next)
> +    update_runstate_area(next);
> + */
> +
> +    schedule_tail(next);
> +    BUG();
> +
> +}
> +
> +void continue_running(struct vcpu *same)
> +{
> +    schedule_tail(same);
> +    BUG();
> +}
> +
> +int __sync_local_execstate(void)
> +{
> +    unsigned long flags;
> +    int switch_required;
> +
> +    local_irq_save(flags);
> +
> +    switch_required = (this_cpu(curr_vcpu) != current);
> +
> +    if ( switch_required )
> +    {
> +        ASSERT(current == idle_vcpu[smp_processor_id()]);
> +        __context_switch();
> +    }
> +
> +    local_irq_restore(flags);
> +
> +    return switch_required;
> +}
> +
> +void sync_local_execstate(void)
> +{
> +    (void)__sync_local_execstate();
> +}
> +
> +void startup_cpu_idle_loop(void)
> +{
> +        struct vcpu *v = current;
> +
> +        ASSERT(is_idle_vcpu(v));
> +  /* TODO
> +     cpumask_set_cpu(v->processor, v->domain->domain_dirty_cpumask);
> +     cpumask_set_cpu(v->processor, v->vcpu_dirty_cpumask);
> +  */
> +
> +        reset_stack_and_jump(idle_loop);
> +}
> +
> +struct domain *alloc_domain_struct(void)
> +{
> +    struct domain *d;
> +    BUILD_BUG_ON(sizeof(*d) > PAGE_SIZE);
> +    d = alloc_xenheap_pages(0, 0);
> +    if ( d != NULL )
> +        clear_page(d);
> +    return d;
> +}
> +
> +void free_domain_struct(struct domain *d)
> +{
> +    free_xenheap_page(d);
> +}
> +
> +void dump_pageframe_info(struct domain *d)
> +{
> +
> +}
> +
> +struct vcpu *alloc_vcpu_struct(void)
> +{
> +    struct vcpu *v;
> +    BUILD_BUG_ON(sizeof(*v) > PAGE_SIZE);
> +    v = alloc_xenheap_pages(0, 0);
> +    if ( v != NULL )
> +        clear_page(v);
> +    return v;
> +}
> +
> +void free_vcpu_struct(struct vcpu *v)
> +{
> +    free_xenheap_page(v);
> +}
> +
> +int vcpu_initialise(struct vcpu *v)
> +{
> +    int rc = 0;
> +
> +    return rc;
> +}
> +
> +void vcpu_destroy(struct vcpu *v)
> +{
> +
> +}
> +
> +int arch_domain_create(struct domain *d, unsigned int domcr_flags)
> +{
> +    int rc;
> +
> +    d->max_vcpus = 8;
> +
> +    rc = 0;
> +fail:
> +    return rc;
> +}
> +
> +void arch_domain_destroy(struct domain *d)
> +{
> +    /* p2m_destroy */
> +    /* domain_vgic_destroy */
> +}
> +
> +void arch_dump_domain_info(struct domain *d)
> +{
> +}
> +
> +void arch_dump_vcpu_info(struct vcpu *v)
> +{
> +}
> +
> +/*
> + * Local variables:
> + * mode: C
> + * c-set-style: "BSD"
> + * c-basic-offset: 4
> + * indent-tabs-mode: nil
> + * End:
> + */
> diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
> new file mode 100644
> index 0000000..c226bdf
> --- /dev/null
> +++ b/xen/include/asm-arm/domain.h
> @@ -0,0 +1,43 @@
> +#ifndef __ASM_DOMAIN_H__
> +#define __ASM_DOMAIN_H__
> +
> +#include <xen/config.h>
> +#include <xen/cache.h>
> +#include <asm/page.h>
> +#include <asm/p2m.h>
> +
> +struct pending_irq
> +{
> +    int irq;
> +    struct irq_desc *desc; /* only set it the irq corresponds to a physical
> irq */
> +    uint8_t priority;
> +    struct list_head link;
> +};
> +
> +struct arch_domain
> +{
> +}  __cacheline_aligned;
> +
> +struct arch_vcpu
> +{
> +    struct cpu_user_regs user_regs;
> +
> +    uint32_t sctlr;
> +    uint32_t ttbr0, ttbr1, ttbcr;
> +
> +}  __cacheline_aligned;
> +
> +void vcpu_show_execution_state(struct vcpu *);
> +void vcpu_show_registers(const struct vcpu *);
> +
> +#endif /* __ASM_DOMAIN_H__ */
> +
> +/*
> + * Local variables:
> + * mode: C
> + * c-set-style: "BSD"
> + * c-basic-offset: 4
> + * tab-width: 4
> + * indent-tabs-mode: nil
> + * End:
> + */



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 13:33:58 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 13:33:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZ0aE-0006dv-6Y; Fri, 09 Dec 2011 13:33:50 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RZ0aD-0006dg-HR
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 13:33:49 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1323437579!7595189!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27328 invoked from network); 9 Dec 2011 13:33:00 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-3.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 9 Dec 2011 13:33:00 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 09 Dec 2011 13:32:59 +0000
Message-Id: <4EE21C4602000078000667AA@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 09 Dec 2011 13:33:42 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: <stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1112091208420.3517@kaball-desktop>
	<1323436408-16335-6-git-send-email-stefano.stabellini@eu.citrix.com>
In-Reply-To: <1323436408-16335-6-git-send-email-stefano.stabellini@eu.citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com, keir.xen@gmail.com,
	Ian Campbell <ian.campbell@citrix.com>, Tim.Deegan@citrix.com
Subject: Re: [Xen-devel] [PATCH v2 06/25] libelf-loader: introduce
	elf_load_image
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 09.12.11 at 14:13, <stefano.stabellini@eu.citrix.com> wrote:
> Implement a new function, called elf_load_image, to perform the actually
> copy of the elf image and clearing the padding.
> The function is implemented as memcpy and memset when the library is
> built as part of the tools, but it is implemented as copy_to_user and
> clear_user when built as part of Xen, so that it can be safely called
> with an HVM style dom0.

I meant to ask this on the first round already, but apparently forgot:
What is it that prevents memcpy()/memset() from being used for a
HVM style Dom0? {clear,copy_to}_user() still expect the guest memory
to be visible in the hypervisor's virtual address space - how could a
fault happen here? And if you have to take precautions for a fault,
shouldn't the calling code check the respective return values?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 13:33:58 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 13:33:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZ0aE-0006dv-6Y; Fri, 09 Dec 2011 13:33:50 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RZ0aD-0006dg-HR
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 13:33:49 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1323437579!7595189!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27328 invoked from network); 9 Dec 2011 13:33:00 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-3.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 9 Dec 2011 13:33:00 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 09 Dec 2011 13:32:59 +0000
Message-Id: <4EE21C4602000078000667AA@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 09 Dec 2011 13:33:42 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: <stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1112091208420.3517@kaball-desktop>
	<1323436408-16335-6-git-send-email-stefano.stabellini@eu.citrix.com>
In-Reply-To: <1323436408-16335-6-git-send-email-stefano.stabellini@eu.citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com, keir.xen@gmail.com,
	Ian Campbell <ian.campbell@citrix.com>, Tim.Deegan@citrix.com
Subject: Re: [Xen-devel] [PATCH v2 06/25] libelf-loader: introduce
	elf_load_image
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 09.12.11 at 14:13, <stefano.stabellini@eu.citrix.com> wrote:
> Implement a new function, called elf_load_image, to perform the actually
> copy of the elf image and clearing the padding.
> The function is implemented as memcpy and memset when the library is
> built as part of the tools, but it is implemented as copy_to_user and
> clear_user when built as part of Xen, so that it can be safely called
> with an HVM style dom0.

I meant to ask this on the first round already, but apparently forgot:
What is it that prevents memcpy()/memset() from being used for a
HVM style Dom0? {clear,copy_to}_user() still expect the guest memory
to be visible in the hypervisor's virtual address space - how could a
fault happen here? And if you have to take precautions for a fault,
shouldn't the calling code check the respective return values?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 13:34:18 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 13:34:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZ0aY-0006fq-Jo; Fri, 09 Dec 2011 13:34:10 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RZ0aX-0006fF-Md
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 13:34:09 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1323437599!6563253!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI2MQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6307 invoked from network); 9 Dec 2011 13:33:20 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 13:33:20 -0000
X-IronPort-AV: E=Sophos;i="4.71,326,1320624000"; 
   d="scan'208";a="9384409"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 13:33:09 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 9 Dec 2011
	13:33:09 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Date: Fri, 9 Dec 2011 13:33:09 +0000
In-Reply-To: <1316700889-3518-3-git-send-email-olaf@aepfle.de>
References: <1316700889-3518-1-git-send-email-olaf@aepfle.de>
	<1316700889-3518-3-git-send-email-olaf@aepfle.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323437589.20077.44.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Vincent
	Hanquez <Vincent.Hanquez@eu.citrix.com>,
	Jon Ludlam <jonathan.ludlam@eu.citrix.com>, Konrad <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH 2/2] xen/pv-on-hvm kexec: add
 xs_reset_watches to shutdown watches from old kernel
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2011-09-22 at 15:14 +0100, Olaf Hering wrote:
> Add new xs_reset_watches function to shutdown watches from old kernel after
> kexec boot.  The old kernel does not unregister all watches in the
> shutdown path.  They are still active, the double registration can not
> be detected by the new kernel.  When the watches fire, unexpected events
> will arrive and the xenwatch thread will crash (jumps to NULL).  An
> orderly reboot of a hvm guest will destroy the entire guest with all its
> resources (including the watches) before it is rebuilt from scratch, so
> the missing unregister is not an issue in that case.
> 
> With this change the xenstored is instructed to wipe all active watches
> for the guest.  However, a patch for xenstored is required so that it
> accepts the XS_RESET_WATCHES request from a client (see changeset
> 23839:42a45baf037d in xen-unstable.hg). Without the patch for xenstored
> the registration of watches will fail and some features of a PVonHVM
> guest are not available. The guest is still able to boot, but repeated
> kexec boots will fail.

This appears to break with oxenstored. It just hangs waiting for a
response from the daemon.

I suspect it is a bug in the daemon if it doesn't respond with an
appropriate error for an unknown command. I'll see if I can figure out
what is going wrong.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 13:34:18 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 13:34:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZ0aY-0006fq-Jo; Fri, 09 Dec 2011 13:34:10 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RZ0aX-0006fF-Md
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 13:34:09 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1323437599!6563253!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI2MQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6307 invoked from network); 9 Dec 2011 13:33:20 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 13:33:20 -0000
X-IronPort-AV: E=Sophos;i="4.71,326,1320624000"; 
   d="scan'208";a="9384409"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 13:33:09 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 9 Dec 2011
	13:33:09 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Date: Fri, 9 Dec 2011 13:33:09 +0000
In-Reply-To: <1316700889-3518-3-git-send-email-olaf@aepfle.de>
References: <1316700889-3518-1-git-send-email-olaf@aepfle.de>
	<1316700889-3518-3-git-send-email-olaf@aepfle.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323437589.20077.44.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Vincent
	Hanquez <Vincent.Hanquez@eu.citrix.com>,
	Jon Ludlam <jonathan.ludlam@eu.citrix.com>, Konrad <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH 2/2] xen/pv-on-hvm kexec: add
 xs_reset_watches to shutdown watches from old kernel
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2011-09-22 at 15:14 +0100, Olaf Hering wrote:
> Add new xs_reset_watches function to shutdown watches from old kernel after
> kexec boot.  The old kernel does not unregister all watches in the
> shutdown path.  They are still active, the double registration can not
> be detected by the new kernel.  When the watches fire, unexpected events
> will arrive and the xenwatch thread will crash (jumps to NULL).  An
> orderly reboot of a hvm guest will destroy the entire guest with all its
> resources (including the watches) before it is rebuilt from scratch, so
> the missing unregister is not an issue in that case.
> 
> With this change the xenstored is instructed to wipe all active watches
> for the guest.  However, a patch for xenstored is required so that it
> accepts the XS_RESET_WATCHES request from a client (see changeset
> 23839:42a45baf037d in xen-unstable.hg). Without the patch for xenstored
> the registration of watches will fail and some features of a PVonHVM
> guest are not available. The guest is still able to boot, but repeated
> kexec boots will fail.

This appears to break with oxenstored. It just hangs waiting for a
response from the daemon.

I suspect it is a bug in the daemon if it doesn't respond with an
appropriate error for an unknown command. I'll see if I can figure out
what is going wrong.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 13:41:29 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 13:41:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZ0hS-00075b-IX; Fri, 09 Dec 2011 13:41:18 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RZ0hR-00075W-2o
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 13:41:17 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1323438027!7596196!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI2MQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17938 invoked from network); 9 Dec 2011 13:40:27 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 13:40:27 -0000
X-IronPort-AV: E=Sophos;i="4.71,326,1320624000"; 
   d="scan'208";a="9384653"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 13:40:26 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 9 Dec 2011
	13:40:27 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Fri, 9 Dec 2011 13:40:26 +0000
In-Reply-To: <4EE21C4602000078000667AA@nat28.tlf.novell.com>
References: <alpine.DEB.2.00.1112091208420.3517@kaball-desktop>
	<1323436408-16335-6-git-send-email-stefano.stabellini@eu.citrix.com>
	<4EE21C4602000078000667AA@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323438026.20077.51.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"keir.xen@gmail.com" <keir.xen@gmail.com>,
	"Tim Deegan \(3P\)" <Tim.Deegan@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v2 06/25] libelf-loader: introduce
	elf_load_image
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2011-12-09 at 13:33 +0000, Jan Beulich wrote:
> >>> On 09.12.11 at 14:13, <stefano.stabellini@eu.citrix.com> wrote:
> > Implement a new function, called elf_load_image, to perform the actually
> > copy of the elf image and clearing the padding.
> > The function is implemented as memcpy and memset when the library is
> > built as part of the tools, but it is implemented as copy_to_user and
> > clear_user when built as part of Xen, so that it can be safely called
> > with an HVM style dom0.
> 
> I meant to ask this on the first round already, but apparently forgot:
> What is it that prevents memcpy()/memset() from being used for a
> HVM style Dom0? {clear,copy_to}_user() still expect the guest memory
> to be visible in the hypervisor's virtual address space - how could a
> fault happen here? And if you have to take precautions for a fault,
> shouldn't the calling code check the respective return values?

HVM guest memory is not (necessarily) mapped in the hypervisor page
tables, it needs to be mapped on demand. Also the source/target (delete
as appropriate) is a guest virtual address so even if the RAM happened
to be mapped it would (likely) not be in the same place so at a minimum
we need to translate things.

This is what copy_{to,from}_user does for an HVM guest even on X86,
where copy_to_user becomes copy_to_user_hvm as appropriate. 

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 13:41:29 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 13:41:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZ0hS-00075b-IX; Fri, 09 Dec 2011 13:41:18 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RZ0hR-00075W-2o
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 13:41:17 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1323438027!7596196!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI2MQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17938 invoked from network); 9 Dec 2011 13:40:27 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 13:40:27 -0000
X-IronPort-AV: E=Sophos;i="4.71,326,1320624000"; 
   d="scan'208";a="9384653"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 13:40:26 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 9 Dec 2011
	13:40:27 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Fri, 9 Dec 2011 13:40:26 +0000
In-Reply-To: <4EE21C4602000078000667AA@nat28.tlf.novell.com>
References: <alpine.DEB.2.00.1112091208420.3517@kaball-desktop>
	<1323436408-16335-6-git-send-email-stefano.stabellini@eu.citrix.com>
	<4EE21C4602000078000667AA@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323438026.20077.51.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"keir.xen@gmail.com" <keir.xen@gmail.com>,
	"Tim Deegan \(3P\)" <Tim.Deegan@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v2 06/25] libelf-loader: introduce
	elf_load_image
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2011-12-09 at 13:33 +0000, Jan Beulich wrote:
> >>> On 09.12.11 at 14:13, <stefano.stabellini@eu.citrix.com> wrote:
> > Implement a new function, called elf_load_image, to perform the actually
> > copy of the elf image and clearing the padding.
> > The function is implemented as memcpy and memset when the library is
> > built as part of the tools, but it is implemented as copy_to_user and
> > clear_user when built as part of Xen, so that it can be safely called
> > with an HVM style dom0.
> 
> I meant to ask this on the first round already, but apparently forgot:
> What is it that prevents memcpy()/memset() from being used for a
> HVM style Dom0? {clear,copy_to}_user() still expect the guest memory
> to be visible in the hypervisor's virtual address space - how could a
> fault happen here? And if you have to take precautions for a fault,
> shouldn't the calling code check the respective return values?

HVM guest memory is not (necessarily) mapped in the hypervisor page
tables, it needs to be mapped on demand. Also the source/target (delete
as appropriate) is a guest virtual address so even if the RAM happened
to be mapped it would (likely) not be in the same place so at a minimum
we need to translate things.

This is what copy_{to,from}_user does for an HVM guest even on X86,
where copy_to_user becomes copy_to_user_hvm as appropriate. 

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 13:42:42 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 13: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.xensource.com>)
	id 1RZ0ig-00079L-1y; Fri, 09 Dec 2011 13:42:34 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RZ0ie-000799-Is
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 13:42:32 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1323438103!7560113!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI2MQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30911 invoked from network); 9 Dec 2011 13:41:43 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 13:41:43 -0000
X-IronPort-AV: E=Sophos;i="4.71,326,1320624000"; 
   d="scan'208";a="9384682"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 13:41:42 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 9 Dec 2011
	13:41:43 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Keir Fraser <keir.xen@gmail.com>
Date: Fri, 9 Dec 2011 13:41:42 +0000
In-Reply-To: <CB07BCE9.26E48%keir.xen@gmail.com>
References: <CB07BCE9.26E48%keir.xen@gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323438102.20077.53.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Tim Deegan
	\(3P\)" <Tim.Deegan@citrix.com>, "JBeulich@suse.com" <JBeulich@suse.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v2 12/25] arm: domain
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2011-12-09 at 13:26 +0000, Keir Fraser wrote:
> On 09/12/2011 13:13, "stefano.stabellini@eu.citrix.com"
> <stefano.stabellini@eu.citrix.com> wrote:
> 
> > From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > 
> > Domain creation and destruction, vcpu initialization and destruction,
> > arch specific scheduling functions called by common code.
> 
> It would be nice if xen-arm had per-vcpu stacks (and, optionally, per-cpu
> irq stacks) off the bat. However I won't make it a strict requirement while
> xen-x86 is lagging in this area. That's where you cribbed this logic from
> after all.

I was going to look into this but I've been distracted by other things. 

We did discuss how this would look though -- we expect we will end up
going with per-PCPU page tables (e.g. for per CPU mapcache etc) which
simplifies things in this case as well since we can put per-PCPU stuff
at a fixed VA instead of relying on finding the CPU state info at the
base of the stack (which can be done with per-VCPU stacks but you'd need
to do a bit more book keeping).

Ian.

> 
>  -- Keir
> 
> > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> > Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
> > ---
> >  xen/arch/arm/domain.c        |  253
> > ++++++++++++++++++++++++++++++++++++++++++
> >  xen/include/asm-arm/domain.h |   43 +++++++
> >  2 files changed, 296 insertions(+), 0 deletions(-)
> >  create mode 100644 xen/arch/arm/domain.c
> >  create mode 100644 xen/include/asm-arm/domain.h
> > 
> > diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
> > new file mode 100644
> > index 0000000..d706b5f
> > --- /dev/null
> > +++ b/xen/arch/arm/domain.c
> > @@ -0,0 +1,253 @@
> > +#include <xen/config.h>
> > +#include <xen/init.h>
> > +#include <xen/lib.h>
> > +#include <xen/sched.h>
> > +#include <xen/softirq.h>
> > +#include <xen/wait.h>
> > +#include <xen/errno.h>
> > +
> > +#include <asm/current.h>
> > +#include <asm/regs.h>
> > +#include <asm/p2m.h>
> > +#include <asm/irq.h>
> > +
> > +DEFINE_PER_CPU(struct vcpu *, curr_vcpu);
> > +
> > +static void continue_idle_domain(struct vcpu *v)
> > +{
> > +    reset_stack_and_jump(idle_loop);
> > +}
> > +
> > +static void continue_nonidle_domain(struct vcpu *v)
> > +{
> > +    /* check_wakeup_from_wait(); */
> > +    reset_stack_and_jump(return_from_trap);
> > +}
> > +
> > +void idle_loop(void)
> > +{
> > +    for ( ; ; )
> > +    {
> > +  /* TODO
> > +     if ( cpu_is_offline(smp_processor_id()) )
> > +     play_dead();
> > +     (*pm_idle)();
> > +     BUG();
> > +  */
> > +        do_tasklet();
> > +        do_softirq();
> > +    }
> > +}
> > +
> > +static void ctxt_switch_from(struct vcpu *p)
> > +{
> > +
> > +}
> > +
> > +static void ctxt_switch_to(struct vcpu *n)
> > +{
> > +    p2m_load_VTTBR(n->domain);
> > +}
> > +
> > +static void __context_switch(void)
> > +{
> > +    struct cpu_user_regs *stack_regs = guest_cpu_user_regs();
> > +    unsigned int          cpu = smp_processor_id();
> > +    struct vcpu          *p = per_cpu(curr_vcpu, cpu);
> > +    struct vcpu          *n = current;
> > +
> > +    ASSERT(p != n);
> > +    ASSERT(cpumask_empty(n->vcpu_dirty_cpumask));
> > +
> > +    if ( !is_idle_vcpu(p) )
> > +    {
> > +        memcpy(&p->arch.user_regs, stack_regs, CTXT_SWITCH_STACK_BYTES);
> > +        ctxt_switch_from(p);
> > +    }
> > +
> > +    if ( !is_idle_vcpu(n) )
> > +    {
> > +        memcpy(stack_regs, &n->arch.user_regs, CTXT_SWITCH_STACK_BYTES);
> > +        ctxt_switch_to(n);
> > +    }
> > +
> > +    per_cpu(curr_vcpu, cpu) = n;
> > +
> > +}
> > +
> > +static void schedule_tail(struct vcpu *v)
> > +{
> > +    if ( is_idle_vcpu(v) )
> > +        continue_idle_domain(v);
> > +    else
> > +        continue_nonidle_domain(v);
> > +}
> > +
> > +void context_switch(struct vcpu *prev, struct vcpu *next)
> > +{
> > +    unsigned int cpu = smp_processor_id();
> > +
> > +    ASSERT(local_irq_is_enabled());
> > +
> > +    printk("context switch %d:%d%s -> %d:%d%s\n",
> > +           prev->domain->domain_id, prev->vcpu_id, is_idle_vcpu(prev) ? "
> > (idle)" : "",
> > +           next->domain->domain_id, next->vcpu_id, is_idle_vcpu(next) ? "
> > (idle)" : "");
> > +
> > + /* TODO
> > +    if (prev != next)
> > +    update_runstate_area(prev);
> > + */
> > +
> > +    local_irq_disable();
> > +
> > +    set_current(next);
> > +
> > +    if ( (per_cpu(curr_vcpu, cpu) == next) ||
> > +         (is_idle_vcpu(next) && cpu_online(cpu)) )
> > +    {
> > +        local_irq_enable();
> > +    }
> > +    else
> > +    {
> > +        __context_switch();
> > +
> > +        /* Re-enable interrupts before restoring state which may fault. */
> > +        local_irq_enable();
> > +    }
> > +
> > +    context_saved(prev);
> > +
> > + /* TODO
> > +    if (prev != next)
> > +    update_runstate_area(next);
> > + */
> > +
> > +    schedule_tail(next);
> > +    BUG();
> > +
> > +}
> > +
> > +void continue_running(struct vcpu *same)
> > +{
> > +    schedule_tail(same);
> > +    BUG();
> > +}
> > +
> > +int __sync_local_execstate(void)
> > +{
> > +    unsigned long flags;
> > +    int switch_required;
> > +
> > +    local_irq_save(flags);
> > +
> > +    switch_required = (this_cpu(curr_vcpu) != current);
> > +
> > +    if ( switch_required )
> > +    {
> > +        ASSERT(current == idle_vcpu[smp_processor_id()]);
> > +        __context_switch();
> > +    }
> > +
> > +    local_irq_restore(flags);
> > +
> > +    return switch_required;
> > +}
> > +
> > +void sync_local_execstate(void)
> > +{
> > +    (void)__sync_local_execstate();
> > +}
> > +
> > +void startup_cpu_idle_loop(void)
> > +{
> > +        struct vcpu *v = current;
> > +
> > +        ASSERT(is_idle_vcpu(v));
> > +  /* TODO
> > +     cpumask_set_cpu(v->processor, v->domain->domain_dirty_cpumask);
> > +     cpumask_set_cpu(v->processor, v->vcpu_dirty_cpumask);
> > +  */
> > +
> > +        reset_stack_and_jump(idle_loop);
> > +}
> > +
> > +struct domain *alloc_domain_struct(void)
> > +{
> > +    struct domain *d;
> > +    BUILD_BUG_ON(sizeof(*d) > PAGE_SIZE);
> > +    d = alloc_xenheap_pages(0, 0);
> > +    if ( d != NULL )
> > +        clear_page(d);
> > +    return d;
> > +}
> > +
> > +void free_domain_struct(struct domain *d)
> > +{
> > +    free_xenheap_page(d);
> > +}
> > +
> > +void dump_pageframe_info(struct domain *d)
> > +{
> > +
> > +}
> > +
> > +struct vcpu *alloc_vcpu_struct(void)
> > +{
> > +    struct vcpu *v;
> > +    BUILD_BUG_ON(sizeof(*v) > PAGE_SIZE);
> > +    v = alloc_xenheap_pages(0, 0);
> > +    if ( v != NULL )
> > +        clear_page(v);
> > +    return v;
> > +}
> > +
> > +void free_vcpu_struct(struct vcpu *v)
> > +{
> > +    free_xenheap_page(v);
> > +}
> > +
> > +int vcpu_initialise(struct vcpu *v)
> > +{
> > +    int rc = 0;
> > +
> > +    return rc;
> > +}
> > +
> > +void vcpu_destroy(struct vcpu *v)
> > +{
> > +
> > +}
> > +
> > +int arch_domain_create(struct domain *d, unsigned int domcr_flags)
> > +{
> > +    int rc;
> > +
> > +    d->max_vcpus = 8;
> > +
> > +    rc = 0;
> > +fail:
> > +    return rc;
> > +}
> > +
> > +void arch_domain_destroy(struct domain *d)
> > +{
> > +    /* p2m_destroy */
> > +    /* domain_vgic_destroy */
> > +}
> > +
> > +void arch_dump_domain_info(struct domain *d)
> > +{
> > +}
> > +
> > +void arch_dump_vcpu_info(struct vcpu *v)
> > +{
> > +}
> > +
> > +/*
> > + * Local variables:
> > + * mode: C
> > + * c-set-style: "BSD"
> > + * c-basic-offset: 4
> > + * indent-tabs-mode: nil
> > + * End:
> > + */
> > diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
> > new file mode 100644
> > index 0000000..c226bdf
> > --- /dev/null
> > +++ b/xen/include/asm-arm/domain.h
> > @@ -0,0 +1,43 @@
> > +#ifndef __ASM_DOMAIN_H__
> > +#define __ASM_DOMAIN_H__
> > +
> > +#include <xen/config.h>
> > +#include <xen/cache.h>
> > +#include <asm/page.h>
> > +#include <asm/p2m.h>
> > +
> > +struct pending_irq
> > +{
> > +    int irq;
> > +    struct irq_desc *desc; /* only set it the irq corresponds to a physical
> > irq */
> > +    uint8_t priority;
> > +    struct list_head link;
> > +};
> > +
> > +struct arch_domain
> > +{
> > +}  __cacheline_aligned;
> > +
> > +struct arch_vcpu
> > +{
> > +    struct cpu_user_regs user_regs;
> > +
> > +    uint32_t sctlr;
> > +    uint32_t ttbr0, ttbr1, ttbcr;
> > +
> > +}  __cacheline_aligned;
> > +
> > +void vcpu_show_execution_state(struct vcpu *);
> > +void vcpu_show_registers(const struct vcpu *);
> > +
> > +#endif /* __ASM_DOMAIN_H__ */
> > +
> > +/*
> > + * Local variables:
> > + * mode: C
> > + * c-set-style: "BSD"
> > + * c-basic-offset: 4
> > + * tab-width: 4
> > + * indent-tabs-mode: nil
> > + * End:
> > + */
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 13:42:42 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 13: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.xensource.com>)
	id 1RZ0ig-00079L-1y; Fri, 09 Dec 2011 13:42:34 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RZ0ie-000799-Is
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 13:42:32 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1323438103!7560113!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI2MQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30911 invoked from network); 9 Dec 2011 13:41:43 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 13:41:43 -0000
X-IronPort-AV: E=Sophos;i="4.71,326,1320624000"; 
   d="scan'208";a="9384682"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 13:41:42 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 9 Dec 2011
	13:41:43 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Keir Fraser <keir.xen@gmail.com>
Date: Fri, 9 Dec 2011 13:41:42 +0000
In-Reply-To: <CB07BCE9.26E48%keir.xen@gmail.com>
References: <CB07BCE9.26E48%keir.xen@gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323438102.20077.53.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Tim Deegan
	\(3P\)" <Tim.Deegan@citrix.com>, "JBeulich@suse.com" <JBeulich@suse.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v2 12/25] arm: domain
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2011-12-09 at 13:26 +0000, Keir Fraser wrote:
> On 09/12/2011 13:13, "stefano.stabellini@eu.citrix.com"
> <stefano.stabellini@eu.citrix.com> wrote:
> 
> > From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > 
> > Domain creation and destruction, vcpu initialization and destruction,
> > arch specific scheduling functions called by common code.
> 
> It would be nice if xen-arm had per-vcpu stacks (and, optionally, per-cpu
> irq stacks) off the bat. However I won't make it a strict requirement while
> xen-x86 is lagging in this area. That's where you cribbed this logic from
> after all.

I was going to look into this but I've been distracted by other things. 

We did discuss how this would look though -- we expect we will end up
going with per-PCPU page tables (e.g. for per CPU mapcache etc) which
simplifies things in this case as well since we can put per-PCPU stuff
at a fixed VA instead of relying on finding the CPU state info at the
base of the stack (which can be done with per-VCPU stacks but you'd need
to do a bit more book keeping).

Ian.

> 
>  -- Keir
> 
> > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> > Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
> > ---
> >  xen/arch/arm/domain.c        |  253
> > ++++++++++++++++++++++++++++++++++++++++++
> >  xen/include/asm-arm/domain.h |   43 +++++++
> >  2 files changed, 296 insertions(+), 0 deletions(-)
> >  create mode 100644 xen/arch/arm/domain.c
> >  create mode 100644 xen/include/asm-arm/domain.h
> > 
> > diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
> > new file mode 100644
> > index 0000000..d706b5f
> > --- /dev/null
> > +++ b/xen/arch/arm/domain.c
> > @@ -0,0 +1,253 @@
> > +#include <xen/config.h>
> > +#include <xen/init.h>
> > +#include <xen/lib.h>
> > +#include <xen/sched.h>
> > +#include <xen/softirq.h>
> > +#include <xen/wait.h>
> > +#include <xen/errno.h>
> > +
> > +#include <asm/current.h>
> > +#include <asm/regs.h>
> > +#include <asm/p2m.h>
> > +#include <asm/irq.h>
> > +
> > +DEFINE_PER_CPU(struct vcpu *, curr_vcpu);
> > +
> > +static void continue_idle_domain(struct vcpu *v)
> > +{
> > +    reset_stack_and_jump(idle_loop);
> > +}
> > +
> > +static void continue_nonidle_domain(struct vcpu *v)
> > +{
> > +    /* check_wakeup_from_wait(); */
> > +    reset_stack_and_jump(return_from_trap);
> > +}
> > +
> > +void idle_loop(void)
> > +{
> > +    for ( ; ; )
> > +    {
> > +  /* TODO
> > +     if ( cpu_is_offline(smp_processor_id()) )
> > +     play_dead();
> > +     (*pm_idle)();
> > +     BUG();
> > +  */
> > +        do_tasklet();
> > +        do_softirq();
> > +    }
> > +}
> > +
> > +static void ctxt_switch_from(struct vcpu *p)
> > +{
> > +
> > +}
> > +
> > +static void ctxt_switch_to(struct vcpu *n)
> > +{
> > +    p2m_load_VTTBR(n->domain);
> > +}
> > +
> > +static void __context_switch(void)
> > +{
> > +    struct cpu_user_regs *stack_regs = guest_cpu_user_regs();
> > +    unsigned int          cpu = smp_processor_id();
> > +    struct vcpu          *p = per_cpu(curr_vcpu, cpu);
> > +    struct vcpu          *n = current;
> > +
> > +    ASSERT(p != n);
> > +    ASSERT(cpumask_empty(n->vcpu_dirty_cpumask));
> > +
> > +    if ( !is_idle_vcpu(p) )
> > +    {
> > +        memcpy(&p->arch.user_regs, stack_regs, CTXT_SWITCH_STACK_BYTES);
> > +        ctxt_switch_from(p);
> > +    }
> > +
> > +    if ( !is_idle_vcpu(n) )
> > +    {
> > +        memcpy(stack_regs, &n->arch.user_regs, CTXT_SWITCH_STACK_BYTES);
> > +        ctxt_switch_to(n);
> > +    }
> > +
> > +    per_cpu(curr_vcpu, cpu) = n;
> > +
> > +}
> > +
> > +static void schedule_tail(struct vcpu *v)
> > +{
> > +    if ( is_idle_vcpu(v) )
> > +        continue_idle_domain(v);
> > +    else
> > +        continue_nonidle_domain(v);
> > +}
> > +
> > +void context_switch(struct vcpu *prev, struct vcpu *next)
> > +{
> > +    unsigned int cpu = smp_processor_id();
> > +
> > +    ASSERT(local_irq_is_enabled());
> > +
> > +    printk("context switch %d:%d%s -> %d:%d%s\n",
> > +           prev->domain->domain_id, prev->vcpu_id, is_idle_vcpu(prev) ? "
> > (idle)" : "",
> > +           next->domain->domain_id, next->vcpu_id, is_idle_vcpu(next) ? "
> > (idle)" : "");
> > +
> > + /* TODO
> > +    if (prev != next)
> > +    update_runstate_area(prev);
> > + */
> > +
> > +    local_irq_disable();
> > +
> > +    set_current(next);
> > +
> > +    if ( (per_cpu(curr_vcpu, cpu) == next) ||
> > +         (is_idle_vcpu(next) && cpu_online(cpu)) )
> > +    {
> > +        local_irq_enable();
> > +    }
> > +    else
> > +    {
> > +        __context_switch();
> > +
> > +        /* Re-enable interrupts before restoring state which may fault. */
> > +        local_irq_enable();
> > +    }
> > +
> > +    context_saved(prev);
> > +
> > + /* TODO
> > +    if (prev != next)
> > +    update_runstate_area(next);
> > + */
> > +
> > +    schedule_tail(next);
> > +    BUG();
> > +
> > +}
> > +
> > +void continue_running(struct vcpu *same)
> > +{
> > +    schedule_tail(same);
> > +    BUG();
> > +}
> > +
> > +int __sync_local_execstate(void)
> > +{
> > +    unsigned long flags;
> > +    int switch_required;
> > +
> > +    local_irq_save(flags);
> > +
> > +    switch_required = (this_cpu(curr_vcpu) != current);
> > +
> > +    if ( switch_required )
> > +    {
> > +        ASSERT(current == idle_vcpu[smp_processor_id()]);
> > +        __context_switch();
> > +    }
> > +
> > +    local_irq_restore(flags);
> > +
> > +    return switch_required;
> > +}
> > +
> > +void sync_local_execstate(void)
> > +{
> > +    (void)__sync_local_execstate();
> > +}
> > +
> > +void startup_cpu_idle_loop(void)
> > +{
> > +        struct vcpu *v = current;
> > +
> > +        ASSERT(is_idle_vcpu(v));
> > +  /* TODO
> > +     cpumask_set_cpu(v->processor, v->domain->domain_dirty_cpumask);
> > +     cpumask_set_cpu(v->processor, v->vcpu_dirty_cpumask);
> > +  */
> > +
> > +        reset_stack_and_jump(idle_loop);
> > +}
> > +
> > +struct domain *alloc_domain_struct(void)
> > +{
> > +    struct domain *d;
> > +    BUILD_BUG_ON(sizeof(*d) > PAGE_SIZE);
> > +    d = alloc_xenheap_pages(0, 0);
> > +    if ( d != NULL )
> > +        clear_page(d);
> > +    return d;
> > +}
> > +
> > +void free_domain_struct(struct domain *d)
> > +{
> > +    free_xenheap_page(d);
> > +}
> > +
> > +void dump_pageframe_info(struct domain *d)
> > +{
> > +
> > +}
> > +
> > +struct vcpu *alloc_vcpu_struct(void)
> > +{
> > +    struct vcpu *v;
> > +    BUILD_BUG_ON(sizeof(*v) > PAGE_SIZE);
> > +    v = alloc_xenheap_pages(0, 0);
> > +    if ( v != NULL )
> > +        clear_page(v);
> > +    return v;
> > +}
> > +
> > +void free_vcpu_struct(struct vcpu *v)
> > +{
> > +    free_xenheap_page(v);
> > +}
> > +
> > +int vcpu_initialise(struct vcpu *v)
> > +{
> > +    int rc = 0;
> > +
> > +    return rc;
> > +}
> > +
> > +void vcpu_destroy(struct vcpu *v)
> > +{
> > +
> > +}
> > +
> > +int arch_domain_create(struct domain *d, unsigned int domcr_flags)
> > +{
> > +    int rc;
> > +
> > +    d->max_vcpus = 8;
> > +
> > +    rc = 0;
> > +fail:
> > +    return rc;
> > +}
> > +
> > +void arch_domain_destroy(struct domain *d)
> > +{
> > +    /* p2m_destroy */
> > +    /* domain_vgic_destroy */
> > +}
> > +
> > +void arch_dump_domain_info(struct domain *d)
> > +{
> > +}
> > +
> > +void arch_dump_vcpu_info(struct vcpu *v)
> > +{
> > +}
> > +
> > +/*
> > + * Local variables:
> > + * mode: C
> > + * c-set-style: "BSD"
> > + * c-basic-offset: 4
> > + * indent-tabs-mode: nil
> > + * End:
> > + */
> > diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
> > new file mode 100644
> > index 0000000..c226bdf
> > --- /dev/null
> > +++ b/xen/include/asm-arm/domain.h
> > @@ -0,0 +1,43 @@
> > +#ifndef __ASM_DOMAIN_H__
> > +#define __ASM_DOMAIN_H__
> > +
> > +#include <xen/config.h>
> > +#include <xen/cache.h>
> > +#include <asm/page.h>
> > +#include <asm/p2m.h>
> > +
> > +struct pending_irq
> > +{
> > +    int irq;
> > +    struct irq_desc *desc; /* only set it the irq corresponds to a physical
> > irq */
> > +    uint8_t priority;
> > +    struct list_head link;
> > +};
> > +
> > +struct arch_domain
> > +{
> > +}  __cacheline_aligned;
> > +
> > +struct arch_vcpu
> > +{
> > +    struct cpu_user_regs user_regs;
> > +
> > +    uint32_t sctlr;
> > +    uint32_t ttbr0, ttbr1, ttbcr;
> > +
> > +}  __cacheline_aligned;
> > +
> > +void vcpu_show_execution_state(struct vcpu *);
> > +void vcpu_show_registers(const struct vcpu *);
> > +
> > +#endif /* __ASM_DOMAIN_H__ */
> > +
> > +/*
> > + * Local variables:
> > + * mode: C
> > + * c-set-style: "BSD"
> > + * c-basic-offset: 4
> > + * tab-width: 4
> > + * indent-tabs-mode: nil
> > + * End:
> > + */
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 13:46:03 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 13:46:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZ0lv-0007QR-Vj; Fri, 09 Dec 2011 13:45:55 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RZ0lu-0007QA-Dl
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 13:45:54 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-13.tower-182.messagelabs.com!1323438304!6044991!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzMTY1ODU=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzMTY1ODU=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2802 invoked from network); 9 Dec 2011 13:45:05 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-13.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 9 Dec 2011 13:45:05 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1323438304; l=230;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=wt6Qk/Q8Bqgwli9RPFJN0C0mlCM=;
	b=shl0sJyhGZ/tN24YZqD3LdGUs+5tizGXwRkAN/zOM0ogeRuf0WZghbUoXcibCd3QUho
	V3ll4udXHextX2I1yo7y5fob3ksxl9cOsPuUbU/4eFkK3iT2prtciJKhXNPmSSFaTOCUY
	++juhYSAr75uVLDPJ1Oq1z/MGSZmamGKFFE=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lk3c7qEGZD
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-094-126.pools.arcor-ip.net [84.57.94.126])
	by smtp.strato.de (cohen mo27) (RZmta 26.10 AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id k048c2nB9DKFc7 ;
	Fri, 9 Dec 2011 14:44:38 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 35FB418637; Fri,  9 Dec 2011 14:44:37 +0100 (CET)
Date: Fri, 9 Dec 2011 14:44:37 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20111209134436.GA21525@aepfle.de>
References: <1316700889-3518-1-git-send-email-olaf@aepfle.de>
	<1316700889-3518-3-git-send-email-olaf@aepfle.de>
	<1323437589.20077.44.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1323437589.20077.44.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Vincent Hanquez <Vincent.Hanquez@eu.citrix.com>,
	Jon Ludlam <jonathan.ludlam@eu.citrix.com>, Konrad <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH 2/2] xen/pv-on-hvm kexec: add
 xs_reset_watches to shutdown watches from old kernel
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Dec 09, Ian Campbell wrote:

> I suspect it is a bug in the daemon if it doesn't respond with an
> appropriate error for an unknown command. I'll see if I can figure out
> what is going wrong.

Yes, please.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 13:46:03 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 13:46:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZ0lv-0007QR-Vj; Fri, 09 Dec 2011 13:45:55 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RZ0lu-0007QA-Dl
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 13:45:54 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-13.tower-182.messagelabs.com!1323438304!6044991!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzMTY1ODU=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzMTY1ODU=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2802 invoked from network); 9 Dec 2011 13:45:05 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-13.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 9 Dec 2011 13:45:05 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1323438304; l=230;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=wt6Qk/Q8Bqgwli9RPFJN0C0mlCM=;
	b=shl0sJyhGZ/tN24YZqD3LdGUs+5tizGXwRkAN/zOM0ogeRuf0WZghbUoXcibCd3QUho
	V3ll4udXHextX2I1yo7y5fob3ksxl9cOsPuUbU/4eFkK3iT2prtciJKhXNPmSSFaTOCUY
	++juhYSAr75uVLDPJ1Oq1z/MGSZmamGKFFE=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lk3c7qEGZD
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-094-126.pools.arcor-ip.net [84.57.94.126])
	by smtp.strato.de (cohen mo27) (RZmta 26.10 AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id k048c2nB9DKFc7 ;
	Fri, 9 Dec 2011 14:44:38 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 35FB418637; Fri,  9 Dec 2011 14:44:37 +0100 (CET)
Date: Fri, 9 Dec 2011 14:44:37 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20111209134436.GA21525@aepfle.de>
References: <1316700889-3518-1-git-send-email-olaf@aepfle.de>
	<1316700889-3518-3-git-send-email-olaf@aepfle.de>
	<1323437589.20077.44.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1323437589.20077.44.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Vincent Hanquez <Vincent.Hanquez@eu.citrix.com>,
	Jon Ludlam <jonathan.ludlam@eu.citrix.com>, Konrad <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH 2/2] xen/pv-on-hvm kexec: add
 xs_reset_watches to shutdown watches from old kernel
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Dec 09, Ian Campbell wrote:

> I suspect it is a bug in the daemon if it doesn't respond with an
> appropriate error for an unknown command. I'll see if I can figure out
> what is going wrong.

Yes, please.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 14:45:59 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 14:45:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZ1hU-0000Q8-1d; Fri, 09 Dec 2011 14:45:24 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RZ1hS-0000Q3-J9
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 14:45:22 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-16.tower-216.messagelabs.com!1323441810!6724440!1
X-Originating-IP: [208.97.132.145]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNDUgPT4gMTczNjI=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1675 invoked from network); 9 Dec 2011 14:43:31 -0000
Received: from caiajhbdcbef.dreamhost.com (HELO homiemail-a15.g.dreamhost.com)
	(208.97.132.145) by server-16.tower-216.messagelabs.com with SMTP;
	9 Dec 2011 14:43:31 -0000
Received: from homiemail-a15.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a15.g.dreamhost.com (Postfix) with ESMTP id 5CE0676C06F;
	Fri,  9 Dec 2011 06:43:30 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=YW20qoXtTXRWmzRLWerABWIUytAs6b0sSv9AggxJnG3G
	zTMpUFTtghU0Ng1KSlcqiCJUiyjEK4hIilxT6eCsn4UJCCtgkCn9Lvv4yvCsVWyL
	pVPwyZ+fqNnn/bNzQWwy+YUqovLE8fv1FD427Y4mdIiuOoW2HuO0O9IU9zgKEcU=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=capz8n2R4lcNba1gvxM5yz1sj08=; b=OlaMOKg9
	BjqkehN2NE3SBy0uovr9HjvRuPDtXJOxM8Lv12iZI4EwtixVVXeJVTRapMqH0jLA
	kmjQPxZYGxm0gbMM91I4Jke7QaJ30FpeRg15YX6v7NOn5Jh7kKo+2L+wJACBLMEe
	d7I/5XjE56S34tn1Q99l/cTiyNq/7Ynrn/M=
Received: from webmail.lagarcavilla.org (ahfbbjcaiaae.dreamhost.com
	[75.119.208.4]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a15.g.dreamhost.com (Postfix) with ESMTPA id 07D2776C06E; 
	Fri,  9 Dec 2011 06:43:30 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP; Fri, 9 Dec 2011 06:43:30 -0800
Message-ID: <2dfafd590950c8406d6bcbb3f28a135a.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20193.56869.681835.810233@mariner.uk.xensource.com>
References: <patchbomb.1323330435@xdev.gridcentric.ca>
	<24d514cd4dee7d0d0cc9.1323330443@xdev.gridcentric.ca>
	<20193.56869.681835.810233@mariner.uk.xensource.com>
Date: Fri, 9 Dec 2011 06:43:30 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Ian Jackson" <Ian.Jackson@eu.citrix.com>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <ian.campbell@citrix.com>,
	"andres@gridcentric.ca" <andres@gridcentric.ca>,
	"Tim \(Xen.org\)" <tim@xen.org>, "keir.xen@gmail.com" <keir.xen@gmail.com>,
	"JBeulich@suse.com" <jbeulich@suse.com>,
	"adin@gridcentric.ca" <adin@gridcentric.ca>
Subject: Re: [Xen-devel] [PATCH 08 of 18] Tools: Add a sharing command to xl
 for information about shared pages
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> Andres Lagar-Cavilla writes ("[PATCH 08 of 18] Tools: Add a sharing
> command to xl for information about shared pages"):
>> +static void sharing(int totals, const libxl_dominfo *info, int
>> nb_domain)
>> +{
>> +    int i;
>> +
>> +    printf("Name                                        ID   Mem
>> Shared\n");
>> +
>> +    for (i = 0; i < nb_domain; i++) {
>> +        char *domname;
>> +        unsigned shutdown_reason;
>> +        domname = libxl_domid_to_name(ctx, info[i].domid);
>> +        shutdown_reason = info[i].shutdown ? info[i].shutdown_reason :
>> 0;
>> +        printf("%-40s %5d %5lu  %5lu\n",
>> +                domname,
>> +                info[i].domid,
>> +                (unsigned long) (info[i].current_memkb / 1024),
>> +                (unsigned long) (info[i].shared_memkb / 1024));
>> +        free(domname);
>> +    }
>> +
>> +    if (totals)
>> +    {
>> +        /* To be added with a future patch. */
>> +    }
>> +}
>
> Is this analogous to an "xm sharing" command ?
>
> Perhaps we should try to integrate this information in the output of
> "xl list" (although we do have some backward compatibility issues
> there).
>
> Maybe we need to invent "xl llist" or "xl list -v" or something.
I seem to recall that several weeks ago, when Adin first posted this
patch, he was asked to not break xl list compatibility with xm list. Hence
the separate command.

Will also try to add doc to xl.pod.1

Thanks
Andres
>
> Ian.
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 14:45:59 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 14:45:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZ1hU-0000Q8-1d; Fri, 09 Dec 2011 14:45:24 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RZ1hS-0000Q3-J9
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 14:45:22 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-16.tower-216.messagelabs.com!1323441810!6724440!1
X-Originating-IP: [208.97.132.145]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNDUgPT4gMTczNjI=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1675 invoked from network); 9 Dec 2011 14:43:31 -0000
Received: from caiajhbdcbef.dreamhost.com (HELO homiemail-a15.g.dreamhost.com)
	(208.97.132.145) by server-16.tower-216.messagelabs.com with SMTP;
	9 Dec 2011 14:43:31 -0000
Received: from homiemail-a15.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a15.g.dreamhost.com (Postfix) with ESMTP id 5CE0676C06F;
	Fri,  9 Dec 2011 06:43:30 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=YW20qoXtTXRWmzRLWerABWIUytAs6b0sSv9AggxJnG3G
	zTMpUFTtghU0Ng1KSlcqiCJUiyjEK4hIilxT6eCsn4UJCCtgkCn9Lvv4yvCsVWyL
	pVPwyZ+fqNnn/bNzQWwy+YUqovLE8fv1FD427Y4mdIiuOoW2HuO0O9IU9zgKEcU=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=capz8n2R4lcNba1gvxM5yz1sj08=; b=OlaMOKg9
	BjqkehN2NE3SBy0uovr9HjvRuPDtXJOxM8Lv12iZI4EwtixVVXeJVTRapMqH0jLA
	kmjQPxZYGxm0gbMM91I4Jke7QaJ30FpeRg15YX6v7NOn5Jh7kKo+2L+wJACBLMEe
	d7I/5XjE56S34tn1Q99l/cTiyNq/7Ynrn/M=
Received: from webmail.lagarcavilla.org (ahfbbjcaiaae.dreamhost.com
	[75.119.208.4]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a15.g.dreamhost.com (Postfix) with ESMTPA id 07D2776C06E; 
	Fri,  9 Dec 2011 06:43:30 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP; Fri, 9 Dec 2011 06:43:30 -0800
Message-ID: <2dfafd590950c8406d6bcbb3f28a135a.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20193.56869.681835.810233@mariner.uk.xensource.com>
References: <patchbomb.1323330435@xdev.gridcentric.ca>
	<24d514cd4dee7d0d0cc9.1323330443@xdev.gridcentric.ca>
	<20193.56869.681835.810233@mariner.uk.xensource.com>
Date: Fri, 9 Dec 2011 06:43:30 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Ian Jackson" <Ian.Jackson@eu.citrix.com>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <ian.campbell@citrix.com>,
	"andres@gridcentric.ca" <andres@gridcentric.ca>,
	"Tim \(Xen.org\)" <tim@xen.org>, "keir.xen@gmail.com" <keir.xen@gmail.com>,
	"JBeulich@suse.com" <jbeulich@suse.com>,
	"adin@gridcentric.ca" <adin@gridcentric.ca>
Subject: Re: [Xen-devel] [PATCH 08 of 18] Tools: Add a sharing command to xl
 for information about shared pages
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> Andres Lagar-Cavilla writes ("[PATCH 08 of 18] Tools: Add a sharing
> command to xl for information about shared pages"):
>> +static void sharing(int totals, const libxl_dominfo *info, int
>> nb_domain)
>> +{
>> +    int i;
>> +
>> +    printf("Name                                        ID   Mem
>> Shared\n");
>> +
>> +    for (i = 0; i < nb_domain; i++) {
>> +        char *domname;
>> +        unsigned shutdown_reason;
>> +        domname = libxl_domid_to_name(ctx, info[i].domid);
>> +        shutdown_reason = info[i].shutdown ? info[i].shutdown_reason :
>> 0;
>> +        printf("%-40s %5d %5lu  %5lu\n",
>> +                domname,
>> +                info[i].domid,
>> +                (unsigned long) (info[i].current_memkb / 1024),
>> +                (unsigned long) (info[i].shared_memkb / 1024));
>> +        free(domname);
>> +    }
>> +
>> +    if (totals)
>> +    {
>> +        /* To be added with a future patch. */
>> +    }
>> +}
>
> Is this analogous to an "xm sharing" command ?
>
> Perhaps we should try to integrate this information in the output of
> "xl list" (although we do have some backward compatibility issues
> there).
>
> Maybe we need to invent "xl llist" or "xl list -v" or something.
I seem to recall that several weeks ago, when Adin first posted this
patch, he was asked to not break xl list compatibility with xm list. Hence
the separate command.

Will also try to add doc to xl.pod.1

Thanks
Andres
>
> Ian.
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 14:47:41 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 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.xensource.com>)
	id 1RZ1jC-0000Vn-NH; Fri, 09 Dec 2011 14:47:10 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RZ1jB-0000VJ-8H
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 14:47:09 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1323441979!6806761!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI2MQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15297 invoked from network); 9 Dec 2011 14:46:20 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 14:46:20 -0000
X-IronPort-AV: E=Sophos;i="4.71,326,1320624000"; 
   d="scan'208";a="9386609"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 14:46:19 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 14:46:19 +0000
Date: Fri, 9 Dec 2011 14:46:54 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Campbell <ian.campbell@citrix.com>
In-Reply-To: <9c1b223e152eaaa3861f.1323432165@cosworth.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1112091421510.3517@kaball-desktop>
References: <patchbomb.1323432164@cosworth.uk.xensource.com>
	<9c1b223e152eaaa3861f.1323432165@cosworth.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 1 of 2] libxl: fix cold plugged PCI devices
 with stubdomains
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 9 Dec 2011, Ian Campbell wrote:
> # HG changeset patch
> # User Ian Campbell <ian.campbell@citrix.com>
> # Date 1323432076 0
> # Node ID 9c1b223e152eaaa3861f9b6132590de0b4f6cb7e
> # Parent  d8c390192ad1147d7202cf04be090478f1810a5d
> libxl: fix cold plugged PCI devices with stubdomains
> 
> Since 23565:72eafe80ebc1 the xenstore entries for the stubdomain's PCI were
> never created and therefore the stubdom ends up waiting forever for the devices
> which it has been asked to insert to show up.
> 
> Since the stubdomain is already running when we call the libxl_device_pci_add
> loop in do_domain_create we should treat it as if "starting == 0".
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

Acked


> diff -r d8c390192ad1 -r 9c1b223e152e tools/libxl/libxl_pci.c
> --- a/tools/libxl/libxl_pci.c	Thu Dec 08 17:43:29 2011 +0000
> +++ b/tools/libxl/libxl_pci.c	Fri Dec 09 12:01:16 2011 +0000
> @@ -819,7 +819,8 @@ int libxl__device_pci_add(libxl__gc *gc,
>      stubdomid = libxl_get_stubdom_id(ctx, domid);
>      if (stubdomid != 0) {
>          libxl_device_pci pcidev_s = *pcidev;
> -        rc = do_pci_add(gc, stubdomid, &pcidev_s, starting);
> +        /* stubdomain is always running by now, even at create time */
> +        rc = do_pci_add(gc, stubdomid, &pcidev_s, 0);
>          if ( rc )
>              goto out;
>      }
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 14:47:41 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 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.xensource.com>)
	id 1RZ1jC-0000Vn-NH; Fri, 09 Dec 2011 14:47:10 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RZ1jB-0000VJ-8H
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 14:47:09 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1323441979!6806761!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI2MQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15297 invoked from network); 9 Dec 2011 14:46:20 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 14:46:20 -0000
X-IronPort-AV: E=Sophos;i="4.71,326,1320624000"; 
   d="scan'208";a="9386609"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 14:46:19 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 14:46:19 +0000
Date: Fri, 9 Dec 2011 14:46:54 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Campbell <ian.campbell@citrix.com>
In-Reply-To: <9c1b223e152eaaa3861f.1323432165@cosworth.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1112091421510.3517@kaball-desktop>
References: <patchbomb.1323432164@cosworth.uk.xensource.com>
	<9c1b223e152eaaa3861f.1323432165@cosworth.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 1 of 2] libxl: fix cold plugged PCI devices
 with stubdomains
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 9 Dec 2011, Ian Campbell wrote:
> # HG changeset patch
> # User Ian Campbell <ian.campbell@citrix.com>
> # Date 1323432076 0
> # Node ID 9c1b223e152eaaa3861f9b6132590de0b4f6cb7e
> # Parent  d8c390192ad1147d7202cf04be090478f1810a5d
> libxl: fix cold plugged PCI devices with stubdomains
> 
> Since 23565:72eafe80ebc1 the xenstore entries for the stubdomain's PCI were
> never created and therefore the stubdom ends up waiting forever for the devices
> which it has been asked to insert to show up.
> 
> Since the stubdomain is already running when we call the libxl_device_pci_add
> loop in do_domain_create we should treat it as if "starting == 0".
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

Acked


> diff -r d8c390192ad1 -r 9c1b223e152e tools/libxl/libxl_pci.c
> --- a/tools/libxl/libxl_pci.c	Thu Dec 08 17:43:29 2011 +0000
> +++ b/tools/libxl/libxl_pci.c	Fri Dec 09 12:01:16 2011 +0000
> @@ -819,7 +819,8 @@ int libxl__device_pci_add(libxl__gc *gc,
>      stubdomid = libxl_get_stubdom_id(ctx, domid);
>      if (stubdomid != 0) {
>          libxl_device_pci pcidev_s = *pcidev;
> -        rc = do_pci_add(gc, stubdomid, &pcidev_s, starting);
> +        /* stubdomain is always running by now, even at create time */
> +        rc = do_pci_add(gc, stubdomid, &pcidev_s, 0);
>          if ( rc )
>              goto out;
>      }
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 14:48:43 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 14:48:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZ1kF-0000b5-78; Fri, 09 Dec 2011 14:48:15 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RZ1kD-0000aQ-CD
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 14:48:13 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-13.tower-182.messagelabs.com!1323442043!6055041!1
X-Originating-IP: [208.97.132.119]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xMTkgPT4gMTU5NzU=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20783 invoked from network); 9 Dec 2011 14:47:23 -0000
Received: from caiajhbdcbbj.dreamhost.com (HELO homiemail-a15.g.dreamhost.com)
	(208.97.132.119) by server-13.tower-182.messagelabs.com with SMTP;
	9 Dec 2011 14:47:23 -0000
Received: from homiemail-a15.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a15.g.dreamhost.com (Postfix) with ESMTP id 8E50776C072;
	Fri,  9 Dec 2011 06:47:22 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=R5C+q553k0RqG4lmjQ0yQ0Cg8r59mQS3UEiGLwroo/Tq
	rkg2UPkCwo3tr4EsBlywxAIkQH4El4lThr29Ne79rVcA91alJ02YgXLUaoeHOx2y
	/IkcaNFXeyd426kDpQ7WdLVpzkhiqd1qFgzF8sjVetSLH0GarLyESSRY8wa3aPA=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=P1fHW0bH66PeDqRvsIwAGKE78lE=; b=CXbIX/e/
	jRgjFJd3w2tKcOzmrKflmxWwLn1Jn6DtqdKaGogadVBv0+jTJtW+k4qKGBPpdNgM
	3QPFL0jhRDljYIBh7FfD0K7uhOlSVnS4wR8Abd4/QvQVA8uAb/RhdXmzhQhv52T0
	00V2pph7ZF6sFM68S6ozlkJjTHda4eEMY2w=
Received: from webmail.lagarcavilla.org (ahfbbjcaiaae.dreamhost.com
	[75.119.208.4]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a15.g.dreamhost.com (Postfix) with ESMTPA id ED10276C06E; 
	Fri,  9 Dec 2011 06:47:21 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP; Fri, 9 Dec 2011 06:47:22 -0800
Message-ID: <2f291a598c94b8734e5cfebd1cbf3fdf.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <CB077497.26D84%keir.xen@gmail.com>
References: <CB077497.26D84%keir.xen@gmail.com>
Date: Fri, 9 Dec 2011 06:47:22 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Keir Fraser" <keir.xen@gmail.com>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, ian.campbell@citrix.com,
	andres@gridcentric.ca, Tim Deegan <tim@xen.org>,
	jbeulich@suse.com, ian.jackson@citrix.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 12 of 18] x86/mm: Make page_lock/unlock() in
 arch/x86/mm.c externally callable
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> On 09/12/2011 03:01, "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
> wrote:
>
>>> On 08/12/2011 22:38, "Tim Deegan" <tim@xen.org> wrote:
>>>
>>>> At 02:47 -0500 on 08 Dec (1323312447), Andres Lagar-Cavilla wrote:
>>>>> This is necessary for a new consumer of page_lock/unlock to follow in
>>>>> the series.
>>>>>
>>>>> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
>>>>
>>>> Nak, I'm afraid.
>>>>
>>>> These were OK as local functions but if they're going to be made
>>>> generally visible, they need clear comments describing what this
>>>> locking protects and what the discipline is for avoiding deadlocks.
>>>>
>>>> Perhaps Jan or Keir can supply appropriate words.  The locking was
>>>> introduce in this cset:
>>>
>>> It's Jan's work originally, but the basic intention of page_lock is to
>>> serialise pte updates. To aid with this, a page's type cannot change
>>> while
>>> its lock is held.
>> That's definitely a property I want to leverage.
>>
>>> No lock nests inside a page lock (not even other page
>>> locks) so there is no deadlock risk.
>> There's no way to not nest when sharing two pages, but I always make
>> sure
>> I lock in ascending order.
>
> The fact there is currently no nesting gives you some freedom. Ordered
> locking of other page locks is obviously going to be safe. So is taking a
> page lock inside any other lock. Taking some other lock inside a page lock
> is all that needs care, but there probably aren't many locks that
> currently
> can have page locks nested inside them (and hence you would risk deadlock
> by
> nesting the other way).
For now, p2m_lock will be taken inside page_lock, to type p2m entries or
make them point to the shared page. Later, when p2m lookups become
synchronized, p2m_lock (or similar) will be taken before page_lock, in
get_gfn* -- and that will be better.

Either way, I will use mm-locks.h to make sure that if there is any chance
of deadlock the hypervisor screams.

Thanks
Andres
>
>  -- Keir
>
>> Thanks,
>> Andres
>>>
>>>>     changeset:   17846:09dd5999401b
>>>>     user:        Keir Fraser <keir.fraser@citrix.com>
>>>>     date:        Thu Jun 12 18:14:00 2008 +0100
>>>>     files:       xen/arch/x86/domain.c xen/arch/x86/domain_build.c
>>>>     xen/arch/x86/mm.c
>>>>     description:
>>>>     x86: remove use of per-domain lock from page table entry handling
>>>>
>>>>     This change results in a 5% performance improvement for kernel
>>>> builds
>>>>     on dual-socket quad-core systems (which is what I used for
>>>> reference
>>>>     for both 32- and 64-bit). Along with that, the amount of time
>>>> reported
>>>>     as spent in the kernel gets reduced by almost 25% (the fraction of
>>>>     time spent in the kernel is generally reported significantly
>>>> higher
>>>>     under Xen than with a native kernel).
>>>>
>>>>     Signed-off-by: Jan Beulich <jbeulich@novell.com>
>>>>     Signed-off-by: Keir Fraser <keir.fraser@citrix.com>
>>>>
>>>> Tim.
>>>
>>>
>>>
>>
>>
>
>
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 14:48:43 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 14:48:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZ1kF-0000b5-78; Fri, 09 Dec 2011 14:48:15 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RZ1kD-0000aQ-CD
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 14:48:13 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-13.tower-182.messagelabs.com!1323442043!6055041!1
X-Originating-IP: [208.97.132.119]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xMTkgPT4gMTU5NzU=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20783 invoked from network); 9 Dec 2011 14:47:23 -0000
Received: from caiajhbdcbbj.dreamhost.com (HELO homiemail-a15.g.dreamhost.com)
	(208.97.132.119) by server-13.tower-182.messagelabs.com with SMTP;
	9 Dec 2011 14:47:23 -0000
Received: from homiemail-a15.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a15.g.dreamhost.com (Postfix) with ESMTP id 8E50776C072;
	Fri,  9 Dec 2011 06:47:22 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=R5C+q553k0RqG4lmjQ0yQ0Cg8r59mQS3UEiGLwroo/Tq
	rkg2UPkCwo3tr4EsBlywxAIkQH4El4lThr29Ne79rVcA91alJ02YgXLUaoeHOx2y
	/IkcaNFXeyd426kDpQ7WdLVpzkhiqd1qFgzF8sjVetSLH0GarLyESSRY8wa3aPA=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=P1fHW0bH66PeDqRvsIwAGKE78lE=; b=CXbIX/e/
	jRgjFJd3w2tKcOzmrKflmxWwLn1Jn6DtqdKaGogadVBv0+jTJtW+k4qKGBPpdNgM
	3QPFL0jhRDljYIBh7FfD0K7uhOlSVnS4wR8Abd4/QvQVA8uAb/RhdXmzhQhv52T0
	00V2pph7ZF6sFM68S6ozlkJjTHda4eEMY2w=
Received: from webmail.lagarcavilla.org (ahfbbjcaiaae.dreamhost.com
	[75.119.208.4]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a15.g.dreamhost.com (Postfix) with ESMTPA id ED10276C06E; 
	Fri,  9 Dec 2011 06:47:21 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP; Fri, 9 Dec 2011 06:47:22 -0800
Message-ID: <2f291a598c94b8734e5cfebd1cbf3fdf.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <CB077497.26D84%keir.xen@gmail.com>
References: <CB077497.26D84%keir.xen@gmail.com>
Date: Fri, 9 Dec 2011 06:47:22 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Keir Fraser" <keir.xen@gmail.com>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, ian.campbell@citrix.com,
	andres@gridcentric.ca, Tim Deegan <tim@xen.org>,
	jbeulich@suse.com, ian.jackson@citrix.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 12 of 18] x86/mm: Make page_lock/unlock() in
 arch/x86/mm.c externally callable
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> On 09/12/2011 03:01, "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
> wrote:
>
>>> On 08/12/2011 22:38, "Tim Deegan" <tim@xen.org> wrote:
>>>
>>>> At 02:47 -0500 on 08 Dec (1323312447), Andres Lagar-Cavilla wrote:
>>>>> This is necessary for a new consumer of page_lock/unlock to follow in
>>>>> the series.
>>>>>
>>>>> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
>>>>
>>>> Nak, I'm afraid.
>>>>
>>>> These were OK as local functions but if they're going to be made
>>>> generally visible, they need clear comments describing what this
>>>> locking protects and what the discipline is for avoiding deadlocks.
>>>>
>>>> Perhaps Jan or Keir can supply appropriate words.  The locking was
>>>> introduce in this cset:
>>>
>>> It's Jan's work originally, but the basic intention of page_lock is to
>>> serialise pte updates. To aid with this, a page's type cannot change
>>> while
>>> its lock is held.
>> That's definitely a property I want to leverage.
>>
>>> No lock nests inside a page lock (not even other page
>>> locks) so there is no deadlock risk.
>> There's no way to not nest when sharing two pages, but I always make
>> sure
>> I lock in ascending order.
>
> The fact there is currently no nesting gives you some freedom. Ordered
> locking of other page locks is obviously going to be safe. So is taking a
> page lock inside any other lock. Taking some other lock inside a page lock
> is all that needs care, but there probably aren't many locks that
> currently
> can have page locks nested inside them (and hence you would risk deadlock
> by
> nesting the other way).
For now, p2m_lock will be taken inside page_lock, to type p2m entries or
make them point to the shared page. Later, when p2m lookups become
synchronized, p2m_lock (or similar) will be taken before page_lock, in
get_gfn* -- and that will be better.

Either way, I will use mm-locks.h to make sure that if there is any chance
of deadlock the hypervisor screams.

Thanks
Andres
>
>  -- Keir
>
>> Thanks,
>> Andres
>>>
>>>>     changeset:   17846:09dd5999401b
>>>>     user:        Keir Fraser <keir.fraser@citrix.com>
>>>>     date:        Thu Jun 12 18:14:00 2008 +0100
>>>>     files:       xen/arch/x86/domain.c xen/arch/x86/domain_build.c
>>>>     xen/arch/x86/mm.c
>>>>     description:
>>>>     x86: remove use of per-domain lock from page table entry handling
>>>>
>>>>     This change results in a 5% performance improvement for kernel
>>>> builds
>>>>     on dual-socket quad-core systems (which is what I used for
>>>> reference
>>>>     for both 32- and 64-bit). Along with that, the amount of time
>>>> reported
>>>>     as spent in the kernel gets reduced by almost 25% (the fraction of
>>>>     time spent in the kernel is generally reported significantly
>>>> higher
>>>>     under Xen than with a native kernel).
>>>>
>>>>     Signed-off-by: Jan Beulich <jbeulich@novell.com>
>>>>     Signed-off-by: Keir Fraser <keir.fraser@citrix.com>
>>>>
>>>> Tim.
>>>
>>>
>>>
>>
>>
>
>
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 14:55:06 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 14:55:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZ1qV-0000vO-2N; Fri, 09 Dec 2011 14:54:43 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RZ1qT-0000vI-Di
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 14:54:41 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-9.tower-216.messagelabs.com!1323442431!6845500!1
X-Originating-IP: [208.97.132.66]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi42NiA9PiAxNTY0OQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30061 invoked from network); 9 Dec 2011 14:53:51 -0000
Received: from caiajhbdcagg.dreamhost.com (HELO homiemail-a22.g.dreamhost.com)
	(208.97.132.66) by server-9.tower-216.messagelabs.com with SMTP;
	9 Dec 2011 14:53:51 -0000
Received: from homiemail-a22.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a22.g.dreamhost.com (Postfix) with ESMTP id E68EE1A808D;
	Fri,  9 Dec 2011 06:53:49 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=rlxY4dIzxIBTV7gKUj8RiHKOLj+4v7h3JuZp+exGB5o7
	EKuDrK7WL8lxX27cen9HjMFSZTte44eDPcCRd6SVXJnqRIN56vBBkgJa8oYQoz6Q
	yvlRhBz+ltYTJozQNQgYgrZsG55Xk3qCE+f2ZWbul0nCIC5pJuCFANCoSEF69c8=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=qyC+cIIAsKZTVBPytIZJEkEDYjU=; b=Z5FwDNAQ
	rNjUR2zkDTyExJd1OGiRmF031goDpuOysNajJrvG5cLCDA/l21wg8Ab7yvsUNzNX
	oLfyodEQin4Pc1UJetC9xdOpFNgXK+SYsbi7wszZlgiPLfRD4+n2bsB/J72iBgXu
	gdvps8980sM8MpJErnxsJZ3MTLkz5oed3ac=
Received: from webmail.lagarcavilla.org (ahfbbjcaiaae.dreamhost.com
	[75.119.208.4]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a22.g.dreamhost.com (Postfix) with ESMTPA id 9A28B1A8089; 
	Fri,  9 Dec 2011 06:53:49 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP; Fri, 9 Dec 2011 06:53:49 -0800
Message-ID: <5721d3b3ef44aac4f864ea6a62e9c835.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <4EE1DA1B020000780006663E@nat28.tlf.novell.com>
References: <patchbomb.1323330435@xdev.gridcentric.ca>
	<ecf95feef9ac5a7d0b79.1323330447@xdev.gridcentric.ca>
	<20111208223822.GH87836@ocelot.phlegethon.org>
	<cba5ca07476cc5619c84113b26325886.squirrel@webmail.lagarcavilla.org>
	<4EE1DA1B020000780006663E@nat28.tlf.novell.com>
Date: Fri, 9 Dec 2011 06:53:49 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Jan Beulich" <JBeulich@suse.com>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, ian.campbell@citrix.com,
	andres@gridcentric.ca, Tim Deegan <tim@xen.org>,
	keir.xen@gmail.com, ian.jackson@citrix.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 12 of 18] x86/mm: Make page_lock/unlock() in
 arch/x86/mm.c externally callable
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>>> On 09.12.11 at 03:54, "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
>>>> wrote:
>>>  At 02:47 -0500 on 08 Dec (1323312447), Andres Lagar-Cavilla wrote:
>>>> This is necessary for a new consumer of page_lock/unlock to follow in
>>>> the series.
>>>>
>>>> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
>>>
>>> Nak, I'm afraid.
>>>
>>> These were OK as local functions but if they're going to be made
>>> generally visible, they need clear comments describing what this
>>> locking protects and what the discipline is for avoiding deadlocks.
>>
>> How about something along the lines of
>> "page_lock() is used for two purposes: pte serialization, and memory
>> sharing. All users of page lock for pte serialization live in mm.c, use
>> it
>> to lock a page table page during pte updates, do not take other locks
>> within the critical section delimited by page_lock/unlock, and perform
>> no
>> nesting. All users of page lock for memory sharing live in
>> mm/mem_sharing.c. For memory sharing, nesting may happen when sharing
>> (and
>> locking) two pages -- deadlock is avoided by locking pages in increasing
>> order. Memory sharing may take the p2m_lock within a page_lock/unlock
>> critical section. These two users (pte serialization and memory sharing)
>> should never collide, as long as page table pages are properly unshared
>> prior to updating."
>
> This would seem to me like very undesirable lock ordering - a very
> coarse (per-domain) lock taken inside a very fine grained (per-page)
> one.
I'm not sure I follow. Unshare would do its work, and then pte
serialization would start. The two pieces of code will be disjoint,
locking-wise.

Now it is true that during unshare we need to take the p2m lock to change
the p2m entry. That's a very strong reason to make the p2m lock
fine-grained. But I need to start somewhere, so I'm breaking up the global
shr_lock first.

>
>> Now those are all pretty words, but here are the two things I (think I)
>> need to do:
>> - Prior to updating pte's, we do get_gfn on the page table page. We
>> should
>> be using get_gfn_unshare. Regardless of this patch. It's likely never
>> going to trigger an actual unshare, yet better safe than sorry.
>
> Does memory sharing work on pv domains at all?
Not. At. All :)

I can _not_ add the unshare. It's idempotent to pv.

>
>> - I can wrap uses of page_lock in mm sharing in an "external"
>> order-enforcing construct from mm-locks.h. And use that to scream
>> deadlock
>> between page_lock and p2m_lock.
>>
>> The code that actually uses page_lock()s in the memory sharing code can
>> be
>> found in "[PATCH] x86/mm: Eliminate global lock in mem sharing code". It
>> already orders locking of individual pages in ascending order.
>
> It should be this patch to make the functions externally visible, not a
> separate one (or at the very minimum the two ought to be in the same
> series, back to back). Which is not to say that I'm fully convinced this
> is a good idea.
Whichever you prefer. I'm of the mind of making shorter patches when
possible, that do one thing, to ease readability. But I can collapse the
two.

Thanks
Andres
>
> Jan
>
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 14:55:06 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 14:55:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZ1qV-0000vO-2N; Fri, 09 Dec 2011 14:54:43 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RZ1qT-0000vI-Di
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 14:54:41 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-9.tower-216.messagelabs.com!1323442431!6845500!1
X-Originating-IP: [208.97.132.66]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi42NiA9PiAxNTY0OQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30061 invoked from network); 9 Dec 2011 14:53:51 -0000
Received: from caiajhbdcagg.dreamhost.com (HELO homiemail-a22.g.dreamhost.com)
	(208.97.132.66) by server-9.tower-216.messagelabs.com with SMTP;
	9 Dec 2011 14:53:51 -0000
Received: from homiemail-a22.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a22.g.dreamhost.com (Postfix) with ESMTP id E68EE1A808D;
	Fri,  9 Dec 2011 06:53:49 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=rlxY4dIzxIBTV7gKUj8RiHKOLj+4v7h3JuZp+exGB5o7
	EKuDrK7WL8lxX27cen9HjMFSZTte44eDPcCRd6SVXJnqRIN56vBBkgJa8oYQoz6Q
	yvlRhBz+ltYTJozQNQgYgrZsG55Xk3qCE+f2ZWbul0nCIC5pJuCFANCoSEF69c8=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=qyC+cIIAsKZTVBPytIZJEkEDYjU=; b=Z5FwDNAQ
	rNjUR2zkDTyExJd1OGiRmF031goDpuOysNajJrvG5cLCDA/l21wg8Ab7yvsUNzNX
	oLfyodEQin4Pc1UJetC9xdOpFNgXK+SYsbi7wszZlgiPLfRD4+n2bsB/J72iBgXu
	gdvps8980sM8MpJErnxsJZ3MTLkz5oed3ac=
Received: from webmail.lagarcavilla.org (ahfbbjcaiaae.dreamhost.com
	[75.119.208.4]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a22.g.dreamhost.com (Postfix) with ESMTPA id 9A28B1A8089; 
	Fri,  9 Dec 2011 06:53:49 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP; Fri, 9 Dec 2011 06:53:49 -0800
Message-ID: <5721d3b3ef44aac4f864ea6a62e9c835.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <4EE1DA1B020000780006663E@nat28.tlf.novell.com>
References: <patchbomb.1323330435@xdev.gridcentric.ca>
	<ecf95feef9ac5a7d0b79.1323330447@xdev.gridcentric.ca>
	<20111208223822.GH87836@ocelot.phlegethon.org>
	<cba5ca07476cc5619c84113b26325886.squirrel@webmail.lagarcavilla.org>
	<4EE1DA1B020000780006663E@nat28.tlf.novell.com>
Date: Fri, 9 Dec 2011 06:53:49 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Jan Beulich" <JBeulich@suse.com>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, ian.campbell@citrix.com,
	andres@gridcentric.ca, Tim Deegan <tim@xen.org>,
	keir.xen@gmail.com, ian.jackson@citrix.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 12 of 18] x86/mm: Make page_lock/unlock() in
 arch/x86/mm.c externally callable
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>>> On 09.12.11 at 03:54, "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
>>>> wrote:
>>>  At 02:47 -0500 on 08 Dec (1323312447), Andres Lagar-Cavilla wrote:
>>>> This is necessary for a new consumer of page_lock/unlock to follow in
>>>> the series.
>>>>
>>>> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
>>>
>>> Nak, I'm afraid.
>>>
>>> These were OK as local functions but if they're going to be made
>>> generally visible, they need clear comments describing what this
>>> locking protects and what the discipline is for avoiding deadlocks.
>>
>> How about something along the lines of
>> "page_lock() is used for two purposes: pte serialization, and memory
>> sharing. All users of page lock for pte serialization live in mm.c, use
>> it
>> to lock a page table page during pte updates, do not take other locks
>> within the critical section delimited by page_lock/unlock, and perform
>> no
>> nesting. All users of page lock for memory sharing live in
>> mm/mem_sharing.c. For memory sharing, nesting may happen when sharing
>> (and
>> locking) two pages -- deadlock is avoided by locking pages in increasing
>> order. Memory sharing may take the p2m_lock within a page_lock/unlock
>> critical section. These two users (pte serialization and memory sharing)
>> should never collide, as long as page table pages are properly unshared
>> prior to updating."
>
> This would seem to me like very undesirable lock ordering - a very
> coarse (per-domain) lock taken inside a very fine grained (per-page)
> one.
I'm not sure I follow. Unshare would do its work, and then pte
serialization would start. The two pieces of code will be disjoint,
locking-wise.

Now it is true that during unshare we need to take the p2m lock to change
the p2m entry. That's a very strong reason to make the p2m lock
fine-grained. But I need to start somewhere, so I'm breaking up the global
shr_lock first.

>
>> Now those are all pretty words, but here are the two things I (think I)
>> need to do:
>> - Prior to updating pte's, we do get_gfn on the page table page. We
>> should
>> be using get_gfn_unshare. Regardless of this patch. It's likely never
>> going to trigger an actual unshare, yet better safe than sorry.
>
> Does memory sharing work on pv domains at all?
Not. At. All :)

I can _not_ add the unshare. It's idempotent to pv.

>
>> - I can wrap uses of page_lock in mm sharing in an "external"
>> order-enforcing construct from mm-locks.h. And use that to scream
>> deadlock
>> between page_lock and p2m_lock.
>>
>> The code that actually uses page_lock()s in the memory sharing code can
>> be
>> found in "[PATCH] x86/mm: Eliminate global lock in mem sharing code". It
>> already orders locking of individual pages in ascending order.
>
> It should be this patch to make the functions externally visible, not a
> separate one (or at the very minimum the two ought to be in the same
> series, back to back). Which is not to say that I'm fully convinced this
> is a good idea.
Whichever you prefer. I'm of the mind of making shorter patches when
possible, that do one thing, to ease readability. But I can collapse the
two.

Thanks
Andres
>
> Jan
>
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 14:58:34 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 14:58:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZ1td-00011q-MO; Fri, 09 Dec 2011 14:57:57 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RZ1tc-00011g-QQ
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 14:57:57 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-15.tower-21.messagelabs.com!1323442626!7580524!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2022 invoked from network); 9 Dec 2011 14:57:07 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-15.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 9 Dec 2011 14:57:07 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RZ1sm-0008u4-D6; Fri, 09 Dec 2011 14:57:04 +0000
Date: Fri, 9 Dec 2011 14:57:04 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20111209145704.GJ87836@ocelot.phlegethon.org>
References: <patchbomb.1323330435@xdev.gridcentric.ca>
	<ecf95feef9ac5a7d0b79.1323330447@xdev.gridcentric.ca>
	<20111208223822.GH87836@ocelot.phlegethon.org>
	<cba5ca07476cc5619c84113b26325886.squirrel@webmail.lagarcavilla.org>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <cba5ca07476cc5619c84113b26325886.squirrel@webmail.lagarcavilla.org>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com, ian.campbell@citrix.com,
	andres@gridcentric.ca, keir.xen@gmail.com, jbeulich@suse.com,
	ian.jackson@citrix.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 12 of 18] x86/mm: Make page_lock/unlock() in
	arch/x86/mm.c externally callable
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 18:54 -0800 on 08 Dec (1323370449), Andres Lagar-Cavilla wrote:
> > At 02:47 -0500 on 08 Dec (1323312447), Andres Lagar-Cavilla wrote:
> >> This is necessary for a new consumer of page_lock/unlock to follow in
> >> the series.
> >>
> >> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
> >
> > Nak, I'm afraid.
> >
> > These were OK as local functions but if they're going to be made
> > generally visible, they need clear comments describing what this
> > locking protects and what the discipline is for avoiding deadlocks.
> 
> How about something along the lines of
> "page_lock() is used for two purposes: pte serialization, and memory
> sharing. All users of page lock for pte serialization live in mm.c, use it
> to lock a page table page during pte updates, do not take other locks
> within the critical section delimited by page_lock/unlock, and perform no
> nesting. All users of page lock for memory sharing live in
> mm/mem_sharing.c. For memory sharing, nesting may happen when sharing (and
> locking) two pages -- deadlock is avoided by locking pages in increasing
> order. Memory sharing may take the p2m_lock within a page_lock/unlock
> critical section. These two users (pte serialization and memory sharing)
> should never collide, as long as page table pages are properly unshared
> prior to updating."

Thanks.  Extracting from that and from Keir's response: 

It serves both as a spinlock and to exclude any to the page-type of the
page in question (by causing the get_page_type() functions to spin).

What it currently protects is all modifications to pages that have
pagetable type.  This serialises PV PTE validations, both against other
validations of the same PTE and against concurrent changes of the
enclosing page's type.

Your planned use is to protect updates to the page-sharing state
associated with a page.  Can you be clear about what exactly is protected?

The proposed locking discipline is that
- page locks must be taken in increasing order of MFN, yes?  
- and that you must always take page locks before the p2m lock?

Is that about right?

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 14:58:34 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 14:58:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZ1td-00011q-MO; Fri, 09 Dec 2011 14:57:57 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RZ1tc-00011g-QQ
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 14:57:57 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-15.tower-21.messagelabs.com!1323442626!7580524!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2022 invoked from network); 9 Dec 2011 14:57:07 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-15.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 9 Dec 2011 14:57:07 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RZ1sm-0008u4-D6; Fri, 09 Dec 2011 14:57:04 +0000
Date: Fri, 9 Dec 2011 14:57:04 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20111209145704.GJ87836@ocelot.phlegethon.org>
References: <patchbomb.1323330435@xdev.gridcentric.ca>
	<ecf95feef9ac5a7d0b79.1323330447@xdev.gridcentric.ca>
	<20111208223822.GH87836@ocelot.phlegethon.org>
	<cba5ca07476cc5619c84113b26325886.squirrel@webmail.lagarcavilla.org>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <cba5ca07476cc5619c84113b26325886.squirrel@webmail.lagarcavilla.org>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com, ian.campbell@citrix.com,
	andres@gridcentric.ca, keir.xen@gmail.com, jbeulich@suse.com,
	ian.jackson@citrix.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 12 of 18] x86/mm: Make page_lock/unlock() in
	arch/x86/mm.c externally callable
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 18:54 -0800 on 08 Dec (1323370449), Andres Lagar-Cavilla wrote:
> > At 02:47 -0500 on 08 Dec (1323312447), Andres Lagar-Cavilla wrote:
> >> This is necessary for a new consumer of page_lock/unlock to follow in
> >> the series.
> >>
> >> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
> >
> > Nak, I'm afraid.
> >
> > These were OK as local functions but if they're going to be made
> > generally visible, they need clear comments describing what this
> > locking protects and what the discipline is for avoiding deadlocks.
> 
> How about something along the lines of
> "page_lock() is used for two purposes: pte serialization, and memory
> sharing. All users of page lock for pte serialization live in mm.c, use it
> to lock a page table page during pte updates, do not take other locks
> within the critical section delimited by page_lock/unlock, and perform no
> nesting. All users of page lock for memory sharing live in
> mm/mem_sharing.c. For memory sharing, nesting may happen when sharing (and
> locking) two pages -- deadlock is avoided by locking pages in increasing
> order. Memory sharing may take the p2m_lock within a page_lock/unlock
> critical section. These two users (pte serialization and memory sharing)
> should never collide, as long as page table pages are properly unshared
> prior to updating."

Thanks.  Extracting from that and from Keir's response: 

It serves both as a spinlock and to exclude any to the page-type of the
page in question (by causing the get_page_type() functions to spin).

What it currently protects is all modifications to pages that have
pagetable type.  This serialises PV PTE validations, both against other
validations of the same PTE and against concurrent changes of the
enclosing page's type.

Your planned use is to protect updates to the page-sharing state
associated with a page.  Can you be clear about what exactly is protected?

The proposed locking discipline is that
- page locks must be taken in increasing order of MFN, yes?  
- and that you must always take page locks before the p2m lock?

Is that about right?

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 15:00:16 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 15:00:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZ1ve-0001Bi-9W; Fri, 09 Dec 2011 15:00:02 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RZ1vc-00019O-Ge
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 15:00:00 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-11.tower-216.messagelabs.com!1323442750!6767372!1
X-Originating-IP: [208.97.132.177]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNzcgPT4gMTQyMDg=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6753 invoked from network); 9 Dec 2011 14:59:10 -0000
Received: from caiajhbdcbhh.dreamhost.com (HELO homiemail-a21.g.dreamhost.com)
	(208.97.132.177) by server-11.tower-216.messagelabs.com with SMTP;
	9 Dec 2011 14:59:10 -0000
Received: from homiemail-a21.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTP id 92AB7300074;
	Fri,  9 Dec 2011 06:59:09 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=lrrQg9igIuGdpH1obDyB+Di0C3pEUn7VeiGJw6bCMjcm
	sFz64u/NvcwbujAfnu6jgwYpZQkmTk9G/UKmcfs7FfZ3IR67KdT9Y5QQOcL62tS/
	HG2BGVNrdwfOQACnNvc/NXMrJaW4aLswGF2KttqYZd4wen8/aBFOyaNYNVmds8w=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=5+1SOmhqpnmX0CA5b7xVLbM15J4=; b=MXgMT9hr
	8Fcp1/wgBDC0caLFTLtez3xR9tQDFh1QGqlrbV79goOD/SRAH+ZdMAhhaNfhOaz2
	PuLL+Ts1dKBR+ec5luxduzP73XDsrTi8hMvE1cZ+kjZtkJhC5fAhrrXZB5Q0ZAuD
	p50veUotviyosGskvWzvQQKxxgaoprvlkxY=
Received: from webmail.lagarcavilla.org (ahfbbjcaiaae.dreamhost.com
	[75.119.208.4]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTPA id BE6E2300064; 
	Fri,  9 Dec 2011 06:59:08 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP; Fri, 9 Dec 2011 06:59:09 -0800
Message-ID: <37c124e690c6dc7371c4ee98ea2dcfd3.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20111209145704.GJ87836@ocelot.phlegethon.org>
References: <patchbomb.1323330435@xdev.gridcentric.ca>
	<ecf95feef9ac5a7d0b79.1323330447@xdev.gridcentric.ca>
	<20111208223822.GH87836@ocelot.phlegethon.org>
	<cba5ca07476cc5619c84113b26325886.squirrel@webmail.lagarcavilla.org>
	<20111209145704.GJ87836@ocelot.phlegethon.org>
Date: Fri, 9 Dec 2011 06:59:09 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Tim Deegan" <tim@xen.org>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, ian.campbell@citrix.com,
	andres@gridcentric.ca, keir.xen@gmail.com, jbeulich@suse.com,
	ian.jackson@citrix.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 12 of 18] x86/mm: Make page_lock/unlock() in
 arch/x86/mm.c externally callable
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> At 18:54 -0800 on 08 Dec (1323370449), Andres Lagar-Cavilla wrote:
>> > At 02:47 -0500 on 08 Dec (1323312447), Andres Lagar-Cavilla wrote:
>> >> This is necessary for a new consumer of page_lock/unlock to follow in
>> >> the series.
>> >>
>> >> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
>> >
>> > Nak, I'm afraid.
>> >
>> > These were OK as local functions but if they're going to be made
>> > generally visible, they need clear comments describing what this
>> > locking protects and what the discipline is for avoiding deadlocks.
>>
>> How about something along the lines of
>> "page_lock() is used for two purposes: pte serialization, and memory
>> sharing. All users of page lock for pte serialization live in mm.c, use
>> it
>> to lock a page table page during pte updates, do not take other locks
>> within the critical section delimited by page_lock/unlock, and perform
>> no
>> nesting. All users of page lock for memory sharing live in
>> mm/mem_sharing.c. For memory sharing, nesting may happen when sharing
>> (and
>> locking) two pages -- deadlock is avoided by locking pages in increasing
>> order. Memory sharing may take the p2m_lock within a page_lock/unlock
>> critical section. These two users (pte serialization and memory sharing)
>> should never collide, as long as page table pages are properly unshared
>> prior to updating."
>
> Thanks.  Extracting from that and from Keir's response:
>
> It serves both as a spinlock and to exclude any to the page-type of the
> page in question (by causing the get_page_type() functions to spin).
>
> What it currently protects is all modifications to pages that have
> pagetable type.  This serialises PV PTE validations, both against other
> validations of the same PTE and against concurrent changes of the
> enclosing page's type.
>
> Your planned use is to protect updates to the page-sharing state
> associated with a page.  Can you be clear about what exactly is protected?
"Hanging" from a shared page, there is a list of all the gfn's it backs.
These are (gfn,domain) tuples. So every time we share or unshare, we need
protected access to that list.

>
> The proposed locking discipline is that
> - page locks must be taken in increasing order of MFN, yes?
> - and that you must always take page locks before the p2m lock?
Yes and yes
>
> Is that about right?
Indeed

Thanks
Andres
>
> Tim.
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 15:00:16 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 15:00:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZ1ve-0001Bi-9W; Fri, 09 Dec 2011 15:00:02 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RZ1vc-00019O-Ge
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 15:00:00 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-11.tower-216.messagelabs.com!1323442750!6767372!1
X-Originating-IP: [208.97.132.177]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNzcgPT4gMTQyMDg=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6753 invoked from network); 9 Dec 2011 14:59:10 -0000
Received: from caiajhbdcbhh.dreamhost.com (HELO homiemail-a21.g.dreamhost.com)
	(208.97.132.177) by server-11.tower-216.messagelabs.com with SMTP;
	9 Dec 2011 14:59:10 -0000
Received: from homiemail-a21.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTP id 92AB7300074;
	Fri,  9 Dec 2011 06:59:09 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=lrrQg9igIuGdpH1obDyB+Di0C3pEUn7VeiGJw6bCMjcm
	sFz64u/NvcwbujAfnu6jgwYpZQkmTk9G/UKmcfs7FfZ3IR67KdT9Y5QQOcL62tS/
	HG2BGVNrdwfOQACnNvc/NXMrJaW4aLswGF2KttqYZd4wen8/aBFOyaNYNVmds8w=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=5+1SOmhqpnmX0CA5b7xVLbM15J4=; b=MXgMT9hr
	8Fcp1/wgBDC0caLFTLtez3xR9tQDFh1QGqlrbV79goOD/SRAH+ZdMAhhaNfhOaz2
	PuLL+Ts1dKBR+ec5luxduzP73XDsrTi8hMvE1cZ+kjZtkJhC5fAhrrXZB5Q0ZAuD
	p50veUotviyosGskvWzvQQKxxgaoprvlkxY=
Received: from webmail.lagarcavilla.org (ahfbbjcaiaae.dreamhost.com
	[75.119.208.4]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTPA id BE6E2300064; 
	Fri,  9 Dec 2011 06:59:08 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP; Fri, 9 Dec 2011 06:59:09 -0800
Message-ID: <37c124e690c6dc7371c4ee98ea2dcfd3.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20111209145704.GJ87836@ocelot.phlegethon.org>
References: <patchbomb.1323330435@xdev.gridcentric.ca>
	<ecf95feef9ac5a7d0b79.1323330447@xdev.gridcentric.ca>
	<20111208223822.GH87836@ocelot.phlegethon.org>
	<cba5ca07476cc5619c84113b26325886.squirrel@webmail.lagarcavilla.org>
	<20111209145704.GJ87836@ocelot.phlegethon.org>
Date: Fri, 9 Dec 2011 06:59:09 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Tim Deegan" <tim@xen.org>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, ian.campbell@citrix.com,
	andres@gridcentric.ca, keir.xen@gmail.com, jbeulich@suse.com,
	ian.jackson@citrix.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 12 of 18] x86/mm: Make page_lock/unlock() in
 arch/x86/mm.c externally callable
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> At 18:54 -0800 on 08 Dec (1323370449), Andres Lagar-Cavilla wrote:
>> > At 02:47 -0500 on 08 Dec (1323312447), Andres Lagar-Cavilla wrote:
>> >> This is necessary for a new consumer of page_lock/unlock to follow in
>> >> the series.
>> >>
>> >> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
>> >
>> > Nak, I'm afraid.
>> >
>> > These were OK as local functions but if they're going to be made
>> > generally visible, they need clear comments describing what this
>> > locking protects and what the discipline is for avoiding deadlocks.
>>
>> How about something along the lines of
>> "page_lock() is used for two purposes: pte serialization, and memory
>> sharing. All users of page lock for pte serialization live in mm.c, use
>> it
>> to lock a page table page during pte updates, do not take other locks
>> within the critical section delimited by page_lock/unlock, and perform
>> no
>> nesting. All users of page lock for memory sharing live in
>> mm/mem_sharing.c. For memory sharing, nesting may happen when sharing
>> (and
>> locking) two pages -- deadlock is avoided by locking pages in increasing
>> order. Memory sharing may take the p2m_lock within a page_lock/unlock
>> critical section. These two users (pte serialization and memory sharing)
>> should never collide, as long as page table pages are properly unshared
>> prior to updating."
>
> Thanks.  Extracting from that and from Keir's response:
>
> It serves both as a spinlock and to exclude any to the page-type of the
> page in question (by causing the get_page_type() functions to spin).
>
> What it currently protects is all modifications to pages that have
> pagetable type.  This serialises PV PTE validations, both against other
> validations of the same PTE and against concurrent changes of the
> enclosing page's type.
>
> Your planned use is to protect updates to the page-sharing state
> associated with a page.  Can you be clear about what exactly is protected?
"Hanging" from a shared page, there is a list of all the gfn's it backs.
These are (gfn,domain) tuples. So every time we share or unshare, we need
protected access to that list.

>
> The proposed locking discipline is that
> - page locks must be taken in increasing order of MFN, yes?
> - and that you must always take page locks before the p2m lock?
Yes and yes
>
> Is that about right?
Indeed

Thanks
Andres
>
> Tim.
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 15:07:08 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 15: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.xensource.com>)
	id 1RZ22F-0001Vz-5G; Fri, 09 Dec 2011 15:06:51 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RZ22D-0001Vo-F0
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 15:06:49 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1323443157!4927919!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9384 invoked from network); 9 Dec 2011 15:05:57 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-10.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 9 Dec 2011 15:05:57 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 09 Dec 2011 15:05:56 +0000
Message-Id: <4EE2320F020000780006687F@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 09 Dec 2011 15:06:39 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: <andres@lagarcavilla.org>
References: <patchbomb.1323330435@xdev.gridcentric.ca>
	<ecf95feef9ac5a7d0b79.1323330447@xdev.gridcentric.ca>
	<20111208223822.GH87836@ocelot.phlegethon.org>
	<cba5ca07476cc5619c84113b26325886.squirrel@webmail.lagarcavilla.org>
	<4EE1DA1B020000780006663E@nat28.tlf.novell.com>
	<5721d3b3ef44aac4f864ea6a62e9c835.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <5721d3b3ef44aac4f864ea6a62e9c835.squirrel@webmail.lagarcavilla.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com, ian.campbell@citrix.com,
	andres@gridcentric.ca, Tim Deegan <tim@xen.org>,
	keir.xen@gmail.com, ian.jackson@citrix.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 12 of 18] x86/mm: Make page_lock/unlock() in
 arch/x86/mm.c externally callable
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 09.12.11 at 15:53, "Andres Lagar-Cavilla" <andres@lagarcavilla.org> wrote:
>>>>> On 09.12.11 at 03:54, "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
>>>>> wrote:
>>>>  At 02:47 -0500 on 08 Dec (1323312447), Andres Lagar-Cavilla wrote:
>>>>> This is necessary for a new consumer of page_lock/unlock to follow in
>>>>> the series.
>>>>>
>>>>> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
>>>>
>>>> Nak, I'm afraid.
>>>>
>>>> These were OK as local functions but if they're going to be made
>>>> generally visible, they need clear comments describing what this
>>>> locking protects and what the discipline is for avoiding deadlocks.
>>>
>>> How about something along the lines of
>>> "page_lock() is used for two purposes: pte serialization, and memory
>>> sharing. All users of page lock for pte serialization live in mm.c, use
>>> it
>>> to lock a page table page during pte updates, do not take other locks
>>> within the critical section delimited by page_lock/unlock, and perform
>>> no
>>> nesting. All users of page lock for memory sharing live in
>>> mm/mem_sharing.c. For memory sharing, nesting may happen when sharing
>>> (and
>>> locking) two pages -- deadlock is avoided by locking pages in increasing
>>> order. Memory sharing may take the p2m_lock within a page_lock/unlock
>>> critical section. These two users (pte serialization and memory sharing)
>>> should never collide, as long as page table pages are properly unshared
>>> prior to updating."
>>
>> This would seem to me like very undesirable lock ordering - a very
>> coarse (per-domain) lock taken inside a very fine grained (per-page)
>> one.
> I'm not sure I follow. Unshare would do its work, and then pte
> serialization would start. The two pieces of code will be disjoint,
> locking-wise.

But your original mail said "Memory sharing may take the p2m_lock
within a page_lock/unlock critical section" - see above. That's what
I'm referring to.

> Now it is true that during unshare we need to take the p2m lock to change
> the p2m entry. That's a very strong reason to make the p2m lock
> fine-grained. But I need to start somewhere, so I'm breaking up the global
> shr_lock first.

I don't really think that it'll be reasonable to split up the p2m lock.

>>> Now those are all pretty words, but here are the two things I (think I)
>>> need to do:
>>> - Prior to updating pte's, we do get_gfn on the page table page. We
>>> should
>>> be using get_gfn_unshare. Regardless of this patch. It's likely never
>>> going to trigger an actual unshare, yet better safe than sorry.
>>
>> Does memory sharing work on pv domains at all?
> Not. At. All :)
> 
> I can _not_ add the unshare. It's idempotent to pv.

Perhaps I should have clarified why I was asking: The pte handling is
a pv-only thing, and if memory sharing is hvm only, then the two can't
ever conflict.

>>> - I can wrap uses of page_lock in mm sharing in an "external"
>>> order-enforcing construct from mm-locks.h. And use that to scream
>>> deadlock
>>> between page_lock and p2m_lock.
>>>
>>> The code that actually uses page_lock()s in the memory sharing code can
>>> be
>>> found in "[PATCH] x86/mm: Eliminate global lock in mem sharing code". It
>>> already orders locking of individual pages in ascending order.
>>
>> It should be this patch to make the functions externally visible, not a
>> separate one (or at the very minimum the two ought to be in the same
>> series, back to back). Which is not to say that I'm fully convinced this
>> is a good idea.
> Whichever you prefer. I'm of the mind of making shorter patches when
> possible, that do one thing, to ease readability. But I can collapse the
> two.

In quite a few (recent) cases your patches did something where the user
of the change wasn't obvious at all (in some cases - I tried to point these
out - there was no user even at the end of a series). While I agree that
shorter patches are easier to review, trivial changes like the one here
should imo really be logically grouped with what requires them.

Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 15:07:08 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 15: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.xensource.com>)
	id 1RZ22F-0001Vz-5G; Fri, 09 Dec 2011 15:06:51 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RZ22D-0001Vo-F0
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 15:06:49 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1323443157!4927919!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9384 invoked from network); 9 Dec 2011 15:05:57 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-10.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 9 Dec 2011 15:05:57 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 09 Dec 2011 15:05:56 +0000
Message-Id: <4EE2320F020000780006687F@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 09 Dec 2011 15:06:39 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: <andres@lagarcavilla.org>
References: <patchbomb.1323330435@xdev.gridcentric.ca>
	<ecf95feef9ac5a7d0b79.1323330447@xdev.gridcentric.ca>
	<20111208223822.GH87836@ocelot.phlegethon.org>
	<cba5ca07476cc5619c84113b26325886.squirrel@webmail.lagarcavilla.org>
	<4EE1DA1B020000780006663E@nat28.tlf.novell.com>
	<5721d3b3ef44aac4f864ea6a62e9c835.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <5721d3b3ef44aac4f864ea6a62e9c835.squirrel@webmail.lagarcavilla.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com, ian.campbell@citrix.com,
	andres@gridcentric.ca, Tim Deegan <tim@xen.org>,
	keir.xen@gmail.com, ian.jackson@citrix.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 12 of 18] x86/mm: Make page_lock/unlock() in
 arch/x86/mm.c externally callable
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 09.12.11 at 15:53, "Andres Lagar-Cavilla" <andres@lagarcavilla.org> wrote:
>>>>> On 09.12.11 at 03:54, "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
>>>>> wrote:
>>>>  At 02:47 -0500 on 08 Dec (1323312447), Andres Lagar-Cavilla wrote:
>>>>> This is necessary for a new consumer of page_lock/unlock to follow in
>>>>> the series.
>>>>>
>>>>> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
>>>>
>>>> Nak, I'm afraid.
>>>>
>>>> These were OK as local functions but if they're going to be made
>>>> generally visible, they need clear comments describing what this
>>>> locking protects and what the discipline is for avoiding deadlocks.
>>>
>>> How about something along the lines of
>>> "page_lock() is used for two purposes: pte serialization, and memory
>>> sharing. All users of page lock for pte serialization live in mm.c, use
>>> it
>>> to lock a page table page during pte updates, do not take other locks
>>> within the critical section delimited by page_lock/unlock, and perform
>>> no
>>> nesting. All users of page lock for memory sharing live in
>>> mm/mem_sharing.c. For memory sharing, nesting may happen when sharing
>>> (and
>>> locking) two pages -- deadlock is avoided by locking pages in increasing
>>> order. Memory sharing may take the p2m_lock within a page_lock/unlock
>>> critical section. These two users (pte serialization and memory sharing)
>>> should never collide, as long as page table pages are properly unshared
>>> prior to updating."
>>
>> This would seem to me like very undesirable lock ordering - a very
>> coarse (per-domain) lock taken inside a very fine grained (per-page)
>> one.
> I'm not sure I follow. Unshare would do its work, and then pte
> serialization would start. The two pieces of code will be disjoint,
> locking-wise.

But your original mail said "Memory sharing may take the p2m_lock
within a page_lock/unlock critical section" - see above. That's what
I'm referring to.

> Now it is true that during unshare we need to take the p2m lock to change
> the p2m entry. That's a very strong reason to make the p2m lock
> fine-grained. But I need to start somewhere, so I'm breaking up the global
> shr_lock first.

I don't really think that it'll be reasonable to split up the p2m lock.

>>> Now those are all pretty words, but here are the two things I (think I)
>>> need to do:
>>> - Prior to updating pte's, we do get_gfn on the page table page. We
>>> should
>>> be using get_gfn_unshare. Regardless of this patch. It's likely never
>>> going to trigger an actual unshare, yet better safe than sorry.
>>
>> Does memory sharing work on pv domains at all?
> Not. At. All :)
> 
> I can _not_ add the unshare. It's idempotent to pv.

Perhaps I should have clarified why I was asking: The pte handling is
a pv-only thing, and if memory sharing is hvm only, then the two can't
ever conflict.

>>> - I can wrap uses of page_lock in mm sharing in an "external"
>>> order-enforcing construct from mm-locks.h. And use that to scream
>>> deadlock
>>> between page_lock and p2m_lock.
>>>
>>> The code that actually uses page_lock()s in the memory sharing code can
>>> be
>>> found in "[PATCH] x86/mm: Eliminate global lock in mem sharing code". It
>>> already orders locking of individual pages in ascending order.
>>
>> It should be this patch to make the functions externally visible, not a
>> separate one (or at the very minimum the two ought to be in the same
>> series, back to back). Which is not to say that I'm fully convinced this
>> is a good idea.
> Whichever you prefer. I'm of the mind of making shorter patches when
> possible, that do one thing, to ease readability. But I can collapse the
> two.

In quite a few (recent) cases your patches did something where the user
of the change wasn't obvious at all (in some cases - I tried to point these
out - there was no user even at the end of a series). While I agree that
shorter patches are easier to review, trivial changes like the one here
should imo really be logically grouped with what requires them.

Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 15:11:33 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 15:11:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZ26W-0001gg-1b; Fri, 09 Dec 2011 15:11:16 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RZ26U-0001gX-NG
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 15:11:14 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1323443424!4927675!1
X-Originating-IP: [209.85.214.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24520 invoked from network); 9 Dec 2011 15:10:24 -0000
Received: from mail-bw0-f43.google.com (HELO mail-bw0-f43.google.com)
	(209.85.214.43)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 15:10:24 -0000
Received: by bkbzs2 with SMTP id zs2so8932813bkb.30
	for <xen-devel@lists.xensource.com>;
	Fri, 09 Dec 2011 07:10:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=oFaK6YXJ8tHd9ZrRLSH4d8KI6nPU1VXAvoNfLyf989M=;
	b=DUfg1UdG1bkNFYU4bRtzjNXqp4J1ehJRsmvvADE91w5P7IEAjkciyEQN7TY1c6Zh4m
	8yJDZSNahLgTUdNQekM8DfsuUJfbkrFnIxmZ+lUuyl6XnSvuM2nJZJSVf22bchxVC104
	pTXXvqon0Y1DXfxZXjjUO6lmafy4rnSVRppaw=
Received: by 10.204.130.85 with SMTP id r21mr3928876bks.38.1323442943831;
	Fri, 09 Dec 2011 07:02:23 -0800 (PST)
Received: from [192.168.1.3] (host81-155-119-104.range81-155.btcentralplus.com.
	[81.155.119.104])
	by mx.google.com with ESMTPS id jf4sm10419564bkc.5.2011.12.09.07.02.21
	(version=SSLv3 cipher=OTHER); Fri, 09 Dec 2011 07:02:23 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Fri, 09 Dec 2011 15:02:21 +0000
From: Keir Fraser <keir@xen.org>
To: Tim Deegan <tim@xen.org>,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <CB07D37D.35959%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH 12 of 18] x86/mm: Make page_lock/unlock() in
	arch/x86/mm.c externally callable
Thread-Index: Acy2g40I5NTjnRXLbkuljKjD63UL2Q==
In-Reply-To: <20111209145704.GJ87836@ocelot.phlegethon.org>
Mime-version: 1.0
Cc: xen-devel@lists.xensource.com, ian.campbell@citrix.com,
	andres@gridcentric.ca, keir.xen@gmail.com, jbeulich@suse.com,
	ian.jackson@citrix.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 12 of 18] x86/mm: Make page_lock/unlock() in
 arch/x86/mm.c externally callable
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 09/12/2011 14:57, "Tim Deegan" <tim@xen.org> wrote:

> At 18:54 -0800 on 08 Dec (1323370449), Andres Lagar-Cavilla wrote:
>>> At 02:47 -0500 on 08 Dec (1323312447), Andres Lagar-Cavilla wrote:
>>>> This is necessary for a new consumer of page_lock/unlock to follow in
>>>> the series.
>>>> 
>>>> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
>>> 
>>> Nak, I'm afraid.
>>> 
>>> These were OK as local functions but if they're going to be made
>>> generally visible, they need clear comments describing what this
>>> locking protects and what the discipline is for avoiding deadlocks.
>> 
>> How about something along the lines of
>> "page_lock() is used for two purposes: pte serialization, and memory
>> sharing. All users of page lock for pte serialization live in mm.c, use it
>> to lock a page table page during pte updates, do not take other locks
>> within the critical section delimited by page_lock/unlock, and perform no
>> nesting. All users of page lock for memory sharing live in
>> mm/mem_sharing.c. For memory sharing, nesting may happen when sharing (and
>> locking) two pages -- deadlock is avoided by locking pages in increasing
>> order. Memory sharing may take the p2m_lock within a page_lock/unlock
>> critical section. These two users (pte serialization and memory sharing)
>> should never collide, as long as page table pages are properly unshared
>> prior to updating."
> 
> Thanks.  Extracting from that and from Keir's response:
> 
> It serves both as a spinlock and to exclude any to the page-type of the
> page in question (by causing the get_page_type() functions to spin).

It does not cause the get_page_type() functions to spin. An attempt to get
another reference to the current type will succeed; an attempt to change the
type will immediately fail. From the p.o.v. of the type-tracking logic,
page_lock() simply takes a reference to the current type.

 -- Keir

> What it currently protects is all modifications to pages that have
> pagetable type.  This serialises PV PTE validations, both against other
> validations of the same PTE and against concurrent changes of the
> enclosing page's type.
> 
> Your planned use is to protect updates to the page-sharing state
> associated with a page.  Can you be clear about what exactly is protected?
> 
> The proposed locking discipline is that
> - page locks must be taken in increasing order of MFN, yes?
> - and that you must always take page locks before the p2m lock?
> 
> Is that about right?
> 
> Tim.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 15:11:33 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 15:11:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZ26W-0001gg-1b; Fri, 09 Dec 2011 15:11:16 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RZ26U-0001gX-NG
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 15:11:14 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1323443424!4927675!1
X-Originating-IP: [209.85.214.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24520 invoked from network); 9 Dec 2011 15:10:24 -0000
Received: from mail-bw0-f43.google.com (HELO mail-bw0-f43.google.com)
	(209.85.214.43)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 15:10:24 -0000
Received: by bkbzs2 with SMTP id zs2so8932813bkb.30
	for <xen-devel@lists.xensource.com>;
	Fri, 09 Dec 2011 07:10:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=oFaK6YXJ8tHd9ZrRLSH4d8KI6nPU1VXAvoNfLyf989M=;
	b=DUfg1UdG1bkNFYU4bRtzjNXqp4J1ehJRsmvvADE91w5P7IEAjkciyEQN7TY1c6Zh4m
	8yJDZSNahLgTUdNQekM8DfsuUJfbkrFnIxmZ+lUuyl6XnSvuM2nJZJSVf22bchxVC104
	pTXXvqon0Y1DXfxZXjjUO6lmafy4rnSVRppaw=
Received: by 10.204.130.85 with SMTP id r21mr3928876bks.38.1323442943831;
	Fri, 09 Dec 2011 07:02:23 -0800 (PST)
Received: from [192.168.1.3] (host81-155-119-104.range81-155.btcentralplus.com.
	[81.155.119.104])
	by mx.google.com with ESMTPS id jf4sm10419564bkc.5.2011.12.09.07.02.21
	(version=SSLv3 cipher=OTHER); Fri, 09 Dec 2011 07:02:23 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Fri, 09 Dec 2011 15:02:21 +0000
From: Keir Fraser <keir@xen.org>
To: Tim Deegan <tim@xen.org>,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <CB07D37D.35959%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH 12 of 18] x86/mm: Make page_lock/unlock() in
	arch/x86/mm.c externally callable
Thread-Index: Acy2g40I5NTjnRXLbkuljKjD63UL2Q==
In-Reply-To: <20111209145704.GJ87836@ocelot.phlegethon.org>
Mime-version: 1.0
Cc: xen-devel@lists.xensource.com, ian.campbell@citrix.com,
	andres@gridcentric.ca, keir.xen@gmail.com, jbeulich@suse.com,
	ian.jackson@citrix.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 12 of 18] x86/mm: Make page_lock/unlock() in
 arch/x86/mm.c externally callable
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 09/12/2011 14:57, "Tim Deegan" <tim@xen.org> wrote:

> At 18:54 -0800 on 08 Dec (1323370449), Andres Lagar-Cavilla wrote:
>>> At 02:47 -0500 on 08 Dec (1323312447), Andres Lagar-Cavilla wrote:
>>>> This is necessary for a new consumer of page_lock/unlock to follow in
>>>> the series.
>>>> 
>>>> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
>>> 
>>> Nak, I'm afraid.
>>> 
>>> These were OK as local functions but if they're going to be made
>>> generally visible, they need clear comments describing what this
>>> locking protects and what the discipline is for avoiding deadlocks.
>> 
>> How about something along the lines of
>> "page_lock() is used for two purposes: pte serialization, and memory
>> sharing. All users of page lock for pte serialization live in mm.c, use it
>> to lock a page table page during pte updates, do not take other locks
>> within the critical section delimited by page_lock/unlock, and perform no
>> nesting. All users of page lock for memory sharing live in
>> mm/mem_sharing.c. For memory sharing, nesting may happen when sharing (and
>> locking) two pages -- deadlock is avoided by locking pages in increasing
>> order. Memory sharing may take the p2m_lock within a page_lock/unlock
>> critical section. These two users (pte serialization and memory sharing)
>> should never collide, as long as page table pages are properly unshared
>> prior to updating."
> 
> Thanks.  Extracting from that and from Keir's response:
> 
> It serves both as a spinlock and to exclude any to the page-type of the
> page in question (by causing the get_page_type() functions to spin).

It does not cause the get_page_type() functions to spin. An attempt to get
another reference to the current type will succeed; an attempt to change the
type will immediately fail. From the p.o.v. of the type-tracking logic,
page_lock() simply takes a reference to the current type.

 -- Keir

> What it currently protects is all modifications to pages that have
> pagetable type.  This serialises PV PTE validations, both against other
> validations of the same PTE and against concurrent changes of the
> enclosing page's type.
> 
> Your planned use is to protect updates to the page-sharing state
> associated with a page.  Can you be clear about what exactly is protected?
> 
> The proposed locking discipline is that
> - page locks must be taken in increasing order of MFN, yes?
> - and that you must always take page locks before the p2m lock?
> 
> Is that about right?
> 
> Tim.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 15:12:33 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 15:12:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZ27X-0001kj-GG; Fri, 09 Dec 2011 15:12:19 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RZ27V-0001k6-J8
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 15:12:17 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1323443487!4744752!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8124 invoked from network); 9 Dec 2011 15:11:27 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-16.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 9 Dec 2011 15:11:27 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 09 Dec 2011 15:11:27 +0000
Message-Id: <4EE2335A020000780006688C@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 09 Dec 2011 15:12:10 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
References: <alpine.DEB.2.00.1112091208420.3517@kaball-desktop>
	<1323436408-16335-6-git-send-email-stefano.stabellini@eu.citrix.com>
	<4EE21C4602000078000667AA@nat28.tlf.novell.com>
	<1323438026.20077.51.camel@zakaz.uk.xensource.com>
In-Reply-To: <1323438026.20077.51.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"keir.xen@gmail.com" <keir.xen@gmail.com>,
	"Tim Deegan \(3P\)" <Tim.Deegan@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v2 06/25] libelf-loader: introduce
	elf_load_image
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 09.12.11 at 14:40, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Fri, 2011-12-09 at 13:33 +0000, Jan Beulich wrote:
>> >>> On 09.12.11 at 14:13, <stefano.stabellini@eu.citrix.com> wrote:
>> > Implement a new function, called elf_load_image, to perform the actually
>> > copy of the elf image and clearing the padding.
>> > The function is implemented as memcpy and memset when the library is
>> > built as part of the tools, but it is implemented as copy_to_user and
>> > clear_user when built as part of Xen, so that it can be safely called
>> > with an HVM style dom0.
>> 
>> I meant to ask this on the first round already, but apparently forgot:
>> What is it that prevents memcpy()/memset() from being used for a
>> HVM style Dom0? {clear,copy_to}_user() still expect the guest memory
>> to be visible in the hypervisor's virtual address space - how could a
>> fault happen here? And if you have to take precautions for a fault,
>> shouldn't the calling code check the respective return values?
> 
> HVM guest memory is not (necessarily) mapped in the hypervisor page
> tables, it needs to be mapped on demand. Also the source/target (delete
> as appropriate) is a guest virtual address so even if the RAM happened
> to be mapped it would (likely) not be in the same place so at a minimum
> we need to translate things.
> 
> This is what copy_{to,from}_user does for an HVM guest even on X86,
> where copy_to_user becomes copy_to_user_hvm as appropriate. 

But that's not true - the distinction of hvm vs pv is at the
copy_to_guest() layer (raw_copy_to_guest() in the x86 case). So
maybe the patch meant to use those interfaces (and then we'd need
a clear_guest() too, which should also have been obvious by the fact
that the prior patch only introduced clear_user(), but no hvm variant
of it)?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 15:12:33 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 15:12:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZ27X-0001kj-GG; Fri, 09 Dec 2011 15:12:19 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RZ27V-0001k6-J8
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 15:12:17 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1323443487!4744752!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8124 invoked from network); 9 Dec 2011 15:11:27 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-16.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 9 Dec 2011 15:11:27 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 09 Dec 2011 15:11:27 +0000
Message-Id: <4EE2335A020000780006688C@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 09 Dec 2011 15:12:10 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
References: <alpine.DEB.2.00.1112091208420.3517@kaball-desktop>
	<1323436408-16335-6-git-send-email-stefano.stabellini@eu.citrix.com>
	<4EE21C4602000078000667AA@nat28.tlf.novell.com>
	<1323438026.20077.51.camel@zakaz.uk.xensource.com>
In-Reply-To: <1323438026.20077.51.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"keir.xen@gmail.com" <keir.xen@gmail.com>,
	"Tim Deegan \(3P\)" <Tim.Deegan@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v2 06/25] libelf-loader: introduce
	elf_load_image
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 09.12.11 at 14:40, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Fri, 2011-12-09 at 13:33 +0000, Jan Beulich wrote:
>> >>> On 09.12.11 at 14:13, <stefano.stabellini@eu.citrix.com> wrote:
>> > Implement a new function, called elf_load_image, to perform the actually
>> > copy of the elf image and clearing the padding.
>> > The function is implemented as memcpy and memset when the library is
>> > built as part of the tools, but it is implemented as copy_to_user and
>> > clear_user when built as part of Xen, so that it can be safely called
>> > with an HVM style dom0.
>> 
>> I meant to ask this on the first round already, but apparently forgot:
>> What is it that prevents memcpy()/memset() from being used for a
>> HVM style Dom0? {clear,copy_to}_user() still expect the guest memory
>> to be visible in the hypervisor's virtual address space - how could a
>> fault happen here? And if you have to take precautions for a fault,
>> shouldn't the calling code check the respective return values?
> 
> HVM guest memory is not (necessarily) mapped in the hypervisor page
> tables, it needs to be mapped on demand. Also the source/target (delete
> as appropriate) is a guest virtual address so even if the RAM happened
> to be mapped it would (likely) not be in the same place so at a minimum
> we need to translate things.
> 
> This is what copy_{to,from}_user does for an HVM guest even on X86,
> where copy_to_user becomes copy_to_user_hvm as appropriate. 

But that's not true - the distinction of hvm vs pv is at the
copy_to_guest() layer (raw_copy_to_guest() in the x86 case). So
maybe the patch meant to use those interfaces (and then we'd need
a clear_guest() too, which should also have been obvious by the fact
that the prior patch only introduced clear_user(), but no hvm variant
of it)?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 15:25:02 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 15:25:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZ2JW-00025V-QX; Fri, 09 Dec 2011 15:24:42 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RZ2JV-00025P-HW
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 15:24:41 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1323444231!7401047!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI2MQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22049 invoked from network); 9 Dec 2011 15:23:52 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 15:23:52 -0000
X-IronPort-AV: E=Sophos;i="4.71,326,1320624000"; 
   d="scan'208";a="9387909"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 15:23:52 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 9 Dec 2011
	15:23:52 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Fri, 9 Dec 2011 15:23:51 +0000
In-Reply-To: <4EE2335A020000780006688C@nat28.tlf.novell.com>
References: <alpine.DEB.2.00.1112091208420.3517@kaball-desktop>
	<1323436408-16335-6-git-send-email-stefano.stabellini@eu.citrix.com>
	<4EE21C4602000078000667AA@nat28.tlf.novell.com>
	<1323438026.20077.51.camel@zakaz.uk.xensource.com>
	<4EE2335A020000780006688C@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323444231.20077.72.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"keir.xen@gmail.com" <keir.xen@gmail.com>,
	"Tim Deegan \(3P\)" <Tim.Deegan@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v2 06/25] libelf-loader: introduce
	elf_load_image
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2011-12-09 at 15:12 +0000, Jan Beulich wrote:
> >>> On 09.12.11 at 14:40, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > On Fri, 2011-12-09 at 13:33 +0000, Jan Beulich wrote:
> >> >>> On 09.12.11 at 14:13, <stefano.stabellini@eu.citrix.com> wrote:
> >> > Implement a new function, called elf_load_image, to perform the actually
> >> > copy of the elf image and clearing the padding.
> >> > The function is implemented as memcpy and memset when the library is
> >> > built as part of the tools, but it is implemented as copy_to_user and
> >> > clear_user when built as part of Xen, so that it can be safely called
> >> > with an HVM style dom0.
> >> 
> >> I meant to ask this on the first round already, but apparently forgot:
> >> What is it that prevents memcpy()/memset() from being used for a
> >> HVM style Dom0? {clear,copy_to}_user() still expect the guest memory
> >> to be visible in the hypervisor's virtual address space - how could a
> >> fault happen here? And if you have to take precautions for a fault,
> >> shouldn't the calling code check the respective return values?
> > 
> > HVM guest memory is not (necessarily) mapped in the hypervisor page
> > tables, it needs to be mapped on demand. Also the source/target (delete
> > as appropriate) is a guest virtual address so even if the RAM happened
> > to be mapped it would (likely) not be in the same place so at a minimum
> > we need to translate things.
> > 
> > This is what copy_{to,from}_user does for an HVM guest even on X86,
> > where copy_to_user becomes copy_to_user_hvm as appropriate. 
> 
> But that's not true - the distinction of hvm vs pv is at the
> copy_to_guest() layer (raw_copy_to_guest() in the x86 case). So
> maybe the patch meant to use those interfaces (and then we'd need
> a clear_guest() too, which should also have been obvious by the fact
> that the prior patch only introduced clear_user(), but no hvm variant
> of it)?

This code is also compiled in userspace which doesn't have copy_to_user
and in that case we need to use memcpy.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 15:25:02 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 15:25:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZ2JW-00025V-QX; Fri, 09 Dec 2011 15:24:42 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RZ2JV-00025P-HW
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 15:24:41 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1323444231!7401047!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI2MQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22049 invoked from network); 9 Dec 2011 15:23:52 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 15:23:52 -0000
X-IronPort-AV: E=Sophos;i="4.71,326,1320624000"; 
   d="scan'208";a="9387909"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 15:23:52 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 9 Dec 2011
	15:23:52 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Fri, 9 Dec 2011 15:23:51 +0000
In-Reply-To: <4EE2335A020000780006688C@nat28.tlf.novell.com>
References: <alpine.DEB.2.00.1112091208420.3517@kaball-desktop>
	<1323436408-16335-6-git-send-email-stefano.stabellini@eu.citrix.com>
	<4EE21C4602000078000667AA@nat28.tlf.novell.com>
	<1323438026.20077.51.camel@zakaz.uk.xensource.com>
	<4EE2335A020000780006688C@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323444231.20077.72.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"keir.xen@gmail.com" <keir.xen@gmail.com>,
	"Tim Deegan \(3P\)" <Tim.Deegan@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v2 06/25] libelf-loader: introduce
	elf_load_image
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2011-12-09 at 15:12 +0000, Jan Beulich wrote:
> >>> On 09.12.11 at 14:40, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > On Fri, 2011-12-09 at 13:33 +0000, Jan Beulich wrote:
> >> >>> On 09.12.11 at 14:13, <stefano.stabellini@eu.citrix.com> wrote:
> >> > Implement a new function, called elf_load_image, to perform the actually
> >> > copy of the elf image and clearing the padding.
> >> > The function is implemented as memcpy and memset when the library is
> >> > built as part of the tools, but it is implemented as copy_to_user and
> >> > clear_user when built as part of Xen, so that it can be safely called
> >> > with an HVM style dom0.
> >> 
> >> I meant to ask this on the first round already, but apparently forgot:
> >> What is it that prevents memcpy()/memset() from being used for a
> >> HVM style Dom0? {clear,copy_to}_user() still expect the guest memory
> >> to be visible in the hypervisor's virtual address space - how could a
> >> fault happen here? And if you have to take precautions for a fault,
> >> shouldn't the calling code check the respective return values?
> > 
> > HVM guest memory is not (necessarily) mapped in the hypervisor page
> > tables, it needs to be mapped on demand. Also the source/target (delete
> > as appropriate) is a guest virtual address so even if the RAM happened
> > to be mapped it would (likely) not be in the same place so at a minimum
> > we need to translate things.
> > 
> > This is what copy_{to,from}_user does for an HVM guest even on X86,
> > where copy_to_user becomes copy_to_user_hvm as appropriate. 
> 
> But that's not true - the distinction of hvm vs pv is at the
> copy_to_guest() layer (raw_copy_to_guest() in the x86 case). So
> maybe the patch meant to use those interfaces (and then we'd need
> a clear_guest() too, which should also have been obvious by the fact
> that the prior patch only introduced clear_user(), but no hvm variant
> of it)?

This code is also compiled in userspace which doesn't have copy_to_user
and in that case we need to use memcpy.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 15:34:46 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 15:34:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZ2Sq-0002Kq-SO; Fri, 09 Dec 2011 15:34:20 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RZ2Sp-0002Kl-PE
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 15:34:19 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1323444774!50158659!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5716 invoked from network); 9 Dec 2011 15:32:54 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-6.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 9 Dec 2011 15:32:54 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 09 Dec 2011 15:33:31 +0000
Message-Id: <4EE2388702000078000668BF@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 09 Dec 2011 15:34:15 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
References: <alpine.DEB.2.00.1112091208420.3517@kaball-desktop>
	<1323436408-16335-6-git-send-email-stefano.stabellini@eu.citrix.com>
	<4EE21C4602000078000667AA@nat28.tlf.novell.com>
	<1323438026.20077.51.camel@zakaz.uk.xensource.com>
	<4EE2335A020000780006688C@nat28.tlf.novell.com>
	<1323444231.20077.72.camel@zakaz.uk.xensource.com>
In-Reply-To: <1323444231.20077.72.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"keir.xen@gmail.com" <keir.xen@gmail.com>,
	"Tim Deegan \(3P\)" <Tim.Deegan@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v2 06/25] libelf-loader: introduce
	elf_load_image
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 09.12.11 at 16:23, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Fri, 2011-12-09 at 15:12 +0000, Jan Beulich wrote:
>> >>> On 09.12.11 at 14:40, Ian Campbell <Ian.Campbell@citrix.com> wrote:
>> > On Fri, 2011-12-09 at 13:33 +0000, Jan Beulich wrote:
>> >> >>> On 09.12.11 at 14:13, <stefano.stabellini@eu.citrix.com> wrote:
>> >> > Implement a new function, called elf_load_image, to perform the actually
>> >> > copy of the elf image and clearing the padding.
>> >> > The function is implemented as memcpy and memset when the library is
>> >> > built as part of the tools, but it is implemented as copy_to_user and
>> >> > clear_user when built as part of Xen, so that it can be safely called
>> >> > with an HVM style dom0.
>> >> 
>> >> I meant to ask this on the first round already, but apparently forgot:
>> >> What is it that prevents memcpy()/memset() from being used for a
>> >> HVM style Dom0? {clear,copy_to}_user() still expect the guest memory
>> >> to be visible in the hypervisor's virtual address space - how could a
>> >> fault happen here? And if you have to take precautions for a fault,
>> >> shouldn't the calling code check the respective return values?
>> > 
>> > HVM guest memory is not (necessarily) mapped in the hypervisor page
>> > tables, it needs to be mapped on demand. Also the source/target (delete
>> > as appropriate) is a guest virtual address so even if the RAM happened
>> > to be mapped it would (likely) not be in the same place so at a minimum
>> > we need to translate things.
>> > 
>> > This is what copy_{to,from}_user does for an HVM guest even on X86,
>> > where copy_to_user becomes copy_to_user_hvm as appropriate. 
>> 
>> But that's not true - the distinction of hvm vs pv is at the
>> copy_to_guest() layer (raw_copy_to_guest() in the x86 case). So
>> maybe the patch meant to use those interfaces (and then we'd need
>> a clear_guest() too, which should also have been obvious by the fact
>> that the prior patch only introduced clear_user(), but no hvm variant
>> of it)?
> 
> This code is also compiled in userspace which doesn't have copy_to_user
> and in that case we need to use memcpy.

Oh, the need for a distinct case for the user space version of it I
understand (assuming memcpy()/memset() indeed can't be used in the
hypervisor). What I was trying to tell you is that the ..._user()
interfaces don't have the property you're apparently thinking they
have, but instead you'd have to use the ..._guest() ones (I didn't look
at the ARM bits, but if there things are done differently that's likely a
mistake).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 15:34:46 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 15:34:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZ2Sq-0002Kq-SO; Fri, 09 Dec 2011 15:34:20 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RZ2Sp-0002Kl-PE
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 15:34:19 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1323444774!50158659!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5716 invoked from network); 9 Dec 2011 15:32:54 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-6.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 9 Dec 2011 15:32:54 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 09 Dec 2011 15:33:31 +0000
Message-Id: <4EE2388702000078000668BF@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 09 Dec 2011 15:34:15 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
References: <alpine.DEB.2.00.1112091208420.3517@kaball-desktop>
	<1323436408-16335-6-git-send-email-stefano.stabellini@eu.citrix.com>
	<4EE21C4602000078000667AA@nat28.tlf.novell.com>
	<1323438026.20077.51.camel@zakaz.uk.xensource.com>
	<4EE2335A020000780006688C@nat28.tlf.novell.com>
	<1323444231.20077.72.camel@zakaz.uk.xensource.com>
In-Reply-To: <1323444231.20077.72.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"keir.xen@gmail.com" <keir.xen@gmail.com>,
	"Tim Deegan \(3P\)" <Tim.Deegan@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v2 06/25] libelf-loader: introduce
	elf_load_image
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 09.12.11 at 16:23, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Fri, 2011-12-09 at 15:12 +0000, Jan Beulich wrote:
>> >>> On 09.12.11 at 14:40, Ian Campbell <Ian.Campbell@citrix.com> wrote:
>> > On Fri, 2011-12-09 at 13:33 +0000, Jan Beulich wrote:
>> >> >>> On 09.12.11 at 14:13, <stefano.stabellini@eu.citrix.com> wrote:
>> >> > Implement a new function, called elf_load_image, to perform the actually
>> >> > copy of the elf image and clearing the padding.
>> >> > The function is implemented as memcpy and memset when the library is
>> >> > built as part of the tools, but it is implemented as copy_to_user and
>> >> > clear_user when built as part of Xen, so that it can be safely called
>> >> > with an HVM style dom0.
>> >> 
>> >> I meant to ask this on the first round already, but apparently forgot:
>> >> What is it that prevents memcpy()/memset() from being used for a
>> >> HVM style Dom0? {clear,copy_to}_user() still expect the guest memory
>> >> to be visible in the hypervisor's virtual address space - how could a
>> >> fault happen here? And if you have to take precautions for a fault,
>> >> shouldn't the calling code check the respective return values?
>> > 
>> > HVM guest memory is not (necessarily) mapped in the hypervisor page
>> > tables, it needs to be mapped on demand. Also the source/target (delete
>> > as appropriate) is a guest virtual address so even if the RAM happened
>> > to be mapped it would (likely) not be in the same place so at a minimum
>> > we need to translate things.
>> > 
>> > This is what copy_{to,from}_user does for an HVM guest even on X86,
>> > where copy_to_user becomes copy_to_user_hvm as appropriate. 
>> 
>> But that's not true - the distinction of hvm vs pv is at the
>> copy_to_guest() layer (raw_copy_to_guest() in the x86 case). So
>> maybe the patch meant to use those interfaces (and then we'd need
>> a clear_guest() too, which should also have been obvious by the fact
>> that the prior patch only introduced clear_user(), but no hvm variant
>> of it)?
> 
> This code is also compiled in userspace which doesn't have copy_to_user
> and in that case we need to use memcpy.

Oh, the need for a distinct case for the user space version of it I
understand (assuming memcpy()/memset() indeed can't be used in the
hypervisor). What I was trying to tell you is that the ..._user()
interfaces don't have the property you're apparently thinking they
have, but instead you'd have to use the ..._guest() ones (I didn't look
at the ARM bits, but if there things are done differently that's likely a
mistake).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 15:42:38 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 15: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.xensource.com>)
	id 1RZ2aR-0002Wd-QU; Fri, 09 Dec 2011 15:42:11 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RZ2aQ-0002WY-Lf
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 15:42:10 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1323445280!4931969!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI2MQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 669 invoked from network); 9 Dec 2011 15:41:20 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 15:41:20 -0000
X-IronPort-AV: E=Sophos;i="4.71,326,1320624000"; 
   d="scan'208";a="9388598"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 15:41:19 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 9 Dec 2011
	15:41:19 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Fri, 9 Dec 2011 15:41:18 +0000
In-Reply-To: <4EE2388702000078000668BF@nat28.tlf.novell.com>
References: <alpine.DEB.2.00.1112091208420.3517@kaball-desktop>
	<1323436408-16335-6-git-send-email-stefano.stabellini@eu.citrix.com>
	<4EE21C4602000078000667AA@nat28.tlf.novell.com>
	<1323438026.20077.51.camel@zakaz.uk.xensource.com>
	<4EE2335A020000780006688C@nat28.tlf.novell.com>
	<1323444231.20077.72.camel@zakaz.uk.xensource.com>
	<4EE2388702000078000668BF@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323445279.20077.76.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"keir.xen@gmail.com" <keir.xen@gmail.com>,
	"Tim Deegan \(3P\)" <Tim.Deegan@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v2 06/25] libelf-loader: introduce
	elf_load_image
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2011-12-09 at 15:34 +0000, Jan Beulich wrote:
> >>> On 09.12.11 at 16:23, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > On Fri, 2011-12-09 at 15:12 +0000, Jan Beulich wrote:
> >> >>> On 09.12.11 at 14:40, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> >> > On Fri, 2011-12-09 at 13:33 +0000, Jan Beulich wrote:
> >> >> >>> On 09.12.11 at 14:13, <stefano.stabellini@eu.citrix.com> wrote:
> >> >> > Implement a new function, called elf_load_image, to perform the actually
> >> >> > copy of the elf image and clearing the padding.
> >> >> > The function is implemented as memcpy and memset when the library is
> >> >> > built as part of the tools, but it is implemented as copy_to_user and
> >> >> > clear_user when built as part of Xen, so that it can be safely called
> >> >> > with an HVM style dom0.
> >> >> 
> >> >> I meant to ask this on the first round already, but apparently forgot:
> >> >> What is it that prevents memcpy()/memset() from being used for a
> >> >> HVM style Dom0? {clear,copy_to}_user() still expect the guest memory
> >> >> to be visible in the hypervisor's virtual address space - how could a
> >> >> fault happen here? And if you have to take precautions for a fault,
> >> >> shouldn't the calling code check the respective return values?
> >> > 
> >> > HVM guest memory is not (necessarily) mapped in the hypervisor page
> >> > tables, it needs to be mapped on demand. Also the source/target (delete
> >> > as appropriate) is a guest virtual address so even if the RAM happened
> >> > to be mapped it would (likely) not be in the same place so at a minimum
> >> > we need to translate things.
> >> > 
> >> > This is what copy_{to,from}_user does for an HVM guest even on X86,
> >> > where copy_to_user becomes copy_to_user_hvm as appropriate. 
> >> 
> >> But that's not true - the distinction of hvm vs pv is at the
> >> copy_to_guest() layer (raw_copy_to_guest() in the x86 case). So
> >> maybe the patch meant to use those interfaces (and then we'd need
> >> a clear_guest() too, which should also have been obvious by the fact
> >> that the prior patch only introduced clear_user(), but no hvm variant
> >> of it)?
> > 
> > This code is also compiled in userspace which doesn't have copy_to_user
> > and in that case we need to use memcpy.
> 
> Oh, the need for a distinct case for the user space version of it I
> understand (assuming memcpy()/memset() indeed can't be used in the
> hypervisor). What I was trying to tell you is that the ..._user()
> interfaces don't have the property you're apparently thinking they
> have, but instead you'd have to use the ..._guest() ones

Oh, I see, yes you are right.

>  (I didn't look
> at the ARM bits, but if there things are done differently that's likely a
> mistake).

This ARM port has no PV guests so it has no "user" in the sense that
x86's copy_to_user means, so copy_to_user and copy_to_guest are both the
same and do things the HVM way.

Maybe the right thing to do is to not supply copy_to_user on ARM at all.
I had feared this would be a big bit of string to pull on but it seems
that copy_to_user isn't actually widely used in common code:
$ rgrep --binary-files=without-match copy_to_user xen | grep -vE x86\|ia64\|asm
xen/common/gdbstub.c:        r = gdb_arch_copy_to_user((void*)addr, (void*)&val, 1);
xen/include/linux/gdbstub.h:unsigned int gdb_arch_copy_to_user(
xen/include/xen/gdbstub.h:unsigned int gdb_arch_copy_to_user(

Stefano, what do you think?

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 15:42:38 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 15: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.xensource.com>)
	id 1RZ2aR-0002Wd-QU; Fri, 09 Dec 2011 15:42:11 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RZ2aQ-0002WY-Lf
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 15:42:10 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1323445280!4931969!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI2MQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 669 invoked from network); 9 Dec 2011 15:41:20 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 15:41:20 -0000
X-IronPort-AV: E=Sophos;i="4.71,326,1320624000"; 
   d="scan'208";a="9388598"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 15:41:19 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 9 Dec 2011
	15:41:19 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Fri, 9 Dec 2011 15:41:18 +0000
In-Reply-To: <4EE2388702000078000668BF@nat28.tlf.novell.com>
References: <alpine.DEB.2.00.1112091208420.3517@kaball-desktop>
	<1323436408-16335-6-git-send-email-stefano.stabellini@eu.citrix.com>
	<4EE21C4602000078000667AA@nat28.tlf.novell.com>
	<1323438026.20077.51.camel@zakaz.uk.xensource.com>
	<4EE2335A020000780006688C@nat28.tlf.novell.com>
	<1323444231.20077.72.camel@zakaz.uk.xensource.com>
	<4EE2388702000078000668BF@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323445279.20077.76.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"keir.xen@gmail.com" <keir.xen@gmail.com>,
	"Tim Deegan \(3P\)" <Tim.Deegan@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v2 06/25] libelf-loader: introduce
	elf_load_image
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2011-12-09 at 15:34 +0000, Jan Beulich wrote:
> >>> On 09.12.11 at 16:23, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > On Fri, 2011-12-09 at 15:12 +0000, Jan Beulich wrote:
> >> >>> On 09.12.11 at 14:40, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> >> > On Fri, 2011-12-09 at 13:33 +0000, Jan Beulich wrote:
> >> >> >>> On 09.12.11 at 14:13, <stefano.stabellini@eu.citrix.com> wrote:
> >> >> > Implement a new function, called elf_load_image, to perform the actually
> >> >> > copy of the elf image and clearing the padding.
> >> >> > The function is implemented as memcpy and memset when the library is
> >> >> > built as part of the tools, but it is implemented as copy_to_user and
> >> >> > clear_user when built as part of Xen, so that it can be safely called
> >> >> > with an HVM style dom0.
> >> >> 
> >> >> I meant to ask this on the first round already, but apparently forgot:
> >> >> What is it that prevents memcpy()/memset() from being used for a
> >> >> HVM style Dom0? {clear,copy_to}_user() still expect the guest memory
> >> >> to be visible in the hypervisor's virtual address space - how could a
> >> >> fault happen here? And if you have to take precautions for a fault,
> >> >> shouldn't the calling code check the respective return values?
> >> > 
> >> > HVM guest memory is not (necessarily) mapped in the hypervisor page
> >> > tables, it needs to be mapped on demand. Also the source/target (delete
> >> > as appropriate) is a guest virtual address so even if the RAM happened
> >> > to be mapped it would (likely) not be in the same place so at a minimum
> >> > we need to translate things.
> >> > 
> >> > This is what copy_{to,from}_user does for an HVM guest even on X86,
> >> > where copy_to_user becomes copy_to_user_hvm as appropriate. 
> >> 
> >> But that's not true - the distinction of hvm vs pv is at the
> >> copy_to_guest() layer (raw_copy_to_guest() in the x86 case). So
> >> maybe the patch meant to use those interfaces (and then we'd need
> >> a clear_guest() too, which should also have been obvious by the fact
> >> that the prior patch only introduced clear_user(), but no hvm variant
> >> of it)?
> > 
> > This code is also compiled in userspace which doesn't have copy_to_user
> > and in that case we need to use memcpy.
> 
> Oh, the need for a distinct case for the user space version of it I
> understand (assuming memcpy()/memset() indeed can't be used in the
> hypervisor). What I was trying to tell you is that the ..._user()
> interfaces don't have the property you're apparently thinking they
> have, but instead you'd have to use the ..._guest() ones

Oh, I see, yes you are right.

>  (I didn't look
> at the ARM bits, but if there things are done differently that's likely a
> mistake).

This ARM port has no PV guests so it has no "user" in the sense that
x86's copy_to_user means, so copy_to_user and copy_to_guest are both the
same and do things the HVM way.

Maybe the right thing to do is to not supply copy_to_user on ARM at all.
I had feared this would be a big bit of string to pull on but it seems
that copy_to_user isn't actually widely used in common code:
$ rgrep --binary-files=without-match copy_to_user xen | grep -vE x86\|ia64\|asm
xen/common/gdbstub.c:        r = gdb_arch_copy_to_user((void*)addr, (void*)&val, 1);
xen/include/linux/gdbstub.h:unsigned int gdb_arch_copy_to_user(
xen/include/xen/gdbstub.h:unsigned int gdb_arch_copy_to_user(

Stefano, what do you think?

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 15:47:01 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 15: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.xensource.com>)
	id 1RZ2ej-0002ev-H3; Fri, 09 Dec 2011 15:46:37 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RZ2eh-0002ec-9N
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 15:46:35 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1323445432!6731336!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI2MQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6259 invoked from network); 9 Dec 2011 15:43:52 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 15:43:52 -0000
X-IronPort-AV: E=Sophos;i="4.71,326,1320624000"; 
   d="scan'208";a="9388657"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 15:43:52 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 15:43:52 +0000
Date: Fri, 9 Dec 2011 15:44:27 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Jackson <ian.jackson@eu.citrix.com>
In-Reply-To: <1323108621-22654-15-git-send-email-ian.jackson@eu.citrix.com>
Message-ID: <alpine.DEB.2.00.1112091504060.3517@kaball-desktop>
References: <1323108621-22654-1-git-send-email-ian.jackson@eu.citrix.com>
	<1323108621-22654-15-git-send-email-ian.jackson@eu.citrix.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 14/15] libxl: New API for providing OS
 events to libxl
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 5 Dec 2011, Ian Jackson wrote:
> We provide a new set of functions and related structures
>   libxl_osevent_*
> which are to be used by event-driven applications to receive
> information from libxl about which fds libxl is interested in, and
> what timeouts libxl is waiting for, and to pass back to libxl
> information about which fds are readable/writeable etc., and which
> timeouts have occurred.  Ie, low-level events.
> 
> In this patch, this new machinery is still all unused.  Callers will
> appear in the next patch in the series, which introduces a new API for
> applications to receive high-level events about actual domains etc.
> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
> ---
>  tools/libxl/Makefile         |    2 +-
>  tools/libxl/libxl.c          |   25 ++
>  tools/libxl/libxl.h          |    6 +
>  tools/libxl/libxl_event.c    |  711 ++++++++++++++++++++++++++++++++++++++++++
>  tools/libxl/libxl_event.h    |  199 ++++++++++++
>  tools/libxl/libxl_internal.h |  216 +++++++++++++-
>  6 files changed, 1155 insertions(+), 4 deletions(-)
>  create mode 100644 tools/libxl/libxl_event.c
>  create mode 100644 tools/libxl/libxl_event.h
> 
> diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
> index 4e0f3fb..3d575b8 100644
> --- a/tools/libxl/Makefile
> +++ b/tools/libxl/Makefile
> @@ -38,7 +38,7 @@ LIBXL_LIBS += -lyajl
>  LIBXL_OBJS = flexarray.o libxl.o libxl_create.o libxl_dm.o libxl_pci.o \
>                         libxl_dom.o libxl_exec.o libxl_xshelp.o libxl_device.o \
>                         libxl_internal.o libxl_utils.o libxl_uuid.o libxl_json.o \
> -                       libxl_qmp.o $(LIBXL_OBJS-y)
> +                       libxl_qmp.o libxl_event.o $(LIBXL_OBJS-y)
>  LIBXL_OBJS += _libxl_types.o libxl_flask.o _libxl_types_internal.o
> 
>  $(LIBXL_OBJS): CFLAGS += $(CFLAGS_libxenctrl) $(CFLAGS_libxenguest) $(CFLAGS_libxenstore) $(CFLAGS_libblktapctl)
> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> index 3a8cfe3..58f280c 100644
> --- a/tools/libxl/libxl.c
> +++ b/tools/libxl/libxl.c
> @@ -60,6 +60,16 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
>       * only as an initialiser, not as an expression. */
>      memcpy(&ctx->lock, &mutex_value, sizeof(ctx->lock));
> 
> +    ctx->osevent_hooks = 0;
> +
> +    ctx->fd_beforepolled = 0;
> +    LIBXL_LIST_INIT(&ctx->efds);
> +    LIBXL_TAILQ_INIT(&ctx->etimes);
> +
> +    ctx->watch_slots = 0;
> +    LIBXL_SLIST_INIT(&ctx->watch_freeslots);
> +    libxl__ev_fd_init(&ctx->watch_efd);
> +
>      if ( stat(XENSTORE_PID_FILE, &stat_buf) != 0 ) {
>          LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "Is xenstore daemon running?\n"
>                       "failed to stat %s", XENSTORE_PID_FILE);
> @@ -89,10 +99,25 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
> 
>  int libxl_ctx_free(libxl_ctx *ctx)
>  {
> +    int i;
> +    GC_INIT(ctx);
> +
>      if (!ctx) return 0;
> +
> +    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_LIST_EMPTY(&ctx->efds));
> +    assert(LIBXL_TAILQ_EMPTY(&ctx->etimes));
> +
>      if (ctx->xch) xc_interface_close(ctx->xch);
>      libxl_version_info_dispose(&ctx->version_info);
>      if (ctx->xsh) xs_daemon_close(ctx->xsh);
> +
> +    free(ctx->fd_beforepolled);
> +    free(ctx->watch_slots);
> +
>      return 0;
>  }
> 
> diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
> index 289dc85..654a5b0 100644
> --- a/tools/libxl/libxl.h
> +++ b/tools/libxl/libxl.h
> @@ -137,6 +137,7 @@
>  #include <xen/sysctl.h>
> 
>  #include <libxl_uuid.h>
> +#include <_libxl_list.h>
> 
>  typedef uint8_t libxl_mac[6];
>  #define LIBXL_MAC_FMT "%02hhx:%02hhx:%02hhx:%02hhx:%02hhx:%02hhx"
> @@ -222,6 +223,9 @@ enum {
>      ERROR_BADFAIL = -7,
>      ERROR_GUEST_TIMEDOUT = -8,
>      ERROR_TIMEDOUT = -9,
> +    ERROR_NOT_READY = -10,
> +    ERROR_OSEVENT_REG_FAIL = -11,
> +    ERROR_BUFFERFULL = -12,
>  };
> 
>  #define LIBXL_VERSION 0
> @@ -635,6 +639,8 @@ const char *libxl_lock_dir_path(void);
>  const char *libxl_run_dir_path(void);
>  const char *libxl_xenpaging_dir_path(void);
> 
> +#include <libxl_event.h>
> +
>  #endif /* LIBXL_H */
> 
>  /*
> diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
> new file mode 100644
> index 0000000..8d4dbf6
> --- /dev/null
> +++ b/tools/libxl/libxl_event.c
> @@ -0,0 +1,711 @@
> +/*
> + * Copyright (C) 2011      Citrix Ltd.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU Lesser General Public License as published
> + * by the Free Software Foundation; version 2.1 only. with the special
> + * exception on linking described in file LICENSE.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU Lesser General Public License for more details.
> + */
> +/*
> + * Internal event machinery for use by other parts of libxl
> + */
> +
> +#include <poll.h>
> +
> +#include "libxl_internal.h"
> +
> +/*
> + * The counter osevent_in_hook is used to ensure that the application
> + * honours the reentrancy restriction documented in libxl_event.h.
> + *
> + * The application's registration hooks should be called ONLY via
> + * these macros, with the ctx locked.  Likewise all the "occurred"
> + * entrypoints from the application should assert(!in_hook);
> + */
> +#define OSEVENT_HOOK_INTERN(defval, hookname, ...)                      \
> +    (CTX->osevent_hooks                                                 \
> +     ? (CTX->osevent_in_hook++,                                         \
> +        CTX->osevent_hooks->hookname(CTX->osevent_user, __VA_ARGS__),   \
> +        CTX->osevent_in_hook--)                                         \
> +     : defval)
> +
> +#define OSEVENT_HOOK(hookname,...)                      \
> +    OSEVENT_HOOK_INTERN(0, hookname, __VA_ARGS__)
> +
> +#define OSEVENT_HOOK_VOID(hookname,...)                 \
> +    OSEVENT_HOOK_INTERN((void)0, hookname, __VA_ARGS__)

Is there any reasons why we cannot use static inline functions here?


> +/*
> + * fd events
> + */
> +
> +int libxl__ev_fd_register(libxl__gc *gc, libxl__ev_fd *ev,
> +                          libxl__ev_fd_callback *func,
> +                          int fd, short events) {
> +    int rc;
> +
> +    assert(fd >= 0);
> +
> +    CTX_LOCK;
> +
> +    rc = OSEVENT_HOOK(fd_register, fd, &ev->for_app_reg, events, ev);
> +    if (rc) goto out;
> +
> +    LIBXL_LIST_INSERT_HEAD(&CTX->efds, ev, entry);
> +
> +    ev->fd = fd;
> +    ev->events = events;
> +    ev->in_beforepolled = -1;
> +    ev->func = func;
> +
> +    rc = 0;
> +
> + out:
> +    CTX_UNLOCK;
> +    return rc;
> +}
> +
> +int libxl__ev_fd_modify(libxl__gc *gc, libxl__ev_fd *ev, short events) {
> +    int rc;
> +
> +    CTX_LOCK;
> +    assert(libxl__ev_fd_isregistered(ev));
> +
> +    rc = OSEVENT_HOOK(fd_modify, ev->fd, &ev->for_app_reg, events);
> +    if (rc) goto out;
> +
> +    ev->events = events;
> +
> +    rc = 0;
> + out:
> +    CTX_UNLOCK;
> +    return rc;
> +}
> +
> +void libxl__ev_fd_deregister(libxl__gc *gc, libxl__ev_fd *ev) {
> +    CTX_LOCK;
> +
> +    if (!libxl__ev_fd_isregistered(ev))
> +        goto out;
> +
> +    OSEVENT_HOOK_VOID(fd_deregister, ev->fd, ev->for_app_reg);
> +    LIBXL_LIST_REMOVE(ev, entry);
> +    ev->fd = -1;
> +
> +    if (ev->in_beforepolled >= 0 &&
> +        ev->in_beforepolled < CTX->fd_beforepolled_used)
> +        /* remove stale reference */
> +        CTX->fd_beforepolled[ev->in_beforepolled] = NULL;
> +
> + out:
> +    CTX_UNLOCK;
> +}
> +
> +/*
> + * timeouts
> + */
> +
> +
> +int libxl__gettimeofday(libxl__gc *gc, struct timeval *now_r) {
> +    int rc = gettimeofday(now_r, 0);
> +    if (rc) {
> +        LIBXL__LOG_ERRNO(CTX, LIBXL__LOG_ERROR, "gettimeofday failed");
> +        return ERROR_FAIL;
> +    }
> +    return 0;
> +}
> +
> +static int time_rel_to_abs(libxl__gc *gc, int ms, struct timeval *abs_out) {
> +    int rc;
> +    struct timeval additional = {
> +        .tv_sec = ms / 1000,
> +        .tv_usec = (ms % 1000) * 1000
> +    };
> +    struct timeval now;
> +
> +    rc = libxl__gettimeofday(gc, &now);
> +    if (rc) return rc;
> +
> +    timeradd(&now, &additional, abs_out);
> +    return 0;
> +}
> +
> +static void time_insert_finite(libxl__gc *gc, libxl__ev_time *ev) {
> +    libxl__ev_time *evsearch;
> +    LIBXL_TAILQ_INSERT_SORTED(&CTX->etimes, entry, ev, evsearch, ,
> +                              timercmp(&ev->abs, &evsearch->abs, >));
> +    ev->infinite = 0;
> +}
> +
> +static int time_register_finite(libxl__gc *gc, libxl__ev_time *ev,
> +                                struct timeval abs) {
> +    int rc;
> +
> +    rc = OSEVENT_HOOK(timeout_register, &ev->for_app_reg, abs, ev);
> +    if (rc) return rc;
> +
> +    ev->infinite = 0;
> +    ev->abs = abs;
> +    time_insert_finite(gc, ev);
> +
> +    return 0;
> +}
> +
> +static void time_deregister(libxl__gc *gc, libxl__ev_time *ev) {
> +    if (!ev->infinite) {
> +        OSEVENT_HOOK_VOID(timeout_deregister, &ev->for_app_reg);
> +        LIBXL_TAILQ_REMOVE(&CTX->etimes, ev, entry);
> +    }
> +}
> +
> +
> +int libxl__ev_time_register_abs(libxl__gc *gc, libxl__ev_time *ev,
> +                                libxl__ev_time_callback *func,
> +                                struct timeval abs) {
> +    int rc;
> +
> +    CTX_LOCK;
> +
> +    rc = time_register_finite(gc, ev, abs);
> +    if (rc) goto out;
> +
> +    ev->func = func;
> +
> +    rc = 0;
> + out:
> +    CTX_UNLOCK;
> +    return rc;
> +}
> +
> +
> +int libxl__ev_time_register_rel(libxl__gc *gc, libxl__ev_time *ev,
> +                                libxl__ev_time_callback *func,
> +                                int milliseconds /* as for poll(2) */) {
> +    struct timeval abs;
> +    int rc;
> +
> +    CTX_LOCK;
> +
> +    if (milliseconds < 0) {
> +        ev->infinite = 1;
> +    } else {
> +        rc = time_rel_to_abs(gc, milliseconds, &abs);
> +        if (rc) goto out;
> +
> +        rc = time_register_finite(gc, ev, abs);
> +        if (rc) goto out;
> +    }
> +
> +    ev->func = func;
> +    rc = 0;
> +
> + out:
> +    CTX_UNLOCK;
> +    return 0;
> +}
> +
> +int libxl__ev_time_modify_abs(libxl__gc *gc, libxl__ev_time *ev,
> +                              struct timeval abs) {
> +    int rc;
> +
> +    CTX_LOCK;
> +
> +    assert(libxl__ev_time_isregistered(ev));
> +
> +    if (ev->infinite) {
> +        rc = time_register_finite(gc, ev, abs);
> +        if (rc) goto out;
> +    } else {
> +        rc = OSEVENT_HOOK(timeout_modify, &ev->for_app_reg, abs);
> +        if (rc) goto out;
> +
> +        LIBXL_TAILQ_REMOVE(&CTX->etimes, ev, entry);
> +        ev->abs = abs;
> +        time_insert_finite(gc, ev);
> +    }
> +
> +    rc = 0;
> + out:
> +    CTX_UNLOCK;
> +    return rc;
> +}
> +
> +int libxl__ev_time_modify_rel(libxl__gc *gc, libxl__ev_time *ev,
> +                              int milliseconds) {
> +    struct timeval abs;
> +    int rc;
> +
> +    CTX_LOCK;
> +
> +    assert(libxl__ev_time_isregistered(ev));
> +
> +    if (milliseconds < 0) {
> +        time_deregister(gc, ev);
> +        ev->infinite = 1;
> +        rc = 0;
> +        goto out;
> +    }
> +
> +    rc = time_rel_to_abs(gc, milliseconds, &abs);
> +    if (rc) goto out;
> +
> +    rc = libxl__ev_time_modify_abs(gc, ev, abs);
> +    if (rc) goto out;
> +
> +    rc = 0;
> + out:
> +    CTX_UNLOCK;
> +    return 0;
> +}
> +
> +void libxl__ev_time_deregister(libxl__gc *gc, libxl__ev_time *ev) {
> +    CTX_LOCK;
> +
> +    if (!libxl__ev_time_isregistered(ev))
> +        goto out;
> +
> +    time_deregister(gc, ev);
> +    ev->func = 0;
> +
> + out:
> +    CTX_UNLOCK;
> +    return;
> +}
> +
> +
> +/*
> + * xenstore watches
> + */
> +
> +libxl__ev_xswatch *libxl__watch_slot_contents(libxl__gc *gc, int slotnum) {
> +    libxl__ev_watch_slot *slot = &CTX->watch_slots[slotnum];
> +    libxl__ev_watch_slot *slotcontents = LIBXL_SLIST_NEXT(slot, empty);
> +
> +    if (slotcontents == NULL ||
> +        ((uintptr_t)slotcontents >= (uintptr_t)CTX->watch_slots &&
> +         (uintptr_t)slotcontents < (uintptr_t)(CTX->watch_slots +
> +                                               CTX->watch_nslots)))
> +        /* An empty slot has either a NULL pointer (end of the
> +         * free list), or a pointer to another entry in the array.
> +         * So we can do a bounds check to distinguish empty from
> +         * full slots.
> +         */
> +        /* We need to do the comparisons as uintptr_t because
> +         * comparing pointers which are not in the same object is
> +         * undefined behaviour; if the compiler managed to figure
> +         * out that watch_slots[0..watch_nslots-1] is all of the
> +         * whole array object it could prove that the above bounds
> +         * check was always true if it was legal, and remove it!
> +         *
> +         * uintptr_t because even on a machine with signed
> +         * pointers, objects do not cross zero; whereas on
> +         * machines with unsigned pointers, they may cross
> +         * 0x8bazillion.
> +         */
> +        return NULL;
> +
> +        /* see comment near libxl__ev_watch_slot definition */
> +    return (void*)slotcontents;
> +}
> +
> +static void watchfd_callback(libxl__gc *gc, libxl__ev_fd *ev,
> +                             int fd, short events, short revents) {
> +    for (;;) {
> +        char **event = xs_check_watch(CTX->xsh);
> +        if (!event) {
> +            if (errno == EAGAIN) break;
> +            if (errno == EINTR) continue;
> +            LIBXL__EVENT_DISASTER(gc, "cannot check/read watches", errno, 0);
> +            return;
> +        }
> +
> +        const char *epath = event[0];
> +        const char *token = event[1];
> +        int slotnum;
> +        uint32_t counterval;

OK, this is the last time I am going to point this out, but epath,
token, etc, should be declared above, at the beginning of the block.


> +        int rc = sscanf(token, "%d/%"SCNx32, &slotnum, &counterval);
> +        if (rc != 2) {
> +            LIBXL__LOG(CTX, LIBXL__LOG_ERROR,
> +                       "watch epath=%s token=%s: failed to parse token",
> +                       epath, token);
> +            /* oh well */
> +            goto ignore;
> +        }
> +        if (slotnum < 0 || slotnum >= CTX->watch_nslots) {
> +            /* perhaps in the future we will make the watchslots array shrink */
> +            LIBXL__LOG(CTX, LIBXL__LOG_DEBUG, "watch epath=%s token=%s:"
> +                       " slotnum %d out of range [0,%d>",
> +                       epath, token, slotnum, CTX->watch_nslots);
> +            goto ignore;
> +        }
> +
> +        libxl__ev_xswatch *w = libxl__watch_slot_contents(gc, slotnum);
> +
> +        if (!w) {
> +            LIBXL__LOG(CTX, LIBXL__LOG_DEBUG,
> +                       "watch epath=%s token=%s: empty slot",
> +                       epath, token);
> +            goto ignore;
> +        }
> +
> +        if (w->counterval != counterval) {
> +            LIBXL__LOG(CTX, LIBXL__LOG_DEBUG,
> +                       "watch epath=%s token=%s: counter != %"PRIx32,
> +                       epath, token, w->counterval);
> +            goto ignore;
> +        }
> +
> +        /* Now it's possible, though unlikely, that this was an event
> +         * from a previous use of the same slot with the same counterval.
> +         *
> +         * In that case either:
> +         *  - the event path is a child of the watch path, in
> +         *    which case this watch would really have generated this
> +         *    event if it had been registered soon enough and we are
> +         *    OK to give this possibly-spurious event to the caller; or
> +         * - it is not, in which case we must suppress it as the
> +         *   caller should not see events for unrelated paths.
> +         *
> +         * See also docs/misc/xenstore.txt.
> +         */
> +        size_t epathlen = strlen(epath);
> +        size_t wpathlen = strlen(w->path);
> +        if (epathlen < wpathlen ||
> +            memcmp(epath, w->path, wpathlen) ||
> +            (epathlen > wpathlen && epath[wpathlen] != '/')) {
> +            LIBXL__LOG(CTX, LIBXL__LOG_DEBUG,
> +                       "watch epath=%s token=%s: not child of wpath=%s",
> +                       epath, token, w->path);
> +            goto ignore;
> +        }
> +
> +        /* At last, we have checked everything! */
> +        LIBXL__LOG(CTX, LIBXL__LOG_DEBUG,
> +                   "watch event: epath=%s token=%s wpath=%s w=%p",
> +                   epath, token, w->path, w);
> +        w->callback(gc, w, w->path, epath);
> +
> +    ignore:
> +        free(event);
> +    }
> +}
> +
> +static char *watch_token(libxl__gc *gc, int slotnum, uint32_t counterval) {
> +    return libxl__sprintf(gc, "%d/%"PRIx32, slotnum, counterval);
> +}
> +
> +int libxl__ev_xswatch_register(libxl__gc *gc, libxl__ev_xswatch *w,
> +                               libxl__ev_xswatch_callback *func,
> +                               const char *path /* copied */) {
> +    libxl__ev_watch_slot *use = NULL;
> +    char *path_copy = NULL;
> +    int rc;
> +
> +    CTX_LOCK;
> +
> +    if (!libxl__ev_fd_isregistered(&CTX->watch_efd)) {
> +        rc = libxl__ev_fd_register(gc, &CTX->watch_efd, watchfd_callback,
> +                                   xs_fileno(CTX->xsh), POLLIN);
> +        if (rc) goto out_rc;
> +    }
> +
> +    if (LIBXL_SLIST_EMPTY(&CTX->watch_freeslots)) {
> +        /* Free list is empty so there is not in fact a linked
> +         * free list in the array and we can safely realloc it */
> +        int newarraysize = (CTX->watch_nslots + 1) << 2;
> +        int i;
> +        libxl__ev_watch_slot *newarray =
> +            realloc(CTX->watch_slots, sizeof(*newarray) * newarraysize);
> +        if (!newarray) goto out_nomem;
> +        for (i=CTX->watch_nslots; i<newarraysize; i++)

does not follow the CODING_STYLE, it should be

           for (i = CTX->watch_nslots; i < newarraysize; i++)


> +            LIBXL_SLIST_INSERT_HEAD(&CTX->watch_freeslots,
> +                                    &newarray[i], empty);
> +        CTX->watch_slots = newarray;
> +        CTX->watch_nslots = newarraysize;
> +    }

would it make sense to move this code in its own allocate_watch_slots
function?


> +    use = LIBXL_SLIST_FIRST(&CTX->watch_freeslots);
> +    assert(use);
> +    LIBXL_SLIST_REMOVE_HEAD(&CTX->watch_freeslots, empty);
> +
> +    path_copy = strdup(path);
> +    if (!path_copy) goto out_nomem;
> +
> +    int slotnum = use - CTX->watch_slots;
> +    w->counterval = CTX->watch_counter++;
> +
> +    if (!xs_watch(CTX->xsh, path, watch_token(gc, slotnum, w->counterval))) {
> +        LIBXL__LOG_ERRNOVAL(CTX, LIBXL__LOG_ERROR, errno,
> +                            "create watch for path %s", path);
> +        rc = ERROR_FAIL;
> +        goto out_rc;
> +    }
> +
> +    w->slotnum = slotnum;
> +    w->path = path_copy;
> +    w->callback = func;
> +    /* we look a bit behind the curtain of LIBXL_SLIST, to explictly
> +     * assign to the pointer that's the next link.  See the comment
> +     * by the definitionn of libxl__ev_watch_slot */
> +    use->empty.sle_next = (void*)w;
> +
> +    CTX_UNLOCK;
> +    return 0;
> +
> + out_nomem:
> +    rc = ERROR_NOMEM;
> + out_rc:
> +    if (use)
> +        LIBXL_SLIST_INSERT_HEAD(&CTX->watch_freeslots, use, empty);
> +
> +    free(w->path);
> +    w->path = NULL;
> +
> +    CTX_UNLOCK;
> +}
> +
> +/*
> + * osevent poll
> + */
> +
> +int libxl_osevent_beforepoll(libxl_ctx *ctx, int *nfds_io,
> +                             struct pollfd *fds, int *timeout_upd,
> +                             struct timeval now) {
> +    libxl__ev_fd *efd;
> +    int i;
> +
> +    /*
> +     * In order to be able to efficiently find the libxl__ev_fd
> +     * for a struct poll during _afterpoll, we maintain a shadow
> +     * data structure in CTX->fd_beforepolled: each slot in
> +     * the fds array corresponds to a slot in fd_beforepolled.
> +     */
> +
> +    GC_INIT(ctx);
> +    CTX_LOCK;
> +
> +    if (*nfds_io) {
> +        /*
> +         * As an optimisation, we don't touch fd_beforepolled_used
> +         * if *nfds_io is zero on entry, since in that case the
> +         * caller just wanted to know how big an array to give us.
> +         *
> +         * If !*nfds_io, the unconditional parts below are guaranteed
> +         * not to mess with fd_beforepolled... or any in_beforepolled.
> +         */
> +
> +        /* Remove all the old references into beforepolled */
> +        for (i = 0; i < CTX->fd_beforepolled_used; i++) {
> +            efd = CTX->fd_beforepolled[i];
> +            if (efd) {
> +                assert(efd->in_beforepolled == i);
> +                efd->in_beforepolled = -1;
> +                CTX->fd_beforepolled[i] = NULL;
> +            }
> +        }
> +        CTX->fd_beforepolled_used = 0;
> +
> +        /* make sure our array is as big as *nfds_io */
> +        if (CTX->fd_beforepolled_allocd < *nfds_io) {
> +            assert(*nfds_io < INT_MAX / sizeof(libxl__ev_fd*) / 2);
> +            libxl__ev_fd **newarray =
> +                realloc(CTX->fd_beforepolled, sizeof(*newarray) * *nfds_io);
> +            if (!newarray)
> +                return ERROR_NOMEM;
> +            CTX->fd_beforepolled = newarray;
> +            CTX->fd_beforepolled_allocd = *nfds_io;
> +        }
> +    }
> +
> +    int used = 0;
> +    LIBXL_LIST_FOREACH(efd, &CTX->efds, entry) {
> +        if (used < *nfds_io) {
> +            fds[used].fd = efd->fd;
> +            fds[used].events = efd->events;
> +            fds[used].revents = 0;
> +            CTX->fd_beforepolled[used] = efd;
> +            efd->in_beforepolled = used;
> +        }
> +        used++;
> +    }
> +    int rc = used <= *nfds_io ? 0 : ERROR_BUFFERFULL;
> +
> +    if (*nfds_io) {
> +        CTX->fd_beforepolled_used = used;
> +    }
> +
> +    *nfds_io = used;
> +
> +    libxl__ev_time *etime = LIBXL_TAILQ_FIRST(&CTX->etimes);
> +    if (etime) {
> +        int our_timeout;
> +        struct timeval rel;
> +        static struct timeval zero;
> +
> +        timersub(&etime->abs, &now, &rel);
> +
> +        if (timercmp(&rel, &zero, <)) {
> +            our_timeout = 0;
> +        } else if (rel.tv_sec >= 2000000) {
> +            our_timeout = 2000000000;
> +        } else {
> +            our_timeout = rel.tv_sec * 1000 + (rel.tv_usec + 999) / 1000;
> +        }
> +        if (*timeout_upd < 0 || our_timeout < *timeout_upd)
> +            *timeout_upd = our_timeout;
> +    }
> +
> +    CTX_UNLOCK;
> +    GC_FREE;
> +    return rc;
> +}
> +
> +void libxl_osevent_afterpoll(libxl_ctx *ctx, int nfds, const struct pollfd *fds,
> +                             struct timeval now) {
> +    int i;
> +    GC_INIT(ctx);
> +    CTX_LOCK;
> +
> +    assert(nfds <= CTX->fd_beforepolled_used);
> +
> +    for (i = 0; i < nfds; i++) {
> +        if (!fds[i].revents)
> +            continue;
> +
> +        libxl__ev_fd *efd = CTX->fd_beforepolled[i];
> +        if (!efd)
> +            continue;
> +
> +        assert(efd->in_beforepolled == i);
> +        assert(fds[i].fd == efd->fd);
> +
> +        int revents = fds[i].revents & efd->events;
> +        if (!revents)
> +            continue;
> +
> +        efd->func(gc, efd, efd->fd, efd->events, revents);
> +    }
> +
> +    for (;;) {
> +        libxl__ev_time *etime = LIBXL_TAILQ_FIRST(&CTX->etimes);
> +        if (!etime)
> +            break;
> +
> +        assert(!etime->infinite);
> +
> +        if (timercmp(&etime->abs, &now, >))
> +            break;
> +
> +        time_deregister(gc, etime);
> +
> +        etime->func(gc, etime, &etime->abs);
> +    }
> +
> +    CTX_UNLOCK;
> +    GC_FREE;
> +}
> +
> +
> +/*
> + * osevent hook and callback machinery
> + */
> +
> +void libxl_osevent_register_hooks(libxl_ctx *ctx,
> +                                  const libxl_osevent_hooks *hooks,
> +                                  void *user) {
> +    GC_INIT(ctx);
> +    CTX_LOCK;
> +    ctx->osevent_hooks = hooks;
> +    ctx->osevent_user = user;
> +    CTX_UNLOCK;
> +    GC_FREE;
> +}
> +
> +
> +void libxl_osevent_occurred_fd(libxl_ctx *ctx, void *for_libxl,
> +                               int fd, short events, short revents) {
> +    libxl__ev_fd *ev = for_libxl;
> +
> +    GC_INIT(ctx);
> +    CTX_LOCK;
> +    assert(!CTX->osevent_in_hook);
> +
> +    assert(fd == ev->fd);
> +    revents &= ev->events;
> +    if (revents)
> +        ev->func(gc, ev, fd, ev->events, revents);
> +
> +    CTX_UNLOCK;
> +    GC_FREE;
> +}
> +
> +void libxl_osevent_occurred_timeout(libxl_ctx *ctx, void *for_libxl) {
> +    libxl__ev_time *ev = for_libxl;
> +
> +    GC_INIT(ctx);
> +    CTX_LOCK;
> +    assert(!CTX->osevent_in_hook);
> +
> +    assert(!ev->infinite);
> +    LIBXL_TAILQ_REMOVE(&CTX->etimes, ev, entry);
> +    ev->func(gc, ev, &ev->abs);
> +
> +    CTX_UNLOCK;
> +    GC_FREE;
> +}
> +
> +void libxl__event_disaster(libxl__gc *gc, const char *msg, int errnoval,
> +                           libxl_event_type type /* may be 0 */,
> +                           const char *file, int line, const char *func) {
> +    libxl__log(CTX, XTL_CRITICAL, errnoval, file, line, func,
> +               "DISASTER in event loop: %s%s%s%s",
> +               msg,
> +               type ? " (relates to event type " : "",
> +               type ? libxl_event_type_to_string(type) : "",
> +               type ? ")" : "");
> +
> +    /*
> +     * FIXME: This should call the "disaster" hook supplied to
> +     * libxl_event_register_callbacks, which will be introduced in the
> +     * next patch.
> +     */
> +
> +    const char verybad[] =
> +        "DISASTER in event loop not handled by libxl application";
> +    LIBXL__LOG(CTX, XTL_CRITICAL, verybad);
> +    fprintf(stderr, "libxl: fatal error, exiting program: %s\n", verybad);
> +    exit(-1);
> +}
> +
> +/*
> + * Local variables:
> + * mode: C
> + * c-basic-offset: 4
> + * indent-tabs-mode: nil
> + * End:
> + */
> diff --git a/tools/libxl/libxl_event.h b/tools/libxl/libxl_event.h
> new file mode 100644
> index 0000000..25efbdf
> --- /dev/null
> +++ b/tools/libxl/libxl_event.h
> @@ -0,0 +1,199 @@
> +/*
> + * Copyright (C) 2011      Citrix Ltd.
> + * Author Ian Jackson <ian.jackson@eu.citrix.com>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU Lesser General Public License as published
> + * by the Free Software Foundation; version 2.1 only. with the special
> + * exception on linking described in file LICENSE.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU Lesser General Public License for more details.
> + */
> +
> +#ifndef LIBXL_EVENT_H
> +#define LIBXL_EVENT_H
> +
> +#include <libxl.h>
> +
> +
> +/*======================================================================*/
> +
> +/*
> + * OS event handling - passing low-level OS events to libxl
> + *
> + * Event-driven programs must use these facilities to allow libxl
> + * to become aware of readability/writeability of file descriptors
> + * and the occurrence of timeouts.
> + *
> + * There are two approaches available.  The first is appropriate for
> + * simple programs handling reasonably small numbers of domains:
> + *
> + *   for (;;) {
> + *      libxl_osevent_beforepoll(...)
> + *      poll();
> + *      libxl_osevent_afterpoll(...);
> + *      for (;;) {
> + *        r=libxl_event_check(...);
> + *        if (r==LIBXL_NOT_READY) break;
> + *        if (r) handle failure;
> + *        do something with the event;
> + *      }
> + *   }
> + *
> + * The second approach uses libxl_osevent_register_hooks and is
> + * suitable for programs which are already using a callback-based
> + * event library.
> + *
> + * An application may freely mix the two styles of interaction.
> + */
> +
> +struct pollfd;
> +
> +int libxl_osevent_beforepoll(libxl_ctx *ctx, int *nfds_io,
> +                             struct pollfd *fds, int *timeout_upd,
> +                             struct timeval now);
> +  /* The caller should provide beforepoll with some space for libxl's
> +   * fds, and tell libxl how much space is available by setting *nfds_io.
> +   * fds points to the start of this space (and fds may be a pointer into
> +   * a larger array, for example, if the application has some fds of
> +   * its own that it is interested in).
> +   *
> +   * On return *nfds_io will in any case have been updated by libxl
> +   * according to how many fds libxl wants to poll on.
> +   *
> +   * If the space was sufficient, libxl fills in fds[0..<new
> +   * *nfds_io>] suitably for poll(2), updates *timeout_upd if needed,
> +   * and returns ok.
> +   *
> +   * If space was insufficient, fds[0..<old *nfds_io>] is undefined on
> +   * return; *nfds_io on return will be greater than the value on
> +   * entry; *timeout_upd may or may not have been updated; and
> +   * libxl_osevent_beforepoll returns ERROR_BUFERFULL.  In this case
> +   * the application needs to make more space (enough space for
> +   * *nfds_io struct pollfd) and then call beforepoll again, before
> +   * entering poll(2).  Typically this will involve calling realloc.
> +   *
> +   * The application may call beforepoll with fds==NULL and
> +   * *nfds_io==0 in order to find out how much space is needed.
> +   *
> +   * *timeout_upd is as for poll(2): it's in milliseconds, and
> +   * negative values mean no timeout (infinity).
> +   * libxl_osevent_beforepoll will only reduce the timeout, naturally.
> +   */

so far we have always added the comment on a function above the
declaration of the function; we should keep doing it for consistency


> +void libxl_osevent_afterpoll(libxl_ctx *ctx, int nfds, const struct pollfd *fds,
> +                             struct timeval now);
> +  /* nfds and fds[0..nfds] must be from the most recent call to
> +   * _beforepoll, as modified by poll.
> +   *
> +   * This function actually performs all of the IO and other actions,
> +   * and generates events (libxl_event), which are implied by either
> +   * (a) the time of day or (b) both (i) the returned information from
> +   * _beforepoll, and (ii) the results from poll specified in
> +   * fds[0..nfds-1].  Generated events can then be retrieved by
> +   * libxl_event_check.
> +   */
> +

I see that the implementation of libxl_event_check is actually missing
from this patch.
Is this patch supposed to compiled, even without the actual libxl_event
generation? Or are the two patches have to be committed together?


> +typedef struct libxl_osevent_hooks {
> +  int (*fd_register)(void *uselibxl_event_check.r, int fd, void **for_app_registration_out,
> +                     short events, void *for_libxl);
> +  int (*fd_modify)(void *user, int fd, void **for_app_registration_update,
> +                   short events);
> +  void (*fd_deregister)(void *user, int fd, void *for_app_registration);
> +  int (*timeout_register)(void *user, void **for_app_registration_out,
> +                          struct timeval abs, void *for_libxl);
> +  int (*timeout_modify)(void *user, void **for_app_registration_update,
> +                         struct timeval abs);
> +  void (*timeout_deregister)(void *user, void *for_app_registration_io);
> +} libxl_osevent_hooks;
> +
> +void libxl_osevent_register_hooks(libxl_ctx *ctx,
> +                                  const libxl_osevent_hooks *hooks,
> +                                  void *user);
> +  /* The application which calls register_fd_hooks promises to
> +   * maintain a register of fds and timeouts that libxl is interested
> +   * in, and make calls into libxl (libxl_osevent_occurred_*)
> +   * when those fd events and timeouts occur.  This is more efficient
> +   * than _beforepoll/_afterpoll if there are many fds (which can
> +   * happen if the same libxl application is managing many domains).
> +   *
> +   * For an fd event, events is as for poll().  register or modify may
> +   * be called with events==0, in which case it must still work
> +   * normally, just not generate any events.
> +   *
> +   * For a timeout event, milliseconds is as for poll().
> +   * Specifically, negative values of milliseconds mean NO TIMEOUT.
> +   * This is used by libxl to temporarily disable a timeout.
> +   *
> +   * If the register or modify hook succeeds it may update
> +   * *for_app_registration_out/_update and must then return 0.
> +   * On entry to register, *for_app_registration_out is always NULL.
> +   *
> +   * A registration or modification hook may fail, in which case it
> +   * must leave the registration state of the fd or timeout unchanged.
> +   * It may then either return ERROR_OSEVENT_REG_FAIL or any positive
> +   * int.  The value returned will be passed up through libxl and
> +   * eventually returned back to the application.  When register
> +   * fails, any value stored into *for_registration_out is ignored by
> +   * libxl; when modify fails, any changed value stored into
> +   * *for_registration_update is honoured by libxl and will be passed
> +   * to future modify or deregister calls.
> +   *
> +   * libxl will only attempt to register one callback for any one fd.
> +   * libxl will remember the value stored in *for_app_registration_io
> +   * by a successful call to register or modify and pass it into
> +   * subsequent calls to modify or deregister.
> +   *
> +   * register_fd_hooks may be called only once for each libxl_ctx.
> +   * libxl may make calls to register/modify/deregister from within
> +   * any libxl function (indeed, it will usually call register from
> +   * register_event_hooks).  Conversely, the application MUST NOT make
> +   * the event occurrence calls (libxl_osevent_occurred_*) into libxl
> +   * reentrantly from within libxl (for example, from within the
> +   * register/modify functions).
> +   *
> +   * Lock hierarchy: the register/modify/deregister functions may be
> +   * called with locks held.  These locks (the "libxl internal locks")
> +   * are inside the libxl_ctx.  Therefore, if those register functions
> +   * acquire any locks of their own ("caller register locks") outside
> +   * libxl, to avoid deadlock one of the following must hold for each
> +   * such caller register lock:
> +   *  (a) "acquire libxl internal locks before caller register lock":
> +   *      No libxl function may be called with the caller register
> +   *      lock held.
> +   *  (b) "acquire caller register lock before libxl internal locks":
> +   *      No libxl function may be called _without_ the caller
> +   *      register lock held.
> +   * Of these we would normally recommend (a).
> +   *
> +   * The value *hooks is not copied and must outlast the libxl_ctx.
> +   */

while this description is very verbose, it doesn't contain informations
on:

- what is void *user;
- what is "const libxl_osevent_hooks *hooks", in particular the role of
  each  of these function pointers and the description of their
  arguments.

If I am a user of the library, how am I supposed to pass as user? and as
hooks?
I think these few lines should go first, then the description of the
contract.


> +/* It is NOT legal to call _occurred_ reentrantly within any libxl
> + * function.  Specifically it is NOT legal to call it from within
> + * a register callback.  Conversely, libxl MAY call register/deregister
> + * from within libxl_event_registered_call_*.
> + */
> +
> +void libxl_osevent_occurred_fd(libxl_ctx *ctx, void *for_libxl,
> +                               int fd, short events, short revents);
> +
> +void libxl_osevent_occurred_timeout(libxl_ctx *ctx, void *for_libxl);
> +  /* Implicitly, on entry to this function the timeout has been
> +   * deregistered.  If _occurred_timeout is called, libxl will not
> +   * call timeout_deregister; if it wants to requeue the timeout it
> +   * will call timeout_register again.
> +   */
> +
> +#endif
> +
> +/*
> + * Local variables:
> + * mode: C
> + * c-basic-offset: 4
> + * indent-tabs-mode: nil
> + * End:
> + */
> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> index d015c7c..88e7dbb 100644
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
> @@ -24,6 +24,9 @@
>  #include <stdlib.h>
>  #include <string.h>
>  #include <pthread.h>
> +#include <inttypes.h>
> +#include <assert.h>
> +#include <sys/poll.h>
> 
>  #include <xs.h>
>  #include <xenctrl.h>
> @@ -91,6 +94,66 @@ _hidden void libxl__log(libxl_ctx *ctx, xentoollog_level msglevel, int errnoval,
> 
>       /* these functions preserve errno (saving and restoring) */
> 
> +typedef struct libxl__gc libxl__gc;
> +
> +typedef struct libxl__ev_fd libxl__ev_fd;
> +typedef void libxl__ev_fd_callback(libxl__gc *gc, libxl__ev_fd *ev,
> +                                   int fd, short events, short revents);
> +struct libxl__ev_fd {
> +    /* all private for libxl__ev_fd... */
> +    LIBXL_LIST_ENTRY(libxl__ev_fd) entry;
> +    int fd;
> +    short events;
> +    int in_beforepolled; /* -1 means not in fd_beforepolled */
> +    void *for_app_reg;
> +    libxl__ev_fd_callback *func;
> +};
> +
> +
> +typedef struct libxl__ev_time libxl__ev_time;
> +typedef void libxl__ev_time_callback(libxl__gc *gc, libxl__ev_time *ev,
> +                                     const struct timeval *requested_abs);
> +struct libxl__ev_time {
> +    /* all private for libxl__ev_time... */
> +    int infinite; /* not registered in list or with app if infinite */
> +    LIBXL_TAILQ_ENTRY(libxl__ev_time) entry;
> +    struct timeval abs;
> +    void *for_app_reg;
> +    libxl__ev_time_callback *func;
> +};
> +
> +typedef struct libxl__ev_xswatch libxl__ev_xswatch;
> +typedef void libxl__ev_xswatch_callback(libxl__gc *gc, libxl__ev_xswatch*,
> +                            const char *watch_path, const char *event_path);
> +struct libxl__ev_xswatch {
> +    /* caller should include this in their own struct */
> +    /* contents are private to xswatch_register */
> +    int slotnum;
> +    uint32_t counterval;
> +    char *path;
> +    libxl__ev_xswatch_callback *callback;
> +};
> +
> +/*
> + * An entry in the watch_slots table is either:
> + *  1. an entry in the free list, ie NULL or pointer to next free list entry
> + *  2. an pointer to a libxl__ev_xswatch
> + *
> + * But we don't want to use unions or type-punning because the
> + * compiler might "prove" that our code is wrong and misoptimise it.
> + *
> + * The rules say that all struct pointers have identical
> + * representation and alignment requirements (C99+TC1+TC2 6.2.5p26) so
> + * what we do is simply declare our array as containing only the free
> + * list pointers, and explicitly convert from and to our actual
> + * xswatch pointers when we store and retrieve them.
> + */
> +typedef struct libxl__ev_watch_slot {
> +    LIBXL_SLIST_ENTRY(struct libxl__ev_watch_slot) empty;
> +} libxl__ev_watch_slot;
> +
> +libxl__ev_xswatch *libxl__watch_slot_contents(libxl__gc *gc, int slotnum);
> +
>  struct libxl__ctx {
>      xentoollog_logger *lg;
>      xc_interface *xch;
> @@ -108,6 +171,23 @@ struct libxl__ctx {
>         * documented in the libxl public interface.
>         */
> 
> +    int osevent_in_hook;
> +    const libxl_osevent_hooks *osevent_hooks;
> +    void *osevent_user;
> +      /* See the comment for OSEVENT_HOOK_INTERN in libxl_event.c
> +       * for restrictions on the use of the osevent fields. */
> +
> +    int fd_beforepolled_allocd, fd_beforepolled_used;
> +    libxl__ev_fd **fd_beforepolled; /* see libxl_osevent_beforepoll */
> +    LIBXL_LIST_HEAD(, libxl__ev_fd) efds;
> +    LIBXL_TAILQ_HEAD(, libxl__ev_time) etimes;
> +
> +    libxl__ev_watch_slot *watch_slots;
> +    int watch_nslots;
> +    LIBXL_SLIST_HEAD(, libxl__ev_watch_slot) watch_freeslots;
> +    uint32_t watch_counter; /* helps disambiguate slot reuse */
> +    libxl__ev_fd watch_efd;
> +
>      /* for callers who reap children willy-nilly; caller must only
>       * set this after libxl_init and before any other call - or
>       * may leave them untouched */
> @@ -138,12 +218,12 @@ typedef struct {
> 
>  #define PRINTF_ATTRIBUTE(x, y) __attribute__((format(printf, x, y)))
> 
> -typedef struct {
> +struct libxl__gc {
>      /* mini-GC */
>      int alloc_maxsize;
>      void **alloc_ptrs;
>      libxl_ctx *owner;
> -} libxl__gc;
> +};
> 
>  #define LIBXL_INIT_GC(gc,ctx) do{               \
>          (gc).alloc_maxsize = 0;                 \
> @@ -209,9 +289,137 @@ _hidden char *libxl__xs_read(libxl__gc *gc, xs_transaction_t t,
>  _hidden char **libxl__xs_directory(libxl__gc *gc, xs_transaction_t t,
>                                     const char *path, unsigned int *nb);
>     /* On error: returns NULL, sets errno (no logging) */
> -
>  _hidden char *libxl__xs_libxl_path(libxl__gc *gc, uint32_t domid);
> 
> +
> +/*
> + * Event generation functions provided by the libxl event core to the
> + * rest of libxl.  Implemented in terms of _beforepoll/_afterpoll
> + * and/or the fd registration machinery, as provided by the
> + * application.
> + *
> + * Semantics are similar to those of the fd and timeout registration
> + * functions provided to libxl_osevent_register_hooks.
> + *
> + * Non-0 returns from libxl__ev_{modify,deregister} have already been
> + * logged by the core and should be returned unmodified to libxl's
> + * caller; NB that they may be valid libxl error codes but they may
> + * also be positive numbers supplied by the caller.
> + *
> + * In each case, there is a libxl__ev_FOO structure which can be in
> + * one of three states:
> + *
> + *   Undefined   - Might contain anything.  All-bits-zero is
> + *                 an undefined state.
> + *
> + *   Idle        - Struct contents are defined enough to pass to any
> + *                 libxl__ev_FOO function but not registered and
> + *                 callback will not be called.  The struct does not
> + *                 contain references to any allocated resources so
> + *                 can be thrown away.
> + *
> + *   Active      - Request for events has been registered and events
> + *                 may be generated.  _deregister must be called to
> + *                 reclaim resources.
> + *
> + * These functions are provided for each kind of event KIND:
> + *
> + *   int libxl__ev_KIND_register(libxl__gc *gc, libxl__ev_KIND *GEN,
> + *                              libxl__ev_KIND_callback *FUNC,
> + *                              DETAILS);
> + *      On entry *GEN must be in state Undefined or Idle.
> + *      Returns a libxl error code; on error return *GEN is Idle.
> + *      On successful return *GEN is Active and FUNC wil be
> + *      called by the event machinery in future.  FUNC will
> + *      not be called from within the call to _register.
> + *
> + *  void libxl__ev_KIND_deregister(libxl__gc *gc, libxl__ev_KIND *GEN_upd);
> + *      On entry *GEN must be in state Active or Idle.
> + *      On return it is Idle.  (Idempotent.)
> + *
> + *  void libxl__ev_KIND_init(libxl__ev_KIND *GEN);
> + *      Provided for initialising an Undefined KIND.
> + *      On entry *GEN must be in state Idle or Undefined.
> + *      On return it is Idle.  (Idempotent.)
> + *
> + *  int libxl__ev_KIND_isregistered(const libxl__ev_KIND *GEN);
> + *      On entry *GEN must be Idle or Active.
> + *      Returns nonzero if it is Active, zero otherwise.
> + *      Cannot fail.
> + *
> + *  int libxl__ev_KiND_modify(libxl__gc*, libxl__ev_KIND *GEN,
> + *                            DETAILS);
> + *      Only provided for some kinds of generator.
> + *      On entry *GEN must be Active and on return, whether successful
> + *      or not, it will be Active.
> + *      Returns a libxl error code; on error the modification
> + *      is not effective.
> + *
> + * All of these functions are fully threadsafe and may be called by
> + * general code in libxl even from within event callback FUNCs.
> + */
> +
> +
> +_hidden int libxl__ev_fd_register(libxl__gc*, libxl__ev_fd *ev_out,
> +                                  libxl__ev_fd_callback*,
> +                                  int fd, short events /* as for poll(2) */);
> +_hidden int libxl__ev_fd_modify(libxl__gc*, libxl__ev_fd *ev,
> +                                short events);
> +_hidden void libxl__ev_fd_deregister(libxl__gc*, libxl__ev_fd *ev);
> +static inline void libxl__ev_fd_init(libxl__ev_fd *efd)
> +                    { efd->fd = -1; }
> +static inline int libxl__ev_fd_isregistered(libxl__ev_fd *efd)
> +                    { return efd->fd >= 0; }
> +
> +_hidden int libxl__ev_time_register_rel(libxl__gc*, libxl__ev_time *ev_out,
> +                                        libxl__ev_time_callback*,
> +                                        int milliseconds /* as for poll(2) */);
> +_hidden int libxl__ev_time_register_abs(libxl__gc*, libxl__ev_time *ev_out,
> +                                        libxl__ev_time_callback*,
> +                                        struct timeval);
> +_hidden int libxl__ev_time_modify_rel(libxl__gc*, libxl__ev_time *ev,
> +                                      int milliseconds /* as for poll(2) */);
> +_hidden int libxl__ev_time_modify_abs(libxl__gc*, libxl__ev_time *ev,
> +                                      struct timeval);
> +_hidden void libxl__ev_time_deregister(libxl__gc*, libxl__ev_time *ev);
> +static inline void libxl__ev_time_init(libxl__ev_time *ev)
> +                { ev->func = 0; }
> +static inline int libxl__ev_time_isregistered(libxl__ev_time *ev)
> +                { return !!ev->func; }
> +
> +
> +_hidden int libxl__ev_xswatch_register(libxl__gc*, libxl__ev_xswatch *xsw_out,
> +                                       libxl__ev_xswatch_callback*,
> +                                       const char *path /* copied */);
> +_hidden void libxl__ev_xswatch_deregister(libxl__gc *gc, libxl__ev_xswatch*);
> +
> +static inline void libxl__ev_xswatch_init(libxl__ev_xswatch *xswatch_out)
> +                { xswatch_out->slotnum = -1; }
> +static inline int libxl__ev_xswatch_isregistered(const libxl__ev_xswatch *xw)
> +                { return xw->slotnum >= 0; }
> +
> +
> +
> +_hidden void libxl__event_disaster(libxl__gc*, const char *msg, int errnoval,
> +                                   libxl_event_type type /* may be 0 */,
> +                                   const char *file, int line,
> +                                   const char *func);
> +  /*
> +   * In general, call this via the macro LIBXL__EVENT_DISASTER.
> +   *
> +   * Event-generating functions may call this if they might have
> +   * wanted to generate an event (either an internal one ie a
> +   * libxl__ev_FOO_callback or an application event), but are
> +   * prevented from doing so due to eg lack of memory.
> +   *
> +   * NB that this function may return and the caller isn't supposed to
> +   * then crash, although it may fail (and henceforth leave things in
> +   * a state where many or all calls fail).
> +   */
> +#define LIBXL__EVENT_DISASTER(gc, msg, errnoval, type) \
> +    libxl__event_disaster(gc, msg, errnoval, type, __FILE__, __LINE__, __func__)

any reason why this shouldn't be a static inline?

> +
>  /* from xl_dom */
>  _hidden libxl_domain_type libxl__domain_type(libxl__gc *gc, uint32_t domid);
>  _hidden int libxl__domain_shutdown_reason(libxl__gc *gc, uint32_t domid);
> @@ -536,6 +744,8 @@ _hidden int libxl__parse_mac(const char *s, libxl_mac mac);
>  /* compare mac address @a and @b. 0 if the same, -ve if a<b and +ve if a>b */
>  _hidden int libxl__compare_macs(libxl_mac *a, libxl_mac *b);
> 
> +_hidden int libxl__gettimeofday(libxl__gc *gc, struct timeval *now_r);
> +
>  #define STRINGIFY(x) #x
>  #define TOSTRING(x) STRINGIFY(x)
> 
> --
> 1.7.2.5
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 15:47:01 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 15: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.xensource.com>)
	id 1RZ2ej-0002ev-H3; Fri, 09 Dec 2011 15:46:37 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RZ2eh-0002ec-9N
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 15:46:35 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1323445432!6731336!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI2MQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6259 invoked from network); 9 Dec 2011 15:43:52 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 15:43:52 -0000
X-IronPort-AV: E=Sophos;i="4.71,326,1320624000"; 
   d="scan'208";a="9388657"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 15:43:52 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 15:43:52 +0000
Date: Fri, 9 Dec 2011 15:44:27 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Jackson <ian.jackson@eu.citrix.com>
In-Reply-To: <1323108621-22654-15-git-send-email-ian.jackson@eu.citrix.com>
Message-ID: <alpine.DEB.2.00.1112091504060.3517@kaball-desktop>
References: <1323108621-22654-1-git-send-email-ian.jackson@eu.citrix.com>
	<1323108621-22654-15-git-send-email-ian.jackson@eu.citrix.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 14/15] libxl: New API for providing OS
 events to libxl
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 5 Dec 2011, Ian Jackson wrote:
> We provide a new set of functions and related structures
>   libxl_osevent_*
> which are to be used by event-driven applications to receive
> information from libxl about which fds libxl is interested in, and
> what timeouts libxl is waiting for, and to pass back to libxl
> information about which fds are readable/writeable etc., and which
> timeouts have occurred.  Ie, low-level events.
> 
> In this patch, this new machinery is still all unused.  Callers will
> appear in the next patch in the series, which introduces a new API for
> applications to receive high-level events about actual domains etc.
> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
> ---
>  tools/libxl/Makefile         |    2 +-
>  tools/libxl/libxl.c          |   25 ++
>  tools/libxl/libxl.h          |    6 +
>  tools/libxl/libxl_event.c    |  711 ++++++++++++++++++++++++++++++++++++++++++
>  tools/libxl/libxl_event.h    |  199 ++++++++++++
>  tools/libxl/libxl_internal.h |  216 +++++++++++++-
>  6 files changed, 1155 insertions(+), 4 deletions(-)
>  create mode 100644 tools/libxl/libxl_event.c
>  create mode 100644 tools/libxl/libxl_event.h
> 
> diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
> index 4e0f3fb..3d575b8 100644
> --- a/tools/libxl/Makefile
> +++ b/tools/libxl/Makefile
> @@ -38,7 +38,7 @@ LIBXL_LIBS += -lyajl
>  LIBXL_OBJS = flexarray.o libxl.o libxl_create.o libxl_dm.o libxl_pci.o \
>                         libxl_dom.o libxl_exec.o libxl_xshelp.o libxl_device.o \
>                         libxl_internal.o libxl_utils.o libxl_uuid.o libxl_json.o \
> -                       libxl_qmp.o $(LIBXL_OBJS-y)
> +                       libxl_qmp.o libxl_event.o $(LIBXL_OBJS-y)
>  LIBXL_OBJS += _libxl_types.o libxl_flask.o _libxl_types_internal.o
> 
>  $(LIBXL_OBJS): CFLAGS += $(CFLAGS_libxenctrl) $(CFLAGS_libxenguest) $(CFLAGS_libxenstore) $(CFLAGS_libblktapctl)
> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> index 3a8cfe3..58f280c 100644
> --- a/tools/libxl/libxl.c
> +++ b/tools/libxl/libxl.c
> @@ -60,6 +60,16 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
>       * only as an initialiser, not as an expression. */
>      memcpy(&ctx->lock, &mutex_value, sizeof(ctx->lock));
> 
> +    ctx->osevent_hooks = 0;
> +
> +    ctx->fd_beforepolled = 0;
> +    LIBXL_LIST_INIT(&ctx->efds);
> +    LIBXL_TAILQ_INIT(&ctx->etimes);
> +
> +    ctx->watch_slots = 0;
> +    LIBXL_SLIST_INIT(&ctx->watch_freeslots);
> +    libxl__ev_fd_init(&ctx->watch_efd);
> +
>      if ( stat(XENSTORE_PID_FILE, &stat_buf) != 0 ) {
>          LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "Is xenstore daemon running?\n"
>                       "failed to stat %s", XENSTORE_PID_FILE);
> @@ -89,10 +99,25 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
> 
>  int libxl_ctx_free(libxl_ctx *ctx)
>  {
> +    int i;
> +    GC_INIT(ctx);
> +
>      if (!ctx) return 0;
> +
> +    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_LIST_EMPTY(&ctx->efds));
> +    assert(LIBXL_TAILQ_EMPTY(&ctx->etimes));
> +
>      if (ctx->xch) xc_interface_close(ctx->xch);
>      libxl_version_info_dispose(&ctx->version_info);
>      if (ctx->xsh) xs_daemon_close(ctx->xsh);
> +
> +    free(ctx->fd_beforepolled);
> +    free(ctx->watch_slots);
> +
>      return 0;
>  }
> 
> diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
> index 289dc85..654a5b0 100644
> --- a/tools/libxl/libxl.h
> +++ b/tools/libxl/libxl.h
> @@ -137,6 +137,7 @@
>  #include <xen/sysctl.h>
> 
>  #include <libxl_uuid.h>
> +#include <_libxl_list.h>
> 
>  typedef uint8_t libxl_mac[6];
>  #define LIBXL_MAC_FMT "%02hhx:%02hhx:%02hhx:%02hhx:%02hhx:%02hhx"
> @@ -222,6 +223,9 @@ enum {
>      ERROR_BADFAIL = -7,
>      ERROR_GUEST_TIMEDOUT = -8,
>      ERROR_TIMEDOUT = -9,
> +    ERROR_NOT_READY = -10,
> +    ERROR_OSEVENT_REG_FAIL = -11,
> +    ERROR_BUFFERFULL = -12,
>  };
> 
>  #define LIBXL_VERSION 0
> @@ -635,6 +639,8 @@ const char *libxl_lock_dir_path(void);
>  const char *libxl_run_dir_path(void);
>  const char *libxl_xenpaging_dir_path(void);
> 
> +#include <libxl_event.h>
> +
>  #endif /* LIBXL_H */
> 
>  /*
> diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
> new file mode 100644
> index 0000000..8d4dbf6
> --- /dev/null
> +++ b/tools/libxl/libxl_event.c
> @@ -0,0 +1,711 @@
> +/*
> + * Copyright (C) 2011      Citrix Ltd.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU Lesser General Public License as published
> + * by the Free Software Foundation; version 2.1 only. with the special
> + * exception on linking described in file LICENSE.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU Lesser General Public License for more details.
> + */
> +/*
> + * Internal event machinery for use by other parts of libxl
> + */
> +
> +#include <poll.h>
> +
> +#include "libxl_internal.h"
> +
> +/*
> + * The counter osevent_in_hook is used to ensure that the application
> + * honours the reentrancy restriction documented in libxl_event.h.
> + *
> + * The application's registration hooks should be called ONLY via
> + * these macros, with the ctx locked.  Likewise all the "occurred"
> + * entrypoints from the application should assert(!in_hook);
> + */
> +#define OSEVENT_HOOK_INTERN(defval, hookname, ...)                      \
> +    (CTX->osevent_hooks                                                 \
> +     ? (CTX->osevent_in_hook++,                                         \
> +        CTX->osevent_hooks->hookname(CTX->osevent_user, __VA_ARGS__),   \
> +        CTX->osevent_in_hook--)                                         \
> +     : defval)
> +
> +#define OSEVENT_HOOK(hookname,...)                      \
> +    OSEVENT_HOOK_INTERN(0, hookname, __VA_ARGS__)
> +
> +#define OSEVENT_HOOK_VOID(hookname,...)                 \
> +    OSEVENT_HOOK_INTERN((void)0, hookname, __VA_ARGS__)

Is there any reasons why we cannot use static inline functions here?


> +/*
> + * fd events
> + */
> +
> +int libxl__ev_fd_register(libxl__gc *gc, libxl__ev_fd *ev,
> +                          libxl__ev_fd_callback *func,
> +                          int fd, short events) {
> +    int rc;
> +
> +    assert(fd >= 0);
> +
> +    CTX_LOCK;
> +
> +    rc = OSEVENT_HOOK(fd_register, fd, &ev->for_app_reg, events, ev);
> +    if (rc) goto out;
> +
> +    LIBXL_LIST_INSERT_HEAD(&CTX->efds, ev, entry);
> +
> +    ev->fd = fd;
> +    ev->events = events;
> +    ev->in_beforepolled = -1;
> +    ev->func = func;
> +
> +    rc = 0;
> +
> + out:
> +    CTX_UNLOCK;
> +    return rc;
> +}
> +
> +int libxl__ev_fd_modify(libxl__gc *gc, libxl__ev_fd *ev, short events) {
> +    int rc;
> +
> +    CTX_LOCK;
> +    assert(libxl__ev_fd_isregistered(ev));
> +
> +    rc = OSEVENT_HOOK(fd_modify, ev->fd, &ev->for_app_reg, events);
> +    if (rc) goto out;
> +
> +    ev->events = events;
> +
> +    rc = 0;
> + out:
> +    CTX_UNLOCK;
> +    return rc;
> +}
> +
> +void libxl__ev_fd_deregister(libxl__gc *gc, libxl__ev_fd *ev) {
> +    CTX_LOCK;
> +
> +    if (!libxl__ev_fd_isregistered(ev))
> +        goto out;
> +
> +    OSEVENT_HOOK_VOID(fd_deregister, ev->fd, ev->for_app_reg);
> +    LIBXL_LIST_REMOVE(ev, entry);
> +    ev->fd = -1;
> +
> +    if (ev->in_beforepolled >= 0 &&
> +        ev->in_beforepolled < CTX->fd_beforepolled_used)
> +        /* remove stale reference */
> +        CTX->fd_beforepolled[ev->in_beforepolled] = NULL;
> +
> + out:
> +    CTX_UNLOCK;
> +}
> +
> +/*
> + * timeouts
> + */
> +
> +
> +int libxl__gettimeofday(libxl__gc *gc, struct timeval *now_r) {
> +    int rc = gettimeofday(now_r, 0);
> +    if (rc) {
> +        LIBXL__LOG_ERRNO(CTX, LIBXL__LOG_ERROR, "gettimeofday failed");
> +        return ERROR_FAIL;
> +    }
> +    return 0;
> +}
> +
> +static int time_rel_to_abs(libxl__gc *gc, int ms, struct timeval *abs_out) {
> +    int rc;
> +    struct timeval additional = {
> +        .tv_sec = ms / 1000,
> +        .tv_usec = (ms % 1000) * 1000
> +    };
> +    struct timeval now;
> +
> +    rc = libxl__gettimeofday(gc, &now);
> +    if (rc) return rc;
> +
> +    timeradd(&now, &additional, abs_out);
> +    return 0;
> +}
> +
> +static void time_insert_finite(libxl__gc *gc, libxl__ev_time *ev) {
> +    libxl__ev_time *evsearch;
> +    LIBXL_TAILQ_INSERT_SORTED(&CTX->etimes, entry, ev, evsearch, ,
> +                              timercmp(&ev->abs, &evsearch->abs, >));
> +    ev->infinite = 0;
> +}
> +
> +static int time_register_finite(libxl__gc *gc, libxl__ev_time *ev,
> +                                struct timeval abs) {
> +    int rc;
> +
> +    rc = OSEVENT_HOOK(timeout_register, &ev->for_app_reg, abs, ev);
> +    if (rc) return rc;
> +
> +    ev->infinite = 0;
> +    ev->abs = abs;
> +    time_insert_finite(gc, ev);
> +
> +    return 0;
> +}
> +
> +static void time_deregister(libxl__gc *gc, libxl__ev_time *ev) {
> +    if (!ev->infinite) {
> +        OSEVENT_HOOK_VOID(timeout_deregister, &ev->for_app_reg);
> +        LIBXL_TAILQ_REMOVE(&CTX->etimes, ev, entry);
> +    }
> +}
> +
> +
> +int libxl__ev_time_register_abs(libxl__gc *gc, libxl__ev_time *ev,
> +                                libxl__ev_time_callback *func,
> +                                struct timeval abs) {
> +    int rc;
> +
> +    CTX_LOCK;
> +
> +    rc = time_register_finite(gc, ev, abs);
> +    if (rc) goto out;
> +
> +    ev->func = func;
> +
> +    rc = 0;
> + out:
> +    CTX_UNLOCK;
> +    return rc;
> +}
> +
> +
> +int libxl__ev_time_register_rel(libxl__gc *gc, libxl__ev_time *ev,
> +                                libxl__ev_time_callback *func,
> +                                int milliseconds /* as for poll(2) */) {
> +    struct timeval abs;
> +    int rc;
> +
> +    CTX_LOCK;
> +
> +    if (milliseconds < 0) {
> +        ev->infinite = 1;
> +    } else {
> +        rc = time_rel_to_abs(gc, milliseconds, &abs);
> +        if (rc) goto out;
> +
> +        rc = time_register_finite(gc, ev, abs);
> +        if (rc) goto out;
> +    }
> +
> +    ev->func = func;
> +    rc = 0;
> +
> + out:
> +    CTX_UNLOCK;
> +    return 0;
> +}
> +
> +int libxl__ev_time_modify_abs(libxl__gc *gc, libxl__ev_time *ev,
> +                              struct timeval abs) {
> +    int rc;
> +
> +    CTX_LOCK;
> +
> +    assert(libxl__ev_time_isregistered(ev));
> +
> +    if (ev->infinite) {
> +        rc = time_register_finite(gc, ev, abs);
> +        if (rc) goto out;
> +    } else {
> +        rc = OSEVENT_HOOK(timeout_modify, &ev->for_app_reg, abs);
> +        if (rc) goto out;
> +
> +        LIBXL_TAILQ_REMOVE(&CTX->etimes, ev, entry);
> +        ev->abs = abs;
> +        time_insert_finite(gc, ev);
> +    }
> +
> +    rc = 0;
> + out:
> +    CTX_UNLOCK;
> +    return rc;
> +}
> +
> +int libxl__ev_time_modify_rel(libxl__gc *gc, libxl__ev_time *ev,
> +                              int milliseconds) {
> +    struct timeval abs;
> +    int rc;
> +
> +    CTX_LOCK;
> +
> +    assert(libxl__ev_time_isregistered(ev));
> +
> +    if (milliseconds < 0) {
> +        time_deregister(gc, ev);
> +        ev->infinite = 1;
> +        rc = 0;
> +        goto out;
> +    }
> +
> +    rc = time_rel_to_abs(gc, milliseconds, &abs);
> +    if (rc) goto out;
> +
> +    rc = libxl__ev_time_modify_abs(gc, ev, abs);
> +    if (rc) goto out;
> +
> +    rc = 0;
> + out:
> +    CTX_UNLOCK;
> +    return 0;
> +}
> +
> +void libxl__ev_time_deregister(libxl__gc *gc, libxl__ev_time *ev) {
> +    CTX_LOCK;
> +
> +    if (!libxl__ev_time_isregistered(ev))
> +        goto out;
> +
> +    time_deregister(gc, ev);
> +    ev->func = 0;
> +
> + out:
> +    CTX_UNLOCK;
> +    return;
> +}
> +
> +
> +/*
> + * xenstore watches
> + */
> +
> +libxl__ev_xswatch *libxl__watch_slot_contents(libxl__gc *gc, int slotnum) {
> +    libxl__ev_watch_slot *slot = &CTX->watch_slots[slotnum];
> +    libxl__ev_watch_slot *slotcontents = LIBXL_SLIST_NEXT(slot, empty);
> +
> +    if (slotcontents == NULL ||
> +        ((uintptr_t)slotcontents >= (uintptr_t)CTX->watch_slots &&
> +         (uintptr_t)slotcontents < (uintptr_t)(CTX->watch_slots +
> +                                               CTX->watch_nslots)))
> +        /* An empty slot has either a NULL pointer (end of the
> +         * free list), or a pointer to another entry in the array.
> +         * So we can do a bounds check to distinguish empty from
> +         * full slots.
> +         */
> +        /* We need to do the comparisons as uintptr_t because
> +         * comparing pointers which are not in the same object is
> +         * undefined behaviour; if the compiler managed to figure
> +         * out that watch_slots[0..watch_nslots-1] is all of the
> +         * whole array object it could prove that the above bounds
> +         * check was always true if it was legal, and remove it!
> +         *
> +         * uintptr_t because even on a machine with signed
> +         * pointers, objects do not cross zero; whereas on
> +         * machines with unsigned pointers, they may cross
> +         * 0x8bazillion.
> +         */
> +        return NULL;
> +
> +        /* see comment near libxl__ev_watch_slot definition */
> +    return (void*)slotcontents;
> +}
> +
> +static void watchfd_callback(libxl__gc *gc, libxl__ev_fd *ev,
> +                             int fd, short events, short revents) {
> +    for (;;) {
> +        char **event = xs_check_watch(CTX->xsh);
> +        if (!event) {
> +            if (errno == EAGAIN) break;
> +            if (errno == EINTR) continue;
> +            LIBXL__EVENT_DISASTER(gc, "cannot check/read watches", errno, 0);
> +            return;
> +        }
> +
> +        const char *epath = event[0];
> +        const char *token = event[1];
> +        int slotnum;
> +        uint32_t counterval;

OK, this is the last time I am going to point this out, but epath,
token, etc, should be declared above, at the beginning of the block.


> +        int rc = sscanf(token, "%d/%"SCNx32, &slotnum, &counterval);
> +        if (rc != 2) {
> +            LIBXL__LOG(CTX, LIBXL__LOG_ERROR,
> +                       "watch epath=%s token=%s: failed to parse token",
> +                       epath, token);
> +            /* oh well */
> +            goto ignore;
> +        }
> +        if (slotnum < 0 || slotnum >= CTX->watch_nslots) {
> +            /* perhaps in the future we will make the watchslots array shrink */
> +            LIBXL__LOG(CTX, LIBXL__LOG_DEBUG, "watch epath=%s token=%s:"
> +                       " slotnum %d out of range [0,%d>",
> +                       epath, token, slotnum, CTX->watch_nslots);
> +            goto ignore;
> +        }
> +
> +        libxl__ev_xswatch *w = libxl__watch_slot_contents(gc, slotnum);
> +
> +        if (!w) {
> +            LIBXL__LOG(CTX, LIBXL__LOG_DEBUG,
> +                       "watch epath=%s token=%s: empty slot",
> +                       epath, token);
> +            goto ignore;
> +        }
> +
> +        if (w->counterval != counterval) {
> +            LIBXL__LOG(CTX, LIBXL__LOG_DEBUG,
> +                       "watch epath=%s token=%s: counter != %"PRIx32,
> +                       epath, token, w->counterval);
> +            goto ignore;
> +        }
> +
> +        /* Now it's possible, though unlikely, that this was an event
> +         * from a previous use of the same slot with the same counterval.
> +         *
> +         * In that case either:
> +         *  - the event path is a child of the watch path, in
> +         *    which case this watch would really have generated this
> +         *    event if it had been registered soon enough and we are
> +         *    OK to give this possibly-spurious event to the caller; or
> +         * - it is not, in which case we must suppress it as the
> +         *   caller should not see events for unrelated paths.
> +         *
> +         * See also docs/misc/xenstore.txt.
> +         */
> +        size_t epathlen = strlen(epath);
> +        size_t wpathlen = strlen(w->path);
> +        if (epathlen < wpathlen ||
> +            memcmp(epath, w->path, wpathlen) ||
> +            (epathlen > wpathlen && epath[wpathlen] != '/')) {
> +            LIBXL__LOG(CTX, LIBXL__LOG_DEBUG,
> +                       "watch epath=%s token=%s: not child of wpath=%s",
> +                       epath, token, w->path);
> +            goto ignore;
> +        }
> +
> +        /* At last, we have checked everything! */
> +        LIBXL__LOG(CTX, LIBXL__LOG_DEBUG,
> +                   "watch event: epath=%s token=%s wpath=%s w=%p",
> +                   epath, token, w->path, w);
> +        w->callback(gc, w, w->path, epath);
> +
> +    ignore:
> +        free(event);
> +    }
> +}
> +
> +static char *watch_token(libxl__gc *gc, int slotnum, uint32_t counterval) {
> +    return libxl__sprintf(gc, "%d/%"PRIx32, slotnum, counterval);
> +}
> +
> +int libxl__ev_xswatch_register(libxl__gc *gc, libxl__ev_xswatch *w,
> +                               libxl__ev_xswatch_callback *func,
> +                               const char *path /* copied */) {
> +    libxl__ev_watch_slot *use = NULL;
> +    char *path_copy = NULL;
> +    int rc;
> +
> +    CTX_LOCK;
> +
> +    if (!libxl__ev_fd_isregistered(&CTX->watch_efd)) {
> +        rc = libxl__ev_fd_register(gc, &CTX->watch_efd, watchfd_callback,
> +                                   xs_fileno(CTX->xsh), POLLIN);
> +        if (rc) goto out_rc;
> +    }
> +
> +    if (LIBXL_SLIST_EMPTY(&CTX->watch_freeslots)) {
> +        /* Free list is empty so there is not in fact a linked
> +         * free list in the array and we can safely realloc it */
> +        int newarraysize = (CTX->watch_nslots + 1) << 2;
> +        int i;
> +        libxl__ev_watch_slot *newarray =
> +            realloc(CTX->watch_slots, sizeof(*newarray) * newarraysize);
> +        if (!newarray) goto out_nomem;
> +        for (i=CTX->watch_nslots; i<newarraysize; i++)

does not follow the CODING_STYLE, it should be

           for (i = CTX->watch_nslots; i < newarraysize; i++)


> +            LIBXL_SLIST_INSERT_HEAD(&CTX->watch_freeslots,
> +                                    &newarray[i], empty);
> +        CTX->watch_slots = newarray;
> +        CTX->watch_nslots = newarraysize;
> +    }

would it make sense to move this code in its own allocate_watch_slots
function?


> +    use = LIBXL_SLIST_FIRST(&CTX->watch_freeslots);
> +    assert(use);
> +    LIBXL_SLIST_REMOVE_HEAD(&CTX->watch_freeslots, empty);
> +
> +    path_copy = strdup(path);
> +    if (!path_copy) goto out_nomem;
> +
> +    int slotnum = use - CTX->watch_slots;
> +    w->counterval = CTX->watch_counter++;
> +
> +    if (!xs_watch(CTX->xsh, path, watch_token(gc, slotnum, w->counterval))) {
> +        LIBXL__LOG_ERRNOVAL(CTX, LIBXL__LOG_ERROR, errno,
> +                            "create watch for path %s", path);
> +        rc = ERROR_FAIL;
> +        goto out_rc;
> +    }
> +
> +    w->slotnum = slotnum;
> +    w->path = path_copy;
> +    w->callback = func;
> +    /* we look a bit behind the curtain of LIBXL_SLIST, to explictly
> +     * assign to the pointer that's the next link.  See the comment
> +     * by the definitionn of libxl__ev_watch_slot */
> +    use->empty.sle_next = (void*)w;
> +
> +    CTX_UNLOCK;
> +    return 0;
> +
> + out_nomem:
> +    rc = ERROR_NOMEM;
> + out_rc:
> +    if (use)
> +        LIBXL_SLIST_INSERT_HEAD(&CTX->watch_freeslots, use, empty);
> +
> +    free(w->path);
> +    w->path = NULL;
> +
> +    CTX_UNLOCK;
> +}
> +
> +/*
> + * osevent poll
> + */
> +
> +int libxl_osevent_beforepoll(libxl_ctx *ctx, int *nfds_io,
> +                             struct pollfd *fds, int *timeout_upd,
> +                             struct timeval now) {
> +    libxl__ev_fd *efd;
> +    int i;
> +
> +    /*
> +     * In order to be able to efficiently find the libxl__ev_fd
> +     * for a struct poll during _afterpoll, we maintain a shadow
> +     * data structure in CTX->fd_beforepolled: each slot in
> +     * the fds array corresponds to a slot in fd_beforepolled.
> +     */
> +
> +    GC_INIT(ctx);
> +    CTX_LOCK;
> +
> +    if (*nfds_io) {
> +        /*
> +         * As an optimisation, we don't touch fd_beforepolled_used
> +         * if *nfds_io is zero on entry, since in that case the
> +         * caller just wanted to know how big an array to give us.
> +         *
> +         * If !*nfds_io, the unconditional parts below are guaranteed
> +         * not to mess with fd_beforepolled... or any in_beforepolled.
> +         */
> +
> +        /* Remove all the old references into beforepolled */
> +        for (i = 0; i < CTX->fd_beforepolled_used; i++) {
> +            efd = CTX->fd_beforepolled[i];
> +            if (efd) {
> +                assert(efd->in_beforepolled == i);
> +                efd->in_beforepolled = -1;
> +                CTX->fd_beforepolled[i] = NULL;
> +            }
> +        }
> +        CTX->fd_beforepolled_used = 0;
> +
> +        /* make sure our array is as big as *nfds_io */
> +        if (CTX->fd_beforepolled_allocd < *nfds_io) {
> +            assert(*nfds_io < INT_MAX / sizeof(libxl__ev_fd*) / 2);
> +            libxl__ev_fd **newarray =
> +                realloc(CTX->fd_beforepolled, sizeof(*newarray) * *nfds_io);
> +            if (!newarray)
> +                return ERROR_NOMEM;
> +            CTX->fd_beforepolled = newarray;
> +            CTX->fd_beforepolled_allocd = *nfds_io;
> +        }
> +    }
> +
> +    int used = 0;
> +    LIBXL_LIST_FOREACH(efd, &CTX->efds, entry) {
> +        if (used < *nfds_io) {
> +            fds[used].fd = efd->fd;
> +            fds[used].events = efd->events;
> +            fds[used].revents = 0;
> +            CTX->fd_beforepolled[used] = efd;
> +            efd->in_beforepolled = used;
> +        }
> +        used++;
> +    }
> +    int rc = used <= *nfds_io ? 0 : ERROR_BUFFERFULL;
> +
> +    if (*nfds_io) {
> +        CTX->fd_beforepolled_used = used;
> +    }
> +
> +    *nfds_io = used;
> +
> +    libxl__ev_time *etime = LIBXL_TAILQ_FIRST(&CTX->etimes);
> +    if (etime) {
> +        int our_timeout;
> +        struct timeval rel;
> +        static struct timeval zero;
> +
> +        timersub(&etime->abs, &now, &rel);
> +
> +        if (timercmp(&rel, &zero, <)) {
> +            our_timeout = 0;
> +        } else if (rel.tv_sec >= 2000000) {
> +            our_timeout = 2000000000;
> +        } else {
> +            our_timeout = rel.tv_sec * 1000 + (rel.tv_usec + 999) / 1000;
> +        }
> +        if (*timeout_upd < 0 || our_timeout < *timeout_upd)
> +            *timeout_upd = our_timeout;
> +    }
> +
> +    CTX_UNLOCK;
> +    GC_FREE;
> +    return rc;
> +}
> +
> +void libxl_osevent_afterpoll(libxl_ctx *ctx, int nfds, const struct pollfd *fds,
> +                             struct timeval now) {
> +    int i;
> +    GC_INIT(ctx);
> +    CTX_LOCK;
> +
> +    assert(nfds <= CTX->fd_beforepolled_used);
> +
> +    for (i = 0; i < nfds; i++) {
> +        if (!fds[i].revents)
> +            continue;
> +
> +        libxl__ev_fd *efd = CTX->fd_beforepolled[i];
> +        if (!efd)
> +            continue;
> +
> +        assert(efd->in_beforepolled == i);
> +        assert(fds[i].fd == efd->fd);
> +
> +        int revents = fds[i].revents & efd->events;
> +        if (!revents)
> +            continue;
> +
> +        efd->func(gc, efd, efd->fd, efd->events, revents);
> +    }
> +
> +    for (;;) {
> +        libxl__ev_time *etime = LIBXL_TAILQ_FIRST(&CTX->etimes);
> +        if (!etime)
> +            break;
> +
> +        assert(!etime->infinite);
> +
> +        if (timercmp(&etime->abs, &now, >))
> +            break;
> +
> +        time_deregister(gc, etime);
> +
> +        etime->func(gc, etime, &etime->abs);
> +    }
> +
> +    CTX_UNLOCK;
> +    GC_FREE;
> +}
> +
> +
> +/*
> + * osevent hook and callback machinery
> + */
> +
> +void libxl_osevent_register_hooks(libxl_ctx *ctx,
> +                                  const libxl_osevent_hooks *hooks,
> +                                  void *user) {
> +    GC_INIT(ctx);
> +    CTX_LOCK;
> +    ctx->osevent_hooks = hooks;
> +    ctx->osevent_user = user;
> +    CTX_UNLOCK;
> +    GC_FREE;
> +}
> +
> +
> +void libxl_osevent_occurred_fd(libxl_ctx *ctx, void *for_libxl,
> +                               int fd, short events, short revents) {
> +    libxl__ev_fd *ev = for_libxl;
> +
> +    GC_INIT(ctx);
> +    CTX_LOCK;
> +    assert(!CTX->osevent_in_hook);
> +
> +    assert(fd == ev->fd);
> +    revents &= ev->events;
> +    if (revents)
> +        ev->func(gc, ev, fd, ev->events, revents);
> +
> +    CTX_UNLOCK;
> +    GC_FREE;
> +}
> +
> +void libxl_osevent_occurred_timeout(libxl_ctx *ctx, void *for_libxl) {
> +    libxl__ev_time *ev = for_libxl;
> +
> +    GC_INIT(ctx);
> +    CTX_LOCK;
> +    assert(!CTX->osevent_in_hook);
> +
> +    assert(!ev->infinite);
> +    LIBXL_TAILQ_REMOVE(&CTX->etimes, ev, entry);
> +    ev->func(gc, ev, &ev->abs);
> +
> +    CTX_UNLOCK;
> +    GC_FREE;
> +}
> +
> +void libxl__event_disaster(libxl__gc *gc, const char *msg, int errnoval,
> +                           libxl_event_type type /* may be 0 */,
> +                           const char *file, int line, const char *func) {
> +    libxl__log(CTX, XTL_CRITICAL, errnoval, file, line, func,
> +               "DISASTER in event loop: %s%s%s%s",
> +               msg,
> +               type ? " (relates to event type " : "",
> +               type ? libxl_event_type_to_string(type) : "",
> +               type ? ")" : "");
> +
> +    /*
> +     * FIXME: This should call the "disaster" hook supplied to
> +     * libxl_event_register_callbacks, which will be introduced in the
> +     * next patch.
> +     */
> +
> +    const char verybad[] =
> +        "DISASTER in event loop not handled by libxl application";
> +    LIBXL__LOG(CTX, XTL_CRITICAL, verybad);
> +    fprintf(stderr, "libxl: fatal error, exiting program: %s\n", verybad);
> +    exit(-1);
> +}
> +
> +/*
> + * Local variables:
> + * mode: C
> + * c-basic-offset: 4
> + * indent-tabs-mode: nil
> + * End:
> + */
> diff --git a/tools/libxl/libxl_event.h b/tools/libxl/libxl_event.h
> new file mode 100644
> index 0000000..25efbdf
> --- /dev/null
> +++ b/tools/libxl/libxl_event.h
> @@ -0,0 +1,199 @@
> +/*
> + * Copyright (C) 2011      Citrix Ltd.
> + * Author Ian Jackson <ian.jackson@eu.citrix.com>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU Lesser General Public License as published
> + * by the Free Software Foundation; version 2.1 only. with the special
> + * exception on linking described in file LICENSE.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU Lesser General Public License for more details.
> + */
> +
> +#ifndef LIBXL_EVENT_H
> +#define LIBXL_EVENT_H
> +
> +#include <libxl.h>
> +
> +
> +/*======================================================================*/
> +
> +/*
> + * OS event handling - passing low-level OS events to libxl
> + *
> + * Event-driven programs must use these facilities to allow libxl
> + * to become aware of readability/writeability of file descriptors
> + * and the occurrence of timeouts.
> + *
> + * There are two approaches available.  The first is appropriate for
> + * simple programs handling reasonably small numbers of domains:
> + *
> + *   for (;;) {
> + *      libxl_osevent_beforepoll(...)
> + *      poll();
> + *      libxl_osevent_afterpoll(...);
> + *      for (;;) {
> + *        r=libxl_event_check(...);
> + *        if (r==LIBXL_NOT_READY) break;
> + *        if (r) handle failure;
> + *        do something with the event;
> + *      }
> + *   }
> + *
> + * The second approach uses libxl_osevent_register_hooks and is
> + * suitable for programs which are already using a callback-based
> + * event library.
> + *
> + * An application may freely mix the two styles of interaction.
> + */
> +
> +struct pollfd;
> +
> +int libxl_osevent_beforepoll(libxl_ctx *ctx, int *nfds_io,
> +                             struct pollfd *fds, int *timeout_upd,
> +                             struct timeval now);
> +  /* The caller should provide beforepoll with some space for libxl's
> +   * fds, and tell libxl how much space is available by setting *nfds_io.
> +   * fds points to the start of this space (and fds may be a pointer into
> +   * a larger array, for example, if the application has some fds of
> +   * its own that it is interested in).
> +   *
> +   * On return *nfds_io will in any case have been updated by libxl
> +   * according to how many fds libxl wants to poll on.
> +   *
> +   * If the space was sufficient, libxl fills in fds[0..<new
> +   * *nfds_io>] suitably for poll(2), updates *timeout_upd if needed,
> +   * and returns ok.
> +   *
> +   * If space was insufficient, fds[0..<old *nfds_io>] is undefined on
> +   * return; *nfds_io on return will be greater than the value on
> +   * entry; *timeout_upd may or may not have been updated; and
> +   * libxl_osevent_beforepoll returns ERROR_BUFERFULL.  In this case
> +   * the application needs to make more space (enough space for
> +   * *nfds_io struct pollfd) and then call beforepoll again, before
> +   * entering poll(2).  Typically this will involve calling realloc.
> +   *
> +   * The application may call beforepoll with fds==NULL and
> +   * *nfds_io==0 in order to find out how much space is needed.
> +   *
> +   * *timeout_upd is as for poll(2): it's in milliseconds, and
> +   * negative values mean no timeout (infinity).
> +   * libxl_osevent_beforepoll will only reduce the timeout, naturally.
> +   */

so far we have always added the comment on a function above the
declaration of the function; we should keep doing it for consistency


> +void libxl_osevent_afterpoll(libxl_ctx *ctx, int nfds, const struct pollfd *fds,
> +                             struct timeval now);
> +  /* nfds and fds[0..nfds] must be from the most recent call to
> +   * _beforepoll, as modified by poll.
> +   *
> +   * This function actually performs all of the IO and other actions,
> +   * and generates events (libxl_event), which are implied by either
> +   * (a) the time of day or (b) both (i) the returned information from
> +   * _beforepoll, and (ii) the results from poll specified in
> +   * fds[0..nfds-1].  Generated events can then be retrieved by
> +   * libxl_event_check.
> +   */
> +

I see that the implementation of libxl_event_check is actually missing
from this patch.
Is this patch supposed to compiled, even without the actual libxl_event
generation? Or are the two patches have to be committed together?


> +typedef struct libxl_osevent_hooks {
> +  int (*fd_register)(void *uselibxl_event_check.r, int fd, void **for_app_registration_out,
> +                     short events, void *for_libxl);
> +  int (*fd_modify)(void *user, int fd, void **for_app_registration_update,
> +                   short events);
> +  void (*fd_deregister)(void *user, int fd, void *for_app_registration);
> +  int (*timeout_register)(void *user, void **for_app_registration_out,
> +                          struct timeval abs, void *for_libxl);
> +  int (*timeout_modify)(void *user, void **for_app_registration_update,
> +                         struct timeval abs);
> +  void (*timeout_deregister)(void *user, void *for_app_registration_io);
> +} libxl_osevent_hooks;
> +
> +void libxl_osevent_register_hooks(libxl_ctx *ctx,
> +                                  const libxl_osevent_hooks *hooks,
> +                                  void *user);
> +  /* The application which calls register_fd_hooks promises to
> +   * maintain a register of fds and timeouts that libxl is interested
> +   * in, and make calls into libxl (libxl_osevent_occurred_*)
> +   * when those fd events and timeouts occur.  This is more efficient
> +   * than _beforepoll/_afterpoll if there are many fds (which can
> +   * happen if the same libxl application is managing many domains).
> +   *
> +   * For an fd event, events is as for poll().  register or modify may
> +   * be called with events==0, in which case it must still work
> +   * normally, just not generate any events.
> +   *
> +   * For a timeout event, milliseconds is as for poll().
> +   * Specifically, negative values of milliseconds mean NO TIMEOUT.
> +   * This is used by libxl to temporarily disable a timeout.
> +   *
> +   * If the register or modify hook succeeds it may update
> +   * *for_app_registration_out/_update and must then return 0.
> +   * On entry to register, *for_app_registration_out is always NULL.
> +   *
> +   * A registration or modification hook may fail, in which case it
> +   * must leave the registration state of the fd or timeout unchanged.
> +   * It may then either return ERROR_OSEVENT_REG_FAIL or any positive
> +   * int.  The value returned will be passed up through libxl and
> +   * eventually returned back to the application.  When register
> +   * fails, any value stored into *for_registration_out is ignored by
> +   * libxl; when modify fails, any changed value stored into
> +   * *for_registration_update is honoured by libxl and will be passed
> +   * to future modify or deregister calls.
> +   *
> +   * libxl will only attempt to register one callback for any one fd.
> +   * libxl will remember the value stored in *for_app_registration_io
> +   * by a successful call to register or modify and pass it into
> +   * subsequent calls to modify or deregister.
> +   *
> +   * register_fd_hooks may be called only once for each libxl_ctx.
> +   * libxl may make calls to register/modify/deregister from within
> +   * any libxl function (indeed, it will usually call register from
> +   * register_event_hooks).  Conversely, the application MUST NOT make
> +   * the event occurrence calls (libxl_osevent_occurred_*) into libxl
> +   * reentrantly from within libxl (for example, from within the
> +   * register/modify functions).
> +   *
> +   * Lock hierarchy: the register/modify/deregister functions may be
> +   * called with locks held.  These locks (the "libxl internal locks")
> +   * are inside the libxl_ctx.  Therefore, if those register functions
> +   * acquire any locks of their own ("caller register locks") outside
> +   * libxl, to avoid deadlock one of the following must hold for each
> +   * such caller register lock:
> +   *  (a) "acquire libxl internal locks before caller register lock":
> +   *      No libxl function may be called with the caller register
> +   *      lock held.
> +   *  (b) "acquire caller register lock before libxl internal locks":
> +   *      No libxl function may be called _without_ the caller
> +   *      register lock held.
> +   * Of these we would normally recommend (a).
> +   *
> +   * The value *hooks is not copied and must outlast the libxl_ctx.
> +   */

while this description is very verbose, it doesn't contain informations
on:

- what is void *user;
- what is "const libxl_osevent_hooks *hooks", in particular the role of
  each  of these function pointers and the description of their
  arguments.

If I am a user of the library, how am I supposed to pass as user? and as
hooks?
I think these few lines should go first, then the description of the
contract.


> +/* It is NOT legal to call _occurred_ reentrantly within any libxl
> + * function.  Specifically it is NOT legal to call it from within
> + * a register callback.  Conversely, libxl MAY call register/deregister
> + * from within libxl_event_registered_call_*.
> + */
> +
> +void libxl_osevent_occurred_fd(libxl_ctx *ctx, void *for_libxl,
> +                               int fd, short events, short revents);
> +
> +void libxl_osevent_occurred_timeout(libxl_ctx *ctx, void *for_libxl);
> +  /* Implicitly, on entry to this function the timeout has been
> +   * deregistered.  If _occurred_timeout is called, libxl will not
> +   * call timeout_deregister; if it wants to requeue the timeout it
> +   * will call timeout_register again.
> +   */
> +
> +#endif
> +
> +/*
> + * Local variables:
> + * mode: C
> + * c-basic-offset: 4
> + * indent-tabs-mode: nil
> + * End:
> + */
> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> index d015c7c..88e7dbb 100644
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
> @@ -24,6 +24,9 @@
>  #include <stdlib.h>
>  #include <string.h>
>  #include <pthread.h>
> +#include <inttypes.h>
> +#include <assert.h>
> +#include <sys/poll.h>
> 
>  #include <xs.h>
>  #include <xenctrl.h>
> @@ -91,6 +94,66 @@ _hidden void libxl__log(libxl_ctx *ctx, xentoollog_level msglevel, int errnoval,
> 
>       /* these functions preserve errno (saving and restoring) */
> 
> +typedef struct libxl__gc libxl__gc;
> +
> +typedef struct libxl__ev_fd libxl__ev_fd;
> +typedef void libxl__ev_fd_callback(libxl__gc *gc, libxl__ev_fd *ev,
> +                                   int fd, short events, short revents);
> +struct libxl__ev_fd {
> +    /* all private for libxl__ev_fd... */
> +    LIBXL_LIST_ENTRY(libxl__ev_fd) entry;
> +    int fd;
> +    short events;
> +    int in_beforepolled; /* -1 means not in fd_beforepolled */
> +    void *for_app_reg;
> +    libxl__ev_fd_callback *func;
> +};
> +
> +
> +typedef struct libxl__ev_time libxl__ev_time;
> +typedef void libxl__ev_time_callback(libxl__gc *gc, libxl__ev_time *ev,
> +                                     const struct timeval *requested_abs);
> +struct libxl__ev_time {
> +    /* all private for libxl__ev_time... */
> +    int infinite; /* not registered in list or with app if infinite */
> +    LIBXL_TAILQ_ENTRY(libxl__ev_time) entry;
> +    struct timeval abs;
> +    void *for_app_reg;
> +    libxl__ev_time_callback *func;
> +};
> +
> +typedef struct libxl__ev_xswatch libxl__ev_xswatch;
> +typedef void libxl__ev_xswatch_callback(libxl__gc *gc, libxl__ev_xswatch*,
> +                            const char *watch_path, const char *event_path);
> +struct libxl__ev_xswatch {
> +    /* caller should include this in their own struct */
> +    /* contents are private to xswatch_register */
> +    int slotnum;
> +    uint32_t counterval;
> +    char *path;
> +    libxl__ev_xswatch_callback *callback;
> +};
> +
> +/*
> + * An entry in the watch_slots table is either:
> + *  1. an entry in the free list, ie NULL or pointer to next free list entry
> + *  2. an pointer to a libxl__ev_xswatch
> + *
> + * But we don't want to use unions or type-punning because the
> + * compiler might "prove" that our code is wrong and misoptimise it.
> + *
> + * The rules say that all struct pointers have identical
> + * representation and alignment requirements (C99+TC1+TC2 6.2.5p26) so
> + * what we do is simply declare our array as containing only the free
> + * list pointers, and explicitly convert from and to our actual
> + * xswatch pointers when we store and retrieve them.
> + */
> +typedef struct libxl__ev_watch_slot {
> +    LIBXL_SLIST_ENTRY(struct libxl__ev_watch_slot) empty;
> +} libxl__ev_watch_slot;
> +
> +libxl__ev_xswatch *libxl__watch_slot_contents(libxl__gc *gc, int slotnum);
> +
>  struct libxl__ctx {
>      xentoollog_logger *lg;
>      xc_interface *xch;
> @@ -108,6 +171,23 @@ struct libxl__ctx {
>         * documented in the libxl public interface.
>         */
> 
> +    int osevent_in_hook;
> +    const libxl_osevent_hooks *osevent_hooks;
> +    void *osevent_user;
> +      /* See the comment for OSEVENT_HOOK_INTERN in libxl_event.c
> +       * for restrictions on the use of the osevent fields. */
> +
> +    int fd_beforepolled_allocd, fd_beforepolled_used;
> +    libxl__ev_fd **fd_beforepolled; /* see libxl_osevent_beforepoll */
> +    LIBXL_LIST_HEAD(, libxl__ev_fd) efds;
> +    LIBXL_TAILQ_HEAD(, libxl__ev_time) etimes;
> +
> +    libxl__ev_watch_slot *watch_slots;
> +    int watch_nslots;
> +    LIBXL_SLIST_HEAD(, libxl__ev_watch_slot) watch_freeslots;
> +    uint32_t watch_counter; /* helps disambiguate slot reuse */
> +    libxl__ev_fd watch_efd;
> +
>      /* for callers who reap children willy-nilly; caller must only
>       * set this after libxl_init and before any other call - or
>       * may leave them untouched */
> @@ -138,12 +218,12 @@ typedef struct {
> 
>  #define PRINTF_ATTRIBUTE(x, y) __attribute__((format(printf, x, y)))
> 
> -typedef struct {
> +struct libxl__gc {
>      /* mini-GC */
>      int alloc_maxsize;
>      void **alloc_ptrs;
>      libxl_ctx *owner;
> -} libxl__gc;
> +};
> 
>  #define LIBXL_INIT_GC(gc,ctx) do{               \
>          (gc).alloc_maxsize = 0;                 \
> @@ -209,9 +289,137 @@ _hidden char *libxl__xs_read(libxl__gc *gc, xs_transaction_t t,
>  _hidden char **libxl__xs_directory(libxl__gc *gc, xs_transaction_t t,
>                                     const char *path, unsigned int *nb);
>     /* On error: returns NULL, sets errno (no logging) */
> -
>  _hidden char *libxl__xs_libxl_path(libxl__gc *gc, uint32_t domid);
> 
> +
> +/*
> + * Event generation functions provided by the libxl event core to the
> + * rest of libxl.  Implemented in terms of _beforepoll/_afterpoll
> + * and/or the fd registration machinery, as provided by the
> + * application.
> + *
> + * Semantics are similar to those of the fd and timeout registration
> + * functions provided to libxl_osevent_register_hooks.
> + *
> + * Non-0 returns from libxl__ev_{modify,deregister} have already been
> + * logged by the core and should be returned unmodified to libxl's
> + * caller; NB that they may be valid libxl error codes but they may
> + * also be positive numbers supplied by the caller.
> + *
> + * In each case, there is a libxl__ev_FOO structure which can be in
> + * one of three states:
> + *
> + *   Undefined   - Might contain anything.  All-bits-zero is
> + *                 an undefined state.
> + *
> + *   Idle        - Struct contents are defined enough to pass to any
> + *                 libxl__ev_FOO function but not registered and
> + *                 callback will not be called.  The struct does not
> + *                 contain references to any allocated resources so
> + *                 can be thrown away.
> + *
> + *   Active      - Request for events has been registered and events
> + *                 may be generated.  _deregister must be called to
> + *                 reclaim resources.
> + *
> + * These functions are provided for each kind of event KIND:
> + *
> + *   int libxl__ev_KIND_register(libxl__gc *gc, libxl__ev_KIND *GEN,
> + *                              libxl__ev_KIND_callback *FUNC,
> + *                              DETAILS);
> + *      On entry *GEN must be in state Undefined or Idle.
> + *      Returns a libxl error code; on error return *GEN is Idle.
> + *      On successful return *GEN is Active and FUNC wil be
> + *      called by the event machinery in future.  FUNC will
> + *      not be called from within the call to _register.
> + *
> + *  void libxl__ev_KIND_deregister(libxl__gc *gc, libxl__ev_KIND *GEN_upd);
> + *      On entry *GEN must be in state Active or Idle.
> + *      On return it is Idle.  (Idempotent.)
> + *
> + *  void libxl__ev_KIND_init(libxl__ev_KIND *GEN);
> + *      Provided for initialising an Undefined KIND.
> + *      On entry *GEN must be in state Idle or Undefined.
> + *      On return it is Idle.  (Idempotent.)
> + *
> + *  int libxl__ev_KIND_isregistered(const libxl__ev_KIND *GEN);
> + *      On entry *GEN must be Idle or Active.
> + *      Returns nonzero if it is Active, zero otherwise.
> + *      Cannot fail.
> + *
> + *  int libxl__ev_KiND_modify(libxl__gc*, libxl__ev_KIND *GEN,
> + *                            DETAILS);
> + *      Only provided for some kinds of generator.
> + *      On entry *GEN must be Active and on return, whether successful
> + *      or not, it will be Active.
> + *      Returns a libxl error code; on error the modification
> + *      is not effective.
> + *
> + * All of these functions are fully threadsafe and may be called by
> + * general code in libxl even from within event callback FUNCs.
> + */
> +
> +
> +_hidden int libxl__ev_fd_register(libxl__gc*, libxl__ev_fd *ev_out,
> +                                  libxl__ev_fd_callback*,
> +                                  int fd, short events /* as for poll(2) */);
> +_hidden int libxl__ev_fd_modify(libxl__gc*, libxl__ev_fd *ev,
> +                                short events);
> +_hidden void libxl__ev_fd_deregister(libxl__gc*, libxl__ev_fd *ev);
> +static inline void libxl__ev_fd_init(libxl__ev_fd *efd)
> +                    { efd->fd = -1; }
> +static inline int libxl__ev_fd_isregistered(libxl__ev_fd *efd)
> +                    { return efd->fd >= 0; }
> +
> +_hidden int libxl__ev_time_register_rel(libxl__gc*, libxl__ev_time *ev_out,
> +                                        libxl__ev_time_callback*,
> +                                        int milliseconds /* as for poll(2) */);
> +_hidden int libxl__ev_time_register_abs(libxl__gc*, libxl__ev_time *ev_out,
> +                                        libxl__ev_time_callback*,
> +                                        struct timeval);
> +_hidden int libxl__ev_time_modify_rel(libxl__gc*, libxl__ev_time *ev,
> +                                      int milliseconds /* as for poll(2) */);
> +_hidden int libxl__ev_time_modify_abs(libxl__gc*, libxl__ev_time *ev,
> +                                      struct timeval);
> +_hidden void libxl__ev_time_deregister(libxl__gc*, libxl__ev_time *ev);
> +static inline void libxl__ev_time_init(libxl__ev_time *ev)
> +                { ev->func = 0; }
> +static inline int libxl__ev_time_isregistered(libxl__ev_time *ev)
> +                { return !!ev->func; }
> +
> +
> +_hidden int libxl__ev_xswatch_register(libxl__gc*, libxl__ev_xswatch *xsw_out,
> +                                       libxl__ev_xswatch_callback*,
> +                                       const char *path /* copied */);
> +_hidden void libxl__ev_xswatch_deregister(libxl__gc *gc, libxl__ev_xswatch*);
> +
> +static inline void libxl__ev_xswatch_init(libxl__ev_xswatch *xswatch_out)
> +                { xswatch_out->slotnum = -1; }
> +static inline int libxl__ev_xswatch_isregistered(const libxl__ev_xswatch *xw)
> +                { return xw->slotnum >= 0; }
> +
> +
> +
> +_hidden void libxl__event_disaster(libxl__gc*, const char *msg, int errnoval,
> +                                   libxl_event_type type /* may be 0 */,
> +                                   const char *file, int line,
> +                                   const char *func);
> +  /*
> +   * In general, call this via the macro LIBXL__EVENT_DISASTER.
> +   *
> +   * Event-generating functions may call this if they might have
> +   * wanted to generate an event (either an internal one ie a
> +   * libxl__ev_FOO_callback or an application event), but are
> +   * prevented from doing so due to eg lack of memory.
> +   *
> +   * NB that this function may return and the caller isn't supposed to
> +   * then crash, although it may fail (and henceforth leave things in
> +   * a state where many or all calls fail).
> +   */
> +#define LIBXL__EVENT_DISASTER(gc, msg, errnoval, type) \
> +    libxl__event_disaster(gc, msg, errnoval, type, __FILE__, __LINE__, __func__)

any reason why this shouldn't be a static inline?

> +
>  /* from xl_dom */
>  _hidden libxl_domain_type libxl__domain_type(libxl__gc *gc, uint32_t domid);
>  _hidden int libxl__domain_shutdown_reason(libxl__gc *gc, uint32_t domid);
> @@ -536,6 +744,8 @@ _hidden int libxl__parse_mac(const char *s, libxl_mac mac);
>  /* compare mac address @a and @b. 0 if the same, -ve if a<b and +ve if a>b */
>  _hidden int libxl__compare_macs(libxl_mac *a, libxl_mac *b);
> 
> +_hidden int libxl__gettimeofday(libxl__gc *gc, struct timeval *now_r);
> +
>  #define STRINGIFY(x) #x
>  #define TOSTRING(x) STRINGIFY(x)
> 
> --
> 1.7.2.5
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 15:47:44 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 15: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.xensource.com>)
	id 1RZ2fY-0002iW-6e; Fri, 09 Dec 2011 15:47:28 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RZ2fX-0002i9-Hv
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 15:47:27 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1323445597!4731264!1
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22762 invoked from network); 9 Dec 2011 15:46:37 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 15:46:37 -0000
Received: by wgbds11 with SMTP id ds11so5106117wgb.24
	for <xen-devel@lists.xensource.com>;
	Fri, 09 Dec 2011 07:46:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=PC0i2UsWN8U7UfLwF/riXZz4ZONRHD1yz5Prd96NKSs=;
	b=QAtjKzbkMob05+U67kLO5VQXPCWhLhWHerThrkTr3d/N+Rm/Q/tOFuzpDCzxXucZBM
	hB7kOX/oy5bgg6ezadEClIOAcA7zf6B20l3QoZyQVOfJuaKfxjGqlz2CDab/VxoH6Ooe
	+5zH6B7eZCQOeq4vaMYNaYUWY7t8ZD4cHdsY8=
Received: by 10.227.59.204 with SMTP id m12mr7173986wbh.10.1323445596606;
	Fri, 09 Dec 2011 07:46:36 -0800 (PST)
Received: from [192.168.1.3] (host81-155-119-104.range81-155.btcentralplus.com.
	[81.155.119.104])
	by mx.google.com with ESMTPS id em4sm12880241wbb.20.2011.12.09.07.46.35
	(version=SSLv3 cipher=OTHER); Fri, 09 Dec 2011 07:46:35 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Fri, 09 Dec 2011 15:46:32 +0000
From: Keir Fraser <keir@xen.org>
To: Ian Campbell <Ian.Campbell@citrix.com>,
	Jan Beulich <JBeulich@suse.com>
Message-ID: <CB07DDD8.35969%keir@xen.org>
Thread-Topic: [PATCH v2 06/25] libelf-loader: introduce elf_load_image
Thread-Index: Acy2ibkm2Jg7biPOu0KXpjEgAIfbow==
In-Reply-To: <1323445279.20077.76.camel@zakaz.uk.xensource.com>
Mime-version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"keir.xen@gmail.com" <keir.xen@gmail.com>,
	"Tim Deegan \(3P\)" <Tim.Deegan@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v2 06/25] libelf-loader: introduce
	elf_load_image
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 09/12/2011 15:41, "Ian Campbell" <Ian.Campbell@citrix.com> wrote:

>>  (I didn't look
>> at the ARM bits, but if there things are done differently that's likely a
>> mistake).
> 
> This ARM port has no PV guests so it has no "user" in the sense that
> x86's copy_to_user means, so copy_to_user and copy_to_guest are both the
> same and do things the HVM way.
> 
> Maybe the right thing to do is to not supply copy_to_user on ARM at all.
> I had feared this would be a big bit of string to pull on but it seems
> that copy_to_user isn't actually widely used in common code:
> $ rgrep --binary-files=without-match copy_to_user xen | grep -vE
> x86\|ia64\|asm
> xen/common/gdbstub.c:        r = gdb_arch_copy_to_user((void*)addr,
> (void*)&val, 1);
> xen/include/linux/gdbstub.h:unsigned int gdb_arch_copy_to_user(
> xen/include/xen/gdbstub.h:unsigned int gdb_arch_copy_to_user(

copy_to/from_user isn't used by and doesn't really have any meaning to
common code. You can leave them out.

 -- Keir

> Stefano, what do you think?



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 15:47:44 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 15: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.xensource.com>)
	id 1RZ2fY-0002iW-6e; Fri, 09 Dec 2011 15:47:28 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RZ2fX-0002i9-Hv
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 15:47:27 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1323445597!4731264!1
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22762 invoked from network); 9 Dec 2011 15:46:37 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 15:46:37 -0000
Received: by wgbds11 with SMTP id ds11so5106117wgb.24
	for <xen-devel@lists.xensource.com>;
	Fri, 09 Dec 2011 07:46:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=PC0i2UsWN8U7UfLwF/riXZz4ZONRHD1yz5Prd96NKSs=;
	b=QAtjKzbkMob05+U67kLO5VQXPCWhLhWHerThrkTr3d/N+Rm/Q/tOFuzpDCzxXucZBM
	hB7kOX/oy5bgg6ezadEClIOAcA7zf6B20l3QoZyQVOfJuaKfxjGqlz2CDab/VxoH6Ooe
	+5zH6B7eZCQOeq4vaMYNaYUWY7t8ZD4cHdsY8=
Received: by 10.227.59.204 with SMTP id m12mr7173986wbh.10.1323445596606;
	Fri, 09 Dec 2011 07:46:36 -0800 (PST)
Received: from [192.168.1.3] (host81-155-119-104.range81-155.btcentralplus.com.
	[81.155.119.104])
	by mx.google.com with ESMTPS id em4sm12880241wbb.20.2011.12.09.07.46.35
	(version=SSLv3 cipher=OTHER); Fri, 09 Dec 2011 07:46:35 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Fri, 09 Dec 2011 15:46:32 +0000
From: Keir Fraser <keir@xen.org>
To: Ian Campbell <Ian.Campbell@citrix.com>,
	Jan Beulich <JBeulich@suse.com>
Message-ID: <CB07DDD8.35969%keir@xen.org>
Thread-Topic: [PATCH v2 06/25] libelf-loader: introduce elf_load_image
Thread-Index: Acy2ibkm2Jg7biPOu0KXpjEgAIfbow==
In-Reply-To: <1323445279.20077.76.camel@zakaz.uk.xensource.com>
Mime-version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"keir.xen@gmail.com" <keir.xen@gmail.com>,
	"Tim Deegan \(3P\)" <Tim.Deegan@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v2 06/25] libelf-loader: introduce
	elf_load_image
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 09/12/2011 15:41, "Ian Campbell" <Ian.Campbell@citrix.com> wrote:

>>  (I didn't look
>> at the ARM bits, but if there things are done differently that's likely a
>> mistake).
> 
> This ARM port has no PV guests so it has no "user" in the sense that
> x86's copy_to_user means, so copy_to_user and copy_to_guest are both the
> same and do things the HVM way.
> 
> Maybe the right thing to do is to not supply copy_to_user on ARM at all.
> I had feared this would be a big bit of string to pull on but it seems
> that copy_to_user isn't actually widely used in common code:
> $ rgrep --binary-files=without-match copy_to_user xen | grep -vE
> x86\|ia64\|asm
> xen/common/gdbstub.c:        r = gdb_arch_copy_to_user((void*)addr,
> (void*)&val, 1);
> xen/include/linux/gdbstub.h:unsigned int gdb_arch_copy_to_user(
> xen/include/xen/gdbstub.h:unsigned int gdb_arch_copy_to_user(

copy_to/from_user isn't used by and doesn't really have any meaning to
common code. You can leave them out.

 -- Keir

> Stefano, what do you think?



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 15:49:00 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 15: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.xensource.com>)
	id 1RZ2gn-0002rK-Re; Fri, 09 Dec 2011 15:48:45 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wferi@niif.hu>) id 1RZ2gm-0002qY-As
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 15:48:44 +0000
X-Env-Sender: wferi@niif.hu
X-Msg-Ref: server-8.tower-182.messagelabs.com!1323445674!2035285!1
X-Originating-IP: [193.6.222.43]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22598 invoked from network); 9 Dec 2011 15:47:54 -0000
Received: from tac.ki.iif.hu (HELO tac.ki.iif.hu) (193.6.222.43)
	by server-8.tower-182.messagelabs.com with AES256-SHA encrypted SMTP;
	9 Dec 2011 15:47:54 -0000
Received: from wferi by tac.ki.iif.hu with local (Exim 4.72)
	(envelope-from <wferi@niif.hu>)
	id 1RZ2fj-0000HE-6W; Fri, 09 Dec 2011 16:47:39 +0100
From: Ferenc Wagner <wferi@niif.hu>
To: Jeremy Fitzhardinge <jeremy@goop.org>
References: <ce19ea02-45e6-465a-a4c8-b5d74bf8c2ad@default>
	<20111010155319.GA29140@phenom.oracle.com> <4E934EC9.5030909@goop.org>
Date: Fri, 09 Dec 2011 16:47:39 +0100
In-Reply-To: <4E934EC9.5030909@goop.org> (Jeremy Fitzhardinge's message of
	"Mon, 10 Oct 2011 13:00:09 -0700")
Message-ID: <87vcppbvc4.fsf@tac.ki.iif.hu>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=-=-="
Cc: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com,
	linux-x86_64@vger.kernel.org, Zhenzhong Duan <zhenzhong.duan@oracle.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH] cpu idle ticks show twice in xen pvm guest
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--=-=-=

Jeremy Fitzhardinge <jeremy@goop.org> writes:

>> On Wed, Oct 05, 2011 at 10:11:58PM -0700, Zhenzhong Duan wrote:
>>
>>> Run below test on xen pvm.
>>> # x=$(cat /proc/stat | grep cpu0 | awk '{print $5}') && sleep 60  \
>>> && y=$(cat /proc/stat | grep cpu0 | awk '{print $5}') \
>>> && echo -e  "X:$x\nY:$y\nIDLE:" $(echo "scale=3; ($y-$x)/6000*100" | bc)
>>>
>>> @ X:58562301
>>> @ Y:58574282
>>> @ IDLE: 199.600
>>>
>>> Normal idle percent should be around 100%.
>>> xen_timer_interrupt called account_idle_ticks to account hypervisor stolen idle ticks 
>>> but these ticks will be accounted again when idle ticks restarted.
>>>
>>> Signed-off-by: Zhenzhong Duan <zhenzhong.duan@oracle.com>
>>> Signed-off-by: Joe Jin <joe.jin@oracle.com>
>
> Does this affect the accounting of stolen ticks?  If it does, that's not
> necessarily a showstopper for this patch, but we'll need to do some more
> thinking about it.  Certainly, accurate accounting for idleness is
> important.

Please see also http://thread.gmane.org/gmane.linux.kernel/734441, where
I found that the counter doubling isn't always present under 2.6.26.
However, after going to 2.6.32 (Debian lenny-backports kernel, 4th of
April on the graph below) that instability seems to disappear.  Please
note that the following graph shows halved idle and iowait percentages.


--=-=-=
Content-Type: image/png
Content-Disposition: inline; filename=cpu.png
Content-Transfer-Encoding: base64
Content-Description: Modified Munin graph

iVBORw0KGgoAAAANSUhEUgAAAfUAAAEGCAYAAAB8TgymAAAABmJLR0QA/wD/AP+gvaeTAAAgAElE
QVR4nO2dfXQUVZr/vx3QySAtCZ0AkbwRQUZRRCJxlbwAkcgZd4POHpjfWUXEEUSjZ1FXB5goIhGY
UXxDE10xwrLrmQ2ODmF0WRhJJ+PLKEFllOwQzAudQDDkpaERCIH07490Nf1WXVXdVXWr6z6fc3Iq
XV1V3/s8VdW3nvvcutfy9ddfu0EQBEEQRExz4sQJxLEuBEEQBEEQ0XHixAk0NzdjqLBi/PjxLMtD
EARBEESEbNu2DQAoUicIgiAIs0CVOkEQBEGYBKrUCYIgCMIkDJXehCAIgiAIFuzcuTPk+jlz5oRc
T5E6QRAEQRiUOXPmYM6cOZg1a5b3czgoUicIgiAIA3PmzBkcOHAAQ4YMgdPpxNCh4lU3VeoEQRAE
YVBaWlrQ3NyMsWPHIjMzE3v37kVGRobo9lSpEwRBEIRB6enpwc0334xhw4YBAGbPnh12e6rUCYIg
CMKgHD9+HMePHw9aTx3lCIIgCCLGoI5yBEEQBGEiqKMcQRAEQZgAbjvKtdTVAQDG5eczLglBEARB
qAOXHeXO9/Xhz2VlAIBFO3Zg6E9+wrhEBEEQBBE9SjvKmaJS3/v22zh55Ij3/5sfeohxiQiCIAgi
eiwWC4qKimCxWAAAbrcbu3btEt0+5nu/nzxyBF9u2uT9/OWmTd4KniAIgiBiGavVira2NgwMDGBg
YABtbW2wWq2i2+taqVutVu+fL21tbSgsLITNZkNhYSHa29vDrvfl4+eew/m+Pu/n8319+Pi557Q1
hCAIgiB04LrrrkNHRwd2796N3bt3o6OjA5MnTxbdXtdK3eVyweVyBa1fuXIlcnNzceTIEeTm5qK0
tDTsel/uLC/H4wcO4PT/+394/MABPH7gAO4sL1dctjO7dys3SCVI25x6RtAmm0nbrLostfXUtVqt
uOmmm3Dbbbfhtttuw0033YRPPvlEdHtD5NTr6uqwYcMGxMfHo6SkBDk5OWHXa4Hlsss0OzZpG0Ob
J1tZ67LU5tFmltpks7EwRE7d6XQiKSkJRUVFsNlscDqdYdf7cqGnB67KSgz09gL19Rg+fHhEy0vO
nYtq/2iWAwcOMNHlzW4e/czT+WWtS/7mx99SuvF9fXBVVuJcQ0PU9ePOnTuD/sJh+frrr90AMH78
+KjF5WK1Wv2a4TMyMlBfX4/k5GR0dnYiJycHra2toutDsWbNGvz2t78NLWjxLN3q2kFExz6Lxe9z
tucE7YMl1OaiCPvF2vkNtF8MMb9kBxgs129S+ynVi/R4co8rd79AxMonVU6p76X8nO0OOI7nPAeu
F0PudREtQnmC7kOZ5STCc+rUKc2OvXPnzqBX2rZt2wbAIM3veXl5KC8vx/Lly1FRUYGCgoKw67Xg
VF0dhjMauIZX7YmptRjeHqwt9WMdKUb1s1x7pbYL9f2p1LqQPpZz3Ej0fNcHakdqp9LrQdCNtPxS
34fb71RqXVAQIbf83so/wutfzrn2w1POID3PerkPiZempuJce7voQ4JAtA8LoR4+wt1XagUNgUjp
skbXSD1UN3yXywWHw4GFCxdi//79mDJlCrZs2YK0tDTR9aGgSD0GUTsgibXzq09ARgRgqRqMaNzz
52krJFyPAZWk3BaPWEOtlpHAytf7MCByvwTpBvhddWSeJi0j9VAwidRD9XwHgPT0dNTU1MherwVG
jeJMra00sohWj0M/6+3jSLTVrmQDdYXjy9UX+yyFe/68sDZH2iIiF1bnWquWEW/lHqYF41RqHbLb
RdIdAdureZ2Fup99WwbUTGF0dXXh4MGD3oeE4cOHY+LEiUhKSgq5PZOcuhZQpB6DUKTORjagkgr8
kRP78Yt2P7EfU7nHVYrSSlktvOWPMmIU84vW50HzFowoibScUn6T2l6gfv58ABItA271IvWPP/4Y
1113nbcS7+rqwrfffovCwkK/7QyVUzcCPEZxzLUpUtdeV4aPxX685Ea4YuuLW1tRnZmp2nHlIqar
B8WtrRcrHYSO/AXkPjxJrReY+7vnZfk70ocose0Ef0s9RCl9WJPa3lK1DcWtrdj+5BN+38t9mIv0
OsuGe7DvhGcstGj7QsjBYrF4h4mVgip1Dyw7PXCrrXNTIY9+VtIMrTasKlZBV297fbXDIVXJKuXi
/tLacsqjdDu551mpnXIi8urMTCbneXh7vk/5tG0inDx5MhobG/HVV18Nag8fbpwR5VhhqdomeeJP
eaZuZQG32qn6apvNz1LXtaVqG+b+7nnVdeVSLPL6qVl1A7X3WSy6vZ4WqK0nWuuGu85Dacv5vY+2
PHreV8nJyZg+fbp3RLnp06cjOTlZdHuK1D3wGMWx1ra++AOAbbJzW9Hm+szq53D+YRUth9LWK6Iy
is0Xm2PZ2M2bv1nphvKzkHpRA6Ud5WI+Uu/v74fD4UBXVxcAoLm5OeRy0tmzYb9v2LEj7PdaLk/V
1THRZW13cWvrxfMyqRmWqm249j+2hvzsu13g0m+/WPNzCHuULAW/TDp7Nsh/ALDo8GHR7bVe+p5f
HnSBi/4OvF4Dz4+Z7BZ0tbZPjr+NotvY2AiHw4GOjg5Ey/79+zFhwgTMnj0bs2fPxoQJE7B//37R
7bno/W7x9Ap0zzN2r07e8J4Xma8SSfbajbXzG2XLrJJXrZRsT6gD+Z1f3PPmqdr7ffLkyd7I/Pjx
42F7v8d8pK4WZsu3xoK2kA/TOgcmwKOfjZJf5kE3UFuv6zqUtp4Yxd9m1RU6yu3atQu7du3CoUOH
wnaUo5y6B7PmW42srXc+jEc/857vJG3z6rLU1lM3OTk5bMe4QChS98BjFMdaW+nTbrSRT6z6OdBu
JX6gKIq0zarLUltP3VCztIWbqY0idQ88RnGstaN92lVawfPoZ4qiSNusuiy19dYNnJEtHBSpe4jV
KC6WtcWeduW8fx1JxG5UP2uZe6UoirTNqstSm6XNUlCk7oHHKI61NuXUtYfViFuCNk+6vGqTzcbC
EJF6dXU1Jk2ahJEjR2LWrFloaWkBALS1taGwsBA2mw2FhYVob2/XrAxGjeLMrK33026s+zmSiJ6i
KNI2qy5LbT11lTS9Awap1B955BG89tprOHbsGH79619jxYoVAICVK1ciNzcXR44cQW5uLkpLSzUr
A49RHGttitS1h6Io0jarLkttitRl4DsDzWeffQYAqKurQ0lJCeLj41FSUgK73a6ZfqxHcbGoTZG6
9lAURdpm1WWpbeScuiEq9RdffBFLly5FamoqPvnkE5w8eRIA4HQ6kZSUhKKiIthsNjidzqB9L/T0
wFVZiYHeXpzyVPqByzs8zfli35+y2zE8Pz/s91ouMTDARJe13XHuwbGxhfMT7TLm/Jxq9y9/qj3k
Mhq/VGdmquZfpUu1z6/Rdcnf/PhbSvd8dzdclZU419AAvTHcMLF1dXVYvHgxDh48iIyMDNTX1yM5
ORmdnZ3IyclBq8gTkqxhYoVhRt3B2/A41zZr7bnPh57/OVKkhok1mp+F61JAahjcSGA9tzgLbR5t
ZqlNNgej5jCxcjHcMLFutxuNjY349a9/jXmeH+e8vDyUl5ejr68PFRUVKCgo0Eyfx3wra23KqWsP
5TtJ26y6LLX10v38889x9OhRuN0hIlERDFGpW61WXH755ZgzZw7y8/Px1FNPAQDWrl0Lu92OlJQU
1NbWoqysTLMy8JhvZa1NOXXtoXwnaZtVl6W2XrrXXHMNjh8/jtraWnz//ffo6+uT3McQ76m7XK6Q
69PT01FTU6NLGXiM4lhrU6SuPRRFkbZZdVlq66U7YsQIXH/99ejr60NbWxs+//xzJCYmIjMzEyNG
jAi5jyEidSPAYxTHWpside2hKIq0zarLUltv3Z/85CcYP3488vPzkZycjIYwHfAMEakbAR6jONba
FKmHR42R4CiKIm2z6rLUZqUbFxeHK664AldccYX4NjqWx9DwGMWx1qZIXXsoiiJts+qy1Dbye+pc
RepC5ONG8KtDsRbFmUGbIvXQqDlWO0VRpG1WXZbaNKJcDMBjFMdamyJ17aEoirTNqstS28iResxX
6v39/XA4HOjq6gIANDc3h1xOOnvWbxn4fWdqatj9tVwOz89nosva7urMzKDzEu0y1vzsW35L1TZc
+x9bVfVH05gxqh5PyVKL82tkXYD8zYu/pXQbGxvhcDjQ0dEBvTHciHKRImdEOYFQI48ZbbQxHrRp
RDntp0Sl0b5I26y6LLVpRLkYIFbyrWbSppy69lC+k7TNqstSm3VOfefOnaLfUaXugcd8K2ttyqlr
D+U7Sdusuiy1jZxT56r3ezh4jOJYa1Okrj0URZG2WXVZauupGy4qDwVF6h54jOJYa1Okrj0URZG2
WXVZauupO2fOnKC/cFCl7oHHKI61NkXq2kNRFGmbVZelNuucejgMUalXV1dj8uTJSEhIwOTJk7Fj
xw4AQFtbGwoLC2Gz2VBYWIj29nbNysBjFMdamyJ17aEoirTNqstSm3VOPVy0bohX2lJTU7F582bk
5eWhtrYW9913H9rb27FgwQJkZWVhxYoVWLduHQ4fPozNmzeHPEa0r7QR+qP2K12xdl71eKWNIAj9
UfOVtq6uLhw8eNB7vOHDh2PixIlISkry285Qr7Slp6cjLi4OFosFQ4YMQaanaaOurg4lJSWIj49H
SUkJ7Ha7ZmXgMYpjrU2RuvZQFEXaZtVlqa2n7v79+zFhwgTMnj0bs2fPxoQJE7B//37R7Q1RqW/c
uBELFy6EzWbDvffei1dffRUA4HQ6kZSUhKKiIthsNjidzqB9L/T0wFVZiYHeXpzyVPqByztaWvyW
obYbnp8vur/WSwwMMNFlbXec2w0g+PxEuow1P6tld7hldWamLjqhlmqfX6Prkr/58beU7vnubrgq
K3EuzBSpSrBYLN4/yW2N0Pw+depUrF+/HgUFBbDb7fjNb36D+vp6ZGRkoL6+HsnJyejs7EROTg5a
RZ6QaES52NOmEeVoRDkz6fKqTTYHo2bz+/Hjx9HY2OjX/H7VVVchOTnZbzuh+d0Q76n/8MMPAOBt
fj927BgAIC8vD+Xl5Vi+fDkqKipQUFCgWRl47BnNWpt6v2sP9UwmbbPqstTWUzc5OTmoAg+HIZrf
X331VTz66KNITk7GsmXLsHHjRgDA2rVrYbfbkZKSgtraWpSVlWlWBh7zray1KaeuPZTvJG2z6rLU
1lN3586dIf/EMETzuxpQ7/fYg3q/U+93gjAjaja/79y5E3PmzPEufdf5Yqje70aAxyiOtTZF6tpD
URRpm1WXpbaeunFxcXC5XLBYLDh58iROnTqFoUPFM+eGyKkbAR7zray1KaeuPZTvJG2z6rLU1lM3
NTUVf/3rX3H11Vfjq6++Qn9/PyZOnCi6PUXqHniM4lhrU6SuPRRFkbZZdVlq66l7zTXXYPbs2UhP
T8eMGTO8/4tBlboHHqM41toUqWsPRVGkbVZdltqsZ2mj+dRlwGMUx1qbInXtoSiKtM2qy1Jbb125
Pd8BE1Tq/f39cDgc6OrqAgA0NzeHXE46e9ZvGfh9Z2pq2P21XA7Pz2eiy9ru6szMoPMS7TLW/Ky2
/YHLpjFjdNEJtdTi/BpZFyB/8+JvKd3GxkY4HA50dHRADZRMvUqvtHkw2mhjPGjTiHI0opyZdHnV
JpuDUfOVNrnQK20B8JhvZa1NOXXtoXwnaZtVl6U2zaceA/CYb2WtTTl17aF8J2mbVZelNuv51MNB
lboHHqM41toUqWsPRVGkbVZdltoUqccAPEZxrLUpUtceiqJI26y6LLUpUo8BeIziWGur/bS7z2LB
vjDzDfPoZ4qiSNusuiy1KVKPAXiM4lhrq/20mw03suEW/Z5HP1MURdpm1WWpbeRI3RBjv1utVr/P
I0eOxOHDh9HW1oZ7770X33zzDaZMmYItW7Yg1fO+r9rwGMWx1qacuvZQFEXaZtVlqa2nbldXFw4e
POh9RW748OGYOHEikpKSQm5viEjd5XJ5/5YsWYL77rsPALBy5Urk5ubiyJEjyM3NRWlpqWZl4DGK
Y61NOXXtoSiKtM2qy1JbT939+/djwoQJmD17NmbPno0JEyZg//79otsbIlIXOHHiBKqqqvDll18C
AOrq6rBhwwbEx8ejpKQEOTk5mmnzGMWx1qZIXXsoiiJts+qy1NZb12KxwBKmv5AvhojUBd555x3c
dtttSElJAQA4nU4kJSWhqKgINpsNTqczaJ8LPT1wVVZioLcXp+x2AAha3tHS4rcMtd2pujrR/bVe
dr3xBhNd1nY/63l4Czw/kS5PpYbXM5qf1bI73LK4tVUXnVBLtc+v0XXJ3/z4W0r3fHc3XJWVONfQ
gGiZPHkyGhsbsWvXLuzatQuHDh3C5MmTRbc3zDCx58+fx3XXXYf/+q//wtSpUwEAGRkZqK+vR3Jy
Mjo7O5GTk4NWkWaPaIeJJfRH7WFS3fM951W8r5yh0GOYWIIg9IeGiQWwfft2pKameit0AMjLy0N5
eTn6+vpQUVGBgoICzfR5zLey1qacuvZQvpO0zarLUltP3cAZ2qRmajNMpf7aa6+hpKTEb93atWth
t9uRkpKC2tpalJWVaabPY76VtTbl1LWH8p2kbVZdltp66wozs8mZpc0wlXpNTQ3uuOMOv3Xp6emo
qalBT08P9uzZg7S0NM30eYziWGtTpK49FEWRtll1WWrTe+oxAI9RHGtttZ92LVWDOSU3QveZ4NHP
FEWRtll1WWrTiHIxAI9RHGttitS1h6Io0jarLkttPXV9m97lQJW6Bx6jONbalFPXHoqiSNusuiy1
KVKPAXiM4lhr8xqpS008oyYURZG2WXVZarPu/R4OU+fUvT+cVVWS2/IYxbHW5jVSvzjpjPbvqVMU
Rdpm1WWpraduqGb3mHilLVL6+/vhcDjQ1dUFAGhubvYus+FG4qQmAMCks2f9lr7bAUDDjh0h1+ux
PFVXx0SXtd3Fra1B50WtpeH9PKlZE7sDl4sOH9ZFJ9RSy/NrRF2A/M2Lv6V0Gxsb4XA40NHRAb0x
zIhy0RJyRDlPoC70ihagEeWMgVYjqhn+/IpclwRBmAMaUc4AGCXfyoW2ZfCP15y6nlC+k7TNqstS
W++cupx1AqbOqSuJhIySb+VJm9ecup5QvpO0zarLUltvXanOcb5QpO6BxyiOtTZF6tpDURRpm1WX
pbbeusLwsHKGiTV1Tl0sZ2v4nKvZ0TinbPjzSzl1gjA1lFM3ADxGcay1KVLXHoqiSNusuiy1aex3
Cfr6+rBq1SpUVVXh+PHjAACXy4W2tjbce++9+OabbzBlyhRs2bIFqampmpSBx3wra23KqWsP5TtJ
26y6LLX11BXLp4s1wxsiUl+zZg3+8pe/4H/+539w8uRJuFwuAMDKlSuRm5uLI0eOIDc3F6WlpZqV
gccojrU2ReraQ1EUaZtVl6W23mO/z5kzB+PGjcOIESMwa9assHl1Q+TUr7rqKlRWViI3N9dvfUZG
Bvbu3YtRo0ahs7MTOTk5aBVxJuXUYwet3k8XMPz5pZw6QZgaNXPqZ86cwYEDB3Du3DlceeWVaGtr
w7XXXov4+Hi/7QyVU+/s7MTu3bsxevRoXH311fjjH/8IAHA6nUhKSkJRURFsNhucTmfQvhd6euCq
rMRAby9O2e0A4F3e0dISchm43Sm7Hafq6kKu12PZ9cYbTHRZ2S2ch2e//NLvs1pLo/v5zt/+Dpaq
barbHWpZ3Nqqi06opVbn16i65G9+/C2le767G67KSpxraEC0fPbZZxg5ciRuvvlmjB49GpMmTcJ3
330nur0hIvW0tDRs2rQJM2fOxKeffop7770Xhw8fRkZGBurr65GcnEyRuongPVLX2n6CINiiZqT+
448/4rLLLvNbd+7cOVx66aV+6wwVqd9yyy1+ny2eiVjy8vJQXl6Ovr4+VFRUoKCgQLMy8JhvZa1N
OXXtoXwnaZtVl6W2nrp/+ctfgmZp27Nnj+j2hqjU169fj/Xr12P06NF4+OGH8eqrrwIA1q5dC7vd
jpSUFNTW1qKsrEwVvVBTX/LYM5q1NvV+1x7qmUzaZtVlqa23rtAxTs7gM4ao1MeNG4eamhr09vbi
wIEDKC4uBgCkp6ejpqYGPT092LNnD9LS0lTRy4Z7cPpLzxjkAJ9RHGttrZ52xeYrV91Wn+tH6nuK
1M2vy6s22WwsDPGeuhFgEUkJFU+22627toAZI/WL85X7E62tYudLznmkSN38urxqk83GwhCRuhEI
F0kJkZ9YBCi2Xmo7ocUgUFvu8eTqhMOMkboYUrZK+c3bwiO1PiCC32ex4FuVWpmUQlEUaZtVl6W2
3u+p+y4D/w/EnJG68INaJX+XcJGUWOQX9L2g6/kYWEHIjSCl9KRQsr8ZI3WBwAhazFbvdiJ+k/pe
imy4gfaIdo0aiqJI26y6LLVpRLkYQFHEKjOXKkRwYhGewLdpaWEjxMAIUqrlQAly7I5ax+OPwONo
/bQb6HcxW6XOT+D3ov4Ic12cSqWcutl1edUmm7VF6Bw3a9Ys7+dwmDJSlztSl7BdvWW+33rvD7hO
qe7r2ttCrheLEGVHlAEtB6EYnp8vmRNW3BIhHCaggrtY7kG/6/a06ynHQQy+EinVh0G2PxQwvJ1y
6mbX5VWbbNYeYVS5IUOGwOl0YuhQ8ao75iP1/v5+OBwOdHV1AQCam5sBAJPOnhVdWqq24dr/2Or9
nA03flpQjWy4kTipafA4k5qxz2LBrmuv9X4OuWwWWR9uaQGar734+VRqXUi9wPKI6nmOF3J73/08
2/nqNOzY4b9fc0D5xOxrvqgnu5w+y0lnz6K4tTXseYpmGUp3YmqtuJ0+23ntEfk+kmVDwQ4/v2hl
d+By0eHDuur5LrU8v0bUBcjfvPhbSrexsREOhwMdHR2IlpaWFnz22WcYPnw4brjhBuzduxfp6emi
2xtiRDk18B1RTumIXe758kYgEyJ7Yft9iC7XqhTV9QIjapEIWylS5dRrzHOx86qWHwOvB6nvBd0b
qxR09iAIIuZQc0S5ffv24eqrr8awYcPCbmeoEeVUQyrXHYZwOU9L1Ta/ikj4LJWLFdsv8LPcfKuU
nlICe2WrkaMH5JdT997vHj+r7Uep8yxoq60rB8p3krZZdVlq66mbnZ0tWaH7YsqculIuRlSBn5VF
8JF+L5VvjbY8YvsF9srWKnIVW691XipQV20/Ky+HqoeVBeU7Sdusuiy1jfyeuqkq9WiadYtbW4P2
16qZOPC4c3/3vCoXidKHC/f8eTiVWhdU2cl9KFDqn8Dti1tbdb05Am2N9PyK7RfueCwjClY/QKy0
ebSZpTbZbCxMValHQyQnSK1KX662mJ5UZBmunEp6Zasdyep1U0Ta0iFsr8Z55jGiIJv50CabjQVV
6h5i+WkzmohTjna0EbkYevtcaYuImi01FKmbX5dXbbLZWJiq9/vvbryRdTG4QM0IliAIwmyo2ftd
Lobq/W61Wv3+BNra2lBYWAibzYbCwkK0t2s31iaPPTgj1Q7Vu1sv7VjSM4I22UzaZtVlqW3kWdoM
EalbrVa4XK6g9QsWLEBWVhZWrFiBdevW4fDhw9i8eXPIY1CkThAEQRgB7iN1AEhNTcXo0aPxz//8
z3A4HACAuro6lJSUID4+HiUlJbDb7Zrp8/i0yZs2T7b66S6fN/jHQpsBPJ5nltpks7EwRKXucrnQ
3t6OAwcO4Oqrr8aiRYsAAE6nE0lJSSgqKoLNZoPT6Qza90JPD1yVlRjo7cUdLS0AENGyOjMzqv2j
WcZ5xhhnoc+T3Tz6uTozE3ck2JnYzcrfPJ5nlnbz6G8p3fPd3XBVVuJcQwP0xhDN776cPXsWV1xx
BXp6epCRkYH6+nokJyejs7MTOTk5aBV5Qoq2+Z3HHpy8afNkq5/uG08Mflivb8dGHnsm86hNNgdD
ze8eTp06hY0bN2Ly5MkAgLy8PJSXl6Ovrw8VFRUoKCjQTJvHdy150+bJVta6LLV5tJmlNtlsLAxR
qQu93jMzM2G32/H2228DANauXQu73Y6UlBTU1tairKxMszLwmBfiTZsnW1nrstTm0WaW2mSzsTBc
83ukUO93ghjEPX9wkHmLMBuc0ElO5+Z3guAVan43ADw+bfKmzYutliw3LFlu3XUD4TGK4lGbbDYW
VKl74DEvxJs2T7ay1mWpzaPNLLXJZmNBlboHHp82edPmyVbWuiy1ebSZpTbZbCyoUvfA49Mmb9o8
2cpal6U2jzaz1CabjQVV6h54fNrkTZsnW1nrstTm0WaW2mSzsYj5Sr2/vx8OhwNdXV0AgElnz0a0
bBozJqr9o1lWZ2Yy0eXNbq78PK7ZX9fzmQd/c3WeDWA3j/6W0m1sbITD4UBHRwf0hl5p88DjqEi8
aXNjq88rbDSiHGmbVZelNo0oFwPwmBfiTZsnW1nrstTm0WaW2mSzsaBK3QOPeSHetHmylbUuS20e
bWapTTYbC6rUPfD4tMmbNk+2stZlqc2jzSy1yWZjQZW6Bx6fNnnT5slW1rostXm0maU22WwsqFL3
wOPTJm/aPNnKWpelNo82s9Qmm42FoSr1DRs2wGq1ej+3tbWhsLAQNpsNhYWFaG9v10ybx6dN3rR5
spW1LkttHm1mqW04m5fPu/gGiJ66BsEwlfrf/vY3vP76637rVq5cidzcXBw5cgS5ubkoLS3VTJ/H
p03etHmylbUuS20ebWapTTYbC0NU6n19fVi8eDHWrVvnt76urg4lJSWIj49HSUkJ7Ha7ZmUw3NMm
ace8nhG0i1tbkdV0JbKarmSizQIezzNLbbLZWBiiUn/22Wfxs5/9DL/85S/91judTiQlJaGoqAg2
mw1OpzNo3ws9PXBVVmKgtxd3tLQAQETL6szMqPaPZhnndjPR5c1ubvycYPfTvdWewMRuVv7m5jwb
xG7D+dvn+tdV12d5vrsbrspKnGtogN4YYkS5ESNGYGBgwG+dy+VCRkYG6ipDyboAACAASURBVOvr
kZycjM7OTuTk5KBV5AmJRpQjbaPpMdMOGFHuuyfeAAA0b1uvj74Ho472Rdrm0BXV9rn+ddX1gfsR
5U6cOAGXywWXywUA3mVeXh7Ky8vR19eHiooKFBQUaFYGHvNCvGmbxVb3/Plwz5+vu65SeMx38qhN
NhsLQ1TqYqxduxZ2ux0pKSmora1FWVmZZlo85oV40zaLrZYsNyxZbt11lcJjvpNHbbLZWAxlXYBA
hCgdANLT01FTU6OLLo9Pm7xp82Kr0Cmuedt6VGdmIks3ZX94jKJ41CabjYWhI3U94fFpkzdtnmwF
BpvpXY89pruuAI9RFI/aZLOxoErdA49Pm7xp82QrMNhMb720TXddAR6jKB61yWZjQZW6Bx6fNnnT
5slWr25CHRNdgM8oikdtstlYUKXugcenTd60ebLVq+vMZ6IL8BlF8ahNNhsLqtQ98Pi0yZu26W0N
MeY1ReqkbVZdltoUqWtIf38/HA4Hurq6AACTzp6NaNk0ZkxU+0ezrM7MZKLLm92m8vO45rDrxzWP
G9RNTPX7zIO/TXWeY8BuQ/pb7P7Q6Tw3NjbC4XCgo6MDemOIEeXUgEaUI22j6amtLQw4431HPXDE
LE+U7n2l7comFCfU4bt9iwY/04hypG0iXVFtzkeUM9x76qzgMS/Em3as2yp3wBk/XWc+vadO2qbU
Zantq+t92K6qYlKWQGK++V0teMwL8abNk61eXcqpk7ZJdVlq++oqGeFRD6hS98Dj0yZv2jzZ6tWl
3u+kbVJdltrU+z0G4PFpkzdtnmz16lKkTtom1WWpTb3fYwAenzZ50+bJVq8uReqkbVJdltoUqccA
PD5t8qbNk61eXYrUSdukuiy1KVKXoLq6Gjk5ObDZbMjPz8enn34KAGhra0NhYSFsNhsKCwvR3t6u
XRk4fNrkTZsnW726FKmTtkl1WWpTpC7B+++/j61bt+Lo0aN44okncM899wAAVq5cidzcXBw5cgS5
ubkoLS3VrAw8Pm3yps2TrV5ditRJ26S6YtpZTVd6x2rQU9coGOI99c2bNwMAzpw5g/PnzyMhIQEA
UFdXhw0bNiA+Ph4lJSXIycnRrAw8Pm3yps2TrV5dek+dtE2qy0rbaO+lB2KISB0ArFYrRo0ahWXL
luHtt98GADidTiQlJaGoqAg2mw1OpzNovws9PXBVVmKgtxd3tLQAQETL4tbWqPaPZvnsl18y0eXN
7pj3c4Ldfyny/a32wYfiJW9n4/53sr2fzX5+Wevydj+x1hXzt9bX+51TazB3am3wfemz3fnubrgq
K3GuoQF6Y6hhYk+fPo2PPvoIzz//PL744gtkZGSgvr4eycnJ6OzsRE5ODlpFmj2iHSaWIAxPwGQt
UsPEBqL3MLEEwYKsecsBaHi9Bw5DG2JYWpbDxBoiUn/wwQfR1taGIUOGYMiQId5B8PPy8lBeXo6+
vj5UVFSgoKBAszIYLS9E2rGvp5W2kpzhrLoE1XSVQjlePrS5tJlhXxUpDFGp5+Xl4ec//znGjBmD
9evXY9OmTQCAtWvXwm63IyUlBbW1tSgrK9OsDLzlhXjU5slWgT35wSkrvaAcLx/amuuGmFJYDW33
/Pne/LhSWL5VIoUhKvV/+Zd/wbfffove3l588cUXKCoqAgCkp6ejpqYGPT092LNnD9LS0jQrA49P
m7xpm9bWMD96FKmTtll1o9WOZsx2itRjAB6fsHnT5slWAYrUSdusupprh2shoEjd+MTq0yZpG1dP
b+1QuXaK1NlpR9O8G622nmilK8d/kWhLHVf0e59KniL1GMC0T5ukzUzPCNoUqbPT1ntKTrP5W47/
ItGWOq4sXZ9IXY/BbpRAlboHozzdk7Z59DTXDtM8KECROmmbVVct7UhaVChSjwGM8nRP2ubRM4I2
ReqkrZuujIfMqAhxfDVsjqRFhXLqGtLf3w+Hw4Guri4AwKSzZyNaLjp8OKr9o1kWt7Yy0eXNblP4
eVwzAGBc8zi/z4HrheXcHdf6b8+Bvw11noXzY2K7/XRl2OuePx9Nq1fLO37A9R14/EWHD4c8nuT1
Huq4y+dh0pvZYfWEz4uu3RFWr7GxEQ6Hwzvmip4YakS5aKAR5QizETTGdMCIcc1XNvltL5XX425E
uRAjfXGlrzdy7VW6XSCBI7kFrBdGlGuyDFbA3ihcbD8pJPbz3o8+9xf3I8oZgVjPC5G28fSi1Q5s
FoykQw7l1EnbrLpA+Ny2lh0VjZxTN8QsbUaAx1wYb9o82SpAOXXSNoyuRIQcyexnrHLblFOPAXh8
wuZNO1ZsVfP9ZorUSdvousL1HklkzSpipkg9BuDxCZs37VixVc0mQ4rUIyeiyDFGrjEj6QZe716/
y7gP/CJmoSXAk1NXjYAWhqymK/EdAAT0aTEKFKl74PEJmzdtnmwVoEg9cqQix6AWleXzULx+tCra
kRDr/hZQErGziphZ3ldSGKJS//3vf4/rr78eI0eORG5uLurqBk9UW1sbCgsLYbPZUFhYiPb2ds3K
wOMTNm/aPNkqQJG6Coi8fx2q8mGZazWNv5VoM/I3y/tKCkNU6h9++CHeffddHD16FA8//DDuuece
AMDKlSuRm5uLI0eOIDc3F6WlpZqVgccojjdtnmwV4CJSD6h0jdobW3Ntk0TqirQpUg/CEDn1rVu3
ev/Py8vDyZMn0d/fj7q6OmzYsAHx8fEoKSlBTk6OZmXgMYrjTTtmbZXIFYZ7zc1UkbrM95vZR45s
3kunSF0CFUe7o0hdJt3d3bjrrruwdOlSXHLJJXA6nUhKSkJRURFsNhuczmBHXujpgauyEgO9vbij
pQUAIloWt7ZGtX80y2e//JKJLm92G93Prsceg3v+fNyRYB9cH7C81Z7gtxRb77ucVZdwcftYP7+C
PyTWe3XFtleqF3ic9cnA8nkX1/t8Lk6oky5vrPhb6jpV6u9Afwb6UebS9z4pTqgTvU+kjrPk7Wxk
NV2pWF+4r4L0fOw9390NV2UlzjU0QG8MM6LcN998gwULFuAXv/gFVq1ahbi4OGRkZKC+vh7Jycno
7OxETk4OWkWaemhEOSLmkYgkAiNyYUQ5uQPSxPyIciIjiAnr3c0WAMEj8EU8opuEniiB25ltRDkx
u6Ts1XJceB/ERlwM/F5AbDup4wdCI8r5sHXrVixbtgybNm3C6tWrERc3WKy8vDyUl5ejr68PFRUV
KCgo0KwMPOZbedPmyVaBmMypRzgxiNBxTW9dX3jKqQu9/7XWDTeSohr+Fjt+4HrfzyHvK60ntJGJ
IXLqDz30EADg1ltv9a47duwY1q5di4ULF+KVV17BlClTsGXLFs3KELP5VtI2rJ4RtM2QU1fy3nIk
ukqPH1abo5y611+Z4e2N1L9yWqC06P0uR5dy6hK4XK6gv8suuwzp6emoqalBT08P9uzZg7S0NM3K
wGMUx5u22WyVMxa8ESN1pSPmKR1pTKmv1Rwj3MyRuth5k9LVagz2rKYrcf872ZL3gdw5E5TMrUC9
32MAHqM43rR5slXAUJG6p2ny4g98dBGtWASo1ljkkWxf7cwHVB7QTC5qX2OBI+qJVcxi51ntvgSh
cuXhrm+lkx8pgSL1GMBsURxps9czgrYRI3W1EIsAhd7RLPCN1COZVS8qbUYju7G8r1hd3xSpG4xQ
YzrzGMXxps2TrQKGitQDkBpbPdJcrPXSNiArRGSncS901mOCa9aHQaKFguV95Xt9a/UAFeq4FKkb
DOEJ1DdHxGMUx5u22nqSuWGf3rChtNWcjU0M34hCDz1fos21RpqLFctr6+1v1ZHoXa3XmPeBCC0j
QS0TIuVVswWDIvVguIzUBXxzezxGcabVFsnpqa2nJDfsqx0cgWoXQfpGFHro+aLY3yq9DiTWI1pv
f2uFWAsHq3vZ2zKC6CpqqffLQ8EqYqZIXUP6+/vhcDjQ1dUFAJh09qy85bhmv+Wiw4eV7a/isri1
lYmu6exePg+T3swe/CycX639PK4Z7vnz0bR6tej3gX62ZLlxbWFT6P19rsuspitRuPtWv/Xjmscp
Ws7dca3f51B+0WoZ0t8B911QecS+V7AsTqgL8pciPc91FMr/UkvB30H6Kl5v3uvH93oP4e+w16XC
38eo/R1wPftuF7g+1HaBy0B/y7kf5Bw30vsqsFyNjY1wOBzo6OiA3hhmRLloUTSinNhIUToTyXzN
XBBp71mtz2tguaT0pEbekiAwcom2yVKv3LLodS1mt9yR2hQSSeQXan+BwOOInZ+gz8JIYxLXtWK/
CUiN4CahJxA0Ep9CIh3JTel1rdb9oDZCudzNFsDt5ntEOSPAIrcc9QhYKsCTtl56oXK3sdz7PdL3
ypnNGqbxu+KKRxqTSbTvc0f6fn7Uujq/m6+Wv6MhnK4W7+Qrgeucui/h8lGiT7QB30cacWv9fqme
2kqIWDvCSD7a3thyCbyplR5XzQgkqtyfxHvlUnYxmzWM4ZzmRn7bQDPdCP2txnVOOfVgTBmpR9LL
NdxTrtQTrXe91Ni/It8HaUc5hrCSJ2+K1C+i1chXliw35k6tjXj/aHoLaxnJhHqLxJfi9aNlXcdq
90qPNHJUo1d2RP4OvN8jvP9l308qj1HOchQ9I0bqrDFlpB5JL1dNnnIDZ4+SOyKTjsS0tsIcZdQt
A1HAakxwPSIKsftNbgSn9oOU0shRbkWu2pjgKo+4plrfnAivcx5bRkLpRtuHQy1MGalHgpKoUcn7
yYB0BGj2aDnIXx7/SGlHG8EF+l1UT6XIJVx5WUUzsiIKjWaX0stmIcIW/uTqajHim6oRnMzzYvQ+
DFqOrEeRejCmjNS9KHgiVhLFqf2+6/Ynnxw8rtwnbbH5oyNAj0j94shUyrTV9rPWs4aFe3Azc6Qu
htoRnNx5sL/btwhZqirLR5G/VX6QEvsdUXMWulAEnmc9I1YjRepGwRCRutVq9f750tbWhsLCQths
NhQWFqK9vV2zMvg95eo8L+7cqbXhbziR8kjmgGXYIevp3nMcpS0Ueo2AJYXa8z5HknuXEz0yjxy1
yrVqdD+J+SvQZj3HYJ9Vl6D7mO8CYr8javcVCbSPcurGwhCRusvlAoCgSn3lypXIzc3Fhx9+iHXr
1qG0tBSbN2+OWEfsiVXrJ1kpxCIaxeWK4IczmhaKaP0mRBbe40u1OERYMQjlcz8ps2VDg1mmTBWp
i5yHwOsh2l7Rkb6PLGazHhGkmVpGpBD8+R0QsmVEjwcbitSDMUSkLkZdXR1KSkoQHx+PkpIS2O32
qI4Xrvd6NL2TlRIY8Yo96cp9wpadew4RMRW3tgatl3u8aCMAIbJQo8VBiZ7s46oYYRoxp652r/Og
PgxR2hxpxCsVRak1/7Zcbb3G3Nf7/XwBllErRerBGLpSdzqdSEpKQlFREWw2G5zO4KejCz09cFVW
YqC3F3e0tAAA7kiw+y/F1vssq535wevXJwPL54nvJ+O4oZZ3Tq2BJcvt/RyHAQAXJ0ZQqhd4PKn9
vDotLajOzAzaznu8SP0p0y+C3dH6U7FepDpRLKud+ZK6t9oTVF/uyXd6Py95e3Do06DzLPe6l7of
pM6vzGW0dscNymriT6mlr7+FpeT9qdJSq+tbuG5ixd+sde9IsON8dzdclZU419AAvTHUMLFWq9Xb
FA8AGRkZqK+vR3JyMjo7O5GTk4NWkbyo3zCxYsN3hsvvJtQpb75SaXhL2dpqD6e5fhuKW1tR/cYT
6h5f5nGC7I5UX6meRsOSSmov/yGsrhbNlbPqEoKaCpssg+NTa51uEruu1RouVIxQNutFKG29XnES
/C31Cq1c5J4Po/mbtW7zlU1wN4HZMLGGyKmLkZeXh/LycixfvhwVFRUoKCiI7EAyfrwjyUeplYuX
q61F7l+L3u9yy6laDlBm5ezV07Ey99NeLr2d2oT64dGr74hYr2itYZnv1FJbqk+A4G+9KnMBs/rb
iLpyMETzu2/Pd9//165dC7vdjpSUFNTW1qKsrEyzMkSSj1KrV6lcbS1GPNOiB7rccgbZrfFbByx7
6Roxp641PNqsh7ZYbpv8bX5dORiq+T0a1qxZg9+991vWxSCIiNErkmU14pXRZtXSC7X8Lfc9fbV1
CGWwbn43RKRuBHiM4njT5slWAYrUY19bbm98VmPem83fRtaVA0XqBMEIVhGRXpG62vPBxypy/S2W
M5fym1rzxRPqQJG6QeAxiuNNmydbBSiKMr622PzsSiNoVmPex5q/Y1lXDhSpEwQjzBqpUwToj5S/
o/WX2PGppYQNFKkbBB6jON60ebJVQI2IQquR3bTCqJFjYASudsR8/zvZIY+n9Vj0RvU3K13WD08x
X6n39/fD4XCgq6sLADBpXHNEy6bE1Kj2j2ZZ7cxnosub3Ub087jmcZouW1ITQ66XU+6spitRuPtW
yf18t/O1a0++U3P7Qi1Z6crxt1a6k8Y1+9mt1/VlVH+z1m1sbITD4UBHRwf0hprfPUQ0opxKkLY6
SA3Ocf872diT7xTtiKS0WVpqZDTfz7PqErBp0b6Q+2mJnBHO5HbQUtqBy4ijfbHQ1rr5Wzh+4PWt
58x0RvK3EXSb0MSs+Z3LSl3uMJVS66WOJxex3JfcXJnWaKUnVZmoVcnK1ZPaL/B7pcOdGiW3GWk5
lFbqBMErvpX6ByUlmLViBUakpmqqGRPDxEZKJJVscUIdvpM4TuB6qUpXjMAfVeGpL3A/pZWUVGUS
iuKEOny3b5Hkdmrp+RJot1qVsNh2UnpSumLHlVovaDeLfqsdoSKKSCtjpfsZNYoibXPostRWotts
t8Px178i51e/wrT77sPQ+HhNy2bKSF3rCSPMilp+In8TBMEzvpH6hkmTvOtHpKVh1ooVyIp0HpMw
xHzze2NjI959913v56+++gpTp06N+HjnW1owdNw4NYpG2gbV5slW1rostXm0maU22Rweq6eyBYAR
qamDlfqMGaqXKeYr9UDWrFmDp556KuL9z372GeJvuUXFEpG20bR5spW1LkttHm1mqU02h2fDpEkY
Gh+Paffdh5xf/Uqz5nd6Tz2A/kOHSNvk2jzZylqXpTaPNrPUJpvDk1VQgHv/+EfcUlKieT4dAIYs
Xbr0GQAYOXKk5mJaUldXF/l86wCGpqYibtgwFUtE2kbT5slW1rostXm0maU22Ryeq2+/HfEjRmhc
IqChoQGAiZrfGxoacM0117AuBkEQBEHojuma36lCJ6xWK+siECbDarV6/wgiFoipSr21tRUzZszA
yJEjMWPGDDgcDsl91LoZrVYrXnnlFdWPK1f78ssvx/jx4/Fv//ZvOHPmjG7agj6LHzZfXT30rVYr
Nm7cCAB49dVXdbe3oaEBVqvV24ymB6xtNsK1FQ6XywWXy6WqNovzDACff/45ZsyYAZvNhsmTJ+O/
//u/ddHl9XebFTFVqa9YsQK33347Ojo6MGfOHKxYsUJX/S1btug+9J/AiRMnUFtbi56eHjz99NO6
amvxw6ZUW68ybNmyBW63G1u2bNFcK5Ddu3cjLi4Ou3fv1lWXpc2sri2W1zSr87xgwQIsXrwY7e3t
+NOf/oSamhpddHn+3WZBTFXqn3zyCX71q1/hJz/5CRYvXoxPPvkEALB//37k5uYiISHB70lM+F+t
SOCuu+7C66+/7rfuiy++wLRp05CYmIhp06bhiy++AABMnz7de9Ps2bMHubm5UWlbLBaMHTsWa9as
wR//+EcAg+/q33rrrRg5ciSmTJmCTz/9FIC4P9RE8GliYiJuueUWr61WqxUVFRVIT09HWlqaJhWF
mN0A8PTTT2PUqFHIzs7Gvn37FB975MiReOGFF5CUlORdJ2ar8N3TTz+N0aNHY/r06VHZ9ec//xl3
3303/vznP/sdv7S0FMnJyUE2qaWtxOaZM2diz549AIA//OEPmD17dsS6YgRes773sZbXlpiu2oid
51DaX331FW688UYkJydj1apVUZXpsssug8PhwLfffovk5GS88cYbAMTvp3DXnhJ4/t1mQUxV6idP
nkRCwuCUd4mJiThx4gQAYOnSpViwYAF++OEHv6dv4X+1nsqXLl2Kd99916sLACUlJXjkkUdw9OhR
lJSU4OGHHwYw+FS8detWAMDWrVuxYMGCqPUBYMyYMd4Z6e6//34sWbIEHR0deOGFF1BSUuItZyh/
qIng066uLrz44otYsmSJ97uhQ4fi4MGDqKysxKpVq6LSCdX8LmY3AGRlZeHw4cNYtmwZHnroIcV6
ixcvRllZGRYvXuxdF85WAEhOTkZLSwumTZsWoZXA6dOnsXfvXjz11FPYu3cvTp8+7f1u/PjxcDgc
WLZsmZ+tamkrsbmkpMR7Xb/yyit49NFHI9aNBDWvLRaEO8+hKCkpwYMPPojDhw8jKysrKu33338f
P/zwAx5//HFMnDgRVVVVAMLfT+GuPbnQ77a+xFTv97S0NPztb39DYmIiuru7MXXqVBw+fBiJiYk4
cuQIhoV4xcBqtapyYQjHeemll+ByufD888/D5XIhISEBHR0d+OlPf4rTp09j7Nix6O3tRW9vL667
7jp8+umnmD59Or777jvvhR2pNgAcOXIEM2bMwKFDh5CYmIjz5897t7NYLDh58mRYf0TKhQsXYLPZ
4HQOjnf81ltv4eWXX0Z7ezsGBga82larFb29vRg6dGhQ2ZUitq+Y3VarFZ2dnfjpT3+KM2fOYOzY
sejp6YlYT/gsZquwTU9PDy655JKIbBTYuXMn5s2b5/28bds2zJkzJ6xNamgrtfn8+fPIzs7G6tWr
UVZWhr1798JisURuOIKvLd8ynT9/HomJiXC5XKpeW0p01dASCHeeQ2knJibi6NGj3vM/atQoVcpx
4MAB3H777WhtbdXsfhLg9Xdbb2Ky9/stt9yCt99+G319fdi0aZO3yXHixInYunUrzp07F7TPpZde
KqtjhlweeOAB7xMuMPgwtG3bNpw5cwZVVVXeh6PExETceuutuPvuuzF79uyoLwy3242jR4/imWee
QXFxMQDg+uuvx7Zt23D8+HG4XC5vRRPOH0opLS3FyZMn8fHHHyMtLc27fuXKlXj55Zdx7NgxvPfe
e3C73d7vhB9drRCzG4D3XLz33nu46qqrVNELZyuAqCt0YDDP+uyzz8LlcuHZZ5/1y7f62hT48K2G
dijEbB46dCjuvfdePPDAA3jkkUeiqtDFri2bzYaPP/4YZ8+exebNm/32UePaikR3zJgx+Oabb6LW
FjvPYtoTJ07E73//e5w5cwZ/+MMfotJevHgxWlpa0NfXh4aGBly4cAGA/Psp0sCP599tFsRUpb5u
3Trs2LEDKSkp+Oijj7B27VoAQEVFBbZs2YLk5OSgHMySJUuQnZ2tWn5s2LBhfs2Ur732Gl599VWk
pKTgtddew2uvveb97p577sE333yjShPOiBEjkJeXh+HDh2PNmjUABqPljRs3Ii0tza95Opw/lHLF
FVfgmmuuwQMPPODX3Pn4449j0aJFmDBhAv7v//4vKg2liNkNDOYH09PT8dJLLwXl0SJFD1t3796N
oqIiAEBRUZFfpe5rk+/1pSXhbF64cCHi4+Mxf/78qDTErq1nnnkGCxcuxFVXXeWteNQkEt2VK1fi
tttui/p+EjvPYtqvv/46Nm7ciPT0dBw8eBBxcZH/ZM+cORNz587FmDFjsH79elRUVACQfz9Feu3x
/LvNgphqficI3lCrGVItBgYGsGnTJrS0tGDdunWsi8MNAwMD+Oijj7Bq1aqIO6wpxWjXHhEeU8+n
ThCENowYMQKTJ0/GBx98wLoo3GC1WmGxWJCZmala6xNhXqhSJwgDY7RIyWjl4QGWY0QQsUdM5dQJ
giAIghCHKnWCIAiCMAlUqRMEQRCESaBKnSAIgiBMAlXqBEEQBGESour9LmdgAOpByZef9LDVSO/P
qmWvHJuEbXw1jeKHcOjpIzUx0nUWjlj1b7hySKFlOd955x2sWLECP/74oyIdo/gv6lfastzikww0
W5qjPXxEGMW5fmS5xb9rjm7sbKMRxlKoYanhzq3P8JNByBx1TYlNvuORR8OXX36J5cuXe2dd++ij
j/Diiy/i66+/xrBhw1BQUIDnnnsOGRkZUekAgDvMVWGReVXofd7F9OT8vujpWwBw/5f4d5a75B3D
SPdVfZjvbtRYe+3atdi1axcmT57st17qvBvFf9T8ThCcsnHjRjzyyCPez2+88QaeeOIJOBwOHDhw
ADfccEPUQ8HyCvk2dvnhhx+CKvRYgmmlvn37dtx4441ITEz0G3O4q6sL6enp3mkJ7XY78vLyJPcT
+1/g2LFjmDt3Lmw2W9A83FarFQUFBVi0aBGuu+46PPjgg5raroRw8zyL+QIIb69wHLXmAlcLq9WK
N998E+np6cjIyPCbxCJwClZfTp48iaVLl4Ycv1rKDywJZ9P333+P6dOnY9SoUYqmGZVjr8PhwP79
+72TAwFAdXU1brvtNlx22WW4/PLLsXTpUrS0tERmmIqE89GhQ4eQn5+PkSNHIj8/H4cOHUJ3dzfG
jRsXNK3p6dOnkZWVhe7ubtH54sPpSf2+CMSSb4Hw/hW+D/U7cejQIe/1uXr1as3mn1dKuN/EUNeL
gLCt2+1WVK8YzX9MK/UHH3wQGzdu9M4OJDRfJCUl4eabb/b+oG/evBmLFi2S3E/sf4Fly5bhrrvu
wtGjR4PmDQaAF198Ee+99x42b96MP/3pT5rZrSZivgCk7RVoamqKaj5utXE6nfj73/+Ol156CU8/
/bR3fbj5lR999FFYLBZ8/fXXEfuBBeFseuyxx/CLX/wCbW1tiqbRlWNveXk5lixZgiFDhogeZ/Xq
1bjzzjtl62qF1HkvLi5GR0cHbr/9djz66KOw2WzIz88PGsr2gw8+QH5+Pmw2m+h88eH0pH5fBGLJ
t4D8ecsDfycef/xx3HnnnWhra0N8fLyWRVREuN/EUNeLgJy6JJSvm5wt6gAABOhJREFUjOa/qCZ0
sVqtkjn1cMb+4z/+I7q7uzFjxgxkZ2fj5z//uffHa8eOHXj55ZdRVVWFG264AQ0NDRg+fLjkfkK5
QumOHj3a7+k9cF7sEydOYMSIEThx4gQSEhL8piCMBqvVKplTD+cnsTmvgfC+CGevcJyOjg6vX9XA
arVK5tSlbP3hhx8wbNgwXLhwAYmJiUHnIdT5HTNmDA4ePIgRI0YEHVPKD9FgtVolc+qRdlIaNWoU
mpqaYLVacfLkSYwdO1b0OvBFyl6Xy4Vp06ahvr4+5Lk/c+YMHnnkEfz973/Hhx9+GNKnShi8JsLn
1NXy0fjx49HZ2Ymamho899xzePfddzFhwgQ0Nzdj/vz5KC0txcyZM/G///u/+M1vfoPvv/8eFy5c
CHlNiPk3XG5Vb98K5ZHKqUfTUU7sd0Lq+owUq9UqmVOPtF4Ru14C9ZWed6n99PCfIeZT/+CDD7B6
9WqMHDkSlZWVmDt3rve7OXPmoKmpCaWlpfinf/onP4eE2y8ccXFxfk9vgTexMK1hXFxc0JzZLLFY
LN7pGAObFMP5QspeAKpW6Goh3IBDhgxR5TzI8UOsEso/UvZu3rwZd955Z8hz39jYiJkzZ2Lo0KHY
tWuXKpWOlohdHzNmzMCxY8dQXl6OgYEBvP766+js7MSMGTMAAA899BBWrVqFzs5OdHR0qHa/m8m3
vhjxd0KMcL+JrH7X9fQf00r9kksuQVFRER577DGsXLnSb97mSy65BPPnz8d//ud/Bs1rG24/YLBS
CDXv9cyZM1FWVoYff/xRG4M0IjU1Fdu3b8fp06eDZmkK54tYtTcSbr/9dqxYsQLd3d1B38WqH266
6SZs2rQJ586dw5tvvhn0fUpKCvbu3Ru0Ppy9Fy5cwFtvvRWyz8i7776LuXPn4sknn8Qbb7yhqMmf
FdOmTcNbb72Fvr4+vPnmm97mTYvFgoULF+KVV17B/Pnz8dJLL2HhwoWwWAZ72p89exZJSUk4d+4c
1q9fr0hT7PfFbL6VIicnB2+99RbOnTuHf//3f2ddHC/hfhPFrhc5iJ33SNHKf0wrdaFzgc1mw7/+
67+ioqLC7/vCwkKMGzcO//AP/6Bov5KSEhQUFAR1PHjllVfw/fffY9y4cWE7NhiNZ555BsuWLcPP
fvYzJCQk+H0Xzhexaq8Y4TqsvPTSSxgYGMD1118f9J2R/RDOphdeeAFVVVUYO3YsTp06FbTv008/
jeLiYkXX+fbt2zFlyhSkp6cHHe+BBx5Ae3s7Fi5c6Nf5h/XDkNR5f//99zFmzBhs374dL774ove7
u+++G5deeinWr1+P+Ph43HXXxXe71q1bh1/+8pe4+uqrkZqaKlsPEP99iUXfAvI7AAayYcMGbNu2
DWPHjg1qQWRJuN/EcNeLFGLn3Wj+izqnLkWkOYLz58/j/vvvxzXXXIMnn3wyomMYBS39ZDR4shWI
PXtnzZqF3/72t7p2jIw1H0UKC98CxvGvVM5ZyXGkMMP1Eki0/hNy6lFV6lpitVoxdepUVFdXx1Tu
iSAIgkfUqtR5Ra1KPeoR5bSCLg6CIIjYgX6zo0Mt/9GIcgRBEARhEqhSJwiCIAiTQJU6QRAEQZgE
qtQJgiAIwiRQpU4QBEEQJsHy9ddfu0+cOIHmZjZznxMEQRAEoQ5xVKETBEEQhDn4/4AYmMnejagV
AAAAAElFTkSuQmCC
--=-=-=


(I haven't collected steal values, so the numbers don't sum up to 100%.)
I'd be grateful if this discrepancy could be cleared up eventually!
It's heartening to see some progress after more than three years. :)

Actually, as Munin doesn't half the idle and iowait values, but
truncates the (then overflowing) graph at 100%, I was rather surprised
to see iowait completely disappear after the kernel upgrade, and
concluded that it was somehow converted into buggy-looping in blkfront.
Now I see this isn't the case, but the steadily increasing system CPU
usage between reboots is still a mystery.  I'll start a separate thread
for that, just wanted to provide some motivation for this topic.
--
Thanks,
Feri.

--=-=-=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--=-=-=--


From xen-devel-bounces@lists.xensource.com Fri Dec 09 15:49:00 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 15: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.xensource.com>)
	id 1RZ2gn-0002rK-Re; Fri, 09 Dec 2011 15:48:45 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wferi@niif.hu>) id 1RZ2gm-0002qY-As
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 15:48:44 +0000
X-Env-Sender: wferi@niif.hu
X-Msg-Ref: server-8.tower-182.messagelabs.com!1323445674!2035285!1
X-Originating-IP: [193.6.222.43]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22598 invoked from network); 9 Dec 2011 15:47:54 -0000
Received: from tac.ki.iif.hu (HELO tac.ki.iif.hu) (193.6.222.43)
	by server-8.tower-182.messagelabs.com with AES256-SHA encrypted SMTP;
	9 Dec 2011 15:47:54 -0000
Received: from wferi by tac.ki.iif.hu with local (Exim 4.72)
	(envelope-from <wferi@niif.hu>)
	id 1RZ2fj-0000HE-6W; Fri, 09 Dec 2011 16:47:39 +0100
From: Ferenc Wagner <wferi@niif.hu>
To: Jeremy Fitzhardinge <jeremy@goop.org>
References: <ce19ea02-45e6-465a-a4c8-b5d74bf8c2ad@default>
	<20111010155319.GA29140@phenom.oracle.com> <4E934EC9.5030909@goop.org>
Date: Fri, 09 Dec 2011 16:47:39 +0100
In-Reply-To: <4E934EC9.5030909@goop.org> (Jeremy Fitzhardinge's message of
	"Mon, 10 Oct 2011 13:00:09 -0700")
Message-ID: <87vcppbvc4.fsf@tac.ki.iif.hu>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=-=-="
Cc: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com,
	linux-x86_64@vger.kernel.org, Zhenzhong Duan <zhenzhong.duan@oracle.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH] cpu idle ticks show twice in xen pvm guest
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--=-=-=

Jeremy Fitzhardinge <jeremy@goop.org> writes:

>> On Wed, Oct 05, 2011 at 10:11:58PM -0700, Zhenzhong Duan wrote:
>>
>>> Run below test on xen pvm.
>>> # x=$(cat /proc/stat | grep cpu0 | awk '{print $5}') && sleep 60  \
>>> && y=$(cat /proc/stat | grep cpu0 | awk '{print $5}') \
>>> && echo -e  "X:$x\nY:$y\nIDLE:" $(echo "scale=3; ($y-$x)/6000*100" | bc)
>>>
>>> @ X:58562301
>>> @ Y:58574282
>>> @ IDLE: 199.600
>>>
>>> Normal idle percent should be around 100%.
>>> xen_timer_interrupt called account_idle_ticks to account hypervisor stolen idle ticks 
>>> but these ticks will be accounted again when idle ticks restarted.
>>>
>>> Signed-off-by: Zhenzhong Duan <zhenzhong.duan@oracle.com>
>>> Signed-off-by: Joe Jin <joe.jin@oracle.com>
>
> Does this affect the accounting of stolen ticks?  If it does, that's not
> necessarily a showstopper for this patch, but we'll need to do some more
> thinking about it.  Certainly, accurate accounting for idleness is
> important.

Please see also http://thread.gmane.org/gmane.linux.kernel/734441, where
I found that the counter doubling isn't always present under 2.6.26.
However, after going to 2.6.32 (Debian lenny-backports kernel, 4th of
April on the graph below) that instability seems to disappear.  Please
note that the following graph shows halved idle and iowait percentages.


--=-=-=
Content-Type: image/png
Content-Disposition: inline; filename=cpu.png
Content-Transfer-Encoding: base64
Content-Description: Modified Munin graph

iVBORw0KGgoAAAANSUhEUgAAAfUAAAEGCAYAAAB8TgymAAAABmJLR0QA/wD/AP+gvaeTAAAgAElE
QVR4nO2dfXQUVZr/vx3QySAtCZ0AkbwRQUZRRCJxlbwAkcgZd4POHpjfWUXEEUSjZ1FXB5goIhGY
UXxDE10xwrLrmQ2ODmF0WRhJJ+PLKEFllOwQzAudQDDkpaERCIH07490Nf1WXVXdVXWr6z6fc3Iq
XV1V3/s8VdW3nvvcutfy9ddfu0EQBEEQRExz4sQJxLEuBEEQBEEQ0XHixAk0NzdjqLBi/PjxLMtD
EARBEESEbNu2DQAoUicIgiAIs0CVOkEQBEGYBKrUCYIgCMIkDJXehCAIgiAIFuzcuTPk+jlz5oRc
T5E6QRAEQRiUOXPmYM6cOZg1a5b3czgoUicIgiAIA3PmzBkcOHAAQ4YMgdPpxNCh4lU3VeoEQRAE
YVBaWlrQ3NyMsWPHIjMzE3v37kVGRobo9lSpEwRBEIRB6enpwc0334xhw4YBAGbPnh12e6rUCYIg
CMKgHD9+HMePHw9aTx3lCIIgCCLGoI5yBEEQBGEiqKMcQRAEQZgAbjvKtdTVAQDG5eczLglBEARB
qAOXHeXO9/Xhz2VlAIBFO3Zg6E9+wrhEBEEQBBE9SjvKmaJS3/v22zh55Ij3/5sfeohxiQiCIAgi
eiwWC4qKimCxWAAAbrcbu3btEt0+5nu/nzxyBF9u2uT9/OWmTd4KniAIgiBiGavVira2NgwMDGBg
YABtbW2wWq2i2+taqVutVu+fL21tbSgsLITNZkNhYSHa29vDrvfl4+eew/m+Pu/n8319+Pi557Q1
hCAIgiB04LrrrkNHRwd2796N3bt3o6OjA5MnTxbdXtdK3eVyweVyBa1fuXIlcnNzceTIEeTm5qK0
tDTsel/uLC/H4wcO4PT/+394/MABPH7gAO4sL1dctjO7dys3SCVI25x6RtAmm0nbrLostfXUtVqt
uOmmm3Dbbbfhtttuw0033YRPPvlEdHtD5NTr6uqwYcMGxMfHo6SkBDk5OWHXa4Hlsss0OzZpG0Ob
J1tZ67LU5tFmltpks7EwRE7d6XQiKSkJRUVFsNlscDqdYdf7cqGnB67KSgz09gL19Rg+fHhEy0vO
nYtq/2iWAwcOMNHlzW4e/czT+WWtS/7mx99SuvF9fXBVVuJcQ0PU9ePOnTuD/sJh+frrr90AMH78
+KjF5WK1Wv2a4TMyMlBfX4/k5GR0dnYiJycHra2toutDsWbNGvz2t78NLWjxLN3q2kFExz6Lxe9z
tucE7YMl1OaiCPvF2vkNtF8MMb9kBxgs129S+ynVi/R4co8rd79AxMonVU6p76X8nO0OOI7nPAeu
F0PudREtQnmC7kOZ5STCc+rUKc2OvXPnzqBX2rZt2wbAIM3veXl5KC8vx/Lly1FRUYGCgoKw67Xg
VF0dhjMauIZX7YmptRjeHqwt9WMdKUb1s1x7pbYL9f2p1LqQPpZz3Ej0fNcHakdqp9LrQdCNtPxS
34fb71RqXVAQIbf83so/wutfzrn2w1POID3PerkPiZempuJce7voQ4JAtA8LoR4+wt1XagUNgUjp
skbXSD1UN3yXywWHw4GFCxdi//79mDJlCrZs2YK0tDTR9aGgSD0GUTsgibXzq09ARgRgqRqMaNzz
52krJFyPAZWk3BaPWEOtlpHAytf7MCByvwTpBvhddWSeJi0j9VAwidRD9XwHgPT0dNTU1MherwVG
jeJMra00sohWj0M/6+3jSLTVrmQDdYXjy9UX+yyFe/68sDZH2iIiF1bnWquWEW/lHqYF41RqHbLb
RdIdAdureZ2Fup99WwbUTGF0dXXh4MGD3oeE4cOHY+LEiUhKSgq5PZOcuhZQpB6DUKTORjagkgr8
kRP78Yt2P7EfU7nHVYrSSlktvOWPMmIU84vW50HzFowoibScUn6T2l6gfv58ABItA271IvWPP/4Y
1113nbcS7+rqwrfffovCwkK/7QyVUzcCPEZxzLUpUtdeV4aPxX685Ea4YuuLW1tRnZmp2nHlIqar
B8WtrRcrHYSO/AXkPjxJrReY+7vnZfk70ocose0Ef0s9RCl9WJPa3lK1DcWtrdj+5BN+38t9mIv0
OsuGe7DvhGcstGj7QsjBYrF4h4mVgip1Dyw7PXCrrXNTIY9+VtIMrTasKlZBV297fbXDIVXJKuXi
/tLacsqjdDu551mpnXIi8urMTCbneXh7vk/5tG0inDx5MhobG/HVV18Nag8fbpwR5VhhqdomeeJP
eaZuZQG32qn6apvNz1LXtaVqG+b+7nnVdeVSLPL6qVl1A7X3WSy6vZ4WqK0nWuuGu85Dacv5vY+2
PHreV8nJyZg+fbp3RLnp06cjOTlZdHuK1D3wGMWx1ra++AOAbbJzW9Hm+szq53D+YRUth9LWK6Iy
is0Xm2PZ2M2bv1nphvKzkHpRA6Ud5WI+Uu/v74fD4UBXVxcAoLm5OeRy0tmzYb9v2LEj7PdaLk/V
1THRZW13cWvrxfMyqRmWqm249j+2hvzsu13g0m+/WPNzCHuULAW/TDp7Nsh/ALDo8GHR7bVe+p5f
HnSBi/4OvF4Dz4+Z7BZ0tbZPjr+NotvY2AiHw4GOjg5Ey/79+zFhwgTMnj0bs2fPxoQJE7B//37R
7bno/W7x9Ap0zzN2r07e8J4Xma8SSfbajbXzG2XLrJJXrZRsT6gD+Z1f3PPmqdr7ffLkyd7I/Pjx
42F7v8d8pK4WZsu3xoK2kA/TOgcmwKOfjZJf5kE3UFuv6zqUtp4Yxd9m1RU6yu3atQu7du3CoUOH
wnaUo5y6B7PmW42srXc+jEc/857vJG3z6rLU1lM3OTk5bMe4QChS98BjFMdaW+nTbrSRT6z6OdBu
JX6gKIq0zarLUltP3VCztIWbqY0idQ88RnGstaN92lVawfPoZ4qiSNusuiy19dYNnJEtHBSpe4jV
KC6WtcWeduW8fx1JxG5UP2uZe6UoirTNqstSm6XNUlCk7oHHKI61NuXUtYfViFuCNk+6vGqTzcbC
EJF6dXU1Jk2ahJEjR2LWrFloaWkBALS1taGwsBA2mw2FhYVob2/XrAxGjeLMrK33026s+zmSiJ6i
KNI2qy5LbT11lTS9Awap1B955BG89tprOHbsGH79619jxYoVAICVK1ciNzcXR44cQW5uLkpLSzUr
A49RHGttitS1h6Io0jarLkttitRl4DsDzWeffQYAqKurQ0lJCeLj41FSUgK73a6ZfqxHcbGoTZG6
9lAURdpm1WWpbeScuiEq9RdffBFLly5FamoqPvnkE5w8eRIA4HQ6kZSUhKKiIthsNjidzqB9L/T0
wFVZiYHeXpzyVPqByzs8zfli35+y2zE8Pz/s91ouMTDARJe13XHuwbGxhfMT7TLm/Jxq9y9/qj3k
Mhq/VGdmquZfpUu1z6/Rdcnf/PhbSvd8dzdclZU419AAvTHcMLF1dXVYvHgxDh48iIyMDNTX1yM5
ORmdnZ3IyclBq8gTkqxhYoVhRt3B2/A41zZr7bnPh57/OVKkhok1mp+F61JAahjcSGA9tzgLbR5t
ZqlNNgej5jCxcjHcMLFutxuNjY349a9/jXmeH+e8vDyUl5ejr68PFRUVKCgo0Eyfx3wra23KqWsP
5TtJ26y6LLX10v38889x9OhRuN0hIlERDFGpW61WXH755ZgzZw7y8/Px1FNPAQDWrl0Lu92OlJQU
1NbWoqysTLMy8JhvZa1NOXXtoXwnaZtVl6W2XrrXXHMNjh8/jtraWnz//ffo6+uT3McQ76m7XK6Q
69PT01FTU6NLGXiM4lhrU6SuPRRFkbZZdVlq66U7YsQIXH/99ejr60NbWxs+//xzJCYmIjMzEyNG
jAi5jyEidSPAYxTHWpside2hKIq0zarLUltv3Z/85CcYP3488vPzkZycjIYwHfAMEakbAR6jONba
FKmHR42R4CiKIm2z6rLUZqUbFxeHK664AldccYX4NjqWx9DwGMWx1qZIXXsoiiJts+qy1Dbye+pc
RepC5ONG8KtDsRbFmUGbIvXQqDlWO0VRpG1WXZbaNKJcDMBjFMdamyJ17aEoirTNqstS28iResxX
6v39/XA4HOjq6gIANDc3h1xOOnvWbxn4fWdqatj9tVwOz89nosva7urMzKDzEu0y1vzsW35L1TZc
+x9bVfVH05gxqh5PyVKL82tkXYD8zYu/pXQbGxvhcDjQ0dEBvTHciHKRImdEOYFQI48ZbbQxHrRp
RDntp0Sl0b5I26y6LLVpRLkYIFbyrWbSppy69lC+k7TNqstSm3VOfefOnaLfUaXugcd8K2ttyqlr
D+U7Sdusuiy1jZxT56r3ezh4jOJYa1Okrj0URZG2WXVZauupGy4qDwVF6h54jOJYa1Okrj0URZG2
WXVZauupO2fOnKC/cFCl7oHHKI61NkXq2kNRFGmbVZelNuucejgMUalXV1dj8uTJSEhIwOTJk7Fj
xw4AQFtbGwoLC2Gz2VBYWIj29nbNysBjFMdamyJ17aEoirTNqstSm3VOPVy0bohX2lJTU7F582bk
5eWhtrYW9913H9rb27FgwQJkZWVhxYoVWLduHQ4fPozNmzeHPEa0r7QR+qP2K12xdl71eKWNIAj9
UfOVtq6uLhw8eNB7vOHDh2PixIlISkry285Qr7Slp6cjLi4OFosFQ4YMQaanaaOurg4lJSWIj49H
SUkJ7Ha7ZmXgMYpjrU2RuvZQFEXaZtVlqa2n7v79+zFhwgTMnj0bs2fPxoQJE7B//37R7Q1RqW/c
uBELFy6EzWbDvffei1dffRUA4HQ6kZSUhKKiIthsNjidzqB9L/T0wFVZiYHeXpzyVPqByztaWvyW
obYbnp8vur/WSwwMMNFlbXec2w0g+PxEuow1P6tld7hldWamLjqhlmqfX6Prkr/58beU7vnubrgq
K3EuzBSpSrBYLN4/yW2N0Pw+depUrF+/HgUFBbDb7fjNb36D+vp6ZGRkoL6+HsnJyejs7EROTg5a
RZ6QaES52NOmEeVoRDkz6fKqTTYHo2bz+/Hjx9HY2OjX/H7VVVchOTnZbzuh+d0Q76n/8MMPAOBt
fj927BgAIC8vD+Xl5Vi+fDkqKipQUFCgWRl47BnNWpt6v2sP9UwmbbPqstTWUzc5OTmoAg+HIZrf
X331VTz66KNITk7GsmXLsHHjRgDA2rVrYbfbkZKSgtraWpSVlWlWBh7zray1KaeuPZTvJG2z6rLU
1lN3586dIf/EMETzuxpQ7/fYg3q/U+93gjAjaja/79y5E3PmzPEufdf5Yqje70aAxyiOtTZF6tpD
URRpm1WXpbaeunFxcXC5XLBYLDh58iROnTqFoUPFM+eGyKkbAR7zray1KaeuPZTvJG2z6rLU1lM3
NTUVf/3rX3H11Vfjq6++Qn9/PyZOnCi6PUXqHniM4lhrU6SuPRRFkbZZdVlq66l7zTXXYPbs2UhP
T8eMGTO8/4tBlboHHqM41toUqWsPRVGkbVZdltqsZ2mj+dRlwGMUx1qbInXtoSiKtM2qy1Jbb125
Pd8BE1Tq/f39cDgc6OrqAgA0NzeHXE46e9ZvGfh9Z2pq2P21XA7Pz2eiy9ru6szMoPMS7TLW/Ky2
/YHLpjFjdNEJtdTi/BpZFyB/8+JvKd3GxkY4HA50dHRADZRMvUqvtHkw2mhjPGjTiHI0opyZdHnV
JpuDUfOVNrnQK20B8JhvZa1NOXXtoXwnaZtVl6U2zaceA/CYb2WtTTl17aF8J2mbVZelNuv51MNB
lboHHqM41toUqWsPRVGkbVZdltoUqccAPEZxrLUpUtceiqJI26y6LLUpUo8BeIziWGur/bS7z2LB
vjDzDfPoZ4qiSNusuiy1KVKPAXiM4lhrq/20mw03suEW/Z5HP1MURdpm1WWpbeRI3RBjv1utVr/P
I0eOxOHDh9HW1oZ7770X33zzDaZMmYItW7Yg1fO+r9rwGMWx1qacuvZQFEXaZtVlqa2nbldXFw4e
POh9RW748OGYOHEikpKSQm5viEjd5XJ5/5YsWYL77rsPALBy5Urk5ubiyJEjyM3NRWlpqWZl4DGK
Y61NOXXtoSiKtM2qy1JbT939+/djwoQJmD17NmbPno0JEyZg//79otsbIlIXOHHiBKqqqvDll18C
AOrq6rBhwwbEx8ejpKQEOTk5mmnzGMWx1qZIXXsoiiJts+qy1NZb12KxwBKmv5AvhojUBd555x3c
dtttSElJAQA4nU4kJSWhqKgINpsNTqczaJ8LPT1wVVZioLcXp+x2AAha3tHS4rcMtd2pujrR/bVe
dr3xBhNd1nY/63l4Czw/kS5PpYbXM5qf1bI73LK4tVUXnVBLtc+v0XXJ3/z4W0r3fHc3XJWVONfQ
gGiZPHkyGhsbsWvXLuzatQuHDh3C5MmTRbc3zDCx58+fx3XXXYf/+q//wtSpUwEAGRkZqK+vR3Jy
Mjo7O5GTk4NWkWaPaIeJJfRH7WFS3fM951W8r5yh0GOYWIIg9IeGiQWwfft2pKameit0AMjLy0N5
eTn6+vpQUVGBgoICzfR5zLey1qacuvZQvpO0zarLUltP3cAZ2qRmajNMpf7aa6+hpKTEb93atWth
t9uRkpKC2tpalJWVaabPY76VtTbl1LWH8p2kbVZdltp66wozs8mZpc0wlXpNTQ3uuOMOv3Xp6emo
qalBT08P9uzZg7S0NM30eYziWGtTpK49FEWRtll1WWrTe+oxAI9RHGtttZ92LVWDOSU3QveZ4NHP
FEWRtll1WWrTiHIxAI9RHGttitS1h6Io0jarLkttPXV9m97lQJW6Bx6jONbalFPXHoqiSNusuiy1
KVKPAXiM4lhr8xqpS008oyYURZG2WXVZarPu/R4OU+fUvT+cVVWS2/IYxbHW5jVSvzjpjPbvqVMU
Rdpm1WWpraduqGb3mHilLVL6+/vhcDjQ1dUFAGhubvYus+FG4qQmAMCks2f9lr7bAUDDjh0h1+ux
PFVXx0SXtd3Fra1B50WtpeH9PKlZE7sDl4sOH9ZFJ9RSy/NrRF2A/M2Lv6V0Gxsb4XA40NHRAb0x
zIhy0RJyRDlPoC70ihagEeWMgVYjqhn+/IpclwRBmAMaUc4AGCXfyoW2ZfCP15y6nlC+k7TNqstS
W++cupx1AqbOqSuJhIySb+VJm9ecup5QvpO0zarLUltvXanOcb5QpO6BxyiOtTZF6tpDURRpm1WX
pbbeusLwsHKGiTV1Tl0sZ2v4nKvZ0TinbPjzSzl1gjA1lFM3ADxGcay1KVLXHoqiSNusuiy1aex3
Cfr6+rBq1SpUVVXh+PHjAACXy4W2tjbce++9+OabbzBlyhRs2bIFqampmpSBx3wra23KqWsP5TtJ
26y6LLX11BXLp4s1wxsiUl+zZg3+8pe/4H/+539w8uRJuFwuAMDKlSuRm5uLI0eOIDc3F6WlpZqV
gccojrU2ReraQ1EUaZtVl6W23mO/z5kzB+PGjcOIESMwa9assHl1Q+TUr7rqKlRWViI3N9dvfUZG
Bvbu3YtRo0ahs7MTOTk5aBVxJuXUYwet3k8XMPz5pZw6QZgaNXPqZ86cwYEDB3Du3DlceeWVaGtr
w7XXXov4+Hi/7QyVU+/s7MTu3bsxevRoXH311fjjH/8IAHA6nUhKSkJRURFsNhucTmfQvhd6euCq
rMRAby9O2e0A4F3e0dISchm43Sm7Hafq6kKu12PZ9cYbTHRZ2S2ch2e//NLvs1pLo/v5zt/+Dpaq
barbHWpZ3Nqqi06opVbn16i65G9+/C2le767G67KSpxraEC0fPbZZxg5ciRuvvlmjB49GpMmTcJ3
330nur0hIvW0tDRs2rQJM2fOxKeffop7770Xhw8fRkZGBurr65GcnEyRuongPVLX2n6CINiiZqT+
448/4rLLLvNbd+7cOVx66aV+6wwVqd9yyy1+ny2eiVjy8vJQXl6Ovr4+VFRUoKCgQLMy8JhvZa1N
OXXtoXwnaZtVl6W2nrp/+ctfgmZp27Nnj+j2hqjU169fj/Xr12P06NF4+OGH8eqrrwIA1q5dC7vd
jpSUFNTW1qKsrEwVvVBTX/LYM5q1NvV+1x7qmUzaZtVlqa23rtAxTs7gM4ao1MeNG4eamhr09vbi
wIEDKC4uBgCkp6ejpqYGPT092LNnD9LS0lTRy4Z7cPpLzxjkAJ9RHGttrZ52xeYrV91Wn+tH6nuK
1M2vy6s22WwsDPGeuhFgEUkJFU+22627toAZI/WL85X7E62tYudLznmkSN38urxqk83GwhCRuhEI
F0kJkZ9YBCi2Xmo7ocUgUFvu8eTqhMOMkboYUrZK+c3bwiO1PiCC32ex4FuVWpmUQlEUaZtVl6W2
3u+p+y4D/w/EnJG68INaJX+XcJGUWOQX9L2g6/kYWEHIjSCl9KRQsr8ZI3WBwAhazFbvdiJ+k/pe
imy4gfaIdo0aiqJI26y6LLVpRLkYQFHEKjOXKkRwYhGewLdpaWEjxMAIUqrlQAly7I5ax+OPwONo
/bQb6HcxW6XOT+D3ov4Ic12cSqWcutl1edUmm7VF6Bw3a9Ys7+dwmDJSlztSl7BdvWW+33rvD7hO
qe7r2ttCrheLEGVHlAEtB6EYnp8vmRNW3BIhHCaggrtY7kG/6/a06ynHQQy+EinVh0G2PxQwvJ1y
6mbX5VWbbNYeYVS5IUOGwOl0YuhQ8ao75iP1/v5+OBwOdHV1AQCam5sBAJPOnhVdWqq24dr/2Or9
nA03flpQjWy4kTipafA4k5qxz2LBrmuv9X4OuWwWWR9uaQGar734+VRqXUi9wPKI6nmOF3J73/08
2/nqNOzY4b9fc0D5xOxrvqgnu5w+y0lnz6K4tTXseYpmGUp3YmqtuJ0+23ntEfk+kmVDwQ4/v2hl
d+By0eHDuur5LrU8v0bUBcjfvPhbSrexsREOhwMdHR2IlpaWFnz22WcYPnw4brjhBuzduxfp6emi
2xtiRDk18B1RTumIXe758kYgEyJ7Yft9iC7XqhTV9QIjapEIWylS5dRrzHOx86qWHwOvB6nvBd0b
qxR09iAIIuZQc0S5ffv24eqrr8awYcPCbmeoEeVUQyrXHYZwOU9L1Ta/ikj4LJWLFdsv8LPcfKuU
nlICe2WrkaMH5JdT997vHj+r7Uep8yxoq60rB8p3krZZdVlq66mbnZ0tWaH7YsqculIuRlSBn5VF
8JF+L5VvjbY8YvsF9srWKnIVW691XipQV20/Ky+HqoeVBeU7Sdusuiy1jfyeuqkq9WiadYtbW4P2
16qZOPC4c3/3vCoXidKHC/f8eTiVWhdU2cl9KFDqn8Dti1tbdb05Am2N9PyK7RfueCwjClY/QKy0
ebSZpTbZbCxMValHQyQnSK1KX662mJ5UZBmunEp6Zasdyep1U0Ta0iFsr8Z55jGiIJv50CabjQVV
6h5i+WkzmohTjna0EbkYevtcaYuImi01FKmbX5dXbbLZWJiq9/vvbryRdTG4QM0IliAIwmyo2ftd
Lobq/W61Wv3+BNra2lBYWAibzYbCwkK0t2s31iaPPTgj1Q7Vu1sv7VjSM4I22UzaZtVlqW3kWdoM
EalbrVa4XK6g9QsWLEBWVhZWrFiBdevW4fDhw9i8eXPIY1CkThAEQRgB7iN1AEhNTcXo0aPxz//8
z3A4HACAuro6lJSUID4+HiUlJbDb7Zrp8/i0yZs2T7b66S6fN/jHQpsBPJ5nltpks7EwRKXucrnQ
3t6OAwcO4Oqrr8aiRYsAAE6nE0lJSSgqKoLNZoPT6Qza90JPD1yVlRjo7cUdLS0AENGyOjMzqv2j
WcZ5xhhnoc+T3Tz6uTozE3ck2JnYzcrfPJ5nlnbz6G8p3fPd3XBVVuJcQwP0xhDN776cPXsWV1xx
BXp6epCRkYH6+nokJyejs7MTOTk5aBV5Qoq2+Z3HHpy8afNkq5/uG08Mflivb8dGHnsm86hNNgdD
ze8eTp06hY0bN2Ly5MkAgLy8PJSXl6Ovrw8VFRUoKCjQTJvHdy150+bJVta6LLV5tJmlNtlsLAxR
qQu93jMzM2G32/H2228DANauXQu73Y6UlBTU1tairKxMszLwmBfiTZsnW1nrstTm0WaW2mSzsTBc
83ukUO93ghjEPX9wkHmLMBuc0ElO5+Z3guAVan43ADw+bfKmzYutliw3LFlu3XUD4TGK4lGbbDYW
VKl74DEvxJs2T7ay1mWpzaPNLLXJZmNBlboHHp82edPmyVbWuiy1ebSZpTbZbCyoUvfA49Mmb9o8
2cpal6U2jzaz1CabjQVV6h54fNrkTZsnW1nrstTm0WaW2mSzsYj5Sr2/vx8OhwNdXV0AgElnz0a0
bBozJqr9o1lWZ2Yy0eXNbq78PK7ZX9fzmQd/c3WeDWA3j/6W0m1sbITD4UBHRwf0hl5p88DjqEi8
aXNjq88rbDSiHGmbVZelNo0oFwPwmBfiTZsnW1nrstTm0WaW2mSzsaBK3QOPeSHetHmylbUuS20e
bWapTTYbC6rUPfD4tMmbNk+2stZlqc2jzSy1yWZjQZW6Bx6fNnnT5slW1rostXm0maU22WwsqFL3
wOPTJm/aPNnKWpelNo82s9Qmm42FoSr1DRs2wGq1ej+3tbWhsLAQNpsNhYWFaG9v10ybx6dN3rR5
spW1LkttHm1mqW04m5fPu/gGiJ66BsEwlfrf/vY3vP76637rVq5cidzcXBw5cgS5ubkoLS3VTJ/H
p03etHmylbUuS20ebWapTTYbC0NU6n19fVi8eDHWrVvnt76urg4lJSWIj49HSUkJ7Ha7ZmUw3NMm
ace8nhG0i1tbkdV0JbKarmSizQIezzNLbbLZWBiiUn/22Wfxs5/9DL/85S/91judTiQlJaGoqAg2
mw1OpzNo3ws9PXBVVmKgtxd3tLQAQETL6szMqPaPZhnndjPR5c1ubvycYPfTvdWewMRuVv7m5jwb
xG7D+dvn+tdV12d5vrsbrspKnGtogN4YYkS5ESNGYGBgwG+dy+VCRkYG6ipDyboAACAASURBVOvr
kZycjM7OTuTk5KBV5AmJRpQjbaPpMdMOGFHuuyfeAAA0b1uvj74Ho472Rdrm0BXV9rn+ddX1gfsR
5U6cOAGXywWXywUA3mVeXh7Ky8vR19eHiooKFBQUaFYGHvNCvGmbxVb3/Plwz5+vu65SeMx38qhN
NhsLQ1TqYqxduxZ2ux0pKSmora1FWVmZZlo85oV40zaLrZYsNyxZbt11lcJjvpNHbbLZWAxlXYBA
hCgdANLT01FTU6OLLo9Pm7xp82Kr0Cmuedt6VGdmIks3ZX94jKJ41CabjYWhI3U94fFpkzdtnmwF
BpvpXY89pruuAI9RFI/aZLOxoErdA49Pm7xp82QrMNhMb720TXddAR6jKB61yWZjQZW6Bx6fNnnT
5slWr25CHRNdgM8oikdtstlYUKXugcenTd60ebLVq+vMZ6IL8BlF8ahNNhsLqtQ98Pi0yZu26W0N
MeY1ReqkbVZdltoUqWtIf38/HA4Hurq6AACTzp6NaNk0ZkxU+0ezrM7MZKLLm92m8vO45rDrxzWP
G9RNTPX7zIO/TXWeY8BuQ/pb7P7Q6Tw3NjbC4XCgo6MDemOIEeXUgEaUI22j6amtLQw4431HPXDE
LE+U7n2l7comFCfU4bt9iwY/04hypG0iXVFtzkeUM9x76qzgMS/Em3as2yp3wBk/XWc+vadO2qbU
Zantq+t92K6qYlKWQGK++V0teMwL8abNk61eXcqpk7ZJdVlq++oqGeFRD6hS98Dj0yZv2jzZ6tWl
3u+kbVJdltrU+z0G4PFpkzdtnmz16lKkTtom1WWpTb3fYwAenzZ50+bJVq8uReqkbVJdltoUqccA
PD5t8qbNk61eXYrUSdukuiy1KVKXoLq6Gjk5ObDZbMjPz8enn34KAGhra0NhYSFsNhsKCwvR3t6u
XRk4fNrkTZsnW726FKmTtkl1WWpTpC7B+++/j61bt+Lo0aN44okncM899wAAVq5cidzcXBw5cgS5
ubkoLS3VrAw8Pm3yps2TrV5ditRJ26S6YtpZTVd6x2rQU9coGOI99c2bNwMAzpw5g/PnzyMhIQEA
UFdXhw0bNiA+Ph4lJSXIycnRrAw8Pm3yps2TrV5dek+dtE2qy0rbaO+lB2KISB0ArFYrRo0ahWXL
luHtt98GADidTiQlJaGoqAg2mw1OpzNovws9PXBVVmKgtxd3tLQAQETL4tbWqPaPZvnsl18y0eXN
7pj3c4Ldfyny/a32wYfiJW9n4/53sr2fzX5+Wevydj+x1hXzt9bX+51TazB3am3wfemz3fnubrgq
K3GuoQF6Y6hhYk+fPo2PPvoIzz//PL744gtkZGSgvr4eycnJ6OzsRE5ODlpFmj2iHSaWIAxPwGQt
UsPEBqL3MLEEwYKsecsBaHi9Bw5DG2JYWpbDxBoiUn/wwQfR1taGIUOGYMiQId5B8PPy8lBeXo6+
vj5UVFSgoKBAszIYLS9E2rGvp5W2kpzhrLoE1XSVQjlePrS5tJlhXxUpDFGp5+Xl4ec//znGjBmD
9evXY9OmTQCAtWvXwm63IyUlBbW1tSgrK9OsDLzlhXjU5slWgT35wSkrvaAcLx/amuuGmFJYDW33
/Pne/LhSWL5VIoUhKvV/+Zd/wbfffove3l588cUXKCoqAgCkp6ejpqYGPT092LNnD9LS0jQrA49P
m7xpm9bWMD96FKmTtll1o9WOZsx2itRjAB6fsHnT5slWAYrUSdusupprh2shoEjd+MTq0yZpG1dP
b+1QuXaK1NlpR9O8G622nmilK8d/kWhLHVf0e59KniL1GMC0T5ukzUzPCNoUqbPT1ntKTrP5W47/
ItGWOq4sXZ9IXY/BbpRAlboHozzdk7Z59DTXDtM8KECROmmbVVct7UhaVChSjwGM8nRP2ubRM4I2
ReqkrZuujIfMqAhxfDVsjqRFhXLqGtLf3w+Hw4Guri4AwKSzZyNaLjp8OKr9o1kWt7Yy0eXNblP4
eVwzAGBc8zi/z4HrheXcHdf6b8+Bvw11noXzY2K7/XRl2OuePx9Nq1fLO37A9R14/EWHD4c8nuT1
Huq4y+dh0pvZYfWEz4uu3RFWr7GxEQ6Hwzvmip4YakS5aKAR5QizETTGdMCIcc1XNvltL5XX425E
uRAjfXGlrzdy7VW6XSCBI7kFrBdGlGuyDFbA3ihcbD8pJPbz3o8+9xf3I8oZgVjPC5G28fSi1Q5s
FoykQw7l1EnbrLpA+Ny2lh0VjZxTN8QsbUaAx1wYb9o82SpAOXXSNoyuRIQcyexnrHLblFOPAXh8
wuZNO1ZsVfP9ZorUSdvousL1HklkzSpipkg9BuDxCZs37VixVc0mQ4rUIyeiyDFGrjEj6QZe716/
y7gP/CJmoSXAk1NXjYAWhqymK/EdAAT0aTEKFKl74PEJmzdtnmwVoEg9cqQix6AWleXzULx+tCra
kRDr/hZQErGziphZ3ldSGKJS//3vf4/rr78eI0eORG5uLurqBk9UW1sbCgsLYbPZUFhYiPb2ds3K
wOMTNm/aPNkqQJG6Coi8fx2q8mGZazWNv5VoM/I3y/tKCkNU6h9++CHeffddHD16FA8//DDuuece
AMDKlSuRm5uLI0eOIDc3F6WlpZqVgccojjdtnmwV4CJSD6h0jdobW3Ntk0TqirQpUg/CEDn1rVu3
ev/Py8vDyZMn0d/fj7q6OmzYsAHx8fEoKSlBTk6OZmXgMYrjTTtmbZXIFYZ7zc1UkbrM95vZR45s
3kunSF0CFUe7o0hdJt3d3bjrrruwdOlSXHLJJXA6nUhKSkJRURFsNhuczmBHXujpgauyEgO9vbij
pQUAIloWt7ZGtX80y2e//JKJLm92G93Prsceg3v+fNyRYB9cH7C81Z7gtxRb77ucVZdwcftYP7+C
PyTWe3XFtleqF3ic9cnA8nkX1/t8Lk6oky5vrPhb6jpV6u9Afwb6UebS9z4pTqgTvU+kjrPk7Wxk
NV2pWF+4r4L0fOw9390NV2UlzjU0QG8MM6LcN998gwULFuAXv/gFVq1ahbi4OGRkZKC+vh7Jycno
7OxETk4OWkWaemhEOSLmkYgkAiNyYUQ5uQPSxPyIciIjiAnr3c0WAMEj8EU8opuEniiB25ltRDkx
u6Ts1XJceB/ERlwM/F5AbDup4wdCI8r5sHXrVixbtgybNm3C6tWrERc3WKy8vDyUl5ejr68PFRUV
KCgo0KwMPOZbedPmyVaBmMypRzgxiNBxTW9dX3jKqQu9/7XWDTeSohr+Fjt+4HrfzyHvK60ntJGJ
IXLqDz30EADg1ltv9a47duwY1q5di4ULF+KVV17BlClTsGXLFs3KELP5VtI2rJ4RtM2QU1fy3nIk
ukqPH1abo5y611+Z4e2N1L9yWqC06P0uR5dy6hK4XK6gv8suuwzp6emoqalBT08P9uzZg7S0NM3K
wGMUx5u22WyVMxa8ESN1pSPmKR1pTKmv1Rwj3MyRuth5k9LVagz2rKYrcf872ZL3gdw5E5TMrUC9
32MAHqM43rR5slXAUJG6p2ny4g98dBGtWASo1ljkkWxf7cwHVB7QTC5qX2OBI+qJVcxi51ntvgSh
cuXhrm+lkx8pgSL1GMBsURxps9czgrYRI3W1EIsAhd7RLPCN1COZVS8qbUYju7G8r1hd3xSpG4xQ
YzrzGMXxps2TrQKGitQDkBpbPdJcrPXSNiArRGSncS901mOCa9aHQaKFguV95Xt9a/UAFeq4FKkb
DOEJ1DdHxGMUx5u22nqSuWGf3rChtNWcjU0M34hCDz1fos21RpqLFctr6+1v1ZHoXa3XmPeBCC0j
QS0TIuVVswWDIvVguIzUBXxzezxGcabVFsnpqa2nJDfsqx0cgWoXQfpGFHro+aLY3yq9DiTWI1pv
f2uFWAsHq3vZ2zKC6CpqqffLQ8EqYqZIXUP6+/vhcDjQ1dUFAJh09qy85bhmv+Wiw4eV7a/isri1
lYmu6exePg+T3swe/CycX639PK4Z7vnz0bR6tej3gX62ZLlxbWFT6P19rsuspitRuPtWv/Xjmscp
Ws7dca3f51B+0WoZ0t8B911QecS+V7AsTqgL8pciPc91FMr/UkvB30H6Kl5v3uvH93oP4e+w16XC
38eo/R1wPftuF7g+1HaBy0B/y7kf5Bw30vsqsFyNjY1wOBzo6OiA3hhmRLloUTSinNhIUToTyXzN
XBBp71mtz2tguaT0pEbekiAwcom2yVKv3LLodS1mt9yR2hQSSeQXan+BwOOInZ+gz8JIYxLXtWK/
CUiN4CahJxA0Ep9CIh3JTel1rdb9oDZCudzNFsDt5ntEOSPAIrcc9QhYKsCTtl56oXK3sdz7PdL3
ypnNGqbxu+KKRxqTSbTvc0f6fn7Uujq/m6+Wv6MhnK4W7+Qrgeucui/h8lGiT7QB30cacWv9fqme
2kqIWDvCSD7a3thyCbyplR5XzQgkqtyfxHvlUnYxmzWM4ZzmRn7bQDPdCP2txnVOOfVgTBmpR9LL
NdxTrtQTrXe91Ni/It8HaUc5hrCSJ2+K1C+i1chXliw35k6tjXj/aHoLaxnJhHqLxJfi9aNlXcdq
90qPNHJUo1d2RP4OvN8jvP9l308qj1HOchQ9I0bqrDFlpB5JL1dNnnIDZ4+SOyKTjsS0tsIcZdQt
A1HAakxwPSIKsftNbgSn9oOU0shRbkWu2pjgKo+4plrfnAivcx5bRkLpRtuHQy1MGalHgpKoUcn7
yYB0BGj2aDnIXx7/SGlHG8EF+l1UT6XIJVx5WUUzsiIKjWaX0stmIcIW/uTqajHim6oRnMzzYvQ+
DFqOrEeRejCmjNS9KHgiVhLFqf2+6/Ynnxw8rtwnbbH5oyNAj0j94shUyrTV9rPWs4aFe3Azc6Qu
htoRnNx5sL/btwhZqirLR5G/VX6QEvsdUXMWulAEnmc9I1YjRepGwRCRutVq9f750tbWhsLCQths
NhQWFqK9vV2zMvg95eo8L+7cqbXhbziR8kjmgGXYIevp3nMcpS0Ueo2AJYXa8z5HknuXEz0yjxy1
yrVqdD+J+SvQZj3HYJ9Vl6D7mO8CYr8javcVCbSPcurGwhCRusvlAoCgSn3lypXIzc3Fhx9+iHXr
1qG0tBSbN2+OWEfsiVXrJ1kpxCIaxeWK4IczmhaKaP0mRBbe40u1OERYMQjlcz8ps2VDg1mmTBWp
i5yHwOsh2l7Rkb6PLGazHhGkmVpGpBD8+R0QsmVEjwcbitSDMUSkLkZdXR1KSkoQHx+PkpIS2O32
qI4Xrvd6NL2TlRIY8Yo96cp9wpadew4RMRW3tgatl3u8aCMAIbJQo8VBiZ7s46oYYRoxp652r/Og
PgxR2hxpxCsVRak1/7Zcbb3G3Nf7/XwBllErRerBGLpSdzqdSEpKQlFREWw2G5zO4KejCz09cFVW
YqC3F3e0tAAA7kiw+y/F1vssq535wevXJwPL54nvJ+O4oZZ3Tq2BJcvt/RyHAQAXJ0ZQqhd4PKn9
vDotLajOzAzaznu8SP0p0y+C3dH6U7FepDpRLKud+ZK6t9oTVF/uyXd6Py95e3Do06DzLPe6l7of
pM6vzGW0dscNymriT6mlr7+FpeT9qdJSq+tbuG5ixd+sde9IsON8dzdclZU419AAvTHUMLFWq9Xb
FA8AGRkZqK+vR3JyMjo7O5GTk4NWkbyo3zCxYsN3hsvvJtQpb75SaXhL2dpqD6e5fhuKW1tR/cYT
6h5f5nGC7I5UX6meRsOSSmov/yGsrhbNlbPqEoKaCpssg+NTa51uEruu1RouVIxQNutFKG29XnES
/C31Cq1c5J4Po/mbtW7zlU1wN4HZMLGGyKmLkZeXh/LycixfvhwVFRUoKCiI7EAyfrwjyUeplYuX
q61F7l+L3u9yy6laDlBm5ezV07Ey99NeLr2d2oT64dGr74hYr2itYZnv1FJbqk+A4G+9KnMBs/rb
iLpyMETzu2/Pd9//165dC7vdjpSUFNTW1qKsrEyzMkSSj1KrV6lcbS1GPNOiB7rccgbZrfFbByx7
6Roxp641PNqsh7ZYbpv8bX5dORiq+T0a1qxZg9+991vWxSCIiNErkmU14pXRZtXSC7X8Lfc9fbV1
CGWwbn43RKRuBHiM4njT5slWAYrUY19bbm98VmPem83fRtaVA0XqBMEIVhGRXpG62vPBxypy/S2W
M5fym1rzxRPqQJG6QeAxiuNNmydbBSiKMr622PzsSiNoVmPex5q/Y1lXDhSpEwQjzBqpUwToj5S/
o/WX2PGppYQNFKkbBB6jON60ebJVQI2IQquR3bTCqJFjYASudsR8/zvZIY+n9Vj0RvU3K13WD08x
X6n39/fD4XCgq6sLADBpXHNEy6bE1Kj2j2ZZ7cxnosub3Ub087jmcZouW1ITQ66XU+6spitRuPtW
yf18t/O1a0++U3P7Qi1Z6crxt1a6k8Y1+9mt1/VlVH+z1m1sbITD4UBHRwf0hprfPUQ0opxKkLY6
SA3Ocf872diT7xTtiKS0WVpqZDTfz7PqErBp0b6Q+2mJnBHO5HbQUtqBy4ijfbHQ1rr5Wzh+4PWt
58x0RvK3EXSb0MSs+Z3LSl3uMJVS66WOJxex3JfcXJnWaKUnVZmoVcnK1ZPaL/B7pcOdGiW3GWk5
lFbqBMErvpX6ByUlmLViBUakpmqqGRPDxEZKJJVscUIdvpM4TuB6qUpXjMAfVeGpL3A/pZWUVGUS
iuKEOny3b5Hkdmrp+RJot1qVsNh2UnpSumLHlVovaDeLfqsdoSKKSCtjpfsZNYoibXPostRWotts
t8Px178i51e/wrT77sPQ+HhNy2bKSF3rCSPMilp+In8TBMEzvpH6hkmTvOtHpKVh1ooVyIp0HpMw
xHzze2NjI959913v56+++gpTp06N+HjnW1owdNw4NYpG2gbV5slW1rostXm0maU22Rweq6eyBYAR
qamDlfqMGaqXKeYr9UDWrFmDp556KuL9z372GeJvuUXFEpG20bR5spW1LkttHm1mqU02h2fDpEkY
Gh+Paffdh5xf/Uqz5nd6Tz2A/kOHSNvk2jzZylqXpTaPNrPUJpvDk1VQgHv/+EfcUlKieT4dAIYs
Xbr0GQAYOXKk5mJaUldXF/l86wCGpqYibtgwFUtE2kbT5slW1rostXm0maU22Ryeq2+/HfEjRmhc
IqChoQGAiZrfGxoacM0117AuBkEQBEHojuma36lCJ6xWK+siECbDarV6/wgiFoipSr21tRUzZszA
yJEjMWPGDDgcDsl91LoZrVYrXnnlFdWPK1f78ssvx/jx4/Fv//ZvOHPmjG7agj6LHzZfXT30rVYr
Nm7cCAB49dVXdbe3oaEBVqvV24ymB6xtNsK1FQ6XywWXy6WqNovzDACff/45ZsyYAZvNhsmTJ+O/
//u/ddHl9XebFTFVqa9YsQK33347Ojo6MGfOHKxYsUJX/S1btug+9J/AiRMnUFtbi56eHjz99NO6
amvxw6ZUW68ybNmyBW63G1u2bNFcK5Ddu3cjLi4Ou3fv1lWXpc2sri2W1zSr87xgwQIsXrwY7e3t
+NOf/oSamhpddHn+3WZBTFXqn3zyCX71q1/hJz/5CRYvXoxPPvkEALB//37k5uYiISHB70lM+F+t
SOCuu+7C66+/7rfuiy++wLRp05CYmIhp06bhiy++AABMnz7de9Ps2bMHubm5UWlbLBaMHTsWa9as
wR//+EcAg+/q33rrrRg5ciSmTJmCTz/9FIC4P9RE8GliYiJuueUWr61WqxUVFRVIT09HWlqaJhWF
mN0A8PTTT2PUqFHIzs7Gvn37FB975MiReOGFF5CUlORdJ2ar8N3TTz+N0aNHY/r06VHZ9ec//xl3
3303/vznP/sdv7S0FMnJyUE2qaWtxOaZM2diz549AIA//OEPmD17dsS6YgRes773sZbXlpiu2oid
51DaX331FW688UYkJydj1apVUZXpsssug8PhwLfffovk5GS88cYbAMTvp3DXnhJ4/t1mQUxV6idP
nkRCwuCUd4mJiThx4gQAYOnSpViwYAF++OEHv6dv4X+1nsqXLl2Kd99916sLACUlJXjkkUdw9OhR
lJSU4OGHHwYw+FS8detWAMDWrVuxYMGCqPUBYMyYMd4Z6e6//34sWbIEHR0deOGFF1BSUuItZyh/
qIng066uLrz44otYsmSJ97uhQ4fi4MGDqKysxKpVq6LSCdX8LmY3AGRlZeHw4cNYtmwZHnroIcV6
ixcvRllZGRYvXuxdF85WAEhOTkZLSwumTZsWoZXA6dOnsXfvXjz11FPYu3cvTp8+7f1u/PjxcDgc
WLZsmZ+tamkrsbmkpMR7Xb/yyit49NFHI9aNBDWvLRaEO8+hKCkpwYMPPojDhw8jKysrKu33338f
P/zwAx5//HFMnDgRVVVVAMLfT+GuPbnQ77a+xFTv97S0NPztb39DYmIiuru7MXXqVBw+fBiJiYk4
cuQIhoV4xcBqtapyYQjHeemll+ByufD888/D5XIhISEBHR0d+OlPf4rTp09j7Nix6O3tRW9vL667
7jp8+umnmD59Or777jvvhR2pNgAcOXIEM2bMwKFDh5CYmIjz5897t7NYLDh58mRYf0TKhQsXYLPZ
4HQOjnf81ltv4eWXX0Z7ezsGBga82larFb29vRg6dGhQ2ZUitq+Y3VarFZ2dnfjpT3+KM2fOYOzY
sejp6YlYT/gsZquwTU9PDy655JKIbBTYuXMn5s2b5/28bds2zJkzJ6xNamgrtfn8+fPIzs7G6tWr
UVZWhr1798JisURuOIKvLd8ynT9/HomJiXC5XKpeW0p01dASCHeeQ2knJibi6NGj3vM/atQoVcpx
4MAB3H777WhtbdXsfhLg9Xdbb2Ky9/stt9yCt99+G319fdi0aZO3yXHixInYunUrzp07F7TPpZde
KqtjhlweeOAB7xMuMPgwtG3bNpw5cwZVVVXeh6PExETceuutuPvuuzF79uyoLwy3242jR4/imWee
QXFxMQDg+uuvx7Zt23D8+HG4XC5vRRPOH0opLS3FyZMn8fHHHyMtLc27fuXKlXj55Zdx7NgxvPfe
e3C73d7vhB9drRCzG4D3XLz33nu46qqrVNELZyuAqCt0YDDP+uyzz8LlcuHZZ5/1y7f62hT48K2G
dijEbB46dCjuvfdePPDAA3jkkUeiqtDFri2bzYaPP/4YZ8+exebNm/32UePaikR3zJgx+Oabb6LW
FjvPYtoTJ07E73//e5w5cwZ/+MMfotJevHgxWlpa0NfXh4aGBly4cAGA/Psp0sCP599tFsRUpb5u
3Trs2LEDKSkp+Oijj7B27VoAQEVFBbZs2YLk5OSgHMySJUuQnZ2tWn5s2LBhfs2Ur732Gl599VWk
pKTgtddew2uvveb97p577sE333yjShPOiBEjkJeXh+HDh2PNmjUABqPljRs3Ii0tza95Opw/lHLF
FVfgmmuuwQMPPODX3Pn4449j0aJFmDBhAv7v//4vKg2liNkNDOYH09PT8dJLLwXl0SJFD1t3796N
oqIiAEBRUZFfpe5rk+/1pSXhbF64cCHi4+Mxf/78qDTErq1nnnkGCxcuxFVXXeWteNQkEt2VK1fi
tttui/p+EjvPYtqvv/46Nm7ciPT0dBw8eBBxcZH/ZM+cORNz587FmDFjsH79elRUVACQfz9Feu3x
/LvNgphqficI3lCrGVItBgYGsGnTJrS0tGDdunWsi8MNAwMD+Oijj7Bq1aqIO6wpxWjXHhEeU8+n
ThCENowYMQKTJ0/GBx98wLoo3GC1WmGxWJCZmala6xNhXqhSJwgDY7RIyWjl4QGWY0QQsUdM5dQJ
giAIghCHKnWCIAiCMAlUqRMEQRCESaBKnSAIgiBMAlXqBEEQBGESour9LmdgAOpByZef9LDVSO/P
qmWvHJuEbXw1jeKHcOjpIzUx0nUWjlj1b7hySKFlOd955x2sWLECP/74oyIdo/gv6lfastzikww0
W5qjPXxEGMW5fmS5xb9rjm7sbKMRxlKoYanhzq3P8JNByBx1TYlNvuORR8OXX36J5cuXe2dd++ij
j/Diiy/i66+/xrBhw1BQUIDnnnsOGRkZUekAgDvMVWGReVXofd7F9OT8vujpWwBw/5f4d5a75B3D
SPdVfZjvbtRYe+3atdi1axcmT57st17qvBvFf9T8ThCcsnHjRjzyyCPez2+88QaeeOIJOBwOHDhw
ADfccEPUQ8HyCvk2dvnhhx+CKvRYgmmlvn37dtx4441ITEz0G3O4q6sL6enp3mkJ7XY78vLyJPcT
+1/g2LFjmDt3Lmw2W9A83FarFQUFBVi0aBGuu+46PPjgg5raroRw8zyL+QIIb69wHLXmAlcLq9WK
N998E+np6cjIyPCbxCJwClZfTp48iaVLl4Ycv1rKDywJZ9P333+P6dOnY9SoUYqmGZVjr8PhwP79
+72TAwFAdXU1brvtNlx22WW4/PLLsXTpUrS0tERmmIqE89GhQ4eQn5+PkSNHIj8/H4cOHUJ3dzfG
jRsXNK3p6dOnkZWVhe7ubtH54sPpSf2+CMSSb4Hw/hW+D/U7cejQIe/1uXr1as3mn1dKuN/EUNeL
gLCt2+1WVK8YzX9MK/UHH3wQGzdu9M4OJDRfJCUl4eabb/b+oG/evBmLFi2S3E/sf4Fly5bhrrvu
wtGjR4PmDQaAF198Ee+99x42b96MP/3pT5rZrSZivgCk7RVoamqKaj5utXE6nfj73/+Ol156CU8/
/bR3fbj5lR999FFYLBZ8/fXXEfuBBeFseuyxx/CLX/wCbW1tiqbRlWNveXk5lixZgiFDhogeZ/Xq
1bjzzjtl62qF1HkvLi5GR0cHbr/9djz66KOw2WzIz88PGsr2gw8+QH5+Pmw2m+h88eH0pH5fBGLJ
t4D8ecsDfycef/xx3HnnnWhra0N8fLyWRVREuN/EUNeLgJy6JJSvm5wt6gAABOhJREFUjOa/qCZ0
sVqtkjn1cMb+4z/+I7q7uzFjxgxkZ2fj5z//uffHa8eOHXj55ZdRVVWFG264AQ0NDRg+fLjkfkK5
QumOHj3a7+k9cF7sEydOYMSIEThx4gQSEhL8piCMBqvVKplTD+cnsTmvgfC+CGevcJyOjg6vX9XA
arVK5tSlbP3hhx8wbNgwXLhwAYmJiUHnIdT5HTNmDA4ePIgRI0YEHVPKD9FgtVolc+qRdlIaNWoU
mpqaYLVacfLkSYwdO1b0OvBFyl6Xy4Vp06ahvr4+5Lk/c+YMHnnkEfz973/Hhx9+GNKnShi8JsLn
1NXy0fjx49HZ2Ymamho899xzePfddzFhwgQ0Nzdj/vz5KC0txcyZM/G///u/+M1vfoPvv/8eFy5c
CHlNiPk3XG5Vb98K5ZHKqUfTUU7sd0Lq+owUq9UqmVOPtF4Ru14C9ZWed6n99PCfIeZT/+CDD7B6
9WqMHDkSlZWVmDt3rve7OXPmoKmpCaWlpfinf/onP4eE2y8ccXFxfk9vgTexMK1hXFxc0JzZLLFY
LN7pGAObFMP5QspeAKpW6Goh3IBDhgxR5TzI8UOsEso/UvZu3rwZd955Z8hz39jYiJkzZ2Lo0KHY
tWuXKpWOlohdHzNmzMCxY8dQXl6OgYEBvP766+js7MSMGTMAAA899BBWrVqFzs5OdHR0qHa/m8m3
vhjxd0KMcL+JrH7X9fQf00r9kksuQVFRER577DGsXLnSb97mSy65BPPnz8d//ud/Bs1rG24/YLBS
CDXv9cyZM1FWVoYff/xRG4M0IjU1Fdu3b8fp06eDZmkK54tYtTcSbr/9dqxYsQLd3d1B38WqH266
6SZs2rQJ586dw5tvvhn0fUpKCvbu3Ru0Ppy9Fy5cwFtvvRWyz8i7776LuXPn4sknn8Qbb7yhqMmf
FdOmTcNbb72Fvr4+vPnmm97mTYvFgoULF+KVV17B/Pnz8dJLL2HhwoWwWAZ72p89exZJSUk4d+4c
1q9fr0hT7PfFbL6VIicnB2+99RbOnTuHf//3f2ddHC/hfhPFrhc5iJ33SNHKf0wrdaFzgc1mw7/+
67+ioqLC7/vCwkKMGzcO//AP/6Bov5KSEhQUFAR1PHjllVfw/fffY9y4cWE7NhiNZ555BsuWLcPP
fvYzJCQk+H0Xzhexaq8Y4TqsvPTSSxgYGMD1118f9J2R/RDOphdeeAFVVVUYO3YsTp06FbTv008/
jeLiYkXX+fbt2zFlyhSkp6cHHe+BBx5Ae3s7Fi5c6Nf5h/XDkNR5f//99zFmzBhs374dL774ove7
u+++G5deeinWr1+P+Ph43HXXxXe71q1bh1/+8pe4+uqrkZqaKlsPEP99iUXfAvI7AAayYcMGbNu2
DWPHjg1qQWRJuN/EcNeLFGLn3Wj+izqnLkWkOYLz58/j/vvvxzXXXIMnn3wyomMYBS39ZDR4shWI
PXtnzZqF3/72t7p2jIw1H0UKC98CxvGvVM5ZyXGkMMP1Eki0/hNy6lFV6lpitVoxdepUVFdXx1Tu
iSAIgkfUqtR5Ra1KPeoR5bSCLg6CIIjYgX6zo0Mt/9GIcgRBEARhEqhSJwiCIAiTQJU6QRAEQZgE
qtQJgiAIwiRQpU4QBEEQJsHy9ddfu0+cOIHmZjZznxMEQRAEoQ5xVKETBEEQhDn4/4AYmMnejagV
AAAAAElFTkSuQmCC
--=-=-=


(I haven't collected steal values, so the numbers don't sum up to 100%.)
I'd be grateful if this discrepancy could be cleared up eventually!
It's heartening to see some progress after more than three years. :)

Actually, as Munin doesn't half the idle and iowait values, but
truncates the (then overflowing) graph at 100%, I was rather surprised
to see iowait completely disappear after the kernel upgrade, and
concluded that it was somehow converted into buggy-looping in blkfront.
Now I see this isn't the case, but the steadily increasing system CPU
usage between reboots is still a mystery.  I'll start a separate thread
for that, just wanted to provide some motivation for this topic.
--
Thanks,
Feri.

--=-=-=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--=-=-=--


From xen-devel-bounces@lists.xensource.com Fri Dec 09 16:20:26 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 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.xensource.com>)
	id 1RZ3Ay-0003pM-SY; Fri, 09 Dec 2011 16:19:56 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RZ3Ax-0003pH-GI
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 16:19:55 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1323447545!6601271!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI2MQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25998 invoked from network); 9 Dec 2011 16:19:05 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 16:19:05 -0000
X-IronPort-AV: E=Sophos;i="4.71,326,1320624000"; 
   d="scan'208";a="9389557"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 16:19:05 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 16:19:05 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RZ3A8-0001n8-TN; Fri, 09 Dec 2011 16:19:04 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RZ3A8-00044T-Sd;
	Fri, 09 Dec 2011 16:19:04 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20194.13560.873396.700831@mariner.uk.xensource.com>
Date: Fri, 9 Dec 2011 16:19:04 +0000
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
In-Reply-To: <alpine.DEB.2.00.1112091504060.3517@kaball-desktop>
References: <1323108621-22654-1-git-send-email-ian.jackson@eu.citrix.com>
	<1323108621-22654-15-git-send-email-ian.jackson@eu.citrix.com>
	<alpine.DEB.2.00.1112091504060.3517@kaball-desktop>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 14/15] libxl: New API for providing OS
 events to libxl
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Firstly, Stefano, please trim your quotes.  You don't need to quote
the whole zillion-line patch.  Just quote the bits that are relevant.
Otherwise people may miss your comments as they page through trying to
find them.


Stefano Stabellini writes ("Re: [Xen-devel] [PATCH 14/15] libxl: New API for providing OS events to libxl"):
> On Mon, 5 Dec 2011, Ian Jackson wrote:
> > +#define OSEVENT_HOOK_INTERN(defval, hookname, ...)                      \
> > +    (CTX->osevent_hooks                                                 \
> > +     ? (CTX->osevent_in_hook++,                                         \
> > +        CTX->osevent_hooks->hookname(CTX->osevent_user, __VA_ARGS__),   \
> > +        CTX->osevent_in_hook--)                                         \
> > +     : defval)
> > +
> > +#define OSEVENT_HOOK(hookname,...)                      \
> > +    OSEVENT_HOOK_INTERN(0, hookname, __VA_ARGS__)
> > +
> > +#define OSEVENT_HOOK_VOID(hookname,...)                 \
> > +    OSEVENT_HOOK_INTERN((void)0, hookname, __VA_ARGS__)
> 
> Is there any reasons why we cannot use static inline functions here?

Yes, I'm afraid so.  The types of the hooks vary, and even if it
weren't for that, C doesn't have Lisp's "apply".


> > +        for (i=CTX->watch_nslots; i<newarraysize; i++)
> 
> does not follow the CODING_STYLE, it should be
> 
>            for (i = CTX->watch_nslots; i < newarraysize; i++)

Fixed, thanks.


> > +            LIBXL_SLIST_INSERT_HEAD(&CTX->watch_freeslots,
> > +                                    &newarray[i], empty);
> > +        CTX->watch_slots = newarray;
> > +        CTX->watch_nslots = newarraysize;
> > +    }
> 
> would it make sense to move this code in its own allocate_watch_slots
> function?
> 
> > +int libxl_osevent_beforepoll(libxl_ctx *ctx, int *nfds_io,
> > +                             struct pollfd *fds, int *timeout_upd,
> > +                             struct timeval now);
> > +  /* The caller should provide beforepoll with some space for libxl's
> > +   * fds, and tell libxl how much space is available by setting *nfds_io.
... [ many lines of commentary ]
> > +   * libxl_osevent_beforepoll will only reduce the timeout, naturally.
> > +   */
> 
> so far we have always added the comment on a function above the
> declaration of the function; we should keep doing it for consistency

I disagree.  That comment style involves either:

 1. Repeating the declaration at the top of the comment (or worse,
    repeating the information in the declaration but in a different
    format, doxygen-style); or

 2. Writing a comment which contains almost entirely forward references

This is not too bad if the comment is a one-liner.  But with a big
comment like this, you end up with something like:

  /* The caller should provide beforepoll with some space for libxl's
   * fds, and tell libxl how much space is available by setting *nfds_io.
   * fds points to the start of this space (and fds may be a pointer into
   * a larger array, for example, if the application has some fds of
   * its own that it is interested in).
   *
   * On return *nfds_io will in any case have been updated by libxl
   * according to how many fds libxl wants to poll on.
   *
   * If the space was sufficient, libxl fills in fds[0..<new
   * *nfds_io>] suitably for poll(2), updates *timeout_upd if needed,
   * and returns ok.
   *
   * If space was insufficient, fds[0..<old *nfds_io>] is undefined on
   * return; *nfds_io on return will be greater than the value on
   * entry; *timeout_upd may or may not have been updated; and
   * libxl_osevent_beforepoll returns ERROR_BUFERFULL.  In this case
   * the application needs to make more space (enough space for
   * *nfds_io struct pollfd) and then call beforepoll again, before
   * entering poll(2).  Typically this will involve calling realloc.
   *
   * The application may call beforepoll with fds==NULL and
   * *nfds_io==0 in order to find out how much space is needed.
   *
   * *timeout_upd is as for poll(2): it's in milliseconds, and
   * negative values mean no timeout (infinity).
   * libxl_osevent_beforepoll will only reduce the timeout, naturally.
   */
  int libxl_osevent_beforepoll(libxl_ctx *ctx, int *nfds_io,
                               struct pollfd *fds, int *timeout_upd,
                               struct timeval now);

This is very disjointed if you try to read it.  You start with

  /* The caller should provide beforepoll with some space for libxl's
   * fds, and tell libxl how much space is available by setting *nfds_io.
   * fds points to the start of this space (and fds may be a pointer into
   * a larger array, for example, if the application has some fds of
   * its own that it is interested in).

and the natural reaction is "What caller?? What is this beforepoll and
*nfds_io of which you speak?? What on earth are we talking about??"

The alternative, repeating the declaration, violates the principle
that things should be said (and defined) in the code if that's
possible, rather than having the primary reference be a comment.  It
also violates the principle of trying to avoid putting the same
information in two places.

If you want consistency then we should change the coding style to put
comment about a function or object declaration after the prototype or
declaration.


> > +void libxl_osevent_afterpoll(libxl_ctx *ctx, int nfds, const struct pollfd *fds,
> > +                             struct timeval now);
> > +  /* nfds and fds[0..nfds] must be from the most recent call to
> > +   * _beforepoll, as modified by poll.
> > +   *
> > +   * This function actually performs all of the IO and other actions,
> > +   * and generates events (libxl_event), which are implied by either
> > +   * (a) the time of day or (b) both (i) the returned information from
> > +   * _beforepoll, and (ii) the results from poll specified in
> > +   * fds[0..nfds-1].  Generated events can then be retrieved by
> > +   * libxl_event_check.
> > +   */
> > +
> 
> I see that the implementation of libxl_event_check is actually missing
> from this patch.
> Is this patch supposed to compiled, even without the actual libxl_event
> generation? Or are the two patches have to be committed together?

libxl_event_check is not referred to by the code in this patch.  It is
introduced in 15/15.  The comment is indeed not 100% true in this
patch but it seemed better to provide here a comment explaining how
things are going to be rather than writing

   * This function performs all of the IO and other actions,
   * but this does not currently have any visible effect outside
   * libxl.

in this patch and removing it in the next one.

My series compiles, and indeed is supposed to work, after each patch.


> > +typedef struct libxl_osevent_hooks {
> > +  int (*fd_register)(void *uselibxl_event_check.r, int fd, void **for_app_registration_out,
> > +                     short events, void *for_libxl);
> > +  int (*fd_modify)(void *user, int fd, void **for_app_registration_update,
> > +                   short events);
> > +  void (*fd_deregister)(void *user, int fd, void *for_app_registration);
> > +  int (*timeout_register)(void *user, void **for_app_registration_out,
> > +                          struct timeval abs, void *for_libxl);
> > +  int (*timeout_modify)(void *user, void **for_app_registration_update,
> > +                         struct timeval abs);
> > +  void (*timeout_deregister)(void *user, void *for_app_registration_io);
> > +} libxl_osevent_hooks;
> > +
> > +void libxl_osevent_register_hooks(libxl_ctx *ctx,
> > +                                  const libxl_osevent_hooks *hooks,
> > +                                  void *user);
...
> while this description is very verbose, it doesn't contain informations
> on:
> 
> - what is void *user;

I would have thought this was obvious.  Every situation in C where a
function pointer is passed needs also to pass a void* (or the
equivalent) so that some context or dynamic information from the
original caller can be passed to the inner called function.  So user
is stored by libxl and passed to the hooks.

> - what is "const libxl_osevent_hooks *hooks", in particular the role of
>   each  of these function pointers and the description of their
>   arguments.

The role of these function pointers is this:

> > +  /* The application which calls register_fd_hooks promises to
> > +   * maintain a register of fds and timeouts that libxl is interested
> > +   * in, and make calls into libxl (libxl_osevent_occurred_*)
> > +   * when those fd events and timeouts occur.  This is more efficient
> > +   * than _beforepoll/_afterpoll if there are many fds (which can
> > +   * happen if the same libxl application is managing many domains).

Ie, this is how libxl tells the application what fds and timeouts
libxl is interested in.

> If I am a user of the library, how am I supposed to pass as user? and as
> hooks?
> I think these few lines should go first, then the description of the
> contract.

Did you spot this comment, earlier ?

> > + * There are two approaches available.  The first is appropriate for
> > + * simple programs handling reasonably small numbers of domains:
> > + *
...
> > + * The second approach uses libxl_osevent_register_hooks and is
> > + * suitable for programs which are already using a callback-based
> > + * event library.

libxl_osevent_hooks is for this second approach.  If you know what a
callback-based event library is - particularly if you actually have
one in front of you - all of this should be obvious.  If you don't
know what a callback-based event library is, then you don't have one
and you don't want to use this interface.

To help make it clear to you, here is an example of a callback-based
event library:

  http://www.chiark.greenend.org.uk/doc/liboop-doc/html/ref.html
  http://www.chiark.greenend.org.uk/doc/liboop-doc/html/

(Copy of the docs as installed on my colo as apparently the upstream
website has gone away.)


> > +#define LIBXL__EVENT_DISASTER(gc, msg, errnoval, type) \
> > +    libxl__event_disaster(gc, msg, errnoval, type, __FILE__, __LINE__, __func__)
> 
> any reason why this shouldn't be a static inline?

__FILE__, __LINE__, __func__


Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 16:20:26 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 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.xensource.com>)
	id 1RZ3Ay-0003pM-SY; Fri, 09 Dec 2011 16:19:56 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RZ3Ax-0003pH-GI
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 16:19:55 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1323447545!6601271!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI2MQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25998 invoked from network); 9 Dec 2011 16:19:05 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 16:19:05 -0000
X-IronPort-AV: E=Sophos;i="4.71,326,1320624000"; 
   d="scan'208";a="9389557"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 16:19:05 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 16:19:05 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RZ3A8-0001n8-TN; Fri, 09 Dec 2011 16:19:04 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RZ3A8-00044T-Sd;
	Fri, 09 Dec 2011 16:19:04 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20194.13560.873396.700831@mariner.uk.xensource.com>
Date: Fri, 9 Dec 2011 16:19:04 +0000
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
In-Reply-To: <alpine.DEB.2.00.1112091504060.3517@kaball-desktop>
References: <1323108621-22654-1-git-send-email-ian.jackson@eu.citrix.com>
	<1323108621-22654-15-git-send-email-ian.jackson@eu.citrix.com>
	<alpine.DEB.2.00.1112091504060.3517@kaball-desktop>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 14/15] libxl: New API for providing OS
 events to libxl
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Firstly, Stefano, please trim your quotes.  You don't need to quote
the whole zillion-line patch.  Just quote the bits that are relevant.
Otherwise people may miss your comments as they page through trying to
find them.


Stefano Stabellini writes ("Re: [Xen-devel] [PATCH 14/15] libxl: New API for providing OS events to libxl"):
> On Mon, 5 Dec 2011, Ian Jackson wrote:
> > +#define OSEVENT_HOOK_INTERN(defval, hookname, ...)                      \
> > +    (CTX->osevent_hooks                                                 \
> > +     ? (CTX->osevent_in_hook++,                                         \
> > +        CTX->osevent_hooks->hookname(CTX->osevent_user, __VA_ARGS__),   \
> > +        CTX->osevent_in_hook--)                                         \
> > +     : defval)
> > +
> > +#define OSEVENT_HOOK(hookname,...)                      \
> > +    OSEVENT_HOOK_INTERN(0, hookname, __VA_ARGS__)
> > +
> > +#define OSEVENT_HOOK_VOID(hookname,...)                 \
> > +    OSEVENT_HOOK_INTERN((void)0, hookname, __VA_ARGS__)
> 
> Is there any reasons why we cannot use static inline functions here?

Yes, I'm afraid so.  The types of the hooks vary, and even if it
weren't for that, C doesn't have Lisp's "apply".


> > +        for (i=CTX->watch_nslots; i<newarraysize; i++)
> 
> does not follow the CODING_STYLE, it should be
> 
>            for (i = CTX->watch_nslots; i < newarraysize; i++)

Fixed, thanks.


> > +            LIBXL_SLIST_INSERT_HEAD(&CTX->watch_freeslots,
> > +                                    &newarray[i], empty);
> > +        CTX->watch_slots = newarray;
> > +        CTX->watch_nslots = newarraysize;
> > +    }
> 
> would it make sense to move this code in its own allocate_watch_slots
> function?
> 
> > +int libxl_osevent_beforepoll(libxl_ctx *ctx, int *nfds_io,
> > +                             struct pollfd *fds, int *timeout_upd,
> > +                             struct timeval now);
> > +  /* The caller should provide beforepoll with some space for libxl's
> > +   * fds, and tell libxl how much space is available by setting *nfds_io.
... [ many lines of commentary ]
> > +   * libxl_osevent_beforepoll will only reduce the timeout, naturally.
> > +   */
> 
> so far we have always added the comment on a function above the
> declaration of the function; we should keep doing it for consistency

I disagree.  That comment style involves either:

 1. Repeating the declaration at the top of the comment (or worse,
    repeating the information in the declaration but in a different
    format, doxygen-style); or

 2. Writing a comment which contains almost entirely forward references

This is not too bad if the comment is a one-liner.  But with a big
comment like this, you end up with something like:

  /* The caller should provide beforepoll with some space for libxl's
   * fds, and tell libxl how much space is available by setting *nfds_io.
   * fds points to the start of this space (and fds may be a pointer into
   * a larger array, for example, if the application has some fds of
   * its own that it is interested in).
   *
   * On return *nfds_io will in any case have been updated by libxl
   * according to how many fds libxl wants to poll on.
   *
   * If the space was sufficient, libxl fills in fds[0..<new
   * *nfds_io>] suitably for poll(2), updates *timeout_upd if needed,
   * and returns ok.
   *
   * If space was insufficient, fds[0..<old *nfds_io>] is undefined on
   * return; *nfds_io on return will be greater than the value on
   * entry; *timeout_upd may or may not have been updated; and
   * libxl_osevent_beforepoll returns ERROR_BUFERFULL.  In this case
   * the application needs to make more space (enough space for
   * *nfds_io struct pollfd) and then call beforepoll again, before
   * entering poll(2).  Typically this will involve calling realloc.
   *
   * The application may call beforepoll with fds==NULL and
   * *nfds_io==0 in order to find out how much space is needed.
   *
   * *timeout_upd is as for poll(2): it's in milliseconds, and
   * negative values mean no timeout (infinity).
   * libxl_osevent_beforepoll will only reduce the timeout, naturally.
   */
  int libxl_osevent_beforepoll(libxl_ctx *ctx, int *nfds_io,
                               struct pollfd *fds, int *timeout_upd,
                               struct timeval now);

This is very disjointed if you try to read it.  You start with

  /* The caller should provide beforepoll with some space for libxl's
   * fds, and tell libxl how much space is available by setting *nfds_io.
   * fds points to the start of this space (and fds may be a pointer into
   * a larger array, for example, if the application has some fds of
   * its own that it is interested in).

and the natural reaction is "What caller?? What is this beforepoll and
*nfds_io of which you speak?? What on earth are we talking about??"

The alternative, repeating the declaration, violates the principle
that things should be said (and defined) in the code if that's
possible, rather than having the primary reference be a comment.  It
also violates the principle of trying to avoid putting the same
information in two places.

If you want consistency then we should change the coding style to put
comment about a function or object declaration after the prototype or
declaration.


> > +void libxl_osevent_afterpoll(libxl_ctx *ctx, int nfds, const struct pollfd *fds,
> > +                             struct timeval now);
> > +  /* nfds and fds[0..nfds] must be from the most recent call to
> > +   * _beforepoll, as modified by poll.
> > +   *
> > +   * This function actually performs all of the IO and other actions,
> > +   * and generates events (libxl_event), which are implied by either
> > +   * (a) the time of day or (b) both (i) the returned information from
> > +   * _beforepoll, and (ii) the results from poll specified in
> > +   * fds[0..nfds-1].  Generated events can then be retrieved by
> > +   * libxl_event_check.
> > +   */
> > +
> 
> I see that the implementation of libxl_event_check is actually missing
> from this patch.
> Is this patch supposed to compiled, even without the actual libxl_event
> generation? Or are the two patches have to be committed together?

libxl_event_check is not referred to by the code in this patch.  It is
introduced in 15/15.  The comment is indeed not 100% true in this
patch but it seemed better to provide here a comment explaining how
things are going to be rather than writing

   * This function performs all of the IO and other actions,
   * but this does not currently have any visible effect outside
   * libxl.

in this patch and removing it in the next one.

My series compiles, and indeed is supposed to work, after each patch.


> > +typedef struct libxl_osevent_hooks {
> > +  int (*fd_register)(void *uselibxl_event_check.r, int fd, void **for_app_registration_out,
> > +                     short events, void *for_libxl);
> > +  int (*fd_modify)(void *user, int fd, void **for_app_registration_update,
> > +                   short events);
> > +  void (*fd_deregister)(void *user, int fd, void *for_app_registration);
> > +  int (*timeout_register)(void *user, void **for_app_registration_out,
> > +                          struct timeval abs, void *for_libxl);
> > +  int (*timeout_modify)(void *user, void **for_app_registration_update,
> > +                         struct timeval abs);
> > +  void (*timeout_deregister)(void *user, void *for_app_registration_io);
> > +} libxl_osevent_hooks;
> > +
> > +void libxl_osevent_register_hooks(libxl_ctx *ctx,
> > +                                  const libxl_osevent_hooks *hooks,
> > +                                  void *user);
...
> while this description is very verbose, it doesn't contain informations
> on:
> 
> - what is void *user;

I would have thought this was obvious.  Every situation in C where a
function pointer is passed needs also to pass a void* (or the
equivalent) so that some context or dynamic information from the
original caller can be passed to the inner called function.  So user
is stored by libxl and passed to the hooks.

> - what is "const libxl_osevent_hooks *hooks", in particular the role of
>   each  of these function pointers and the description of their
>   arguments.

The role of these function pointers is this:

> > +  /* The application which calls register_fd_hooks promises to
> > +   * maintain a register of fds and timeouts that libxl is interested
> > +   * in, and make calls into libxl (libxl_osevent_occurred_*)
> > +   * when those fd events and timeouts occur.  This is more efficient
> > +   * than _beforepoll/_afterpoll if there are many fds (which can
> > +   * happen if the same libxl application is managing many domains).

Ie, this is how libxl tells the application what fds and timeouts
libxl is interested in.

> If I am a user of the library, how am I supposed to pass as user? and as
> hooks?
> I think these few lines should go first, then the description of the
> contract.

Did you spot this comment, earlier ?

> > + * There are two approaches available.  The first is appropriate for
> > + * simple programs handling reasonably small numbers of domains:
> > + *
...
> > + * The second approach uses libxl_osevent_register_hooks and is
> > + * suitable for programs which are already using a callback-based
> > + * event library.

libxl_osevent_hooks is for this second approach.  If you know what a
callback-based event library is - particularly if you actually have
one in front of you - all of this should be obvious.  If you don't
know what a callback-based event library is, then you don't have one
and you don't want to use this interface.

To help make it clear to you, here is an example of a callback-based
event library:

  http://www.chiark.greenend.org.uk/doc/liboop-doc/html/ref.html
  http://www.chiark.greenend.org.uk/doc/liboop-doc/html/

(Copy of the docs as installed on my colo as apparently the upstream
website has gone away.)


> > +#define LIBXL__EVENT_DISASTER(gc, msg, errnoval, type) \
> > +    libxl__event_disaster(gc, msg, errnoval, type, __FILE__, __LINE__, __func__)
> 
> any reason why this shouldn't be a static inline?

__FILE__, __LINE__, __func__


Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 16:28:29 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 16:28:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZ3Ir-0003zn-Rs; Fri, 09 Dec 2011 16:28:05 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RZ3Iq-0003zi-R9
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 16:28:05 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1323447993!56682032!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI2MQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20673 invoked from network); 9 Dec 2011 16:26:33 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 16:26:33 -0000
X-IronPort-AV: E=Sophos;i="4.71,326,1320624000"; 
   d="scan'208";a="9389673"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 16:27:20 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 9 Dec 2011
	16:27:20 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Fri, 9 Dec 2011 16:27:20 +0000
In-Reply-To: <alpine.DEB.2.00.1112091504060.3517@kaball-desktop>
References: <1323108621-22654-1-git-send-email-ian.jackson@eu.citrix.com>
	<1323108621-22654-15-git-send-email-ian.jackson@eu.citrix.com>
	<alpine.DEB.2.00.1112091504060.3517@kaball-desktop>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323448040.20077.79.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 14/15] libxl: New API for providing OS
 events to libxl
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2011-12-09 at 15:44 +0000, Stefano Stabellini wrote:
[...]
> >  tools/libxl/Makefile         |    2 +-
> >  tools/libxl/libxl.c          |   25 ++
> >  tools/libxl/libxl.h          |    6 +
> >  tools/libxl/libxl_event.c    |  711 ++++++++++++++++++++++++++++++++++++++++++
> >  tools/libxl/libxl_event.h    |  199 ++++++++++++
> >  tools/libxl/libxl_internal.h |  216 +++++++++++++-

Please do trim the thousand lines of patch which you aren't commenting
on. Just including the hunk or function you are commenting on is
sufficient for context and snipping appropriately makes makes it far
easier to find the wheat in the chafe.

(this applies to everyone, this is just the latest one to annoy me ;-))

Ian.

[...snip...]


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 16:28:29 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 16:28:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZ3Ir-0003zn-Rs; Fri, 09 Dec 2011 16:28:05 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RZ3Iq-0003zi-R9
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 16:28:05 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1323447993!56682032!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI2MQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20673 invoked from network); 9 Dec 2011 16:26:33 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 16:26:33 -0000
X-IronPort-AV: E=Sophos;i="4.71,326,1320624000"; 
   d="scan'208";a="9389673"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 16:27:20 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 9 Dec 2011
	16:27:20 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Fri, 9 Dec 2011 16:27:20 +0000
In-Reply-To: <alpine.DEB.2.00.1112091504060.3517@kaball-desktop>
References: <1323108621-22654-1-git-send-email-ian.jackson@eu.citrix.com>
	<1323108621-22654-15-git-send-email-ian.jackson@eu.citrix.com>
	<alpine.DEB.2.00.1112091504060.3517@kaball-desktop>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323448040.20077.79.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 14/15] libxl: New API for providing OS
 events to libxl
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2011-12-09 at 15:44 +0000, Stefano Stabellini wrote:
[...]
> >  tools/libxl/Makefile         |    2 +-
> >  tools/libxl/libxl.c          |   25 ++
> >  tools/libxl/libxl.h          |    6 +
> >  tools/libxl/libxl_event.c    |  711 ++++++++++++++++++++++++++++++++++++++++++
> >  tools/libxl/libxl_event.h    |  199 ++++++++++++
> >  tools/libxl/libxl_internal.h |  216 +++++++++++++-

Please do trim the thousand lines of patch which you aren't commenting
on. Just including the hunk or function you are commenting on is
sufficient for context and snipping appropriately makes makes it far
easier to find the wheat in the chafe.

(this applies to everyone, this is just the latest one to annoy me ;-))

Ian.

[...snip...]


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 16:30:22 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 16:30:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZ3Kh-00044U-Ci; Fri, 09 Dec 2011 16:29:59 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RZ3Kf-000449-PS
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 16:29:58 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1323448148!6589068!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI2MQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 927 invoked from network); 9 Dec 2011 16:29:08 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 16:29:08 -0000
X-IronPort-AV: E=Sophos;i="4.71,326,1320624000"; 
   d="scan'208";a="9389703"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 16:29:07 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 16:29:08 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RZ3Jr-0001qV-Ks;
	Fri, 09 Dec 2011 16:29:07 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RZ3Jr-0003dm-KO;
	Fri, 09 Dec 2011 16:29:07 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10465-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 9 Dec 2011 16:29:07 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing test] 10465: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10465 xen-4.1-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10465/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-i386-i386-xl-winxpsp3    7 windows-install              fail   never pass
 test-amd64-amd64-xl-win7-amd64  7 windows-install              fail never pass
 test-amd64-i386-xend-winxpsp3  7 windows-install              fail  never pass
 test-amd64-i386-xl-win7-amd64  7 windows-install              fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install          fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  1c89f7d29fbb
baseline version:
 xen                  d9f8316a8291

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-4.1-testing
+ revision=1c89f7d29fbb
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-4.1-testing 1c89f7d29fbb
+ branch=xen-4.1-testing
+ revision=1c89f7d29fbb
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ : xen@xenbits.xensource.com
+ : xen@xenbits.xensource.com:git/linux-pvops
+ : master
+ : tested/2.6.39.x
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-4.1-testing.hg
+ hg push -r 1c89f7d29fbb ssh://xen@xenbits.xensource.com/HG/xen-4.1-testing.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-4.1-testing.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 2 changesets with 2 changes to 1 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 16:30:22 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 16:30:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZ3Kh-00044U-Ci; Fri, 09 Dec 2011 16:29:59 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RZ3Kf-000449-PS
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 16:29:58 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1323448148!6589068!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI2MQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 927 invoked from network); 9 Dec 2011 16:29:08 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 16:29:08 -0000
X-IronPort-AV: E=Sophos;i="4.71,326,1320624000"; 
   d="scan'208";a="9389703"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 16:29:07 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 16:29:08 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RZ3Jr-0001qV-Ks;
	Fri, 09 Dec 2011 16:29:07 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RZ3Jr-0003dm-KO;
	Fri, 09 Dec 2011 16:29:07 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10465-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 9 Dec 2011 16:29:07 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing test] 10465: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10465 xen-4.1-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10465/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-i386-i386-xl-winxpsp3    7 windows-install              fail   never pass
 test-amd64-amd64-xl-win7-amd64  7 windows-install              fail never pass
 test-amd64-i386-xend-winxpsp3  7 windows-install              fail  never pass
 test-amd64-i386-xl-win7-amd64  7 windows-install              fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install          fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  1c89f7d29fbb
baseline version:
 xen                  d9f8316a8291

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-4.1-testing
+ revision=1c89f7d29fbb
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-4.1-testing 1c89f7d29fbb
+ branch=xen-4.1-testing
+ revision=1c89f7d29fbb
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ : xen@xenbits.xensource.com
+ : xen@xenbits.xensource.com:git/linux-pvops
+ : master
+ : tested/2.6.39.x
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-4.1-testing.hg
+ hg push -r 1c89f7d29fbb ssh://xen@xenbits.xensource.com/HG/xen-4.1-testing.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-4.1-testing.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 2 changesets with 2 changes to 1 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 16:38:33 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 16:38:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZ3Sk-0004gF-Ke; Fri, 09 Dec 2011 16:38:18 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RZ3Sj-0004ff-1K
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 16:38:17 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1323448644!6843090!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDQ0MTg=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20518 invoked from network); 9 Dec 2011 16:37:27 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 16:37:27 -0000
X-IronPort-AV: E=Sophos;i="4.71,326,1320642000"; d="scan'208";a="19817753"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 11:37:27 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 11:37:27 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pB9GbLib009318;	Fri, 9 Dec 2011 08:37:25 -0800
MIME-Version: 1.0
X-Mercurial-Node: 18c0807a0504791bcb6e083866def9c4862a119a
Message-ID: <18c0807a0504791bcb6e.1323448642@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1323448640@cosworth.uk.xensource.com>
References: <patchbomb.1323448640@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 9 Dec 2011 16:37:22 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com, Olaf Hering <olaf@aepfle.de>,
	Vincent Hanquez <Vincent.Hanquez@eu.citrix.com>,
	Jonathan Ludlam <Jonathan.Ludlam@eu.citrix.com>, konrad.wilk@oracle.com
Subject: [Xen-devel] [PATCH 2 of 4] oxenstored: log Errors and Warnings by
	default
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1323447576 0
# Node ID 18c0807a0504791bcb6e083866def9c4862a119a
# Parent  beaf8eb93c36062b395bab3a30e3cf9d1f335a73
oxenstored: log Errors and Warnings by default.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r beaf8eb93c36 -r 18c0807a0504 tools/ocaml/xenstored/logging.ml
--- a/tools/ocaml/xenstored/logging.ml	Fri Dec 09 16:19:36 2011 +0000
+++ b/tools/ocaml/xenstored/logging.ml	Fri Dec 09 16:19:36 2011 +0000
@@ -105,7 +105,7 @@ let string_of_date () =
 		(int_of_float (1000.0 *. msec))
 
 let xenstored_log_file = ref "/var/log/xenstored.log"
-let xenstored_log_level = ref Null
+let xenstored_log_level = ref Warn
 let xenstored_log_nb_files = ref 10
 let xenstored_log_nb_lines = ref 13215
 let xenstored_log_nb_chars = ref (-1)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 16:38:33 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 16:38:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZ3Sk-0004gF-Ke; Fri, 09 Dec 2011 16:38:18 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RZ3Sj-0004ff-1K
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 16:38:17 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1323448644!6843090!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDQ0MTg=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20518 invoked from network); 9 Dec 2011 16:37:27 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 16:37:27 -0000
X-IronPort-AV: E=Sophos;i="4.71,326,1320642000"; d="scan'208";a="19817753"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 11:37:27 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 11:37:27 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pB9GbLib009318;	Fri, 9 Dec 2011 08:37:25 -0800
MIME-Version: 1.0
X-Mercurial-Node: 18c0807a0504791bcb6e083866def9c4862a119a
Message-ID: <18c0807a0504791bcb6e.1323448642@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1323448640@cosworth.uk.xensource.com>
References: <patchbomb.1323448640@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 9 Dec 2011 16:37:22 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com, Olaf Hering <olaf@aepfle.de>,
	Vincent Hanquez <Vincent.Hanquez@eu.citrix.com>,
	Jonathan Ludlam <Jonathan.Ludlam@eu.citrix.com>, konrad.wilk@oracle.com
Subject: [Xen-devel] [PATCH 2 of 4] oxenstored: log Errors and Warnings by
	default
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1323447576 0
# Node ID 18c0807a0504791bcb6e083866def9c4862a119a
# Parent  beaf8eb93c36062b395bab3a30e3cf9d1f335a73
oxenstored: log Errors and Warnings by default.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r beaf8eb93c36 -r 18c0807a0504 tools/ocaml/xenstored/logging.ml
--- a/tools/ocaml/xenstored/logging.ml	Fri Dec 09 16:19:36 2011 +0000
+++ b/tools/ocaml/xenstored/logging.ml	Fri Dec 09 16:19:36 2011 +0000
@@ -105,7 +105,7 @@ let string_of_date () =
 		(int_of_float (1000.0 *. msec))
 
 let xenstored_log_file = ref "/var/log/xenstored.log"
-let xenstored_log_level = ref Null
+let xenstored_log_level = ref Warn
 let xenstored_log_nb_files = ref 10
 let xenstored_log_nb_lines = ref 13215
 let xenstored_log_nb_chars = ref (-1)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 16:38:35 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 16:38:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZ3Si-0004fy-7e; Fri, 09 Dec 2011 16:38:16 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RZ3Sh-0004fa-9r
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 16:38:15 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1323448644!6843090!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDQ0MTg=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20393 invoked from network); 9 Dec 2011 16:37:25 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 16:37:25 -0000
X-IronPort-AV: E=Sophos;i="4.71,326,1320642000"; d="scan'208";a="19817752"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 11:37:24 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 11:37:24 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pB9GbLiZ009318;	Fri, 9 Dec 2011 08:37:22 -0800
MIME-Version: 1.0
Message-ID: <patchbomb.1323448640@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 9 Dec 2011 16:37:20 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com, Olaf Hering <olaf@aepfle.de>,
	Vincent Hanquez <Vincent.Hanquez@eu.citrix.com>,
	Jonathan Ludlam <Jonathan.Ludlam@eu.citrix.com>, konrad.wilk@oracle.com
Subject: [Xen-devel] [PATCH 0 of 4] oxenstored fixes -- fixes recent pvops
	kernel hang
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Currently PVHVM Linux guests after ddacf5ef684a "xen/pv-on-hvm kexec:
add xs_reset_watches to shutdown watches from old kernel" hang when
run against oxenstored because it does not handle the unknown
XS_RESET_WATCHES operation and does not reply.

The symptom of this issue is a hang during boot at this point:
    cpu 1 spinlock event irq 70
    CPU 1 irqstacks, hard=dec94000 soft=dec96000
    Booting Node   0, Processors  #1
    smpboot cpu 1: start_ip = 99000
    Initializing CPU#1
    installing Xen timer for CPU 1
    Brought up 2 CPUs
    Total of 2 processors activated (9625.99 BogoMIPS).
    NET: Registered protocol family 16
    <HANG>

This series makes oxenstored handle unknown operations by returning an
error indicating that the operation is unknown. I have not actually
implemented support for XS_RESET_WATCHES.

Two other small fixlets are included.

Lastly I include a patch which I've been using for some time to enable
the use of oxenstored in preference to C xenstored when available.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 16:38:35 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 16:38:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZ3Si-0004fy-7e; Fri, 09 Dec 2011 16:38:16 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RZ3Sh-0004fa-9r
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 16:38:15 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1323448644!6843090!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDQ0MTg=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20393 invoked from network); 9 Dec 2011 16:37:25 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 16:37:25 -0000
X-IronPort-AV: E=Sophos;i="4.71,326,1320642000"; d="scan'208";a="19817752"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 11:37:24 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 11:37:24 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pB9GbLiZ009318;	Fri, 9 Dec 2011 08:37:22 -0800
MIME-Version: 1.0
Message-ID: <patchbomb.1323448640@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 9 Dec 2011 16:37:20 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com, Olaf Hering <olaf@aepfle.de>,
	Vincent Hanquez <Vincent.Hanquez@eu.citrix.com>,
	Jonathan Ludlam <Jonathan.Ludlam@eu.citrix.com>, konrad.wilk@oracle.com
Subject: [Xen-devel] [PATCH 0 of 4] oxenstored fixes -- fixes recent pvops
	kernel hang
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Currently PVHVM Linux guests after ddacf5ef684a "xen/pv-on-hvm kexec:
add xs_reset_watches to shutdown watches from old kernel" hang when
run against oxenstored because it does not handle the unknown
XS_RESET_WATCHES operation and does not reply.

The symptom of this issue is a hang during boot at this point:
    cpu 1 spinlock event irq 70
    CPU 1 irqstacks, hard=dec94000 soft=dec96000
    Booting Node   0, Processors  #1
    smpboot cpu 1: start_ip = 99000
    Initializing CPU#1
    installing Xen timer for CPU 1
    Brought up 2 CPUs
    Total of 2 processors activated (9625.99 BogoMIPS).
    NET: Registered protocol family 16
    <HANG>

This series makes oxenstored handle unknown operations by returning an
error indicating that the operation is unknown. I have not actually
implemented support for XS_RESET_WATCHES.

Two other small fixlets are included.

Lastly I include a patch which I've been using for some time to enable
the use of oxenstored in preference to C xenstored when available.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 16:38:36 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 16:38:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZ3Sn-0004h5-KY; Fri, 09 Dec 2011 16:38:21 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RZ3Sm-0004fr-Jp
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 16:38:20 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1323448649!6856863!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMTkxNzY=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7528 invoked from network); 9 Dec 2011 16:37:31 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 16:37:31 -0000
X-IronPort-AV: E=Sophos;i="4.71,326,1320642000"; d="scan'208";a="173580316"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 11:37:29 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 11:37:29 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pB9GbLid009318;	Fri, 9 Dec 2011 08:37:28 -0800
MIME-Version: 1.0
X-Mercurial-Node: 3b7ac401f144206c30440fbb41c74b13fa20b8cb
Message-ID: <3b7ac401f144206c3044.1323448644@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1323448640@cosworth.uk.xensource.com>
References: <patchbomb.1323448640@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 9 Dec 2011 16:37:24 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com, Olaf Hering <olaf@aepfle.de>,
	Vincent Hanquez <Vincent.Hanquez@eu.citrix.com>,
	Jonathan Ludlam <Jonathan.Ludlam@eu.citrix.com>, konrad.wilk@oracle.com
Subject: [Xen-devel] [PATCH 4 of 4] Linux/xencommons: Use oxenstored by
 default when available
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1323448636 0
# Node ID 3b7ac401f144206c30440fbb41c74b13fa20b8cb
# Parent  74f94e15bfe1dad412d0342aeabdbd895657f54f
Linux/xencommons: Use oxenstored by default when available

oxenstored is an ocaml implementation of the xenstore daemon. It is faster,
more scalable and more reliable than the C xenstored.

In particular the transaction model in oxenstored does not involve taking a
complete copy of the database and aborting on any (even non-conflicting) other
change.

There is a paper on the design and implementation of oxenstored at
http://gazagnaire.org/pub/GH09.pdf which includes a performance evaluation and
comparison with the C daemon etc.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 74f94e15bfe1 -r 3b7ac401f144 tools/hotplug/Linux/init.d/sysconfig.xencommons
--- a/tools/hotplug/Linux/init.d/sysconfig.xencommons	Fri Dec 09 16:35:56 2011 +0000
+++ b/tools/hotplug/Linux/init.d/sysconfig.xencommons	Fri Dec 09 16:37:16 2011 +0000
@@ -1,6 +1,9 @@
 # Log xenconsoled messages (cf xl dmesg)
 XENCONSOLED_TRACE=guest
 
+# Select xenstored implementation
+#XENSTORED=[oxenstored|xenstored]
+
 # Log xenstored messages
 #XENSTORED_TRACE=[yes|on|1]
 
diff -r 74f94e15bfe1 -r 3b7ac401f144 tools/hotplug/Linux/init.d/xencommons
--- a/tools/hotplug/Linux/init.d/xencommons	Fri Dec 09 16:35:56 2011 +0000
+++ b/tools/hotplug/Linux/init.d/xencommons	Fri Dec 09 16:37:16 2011 +0000
@@ -70,8 +70,19 @@ do_start () {
 		rm -f "$XENSTORED_ROOTDIR"/tdb* &>/dev/null
 		test -z "$XENSTORED_TRACE" || XENSTORED_ARGS=" -T /var/log/xen/xenstored-trace.log"
 
-		echo -n Starting xenstored...
-		xenstored --pid-file=/var/run/xenstored.pid $XENSTORED_ARGS
+		if [ -n "$XENSTORED" ] ; then
+		    echo -n Starting $XENSTORED...
+		    $XENSTORED --pid-file /var/run/xenstored.pid $XENSTORED_ARGS
+		elif [ -x /usr/sbin/oxenstored ] ; then
+		    echo -n Starting oxenstored...
+		    /usr/sbin/oxenstored --pid-file /var/run/xenstored.pid $XENSTORED_ARGS
+		elif [ -x /usr/sbin/xenstored ] ; then
+		    echo -n Starting C xenstored...
+		    /usr/sbin/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 ] && ! `xenstore-read -s / >/dev/null 2>&1` ; do

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 16:38:36 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 16:38:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZ3Sn-0004h5-KY; Fri, 09 Dec 2011 16:38:21 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RZ3Sm-0004fr-Jp
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 16:38:20 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1323448649!6856863!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMTkxNzY=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7528 invoked from network); 9 Dec 2011 16:37:31 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 16:37:31 -0000
X-IronPort-AV: E=Sophos;i="4.71,326,1320642000"; d="scan'208";a="173580316"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 11:37:29 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 11:37:29 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pB9GbLid009318;	Fri, 9 Dec 2011 08:37:28 -0800
MIME-Version: 1.0
X-Mercurial-Node: 3b7ac401f144206c30440fbb41c74b13fa20b8cb
Message-ID: <3b7ac401f144206c3044.1323448644@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1323448640@cosworth.uk.xensource.com>
References: <patchbomb.1323448640@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 9 Dec 2011 16:37:24 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com, Olaf Hering <olaf@aepfle.de>,
	Vincent Hanquez <Vincent.Hanquez@eu.citrix.com>,
	Jonathan Ludlam <Jonathan.Ludlam@eu.citrix.com>, konrad.wilk@oracle.com
Subject: [Xen-devel] [PATCH 4 of 4] Linux/xencommons: Use oxenstored by
 default when available
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1323448636 0
# Node ID 3b7ac401f144206c30440fbb41c74b13fa20b8cb
# Parent  74f94e15bfe1dad412d0342aeabdbd895657f54f
Linux/xencommons: Use oxenstored by default when available

oxenstored is an ocaml implementation of the xenstore daemon. It is faster,
more scalable and more reliable than the C xenstored.

In particular the transaction model in oxenstored does not involve taking a
complete copy of the database and aborting on any (even non-conflicting) other
change.

There is a paper on the design and implementation of oxenstored at
http://gazagnaire.org/pub/GH09.pdf which includes a performance evaluation and
comparison with the C daemon etc.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 74f94e15bfe1 -r 3b7ac401f144 tools/hotplug/Linux/init.d/sysconfig.xencommons
--- a/tools/hotplug/Linux/init.d/sysconfig.xencommons	Fri Dec 09 16:35:56 2011 +0000
+++ b/tools/hotplug/Linux/init.d/sysconfig.xencommons	Fri Dec 09 16:37:16 2011 +0000
@@ -1,6 +1,9 @@
 # Log xenconsoled messages (cf xl dmesg)
 XENCONSOLED_TRACE=guest
 
+# Select xenstored implementation
+#XENSTORED=[oxenstored|xenstored]
+
 # Log xenstored messages
 #XENSTORED_TRACE=[yes|on|1]
 
diff -r 74f94e15bfe1 -r 3b7ac401f144 tools/hotplug/Linux/init.d/xencommons
--- a/tools/hotplug/Linux/init.d/xencommons	Fri Dec 09 16:35:56 2011 +0000
+++ b/tools/hotplug/Linux/init.d/xencommons	Fri Dec 09 16:37:16 2011 +0000
@@ -70,8 +70,19 @@ do_start () {
 		rm -f "$XENSTORED_ROOTDIR"/tdb* &>/dev/null
 		test -z "$XENSTORED_TRACE" || XENSTORED_ARGS=" -T /var/log/xen/xenstored-trace.log"
 
-		echo -n Starting xenstored...
-		xenstored --pid-file=/var/run/xenstored.pid $XENSTORED_ARGS
+		if [ -n "$XENSTORED" ] ; then
+		    echo -n Starting $XENSTORED...
+		    $XENSTORED --pid-file /var/run/xenstored.pid $XENSTORED_ARGS
+		elif [ -x /usr/sbin/oxenstored ] ; then
+		    echo -n Starting oxenstored...
+		    /usr/sbin/oxenstored --pid-file /var/run/xenstored.pid $XENSTORED_ARGS
+		elif [ -x /usr/sbin/xenstored ] ; then
+		    echo -n Starting C xenstored...
+		    /usr/sbin/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 ] && ! `xenstore-read -s / >/dev/null 2>&1` ; do

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 16:38:36 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 16:38:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZ3Sn-0004gu-6e; Fri, 09 Dec 2011 16:38:21 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RZ3Sm-0004fo-2E
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 16:38:20 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1323448649!6856863!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMTkxNzY=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7519 invoked from network); 9 Dec 2011 16:37:30 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 16:37:30 -0000
X-IronPort-AV: E=Sophos;i="4.71,326,1320642000"; d="scan'208";a="173580314"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 11:37:28 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 11:37:28 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pB9GbLic009318;	Fri, 9 Dec 2011 08:37:27 -0800
MIME-Version: 1.0
X-Mercurial-Node: 74f94e15bfe1dad412d0342aeabdbd895657f54f
Message-ID: <74f94e15bfe1dad412d0.1323448643@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1323448640@cosworth.uk.xensource.com>
References: <patchbomb.1323448640@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 9 Dec 2011 16:37:23 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com, Olaf Hering <olaf@aepfle.de>,
	Vincent Hanquez <Vincent.Hanquez@eu.citrix.com>,
	Jonathan Ludlam <Jonathan.Ludlam@eu.citrix.com>, konrad.wilk@oracle.com
Subject: [Xen-devel] [PATCH 3 of 4] oxenstored: handle unknown operations by
 returning an error to the client
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1323448556 0
# Node ID 74f94e15bfe1dad412d0342aeabdbd895657f54f
# Parent  18c0807a0504791bcb6e083866def9c4862a119a
oxenstored: handle unknown operations by returning an error to the client

Previous an unknown operation would be decoded as a Not_found exception which
would bubble all the way up to the try ... with surrounding the call to
main_loop where it would be logged and ignored.

This would leave the guest hanging waiting for a response to the invalid
request.

Instead introduce a specific "Invalid" operation. Higher level functionality,
such as Process.process_packet, already handles operations which are not
understood with an error reply due to the final wildcard entry in
Process.function_of_type but explicitly handle Invalid this way to make it
clear what is going on.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 18c0807a0504 -r 74f94e15bfe1 tools/ocaml/libs/xb/op.ml
--- a/tools/ocaml/libs/xb/op.ml	Fri Dec 09 16:19:36 2011 +0000
+++ b/tools/ocaml/libs/xb/op.ml	Fri Dec 09 16:35:56 2011 +0000
@@ -19,8 +19,7 @@ type operation = Debug | Directory | Rea
                  Transaction_end | Introduce | Release |
                  Getdomainpath | Write | Mkdir | Rm |
                  Setperms | Watchevent | Error | Isintroduced |
-                 Resume | Set_target
-               | Restrict 
+                 Resume | Set_target | Restrict | Invalid
 
 let operation_c_mapping =
 	[| Debug; Directory; Read; Getperms;
@@ -41,7 +40,7 @@ let array_search el a =
 let of_cval i =
 	if i >= 0 && i < size
 	then operation_c_mapping.(i)
-	else raise Not_found
+	else Invalid
 
 let to_cval op =
 	array_search op operation_c_mapping
@@ -69,3 +68,4 @@ let to_string ty =
 	| Resume		-> "RESUME"
 	| Set_target		-> "SET_TARGET"
 	| Restrict		-> "RESTRICT"
+	| Invalid		-> "INVALID"
diff -r 18c0807a0504 -r 74f94e15bfe1 tools/ocaml/libs/xb/xb.mli
--- a/tools/ocaml/libs/xb/xb.mli	Fri Dec 09 16:19:36 2011 +0000
+++ b/tools/ocaml/libs/xb/xb.mli	Fri Dec 09 16:35:56 2011 +0000
@@ -23,6 +23,7 @@ module Op :
       | Resume
       | Set_target
       | Restrict
+      | Invalid (* Not a valid wire operation *)
     val operation_c_mapping : operation array
     val size : int
     val array_search : 'a -> 'a array -> int
diff -r 18c0807a0504 -r 74f94e15bfe1 tools/ocaml/xenstored/process.ml
--- a/tools/ocaml/xenstored/process.ml	Fri Dec 09 16:19:36 2011 +0000
+++ b/tools/ocaml/xenstored/process.ml	Fri Dec 09 16:35:56 2011 +0000
@@ -324,7 +324,8 @@ let function_of_type ty =
 	| Xenbus.Xb.Op.Resume            -> reply_ack do_resume
 	| Xenbus.Xb.Op.Set_target        -> reply_ack do_set_target
 	| Xenbus.Xb.Op.Restrict          -> reply_ack do_restrict
-	| _                       -> reply_ack do_error
+	| Xenbus.Xb.Op.Invalid           -> reply_ack do_error
+	| _                              -> reply_ack do_error
 
 let input_handle_error ~cons ~doms ~fct ~ty ~con ~t ~rid ~data =
 	let reply_error e =
diff -r 18c0807a0504 -r 74f94e15bfe1 tools/ocaml/xenstored/xenstored.ml
--- a/tools/ocaml/xenstored/xenstored.ml	Fri Dec 09 16:19:36 2011 +0000
+++ b/tools/ocaml/xenstored/xenstored.ml	Fri Dec 09 16:35:56 2011 +0000
@@ -43,9 +43,7 @@ let process_connection_fds store cons do
 			debug "closing socket connection"
 		in
 	let process_fdset_with fds fct =
-		List.iter (fun fd ->
-		           try try_fct fct (Connections.find cons fd)
-		           with Not_found -> ()) fds
+		List.iter (fun fd -> try_fct fct (Connections.find cons fd)) fds
 	in
 	process_fdset_with rset Process.do_input;
 	process_fdset_with wset Process.do_output

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 16:38:36 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 16:38:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZ3Sn-0004gu-6e; Fri, 09 Dec 2011 16:38:21 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RZ3Sm-0004fo-2E
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 16:38:20 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1323448649!6856863!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMTkxNzY=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7519 invoked from network); 9 Dec 2011 16:37:30 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 16:37:30 -0000
X-IronPort-AV: E=Sophos;i="4.71,326,1320642000"; d="scan'208";a="173580314"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 11:37:28 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 11:37:28 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pB9GbLic009318;	Fri, 9 Dec 2011 08:37:27 -0800
MIME-Version: 1.0
X-Mercurial-Node: 74f94e15bfe1dad412d0342aeabdbd895657f54f
Message-ID: <74f94e15bfe1dad412d0.1323448643@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1323448640@cosworth.uk.xensource.com>
References: <patchbomb.1323448640@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 9 Dec 2011 16:37:23 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com, Olaf Hering <olaf@aepfle.de>,
	Vincent Hanquez <Vincent.Hanquez@eu.citrix.com>,
	Jonathan Ludlam <Jonathan.Ludlam@eu.citrix.com>, konrad.wilk@oracle.com
Subject: [Xen-devel] [PATCH 3 of 4] oxenstored: handle unknown operations by
 returning an error to the client
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1323448556 0
# Node ID 74f94e15bfe1dad412d0342aeabdbd895657f54f
# Parent  18c0807a0504791bcb6e083866def9c4862a119a
oxenstored: handle unknown operations by returning an error to the client

Previous an unknown operation would be decoded as a Not_found exception which
would bubble all the way up to the try ... with surrounding the call to
main_loop where it would be logged and ignored.

This would leave the guest hanging waiting for a response to the invalid
request.

Instead introduce a specific "Invalid" operation. Higher level functionality,
such as Process.process_packet, already handles operations which are not
understood with an error reply due to the final wildcard entry in
Process.function_of_type but explicitly handle Invalid this way to make it
clear what is going on.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 18c0807a0504 -r 74f94e15bfe1 tools/ocaml/libs/xb/op.ml
--- a/tools/ocaml/libs/xb/op.ml	Fri Dec 09 16:19:36 2011 +0000
+++ b/tools/ocaml/libs/xb/op.ml	Fri Dec 09 16:35:56 2011 +0000
@@ -19,8 +19,7 @@ type operation = Debug | Directory | Rea
                  Transaction_end | Introduce | Release |
                  Getdomainpath | Write | Mkdir | Rm |
                  Setperms | Watchevent | Error | Isintroduced |
-                 Resume | Set_target
-               | Restrict 
+                 Resume | Set_target | Restrict | Invalid
 
 let operation_c_mapping =
 	[| Debug; Directory; Read; Getperms;
@@ -41,7 +40,7 @@ let array_search el a =
 let of_cval i =
 	if i >= 0 && i < size
 	then operation_c_mapping.(i)
-	else raise Not_found
+	else Invalid
 
 let to_cval op =
 	array_search op operation_c_mapping
@@ -69,3 +68,4 @@ let to_string ty =
 	| Resume		-> "RESUME"
 	| Set_target		-> "SET_TARGET"
 	| Restrict		-> "RESTRICT"
+	| Invalid		-> "INVALID"
diff -r 18c0807a0504 -r 74f94e15bfe1 tools/ocaml/libs/xb/xb.mli
--- a/tools/ocaml/libs/xb/xb.mli	Fri Dec 09 16:19:36 2011 +0000
+++ b/tools/ocaml/libs/xb/xb.mli	Fri Dec 09 16:35:56 2011 +0000
@@ -23,6 +23,7 @@ module Op :
       | Resume
       | Set_target
       | Restrict
+      | Invalid (* Not a valid wire operation *)
     val operation_c_mapping : operation array
     val size : int
     val array_search : 'a -> 'a array -> int
diff -r 18c0807a0504 -r 74f94e15bfe1 tools/ocaml/xenstored/process.ml
--- a/tools/ocaml/xenstored/process.ml	Fri Dec 09 16:19:36 2011 +0000
+++ b/tools/ocaml/xenstored/process.ml	Fri Dec 09 16:35:56 2011 +0000
@@ -324,7 +324,8 @@ let function_of_type ty =
 	| Xenbus.Xb.Op.Resume            -> reply_ack do_resume
 	| Xenbus.Xb.Op.Set_target        -> reply_ack do_set_target
 	| Xenbus.Xb.Op.Restrict          -> reply_ack do_restrict
-	| _                       -> reply_ack do_error
+	| Xenbus.Xb.Op.Invalid           -> reply_ack do_error
+	| _                              -> reply_ack do_error
 
 let input_handle_error ~cons ~doms ~fct ~ty ~con ~t ~rid ~data =
 	let reply_error e =
diff -r 18c0807a0504 -r 74f94e15bfe1 tools/ocaml/xenstored/xenstored.ml
--- a/tools/ocaml/xenstored/xenstored.ml	Fri Dec 09 16:19:36 2011 +0000
+++ b/tools/ocaml/xenstored/xenstored.ml	Fri Dec 09 16:35:56 2011 +0000
@@ -43,9 +43,7 @@ let process_connection_fds store cons do
 			debug "closing socket connection"
 		in
 	let process_fdset_with fds fct =
-		List.iter (fun fd ->
-		           try try_fct fct (Connections.find cons fd)
-		           with Not_found -> ()) fds
+		List.iter (fun fd -> try_fct fct (Connections.find cons fd)) fds
 	in
 	process_fdset_with rset Process.do_input;
 	process_fdset_with wset Process.do_output

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 16:39:29 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 16:39:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZ3Tm-0004uu-3n; Fri, 09 Dec 2011 16:39:22 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RZ3Tk-0004tZ-Ox
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 16:39:20 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1323448709!7593412!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMTkxNzY=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2318 invoked from network); 9 Dec 2011 16:38:31 -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;
	9 Dec 2011 16:38:31 -0000
X-IronPort-AV: E=Sophos;i="4.71,326,1320642000"; d="scan'208";a="173580303"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 11:37:25 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 11:37:25 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pB9GbLia009318;	Fri, 9 Dec 2011 08:37:24 -0800
MIME-Version: 1.0
X-Mercurial-Node: beaf8eb93c36062b395bab3a30e3cf9d1f335a73
Message-ID: <beaf8eb93c36062b395b.1323448641@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1323448640@cosworth.uk.xensource.com>
References: <patchbomb.1323448640@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 9 Dec 2011 16:37:21 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com, Olaf Hering <olaf@aepfle.de>,
	Vincent Hanquez <Vincent.Hanquez@eu.citrix.com>,
	Jonathan Ludlam <Jonathan.Ludlam@eu.citrix.com>, konrad.wilk@oracle.com
Subject: [Xen-devel] [PATCH 1 of 4] oxenstored: Remove support for PQ
	defined operations
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1323447576 0
# Node ID beaf8eb93c36062b395bab3a30e3cf9d1f335a73
# Parent  3429972bbc6a1b998b13ba38f449fbb8251b3717
oxenstored: Remove support for PQ defined operations.

It is unused.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 3429972bbc6a -r beaf8eb93c36 tools/ocaml/libs/xb/op.ml
--- a/tools/ocaml/libs/xb/op.ml	Fri Dec 09 16:19:36 2011 +0000
+++ b/tools/ocaml/libs/xb/op.ml	Fri Dec 09 16:19:36 2011 +0000
@@ -22,9 +22,6 @@ type operation = Debug | Directory | Rea
                  Resume | Set_target
                | Restrict 
 
-(* There are two sets of XB operations: the one coming from open-source and *)
-(* the one coming from our private patch queue. These operations            *)
-(* in two differents arrays for make easier the forward compatibility       *)
 let operation_c_mapping =
 	[| Debug; Directory; Read; Getperms;
            Watch; Unwatch; Transaction_start;
@@ -34,12 +31,6 @@ let operation_c_mapping =
            Resume; Set_target; Restrict |]
 let size = Array.length operation_c_mapping
 
-(* [offset_pq] has to be the same as in <xen/io/xs_wire.h> *)
-let offset_pq = size
-let operation_c_mapping_pq =
-	[| |]
-let size_pq = Array.length operation_c_mapping_pq
-
 let array_search el a =
 	let len = Array.length a in
 	let rec search i =
@@ -50,14 +41,10 @@ let array_search el a =
 let of_cval i =
 	if i >= 0 && i < size
 	then operation_c_mapping.(i)
-	else if i >= offset_pq && i < offset_pq + size_pq
-	then operation_c_mapping_pq.(i-offset_pq)
 	else raise Not_found
 
 let to_cval op =
-	try
 	array_search op operation_c_mapping
-	with _ -> offset_pq + array_search op operation_c_mapping_pq
 
 let to_string ty =
 	match ty with
diff -r 3429972bbc6a -r beaf8eb93c36 tools/ocaml/libs/xb/xb.mli
--- a/tools/ocaml/libs/xb/xb.mli	Fri Dec 09 16:19:36 2011 +0000
+++ b/tools/ocaml/libs/xb/xb.mli	Fri Dec 09 16:19:36 2011 +0000
@@ -25,9 +25,6 @@ module Op :
       | Restrict
     val operation_c_mapping : operation array
     val size : int
-    val offset_pq : int
-    val operation_c_mapping_pq : 'a array
-    val size_pq : int
     val array_search : 'a -> 'a array -> int
     val of_cval : int -> operation
     val to_cval : operation -> int

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 16:39:29 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 16:39:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZ3Tm-0004uu-3n; Fri, 09 Dec 2011 16:39:22 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RZ3Tk-0004tZ-Ox
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 16:39:20 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1323448709!7593412!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMTkxNzY=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2318 invoked from network); 9 Dec 2011 16:38:31 -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;
	9 Dec 2011 16:38:31 -0000
X-IronPort-AV: E=Sophos;i="4.71,326,1320642000"; d="scan'208";a="173580303"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 11:37:25 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 11:37:25 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pB9GbLia009318;	Fri, 9 Dec 2011 08:37:24 -0800
MIME-Version: 1.0
X-Mercurial-Node: beaf8eb93c36062b395bab3a30e3cf9d1f335a73
Message-ID: <beaf8eb93c36062b395b.1323448641@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1323448640@cosworth.uk.xensource.com>
References: <patchbomb.1323448640@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 9 Dec 2011 16:37:21 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com, Olaf Hering <olaf@aepfle.de>,
	Vincent Hanquez <Vincent.Hanquez@eu.citrix.com>,
	Jonathan Ludlam <Jonathan.Ludlam@eu.citrix.com>, konrad.wilk@oracle.com
Subject: [Xen-devel] [PATCH 1 of 4] oxenstored: Remove support for PQ
	defined operations
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1323447576 0
# Node ID beaf8eb93c36062b395bab3a30e3cf9d1f335a73
# Parent  3429972bbc6a1b998b13ba38f449fbb8251b3717
oxenstored: Remove support for PQ defined operations.

It is unused.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 3429972bbc6a -r beaf8eb93c36 tools/ocaml/libs/xb/op.ml
--- a/tools/ocaml/libs/xb/op.ml	Fri Dec 09 16:19:36 2011 +0000
+++ b/tools/ocaml/libs/xb/op.ml	Fri Dec 09 16:19:36 2011 +0000
@@ -22,9 +22,6 @@ type operation = Debug | Directory | Rea
                  Resume | Set_target
                | Restrict 
 
-(* There are two sets of XB operations: the one coming from open-source and *)
-(* the one coming from our private patch queue. These operations            *)
-(* in two differents arrays for make easier the forward compatibility       *)
 let operation_c_mapping =
 	[| Debug; Directory; Read; Getperms;
            Watch; Unwatch; Transaction_start;
@@ -34,12 +31,6 @@ let operation_c_mapping =
            Resume; Set_target; Restrict |]
 let size = Array.length operation_c_mapping
 
-(* [offset_pq] has to be the same as in <xen/io/xs_wire.h> *)
-let offset_pq = size
-let operation_c_mapping_pq =
-	[| |]
-let size_pq = Array.length operation_c_mapping_pq
-
 let array_search el a =
 	let len = Array.length a in
 	let rec search i =
@@ -50,14 +41,10 @@ let array_search el a =
 let of_cval i =
 	if i >= 0 && i < size
 	then operation_c_mapping.(i)
-	else if i >= offset_pq && i < offset_pq + size_pq
-	then operation_c_mapping_pq.(i-offset_pq)
 	else raise Not_found
 
 let to_cval op =
-	try
 	array_search op operation_c_mapping
-	with _ -> offset_pq + array_search op operation_c_mapping_pq
 
 let to_string ty =
 	match ty with
diff -r 3429972bbc6a -r beaf8eb93c36 tools/ocaml/libs/xb/xb.mli
--- a/tools/ocaml/libs/xb/xb.mli	Fri Dec 09 16:19:36 2011 +0000
+++ b/tools/ocaml/libs/xb/xb.mli	Fri Dec 09 16:19:36 2011 +0000
@@ -25,9 +25,6 @@ module Op :
       | Restrict
     val operation_c_mapping : operation array
     val size : int
-    val offset_pq : int
-    val operation_c_mapping_pq : 'a array
-    val size_pq : int
     val array_search : 'a -> 'a array -> int
     val of_cval : int -> operation
     val to_cval : operation -> int

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 16:52:20 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 16: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.xensource.com>)
	id 1RZ3g3-0005cp-E0; Fri, 09 Dec 2011 16:52:03 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RZ3g1-0005cf-IZ
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 16:52:01 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1323449471!2043641!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI2MQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17653 invoked from network); 9 Dec 2011 16:51:11 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 16:51:11 -0000
X-IronPort-AV: E=Sophos;i="4.71,326,1320624000"; 
   d="scan'208";a="9390081"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 16:51:11 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 16:51:11 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RZ3fC-0001xq-Ur; Fri, 09 Dec 2011 16:51:10 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RZ3fC-0004KF-U7;
	Fri, 09 Dec 2011 16:51:10 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20194.15486.922005.205889@mariner.uk.xensource.com>
Date: Fri, 9 Dec 2011 16:51:10 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1323422186.20077.28.camel@zakaz.uk.xensource.com>
References: <1323108621-22654-1-git-send-email-ian.jackson@eu.citrix.com>
	<1323108621-22654-15-git-send-email-ian.jackson@eu.citrix.com>
	<1323279343.2969.44.camel@zakaz.uk.xensource.com>
	<20193.5581.714247.641528@mariner.uk.xensource.com>
	<1323422186.20077.28.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 14/15] libxl: New API for providing OS
 events to libxl
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("Re: [Xen-devel] [PATCH 14/15] libxl: New API for providing OS events to libxl"):
> On Thu, 2011-12-08 at 19:53 +0000, Ian Jackson wrote:
> > All the existing files in libxl/ mention this nonexistent file
> > LICENCE.  I think we should fix this in a separate patch.  I'd argue
> > that my copying of the existing text isn't making the situation worse.
> 
> Sure, I didn't mean to suggest you needed to fix this in this series, I
> just happened to observe it here.

Right.  Yes.

> > > > +int libxl__ev_fd_register(libxl__gc *gc, libxl__ev_fd *ev,
> > > > +                          libxl__ev_fd_callback *func,
> > > > +                          int fd, short events) {
> > > 
> > > Strictly speaking CODING_STYLE requires the { to be on the next line.
> > 
> > Oh, I probably have a lot of those.  Damn.
> 
> Yeah, I refrained from commenting every time ;-)

Fixed.

> > You mean "int xs_path_is_subpath_p(const char *parent, const char *child)" ?
...
> Wouldn't most users of libxenstore doing watches need something like
> this (and probably either open code it or erroneously omit it)?

Many.  If you are careful enough with your tokens you might not need
to.

> Regardless of where it goes moving that logic into a helper function
> will make it clearer what is going on, both by having a descriptive name
> and allowing the logic to be a bit more spaced out / commented, the last
> clause in particular is slightly subtle.

OK, I have split this out into a function in libxenstore (in a
separate patch):

  /* Returns true if child is either equal to parent, or a node underneath
   * parent; or false otherwise.  Done by string comparison, so relative and
   * absolute pathnames never in a parent/child relationship by this
   * definition.  Cannot fail.
   */
  bool xs_path_is_subpath(const char *parent, const char *child);

You're right, the resulting code is clearer I think.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 16:52:20 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 16: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.xensource.com>)
	id 1RZ3g3-0005cp-E0; Fri, 09 Dec 2011 16:52:03 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RZ3g1-0005cf-IZ
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 16:52:01 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1323449471!2043641!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI2MQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17653 invoked from network); 9 Dec 2011 16:51:11 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 16:51:11 -0000
X-IronPort-AV: E=Sophos;i="4.71,326,1320624000"; 
   d="scan'208";a="9390081"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 16:51:11 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 16:51:11 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RZ3fC-0001xq-Ur; Fri, 09 Dec 2011 16:51:10 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RZ3fC-0004KF-U7;
	Fri, 09 Dec 2011 16:51:10 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20194.15486.922005.205889@mariner.uk.xensource.com>
Date: Fri, 9 Dec 2011 16:51:10 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1323422186.20077.28.camel@zakaz.uk.xensource.com>
References: <1323108621-22654-1-git-send-email-ian.jackson@eu.citrix.com>
	<1323108621-22654-15-git-send-email-ian.jackson@eu.citrix.com>
	<1323279343.2969.44.camel@zakaz.uk.xensource.com>
	<20193.5581.714247.641528@mariner.uk.xensource.com>
	<1323422186.20077.28.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 14/15] libxl: New API for providing OS
 events to libxl
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("Re: [Xen-devel] [PATCH 14/15] libxl: New API for providing OS events to libxl"):
> On Thu, 2011-12-08 at 19:53 +0000, Ian Jackson wrote:
> > All the existing files in libxl/ mention this nonexistent file
> > LICENCE.  I think we should fix this in a separate patch.  I'd argue
> > that my copying of the existing text isn't making the situation worse.
> 
> Sure, I didn't mean to suggest you needed to fix this in this series, I
> just happened to observe it here.

Right.  Yes.

> > > > +int libxl__ev_fd_register(libxl__gc *gc, libxl__ev_fd *ev,
> > > > +                          libxl__ev_fd_callback *func,
> > > > +                          int fd, short events) {
> > > 
> > > Strictly speaking CODING_STYLE requires the { to be on the next line.
> > 
> > Oh, I probably have a lot of those.  Damn.
> 
> Yeah, I refrained from commenting every time ;-)

Fixed.

> > You mean "int xs_path_is_subpath_p(const char *parent, const char *child)" ?
...
> Wouldn't most users of libxenstore doing watches need something like
> this (and probably either open code it or erroneously omit it)?

Many.  If you are careful enough with your tokens you might not need
to.

> Regardless of where it goes moving that logic into a helper function
> will make it clearer what is going on, both by having a descriptive name
> and allowing the logic to be a bit more spaced out / commented, the last
> clause in particular is slightly subtle.

OK, I have split this out into a function in libxenstore (in a
separate patch):

  /* Returns true if child is either equal to parent, or a node underneath
   * parent; or false otherwise.  Done by string comparison, so relative and
   * absolute pathnames never in a parent/child relationship by this
   * definition.  Cannot fail.
   */
  bool xs_path_is_subpath(const char *parent, const char *child);

You're right, the resulting code is clearer I think.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 16:52:40 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 16:52:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZ3gO-0005eE-Ro; Fri, 09 Dec 2011 16:52:24 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RZ3gN-0005dY-Mt
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 16:52:24 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-13.tower-174.messagelabs.com!1323449493!4931192!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyODgwMTA=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyODgwMTA=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31897 invoked from network); 9 Dec 2011 16:51:34 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-13.tower-174.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 9 Dec 2011 16:51:34 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1323449493; l=380;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=e9sbSWBkgKHHjAB6S4p3OJ4UHGs=;
	b=rwdAlpNbWlBIrwwtXlC17BazpBXKYYr4+WTxImQxDOtCpv5B/aO6AGYYANUpYBSe9OS
	Y2/aNHLlusZ/CV6YD/43kYw7fZhZjJvkUypDImLbLFaS8XuHwpHRxBrxNZ7Kqv9BopdRo
	f+0zmxm/bYmA7wgDOPYxZ1wCSRIM+6I+W34=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lk3c7qEGZD
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-094-126.pools.arcor-ip.net [84.57.94.126])
	by smtp.strato.de (fruni mo12) (RZmta 26.10 AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id N05465nB9FJMGT ;
	Fri, 9 Dec 2011 17:51:12 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id D8ACD18637; Fri,  9 Dec 2011 17:51:11 +0100 (CET)
Date: Fri, 9 Dec 2011 17:51:11 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20111209165111.GA24038@aepfle.de>
References: <patchbomb.1323448640@cosworth.uk.xensource.com>
	<3b7ac401f144206c3044.1323448644@cosworth.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <3b7ac401f144206c3044.1323448644@cosworth.uk.xensource.com>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: ian.jackson@citrix.com, xen-devel@lists.xensource.com,
	Vincent Hanquez <Vincent.Hanquez@eu.citrix.com>,
	Jonathan Ludlam <Jonathan.Ludlam@eu.citrix.com>, konrad.wilk@oracle.com
Subject: Re: [Xen-devel] [PATCH 4 of 4] Linux/xencommons: Use oxenstored by
 default when available
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Dec 09, Ian Campbell wrote:

> # HG changeset patch
> # User Ian Campbell <ian.campbell@citrix.com>
> # Date 1323448636 0
> # Node ID 3b7ac401f144206c30440fbb41c74b13fa20b8cb
> # Parent  74f94e15bfe1dad412d0342aeabdbd895657f54f
> Linux/xencommons: Use oxenstored by default when available

Assuming this has been tested:

Acked-by: Olaf Hering <olaf@aepfle.de>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 16:52:40 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 16:52:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZ3gO-0005eE-Ro; Fri, 09 Dec 2011 16:52:24 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RZ3gN-0005dY-Mt
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 16:52:24 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-13.tower-174.messagelabs.com!1323449493!4931192!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyODgwMTA=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyODgwMTA=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31897 invoked from network); 9 Dec 2011 16:51:34 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-13.tower-174.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 9 Dec 2011 16:51:34 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1323449493; l=380;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=e9sbSWBkgKHHjAB6S4p3OJ4UHGs=;
	b=rwdAlpNbWlBIrwwtXlC17BazpBXKYYr4+WTxImQxDOtCpv5B/aO6AGYYANUpYBSe9OS
	Y2/aNHLlusZ/CV6YD/43kYw7fZhZjJvkUypDImLbLFaS8XuHwpHRxBrxNZ7Kqv9BopdRo
	f+0zmxm/bYmA7wgDOPYxZ1wCSRIM+6I+W34=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lk3c7qEGZD
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-094-126.pools.arcor-ip.net [84.57.94.126])
	by smtp.strato.de (fruni mo12) (RZmta 26.10 AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id N05465nB9FJMGT ;
	Fri, 9 Dec 2011 17:51:12 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id D8ACD18637; Fri,  9 Dec 2011 17:51:11 +0100 (CET)
Date: Fri, 9 Dec 2011 17:51:11 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20111209165111.GA24038@aepfle.de>
References: <patchbomb.1323448640@cosworth.uk.xensource.com>
	<3b7ac401f144206c3044.1323448644@cosworth.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <3b7ac401f144206c3044.1323448644@cosworth.uk.xensource.com>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: ian.jackson@citrix.com, xen-devel@lists.xensource.com,
	Vincent Hanquez <Vincent.Hanquez@eu.citrix.com>,
	Jonathan Ludlam <Jonathan.Ludlam@eu.citrix.com>, konrad.wilk@oracle.com
Subject: Re: [Xen-devel] [PATCH 4 of 4] Linux/xencommons: Use oxenstored by
 default when available
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Dec 09, Ian Campbell wrote:

> # HG changeset patch
> # User Ian Campbell <ian.campbell@citrix.com>
> # Date 1323448636 0
> # Node ID 3b7ac401f144206c30440fbb41c74b13fa20b8cb
> # Parent  74f94e15bfe1dad412d0342aeabdbd895657f54f
> Linux/xencommons: Use oxenstored by default when available

Assuming this has been tested:

Acked-by: Olaf Hering <olaf@aepfle.de>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 16:57:40 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 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.xensource.com>)
	id 1RZ3lF-0005vW-JZ; Fri, 09 Dec 2011 16:57:25 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RZ3lE-0005vJ-Ae
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 16:57:24 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1323449794!6824428!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI2MQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25894 invoked from network); 9 Dec 2011 16:56:35 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 16:56:35 -0000
X-IronPort-AV: E=Sophos;i="4.71,326,1320624000"; 
   d="scan'208";a="9390161"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 16:56:34 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 16:56:34 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RZ3kQ-0001zh-9a; Fri, 09 Dec 2011 16:56:34 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RZ3kQ-0004Kh-8r;
	Fri, 09 Dec 2011 16:56:34 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20194.15809.931214.529696@mariner.uk.xensource.com>
Date: Fri, 9 Dec 2011 16:56:33 +0000
To: Ian Campbell <ian.campbell@citrix.com>
In-Reply-To: <d50241faddf372f22626.1323432166@cosworth.uk.xensource.com>
References: <patchbomb.1323432164@cosworth.uk.xensource.com>
	<d50241faddf372f22626.1323432166@cosworth.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 2 of 2] mini-os: do not wait for pci backend
	in pcifront_scan
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("[PATCH 2 of 2] mini-os: do not wait for pci backend in pcifront_scan"):
> Even in the case where there are passthrough devices configured libxl creates
> the stubdom and waits for it to startup _before_ adding the backend. Since the
> stub domains main thread is blocked before it can write the "running" state to
> xenstore the toolstack eventually times out and kills everything.
> 
> There is already a separate pcifront thread which waits for the backend to
> appear and calls init_pcifront at the appropriate time should a backend ever
> appear.
> 
> Unfortunately I don't have any free test boxes with VT-d so I
> haven't been able to test the cases where PCI deivces are passed
> through but I obviously have tested that I can now start an HVM
> domain with stub qemu without PCI devices passed through which I
> couldn't do before so this is an improvement. This stuff is a bit
> like pushing the lump around the carpet :-/

Right.  The worry would be, surely, that this somehow breaks by
unpausing the guest before everything has been set up by the stubdom.

But I'm happy to ack this patch on the basis that it seemed to improve
things for you and should be harmless for the non-stubdom case.

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

(Not applying it yet as the patch floodgate is still closed pending a
test pass.)

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 16:57:40 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 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.xensource.com>)
	id 1RZ3lF-0005vW-JZ; Fri, 09 Dec 2011 16:57:25 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RZ3lE-0005vJ-Ae
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 16:57:24 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1323449794!6824428!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI2MQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25894 invoked from network); 9 Dec 2011 16:56:35 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 16:56:35 -0000
X-IronPort-AV: E=Sophos;i="4.71,326,1320624000"; 
   d="scan'208";a="9390161"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 16:56:34 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 16:56:34 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RZ3kQ-0001zh-9a; Fri, 09 Dec 2011 16:56:34 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RZ3kQ-0004Kh-8r;
	Fri, 09 Dec 2011 16:56:34 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20194.15809.931214.529696@mariner.uk.xensource.com>
Date: Fri, 9 Dec 2011 16:56:33 +0000
To: Ian Campbell <ian.campbell@citrix.com>
In-Reply-To: <d50241faddf372f22626.1323432166@cosworth.uk.xensource.com>
References: <patchbomb.1323432164@cosworth.uk.xensource.com>
	<d50241faddf372f22626.1323432166@cosworth.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 2 of 2] mini-os: do not wait for pci backend
	in pcifront_scan
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("[PATCH 2 of 2] mini-os: do not wait for pci backend in pcifront_scan"):
> Even in the case where there are passthrough devices configured libxl creates
> the stubdom and waits for it to startup _before_ adding the backend. Since the
> stub domains main thread is blocked before it can write the "running" state to
> xenstore the toolstack eventually times out and kills everything.
> 
> There is already a separate pcifront thread which waits for the backend to
> appear and calls init_pcifront at the appropriate time should a backend ever
> appear.
> 
> Unfortunately I don't have any free test boxes with VT-d so I
> haven't been able to test the cases where PCI deivces are passed
> through but I obviously have tested that I can now start an HVM
> domain with stub qemu without PCI devices passed through which I
> couldn't do before so this is an improvement. This stuff is a bit
> like pushing the lump around the carpet :-/

Right.  The worry would be, surely, that this somehow breaks by
unpausing the guest before everything has been set up by the stubdom.

But I'm happy to ack this patch on the basis that it seemed to improve
things for you and should be harmless for the non-stubdom case.

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

(Not applying it yet as the patch floodgate is still closed pending a
test pass.)

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 16:58:02 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 16:58:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZ3lc-0005xJ-1Q; Fri, 09 Dec 2011 16:57:48 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RZ3la-0005we-79
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 16:57:46 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1323449816!6783108!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI2MQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11063 invoked from network); 9 Dec 2011 16:56:56 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 16:56:56 -0000
X-IronPort-AV: E=Sophos;i="4.71,326,1320624000"; 
   d="scan'208";a="9390166"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 16:56:56 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 16:56:56 +0000
Date: Fri, 9 Dec 2011 16:57:31 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
In-Reply-To: <20194.13560.873396.700831@mariner.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1112091629340.3517@kaball-desktop>
References: <1323108621-22654-1-git-send-email-ian.jackson@eu.citrix.com>
	<1323108621-22654-15-git-send-email-ian.jackson@eu.citrix.com>
	<alpine.DEB.2.00.1112091504060.3517@kaball-desktop>
	<20194.13560.873396.700831@mariner.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 14/15] libxl: New API for providing OS
 events to libxl
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 9 Dec 2011, Ian Jackson wrote:
> Firstly, Stefano, please trim your quotes.  You don't need to quote
> the whole zillion-line patch.  Just quote the bits that are relevant.
> Otherwise people may miss your comments as they page through trying to
> find them.

I personally prefer to keep the full quote so that I can search for
references without having to go back to the other email. However I do
understand that some people don't like this so I'll trim my comment to
your patches in the future.

 
> > > +int libxl_osevent_beforepoll(libxl_ctx *ctx, int *nfds_io,
> > > +                             struct pollfd *fds, int *timeout_upd,
> > > +                             struct timeval now);
> > > +  /* The caller should provide beforepoll with some space for libxl's
> > > +   * fds, and tell libxl how much space is available by setting *nfds_io.
> ... [ many lines of commentary ]
> > > +   * libxl_osevent_beforepoll will only reduce the timeout, naturally.
> > > +   */
> > 
> > so far we have always added the comment on a function above the
> > declaration of the function; we should keep doing it for consistency
> 
> I disagree.  That comment style involves either:
> 
>  1. Repeating the declaration at the top of the comment (or worse,
>     repeating the information in the declaration but in a different
>     format, doxygen-style); or
> 
>  2. Writing a comment which contains almost entirely forward references
> 
> This is not too bad if the comment is a one-liner.  But with a big
> comment like this, you end up with something like:
> 
>   /* The caller should provide beforepoll with some space for libxl's
>    * fds, and tell libxl how much space is available by setting *nfds_io.
>    * fds points to the start of this space (and fds may be a pointer into
>    * a larger array, for example, if the application has some fds of
>    * its own that it is interested in).
>    *
>    * On return *nfds_io will in any case have been updated by libxl
>    * according to how many fds libxl wants to poll on.
>    *
>    * If the space was sufficient, libxl fills in fds[0..<new
>    * *nfds_io>] suitably for poll(2), updates *timeout_upd if needed,
>    * and returns ok.
>    *
>    * If space was insufficient, fds[0..<old *nfds_io>] is undefined on
>    * return; *nfds_io on return will be greater than the value on
>    * entry; *timeout_upd may or may not have been updated; and
>    * libxl_osevent_beforepoll returns ERROR_BUFERFULL.  In this case
>    * the application needs to make more space (enough space for
>    * *nfds_io struct pollfd) and then call beforepoll again, before
>    * entering poll(2).  Typically this will involve calling realloc.
>    *
>    * The application may call beforepoll with fds==NULL and
>    * *nfds_io==0 in order to find out how much space is needed.
>    *
>    * *timeout_upd is as for poll(2): it's in milliseconds, and
>    * negative values mean no timeout (infinity).
>    * libxl_osevent_beforepoll will only reduce the timeout, naturally.
>    */
>   int libxl_osevent_beforepoll(libxl_ctx *ctx, int *nfds_io,
>                                struct pollfd *fds, int *timeout_upd,
>                                struct timeval now);
> 
> This is very disjointed if you try to read it.  You start with
> 
>   /* The caller should provide beforepoll with some space for libxl's
>    * fds, and tell libxl how much space is available by setting *nfds_io.
>    * fds points to the start of this space (and fds may be a pointer into
>    * a larger array, for example, if the application has some fds of
>    * its own that it is interested in).
> 
> and the natural reaction is "What caller?? What is this beforepoll and
> *nfds_io of which you speak?? What on earth are we talking about??"
> 
> The alternative, repeating the declaration, violates the principle
> that things should be said (and defined) in the code if that's
> possible, rather than having the primary reference be a comment.  It
> also violates the principle of trying to avoid putting the same
> information in two places.

I would prefer having a brief explanation of what the parameters are
before the function.  At least a few times this what my eyes where
looking for reading this patch.
See for example arch/x86/include/asm/paravirt_types.h in the linux
kernel: the long description of the MACROs is before the MACROs.


> If you want consistency then we should change the coding style to put
> comment about a function or object declaration after the prototype or
> declaration.

I disagree.


> > I see that the implementation of libxl_event_check is actually missing
> > from this patch.
> > Is this patch supposed to compiled, even without the actual libxl_event
> > generation? Or are the two patches have to be committed together?
> 
> libxl_event_check is not referred to by the code in this patch.  It is
> introduced in 15/15.  The comment is indeed not 100% true in this
> patch but it seemed better to provide here a comment explaining how
> things are going to be rather than writing
> 
>    * This function performs all of the IO and other actions,
>    * but this does not currently have any visible effect outside
>    * libxl.
> 
> in this patch and removing it in the next one.
> 
> My series compiles, and indeed is supposed to work, after each patch.

Yes, I think it is better this way.

 
> > > +typedef struct libxl_osevent_hooks {
> > > +  int (*fd_register)(void *uselibxl_event_check.r, int fd, void **for_app_registration_out,
> > > +                     short events, void *for_libxl);
> > > +  int (*fd_modify)(void *user, int fd, void **for_app_registration_update,
> > > +                   short events);
> > > +  void (*fd_deregister)(void *user, int fd, void *for_app_registration);
> > > +  int (*timeout_register)(void *user, void **for_app_registration_out,
> > > +                          struct timeval abs, void *for_libxl);
> > > +  int (*timeout_modify)(void *user, void **for_app_registration_update,
> > > +                         struct timeval abs);
> > > +  void (*timeout_deregister)(void *user, void *for_app_registration_io);
> > > +} libxl_osevent_hooks;
> > > +
> > > +void libxl_osevent_register_hooks(libxl_ctx *ctx,
> > > +                                  const libxl_osevent_hooks *hooks,
> > > +                                  void *user);
> ...
> > while this description is very verbose, it doesn't contain informations
> > on:
> > 
> > - what is void *user;
> 
> I would have thought this was obvious.  Every situation in C where a
> function pointer is passed needs also to pass a void* (or the
> equivalent) so that some context or dynamic information from the
> original caller can be passed to the inner called function.  So user
> is stored by libxl and passed to the hooks.

It might be obvious but it is not written anywhere. Considering the
level of details you went through in the following paragraph, I am
surprised that you left to guessing what this parameter is for. Better
be pedantic than leaving things to imagination.


> > - what is "const libxl_osevent_hooks *hooks", in particular the role of
> >   each  of these function pointers and the description of their
> >   arguments.
> 
> The role of these function pointers is this:
> 
> > > +  /* The application which calls register_fd_hooks promises to
> > > +   * maintain a register of fds and timeouts that libxl is interested
> > > +   * in, and make calls into libxl (libxl_osevent_occurred_*)
> > > +   * when those fd events and timeouts occur.  This is more efficient
> > > +   * than _beforepoll/_afterpoll if there are many fds (which can
> > > +   * happen if the same libxl application is managing many domains).
> 
> Ie, this is how libxl tells the application what fds and timeouts
> libxl is interested in.
> 
> > If I am a user of the library, how am I supposed to pass as user? and as
> > hooks?
> > I think these few lines should go first, then the description of the
> > contract.
> 
> Did you spot this comment, earlier ?

That comment explains what the application promises, not what the
parameters are. However I know what you mean: from that paragraph and
from the name of the parameters it is easy to guess what they are for.
Still I would rather avoid leaving anything to guessing.


> > > + * The second approach uses libxl_osevent_register_hooks and is
> > > + * suitable for programs which are already using a callback-based
> > > + * event library.
> 
> libxl_osevent_hooks is for this second approach.  If you know what a
> callback-based event library is - particularly if you actually have
> one in front of you - all of this should be obvious.  If you don't
> know what a callback-based event library is, then you don't have one
> and you don't want to use this interface.

I disagree. Even if it is the first time one sees a callback-based event
library, one should be able to use it without trouble. If it is too
difficult, maybe it is not designed in the best possible way.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 16:58:02 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 16:58:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZ3lc-0005xJ-1Q; Fri, 09 Dec 2011 16:57:48 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RZ3la-0005we-79
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 16:57:46 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1323449816!6783108!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI2MQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11063 invoked from network); 9 Dec 2011 16:56:56 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 16:56:56 -0000
X-IronPort-AV: E=Sophos;i="4.71,326,1320624000"; 
   d="scan'208";a="9390166"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 16:56:56 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 16:56:56 +0000
Date: Fri, 9 Dec 2011 16:57:31 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
In-Reply-To: <20194.13560.873396.700831@mariner.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1112091629340.3517@kaball-desktop>
References: <1323108621-22654-1-git-send-email-ian.jackson@eu.citrix.com>
	<1323108621-22654-15-git-send-email-ian.jackson@eu.citrix.com>
	<alpine.DEB.2.00.1112091504060.3517@kaball-desktop>
	<20194.13560.873396.700831@mariner.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 14/15] libxl: New API for providing OS
 events to libxl
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 9 Dec 2011, Ian Jackson wrote:
> Firstly, Stefano, please trim your quotes.  You don't need to quote
> the whole zillion-line patch.  Just quote the bits that are relevant.
> Otherwise people may miss your comments as they page through trying to
> find them.

I personally prefer to keep the full quote so that I can search for
references without having to go back to the other email. However I do
understand that some people don't like this so I'll trim my comment to
your patches in the future.

 
> > > +int libxl_osevent_beforepoll(libxl_ctx *ctx, int *nfds_io,
> > > +                             struct pollfd *fds, int *timeout_upd,
> > > +                             struct timeval now);
> > > +  /* The caller should provide beforepoll with some space for libxl's
> > > +   * fds, and tell libxl how much space is available by setting *nfds_io.
> ... [ many lines of commentary ]
> > > +   * libxl_osevent_beforepoll will only reduce the timeout, naturally.
> > > +   */
> > 
> > so far we have always added the comment on a function above the
> > declaration of the function; we should keep doing it for consistency
> 
> I disagree.  That comment style involves either:
> 
>  1. Repeating the declaration at the top of the comment (or worse,
>     repeating the information in the declaration but in a different
>     format, doxygen-style); or
> 
>  2. Writing a comment which contains almost entirely forward references
> 
> This is not too bad if the comment is a one-liner.  But with a big
> comment like this, you end up with something like:
> 
>   /* The caller should provide beforepoll with some space for libxl's
>    * fds, and tell libxl how much space is available by setting *nfds_io.
>    * fds points to the start of this space (and fds may be a pointer into
>    * a larger array, for example, if the application has some fds of
>    * its own that it is interested in).
>    *
>    * On return *nfds_io will in any case have been updated by libxl
>    * according to how many fds libxl wants to poll on.
>    *
>    * If the space was sufficient, libxl fills in fds[0..<new
>    * *nfds_io>] suitably for poll(2), updates *timeout_upd if needed,
>    * and returns ok.
>    *
>    * If space was insufficient, fds[0..<old *nfds_io>] is undefined on
>    * return; *nfds_io on return will be greater than the value on
>    * entry; *timeout_upd may or may not have been updated; and
>    * libxl_osevent_beforepoll returns ERROR_BUFERFULL.  In this case
>    * the application needs to make more space (enough space for
>    * *nfds_io struct pollfd) and then call beforepoll again, before
>    * entering poll(2).  Typically this will involve calling realloc.
>    *
>    * The application may call beforepoll with fds==NULL and
>    * *nfds_io==0 in order to find out how much space is needed.
>    *
>    * *timeout_upd is as for poll(2): it's in milliseconds, and
>    * negative values mean no timeout (infinity).
>    * libxl_osevent_beforepoll will only reduce the timeout, naturally.
>    */
>   int libxl_osevent_beforepoll(libxl_ctx *ctx, int *nfds_io,
>                                struct pollfd *fds, int *timeout_upd,
>                                struct timeval now);
> 
> This is very disjointed if you try to read it.  You start with
> 
>   /* The caller should provide beforepoll with some space for libxl's
>    * fds, and tell libxl how much space is available by setting *nfds_io.
>    * fds points to the start of this space (and fds may be a pointer into
>    * a larger array, for example, if the application has some fds of
>    * its own that it is interested in).
> 
> and the natural reaction is "What caller?? What is this beforepoll and
> *nfds_io of which you speak?? What on earth are we talking about??"
> 
> The alternative, repeating the declaration, violates the principle
> that things should be said (and defined) in the code if that's
> possible, rather than having the primary reference be a comment.  It
> also violates the principle of trying to avoid putting the same
> information in two places.

I would prefer having a brief explanation of what the parameters are
before the function.  At least a few times this what my eyes where
looking for reading this patch.
See for example arch/x86/include/asm/paravirt_types.h in the linux
kernel: the long description of the MACROs is before the MACROs.


> If you want consistency then we should change the coding style to put
> comment about a function or object declaration after the prototype or
> declaration.

I disagree.


> > I see that the implementation of libxl_event_check is actually missing
> > from this patch.
> > Is this patch supposed to compiled, even without the actual libxl_event
> > generation? Or are the two patches have to be committed together?
> 
> libxl_event_check is not referred to by the code in this patch.  It is
> introduced in 15/15.  The comment is indeed not 100% true in this
> patch but it seemed better to provide here a comment explaining how
> things are going to be rather than writing
> 
>    * This function performs all of the IO and other actions,
>    * but this does not currently have any visible effect outside
>    * libxl.
> 
> in this patch and removing it in the next one.
> 
> My series compiles, and indeed is supposed to work, after each patch.

Yes, I think it is better this way.

 
> > > +typedef struct libxl_osevent_hooks {
> > > +  int (*fd_register)(void *uselibxl_event_check.r, int fd, void **for_app_registration_out,
> > > +                     short events, void *for_libxl);
> > > +  int (*fd_modify)(void *user, int fd, void **for_app_registration_update,
> > > +                   short events);
> > > +  void (*fd_deregister)(void *user, int fd, void *for_app_registration);
> > > +  int (*timeout_register)(void *user, void **for_app_registration_out,
> > > +                          struct timeval abs, void *for_libxl);
> > > +  int (*timeout_modify)(void *user, void **for_app_registration_update,
> > > +                         struct timeval abs);
> > > +  void (*timeout_deregister)(void *user, void *for_app_registration_io);
> > > +} libxl_osevent_hooks;
> > > +
> > > +void libxl_osevent_register_hooks(libxl_ctx *ctx,
> > > +                                  const libxl_osevent_hooks *hooks,
> > > +                                  void *user);
> ...
> > while this description is very verbose, it doesn't contain informations
> > on:
> > 
> > - what is void *user;
> 
> I would have thought this was obvious.  Every situation in C where a
> function pointer is passed needs also to pass a void* (or the
> equivalent) so that some context or dynamic information from the
> original caller can be passed to the inner called function.  So user
> is stored by libxl and passed to the hooks.

It might be obvious but it is not written anywhere. Considering the
level of details you went through in the following paragraph, I am
surprised that you left to guessing what this parameter is for. Better
be pedantic than leaving things to imagination.


> > - what is "const libxl_osevent_hooks *hooks", in particular the role of
> >   each  of these function pointers and the description of their
> >   arguments.
> 
> The role of these function pointers is this:
> 
> > > +  /* The application which calls register_fd_hooks promises to
> > > +   * maintain a register of fds and timeouts that libxl is interested
> > > +   * in, and make calls into libxl (libxl_osevent_occurred_*)
> > > +   * when those fd events and timeouts occur.  This is more efficient
> > > +   * than _beforepoll/_afterpoll if there are many fds (which can
> > > +   * happen if the same libxl application is managing many domains).
> 
> Ie, this is how libxl tells the application what fds and timeouts
> libxl is interested in.
> 
> > If I am a user of the library, how am I supposed to pass as user? and as
> > hooks?
> > I think these few lines should go first, then the description of the
> > contract.
> 
> Did you spot this comment, earlier ?

That comment explains what the application promises, not what the
parameters are. However I know what you mean: from that paragraph and
from the name of the parameters it is easy to guess what they are for.
Still I would rather avoid leaving anything to guessing.


> > > + * The second approach uses libxl_osevent_register_hooks and is
> > > + * suitable for programs which are already using a callback-based
> > > + * event library.
> 
> libxl_osevent_hooks is for this second approach.  If you know what a
> callback-based event library is - particularly if you actually have
> one in front of you - all of this should be obvious.  If you don't
> know what a callback-based event library is, then you don't have one
> and you don't want to use this interface.

I disagree. Even if it is the first time one sees a callback-based event
library, one should be able to use it without trouble. If it is too
difficult, maybe it is not designed in the best possible way.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 16:58:07 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 16:58:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZ3lm-0005za-Kr; Fri, 09 Dec 2011 16:57:58 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RZ3ll-0005yE-E2
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 16:57:57 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1323449828!6845413!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI2MQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13534 invoked from network); 9 Dec 2011 16:57:08 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 16:57:08 -0000
X-IronPort-AV: E=Sophos;i="4.71,326,1320624000"; 
   d="scan'208";a="9390169"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 16:57:08 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 16:57:07 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RZ3kx-0001zt-C8; Fri, 09 Dec 2011 16:57:07 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RZ3kx-0004Kz-BW;
	Fri, 09 Dec 2011 16:57:07 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20194.15843.346545.779639@mariner.uk.xensource.com>
Date: Fri, 9 Dec 2011 16:57:07 +0000
To: Ian Campbell <ian.campbell@citrix.com>
In-Reply-To: <9c1b223e152eaaa3861f.1323432165@cosworth.uk.xensource.com>
References: <patchbomb.1323432164@cosworth.uk.xensource.com>
	<9c1b223e152eaaa3861f.1323432165@cosworth.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 1 of 2] libxl: fix cold plugged PCI devices
	with stubdomains
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("[PATCH 1 of 2] libxl: fix cold plugged PCI devices with stubdomains"):
> libxl: fix cold plugged PCI devices with stubdomains
> 
> Since 23565:72eafe80ebc1 the xenstore entries for the stubdomain's
> PCI were never created and therefore the stubdom ends up waiting
> forever for the devices which it has been asked to insert to show
> up.
> 
> Since the stubdomain is already running when we call the libxl_device_pci_add
> loop in do_domain_create we should treat it as if "starting == 0".

That sounds plausible.

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 16:58:07 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 16:58:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZ3lm-0005za-Kr; Fri, 09 Dec 2011 16:57:58 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RZ3ll-0005yE-E2
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 16:57:57 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1323449828!6845413!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI2MQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13534 invoked from network); 9 Dec 2011 16:57:08 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 16:57:08 -0000
X-IronPort-AV: E=Sophos;i="4.71,326,1320624000"; 
   d="scan'208";a="9390169"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 16:57:08 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 16:57:07 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RZ3kx-0001zt-C8; Fri, 09 Dec 2011 16:57:07 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RZ3kx-0004Kz-BW;
	Fri, 09 Dec 2011 16:57:07 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20194.15843.346545.779639@mariner.uk.xensource.com>
Date: Fri, 9 Dec 2011 16:57:07 +0000
To: Ian Campbell <ian.campbell@citrix.com>
In-Reply-To: <9c1b223e152eaaa3861f.1323432165@cosworth.uk.xensource.com>
References: <patchbomb.1323432164@cosworth.uk.xensource.com>
	<9c1b223e152eaaa3861f.1323432165@cosworth.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 1 of 2] libxl: fix cold plugged PCI devices
	with stubdomains
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("[PATCH 1 of 2] libxl: fix cold plugged PCI devices with stubdomains"):
> libxl: fix cold plugged PCI devices with stubdomains
> 
> Since 23565:72eafe80ebc1 the xenstore entries for the stubdomain's
> PCI were never created and therefore the stubdom ends up waiting
> forever for the devices which it has been asked to insert to show
> up.
> 
> Since the stubdomain is already running when we call the libxl_device_pci_add
> loop in do_domain_create we should treat it as if "starting == 0".

That sounds plausible.

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 17:01:20 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 17:01:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZ3oo-0006Nn-8x; Fri, 09 Dec 2011 17:01:06 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RZ3om-0006N5-VU
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 17:01:05 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1323450011!7413108!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI2MQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3549 invoked from network); 9 Dec 2011 17:00:11 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 17:00:11 -0000
X-IronPort-AV: E=Sophos;i="4.71,326,1320624000"; 
   d="scan'208";a="9390234"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 17:00:11 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 17:00:11 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RZ3nv-00020u-1P; Fri, 09 Dec 2011 17:00:11 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RZ3nv-0004LF-0c;
	Fri, 09 Dec 2011 17:00:11 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20194.16027.6685.77329@mariner.uk.xensource.com>
Date: Fri, 9 Dec 2011 17:00:11 +0000
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
In-Reply-To: <alpine.DEB.2.00.1112091629340.3517@kaball-desktop>
References: <1323108621-22654-1-git-send-email-ian.jackson@eu.citrix.com>
	<1323108621-22654-15-git-send-email-ian.jackson@eu.citrix.com>
	<alpine.DEB.2.00.1112091504060.3517@kaball-desktop>
	<20194.13560.873396.700831@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1112091629340.3517@kaball-desktop>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 14/15] libxl: New API for providing OS
 events to libxl
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Stefano Stabellini writes ("Re: [Xen-devel] [PATCH 14/15] libxl: New API for providing OS events to libxl"):
> On Fri, 9 Dec 2011, Ian Jackson wrote:
> > Firstly, Stefano, please trim your quotes.  You don't need to quote
> > the whole zillion-line patch.  Just quote the bits that are relevant.
> > Otherwise people may miss your comments as they page through trying to
> > find them.
> 
> I personally prefer to keep the full quote so that I can search for
> references without having to go back to the other email. However I do
> understand that some people don't like this so I'll trim my comment to
> your patches in the future.

Everyone on the list needs to be able to read these review comments,
not just the author of the original patch.  I see Ian C agrees with
me.  The standard approach should always be to trim the patch to the
relevant parts only.

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 17:01:20 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 17:01:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZ3oo-0006Nn-8x; Fri, 09 Dec 2011 17:01:06 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RZ3om-0006N5-VU
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 17:01:05 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1323450011!7413108!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI2MQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3549 invoked from network); 9 Dec 2011 17:00:11 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 17:00:11 -0000
X-IronPort-AV: E=Sophos;i="4.71,326,1320624000"; 
   d="scan'208";a="9390234"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 17:00:11 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 17:00:11 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RZ3nv-00020u-1P; Fri, 09 Dec 2011 17:00:11 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RZ3nv-0004LF-0c;
	Fri, 09 Dec 2011 17:00:11 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20194.16027.6685.77329@mariner.uk.xensource.com>
Date: Fri, 9 Dec 2011 17:00:11 +0000
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
In-Reply-To: <alpine.DEB.2.00.1112091629340.3517@kaball-desktop>
References: <1323108621-22654-1-git-send-email-ian.jackson@eu.citrix.com>
	<1323108621-22654-15-git-send-email-ian.jackson@eu.citrix.com>
	<alpine.DEB.2.00.1112091504060.3517@kaball-desktop>
	<20194.13560.873396.700831@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1112091629340.3517@kaball-desktop>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 14/15] libxl: New API for providing OS
 events to libxl
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Stefano Stabellini writes ("Re: [Xen-devel] [PATCH 14/15] libxl: New API for providing OS events to libxl"):
> On Fri, 9 Dec 2011, Ian Jackson wrote:
> > Firstly, Stefano, please trim your quotes.  You don't need to quote
> > the whole zillion-line patch.  Just quote the bits that are relevant.
> > Otherwise people may miss your comments as they page through trying to
> > find them.
> 
> I personally prefer to keep the full quote so that I can search for
> references without having to go back to the other email. However I do
> understand that some people don't like this so I'll trim my comment to
> your patches in the future.

Everyone on the list needs to be able to read these review comments,
not just the author of the original patch.  I see Ian C agrees with
me.  The standard approach should always be to trim the patch to the
relevant parts only.

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 17:02:07 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 17:02:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZ3pc-0006Th-OF; Fri, 09 Dec 2011 17:01:56 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RZ3pb-0006T4-20
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 17:01:55 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1323450065!6546563!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI2MQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17250 invoked from network); 9 Dec 2011 17:01:05 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 17:01:05 -0000
X-IronPort-AV: E=Sophos;i="4.71,326,1320624000"; 
   d="scan'208";a="9390255"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 17:01:04 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 9 Dec 2011
	17:01:04 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Fri, 9 Dec 2011 17:01:04 +0000
In-Reply-To: <20194.15809.931214.529696@mariner.uk.xensource.com>
References: <patchbomb.1323432164@cosworth.uk.xensource.com>
	<d50241faddf372f22626.1323432166@cosworth.uk.xensource.com>
	<20194.15809.931214.529696@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323450064.20077.82.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 2 of 2] mini-os: do not wait for pci backend
 in pcifront_scan
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2011-12-09 at 16:56 +0000, Ian Jackson wrote:
> Ian Campbell writes ("[PATCH 2 of 2] mini-os: do not wait for pci backend in pcifront_scan"):
> > Even in the case where there are passthrough devices configured libxl creates
> > the stubdom and waits for it to startup _before_ adding the backend. Since the
> > stub domains main thread is blocked before it can write the "running" state to
> > xenstore the toolstack eventually times out and kills everything.
> > 
> > There is already a separate pcifront thread which waits for the backend to
> > appear and calls init_pcifront at the appropriate time should a backend ever
> > appear.
> > 
> > Unfortunately I don't have any free test boxes with VT-d so I
> > haven't been able to test the cases where PCI deivces are passed
> > through but I obviously have tested that I can now start an HVM
> > domain with stub qemu without PCI devices passed through which I
> > couldn't do before so this is an improvement. This stuff is a bit
> > like pushing the lump around the carpet :-/
> 
> Right.  The worry would be, surely, that this somehow breaks by
> unpausing the guest before everything has been set up by the stubdom.

Yes. I was a bit unclear how this ever worked though...

We could potentially add something to libxl__create_pci_backend which
interlocks against the stubdom pcifront but without a system with an
IOMMU I'm not really in a position to test such a patch.

> But I'm happy to ack this patch on the basis that it seemed to improve
> things for you and should be harmless for the non-stubdom case.

Thanks.

> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
> 
> (Not applying it yet as the patch floodgate is still closed pending a
> test pass.)

Sure.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 17:02:07 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 17:02:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZ3pc-0006Th-OF; Fri, 09 Dec 2011 17:01:56 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RZ3pb-0006T4-20
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 17:01:55 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1323450065!6546563!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI2MQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17250 invoked from network); 9 Dec 2011 17:01:05 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 17:01:05 -0000
X-IronPort-AV: E=Sophos;i="4.71,326,1320624000"; 
   d="scan'208";a="9390255"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 17:01:04 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 9 Dec 2011
	17:01:04 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Fri, 9 Dec 2011 17:01:04 +0000
In-Reply-To: <20194.15809.931214.529696@mariner.uk.xensource.com>
References: <patchbomb.1323432164@cosworth.uk.xensource.com>
	<d50241faddf372f22626.1323432166@cosworth.uk.xensource.com>
	<20194.15809.931214.529696@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323450064.20077.82.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 2 of 2] mini-os: do not wait for pci backend
 in pcifront_scan
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2011-12-09 at 16:56 +0000, Ian Jackson wrote:
> Ian Campbell writes ("[PATCH 2 of 2] mini-os: do not wait for pci backend in pcifront_scan"):
> > Even in the case where there are passthrough devices configured libxl creates
> > the stubdom and waits for it to startup _before_ adding the backend. Since the
> > stub domains main thread is blocked before it can write the "running" state to
> > xenstore the toolstack eventually times out and kills everything.
> > 
> > There is already a separate pcifront thread which waits for the backend to
> > appear and calls init_pcifront at the appropriate time should a backend ever
> > appear.
> > 
> > Unfortunately I don't have any free test boxes with VT-d so I
> > haven't been able to test the cases where PCI deivces are passed
> > through but I obviously have tested that I can now start an HVM
> > domain with stub qemu without PCI devices passed through which I
> > couldn't do before so this is an improvement. This stuff is a bit
> > like pushing the lump around the carpet :-/
> 
> Right.  The worry would be, surely, that this somehow breaks by
> unpausing the guest before everything has been set up by the stubdom.

Yes. I was a bit unclear how this ever worked though...

We could potentially add something to libxl__create_pci_backend which
interlocks against the stubdom pcifront but without a system with an
IOMMU I'm not really in a position to test such a patch.

> But I'm happy to ack this patch on the basis that it seemed to improve
> things for you and should be harmless for the non-stubdom case.

Thanks.

> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
> 
> (Not applying it yet as the patch floodgate is still closed pending a
> test pass.)

Sure.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 17:05:59 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 17: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.xensource.com>)
	id 1RZ3tO-0006oU-Dl; Fri, 09 Dec 2011 17:05:50 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RZ3tN-0006o2-BP
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 17:05:49 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1323450299!4759327!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI2MQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6985 invoked from network); 9 Dec 2011 17:05:00 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 17:05:00 -0000
X-IronPort-AV: E=Sophos;i="4.71,327,1320624000"; 
   d="scan'208";a="9390329"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 17:04:59 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 9 Dec 2011
	17:04:59 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Fri, 9 Dec 2011 17:04:59 +0000
In-Reply-To: <patchbomb.1323448640@cosworth.uk.xensource.com>
References: <patchbomb.1323448640@cosworth.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323450299.20077.84.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Vincent Hanquez <Vincent.Hanquez@eu.citrix.com>,
	Olaf Hering <olaf@aepfle.de>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Jonathan Ludlam <Jonathan.Ludlam@eu.citrix.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH 0 of 4] oxenstored fixes -- fixes recent
 pvops kernel hang
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2011-12-09 at 16:37 +0000, Ian Campbell wrote:
> Two other small fixlets are included.

Actually, that should have been four. I'll post the other two as
separate replies to this mail. They will be:

oxenstored: install configuration file
oxenstored: Always log something at start of day (if logging enabled at all)

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 17:05:59 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 17: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.xensource.com>)
	id 1RZ3tO-0006oU-Dl; Fri, 09 Dec 2011 17:05:50 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RZ3tN-0006o2-BP
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 17:05:49 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1323450299!4759327!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI2MQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6985 invoked from network); 9 Dec 2011 17:05:00 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 17:05:00 -0000
X-IronPort-AV: E=Sophos;i="4.71,327,1320624000"; 
   d="scan'208";a="9390329"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 17:04:59 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 9 Dec 2011
	17:04:59 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Fri, 9 Dec 2011 17:04:59 +0000
In-Reply-To: <patchbomb.1323448640@cosworth.uk.xensource.com>
References: <patchbomb.1323448640@cosworth.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323450299.20077.84.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Vincent Hanquez <Vincent.Hanquez@eu.citrix.com>,
	Olaf Hering <olaf@aepfle.de>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Jonathan Ludlam <Jonathan.Ludlam@eu.citrix.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH 0 of 4] oxenstored fixes -- fixes recent
 pvops kernel hang
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2011-12-09 at 16:37 +0000, Ian Campbell wrote:
> Two other small fixlets are included.

Actually, that should have been four. I'll post the other two as
separate replies to this mail. They will be:

oxenstored: install configuration file
oxenstored: Always log something at start of day (if logging enabled at all)

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 17:08:45 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 17:08:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZ3w2-0006xQ-12; Fri, 09 Dec 2011 17:08:34 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RZ3w0-0006wz-2t
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 17:08:32 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1323450462!4942567!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI2MQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27462 invoked from network); 9 Dec 2011 17:07:42 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 17:07:42 -0000
X-IronPort-AV: E=Sophos;i="4.71,327,1320624000"; 
   d="scan'208";a="9390361"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 17:07:42 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 9 Dec 2011
	17:07:41 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Fri, 9 Dec 2011 17:07:41 +0000
In-Reply-To: <alpine.DEB.2.00.1112091629340.3517@kaball-desktop>
References: <1323108621-22654-1-git-send-email-ian.jackson@eu.citrix.com>
	<1323108621-22654-15-git-send-email-ian.jackson@eu.citrix.com>
	<alpine.DEB.2.00.1112091504060.3517@kaball-desktop>
	<20194.13560.873396.700831@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1112091629340.3517@kaball-desktop>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323450461.20077.86.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 14/15] libxl: New API for providing OS
 events to libxl
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2011-12-09 at 16:57 +0000, Stefano Stabellini wrote:
> On Fri, 9 Dec 2011, Ian Jackson wrote:
> > Firstly, Stefano, please trim your quotes.  You don't need to quote
> > the whole zillion-line patch.  Just quote the bits that are relevant.
> > Otherwise people may miss your comments as they page through trying to
> > find them.
> 
> I personally prefer to keep the full quote so that I can search for
> references without having to go back to the other email.

A proper mailer has at least two windows. (/duck and cover) ;-)

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 17:08:45 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 17:08:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZ3w2-0006xQ-12; Fri, 09 Dec 2011 17:08:34 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RZ3w0-0006wz-2t
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 17:08:32 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1323450462!4942567!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI2MQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27462 invoked from network); 9 Dec 2011 17:07:42 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 17:07:42 -0000
X-IronPort-AV: E=Sophos;i="4.71,327,1320624000"; 
   d="scan'208";a="9390361"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 17:07:42 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 9 Dec 2011
	17:07:41 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Fri, 9 Dec 2011 17:07:41 +0000
In-Reply-To: <alpine.DEB.2.00.1112091629340.3517@kaball-desktop>
References: <1323108621-22654-1-git-send-email-ian.jackson@eu.citrix.com>
	<1323108621-22654-15-git-send-email-ian.jackson@eu.citrix.com>
	<alpine.DEB.2.00.1112091504060.3517@kaball-desktop>
	<20194.13560.873396.700831@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1112091629340.3517@kaball-desktop>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323450461.20077.86.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 14/15] libxl: New API for providing OS
 events to libxl
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2011-12-09 at 16:57 +0000, Stefano Stabellini wrote:
> On Fri, 9 Dec 2011, Ian Jackson wrote:
> > Firstly, Stefano, please trim your quotes.  You don't need to quote
> > the whole zillion-line patch.  Just quote the bits that are relevant.
> > Otherwise people may miss your comments as they page through trying to
> > find them.
> 
> I personally prefer to keep the full quote so that I can search for
> references without having to go back to the other email.

A proper mailer has at least two windows. (/duck and cover) ;-)

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 17:09:18 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 17: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.xensource.com>)
	id 1RZ3wc-000704-Ez; Fri, 09 Dec 2011 17:09:10 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RZ3wa-0006zV-Om
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 17:09:08 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1323450492!6807852!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMTkxNzY=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21754 invoked from network); 9 Dec 2011 17:08:14 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 17:08:14 -0000
X-IronPort-AV: E=Sophos;i="4.71,327,1320642000"; d="scan'208";a="173585764"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 12:08:12 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 12:08:10 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pB9H87c7009521;	Fri, 9 Dec 2011 09:08:08 -0800
MIME-Version: 1.0
X-Mercurial-Node: 91415c125c676d9e87d9939bfecdd1a4a0b2edfa
Message-ID: <91415c125c676d9e87d9.1323450487@cosworth.uk.xensource.com>
In-Reply-To: <1323450299.20077.84.camel@zakaz.uk.xensource.com>
References: <1323450299.20077.84.camel@zakaz.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 9 Dec 2011 17:08:07 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com, Olaf Hering <olaf@aepfle.de>,
	Vincent Hanquez <Vincent.Hanquez@eu.citrix.com>,
	Jonathan Ludlam <Jonathan.Ludlam@eu.citrix.com>, konrad.wilk@oracle.com
Subject: [Xen-devel] [PATCH] oxenstored: install configuration file
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1323449332 0
# Node ID 91415c125c676d9e87d9939bfecdd1a4a0b2edfa
# Parent  3b7ac401f144206c30440fbb41c74b13fa20b8cb
oxenstored: install configuration file

First though:
  - Move it to /etc/xen/oxenstored.conf.
  - Use /var/run/xenstored.pid as default pid file
  - Disable test-eagain "Randomly failed a transaction with EAGAIN. Used for
    testing Xs user". Doesn't sound fun by default...

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff --git a/tools/ocaml/xenstored/Makefile b/tools/ocaml/xenstored/Makefile
--- a/tools/ocaml/xenstored/Makefile
+++ b/tools/ocaml/xenstored/Makefile
@@ -52,5 +52,7 @@ bins: $(PROGRAMS)
 install: all
 	$(INSTALL_DIR) $(DESTDIR)$(SBINDIR)
 	$(INSTALL_PROG) oxenstored $(DESTDIR)$(SBINDIR)
+	$(INSTALL_DIR) $(DESTDIR)$(XEN_CONFIG_DIR)
+	$(INSTALL_DATA) oxenstored.conf $(DESTDIR)$(XEN_CONFIG_DIR)
 
 include $(OCAML_TOPLEVEL)/Makefile.rules
diff --git a/tools/ocaml/xenstored/define.ml b/tools/ocaml/xenstored/define.ml
--- a/tools/ocaml/xenstored/define.ml
+++ b/tools/ocaml/xenstored/define.ml
@@ -23,7 +23,7 @@ let xenstored_proc_port = "/proc/xen/xsd
 let xs_daemon_socket = "/var/run/xenstored/socket"
 let xs_daemon_socket_ro = "/var/run/xenstored/socket_ro"
 
-let default_config_dir = "/etc/xensource"
+let default_config_dir = "/etc/xen"
 
 let maxwatch = ref (50)
 let maxtransaction = ref (20)
diff --git a/tools/ocaml/xenstored/xenstored.conf b/tools/ocaml/xenstored/oxenstored.conf
rename from tools/ocaml/xenstored/xenstored.conf
rename to tools/ocaml/xenstored/oxenstored.conf
--- a/tools/ocaml/xenstored/xenstored.conf
+++ b/tools/ocaml/xenstored/oxenstored.conf
@@ -1,10 +1,10 @@
 # default xenstored config
 
 # Where the pid file is stored
-pid-file = /var/run/xensource/xenstored.pid
+pid-file = /var/run/xenstored.pid
 
 # Randomly failed a transaction with EAGAIN. Used for testing Xs user
-test-eagain = true
+test-eagain = false
 
 # Activate transaction merge support
 merge-activate = true
diff --git a/tools/ocaml/xenstored/xenstored.ml b/tools/ocaml/xenstored/xenstored.ml
--- a/tools/ocaml/xenstored/xenstored.ml
+++ b/tools/ocaml/xenstored/xenstored.ml
@@ -71,7 +71,7 @@ let sighup_handler _ =
 let config_filename cf =
 	match cf.config_file with
 	| Some name -> name
-	| None      -> Define.default_config_dir ^ "/xenstored.conf"
+	| None      -> Define.default_config_dir ^ "/oxenstored.conf"
 
 let default_pidfile = "/var/run/xenstored.pid"
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 17:09:18 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 17: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.xensource.com>)
	id 1RZ3wc-000704-Ez; Fri, 09 Dec 2011 17:09:10 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RZ3wa-0006zV-Om
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 17:09:08 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1323450492!6807852!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMTkxNzY=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21754 invoked from network); 9 Dec 2011 17:08:14 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 17:08:14 -0000
X-IronPort-AV: E=Sophos;i="4.71,327,1320642000"; d="scan'208";a="173585764"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 12:08:12 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 12:08:10 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pB9H87c7009521;	Fri, 9 Dec 2011 09:08:08 -0800
MIME-Version: 1.0
X-Mercurial-Node: 91415c125c676d9e87d9939bfecdd1a4a0b2edfa
Message-ID: <91415c125c676d9e87d9.1323450487@cosworth.uk.xensource.com>
In-Reply-To: <1323450299.20077.84.camel@zakaz.uk.xensource.com>
References: <1323450299.20077.84.camel@zakaz.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 9 Dec 2011 17:08:07 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com, Olaf Hering <olaf@aepfle.de>,
	Vincent Hanquez <Vincent.Hanquez@eu.citrix.com>,
	Jonathan Ludlam <Jonathan.Ludlam@eu.citrix.com>, konrad.wilk@oracle.com
Subject: [Xen-devel] [PATCH] oxenstored: install configuration file
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1323449332 0
# Node ID 91415c125c676d9e87d9939bfecdd1a4a0b2edfa
# Parent  3b7ac401f144206c30440fbb41c74b13fa20b8cb
oxenstored: install configuration file

First though:
  - Move it to /etc/xen/oxenstored.conf.
  - Use /var/run/xenstored.pid as default pid file
  - Disable test-eagain "Randomly failed a transaction with EAGAIN. Used for
    testing Xs user". Doesn't sound fun by default...

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff --git a/tools/ocaml/xenstored/Makefile b/tools/ocaml/xenstored/Makefile
--- a/tools/ocaml/xenstored/Makefile
+++ b/tools/ocaml/xenstored/Makefile
@@ -52,5 +52,7 @@ bins: $(PROGRAMS)
 install: all
 	$(INSTALL_DIR) $(DESTDIR)$(SBINDIR)
 	$(INSTALL_PROG) oxenstored $(DESTDIR)$(SBINDIR)
+	$(INSTALL_DIR) $(DESTDIR)$(XEN_CONFIG_DIR)
+	$(INSTALL_DATA) oxenstored.conf $(DESTDIR)$(XEN_CONFIG_DIR)
 
 include $(OCAML_TOPLEVEL)/Makefile.rules
diff --git a/tools/ocaml/xenstored/define.ml b/tools/ocaml/xenstored/define.ml
--- a/tools/ocaml/xenstored/define.ml
+++ b/tools/ocaml/xenstored/define.ml
@@ -23,7 +23,7 @@ let xenstored_proc_port = "/proc/xen/xsd
 let xs_daemon_socket = "/var/run/xenstored/socket"
 let xs_daemon_socket_ro = "/var/run/xenstored/socket_ro"
 
-let default_config_dir = "/etc/xensource"
+let default_config_dir = "/etc/xen"
 
 let maxwatch = ref (50)
 let maxtransaction = ref (20)
diff --git a/tools/ocaml/xenstored/xenstored.conf b/tools/ocaml/xenstored/oxenstored.conf
rename from tools/ocaml/xenstored/xenstored.conf
rename to tools/ocaml/xenstored/oxenstored.conf
--- a/tools/ocaml/xenstored/xenstored.conf
+++ b/tools/ocaml/xenstored/oxenstored.conf
@@ -1,10 +1,10 @@
 # default xenstored config
 
 # Where the pid file is stored
-pid-file = /var/run/xensource/xenstored.pid
+pid-file = /var/run/xenstored.pid
 
 # Randomly failed a transaction with EAGAIN. Used for testing Xs user
-test-eagain = true
+test-eagain = false
 
 # Activate transaction merge support
 merge-activate = true
diff --git a/tools/ocaml/xenstored/xenstored.ml b/tools/ocaml/xenstored/xenstored.ml
--- a/tools/ocaml/xenstored/xenstored.ml
+++ b/tools/ocaml/xenstored/xenstored.ml
@@ -71,7 +71,7 @@ let sighup_handler _ =
 let config_filename cf =
 	match cf.config_file with
 	| Some name -> name
-	| None      -> Define.default_config_dir ^ "/xenstored.conf"
+	| None      -> Define.default_config_dir ^ "/oxenstored.conf"
 
 let default_pidfile = "/var/run/xenstored.pid"
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 17:09:19 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 17:09:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZ3we-00070V-RG; Fri, 09 Dec 2011 17:09:12 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RZ3wd-0006zj-MT
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 17:09:11 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1323450492!6807852!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMTkxNzY=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22493 invoked from network); 9 Dec 2011 17:08:21 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 17:08:21 -0000
X-IronPort-AV: E=Sophos;i="4.71,327,1320642000"; d="scan'208";a="173585789"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 12:08:21 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 12:08:21 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pB9H8J6R009524;	Fri, 9 Dec 2011 09:08:19 -0800
MIME-Version: 1.0
X-Mercurial-Node: c2fbf133c235c023769640fdb24d84462a6b36ec
Message-ID: <c2fbf133c235c0237696.1323450498@cosworth.uk.xensource.com>
In-Reply-To: <1323450299.20077.84.camel@zakaz.uk.xensource.com>
References: <1323450299.20077.84.camel@zakaz.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 9 Dec 2011 17:08:18 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com, Olaf Hering <olaf@aepfle.de>,
	Vincent Hanquez <Vincent.Hanquez@eu.citrix.com>,
	Jonathan Ludlam <Jonathan.Ludlam@eu.citrix.com>, konrad.wilk@oracle.com
Subject: [Xen-devel] [PATCH] oxenstored: Always log something at start of
 day (if logging enabled at all)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1323450179 0
# Node ID c2fbf133c235c023769640fdb24d84462a6b36ec
# Parent  91415c125c676d9e87d9939bfecdd1a4a0b2edfa
oxenstored: Always log something at start of day (if logging enabled at all)

Otherwise at the default level we rarely log anything at all.

A completely empty log file is a good sign, but only if you know you are
looking in the right place...

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff --git a/tools/ocaml/xenstored/logging.ml b/tools/ocaml/xenstored/logging.ml
--- a/tools/ocaml/xenstored/logging.ml
+++ b/tools/ocaml/xenstored/logging.ml
@@ -117,6 +117,9 @@ let init_xenstored_log () =
 			make_logger 
 				!xenstored_log_file !xenstored_log_nb_files !xenstored_log_nb_lines
 				!xenstored_log_nb_chars ignore in
+		let date = string_of_date() in
+		logger.write ("[%s|%5s|%s] Xen Storage Daemon, version %d.%d") date "" "startup"
+		  Define.xenstored_major Define.xenstored_minor;
 		xenstored_logger := Some logger
 
 let xenstored_logging level key (fmt: (_,_,_,_) format4) =
diff --git a/tools/ocaml/xenstored/xenstored.ml b/tools/ocaml/xenstored/xenstored.ml
--- a/tools/ocaml/xenstored/xenstored.ml
+++ b/tools/ocaml/xenstored/xenstored.ml
@@ -284,9 +284,6 @@ let _ =
 		Logging.init_access_log post_rotate
 	end;
 
-	info "Xen Storage Daemon, version %d.%d"
-	     Define.xenstored_major Define.xenstored_minor;
-
 	let spec_fds =
 		(match rw_sock with None -> [] | Some x -> [ x ]) @
 		(match ro_sock with None -> [] | Some x -> [ x ]) @

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 17:09:19 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 17:09:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZ3we-00070V-RG; Fri, 09 Dec 2011 17:09:12 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RZ3wd-0006zj-MT
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 17:09:11 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1323450492!6807852!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMTkxNzY=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22493 invoked from network); 9 Dec 2011 17:08:21 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 17:08:21 -0000
X-IronPort-AV: E=Sophos;i="4.71,327,1320642000"; d="scan'208";a="173585789"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 12:08:21 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 12:08:21 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pB9H8J6R009524;	Fri, 9 Dec 2011 09:08:19 -0800
MIME-Version: 1.0
X-Mercurial-Node: c2fbf133c235c023769640fdb24d84462a6b36ec
Message-ID: <c2fbf133c235c0237696.1323450498@cosworth.uk.xensource.com>
In-Reply-To: <1323450299.20077.84.camel@zakaz.uk.xensource.com>
References: <1323450299.20077.84.camel@zakaz.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 9 Dec 2011 17:08:18 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com, Olaf Hering <olaf@aepfle.de>,
	Vincent Hanquez <Vincent.Hanquez@eu.citrix.com>,
	Jonathan Ludlam <Jonathan.Ludlam@eu.citrix.com>, konrad.wilk@oracle.com
Subject: [Xen-devel] [PATCH] oxenstored: Always log something at start of
 day (if logging enabled at all)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1323450179 0
# Node ID c2fbf133c235c023769640fdb24d84462a6b36ec
# Parent  91415c125c676d9e87d9939bfecdd1a4a0b2edfa
oxenstored: Always log something at start of day (if logging enabled at all)

Otherwise at the default level we rarely log anything at all.

A completely empty log file is a good sign, but only if you know you are
looking in the right place...

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff --git a/tools/ocaml/xenstored/logging.ml b/tools/ocaml/xenstored/logging.ml
--- a/tools/ocaml/xenstored/logging.ml
+++ b/tools/ocaml/xenstored/logging.ml
@@ -117,6 +117,9 @@ let init_xenstored_log () =
 			make_logger 
 				!xenstored_log_file !xenstored_log_nb_files !xenstored_log_nb_lines
 				!xenstored_log_nb_chars ignore in
+		let date = string_of_date() in
+		logger.write ("[%s|%5s|%s] Xen Storage Daemon, version %d.%d") date "" "startup"
+		  Define.xenstored_major Define.xenstored_minor;
 		xenstored_logger := Some logger
 
 let xenstored_logging level key (fmt: (_,_,_,_) format4) =
diff --git a/tools/ocaml/xenstored/xenstored.ml b/tools/ocaml/xenstored/xenstored.ml
--- a/tools/ocaml/xenstored/xenstored.ml
+++ b/tools/ocaml/xenstored/xenstored.ml
@@ -284,9 +284,6 @@ let _ =
 		Logging.init_access_log post_rotate
 	end;
 
-	info "Xen Storage Daemon, version %d.%d"
-	     Define.xenstored_major Define.xenstored_minor;
-
 	let spec_fds =
 		(match rw_sock with None -> [] | Some x -> [ x ]) @
 		(match ro_sock with None -> [] | Some x -> [ x ]) @

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 17:12:16 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 17:12:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZ3zS-0007Nb-Fb; Fri, 09 Dec 2011 17:12:06 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RZ3zR-0007Mu-Iv
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 17:12:05 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1323450676!6282095!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI2MQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11593 invoked from network); 9 Dec 2011 17:11:16 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 17:11:16 -0000
X-IronPort-AV: E=Sophos;i="4.71,327,1320624000"; 
   d="scan'208";a="9390439"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 17:11:16 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 9 Dec 2011
	17:11:15 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Date: Fri, 9 Dec 2011 17:11:12 +0000
In-Reply-To: <20111209165111.GA24038@aepfle.de>
References: <patchbomb.1323448640@cosworth.uk.xensource.com>
	<3b7ac401f144206c3044.1323448644@cosworth.uk.xensource.com>
	<20111209165111.GA24038@aepfle.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323450675.20077.89.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Vincent Hanquez <Vincent.Hanquez@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Ian
	Jackson <Ian.Jackson@eu.citrix.com>,
	Jonathan Ludlam <Jonathan.Ludlam@eu.citrix.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH 4 of 4] Linux/xencommons: Use oxenstored by
 default when available
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2011-12-09 at 16:51 +0000, Olaf Hering wrote:
> On Fri, Dec 09, Ian Campbell wrote:
> 
> > # HG changeset patch
> > # User Ian Campbell <ian.campbell@citrix.com>
> > # Date 1323448636 0
> > # Node ID 3b7ac401f144206c30440fbb41c74b13fa20b8cb
> > # Parent  74f94e15bfe1dad412d0342aeabdbd895657f54f
> > Linux/xencommons: Use oxenstored by default when available
> 
> Assuming this has been tested:

I've been running with it for quite a while. Perhaps more importantly
XenServer has been using it since, well, since I can't remember when but
it was several years ago when they switched and they pound it pretty
hard in their testing. Harder than C xenstored could cope with which is
why this one got written...

Another thing I forgot to mention is that by default the database is
non-persistent and held in RAM, so no need for hacks like putting the db
file on a tmpfs.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 17:12:16 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 17:12:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZ3zS-0007Nb-Fb; Fri, 09 Dec 2011 17:12:06 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RZ3zR-0007Mu-Iv
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 17:12:05 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1323450676!6282095!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI2MQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11593 invoked from network); 9 Dec 2011 17:11:16 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 17:11:16 -0000
X-IronPort-AV: E=Sophos;i="4.71,327,1320624000"; 
   d="scan'208";a="9390439"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 17:11:16 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 9 Dec 2011
	17:11:15 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Date: Fri, 9 Dec 2011 17:11:12 +0000
In-Reply-To: <20111209165111.GA24038@aepfle.de>
References: <patchbomb.1323448640@cosworth.uk.xensource.com>
	<3b7ac401f144206c3044.1323448644@cosworth.uk.xensource.com>
	<20111209165111.GA24038@aepfle.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323450675.20077.89.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Vincent Hanquez <Vincent.Hanquez@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Ian
	Jackson <Ian.Jackson@eu.citrix.com>,
	Jonathan Ludlam <Jonathan.Ludlam@eu.citrix.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH 4 of 4] Linux/xencommons: Use oxenstored by
 default when available
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2011-12-09 at 16:51 +0000, Olaf Hering wrote:
> On Fri, Dec 09, Ian Campbell wrote:
> 
> > # HG changeset patch
> > # User Ian Campbell <ian.campbell@citrix.com>
> > # Date 1323448636 0
> > # Node ID 3b7ac401f144206c30440fbb41c74b13fa20b8cb
> > # Parent  74f94e15bfe1dad412d0342aeabdbd895657f54f
> > Linux/xencommons: Use oxenstored by default when available
> 
> Assuming this has been tested:

I've been running with it for quite a while. Perhaps more importantly
XenServer has been using it since, well, since I can't remember when but
it was several years ago when they switched and they pound it pretty
hard in their testing. Harder than C xenstored could cope with which is
why this one got written...

Another thing I forgot to mention is that by default the database is
non-persistent and held in RAM, so no need for hacks like putting the db
file on a tmpfs.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 17:19:23 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 17:19:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZ46J-0007j3-HB; Fri, 09 Dec 2011 17:19:11 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RZ46H-0007ij-63
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 17:19:09 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1323451061!47259569!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI2MQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27210 invoked from network); 9 Dec 2011 17:17:41 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 17:17:41 -0000
X-IronPort-AV: E=Sophos;i="4.71,327,1320624000"; 
   d="scan'208";a="9390550"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 17:18:00 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 17:17:59 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RZ459-00026w-Hh; Fri, 09 Dec 2011 17:17:59 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RZ459-0005Nq-Gw;
	Fri, 09 Dec 2011 17:17:59 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20194.17095.512495.93972@mariner.uk.xensource.com>
Date: Fri, 9 Dec 2011 17:17:59 +0000
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
In-Reply-To: <alpine.DEB.2.00.1112091629340.3517@kaball-desktop>
References: <1323108621-22654-1-git-send-email-ian.jackson@eu.citrix.com>
	<1323108621-22654-15-git-send-email-ian.jackson@eu.citrix.com>
	<alpine.DEB.2.00.1112091504060.3517@kaball-desktop>
	<20194.13560.873396.700831@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1112091629340.3517@kaball-desktop>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 14/15] libxl: New API for providing OS
 events to libxl
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Stefano Stabellini writes ("Re: [Xen-devel] [PATCH 14/15] libxl: New API for providing OS events to libxl"):
> On Fri, 9 Dec 2011, Ian Jackson wrote:
> > The alternative, repeating the declaration, violates the principle
> > that things should be said (and defined) in the code if that's
> > possible, rather than having the primary reference be a comment.  It
> > also violates the principle of trying to avoid putting the same
> > information in two places.
> 
> I would prefer having a brief explanation of what the parameters are
> before the function.  At least a few times this what my eyes where
> looking for reading this patch.

The parameters are listed in the function prototype!  That's what the
function prototype is!  The very first thing you should be reading is
the function prototype.

If by "what they are" you mean you want to know what they mean, then
that is why we give them names rather than just using anonymous
parameters.

Or are you saying that you want something like this:

  int (*fd_register)(void *user, int fd, void **for_app_registration_out,
                     short events, void *for_libxl);
    /* @fd@  the file descriptor
     ...

This is pointless boilerplate.  Obviously "int fd" is a file
descriptor and it doesn't help to write it out in English as well
as C.

This style also encourages formulaic descriptions like this:
     * @reg@  application's registration token (out parameter)

> See for example arch/x86/include/asm/paravirt_types.h in the linux
> kernel: the long description of the MACROs is before the MACROs.

Macros are different because they don't have prototypes, just
definitions.  Nontrivial macros often need a comment beforehand to
serve in place of the function prototype.

You'll see that in general my macros have the comment beforehand, for
example:

   /*
    * Inserts "elm_new" into the sorted list "head".
    *
    * "elm_search" must be a loop search variable of the same type as
    * "elm_new".  "new_after_search_p" must be an expression which is
    * true iff the element "elm_new" sorts after the element
    * "elm_search".
    *
    * "search_body" can be empty, or some declaration(s) and statement(s)
    * needed for "new_after_search_p".
    */
   #define LIBXL_TAILQ_INSERT_SORTED(head, entry, elm_new, elm_search,     \
                                     search_body, new_after_search_p)      \
       do {                                                                \


> > > > +typedef struct libxl_osevent_hooks {
> > > > +  int (*fd_register)(void *uselibxl_event_check.r, int fd, void **for_app_registration_out,
> > > > +                     short events, void *for_libxl);
> > > > +  int (*fd_modify)(void *user, int fd, void **for_app_registration_update,
> > > > +                   short events);
> > > > +  void (*fd_deregister)(void *user, int fd, void *for_app_registration);
> > > > +  int (*timeout_register)(void *user, void **for_app_registration_out,
> > > > +                          struct timeval abs, void *for_libxl);
> > > > +  int (*timeout_modify)(void *user, void **for_app_registration_update,
> > > > +                         struct timeval abs);
> > > > +  void (*timeout_deregister)(void *user, void *for_app_registration_io);
> > > > +} libxl_osevent_hooks;
> > > > +
> > > > +void libxl_osevent_register_hooks(libxl_ctx *ctx,
> > > > +                                  const libxl_osevent_hooks *hooks,
> > > > +                                  void *user);
> > ...
> > > while this description is very verbose, it doesn't contain informations
> > > on:
> > > 
> > > - what is void *user;
> > 
> > I would have thought this was obvious.  Every situation in C where a
> > function pointer is passed needs also to pass a void* (or the
> > equivalent) so that some context or dynamic information from the
> > original caller can be passed to the inner called function.  So user
> > is stored by libxl and passed to the hooks.
> 
> It might be obvious but it is not written anywhere. Considering the
> level of details you went through in the following paragraph, I am
> surprised that you left to guessing what this parameter is for. Better
> be pedantic than leaving things to imagination.

All of the details in that paragraph are there because they not
otherwise clear.  In particular, there are many semantic details which
need to be covered.  It's precisely because there are so many
important details to state, that it's not helpful to restate in
sentences in comments things which have already been stated in the
choice of function and parameter names.

But I can add a sentence about "user" if that would help:

   *
   * The value of user is stored by libxl and passed to the callbacks.

Would that address this objection ?

I definitely don't want to add a sentence next to "timeout_register"
saying "this is for libxl to register a timeout" and another sentence
saying that the "struct timeval abs" is the absolute time at which the
timeout should fire and another sentence saying that "int fd" is the
file descriptor and on on.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 17:19:23 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 17:19:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZ46J-0007j3-HB; Fri, 09 Dec 2011 17:19:11 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RZ46H-0007ij-63
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 17:19:09 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1323451061!47259569!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI2MQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27210 invoked from network); 9 Dec 2011 17:17:41 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 17:17:41 -0000
X-IronPort-AV: E=Sophos;i="4.71,327,1320624000"; 
   d="scan'208";a="9390550"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 17:18:00 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 17:17:59 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RZ459-00026w-Hh; Fri, 09 Dec 2011 17:17:59 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RZ459-0005Nq-Gw;
	Fri, 09 Dec 2011 17:17:59 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20194.17095.512495.93972@mariner.uk.xensource.com>
Date: Fri, 9 Dec 2011 17:17:59 +0000
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
In-Reply-To: <alpine.DEB.2.00.1112091629340.3517@kaball-desktop>
References: <1323108621-22654-1-git-send-email-ian.jackson@eu.citrix.com>
	<1323108621-22654-15-git-send-email-ian.jackson@eu.citrix.com>
	<alpine.DEB.2.00.1112091504060.3517@kaball-desktop>
	<20194.13560.873396.700831@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1112091629340.3517@kaball-desktop>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 14/15] libxl: New API for providing OS
 events to libxl
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Stefano Stabellini writes ("Re: [Xen-devel] [PATCH 14/15] libxl: New API for providing OS events to libxl"):
> On Fri, 9 Dec 2011, Ian Jackson wrote:
> > The alternative, repeating the declaration, violates the principle
> > that things should be said (and defined) in the code if that's
> > possible, rather than having the primary reference be a comment.  It
> > also violates the principle of trying to avoid putting the same
> > information in two places.
> 
> I would prefer having a brief explanation of what the parameters are
> before the function.  At least a few times this what my eyes where
> looking for reading this patch.

The parameters are listed in the function prototype!  That's what the
function prototype is!  The very first thing you should be reading is
the function prototype.

If by "what they are" you mean you want to know what they mean, then
that is why we give them names rather than just using anonymous
parameters.

Or are you saying that you want something like this:

  int (*fd_register)(void *user, int fd, void **for_app_registration_out,
                     short events, void *for_libxl);
    /* @fd@  the file descriptor
     ...

This is pointless boilerplate.  Obviously "int fd" is a file
descriptor and it doesn't help to write it out in English as well
as C.

This style also encourages formulaic descriptions like this:
     * @reg@  application's registration token (out parameter)

> See for example arch/x86/include/asm/paravirt_types.h in the linux
> kernel: the long description of the MACROs is before the MACROs.

Macros are different because they don't have prototypes, just
definitions.  Nontrivial macros often need a comment beforehand to
serve in place of the function prototype.

You'll see that in general my macros have the comment beforehand, for
example:

   /*
    * Inserts "elm_new" into the sorted list "head".
    *
    * "elm_search" must be a loop search variable of the same type as
    * "elm_new".  "new_after_search_p" must be an expression which is
    * true iff the element "elm_new" sorts after the element
    * "elm_search".
    *
    * "search_body" can be empty, or some declaration(s) and statement(s)
    * needed for "new_after_search_p".
    */
   #define LIBXL_TAILQ_INSERT_SORTED(head, entry, elm_new, elm_search,     \
                                     search_body, new_after_search_p)      \
       do {                                                                \


> > > > +typedef struct libxl_osevent_hooks {
> > > > +  int (*fd_register)(void *uselibxl_event_check.r, int fd, void **for_app_registration_out,
> > > > +                     short events, void *for_libxl);
> > > > +  int (*fd_modify)(void *user, int fd, void **for_app_registration_update,
> > > > +                   short events);
> > > > +  void (*fd_deregister)(void *user, int fd, void *for_app_registration);
> > > > +  int (*timeout_register)(void *user, void **for_app_registration_out,
> > > > +                          struct timeval abs, void *for_libxl);
> > > > +  int (*timeout_modify)(void *user, void **for_app_registration_update,
> > > > +                         struct timeval abs);
> > > > +  void (*timeout_deregister)(void *user, void *for_app_registration_io);
> > > > +} libxl_osevent_hooks;
> > > > +
> > > > +void libxl_osevent_register_hooks(libxl_ctx *ctx,
> > > > +                                  const libxl_osevent_hooks *hooks,
> > > > +                                  void *user);
> > ...
> > > while this description is very verbose, it doesn't contain informations
> > > on:
> > > 
> > > - what is void *user;
> > 
> > I would have thought this was obvious.  Every situation in C where a
> > function pointer is passed needs also to pass a void* (or the
> > equivalent) so that some context or dynamic information from the
> > original caller can be passed to the inner called function.  So user
> > is stored by libxl and passed to the hooks.
> 
> It might be obvious but it is not written anywhere. Considering the
> level of details you went through in the following paragraph, I am
> surprised that you left to guessing what this parameter is for. Better
> be pedantic than leaving things to imagination.

All of the details in that paragraph are there because they not
otherwise clear.  In particular, there are many semantic details which
need to be covered.  It's precisely because there are so many
important details to state, that it's not helpful to restate in
sentences in comments things which have already been stated in the
choice of function and parameter names.

But I can add a sentence about "user" if that would help:

   *
   * The value of user is stored by libxl and passed to the callbacks.

Would that address this objection ?

I definitely don't want to add a sentence next to "timeout_register"
saying "this is for libxl to register a timeout" and another sentence
saying that the "struct timeval abs" is the absolute time at which the
timeout should fire and another sentence saying that "int fd" is the
file descriptor and on on.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 17:33:33 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 17:33:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZ4Jo-000832-Ut; Fri, 09 Dec 2011 17:33:08 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RZ4Jn-00082b-H9
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 17:33:07 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1323451937!6828360!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI2MQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21163 invoked from network); 9 Dec 2011 17:32:17 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 17:32:17 -0000
X-IronPort-AV: E=Sophos;i="4.71,327,1320624000"; 
   d="scan'208";a="9390838"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 17:32:17 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 17:32:17 +0000
Date: Fri, 9 Dec 2011 17:32:43 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1323450675.20077.89.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1112091731500.3517@kaball-desktop>
References: <patchbomb.1323448640@cosworth.uk.xensource.com>
	<3b7ac401f144206c3044.1323448644@cosworth.uk.xensource.com>
	<20111209165111.GA24038@aepfle.de>
	<1323450675.20077.89.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Olaf Hering <olaf@aepfle.de>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	Vincent Hanquez <Vincent.Hanquez@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Jonathan Ludlam <Jonathan.Ludlam@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 4 of 4] Linux/xencommons: Use oxenstored by
 default when available
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 9 Dec 2011, Ian Campbell wrote:
> On Fri, 2011-12-09 at 16:51 +0000, Olaf Hering wrote:
> > On Fri, Dec 09, Ian Campbell wrote:
> > 
> > > # HG changeset patch
> > > # User Ian Campbell <ian.campbell@citrix.com>
> > > # Date 1323448636 0
> > > # Node ID 3b7ac401f144206c30440fbb41c74b13fa20b8cb
> > > # Parent  74f94e15bfe1dad412d0342aeabdbd895657f54f
> > > Linux/xencommons: Use oxenstored by default when available
> > 
> > Assuming this has been tested:
> 
> I've been running with it for quite a while. Perhaps more importantly
> XenServer has been using it since, well, since I can't remember when but
> it was several years ago when they switched and they pound it pretty
> hard in their testing. Harder than C xenstored could cope with which is
> why this one got written...

However is our version up in sync with theirs I wonder... Are we missing
any important bug fix?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 17:33:33 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 17:33:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZ4Jo-000832-Ut; Fri, 09 Dec 2011 17:33:08 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RZ4Jn-00082b-H9
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 17:33:07 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1323451937!6828360!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI2MQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21163 invoked from network); 9 Dec 2011 17:32:17 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 17:32:17 -0000
X-IronPort-AV: E=Sophos;i="4.71,327,1320624000"; 
   d="scan'208";a="9390838"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 17:32:17 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 17:32:17 +0000
Date: Fri, 9 Dec 2011 17:32:43 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1323450675.20077.89.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1112091731500.3517@kaball-desktop>
References: <patchbomb.1323448640@cosworth.uk.xensource.com>
	<3b7ac401f144206c3044.1323448644@cosworth.uk.xensource.com>
	<20111209165111.GA24038@aepfle.de>
	<1323450675.20077.89.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Olaf Hering <olaf@aepfle.de>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	Vincent Hanquez <Vincent.Hanquez@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Jonathan Ludlam <Jonathan.Ludlam@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 4 of 4] Linux/xencommons: Use oxenstored by
 default when available
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 9 Dec 2011, Ian Campbell wrote:
> On Fri, 2011-12-09 at 16:51 +0000, Olaf Hering wrote:
> > On Fri, Dec 09, Ian Campbell wrote:
> > 
> > > # HG changeset patch
> > > # User Ian Campbell <ian.campbell@citrix.com>
> > > # Date 1323448636 0
> > > # Node ID 3b7ac401f144206c30440fbb41c74b13fa20b8cb
> > > # Parent  74f94e15bfe1dad412d0342aeabdbd895657f54f
> > > Linux/xencommons: Use oxenstored by default when available
> > 
> > Assuming this has been tested:
> 
> I've been running with it for quite a while. Perhaps more importantly
> XenServer has been using it since, well, since I can't remember when but
> it was several years ago when they switched and they pound it pretty
> hard in their testing. Harder than C xenstored could cope with which is
> why this one got written...

However is our version up in sync with theirs I wonder... Are we missing
any important bug fix?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 17:35:35 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 17:35:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZ4Lv-0008Ac-Ga; Fri, 09 Dec 2011 17:35:19 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RZ4Lt-0008AP-R4
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 17:35:18 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-15.tower-216.messagelabs.com!1323452067!6828591!1
X-Originating-IP: [208.97.132.202]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4yMDIgPT4gMTYxMDY=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26564 invoked from network); 9 Dec 2011 17:34:28 -0000
Received: from caiajhbdccac.dreamhost.com (HELO homiemail-a21.g.dreamhost.com)
	(208.97.132.202) by server-15.tower-216.messagelabs.com with SMTP;
	9 Dec 2011 17:34:28 -0000
Received: from homiemail-a21.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTP id 6C69930006C;
	Fri,  9 Dec 2011 09:34:27 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=h4HGJP08bdqlsBU9Mo8JXYSl37jvlaVljiX9yafvvQva
	G7wxJsa5TueULTBErZzqtsSYhCQpi7QomuG6tS3Q6CrxgMurUUbzWYUqIknTfnbQ
	9Umlv2cUpW56rCWwSeqtRAyOwEp5KNL2pv2lWznOUwHCyMy0dnUolj8u8ojSYa8=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=Tf1K3PiRh/j9DBCs+1AsR7JTodA=; b=l28b0LBS
	GLpxi43pMF+3e6zGT1LRXvJMX9t5IkpPEuLPImylgvyr7S+ZS+KVybpBE0rrM2Af
	dWj0DKwi228q3RJKDMousxDa+UppQr1PIZ6j+JTLyDZS0ZG1N5Rk74plBkKCg0C8
	FAiedkefHWAuVPYJAYas5b8a6E1NpYE2V0o=
Received: from webmail.lagarcavilla.org (ahfbbjcaiaae.dreamhost.com
	[75.119.208.4]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTPA id 0CB41300061; 
	Fri,  9 Dec 2011 09:34:27 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP; Fri, 9 Dec 2011 09:34:27 -0800
Message-ID: <e26f44da411e2f7fbbc4a511f3cd6317.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <4EE2320F020000780006687F@nat28.tlf.novell.com>
References: <patchbomb.1323330435@xdev.gridcentric.ca>
	<ecf95feef9ac5a7d0b79.1323330447@xdev.gridcentric.ca>
	<20111208223822.GH87836@ocelot.phlegethon.org>
	<cba5ca07476cc5619c84113b26325886.squirrel@webmail.lagarcavilla.org>
	<4EE1DA1B020000780006663E@nat28.tlf.novell.com>
	<5721d3b3ef44aac4f864ea6a62e9c835.squirrel@webmail.lagarcavilla.org>
	<4EE2320F020000780006687F@nat28.tlf.novell.com>
Date: Fri, 9 Dec 2011 09:34:27 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Jan Beulich" <JBeulich@suse.com>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, ian.campbell@citrix.com,
	andres@gridcentric.ca, Tim Deegan <tim@xen.org>,
	keir.xen@gmail.com, ian.jackson@citrix.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 12 of 18] x86/mm: Make page_lock/unlock() in
 arch/x86/mm.c externally callable
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>>> On 09.12.11 at 15:53, "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
>>>> wrote:
>>>>>> On 09.12.11 at 03:54, "Andres Lagar-Cavilla"
>>>>>> <andres@lagarcavilla.org>
>>>>>> wrote:
>>>>>  At 02:47 -0500 on 08 Dec (1323312447), Andres Lagar-Cavilla wrote:
>>>>>> This is necessary for a new consumer of page_lock/unlock to follow
>>>>>> in
>>>>>> the series.
>>>>>>
>>>>>> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
>>>>>
>>>>> Nak, I'm afraid.
>>>>>
>>>>> These were OK as local functions but if they're going to be made
>>>>> generally visible, they need clear comments describing what this
>>>>> locking protects and what the discipline is for avoiding deadlocks.
>>>>
>>>> How about something along the lines of
>>>> "page_lock() is used for two purposes: pte serialization, and memory
>>>> sharing. All users of page lock for pte serialization live in mm.c,
>>>> use
>>>> it
>>>> to lock a page table page during pte updates, do not take other locks
>>>> within the critical section delimited by page_lock/unlock, and perform
>>>> no
>>>> nesting. All users of page lock for memory sharing live in
>>>> mm/mem_sharing.c. For memory sharing, nesting may happen when sharing
>>>> (and
>>>> locking) two pages -- deadlock is avoided by locking pages in
>>>> increasing
>>>> order. Memory sharing may take the p2m_lock within a page_lock/unlock
>>>> critical section. These two users (pte serialization and memory
>>>> sharing)
>>>> should never collide, as long as page table pages are properly
>>>> unshared
>>>> prior to updating."
>>>
>>> This would seem to me like very undesirable lock ordering - a very
>>> coarse (per-domain) lock taken inside a very fine grained (per-page)
>>> one.
>> I'm not sure I follow. Unshare would do its work, and then pte
>> serialization would start. The two pieces of code will be disjoint,
>> locking-wise.
>
> But your original mail said "Memory sharing may take the p2m_lock
> within a page_lock/unlock critical section" - see above. That's what
> I'm referring to.
>
>> Now it is true that during unshare we need to take the p2m lock to
>> change
>> the p2m entry. That's a very strong reason to make the p2m lock
>> fine-grained. But I need to start somewhere, so I'm breaking up the
>> global
>> shr_lock first.
>
> I don't really think that it'll be reasonable to split up the p2m lock.
>
>>>> Now those are all pretty words, but here are the two things I (think
>>>> I)
>>>> need to do:
>>>> - Prior to updating pte's, we do get_gfn on the page table page. We
>>>> should
>>>> be using get_gfn_unshare. Regardless of this patch. It's likely never
>>>> going to trigger an actual unshare, yet better safe than sorry.
>>>
>>> Does memory sharing work on pv domains at all?
>> Not. At. All :)
>>
>> I can _not_ add the unshare. It's idempotent to pv.
>
> Perhaps I should have clarified why I was asking: The pte handling is
> a pv-only thing, and if memory sharing is hvm only, then the two can't
> ever conflict.

Grant mapping uses the page_lock. I believe there is work trying to make
pv backends work in hvm?

If so, best to add unshare of the page table page now. Should a
free-wheeling user-space sharer try to share page table pages....

Andres
>
>>>> - I can wrap uses of page_lock in mm sharing in an "external"
>>>> order-enforcing construct from mm-locks.h. And use that to scream
>>>> deadlock
>>>> between page_lock and p2m_lock.
>>>>
>>>> The code that actually uses page_lock()s in the memory sharing code
>>>> can
>>>> be
>>>> found in "[PATCH] x86/mm: Eliminate global lock in mem sharing code".
>>>> It
>>>> already orders locking of individual pages in ascending order.
>>>
>>> It should be this patch to make the functions externally visible, not a
>>> separate one (or at the very minimum the two ought to be in the same
>>> series, back to back). Which is not to say that I'm fully convinced
>>> this
>>> is a good idea.
>> Whichever you prefer. I'm of the mind of making shorter patches when
>> possible, that do one thing, to ease readability. But I can collapse the
>> two.
>
> In quite a few (recent) cases your patches did something where the user
> of the change wasn't obvious at all (in some cases - I tried to point
> these
> out - there was no user even at the end of a series). While I agree that
> shorter patches are easier to review, trivial changes like the one here
> should imo really be logically grouped with what requires them.
>
> Jan
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 17:35:35 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 17:35:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZ4Lv-0008Ac-Ga; Fri, 09 Dec 2011 17:35:19 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RZ4Lt-0008AP-R4
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 17:35:18 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-15.tower-216.messagelabs.com!1323452067!6828591!1
X-Originating-IP: [208.97.132.202]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4yMDIgPT4gMTYxMDY=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26564 invoked from network); 9 Dec 2011 17:34:28 -0000
Received: from caiajhbdccac.dreamhost.com (HELO homiemail-a21.g.dreamhost.com)
	(208.97.132.202) by server-15.tower-216.messagelabs.com with SMTP;
	9 Dec 2011 17:34:28 -0000
Received: from homiemail-a21.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTP id 6C69930006C;
	Fri,  9 Dec 2011 09:34:27 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=h4HGJP08bdqlsBU9Mo8JXYSl37jvlaVljiX9yafvvQva
	G7wxJsa5TueULTBErZzqtsSYhCQpi7QomuG6tS3Q6CrxgMurUUbzWYUqIknTfnbQ
	9Umlv2cUpW56rCWwSeqtRAyOwEp5KNL2pv2lWznOUwHCyMy0dnUolj8u8ojSYa8=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=Tf1K3PiRh/j9DBCs+1AsR7JTodA=; b=l28b0LBS
	GLpxi43pMF+3e6zGT1LRXvJMX9t5IkpPEuLPImylgvyr7S+ZS+KVybpBE0rrM2Af
	dWj0DKwi228q3RJKDMousxDa+UppQr1PIZ6j+JTLyDZS0ZG1N5Rk74plBkKCg0C8
	FAiedkefHWAuVPYJAYas5b8a6E1NpYE2V0o=
Received: from webmail.lagarcavilla.org (ahfbbjcaiaae.dreamhost.com
	[75.119.208.4]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTPA id 0CB41300061; 
	Fri,  9 Dec 2011 09:34:27 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP; Fri, 9 Dec 2011 09:34:27 -0800
Message-ID: <e26f44da411e2f7fbbc4a511f3cd6317.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <4EE2320F020000780006687F@nat28.tlf.novell.com>
References: <patchbomb.1323330435@xdev.gridcentric.ca>
	<ecf95feef9ac5a7d0b79.1323330447@xdev.gridcentric.ca>
	<20111208223822.GH87836@ocelot.phlegethon.org>
	<cba5ca07476cc5619c84113b26325886.squirrel@webmail.lagarcavilla.org>
	<4EE1DA1B020000780006663E@nat28.tlf.novell.com>
	<5721d3b3ef44aac4f864ea6a62e9c835.squirrel@webmail.lagarcavilla.org>
	<4EE2320F020000780006687F@nat28.tlf.novell.com>
Date: Fri, 9 Dec 2011 09:34:27 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Jan Beulich" <JBeulich@suse.com>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, ian.campbell@citrix.com,
	andres@gridcentric.ca, Tim Deegan <tim@xen.org>,
	keir.xen@gmail.com, ian.jackson@citrix.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 12 of 18] x86/mm: Make page_lock/unlock() in
 arch/x86/mm.c externally callable
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>>> On 09.12.11 at 15:53, "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
>>>> wrote:
>>>>>> On 09.12.11 at 03:54, "Andres Lagar-Cavilla"
>>>>>> <andres@lagarcavilla.org>
>>>>>> wrote:
>>>>>  At 02:47 -0500 on 08 Dec (1323312447), Andres Lagar-Cavilla wrote:
>>>>>> This is necessary for a new consumer of page_lock/unlock to follow
>>>>>> in
>>>>>> the series.
>>>>>>
>>>>>> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
>>>>>
>>>>> Nak, I'm afraid.
>>>>>
>>>>> These were OK as local functions but if they're going to be made
>>>>> generally visible, they need clear comments describing what this
>>>>> locking protects and what the discipline is for avoiding deadlocks.
>>>>
>>>> How about something along the lines of
>>>> "page_lock() is used for two purposes: pte serialization, and memory
>>>> sharing. All users of page lock for pte serialization live in mm.c,
>>>> use
>>>> it
>>>> to lock a page table page during pte updates, do not take other locks
>>>> within the critical section delimited by page_lock/unlock, and perform
>>>> no
>>>> nesting. All users of page lock for memory sharing live in
>>>> mm/mem_sharing.c. For memory sharing, nesting may happen when sharing
>>>> (and
>>>> locking) two pages -- deadlock is avoided by locking pages in
>>>> increasing
>>>> order. Memory sharing may take the p2m_lock within a page_lock/unlock
>>>> critical section. These two users (pte serialization and memory
>>>> sharing)
>>>> should never collide, as long as page table pages are properly
>>>> unshared
>>>> prior to updating."
>>>
>>> This would seem to me like very undesirable lock ordering - a very
>>> coarse (per-domain) lock taken inside a very fine grained (per-page)
>>> one.
>> I'm not sure I follow. Unshare would do its work, and then pte
>> serialization would start. The two pieces of code will be disjoint,
>> locking-wise.
>
> But your original mail said "Memory sharing may take the p2m_lock
> within a page_lock/unlock critical section" - see above. That's what
> I'm referring to.
>
>> Now it is true that during unshare we need to take the p2m lock to
>> change
>> the p2m entry. That's a very strong reason to make the p2m lock
>> fine-grained. But I need to start somewhere, so I'm breaking up the
>> global
>> shr_lock first.
>
> I don't really think that it'll be reasonable to split up the p2m lock.
>
>>>> Now those are all pretty words, but here are the two things I (think
>>>> I)
>>>> need to do:
>>>> - Prior to updating pte's, we do get_gfn on the page table page. We
>>>> should
>>>> be using get_gfn_unshare. Regardless of this patch. It's likely never
>>>> going to trigger an actual unshare, yet better safe than sorry.
>>>
>>> Does memory sharing work on pv domains at all?
>> Not. At. All :)
>>
>> I can _not_ add the unshare. It's idempotent to pv.
>
> Perhaps I should have clarified why I was asking: The pte handling is
> a pv-only thing, and if memory sharing is hvm only, then the two can't
> ever conflict.

Grant mapping uses the page_lock. I believe there is work trying to make
pv backends work in hvm?

If so, best to add unshare of the page table page now. Should a
free-wheeling user-space sharer try to share page table pages....

Andres
>
>>>> - I can wrap uses of page_lock in mm sharing in an "external"
>>>> order-enforcing construct from mm-locks.h. And use that to scream
>>>> deadlock
>>>> between page_lock and p2m_lock.
>>>>
>>>> The code that actually uses page_lock()s in the memory sharing code
>>>> can
>>>> be
>>>> found in "[PATCH] x86/mm: Eliminate global lock in mem sharing code".
>>>> It
>>>> already orders locking of individual pages in ascending order.
>>>
>>> It should be this patch to make the functions externally visible, not a
>>> separate one (or at the very minimum the two ought to be in the same
>>> series, back to back). Which is not to say that I'm fully convinced
>>> this
>>> is a good idea.
>> Whichever you prefer. I'm of the mind of making shorter patches when
>> possible, that do one thing, to ease readability. But I can collapse the
>> two.
>
> In quite a few (recent) cases your patches did something where the user
> of the change wasn't obvious at all (in some cases - I tried to point
> these
> out - there was no user even at the end of a series). While I agree that
> shorter patches are easier to review, trivial changes like the one here
> should imo really be logically grouped with what requires them.
>
> Jan
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 17:40:13 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 17:40:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZ4QJ-0008Po-7p; Fri, 09 Dec 2011 17:39:51 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RZ4QH-0008PV-CT
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 17:39:49 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1323452339!2049067!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI2MQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31078 invoked from network); 9 Dec 2011 17:38:59 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 17:38:59 -0000
X-IronPort-AV: E=Sophos;i="4.71,327,1320624000"; 
   d="scan'208";a="9391073"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 17:38:59 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 9 Dec 2011
	17:38:59 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "annie.li@oracle.com" <annie.li@oracle.com>
Date: Fri, 9 Dec 2011 17:38:59 +0000
In-Reply-To: <1323430372-5503-1-git-send-email-annie.li@oracle.com>
References: <1323430321-5465-1-git-send-email-annie.li@oracle.com>
	<1323430372-5503-1-git-send-email-annie.li@oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323452339.20077.92.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "jeremy@goop.org" <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	"kurt.hackel@oracle.com" <kurt.hackel@oracle.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Paul Durrant <Paul.Durrant@citrix.com>
Subject: Re: [Xen-devel] [PATCH V3 1/2] xen/granttable: Support sub-page
	grants
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2011-12-09 at 11:32 +0000, annie.li@oracle.com wrote:
> -- They can't be used to map the page (so can only be used in a GNTTABOP_copy
>        hypercall).
>     -- It's possible to grant access with a finer granularity than whole pages.
>     -- Xen guarantees that they can be revoked quickly (a normal map grant can
>        only be revoked with the cooperation of the domain which has been granted
>        access).
> 
> Signed-off-by: Annie Li <annie.li@oracle.com>
> ---
>  drivers/xen/grant-table.c |   71 +++++++++++++++++++++++++++++++++++++++++++++
>  include/xen/grant_table.h |   13 ++++++++
>  2 files changed, 84 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
> index bd325fd..0ac16fa 100644
> --- a/drivers/xen/grant-table.c
> +++ b/drivers/xen/grant-table.c
> @@ -120,6 +120,16 @@ struct gnttab_ops {
>  	 * by bit operations.
>  	 */
>  	int (*query_foreign_access)(grant_ref_t);
> +	/*
> +	 * Grant a domain to access a range of bytes within the page referred by
> +	 * an available grant entry. First parameter is grant entry reference
> +	 * number, second one is id of grantee domain, third one is frame
> +	 * address of subpage grant, forth one is grant type and flag
> +	 * information, fifth one is offset of the range of bytes, and last one
> +	 * is length of bytes to be accessed.
> +	 */
> +	void (*update_subpage_entry)(grant_ref_t, domid_t, unsigned long, int,
> +				     unsigned, unsigned);

Please can you name the arguments here and then refer to them by name in
the comments instead of all this "First parameter", "second one" stuff.

Similarly for the existing comments sorry I didn't notice this in
previous review.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 17:40:13 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 17:40:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZ4QJ-0008Po-7p; Fri, 09 Dec 2011 17:39:51 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RZ4QH-0008PV-CT
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 17:39:49 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1323452339!2049067!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI2MQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31078 invoked from network); 9 Dec 2011 17:38:59 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 17:38:59 -0000
X-IronPort-AV: E=Sophos;i="4.71,327,1320624000"; 
   d="scan'208";a="9391073"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 17:38:59 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 9 Dec 2011
	17:38:59 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "annie.li@oracle.com" <annie.li@oracle.com>
Date: Fri, 9 Dec 2011 17:38:59 +0000
In-Reply-To: <1323430372-5503-1-git-send-email-annie.li@oracle.com>
References: <1323430321-5465-1-git-send-email-annie.li@oracle.com>
	<1323430372-5503-1-git-send-email-annie.li@oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323452339.20077.92.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "jeremy@goop.org" <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	"kurt.hackel@oracle.com" <kurt.hackel@oracle.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Paul Durrant <Paul.Durrant@citrix.com>
Subject: Re: [Xen-devel] [PATCH V3 1/2] xen/granttable: Support sub-page
	grants
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2011-12-09 at 11:32 +0000, annie.li@oracle.com wrote:
> -- They can't be used to map the page (so can only be used in a GNTTABOP_copy
>        hypercall).
>     -- It's possible to grant access with a finer granularity than whole pages.
>     -- Xen guarantees that they can be revoked quickly (a normal map grant can
>        only be revoked with the cooperation of the domain which has been granted
>        access).
> 
> Signed-off-by: Annie Li <annie.li@oracle.com>
> ---
>  drivers/xen/grant-table.c |   71 +++++++++++++++++++++++++++++++++++++++++++++
>  include/xen/grant_table.h |   13 ++++++++
>  2 files changed, 84 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
> index bd325fd..0ac16fa 100644
> --- a/drivers/xen/grant-table.c
> +++ b/drivers/xen/grant-table.c
> @@ -120,6 +120,16 @@ struct gnttab_ops {
>  	 * by bit operations.
>  	 */
>  	int (*query_foreign_access)(grant_ref_t);
> +	/*
> +	 * Grant a domain to access a range of bytes within the page referred by
> +	 * an available grant entry. First parameter is grant entry reference
> +	 * number, second one is id of grantee domain, third one is frame
> +	 * address of subpage grant, forth one is grant type and flag
> +	 * information, fifth one is offset of the range of bytes, and last one
> +	 * is length of bytes to be accessed.
> +	 */
> +	void (*update_subpage_entry)(grant_ref_t, domid_t, unsigned long, int,
> +				     unsigned, unsigned);

Please can you name the arguments here and then refer to them by name in
the comments instead of all this "First parameter", "second one" stuff.

Similarly for the existing comments sorry I didn't notice this in
previous review.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 18:13:20 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 18:13:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZ4w7-0000NO-5K; Fri, 09 Dec 2011 18:12:43 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RZ4w6-0000NJ-9M
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 18:12:42 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1323454312!7485485!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI2MQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18345 invoked from network); 9 Dec 2011 18:11:52 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 18:11:52 -0000
X-IronPort-AV: E=Sophos;i="4.71,327,1320624000"; 
   d="scan'208";a="9391519"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 18:11:52 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 18:11:52 +0000
Date: Fri, 9 Dec 2011 18:12:29 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
In-Reply-To: <20194.17095.512495.93972@mariner.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1112091730250.3517@kaball-desktop>
References: <1323108621-22654-1-git-send-email-ian.jackson@eu.citrix.com>
	<1323108621-22654-15-git-send-email-ian.jackson@eu.citrix.com>
	<alpine.DEB.2.00.1112091504060.3517@kaball-desktop>
	<20194.13560.873396.700831@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1112091629340.3517@kaball-desktop>
	<20194.17095.512495.93972@mariner.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 14/15] libxl: New API for providing OS
 events to libxl
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 9 Dec 2011, Ian Jackson wrote:
> All of the details in that paragraph are there because they not
> otherwise clear.  In particular, there are many semantic details which
> need to be covered.  It's precisely because there are so many
> important details to state, that it's not helpful to restate in
> sentences in comments things which have already been stated in the
> choice of function and parameter names.
> 
> But I can add a sentence about "user" if that would help:
> 
>    *
>    * The value of user is stored by libxl and passed to the callbacks.
> 
> Would that address this objection ?

Yes, that would help.

Maybe something similar for the parameters of the functions in
libxl_osevent_hooks, in particular for_app_registration_update.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 18:13:20 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 18:13:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZ4w7-0000NO-5K; Fri, 09 Dec 2011 18:12:43 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RZ4w6-0000NJ-9M
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 18:12:42 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1323454312!7485485!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI2MQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18345 invoked from network); 9 Dec 2011 18:11:52 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 18:11:52 -0000
X-IronPort-AV: E=Sophos;i="4.71,327,1320624000"; 
   d="scan'208";a="9391519"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 18:11:52 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 18:11:52 +0000
Date: Fri, 9 Dec 2011 18:12:29 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
In-Reply-To: <20194.17095.512495.93972@mariner.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1112091730250.3517@kaball-desktop>
References: <1323108621-22654-1-git-send-email-ian.jackson@eu.citrix.com>
	<1323108621-22654-15-git-send-email-ian.jackson@eu.citrix.com>
	<alpine.DEB.2.00.1112091504060.3517@kaball-desktop>
	<20194.13560.873396.700831@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1112091629340.3517@kaball-desktop>
	<20194.17095.512495.93972@mariner.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 14/15] libxl: New API for providing OS
 events to libxl
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 9 Dec 2011, Ian Jackson wrote:
> All of the details in that paragraph are there because they not
> otherwise clear.  In particular, there are many semantic details which
> need to be covered.  It's precisely because there are so many
> important details to state, that it's not helpful to restate in
> sentences in comments things which have already been stated in the
> choice of function and parameter names.
> 
> But I can add a sentence about "user" if that would help:
> 
>    *
>    * The value of user is stored by libxl and passed to the callbacks.
> 
> Would that address this objection ?

Yes, that would help.

Maybe something similar for the parameters of the functions in
libxl_osevent_hooks, in particular for_app_registration_update.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 18:15:30 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 18:15:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZ4yQ-0000SL-NB; Fri, 09 Dec 2011 18:15:06 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RZ4yP-0000S1-40
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 18:15:05 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1323454455!6746923!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI2MQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26675 invoked from network); 9 Dec 2011 18:14:15 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 18:14:15 -0000
X-IronPort-AV: E=Sophos;i="4.71,327,1320624000"; 
   d="scan'208";a="9391544"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 18:14:14 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 18:14:14 +0000
Date: Fri, 9 Dec 2011 18:14:52 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Jackson <ian.jackson@eu.citrix.com>
In-Reply-To: <1323108621-22654-16-git-send-email-ian.jackson@eu.citrix.com>
Message-ID: <alpine.DEB.2.00.1112091558300.3517@kaball-desktop>
References: <1323108621-22654-1-git-send-email-ian.jackson@eu.citrix.com>
	<1323108621-22654-16-git-send-email-ian.jackson@eu.citrix.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 15/15] libxl: New event generation API
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 5 Dec 2011, Ian Jackson wrote:
> +int libxl_evenable_domain_death(libxl_ctx *ctx, uint32_t domid,
> +                libxl_ev_user user, libxl_evgen_domain_death **evgen_out) {
> +    GC_INIT(ctx);
> +    libxl_evgen_domain_death *evg, *evg_search;
> +    int rc;
> +
> +    CTX_LOCK;
> +
> +    evg = malloc(sizeof(*evg));  if (!evg) { rc = ERROR_NOMEM; goto out; }
> +    memset(evg, 0, sizeof(*evg));
> +    evg->domid = domid;
> +    evg->user = user;
> +
> +    LIBXL_TAILQ_INSERT_SORTED(&ctx->death_list, entry, evg, evg_search, ,

is this a mistake?                                                        ^


> +void libxl__event_occurred(libxl__gc *gc, libxl_event *event) {
> +    if (CTX->event_hooks &&
> +        (CTX->event_hooks->event_occurs_mask & (1UL << event->type))) {
> +        /* libxl__free_all will call the callback, just before exit
> +         * from libxl.

Please extend this comment: "just before leaving libxl to go back to the
caller".  Also, even though libxl__free_all might be the right place to
call the callbacks, the name of the function (libxl__free_all) won't
completely reflect its behaviour anymore. Maybe we need to rename
libxl__free_all?


> +int libxl_event_check(libxl_ctx *ctx, libxl_event **event_r,
> +                      unsigned long typemask,
> +                      libxl_event_predicate *pred, void *pred_user) {
> +    GC_INIT(ctx);
> +    CTX_LOCK;
> +    int rc = event_check_unlocked(gc, event_r, typemask, pred, pred_user);
> +    CTX_UNLOCK;
> +    GC_FREE;
> +    return rc;
> +}

I think it is confusing to call event_check_*unlocked* from within
CTX_LOCK/CTX_UNLOCK.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 18:15:30 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 18:15:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZ4yQ-0000SL-NB; Fri, 09 Dec 2011 18:15:06 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RZ4yP-0000S1-40
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 18:15:05 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1323454455!6746923!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI2MQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26675 invoked from network); 9 Dec 2011 18:14:15 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 18:14:15 -0000
X-IronPort-AV: E=Sophos;i="4.71,327,1320624000"; 
   d="scan'208";a="9391544"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 18:14:14 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 18:14:14 +0000
Date: Fri, 9 Dec 2011 18:14:52 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Jackson <ian.jackson@eu.citrix.com>
In-Reply-To: <1323108621-22654-16-git-send-email-ian.jackson@eu.citrix.com>
Message-ID: <alpine.DEB.2.00.1112091558300.3517@kaball-desktop>
References: <1323108621-22654-1-git-send-email-ian.jackson@eu.citrix.com>
	<1323108621-22654-16-git-send-email-ian.jackson@eu.citrix.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 15/15] libxl: New event generation API
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 5 Dec 2011, Ian Jackson wrote:
> +int libxl_evenable_domain_death(libxl_ctx *ctx, uint32_t domid,
> +                libxl_ev_user user, libxl_evgen_domain_death **evgen_out) {
> +    GC_INIT(ctx);
> +    libxl_evgen_domain_death *evg, *evg_search;
> +    int rc;
> +
> +    CTX_LOCK;
> +
> +    evg = malloc(sizeof(*evg));  if (!evg) { rc = ERROR_NOMEM; goto out; }
> +    memset(evg, 0, sizeof(*evg));
> +    evg->domid = domid;
> +    evg->user = user;
> +
> +    LIBXL_TAILQ_INSERT_SORTED(&ctx->death_list, entry, evg, evg_search, ,

is this a mistake?                                                        ^


> +void libxl__event_occurred(libxl__gc *gc, libxl_event *event) {
> +    if (CTX->event_hooks &&
> +        (CTX->event_hooks->event_occurs_mask & (1UL << event->type))) {
> +        /* libxl__free_all will call the callback, just before exit
> +         * from libxl.

Please extend this comment: "just before leaving libxl to go back to the
caller".  Also, even though libxl__free_all might be the right place to
call the callbacks, the name of the function (libxl__free_all) won't
completely reflect its behaviour anymore. Maybe we need to rename
libxl__free_all?


> +int libxl_event_check(libxl_ctx *ctx, libxl_event **event_r,
> +                      unsigned long typemask,
> +                      libxl_event_predicate *pred, void *pred_user) {
> +    GC_INIT(ctx);
> +    CTX_LOCK;
> +    int rc = event_check_unlocked(gc, event_r, typemask, pred, pred_user);
> +    CTX_UNLOCK;
> +    GC_FREE;
> +    return rc;
> +}

I think it is confusing to call event_check_*unlocked* from within
CTX_LOCK/CTX_UNLOCK.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 18:48:51 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 18: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.xensource.com>)
	id 1RZ5UV-0000rn-U9; Fri, 09 Dec 2011 18:48:15 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <davem@davemloft.net>) id 1RZ5UT-0000rf-Rx
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 18:48:14 +0000
X-Env-Sender: davem@davemloft.net
X-Msg-Ref: server-13.tower-174.messagelabs.com!1323456442!4941750!1
X-Originating-IP: [198.137.202.13]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12613 invoked from network); 9 Dec 2011 18:47:23 -0000
Received: from shards.monkeyblade.net (HELO shards.monkeyblade.net)
	(198.137.202.13)
	by server-13.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 9 Dec 2011 18:47:23 -0000
Received: from localhost (cpe-66-65-61-233.nyc.res.rr.com [66.65.61.233])
	(authenticated bits=0)
	by shards.monkeyblade.net (8.14.4/8.14.4) with ESMTP id pB9IjEbv022459
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO);
	Fri, 9 Dec 2011 10:45:15 -0800
Date: Fri, 09 Dec 2011 13:45:14 -0500 (EST)
Message-Id: <20111209.134514.2071890208094978847.davem@davemloft.net>
To: lersek@redhat.com
From: David Miller <davem@davemloft.net>
In-Reply-To: <1323430738-3798-1-git-send-email-lersek@redhat.com>
References: <1323430738-3798-1-git-send-email-lersek@redhat.com>
X-Mailer: Mew version 6.4 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6
	(shards.monkeyblade.net [198.137.202.13]);
	Fri, 09 Dec 2011 10:45:17 -0800 (PST)
Cc: jeremy@goop.org, xen-devel@lists.xensource.com, ian.campbell@citrix.com,
	konrad.wilk@oracle.com, netdev@vger.kernel.org,
	linux-kernel@vger.kernel.org, virtualization@lists.linux-foundation.org
Subject: Re: [Xen-devel] [PATCH v3 REPOST] xen-netfront: delay gARP until
 backend switches to Connected
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Laszlo Ersek <lersek@redhat.com>
Date: Fri,  9 Dec 2011 12:38:58 +0100

> These two together provide complete ordering. Sub-condition (1) is
> satisfied by pvops commit 43223efd9bfd.

I don't see this commit in Linus's tree, so I doubt it's valid for
me to apply this as a bug fix to my 'net' tree since the precondition
pvops commit isn't upstream as far as I can tell.

Where did you intend me to apply this patch, and how did you expect
the dependent commit to make it's way into the tree so that this
fix is complete?

BTW, you should always explicitly specificy the answers to all the
questions in the previous paragraph, otherwise (like right now) we
go back and forth wasting time establishing these facts.

The way to say which tree the patch is intended for is to specify
it in the Subject like, f.e. "[PATCH net-next v3 REPOST] ..."


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 18:48:51 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 18: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.xensource.com>)
	id 1RZ5UV-0000rn-U9; Fri, 09 Dec 2011 18:48:15 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <davem@davemloft.net>) id 1RZ5UT-0000rf-Rx
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 18:48:14 +0000
X-Env-Sender: davem@davemloft.net
X-Msg-Ref: server-13.tower-174.messagelabs.com!1323456442!4941750!1
X-Originating-IP: [198.137.202.13]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12613 invoked from network); 9 Dec 2011 18:47:23 -0000
Received: from shards.monkeyblade.net (HELO shards.monkeyblade.net)
	(198.137.202.13)
	by server-13.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 9 Dec 2011 18:47:23 -0000
Received: from localhost (cpe-66-65-61-233.nyc.res.rr.com [66.65.61.233])
	(authenticated bits=0)
	by shards.monkeyblade.net (8.14.4/8.14.4) with ESMTP id pB9IjEbv022459
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO);
	Fri, 9 Dec 2011 10:45:15 -0800
Date: Fri, 09 Dec 2011 13:45:14 -0500 (EST)
Message-Id: <20111209.134514.2071890208094978847.davem@davemloft.net>
To: lersek@redhat.com
From: David Miller <davem@davemloft.net>
In-Reply-To: <1323430738-3798-1-git-send-email-lersek@redhat.com>
References: <1323430738-3798-1-git-send-email-lersek@redhat.com>
X-Mailer: Mew version 6.4 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6
	(shards.monkeyblade.net [198.137.202.13]);
	Fri, 09 Dec 2011 10:45:17 -0800 (PST)
Cc: jeremy@goop.org, xen-devel@lists.xensource.com, ian.campbell@citrix.com,
	konrad.wilk@oracle.com, netdev@vger.kernel.org,
	linux-kernel@vger.kernel.org, virtualization@lists.linux-foundation.org
Subject: Re: [Xen-devel] [PATCH v3 REPOST] xen-netfront: delay gARP until
 backend switches to Connected
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Laszlo Ersek <lersek@redhat.com>
Date: Fri,  9 Dec 2011 12:38:58 +0100

> These two together provide complete ordering. Sub-condition (1) is
> satisfied by pvops commit 43223efd9bfd.

I don't see this commit in Linus's tree, so I doubt it's valid for
me to apply this as a bug fix to my 'net' tree since the precondition
pvops commit isn't upstream as far as I can tell.

Where did you intend me to apply this patch, and how did you expect
the dependent commit to make it's way into the tree so that this
fix is complete?

BTW, you should always explicitly specificy the answers to all the
questions in the previous paragraph, otherwise (like right now) we
go back and forth wasting time establishing these facts.

The way to say which tree the patch is intended for is to specify
it in the Subject like, f.e. "[PATCH net-next v3 REPOST] ..."


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 18:50:00 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 18:50:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZ5Vh-0000uc-E0; Fri, 09 Dec 2011 18:49:29 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RZ5Vg-0000uX-Kx
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 18:49:28 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1323456485!47265886!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI2MQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16433 invoked from network); 9 Dec 2011 18:48:05 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 18:48:05 -0000
X-IronPort-AV: E=Sophos;i="4.71,327,1320624000"; 
   d="scan'208";a="9392081"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 18:48:43 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 18:48:43 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RZ5Ux-0002bT-Jq; Fri, 09 Dec 2011 18:48:43 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RZ5Ux-0000Bf-Is;
	Fri, 09 Dec 2011 18:48:43 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20194.22539.574524.956955@mariner.uk.xensource.com>
Date: Fri, 9 Dec 2011 18:48:43 +0000
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
In-Reply-To: <alpine.DEB.2.00.1112091558300.3517@kaball-desktop>
References: <1323108621-22654-1-git-send-email-ian.jackson@eu.citrix.com>
	<1323108621-22654-16-git-send-email-ian.jackson@eu.citrix.com>
	<alpine.DEB.2.00.1112091558300.3517@kaball-desktop>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 15/15] libxl: New event generation API
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Stefano Stabellini writes ("Re: [Xen-devel] [PATCH 15/15] libxl: New event generation API"):
> On Mon, 5 Dec 2011, Ian Jackson wrote:
> > +    LIBXL_TAILQ_INSERT_SORTED(&ctx->death_list, entry, evg, evg_search, ,
> 
> is this a mistake?                                                        ^

No.  It's a parameter to allow the macro's caller to introduce
variable declarations and arbitrary code into the search loop, for the
benefit of their predicate.  We don't need it here.

I've added   /*empty*/  in the empty parameter to avoid people
tripping over it.

> > +void libxl__event_occurred(libxl__gc *gc, libxl_event *event) {
> > +    if (CTX->event_hooks &&
> > +        (CTX->event_hooks->event_occurs_mask & (1UL << event->type))) {
> > +        /* libxl__free_all will call the callback, just before exit
> > +         * from libxl.
> 
> Please extend this comment: "just before leaving libxl to go back to the
> caller".  Also, even though libxl__free_all might be the right place to
> call the callbacks, the name of the function (libxl__free_all) won't
> completely reflect its behaviour anymore. Maybe we need to rename
> libxl__free_all?

Yes, I think you're probably right.  I'll add a patch to rename it to
libxl__gc_cleanup, which I think is the best name I can think of for
the moment.

> > +int libxl_event_check(libxl_ctx *ctx, libxl_event **event_r,
> > +                      unsigned long typemask,
> > +                      libxl_event_predicate *pred, void *pred_user) {
> > +    GC_INIT(ctx);
> > +    CTX_LOCK;
> > +    int rc = event_check_unlocked(gc, event_r, typemask, pred, pred_user);
> > +    CTX_UNLOCK;
> > +    GC_FREE;
> > +    return rc;
> > +}
> 
> I think it is confusing to call event_check_*unlocked* from within
> CTX_LOCK/CTX_UNLOCK.

I'm open to other suggestions for the name of these functions, but I
got the naming pattern from stdio.  From man getc_unlocked(3) on
squeeze:

 UNLOCKED_STDIO(3)          Linux Programmer's Manual         UNLOCKED_STDIO(3)
 ...
        int getc_unlocked(FILE *stream);
        int getchar_unlocked(void);
        int putc_unlocked(int c, FILE *stream);
 ...
 DESCRIPTION
        Each of these functions has the same behavior as its counterpart  with-
        out  the  "_unlocked" suffix, except that they do not use locking (they
        do not set locks themselves, and do not test for the presence of  locks
        set by others) and hence are thread-unsafe.  See flockfile(3).

Now Linux and Xen have a tendency, when they need a name for an
unlocked version of foo, to use the name _foo.  Obviously this is no
good in a userspace program and anyway I think it is a completely
ridiculous convention.  We need something much clearer.

foo_internal is a possibility but that merely suggests that the
GC_INIT has been done, and doesn't make it 100% clear that the caller
must already have done CTX_LOCK.

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 18:50:00 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 18:50:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZ5Vh-0000uc-E0; Fri, 09 Dec 2011 18:49:29 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RZ5Vg-0000uX-Kx
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 18:49:28 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1323456485!47265886!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI2MQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16433 invoked from network); 9 Dec 2011 18:48:05 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 18:48:05 -0000
X-IronPort-AV: E=Sophos;i="4.71,327,1320624000"; 
   d="scan'208";a="9392081"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 18:48:43 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 18:48:43 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RZ5Ux-0002bT-Jq; Fri, 09 Dec 2011 18:48:43 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RZ5Ux-0000Bf-Is;
	Fri, 09 Dec 2011 18:48:43 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20194.22539.574524.956955@mariner.uk.xensource.com>
Date: Fri, 9 Dec 2011 18:48:43 +0000
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
In-Reply-To: <alpine.DEB.2.00.1112091558300.3517@kaball-desktop>
References: <1323108621-22654-1-git-send-email-ian.jackson@eu.citrix.com>
	<1323108621-22654-16-git-send-email-ian.jackson@eu.citrix.com>
	<alpine.DEB.2.00.1112091558300.3517@kaball-desktop>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 15/15] libxl: New event generation API
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Stefano Stabellini writes ("Re: [Xen-devel] [PATCH 15/15] libxl: New event generation API"):
> On Mon, 5 Dec 2011, Ian Jackson wrote:
> > +    LIBXL_TAILQ_INSERT_SORTED(&ctx->death_list, entry, evg, evg_search, ,
> 
> is this a mistake?                                                        ^

No.  It's a parameter to allow the macro's caller to introduce
variable declarations and arbitrary code into the search loop, for the
benefit of their predicate.  We don't need it here.

I've added   /*empty*/  in the empty parameter to avoid people
tripping over it.

> > +void libxl__event_occurred(libxl__gc *gc, libxl_event *event) {
> > +    if (CTX->event_hooks &&
> > +        (CTX->event_hooks->event_occurs_mask & (1UL << event->type))) {
> > +        /* libxl__free_all will call the callback, just before exit
> > +         * from libxl.
> 
> Please extend this comment: "just before leaving libxl to go back to the
> caller".  Also, even though libxl__free_all might be the right place to
> call the callbacks, the name of the function (libxl__free_all) won't
> completely reflect its behaviour anymore. Maybe we need to rename
> libxl__free_all?

Yes, I think you're probably right.  I'll add a patch to rename it to
libxl__gc_cleanup, which I think is the best name I can think of for
the moment.

> > +int libxl_event_check(libxl_ctx *ctx, libxl_event **event_r,
> > +                      unsigned long typemask,
> > +                      libxl_event_predicate *pred, void *pred_user) {
> > +    GC_INIT(ctx);
> > +    CTX_LOCK;
> > +    int rc = event_check_unlocked(gc, event_r, typemask, pred, pred_user);
> > +    CTX_UNLOCK;
> > +    GC_FREE;
> > +    return rc;
> > +}
> 
> I think it is confusing to call event_check_*unlocked* from within
> CTX_LOCK/CTX_UNLOCK.

I'm open to other suggestions for the name of these functions, but I
got the naming pattern from stdio.  From man getc_unlocked(3) on
squeeze:

 UNLOCKED_STDIO(3)          Linux Programmer's Manual         UNLOCKED_STDIO(3)
 ...
        int getc_unlocked(FILE *stream);
        int getchar_unlocked(void);
        int putc_unlocked(int c, FILE *stream);
 ...
 DESCRIPTION
        Each of these functions has the same behavior as its counterpart  with-
        out  the  "_unlocked" suffix, except that they do not use locking (they
        do not set locks themselves, and do not test for the presence of  locks
        set by others) and hence are thread-unsafe.  See flockfile(3).

Now Linux and Xen have a tendency, when they need a name for an
unlocked version of foo, to use the name _foo.  Obviously this is no
good in a userspace program and anyway I think it is a completely
ridiculous convention.  We need something much clearer.

foo_internal is a possibility but that merely suggests that the
GC_INIT has been done, and doesn't make it 100% clear that the caller
must already have done CTX_LOCK.

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 18:55:50 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 18: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.xensource.com>)
	id 1RZ5be-0001E1-Eg; Fri, 09 Dec 2011 18:55:38 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RZ5bc-0001Aw-Kp
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 18:55:36 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1323456879!6616386!10
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI2MQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21380 invoked from network); 9 Dec 2011 18:54:46 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 18:54:46 -0000
X-IronPort-AV: E=Sophos;i="4.71,327,1320624000"; 
   d="scan'208";a="9392201"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 18:54:46 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 18:54:46 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RZ5ao-0002e9-BM; Fri, 09 Dec 2011 18:54:46 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RZ5ao-00040V-Aa;
	Fri, 09 Dec 2011 18:54:46 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Fri, 9 Dec 2011 18:54:28 +0000
Message-ID: <1323456877-15315-10-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1323456877-15315-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1323456877-15315-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 09/18] libxl: introduce lock in libxl_ctx
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This lock will be used to protect data structures which will be hung
off the libxl_ctx in subsequent patches.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl.c          |    6 ++++++
 tools/libxl/libxl_internal.h |   27 +++++++++++++++++++++++++++
 2 files changed, 33 insertions(+), 0 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index bc17b15..7488538 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -41,6 +41,7 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
 {
     libxl_ctx *ctx;
     struct stat stat_buf;
+    const pthread_mutex_t mutex_value = PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP;
 
     if (version != LIBXL_VERSION)
         return ERROR_VERSION;
@@ -54,6 +55,11 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
     memset(ctx, 0, sizeof(libxl_ctx));
     ctx->lg = lg;
 
+    /* This somewhat convoluted approach is needed because
+     * PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP is defined to be valid
+     * only as an initialiser, not as an expression. */
+    memcpy(&ctx->lock, &mutex_value, sizeof(ctx->lock));
+
     if ( stat(XENSTORE_PID_FILE, &stat_buf) != 0 ) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "Is xenstore daemon running?\n"
                      "failed to stat %s", XENSTORE_PID_FILE);
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index cda6fc1..41de6fd 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -23,6 +23,7 @@
 #include <stdarg.h>
 #include <stdlib.h>
 #include <string.h>
+#include <pthread.h>
 
 #include <xs.h>
 #include <xenctrl.h>
@@ -95,6 +96,18 @@ struct libxl__ctx {
     xc_interface *xch;
     struct xs_handle *xsh;
 
+    pthread_mutex_t lock; /* protects data structures hanging off the ctx */
+      /* Always use CTX_LOCK and CTX_UNLOCK to manipulate this.
+       *
+       * You may acquire this mutex recursively if it is convenient to
+       * do so.  You may not acquire this lock at the same time as any
+       * other lock.  If you need to call application code outside
+       * libxl (ie, a callback) with this lock held then it is
+       * necessaray to impose restrictions on the caller to maintain a
+       * proper lock hierarchy, and these restrictions must then be
+       * documented in the libxl public interface.
+       */
+
     /* for callers who reap children willy-nilly; caller must only
      * set this after libxl_init and before any other call - or
      * may leave them untouched */
@@ -668,6 +681,20 @@ libxl__device_model_version_running(libxl__gc *gc, uint32_t domid);
 #define CTX           libxl__gc_owner(gc)
 
 
+/* Locking functions.  See comment for "lock" member of libxl__ctx. */
+
+#define CTX_LOCK do {                                   \
+        int mutex_r = pthread_mutex_lock(&CTX->lock);   \
+        assert(!mutex_r);                               \
+    } while(0)
+
+#define CTX_UNLOCK do {                                 \
+        int mutex_r = pthread_mutex_unlock(&CTX->lock); \
+        assert(!mutex_r);                               \
+    } while(0)
+        
+
+
 /*
  * Inserts "elm_new" into the sorted list "head".
  *
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 18:55:50 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 18: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.xensource.com>)
	id 1RZ5be-0001E1-Eg; Fri, 09 Dec 2011 18:55:38 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RZ5bc-0001Aw-Kp
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 18:55:36 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1323456879!6616386!10
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI2MQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21380 invoked from network); 9 Dec 2011 18:54:46 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 18:54:46 -0000
X-IronPort-AV: E=Sophos;i="4.71,327,1320624000"; 
   d="scan'208";a="9392201"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 18:54:46 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 18:54:46 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RZ5ao-0002e9-BM; Fri, 09 Dec 2011 18:54:46 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RZ5ao-00040V-Aa;
	Fri, 09 Dec 2011 18:54:46 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Fri, 9 Dec 2011 18:54:28 +0000
Message-ID: <1323456877-15315-10-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1323456877-15315-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1323456877-15315-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 09/18] libxl: introduce lock in libxl_ctx
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This lock will be used to protect data structures which will be hung
off the libxl_ctx in subsequent patches.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl.c          |    6 ++++++
 tools/libxl/libxl_internal.h |   27 +++++++++++++++++++++++++++
 2 files changed, 33 insertions(+), 0 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index bc17b15..7488538 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -41,6 +41,7 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
 {
     libxl_ctx *ctx;
     struct stat stat_buf;
+    const pthread_mutex_t mutex_value = PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP;
 
     if (version != LIBXL_VERSION)
         return ERROR_VERSION;
@@ -54,6 +55,11 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
     memset(ctx, 0, sizeof(libxl_ctx));
     ctx->lg = lg;
 
+    /* This somewhat convoluted approach is needed because
+     * PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP is defined to be valid
+     * only as an initialiser, not as an expression. */
+    memcpy(&ctx->lock, &mutex_value, sizeof(ctx->lock));
+
     if ( stat(XENSTORE_PID_FILE, &stat_buf) != 0 ) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "Is xenstore daemon running?\n"
                      "failed to stat %s", XENSTORE_PID_FILE);
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index cda6fc1..41de6fd 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -23,6 +23,7 @@
 #include <stdarg.h>
 #include <stdlib.h>
 #include <string.h>
+#include <pthread.h>
 
 #include <xs.h>
 #include <xenctrl.h>
@@ -95,6 +96,18 @@ struct libxl__ctx {
     xc_interface *xch;
     struct xs_handle *xsh;
 
+    pthread_mutex_t lock; /* protects data structures hanging off the ctx */
+      /* Always use CTX_LOCK and CTX_UNLOCK to manipulate this.
+       *
+       * You may acquire this mutex recursively if it is convenient to
+       * do so.  You may not acquire this lock at the same time as any
+       * other lock.  If you need to call application code outside
+       * libxl (ie, a callback) with this lock held then it is
+       * necessaray to impose restrictions on the caller to maintain a
+       * proper lock hierarchy, and these restrictions must then be
+       * documented in the libxl public interface.
+       */
+
     /* for callers who reap children willy-nilly; caller must only
      * set this after libxl_init and before any other call - or
      * may leave them untouched */
@@ -668,6 +681,20 @@ libxl__device_model_version_running(libxl__gc *gc, uint32_t domid);
 #define CTX           libxl__gc_owner(gc)
 
 
+/* Locking functions.  See comment for "lock" member of libxl__ctx. */
+
+#define CTX_LOCK do {                                   \
+        int mutex_r = pthread_mutex_lock(&CTX->lock);   \
+        assert(!mutex_r);                               \
+    } while(0)
+
+#define CTX_UNLOCK do {                                 \
+        int mutex_r = pthread_mutex_unlock(&CTX->lock); \
+        assert(!mutex_r);                               \
+    } while(0)
+        
+
+
 /*
  * Inserts "elm_new" into the sorted list "head".
  *
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 18:55:50 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 18: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.xensource.com>)
	id 1RZ5bb-0001CC-SQ; Fri, 09 Dec 2011 18:55:35 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RZ5bZ-0001Ah-UI
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 18:55:34 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1323456879!6616386!4
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI2MQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21252 invoked from network); 9 Dec 2011 18:54:43 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 18:54:43 -0000
X-IronPort-AV: E=Sophos;i="4.71,327,1320624000"; 
   d="scan'208";a="9392195"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 18:54:43 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 18:54:43 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RZ5ak-0002dr-T1; Fri, 09 Dec 2011 18:54:42 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RZ5ak-000402-S9;
	Fri, 09 Dec 2011 18:54:42 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Fri, 9 Dec 2011 18:54:22 +0000
Message-ID: <1323456877-15315-4-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1323456877-15315-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1323456877-15315-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 03/18] libxl: Provide a version of bsd's queue.h
	as _libxl_list.h
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

We would like some linked list macros which are (a) well known to be
sane and (b) typesafe.  BSD's queue.h meets these criteria.

We also provide some simple perlery to arrange to add the libxl_
namespace prefix to the macros.  This will allow us to #include
_libxl_list.h in our public header file without clashing with anyone
else who is also using another version of queue.h.

(A note on copyright: The FreeBSD files we are adding have an
[L]GPL-compatible licence, so there is no need to change our COPYING.
Although FreeBSD's queue.3 still contains the advertising clause, this
has been withdrawn by UCB as recorded in the FreeBSD COPYRIGHT file,
which is included in tools/libxl/external/ for reference.)

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <Ian.campbell@citrix.com>
Tested-by: Roger Pau Monne <roger.pau@entel.upc.edu>
---
 tools/libxl/Makefile                 |   12 +-
 tools/libxl/bsd-sys-queue-h-seddery  |   70 +++
 tools/libxl/external/README          |   14 +
 tools/libxl/external/bsd-COPYRIGHT   |  126 ++++
 tools/libxl/external/bsd-queue.3     | 1044 ++++++++++++++++++++++++++++++++++
 tools/libxl/external/bsd-sys-queue.h |  637 +++++++++++++++++++++
 6 files changed, 1899 insertions(+), 4 deletions(-)
 create mode 100755 tools/libxl/bsd-sys-queue-h-seddery
 create mode 100644 tools/libxl/external/README
 create mode 100644 tools/libxl/external/bsd-COPYRIGHT
 create mode 100644 tools/libxl/external/bsd-queue.3
 create mode 100644 tools/libxl/external/bsd-sys-queue.h

diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index a7a4625..7a0c03c 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -42,7 +42,7 @@ LIBXL_OBJS += _libxl_types.o libxl_flask.o _libxl_types_internal.o
 
 $(LIBXL_OBJS): CFLAGS += $(CFLAGS_libxenctrl) $(CFLAGS_libxenguest) $(CFLAGS_libxenstore) $(CFLAGS_libblktapctl)
 
-AUTOINCS= libxlu_cfg_y.h libxlu_cfg_l.h
+AUTOINCS= libxlu_cfg_y.h libxlu_cfg_l.h _libxl_list.h
 AUTOSRCS= libxlu_cfg_y.c libxlu_cfg_l.c
 LIBXLU_OBJS = libxlu_cfg_y.o libxlu_cfg_l.o libxlu_cfg.o \
 	libxlu_disk_l.o libxlu_disk.o
@@ -55,7 +55,7 @@ $(XL_OBJS): CFLAGS += $(CFLAGS_libxenctrl) # For xentoollog.h
 $(XL_OBJS): CFLAGS += $(CFLAGS_libxenlight)
 
 testidl.o: CFLAGS += $(CFLAGS_libxenctrl) $(CFLAGS_libxenlight)
-testidl.c: libxl_types.idl gentest.py libxl.h
+testidl.c: libxl_types.idl gentest.py libxl.h $(AUTOINCS)
 	$(PYTHON) gentest.py libxl_types.idl testidl.c.new
 	mv testidl.c.new testidl.c
 
@@ -63,7 +63,7 @@ testidl.c: libxl_types.idl gentest.py libxl.h
 all: $(CLIENTS) libxenlight.so libxenlight.a libxlutil.so libxlutil.a \
 	$(AUTOSRCS) $(AUTOINCS)
 
-$(LIBXLU_OBJS): $(AUTOINCS)
+$(LIBXL_OBJS) $(LIBXLU_OBJS) $(XL_OBJS): $(AUTOINCS)
 
 %.c %.h: %.y
 	@rm -f $*.[ch]
@@ -81,6 +81,10 @@ _libxl_paths.h: genpath
 	rm -f $@.tmp
 	$(call move-if-changed,$@.2.tmp,$@)
 
+_libxl_list.h: bsd-sys-queue-h-seddery external/bsd-sys-queue.h
+	perl ./$^ --prefix=libxl >$@.new
+	$(call move-if-changed,$@.new,$@)
+
 libxl_paths.c: _libxl_paths.h
 
 libxl.h: _libxl_types.h
@@ -143,7 +147,7 @@ install: all
 	ln -sf libxlutil.so.$(XLUMAJOR).$(XLUMINOR) $(DESTDIR)$(LIBDIR)/libxlutil.so.$(XLUMAJOR)
 	ln -sf libxlutil.so.$(XLUMAJOR) $(DESTDIR)$(LIBDIR)/libxlutil.so
 	$(INSTALL_DATA) libxlutil.a $(DESTDIR)$(LIBDIR)
-	$(INSTALL_DATA) libxl.h libxl_json.h _libxl_types.h _libxl_types_json.h libxl_utils.h libxl_uuid.h $(DESTDIR)$(INCLUDEDIR)
+	$(INSTALL_DATA) libxl.h libxl_json.h _libxl_types.h _libxl_types_json.h _libxl_list.h libxl_utils.h libxl_uuid.h $(DESTDIR)$(INCLUDEDIR)
 	$(INSTALL_DATA) bash-completion $(DESTDIR)$(BASH_COMPLETION_DIR)/xl.sh
 
 .PHONY: clean
diff --git a/tools/libxl/bsd-sys-queue-h-seddery b/tools/libxl/bsd-sys-queue-h-seddery
new file mode 100755
index 0000000..c0aa079
--- /dev/null
+++ b/tools/libxl/bsd-sys-queue-h-seddery
@@ -0,0 +1,70 @@
+#!/usr/bin/perl -p
+#
+# This script is part of the Xen build system.  It has a very
+# permissive licence to avoid complicating the licence of the
+# generated header file and to allow this seddery to be reused by
+# other projects.
+#
+# Permission is hereby granted, free of charge, to any person
+# obtaining a copy of this individual 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.
+#
+# Copyright (C) 2011 Citrix Ltd
+
+our $namespace, $ucnamespace;
+
+BEGIN {
+    die unless @ARGV;
+    $namespace = pop @ARGV;
+    $namespace =~ s/^--prefix=// or die;
+    $ucnamespace = uc $namespace;
+
+    print <<END or die $!;
+/*
+ * DO NOT EDIT THIS FILE
+ *
+ * Generated automatically by bsd-sys-queue-h-seddery to
+ *  - introduce ${ucnamespace}_ and ${namespace}_ namespace prefixes
+ *  - turn "struct type" into "type" so that type arguments
+ *     to the macros are type names not struct tags
+ *  - remove the reference to sys/cdefs.h, which is not needed
+ *
+ * The purpose of this seddery is to allow the resulting file to be
+ * freely included by software which might also want to include other
+ * list macros; to make it usable when struct tags are not being used
+ * or not known; to make it more portable.
+ */
+END
+}
+
+s/\b( _SYS_QUEUE |
+      SLIST | LIST | STAILQ | TAILQ | QUEUE
+      )/${ucnamespace}_$1/xg;
+
+s/\b( TRACEBUF | TRASHIT |
+      QMD_
+      )/${ucnamespace}__$1/xg;
+
+s/\b(
+      qm_
+      )/${namespace}__$1/xg;
+
+s/\b struct \s+ type \b/type/xg;
+
+s,^\#include.*sys/cdefs.*,/* $& */,xg;
diff --git a/tools/libxl/external/README b/tools/libxl/external/README
new file mode 100644
index 0000000..8c8beea
--- /dev/null
+++ b/tools/libxl/external/README
@@ -0,0 +1,14 @@
+WARNING - DO NOT EDIT THINGS IN THIS DIRECTORY (apart from this README)
+-----------------------------------------------------------------------
+
+These files were obtained elsewhere and should only be updated by
+copying new versions from the source location, as documented below:
+
+bsd-COPYRIGHT
+bsd-sys-queue.h
+bsd-queue.3
+
+  Obtained from the FreeBSD SVN using the following commands:
+    svn co -r 221843 svn://svn.freebsd.org/base/head/sys/sys/
+    svn co -r 221843 svn://svn.freebsd.org/base/head/share/man/man3
+    svn cat -r 221843 http://svn.freebsd.org/base/head/COPYRIGHT >tools/libxl/external/bsd-COPYRIGHT
diff --git a/tools/libxl/external/bsd-COPYRIGHT b/tools/libxl/external/bsd-COPYRIGHT
new file mode 100644
index 0000000..6dc5d16
--- /dev/null
+++ b/tools/libxl/external/bsd-COPYRIGHT
@@ -0,0 +1,126 @@
+# $FreeBSD$
+#	@(#)COPYRIGHT	8.2 (Berkeley) 3/21/94
+
+The compilation of software known as FreeBSD is distributed under the
+following terms:
+
+Copyright (c) 1992-2011 The FreeBSD Project. All rights reserved.
+
+Redistribution and use in source and binary forms, with or without
+modification, are permitted provided that the following conditions
+are met:
+1. Redistributions of source code must retain the above copyright
+   notice, this list of conditions and the following disclaimer.
+2. Redistributions in binary form must reproduce the above copyright
+   notice, this list of conditions and the following disclaimer in the
+   documentation and/or other materials provided with the distribution.
+
+THIS SOFTWARE IS PROVIDED BY THE 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 THE 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.
+
+The 4.4BSD and 4.4BSD-Lite software is distributed under the following
+terms:
+
+All of the documentation and software included in the 4.4BSD and 4.4BSD-Lite
+Releases is copyrighted by The Regents of the University of California.
+
+Copyright 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
+	The Regents of the University of California.  All rights reserved.
+
+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.
+3. All advertising materials mentioning features or use of this software
+   must display the following acknowledgement:
+This product includes software developed by the University of
+California, Berkeley and its contributors.
+4. Neither the name of the University 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 REGENTS 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 REGENTS 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.
+
+The Institute of Electrical and Electronics Engineers and the American
+National Standards Committee X3, on Information Processing Systems have
+given us permission to reprint portions of their documentation.
+
+In the following statement, the phrase ``this text'' refers to portions
+of the system documentation.
+
+Portions of this text are reprinted and reproduced in electronic form in
+the second BSD Networking Software Release, from IEEE Std 1003.1-1988, IEEE
+Standard Portable Operating System Interface for Computer Environments
+(POSIX), copyright C 1988 by the Institute of Electrical and Electronics
+Engineers, Inc.  In the event of any discrepancy between these versions
+and the original IEEE Standard, the original IEEE Standard is the referee
+document.
+
+In the following statement, the phrase ``This material'' refers to portions
+of the system documentation.
+
+This material is reproduced with permission from American National
+Standards Committee X3, on Information Processing Systems.  Computer and
+Business Equipment Manufacturers Association (CBEMA), 311 First St., NW,
+Suite 500, Washington, DC 20001-2178.  The developmental work of
+Programming Language C was completed by the X3J11 Technical Committee.
+
+The views and conclusions contained in the software and documentation are
+those of the authors and should not be interpreted as representing official
+policies, either expressed or implied, of the Regents of the University
+of California.
+
+
+NOTE: The copyright of UC Berkeley's Berkeley Software Distribution ("BSD")
+source has been updated.  The copyright addendum may be found at
+ftp://ftp.cs.berkeley.edu/pub/4bsd/README.Impt.License.Change and is
+included below.
+
+July 22, 1999
+
+To All Licensees, Distributors of Any Version of BSD:
+
+As you know, certain of the Berkeley Software Distribution ("BSD") source
+code files require that further distributions of products containing all or
+portions of the software, acknowledge within their advertising materials
+that such products contain software developed by UC Berkeley and its
+contributors.
+
+Specifically, the provision reads:
+
+"     * 3. All advertising materials mentioning features or use of this software
+      *    must display the following acknowledgement:
+      *    This product includes software developed by the University of
+      *    California, Berkeley and its contributors."
+
+Effective immediately, licensees and distributors are no longer required to
+include the acknowledgement within advertising materials.  Accordingly, the
+foregoing paragraph of those BSD Unix files containing it is hereby deleted
+in its entirety.
+
+William Hoskins
+Director, Office of Technology Licensing
+University of California, Berkeley
diff --git a/tools/libxl/external/bsd-queue.3 b/tools/libxl/external/bsd-queue.3
new file mode 100644
index 0000000..007ca5c
--- /dev/null
+++ b/tools/libxl/external/bsd-queue.3
@@ -0,0 +1,1044 @@
+.\" Copyright (c) 1993
+.\"	The Regents of the University of California.  All rights reserved.
+.\"
+.\" 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.
+.\" 3. All advertising materials mentioning features or use of this software
+.\"    must display the following acknowledgement:
+.\"	This product includes software developed by the University of
+.\"	California, Berkeley and its contributors.
+.\" 4. Neither the name of the University 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 REGENTS 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 REGENTS 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.
+.\"
+.\"	@(#)queue.3	8.2 (Berkeley) 1/24/94
+.\" $FreeBSD$
+.\"
+.Dd May 13, 2011
+.Dt QUEUE 3
+.Os
+.Sh NAME
+.Nm SLIST_EMPTY ,
+.Nm SLIST_ENTRY ,
+.Nm SLIST_FIRST ,
+.Nm SLIST_FOREACH ,
+.Nm SLIST_FOREACH_SAFE ,
+.Nm SLIST_HEAD ,
+.Nm SLIST_HEAD_INITIALIZER ,
+.Nm SLIST_INIT ,
+.Nm SLIST_INSERT_AFTER ,
+.Nm SLIST_INSERT_HEAD ,
+.Nm SLIST_NEXT ,
+.Nm SLIST_REMOVE_AFTER ,
+.Nm SLIST_REMOVE_HEAD ,
+.Nm SLIST_REMOVE ,
+.Nm SLIST_SWAP ,
+.Nm STAILQ_CONCAT ,
+.Nm STAILQ_EMPTY ,
+.Nm STAILQ_ENTRY ,
+.Nm STAILQ_FIRST ,
+.Nm STAILQ_FOREACH ,
+.Nm STAILQ_FOREACH_SAFE ,
+.Nm STAILQ_HEAD ,
+.Nm STAILQ_HEAD_INITIALIZER ,
+.Nm STAILQ_INIT ,
+.Nm STAILQ_INSERT_AFTER ,
+.Nm STAILQ_INSERT_HEAD ,
+.Nm STAILQ_INSERT_TAIL ,
+.Nm STAILQ_LAST ,
+.Nm STAILQ_NEXT ,
+.Nm STAILQ_REMOVE_AFTER ,
+.Nm STAILQ_REMOVE_HEAD ,
+.Nm STAILQ_REMOVE ,
+.Nm STAILQ_SWAP ,
+.Nm LIST_EMPTY ,
+.Nm LIST_ENTRY ,
+.Nm LIST_FIRST ,
+.Nm LIST_FOREACH ,
+.Nm LIST_FOREACH_SAFE ,
+.Nm LIST_HEAD ,
+.Nm LIST_HEAD_INITIALIZER ,
+.Nm LIST_INIT ,
+.Nm LIST_INSERT_AFTER ,
+.Nm LIST_INSERT_BEFORE ,
+.Nm LIST_INSERT_HEAD ,
+.Nm LIST_NEXT ,
+.Nm LIST_REMOVE ,
+.Nm LIST_SWAP ,
+.Nm TAILQ_CONCAT ,
+.Nm TAILQ_EMPTY ,
+.Nm TAILQ_ENTRY ,
+.Nm TAILQ_FIRST ,
+.Nm TAILQ_FOREACH ,
+.Nm TAILQ_FOREACH_SAFE ,
+.Nm TAILQ_FOREACH_REVERSE ,
+.Nm TAILQ_FOREACH_REVERSE_SAFE ,
+.Nm TAILQ_HEAD ,
+.Nm TAILQ_HEAD_INITIALIZER ,
+.Nm TAILQ_INIT ,
+.Nm TAILQ_INSERT_AFTER ,
+.Nm TAILQ_INSERT_BEFORE ,
+.Nm TAILQ_INSERT_HEAD ,
+.Nm TAILQ_INSERT_TAIL ,
+.Nm TAILQ_LAST ,
+.Nm TAILQ_NEXT ,
+.Nm TAILQ_PREV ,
+.Nm TAILQ_REMOVE ,
+.Nm TAILQ_SWAP
+.Nd implementations of singly-linked lists, singly-linked tail queues,
+lists and tail queues
+.Sh SYNOPSIS
+.In sys/queue.h
+.\"
+.Fn SLIST_EMPTY "SLIST_HEAD *head"
+.Fn SLIST_ENTRY "TYPE"
+.Fn SLIST_FIRST "SLIST_HEAD *head"
+.Fn SLIST_FOREACH "TYPE *var" "SLIST_HEAD *head" "SLIST_ENTRY NAME"
+.Fn SLIST_FOREACH_SAFE "TYPE *var" "SLIST_HEAD *head" "SLIST_ENTRY NAME" "TYPE *temp_var"
+.Fn SLIST_HEAD "HEADNAME" "TYPE"
+.Fn SLIST_HEAD_INITIALIZER "SLIST_HEAD head"
+.Fn SLIST_INIT "SLIST_HEAD *head"
+.Fn SLIST_INSERT_AFTER "TYPE *listelm" "TYPE *elm" "SLIST_ENTRY NAME"
+.Fn SLIST_INSERT_HEAD "SLIST_HEAD *head" "TYPE *elm" "SLIST_ENTRY NAME"
+.Fn SLIST_NEXT "TYPE *elm" "SLIST_ENTRY NAME"
+.Fn SLIST_REMOVE_AFTER "TYPE *elm" "SLIST_ENTRY NAME"
+.Fn SLIST_REMOVE_HEAD "SLIST_HEAD *head" "SLIST_ENTRY NAME"
+.Fn SLIST_REMOVE "SLIST_HEAD *head" "TYPE *elm" "TYPE" "SLIST_ENTRY NAME"
+.Fn SLIST_SWAP "SLIST_HEAD *head1" "SLIST_HEAD *head2" "SLIST_ENTRY NAME"
+.\"
+.Fn STAILQ_CONCAT "STAILQ_HEAD *head1" "STAILQ_HEAD *head2"
+.Fn STAILQ_EMPTY "STAILQ_HEAD *head"
+.Fn STAILQ_ENTRY "TYPE"
+.Fn STAILQ_FIRST "STAILQ_HEAD *head"
+.Fn STAILQ_FOREACH "TYPE *var" "STAILQ_HEAD *head" "STAILQ_ENTRY NAME"
+.Fn STAILQ_FOREACH_SAFE "TYPE *var" "STAILQ_HEAD *head" "STAILQ_ENTRY NAME" "TYPE *temp_var"
+.Fn STAILQ_HEAD "HEADNAME" "TYPE"
+.Fn STAILQ_HEAD_INITIALIZER "STAILQ_HEAD head"
+.Fn STAILQ_INIT "STAILQ_HEAD *head"
+.Fn STAILQ_INSERT_AFTER "STAILQ_HEAD *head" "TYPE *listelm" "TYPE *elm" "STAILQ_ENTRY NAME"
+.Fn STAILQ_INSERT_HEAD "STAILQ_HEAD *head" "TYPE *elm" "STAILQ_ENTRY NAME"
+.Fn STAILQ_INSERT_TAIL "STAILQ_HEAD *head" "TYPE *elm" "STAILQ_ENTRY NAME"
+.Fn STAILQ_LAST "STAILQ_HEAD *head" "TYPE" "STAILQ_ENTRY NAME"
+.Fn STAILQ_NEXT "TYPE *elm" "STAILQ_ENTRY NAME"
+.Fn STAILQ_REMOVE_AFTER "STAILQ_HEAD *head" "TYPE *elm" "STAILQ_ENTRY NAME"
+.Fn STAILQ_REMOVE_HEAD "STAILQ_HEAD *head" "STAILQ_ENTRY NAME"
+.Fn STAILQ_REMOVE "STAILQ_HEAD *head" "TYPE *elm" "TYPE" "STAILQ_ENTRY NAME"
+.Fn STAILQ_SWAP "STAILQ_HEAD *head1" "STAILQ_HEAD *head2" "STAILQ_ENTRY NAME"
+.\"
+.Fn LIST_EMPTY "LIST_HEAD *head"
+.Fn LIST_ENTRY "TYPE"
+.Fn LIST_FIRST "LIST_HEAD *head"
+.Fn LIST_FOREACH "TYPE *var" "LIST_HEAD *head" "LIST_ENTRY NAME"
+.Fn LIST_FOREACH_SAFE "TYPE *var" "LIST_HEAD *head" "LIST_ENTRY NAME" "TYPE *temp_var"
+.Fn LIST_HEAD "HEADNAME" "TYPE"
+.Fn LIST_HEAD_INITIALIZER "LIST_HEAD head"
+.Fn LIST_INIT "LIST_HEAD *head"
+.Fn LIST_INSERT_AFTER "TYPE *listelm" "TYPE *elm" "LIST_ENTRY NAME"
+.Fn LIST_INSERT_BEFORE "TYPE *listelm" "TYPE *elm" "LIST_ENTRY NAME"
+.Fn LIST_INSERT_HEAD "LIST_HEAD *head" "TYPE *elm" "LIST_ENTRY NAME"
+.Fn LIST_NEXT "TYPE *elm" "LIST_ENTRY NAME"
+.Fn LIST_REMOVE "TYPE *elm" "LIST_ENTRY NAME"
+.Fn LIST_SWAP "LIST_HEAD *head1" "LIST_HEAD *head2" "TYPE" "LIST_ENTRY NAME"
+.\"
+.Fn TAILQ_CONCAT "TAILQ_HEAD *head1" "TAILQ_HEAD *head2" "TAILQ_ENTRY NAME"
+.Fn TAILQ_EMPTY "TAILQ_HEAD *head"
+.Fn TAILQ_ENTRY "TYPE"
+.Fn TAILQ_FIRST "TAILQ_HEAD *head"
+.Fn TAILQ_FOREACH "TYPE *var" "TAILQ_HEAD *head" "TAILQ_ENTRY NAME"
+.Fn TAILQ_FOREACH_SAFE "TYPE *var" "TAILQ_HEAD *head" "TAILQ_ENTRY NAME" "TYPE *temp_var"
+.Fn TAILQ_FOREACH_REVERSE "TYPE *var" "TAILQ_HEAD *head" "HEADNAME" "TAILQ_ENTRY NAME"
+.Fn TAILQ_FOREACH_REVERSE_SAFE "TYPE *var" "TAILQ_HEAD *head" "HEADNAME" "TAILQ_ENTRY NAME" "TYPE *temp_var"
+.Fn TAILQ_HEAD "HEADNAME" "TYPE"
+.Fn TAILQ_HEAD_INITIALIZER "TAILQ_HEAD head"
+.Fn TAILQ_INIT "TAILQ_HEAD *head"
+.Fn TAILQ_INSERT_AFTER "TAILQ_HEAD *head" "TYPE *listelm" "TYPE *elm" "TAILQ_ENTRY NAME"
+.Fn TAILQ_INSERT_BEFORE "TYPE *listelm" "TYPE *elm" "TAILQ_ENTRY NAME"
+.Fn TAILQ_INSERT_HEAD "TAILQ_HEAD *head" "TYPE *elm" "TAILQ_ENTRY NAME"
+.Fn TAILQ_INSERT_TAIL "TAILQ_HEAD *head" "TYPE *elm" "TAILQ_ENTRY NAME"
+.Fn TAILQ_LAST "TAILQ_HEAD *head" "HEADNAME"
+.Fn TAILQ_NEXT "TYPE *elm" "TAILQ_ENTRY NAME"
+.Fn TAILQ_PREV "TYPE *elm" "HEADNAME" "TAILQ_ENTRY NAME"
+.Fn TAILQ_REMOVE "TAILQ_HEAD *head" "TYPE *elm" "TAILQ_ENTRY NAME"
+.Fn TAILQ_SWAP "TAILQ_HEAD *head1" "TAILQ_HEAD *head2" "TYPE" "TAILQ_ENTRY NAME"
+.\"
+.Sh DESCRIPTION
+These macros define and operate on four types of data structures:
+singly-linked lists, singly-linked tail queues, lists, and tail queues.
+All four structures support the following functionality:
+.Bl -enum -compact -offset indent
+.It
+Insertion of a new entry at the head of the list.
+.It
+Insertion of a new entry after any element in the list.
+.It
+O(1) removal of an entry from the head of the list.
+.It
+Forward traversal through the list.
+.It
+Swawpping the contents of two lists.
+.El
+.Pp
+Singly-linked lists are the simplest of the four data structures
+and support only the above functionality.
+Singly-linked lists are ideal for applications with large datasets
+and few or no removals,
+or for implementing a LIFO queue.
+Singly-linked lists add the following functionality:
+.Bl -enum -compact -offset indent
+.It
+O(n) removal of any entry in the list.
+.El
+.Pp
+Singly-linked tail queues add the following functionality:
+.Bl -enum -compact -offset indent
+.It
+Entries can be added at the end of a list.
+.It
+O(n) removal of any entry in the list.
+.It
+They may be concatenated.
+.El
+However:
+.Bl -enum -compact -offset indent
+.It
+All list insertions must specify the head of the list.
+.It
+Each head entry requires two pointers rather than one.
+.It
+Code size is about 15% greater and operations run about 20% slower
+than singly-linked lists.
+.El
+.Pp
+Singly-linked tailqs are ideal for applications with large datasets and
+few or no removals,
+or for implementing a FIFO queue.
+.Pp
+All doubly linked types of data structures (lists and tail queues)
+additionally allow:
+.Bl -enum -compact -offset indent
+.It
+Insertion of a new entry before any element in the list.
+.It
+O(1) removal of any entry in the list.
+.El
+However:
+.Bl -enum -compact -offset indent
+.It
+Each element requires two pointers rather than one.
+.It
+Code size and execution time of operations (except for removal) is about
+twice that of the singly-linked data-structures.
+.El
+.Pp
+Linked lists are the simplest of the doubly linked data structures and support
+only the above functionality over singly-linked lists.
+.Pp
+Tail queues add the following functionality:
+.Bl -enum -compact -offset indent
+.It
+Entries can be added at the end of a list.
+.It
+They may be traversed backwards, from tail to head.
+.It
+They may be concatenated.
+.El
+However:
+.Bl -enum -compact -offset indent
+.It
+All list insertions and removals must specify the head of the list.
+.It
+Each head entry requires two pointers rather than one.
+.It
+Code size is about 15% greater and operations run about 20% slower
+than singly-linked lists.
+.El
+.Pp
+In the macro definitions,
+.Fa TYPE
+is the name of a user defined structure,
+that must contain a field of type
+.Li SLIST_ENTRY ,
+.Li STAILQ_ENTRY ,
+.Li LIST_ENTRY ,
+or
+.Li TAILQ_ENTRY ,
+named
+.Fa NAME .
+The argument
+.Fa HEADNAME
+is the name of a user defined structure that must be declared
+using the macros
+.Li SLIST_HEAD ,
+.Li STAILQ_HEAD ,
+.Li LIST_HEAD ,
+or
+.Li TAILQ_HEAD .
+See the examples below for further explanation of how these
+macros are used.
+.Sh SINGLY-LINKED LISTS
+A singly-linked list is headed by a structure defined by the
+.Nm SLIST_HEAD
+macro.
+This structure contains a single pointer to the first element
+on the list.
+The elements are singly linked for minimum space and pointer manipulation
+overhead at the expense of O(n) removal for arbitrary elements.
+New elements can be added to the list after an existing element or
+at the head of the list.
+An
+.Fa SLIST_HEAD
+structure is declared as follows:
+.Bd -literal -offset indent
+SLIST_HEAD(HEADNAME, TYPE) head;
+.Ed
+.Pp
+where
+.Fa HEADNAME
+is the name of the structure to be defined, and
+.Fa TYPE
+is the type of the elements to be linked into the list.
+A pointer to the head of the list can later be declared as:
+.Bd -literal -offset indent
+struct HEADNAME *headp;
+.Ed
+.Pp
+(The names
+.Li head
+and
+.Li headp
+are user selectable.)
+.Pp
+The macro
+.Nm SLIST_HEAD_INITIALIZER
+evaluates to an initializer for the list
+.Fa head .
+.Pp
+The macro
+.Nm SLIST_EMPTY
+evaluates to true if there are no elements in the list.
+.Pp
+The macro
+.Nm SLIST_ENTRY
+declares a structure that connects the elements in
+the list.
+.Pp
+The macro
+.Nm SLIST_FIRST
+returns the first element in the list or NULL if the list is empty.
+.Pp
+The macro
+.Nm SLIST_FOREACH
+traverses the list referenced by
+.Fa head
+in the forward direction, assigning each element in
+turn to
+.Fa var .
+.Pp
+The macro
+.Nm SLIST_FOREACH_SAFE
+traverses the list referenced by
+.Fa head
+in the forward direction, assigning each element in
+turn to
+.Fa var .
+However, unlike
+.Fn SLIST_FOREACH
+here it is permitted to both remove
+.Fa var
+as well as free it from within the loop safely without interfering with the
+traversal.
+.Pp
+The macro
+.Nm SLIST_INIT
+initializes the list referenced by
+.Fa head .
+.Pp
+The macro
+.Nm SLIST_INSERT_HEAD
+inserts the new element
+.Fa elm
+at the head of the list.
+.Pp
+The macro
+.Nm SLIST_INSERT_AFTER
+inserts the new element
+.Fa elm
+after the element
+.Fa listelm .
+.Pp
+The macro
+.Nm SLIST_NEXT
+returns the next element in the list.
+.Pp
+The macro
+.Nm SLIST_REMOVE_AFTER
+removes the element after
+.Fa elm
+from the list. Unlike
+.Fa SLIST_REMOVE ,
+this macro does not traverse the entire list.
+.Pp
+The macro
+.Nm SLIST_REMOVE_HEAD
+removes the element
+.Fa elm
+from the head of the list.
+For optimum efficiency,
+elements being removed from the head of the list should explicitly use
+this macro instead of the generic
+.Fa SLIST_REMOVE
+macro.
+.Pp
+The macro
+.Nm SLIST_REMOVE
+removes the element
+.Fa elm
+from the list.
+.Pp
+The macro
+.Nm SLIST_SWAP
+swaps the contents of
+.Fa head1
+and
+.Fa head2 .
+.Sh SINGLY-LINKED LIST EXAMPLE
+.Bd -literal
+SLIST_HEAD(slisthead, entry) head =
+    SLIST_HEAD_INITIALIZER(head);
+struct slisthead *headp;		/* Singly-linked List head. */
+struct entry {
+	...
+	SLIST_ENTRY(entry) entries;	/* Singly-linked List. */
+	...
+} *n1, *n2, *n3, *np;
+
+SLIST_INIT(&head);			/* Initialize the list. */
+
+n1 = malloc(sizeof(struct entry));	/* Insert at the head. */
+SLIST_INSERT_HEAD(&head, n1, entries);
+
+n2 = malloc(sizeof(struct entry));	/* Insert after. */
+SLIST_INSERT_AFTER(n1, n2, entries);
+
+SLIST_REMOVE(&head, n2, entry, entries);/* Deletion. */
+free(n2);
+
+n3 = SLIST_FIRST(&head);
+SLIST_REMOVE_HEAD(&head, entries);	/* Deletion from the head. */
+free(n3);
+					/* Forward traversal. */
+SLIST_FOREACH(np, &head, entries)
+	np-> ...
+					/* Safe forward traversal. */
+SLIST_FOREACH_SAFE(np, &head, entries, np_temp) {
+	np->do_stuff();
+	...
+	SLIST_REMOVE(&head, np, entry, entries);
+	free(np);
+}
+
+while (!SLIST_EMPTY(&head)) {		/* List Deletion. */
+	n1 = SLIST_FIRST(&head);
+	SLIST_REMOVE_HEAD(&head, entries);
+	free(n1);
+}
+.Ed
+.Sh SINGLY-LINKED TAIL QUEUES
+A singly-linked tail queue is headed by a structure defined by the
+.Nm STAILQ_HEAD
+macro.
+This structure contains a pair of pointers,
+one to the first element in the tail queue and the other to
+the last element in the tail queue.
+The elements are singly linked for minimum space and pointer
+manipulation overhead at the expense of O(n) removal for arbitrary
+elements.
+New elements can be added to the tail queue after an existing element,
+at the head of the tail queue, or at the end of the tail queue.
+A
+.Fa STAILQ_HEAD
+structure is declared as follows:
+.Bd -literal -offset indent
+STAILQ_HEAD(HEADNAME, TYPE) head;
+.Ed
+.Pp
+where
+.Li HEADNAME
+is the name of the structure to be defined, and
+.Li TYPE
+is the type of the elements to be linked into the tail queue.
+A pointer to the head of the tail queue can later be declared as:
+.Bd -literal -offset indent
+struct HEADNAME *headp;
+.Ed
+.Pp
+(The names
+.Li head
+and
+.Li headp
+are user selectable.)
+.Pp
+The macro
+.Nm STAILQ_HEAD_INITIALIZER
+evaluates to an initializer for the tail queue
+.Fa head .
+.Pp
+The macro
+.Nm STAILQ_CONCAT
+concatenates the tail queue headed by
+.Fa head2
+onto the end of the one headed by
+.Fa head1
+removing all entries from the former.
+.Pp
+The macro
+.Nm STAILQ_EMPTY
+evaluates to true if there are no items on the tail queue.
+.Pp
+The macro
+.Nm STAILQ_ENTRY
+declares a structure that connects the elements in
+the tail queue.
+.Pp
+The macro
+.Nm STAILQ_FIRST
+returns the first item on the tail queue or NULL if the tail queue
+is empty.
+.Pp
+The macro
+.Nm STAILQ_FOREACH
+traverses the tail queue referenced by
+.Fa head
+in the forward direction, assigning each element
+in turn to
+.Fa var .
+.Pp
+The macro
+.Nm STAILQ_FOREACH_SAFE
+traverses the tail queue referenced by
+.Fa head
+in the forward direction, assigning each element
+in turn to
+.Fa var .
+However, unlike
+.Fn STAILQ_FOREACH
+here it is permitted to both remove
+.Fa var
+as well as free it from within the loop safely without interfering with the
+traversal.
+.Pp
+The macro
+.Nm STAILQ_INIT
+initializes the tail queue referenced by
+.Fa head .
+.Pp
+The macro
+.Nm STAILQ_INSERT_HEAD
+inserts the new element
+.Fa elm
+at the head of the tail queue.
+.Pp
+The macro
+.Nm STAILQ_INSERT_TAIL
+inserts the new element
+.Fa elm
+at the end of the tail queue.
+.Pp
+The macro
+.Nm STAILQ_INSERT_AFTER
+inserts the new element
+.Fa elm
+after the element
+.Fa listelm .
+.Pp
+The macro
+.Nm STAILQ_LAST
+returns the last item on the tail queue.
+If the tail queue is empty the return value is
+.Dv NULL .
+.Pp
+The macro
+.Nm STAILQ_NEXT
+returns the next item on the tail queue, or NULL this item is the last.
+.Pp
+The macro
+.Nm STAILQ_REMOVE_AFTER
+removes the element after
+.Fa elm
+from the tail queue. Unlike
+.Fa STAILQ_REMOVE ,
+this macro does not traverse the entire tail queue.
+.Pp
+The macro
+.Nm STAILQ_REMOVE_HEAD
+removes the element at the head of the tail queue.
+For optimum efficiency,
+elements being removed from the head of the tail queue should
+use this macro explicitly rather than the generic
+.Fa STAILQ_REMOVE
+macro.
+.Pp
+The macro
+.Nm STAILQ_REMOVE
+removes the element
+.Fa elm
+from the tail queue.
+.Pp
+The macro
+.Nm STAILQ_SWAP
+swaps the contents of
+.Fa head1
+and
+.Fa head2 .
+.Sh SINGLY-LINKED TAIL QUEUE EXAMPLE
+.Bd -literal
+STAILQ_HEAD(stailhead, entry) head =
+    STAILQ_HEAD_INITIALIZER(head);
+struct stailhead *headp;		/* Singly-linked tail queue head. */
+struct entry {
+	...
+	STAILQ_ENTRY(entry) entries;	/* Tail queue. */
+	...
+} *n1, *n2, *n3, *np;
+
+STAILQ_INIT(&head);			/* Initialize the queue. */
+
+n1 = malloc(sizeof(struct entry));	/* Insert at the head. */
+STAILQ_INSERT_HEAD(&head, n1, entries);
+
+n1 = malloc(sizeof(struct entry));	/* Insert at the tail. */
+STAILQ_INSERT_TAIL(&head, n1, entries);
+
+n2 = malloc(sizeof(struct entry));	/* Insert after. */
+STAILQ_INSERT_AFTER(&head, n1, n2, entries);
+					/* Deletion. */
+STAILQ_REMOVE(&head, n2, entry, entries);
+free(n2);
+					/* Deletion from the head. */
+n3 = STAILQ_FIRST(&head);
+STAILQ_REMOVE_HEAD(&head, entries);
+free(n3);
+					/* Forward traversal. */
+STAILQ_FOREACH(np, &head, entries)
+	np-> ...
+					/* Safe forward traversal. */
+STAILQ_FOREACH_SAFE(np, &head, entries, np_temp) {
+	np->do_stuff();
+	...
+	STAILQ_REMOVE(&head, np, entry, entries);
+	free(np);
+}
+					/* TailQ Deletion. */
+while (!STAILQ_EMPTY(&head)) {
+	n1 = STAILQ_FIRST(&head);
+	STAILQ_REMOVE_HEAD(&head, entries);
+	free(n1);
+}
+					/* Faster TailQ Deletion. */
+n1 = STAILQ_FIRST(&head);
+while (n1 != NULL) {
+	n2 = STAILQ_NEXT(n1, entries);
+	free(n1);
+	n1 = n2;
+}
+STAILQ_INIT(&head);
+.Ed
+.Sh LISTS
+A list is headed by a structure defined by the
+.Nm LIST_HEAD
+macro.
+This structure contains a single pointer to the first element
+on the list.
+The elements are doubly linked so that an arbitrary element can be
+removed without traversing the list.
+New elements can be added to the list after an existing element,
+before an existing element, or at the head of the list.
+A
+.Fa LIST_HEAD
+structure is declared as follows:
+.Bd -literal -offset indent
+LIST_HEAD(HEADNAME, TYPE) head;
+.Ed
+.Pp
+where
+.Fa HEADNAME
+is the name of the structure to be defined, and
+.Fa TYPE
+is the type of the elements to be linked into the list.
+A pointer to the head of the list can later be declared as:
+.Bd -literal -offset indent
+struct HEADNAME *headp;
+.Ed
+.Pp
+(The names
+.Li head
+and
+.Li headp
+are user selectable.)
+.Pp
+The macro
+.Nm LIST_HEAD_INITIALIZER
+evaluates to an initializer for the list
+.Fa head .
+.Pp
+The macro
+.Nm LIST_EMPTY
+evaluates to true if there are no elements in the list.
+.Pp
+The macro
+.Nm LIST_ENTRY
+declares a structure that connects the elements in
+the list.
+.Pp
+The macro
+.Nm LIST_FIRST
+returns the first element in the list or NULL if the list
+is empty.
+.Pp
+The macro
+.Nm LIST_FOREACH
+traverses the list referenced by
+.Fa head
+in the forward direction, assigning each element in turn to
+.Fa var .
+.Pp
+The macro
+.Nm LIST_FOREACH_SAFE
+traverses the list referenced by
+.Fa head
+in the forward direction, assigning each element in turn to
+.Fa var .
+However, unlike
+.Fn LIST_FOREACH
+here it is permitted to both remove
+.Fa var
+as well as free it from within the loop safely without interfering with the
+traversal.
+.Pp
+The macro
+.Nm LIST_INIT
+initializes the list referenced by
+.Fa head .
+.Pp
+The macro
+.Nm LIST_INSERT_HEAD
+inserts the new element
+.Fa elm
+at the head of the list.
+.Pp
+The macro
+.Nm LIST_INSERT_AFTER
+inserts the new element
+.Fa elm
+after the element
+.Fa listelm .
+.Pp
+The macro
+.Nm LIST_INSERT_BEFORE
+inserts the new element
+.Fa elm
+before the element
+.Fa listelm .
+.Pp
+The macro
+.Nm LIST_NEXT
+returns the next element in the list, or NULL if this is the last.
+.Pp
+The macro
+.Nm LIST_REMOVE
+removes the element
+.Fa elm
+from the list.
+.Pp
+The macro
+.Nm LIST_SWAP
+swaps the contents of
+.Fa head1
+and
+.Fa head2 .
+.Sh LIST EXAMPLE
+.Bd -literal
+LIST_HEAD(listhead, entry) head =
+    LIST_HEAD_INITIALIZER(head);
+struct listhead *headp;			/* List head. */
+struct entry {
+	...
+	LIST_ENTRY(entry) entries;	/* List. */
+	...
+} *n1, *n2, *n3, *np, *np_temp;
+
+LIST_INIT(&head);			/* Initialize the list. */
+
+n1 = malloc(sizeof(struct entry));	/* Insert at the head. */
+LIST_INSERT_HEAD(&head, n1, entries);
+
+n2 = malloc(sizeof(struct entry));	/* Insert after. */
+LIST_INSERT_AFTER(n1, n2, entries);
+
+n3 = malloc(sizeof(struct entry));	/* Insert before. */
+LIST_INSERT_BEFORE(n2, n3, entries);
+
+LIST_REMOVE(n2, entries);		/* Deletion. */
+free(n2);
+					/* Forward traversal. */
+LIST_FOREACH(np, &head, entries)
+	np-> ...
+
+					/* Safe forward traversal. */
+LIST_FOREACH_SAFE(np, &head, entries, np_temp) {
+	np->do_stuff();
+	...
+	LIST_REMOVE(np, entries);
+	free(np);
+}
+
+while (!LIST_EMPTY(&head)) {		/* List Deletion. */
+	n1 = LIST_FIRST(&head);
+	LIST_REMOVE(n1, entries);
+	free(n1);
+}
+
+n1 = LIST_FIRST(&head);			/* Faster List Deletion. */
+while (n1 != NULL) {
+	n2 = LIST_NEXT(n1, entries);
+	free(n1);
+	n1 = n2;
+}
+LIST_INIT(&head);
+.Ed
+.Sh TAIL QUEUES
+A tail queue is headed by a structure defined by the
+.Nm TAILQ_HEAD
+macro.
+This structure contains a pair of pointers,
+one to the first element in the tail queue and the other to
+the last element in the tail queue.
+The elements are doubly linked so that an arbitrary element can be
+removed without traversing the tail queue.
+New elements can be added to the tail queue after an existing element,
+before an existing element, at the head of the tail queue,
+or at the end of the tail queue.
+A
+.Fa TAILQ_HEAD
+structure is declared as follows:
+.Bd -literal -offset indent
+TAILQ_HEAD(HEADNAME, TYPE) head;
+.Ed
+.Pp
+where
+.Li HEADNAME
+is the name of the structure to be defined, and
+.Li TYPE
+is the type of the elements to be linked into the tail queue.
+A pointer to the head of the tail queue can later be declared as:
+.Bd -literal -offset indent
+struct HEADNAME *headp;
+.Ed
+.Pp
+(The names
+.Li head
+and
+.Li headp
+are user selectable.)
+.Pp
+The macro
+.Nm TAILQ_HEAD_INITIALIZER
+evaluates to an initializer for the tail queue
+.Fa head .
+.Pp
+The macro
+.Nm TAILQ_CONCAT
+concatenates the tail queue headed by
+.Fa head2
+onto the end of the one headed by
+.Fa head1
+removing all entries from the former.
+.Pp
+The macro
+.Nm TAILQ_EMPTY
+evaluates to true if there are no items on the tail queue.
+.Pp
+The macro
+.Nm TAILQ_ENTRY
+declares a structure that connects the elements in
+the tail queue.
+.Pp
+The macro
+.Nm TAILQ_FIRST
+returns the first item on the tail queue or NULL if the tail queue
+is empty.
+.Pp
+The macro
+.Nm TAILQ_FOREACH
+traverses the tail queue referenced by
+.Fa head
+in the forward direction, assigning each element in turn to
+.Fa var .
+.Fa var
+is set to
+.Dv NULL
+if the loop completes normally, or if there were no elements.
+.Pp
+The macro
+.Nm TAILQ_FOREACH_REVERSE
+traverses the tail queue referenced by
+.Fa head
+in the reverse direction, assigning each element in turn to
+.Fa var .
+.Pp
+The macros
+.Nm TAILQ_FOREACH_SAFE
+and
+.Nm TAILQ_FOREACH_REVERSE_SAFE
+traverse the list referenced by
+.Fa head
+in the forward or reverse direction respectively,
+assigning each element in turn to
+.Fa var .
+However, unlike their unsafe counterparts,
+.Nm TAILQ_FOREACH
+and
+.Nm TAILQ_FOREACH_REVERSE
+permit to both remove
+.Fa var
+as well as free it from within the loop safely without interfering with the
+traversal.
+.Pp
+The macro
+.Nm TAILQ_INIT
+initializes the tail queue referenced by
+.Fa head .
+.Pp
+The macro
+.Nm TAILQ_INSERT_HEAD
+inserts the new element
+.Fa elm
+at the head of the tail queue.
+.Pp
+The macro
+.Nm TAILQ_INSERT_TAIL
+inserts the new element
+.Fa elm
+at the end of the tail queue.
+.Pp
+The macro
+.Nm TAILQ_INSERT_AFTER
+inserts the new element
+.Fa elm
+after the element
+.Fa listelm .
+.Pp
+The macro
+.Nm TAILQ_INSERT_BEFORE
+inserts the new element
+.Fa elm
+before the element
+.Fa listelm .
+.Pp
+The macro
+.Nm TAILQ_LAST
+returns the last item on the tail queue.
+If the tail queue is empty the return value is
+.Dv NULL .
+.Pp
+The macro
+.Nm TAILQ_NEXT
+returns the next item on the tail queue, or NULL if this item is the last.
+.Pp
+The macro
+.Nm TAILQ_PREV
+returns the previous item on the tail queue, or NULL if this item
+is the first.
+.Pp
+The macro
+.Nm TAILQ_REMOVE
+removes the element
+.Fa elm
+from the tail queue.
+.Pp
+The macro
+.Nm TAILQ_SWAP
+swaps the contents of
+.Fa head1
+and
+.Fa head2 .
+.Sh TAIL QUEUE EXAMPLE
+.Bd -literal
+TAILQ_HEAD(tailhead, entry) head =
+    TAILQ_HEAD_INITIALIZER(head);
+struct tailhead *headp;			/* Tail queue head. */
+struct entry {
+	...
+	TAILQ_ENTRY(entry) entries;	/* Tail queue. */
+	...
+} *n1, *n2, *n3, *np;
+
+TAILQ_INIT(&head);			/* Initialize the queue. */
+
+n1 = malloc(sizeof(struct entry));	/* Insert at the head. */
+TAILQ_INSERT_HEAD(&head, n1, entries);
+
+n1 = malloc(sizeof(struct entry));	/* Insert at the tail. */
+TAILQ_INSERT_TAIL(&head, n1, entries);
+
+n2 = malloc(sizeof(struct entry));	/* Insert after. */
+TAILQ_INSERT_AFTER(&head, n1, n2, entries);
+
+n3 = malloc(sizeof(struct entry));	/* Insert before. */
+TAILQ_INSERT_BEFORE(n2, n3, entries);
+
+TAILQ_REMOVE(&head, n2, entries);	/* Deletion. */
+free(n2);
+					/* Forward traversal. */
+TAILQ_FOREACH(np, &head, entries)
+	np-> ...
+					/* Safe forward traversal. */
+TAILQ_FOREACH_SAFE(np, &head, entries, np_temp) {
+	np->do_stuff();
+	...
+	TAILQ_REMOVE(&head, np, entries);
+	free(np);
+}
+					/* Reverse traversal. */
+TAILQ_FOREACH_REVERSE(np, &head, tailhead, entries)
+	np-> ...
+					/* TailQ Deletion. */
+while (!TAILQ_EMPTY(&head)) {
+	n1 = TAILQ_FIRST(&head);
+	TAILQ_REMOVE(&head, n1, entries);
+	free(n1);
+}
+					/* Faster TailQ Deletion. */
+n1 = TAILQ_FIRST(&head);
+while (n1 != NULL) {
+	n2 = TAILQ_NEXT(n1, entries);
+	free(n1);
+	n1 = n2;
+}
+TAILQ_INIT(&head);
+.Ed
+.Sh SEE ALSO
+.Xr tree 3
+.Sh HISTORY
+The
+.Nm queue
+functions first appeared in
+.Bx 4.4 .
diff --git a/tools/libxl/external/bsd-sys-queue.h b/tools/libxl/external/bsd-sys-queue.h
new file mode 100644
index 0000000..274e636
--- /dev/null
+++ b/tools/libxl/external/bsd-sys-queue.h
@@ -0,0 +1,637 @@
+/*-
+ * Copyright (c) 1991, 1993
+ *	The Regents of the University of California.  All rights reserved.
+ *
+ * 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.
+ * 4. Neither the name of the University 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 REGENTS 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 REGENTS 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.
+ *
+ *	@(#)queue.h	8.5 (Berkeley) 8/20/94
+ * $FreeBSD$
+ */
+
+#ifndef _SYS_QUEUE_H_
+#define	_SYS_QUEUE_H_
+
+#include <sys/cdefs.h>
+
+/*
+ * This file defines four types of data structures: singly-linked lists,
+ * singly-linked tail queues, lists and tail queues.
+ *
+ * A singly-linked list is headed by a single forward pointer. The elements
+ * are singly linked for minimum space and pointer manipulation overhead at
+ * the expense of O(n) removal for arbitrary elements. New elements can be
+ * added to the list after an existing element or at the head of the list.
+ * Elements being removed from the head of the list should use the explicit
+ * macro for this purpose for optimum efficiency. A singly-linked list may
+ * only be traversed in the forward direction.  Singly-linked lists are ideal
+ * for applications with large datasets and few or no removals or for
+ * implementing a LIFO queue.
+ *
+ * A singly-linked tail queue is headed by a pair of pointers, one to the
+ * head of the list and the other to the tail of the list. The elements are
+ * singly linked for minimum space and pointer manipulation overhead at the
+ * expense of O(n) removal for arbitrary elements. New elements can be added
+ * to the list after an existing element, at the head of the list, or at the
+ * end of the list. Elements being removed from the head of the tail queue
+ * should use the explicit macro for this purpose for optimum efficiency.
+ * A singly-linked tail queue may only be traversed in the forward direction.
+ * Singly-linked tail queues are ideal for applications with large datasets
+ * and few or no removals or for implementing a FIFO queue.
+ *
+ * A list is headed by a single forward pointer (or an array of forward
+ * pointers for a hash table header). The elements are doubly linked
+ * so that an arbitrary element can be removed without a need to
+ * traverse the list. New elements can be added to the list before
+ * or after an existing element or at the head of the list. A list
+ * may only be traversed in the forward direction.
+ *
+ * A tail queue is headed by a pair of pointers, one to the head of the
+ * list and the other to the tail of the list. The elements are doubly
+ * linked so that an arbitrary element can be removed without a need to
+ * traverse the list. New elements can be added to the list before or
+ * after an existing element, at the head of the list, or at the end of
+ * the list. A tail queue may be traversed in either direction.
+ *
+ * For details on the use of these macros, see the queue(3) manual page.
+ *
+ *
+ *				SLIST	LIST	STAILQ	TAILQ
+ * _HEAD			+	+	+	+
+ * _HEAD_INITIALIZER		+	+	+	+
+ * _ENTRY			+	+	+	+
+ * _INIT			+	+	+	+
+ * _EMPTY			+	+	+	+
+ * _FIRST			+	+	+	+
+ * _NEXT			+	+	+	+
+ * _PREV			-	-	-	+
+ * _LAST			-	-	+	+
+ * _FOREACH			+	+	+	+
+ * _FOREACH_SAFE		+	+	+	+
+ * _FOREACH_REVERSE		-	-	-	+
+ * _FOREACH_REVERSE_SAFE	-	-	-	+
+ * _INSERT_HEAD			+	+	+	+
+ * _INSERT_BEFORE		-	+	-	+
+ * _INSERT_AFTER		+	+	+	+
+ * _INSERT_TAIL			-	-	+	+
+ * _CONCAT			-	-	+	+
+ * _REMOVE_AFTER		+	-	+	-
+ * _REMOVE_HEAD			+	-	+	-
+ * _REMOVE			+	+	+	+
+ * _SWAP			+	+	+	+
+ *
+ */
+#ifdef QUEUE_MACRO_DEBUG
+/* Store the last 2 places the queue element or head was altered */
+struct qm_trace {
+	char * lastfile;
+	int lastline;
+	char * prevfile;
+	int prevline;
+};
+
+#define	TRACEBUF	struct qm_trace trace;
+#define	TRASHIT(x)	do {(x) = (void *)-1;} while (0)
+#define	QMD_SAVELINK(name, link)	void **name = (void *)&(link)
+
+#define	QMD_TRACE_HEAD(head) do {					\
+	(head)->trace.prevline = (head)->trace.lastline;		\
+	(head)->trace.prevfile = (head)->trace.lastfile;		\
+	(head)->trace.lastline = __LINE__;				\
+	(head)->trace.lastfile = __FILE__;				\
+} while (0)
+
+#define	QMD_TRACE_ELEM(elem) do {					\
+	(elem)->trace.prevline = (elem)->trace.lastline;		\
+	(elem)->trace.prevfile = (elem)->trace.lastfile;		\
+	(elem)->trace.lastline = __LINE__;				\
+	(elem)->trace.lastfile = __FILE__;				\
+} while (0)
+
+#else
+#define	QMD_TRACE_ELEM(elem)
+#define	QMD_TRACE_HEAD(head)
+#define	QMD_SAVELINK(name, link)
+#define	TRACEBUF
+#define	TRASHIT(x)
+#endif	/* QUEUE_MACRO_DEBUG */
+
+/*
+ * Singly-linked List declarations.
+ */
+#define	SLIST_HEAD(name, type)						\
+struct name {								\
+	struct type *slh_first;	/* first element */			\
+}
+
+#define	SLIST_HEAD_INITIALIZER(head)					\
+	{ NULL }
+
+#define	SLIST_ENTRY(type)						\
+struct {								\
+	struct type *sle_next;	/* next element */			\
+}
+
+/*
+ * Singly-linked List functions.
+ */
+#define	SLIST_EMPTY(head)	((head)->slh_first == NULL)
+
+#define	SLIST_FIRST(head)	((head)->slh_first)
+
+#define	SLIST_FOREACH(var, head, field)					\
+	for ((var) = SLIST_FIRST((head));				\
+	    (var);							\
+	    (var) = SLIST_NEXT((var), field))
+
+#define	SLIST_FOREACH_SAFE(var, head, field, tvar)			\
+	for ((var) = SLIST_FIRST((head));				\
+	    (var) && ((tvar) = SLIST_NEXT((var), field), 1);		\
+	    (var) = (tvar))
+
+#define	SLIST_FOREACH_PREVPTR(var, varp, head, field)			\
+	for ((varp) = &SLIST_FIRST((head));				\
+	    ((var) = *(varp)) != NULL;					\
+	    (varp) = &SLIST_NEXT((var), field))
+
+#define	SLIST_INIT(head) do {						\
+	SLIST_FIRST((head)) = NULL;					\
+} while (0)
+
+#define	SLIST_INSERT_AFTER(slistelm, elm, field) do {			\
+	SLIST_NEXT((elm), field) = SLIST_NEXT((slistelm), field);	\
+	SLIST_NEXT((slistelm), field) = (elm);				\
+} while (0)
+
+#define	SLIST_INSERT_HEAD(head, elm, field) do {			\
+	SLIST_NEXT((elm), field) = SLIST_FIRST((head));			\
+	SLIST_FIRST((head)) = (elm);					\
+} while (0)
+
+#define	SLIST_NEXT(elm, field)	((elm)->field.sle_next)
+
+#define	SLIST_REMOVE(head, elm, type, field) do {			\
+	QMD_SAVELINK(oldnext, (elm)->field.sle_next);			\
+	if (SLIST_FIRST((head)) == (elm)) {				\
+		SLIST_REMOVE_HEAD((head), field);			\
+	}								\
+	else {								\
+		struct type *curelm = SLIST_FIRST((head));		\
+		while (SLIST_NEXT(curelm, field) != (elm))		\
+			curelm = SLIST_NEXT(curelm, field);		\
+		SLIST_REMOVE_AFTER(curelm, field);			\
+	}								\
+	TRASHIT(*oldnext);						\
+} while (0)
+
+#define SLIST_REMOVE_AFTER(elm, field) do {				\
+	SLIST_NEXT(elm, field) =					\
+	    SLIST_NEXT(SLIST_NEXT(elm, field), field);			\
+} while (0)
+
+#define	SLIST_REMOVE_HEAD(head, field) do {				\
+	SLIST_FIRST((head)) = SLIST_NEXT(SLIST_FIRST((head)), field);	\
+} while (0)
+
+#define SLIST_SWAP(head1, head2, type) do {				\
+	struct type *swap_first = SLIST_FIRST(head1);			\
+	SLIST_FIRST(head1) = SLIST_FIRST(head2);			\
+	SLIST_FIRST(head2) = swap_first;				\
+} while (0)
+
+/*
+ * Singly-linked Tail queue declarations.
+ */
+#define	STAILQ_HEAD(name, type)						\
+struct name {								\
+	struct type *stqh_first;/* first element */			\
+	struct type **stqh_last;/* addr of last next element */		\
+}
+
+#define	STAILQ_HEAD_INITIALIZER(head)					\
+	{ NULL, &(head).stqh_first }
+
+#define	STAILQ_ENTRY(type)						\
+struct {								\
+	struct type *stqe_next;	/* next element */			\
+}
+
+/*
+ * Singly-linked Tail queue functions.
+ */
+#define	STAILQ_CONCAT(head1, head2) do {				\
+	if (!STAILQ_EMPTY((head2))) {					\
+		*(head1)->stqh_last = (head2)->stqh_first;		\
+		(head1)->stqh_last = (head2)->stqh_last;		\
+		STAILQ_INIT((head2));					\
+	}								\
+} while (0)
+
+#define	STAILQ_EMPTY(head)	((head)->stqh_first == NULL)
+
+#define	STAILQ_FIRST(head)	((head)->stqh_first)
+
+#define	STAILQ_FOREACH(var, head, field)				\
+	for((var) = STAILQ_FIRST((head));				\
+	   (var);							\
+	   (var) = STAILQ_NEXT((var), field))
+
+
+#define	STAILQ_FOREACH_SAFE(var, head, field, tvar)			\
+	for ((var) = STAILQ_FIRST((head));				\
+	    (var) && ((tvar) = STAILQ_NEXT((var), field), 1);		\
+	    (var) = (tvar))
+
+#define	STAILQ_INIT(head) do {						\
+	STAILQ_FIRST((head)) = NULL;					\
+	(head)->stqh_last = &STAILQ_FIRST((head));			\
+} while (0)
+
+#define	STAILQ_INSERT_AFTER(head, tqelm, elm, field) do {		\
+	if ((STAILQ_NEXT((elm), field) = STAILQ_NEXT((tqelm), field)) == NULL)\
+		(head)->stqh_last = &STAILQ_NEXT((elm), field);		\
+	STAILQ_NEXT((tqelm), field) = (elm);				\
+} while (0)
+
+#define	STAILQ_INSERT_HEAD(head, elm, field) do {			\
+	if ((STAILQ_NEXT((elm), field) = STAILQ_FIRST((head))) == NULL)	\
+		(head)->stqh_last = &STAILQ_NEXT((elm), field);		\
+	STAILQ_FIRST((head)) = (elm);					\
+} while (0)
+
+#define	STAILQ_INSERT_TAIL(head, elm, field) do {			\
+	STAILQ_NEXT((elm), field) = NULL;				\
+	*(head)->stqh_last = (elm);					\
+	(head)->stqh_last = &STAILQ_NEXT((elm), field);			\
+} while (0)
+
+#define	STAILQ_LAST(head, type, field)					\
+	(STAILQ_EMPTY((head)) ?						\
+		NULL :							\
+	        ((struct type *)(void *)				\
+		((char *)((head)->stqh_last) - __offsetof(struct type, field))))
+
+#define	STAILQ_NEXT(elm, field)	((elm)->field.stqe_next)
+
+#define	STAILQ_REMOVE(head, elm, type, field) do {			\
+	QMD_SAVELINK(oldnext, (elm)->field.stqe_next);			\
+	if (STAILQ_FIRST((head)) == (elm)) {				\
+		STAILQ_REMOVE_HEAD((head), field);			\
+	}								\
+	else {								\
+		struct type *curelm = STAILQ_FIRST((head));		\
+		while (STAILQ_NEXT(curelm, field) != (elm))		\
+			curelm = STAILQ_NEXT(curelm, field);		\
+		STAILQ_REMOVE_AFTER(head, curelm, field);		\
+	}								\
+	TRASHIT(*oldnext);						\
+} while (0)
+
+#define STAILQ_REMOVE_AFTER(head, elm, field) do {			\
+	if ((STAILQ_NEXT(elm, field) =					\
+	     STAILQ_NEXT(STAILQ_NEXT(elm, field), field)) == NULL)	\
+		(head)->stqh_last = &STAILQ_NEXT((elm), field);		\
+} while (0)
+
+#define	STAILQ_REMOVE_HEAD(head, field) do {				\
+	if ((STAILQ_FIRST((head)) =					\
+	     STAILQ_NEXT(STAILQ_FIRST((head)), field)) == NULL)		\
+		(head)->stqh_last = &STAILQ_FIRST((head));		\
+} while (0)
+
+#define STAILQ_SWAP(head1, head2, type) do {				\
+	struct type *swap_first = STAILQ_FIRST(head1);			\
+	struct type **swap_last = (head1)->stqh_last;			\
+	STAILQ_FIRST(head1) = STAILQ_FIRST(head2);			\
+	(head1)->stqh_last = (head2)->stqh_last;			\
+	STAILQ_FIRST(head2) = swap_first;				\
+	(head2)->stqh_last = swap_last;					\
+	if (STAILQ_EMPTY(head1))					\
+		(head1)->stqh_last = &STAILQ_FIRST(head1);		\
+	if (STAILQ_EMPTY(head2))					\
+		(head2)->stqh_last = &STAILQ_FIRST(head2);		\
+} while (0)
+
+
+/*
+ * List declarations.
+ */
+#define	LIST_HEAD(name, type)						\
+struct name {								\
+	struct type *lh_first;	/* first element */			\
+}
+
+#define	LIST_HEAD_INITIALIZER(head)					\
+	{ NULL }
+
+#define	LIST_ENTRY(type)						\
+struct {								\
+	struct type *le_next;	/* next element */			\
+	struct type **le_prev;	/* address of previous next element */	\
+}
+
+/*
+ * List functions.
+ */
+
+#if (defined(_KERNEL) && defined(INVARIANTS))
+#define	QMD_LIST_CHECK_HEAD(head, field) do {				\
+	if (LIST_FIRST((head)) != NULL &&				\
+	    LIST_FIRST((head))->field.le_prev !=			\
+	     &LIST_FIRST((head)))					\
+		panic("Bad list head %p first->prev != head", (head));	\
+} while (0)
+
+#define	QMD_LIST_CHECK_NEXT(elm, field) do {				\
+	if (LIST_NEXT((elm), field) != NULL &&				\
+	    LIST_NEXT((elm), field)->field.le_prev !=			\
+	     &((elm)->field.le_next))					\
+	     	panic("Bad link elm %p next->prev != elm", (elm));	\
+} while (0)
+
+#define	QMD_LIST_CHECK_PREV(elm, field) do {				\
+	if (*(elm)->field.le_prev != (elm))				\
+		panic("Bad link elm %p prev->next != elm", (elm));	\
+} while (0)
+#else
+#define	QMD_LIST_CHECK_HEAD(head, field)
+#define	QMD_LIST_CHECK_NEXT(elm, field)
+#define	QMD_LIST_CHECK_PREV(elm, field)
+#endif /* (_KERNEL && INVARIANTS) */
+
+#define	LIST_EMPTY(head)	((head)->lh_first == NULL)
+
+#define	LIST_FIRST(head)	((head)->lh_first)
+
+#define	LIST_FOREACH(var, head, field)					\
+	for ((var) = LIST_FIRST((head));				\
+	    (var);							\
+	    (var) = LIST_NEXT((var), field))
+
+#define	LIST_FOREACH_SAFE(var, head, field, tvar)			\
+	for ((var) = LIST_FIRST((head));				\
+	    (var) && ((tvar) = LIST_NEXT((var), field), 1);		\
+	    (var) = (tvar))
+
+#define	LIST_INIT(head) do {						\
+	LIST_FIRST((head)) = NULL;					\
+} while (0)
+
+#define	LIST_INSERT_AFTER(listelm, elm, field) do {			\
+	QMD_LIST_CHECK_NEXT(listelm, field);				\
+	if ((LIST_NEXT((elm), field) = LIST_NEXT((listelm), field)) != NULL)\
+		LIST_NEXT((listelm), field)->field.le_prev =		\
+		    &LIST_NEXT((elm), field);				\
+	LIST_NEXT((listelm), field) = (elm);				\
+	(elm)->field.le_prev = &LIST_NEXT((listelm), field);		\
+} while (0)
+
+#define	LIST_INSERT_BEFORE(listelm, elm, field) do {			\
+	QMD_LIST_CHECK_PREV(listelm, field);				\
+	(elm)->field.le_prev = (listelm)->field.le_prev;		\
+	LIST_NEXT((elm), field) = (listelm);				\
+	*(listelm)->field.le_prev = (elm);				\
+	(listelm)->field.le_prev = &LIST_NEXT((elm), field);		\
+} while (0)
+
+#define	LIST_INSERT_HEAD(head, elm, field) do {				\
+	QMD_LIST_CHECK_HEAD((head), field);				\
+	if ((LIST_NEXT((elm), field) = LIST_FIRST((head))) != NULL)	\
+		LIST_FIRST((head))->field.le_prev = &LIST_NEXT((elm), field);\
+	LIST_FIRST((head)) = (elm);					\
+	(elm)->field.le_prev = &LIST_FIRST((head));			\
+} while (0)
+
+#define	LIST_NEXT(elm, field)	((elm)->field.le_next)
+
+#define	LIST_REMOVE(elm, field) do {					\
+	QMD_SAVELINK(oldnext, (elm)->field.le_next);			\
+	QMD_SAVELINK(oldprev, (elm)->field.le_prev);			\
+	QMD_LIST_CHECK_NEXT(elm, field);				\
+	QMD_LIST_CHECK_PREV(elm, field);				\
+	if (LIST_NEXT((elm), field) != NULL)				\
+		LIST_NEXT((elm), field)->field.le_prev = 		\
+		    (elm)->field.le_prev;				\
+	*(elm)->field.le_prev = LIST_NEXT((elm), field);		\
+	TRASHIT(*oldnext);						\
+	TRASHIT(*oldprev);						\
+} while (0)
+
+#define LIST_SWAP(head1, head2, type, field) do {			\
+	struct type *swap_tmp = LIST_FIRST((head1));			\
+	LIST_FIRST((head1)) = LIST_FIRST((head2));			\
+	LIST_FIRST((head2)) = swap_tmp;					\
+	if ((swap_tmp = LIST_FIRST((head1))) != NULL)			\
+		swap_tmp->field.le_prev = &LIST_FIRST((head1));		\
+	if ((swap_tmp = LIST_FIRST((head2))) != NULL)			\
+		swap_tmp->field.le_prev = &LIST_FIRST((head2));		\
+} while (0)
+
+/*
+ * Tail queue declarations.
+ */
+#define	TAILQ_HEAD(name, type)						\
+struct name {								\
+	struct type *tqh_first;	/* first element */			\
+	struct type **tqh_last;	/* addr of last next element */		\
+	TRACEBUF							\
+}
+
+#define	TAILQ_HEAD_INITIALIZER(head)					\
+	{ NULL, &(head).tqh_first }
+
+#define	TAILQ_ENTRY(type)						\
+struct {								\
+	struct type *tqe_next;	/* next element */			\
+	struct type **tqe_prev;	/* address of previous next element */	\
+	TRACEBUF							\
+}
+
+/*
+ * Tail queue functions.
+ */
+#if (defined(_KERNEL) && defined(INVARIANTS))
+#define	QMD_TAILQ_CHECK_HEAD(head, field) do {				\
+	if (!TAILQ_EMPTY(head) &&					\
+	    TAILQ_FIRST((head))->field.tqe_prev !=			\
+	     &TAILQ_FIRST((head)))					\
+		panic("Bad tailq head %p first->prev != head", (head));	\
+} while (0)
+
+#define	QMD_TAILQ_CHECK_TAIL(head, field) do {				\
+	if (*(head)->tqh_last != NULL)					\
+	    	panic("Bad tailq NEXT(%p->tqh_last) != NULL", (head)); 	\
+} while (0)
+
+#define	QMD_TAILQ_CHECK_NEXT(elm, field) do {				\
+	if (TAILQ_NEXT((elm), field) != NULL &&				\
+	    TAILQ_NEXT((elm), field)->field.tqe_prev !=			\
+	     &((elm)->field.tqe_next))					\
+		panic("Bad link elm %p next->prev != elm", (elm));	\
+} while (0)
+
+#define	QMD_TAILQ_CHECK_PREV(elm, field) do {				\
+	if (*(elm)->field.tqe_prev != (elm))				\
+		panic("Bad link elm %p prev->next != elm", (elm));	\
+} while (0)
+#else
+#define	QMD_TAILQ_CHECK_HEAD(head, field)
+#define	QMD_TAILQ_CHECK_TAIL(head, headname)
+#define	QMD_TAILQ_CHECK_NEXT(elm, field)
+#define	QMD_TAILQ_CHECK_PREV(elm, field)
+#endif /* (_KERNEL && INVARIANTS) */
+
+#define	TAILQ_CONCAT(head1, head2, field) do {				\
+	if (!TAILQ_EMPTY(head2)) {					\
+		*(head1)->tqh_last = (head2)->tqh_first;		\
+		(head2)->tqh_first->field.tqe_prev = (head1)->tqh_last;	\
+		(head1)->tqh_last = (head2)->tqh_last;			\
+		TAILQ_INIT((head2));					\
+		QMD_TRACE_HEAD(head1);					\
+		QMD_TRACE_HEAD(head2);					\
+	}								\
+} while (0)
+
+#define	TAILQ_EMPTY(head)	((head)->tqh_first == NULL)
+
+#define	TAILQ_FIRST(head)	((head)->tqh_first)
+
+#define	TAILQ_FOREACH(var, head, field)					\
+	for ((var) = TAILQ_FIRST((head));				\
+	    (var);							\
+	    (var) = TAILQ_NEXT((var), field))
+
+#define	TAILQ_FOREACH_SAFE(var, head, field, tvar)			\
+	for ((var) = TAILQ_FIRST((head));				\
+	    (var) && ((tvar) = TAILQ_NEXT((var), field), 1);		\
+	    (var) = (tvar))
+
+#define	TAILQ_FOREACH_REVERSE(var, head, headname, field)		\
+	for ((var) = TAILQ_LAST((head), headname);			\
+	    (var);							\
+	    (var) = TAILQ_PREV((var), headname, field))
+
+#define	TAILQ_FOREACH_REVERSE_SAFE(var, head, headname, field, tvar)	\
+	for ((var) = TAILQ_LAST((head), headname);			\
+	    (var) && ((tvar) = TAILQ_PREV((var), headname, field), 1);	\
+	    (var) = (tvar))
+
+#define	TAILQ_INIT(head) do {						\
+	TAILQ_FIRST((head)) = NULL;					\
+	(head)->tqh_last = &TAILQ_FIRST((head));			\
+	QMD_TRACE_HEAD(head);						\
+} while (0)
+
+#define	TAILQ_INSERT_AFTER(head, listelm, elm, field) do {		\
+	QMD_TAILQ_CHECK_NEXT(listelm, field);				\
+	if ((TAILQ_NEXT((elm), field) = TAILQ_NEXT((listelm), field)) != NULL)\
+		TAILQ_NEXT((elm), field)->field.tqe_prev = 		\
+		    &TAILQ_NEXT((elm), field);				\
+	else {								\
+		(head)->tqh_last = &TAILQ_NEXT((elm), field);		\
+		QMD_TRACE_HEAD(head);					\
+	}								\
+	TAILQ_NEXT((listelm), field) = (elm);				\
+	(elm)->field.tqe_prev = &TAILQ_NEXT((listelm), field);		\
+	QMD_TRACE_ELEM(&(elm)->field);					\
+	QMD_TRACE_ELEM(&listelm->field);				\
+} while (0)
+
+#define	TAILQ_INSERT_BEFORE(listelm, elm, field) do {			\
+	QMD_TAILQ_CHECK_PREV(listelm, field);				\
+	(elm)->field.tqe_prev = (listelm)->field.tqe_prev;		\
+	TAILQ_NEXT((elm), field) = (listelm);				\
+	*(listelm)->field.tqe_prev = (elm);				\
+	(listelm)->field.tqe_prev = &TAILQ_NEXT((elm), field);		\
+	QMD_TRACE_ELEM(&(elm)->field);					\
+	QMD_TRACE_ELEM(&listelm->field);				\
+} while (0)
+
+#define	TAILQ_INSERT_HEAD(head, elm, field) do {			\
+	QMD_TAILQ_CHECK_HEAD(head, field);				\
+	if ((TAILQ_NEXT((elm), field) = TAILQ_FIRST((head))) != NULL)	\
+		TAILQ_FIRST((head))->field.tqe_prev =			\
+		    &TAILQ_NEXT((elm), field);				\
+	else								\
+		(head)->tqh_last = &TAILQ_NEXT((elm), field);		\
+	TAILQ_FIRST((head)) = (elm);					\
+	(elm)->field.tqe_prev = &TAILQ_FIRST((head));			\
+	QMD_TRACE_HEAD(head);						\
+	QMD_TRACE_ELEM(&(elm)->field);					\
+} while (0)
+
+#define	TAILQ_INSERT_TAIL(head, elm, field) do {			\
+	QMD_TAILQ_CHECK_TAIL(head, field);				\
+	TAILQ_NEXT((elm), field) = NULL;				\
+	(elm)->field.tqe_prev = (head)->tqh_last;			\
+	*(head)->tqh_last = (elm);					\
+	(head)->tqh_last = &TAILQ_NEXT((elm), field);			\
+	QMD_TRACE_HEAD(head);						\
+	QMD_TRACE_ELEM(&(elm)->field);					\
+} while (0)
+
+#define	TAILQ_LAST(head, headname)					\
+	(*(((struct headname *)((head)->tqh_last))->tqh_last))
+
+#define	TAILQ_NEXT(elm, field) ((elm)->field.tqe_next)
+
+#define	TAILQ_PREV(elm, headname, field)				\
+	(*(((struct headname *)((elm)->field.tqe_prev))->tqh_last))
+
+#define	TAILQ_REMOVE(head, elm, field) do {				\
+	QMD_SAVELINK(oldnext, (elm)->field.tqe_next);			\
+	QMD_SAVELINK(oldprev, (elm)->field.tqe_prev);			\
+	QMD_TAILQ_CHECK_NEXT(elm, field);				\
+	QMD_TAILQ_CHECK_PREV(elm, field);				\
+	if ((TAILQ_NEXT((elm), field)) != NULL)				\
+		TAILQ_NEXT((elm), field)->field.tqe_prev = 		\
+		    (elm)->field.tqe_prev;				\
+	else {								\
+		(head)->tqh_last = (elm)->field.tqe_prev;		\
+		QMD_TRACE_HEAD(head);					\
+	}								\
+	*(elm)->field.tqe_prev = TAILQ_NEXT((elm), field);		\
+	TRASHIT(*oldnext);						\
+	TRASHIT(*oldprev);						\
+	QMD_TRACE_ELEM(&(elm)->field);					\
+} while (0)
+
+#define TAILQ_SWAP(head1, head2, type, field) do {			\
+	struct type *swap_first = (head1)->tqh_first;			\
+	struct type **swap_last = (head1)->tqh_last;			\
+	(head1)->tqh_first = (head2)->tqh_first;			\
+	(head1)->tqh_last = (head2)->tqh_last;				\
+	(head2)->tqh_first = swap_first;				\
+	(head2)->tqh_last = swap_last;					\
+	if ((swap_first = (head1)->tqh_first) != NULL)			\
+		swap_first->field.tqe_prev = &(head1)->tqh_first;	\
+	else								\
+		(head1)->tqh_last = &(head1)->tqh_first;		\
+	if ((swap_first = (head2)->tqh_first) != NULL)			\
+		swap_first->field.tqe_prev = &(head2)->tqh_first;	\
+	else								\
+		(head2)->tqh_last = &(head2)->tqh_first;		\
+} while (0)
+
+#endif /* !_SYS_QUEUE_H_ */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 18:55:50 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 18: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.xensource.com>)
	id 1RZ5bd-0001DA-4r; Fri, 09 Dec 2011 18:55:37 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RZ5bb-0001Am-1Y
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 18:55:35 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1323456879!6616386!7
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI2MQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21328 invoked from network); 9 Dec 2011 18:54:45 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 18:54:45 -0000
X-IronPort-AV: E=Sophos;i="4.71,327,1320624000"; 
   d="scan'208";a="9392198"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 18:54:45 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 18:54:44 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RZ5am-0002e0-Q4; Fri, 09 Dec 2011 18:54:44 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RZ5am-00040J-PI;
	Fri, 09 Dec 2011 18:54:44 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Fri, 9 Dec 2011 18:54:25 +0000
Message-ID: <1323456877-15315-7-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1323456877-15315-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1323456877-15315-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 06/18] libxl: permit declaration after statement
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

GCC and C99 allow declarations to be mixed with code.  This is a good
idea because:

 * It allows variables to be more often initialised as they are
   declared, thus reducing the occurrence of uninitialised variable
   errors.

 * Certain alloca-like constructs (arrays allocated at runtime on the
   stack) can more often be written without a spurious { } block.
   Such blocks are confusing to read.

 * It makes it easier to write and use macros which declare and
   initialise formulaic variables and do other function setup code,
   because there is no need to worry that such macros might be
   incompatible with each other or have strict ordering constraints.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/Makefile |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index 7a0c03c..70c9c1c 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -11,7 +11,8 @@ MINOR = 0
 XLUMAJOR = 1.0
 XLUMINOR = 0
 
-CFLAGS += -Werror -Wno-format-zero-length -Wmissing-declarations
+CFLAGS += -Werror -Wno-format-zero-length -Wmissing-declarations \
+	-Wno-declaration-after-statement
 CFLAGS += -I. -fPIC
 
 ifeq ($(CONFIG_Linux),y)
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 18:55:50 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 18: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.xensource.com>)
	id 1RZ5bh-0001Gk-4E; Fri, 09 Dec 2011 18:55:41 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RZ5bf-0001Bc-Fy
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 18:55:39 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1323456879!6616386!16
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI2MQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21495 invoked from network); 9 Dec 2011 18:54:49 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 18:54:49 -0000
X-IronPort-AV: E=Sophos;i="4.71,327,1320624000"; 
   d="scan'208";a="9392207"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 18:54:49 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 18:54:49 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RZ5ar-0002eR-5g; Fri, 09 Dec 2011 18:54:49 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RZ5ar-00040t-4v;
	Fri, 09 Dec 2011 18:54:49 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Fri, 9 Dec 2011 18:54:34 +0000
Message-ID: <1323456877-15315-16-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1323456877-15315-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1323456877-15315-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 15/18] xenstore: New function xs_path_is_subpath
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This utility function compares two paths, textually and reports
whether one is a subpath (a child path) of the other.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/xenstore/xs.c |   17 +++++++++++++++++
 tools/xenstore/xs.h |    7 +++++++
 2 files changed, 24 insertions(+), 0 deletions(-)

diff --git a/tools/xenstore/xs.c b/tools/xenstore/xs.c
index 8e54fe0..0a01675 100644
--- a/tools/xenstore/xs.c
+++ b/tools/xenstore/xs.c
@@ -950,6 +950,23 @@ char *xs_get_domain_path(struct xs_handle *h, unsigned int domid)
 	return xs_single(h, XBT_NULL, XS_GET_DOMAIN_PATH, domid_str, NULL);
 }
 
+bool xs_path_is_subpath(const char *parent, const char *child)
+{
+        size_t childlen = strlen(child);
+        size_t parentlen = strlen(parent);
+
+	if (childlen < parentlen)
+		return false;
+
+	if (memcmp(child, parent, parentlen))
+		return false;
+
+	if (childlen > parentlen && child[parentlen] != '/')
+		return false;
+
+	return true;
+}
+
 bool xs_is_domain_introduced(struct xs_handle *h, unsigned int domid)
 {
 	char *domain = single_with_domid(h, XS_IS_DOMAIN_INTRODUCED, domid);
diff --git a/tools/xenstore/xs.h b/tools/xenstore/xs.h
index 63f535d..8d49e50 100644
--- a/tools/xenstore/xs.h
+++ b/tools/xenstore/xs.h
@@ -207,6 +207,13 @@ bool xs_release_domain(struct xs_handle *h, unsigned int domid);
  */
 char *xs_get_domain_path(struct xs_handle *h, unsigned int domid);
 
+/* Returns true if child is either equal to parent, or a node underneath
+ * parent; or false otherwise.  Done by string comparison, so relative and
+ * absolute pathnames never in a parent/child relationship by this
+ * definition.  Cannot fail.
+ */
+bool xs_path_is_subpath(const char *parent, const char *child);
+
 /* Return whether the domain specified has been introduced to xenstored.
  */
 bool xs_is_domain_introduced(struct xs_handle *h, unsigned int domid);
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 18:55:50 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 18: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.xensource.com>)
	id 1RZ5bc-0001CS-C1; Fri, 09 Dec 2011 18:55:36 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RZ5ba-0001Ak-Az
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 18:55:34 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1323456879!6616386!6
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI2MQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21282 invoked from network); 9 Dec 2011 18:54:44 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 18:54:44 -0000
X-IronPort-AV: E=Sophos;i="4.71,327,1320624000"; 
   d="scan'208";a="9392197"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 18:54:44 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 18:54:44 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RZ5am-0002dx-15; Fri, 09 Dec 2011 18:54:44 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RZ5am-00040C-0J;
	Fri, 09 Dec 2011 18:54:44 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 9 Dec 2011 18:54:24 +0000
Message-ID: <1323456877-15315-6-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1323456877-15315-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1323456877-15315-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 05/18] libxl: idl: Provide struct and union tags
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Instead of generating:

   typedef struct {
     ...
   } libxl_foo;

Produce:

   typedef struct libxl_foo {
     ...
   } libxl_foo;

This makes it possible to refer to libxl idl-generated structs and
unions, as incomplete types, before they have been defined.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/gentypes.py |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/tools/libxl/gentypes.py b/tools/libxl/gentypes.py
index d8f43e3..7ca6375 100644
--- a/tools/libxl/gentypes.py
+++ b/tools/libxl/gentypes.py
@@ -56,7 +56,7 @@ def libxl_C_type_define(ty, indent = ""):
         if ty.typename is None:
             s += "%s {\n" % ty.kind
         else:
-            s += "typedef %s {\n" % ty.kind
+            s += "typedef %s %s {\n" % (ty.kind, ty.typename)
 
         for f in ty.fields:
             if f.comment is not None:
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 18:55:50 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 18: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.xensource.com>)
	id 1RZ5bh-0001Gk-4E; Fri, 09 Dec 2011 18:55:41 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RZ5bf-0001Bc-Fy
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 18:55:39 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1323456879!6616386!16
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI2MQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21495 invoked from network); 9 Dec 2011 18:54:49 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 18:54:49 -0000
X-IronPort-AV: E=Sophos;i="4.71,327,1320624000"; 
   d="scan'208";a="9392207"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 18:54:49 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 18:54:49 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RZ5ar-0002eR-5g; Fri, 09 Dec 2011 18:54:49 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RZ5ar-00040t-4v;
	Fri, 09 Dec 2011 18:54:49 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Fri, 9 Dec 2011 18:54:34 +0000
Message-ID: <1323456877-15315-16-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1323456877-15315-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1323456877-15315-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 15/18] xenstore: New function xs_path_is_subpath
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This utility function compares two paths, textually and reports
whether one is a subpath (a child path) of the other.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/xenstore/xs.c |   17 +++++++++++++++++
 tools/xenstore/xs.h |    7 +++++++
 2 files changed, 24 insertions(+), 0 deletions(-)

diff --git a/tools/xenstore/xs.c b/tools/xenstore/xs.c
index 8e54fe0..0a01675 100644
--- a/tools/xenstore/xs.c
+++ b/tools/xenstore/xs.c
@@ -950,6 +950,23 @@ char *xs_get_domain_path(struct xs_handle *h, unsigned int domid)
 	return xs_single(h, XBT_NULL, XS_GET_DOMAIN_PATH, domid_str, NULL);
 }
 
+bool xs_path_is_subpath(const char *parent, const char *child)
+{
+        size_t childlen = strlen(child);
+        size_t parentlen = strlen(parent);
+
+	if (childlen < parentlen)
+		return false;
+
+	if (memcmp(child, parent, parentlen))
+		return false;
+
+	if (childlen > parentlen && child[parentlen] != '/')
+		return false;
+
+	return true;
+}
+
 bool xs_is_domain_introduced(struct xs_handle *h, unsigned int domid)
 {
 	char *domain = single_with_domid(h, XS_IS_DOMAIN_INTRODUCED, domid);
diff --git a/tools/xenstore/xs.h b/tools/xenstore/xs.h
index 63f535d..8d49e50 100644
--- a/tools/xenstore/xs.h
+++ b/tools/xenstore/xs.h
@@ -207,6 +207,13 @@ bool xs_release_domain(struct xs_handle *h, unsigned int domid);
  */
 char *xs_get_domain_path(struct xs_handle *h, unsigned int domid);
 
+/* Returns true if child is either equal to parent, or a node underneath
+ * parent; or false otherwise.  Done by string comparison, so relative and
+ * absolute pathnames never in a parent/child relationship by this
+ * definition.  Cannot fail.
+ */
+bool xs_path_is_subpath(const char *parent, const char *child);
+
 /* Return whether the domain specified has been introduced to xenstored.
  */
 bool xs_is_domain_introduced(struct xs_handle *h, unsigned int domid);
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 18:55:50 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 18: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.xensource.com>)
	id 1RZ5bc-0001CS-C1; Fri, 09 Dec 2011 18:55:36 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RZ5ba-0001Ak-Az
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 18:55:34 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1323456879!6616386!6
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI2MQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21282 invoked from network); 9 Dec 2011 18:54:44 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 18:54:44 -0000
X-IronPort-AV: E=Sophos;i="4.71,327,1320624000"; 
   d="scan'208";a="9392197"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 18:54:44 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 18:54:44 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RZ5am-0002dx-15; Fri, 09 Dec 2011 18:54:44 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RZ5am-00040C-0J;
	Fri, 09 Dec 2011 18:54:44 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 9 Dec 2011 18:54:24 +0000
Message-ID: <1323456877-15315-6-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1323456877-15315-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1323456877-15315-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 05/18] libxl: idl: Provide struct and union tags
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Instead of generating:

   typedef struct {
     ...
   } libxl_foo;

Produce:

   typedef struct libxl_foo {
     ...
   } libxl_foo;

This makes it possible to refer to libxl idl-generated structs and
unions, as incomplete types, before they have been defined.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/gentypes.py |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/tools/libxl/gentypes.py b/tools/libxl/gentypes.py
index d8f43e3..7ca6375 100644
--- a/tools/libxl/gentypes.py
+++ b/tools/libxl/gentypes.py
@@ -56,7 +56,7 @@ def libxl_C_type_define(ty, indent = ""):
         if ty.typename is None:
             s += "%s {\n" % ty.kind
         else:
-            s += "typedef %s {\n" % ty.kind
+            s += "typedef %s %s {\n" % (ty.kind, ty.typename)
 
         for f in ty.fields:
             if f.comment is not None:
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 18:55:50 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 18: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.xensource.com>)
	id 1RZ5bd-0001DA-4r; Fri, 09 Dec 2011 18:55:37 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RZ5bb-0001Am-1Y
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 18:55:35 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1323456879!6616386!7
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI2MQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21328 invoked from network); 9 Dec 2011 18:54:45 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 18:54:45 -0000
X-IronPort-AV: E=Sophos;i="4.71,327,1320624000"; 
   d="scan'208";a="9392198"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 18:54:45 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 18:54:44 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RZ5am-0002e0-Q4; Fri, 09 Dec 2011 18:54:44 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RZ5am-00040J-PI;
	Fri, 09 Dec 2011 18:54:44 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Fri, 9 Dec 2011 18:54:25 +0000
Message-ID: <1323456877-15315-7-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1323456877-15315-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1323456877-15315-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 06/18] libxl: permit declaration after statement
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

GCC and C99 allow declarations to be mixed with code.  This is a good
idea because:

 * It allows variables to be more often initialised as they are
   declared, thus reducing the occurrence of uninitialised variable
   errors.

 * Certain alloca-like constructs (arrays allocated at runtime on the
   stack) can more often be written without a spurious { } block.
   Such blocks are confusing to read.

 * It makes it easier to write and use macros which declare and
   initialise formulaic variables and do other function setup code,
   because there is no need to worry that such macros might be
   incompatible with each other or have strict ordering constraints.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/Makefile |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index 7a0c03c..70c9c1c 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -11,7 +11,8 @@ MINOR = 0
 XLUMAJOR = 1.0
 XLUMINOR = 0
 
-CFLAGS += -Werror -Wno-format-zero-length -Wmissing-declarations
+CFLAGS += -Werror -Wno-format-zero-length -Wmissing-declarations \
+	-Wno-declaration-after-statement
 CFLAGS += -I. -fPIC
 
 ifeq ($(CONFIG_Linux),y)
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 18:55:50 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 18: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.xensource.com>)
	id 1RZ5bb-0001CC-SQ; Fri, 09 Dec 2011 18:55:35 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RZ5bZ-0001Ah-UI
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 18:55:34 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1323456879!6616386!4
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI2MQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21252 invoked from network); 9 Dec 2011 18:54:43 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 18:54:43 -0000
X-IronPort-AV: E=Sophos;i="4.71,327,1320624000"; 
   d="scan'208";a="9392195"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 18:54:43 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 18:54:43 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RZ5ak-0002dr-T1; Fri, 09 Dec 2011 18:54:42 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RZ5ak-000402-S9;
	Fri, 09 Dec 2011 18:54:42 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Fri, 9 Dec 2011 18:54:22 +0000
Message-ID: <1323456877-15315-4-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1323456877-15315-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1323456877-15315-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 03/18] libxl: Provide a version of bsd's queue.h
	as _libxl_list.h
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

We would like some linked list macros which are (a) well known to be
sane and (b) typesafe.  BSD's queue.h meets these criteria.

We also provide some simple perlery to arrange to add the libxl_
namespace prefix to the macros.  This will allow us to #include
_libxl_list.h in our public header file without clashing with anyone
else who is also using another version of queue.h.

(A note on copyright: The FreeBSD files we are adding have an
[L]GPL-compatible licence, so there is no need to change our COPYING.
Although FreeBSD's queue.3 still contains the advertising clause, this
has been withdrawn by UCB as recorded in the FreeBSD COPYRIGHT file,
which is included in tools/libxl/external/ for reference.)

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <Ian.campbell@citrix.com>
Tested-by: Roger Pau Monne <roger.pau@entel.upc.edu>
---
 tools/libxl/Makefile                 |   12 +-
 tools/libxl/bsd-sys-queue-h-seddery  |   70 +++
 tools/libxl/external/README          |   14 +
 tools/libxl/external/bsd-COPYRIGHT   |  126 ++++
 tools/libxl/external/bsd-queue.3     | 1044 ++++++++++++++++++++++++++++++++++
 tools/libxl/external/bsd-sys-queue.h |  637 +++++++++++++++++++++
 6 files changed, 1899 insertions(+), 4 deletions(-)
 create mode 100755 tools/libxl/bsd-sys-queue-h-seddery
 create mode 100644 tools/libxl/external/README
 create mode 100644 tools/libxl/external/bsd-COPYRIGHT
 create mode 100644 tools/libxl/external/bsd-queue.3
 create mode 100644 tools/libxl/external/bsd-sys-queue.h

diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index a7a4625..7a0c03c 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -42,7 +42,7 @@ LIBXL_OBJS += _libxl_types.o libxl_flask.o _libxl_types_internal.o
 
 $(LIBXL_OBJS): CFLAGS += $(CFLAGS_libxenctrl) $(CFLAGS_libxenguest) $(CFLAGS_libxenstore) $(CFLAGS_libblktapctl)
 
-AUTOINCS= libxlu_cfg_y.h libxlu_cfg_l.h
+AUTOINCS= libxlu_cfg_y.h libxlu_cfg_l.h _libxl_list.h
 AUTOSRCS= libxlu_cfg_y.c libxlu_cfg_l.c
 LIBXLU_OBJS = libxlu_cfg_y.o libxlu_cfg_l.o libxlu_cfg.o \
 	libxlu_disk_l.o libxlu_disk.o
@@ -55,7 +55,7 @@ $(XL_OBJS): CFLAGS += $(CFLAGS_libxenctrl) # For xentoollog.h
 $(XL_OBJS): CFLAGS += $(CFLAGS_libxenlight)
 
 testidl.o: CFLAGS += $(CFLAGS_libxenctrl) $(CFLAGS_libxenlight)
-testidl.c: libxl_types.idl gentest.py libxl.h
+testidl.c: libxl_types.idl gentest.py libxl.h $(AUTOINCS)
 	$(PYTHON) gentest.py libxl_types.idl testidl.c.new
 	mv testidl.c.new testidl.c
 
@@ -63,7 +63,7 @@ testidl.c: libxl_types.idl gentest.py libxl.h
 all: $(CLIENTS) libxenlight.so libxenlight.a libxlutil.so libxlutil.a \
 	$(AUTOSRCS) $(AUTOINCS)
 
-$(LIBXLU_OBJS): $(AUTOINCS)
+$(LIBXL_OBJS) $(LIBXLU_OBJS) $(XL_OBJS): $(AUTOINCS)
 
 %.c %.h: %.y
 	@rm -f $*.[ch]
@@ -81,6 +81,10 @@ _libxl_paths.h: genpath
 	rm -f $@.tmp
 	$(call move-if-changed,$@.2.tmp,$@)
 
+_libxl_list.h: bsd-sys-queue-h-seddery external/bsd-sys-queue.h
+	perl ./$^ --prefix=libxl >$@.new
+	$(call move-if-changed,$@.new,$@)
+
 libxl_paths.c: _libxl_paths.h
 
 libxl.h: _libxl_types.h
@@ -143,7 +147,7 @@ install: all
 	ln -sf libxlutil.so.$(XLUMAJOR).$(XLUMINOR) $(DESTDIR)$(LIBDIR)/libxlutil.so.$(XLUMAJOR)
 	ln -sf libxlutil.so.$(XLUMAJOR) $(DESTDIR)$(LIBDIR)/libxlutil.so
 	$(INSTALL_DATA) libxlutil.a $(DESTDIR)$(LIBDIR)
-	$(INSTALL_DATA) libxl.h libxl_json.h _libxl_types.h _libxl_types_json.h libxl_utils.h libxl_uuid.h $(DESTDIR)$(INCLUDEDIR)
+	$(INSTALL_DATA) libxl.h libxl_json.h _libxl_types.h _libxl_types_json.h _libxl_list.h libxl_utils.h libxl_uuid.h $(DESTDIR)$(INCLUDEDIR)
 	$(INSTALL_DATA) bash-completion $(DESTDIR)$(BASH_COMPLETION_DIR)/xl.sh
 
 .PHONY: clean
diff --git a/tools/libxl/bsd-sys-queue-h-seddery b/tools/libxl/bsd-sys-queue-h-seddery
new file mode 100755
index 0000000..c0aa079
--- /dev/null
+++ b/tools/libxl/bsd-sys-queue-h-seddery
@@ -0,0 +1,70 @@
+#!/usr/bin/perl -p
+#
+# This script is part of the Xen build system.  It has a very
+# permissive licence to avoid complicating the licence of the
+# generated header file and to allow this seddery to be reused by
+# other projects.
+#
+# Permission is hereby granted, free of charge, to any person
+# obtaining a copy of this individual 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.
+#
+# Copyright (C) 2011 Citrix Ltd
+
+our $namespace, $ucnamespace;
+
+BEGIN {
+    die unless @ARGV;
+    $namespace = pop @ARGV;
+    $namespace =~ s/^--prefix=// or die;
+    $ucnamespace = uc $namespace;
+
+    print <<END or die $!;
+/*
+ * DO NOT EDIT THIS FILE
+ *
+ * Generated automatically by bsd-sys-queue-h-seddery to
+ *  - introduce ${ucnamespace}_ and ${namespace}_ namespace prefixes
+ *  - turn "struct type" into "type" so that type arguments
+ *     to the macros are type names not struct tags
+ *  - remove the reference to sys/cdefs.h, which is not needed
+ *
+ * The purpose of this seddery is to allow the resulting file to be
+ * freely included by software which might also want to include other
+ * list macros; to make it usable when struct tags are not being used
+ * or not known; to make it more portable.
+ */
+END
+}
+
+s/\b( _SYS_QUEUE |
+      SLIST | LIST | STAILQ | TAILQ | QUEUE
+      )/${ucnamespace}_$1/xg;
+
+s/\b( TRACEBUF | TRASHIT |
+      QMD_
+      )/${ucnamespace}__$1/xg;
+
+s/\b(
+      qm_
+      )/${namespace}__$1/xg;
+
+s/\b struct \s+ type \b/type/xg;
+
+s,^\#include.*sys/cdefs.*,/* $& */,xg;
diff --git a/tools/libxl/external/README b/tools/libxl/external/README
new file mode 100644
index 0000000..8c8beea
--- /dev/null
+++ b/tools/libxl/external/README
@@ -0,0 +1,14 @@
+WARNING - DO NOT EDIT THINGS IN THIS DIRECTORY (apart from this README)
+-----------------------------------------------------------------------
+
+These files were obtained elsewhere and should only be updated by
+copying new versions from the source location, as documented below:
+
+bsd-COPYRIGHT
+bsd-sys-queue.h
+bsd-queue.3
+
+  Obtained from the FreeBSD SVN using the following commands:
+    svn co -r 221843 svn://svn.freebsd.org/base/head/sys/sys/
+    svn co -r 221843 svn://svn.freebsd.org/base/head/share/man/man3
+    svn cat -r 221843 http://svn.freebsd.org/base/head/COPYRIGHT >tools/libxl/external/bsd-COPYRIGHT
diff --git a/tools/libxl/external/bsd-COPYRIGHT b/tools/libxl/external/bsd-COPYRIGHT
new file mode 100644
index 0000000..6dc5d16
--- /dev/null
+++ b/tools/libxl/external/bsd-COPYRIGHT
@@ -0,0 +1,126 @@
+# $FreeBSD$
+#	@(#)COPYRIGHT	8.2 (Berkeley) 3/21/94
+
+The compilation of software known as FreeBSD is distributed under the
+following terms:
+
+Copyright (c) 1992-2011 The FreeBSD Project. All rights reserved.
+
+Redistribution and use in source and binary forms, with or without
+modification, are permitted provided that the following conditions
+are met:
+1. Redistributions of source code must retain the above copyright
+   notice, this list of conditions and the following disclaimer.
+2. Redistributions in binary form must reproduce the above copyright
+   notice, this list of conditions and the following disclaimer in the
+   documentation and/or other materials provided with the distribution.
+
+THIS SOFTWARE IS PROVIDED BY THE 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 THE 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.
+
+The 4.4BSD and 4.4BSD-Lite software is distributed under the following
+terms:
+
+All of the documentation and software included in the 4.4BSD and 4.4BSD-Lite
+Releases is copyrighted by The Regents of the University of California.
+
+Copyright 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
+	The Regents of the University of California.  All rights reserved.
+
+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.
+3. All advertising materials mentioning features or use of this software
+   must display the following acknowledgement:
+This product includes software developed by the University of
+California, Berkeley and its contributors.
+4. Neither the name of the University 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 REGENTS 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 REGENTS 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.
+
+The Institute of Electrical and Electronics Engineers and the American
+National Standards Committee X3, on Information Processing Systems have
+given us permission to reprint portions of their documentation.
+
+In the following statement, the phrase ``this text'' refers to portions
+of the system documentation.
+
+Portions of this text are reprinted and reproduced in electronic form in
+the second BSD Networking Software Release, from IEEE Std 1003.1-1988, IEEE
+Standard Portable Operating System Interface for Computer Environments
+(POSIX), copyright C 1988 by the Institute of Electrical and Electronics
+Engineers, Inc.  In the event of any discrepancy between these versions
+and the original IEEE Standard, the original IEEE Standard is the referee
+document.
+
+In the following statement, the phrase ``This material'' refers to portions
+of the system documentation.
+
+This material is reproduced with permission from American National
+Standards Committee X3, on Information Processing Systems.  Computer and
+Business Equipment Manufacturers Association (CBEMA), 311 First St., NW,
+Suite 500, Washington, DC 20001-2178.  The developmental work of
+Programming Language C was completed by the X3J11 Technical Committee.
+
+The views and conclusions contained in the software and documentation are
+those of the authors and should not be interpreted as representing official
+policies, either expressed or implied, of the Regents of the University
+of California.
+
+
+NOTE: The copyright of UC Berkeley's Berkeley Software Distribution ("BSD")
+source has been updated.  The copyright addendum may be found at
+ftp://ftp.cs.berkeley.edu/pub/4bsd/README.Impt.License.Change and is
+included below.
+
+July 22, 1999
+
+To All Licensees, Distributors of Any Version of BSD:
+
+As you know, certain of the Berkeley Software Distribution ("BSD") source
+code files require that further distributions of products containing all or
+portions of the software, acknowledge within their advertising materials
+that such products contain software developed by UC Berkeley and its
+contributors.
+
+Specifically, the provision reads:
+
+"     * 3. All advertising materials mentioning features or use of this software
+      *    must display the following acknowledgement:
+      *    This product includes software developed by the University of
+      *    California, Berkeley and its contributors."
+
+Effective immediately, licensees and distributors are no longer required to
+include the acknowledgement within advertising materials.  Accordingly, the
+foregoing paragraph of those BSD Unix files containing it is hereby deleted
+in its entirety.
+
+William Hoskins
+Director, Office of Technology Licensing
+University of California, Berkeley
diff --git a/tools/libxl/external/bsd-queue.3 b/tools/libxl/external/bsd-queue.3
new file mode 100644
index 0000000..007ca5c
--- /dev/null
+++ b/tools/libxl/external/bsd-queue.3
@@ -0,0 +1,1044 @@
+.\" Copyright (c) 1993
+.\"	The Regents of the University of California.  All rights reserved.
+.\"
+.\" 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.
+.\" 3. All advertising materials mentioning features or use of this software
+.\"    must display the following acknowledgement:
+.\"	This product includes software developed by the University of
+.\"	California, Berkeley and its contributors.
+.\" 4. Neither the name of the University 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 REGENTS 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 REGENTS 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.
+.\"
+.\"	@(#)queue.3	8.2 (Berkeley) 1/24/94
+.\" $FreeBSD$
+.\"
+.Dd May 13, 2011
+.Dt QUEUE 3
+.Os
+.Sh NAME
+.Nm SLIST_EMPTY ,
+.Nm SLIST_ENTRY ,
+.Nm SLIST_FIRST ,
+.Nm SLIST_FOREACH ,
+.Nm SLIST_FOREACH_SAFE ,
+.Nm SLIST_HEAD ,
+.Nm SLIST_HEAD_INITIALIZER ,
+.Nm SLIST_INIT ,
+.Nm SLIST_INSERT_AFTER ,
+.Nm SLIST_INSERT_HEAD ,
+.Nm SLIST_NEXT ,
+.Nm SLIST_REMOVE_AFTER ,
+.Nm SLIST_REMOVE_HEAD ,
+.Nm SLIST_REMOVE ,
+.Nm SLIST_SWAP ,
+.Nm STAILQ_CONCAT ,
+.Nm STAILQ_EMPTY ,
+.Nm STAILQ_ENTRY ,
+.Nm STAILQ_FIRST ,
+.Nm STAILQ_FOREACH ,
+.Nm STAILQ_FOREACH_SAFE ,
+.Nm STAILQ_HEAD ,
+.Nm STAILQ_HEAD_INITIALIZER ,
+.Nm STAILQ_INIT ,
+.Nm STAILQ_INSERT_AFTER ,
+.Nm STAILQ_INSERT_HEAD ,
+.Nm STAILQ_INSERT_TAIL ,
+.Nm STAILQ_LAST ,
+.Nm STAILQ_NEXT ,
+.Nm STAILQ_REMOVE_AFTER ,
+.Nm STAILQ_REMOVE_HEAD ,
+.Nm STAILQ_REMOVE ,
+.Nm STAILQ_SWAP ,
+.Nm LIST_EMPTY ,
+.Nm LIST_ENTRY ,
+.Nm LIST_FIRST ,
+.Nm LIST_FOREACH ,
+.Nm LIST_FOREACH_SAFE ,
+.Nm LIST_HEAD ,
+.Nm LIST_HEAD_INITIALIZER ,
+.Nm LIST_INIT ,
+.Nm LIST_INSERT_AFTER ,
+.Nm LIST_INSERT_BEFORE ,
+.Nm LIST_INSERT_HEAD ,
+.Nm LIST_NEXT ,
+.Nm LIST_REMOVE ,
+.Nm LIST_SWAP ,
+.Nm TAILQ_CONCAT ,
+.Nm TAILQ_EMPTY ,
+.Nm TAILQ_ENTRY ,
+.Nm TAILQ_FIRST ,
+.Nm TAILQ_FOREACH ,
+.Nm TAILQ_FOREACH_SAFE ,
+.Nm TAILQ_FOREACH_REVERSE ,
+.Nm TAILQ_FOREACH_REVERSE_SAFE ,
+.Nm TAILQ_HEAD ,
+.Nm TAILQ_HEAD_INITIALIZER ,
+.Nm TAILQ_INIT ,
+.Nm TAILQ_INSERT_AFTER ,
+.Nm TAILQ_INSERT_BEFORE ,
+.Nm TAILQ_INSERT_HEAD ,
+.Nm TAILQ_INSERT_TAIL ,
+.Nm TAILQ_LAST ,
+.Nm TAILQ_NEXT ,
+.Nm TAILQ_PREV ,
+.Nm TAILQ_REMOVE ,
+.Nm TAILQ_SWAP
+.Nd implementations of singly-linked lists, singly-linked tail queues,
+lists and tail queues
+.Sh SYNOPSIS
+.In sys/queue.h
+.\"
+.Fn SLIST_EMPTY "SLIST_HEAD *head"
+.Fn SLIST_ENTRY "TYPE"
+.Fn SLIST_FIRST "SLIST_HEAD *head"
+.Fn SLIST_FOREACH "TYPE *var" "SLIST_HEAD *head" "SLIST_ENTRY NAME"
+.Fn SLIST_FOREACH_SAFE "TYPE *var" "SLIST_HEAD *head" "SLIST_ENTRY NAME" "TYPE *temp_var"
+.Fn SLIST_HEAD "HEADNAME" "TYPE"
+.Fn SLIST_HEAD_INITIALIZER "SLIST_HEAD head"
+.Fn SLIST_INIT "SLIST_HEAD *head"
+.Fn SLIST_INSERT_AFTER "TYPE *listelm" "TYPE *elm" "SLIST_ENTRY NAME"
+.Fn SLIST_INSERT_HEAD "SLIST_HEAD *head" "TYPE *elm" "SLIST_ENTRY NAME"
+.Fn SLIST_NEXT "TYPE *elm" "SLIST_ENTRY NAME"
+.Fn SLIST_REMOVE_AFTER "TYPE *elm" "SLIST_ENTRY NAME"
+.Fn SLIST_REMOVE_HEAD "SLIST_HEAD *head" "SLIST_ENTRY NAME"
+.Fn SLIST_REMOVE "SLIST_HEAD *head" "TYPE *elm" "TYPE" "SLIST_ENTRY NAME"
+.Fn SLIST_SWAP "SLIST_HEAD *head1" "SLIST_HEAD *head2" "SLIST_ENTRY NAME"
+.\"
+.Fn STAILQ_CONCAT "STAILQ_HEAD *head1" "STAILQ_HEAD *head2"
+.Fn STAILQ_EMPTY "STAILQ_HEAD *head"
+.Fn STAILQ_ENTRY "TYPE"
+.Fn STAILQ_FIRST "STAILQ_HEAD *head"
+.Fn STAILQ_FOREACH "TYPE *var" "STAILQ_HEAD *head" "STAILQ_ENTRY NAME"
+.Fn STAILQ_FOREACH_SAFE "TYPE *var" "STAILQ_HEAD *head" "STAILQ_ENTRY NAME" "TYPE *temp_var"
+.Fn STAILQ_HEAD "HEADNAME" "TYPE"
+.Fn STAILQ_HEAD_INITIALIZER "STAILQ_HEAD head"
+.Fn STAILQ_INIT "STAILQ_HEAD *head"
+.Fn STAILQ_INSERT_AFTER "STAILQ_HEAD *head" "TYPE *listelm" "TYPE *elm" "STAILQ_ENTRY NAME"
+.Fn STAILQ_INSERT_HEAD "STAILQ_HEAD *head" "TYPE *elm" "STAILQ_ENTRY NAME"
+.Fn STAILQ_INSERT_TAIL "STAILQ_HEAD *head" "TYPE *elm" "STAILQ_ENTRY NAME"
+.Fn STAILQ_LAST "STAILQ_HEAD *head" "TYPE" "STAILQ_ENTRY NAME"
+.Fn STAILQ_NEXT "TYPE *elm" "STAILQ_ENTRY NAME"
+.Fn STAILQ_REMOVE_AFTER "STAILQ_HEAD *head" "TYPE *elm" "STAILQ_ENTRY NAME"
+.Fn STAILQ_REMOVE_HEAD "STAILQ_HEAD *head" "STAILQ_ENTRY NAME"
+.Fn STAILQ_REMOVE "STAILQ_HEAD *head" "TYPE *elm" "TYPE" "STAILQ_ENTRY NAME"
+.Fn STAILQ_SWAP "STAILQ_HEAD *head1" "STAILQ_HEAD *head2" "STAILQ_ENTRY NAME"
+.\"
+.Fn LIST_EMPTY "LIST_HEAD *head"
+.Fn LIST_ENTRY "TYPE"
+.Fn LIST_FIRST "LIST_HEAD *head"
+.Fn LIST_FOREACH "TYPE *var" "LIST_HEAD *head" "LIST_ENTRY NAME"
+.Fn LIST_FOREACH_SAFE "TYPE *var" "LIST_HEAD *head" "LIST_ENTRY NAME" "TYPE *temp_var"
+.Fn LIST_HEAD "HEADNAME" "TYPE"
+.Fn LIST_HEAD_INITIALIZER "LIST_HEAD head"
+.Fn LIST_INIT "LIST_HEAD *head"
+.Fn LIST_INSERT_AFTER "TYPE *listelm" "TYPE *elm" "LIST_ENTRY NAME"
+.Fn LIST_INSERT_BEFORE "TYPE *listelm" "TYPE *elm" "LIST_ENTRY NAME"
+.Fn LIST_INSERT_HEAD "LIST_HEAD *head" "TYPE *elm" "LIST_ENTRY NAME"
+.Fn LIST_NEXT "TYPE *elm" "LIST_ENTRY NAME"
+.Fn LIST_REMOVE "TYPE *elm" "LIST_ENTRY NAME"
+.Fn LIST_SWAP "LIST_HEAD *head1" "LIST_HEAD *head2" "TYPE" "LIST_ENTRY NAME"
+.\"
+.Fn TAILQ_CONCAT "TAILQ_HEAD *head1" "TAILQ_HEAD *head2" "TAILQ_ENTRY NAME"
+.Fn TAILQ_EMPTY "TAILQ_HEAD *head"
+.Fn TAILQ_ENTRY "TYPE"
+.Fn TAILQ_FIRST "TAILQ_HEAD *head"
+.Fn TAILQ_FOREACH "TYPE *var" "TAILQ_HEAD *head" "TAILQ_ENTRY NAME"
+.Fn TAILQ_FOREACH_SAFE "TYPE *var" "TAILQ_HEAD *head" "TAILQ_ENTRY NAME" "TYPE *temp_var"
+.Fn TAILQ_FOREACH_REVERSE "TYPE *var" "TAILQ_HEAD *head" "HEADNAME" "TAILQ_ENTRY NAME"
+.Fn TAILQ_FOREACH_REVERSE_SAFE "TYPE *var" "TAILQ_HEAD *head" "HEADNAME" "TAILQ_ENTRY NAME" "TYPE *temp_var"
+.Fn TAILQ_HEAD "HEADNAME" "TYPE"
+.Fn TAILQ_HEAD_INITIALIZER "TAILQ_HEAD head"
+.Fn TAILQ_INIT "TAILQ_HEAD *head"
+.Fn TAILQ_INSERT_AFTER "TAILQ_HEAD *head" "TYPE *listelm" "TYPE *elm" "TAILQ_ENTRY NAME"
+.Fn TAILQ_INSERT_BEFORE "TYPE *listelm" "TYPE *elm" "TAILQ_ENTRY NAME"
+.Fn TAILQ_INSERT_HEAD "TAILQ_HEAD *head" "TYPE *elm" "TAILQ_ENTRY NAME"
+.Fn TAILQ_INSERT_TAIL "TAILQ_HEAD *head" "TYPE *elm" "TAILQ_ENTRY NAME"
+.Fn TAILQ_LAST "TAILQ_HEAD *head" "HEADNAME"
+.Fn TAILQ_NEXT "TYPE *elm" "TAILQ_ENTRY NAME"
+.Fn TAILQ_PREV "TYPE *elm" "HEADNAME" "TAILQ_ENTRY NAME"
+.Fn TAILQ_REMOVE "TAILQ_HEAD *head" "TYPE *elm" "TAILQ_ENTRY NAME"
+.Fn TAILQ_SWAP "TAILQ_HEAD *head1" "TAILQ_HEAD *head2" "TYPE" "TAILQ_ENTRY NAME"
+.\"
+.Sh DESCRIPTION
+These macros define and operate on four types of data structures:
+singly-linked lists, singly-linked tail queues, lists, and tail queues.
+All four structures support the following functionality:
+.Bl -enum -compact -offset indent
+.It
+Insertion of a new entry at the head of the list.
+.It
+Insertion of a new entry after any element in the list.
+.It
+O(1) removal of an entry from the head of the list.
+.It
+Forward traversal through the list.
+.It
+Swawpping the contents of two lists.
+.El
+.Pp
+Singly-linked lists are the simplest of the four data structures
+and support only the above functionality.
+Singly-linked lists are ideal for applications with large datasets
+and few or no removals,
+or for implementing a LIFO queue.
+Singly-linked lists add the following functionality:
+.Bl -enum -compact -offset indent
+.It
+O(n) removal of any entry in the list.
+.El
+.Pp
+Singly-linked tail queues add the following functionality:
+.Bl -enum -compact -offset indent
+.It
+Entries can be added at the end of a list.
+.It
+O(n) removal of any entry in the list.
+.It
+They may be concatenated.
+.El
+However:
+.Bl -enum -compact -offset indent
+.It
+All list insertions must specify the head of the list.
+.It
+Each head entry requires two pointers rather than one.
+.It
+Code size is about 15% greater and operations run about 20% slower
+than singly-linked lists.
+.El
+.Pp
+Singly-linked tailqs are ideal for applications with large datasets and
+few or no removals,
+or for implementing a FIFO queue.
+.Pp
+All doubly linked types of data structures (lists and tail queues)
+additionally allow:
+.Bl -enum -compact -offset indent
+.It
+Insertion of a new entry before any element in the list.
+.It
+O(1) removal of any entry in the list.
+.El
+However:
+.Bl -enum -compact -offset indent
+.It
+Each element requires two pointers rather than one.
+.It
+Code size and execution time of operations (except for removal) is about
+twice that of the singly-linked data-structures.
+.El
+.Pp
+Linked lists are the simplest of the doubly linked data structures and support
+only the above functionality over singly-linked lists.
+.Pp
+Tail queues add the following functionality:
+.Bl -enum -compact -offset indent
+.It
+Entries can be added at the end of a list.
+.It
+They may be traversed backwards, from tail to head.
+.It
+They may be concatenated.
+.El
+However:
+.Bl -enum -compact -offset indent
+.It
+All list insertions and removals must specify the head of the list.
+.It
+Each head entry requires two pointers rather than one.
+.It
+Code size is about 15% greater and operations run about 20% slower
+than singly-linked lists.
+.El
+.Pp
+In the macro definitions,
+.Fa TYPE
+is the name of a user defined structure,
+that must contain a field of type
+.Li SLIST_ENTRY ,
+.Li STAILQ_ENTRY ,
+.Li LIST_ENTRY ,
+or
+.Li TAILQ_ENTRY ,
+named
+.Fa NAME .
+The argument
+.Fa HEADNAME
+is the name of a user defined structure that must be declared
+using the macros
+.Li SLIST_HEAD ,
+.Li STAILQ_HEAD ,
+.Li LIST_HEAD ,
+or
+.Li TAILQ_HEAD .
+See the examples below for further explanation of how these
+macros are used.
+.Sh SINGLY-LINKED LISTS
+A singly-linked list is headed by a structure defined by the
+.Nm SLIST_HEAD
+macro.
+This structure contains a single pointer to the first element
+on the list.
+The elements are singly linked for minimum space and pointer manipulation
+overhead at the expense of O(n) removal for arbitrary elements.
+New elements can be added to the list after an existing element or
+at the head of the list.
+An
+.Fa SLIST_HEAD
+structure is declared as follows:
+.Bd -literal -offset indent
+SLIST_HEAD(HEADNAME, TYPE) head;
+.Ed
+.Pp
+where
+.Fa HEADNAME
+is the name of the structure to be defined, and
+.Fa TYPE
+is the type of the elements to be linked into the list.
+A pointer to the head of the list can later be declared as:
+.Bd -literal -offset indent
+struct HEADNAME *headp;
+.Ed
+.Pp
+(The names
+.Li head
+and
+.Li headp
+are user selectable.)
+.Pp
+The macro
+.Nm SLIST_HEAD_INITIALIZER
+evaluates to an initializer for the list
+.Fa head .
+.Pp
+The macro
+.Nm SLIST_EMPTY
+evaluates to true if there are no elements in the list.
+.Pp
+The macro
+.Nm SLIST_ENTRY
+declares a structure that connects the elements in
+the list.
+.Pp
+The macro
+.Nm SLIST_FIRST
+returns the first element in the list or NULL if the list is empty.
+.Pp
+The macro
+.Nm SLIST_FOREACH
+traverses the list referenced by
+.Fa head
+in the forward direction, assigning each element in
+turn to
+.Fa var .
+.Pp
+The macro
+.Nm SLIST_FOREACH_SAFE
+traverses the list referenced by
+.Fa head
+in the forward direction, assigning each element in
+turn to
+.Fa var .
+However, unlike
+.Fn SLIST_FOREACH
+here it is permitted to both remove
+.Fa var
+as well as free it from within the loop safely without interfering with the
+traversal.
+.Pp
+The macro
+.Nm SLIST_INIT
+initializes the list referenced by
+.Fa head .
+.Pp
+The macro
+.Nm SLIST_INSERT_HEAD
+inserts the new element
+.Fa elm
+at the head of the list.
+.Pp
+The macro
+.Nm SLIST_INSERT_AFTER
+inserts the new element
+.Fa elm
+after the element
+.Fa listelm .
+.Pp
+The macro
+.Nm SLIST_NEXT
+returns the next element in the list.
+.Pp
+The macro
+.Nm SLIST_REMOVE_AFTER
+removes the element after
+.Fa elm
+from the list. Unlike
+.Fa SLIST_REMOVE ,
+this macro does not traverse the entire list.
+.Pp
+The macro
+.Nm SLIST_REMOVE_HEAD
+removes the element
+.Fa elm
+from the head of the list.
+For optimum efficiency,
+elements being removed from the head of the list should explicitly use
+this macro instead of the generic
+.Fa SLIST_REMOVE
+macro.
+.Pp
+The macro
+.Nm SLIST_REMOVE
+removes the element
+.Fa elm
+from the list.
+.Pp
+The macro
+.Nm SLIST_SWAP
+swaps the contents of
+.Fa head1
+and
+.Fa head2 .
+.Sh SINGLY-LINKED LIST EXAMPLE
+.Bd -literal
+SLIST_HEAD(slisthead, entry) head =
+    SLIST_HEAD_INITIALIZER(head);
+struct slisthead *headp;		/* Singly-linked List head. */
+struct entry {
+	...
+	SLIST_ENTRY(entry) entries;	/* Singly-linked List. */
+	...
+} *n1, *n2, *n3, *np;
+
+SLIST_INIT(&head);			/* Initialize the list. */
+
+n1 = malloc(sizeof(struct entry));	/* Insert at the head. */
+SLIST_INSERT_HEAD(&head, n1, entries);
+
+n2 = malloc(sizeof(struct entry));	/* Insert after. */
+SLIST_INSERT_AFTER(n1, n2, entries);
+
+SLIST_REMOVE(&head, n2, entry, entries);/* Deletion. */
+free(n2);
+
+n3 = SLIST_FIRST(&head);
+SLIST_REMOVE_HEAD(&head, entries);	/* Deletion from the head. */
+free(n3);
+					/* Forward traversal. */
+SLIST_FOREACH(np, &head, entries)
+	np-> ...
+					/* Safe forward traversal. */
+SLIST_FOREACH_SAFE(np, &head, entries, np_temp) {
+	np->do_stuff();
+	...
+	SLIST_REMOVE(&head, np, entry, entries);
+	free(np);
+}
+
+while (!SLIST_EMPTY(&head)) {		/* List Deletion. */
+	n1 = SLIST_FIRST(&head);
+	SLIST_REMOVE_HEAD(&head, entries);
+	free(n1);
+}
+.Ed
+.Sh SINGLY-LINKED TAIL QUEUES
+A singly-linked tail queue is headed by a structure defined by the
+.Nm STAILQ_HEAD
+macro.
+This structure contains a pair of pointers,
+one to the first element in the tail queue and the other to
+the last element in the tail queue.
+The elements are singly linked for minimum space and pointer
+manipulation overhead at the expense of O(n) removal for arbitrary
+elements.
+New elements can be added to the tail queue after an existing element,
+at the head of the tail queue, or at the end of the tail queue.
+A
+.Fa STAILQ_HEAD
+structure is declared as follows:
+.Bd -literal -offset indent
+STAILQ_HEAD(HEADNAME, TYPE) head;
+.Ed
+.Pp
+where
+.Li HEADNAME
+is the name of the structure to be defined, and
+.Li TYPE
+is the type of the elements to be linked into the tail queue.
+A pointer to the head of the tail queue can later be declared as:
+.Bd -literal -offset indent
+struct HEADNAME *headp;
+.Ed
+.Pp
+(The names
+.Li head
+and
+.Li headp
+are user selectable.)
+.Pp
+The macro
+.Nm STAILQ_HEAD_INITIALIZER
+evaluates to an initializer for the tail queue
+.Fa head .
+.Pp
+The macro
+.Nm STAILQ_CONCAT
+concatenates the tail queue headed by
+.Fa head2
+onto the end of the one headed by
+.Fa head1
+removing all entries from the former.
+.Pp
+The macro
+.Nm STAILQ_EMPTY
+evaluates to true if there are no items on the tail queue.
+.Pp
+The macro
+.Nm STAILQ_ENTRY
+declares a structure that connects the elements in
+the tail queue.
+.Pp
+The macro
+.Nm STAILQ_FIRST
+returns the first item on the tail queue or NULL if the tail queue
+is empty.
+.Pp
+The macro
+.Nm STAILQ_FOREACH
+traverses the tail queue referenced by
+.Fa head
+in the forward direction, assigning each element
+in turn to
+.Fa var .
+.Pp
+The macro
+.Nm STAILQ_FOREACH_SAFE
+traverses the tail queue referenced by
+.Fa head
+in the forward direction, assigning each element
+in turn to
+.Fa var .
+However, unlike
+.Fn STAILQ_FOREACH
+here it is permitted to both remove
+.Fa var
+as well as free it from within the loop safely without interfering with the
+traversal.
+.Pp
+The macro
+.Nm STAILQ_INIT
+initializes the tail queue referenced by
+.Fa head .
+.Pp
+The macro
+.Nm STAILQ_INSERT_HEAD
+inserts the new element
+.Fa elm
+at the head of the tail queue.
+.Pp
+The macro
+.Nm STAILQ_INSERT_TAIL
+inserts the new element
+.Fa elm
+at the end of the tail queue.
+.Pp
+The macro
+.Nm STAILQ_INSERT_AFTER
+inserts the new element
+.Fa elm
+after the element
+.Fa listelm .
+.Pp
+The macro
+.Nm STAILQ_LAST
+returns the last item on the tail queue.
+If the tail queue is empty the return value is
+.Dv NULL .
+.Pp
+The macro
+.Nm STAILQ_NEXT
+returns the next item on the tail queue, or NULL this item is the last.
+.Pp
+The macro
+.Nm STAILQ_REMOVE_AFTER
+removes the element after
+.Fa elm
+from the tail queue. Unlike
+.Fa STAILQ_REMOVE ,
+this macro does not traverse the entire tail queue.
+.Pp
+The macro
+.Nm STAILQ_REMOVE_HEAD
+removes the element at the head of the tail queue.
+For optimum efficiency,
+elements being removed from the head of the tail queue should
+use this macro explicitly rather than the generic
+.Fa STAILQ_REMOVE
+macro.
+.Pp
+The macro
+.Nm STAILQ_REMOVE
+removes the element
+.Fa elm
+from the tail queue.
+.Pp
+The macro
+.Nm STAILQ_SWAP
+swaps the contents of
+.Fa head1
+and
+.Fa head2 .
+.Sh SINGLY-LINKED TAIL QUEUE EXAMPLE
+.Bd -literal
+STAILQ_HEAD(stailhead, entry) head =
+    STAILQ_HEAD_INITIALIZER(head);
+struct stailhead *headp;		/* Singly-linked tail queue head. */
+struct entry {
+	...
+	STAILQ_ENTRY(entry) entries;	/* Tail queue. */
+	...
+} *n1, *n2, *n3, *np;
+
+STAILQ_INIT(&head);			/* Initialize the queue. */
+
+n1 = malloc(sizeof(struct entry));	/* Insert at the head. */
+STAILQ_INSERT_HEAD(&head, n1, entries);
+
+n1 = malloc(sizeof(struct entry));	/* Insert at the tail. */
+STAILQ_INSERT_TAIL(&head, n1, entries);
+
+n2 = malloc(sizeof(struct entry));	/* Insert after. */
+STAILQ_INSERT_AFTER(&head, n1, n2, entries);
+					/* Deletion. */
+STAILQ_REMOVE(&head, n2, entry, entries);
+free(n2);
+					/* Deletion from the head. */
+n3 = STAILQ_FIRST(&head);
+STAILQ_REMOVE_HEAD(&head, entries);
+free(n3);
+					/* Forward traversal. */
+STAILQ_FOREACH(np, &head, entries)
+	np-> ...
+					/* Safe forward traversal. */
+STAILQ_FOREACH_SAFE(np, &head, entries, np_temp) {
+	np->do_stuff();
+	...
+	STAILQ_REMOVE(&head, np, entry, entries);
+	free(np);
+}
+					/* TailQ Deletion. */
+while (!STAILQ_EMPTY(&head)) {
+	n1 = STAILQ_FIRST(&head);
+	STAILQ_REMOVE_HEAD(&head, entries);
+	free(n1);
+}
+					/* Faster TailQ Deletion. */
+n1 = STAILQ_FIRST(&head);
+while (n1 != NULL) {
+	n2 = STAILQ_NEXT(n1, entries);
+	free(n1);
+	n1 = n2;
+}
+STAILQ_INIT(&head);
+.Ed
+.Sh LISTS
+A list is headed by a structure defined by the
+.Nm LIST_HEAD
+macro.
+This structure contains a single pointer to the first element
+on the list.
+The elements are doubly linked so that an arbitrary element can be
+removed without traversing the list.
+New elements can be added to the list after an existing element,
+before an existing element, or at the head of the list.
+A
+.Fa LIST_HEAD
+structure is declared as follows:
+.Bd -literal -offset indent
+LIST_HEAD(HEADNAME, TYPE) head;
+.Ed
+.Pp
+where
+.Fa HEADNAME
+is the name of the structure to be defined, and
+.Fa TYPE
+is the type of the elements to be linked into the list.
+A pointer to the head of the list can later be declared as:
+.Bd -literal -offset indent
+struct HEADNAME *headp;
+.Ed
+.Pp
+(The names
+.Li head
+and
+.Li headp
+are user selectable.)
+.Pp
+The macro
+.Nm LIST_HEAD_INITIALIZER
+evaluates to an initializer for the list
+.Fa head .
+.Pp
+The macro
+.Nm LIST_EMPTY
+evaluates to true if there are no elements in the list.
+.Pp
+The macro
+.Nm LIST_ENTRY
+declares a structure that connects the elements in
+the list.
+.Pp
+The macro
+.Nm LIST_FIRST
+returns the first element in the list or NULL if the list
+is empty.
+.Pp
+The macro
+.Nm LIST_FOREACH
+traverses the list referenced by
+.Fa head
+in the forward direction, assigning each element in turn to
+.Fa var .
+.Pp
+The macro
+.Nm LIST_FOREACH_SAFE
+traverses the list referenced by
+.Fa head
+in the forward direction, assigning each element in turn to
+.Fa var .
+However, unlike
+.Fn LIST_FOREACH
+here it is permitted to both remove
+.Fa var
+as well as free it from within the loop safely without interfering with the
+traversal.
+.Pp
+The macro
+.Nm LIST_INIT
+initializes the list referenced by
+.Fa head .
+.Pp
+The macro
+.Nm LIST_INSERT_HEAD
+inserts the new element
+.Fa elm
+at the head of the list.
+.Pp
+The macro
+.Nm LIST_INSERT_AFTER
+inserts the new element
+.Fa elm
+after the element
+.Fa listelm .
+.Pp
+The macro
+.Nm LIST_INSERT_BEFORE
+inserts the new element
+.Fa elm
+before the element
+.Fa listelm .
+.Pp
+The macro
+.Nm LIST_NEXT
+returns the next element in the list, or NULL if this is the last.
+.Pp
+The macro
+.Nm LIST_REMOVE
+removes the element
+.Fa elm
+from the list.
+.Pp
+The macro
+.Nm LIST_SWAP
+swaps the contents of
+.Fa head1
+and
+.Fa head2 .
+.Sh LIST EXAMPLE
+.Bd -literal
+LIST_HEAD(listhead, entry) head =
+    LIST_HEAD_INITIALIZER(head);
+struct listhead *headp;			/* List head. */
+struct entry {
+	...
+	LIST_ENTRY(entry) entries;	/* List. */
+	...
+} *n1, *n2, *n3, *np, *np_temp;
+
+LIST_INIT(&head);			/* Initialize the list. */
+
+n1 = malloc(sizeof(struct entry));	/* Insert at the head. */
+LIST_INSERT_HEAD(&head, n1, entries);
+
+n2 = malloc(sizeof(struct entry));	/* Insert after. */
+LIST_INSERT_AFTER(n1, n2, entries);
+
+n3 = malloc(sizeof(struct entry));	/* Insert before. */
+LIST_INSERT_BEFORE(n2, n3, entries);
+
+LIST_REMOVE(n2, entries);		/* Deletion. */
+free(n2);
+					/* Forward traversal. */
+LIST_FOREACH(np, &head, entries)
+	np-> ...
+
+					/* Safe forward traversal. */
+LIST_FOREACH_SAFE(np, &head, entries, np_temp) {
+	np->do_stuff();
+	...
+	LIST_REMOVE(np, entries);
+	free(np);
+}
+
+while (!LIST_EMPTY(&head)) {		/* List Deletion. */
+	n1 = LIST_FIRST(&head);
+	LIST_REMOVE(n1, entries);
+	free(n1);
+}
+
+n1 = LIST_FIRST(&head);			/* Faster List Deletion. */
+while (n1 != NULL) {
+	n2 = LIST_NEXT(n1, entries);
+	free(n1);
+	n1 = n2;
+}
+LIST_INIT(&head);
+.Ed
+.Sh TAIL QUEUES
+A tail queue is headed by a structure defined by the
+.Nm TAILQ_HEAD
+macro.
+This structure contains a pair of pointers,
+one to the first element in the tail queue and the other to
+the last element in the tail queue.
+The elements are doubly linked so that an arbitrary element can be
+removed without traversing the tail queue.
+New elements can be added to the tail queue after an existing element,
+before an existing element, at the head of the tail queue,
+or at the end of the tail queue.
+A
+.Fa TAILQ_HEAD
+structure is declared as follows:
+.Bd -literal -offset indent
+TAILQ_HEAD(HEADNAME, TYPE) head;
+.Ed
+.Pp
+where
+.Li HEADNAME
+is the name of the structure to be defined, and
+.Li TYPE
+is the type of the elements to be linked into the tail queue.
+A pointer to the head of the tail queue can later be declared as:
+.Bd -literal -offset indent
+struct HEADNAME *headp;
+.Ed
+.Pp
+(The names
+.Li head
+and
+.Li headp
+are user selectable.)
+.Pp
+The macro
+.Nm TAILQ_HEAD_INITIALIZER
+evaluates to an initializer for the tail queue
+.Fa head .
+.Pp
+The macro
+.Nm TAILQ_CONCAT
+concatenates the tail queue headed by
+.Fa head2
+onto the end of the one headed by
+.Fa head1
+removing all entries from the former.
+.Pp
+The macro
+.Nm TAILQ_EMPTY
+evaluates to true if there are no items on the tail queue.
+.Pp
+The macro
+.Nm TAILQ_ENTRY
+declares a structure that connects the elements in
+the tail queue.
+.Pp
+The macro
+.Nm TAILQ_FIRST
+returns the first item on the tail queue or NULL if the tail queue
+is empty.
+.Pp
+The macro
+.Nm TAILQ_FOREACH
+traverses the tail queue referenced by
+.Fa head
+in the forward direction, assigning each element in turn to
+.Fa var .
+.Fa var
+is set to
+.Dv NULL
+if the loop completes normally, or if there were no elements.
+.Pp
+The macro
+.Nm TAILQ_FOREACH_REVERSE
+traverses the tail queue referenced by
+.Fa head
+in the reverse direction, assigning each element in turn to
+.Fa var .
+.Pp
+The macros
+.Nm TAILQ_FOREACH_SAFE
+and
+.Nm TAILQ_FOREACH_REVERSE_SAFE
+traverse the list referenced by
+.Fa head
+in the forward or reverse direction respectively,
+assigning each element in turn to
+.Fa var .
+However, unlike their unsafe counterparts,
+.Nm TAILQ_FOREACH
+and
+.Nm TAILQ_FOREACH_REVERSE
+permit to both remove
+.Fa var
+as well as free it from within the loop safely without interfering with the
+traversal.
+.Pp
+The macro
+.Nm TAILQ_INIT
+initializes the tail queue referenced by
+.Fa head .
+.Pp
+The macro
+.Nm TAILQ_INSERT_HEAD
+inserts the new element
+.Fa elm
+at the head of the tail queue.
+.Pp
+The macro
+.Nm TAILQ_INSERT_TAIL
+inserts the new element
+.Fa elm
+at the end of the tail queue.
+.Pp
+The macro
+.Nm TAILQ_INSERT_AFTER
+inserts the new element
+.Fa elm
+after the element
+.Fa listelm .
+.Pp
+The macro
+.Nm TAILQ_INSERT_BEFORE
+inserts the new element
+.Fa elm
+before the element
+.Fa listelm .
+.Pp
+The macro
+.Nm TAILQ_LAST
+returns the last item on the tail queue.
+If the tail queue is empty the return value is
+.Dv NULL .
+.Pp
+The macro
+.Nm TAILQ_NEXT
+returns the next item on the tail queue, or NULL if this item is the last.
+.Pp
+The macro
+.Nm TAILQ_PREV
+returns the previous item on the tail queue, or NULL if this item
+is the first.
+.Pp
+The macro
+.Nm TAILQ_REMOVE
+removes the element
+.Fa elm
+from the tail queue.
+.Pp
+The macro
+.Nm TAILQ_SWAP
+swaps the contents of
+.Fa head1
+and
+.Fa head2 .
+.Sh TAIL QUEUE EXAMPLE
+.Bd -literal
+TAILQ_HEAD(tailhead, entry) head =
+    TAILQ_HEAD_INITIALIZER(head);
+struct tailhead *headp;			/* Tail queue head. */
+struct entry {
+	...
+	TAILQ_ENTRY(entry) entries;	/* Tail queue. */
+	...
+} *n1, *n2, *n3, *np;
+
+TAILQ_INIT(&head);			/* Initialize the queue. */
+
+n1 = malloc(sizeof(struct entry));	/* Insert at the head. */
+TAILQ_INSERT_HEAD(&head, n1, entries);
+
+n1 = malloc(sizeof(struct entry));	/* Insert at the tail. */
+TAILQ_INSERT_TAIL(&head, n1, entries);
+
+n2 = malloc(sizeof(struct entry));	/* Insert after. */
+TAILQ_INSERT_AFTER(&head, n1, n2, entries);
+
+n3 = malloc(sizeof(struct entry));	/* Insert before. */
+TAILQ_INSERT_BEFORE(n2, n3, entries);
+
+TAILQ_REMOVE(&head, n2, entries);	/* Deletion. */
+free(n2);
+					/* Forward traversal. */
+TAILQ_FOREACH(np, &head, entries)
+	np-> ...
+					/* Safe forward traversal. */
+TAILQ_FOREACH_SAFE(np, &head, entries, np_temp) {
+	np->do_stuff();
+	...
+	TAILQ_REMOVE(&head, np, entries);
+	free(np);
+}
+					/* Reverse traversal. */
+TAILQ_FOREACH_REVERSE(np, &head, tailhead, entries)
+	np-> ...
+					/* TailQ Deletion. */
+while (!TAILQ_EMPTY(&head)) {
+	n1 = TAILQ_FIRST(&head);
+	TAILQ_REMOVE(&head, n1, entries);
+	free(n1);
+}
+					/* Faster TailQ Deletion. */
+n1 = TAILQ_FIRST(&head);
+while (n1 != NULL) {
+	n2 = TAILQ_NEXT(n1, entries);
+	free(n1);
+	n1 = n2;
+}
+TAILQ_INIT(&head);
+.Ed
+.Sh SEE ALSO
+.Xr tree 3
+.Sh HISTORY
+The
+.Nm queue
+functions first appeared in
+.Bx 4.4 .
diff --git a/tools/libxl/external/bsd-sys-queue.h b/tools/libxl/external/bsd-sys-queue.h
new file mode 100644
index 0000000..274e636
--- /dev/null
+++ b/tools/libxl/external/bsd-sys-queue.h
@@ -0,0 +1,637 @@
+/*-
+ * Copyright (c) 1991, 1993
+ *	The Regents of the University of California.  All rights reserved.
+ *
+ * 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.
+ * 4. Neither the name of the University 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 REGENTS 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 REGENTS 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.
+ *
+ *	@(#)queue.h	8.5 (Berkeley) 8/20/94
+ * $FreeBSD$
+ */
+
+#ifndef _SYS_QUEUE_H_
+#define	_SYS_QUEUE_H_
+
+#include <sys/cdefs.h>
+
+/*
+ * This file defines four types of data structures: singly-linked lists,
+ * singly-linked tail queues, lists and tail queues.
+ *
+ * A singly-linked list is headed by a single forward pointer. The elements
+ * are singly linked for minimum space and pointer manipulation overhead at
+ * the expense of O(n) removal for arbitrary elements. New elements can be
+ * added to the list after an existing element or at the head of the list.
+ * Elements being removed from the head of the list should use the explicit
+ * macro for this purpose for optimum efficiency. A singly-linked list may
+ * only be traversed in the forward direction.  Singly-linked lists are ideal
+ * for applications with large datasets and few or no removals or for
+ * implementing a LIFO queue.
+ *
+ * A singly-linked tail queue is headed by a pair of pointers, one to the
+ * head of the list and the other to the tail of the list. The elements are
+ * singly linked for minimum space and pointer manipulation overhead at the
+ * expense of O(n) removal for arbitrary elements. New elements can be added
+ * to the list after an existing element, at the head of the list, or at the
+ * end of the list. Elements being removed from the head of the tail queue
+ * should use the explicit macro for this purpose for optimum efficiency.
+ * A singly-linked tail queue may only be traversed in the forward direction.
+ * Singly-linked tail queues are ideal for applications with large datasets
+ * and few or no removals or for implementing a FIFO queue.
+ *
+ * A list is headed by a single forward pointer (or an array of forward
+ * pointers for a hash table header). The elements are doubly linked
+ * so that an arbitrary element can be removed without a need to
+ * traverse the list. New elements can be added to the list before
+ * or after an existing element or at the head of the list. A list
+ * may only be traversed in the forward direction.
+ *
+ * A tail queue is headed by a pair of pointers, one to the head of the
+ * list and the other to the tail of the list. The elements are doubly
+ * linked so that an arbitrary element can be removed without a need to
+ * traverse the list. New elements can be added to the list before or
+ * after an existing element, at the head of the list, or at the end of
+ * the list. A tail queue may be traversed in either direction.
+ *
+ * For details on the use of these macros, see the queue(3) manual page.
+ *
+ *
+ *				SLIST	LIST	STAILQ	TAILQ
+ * _HEAD			+	+	+	+
+ * _HEAD_INITIALIZER		+	+	+	+
+ * _ENTRY			+	+	+	+
+ * _INIT			+	+	+	+
+ * _EMPTY			+	+	+	+
+ * _FIRST			+	+	+	+
+ * _NEXT			+	+	+	+
+ * _PREV			-	-	-	+
+ * _LAST			-	-	+	+
+ * _FOREACH			+	+	+	+
+ * _FOREACH_SAFE		+	+	+	+
+ * _FOREACH_REVERSE		-	-	-	+
+ * _FOREACH_REVERSE_SAFE	-	-	-	+
+ * _INSERT_HEAD			+	+	+	+
+ * _INSERT_BEFORE		-	+	-	+
+ * _INSERT_AFTER		+	+	+	+
+ * _INSERT_TAIL			-	-	+	+
+ * _CONCAT			-	-	+	+
+ * _REMOVE_AFTER		+	-	+	-
+ * _REMOVE_HEAD			+	-	+	-
+ * _REMOVE			+	+	+	+
+ * _SWAP			+	+	+	+
+ *
+ */
+#ifdef QUEUE_MACRO_DEBUG
+/* Store the last 2 places the queue element or head was altered */
+struct qm_trace {
+	char * lastfile;
+	int lastline;
+	char * prevfile;
+	int prevline;
+};
+
+#define	TRACEBUF	struct qm_trace trace;
+#define	TRASHIT(x)	do {(x) = (void *)-1;} while (0)
+#define	QMD_SAVELINK(name, link)	void **name = (void *)&(link)
+
+#define	QMD_TRACE_HEAD(head) do {					\
+	(head)->trace.prevline = (head)->trace.lastline;		\
+	(head)->trace.prevfile = (head)->trace.lastfile;		\
+	(head)->trace.lastline = __LINE__;				\
+	(head)->trace.lastfile = __FILE__;				\
+} while (0)
+
+#define	QMD_TRACE_ELEM(elem) do {					\
+	(elem)->trace.prevline = (elem)->trace.lastline;		\
+	(elem)->trace.prevfile = (elem)->trace.lastfile;		\
+	(elem)->trace.lastline = __LINE__;				\
+	(elem)->trace.lastfile = __FILE__;				\
+} while (0)
+
+#else
+#define	QMD_TRACE_ELEM(elem)
+#define	QMD_TRACE_HEAD(head)
+#define	QMD_SAVELINK(name, link)
+#define	TRACEBUF
+#define	TRASHIT(x)
+#endif	/* QUEUE_MACRO_DEBUG */
+
+/*
+ * Singly-linked List declarations.
+ */
+#define	SLIST_HEAD(name, type)						\
+struct name {								\
+	struct type *slh_first;	/* first element */			\
+}
+
+#define	SLIST_HEAD_INITIALIZER(head)					\
+	{ NULL }
+
+#define	SLIST_ENTRY(type)						\
+struct {								\
+	struct type *sle_next;	/* next element */			\
+}
+
+/*
+ * Singly-linked List functions.
+ */
+#define	SLIST_EMPTY(head)	((head)->slh_first == NULL)
+
+#define	SLIST_FIRST(head)	((head)->slh_first)
+
+#define	SLIST_FOREACH(var, head, field)					\
+	for ((var) = SLIST_FIRST((head));				\
+	    (var);							\
+	    (var) = SLIST_NEXT((var), field))
+
+#define	SLIST_FOREACH_SAFE(var, head, field, tvar)			\
+	for ((var) = SLIST_FIRST((head));				\
+	    (var) && ((tvar) = SLIST_NEXT((var), field), 1);		\
+	    (var) = (tvar))
+
+#define	SLIST_FOREACH_PREVPTR(var, varp, head, field)			\
+	for ((varp) = &SLIST_FIRST((head));				\
+	    ((var) = *(varp)) != NULL;					\
+	    (varp) = &SLIST_NEXT((var), field))
+
+#define	SLIST_INIT(head) do {						\
+	SLIST_FIRST((head)) = NULL;					\
+} while (0)
+
+#define	SLIST_INSERT_AFTER(slistelm, elm, field) do {			\
+	SLIST_NEXT((elm), field) = SLIST_NEXT((slistelm), field);	\
+	SLIST_NEXT((slistelm), field) = (elm);				\
+} while (0)
+
+#define	SLIST_INSERT_HEAD(head, elm, field) do {			\
+	SLIST_NEXT((elm), field) = SLIST_FIRST((head));			\
+	SLIST_FIRST((head)) = (elm);					\
+} while (0)
+
+#define	SLIST_NEXT(elm, field)	((elm)->field.sle_next)
+
+#define	SLIST_REMOVE(head, elm, type, field) do {			\
+	QMD_SAVELINK(oldnext, (elm)->field.sle_next);			\
+	if (SLIST_FIRST((head)) == (elm)) {				\
+		SLIST_REMOVE_HEAD((head), field);			\
+	}								\
+	else {								\
+		struct type *curelm = SLIST_FIRST((head));		\
+		while (SLIST_NEXT(curelm, field) != (elm))		\
+			curelm = SLIST_NEXT(curelm, field);		\
+		SLIST_REMOVE_AFTER(curelm, field);			\
+	}								\
+	TRASHIT(*oldnext);						\
+} while (0)
+
+#define SLIST_REMOVE_AFTER(elm, field) do {				\
+	SLIST_NEXT(elm, field) =					\
+	    SLIST_NEXT(SLIST_NEXT(elm, field), field);			\
+} while (0)
+
+#define	SLIST_REMOVE_HEAD(head, field) do {				\
+	SLIST_FIRST((head)) = SLIST_NEXT(SLIST_FIRST((head)), field);	\
+} while (0)
+
+#define SLIST_SWAP(head1, head2, type) do {				\
+	struct type *swap_first = SLIST_FIRST(head1);			\
+	SLIST_FIRST(head1) = SLIST_FIRST(head2);			\
+	SLIST_FIRST(head2) = swap_first;				\
+} while (0)
+
+/*
+ * Singly-linked Tail queue declarations.
+ */
+#define	STAILQ_HEAD(name, type)						\
+struct name {								\
+	struct type *stqh_first;/* first element */			\
+	struct type **stqh_last;/* addr of last next element */		\
+}
+
+#define	STAILQ_HEAD_INITIALIZER(head)					\
+	{ NULL, &(head).stqh_first }
+
+#define	STAILQ_ENTRY(type)						\
+struct {								\
+	struct type *stqe_next;	/* next element */			\
+}
+
+/*
+ * Singly-linked Tail queue functions.
+ */
+#define	STAILQ_CONCAT(head1, head2) do {				\
+	if (!STAILQ_EMPTY((head2))) {					\
+		*(head1)->stqh_last = (head2)->stqh_first;		\
+		(head1)->stqh_last = (head2)->stqh_last;		\
+		STAILQ_INIT((head2));					\
+	}								\
+} while (0)
+
+#define	STAILQ_EMPTY(head)	((head)->stqh_first == NULL)
+
+#define	STAILQ_FIRST(head)	((head)->stqh_first)
+
+#define	STAILQ_FOREACH(var, head, field)				\
+	for((var) = STAILQ_FIRST((head));				\
+	   (var);							\
+	   (var) = STAILQ_NEXT((var), field))
+
+
+#define	STAILQ_FOREACH_SAFE(var, head, field, tvar)			\
+	for ((var) = STAILQ_FIRST((head));				\
+	    (var) && ((tvar) = STAILQ_NEXT((var), field), 1);		\
+	    (var) = (tvar))
+
+#define	STAILQ_INIT(head) do {						\
+	STAILQ_FIRST((head)) = NULL;					\
+	(head)->stqh_last = &STAILQ_FIRST((head));			\
+} while (0)
+
+#define	STAILQ_INSERT_AFTER(head, tqelm, elm, field) do {		\
+	if ((STAILQ_NEXT((elm), field) = STAILQ_NEXT((tqelm), field)) == NULL)\
+		(head)->stqh_last = &STAILQ_NEXT((elm), field);		\
+	STAILQ_NEXT((tqelm), field) = (elm);				\
+} while (0)
+
+#define	STAILQ_INSERT_HEAD(head, elm, field) do {			\
+	if ((STAILQ_NEXT((elm), field) = STAILQ_FIRST((head))) == NULL)	\
+		(head)->stqh_last = &STAILQ_NEXT((elm), field);		\
+	STAILQ_FIRST((head)) = (elm);					\
+} while (0)
+
+#define	STAILQ_INSERT_TAIL(head, elm, field) do {			\
+	STAILQ_NEXT((elm), field) = NULL;				\
+	*(head)->stqh_last = (elm);					\
+	(head)->stqh_last = &STAILQ_NEXT((elm), field);			\
+} while (0)
+
+#define	STAILQ_LAST(head, type, field)					\
+	(STAILQ_EMPTY((head)) ?						\
+		NULL :							\
+	        ((struct type *)(void *)				\
+		((char *)((head)->stqh_last) - __offsetof(struct type, field))))
+
+#define	STAILQ_NEXT(elm, field)	((elm)->field.stqe_next)
+
+#define	STAILQ_REMOVE(head, elm, type, field) do {			\
+	QMD_SAVELINK(oldnext, (elm)->field.stqe_next);			\
+	if (STAILQ_FIRST((head)) == (elm)) {				\
+		STAILQ_REMOVE_HEAD((head), field);			\
+	}								\
+	else {								\
+		struct type *curelm = STAILQ_FIRST((head));		\
+		while (STAILQ_NEXT(curelm, field) != (elm))		\
+			curelm = STAILQ_NEXT(curelm, field);		\
+		STAILQ_REMOVE_AFTER(head, curelm, field);		\
+	}								\
+	TRASHIT(*oldnext);						\
+} while (0)
+
+#define STAILQ_REMOVE_AFTER(head, elm, field) do {			\
+	if ((STAILQ_NEXT(elm, field) =					\
+	     STAILQ_NEXT(STAILQ_NEXT(elm, field), field)) == NULL)	\
+		(head)->stqh_last = &STAILQ_NEXT((elm), field);		\
+} while (0)
+
+#define	STAILQ_REMOVE_HEAD(head, field) do {				\
+	if ((STAILQ_FIRST((head)) =					\
+	     STAILQ_NEXT(STAILQ_FIRST((head)), field)) == NULL)		\
+		(head)->stqh_last = &STAILQ_FIRST((head));		\
+} while (0)
+
+#define STAILQ_SWAP(head1, head2, type) do {				\
+	struct type *swap_first = STAILQ_FIRST(head1);			\
+	struct type **swap_last = (head1)->stqh_last;			\
+	STAILQ_FIRST(head1) = STAILQ_FIRST(head2);			\
+	(head1)->stqh_last = (head2)->stqh_last;			\
+	STAILQ_FIRST(head2) = swap_first;				\
+	(head2)->stqh_last = swap_last;					\
+	if (STAILQ_EMPTY(head1))					\
+		(head1)->stqh_last = &STAILQ_FIRST(head1);		\
+	if (STAILQ_EMPTY(head2))					\
+		(head2)->stqh_last = &STAILQ_FIRST(head2);		\
+} while (0)
+
+
+/*
+ * List declarations.
+ */
+#define	LIST_HEAD(name, type)						\
+struct name {								\
+	struct type *lh_first;	/* first element */			\
+}
+
+#define	LIST_HEAD_INITIALIZER(head)					\
+	{ NULL }
+
+#define	LIST_ENTRY(type)						\
+struct {								\
+	struct type *le_next;	/* next element */			\
+	struct type **le_prev;	/* address of previous next element */	\
+}
+
+/*
+ * List functions.
+ */
+
+#if (defined(_KERNEL) && defined(INVARIANTS))
+#define	QMD_LIST_CHECK_HEAD(head, field) do {				\
+	if (LIST_FIRST((head)) != NULL &&				\
+	    LIST_FIRST((head))->field.le_prev !=			\
+	     &LIST_FIRST((head)))					\
+		panic("Bad list head %p first->prev != head", (head));	\
+} while (0)
+
+#define	QMD_LIST_CHECK_NEXT(elm, field) do {				\
+	if (LIST_NEXT((elm), field) != NULL &&				\
+	    LIST_NEXT((elm), field)->field.le_prev !=			\
+	     &((elm)->field.le_next))					\
+	     	panic("Bad link elm %p next->prev != elm", (elm));	\
+} while (0)
+
+#define	QMD_LIST_CHECK_PREV(elm, field) do {				\
+	if (*(elm)->field.le_prev != (elm))				\
+		panic("Bad link elm %p prev->next != elm", (elm));	\
+} while (0)
+#else
+#define	QMD_LIST_CHECK_HEAD(head, field)
+#define	QMD_LIST_CHECK_NEXT(elm, field)
+#define	QMD_LIST_CHECK_PREV(elm, field)
+#endif /* (_KERNEL && INVARIANTS) */
+
+#define	LIST_EMPTY(head)	((head)->lh_first == NULL)
+
+#define	LIST_FIRST(head)	((head)->lh_first)
+
+#define	LIST_FOREACH(var, head, field)					\
+	for ((var) = LIST_FIRST((head));				\
+	    (var);							\
+	    (var) = LIST_NEXT((var), field))
+
+#define	LIST_FOREACH_SAFE(var, head, field, tvar)			\
+	for ((var) = LIST_FIRST((head));				\
+	    (var) && ((tvar) = LIST_NEXT((var), field), 1);		\
+	    (var) = (tvar))
+
+#define	LIST_INIT(head) do {						\
+	LIST_FIRST((head)) = NULL;					\
+} while (0)
+
+#define	LIST_INSERT_AFTER(listelm, elm, field) do {			\
+	QMD_LIST_CHECK_NEXT(listelm, field);				\
+	if ((LIST_NEXT((elm), field) = LIST_NEXT((listelm), field)) != NULL)\
+		LIST_NEXT((listelm), field)->field.le_prev =		\
+		    &LIST_NEXT((elm), field);				\
+	LIST_NEXT((listelm), field) = (elm);				\
+	(elm)->field.le_prev = &LIST_NEXT((listelm), field);		\
+} while (0)
+
+#define	LIST_INSERT_BEFORE(listelm, elm, field) do {			\
+	QMD_LIST_CHECK_PREV(listelm, field);				\
+	(elm)->field.le_prev = (listelm)->field.le_prev;		\
+	LIST_NEXT((elm), field) = (listelm);				\
+	*(listelm)->field.le_prev = (elm);				\
+	(listelm)->field.le_prev = &LIST_NEXT((elm), field);		\
+} while (0)
+
+#define	LIST_INSERT_HEAD(head, elm, field) do {				\
+	QMD_LIST_CHECK_HEAD((head), field);				\
+	if ((LIST_NEXT((elm), field) = LIST_FIRST((head))) != NULL)	\
+		LIST_FIRST((head))->field.le_prev = &LIST_NEXT((elm), field);\
+	LIST_FIRST((head)) = (elm);					\
+	(elm)->field.le_prev = &LIST_FIRST((head));			\
+} while (0)
+
+#define	LIST_NEXT(elm, field)	((elm)->field.le_next)
+
+#define	LIST_REMOVE(elm, field) do {					\
+	QMD_SAVELINK(oldnext, (elm)->field.le_next);			\
+	QMD_SAVELINK(oldprev, (elm)->field.le_prev);			\
+	QMD_LIST_CHECK_NEXT(elm, field);				\
+	QMD_LIST_CHECK_PREV(elm, field);				\
+	if (LIST_NEXT((elm), field) != NULL)				\
+		LIST_NEXT((elm), field)->field.le_prev = 		\
+		    (elm)->field.le_prev;				\
+	*(elm)->field.le_prev = LIST_NEXT((elm), field);		\
+	TRASHIT(*oldnext);						\
+	TRASHIT(*oldprev);						\
+} while (0)
+
+#define LIST_SWAP(head1, head2, type, field) do {			\
+	struct type *swap_tmp = LIST_FIRST((head1));			\
+	LIST_FIRST((head1)) = LIST_FIRST((head2));			\
+	LIST_FIRST((head2)) = swap_tmp;					\
+	if ((swap_tmp = LIST_FIRST((head1))) != NULL)			\
+		swap_tmp->field.le_prev = &LIST_FIRST((head1));		\
+	if ((swap_tmp = LIST_FIRST((head2))) != NULL)			\
+		swap_tmp->field.le_prev = &LIST_FIRST((head2));		\
+} while (0)
+
+/*
+ * Tail queue declarations.
+ */
+#define	TAILQ_HEAD(name, type)						\
+struct name {								\
+	struct type *tqh_first;	/* first element */			\
+	struct type **tqh_last;	/* addr of last next element */		\
+	TRACEBUF							\
+}
+
+#define	TAILQ_HEAD_INITIALIZER(head)					\
+	{ NULL, &(head).tqh_first }
+
+#define	TAILQ_ENTRY(type)						\
+struct {								\
+	struct type *tqe_next;	/* next element */			\
+	struct type **tqe_prev;	/* address of previous next element */	\
+	TRACEBUF							\
+}
+
+/*
+ * Tail queue functions.
+ */
+#if (defined(_KERNEL) && defined(INVARIANTS))
+#define	QMD_TAILQ_CHECK_HEAD(head, field) do {				\
+	if (!TAILQ_EMPTY(head) &&					\
+	    TAILQ_FIRST((head))->field.tqe_prev !=			\
+	     &TAILQ_FIRST((head)))					\
+		panic("Bad tailq head %p first->prev != head", (head));	\
+} while (0)
+
+#define	QMD_TAILQ_CHECK_TAIL(head, field) do {				\
+	if (*(head)->tqh_last != NULL)					\
+	    	panic("Bad tailq NEXT(%p->tqh_last) != NULL", (head)); 	\
+} while (0)
+
+#define	QMD_TAILQ_CHECK_NEXT(elm, field) do {				\
+	if (TAILQ_NEXT((elm), field) != NULL &&				\
+	    TAILQ_NEXT((elm), field)->field.tqe_prev !=			\
+	     &((elm)->field.tqe_next))					\
+		panic("Bad link elm %p next->prev != elm", (elm));	\
+} while (0)
+
+#define	QMD_TAILQ_CHECK_PREV(elm, field) do {				\
+	if (*(elm)->field.tqe_prev != (elm))				\
+		panic("Bad link elm %p prev->next != elm", (elm));	\
+} while (0)
+#else
+#define	QMD_TAILQ_CHECK_HEAD(head, field)
+#define	QMD_TAILQ_CHECK_TAIL(head, headname)
+#define	QMD_TAILQ_CHECK_NEXT(elm, field)
+#define	QMD_TAILQ_CHECK_PREV(elm, field)
+#endif /* (_KERNEL && INVARIANTS) */
+
+#define	TAILQ_CONCAT(head1, head2, field) do {				\
+	if (!TAILQ_EMPTY(head2)) {					\
+		*(head1)->tqh_last = (head2)->tqh_first;		\
+		(head2)->tqh_first->field.tqe_prev = (head1)->tqh_last;	\
+		(head1)->tqh_last = (head2)->tqh_last;			\
+		TAILQ_INIT((head2));					\
+		QMD_TRACE_HEAD(head1);					\
+		QMD_TRACE_HEAD(head2);					\
+	}								\
+} while (0)
+
+#define	TAILQ_EMPTY(head)	((head)->tqh_first == NULL)
+
+#define	TAILQ_FIRST(head)	((head)->tqh_first)
+
+#define	TAILQ_FOREACH(var, head, field)					\
+	for ((var) = TAILQ_FIRST((head));				\
+	    (var);							\
+	    (var) = TAILQ_NEXT((var), field))
+
+#define	TAILQ_FOREACH_SAFE(var, head, field, tvar)			\
+	for ((var) = TAILQ_FIRST((head));				\
+	    (var) && ((tvar) = TAILQ_NEXT((var), field), 1);		\
+	    (var) = (tvar))
+
+#define	TAILQ_FOREACH_REVERSE(var, head, headname, field)		\
+	for ((var) = TAILQ_LAST((head), headname);			\
+	    (var);							\
+	    (var) = TAILQ_PREV((var), headname, field))
+
+#define	TAILQ_FOREACH_REVERSE_SAFE(var, head, headname, field, tvar)	\
+	for ((var) = TAILQ_LAST((head), headname);			\
+	    (var) && ((tvar) = TAILQ_PREV((var), headname, field), 1);	\
+	    (var) = (tvar))
+
+#define	TAILQ_INIT(head) do {						\
+	TAILQ_FIRST((head)) = NULL;					\
+	(head)->tqh_last = &TAILQ_FIRST((head));			\
+	QMD_TRACE_HEAD(head);						\
+} while (0)
+
+#define	TAILQ_INSERT_AFTER(head, listelm, elm, field) do {		\
+	QMD_TAILQ_CHECK_NEXT(listelm, field);				\
+	if ((TAILQ_NEXT((elm), field) = TAILQ_NEXT((listelm), field)) != NULL)\
+		TAILQ_NEXT((elm), field)->field.tqe_prev = 		\
+		    &TAILQ_NEXT((elm), field);				\
+	else {								\
+		(head)->tqh_last = &TAILQ_NEXT((elm), field);		\
+		QMD_TRACE_HEAD(head);					\
+	}								\
+	TAILQ_NEXT((listelm), field) = (elm);				\
+	(elm)->field.tqe_prev = &TAILQ_NEXT((listelm), field);		\
+	QMD_TRACE_ELEM(&(elm)->field);					\
+	QMD_TRACE_ELEM(&listelm->field);				\
+} while (0)
+
+#define	TAILQ_INSERT_BEFORE(listelm, elm, field) do {			\
+	QMD_TAILQ_CHECK_PREV(listelm, field);				\
+	(elm)->field.tqe_prev = (listelm)->field.tqe_prev;		\
+	TAILQ_NEXT((elm), field) = (listelm);				\
+	*(listelm)->field.tqe_prev = (elm);				\
+	(listelm)->field.tqe_prev = &TAILQ_NEXT((elm), field);		\
+	QMD_TRACE_ELEM(&(elm)->field);					\
+	QMD_TRACE_ELEM(&listelm->field);				\
+} while (0)
+
+#define	TAILQ_INSERT_HEAD(head, elm, field) do {			\
+	QMD_TAILQ_CHECK_HEAD(head, field);				\
+	if ((TAILQ_NEXT((elm), field) = TAILQ_FIRST((head))) != NULL)	\
+		TAILQ_FIRST((head))->field.tqe_prev =			\
+		    &TAILQ_NEXT((elm), field);				\
+	else								\
+		(head)->tqh_last = &TAILQ_NEXT((elm), field);		\
+	TAILQ_FIRST((head)) = (elm);					\
+	(elm)->field.tqe_prev = &TAILQ_FIRST((head));			\
+	QMD_TRACE_HEAD(head);						\
+	QMD_TRACE_ELEM(&(elm)->field);					\
+} while (0)
+
+#define	TAILQ_INSERT_TAIL(head, elm, field) do {			\
+	QMD_TAILQ_CHECK_TAIL(head, field);				\
+	TAILQ_NEXT((elm), field) = NULL;				\
+	(elm)->field.tqe_prev = (head)->tqh_last;			\
+	*(head)->tqh_last = (elm);					\
+	(head)->tqh_last = &TAILQ_NEXT((elm), field);			\
+	QMD_TRACE_HEAD(head);						\
+	QMD_TRACE_ELEM(&(elm)->field);					\
+} while (0)
+
+#define	TAILQ_LAST(head, headname)					\
+	(*(((struct headname *)((head)->tqh_last))->tqh_last))
+
+#define	TAILQ_NEXT(elm, field) ((elm)->field.tqe_next)
+
+#define	TAILQ_PREV(elm, headname, field)				\
+	(*(((struct headname *)((elm)->field.tqe_prev))->tqh_last))
+
+#define	TAILQ_REMOVE(head, elm, field) do {				\
+	QMD_SAVELINK(oldnext, (elm)->field.tqe_next);			\
+	QMD_SAVELINK(oldprev, (elm)->field.tqe_prev);			\
+	QMD_TAILQ_CHECK_NEXT(elm, field);				\
+	QMD_TAILQ_CHECK_PREV(elm, field);				\
+	if ((TAILQ_NEXT((elm), field)) != NULL)				\
+		TAILQ_NEXT((elm), field)->field.tqe_prev = 		\
+		    (elm)->field.tqe_prev;				\
+	else {								\
+		(head)->tqh_last = (elm)->field.tqe_prev;		\
+		QMD_TRACE_HEAD(head);					\
+	}								\
+	*(elm)->field.tqe_prev = TAILQ_NEXT((elm), field);		\
+	TRASHIT(*oldnext);						\
+	TRASHIT(*oldprev);						\
+	QMD_TRACE_ELEM(&(elm)->field);					\
+} while (0)
+
+#define TAILQ_SWAP(head1, head2, type, field) do {			\
+	struct type *swap_first = (head1)->tqh_first;			\
+	struct type **swap_last = (head1)->tqh_last;			\
+	(head1)->tqh_first = (head2)->tqh_first;			\
+	(head1)->tqh_last = (head2)->tqh_last;				\
+	(head2)->tqh_first = swap_first;				\
+	(head2)->tqh_last = swap_last;					\
+	if ((swap_first = (head1)->tqh_first) != NULL)			\
+		swap_first->field.tqe_prev = &(head1)->tqh_first;	\
+	else								\
+		(head1)->tqh_last = &(head1)->tqh_first;		\
+	if ((swap_first = (head2)->tqh_first) != NULL)			\
+		swap_first->field.tqe_prev = &(head2)->tqh_first;	\
+	else								\
+		(head2)->tqh_last = &(head2)->tqh_first;		\
+} while (0)
+
+#endif /* !_SYS_QUEUE_H_ */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 18:55:50 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 18: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.xensource.com>)
	id 1RZ5bf-0001F1-CO; Fri, 09 Dec 2011 18:55:39 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RZ5bd-0001BB-MX
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 18:55:37 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1323456879!6616386!12
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI2MQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21440 invoked from network); 9 Dec 2011 18:54:47 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 18:54:47 -0000
X-IronPort-AV: E=Sophos;i="4.71,327,1320624000"; 
   d="scan'208";a="9392203"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 18:54:47 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 18:54:47 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RZ5ap-0002eF-Aq; Fri, 09 Dec 2011 18:54:47 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RZ5ap-00040d-A4;
	Fri, 09 Dec 2011 18:54:47 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Fri, 9 Dec 2011 18:54:30 +0000
Message-ID: <1323456877-15315-12-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1323456877-15315-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1323456877-15315-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 11/18] libxl: make libxl__free_all idempotent
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl_internal.c |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c
index ae28cb0..a2e5820 100644
--- a/tools/libxl/libxl_internal.c
+++ b/tools/libxl/libxl_internal.c
@@ -72,6 +72,8 @@ void libxl__free_all(libxl__gc *gc)
         free(ptr);
     }
     free(gc->alloc_ptrs);
+    gc->alloc_ptrs = 0;
+    gc->alloc_maxsize = 0;
 }
 
 void *libxl__zalloc(libxl__gc *gc, int bytes)
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 18:55:50 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 18: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.xensource.com>)
	id 1RZ5bZ-0001BM-LQ; Fri, 09 Dec 2011 18:55:33 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RZ5bX-0001Ac-F1
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 18:55:31 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1323456879!6616386!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI2MQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21201 invoked from network); 9 Dec 2011 18:54:41 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 18:54:41 -0000
X-IronPort-AV: E=Sophos;i="4.71,327,1320624000"; 
   d="scan'208";a="9392193"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 18:54:41 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 18:54:41 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RZ5aj-0002dl-3c; Fri, 09 Dec 2011 18:54:41 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RZ5aj-0003zu-2r;
	Fri, 09 Dec 2011 18:54:41 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Fri, 9 Dec 2011 18:54:20 +0000
Message-ID: <1323456877-15315-2-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1323456877-15315-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1323456877-15315-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 01/18] libxl: Make libxl__xs_* more const-correct
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Paths and values which are not modified by these functions should be
declared as "const char *" not "char *".

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl_internal.h |    9 +++++----
 tools/libxl/libxl_xshelp.c   |    9 +++++----
 2 files changed, 10 insertions(+), 8 deletions(-)

diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 84da6b1..bfc74c9 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -172,18 +172,19 @@ _hidden char *libxl__dirname(libxl__gc *gc, const char *s);
 _hidden char **libxl__xs_kvs_of_flexarray(libxl__gc *gc, flexarray_t *array, int length);
 
 _hidden int libxl__xs_writev(libxl__gc *gc, xs_transaction_t t,
-                    char *dir, char **kvs);
+                             const char *dir, char **kvs);
 _hidden int libxl__xs_write(libxl__gc *gc, xs_transaction_t t,
-                   char *path, const char *fmt, ...) PRINTF_ATTRIBUTE(4, 5);
+               const char *path, const char *fmt, ...) PRINTF_ATTRIBUTE(4, 5);
    /* Each fn returns 0 on success.
     * On error: returns -1, sets errno (no logging) */
 
 _hidden char *libxl__xs_get_dompath(libxl__gc *gc, uint32_t domid);
    /* On error: logs, returns NULL, sets errno. */
 
-_hidden char *libxl__xs_read(libxl__gc *gc, xs_transaction_t t, char *path);
+_hidden char *libxl__xs_read(libxl__gc *gc, xs_transaction_t t,
+                             const char *path);
 _hidden char **libxl__xs_directory(libxl__gc *gc, xs_transaction_t t,
-                                   char *path, unsigned int *nb);
+                                   const char *path, unsigned int *nb);
    /* On error: returns NULL, sets errno (no logging) */
 
 _hidden char *libxl__xs_libxl_path(libxl__gc *gc, uint32_t domid);
diff --git a/tools/libxl/libxl_xshelp.c b/tools/libxl/libxl_xshelp.c
index 4b09be3..bc4e7e4 100644
--- a/tools/libxl/libxl_xshelp.c
+++ b/tools/libxl/libxl_xshelp.c
@@ -49,7 +49,7 @@ char **libxl__xs_kvs_of_flexarray(libxl__gc *gc, flexarray_t *array, int length)
 }
 
 int libxl__xs_writev(libxl__gc *gc, xs_transaction_t t,
-                    char *dir, char *kvs[])
+                     const char *dir, char *kvs[])
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
     char *path;
@@ -69,7 +69,7 @@ int libxl__xs_writev(libxl__gc *gc, xs_transaction_t t,
 }
 
 int libxl__xs_write(libxl__gc *gc, xs_transaction_t t,
-                   char *path, const char *fmt, ...)
+                    const char *path, const char *fmt, ...)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
     char *s;
@@ -87,7 +87,7 @@ int libxl__xs_write(libxl__gc *gc, xs_transaction_t t,
     return 0;
 }
 
-char * libxl__xs_read(libxl__gc *gc, xs_transaction_t t, char *path)
+char * libxl__xs_read(libxl__gc *gc, xs_transaction_t t, const char *path)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
     char *ptr;
@@ -113,7 +113,8 @@ char *libxl__xs_get_dompath(libxl__gc *gc, uint32_t domid)
     return s;
 }
 
-char **libxl__xs_directory(libxl__gc *gc, xs_transaction_t t, char *path, unsigned int *nb)
+char **libxl__xs_directory(libxl__gc *gc, xs_transaction_t t,
+                           const char *path, unsigned int *nb)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
     char **ret = NULL;
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 18:55:51 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 18: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.xensource.com>)
	id 1RZ5be-0001EK-R0; Fri, 09 Dec 2011 18:55:38 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RZ5bd-0001B8-3v
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 18:55:37 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1323456879!6616386!11
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI2MQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21409 invoked from network); 9 Dec 2011 18:54:47 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 18:54:47 -0000
X-IronPort-AV: E=Sophos;i="4.71,327,1320624000"; 
   d="scan'208";a="9392202"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 18:54:47 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 18:54:47 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RZ5ao-0002eC-Rc; Fri, 09 Dec 2011 18:54:46 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RZ5ao-00040Z-Qr;
	Fri, 09 Dec 2011 18:54:46 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Fri, 9 Dec 2011 18:54:29 +0000
Message-ID: <1323456877-15315-11-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1323456877-15315-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1323456877-15315-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 10/18] libxl: make libxl__[v]log const-correct
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl_internal.c |    4 ++--
 tools/libxl/libxl_internal.h |    4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c
index d767ce3..ae28cb0 100644
--- a/tools/libxl/libxl_internal.c
+++ b/tools/libxl/libxl_internal.c
@@ -179,7 +179,7 @@ char *libxl__dirname(libxl__gc *gc, const char *s)
 
 void libxl__logv(libxl_ctx *ctx, xentoollog_level msglevel, int errnoval,
              const char *file, int line, const char *func,
-             char *fmt, va_list ap)
+             const char *fmt, va_list ap)
 {
     char *enomem = "[out of memory formatting log message]";
     char *base = NULL;
@@ -206,7 +206,7 @@ void libxl__logv(libxl_ctx *ctx, xentoollog_level msglevel, int errnoval,
 
 void libxl__log(libxl_ctx *ctx, xentoollog_level msglevel, int errnoval,
             const char *file, int line, const char *func,
-            char *fmt, ...)
+            const char *fmt, ...)
 {
     va_list ap;
     va_start(ap, fmt);
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 41de6fd..1d1dc35 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -80,13 +80,13 @@
 _hidden void libxl__logv(libxl_ctx *ctx, xentoollog_level msglevel, int errnoval,
              const char *file /* may be 0 */, int line /* ignored if !file */,
              const char *func /* may be 0 */,
-             char *fmt, va_list al)
+             const char *fmt, va_list al)
      __attribute__((format(printf,7,0)));
 
 _hidden void libxl__log(libxl_ctx *ctx, xentoollog_level msglevel, int errnoval,
             const char *file /* may be 0 */, int line /* ignored if !file */,
             const char *func /* may be 0 */,
-            char *fmt, ...)
+            const char *fmt, ...)
      __attribute__((format(printf,7,8)));
 
      /* these functions preserve errno (saving and restoring) */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 18:55:51 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 18: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.xensource.com>)
	id 1RZ5bX-0001Av-8l; Fri, 09 Dec 2011 18:55:31 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RZ5bV-0001AW-HE
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 18:55:29 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1323456879!6616386!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI2MQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21162 invoked from network); 9 Dec 2011 18:54:39 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 18:54:39 -0000
X-IronPort-AV: E=Sophos;i="4.71,327,1320624000"; 
   d="scan'208";a="9392192"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 18:54:39 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 18:54:39 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RZ5ag-0002di-Rh; Fri, 09 Dec 2011 18:54:38 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RZ5ag-0003zk-QN;
	Fri, 09 Dec 2011 18:54:38 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Fri, 9 Dec 2011 18:54:19 +0000
Message-ID: <1323456877-15315-1-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Subject: [Xen-devel] [PATCH v5 00/18] New event API
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Yet another version of my event handling API series I'm afraid.  This
addresses all comments so far.

Many of the earlier parts of the series have been acked and are
reposted for completeness.  Hopefully we will be able to apply these
early parts 01-13 soon:
    01/18 libxl: Make libxl__xs_* more const-correct
    02/18 libxenstore: Provide xs_check_watch
    03/18 libxl: Provide a version of bsd's queue.h as _libxl_list.h
    04/18 libxl: idl: support new "private" type attribute
    05/18 libxl: idl: Provide struct and union tags
    06/18 libxl: permit declaration after statement
    07/18 libxl: internal convenience macros
    08/18 libxl: Rationalise #includes
    09/18 libxl: introduce lock in libxl_ctx
    10/18 libxl: make libxl__[v]log const-correct
    11/18 libxl: make libxl__free_all idempotent
  * 12/18 libxl: libxl_ctx_free should free the ctx
    13/18 libxl: Use GC_INIT and GC_FREE everywhere
Of these 12/18 is new but I think obviously correct.  After that's
acked, and test passes and patch backlog permitting, I intend to apply
those.

And here are the remaining patches, including the meat, which are
still undergoing review:
    14/18 libxl: make LIBXL_INIT_GC a statement, not an initialiser
    15/18 xenstore: New function xs_path_is_subpath
    16/18 libxl: rename libxl__free_all
    17/18 libxl: New API for providing OS events to libxl
    18/18 libxl: New event generation API


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 18:55:51 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 18: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.xensource.com>)
	id 1RZ5bf-0001FK-OJ; Fri, 09 Dec 2011 18:55:39 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RZ5bd-0001BD-W0
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 18:55:38 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1323456879!6616386!13
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI2MQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21457 invoked from network); 9 Dec 2011 18:54:48 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 18:54:48 -0000
X-IronPort-AV: E=Sophos;i="4.71,327,1320624000"; 
   d="scan'208";a="9392204"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 18:54:48 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 18:54:48 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RZ5ap-0002eI-RL; Fri, 09 Dec 2011 18:54:47 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RZ5ap-00040h-Qa;
	Fri, 09 Dec 2011 18:54:47 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Fri, 9 Dec 2011 18:54:31 +0000
Message-ID: <1323456877-15315-13-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1323456877-15315-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1323456877-15315-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 12/18] libxl: libxl_ctx_free should free the ctx
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 7488538..5a29c29 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -93,6 +93,7 @@ int libxl_ctx_free(libxl_ctx *ctx)
     if (ctx->xch) xc_interface_close(ctx->xch);
     libxl_version_info_dispose(&ctx->version_info);
     if (ctx->xsh) xs_daemon_close(ctx->xsh);
+    free(ctx);
     return 0;
 }
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 18:55:51 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 18: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.xensource.com>)
	id 1RZ5bg-0001GJ-MY; Fri, 09 Dec 2011 18:55:40 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RZ5bf-0001BN-13
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 18:55:39 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1323456879!6616386!14
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI2MQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21474 invoked from network); 9 Dec 2011 18:54:48 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 18:54:48 -0000
X-IronPort-AV: E=Sophos;i="4.71,327,1320624000"; 
   d="scan'208";a="9392205"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 18:54:48 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 18:54:48 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RZ5aq-0002eL-Ag; Fri, 09 Dec 2011 18:54:48 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RZ5aq-00040l-9p;
	Fri, 09 Dec 2011 18:54:48 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 9 Dec 2011 18:54:32 +0000
Message-ID: <1323456877-15315-14-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1323456877-15315-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1323456877-15315-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 13/18] libxl: Use GC_INIT and GC_FREE everywhere
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Replace
    libxl__gc gc = LIBXL_INIT_GC(ctx);
    ...
    libxl__free_all(&gc);
with
    GC_INIT(ctx);
    ...
    GC_FREE;
throughout with a couple of perl runes.

We must then adjust uses of the resulting gc for pointerness, which is
mostly just replacing all occurrences of "&gc" with "gc".  Also a
couple of unusual uses of LIBXL_INIT_GC needed to be fixed up by hand.

Here are those runes:
 perl -i -pe 's/\Q    libxl__gc gc = LIBXL_INIT_GC(ctx);/    GC_INIT(ctx);/' tools/libxl/*.c
 perl -i -pe 's/\Q    libxl__free_all(&gc);/    GC_FREE;/' tools/libxl/*.c

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl.c            |  590 ++++++++++++++++++++--------------------
 tools/libxl/libxl_bootloader.c |   14 +-
 tools/libxl/libxl_create.c     |   12 +-
 tools/libxl/libxl_dom.c        |   16 +-
 tools/libxl/libxl_pci.c        |   34 ++--
 tools/libxl/libxl_qmp.c        |   32 +-
 tools/libxl/libxl_utils.c      |   36 ++--
 7 files changed, 367 insertions(+), 367 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 5a29c29..79ea701 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -233,19 +233,19 @@ int libxl__domain_rename(libxl__gc *gc, uint32_t domid,
 int libxl_domain_rename(libxl_ctx *ctx, uint32_t domid,
                         const char *old_name, const char *new_name)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     int rc;
-    rc = libxl__domain_rename(&gc, domid, old_name, new_name, XBT_NULL);
-    libxl__free_all(&gc);
+    rc = libxl__domain_rename(gc, domid, old_name, new_name, XBT_NULL);
+    GC_FREE;
     return rc;
 }
 
 int libxl_domain_resume(libxl_ctx *ctx, uint32_t domid)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     int rc = 0;
 
-    if (LIBXL__DOMAIN_IS_TYPE(&gc,  domid, HVM)) {
+    if (LIBXL__DOMAIN_IS_TYPE(gc,  domid, HVM)) {
         LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Called domain_resume on "
                 "non-cooperative hvm domain %u", domid);
         rc = ERROR_NI;
@@ -265,7 +265,7 @@ int libxl_domain_resume(libxl_ctx *ctx, uint32_t domid)
         rc = ERROR_FAIL;
     }
 out:
-    libxl__free_all(&gc);
+    GC_FREE;
     return rc;
 }
 
@@ -278,7 +278,7 @@ out:
 int libxl_domain_preserve(libxl_ctx *ctx, uint32_t domid,
                           libxl_domain_create_info *info, const char *name_suffix, libxl_uuid new_uuid)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     struct xs_permissions roperm[2];
     xs_transaction_t t;
     char *preserved_name;
@@ -288,27 +288,27 @@ int libxl_domain_preserve(libxl_ctx *ctx, uint32_t domid,
 
     int rc;
 
-    preserved_name = libxl__sprintf(&gc, "%s%s", info->name, name_suffix);
+    preserved_name = libxl__sprintf(gc, "%s%s", info->name, name_suffix);
     if (!preserved_name) {
-        libxl__free_all(&gc);
+        GC_FREE;
         return ERROR_NOMEM;
     }
 
-    uuid_string = libxl__uuid2string(&gc, new_uuid);
+    uuid_string = libxl__uuid2string(gc, new_uuid);
     if (!uuid_string) {
-        libxl__free_all(&gc);
+        GC_FREE;
         return ERROR_NOMEM;
     }
 
-    dom_path = libxl__xs_get_dompath(&gc, domid);
+    dom_path = libxl__xs_get_dompath(gc, domid);
     if (!dom_path) {
-        libxl__free_all(&gc);
+        GC_FREE;
         return ERROR_FAIL;
     }
 
-    vm_path = libxl__sprintf(&gc, "/vm/%s", uuid_string);
+    vm_path = libxl__sprintf(gc, "/vm/%s", uuid_string);
     if (!vm_path) {
-        libxl__free_all(&gc);
+        GC_FREE;
         return ERROR_FAIL;
     }
 
@@ -324,20 +324,20 @@ int libxl_domain_preserve(libxl_ctx *ctx, uint32_t domid,
     xs_mkdir(ctx->xsh, t, vm_path);
     xs_set_permissions(ctx->xsh, t, vm_path, roperm, ARRAY_SIZE(roperm));
 
-    xs_write(ctx->xsh, t, libxl__sprintf(&gc, "%s/vm", dom_path), vm_path, strlen(vm_path));
-    rc = libxl__domain_rename(&gc, domid, info->name, preserved_name, t);
+    xs_write(ctx->xsh, t, libxl__sprintf(gc, "%s/vm", dom_path), vm_path, strlen(vm_path));
+    rc = libxl__domain_rename(gc, domid, info->name, preserved_name, t);
     if (rc) {
-        libxl__free_all(&gc);
+        GC_FREE;
         return rc;
     }
 
-    xs_write(ctx->xsh, t, libxl__sprintf(&gc, "%s/uuid", vm_path), uuid_string, strlen(uuid_string));
+    xs_write(ctx->xsh, t, libxl__sprintf(gc, "%s/uuid", vm_path), uuid_string, strlen(uuid_string));
 
     if (!xs_transaction_end(ctx->xsh, t, 0))
         if (errno == EAGAIN)
             goto retry_transaction;
 
-    libxl__free_all(&gc);
+    GC_FREE;
     return 0;
 }
 
@@ -479,16 +479,16 @@ libxl_vminfo * libxl_list_vm(libxl_ctx *ctx, int *nb_vm)
 int libxl_domain_suspend(libxl_ctx *ctx, libxl_domain_suspend_info *info,
                          uint32_t domid, int fd)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
-    libxl_domain_type type = libxl__domain_type(&gc, domid);
+    GC_INIT(ctx);
+    libxl_domain_type type = libxl__domain_type(gc, domid);
     int live = info != NULL && info->flags & XL_SUSPEND_LIVE;
     int debug = info != NULL && info->flags & XL_SUSPEND_DEBUG;
     int rc = 0;
 
-    rc = libxl__domain_suspend_common(&gc, domid, fd, type, live, debug);
+    rc = libxl__domain_suspend_common(gc, domid, fd, type, live, debug);
     if (!rc && type == LIBXL_DOMAIN_TYPE_HVM)
-        rc = libxl__domain_save_device_model(&gc, domid, fd);
-    libxl__free_all(&gc);
+        rc = libxl__domain_save_device_model(gc, domid, fd);
+    GC_FREE;
     return rc;
 }
 
@@ -518,17 +518,17 @@ int libxl_domain_core_dump(libxl_ctx *ctx, uint32_t domid,
 
 int libxl_domain_unpause(libxl_ctx *ctx, uint32_t domid)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     char *path;
     char *state;
     int ret, rc = 0;
 
-    if (LIBXL__DOMAIN_IS_TYPE(&gc,  domid, HVM)) {
-        path = libxl__sprintf(&gc, "/local/domain/0/device-model/%d/state", domid);
-        state = libxl__xs_read(&gc, XBT_NULL, path);
+    if (LIBXL__DOMAIN_IS_TYPE(gc,  domid, HVM)) {
+        path = libxl__sprintf(gc, "/local/domain/0/device-model/%d/state", domid);
+        state = libxl__xs_read(gc, XBT_NULL, path);
         if (state != NULL && !strcmp(state, "paused")) {
-            libxl__xs_write(&gc, XBT_NULL, libxl__sprintf(&gc, "/local/domain/0/device-model/%d/command", domid), "continue");
-            libxl__wait_for_device_model(&gc, domid, "running",
+            libxl__xs_write(gc, XBT_NULL, libxl__sprintf(gc, "/local/domain/0/device-model/%d/command", domid), "continue");
+            libxl__wait_for_device_model(gc, domid, "running",
                                          NULL, NULL, NULL);
         }
     }
@@ -537,7 +537,7 @@ int libxl_domain_unpause(libxl_ctx *ctx, uint32_t domid)
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "unpausing domain %d", domid);
         rc = ERROR_FAIL;
     }
-    libxl__free_all(&gc);
+    GC_FREE;
     return rc;
 }
 
@@ -551,42 +551,42 @@ static char *req_table[] = {
 
 int libxl_domain_shutdown(libxl_ctx *ctx, uint32_t domid, int req)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     char *shutdown_path;
     char *dom_path;
 
     if (req > ARRAY_SIZE(req_table)) {
-        libxl__free_all(&gc);
+        GC_FREE;
         return ERROR_INVAL;
     }
 
-    dom_path = libxl__xs_get_dompath(&gc, domid);
+    dom_path = libxl__xs_get_dompath(gc, domid);
     if (!dom_path) {
-        libxl__free_all(&gc);
+        GC_FREE;
         return ERROR_FAIL;
     }
 
-    if (LIBXL__DOMAIN_IS_TYPE(&gc,  domid, HVM)) {
+    if (LIBXL__DOMAIN_IS_TYPE(gc,  domid, HVM)) {
         unsigned long pvdriver = 0;
         int ret;
         ret = xc_get_hvm_param(ctx->xch, domid, HVM_PARAM_CALLBACK_IRQ, &pvdriver);
         if (ret<0) {
             LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "getting HVM callback IRQ");
-            libxl__free_all(&gc);
+            GC_FREE;
             return ERROR_FAIL;
         }
         if (!pvdriver) {
             LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "HVM domain without PV drivers:"
                        " graceful shutdown not possible, use destroy");
-            libxl__free_all(&gc);
+            GC_FREE;
             return ERROR_FAIL;
         }
     }
 
-    shutdown_path = libxl__sprintf(&gc, "%s/control/shutdown", dom_path);
+    shutdown_path = libxl__sprintf(gc, "%s/control/shutdown", dom_path);
     xs_write(ctx->xsh, XBT_NULL, shutdown_path, req_table[req], strlen(req_table[req]));
 
-    libxl__free_all(&gc);
+    GC_FREE;
     return 0;
 }
 
@@ -608,7 +608,7 @@ int libxl_wait_for_domain_death(libxl_ctx *ctx, uint32_t domid, libxl_waiter *wa
 
 int libxl_wait_for_disk_ejects(libxl_ctx *ctx, uint32_t guest_domid, libxl_device_disk *disks, int num_disks, libxl_waiter *waiter)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     int i, rc = -1;
     uint32_t domid = libxl_get_stubdom_id(ctx, guest_domid);
 
@@ -617,7 +617,7 @@ int libxl_wait_for_disk_ejects(libxl_ctx *ctx, uint32_t guest_domid, libxl_devic
 
     for (i = 0; i < num_disks; i++) {
         if (asprintf(&(waiter[i].path), "%s/device/vbd/%d/eject",
-                     libxl__xs_get_dompath(&gc, domid),
+                     libxl__xs_get_dompath(gc, domid),
                      libxl__device_disk_dev_number(disks[i].vdev,
                                                    NULL, NULL)) < 0)
             goto out;
@@ -627,7 +627,7 @@ int libxl_wait_for_disk_ejects(libxl_ctx *ctx, uint32_t guest_domid, libxl_devic
     }
     rc = 0;
 out:
-    libxl__free_all(&gc);
+    GC_FREE;
     return rc;
 }
 
@@ -681,22 +681,22 @@ int libxl_event_get_domain_death_info(libxl_ctx *ctx, uint32_t domid, libxl_even
 
 int libxl_event_get_disk_eject_info(libxl_ctx *ctx, uint32_t domid, libxl_event *event, libxl_device_disk *disk)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     char *path;
     char *backend;
     char *value;
     char backend_type[BACKEND_STRING_SIZE+1];
 
-    value = libxl__xs_read(&gc, XBT_NULL, event->path);
+    value = libxl__xs_read(gc, XBT_NULL, event->path);
 
     if (!value || strcmp(value,  "eject")) {
-        libxl__free_all(&gc);
+        GC_FREE;
         return 0;
     }
 
     path = strdup(event->path);
     path[strlen(path) - 6] = '\0';
-    backend = libxl__xs_read(&gc, XBT_NULL, libxl__sprintf(&gc, "%s/backend", path));
+    backend = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/backend", path));
 
     sscanf(backend,
             "/local/domain/%d/backend/%" TOSTRING(BACKEND_STRING_SIZE) "[a-z]/%*d/%*d",
@@ -712,19 +712,19 @@ int libxl_event_get_disk_eject_info(libxl_ctx *ctx, uint32_t domid, libxl_event
     disk->pdev_path = strdup("");
     disk->format = LIBXL_DISK_FORMAT_EMPTY;
     /* this value is returned to the user: do not free right away */
-    disk->vdev = xs_read(ctx->xsh, XBT_NULL, libxl__sprintf(&gc, "%s/dev", backend), NULL);
+    disk->vdev = xs_read(ctx->xsh, XBT_NULL, libxl__sprintf(gc, "%s/dev", backend), NULL);
     disk->removable = 1;
     disk->readwrite = 0;
     disk->is_cdrom = 1;
 
     free(path);
-    libxl__free_all(&gc);
+    GC_FREE;
     return 1;
 }
 
 int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid, int force)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     libxl_dominfo dominfo;
     char *dom_path;
     char *vm_path;
@@ -741,40 +741,40 @@ int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid, int force)
         return rc;
     }
 
-    switch (libxl__domain_type(&gc, domid)) {
+    switch (libxl__domain_type(gc, domid)) {
     case LIBXL_DOMAIN_TYPE_HVM:
         dm_present = 1;
         break;
     case LIBXL_DOMAIN_TYPE_PV:
-        pid = libxl__xs_read(&gc, XBT_NULL, libxl__sprintf(&gc, "/local/domain/%d/image/device-model-pid", domid));
+        pid = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "/local/domain/%d/image/device-model-pid", domid));
         dm_present = (pid != NULL);
         break;
     default:
         abort();
     }
 
-    dom_path = libxl__xs_get_dompath(&gc, domid);
+    dom_path = libxl__xs_get_dompath(gc, domid);
     if (!dom_path) {
         rc = ERROR_FAIL;
         goto out;
     }
 
-    if (libxl__device_pci_destroy_all(&gc, domid) < 0)
+    if (libxl__device_pci_destroy_all(gc, domid) < 0)
         LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "pci shutdown failed for domid %d", domid);
     rc = xc_domain_pause(ctx->xch, domid);
     if (rc < 0) {
         LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, rc, "xc_domain_pause failed for %d", domid);
     }
     if (dm_present) {
-        if (libxl__destroy_device_model(&gc, domid) < 0)
+        if (libxl__destroy_device_model(gc, domid) < 0)
             LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "libxl__destroy_device_model failed for %d", domid);
 
-        libxl__qmp_cleanup(&gc, domid);
+        libxl__qmp_cleanup(gc, domid);
     }
-    if (libxl__devices_destroy(&gc, domid, force) < 0)
+    if (libxl__devices_destroy(gc, domid, force) < 0)
         LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "libxl_devices_dispose failed for %d", domid);
 
-    vm_path = libxl__xs_read(&gc, XBT_NULL, libxl__sprintf(&gc, "%s/vm", dom_path));
+    vm_path = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/vm", dom_path));
     if (vm_path)
         if (!xs_rm(ctx->xsh, XBT_NULL, vm_path))
             LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "xs_rm failed for %s", vm_path);
@@ -782,9 +782,9 @@ int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid, int force)
     if (!xs_rm(ctx->xsh, XBT_NULL, dom_path))
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "xs_rm failed for %s", dom_path);
 
-    xs_rm(ctx->xsh, XBT_NULL, libxl__xs_libxl_path(&gc, domid));
+    xs_rm(ctx->xsh, XBT_NULL, libxl__xs_libxl_path(gc, domid));
 
-    libxl__userdata_destroyall(&gc, domid);
+    libxl__userdata_destroyall(gc, domid);
 
     rc = xc_domain_destroy(ctx->xch, domid);
     if (rc < 0) {
@@ -794,16 +794,16 @@ int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid, int force)
     }
     rc = 0;
 out:
-    libxl__free_all(&gc);
+    GC_FREE;
     return rc;
 }
 
 int libxl_console_exec(libxl_ctx *ctx, uint32_t domid, int cons_num, libxl_console_type type)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
-    char *p = libxl__sprintf(&gc, "%s/xenconsole", libxl_private_bindir_path());
-    char *domid_s = libxl__sprintf(&gc, "%d", domid);
-    char *cons_num_s = libxl__sprintf(&gc, "%d", cons_num);
+    GC_INIT(ctx);
+    char *p = libxl__sprintf(gc, "%s/xenconsole", libxl_private_bindir_path());
+    char *domid_s = libxl__sprintf(gc, "%d", domid);
+    char *cons_num_s = libxl__sprintf(gc, "%d", cons_num);
     char *cons_type_s;
 
     switch (type) {
@@ -820,20 +820,20 @@ int libxl_console_exec(libxl_ctx *ctx, uint32_t domid, int cons_num, libxl_conso
     execl(p, p, domid_s, "--num", cons_num_s, "--type", cons_type_s, (void *)NULL);
 
 out:
-    libxl__free_all(&gc);
+    GC_FREE;
     return ERROR_FAIL;
 }
 
 int libxl_primary_console_exec(libxl_ctx *ctx, uint32_t domid_vm)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     uint32_t stubdomid = libxl_get_stubdom_id(ctx, domid_vm);
     int rc;
     if (stubdomid)
         rc = libxl_console_exec(ctx, stubdomid,
                                 STUBDOM_CONSOLE_SERIAL, LIBXL_CONSOLE_TYPE_PV);
     else {
-        switch (libxl__domain_type(&gc, domid_vm)) {
+        switch (libxl__domain_type(gc, domid_vm)) {
         case LIBXL_DOMAIN_TYPE_HVM:
             rc = libxl_console_exec(ctx, domid_vm, 0, LIBXL_CONSOLE_TYPE_SERIAL);
             break;
@@ -844,13 +844,13 @@ int libxl_primary_console_exec(libxl_ctx *ctx, uint32_t domid_vm)
             abort();
         }
     }
-    libxl__free_all(&gc);
+    GC_FREE;
     return rc;
 }
 
 int libxl_vncviewer_exec(libxl_ctx *ctx, uint32_t domid, int autopass)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     const char *vnc_port;
     const char *vnc_listen = NULL, *vnc_pass = NULL;
     int port = 0, autopass_fd = -1;
@@ -861,19 +861,19 @@ int libxl_vncviewer_exec(libxl_ctx *ctx, uint32_t domid, int autopass)
         NULL,
     };
 
-    vnc_port = libxl__xs_read(&gc, XBT_NULL,
-                            libxl__sprintf(&gc,
+    vnc_port = libxl__xs_read(gc, XBT_NULL,
+                            libxl__sprintf(gc,
                             "/local/domain/%d/console/vnc-port", domid));
     if ( vnc_port )
         port = atoi(vnc_port) - 5900;
 
-    vnc_listen = libxl__xs_read(&gc, XBT_NULL,
-                                libxl__sprintf(&gc,
+    vnc_listen = libxl__xs_read(gc, XBT_NULL,
+                                libxl__sprintf(gc,
                             "/local/domain/%d/console/vnc-listen", domid));
 
     if ( autopass )
-        vnc_pass = libxl__xs_read(&gc, XBT_NULL,
-                                  libxl__sprintf(&gc,
+        vnc_pass = libxl__xs_read(gc, XBT_NULL,
+                                  libxl__sprintf(gc,
                             "/local/domain/%d/console/vnc-pass", domid));
 
     if ( NULL == vnc_listen )
@@ -882,7 +882,7 @@ int libxl_vncviewer_exec(libxl_ctx *ctx, uint32_t domid, int autopass)
     if ( (vnc_bin = getenv("VNCVIEWER")) )
         args[0] = vnc_bin;
 
-    args[1] = libxl__sprintf(&gc, "%s:%d", vnc_listen, port);
+    args[1] = libxl__sprintf(gc, "%s:%d", vnc_listen, port);
 
     if ( vnc_pass ) {
         char tmpname[] = "/tmp/vncautopass.XXXXXX";
@@ -917,7 +917,7 @@ int libxl_vncviewer_exec(libxl_ctx *ctx, uint32_t domid, int autopass)
     abort();
 
  x_fail:
-    libxl__free_all(&gc);
+    GC_FREE;
     return ERROR_FAIL;
 }
 
@@ -971,17 +971,17 @@ static int libxl__device_from_disk(libxl__gc *gc, uint32_t domid,
 
 int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *disk)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     flexarray_t *front;
     flexarray_t *back;
     char *dev;
     libxl__device device;
     int major, minor, rc;
 
-    rc = libxl__device_disk_set_backend(&gc, disk);
+    rc = libxl__device_disk_set_backend(gc, disk);
     if (rc) goto out;
 
-    rc = libxl__device_disk_set_backend(&gc, disk);
+    rc = libxl__device_disk_set_backend(gc, disk);
     if (rc) goto out;
 
     front = flexarray_make(16, 1);
@@ -1002,7 +1002,7 @@ int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *dis
         goto out_free;
     }
 
-    rc = libxl__device_from_disk(&gc, domid, disk, &device);
+    rc = libxl__device_from_disk(gc, domid, disk, &device);
     if (rc != 0) {
         LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Invalid or unsupported"
                " virtual disk identifier %s", disk->vdev);
@@ -1015,7 +1015,7 @@ int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *dis
     do_backend_phy:
             libxl__device_physdisk_major_minor(dev, &major, &minor);
             flexarray_append(back, "physical-device");
-            flexarray_append(back, libxl__sprintf(&gc, "%x:%x", major, minor));
+            flexarray_append(back, libxl__sprintf(gc, "%x:%x", major, minor));
 
             flexarray_append(back, "params");
             flexarray_append(back, dev);
@@ -1023,13 +1023,13 @@ int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *dis
             assert(device.backend_kind == LIBXL__DEVICE_KIND_VBD);
             break;
         case LIBXL_DISK_BACKEND_TAP:
-            dev = libxl__blktap_devpath(&gc, disk->pdev_path, disk->format);
+            dev = libxl__blktap_devpath(gc, disk->pdev_path, disk->format);
             if (!dev) {
                 rc = ERROR_FAIL;
                 goto out_free;
             }
             flexarray_append(back, "tapdisk-params");
-            flexarray_append(back, libxl__sprintf(&gc, "%s:%s",
+            flexarray_append(back, libxl__sprintf(gc, "%s:%s",
                 libxl__device_disk_string_of_format(disk->format),
                 disk->pdev_path));
 
@@ -1037,7 +1037,7 @@ int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *dis
             goto do_backend_phy;
         case LIBXL_DISK_BACKEND_QDISK:
             flexarray_append(back, "params");
-            flexarray_append(back, libxl__sprintf(&gc, "%s:%s",
+            flexarray_append(back, libxl__sprintf(gc, "%s:%s",
                           libxl__device_disk_string_of_format(disk->format), disk->pdev_path));
             assert(device.backend_kind == LIBXL__DEVICE_KIND_QDISK);
             break;
@@ -1048,15 +1048,15 @@ int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *dis
     }
 
     flexarray_append(back, "frontend-id");
-    flexarray_append(back, libxl__sprintf(&gc, "%d", domid));
+    flexarray_append(back, libxl__sprintf(gc, "%d", domid));
     flexarray_append(back, "online");
     flexarray_append(back, "1");
     flexarray_append(back, "removable");
-    flexarray_append(back, libxl__sprintf(&gc, "%d", (disk->removable) ? 1 : 0));
+    flexarray_append(back, libxl__sprintf(gc, "%d", (disk->removable) ? 1 : 0));
     flexarray_append(back, "bootable");
-    flexarray_append(back, libxl__sprintf(&gc, "%d", 1));
+    flexarray_append(back, libxl__sprintf(gc, "%d", 1));
     flexarray_append(back, "state");
-    flexarray_append(back, libxl__sprintf(&gc, "%d", 1));
+    flexarray_append(back, libxl__sprintf(gc, "%d", 1));
     flexarray_append(back, "dev");
     flexarray_append(back, disk->vdev);
     flexarray_append(back, "type");
@@ -1067,17 +1067,17 @@ int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *dis
     flexarray_append(back, disk->is_cdrom ? "cdrom" : "disk");
 
     flexarray_append(front, "backend-id");
-    flexarray_append(front, libxl__sprintf(&gc, "%d", disk->backend_domid));
+    flexarray_append(front, libxl__sprintf(gc, "%d", disk->backend_domid));
     flexarray_append(front, "state");
-    flexarray_append(front, libxl__sprintf(&gc, "%d", 1));
+    flexarray_append(front, libxl__sprintf(gc, "%d", 1));
     flexarray_append(front, "virtual-device");
-    flexarray_append(front, libxl__sprintf(&gc, "%d", device.devid));
+    flexarray_append(front, libxl__sprintf(gc, "%d", device.devid));
     flexarray_append(front, "device-type");
     flexarray_append(front, disk->is_cdrom ? "cdrom" : "disk");
 
-    libxl__device_generic_add(&gc, &device,
-                             libxl__xs_kvs_of_flexarray(&gc, back, back->count),
-                             libxl__xs_kvs_of_flexarray(&gc, front, front->count));
+    libxl__device_generic_add(gc, &device,
+                             libxl__xs_kvs_of_flexarray(gc, back, back->count),
+                             libxl__xs_kvs_of_flexarray(gc, front, front->count));
 
     rc = 0;
 
@@ -1085,39 +1085,39 @@ out_free:
     flexarray_free(back);
     flexarray_free(front);
 out:
-    libxl__free_all(&gc);
+    GC_FREE;
     return rc;
 }
 
 int libxl_device_disk_remove(libxl_ctx *ctx, uint32_t domid,
                              libxl_device_disk *disk)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     libxl__device device;
     int rc;
 
-    rc = libxl__device_from_disk(&gc, domid, disk, &device);
+    rc = libxl__device_from_disk(gc, domid, disk, &device);
     if (rc != 0) goto out;
 
-    rc = libxl__device_remove(&gc, &device, 1);
+    rc = libxl__device_remove(gc, &device, 1);
 out:
-    libxl__free_all(&gc);
+    GC_FREE;
     return rc;
 }
 
 int libxl_device_disk_destroy(libxl_ctx *ctx, uint32_t domid,
                               libxl_device_disk *disk)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     libxl__device device;
     int rc;
 
-    rc = libxl__device_from_disk(&gc, domid, disk, &device);
+    rc = libxl__device_from_disk(gc, domid, disk, &device);
     if (rc != 0) goto out;
 
-    rc = libxl__device_destroy(&gc, &device);
+    rc = libxl__device_destroy(gc, &device);
 out:
-    libxl__free_all(&gc);
+    GC_FREE;
     return rc;
 }
 
@@ -1169,27 +1169,27 @@ static void libxl__device_disk_from_xs_be(libxl__gc *gc,
 int libxl_devid_to_device_disk(libxl_ctx *ctx, uint32_t domid,
                                int devid, libxl_device_disk *disk)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     char *dompath, *path;
     int rc = ERROR_FAIL;
 
     libxl_device_disk_init(ctx, disk);
 
-    dompath = libxl__xs_get_dompath(&gc, domid);
+    dompath = libxl__xs_get_dompath(gc, domid);
     if (!dompath) {
         goto out;
     }
-    path = libxl__xs_read(&gc, XBT_NULL,
-                          libxl__sprintf(&gc, "%s/device/vbd/%d/backend",
+    path = libxl__xs_read(gc, XBT_NULL,
+                          libxl__sprintf(gc, "%s/device/vbd/%d/backend",
                                          dompath, devid));
     if (!path)
         goto out;
 
-    libxl__device_disk_from_xs_be(&gc, path, disk);
+    libxl__device_disk_from_xs_be(gc, path, disk);
 
     rc = 0;
 out:
-    libxl__free_all(&gc);
+    GC_FREE;
     return rc;
 }
 
@@ -1229,22 +1229,22 @@ static int libxl__append_disk_list_of_type(libxl__gc *gc,
 
 libxl_device_disk *libxl_device_disk_list(libxl_ctx *ctx, uint32_t domid, int *num)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     libxl_device_disk *disks = NULL;
     int rc;
 
     *num = 0;
 
-    rc = libxl__append_disk_list_of_type(&gc, domid, "vbd", &disks, num);
+    rc = libxl__append_disk_list_of_type(gc, domid, "vbd", &disks, num);
     if (rc) goto out_err;
 
-    rc = libxl__append_disk_list_of_type(&gc, domid, "tap", &disks, num);
+    rc = libxl__append_disk_list_of_type(gc, domid, "tap", &disks, num);
     if (rc) goto out_err;
 
-    rc = libxl__append_disk_list_of_type(&gc, domid, "qdisk", &disks, num);
+    rc = libxl__append_disk_list_of_type(gc, domid, "qdisk", &disks, num);
     if (rc) goto out_err;
 
-    libxl__free_all(&gc);
+    GC_FREE;
     return disks;
 
 out_err:
@@ -1260,35 +1260,35 @@ out_err:
 int libxl_device_disk_getinfo(libxl_ctx *ctx, uint32_t domid,
                               libxl_device_disk *disk, libxl_diskinfo *diskinfo)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     char *dompath, *diskpath;
     char *val;
 
-    dompath = libxl__xs_get_dompath(&gc, domid);
+    dompath = libxl__xs_get_dompath(gc, domid);
     diskinfo->devid = libxl__device_disk_dev_number(disk->vdev, NULL, NULL);
 
     /* tap devices entries in xenstore are written as vbd devices. */
-    diskpath = libxl__sprintf(&gc, "%s/device/vbd/%d", dompath, diskinfo->devid);
+    diskpath = libxl__sprintf(gc, "%s/device/vbd/%d", dompath, diskinfo->devid);
     diskinfo->backend = xs_read(ctx->xsh, XBT_NULL,
-                                libxl__sprintf(&gc, "%s/backend", diskpath), NULL);
+                                libxl__sprintf(gc, "%s/backend", diskpath), NULL);
     if (!diskinfo->backend) {
-        libxl__free_all(&gc);
+        GC_FREE;
         return ERROR_FAIL;
     }
-    val = libxl__xs_read(&gc, XBT_NULL, libxl__sprintf(&gc, "%s/backend-id", diskpath));
+    val = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/backend-id", diskpath));
     diskinfo->backend_id = val ? strtoul(val, NULL, 10) : -1;
-    val = libxl__xs_read(&gc, XBT_NULL, libxl__sprintf(&gc, "%s/state", diskpath));
+    val = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/state", diskpath));
     diskinfo->state = val ? strtoul(val, NULL, 10) : -1;
-    val = libxl__xs_read(&gc, XBT_NULL, libxl__sprintf(&gc, "%s/event-channel", diskpath));
+    val = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/event-channel", diskpath));
     diskinfo->evtch = val ? strtoul(val, NULL, 10) : -1;
-    val = libxl__xs_read(&gc, XBT_NULL, libxl__sprintf(&gc, "%s/ring-ref", diskpath));
+    val = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/ring-ref", diskpath));
     diskinfo->rref = val ? strtoul(val, NULL, 10) : -1;
     diskinfo->frontend = xs_read(ctx->xsh, XBT_NULL,
-                                 libxl__sprintf(&gc, "%s/frontend", diskinfo->backend), NULL);
-    val = libxl__xs_read(&gc, XBT_NULL, libxl__sprintf(&gc, "%s/frontend-id", diskinfo->backend));
+                                 libxl__sprintf(gc, "%s/frontend", diskinfo->backend), NULL);
+    val = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/frontend-id", diskinfo->backend));
     diskinfo->frontend_id = val ? strtoul(val, NULL, 10) : -1;
 
-    libxl__free_all(&gc);
+    GC_FREE;
     return 0;
 }
 
@@ -1332,12 +1332,12 @@ out:
 
 char * libxl_device_disk_local_attach(libxl_ctx *ctx, libxl_device_disk *disk)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     char *dev = NULL;
     char *ret = NULL;
     int rc;
 
-    rc = libxl__device_disk_set_backend(&gc, disk);
+    rc = libxl__device_disk_set_backend(gc, disk);
     if (rc) goto out;
 
     switch (disk->backend) {
@@ -1356,7 +1356,7 @@ char * libxl_device_disk_local_attach(libxl_ctx *ctx, libxl_device_disk *disk)
                 dev = disk->pdev_path;
                 break;
             case LIBXL_DISK_FORMAT_VHD:
-                dev = libxl__blktap_devpath(&gc, disk->pdev_path,
+                dev = libxl__blktap_devpath(gc, disk->pdev_path,
                                             disk->format);
                 break;
             case LIBXL_DISK_FORMAT_QCOW:
@@ -1387,7 +1387,7 @@ char * libxl_device_disk_local_attach(libxl_ctx *ctx, libxl_device_disk *disk)
  out:
     if (dev != NULL)
         ret = strdup(dev);
-    libxl__free_all(&gc);
+    GC_FREE;
     return ret;
 }
 
@@ -1449,7 +1449,7 @@ static int libxl__device_from_nic(libxl__gc *gc, uint32_t domid,
 
 int libxl_device_nic_add(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     flexarray_t *front;
     flexarray_t *back;
     libxl__device device;
@@ -1468,59 +1468,59 @@ int libxl_device_nic_add(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic)
     }
 
     if (nic->devid == -1) {
-        if (!(dompath = libxl__xs_get_dompath(&gc, domid))) {
+        if (!(dompath = libxl__xs_get_dompath(gc, domid))) {
             rc = ERROR_FAIL;
             goto out_free;
         }
-        if (!(l = libxl__xs_directory(&gc, XBT_NULL,
-                                     libxl__sprintf(&gc, "%s/device/vif", dompath), &nb))) {
+        if (!(l = libxl__xs_directory(gc, XBT_NULL,
+                                     libxl__sprintf(gc, "%s/device/vif", dompath), &nb))) {
             nic->devid = 0;
         } else {
             nic->devid = strtoul(l[nb - 1], NULL, 10) + 1;
         }
     }
 
-    rc = libxl__device_from_nic(&gc, domid, nic, &device);
+    rc = libxl__device_from_nic(gc, domid, nic, &device);
     if ( rc != 0 ) goto out_free;
 
     flexarray_append(back, "frontend-id");
-    flexarray_append(back, libxl__sprintf(&gc, "%d", domid));
+    flexarray_append(back, libxl__sprintf(gc, "%d", domid));
     flexarray_append(back, "online");
     flexarray_append(back, "1");
     flexarray_append(back, "state");
-    flexarray_append(back, libxl__sprintf(&gc, "%d", 1));
+    flexarray_append(back, libxl__sprintf(gc, "%d", 1));
     if (nic->script) {
         flexarray_append(back, "script");
         flexarray_append(back, nic->script[0]=='/' ? nic->script
-                         : libxl__sprintf(&gc, "%s/%s",
+                         : libxl__sprintf(gc, "%s/%s",
                                           libxl_xen_script_dir_path(),
                                           nic->script));
     }
     flexarray_append(back, "mac");
-    flexarray_append(back,libxl__sprintf(&gc,
+    flexarray_append(back,libxl__sprintf(gc,
                                     LIBXL_MAC_FMT, LIBXL_MAC_BYTES(nic->mac)));
     if (nic->ip) {
         flexarray_append(back, "ip");
-        flexarray_append(back, libxl__strdup(&gc, nic->ip));
+        flexarray_append(back, libxl__strdup(gc, nic->ip));
     }
 
     flexarray_append(back, "bridge");
-    flexarray_append(back, libxl__strdup(&gc, nic->bridge));
+    flexarray_append(back, libxl__strdup(gc, nic->bridge));
     flexarray_append(back, "handle");
-    flexarray_append(back, libxl__sprintf(&gc, "%d", nic->devid));
+    flexarray_append(back, libxl__sprintf(gc, "%d", nic->devid));
 
     flexarray_append(front, "backend-id");
-    flexarray_append(front, libxl__sprintf(&gc, "%d", nic->backend_domid));
+    flexarray_append(front, libxl__sprintf(gc, "%d", nic->backend_domid));
     flexarray_append(front, "state");
-    flexarray_append(front, libxl__sprintf(&gc, "%d", 1));
+    flexarray_append(front, libxl__sprintf(gc, "%d", 1));
     flexarray_append(front, "handle");
-    flexarray_append(front, libxl__sprintf(&gc, "%d", nic->devid));
+    flexarray_append(front, libxl__sprintf(gc, "%d", nic->devid));
     flexarray_append(front, "mac");
-    flexarray_append(front, libxl__sprintf(&gc,
+    flexarray_append(front, libxl__sprintf(gc,
                                     LIBXL_MAC_FMT, LIBXL_MAC_BYTES(nic->mac)));
-    libxl__device_generic_add(&gc, &device,
-                             libxl__xs_kvs_of_flexarray(&gc, back, back->count),
-                             libxl__xs_kvs_of_flexarray(&gc, front, front->count));
+    libxl__device_generic_add(gc, &device,
+                             libxl__xs_kvs_of_flexarray(gc, back, back->count),
+                             libxl__xs_kvs_of_flexarray(gc, front, front->count));
 
     /* FIXME: wait for plug */
     rc = 0;
@@ -1528,39 +1528,39 @@ out_free:
     flexarray_free(back);
     flexarray_free(front);
 out:
-    libxl__free_all(&gc);
+    GC_FREE;
     return rc;
 }
 
 int libxl_device_nic_remove(libxl_ctx *ctx, uint32_t domid,
                             libxl_device_nic *nic)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     libxl__device device;
     int rc;
 
-    rc = libxl__device_from_nic(&gc, domid, nic, &device);
+    rc = libxl__device_from_nic(gc, domid, nic, &device);
     if (rc != 0) goto out;
 
-    rc = libxl__device_remove(&gc, &device, 1);
+    rc = libxl__device_remove(gc, &device, 1);
 out:
-    libxl__free_all(&gc);
+    GC_FREE;
     return rc;
 }
 
 int libxl_device_nic_destroy(libxl_ctx *ctx, uint32_t domid,
                                   libxl_device_nic *nic)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     libxl__device device;
     int rc;
 
-    rc = libxl__device_from_nic(&gc, domid, nic, &device);
+    rc = libxl__device_from_nic(gc, domid, nic, &device);
     if (rc != 0) goto out;
 
-    rc = libxl__device_destroy(&gc, &device);
+    rc = libxl__device_destroy(gc, &device);
 out:
-    libxl__free_all(&gc);
+    GC_FREE;
     return rc;
 }
 
@@ -1608,26 +1608,26 @@ static void libxl__device_nic_from_xs_be(libxl__gc *gc,
 int libxl_devid_to_device_nic(libxl_ctx *ctx, uint32_t domid,
                               int devid, libxl_device_nic *nic)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     char *dompath, *path;
     int rc = ERROR_FAIL;
 
     memset(nic, 0, sizeof (libxl_device_nic));
-    dompath = libxl__xs_get_dompath(&gc, domid);
+    dompath = libxl__xs_get_dompath(gc, domid);
     if (!dompath)
         goto out;
 
-    path = libxl__xs_read(&gc, XBT_NULL,
-                          libxl__sprintf(&gc, "%s/device/vif/%d/backend",
+    path = libxl__xs_read(gc, XBT_NULL,
+                          libxl__sprintf(gc, "%s/device/vif/%d/backend",
                                          dompath, devid));
     if (!path)
         goto out;
 
-    libxl__device_nic_from_xs_be(&gc, path, nic);
+    libxl__device_nic_from_xs_be(gc, path, nic);
 
     rc = 0;
 out:
-    libxl__free_all(&gc);
+    GC_FREE;
     return rc;
 }
 
@@ -1666,16 +1666,16 @@ static int libxl__append_nic_list_of_type(libxl__gc *gc,
 
 libxl_device_nic *libxl_device_nic_list(libxl_ctx *ctx, uint32_t domid, int *num)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     libxl_device_nic *nics = NULL;
     int rc;
 
     *num = 0;
 
-    rc = libxl__append_nic_list_of_type(&gc, domid, "vif", &nics, num);
+    rc = libxl__append_nic_list_of_type(gc, domid, "vif", &nics, num);
     if (rc) goto out_err;
 
-    libxl__free_all(&gc);
+    GC_FREE;
     return nics;
 
 out_err:
@@ -1691,36 +1691,36 @@ out_err:
 int libxl_device_nic_getinfo(libxl_ctx *ctx, uint32_t domid,
                               libxl_device_nic *nic, libxl_nicinfo *nicinfo)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     char *dompath, *nicpath;
     char *val;
 
-    dompath = libxl__xs_get_dompath(&gc, domid);
+    dompath = libxl__xs_get_dompath(gc, domid);
     nicinfo->devid = nic->devid;
 
-    nicpath = libxl__sprintf(&gc, "%s/device/vif/%d", dompath, nicinfo->devid);
+    nicpath = libxl__sprintf(gc, "%s/device/vif/%d", dompath, nicinfo->devid);
     nicinfo->backend = xs_read(ctx->xsh, XBT_NULL,
-                                libxl__sprintf(&gc, "%s/backend", nicpath), NULL);
+                                libxl__sprintf(gc, "%s/backend", nicpath), NULL);
     if (!nicinfo->backend) {
-        libxl__free_all(&gc);
+        GC_FREE;
         return ERROR_FAIL;
     }
-    val = libxl__xs_read(&gc, XBT_NULL, libxl__sprintf(&gc, "%s/backend-id", nicpath));
+    val = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/backend-id", nicpath));
     nicinfo->backend_id = val ? strtoul(val, NULL, 10) : -1;
-    val = libxl__xs_read(&gc, XBT_NULL, libxl__sprintf(&gc, "%s/state", nicpath));
+    val = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/state", nicpath));
     nicinfo->state = val ? strtoul(val, NULL, 10) : -1;
-    val = libxl__xs_read(&gc, XBT_NULL, libxl__sprintf(&gc, "%s/event-channel", nicpath));
+    val = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/event-channel", nicpath));
     nicinfo->evtch = val ? strtoul(val, NULL, 10) : -1;
-    val = libxl__xs_read(&gc, XBT_NULL, libxl__sprintf(&gc, "%s/tx-ring-ref", nicpath));
+    val = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/tx-ring-ref", nicpath));
     nicinfo->rref_tx = val ? strtoul(val, NULL, 10) : -1;
-    val = libxl__xs_read(&gc, XBT_NULL, libxl__sprintf(&gc, "%s/rx-ring-ref", nicpath));
+    val = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/rx-ring-ref", nicpath));
     nicinfo->rref_rx = val ? strtoul(val, NULL, 10) : -1;
     nicinfo->frontend = xs_read(ctx->xsh, XBT_NULL,
-                                 libxl__sprintf(&gc, "%s/frontend", nicinfo->backend), NULL);
-    val = libxl__xs_read(&gc, XBT_NULL, libxl__sprintf(&gc, "%s/frontend-id", nicinfo->backend));
+                                 libxl__sprintf(gc, "%s/frontend", nicinfo->backend), NULL);
+    val = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/frontend-id", nicinfo->backend));
     nicinfo->frontend_id = val ? strtoul(val, NULL, 10) : -1;
 
-    libxl__free_all(&gc);
+    GC_FREE;
     return 0;
 }
 
@@ -1826,7 +1826,7 @@ static int libxl__device_from_vkb(libxl__gc *gc, uint32_t domid,
 
 int libxl_device_vkb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vkb *vkb)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     flexarray_t *front;
     flexarray_t *back;
     libxl__device device;
@@ -1843,64 +1843,64 @@ int libxl_device_vkb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vkb *vkb)
         goto out_free;
     }
 
-    rc = libxl__device_from_vkb(&gc, domid, vkb, &device);
+    rc = libxl__device_from_vkb(gc, domid, vkb, &device);
     if (rc != 0) goto out_free;
 
     flexarray_append(back, "frontend-id");
-    flexarray_append(back, libxl__sprintf(&gc, "%d", domid));
+    flexarray_append(back, libxl__sprintf(gc, "%d", domid));
     flexarray_append(back, "online");
     flexarray_append(back, "1");
     flexarray_append(back, "state");
-    flexarray_append(back, libxl__sprintf(&gc, "%d", 1));
+    flexarray_append(back, libxl__sprintf(gc, "%d", 1));
     flexarray_append(back, "domain");
-    flexarray_append(back, libxl__domid_to_name(&gc, domid));
+    flexarray_append(back, libxl__domid_to_name(gc, domid));
 
     flexarray_append(front, "backend-id");
-    flexarray_append(front, libxl__sprintf(&gc, "%d", vkb->backend_domid));
+    flexarray_append(front, libxl__sprintf(gc, "%d", vkb->backend_domid));
     flexarray_append(front, "state");
-    flexarray_append(front, libxl__sprintf(&gc, "%d", 1));
+    flexarray_append(front, libxl__sprintf(gc, "%d", 1));
 
-    libxl__device_generic_add(&gc, &device,
-                             libxl__xs_kvs_of_flexarray(&gc, back, back->count),
-                             libxl__xs_kvs_of_flexarray(&gc, front, front->count));
+    libxl__device_generic_add(gc, &device,
+                             libxl__xs_kvs_of_flexarray(gc, back, back->count),
+                             libxl__xs_kvs_of_flexarray(gc, front, front->count));
     rc = 0;
 out_free:
     flexarray_free(back);
     flexarray_free(front);
 out:
-    libxl__free_all(&gc);
+    GC_FREE;
     return rc;
 }
 
 int libxl_device_vkb_remove(libxl_ctx *ctx, uint32_t domid,
                             libxl_device_vkb *vkb)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     libxl__device device;
     int rc;
 
-    rc = libxl__device_from_vkb(&gc, domid, vkb, &device);
+    rc = libxl__device_from_vkb(gc, domid, vkb, &device);
     if (rc != 0) goto out;
 
-    rc = libxl__device_remove(&gc, &device, 1);
+    rc = libxl__device_remove(gc, &device, 1);
 out:
-    libxl__free_all(&gc);
+    GC_FREE;
     return rc;
 }
 
 int libxl_device_vkb_destroy(libxl_ctx *ctx, uint32_t domid,
                                   libxl_device_vkb *vkb)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     libxl__device device;
     int rc;
 
-    rc = libxl__device_from_vkb(&gc, domid, vkb, &device);
+    rc = libxl__device_from_vkb(gc, domid, vkb, &device);
     if (rc != 0) goto out;
 
-    rc = libxl__device_destroy(&gc, &device);
+    rc = libxl__device_destroy(gc, &device);
 out:
-    libxl__free_all(&gc);
+    GC_FREE;
     return rc;
 }
 
@@ -1936,7 +1936,7 @@ static int libxl__device_from_vfb(libxl__gc *gc, uint32_t domid,
 
 int libxl_device_vfb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vfb *vfb)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     flexarray_t *front;
     flexarray_t *back;
     libxl__device device;
@@ -1953,20 +1953,20 @@ int libxl_device_vfb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vfb *vfb)
         goto out_free;
     }
 
-    rc = libxl__device_from_vfb(&gc, domid, vfb, &device);
+    rc = libxl__device_from_vfb(gc, domid, vfb, &device);
     if (rc != 0) goto out_free;
 
-    flexarray_append_pair(back, "frontend-id", libxl__sprintf(&gc, "%d", domid));
+    flexarray_append_pair(back, "frontend-id", libxl__sprintf(gc, "%d", domid));
     flexarray_append_pair(back, "online", "1");
-    flexarray_append_pair(back, "state", libxl__sprintf(&gc, "%d", 1));
-    flexarray_append_pair(back, "domain", libxl__domid_to_name(&gc, domid));
-    flexarray_append_pair(back, "vnc", libxl__sprintf(&gc, "%d", vfb->vnc));
+    flexarray_append_pair(back, "state", libxl__sprintf(gc, "%d", 1));
+    flexarray_append_pair(back, "domain", libxl__domid_to_name(gc, domid));
+    flexarray_append_pair(back, "vnc", libxl__sprintf(gc, "%d", vfb->vnc));
     flexarray_append_pair(back, "vnclisten", vfb->vnclisten);
     flexarray_append_pair(back, "vncpasswd", vfb->vncpasswd);
-    flexarray_append_pair(back, "vncdisplay", libxl__sprintf(&gc, "%d", vfb->vncdisplay));
-    flexarray_append_pair(back, "vncunused", libxl__sprintf(&gc, "%d", vfb->vncunused));
-    flexarray_append_pair(back, "sdl", libxl__sprintf(&gc, "%d", vfb->sdl));
-    flexarray_append_pair(back, "opengl", libxl__sprintf(&gc, "%d", vfb->opengl));
+    flexarray_append_pair(back, "vncdisplay", libxl__sprintf(gc, "%d", vfb->vncdisplay));
+    flexarray_append_pair(back, "vncunused", libxl__sprintf(gc, "%d", vfb->vncunused));
+    flexarray_append_pair(back, "sdl", libxl__sprintf(gc, "%d", vfb->sdl));
+    flexarray_append_pair(back, "opengl", libxl__sprintf(gc, "%d", vfb->opengl));
     if (vfb->xauthority) {
         flexarray_append_pair(back, "xauthority", vfb->xauthority);
     }
@@ -1974,50 +1974,50 @@ int libxl_device_vfb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vfb *vfb)
         flexarray_append_pair(back, "display", vfb->display);
     }
 
-    flexarray_append_pair(front, "backend-id", libxl__sprintf(&gc, "%d", vfb->backend_domid));
-    flexarray_append_pair(front, "state", libxl__sprintf(&gc, "%d", 1));
+    flexarray_append_pair(front, "backend-id", libxl__sprintf(gc, "%d", vfb->backend_domid));
+    flexarray_append_pair(front, "state", libxl__sprintf(gc, "%d", 1));
 
-    libxl__device_generic_add(&gc, &device,
-                             libxl__xs_kvs_of_flexarray(&gc, back, back->count),
-                             libxl__xs_kvs_of_flexarray(&gc, front, front->count));
+    libxl__device_generic_add(gc, &device,
+                             libxl__xs_kvs_of_flexarray(gc, back, back->count),
+                             libxl__xs_kvs_of_flexarray(gc, front, front->count));
     rc = 0;
 out_free:
     flexarray_free(front);
     flexarray_free(back);
 out:
-    libxl__free_all(&gc);
+    GC_FREE;
     return rc;
 }
 
 int libxl_device_vfb_remove(libxl_ctx *ctx, uint32_t domid,
                             libxl_device_vfb *vfb)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     libxl__device device;
     int rc;
 
-    rc = libxl__device_from_vfb(&gc, domid, vfb, &device);
+    rc = libxl__device_from_vfb(gc, domid, vfb, &device);
     if (rc != 0) goto out;
 
-    rc = libxl__device_remove(&gc, &device, 1);
+    rc = libxl__device_remove(gc, &device, 1);
 out:
-    libxl__free_all(&gc);
+    GC_FREE;
     return rc;
 }
 
 int libxl_device_vfb_destroy(libxl_ctx *ctx, uint32_t domid,
                                   libxl_device_vfb *vfb)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     libxl__device device;
     int rc;
 
-    rc = libxl__device_from_vfb(&gc, domid, vfb, &device);
+    rc = libxl__device_from_vfb(gc, domid, vfb, &device);
     if (rc != 0) goto out;
 
-    rc = libxl__device_destroy(&gc, &device);
+    rc = libxl__device_destroy(gc, &device);
 out:
-    libxl__free_all(&gc);
+    GC_FREE;
     return rc;
 }
 
@@ -2025,13 +2025,13 @@ out:
 
 int libxl_domain_setmaxmem(libxl_ctx *ctx, uint32_t domid, uint32_t max_memkb)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     char *mem, *endptr;
     uint32_t memorykb;
-    char *dompath = libxl__xs_get_dompath(&gc, domid);
+    char *dompath = libxl__xs_get_dompath(gc, domid);
     int rc = 1;
 
-    mem = libxl__xs_read(&gc, XBT_NULL, libxl__sprintf(&gc, "%s/memory/target", dompath));
+    mem = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/memory/target", dompath));
     if (!mem) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "cannot get memory info from %s/memory/target\n", dompath);
         goto out;
@@ -2056,7 +2056,7 @@ int libxl_domain_setmaxmem(libxl_ctx *ctx, uint32_t domid, uint32_t max_memkb)
 
     rc = 0;
 out:
-    libxl__free_all(&gc);
+    GC_FREE;
     return rc;
 }
 
@@ -2164,12 +2164,12 @@ retry:
 int libxl_set_memory_target(libxl_ctx *ctx, uint32_t domid,
         int32_t target_memkb, int relative, int enforce)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     int rc = 1, abort = 0;
     uint32_t memorykb = 0, videoram = 0;
     uint32_t current_target_memkb = 0, new_target_memkb = 0;
     char *memmax, *endptr, *videoram_s = NULL, *target = NULL;
-    char *dompath = libxl__xs_get_dompath(&gc, domid);
+    char *dompath = libxl__xs_get_dompath(gc, domid);
     xc_domaininfo_t info;
     libxl_dominfo ptr;
     char *uuid;
@@ -2178,11 +2178,11 @@ int libxl_set_memory_target(libxl_ctx *ctx, uint32_t domid,
 retry_transaction:
     t = xs_transaction_start(ctx->xsh);
 
-    target = libxl__xs_read(&gc, t, libxl__sprintf(&gc,
+    target = libxl__xs_read(gc, t, libxl__sprintf(gc,
                 "%s/memory/target", dompath));
     if (!target && !domid) {
         xs_transaction_end(ctx->xsh, t, 1);
-        rc = libxl__fill_dom0_memory_info(&gc, &current_target_memkb);
+        rc = libxl__fill_dom0_memory_info(gc, &current_target_memkb);
         if (rc < 0) {
             abort = 1;
             goto out;
@@ -2204,7 +2204,7 @@ retry_transaction:
             goto out;
         }
     }
-    memmax = libxl__xs_read(&gc, t, libxl__sprintf(&gc,
+    memmax = libxl__xs_read(gc, t, libxl__sprintf(gc,
                 "%s/memory/static-max", dompath));
     if (!memmax) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
@@ -2244,7 +2244,7 @@ retry_transaction:
         abort = 1;
         goto out;
     }
-    videoram_s = libxl__xs_read(&gc, t, libxl__sprintf(&gc,
+    videoram_s = libxl__xs_read(gc, t, libxl__sprintf(gc,
                 "%s/memory/videoram", dompath));
     videoram = videoram_s ? atoi(videoram_s) : 0;
 
@@ -2273,7 +2273,7 @@ retry_transaction:
         goto out;
     }
 
-    libxl__xs_write(&gc, t, libxl__sprintf(&gc, "%s/memory/target",
+    libxl__xs_write(gc, t, libxl__sprintf(gc, "%s/memory/target",
                 dompath), "%"PRIu32, new_target_memkb);
     rc = xc_domain_getinfolist(ctx->xch, domid, 1, &info);
     if (rc != 1 || info.domain != domid) {
@@ -2281,8 +2281,8 @@ retry_transaction:
         goto out;
     }
     xcinfo2xlinfo(&info, &ptr);
-    uuid = libxl__uuid2string(&gc, ptr.uuid);
-    libxl__xs_write(&gc, t, libxl__sprintf(&gc, "/vm/%s/memory", uuid),
+    uuid = libxl__uuid2string(gc, ptr.uuid);
+    libxl__xs_write(gc, t, libxl__sprintf(gc, "/vm/%s/memory", uuid),
             "%"PRIu32, new_target_memkb / 1024);
 
 out:
@@ -2290,22 +2290,22 @@ out:
         if (errno == EAGAIN)
             goto retry_transaction;
 
-    libxl__free_all(&gc);
+    GC_FREE;
     return rc;
 }
 
 int libxl_get_memory_target(libxl_ctx *ctx, uint32_t domid, uint32_t *out_target)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     int rc = 1;
     char *target = NULL, *endptr = NULL;
-    char *dompath = libxl__xs_get_dompath(&gc, domid);
+    char *dompath = libxl__xs_get_dompath(gc, domid);
     uint32_t target_memkb;
 
-    target = libxl__xs_read(&gc, XBT_NULL, libxl__sprintf(&gc,
+    target = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc,
                 "%s/memory/target", dompath));
     if (!target && !domid) {
-        rc = libxl__fill_dom0_memory_info(&gc, &target_memkb);
+        rc = libxl__fill_dom0_memory_info(gc, &target_memkb);
         if (rc < 0)
             goto out;
     } else if (!target) {
@@ -2326,14 +2326,14 @@ int libxl_get_memory_target(libxl_ctx *ctx, uint32_t domid, uint32_t *out_target
     rc = 0;
 
 out:
-    libxl__free_all(&gc);
+    GC_FREE;
     return rc;
 }
 
 int libxl_domain_need_memory(libxl_ctx *ctx, libxl_domain_build_info *b_info,
         libxl_device_model_info *dm_info, uint32_t *need_memkb)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     int rc = ERROR_INVAL;
     *need_memkb = b_info->target_memkb;
     switch (b_info->type) {
@@ -2352,7 +2352,7 @@ int libxl_domain_need_memory(libxl_ctx *ctx, libxl_domain_build_info *b_info,
         *need_memkb += (2 * 1024) - (*need_memkb % (2 * 1024));
     rc = 0;
 out:
-    libxl__free_all(&gc);
+    GC_FREE;
     return rc;
 
 }
@@ -2362,12 +2362,12 @@ int libxl_get_free_memory(libxl_ctx *ctx, uint32_t *memkb)
     int rc = 0;
     libxl_physinfo info;
     uint32_t freemem_slack;
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
 
     rc = libxl_get_physinfo(ctx, &info);
     if (rc < 0)
         goto out;
-    rc = libxl__get_free_memory_slack(&gc, &freemem_slack);
+    rc = libxl__get_free_memory_slack(gc, &freemem_slack);
     if (rc < 0)
         goto out;
 
@@ -2377,7 +2377,7 @@ int libxl_get_free_memory(libxl_ctx *ctx, uint32_t *memkb)
         *memkb = 0;
 
 out:
-    libxl__free_all(&gc);
+    GC_FREE;
     return rc;
 }
 
@@ -2387,9 +2387,9 @@ int libxl_wait_for_free_memory(libxl_ctx *ctx, uint32_t domid, uint32_t
     int rc = 0;
     libxl_physinfo info;
     uint32_t freemem_slack;
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
 
-    rc = libxl__get_free_memory_slack(&gc, &freemem_slack);
+    rc = libxl__get_free_memory_slack(gc, &freemem_slack);
     if (rc < 0)
         goto out;
     while (wait_secs > 0) {
@@ -2406,7 +2406,7 @@ int libxl_wait_for_free_memory(libxl_ctx *ctx, uint32_t domid, uint32_t
     rc = ERROR_NOMEM;
 
 out:
-    libxl__free_all(&gc);
+    GC_FREE;
     return rc;
 }
 
@@ -2632,7 +2632,7 @@ int libxl_set_vcpuaffinity(libxl_ctx *ctx, uint32_t domid, uint32_t vcpuid,
 
 int libxl_set_vcpuonline(libxl_ctx *ctx, uint32_t domid, libxl_cpumap *cpumap)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     libxl_dominfo info;
     char *dompath;
     xs_transaction_t t;
@@ -2642,14 +2642,14 @@ int libxl_set_vcpuonline(libxl_ctx *ctx, uint32_t domid, libxl_cpumap *cpumap)
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "getting domain info list");
         goto out;
     }
-    if (!(dompath = libxl__xs_get_dompath(&gc, domid)))
+    if (!(dompath = libxl__xs_get_dompath(gc, domid)))
         goto out;
 
 retry_transaction:
     t = xs_transaction_start(ctx->xsh);
     for (i = 0; i <= info.vcpu_max_id; i++)
-        libxl__xs_write(&gc, t,
-                       libxl__sprintf(&gc, "%s/cpu/%u/availability", dompath, i),
+        libxl__xs_write(gc, t,
+                       libxl__sprintf(gc, "%s/cpu/%u/availability", dompath, i),
                        "%s", libxl_cpumap_test(cpumap, i) ? "online" : "offline");
     if (!xs_transaction_end(ctx->xsh, t, 0)) {
         if (errno == EAGAIN)
@@ -2657,7 +2657,7 @@ retry_transaction:
     } else
         rc = 0;
 out:
-    libxl__free_all(&gc);
+    GC_FREE;
     return rc;
 }
 
@@ -2777,12 +2777,12 @@ int libxl_send_trigger(libxl_ctx *ctx, uint32_t domid, char *trigger_name, uint3
 
 int libxl_send_sysrq(libxl_ctx *ctx, uint32_t domid, char sysrq)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
-    char *dompath = libxl__xs_get_dompath(&gc, domid);
+    GC_INIT(ctx);
+    char *dompath = libxl__xs_get_dompath(gc, domid);
 
-    libxl__xs_write(&gc, XBT_NULL, libxl__sprintf(&gc, "%s/control/sysrq", dompath), "%c", sysrq);
+    libxl__xs_write(gc, XBT_NULL, libxl__sprintf(gc, "%s/control/sysrq", dompath), "%c", sysrq);
 
-    libxl__free_all(&gc);
+    GC_FREE;
     return 0;
 }
 
@@ -2869,15 +2869,15 @@ void libxl_xen_console_read_finish(libxl_ctx *ctx,
 
 uint32_t libxl_vm_get_start_time(libxl_ctx *ctx, uint32_t domid)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
-    char *dompath = libxl__xs_get_dompath(&gc, domid);
+    GC_INIT(ctx);
+    char *dompath = libxl__xs_get_dompath(gc, domid);
     char *vm_path, *start_time;
     uint32_t ret;
 
     vm_path = libxl__xs_read(
-        &gc, XBT_NULL, libxl__sprintf(&gc, "%s/vm", dompath));
+        gc, XBT_NULL, libxl__sprintf(gc, "%s/vm", dompath));
     start_time = libxl__xs_read(
-        &gc, XBT_NULL, libxl__sprintf(&gc, "%s/start_time", vm_path));
+        gc, XBT_NULL, libxl__sprintf(gc, "%s/start_time", vm_path));
     if (start_time == NULL) {
         LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, -1,
                         "Can't get start time of domain '%d'", domid);
@@ -2885,7 +2885,7 @@ uint32_t libxl_vm_get_start_time(libxl_ctx *ctx, uint32_t domid)
     }else{
         ret = strtoul(start_time, NULL, 10);
     }
-    libxl__free_all(&gc);
+    GC_FREE;
     return ret;
 }
 
@@ -3038,15 +3038,15 @@ int libxl_create_cpupool(libxl_ctx *ctx, const char *name, int schedid,
                          libxl_cpumap cpumap, libxl_uuid *uuid,
                          uint32_t *poolid)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     int rc;
     int i;
     xs_transaction_t t;
     char *uuid_string;
 
-    uuid_string = libxl__uuid2string(&gc, *uuid);
+    uuid_string = libxl__uuid2string(gc, *uuid);
     if (!uuid_string) {
-        libxl__free_all(&gc);
+        GC_FREE;
         return ERROR_NOMEM;
     }
 
@@ -3054,7 +3054,7 @@ int libxl_create_cpupool(libxl_ctx *ctx, const char *name, int schedid,
     if (rc) {
         LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, rc,
            "Could not create cpupool");
-        libxl__free_all(&gc);
+        GC_FREE;
         return ERROR_FAIL;
     }
 
@@ -3065,7 +3065,7 @@ int libxl_create_cpupool(libxl_ctx *ctx, const char *name, int schedid,
                 LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, rc,
                     "Error moving cpu to cpupool");
                 libxl_cpupool_destroy(ctx, *poolid);
-                libxl__free_all(&gc);
+                GC_FREE;
                 return ERROR_FAIL;
             }
         }
@@ -3073,16 +3073,16 @@ int libxl_create_cpupool(libxl_ctx *ctx, const char *name, int schedid,
     for (;;) {
         t = xs_transaction_start(ctx->xsh);
 
-        xs_mkdir(ctx->xsh, t, libxl__sprintf(&gc, "/local/pool/%d", *poolid));
-        libxl__xs_write(&gc, t,
-                        libxl__sprintf(&gc, "/local/pool/%d/uuid", *poolid),
+        xs_mkdir(ctx->xsh, t, libxl__sprintf(gc, "/local/pool/%d", *poolid));
+        libxl__xs_write(gc, t,
+                        libxl__sprintf(gc, "/local/pool/%d/uuid", *poolid),
                         "%s", uuid_string);
-        libxl__xs_write(&gc, t,
-                        libxl__sprintf(&gc, "/local/pool/%d/name", *poolid),
+        libxl__xs_write(gc, t,
+                        libxl__sprintf(gc, "/local/pool/%d/name", *poolid),
                         "%s", name);
 
         if (xs_transaction_end(ctx->xsh, t, 0) || (errno != EAGAIN)) {
-            libxl__free_all(&gc);
+            GC_FREE;
             return 0;
         }
     }
@@ -3090,7 +3090,7 @@ int libxl_create_cpupool(libxl_ctx *ctx, const char *name, int schedid,
 
 int libxl_cpupool_destroy(libxl_ctx *ctx, uint32_t poolid)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     int rc, i;
     xc_cpupoolinfo_t *info;
     xs_transaction_t t;
@@ -3098,7 +3098,7 @@ int libxl_cpupool_destroy(libxl_ctx *ctx, uint32_t poolid)
 
     info = xc_cpupool_getinfo(ctx->xch, poolid);
     if (info == NULL) {
-        libxl__free_all(&gc);
+        GC_FREE;
         return ERROR_NOMEM;
     }
 
@@ -3132,7 +3132,7 @@ int libxl_cpupool_destroy(libxl_ctx *ctx, uint32_t poolid)
     for (;;) {
         t = xs_transaction_start(ctx->xsh);
 
-        xs_rm(ctx->xsh, XBT_NULL, libxl__sprintf(&gc, "/local/pool/%d", poolid));
+        xs_rm(ctx->xsh, XBT_NULL, libxl__sprintf(gc, "/local/pool/%d", poolid));
 
         if (xs_transaction_end(ctx->xsh, t, 0) || (errno != EAGAIN))
             break;
@@ -3144,21 +3144,21 @@ out1:
     libxl_cpumap_dispose(&cpumap);
 out:
     xc_cpupool_infofree(ctx->xch, info);
-    libxl__free_all(&gc);
+    GC_FREE;
 
     return rc;
 }
 
 int libxl_cpupool_rename(libxl_ctx *ctx, const char *name, uint32_t poolid)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     xs_transaction_t t;
     xc_cpupoolinfo_t *info;
     int rc;
 
     info = xc_cpupool_getinfo(ctx->xch, poolid);
     if (info == NULL) {
-        libxl__free_all(&gc);
+        GC_FREE;
         return ERROR_NOMEM;
     }
 
@@ -3171,8 +3171,8 @@ int libxl_cpupool_rename(libxl_ctx *ctx, const char *name, uint32_t poolid)
     for (;;) {
         t = xs_transaction_start(ctx->xsh);
 
-        libxl__xs_write(&gc, t,
-                        libxl__sprintf(&gc, "/local/pool/%d/name", poolid),
+        libxl__xs_write(gc, t,
+                        libxl__sprintf(gc, "/local/pool/%d/name", poolid),
                         "%s", name);
 
         if (xs_transaction_end(ctx->xsh, t, 0))
@@ -3187,7 +3187,7 @@ int libxl_cpupool_rename(libxl_ctx *ctx, const char *name, uint32_t poolid)
 
 out:
     xc_cpupool_infofree(ctx->xch, info);
-    libxl__free_all(&gc);
+    GC_FREE;
 
     return rc;
 }
@@ -3294,16 +3294,16 @@ out:
 
 int libxl_cpupool_movedomain(libxl_ctx *ctx, uint32_t poolid, uint32_t domid)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     int rc;
     char *dom_path;
     char *vm_path;
     char *poolname;
     xs_transaction_t t;
 
-    dom_path = libxl__xs_get_dompath(&gc, domid);
+    dom_path = libxl__xs_get_dompath(gc, domid);
     if (!dom_path) {
-        libxl__free_all(&gc);
+        GC_FREE;
         return ERROR_FAIL;
     }
 
@@ -3311,26 +3311,26 @@ int libxl_cpupool_movedomain(libxl_ctx *ctx, uint32_t poolid, uint32_t domid)
     if (rc) {
         LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, rc,
             "Error moving domain to cpupool");
-        libxl__free_all(&gc);
+        GC_FREE;
         return ERROR_FAIL;
     }
 
     for (;;) {
         t = xs_transaction_start(ctx->xsh);
 
-        poolname = libxl__cpupoolid_to_name(&gc, poolid);
-        vm_path = libxl__xs_read(&gc, XBT_NULL, libxl__sprintf(&gc, "%s/vm", dom_path));
+        poolname = libxl__cpupoolid_to_name(gc, poolid);
+        vm_path = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/vm", dom_path));
         if (!vm_path)
             break;
 
-        libxl__xs_write(&gc, t, libxl__sprintf(&gc, "%s/pool_name", vm_path),
+        libxl__xs_write(gc, t, libxl__sprintf(gc, "%s/pool_name", vm_path),
                         "%s", poolname);
 
         if (xs_transaction_end(ctx->xsh, t, 0) || (errno != EAGAIN))
             break;
     }
 
-    libxl__free_all(&gc);
+    GC_FREE;
     return 0;
 }
 
diff --git a/tools/libxl/libxl_bootloader.c b/tools/libxl/libxl_bootloader.c
index b8399a1..ce83b8e 100644
--- a/tools/libxl/libxl_bootloader.c
+++ b/tools/libxl/libxl_bootloader.c
@@ -328,7 +328,7 @@ int libxl_run_bootloader(libxl_ctx *ctx,
                          libxl_device_disk *disk,
                          uint32_t domid)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     int ret, rc = 0;
     char *fifo = NULL;
     char *diskpath = NULL;
@@ -388,7 +388,7 @@ int libxl_run_bootloader(libxl_ctx *ctx,
         goto out_close;
     }
 
-    args = make_bootloader_args(&gc, info, domid, fifo, diskpath);
+    args = make_bootloader_args(gc, info, domid, fifo, diskpath);
     if (args == NULL) {
         rc = ERROR_NOMEM;
         goto out_close;
@@ -411,8 +411,8 @@ int libxl_run_bootloader(libxl_ctx *ctx,
         goto out_close;
     }
 
-    dom_console_xs_path = libxl__sprintf(&gc, "%s/console/tty", libxl__xs_get_dompath(&gc, domid));
-    libxl__xs_write(&gc, XBT_NULL, dom_console_xs_path, "%s", dom_console_slave_tty_path);
+    dom_console_xs_path = libxl__sprintf(gc, "%s/console/tty", libxl__xs_get_dompath(gc, domid));
+    libxl__xs_write(gc, XBT_NULL, dom_console_xs_path, "%s", dom_console_slave_tty_path);
 
     pid = fork_exec_bootloader(&bootloader_fd, info->u.pv.bootloader, args);
     if (pid < 0) {
@@ -435,7 +435,7 @@ int libxl_run_bootloader(libxl_ctx *ctx,
 
     fcntl(fifo_fd, F_SETFL, O_NDELAY);
 
-    blout = bootloader_interact(&gc, xenconsoled_fd, bootloader_fd, fifo_fd);
+    blout = bootloader_interact(gc, xenconsoled_fd, bootloader_fd, fifo_fd);
     if (blout == NULL) {
         goto out_close;
     }
@@ -445,7 +445,7 @@ int libxl_run_bootloader(libxl_ctx *ctx,
         goto out_close;
     }
 
-    parse_bootloader_result(&gc, info, blout);
+    parse_bootloader_result(gc, info, blout);
 
     rc = 0;
 out_close:
@@ -472,7 +472,7 @@ out_close:
     free(args);
 
 out:
-    libxl__free_all(&gc);
+    GC_FREE;
     return rc;
 }
 
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index ccb56c7..69f10fe 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -670,20 +670,20 @@ error_out:
 int libxl_domain_create_new(libxl_ctx *ctx, libxl_domain_config *d_config,
                             libxl_console_ready cb, void *priv, uint32_t *domid)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     int rc;
-    rc = do_domain_create(&gc, d_config, cb, priv, domid, -1);
-    libxl__free_all(&gc);
+    rc = do_domain_create(gc, d_config, cb, priv, domid, -1);
+    GC_FREE;
     return rc;
 }
 
 int libxl_domain_create_restore(libxl_ctx *ctx, libxl_domain_config *d_config,
                                 libxl_console_ready cb, void *priv, uint32_t *domid, int restore_fd)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     int rc;
-    rc = do_domain_create(&gc, d_config, cb, priv, domid, restore_fd);
-    libxl__free_all(&gc);
+    rc = do_domain_create(gc, d_config, cb, priv, domid, restore_fd);
+    GC_FREE;
     return rc;
 }
 
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 96098de..b1ff967 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -730,7 +730,7 @@ int libxl_userdata_store(libxl_ctx *ctx, uint32_t domid,
                               const char *userdata_userid,
                               const uint8_t *data, int datalen)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     const char *filename;
     const char *newfilename;
     int e, rc;
@@ -738,18 +738,18 @@ int libxl_userdata_store(libxl_ctx *ctx, uint32_t domid,
     FILE *f = NULL;
     size_t rs;
 
-    filename = userdata_path(&gc, domid, userdata_userid, "d");
+    filename = userdata_path(gc, domid, userdata_userid, "d");
     if (!filename) {
         rc = ERROR_NOMEM;
         goto out;
     }
 
     if (!datalen) {
-        rc = userdata_delete(&gc, filename);
+        rc = userdata_delete(gc, filename);
         goto out;
     }
 
-    newfilename = userdata_path(&gc, domid, userdata_userid, "n");
+    newfilename = userdata_path(gc, domid, userdata_userid, "n");
     if (!newfilename) {
         rc = ERROR_NOMEM;
         goto out;
@@ -791,7 +791,7 @@ err:
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "cannot write %s for %s",
                  newfilename, filename);
 out:
-    libxl__free_all(&gc);
+    GC_FREE;
     return rc;
 }
 
@@ -799,13 +799,13 @@ int libxl_userdata_retrieve(libxl_ctx *ctx, uint32_t domid,
                                  const char *userdata_userid,
                                  uint8_t **data_r, int *datalen_r)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     const char *filename;
     int e, rc;
     int datalen = 0;
     void *data = 0;
 
-    filename = userdata_path(&gc, domid, userdata_userid, "d");
+    filename = userdata_path(gc, domid, userdata_userid, "d");
     if (!filename) {
         rc = ERROR_NOMEM;
         goto out;
@@ -827,7 +827,7 @@ int libxl_userdata_retrieve(libxl_ctx *ctx, uint32_t domid,
     if (datalen_r) *datalen_r = datalen;
     rc = 0;
 out:
-    libxl__free_all(&gc);
+    GC_FREE;
     return rc;
 }
 
diff --git a/tools/libxl/libxl_pci.c b/tools/libxl/libxl_pci.c
index 63c3050..120c239 100644
--- a/tools/libxl/libxl_pci.c
+++ b/tools/libxl/libxl_pci.c
@@ -483,7 +483,7 @@ static int is_assigned(libxl_device_pci *assigned, int num_assigned,
 
 libxl_device_pci *libxl_device_pci_list_assignable(libxl_ctx *ctx, int *num)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     libxl_device_pci *pcidevs = NULL, *new, *assigned;
     struct dirent *de;
     DIR *dir;
@@ -491,7 +491,7 @@ libxl_device_pci *libxl_device_pci_list_assignable(libxl_ctx *ctx, int *num)
 
     *num = 0;
 
-    rc = get_all_assigned_devices(&gc, &assigned, &num_assigned);
+    rc = get_all_assigned_devices(gc, &assigned, &num_assigned);
     if ( rc )
         goto out;
 
@@ -528,7 +528,7 @@ libxl_device_pci *libxl_device_pci_list_assignable(libxl_ctx *ctx, int *num)
 out_closedir:
     closedir(dir);
 out:
-    libxl__free_all(&gc);
+    GC_FREE;
     return pcidevs;
 }
 
@@ -782,10 +782,10 @@ static int libxl__device_pci_reset(libxl__gc *gc, unsigned int domain, unsigned
 
 int libxl_device_pci_add(libxl_ctx *ctx, uint32_t domid, libxl_device_pci *pcidev)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     int rc;
-    rc = libxl__device_pci_add(&gc, domid, pcidev, 0);
-    libxl__free_all(&gc);
+    rc = libxl__device_pci_add(gc, domid, pcidev, 0);
+    GC_FREE;
     return rc;
 }
 
@@ -1057,24 +1057,24 @@ out:
 
 int libxl_device_pci_remove(libxl_ctx *ctx, uint32_t domid, libxl_device_pci *pcidev)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     int rc;
 
-    rc = libxl__device_pci_remove_common(&gc, domid, pcidev, 0);
+    rc = libxl__device_pci_remove_common(gc, domid, pcidev, 0);
 
-    libxl__free_all(&gc);
+    GC_FREE;
     return rc;
 }
 
 int libxl_device_pci_destroy(libxl_ctx *ctx, uint32_t domid,
                                   libxl_device_pci *pcidev)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     int rc;
 
-    rc = libxl__device_pci_remove_common(&gc, domid, pcidev, 1);
+    rc = libxl__device_pci_remove_common(gc, domid, pcidev, 1);
 
-    libxl__free_all(&gc);
+    GC_FREE;
     return rc;
 }
 
@@ -1115,15 +1115,15 @@ static void libxl__device_pci_from_xs_be(libxl__gc *gc,
 
 libxl_device_pci *libxl_device_pci_list(libxl_ctx *ctx, uint32_t domid, int *num)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     char *be_path, *num_devs;
     int n, i;
     libxl_device_pci *pcidevs = NULL;
 
     *num = 0;
 
-    be_path = libxl__sprintf(&gc, "%s/backend/pci/%d/0", libxl__xs_get_dompath(&gc, 0), domid);
-    num_devs = libxl__xs_read(&gc, XBT_NULL, libxl__sprintf(&gc, "%s/num_devs", be_path));
+    be_path = libxl__sprintf(gc, "%s/backend/pci/%d/0", libxl__xs_get_dompath(gc, 0), domid);
+    num_devs = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/num_devs", be_path));
     if (!num_devs)
         goto out;
 
@@ -1131,11 +1131,11 @@ libxl_device_pci *libxl_device_pci_list(libxl_ctx *ctx, uint32_t domid, int *num
     pcidevs = calloc(n, sizeof(libxl_device_pci));
 
     for (i = 0; i < n; i++)
-        libxl__device_pci_from_xs_be(&gc, be_path, pcidevs + i, i);
+        libxl__device_pci_from_xs_be(gc, be_path, pcidevs + i, i);
 
     *num = n;
 out:
-    libxl__free_all(&gc);
+    GC_FREE;
     return pcidevs;
 }
 
diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
index c7696d7..60af98c 100644
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/libxl/libxl_qmp.c
@@ -94,7 +94,7 @@ static int store_serial_port_info(libxl__qmp_handler *qmp,
                                   const char *chardev,
                                   int port)
 {
-    libxl__gc gc = LIBXL_INIT_GC(qmp->ctx);
+    GC_INIT(qmp->ctx);
     char *path = NULL;
     int ret = 0;
 
@@ -102,12 +102,12 @@ static int store_serial_port_info(libxl__qmp_handler *qmp,
         return 0;
     }
 
-    path = libxl__xs_get_dompath(&gc, qmp->domid);
-    path = libxl__sprintf(&gc, "%s/serial/%d/tty", path, port);
+    path = libxl__xs_get_dompath(gc, qmp->domid);
+    path = libxl__sprintf(gc, "%s/serial/%d/tty", path, port);
 
-    ret = libxl__xs_write(&gc, XBT_NULL, path, "%s", chardev + 4);
+    ret = libxl__xs_write(gc, XBT_NULL, path, "%s", chardev + 4);
 
-    libxl__free_all(&gc);
+    GC_FREE;
     return ret;
 }
 
@@ -521,7 +521,7 @@ static int qmp_synchronous_send(libxl__qmp_handler *qmp, const char *cmd,
 {
     int id = 0;
     int ret = 0;
-    libxl__gc gc = LIBXL_INIT_GC(qmp->ctx);
+    GC_INIT(qmp->ctx);
     qmp_request_context context = { .rc = 0 };
 
     id = qmp_send(qmp, cmd, args, callback, opaque, &context);
@@ -531,7 +531,7 @@ static int qmp_synchronous_send(libxl__qmp_handler *qmp, const char *cmd,
     qmp->wait_for_id = id;
 
     while (qmp->wait_for_id == id) {
-        if ((ret = qmp_next(&gc, qmp)) < 0) {
+        if ((ret = qmp_next(gc, qmp)) < 0) {
             break;
         }
     }
@@ -540,7 +540,7 @@ static int qmp_synchronous_send(libxl__qmp_handler *qmp, const char *cmd,
         ret = context.rc;
     }
 
-    libxl__free_all(&gc);
+    GC_FREE;
 
     return ret;
 }
@@ -559,15 +559,15 @@ libxl__qmp_handler *libxl__qmp_initialize(libxl_ctx *ctx, uint32_t domid)
     int ret = 0;
     libxl__qmp_handler *qmp = NULL;
     char *qmp_socket;
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
 
     qmp = qmp_init_handler(ctx, domid);
 
-    qmp_socket = libxl__sprintf(&gc, "%s/qmp-libxl-%d",
+    qmp_socket = libxl__sprintf(gc, "%s/qmp-libxl-%d",
                                 libxl_run_dir_path(), domid);
     if ((ret = qmp_open(qmp, qmp_socket, QMP_SOCKET_CONNECT_TIMEOUT)) < 0) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "Connection error");
-        libxl__free_all(&gc);
+        GC_FREE;
         qmp_free_handler(qmp);
         return NULL;
     }
@@ -576,12 +576,12 @@ libxl__qmp_handler *libxl__qmp_initialize(libxl_ctx *ctx, uint32_t domid)
 
     /* Wait for the response to qmp_capabilities */
     while (!qmp->connected) {
-        if ((ret = qmp_next(&gc, qmp)) < 0) {
+        if ((ret = qmp_next(gc, qmp)) < 0) {
             break;
         }
     }
 
-    libxl__free_all(&gc);
+    GC_FREE;
     if (!qmp->connected) {
         LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Failed to connect to QMP");
         libxl__qmp_close(qmp);
@@ -626,9 +626,9 @@ static int pci_add_callback(libxl__qmp_handler *qmp,
 {
     libxl_device_pci *pcidev = opaque;
     const libxl__json_object *bus = NULL;
-    libxl__gc gc = LIBXL_INIT_GC(qmp->ctx);
+    GC_INIT(qmp->ctx);
     int i, j, rc = -1;
-    char *asked_id = libxl__sprintf(&gc, PCI_PT_QDEV_ID,
+    char *asked_id = libxl__sprintf(gc, PCI_PT_QDEV_ID,
                                     pcidev->bus, pcidev->dev, pcidev->func);
 
     for (i = 0; (bus = libxl__json_array_get(response, i)); i++) {
@@ -665,7 +665,7 @@ static int pci_add_callback(libxl__qmp_handler *qmp,
 
 
 out:
-    libxl__free_all(&gc);
+    GC_FREE;
     return rc;
 }
 
diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
index f1f2a6d..d36c737 100644
--- a/tools/libxl/libxl_utils.c
+++ b/tools/libxl/libxl_utils.c
@@ -186,29 +186,29 @@ char *libxl_schedid_to_name(libxl_ctx *ctx, int schedid)
 
 int libxl_get_stubdom_id(libxl_ctx *ctx, int guest_domid)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     char * stubdom_id_s;
     int ret;
 
-    stubdom_id_s = libxl__xs_read(&gc, XBT_NULL,
-                                 libxl__sprintf(&gc, "%s/image/device-model-domid",
-                                               libxl__xs_get_dompath(&gc, guest_domid)));
+    stubdom_id_s = libxl__xs_read(gc, XBT_NULL,
+                                 libxl__sprintf(gc, "%s/image/device-model-domid",
+                                               libxl__xs_get_dompath(gc, guest_domid)));
     if (stubdom_id_s)
         ret = atoi(stubdom_id_s);
     else
         ret = 0;
-    libxl__free_all(&gc);
+    GC_FREE;
     return ret;
 }
 
 int libxl_is_stubdom(libxl_ctx *ctx, uint32_t domid, uint32_t *target_domid)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     char *target, *endptr;
     uint32_t value;
     int ret = 0;
 
-    target = libxl__xs_read(&gc, XBT_NULL, libxl__sprintf(&gc, "%s/target", libxl__xs_get_dompath(&gc, domid)));
+    target = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/target", libxl__xs_get_dompath(gc, domid)));
     if (!target)
         goto out;
     value = strtol(target, &endptr, 10);
@@ -218,7 +218,7 @@ int libxl_is_stubdom(libxl_ctx *ctx, uint32_t domid, uint32_t *target_domid)
         *target_domid = value;
     ret = 1;
 out:
-    libxl__free_all(&gc);
+    GC_FREE;
     return ret;
 }
 
@@ -240,27 +240,27 @@ static int logrename(libxl__gc *gc, const char *old, const char *new)
 
 int libxl_create_logfile(libxl_ctx *ctx, char *name, char **full_name)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     struct stat stat_buf;
     char *logfile, *logfile_new;
     int i, rc;
 
-    logfile = libxl__sprintf(&gc, "/var/log/xen/%s.log", name);
+    logfile = libxl__sprintf(gc, "/var/log/xen/%s.log", name);
     if (stat(logfile, &stat_buf) == 0) {
         /* file exists, rotate */
-        logfile = libxl__sprintf(&gc, "/var/log/xen/%s.log.10", name);
+        logfile = libxl__sprintf(gc, "/var/log/xen/%s.log.10", name);
         unlink(logfile);
         for (i = 9; i > 0; i--) {
-            logfile = libxl__sprintf(&gc, "/var/log/xen/%s.log.%d", name, i);
-            logfile_new = libxl__sprintf(&gc, "/var/log/xen/%s.log.%d", name, i + 1);
-            rc = logrename(&gc, logfile, logfile_new);
+            logfile = libxl__sprintf(gc, "/var/log/xen/%s.log.%d", name, i);
+            logfile_new = libxl__sprintf(gc, "/var/log/xen/%s.log.%d", name, i + 1);
+            rc = logrename(gc, logfile, logfile_new);
             if (rc)
                 goto out;
         }
-        logfile = libxl__sprintf(&gc, "/var/log/xen/%s.log", name);
-        logfile_new = libxl__sprintf(&gc, "/var/log/xen/%s.log.1", name);
+        logfile = libxl__sprintf(gc, "/var/log/xen/%s.log", name);
+        logfile_new = libxl__sprintf(gc, "/var/log/xen/%s.log.1", name);
 
-        rc = logrename(&gc, logfile, logfile_new);
+        rc = logrename(gc, logfile, logfile_new);
         if (rc)
             goto out;
     } else {
@@ -272,7 +272,7 @@ int libxl_create_logfile(libxl_ctx *ctx, char *name, char **full_name)
     *full_name = strdup(logfile);
     rc = 0;
 out:
-    libxl__free_all(&gc);
+    GC_FREE;
     return rc;
 }
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 18:55:50 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 18: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.xensource.com>)
	id 1RZ5bZ-0001BM-LQ; Fri, 09 Dec 2011 18:55:33 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RZ5bX-0001Ac-F1
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 18:55:31 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1323456879!6616386!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI2MQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21201 invoked from network); 9 Dec 2011 18:54:41 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 18:54:41 -0000
X-IronPort-AV: E=Sophos;i="4.71,327,1320624000"; 
   d="scan'208";a="9392193"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 18:54:41 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 18:54:41 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RZ5aj-0002dl-3c; Fri, 09 Dec 2011 18:54:41 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RZ5aj-0003zu-2r;
	Fri, 09 Dec 2011 18:54:41 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Fri, 9 Dec 2011 18:54:20 +0000
Message-ID: <1323456877-15315-2-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1323456877-15315-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1323456877-15315-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 01/18] libxl: Make libxl__xs_* more const-correct
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Paths and values which are not modified by these functions should be
declared as "const char *" not "char *".

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl_internal.h |    9 +++++----
 tools/libxl/libxl_xshelp.c   |    9 +++++----
 2 files changed, 10 insertions(+), 8 deletions(-)

diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 84da6b1..bfc74c9 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -172,18 +172,19 @@ _hidden char *libxl__dirname(libxl__gc *gc, const char *s);
 _hidden char **libxl__xs_kvs_of_flexarray(libxl__gc *gc, flexarray_t *array, int length);
 
 _hidden int libxl__xs_writev(libxl__gc *gc, xs_transaction_t t,
-                    char *dir, char **kvs);
+                             const char *dir, char **kvs);
 _hidden int libxl__xs_write(libxl__gc *gc, xs_transaction_t t,
-                   char *path, const char *fmt, ...) PRINTF_ATTRIBUTE(4, 5);
+               const char *path, const char *fmt, ...) PRINTF_ATTRIBUTE(4, 5);
    /* Each fn returns 0 on success.
     * On error: returns -1, sets errno (no logging) */
 
 _hidden char *libxl__xs_get_dompath(libxl__gc *gc, uint32_t domid);
    /* On error: logs, returns NULL, sets errno. */
 
-_hidden char *libxl__xs_read(libxl__gc *gc, xs_transaction_t t, char *path);
+_hidden char *libxl__xs_read(libxl__gc *gc, xs_transaction_t t,
+                             const char *path);
 _hidden char **libxl__xs_directory(libxl__gc *gc, xs_transaction_t t,
-                                   char *path, unsigned int *nb);
+                                   const char *path, unsigned int *nb);
    /* On error: returns NULL, sets errno (no logging) */
 
 _hidden char *libxl__xs_libxl_path(libxl__gc *gc, uint32_t domid);
diff --git a/tools/libxl/libxl_xshelp.c b/tools/libxl/libxl_xshelp.c
index 4b09be3..bc4e7e4 100644
--- a/tools/libxl/libxl_xshelp.c
+++ b/tools/libxl/libxl_xshelp.c
@@ -49,7 +49,7 @@ char **libxl__xs_kvs_of_flexarray(libxl__gc *gc, flexarray_t *array, int length)
 }
 
 int libxl__xs_writev(libxl__gc *gc, xs_transaction_t t,
-                    char *dir, char *kvs[])
+                     const char *dir, char *kvs[])
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
     char *path;
@@ -69,7 +69,7 @@ int libxl__xs_writev(libxl__gc *gc, xs_transaction_t t,
 }
 
 int libxl__xs_write(libxl__gc *gc, xs_transaction_t t,
-                   char *path, const char *fmt, ...)
+                    const char *path, const char *fmt, ...)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
     char *s;
@@ -87,7 +87,7 @@ int libxl__xs_write(libxl__gc *gc, xs_transaction_t t,
     return 0;
 }
 
-char * libxl__xs_read(libxl__gc *gc, xs_transaction_t t, char *path)
+char * libxl__xs_read(libxl__gc *gc, xs_transaction_t t, const char *path)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
     char *ptr;
@@ -113,7 +113,8 @@ char *libxl__xs_get_dompath(libxl__gc *gc, uint32_t domid)
     return s;
 }
 
-char **libxl__xs_directory(libxl__gc *gc, xs_transaction_t t, char *path, unsigned int *nb)
+char **libxl__xs_directory(libxl__gc *gc, xs_transaction_t t,
+                           const char *path, unsigned int *nb)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
     char **ret = NULL;
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 18:55:50 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 18: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.xensource.com>)
	id 1RZ5bf-0001F1-CO; Fri, 09 Dec 2011 18:55:39 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RZ5bd-0001BB-MX
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 18:55:37 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1323456879!6616386!12
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI2MQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21440 invoked from network); 9 Dec 2011 18:54:47 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 18:54:47 -0000
X-IronPort-AV: E=Sophos;i="4.71,327,1320624000"; 
   d="scan'208";a="9392203"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 18:54:47 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 18:54:47 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RZ5ap-0002eF-Aq; Fri, 09 Dec 2011 18:54:47 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RZ5ap-00040d-A4;
	Fri, 09 Dec 2011 18:54:47 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Fri, 9 Dec 2011 18:54:30 +0000
Message-ID: <1323456877-15315-12-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1323456877-15315-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1323456877-15315-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 11/18] libxl: make libxl__free_all idempotent
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl_internal.c |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c
index ae28cb0..a2e5820 100644
--- a/tools/libxl/libxl_internal.c
+++ b/tools/libxl/libxl_internal.c
@@ -72,6 +72,8 @@ void libxl__free_all(libxl__gc *gc)
         free(ptr);
     }
     free(gc->alloc_ptrs);
+    gc->alloc_ptrs = 0;
+    gc->alloc_maxsize = 0;
 }
 
 void *libxl__zalloc(libxl__gc *gc, int bytes)
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 18:55:51 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 18: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.xensource.com>)
	id 1RZ5be-0001EK-R0; Fri, 09 Dec 2011 18:55:38 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RZ5bd-0001B8-3v
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 18:55:37 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1323456879!6616386!11
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI2MQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21409 invoked from network); 9 Dec 2011 18:54:47 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 18:54:47 -0000
X-IronPort-AV: E=Sophos;i="4.71,327,1320624000"; 
   d="scan'208";a="9392202"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 18:54:47 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 18:54:47 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RZ5ao-0002eC-Rc; Fri, 09 Dec 2011 18:54:46 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RZ5ao-00040Z-Qr;
	Fri, 09 Dec 2011 18:54:46 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Fri, 9 Dec 2011 18:54:29 +0000
Message-ID: <1323456877-15315-11-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1323456877-15315-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1323456877-15315-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 10/18] libxl: make libxl__[v]log const-correct
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl_internal.c |    4 ++--
 tools/libxl/libxl_internal.h |    4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c
index d767ce3..ae28cb0 100644
--- a/tools/libxl/libxl_internal.c
+++ b/tools/libxl/libxl_internal.c
@@ -179,7 +179,7 @@ char *libxl__dirname(libxl__gc *gc, const char *s)
 
 void libxl__logv(libxl_ctx *ctx, xentoollog_level msglevel, int errnoval,
              const char *file, int line, const char *func,
-             char *fmt, va_list ap)
+             const char *fmt, va_list ap)
 {
     char *enomem = "[out of memory formatting log message]";
     char *base = NULL;
@@ -206,7 +206,7 @@ void libxl__logv(libxl_ctx *ctx, xentoollog_level msglevel, int errnoval,
 
 void libxl__log(libxl_ctx *ctx, xentoollog_level msglevel, int errnoval,
             const char *file, int line, const char *func,
-            char *fmt, ...)
+            const char *fmt, ...)
 {
     va_list ap;
     va_start(ap, fmt);
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 41de6fd..1d1dc35 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -80,13 +80,13 @@
 _hidden void libxl__logv(libxl_ctx *ctx, xentoollog_level msglevel, int errnoval,
              const char *file /* may be 0 */, int line /* ignored if !file */,
              const char *func /* may be 0 */,
-             char *fmt, va_list al)
+             const char *fmt, va_list al)
      __attribute__((format(printf,7,0)));
 
 _hidden void libxl__log(libxl_ctx *ctx, xentoollog_level msglevel, int errnoval,
             const char *file /* may be 0 */, int line /* ignored if !file */,
             const char *func /* may be 0 */,
-            char *fmt, ...)
+            const char *fmt, ...)
      __attribute__((format(printf,7,8)));
 
      /* these functions preserve errno (saving and restoring) */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 18:55:51 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 18: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.xensource.com>)
	id 1RZ5bf-0001FK-OJ; Fri, 09 Dec 2011 18:55:39 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RZ5bd-0001BD-W0
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 18:55:38 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1323456879!6616386!13
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI2MQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21457 invoked from network); 9 Dec 2011 18:54:48 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 18:54:48 -0000
X-IronPort-AV: E=Sophos;i="4.71,327,1320624000"; 
   d="scan'208";a="9392204"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 18:54:48 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 18:54:48 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RZ5ap-0002eI-RL; Fri, 09 Dec 2011 18:54:47 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RZ5ap-00040h-Qa;
	Fri, 09 Dec 2011 18:54:47 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Fri, 9 Dec 2011 18:54:31 +0000
Message-ID: <1323456877-15315-13-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1323456877-15315-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1323456877-15315-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 12/18] libxl: libxl_ctx_free should free the ctx
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 7488538..5a29c29 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -93,6 +93,7 @@ int libxl_ctx_free(libxl_ctx *ctx)
     if (ctx->xch) xc_interface_close(ctx->xch);
     libxl_version_info_dispose(&ctx->version_info);
     if (ctx->xsh) xs_daemon_close(ctx->xsh);
+    free(ctx);
     return 0;
 }
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 18:55:51 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 18: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.xensource.com>)
	id 1RZ5bg-0001GJ-MY; Fri, 09 Dec 2011 18:55:40 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RZ5bf-0001BN-13
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 18:55:39 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1323456879!6616386!14
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI2MQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21474 invoked from network); 9 Dec 2011 18:54:48 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 18:54:48 -0000
X-IronPort-AV: E=Sophos;i="4.71,327,1320624000"; 
   d="scan'208";a="9392205"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 18:54:48 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 18:54:48 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RZ5aq-0002eL-Ag; Fri, 09 Dec 2011 18:54:48 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RZ5aq-00040l-9p;
	Fri, 09 Dec 2011 18:54:48 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 9 Dec 2011 18:54:32 +0000
Message-ID: <1323456877-15315-14-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1323456877-15315-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1323456877-15315-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 13/18] libxl: Use GC_INIT and GC_FREE everywhere
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Replace
    libxl__gc gc = LIBXL_INIT_GC(ctx);
    ...
    libxl__free_all(&gc);
with
    GC_INIT(ctx);
    ...
    GC_FREE;
throughout with a couple of perl runes.

We must then adjust uses of the resulting gc for pointerness, which is
mostly just replacing all occurrences of "&gc" with "gc".  Also a
couple of unusual uses of LIBXL_INIT_GC needed to be fixed up by hand.

Here are those runes:
 perl -i -pe 's/\Q    libxl__gc gc = LIBXL_INIT_GC(ctx);/    GC_INIT(ctx);/' tools/libxl/*.c
 perl -i -pe 's/\Q    libxl__free_all(&gc);/    GC_FREE;/' tools/libxl/*.c

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl.c            |  590 ++++++++++++++++++++--------------------
 tools/libxl/libxl_bootloader.c |   14 +-
 tools/libxl/libxl_create.c     |   12 +-
 tools/libxl/libxl_dom.c        |   16 +-
 tools/libxl/libxl_pci.c        |   34 ++--
 tools/libxl/libxl_qmp.c        |   32 +-
 tools/libxl/libxl_utils.c      |   36 ++--
 7 files changed, 367 insertions(+), 367 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 5a29c29..79ea701 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -233,19 +233,19 @@ int libxl__domain_rename(libxl__gc *gc, uint32_t domid,
 int libxl_domain_rename(libxl_ctx *ctx, uint32_t domid,
                         const char *old_name, const char *new_name)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     int rc;
-    rc = libxl__domain_rename(&gc, domid, old_name, new_name, XBT_NULL);
-    libxl__free_all(&gc);
+    rc = libxl__domain_rename(gc, domid, old_name, new_name, XBT_NULL);
+    GC_FREE;
     return rc;
 }
 
 int libxl_domain_resume(libxl_ctx *ctx, uint32_t domid)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     int rc = 0;
 
-    if (LIBXL__DOMAIN_IS_TYPE(&gc,  domid, HVM)) {
+    if (LIBXL__DOMAIN_IS_TYPE(gc,  domid, HVM)) {
         LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Called domain_resume on "
                 "non-cooperative hvm domain %u", domid);
         rc = ERROR_NI;
@@ -265,7 +265,7 @@ int libxl_domain_resume(libxl_ctx *ctx, uint32_t domid)
         rc = ERROR_FAIL;
     }
 out:
-    libxl__free_all(&gc);
+    GC_FREE;
     return rc;
 }
 
@@ -278,7 +278,7 @@ out:
 int libxl_domain_preserve(libxl_ctx *ctx, uint32_t domid,
                           libxl_domain_create_info *info, const char *name_suffix, libxl_uuid new_uuid)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     struct xs_permissions roperm[2];
     xs_transaction_t t;
     char *preserved_name;
@@ -288,27 +288,27 @@ int libxl_domain_preserve(libxl_ctx *ctx, uint32_t domid,
 
     int rc;
 
-    preserved_name = libxl__sprintf(&gc, "%s%s", info->name, name_suffix);
+    preserved_name = libxl__sprintf(gc, "%s%s", info->name, name_suffix);
     if (!preserved_name) {
-        libxl__free_all(&gc);
+        GC_FREE;
         return ERROR_NOMEM;
     }
 
-    uuid_string = libxl__uuid2string(&gc, new_uuid);
+    uuid_string = libxl__uuid2string(gc, new_uuid);
     if (!uuid_string) {
-        libxl__free_all(&gc);
+        GC_FREE;
         return ERROR_NOMEM;
     }
 
-    dom_path = libxl__xs_get_dompath(&gc, domid);
+    dom_path = libxl__xs_get_dompath(gc, domid);
     if (!dom_path) {
-        libxl__free_all(&gc);
+        GC_FREE;
         return ERROR_FAIL;
     }
 
-    vm_path = libxl__sprintf(&gc, "/vm/%s", uuid_string);
+    vm_path = libxl__sprintf(gc, "/vm/%s", uuid_string);
     if (!vm_path) {
-        libxl__free_all(&gc);
+        GC_FREE;
         return ERROR_FAIL;
     }
 
@@ -324,20 +324,20 @@ int libxl_domain_preserve(libxl_ctx *ctx, uint32_t domid,
     xs_mkdir(ctx->xsh, t, vm_path);
     xs_set_permissions(ctx->xsh, t, vm_path, roperm, ARRAY_SIZE(roperm));
 
-    xs_write(ctx->xsh, t, libxl__sprintf(&gc, "%s/vm", dom_path), vm_path, strlen(vm_path));
-    rc = libxl__domain_rename(&gc, domid, info->name, preserved_name, t);
+    xs_write(ctx->xsh, t, libxl__sprintf(gc, "%s/vm", dom_path), vm_path, strlen(vm_path));
+    rc = libxl__domain_rename(gc, domid, info->name, preserved_name, t);
     if (rc) {
-        libxl__free_all(&gc);
+        GC_FREE;
         return rc;
     }
 
-    xs_write(ctx->xsh, t, libxl__sprintf(&gc, "%s/uuid", vm_path), uuid_string, strlen(uuid_string));
+    xs_write(ctx->xsh, t, libxl__sprintf(gc, "%s/uuid", vm_path), uuid_string, strlen(uuid_string));
 
     if (!xs_transaction_end(ctx->xsh, t, 0))
         if (errno == EAGAIN)
             goto retry_transaction;
 
-    libxl__free_all(&gc);
+    GC_FREE;
     return 0;
 }
 
@@ -479,16 +479,16 @@ libxl_vminfo * libxl_list_vm(libxl_ctx *ctx, int *nb_vm)
 int libxl_domain_suspend(libxl_ctx *ctx, libxl_domain_suspend_info *info,
                          uint32_t domid, int fd)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
-    libxl_domain_type type = libxl__domain_type(&gc, domid);
+    GC_INIT(ctx);
+    libxl_domain_type type = libxl__domain_type(gc, domid);
     int live = info != NULL && info->flags & XL_SUSPEND_LIVE;
     int debug = info != NULL && info->flags & XL_SUSPEND_DEBUG;
     int rc = 0;
 
-    rc = libxl__domain_suspend_common(&gc, domid, fd, type, live, debug);
+    rc = libxl__domain_suspend_common(gc, domid, fd, type, live, debug);
     if (!rc && type == LIBXL_DOMAIN_TYPE_HVM)
-        rc = libxl__domain_save_device_model(&gc, domid, fd);
-    libxl__free_all(&gc);
+        rc = libxl__domain_save_device_model(gc, domid, fd);
+    GC_FREE;
     return rc;
 }
 
@@ -518,17 +518,17 @@ int libxl_domain_core_dump(libxl_ctx *ctx, uint32_t domid,
 
 int libxl_domain_unpause(libxl_ctx *ctx, uint32_t domid)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     char *path;
     char *state;
     int ret, rc = 0;
 
-    if (LIBXL__DOMAIN_IS_TYPE(&gc,  domid, HVM)) {
-        path = libxl__sprintf(&gc, "/local/domain/0/device-model/%d/state", domid);
-        state = libxl__xs_read(&gc, XBT_NULL, path);
+    if (LIBXL__DOMAIN_IS_TYPE(gc,  domid, HVM)) {
+        path = libxl__sprintf(gc, "/local/domain/0/device-model/%d/state", domid);
+        state = libxl__xs_read(gc, XBT_NULL, path);
         if (state != NULL && !strcmp(state, "paused")) {
-            libxl__xs_write(&gc, XBT_NULL, libxl__sprintf(&gc, "/local/domain/0/device-model/%d/command", domid), "continue");
-            libxl__wait_for_device_model(&gc, domid, "running",
+            libxl__xs_write(gc, XBT_NULL, libxl__sprintf(gc, "/local/domain/0/device-model/%d/command", domid), "continue");
+            libxl__wait_for_device_model(gc, domid, "running",
                                          NULL, NULL, NULL);
         }
     }
@@ -537,7 +537,7 @@ int libxl_domain_unpause(libxl_ctx *ctx, uint32_t domid)
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "unpausing domain %d", domid);
         rc = ERROR_FAIL;
     }
-    libxl__free_all(&gc);
+    GC_FREE;
     return rc;
 }
 
@@ -551,42 +551,42 @@ static char *req_table[] = {
 
 int libxl_domain_shutdown(libxl_ctx *ctx, uint32_t domid, int req)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     char *shutdown_path;
     char *dom_path;
 
     if (req > ARRAY_SIZE(req_table)) {
-        libxl__free_all(&gc);
+        GC_FREE;
         return ERROR_INVAL;
     }
 
-    dom_path = libxl__xs_get_dompath(&gc, domid);
+    dom_path = libxl__xs_get_dompath(gc, domid);
     if (!dom_path) {
-        libxl__free_all(&gc);
+        GC_FREE;
         return ERROR_FAIL;
     }
 
-    if (LIBXL__DOMAIN_IS_TYPE(&gc,  domid, HVM)) {
+    if (LIBXL__DOMAIN_IS_TYPE(gc,  domid, HVM)) {
         unsigned long pvdriver = 0;
         int ret;
         ret = xc_get_hvm_param(ctx->xch, domid, HVM_PARAM_CALLBACK_IRQ, &pvdriver);
         if (ret<0) {
             LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "getting HVM callback IRQ");
-            libxl__free_all(&gc);
+            GC_FREE;
             return ERROR_FAIL;
         }
         if (!pvdriver) {
             LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "HVM domain without PV drivers:"
                        " graceful shutdown not possible, use destroy");
-            libxl__free_all(&gc);
+            GC_FREE;
             return ERROR_FAIL;
         }
     }
 
-    shutdown_path = libxl__sprintf(&gc, "%s/control/shutdown", dom_path);
+    shutdown_path = libxl__sprintf(gc, "%s/control/shutdown", dom_path);
     xs_write(ctx->xsh, XBT_NULL, shutdown_path, req_table[req], strlen(req_table[req]));
 
-    libxl__free_all(&gc);
+    GC_FREE;
     return 0;
 }
 
@@ -608,7 +608,7 @@ int libxl_wait_for_domain_death(libxl_ctx *ctx, uint32_t domid, libxl_waiter *wa
 
 int libxl_wait_for_disk_ejects(libxl_ctx *ctx, uint32_t guest_domid, libxl_device_disk *disks, int num_disks, libxl_waiter *waiter)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     int i, rc = -1;
     uint32_t domid = libxl_get_stubdom_id(ctx, guest_domid);
 
@@ -617,7 +617,7 @@ int libxl_wait_for_disk_ejects(libxl_ctx *ctx, uint32_t guest_domid, libxl_devic
 
     for (i = 0; i < num_disks; i++) {
         if (asprintf(&(waiter[i].path), "%s/device/vbd/%d/eject",
-                     libxl__xs_get_dompath(&gc, domid),
+                     libxl__xs_get_dompath(gc, domid),
                      libxl__device_disk_dev_number(disks[i].vdev,
                                                    NULL, NULL)) < 0)
             goto out;
@@ -627,7 +627,7 @@ int libxl_wait_for_disk_ejects(libxl_ctx *ctx, uint32_t guest_domid, libxl_devic
     }
     rc = 0;
 out:
-    libxl__free_all(&gc);
+    GC_FREE;
     return rc;
 }
 
@@ -681,22 +681,22 @@ int libxl_event_get_domain_death_info(libxl_ctx *ctx, uint32_t domid, libxl_even
 
 int libxl_event_get_disk_eject_info(libxl_ctx *ctx, uint32_t domid, libxl_event *event, libxl_device_disk *disk)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     char *path;
     char *backend;
     char *value;
     char backend_type[BACKEND_STRING_SIZE+1];
 
-    value = libxl__xs_read(&gc, XBT_NULL, event->path);
+    value = libxl__xs_read(gc, XBT_NULL, event->path);
 
     if (!value || strcmp(value,  "eject")) {
-        libxl__free_all(&gc);
+        GC_FREE;
         return 0;
     }
 
     path = strdup(event->path);
     path[strlen(path) - 6] = '\0';
-    backend = libxl__xs_read(&gc, XBT_NULL, libxl__sprintf(&gc, "%s/backend", path));
+    backend = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/backend", path));
 
     sscanf(backend,
             "/local/domain/%d/backend/%" TOSTRING(BACKEND_STRING_SIZE) "[a-z]/%*d/%*d",
@@ -712,19 +712,19 @@ int libxl_event_get_disk_eject_info(libxl_ctx *ctx, uint32_t domid, libxl_event
     disk->pdev_path = strdup("");
     disk->format = LIBXL_DISK_FORMAT_EMPTY;
     /* this value is returned to the user: do not free right away */
-    disk->vdev = xs_read(ctx->xsh, XBT_NULL, libxl__sprintf(&gc, "%s/dev", backend), NULL);
+    disk->vdev = xs_read(ctx->xsh, XBT_NULL, libxl__sprintf(gc, "%s/dev", backend), NULL);
     disk->removable = 1;
     disk->readwrite = 0;
     disk->is_cdrom = 1;
 
     free(path);
-    libxl__free_all(&gc);
+    GC_FREE;
     return 1;
 }
 
 int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid, int force)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     libxl_dominfo dominfo;
     char *dom_path;
     char *vm_path;
@@ -741,40 +741,40 @@ int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid, int force)
         return rc;
     }
 
-    switch (libxl__domain_type(&gc, domid)) {
+    switch (libxl__domain_type(gc, domid)) {
     case LIBXL_DOMAIN_TYPE_HVM:
         dm_present = 1;
         break;
     case LIBXL_DOMAIN_TYPE_PV:
-        pid = libxl__xs_read(&gc, XBT_NULL, libxl__sprintf(&gc, "/local/domain/%d/image/device-model-pid", domid));
+        pid = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "/local/domain/%d/image/device-model-pid", domid));
         dm_present = (pid != NULL);
         break;
     default:
         abort();
     }
 
-    dom_path = libxl__xs_get_dompath(&gc, domid);
+    dom_path = libxl__xs_get_dompath(gc, domid);
     if (!dom_path) {
         rc = ERROR_FAIL;
         goto out;
     }
 
-    if (libxl__device_pci_destroy_all(&gc, domid) < 0)
+    if (libxl__device_pci_destroy_all(gc, domid) < 0)
         LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "pci shutdown failed for domid %d", domid);
     rc = xc_domain_pause(ctx->xch, domid);
     if (rc < 0) {
         LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, rc, "xc_domain_pause failed for %d", domid);
     }
     if (dm_present) {
-        if (libxl__destroy_device_model(&gc, domid) < 0)
+        if (libxl__destroy_device_model(gc, domid) < 0)
             LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "libxl__destroy_device_model failed for %d", domid);
 
-        libxl__qmp_cleanup(&gc, domid);
+        libxl__qmp_cleanup(gc, domid);
     }
-    if (libxl__devices_destroy(&gc, domid, force) < 0)
+    if (libxl__devices_destroy(gc, domid, force) < 0)
         LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "libxl_devices_dispose failed for %d", domid);
 
-    vm_path = libxl__xs_read(&gc, XBT_NULL, libxl__sprintf(&gc, "%s/vm", dom_path));
+    vm_path = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/vm", dom_path));
     if (vm_path)
         if (!xs_rm(ctx->xsh, XBT_NULL, vm_path))
             LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "xs_rm failed for %s", vm_path);
@@ -782,9 +782,9 @@ int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid, int force)
     if (!xs_rm(ctx->xsh, XBT_NULL, dom_path))
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "xs_rm failed for %s", dom_path);
 
-    xs_rm(ctx->xsh, XBT_NULL, libxl__xs_libxl_path(&gc, domid));
+    xs_rm(ctx->xsh, XBT_NULL, libxl__xs_libxl_path(gc, domid));
 
-    libxl__userdata_destroyall(&gc, domid);
+    libxl__userdata_destroyall(gc, domid);
 
     rc = xc_domain_destroy(ctx->xch, domid);
     if (rc < 0) {
@@ -794,16 +794,16 @@ int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid, int force)
     }
     rc = 0;
 out:
-    libxl__free_all(&gc);
+    GC_FREE;
     return rc;
 }
 
 int libxl_console_exec(libxl_ctx *ctx, uint32_t domid, int cons_num, libxl_console_type type)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
-    char *p = libxl__sprintf(&gc, "%s/xenconsole", libxl_private_bindir_path());
-    char *domid_s = libxl__sprintf(&gc, "%d", domid);
-    char *cons_num_s = libxl__sprintf(&gc, "%d", cons_num);
+    GC_INIT(ctx);
+    char *p = libxl__sprintf(gc, "%s/xenconsole", libxl_private_bindir_path());
+    char *domid_s = libxl__sprintf(gc, "%d", domid);
+    char *cons_num_s = libxl__sprintf(gc, "%d", cons_num);
     char *cons_type_s;
 
     switch (type) {
@@ -820,20 +820,20 @@ int libxl_console_exec(libxl_ctx *ctx, uint32_t domid, int cons_num, libxl_conso
     execl(p, p, domid_s, "--num", cons_num_s, "--type", cons_type_s, (void *)NULL);
 
 out:
-    libxl__free_all(&gc);
+    GC_FREE;
     return ERROR_FAIL;
 }
 
 int libxl_primary_console_exec(libxl_ctx *ctx, uint32_t domid_vm)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     uint32_t stubdomid = libxl_get_stubdom_id(ctx, domid_vm);
     int rc;
     if (stubdomid)
         rc = libxl_console_exec(ctx, stubdomid,
                                 STUBDOM_CONSOLE_SERIAL, LIBXL_CONSOLE_TYPE_PV);
     else {
-        switch (libxl__domain_type(&gc, domid_vm)) {
+        switch (libxl__domain_type(gc, domid_vm)) {
         case LIBXL_DOMAIN_TYPE_HVM:
             rc = libxl_console_exec(ctx, domid_vm, 0, LIBXL_CONSOLE_TYPE_SERIAL);
             break;
@@ -844,13 +844,13 @@ int libxl_primary_console_exec(libxl_ctx *ctx, uint32_t domid_vm)
             abort();
         }
     }
-    libxl__free_all(&gc);
+    GC_FREE;
     return rc;
 }
 
 int libxl_vncviewer_exec(libxl_ctx *ctx, uint32_t domid, int autopass)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     const char *vnc_port;
     const char *vnc_listen = NULL, *vnc_pass = NULL;
     int port = 0, autopass_fd = -1;
@@ -861,19 +861,19 @@ int libxl_vncviewer_exec(libxl_ctx *ctx, uint32_t domid, int autopass)
         NULL,
     };
 
-    vnc_port = libxl__xs_read(&gc, XBT_NULL,
-                            libxl__sprintf(&gc,
+    vnc_port = libxl__xs_read(gc, XBT_NULL,
+                            libxl__sprintf(gc,
                             "/local/domain/%d/console/vnc-port", domid));
     if ( vnc_port )
         port = atoi(vnc_port) - 5900;
 
-    vnc_listen = libxl__xs_read(&gc, XBT_NULL,
-                                libxl__sprintf(&gc,
+    vnc_listen = libxl__xs_read(gc, XBT_NULL,
+                                libxl__sprintf(gc,
                             "/local/domain/%d/console/vnc-listen", domid));
 
     if ( autopass )
-        vnc_pass = libxl__xs_read(&gc, XBT_NULL,
-                                  libxl__sprintf(&gc,
+        vnc_pass = libxl__xs_read(gc, XBT_NULL,
+                                  libxl__sprintf(gc,
                             "/local/domain/%d/console/vnc-pass", domid));
 
     if ( NULL == vnc_listen )
@@ -882,7 +882,7 @@ int libxl_vncviewer_exec(libxl_ctx *ctx, uint32_t domid, int autopass)
     if ( (vnc_bin = getenv("VNCVIEWER")) )
         args[0] = vnc_bin;
 
-    args[1] = libxl__sprintf(&gc, "%s:%d", vnc_listen, port);
+    args[1] = libxl__sprintf(gc, "%s:%d", vnc_listen, port);
 
     if ( vnc_pass ) {
         char tmpname[] = "/tmp/vncautopass.XXXXXX";
@@ -917,7 +917,7 @@ int libxl_vncviewer_exec(libxl_ctx *ctx, uint32_t domid, int autopass)
     abort();
 
  x_fail:
-    libxl__free_all(&gc);
+    GC_FREE;
     return ERROR_FAIL;
 }
 
@@ -971,17 +971,17 @@ static int libxl__device_from_disk(libxl__gc *gc, uint32_t domid,
 
 int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *disk)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     flexarray_t *front;
     flexarray_t *back;
     char *dev;
     libxl__device device;
     int major, minor, rc;
 
-    rc = libxl__device_disk_set_backend(&gc, disk);
+    rc = libxl__device_disk_set_backend(gc, disk);
     if (rc) goto out;
 
-    rc = libxl__device_disk_set_backend(&gc, disk);
+    rc = libxl__device_disk_set_backend(gc, disk);
     if (rc) goto out;
 
     front = flexarray_make(16, 1);
@@ -1002,7 +1002,7 @@ int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *dis
         goto out_free;
     }
 
-    rc = libxl__device_from_disk(&gc, domid, disk, &device);
+    rc = libxl__device_from_disk(gc, domid, disk, &device);
     if (rc != 0) {
         LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Invalid or unsupported"
                " virtual disk identifier %s", disk->vdev);
@@ -1015,7 +1015,7 @@ int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *dis
     do_backend_phy:
             libxl__device_physdisk_major_minor(dev, &major, &minor);
             flexarray_append(back, "physical-device");
-            flexarray_append(back, libxl__sprintf(&gc, "%x:%x", major, minor));
+            flexarray_append(back, libxl__sprintf(gc, "%x:%x", major, minor));
 
             flexarray_append(back, "params");
             flexarray_append(back, dev);
@@ -1023,13 +1023,13 @@ int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *dis
             assert(device.backend_kind == LIBXL__DEVICE_KIND_VBD);
             break;
         case LIBXL_DISK_BACKEND_TAP:
-            dev = libxl__blktap_devpath(&gc, disk->pdev_path, disk->format);
+            dev = libxl__blktap_devpath(gc, disk->pdev_path, disk->format);
             if (!dev) {
                 rc = ERROR_FAIL;
                 goto out_free;
             }
             flexarray_append(back, "tapdisk-params");
-            flexarray_append(back, libxl__sprintf(&gc, "%s:%s",
+            flexarray_append(back, libxl__sprintf(gc, "%s:%s",
                 libxl__device_disk_string_of_format(disk->format),
                 disk->pdev_path));
 
@@ -1037,7 +1037,7 @@ int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *dis
             goto do_backend_phy;
         case LIBXL_DISK_BACKEND_QDISK:
             flexarray_append(back, "params");
-            flexarray_append(back, libxl__sprintf(&gc, "%s:%s",
+            flexarray_append(back, libxl__sprintf(gc, "%s:%s",
                           libxl__device_disk_string_of_format(disk->format), disk->pdev_path));
             assert(device.backend_kind == LIBXL__DEVICE_KIND_QDISK);
             break;
@@ -1048,15 +1048,15 @@ int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *dis
     }
 
     flexarray_append(back, "frontend-id");
-    flexarray_append(back, libxl__sprintf(&gc, "%d", domid));
+    flexarray_append(back, libxl__sprintf(gc, "%d", domid));
     flexarray_append(back, "online");
     flexarray_append(back, "1");
     flexarray_append(back, "removable");
-    flexarray_append(back, libxl__sprintf(&gc, "%d", (disk->removable) ? 1 : 0));
+    flexarray_append(back, libxl__sprintf(gc, "%d", (disk->removable) ? 1 : 0));
     flexarray_append(back, "bootable");
-    flexarray_append(back, libxl__sprintf(&gc, "%d", 1));
+    flexarray_append(back, libxl__sprintf(gc, "%d", 1));
     flexarray_append(back, "state");
-    flexarray_append(back, libxl__sprintf(&gc, "%d", 1));
+    flexarray_append(back, libxl__sprintf(gc, "%d", 1));
     flexarray_append(back, "dev");
     flexarray_append(back, disk->vdev);
     flexarray_append(back, "type");
@@ -1067,17 +1067,17 @@ int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *dis
     flexarray_append(back, disk->is_cdrom ? "cdrom" : "disk");
 
     flexarray_append(front, "backend-id");
-    flexarray_append(front, libxl__sprintf(&gc, "%d", disk->backend_domid));
+    flexarray_append(front, libxl__sprintf(gc, "%d", disk->backend_domid));
     flexarray_append(front, "state");
-    flexarray_append(front, libxl__sprintf(&gc, "%d", 1));
+    flexarray_append(front, libxl__sprintf(gc, "%d", 1));
     flexarray_append(front, "virtual-device");
-    flexarray_append(front, libxl__sprintf(&gc, "%d", device.devid));
+    flexarray_append(front, libxl__sprintf(gc, "%d", device.devid));
     flexarray_append(front, "device-type");
     flexarray_append(front, disk->is_cdrom ? "cdrom" : "disk");
 
-    libxl__device_generic_add(&gc, &device,
-                             libxl__xs_kvs_of_flexarray(&gc, back, back->count),
-                             libxl__xs_kvs_of_flexarray(&gc, front, front->count));
+    libxl__device_generic_add(gc, &device,
+                             libxl__xs_kvs_of_flexarray(gc, back, back->count),
+                             libxl__xs_kvs_of_flexarray(gc, front, front->count));
 
     rc = 0;
 
@@ -1085,39 +1085,39 @@ out_free:
     flexarray_free(back);
     flexarray_free(front);
 out:
-    libxl__free_all(&gc);
+    GC_FREE;
     return rc;
 }
 
 int libxl_device_disk_remove(libxl_ctx *ctx, uint32_t domid,
                              libxl_device_disk *disk)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     libxl__device device;
     int rc;
 
-    rc = libxl__device_from_disk(&gc, domid, disk, &device);
+    rc = libxl__device_from_disk(gc, domid, disk, &device);
     if (rc != 0) goto out;
 
-    rc = libxl__device_remove(&gc, &device, 1);
+    rc = libxl__device_remove(gc, &device, 1);
 out:
-    libxl__free_all(&gc);
+    GC_FREE;
     return rc;
 }
 
 int libxl_device_disk_destroy(libxl_ctx *ctx, uint32_t domid,
                               libxl_device_disk *disk)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     libxl__device device;
     int rc;
 
-    rc = libxl__device_from_disk(&gc, domid, disk, &device);
+    rc = libxl__device_from_disk(gc, domid, disk, &device);
     if (rc != 0) goto out;
 
-    rc = libxl__device_destroy(&gc, &device);
+    rc = libxl__device_destroy(gc, &device);
 out:
-    libxl__free_all(&gc);
+    GC_FREE;
     return rc;
 }
 
@@ -1169,27 +1169,27 @@ static void libxl__device_disk_from_xs_be(libxl__gc *gc,
 int libxl_devid_to_device_disk(libxl_ctx *ctx, uint32_t domid,
                                int devid, libxl_device_disk *disk)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     char *dompath, *path;
     int rc = ERROR_FAIL;
 
     libxl_device_disk_init(ctx, disk);
 
-    dompath = libxl__xs_get_dompath(&gc, domid);
+    dompath = libxl__xs_get_dompath(gc, domid);
     if (!dompath) {
         goto out;
     }
-    path = libxl__xs_read(&gc, XBT_NULL,
-                          libxl__sprintf(&gc, "%s/device/vbd/%d/backend",
+    path = libxl__xs_read(gc, XBT_NULL,
+                          libxl__sprintf(gc, "%s/device/vbd/%d/backend",
                                          dompath, devid));
     if (!path)
         goto out;
 
-    libxl__device_disk_from_xs_be(&gc, path, disk);
+    libxl__device_disk_from_xs_be(gc, path, disk);
 
     rc = 0;
 out:
-    libxl__free_all(&gc);
+    GC_FREE;
     return rc;
 }
 
@@ -1229,22 +1229,22 @@ static int libxl__append_disk_list_of_type(libxl__gc *gc,
 
 libxl_device_disk *libxl_device_disk_list(libxl_ctx *ctx, uint32_t domid, int *num)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     libxl_device_disk *disks = NULL;
     int rc;
 
     *num = 0;
 
-    rc = libxl__append_disk_list_of_type(&gc, domid, "vbd", &disks, num);
+    rc = libxl__append_disk_list_of_type(gc, domid, "vbd", &disks, num);
     if (rc) goto out_err;
 
-    rc = libxl__append_disk_list_of_type(&gc, domid, "tap", &disks, num);
+    rc = libxl__append_disk_list_of_type(gc, domid, "tap", &disks, num);
     if (rc) goto out_err;
 
-    rc = libxl__append_disk_list_of_type(&gc, domid, "qdisk", &disks, num);
+    rc = libxl__append_disk_list_of_type(gc, domid, "qdisk", &disks, num);
     if (rc) goto out_err;
 
-    libxl__free_all(&gc);
+    GC_FREE;
     return disks;
 
 out_err:
@@ -1260,35 +1260,35 @@ out_err:
 int libxl_device_disk_getinfo(libxl_ctx *ctx, uint32_t domid,
                               libxl_device_disk *disk, libxl_diskinfo *diskinfo)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     char *dompath, *diskpath;
     char *val;
 
-    dompath = libxl__xs_get_dompath(&gc, domid);
+    dompath = libxl__xs_get_dompath(gc, domid);
     diskinfo->devid = libxl__device_disk_dev_number(disk->vdev, NULL, NULL);
 
     /* tap devices entries in xenstore are written as vbd devices. */
-    diskpath = libxl__sprintf(&gc, "%s/device/vbd/%d", dompath, diskinfo->devid);
+    diskpath = libxl__sprintf(gc, "%s/device/vbd/%d", dompath, diskinfo->devid);
     diskinfo->backend = xs_read(ctx->xsh, XBT_NULL,
-                                libxl__sprintf(&gc, "%s/backend", diskpath), NULL);
+                                libxl__sprintf(gc, "%s/backend", diskpath), NULL);
     if (!diskinfo->backend) {
-        libxl__free_all(&gc);
+        GC_FREE;
         return ERROR_FAIL;
     }
-    val = libxl__xs_read(&gc, XBT_NULL, libxl__sprintf(&gc, "%s/backend-id", diskpath));
+    val = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/backend-id", diskpath));
     diskinfo->backend_id = val ? strtoul(val, NULL, 10) : -1;
-    val = libxl__xs_read(&gc, XBT_NULL, libxl__sprintf(&gc, "%s/state", diskpath));
+    val = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/state", diskpath));
     diskinfo->state = val ? strtoul(val, NULL, 10) : -1;
-    val = libxl__xs_read(&gc, XBT_NULL, libxl__sprintf(&gc, "%s/event-channel", diskpath));
+    val = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/event-channel", diskpath));
     diskinfo->evtch = val ? strtoul(val, NULL, 10) : -1;
-    val = libxl__xs_read(&gc, XBT_NULL, libxl__sprintf(&gc, "%s/ring-ref", diskpath));
+    val = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/ring-ref", diskpath));
     diskinfo->rref = val ? strtoul(val, NULL, 10) : -1;
     diskinfo->frontend = xs_read(ctx->xsh, XBT_NULL,
-                                 libxl__sprintf(&gc, "%s/frontend", diskinfo->backend), NULL);
-    val = libxl__xs_read(&gc, XBT_NULL, libxl__sprintf(&gc, "%s/frontend-id", diskinfo->backend));
+                                 libxl__sprintf(gc, "%s/frontend", diskinfo->backend), NULL);
+    val = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/frontend-id", diskinfo->backend));
     diskinfo->frontend_id = val ? strtoul(val, NULL, 10) : -1;
 
-    libxl__free_all(&gc);
+    GC_FREE;
     return 0;
 }
 
@@ -1332,12 +1332,12 @@ out:
 
 char * libxl_device_disk_local_attach(libxl_ctx *ctx, libxl_device_disk *disk)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     char *dev = NULL;
     char *ret = NULL;
     int rc;
 
-    rc = libxl__device_disk_set_backend(&gc, disk);
+    rc = libxl__device_disk_set_backend(gc, disk);
     if (rc) goto out;
 
     switch (disk->backend) {
@@ -1356,7 +1356,7 @@ char * libxl_device_disk_local_attach(libxl_ctx *ctx, libxl_device_disk *disk)
                 dev = disk->pdev_path;
                 break;
             case LIBXL_DISK_FORMAT_VHD:
-                dev = libxl__blktap_devpath(&gc, disk->pdev_path,
+                dev = libxl__blktap_devpath(gc, disk->pdev_path,
                                             disk->format);
                 break;
             case LIBXL_DISK_FORMAT_QCOW:
@@ -1387,7 +1387,7 @@ char * libxl_device_disk_local_attach(libxl_ctx *ctx, libxl_device_disk *disk)
  out:
     if (dev != NULL)
         ret = strdup(dev);
-    libxl__free_all(&gc);
+    GC_FREE;
     return ret;
 }
 
@@ -1449,7 +1449,7 @@ static int libxl__device_from_nic(libxl__gc *gc, uint32_t domid,
 
 int libxl_device_nic_add(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     flexarray_t *front;
     flexarray_t *back;
     libxl__device device;
@@ -1468,59 +1468,59 @@ int libxl_device_nic_add(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic)
     }
 
     if (nic->devid == -1) {
-        if (!(dompath = libxl__xs_get_dompath(&gc, domid))) {
+        if (!(dompath = libxl__xs_get_dompath(gc, domid))) {
             rc = ERROR_FAIL;
             goto out_free;
         }
-        if (!(l = libxl__xs_directory(&gc, XBT_NULL,
-                                     libxl__sprintf(&gc, "%s/device/vif", dompath), &nb))) {
+        if (!(l = libxl__xs_directory(gc, XBT_NULL,
+                                     libxl__sprintf(gc, "%s/device/vif", dompath), &nb))) {
             nic->devid = 0;
         } else {
             nic->devid = strtoul(l[nb - 1], NULL, 10) + 1;
         }
     }
 
-    rc = libxl__device_from_nic(&gc, domid, nic, &device);
+    rc = libxl__device_from_nic(gc, domid, nic, &device);
     if ( rc != 0 ) goto out_free;
 
     flexarray_append(back, "frontend-id");
-    flexarray_append(back, libxl__sprintf(&gc, "%d", domid));
+    flexarray_append(back, libxl__sprintf(gc, "%d", domid));
     flexarray_append(back, "online");
     flexarray_append(back, "1");
     flexarray_append(back, "state");
-    flexarray_append(back, libxl__sprintf(&gc, "%d", 1));
+    flexarray_append(back, libxl__sprintf(gc, "%d", 1));
     if (nic->script) {
         flexarray_append(back, "script");
         flexarray_append(back, nic->script[0]=='/' ? nic->script
-                         : libxl__sprintf(&gc, "%s/%s",
+                         : libxl__sprintf(gc, "%s/%s",
                                           libxl_xen_script_dir_path(),
                                           nic->script));
     }
     flexarray_append(back, "mac");
-    flexarray_append(back,libxl__sprintf(&gc,
+    flexarray_append(back,libxl__sprintf(gc,
                                     LIBXL_MAC_FMT, LIBXL_MAC_BYTES(nic->mac)));
     if (nic->ip) {
         flexarray_append(back, "ip");
-        flexarray_append(back, libxl__strdup(&gc, nic->ip));
+        flexarray_append(back, libxl__strdup(gc, nic->ip));
     }
 
     flexarray_append(back, "bridge");
-    flexarray_append(back, libxl__strdup(&gc, nic->bridge));
+    flexarray_append(back, libxl__strdup(gc, nic->bridge));
     flexarray_append(back, "handle");
-    flexarray_append(back, libxl__sprintf(&gc, "%d", nic->devid));
+    flexarray_append(back, libxl__sprintf(gc, "%d", nic->devid));
 
     flexarray_append(front, "backend-id");
-    flexarray_append(front, libxl__sprintf(&gc, "%d", nic->backend_domid));
+    flexarray_append(front, libxl__sprintf(gc, "%d", nic->backend_domid));
     flexarray_append(front, "state");
-    flexarray_append(front, libxl__sprintf(&gc, "%d", 1));
+    flexarray_append(front, libxl__sprintf(gc, "%d", 1));
     flexarray_append(front, "handle");
-    flexarray_append(front, libxl__sprintf(&gc, "%d", nic->devid));
+    flexarray_append(front, libxl__sprintf(gc, "%d", nic->devid));
     flexarray_append(front, "mac");
-    flexarray_append(front, libxl__sprintf(&gc,
+    flexarray_append(front, libxl__sprintf(gc,
                                     LIBXL_MAC_FMT, LIBXL_MAC_BYTES(nic->mac)));
-    libxl__device_generic_add(&gc, &device,
-                             libxl__xs_kvs_of_flexarray(&gc, back, back->count),
-                             libxl__xs_kvs_of_flexarray(&gc, front, front->count));
+    libxl__device_generic_add(gc, &device,
+                             libxl__xs_kvs_of_flexarray(gc, back, back->count),
+                             libxl__xs_kvs_of_flexarray(gc, front, front->count));
 
     /* FIXME: wait for plug */
     rc = 0;
@@ -1528,39 +1528,39 @@ out_free:
     flexarray_free(back);
     flexarray_free(front);
 out:
-    libxl__free_all(&gc);
+    GC_FREE;
     return rc;
 }
 
 int libxl_device_nic_remove(libxl_ctx *ctx, uint32_t domid,
                             libxl_device_nic *nic)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     libxl__device device;
     int rc;
 
-    rc = libxl__device_from_nic(&gc, domid, nic, &device);
+    rc = libxl__device_from_nic(gc, domid, nic, &device);
     if (rc != 0) goto out;
 
-    rc = libxl__device_remove(&gc, &device, 1);
+    rc = libxl__device_remove(gc, &device, 1);
 out:
-    libxl__free_all(&gc);
+    GC_FREE;
     return rc;
 }
 
 int libxl_device_nic_destroy(libxl_ctx *ctx, uint32_t domid,
                                   libxl_device_nic *nic)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     libxl__device device;
     int rc;
 
-    rc = libxl__device_from_nic(&gc, domid, nic, &device);
+    rc = libxl__device_from_nic(gc, domid, nic, &device);
     if (rc != 0) goto out;
 
-    rc = libxl__device_destroy(&gc, &device);
+    rc = libxl__device_destroy(gc, &device);
 out:
-    libxl__free_all(&gc);
+    GC_FREE;
     return rc;
 }
 
@@ -1608,26 +1608,26 @@ static void libxl__device_nic_from_xs_be(libxl__gc *gc,
 int libxl_devid_to_device_nic(libxl_ctx *ctx, uint32_t domid,
                               int devid, libxl_device_nic *nic)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     char *dompath, *path;
     int rc = ERROR_FAIL;
 
     memset(nic, 0, sizeof (libxl_device_nic));
-    dompath = libxl__xs_get_dompath(&gc, domid);
+    dompath = libxl__xs_get_dompath(gc, domid);
     if (!dompath)
         goto out;
 
-    path = libxl__xs_read(&gc, XBT_NULL,
-                          libxl__sprintf(&gc, "%s/device/vif/%d/backend",
+    path = libxl__xs_read(gc, XBT_NULL,
+                          libxl__sprintf(gc, "%s/device/vif/%d/backend",
                                          dompath, devid));
     if (!path)
         goto out;
 
-    libxl__device_nic_from_xs_be(&gc, path, nic);
+    libxl__device_nic_from_xs_be(gc, path, nic);
 
     rc = 0;
 out:
-    libxl__free_all(&gc);
+    GC_FREE;
     return rc;
 }
 
@@ -1666,16 +1666,16 @@ static int libxl__append_nic_list_of_type(libxl__gc *gc,
 
 libxl_device_nic *libxl_device_nic_list(libxl_ctx *ctx, uint32_t domid, int *num)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     libxl_device_nic *nics = NULL;
     int rc;
 
     *num = 0;
 
-    rc = libxl__append_nic_list_of_type(&gc, domid, "vif", &nics, num);
+    rc = libxl__append_nic_list_of_type(gc, domid, "vif", &nics, num);
     if (rc) goto out_err;
 
-    libxl__free_all(&gc);
+    GC_FREE;
     return nics;
 
 out_err:
@@ -1691,36 +1691,36 @@ out_err:
 int libxl_device_nic_getinfo(libxl_ctx *ctx, uint32_t domid,
                               libxl_device_nic *nic, libxl_nicinfo *nicinfo)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     char *dompath, *nicpath;
     char *val;
 
-    dompath = libxl__xs_get_dompath(&gc, domid);
+    dompath = libxl__xs_get_dompath(gc, domid);
     nicinfo->devid = nic->devid;
 
-    nicpath = libxl__sprintf(&gc, "%s/device/vif/%d", dompath, nicinfo->devid);
+    nicpath = libxl__sprintf(gc, "%s/device/vif/%d", dompath, nicinfo->devid);
     nicinfo->backend = xs_read(ctx->xsh, XBT_NULL,
-                                libxl__sprintf(&gc, "%s/backend", nicpath), NULL);
+                                libxl__sprintf(gc, "%s/backend", nicpath), NULL);
     if (!nicinfo->backend) {
-        libxl__free_all(&gc);
+        GC_FREE;
         return ERROR_FAIL;
     }
-    val = libxl__xs_read(&gc, XBT_NULL, libxl__sprintf(&gc, "%s/backend-id", nicpath));
+    val = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/backend-id", nicpath));
     nicinfo->backend_id = val ? strtoul(val, NULL, 10) : -1;
-    val = libxl__xs_read(&gc, XBT_NULL, libxl__sprintf(&gc, "%s/state", nicpath));
+    val = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/state", nicpath));
     nicinfo->state = val ? strtoul(val, NULL, 10) : -1;
-    val = libxl__xs_read(&gc, XBT_NULL, libxl__sprintf(&gc, "%s/event-channel", nicpath));
+    val = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/event-channel", nicpath));
     nicinfo->evtch = val ? strtoul(val, NULL, 10) : -1;
-    val = libxl__xs_read(&gc, XBT_NULL, libxl__sprintf(&gc, "%s/tx-ring-ref", nicpath));
+    val = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/tx-ring-ref", nicpath));
     nicinfo->rref_tx = val ? strtoul(val, NULL, 10) : -1;
-    val = libxl__xs_read(&gc, XBT_NULL, libxl__sprintf(&gc, "%s/rx-ring-ref", nicpath));
+    val = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/rx-ring-ref", nicpath));
     nicinfo->rref_rx = val ? strtoul(val, NULL, 10) : -1;
     nicinfo->frontend = xs_read(ctx->xsh, XBT_NULL,
-                                 libxl__sprintf(&gc, "%s/frontend", nicinfo->backend), NULL);
-    val = libxl__xs_read(&gc, XBT_NULL, libxl__sprintf(&gc, "%s/frontend-id", nicinfo->backend));
+                                 libxl__sprintf(gc, "%s/frontend", nicinfo->backend), NULL);
+    val = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/frontend-id", nicinfo->backend));
     nicinfo->frontend_id = val ? strtoul(val, NULL, 10) : -1;
 
-    libxl__free_all(&gc);
+    GC_FREE;
     return 0;
 }
 
@@ -1826,7 +1826,7 @@ static int libxl__device_from_vkb(libxl__gc *gc, uint32_t domid,
 
 int libxl_device_vkb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vkb *vkb)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     flexarray_t *front;
     flexarray_t *back;
     libxl__device device;
@@ -1843,64 +1843,64 @@ int libxl_device_vkb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vkb *vkb)
         goto out_free;
     }
 
-    rc = libxl__device_from_vkb(&gc, domid, vkb, &device);
+    rc = libxl__device_from_vkb(gc, domid, vkb, &device);
     if (rc != 0) goto out_free;
 
     flexarray_append(back, "frontend-id");
-    flexarray_append(back, libxl__sprintf(&gc, "%d", domid));
+    flexarray_append(back, libxl__sprintf(gc, "%d", domid));
     flexarray_append(back, "online");
     flexarray_append(back, "1");
     flexarray_append(back, "state");
-    flexarray_append(back, libxl__sprintf(&gc, "%d", 1));
+    flexarray_append(back, libxl__sprintf(gc, "%d", 1));
     flexarray_append(back, "domain");
-    flexarray_append(back, libxl__domid_to_name(&gc, domid));
+    flexarray_append(back, libxl__domid_to_name(gc, domid));
 
     flexarray_append(front, "backend-id");
-    flexarray_append(front, libxl__sprintf(&gc, "%d", vkb->backend_domid));
+    flexarray_append(front, libxl__sprintf(gc, "%d", vkb->backend_domid));
     flexarray_append(front, "state");
-    flexarray_append(front, libxl__sprintf(&gc, "%d", 1));
+    flexarray_append(front, libxl__sprintf(gc, "%d", 1));
 
-    libxl__device_generic_add(&gc, &device,
-                             libxl__xs_kvs_of_flexarray(&gc, back, back->count),
-                             libxl__xs_kvs_of_flexarray(&gc, front, front->count));
+    libxl__device_generic_add(gc, &device,
+                             libxl__xs_kvs_of_flexarray(gc, back, back->count),
+                             libxl__xs_kvs_of_flexarray(gc, front, front->count));
     rc = 0;
 out_free:
     flexarray_free(back);
     flexarray_free(front);
 out:
-    libxl__free_all(&gc);
+    GC_FREE;
     return rc;
 }
 
 int libxl_device_vkb_remove(libxl_ctx *ctx, uint32_t domid,
                             libxl_device_vkb *vkb)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     libxl__device device;
     int rc;
 
-    rc = libxl__device_from_vkb(&gc, domid, vkb, &device);
+    rc = libxl__device_from_vkb(gc, domid, vkb, &device);
     if (rc != 0) goto out;
 
-    rc = libxl__device_remove(&gc, &device, 1);
+    rc = libxl__device_remove(gc, &device, 1);
 out:
-    libxl__free_all(&gc);
+    GC_FREE;
     return rc;
 }
 
 int libxl_device_vkb_destroy(libxl_ctx *ctx, uint32_t domid,
                                   libxl_device_vkb *vkb)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     libxl__device device;
     int rc;
 
-    rc = libxl__device_from_vkb(&gc, domid, vkb, &device);
+    rc = libxl__device_from_vkb(gc, domid, vkb, &device);
     if (rc != 0) goto out;
 
-    rc = libxl__device_destroy(&gc, &device);
+    rc = libxl__device_destroy(gc, &device);
 out:
-    libxl__free_all(&gc);
+    GC_FREE;
     return rc;
 }
 
@@ -1936,7 +1936,7 @@ static int libxl__device_from_vfb(libxl__gc *gc, uint32_t domid,
 
 int libxl_device_vfb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vfb *vfb)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     flexarray_t *front;
     flexarray_t *back;
     libxl__device device;
@@ -1953,20 +1953,20 @@ int libxl_device_vfb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vfb *vfb)
         goto out_free;
     }
 
-    rc = libxl__device_from_vfb(&gc, domid, vfb, &device);
+    rc = libxl__device_from_vfb(gc, domid, vfb, &device);
     if (rc != 0) goto out_free;
 
-    flexarray_append_pair(back, "frontend-id", libxl__sprintf(&gc, "%d", domid));
+    flexarray_append_pair(back, "frontend-id", libxl__sprintf(gc, "%d", domid));
     flexarray_append_pair(back, "online", "1");
-    flexarray_append_pair(back, "state", libxl__sprintf(&gc, "%d", 1));
-    flexarray_append_pair(back, "domain", libxl__domid_to_name(&gc, domid));
-    flexarray_append_pair(back, "vnc", libxl__sprintf(&gc, "%d", vfb->vnc));
+    flexarray_append_pair(back, "state", libxl__sprintf(gc, "%d", 1));
+    flexarray_append_pair(back, "domain", libxl__domid_to_name(gc, domid));
+    flexarray_append_pair(back, "vnc", libxl__sprintf(gc, "%d", vfb->vnc));
     flexarray_append_pair(back, "vnclisten", vfb->vnclisten);
     flexarray_append_pair(back, "vncpasswd", vfb->vncpasswd);
-    flexarray_append_pair(back, "vncdisplay", libxl__sprintf(&gc, "%d", vfb->vncdisplay));
-    flexarray_append_pair(back, "vncunused", libxl__sprintf(&gc, "%d", vfb->vncunused));
-    flexarray_append_pair(back, "sdl", libxl__sprintf(&gc, "%d", vfb->sdl));
-    flexarray_append_pair(back, "opengl", libxl__sprintf(&gc, "%d", vfb->opengl));
+    flexarray_append_pair(back, "vncdisplay", libxl__sprintf(gc, "%d", vfb->vncdisplay));
+    flexarray_append_pair(back, "vncunused", libxl__sprintf(gc, "%d", vfb->vncunused));
+    flexarray_append_pair(back, "sdl", libxl__sprintf(gc, "%d", vfb->sdl));
+    flexarray_append_pair(back, "opengl", libxl__sprintf(gc, "%d", vfb->opengl));
     if (vfb->xauthority) {
         flexarray_append_pair(back, "xauthority", vfb->xauthority);
     }
@@ -1974,50 +1974,50 @@ int libxl_device_vfb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vfb *vfb)
         flexarray_append_pair(back, "display", vfb->display);
     }
 
-    flexarray_append_pair(front, "backend-id", libxl__sprintf(&gc, "%d", vfb->backend_domid));
-    flexarray_append_pair(front, "state", libxl__sprintf(&gc, "%d", 1));
+    flexarray_append_pair(front, "backend-id", libxl__sprintf(gc, "%d", vfb->backend_domid));
+    flexarray_append_pair(front, "state", libxl__sprintf(gc, "%d", 1));
 
-    libxl__device_generic_add(&gc, &device,
-                             libxl__xs_kvs_of_flexarray(&gc, back, back->count),
-                             libxl__xs_kvs_of_flexarray(&gc, front, front->count));
+    libxl__device_generic_add(gc, &device,
+                             libxl__xs_kvs_of_flexarray(gc, back, back->count),
+                             libxl__xs_kvs_of_flexarray(gc, front, front->count));
     rc = 0;
 out_free:
     flexarray_free(front);
     flexarray_free(back);
 out:
-    libxl__free_all(&gc);
+    GC_FREE;
     return rc;
 }
 
 int libxl_device_vfb_remove(libxl_ctx *ctx, uint32_t domid,
                             libxl_device_vfb *vfb)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     libxl__device device;
     int rc;
 
-    rc = libxl__device_from_vfb(&gc, domid, vfb, &device);
+    rc = libxl__device_from_vfb(gc, domid, vfb, &device);
     if (rc != 0) goto out;
 
-    rc = libxl__device_remove(&gc, &device, 1);
+    rc = libxl__device_remove(gc, &device, 1);
 out:
-    libxl__free_all(&gc);
+    GC_FREE;
     return rc;
 }
 
 int libxl_device_vfb_destroy(libxl_ctx *ctx, uint32_t domid,
                                   libxl_device_vfb *vfb)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     libxl__device device;
     int rc;
 
-    rc = libxl__device_from_vfb(&gc, domid, vfb, &device);
+    rc = libxl__device_from_vfb(gc, domid, vfb, &device);
     if (rc != 0) goto out;
 
-    rc = libxl__device_destroy(&gc, &device);
+    rc = libxl__device_destroy(gc, &device);
 out:
-    libxl__free_all(&gc);
+    GC_FREE;
     return rc;
 }
 
@@ -2025,13 +2025,13 @@ out:
 
 int libxl_domain_setmaxmem(libxl_ctx *ctx, uint32_t domid, uint32_t max_memkb)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     char *mem, *endptr;
     uint32_t memorykb;
-    char *dompath = libxl__xs_get_dompath(&gc, domid);
+    char *dompath = libxl__xs_get_dompath(gc, domid);
     int rc = 1;
 
-    mem = libxl__xs_read(&gc, XBT_NULL, libxl__sprintf(&gc, "%s/memory/target", dompath));
+    mem = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/memory/target", dompath));
     if (!mem) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "cannot get memory info from %s/memory/target\n", dompath);
         goto out;
@@ -2056,7 +2056,7 @@ int libxl_domain_setmaxmem(libxl_ctx *ctx, uint32_t domid, uint32_t max_memkb)
 
     rc = 0;
 out:
-    libxl__free_all(&gc);
+    GC_FREE;
     return rc;
 }
 
@@ -2164,12 +2164,12 @@ retry:
 int libxl_set_memory_target(libxl_ctx *ctx, uint32_t domid,
         int32_t target_memkb, int relative, int enforce)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     int rc = 1, abort = 0;
     uint32_t memorykb = 0, videoram = 0;
     uint32_t current_target_memkb = 0, new_target_memkb = 0;
     char *memmax, *endptr, *videoram_s = NULL, *target = NULL;
-    char *dompath = libxl__xs_get_dompath(&gc, domid);
+    char *dompath = libxl__xs_get_dompath(gc, domid);
     xc_domaininfo_t info;
     libxl_dominfo ptr;
     char *uuid;
@@ -2178,11 +2178,11 @@ int libxl_set_memory_target(libxl_ctx *ctx, uint32_t domid,
 retry_transaction:
     t = xs_transaction_start(ctx->xsh);
 
-    target = libxl__xs_read(&gc, t, libxl__sprintf(&gc,
+    target = libxl__xs_read(gc, t, libxl__sprintf(gc,
                 "%s/memory/target", dompath));
     if (!target && !domid) {
         xs_transaction_end(ctx->xsh, t, 1);
-        rc = libxl__fill_dom0_memory_info(&gc, &current_target_memkb);
+        rc = libxl__fill_dom0_memory_info(gc, &current_target_memkb);
         if (rc < 0) {
             abort = 1;
             goto out;
@@ -2204,7 +2204,7 @@ retry_transaction:
             goto out;
         }
     }
-    memmax = libxl__xs_read(&gc, t, libxl__sprintf(&gc,
+    memmax = libxl__xs_read(gc, t, libxl__sprintf(gc,
                 "%s/memory/static-max", dompath));
     if (!memmax) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
@@ -2244,7 +2244,7 @@ retry_transaction:
         abort = 1;
         goto out;
     }
-    videoram_s = libxl__xs_read(&gc, t, libxl__sprintf(&gc,
+    videoram_s = libxl__xs_read(gc, t, libxl__sprintf(gc,
                 "%s/memory/videoram", dompath));
     videoram = videoram_s ? atoi(videoram_s) : 0;
 
@@ -2273,7 +2273,7 @@ retry_transaction:
         goto out;
     }
 
-    libxl__xs_write(&gc, t, libxl__sprintf(&gc, "%s/memory/target",
+    libxl__xs_write(gc, t, libxl__sprintf(gc, "%s/memory/target",
                 dompath), "%"PRIu32, new_target_memkb);
     rc = xc_domain_getinfolist(ctx->xch, domid, 1, &info);
     if (rc != 1 || info.domain != domid) {
@@ -2281,8 +2281,8 @@ retry_transaction:
         goto out;
     }
     xcinfo2xlinfo(&info, &ptr);
-    uuid = libxl__uuid2string(&gc, ptr.uuid);
-    libxl__xs_write(&gc, t, libxl__sprintf(&gc, "/vm/%s/memory", uuid),
+    uuid = libxl__uuid2string(gc, ptr.uuid);
+    libxl__xs_write(gc, t, libxl__sprintf(gc, "/vm/%s/memory", uuid),
             "%"PRIu32, new_target_memkb / 1024);
 
 out:
@@ -2290,22 +2290,22 @@ out:
         if (errno == EAGAIN)
             goto retry_transaction;
 
-    libxl__free_all(&gc);
+    GC_FREE;
     return rc;
 }
 
 int libxl_get_memory_target(libxl_ctx *ctx, uint32_t domid, uint32_t *out_target)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     int rc = 1;
     char *target = NULL, *endptr = NULL;
-    char *dompath = libxl__xs_get_dompath(&gc, domid);
+    char *dompath = libxl__xs_get_dompath(gc, domid);
     uint32_t target_memkb;
 
-    target = libxl__xs_read(&gc, XBT_NULL, libxl__sprintf(&gc,
+    target = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc,
                 "%s/memory/target", dompath));
     if (!target && !domid) {
-        rc = libxl__fill_dom0_memory_info(&gc, &target_memkb);
+        rc = libxl__fill_dom0_memory_info(gc, &target_memkb);
         if (rc < 0)
             goto out;
     } else if (!target) {
@@ -2326,14 +2326,14 @@ int libxl_get_memory_target(libxl_ctx *ctx, uint32_t domid, uint32_t *out_target
     rc = 0;
 
 out:
-    libxl__free_all(&gc);
+    GC_FREE;
     return rc;
 }
 
 int libxl_domain_need_memory(libxl_ctx *ctx, libxl_domain_build_info *b_info,
         libxl_device_model_info *dm_info, uint32_t *need_memkb)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     int rc = ERROR_INVAL;
     *need_memkb = b_info->target_memkb;
     switch (b_info->type) {
@@ -2352,7 +2352,7 @@ int libxl_domain_need_memory(libxl_ctx *ctx, libxl_domain_build_info *b_info,
         *need_memkb += (2 * 1024) - (*need_memkb % (2 * 1024));
     rc = 0;
 out:
-    libxl__free_all(&gc);
+    GC_FREE;
     return rc;
 
 }
@@ -2362,12 +2362,12 @@ int libxl_get_free_memory(libxl_ctx *ctx, uint32_t *memkb)
     int rc = 0;
     libxl_physinfo info;
     uint32_t freemem_slack;
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
 
     rc = libxl_get_physinfo(ctx, &info);
     if (rc < 0)
         goto out;
-    rc = libxl__get_free_memory_slack(&gc, &freemem_slack);
+    rc = libxl__get_free_memory_slack(gc, &freemem_slack);
     if (rc < 0)
         goto out;
 
@@ -2377,7 +2377,7 @@ int libxl_get_free_memory(libxl_ctx *ctx, uint32_t *memkb)
         *memkb = 0;
 
 out:
-    libxl__free_all(&gc);
+    GC_FREE;
     return rc;
 }
 
@@ -2387,9 +2387,9 @@ int libxl_wait_for_free_memory(libxl_ctx *ctx, uint32_t domid, uint32_t
     int rc = 0;
     libxl_physinfo info;
     uint32_t freemem_slack;
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
 
-    rc = libxl__get_free_memory_slack(&gc, &freemem_slack);
+    rc = libxl__get_free_memory_slack(gc, &freemem_slack);
     if (rc < 0)
         goto out;
     while (wait_secs > 0) {
@@ -2406,7 +2406,7 @@ int libxl_wait_for_free_memory(libxl_ctx *ctx, uint32_t domid, uint32_t
     rc = ERROR_NOMEM;
 
 out:
-    libxl__free_all(&gc);
+    GC_FREE;
     return rc;
 }
 
@@ -2632,7 +2632,7 @@ int libxl_set_vcpuaffinity(libxl_ctx *ctx, uint32_t domid, uint32_t vcpuid,
 
 int libxl_set_vcpuonline(libxl_ctx *ctx, uint32_t domid, libxl_cpumap *cpumap)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     libxl_dominfo info;
     char *dompath;
     xs_transaction_t t;
@@ -2642,14 +2642,14 @@ int libxl_set_vcpuonline(libxl_ctx *ctx, uint32_t domid, libxl_cpumap *cpumap)
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "getting domain info list");
         goto out;
     }
-    if (!(dompath = libxl__xs_get_dompath(&gc, domid)))
+    if (!(dompath = libxl__xs_get_dompath(gc, domid)))
         goto out;
 
 retry_transaction:
     t = xs_transaction_start(ctx->xsh);
     for (i = 0; i <= info.vcpu_max_id; i++)
-        libxl__xs_write(&gc, t,
-                       libxl__sprintf(&gc, "%s/cpu/%u/availability", dompath, i),
+        libxl__xs_write(gc, t,
+                       libxl__sprintf(gc, "%s/cpu/%u/availability", dompath, i),
                        "%s", libxl_cpumap_test(cpumap, i) ? "online" : "offline");
     if (!xs_transaction_end(ctx->xsh, t, 0)) {
         if (errno == EAGAIN)
@@ -2657,7 +2657,7 @@ retry_transaction:
     } else
         rc = 0;
 out:
-    libxl__free_all(&gc);
+    GC_FREE;
     return rc;
 }
 
@@ -2777,12 +2777,12 @@ int libxl_send_trigger(libxl_ctx *ctx, uint32_t domid, char *trigger_name, uint3
 
 int libxl_send_sysrq(libxl_ctx *ctx, uint32_t domid, char sysrq)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
-    char *dompath = libxl__xs_get_dompath(&gc, domid);
+    GC_INIT(ctx);
+    char *dompath = libxl__xs_get_dompath(gc, domid);
 
-    libxl__xs_write(&gc, XBT_NULL, libxl__sprintf(&gc, "%s/control/sysrq", dompath), "%c", sysrq);
+    libxl__xs_write(gc, XBT_NULL, libxl__sprintf(gc, "%s/control/sysrq", dompath), "%c", sysrq);
 
-    libxl__free_all(&gc);
+    GC_FREE;
     return 0;
 }
 
@@ -2869,15 +2869,15 @@ void libxl_xen_console_read_finish(libxl_ctx *ctx,
 
 uint32_t libxl_vm_get_start_time(libxl_ctx *ctx, uint32_t domid)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
-    char *dompath = libxl__xs_get_dompath(&gc, domid);
+    GC_INIT(ctx);
+    char *dompath = libxl__xs_get_dompath(gc, domid);
     char *vm_path, *start_time;
     uint32_t ret;
 
     vm_path = libxl__xs_read(
-        &gc, XBT_NULL, libxl__sprintf(&gc, "%s/vm", dompath));
+        gc, XBT_NULL, libxl__sprintf(gc, "%s/vm", dompath));
     start_time = libxl__xs_read(
-        &gc, XBT_NULL, libxl__sprintf(&gc, "%s/start_time", vm_path));
+        gc, XBT_NULL, libxl__sprintf(gc, "%s/start_time", vm_path));
     if (start_time == NULL) {
         LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, -1,
                         "Can't get start time of domain '%d'", domid);
@@ -2885,7 +2885,7 @@ uint32_t libxl_vm_get_start_time(libxl_ctx *ctx, uint32_t domid)
     }else{
         ret = strtoul(start_time, NULL, 10);
     }
-    libxl__free_all(&gc);
+    GC_FREE;
     return ret;
 }
 
@@ -3038,15 +3038,15 @@ int libxl_create_cpupool(libxl_ctx *ctx, const char *name, int schedid,
                          libxl_cpumap cpumap, libxl_uuid *uuid,
                          uint32_t *poolid)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     int rc;
     int i;
     xs_transaction_t t;
     char *uuid_string;
 
-    uuid_string = libxl__uuid2string(&gc, *uuid);
+    uuid_string = libxl__uuid2string(gc, *uuid);
     if (!uuid_string) {
-        libxl__free_all(&gc);
+        GC_FREE;
         return ERROR_NOMEM;
     }
 
@@ -3054,7 +3054,7 @@ int libxl_create_cpupool(libxl_ctx *ctx, const char *name, int schedid,
     if (rc) {
         LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, rc,
            "Could not create cpupool");
-        libxl__free_all(&gc);
+        GC_FREE;
         return ERROR_FAIL;
     }
 
@@ -3065,7 +3065,7 @@ int libxl_create_cpupool(libxl_ctx *ctx, const char *name, int schedid,
                 LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, rc,
                     "Error moving cpu to cpupool");
                 libxl_cpupool_destroy(ctx, *poolid);
-                libxl__free_all(&gc);
+                GC_FREE;
                 return ERROR_FAIL;
             }
         }
@@ -3073,16 +3073,16 @@ int libxl_create_cpupool(libxl_ctx *ctx, const char *name, int schedid,
     for (;;) {
         t = xs_transaction_start(ctx->xsh);
 
-        xs_mkdir(ctx->xsh, t, libxl__sprintf(&gc, "/local/pool/%d", *poolid));
-        libxl__xs_write(&gc, t,
-                        libxl__sprintf(&gc, "/local/pool/%d/uuid", *poolid),
+        xs_mkdir(ctx->xsh, t, libxl__sprintf(gc, "/local/pool/%d", *poolid));
+        libxl__xs_write(gc, t,
+                        libxl__sprintf(gc, "/local/pool/%d/uuid", *poolid),
                         "%s", uuid_string);
-        libxl__xs_write(&gc, t,
-                        libxl__sprintf(&gc, "/local/pool/%d/name", *poolid),
+        libxl__xs_write(gc, t,
+                        libxl__sprintf(gc, "/local/pool/%d/name", *poolid),
                         "%s", name);
 
         if (xs_transaction_end(ctx->xsh, t, 0) || (errno != EAGAIN)) {
-            libxl__free_all(&gc);
+            GC_FREE;
             return 0;
         }
     }
@@ -3090,7 +3090,7 @@ int libxl_create_cpupool(libxl_ctx *ctx, const char *name, int schedid,
 
 int libxl_cpupool_destroy(libxl_ctx *ctx, uint32_t poolid)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     int rc, i;
     xc_cpupoolinfo_t *info;
     xs_transaction_t t;
@@ -3098,7 +3098,7 @@ int libxl_cpupool_destroy(libxl_ctx *ctx, uint32_t poolid)
 
     info = xc_cpupool_getinfo(ctx->xch, poolid);
     if (info == NULL) {
-        libxl__free_all(&gc);
+        GC_FREE;
         return ERROR_NOMEM;
     }
 
@@ -3132,7 +3132,7 @@ int libxl_cpupool_destroy(libxl_ctx *ctx, uint32_t poolid)
     for (;;) {
         t = xs_transaction_start(ctx->xsh);
 
-        xs_rm(ctx->xsh, XBT_NULL, libxl__sprintf(&gc, "/local/pool/%d", poolid));
+        xs_rm(ctx->xsh, XBT_NULL, libxl__sprintf(gc, "/local/pool/%d", poolid));
 
         if (xs_transaction_end(ctx->xsh, t, 0) || (errno != EAGAIN))
             break;
@@ -3144,21 +3144,21 @@ out1:
     libxl_cpumap_dispose(&cpumap);
 out:
     xc_cpupool_infofree(ctx->xch, info);
-    libxl__free_all(&gc);
+    GC_FREE;
 
     return rc;
 }
 
 int libxl_cpupool_rename(libxl_ctx *ctx, const char *name, uint32_t poolid)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     xs_transaction_t t;
     xc_cpupoolinfo_t *info;
     int rc;
 
     info = xc_cpupool_getinfo(ctx->xch, poolid);
     if (info == NULL) {
-        libxl__free_all(&gc);
+        GC_FREE;
         return ERROR_NOMEM;
     }
 
@@ -3171,8 +3171,8 @@ int libxl_cpupool_rename(libxl_ctx *ctx, const char *name, uint32_t poolid)
     for (;;) {
         t = xs_transaction_start(ctx->xsh);
 
-        libxl__xs_write(&gc, t,
-                        libxl__sprintf(&gc, "/local/pool/%d/name", poolid),
+        libxl__xs_write(gc, t,
+                        libxl__sprintf(gc, "/local/pool/%d/name", poolid),
                         "%s", name);
 
         if (xs_transaction_end(ctx->xsh, t, 0))
@@ -3187,7 +3187,7 @@ int libxl_cpupool_rename(libxl_ctx *ctx, const char *name, uint32_t poolid)
 
 out:
     xc_cpupool_infofree(ctx->xch, info);
-    libxl__free_all(&gc);
+    GC_FREE;
 
     return rc;
 }
@@ -3294,16 +3294,16 @@ out:
 
 int libxl_cpupool_movedomain(libxl_ctx *ctx, uint32_t poolid, uint32_t domid)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     int rc;
     char *dom_path;
     char *vm_path;
     char *poolname;
     xs_transaction_t t;
 
-    dom_path = libxl__xs_get_dompath(&gc, domid);
+    dom_path = libxl__xs_get_dompath(gc, domid);
     if (!dom_path) {
-        libxl__free_all(&gc);
+        GC_FREE;
         return ERROR_FAIL;
     }
 
@@ -3311,26 +3311,26 @@ int libxl_cpupool_movedomain(libxl_ctx *ctx, uint32_t poolid, uint32_t domid)
     if (rc) {
         LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, rc,
             "Error moving domain to cpupool");
-        libxl__free_all(&gc);
+        GC_FREE;
         return ERROR_FAIL;
     }
 
     for (;;) {
         t = xs_transaction_start(ctx->xsh);
 
-        poolname = libxl__cpupoolid_to_name(&gc, poolid);
-        vm_path = libxl__xs_read(&gc, XBT_NULL, libxl__sprintf(&gc, "%s/vm", dom_path));
+        poolname = libxl__cpupoolid_to_name(gc, poolid);
+        vm_path = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/vm", dom_path));
         if (!vm_path)
             break;
 
-        libxl__xs_write(&gc, t, libxl__sprintf(&gc, "%s/pool_name", vm_path),
+        libxl__xs_write(gc, t, libxl__sprintf(gc, "%s/pool_name", vm_path),
                         "%s", poolname);
 
         if (xs_transaction_end(ctx->xsh, t, 0) || (errno != EAGAIN))
             break;
     }
 
-    libxl__free_all(&gc);
+    GC_FREE;
     return 0;
 }
 
diff --git a/tools/libxl/libxl_bootloader.c b/tools/libxl/libxl_bootloader.c
index b8399a1..ce83b8e 100644
--- a/tools/libxl/libxl_bootloader.c
+++ b/tools/libxl/libxl_bootloader.c
@@ -328,7 +328,7 @@ int libxl_run_bootloader(libxl_ctx *ctx,
                          libxl_device_disk *disk,
                          uint32_t domid)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     int ret, rc = 0;
     char *fifo = NULL;
     char *diskpath = NULL;
@@ -388,7 +388,7 @@ int libxl_run_bootloader(libxl_ctx *ctx,
         goto out_close;
     }
 
-    args = make_bootloader_args(&gc, info, domid, fifo, diskpath);
+    args = make_bootloader_args(gc, info, domid, fifo, diskpath);
     if (args == NULL) {
         rc = ERROR_NOMEM;
         goto out_close;
@@ -411,8 +411,8 @@ int libxl_run_bootloader(libxl_ctx *ctx,
         goto out_close;
     }
 
-    dom_console_xs_path = libxl__sprintf(&gc, "%s/console/tty", libxl__xs_get_dompath(&gc, domid));
-    libxl__xs_write(&gc, XBT_NULL, dom_console_xs_path, "%s", dom_console_slave_tty_path);
+    dom_console_xs_path = libxl__sprintf(gc, "%s/console/tty", libxl__xs_get_dompath(gc, domid));
+    libxl__xs_write(gc, XBT_NULL, dom_console_xs_path, "%s", dom_console_slave_tty_path);
 
     pid = fork_exec_bootloader(&bootloader_fd, info->u.pv.bootloader, args);
     if (pid < 0) {
@@ -435,7 +435,7 @@ int libxl_run_bootloader(libxl_ctx *ctx,
 
     fcntl(fifo_fd, F_SETFL, O_NDELAY);
 
-    blout = bootloader_interact(&gc, xenconsoled_fd, bootloader_fd, fifo_fd);
+    blout = bootloader_interact(gc, xenconsoled_fd, bootloader_fd, fifo_fd);
     if (blout == NULL) {
         goto out_close;
     }
@@ -445,7 +445,7 @@ int libxl_run_bootloader(libxl_ctx *ctx,
         goto out_close;
     }
 
-    parse_bootloader_result(&gc, info, blout);
+    parse_bootloader_result(gc, info, blout);
 
     rc = 0;
 out_close:
@@ -472,7 +472,7 @@ out_close:
     free(args);
 
 out:
-    libxl__free_all(&gc);
+    GC_FREE;
     return rc;
 }
 
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index ccb56c7..69f10fe 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -670,20 +670,20 @@ error_out:
 int libxl_domain_create_new(libxl_ctx *ctx, libxl_domain_config *d_config,
                             libxl_console_ready cb, void *priv, uint32_t *domid)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     int rc;
-    rc = do_domain_create(&gc, d_config, cb, priv, domid, -1);
-    libxl__free_all(&gc);
+    rc = do_domain_create(gc, d_config, cb, priv, domid, -1);
+    GC_FREE;
     return rc;
 }
 
 int libxl_domain_create_restore(libxl_ctx *ctx, libxl_domain_config *d_config,
                                 libxl_console_ready cb, void *priv, uint32_t *domid, int restore_fd)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     int rc;
-    rc = do_domain_create(&gc, d_config, cb, priv, domid, restore_fd);
-    libxl__free_all(&gc);
+    rc = do_domain_create(gc, d_config, cb, priv, domid, restore_fd);
+    GC_FREE;
     return rc;
 }
 
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 96098de..b1ff967 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -730,7 +730,7 @@ int libxl_userdata_store(libxl_ctx *ctx, uint32_t domid,
                               const char *userdata_userid,
                               const uint8_t *data, int datalen)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     const char *filename;
     const char *newfilename;
     int e, rc;
@@ -738,18 +738,18 @@ int libxl_userdata_store(libxl_ctx *ctx, uint32_t domid,
     FILE *f = NULL;
     size_t rs;
 
-    filename = userdata_path(&gc, domid, userdata_userid, "d");
+    filename = userdata_path(gc, domid, userdata_userid, "d");
     if (!filename) {
         rc = ERROR_NOMEM;
         goto out;
     }
 
     if (!datalen) {
-        rc = userdata_delete(&gc, filename);
+        rc = userdata_delete(gc, filename);
         goto out;
     }
 
-    newfilename = userdata_path(&gc, domid, userdata_userid, "n");
+    newfilename = userdata_path(gc, domid, userdata_userid, "n");
     if (!newfilename) {
         rc = ERROR_NOMEM;
         goto out;
@@ -791,7 +791,7 @@ err:
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "cannot write %s for %s",
                  newfilename, filename);
 out:
-    libxl__free_all(&gc);
+    GC_FREE;
     return rc;
 }
 
@@ -799,13 +799,13 @@ int libxl_userdata_retrieve(libxl_ctx *ctx, uint32_t domid,
                                  const char *userdata_userid,
                                  uint8_t **data_r, int *datalen_r)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     const char *filename;
     int e, rc;
     int datalen = 0;
     void *data = 0;
 
-    filename = userdata_path(&gc, domid, userdata_userid, "d");
+    filename = userdata_path(gc, domid, userdata_userid, "d");
     if (!filename) {
         rc = ERROR_NOMEM;
         goto out;
@@ -827,7 +827,7 @@ int libxl_userdata_retrieve(libxl_ctx *ctx, uint32_t domid,
     if (datalen_r) *datalen_r = datalen;
     rc = 0;
 out:
-    libxl__free_all(&gc);
+    GC_FREE;
     return rc;
 }
 
diff --git a/tools/libxl/libxl_pci.c b/tools/libxl/libxl_pci.c
index 63c3050..120c239 100644
--- a/tools/libxl/libxl_pci.c
+++ b/tools/libxl/libxl_pci.c
@@ -483,7 +483,7 @@ static int is_assigned(libxl_device_pci *assigned, int num_assigned,
 
 libxl_device_pci *libxl_device_pci_list_assignable(libxl_ctx *ctx, int *num)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     libxl_device_pci *pcidevs = NULL, *new, *assigned;
     struct dirent *de;
     DIR *dir;
@@ -491,7 +491,7 @@ libxl_device_pci *libxl_device_pci_list_assignable(libxl_ctx *ctx, int *num)
 
     *num = 0;
 
-    rc = get_all_assigned_devices(&gc, &assigned, &num_assigned);
+    rc = get_all_assigned_devices(gc, &assigned, &num_assigned);
     if ( rc )
         goto out;
 
@@ -528,7 +528,7 @@ libxl_device_pci *libxl_device_pci_list_assignable(libxl_ctx *ctx, int *num)
 out_closedir:
     closedir(dir);
 out:
-    libxl__free_all(&gc);
+    GC_FREE;
     return pcidevs;
 }
 
@@ -782,10 +782,10 @@ static int libxl__device_pci_reset(libxl__gc *gc, unsigned int domain, unsigned
 
 int libxl_device_pci_add(libxl_ctx *ctx, uint32_t domid, libxl_device_pci *pcidev)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     int rc;
-    rc = libxl__device_pci_add(&gc, domid, pcidev, 0);
-    libxl__free_all(&gc);
+    rc = libxl__device_pci_add(gc, domid, pcidev, 0);
+    GC_FREE;
     return rc;
 }
 
@@ -1057,24 +1057,24 @@ out:
 
 int libxl_device_pci_remove(libxl_ctx *ctx, uint32_t domid, libxl_device_pci *pcidev)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     int rc;
 
-    rc = libxl__device_pci_remove_common(&gc, domid, pcidev, 0);
+    rc = libxl__device_pci_remove_common(gc, domid, pcidev, 0);
 
-    libxl__free_all(&gc);
+    GC_FREE;
     return rc;
 }
 
 int libxl_device_pci_destroy(libxl_ctx *ctx, uint32_t domid,
                                   libxl_device_pci *pcidev)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     int rc;
 
-    rc = libxl__device_pci_remove_common(&gc, domid, pcidev, 1);
+    rc = libxl__device_pci_remove_common(gc, domid, pcidev, 1);
 
-    libxl__free_all(&gc);
+    GC_FREE;
     return rc;
 }
 
@@ -1115,15 +1115,15 @@ static void libxl__device_pci_from_xs_be(libxl__gc *gc,
 
 libxl_device_pci *libxl_device_pci_list(libxl_ctx *ctx, uint32_t domid, int *num)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     char *be_path, *num_devs;
     int n, i;
     libxl_device_pci *pcidevs = NULL;
 
     *num = 0;
 
-    be_path = libxl__sprintf(&gc, "%s/backend/pci/%d/0", libxl__xs_get_dompath(&gc, 0), domid);
-    num_devs = libxl__xs_read(&gc, XBT_NULL, libxl__sprintf(&gc, "%s/num_devs", be_path));
+    be_path = libxl__sprintf(gc, "%s/backend/pci/%d/0", libxl__xs_get_dompath(gc, 0), domid);
+    num_devs = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/num_devs", be_path));
     if (!num_devs)
         goto out;
 
@@ -1131,11 +1131,11 @@ libxl_device_pci *libxl_device_pci_list(libxl_ctx *ctx, uint32_t domid, int *num
     pcidevs = calloc(n, sizeof(libxl_device_pci));
 
     for (i = 0; i < n; i++)
-        libxl__device_pci_from_xs_be(&gc, be_path, pcidevs + i, i);
+        libxl__device_pci_from_xs_be(gc, be_path, pcidevs + i, i);
 
     *num = n;
 out:
-    libxl__free_all(&gc);
+    GC_FREE;
     return pcidevs;
 }
 
diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
index c7696d7..60af98c 100644
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/libxl/libxl_qmp.c
@@ -94,7 +94,7 @@ static int store_serial_port_info(libxl__qmp_handler *qmp,
                                   const char *chardev,
                                   int port)
 {
-    libxl__gc gc = LIBXL_INIT_GC(qmp->ctx);
+    GC_INIT(qmp->ctx);
     char *path = NULL;
     int ret = 0;
 
@@ -102,12 +102,12 @@ static int store_serial_port_info(libxl__qmp_handler *qmp,
         return 0;
     }
 
-    path = libxl__xs_get_dompath(&gc, qmp->domid);
-    path = libxl__sprintf(&gc, "%s/serial/%d/tty", path, port);
+    path = libxl__xs_get_dompath(gc, qmp->domid);
+    path = libxl__sprintf(gc, "%s/serial/%d/tty", path, port);
 
-    ret = libxl__xs_write(&gc, XBT_NULL, path, "%s", chardev + 4);
+    ret = libxl__xs_write(gc, XBT_NULL, path, "%s", chardev + 4);
 
-    libxl__free_all(&gc);
+    GC_FREE;
     return ret;
 }
 
@@ -521,7 +521,7 @@ static int qmp_synchronous_send(libxl__qmp_handler *qmp, const char *cmd,
 {
     int id = 0;
     int ret = 0;
-    libxl__gc gc = LIBXL_INIT_GC(qmp->ctx);
+    GC_INIT(qmp->ctx);
     qmp_request_context context = { .rc = 0 };
 
     id = qmp_send(qmp, cmd, args, callback, opaque, &context);
@@ -531,7 +531,7 @@ static int qmp_synchronous_send(libxl__qmp_handler *qmp, const char *cmd,
     qmp->wait_for_id = id;
 
     while (qmp->wait_for_id == id) {
-        if ((ret = qmp_next(&gc, qmp)) < 0) {
+        if ((ret = qmp_next(gc, qmp)) < 0) {
             break;
         }
     }
@@ -540,7 +540,7 @@ static int qmp_synchronous_send(libxl__qmp_handler *qmp, const char *cmd,
         ret = context.rc;
     }
 
-    libxl__free_all(&gc);
+    GC_FREE;
 
     return ret;
 }
@@ -559,15 +559,15 @@ libxl__qmp_handler *libxl__qmp_initialize(libxl_ctx *ctx, uint32_t domid)
     int ret = 0;
     libxl__qmp_handler *qmp = NULL;
     char *qmp_socket;
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
 
     qmp = qmp_init_handler(ctx, domid);
 
-    qmp_socket = libxl__sprintf(&gc, "%s/qmp-libxl-%d",
+    qmp_socket = libxl__sprintf(gc, "%s/qmp-libxl-%d",
                                 libxl_run_dir_path(), domid);
     if ((ret = qmp_open(qmp, qmp_socket, QMP_SOCKET_CONNECT_TIMEOUT)) < 0) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "Connection error");
-        libxl__free_all(&gc);
+        GC_FREE;
         qmp_free_handler(qmp);
         return NULL;
     }
@@ -576,12 +576,12 @@ libxl__qmp_handler *libxl__qmp_initialize(libxl_ctx *ctx, uint32_t domid)
 
     /* Wait for the response to qmp_capabilities */
     while (!qmp->connected) {
-        if ((ret = qmp_next(&gc, qmp)) < 0) {
+        if ((ret = qmp_next(gc, qmp)) < 0) {
             break;
         }
     }
 
-    libxl__free_all(&gc);
+    GC_FREE;
     if (!qmp->connected) {
         LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Failed to connect to QMP");
         libxl__qmp_close(qmp);
@@ -626,9 +626,9 @@ static int pci_add_callback(libxl__qmp_handler *qmp,
 {
     libxl_device_pci *pcidev = opaque;
     const libxl__json_object *bus = NULL;
-    libxl__gc gc = LIBXL_INIT_GC(qmp->ctx);
+    GC_INIT(qmp->ctx);
     int i, j, rc = -1;
-    char *asked_id = libxl__sprintf(&gc, PCI_PT_QDEV_ID,
+    char *asked_id = libxl__sprintf(gc, PCI_PT_QDEV_ID,
                                     pcidev->bus, pcidev->dev, pcidev->func);
 
     for (i = 0; (bus = libxl__json_array_get(response, i)); i++) {
@@ -665,7 +665,7 @@ static int pci_add_callback(libxl__qmp_handler *qmp,
 
 
 out:
-    libxl__free_all(&gc);
+    GC_FREE;
     return rc;
 }
 
diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
index f1f2a6d..d36c737 100644
--- a/tools/libxl/libxl_utils.c
+++ b/tools/libxl/libxl_utils.c
@@ -186,29 +186,29 @@ char *libxl_schedid_to_name(libxl_ctx *ctx, int schedid)
 
 int libxl_get_stubdom_id(libxl_ctx *ctx, int guest_domid)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     char * stubdom_id_s;
     int ret;
 
-    stubdom_id_s = libxl__xs_read(&gc, XBT_NULL,
-                                 libxl__sprintf(&gc, "%s/image/device-model-domid",
-                                               libxl__xs_get_dompath(&gc, guest_domid)));
+    stubdom_id_s = libxl__xs_read(gc, XBT_NULL,
+                                 libxl__sprintf(gc, "%s/image/device-model-domid",
+                                               libxl__xs_get_dompath(gc, guest_domid)));
     if (stubdom_id_s)
         ret = atoi(stubdom_id_s);
     else
         ret = 0;
-    libxl__free_all(&gc);
+    GC_FREE;
     return ret;
 }
 
 int libxl_is_stubdom(libxl_ctx *ctx, uint32_t domid, uint32_t *target_domid)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     char *target, *endptr;
     uint32_t value;
     int ret = 0;
 
-    target = libxl__xs_read(&gc, XBT_NULL, libxl__sprintf(&gc, "%s/target", libxl__xs_get_dompath(&gc, domid)));
+    target = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/target", libxl__xs_get_dompath(gc, domid)));
     if (!target)
         goto out;
     value = strtol(target, &endptr, 10);
@@ -218,7 +218,7 @@ int libxl_is_stubdom(libxl_ctx *ctx, uint32_t domid, uint32_t *target_domid)
         *target_domid = value;
     ret = 1;
 out:
-    libxl__free_all(&gc);
+    GC_FREE;
     return ret;
 }
 
@@ -240,27 +240,27 @@ static int logrename(libxl__gc *gc, const char *old, const char *new)
 
 int libxl_create_logfile(libxl_ctx *ctx, char *name, char **full_name)
 {
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
+    GC_INIT(ctx);
     struct stat stat_buf;
     char *logfile, *logfile_new;
     int i, rc;
 
-    logfile = libxl__sprintf(&gc, "/var/log/xen/%s.log", name);
+    logfile = libxl__sprintf(gc, "/var/log/xen/%s.log", name);
     if (stat(logfile, &stat_buf) == 0) {
         /* file exists, rotate */
-        logfile = libxl__sprintf(&gc, "/var/log/xen/%s.log.10", name);
+        logfile = libxl__sprintf(gc, "/var/log/xen/%s.log.10", name);
         unlink(logfile);
         for (i = 9; i > 0; i--) {
-            logfile = libxl__sprintf(&gc, "/var/log/xen/%s.log.%d", name, i);
-            logfile_new = libxl__sprintf(&gc, "/var/log/xen/%s.log.%d", name, i + 1);
-            rc = logrename(&gc, logfile, logfile_new);
+            logfile = libxl__sprintf(gc, "/var/log/xen/%s.log.%d", name, i);
+            logfile_new = libxl__sprintf(gc, "/var/log/xen/%s.log.%d", name, i + 1);
+            rc = logrename(gc, logfile, logfile_new);
             if (rc)
                 goto out;
         }
-        logfile = libxl__sprintf(&gc, "/var/log/xen/%s.log", name);
-        logfile_new = libxl__sprintf(&gc, "/var/log/xen/%s.log.1", name);
+        logfile = libxl__sprintf(gc, "/var/log/xen/%s.log", name);
+        logfile_new = libxl__sprintf(gc, "/var/log/xen/%s.log.1", name);
 
-        rc = logrename(&gc, logfile, logfile_new);
+        rc = logrename(gc, logfile, logfile_new);
         if (rc)
             goto out;
     } else {
@@ -272,7 +272,7 @@ int libxl_create_logfile(libxl_ctx *ctx, char *name, char **full_name)
     *full_name = strdup(logfile);
     rc = 0;
 out:
-    libxl__free_all(&gc);
+    GC_FREE;
     return rc;
 }
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 18:55:51 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 18: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.xensource.com>)
	id 1RZ5bj-0001Jz-6t; Fri, 09 Dec 2011 18:55:43 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RZ5bg-0001C3-SG
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 18:55:41 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1323456890!5661081!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI2MQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15635 invoked from network); 9 Dec 2011 18:54:51 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 18:54:51 -0000
X-IronPort-AV: E=Sophos;i="4.71,327,1320624000"; 
   d="scan'208";a="9392209"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 18:54:50 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 18:54:50 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RZ5ar-0002eZ-Ua; Fri, 09 Dec 2011 18:54:49 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RZ5ar-000411-Tg;
	Fri, 09 Dec 2011 18:54:49 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Fri, 9 Dec 2011 18:54:36 +0000
Message-ID: <1323456877-15315-18-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1323456877-15315-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1323456877-15315-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 17/18] libxl: New API for providing OS events to
	libxl
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

We provide a new set of functions and related structures
  libxl_osevent_*
which are to be used by event-driven applications to receive
information from libxl about which fds libxl is interested in, and
what timeouts libxl is waiting for, and to pass back to libxl
information about which fds are readable/writeable etc., and which
timeouts have occurred.  Ie, low-level events.

In this patch, this new machinery is still all unused.  Callers will
appear in the next patch in the series, which introduces a new API for
applications to receive high-level events about actual domains etc.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/Makefile         |    2 +-
 tools/libxl/libxl.c          |   30 ++
 tools/libxl/libxl.h          |    6 +
 tools/libxl/libxl_event.c    |  736 ++++++++++++++++++++++++++++++++++++++++++
 tools/libxl/libxl_event.h    |  200 ++++++++++++
 tools/libxl/libxl_internal.h |  219 ++++++++++++-
 6 files changed, 1189 insertions(+), 4 deletions(-)
 create mode 100644 tools/libxl/libxl_event.c
 create mode 100644 tools/libxl/libxl_event.h

diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index 70c9c1c..1084a7c 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -38,7 +38,7 @@ LIBXL_LIBS += -lyajl
 LIBXL_OBJS = flexarray.o libxl.o libxl_create.o libxl_dm.o libxl_pci.o \
 			libxl_dom.o libxl_exec.o libxl_xshelp.o libxl_device.o \
 			libxl_internal.o libxl_utils.o libxl_uuid.o libxl_json.o \
-			libxl_qmp.o $(LIBXL_OBJS-y)
+			libxl_qmp.o libxl_event.o $(LIBXL_OBJS-y)
 LIBXL_OBJS += _libxl_types.o libxl_flask.o _libxl_types_internal.o
 
 $(LIBXL_OBJS): CFLAGS += $(CFLAGS_libxenctrl) $(CFLAGS_libxenguest) $(CFLAGS_libxenstore) $(CFLAGS_libblktapctl)
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 79ea701..23a7539 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -60,6 +60,16 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
      * only as an initialiser, not as an expression. */
     memcpy(&ctx->lock, &mutex_value, sizeof(ctx->lock));
 
+    ctx->osevent_hooks = 0;
+
+    ctx->fd_beforepolled = 0;
+    LIBXL_LIST_INIT(&ctx->efds);
+    LIBXL_TAILQ_INIT(&ctx->etimes);
+
+    ctx->watch_slots = 0;
+    LIBXL_SLIST_INIT(&ctx->watch_freeslots);
+    libxl__ev_fd_init(&ctx->watch_efd);
+
     if ( stat(XENSTORE_PID_FILE, &stat_buf) != 0 ) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "Is xenstore daemon running?\n"
                      "failed to stat %s", XENSTORE_PID_FILE);
@@ -90,9 +100,29 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
 int libxl_ctx_free(libxl_ctx *ctx)
 {
     if (!ctx) return 0;
+
+    int i;
+    GC_INIT(ctx);
+
+    /* Deregister all libxl__ev_KINDs: */
+
+    for (i = 0; i < ctx->watch_nslots; i++)
+        assert(!libxl__watch_slot_contents(gc, i));
+    libxl__ev_fd_deregister(gc, &ctx->watch_efd);
+
+    /* Now there should be no more events requested from the application: */
+
+    assert(LIBXL_LIST_EMPTY(&ctx->efds));
+    assert(LIBXL_TAILQ_EMPTY(&ctx->etimes));
+
     if (ctx->xch) xc_interface_close(ctx->xch);
     libxl_version_info_dispose(&ctx->version_info);
     if (ctx->xsh) xs_daemon_close(ctx->xsh);
+
+    free(ctx->fd_beforepolled);
+    free(ctx->watch_slots);
+
+    GC_FREE;
     free(ctx);
     return 0;
 }
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 9e8ca29..8d6c788 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -137,6 +137,7 @@
 #include <xen/sysctl.h>
 
 #include <libxl_uuid.h>
+#include <_libxl_list.h>
 
 typedef uint8_t libxl_mac[6];
 #define LIBXL_MAC_FMT "%02hhx:%02hhx:%02hhx:%02hhx:%02hhx:%02hhx"
@@ -222,6 +223,9 @@ enum {
     ERROR_BADFAIL = -7,
     ERROR_GUEST_TIMEDOUT = -8,
     ERROR_TIMEDOUT = -9,
+    ERROR_NOT_READY = -10,
+    ERROR_OSEVENT_REG_FAIL = -11,
+    ERROR_BUFFERFULL = -12,
 };
 
 #define LIBXL_VERSION 0
@@ -635,6 +639,8 @@ const char *libxl_lock_dir_path(void);
 const char *libxl_run_dir_path(void);
 const char *libxl_xenpaging_dir_path(void);
 
+#include <libxl_event.h>
+
 #endif /* LIBXL_H */
 
 /*
diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
new file mode 100644
index 0000000..dc6543f
--- /dev/null
+++ b/tools/libxl/libxl_event.c
@@ -0,0 +1,736 @@
+/*
+ * Copyright (C) 2011      Citrix Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU Lesser General Public License as published
+ * by the Free Software Foundation; version 2.1 only. with the special
+ * exception on linking described in file LICENSE.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU Lesser General Public License for more details.
+ */
+/*
+ * Internal event machinery for use by other parts of libxl
+ */
+
+#include <poll.h>
+
+#include "libxl_internal.h"
+
+/*
+ * The counter osevent_in_hook is used to ensure that the application
+ * honours the reentrancy restriction documented in libxl_event.h.
+ *
+ * The application's registration hooks should be called ONLY via
+ * these macros, with the ctx locked.  Likewise all the "occurred"
+ * entrypoints from the application should assert(!in_hook);
+ */
+#define OSEVENT_HOOK_INTERN(defval, hookname, ...)                      \
+    (CTX->osevent_hooks                                                 \
+     ? (CTX->osevent_in_hook++,                                         \
+        CTX->osevent_hooks->hookname(CTX->osevent_user, __VA_ARGS__),   \
+        CTX->osevent_in_hook--)                                         \
+     : defval)
+
+#define OSEVENT_HOOK(hookname,...)                      \
+    OSEVENT_HOOK_INTERN(0, hookname, __VA_ARGS__)
+
+#define OSEVENT_HOOK_VOID(hookname,...)                 \
+    OSEVENT_HOOK_INTERN((void)0, hookname, __VA_ARGS__)
+
+/*
+ * fd events
+ */
+
+int libxl__ev_fd_register(libxl__gc *gc, libxl__ev_fd *ev,
+                          libxl__ev_fd_callback *func,
+                          int fd, short events)
+{
+    int rc;
+
+    assert(fd >= 0);
+
+    CTX_LOCK;
+
+    rc = OSEVENT_HOOK(fd_register, fd, &ev->for_app_reg, events, ev);
+    if (rc) goto out;
+
+    ev->fd = fd;
+    ev->events = events;
+    ev->in_beforepolled = -1;
+    ev->func = func;
+
+    LIBXL_LIST_INSERT_HEAD(&CTX->efds, ev, entry);
+
+    rc = 0;
+
+ out:
+    CTX_UNLOCK;
+    return rc;
+}
+
+int libxl__ev_fd_modify(libxl__gc *gc, libxl__ev_fd *ev, short events)
+{
+    int rc;
+
+    CTX_LOCK;
+    assert(libxl__ev_fd_isregistered(ev));
+
+    rc = OSEVENT_HOOK(fd_modify, ev->fd, &ev->for_app_reg, events);
+    if (rc) goto out;
+
+    ev->events = events;
+
+    rc = 0;
+ out:
+    CTX_UNLOCK;
+    return rc;
+}
+
+void libxl__ev_fd_deregister(libxl__gc *gc, libxl__ev_fd *ev)
+{
+    CTX_LOCK;
+
+    if (!libxl__ev_fd_isregistered(ev))
+        goto out;
+
+    OSEVENT_HOOK_VOID(fd_deregister, ev->fd, ev->for_app_reg);
+    LIBXL_LIST_REMOVE(ev, entry);
+    ev->fd = -1;
+
+    if (ev->in_beforepolled >= 0 &&
+        ev->in_beforepolled < CTX->fd_beforepolled_used)
+        /* remove stale reference */
+        CTX->fd_beforepolled[ev->in_beforepolled] = NULL;
+
+ out:
+    CTX_UNLOCK;
+}
+
+/*
+ * timeouts
+ */
+
+
+int libxl__gettimeofday(libxl__gc *gc, struct timeval *now_r)
+{
+    int rc = gettimeofday(now_r, 0);
+    if (rc) {
+        LIBXL__LOG_ERRNO(CTX, LIBXL__LOG_ERROR, "gettimeofday failed");
+        return ERROR_FAIL;
+    }
+    return 0;
+}
+
+static int time_rel_to_abs(libxl__gc *gc, int ms, struct timeval *abs_out)
+{
+    int rc;
+    struct timeval additional = {
+        .tv_sec = ms / 1000,
+        .tv_usec = (ms % 1000) * 1000
+    };
+    struct timeval now;
+
+    rc = libxl__gettimeofday(gc, &now);
+    if (rc) return rc;
+
+    timeradd(&now, &additional, abs_out);
+    return 0;
+}
+
+static void time_insert_finite(libxl__gc *gc, libxl__ev_time *ev)
+{
+    libxl__ev_time *evsearch;
+    LIBXL_TAILQ_INSERT_SORTED(&CTX->etimes, entry, ev, evsearch, /*empty*/,
+                              timercmp(&ev->abs, &evsearch->abs, >));
+    ev->infinite = 0;
+}
+
+static int time_register_finite(libxl__gc *gc, libxl__ev_time *ev,
+                                struct timeval abs) {
+    int rc;
+    
+    rc = OSEVENT_HOOK(timeout_register, &ev->for_app_reg, abs, ev);
+    if (rc) return rc;
+
+    ev->infinite = 0;
+    ev->abs = abs;
+    time_insert_finite(gc, ev);
+
+    return 0;
+}
+
+static void time_deregister(libxl__gc *gc, libxl__ev_time *ev)
+{
+    if (!ev->infinite) {
+        OSEVENT_HOOK_VOID(timeout_deregister, &ev->for_app_reg);
+        LIBXL_TAILQ_REMOVE(&CTX->etimes, ev, entry);
+    }
+}
+    
+
+int libxl__ev_time_register_abs(libxl__gc *gc, libxl__ev_time *ev,
+                                libxl__ev_time_callback *func,
+                                struct timeval abs)
+{
+    int rc;
+    
+    CTX_LOCK;
+
+    rc = time_register_finite(gc, ev, abs);
+    if (rc) goto out;
+
+    ev->func = func;
+
+    rc = 0;
+ out:
+    CTX_UNLOCK;
+    return rc;
+}
+
+
+int libxl__ev_time_register_rel(libxl__gc *gc, libxl__ev_time *ev,
+                                libxl__ev_time_callback *func,
+                                int milliseconds /* as for poll(2) */)
+{
+    struct timeval abs;
+    int rc;
+
+    CTX_LOCK;
+
+    if (milliseconds < 0) {
+        ev->infinite = 1;
+    } else {
+        rc = time_rel_to_abs(gc, milliseconds, &abs);
+        if (rc) goto out;
+
+        rc = time_register_finite(gc, ev, abs);
+        if (rc) goto out;
+    }
+
+    ev->func = func;
+    rc = 0;
+
+ out:
+    CTX_UNLOCK;
+    return rc;
+}
+
+int libxl__ev_time_modify_abs(libxl__gc *gc, libxl__ev_time *ev,
+                              struct timeval abs)
+{
+    int rc;
+
+    CTX_LOCK;
+
+    assert(libxl__ev_time_isregistered(ev));
+
+    if (ev->infinite) {
+        rc = time_register_finite(gc, ev, abs);
+        if (rc) goto out;
+    } else {
+        rc = OSEVENT_HOOK(timeout_modify, &ev->for_app_reg, abs);
+        if (rc) goto out;
+
+        LIBXL_TAILQ_REMOVE(&CTX->etimes, ev, entry);
+        ev->abs = abs;
+        time_insert_finite(gc, ev);
+    }
+
+    rc = 0;
+ out:
+    CTX_UNLOCK;
+    return rc;
+}
+
+int libxl__ev_time_modify_rel(libxl__gc *gc, libxl__ev_time *ev,
+                              int milliseconds)
+{
+    struct timeval abs;
+    int rc;
+
+    CTX_LOCK;
+
+    assert(libxl__ev_time_isregistered(ev));
+
+    if (milliseconds < 0) {
+        time_deregister(gc, ev);
+        ev->infinite = 1;
+        rc = 0;
+        goto out;
+    }
+
+    rc = time_rel_to_abs(gc, milliseconds, &abs);
+    if (rc) goto out;
+
+    rc = libxl__ev_time_modify_abs(gc, ev, abs);
+    if (rc) goto out;
+
+    rc = 0;
+ out:
+    CTX_UNLOCK;
+    return rc;
+}
+
+void libxl__ev_time_deregister(libxl__gc *gc, libxl__ev_time *ev)
+{
+    CTX_LOCK;
+
+    if (!libxl__ev_time_isregistered(ev))
+        goto out;
+        
+    time_deregister(gc, ev);
+    ev->func = 0;
+
+ out:
+    CTX_UNLOCK;
+    return;
+}
+
+
+/*
+ * xenstore watches
+ */
+
+libxl__ev_xswatch *libxl__watch_slot_contents(libxl__gc *gc, int slotnum)
+{
+    libxl__ev_watch_slot *slot = &CTX->watch_slots[slotnum];
+    libxl__ev_watch_slot *slotcontents = LIBXL_SLIST_NEXT(slot, empty);
+
+    if (slotcontents == NULL ||
+        ((uintptr_t)slotcontents >= (uintptr_t)CTX->watch_slots &&
+         (uintptr_t)slotcontents < (uintptr_t)(CTX->watch_slots +
+                                               CTX->watch_nslots)))
+        /* An empty slot has either a NULL pointer (end of the
+         * free list), or a pointer to another entry in the array.
+         * So we can do a bounds check to distinguish empty from
+         * full slots.
+         */
+        /* We need to do the comparisons as uintptr_t because
+         * comparing pointers which are not in the same object is
+         * undefined behaviour; if the compiler managed to figure
+         * out that watch_slots[0..watch_nslots-1] is all of the
+         * whole array object it could prove that the above bounds
+         * check was always true if it was legal, and remove it!
+         *
+         * uintptr_t because even on a machine with signed
+         * pointers, objects do not cross zero; whereas on
+         * machines with unsigned pointers, they may cross
+         * 0x8bazillion.
+         */
+        return NULL;
+
+        /* see comment near libxl__ev_watch_slot definition */
+    return (void*)slotcontents;
+}
+
+static void libxl__set_watch_slot_contents(libxl__ev_watch_slot *slot,
+                                           libxl__ev_xswatch *w)
+{
+    /* we look a bit behind the curtain of LIBXL_SLIST, to explicitly
+     * assign to the pointer that's the next link.  See the comment
+     * by the definition of libxl__ev_watch_slot */
+    slot->empty.sle_next = (void*)w;
+}
+
+static void watchfd_callback(libxl__gc *gc, libxl__ev_fd *ev,
+                             int fd, short events, short revents)
+{
+    for (;;) {
+        char **event = xs_check_watch(CTX->xsh);
+        if (!event) {
+            if (errno == EAGAIN) break;
+            if (errno == EINTR) continue;
+            LIBXL__EVENT_DISASTER(gc, "cannot check/read watches", errno, 0);
+            return;
+        }
+
+        const char *epath = event[0];
+        const char *token = event[1];
+        int slotnum;
+        uint32_t counterval;
+        int rc = sscanf(token, "%d/%"SCNx32, &slotnum, &counterval);
+        if (rc != 2) {
+            LIBXL__LOG(CTX, LIBXL__LOG_ERROR,
+                       "watch epath=%s token=%s: failed to parse token",
+                       epath, token);
+            /* oh well */
+            goto ignore;
+        }
+        if (slotnum < 0 || slotnum >= CTX->watch_nslots) {
+            /* perhaps in the future we will make the watchslots array shrink */
+            LIBXL__LOG(CTX, LIBXL__LOG_DEBUG, "watch epath=%s token=%s:"
+                       " slotnum %d out of range [0,%d>",
+                       epath, token, slotnum, CTX->watch_nslots);
+            goto ignore;
+        }
+
+        libxl__ev_xswatch *w = libxl__watch_slot_contents(gc, slotnum);
+
+        if (!w) {
+            LIBXL__LOG(CTX, LIBXL__LOG_DEBUG,
+                       "watch epath=%s token=%s: empty slot",
+                       epath, token);
+            goto ignore;
+        }
+        
+        if (w->counterval != counterval) {
+            LIBXL__LOG(CTX, LIBXL__LOG_DEBUG,
+                       "watch epath=%s token=%s: counter != %"PRIx32,
+                       epath, token, w->counterval);
+            goto ignore;
+        }
+
+        /* Now it's possible, though unlikely, that this was an event
+         * from a previous use of the same slot with the same counterval.
+         *
+         * In that case either:
+         *  - the event path is a child of the watch path, in
+         *    which case this watch would really have generated this
+         *    event if it had been registered soon enough and we are
+         *    OK to give this possibly-spurious event to the caller; or
+         * - it is not, in which case we must suppress it as the
+         *   caller should not see events for unrelated paths.
+         *
+         * See also docs/misc/xenstore.txt.
+         */
+        if (!xs_path_is_subpath(w->path, epath)) {
+            LIBXL__LOG(CTX, LIBXL__LOG_DEBUG,
+                       "watch epath=%s token=%s: not child of wpath=%s",
+                       epath, token, w->path);
+            goto ignore;
+        }
+
+        /* At last, we have checked everything! */
+        LIBXL__LOG(CTX, LIBXL__LOG_DEBUG,
+                   "watch event: epath=%s token=%s wpath=%s w=%p",
+                   epath, token, w->path, w);
+        w->callback(gc, w, w->path, epath);
+
+    ignore:
+        free(event);
+    }
+}
+
+static char *watch_token(libxl__gc *gc, int slotnum, uint32_t counterval)
+{
+    return libxl__sprintf(gc, "%d/%"PRIx32, slotnum, counterval);
+}
+
+int libxl__ev_xswatch_register(libxl__gc *gc, libxl__ev_xswatch *w,
+                               libxl__ev_xswatch_callback *func,
+                               const char *path /* copied */)
+{
+    libxl__ev_watch_slot *use = NULL;
+    char *path_copy = NULL;
+    int rc;
+
+    CTX_LOCK;
+
+    if (!libxl__ev_fd_isregistered(&CTX->watch_efd)) {
+        rc = libxl__ev_fd_register(gc, &CTX->watch_efd, watchfd_callback,
+                                   xs_fileno(CTX->xsh), POLLIN);
+        if (rc) goto out_rc;
+    }
+
+    if (LIBXL_SLIST_EMPTY(&CTX->watch_freeslots)) {
+        /* Free list is empty so there is not in fact a linked
+         * free list in the array and we can safely realloc it */
+        int newarraysize = (CTX->watch_nslots + 1) << 2;
+        int i;
+        libxl__ev_watch_slot *newarray =
+            realloc(CTX->watch_slots, sizeof(*newarray) * newarraysize);
+        if (!newarray) goto out_nomem;
+        for (i = CTX->watch_nslots; i < newarraysize; i++)
+            LIBXL_SLIST_INSERT_HEAD(&CTX->watch_freeslots,
+                                    &newarray[i], empty);
+        CTX->watch_slots = newarray;
+        CTX->watch_nslots = newarraysize;
+    }
+    use = LIBXL_SLIST_FIRST(&CTX->watch_freeslots);
+    assert(use);
+    LIBXL_SLIST_REMOVE_HEAD(&CTX->watch_freeslots, empty);
+
+    path_copy = strdup(path);
+    if (!path_copy) goto out_nomem;
+
+    int slotnum = use - CTX->watch_slots;
+    w->counterval = CTX->watch_counter++;
+
+    if (!xs_watch(CTX->xsh, path, watch_token(gc, slotnum, w->counterval))) {
+        LIBXL__LOG_ERRNOVAL(CTX, LIBXL__LOG_ERROR, errno,
+                            "create watch for path %s", path);
+        rc = ERROR_FAIL;
+        goto out_rc;
+    }
+
+    w->slotnum = slotnum;
+    w->path = path_copy;
+    w->callback = func;
+    libxl__set_watch_slot_contents(use, w);
+
+    CTX_UNLOCK;
+    return 0;
+
+ out_nomem:
+    rc = ERROR_NOMEM;
+ out_rc:
+    if (use)
+        LIBXL_SLIST_INSERT_HEAD(&CTX->watch_freeslots, use, empty);
+    if (path_copy)
+        free(path_copy);
+    CTX_UNLOCK;
+    return rc;
+}
+
+void libxl__ev_xswatch_deregister(libxl__gc *gc, libxl__ev_xswatch *w)
+{
+    /* it is legal to deregister from within _callback */
+    CTX_LOCK;
+
+    if (w->slotnum >= 0) {
+        char *token = watch_token(gc, w->slotnum, w->counterval);
+        if (!xs_unwatch(CTX->xsh, w->path, token))
+            /* Oh well, we will just get watch events forever more
+             * and ignore them.  But we should complain to the log. */
+            LIBXL__LOG_ERRNOVAL(CTX, LIBXL__LOG_ERROR, errno,
+                                "remove watch for path %s", w->path);
+
+        libxl__ev_watch_slot *slot = &CTX->watch_slots[w->slotnum];
+        LIBXL_SLIST_INSERT_HEAD(&CTX->watch_freeslots, slot, empty);
+    }
+
+    free(w->path);
+    w->path = NULL;
+
+    CTX_UNLOCK;
+}
+
+/*
+ * osevent poll
+ */
+
+int libxl_osevent_beforepoll(libxl_ctx *ctx, int *nfds_io,
+                             struct pollfd *fds, int *timeout_upd,
+                             struct timeval now)
+{
+    libxl__ev_fd *efd;
+    int i;
+
+    /*
+     * In order to be able to efficiently find the libxl__ev_fd
+     * for a struct poll during _afterpoll, we maintain a shadow
+     * data structure in CTX->fd_beforepolled: each slot in
+     * the fds array corresponds to a slot in fd_beforepolled.
+     */
+
+    GC_INIT(ctx);
+    CTX_LOCK;
+
+    if (*nfds_io) {
+        /*
+         * As an optimisation, we don't touch fd_beforepolled_used
+         * if *nfds_io is zero on entry, since in that case the
+         * caller just wanted to know how big an array to give us.
+         *
+         * If !*nfds_io, the unconditional parts below are guaranteed
+         * not to mess with fd_beforepolled... or any in_beforepolled.
+         */
+
+        /* Remove all the old references into beforepolled */
+        for (i = 0; i < CTX->fd_beforepolled_used; i++) {
+            efd = CTX->fd_beforepolled[i];
+            if (efd) {
+                assert(efd->in_beforepolled == i);
+                efd->in_beforepolled = -1;
+                CTX->fd_beforepolled[i] = NULL;
+            }
+        }
+        CTX->fd_beforepolled_used = 0;
+
+        /* make sure our array is as big as *nfds_io */
+        if (CTX->fd_beforepolled_allocd < *nfds_io) {
+            assert(*nfds_io < INT_MAX / sizeof(libxl__ev_fd*) / 2);
+            libxl__ev_fd **newarray =
+                realloc(CTX->fd_beforepolled, sizeof(*newarray) * *nfds_io);
+            if (!newarray)
+                return ERROR_NOMEM;
+            CTX->fd_beforepolled = newarray;
+            CTX->fd_beforepolled_allocd = *nfds_io;
+        }
+    }
+
+    int used = 0;
+    LIBXL_LIST_FOREACH(efd, &CTX->efds, entry) {
+        if (used < *nfds_io) {
+            fds[used].fd = efd->fd;
+            fds[used].events = efd->events;
+            fds[used].revents = 0;
+            CTX->fd_beforepolled[used] = efd;
+            efd->in_beforepolled = used;
+        }
+        used++;
+    }
+    int rc = used <= *nfds_io ? 0 : ERROR_BUFFERFULL;
+
+    if (*nfds_io) {
+        CTX->fd_beforepolled_used = used;
+    }
+
+    *nfds_io = used;
+
+    libxl__ev_time *etime = LIBXL_TAILQ_FIRST(&CTX->etimes);
+    if (etime) {
+        int our_timeout;
+        struct timeval rel;
+        static struct timeval zero;
+
+        timersub(&etime->abs, &now, &rel);
+
+        if (timercmp(&rel, &zero, <)) {
+            our_timeout = 0;
+        } else if (rel.tv_sec >= 2000000) {
+            our_timeout = 2000000000;
+        } else {
+            our_timeout = rel.tv_sec * 1000 + (rel.tv_usec + 999) / 1000;
+        }
+        if (*timeout_upd < 0 || our_timeout < *timeout_upd)
+            *timeout_upd = our_timeout;
+    }
+
+    CTX_UNLOCK;
+    GC_FREE;
+    return rc;
+}
+
+void libxl_osevent_afterpoll(libxl_ctx *ctx, int nfds, const struct pollfd *fds,
+                             struct timeval now)
+{
+    int i;
+    GC_INIT(ctx);
+    CTX_LOCK;
+
+    assert(nfds <= CTX->fd_beforepolled_used);
+
+    for (i = 0; i < nfds; i++) {
+        if (!fds[i].revents)
+            continue;
+
+        libxl__ev_fd *efd = CTX->fd_beforepolled[i];
+        if (!efd)
+            continue;
+
+        assert(efd->in_beforepolled == i);
+        assert(fds[i].fd == efd->fd);
+
+        int revents = fds[i].revents & efd->events;
+        if (!revents)
+            continue;
+
+        efd->func(gc, efd, efd->fd, efd->events, revents);
+    }
+
+    for (;;) {
+        libxl__ev_time *etime = LIBXL_TAILQ_FIRST(&CTX->etimes);
+        if (!etime)
+            break;
+
+        assert(!etime->infinite);
+
+        if (timercmp(&etime->abs, &now, >))
+            break;
+
+        time_deregister(gc, etime);
+
+        etime->func(gc, etime, &etime->abs);
+    }
+
+    CTX_UNLOCK;
+    GC_FREE;
+}
+
+
+/*
+ * osevent hook and callback machinery
+ */
+
+void libxl_osevent_register_hooks(libxl_ctx *ctx,
+                                  const libxl_osevent_hooks *hooks,
+                                  void *user)
+{
+    GC_INIT(ctx);
+    CTX_LOCK;
+    ctx->osevent_hooks = hooks;
+    ctx->osevent_user = user;
+    CTX_UNLOCK;
+    GC_FREE;
+}
+
+
+void libxl_osevent_occurred_fd(libxl_ctx *ctx, void *for_libxl,
+                               int fd, short events, short revents)
+{
+    libxl__ev_fd *ev = for_libxl;
+
+    GC_INIT(ctx);
+    CTX_LOCK;
+    assert(!CTX->osevent_in_hook);
+
+    assert(fd == ev->fd);
+    revents &= ev->events;
+    if (revents)
+        ev->func(gc, ev, fd, ev->events, revents);
+
+    CTX_UNLOCK;
+    GC_FREE;
+}
+
+void libxl_osevent_occurred_timeout(libxl_ctx *ctx, void *for_libxl)
+{
+    libxl__ev_time *ev = for_libxl;
+
+    GC_INIT(ctx);
+    CTX_LOCK;
+    assert(!CTX->osevent_in_hook);
+
+    assert(!ev->infinite);
+    LIBXL_TAILQ_REMOVE(&CTX->etimes, ev, entry);
+    ev->func(gc, ev, &ev->abs);
+
+    CTX_UNLOCK;
+    GC_FREE;
+}
+
+void libxl__event_disaster(libxl__gc *gc, const char *msg, int errnoval,
+                           libxl_event_type type /* may be 0 */,
+                           const char *file, int line, const char *func)
+{
+    libxl__log(CTX, XTL_CRITICAL, errnoval, file, line, func,
+               "DISASTER in event loop: %s%s%s%s",
+               msg,
+               type ? " (relates to event type " : "",
+               type ? libxl_event_type_to_string(type) : "",
+               type ? ")" : "");
+
+    /*
+     * FIXME: This should call the "disaster" hook supplied to
+     * libxl_event_register_callbacks, which will be introduced in the
+     * next patch.
+     */
+
+    const char verybad[] =
+        "DISASTER in event loop not handled by libxl application";
+    LIBXL__LOG(CTX, XTL_CRITICAL, verybad);
+    fprintf(stderr, "libxl: fatal error, exiting program: %s\n", verybad);
+    exit(-1);
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/tools/libxl/libxl_event.h b/tools/libxl/libxl_event.h
new file mode 100644
index 0000000..cc4a348
--- /dev/null
+++ b/tools/libxl/libxl_event.h
@@ -0,0 +1,200 @@
+/*
+ * Copyright (C) 2011      Citrix Ltd.
+ * Author Ian Jackson <ian.jackson@eu.citrix.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU Lesser General Public License as published
+ * by the Free Software Foundation; version 2.1 only. with the special
+ * exception on linking described in file LICENSE.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU Lesser General Public License for more details.
+ */
+
+#ifndef LIBXL_EVENT_H
+#define LIBXL_EVENT_H
+
+#include <libxl.h>
+
+
+/*======================================================================*/
+
+/*
+ * OS event handling - passing low-level OS events to libxl
+ *
+ * Event-driven programs must use these facilities to allow libxl
+ * to become aware of readability/writeability of file descriptors
+ * and the occurrence of timeouts.
+ *
+ * There are two approaches available.  The first is appropriate for
+ * simple programs handling reasonably small numbers of domains:
+ *
+ *   for (;;) {
+ *      libxl_osevent_beforepoll(...)
+ *      poll();
+ *      libxl_osevent_afterpoll(...);
+ *      for (;;) {
+ *        r=libxl_event_check(...);
+ *        if (r==LIBXL_NOT_READY) break;
+ *        if (r) handle failure;
+ *        do something with the event;
+ *      }
+ *   }
+ *
+ * The second approach uses libxl_osevent_register_hooks and is
+ * suitable for programs which are already using a callback-based
+ * event library.
+ *
+ * An application may freely mix the two styles of interaction.
+ */
+
+struct pollfd;
+
+int libxl_osevent_beforepoll(libxl_ctx *ctx, int *nfds_io,
+                             struct pollfd *fds, int *timeout_upd,
+                             struct timeval now);
+  /* The caller should provide beforepoll with some space for libxl's
+   * fds, and tell libxl how much space is available by setting *nfds_io.
+   * fds points to the start of this space (and fds may be a pointer into
+   * a larger array, for example, if the application has some fds of
+   * its own that it is interested in).
+   *
+   * On return *nfds_io will in any case have been updated by libxl
+   * according to how many fds libxl wants to poll on.
+   *
+   * If the space was sufficient, libxl fills in fds[0..<new
+   * *nfds_io>] suitably for poll(2), updates *timeout_upd if needed,
+   * and returns ok.
+   *
+   * If space was insufficient, fds[0..<old *nfds_io>] is undefined on
+   * return; *nfds_io on return will be greater than the value on
+   * entry; *timeout_upd may or may not have been updated; and
+   * libxl_osevent_beforepoll returns ERROR_BUFERFULL.  In this case
+   * the application needs to make more space (enough space for
+   * *nfds_io struct pollfd) and then call beforepoll again, before
+   * entering poll(2).  Typically this will involve calling realloc.
+   *
+   * The application may call beforepoll with fds==NULL and
+   * *nfds_io==0 in order to find out how much space is needed.
+   *
+   * *timeout_upd is as for poll(2): it's in milliseconds, and
+   * negative values mean no timeout (infinity).
+   * libxl_osevent_beforepoll will only reduce the timeout, naturally.
+   */
+void libxl_osevent_afterpoll(libxl_ctx *ctx, int nfds, const struct pollfd *fds,
+                             struct timeval now);
+  /* nfds and fds[0..nfds] must be from the most recent call to
+   * _beforepoll, as modified by poll.
+   *
+   * This function actually performs all of the IO and other actions,
+   * and generates events (libxl_event), which are implied by either
+   * (a) the time of day or (b) both (i) the returned information from
+   * _beforepoll, and (ii) the results from poll specified in
+   * fds[0..nfds-1].  Generated events can then be retrieved by
+   * libxl_event_check.
+   */
+
+
+typedef struct libxl_osevent_hooks {
+  int (*fd_register)(void *user, int fd, void **for_app_registration_out,
+                     short events, void *for_libxl);
+  int (*fd_modify)(void *user, int fd, void **for_app_registration_update,
+                   short events);
+  void (*fd_deregister)(void *user, int fd, void *for_app_registration);
+  int (*timeout_register)(void *user, void **for_app_registration_out,
+                          struct timeval abs, void *for_libxl);
+  int (*timeout_modify)(void *user, void **for_app_registration_update,
+                         struct timeval abs);
+  void (*timeout_deregister)(void *user, void *for_app_registration);
+} libxl_osevent_hooks;
+
+void libxl_osevent_register_hooks(libxl_ctx *ctx,
+                                  const libxl_osevent_hooks *hooks,
+                                  void *user);
+  /* The application which calls register_fd_hooks promises to
+   * maintain a register of fds and timeouts that libxl is interested
+   * in, and make calls into libxl (libxl_osevent_occurred_*)
+   * when those fd events and timeouts occur.  This is more efficient
+   * than _beforepoll/_afterpoll if there are many fds (which can
+   * happen if the same libxl application is managing many domains).
+   *
+   * For an fd event, events is as for poll().  register or modify may
+   * be called with events==0, in which case it must still work
+   * normally, just not generate any events.
+   *
+   * For a timeout event, milliseconds is as for poll().
+   * Specifically, negative values of milliseconds mean NO TIMEOUT.
+   * This is used by libxl to temporarily disable a timeout.
+   *
+   * If the register or modify hook succeeds it may update
+   * *for_app_registration_out/_update and must then return 0.
+   * On entry to register, *for_app_registration_out is always NULL.
+   *
+   * A registration or modification hook may fail, in which case it
+   * must leave the registration state of the fd or timeout unchanged.
+   * It may then either return ERROR_OSEVENT_REG_FAIL or any positive
+   * int.  The value returned will be passed up through libxl and
+   * eventually returned back to the application.  When register
+   * fails, any value stored into *for_registration_out is ignored by
+   * libxl; when modify fails, any changed value stored into
+   * *for_registration_update is honoured by libxl and will be passed
+   * to future modify or deregister calls.
+   *
+   * libxl will only attempt to register one callback for any one fd.
+   * libxl will remember the value stored in *for_app_registration_out
+   * (or *for_app_registration_update) by a successful call to
+   * register (or modify), and pass it to subsequent calls to modify
+   * or deregister.
+   *
+   * register_fd_hooks may be called only once for each libxl_ctx.
+   * libxl may make calls to register/modify/deregister from within
+   * any libxl function (indeed, it will usually call register from
+   * register_event_hooks).  Conversely, the application MUST NOT make
+   * the event occurrence calls (libxl_osevent_occurred_*) into libxl
+   * reentrantly from within libxl (for example, from within the
+   * register/modify functions).
+   *
+   * Lock hierarchy: the register/modify/deregister functions may be
+   * called with locks held.  These locks (the "libxl internal locks")
+   * are inside the libxl_ctx.  Therefore, if those register functions
+   * acquire any locks of their own ("caller register locks") outside
+   * libxl, to avoid deadlock one of the following must hold for each
+   * such caller register lock:
+   *  (a) "acquire libxl internal locks before caller register lock":
+   *      No libxl function may be called with the caller register
+   *      lock held.
+   *  (b) "acquire caller register lock before libxl internal locks":
+   *      No libxl function may be called _without_ the caller
+   *      register lock held.
+   * Of these we would normally recommend (a).
+   *
+   * The value *hooks is not copied and must outlast the libxl_ctx.
+   */
+
+/* It is NOT legal to call _occurred_ reentrantly within any libxl
+ * function.  Specifically it is NOT legal to call it from within
+ * a register callback.  Conversely, libxl MAY call register/deregister
+ * from within libxl_event_registered_call_*.
+ */
+
+void libxl_osevent_occurred_fd(libxl_ctx *ctx, void *for_libxl,
+                               int fd, short events, short revents);
+
+void libxl_osevent_occurred_timeout(libxl_ctx *ctx, void *for_libxl);
+  /* Implicitly, on entry to this function the timeout has been
+   * deregistered.  If _occurred_timeout is called, libxl will not
+   * call timeout_deregister; if it wants to requeue the timeout it
+   * will call timeout_register again.
+   */
+
+#endif
+
+/*
+ * Local variables:
+ * mode: C
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 536a1ec..c4a5fa1 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -24,6 +24,9 @@
 #include <stdlib.h>
 #include <string.h>
 #include <pthread.h>
+#include <inttypes.h>
+#include <assert.h>
+#include <sys/poll.h>
 
 #include <xs.h>
 #include <xenctrl.h>
@@ -91,6 +94,66 @@ _hidden void libxl__log(libxl_ctx *ctx, xentoollog_level msglevel, int errnoval,
 
      /* these functions preserve errno (saving and restoring) */
 
+typedef struct libxl__gc libxl__gc;
+
+typedef struct libxl__ev_fd libxl__ev_fd;
+typedef void libxl__ev_fd_callback(libxl__gc *gc, libxl__ev_fd *ev,
+                                   int fd, short events, short revents);
+struct libxl__ev_fd {
+    /* all private for libxl__ev_fd... */
+    LIBXL_LIST_ENTRY(libxl__ev_fd) entry;
+    int fd;
+    short events;
+    int in_beforepolled; /* -1 means not in fd_beforepolled */
+    void *for_app_reg;
+    libxl__ev_fd_callback *func;
+};
+
+
+typedef struct libxl__ev_time libxl__ev_time;
+typedef void libxl__ev_time_callback(libxl__gc *gc, libxl__ev_time *ev,
+                                     const struct timeval *requested_abs);
+struct libxl__ev_time {
+    /* all private for libxl__ev_time... */
+    int infinite; /* not registered in list or with app if infinite */
+    LIBXL_TAILQ_ENTRY(libxl__ev_time) entry;
+    struct timeval abs;
+    void *for_app_reg;
+    libxl__ev_time_callback *func;
+};
+
+typedef struct libxl__ev_xswatch libxl__ev_xswatch;
+typedef void libxl__ev_xswatch_callback(libxl__gc *gc, libxl__ev_xswatch*,
+                            const char *watch_path, const char *event_path);
+struct libxl__ev_xswatch {
+    /* caller should include this in their own struct */
+    /* contents are private to xswatch_register */
+    int slotnum;
+    uint32_t counterval;
+    char *path;
+    libxl__ev_xswatch_callback *callback;
+};
+
+/*
+ * An entry in the watch_slots table is either:
+ *  1. an entry in the free list, ie NULL or pointer to next free list entry
+ *  2. an pointer to a libxl__ev_xswatch
+ *
+ * But we don't want to use unions or type-punning because the
+ * compiler might "prove" that our code is wrong and misoptimise it.
+ *
+ * The rules say that all struct pointers have identical
+ * representation and alignment requirements (C99+TC1+TC2 6.2.5p26) so
+ * what we do is simply declare our array as containing only the free
+ * list pointers, and explicitly convert from and to our actual
+ * xswatch pointers when we store and retrieve them.
+ */
+typedef struct libxl__ev_watch_slot {
+    LIBXL_SLIST_ENTRY(struct libxl__ev_watch_slot) empty;
+} libxl__ev_watch_slot;
+    
+libxl__ev_xswatch *libxl__watch_slot_contents(libxl__gc *gc, int slotnum);
+
 struct libxl__ctx {
     xentoollog_logger *lg;
     xc_interface *xch;
@@ -108,6 +171,23 @@ struct libxl__ctx {
        * documented in the libxl public interface.
        */
 
+    int osevent_in_hook;
+    const libxl_osevent_hooks *osevent_hooks;
+    void *osevent_user;
+      /* See the comment for OSEVENT_HOOK_INTERN in libxl_event.c
+       * for restrictions on the use of the osevent fields. */
+
+    int fd_beforepolled_allocd, fd_beforepolled_used;
+    libxl__ev_fd **fd_beforepolled; /* see libxl_osevent_beforepoll */
+    LIBXL_LIST_HEAD(, libxl__ev_fd) efds;
+    LIBXL_TAILQ_HEAD(, libxl__ev_time) etimes;
+
+    libxl__ev_watch_slot *watch_slots;
+    int watch_nslots;
+    LIBXL_SLIST_HEAD(, libxl__ev_watch_slot) watch_freeslots;
+    uint32_t watch_counter; /* helps disambiguate slot reuse */
+    libxl__ev_fd watch_efd;
+
     /* for callers who reap children willy-nilly; caller must only
      * set this after libxl_init and before any other call - or
      * may leave them untouched */
@@ -138,12 +218,12 @@ typedef struct {
 
 #define PRINTF_ATTRIBUTE(x, y) __attribute__((format(printf, x, y)))
 
-typedef struct {
+struct libxl__gc {
     /* mini-GC */
     int alloc_maxsize;
     void **alloc_ptrs;
     libxl_ctx *owner;
-} libxl__gc;
+};
 
 #define LIBXL_INIT_GC(gc,ctx) do{               \
         (gc).alloc_maxsize = 0;                 \
@@ -209,9 +289,140 @@ _hidden char *libxl__xs_read(libxl__gc *gc, xs_transaction_t t,
 _hidden char **libxl__xs_directory(libxl__gc *gc, xs_transaction_t t,
                                    const char *path, unsigned int *nb);
    /* On error: returns NULL, sets errno (no logging) */
-
 _hidden char *libxl__xs_libxl_path(libxl__gc *gc, uint32_t domid);
 
+
+/*
+ * Event generation functions provided by the libxl event core to the
+ * rest of libxl.  Implemented in terms of _beforepoll/_afterpoll
+ * and/or the fd registration machinery, as provided by the
+ * application.
+ *
+ * Semantics are similar to those of the fd and timeout registration
+ * functions provided to libxl_osevent_register_hooks.
+ *
+ * Non-0 returns from libxl__ev_{modify,deregister} have already been
+ * logged by the core and should be returned unmodified to libxl's
+ * caller; NB that they may be valid libxl error codes but they may
+ * also be positive numbers supplied by the caller.
+ *
+ * In each case, there is a libxl__ev_FOO structure which can be in
+ * one of three states:
+ *
+ *   Undefined   - Might contain anything.  All-bits-zero is
+ *                 an undefined state.
+ *
+ *   Idle        - Struct contents are defined enough to pass to any
+ *                 libxl__ev_FOO function but not registered and
+ *                 callback will not be called.  The struct does not
+ *                 contain references to any allocated resources so
+ *                 can be thrown away.
+ *
+ *   Active      - Request for events has been registered and events
+ *                 may be generated.  _deregister must be called to
+ *                 reclaim resources.
+ *
+ * These functions are provided for each kind of event KIND:
+ *
+ *   int libxl__ev_KIND_register(libxl__gc *gc, libxl__ev_KIND *GEN,
+ *                              libxl__ev_KIND_callback *FUNC,
+ *                              DETAILS);
+ *      On entry *GEN must be in state Undefined or Idle.
+ *      Returns a libxl error code; on error return *GEN is Idle.
+ *      On successful return *GEN is Active and FUNC wil be
+ *      called by the event machinery in future.  FUNC will
+ *      not be called from within the call to _register.
+ *
+ *  void libxl__ev_KIND_deregister(libxl__gc *gc, libxl__ev_KIND *GEN_upd);
+ *      On entry *GEN must be in state Active or Idle.
+ *      On return it is Idle.  (Idempotent.)
+ *
+ *  void libxl__ev_KIND_init(libxl__ev_KIND *GEN);
+ *      Provided for initialising an Undefined KIND.
+ *      On entry *GEN must be in state Idle or Undefined.
+ *      On return it is Idle.  (Idempotent.)
+ *
+ *  int libxl__ev_KIND_isregistered(const libxl__ev_KIND *GEN);
+ *      On entry *GEN must be Idle or Active.
+ *      Returns nonzero if it is Active, zero otherwise.
+ *      Cannot fail.
+ *
+ *  int libxl__ev_KiND_modify(libxl__gc*, libxl__ev_KIND *GEN,
+ *                            DETAILS);
+ *      Only provided for some kinds of generator.
+ *      On entry *GEN must be Active and on return, whether successful
+ *      or not, it will be Active.
+ *      Returns a libxl error code; on error the modification
+ *      is not effective.
+ *
+ * All of these functions are fully threadsafe and may be called by
+ * general code in libxl even from within event callback FUNCs.
+ *
+ * Callers of libxl__ev_KIND_register must ensure that the
+ * registration is undone, with _deregister, in libxl_ctx_free.
+ */
+
+
+_hidden int libxl__ev_fd_register(libxl__gc*, libxl__ev_fd *ev_out,
+                                  libxl__ev_fd_callback*,
+                                  int fd, short events /* as for poll(2) */);
+_hidden int libxl__ev_fd_modify(libxl__gc*, libxl__ev_fd *ev,
+                                short events);
+_hidden void libxl__ev_fd_deregister(libxl__gc*, libxl__ev_fd *ev);
+static inline void libxl__ev_fd_init(libxl__ev_fd *efd)
+                    { efd->fd = -1; }
+static inline int libxl__ev_fd_isregistered(libxl__ev_fd *efd)
+                    { return efd->fd >= 0; }
+
+_hidden int libxl__ev_time_register_rel(libxl__gc*, libxl__ev_time *ev_out,
+                                        libxl__ev_time_callback*,
+                                        int milliseconds /* as for poll(2) */);
+_hidden int libxl__ev_time_register_abs(libxl__gc*, libxl__ev_time *ev_out,
+                                        libxl__ev_time_callback*,
+                                        struct timeval);
+_hidden int libxl__ev_time_modify_rel(libxl__gc*, libxl__ev_time *ev,
+                                      int milliseconds /* as for poll(2) */);
+_hidden int libxl__ev_time_modify_abs(libxl__gc*, libxl__ev_time *ev,
+                                      struct timeval);
+_hidden void libxl__ev_time_deregister(libxl__gc*, libxl__ev_time *ev);
+static inline void libxl__ev_time_init(libxl__ev_time *ev)
+                { ev->func = 0; }
+static inline int libxl__ev_time_isregistered(libxl__ev_time *ev)
+                { return !!ev->func; }
+
+
+_hidden int libxl__ev_xswatch_register(libxl__gc*, libxl__ev_xswatch *xsw_out,
+                                       libxl__ev_xswatch_callback*,
+                                       const char *path /* copied */);
+_hidden void libxl__ev_xswatch_deregister(libxl__gc *gc, libxl__ev_xswatch*);
+
+static inline void libxl__ev_xswatch_init(libxl__ev_xswatch *xswatch_out)
+                { xswatch_out->slotnum = -1; }
+static inline int libxl__ev_xswatch_isregistered(const libxl__ev_xswatch *xw)
+                { return xw->slotnum >= 0; }
+
+
+
+_hidden void libxl__event_disaster(libxl__gc*, const char *msg, int errnoval,
+                                   libxl_event_type type /* may be 0 */,
+                                   const char *file, int line,
+                                   const char *func);
+  /*
+   * In general, call this via the macro LIBXL__EVENT_DISASTER.
+   *
+   * Event-generating functions may call this if they might have
+   * wanted to generate an event (either an internal one ie a
+   * libxl__ev_FOO_callback or an application event), but are
+   * prevented from doing so due to eg lack of memory.
+   *
+   * NB that this function may return and the caller isn't supposed to
+   * then crash, although it may fail (and henceforth leave things in
+   * a state where many or all calls fail).
+   */
+#define LIBXL__EVENT_DISASTER(gc, msg, errnoval, type) \
+    libxl__event_disaster(gc, msg, errnoval, type, __FILE__, __LINE__, __func__)
+
+
 /* from xl_dom */
 _hidden libxl_domain_type libxl__domain_type(libxl__gc *gc, uint32_t domid);
 _hidden int libxl__domain_shutdown_reason(libxl__gc *gc, uint32_t domid);
@@ -536,6 +747,8 @@ _hidden int libxl__parse_mac(const char *s, libxl_mac mac);
 /* compare mac address @a and @b. 0 if the same, -ve if a<b and +ve if a>b */
 _hidden int libxl__compare_macs(libxl_mac *a, libxl_mac *b);
 
+_hidden int libxl__gettimeofday(libxl__gc *gc, struct timeval *now_r);
+
 #define STRINGIFY(x) #x
 #define TOSTRING(x) STRINGIFY(x)
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 18:55:51 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 18: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.xensource.com>)
	id 1RZ5bh-0001HH-H0; Fri, 09 Dec 2011 18:55:41 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RZ5bf-0001Bh-MI
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 18:55:39 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1323456879!6616386!17
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI2MQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21522 invoked from network); 9 Dec 2011 18:54:49 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 18:54:49 -0000
X-IronPort-AV: E=Sophos;i="4.71,327,1320624000"; 
   d="scan'208";a="9392208"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 18:54:49 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 18:54:49 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RZ5ar-0002eU-IK; Fri, 09 Dec 2011 18:54:49 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RZ5ar-00040x-HY;
	Fri, 09 Dec 2011 18:54:49 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Fri, 9 Dec 2011 18:54:35 +0000
Message-ID: <1323456877-15315-17-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1323456877-15315-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1323456877-15315-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 16/18] libxl: rename libxl__free_all
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

libxl__free_all is going to gain some extra functionality, which will
mean that the name is no longer accurate.  Rename it to
libxl__gc_cleanup.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl.h          |    2 +-
 tools/libxl/libxl_internal.c |    2 +-
 tools/libxl/libxl_internal.h |    4 ++--
 3 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 289dc85..9e8ca29 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -119,7 +119,7 @@
  *
  * No temporary objects allocated from the pool may be explicitly freed.
  * Therefore public functions which initialize a libxl__gc MUST call
- * libxl__free_all() before returning.
+ * libxl__gc_cleanup() before returning.
  */
 #ifndef LIBXL_H
 #define LIBXL_H
diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c
index a2e5820..232cc4a 100644
--- a/tools/libxl/libxl_internal.c
+++ b/tools/libxl/libxl_internal.c
@@ -61,7 +61,7 @@ int libxl__ptr_add(libxl__gc *gc, void *ptr)
     return 0;
 }
 
-void libxl__free_all(libxl__gc *gc)
+void libxl__gc_cleanup(libxl__gc *gc)
 {
     void *ptr;
     int i;
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index d015c7c..536a1ec 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -171,7 +171,7 @@ static inline libxl_ctx *libxl__gc_owner(libxl__gc *gc)
 /* register @ptr in @gc for free on exit from outermost libxl callframe. */
 _hidden int libxl__ptr_add(libxl__gc *gc, void *ptr);
 /* if this is the outermost libxl callframe then free all pointers in @gc */
-_hidden void libxl__free_all(libxl__gc *gc);
+_hidden void libxl__gc_cleanup(libxl__gc *gc);
 /* allocate and zero @bytes. (similar to a gc'd malloc(3)+memzero()) */
 _hidden void *libxl__zalloc(libxl__gc *gc, int bytes);
 /* allocate and zero memory for an array of @nmemb members of @size each.
@@ -682,7 +682,7 @@ libxl__device_model_version_running(libxl__gc *gc, uint32_t domid);
  */
 
 #define GC_INIT(ctx)  libxl__gc gc[1]; LIBXL_INIT_GC(gc[0],ctx)
-#define GC_FREE       libxl__free_all(gc)
+#define GC_FREE       libxl__gc_cleanup(gc)
 #define CTX           libxl__gc_owner(gc)
 
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 18:55:51 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 18: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.xensource.com>)
	id 1RZ5bb-0001C1-FW; Fri, 09 Dec 2011 18:55:35 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RZ5bZ-0001Ai-Nf
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 18:55:33 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1323456879!6616386!5
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI2MQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21254 invoked from network); 9 Dec 2011 18:54:43 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 18:54:43 -0000
X-IronPort-AV: E=Sophos;i="4.71,327,1320624000"; 
   d="scan'208";a="9392196"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 18:54:43 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 18:54:43 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RZ5al-0002du-DQ; Fri, 09 Dec 2011 18:54:43 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RZ5al-000408-Cf;
	Fri, 09 Dec 2011 18:54:43 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Fri, 9 Dec 2011 18:54:23 +0000
Message-ID: <1323456877-15315-5-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1323456877-15315-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1323456877-15315-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 04/18] libxl: idl: support new "private" type
	attribute
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This provides for fields in libxl datatypes which are only present in
the C version of structures and are used only by libxl itself.  This
is useful when a libxl datatype wants to contain fields which are used
by libxl internally and which are only present in the structure to
avoid additional memory allocation inconvenience.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/gentest.py    |    2 ++
 tools/libxl/libxltypes.py |    4 +++-
 tools/python/genwrap.py   |    6 ++++++
 3 files changed, 11 insertions(+), 1 deletions(-)

diff --git a/tools/libxl/gentest.py b/tools/libxl/gentest.py
index 05e77cc..ac7a400 100644
--- a/tools/libxl/gentest.py
+++ b/tools/libxl/gentest.py
@@ -56,6 +56,8 @@ def gen_rand_init(ty, v, indent = "    ", parent = None):
         s += "%s = rand() %% 2;\n" % v
     elif ty.typename in ["char *"]:
         s += "%s = rand_str();\n" % v
+    elif ty.private:
+        pass
     elif ty.typename in handcoded:
         raise Exception("Gen for handcoded %s" % ty.typename)
     else:
diff --git a/tools/libxl/libxltypes.py b/tools/libxl/libxltypes.py
index 55056c2..450de88 100644
--- a/tools/libxl/libxltypes.py
+++ b/tools/libxl/libxltypes.py
@@ -33,6 +33,8 @@ class Type(object):
         if self.passby not in [PASS_BY_VALUE, PASS_BY_REFERENCE]:
             raise ValueError
 
+        self.private = kwargs.setdefault('private', False)
+
         if typename is None: # Anonymous type
             self.typename = None
             self.rawname = None
@@ -50,7 +52,7 @@ class Type(object):
 
         self.autogenerate_dispose_fn = kwargs.setdefault('autogenerate_dispose_fn', True)
 
-        if self.typename is not None:
+        if self.typename is not None and not self.private:
             self.json_fn = kwargs.setdefault('json_fn', self.typename + "_gen_json")
         else:
             self.json_fn = kwargs.setdefault('json_fn', None)
diff --git a/tools/python/genwrap.py b/tools/python/genwrap.py
index d0c193d..a5febee 100644
--- a/tools/python/genwrap.py
+++ b/tools/python/genwrap.py
@@ -129,6 +129,8 @@ static PyObject *Py%(rawname)s_new(PyTypeObject *type, PyObject *args, PyObject
 
     l.append('static PyGetSetDef Py%s_getset[] = {'%ty.rawname)
     for f in ty.fields:
+        if f.type.private:
+            continue
         l.append('    { .name = "%s", '%f.name)
         if ty.marshal_out():
             l.append('      .get = (getter)py_%s_%s_get, '%(ty.rawname, f.name))
@@ -295,9 +297,13 @@ _hidden int genwrap__ll_set(PyObject *v, long long *val, long long mask);
 
 """ % tuple((' '.join(sys.argv),) + (os.path.split(decls)[-1:]),))
     for ty in types:
+        if ty.private:
+            continue
         if isinstance(ty, libxltypes.Aggregate):
             f.write('/* Attribute get/set functions for %s */\n'%ty.typename)
             for a in ty.fields:
+                if a.type.private:
+                    continue
                 if ty.marshal_out():
                     f.write(py_attrib_get(ty,a))
                 if ty.marshal_in():
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 18:55:51 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 18: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.xensource.com>)
	id 1RZ5bX-0001Av-8l; Fri, 09 Dec 2011 18:55:31 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RZ5bV-0001AW-HE
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 18:55:29 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1323456879!6616386!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI2MQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21162 invoked from network); 9 Dec 2011 18:54:39 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 18:54:39 -0000
X-IronPort-AV: E=Sophos;i="4.71,327,1320624000"; 
   d="scan'208";a="9392192"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 18:54:39 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 18:54:39 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RZ5ag-0002di-Rh; Fri, 09 Dec 2011 18:54:38 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RZ5ag-0003zk-QN;
	Fri, 09 Dec 2011 18:54:38 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Fri, 9 Dec 2011 18:54:19 +0000
Message-ID: <1323456877-15315-1-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Subject: [Xen-devel] [PATCH v5 00/18] New event API
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Yet another version of my event handling API series I'm afraid.  This
addresses all comments so far.

Many of the earlier parts of the series have been acked and are
reposted for completeness.  Hopefully we will be able to apply these
early parts 01-13 soon:
    01/18 libxl: Make libxl__xs_* more const-correct
    02/18 libxenstore: Provide xs_check_watch
    03/18 libxl: Provide a version of bsd's queue.h as _libxl_list.h
    04/18 libxl: idl: support new "private" type attribute
    05/18 libxl: idl: Provide struct and union tags
    06/18 libxl: permit declaration after statement
    07/18 libxl: internal convenience macros
    08/18 libxl: Rationalise #includes
    09/18 libxl: introduce lock in libxl_ctx
    10/18 libxl: make libxl__[v]log const-correct
    11/18 libxl: make libxl__free_all idempotent
  * 12/18 libxl: libxl_ctx_free should free the ctx
    13/18 libxl: Use GC_INIT and GC_FREE everywhere
Of these 12/18 is new but I think obviously correct.  After that's
acked, and test passes and patch backlog permitting, I intend to apply
those.

And here are the remaining patches, including the meat, which are
still undergoing review:
    14/18 libxl: make LIBXL_INIT_GC a statement, not an initialiser
    15/18 xenstore: New function xs_path_is_subpath
    16/18 libxl: rename libxl__free_all
    17/18 libxl: New API for providing OS events to libxl
    18/18 libxl: New event generation API


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 18:55:51 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 18: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.xensource.com>)
	id 1RZ5ba-0001BZ-2B; Fri, 09 Dec 2011 18:55:34 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RZ5bY-0001Ag-SM
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 18:55:33 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1323456879!6616386!3
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI2MQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21226 invoked from network); 9 Dec 2011 18:54:42 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 18:54:42 -0000
X-IronPort-AV: E=Sophos;i="4.71,327,1320624000"; 
   d="scan'208";a="9392194"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 18:54:42 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 18:54:42 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RZ5ak-0002do-6y; Fri, 09 Dec 2011 18:54:42 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RZ5ak-0003zy-6D;
	Fri, 09 Dec 2011 18:54:42 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Fri, 9 Dec 2011 18:54:21 +0000
Message-ID: <1323456877-15315-3-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1323456877-15315-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1323456877-15315-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 02/18] libxenstore: Provide xs_check_watch
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Event-driven programs want to wait until the xs_fileno triggers for
reading, and then repeatedly call xs_check_watch.

Also xs_read_watch exposes a useless "num" out parameter, which should
always (if things aren't going hideously wrong) be at least 2 and
which the caller shouldn't be interested in.  So xs_check_watch
doesn't have one of those.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/xenstore/Makefile |    2 +-
 tools/xenstore/xs.c     |   89 ++++++++++++++++++++++++++++++++++++++++------
 tools/xenstore/xs.h     |   16 ++++++++
 3 files changed, 94 insertions(+), 13 deletions(-)

diff --git a/tools/xenstore/Makefile b/tools/xenstore/Makefile
index bd3e8f1..4facb62 100644
--- a/tools/xenstore/Makefile
+++ b/tools/xenstore/Makefile
@@ -2,7 +2,7 @@ XEN_ROOT=$(CURDIR)/../..
 include $(XEN_ROOT)/tools/Rules.mk
 
 MAJOR = 3.0
-MINOR = 0
+MINOR = 1
 
 CFLAGS += -Werror
 CFLAGS += -I.
diff --git a/tools/xenstore/xs.c b/tools/xenstore/xs.c
index df270f7..8e54fe0 100644
--- a/tools/xenstore/xs.c
+++ b/tools/xenstore/xs.c
@@ -132,7 +132,23 @@ struct xs_handle {
 
 #endif
 
-static int read_message(struct xs_handle *h);
+static int read_message(struct xs_handle *h, int nonblocking);
+
+static void setnonblock(int fd, int nonblock) {
+	int esave = errno;
+	int flags = fcntl(fd, F_GETFL);
+	if (flags == -1)
+		goto out;
+
+	if (nonblock)
+		flags |= O_NONBLOCK;
+	else
+		flags &= ~O_NONBLOCK;
+
+	fcntl(fd, F_SETFL, flags);
+out:
+	errno = esave;
+}
 
 int xs_fileno(struct xs_handle *h)
 {
@@ -325,8 +341,16 @@ void xs_close(struct xs_handle* xsh)
 		xs_daemon_close(xsh);
 }
 
-static bool read_all(int fd, void *data, unsigned int len)
+static bool read_all(int fd, void *data, unsigned int len, int nonblocking)
+	/* With nonblocking, either reads either everything requested,
+	 * or nothing. */
 {
+	if (!len)
+		return true;
+
+	if (nonblocking)
+		setnonblock(fd, 1);
+
 	while (len) {
 		int done;
 
@@ -334,18 +358,28 @@ static bool read_all(int fd, void *data, unsigned int len)
 		if (done < 0) {
 			if (errno == EINTR)
 				continue;
-			return false;
+			goto out_false;
 		}
 		if (done == 0) {
 			/* It closed fd on us?  EBADF is appropriate. */
 			errno = EBADF;
-			return false;
+			goto out_false;
 		}
 		data += done;
 		len -= done;
+
+		if (nonblocking) {
+			setnonblock(fd, 0);
+			nonblocking = 0;
+		}
 	}
 
 	return true;
+
+out_false:
+	if (nonblocking)
+		setnonblock(fd, 0);
+	return false;
 }
 
 #ifdef XSTEST
@@ -374,7 +408,7 @@ static void *read_reply(
 	read_from_thread = read_thread_exists(h);
 
 	/* Read from comms channel ourselves if there is no reader thread. */
-	if (!read_from_thread && (read_message(h) == -1))
+	if (!read_from_thread && (read_message(h, 0) == -1))
 		return NULL;
 
 	mutex_lock(&h->reply_mutex);
@@ -693,7 +727,8 @@ bool xs_watch(struct xs_handle *h, const char *path, const char *token)
  * Returns array of two pointers: path and token, or NULL.
  * Call free() after use.
  */
-char **xs_read_watch(struct xs_handle *h, unsigned int *num)
+static char **read_watch_internal(struct xs_handle *h, unsigned int *num,
+				  int nonblocking)
 {
 	struct xs_stored_msg *msg;
 	char **ret, *strings, c = 0;
@@ -707,14 +742,20 @@ char **xs_read_watch(struct xs_handle *h, unsigned int *num)
 	 * we haven't called xs_watch.	Presumably the application
 	 * will do so later; in the meantime we just block.
 	 */
-	while (list_empty(&h->watch_list) && h->fd != -1)
+	while (list_empty(&h->watch_list) && h->fd != -1) {
+		if (nonblocking) {
+			mutex_unlock(&h->watch_mutex);
+			errno = EAGAIN;
+			return 0;
+		}
 		condvar_wait(&h->watch_condvar, &h->watch_mutex);
+	}
 #else /* !defined(USE_PTHREAD) */
 	/* Read from comms channel ourselves if there are no threads
 	 * and therefore no reader thread. */
 
 	assert(!read_thread_exists(h)); /* not threadsafe but worth a check */
-	if ((read_message(h) == -1))
+	if ((read_message(h, nonblocking) == -1))
 		return NULL;
 
 #endif /* !defined(USE_PTHREAD) */
@@ -760,6 +801,24 @@ char **xs_read_watch(struct xs_handle *h, unsigned int *num)
 	return ret;
 }
 
+char **xs_check_watch(struct xs_handle *h)
+{
+	unsigned int num;
+	char **ret;
+	ret = read_watch_internal(h, &num, 1);
+	if (ret) assert(num >= 2);
+	return ret;
+}
+
+/* Find out what node change was on (will block if nothing pending).
+ * Returns array of two pointers: path and token, or NULL.
+ * Call free() after use.
+ */
+char **xs_read_watch(struct xs_handle *h, unsigned int *num)
+{
+	return read_watch_internal(h, num, 0);
+}
+
 /* Remove a watch on a node.
  * Returns false on failure (no watch on that node).
  */
@@ -940,11 +999,17 @@ char *xs_debug_command(struct xs_handle *h, const char *cmd,
 			ARRAY_SIZE(iov), NULL);
 }
 
-static int read_message(struct xs_handle *h)
+static int read_message(struct xs_handle *h, int nonblocking)
 {
 	/* IMPORTANT: It is forbidden to call this function without
 	 * acquiring the request lock and checking that h->read_thr_exists
 	 * is false.  See "Lock discipline" in struct xs_handle, above. */
+
+	/* If nonblocking==1, this function will always read either
+	 * nothing, returning -1 and setting errno==EAGAIN, or we read
+	 * whole amount requested.  Ie as soon as we have the start of
+	 * the message we block until we get all of it.
+	 */
          
 	struct xs_stored_msg *msg = NULL;
 	char *body = NULL;
@@ -956,7 +1021,7 @@ static int read_message(struct xs_handle *h)
 	if (msg == NULL)
 		goto error;
 	cleanup_push(free, msg);
-	if (!read_all(h->fd, &msg->hdr, sizeof(msg->hdr))) { /* Cancellation point */
+	if (!read_all(h->fd, &msg->hdr, sizeof(msg->hdr), nonblocking)) { /* Cancellation point */
 		saved_errno = errno;
 		goto error_freemsg;
 	}
@@ -966,7 +1031,7 @@ static int read_message(struct xs_handle *h)
 	if (body == NULL)
 		goto error_freemsg;
 	cleanup_push(free, body);
-	if (!read_all(h->fd, body, msg->hdr.len)) { /* Cancellation point */
+	if (!read_all(h->fd, body, msg->hdr.len, 0)) { /* Cancellation point */
 		saved_errno = errno;
 		goto error_freebody;
 	}
@@ -1021,7 +1086,7 @@ static void *read_thread(void *arg)
 	struct xs_handle *h = arg;
 	int fd;
 
-	while (read_message(h) != -1)
+	while (read_message(h, 0) != -1)
 		continue;
 
 	/* An error return from read_message leaves the socket in an undefined
diff --git a/tools/xenstore/xs.h b/tools/xenstore/xs.h
index 1cbe255..63f535d 100644
--- a/tools/xenstore/xs.h
+++ b/tools/xenstore/xs.h
@@ -135,6 +135,22 @@ bool xs_watch(struct xs_handle *h, const char *path, const char *token);
 /* Return the FD to poll on to see if a watch has fired. */
 int xs_fileno(struct xs_handle *h);
 
+/* Check for node changes.  On success, returns a non-NULL pointer ret
+ * such that ret[0] and ret[1] are valid C strings, namely the
+ * triggering path (see docs/misc/xenstore.txt) and the token (from
+ * xs_watch).  On error return value is NULL setting errno.
+ * 
+ * Callers should, after xs_fileno has become readable, repeatedly
+ * call xs_check_watch until it returns NULL and sets errno to EAGAIN.
+ * (If the fd became readable, xs_check_watch is allowed to make it no
+ * longer show up as readable even if future calls to xs_check_watch
+ * will return more watch events.)
+ *
+ * After the caller is finished with the returned information it
+ * should be freed all in one go with free(ret).
+ */
+char **xs_check_watch(struct xs_handle *h);
+
 /* Find out what node change was on (will block if nothing pending).
  * Returns array containing the path and token. Use XS_WATCH_* to access these
  * elements. Call free() after use.
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 18:55:51 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 18: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.xensource.com>)
	id 1RZ5bg-0001Fr-8z; Fri, 09 Dec 2011 18:55:40 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RZ5bf-0001BP-1h
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 18:55:39 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1323456879!6616386!15
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI2MQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21479 invoked from network); 9 Dec 2011 18:54:49 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 18:54:49 -0000
X-IronPort-AV: E=Sophos;i="4.71,327,1320624000"; 
   d="scan'208";a="9392206"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 18:54:49 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 18:54:48 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RZ5aq-0002eO-Om; Fri, 09 Dec 2011 18:54:48 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RZ5aq-00040p-O1;
	Fri, 09 Dec 2011 18:54:48 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Fri, 9 Dec 2011 18:54:33 +0000
Message-ID: <1323456877-15315-15-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1323456877-15315-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1323456877-15315-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 14/18] libxl: make LIBXL_INIT_GC a statement,
	not an initialiser
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Previously LIBXL_INIT_GC was an initialiser, which you were expected
to use like this:
    libxl__gc gc = LIBXL_INIT_GC(ctx);

But we are going to want to put things in the gc which are to be
initialised using other macros.  That means that LIBXL_INIT_GC has to
become a statement too.  So instead, we make it so that it's used like this:
    libxl_gc gc;
    LIBXL_INIT_GC(gc,ctx);

In fact there is only one caller now, GC_INIT, which uses this trick:
    libxl_gc gc[1];
    LIBXL_INIT_GC(gc[0],ctx);

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl_internal.h |    9 +++++++--
 1 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 1d1dc35..d015c7c 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -145,7 +145,12 @@ typedef struct {
     libxl_ctx *owner;
 } libxl__gc;
 
-#define LIBXL_INIT_GC(ctx) (libxl__gc){ .alloc_maxsize = 0, .alloc_ptrs = 0, .owner = ctx }
+#define LIBXL_INIT_GC(gc,ctx) do{               \
+        (gc).alloc_maxsize = 0;                 \
+        (gc).alloc_ptrs = 0;                    \
+        (gc).owner = (ctx);                     \
+    } while(0)
+
 static inline libxl_ctx *libxl__gc_owner(libxl__gc *gc)
 {
     return gc->owner;
@@ -676,7 +681,7 @@ libxl__device_model_version_running(libxl__gc *gc, uint32_t domid);
  * as a local variable.
  */
 
-#define GC_INIT(ctx)  libxl__gc gc[1] = { LIBXL_INIT_GC(ctx) }
+#define GC_INIT(ctx)  libxl__gc gc[1]; LIBXL_INIT_GC(gc[0],ctx)
 #define GC_FREE       libxl__free_all(gc)
 #define CTX           libxl__gc_owner(gc)
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 18:55:51 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 18: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.xensource.com>)
	id 1RZ5be-0001Dm-1S; Fri, 09 Dec 2011 18:55:38 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RZ5bc-0001Au-49
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 18:55:36 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1323456879!6616386!9
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI2MQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21357 invoked from network); 9 Dec 2011 18:54:46 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 18:54:46 -0000
X-IronPort-AV: E=Sophos;i="4.71,327,1320624000"; 
   d="scan'208";a="9392200"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 18:54:46 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 18:54:46 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RZ5an-0002e6-RN; Fri, 09 Dec 2011 18:54:45 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RZ5an-00040R-Qb;
	Fri, 09 Dec 2011 18:54:45 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Fri, 9 Dec 2011 18:54:27 +0000
Message-ID: <1323456877-15315-9-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1323456877-15315-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1323456877-15315-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 08/18] libxl: Rationalise #includes
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

libxl_internal.h now #includes libxl.h and various system headers.

This
 1. makes the order of header inclusion more predictable
 2. explicitly allows libxl_internal.h to use objects defined in libxl.h
 3. removes the need for individual files to include these headers

Also
 - remove some unnecessary #includes of libxl_utils.h,
   flexarray.h, etc. in some libxl*.c files,
 - include libxl_osdeps.h at the top of libxl_internal.h
 - add missing includes of libxl_osdeps.h to a couple of files
 - change libxl.h to libxl_internal.h in a couple of files

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl.c            |    3 ---
 tools/libxl/libxl_blktap2.c    |    1 -
 tools/libxl/libxl_bootloader.c |    4 ----
 tools/libxl/libxl_cpuid.c      |    4 ----
 tools/libxl/libxl_create.c     |    4 +---
 tools/libxl/libxl_device.c     |    1 -
 tools/libxl/libxl_dm.c         |    4 +---
 tools/libxl/libxl_dom.c        |    1 -
 tools/libxl/libxl_exec.c       |    1 -
 tools/libxl/libxl_flask.c      |    3 ++-
 tools/libxl/libxl_internal.c   |    4 ----
 tools/libxl/libxl_internal.h   |    5 +++++
 tools/libxl/libxl_json.c       |    3 ++-
 tools/libxl/libxl_noblktap2.c  |    2 --
 tools/libxl/libxl_nocpuid.c    |    2 +-
 tools/libxl/libxl_paths.c      |    2 +-
 tools/libxl/libxl_pci.c        |    5 -----
 tools/libxl/libxl_qmp.c        |    2 ++
 tools/libxl/libxl_utils.c      |    1 -
 tools/libxl/libxl_uuid.c       |    4 ++++
 tools/libxl/libxl_xshelp.c     |    1 -
 21 files changed, 19 insertions(+), 38 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index a171142..bc17b15 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -31,10 +31,7 @@
 #include <inttypes.h>
 #include <assert.h>
 
-#include "libxl.h"
-#include "libxl_utils.h"
 #include "libxl_internal.h"
-#include "flexarray.h"
 
 #define PAGE_TO_MEMKB(pages) ((pages) * 4)
 #define BACKEND_STRING_SIZE 5
diff --git a/tools/libxl/libxl_blktap2.c b/tools/libxl/libxl_blktap2.c
index c8d9148..acf4110 100644
--- a/tools/libxl/libxl_blktap2.c
+++ b/tools/libxl/libxl_blktap2.c
@@ -12,7 +12,6 @@
  * GNU Lesser General Public License for more details.
  */
 
-#include "libxl.h"
 #include "libxl_osdeps.h"
 #include "libxl_internal.h"
 
diff --git a/tools/libxl/libxl_bootloader.c b/tools/libxl/libxl_bootloader.c
index 47bb3a1..b8399a1 100644
--- a/tools/libxl/libxl_bootloader.c
+++ b/tools/libxl/libxl_bootloader.c
@@ -14,7 +14,6 @@
 
 #include "libxl_osdeps.h"
 
-#include <string.h>
 #include <unistd.h>
 #include <fcntl.h>
 #include <termios.h>
@@ -22,11 +21,8 @@
 #include <sys/stat.h>
 #include <sys/types.h>
 
-#include "libxl.h"
 #include "libxl_internal.h"
 
-#include "flexarray.h"
-
 #define XENCONSOLED_BUF_SIZE 16
 #define BOOTLOADER_BUF_SIZE 4096
 #define BOOTLOADER_TIMEOUT 1
diff --git a/tools/libxl/libxl_cpuid.c b/tools/libxl/libxl_cpuid.c
index 78bcab5..56a00cd 100644
--- a/tools/libxl/libxl_cpuid.c
+++ b/tools/libxl/libxl_cpuid.c
@@ -10,10 +10,6 @@
  * GNU Lesser General Public License for more details.
  */
 
-#include <string.h>
-
-#include "libxl.h"
-#include "libxl_osdeps.h"
 #include "libxl_internal.h"
 
 void libxl_cpuid_dispose(libxl_cpuid_policy_list *p_cpuid_list)
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index ce6a55e..ccb56c7 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -26,10 +26,8 @@
 #include <xc_dom.h>
 #include <xenguest.h>
 #include <assert.h>
-#include "libxl.h"
-#include "libxl_utils.h"
+
 #include "libxl_internal.h"
-#include "flexarray.h"
 
 void libxl_domain_config_dispose(libxl_domain_config *d_config)
 {
diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c
index a53fb70..46254ea 100644
--- a/tools/libxl/libxl_device.c
+++ b/tools/libxl/libxl_device.c
@@ -24,7 +24,6 @@
 #include <unistd.h>
 #include <fcntl.h>
 
-#include "libxl.h"
 #include "libxl_internal.h"
 
 char *libxl__device_frontend_path(libxl__gc *gc, libxl__device *device)
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index cef80be..05c83cd 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -24,10 +24,8 @@
 #include <unistd.h>
 #include <fcntl.h>
 #include <assert.h>
-#include "libxl_utils.h"
+
 #include "libxl_internal.h"
-#include "libxl.h"
-#include "flexarray.h"
 
 static const char *libxl_tapif_script(libxl__gc *gc)
 {
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index b74db34..96098de 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -32,7 +32,6 @@
 
 #include <xen/hvm/hvm_info_table.h>
 
-#include "libxl.h"
 #include "libxl_internal.h"
 
 libxl_domain_type libxl__domain_type(libxl__gc *gc, uint32_t domid)
diff --git a/tools/libxl/libxl_exec.c b/tools/libxl/libxl_exec.c
index 1a62d47..52d40d1 100644
--- a/tools/libxl/libxl_exec.c
+++ b/tools/libxl/libxl_exec.c
@@ -28,7 +28,6 @@
 #include <signal.h> /* for SIGKILL */
 #include <fcntl.h>
 
-#include "libxl.h"
 #include "libxl_internal.h"
 
 static int call_waitpid(pid_t (*waitpid_cb)(pid_t, int *, int), pid_t pid, int *status, int options)
diff --git a/tools/libxl/libxl_flask.c b/tools/libxl/libxl_flask.c
index c8d0594..6b548dd 100644
--- a/tools/libxl/libxl_flask.c
+++ b/tools/libxl/libxl_flask.c
@@ -7,13 +7,14 @@
  *  as published by the Free Software Foundation.
  */
 
+#include "libxl_osdeps.h"
+
 #include <stdio.h>
 #include <stdlib.h>
 #include <string.h>
 #include <errno.h>
 #include <xenctrl.h>
 
-#include "libxl.h"
 #include "libxl_internal.h"
 
 int libxl_flask_context_to_sid(libxl_ctx *ctx, char *buf, size_t len,
diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c
index 34edaf3..d767ce3 100644
--- a/tools/libxl/libxl_internal.c
+++ b/tools/libxl/libxl_internal.c
@@ -16,8 +16,6 @@
 #include "libxl_osdeps.h"
 
 #include <stdio.h>
-#include <stdarg.h>
-#include <string.h>
 
 #include <sys/types.h>
 #include <sys/stat.h>
@@ -25,9 +23,7 @@
 #include <sys/mman.h>
 #include <unistd.h>
 
-#include "libxl.h"
 #include "libxl_internal.h"
-#include "libxl_utils.h"
 
 int libxl__error_set(libxl__gc *gc, int code)
 {
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 950c466..cda6fc1 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -17,14 +17,19 @@
 #ifndef LIBXL_INTERNAL_H
 #define LIBXL_INTERNAL_H
 
+#include "libxl_osdeps.h"
+
 #include <stdint.h>
 #include <stdarg.h>
 #include <stdlib.h>
+#include <string.h>
 
 #include <xs.h>
 #include <xenctrl.h>
 #include "xentoollog.h"
 
+#include "libxl.h"
+
 #if __GNUC__ > 3 || (__GNUC__ == 3 && __GNUC_MINOR__ >= 1)
 #define _hidden __attribute__((visibility("hidden")))
 #define _protected __attribute__((visibility("protected")))
diff --git a/tools/libxl/libxl_json.c b/tools/libxl/libxl_json.c
index fd5e2aa..c0f869e 100644
--- a/tools/libxl/libxl_json.c
+++ b/tools/libxl/libxl_json.c
@@ -12,6 +12,8 @@
  * GNU Lesser General Public License for more details.
  */
 
+#include "libxl_osdeps.h"
+
 #include <assert.h>
 #include <string.h>
 #include <math.h>
@@ -19,7 +21,6 @@
 #include <yajl/yajl_parse.h>
 #include <yajl/yajl_gen.h>
 
-#include <libxl.h>
 #include "libxl_internal.h"
 
 /* #define DEBUG_ANSWER */
diff --git a/tools/libxl/libxl_noblktap2.c b/tools/libxl/libxl_noblktap2.c
index 704d03f..3307551 100644
--- a/tools/libxl/libxl_noblktap2.c
+++ b/tools/libxl/libxl_noblktap2.c
@@ -12,8 +12,6 @@
  * GNU Lesser General Public License for more details.
  */
 
-#include "libxl.h"
-#include "libxl_osdeps.h"
 #include "libxl_internal.h"
 
 int libxl__blktap_enabled(libxl__gc *gc)
diff --git a/tools/libxl/libxl_nocpuid.c b/tools/libxl/libxl_nocpuid.c
index d63757f..2e9490c 100644
--- a/tools/libxl/libxl_nocpuid.c
+++ b/tools/libxl/libxl_nocpuid.c
@@ -10,7 +10,7 @@
  * GNU Lesser General Public License for more details.
  */
 
-#include "libxl.h"
+#include "libxl_internal.h"
 
 void libxl_cpuid_destroy(libxl_cpuid_policy_list *p_cpuid_list)
 {
diff --git a/tools/libxl/libxl_paths.c b/tools/libxl/libxl_paths.c
index c84e51d..e7bd1a2 100644
--- a/tools/libxl/libxl_paths.c
+++ b/tools/libxl/libxl_paths.c
@@ -12,7 +12,7 @@
  * GNU Lesser General Public License for more details.
  */
 
-#include "libxl.h"
+#include "libxl_internal.h"
 #include "_libxl_paths.h"
 
 const char *libxl_sbindir_path(void)
diff --git a/tools/libxl/libxl_pci.c b/tools/libxl/libxl_pci.c
index 4186cf8..63c3050 100644
--- a/tools/libxl/libxl_pci.c
+++ b/tools/libxl/libxl_pci.c
@@ -17,7 +17,6 @@
 #include "libxl_osdeps.h"
 
 #include <stdio.h>
-#include <string.h>
 #include <stdlib.h>
 #include <sys/types.h>
 #include <fcntl.h>
@@ -27,15 +26,11 @@
 #include <sys/stat.h>
 #include <signal.h>
 #include <unistd.h> /* for write, unlink and close */
-#include <stdint.h>
 #include <inttypes.h>
 #include <dirent.h>
 #include <assert.h>
 
-#include "libxl.h"
-#include "libxl_utils.h"
 #include "libxl_internal.h"
-#include "flexarray.h"
 
 #define PCI_BDF                "%04x:%02x:%02x.%01x"
 #define PCI_BDF_SHORT          "%02x:%02x.%01x"
diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
index f749e01..c7696d7 100644
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/libxl/libxl_qmp.c
@@ -18,6 +18,8 @@
  * Specification, see in the QEMU repository.
  */
 
+#include "libxl_osdeps.h"
+
 #include <unistd.h>
 #include <sys/un.h>
 #include <sys/queue.h>
diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
index 1fa2c0f..f1f2a6d 100644
--- a/tools/libxl/libxl_utils.c
+++ b/tools/libxl/libxl_utils.c
@@ -28,7 +28,6 @@
 #include <unistd.h>
 #include <assert.h>
 
-#include "libxl_utils.h"
 #include "libxl_internal.h"
 
 struct schedid_name {
diff --git a/tools/libxl/libxl_uuid.c b/tools/libxl/libxl_uuid.c
index e837228..80ab789 100644
--- a/tools/libxl/libxl_uuid.c
+++ b/tools/libxl/libxl_uuid.c
@@ -12,8 +12,12 @@
  * GNU Lesser General Public License for more details.
  */
 
+#include "libxl_osdeps.h"
+
 #include <libxl_uuid.h>
 
+#include "libxl_internal.h"
+
 #if defined(__linux__)
 
 int libxl_uuid_is_nil(libxl_uuid *uuid)
diff --git a/tools/libxl/libxl_xshelp.c b/tools/libxl/libxl_xshelp.c
index bc4e7e4..ea835e2 100644
--- a/tools/libxl/libxl_xshelp.c
+++ b/tools/libxl/libxl_xshelp.c
@@ -21,7 +21,6 @@
 #include <stdarg.h>
 #include <inttypes.h>
 
-#include "libxl.h"
 #include "libxl_internal.h"
 
 char **libxl__xs_kvs_of_flexarray(libxl__gc *gc, flexarray_t *array, int length)
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 18:55:51 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 18: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.xensource.com>)
	id 1RZ5bb-0001C1-FW; Fri, 09 Dec 2011 18:55:35 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RZ5bZ-0001Ai-Nf
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 18:55:33 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1323456879!6616386!5
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI2MQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21254 invoked from network); 9 Dec 2011 18:54:43 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 18:54:43 -0000
X-IronPort-AV: E=Sophos;i="4.71,327,1320624000"; 
   d="scan'208";a="9392196"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 18:54:43 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 18:54:43 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RZ5al-0002du-DQ; Fri, 09 Dec 2011 18:54:43 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RZ5al-000408-Cf;
	Fri, 09 Dec 2011 18:54:43 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Fri, 9 Dec 2011 18:54:23 +0000
Message-ID: <1323456877-15315-5-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1323456877-15315-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1323456877-15315-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 04/18] libxl: idl: support new "private" type
	attribute
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This provides for fields in libxl datatypes which are only present in
the C version of structures and are used only by libxl itself.  This
is useful when a libxl datatype wants to contain fields which are used
by libxl internally and which are only present in the structure to
avoid additional memory allocation inconvenience.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/gentest.py    |    2 ++
 tools/libxl/libxltypes.py |    4 +++-
 tools/python/genwrap.py   |    6 ++++++
 3 files changed, 11 insertions(+), 1 deletions(-)

diff --git a/tools/libxl/gentest.py b/tools/libxl/gentest.py
index 05e77cc..ac7a400 100644
--- a/tools/libxl/gentest.py
+++ b/tools/libxl/gentest.py
@@ -56,6 +56,8 @@ def gen_rand_init(ty, v, indent = "    ", parent = None):
         s += "%s = rand() %% 2;\n" % v
     elif ty.typename in ["char *"]:
         s += "%s = rand_str();\n" % v
+    elif ty.private:
+        pass
     elif ty.typename in handcoded:
         raise Exception("Gen for handcoded %s" % ty.typename)
     else:
diff --git a/tools/libxl/libxltypes.py b/tools/libxl/libxltypes.py
index 55056c2..450de88 100644
--- a/tools/libxl/libxltypes.py
+++ b/tools/libxl/libxltypes.py
@@ -33,6 +33,8 @@ class Type(object):
         if self.passby not in [PASS_BY_VALUE, PASS_BY_REFERENCE]:
             raise ValueError
 
+        self.private = kwargs.setdefault('private', False)
+
         if typename is None: # Anonymous type
             self.typename = None
             self.rawname = None
@@ -50,7 +52,7 @@ class Type(object):
 
         self.autogenerate_dispose_fn = kwargs.setdefault('autogenerate_dispose_fn', True)
 
-        if self.typename is not None:
+        if self.typename is not None and not self.private:
             self.json_fn = kwargs.setdefault('json_fn', self.typename + "_gen_json")
         else:
             self.json_fn = kwargs.setdefault('json_fn', None)
diff --git a/tools/python/genwrap.py b/tools/python/genwrap.py
index d0c193d..a5febee 100644
--- a/tools/python/genwrap.py
+++ b/tools/python/genwrap.py
@@ -129,6 +129,8 @@ static PyObject *Py%(rawname)s_new(PyTypeObject *type, PyObject *args, PyObject
 
     l.append('static PyGetSetDef Py%s_getset[] = {'%ty.rawname)
     for f in ty.fields:
+        if f.type.private:
+            continue
         l.append('    { .name = "%s", '%f.name)
         if ty.marshal_out():
             l.append('      .get = (getter)py_%s_%s_get, '%(ty.rawname, f.name))
@@ -295,9 +297,13 @@ _hidden int genwrap__ll_set(PyObject *v, long long *val, long long mask);
 
 """ % tuple((' '.join(sys.argv),) + (os.path.split(decls)[-1:]),))
     for ty in types:
+        if ty.private:
+            continue
         if isinstance(ty, libxltypes.Aggregate):
             f.write('/* Attribute get/set functions for %s */\n'%ty.typename)
             for a in ty.fields:
+                if a.type.private:
+                    continue
                 if ty.marshal_out():
                     f.write(py_attrib_get(ty,a))
                 if ty.marshal_in():
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 18:55:51 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 18: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.xensource.com>)
	id 1RZ5bh-0001HH-H0; Fri, 09 Dec 2011 18:55:41 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RZ5bf-0001Bh-MI
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 18:55:39 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1323456879!6616386!17
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI2MQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21522 invoked from network); 9 Dec 2011 18:54:49 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 18:54:49 -0000
X-IronPort-AV: E=Sophos;i="4.71,327,1320624000"; 
   d="scan'208";a="9392208"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 18:54:49 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 18:54:49 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RZ5ar-0002eU-IK; Fri, 09 Dec 2011 18:54:49 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RZ5ar-00040x-HY;
	Fri, 09 Dec 2011 18:54:49 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Fri, 9 Dec 2011 18:54:35 +0000
Message-ID: <1323456877-15315-17-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1323456877-15315-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1323456877-15315-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 16/18] libxl: rename libxl__free_all
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

libxl__free_all is going to gain some extra functionality, which will
mean that the name is no longer accurate.  Rename it to
libxl__gc_cleanup.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl.h          |    2 +-
 tools/libxl/libxl_internal.c |    2 +-
 tools/libxl/libxl_internal.h |    4 ++--
 3 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 289dc85..9e8ca29 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -119,7 +119,7 @@
  *
  * No temporary objects allocated from the pool may be explicitly freed.
  * Therefore public functions which initialize a libxl__gc MUST call
- * libxl__free_all() before returning.
+ * libxl__gc_cleanup() before returning.
  */
 #ifndef LIBXL_H
 #define LIBXL_H
diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c
index a2e5820..232cc4a 100644
--- a/tools/libxl/libxl_internal.c
+++ b/tools/libxl/libxl_internal.c
@@ -61,7 +61,7 @@ int libxl__ptr_add(libxl__gc *gc, void *ptr)
     return 0;
 }
 
-void libxl__free_all(libxl__gc *gc)
+void libxl__gc_cleanup(libxl__gc *gc)
 {
     void *ptr;
     int i;
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index d015c7c..536a1ec 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -171,7 +171,7 @@ static inline libxl_ctx *libxl__gc_owner(libxl__gc *gc)
 /* register @ptr in @gc for free on exit from outermost libxl callframe. */
 _hidden int libxl__ptr_add(libxl__gc *gc, void *ptr);
 /* if this is the outermost libxl callframe then free all pointers in @gc */
-_hidden void libxl__free_all(libxl__gc *gc);
+_hidden void libxl__gc_cleanup(libxl__gc *gc);
 /* allocate and zero @bytes. (similar to a gc'd malloc(3)+memzero()) */
 _hidden void *libxl__zalloc(libxl__gc *gc, int bytes);
 /* allocate and zero memory for an array of @nmemb members of @size each.
@@ -682,7 +682,7 @@ libxl__device_model_version_running(libxl__gc *gc, uint32_t domid);
  */
 
 #define GC_INIT(ctx)  libxl__gc gc[1]; LIBXL_INIT_GC(gc[0],ctx)
-#define GC_FREE       libxl__free_all(gc)
+#define GC_FREE       libxl__gc_cleanup(gc)
 #define CTX           libxl__gc_owner(gc)
 
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 18:55:51 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 18: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.xensource.com>)
	id 1RZ5bg-0001Fr-8z; Fri, 09 Dec 2011 18:55:40 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RZ5bf-0001BP-1h
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 18:55:39 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1323456879!6616386!15
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI2MQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21479 invoked from network); 9 Dec 2011 18:54:49 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 18:54:49 -0000
X-IronPort-AV: E=Sophos;i="4.71,327,1320624000"; 
   d="scan'208";a="9392206"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 18:54:49 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 18:54:48 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RZ5aq-0002eO-Om; Fri, 09 Dec 2011 18:54:48 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RZ5aq-00040p-O1;
	Fri, 09 Dec 2011 18:54:48 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Fri, 9 Dec 2011 18:54:33 +0000
Message-ID: <1323456877-15315-15-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1323456877-15315-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1323456877-15315-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 14/18] libxl: make LIBXL_INIT_GC a statement,
	not an initialiser
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Previously LIBXL_INIT_GC was an initialiser, which you were expected
to use like this:
    libxl__gc gc = LIBXL_INIT_GC(ctx);

But we are going to want to put things in the gc which are to be
initialised using other macros.  That means that LIBXL_INIT_GC has to
become a statement too.  So instead, we make it so that it's used like this:
    libxl_gc gc;
    LIBXL_INIT_GC(gc,ctx);

In fact there is only one caller now, GC_INIT, which uses this trick:
    libxl_gc gc[1];
    LIBXL_INIT_GC(gc[0],ctx);

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl_internal.h |    9 +++++++--
 1 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 1d1dc35..d015c7c 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -145,7 +145,12 @@ typedef struct {
     libxl_ctx *owner;
 } libxl__gc;
 
-#define LIBXL_INIT_GC(ctx) (libxl__gc){ .alloc_maxsize = 0, .alloc_ptrs = 0, .owner = ctx }
+#define LIBXL_INIT_GC(gc,ctx) do{               \
+        (gc).alloc_maxsize = 0;                 \
+        (gc).alloc_ptrs = 0;                    \
+        (gc).owner = (ctx);                     \
+    } while(0)
+
 static inline libxl_ctx *libxl__gc_owner(libxl__gc *gc)
 {
     return gc->owner;
@@ -676,7 +681,7 @@ libxl__device_model_version_running(libxl__gc *gc, uint32_t domid);
  * as a local variable.
  */
 
-#define GC_INIT(ctx)  libxl__gc gc[1] = { LIBXL_INIT_GC(ctx) }
+#define GC_INIT(ctx)  libxl__gc gc[1]; LIBXL_INIT_GC(gc[0],ctx)
 #define GC_FREE       libxl__free_all(gc)
 #define CTX           libxl__gc_owner(gc)
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 18:55:51 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 18: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.xensource.com>)
	id 1RZ5ba-0001BZ-2B; Fri, 09 Dec 2011 18:55:34 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RZ5bY-0001Ag-SM
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 18:55:33 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1323456879!6616386!3
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI2MQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21226 invoked from network); 9 Dec 2011 18:54:42 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 18:54:42 -0000
X-IronPort-AV: E=Sophos;i="4.71,327,1320624000"; 
   d="scan'208";a="9392194"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 18:54:42 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 18:54:42 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RZ5ak-0002do-6y; Fri, 09 Dec 2011 18:54:42 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RZ5ak-0003zy-6D;
	Fri, 09 Dec 2011 18:54:42 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Fri, 9 Dec 2011 18:54:21 +0000
Message-ID: <1323456877-15315-3-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1323456877-15315-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1323456877-15315-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 02/18] libxenstore: Provide xs_check_watch
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Event-driven programs want to wait until the xs_fileno triggers for
reading, and then repeatedly call xs_check_watch.

Also xs_read_watch exposes a useless "num" out parameter, which should
always (if things aren't going hideously wrong) be at least 2 and
which the caller shouldn't be interested in.  So xs_check_watch
doesn't have one of those.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/xenstore/Makefile |    2 +-
 tools/xenstore/xs.c     |   89 ++++++++++++++++++++++++++++++++++++++++------
 tools/xenstore/xs.h     |   16 ++++++++
 3 files changed, 94 insertions(+), 13 deletions(-)

diff --git a/tools/xenstore/Makefile b/tools/xenstore/Makefile
index bd3e8f1..4facb62 100644
--- a/tools/xenstore/Makefile
+++ b/tools/xenstore/Makefile
@@ -2,7 +2,7 @@ XEN_ROOT=$(CURDIR)/../..
 include $(XEN_ROOT)/tools/Rules.mk
 
 MAJOR = 3.0
-MINOR = 0
+MINOR = 1
 
 CFLAGS += -Werror
 CFLAGS += -I.
diff --git a/tools/xenstore/xs.c b/tools/xenstore/xs.c
index df270f7..8e54fe0 100644
--- a/tools/xenstore/xs.c
+++ b/tools/xenstore/xs.c
@@ -132,7 +132,23 @@ struct xs_handle {
 
 #endif
 
-static int read_message(struct xs_handle *h);
+static int read_message(struct xs_handle *h, int nonblocking);
+
+static void setnonblock(int fd, int nonblock) {
+	int esave = errno;
+	int flags = fcntl(fd, F_GETFL);
+	if (flags == -1)
+		goto out;
+
+	if (nonblock)
+		flags |= O_NONBLOCK;
+	else
+		flags &= ~O_NONBLOCK;
+
+	fcntl(fd, F_SETFL, flags);
+out:
+	errno = esave;
+}
 
 int xs_fileno(struct xs_handle *h)
 {
@@ -325,8 +341,16 @@ void xs_close(struct xs_handle* xsh)
 		xs_daemon_close(xsh);
 }
 
-static bool read_all(int fd, void *data, unsigned int len)
+static bool read_all(int fd, void *data, unsigned int len, int nonblocking)
+	/* With nonblocking, either reads either everything requested,
+	 * or nothing. */
 {
+	if (!len)
+		return true;
+
+	if (nonblocking)
+		setnonblock(fd, 1);
+
 	while (len) {
 		int done;
 
@@ -334,18 +358,28 @@ static bool read_all(int fd, void *data, unsigned int len)
 		if (done < 0) {
 			if (errno == EINTR)
 				continue;
-			return false;
+			goto out_false;
 		}
 		if (done == 0) {
 			/* It closed fd on us?  EBADF is appropriate. */
 			errno = EBADF;
-			return false;
+			goto out_false;
 		}
 		data += done;
 		len -= done;
+
+		if (nonblocking) {
+			setnonblock(fd, 0);
+			nonblocking = 0;
+		}
 	}
 
 	return true;
+
+out_false:
+	if (nonblocking)
+		setnonblock(fd, 0);
+	return false;
 }
 
 #ifdef XSTEST
@@ -374,7 +408,7 @@ static void *read_reply(
 	read_from_thread = read_thread_exists(h);
 
 	/* Read from comms channel ourselves if there is no reader thread. */
-	if (!read_from_thread && (read_message(h) == -1))
+	if (!read_from_thread && (read_message(h, 0) == -1))
 		return NULL;
 
 	mutex_lock(&h->reply_mutex);
@@ -693,7 +727,8 @@ bool xs_watch(struct xs_handle *h, const char *path, const char *token)
  * Returns array of two pointers: path and token, or NULL.
  * Call free() after use.
  */
-char **xs_read_watch(struct xs_handle *h, unsigned int *num)
+static char **read_watch_internal(struct xs_handle *h, unsigned int *num,
+				  int nonblocking)
 {
 	struct xs_stored_msg *msg;
 	char **ret, *strings, c = 0;
@@ -707,14 +742,20 @@ char **xs_read_watch(struct xs_handle *h, unsigned int *num)
 	 * we haven't called xs_watch.	Presumably the application
 	 * will do so later; in the meantime we just block.
 	 */
-	while (list_empty(&h->watch_list) && h->fd != -1)
+	while (list_empty(&h->watch_list) && h->fd != -1) {
+		if (nonblocking) {
+			mutex_unlock(&h->watch_mutex);
+			errno = EAGAIN;
+			return 0;
+		}
 		condvar_wait(&h->watch_condvar, &h->watch_mutex);
+	}
 #else /* !defined(USE_PTHREAD) */
 	/* Read from comms channel ourselves if there are no threads
 	 * and therefore no reader thread. */
 
 	assert(!read_thread_exists(h)); /* not threadsafe but worth a check */
-	if ((read_message(h) == -1))
+	if ((read_message(h, nonblocking) == -1))
 		return NULL;
 
 #endif /* !defined(USE_PTHREAD) */
@@ -760,6 +801,24 @@ char **xs_read_watch(struct xs_handle *h, unsigned int *num)
 	return ret;
 }
 
+char **xs_check_watch(struct xs_handle *h)
+{
+	unsigned int num;
+	char **ret;
+	ret = read_watch_internal(h, &num, 1);
+	if (ret) assert(num >= 2);
+	return ret;
+}
+
+/* Find out what node change was on (will block if nothing pending).
+ * Returns array of two pointers: path and token, or NULL.
+ * Call free() after use.
+ */
+char **xs_read_watch(struct xs_handle *h, unsigned int *num)
+{
+	return read_watch_internal(h, num, 0);
+}
+
 /* Remove a watch on a node.
  * Returns false on failure (no watch on that node).
  */
@@ -940,11 +999,17 @@ char *xs_debug_command(struct xs_handle *h, const char *cmd,
 			ARRAY_SIZE(iov), NULL);
 }
 
-static int read_message(struct xs_handle *h)
+static int read_message(struct xs_handle *h, int nonblocking)
 {
 	/* IMPORTANT: It is forbidden to call this function without
 	 * acquiring the request lock and checking that h->read_thr_exists
 	 * is false.  See "Lock discipline" in struct xs_handle, above. */
+
+	/* If nonblocking==1, this function will always read either
+	 * nothing, returning -1 and setting errno==EAGAIN, or we read
+	 * whole amount requested.  Ie as soon as we have the start of
+	 * the message we block until we get all of it.
+	 */
          
 	struct xs_stored_msg *msg = NULL;
 	char *body = NULL;
@@ -956,7 +1021,7 @@ static int read_message(struct xs_handle *h)
 	if (msg == NULL)
 		goto error;
 	cleanup_push(free, msg);
-	if (!read_all(h->fd, &msg->hdr, sizeof(msg->hdr))) { /* Cancellation point */
+	if (!read_all(h->fd, &msg->hdr, sizeof(msg->hdr), nonblocking)) { /* Cancellation point */
 		saved_errno = errno;
 		goto error_freemsg;
 	}
@@ -966,7 +1031,7 @@ static int read_message(struct xs_handle *h)
 	if (body == NULL)
 		goto error_freemsg;
 	cleanup_push(free, body);
-	if (!read_all(h->fd, body, msg->hdr.len)) { /* Cancellation point */
+	if (!read_all(h->fd, body, msg->hdr.len, 0)) { /* Cancellation point */
 		saved_errno = errno;
 		goto error_freebody;
 	}
@@ -1021,7 +1086,7 @@ static void *read_thread(void *arg)
 	struct xs_handle *h = arg;
 	int fd;
 
-	while (read_message(h) != -1)
+	while (read_message(h, 0) != -1)
 		continue;
 
 	/* An error return from read_message leaves the socket in an undefined
diff --git a/tools/xenstore/xs.h b/tools/xenstore/xs.h
index 1cbe255..63f535d 100644
--- a/tools/xenstore/xs.h
+++ b/tools/xenstore/xs.h
@@ -135,6 +135,22 @@ bool xs_watch(struct xs_handle *h, const char *path, const char *token);
 /* Return the FD to poll on to see if a watch has fired. */
 int xs_fileno(struct xs_handle *h);
 
+/* Check for node changes.  On success, returns a non-NULL pointer ret
+ * such that ret[0] and ret[1] are valid C strings, namely the
+ * triggering path (see docs/misc/xenstore.txt) and the token (from
+ * xs_watch).  On error return value is NULL setting errno.
+ * 
+ * Callers should, after xs_fileno has become readable, repeatedly
+ * call xs_check_watch until it returns NULL and sets errno to EAGAIN.
+ * (If the fd became readable, xs_check_watch is allowed to make it no
+ * longer show up as readable even if future calls to xs_check_watch
+ * will return more watch events.)
+ *
+ * After the caller is finished with the returned information it
+ * should be freed all in one go with free(ret).
+ */
+char **xs_check_watch(struct xs_handle *h);
+
 /* Find out what node change was on (will block if nothing pending).
  * Returns array containing the path and token. Use XS_WATCH_* to access these
  * elements. Call free() after use.
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 18:55:51 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 18: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.xensource.com>)
	id 1RZ5bj-0001Jz-6t; Fri, 09 Dec 2011 18:55:43 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RZ5bg-0001C3-SG
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 18:55:41 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1323456890!5661081!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI2MQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15635 invoked from network); 9 Dec 2011 18:54:51 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 18:54:51 -0000
X-IronPort-AV: E=Sophos;i="4.71,327,1320624000"; 
   d="scan'208";a="9392209"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 18:54:50 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 18:54:50 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RZ5ar-0002eZ-Ua; Fri, 09 Dec 2011 18:54:49 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RZ5ar-000411-Tg;
	Fri, 09 Dec 2011 18:54:49 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Fri, 9 Dec 2011 18:54:36 +0000
Message-ID: <1323456877-15315-18-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1323456877-15315-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1323456877-15315-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 17/18] libxl: New API for providing OS events to
	libxl
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

We provide a new set of functions and related structures
  libxl_osevent_*
which are to be used by event-driven applications to receive
information from libxl about which fds libxl is interested in, and
what timeouts libxl is waiting for, and to pass back to libxl
information about which fds are readable/writeable etc., and which
timeouts have occurred.  Ie, low-level events.

In this patch, this new machinery is still all unused.  Callers will
appear in the next patch in the series, which introduces a new API for
applications to receive high-level events about actual domains etc.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/Makefile         |    2 +-
 tools/libxl/libxl.c          |   30 ++
 tools/libxl/libxl.h          |    6 +
 tools/libxl/libxl_event.c    |  736 ++++++++++++++++++++++++++++++++++++++++++
 tools/libxl/libxl_event.h    |  200 ++++++++++++
 tools/libxl/libxl_internal.h |  219 ++++++++++++-
 6 files changed, 1189 insertions(+), 4 deletions(-)
 create mode 100644 tools/libxl/libxl_event.c
 create mode 100644 tools/libxl/libxl_event.h

diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index 70c9c1c..1084a7c 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -38,7 +38,7 @@ LIBXL_LIBS += -lyajl
 LIBXL_OBJS = flexarray.o libxl.o libxl_create.o libxl_dm.o libxl_pci.o \
 			libxl_dom.o libxl_exec.o libxl_xshelp.o libxl_device.o \
 			libxl_internal.o libxl_utils.o libxl_uuid.o libxl_json.o \
-			libxl_qmp.o $(LIBXL_OBJS-y)
+			libxl_qmp.o libxl_event.o $(LIBXL_OBJS-y)
 LIBXL_OBJS += _libxl_types.o libxl_flask.o _libxl_types_internal.o
 
 $(LIBXL_OBJS): CFLAGS += $(CFLAGS_libxenctrl) $(CFLAGS_libxenguest) $(CFLAGS_libxenstore) $(CFLAGS_libblktapctl)
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 79ea701..23a7539 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -60,6 +60,16 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
      * only as an initialiser, not as an expression. */
     memcpy(&ctx->lock, &mutex_value, sizeof(ctx->lock));
 
+    ctx->osevent_hooks = 0;
+
+    ctx->fd_beforepolled = 0;
+    LIBXL_LIST_INIT(&ctx->efds);
+    LIBXL_TAILQ_INIT(&ctx->etimes);
+
+    ctx->watch_slots = 0;
+    LIBXL_SLIST_INIT(&ctx->watch_freeslots);
+    libxl__ev_fd_init(&ctx->watch_efd);
+
     if ( stat(XENSTORE_PID_FILE, &stat_buf) != 0 ) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "Is xenstore daemon running?\n"
                      "failed to stat %s", XENSTORE_PID_FILE);
@@ -90,9 +100,29 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
 int libxl_ctx_free(libxl_ctx *ctx)
 {
     if (!ctx) return 0;
+
+    int i;
+    GC_INIT(ctx);
+
+    /* Deregister all libxl__ev_KINDs: */
+
+    for (i = 0; i < ctx->watch_nslots; i++)
+        assert(!libxl__watch_slot_contents(gc, i));
+    libxl__ev_fd_deregister(gc, &ctx->watch_efd);
+
+    /* Now there should be no more events requested from the application: */
+
+    assert(LIBXL_LIST_EMPTY(&ctx->efds));
+    assert(LIBXL_TAILQ_EMPTY(&ctx->etimes));
+
     if (ctx->xch) xc_interface_close(ctx->xch);
     libxl_version_info_dispose(&ctx->version_info);
     if (ctx->xsh) xs_daemon_close(ctx->xsh);
+
+    free(ctx->fd_beforepolled);
+    free(ctx->watch_slots);
+
+    GC_FREE;
     free(ctx);
     return 0;
 }
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 9e8ca29..8d6c788 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -137,6 +137,7 @@
 #include <xen/sysctl.h>
 
 #include <libxl_uuid.h>
+#include <_libxl_list.h>
 
 typedef uint8_t libxl_mac[6];
 #define LIBXL_MAC_FMT "%02hhx:%02hhx:%02hhx:%02hhx:%02hhx:%02hhx"
@@ -222,6 +223,9 @@ enum {
     ERROR_BADFAIL = -7,
     ERROR_GUEST_TIMEDOUT = -8,
     ERROR_TIMEDOUT = -9,
+    ERROR_NOT_READY = -10,
+    ERROR_OSEVENT_REG_FAIL = -11,
+    ERROR_BUFFERFULL = -12,
 };
 
 #define LIBXL_VERSION 0
@@ -635,6 +639,8 @@ const char *libxl_lock_dir_path(void);
 const char *libxl_run_dir_path(void);
 const char *libxl_xenpaging_dir_path(void);
 
+#include <libxl_event.h>
+
 #endif /* LIBXL_H */
 
 /*
diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
new file mode 100644
index 0000000..dc6543f
--- /dev/null
+++ b/tools/libxl/libxl_event.c
@@ -0,0 +1,736 @@
+/*
+ * Copyright (C) 2011      Citrix Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU Lesser General Public License as published
+ * by the Free Software Foundation; version 2.1 only. with the special
+ * exception on linking described in file LICENSE.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU Lesser General Public License for more details.
+ */
+/*
+ * Internal event machinery for use by other parts of libxl
+ */
+
+#include <poll.h>
+
+#include "libxl_internal.h"
+
+/*
+ * The counter osevent_in_hook is used to ensure that the application
+ * honours the reentrancy restriction documented in libxl_event.h.
+ *
+ * The application's registration hooks should be called ONLY via
+ * these macros, with the ctx locked.  Likewise all the "occurred"
+ * entrypoints from the application should assert(!in_hook);
+ */
+#define OSEVENT_HOOK_INTERN(defval, hookname, ...)                      \
+    (CTX->osevent_hooks                                                 \
+     ? (CTX->osevent_in_hook++,                                         \
+        CTX->osevent_hooks->hookname(CTX->osevent_user, __VA_ARGS__),   \
+        CTX->osevent_in_hook--)                                         \
+     : defval)
+
+#define OSEVENT_HOOK(hookname,...)                      \
+    OSEVENT_HOOK_INTERN(0, hookname, __VA_ARGS__)
+
+#define OSEVENT_HOOK_VOID(hookname,...)                 \
+    OSEVENT_HOOK_INTERN((void)0, hookname, __VA_ARGS__)
+
+/*
+ * fd events
+ */
+
+int libxl__ev_fd_register(libxl__gc *gc, libxl__ev_fd *ev,
+                          libxl__ev_fd_callback *func,
+                          int fd, short events)
+{
+    int rc;
+
+    assert(fd >= 0);
+
+    CTX_LOCK;
+
+    rc = OSEVENT_HOOK(fd_register, fd, &ev->for_app_reg, events, ev);
+    if (rc) goto out;
+
+    ev->fd = fd;
+    ev->events = events;
+    ev->in_beforepolled = -1;
+    ev->func = func;
+
+    LIBXL_LIST_INSERT_HEAD(&CTX->efds, ev, entry);
+
+    rc = 0;
+
+ out:
+    CTX_UNLOCK;
+    return rc;
+}
+
+int libxl__ev_fd_modify(libxl__gc *gc, libxl__ev_fd *ev, short events)
+{
+    int rc;
+
+    CTX_LOCK;
+    assert(libxl__ev_fd_isregistered(ev));
+
+    rc = OSEVENT_HOOK(fd_modify, ev->fd, &ev->for_app_reg, events);
+    if (rc) goto out;
+
+    ev->events = events;
+
+    rc = 0;
+ out:
+    CTX_UNLOCK;
+    return rc;
+}
+
+void libxl__ev_fd_deregister(libxl__gc *gc, libxl__ev_fd *ev)
+{
+    CTX_LOCK;
+
+    if (!libxl__ev_fd_isregistered(ev))
+        goto out;
+
+    OSEVENT_HOOK_VOID(fd_deregister, ev->fd, ev->for_app_reg);
+    LIBXL_LIST_REMOVE(ev, entry);
+    ev->fd = -1;
+
+    if (ev->in_beforepolled >= 0 &&
+        ev->in_beforepolled < CTX->fd_beforepolled_used)
+        /* remove stale reference */
+        CTX->fd_beforepolled[ev->in_beforepolled] = NULL;
+
+ out:
+    CTX_UNLOCK;
+}
+
+/*
+ * timeouts
+ */
+
+
+int libxl__gettimeofday(libxl__gc *gc, struct timeval *now_r)
+{
+    int rc = gettimeofday(now_r, 0);
+    if (rc) {
+        LIBXL__LOG_ERRNO(CTX, LIBXL__LOG_ERROR, "gettimeofday failed");
+        return ERROR_FAIL;
+    }
+    return 0;
+}
+
+static int time_rel_to_abs(libxl__gc *gc, int ms, struct timeval *abs_out)
+{
+    int rc;
+    struct timeval additional = {
+        .tv_sec = ms / 1000,
+        .tv_usec = (ms % 1000) * 1000
+    };
+    struct timeval now;
+
+    rc = libxl__gettimeofday(gc, &now);
+    if (rc) return rc;
+
+    timeradd(&now, &additional, abs_out);
+    return 0;
+}
+
+static void time_insert_finite(libxl__gc *gc, libxl__ev_time *ev)
+{
+    libxl__ev_time *evsearch;
+    LIBXL_TAILQ_INSERT_SORTED(&CTX->etimes, entry, ev, evsearch, /*empty*/,
+                              timercmp(&ev->abs, &evsearch->abs, >));
+    ev->infinite = 0;
+}
+
+static int time_register_finite(libxl__gc *gc, libxl__ev_time *ev,
+                                struct timeval abs) {
+    int rc;
+    
+    rc = OSEVENT_HOOK(timeout_register, &ev->for_app_reg, abs, ev);
+    if (rc) return rc;
+
+    ev->infinite = 0;
+    ev->abs = abs;
+    time_insert_finite(gc, ev);
+
+    return 0;
+}
+
+static void time_deregister(libxl__gc *gc, libxl__ev_time *ev)
+{
+    if (!ev->infinite) {
+        OSEVENT_HOOK_VOID(timeout_deregister, &ev->for_app_reg);
+        LIBXL_TAILQ_REMOVE(&CTX->etimes, ev, entry);
+    }
+}
+    
+
+int libxl__ev_time_register_abs(libxl__gc *gc, libxl__ev_time *ev,
+                                libxl__ev_time_callback *func,
+                                struct timeval abs)
+{
+    int rc;
+    
+    CTX_LOCK;
+
+    rc = time_register_finite(gc, ev, abs);
+    if (rc) goto out;
+
+    ev->func = func;
+
+    rc = 0;
+ out:
+    CTX_UNLOCK;
+    return rc;
+}
+
+
+int libxl__ev_time_register_rel(libxl__gc *gc, libxl__ev_time *ev,
+                                libxl__ev_time_callback *func,
+                                int milliseconds /* as for poll(2) */)
+{
+    struct timeval abs;
+    int rc;
+
+    CTX_LOCK;
+
+    if (milliseconds < 0) {
+        ev->infinite = 1;
+    } else {
+        rc = time_rel_to_abs(gc, milliseconds, &abs);
+        if (rc) goto out;
+
+        rc = time_register_finite(gc, ev, abs);
+        if (rc) goto out;
+    }
+
+    ev->func = func;
+    rc = 0;
+
+ out:
+    CTX_UNLOCK;
+    return rc;
+}
+
+int libxl__ev_time_modify_abs(libxl__gc *gc, libxl__ev_time *ev,
+                              struct timeval abs)
+{
+    int rc;
+
+    CTX_LOCK;
+
+    assert(libxl__ev_time_isregistered(ev));
+
+    if (ev->infinite) {
+        rc = time_register_finite(gc, ev, abs);
+        if (rc) goto out;
+    } else {
+        rc = OSEVENT_HOOK(timeout_modify, &ev->for_app_reg, abs);
+        if (rc) goto out;
+
+        LIBXL_TAILQ_REMOVE(&CTX->etimes, ev, entry);
+        ev->abs = abs;
+        time_insert_finite(gc, ev);
+    }
+
+    rc = 0;
+ out:
+    CTX_UNLOCK;
+    return rc;
+}
+
+int libxl__ev_time_modify_rel(libxl__gc *gc, libxl__ev_time *ev,
+                              int milliseconds)
+{
+    struct timeval abs;
+    int rc;
+
+    CTX_LOCK;
+
+    assert(libxl__ev_time_isregistered(ev));
+
+    if (milliseconds < 0) {
+        time_deregister(gc, ev);
+        ev->infinite = 1;
+        rc = 0;
+        goto out;
+    }
+
+    rc = time_rel_to_abs(gc, milliseconds, &abs);
+    if (rc) goto out;
+
+    rc = libxl__ev_time_modify_abs(gc, ev, abs);
+    if (rc) goto out;
+
+    rc = 0;
+ out:
+    CTX_UNLOCK;
+    return rc;
+}
+
+void libxl__ev_time_deregister(libxl__gc *gc, libxl__ev_time *ev)
+{
+    CTX_LOCK;
+
+    if (!libxl__ev_time_isregistered(ev))
+        goto out;
+        
+    time_deregister(gc, ev);
+    ev->func = 0;
+
+ out:
+    CTX_UNLOCK;
+    return;
+}
+
+
+/*
+ * xenstore watches
+ */
+
+libxl__ev_xswatch *libxl__watch_slot_contents(libxl__gc *gc, int slotnum)
+{
+    libxl__ev_watch_slot *slot = &CTX->watch_slots[slotnum];
+    libxl__ev_watch_slot *slotcontents = LIBXL_SLIST_NEXT(slot, empty);
+
+    if (slotcontents == NULL ||
+        ((uintptr_t)slotcontents >= (uintptr_t)CTX->watch_slots &&
+         (uintptr_t)slotcontents < (uintptr_t)(CTX->watch_slots +
+                                               CTX->watch_nslots)))
+        /* An empty slot has either a NULL pointer (end of the
+         * free list), or a pointer to another entry in the array.
+         * So we can do a bounds check to distinguish empty from
+         * full slots.
+         */
+        /* We need to do the comparisons as uintptr_t because
+         * comparing pointers which are not in the same object is
+         * undefined behaviour; if the compiler managed to figure
+         * out that watch_slots[0..watch_nslots-1] is all of the
+         * whole array object it could prove that the above bounds
+         * check was always true if it was legal, and remove it!
+         *
+         * uintptr_t because even on a machine with signed
+         * pointers, objects do not cross zero; whereas on
+         * machines with unsigned pointers, they may cross
+         * 0x8bazillion.
+         */
+        return NULL;
+
+        /* see comment near libxl__ev_watch_slot definition */
+    return (void*)slotcontents;
+}
+
+static void libxl__set_watch_slot_contents(libxl__ev_watch_slot *slot,
+                                           libxl__ev_xswatch *w)
+{
+    /* we look a bit behind the curtain of LIBXL_SLIST, to explicitly
+     * assign to the pointer that's the next link.  See the comment
+     * by the definition of libxl__ev_watch_slot */
+    slot->empty.sle_next = (void*)w;
+}
+
+static void watchfd_callback(libxl__gc *gc, libxl__ev_fd *ev,
+                             int fd, short events, short revents)
+{
+    for (;;) {
+        char **event = xs_check_watch(CTX->xsh);
+        if (!event) {
+            if (errno == EAGAIN) break;
+            if (errno == EINTR) continue;
+            LIBXL__EVENT_DISASTER(gc, "cannot check/read watches", errno, 0);
+            return;
+        }
+
+        const char *epath = event[0];
+        const char *token = event[1];
+        int slotnum;
+        uint32_t counterval;
+        int rc = sscanf(token, "%d/%"SCNx32, &slotnum, &counterval);
+        if (rc != 2) {
+            LIBXL__LOG(CTX, LIBXL__LOG_ERROR,
+                       "watch epath=%s token=%s: failed to parse token",
+                       epath, token);
+            /* oh well */
+            goto ignore;
+        }
+        if (slotnum < 0 || slotnum >= CTX->watch_nslots) {
+            /* perhaps in the future we will make the watchslots array shrink */
+            LIBXL__LOG(CTX, LIBXL__LOG_DEBUG, "watch epath=%s token=%s:"
+                       " slotnum %d out of range [0,%d>",
+                       epath, token, slotnum, CTX->watch_nslots);
+            goto ignore;
+        }
+
+        libxl__ev_xswatch *w = libxl__watch_slot_contents(gc, slotnum);
+
+        if (!w) {
+            LIBXL__LOG(CTX, LIBXL__LOG_DEBUG,
+                       "watch epath=%s token=%s: empty slot",
+                       epath, token);
+            goto ignore;
+        }
+        
+        if (w->counterval != counterval) {
+            LIBXL__LOG(CTX, LIBXL__LOG_DEBUG,
+                       "watch epath=%s token=%s: counter != %"PRIx32,
+                       epath, token, w->counterval);
+            goto ignore;
+        }
+
+        /* Now it's possible, though unlikely, that this was an event
+         * from a previous use of the same slot with the same counterval.
+         *
+         * In that case either:
+         *  - the event path is a child of the watch path, in
+         *    which case this watch would really have generated this
+         *    event if it had been registered soon enough and we are
+         *    OK to give this possibly-spurious event to the caller; or
+         * - it is not, in which case we must suppress it as the
+         *   caller should not see events for unrelated paths.
+         *
+         * See also docs/misc/xenstore.txt.
+         */
+        if (!xs_path_is_subpath(w->path, epath)) {
+            LIBXL__LOG(CTX, LIBXL__LOG_DEBUG,
+                       "watch epath=%s token=%s: not child of wpath=%s",
+                       epath, token, w->path);
+            goto ignore;
+        }
+
+        /* At last, we have checked everything! */
+        LIBXL__LOG(CTX, LIBXL__LOG_DEBUG,
+                   "watch event: epath=%s token=%s wpath=%s w=%p",
+                   epath, token, w->path, w);
+        w->callback(gc, w, w->path, epath);
+
+    ignore:
+        free(event);
+    }
+}
+
+static char *watch_token(libxl__gc *gc, int slotnum, uint32_t counterval)
+{
+    return libxl__sprintf(gc, "%d/%"PRIx32, slotnum, counterval);
+}
+
+int libxl__ev_xswatch_register(libxl__gc *gc, libxl__ev_xswatch *w,
+                               libxl__ev_xswatch_callback *func,
+                               const char *path /* copied */)
+{
+    libxl__ev_watch_slot *use = NULL;
+    char *path_copy = NULL;
+    int rc;
+
+    CTX_LOCK;
+
+    if (!libxl__ev_fd_isregistered(&CTX->watch_efd)) {
+        rc = libxl__ev_fd_register(gc, &CTX->watch_efd, watchfd_callback,
+                                   xs_fileno(CTX->xsh), POLLIN);
+        if (rc) goto out_rc;
+    }
+
+    if (LIBXL_SLIST_EMPTY(&CTX->watch_freeslots)) {
+        /* Free list is empty so there is not in fact a linked
+         * free list in the array and we can safely realloc it */
+        int newarraysize = (CTX->watch_nslots + 1) << 2;
+        int i;
+        libxl__ev_watch_slot *newarray =
+            realloc(CTX->watch_slots, sizeof(*newarray) * newarraysize);
+        if (!newarray) goto out_nomem;
+        for (i = CTX->watch_nslots; i < newarraysize; i++)
+            LIBXL_SLIST_INSERT_HEAD(&CTX->watch_freeslots,
+                                    &newarray[i], empty);
+        CTX->watch_slots = newarray;
+        CTX->watch_nslots = newarraysize;
+    }
+    use = LIBXL_SLIST_FIRST(&CTX->watch_freeslots);
+    assert(use);
+    LIBXL_SLIST_REMOVE_HEAD(&CTX->watch_freeslots, empty);
+
+    path_copy = strdup(path);
+    if (!path_copy) goto out_nomem;
+
+    int slotnum = use - CTX->watch_slots;
+    w->counterval = CTX->watch_counter++;
+
+    if (!xs_watch(CTX->xsh, path, watch_token(gc, slotnum, w->counterval))) {
+        LIBXL__LOG_ERRNOVAL(CTX, LIBXL__LOG_ERROR, errno,
+                            "create watch for path %s", path);
+        rc = ERROR_FAIL;
+        goto out_rc;
+    }
+
+    w->slotnum = slotnum;
+    w->path = path_copy;
+    w->callback = func;
+    libxl__set_watch_slot_contents(use, w);
+
+    CTX_UNLOCK;
+    return 0;
+
+ out_nomem:
+    rc = ERROR_NOMEM;
+ out_rc:
+    if (use)
+        LIBXL_SLIST_INSERT_HEAD(&CTX->watch_freeslots, use, empty);
+    if (path_copy)
+        free(path_copy);
+    CTX_UNLOCK;
+    return rc;
+}
+
+void libxl__ev_xswatch_deregister(libxl__gc *gc, libxl__ev_xswatch *w)
+{
+    /* it is legal to deregister from within _callback */
+    CTX_LOCK;
+
+    if (w->slotnum >= 0) {
+        char *token = watch_token(gc, w->slotnum, w->counterval);
+        if (!xs_unwatch(CTX->xsh, w->path, token))
+            /* Oh well, we will just get watch events forever more
+             * and ignore them.  But we should complain to the log. */
+            LIBXL__LOG_ERRNOVAL(CTX, LIBXL__LOG_ERROR, errno,
+                                "remove watch for path %s", w->path);
+
+        libxl__ev_watch_slot *slot = &CTX->watch_slots[w->slotnum];
+        LIBXL_SLIST_INSERT_HEAD(&CTX->watch_freeslots, slot, empty);
+    }
+
+    free(w->path);
+    w->path = NULL;
+
+    CTX_UNLOCK;
+}
+
+/*
+ * osevent poll
+ */
+
+int libxl_osevent_beforepoll(libxl_ctx *ctx, int *nfds_io,
+                             struct pollfd *fds, int *timeout_upd,
+                             struct timeval now)
+{
+    libxl__ev_fd *efd;
+    int i;
+
+    /*
+     * In order to be able to efficiently find the libxl__ev_fd
+     * for a struct poll during _afterpoll, we maintain a shadow
+     * data structure in CTX->fd_beforepolled: each slot in
+     * the fds array corresponds to a slot in fd_beforepolled.
+     */
+
+    GC_INIT(ctx);
+    CTX_LOCK;
+
+    if (*nfds_io) {
+        /*
+         * As an optimisation, we don't touch fd_beforepolled_used
+         * if *nfds_io is zero on entry, since in that case the
+         * caller just wanted to know how big an array to give us.
+         *
+         * If !*nfds_io, the unconditional parts below are guaranteed
+         * not to mess with fd_beforepolled... or any in_beforepolled.
+         */
+
+        /* Remove all the old references into beforepolled */
+        for (i = 0; i < CTX->fd_beforepolled_used; i++) {
+            efd = CTX->fd_beforepolled[i];
+            if (efd) {
+                assert(efd->in_beforepolled == i);
+                efd->in_beforepolled = -1;
+                CTX->fd_beforepolled[i] = NULL;
+            }
+        }
+        CTX->fd_beforepolled_used = 0;
+
+        /* make sure our array is as big as *nfds_io */
+        if (CTX->fd_beforepolled_allocd < *nfds_io) {
+            assert(*nfds_io < INT_MAX / sizeof(libxl__ev_fd*) / 2);
+            libxl__ev_fd **newarray =
+                realloc(CTX->fd_beforepolled, sizeof(*newarray) * *nfds_io);
+            if (!newarray)
+                return ERROR_NOMEM;
+            CTX->fd_beforepolled = newarray;
+            CTX->fd_beforepolled_allocd = *nfds_io;
+        }
+    }
+
+    int used = 0;
+    LIBXL_LIST_FOREACH(efd, &CTX->efds, entry) {
+        if (used < *nfds_io) {
+            fds[used].fd = efd->fd;
+            fds[used].events = efd->events;
+            fds[used].revents = 0;
+            CTX->fd_beforepolled[used] = efd;
+            efd->in_beforepolled = used;
+        }
+        used++;
+    }
+    int rc = used <= *nfds_io ? 0 : ERROR_BUFFERFULL;
+
+    if (*nfds_io) {
+        CTX->fd_beforepolled_used = used;
+    }
+
+    *nfds_io = used;
+
+    libxl__ev_time *etime = LIBXL_TAILQ_FIRST(&CTX->etimes);
+    if (etime) {
+        int our_timeout;
+        struct timeval rel;
+        static struct timeval zero;
+
+        timersub(&etime->abs, &now, &rel);
+
+        if (timercmp(&rel, &zero, <)) {
+            our_timeout = 0;
+        } else if (rel.tv_sec >= 2000000) {
+            our_timeout = 2000000000;
+        } else {
+            our_timeout = rel.tv_sec * 1000 + (rel.tv_usec + 999) / 1000;
+        }
+        if (*timeout_upd < 0 || our_timeout < *timeout_upd)
+            *timeout_upd = our_timeout;
+    }
+
+    CTX_UNLOCK;
+    GC_FREE;
+    return rc;
+}
+
+void libxl_osevent_afterpoll(libxl_ctx *ctx, int nfds, const struct pollfd *fds,
+                             struct timeval now)
+{
+    int i;
+    GC_INIT(ctx);
+    CTX_LOCK;
+
+    assert(nfds <= CTX->fd_beforepolled_used);
+
+    for (i = 0; i < nfds; i++) {
+        if (!fds[i].revents)
+            continue;
+
+        libxl__ev_fd *efd = CTX->fd_beforepolled[i];
+        if (!efd)
+            continue;
+
+        assert(efd->in_beforepolled == i);
+        assert(fds[i].fd == efd->fd);
+
+        int revents = fds[i].revents & efd->events;
+        if (!revents)
+            continue;
+
+        efd->func(gc, efd, efd->fd, efd->events, revents);
+    }
+
+    for (;;) {
+        libxl__ev_time *etime = LIBXL_TAILQ_FIRST(&CTX->etimes);
+        if (!etime)
+            break;
+
+        assert(!etime->infinite);
+
+        if (timercmp(&etime->abs, &now, >))
+            break;
+
+        time_deregister(gc, etime);
+
+        etime->func(gc, etime, &etime->abs);
+    }
+
+    CTX_UNLOCK;
+    GC_FREE;
+}
+
+
+/*
+ * osevent hook and callback machinery
+ */
+
+void libxl_osevent_register_hooks(libxl_ctx *ctx,
+                                  const libxl_osevent_hooks *hooks,
+                                  void *user)
+{
+    GC_INIT(ctx);
+    CTX_LOCK;
+    ctx->osevent_hooks = hooks;
+    ctx->osevent_user = user;
+    CTX_UNLOCK;
+    GC_FREE;
+}
+
+
+void libxl_osevent_occurred_fd(libxl_ctx *ctx, void *for_libxl,
+                               int fd, short events, short revents)
+{
+    libxl__ev_fd *ev = for_libxl;
+
+    GC_INIT(ctx);
+    CTX_LOCK;
+    assert(!CTX->osevent_in_hook);
+
+    assert(fd == ev->fd);
+    revents &= ev->events;
+    if (revents)
+        ev->func(gc, ev, fd, ev->events, revents);
+
+    CTX_UNLOCK;
+    GC_FREE;
+}
+
+void libxl_osevent_occurred_timeout(libxl_ctx *ctx, void *for_libxl)
+{
+    libxl__ev_time *ev = for_libxl;
+
+    GC_INIT(ctx);
+    CTX_LOCK;
+    assert(!CTX->osevent_in_hook);
+
+    assert(!ev->infinite);
+    LIBXL_TAILQ_REMOVE(&CTX->etimes, ev, entry);
+    ev->func(gc, ev, &ev->abs);
+
+    CTX_UNLOCK;
+    GC_FREE;
+}
+
+void libxl__event_disaster(libxl__gc *gc, const char *msg, int errnoval,
+                           libxl_event_type type /* may be 0 */,
+                           const char *file, int line, const char *func)
+{
+    libxl__log(CTX, XTL_CRITICAL, errnoval, file, line, func,
+               "DISASTER in event loop: %s%s%s%s",
+               msg,
+               type ? " (relates to event type " : "",
+               type ? libxl_event_type_to_string(type) : "",
+               type ? ")" : "");
+
+    /*
+     * FIXME: This should call the "disaster" hook supplied to
+     * libxl_event_register_callbacks, which will be introduced in the
+     * next patch.
+     */
+
+    const char verybad[] =
+        "DISASTER in event loop not handled by libxl application";
+    LIBXL__LOG(CTX, XTL_CRITICAL, verybad);
+    fprintf(stderr, "libxl: fatal error, exiting program: %s\n", verybad);
+    exit(-1);
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/tools/libxl/libxl_event.h b/tools/libxl/libxl_event.h
new file mode 100644
index 0000000..cc4a348
--- /dev/null
+++ b/tools/libxl/libxl_event.h
@@ -0,0 +1,200 @@
+/*
+ * Copyright (C) 2011      Citrix Ltd.
+ * Author Ian Jackson <ian.jackson@eu.citrix.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU Lesser General Public License as published
+ * by the Free Software Foundation; version 2.1 only. with the special
+ * exception on linking described in file LICENSE.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU Lesser General Public License for more details.
+ */
+
+#ifndef LIBXL_EVENT_H
+#define LIBXL_EVENT_H
+
+#include <libxl.h>
+
+
+/*======================================================================*/
+
+/*
+ * OS event handling - passing low-level OS events to libxl
+ *
+ * Event-driven programs must use these facilities to allow libxl
+ * to become aware of readability/writeability of file descriptors
+ * and the occurrence of timeouts.
+ *
+ * There are two approaches available.  The first is appropriate for
+ * simple programs handling reasonably small numbers of domains:
+ *
+ *   for (;;) {
+ *      libxl_osevent_beforepoll(...)
+ *      poll();
+ *      libxl_osevent_afterpoll(...);
+ *      for (;;) {
+ *        r=libxl_event_check(...);
+ *        if (r==LIBXL_NOT_READY) break;
+ *        if (r) handle failure;
+ *        do something with the event;
+ *      }
+ *   }
+ *
+ * The second approach uses libxl_osevent_register_hooks and is
+ * suitable for programs which are already using a callback-based
+ * event library.
+ *
+ * An application may freely mix the two styles of interaction.
+ */
+
+struct pollfd;
+
+int libxl_osevent_beforepoll(libxl_ctx *ctx, int *nfds_io,
+                             struct pollfd *fds, int *timeout_upd,
+                             struct timeval now);
+  /* The caller should provide beforepoll with some space for libxl's
+   * fds, and tell libxl how much space is available by setting *nfds_io.
+   * fds points to the start of this space (and fds may be a pointer into
+   * a larger array, for example, if the application has some fds of
+   * its own that it is interested in).
+   *
+   * On return *nfds_io will in any case have been updated by libxl
+   * according to how many fds libxl wants to poll on.
+   *
+   * If the space was sufficient, libxl fills in fds[0..<new
+   * *nfds_io>] suitably for poll(2), updates *timeout_upd if needed,
+   * and returns ok.
+   *
+   * If space was insufficient, fds[0..<old *nfds_io>] is undefined on
+   * return; *nfds_io on return will be greater than the value on
+   * entry; *timeout_upd may or may not have been updated; and
+   * libxl_osevent_beforepoll returns ERROR_BUFERFULL.  In this case
+   * the application needs to make more space (enough space for
+   * *nfds_io struct pollfd) and then call beforepoll again, before
+   * entering poll(2).  Typically this will involve calling realloc.
+   *
+   * The application may call beforepoll with fds==NULL and
+   * *nfds_io==0 in order to find out how much space is needed.
+   *
+   * *timeout_upd is as for poll(2): it's in milliseconds, and
+   * negative values mean no timeout (infinity).
+   * libxl_osevent_beforepoll will only reduce the timeout, naturally.
+   */
+void libxl_osevent_afterpoll(libxl_ctx *ctx, int nfds, const struct pollfd *fds,
+                             struct timeval now);
+  /* nfds and fds[0..nfds] must be from the most recent call to
+   * _beforepoll, as modified by poll.
+   *
+   * This function actually performs all of the IO and other actions,
+   * and generates events (libxl_event), which are implied by either
+   * (a) the time of day or (b) both (i) the returned information from
+   * _beforepoll, and (ii) the results from poll specified in
+   * fds[0..nfds-1].  Generated events can then be retrieved by
+   * libxl_event_check.
+   */
+
+
+typedef struct libxl_osevent_hooks {
+  int (*fd_register)(void *user, int fd, void **for_app_registration_out,
+                     short events, void *for_libxl);
+  int (*fd_modify)(void *user, int fd, void **for_app_registration_update,
+                   short events);
+  void (*fd_deregister)(void *user, int fd, void *for_app_registration);
+  int (*timeout_register)(void *user, void **for_app_registration_out,
+                          struct timeval abs, void *for_libxl);
+  int (*timeout_modify)(void *user, void **for_app_registration_update,
+                         struct timeval abs);
+  void (*timeout_deregister)(void *user, void *for_app_registration);
+} libxl_osevent_hooks;
+
+void libxl_osevent_register_hooks(libxl_ctx *ctx,
+                                  const libxl_osevent_hooks *hooks,
+                                  void *user);
+  /* The application which calls register_fd_hooks promises to
+   * maintain a register of fds and timeouts that libxl is interested
+   * in, and make calls into libxl (libxl_osevent_occurred_*)
+   * when those fd events and timeouts occur.  This is more efficient
+   * than _beforepoll/_afterpoll if there are many fds (which can
+   * happen if the same libxl application is managing many domains).
+   *
+   * For an fd event, events is as for poll().  register or modify may
+   * be called with events==0, in which case it must still work
+   * normally, just not generate any events.
+   *
+   * For a timeout event, milliseconds is as for poll().
+   * Specifically, negative values of milliseconds mean NO TIMEOUT.
+   * This is used by libxl to temporarily disable a timeout.
+   *
+   * If the register or modify hook succeeds it may update
+   * *for_app_registration_out/_update and must then return 0.
+   * On entry to register, *for_app_registration_out is always NULL.
+   *
+   * A registration or modification hook may fail, in which case it
+   * must leave the registration state of the fd or timeout unchanged.
+   * It may then either return ERROR_OSEVENT_REG_FAIL or any positive
+   * int.  The value returned will be passed up through libxl and
+   * eventually returned back to the application.  When register
+   * fails, any value stored into *for_registration_out is ignored by
+   * libxl; when modify fails, any changed value stored into
+   * *for_registration_update is honoured by libxl and will be passed
+   * to future modify or deregister calls.
+   *
+   * libxl will only attempt to register one callback for any one fd.
+   * libxl will remember the value stored in *for_app_registration_out
+   * (or *for_app_registration_update) by a successful call to
+   * register (or modify), and pass it to subsequent calls to modify
+   * or deregister.
+   *
+   * register_fd_hooks may be called only once for each libxl_ctx.
+   * libxl may make calls to register/modify/deregister from within
+   * any libxl function (indeed, it will usually call register from
+   * register_event_hooks).  Conversely, the application MUST NOT make
+   * the event occurrence calls (libxl_osevent_occurred_*) into libxl
+   * reentrantly from within libxl (for example, from within the
+   * register/modify functions).
+   *
+   * Lock hierarchy: the register/modify/deregister functions may be
+   * called with locks held.  These locks (the "libxl internal locks")
+   * are inside the libxl_ctx.  Therefore, if those register functions
+   * acquire any locks of their own ("caller register locks") outside
+   * libxl, to avoid deadlock one of the following must hold for each
+   * such caller register lock:
+   *  (a) "acquire libxl internal locks before caller register lock":
+   *      No libxl function may be called with the caller register
+   *      lock held.
+   *  (b) "acquire caller register lock before libxl internal locks":
+   *      No libxl function may be called _without_ the caller
+   *      register lock held.
+   * Of these we would normally recommend (a).
+   *
+   * The value *hooks is not copied and must outlast the libxl_ctx.
+   */
+
+/* It is NOT legal to call _occurred_ reentrantly within any libxl
+ * function.  Specifically it is NOT legal to call it from within
+ * a register callback.  Conversely, libxl MAY call register/deregister
+ * from within libxl_event_registered_call_*.
+ */
+
+void libxl_osevent_occurred_fd(libxl_ctx *ctx, void *for_libxl,
+                               int fd, short events, short revents);
+
+void libxl_osevent_occurred_timeout(libxl_ctx *ctx, void *for_libxl);
+  /* Implicitly, on entry to this function the timeout has been
+   * deregistered.  If _occurred_timeout is called, libxl will not
+   * call timeout_deregister; if it wants to requeue the timeout it
+   * will call timeout_register again.
+   */
+
+#endif
+
+/*
+ * Local variables:
+ * mode: C
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 536a1ec..c4a5fa1 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -24,6 +24,9 @@
 #include <stdlib.h>
 #include <string.h>
 #include <pthread.h>
+#include <inttypes.h>
+#include <assert.h>
+#include <sys/poll.h>
 
 #include <xs.h>
 #include <xenctrl.h>
@@ -91,6 +94,66 @@ _hidden void libxl__log(libxl_ctx *ctx, xentoollog_level msglevel, int errnoval,
 
      /* these functions preserve errno (saving and restoring) */
 
+typedef struct libxl__gc libxl__gc;
+
+typedef struct libxl__ev_fd libxl__ev_fd;
+typedef void libxl__ev_fd_callback(libxl__gc *gc, libxl__ev_fd *ev,
+                                   int fd, short events, short revents);
+struct libxl__ev_fd {
+    /* all private for libxl__ev_fd... */
+    LIBXL_LIST_ENTRY(libxl__ev_fd) entry;
+    int fd;
+    short events;
+    int in_beforepolled; /* -1 means not in fd_beforepolled */
+    void *for_app_reg;
+    libxl__ev_fd_callback *func;
+};
+
+
+typedef struct libxl__ev_time libxl__ev_time;
+typedef void libxl__ev_time_callback(libxl__gc *gc, libxl__ev_time *ev,
+                                     const struct timeval *requested_abs);
+struct libxl__ev_time {
+    /* all private for libxl__ev_time... */
+    int infinite; /* not registered in list or with app if infinite */
+    LIBXL_TAILQ_ENTRY(libxl__ev_time) entry;
+    struct timeval abs;
+    void *for_app_reg;
+    libxl__ev_time_callback *func;
+};
+
+typedef struct libxl__ev_xswatch libxl__ev_xswatch;
+typedef void libxl__ev_xswatch_callback(libxl__gc *gc, libxl__ev_xswatch*,
+                            const char *watch_path, const char *event_path);
+struct libxl__ev_xswatch {
+    /* caller should include this in their own struct */
+    /* contents are private to xswatch_register */
+    int slotnum;
+    uint32_t counterval;
+    char *path;
+    libxl__ev_xswatch_callback *callback;
+};
+
+/*
+ * An entry in the watch_slots table is either:
+ *  1. an entry in the free list, ie NULL or pointer to next free list entry
+ *  2. an pointer to a libxl__ev_xswatch
+ *
+ * But we don't want to use unions or type-punning because the
+ * compiler might "prove" that our code is wrong and misoptimise it.
+ *
+ * The rules say that all struct pointers have identical
+ * representation and alignment requirements (C99+TC1+TC2 6.2.5p26) so
+ * what we do is simply declare our array as containing only the free
+ * list pointers, and explicitly convert from and to our actual
+ * xswatch pointers when we store and retrieve them.
+ */
+typedef struct libxl__ev_watch_slot {
+    LIBXL_SLIST_ENTRY(struct libxl__ev_watch_slot) empty;
+} libxl__ev_watch_slot;
+    
+libxl__ev_xswatch *libxl__watch_slot_contents(libxl__gc *gc, int slotnum);
+
 struct libxl__ctx {
     xentoollog_logger *lg;
     xc_interface *xch;
@@ -108,6 +171,23 @@ struct libxl__ctx {
        * documented in the libxl public interface.
        */
 
+    int osevent_in_hook;
+    const libxl_osevent_hooks *osevent_hooks;
+    void *osevent_user;
+      /* See the comment for OSEVENT_HOOK_INTERN in libxl_event.c
+       * for restrictions on the use of the osevent fields. */
+
+    int fd_beforepolled_allocd, fd_beforepolled_used;
+    libxl__ev_fd **fd_beforepolled; /* see libxl_osevent_beforepoll */
+    LIBXL_LIST_HEAD(, libxl__ev_fd) efds;
+    LIBXL_TAILQ_HEAD(, libxl__ev_time) etimes;
+
+    libxl__ev_watch_slot *watch_slots;
+    int watch_nslots;
+    LIBXL_SLIST_HEAD(, libxl__ev_watch_slot) watch_freeslots;
+    uint32_t watch_counter; /* helps disambiguate slot reuse */
+    libxl__ev_fd watch_efd;
+
     /* for callers who reap children willy-nilly; caller must only
      * set this after libxl_init and before any other call - or
      * may leave them untouched */
@@ -138,12 +218,12 @@ typedef struct {
 
 #define PRINTF_ATTRIBUTE(x, y) __attribute__((format(printf, x, y)))
 
-typedef struct {
+struct libxl__gc {
     /* mini-GC */
     int alloc_maxsize;
     void **alloc_ptrs;
     libxl_ctx *owner;
-} libxl__gc;
+};
 
 #define LIBXL_INIT_GC(gc,ctx) do{               \
         (gc).alloc_maxsize = 0;                 \
@@ -209,9 +289,140 @@ _hidden char *libxl__xs_read(libxl__gc *gc, xs_transaction_t t,
 _hidden char **libxl__xs_directory(libxl__gc *gc, xs_transaction_t t,
                                    const char *path, unsigned int *nb);
    /* On error: returns NULL, sets errno (no logging) */
-
 _hidden char *libxl__xs_libxl_path(libxl__gc *gc, uint32_t domid);
 
+
+/*
+ * Event generation functions provided by the libxl event core to the
+ * rest of libxl.  Implemented in terms of _beforepoll/_afterpoll
+ * and/or the fd registration machinery, as provided by the
+ * application.
+ *
+ * Semantics are similar to those of the fd and timeout registration
+ * functions provided to libxl_osevent_register_hooks.
+ *
+ * Non-0 returns from libxl__ev_{modify,deregister} have already been
+ * logged by the core and should be returned unmodified to libxl's
+ * caller; NB that they may be valid libxl error codes but they may
+ * also be positive numbers supplied by the caller.
+ *
+ * In each case, there is a libxl__ev_FOO structure which can be in
+ * one of three states:
+ *
+ *   Undefined   - Might contain anything.  All-bits-zero is
+ *                 an undefined state.
+ *
+ *   Idle        - Struct contents are defined enough to pass to any
+ *                 libxl__ev_FOO function but not registered and
+ *                 callback will not be called.  The struct does not
+ *                 contain references to any allocated resources so
+ *                 can be thrown away.
+ *
+ *   Active      - Request for events has been registered and events
+ *                 may be generated.  _deregister must be called to
+ *                 reclaim resources.
+ *
+ * These functions are provided for each kind of event KIND:
+ *
+ *   int libxl__ev_KIND_register(libxl__gc *gc, libxl__ev_KIND *GEN,
+ *                              libxl__ev_KIND_callback *FUNC,
+ *                              DETAILS);
+ *      On entry *GEN must be in state Undefined or Idle.
+ *      Returns a libxl error code; on error return *GEN is Idle.
+ *      On successful return *GEN is Active and FUNC wil be
+ *      called by the event machinery in future.  FUNC will
+ *      not be called from within the call to _register.
+ *
+ *  void libxl__ev_KIND_deregister(libxl__gc *gc, libxl__ev_KIND *GEN_upd);
+ *      On entry *GEN must be in state Active or Idle.
+ *      On return it is Idle.  (Idempotent.)
+ *
+ *  void libxl__ev_KIND_init(libxl__ev_KIND *GEN);
+ *      Provided for initialising an Undefined KIND.
+ *      On entry *GEN must be in state Idle or Undefined.
+ *      On return it is Idle.  (Idempotent.)
+ *
+ *  int libxl__ev_KIND_isregistered(const libxl__ev_KIND *GEN);
+ *      On entry *GEN must be Idle or Active.
+ *      Returns nonzero if it is Active, zero otherwise.
+ *      Cannot fail.
+ *
+ *  int libxl__ev_KiND_modify(libxl__gc*, libxl__ev_KIND *GEN,
+ *                            DETAILS);
+ *      Only provided for some kinds of generator.
+ *      On entry *GEN must be Active and on return, whether successful
+ *      or not, it will be Active.
+ *      Returns a libxl error code; on error the modification
+ *      is not effective.
+ *
+ * All of these functions are fully threadsafe and may be called by
+ * general code in libxl even from within event callback FUNCs.
+ *
+ * Callers of libxl__ev_KIND_register must ensure that the
+ * registration is undone, with _deregister, in libxl_ctx_free.
+ */
+
+
+_hidden int libxl__ev_fd_register(libxl__gc*, libxl__ev_fd *ev_out,
+                                  libxl__ev_fd_callback*,
+                                  int fd, short events /* as for poll(2) */);
+_hidden int libxl__ev_fd_modify(libxl__gc*, libxl__ev_fd *ev,
+                                short events);
+_hidden void libxl__ev_fd_deregister(libxl__gc*, libxl__ev_fd *ev);
+static inline void libxl__ev_fd_init(libxl__ev_fd *efd)
+                    { efd->fd = -1; }
+static inline int libxl__ev_fd_isregistered(libxl__ev_fd *efd)
+                    { return efd->fd >= 0; }
+
+_hidden int libxl__ev_time_register_rel(libxl__gc*, libxl__ev_time *ev_out,
+                                        libxl__ev_time_callback*,
+                                        int milliseconds /* as for poll(2) */);
+_hidden int libxl__ev_time_register_abs(libxl__gc*, libxl__ev_time *ev_out,
+                                        libxl__ev_time_callback*,
+                                        struct timeval);
+_hidden int libxl__ev_time_modify_rel(libxl__gc*, libxl__ev_time *ev,
+                                      int milliseconds /* as for poll(2) */);
+_hidden int libxl__ev_time_modify_abs(libxl__gc*, libxl__ev_time *ev,
+                                      struct timeval);
+_hidden void libxl__ev_time_deregister(libxl__gc*, libxl__ev_time *ev);
+static inline void libxl__ev_time_init(libxl__ev_time *ev)
+                { ev->func = 0; }
+static inline int libxl__ev_time_isregistered(libxl__ev_time *ev)
+                { return !!ev->func; }
+
+
+_hidden int libxl__ev_xswatch_register(libxl__gc*, libxl__ev_xswatch *xsw_out,
+                                       libxl__ev_xswatch_callback*,
+                                       const char *path /* copied */);
+_hidden void libxl__ev_xswatch_deregister(libxl__gc *gc, libxl__ev_xswatch*);
+
+static inline void libxl__ev_xswatch_init(libxl__ev_xswatch *xswatch_out)
+                { xswatch_out->slotnum = -1; }
+static inline int libxl__ev_xswatch_isregistered(const libxl__ev_xswatch *xw)
+                { return xw->slotnum >= 0; }
+
+
+
+_hidden void libxl__event_disaster(libxl__gc*, const char *msg, int errnoval,
+                                   libxl_event_type type /* may be 0 */,
+                                   const char *file, int line,
+                                   const char *func);
+  /*
+   * In general, call this via the macro LIBXL__EVENT_DISASTER.
+   *
+   * Event-generating functions may call this if they might have
+   * wanted to generate an event (either an internal one ie a
+   * libxl__ev_FOO_callback or an application event), but are
+   * prevented from doing so due to eg lack of memory.
+   *
+   * NB that this function may return and the caller isn't supposed to
+   * then crash, although it may fail (and henceforth leave things in
+   * a state where many or all calls fail).
+   */
+#define LIBXL__EVENT_DISASTER(gc, msg, errnoval, type) \
+    libxl__event_disaster(gc, msg, errnoval, type, __FILE__, __LINE__, __func__)
+
+
 /* from xl_dom */
 _hidden libxl_domain_type libxl__domain_type(libxl__gc *gc, uint32_t domid);
 _hidden int libxl__domain_shutdown_reason(libxl__gc *gc, uint32_t domid);
@@ -536,6 +747,8 @@ _hidden int libxl__parse_mac(const char *s, libxl_mac mac);
 /* compare mac address @a and @b. 0 if the same, -ve if a<b and +ve if a>b */
 _hidden int libxl__compare_macs(libxl_mac *a, libxl_mac *b);
 
+_hidden int libxl__gettimeofday(libxl__gc *gc, struct timeval *now_r);
+
 #define STRINGIFY(x) #x
 #define TOSTRING(x) STRINGIFY(x)
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 18:55:51 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 18: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.xensource.com>)
	id 1RZ5bj-0001Kx-MY; Fri, 09 Dec 2011 18:55:43 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RZ5bg-0001C4-Tp
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 18:55:41 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1323456890!5661081!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI2MQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15637 invoked from network); 9 Dec 2011 18:54:51 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 18:54:51 -0000
X-IronPort-AV: E=Sophos;i="4.71,327,1320624000"; 
   d="scan'208";a="9392210"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 18:54:50 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 18:54:50 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RZ5as-0002ec-FV; Fri, 09 Dec 2011 18:54:50 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RZ5as-000415-ES;
	Fri, 09 Dec 2011 18:54:50 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Fri, 9 Dec 2011 18:54:37 +0000
Message-ID: <1323456877-15315-19-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1323456877-15315-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1323456877-15315-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 18/18] libxl: New event generation API
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Replace the existing API for retrieving high-level events (events
about domains, etc.) from libxl with a new one.

This changes the definition and semantics of the `libxl_event'
structure, and replaces the calls for obtaining information about
domain death and disk eject events.

This is an incompatible change, sorry.  The alternative was to try to
provide both the previous horrid API and the new one, and would also
involve never using the name `libxl_event' for the new interface.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl.c          |  329 +++++++++++++++++++++++++++++++-----------
 tools/libxl/libxl.h          |   55 ++------
 tools/libxl/libxl_event.c    |  200 +++++++++++++++++++++++---
 tools/libxl/libxl_event.h    |  182 +++++++++++++++++++++++-
 tools/libxl/libxl_internal.c |    6 +
 tools/libxl/libxl_internal.h |   87 +++++++++++-
 tools/libxl/libxl_types.idl  |   35 ++++-
 tools/libxl/xl_cmdimpl.c     |  270 ++++++++++++++++++++---------------
 8 files changed, 885 insertions(+), 279 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 23a7539..e94cbf1 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -60,8 +60,11 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
      * only as an initialiser, not as an expression. */
     memcpy(&ctx->lock, &mutex_value, sizeof(ctx->lock));
 
+    LIBXL_TAILQ_INIT(&ctx->occurred);
+
     ctx->osevent_hooks = 0;
 
+    ctx->fd_polls = 0;
     ctx->fd_beforepolled = 0;
     LIBXL_LIST_INIT(&ctx->efds);
     LIBXL_TAILQ_INIT(&ctx->etimes);
@@ -70,6 +73,9 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
     LIBXL_SLIST_INIT(&ctx->watch_freeslots);
     libxl__ev_fd_init(&ctx->watch_efd);
 
+    LIBXL_TAILQ_INIT(&ctx->death_list);
+    libxl__ev_xswatch_init(&ctx->death_watch);
+
     if ( stat(XENSTORE_PID_FILE, &stat_buf) != 0 ) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "Is xenstore daemon running?\n"
                      "failed to stat %s", XENSTORE_PID_FILE);
@@ -97,6 +103,20 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
     return 0;
 }
 
+static void free_disable_deaths(libxl__gc *gc,
+                                struct libxl__evgen_domain_death_list *l) {
+    libxl_evgen_domain_death *death;
+    while ((death = LIBXL_TAILQ_FIRST(l)))
+        libxl__evdisable_domain_death(gc, death);
+}
+
+static void discard_events(struct libxl__event_list *l) {
+    /* doesn't bother unlinking from the list, so l is corrupt on return */
+    libxl_event *ev;
+    LIBXL_TAILQ_FOREACH(ev, l, link)
+        libxl_event_free(0, ev);
+}
+
 int libxl_ctx_free(libxl_ctx *ctx)
 {
     if (!ctx) return 0;
@@ -106,6 +126,13 @@ int libxl_ctx_free(libxl_ctx *ctx)
 
     /* Deregister all libxl__ev_KINDs: */
 
+    free_disable_deaths(gc, &CTX->death_list);
+    free_disable_deaths(gc, &CTX->death_reported);
+
+    libxl_evgen_disk_eject *eject;
+    while ((eject = LIBXL_LIST_FIRST(&CTX->disk_eject_evgens)))
+        libxl__evdisable_disk_eject(gc, eject);
+
     for (i = 0; i < ctx->watch_nslots; i++)
         assert(!libxl__watch_slot_contents(gc, i));
     libxl__ev_fd_deregister(gc, &ctx->watch_efd);
@@ -119,9 +146,16 @@ int libxl_ctx_free(libxl_ctx *ctx)
     libxl_version_info_dispose(&ctx->version_info);
     if (ctx->xsh) xs_daemon_close(ctx->xsh);
 
+    free(ctx->fd_polls);
     free(ctx->fd_beforepolled);
     free(ctx->watch_slots);
 
+    discard_events(&ctx->occurred);
+    discard_events(&gc->occurred_for_callback);
+      /* There shouldn't be any of the latter - they would have had to
+       * have been generated during libxl_ctx_free - but throwing them
+       * away is more friendly than asserting. */
+
     GC_FREE;
     free(ctx);
     return 0;
@@ -620,117 +654,173 @@ int libxl_domain_shutdown(libxl_ctx *ctx, uint32_t domid, int req)
     return 0;
 }
 
-int libxl_get_wait_fd(libxl_ctx *ctx, int *fd)
-{
-    *fd = xs_fileno(ctx->xsh);
-    return 0;
-}
+static void domain_death_xswatch_callback(libxl__gc *gc, libxl__ev_xswatch *w,
+                                        const char *wpath, const char *epath) {
+    libxl_evgen_domain_death *evg;
+    uint32_t domid;
+    int rc;
 
-int libxl_wait_for_domain_death(libxl_ctx *ctx, uint32_t domid, libxl_waiter *waiter)
-{
-    waiter->path = strdup("@releaseDomain");
-    if (asprintf(&(waiter->token), "%d", LIBXL_EVENT_TYPE_DOMAIN_DEATH) < 0)
-        return -1;
-    if (!xs_watch(ctx->xsh, waiter->path, waiter->token))
-        return -1;
-    return 0;
-}
+    CTX_LOCK;
 
-int libxl_wait_for_disk_ejects(libxl_ctx *ctx, uint32_t guest_domid, libxl_device_disk *disks, int num_disks, libxl_waiter *waiter)
-{
-    GC_INIT(ctx);
-    int i, rc = -1;
-    uint32_t domid = libxl_get_stubdom_id(ctx, guest_domid);
+    evg = LIBXL_TAILQ_FIRST(&CTX->death_list);
+    if (!evg) goto out;
 
-    if (!domid)
-        domid = guest_domid;
+    domid = evg->domid;
 
-    for (i = 0; i < num_disks; i++) {
-        if (asprintf(&(waiter[i].path), "%s/device/vbd/%d/eject",
-                     libxl__xs_get_dompath(gc, domid),
-                     libxl__device_disk_dev_number(disks[i].vdev,
-                                                   NULL, NULL)) < 0)
-            goto out;
-        if (asprintf(&(waiter[i].token), "%d", LIBXL_EVENT_TYPE_DISK_EJECT) < 0)
+    for (;;) {
+        int nentries = LIBXL_TAILQ_NEXT(evg, entry) ? 200 : 1;
+        xc_domaininfo_t domaininfos[nentries];
+        const xc_domaininfo_t *got = domaininfos, *gotend;
+
+        rc = xc_domain_getinfolist(CTX->xch, domid, nentries, domaininfos);
+        if (rc == -1) {
+            LIBXL__EVENT_DISASTER(gc, "xc_domain_getinfolist failed while"
+                                  " processing @releaseDomain watch event",
+                                  errno, 0);
             goto out;
-        xs_watch(ctx->xsh, waiter[i].path, waiter[i].token);
+        }
+        gotend = &domaininfos[rc];
+
+        for (;;) {
+            if (!evg)
+                goto all_reported;
+
+            if (!rc || got->domain > evg->domid) {
+                /* ie, the list doesn't contain evg->domid any more so
+                 * the domain has been destroyed */
+                libxl_evgen_domain_death *evg_next;
+
+                libxl_event *ev = NEW_EVENT(gc, DOMAIN_DESTROY, evg->domid);
+                if (!ev) goto out;
+
+                libxl__event_occurred(gc, ev);
+
+                evg->death_reported = 1;
+                evg_next = LIBXL_TAILQ_NEXT(evg, entry);
+                LIBXL_TAILQ_REMOVE(&CTX->death_list, evg, entry);
+                LIBXL_TAILQ_INSERT_HEAD(&CTX->death_reported, evg, entry);
+                evg = evg_next;
+
+                continue;
+            }
+            
+            if (got == gotend)
+                break;
+
+            if (got->domain < evg->domid) {
+                got++;
+                continue;
+            }
+
+            assert(evg->domid == got->domain);
+
+            if (!evg->shutdown_reported &&
+                (got->flags & XEN_DOMINF_shutdown)) {
+                libxl_event *ev = NEW_EVENT(gc, DOMAIN_SHUTDOWN, got->domain);
+                if (!ev) goto out;
+                
+                ev->u.domain_shutdown.shutdown_reason =
+                    (got->flags >> XEN_DOMINF_shutdownshift) &
+                    XEN_DOMINF_shutdownmask;
+                libxl__event_occurred(gc, ev);
+
+                evg->shutdown_reported = 1;
+            }
+            evg = LIBXL_TAILQ_NEXT(evg, entry);
+        }
+
+        assert(rc); /* rc==0 results in us eating all evgs and quitting */
+        domid = gotend[-1].domain;
     }
-    rc = 0;
-out:
-    GC_FREE;
-    return rc;
+ all_reported:
+ out:
+
+    CTX_UNLOCK;
 }
 
-int libxl_get_event(libxl_ctx *ctx, libxl_event *event)
-{
-    unsigned int num;
-    char **events = xs_read_watch(ctx->xsh, &num);
-    if (num != 2) {
-        free(events);
-        return ERROR_FAIL;
+int libxl_evenable_domain_death(libxl_ctx *ctx, uint32_t domid,
+                libxl_ev_user user, libxl_evgen_domain_death **evgen_out) {
+    GC_INIT(ctx);
+    libxl_evgen_domain_death *evg, *evg_search;
+    int rc;
+    
+    CTX_LOCK;
+
+    evg = malloc(sizeof(*evg));  if (!evg) { rc = ERROR_NOMEM; goto out; }
+    memset(evg, 0, sizeof(*evg));
+    evg->domid = domid;
+    evg->user = user;
+
+    LIBXL_TAILQ_INSERT_SORTED(&ctx->death_list, entry, evg, evg_search, ,
+                              evg->domid > evg_search->domid);
+
+    if (!libxl__ev_xswatch_isregistered(&ctx->death_watch)) {
+        rc = libxl__ev_xswatch_register(gc, &ctx->death_watch,
+                        domain_death_xswatch_callback, "@releaseDomain");
+        if (rc) { libxl__evdisable_domain_death(gc, evg); goto out; }
     }
-    event->path = strdup(events[XS_WATCH_PATH]);
-    event->token = strdup(events[XS_WATCH_TOKEN]);
-    event->type = atoi(event->token);
-    free(events);
-    return 0;
-}
 
-int libxl_stop_waiting(libxl_ctx *ctx, libxl_waiter *waiter)
-{
-    if (!xs_unwatch(ctx->xsh, waiter->path, waiter->token))
-        return ERROR_FAIL;
-    else
-        return 0;
-}
+    rc = 0;
 
-int libxl_free_event(libxl_event *event)
-{
-    free(event->path);
-    free(event->token);
-    return 0;
-}
+ out:
+    CTX_UNLOCK;
+    return rc;
+};
 
-int libxl_free_waiter(libxl_waiter *waiter)
-{
-    free(waiter->path);
-    free(waiter->token);
-    return 0;
-}
+void libxl__evdisable_domain_death(libxl__gc *gc,
+                                   libxl_evgen_domain_death *evg) {
+    CTX_LOCK;
 
-int libxl_event_get_domain_death_info(libxl_ctx *ctx, uint32_t domid, libxl_event *event, libxl_dominfo *info)
-{
-    if (libxl_domain_info(ctx, info, domid) < 0)
-        return 0;
+    if (!evg->death_reported)
+        LIBXL_TAILQ_REMOVE(&CTX->death_list, evg, entry);
+    else
+        LIBXL_TAILQ_REMOVE(&CTX->death_reported, evg, entry);
 
-    if (info->running || (!info->shutdown && !info->dying))
-        return ERROR_INVAL;
+    free(evg);
 
-    return 1;
+    if (!LIBXL_TAILQ_FIRST(&CTX->death_list) &&
+        libxl__ev_xswatch_isregistered(&CTX->death_watch))
+        libxl__ev_xswatch_deregister(gc, &CTX->death_watch);
+
+    CTX_UNLOCK;
 }
 
-int libxl_event_get_disk_eject_info(libxl_ctx *ctx, uint32_t domid, libxl_event *event, libxl_device_disk *disk)
-{
+void libxl_evdisable_domain_death(libxl_ctx *ctx,
+                                  libxl_evgen_domain_death *evg) {
     GC_INIT(ctx);
-    char *path;
+    libxl__evdisable_domain_death(gc, evg);
+    GC_FREE;
+}
+
+static void disk_eject_xswatch_callback(libxl__gc *gc, libxl__ev_xswatch *watch,
+                                        const char *wpath, const char *epath) {
+    libxl_evgen_disk_eject *evg = (void*)watch;
     char *backend;
     char *value;
     char backend_type[BACKEND_STRING_SIZE+1];
 
-    value = libxl__xs_read(gc, XBT_NULL, event->path);
+    value = libxl__xs_read(gc, XBT_NULL, wpath);
 
-    if (!value || strcmp(value,  "eject")) {
-        GC_FREE;
-        return 0;
+    if (!value || strcmp(value,  "eject"))
+        return;
+
+    if (libxl__xs_write(gc, XBT_NULL, wpath, "")) {
+        LIBXL__EVENT_DISASTER(gc, "xs_write failed acknowledging eject",
+                              errno, LIBXL_EVENT_TYPE_DISK_EJECT);
+        return;
     }
 
-    path = strdup(event->path);
-    path[strlen(path) - 6] = '\0';
-    backend = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/backend", path));
+    libxl_event *ev = NEW_EVENT(gc, DISK_EJECT, evg->domid);
+    libxl_device_disk *disk = &ev->u.disk_eject.disk;
+    
+    backend = libxl__xs_read(gc, XBT_NULL,
+                             libxl__sprintf(gc, "%.*s/backend",
+                                            (int)strlen(wpath)-6, wpath));
 
     sscanf(backend,
-            "/local/domain/%d/backend/%" TOSTRING(BACKEND_STRING_SIZE) "[a-z]/%*d/%*d",
-            &disk->backend_domid, backend_type);
+            "/local/domain/%d/backend/%" TOSTRING(BACKEND_STRING_SIZE)
+           "[a-z]/%*d/%*d",
+           &disk->backend_domid, backend_type);
     if (!strcmp(backend_type, "tap") || !strcmp(backend_type, "vbd")) {
         disk->backend = LIBXL_DISK_BACKEND_TAP;
     } else if (!strcmp(backend_type, "qdisk")) {
@@ -739,19 +829,82 @@ int libxl_event_get_disk_eject_info(libxl_ctx *ctx, uint32_t domid, libxl_event
         disk->backend = LIBXL_DISK_BACKEND_UNKNOWN;
     }
 
-    disk->pdev_path = strdup("");
+    disk->pdev_path = strdup(""); /* xxx fixme malloc failure */
     disk->format = LIBXL_DISK_FORMAT_EMPTY;
     /* this value is returned to the user: do not free right away */
-    disk->vdev = xs_read(ctx->xsh, XBT_NULL, libxl__sprintf(gc, "%s/dev", backend), NULL);
+    disk->vdev = xs_read(CTX->xsh, XBT_NULL,
+                         libxl__sprintf(gc, "%s/dev", backend), NULL);
     disk->removable = 1;
     disk->readwrite = 0;
     disk->is_cdrom = 1;
 
-    free(path);
+    libxl__event_occurred(gc, ev);
+}
+
+int libxl_evenable_disk_eject(libxl_ctx *ctx, uint32_t guest_domid,
+                              const char *vdev, libxl_ev_user user,
+                              libxl_evgen_disk_eject **evgen_out) {
+    GC_INIT(ctx);
+    CTX_LOCK;
+    int rc;
+    char *path;
+    libxl_evgen_disk_eject *evg = NULL;
+
+    evg = malloc(sizeof(*evg));  if (!evg) { rc = ERROR_NOMEM; goto out; }
+    memset(evg, 0, sizeof(*evg));
+    evg->user = user;
+    evg->domid = guest_domid;
+    LIBXL_LIST_INSERT_HEAD(&CTX->disk_eject_evgens, evg, entry);
+
+    evg->vdev = strdup(vdev);
+    if (!evg->vdev) { rc = ERROR_NOMEM; goto out; }
+
+    uint32_t domid = libxl_get_stubdom_id(ctx, guest_domid);
+
+    if (!domid)
+        domid = guest_domid;
+
+    path = libxl__sprintf(gc, "%s/device/vbd/%d/eject",
+                 libxl__xs_get_dompath(gc, domid),
+                 libxl__device_disk_dev_number(vdev, NULL, NULL));
+    if (!path) { rc = ERROR_NOMEM; goto out; }
+
+    rc = libxl__ev_xswatch_register(gc, &evg->watch,
+                                    disk_eject_xswatch_callback, path);
+    if (rc) goto out;
+
+    CTX_UNLOCK;
     GC_FREE;
-    return 1;
+    return 0;
+
+ out:
+    if (evg)
+        libxl__evdisable_disk_eject(gc, evg);
+    CTX_UNLOCK;
+    GC_FREE;
+    return rc;
+}
+
+void libxl__evdisable_disk_eject(libxl__gc *gc, libxl_evgen_disk_eject *evg) {
+    CTX_LOCK;
+
+    LIBXL_LIST_REMOVE(evg, entry);
+
+    if (libxl__ev_xswatch_isregistered(&evg->watch))
+        libxl__ev_xswatch_deregister(gc, &evg->watch);
+
+    free(evg->vdev);
+    free(evg);
+
+    CTX_UNLOCK;
 }
 
+void libxl_evdisable_disk_eject(libxl_ctx *ctx, libxl_evgen_disk_eject *evg) {
+    GC_INIT(ctx);
+    libxl__evdisable_disk_eject(gc, evg);
+    GC_FREE;
+}    
+
 int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid, int force)
 {
     GC_INIT(ctx);
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 8d6c788..bdb7b56 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -53,7 +53,10 @@
  *    A public function may be called from within libxl; the call
  *    context initialisation macros will make sure that the internal
  *    caller's context is reused (eg, so that the same xenstore
- *    transaction is used).
+ *    transaction is used).  But in-libxl callers of libxl public
+ *    functions should note that any libxl public function may cause
+ *    recursively reentry into libxl via the application's event
+ *    callback hook.
  *
  *    Public functions have names like libxl_foobar.
  *
@@ -152,6 +155,8 @@ void libxl_key_value_list_dispose(libxl_key_value_list *kvl);
 
 typedef uint32_t libxl_hwcap[8];
 
+typedef uint64_t libxl_ev_user;
+
 typedef struct {
     uint32_t size;          /* number of bytes in map */
     uint8_t *map;
@@ -200,6 +205,9 @@ typedef struct {
     int v;
 } libxl_enum_string_table;
 
+struct libxl_event;
+typedef LIBXL_TAILQ_ENTRY(struct libxl_event) libxl_ev_link;
+
 typedef struct libxl__ctx libxl_ctx;
 
 #include "_libxl_types.h"
@@ -298,51 +306,6 @@ int libxl_run_bootloader(libxl_ctx *ctx,
 
   /* 0 means ERROR_ENOMEM, which we have logged */
 
-/* events handling */
-
-typedef struct {
-    /* event type */
-    libxl_event_type type;
-    /* data for internal use of the library */
-    char *path;
-    char *token;
-} libxl_event;
-
-typedef struct {
-    char *path;
-    char *token;
-} libxl_waiter;
-
-
-int libxl_get_wait_fd(libxl_ctx *ctx, int *fd);
-/* waiter is allocated by the caller */
-int libxl_wait_for_domain_death(libxl_ctx *ctx, uint32_t domid, libxl_waiter *waiter);
-/* waiter is a preallocated array of num_disks libxl_waiter elements */
-int libxl_wait_for_disk_ejects(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *disks, int num_disks, libxl_waiter *waiter);
-int libxl_get_event(libxl_ctx *ctx, libxl_event *event);
-int libxl_stop_waiting(libxl_ctx *ctx, libxl_waiter *waiter);
-int libxl_free_event(libxl_event *event);
-int libxl_free_waiter(libxl_waiter *waiter);
-
-/*
- * Returns:
- *  - 0 if the domain is dead but there is no cleanup to be done. e.g
- *    because someone else has already done it.
- *  - 1 if the domain is dead and there is cleanup to be done.
- *
- * Can return error if the domain exists and is still running.
- *
- * *info will contain valid domain state iff 1 is returned. In
- * particular if 1 is returned then info->shutdown_reason is
- * guaranteed to be valid since by definition the domain is
- * (shutdown||dying))
- */
-int libxl_event_get_domain_death_info(libxl_ctx *ctx, uint32_t domid, libxl_event *event, libxl_dominfo *info);
-
-/*
- * Returns true and fills *disk if the caller should eject the disk
- */
-int libxl_event_get_disk_eject_info(libxl_ctx *ctx, uint32_t domid, libxl_event *event, libxl_device_disk *disk);
 
 int libxl_domain_rename(libxl_ctx *ctx, uint32_t domid,
                         const char *old_name, const char *new_name);
diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
index dc6543f..5a93bdf 100644
--- a/tools/libxl/libxl_event.c
+++ b/tools/libxl/libxl_event.c
@@ -149,7 +149,8 @@ static void time_insert_finite(libxl__gc *gc, libxl__ev_time *ev)
 }
 
 static int time_register_finite(libxl__gc *gc, libxl__ev_time *ev,
-                                struct timeval abs) {
+                                struct timeval abs)
+{
     int rc;
     
     rc = OSEVENT_HOOK(timeout_register, &ev->for_app_reg, abs, ev);
@@ -512,9 +513,9 @@ void libxl__ev_xswatch_deregister(libxl__gc *gc, libxl__ev_xswatch *w)
  * osevent poll
  */
 
-int libxl_osevent_beforepoll(libxl_ctx *ctx, int *nfds_io,
-                             struct pollfd *fds, int *timeout_upd,
-                             struct timeval now)
+static int beforepoll_unlocked(libxl__gc *gc, int *nfds_io,
+                               struct pollfd *fds, int *timeout_upd,
+                               struct timeval now)
 {
     libxl__ev_fd *efd;
     int i;
@@ -526,9 +527,6 @@ int libxl_osevent_beforepoll(libxl_ctx *ctx, int *nfds_io,
      * the fds array corresponds to a slot in fd_beforepolled.
      */
 
-    GC_INIT(ctx);
-    CTX_LOCK;
-
     if (*nfds_io) {
         /*
          * As an optimisation, we don't touch fd_beforepolled_used
@@ -600,17 +598,26 @@ int libxl_osevent_beforepoll(libxl_ctx *ctx, int *nfds_io,
             *timeout_upd = our_timeout;
     }
 
-    CTX_UNLOCK;
-    GC_FREE;
     return rc;
 }
 
-void libxl_osevent_afterpoll(libxl_ctx *ctx, int nfds, const struct pollfd *fds,
+int libxl_osevent_beforepoll(libxl_ctx *ctx, int *nfds_io,
+                             struct pollfd *fds, int *timeout_upd,
                              struct timeval now)
 {
-    int i;
     GC_INIT(ctx);
     CTX_LOCK;
+    int rc = beforepoll_unlocked(gc, nfds_io, fds, timeout_upd, now);
+    CTX_UNLOCK;
+    GC_FREE;
+    return rc;
+}
+
+static void afterpoll_unlocked(libxl__gc *gc,
+                               int nfds, const struct pollfd *fds,
+                               struct timeval now)
+{
+    int i;
 
     assert(nfds <= CTX->fd_beforepolled_used);
 
@@ -646,12 +653,18 @@ void libxl_osevent_afterpoll(libxl_ctx *ctx, int nfds, const struct pollfd *fds,
 
         etime->func(gc, etime, &etime->abs);
     }
+}
 
+void libxl_osevent_afterpoll(libxl_ctx *ctx, int nfds, const struct pollfd *fds,
+                             struct timeval now)
+{
+    GC_INIT(ctx);
+    CTX_LOCK;
+    afterpoll_unlocked(gc, nfds, fds, now);
     CTX_UNLOCK;
     GC_FREE;
 }
 
-
 /*
  * osevent hook and callback machinery
  */
@@ -714,11 +727,10 @@ void libxl__event_disaster(libxl__gc *gc, const char *msg, int errnoval,
                type ? libxl_event_type_to_string(type) : "",
                type ? ")" : "");
 
-    /*
-     * FIXME: This should call the "disaster" hook supplied to
-     * libxl_event_register_callbacks, which will be introduced in the
-     * next patch.
-     */
+    if (CTX->event_hooks && CTX->event_hooks->disaster) {
+        CTX->event_hooks->disaster(CTX->event_hooks_user, type, msg, errnoval);
+        return;
+    }
 
     const char verybad[] =
         "DISASTER in event loop not handled by libxl application";
@@ -728,6 +740,160 @@ void libxl__event_disaster(libxl__gc *gc, const char *msg, int errnoval,
 }
 
 /*
+ * Event retrieval etc.
+ */
+
+void libxl_event_register_callbacks(libxl_ctx *ctx,
+                  const libxl_event_hooks *hooks, void *user)
+{
+    ctx->event_hooks = hooks;
+    ctx->event_hooks_user = user;
+}
+
+void libxl__event_occurred(libxl__gc *gc, libxl_event *event)
+{
+    if (CTX->event_hooks &&
+        (CTX->event_hooks->event_occurs_mask & (1UL << event->type))) {
+        /* libxl__gc_cleanup will call the callback, just before exit
+         * from libxl.  This helps avoid reentrancy bugs: parts of
+         * libxl that call libxl__event_occurred do not have to worry
+         * that libxl might be reentered at that point. */
+        LIBXL_TAILQ_INSERT_TAIL(&gc->occurred_for_callback, event, link);
+        return;
+    } else {
+        LIBXL_TAILQ_INSERT_TAIL(&CTX->occurred, event, link);
+    }
+}
+
+void libxl_event_free(libxl_ctx *ctx, libxl_event *event)
+{
+    /* Exceptionally, this function may be called from libxl, with ctx==0 */
+    libxl_event_dispose(event);
+    free(event);
+}
+
+libxl_event *libxl__event_new(libxl__gc *gc,
+                              libxl_event_type type, uint32_t domid)
+{
+    libxl_event *ev;
+
+    ev = malloc(sizeof(*ev));
+    if (!ev) {
+        LIBXL__EVENT_DISASTER(gc, "allocate new event", errno, type);
+        return NULL;
+    }
+
+    memset(ev, 0, sizeof(*ev));
+    ev->type = type;
+    ev->domid = domid;
+
+    return ev;
+}
+
+static int event_check_unlocked(libxl__gc *gc, libxl_event **event_r,
+                                unsigned long typemask,
+                                libxl_event_predicate *pred, void *pred_user)
+{
+    libxl_event *ev;
+    int rc;
+
+    LIBXL_TAILQ_FOREACH(ev, &CTX->occurred, link) {
+        if (!(typemask & (1UL << ev->type)))
+            continue;
+
+        if (pred && !pred(ev, pred_user))
+            continue;
+
+        /* got one! */
+        LIBXL_TAILQ_REMOVE(&CTX->occurred, ev, link);
+        *event_r = ev;
+        rc = 0;
+        goto out;
+    }
+    rc = ERROR_NOT_READY;
+
+ out:
+    return rc;
+}
+
+int libxl_event_check(libxl_ctx *ctx, libxl_event **event_r,
+                      unsigned long typemask,
+                      libxl_event_predicate *pred, void *pred_user)
+{
+    GC_INIT(ctx);
+    CTX_LOCK;
+    int rc = event_check_unlocked(gc, event_r, typemask, pred, pred_user);
+    CTX_UNLOCK;
+    GC_FREE;
+    return rc;
+}
+
+int libxl_event_wait(libxl_ctx *ctx, libxl_event **event_r,
+                     unsigned long typemask,
+                     libxl_event_predicate *pred, void *pred_user)
+{
+    int rc;
+    struct timeval now;
+
+    GC_INIT(ctx);
+    CTX_LOCK;
+
+    for (;;) {
+        rc = event_check_unlocked(gc, event_r, typemask, pred, pred_user);
+        if (rc != ERROR_NOT_READY) goto out;
+
+        rc = libxl__gettimeofday(gc, &now);
+        if (rc) goto out;
+
+        int timeout;
+
+        for (;;) {
+            int nfds = CTX->fd_polls_allocd;
+            timeout = -1;
+            rc = beforepoll_unlocked(gc, &nfds, CTX->fd_polls, &timeout, now);
+            if (!rc) break;
+            if (rc != ERROR_BUFFERFULL) goto out;
+            
+            struct pollfd *newarray =
+                (nfds > INT_MAX / sizeof(struct pollfd) / 2) ? 0 :
+                realloc(CTX->fd_polls, sizeof(*newarray) * nfds);
+            
+            if (!newarray) { rc = ERROR_NOMEM; goto out; }
+
+            CTX->fd_polls = newarray;
+            CTX->fd_polls_allocd = nfds;
+        }
+
+        rc = poll(CTX->fd_polls, CTX->fd_polls_allocd, timeout);
+        if (rc < 0) {
+            if (errno == EINTR) continue;
+            LIBXL__LOG_ERRNOVAL(CTX, LIBXL__LOG_ERROR, errno, "poll failed");
+            rc = ERROR_FAIL;
+            goto out;
+        }
+
+        rc = libxl__gettimeofday(gc, &now);
+        if (rc) goto out;
+
+        afterpoll_unlocked(gc, CTX->fd_polls_allocd, CTX->fd_polls, now);
+
+        /* we unlock and free the gc each time we go through this loop,
+         * so that (a) we don't accumulate garbage and (b) any events
+         * which are to be dispatched by callback are actually delivered
+         * in a timely fashion.
+         */
+        CTX_UNLOCK;
+        libxl__gc_cleanup(gc);
+        CTX_LOCK;
+    }
+
+ out:
+    CTX_UNLOCK;
+    GC_FREE;
+    return rc;
+}
+
+/*
  * Local variables:
  * mode: C
  * c-basic-offset: 4
diff --git a/tools/libxl/libxl_event.h b/tools/libxl/libxl_event.h
index cc4a348..3001100 100644
--- a/tools/libxl/libxl_event.h
+++ b/tools/libxl/libxl_event.h
@@ -18,6 +18,178 @@
 
 #include <libxl.h>
 
+/*======================================================================*/
+
+/*
+ * Domain event handling - getting Xen events from libxl
+ */
+
+#define LIBXL_EVENTMASK_ALL (~(unsigned long)0)
+
+typedef int libxl_event_predicate(const libxl_event*, void *user);
+  /* Return value is 0 if the event is unwanted or non-0 if it is.
+   * Predicates are not allowed to fail.
+   */
+
+int libxl_event_check(libxl_ctx *ctx, libxl_event **event_r,
+                      unsigned long typemask,
+                      libxl_event_predicate *predicate, void *predicate_user);
+  /* Searches for an event, already-happened, which matches typemask
+   * and predicate.  predicate==0 matches any event.
+   * libxl_event_check returns the event, which must then later be
+   * freed by the caller using libxl_event_free.
+   *
+   * Returns ERROR_NOT_READY if no such event has happened.
+   */
+
+int libxl_event_wait(libxl_ctx *ctx, libxl_event **event_r,
+                     unsigned long typemask,
+                     libxl_event_predicate *predicate, void *predicate_user);
+  /* Like libxl_event_check but blocks if no suitable events are
+   * available, until some are.  Uses libxl_osevent_beforepoll/
+   * _afterpoll so may be inefficient if very many domains are being
+   * handled by a single program.
+   */
+
+void libxl_event_free(libxl_ctx *ctx, libxl_event *event);
+
+
+/* Alternatively or additionally, the application may also use this: */
+
+typedef struct libxl_event_hooks {
+    uint64_t event_occurs_mask;
+    void (*event_occurs)(void *user, const libxl_event *event);
+    void (*disaster)(void *user, libxl_event_type type,
+                     const char *msg, int errnoval);
+} libxl_event_hooks;
+
+void libxl_event_register_callbacks(libxl_ctx *ctx,
+                                    const libxl_event_hooks *hooks, void *user);
+  /*
+   * Arranges that libxl will henceforth call event_occurs for any
+   * events whose type is set in event_occurs_mask, rather than
+   * queueing the event for retrieval by libxl_event_check/wait.
+   * Events whose bit is clear in mask are not affected.
+   *
+   * event becomes owned by the application and must be freed, either
+   * by event_occurs or later.
+   *
+   * event_occurs may be NULL if mask is 0.
+   *
+   * libxl_event_register_callback also provides a way for libxl to
+   * report to the application that there was a problem reporting
+   * events; this can occur due to lack of host memory during event
+   * handling, or other wholly unrecoverable errors from system calls
+   * made by libxl.  This will not happen for frivolous reasons - only
+   * if the system, or the Xen components of it, are badly broken.
+   *
+   * msg and errnoval will describe the action that libxl was trying
+   * to do, and type specifies the type of libxl events which may be
+   * missing.  type may be 0 in which case events of all types may be
+   * missing.
+   *
+   * disaster may be NULL.  If it is, or if _register_callbacks has
+   * not been called, errors of this kind are fatal to the entire
+   * application: libxl will print messages to its logs and to stderr
+   * and call exit(-1).
+   *
+   * If disaster returns, it may be the case that some or all future
+   * libxl calls will return errors; likewise it may be the case that
+   * no more events (of the specified type, if applicable) can be
+   * produced.  An application which supplies a disaster function
+   * should normally react either by exiting, or by (when it has
+   * returned to its main event loop) shutting down libxl with
+   * libxl_ctx_free and perhaps trying to restart it with
+   * libxl_ctx_init.
+   *
+   * In any case before calling disaster, libxl will have logged a
+   * message with level XTL_CRITICAL.
+   *
+   * Reentrancy: it IS permitted to call libxl from within
+   * event_occurs.  It is NOT permitted to call libxl from within
+   * disaster.
+   *
+   * libxl_event_register_callbacks may be called as many times, with
+   * 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.
+   */
+
+
+/*
+ * Events are only generated if they have been requested.
+ * The following functions request the generation of specific events.
+ *
+ * Each set of functions for controlling event generation has this form:
+ *
+ *   typedef struct libxl__evgen_FOO libxl__evgen_FOO;
+ *   int libxl_evenable_FOO(libxl_ctx *ctx, FURTHER PARAMETERS,
+ *                          libxl_ev_user user, libxl__evgen_FOO **evgen_out);
+ *   void libxl_evdisable_FOO(libxl_ctx *ctx, libxl__evgen_FOO *evgen);
+ *
+ * The evenable function arranges that the events (as described in the
+ * doc comment for the individual function) will start to be generated
+ * by libxl.  On success, *evgen_out is set to a non-null pointer to
+ * an opaque struct.
+ *
+ * The user value is returned in the generated events and may be
+ * used by the caller for whatever it likes.  The type ev_user is
+ * guaranteed to be an unsigned integer type which is at least
+ * as big as uint64_t and is also guaranteed to be big enough to
+ * contain any intptr_t value.
+ *
+ * If it becomes desirable to stop generation of the relevant events,
+ * or to reclaim the resources in libxl associated with the evgen
+ * structure, the same evgen value should be passed to the evdisable
+ * function.  However, note that events which occurred prior to the
+ * evdisable call may still be returned.
+ *
+ * The caller may enable identical events more than once.  If they do
+ * so, each actual occurrence will generate several events to be
+ * returned by libxl_event_check, with the appropriate user value(s).
+ * Aside from this, each occurrence of each event is returned by
+ * libxl_event_check exactly once.
+ *
+ * An evgen is associated with the libxl_ctx used for its creation.
+ * After libxl_ctx_free, all corresponding evgen handles become
+ * invalid and must no longer be passed to evdisable.
+ *
+ * Events enabled with evenable prior to a fork and libxl_ctx_postfork
+ * are no longer generated after the fork/postfork; however the evgen
+ * structures are still valid and must be passed to evdisable if the
+ * memory they use should not be leaked.
+ *
+ * Applications should ensure that they eventually retrieve every
+ * event using libxl_event_check or libxl_event_wait, since events
+ * which occur but are not retreived by the application will be queued
+ * inside libxl indefinitely.  libxl_event_check/_wait may be O(n)
+ * where n is the number of queued events which do not match the
+ * criteria specified in the arguments to check/wait.
+ */
+
+typedef struct libxl__evgen_domain_death libxl_evgen_domain_death;
+int libxl_evenable_domain_death(libxl_ctx *ctx, uint32_t domid,
+                         libxl_ev_user, libxl_evgen_domain_death **evgen_out);
+void libxl_evdisable_domain_death(libxl_ctx *ctx, libxl_evgen_domain_death*);
+  /* Arranges for the generation of DOMAIN_SHUTDOWN and DOMAIN_DESTROY
+   * events.  A domain which is destroyed before it shuts down
+   * may generate only a DESTROY event.
+   */
+
+typedef struct libxl__evgen_disk_eject libxl_evgen_disk_eject;
+int libxl_evenable_disk_eject(libxl_ctx *ctx, uint32_t domid, const char *vdev,
+                        libxl_ev_user, libxl_evgen_disk_eject **evgen_out);
+void libxl_evdisable_disk_eject(libxl_ctx *ctx, libxl_evgen_disk_eject*);
+  /* Arranges for the generation of DISK_EJECT events.  A copy of the
+   * string *vdev will be made for libxl's internal use, and a pointer
+   * to this (or some other) copy will be returned as the vdev
+   * member of event.u.
+   */
+
 
 /*======================================================================*/
 
@@ -36,10 +208,10 @@
  *      poll();
  *      libxl_osevent_afterpoll(...);
  *      for (;;) {
- *        r=libxl_event_check(...);
- *        if (r==LIBXL_NOT_READY) break;
- *        if (r) handle failure;
- *        do something with the event;
+ *          r = libxl_event_check(...);
+ *          if (r==LIBXL_NOT_READY) break;
+ *          if (r) goto error_out;
+ *          do something with the event;
  *      }
  *   }
  *
@@ -171,6 +343,8 @@ void libxl_osevent_register_hooks(libxl_ctx *ctx,
    * Of these we would normally recommend (a).
    *
    * The value *hooks is not copied and must outlast the libxl_ctx.
+   *
+   * The value of user is stored by libxl and passed to the callbacks.
    */
 
 /* It is NOT legal to call _occurred_ reentrantly within any libxl
diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c
index 232cc4a..afae0dd 100644
--- a/tools/libxl/libxl_internal.c
+++ b/tools/libxl/libxl_internal.c
@@ -74,6 +74,12 @@ void libxl__gc_cleanup(libxl__gc *gc)
     free(gc->alloc_ptrs);
     gc->alloc_ptrs = 0;
     gc->alloc_maxsize = 0;
+
+    libxl_event *ev, *ev_tmp;
+    LIBXL_TAILQ_FOREACH_SAFE(ev, &gc->occurred_for_callback, link, ev_tmp) {
+        LIBXL_TAILQ_REMOVE(&gc->occurred_for_callback, ev, link);
+        CTX->event_hooks->event_occurs(CTX->event_hooks_user, ev);
+    }
 }
 
 void *libxl__zalloc(libxl__gc *gc, int bytes)
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index c4a5fa1..2f4d437 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -154,11 +154,45 @@ typedef struct libxl__ev_watch_slot {
     
 libxl__ev_xswatch *libxl__watch_slot_contents(libxl__gc *gc, int slotnum);
 
+
+/*
+ * evgen structures, which are the state we use for generating
+ * events for the caller.
+ *
+ * In general in each case there's an internal and an external
+ * version of the _evdisable_FOO function; the internal one is
+ * used during cleanup.
+ */
+
+struct libxl__evgen_domain_death {
+    uint32_t domid;
+    unsigned shutdown_reported:1, death_reported:1;
+    LIBXL_TAILQ_ENTRY(libxl_evgen_domain_death) entry;
+        /* on list .death_reported ? CTX->death_list : CTX->death_reported */
+    libxl_ev_user user;
+};
+_hidden void
+libxl__evdisable_domain_death(libxl__gc*, libxl_evgen_domain_death*);
+
+struct libxl__evgen_disk_eject {
+    libxl__ev_xswatch watch;
+    uint32_t domid;
+    LIBXL_LIST_ENTRY(libxl_evgen_disk_eject) entry;
+    libxl_ev_user user;
+    char *vdev;
+};
+_hidden void
+libxl__evdisable_disk_eject(libxl__gc*, libxl_evgen_disk_eject*);
+
+
 struct libxl__ctx {
     xentoollog_logger *lg;
     xc_interface *xch;
     struct xs_handle *xsh;
 
+    const libxl_event_hooks *event_hooks;
+    void *event_hooks_user;
+
     pthread_mutex_t lock; /* protects data structures hanging off the ctx */
       /* Always use CTX_LOCK and CTX_UNLOCK to manipulate this.
        *
@@ -171,12 +205,17 @@ struct libxl__ctx {
        * documented in the libxl public interface.
        */
 
+    LIBXL_TAILQ_HEAD(libxl__event_list, libxl_event) occurred;
+
     int osevent_in_hook;
     const libxl_osevent_hooks *osevent_hooks;
     void *osevent_user;
       /* See the comment for OSEVENT_HOOK_INTERN in libxl_event.c
        * for restrictions on the use of the osevent fields. */
 
+    struct pollfd *fd_polls;
+    int fd_polls_allocd;
+
     int fd_beforepolled_allocd, fd_beforepolled_used;
     libxl__ev_fd **fd_beforepolled; /* see libxl_osevent_beforepoll */
     LIBXL_LIST_HEAD(, libxl__ev_fd) efds;
@@ -188,6 +227,13 @@ struct libxl__ctx {
     uint32_t watch_counter; /* helps disambiguate slot reuse */
     libxl__ev_fd watch_efd;
 
+    LIBXL_TAILQ_HEAD(libxl__evgen_domain_death_list, libxl_evgen_domain_death)
+        death_list /* sorted by domid */,
+        death_reported;
+    libxl__ev_xswatch death_watch;
+    
+    LIBXL_LIST_HEAD(, libxl_evgen_disk_eject) disk_eject_evgens;
+
     /* for callers who reap children willy-nilly; caller must only
      * set this after libxl_init and before any other call - or
      * may leave them untouched */
@@ -223,12 +269,14 @@ struct libxl__gc {
     int alloc_maxsize;
     void **alloc_ptrs;
     libxl_ctx *owner;
+    struct libxl__event_list occurred_for_callback;
 };
 
-#define LIBXL_INIT_GC(gc,ctx) do{               \
-        (gc).alloc_maxsize = 0;                 \
-        (gc).alloc_ptrs = 0;                    \
-        (gc).owner = (ctx);                     \
+#define LIBXL_INIT_GC(gc,ctx) do{                       \
+        (gc).alloc_maxsize = 0;                         \
+        (gc).alloc_ptrs = 0;                            \
+        (gc).owner = (ctx);                             \
+        LIBXL_TAILQ_INIT(&(gc).occurred_for_callback);  \
     } while(0)
 
 static inline libxl_ctx *libxl__gc_owner(libxl__gc *gc)
@@ -250,7 +298,9 @@ static inline libxl_ctx *libxl__gc_owner(libxl__gc *gc)
  */
 /* register @ptr in @gc for free on exit from outermost libxl callframe. */
 _hidden int libxl__ptr_add(libxl__gc *gc, void *ptr);
-/* if this is the outermost libxl callframe then free all pointers in @gc */
+/* if this is the outermost libxl callframe then free all pointers in @gc
+ *  and report all occurred events via callback, if applicable.
+ * May reenters the application so must not be called with ctx locked. */
 _hidden void libxl__gc_cleanup(libxl__gc *gc);
 /* allocate and zero @bytes. (similar to a gc'd malloc(3)+memzero()) */
 _hidden void *libxl__zalloc(libxl__gc *gc, int bytes);
@@ -360,6 +410,9 @@ _hidden char *libxl__xs_libxl_path(libxl__gc *gc, uint32_t domid);
  *
  * Callers of libxl__ev_KIND_register must ensure that the
  * registration is undone, with _deregister, in libxl_ctx_free.
+ * This means that normally each kind of libxl__evgen (ie each
+ * application-requested event source) needs to be on a list so that
+ * it can be automatically deregistered as promised in libxl_event.h.
  */
 
 
@@ -403,6 +456,25 @@ static inline int libxl__ev_xswatch_isregistered(const libxl__ev_xswatch *xw)
 
 
 
+/*
+ * Other event-handling support provided by the libxl event core to
+ * the rest of libxl.
+ */
+
+_hidden void libxl__event_occurred(libxl__gc*, libxl_event *event);
+  /* Arranges to notify the application that the event has occurred.
+   * event should be suitable for passing to libxl_event_free. */
+
+_hidden libxl_event *libxl__event_new(libxl__gc*, libxl_event_type,
+                                      uint32_t domid);
+  /* Convenience function.
+   * Allocates a new libxl_event, fills in domid and type.
+   * If allocation fails, calls _disaster, and returns NULL. */
+
+#define NEW_EVENT(gc, type, domid)                              \
+    libxl__event_new((gc), LIBXL_EVENT_TYPE_##type, (domid));
+    /* Convenience macro. */
+
 _hidden void libxl__event_disaster(libxl__gc*, const char *msg, int errnoval,
                                    libxl_event_type type /* may be 0 */,
                                    const char *file, int line,
@@ -415,6 +487,9 @@ _hidden void libxl__event_disaster(libxl__gc*, const char *msg, int errnoval,
    * libxl__ev_FOO_callback or an application event), but are
    * prevented from doing so due to eg lack of memory.
    *
+   * See the "disaster" member of libxl_event_hooks and associated
+   * comment in libxl_event.h.
+   *
    * NB that this function may return and the caller isn't supposed to
    * then crash, although it may fail (and henceforth leave things in
    * a state where many or all calls fail).
@@ -895,7 +970,7 @@ libxl__device_model_version_running(libxl__gc *gc, uint32_t domid);
  */
 
 #define GC_INIT(ctx)  libxl__gc gc[1]; LIBXL_INIT_GC(gc[0],ctx)
-#define GC_FREE       libxl__gc_cleanup(gc)
+#define GC_FREE       libxl__gc_cleanup(gc) /* MUST NOT CALL WITH CTX LOCKED */
 #define CTX           libxl__gc_owner(gc)
 
 
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index d59d2cb..5a713f0 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -75,11 +75,6 @@ libxl_action_on_shutdown = Enumeration("action_on_shutdown", [
     (6, "COREDUMP_RESTART"),
     ])
 
-libxl_event_type = Enumeration("event_type", [
-    (1, "DOMAIN_DEATH"),
-    (2, "DISK_EJECT"),
-    ])
-
 libxl_button = Enumeration("button", [
     (1, "POWER"),
     (2, "SLEEP"),
@@ -381,3 +376,33 @@ libxl_sched_credit = Struct("sched_credit", [
     ("weight", integer),
     ("cap", integer),
     ], dispose_fn=None)
+
+libxl_event_type = Enumeration("event_type", [
+    (1, "DOMAIN_SHUTDOWN"),
+    (2, "DOMAIN_DESTROY"),
+    (3, "DISK_EJECT"),
+    ])
+
+libxl_ev_user = Number("libxl_ev_user")
+
+libxl_ev_link = Builtin("ev_link", passby=PASS_BY_REFERENCE, private=True)
+
+libxl_event = Struct("event",[
+    ("link",     libxl_ev_link,0,
+     "for use by libxl; caller may use this once the event has been"
+     " returned by libxl_event_{check,wait}"),
+    ("domid",    libxl_domid),
+    ("domuuid",  libxl_uuid),
+    ("for_user", libxl_ev_user),
+    ("type",     libxl_event_type),
+    ("u", KeyedUnion(None, libxl_event_type, "type",
+          [("domain_shutdown", Struct(None, [
+                                             ("shutdown_reason", uint8),
+                                      ])),
+           ("domain_destroy", Struct(None, [])),
+           ("disk_eject", Struct(None, [
+                                        ("vdev", string),
+                                        ("disk", libxl_device_disk),
+                                 ])),
+           ]))])
+
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index f1e729c..e5738b7 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -1221,14 +1221,16 @@ skip_vfb:
     xlu_cfg_destroy(config);
 }
 
-/* Returns 1 if domain should be restarted, 2 if domain should be renamed then restarted  */
-static int handle_domain_death(libxl_ctx *ctx, uint32_t domid, libxl_event *event,
-                               libxl_domain_config *d_config, libxl_dominfo *info)
+/* Returns 1 if domain should be restarted,
+ * 2 if domain should be renamed then restarted, or 0 */
+static int handle_domain_death(libxl_ctx *ctx, uint32_t domid,
+                               libxl_event *event,
+                               libxl_domain_config *d_config)
 {
     int restart = 0;
     libxl_action_on_shutdown action;
 
-    switch (info->shutdown_reason) {
+    switch (event->u.domain_shutdown.shutdown_reason) {
     case SHUTDOWN_poweroff:
         action = d_config->on_poweroff;
         break;
@@ -1245,11 +1247,14 @@ static int handle_domain_death(libxl_ctx *ctx, uint32_t domid, libxl_event *even
         action = d_config->on_watchdog;
         break;
     default:
-        LOG("Unknown shutdown reason code %d. Destroying domain.", info->shutdown_reason);
+        LOG("Unknown shutdown reason code %d. Destroying domain.",
+            event->u.domain_shutdown.shutdown_reason);
         action = LIBXL_ACTION_ON_SHUTDOWN_DESTROY;
     }
 
-    LOG("Action for shutdown reason code %d is %s", info->shutdown_reason, action_on_shutdown_names[action]);
+    LOG("Action for shutdown reason code %d is %s",
+        event->u.domain_shutdown.shutdown_reason,
+        action_on_shutdown_names[action]);
 
     if (action == LIBXL_ACTION_ON_SHUTDOWN_COREDUMP_DESTROY || action == LIBXL_ACTION_ON_SHUTDOWN_COREDUMP_RESTART) {
         char *corefile;
@@ -1314,7 +1319,7 @@ static void replace_string(char **str, const char *val)
 
 
 static int preserve_domain(libxl_ctx *ctx, uint32_t domid, libxl_event *event,
-                           libxl_domain_config *d_config, libxl_dominfo *info)
+                           libxl_domain_config *d_config)
 {
     time_t now;
     struct tm tm;
@@ -1426,6 +1431,27 @@ static int autoconnect_console(libxl_ctx *ctx, uint32_t domid, void *priv)
     _exit(1);
 }
 
+static int domain_wait_event(libxl_event **event_r) {
+    int ret;
+    for (;;) {
+        ret = libxl_event_wait(ctx, event_r, LIBXL_EVENTMASK_ALL, 0,0);
+        if (ret) {
+            LOG("Domain %d, failed to get event, quitting (rc=%d)", domid, ret);
+            return ret;
+        }
+        if ((*event_r)->domid != domid) {
+            char *evstr = libxl_event_to_json(ctx, *event_r);
+            LOG("INTERNAL PROBLEM - ignoring unexpected event for"
+                " domain %d (expected %d): event=%s",
+                (*event_r)->domid, domid, evstr);
+            free(evstr);
+            libxl_event_free(ctx, *event_r);
+            continue;
+        }
+        return ret;
+    }
+}
+
 static int create_domain(struct domain_create *dom_info)
 {
     libxl_domain_config d_config;
@@ -1439,10 +1465,11 @@ static int create_domain(struct domain_create *dom_info)
     const char *restore_file = dom_info->restore_file;
     int migrate_fd = dom_info->migrate_fd;
 
-    int fd, i;
+    int i;
     int need_daemon = daemonize;
     int ret, rc;
-    libxl_waiter *w1 = NULL, *w2 = NULL;
+    libxl_evgen_domain_death *deathw = NULL;
+    libxl_evgen_disk_eject **diskws = NULL; /* one per disk */
     void *config_data = 0;
     int config_len = 0;
     int restore_fd = -1;
@@ -1647,14 +1674,14 @@ start:
                 if (errno != EINTR) {
                     perror("failed to wait for daemonizing child");
                     ret = ERROR_FAIL;
-                    goto error_out;
+                    goto out;
                 }
             }
             if (status) {
                 libxl_report_child_exitstatus(ctx, XTL_ERROR,
                            "daemonizing child", child1, status);
                 ret = ERROR_FAIL;
-                goto error_out;
+                goto out;
             }
             ret = domid;
             goto out;
@@ -1691,92 +1718,106 @@ start:
     }
     LOG("Waiting for domain %s (domid %d) to die [pid %ld]",
         d_config.c_info.name, domid, (long)getpid());
-    w1 = (libxl_waiter*) xmalloc(sizeof(libxl_waiter) * d_config.num_disks);
-    w2 = (libxl_waiter*) xmalloc(sizeof(libxl_waiter));
-    libxl_wait_for_disk_ejects(ctx, domid, d_config.disks, d_config.num_disks, w1);
-    libxl_wait_for_domain_death(ctx, domid, w2);
-    libxl_get_wait_fd(ctx, &fd);
-    while (1) {
-        int ret;
-        fd_set rfds;
-        libxl_dominfo info;
-        libxl_event event;
-        libxl_device_disk disk;
 
-        FD_ZERO(&rfds);
-        FD_SET(fd, &rfds);
+    ret = libxl_evenable_domain_death(ctx, domid, 0, &deathw);
+    if (ret) goto out;
 
-        ret = select(fd + 1, &rfds, NULL, NULL, NULL);
-        if (!ret)
-            continue;
-        libxl_get_event(ctx, &event);
-        switch (event.type) {
-            case LIBXL_EVENT_TYPE_DOMAIN_DEATH:
-                ret = libxl_event_get_domain_death_info(ctx, domid, &event, &info);
-
-                if (ret < 0) {
-                    libxl_free_event(&event);
-                    continue;
+    if (!diskws) {
+        diskws = xmalloc(sizeof(*diskws) * d_config.num_disks);
+        for (i = 0; i < d_config.num_disks; i++)
+            diskws[i] = NULL;
+    }
+    for (i = 0; i < d_config.num_disks; i++) {
+        ret = libxl_evenable_disk_eject(ctx, domid, d_config.disks[i].vdev,
+                                        0, &diskws[i]);
+        if (ret) goto out;
+    }
+    while (1) {
+        libxl_event *event;
+        ret = domain_wait_event(&event);
+        if (ret) goto out;
+
+        switch (event->type) {
+
+        case LIBXL_EVENT_TYPE_DOMAIN_SHUTDOWN:
+            LOG("Domain %d has shut down, reason code %d 0x%x", domid,
+                event->u.domain_shutdown.shutdown_reason,
+                event->u.domain_shutdown.shutdown_reason);
+            switch (handle_domain_death(ctx, domid, event, &d_config)) {
+            case 2:
+                if (!preserve_domain(ctx, domid, event, &d_config)) {
+                    /* If we fail then exit leaving the old domain in place. */
+                    ret = -1;
+                    goto out;
                 }
 
-                LOG("Domain %d is dead", domid);
-
-                if (ret) {
-                    switch (handle_domain_death(ctx, domid, &event, &d_config, &info)) {
-                    case 2:
-                        if (!preserve_domain(ctx, domid, &event, &d_config, &info)) {
-                            /* If we fail then exit leaving the old domain in place. */
-                            ret = -1;
-                            goto out;
-                        }
-
-                        /* Otherwise fall through and restart. */
-                    case 1:
-
-                        for (i = 0; i < d_config.num_disks; i++)
-                            libxl_free_waiter(&w1[i]);
-                        libxl_free_waiter(w2);
-                        free(w1);
-                        free(w2);
-
-                        /*
-                         * Do not attempt to reconnect if we come round again due to a
-                         * guest reboot -- the stdin/out will be disconnected by then.
-                         */
-                        dom_info->console_autoconnect = 0;
-
-                        /* Some settings only make sense on first boot. */
-                        paused = 0;
-                        if (common_domname
-                            && strcmp(d_config.c_info.name, common_domname)) {
-                            d_config.c_info.name = strdup(common_domname);
-                        }
-
-                        /*
-                         * XXX FIXME: If this sleep is not there then domain
-                         * re-creation fails sometimes.
-                         */
-                        LOG("Done. Rebooting now");
-                        sleep(2);
-                        goto start;
-                    case 0:
-                        LOG("Done. Exiting now");
-                        ret = 0;
-                        goto out;
-                    }
-                } else {
-                    LOG("Unable to get domain death info, quitting");
-                    goto out;
+                /* Otherwise fall through and restart. */
+            case 1:
+                libxl_event_free(ctx, event);
+                libxl_evdisable_domain_death(ctx, deathw);
+                deathw = NULL;
+                for (i = 0; i < d_config.num_disks; i++) {
+                    libxl_evdisable_disk_eject(ctx, diskws[i]);
+                    diskws[i] = NULL;
                 }
-                break;
-            case LIBXL_EVENT_TYPE_DISK_EJECT:
-                if (libxl_event_get_disk_eject_info(ctx, domid, &event, &disk)) {
-                    libxl_cdrom_insert(ctx, domid, &disk);
-                    libxl_device_disk_dispose(&disk);
+                /* discard any other events which may have been generated */
+                while (!(ret = libxl_event_check(ctx, &event,
+                                                 LIBXL_EVENTMASK_ALL, 0,0))) {
+                    libxl_event_free(ctx, event);
                 }
-                break;
+                if (ret != ERROR_NOT_READY) {
+                    LOG("warning, libxl_event_check (cleanup) failed (rc=%d)",
+                        ret);
+                }
+
+                /*
+                 * Do not attempt to reconnect if we come round again due to a
+                 * guest reboot -- the stdin/out will be disconnected by then.
+                 */
+                dom_info->console_autoconnect = 0;
+
+                /* Some settings only make sense on first boot. */
+                paused = 0;
+                if (common_domname
+                    && strcmp(d_config.c_info.name, common_domname)) {
+                    d_config.c_info.name = strdup(common_domname);
+                }
+
+                /*
+                 * XXX FIXME: If this sleep is not there then domain
+                 * re-creation fails sometimes.
+                 */
+                LOG("Done. Rebooting now");
+                sleep(2);
+                goto start;
+
+            case 0:
+                LOG("Done. Exiting now");
+                ret = 0;
+                goto out;
+
+            default:
+                abort();
+            }
+
+        case LIBXL_EVENT_TYPE_DOMAIN_DESTROY:
+            LOG("Domain %d has been destroyed.", domid);
+            ret = 0;
+            goto out;
+
+        case LIBXL_EVENT_TYPE_DISK_EJECT:
+            /* XXX what is this for? */
+            libxl_cdrom_insert(ctx, domid, &event->u.disk_eject.disk);
+            break;
+
+        default:;
+            char *evstr = libxl_event_to_json(ctx, event);
+            LOG("warning, got unexpected event type %d, event=%s",
+                event->type, evstr);
+            free(evstr);
         }
-        libxl_free_event(&event);
+
+        libxl_event_free(ctx, event);
     }
 
 error_out:
@@ -2259,43 +2300,46 @@ static void destroy_domain(const char *p)
 static void shutdown_domain(const char *p, int wait)
 {
     int rc;
+    libxl_event *event;
 
     find_domain(p);
     rc=libxl_domain_shutdown(ctx, domid, 0);
     if (rc) { fprintf(stderr,"shutdown failed (rc=%d)\n",rc);exit(-1); }
 
     if (wait) {
-        libxl_waiter waiter;
-        int fd;
-
-        libxl_wait_for_domain_death(ctx, domid, &waiter);
+        libxl_evgen_domain_death *deathw;
 
-        libxl_get_wait_fd(ctx, &fd);
-
-        while (wait) {
-            fd_set rfds;
-            libxl_event event;
-            libxl_dominfo info;
+        rc = libxl_evenable_domain_death(ctx, domid, 0, &deathw);
+        if (rc) {
+            fprintf(stderr,"wait for death failed (evgen, rc=%d)\n",rc);
+            exit(-1);
+        }
 
-            FD_ZERO(&rfds);
-            FD_SET(fd, &rfds);
+        for (;;) {
+            rc = domain_wait_event(&event);
+            if (rc) exit(-1);
 
-            if (!select(fd + 1, &rfds, NULL, NULL, NULL))
-                continue;
+            switch (event->type) {
 
-            libxl_get_event(ctx, &event);
+            case LIBXL_EVENT_TYPE_DOMAIN_DESTROY:
+                LOG("Domain %d has been destroyed", domid);
+                goto done;
 
-            if (event.type == LIBXL_EVENT_TYPE_DOMAIN_DEATH) {
-                if (libxl_event_get_domain_death_info(ctx, domid, &event, &info) < 0)
-                    continue;
+            case LIBXL_EVENT_TYPE_DOMAIN_SHUTDOWN:
+                LOG("Domain %d has been shut down, reason code %d %x", domid,
+                    event->u.domain_shutdown.shutdown_reason,
+                    event->u.domain_shutdown.shutdown_reason);
+                goto done;
 
-                LOG("Domain %d is dead", domid);
-                wait = 0;
+            default:
+                LOG("Unexpected event type %d", event->type);
+                break;
             }
-
-            libxl_free_event(&event);
+            libxl_event_free(ctx, event);
         }
-        libxl_free_waiter(&waiter);
+    done:
+        libxl_event_free(ctx, event);
+        libxl_evdisable_domain_death(ctx, deathw);
     }
 }
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 18:55:51 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 18: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.xensource.com>)
	id 1RZ5bd-0001DT-Hb; Fri, 09 Dec 2011 18:55:37 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RZ5bb-0001Ar-KF
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 18:55:35 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1323456879!6616386!8
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI2MQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21344 invoked from network); 9 Dec 2011 18:54:45 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 18:54:45 -0000
X-IronPort-AV: E=Sophos;i="4.71,327,1320624000"; 
   d="scan'208";a="9392199"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 18:54:45 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 18:54:45 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RZ5an-0002e3-BN; Fri, 09 Dec 2011 18:54:45 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RZ5an-00040N-Aa;
	Fri, 09 Dec 2011 18:54:45 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Fri, 9 Dec 2011 18:54:26 +0000
Message-ID: <1323456877-15315-8-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1323456877-15315-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1323456877-15315-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 07/18] libxl: internal convenience macros
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Provide some macros which are useful shorthands for use within libxl:
  * GC_INIT to initialise a gc from a ctx and GC_FREE to free it
  * CTX(gc) to give you back the ctx
  * LIBXL_TAILQ_INSERT_SORTED for inserting things into sorted lists

These will be used by later patches.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl_internal.h |   48 ++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 48 insertions(+), 0 deletions(-)

diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index bfc74c9..950c466 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -646,6 +646,54 @@ _hidden libxl__json_object *libxl__json_parse(libxl__gc *gc, const char *s);
 _hidden libxl_device_model_version
 libxl__device_model_version_running(libxl__gc *gc, uint32_t domid);
 
+
+/*
+ * Convenience macros.
+ */
+
+
+/*
+ * All of these assume (or define)
+ *    libxl__gc *gc;
+ * as a local variable.
+ */
+
+#define GC_INIT(ctx)  libxl__gc gc[1] = { LIBXL_INIT_GC(ctx) }
+#define GC_FREE       libxl__free_all(gc)
+#define CTX           libxl__gc_owner(gc)
+
+
+/*
+ * Inserts "elm_new" into the sorted list "head".
+ *
+ * "elm_search" must be a loop search variable of the same type as
+ * "elm_new".  "new_after_search_p" must be an expression which is
+ * true iff the element "elm_new" sorts after the element
+ * "elm_search".
+ *
+ * "search_body" can be empty, or some declaration(s) and statement(s)
+ * needed for "new_after_search_p".
+ */
+#define LIBXL_TAILQ_INSERT_SORTED(head, entry, elm_new, elm_search,     \
+                                  search_body, new_after_search_p)      \
+    do {                                                                \
+        for ((elm_search) = LIBXL_TAILQ_FIRST((head));                  \
+             (elm_search);                                              \
+             (elm_search) = LIBXL_TAILQ_NEXT((elm_search), entry)) {    \
+            search_body;                                                \
+            if (!(new_after_search_p))                                  \
+                break;                                                  \
+        }                                                               \
+        /* now elm_search is either the element before which we want    \
+         * to place elm_new, or NULL meaning we want to put elm_new at  \
+         * the end */                                                   \
+        if ((elm_search))                                               \
+            LIBXL_TAILQ_INSERT_BEFORE((elm_search), (elm_new), entry);  \
+        else                                                            \
+            LIBXL_TAILQ_INSERT_TAIL((head), (elm_new), entry);          \
+    } while(0)
+
+
 #endif
 
 /*
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 18:55:51 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 18: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.xensource.com>)
	id 1RZ5be-0001Dm-1S; Fri, 09 Dec 2011 18:55:38 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RZ5bc-0001Au-49
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 18:55:36 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1323456879!6616386!9
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI2MQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21357 invoked from network); 9 Dec 2011 18:54:46 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 18:54:46 -0000
X-IronPort-AV: E=Sophos;i="4.71,327,1320624000"; 
   d="scan'208";a="9392200"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 18:54:46 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 18:54:46 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RZ5an-0002e6-RN; Fri, 09 Dec 2011 18:54:45 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RZ5an-00040R-Qb;
	Fri, 09 Dec 2011 18:54:45 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Fri, 9 Dec 2011 18:54:27 +0000
Message-ID: <1323456877-15315-9-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1323456877-15315-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1323456877-15315-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 08/18] libxl: Rationalise #includes
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

libxl_internal.h now #includes libxl.h and various system headers.

This
 1. makes the order of header inclusion more predictable
 2. explicitly allows libxl_internal.h to use objects defined in libxl.h
 3. removes the need for individual files to include these headers

Also
 - remove some unnecessary #includes of libxl_utils.h,
   flexarray.h, etc. in some libxl*.c files,
 - include libxl_osdeps.h at the top of libxl_internal.h
 - add missing includes of libxl_osdeps.h to a couple of files
 - change libxl.h to libxl_internal.h in a couple of files

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl.c            |    3 ---
 tools/libxl/libxl_blktap2.c    |    1 -
 tools/libxl/libxl_bootloader.c |    4 ----
 tools/libxl/libxl_cpuid.c      |    4 ----
 tools/libxl/libxl_create.c     |    4 +---
 tools/libxl/libxl_device.c     |    1 -
 tools/libxl/libxl_dm.c         |    4 +---
 tools/libxl/libxl_dom.c        |    1 -
 tools/libxl/libxl_exec.c       |    1 -
 tools/libxl/libxl_flask.c      |    3 ++-
 tools/libxl/libxl_internal.c   |    4 ----
 tools/libxl/libxl_internal.h   |    5 +++++
 tools/libxl/libxl_json.c       |    3 ++-
 tools/libxl/libxl_noblktap2.c  |    2 --
 tools/libxl/libxl_nocpuid.c    |    2 +-
 tools/libxl/libxl_paths.c      |    2 +-
 tools/libxl/libxl_pci.c        |    5 -----
 tools/libxl/libxl_qmp.c        |    2 ++
 tools/libxl/libxl_utils.c      |    1 -
 tools/libxl/libxl_uuid.c       |    4 ++++
 tools/libxl/libxl_xshelp.c     |    1 -
 21 files changed, 19 insertions(+), 38 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index a171142..bc17b15 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -31,10 +31,7 @@
 #include <inttypes.h>
 #include <assert.h>
 
-#include "libxl.h"
-#include "libxl_utils.h"
 #include "libxl_internal.h"
-#include "flexarray.h"
 
 #define PAGE_TO_MEMKB(pages) ((pages) * 4)
 #define BACKEND_STRING_SIZE 5
diff --git a/tools/libxl/libxl_blktap2.c b/tools/libxl/libxl_blktap2.c
index c8d9148..acf4110 100644
--- a/tools/libxl/libxl_blktap2.c
+++ b/tools/libxl/libxl_blktap2.c
@@ -12,7 +12,6 @@
  * GNU Lesser General Public License for more details.
  */
 
-#include "libxl.h"
 #include "libxl_osdeps.h"
 #include "libxl_internal.h"
 
diff --git a/tools/libxl/libxl_bootloader.c b/tools/libxl/libxl_bootloader.c
index 47bb3a1..b8399a1 100644
--- a/tools/libxl/libxl_bootloader.c
+++ b/tools/libxl/libxl_bootloader.c
@@ -14,7 +14,6 @@
 
 #include "libxl_osdeps.h"
 
-#include <string.h>
 #include <unistd.h>
 #include <fcntl.h>
 #include <termios.h>
@@ -22,11 +21,8 @@
 #include <sys/stat.h>
 #include <sys/types.h>
 
-#include "libxl.h"
 #include "libxl_internal.h"
 
-#include "flexarray.h"
-
 #define XENCONSOLED_BUF_SIZE 16
 #define BOOTLOADER_BUF_SIZE 4096
 #define BOOTLOADER_TIMEOUT 1
diff --git a/tools/libxl/libxl_cpuid.c b/tools/libxl/libxl_cpuid.c
index 78bcab5..56a00cd 100644
--- a/tools/libxl/libxl_cpuid.c
+++ b/tools/libxl/libxl_cpuid.c
@@ -10,10 +10,6 @@
  * GNU Lesser General Public License for more details.
  */
 
-#include <string.h>
-
-#include "libxl.h"
-#include "libxl_osdeps.h"
 #include "libxl_internal.h"
 
 void libxl_cpuid_dispose(libxl_cpuid_policy_list *p_cpuid_list)
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index ce6a55e..ccb56c7 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -26,10 +26,8 @@
 #include <xc_dom.h>
 #include <xenguest.h>
 #include <assert.h>
-#include "libxl.h"
-#include "libxl_utils.h"
+
 #include "libxl_internal.h"
-#include "flexarray.h"
 
 void libxl_domain_config_dispose(libxl_domain_config *d_config)
 {
diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c
index a53fb70..46254ea 100644
--- a/tools/libxl/libxl_device.c
+++ b/tools/libxl/libxl_device.c
@@ -24,7 +24,6 @@
 #include <unistd.h>
 #include <fcntl.h>
 
-#include "libxl.h"
 #include "libxl_internal.h"
 
 char *libxl__device_frontend_path(libxl__gc *gc, libxl__device *device)
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index cef80be..05c83cd 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -24,10 +24,8 @@
 #include <unistd.h>
 #include <fcntl.h>
 #include <assert.h>
-#include "libxl_utils.h"
+
 #include "libxl_internal.h"
-#include "libxl.h"
-#include "flexarray.h"
 
 static const char *libxl_tapif_script(libxl__gc *gc)
 {
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index b74db34..96098de 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -32,7 +32,6 @@
 
 #include <xen/hvm/hvm_info_table.h>
 
-#include "libxl.h"
 #include "libxl_internal.h"
 
 libxl_domain_type libxl__domain_type(libxl__gc *gc, uint32_t domid)
diff --git a/tools/libxl/libxl_exec.c b/tools/libxl/libxl_exec.c
index 1a62d47..52d40d1 100644
--- a/tools/libxl/libxl_exec.c
+++ b/tools/libxl/libxl_exec.c
@@ -28,7 +28,6 @@
 #include <signal.h> /* for SIGKILL */
 #include <fcntl.h>
 
-#include "libxl.h"
 #include "libxl_internal.h"
 
 static int call_waitpid(pid_t (*waitpid_cb)(pid_t, int *, int), pid_t pid, int *status, int options)
diff --git a/tools/libxl/libxl_flask.c b/tools/libxl/libxl_flask.c
index c8d0594..6b548dd 100644
--- a/tools/libxl/libxl_flask.c
+++ b/tools/libxl/libxl_flask.c
@@ -7,13 +7,14 @@
  *  as published by the Free Software Foundation.
  */
 
+#include "libxl_osdeps.h"
+
 #include <stdio.h>
 #include <stdlib.h>
 #include <string.h>
 #include <errno.h>
 #include <xenctrl.h>
 
-#include "libxl.h"
 #include "libxl_internal.h"
 
 int libxl_flask_context_to_sid(libxl_ctx *ctx, char *buf, size_t len,
diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c
index 34edaf3..d767ce3 100644
--- a/tools/libxl/libxl_internal.c
+++ b/tools/libxl/libxl_internal.c
@@ -16,8 +16,6 @@
 #include "libxl_osdeps.h"
 
 #include <stdio.h>
-#include <stdarg.h>
-#include <string.h>
 
 #include <sys/types.h>
 #include <sys/stat.h>
@@ -25,9 +23,7 @@
 #include <sys/mman.h>
 #include <unistd.h>
 
-#include "libxl.h"
 #include "libxl_internal.h"
-#include "libxl_utils.h"
 
 int libxl__error_set(libxl__gc *gc, int code)
 {
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 950c466..cda6fc1 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -17,14 +17,19 @@
 #ifndef LIBXL_INTERNAL_H
 #define LIBXL_INTERNAL_H
 
+#include "libxl_osdeps.h"
+
 #include <stdint.h>
 #include <stdarg.h>
 #include <stdlib.h>
+#include <string.h>
 
 #include <xs.h>
 #include <xenctrl.h>
 #include "xentoollog.h"
 
+#include "libxl.h"
+
 #if __GNUC__ > 3 || (__GNUC__ == 3 && __GNUC_MINOR__ >= 1)
 #define _hidden __attribute__((visibility("hidden")))
 #define _protected __attribute__((visibility("protected")))
diff --git a/tools/libxl/libxl_json.c b/tools/libxl/libxl_json.c
index fd5e2aa..c0f869e 100644
--- a/tools/libxl/libxl_json.c
+++ b/tools/libxl/libxl_json.c
@@ -12,6 +12,8 @@
  * GNU Lesser General Public License for more details.
  */
 
+#include "libxl_osdeps.h"
+
 #include <assert.h>
 #include <string.h>
 #include <math.h>
@@ -19,7 +21,6 @@
 #include <yajl/yajl_parse.h>
 #include <yajl/yajl_gen.h>
 
-#include <libxl.h>
 #include "libxl_internal.h"
 
 /* #define DEBUG_ANSWER */
diff --git a/tools/libxl/libxl_noblktap2.c b/tools/libxl/libxl_noblktap2.c
index 704d03f..3307551 100644
--- a/tools/libxl/libxl_noblktap2.c
+++ b/tools/libxl/libxl_noblktap2.c
@@ -12,8 +12,6 @@
  * GNU Lesser General Public License for more details.
  */
 
-#include "libxl.h"
-#include "libxl_osdeps.h"
 #include "libxl_internal.h"
 
 int libxl__blktap_enabled(libxl__gc *gc)
diff --git a/tools/libxl/libxl_nocpuid.c b/tools/libxl/libxl_nocpuid.c
index d63757f..2e9490c 100644
--- a/tools/libxl/libxl_nocpuid.c
+++ b/tools/libxl/libxl_nocpuid.c
@@ -10,7 +10,7 @@
  * GNU Lesser General Public License for more details.
  */
 
-#include "libxl.h"
+#include "libxl_internal.h"
 
 void libxl_cpuid_destroy(libxl_cpuid_policy_list *p_cpuid_list)
 {
diff --git a/tools/libxl/libxl_paths.c b/tools/libxl/libxl_paths.c
index c84e51d..e7bd1a2 100644
--- a/tools/libxl/libxl_paths.c
+++ b/tools/libxl/libxl_paths.c
@@ -12,7 +12,7 @@
  * GNU Lesser General Public License for more details.
  */
 
-#include "libxl.h"
+#include "libxl_internal.h"
 #include "_libxl_paths.h"
 
 const char *libxl_sbindir_path(void)
diff --git a/tools/libxl/libxl_pci.c b/tools/libxl/libxl_pci.c
index 4186cf8..63c3050 100644
--- a/tools/libxl/libxl_pci.c
+++ b/tools/libxl/libxl_pci.c
@@ -17,7 +17,6 @@
 #include "libxl_osdeps.h"
 
 #include <stdio.h>
-#include <string.h>
 #include <stdlib.h>
 #include <sys/types.h>
 #include <fcntl.h>
@@ -27,15 +26,11 @@
 #include <sys/stat.h>
 #include <signal.h>
 #include <unistd.h> /* for write, unlink and close */
-#include <stdint.h>
 #include <inttypes.h>
 #include <dirent.h>
 #include <assert.h>
 
-#include "libxl.h"
-#include "libxl_utils.h"
 #include "libxl_internal.h"
-#include "flexarray.h"
 
 #define PCI_BDF                "%04x:%02x:%02x.%01x"
 #define PCI_BDF_SHORT          "%02x:%02x.%01x"
diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
index f749e01..c7696d7 100644
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/libxl/libxl_qmp.c
@@ -18,6 +18,8 @@
  * Specification, see in the QEMU repository.
  */
 
+#include "libxl_osdeps.h"
+
 #include <unistd.h>
 #include <sys/un.h>
 #include <sys/queue.h>
diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
index 1fa2c0f..f1f2a6d 100644
--- a/tools/libxl/libxl_utils.c
+++ b/tools/libxl/libxl_utils.c
@@ -28,7 +28,6 @@
 #include <unistd.h>
 #include <assert.h>
 
-#include "libxl_utils.h"
 #include "libxl_internal.h"
 
 struct schedid_name {
diff --git a/tools/libxl/libxl_uuid.c b/tools/libxl/libxl_uuid.c
index e837228..80ab789 100644
--- a/tools/libxl/libxl_uuid.c
+++ b/tools/libxl/libxl_uuid.c
@@ -12,8 +12,12 @@
  * GNU Lesser General Public License for more details.
  */
 
+#include "libxl_osdeps.h"
+
 #include <libxl_uuid.h>
 
+#include "libxl_internal.h"
+
 #if defined(__linux__)
 
 int libxl_uuid_is_nil(libxl_uuid *uuid)
diff --git a/tools/libxl/libxl_xshelp.c b/tools/libxl/libxl_xshelp.c
index bc4e7e4..ea835e2 100644
--- a/tools/libxl/libxl_xshelp.c
+++ b/tools/libxl/libxl_xshelp.c
@@ -21,7 +21,6 @@
 #include <stdarg.h>
 #include <inttypes.h>
 
-#include "libxl.h"
 #include "libxl_internal.h"
 
 char **libxl__xs_kvs_of_flexarray(libxl__gc *gc, flexarray_t *array, int length)
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 18:55:51 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 18: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.xensource.com>)
	id 1RZ5bj-0001Kx-MY; Fri, 09 Dec 2011 18:55:43 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RZ5bg-0001C4-Tp
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 18:55:41 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1323456890!5661081!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI2MQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15637 invoked from network); 9 Dec 2011 18:54:51 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 18:54:51 -0000
X-IronPort-AV: E=Sophos;i="4.71,327,1320624000"; 
   d="scan'208";a="9392210"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 18:54:50 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 18:54:50 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RZ5as-0002ec-FV; Fri, 09 Dec 2011 18:54:50 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RZ5as-000415-ES;
	Fri, 09 Dec 2011 18:54:50 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Fri, 9 Dec 2011 18:54:37 +0000
Message-ID: <1323456877-15315-19-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1323456877-15315-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1323456877-15315-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 18/18] libxl: New event generation API
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Replace the existing API for retrieving high-level events (events
about domains, etc.) from libxl with a new one.

This changes the definition and semantics of the `libxl_event'
structure, and replaces the calls for obtaining information about
domain death and disk eject events.

This is an incompatible change, sorry.  The alternative was to try to
provide both the previous horrid API and the new one, and would also
involve never using the name `libxl_event' for the new interface.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl.c          |  329 +++++++++++++++++++++++++++++++-----------
 tools/libxl/libxl.h          |   55 ++------
 tools/libxl/libxl_event.c    |  200 +++++++++++++++++++++++---
 tools/libxl/libxl_event.h    |  182 +++++++++++++++++++++++-
 tools/libxl/libxl_internal.c |    6 +
 tools/libxl/libxl_internal.h |   87 +++++++++++-
 tools/libxl/libxl_types.idl  |   35 ++++-
 tools/libxl/xl_cmdimpl.c     |  270 ++++++++++++++++++++---------------
 8 files changed, 885 insertions(+), 279 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 23a7539..e94cbf1 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -60,8 +60,11 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
      * only as an initialiser, not as an expression. */
     memcpy(&ctx->lock, &mutex_value, sizeof(ctx->lock));
 
+    LIBXL_TAILQ_INIT(&ctx->occurred);
+
     ctx->osevent_hooks = 0;
 
+    ctx->fd_polls = 0;
     ctx->fd_beforepolled = 0;
     LIBXL_LIST_INIT(&ctx->efds);
     LIBXL_TAILQ_INIT(&ctx->etimes);
@@ -70,6 +73,9 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
     LIBXL_SLIST_INIT(&ctx->watch_freeslots);
     libxl__ev_fd_init(&ctx->watch_efd);
 
+    LIBXL_TAILQ_INIT(&ctx->death_list);
+    libxl__ev_xswatch_init(&ctx->death_watch);
+
     if ( stat(XENSTORE_PID_FILE, &stat_buf) != 0 ) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "Is xenstore daemon running?\n"
                      "failed to stat %s", XENSTORE_PID_FILE);
@@ -97,6 +103,20 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
     return 0;
 }
 
+static void free_disable_deaths(libxl__gc *gc,
+                                struct libxl__evgen_domain_death_list *l) {
+    libxl_evgen_domain_death *death;
+    while ((death = LIBXL_TAILQ_FIRST(l)))
+        libxl__evdisable_domain_death(gc, death);
+}
+
+static void discard_events(struct libxl__event_list *l) {
+    /* doesn't bother unlinking from the list, so l is corrupt on return */
+    libxl_event *ev;
+    LIBXL_TAILQ_FOREACH(ev, l, link)
+        libxl_event_free(0, ev);
+}
+
 int libxl_ctx_free(libxl_ctx *ctx)
 {
     if (!ctx) return 0;
@@ -106,6 +126,13 @@ int libxl_ctx_free(libxl_ctx *ctx)
 
     /* Deregister all libxl__ev_KINDs: */
 
+    free_disable_deaths(gc, &CTX->death_list);
+    free_disable_deaths(gc, &CTX->death_reported);
+
+    libxl_evgen_disk_eject *eject;
+    while ((eject = LIBXL_LIST_FIRST(&CTX->disk_eject_evgens)))
+        libxl__evdisable_disk_eject(gc, eject);
+
     for (i = 0; i < ctx->watch_nslots; i++)
         assert(!libxl__watch_slot_contents(gc, i));
     libxl__ev_fd_deregister(gc, &ctx->watch_efd);
@@ -119,9 +146,16 @@ int libxl_ctx_free(libxl_ctx *ctx)
     libxl_version_info_dispose(&ctx->version_info);
     if (ctx->xsh) xs_daemon_close(ctx->xsh);
 
+    free(ctx->fd_polls);
     free(ctx->fd_beforepolled);
     free(ctx->watch_slots);
 
+    discard_events(&ctx->occurred);
+    discard_events(&gc->occurred_for_callback);
+      /* There shouldn't be any of the latter - they would have had to
+       * have been generated during libxl_ctx_free - but throwing them
+       * away is more friendly than asserting. */
+
     GC_FREE;
     free(ctx);
     return 0;
@@ -620,117 +654,173 @@ int libxl_domain_shutdown(libxl_ctx *ctx, uint32_t domid, int req)
     return 0;
 }
 
-int libxl_get_wait_fd(libxl_ctx *ctx, int *fd)
-{
-    *fd = xs_fileno(ctx->xsh);
-    return 0;
-}
+static void domain_death_xswatch_callback(libxl__gc *gc, libxl__ev_xswatch *w,
+                                        const char *wpath, const char *epath) {
+    libxl_evgen_domain_death *evg;
+    uint32_t domid;
+    int rc;
 
-int libxl_wait_for_domain_death(libxl_ctx *ctx, uint32_t domid, libxl_waiter *waiter)
-{
-    waiter->path = strdup("@releaseDomain");
-    if (asprintf(&(waiter->token), "%d", LIBXL_EVENT_TYPE_DOMAIN_DEATH) < 0)
-        return -1;
-    if (!xs_watch(ctx->xsh, waiter->path, waiter->token))
-        return -1;
-    return 0;
-}
+    CTX_LOCK;
 
-int libxl_wait_for_disk_ejects(libxl_ctx *ctx, uint32_t guest_domid, libxl_device_disk *disks, int num_disks, libxl_waiter *waiter)
-{
-    GC_INIT(ctx);
-    int i, rc = -1;
-    uint32_t domid = libxl_get_stubdom_id(ctx, guest_domid);
+    evg = LIBXL_TAILQ_FIRST(&CTX->death_list);
+    if (!evg) goto out;
 
-    if (!domid)
-        domid = guest_domid;
+    domid = evg->domid;
 
-    for (i = 0; i < num_disks; i++) {
-        if (asprintf(&(waiter[i].path), "%s/device/vbd/%d/eject",
-                     libxl__xs_get_dompath(gc, domid),
-                     libxl__device_disk_dev_number(disks[i].vdev,
-                                                   NULL, NULL)) < 0)
-            goto out;
-        if (asprintf(&(waiter[i].token), "%d", LIBXL_EVENT_TYPE_DISK_EJECT) < 0)
+    for (;;) {
+        int nentries = LIBXL_TAILQ_NEXT(evg, entry) ? 200 : 1;
+        xc_domaininfo_t domaininfos[nentries];
+        const xc_domaininfo_t *got = domaininfos, *gotend;
+
+        rc = xc_domain_getinfolist(CTX->xch, domid, nentries, domaininfos);
+        if (rc == -1) {
+            LIBXL__EVENT_DISASTER(gc, "xc_domain_getinfolist failed while"
+                                  " processing @releaseDomain watch event",
+                                  errno, 0);
             goto out;
-        xs_watch(ctx->xsh, waiter[i].path, waiter[i].token);
+        }
+        gotend = &domaininfos[rc];
+
+        for (;;) {
+            if (!evg)
+                goto all_reported;
+
+            if (!rc || got->domain > evg->domid) {
+                /* ie, the list doesn't contain evg->domid any more so
+                 * the domain has been destroyed */
+                libxl_evgen_domain_death *evg_next;
+
+                libxl_event *ev = NEW_EVENT(gc, DOMAIN_DESTROY, evg->domid);
+                if (!ev) goto out;
+
+                libxl__event_occurred(gc, ev);
+
+                evg->death_reported = 1;
+                evg_next = LIBXL_TAILQ_NEXT(evg, entry);
+                LIBXL_TAILQ_REMOVE(&CTX->death_list, evg, entry);
+                LIBXL_TAILQ_INSERT_HEAD(&CTX->death_reported, evg, entry);
+                evg = evg_next;
+
+                continue;
+            }
+            
+            if (got == gotend)
+                break;
+
+            if (got->domain < evg->domid) {
+                got++;
+                continue;
+            }
+
+            assert(evg->domid == got->domain);
+
+            if (!evg->shutdown_reported &&
+                (got->flags & XEN_DOMINF_shutdown)) {
+                libxl_event *ev = NEW_EVENT(gc, DOMAIN_SHUTDOWN, got->domain);
+                if (!ev) goto out;
+                
+                ev->u.domain_shutdown.shutdown_reason =
+                    (got->flags >> XEN_DOMINF_shutdownshift) &
+                    XEN_DOMINF_shutdownmask;
+                libxl__event_occurred(gc, ev);
+
+                evg->shutdown_reported = 1;
+            }
+            evg = LIBXL_TAILQ_NEXT(evg, entry);
+        }
+
+        assert(rc); /* rc==0 results in us eating all evgs and quitting */
+        domid = gotend[-1].domain;
     }
-    rc = 0;
-out:
-    GC_FREE;
-    return rc;
+ all_reported:
+ out:
+
+    CTX_UNLOCK;
 }
 
-int libxl_get_event(libxl_ctx *ctx, libxl_event *event)
-{
-    unsigned int num;
-    char **events = xs_read_watch(ctx->xsh, &num);
-    if (num != 2) {
-        free(events);
-        return ERROR_FAIL;
+int libxl_evenable_domain_death(libxl_ctx *ctx, uint32_t domid,
+                libxl_ev_user user, libxl_evgen_domain_death **evgen_out) {
+    GC_INIT(ctx);
+    libxl_evgen_domain_death *evg, *evg_search;
+    int rc;
+    
+    CTX_LOCK;
+
+    evg = malloc(sizeof(*evg));  if (!evg) { rc = ERROR_NOMEM; goto out; }
+    memset(evg, 0, sizeof(*evg));
+    evg->domid = domid;
+    evg->user = user;
+
+    LIBXL_TAILQ_INSERT_SORTED(&ctx->death_list, entry, evg, evg_search, ,
+                              evg->domid > evg_search->domid);
+
+    if (!libxl__ev_xswatch_isregistered(&ctx->death_watch)) {
+        rc = libxl__ev_xswatch_register(gc, &ctx->death_watch,
+                        domain_death_xswatch_callback, "@releaseDomain");
+        if (rc) { libxl__evdisable_domain_death(gc, evg); goto out; }
     }
-    event->path = strdup(events[XS_WATCH_PATH]);
-    event->token = strdup(events[XS_WATCH_TOKEN]);
-    event->type = atoi(event->token);
-    free(events);
-    return 0;
-}
 
-int libxl_stop_waiting(libxl_ctx *ctx, libxl_waiter *waiter)
-{
-    if (!xs_unwatch(ctx->xsh, waiter->path, waiter->token))
-        return ERROR_FAIL;
-    else
-        return 0;
-}
+    rc = 0;
 
-int libxl_free_event(libxl_event *event)
-{
-    free(event->path);
-    free(event->token);
-    return 0;
-}
+ out:
+    CTX_UNLOCK;
+    return rc;
+};
 
-int libxl_free_waiter(libxl_waiter *waiter)
-{
-    free(waiter->path);
-    free(waiter->token);
-    return 0;
-}
+void libxl__evdisable_domain_death(libxl__gc *gc,
+                                   libxl_evgen_domain_death *evg) {
+    CTX_LOCK;
 
-int libxl_event_get_domain_death_info(libxl_ctx *ctx, uint32_t domid, libxl_event *event, libxl_dominfo *info)
-{
-    if (libxl_domain_info(ctx, info, domid) < 0)
-        return 0;
+    if (!evg->death_reported)
+        LIBXL_TAILQ_REMOVE(&CTX->death_list, evg, entry);
+    else
+        LIBXL_TAILQ_REMOVE(&CTX->death_reported, evg, entry);
 
-    if (info->running || (!info->shutdown && !info->dying))
-        return ERROR_INVAL;
+    free(evg);
 
-    return 1;
+    if (!LIBXL_TAILQ_FIRST(&CTX->death_list) &&
+        libxl__ev_xswatch_isregistered(&CTX->death_watch))
+        libxl__ev_xswatch_deregister(gc, &CTX->death_watch);
+
+    CTX_UNLOCK;
 }
 
-int libxl_event_get_disk_eject_info(libxl_ctx *ctx, uint32_t domid, libxl_event *event, libxl_device_disk *disk)
-{
+void libxl_evdisable_domain_death(libxl_ctx *ctx,
+                                  libxl_evgen_domain_death *evg) {
     GC_INIT(ctx);
-    char *path;
+    libxl__evdisable_domain_death(gc, evg);
+    GC_FREE;
+}
+
+static void disk_eject_xswatch_callback(libxl__gc *gc, libxl__ev_xswatch *watch,
+                                        const char *wpath, const char *epath) {
+    libxl_evgen_disk_eject *evg = (void*)watch;
     char *backend;
     char *value;
     char backend_type[BACKEND_STRING_SIZE+1];
 
-    value = libxl__xs_read(gc, XBT_NULL, event->path);
+    value = libxl__xs_read(gc, XBT_NULL, wpath);
 
-    if (!value || strcmp(value,  "eject")) {
-        GC_FREE;
-        return 0;
+    if (!value || strcmp(value,  "eject"))
+        return;
+
+    if (libxl__xs_write(gc, XBT_NULL, wpath, "")) {
+        LIBXL__EVENT_DISASTER(gc, "xs_write failed acknowledging eject",
+                              errno, LIBXL_EVENT_TYPE_DISK_EJECT);
+        return;
     }
 
-    path = strdup(event->path);
-    path[strlen(path) - 6] = '\0';
-    backend = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/backend", path));
+    libxl_event *ev = NEW_EVENT(gc, DISK_EJECT, evg->domid);
+    libxl_device_disk *disk = &ev->u.disk_eject.disk;
+    
+    backend = libxl__xs_read(gc, XBT_NULL,
+                             libxl__sprintf(gc, "%.*s/backend",
+                                            (int)strlen(wpath)-6, wpath));
 
     sscanf(backend,
-            "/local/domain/%d/backend/%" TOSTRING(BACKEND_STRING_SIZE) "[a-z]/%*d/%*d",
-            &disk->backend_domid, backend_type);
+            "/local/domain/%d/backend/%" TOSTRING(BACKEND_STRING_SIZE)
+           "[a-z]/%*d/%*d",
+           &disk->backend_domid, backend_type);
     if (!strcmp(backend_type, "tap") || !strcmp(backend_type, "vbd")) {
         disk->backend = LIBXL_DISK_BACKEND_TAP;
     } else if (!strcmp(backend_type, "qdisk")) {
@@ -739,19 +829,82 @@ int libxl_event_get_disk_eject_info(libxl_ctx *ctx, uint32_t domid, libxl_event
         disk->backend = LIBXL_DISK_BACKEND_UNKNOWN;
     }
 
-    disk->pdev_path = strdup("");
+    disk->pdev_path = strdup(""); /* xxx fixme malloc failure */
     disk->format = LIBXL_DISK_FORMAT_EMPTY;
     /* this value is returned to the user: do not free right away */
-    disk->vdev = xs_read(ctx->xsh, XBT_NULL, libxl__sprintf(gc, "%s/dev", backend), NULL);
+    disk->vdev = xs_read(CTX->xsh, XBT_NULL,
+                         libxl__sprintf(gc, "%s/dev", backend), NULL);
     disk->removable = 1;
     disk->readwrite = 0;
     disk->is_cdrom = 1;
 
-    free(path);
+    libxl__event_occurred(gc, ev);
+}
+
+int libxl_evenable_disk_eject(libxl_ctx *ctx, uint32_t guest_domid,
+                              const char *vdev, libxl_ev_user user,
+                              libxl_evgen_disk_eject **evgen_out) {
+    GC_INIT(ctx);
+    CTX_LOCK;
+    int rc;
+    char *path;
+    libxl_evgen_disk_eject *evg = NULL;
+
+    evg = malloc(sizeof(*evg));  if (!evg) { rc = ERROR_NOMEM; goto out; }
+    memset(evg, 0, sizeof(*evg));
+    evg->user = user;
+    evg->domid = guest_domid;
+    LIBXL_LIST_INSERT_HEAD(&CTX->disk_eject_evgens, evg, entry);
+
+    evg->vdev = strdup(vdev);
+    if (!evg->vdev) { rc = ERROR_NOMEM; goto out; }
+
+    uint32_t domid = libxl_get_stubdom_id(ctx, guest_domid);
+
+    if (!domid)
+        domid = guest_domid;
+
+    path = libxl__sprintf(gc, "%s/device/vbd/%d/eject",
+                 libxl__xs_get_dompath(gc, domid),
+                 libxl__device_disk_dev_number(vdev, NULL, NULL));
+    if (!path) { rc = ERROR_NOMEM; goto out; }
+
+    rc = libxl__ev_xswatch_register(gc, &evg->watch,
+                                    disk_eject_xswatch_callback, path);
+    if (rc) goto out;
+
+    CTX_UNLOCK;
     GC_FREE;
-    return 1;
+    return 0;
+
+ out:
+    if (evg)
+        libxl__evdisable_disk_eject(gc, evg);
+    CTX_UNLOCK;
+    GC_FREE;
+    return rc;
+}
+
+void libxl__evdisable_disk_eject(libxl__gc *gc, libxl_evgen_disk_eject *evg) {
+    CTX_LOCK;
+
+    LIBXL_LIST_REMOVE(evg, entry);
+
+    if (libxl__ev_xswatch_isregistered(&evg->watch))
+        libxl__ev_xswatch_deregister(gc, &evg->watch);
+
+    free(evg->vdev);
+    free(evg);
+
+    CTX_UNLOCK;
 }
 
+void libxl_evdisable_disk_eject(libxl_ctx *ctx, libxl_evgen_disk_eject *evg) {
+    GC_INIT(ctx);
+    libxl__evdisable_disk_eject(gc, evg);
+    GC_FREE;
+}    
+
 int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid, int force)
 {
     GC_INIT(ctx);
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 8d6c788..bdb7b56 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -53,7 +53,10 @@
  *    A public function may be called from within libxl; the call
  *    context initialisation macros will make sure that the internal
  *    caller's context is reused (eg, so that the same xenstore
- *    transaction is used).
+ *    transaction is used).  But in-libxl callers of libxl public
+ *    functions should note that any libxl public function may cause
+ *    recursively reentry into libxl via the application's event
+ *    callback hook.
  *
  *    Public functions have names like libxl_foobar.
  *
@@ -152,6 +155,8 @@ void libxl_key_value_list_dispose(libxl_key_value_list *kvl);
 
 typedef uint32_t libxl_hwcap[8];
 
+typedef uint64_t libxl_ev_user;
+
 typedef struct {
     uint32_t size;          /* number of bytes in map */
     uint8_t *map;
@@ -200,6 +205,9 @@ typedef struct {
     int v;
 } libxl_enum_string_table;
 
+struct libxl_event;
+typedef LIBXL_TAILQ_ENTRY(struct libxl_event) libxl_ev_link;
+
 typedef struct libxl__ctx libxl_ctx;
 
 #include "_libxl_types.h"
@@ -298,51 +306,6 @@ int libxl_run_bootloader(libxl_ctx *ctx,
 
   /* 0 means ERROR_ENOMEM, which we have logged */
 
-/* events handling */
-
-typedef struct {
-    /* event type */
-    libxl_event_type type;
-    /* data for internal use of the library */
-    char *path;
-    char *token;
-} libxl_event;
-
-typedef struct {
-    char *path;
-    char *token;
-} libxl_waiter;
-
-
-int libxl_get_wait_fd(libxl_ctx *ctx, int *fd);
-/* waiter is allocated by the caller */
-int libxl_wait_for_domain_death(libxl_ctx *ctx, uint32_t domid, libxl_waiter *waiter);
-/* waiter is a preallocated array of num_disks libxl_waiter elements */
-int libxl_wait_for_disk_ejects(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *disks, int num_disks, libxl_waiter *waiter);
-int libxl_get_event(libxl_ctx *ctx, libxl_event *event);
-int libxl_stop_waiting(libxl_ctx *ctx, libxl_waiter *waiter);
-int libxl_free_event(libxl_event *event);
-int libxl_free_waiter(libxl_waiter *waiter);
-
-/*
- * Returns:
- *  - 0 if the domain is dead but there is no cleanup to be done. e.g
- *    because someone else has already done it.
- *  - 1 if the domain is dead and there is cleanup to be done.
- *
- * Can return error if the domain exists and is still running.
- *
- * *info will contain valid domain state iff 1 is returned. In
- * particular if 1 is returned then info->shutdown_reason is
- * guaranteed to be valid since by definition the domain is
- * (shutdown||dying))
- */
-int libxl_event_get_domain_death_info(libxl_ctx *ctx, uint32_t domid, libxl_event *event, libxl_dominfo *info);
-
-/*
- * Returns true and fills *disk if the caller should eject the disk
- */
-int libxl_event_get_disk_eject_info(libxl_ctx *ctx, uint32_t domid, libxl_event *event, libxl_device_disk *disk);
 
 int libxl_domain_rename(libxl_ctx *ctx, uint32_t domid,
                         const char *old_name, const char *new_name);
diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
index dc6543f..5a93bdf 100644
--- a/tools/libxl/libxl_event.c
+++ b/tools/libxl/libxl_event.c
@@ -149,7 +149,8 @@ static void time_insert_finite(libxl__gc *gc, libxl__ev_time *ev)
 }
 
 static int time_register_finite(libxl__gc *gc, libxl__ev_time *ev,
-                                struct timeval abs) {
+                                struct timeval abs)
+{
     int rc;
     
     rc = OSEVENT_HOOK(timeout_register, &ev->for_app_reg, abs, ev);
@@ -512,9 +513,9 @@ void libxl__ev_xswatch_deregister(libxl__gc *gc, libxl__ev_xswatch *w)
  * osevent poll
  */
 
-int libxl_osevent_beforepoll(libxl_ctx *ctx, int *nfds_io,
-                             struct pollfd *fds, int *timeout_upd,
-                             struct timeval now)
+static int beforepoll_unlocked(libxl__gc *gc, int *nfds_io,
+                               struct pollfd *fds, int *timeout_upd,
+                               struct timeval now)
 {
     libxl__ev_fd *efd;
     int i;
@@ -526,9 +527,6 @@ int libxl_osevent_beforepoll(libxl_ctx *ctx, int *nfds_io,
      * the fds array corresponds to a slot in fd_beforepolled.
      */
 
-    GC_INIT(ctx);
-    CTX_LOCK;
-
     if (*nfds_io) {
         /*
          * As an optimisation, we don't touch fd_beforepolled_used
@@ -600,17 +598,26 @@ int libxl_osevent_beforepoll(libxl_ctx *ctx, int *nfds_io,
             *timeout_upd = our_timeout;
     }
 
-    CTX_UNLOCK;
-    GC_FREE;
     return rc;
 }
 
-void libxl_osevent_afterpoll(libxl_ctx *ctx, int nfds, const struct pollfd *fds,
+int libxl_osevent_beforepoll(libxl_ctx *ctx, int *nfds_io,
+                             struct pollfd *fds, int *timeout_upd,
                              struct timeval now)
 {
-    int i;
     GC_INIT(ctx);
     CTX_LOCK;
+    int rc = beforepoll_unlocked(gc, nfds_io, fds, timeout_upd, now);
+    CTX_UNLOCK;
+    GC_FREE;
+    return rc;
+}
+
+static void afterpoll_unlocked(libxl__gc *gc,
+                               int nfds, const struct pollfd *fds,
+                               struct timeval now)
+{
+    int i;
 
     assert(nfds <= CTX->fd_beforepolled_used);
 
@@ -646,12 +653,18 @@ void libxl_osevent_afterpoll(libxl_ctx *ctx, int nfds, const struct pollfd *fds,
 
         etime->func(gc, etime, &etime->abs);
     }
+}
 
+void libxl_osevent_afterpoll(libxl_ctx *ctx, int nfds, const struct pollfd *fds,
+                             struct timeval now)
+{
+    GC_INIT(ctx);
+    CTX_LOCK;
+    afterpoll_unlocked(gc, nfds, fds, now);
     CTX_UNLOCK;
     GC_FREE;
 }
 
-
 /*
  * osevent hook and callback machinery
  */
@@ -714,11 +727,10 @@ void libxl__event_disaster(libxl__gc *gc, const char *msg, int errnoval,
                type ? libxl_event_type_to_string(type) : "",
                type ? ")" : "");
 
-    /*
-     * FIXME: This should call the "disaster" hook supplied to
-     * libxl_event_register_callbacks, which will be introduced in the
-     * next patch.
-     */
+    if (CTX->event_hooks && CTX->event_hooks->disaster) {
+        CTX->event_hooks->disaster(CTX->event_hooks_user, type, msg, errnoval);
+        return;
+    }
 
     const char verybad[] =
         "DISASTER in event loop not handled by libxl application";
@@ -728,6 +740,160 @@ void libxl__event_disaster(libxl__gc *gc, const char *msg, int errnoval,
 }
 
 /*
+ * Event retrieval etc.
+ */
+
+void libxl_event_register_callbacks(libxl_ctx *ctx,
+                  const libxl_event_hooks *hooks, void *user)
+{
+    ctx->event_hooks = hooks;
+    ctx->event_hooks_user = user;
+}
+
+void libxl__event_occurred(libxl__gc *gc, libxl_event *event)
+{
+    if (CTX->event_hooks &&
+        (CTX->event_hooks->event_occurs_mask & (1UL << event->type))) {
+        /* libxl__gc_cleanup will call the callback, just before exit
+         * from libxl.  This helps avoid reentrancy bugs: parts of
+         * libxl that call libxl__event_occurred do not have to worry
+         * that libxl might be reentered at that point. */
+        LIBXL_TAILQ_INSERT_TAIL(&gc->occurred_for_callback, event, link);
+        return;
+    } else {
+        LIBXL_TAILQ_INSERT_TAIL(&CTX->occurred, event, link);
+    }
+}
+
+void libxl_event_free(libxl_ctx *ctx, libxl_event *event)
+{
+    /* Exceptionally, this function may be called from libxl, with ctx==0 */
+    libxl_event_dispose(event);
+    free(event);
+}
+
+libxl_event *libxl__event_new(libxl__gc *gc,
+                              libxl_event_type type, uint32_t domid)
+{
+    libxl_event *ev;
+
+    ev = malloc(sizeof(*ev));
+    if (!ev) {
+        LIBXL__EVENT_DISASTER(gc, "allocate new event", errno, type);
+        return NULL;
+    }
+
+    memset(ev, 0, sizeof(*ev));
+    ev->type = type;
+    ev->domid = domid;
+
+    return ev;
+}
+
+static int event_check_unlocked(libxl__gc *gc, libxl_event **event_r,
+                                unsigned long typemask,
+                                libxl_event_predicate *pred, void *pred_user)
+{
+    libxl_event *ev;
+    int rc;
+
+    LIBXL_TAILQ_FOREACH(ev, &CTX->occurred, link) {
+        if (!(typemask & (1UL << ev->type)))
+            continue;
+
+        if (pred && !pred(ev, pred_user))
+            continue;
+
+        /* got one! */
+        LIBXL_TAILQ_REMOVE(&CTX->occurred, ev, link);
+        *event_r = ev;
+        rc = 0;
+        goto out;
+    }
+    rc = ERROR_NOT_READY;
+
+ out:
+    return rc;
+}
+
+int libxl_event_check(libxl_ctx *ctx, libxl_event **event_r,
+                      unsigned long typemask,
+                      libxl_event_predicate *pred, void *pred_user)
+{
+    GC_INIT(ctx);
+    CTX_LOCK;
+    int rc = event_check_unlocked(gc, event_r, typemask, pred, pred_user);
+    CTX_UNLOCK;
+    GC_FREE;
+    return rc;
+}
+
+int libxl_event_wait(libxl_ctx *ctx, libxl_event **event_r,
+                     unsigned long typemask,
+                     libxl_event_predicate *pred, void *pred_user)
+{
+    int rc;
+    struct timeval now;
+
+    GC_INIT(ctx);
+    CTX_LOCK;
+
+    for (;;) {
+        rc = event_check_unlocked(gc, event_r, typemask, pred, pred_user);
+        if (rc != ERROR_NOT_READY) goto out;
+
+        rc = libxl__gettimeofday(gc, &now);
+        if (rc) goto out;
+
+        int timeout;
+
+        for (;;) {
+            int nfds = CTX->fd_polls_allocd;
+            timeout = -1;
+            rc = beforepoll_unlocked(gc, &nfds, CTX->fd_polls, &timeout, now);
+            if (!rc) break;
+            if (rc != ERROR_BUFFERFULL) goto out;
+            
+            struct pollfd *newarray =
+                (nfds > INT_MAX / sizeof(struct pollfd) / 2) ? 0 :
+                realloc(CTX->fd_polls, sizeof(*newarray) * nfds);
+            
+            if (!newarray) { rc = ERROR_NOMEM; goto out; }
+
+            CTX->fd_polls = newarray;
+            CTX->fd_polls_allocd = nfds;
+        }
+
+        rc = poll(CTX->fd_polls, CTX->fd_polls_allocd, timeout);
+        if (rc < 0) {
+            if (errno == EINTR) continue;
+            LIBXL__LOG_ERRNOVAL(CTX, LIBXL__LOG_ERROR, errno, "poll failed");
+            rc = ERROR_FAIL;
+            goto out;
+        }
+
+        rc = libxl__gettimeofday(gc, &now);
+        if (rc) goto out;
+
+        afterpoll_unlocked(gc, CTX->fd_polls_allocd, CTX->fd_polls, now);
+
+        /* we unlock and free the gc each time we go through this loop,
+         * so that (a) we don't accumulate garbage and (b) any events
+         * which are to be dispatched by callback are actually delivered
+         * in a timely fashion.
+         */
+        CTX_UNLOCK;
+        libxl__gc_cleanup(gc);
+        CTX_LOCK;
+    }
+
+ out:
+    CTX_UNLOCK;
+    GC_FREE;
+    return rc;
+}
+
+/*
  * Local variables:
  * mode: C
  * c-basic-offset: 4
diff --git a/tools/libxl/libxl_event.h b/tools/libxl/libxl_event.h
index cc4a348..3001100 100644
--- a/tools/libxl/libxl_event.h
+++ b/tools/libxl/libxl_event.h
@@ -18,6 +18,178 @@
 
 #include <libxl.h>
 
+/*======================================================================*/
+
+/*
+ * Domain event handling - getting Xen events from libxl
+ */
+
+#define LIBXL_EVENTMASK_ALL (~(unsigned long)0)
+
+typedef int libxl_event_predicate(const libxl_event*, void *user);
+  /* Return value is 0 if the event is unwanted or non-0 if it is.
+   * Predicates are not allowed to fail.
+   */
+
+int libxl_event_check(libxl_ctx *ctx, libxl_event **event_r,
+                      unsigned long typemask,
+                      libxl_event_predicate *predicate, void *predicate_user);
+  /* Searches for an event, already-happened, which matches typemask
+   * and predicate.  predicate==0 matches any event.
+   * libxl_event_check returns the event, which must then later be
+   * freed by the caller using libxl_event_free.
+   *
+   * Returns ERROR_NOT_READY if no such event has happened.
+   */
+
+int libxl_event_wait(libxl_ctx *ctx, libxl_event **event_r,
+                     unsigned long typemask,
+                     libxl_event_predicate *predicate, void *predicate_user);
+  /* Like libxl_event_check but blocks if no suitable events are
+   * available, until some are.  Uses libxl_osevent_beforepoll/
+   * _afterpoll so may be inefficient if very many domains are being
+   * handled by a single program.
+   */
+
+void libxl_event_free(libxl_ctx *ctx, libxl_event *event);
+
+
+/* Alternatively or additionally, the application may also use this: */
+
+typedef struct libxl_event_hooks {
+    uint64_t event_occurs_mask;
+    void (*event_occurs)(void *user, const libxl_event *event);
+    void (*disaster)(void *user, libxl_event_type type,
+                     const char *msg, int errnoval);
+} libxl_event_hooks;
+
+void libxl_event_register_callbacks(libxl_ctx *ctx,
+                                    const libxl_event_hooks *hooks, void *user);
+  /*
+   * Arranges that libxl will henceforth call event_occurs for any
+   * events whose type is set in event_occurs_mask, rather than
+   * queueing the event for retrieval by libxl_event_check/wait.
+   * Events whose bit is clear in mask are not affected.
+   *
+   * event becomes owned by the application and must be freed, either
+   * by event_occurs or later.
+   *
+   * event_occurs may be NULL if mask is 0.
+   *
+   * libxl_event_register_callback also provides a way for libxl to
+   * report to the application that there was a problem reporting
+   * events; this can occur due to lack of host memory during event
+   * handling, or other wholly unrecoverable errors from system calls
+   * made by libxl.  This will not happen for frivolous reasons - only
+   * if the system, or the Xen components of it, are badly broken.
+   *
+   * msg and errnoval will describe the action that libxl was trying
+   * to do, and type specifies the type of libxl events which may be
+   * missing.  type may be 0 in which case events of all types may be
+   * missing.
+   *
+   * disaster may be NULL.  If it is, or if _register_callbacks has
+   * not been called, errors of this kind are fatal to the entire
+   * application: libxl will print messages to its logs and to stderr
+   * and call exit(-1).
+   *
+   * If disaster returns, it may be the case that some or all future
+   * libxl calls will return errors; likewise it may be the case that
+   * no more events (of the specified type, if applicable) can be
+   * produced.  An application which supplies a disaster function
+   * should normally react either by exiting, or by (when it has
+   * returned to its main event loop) shutting down libxl with
+   * libxl_ctx_free and perhaps trying to restart it with
+   * libxl_ctx_init.
+   *
+   * In any case before calling disaster, libxl will have logged a
+   * message with level XTL_CRITICAL.
+   *
+   * Reentrancy: it IS permitted to call libxl from within
+   * event_occurs.  It is NOT permitted to call libxl from within
+   * disaster.
+   *
+   * libxl_event_register_callbacks may be called as many times, with
+   * 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.
+   */
+
+
+/*
+ * Events are only generated if they have been requested.
+ * The following functions request the generation of specific events.
+ *
+ * Each set of functions for controlling event generation has this form:
+ *
+ *   typedef struct libxl__evgen_FOO libxl__evgen_FOO;
+ *   int libxl_evenable_FOO(libxl_ctx *ctx, FURTHER PARAMETERS,
+ *                          libxl_ev_user user, libxl__evgen_FOO **evgen_out);
+ *   void libxl_evdisable_FOO(libxl_ctx *ctx, libxl__evgen_FOO *evgen);
+ *
+ * The evenable function arranges that the events (as described in the
+ * doc comment for the individual function) will start to be generated
+ * by libxl.  On success, *evgen_out is set to a non-null pointer to
+ * an opaque struct.
+ *
+ * The user value is returned in the generated events and may be
+ * used by the caller for whatever it likes.  The type ev_user is
+ * guaranteed to be an unsigned integer type which is at least
+ * as big as uint64_t and is also guaranteed to be big enough to
+ * contain any intptr_t value.
+ *
+ * If it becomes desirable to stop generation of the relevant events,
+ * or to reclaim the resources in libxl associated with the evgen
+ * structure, the same evgen value should be passed to the evdisable
+ * function.  However, note that events which occurred prior to the
+ * evdisable call may still be returned.
+ *
+ * The caller may enable identical events more than once.  If they do
+ * so, each actual occurrence will generate several events to be
+ * returned by libxl_event_check, with the appropriate user value(s).
+ * Aside from this, each occurrence of each event is returned by
+ * libxl_event_check exactly once.
+ *
+ * An evgen is associated with the libxl_ctx used for its creation.
+ * After libxl_ctx_free, all corresponding evgen handles become
+ * invalid and must no longer be passed to evdisable.
+ *
+ * Events enabled with evenable prior to a fork and libxl_ctx_postfork
+ * are no longer generated after the fork/postfork; however the evgen
+ * structures are still valid and must be passed to evdisable if the
+ * memory they use should not be leaked.
+ *
+ * Applications should ensure that they eventually retrieve every
+ * event using libxl_event_check or libxl_event_wait, since events
+ * which occur but are not retreived by the application will be queued
+ * inside libxl indefinitely.  libxl_event_check/_wait may be O(n)
+ * where n is the number of queued events which do not match the
+ * criteria specified in the arguments to check/wait.
+ */
+
+typedef struct libxl__evgen_domain_death libxl_evgen_domain_death;
+int libxl_evenable_domain_death(libxl_ctx *ctx, uint32_t domid,
+                         libxl_ev_user, libxl_evgen_domain_death **evgen_out);
+void libxl_evdisable_domain_death(libxl_ctx *ctx, libxl_evgen_domain_death*);
+  /* Arranges for the generation of DOMAIN_SHUTDOWN and DOMAIN_DESTROY
+   * events.  A domain which is destroyed before it shuts down
+   * may generate only a DESTROY event.
+   */
+
+typedef struct libxl__evgen_disk_eject libxl_evgen_disk_eject;
+int libxl_evenable_disk_eject(libxl_ctx *ctx, uint32_t domid, const char *vdev,
+                        libxl_ev_user, libxl_evgen_disk_eject **evgen_out);
+void libxl_evdisable_disk_eject(libxl_ctx *ctx, libxl_evgen_disk_eject*);
+  /* Arranges for the generation of DISK_EJECT events.  A copy of the
+   * string *vdev will be made for libxl's internal use, and a pointer
+   * to this (or some other) copy will be returned as the vdev
+   * member of event.u.
+   */
+
 
 /*======================================================================*/
 
@@ -36,10 +208,10 @@
  *      poll();
  *      libxl_osevent_afterpoll(...);
  *      for (;;) {
- *        r=libxl_event_check(...);
- *        if (r==LIBXL_NOT_READY) break;
- *        if (r) handle failure;
- *        do something with the event;
+ *          r = libxl_event_check(...);
+ *          if (r==LIBXL_NOT_READY) break;
+ *          if (r) goto error_out;
+ *          do something with the event;
  *      }
  *   }
  *
@@ -171,6 +343,8 @@ void libxl_osevent_register_hooks(libxl_ctx *ctx,
    * Of these we would normally recommend (a).
    *
    * The value *hooks is not copied and must outlast the libxl_ctx.
+   *
+   * The value of user is stored by libxl and passed to the callbacks.
    */
 
 /* It is NOT legal to call _occurred_ reentrantly within any libxl
diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c
index 232cc4a..afae0dd 100644
--- a/tools/libxl/libxl_internal.c
+++ b/tools/libxl/libxl_internal.c
@@ -74,6 +74,12 @@ void libxl__gc_cleanup(libxl__gc *gc)
     free(gc->alloc_ptrs);
     gc->alloc_ptrs = 0;
     gc->alloc_maxsize = 0;
+
+    libxl_event *ev, *ev_tmp;
+    LIBXL_TAILQ_FOREACH_SAFE(ev, &gc->occurred_for_callback, link, ev_tmp) {
+        LIBXL_TAILQ_REMOVE(&gc->occurred_for_callback, ev, link);
+        CTX->event_hooks->event_occurs(CTX->event_hooks_user, ev);
+    }
 }
 
 void *libxl__zalloc(libxl__gc *gc, int bytes)
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index c4a5fa1..2f4d437 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -154,11 +154,45 @@ typedef struct libxl__ev_watch_slot {
     
 libxl__ev_xswatch *libxl__watch_slot_contents(libxl__gc *gc, int slotnum);
 
+
+/*
+ * evgen structures, which are the state we use for generating
+ * events for the caller.
+ *
+ * In general in each case there's an internal and an external
+ * version of the _evdisable_FOO function; the internal one is
+ * used during cleanup.
+ */
+
+struct libxl__evgen_domain_death {
+    uint32_t domid;
+    unsigned shutdown_reported:1, death_reported:1;
+    LIBXL_TAILQ_ENTRY(libxl_evgen_domain_death) entry;
+        /* on list .death_reported ? CTX->death_list : CTX->death_reported */
+    libxl_ev_user user;
+};
+_hidden void
+libxl__evdisable_domain_death(libxl__gc*, libxl_evgen_domain_death*);
+
+struct libxl__evgen_disk_eject {
+    libxl__ev_xswatch watch;
+    uint32_t domid;
+    LIBXL_LIST_ENTRY(libxl_evgen_disk_eject) entry;
+    libxl_ev_user user;
+    char *vdev;
+};
+_hidden void
+libxl__evdisable_disk_eject(libxl__gc*, libxl_evgen_disk_eject*);
+
+
 struct libxl__ctx {
     xentoollog_logger *lg;
     xc_interface *xch;
     struct xs_handle *xsh;
 
+    const libxl_event_hooks *event_hooks;
+    void *event_hooks_user;
+
     pthread_mutex_t lock; /* protects data structures hanging off the ctx */
       /* Always use CTX_LOCK and CTX_UNLOCK to manipulate this.
        *
@@ -171,12 +205,17 @@ struct libxl__ctx {
        * documented in the libxl public interface.
        */
 
+    LIBXL_TAILQ_HEAD(libxl__event_list, libxl_event) occurred;
+
     int osevent_in_hook;
     const libxl_osevent_hooks *osevent_hooks;
     void *osevent_user;
       /* See the comment for OSEVENT_HOOK_INTERN in libxl_event.c
        * for restrictions on the use of the osevent fields. */
 
+    struct pollfd *fd_polls;
+    int fd_polls_allocd;
+
     int fd_beforepolled_allocd, fd_beforepolled_used;
     libxl__ev_fd **fd_beforepolled; /* see libxl_osevent_beforepoll */
     LIBXL_LIST_HEAD(, libxl__ev_fd) efds;
@@ -188,6 +227,13 @@ struct libxl__ctx {
     uint32_t watch_counter; /* helps disambiguate slot reuse */
     libxl__ev_fd watch_efd;
 
+    LIBXL_TAILQ_HEAD(libxl__evgen_domain_death_list, libxl_evgen_domain_death)
+        death_list /* sorted by domid */,
+        death_reported;
+    libxl__ev_xswatch death_watch;
+    
+    LIBXL_LIST_HEAD(, libxl_evgen_disk_eject) disk_eject_evgens;
+
     /* for callers who reap children willy-nilly; caller must only
      * set this after libxl_init and before any other call - or
      * may leave them untouched */
@@ -223,12 +269,14 @@ struct libxl__gc {
     int alloc_maxsize;
     void **alloc_ptrs;
     libxl_ctx *owner;
+    struct libxl__event_list occurred_for_callback;
 };
 
-#define LIBXL_INIT_GC(gc,ctx) do{               \
-        (gc).alloc_maxsize = 0;                 \
-        (gc).alloc_ptrs = 0;                    \
-        (gc).owner = (ctx);                     \
+#define LIBXL_INIT_GC(gc,ctx) do{                       \
+        (gc).alloc_maxsize = 0;                         \
+        (gc).alloc_ptrs = 0;                            \
+        (gc).owner = (ctx);                             \
+        LIBXL_TAILQ_INIT(&(gc).occurred_for_callback);  \
     } while(0)
 
 static inline libxl_ctx *libxl__gc_owner(libxl__gc *gc)
@@ -250,7 +298,9 @@ static inline libxl_ctx *libxl__gc_owner(libxl__gc *gc)
  */
 /* register @ptr in @gc for free on exit from outermost libxl callframe. */
 _hidden int libxl__ptr_add(libxl__gc *gc, void *ptr);
-/* if this is the outermost libxl callframe then free all pointers in @gc */
+/* if this is the outermost libxl callframe then free all pointers in @gc
+ *  and report all occurred events via callback, if applicable.
+ * May reenters the application so must not be called with ctx locked. */
 _hidden void libxl__gc_cleanup(libxl__gc *gc);
 /* allocate and zero @bytes. (similar to a gc'd malloc(3)+memzero()) */
 _hidden void *libxl__zalloc(libxl__gc *gc, int bytes);
@@ -360,6 +410,9 @@ _hidden char *libxl__xs_libxl_path(libxl__gc *gc, uint32_t domid);
  *
  * Callers of libxl__ev_KIND_register must ensure that the
  * registration is undone, with _deregister, in libxl_ctx_free.
+ * This means that normally each kind of libxl__evgen (ie each
+ * application-requested event source) needs to be on a list so that
+ * it can be automatically deregistered as promised in libxl_event.h.
  */
 
 
@@ -403,6 +456,25 @@ static inline int libxl__ev_xswatch_isregistered(const libxl__ev_xswatch *xw)
 
 
 
+/*
+ * Other event-handling support provided by the libxl event core to
+ * the rest of libxl.
+ */
+
+_hidden void libxl__event_occurred(libxl__gc*, libxl_event *event);
+  /* Arranges to notify the application that the event has occurred.
+   * event should be suitable for passing to libxl_event_free. */
+
+_hidden libxl_event *libxl__event_new(libxl__gc*, libxl_event_type,
+                                      uint32_t domid);
+  /* Convenience function.
+   * Allocates a new libxl_event, fills in domid and type.
+   * If allocation fails, calls _disaster, and returns NULL. */
+
+#define NEW_EVENT(gc, type, domid)                              \
+    libxl__event_new((gc), LIBXL_EVENT_TYPE_##type, (domid));
+    /* Convenience macro. */
+
 _hidden void libxl__event_disaster(libxl__gc*, const char *msg, int errnoval,
                                    libxl_event_type type /* may be 0 */,
                                    const char *file, int line,
@@ -415,6 +487,9 @@ _hidden void libxl__event_disaster(libxl__gc*, const char *msg, int errnoval,
    * libxl__ev_FOO_callback or an application event), but are
    * prevented from doing so due to eg lack of memory.
    *
+   * See the "disaster" member of libxl_event_hooks and associated
+   * comment in libxl_event.h.
+   *
    * NB that this function may return and the caller isn't supposed to
    * then crash, although it may fail (and henceforth leave things in
    * a state where many or all calls fail).
@@ -895,7 +970,7 @@ libxl__device_model_version_running(libxl__gc *gc, uint32_t domid);
  */
 
 #define GC_INIT(ctx)  libxl__gc gc[1]; LIBXL_INIT_GC(gc[0],ctx)
-#define GC_FREE       libxl__gc_cleanup(gc)
+#define GC_FREE       libxl__gc_cleanup(gc) /* MUST NOT CALL WITH CTX LOCKED */
 #define CTX           libxl__gc_owner(gc)
 
 
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index d59d2cb..5a713f0 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -75,11 +75,6 @@ libxl_action_on_shutdown = Enumeration("action_on_shutdown", [
     (6, "COREDUMP_RESTART"),
     ])
 
-libxl_event_type = Enumeration("event_type", [
-    (1, "DOMAIN_DEATH"),
-    (2, "DISK_EJECT"),
-    ])
-
 libxl_button = Enumeration("button", [
     (1, "POWER"),
     (2, "SLEEP"),
@@ -381,3 +376,33 @@ libxl_sched_credit = Struct("sched_credit", [
     ("weight", integer),
     ("cap", integer),
     ], dispose_fn=None)
+
+libxl_event_type = Enumeration("event_type", [
+    (1, "DOMAIN_SHUTDOWN"),
+    (2, "DOMAIN_DESTROY"),
+    (3, "DISK_EJECT"),
+    ])
+
+libxl_ev_user = Number("libxl_ev_user")
+
+libxl_ev_link = Builtin("ev_link", passby=PASS_BY_REFERENCE, private=True)
+
+libxl_event = Struct("event",[
+    ("link",     libxl_ev_link,0,
+     "for use by libxl; caller may use this once the event has been"
+     " returned by libxl_event_{check,wait}"),
+    ("domid",    libxl_domid),
+    ("domuuid",  libxl_uuid),
+    ("for_user", libxl_ev_user),
+    ("type",     libxl_event_type),
+    ("u", KeyedUnion(None, libxl_event_type, "type",
+          [("domain_shutdown", Struct(None, [
+                                             ("shutdown_reason", uint8),
+                                      ])),
+           ("domain_destroy", Struct(None, [])),
+           ("disk_eject", Struct(None, [
+                                        ("vdev", string),
+                                        ("disk", libxl_device_disk),
+                                 ])),
+           ]))])
+
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index f1e729c..e5738b7 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -1221,14 +1221,16 @@ skip_vfb:
     xlu_cfg_destroy(config);
 }
 
-/* Returns 1 if domain should be restarted, 2 if domain should be renamed then restarted  */
-static int handle_domain_death(libxl_ctx *ctx, uint32_t domid, libxl_event *event,
-                               libxl_domain_config *d_config, libxl_dominfo *info)
+/* Returns 1 if domain should be restarted,
+ * 2 if domain should be renamed then restarted, or 0 */
+static int handle_domain_death(libxl_ctx *ctx, uint32_t domid,
+                               libxl_event *event,
+                               libxl_domain_config *d_config)
 {
     int restart = 0;
     libxl_action_on_shutdown action;
 
-    switch (info->shutdown_reason) {
+    switch (event->u.domain_shutdown.shutdown_reason) {
     case SHUTDOWN_poweroff:
         action = d_config->on_poweroff;
         break;
@@ -1245,11 +1247,14 @@ static int handle_domain_death(libxl_ctx *ctx, uint32_t domid, libxl_event *even
         action = d_config->on_watchdog;
         break;
     default:
-        LOG("Unknown shutdown reason code %d. Destroying domain.", info->shutdown_reason);
+        LOG("Unknown shutdown reason code %d. Destroying domain.",
+            event->u.domain_shutdown.shutdown_reason);
         action = LIBXL_ACTION_ON_SHUTDOWN_DESTROY;
     }
 
-    LOG("Action for shutdown reason code %d is %s", info->shutdown_reason, action_on_shutdown_names[action]);
+    LOG("Action for shutdown reason code %d is %s",
+        event->u.domain_shutdown.shutdown_reason,
+        action_on_shutdown_names[action]);
 
     if (action == LIBXL_ACTION_ON_SHUTDOWN_COREDUMP_DESTROY || action == LIBXL_ACTION_ON_SHUTDOWN_COREDUMP_RESTART) {
         char *corefile;
@@ -1314,7 +1319,7 @@ static void replace_string(char **str, const char *val)
 
 
 static int preserve_domain(libxl_ctx *ctx, uint32_t domid, libxl_event *event,
-                           libxl_domain_config *d_config, libxl_dominfo *info)
+                           libxl_domain_config *d_config)
 {
     time_t now;
     struct tm tm;
@@ -1426,6 +1431,27 @@ static int autoconnect_console(libxl_ctx *ctx, uint32_t domid, void *priv)
     _exit(1);
 }
 
+static int domain_wait_event(libxl_event **event_r) {
+    int ret;
+    for (;;) {
+        ret = libxl_event_wait(ctx, event_r, LIBXL_EVENTMASK_ALL, 0,0);
+        if (ret) {
+            LOG("Domain %d, failed to get event, quitting (rc=%d)", domid, ret);
+            return ret;
+        }
+        if ((*event_r)->domid != domid) {
+            char *evstr = libxl_event_to_json(ctx, *event_r);
+            LOG("INTERNAL PROBLEM - ignoring unexpected event for"
+                " domain %d (expected %d): event=%s",
+                (*event_r)->domid, domid, evstr);
+            free(evstr);
+            libxl_event_free(ctx, *event_r);
+            continue;
+        }
+        return ret;
+    }
+}
+
 static int create_domain(struct domain_create *dom_info)
 {
     libxl_domain_config d_config;
@@ -1439,10 +1465,11 @@ static int create_domain(struct domain_create *dom_info)
     const char *restore_file = dom_info->restore_file;
     int migrate_fd = dom_info->migrate_fd;
 
-    int fd, i;
+    int i;
     int need_daemon = daemonize;
     int ret, rc;
-    libxl_waiter *w1 = NULL, *w2 = NULL;
+    libxl_evgen_domain_death *deathw = NULL;
+    libxl_evgen_disk_eject **diskws = NULL; /* one per disk */
     void *config_data = 0;
     int config_len = 0;
     int restore_fd = -1;
@@ -1647,14 +1674,14 @@ start:
                 if (errno != EINTR) {
                     perror("failed to wait for daemonizing child");
                     ret = ERROR_FAIL;
-                    goto error_out;
+                    goto out;
                 }
             }
             if (status) {
                 libxl_report_child_exitstatus(ctx, XTL_ERROR,
                            "daemonizing child", child1, status);
                 ret = ERROR_FAIL;
-                goto error_out;
+                goto out;
             }
             ret = domid;
             goto out;
@@ -1691,92 +1718,106 @@ start:
     }
     LOG("Waiting for domain %s (domid %d) to die [pid %ld]",
         d_config.c_info.name, domid, (long)getpid());
-    w1 = (libxl_waiter*) xmalloc(sizeof(libxl_waiter) * d_config.num_disks);
-    w2 = (libxl_waiter*) xmalloc(sizeof(libxl_waiter));
-    libxl_wait_for_disk_ejects(ctx, domid, d_config.disks, d_config.num_disks, w1);
-    libxl_wait_for_domain_death(ctx, domid, w2);
-    libxl_get_wait_fd(ctx, &fd);
-    while (1) {
-        int ret;
-        fd_set rfds;
-        libxl_dominfo info;
-        libxl_event event;
-        libxl_device_disk disk;
 
-        FD_ZERO(&rfds);
-        FD_SET(fd, &rfds);
+    ret = libxl_evenable_domain_death(ctx, domid, 0, &deathw);
+    if (ret) goto out;
 
-        ret = select(fd + 1, &rfds, NULL, NULL, NULL);
-        if (!ret)
-            continue;
-        libxl_get_event(ctx, &event);
-        switch (event.type) {
-            case LIBXL_EVENT_TYPE_DOMAIN_DEATH:
-                ret = libxl_event_get_domain_death_info(ctx, domid, &event, &info);
-
-                if (ret < 0) {
-                    libxl_free_event(&event);
-                    continue;
+    if (!diskws) {
+        diskws = xmalloc(sizeof(*diskws) * d_config.num_disks);
+        for (i = 0; i < d_config.num_disks; i++)
+            diskws[i] = NULL;
+    }
+    for (i = 0; i < d_config.num_disks; i++) {
+        ret = libxl_evenable_disk_eject(ctx, domid, d_config.disks[i].vdev,
+                                        0, &diskws[i]);
+        if (ret) goto out;
+    }
+    while (1) {
+        libxl_event *event;
+        ret = domain_wait_event(&event);
+        if (ret) goto out;
+
+        switch (event->type) {
+
+        case LIBXL_EVENT_TYPE_DOMAIN_SHUTDOWN:
+            LOG("Domain %d has shut down, reason code %d 0x%x", domid,
+                event->u.domain_shutdown.shutdown_reason,
+                event->u.domain_shutdown.shutdown_reason);
+            switch (handle_domain_death(ctx, domid, event, &d_config)) {
+            case 2:
+                if (!preserve_domain(ctx, domid, event, &d_config)) {
+                    /* If we fail then exit leaving the old domain in place. */
+                    ret = -1;
+                    goto out;
                 }
 
-                LOG("Domain %d is dead", domid);
-
-                if (ret) {
-                    switch (handle_domain_death(ctx, domid, &event, &d_config, &info)) {
-                    case 2:
-                        if (!preserve_domain(ctx, domid, &event, &d_config, &info)) {
-                            /* If we fail then exit leaving the old domain in place. */
-                            ret = -1;
-                            goto out;
-                        }
-
-                        /* Otherwise fall through and restart. */
-                    case 1:
-
-                        for (i = 0; i < d_config.num_disks; i++)
-                            libxl_free_waiter(&w1[i]);
-                        libxl_free_waiter(w2);
-                        free(w1);
-                        free(w2);
-
-                        /*
-                         * Do not attempt to reconnect if we come round again due to a
-                         * guest reboot -- the stdin/out will be disconnected by then.
-                         */
-                        dom_info->console_autoconnect = 0;
-
-                        /* Some settings only make sense on first boot. */
-                        paused = 0;
-                        if (common_domname
-                            && strcmp(d_config.c_info.name, common_domname)) {
-                            d_config.c_info.name = strdup(common_domname);
-                        }
-
-                        /*
-                         * XXX FIXME: If this sleep is not there then domain
-                         * re-creation fails sometimes.
-                         */
-                        LOG("Done. Rebooting now");
-                        sleep(2);
-                        goto start;
-                    case 0:
-                        LOG("Done. Exiting now");
-                        ret = 0;
-                        goto out;
-                    }
-                } else {
-                    LOG("Unable to get domain death info, quitting");
-                    goto out;
+                /* Otherwise fall through and restart. */
+            case 1:
+                libxl_event_free(ctx, event);
+                libxl_evdisable_domain_death(ctx, deathw);
+                deathw = NULL;
+                for (i = 0; i < d_config.num_disks; i++) {
+                    libxl_evdisable_disk_eject(ctx, diskws[i]);
+                    diskws[i] = NULL;
                 }
-                break;
-            case LIBXL_EVENT_TYPE_DISK_EJECT:
-                if (libxl_event_get_disk_eject_info(ctx, domid, &event, &disk)) {
-                    libxl_cdrom_insert(ctx, domid, &disk);
-                    libxl_device_disk_dispose(&disk);
+                /* discard any other events which may have been generated */
+                while (!(ret = libxl_event_check(ctx, &event,
+                                                 LIBXL_EVENTMASK_ALL, 0,0))) {
+                    libxl_event_free(ctx, event);
                 }
-                break;
+                if (ret != ERROR_NOT_READY) {
+                    LOG("warning, libxl_event_check (cleanup) failed (rc=%d)",
+                        ret);
+                }
+
+                /*
+                 * Do not attempt to reconnect if we come round again due to a
+                 * guest reboot -- the stdin/out will be disconnected by then.
+                 */
+                dom_info->console_autoconnect = 0;
+
+                /* Some settings only make sense on first boot. */
+                paused = 0;
+                if (common_domname
+                    && strcmp(d_config.c_info.name, common_domname)) {
+                    d_config.c_info.name = strdup(common_domname);
+                }
+
+                /*
+                 * XXX FIXME: If this sleep is not there then domain
+                 * re-creation fails sometimes.
+                 */
+                LOG("Done. Rebooting now");
+                sleep(2);
+                goto start;
+
+            case 0:
+                LOG("Done. Exiting now");
+                ret = 0;
+                goto out;
+
+            default:
+                abort();
+            }
+
+        case LIBXL_EVENT_TYPE_DOMAIN_DESTROY:
+            LOG("Domain %d has been destroyed.", domid);
+            ret = 0;
+            goto out;
+
+        case LIBXL_EVENT_TYPE_DISK_EJECT:
+            /* XXX what is this for? */
+            libxl_cdrom_insert(ctx, domid, &event->u.disk_eject.disk);
+            break;
+
+        default:;
+            char *evstr = libxl_event_to_json(ctx, event);
+            LOG("warning, got unexpected event type %d, event=%s",
+                event->type, evstr);
+            free(evstr);
         }
-        libxl_free_event(&event);
+
+        libxl_event_free(ctx, event);
     }
 
 error_out:
@@ -2259,43 +2300,46 @@ static void destroy_domain(const char *p)
 static void shutdown_domain(const char *p, int wait)
 {
     int rc;
+    libxl_event *event;
 
     find_domain(p);
     rc=libxl_domain_shutdown(ctx, domid, 0);
     if (rc) { fprintf(stderr,"shutdown failed (rc=%d)\n",rc);exit(-1); }
 
     if (wait) {
-        libxl_waiter waiter;
-        int fd;
-
-        libxl_wait_for_domain_death(ctx, domid, &waiter);
+        libxl_evgen_domain_death *deathw;
 
-        libxl_get_wait_fd(ctx, &fd);
-
-        while (wait) {
-            fd_set rfds;
-            libxl_event event;
-            libxl_dominfo info;
+        rc = libxl_evenable_domain_death(ctx, domid, 0, &deathw);
+        if (rc) {
+            fprintf(stderr,"wait for death failed (evgen, rc=%d)\n",rc);
+            exit(-1);
+        }
 
-            FD_ZERO(&rfds);
-            FD_SET(fd, &rfds);
+        for (;;) {
+            rc = domain_wait_event(&event);
+            if (rc) exit(-1);
 
-            if (!select(fd + 1, &rfds, NULL, NULL, NULL))
-                continue;
+            switch (event->type) {
 
-            libxl_get_event(ctx, &event);
+            case LIBXL_EVENT_TYPE_DOMAIN_DESTROY:
+                LOG("Domain %d has been destroyed", domid);
+                goto done;
 
-            if (event.type == LIBXL_EVENT_TYPE_DOMAIN_DEATH) {
-                if (libxl_event_get_domain_death_info(ctx, domid, &event, &info) < 0)
-                    continue;
+            case LIBXL_EVENT_TYPE_DOMAIN_SHUTDOWN:
+                LOG("Domain %d has been shut down, reason code %d %x", domid,
+                    event->u.domain_shutdown.shutdown_reason,
+                    event->u.domain_shutdown.shutdown_reason);
+                goto done;
 
-                LOG("Domain %d is dead", domid);
-                wait = 0;
+            default:
+                LOG("Unexpected event type %d", event->type);
+                break;
             }
-
-            libxl_free_event(&event);
+            libxl_event_free(ctx, event);
         }
-        libxl_free_waiter(&waiter);
+    done:
+        libxl_event_free(ctx, event);
+        libxl_evdisable_domain_death(ctx, deathw);
     }
 }
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 18:55:51 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 18: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.xensource.com>)
	id 1RZ5bd-0001DT-Hb; Fri, 09 Dec 2011 18:55:37 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RZ5bb-0001Ar-KF
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 18:55:35 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1323456879!6616386!8
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI2MQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21344 invoked from network); 9 Dec 2011 18:54:45 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 18:54:45 -0000
X-IronPort-AV: E=Sophos;i="4.71,327,1320624000"; 
   d="scan'208";a="9392199"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 18:54:45 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 18:54:45 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RZ5an-0002e3-BN; Fri, 09 Dec 2011 18:54:45 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RZ5an-00040N-Aa;
	Fri, 09 Dec 2011 18:54:45 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Fri, 9 Dec 2011 18:54:26 +0000
Message-ID: <1323456877-15315-8-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1323456877-15315-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1323456877-15315-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 07/18] libxl: internal convenience macros
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Provide some macros which are useful shorthands for use within libxl:
  * GC_INIT to initialise a gc from a ctx and GC_FREE to free it
  * CTX(gc) to give you back the ctx
  * LIBXL_TAILQ_INSERT_SORTED for inserting things into sorted lists

These will be used by later patches.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl_internal.h |   48 ++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 48 insertions(+), 0 deletions(-)

diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index bfc74c9..950c466 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -646,6 +646,54 @@ _hidden libxl__json_object *libxl__json_parse(libxl__gc *gc, const char *s);
 _hidden libxl_device_model_version
 libxl__device_model_version_running(libxl__gc *gc, uint32_t domid);
 
+
+/*
+ * Convenience macros.
+ */
+
+
+/*
+ * All of these assume (or define)
+ *    libxl__gc *gc;
+ * as a local variable.
+ */
+
+#define GC_INIT(ctx)  libxl__gc gc[1] = { LIBXL_INIT_GC(ctx) }
+#define GC_FREE       libxl__free_all(gc)
+#define CTX           libxl__gc_owner(gc)
+
+
+/*
+ * Inserts "elm_new" into the sorted list "head".
+ *
+ * "elm_search" must be a loop search variable of the same type as
+ * "elm_new".  "new_after_search_p" must be an expression which is
+ * true iff the element "elm_new" sorts after the element
+ * "elm_search".
+ *
+ * "search_body" can be empty, or some declaration(s) and statement(s)
+ * needed for "new_after_search_p".
+ */
+#define LIBXL_TAILQ_INSERT_SORTED(head, entry, elm_new, elm_search,     \
+                                  search_body, new_after_search_p)      \
+    do {                                                                \
+        for ((elm_search) = LIBXL_TAILQ_FIRST((head));                  \
+             (elm_search);                                              \
+             (elm_search) = LIBXL_TAILQ_NEXT((elm_search), entry)) {    \
+            search_body;                                                \
+            if (!(new_after_search_p))                                  \
+                break;                                                  \
+        }                                                               \
+        /* now elm_search is either the element before which we want    \
+         * to place elm_new, or NULL meaning we want to put elm_new at  \
+         * the end */                                                   \
+        if ((elm_search))                                               \
+            LIBXL_TAILQ_INSERT_BEFORE((elm_search), (elm_new), entry);  \
+        else                                                            \
+            LIBXL_TAILQ_INSERT_TAIL((head), (elm_new), entry);          \
+    } while(0)
+
+
 #endif
 
 /*
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 19:24:34 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 19:24:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZ63L-0004Wi-4H; Fri, 09 Dec 2011 19:24:15 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RZ63J-0004Wd-Pp
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 19:24:14 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1323458599!6618875!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI2MQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12789 invoked from network); 9 Dec 2011 19:23:20 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 19:23:20 -0000
X-IronPort-AV: E=Sophos;i="4.71,327,1320624000"; 
   d="scan'208";a="9392759"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 19:22:52 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 19:22:52 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RZ620-0002o7-ER;
	Fri, 09 Dec 2011 19:22:52 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RZ620-0002CT-AW;
	Fri, 09 Dec 2011 19:22:52 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10466-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 9 Dec 2011 19:22:52 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10466: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10466 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10466/

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-amd64-xl-sedf      9 guest-start               fail REGR. vs. 10201
 test-amd64-i386-rhel6hvm-intel  3 host-install(3)              broken in 10460
 test-i386-i386-pv             3 host-install(3)              broken   in 10460
 test-amd64-amd64-xl-sedf      3 host-install(3)              broken   in 10460

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-win-vcpus1  7 windows-install            fail pass in 10460
 test-amd64-i386-win-vcpus1    7 windows-install    fail in 10460 pass in 10466
 test-amd64-amd64-xl-win       7 windows-install    fail in 10460 pass in 10466
 test-i386-i386-xl-win         7 windows-install    fail in 10460 pass in 10466

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-i386-i386-xl-winxpsp3    7 windows-install              fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install          fail never pass
 test-amd64-i386-xl-win7-amd64  7 windows-install              fail  never pass
 test-amd64-i386-xend-winxpsp3  7 windows-install              fail  never pass
 test-amd64-amd64-xl-win7-amd64  7 windows-install              fail never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop           fail in 10460 never pass

version targeted for testing:
 xen                  1c58bb664d8d
baseline version:
 xen                  62ff6a318c5d

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scanneel.ca>
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Andres Lagar-Cavilla <andres@lagarcavilla>
  Andrew Cooper <andrew.cooper3@citrix.com>
  Anthony PERARD <anthony.perard@citrix.com>
  Brendan Cully <brendan@cs.ubc.ca>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Haitao Shan <haitao.shan@intel.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@novell.com>
  Jan Beulich <jbeulich@suse.com>
  Jonathan Davies <jonathan.davies@citrix.com>
  juergen.gross@ts.fujitsu.com
  Keir Fraser <keir@xen.org>
  Liu, Jinsong <jinsong.liu@intel.com>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
  Philipp Hahn <hahn@univention.de>
  Shriram Rajagopalan <rshriram@cs.ubc.ca>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang2 <wei.wang2@amd.com>
  Xudong Hao <xudong.hao@intel.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 1522 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 19:24:34 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 19:24:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZ63L-0004Wi-4H; Fri, 09 Dec 2011 19:24:15 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RZ63J-0004Wd-Pp
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 19:24:14 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1323458599!6618875!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI2MQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12789 invoked from network); 9 Dec 2011 19:23:20 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 19:23:20 -0000
X-IronPort-AV: E=Sophos;i="4.71,327,1320624000"; 
   d="scan'208";a="9392759"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 19:22:52 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 19:22:52 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RZ620-0002o7-ER;
	Fri, 09 Dec 2011 19:22:52 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RZ620-0002CT-AW;
	Fri, 09 Dec 2011 19:22:52 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10466-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 9 Dec 2011 19:22:52 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10466: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10466 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10466/

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-amd64-xl-sedf      9 guest-start               fail REGR. vs. 10201
 test-amd64-i386-rhel6hvm-intel  3 host-install(3)              broken in 10460
 test-i386-i386-pv             3 host-install(3)              broken   in 10460
 test-amd64-amd64-xl-sedf      3 host-install(3)              broken   in 10460

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-win-vcpus1  7 windows-install            fail pass in 10460
 test-amd64-i386-win-vcpus1    7 windows-install    fail in 10460 pass in 10466
 test-amd64-amd64-xl-win       7 windows-install    fail in 10460 pass in 10466
 test-i386-i386-xl-win         7 windows-install    fail in 10460 pass in 10466

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-i386-i386-xl-winxpsp3    7 windows-install              fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install          fail never pass
 test-amd64-i386-xl-win7-amd64  7 windows-install              fail  never pass
 test-amd64-i386-xend-winxpsp3  7 windows-install              fail  never pass
 test-amd64-amd64-xl-win7-amd64  7 windows-install              fail never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop           fail in 10460 never pass

version targeted for testing:
 xen                  1c58bb664d8d
baseline version:
 xen                  62ff6a318c5d

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scanneel.ca>
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Andres Lagar-Cavilla <andres@lagarcavilla>
  Andrew Cooper <andrew.cooper3@citrix.com>
  Anthony PERARD <anthony.perard@citrix.com>
  Brendan Cully <brendan@cs.ubc.ca>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Haitao Shan <haitao.shan@intel.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@novell.com>
  Jan Beulich <jbeulich@suse.com>
  Jonathan Davies <jonathan.davies@citrix.com>
  juergen.gross@ts.fujitsu.com
  Keir Fraser <keir@xen.org>
  Liu, Jinsong <jinsong.liu@intel.com>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
  Philipp Hahn <hahn@univention.de>
  Shriram Rajagopalan <rshriram@cs.ubc.ca>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang2 <wei.wang2@amd.com>
  Xudong Hao <xudong.hao@intel.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 1522 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 19:25:16 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 19:25:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZ642-0004ZC-J7; Fri, 09 Dec 2011 19:24:58 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RZ63z-0004YY-Pf
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 19:24:56 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-7.tower-182.messagelabs.com!1323458644!6559915!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyODgwMTA=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyODgwMTA=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31744 invoked from network); 9 Dec 2011 19:24:05 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-7.tower-182.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 9 Dec 2011 19:24:05 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1323458644; l=17446;
	s=domk; d=aepfle.de;
	h=To:From:Date:Subject:Content-Transfer-Encoding:MIME-Version:
	Content-Type:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=6kM/HX9BTJ56i4da50nyKR4f1TE=;
	b=upceiG0hXKg4TNMPszME7BqII5KFC6MDtFxCXw68tK4n/2Aa34+qvb2UKX0i64Pjw9J
	+0KsdxflGZQQgrN52R/qLNoie495+nzeopxmUeQDw29yB+DysISK+mj8jUxZuZ7ZS8KtQ
	3ZR4g/+b4jMLAf2q83/xd0AvqFKvPs7gX9c=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lk3c7qEGZD
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-094-126.pools.arcor-ip.net [84.57.94.126])
	by post.strato.de (mrclete mo18) (RZmta 26.14 AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id 5041a2nB9J8hRN
	for <xen-devel@lists.xensource.com>;
	Fri, 9 Dec 2011 20:23:58 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 0CA6E18636
	for <xen-devel@lists.xensource.com>;
	Fri,  9 Dec 2011 20:23:58 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: b25b2bcc2c6a987086bf37ec67a64d989813eb4d
Message-Id: <b25b2bcc2c6a987086bf.1323458635@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Fri, 09 Dec 2011 20:23:55 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH] mem_event: use wait queue when ring is full
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1323456817 -3600
# Node ID b25b2bcc2c6a987086bf37ec67a64d989813eb4d
# Parent  1c58bb664d8d55e475d179cb5f81693991859fc8
mem_event: use wait queue when ring is full

This change is based on an idea/patch from Adin Scannell.

If the ring is full, put the current vcpu to sleep if it belongs to the
target domain. The wakeup happens in the p2m_*_resume functions. Wakeup
will take the number of free slots into account.

A request from foreign domain has to succeed once a slot was claimed
because such vcpus can not sleep.

This change fixes also a bug in p2m_mem_paging_drop_page(). Up to now a
full ring will lead to harmless inconsistency in the pager.

v6:
  - take foreign requests into account before calling wake_up_nr()
  - call wake_up_nr() outside of ring lock
 - rename ->bit to ->pause_flag
 - update comment in mem_event_enable()

v5:
  - rename mem_event_check_ring() to mem_event_claim_slot()
  - rename mem_event_put_req_producers() to mem_event_release_slot()
  - add local/foreign request accounting
  - keep room for at least one guest request

v4:
 - fix off-by-one bug in _mem_event_put_request
 - add mem_event_wake_requesters() and use wake_up_nr()
 - rename mem_event_mark_and_pause() and mem_event_mark_and_pause() functions
 - req_producers counts foreign request producers, rename member

v3:
 - rename ->mem_event_bit to ->bit
 - remove me_ from new VPF_ defines

v2:
 - p2m_mem_paging_populate: move vcpu_pause after put_request, otherwise the
   vcpu will not wake_up after a wait_event because the pause_count was
   increased twice. Fixes guest hangs.
 - update free space check in _mem_event_put_request()
 - simplify mem_event_put_request()

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 1c58bb664d8d -r b25b2bcc2c6a xen/arch/x86/hvm/hvm.c
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -4172,8 +4172,8 @@ static int hvm_memory_event_traps(long p
     if ( (p & HVMPME_onchangeonly) && (value == old) )
         return 1;
     
-    rc = mem_event_check_ring(d, &d->mem_event->access);
-    if ( rc )
+    rc = mem_event_claim_slot(d, &d->mem_event->access);
+    if ( rc < 0 )
         return rc;
     
     memset(&req, 0, sizeof(req));
diff -r 1c58bb664d8d -r b25b2bcc2c6a xen/arch/x86/mm/mem_event.c
--- a/xen/arch/x86/mm/mem_event.c
+++ b/xen/arch/x86/mm/mem_event.c
@@ -23,6 +23,7 @@
 
 #include <asm/domain.h>
 #include <xen/event.h>
+#include <xen/wait.h>
 #include <asm/p2m.h>
 #include <asm/mem_event.h>
 #include <asm/mem_paging.h>
@@ -41,6 +42,7 @@ static int mem_event_enable(
     struct domain *d,
     xen_domctl_mem_event_op_t *mec,
     struct mem_event_domain *med,
+    int pause_flag,
     xen_event_channel_notification_t notification_fn)
 {
     int rc;
@@ -110,8 +112,12 @@ static int mem_event_enable(
 
     mem_event_ring_lock_init(med);
 
-    /* Wake any VCPUs paused for memory events */
-    mem_event_unpause_vcpus(d);
+    med->pause_flag = pause_flag;
+
+    init_waitqueue_head(&med->wq);
+
+    /* Wake any VCPUs waiting for the ring to appear */
+    mem_event_wake_waiters(d, med);
 
     return 0;
 
@@ -127,6 +133,9 @@ static int mem_event_enable(
 
 static int mem_event_disable(struct mem_event_domain *med)
 {
+    if (!list_empty(&med->wq.list))
+        return -EBUSY;
+
     unmap_domain_page(med->ring_page);
     med->ring_page = NULL;
 
@@ -136,13 +145,24 @@ static int mem_event_disable(struct mem_
     return 0;
 }
 
-void mem_event_put_request(struct domain *d, struct mem_event_domain *med, mem_event_request_t *req)
+static int _mem_event_put_request(struct domain *d,
+                                  struct mem_event_domain *med,
+                                  mem_event_request_t *req)
 {
     mem_event_front_ring_t *front_ring;
+    int free_req, claimed_req;
     RING_IDX req_prod;
 
     mem_event_ring_lock(med);
 
+    free_req = RING_FREE_REQUESTS(&med->front_ring);
+    /* Foreign requests must succeed because their vcpus can not sleep */
+    claimed_req = med->foreign_producers;
+    if ( !free_req || ( current->domain == d && free_req <= claimed_req ) ) {
+        mem_event_ring_unlock(med);
+        return 0;
+    }
+
     front_ring = &med->front_ring;
     req_prod = front_ring->req_prod_pvt;
 
@@ -156,14 +176,35 @@ void mem_event_put_request(struct domain
     memcpy(RING_GET_REQUEST(front_ring, req_prod), req, sizeof(*req));
     req_prod++;
 
+    /* Update accounting */
+    if ( current->domain == d )
+        med->target_producers--;
+    else
+        med->foreign_producers--;
+
     /* Update ring */
-    med->req_producers--;
     front_ring->req_prod_pvt = req_prod;
     RING_PUSH_REQUESTS(front_ring);
 
     mem_event_ring_unlock(med);
 
     notify_via_xen_event_channel(d, med->xen_port);
+
+    return 1;
+}
+
+void mem_event_put_request(struct domain *d, struct mem_event_domain *med,
+                           mem_event_request_t *req)
+{
+    /* Go to sleep if request came from guest */
+    if (current->domain == d) {
+        wait_event(med->wq, _mem_event_put_request(d, med, req));
+        return;
+    }
+    /* Ring was full anyway, unable to sleep in non-guest context */
+    if (!_mem_event_put_request(d, med, req))
+        printk("Failed to put memreq: d %u t %x f %x gfn %lx\n", d->domain_id,
+                req->type, req->flags, (unsigned long)req->gfn);
 }
 
 int mem_event_get_response(struct mem_event_domain *med, mem_event_response_t *rsp)
@@ -195,32 +236,97 @@ int mem_event_get_response(struct mem_ev
     return 1;
 }
 
-void mem_event_unpause_vcpus(struct domain *d)
+/**
+ * mem_event_wake_requesters - Wake vcpus waiting for room in the ring
+ * @d: guest domain
+ * @med: mem_event ring
+ *
+ * mem_event_wake_requesters() will wakeup vcpus waiting for room in the
+ * ring. Only as many as can place another request in the ring will
+ * resume execution.
+ */
+void mem_event_wake_requesters(struct mem_event_domain *med)
+{
+    int free_req;
+
+    mem_event_ring_lock(med);
+    free_req = RING_FREE_REQUESTS(&med->front_ring);
+    free_req -= med->foreign_producers;
+    mem_event_ring_unlock(med);
+
+    if ( free_req )
+        wake_up_nr(&med->wq, free_req);
+}
+
+/**
+ * mem_event_wake_waiters - Wake all vcpus waiting for the ring
+ * @d: guest domain
+ * @med: mem_event ring
+ *
+ * mem_event_wake_waiters() will wakeup all vcpus waiting for the ring to
+ * become available.
+ */
+void mem_event_wake_waiters(struct domain *d, struct mem_event_domain *med)
 {
     struct vcpu *v;
 
     for_each_vcpu ( d, v )
-        if ( test_and_clear_bit(_VPF_mem_event, &v->pause_flags) )
+        if ( test_and_clear_bit(med->pause_flag, &v->pause_flags) )
             vcpu_wake(v);
 }
 
-void mem_event_mark_and_pause(struct vcpu *v)
+/**
+ * mem_event_mark_and_sleep - Put vcpu to sleep
+ * @v: guest vcpu
+ * @med: mem_event ring
+ *
+ * mem_event_mark_and_sleep() tags vcpu and put it to sleep.
+ * The vcpu will resume execution in mem_event_wake_waiters().
+ */
+void mem_event_mark_and_sleep(struct vcpu *v, struct mem_event_domain *med)
 {
-    set_bit(_VPF_mem_event, &v->pause_flags);
+    set_bit(med->pause_flag, &v->pause_flags);
     vcpu_sleep_nosync(v);
 }
 
-void mem_event_put_req_producers(struct mem_event_domain *med)
+/**
+ * mem_event_release_slot - Release a claimed slot
+ * @med: mem_event ring
+ *
+ * mem_event_release_slot() releases a claimed slot in the mem_event ring.
+ */
+void mem_event_release_slot(struct domain *d, struct mem_event_domain *med)
 {
     mem_event_ring_lock(med);
-    med->req_producers--;
+    if ( current->domain == d )
+        med->target_producers--;
+    else
+        med->foreign_producers--;
     mem_event_ring_unlock(med);
 }
 
-int mem_event_check_ring(struct domain *d, struct mem_event_domain *med)
+/**
+ * mem_event_claim_slot - Check state of a mem_event ring
+ * @d: guest domain
+ * @med: mem_event ring
+ *
+ * Return codes: < 0: the ring is not yet configured
+ *                 0: the ring has some room
+ *               > 0: the ring is full
+ *
+ * mem_event_claim_slot() checks the state of the given mem_event ring.
+ * If the current vcpu belongs to the guest domain, the function assumes that
+ * mem_event_put_request() will sleep until the ring has room again.
+ * A guest can always place at least one request.
+ *
+ * If the current vcpu does not belong to the target domain the caller must try
+ * again until there is room. A slot is claimed and the caller can place a
+ * request. If the caller does not need to send a request, the claimed slot has
+ * to be released with mem_event_release_slot().
+ */
+int mem_event_claim_slot(struct domain *d, struct mem_event_domain *med)
 {
-    struct vcpu *curr = current;
-    int free_requests;
+    int free_req;
     int ring_full = 1;
 
     if ( !med->ring_page )
@@ -228,16 +334,17 @@ int mem_event_check_ring(struct domain *
 
     mem_event_ring_lock(med);
 
-    free_requests = RING_FREE_REQUESTS(&med->front_ring);
-    if ( med->req_producers < free_requests )
+    free_req = RING_FREE_REQUESTS(&med->front_ring);
+
+    if ( current->domain == d ) {
+        med->target_producers++;
+        ring_full = 0;
+    } else if ( med->foreign_producers + med->target_producers + 1 < free_req )
     {
-        med->req_producers++;
+        med->foreign_producers++;
         ring_full = 0;
     }
 
-    if ( ring_full && (curr->domain == d) )
-        mem_event_mark_and_pause(curr);
-
     mem_event_ring_unlock(med);
 
     return ring_full;
@@ -316,7 +423,7 @@ int mem_event_domctl(struct domain *d, x
             if ( p2m->pod.entry_count )
                 break;
 
-            rc = mem_event_enable(d, mec, med, mem_paging_notification);
+            rc = mem_event_enable(d, mec, med, _VPF_mem_paging, mem_paging_notification);
         }
         break;
 
@@ -355,7 +462,7 @@ int mem_event_domctl(struct domain *d, x
             if ( boot_cpu_data.x86_vendor != X86_VENDOR_INTEL )
                 break;
 
-            rc = mem_event_enable(d, mec, med, mem_access_notification);
+            rc = mem_event_enable(d, mec, med, _VPF_mem_access, mem_access_notification);
         }
         break;
 
diff -r 1c58bb664d8d -r b25b2bcc2c6a xen/arch/x86/mm/mem_sharing.c
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -253,18 +253,10 @@ static void mem_sharing_audit(void)
 #endif
 
 
-static struct page_info* mem_sharing_alloc_page(struct domain *d, 
-                                                unsigned long gfn)
+static void mem_sharing_notify_helper(struct domain *d, unsigned long gfn)
 {
-    struct page_info* page;
     struct vcpu *v = current;
-    mem_event_request_t req;
-
-    page = alloc_domheap_page(d, 0); 
-    if(page != NULL) return page;
-
-    memset(&req, 0, sizeof(req));
-    req.type = MEM_EVENT_TYPE_SHARED;
+    mem_event_request_t req = { .type = MEM_EVENT_TYPE_SHARED };
 
     if ( v->domain != d )
     {
@@ -275,20 +267,18 @@ static struct page_info* mem_sharing_all
         gdprintk(XENLOG_ERR, 
                  "Failed alloc on unshare path for foreign (%d) lookup\n",
                  d->domain_id);
-        return page;
+        return;
     }
 
-    vcpu_pause_nosync(v);
-    req.flags |= MEM_EVENT_FLAG_VCPU_PAUSED;
+    if (mem_event_claim_slot(d, &d->mem_event->share) < 0)
+        return;
 
-    if(mem_event_check_ring(d, &d->mem_event->share)) return page;
-
+    req.flags = MEM_EVENT_FLAG_VCPU_PAUSED;
     req.gfn = gfn;
     req.p2mt = p2m_ram_shared;
     req.vcpu_id = v->vcpu_id;
     mem_event_put_request(d, &d->mem_event->share, &req);
-
-    return page;
+    vcpu_pause_nosync(v);
 }
 
 unsigned int mem_sharing_get_nr_saved_mfns(void)
@@ -656,7 +646,7 @@ gfn_found:
     if(ret == 0) goto private_page_found;
         
     old_page = page;
-    page = mem_sharing_alloc_page(d, gfn);
+    page = alloc_domheap_page(d, 0);
     if(!page) 
     {
         /* We've failed to obtain memory for private page. Need to re-add the
@@ -664,6 +654,7 @@ gfn_found:
         list_add(&gfn_info->list, &hash_entry->gfns);
         put_gfn(d, gfn);
         shr_unlock();
+        mem_sharing_notify_helper(d, gfn);
         return -ENOMEM;
     }
 
diff -r 1c58bb664d8d -r b25b2bcc2c6a xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -861,20 +861,12 @@ int p2m_mem_paging_evict(struct domain *
  */
 void p2m_mem_paging_drop_page(struct domain *d, unsigned long gfn)
 {
-    struct vcpu *v = current;
-    mem_event_request_t req;
+    mem_event_request_t req = { .type = MEM_EVENT_TYPE_PAGING, .gfn = gfn };
 
-    /* Check that there's space on the ring for this request */
-    if ( mem_event_check_ring(d, &d->mem_event->paging) == 0)
-    {
-        /* Send release notification to pager */
-        memset(&req, 0, sizeof(req));
-        req.flags |= MEM_EVENT_FLAG_DROP_PAGE;
-        req.gfn = gfn;
-        req.vcpu_id = v->vcpu_id;
+    /* Send release notification to pager */
+    req.flags = MEM_EVENT_FLAG_DROP_PAGE;
 
-        mem_event_put_request(d, &d->mem_event->paging, &req);
-    }
+    mem_event_put_request(d, &d->mem_event->paging, &req);
 }
 
 /**
@@ -908,7 +900,7 @@ void p2m_mem_paging_populate(struct doma
     struct p2m_domain *p2m = p2m_get_hostp2m(d);
 
     /* Check that there's space on the ring for this request */
-    if ( mem_event_check_ring(d, &d->mem_event->paging) )
+    if ( mem_event_claim_slot(d, &d->mem_event->paging) )
         return;
 
     memset(&req, 0, sizeof(req));
@@ -938,7 +930,7 @@ void p2m_mem_paging_populate(struct doma
     else if ( p2mt != p2m_ram_paging_out && p2mt != p2m_ram_paged )
     {
         /* gfn is already on its way back and vcpu is not paused */
-        mem_event_put_req_producers(&d->mem_event->paging);
+        mem_event_release_slot(d, &d->mem_event->paging);
         return;
     }
 
@@ -1080,8 +1072,8 @@ void p2m_mem_paging_resume(struct domain
             vcpu_unpause(d->vcpu[rsp.vcpu_id]);
     }
 
-    /* Unpause any domains that were paused because the ring was full */
-    mem_event_unpause_vcpus(d);
+    /* Wake vcpus waiting for room in the ring */
+    mem_event_wake_requesters(&d->mem_event->paging);
 }
 
 bool_t p2m_mem_access_check(unsigned long gpa, bool_t gla_valid, unsigned long gla, 
@@ -1115,7 +1107,7 @@ bool_t p2m_mem_access_check(unsigned lon
     p2m_unlock(p2m);
 
     /* Otherwise, check if there is a memory event listener, and send the message along */
-    res = mem_event_check_ring(d, &d->mem_event->access);
+    res = mem_event_claim_slot(d, &d->mem_event->access);
     if ( res < 0 ) 
     {
         /* No listener */
@@ -1125,7 +1117,7 @@ bool_t p2m_mem_access_check(unsigned lon
                    "Memory access permissions failure, no mem_event listener: pausing VCPU %d, dom %d\n",
                    v->vcpu_id, d->domain_id);
 
-            mem_event_mark_and_pause(v);
+            mem_event_mark_and_sleep(v, &d->mem_event->access);
         }
         else
         {
@@ -1186,9 +1178,11 @@ void p2m_mem_access_resume(struct domain
             vcpu_unpause(d->vcpu[rsp.vcpu_id]);
     }
 
-    /* Unpause any domains that were paused because the ring was full or no listener 
-     * was available */
-    mem_event_unpause_vcpus(d);
+    /* Wake vcpus waiting for room in the ring */
+    mem_event_wake_requesters(&d->mem_event->access);
+
+    /* Unpause all vcpus that were paused because no listener was available */
+    mem_event_wake_waiters(d, &d->mem_event->access);
 }
 
 
diff -r 1c58bb664d8d -r b25b2bcc2c6a xen/include/asm-x86/mem_event.h
--- a/xen/include/asm-x86/mem_event.h
+++ b/xen/include/asm-x86/mem_event.h
@@ -24,13 +24,13 @@
 #ifndef __MEM_EVENT_H__
 #define __MEM_EVENT_H__
 
-/* Pauses VCPU while marking pause flag for mem event */
-void mem_event_mark_and_pause(struct vcpu *v);
-int mem_event_check_ring(struct domain *d, struct mem_event_domain *med);
-void mem_event_put_req_producers(struct mem_event_domain *med);
+int mem_event_claim_slot(struct domain *d, struct mem_event_domain *med);
+void mem_event_release_slot(struct domain *d, struct mem_event_domain *med);
 void mem_event_put_request(struct domain *d, struct mem_event_domain *med, mem_event_request_t *req);
 int mem_event_get_response(struct mem_event_domain *med, mem_event_response_t *rsp);
-void mem_event_unpause_vcpus(struct domain *d);
+void mem_event_wake_requesters(struct mem_event_domain *med);
+void mem_event_wake_waiters(struct domain *d, struct mem_event_domain *med);
+void mem_event_mark_and_sleep(struct vcpu *v, struct mem_event_domain *med);
 
 int mem_event_domctl(struct domain *d, xen_domctl_mem_event_op_t *mec,
                      XEN_GUEST_HANDLE(void) u_domctl);
diff -r 1c58bb664d8d -r b25b2bcc2c6a xen/include/xen/sched.h
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -14,6 +14,7 @@
 #include <xen/nodemask.h>
 #include <xen/radix-tree.h>
 #include <xen/multicall.h>
+#include <xen/wait.h>
 #include <public/xen.h>
 #include <public/domctl.h>
 #include <public/sysctl.h>
@@ -183,7 +184,8 @@ struct mem_event_domain
 {
     /* ring lock */
     spinlock_t ring_lock;
-    unsigned int req_producers;
+    unsigned short foreign_producers;
+    unsigned short target_producers;
     /* shared page */
     mem_event_shared_page_t *shared_page;
     /* shared ring page */
@@ -192,6 +194,10 @@ struct mem_event_domain
     mem_event_front_ring_t front_ring;
     /* event channel port (vcpu0 only) */
     int xen_port;
+    /* mem_event bit for vcpu->pause_flags */
+    int pause_flag;
+    /* list of vcpus waiting for room in the ring */
+    struct waitqueue_head wq;
 };
 
 struct mem_event_per_domain
@@ -615,9 +621,12 @@ static inline struct domain *next_domain
  /* VCPU affinity has changed: migrating to a new CPU. */
 #define _VPF_migrating       3
 #define VPF_migrating        (1UL<<_VPF_migrating)
- /* VCPU is blocked on memory-event ring. */
-#define _VPF_mem_event       4
-#define VPF_mem_event        (1UL<<_VPF_mem_event)
+ /* VCPU is blocked due to missing mem_paging ring. */
+#define _VPF_mem_paging      4
+#define VPF_mem_paging       (1UL<<_VPF_mem_paging)
+ /* VCPU is blocked due to missing mem_access ring. */
+#define _VPF_mem_access      5
+#define VPF_mem_access       (1UL<<_VPF_mem_access)
 
 static inline int vcpu_runnable(struct vcpu *v)
 {

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 19:25:16 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 19:25:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZ642-0004ZC-J7; Fri, 09 Dec 2011 19:24:58 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RZ63z-0004YY-Pf
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 19:24:56 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-7.tower-182.messagelabs.com!1323458644!6559915!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyODgwMTA=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyODgwMTA=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31744 invoked from network); 9 Dec 2011 19:24:05 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-7.tower-182.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 9 Dec 2011 19:24:05 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1323458644; l=17446;
	s=domk; d=aepfle.de;
	h=To:From:Date:Subject:Content-Transfer-Encoding:MIME-Version:
	Content-Type:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=6kM/HX9BTJ56i4da50nyKR4f1TE=;
	b=upceiG0hXKg4TNMPszME7BqII5KFC6MDtFxCXw68tK4n/2Aa34+qvb2UKX0i64Pjw9J
	+0KsdxflGZQQgrN52R/qLNoie495+nzeopxmUeQDw29yB+DysISK+mj8jUxZuZ7ZS8KtQ
	3ZR4g/+b4jMLAf2q83/xd0AvqFKvPs7gX9c=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lk3c7qEGZD
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-094-126.pools.arcor-ip.net [84.57.94.126])
	by post.strato.de (mrclete mo18) (RZmta 26.14 AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id 5041a2nB9J8hRN
	for <xen-devel@lists.xensource.com>;
	Fri, 9 Dec 2011 20:23:58 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 0CA6E18636
	for <xen-devel@lists.xensource.com>;
	Fri,  9 Dec 2011 20:23:58 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: b25b2bcc2c6a987086bf37ec67a64d989813eb4d
Message-Id: <b25b2bcc2c6a987086bf.1323458635@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Fri, 09 Dec 2011 20:23:55 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH] mem_event: use wait queue when ring is full
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1323456817 -3600
# Node ID b25b2bcc2c6a987086bf37ec67a64d989813eb4d
# Parent  1c58bb664d8d55e475d179cb5f81693991859fc8
mem_event: use wait queue when ring is full

This change is based on an idea/patch from Adin Scannell.

If the ring is full, put the current vcpu to sleep if it belongs to the
target domain. The wakeup happens in the p2m_*_resume functions. Wakeup
will take the number of free slots into account.

A request from foreign domain has to succeed once a slot was claimed
because such vcpus can not sleep.

This change fixes also a bug in p2m_mem_paging_drop_page(). Up to now a
full ring will lead to harmless inconsistency in the pager.

v6:
  - take foreign requests into account before calling wake_up_nr()
  - call wake_up_nr() outside of ring lock
 - rename ->bit to ->pause_flag
 - update comment in mem_event_enable()

v5:
  - rename mem_event_check_ring() to mem_event_claim_slot()
  - rename mem_event_put_req_producers() to mem_event_release_slot()
  - add local/foreign request accounting
  - keep room for at least one guest request

v4:
 - fix off-by-one bug in _mem_event_put_request
 - add mem_event_wake_requesters() and use wake_up_nr()
 - rename mem_event_mark_and_pause() and mem_event_mark_and_pause() functions
 - req_producers counts foreign request producers, rename member

v3:
 - rename ->mem_event_bit to ->bit
 - remove me_ from new VPF_ defines

v2:
 - p2m_mem_paging_populate: move vcpu_pause after put_request, otherwise the
   vcpu will not wake_up after a wait_event because the pause_count was
   increased twice. Fixes guest hangs.
 - update free space check in _mem_event_put_request()
 - simplify mem_event_put_request()

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 1c58bb664d8d -r b25b2bcc2c6a xen/arch/x86/hvm/hvm.c
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -4172,8 +4172,8 @@ static int hvm_memory_event_traps(long p
     if ( (p & HVMPME_onchangeonly) && (value == old) )
         return 1;
     
-    rc = mem_event_check_ring(d, &d->mem_event->access);
-    if ( rc )
+    rc = mem_event_claim_slot(d, &d->mem_event->access);
+    if ( rc < 0 )
         return rc;
     
     memset(&req, 0, sizeof(req));
diff -r 1c58bb664d8d -r b25b2bcc2c6a xen/arch/x86/mm/mem_event.c
--- a/xen/arch/x86/mm/mem_event.c
+++ b/xen/arch/x86/mm/mem_event.c
@@ -23,6 +23,7 @@
 
 #include <asm/domain.h>
 #include <xen/event.h>
+#include <xen/wait.h>
 #include <asm/p2m.h>
 #include <asm/mem_event.h>
 #include <asm/mem_paging.h>
@@ -41,6 +42,7 @@ static int mem_event_enable(
     struct domain *d,
     xen_domctl_mem_event_op_t *mec,
     struct mem_event_domain *med,
+    int pause_flag,
     xen_event_channel_notification_t notification_fn)
 {
     int rc;
@@ -110,8 +112,12 @@ static int mem_event_enable(
 
     mem_event_ring_lock_init(med);
 
-    /* Wake any VCPUs paused for memory events */
-    mem_event_unpause_vcpus(d);
+    med->pause_flag = pause_flag;
+
+    init_waitqueue_head(&med->wq);
+
+    /* Wake any VCPUs waiting for the ring to appear */
+    mem_event_wake_waiters(d, med);
 
     return 0;
 
@@ -127,6 +133,9 @@ static int mem_event_enable(
 
 static int mem_event_disable(struct mem_event_domain *med)
 {
+    if (!list_empty(&med->wq.list))
+        return -EBUSY;
+
     unmap_domain_page(med->ring_page);
     med->ring_page = NULL;
 
@@ -136,13 +145,24 @@ static int mem_event_disable(struct mem_
     return 0;
 }
 
-void mem_event_put_request(struct domain *d, struct mem_event_domain *med, mem_event_request_t *req)
+static int _mem_event_put_request(struct domain *d,
+                                  struct mem_event_domain *med,
+                                  mem_event_request_t *req)
 {
     mem_event_front_ring_t *front_ring;
+    int free_req, claimed_req;
     RING_IDX req_prod;
 
     mem_event_ring_lock(med);
 
+    free_req = RING_FREE_REQUESTS(&med->front_ring);
+    /* Foreign requests must succeed because their vcpus can not sleep */
+    claimed_req = med->foreign_producers;
+    if ( !free_req || ( current->domain == d && free_req <= claimed_req ) ) {
+        mem_event_ring_unlock(med);
+        return 0;
+    }
+
     front_ring = &med->front_ring;
     req_prod = front_ring->req_prod_pvt;
 
@@ -156,14 +176,35 @@ void mem_event_put_request(struct domain
     memcpy(RING_GET_REQUEST(front_ring, req_prod), req, sizeof(*req));
     req_prod++;
 
+    /* Update accounting */
+    if ( current->domain == d )
+        med->target_producers--;
+    else
+        med->foreign_producers--;
+
     /* Update ring */
-    med->req_producers--;
     front_ring->req_prod_pvt = req_prod;
     RING_PUSH_REQUESTS(front_ring);
 
     mem_event_ring_unlock(med);
 
     notify_via_xen_event_channel(d, med->xen_port);
+
+    return 1;
+}
+
+void mem_event_put_request(struct domain *d, struct mem_event_domain *med,
+                           mem_event_request_t *req)
+{
+    /* Go to sleep if request came from guest */
+    if (current->domain == d) {
+        wait_event(med->wq, _mem_event_put_request(d, med, req));
+        return;
+    }
+    /* Ring was full anyway, unable to sleep in non-guest context */
+    if (!_mem_event_put_request(d, med, req))
+        printk("Failed to put memreq: d %u t %x f %x gfn %lx\n", d->domain_id,
+                req->type, req->flags, (unsigned long)req->gfn);
 }
 
 int mem_event_get_response(struct mem_event_domain *med, mem_event_response_t *rsp)
@@ -195,32 +236,97 @@ int mem_event_get_response(struct mem_ev
     return 1;
 }
 
-void mem_event_unpause_vcpus(struct domain *d)
+/**
+ * mem_event_wake_requesters - Wake vcpus waiting for room in the ring
+ * @d: guest domain
+ * @med: mem_event ring
+ *
+ * mem_event_wake_requesters() will wakeup vcpus waiting for room in the
+ * ring. Only as many as can place another request in the ring will
+ * resume execution.
+ */
+void mem_event_wake_requesters(struct mem_event_domain *med)
+{
+    int free_req;
+
+    mem_event_ring_lock(med);
+    free_req = RING_FREE_REQUESTS(&med->front_ring);
+    free_req -= med->foreign_producers;
+    mem_event_ring_unlock(med);
+
+    if ( free_req )
+        wake_up_nr(&med->wq, free_req);
+}
+
+/**
+ * mem_event_wake_waiters - Wake all vcpus waiting for the ring
+ * @d: guest domain
+ * @med: mem_event ring
+ *
+ * mem_event_wake_waiters() will wakeup all vcpus waiting for the ring to
+ * become available.
+ */
+void mem_event_wake_waiters(struct domain *d, struct mem_event_domain *med)
 {
     struct vcpu *v;
 
     for_each_vcpu ( d, v )
-        if ( test_and_clear_bit(_VPF_mem_event, &v->pause_flags) )
+        if ( test_and_clear_bit(med->pause_flag, &v->pause_flags) )
             vcpu_wake(v);
 }
 
-void mem_event_mark_and_pause(struct vcpu *v)
+/**
+ * mem_event_mark_and_sleep - Put vcpu to sleep
+ * @v: guest vcpu
+ * @med: mem_event ring
+ *
+ * mem_event_mark_and_sleep() tags vcpu and put it to sleep.
+ * The vcpu will resume execution in mem_event_wake_waiters().
+ */
+void mem_event_mark_and_sleep(struct vcpu *v, struct mem_event_domain *med)
 {
-    set_bit(_VPF_mem_event, &v->pause_flags);
+    set_bit(med->pause_flag, &v->pause_flags);
     vcpu_sleep_nosync(v);
 }
 
-void mem_event_put_req_producers(struct mem_event_domain *med)
+/**
+ * mem_event_release_slot - Release a claimed slot
+ * @med: mem_event ring
+ *
+ * mem_event_release_slot() releases a claimed slot in the mem_event ring.
+ */
+void mem_event_release_slot(struct domain *d, struct mem_event_domain *med)
 {
     mem_event_ring_lock(med);
-    med->req_producers--;
+    if ( current->domain == d )
+        med->target_producers--;
+    else
+        med->foreign_producers--;
     mem_event_ring_unlock(med);
 }
 
-int mem_event_check_ring(struct domain *d, struct mem_event_domain *med)
+/**
+ * mem_event_claim_slot - Check state of a mem_event ring
+ * @d: guest domain
+ * @med: mem_event ring
+ *
+ * Return codes: < 0: the ring is not yet configured
+ *                 0: the ring has some room
+ *               > 0: the ring is full
+ *
+ * mem_event_claim_slot() checks the state of the given mem_event ring.
+ * If the current vcpu belongs to the guest domain, the function assumes that
+ * mem_event_put_request() will sleep until the ring has room again.
+ * A guest can always place at least one request.
+ *
+ * If the current vcpu does not belong to the target domain the caller must try
+ * again until there is room. A slot is claimed and the caller can place a
+ * request. If the caller does not need to send a request, the claimed slot has
+ * to be released with mem_event_release_slot().
+ */
+int mem_event_claim_slot(struct domain *d, struct mem_event_domain *med)
 {
-    struct vcpu *curr = current;
-    int free_requests;
+    int free_req;
     int ring_full = 1;
 
     if ( !med->ring_page )
@@ -228,16 +334,17 @@ int mem_event_check_ring(struct domain *
 
     mem_event_ring_lock(med);
 
-    free_requests = RING_FREE_REQUESTS(&med->front_ring);
-    if ( med->req_producers < free_requests )
+    free_req = RING_FREE_REQUESTS(&med->front_ring);
+
+    if ( current->domain == d ) {
+        med->target_producers++;
+        ring_full = 0;
+    } else if ( med->foreign_producers + med->target_producers + 1 < free_req )
     {
-        med->req_producers++;
+        med->foreign_producers++;
         ring_full = 0;
     }
 
-    if ( ring_full && (curr->domain == d) )
-        mem_event_mark_and_pause(curr);
-
     mem_event_ring_unlock(med);
 
     return ring_full;
@@ -316,7 +423,7 @@ int mem_event_domctl(struct domain *d, x
             if ( p2m->pod.entry_count )
                 break;
 
-            rc = mem_event_enable(d, mec, med, mem_paging_notification);
+            rc = mem_event_enable(d, mec, med, _VPF_mem_paging, mem_paging_notification);
         }
         break;
 
@@ -355,7 +462,7 @@ int mem_event_domctl(struct domain *d, x
             if ( boot_cpu_data.x86_vendor != X86_VENDOR_INTEL )
                 break;
 
-            rc = mem_event_enable(d, mec, med, mem_access_notification);
+            rc = mem_event_enable(d, mec, med, _VPF_mem_access, mem_access_notification);
         }
         break;
 
diff -r 1c58bb664d8d -r b25b2bcc2c6a xen/arch/x86/mm/mem_sharing.c
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -253,18 +253,10 @@ static void mem_sharing_audit(void)
 #endif
 
 
-static struct page_info* mem_sharing_alloc_page(struct domain *d, 
-                                                unsigned long gfn)
+static void mem_sharing_notify_helper(struct domain *d, unsigned long gfn)
 {
-    struct page_info* page;
     struct vcpu *v = current;
-    mem_event_request_t req;
-
-    page = alloc_domheap_page(d, 0); 
-    if(page != NULL) return page;
-
-    memset(&req, 0, sizeof(req));
-    req.type = MEM_EVENT_TYPE_SHARED;
+    mem_event_request_t req = { .type = MEM_EVENT_TYPE_SHARED };
 
     if ( v->domain != d )
     {
@@ -275,20 +267,18 @@ static struct page_info* mem_sharing_all
         gdprintk(XENLOG_ERR, 
                  "Failed alloc on unshare path for foreign (%d) lookup\n",
                  d->domain_id);
-        return page;
+        return;
     }
 
-    vcpu_pause_nosync(v);
-    req.flags |= MEM_EVENT_FLAG_VCPU_PAUSED;
+    if (mem_event_claim_slot(d, &d->mem_event->share) < 0)
+        return;
 
-    if(mem_event_check_ring(d, &d->mem_event->share)) return page;
-
+    req.flags = MEM_EVENT_FLAG_VCPU_PAUSED;
     req.gfn = gfn;
     req.p2mt = p2m_ram_shared;
     req.vcpu_id = v->vcpu_id;
     mem_event_put_request(d, &d->mem_event->share, &req);
-
-    return page;
+    vcpu_pause_nosync(v);
 }
 
 unsigned int mem_sharing_get_nr_saved_mfns(void)
@@ -656,7 +646,7 @@ gfn_found:
     if(ret == 0) goto private_page_found;
         
     old_page = page;
-    page = mem_sharing_alloc_page(d, gfn);
+    page = alloc_domheap_page(d, 0);
     if(!page) 
     {
         /* We've failed to obtain memory for private page. Need to re-add the
@@ -664,6 +654,7 @@ gfn_found:
         list_add(&gfn_info->list, &hash_entry->gfns);
         put_gfn(d, gfn);
         shr_unlock();
+        mem_sharing_notify_helper(d, gfn);
         return -ENOMEM;
     }
 
diff -r 1c58bb664d8d -r b25b2bcc2c6a xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -861,20 +861,12 @@ int p2m_mem_paging_evict(struct domain *
  */
 void p2m_mem_paging_drop_page(struct domain *d, unsigned long gfn)
 {
-    struct vcpu *v = current;
-    mem_event_request_t req;
+    mem_event_request_t req = { .type = MEM_EVENT_TYPE_PAGING, .gfn = gfn };
 
-    /* Check that there's space on the ring for this request */
-    if ( mem_event_check_ring(d, &d->mem_event->paging) == 0)
-    {
-        /* Send release notification to pager */
-        memset(&req, 0, sizeof(req));
-        req.flags |= MEM_EVENT_FLAG_DROP_PAGE;
-        req.gfn = gfn;
-        req.vcpu_id = v->vcpu_id;
+    /* Send release notification to pager */
+    req.flags = MEM_EVENT_FLAG_DROP_PAGE;
 
-        mem_event_put_request(d, &d->mem_event->paging, &req);
-    }
+    mem_event_put_request(d, &d->mem_event->paging, &req);
 }
 
 /**
@@ -908,7 +900,7 @@ void p2m_mem_paging_populate(struct doma
     struct p2m_domain *p2m = p2m_get_hostp2m(d);
 
     /* Check that there's space on the ring for this request */
-    if ( mem_event_check_ring(d, &d->mem_event->paging) )
+    if ( mem_event_claim_slot(d, &d->mem_event->paging) )
         return;
 
     memset(&req, 0, sizeof(req));
@@ -938,7 +930,7 @@ void p2m_mem_paging_populate(struct doma
     else if ( p2mt != p2m_ram_paging_out && p2mt != p2m_ram_paged )
     {
         /* gfn is already on its way back and vcpu is not paused */
-        mem_event_put_req_producers(&d->mem_event->paging);
+        mem_event_release_slot(d, &d->mem_event->paging);
         return;
     }
 
@@ -1080,8 +1072,8 @@ void p2m_mem_paging_resume(struct domain
             vcpu_unpause(d->vcpu[rsp.vcpu_id]);
     }
 
-    /* Unpause any domains that were paused because the ring was full */
-    mem_event_unpause_vcpus(d);
+    /* Wake vcpus waiting for room in the ring */
+    mem_event_wake_requesters(&d->mem_event->paging);
 }
 
 bool_t p2m_mem_access_check(unsigned long gpa, bool_t gla_valid, unsigned long gla, 
@@ -1115,7 +1107,7 @@ bool_t p2m_mem_access_check(unsigned lon
     p2m_unlock(p2m);
 
     /* Otherwise, check if there is a memory event listener, and send the message along */
-    res = mem_event_check_ring(d, &d->mem_event->access);
+    res = mem_event_claim_slot(d, &d->mem_event->access);
     if ( res < 0 ) 
     {
         /* No listener */
@@ -1125,7 +1117,7 @@ bool_t p2m_mem_access_check(unsigned lon
                    "Memory access permissions failure, no mem_event listener: pausing VCPU %d, dom %d\n",
                    v->vcpu_id, d->domain_id);
 
-            mem_event_mark_and_pause(v);
+            mem_event_mark_and_sleep(v, &d->mem_event->access);
         }
         else
         {
@@ -1186,9 +1178,11 @@ void p2m_mem_access_resume(struct domain
             vcpu_unpause(d->vcpu[rsp.vcpu_id]);
     }
 
-    /* Unpause any domains that were paused because the ring was full or no listener 
-     * was available */
-    mem_event_unpause_vcpus(d);
+    /* Wake vcpus waiting for room in the ring */
+    mem_event_wake_requesters(&d->mem_event->access);
+
+    /* Unpause all vcpus that were paused because no listener was available */
+    mem_event_wake_waiters(d, &d->mem_event->access);
 }
 
 
diff -r 1c58bb664d8d -r b25b2bcc2c6a xen/include/asm-x86/mem_event.h
--- a/xen/include/asm-x86/mem_event.h
+++ b/xen/include/asm-x86/mem_event.h
@@ -24,13 +24,13 @@
 #ifndef __MEM_EVENT_H__
 #define __MEM_EVENT_H__
 
-/* Pauses VCPU while marking pause flag for mem event */
-void mem_event_mark_and_pause(struct vcpu *v);
-int mem_event_check_ring(struct domain *d, struct mem_event_domain *med);
-void mem_event_put_req_producers(struct mem_event_domain *med);
+int mem_event_claim_slot(struct domain *d, struct mem_event_domain *med);
+void mem_event_release_slot(struct domain *d, struct mem_event_domain *med);
 void mem_event_put_request(struct domain *d, struct mem_event_domain *med, mem_event_request_t *req);
 int mem_event_get_response(struct mem_event_domain *med, mem_event_response_t *rsp);
-void mem_event_unpause_vcpus(struct domain *d);
+void mem_event_wake_requesters(struct mem_event_domain *med);
+void mem_event_wake_waiters(struct domain *d, struct mem_event_domain *med);
+void mem_event_mark_and_sleep(struct vcpu *v, struct mem_event_domain *med);
 
 int mem_event_domctl(struct domain *d, xen_domctl_mem_event_op_t *mec,
                      XEN_GUEST_HANDLE(void) u_domctl);
diff -r 1c58bb664d8d -r b25b2bcc2c6a xen/include/xen/sched.h
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -14,6 +14,7 @@
 #include <xen/nodemask.h>
 #include <xen/radix-tree.h>
 #include <xen/multicall.h>
+#include <xen/wait.h>
 #include <public/xen.h>
 #include <public/domctl.h>
 #include <public/sysctl.h>
@@ -183,7 +184,8 @@ struct mem_event_domain
 {
     /* ring lock */
     spinlock_t ring_lock;
-    unsigned int req_producers;
+    unsigned short foreign_producers;
+    unsigned short target_producers;
     /* shared page */
     mem_event_shared_page_t *shared_page;
     /* shared ring page */
@@ -192,6 +194,10 @@ struct mem_event_domain
     mem_event_front_ring_t front_ring;
     /* event channel port (vcpu0 only) */
     int xen_port;
+    /* mem_event bit for vcpu->pause_flags */
+    int pause_flag;
+    /* list of vcpus waiting for room in the ring */
+    struct waitqueue_head wq;
 };
 
 struct mem_event_per_domain
@@ -615,9 +621,12 @@ static inline struct domain *next_domain
  /* VCPU affinity has changed: migrating to a new CPU. */
 #define _VPF_migrating       3
 #define VPF_migrating        (1UL<<_VPF_migrating)
- /* VCPU is blocked on memory-event ring. */
-#define _VPF_mem_event       4
-#define VPF_mem_event        (1UL<<_VPF_mem_event)
+ /* VCPU is blocked due to missing mem_paging ring. */
+#define _VPF_mem_paging      4
+#define VPF_mem_paging       (1UL<<_VPF_mem_paging)
+ /* VCPU is blocked due to missing mem_access ring. */
+#define _VPF_mem_access      5
+#define VPF_mem_access       (1UL<<_VPF_mem_access)
 
 static inline int vcpu_runnable(struct vcpu *v)
 {

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 19:51:04 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 19:51:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZ6Sw-00058G-SN; Fri, 09 Dec 2011 19:50:42 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <george.shuklin@gmail.com>) id 1RZ6Sv-000588-Hy
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 19:50:41 +0000
X-Env-Sender: george.shuklin@gmail.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1323460191!6621074!1
X-Originating-IP: [209.85.214.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24492 invoked from network); 9 Dec 2011 19:49:51 -0000
Received: from mail-bw0-f43.google.com (HELO mail-bw0-f43.google.com)
	(209.85.214.43)
	by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 19:49:51 -0000
Received: by bkbzs2 with SMTP id zs2so9818717bkb.30
	for <xen-devel@lists.xensource.com>;
	Fri, 09 Dec 2011 11:49:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=message-id:date:from:user-agent:mime-version:to:subject
	:content-type:content-transfer-encoding;
	bh=UeThKYBa9XTx3K3o9i0rXljkUc16o3ISsitUUA5iZPQ=;
	b=OCtTUsQl4+lBruQtYW2pz/iZD6l11Ls7sqgLVLRC+04ryKUhfgo1x3SYiipFr6Q4m4
	BVXKrIs8OZAyFlUc4jO7qXNGA4GWnvDs/cJkRXO2vmUlrYGQ/SzpG9J3Xl8w39viiVvV
	ACf9oumxczi0vRmyLc2hwwBXbDBJFI35YNRN0=
Received: by 10.204.146.79 with SMTP id g15mr4517928bkv.121.1323460191426;
	Fri, 09 Dec 2011 11:49:51 -0800 (PST)
Received: from [192.168.0.220] (desunote.ru. [95.161.2.76])
	by mx.google.com with ESMTPS id e18sm12282721bkr.15.2011.12.09.11.49.49
	(version=SSLv3 cipher=OTHER); Fri, 09 Dec 2011 11:49:50 -0800 (PST)
Message-ID: <4EE2665C.8090602@gmail.com>
Date: Fri, 09 Dec 2011 23:49:48 +0400
From: George Shuklin <george.shuklin@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:9.0) Gecko/20111209 Thunderbird/9.0
MIME-Version: 1.0
To: xen-devel@lists.xensource.com, xen-hosting@googlegroups.com
Subject: [Xen-devel] bug in xenstored? No notification to subscription on
	@introduceDomain
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Good day.

I think I met some strange bug in xenstored.

I using XCP for long time and all that time we have some funny bug we 
was not able to debug enough due product environment and very low chance 
to appear, now we was able to catch it in testing environment and done 
some research.

We have python application running in dom0 and waiting domain 
appearance. This implemented this via subscription to @introduceDomain 
xenstore key. Under some conditions we stops to receive notification on 
subscription. If we ran application as second instance it will receive 
that notification, if we restart application it will  receive too.

I unable to pinpoint exact condition for this, but this
a) Happens occasionally but consistently (about once a month in farm of 
50 hosts at least at one host)
b) Not related to xenstored uptime
c) Not related to load on xen or dom0
d) Not related to amount of domains
e) Occur at least at XCP 0.5, 1.0 and 1.1 (I don't know how to get 
version from xenstored)

Last time I got that on two hosts in lab at same time (with single guest 
domain without any high load) and done some experiments - so I can say 
exactly I wrote above.

The pieces from python code we ran:

from xen.lowlevel.xs import xs
conn = xs.xs()
conn.watch("@introduceDomain", "+")
conn.watch("@releaseDomain", "-")
conn.read_watch()

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 19:51:04 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 19:51:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZ6Sw-00058G-SN; Fri, 09 Dec 2011 19:50:42 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <george.shuklin@gmail.com>) id 1RZ6Sv-000588-Hy
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 19:50:41 +0000
X-Env-Sender: george.shuklin@gmail.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1323460191!6621074!1
X-Originating-IP: [209.85.214.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24492 invoked from network); 9 Dec 2011 19:49:51 -0000
Received: from mail-bw0-f43.google.com (HELO mail-bw0-f43.google.com)
	(209.85.214.43)
	by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 19:49:51 -0000
Received: by bkbzs2 with SMTP id zs2so9818717bkb.30
	for <xen-devel@lists.xensource.com>;
	Fri, 09 Dec 2011 11:49:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=message-id:date:from:user-agent:mime-version:to:subject
	:content-type:content-transfer-encoding;
	bh=UeThKYBa9XTx3K3o9i0rXljkUc16o3ISsitUUA5iZPQ=;
	b=OCtTUsQl4+lBruQtYW2pz/iZD6l11Ls7sqgLVLRC+04ryKUhfgo1x3SYiipFr6Q4m4
	BVXKrIs8OZAyFlUc4jO7qXNGA4GWnvDs/cJkRXO2vmUlrYGQ/SzpG9J3Xl8w39viiVvV
	ACf9oumxczi0vRmyLc2hwwBXbDBJFI35YNRN0=
Received: by 10.204.146.79 with SMTP id g15mr4517928bkv.121.1323460191426;
	Fri, 09 Dec 2011 11:49:51 -0800 (PST)
Received: from [192.168.0.220] (desunote.ru. [95.161.2.76])
	by mx.google.com with ESMTPS id e18sm12282721bkr.15.2011.12.09.11.49.49
	(version=SSLv3 cipher=OTHER); Fri, 09 Dec 2011 11:49:50 -0800 (PST)
Message-ID: <4EE2665C.8090602@gmail.com>
Date: Fri, 09 Dec 2011 23:49:48 +0400
From: George Shuklin <george.shuklin@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:9.0) Gecko/20111209 Thunderbird/9.0
MIME-Version: 1.0
To: xen-devel@lists.xensource.com, xen-hosting@googlegroups.com
Subject: [Xen-devel] bug in xenstored? No notification to subscription on
	@introduceDomain
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Good day.

I think I met some strange bug in xenstored.

I using XCP for long time and all that time we have some funny bug we 
was not able to debug enough due product environment and very low chance 
to appear, now we was able to catch it in testing environment and done 
some research.

We have python application running in dom0 and waiting domain 
appearance. This implemented this via subscription to @introduceDomain 
xenstore key. Under some conditions we stops to receive notification on 
subscription. If we ran application as second instance it will receive 
that notification, if we restart application it will  receive too.

I unable to pinpoint exact condition for this, but this
a) Happens occasionally but consistently (about once a month in farm of 
50 hosts at least at one host)
b) Not related to xenstored uptime
c) Not related to load on xen or dom0
d) Not related to amount of domains
e) Occur at least at XCP 0.5, 1.0 and 1.1 (I don't know how to get 
version from xenstored)

Last time I got that on two hosts in lab at same time (with single guest 
domain without any high load) and done some experiments - so I can say 
exactly I wrote above.

The pieces from python code we ran:

from xen.lowlevel.xs import xs
conn = xs.xs()
conn.watch("@introduceDomain", "+")
conn.watch("@releaseDomain", "-")
conn.read_watch()

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 20:21:23 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 20: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.xensource.com>)
	id 1RZ6w3-0005bO-NW; Fri, 09 Dec 2011 20:20:47 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Neal.Taylor@ca.com>) id 1RZ6w0-0005bJ-Lm
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 20:20:45 +0000
X-Env-Sender: Neal.Taylor@ca.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1323461956!56089715!1
X-Originating-IP: [74.125.149.211]
X-SpamReason: No, hits=0.9 required=7.0 tests=BODY_RANDOM_LONG,
	HTML_50_60,HTML_ATTR_UNIQUE,HTML_MESSAGE
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32395 invoked from network); 9 Dec 2011 20:19:19 -0000
Received: from na3sys009aog114.obsmtp.com (HELO na3sys009aog114.obsmtp.com)
	(74.125.149.211)
	by server-9.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 9 Dec 2011 20:19:19 -0000
Received: from USILMS191.ca.com ([141.202.246.45]) (using TLSv1) by
	na3sys009aob114.postini.com ([74.125.148.12]) with SMTP
	ID DSNKTuJtZV14JjFrCEb478Zzi6zSOjnnErqF@postini.com;
	Fri, 09 Dec 2011 12:19:51 PST
Received: from USILMS174.ca.com (141.202.6.24) by USILMS191.ca.com
	(141.202.246.45) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Fri, 9 Dec 2011 15:19:48 -0500
Received: from USILMS110A.ca.com ([169.254.1.109]) by usilms174.ca.com
	([141.202.6.24]) with mapi id 14.01.0289.001;
	Fri, 9 Dec 2011 15:19:48 -0500
From: "Taylor, Neal E" <Neal.Taylor@ca.com>
To: xen-devel <xen-devel@lists.xensource.com>
Thread-Topic: Buffers not reachable by PCI
Thread-Index: Acy2r+Ulg1PsfbmtTl6QVj0jZAx7mw==
Date: Fri, 9 Dec 2011 20:19:47 +0000
Message-ID: <3E243B26F475504B9BB0BCC9728B0DA629E16E01@USILMS110A.ca.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [138.42.46.108]
Content-Type: multipart/mixed;
	boundary="_005_3E243B26F475504B9BB0BCC9728B0DA629E16E01USILMS110Acacom_"
MIME-Version: 1.0
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>, "Kalev,
	Leonid" <Leonid.Kalev@ca.com>, "Dave, Tushar N" <tushar.n.dave@intel.com>
Subject: [Xen-devel] Buffers not reachable by PCI
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--_005_3E243B26F475504B9BB0BCC9728B0DA629E16E01USILMS110Acacom_
Content-Type: multipart/alternative;
	boundary="_000_3E243B26F475504B9BB0BCC9728B0DA629E16E01USILMS110Acacom_"

--_000_3E243B26F475504B9BB0BCC9728B0DA629E16E01USILMS110Acacom_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

We're running 64-bit Xex 4.1.1 and 32-bit Linux 3.0.4 Dom0 (Linux 3.1 shows=
 the same symptom.)

Several PCI drivers are unable to use DMA. Most fallback to using PIO but i=
n two instances the network drivers (e1000 and pcinet32) abort. The same ke=
rnel running on the same hardware without Xen works fine.

Digging through the code, in swiotlb-xen.c I find "DMA_BIT_MASK(32)" (0x000=
00000ffffffff) compared to "xen_virt_to_bus(xen_io_tlb_end - 1)" which reso=
lves to 0x1,20fd,feff. Since the address is larger than the mask, DMA is de=
clared as unsupportable.

In talking with others I hear Linux handles this situation with bounce buff=
ers. Is there a config setting I've missed to enable that for Xen? (Config =
file attached)


Relevant slice of source callback list:
xen_swiotlb_dma_supported (drivers/xen/swiotlb-xen.c: line 591)
dma_supported             (arch/x86/kernel/pci-dma.c: line 199)
dma_set_mask              (arch/x86/kernel/pci-dma.c: line 59)
e1000_probe               (drivers/net/e1000/e1000_main.c: line 986)


Relevant patches:

https://lkml.org/lkml/2011/9/1/100, "[PATCH v2] xen: x86_32: do not enable =
iterrupts when returning from exception in interrupt context"

http://xen.1045712.n5.nabble.com/PATCH-mm-sync-vmalloc-address-space-page-t=
ables-in-alloc-vm-area-td4757995.html "[PATCH] mm: sync vmalloc address spa=
ce page tables in alloc_vm_area()" (this patch was reverted for 3.1 but thi=
s is 3.0.4) and

an additional 2048 NR_IRQS to support (as I understand it) all the virtual =
devices we might support with 50 guests.

Not so relevant patches in md, nbd and loop.

lspci:
00:00.0 Host bridge: Intel Corporation E7520 Memory Controller Hub (rev 09)
00:02.0 PCI bridge: Intel Corporation E7525/E7520/E7320 PCI Express Port A =
(rev 09)
00:04.0 PCI bridge: Intel Corporation E7525/E7520 PCI Express Port B (rev 0=
9)
00:05.0 PCI bridge: Intel Corporation E7520 PCI Express Port B1 (rev 09)
00:06.0 PCI bridge: Intel Corporation E7520 PCI Express Port C (rev 09)
00:1d.0 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB UHCI =
Controller #1 (rev 02)
00:1d.1 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB UHCI =
Controller #2 (rev 02)
00:1d.2 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB UHCI =
Controller #3 (rev 02)
00:1d.7 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB2 EHCI=
 Controller (rev 02)
00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev c2)
00:1f.0 ISA bridge: Intel Corporation 82801EB/ER (ICH5/ICH5R) LPC Interface=
 Bridge (rev 02)
00:1f.1 IDE interface: Intel Corporation 82801EB/ER (ICH5/ICH5R) IDE Contro=
ller (rev 02)
01:00.0 PCI bridge: Intel Corporation 80332 [Dobson] I/O processor (A-Segme=
nt Bridge) (rev 06)
01:00.2 PCI bridge: Intel Corporation 80332 [Dobson] I/O processor (B-Segme=
nt Bridge) (rev 06)
02:05.0 SCSI storage controller: LSI Logic / Symbios Logic 53c1030 PCI-X Fu=
sion-MPT Dual Ultra320 SCSI (rev 08)
05:00.0 PCI bridge: Intel Corporation 6700PXH PCI Express-to-PCI Bridge A (=
rev 09)
05:00.2 PCI bridge: Intel Corporation 6700PXH PCI Express-to-PCI Bridge B (=
rev 09)
06:07.0 Ethernet controller: Intel Corporation 82541GI Gigabit Ethernet Con=
troller (rev 05)
07:08.0 Ethernet controller: Intel Corporation 82541GI Gigabit Ethernet Con=
troller (rev 05)
09:05.0 Class ff00: Dell Remote Access Card 4 Daughter Card
09:05.1 Class ff00: Dell Remote Access Card 4 Daughter Card Virtual UART
09:05.2 Class ff00: Dell Remote Access Card 4 Daughter Card SMIC interface
09:06.0 IDE interface: Silicon Image, Inc. PCI0680 Ultra ATA-133 Host Contr=
oller (rev 02)
09:0d.0 VGA compatible controller: ATI Technologies Inc Radeon RV100 QY [Ra=
deon 7000/VE]

     1  00:00.0 Host bridge: Intel Corporation E7520 Memory Controller Hub =
(rev 09)
     2  00:02.0 PCI bridge: Intel Corporation E7525/E7520/E7320 PCI Express=
 Port A (rev 09)
     3  00:04.0 PCI bridge: Intel Corporation E7525/E7520 PCI Express Port =
B (rev 09)
     4  00:05.0 PCI bridge: Intel Corporation E7520 PCI Express Port B1 (re=
v 09)
     5  00:06.0 PCI bridge: Intel Corporation E7520 PCI Express Port C (rev=
 09)
     6  00:1d.0 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) U=
SB UHCI Controller #1 (rev 02)
     7  00:1d.1 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) U=
SB UHCI Controller #2 (rev 02)
     8  00:1d.2 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) U=
SB UHCI Controller #3 (rev 02)
     9  00:1d.7 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) U=
SB2 EHCI Controller (rev 02)
    10  00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev c2)
    11  00:1f.0 ISA bridge: Intel Corporation 82801EB/ER (ICH5/ICH5R) LPC I=
nterface Bridge (rev 02)
    12  00:1f.1 IDE interface: Intel Corporation 82801EB/ER (ICH5/ICH5R) ID=
E Controller (rev 02)
    13  01:00.0 PCI bridge: Intel Corporation 80332 [Dobson] I/O processor =
(A-Segment Bridge) (rev 06)
    14  01:00.2 PCI bridge: Intel Corporation 80332 [Dobson] I/O processor =
(B-Segment Bridge) (rev 06)
    15  02:05.0 SCSI storage controller: LSI Logic / Symbios Logic 53c1030 =
PCI-X Fusion-MPT Dual Ultra320 SCSI (rev 08)
    16  05:00.0 PCI bridge: Intel Corporation 6700PXH PCI Express-to-PCI Br=
idge A (rev 09)
    17  05:00.2 PCI bridge: Intel Corporation 6700PXH PCI Express-to-PCI Br=
idge B (rev 09)
    18  06:07.0 Ethernet controller: Intel Corporation 82541GI Gigabit Ethe=
rnet Controller (rev 05)
    19  07:08.0 Ethernet controller: Intel Corporation 82541GI Gigabit Ethe=
rnet Controller (rev 05)
    20  09:05.0 Class ff00: Dell Remote Access Card 4 Daughter Card
    21  09:05.1 Class ff00: Dell Remote Access Card 4 Daughter Card Virtual=
 UART
    22  09:05.2 Class ff00: Dell Remote Access Card 4 Daughter Card SMIC in=
terface
    23  09:06.0 IDE interface: Silicon Image, Inc. PCI0680 Ultra ATA-133 Ho=
st Controller (rev 02)
    24  09:0d.0 VGA compatible controller: ATI Technologies Inc Radeon RV10=
0 QY [Radeon 7000/VE]

06:07.0 Ethernet controller: Intel Corporation 82541GI Gigabit Ethernet Con=
troller (rev 05)
        Subsystem: Dell PRO/1000 MT Network Connection
        Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV+ VGASnoop- ParErr-=
 Stepping- SERR+ FastB2B-
        Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=3Dmedium >TAbort- =
<TAbort- <MAbort- >SERR- <PERR-
        Interrupt: pin A routed to IRQ 64
        Region 0: Memory at dfae0000 (32-bit, non-prefetchable) [size=3D128=
K]
        Region 2: I/O ports at dcc0 [size=3D64]
        Capabilities: [dc] Power Management version 2
                Flags: PMEClk- DSI+ D1- D2- AuxCurrent=3D0mA PME(D0+,D1-,D2=
-,D3hot+,D3cold+)
                Status: D0 PME-Enable- DSel=3D0 DScale=3D1 PME-
        Capabilities: [e4] PCI-X non-bridge device
                Command: DPERE- ERO+ RBC=3D512 OST=3D1
                Status: Dev=3D00:00.0 64bit- 133MHz- SCD- USC- DC=3Dsimple =
DMMRBC=3D2048 DMOST=3D1 DMCRS=3D8 RSCEM- 266MHz- 533MHz-

log file attached.

--_000_3E243B26F475504B9BB0BCC9728B0DA629E16E01USILMS110Acacom_
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:x=3D"urn:schemas-microsoft-com:office:excel" xmlns:p=3D"urn:schemas-m=
icrosoft-com:office:powerpoint" xmlns:a=3D"urn:schemas-microsoft-com:office=
:access" xmlns:dt=3D"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s=3D"=
uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs=3D"urn:schemas-microsof=
t-com:rowset" xmlns:z=3D"#RowsetSchema" xmlns:b=3D"urn:schemas-microsoft-co=
m:office:publisher" xmlns:ss=3D"urn:schemas-microsoft-com:office:spreadshee=
t" xmlns:c=3D"urn:schemas-microsoft-com:office:component:spreadsheet" xmlns=
:odc=3D"urn:schemas-microsoft-com:office:odc" xmlns:oa=3D"urn:schemas-micro=
soft-com:office:activation" xmlns:html=3D"http://www.w3.org/TR/REC-html40" =
xmlns:q=3D"http://schemas.xmlsoap.org/soap/envelope/" xmlns:rtc=3D"http://m=
icrosoft.com/officenet/conferencing" xmlns:D=3D"DAV:" xmlns:Repl=3D"http://=
schemas.microsoft.com/repl/" xmlns:mt=3D"http://schemas.microsoft.com/share=
point/soap/meetings/" xmlns:x2=3D"http://schemas.microsoft.com/office/excel=
/2003/xml" xmlns:ppda=3D"http://www.passport.com/NameSpace.xsd" xmlns:ois=
=3D"http://schemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir=3D"http://=
schemas.microsoft.com/sharepoint/soap/directory/" xmlns:ds=3D"http://www.w3=
.org/2000/09/xmldsig#" xmlns:dsp=3D"http://schemas.microsoft.com/sharepoint=
/dsp" xmlns:udc=3D"http://schemas.microsoft.com/data/udc" xmlns:xsd=3D"http=
://www.w3.org/2001/XMLSchema" xmlns:sub=3D"http://schemas.microsoft.com/sha=
repoint/soap/2002/1/alerts/" xmlns:ec=3D"http://www.w3.org/2001/04/xmlenc#"=
 xmlns:sp=3D"http://schemas.microsoft.com/sharepoint/" xmlns:sps=3D"http://=
schemas.microsoft.com/sharepoint/soap/" xmlns:xsi=3D"http://www.w3.org/2001=
/XMLSchema-instance" xmlns:udcs=3D"http://schemas.microsoft.com/data/udc/so=
ap" xmlns:udcxf=3D"http://schemas.microsoft.com/data/udc/xmlfile" xmlns:udc=
p2p=3D"http://schemas.microsoft.com/data/udc/parttopart" xmlns:wf=3D"http:/=
/schemas.microsoft.com/sharepoint/soap/workflow/" xmlns:dsss=3D"http://sche=
mas.microsoft.com/office/2006/digsig-setup" xmlns:dssi=3D"http://schemas.mi=
crosoft.com/office/2006/digsig" xmlns:mdssi=3D"http://schemas.openxmlformat=
s.org/package/2006/digital-signature" xmlns:mver=3D"http://schemas.openxmlf=
ormats.org/markup-compatibility/2006" xmlns:m=3D"http://schemas.microsoft.c=
om/office/2004/12/omml" xmlns:mrels=3D"http://schemas.openxmlformats.org/pa=
ckage/2006/relationships" xmlns:spwp=3D"http://microsoft.com/sharepoint/web=
partpages" xmlns:ex12t=3D"http://schemas.microsoft.com/exchange/services/20=
06/types" xmlns:ex12m=3D"http://schemas.microsoft.com/exchange/services/200=
6/messages" xmlns:pptsl=3D"http://schemas.microsoft.com/sharepoint/soap/Sli=
deLibrary/" xmlns:spsl=3D"http://microsoft.com/webservices/SharePointPortal=
Server/PublishedLinksService" xmlns:Z=3D"urn:schemas-microsoft-com:" xmlns:=
st=3D"&#1;" xmlns=3D"http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3D"Generator" content=3D"Microsoft Word 12 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:"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: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";}
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;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
	{mso-style-priority:99;
	mso-style-link:"Plain Text Char";
	margin:0in;
	margin-bottom:.0001pt;
	font-size:10.5pt;
	font-family:Consolas;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
span.PlainTextChar
	{mso-style-name:"Plain Text Char";
	mso-style-priority:99;
	mso-style-link:"Plain Text";
	font-family:Consolas;}
.MsoChpDefault
	{mso-style-type:export-only;}
@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">We&#8217;re running 64-bit Xex 4.1.1 and 32-bit Linu=
x 3.0.4 Dom0 (Linux 3.1 shows the same symptom.)<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">Several PCI drivers are unable to use DMA. Most fall=
back to using PIO but in two instances the network drivers (e1000 and pcine=
t32) abort. The same kernel running on the same hardware without Xen works =
fine.<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">Digging through the code, in swiotlb-xen.c I find &#=
8220;DMA_BIT_MASK(32)&#8221; (0x00000000ffffffff) compared to &#8220;xen_vi=
rt_to_bus(xen_io_tlb_end - 1)&#8221; which resolves to 0x1,20fd,feff. Since=
 the address is larger than the mask, DMA is declared as unsupportable.<o:p=
></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">In talking with others I hear Linux handles this sit=
uation with bounce buffers. Is there a config setting I&#8217;ve missed to =
enable that for Xen? (Config file attached)<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">Relevant slice of source callback list:<o:p></o:p></=
p>
<p class=3D"MsoNormal"><span style=3D"font-family:&quot;Courier New&quot;">=
xen_swiotlb_dma_supported (drivers/xen/swiotlb-xen.c: line 591)<o:p></o:p><=
/span></p>
<p class=3D"MsoNormal"><span style=3D"font-family:&quot;Courier New&quot;">=
dma_supported&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp; (arch/x86/kernel/pci-dma.c: line 199)<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-family:&quot;Courier New&quot;">=
dma_set_mask&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;(arch/x86/kernel/pci-dma.c: line 59)<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-family:&quot;Courier New&quot;">=
e1000_probe&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp; (drivers/net/e1000/e1000_main.c: line 986)<o:p></o:p><=
/span></p>
<p class=3D"MsoNormal"><span style=3D"font-family:&quot;Courier New&quot;">=
<o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-family:&quot;Courier New&quot;">=
<o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal">Relevant patches:<o:p></o:p></p>
<p class=3D"MsoPlainText"><a href=3D"https://lkml.org/lkml/2011/9/1/100">ht=
tps://lkml.org/lkml/2011/9/1/100</a>, &quot;[PATCH v2] xen: x86_32: do not =
enable iterrupts when returning from exception in interrupt context&quot;<o=
:p></o:p></p>
<p class=3D"MsoPlainText"><a href=3D"http://xen.1045712.n5.nabble.com/PATCH=
-mm-sync-vmalloc-address-space-page-tables-in-alloc-vm-area-td4757995.html"=
>http://xen.1045712.n5.nabble.com/PATCH-mm-sync-vmalloc-address-space-page-=
tables-in-alloc-vm-area-td4757995.html</a>
 &quot;[PATCH] mm: sync vmalloc address space page tables in alloc_vm_area(=
)&quot; (this patch was reverted for 3.1 but this is 3.0.4) and
<o:p></o:p></p>
<p class=3D"MsoPlainText">an additional 2048 NR_IRQS to support (as I under=
stand it) all the virtual devices we might support with 50 guests.<o:p></o:=
p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">Not so relevant patches in md, nbd and loop.<o:p></o=
:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">lspci:<o:p></o:p></p>
<p class=3D"MsoNormal">00:00.0 Host bridge: Intel Corporation E7520 Memory =
Controller Hub (rev 09)<o:p></o:p></p>
<p class=3D"MsoNormal">00:02.0 PCI bridge: Intel Corporation E7525/E7520/E7=
320 PCI Express Port A (rev 09)<o:p></o:p></p>
<p class=3D"MsoNormal">00:04.0 PCI bridge: Intel Corporation E7525/E7520 PC=
I Express Port B (rev 09)<o:p></o:p></p>
<p class=3D"MsoNormal">00:05.0 PCI bridge: Intel Corporation E7520 PCI Expr=
ess Port B1 (rev 09)<o:p></o:p></p>
<p class=3D"MsoNormal">00:06.0 PCI bridge: Intel Corporation E7520 PCI Expr=
ess Port C (rev 09)<o:p></o:p></p>
<p class=3D"MsoNormal">00:1d.0 USB Controller: Intel Corporation 82801EB/ER=
 (ICH5/ICH5R) USB UHCI Controller #1 (rev 02)<o:p></o:p></p>
<p class=3D"MsoNormal">00:1d.1 USB Controller: Intel Corporation 82801EB/ER=
 (ICH5/ICH5R) USB UHCI Controller #2 (rev 02)<o:p></o:p></p>
<p class=3D"MsoNormal">00:1d.2 USB Controller: Intel Corporation 82801EB/ER=
 (ICH5/ICH5R) USB UHCI Controller #3 (rev 02)<o:p></o:p></p>
<p class=3D"MsoNormal">00:1d.7 USB Controller: Intel Corporation 82801EB/ER=
 (ICH5/ICH5R) USB2 EHCI Controller (rev 02)<o:p></o:p></p>
<p class=3D"MsoNormal">00:1e.0 PCI bridge: Intel Corporation 82801 PCI Brid=
ge (rev c2)<o:p></o:p></p>
<p class=3D"MsoNormal">00:1f.0 ISA bridge: Intel Corporation 82801EB/ER (IC=
H5/ICH5R) LPC Interface Bridge (rev 02)<o:p></o:p></p>
<p class=3D"MsoNormal">00:1f.1 IDE interface: Intel Corporation 82801EB/ER =
(ICH5/ICH5R) IDE Controller (rev 02)<o:p></o:p></p>
<p class=3D"MsoNormal">01:00.0 PCI bridge: Intel Corporation 80332 [Dobson]=
 I/O processor (A-Segment Bridge) (rev 06)<o:p></o:p></p>
<p class=3D"MsoNormal">01:00.2 PCI bridge: Intel Corporation 80332 [Dobson]=
 I/O processor (B-Segment Bridge) (rev 06)<o:p></o:p></p>
<p class=3D"MsoNormal">02:05.0 SCSI storage controller: LSI Logic / Symbios=
 Logic 53c1030 PCI-X Fusion-MPT Dual Ultra320 SCSI (rev 08)<o:p></o:p></p>
<p class=3D"MsoNormal">05:00.0 PCI bridge: Intel Corporation 6700PXH PCI Ex=
press-to-PCI Bridge A (rev 09)<o:p></o:p></p>
<p class=3D"MsoNormal">05:00.2 PCI bridge: Intel Corporation 6700PXH PCI Ex=
press-to-PCI Bridge B (rev 09)<o:p></o:p></p>
<p class=3D"MsoNormal">06:07.0 Ethernet controller: Intel Corporation 82541=
GI Gigabit Ethernet Controller (rev 05)<o:p></o:p></p>
<p class=3D"MsoNormal">07:08.0 Ethernet controller: Intel Corporation 82541=
GI Gigabit Ethernet Controller (rev 05)<o:p></o:p></p>
<p class=3D"MsoNormal">09:05.0 Class ff00: Dell Remote Access Card 4 Daught=
er Card<o:p></o:p></p>
<p class=3D"MsoNormal">09:05.1 Class ff00: Dell Remote Access Card 4 Daught=
er Card Virtual UART<o:p></o:p></p>
<p class=3D"MsoNormal">09:05.2 Class ff00: Dell Remote Access Card 4 Daught=
er Card SMIC interface<o:p></o:p></p>
<p class=3D"MsoNormal">09:06.0 IDE interface: Silicon Image, Inc. PCI0680 U=
ltra ATA-133 Host Controller (rev 02)<o:p></o:p></p>
<p class=3D"MsoNormal">09:0d.0 VGA compatible controller: ATI Technologies =
Inc Radeon RV100 QY [Radeon 7000/VE]<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">&nbsp;&nbsp;&nbsp;&nbsp; 1&nbsp; 00:00.0 Host bridge=
: Intel Corporation E7520 Memory Controller Hub (rev 09)<o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;&nbsp;&nbsp;&nbsp; 2&nbsp; 00:02.0 PCI bridge:=
 Intel Corporation E7525/E7520/E7320 PCI Express Port A (rev 09)<o:p></o:p>=
</p>
<p class=3D"MsoNormal">&nbsp;&nbsp;&nbsp;&nbsp; 3&nbsp; 00:04.0 PCI bridge:=
 Intel Corporation E7525/E7520 PCI Express Port B (rev 09)<o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;&nbsp;&nbsp;&nbsp; 4&nbsp; 00:05.0 PCI bridge:=
 Intel Corporation E7520 PCI Express Port B1 (rev 09)<o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;&nbsp;&nbsp;&nbsp; 5&nbsp; 00:06.0 PCI bridge:=
 Intel Corporation E7520 PCI Express Port C (rev 09)<o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;&nbsp;&nbsp;&nbsp; 6&nbsp; 00:1d.0 USB Control=
ler: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB UHCI Controller #1 (rev =
02)<o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;&nbsp;&nbsp;&nbsp; 7&nbsp; 00:1d.1 USB Control=
ler: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB UHCI Controller #2 (rev =
02)<o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;&nbsp;&nbsp;&nbsp; 8&nbsp; 00:1d.2 USB Control=
ler: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB UHCI Controller #3 (rev =
02)<o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;&nbsp;&nbsp;&nbsp; 9&nbsp; 00:1d.7 USB Control=
ler: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB2 EHCI Controller (rev 02=
)<o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;&nbsp;&nbsp; 10&nbsp; 00:1e.0 PCI bridge: Inte=
l Corporation 82801 PCI Bridge (rev c2)<o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;&nbsp;&nbsp; 11&nbsp; 00:1f.0 ISA bridge: Inte=
l Corporation 82801EB/ER (ICH5/ICH5R) LPC Interface Bridge (rev 02)<o:p></o=
:p></p>
<p class=3D"MsoNormal">&nbsp;&nbsp;&nbsp; 12&nbsp; 00:1f.1 IDE interface: I=
ntel Corporation 82801EB/ER (ICH5/ICH5R) IDE Controller (rev 02)<o:p></o:p>=
</p>
<p class=3D"MsoNormal">&nbsp;&nbsp;&nbsp; 13&nbsp; 01:00.0 PCI bridge: Inte=
l Corporation 80332 [Dobson] I/O processor (A-Segment Bridge) (rev 06)<o:p>=
</o:p></p>
<p class=3D"MsoNormal">&nbsp;&nbsp;&nbsp; 14&nbsp; 01:00.2 PCI bridge: Inte=
l Corporation 80332 [Dobson] I/O processor (B-Segment Bridge) (rev 06)<o:p>=
</o:p></p>
<p class=3D"MsoNormal">&nbsp;&nbsp;&nbsp; 15&nbsp; 02:05.0 SCSI storage con=
troller: LSI Logic / Symbios Logic 53c1030 PCI-X Fusion-MPT Dual Ultra320 S=
CSI (rev 08)<o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;&nbsp;&nbsp; 16 &nbsp;05:00.0 PCI bridge: Inte=
l Corporation 6700PXH PCI Express-to-PCI Bridge A (rev 09)<o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;&nbsp;&nbsp; 17&nbsp; 05:00.2 PCI bridge: Inte=
l Corporation 6700PXH PCI Express-to-PCI Bridge B (rev 09)<o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;&nbsp;&nbsp; 18&nbsp; 06:07.0 Ethernet control=
ler: Intel Corporation 82541GI Gigabit Ethernet Controller (rev 05)<o:p></o=
:p></p>
<p class=3D"MsoNormal">&nbsp;&nbsp;&nbsp; 19&nbsp; 07:08.0 Ethernet control=
ler: Intel Corporation 82541GI Gigabit Ethernet Controller (rev 05)<o:p></o=
:p></p>
<p class=3D"MsoNormal">&nbsp;&nbsp;&nbsp; 20&nbsp; 09:05.0 Class ff00: Dell=
 Remote Access Card 4 Daughter Card<o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;&nbsp;&nbsp; 21&nbsp; 09:05.1 Class ff00: Dell=
 Remote Access Card 4 Daughter Card Virtual UART<o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;&nbsp;&nbsp; 22&nbsp; 09:05.2 Class ff00: Dell=
 Remote Access Card 4 Daughter Card SMIC interface<o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;&nbsp;&nbsp; 23&nbsp; 09:06.0 IDE interface: S=
ilicon Image, Inc. PCI0680 Ultra ATA-133 Host Controller (rev 02)<o:p></o:p=
></p>
<p class=3D"MsoNormal">&nbsp;&nbsp;&nbsp; 24&nbsp; 09:0d.0 VGA compatible c=
ontroller: ATI Technologies Inc Radeon RV100 QY [Radeon 7000/VE]<o:p></o:p>=
</p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">06:07.0 Ethernet controller: Intel Corporation 82541=
GI Gigabit Ethernet Controller (rev 05)<o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Subsystem=
: Dell PRO/1000 MT Network Connection<o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Control: =
I/O&#43; Mem&#43; BusMaster- SpecCycle- MemWINV&#43; VGASnoop- ParErr- Step=
ping- SERR&#43; FastB2B-<o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Status: C=
ap&#43; 66MHz&#43; UDF- FastB2B- ParErr- DEVSEL=3Dmedium &gt;TAbort- &lt;TA=
bort- &lt;MAbort- &gt;SERR- &lt;PERR-<o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Interrupt=
: pin A routed to IRQ 64<o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Region 0:=
 Memory at dfae0000 (32-bit, non-prefetchable) [size=3D128K]<o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;Region 2:=
 I/O ports at dcc0 [size=3D64]<o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Capabilit=
ies: [dc] Power Management version 2<o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Flags: PMEClk- DSI&#43; D1- D2- AuxC=
urrent=3D0mA PME(D0&#43;,D1-,D2-,D3hot&#43;,D3cold&#43;)<o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Status: D0 PME-Enable- DSel=3D0 DSca=
le=3D1 PME-<o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Capabilit=
ies: [e4] PCI-X non-bridge device<o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Command: DPERE- ERO&#43; RBC=3D512 O=
ST=3D1<o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Status: Dev=3D00:00.0 64bit- 133MHz-=
 SCD- USC- DC=3Dsimple DMMRBC=3D2048 DMOST=3D1 DMCRS=3D8 RSCEM- 266MHz- 533=
MHz-<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">log file attached.<o:p></o:p></p>
</div>
</body>
</html>

--_000_3E243B26F475504B9BB0BCC9728B0DA629E16E01USILMS110Acacom_--

--_005_3E243B26F475504B9BB0BCC9728B0DA629E16E01USILMS110Acacom_
Content-Type: application/octet-stream; name="config-xen0.i386"
Content-Description: config-xen0.i386
Content-Disposition: attachment; filename="config-xen0.i386"; size=59186;
	creation-date="Fri, 09 Dec 2011 19:18:26 GMT";
	modification-date="Fri, 09 Dec 2011 19:16:35 GMT"
Content-Transfer-Encoding: base64

IwojIEF1dG9tYXRpY2FsbHkgZ2VuZXJhdGVkIG1ha2UgY29uZmlnOiBkb24ndCBlZGl0CiMgTGlu
dXgvaTM4NiAzLjAuNC0zMi54ZW4wIEtlcm5lbCBDb25maWd1cmF0aW9uCiMKIyBDT05GSUdfNjRC
SVQgaXMgbm90IHNldApDT05GSUdfWDg2XzMyPXkKIyBDT05GSUdfWDg2XzY0IGlzIG5vdCBzZXQK
Q09ORklHX1g4Nj15CkNPTkZJR19JTlNUUlVDVElPTl9ERUNPREVSPXkKQ09ORklHX09VVFBVVF9G
T1JNQVQ9ImVsZjMyLWkzODYiCkNPTkZJR19BUkNIX0RFRkNPTkZJRz0iYXJjaC94ODYvY29uZmln
cy9pMzg2X2RlZmNvbmZpZyIKQ09ORklHX0dFTkVSSUNfQ01PU19VUERBVEU9eQpDT05GSUdfQ0xP
Q0tTT1VSQ0VfV0FUQ0hET0c9eQpDT05GSUdfR0VORVJJQ19DTE9DS0VWRU5UUz15CkNPTkZJR19H
RU5FUklDX0NMT0NLRVZFTlRTX0JST0FEQ0FTVD15CkNPTkZJR19MT0NLREVQX1NVUFBPUlQ9eQpD
T05GSUdfU1RBQ0tUUkFDRV9TVVBQT1JUPXkKQ09ORklHX0hBVkVfTEFURU5DWVRPUF9TVVBQT1JU
PXkKQ09ORklHX01NVT15CkNPTkZJR19aT05FX0RNQT15CiMgQ09ORklHX05FRURfRE1BX01BUF9T
VEFURSBpcyBub3Qgc2V0CkNPTkZJR19ORUVEX1NHX0RNQV9MRU5HVEg9eQpDT05GSUdfR0VORVJJ
Q19JU0FfRE1BPXkKQ09ORklHX0dFTkVSSUNfSU9NQVA9eQpDT05GSUdfR0VORVJJQ19CVUc9eQpD
T05GSUdfR0VORVJJQ19IV0VJR0hUPXkKQ09ORklHX0FSQ0hfTUFZX0hBVkVfUENfRkRDPXkKIyBD
T05GSUdfUldTRU1fR0VORVJJQ19TUElOTE9DSyBpcyBub3Qgc2V0CkNPTkZJR19SV1NFTV9YQ0hH
QUREX0FMR09SSVRITT15CkNPTkZJR19BUkNIX0hBU19DUFVfSURMRV9XQUlUPXkKQ09ORklHX0dF
TkVSSUNfQ0FMSUJSQVRFX0RFTEFZPXkKIyBDT05GSUdfR0VORVJJQ19USU1FX1ZTWVNDQUxMIGlz
IG5vdCBzZXQKQ09ORklHX0FSQ0hfSEFTX0NQVV9SRUxBWD15CkNPTkZJR19BUkNIX0hBU19ERUZB
VUxUX0lETEU9eQpDT05GSUdfQVJDSF9IQVNfQ0FDSEVfTElORV9TSVpFPXkKQ09ORklHX0hBVkVf
U0VUVVBfUEVSX0NQVV9BUkVBPXkKQ09ORklHX05FRURfUEVSX0NQVV9FTUJFRF9GSVJTVF9DSFVO
Sz15CkNPTkZJR19ORUVEX1BFUl9DUFVfUEFHRV9GSVJTVF9DSFVOSz15CiMgQ09ORklHX0hBVkVf
Q1BVTUFTS19PRl9DUFVfTUFQIGlzIG5vdCBzZXQKQ09ORklHX0FSQ0hfSElCRVJOQVRJT05fUE9T
U0lCTEU9eQpDT05GSUdfQVJDSF9TVVNQRU5EX1BPU1NJQkxFPXkKIyBDT05GSUdfWk9ORV9ETUEz
MiBpcyBub3Qgc2V0CkNPTkZJR19BUkNIX1BPUFVMQVRFU19OT0RFX01BUD15CiMgQ09ORklHX0FV
RElUX0FSQ0ggaXMgbm90IHNldApDT05GSUdfQVJDSF9TVVBQT1JUU19PUFRJTUlaRURfSU5MSU5J
Tkc9eQpDT05GSUdfQVJDSF9TVVBQT1JUU19ERUJVR19QQUdFQUxMT0M9eQpDT05GSUdfWDg2XzMy
X1NNUD15CkNPTkZJR19YODZfSFQ9eQpDT05GSUdfWDg2XzMyX0xBWllfR1M9eQpDT05GSUdfQVJD
SF9IV0VJR0hUX0NGTEFHUz0iLWZjYWxsLXNhdmVkLWVjeCAtZmNhbGwtc2F2ZWQtZWR4IgpDT05G
SUdfS1RJTUVfU0NBTEFSPXkKQ09ORklHX0FSQ0hfQ1BVX1BST0JFX1JFTEVBU0U9eQpDT05GSUdf
REVGQ09ORklHX0xJU1Q9Ii9saWIvbW9kdWxlcy8kVU5BTUVfUkVMRUFTRS8uY29uZmlnIgpDT05G
SUdfSEFWRV9JUlFfV09SSz15CkNPTkZJR19JUlFfV09SSz15CgojCiMgR2VuZXJhbCBzZXR1cAoj
CkNPTkZJR19FWFBFUklNRU5UQUw9eQpDT05GSUdfSU5JVF9FTlZfQVJHX0xJTUlUPTMyCkNPTkZJ
R19DUk9TU19DT01QSUxFPSIiCkNPTkZJR19MT0NBTFZFUlNJT049IiIKIyBDT05GSUdfTE9DQUxW
RVJTSU9OX0FVVE8gaXMgbm90IHNldApDT05GSUdfSEFWRV9LRVJORUxfR1pJUD15CkNPTkZJR19I
QVZFX0tFUk5FTF9CWklQMj15CkNPTkZJR19IQVZFX0tFUk5FTF9MWk1BPXkKQ09ORklHX0hBVkVf
S0VSTkVMX1haPXkKQ09ORklHX0hBVkVfS0VSTkVMX0xaTz15CkNPTkZJR19LRVJORUxfR1pJUD15
CiMgQ09ORklHX0tFUk5FTF9CWklQMiBpcyBub3Qgc2V0CiMgQ09ORklHX0tFUk5FTF9MWk1BIGlz
IG5vdCBzZXQKIyBDT05GSUdfS0VSTkVMX1haIGlzIG5vdCBzZXQKIyBDT05GSUdfS0VSTkVMX0xa
TyBpcyBub3Qgc2V0CkNPTkZJR19ERUZBVUxUX0hPU1ROQU1FPSIobm9uZSkiCkNPTkZJR19TV0FQ
PXkKQ09ORklHX1NZU1ZJUEM9eQpDT05GSUdfU1lTVklQQ19TWVNDVEw9eQojIENPTkZJR19QT1NJ
WF9NUVVFVUUgaXMgbm90IHNldAojIENPTkZJR19CU0RfUFJPQ0VTU19BQ0NUIGlzIG5vdCBzZXQK
IyBDT05GSUdfRkhBTkRMRSBpcyBub3Qgc2V0CiMgQ09ORklHX1RBU0tTVEFUUyBpcyBub3Qgc2V0
CiMgQ09ORklHX0FVRElUIGlzIG5vdCBzZXQKQ09ORklHX0hBVkVfR0VORVJJQ19IQVJESVJRUz15
CgojCiMgSVJRIHN1YnN5c3RlbQojCkNPTkZJR19HRU5FUklDX0hBUkRJUlFTPXkKQ09ORklHX0hB
VkVfU1BBUlNFX0lSUT15CkNPTkZJR19HRU5FUklDX0lSUV9QUk9CRT15CkNPTkZJR19HRU5FUklD
X0lSUV9TSE9XPXkKQ09ORklHX0dFTkVSSUNfUEVORElOR19JUlE9eQpDT05GSUdfSVJRX0ZPUkNF
RF9USFJFQURJTkc9eQojIENPTkZJR19TUEFSU0VfSVJRIGlzIG5vdCBzZXQKCiMKIyBSQ1UgU3Vi
c3lzdGVtCiMKQ09ORklHX1RSRUVfUkNVPXkKIyBDT05GSUdfUFJFRU1QVF9SQ1UgaXMgbm90IHNl
dAojIENPTkZJR19SQ1VfVFJBQ0UgaXMgbm90IHNldApDT05GSUdfUkNVX0ZBTk9VVD0zMgojIENP
TkZJR19SQ1VfRkFOT1VUX0VYQUNUIGlzIG5vdCBzZXQKIyBDT05GSUdfUkNVX0ZBU1RfTk9fSFog
aXMgbm90IHNldAojIENPTkZJR19UUkVFX1JDVV9UUkFDRSBpcyBub3Qgc2V0CiMgQ09ORklHX0lL
Q09ORklHIGlzIG5vdCBzZXQKQ09ORklHX0xPR19CVUZfU0hJRlQ9MTcKQ09ORklHX0hBVkVfVU5T
VEFCTEVfU0NIRURfQ0xPQ0s9eQojIENPTkZJR19DR1JPVVBTIGlzIG5vdCBzZXQKQ09ORklHX05B
TUVTUEFDRVM9eQojIENPTkZJR19VVFNfTlMgaXMgbm90IHNldApDT05GSUdfSVBDX05TPXkKIyBD
T05GSUdfVVNFUl9OUyBpcyBub3Qgc2V0CiMgQ09ORklHX1BJRF9OUyBpcyBub3Qgc2V0CkNPTkZJ
R19ORVRfTlM9eQojIENPTkZJR19TQ0hFRF9BVVRPR1JPVVAgaXMgbm90IHNldApDT05GSUdfU1lT
RlNfREVQUkVDQVRFRD15CkNPTkZJR19TWVNGU19ERVBSRUNBVEVEX1YyPXkKIyBDT05GSUdfUkVM
QVkgaXMgbm90IHNldApDT05GSUdfQkxLX0RFVl9JTklUUkQ9eQpDT05GSUdfSU5JVFJBTUZTX1NP
VVJDRT0iIgpDT05GSUdfUkRfR1pJUD15CkNPTkZJR19SRF9CWklQMj15CiMgQ09ORklHX1JEX0xa
TUEgaXMgbm90IHNldAojIENPTkZJR19SRF9YWiBpcyBub3Qgc2V0CiMgQ09ORklHX1JEX0xaTyBp
cyBub3Qgc2V0CiMgQ09ORklHX0NDX09QVElNSVpFX0ZPUl9TSVpFIGlzIG5vdCBzZXQKQ09ORklH
X1NZU0NUTD15CkNPTkZJR19BTk9OX0lOT0RFUz15CkNPTkZJR19FWFBFUlQ9eQpDT05GSUdfVUlE
MTY9eQpDT05GSUdfU1lTQ1RMX1NZU0NBTEw9eQpDT05GSUdfS0FMTFNZTVM9eQpDT05GSUdfSE9U
UExVRz15CkNPTkZJR19QUklOVEs9eQpDT05GSUdfQlVHPXkKQ09ORklHX0VMRl9DT1JFPXkKQ09O
RklHX1BDU1BLUl9QTEFURk9STT15CkNPTkZJR19CQVNFX0ZVTEw9eQpDT05GSUdfRlVURVg9eQpD
T05GSUdfRVBPTEw9eQpDT05GSUdfU0lHTkFMRkQ9eQpDT05GSUdfVElNRVJGRD15CkNPTkZJR19F
VkVOVEZEPXkKQ09ORklHX1NITUVNPXkKQ09ORklHX0FJTz15CiMgQ09ORklHX0VNQkVEREVEIGlz
IG5vdCBzZXQKQ09ORklHX0hBVkVfUEVSRl9FVkVOVFM9eQoKIwojIEtlcm5lbCBQZXJmb3JtYW5j
ZSBFdmVudHMgQW5kIENvdW50ZXJzCiMKQ09ORklHX1BFUkZfRVZFTlRTPXkKIyBDT05GSUdfUEVS
Rl9DT1VOVEVSUyBpcyBub3Qgc2V0CkNPTkZJR19WTV9FVkVOVF9DT1VOVEVSUz15CkNPTkZJR19Q
Q0lfUVVJUktTPXkKIyBDT05GSUdfQ09NUEFUX0JSSyBpcyBub3Qgc2V0CkNPTkZJR19TTEFCPXkK
IyBDT05GSUdfU0xVQiBpcyBub3Qgc2V0CiMgQ09ORklHX1NMT0IgaXMgbm90IHNldAojIENPTkZJ
R19QUk9GSUxJTkcgaXMgbm90IHNldApDT05GSUdfSEFWRV9PUFJPRklMRT15CiMgQ09ORklHX0tQ
Uk9CRVMgaXMgbm90IHNldAojIENPTkZJR19KVU1QX0xBQkVMIGlzIG5vdCBzZXQKQ09ORklHX0hB
VkVfRUZGSUNJRU5UX1VOQUxJR05FRF9BQ0NFU1M9eQpDT05GSUdfSEFWRV9JT1JFTUFQX1BST1Q9
eQpDT05GSUdfSEFWRV9LUFJPQkVTPXkKQ09ORklHX0hBVkVfS1JFVFBST0JFUz15CkNPTkZJR19I
QVZFX09QVFBST0JFUz15CkNPTkZJR19IQVZFX0FSQ0hfVFJBQ0VIT09LPXkKQ09ORklHX0hBVkVf
RE1BX0FUVFJTPXkKQ09ORklHX1VTRV9HRU5FUklDX1NNUF9IRUxQRVJTPXkKQ09ORklHX0hBVkVf
UkVHU19BTkRfU1RBQ0tfQUNDRVNTX0FQST15CkNPTkZJR19IQVZFX0RNQV9BUElfREVCVUc9eQpD
T05GSUdfSEFWRV9IV19CUkVBS1BPSU5UPXkKQ09ORklHX0hBVkVfTUlYRURfQlJFQUtQT0lOVFNf
UkVHUz15CkNPTkZJR19IQVZFX1VTRVJfUkVUVVJOX05PVElGSUVSPXkKQ09ORklHX0hBVkVfUEVS
Rl9FVkVOVFNfTk1JPXkKQ09ORklHX0hBVkVfQVJDSF9KVU1QX0xBQkVMPXkKCiMKIyBHQ09WLWJh
c2VkIGtlcm5lbCBwcm9maWxpbmcKIwpDT05GSUdfSEFWRV9HRU5FUklDX0RNQV9DT0hFUkVOVD15
CkNPTkZJR19TTEFCSU5GTz15CkNPTkZJR19SVF9NVVRFWEVTPXkKQ09ORklHX0JBU0VfU01BTEw9
MApDT05GSUdfTU9EVUxFUz15CiMgQ09ORklHX01PRFVMRV9GT1JDRV9MT0FEIGlzIG5vdCBzZXQK
Q09ORklHX01PRFVMRV9VTkxPQUQ9eQojIENPTkZJR19NT0RVTEVfRk9SQ0VfVU5MT0FEIGlzIG5v
dCBzZXQKQ09ORklHX01PRFZFUlNJT05TPXkKIyBDT05GSUdfTU9EVUxFX1NSQ1ZFUlNJT05fQUxM
IGlzIG5vdCBzZXQKQ09ORklHX1NUT1BfTUFDSElORT15CkNPTkZJR19CTE9DSz15CkNPTkZJR19M
QkRBRj15CkNPTkZJR19CTEtfREVWX0JTRz15CiMgQ09ORklHX0JMS19ERVZfSU5URUdSSVRZIGlz
IG5vdCBzZXQKCiMKIyBJTyBTY2hlZHVsZXJzCiMKQ09ORklHX0lPU0NIRURfTk9PUD15CkNPTkZJ
R19JT1NDSEVEX0RFQURMSU5FPXkKQ09ORklHX0lPU0NIRURfQ0ZRPXkKIyBDT05GSUdfREVGQVVM
VF9ERUFETElORSBpcyBub3Qgc2V0CkNPTkZJR19ERUZBVUxUX0NGUT15CiMgQ09ORklHX0RFRkFV
TFRfTk9PUCBpcyBub3Qgc2V0CkNPTkZJR19ERUZBVUxUX0lPU0NIRUQ9ImNmcSIKIyBDT05GSUdf
SU5MSU5FX1NQSU5fVFJZTE9DSyBpcyBub3Qgc2V0CiMgQ09ORklHX0lOTElORV9TUElOX1RSWUxP
Q0tfQkggaXMgbm90IHNldAojIENPTkZJR19JTkxJTkVfU1BJTl9MT0NLIGlzIG5vdCBzZXQKIyBD
T05GSUdfSU5MSU5FX1NQSU5fTE9DS19CSCBpcyBub3Qgc2V0CiMgQ09ORklHX0lOTElORV9TUElO
X0xPQ0tfSVJRIGlzIG5vdCBzZXQKIyBDT05GSUdfSU5MSU5FX1NQSU5fTE9DS19JUlFTQVZFIGlz
IG5vdCBzZXQKQ09ORklHX0lOTElORV9TUElOX1VOTE9DSz15CiMgQ09ORklHX0lOTElORV9TUElO
X1VOTE9DS19CSCBpcyBub3Qgc2V0CkNPTkZJR19JTkxJTkVfU1BJTl9VTkxPQ0tfSVJRPXkKIyBD
T05GSUdfSU5MSU5FX1NQSU5fVU5MT0NLX0lSUVJFU1RPUkUgaXMgbm90IHNldAojIENPTkZJR19J
TkxJTkVfUkVBRF9UUllMT0NLIGlzIG5vdCBzZXQKIyBDT05GSUdfSU5MSU5FX1JFQURfTE9DSyBp
cyBub3Qgc2V0CiMgQ09ORklHX0lOTElORV9SRUFEX0xPQ0tfQkggaXMgbm90IHNldAojIENPTkZJ
R19JTkxJTkVfUkVBRF9MT0NLX0lSUSBpcyBub3Qgc2V0CiMgQ09ORklHX0lOTElORV9SRUFEX0xP
Q0tfSVJRU0FWRSBpcyBub3Qgc2V0CkNPTkZJR19JTkxJTkVfUkVBRF9VTkxPQ0s9eQojIENPTkZJ
R19JTkxJTkVfUkVBRF9VTkxPQ0tfQkggaXMgbm90IHNldApDT05GSUdfSU5MSU5FX1JFQURfVU5M
T0NLX0lSUT15CiMgQ09ORklHX0lOTElORV9SRUFEX1VOTE9DS19JUlFSRVNUT1JFIGlzIG5vdCBz
ZXQKIyBDT05GSUdfSU5MSU5FX1dSSVRFX1RSWUxPQ0sgaXMgbm90IHNldAojIENPTkZJR19JTkxJ
TkVfV1JJVEVfTE9DSyBpcyBub3Qgc2V0CiMgQ09ORklHX0lOTElORV9XUklURV9MT0NLX0JIIGlz
IG5vdCBzZXQKIyBDT05GSUdfSU5MSU5FX1dSSVRFX0xPQ0tfSVJRIGlzIG5vdCBzZXQKIyBDT05G
SUdfSU5MSU5FX1dSSVRFX0xPQ0tfSVJRU0FWRSBpcyBub3Qgc2V0CkNPTkZJR19JTkxJTkVfV1JJ
VEVfVU5MT0NLPXkKIyBDT05GSUdfSU5MSU5FX1dSSVRFX1VOTE9DS19CSCBpcyBub3Qgc2V0CkNP
TkZJR19JTkxJTkVfV1JJVEVfVU5MT0NLX0lSUT15CiMgQ09ORklHX0lOTElORV9XUklURV9VTkxP
Q0tfSVJRUkVTVE9SRSBpcyBub3Qgc2V0CkNPTkZJR19NVVRFWF9TUElOX09OX09XTkVSPXkKQ09O
RklHX0ZSRUVaRVI9eQoKIwojIFByb2Nlc3NvciB0eXBlIGFuZCBmZWF0dXJlcwojCkNPTkZJR19U
SUNLX09ORVNIT1Q9eQpDT05GSUdfTk9fSFo9eQojIENPTkZJR19ISUdIX1JFU19USU1FUlMgaXMg
bm90IHNldApDT05GSUdfR0VORVJJQ19DTE9DS0VWRU5UU19CVUlMRD15CkNPTkZJR19TTVA9eQpD
T05GSUdfWDg2X01QUEFSU0U9eQojIENPTkZJR19YODZfQklHU01QIGlzIG5vdCBzZXQKQ09ORklH
X1g4Nl9FWFRFTkRFRF9QTEFURk9STT15CiMgQ09ORklHX1g4Nl9NUlNUIGlzIG5vdCBzZXQKIyBD
T05GSUdfWDg2X1JEQzMyMVggaXMgbm90IHNldAojIENPTkZJR19YODZfMzJfTk9OX1NUQU5EQVJE
IGlzIG5vdCBzZXQKIyBDT05GSUdfWDg2XzMyX0lSSVMgaXMgbm90IHNldApDT05GSUdfU0NIRURf
T01JVF9GUkFNRV9QT0lOVEVSPXkKQ09ORklHX1BBUkFWSVJUX0dVRVNUPXkKQ09ORklHX1hFTj15
CkNPTkZJR19YRU5fRE9NMD15CkNPTkZJR19YRU5fUFJJVklMRUdFRF9HVUVTVD15CkNPTkZJR19Y
RU5fUFZIVk09eQpDT05GSUdfWEVOX01BWF9ET01BSU5fTUVNT1JZPTEyOApDT05GSUdfWEVOX1NB
VkVfUkVTVE9SRT15CiMgQ09ORklHX1hFTl9ERUJVRyBpcyBub3Qgc2V0CiMgQ09ORklHX0tWTV9D
TE9DSyBpcyBub3Qgc2V0CiMgQ09ORklHX0tWTV9HVUVTVCBpcyBub3Qgc2V0CiMgQ09ORklHX0xH
VUVTVF9HVUVTVCBpcyBub3Qgc2V0CkNPTkZJR19QQVJBVklSVD15CiMgQ09ORklHX1BBUkFWSVJU
X1NQSU5MT0NLUyBpcyBub3Qgc2V0CkNPTkZJR19QQVJBVklSVF9DTE9DSz15CkNPTkZJR19OT19C
T09UTUVNPXkKIyBDT05GSUdfTUVNVEVTVCBpcyBub3Qgc2V0CiMgQ09ORklHX00zODYgaXMgbm90
IHNldAojIENPTkZJR19NNDg2IGlzIG5vdCBzZXQKIyBDT05GSUdfTTU4NiBpcyBub3Qgc2V0CiMg
Q09ORklHX001ODZUU0MgaXMgbm90IHNldAojIENPTkZJR19NNTg2TU1YIGlzIG5vdCBzZXQKIyBD
T05GSUdfTTY4NiBpcyBub3Qgc2V0CiMgQ09ORklHX01QRU5USVVNSUkgaXMgbm90IHNldAojIENP
TkZJR19NUEVOVElVTUlJSSBpcyBub3Qgc2V0CiMgQ09ORklHX01QRU5USVVNTSBpcyBub3Qgc2V0
CkNPTkZJR19NUEVOVElVTTQ9eQojIENPTkZJR19NSzYgaXMgbm90IHNldAojIENPTkZJR19NSzcg
aXMgbm90IHNldAojIENPTkZJR19NSzggaXMgbm90IHNldAojIENPTkZJR19NQ1JVU09FIGlzIG5v
dCBzZXQKIyBDT05GSUdfTUVGRklDRU9OIGlzIG5vdCBzZXQKIyBDT05GSUdfTVdJTkNISVBDNiBp
cyBub3Qgc2V0CiMgQ09ORklHX01XSU5DSElQM0QgaXMgbm90IHNldAojIENPTkZJR19NRUxBTiBp
cyBub3Qgc2V0CiMgQ09ORklHX01HRU9ERUdYMSBpcyBub3Qgc2V0CiMgQ09ORklHX01HRU9ERV9M
WCBpcyBub3Qgc2V0CiMgQ09ORklHX01DWVJJWElJSSBpcyBub3Qgc2V0CiMgQ09ORklHX01WSUFD
M18yIGlzIG5vdCBzZXQKIyBDT05GSUdfTVZJQUM3IGlzIG5vdCBzZXQKIyBDT05GSUdfTUNPUkUy
IGlzIG5vdCBzZXQKIyBDT05GSUdfTUFUT00gaXMgbm90IHNldAojIENPTkZJR19YODZfR0VORVJJ
QyBpcyBub3Qgc2V0CkNPTkZJR19YODZfSU5URVJOT0RFX0NBQ0hFX1NISUZUPTcKQ09ORklHX1g4
Nl9DTVBYQ0hHPXkKQ09ORklHX0NNUFhDSEdfTE9DQUw9eQpDT05GSUdfWDg2X0wxX0NBQ0hFX1NI
SUZUPTcKQ09ORklHX1g4Nl9YQUREPXkKQ09ORklHX1g4Nl9XUF9XT1JLU19PSz15CkNPTkZJR19Y
ODZfSU5WTFBHPXkKQ09ORklHX1g4Nl9CU1dBUD15CkNPTkZJR19YODZfUE9QQURfT0s9eQpDT05G
SUdfWDg2X0lOVEVMX1VTRVJDT1BZPXkKQ09ORklHX1g4Nl9VU0VfUFBST19DSEVDS1NVTT15CkNP
TkZJR19YODZfVFNDPXkKQ09ORklHX1g4Nl9DTVBYQ0hHNjQ9eQpDT05GSUdfWDg2X0NNT1Y9eQpD
T05GSUdfWDg2X01JTklNVU1fQ1BVX0ZBTUlMWT01CkNPTkZJR19YODZfREVCVUdDVExNU1I9eQoj
IENPTkZJR19QUk9DRVNTT1JfU0VMRUNUIGlzIG5vdCBzZXQKQ09ORklHX0NQVV9TVVBfSU5URUw9
eQpDT05GSUdfQ1BVX1NVUF9DWVJJWF8zMj15CkNPTkZJR19DUFVfU1VQX0FNRD15CkNPTkZJR19D
UFVfU1VQX0NFTlRBVVI9eQpDT05GSUdfQ1BVX1NVUF9UUkFOU01FVEFfMzI9eQpDT05GSUdfQ1BV
X1NVUF9VTUNfMzI9eQojIENPTkZJR19IUEVUX1RJTUVSIGlzIG5vdCBzZXQKQ09ORklHX0RNST15
CkNPTkZJR19TV0lPVExCPXkKQ09ORklHX0lPTU1VX0hFTFBFUj15CiMgQ09ORklHX0lPTU1VX0FQ
SSBpcyBub3Qgc2V0CkNPTkZJR19OUl9DUFVTPTgKIyBDT05GSUdfU0NIRURfU01UIGlzIG5vdCBz
ZXQKQ09ORklHX1NDSEVEX01DPXkKIyBDT05GSUdfSVJRX1RJTUVfQUNDT1VOVElORyBpcyBub3Qg
c2V0CkNPTkZJR19QUkVFTVBUX05PTkU9eQojIENPTkZJR19QUkVFTVBUX1ZPTFVOVEFSWSBpcyBu
b3Qgc2V0CiMgQ09ORklHX1BSRUVNUFQgaXMgbm90IHNldApDT05GSUdfWDg2X0xPQ0FMX0FQSUM9
eQpDT05GSUdfWDg2X0lPX0FQSUM9eQojIENPTkZJR19YODZfUkVST1VURV9GT1JfQlJPS0VOX0JP
T1RfSVJRUyBpcyBub3Qgc2V0CiMgQ09ORklHX1g4Nl9NQ0UgaXMgbm90IHNldApDT05GSUdfVk04
Nj15CiMgQ09ORklHX1RPU0hJQkEgaXMgbm90IHNldAojIENPTkZJR19JOEsgaXMgbm90IHNldAoj
IENPTkZJR19YODZfUkVCT09URklYVVBTIGlzIG5vdCBzZXQKQ09ORklHX01JQ1JPQ09ERT15CkNP
TkZJR19NSUNST0NPREVfSU5URUw9eQojIENPTkZJR19NSUNST0NPREVfQU1EIGlzIG5vdCBzZXQK
Q09ORklHX01JQ1JPQ09ERV9PTERfSU5URVJGQUNFPXkKIyBDT05GSUdfWDg2X01TUiBpcyBub3Qg
c2V0CkNPTkZJR19YODZfQ1BVSUQ9eQojIENPTkZJR19OT0hJR0hNRU0gaXMgbm90IHNldAojIENP
TkZJR19ISUdITUVNNEcgaXMgbm90IHNldApDT05GSUdfSElHSE1FTTY0Rz15CkNPTkZJR19WTVNQ
TElUXzNHPXkKIyBDT05GSUdfVk1TUExJVF8yRyBpcyBub3Qgc2V0CiMgQ09ORklHX1ZNU1BMSVRf
MUcgaXMgbm90IHNldApDT05GSUdfUEFHRV9PRkZTRVQ9MHhDMDAwMDAwMApDT05GSUdfSElHSE1F
TT15CkNPTkZJR19YODZfUEFFPXkKQ09ORklHX0FSQ0hfUEhZU19BRERSX1RfNjRCSVQ9eQpDT05G
SUdfQVJDSF9ETUFfQUREUl9UXzY0QklUPXkKQ09ORklHX0FSQ0hfRkxBVE1FTV9FTkFCTEU9eQpD
T05GSUdfQVJDSF9TUEFSU0VNRU1fRU5BQkxFPXkKQ09ORklHX0FSQ0hfU0VMRUNUX01FTU9SWV9N
T0RFTD15CkNPTkZJR19JTExFR0FMX1BPSU5URVJfVkFMVUU9MApDT05GSUdfU0VMRUNUX01FTU9S
WV9NT0RFTD15CkNPTkZJR19GTEFUTUVNX01BTlVBTD15CiMgQ09ORklHX1NQQVJTRU1FTV9NQU5V
QUwgaXMgbm90IHNldApDT05GSUdfRkxBVE1FTT15CkNPTkZJR19GTEFUX05PREVfTUVNX01BUD15
CkNPTkZJR19TUEFSU0VNRU1fU1RBVElDPXkKQ09ORklHX0hBVkVfTUVNQkxPQ0s9eQpDT05GSUdf
UEFHRUZMQUdTX0VYVEVOREVEPXkKQ09ORklHX1NQTElUX1BUTE9DS19DUFVTPTQKIyBDT05GSUdf
Q09NUEFDVElPTiBpcyBub3Qgc2V0CkNPTkZJR19QSFlTX0FERFJfVF82NEJJVD15CkNPTkZJR19a
T05FX0RNQV9GTEFHPTEKQ09ORklHX0JPVU5DRT15CkNPTkZJR19WSVJUX1RPX0JVUz15CkNPTkZJ
R19NTVVfTk9USUZJRVI9eQojIENPTkZJR19LU00gaXMgbm90IHNldApDT05GSUdfREVGQVVMVF9N
TUFQX01JTl9BRERSPTQwOTYKIyBDT05GSUdfVFJBTlNQQVJFTlRfSFVHRVBBR0UgaXMgbm90IHNl
dAojIENPTkZJR19DTEVBTkNBQ0hFIGlzIG5vdCBzZXQKIyBDT05GSUdfSElHSFBURSBpcyBub3Qg
c2V0CiMgQ09ORklHX1g4Nl9DSEVDS19CSU9TX0NPUlJVUFRJT04gaXMgbm90IHNldApDT05GSUdf
WDg2X1JFU0VSVkVfTE9XPTY0CiMgQ09ORklHX01BVEhfRU1VTEFUSU9OIGlzIG5vdCBzZXQKQ09O
RklHX01UUlI9eQpDT05GSUdfTVRSUl9TQU5JVElaRVI9eQpDT05GSUdfTVRSUl9TQU5JVElaRVJf
RU5BQkxFX0RFRkFVTFQ9MApDT05GSUdfTVRSUl9TQU5JVElaRVJfU1BBUkVfUkVHX05SX0RFRkFV
TFQ9MQpDT05GSUdfWDg2X1BBVD15CkNPTkZJR19BUkNIX1VTRVNfUEdfVU5DQUNIRUQ9eQojIENP
TkZJR19FRkkgaXMgbm90IHNldApDT05GSUdfU0VDQ09NUD15CiMgQ09ORklHX0NDX1NUQUNLUFJP
VEVDVE9SIGlzIG5vdCBzZXQKQ09ORklHX0haXzEwMD15CiMgQ09ORklHX0haXzI1MCBpcyBub3Qg
c2V0CiMgQ09ORklHX0haXzMwMCBpcyBub3Qgc2V0CiMgQ09ORklHX0haXzEwMDAgaXMgbm90IHNl
dApDT05GSUdfSFo9MTAwCiMgQ09ORklHX1NDSEVEX0hSVElDSyBpcyBub3Qgc2V0CiMgQ09ORklH
X0tFWEVDIGlzIG5vdCBzZXQKIyBDT05GSUdfQ1JBU0hfRFVNUCBpcyBub3Qgc2V0CkNPTkZJR19Q
SFlTSUNBTF9TVEFSVD0weDEwMDAwMDAKQ09ORklHX1JFTE9DQVRBQkxFPXkKQ09ORklHX1g4Nl9O
RUVEX1JFTE9DUz15CkNPTkZJR19QSFlTSUNBTF9BTElHTj0weDEwMDAwMDAKQ09ORklHX0hPVFBM
VUdfQ1BVPXkKQ09ORklHX0NPTVBBVF9WRFNPPXkKIyBDT05GSUdfQ01ETElORV9CT09MIGlzIG5v
dCBzZXQKQ09ORklHX0FSQ0hfRU5BQkxFX01FTU9SWV9IT1RQTFVHPXkKCiMKIyBQb3dlciBtYW5h
Z2VtZW50IGFuZCBBQ1BJIG9wdGlvbnMKIwojIENPTkZJR19TVVNQRU5EIGlzIG5vdCBzZXQKQ09O
RklHX0hJQkVSTkFURV9DQUxMQkFDS1M9eQojIENPTkZJR19ISUJFUk5BVElPTiBpcyBub3Qgc2V0
CkNPTkZJR19QTV9TTEVFUD15CkNPTkZJR19QTV9TTEVFUF9TTVA9eQojIENPTkZJR19QTV9SVU5U
SU1FIGlzIG5vdCBzZXQKQ09ORklHX1BNPXkKIyBDT05GSUdfUE1fREVCVUcgaXMgbm90IHNldApD
T05GSUdfQUNQST15CiMgQ09ORklHX0FDUElfUFJPQ0ZTIGlzIG5vdCBzZXQKIyBDT05GSUdfQUNQ
SV9QUk9DRlNfUE9XRVIgaXMgbm90IHNldAojIENPTkZJR19BQ1BJX0VDX0RFQlVHRlMgaXMgbm90
IHNldApDT05GSUdfQUNQSV9QUk9DX0VWRU5UPXkKIyBDT05GSUdfQUNQSV9BQyBpcyBub3Qgc2V0
CiMgQ09ORklHX0FDUElfQkFUVEVSWSBpcyBub3Qgc2V0CkNPTkZJR19BQ1BJX0JVVFRPTj1tCkNP
TkZJR19BQ1BJX0ZBTj1tCiMgQ09ORklHX0FDUElfRE9DSyBpcyBub3Qgc2V0CkNPTkZJR19BQ1BJ
X1BST0NFU1NPUj15CiMgQ09ORklHX0FDUElfSVBNSSBpcyBub3Qgc2V0CkNPTkZJR19BQ1BJX0hP
VFBMVUdfQ1BVPXkKIyBDT05GSUdfQUNQSV9QUk9DRVNTT1JfQUdHUkVHQVRPUiBpcyBub3Qgc2V0
CkNPTkZJR19BQ1BJX1RIRVJNQUw9bQojIENPTkZJR19BQ1BJX0NVU1RPTV9EU0RUIGlzIG5vdCBz
ZXQKQ09ORklHX0FDUElfQkxBQ0tMSVNUX1lFQVI9MAojIENPTkZJR19BQ1BJX0RFQlVHIGlzIG5v
dCBzZXQKIyBDT05GSUdfQUNQSV9QQ0lfU0xPVCBpcyBub3Qgc2V0CkNPTkZJR19YODZfUE1fVElN
RVI9eQpDT05GSUdfQUNQSV9DT05UQUlORVI9eQojIENPTkZJR19BQ1BJX1NCUyBpcyBub3Qgc2V0
CiMgQ09ORklHX0FDUElfSEVEIGlzIG5vdCBzZXQKIyBDT05GSUdfQUNQSV9BUEVJIGlzIG5vdCBz
ZXQKIyBDT05GSUdfU0ZJIGlzIG5vdCBzZXQKIyBDT05GSUdfQVBNIGlzIG5vdCBzZXQKCiMKIyBD
UFUgRnJlcXVlbmN5IHNjYWxpbmcKIwojIENPTkZJR19DUFVfRlJFUSBpcyBub3Qgc2V0CkNPTkZJ
R19DUFVfSURMRT15CkNPTkZJR19DUFVfSURMRV9HT1ZfTEFEREVSPXkKQ09ORklHX0NQVV9JRExF
X0dPVl9NRU5VPXkKIyBDT05GSUdfSU5URUxfSURMRSBpcyBub3Qgc2V0CgojCiMgQnVzIG9wdGlv
bnMgKFBDSSBldGMuKQojCkNPTkZJR19QQ0k9eQojIENPTkZJR19QQ0lfR09CSU9TIGlzIG5vdCBz
ZXQKIyBDT05GSUdfUENJX0dPTU1DT05GSUcgaXMgbm90IHNldAojIENPTkZJR19QQ0lfR09ESVJF
Q1QgaXMgbm90IHNldApDT05GSUdfUENJX0dPQU5ZPXkKQ09ORklHX1BDSV9CSU9TPXkKQ09ORklH
X1BDSV9ESVJFQ1Q9eQpDT05GSUdfUENJX01NQ09ORklHPXkKQ09ORklHX1BDSV9YRU49eQpDT05G
SUdfUENJX0RPTUFJTlM9eQojIENPTkZJR19QQ0lfQ05CMjBMRV9RVUlSSyBpcyBub3Qgc2V0CiMg
Q09ORklHX0RNQVIgaXMgbm90IHNldApDT05GSUdfUENJRVBPUlRCVVM9eQojIENPTkZJR19IT1RQ
TFVHX1BDSV9QQ0lFIGlzIG5vdCBzZXQKQ09ORklHX1BDSUVBRVI9eQojIENPTkZJR19QQ0lFX0VD
UkMgaXMgbm90IHNldAojIENPTkZJR19QQ0lFQUVSX0lOSkVDVCBpcyBub3Qgc2V0CkNPTkZJR19Q
Q0lFQVNQTT15CiMgQ09ORklHX1BDSUVBU1BNX0RFQlVHIGlzIG5vdCBzZXQKQ09ORklHX0FSQ0hf
U1VQUE9SVFNfTVNJPXkKQ09ORklHX1BDSV9NU0k9eQojIENPTkZJR19QQ0lfU1RVQiBpcyBub3Qg
c2V0CiMgQ09ORklHX1hFTl9QQ0lERVZfRlJPTlRFTkQgaXMgbm90IHNldApDT05GSUdfSFRfSVJR
PXkKIyBDT05GSUdfUENJX0lPViBpcyBub3Qgc2V0CkNPTkZJR19QQ0lfSU9BUElDPXkKQ09ORklH
X1BDSV9MQUJFTD15CkNPTkZJR19JU0FfRE1BX0FQST15CiMgQ09ORklHX0lTQSBpcyBub3Qgc2V0
CiMgQ09ORklHX01DQSBpcyBub3Qgc2V0CiMgQ09ORklHX1NDeDIwMCBpcyBub3Qgc2V0CkNPTkZJ
R19BTURfTkI9eQojIENPTkZJR19QQ0NBUkQgaXMgbm90IHNldApDT05GSUdfSE9UUExVR19QQ0k9
bQpDT05GSUdfSE9UUExVR19QQ0lfRkFLRT1tCiMgQ09ORklHX0hPVFBMVUdfUENJX0NPTVBBUSBp
cyBub3Qgc2V0CiMgQ09ORklHX0hPVFBMVUdfUENJX0lCTSBpcyBub3Qgc2V0CkNPTkZJR19IT1RQ
TFVHX1BDSV9BQ1BJPW0KQ09ORklHX0hPVFBMVUdfUENJX0FDUElfSUJNPW0KQ09ORklHX0hPVFBM
VUdfUENJX0NQQ0k9eQojIENPTkZJR19IT1RQTFVHX1BDSV9DUENJX1pUNTU1MCBpcyBub3Qgc2V0
CiMgQ09ORklHX0hPVFBMVUdfUENJX0NQQ0lfR0VORVJJQyBpcyBub3Qgc2V0CiMgQ09ORklHX0hP
VFBMVUdfUENJX1NIUEMgaXMgbm90IHNldAojIENPTkZJR19SQVBJRElPIGlzIG5vdCBzZXQKCiMK
IyBFeGVjdXRhYmxlIGZpbGUgZm9ybWF0cyAvIEVtdWxhdGlvbnMKIwpDT05GSUdfQklORk1UX0VM
Rj15CkNPTkZJR19DT1JFX0RVTVBfREVGQVVMVF9FTEZfSEVBREVSUz15CkNPTkZJR19IQVZFX0FP
VVQ9eQojIENPTkZJR19CSU5GTVRfQU9VVCBpcyBub3Qgc2V0CiMgQ09ORklHX0JJTkZNVF9NSVND
IGlzIG5vdCBzZXQKQ09ORklHX0hBVkVfQVRPTUlDX0lPTUFQPXkKQ09ORklHX0hBVkVfVEVYVF9Q
T0tFX1NNUD15CkNPTkZJR19ORVQ9eQoKIwojIE5ldHdvcmtpbmcgb3B0aW9ucwojCkNPTkZJR19Q
QUNLRVQ9eQpDT05GSUdfVU5JWD15CkNPTkZJR19YRlJNPXkKIyBDT05GSUdfWEZSTV9VU0VSIGlz
IG5vdCBzZXQKIyBDT05GSUdfWEZSTV9TVUJfUE9MSUNZIGlzIG5vdCBzZXQKIyBDT05GSUdfWEZS
TV9NSUdSQVRFIGlzIG5vdCBzZXQKIyBDT05GSUdfWEZSTV9TVEFUSVNUSUNTIGlzIG5vdCBzZXQK
Q09ORklHX1hGUk1fSVBDT01QPW0KQ09ORklHX05FVF9LRVk9bQojIENPTkZJR19ORVRfS0VZX01J
R1JBVEUgaXMgbm90IHNldApDT05GSUdfSU5FVD15CiMgQ09ORklHX0lQX01VTFRJQ0FTVCBpcyBu
b3Qgc2V0CiMgQ09ORklHX0lQX0FEVkFOQ0VEX1JPVVRFUiBpcyBub3Qgc2V0CkNPTkZJR19JUF9S
T1VURV9DTEFTU0lEPXkKQ09ORklHX0lQX1BOUD15CkNPTkZJR19JUF9QTlBfREhDUD15CiMgQ09O
RklHX0lQX1BOUF9CT09UUCBpcyBub3Qgc2V0CiMgQ09ORklHX0lQX1BOUF9SQVJQIGlzIG5vdCBz
ZXQKIyBDT05GSUdfTkVUX0lQSVAgaXMgbm90IHNldAojIENPTkZJR19ORVRfSVBHUkVfREVNVVgg
aXMgbm90IHNldAojIENPTkZJR19BUlBEIGlzIG5vdCBzZXQKQ09ORklHX1NZTl9DT09LSUVTPXkK
Q09ORklHX0lORVRfQUg9bQpDT05GSUdfSU5FVF9FU1A9bQpDT05GSUdfSU5FVF9JUENPTVA9bQpD
T05GSUdfSU5FVF9YRlJNX1RVTk5FTD1tCkNPTkZJR19JTkVUX1RVTk5FTD1tCkNPTkZJR19JTkVU
X1hGUk1fTU9ERV9UUkFOU1BPUlQ9bQpDT05GSUdfSU5FVF9YRlJNX01PREVfVFVOTkVMPW0KQ09O
RklHX0lORVRfWEZSTV9NT0RFX0JFRVQ9eQpDT05GSUdfSU5FVF9MUk89bQpDT05GSUdfSU5FVF9E
SUFHPW0KQ09ORklHX0lORVRfVENQX0RJQUc9bQojIENPTkZJR19UQ1BfQ09OR19BRFZBTkNFRCBp
cyBub3Qgc2V0CkNPTkZJR19UQ1BfQ09OR19DVUJJQz15CkNPTkZJR19ERUZBVUxUX1RDUF9DT05H
PSJjdWJpYyIKIyBDT05GSUdfVENQX01ENVNJRyBpcyBub3Qgc2V0CkNPTkZJR19JUFY2PW0KQ09O
RklHX0lQVjZfUFJJVkFDWT15CiMgQ09ORklHX0lQVjZfUk9VVEVSX1BSRUYgaXMgbm90IHNldAoj
IENPTkZJR19JUFY2X09QVElNSVNUSUNfREFEIGlzIG5vdCBzZXQKQ09ORklHX0lORVQ2X0FIPW0K
Q09ORklHX0lORVQ2X0VTUD1tCkNPTkZJR19JTkVUNl9JUENPTVA9bQojIENPTkZJR19JUFY2X01J
UDYgaXMgbm90IHNldApDT05GSUdfSU5FVDZfWEZSTV9UVU5ORUw9bQpDT05GSUdfSU5FVDZfVFVO
TkVMPW0KQ09ORklHX0lORVQ2X1hGUk1fTU9ERV9UUkFOU1BPUlQ9bQpDT05GSUdfSU5FVDZfWEZS
TV9NT0RFX1RVTk5FTD1tCkNPTkZJR19JTkVUNl9YRlJNX01PREVfQkVFVD1tCiMgQ09ORklHX0lO
RVQ2X1hGUk1fTU9ERV9ST1VURU9QVElNSVpBVElPTiBpcyBub3Qgc2V0CkNPTkZJR19JUFY2X1NJ
VD1tCiMgQ09ORklHX0lQVjZfU0lUXzZSRCBpcyBub3Qgc2V0CkNPTkZJR19JUFY2X05ESVNDX05P
REVUWVBFPXkKQ09ORklHX0lQVjZfVFVOTkVMPW0KIyBDT05GSUdfSVBWNl9NVUxUSVBMRV9UQUJM
RVMgaXMgbm90IHNldAojIENPTkZJR19JUFY2X01ST1VURSBpcyBub3Qgc2V0CiMgQ09ORklHX05F
VFdPUktfU0VDTUFSSyBpcyBub3Qgc2V0CiMgQ09ORklHX05FVFdPUktfUEhZX1RJTUVTVEFNUElO
RyBpcyBub3Qgc2V0CkNPTkZJR19ORVRGSUxURVI9eQojIENPTkZJR19ORVRGSUxURVJfREVCVUcg
aXMgbm90IHNldApDT05GSUdfTkVURklMVEVSX0FEVkFOQ0VEPXkKQ09ORklHX0JSSURHRV9ORVRG
SUxURVI9eQoKIwojIENvcmUgTmV0ZmlsdGVyIENvbmZpZ3VyYXRpb24KIwpDT05GSUdfTkVURklM
VEVSX05FVExJTks9bQpDT05GSUdfTkVURklMVEVSX05FVExJTktfUVVFVUU9bQpDT05GSUdfTkVU
RklMVEVSX05FVExJTktfTE9HPW0KIyBDT05GSUdfTkZfQ09OTlRSQUNLIGlzIG5vdCBzZXQKIyBD
T05GSUdfTkVURklMVEVSX1RQUk9YWSBpcyBub3Qgc2V0CkNPTkZJR19ORVRGSUxURVJfWFRBQkxF
Uz1tCgojCiMgWHRhYmxlcyBjb21iaW5lZCBtb2R1bGVzCiMKQ09ORklHX05FVEZJTFRFUl9YVF9N
QVJLPW0KCiMKIyBYdGFibGVzIHRhcmdldHMKIwojIENPTkZJR19ORVRGSUxURVJfWFRfVEFSR0VU
X0NIRUNLU1VNIGlzIG5vdCBzZXQKQ09ORklHX05FVEZJTFRFUl9YVF9UQVJHRVRfQ0xBU1NJRlk9
bQojIENPTkZJR19ORVRGSUxURVJfWFRfVEFSR0VUX0RTQ1AgaXMgbm90IHNldApDT05GSUdfTkVU
RklMVEVSX1hUX1RBUkdFVF9ITD1tCiMgQ09ORklHX05FVEZJTFRFUl9YVF9UQVJHRVRfSURMRVRJ
TUVSIGlzIG5vdCBzZXQKQ09ORklHX05FVEZJTFRFUl9YVF9UQVJHRVRfTUFSSz1tCiMgQ09ORklH
X05FVEZJTFRFUl9YVF9UQVJHRVRfTkZMT0cgaXMgbm90IHNldApDT05GSUdfTkVURklMVEVSX1hU
X1RBUkdFVF9ORlFVRVVFPW0KIyBDT05GSUdfTkVURklMVEVSX1hUX1RBUkdFVF9SQVRFRVNUIGlz
IG5vdCBzZXQKIyBDT05GSUdfTkVURklMVEVSX1hUX1RBUkdFVF9URUUgaXMgbm90IHNldAojIENP
TkZJR19ORVRGSUxURVJfWFRfVEFSR0VUX1RSQUNFIGlzIG5vdCBzZXQKIyBDT05GSUdfTkVURklM
VEVSX1hUX1RBUkdFVF9UQ1BNU1MgaXMgbm90IHNldAojIENPTkZJR19ORVRGSUxURVJfWFRfVEFS
R0VUX1RDUE9QVFNUUklQIGlzIG5vdCBzZXQKCiMKIyBYdGFibGVzIG1hdGNoZXMKIwojIENPTkZJ
R19ORVRGSUxURVJfWFRfTUFUQ0hfQUREUlRZUEUgaXMgbm90IHNldApDT05GSUdfTkVURklMVEVS
X1hUX01BVENIX0NPTU1FTlQ9bQojIENPTkZJR19ORVRGSUxURVJfWFRfTUFUQ0hfQ1BVIGlzIG5v
dCBzZXQKQ09ORklHX05FVEZJTFRFUl9YVF9NQVRDSF9EQ0NQPW0KIyBDT05GSUdfTkVURklMVEVS
X1hUX01BVENIX0RFVkdST1VQIGlzIG5vdCBzZXQKIyBDT05GSUdfTkVURklMVEVSX1hUX01BVENI
X0RTQ1AgaXMgbm90IHNldApDT05GSUdfTkVURklMVEVSX1hUX01BVENIX0VTUD1tCiMgQ09ORklH
X05FVEZJTFRFUl9YVF9NQVRDSF9IQVNITElNSVQgaXMgbm90IHNldApDT05GSUdfTkVURklMVEVS
X1hUX01BVENIX0hMPW0KIyBDT05GSUdfTkVURklMVEVSX1hUX01BVENIX0lQUkFOR0UgaXMgbm90
IHNldApDT05GSUdfTkVURklMVEVSX1hUX01BVENIX0xFTkdUSD1tCkNPTkZJR19ORVRGSUxURVJf
WFRfTUFUQ0hfTElNSVQ9bQpDT05GSUdfTkVURklMVEVSX1hUX01BVENIX01BQz1tCkNPTkZJR19O
RVRGSUxURVJfWFRfTUFUQ0hfTUFSSz1tCkNPTkZJR19ORVRGSUxURVJfWFRfTUFUQ0hfTVVMVElQ
T1JUPW0KIyBDT05GSUdfTkVURklMVEVSX1hUX01BVENIX09TRiBpcyBub3Qgc2V0CiMgQ09ORklH
X05FVEZJTFRFUl9YVF9NQVRDSF9PV05FUiBpcyBub3Qgc2V0CkNPTkZJR19ORVRGSUxURVJfWFRf
TUFUQ0hfUE9MSUNZPW0KQ09ORklHX05FVEZJTFRFUl9YVF9NQVRDSF9QSFlTREVWPW0KQ09ORklH
X05FVEZJTFRFUl9YVF9NQVRDSF9QS1RUWVBFPW0KQ09ORklHX05FVEZJTFRFUl9YVF9NQVRDSF9R
VU9UQT1tCiMgQ09ORklHX05FVEZJTFRFUl9YVF9NQVRDSF9SQVRFRVNUIGlzIG5vdCBzZXQKQ09O
RklHX05FVEZJTFRFUl9YVF9NQVRDSF9SRUFMTT1tCiMgQ09ORklHX05FVEZJTFRFUl9YVF9NQVRD
SF9SRUNFTlQgaXMgbm90IHNldApDT05GSUdfTkVURklMVEVSX1hUX01BVENIX1NDVFA9bQpDT05G
SUdfTkVURklMVEVSX1hUX01BVENIX1NUQVRJU1RJQz1tCkNPTkZJR19ORVRGSUxURVJfWFRfTUFU
Q0hfU1RSSU5HPW0KQ09ORklHX05FVEZJTFRFUl9YVF9NQVRDSF9UQ1BNU1M9bQojIENPTkZJR19O
RVRGSUxURVJfWFRfTUFUQ0hfVElNRSBpcyBub3Qgc2V0CiMgQ09ORklHX05FVEZJTFRFUl9YVF9N
QVRDSF9VMzIgaXMgbm90IHNldAojIENPTkZJR19JUF9TRVQgaXMgbm90IHNldAojIENPTkZJR19J
UF9WUyBpcyBub3Qgc2V0CgojCiMgSVA6IE5ldGZpbHRlciBDb25maWd1cmF0aW9uCiMKIyBDT05G
SUdfTkZfREVGUkFHX0lQVjQgaXMgbm90IHNldAojIENPTkZJR19JUF9ORl9RVUVVRSBpcyBub3Qg
c2V0CkNPTkZJR19JUF9ORl9JUFRBQkxFUz1tCkNPTkZJR19JUF9ORl9NQVRDSF9BSD1tCkNPTkZJ
R19JUF9ORl9NQVRDSF9FQ049bQpDT05GSUdfSVBfTkZfTUFUQ0hfVFRMPW0KQ09ORklHX0lQX05G
X0ZJTFRFUj1tCkNPTkZJR19JUF9ORl9UQVJHRVRfUkVKRUNUPW0KQ09ORklHX0lQX05GX1RBUkdF
VF9MT0c9bQpDT05GSUdfSVBfTkZfVEFSR0VUX1VMT0c9bQpDT05GSUdfSVBfTkZfTUFOR0xFPW0K
Q09ORklHX0lQX05GX1RBUkdFVF9FQ049bQpDT05GSUdfSVBfTkZfVEFSR0VUX1RUTD1tCkNPTkZJ
R19JUF9ORl9SQVc9bQpDT05GSUdfSVBfTkZfQVJQVEFCTEVTPW0KQ09ORklHX0lQX05GX0FSUEZJ
TFRFUj1tCkNPTkZJR19JUF9ORl9BUlBfTUFOR0xFPW0KCiMKIyBJUHY2OiBOZXRmaWx0ZXIgQ29u
ZmlndXJhdGlvbgojCiMgQ09ORklHX05GX0RFRlJBR19JUFY2IGlzIG5vdCBzZXQKIyBDT05GSUdf
SVA2X05GX1FVRVVFIGlzIG5vdCBzZXQKIyBDT05GSUdfSVA2X05GX0lQVEFCTEVTIGlzIG5vdCBz
ZXQKQ09ORklHX0JSSURHRV9ORl9FQlRBQkxFUz1tCkNPTkZJR19CUklER0VfRUJUX0JST1VURT1t
CkNPTkZJR19CUklER0VfRUJUX1RfRklMVEVSPW0KQ09ORklHX0JSSURHRV9FQlRfVF9OQVQ9bQpD
T05GSUdfQlJJREdFX0VCVF84MDJfMz1tCkNPTkZJR19CUklER0VfRUJUX0FNT05HPW0KQ09ORklH
X0JSSURHRV9FQlRfQVJQPW0KQ09ORklHX0JSSURHRV9FQlRfSVA9bQojIENPTkZJR19CUklER0Vf
RUJUX0lQNiBpcyBub3Qgc2V0CkNPTkZJR19CUklER0VfRUJUX0xJTUlUPW0KQ09ORklHX0JSSURH
RV9FQlRfTUFSSz1tCkNPTkZJR19CUklER0VfRUJUX1BLVFRZUEU9bQpDT05GSUdfQlJJREdFX0VC
VF9TVFA9bQpDT05GSUdfQlJJREdFX0VCVF9WTEFOPW0KQ09ORklHX0JSSURHRV9FQlRfQVJQUkVQ
TFk9bQpDT05GSUdfQlJJREdFX0VCVF9ETkFUPW0KQ09ORklHX0JSSURHRV9FQlRfTUFSS19UPW0K
Q09ORklHX0JSSURHRV9FQlRfUkVESVJFQ1Q9bQpDT05GSUdfQlJJREdFX0VCVF9TTkFUPW0KQ09O
RklHX0JSSURHRV9FQlRfTE9HPW0KQ09ORklHX0JSSURHRV9FQlRfVUxPRz1tCiMgQ09ORklHX0JS
SURHRV9FQlRfTkZMT0cgaXMgbm90IHNldAojIENPTkZJR19JUF9EQ0NQIGlzIG5vdCBzZXQKQ09O
RklHX0lQX1NDVFA9bQojIENPTkZJR19TQ1RQX0RCR19NU0cgaXMgbm90IHNldAojIENPTkZJR19T
Q1RQX0RCR19PQkpDTlQgaXMgbm90IHNldAojIENPTkZJR19TQ1RQX0hNQUNfTk9ORSBpcyBub3Qg
c2V0CiMgQ09ORklHX1NDVFBfSE1BQ19TSEExIGlzIG5vdCBzZXQKQ09ORklHX1NDVFBfSE1BQ19N
RDU9eQojIENPTkZJR19SRFMgaXMgbm90IHNldAojIENPTkZJR19USVBDIGlzIG5vdCBzZXQKIyBD
T05GSUdfQVRNIGlzIG5vdCBzZXQKIyBDT05GSUdfTDJUUCBpcyBub3Qgc2V0CkNPTkZJR19TVFA9
bQpDT05GSUdfQlJJREdFPW0KQ09ORklHX0JSSURHRV9JR01QX1NOT09QSU5HPXkKIyBDT05GSUdf
TkVUX0RTQSBpcyBub3Qgc2V0CkNPTkZJR19WTEFOXzgwMjFRPW0KIyBDT05GSUdfVkxBTl84MDIx
UV9HVlJQIGlzIG5vdCBzZXQKIyBDT05GSUdfREVDTkVUIGlzIG5vdCBzZXQKQ09ORklHX0xMQz15
CiMgQ09ORklHX0xMQzIgaXMgbm90IHNldAojIENPTkZJR19JUFggaXMgbm90IHNldAojIENPTkZJ
R19BVEFMSyBpcyBub3Qgc2V0CiMgQ09ORklHX1gyNSBpcyBub3Qgc2V0CiMgQ09ORklHX0xBUEIg
aXMgbm90IHNldAojIENPTkZJR19FQ09ORVQgaXMgbm90IHNldAojIENPTkZJR19XQU5fUk9VVEVS
IGlzIG5vdCBzZXQKIyBDT05GSUdfUEhPTkVUIGlzIG5vdCBzZXQKIyBDT05GSUdfSUVFRTgwMjE1
NCBpcyBub3Qgc2V0CiMgQ09ORklHX05FVF9TQ0hFRCBpcyBub3Qgc2V0CiMgQ09ORklHX0RDQiBp
cyBub3Qgc2V0CiMgQ09ORklHX0JBVE1BTl9BRFYgaXMgbm90IHNldApDT05GSUdfUlBTPXkKQ09O
RklHX1JGU19BQ0NFTD15CkNPTkZJR19YUFM9eQoKIwojIE5ldHdvcmsgdGVzdGluZwojCiMgQ09O
RklHX05FVF9QS1RHRU4gaXMgbm90IHNldAojIENPTkZJR19IQU1SQURJTyBpcyBub3Qgc2V0CiMg
Q09ORklHX0NBTiBpcyBub3Qgc2V0CiMgQ09ORklHX0lSREEgaXMgbm90IHNldAojIENPTkZJR19C
VCBpcyBub3Qgc2V0CiMgQ09ORklHX0FGX1JYUlBDIGlzIG5vdCBzZXQKIyBDT05GSUdfV0lSRUxF
U1MgaXMgbm90IHNldAojIENPTkZJR19XSU1BWCBpcyBub3Qgc2V0CiMgQ09ORklHX1JGS0lMTCBp
cyBub3Qgc2V0CiMgQ09ORklHX05FVF85UCBpcyBub3Qgc2V0CiMgQ09ORklHX0NBSUYgaXMgbm90
IHNldAojIENPTkZJR19DRVBIX0xJQiBpcyBub3Qgc2V0CgojCiMgRGV2aWNlIERyaXZlcnMKIwoK
IwojIEdlbmVyaWMgRHJpdmVyIE9wdGlvbnMKIwpDT05GSUdfVUVWRU5UX0hFTFBFUl9QQVRIPSIi
CiMgQ09ORklHX0RFVlRNUEZTIGlzIG5vdCBzZXQKQ09ORklHX1NUQU5EQUxPTkU9eQpDT05GSUdf
UFJFVkVOVF9GSVJNV0FSRV9CVUlMRD15CkNPTkZJR19GV19MT0FERVI9eQojIENPTkZJR19GSVJN
V0FSRV9JTl9LRVJORUwgaXMgbm90IHNldApDT05GSUdfRVhUUkFfRklSTVdBUkU9IiIKQ09ORklH
X1NZU19IWVBFUlZJU09SPXkKIyBDT05GSUdfQ09OTkVDVE9SIGlzIG5vdCBzZXQKIyBDT05GSUdf
TVREIGlzIG5vdCBzZXQKQ09ORklHX1BBUlBPUlQ9bQpDT05GSUdfUEFSUE9SVF9QQz1tCkNPTkZJ
R19QQVJQT1JUX1NFUklBTD1tCiMgQ09ORklHX1BBUlBPUlRfUENfRklGTyBpcyBub3Qgc2V0CiMg
Q09ORklHX1BBUlBPUlRfUENfU1VQRVJJTyBpcyBub3Qgc2V0CiMgQ09ORklHX1BBUlBPUlRfR1ND
IGlzIG5vdCBzZXQKIyBDT05GSUdfUEFSUE9SVF9BWDg4Nzk2IGlzIG5vdCBzZXQKQ09ORklHX1BB
UlBPUlRfMTI4ND15CkNPTkZJR19QTlA9eQpDT05GSUdfUE5QX0RFQlVHX01FU1NBR0VTPXkKCiMK
IyBQcm90b2NvbHMKIwpDT05GSUdfUE5QQUNQST15CkNPTkZJR19CTEtfREVWPXkKQ09ORklHX0JM
S19ERVZfRkQ9bQojIENPTkZJR19QQVJJREUgaXMgbm90IHNldApDT05GSUdfQkxLX0NQUV9EQT1t
CkNPTkZJR19CTEtfQ1BRX0NJU1NfREE9bQpDT05GSUdfQ0lTU19TQ1NJX1RBUEU9eQpDT05GSUdf
QkxLX0RFVl9EQUM5NjA9bQpDT05GSUdfQkxLX0RFVl9VTUVNPW0KIyBDT05GSUdfQkxLX0RFVl9D
T1dfQ09NTU9OIGlzIG5vdCBzZXQKQ09ORklHX0JMS19ERVZfTE9PUD1tCkNPTkZJR19CTEtfREVW
X0NSWVBUT0xPT1A9bQoKIwojIERSQkQgZGlzYWJsZWQgYmVjYXVzZSBQUk9DX0ZTLCBJTkVUIG9y
IENPTk5FQ1RPUiBub3Qgc2VsZWN0ZWQKIwpDT05GSUdfQkxLX0RFVl9OQkQ9bQpDT05GSUdfQkxL
X0RFVl9TWDg9bQpDT05GSUdfQkxLX0RFVl9VQj1tCiMgQ09ORklHX0JMS19ERVZfUkFNIGlzIG5v
dCBzZXQKQ09ORklHX0NEUk9NX1BLVENEVkQ9bQpDT05GSUdfQ0RST01fUEtUQ0RWRF9CVUZGRVJT
PTgKIyBDT05GSUdfQ0RST01fUEtUQ0RWRF9XQ0FDSEUgaXMgbm90IHNldApDT05GSUdfQVRBX09W
RVJfRVRIPW0KIyBDT05GSUdfWEVOX0JMS0RFVl9GUk9OVEVORCBpcyBub3Qgc2V0CkNPTkZJR19Y
RU5fQkxLREVWX0JBQ0tFTkQ9eQojIENPTkZJR19CTEtfREVWX0hEIGlzIG5vdCBzZXQKIyBDT05G
SUdfQkxLX0RFVl9SQkQgaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JTX0xJUzNMVjAyRCBpcyBu
b3Qgc2V0CiMgQ09ORklHX01JU0NfREVWSUNFUyBpcyBub3Qgc2V0CkNPTkZJR19IQVZFX0lERT15
CiMgQ09ORklHX0lERSBpcyBub3Qgc2V0CgojCiMgU0NTSSBkZXZpY2Ugc3VwcG9ydAojCkNPTkZJ
R19TQ1NJX01PRD1tCkNPTkZJR19SQUlEX0FUVFJTPW0KQ09ORklHX1NDU0k9bQpDT05GSUdfU0NT
SV9ETUE9eQojIENPTkZJR19TQ1NJX1RHVCBpcyBub3Qgc2V0CkNPTkZJR19TQ1NJX05FVExJTks9
eQpDT05GSUdfU0NTSV9QUk9DX0ZTPXkKCiMKIyBTQ1NJIHN1cHBvcnQgdHlwZSAoZGlzaywgdGFw
ZSwgQ0QtUk9NKQojCkNPTkZJR19CTEtfREVWX1NEPW0KQ09ORklHX0NIUl9ERVZfU1Q9bQpDT05G
SUdfQ0hSX0RFVl9PU1NUPW0KQ09ORklHX0JMS19ERVZfU1I9bQpDT05GSUdfQkxLX0RFVl9TUl9W
RU5ET1I9eQpDT05GSUdfQ0hSX0RFVl9TRz1tCkNPTkZJR19DSFJfREVWX1NDSD1tCkNPTkZJR19T
Q1NJX01VTFRJX0xVTj15CkNPTkZJR19TQ1NJX0NPTlNUQU5UUz15CkNPTkZJR19TQ1NJX0xPR0dJ
Tkc9eQojIENPTkZJR19TQ1NJX1NDQU5fQVNZTkMgaXMgbm90IHNldApDT05GSUdfU0NTSV9XQUlU
X1NDQU49bQoKIwojIFNDU0kgVHJhbnNwb3J0cwojCkNPTkZJR19TQ1NJX1NQSV9BVFRSUz1tCkNP
TkZJR19TQ1NJX0ZDX0FUVFJTPW0KQ09ORklHX1NDU0lfSVNDU0lfQVRUUlM9bQpDT05GSUdfU0NT
SV9TQVNfQVRUUlM9bQpDT05GSUdfU0NTSV9TQVNfTElCU0FTPW0KIyBDT05GSUdfU0NTSV9TQVNf
QVRBIGlzIG5vdCBzZXQKQ09ORklHX1NDU0lfU0FTX0hPU1RfU01QPXkKQ09ORklHX1NDU0lfU1JQ
X0FUVFJTPW0KQ09ORklHX1NDU0lfTE9XTEVWRUw9eQpDT05GSUdfSVNDU0lfVENQPW0KIyBDT05G
SUdfSVNDU0lfQk9PVF9TWVNGUyBpcyBub3Qgc2V0CiMgQ09ORklHX1NDU0lfQ1hHQjNfSVNDU0kg
aXMgbm90IHNldAojIENPTkZJR19TQ1NJX0NYR0I0X0lTQ1NJIGlzIG5vdCBzZXQKIyBDT05GSUdf
U0NTSV9CTlgyX0lTQ1NJIGlzIG5vdCBzZXQKIyBDT05GSUdfU0NTSV9CTlgyWF9GQ09FIGlzIG5v
dCBzZXQKIyBDT05GSUdfQkUySVNDU0kgaXMgbm90IHNldApDT05GSUdfQkxLX0RFVl8zV19YWFhY
X1JBSUQ9bQojIENPTkZJR19TQ1NJX0hQU0EgaXMgbm90IHNldApDT05GSUdfU0NTSV8zV185WFhY
PW0KIyBDT05GSUdfU0NTSV8zV19TQVMgaXMgbm90IHNldApDT05GSUdfU0NTSV9BQ0FSRD1tCkNP
TkZJR19TQ1NJX0FBQ1JBSUQ9bQpDT05GSUdfU0NTSV9BSUM3WFhYPW0KQ09ORklHX0FJQzdYWFhf
Q01EU19QRVJfREVWSUNFPTMyCkNPTkZJR19BSUM3WFhYX1JFU0VUX0RFTEFZX01TPTE1MDAwCiMg
Q09ORklHX0FJQzdYWFhfREVCVUdfRU5BQkxFIGlzIG5vdCBzZXQKQ09ORklHX0FJQzdYWFhfREVC
VUdfTUFTSz0wCkNPTkZJR19BSUM3WFhYX1JFR19QUkVUVFlfUFJJTlQ9eQpDT05GSUdfU0NTSV9B
SUM3WFhYX09MRD1tCkNPTkZJR19TQ1NJX0FJQzc5WFg9bQpDT05GSUdfQUlDNzlYWF9DTURTX1BF
Ul9ERVZJQ0U9MzIKQ09ORklHX0FJQzc5WFhfUkVTRVRfREVMQVlfTVM9MTUwMDAKIyBDT05GSUdf
QUlDNzlYWF9ERUJVR19FTkFCTEUgaXMgbm90IHNldApDT05GSUdfQUlDNzlYWF9ERUJVR19NQVNL
PTAKQ09ORklHX0FJQzc5WFhfUkVHX1BSRVRUWV9QUklOVD15CkNPTkZJR19TQ1NJX0FJQzk0WFg9
bQojIENPTkZJR19BSUM5NFhYX0RFQlVHIGlzIG5vdCBzZXQKIyBDT05GSUdfU0NTSV9NVlNBUyBp
cyBub3Qgc2V0CkNPTkZJR19TQ1NJX0RQVF9JMk89bQpDT05GSUdfU0NTSV9BRFZBTlNZUz1tCkNP
TkZJR19TQ1NJX0FSQ01TUj1tCiMgQ09ORklHX1NDU0lfQVJDTVNSX0FFUiBpcyBub3Qgc2V0CkNP
TkZJR19NRUdBUkFJRF9ORVdHRU49eQpDT05GSUdfTUVHQVJBSURfTU09bQpDT05GSUdfTUVHQVJB
SURfTUFJTEJPWD1tCkNPTkZJR19NRUdBUkFJRF9MRUdBQ1k9bQpDT05GSUdfTUVHQVJBSURfU0FT
PW0KQ09ORklHX1NDU0lfTVBUMlNBUz1tCkNPTkZJR19TQ1NJX01QVDJTQVNfTUFYX1NHRT0xMjgK
IyBDT05GSUdfU0NTSV9NUFQyU0FTX0xPR0dJTkcgaXMgbm90IHNldApDT05GSUdfU0NTSV9IUFRJ
T1A9bQpDT05GSUdfU0NTSV9CVVNMT0dJQz1tCiMgQ09ORklHX1NDU0lfRkxBU0hQT0lOVCBpcyBu
b3Qgc2V0CiMgQ09ORklHX1ZNV0FSRV9QVlNDU0kgaXMgbm90IHNldAojIENPTkZJR19MSUJGQyBp
cyBub3Qgc2V0CiMgQ09ORklHX0xJQkZDT0UgaXMgbm90IHNldAojIENPTkZJR19GQ09FIGlzIG5v
dCBzZXQKIyBDT05GSUdfRkNPRV9GTklDIGlzIG5vdCBzZXQKQ09ORklHX1NDU0lfRE1YMzE5MUQ9
bQpDT05GSUdfU0NTSV9FQVRBPW0KIyBDT05GSUdfU0NTSV9FQVRBX1RBR0dFRF9RVUVVRSBpcyBu
b3Qgc2V0CiMgQ09ORklHX1NDU0lfRUFUQV9MSU5LRURfQ09NTUFORFMgaXMgbm90IHNldApDT05G
SUdfU0NTSV9FQVRBX01BWF9UQUdTPTE2CkNPTkZJR19TQ1NJX0ZVVFVSRV9ET01BSU49bQpDT05G
SUdfU0NTSV9HRFRIPW0KIyBDT05GSUdfU0NTSV9JU0NJIGlzIG5vdCBzZXQKQ09ORklHX1NDU0lf
SVBTPW0KQ09ORklHX1NDU0lfSU5JVElPPW0KQ09ORklHX1NDU0lfSU5JQTEwMD1tCkNPTkZJR19T
Q1NJX1BQQT1tCkNPTkZJR19TQ1NJX0lNTT1tCiMgQ09ORklHX1NDU0lfSVpJUF9FUFAxNiBpcyBu
b3Qgc2V0CiMgQ09ORklHX1NDU0lfSVpJUF9TTE9XX0NUUiBpcyBub3Qgc2V0CkNPTkZJR19TQ1NJ
X1NURVg9bQpDT05GSUdfU0NTSV9TWU01M0M4WFhfMj1tCkNPTkZJR19TQ1NJX1NZTTUzQzhYWF9E
TUFfQUREUkVTU0lOR19NT0RFPTEKQ09ORklHX1NDU0lfU1lNNTNDOFhYX0RFRkFVTFRfVEFHUz0x
NgpDT05GSUdfU0NTSV9TWU01M0M4WFhfTUFYX1RBR1M9NjQKQ09ORklHX1NDU0lfU1lNNTNDOFhY
X01NSU89eQpDT05GSUdfU0NTSV9JUFI9bQojIENPTkZJR19TQ1NJX0lQUl9UUkFDRSBpcyBub3Qg
c2V0CiMgQ09ORklHX1NDU0lfSVBSX0RVTVAgaXMgbm90IHNldApDT05GSUdfU0NTSV9RTE9HSUNf
MTI4MD1tCkNPTkZJR19TQ1NJX1FMQV9GQz1tCkNPTkZJR19TQ1NJX1FMQV9JU0NTST1tCkNPTkZJ
R19TQ1NJX0xQRkM9bQpDT05GSUdfU0NTSV9EQzM5NXg9bQpDT05GSUdfU0NTSV9EQzM5MFQ9bQpD
T05GSUdfU0NTSV9OU1AzMj1tCiMgQ09ORklHX1NDU0lfREVCVUcgaXMgbm90IHNldAojIENPTkZJ
R19TQ1NJX1BNQ1JBSUQgaXMgbm90IHNldAojIENPTkZJR19TQ1NJX1BNODAwMSBpcyBub3Qgc2V0
CiMgQ09ORklHX1NDU0lfU1JQIGlzIG5vdCBzZXQKIyBDT05GSUdfU0NTSV9CRkFfRkMgaXMgbm90
IHNldApDT05GSUdfU0NTSV9ESD1tCiMgQ09ORklHX1NDU0lfREhfUkRBQyBpcyBub3Qgc2V0CiMg
Q09ORklHX1NDU0lfREhfSFBfU1cgaXMgbm90IHNldAojIENPTkZJR19TQ1NJX0RIX0VNQyBpcyBu
b3Qgc2V0CiMgQ09ORklHX1NDU0lfREhfQUxVQSBpcyBub3Qgc2V0CiMgQ09ORklHX1NDU0lfT1NE
X0lOSVRJQVRPUiBpcyBub3Qgc2V0CkNPTkZJR19BVEE9bQojIENPTkZJR19BVEFfTk9OU1RBTkRB
UkQgaXMgbm90IHNldApDT05GSUdfQVRBX1ZFUkJPU0VfRVJST1I9eQpDT05GSUdfQVRBX0FDUEk9
eQpDT05GSUdfU0FUQV9QTVA9eQoKIwojIENvbnRyb2xsZXJzIHdpdGggbm9uLVNGRiBuYXRpdmUg
aW50ZXJmYWNlCiMKQ09ORklHX1NBVEFfQUhDST1tCkNPTkZJR19TQVRBX0FIQ0lfUExBVEZPUk09
bQpDT05GSUdfU0FUQV9JTklDMTYyWD1tCkNPTkZJR19TQVRBX0FDQVJEX0FIQ0k9bQpDT05GSUdf
U0FUQV9TSUwyND1tCkNPTkZJR19BVEFfU0ZGPXkKCiMKIyBTRkYgY29udHJvbGxlcnMgd2l0aCBj
dXN0b20gRE1BIGludGVyZmFjZQojCkNPTkZJR19QRENfQURNQT1tCkNPTkZJR19TQVRBX1FTVE9S
PW0KQ09ORklHX1NBVEFfU1g0PW0KQ09ORklHX0FUQV9CTURNQT15CgojCiMgU0FUQSBTRkYgY29u
dHJvbGxlcnMgd2l0aCBCTURNQQojCkNPTkZJR19BVEFfUElJWD1tCkNPTkZJR19TQVRBX01WPW0K
Q09ORklHX1NBVEFfTlY9bQpDT05GSUdfU0FUQV9QUk9NSVNFPW0KQ09ORklHX1NBVEFfU0lMPW0K
Q09ORklHX1NBVEFfU0lTPW0KQ09ORklHX1NBVEFfU1ZXPW0KQ09ORklHX1NBVEFfVUxJPW0KQ09O
RklHX1NBVEFfVklBPW0KQ09ORklHX1NBVEFfVklURVNTRT1tCgojCiMgUEFUQSBTRkYgY29udHJv
bGxlcnMgd2l0aCBCTURNQQojCkNPTkZJR19QQVRBX0FMST1tCkNPTkZJR19QQVRBX0FNRD1tCkNP
TkZJR19QQVRBX0FSQVNBTl9DRj1tCkNPTkZJR19QQVRBX0FSVE9QPW0KQ09ORklHX1BBVEFfQVRJ
SVhQPW0KQ09ORklHX1BBVEFfQVRQODY3WD1tCkNPTkZJR19QQVRBX0NNRDY0WD1tCkNPTkZJR19Q
QVRBX0NTNTUyMD1tCkNPTkZJR19QQVRBX0NTNTUzMD1tCkNPTkZJR19QQVRBX0NTNTUzNT1tCkNP
TkZJR19QQVRBX0NTNTUzNj1tCkNPTkZJR19QQVRBX0NZUFJFU1M9bQpDT05GSUdfUEFUQV9FRkFS
PW0KQ09ORklHX1BBVEFfSFBUMzY2PW0KQ09ORklHX1BBVEFfSFBUMzdYPW0KQ09ORklHX1BBVEFf
SFBUM1gyTj1tCkNPTkZJR19QQVRBX0hQVDNYMz1tCkNPTkZJR19QQVRBX0hQVDNYM19ETUE9eQpD
T05GSUdfUEFUQV9JVDgyMTM9bQpDT05GSUdfUEFUQV9JVDgyMVg9bQpDT05GSUdfUEFUQV9KTUlD
Uk9OPW0KQ09ORklHX1BBVEFfTUFSVkVMTD1tCkNPTkZJR19QQVRBX05FVENFTEw9bQpDT05GSUdf
UEFUQV9OSU5KQTMyPW0KQ09ORklHX1BBVEFfTlM4NzQxNT1tCkNPTkZJR19QQVRBX09MRFBJSVg9
bQpDT05GSUdfUEFUQV9PUFRJRE1BPW0KQ09ORklHX1BBVEFfUERDMjAyN1g9bQpDT05GSUdfUEFU
QV9QRENfT0xEPW0KQ09ORklHX1BBVEFfUkFESVNZUz1tCkNPTkZJR19QQVRBX1JEQz1tCkNPTkZJ
R19QQVRBX1NDMTIwMD1tCkNPTkZJR19QQVRBX1NDSD1tCkNPTkZJR19QQVRBX1NFUlZFUldPUktT
PW0KQ09ORklHX1BBVEFfU0lMNjgwPW0KQ09ORklHX1BBVEFfU0lTPW0KQ09ORklHX1BBVEFfVE9T
SElCQT1tCkNPTkZJR19QQVRBX1RSSUZMRVg9bQpDT05GSUdfUEFUQV9WSUE9bQpDT05GSUdfUEFU
QV9XSU5CT05EPW0KCiMKIyBQSU8tb25seSBTRkYgY29udHJvbGxlcnMKIwpDT05GSUdfUEFUQV9D
TUQ2NDBfUENJPW0KQ09ORklHX1BBVEFfTVBJSVg9bQpDT05GSUdfUEFUQV9OUzg3NDEwPW0KQ09O
RklHX1BBVEFfT1BUST1tCiMgQ09ORklHX1BBVEFfUExBVEZPUk0gaXMgbm90IHNldApDT05GSUdf
UEFUQV9SWjEwMDA9bQoKIwojIEdlbmVyaWMgZmFsbGJhY2sgLyBsZWdhY3kgZHJpdmVycwojCkNP
TkZJR19QQVRBX0FDUEk9bQpDT05GSUdfQVRBX0dFTkVSSUM9bQojIENPTkZJR19QQVRBX0xFR0FD
WSBpcyBub3Qgc2V0CkNPTkZJR19NRD15CkNPTkZJR19CTEtfREVWX01EPXkKQ09ORklHX01EX0FV
VE9ERVRFQ1Q9eQpDT05GSUdfTURfTElORUFSPW0KQ09ORklHX01EX1JBSUQwPW0KQ09ORklHX01E
X1JBSUQxPW0KQ09ORklHX01EX1JBSUQxMD1tCkNPTkZJR19NRF9SQUlENDU2PW0KIyBDT05GSUdf
TVVMVElDT1JFX1JBSUQ0NTYgaXMgbm90IHNldApDT05GSUdfTURfTVVMVElQQVRIPW0KIyBDT05G
SUdfTURfRkFVTFRZIGlzIG5vdCBzZXQKQ09ORklHX0JMS19ERVZfRE09bQojIENPTkZJR19ETV9E
RUJVRyBpcyBub3Qgc2V0CkNPTkZJR19ETV9DUllQVD1tCkNPTkZJR19ETV9TTkFQU0hPVD1tCkNP
TkZJR19ETV9NSVJST1I9bQojIENPTkZJR19ETV9SQUlEIGlzIG5vdCBzZXQKIyBDT05GSUdfRE1f
TE9HX1VTRVJTUEFDRSBpcyBub3Qgc2V0CkNPTkZJR19ETV9aRVJPPW0KQ09ORklHX0RNX01VTFRJ
UEFUSD1tCiMgQ09ORklHX0RNX01VTFRJUEFUSF9RTCBpcyBub3Qgc2V0CiMgQ09ORklHX0RNX01V
TFRJUEFUSF9TVCBpcyBub3Qgc2V0CiMgQ09ORklHX0RNX0RFTEFZIGlzIG5vdCBzZXQKIyBDT05G
SUdfRE1fVUVWRU5UIGlzIG5vdCBzZXQKIyBDT05GSUdfRE1fRkxBS0VZIGlzIG5vdCBzZXQKIyBD
T05GSUdfVEFSR0VUX0NPUkUgaXMgbm90IHNldApDT05GSUdfRlVTSU9OPXkKQ09ORklHX0ZVU0lP
Tl9TUEk9bQpDT05GSUdfRlVTSU9OX0ZDPW0KQ09ORklHX0ZVU0lPTl9TQVM9bQpDT05GSUdfRlVT
SU9OX01BWF9TR0U9MTI4CkNPTkZJR19GVVNJT05fQ1RMPW0KIyBDT05GSUdfRlVTSU9OX0xBTiBp
cyBub3Qgc2V0CiMgQ09ORklHX0ZVU0lPTl9MT0dHSU5HIGlzIG5vdCBzZXQKCiMKIyBJRUVFIDEz
OTQgKEZpcmVXaXJlKSBzdXBwb3J0CiMKIyBDT05GSUdfRklSRVdJUkUgaXMgbm90IHNldAojIENP
TkZJR19GSVJFV0lSRV9OT1NZIGlzIG5vdCBzZXQKQ09ORklHX0kyTz1tCkNPTkZJR19JMk9fTENU
X05PVElGWV9PTl9DSEFOR0VTPXkKQ09ORklHX0kyT19FWFRfQURBUFRFQz15CkNPTkZJR19JMk9f
RVhUX0FEQVBURUNfRE1BNjQ9eQpDT05GSUdfSTJPX0NPTkZJRz1tCkNPTkZJR19JMk9fQ09ORklH
X09MRF9JT0NUTD15CkNPTkZJR19JMk9fQlVTPW0KQ09ORklHX0kyT19CTE9DSz1tCkNPTkZJR19J
Mk9fU0NTST1tCkNPTkZJR19JMk9fUFJPQz1tCiMgQ09ORklHX01BQ0lOVE9TSF9EUklWRVJTIGlz
IG5vdCBzZXQKQ09ORklHX05FVERFVklDRVM9eQpDT05GSUdfRFVNTVk9bQpDT05GSUdfQk9ORElO
Rz1tCiMgQ09ORklHX01BQ1ZMQU4gaXMgbm90IHNldApDT05GSUdfRVFVQUxJWkVSPW0KQ09ORklH
X1RVTj1tCkNPTkZJR19WRVRIPW0KQ09ORklHX05FVF9TQjEwMDA9bQojIENPTkZJR19BUkNORVQg
aXMgbm90IHNldApDT05GSUdfTUlJPXkKQ09ORklHX1BIWUxJQj1tCgojCiMgTUlJIFBIWSBkZXZp
Y2UgZHJpdmVycwojCkNPTkZJR19NQVJWRUxMX1BIWT1tCkNPTkZJR19EQVZJQ09NX1BIWT1tCkNP
TkZJR19RU0VNSV9QSFk9bQpDT05GSUdfTFhUX1BIWT1tCkNPTkZJR19DSUNBREFfUEhZPW0KQ09O
RklHX1ZJVEVTU0VfUEhZPW0KQ09ORklHX1NNU0NfUEhZPW0KIyBDT05GSUdfQlJPQURDT01fUEhZ
IGlzIG5vdCBzZXQKIyBDT05GSUdfSUNQTFVTX1BIWSBpcyBub3Qgc2V0CiMgQ09ORklHX1JFQUxU
RUtfUEhZIGlzIG5vdCBzZXQKIyBDT05GSUdfTkFUSU9OQUxfUEhZIGlzIG5vdCBzZXQKIyBDT05G
SUdfU1RFMTBYUCBpcyBub3Qgc2V0CiMgQ09ORklHX0xTSV9FVDEwMTFDX1BIWSBpcyBub3Qgc2V0
CiMgQ09ORklHX01JQ1JFTF9QSFkgaXMgbm90IHNldAojIENPTkZJR19NRElPX0JJVEJBTkcgaXMg
bm90IHNldApDT05GSUdfTkVUX0VUSEVSTkVUPXkKQ09ORklHX0hBUFBZTUVBTD1tCkNPTkZJR19T
VU5HRU09bQpDT05GSUdfQ0FTU0lOST1tCkNPTkZJR19ORVRfVkVORE9SXzNDT009eQpDT05GSUdf
Vk9SVEVYPW0KQ09ORklHX1RZUEhPT049bQojIENPTkZJR19FVEhPQyBpcyBub3Qgc2V0CiMgQ09O
RklHX0RORVQgaXMgbm90IHNldApDT05GSUdfTkVUX1RVTElQPXkKQ09ORklHX0RFMjEwNFg9bQpD
T05GSUdfREUyMTA0WF9EU0w9MApDT05GSUdfVFVMSVA9bQojIENPTkZJR19UVUxJUF9NV0kgaXMg
bm90IHNldApDT05GSUdfVFVMSVBfTU1JTz15CiMgQ09ORklHX1RVTElQX05BUEkgaXMgbm90IHNl
dApDT05GSUdfREU0WDU9bQpDT05GSUdfV0lOQk9ORF84NDA9bQpDT05GSUdfRE05MTAyPW0KQ09O
RklHX1VMSTUyNlg9bQpDT05GSUdfSFAxMDA9bQojIENPTkZJR19JQk1fTkVXX0VNQUNfWk1JSSBp
cyBub3Qgc2V0CiMgQ09ORklHX0lCTV9ORVdfRU1BQ19SR01JSSBpcyBub3Qgc2V0CiMgQ09ORklH
X0lCTV9ORVdfRU1BQ19UQUggaXMgbm90IHNldAojIENPTkZJR19JQk1fTkVXX0VNQUNfRU1BQzQg
aXMgbm90IHNldAojIENPTkZJR19JQk1fTkVXX0VNQUNfTk9fRkxPV19DVFJMIGlzIG5vdCBzZXQK
IyBDT05GSUdfSUJNX05FV19FTUFDX01BTF9DTFJfSUNJTlRTVEFUIGlzIG5vdCBzZXQKIyBDT05G
SUdfSUJNX05FV19FTUFDX01BTF9DT01NT05fRVJSIGlzIG5vdCBzZXQKQ09ORklHX05FVF9QQ0k9
eQpDT05GSUdfUENORVQzMj1tCkNPTkZJR19BTUQ4MTExX0VUSD1tCkNPTkZJR19BREFQVEVDX1NU
QVJGSVJFPW0KIyBDT05GSUdfS1NaODg0WF9QQ0kgaXMgbm90IHNldApDT05GSUdfQjQ0PW0KQ09O
RklHX0I0NF9QQ0lfQVVUT1NFTEVDVD15CkNPTkZJR19CNDRfUENJQ09SRV9BVVRPU0VMRUNUPXkK
Q09ORklHX0I0NF9QQ0k9eQpDT05GSUdfRk9SQ0VERVRIPW0KQ09ORklHX0UxMDA9bQpDT05GSUdf
RkVBTE5YPW0KQ09ORklHX05BVFNFTUk9bQpDT05GSUdfTkUyS19QQ0k9bQpDT05GSUdfODEzOUNQ
PW0KQ09ORklHXzgxMzlUT089bQpDT05GSUdfODEzOVRPT19QSU89eQojIENPTkZJR184MTM5VE9P
X1RVTkVfVFdJU1RFUiBpcyBub3Qgc2V0CkNPTkZJR184MTM5VE9PXzgxMjk9eQojIENPTkZJR184
MTM5X09MRF9SWF9SRVNFVCBpcyBub3Qgc2V0CiMgQ09ORklHX1I2MDQwIGlzIG5vdCBzZXQKQ09O
RklHX1NJUzkwMD1tCkNPTkZJR19FUElDMTAwPW0KIyBDT05GSUdfU01TQzk0MjAgaXMgbm90IHNl
dApDT05GSUdfU1VOREFOQ0U9bQpDT05GSUdfU1VOREFOQ0VfTU1JTz15CkNPTkZJR19UTEFOPW0K
IyBDT05GSUdfS1M4ODQyIGlzIG5vdCBzZXQKIyBDT05GSUdfS1M4ODUxX01MTCBpcyBub3Qgc2V0
CkNPTkZJR19WSUFfUkhJTkU9bQpDT05GSUdfVklBX1JISU5FX01NSU89eQojIENPTkZJR19TQzky
MDMxIGlzIG5vdCBzZXQKQ09ORklHX05FVF9QT0NLRVQ9eQpDT05GSUdfQVRQPW0KQ09ORklHX0RF
NjAwPW0KQ09ORklHX0RFNjIwPW0KIyBDT05GSUdfQVRMMiBpcyBub3Qgc2V0CkNPTkZJR19ORVRE
RVZfMTAwMD15CkNPTkZJR19BQ0VOSUM9bQojIENPTkZJR19BQ0VOSUNfT01JVF9USUdPTl9JIGlz
IG5vdCBzZXQKQ09ORklHX0RMMks9bQpDT05GSUdfRTEwMDA9bQpDT05GSUdfRTEwMDBFPW0KQ09O
RklHX0lQMTAwMD1tCkNPTkZJR19JR0I9bQpDT05GSUdfSUdCX0RDQT15CkNPTkZJR19JR0JWRj1t
CkNPTkZJR19OUzgzODIwPW0KQ09ORklHX0hBTUFDSEk9bQpDT05GSUdfWUVMTE9XRklOPW0KQ09O
RklHX1I4MTY5PW0KQ09ORklHX1NJUzE5MD1tCkNPTkZJR19TS0dFPW0KQ09ORklHX1NLWTI9bQpD
T05GSUdfVklBX1ZFTE9DSVRZPW0KQ09ORklHX1RJR09OMz1tCkNPTkZJR19CTlgyPW0KIyBDT05G
SUdfQ05JQyBpcyBub3Qgc2V0CkNPTkZJR19RTEEzWFhYPW0KQ09ORklHX0FUTDE9bQpDT05GSUdf
QVRMMUU9bQpDT05GSUdfQVRMMUM9bQpDT05GSUdfSk1FPW0KQ09ORklHX1NUTU1BQ19FVEg9bQoj
IENPTkZJR19TVE1NQUNfREEgaXMgbm90IHNldAojIENPTkZJR19TVE1NQUNfRFVBTF9NQUMgaXMg
bm90IHNldApDT05GSUdfUENIX0dCRT15CkNPTkZJR19ORVRERVZfMTAwMDA9eQpDT05GSUdfTURJ
Tz1tCkNPTkZJR19DSEVMU0lPX1QxPW0KIyBDT05GSUdfQ0hFTFNJT19UMV8xRyBpcyBub3Qgc2V0
CkNPTkZJR19DSEVMU0lPX1QzPW0KQ09ORklHX0NIRUxTSU9fVDQ9bQpDT05GSUdfQ0hFTFNJT19U
NFZGPW0KQ09ORklHX0VOSUM9bQpDT05GSUdfSVhHQkU9bQpDT05GSUdfSVhHQkVfRENBPXkKQ09O
RklHX0lYR0JFVkY9bQpDT05GSUdfSVhHQj1tCkNPTkZJR19TMklPPW0KQ09ORklHX1ZYR0U9bQoj
IENPTkZJR19WWEdFX0RFQlVHX1RSQUNFX0FMTCBpcyBub3Qgc2V0CkNPTkZJR19NWVJJMTBHRT1t
CkNPTkZJR19NWVJJMTBHRV9EQ0E9eQpDT05GSUdfTkVUWEVOX05JQz1tCkNPTkZJR19OSVU9bQpD
T05GSUdfTUxYNF9FTj1tCkNPTkZJR19NTFg0X0NPUkU9bQpDT05GSUdfTUxYNF9ERUJVRz15CkNP
TkZJR19URUhVVEk9bQpDT05GSUdfQk5YMlg9bQpDT05GSUdfUUxDTklDPW0KQ09ORklHX1FMR0U9
bQpDT05GSUdfQk5BPW0KQ09ORklHX1NGQz1tCkNPTkZJR19CRTJORVQ9bQpDT05GSUdfVFI9eQpD
T05GSUdfSUJNT0w9bQpDT05GSUdfSUJNTFM9bQpDT05GSUdfM0MzNTk9bQojIENPTkZJR19UTVMz
ODBUUiBpcyBub3Qgc2V0CiMgQ09ORklHX1dMQU4gaXMgbm90IHNldAoKIwojIEVuYWJsZSBXaU1B
WCAoTmV0d29ya2luZyBvcHRpb25zKSB0byBzZWUgdGhlIFdpTUFYIGRyaXZlcnMKIwoKIwojIFVT
QiBOZXR3b3JrIEFkYXB0ZXJzCiMKIyBDT05GSUdfVVNCX0NBVEMgaXMgbm90IHNldAojIENPTkZJ
R19VU0JfS0FXRVRIIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX1BFR0FTVVMgaXMgbm90IHNldAoj
IENPTkZJR19VU0JfUlRMODE1MCBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9VU0JORVQgaXMgbm90
IHNldAojIENPTkZJR19VU0JfSVBIRVRIIGlzIG5vdCBzZXQKIyBDT05GSUdfV0FOIGlzIG5vdCBz
ZXQKCiMKIyBDQUlGIHRyYW5zcG9ydCBkcml2ZXJzCiMKIyBDT05GSUdfWEVOX05FVERFVl9GUk9O
VEVORCBpcyBub3Qgc2V0CkNPTkZJR19YRU5fTkVUREVWX0JBQ0tFTkQ9eQojIENPTkZJR19GRERJ
IGlzIG5vdCBzZXQKIyBDT05GSUdfSElQUEkgaXMgbm90IHNldAojIENPTkZJR19QTElQIGlzIG5v
dCBzZXQKQ09ORklHX1BQUD1tCkNPTkZJR19QUFBfTVVMVElMSU5LPXkKQ09ORklHX1BQUF9GSUxU
RVI9eQpDT05GSUdfUFBQX0FTWU5DPW0KQ09ORklHX1BQUF9TWU5DX1RUWT1tCkNPTkZJR19QUFBf
REVGTEFURT1tCkNPTkZJR19QUFBfQlNEQ09NUD1tCiMgQ09ORklHX1BQUF9NUFBFIGlzIG5vdCBz
ZXQKQ09ORklHX1BQUE9FPW0KQ09ORklHX1NMSVA9bQpDT05GSUdfU0xJUF9DT01QUkVTU0VEPXkK
Q09ORklHX1NMSEM9bQpDT05GSUdfU0xJUF9TTUFSVD15CiMgQ09ORklHX1NMSVBfTU9ERV9TTElQ
NiBpcyBub3Qgc2V0CkNPTkZJR19ORVRfRkM9eQpDT05GSUdfTkVUQ09OU09MRT1tCkNPTkZJR19O
RVRQT0xMPXkKQ09ORklHX05FVFBPTExfVFJBUD15CkNPTkZJR19ORVRfUE9MTF9DT05UUk9MTEVS
PXkKIyBDT05GSUdfVk1YTkVUMyBpcyBub3Qgc2V0CiMgQ09ORklHX0lTRE4gaXMgbm90IHNldAoj
IENPTkZJR19QSE9ORSBpcyBub3Qgc2V0CgojCiMgSW5wdXQgZGV2aWNlIHN1cHBvcnQKIwpDT05G
SUdfSU5QVVQ9eQojIENPTkZJR19JTlBVVF9GRl9NRU1MRVNTIGlzIG5vdCBzZXQKQ09ORklHX0lO
UFVUX1BPTExERVY9bQpDT05GSUdfSU5QVVRfU1BBUlNFS01BUD1tCgojCiMgVXNlcmxhbmQgaW50
ZXJmYWNlcwojCkNPTkZJR19JTlBVVF9NT1VTRURFVj15CkNPTkZJR19JTlBVVF9NT1VTRURFVl9Q
U0FVWD15CkNPTkZJR19JTlBVVF9NT1VTRURFVl9TQ1JFRU5fWD0xMDI0CkNPTkZJR19JTlBVVF9N
T1VTRURFVl9TQ1JFRU5fWT03NjgKIyBDT05GSUdfSU5QVVRfSk9ZREVWIGlzIG5vdCBzZXQKIyBD
T05GSUdfSU5QVVRfRVZERVYgaXMgbm90IHNldAojIENPTkZJR19JTlBVVF9FVkJVRyBpcyBub3Qg
c2V0CgojCiMgSW5wdXQgRGV2aWNlIERyaXZlcnMKIwpDT05GSUdfSU5QVVRfS0VZQk9BUkQ9eQoj
IENPTkZJR19LRVlCT0FSRF9BRFA1NTg4IGlzIG5vdCBzZXQKIyBDT05GSUdfS0VZQk9BUkRfQURQ
NTU4OSBpcyBub3Qgc2V0CkNPTkZJR19LRVlCT0FSRF9BVEtCRD15CiMgQ09ORklHX0tFWUJPQVJE
X1FUMTA3MCBpcyBub3Qgc2V0CiMgQ09ORklHX0tFWUJPQVJEX1FUMjE2MCBpcyBub3Qgc2V0CiMg
Q09ORklHX0tFWUJPQVJEX0xLS0JEIGlzIG5vdCBzZXQKIyBDT05GSUdfS0VZQk9BUkRfVENBNjQx
NiBpcyBub3Qgc2V0CiMgQ09ORklHX0tFWUJPQVJEX0xNODMyMyBpcyBub3Qgc2V0CiMgQ09ORklH
X0tFWUJPQVJEX01BWDczNTkgaXMgbm90IHNldAojIENPTkZJR19LRVlCT0FSRF9NQ1MgaXMgbm90
IHNldAojIENPTkZJR19LRVlCT0FSRF9NUFIxMjEgaXMgbm90IHNldAojIENPTkZJR19LRVlCT0FS
RF9ORVdUT04gaXMgbm90IHNldAojIENPTkZJR19LRVlCT0FSRF9PUEVOQ09SRVMgaXMgbm90IHNl
dAojIENPTkZJR19LRVlCT0FSRF9TVE9XQVdBWSBpcyBub3Qgc2V0CiMgQ09ORklHX0tFWUJPQVJE
X1NVTktCRCBpcyBub3Qgc2V0CiMgQ09ORklHX0tFWUJPQVJEX1hUS0JEIGlzIG5vdCBzZXQKIyBD
T05GSUdfSU5QVVRfTU9VU0UgaXMgbm90IHNldAojIENPTkZJR19JTlBVVF9KT1lTVElDSyBpcyBu
b3Qgc2V0CiMgQ09ORklHX0lOUFVUX1RBQkxFVCBpcyBub3Qgc2V0CiMgQ09ORklHX0lOUFVUX1RP
VUNIU0NSRUVOIGlzIG5vdCBzZXQKQ09ORklHX0lOUFVUX01JU0M9eQojIENPTkZJR19JTlBVVF9B
RDcxNFggaXMgbm90IHNldApDT05GSUdfSU5QVVRfUENTUEtSPW0KIyBDT05GSUdfSU5QVVRfQVBB
TkVMIGlzIG5vdCBzZXQKQ09ORklHX0lOUFVUX1dJU1RST05fQlROUz1tCiMgQ09ORklHX0lOUFVU
X0FUTEFTX0JUTlMgaXMgbm90IHNldAojIENPTkZJR19JTlBVVF9BVElfUkVNT1RFIGlzIG5vdCBz
ZXQKIyBDT05GSUdfSU5QVVRfQVRJX1JFTU9URTIgaXMgbm90IHNldAojIENPTkZJR19JTlBVVF9L
RVlTUEFOX1JFTU9URSBpcyBub3Qgc2V0CiMgQ09ORklHX0lOUFVUX1BPV0VSTUFURSBpcyBub3Qg
c2V0CiMgQ09ORklHX0lOUFVUX1lFQUxJTksgaXMgbm90IHNldAojIENPTkZJR19JTlBVVF9DTTEw
OSBpcyBub3Qgc2V0CkNPTkZJR19JTlBVVF9VSU5QVVQ9bQojIENPTkZJR19JTlBVVF9QQ0Y4NTc0
IGlzIG5vdCBzZXQKIyBDT05GSUdfSU5QVVRfQURYTDM0WCBpcyBub3Qgc2V0CiMgQ09ORklHX0lO
UFVUX0NNQTMwMDAgaXMgbm90IHNldAoKIwojIEhhcmR3YXJlIEkvTyBwb3J0cwojCkNPTkZJR19T
RVJJTz15CkNPTkZJR19TRVJJT19JODA0Mj15CkNPTkZJR19TRVJJT19TRVJQT1JUPXkKIyBDT05G
SUdfU0VSSU9fQ1Q4MkM3MTAgaXMgbm90IHNldAojIENPTkZJR19TRVJJT19QQVJLQkQgaXMgbm90
IHNldAojIENPTkZJR19TRVJJT19QQ0lQUzIgaXMgbm90IHNldApDT05GSUdfU0VSSU9fTElCUFMy
PXkKQ09ORklHX1NFUklPX1JBVz1tCiMgQ09ORklHX1NFUklPX0FMVEVSQV9QUzIgaXMgbm90IHNl
dAojIENPTkZJR19TRVJJT19QUzJNVUxUIGlzIG5vdCBzZXQKIyBDT05GSUdfR0FNRVBPUlQgaXMg
bm90IHNldAoKIwojIENoYXJhY3RlciBkZXZpY2VzCiMKQ09ORklHX1ZUPXkKQ09ORklHX0NPTlNP
TEVfVFJBTlNMQVRJT05TPXkKQ09ORklHX1ZUX0NPTlNPTEU9eQpDT05GSUdfSFdfQ09OU09MRT15
CkNPTkZJR19WVF9IV19DT05TT0xFX0JJTkRJTkc9eQpDT05GSUdfVU5JWDk4X1BUWVM9eQojIENP
TkZJR19ERVZQVFNfTVVMVElQTEVfSU5TVEFOQ0VTIGlzIG5vdCBzZXQKIyBDT05GSUdfTEVHQUNZ
X1BUWVMgaXMgbm90IHNldApDT05GSUdfU0VSSUFMX05PTlNUQU5EQVJEPXkKIyBDT05GSUdfUk9D
S0VUUE9SVCBpcyBub3Qgc2V0CkNPTkZJR19DWUNMQURFUz1tCiMgQ09ORklHX0NZWl9JTlRSIGlz
IG5vdCBzZXQKIyBDT05GSUdfTU9YQV9JTlRFTExJTyBpcyBub3Qgc2V0CiMgQ09ORklHX01PWEFf
U01BUlRJTyBpcyBub3Qgc2V0CkNPTkZJR19TWU5DTElOSz1tCkNPTkZJR19TWU5DTElOS01QPW0K
Q09ORklHX1NZTkNMSU5LX0dUPW0KIyBDT05GSUdfTk9aT01JIGlzIG5vdCBzZXQKIyBDT05GSUdf
SVNJIGlzIG5vdCBzZXQKQ09ORklHX05fSERMQz1tCiMgQ09ORklHX05fR1NNIGlzIG5vdCBzZXQK
IyBDT05GSUdfVFJBQ0VfU0lOSyBpcyBub3Qgc2V0CkNPTkZJR19ERVZLTUVNPXkKQ09ORklHX1NU
QUxEUlY9eQoKIwojIFNlcmlhbCBkcml2ZXJzCiMKQ09ORklHX1NFUklBTF84MjUwPXkKQ09ORklH
X1NFUklBTF84MjUwX0NPTlNPTEU9eQpDT05GSUdfRklYX0VBUkxZQ09OX01FTT15CkNPTkZJR19T
RVJJQUxfODI1MF9QQ0k9eQpDT05GSUdfU0VSSUFMXzgyNTBfUE5QPXkKQ09ORklHX1NFUklBTF84
MjUwX05SX1VBUlRTPTQKQ09ORklHX1NFUklBTF84MjUwX1JVTlRJTUVfVUFSVFM9NApDT05GSUdf
U0VSSUFMXzgyNTBfRVhURU5ERUQ9eQojIENPTkZJR19TRVJJQUxfODI1MF9NQU5ZX1BPUlRTIGlz
IG5vdCBzZXQKQ09ORklHX1NFUklBTF84MjUwX1NIQVJFX0lSUT15CkNPTkZJR19TRVJJQUxfODI1
MF9ERVRFQ1RfSVJRPXkKQ09ORklHX1NFUklBTF84MjUwX1JTQT15CgojCiMgTm9uLTgyNTAgc2Vy
aWFsIHBvcnQgc3VwcG9ydAojCiMgQ09ORklHX1NFUklBTF9NRkRfSFNVIGlzIG5vdCBzZXQKQ09O
RklHX1NFUklBTF9DT1JFPXkKQ09ORklHX1NFUklBTF9DT1JFX0NPTlNPTEU9eQpDT05GSUdfU0VS
SUFMX0pTTT1tCiMgQ09ORklHX1NFUklBTF9USU1CRVJEQUxFIGlzIG5vdCBzZXQKIyBDT05GSUdf
U0VSSUFMX0FMVEVSQV9KVEFHVUFSVCBpcyBub3Qgc2V0CiMgQ09ORklHX1NFUklBTF9BTFRFUkFf
VUFSVCBpcyBub3Qgc2V0CiMgQ09ORklHX1NFUklBTF9QQ0hfVUFSVCBpcyBub3Qgc2V0CiMgQ09O
RklHX1NFUklBTF9YSUxJTlhfUFNfVUFSVCBpcyBub3Qgc2V0CiMgQ09ORklHX1RUWV9QUklOVEsg
aXMgbm90IHNldAojIENPTkZJR19QUklOVEVSIGlzIG5vdCBzZXQKIyBDT05GSUdfUFBERVYgaXMg
bm90IHNldApDT05GSUdfSFZDX0RSSVZFUj15CkNPTkZJR19IVkNfSVJRPXkKQ09ORklHX0hWQ19Y
RU49eQpDT05GSUdfSVBNSV9IQU5ETEVSPW0KQ09ORklHX0lQTUlfUEFOSUNfRVZFTlQ9eQojIENP
TkZJR19JUE1JX1BBTklDX1NUUklORyBpcyBub3Qgc2V0CkNPTkZJR19JUE1JX0RFVklDRV9JTlRF
UkZBQ0U9bQpDT05GSUdfSVBNSV9TST1tCkNPTkZJR19JUE1JX1dBVENIRE9HPW0KQ09ORklHX0lQ
TUlfUE9XRVJPRkY9bQpDT05GSUdfSFdfUkFORE9NPXkKIyBDT05GSUdfSFdfUkFORE9NX1RJTUVS
SU9NRU0gaXMgbm90IHNldApDT05GSUdfSFdfUkFORE9NX0lOVEVMPXkKQ09ORklHX0hXX1JBTkRP
TV9BTUQ9eQpDT05GSUdfSFdfUkFORE9NX0dFT0RFPXkKQ09ORklHX0hXX1JBTkRPTV9WSUE9eQpD
T05GSUdfTlZSQU09bQpDT05GSUdfUlRDPXkKIyBDT05GSUdfUjM5NjQgaXMgbm90IHNldAojIENP
TkZJR19BUFBMSUNPTSBpcyBub3Qgc2V0CkNPTkZJR19TT05ZUEk9bQojIENPTkZJR19NV0FWRSBp
cyBub3Qgc2V0CkNPTkZJR19QQzg3MzZ4X0dQSU89bQpDT05GSUdfTlNDX0dQSU89bQpDT05GSUdf
UkFXX0RSSVZFUj1tCkNPTkZJR19NQVhfUkFXX0RFVlM9MjU2CiMgQ09ORklHX0hQRVQgaXMgbm90
IHNldAojIENPTkZJR19IQU5HQ0hFQ0tfVElNRVIgaXMgbm90IHNldAojIENPTkZJR19UQ0dfVFBN
IGlzIG5vdCBzZXQKIyBDT05GSUdfVEVMQ0xPQ0sgaXMgbm90IHNldApDT05GSUdfREVWUE9SVD15
CiMgQ09ORklHX1JBTU9PUFMgaXMgbm90IHNldApDT05GSUdfSTJDPW0KQ09ORklHX0kyQ19CT0FS
RElORk89eQpDT05GSUdfSTJDX0NPTVBBVD15CkNPTkZJR19JMkNfQ0hBUkRFVj1tCiMgQ09ORklH
X0kyQ19NVVggaXMgbm90IHNldApDT05GSUdfSTJDX0hFTFBFUl9BVVRPPXkKQ09ORklHX0kyQ19T
TUJVUz1tCkNPTkZJR19JMkNfQUxHT0JJVD1tCgojCiMgSTJDIEhhcmR3YXJlIEJ1cyBzdXBwb3J0
CiMKCiMKIyBQQyBTTUJ1cyBob3N0IGNvbnRyb2xsZXIgZHJpdmVycwojCkNPTkZJR19JMkNfQUxJ
MTUzNT1tCkNPTkZJR19JMkNfQUxJMTU2Mz1tCkNPTkZJR19JMkNfQUxJMTVYMz1tCkNPTkZJR19J
MkNfQU1ENzU2PW0KQ09ORklHX0kyQ19BTUQ3NTZfUzQ4ODI9bQpDT05GSUdfSTJDX0FNRDgxMTE9
bQpDT05GSUdfSTJDX0k4MDE9bQojIENPTkZJR19JMkNfSVNDSCBpcyBub3Qgc2V0CkNPTkZJR19J
MkNfUElJWDQ9bQpDT05GSUdfSTJDX05GT1JDRTI9bQojIENPTkZJR19JMkNfTkZPUkNFMl9TNDk4
NSBpcyBub3Qgc2V0CkNPTkZJR19JMkNfU0lTNTU5NT1tCkNPTkZJR19JMkNfU0lTNjMwPW0KQ09O
RklHX0kyQ19TSVM5Nlg9bQpDT05GSUdfSTJDX1ZJQT1tCkNPTkZJR19JMkNfVklBUFJPPW0KCiMK
IyBBQ1BJIGRyaXZlcnMKIwojIENPTkZJR19JMkNfU0NNSSBpcyBub3Qgc2V0CgojCiMgSTJDIHN5
c3RlbSBidXMgZHJpdmVycyAobW9zdGx5IGVtYmVkZGVkIC8gc3lzdGVtLW9uLWNoaXApCiMKIyBD
T05GSUdfSTJDX0lOVEVMX01JRCBpcyBub3Qgc2V0CiMgQ09ORklHX0kyQ19PQ09SRVMgaXMgbm90
IHNldAojIENPTkZJR19JMkNfUENBX1BMQVRGT1JNIGlzIG5vdCBzZXQKIyBDT05GSUdfSTJDX1BY
QV9QQ0kgaXMgbm90IHNldAojIENPTkZJR19JMkNfU0lNVEVDIGlzIG5vdCBzZXQKIyBDT05GSUdf
STJDX1hJTElOWCBpcyBub3Qgc2V0CiMgQ09ORklHX0kyQ19FRzIwVCBpcyBub3Qgc2V0CgojCiMg
RXh0ZXJuYWwgSTJDL1NNQnVzIGFkYXB0ZXIgZHJpdmVycwojCiMgQ09ORklHX0kyQ19ESU9MQU5f
VTJDIGlzIG5vdCBzZXQKQ09ORklHX0kyQ19QQVJQT1JUPW0KQ09ORklHX0kyQ19QQVJQT1JUX0xJ
R0hUPW0KIyBDT05GSUdfSTJDX1RBT1NfRVZNIGlzIG5vdCBzZXQKIyBDT05GSUdfSTJDX1RJTllf
VVNCIGlzIG5vdCBzZXQKCiMKIyBPdGhlciBJMkMvU01CdXMgYnVzIGRyaXZlcnMKIwpDT05GSUdf
STJDX1NUVUI9bQpDT05GSUdfU0N4MjAwX0FDQj1tCiMgQ09ORklHX0kyQ19ERUJVR19DT1JFIGlz
IG5vdCBzZXQKIyBDT05GSUdfSTJDX0RFQlVHX0FMR08gaXMgbm90IHNldAojIENPTkZJR19JMkNf
REVCVUdfQlVTIGlzIG5vdCBzZXQKIyBDT05GSUdfU1BJIGlzIG5vdCBzZXQKCiMKIyBQUFMgc3Vw
cG9ydAojCiMgQ09ORklHX1BQUyBpcyBub3Qgc2V0CgojCiMgUFBTIGdlbmVyYXRvcnMgc3VwcG9y
dAojCgojCiMgUFRQIGNsb2NrIHN1cHBvcnQKIwoKIwojIEVuYWJsZSBEZXZpY2UgRHJpdmVycyAt
PiBQUFMgdG8gc2VlIHRoZSBQVFAgY2xvY2sgb3B0aW9ucy4KIwpDT05GSUdfQVJDSF9XQU5UX09Q
VElPTkFMX0dQSU9MSUI9eQojIENPTkZJR19HUElPTElCIGlzIG5vdCBzZXQKIyBDT05GSUdfVzEg
aXMgbm90IHNldApDT05GSUdfUE9XRVJfU1VQUExZPW0KIyBDT05GSUdfUE9XRVJfU1VQUExZX0RF
QlVHIGlzIG5vdCBzZXQKIyBDT05GSUdfUERBX1BPV0VSIGlzIG5vdCBzZXQKIyBDT05GSUdfVEVT
VF9QT1dFUiBpcyBub3Qgc2V0CiMgQ09ORklHX0JBVFRFUllfRFMyNzgwIGlzIG5vdCBzZXQKIyBD
T05GSUdfQkFUVEVSWV9EUzI3ODIgaXMgbm90IHNldAojIENPTkZJR19CQVRURVJZX0JRMjBaNzUg
aXMgbm90IHNldAojIENPTkZJR19CQVRURVJZX0JRMjd4MDAgaXMgbm90IHNldAojIENPTkZJR19C
QVRURVJZX01BWDE3MDQwIGlzIG5vdCBzZXQKIyBDT05GSUdfQkFUVEVSWV9NQVgxNzA0MiBpcyBu
b3Qgc2V0CiMgQ09ORklHX0NIQVJHRVJfTUFYODkwMyBpcyBub3Qgc2V0CkNPTkZJR19IV01PTj1t
CkNPTkZJR19IV01PTl9WSUQ9bQojIENPTkZJR19IV01PTl9ERUJVR19DSElQIGlzIG5vdCBzZXQK
CiMKIyBOYXRpdmUgZHJpdmVycwojCkNPTkZJR19TRU5TT1JTX0FCSVRVR1VSVT1tCkNPTkZJR19T
RU5TT1JTX0FCSVRVR1VSVTM9bQpDT05GSUdfU0VOU09SU19BRDc0MTQ9bQpDT05GSUdfU0VOU09S
U19BRDc0MTg9bQpDT05GSUdfU0VOU09SU19BRE0xMDIxPW0KQ09ORklHX1NFTlNPUlNfQURNMTAy
NT1tCkNPTkZJR19TRU5TT1JTX0FETTEwMjY9bQpDT05GSUdfU0VOU09SU19BRE0xMDI5PW0KQ09O
RklHX1NFTlNPUlNfQURNMTAzMT1tCkNPTkZJR19TRU5TT1JTX0FETTkyNDA9bQpDT05GSUdfU0VO
U09SU19BRFQ3NDExPW0KQ09ORklHX1NFTlNPUlNfQURUNzQ2Mj1tCkNPTkZJR19TRU5TT1JTX0FE
VDc0NzA9bQpDT05GSUdfU0VOU09SU19BRFQ3NDc1PW0KQ09ORklHX1NFTlNPUlNfQVNDNzYyMT1t
CkNPTkZJR19TRU5TT1JTX0s4VEVNUD1tCkNPTkZJR19TRU5TT1JTX0sxMFRFTVA9bQpDT05GSUdf
U0VOU09SU19GQU0xNUhfUE9XRVI9bQpDT05GSUdfU0VOU09SU19BU0IxMDA9bQpDT05GSUdfU0VO
U09SU19BVFhQMT1tCkNPTkZJR19TRU5TT1JTX0RTNjIwPW0KQ09ORklHX1NFTlNPUlNfRFMxNjIx
PW0KQ09ORklHX1NFTlNPUlNfSTVLX0FNQj1tCkNPTkZJR19TRU5TT1JTX0Y3MTgwNUY9bQpDT05G
SUdfU0VOU09SU19GNzE4ODJGRz1tCkNPTkZJR19TRU5TT1JTX0Y3NTM3NVM9bQpDT05GSUdfU0VO
U09SU19GU0NITUQ9bQpDT05GSUdfU0VOU09SU19HNzYwQT1tCkNPTkZJR19TRU5TT1JTX0dMNTE4
U009bQpDT05GSUdfU0VOU09SU19HTDUyMFNNPW0KQ09ORklHX1NFTlNPUlNfQ09SRVRFTVA9bQpD
T05GSUdfU0VOU09SU19JQk1BRU09bQpDT05GSUdfU0VOU09SU19JQk1QRVg9bQpDT05GSUdfU0VO
U09SU19JVDg3PW0KQ09ORklHX1NFTlNPUlNfSkM0Mj1tCkNPTkZJR19TRU5TT1JTX0xJTkVBR0U9
bQpDT05GSUdfU0VOU09SU19MTTYzPW0KQ09ORklHX1NFTlNPUlNfTE03Mz1tCkNPTkZJR19TRU5T
T1JTX0xNNzU9bQpDT05GSUdfU0VOU09SU19MTTc3PW0KQ09ORklHX1NFTlNPUlNfTE03OD1tCkNP
TkZJR19TRU5TT1JTX0xNODA9bQpDT05GSUdfU0VOU09SU19MTTgzPW0KQ09ORklHX1NFTlNPUlNf
TE04NT1tCkNPTkZJR19TRU5TT1JTX0xNODc9bQpDT05GSUdfU0VOU09SU19MTTkwPW0KQ09ORklH
X1NFTlNPUlNfTE05Mj1tCkNPTkZJR19TRU5TT1JTX0xNOTM9bQpDT05GSUdfU0VOU09SU19MVEM0
MTUxPW0KQ09ORklHX1NFTlNPUlNfTFRDNDIxNT1tCkNPTkZJR19TRU5TT1JTX0xUQzQyNDU9bQpD
T05GSUdfU0VOU09SU19MVEM0MjYxPW0KQ09ORklHX1NFTlNPUlNfTE05NTI0MT1tCkNPTkZJR19T
RU5TT1JTX01BWDE2MDY1PW0KQ09ORklHX1NFTlNPUlNfTUFYMTYxOT1tCkNPTkZJR19TRU5TT1JT
X01BWDY2Mzk9bQpDT05GSUdfU0VOU09SU19NQVg2NjQyPW0KQ09ORklHX1NFTlNPUlNfTUFYNjY1
MD1tCkNPTkZJR19TRU5TT1JTX1BDODczNjA9bQpDT05GSUdfU0VOU09SU19QQzg3NDI3PW0KQ09O
RklHX1NFTlNPUlNfUENGODU5MT1tCkNPTkZJR19QTUJVUz1tCkNPTkZJR19TRU5TT1JTX1BNQlVT
PW0KQ09ORklHX1NFTlNPUlNfQURNMTI3NT1tCkNPTkZJR19TRU5TT1JTX01BWDE2MDY0PW0KQ09O
RklHX1NFTlNPUlNfTUFYMzQ0NDA9bQpDT05GSUdfU0VOU09SU19NQVg4Njg4PW0KQ09ORklHX1NF
TlNPUlNfVUNEOTAwMD1tCkNPTkZJR19TRU5TT1JTX1VDRDkyMDA9bQpDT05GSUdfU0VOU09SU19T
SFQyMT1tCkNPTkZJR19TRU5TT1JTX1NJUzU1OTU9bQpDT05GSUdfU0VOU09SU19TTU02NjU9bQpD
T05GSUdfU0VOU09SU19ETUUxNzM3PW0KQ09ORklHX1NFTlNPUlNfRU1DMTQwMz1tCkNPTkZJR19T
RU5TT1JTX0VNQzIxMDM9bQpDT05GSUdfU0VOU09SU19FTUM2VzIwMT1tCkNPTkZJR19TRU5TT1JT
X1NNU0M0N00xPW0KQ09ORklHX1NFTlNPUlNfU01TQzQ3TTE5Mj1tCkNPTkZJR19TRU5TT1JTX1NN
U0M0N0IzOTc9bQpDT05GSUdfU0VOU09SU19TQ0g1NjI3PW0KQ09ORklHX1NFTlNPUlNfQURTMTAx
NT1tCkNPTkZJR19TRU5TT1JTX0FEUzc4Mjg9bQpDT05GSUdfU0VOU09SU19BTUM2ODIxPW0KQ09O
RklHX1NFTlNPUlNfVEhNQzUwPW0KQ09ORklHX1NFTlNPUlNfVE1QMTAyPW0KQ09ORklHX1NFTlNP
UlNfVE1QNDAxPW0KQ09ORklHX1NFTlNPUlNfVE1QNDIxPW0KQ09ORklHX1NFTlNPUlNfVklBX0NQ
VVRFTVA9bQpDT05GSUdfU0VOU09SU19WSUE2ODZBPW0KQ09ORklHX1NFTlNPUlNfVlQxMjExPW0K
Q09ORklHX1NFTlNPUlNfVlQ4MjMxPW0KQ09ORklHX1NFTlNPUlNfVzgzNzgxRD1tCkNPTkZJR19T
RU5TT1JTX1c4Mzc5MUQ9bQpDT05GSUdfU0VOU09SU19XODM3OTJEPW0KQ09ORklHX1NFTlNPUlNf
VzgzNzkzPW0KQ09ORklHX1NFTlNPUlNfVzgzNzk1PW0KQ09ORklHX1NFTlNPUlNfVzgzNzk1X0ZB
TkNUUkw9eQpDT05GSUdfU0VOU09SU19XODNMNzg1VFM9bQpDT05GSUdfU0VOU09SU19XODNMNzg2
Tkc9bQpDT05GSUdfU0VOU09SU19XODM2MjdIRj1tCkNPTkZJR19TRU5TT1JTX1c4MzYyN0VIRj1t
CkNPTkZJR19TRU5TT1JTX0FQUExFU01DPW0KCiMKIyBBQ1BJIGRyaXZlcnMKIwpDT05GSUdfU0VO
U09SU19BQ1BJX1BPV0VSPW0KQ09ORklHX1NFTlNPUlNfQVRLMDExMD1tCkNPTkZJR19USEVSTUFM
PXkKQ09ORklHX1dBVENIRE9HPXkKQ09ORklHX1dBVENIRE9HX05PV0FZT1VUPXkKCiMKIyBXYXRj
aGRvZyBEZXZpY2UgRHJpdmVycwojCkNPTkZJR19TT0ZUX1dBVENIRE9HPW0KQ09ORklHX0FDUVVJ
UkVfV0RUPW0KQ09ORklHX0FEVkFOVEVDSF9XRFQ9bQpDT05GSUdfQUxJTTE1MzVfV0RUPW0KQ09O
RklHX0FMSU03MTAxX1dEVD1tCkNPTkZJR19GNzE4MDhFX1dEVD1tCkNPTkZJR19TUDUxMDBfVENP
PW0KQ09ORklHX1NDNTIwX1dEVD1tCkNPTkZJR19TQkNfRklUUEMyX1dBVENIRE9HPW0KQ09ORklH
X0VVUk9URUNIX1dEVD1tCkNPTkZJR19JQjcwMF9XRFQ9bQpDT05GSUdfSUJNQVNSPW0KQ09ORklH
X1dBRkVSX1dEVD1tCkNPTkZJR19JNjMwMEVTQl9XRFQ9bQpDT05GSUdfSVRDT19XRFQ9bQpDT05G
SUdfSVRDT19WRU5ET1JfU1VQUE9SVD15CkNPTkZJR19JVDg3MTJGX1dEVD1tCkNPTkZJR19JVDg3
X1dEVD1tCkNPTkZJR19IUF9XQVRDSERPRz1tCkNPTkZJR19IUFdEVF9OTUlfREVDT0RJTkc9eQpD
T05GSUdfU0MxMjAwX1dEVD1tCkNPTkZJR19QQzg3NDEzX1dEVD1tCkNPTkZJR19OVl9UQ089bQpD
T05GSUdfNjBYWF9XRFQ9bQpDT05GSUdfU0JDODM2MF9XRFQ9bQpDT05GSUdfU0JDNzI0MF9XRFQ9
bQpDT05GSUdfQ1BVNV9XRFQ9bQpDT05GSUdfU01TQ19TQ0gzMTFYX1dEVD1tCkNPTkZJR19TTVND
MzdCNzg3X1dEVD1tCkNPTkZJR19XODM2MjdIRl9XRFQ9bQpDT05GSUdfVzgzNjk3SEZfV0RUPW0K
Q09ORklHX1c4MzY5N1VHX1dEVD1tCkNPTkZJR19XODM4NzdGX1dEVD1tCkNPTkZJR19XODM5NzdG
X1dEVD1tCkNPTkZJR19NQUNIWl9XRFQ9bQpDT05GSUdfU0JDX0VQWF9DM19XQVRDSERPRz1tCiMg
Q09ORklHX1hFTl9XRFQgaXMgbm90IHNldAoKIwojIFBDSS1iYXNlZCBXYXRjaGRvZyBDYXJkcwoj
CkNPTkZJR19QQ0lQQ1dBVENIRE9HPW0KQ09ORklHX1dEVFBDST1tCgojCiMgVVNCLWJhc2VkIFdh
dGNoZG9nIENhcmRzCiMKQ09ORklHX1VTQlBDV0FUQ0hET0c9bQpDT05GSUdfU1NCX1BPU1NJQkxF
PXkKCiMKIyBTb25pY3MgU2lsaWNvbiBCYWNrcGxhbmUKIwpDT05GSUdfU1NCPW0KQ09ORklHX1NT
Ql9TUFJPTT15CkNPTkZJR19TU0JfUENJSE9TVF9QT1NTSUJMRT15CkNPTkZJR19TU0JfUENJSE9T
VD15CiMgQ09ORklHX1NTQl9CNDNfUENJX0JSSURHRSBpcyBub3Qgc2V0CiMgQ09ORklHX1NTQl9T
SUxFTlQgaXMgbm90IHNldAojIENPTkZJR19TU0JfREVCVUcgaXMgbm90IHNldApDT05GSUdfU1NC
X0RSSVZFUl9QQ0lDT1JFX1BPU1NJQkxFPXkKQ09ORklHX1NTQl9EUklWRVJfUENJQ09SRT15CkNP
TkZJR19CQ01BX1BPU1NJQkxFPXkKCiMKIyBCcm9hZGNvbSBzcGVjaWZpYyBBTUJBCiMKIyBDT05G
SUdfQkNNQSBpcyBub3Qgc2V0CiMgQ09ORklHX01GRF9TVVBQT1JUIGlzIG5vdCBzZXQKIyBDT05G
SUdfUkVHVUxBVE9SIGlzIG5vdCBzZXQKIyBDT05GSUdfTUVESUFfU1VQUE9SVCBpcyBub3Qgc2V0
CgojCiMgR3JhcGhpY3Mgc3VwcG9ydAojCiMgQ09ORklHX0FHUCBpcyBub3Qgc2V0CkNPTkZJR19W
R0FfQVJCPXkKQ09ORklHX1ZHQV9BUkJfTUFYX0dQVVM9MTYKIyBDT05GSUdfVkdBX1NXSVRDSEVS
T08gaXMgbm90IHNldAojIENPTkZJR19EUk0gaXMgbm90IHNldAojIENPTkZJR19TVFVCX1BPVUxT
Qk8gaXMgbm90IHNldAojIENPTkZJR19WR0FTVEFURSBpcyBub3Qgc2V0CiMgQ09ORklHX1ZJREVP
X09VVFBVVF9DT05UUk9MIGlzIG5vdCBzZXQKIyBDT05GSUdfRkIgaXMgbm90IHNldAojIENPTkZJ
R19CQUNLTElHSFRfTENEX1NVUFBPUlQgaXMgbm90IHNldAoKIwojIERpc3BsYXkgZGV2aWNlIHN1
cHBvcnQKIwojIENPTkZJR19ESVNQTEFZX1NVUFBPUlQgaXMgbm90IHNldAoKIwojIENvbnNvbGUg
ZGlzcGxheSBkcml2ZXIgc3VwcG9ydAojCkNPTkZJR19WR0FfQ09OU09MRT15CiMgQ09ORklHX1ZH
QUNPTl9TT0ZUX1NDUk9MTEJBQ0sgaXMgbm90IHNldApDT05GSUdfRFVNTVlfQ09OU09MRT15CiMg
Q09ORklHX1NPVU5EIGlzIG5vdCBzZXQKQ09ORklHX0hJRF9TVVBQT1JUPXkKQ09ORklHX0hJRD15
CiMgQ09ORklHX0hJRFJBVyBpcyBub3Qgc2V0CgojCiMgVVNCIElucHV0IERldmljZXMKIwpDT05G
SUdfVVNCX0hJRD15CiMgQ09ORklHX0hJRF9QSUQgaXMgbm90IHNldAojIENPTkZJR19VU0JfSElE
REVWIGlzIG5vdCBzZXQKCiMKIyBTcGVjaWFsIEhJRCBkcml2ZXJzCiMKQ09ORklHX0hJRF9BNFRF
Q0g9eQojIENPTkZJR19ISURfQUNSVVggaXMgbm90IHNldApDT05GSUdfSElEX0FQUExFPXkKQ09O
RklHX0hJRF9CRUxLSU49eQpDT05GSUdfSElEX0NIRVJSWT15CkNPTkZJR19ISURfQ0hJQ09OWT15
CkNPTkZJR19ISURfQ1lQUkVTUz15CiMgQ09ORklHX0hJRF9EUkFHT05SSVNFIGlzIG5vdCBzZXQK
IyBDT05GSUdfSElEX0VNU19GRiBpcyBub3Qgc2V0CkNPTkZJR19ISURfRVpLRVk9eQojIENPTkZJ
R19ISURfS0VZVE9VQ0ggaXMgbm90IHNldApDT05GSUdfSElEX0tZRT15CiMgQ09ORklHX0hJRF9V
Q0xPR0lDIGlzIG5vdCBzZXQKIyBDT05GSUdfSElEX1dBTFRPUCBpcyBub3Qgc2V0CiMgQ09ORklH
X0hJRF9HWVJBVElPTiBpcyBub3Qgc2V0CiMgQ09ORklHX0hJRF9UV0lOSEFOIGlzIG5vdCBzZXQK
Q09ORklHX0hJRF9LRU5TSU5HVE9OPXkKIyBDT05GSUdfSElEX0xDUE9XRVIgaXMgbm90IHNldApD
T05GSUdfSElEX0xPR0lURUNIPXkKIyBDT05GSUdfTE9HSVRFQ0hfRkYgaXMgbm90IHNldAojIENP
TkZJR19MT0dJUlVNQkxFUEFEMl9GRiBpcyBub3Qgc2V0CiMgQ09ORklHX0xPR0lHOTQwX0ZGIGlz
IG5vdCBzZXQKIyBDT05GSUdfTE9HSVdJSV9GRiBpcyBub3Qgc2V0CkNPTkZJR19ISURfTUlDUk9T
T0ZUPXkKQ09ORklHX0hJRF9NT05URVJFWT15CiMgQ09ORklHX0hJRF9NVUxUSVRPVUNIIGlzIG5v
dCBzZXQKIyBDT05GSUdfSElEX05UUklHIGlzIG5vdCBzZXQKIyBDT05GSUdfSElEX09SVEVLIGlz
IG5vdCBzZXQKIyBDT05GSUdfSElEX1BBTlRIRVJMT1JEIGlzIG5vdCBzZXQKIyBDT05GSUdfSElE
X1BFVEFMWU5YIGlzIG5vdCBzZXQKIyBDT05GSUdfSElEX1BJQ09MQ0QgaXMgbm90IHNldAojIENP
TkZJR19ISURfUVVBTlRBIGlzIG5vdCBzZXQKIyBDT05GSUdfSElEX1JPQ0NBVCBpcyBub3Qgc2V0
CiMgQ09ORklHX0hJRF9ST0NDQVRfQVJWTyBpcyBub3Qgc2V0CiMgQ09ORklHX0hJRF9ST0NDQVRf
S09ORSBpcyBub3Qgc2V0CiMgQ09ORklHX0hJRF9ST0NDQVRfS09ORVBMVVMgaXMgbm90IHNldAoj
IENPTkZJR19ISURfUk9DQ0FUX0tPVkFQTFVTIGlzIG5vdCBzZXQKIyBDT05GSUdfSElEX1JPQ0NB
VF9QWVJBIGlzIG5vdCBzZXQKIyBDT05GSUdfSElEX1NBTVNVTkcgaXMgbm90IHNldAojIENPTkZJ
R19ISURfU09OWSBpcyBub3Qgc2V0CiMgQ09ORklHX0hJRF9TVU5QTFVTIGlzIG5vdCBzZXQKIyBD
T05GSUdfSElEX0dSRUVOQVNJQSBpcyBub3Qgc2V0CiMgQ09ORklHX0hJRF9TTUFSVEpPWVBMVVMg
aXMgbm90IHNldAojIENPTkZJR19ISURfVE9QU0VFRCBpcyBub3Qgc2V0CiMgQ09ORklHX0hJRF9U
SFJVU1RNQVNURVIgaXMgbm90IHNldAojIENPTkZJR19ISURfWkVST1BMVVMgaXMgbm90IHNldAoj
IENPTkZJR19ISURfWllEQUNST04gaXMgbm90IHNldApDT05GSUdfVVNCX1NVUFBPUlQ9eQpDT05G
SUdfVVNCX0FSQ0hfSEFTX0hDRD15CkNPTkZJR19VU0JfQVJDSF9IQVNfT0hDST15CkNPTkZJR19V
U0JfQVJDSF9IQVNfRUhDST15CkNPTkZJR19VU0I9eQojIENPTkZJR19VU0JfREVCVUcgaXMgbm90
IHNldAojIENPTkZJR19VU0JfQU5OT1VOQ0VfTkVXX0RFVklDRVMgaXMgbm90IHNldAoKIwojIE1p
c2NlbGxhbmVvdXMgVVNCIG9wdGlvbnMKIwojIENPTkZJR19VU0JfREVWSUNFRlMgaXMgbm90IHNl
dAojIENPTkZJR19VU0JfREVWSUNFX0NMQVNTIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX0RZTkFN
SUNfTUlOT1JTIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX09UR19XSElURUxJU1QgaXMgbm90IHNl
dAojIENPTkZJR19VU0JfT1RHX0JMQUNLTElTVF9IVUIgaXMgbm90IHNldAojIENPTkZJR19VU0Jf
TU9OIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX1dVU0IgaXMgbm90IHNldAojIENPTkZJR19VU0Jf
V1VTQl9DQkFGIGlzIG5vdCBzZXQKCiMKIyBVU0IgSG9zdCBDb250cm9sbGVyIERyaXZlcnMKIwoj
IENPTkZJR19VU0JfQzY3WDAwX0hDRCBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9YSENJX0hDRCBp
cyBub3Qgc2V0CkNPTkZJR19VU0JfRUhDSV9IQ0Q9bQpDT05GSUdfVVNCX0VIQ0lfUk9PVF9IVUJf
VFQ9eQpDT05GSUdfVVNCX0VIQ0lfVFRfTkVXU0NIRUQ9eQojIENPTkZJR19VU0JfT1hVMjEwSFBf
SENEIGlzIG5vdCBzZXQKQ09ORklHX1VTQl9JU1AxMTZYX0hDRD1tCiMgQ09ORklHX1VTQl9JU1Ax
NzYwX0hDRCBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9JU1AxMzYyX0hDRCBpcyBub3Qgc2V0CkNP
TkZJR19VU0JfT0hDSV9IQ0Q9bQojIENPTkZJR19VU0JfT0hDSV9IQ0RfU1NCIGlzIG5vdCBzZXQK
IyBDT05GSUdfVVNCX09IQ0lfQklHX0VORElBTl9ERVNDIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNC
X09IQ0lfQklHX0VORElBTl9NTUlPIGlzIG5vdCBzZXQKQ09ORklHX1VTQl9PSENJX0xJVFRMRV9F
TkRJQU49eQpDT05GSUdfVVNCX1VIQ0lfSENEPW0KQ09ORklHX1VTQl9TTDgxMV9IQ0Q9bQojIENP
TkZJR19VU0JfU0w4MTFfSENEX0lTTyBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9SOEE2NjU5N19I
Q0QgaXMgbm90IHNldAojIENPTkZJR19VU0JfV0hDSV9IQ0QgaXMgbm90IHNldAojIENPTkZJR19V
U0JfSFdBX0hDRCBpcyBub3Qgc2V0CgojCiMgVVNCIERldmljZSBDbGFzcyBkcml2ZXJzCiMKIyBD
T05GSUdfVVNCX0FDTSBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9QUklOVEVSIGlzIG5vdCBzZXQK
IyBDT05GSUdfVVNCX1dETSBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9UTUMgaXMgbm90IHNldAoK
IwojIE5PVEU6IFVTQl9TVE9SQUdFIGRlcGVuZHMgb24gU0NTSSBidXQgQkxLX0RFVl9TRCBtYXkK
IwoKIwojIGFsc28gYmUgbmVlZGVkOyBzZWUgVVNCX1NUT1JBR0UgSGVscCBmb3IgbW9yZSBpbmZv
CiMKQ09ORklHX1VTQl9TVE9SQUdFPW0KIyBDT05GSUdfVVNCX1NUT1JBR0VfREVCVUcgaXMgbm90
IHNldAojIENPTkZJR19VU0JfU1RPUkFHRV9SRUFMVEVLIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNC
X1NUT1JBR0VfREFUQUZBQiBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9TVE9SQUdFX0ZSRUVDT00g
aXMgbm90IHNldAojIENPTkZJR19VU0JfU1RPUkFHRV9JU0QyMDAgaXMgbm90IHNldAojIENPTkZJ
R19VU0JfU1RPUkFHRV9VU0JBVCBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9TVE9SQUdFX1NERFIw
OSBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9TVE9SQUdFX1NERFI1NSBpcyBub3Qgc2V0CiMgQ09O
RklHX1VTQl9TVE9SQUdFX0pVTVBTSE9UIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX1NUT1JBR0Vf
QUxBVURBIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX1NUT1JBR0VfT05FVE9VQ0ggaXMgbm90IHNl
dAojIENPTkZJR19VU0JfU1RPUkFHRV9LQVJNQSBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9TVE9S
QUdFX0NZUFJFU1NfQVRBQ0IgaXMgbm90IHNldAojIENPTkZJR19VU0JfU1RPUkFHRV9FTkVfVUI2
MjUwIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX1VBUyBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9M
SUJVU1VBTCBpcyBub3Qgc2V0CgojCiMgVVNCIEltYWdpbmcgZGV2aWNlcwojCiMgQ09ORklHX1VT
Ql9NREM4MDAgaXMgbm90IHNldAojIENPTkZJR19VU0JfTUlDUk9URUsgaXMgbm90IHNldAoKIwoj
IFVTQiBwb3J0IGRyaXZlcnMKIwojIENPTkZJR19VU0JfVVNTNzIwIGlzIG5vdCBzZXQKIyBDT05G
SUdfVVNCX1NFUklBTCBpcyBub3Qgc2V0CgojCiMgVVNCIE1pc2NlbGxhbmVvdXMgZHJpdmVycwoj
CiMgQ09ORklHX1VTQl9FTUk2MiBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9FTUkyNiBpcyBub3Qg
c2V0CiMgQ09ORklHX1VTQl9BRFVUVVggaXMgbm90IHNldAojIENPTkZJR19VU0JfU0VWU0VHIGlz
IG5vdCBzZXQKIyBDT05GSUdfVVNCX1JJTzUwMCBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9MRUdP
VE9XRVIgaXMgbm90IHNldAojIENPTkZJR19VU0JfTENEIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNC
X0xFRCBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9DWVBSRVNTX0NZN0M2MyBpcyBub3Qgc2V0CiMg
Q09ORklHX1VTQl9DWVRIRVJNIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX0lETU9VU0UgaXMgbm90
IHNldAojIENPTkZJR19VU0JfRlRESV9FTEFOIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX0FQUExF
RElTUExBWSBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9TSVNVU0JWR0EgaXMgbm90IHNldAojIENP
TkZJR19VU0JfTEQgaXMgbm90IHNldAojIENPTkZJR19VU0JfVFJBTkNFVklCUkFUT1IgaXMgbm90
IHNldAojIENPTkZJR19VU0JfSU9XQVJSSU9SIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX1RFU1Qg
aXMgbm90IHNldAojIENPTkZJR19VU0JfSVNJR0hURlcgaXMgbm90IHNldAojIENPTkZJR19VU0Jf
WVVSRVggaXMgbm90IHNldAojIENPTkZJR19VU0JfR0FER0VUIGlzIG5vdCBzZXQKCiMKIyBPVEcg
YW5kIHJlbGF0ZWQgaW5mcmFzdHJ1Y3R1cmUKIwojIENPTkZJR19OT1BfVVNCX1hDRUlWIGlzIG5v
dCBzZXQKIyBDT05GSUdfVVdCIGlzIG5vdCBzZXQKIyBDT05GSUdfTU1DIGlzIG5vdCBzZXQKIyBD
T05GSUdfTUVNU1RJQ0sgaXMgbm90IHNldApDT05GSUdfTkVXX0xFRFM9eQpDT05GSUdfTEVEU19D
TEFTUz15CgojCiMgTEVEIGRyaXZlcnMKIwojIENPTkZJR19MRURTX0xNMzUzMCBpcyBub3Qgc2V0
CiMgQ09ORklHX0xFRFNfQUxJWDIgaXMgbm90IHNldAojIENPTkZJR19MRURTX1BDQTk1MzIgaXMg
bm90IHNldAojIENPTkZJR19MRURTX0xQMzk0NCBpcyBub3Qgc2V0CiMgQ09ORklHX0xFRFNfTFA1
NTIxIGlzIG5vdCBzZXQKIyBDT05GSUdfTEVEU19MUDU1MjMgaXMgbm90IHNldAojIENPTkZJR19M
RURTX0NMRVZPX01BSUwgaXMgbm90IHNldAojIENPTkZJR19MRURTX1BDQTk1NVggaXMgbm90IHNl
dAojIENPTkZJR19MRURTX0JEMjgwMiBpcyBub3Qgc2V0CiMgQ09ORklHX0xFRFNfSU5URUxfU1M0
MjAwIGlzIG5vdCBzZXQKIyBDT05GSUdfTEVEU19UUklHR0VSUyBpcyBub3Qgc2V0CgojCiMgTEVE
IFRyaWdnZXJzCiMKIyBDT05GSUdfTkZDX0RFVklDRVMgaXMgbm90IHNldAojIENPTkZJR19BQ0NF
U1NJQklMSVRZIGlzIG5vdCBzZXQKQ09ORklHX0lORklOSUJBTkQ9bQojIENPTkZJR19JTkZJTklC
QU5EX1VTRVJfTUFEIGlzIG5vdCBzZXQKIyBDT05GSUdfSU5GSU5JQkFORF9VU0VSX0FDQ0VTUyBp
cyBub3Qgc2V0CkNPTkZJR19JTkZJTklCQU5EX0FERFJfVFJBTlM9eQpDT05GSUdfSU5GSU5JQkFO
RF9NVEhDQT1tCkNPTkZJR19JTkZJTklCQU5EX01USENBX0RFQlVHPXkKIyBDT05GSUdfSU5GSU5J
QkFORF9BTVNPMTEwMCBpcyBub3Qgc2V0CiMgQ09ORklHX0lORklOSUJBTkRfQ1hHQjMgaXMgbm90
IHNldAojIENPTkZJR19JTkZJTklCQU5EX0NYR0I0IGlzIG5vdCBzZXQKIyBDT05GSUdfTUxYNF9J
TkZJTklCQU5EIGlzIG5vdCBzZXQKIyBDT05GSUdfSU5GSU5JQkFORF9ORVMgaXMgbm90IHNldApD
T05GSUdfSU5GSU5JQkFORF9JUE9JQj1tCiMgQ09ORklHX0lORklOSUJBTkRfSVBPSUJfQ00gaXMg
bm90IHNldApDT05GSUdfSU5GSU5JQkFORF9JUE9JQl9ERUJVRz15CiMgQ09ORklHX0lORklOSUJB
TkRfSVBPSUJfREVCVUdfREFUQSBpcyBub3Qgc2V0CkNPTkZJR19JTkZJTklCQU5EX1NSUD1tCkNP
TkZJR19JTkZJTklCQU5EX0lTRVI9bQojIENPTkZJR19FREFDIGlzIG5vdCBzZXQKIyBDT05GSUdf
UlRDX0NMQVNTIGlzIG5vdCBzZXQKQ09ORklHX0RNQURFVklDRVM9eQojIENPTkZJR19ETUFERVZJ
Q0VTX0RFQlVHIGlzIG5vdCBzZXQKCiMKIyBETUEgRGV2aWNlcwojCkNPTkZJR19JTlRFTF9NSURf
RE1BQz1tCkNPTkZJR19JTlRFTF9JT0FURE1BPW0KQ09ORklHX1RJTUJfRE1BPW0KQ09ORklHX1BD
SF9ETUE9bQpDT05GSUdfRE1BX0VOR0lORT15CgojCiMgRE1BIENsaWVudHMKIwpDT05GSUdfTkVU
X0RNQT15CkNPTkZJR19BU1lOQ19UWF9ETUE9eQpDT05GSUdfRE1BVEVTVD1tCkNPTkZJR19EQ0E9
bQojIENPTkZJR19BVVhESVNQTEFZIGlzIG5vdCBzZXQKIyBDT05GSUdfVUlPIGlzIG5vdCBzZXQK
CiMKIyBYZW4gZHJpdmVyIHN1cHBvcnQKIwpDT05GSUdfWEVOX0JBTExPT049eQpDT05GSUdfWEVO
X1NDUlVCX1BBR0VTPXkKQ09ORklHX1hFTl9ERVZfRVZUQ0hOPXkKQ09ORklHX1hFTl9CQUNLRU5E
PXkKQ09ORklHX1hFTkZTPW0KQ09ORklHX1hFTl9DT01QQVRfWEVORlM9eQpDT05GSUdfWEVOX1NZ
U19IWVBFUlZJU09SPXkKQ09ORklHX1hFTl9HTlRERVY9bQpDT05GSUdfWEVOX0dSQU5UX0RFVl9B
TExPQz1tCkNPTkZJR19YRU5fUExBVEZPUk1fUENJPW0KQ09ORklHX1NXSU9UTEJfWEVOPXkKIyBD
T05GSUdfU1RBR0lORyBpcyBub3Qgc2V0CiMgQ09ORklHX1g4Nl9QTEFURk9STV9ERVZJQ0VTIGlz
IG5vdCBzZXQKQ09ORklHX0NMS1NSQ19JODI1Mz15CgojCiMgRmlybXdhcmUgRHJpdmVycwojCiMg
Q09ORklHX0VERCBpcyBub3Qgc2V0CkNPTkZJR19GSVJNV0FSRV9NRU1NQVA9eQojIENPTkZJR19E
RUxMX1JCVSBpcyBub3Qgc2V0CiMgQ09ORklHX0RDREJBUyBpcyBub3Qgc2V0CkNPTkZJR19ETUlJ
RD15CiMgQ09ORklHX0RNSV9TWVNGUyBpcyBub3Qgc2V0CiMgQ09ORklHX0lTQ1NJX0lCRlRfRklO
RCBpcyBub3Qgc2V0CiMgQ09ORklHX1NJR01BIGlzIG5vdCBzZXQKIyBDT05GSUdfR09PR0xFX0ZJ
Uk1XQVJFIGlzIG5vdCBzZXQKCiMKIyBGaWxlIHN5c3RlbXMKIwpDT05GSUdfRVhUMl9GUz1tCiMg
Q09ORklHX0VYVDJfRlNfWEFUVFIgaXMgbm90IHNldAojIENPTkZJR19FWFQyX0ZTX1hJUCBpcyBu
b3Qgc2V0CkNPTkZJR19FWFQzX0ZTPW0KQ09ORklHX0VYVDNfREVGQVVMVFNfVE9fT1JERVJFRD15
CiMgQ09ORklHX0VYVDNfRlNfWEFUVFIgaXMgbm90IHNldApDT05GSUdfRVhUNF9GUz1tCiMgQ09O
RklHX0VYVDRfRlNfWEFUVFIgaXMgbm90IHNldAojIENPTkZJR19FWFQ0X0RFQlVHIGlzIG5vdCBz
ZXQKQ09ORklHX0pCRD1tCkNPTkZJR19KQkQyPW0KIyBDT05GSUdfUkVJU0VSRlNfRlMgaXMgbm90
IHNldAojIENPTkZJR19KRlNfRlMgaXMgbm90IHNldAojIENPTkZJR19YRlNfRlMgaXMgbm90IHNl
dAojIENPTkZJR19HRlMyX0ZTIGlzIG5vdCBzZXQKIyBDT05GSUdfQlRSRlNfRlMgaXMgbm90IHNl
dAojIENPTkZJR19OSUxGUzJfRlMgaXMgbm90IHNldApDT05GSUdfRlNfUE9TSVhfQUNMPXkKQ09O
RklHX0VYUE9SVEZTPW0KQ09ORklHX0ZJTEVfTE9DS0lORz15CkNPTkZJR19GU05PVElGWT15CkNP
TkZJR19ETk9USUZZPXkKQ09ORklHX0lOT1RJRllfVVNFUj15CiMgQ09ORklHX0ZBTk9USUZZIGlz
IG5vdCBzZXQKIyBDT05GSUdfUVVPVEEgaXMgbm90IHNldAojIENPTkZJR19RVU9UQUNUTCBpcyBu
b3Qgc2V0CkNPTkZJR19BVVRPRlM0X0ZTPXkKQ09ORklHX0ZVU0VfRlM9bQpDT05GSUdfQ1VTRT1t
CgojCiMgQ2FjaGVzCiMKIyBDT05GSUdfRlNDQUNIRSBpcyBub3Qgc2V0CgojCiMgQ0QtUk9NL0RW
RCBGaWxlc3lzdGVtcwojCkNPTkZJR19JU085NjYwX0ZTPW0KQ09ORklHX0pPTElFVD15CkNPTkZJ
R19aSVNPRlM9eQpDT05GSUdfVURGX0ZTPW0KQ09ORklHX1VERl9OTFM9eQoKIwojIERPUy9GQVQv
TlQgRmlsZXN5c3RlbXMKIwojIENPTkZJR19NU0RPU19GUyBpcyBub3Qgc2V0CiMgQ09ORklHX1ZG
QVRfRlMgaXMgbm90IHNldAojIENPTkZJR19OVEZTX0ZTIGlzIG5vdCBzZXQKCiMKIyBQc2V1ZG8g
ZmlsZXN5c3RlbXMKIwpDT05GSUdfUFJPQ19GUz15CkNPTkZJR19QUk9DX0tDT1JFPXkKQ09ORklH
X1BST0NfU1lTQ1RMPXkKQ09ORklHX1BST0NfUEFHRV9NT05JVE9SPXkKQ09ORklHX1NZU0ZTPXkK
Q09ORklHX1RNUEZTPXkKIyBDT05GSUdfVE1QRlNfUE9TSVhfQUNMIGlzIG5vdCBzZXQKIyBDT05G
SUdfVE1QRlNfWEFUVFIgaXMgbm90IHNldAojIENPTkZJR19IVUdFVExCRlMgaXMgbm90IHNldAoj
IENPTkZJR19IVUdFVExCX1BBR0UgaXMgbm90IHNldAojIENPTkZJR19DT05GSUdGU19GUyBpcyBu
b3Qgc2V0CkNPTkZJR19NSVNDX0ZJTEVTWVNURU1TPXkKIyBDT05GSUdfQURGU19GUyBpcyBub3Qg
c2V0CiMgQ09ORklHX0FGRlNfRlMgaXMgbm90IHNldAojIENPTkZJR19IRlNfRlMgaXMgbm90IHNl
dAojIENPTkZJR19IRlNQTFVTX0ZTIGlzIG5vdCBzZXQKIyBDT05GSUdfQkVGU19GUyBpcyBub3Qg
c2V0CiMgQ09ORklHX0JGU19GUyBpcyBub3Qgc2V0CiMgQ09ORklHX0VGU19GUyBpcyBub3Qgc2V0
CiMgQ09ORklHX0xPR0ZTIGlzIG5vdCBzZXQKQ09ORklHX0NSQU1GUz1tCiMgQ09ORklHX1NRVUFT
SEZTIGlzIG5vdCBzZXQKIyBDT05GSUdfVlhGU19GUyBpcyBub3Qgc2V0CiMgQ09ORklHX01JTklY
X0ZTIGlzIG5vdCBzZXQKIyBDT05GSUdfT01GU19GUyBpcyBub3Qgc2V0CiMgQ09ORklHX0hQRlNf
RlMgaXMgbm90IHNldAojIENPTkZJR19RTlg0RlNfRlMgaXMgbm90IHNldAojIENPTkZJR19ST01G
U19GUyBpcyBub3Qgc2V0CiMgQ09ORklHX1BTVE9SRSBpcyBub3Qgc2V0CiMgQ09ORklHX1NZU1Zf
RlMgaXMgbm90IHNldAojIENPTkZJR19VRlNfRlMgaXMgbm90IHNldApDT05GSUdfTkVUV09SS19G
SUxFU1lTVEVNUz15CkNPTkZJR19ORlNfRlM9bQpDT05GSUdfTkZTX1YzPXkKIyBDT05GSUdfTkZT
X1YzX0FDTCBpcyBub3Qgc2V0CiMgQ09ORklHX05GU19WNCBpcyBub3Qgc2V0CkNPTkZJR19ORlNE
PW0KQ09ORklHX05GU0RfREVQUkVDQVRFRD15CkNPTkZJR19ORlNEX1YyX0FDTD15CkNPTkZJR19O
RlNEX1YzPXkKQ09ORklHX05GU0RfVjNfQUNMPXkKQ09ORklHX05GU0RfVjQ9eQpDT05GSUdfTE9D
S0Q9bQpDT05GSUdfTE9DS0RfVjQ9eQpDT05GSUdfTkZTX0FDTF9TVVBQT1JUPW0KQ09ORklHX05G
U19DT01NT049eQpDT05GSUdfU1VOUlBDPW0KQ09ORklHX1NVTlJQQ19HU1M9bQpDT05GSUdfU1VO
UlBDX1hQUlRfUkRNQT1tCiMgQ09ORklHX0NFUEhfRlMgaXMgbm90IHNldApDT05GSUdfQ0lGUz1t
CiMgQ09ORklHX0NJRlNfU1RBVFMgaXMgbm90IHNldAojIENPTkZJR19DSUZTX1dFQUtfUFdfSEFT
SCBpcyBub3Qgc2V0CkNPTkZJR19DSUZTX1hBVFRSPXkKQ09ORklHX0NJRlNfUE9TSVg9eQojIENP
TkZJR19DSUZTX0RFQlVHMiBpcyBub3Qgc2V0CiMgQ09ORklHX05DUF9GUyBpcyBub3Qgc2V0CiMg
Q09ORklHX0NPREFfRlMgaXMgbm90IHNldAojIENPTkZJR19BRlNfRlMgaXMgbm90IHNldAoKIwoj
IFBhcnRpdGlvbiBUeXBlcwojCiMgQ09ORklHX1BBUlRJVElPTl9BRFZBTkNFRCBpcyBub3Qgc2V0
CkNPTkZJR19NU0RPU19QQVJUSVRJT049eQpDT05GSUdfTkxTPXkKQ09ORklHX05MU19ERUZBVUxU
PSJpc284ODU5LTEiCkNPTkZJR19OTFNfQ09ERVBBR0VfNDM3PXkKIyBDT05GSUdfTkxTX0NPREVQ
QUdFXzczNyBpcyBub3Qgc2V0CiMgQ09ORklHX05MU19DT0RFUEFHRV83NzUgaXMgbm90IHNldAoj
IENPTkZJR19OTFNfQ09ERVBBR0VfODUwIGlzIG5vdCBzZXQKIyBDT05GSUdfTkxTX0NPREVQQUdF
Xzg1MiBpcyBub3Qgc2V0CiMgQ09ORklHX05MU19DT0RFUEFHRV84NTUgaXMgbm90IHNldAojIENP
TkZJR19OTFNfQ09ERVBBR0VfODU3IGlzIG5vdCBzZXQKIyBDT05GSUdfTkxTX0NPREVQQUdFXzg2
MCBpcyBub3Qgc2V0CiMgQ09ORklHX05MU19DT0RFUEFHRV84NjEgaXMgbm90IHNldAojIENPTkZJ
R19OTFNfQ09ERVBBR0VfODYyIGlzIG5vdCBzZXQKIyBDT05GSUdfTkxTX0NPREVQQUdFXzg2MyBp
cyBub3Qgc2V0CiMgQ09ORklHX05MU19DT0RFUEFHRV84NjQgaXMgbm90IHNldAojIENPTkZJR19O
TFNfQ09ERVBBR0VfODY1IGlzIG5vdCBzZXQKIyBDT05GSUdfTkxTX0NPREVQQUdFXzg2NiBpcyBu
b3Qgc2V0CiMgQ09ORklHX05MU19DT0RFUEFHRV84NjkgaXMgbm90IHNldAojIENPTkZJR19OTFNf
Q09ERVBBR0VfOTM2IGlzIG5vdCBzZXQKIyBDT05GSUdfTkxTX0NPREVQQUdFXzk1MCBpcyBub3Qg
c2V0CiMgQ09ORklHX05MU19DT0RFUEFHRV85MzIgaXMgbm90IHNldAojIENPTkZJR19OTFNfQ09E
RVBBR0VfOTQ5IGlzIG5vdCBzZXQKIyBDT05GSUdfTkxTX0NPREVQQUdFXzg3NCBpcyBub3Qgc2V0
CiMgQ09ORklHX05MU19JU084ODU5XzggaXMgbm90IHNldAojIENPTkZJR19OTFNfQ09ERVBBR0Vf
MTI1MCBpcyBub3Qgc2V0CiMgQ09ORklHX05MU19DT0RFUEFHRV8xMjUxIGlzIG5vdCBzZXQKIyBD
T05GSUdfTkxTX0FTQ0lJIGlzIG5vdCBzZXQKQ09ORklHX05MU19JU084ODU5XzE9eQojIENPTkZJ
R19OTFNfSVNPODg1OV8yIGlzIG5vdCBzZXQKIyBDT05GSUdfTkxTX0lTTzg4NTlfMyBpcyBub3Qg
c2V0CiMgQ09ORklHX05MU19JU084ODU5XzQgaXMgbm90IHNldAojIENPTkZJR19OTFNfSVNPODg1
OV81IGlzIG5vdCBzZXQKIyBDT05GSUdfTkxTX0lTTzg4NTlfNiBpcyBub3Qgc2V0CiMgQ09ORklH
X05MU19JU084ODU5XzcgaXMgbm90IHNldAojIENPTkZJR19OTFNfSVNPODg1OV85IGlzIG5vdCBz
ZXQKIyBDT05GSUdfTkxTX0lTTzg4NTlfMTMgaXMgbm90IHNldAojIENPTkZJR19OTFNfSVNPODg1
OV8xNCBpcyBub3Qgc2V0CiMgQ09ORklHX05MU19JU084ODU5XzE1IGlzIG5vdCBzZXQKIyBDT05G
SUdfTkxTX0tPSThfUiBpcyBub3Qgc2V0CiMgQ09ORklHX05MU19LT0k4X1UgaXMgbm90IHNldApD
T05GSUdfTkxTX1VURjg9eQoKIwojIEtlcm5lbCBoYWNraW5nCiMKQ09ORklHX1RSQUNFX0lSUUZM
QUdTX1NVUFBPUlQ9eQpDT05GSUdfUFJJTlRLX1RJTUU9eQpDT05GSUdfREVGQVVMVF9NRVNTQUdF
X0xPR0xFVkVMPTQKQ09ORklHX0VOQUJMRV9XQVJOX0RFUFJFQ0FURUQ9eQpDT05GSUdfRU5BQkxF
X01VU1RfQ0hFQ0s9eQpDT05GSUdfRlJBTUVfV0FSTj0xMDI0CkNPTkZJR19NQUdJQ19TWVNSUT15
CiMgQ09ORklHX1NUUklQX0FTTV9TWU1TIGlzIG5vdCBzZXQKIyBDT05GSUdfVU5VU0VEX1NZTUJP
TFMgaXMgbm90IHNldAojIENPTkZJR19ERUJVR19GUyBpcyBub3Qgc2V0CiMgQ09ORklHX0hFQURF
UlNfQ0hFQ0sgaXMgbm90IHNldAojIENPTkZJR19ERUJVR19TRUNUSU9OX01JU01BVENIIGlzIG5v
dCBzZXQKIyBDT05GSUdfREVCVUdfS0VSTkVMIGlzIG5vdCBzZXQKIyBDT05GSUdfSEFSRExPQ0tV
UF9ERVRFQ1RPUiBpcyBub3Qgc2V0CiMgQ09ORklHX1NQQVJTRV9SQ1VfUE9JTlRFUiBpcyBub3Qg
c2V0CkNPTkZJR19ERUJVR19CVUdWRVJCT1NFPXkKQ09ORklHX0RFQlVHX01FTU9SWV9JTklUPXkK
Q09ORklHX0FSQ0hfV0FOVF9GUkFNRV9QT0lOVEVSUz15CkNPTkZJR19GUkFNRV9QT0lOVEVSPXkK
Q09ORklHX1JDVV9DUFVfU1RBTExfVElNRU9VVD02MAojIENPTkZJR19TWVNDVExfU1lTQ0FMTF9D
SEVDSyBpcyBub3Qgc2V0CkNPTkZJR19VU0VSX1NUQUNLVFJBQ0VfU1VQUE9SVD15CkNPTkZJR19I
QVZFX0ZVTkNUSU9OX1RSQUNFUj15CkNPTkZJR19IQVZFX0ZVTkNUSU9OX0dSQVBIX1RSQUNFUj15
CkNPTkZJR19IQVZFX0ZVTkNUSU9OX0dSQVBIX0ZQX1RFU1Q9eQpDT05GSUdfSEFWRV9GVU5DVElP
Tl9UUkFDRV9NQ09VTlRfVEVTVD15CkNPTkZJR19IQVZFX0RZTkFNSUNfRlRSQUNFPXkKQ09ORklH
X0hBVkVfRlRSQUNFX01DT1VOVF9SRUNPUkQ9eQpDT05GSUdfSEFWRV9TWVNDQUxMX1RSQUNFUE9J
TlRTPXkKQ09ORklHX0hBVkVfQ19SRUNPUkRNQ09VTlQ9eQpDT05GSUdfVFJBQ0lOR19TVVBQT1JU
PXkKIyBDT05GSUdfRlRSQUNFIGlzIG5vdCBzZXQKIyBDT05GSUdfUFJPVklERV9PSENJMTM5NF9E
TUFfSU5JVCBpcyBub3Qgc2V0CiMgQ09ORklHX0RNQV9BUElfREVCVUcgaXMgbm90IHNldAojIENP
TkZJR19BVE9NSUM2NF9TRUxGVEVTVCBpcyBub3Qgc2V0CiMgQ09ORklHX0FTWU5DX1JBSUQ2X1RF
U1QgaXMgbm90IHNldAojIENPTkZJR19TQU1QTEVTIGlzIG5vdCBzZXQKQ09ORklHX0hBVkVfQVJD
SF9LR0RCPXkKQ09ORklHX0hBVkVfQVJDSF9LTUVNQ0hFQ0s9eQojIENPTkZJR19URVNUX0tTVFJU
T1ggaXMgbm90IHNldAojIENPTkZJR19TVFJJQ1RfREVWTUVNIGlzIG5vdCBzZXQKQ09ORklHX1g4
Nl9WRVJCT1NFX0JPT1RVUD15CkNPTkZJR19FQVJMWV9QUklOVEs9eQojIENPTkZJR19FQVJMWV9Q
UklOVEtfREJHUCBpcyBub3Qgc2V0CiMgQ09ORklHX0RFQlVHX1NFVF9NT0RVTEVfUk9OWCBpcyBu
b3Qgc2V0CkNPTkZJR19ET1VCTEVGQVVMVD15CiMgQ09ORklHX0lPTU1VX1NUUkVTUyBpcyBub3Qg
c2V0CkNPTkZJR19IQVZFX01NSU9UUkFDRV9TVVBQT1JUPXkKQ09ORklHX0lPX0RFTEFZX1RZUEVf
MFg4MD0wCkNPTkZJR19JT19ERUxBWV9UWVBFXzBYRUQ9MQpDT05GSUdfSU9fREVMQVlfVFlQRV9V
REVMQVk9MgpDT05GSUdfSU9fREVMQVlfVFlQRV9OT05FPTMKQ09ORklHX0lPX0RFTEFZXzBYODA9
eQojIENPTkZJR19JT19ERUxBWV8wWEVEIGlzIG5vdCBzZXQKIyBDT05GSUdfSU9fREVMQVlfVURF
TEFZIGlzIG5vdCBzZXQKIyBDT05GSUdfSU9fREVMQVlfTk9ORSBpcyBub3Qgc2V0CkNPTkZJR19E
RUZBVUxUX0lPX0RFTEFZX1RZUEU9MAojIENPTkZJR19PUFRJTUlaRV9JTkxJTklORyBpcyBub3Qg
c2V0CgojCiMgU2VjdXJpdHkgb3B0aW9ucwojCiMgQ09ORklHX0tFWVMgaXMgbm90IHNldAojIENP
TkZJR19TRUNVUklUWV9ETUVTR19SRVNUUklDVCBpcyBub3Qgc2V0CiMgQ09ORklHX1NFQ1VSSVRZ
IGlzIG5vdCBzZXQKIyBDT05GSUdfU0VDVVJJVFlGUyBpcyBub3Qgc2V0CkNPTkZJR19ERUZBVUxU
X1NFQ1VSSVRZX0RBQz15CkNPTkZJR19ERUZBVUxUX1NFQ1VSSVRZPSIiCkNPTkZJR19YT1JfQkxP
Q0tTPW0KQ09ORklHX0FTWU5DX0NPUkU9bQpDT05GSUdfQVNZTkNfTUVNQ1BZPW0KQ09ORklHX0FT
WU5DX1hPUj1tCkNPTkZJR19BU1lOQ19QUT1tCkNPTkZJR19BU1lOQ19SQUlENl9SRUNPVj1tCkNP
TkZJR19BU1lOQ19UWF9ESVNBQkxFX1BRX1ZBTF9ETUE9eQpDT05GSUdfQVNZTkNfVFhfRElTQUJM
RV9YT1JfVkFMX0RNQT15CkNPTkZJR19DUllQVE89eQoKIwojIENyeXB0byBjb3JlIG9yIGhlbHBl
cgojCkNPTkZJR19DUllQVE9fQUxHQVBJPXkKQ09ORklHX0NSWVBUT19BTEdBUEkyPXkKQ09ORklH
X0NSWVBUT19BRUFEPW0KQ09ORklHX0NSWVBUT19BRUFEMj15CkNPTkZJR19DUllQVE9fQkxLQ0lQ
SEVSPW0KQ09ORklHX0NSWVBUT19CTEtDSVBIRVIyPXkKQ09ORklHX0NSWVBUT19IQVNIPXkKQ09O
RklHX0NSWVBUT19IQVNIMj15CkNPTkZJR19DUllQVE9fUk5HPW0KQ09ORklHX0NSWVBUT19STkcy
PXkKQ09ORklHX0NSWVBUT19QQ09NUDI9eQpDT05GSUdfQ1JZUFRPX01BTkFHRVI9eQpDT05GSUdf
Q1JZUFRPX01BTkFHRVIyPXkKQ09ORklHX0NSWVBUT19NQU5BR0VSX0RJU0FCTEVfVEVTVFM9eQoj
IENPTkZJR19DUllQVE9fR0YxMjhNVUwgaXMgbm90IHNldAojIENPTkZJR19DUllQVE9fTlVMTCBp
cyBub3Qgc2V0CiMgQ09ORklHX0NSWVBUT19QQ1JZUFQgaXMgbm90IHNldApDT05GSUdfQ1JZUFRP
X1dPUktRVUVVRT15CiMgQ09ORklHX0NSWVBUT19DUllQVEQgaXMgbm90IHNldApDT05GSUdfQ1JZ
UFRPX0FVVEhFTkM9bQojIENPTkZJR19DUllQVE9fVEVTVCBpcyBub3Qgc2V0CgojCiMgQXV0aGVu
dGljYXRlZCBFbmNyeXB0aW9uIHdpdGggQXNzb2NpYXRlZCBEYXRhCiMKIyBDT05GSUdfQ1JZUFRP
X0NDTSBpcyBub3Qgc2V0CiMgQ09ORklHX0NSWVBUT19HQ00gaXMgbm90IHNldAojIENPTkZJR19D
UllQVE9fU0VRSVYgaXMgbm90IHNldAoKIwojIEJsb2NrIG1vZGVzCiMKQ09ORklHX0NSWVBUT19D
QkM9bQojIENPTkZJR19DUllQVE9fQ1RSIGlzIG5vdCBzZXQKIyBDT05GSUdfQ1JZUFRPX0NUUyBp
cyBub3Qgc2V0CkNPTkZJR19DUllQVE9fRUNCPW0KIyBDT05GSUdfQ1JZUFRPX0xSVyBpcyBub3Qg
c2V0CiMgQ09ORklHX0NSWVBUT19QQ0JDIGlzIG5vdCBzZXQKIyBDT05GSUdfQ1JZUFRPX1hUUyBp
cyBub3Qgc2V0CgojCiMgSGFzaCBtb2RlcwojCkNPTkZJR19DUllQVE9fSE1BQz15CiMgQ09ORklH
X0NSWVBUT19YQ0JDIGlzIG5vdCBzZXQKIyBDT05GSUdfQ1JZUFRPX1ZNQUMgaXMgbm90IHNldAoK
IwojIERpZ2VzdAojCkNPTkZJR19DUllQVE9fQ1JDMzJDPXkKIyBDT05GSUdfQ1JZUFRPX0NSQzMy
Q19JTlRFTCBpcyBub3Qgc2V0CiMgQ09ORklHX0NSWVBUT19HSEFTSCBpcyBub3Qgc2V0CkNPTkZJ
R19DUllQVE9fTUQ0PW0KQ09ORklHX0NSWVBUT19NRDU9eQojIENPTkZJR19DUllQVE9fTUlDSEFF
TF9NSUMgaXMgbm90IHNldAojIENPTkZJR19DUllQVE9fUk1EMTI4IGlzIG5vdCBzZXQKIyBDT05G
SUdfQ1JZUFRPX1JNRDE2MCBpcyBub3Qgc2V0CiMgQ09ORklHX0NSWVBUT19STUQyNTYgaXMgbm90
IHNldAojIENPTkZJR19DUllQVE9fUk1EMzIwIGlzIG5vdCBzZXQKQ09ORklHX0NSWVBUT19TSEEx
PW0KIyBDT05GSUdfQ1JZUFRPX1NIQTI1NiBpcyBub3Qgc2V0CiMgQ09ORklHX0NSWVBUT19TSEE1
MTIgaXMgbm90IHNldAojIENPTkZJR19DUllQVE9fVEdSMTkyIGlzIG5vdCBzZXQKIyBDT05GSUdf
Q1JZUFRPX1dQNTEyIGlzIG5vdCBzZXQKCiMKIyBDaXBoZXJzCiMKQ09ORklHX0NSWVBUT19BRVM9
bQojIENPTkZJR19DUllQVE9fQUVTXzU4NiBpcyBub3Qgc2V0CiMgQ09ORklHX0NSWVBUT19BRVNf
TklfSU5URUwgaXMgbm90IHNldAojIENPTkZJR19DUllQVE9fQU5VQklTIGlzIG5vdCBzZXQKQ09O
RklHX0NSWVBUT19BUkM0PW0KIyBDT05GSUdfQ1JZUFRPX0JMT1dGSVNIIGlzIG5vdCBzZXQKIyBD
T05GSUdfQ1JZUFRPX0NBTUVMTElBIGlzIG5vdCBzZXQKIyBDT05GSUdfQ1JZUFRPX0NBU1Q1IGlz
IG5vdCBzZXQKIyBDT05GSUdfQ1JZUFRPX0NBU1Q2IGlzIG5vdCBzZXQKQ09ORklHX0NSWVBUT19E
RVM9bQojIENPTkZJR19DUllQVE9fRkNSWVBUIGlzIG5vdCBzZXQKIyBDT05GSUdfQ1JZUFRPX0tI
QVpBRCBpcyBub3Qgc2V0CiMgQ09ORklHX0NSWVBUT19TQUxTQTIwIGlzIG5vdCBzZXQKIyBDT05G
SUdfQ1JZUFRPX1NBTFNBMjBfNTg2IGlzIG5vdCBzZXQKIyBDT05GSUdfQ1JZUFRPX1NFRUQgaXMg
bm90IHNldAojIENPTkZJR19DUllQVE9fU0VSUEVOVCBpcyBub3Qgc2V0CiMgQ09ORklHX0NSWVBU
T19URUEgaXMgbm90IHNldAojIENPTkZJR19DUllQVE9fVFdPRklTSCBpcyBub3Qgc2V0CiMgQ09O
RklHX0NSWVBUT19UV09GSVNIXzU4NiBpcyBub3Qgc2V0CgojCiMgQ29tcHJlc3Npb24KIwpDT05G
SUdfQ1JZUFRPX0RFRkxBVEU9bQojIENPTkZJR19DUllQVE9fWkxJQiBpcyBub3Qgc2V0CiMgQ09O
RklHX0NSWVBUT19MWk8gaXMgbm90IHNldAoKIwojIFJhbmRvbSBOdW1iZXIgR2VuZXJhdGlvbgoj
CkNPTkZJR19DUllQVE9fQU5TSV9DUFJORz1tCiMgQ09ORklHX0NSWVBUT19VU0VSX0FQSV9IQVNI
IGlzIG5vdCBzZXQKIyBDT05GSUdfQ1JZUFRPX1VTRVJfQVBJX1NLQ0lQSEVSIGlzIG5vdCBzZXQK
Q09ORklHX0NSWVBUT19IVz15CiMgQ09ORklHX0NSWVBUT19ERVZfUEFETE9DSyBpcyBub3Qgc2V0
CiMgQ09ORklHX0NSWVBUT19ERVZfR0VPREUgaXMgbm90IHNldAojIENPTkZJR19DUllQVE9fREVW
X0hJRk5fNzk1WCBpcyBub3Qgc2V0CkNPTkZJR19IQVZFX0tWTT15CiMgQ09ORklHX1ZJUlRVQUxJ
WkFUSU9OIGlzIG5vdCBzZXQKIyBDT05GSUdfQklOQVJZX1BSSU5URiBpcyBub3Qgc2V0CgojCiMg
TGlicmFyeSByb3V0aW5lcwojCkNPTkZJR19SQUlENl9QUT1tCkNPTkZJR19CSVRSRVZFUlNFPXkK
Q09ORklHX0dFTkVSSUNfRklORF9GSVJTVF9CSVQ9eQpDT05GSUdfQ1JDX0NDSVRUPW0KQ09ORklH
X0NSQzE2PW0KIyBDT05GSUdfQ1JDX1QxMERJRiBpcyBub3Qgc2V0CkNPTkZJR19DUkNfSVRVX1Q9
bQpDT05GSUdfQ1JDMzI9eQojIENPTkZJR19DUkM3IGlzIG5vdCBzZXQKQ09ORklHX0xJQkNSQzMy
Qz15CkNPTkZJR19aTElCX0lORkxBVEU9eQpDT05GSUdfWkxJQl9ERUZMQVRFPW0KQ09ORklHX1ha
X0RFQz15CkNPTkZJR19YWl9ERUNfWDg2PXkKQ09ORklHX1haX0RFQ19QT1dFUlBDPXkKQ09ORklH
X1haX0RFQ19JQTY0PXkKQ09ORklHX1haX0RFQ19BUk09eQpDT05GSUdfWFpfREVDX0FSTVRIVU1C
PXkKQ09ORklHX1haX0RFQ19TUEFSQz15CkNPTkZJR19YWl9ERUNfQkNKPXkKIyBDT05GSUdfWFpf
REVDX1RFU1QgaXMgbm90IHNldApDT05GSUdfREVDT01QUkVTU19HWklQPXkKQ09ORklHX0RFQ09N
UFJFU1NfQlpJUDI9eQpDT05GSUdfVEVYVFNFQVJDSD15CkNPTkZJR19URVhUU0VBUkNIX0tNUD1t
CkNPTkZJR19URVhUU0VBUkNIX0JNPW0KQ09ORklHX1RFWFRTRUFSQ0hfRlNNPW0KQ09ORklHX0hB
U19JT01FTT15CkNPTkZJR19IQVNfSU9QT1JUPXkKQ09ORklHX0hBU19ETUE9eQpDT05GSUdfQ0hF
Q0tfU0lHTkFUVVJFPXkKQ09ORklHX0NQVV9STUFQPXkKQ09ORklHX05MQVRUUj15CiMgQ09ORklH
X0FWRVJBR0UgaXMgbm90IHNldAo=

--_005_3E243B26F475504B9BB0BCC9728B0DA629E16E01USILMS110Acacom_
Content-Type: application/octet-stream; name="messages"
Content-Description: messages
Content-Disposition: attachment; filename="messages"; size=45246;
	creation-date="Fri, 09 Dec 2011 20:00:35 GMT";
	modification-date="Fri, 09 Dec 2011 19:59:15 GMT"
Content-Transfer-Encoding: base64

RGVjICAxIDA0OjAyOjAxIEdyaWRvc19Ob2RlIHN5c2xvZ2QgMS40LjE6IHJlc3RhcnQuCkRlYyAg
MSAwNDowMjowMSBHcmlkb3NfTm9kZSBsb2dyb3RhdGU6IEFMRVJUIGV4aXRlZCBhYm5vcm1hbGx5
IHdpdGggWzFdCkRlYyAgMSAxNTo0NDowNSBHcmlkb3NfTm9kZSBzaHV0ZG93blsyMjkyNV06IHNo
dXR0aW5nIGRvd24gZm9yIHN5c3RlbSByZWJvb3QKRGVjICAxIDE1OjQ0OjA1IEdyaWRvc19Ob2Rl
IGluaXQ6IFN3aXRjaGluZyB0byBydW5sZXZlbDogNgpEZWMgIDEgMTU6NDQ6MDYgR3JpZG9zX05v
ZGUgc21hcnRkWzIwNjJdOiBzbWFydGQgcmVjZWl2ZWQgc2lnbmFsIDE1OiBUZXJtaW5hdGVkIApE
ZWMgIDEgMTU6NDQ6MDYgR3JpZG9zX05vZGUgc21hcnRkWzIwNjJdOiBzbWFydGQgaXMgZXhpdGlu
ZyAoZXhpdCBzdGF0dXMgMCkgCkRlYyAgMSAxNTo0NDowNyBHcmlkb3NfTm9kZSBrZXJuZWw6IEtl
cm5lbCBsb2dnaW5nIChwcm9jKSBzdG9wcGVkLgpEZWMgIDEgMTU6NDQ6MDcgR3JpZG9zX05vZGUg
a2VybmVsOiBLZXJuZWwgbG9nIGRhZW1vbiB0ZXJtaW5hdGluZy4KRGVjICAxIDE1OjQ0OjA4IEdy
aWRvc19Ob2RlIGV4aXRpbmcgb24gc2lnbmFsIDE1CkRlYyAgMSAxNTo1NToxNyBHcmlkb3NfTm9k
ZSBzeXNsb2dkIDEuNC4xOiByZXN0YXJ0LgpEZWMgIDEgMTU6NTU6MTcgR3JpZG9zX05vZGUga2Vy
bmVsOiBrbG9nZCAxLjQuMSwgbG9nIHNvdXJjZSA9IC9wcm9jL2ttc2cgc3RhcnRlZC4KRGVjICAx
IDE1OjU1OjE3IEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgICAwLjAwMDAwMF0gUmVzZXJ2aW5nIHZp
cnR1YWwgYWRkcmVzcyBzcGFjZSBhYm92ZSAweGZmODAwMDAwCkRlYyAgMSAxNTo1NToxNyBHcmlk
b3NfTm9kZSBrZXJuZWw6IFsgICAgMC4wMDAwMDBdIExpbnV4IHZlcnNpb24gMy4wLjQtMzMueGVu
MCAocm9vdEBudC1kZXYtQ2VudDU1LTMyKSAoZ2NjIHZlcnNpb24gNC4xLjIgMjAwODA3MDQgKFJl
ZCBIYXQgNC4xLjItNDgpKSAjMSBTTVAgTW9uIE5vdiAyMSAxODo0Njo1MCBFU1QgMjAxMQpEZWMg
IDEgMTU6NTU6MTcgR3JpZG9zX05vZGUga2VybmVsOiBbICAgIDAuMDAwMDAwXSByZWxlYXNlZCAw
IHBhZ2VzIG9mIHVudXNlZCBtZW1vcnkKRGVjICAxIDE1OjU1OjE3IEdyaWRvc19Ob2RlIGtlcm5l
bDogWyAgICAwLjAwMDAwMF0gU2V0IDI2MjMwNCBwYWdlKHMpIHRvIDEtMSBtYXBwaW5nLgpEZWMg
IDEgMTU6NTU6MTcgR3JpZG9zX05vZGUga2VybmVsOiBbICAgIDAuMDAwMDAwXSBCSU9TLXByb3Zp
ZGVkIHBoeXNpY2FsIFJBTSBtYXA6CkRlYyAgMSAxNTo1NToxNyBHcmlkb3NfTm9kZSBrZXJuZWw6
IFsgICAgMC4wMDAwMDBdICBYZW46IDAwMDAwMDAwMDAwMDAwMDAgLSAwMDAwMDAwMDAwMGEwMDAw
ICh1c2FibGUpCkRlYyAgMSAxNTo1NToxNyBHcmlkb3NfTm9kZSBrZXJuZWw6IFsgICAgMC4wMDAw
MDBdICBYZW46IDAwMDAwMDAwMDAwYTAwMDAgLSAwMDAwMDAwMDAwMTAwMDAwIChyZXNlcnZlZCkK
RGVjICAxIDE1OjU1OjE3IEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgICAwLjAwMDAwMF0gIFhlbjog
MDAwMDAwMDAwMDEwMDAwMCAtIDAwMDAwMDAwMjAwMDAwMDAgKHVzYWJsZSkKRGVjICAxIDE1OjU1
OjE3IEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgICAwLjAwMDAwMF0gIFhlbjogMDAwMDAwMDAyMDAw
MDAwMCAtIDAwMDAwMDAwYmZmYzAwMDAgKHVudXNhYmxlKQpEZWMgIDEgMTU6NTU6MTcgR3JpZG9z
X05vZGUga2VybmVsOiBbICAgIDAuMDAwMDAwXSAgWGVuOiAwMDAwMDAwMGJmZmMwMDAwIC0gMDAw
MDAwMDBiZmZjZmMwMCAoQUNQSSBkYXRhKQpEZWMgIDEgMTU6NTU6MTcgR3JpZG9zX05vZGUga2Vy
bmVsOiBbICAgIDAuMDAwMDAwXSAgWGVuOiAwMDAwMDAwMGJmZmNmYzAwIC0gMDAwMDAwMDBiZmZm
ZjAwMCAocmVzZXJ2ZWQpCkRlYyAgMSAxNTo1NToxNyBHcmlkb3NfTm9kZSBrZXJuZWw6IFsgICAg
MC4wMDAwMDBdICBYZW46IDAwMDAwMDAwZTAwMDAwMDAgLSAwMDAwMDAwMGZlYzkwMDAwIChyZXNl
cnZlZCkKRGVjICAxIDE1OjU1OjE3IEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgICAwLjAwMDAwMF0g
IFhlbjogMDAwMDAwMDBmZWQwMDAwMCAtIDAwMDAwMDAwZmVkMDA0MDAgKHJlc2VydmVkKQpEZWMg
IDEgMTU6NTU6MTcgR3JpZG9zX05vZGUga2VybmVsOiBbICAgIDAuMDAwMDAwXSAgWGVuOiAwMDAw
MDAwMGZlZTAwMDAwIC0gMDAwMDAwMDBmZWUxMDAwMCAocmVzZXJ2ZWQpCkRlYyAgMSAxNTo1NTox
NyBHcmlkb3NfTm9kZSBrZXJuZWw6IFsgICAgMC4wMDAwMDBdICBYZW46IDAwMDAwMDAwZmZiMDAw
MDAgLSAwMDAwMDAwMTAwMDAwMDAwIChyZXNlcnZlZCkKRGVjICAxIDE1OjU1OjE3IEdyaWRvc19O
b2RlIGtlcm5lbDogWyAgICAwLjAwMDAwMF0gIFhlbjogMDAwMDAwMDEwMDAwMDAwMCAtIDAwMDAw
MDAxZGZmYzAwMDAgKHVzYWJsZSkKRGVjICAxIDE1OjU1OjE3IEdyaWRvc19Ob2RlIGtlcm5lbDog
WyAgICAwLjAwMDAwMF0gTlggKEV4ZWN1dGUgRGlzYWJsZSkgcHJvdGVjdGlvbjogYWN0aXZlCkRl
YyAgMSAxNTo1NToxNyBHcmlkb3NfTm9kZSBrZXJuZWw6IFsgICAgMC4wMDAwMDBdIERNSSAyLjMg
cHJlc2VudC4KRGVjICAxIDE1OjU1OjE3IEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgICAwLjAwMDAw
MF0gbGFzdF9wZm4gPSAweDFkZmZjMCBtYXhfYXJjaF9wZm4gPSAweDEwMDAwMDAKRGVjICAxIDE1
OjU1OjE3IEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgICAwLjAwMDAwMF0gZm91bmQgU01QIE1QLXRh
YmxlIGF0IFtjMDBmZTcxMF0gZmU3MTAKRGVjICAxIDE1OjU1OjE3IEdyaWRvc19Ob2RlIGtlcm5l
bDogWyAgICAwLjAwMDAwMF0gaW5pdF9tZW1vcnlfbWFwcGluZzogMDAwMDAwMDAwMDAwMDAwMC0w
MDAwMDAwMDM3M2ZlMDAwCkRlYyAgMSAxNTo1NToxNyBHcmlkb3NfTm9kZSBrZXJuZWw6IFsgICAg
MC4wMDAwMDBdIFJBTURJU0s6IDAxNjY3MDAwIC0gMDFhMWUwMDAKRGVjICAxIDE1OjU1OjE3IEdy
aWRvc19Ob2RlIGtlcm5lbDogWyAgICAwLjAwMDAwMF0gQUNQSTogUlNEUCAwMDBmZDViMCAwMDAx
NCAodjAwIERFTEwgICkKRGVjICAxIDE1OjU1OjE3IEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgICAw
LjAwMDAwMF0gQUNQSTogUlNEVCAwMDBmZDVjNCAwMDAzOCAodjAxIERFTEwgICBQRSBCS0MgICAw
MDAwMDAwMSBNU0ZUIDAxMDAwMDBBKQpEZWMgIDEgMTU6NTU6MTcgR3JpZG9zX05vZGUga2VybmVs
OiBbICAgIDAuMDAwMDAwXSBBQ1BJOiBGQUNQIDAwMGZkNjIwIDAwMDc0ICh2MDEgREVMTCAgIFBF
IEJLQyAgIDAwMDAwMDAxIE1TRlQgMDEwMDAwMEEpCkRlYyAgMSAxNTo1NToxNyBHcmlkb3NfTm9k
ZSBrZXJuZWw6IFsgICAgMC4wMDAwMDBdIEFDUEk6IERTRFQgYmZmYzAwMDAgMDNDQ0QgKHYwMSBE
RUxMICAgUEUgQktDICAgMDAwMDAwMDEgTVNGVCAwMTAwMDAwRSkKRGVjICAxIDE1OjU1OjE3IEdy
aWRvc19Ob2RlIGtlcm5lbDogWyAgICAwLjAwMDAwMF0gQUNQSTogRkFDUyBiZmZjZmMwMCAwMDA0
MApEZWMgIDEgMTU6NTU6MTcgR3JpZG9zX05vZGUga2VybmVsOiBbICAgIDAuMDAwMDAwXSBBQ1BJ
OiBBUElDIDAwMGZkNjk0IDAwMEQ0ICh2MDEgREVMTCAgIFBFIEJLQyAgIDAwMDAwMDAxIE1TRlQg
MDEwMDAwMEEpCkRlYyAgMSAxNTo1NToxNyBHcmlkb3NfTm9kZSBrZXJuZWw6IFsgICAgMC4wMDAw
MDBdIEFDUEk6IFNQQ1IgMDAwZmQ3NzQgMDAwNTAgKHYwMSBERUxMICAgUEUgQktDICAgMDAwMDAw
MDEgTVNGVCAwMTAwMDAwQSkKRGVjICAxIDE1OjU1OjE3IEdyaWRvc19Ob2RlIGtlcm5lbDogWyAg
ICAwLjAwMDAwMF0gQUNQSTogSFBFVCAwMDBmZDdjNCAwMDAzOCAodjAxIERFTEwgICBQRSBCS0Mg
ICAwMDAwMDAwMSBNU0ZUIDAxMDAwMDBBKQpEZWMgIDEgMTU6NTU6MTcgR3JpZG9zX05vZGUga2Vy
bmVsOiBbICAgIDAuMDAwMDAwXSBBQ1BJOiBNQ0ZHIDAwMGZkN2ZjIDAwMDNDICh2MDEgREVMTCAg
IFBFIEJLQyAgIDAwMDAwMDAxIE1TRlQgMDEwMDAwMEEpCkRlYyAgMSAxNTo1NToxNyBHcmlkb3Nf
Tm9kZSBrZXJuZWw6IFsgICAgMC4wMDAwMDBdIDY3OTVNQiBISUdITUVNIGF2YWlsYWJsZS4KRGVj
ICAxIDE1OjU1OjE3IEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgICAwLjAwMDAwMF0gODgzTUIgTE9X
TUVNIGF2YWlsYWJsZS4KRGVjICAxIDE1OjU1OjE3IEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgICAw
LjAwMDAwMF0gICBtYXBwZWQgbG93IHJhbTogMCAtIDM3M2ZlMDAwCkRlYyAgMSAxNTo1NToxNyBH
cmlkb3NfTm9kZSBrZXJuZWw6IFsgICAgMC4wMDAwMDBdICAgbG93IHJhbTogMCAtIDM3M2ZlMDAw
CkRlYyAgMSAxNTo1NToxNyBHcmlkb3NfTm9kZSBrZXJuZWw6IFsgICAgMC4wMDAwMDBdIFpvbmUg
UEZOIHJhbmdlczoKRGVjICAxIDE1OjU1OjE3IEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgICAwLjAw
MDAwMF0gICBETUEgICAgICAweDAwMDAwMDEwIC0+IDB4MDAwMDEwMDAKRGVjICAxIDE1OjU1OjE3
IEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgICAwLjAwMDAwMF0gICBOb3JtYWwgICAweDAwMDAxMDAw
IC0+IDB4MDAwMzczZmUKRGVjICAxIDE1OjU1OjE3IEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgICAw
LjAwMDAwMF0gICBIaWdoTWVtICAweDAwMDM3M2ZlIC0+IDB4MDAxZGZmYzAKRGVjICAxIDE1OjU1
OjE3IEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgICAwLjAwMDAwMF0gTW92YWJsZSB6b25lIHN0YXJ0
IFBGTiBmb3IgZWFjaCBub2RlCkRlYyAgMSAxNTo1NToxNyBHcmlkb3NfTm9kZSBrZXJuZWw6IFsg
ICAgMC4wMDAwMDBdIGVhcmx5X25vZGVfbWFwWzNdIGFjdGl2ZSBQRk4gcmFuZ2VzCkRlYyAgMSAx
NTo1NToxNyBHcmlkb3NfTm9kZSBrZXJuZWw6IFsgICAgMC4wMDAwMDBdICAgICAwOiAweDAwMDAw
MDEwIC0+IDB4MDAwMDAwYTAKRGVjICAxIDE1OjU1OjE3IEdyaWRvc19Ob2RlIGtlcm5lbDogWyAg
ICAwLjAwMDAwMF0gICAgIDA6IDB4MDAwMDAxMDAgLT4gMHgwMDAyMDAwMApEZWMgIDEgMTU6NTU6
MTcgR3JpZG9zX05vZGUga2VybmVsOiBbICAgIDAuMDAwMDAwXSAgICAgMDogMHgwMDEwMDAwMCAt
PiAweDAwMWRmZmMwCkRlYyAgMSAxNTo1NToxOCBHcmlkb3NfTm9kZSBrZXJuZWw6IFsgICAgMC4w
MDAwMDBdIFVzaW5nIEFQSUMgZHJpdmVyIGRlZmF1bHQKRGVjICAxIDE1OjU1OjE4IEdyaWRvc19O
b2RlIGtlcm5lbDogWyAgICAwLjAwMDAwMF0gQUNQSTogUE0tVGltZXIgSU8gUG9ydDogMHg4MDgK
RGVjICAxIDE1OjU1OjE4IEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgICAwLjAwMDAwMF0gQUNQSTog
TEFQSUMgKGFjcGlfaWRbMHgwMV0gbGFwaWNfaWRbMHgwMF0gZW5hYmxlZCkKRGVjICAxIDE1OjU1
OjE4IEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgICAwLjAwMDAwMF0gQklPUyBidWc6IEFQSUMgdmVy
c2lvbiBpcyAwIGZvciBDUFUgMC8weDAsIGZpeGluZyB1cCB0byAweDEwCkRlYyAgMSAxNTo1NTox
OCBHcmlkb3NfTm9kZSBrZXJuZWw6IFsgICAgMC4wMDAwMDBdIEFDUEk6IExBUElDIChhY3BpX2lk
WzB4MDJdIGxhcGljX2lkWzB4MDZdIGVuYWJsZWQpCkRlYyAgMSAxNTo1NToxOCBHcmlkb3NfTm9k
ZSBrZXJuZWw6IFsgICAgMC4wMDAwMDBdIEFDUEk6IExBUElDIChhY3BpX2lkWzB4MDNdIGxhcGlj
X2lkWzB4MDFdIGVuYWJsZWQpCkRlYyAgMSAxNTo1NToxOCBHcmlkb3NfTm9kZSBrZXJuZWw6IFsg
ICAgMC4wMDAwMDBdIEFDUEk6IExBUElDIChhY3BpX2lkWzB4MDRdIGxhcGljX2lkWzB4MDddIGVu
YWJsZWQpCkRlYyAgMSAxNTo1NToxOCBHcmlkb3NfTm9kZSBrZXJuZWw6IFsgICAgMC4wMDAwMDBd
IEFDUEk6IExBUElDIChhY3BpX2lkWzB4MDVdIGxhcGljX2lkWzB4MDJdIGRpc2FibGVkKQpEZWMg
IDEgMTU6NTU6MTggR3JpZG9zX05vZGUga2VybmVsOiBbICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJ
QyAoYWNwaV9pZFsweDA2XSBsYXBpY19pZFsweDA0XSBkaXNhYmxlZCkKRGVjICAxIDE1OjU1OjE4
IEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgICAwLjAwMDAwMF0gQUNQSTogTEFQSUMgKGFjcGlfaWRb
MHgwN10gbGFwaWNfaWRbMHgwM10gZGlzYWJsZWQpCkRlYyAgMSAxNTo1NToxOCBHcmlkb3NfTm9k
ZSBrZXJuZWw6IFsgICAgMC4wMDAwMDBdIEFDUEk6IExBUElDIChhY3BpX2lkWzB4MDhdIGxhcGlj
X2lkWzB4MDVdIGRpc2FibGVkKQpEZWMgIDEgMTU6NTU6MTggR3JpZG9zX05vZGUga2VybmVsOiBb
ICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJQ19OTUkgKGFjcGlfaWRbMHgwMV0gaGlnaCBlZGdlIGxp
bnRbMHgxXSkKRGVjICAxIDE1OjU1OjE4IEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgICAwLjAwMDAw
MF0gQUNQSTogTEFQSUNfTk1JIChhY3BpX2lkWzB4MDJdIGhpZ2ggZWRnZSBsaW50WzB4MV0pCkRl
YyAgMSAxNTo1NToxOCBHcmlkb3NfTm9kZSBrZXJuZWw6IFsgICAgMC4wMDAwMDBdIEFDUEk6IExB
UElDX05NSSAoYWNwaV9pZFsweDAzXSBoaWdoIGVkZ2UgbGludFsweDFdKQpEZWMgIDEgMTU6NTU6
MTggR3JpZG9zX05vZGUga2VybmVsOiBbICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJQ19OTUkgKGFj
cGlfaWRbMHgwNF0gaGlnaCBlZGdlIGxpbnRbMHgxXSkKRGVjICAxIDE1OjU1OjE4IEdyaWRvc19O
b2RlIGtlcm5lbDogWyAgICAwLjAwMDAwMF0gQUNQSTogTEFQSUNfTk1JIChhY3BpX2lkWzB4MDVd
IGhpZ2ggZWRnZSBsaW50WzB4MV0pCkRlYyAgMSAxNTo1NToxOCBHcmlkb3NfTm9kZSBrZXJuZWw6
IFsgICAgMC4wMDAwMDBdIEFDUEk6IExBUElDX05NSSAoYWNwaV9pZFsweDA2XSBoaWdoIGVkZ2Ug
bGludFsweDFdKQpEZWMgIDEgMTU6NTU6MTggR3JpZG9zX05vZGUga2VybmVsOiBbICAgIDAuMDAw
MDAwXSBBQ1BJOiBMQVBJQ19OTUkgKGFjcGlfaWRbMHgwN10gaGlnaCBlZGdlIGxpbnRbMHgxXSkK
RGVjICAxIDE1OjU1OjE4IEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgICAwLjAwMDAwMF0gQUNQSTog
TEFQSUNfTk1JIChhY3BpX2lkWzB4MDhdIGhpZ2ggZWRnZSBsaW50WzB4MV0pCkRlYyAgMSAxNTo1
NToxOCBHcmlkb3NfTm9kZSBrZXJuZWw6IFsgICAgMC4wMDAwMDBdIEFDUEk6IElPQVBJQyAoaWRb
MHgwOF0gYWRkcmVzc1sweGZlYzAwMDAwXSBnc2lfYmFzZVswXSkKRGVjICAxIDE1OjU1OjE4IEdy
aWRvc19Ob2RlIGtlcm5lbDogWyAgICAwLjAwMDAwMF0gSU9BUElDWzBdOiBhcGljX2lkIDgsIHZl
cnNpb24gMjU1LCBhZGRyZXNzIDB4ZmVjMDAwMDAsIEdTSSAwLTI1NQpEZWMgIDEgMTU6NTU6MTgg
R3JpZG9zX05vZGUga2VybmVsOiBbICAgIDAuMDAwMDAwXSBBQ1BJOiBJT0FQSUMgKGlkWzB4MDld
IGFkZHJlc3NbMHhmZWM4MDAwMF0gZ3NpX2Jhc2VbMzJdKQpEZWMgIDEgMTU6NTU6MTggR3JpZG9z
X05vZGUga2VybmVsOiBbICAgIDAuMDAwMDAwXSBJT0FQSUNbMV06IGFwaWNfaWQgOSwgdmVyc2lv
biAyNTUsIGFkZHJlc3MgMHhmZWM4MDAwMCwgR1NJIDMyLTI4NwpEZWMgIDEgMTU6NTU6MTggR3Jp
ZG9zX05vZGUgYWlzZXhlYzogW01BSU4gXSBBSVMgRXhlY3V0aXZlIFNlcnZpY2UgUkVMRUFTRSAn
c3VicmV2IDExNTIgdmVyc2lvbiAwLjgwJyAKRGVjICAxIDE1OjU1OjE4IEdyaWRvc19Ob2RlIGtl
cm5lbDogWyAgICAwLjAwMDAwMF0gQUNQSTogSU9BUElDIChpZFsweDBhXSBhZGRyZXNzWzB4ZmVj
ODMwMDBdIGdzaV9iYXNlWzY0XSkKRGVjICAxIDE1OjU1OjE4IEdyaWRvc19Ob2RlIGFpc2V4ZWM6
IFtNQUlOIF0gQ29weXJpZ2h0IChDKSAyMDAyLTIwMDYgTW9udGFWaXN0YSBTb2Z0d2FyZSwgSW5j
IGFuZCBjb250cmlidXRvcnMuIApEZWMgIDEgMTU6NTU6MTggR3JpZG9zX05vZGUga2VybmVsOiBb
ICAgIDAuMDAwMDAwXSBJT0FQSUNbMl06IGFwaWNfaWQgMTAsIHZlcnNpb24gMjU1LCBhZGRyZXNz
IDB4ZmVjODMwMDAsIEdTSSA2NC0zMTkKRGVjICAxIDE1OjU1OjE4IEdyaWRvc19Ob2RlIGFpc2V4
ZWM6IFtNQUlOIF0gQ29weXJpZ2h0IChDKSAyMDA2IFJlZCBIYXQsIEluYy4gCkRlYyAgMSAxNTo1
NToxOCBHcmlkb3NfTm9kZSBrZXJuZWw6IFsgICAgMC4wMDAwMDBdIEFDUEk6IElOVF9TUkNfT1ZS
IChidXMgMCBidXNfaXJxIDAgZ2xvYmFsX2lycSAyIGRmbCBkZmwpCkRlYyAgMSAxNTo1NToxOCBH
cmlkb3NfTm9kZSBhaXNleGVjOiBbTUFJTiBdIEFJUyBFeGVjdXRpdmUgU2VydmljZTogc3RhcnRl
ZCBhbmQgcmVhZHkgdG8gcHJvdmlkZSBzZXJ2aWNlLiAKRGVjICAxIDE1OjU1OjE4IEdyaWRvc19O
b2RlIGtlcm5lbDogWyAgICAwLjAwMDAwMF0gQUNQSTogSU5UX1NSQ19PVlIgKGJ1cyAwIGJ1c19p
cnEgOSBnbG9iYWxfaXJxIDkgaGlnaCBsZXZlbCkKRGVjICAxIDE1OjU1OjE4IEdyaWRvc19Ob2Rl
IGFpc2V4ZWM6IFtNQUlOIF0gcGFyc2UgZXJyb3IgaW4gY29uZmlnOiBObyBtdWx0aWNhc3QgcG9y
dCBzcGVjaWZpZWQgCkRlYyAgMSAxNTo1NToxOCBHcmlkb3NfTm9kZSBhaXNleGVjOiBbTUFJTiBd
IEFJUyBFeGVjdXRpdmUgZXhpdGluZyAocmVhc29uOiBjb3VsZCBub3QgcmVhZCB0aGUgbWFpbiBj
b25maWd1cmF0aW9uIGZpbGUpLiAKRGVjICAxIDE1OjU1OjE4IEdyaWRvc19Ob2RlIGtlcm5lbDog
WyAgICAwLjAwMDAwMF0gVXNpbmcgQUNQSSAoTUFEVCkgZm9yIFNNUCBjb25maWd1cmF0aW9uIGlu
Zm9ybWF0aW9uCkRlYyAgMSAxNTo1NToxOCBHcmlkb3NfTm9kZSBrZXJuZWw6IFsgICAgMC4wMDAw
MDBdIFNNUDogQWxsb3dpbmcgOCBDUFVzLCA0IGhvdHBsdWcgQ1BVcwpEZWMgIDEgMTU6NTU6MTgg
R3JpZG9zX05vZGUga2VybmVsOiBbICAgIDAuMDAwMDAwXSBBbGxvY2F0aW5nIFBDSSByZXNvdXJj
ZXMgc3RhcnRpbmcgYXQgYmZmZmYwMDAgKGdhcDogYmZmZmYwMDA6MjAwMDEwMDApCkRlYyAgMSAx
NTo1NToxOCBHcmlkb3NfTm9kZSBrZXJuZWw6IFsgICAgMC4wMDAwMDBdIEJvb3RpbmcgcGFyYXZp
cnR1YWxpemVkIGtlcm5lbCBvbiBYZW4KRGVjICAxIDE1OjU1OjE4IEdyaWRvc19Ob2RlIGtlcm5l
bDogWyAgICAwLjAwMDAwMF0gWGVuIHZlcnNpb246IDQuMS4xIChwcmVzZXJ2ZS1BRCkKRGVjICAx
IDE1OjU1OjE4IEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgICAwLjAwMDAwMF0gc2V0dXBfcGVyY3B1
OiBOUl9DUFVTOjggbnJfY3B1bWFza19iaXRzOjggbnJfY3B1X2lkczo4IG5yX25vZGVfaWRzOjEK
RGVjICAxIDE1OjU1OjE4IEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgICAwLjAwMDAwMF0gUEVSQ1BV
OiBFbWJlZGRlZCAxMiBwYWdlcy9jcHUgQGRjMzhkMDAwIHMyNjYyNCByMCBkMjI1MjggdTQ5MTUy
CkRlYyAgMSAxNTo1NToxOCBHcmlkb3NfTm9kZSBrZXJuZWw6IFsgICAgMC4wMDAwMDBdIEJ1aWx0
IDEgem9uZWxpc3RzIGluIFpvbmUgb3JkZXIsIG1vYmlsaXR5IGdyb3VwaW5nIG9uLiAgVG90YWwg
cGFnZXM6IDEwMzMwNDAKRGVjICAxIDE1OjU1OjE4IEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgICAw
LjAwMDAwMF0gS2VybmVsIGNvbW1hbmQgbGluZTogbm91c2Igcm9vdD1MQUJFTD0vbW50L2FwbGJv
b3QxIHNlbGludXg9MCAgbWF4X2xvb3A9MjU2IGlvbW11PW9mZgpEZWMgIDEgMTU6NTU6MTggR3Jp
ZG9zX05vZGUga2VybmVsOiBbICAgIDAuMDAwMDAwXSBQSUQgaGFzaCB0YWJsZSBlbnRyaWVzOiAy
MDQ4IChvcmRlcjogMSwgODE5MiBieXRlcykKRGVjICAxIDE1OjU1OjE4IEdyaWRvc19Ob2RlIGtl
cm5lbDogWyAgICAwLjAwMDAwMF0gRGVudHJ5IGNhY2hlIGhhc2ggdGFibGUgZW50cmllczogNjU1
MzYgKG9yZGVyOiA2LCAyNjIxNDQgYnl0ZXMpCkRlYyAgMSAxNTo1NToxOCBHcmlkb3NfTm9kZSBr
ZXJuZWw6IFsgICAgMC4wMDAwMDBdIElub2RlLWNhY2hlIGhhc2ggdGFibGUgZW50cmllczogMzI3
NjggKG9yZGVyOiA1LCAxMzEwNzIgYnl0ZXMpCkRlYyAgMSAxNTo1NToxOCBHcmlkb3NfTm9kZSBr
ZXJuZWw6IFsgICAgMC4wMDAwMDBdIEluaXRpYWxpemluZyBDUFUjMApEZWMgIDEgMTU6NTU6MTgg
R3JpZG9zX05vZGUga2VybmVsOiBbICAgIDAuMDAwMDAwXSBQbGFjaW5nIDY0TUIgc29mdHdhcmUg
SU8gVExCIGJldHdlZW4gZDgzMmNmMDAgLSBkYzMyY2YwMApEZWMgIDEgMTU6NTU6MTggR3JpZG9z
X05vZGUga2VybmVsOiBbICAgIDAuMDAwMDAwXSBzb2Z0d2FyZSBJTyBUTEIgYXQgcGh5cyAweDE4
MzJjZjAwIC0gMHgxYzMyY2YwMApEZWMgIDEgMTU6NTU6MTggR3JpZG9zX05vZGUga2VybmVsOiBb
ICAgIDAuMDAwMDAwXSBJbml0aWFsaXppbmcgSGlnaE1lbSBmb3Igbm9kZSAwICgwMDAzNzNmZTow
MDFkZmZjMCkKRGVjICAxIDE1OjU1OjE4IEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgICAwLjAwMDAw
MF0gTWVtb3J5OiAzODUzOTZrLzc4NjQwNjRrIGF2YWlsYWJsZSAoMjM4M2sga2VybmVsIGNvZGUs
IDEzODQ0NGsgcmVzZXJ2ZWQsIDk2MmsgZGF0YSwgMzg0ayBpbml0LCAwayBoaWdobWVtKQpEZWMg
IDEgMTU6NTU6MTggR3JpZG9zX05vZGUga2VybmVsOiBbICAgIDAuMDAwMDAwXSB2aXJ0dWFsIGtl
cm5lbCBtZW1vcnkgbGF5b3V0OgpEZWMgIDEgMTU6NTU6MTggR3JpZG9zX05vZGUga2VybmVsOiBb
ICAgIDAuMDAwMDAwXSAgICAgZml4bWFwICA6IDB4ZmY3MTYwMDAgLSAweGZmN2ZmMDAwICAgKCA5
MzIga0IpCkRlYyAgMSAxNTo1NToxOCBHcmlkb3NfTm9kZSBrZXJuZWw6IFsgICAgMC4wMDAwMDBd
ICAgICBwa21hcCAgIDogMHhmZjQwMDAwMCAtIDB4ZmY2MDAwMDAgICAoMjA0OCBrQikKRGVjICAx
IDE1OjU1OjE4IEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgICAwLjAwMDAwMF0gICAgIHZtYWxsb2Mg
OiAweGY3YmZlMDAwIC0gMHhmZjNmZTAwMCAgICggMTIwIE1CKQpEZWMgIDEgMTU6NTU6MTkgR3Jp
ZG9zX05vZGUga2VybmVsOiBbICAgIDAuMDAwMDAwXSAgICAgbG93bWVtICA6IDB4YzAwMDAwMDAg
LSAweGY3M2ZlMDAwICAgKCA4ODMgTUIpCkRlYyAgMSAxNTo1NToxOSBHcmlkb3NfTm9kZSBrZXJu
ZWw6IFsgICAgMC4wMDAwMDBdICAgICAgIC5pbml0IDogMHhjMTM0NTAwMCAtIDB4YzEzYTUwMDAg
ICAoIDM4NCBrQikKRGVjICAxIDE1OjU1OjE5IEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgICAwLjAw
MDAwMF0gICAgICAgLmRhdGEgOiAweGMxMjUzZGE1IC0gMHhjMTM0NDkwMCAgICggOTYyIGtCKQpE
ZWMgIDEgMTU6NTU6MTkgR3JpZG9zX05vZGUga2VybmVsOiBbICAgIDAuMDAwMDAwXSAgICAgICAu
dGV4dCA6IDB4YzEwMDAwMDAgLSAweGMxMjUzZGE1ICAgKDIzODMga0IpCkRlYyAgMSAxNTo1NTox
OSBHcmlkb3NfTm9kZSBrZXJuZWw6IFsgICAgMC4wMDAwMDBdIEhpZXJhcmNoaWNhbCBSQ1UgaW1w
bGVtZW50YXRpb24uCkRlYyAgMSAxNTo1NToxOSBHcmlkb3NfTm9kZSBrZXJuZWw6IFsgICAgMC4w
MDAwMDBdIE5SX0lSUVM6NTEyCkRlYyAgMSAxNTo1NToxOSBHcmlkb3NfTm9kZSBrZXJuZWw6IFsg
ICAgMC4wMDAwMDBdIHhlbjogc2NpIG92ZXJyaWRlOiBnbG9iYWxfaXJxPTkgdHJpZ2dlcj0wIHBv
bGFyaXR5PTAKRGVjICAxIDE1OjU1OjE5IEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgICAwLjAwMDAw
MF0geGVuOiBhY3BpIHNjaSA5CkRlYyAgMSAxNTo1NToxOSBHcmlkb3NfTm9kZSBrZXJuZWw6IFsg
ICAgMC4wMDAwMDBdIHhlbl9tYXBfcGlycV9nc2k6IHJldHVybmluZyBpcnEgOSBmb3IgZ3NpIDkK
RGVjICAxIDE1OjU1OjE5IEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgICAwLjAwMDAwMF0gQ29uc29s
ZTogY29sb3VyIFZHQSsgODB4MjUKRGVjICAxIDE1OjU1OjE5IEdyaWRvc19Ob2RlIGtlcm5lbDog
WyAgICAwLjAwMDAwMF0gY29uc29sZSBbdHR5MF0gZW5hYmxlZApEZWMgIDEgMTU6NTU6MTkgR3Jp
ZG9zX05vZGUga2VybmVsOiBbICAgIDAuMDAwMDAwXSBpbnN0YWxsaW5nIFhlbiB0aW1lciBmb3Ig
Q1BVIDAKRGVjICAxIDE1OjU1OjE5IEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgICAwLjAwMDAwMF0g
RGV0ZWN0ZWQgMjk5Mi44MzYgTUh6IHByb2Nlc3Nvci4KRGVjICAxIDE1OjU1OjE5IEdyaWRvc19O
b2RlIGtlcm5lbDogWyAgICAwLjAxMDAwMF0gQ2FsaWJyYXRpbmcgZGVsYXkgbG9vcCAoc2tpcHBl
ZCksIHZhbHVlIGNhbGN1bGF0ZWQgdXNpbmcgdGltZXIgZnJlcXVlbmN5Li4gNTk4NS42NyBCb2dv
TUlQUyAobHBqPTI5OTI4MzYwKQpEZWMgIDEgMTU6NTU6MTkgR3JpZG9zX05vZGUga2VybmVsOiBb
ICAgIDAuMDEwMDAwXSBwaWRfbWF4OiBkZWZhdWx0OiAzMjc2OCBtaW5pbXVtOiAzMDEKRGVjICAx
IDE1OjU1OjE5IEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgICAwLjAxMDAwMF0gLS0tLS0tLS0tLS0t
WyBjdXQgaGVyZSBdLS0tLS0tLS0tLS0tCkRlYyAgMSAxNTo1NToxOSBHcmlkb3NfTm9kZSBrZXJu
ZWw6IFsgICAgMC4wMTAwMDBdIFdBUk5JTkc6IGF0IGFyY2gveDg2L3hlbi9tbXUuYzo0OTIgeGVu
X21ha2VfcHRlX2RlYnVnKzB4MTQ1LzB4MTg4KCkKRGVjICAxIDE1OjU1OjE5IEdyaWRvc19Ob2Rl
IGtlcm5lbDogWyAgICAwLjAxMDAwMF0gSGFyZHdhcmUgbmFtZTogUG93ZXJFZGdlIDE4NTAKRGVj
ICAxIDE1OjU1OjE5IEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgICAwLjAxMDAwMF0gMHgxN2MyYzAw
MCBpcyBtaXNzaW5nIFZNX0lPIChhbmQgd2Fzbid0IGZpeGVkKSEKRGVjICAxIDE1OjU1OjE5IEdy
aWRvc19Ob2RlIGtlcm5lbDogWyAgICAwLjAxMDAwMF0gTW9kdWxlcyBsaW5rZWQgaW46CkRlYyAg
MSAxNTo1NToxOSBHcmlkb3NfTm9kZSBrZXJuZWw6IFsgICAgMC4wMTAwMDBdIFBpZDogMCwgY29t
bTogc3dhcHBlciBOb3QgdGFpbnRlZCAzLjAuNC0zMy54ZW4wICMxCkRlYyAgMSAxNTo1NToxOSBH
cmlkb3NfTm9kZSBrZXJuZWw6IFsgICAgMC4wMTAwMDBdIENhbGwgVHJhY2U6CkRlYyAgMSAxNTo1
NToxOSBHcmlkb3NfTm9kZSBrZXJuZWw6IFsgICAgMC4wMTAwMDBdICBbPGMxMDA1NGU4Pl0gPyB4
ZW5fbWFrZV9wdGVfZGVidWcrMHgxNDUvMHgxODgKRGVjICAxIDE1OjU1OjE5IEdyaWRvc19Ob2Rl
IGtlcm5lbDogWyAgICAwLjAxMDAwMF0gIFs8YzEwMzQwMzA+XSB3YXJuX3Nsb3dwYXRoX2NvbW1v
bisweDc2LzB4OGIKRGVjICAxIDE1OjU1OjE5IEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgICAwLjAx
MDAwMF0gIFs8YzEwMDU0ZTg+XSA/IHhlbl9tYWtlX3B0ZV9kZWJ1ZysweDE0NS8weDE4OApEZWMg
IDEgMTU6NTU6MTkgR3JpZG9zX05vZGUga2VybmVsOiBbICAgIDAuMDEwMDAwXSAgWzxjMTAzNDBj
MT5dIHdhcm5fc2xvd3BhdGhfZm10KzB4MmUvMHgzMApEZWMgIDEgMTU6NTU6MTkgR3JpZG9zX05v
ZGUga2VybmVsOiBbICAgIDAuMDEwMDAwXSAgWzxjMTAwNTRlOD5dIHhlbl9tYWtlX3B0ZV9kZWJ1
ZysweDE0NS8weDE4OApEZWMgIDEgMTU6NTU6MTkgR3JpZG9zX05vZGUga2VybmVsOiBbICAgIDAu
MDEwMDAwXSAgWzxjMTAwMzY2ZT5dIF9fcmF3X2NhbGxlZV9zYXZlX3hlbl9tYWtlX3B0ZV9kZWJ1
ZysweDYvMHg4CkRlYyAgMSAxNTo1NToxOSBHcmlkb3NfTm9kZSBrZXJuZWw6IFsgICAgMC4wMTAw
MDBdICBbPGMxMDIzMmQxPl0gPyBfX2NoYW5nZV9wYWdlX2F0dHJfc2V0X2NscisweDlmNC8weGMy
ZQpEZWMgIDEgMTU6NTU6MTkgR3JpZG9zX05vZGUga2VybmVsOiBbICAgIDAuMDEwMDAwXSAgWzxj
MTAwNTk3Zj5dID8geGVuX2ZvcmNlX2V2dGNobl9jYWxsYmFjaysweGYvMHgxNApEZWMgIDEgMTU6
NTU6MTkgR3JpZG9zX05vZGUga2VybmVsOiBbICAgIDAuMDEwMDAwXSAgWzxjMTAwNTk3Zj5dID8g
eGVuX2ZvcmNlX2V2dGNobl9jYWxsYmFjaysweGYvMHgxNApEZWMgIDEgMTU6NTU6MTkgR3JpZG9z
X05vZGUga2VybmVsOiBbICAgIDAuMDEwMDAwXSAgWzxjMTAwNjBhMD5dID8gY2hlY2tfZXZlbnRz
KzB4OC8weGMKRGVjICAxIDE1OjU1OjE5IEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgICAwLjAxMDAw
MF0gIFs8YzEwMDYwOTc+XSA/IHhlbl9yZXN0b3JlX2ZsX2RpcmVjdF9yZWxvYysweDQvMHg0CkRl
YyAgMSAxNTo1NToxOSBHcmlkb3NfTm9kZSBrZXJuZWw6IFsgICAgMC4wMTAwMDBdICBbPGMxMDA0
MzRjPl0gPyB4ZW5fZmx1c2hfdGxiKzB4NWYvMHg2YwpEZWMgIDEgMTU6NTU6MTkgR3JpZG9zX05v
ZGUga2VybmVsOiBbICAgIDAuMDEwMDAwXSAgWzxjMTAyMzViNz5dID8ga2VybmVsX21hcF9wYWdl
cysweGFjLzB4MTA0CkRlYyAgMSAxNTo1NToxOSBHcmlkb3NfTm9kZSBrZXJuZWw6IFsgICAgMC4w
MTAwMDBdICBbPGMxMDcxNDhkPl0gPyBnZXRfcGFnZV9mcm9tX2ZyZWVsaXN0KzB4MjU1LzB4Mzlj
CkRlYyAgMSAxNTo1NToxOSBHcmlkb3NfTm9kZSBrZXJuZWw6IFsgICAgMC4wMTAwMDBdICBbPGMx
MDkyODJhPl0gPyBjaGVja19wb2lzb25fb2JqKzB4MjIvMHgxYWQKRGVjICAxIDE1OjU1OjE5IEdy
aWRvc19Ob2RlIGtlcm5lbDogWyAgICAwLjAxMDAwMF0gIFs8YzEwNzE3OWU+XSA/IF9fYWxsb2Nf
cGFnZXNfbm9kZW1hc2srMHhkOS8weDU2MQpEZWMgIDEgMTU6NTU6MTkgR3JpZG9zX05vZGUga2Vy
bmVsOiBbICAgIDAuMDEwMDAwXSAgWzxjMTA5MmI5ZD5dID8gcG9pc29uX29iaisweDMyLzB4M2YK
RGVjICAxIDE1OjU1OjE5IEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgICAwLjAxMDAwMF0gIFs8YzEw
OTI1NDM+XSA/IGRiZ19yZWR6b25lMSsweDExLzB4MWQKRGVjICAxIDE1OjU1OjE5IEdyaWRvc19O
b2RlIGtlcm5lbDogWyAgICAwLjAxMDAwMF0gIFs8YzEwMjM1Zjc+XSBrZXJuZWxfbWFwX3BhZ2Vz
KzB4ZWMvMHgxMDQKRGVjICAxIDE1OjU1OjE5IEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgICAwLjAx
MDAwMF0gIFs8YzEwOTNmYTM+XSBjYWNoZV9hbGxvY19yZWZpbGwrMHg2Y2QvMHg2ZDIKRGVjICAx
IDE1OjU1OjE5IEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgICAwLjAxMDAwMF0gIFs8YzEwOTQyYzg+
XSBrbWVtX2NhY2hlX2FsbG9jKzB4YzMvMHhjNwpEZWMgIDEgMTU6NTU6MTkgR3JpZG9zX05vZGUg
a2VybmVsOiBbICAgIDAuMDEwMDAwXSAgWzxjMTM1YjRiNT5dID8gcGlkbWFwX2luaXQrMHg3My8w
eGFkCkRlYyAgMSAxNTo1NToxOSBHcmlkb3NfTm9kZSBrZXJuZWw6IFsgICAgMC4wMTAwMDBdICBb
PGMxMzViNGI1Pl0gcGlkbWFwX2luaXQrMHg3My8weGFkCkRlYyAgMSAxNTo1NToxOSBHcmlkb3Nf
Tm9kZSBrZXJuZWw6IFsgICAgMC4wMTAwMDBdICBbPGMxMzQ1ODFlPl0gc3RhcnRfa2VybmVsKzB4
MjJmLzB4MzExCkRlYyAgMSAxNTo1NToxOSBHcmlkb3NfTm9kZSBrZXJuZWw6IFsgICAgMC4wMTAw
MDBdICBbPGMxMzQ1MjE3Pl0gPyBwYXJzZV9lYXJseV9vcHRpb25zKzB4MjUvMHgyNQpEZWMgIDEg
MTU6NTU6MTkgR3JpZG9zX05vZGUga2VybmVsOiBbICAgIDAuMDEwMDAwXSAgWzxjMTM0NTA4OT5d
IGkzODZfc3RhcnRfa2VybmVsKzB4NzgvMHhiZgpEZWMgIDEgMTU6NTU6MTkgR3JpZG9zX05vZGUg
a2VybmVsOiBbICAgIDAuMDEwMDAwXSAgWzxjMTM0N2I4MD5dIHhlbl9zdGFydF9rZXJuZWwrMHgz
ZTgvMHg0ZGQKRGVjICAxIDE1OjU1OjE5IEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgICAwLjAxMDAw
MF0gLS0tWyBlbmQgdHJhY2UgNGVhYTJhODZhOGUyZGEyMiBdLS0tCkRlYyAgMSAxNTo1NToyMCBH
cmlkb3NfTm9kZSBrZXJuZWw6IFsgICAgMC4wMTAwMDBdIE1vdW50LWNhY2hlIGhhc2ggdGFibGUg
ZW50cmllczogNTEyCkRlYyAgMSAxNTo1NToyMCBHcmlkb3NfTm9kZSBrZXJuZWw6IFsgICAgMC4w
MTAwMDBdIENQVTogUGh5c2ljYWwgUHJvY2Vzc29yIElEOiAwCkRlYyAgMSAxNTo1NToyMCBHcmlk
b3NfTm9kZSBrZXJuZWw6IFsgICAgMC4wMTAwMDBdIENQVTogUHJvY2Vzc29yIENvcmUgSUQ6IDAK
RGVjICAxIDE1OjU1OjIwIEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgICAwLjAxMDAwMF0gQUNQSTog
Q29yZSByZXZpc2lvbiAyMDExMDQxMwpEZWMgIDEgMTU6NTU6MjAgR3JpZG9zX05vZGUga2VybmVs
OiBbICAgIDAuMDI0NzUzXSBQZXJmb3JtYW5jZSBFdmVudHM6IHVuc3VwcG9ydGVkIE5ldGJ1cnN0
IENQVSBtb2RlbCA0IG5vIFBNVSBkcml2ZXIsIHNvZnR3YXJlIGV2ZW50cyBvbmx5LgpEZWMgIDEg
MTU6NTU6MjAgR3JpZG9zX05vZGUga2VybmVsOiBbICAgIDAuMDI4MTMzXSBpbnN0YWxsaW5nIFhl
biB0aW1lciBmb3IgQ1BVIDEKRGVjICAxIDE1OjU1OjIwIEdyaWRvc19Ob2RlIGtlcm5lbDogWyAg
ICAwLjAxMDAwMF0gSW5pdGlhbGl6aW5nIENQVSMxCkRlYyAgMSAxNTo1NToyMCBHcmlkb3NfTm9k
ZSBrZXJuZWw6IFsgICAgMC4wMzA1MjhdIGluc3RhbGxpbmcgWGVuIHRpbWVyIGZvciBDUFUgMgpE
ZWMgIDEgMTU6NTU6MjAgR3JpZG9zX05vZGUga2VybmVsOiBbICAgIDAuMDEwMDAwXSBJbml0aWFs
aXppbmcgQ1BVIzIKRGVjICAxIDE1OjU1OjIwIEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgICAwLjAz
Mjk1OF0gaW5zdGFsbGluZyBYZW4gdGltZXIgZm9yIENQVSAzCkRlYyAgMSAxNTo1NToyMCBHcmlk
b3NfTm9kZSBrZXJuZWw6IFsgICAgMC4wMTAwMDBdIEluaXRpYWxpemluZyBDUFUjMwpEZWMgIDEg
MTU6NTU6MjAgR3JpZG9zX05vZGUga2VybmVsOiBbICAgIDAuMDMzMjgxXSBCcm91Z2h0IHVwIDQg
Q1BVcwpEZWMgIDEgMTU6NTU6MjAgR3JpZG9zX05vZGUga2VybmVsOiBbICAgIDAuMDM5NTU5XSBH
cmFudCB0YWJsZSBpbml0aWFsaXplZApEZWMgIDEgMTU6NTU6MjAgR3JpZG9zX05vZGUga2VybmVs
OiBbICAgIDAuMDQwMDEzXSBORVQ6IFJlZ2lzdGVyZWQgcHJvdG9jb2wgZmFtaWx5IDE2CkRlYyAg
MSAxNTo1NToyMCBHcmlkb3NfTm9kZSBrZXJuZWw6IFsgICAgMC4wNDE0NDNdIEFDUEk6IGJ1cyB0
eXBlIHBjaSByZWdpc3RlcmVkCkRlYyAgMSAxNTo1NToyMCBHcmlkb3NfTm9kZSBrZXJuZWw6IFsg
ICAgMC4wNDE5NDhdIFBDSTogTU1DT05GSUcgZm9yIGRvbWFpbiAwMDAwIFtidXMgMDAtZmZdIGF0
IFttZW0gMHhlMDAwMDAwMC0weGVmZmZmZmZmXSAoYmFzZSAweGUwMDAwMDAwKQpEZWMgIDEgMTU6
NTU6MjAgR3JpZG9zX05vZGUga2VybmVsOiBbICAgIDAuMDQyMDYwXSBQQ0k6IEludGVsIENvcnBv
cmF0aW9uIEU3NTIwIE1lbW9yeSBDb250cm9sbGVyIEh1YiB3aXRoIE1NQ09ORklHIHN1cHBvcnQK
RGVjICAxIDE1OjU1OjIwIEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgICAwLjA0MjE4NV0gUENJOiBN
TUNPTkZJRyBhdCBbbWVtIDB4ZTAwMDAwMDAtMHhlZmZmZmZmZl0gcmVzZXJ2ZWQgaW4gRTgyMApE
ZWMgIDEgMTU6NTU6MjAgR3JpZG9zX05vZGUga2VybmVsOiBbICAgIDAuMDQyMjc4XSBQQ0k6IFVz
aW5nIE1NQ09ORklHIGZvciBleHRlbmRlZCBjb25maWcgc3BhY2UKRGVjICAxIDE1OjU1OjIwIEdy
aWRvc19Ob2RlIGtlcm5lbDogWyAgICAwLjA0MjM3MF0gUENJOiBVc2luZyBjb25maWd1cmF0aW9u
IHR5cGUgMSBmb3IgYmFzZSBhY2Nlc3MKRGVjICAxIDE1OjU1OjIwIEdyaWRvc19Ob2RlIGtlcm5l
bDogWyAgICAwLjA0OTI3Nl0gYmlvOiBjcmVhdGUgc2xhYiA8YmlvLTA+IGF0IDAKRGVjICAxIDE1
OjU1OjIwIEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgICAwLjA3ODczMl0gQUNQSTogSW50ZXJwcmV0
ZXIgZW5hYmxlZApEZWMgIDEgMTU6NTU6MjAgR3JpZG9zX05vZGUga2VybmVsOiBbICAgIDAuMDc4
ODI0XSBBQ1BJOiAoc3VwcG9ydHMgUzAgUzUpCkRlYyAgMSAxNTo1NToyMCBHcmlkb3NfTm9kZSBr
ZXJuZWw6IFsgICAgMC4wNzkxMDBdIEFDUEk6IFVzaW5nIElPQVBJQyBmb3IgaW50ZXJydXB0IHJv
dXRpbmcKRGVjICAxIDE1OjU1OjIwIEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgICAwLjEwNTA3NV0g
UENJOiBJZ25vcmluZyBob3N0IGJyaWRnZSB3aW5kb3dzIGZyb20gQUNQSTsgaWYgbmVjZXNzYXJ5
LCB1c2UgInBjaT11c2VfY3JzIiBhbmQgcmVwb3J0IGEgYnVnCkRlYyAgMSAxNTo1NToyMCBHcmlk
b3NfTm9kZSBrZXJuZWw6IFsgICAgMC4xMDY4NDFdIEFDUEk6IFBDSSBSb290IEJyaWRnZSBbUENJ
MF0gKGRvbWFpbiAwMDAwIFtidXMgMDAtZmZdKQpEZWMgIDEgMTU6NTU6MjAgR3JpZG9zX05vZGUg
a2VybmVsOiBbICAgIDAuMTE0NDA1XSBwY2kgMDAwMDowMTowMC4wOiBkaXNhYmxpbmcgQVNQTSBv
biBwcmUtMS4xIFBDSWUgZGV2aWNlLiAgWW91IGNhbiBlbmFibGUgaXQgd2l0aCAncGNpZV9hc3Bt
PWZvcmNlJwpEZWMgIDEgMTU6NTU6MjAgR3JpZG9zX05vZGUga2VybmVsOiBbICAgIDAuMTE0NTQ4
XSBwY2kgMDAwMDowMDowMi4wOiBQQ0kgYnJpZGdlIHRvIFtidXMgMDEtMDNdCkRlYyAgMSAxNTo1
NToyMCBHcmlkb3NfTm9kZSBrZXJuZWw6IFsgICAgMC4xMTUzMTBdIHBjaSAwMDAwOjAxOjAwLjA6
IFBDSSBicmlkZ2UgdG8gW2J1cyAwMi0wMl0KRGVjICAxIDE1OjU1OjIwIEdyaWRvc19Ob2RlIGtl
cm5lbDogWyAgICAwLjExNTcwOF0gcGNpIDAwMDA6MDE6MDAuMjogUENJIGJyaWRnZSB0byBbYnVz
IDAzLTAzXQpEZWMgIDEgMTU6NTU6MjAgR3JpZG9zX05vZGUga2VybmVsOiBbICAgIDAuMTE2MDI3
XSBwY2kgMDAwMDowMDowNC4wOiBQQ0kgYnJpZGdlIHRvIFtidXMgMDQtMDRdCkRlYyAgMSAxNTo1
NToyMCBHcmlkb3NfTm9kZSBrZXJuZWw6IFsgICAgMC4xMTY0MzNdIHBjaSAwMDAwOjA1OjAwLjA6
IFBYSCBxdWlyayBkZXRlY3RlZDsgU0hQQyBkZXZpY2UgTVNJIGRpc2FibGVkCkRlYyAgMSAxNTo1
NToyMCBHcmlkb3NfTm9kZSBrZXJuZWw6IFsgICAgMC4xMTY4ODldIHBjaSAwMDAwOjA1OjAwLjI6
IFBYSCBxdWlyayBkZXRlY3RlZDsgU0hQQyBkZXZpY2UgTVNJIGRpc2FibGVkCkRlYyAgMSAxNTo1
NToyMCBHcmlkb3NfTm9kZSBrZXJuZWw6IFsgICAgMC4xMTcyMzddIHBjaSAwMDAwOjA1OjAwLjA6
IGRpc2FibGluZyBBU1BNIG9uIHByZS0xLjEgUENJZSBkZXZpY2UuICBZb3UgY2FuIGVuYWJsZSBp
dCB3aXRoICdwY2llX2FzcG09Zm9yY2UnCkRlYyAgMSAxNTo1NToyMCBHcmlkb3NfTm9kZSBrZXJu
ZWw6IFsgICAgMC4xMTczNzhdIHBjaSAwMDAwOjAwOjA1LjA6IFBDSSBicmlkZ2UgdG8gW2J1cyAw
NS0wN10KRGVjICAxIDE1OjU1OjIwIEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgICAwLjExODEzM10g
cGNpIDAwMDA6MDU6MDAuMDogUENJIGJyaWRnZSB0byBbYnVzIDA2LTA2XQpEZWMgIDEgMTU6NTU6
MjEgR3JpZG9zX05vZGUga2VybmVsOiBbICAgIDAuMTE4OTAxXSBwY2kgMDAwMDowNTowMC4yOiBQ
Q0kgYnJpZGdlIHRvIFtidXMgMDctMDddCkRlYyAgMSAxNTo1NToyMSBHcmlkb3NfTm9kZSBrZXJu
ZWw6IFsgICAgMC4xMTkyMjBdIHBjaSAwMDAwOjAwOjA2LjA6IFBDSSBicmlkZ2UgdG8gW2J1cyAw
OC0wOF0KRGVjICAxIDE1OjU1OjIxIEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgICAwLjEyMTEyOF0g
cGNpIDAwMDA6MDA6MWUuMDogUENJIGJyaWRnZSB0byBbYnVzIDA5LTA5XSAoc3VidHJhY3RpdmUg
ZGVjb2RlKQpEZWMgIDEgMTU6NTU6MjEgR3JpZG9zX05vZGUga2VybmVsOiBbICAgIDAuMTI3Nzc0
XSAgcGNpMDAwMDowMDogUmVxdWVzdGluZyBBQ1BJIF9PU0MgY29udHJvbCAoMHgxZCkKRGVjICAx
IDE1OjU1OjIxIEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgICAwLjEyOTY4OV0gIHBjaTAwMDA6MDA6
IEFDUEkgX09TQyByZXF1ZXN0IGZhaWxlZCAoQUVfTk9UX0ZPVU5EKSwgcmV0dXJuZWQgY29udHJv
bCBtYXNrOiAweDFkCkRlYyAgMSAxNTo1NToyMSBHcmlkb3NfTm9kZSBrZXJuZWw6IFsgICAgMC4x
Mjk3OTldIEFDUEkgX09TQyBjb250cm9sIGZvciBQQ0llIG5vdCBncmFudGVkLCBkaXNhYmxpbmcg
QVNQTQpEZWMgIDEgMTU6NTU6MjEgR3JpZG9zX05vZGUga2VybmVsOiBbICAgIDAuMTQ0ODIyXSBB
Q1BJOiBQQ0kgSW50ZXJydXB0IExpbmsgW0xOS0FdIChJUlFzIDMgNCA1IDYgNyAxMCAqMTEgMTIp
CkRlYyAgMSAxNTo1NToyMSBHcmlkb3NfTm9kZSBrZXJuZWw6IFsgICAgMC4xNDU5MTZdIEFDUEk6
IFBDSSBJbnRlcnJ1cHQgTGluayBbTE5LQl0gKElSUXMgKjMgNCA1IDYgNyAxMCAxMSAxMikKRGVj
ICAxIDE1OjU1OjIxIEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgICAwLjE0NzAwNV0gQUNQSTogUENJ
IEludGVycnVwdCBMaW5rIFtMTktDXSAoSVJRcyAzIDQgNSA2ICo3IDEwIDExIDEyKQpEZWMgIDEg
MTU6NTU6MjEgR3JpZG9zX05vZGUga2VybmVsOiBbICAgIDAuMTQ4MDk1XSBBQ1BJOiBQQ0kgSW50
ZXJydXB0IExpbmsgW0xOS0RdIChJUlFzIDMgNCA1IDYgNyAqMTAgMTEgMTIpCkRlYyAgMSAxNTo1
NToyMSBHcmlkb3NfTm9kZSBrZXJuZWw6IFsgICAgMC4xNDkxOThdIEFDUEk6IFBDSSBJbnRlcnJ1
cHQgTGluayBbTE5LRV0gKElSUXMgMyA0IDUgNiA3IDEwICoxMSAxMikKRGVjICAxIDE1OjU1OjIx
IEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgICAwLjE1MDI0Nl0gQUNQSTogUENJIEludGVycnVwdCBM
aW5rIFtMTktGXSAoSVJRcyAzIDQgNSA2IDcgKjEwIDExIDEyKQpEZWMgIDEgMTU6NTU6MjEgR3Jp
ZG9zX05vZGUga2VybmVsOiBbICAgIDAuMTUxMzMwXSBBQ1BJOiBQQ0kgSW50ZXJydXB0IExpbmsg
W0xOS0ddIChJUlFzIDMgNCA1IDYgNyAxMCAxMSAxMikgKjAsIGRpc2FibGVkLgpEZWMgIDEgMTU6
NTU6MjEgR3JpZG9zX05vZGUga2VybmVsOiBbICAgIDAuMTUyNTg2XSBBQ1BJOiBQQ0kgSW50ZXJy
dXB0IExpbmsgW0xOS0hdIChJUlFzIDMgNCAqNSA2IDcgMTAgMTEgMTIpCkRlYyAgMSAxNTo1NToy
MSBHcmlkb3NfTm9kZSBrZXJuZWw6IFsgICAgMC4xNTM2MDZdIHhlbi9iYWxsb29uOiBJbml0aWFs
aXNpbmcgYmFsbG9vbiBkcml2ZXIuCkRlYyAgMSAxNTo1NToyMSBHcmlkb3NfTm9kZSBrZXJuZWw6
IFsgICAgMC4xNTM3MDFdIGxhc3RfcGZuID0gMHgxZGZmYzAgbWF4X2FyY2hfcGZuID0gMHgxMDAw
MDAwCkRlYyAgMSAxNTo1NToyMSBHcmlkb3NfTm9kZSBrZXJuZWw6IFsgICAgMC4xNzM0NTBdIHhl
bi1iYWxsb29uOiBJbml0aWFsaXNpbmcgYmFsbG9vbiBkcml2ZXIuCkRlYyAgMSAxNTo1NToyMSBH
cmlkb3NfTm9kZSBrZXJuZWw6IFsgICAgMC4xNzQwMzVdIHZnYWFyYjogZGV2aWNlIGFkZGVkOiBQ
Q0k6MDAwMDowOTowZC4wLGRlY29kZXM9aW8rbWVtLG93bnM9aW8rbWVtLGxvY2tzPW5vbmUKRGVj
ICAxIDE1OjU1OjIxIEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgICAwLjE3NDE0OV0gdmdhYXJiOiBs
b2FkZWQKRGVjICAxIDE1OjU1OjIxIEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgICAwLjE3NDIzN10g
dmdhYXJiOiBicmlkZ2UgY29udHJvbCBwb3NzaWJsZSAwMDAwOjA5OjBkLjAKRGVjICAxIDE1OjU1
OjIxIEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgICAwLjE3NDMzMF0gdXNiY29yZTogVVNCIHN1cHBv
cnQgZGlzYWJsZWQKRGVjICAxIDE1OjU1OjIxIEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgICAwLjE3
NTEwMV0gUENJOiBVc2luZyBBQ1BJIGZvciBJUlEgcm91dGluZwpEZWMgIDEgMTU6NTU6MjEgR3Jp
ZG9zX05vZGUga2VybmVsOiBbICAgIDAuMTgwODY5XSBTd2l0Y2hpbmcgdG8gY2xvY2tzb3VyY2Ug
eGVuCkRlYyAgMSAxNTo1NToyMSBHcmlkb3NfTm9kZSBrZXJuZWw6IFsgICAgMC4xODA5NzBdIHBu
cDogUG5QIEFDUEkgaW5pdApEZWMgIDEgMTU6NTU6MjEgR3JpZG9zX05vZGUga2VybmVsOiBbICAg
IDAuMTgwOTcwXSBBQ1BJOiBidXMgdHlwZSBwbnAgcmVnaXN0ZXJlZApEZWMgIDEgMTU6NTU6MjEg
R3JpZG9zX05vZGUga2VybmVsOiBbICAgIDAuMTgzNTU0XSB4ZW5fbWFwX3BpcnFfZ3NpOiByZXR1
cm5pbmcgaXJxIDEzIGZvciBnc2kgMTMKRGVjICAxIDE1OjU1OjIxIEdyaWRvc19Ob2RlIGtlcm5l
bDogWyAgICAwLjE4NDI0MF0geGVuX21hcF9waXJxX2dzaTogcmV0dXJuaW5nIGlycSA4IGZvciBn
c2kgOApEZWMgIDEgMTU6NTU6MjEgR3JpZG9zX05vZGUga2VybmVsOiBbICAgIDAuMTg1Njc2XSB4
ZW5fbWFwX3BpcnFfZ3NpOiByZXR1cm5pbmcgaXJxIDYgZm9yIGdzaSA2CkRlYyAgMSAxNTo1NToy
MSBHcmlkb3NfTm9kZSBrZXJuZWw6IFsgICAgMC4xODcxMDZdIHhlbl9tYXBfcGlycV9nc2k6IHJl
dHVybmluZyBpcnEgMSBmb3IgZ3NpIDEKRGVjICAxIDE1OjU1OjIxIEdyaWRvc19Ob2RlIGtlcm5l
bDogWyAgICAwLjE4OTEyMV0geGVuX21hcF9waXJxX2dzaTogcmV0dXJuaW5nIGlycSAxMiBmb3Ig
Z3NpIDEyCkRlYyAgMSAxNTo1NToyMSBHcmlkb3NfTm9kZSBrZXJuZWw6IFsgICAgMC4xOTAxOTRd
IHhlbl9tYXBfcGlycV9nc2k6IHJldHVybmluZyBpcnEgNCBmb3IgZ3NpIDQKRGVjICAxIDE1OjU1
OjIxIEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgICAwLjE5Mjk3Ml0gc3lzdGVtIDAwOjA5OiBbaW8g
IDB4MDgwMC0weDA4N2ZdIGhhcyBiZWVuIHJlc2VydmVkCkRlYyAgMSAxNTo1NToyMSBHcmlkb3Nf
Tm9kZSBrZXJuZWw6IFsgICAgMC4xOTI5NzRdIHN5c3RlbSAwMDowOTogW2lvICAweDA4ODAtMHgw
OGJmXSBoYXMgYmVlbiByZXNlcnZlZApEZWMgIDEgMTU6NTU6MjEgR3JpZG9zX05vZGUga2VybmVs
OiBbICAgIDAuMTkyOTc0XSBzeXN0ZW0gMDA6MDk6IFtpbyAgMHgwOGMwLTB4MDhkZl0gaGFzIGJl
ZW4gcmVzZXJ2ZWQKRGVjICAxIDE1OjU1OjIxIEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgICAwLjE5
Mjk3NF0gc3lzdGVtIDAwOjA5OiBbaW8gIDB4MDhlMC0weDA4ZTNdIGhhcyBiZWVuIHJlc2VydmVk
CkRlYyAgMSAxNTo1NToyMSBHcmlkb3NfTm9kZSBrZXJuZWw6IFsgICAgMC4xOTI5NzRdIHN5c3Rl
bSAwMDowOTogW2lvICAweDBjMDAtMHgwYzBmXSBoYXMgYmVlbiByZXNlcnZlZApEZWMgIDEgMTU6
NTU6MjEgR3JpZG9zX05vZGUga2VybmVsOiBbICAgIDAuMTkyOTc0XSBzeXN0ZW0gMDA6MDk6IFtp
byAgMHgwYzEwLTB4MGMxZl0gaGFzIGJlZW4gcmVzZXJ2ZWQKRGVjICAxIDE1OjU1OjIxIEdyaWRv
c19Ob2RlIGtlcm5lbDogWyAgICAwLjE5Mjk3NF0gc3lzdGVtIDAwOjA5OiBbaW8gIDB4MGNhMC0w
eDBjYTddIGhhcyBiZWVuIHJlc2VydmVkCkRlYyAgMSAxNTo1NToyMSBHcmlkb3NfTm9kZSBrZXJu
ZWw6IFsgICAgMC4xOTI5NzRdIHN5c3RlbSAwMDowOTogW2lvICAweDBjYTktMHgwY2FiXSBoYXMg
YmVlbiByZXNlcnZlZApEZWMgIDEgMTU6NTU6MjEgR3JpZG9zX05vZGUga2VybmVsOiBbICAgIDAu
MTkyOTc0XSBzeXN0ZW0gMDA6MDk6IFtpbyAgMHgwY2FkLTB4MGNhZl0gaGFzIGJlZW4gcmVzZXJ2
ZWQKRGVjICAxIDE1OjU1OjIxIEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgICAwLjE5Mjk3NF0gc3lz
dGVtIDAwOjA5OiBbaW8gIDB4MGMyMC0weDBjM2ZdIGhhcyBiZWVuIHJlc2VydmVkCkRlYyAgMSAx
NTo1NToyMSBHcmlkb3NfTm9kZSBrZXJuZWw6IFsgICAgMC4xOTI5NzRdIHN5c3RlbSAwMDowYjog
W21lbSAweGUwMDAwMDAwLTB4ZWZmZmZmZmZdIGhhcyBiZWVuIHJlc2VydmVkCkRlYyAgMSAxNTo1
NToyMSBHcmlkb3NfTm9kZSBrZXJuZWw6IFsgICAgMC4xOTI5NzRdIHBucDogUG5QIEFDUEk6IGZv
dW5kIDEzIGRldmljZXMKRGVjICAxIDE1OjU1OjIxIEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgICAw
LjE5Mjk3NF0gQUNQSTogQUNQSSBidXMgdHlwZSBwbnAgdW5yZWdpc3RlcmVkCkRlYyAgMSAxNTo1
NToyMSBHcmlkb3NfTm9kZSBrZXJuZWw6IFsgICAgMC4yMTY5MzJdIFBNLVRpbWVyIGZhaWxlZCBj
b25zaXN0ZW5jeSBjaGVjayAgKDB4MHhmZmZmZmYpIC0gYWJvcnRpbmcuCkRlYyAgMSAxNTo1NToy
MSBHcmlkb3NfTm9kZSBrZXJuZWw6IFsgICAgMC4yMTcwODNdIHBjaSAwMDAwOjA5OjA2LjA6IGFk
ZHJlc3Mgc3BhY2UgY29sbGlzaW9uOiBbbWVtIDB4ZGY2MDAwMDAtMHhkZjY3ZmZmZiBwcmVmXSBj
b25mbGljdHMgd2l0aCAwMDAwOjA5OjA1LjAgW21lbSAweGRmNjAwMDAwLTB4ZGY2MGZmZmYgcHJl
Zl0KRGVjICAxIDE1OjU1OjIxIEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgICAwLjIxNzQwMl0gcGNp
IDAwMDA6MDA6MWYuMTogQkFSIDU6IGFzc2lnbmVkIFttZW0gMHhiZmZmZjAwMC0weGJmZmZmM2Zm
XQpEZWMgIDEgMTU6NTU6MjEgR3JpZG9zX05vZGUga2VybmVsOiBbICAgIDAuMjE3NTA3XSBwY2kg
MDAwMDowMDoxZi4xOiBCQVIgNTogc2V0IHRvIFttZW0gMHhiZmZmZjAwMC0weGJmZmZmM2ZmXSAo
UENJIGFkZHJlc3MgWzB4YmZmZmYwMDAtMHhiZmZmZjNmZl0pCkRlYyAgMSAxNTo1NToyMSBHcmlk
b3NfTm9kZSBrZXJuZWw6IFsgICAgMC4yMTc2MjNdIHBjaSAwMDAwOjAxOjAwLjA6IFBDSSBicmlk
Z2UgdG8gW2J1cyAwMi0wMl0KRGVjICAxIDE1OjU1OjIxIEdyaWRvc19Ob2RlIGtlcm5lbDogWyAg
ICAwLjIxNzcyMF0gcGNpIDAwMDA6MDE6MDAuMDogICBicmlkZ2Ugd2luZG93IFtpbyAgMHhlMDAw
LTB4ZWZmZl0KRGVjICAxIDE1OjU1OjIxIEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgICAwLjIxNzgy
NV0gcGNpIDAwMDA6MDE6MDAuMDogICBicmlkZ2Ugd2luZG93IFttZW0gMHhkZmQwMDAwMC0weGRm
ZWZmZmZmXQpEZWMgIDEgMTU6NTU6MjEgR3JpZG9zX05vZGUga2VybmVsOiBbICAgIDAuMjE3OTI3
XSBwY2kgMDAwMDowMTowMC4wOiAgIGJyaWRnZSB3aW5kb3cgW21lbSAweGQ4MDAwMDAwLTB4ZDhm
ZmZmZmYgNjRiaXQgcHJlZl0KRGVjICAxIDE1OjU1OjIxIEdyaWRvc19Ob2RlIGtlcm5lbDogWyAg
ICAwLjIxODA1Ml0gcGNpIDAwMDA6MDE6MDAuMjogUENJIGJyaWRnZSB0byBbYnVzIDAzLTAzXQpE
ZWMgIDEgMTU6NTU6MjEgR3JpZG9zX05vZGUga2VybmVsOiBbICAgIDAuMjE4MTQ0XSBwY2kgMDAw
MDowMTowMC4yOiAgIGJyaWRnZSB3aW5kb3cgW2lvICBkaXNhYmxlZF0KRGVjICAxIDE1OjU1OjIx
IEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgICAwLjIxODI0N10gcGNpIDAwMDA6MDE6MDAuMjogICBi
cmlkZ2Ugd2luZG93IFttZW0gZGlzYWJsZWRdCkRlYyAgMSAxNTo1NToyMSBHcmlkb3NfTm9kZSBr
ZXJuZWw6IFsgICAgMC4yMTgzNDddIHBjaSAwMDAwOjAxOjAwLjI6ICAgYnJpZGdlIHdpbmRvdyBb
bWVtIHByZWYgZGlzYWJsZWRdCkRlYyAgMSAxNTo1NToyMSBHcmlkb3NfTm9kZSBrZXJuZWw6IFsg
ICAgMC4yMTg0NTRdIHBjaSAwMDAwOjAwOjAyLjA6IFBDSSBicmlkZ2UgdG8gW2J1cyAwMS0wM10K
RGVjICAxIDE1OjU1OjIyIEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgICAwLjIxODU1MV0gcGNpIDAw
MDA6MDA6MDIuMDogICBicmlkZ2Ugd2luZG93IFtpbyAgMHhlMDAwLTB4ZWZmZl0KRGVjICAxIDE1
OjU1OjIyIEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgICAwLjIxODY1NV0gcGNpIDAwMDA6MDA6MDIu
MDogICBicmlkZ2Ugd2luZG93IFttZW0gMHhkZmMwMDAwMC0weGRmZWZmZmZmXQpEZWMgIDEgMTU6
NTU6MjIgR3JpZG9zX05vZGUga2VybmVsOiBbICAgIDAuMjE4NzU3XSBwY2kgMDAwMDowMDowMi4w
OiAgIGJyaWRnZSB3aW5kb3cgW21lbSAweGQ4MDAwMDAwLTB4ZDhmZmZmZmYgNjRiaXQgcHJlZl0K
RGVjICAxIDE1OjU1OjIyIEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgICAwLjIxODg4MV0gcGNpIDAw
MDA6MDA6MDQuMDogUENJIGJyaWRnZSB0byBbYnVzIDA0LTA0XQpEZWMgIDEgMTU6NTU6MjIgR3Jp
ZG9zX05vZGUga2VybmVsOiBbICAgIDAuMjE4OTczXSBwY2kgMDAwMDowMDowNC4wOiAgIGJyaWRn
ZSB3aW5kb3cgW2lvICBkaXNhYmxlZF0KRGVjICAxIDE1OjU1OjIyIEdyaWRvc19Ob2RlIGtlcm5l
bDogWyAgICAwLjIxOTA3Nl0gcGNpIDAwMDA6MDA6MDQuMDogICBicmlkZ2Ugd2luZG93IFttZW0g
ZGlzYWJsZWRdCkRlYyAgMSAxNTo1NToyMiBHcmlkb3NfTm9kZSBrZXJuZWw6IFsgICAgMC4yMTkx
NzVdIHBjaSAwMDAwOjAwOjA0LjA6ICAgYnJpZGdlIHdpbmRvdyBbbWVtIHByZWYgZGlzYWJsZWRd
CkRlYyAgMSAxNTo1NToyMiBHcmlkb3NfTm9kZSBrZXJuZWw6IFsgICAgMC4yMTkyODNdIHBjaSAw
MDAwOjA1OjAwLjA6IFBDSSBicmlkZ2UgdG8gW2J1cyAwNi0wNl0KRGVjICAxIDE1OjU1OjIyIEdy
aWRvc19Ob2RlIGtlcm5lbDogWyAgICAwLjIxOTM4MF0gcGNpIDAwMDA6MDU6MDAuMDogICBicmlk
Z2Ugd2luZG93IFtpbyAgMHhkMDAwLTB4ZGZmZl0KRGVjICAxIDE1OjU1OjIyIEdyaWRvc19Ob2Rl
IGtlcm5lbDogWyAgICAwLjIxOTQ4NF0gcGNpIDAwMDA6MDU6MDAuMDogICBicmlkZ2Ugd2luZG93
IFttZW0gMHhkZmEwMDAwMC0weGRmYmZmZmZmXQpEZWMgIDEgMTU6NTU6MjIgR3JpZG9zX05vZGUg
a2VybmVsOiBbICAgIDAuMjE5NTg1XSBwY2kgMDAwMDowNTowMC4wOiAgIGJyaWRnZSB3aW5kb3cg
W21lbSBwcmVmIGRpc2FibGVkXQpEZWMgIDEgMTU6NTU6MjIgR3JpZG9zX05vZGUga2VybmVsOiBb
ICAgIDAuMjE5NjkzXSBwY2kgMDAwMDowNTowMC4yOiBQQ0kgYnJpZGdlIHRvIFtidXMgMDctMDdd
CkRlYyAgMSAxNTo1NToyMiBHcmlkb3NfTm9kZSBrZXJuZWw6IFsgICAgMC4yMTk3ODldIHBjaSAw
MDAwOjA1OjAwLjI6ICAgYnJpZGdlIHdpbmRvdyBbaW8gIDB4YzAwMC0weGNmZmZdCkRlYyAgMSAx
NTo1NToyMiBHcmlkb3NfTm9kZSBrZXJuZWw6IFsgICAgMC4yMTk4OTRdIHBjaSAwMDAwOjA1OjAw
LjI6ICAgYnJpZGdlIHdpbmRvdyBbbWVtIDB4ZGY4MDAwMDAtMHhkZjlmZmZmZl0KRGVjICAxIDE1
OjU1OjIyIEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgICAwLjIxOTk5NV0gcGNpIDAwMDA6MDU6MDAu
MjogICBicmlkZ2Ugd2luZG93IFttZW0gcHJlZiBkaXNhYmxlZF0KRGVjICAxIDE1OjU1OjIyIEdy
aWRvc19Ob2RlIGtlcm5lbDogWyAgICAwLjIyMDAzMV0gcGNpIDAwMDA6MDA6MDUuMDogUENJIGJy
aWRnZSB0byBbYnVzIDA1LTA3XQpEZWMgIDEgMTU6NTU6MjIgR3JpZG9zX05vZGUga2VybmVsOiBb
ICAgIDAuMjIwMDMxXSBwY2kgMDAwMDowMDowNS4wOiAgIGJyaWRnZSB3aW5kb3cgW2lvICAweGMw
MDAtMHhkZmZmXQpEZWMgIDEgMTU6NTU6MjIgR3JpZG9zX05vZGUga2VybmVsOiBbICAgIDAuMjIw
MDMxXSBwY2kgMDAwMDowMDowNS4wOiAgIGJyaWRnZSB3aW5kb3cgW21lbSAweGRmNzAwMDAwLTB4
ZGZiZmZmZmZdCkRlYyAgMSAxNTo1NToyMiBHcmlkb3NfTm9kZSBrZXJuZWw6IFsgICAgMC4yMjAw
MzFdIHBjaSAwMDAwOjAwOjA1LjA6ICAgYnJpZGdlIHdpbmRvdyBbbWVtIHByZWYgZGlzYWJsZWRd
CkRlYyAgMSAxNTo1NToyMiBHcmlkb3NfTm9kZSBrZXJuZWw6IFsgICAgMC4yMjAwMzFdIHBjaSAw
MDAwOjAwOjA2LjA6IFBDSSBicmlkZ2UgdG8gW2J1cyAwOC0wOF0KRGVjICAxIDE1OjU1OjIyIEdy
aWRvc19Ob2RlIGtlcm5lbDogWyAgICAwLjIyMDAzMV0gcGNpIDAwMDA6MDA6MDYuMDogICBicmlk
Z2Ugd2luZG93IFtpbyAgZGlzYWJsZWRdCkRlYyAgMSAxNTo1NToyMiBHcmlkb3NfTm9kZSBrZXJu
ZWw6IFsgICAgMC4yMjAwMzFdIHBjaSAwMDAwOjAwOjA2LjA6ICAgYnJpZGdlIHdpbmRvdyBbbWVt
IGRpc2FibGVkXQpEZWMgIDEgMTU6NTU6MjIgR3JpZG9zX05vZGUga2VybmVsOiBbICAgIDAuMjIw
MDMxXSBwY2kgMDAwMDowMDowNi4wOiAgIGJyaWRnZSB3aW5kb3cgW21lbSBwcmVmIGRpc2FibGVk
XQpEZWMgIDEgMTU6NTU6MjIgR3JpZG9zX05vZGUga2VybmVsOiBbICAgIDAuMjIwMDMxXSBwY2kg
MDAwMDowOTowNi4wOiBCQVIgNjogYXNzaWduZWQgW21lbSAweGQwMDAwMDAwLTB4ZDAwN2ZmZmYg
cHJlZl0KRGVjICAxIDE1OjU1OjIyIEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgICAwLjIyMDAzMV0g
cGNpIDAwMDA6MDk6MGQuMDogQkFSIDY6IGFzc2lnbmVkIFttZW0gMHhkMDA4MDAwMC0weGQwMDlm
ZmZmIHByZWZdCkRlYyAgMSAxNTo1NToyMiBHcmlkb3NfTm9kZSBrZXJuZWw6IFsgICAgMC4yMjAw
MzFdIHBjaSAwMDAwOjAwOjFlLjA6IFBDSSBicmlkZ2UgdG8gW2J1cyAwOS0wOV0KRGVjICAxIDE1
OjU1OjIyIEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgICAwLjIyMDAzMV0gcGNpIDAwMDA6MDA6MWUu
MDogICBicmlkZ2Ugd2luZG93IFtpbyAgMHhiMDAwLTB4YmZmZl0KRGVjICAxIDE1OjU1OjIyIEdy
aWRvc19Ob2RlIGtlcm5lbDogWyAgICAwLjIyMDAzMV0gcGNpIDAwMDA6MDA6MWUuMDogICBicmlk
Z2Ugd2luZG93IFttZW0gMHhkZjUwMDAwMC0weGRmNmZmZmZmXQpEZWMgIDEgMTU6NTU6MjIgR3Jp
ZG9zX05vZGUga2VybmVsOiBbICAgIDAuMjIwMDMxXSBwY2kgMDAwMDowMDoxZS4wOiAgIGJyaWRn
ZSB3aW5kb3cgW21lbSAweGM4MDAwMDAwLTB4ZDdmZmZmZmYgcHJlZl0KRGVjICAxIDE1OjU1OjIy
IEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgICAwLjIyMTYxOV0gcGNpIDAwMDA6MDA6MDIuMDogUENJ
IElOVCBBIC0+IEdTSSAxNiAobGV2ZWwsIGxvdykgLT4gSVJRIDE2CkRlYyAgMSAxNTo1NToyMiBH
cmlkb3NfTm9kZSBrZXJuZWw6IFsgICAgMC4yMjE4MDJdIHhlbl9tYXBfcGlycV9nc2k6IHJldHVy
bmluZyBpcnEgMTYgZm9yIGdzaSAxNgpEZWMgIDEgMTU6NTU6MjIgR3JpZG9zX05vZGUga2VybmVs
OiBbICAgIDAuMjIxOTAxXSBBbHJlYWR5IHNldHVwIHRoZSBHU0kgOjE2CkRlYyAgMSAxNTo1NToy
MiBHcmlkb3NfTm9kZSBrZXJuZWw6IFsgICAgMC4yMjE5OTJdIHBjaSAwMDAwOjAwOjA0LjA6IFBD
SSBJTlQgQSAtPiBHU0kgMTYgKGxldmVsLCBsb3cpIC0+IElSUSAxNgpEZWMgIDEgMTU6NTU6MjIg
R3JpZG9zX05vZGUga2VybmVsOiBbICAgIDAuMjIyMTI0XSB4ZW5fbWFwX3BpcnFfZ3NpOiByZXR1
cm5pbmcgaXJxIDE2IGZvciBnc2kgMTYKRGVjICAxIDE1OjU1OjIyIEdyaWRvc19Ob2RlIGtlcm5l
bDogWyAgICAwLjIyMjIyMl0gQWxyZWFkeSBzZXR1cCB0aGUgR1NJIDoxNgpEZWMgIDEgMTU6NTU6
MjIgR3JpZG9zX05vZGUga2VybmVsOiBbICAgIDAuMjIyMzEzXSBwY2kgMDAwMDowMDowNS4wOiBQ
Q0kgSU5UIEEgLT4gR1NJIDE2IChsZXZlbCwgbG93KSAtPiBJUlEgMTYKRGVjICAxIDE1OjU1OjIy
IEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgICAwLjIyMjQ5Nl0geGVuX21hcF9waXJxX2dzaTogcmV0
dXJuaW5nIGlycSAxNiBmb3IgZ3NpIDE2CkRlYyAgMSAxNTo1NToyMyBHcmlkb3NfTm9kZSBrZXJu
ZWw6IFsgICAgMC4yMjI1OTVdIEFscmVhZHkgc2V0dXAgdGhlIEdTSSA6MTYKRGVjICAxIDE1OjU1
OjIzIEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgICAwLjIyMjY4Nl0gcGNpIDAwMDA6MDA6MDYuMDog
UENJIElOVCBBIC0+IEdTSSAxNiAobGV2ZWwsIGxvdykgLT4gSVJRIDE2CkRlYyAgMSAxNTo1NToy
MyBHcmlkb3NfTm9kZSBrZXJuZWw6IFsgICAgMC4yMjM0OTJdIE5FVDogUmVnaXN0ZXJlZCBwcm90
b2NvbCBmYW1pbHkgMgpEZWMgIDEgMTU6NTU6MjMgR3JpZG9zX05vZGUga2VybmVsOiBbICAgIDAu
MjIzODU3XSBJUCByb3V0ZSBjYWNoZSBoYXNoIHRhYmxlIGVudHJpZXM6IDQwOTYgKG9yZGVyOiAy
LCAxNjM4NCBieXRlcykKRGVjICAxIDE1OjU1OjIzIEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgICAw
LjIyNTI1MV0gVENQIGVzdGFibGlzaGVkIGhhc2ggdGFibGUgZW50cmllczogMTYzODQgKG9yZGVy
OiA1LCAxMzEwNzIgYnl0ZXMpCkRlYyAgMSAxNTo1NToyMyBHcmlkb3NfTm9kZSBrZXJuZWw6IFsg
ICAgMC4yMjU0NzFdIFRDUCBiaW5kIGhhc2ggdGFibGUgZW50cmllczogMTYzODQgKG9yZGVyOiA1
LCAxMzEwNzIgYnl0ZXMpCkRlYyAgMSAxNTo1NToyMyBHcmlkb3NfTm9kZSBrZXJuZWw6IFsgICAg
MC4yMjU2MzddIFRDUDogSGFzaCB0YWJsZXMgY29uZmlndXJlZCAoZXN0YWJsaXNoZWQgMTYzODQg
YmluZCAxNjM4NCkKRGVjICAxIDE1OjU1OjIzIEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgICAwLjIy
NTczMV0gVENQIHJlbm8gcmVnaXN0ZXJlZApEZWMgIDEgMTU6NTU6MjMgR3JpZG9zX05vZGUga2Vy
bmVsOiBbICAgIDAuMjI1ODI3XSBVRFAgaGFzaCB0YWJsZSBlbnRyaWVzOiAyNTYgKG9yZGVyOiAx
LCA4MTkyIGJ5dGVzKQpEZWMgIDEgMTU6NTU6MjMgR3JpZG9zX05vZGUga2VybmVsOiBbICAgIDAu
MjI1OTI5XSBVRFAtTGl0ZSBoYXNoIHRhYmxlIGVudHJpZXM6IDI1NiAob3JkZXI6IDEsIDgxOTIg
Ynl0ZXMpCkRlYyAgMSAxNTo1NToyMyBHcmlkb3NfTm9kZSBrZXJuZWw6IFsgICAgMC4yMjY2MjRd
IE5FVDogUmVnaXN0ZXJlZCBwcm90b2NvbCBmYW1pbHkgMQpEZWMgIDEgMTU6NTU6MjMgR3JpZG9z
X05vZGUga2VybmVsOiBbICAgIDAuMjI3NzMxXSBVbnBhY2tpbmcgaW5pdHJhbWZzLi4uCkRlYyAg
MSAxNTo1NToyMyBHcmlkb3NfTm9kZSBrZXJuZWw6IFsgICAgMC4yNDUxNTZdIGRlYnVnOiB1bm1h
cHBpbmcgaW5pdCBtZW1vcnkgYzE2NjcwMDAuLmMxYTFlMDAwCkRlYyAgMSAxNTo1NToyMyBHcmlk
b3NfTm9kZSBrZXJuZWw6IFsgICAgMC4yNDkwNTRdIG1pY3JvY29kZTogQ1BVMCBzaWc9MHhmNDMs
IHBmPTB4MSwgcmV2aXNpb249MHg1CkRlYyAgMSAxNTo1NToyMyBHcmlkb3NfTm9kZSBrZXJuZWw6
IFsgICAgMC4yNDkxODRdIG1pY3JvY29kZTogQ1BVMSBzaWc9MHhmNDMsIHBmPTB4MSwgcmV2aXNp
b249MHg1CkRlYyAgMSAxNTo1NToyMyBHcmlkb3NfTm9kZSBrZXJuZWw6IFsgICAgMC4yNDkyOTld
IG1pY3JvY29kZTogQ1BVMiBzaWc9MHhmNDMsIHBmPTB4MSwgcmV2aXNpb249MHg1CkRlYyAgMSAx
NTo1NToyMyBHcmlkb3NfTm9kZSBrZXJuZWw6IFsgICAgMC4yNDk0MThdIG1pY3JvY29kZTogQ1BV
MyBzaWc9MHhmNDMsIHBmPTB4MSwgcmV2aXNpb249MHg1CkRlYyAgMSAxNTo1NToyMyBHcmlkb3Nf
Tm9kZSBrZXJuZWw6IFsgICAgMC4yNDk2NzBdIG1pY3JvY29kZTogTWljcm9jb2RlIFVwZGF0ZSBE
cml2ZXI6IHYyLjAwIDx0aWdyYW5AYWl2YXppYW4uZnNuZXQuY28udWs+LCBQZXRlciBPcnViYQpE
ZWMgIDEgMTU6NTU6MjMgR3JpZG9zX05vZGUga2VybmVsOiBbICAgIDAuMjU0NjY3XSBtc2dtbmkg
aGFzIGJlZW4gc2V0IHRvIDc1MgpEZWMgIDEgMTU6NTU6MjMgR3JpZG9zX05vZGUga2VybmVsOiBb
ICAgIDAuMjU2MDM5XSBCbG9jayBsYXllciBTQ1NJIGdlbmVyaWMgKGJzZykgZHJpdmVyIHZlcnNp
b24gMC40IGxvYWRlZCAobWFqb3IgMjU0KQpEZWMgIDEgMTU6NTU6MjMgR3JpZG9zX05vZGUga2Vy
bmVsOiBbICAgIDAuMjU2MTUxXSBpbyBzY2hlZHVsZXIgbm9vcCByZWdpc3RlcmVkCkRlYyAgMSAx
NTo1NToyMyBHcmlkb3NfTm9kZSBrZXJuZWw6IFsgICAgMC4yNTYyNDJdIGlvIHNjaGVkdWxlciBk
ZWFkbGluZSByZWdpc3RlcmVkCkRlYyAgMSAxNTo1NToyMyBHcmlkb3NfTm9kZSBrZXJuZWw6IFsg
ICAgMC4yNTY1MDhdIGlvIHNjaGVkdWxlciBjZnEgcmVnaXN0ZXJlZCAoZGVmYXVsdCkKRGVjICAx
IDE1OjU1OjIzIEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgICAwLjI2OTk5Nl0gRXZlbnQtY2hhbm5l
bCBkZXZpY2UgaW5zdGFsbGVkLgpEZWMgIDEgMTU6NTU6MjMgR3JpZG9zX05vZGUga2VybmVsOiBb
ICAgIDAuMjcxNjE2XSBTZXJpYWw6IDgyNTAvMTY1NTAgZHJpdmVyLCA0IHBvcnRzLCBJUlEgc2hh
cmluZyBlbmFibGVkCkRlYyAgMSAxNTo1NToyMyBHcmlkb3NfTm9kZSBrZXJuZWw6IFsgICAgMC41
NzAyNTddIHNlcmlhbDgyNTA6IHR0eVMwIGF0IEkvTyAweDNmOCAoaXJxID0gNCkgaXMgYSAxNjU1
MEEKRGVjICAxIDE1OjU1OjIzIEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgICAwLjczMDA1OV0gMDA6
MDg6IHR0eVMwIGF0IEkvTyAweDNmOCAoaXJxID0gNCkgaXMgYSAxNjU1MEEKRGVjICAxIDE1OjU1
OjIzIEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgICAwLjc5MDMyNl0gc2VyaWFsIDAwMDA6MDk6MDUu
MTogUENJIElOVCBCIC0+IEdTSSAyMSAobGV2ZWwsIGxvdykgLT4gSVJRIDIxCkRlYyAgMSAxNTo1
NToyMyBHcmlkb3NfTm9kZSBrZXJuZWw6IFsgICAgMC44MDAwNjBdIDAwMDA6MDk6MDUuMTogdHR5
UzEgYXQgSS9PIDB4YmM4MCAoaXJxID0gMjEpIGlzIGEgMTY1NTBBCkRlYyAgMSAxNTo1NToyMyBH
cmlkb3NfTm9kZSBrZXJuZWw6IFsgICAgMC44NDA0MTBdIFJlYWwgVGltZSBDbG9jayBEcml2ZXIg
djEuMTJiCkRlYyAgMSAxNTo1NToyMyBHcmlkb3NfTm9kZSBrZXJuZWw6IFsgICAgMC44NDA2NDZd
IGludGVsX3JuZzogRldIIG5vdCBkZXRlY3RlZApEZWMgIDEgMTU6NTU6MjMgR3JpZG9zX05vZGUg
a2VybmVsOiBbICAgIDAuODQ1OTE1XSBpODA0MjogUE5QOiBQUy8yIENvbnRyb2xsZXIgW1BOUDAz
MDM6S0JELFBOUDBmMTM6TU9VXSBhdCAweDYwLDB4NjQgaXJxIDEsMTIKRGVjICAxIDE1OjU1OjIz
IEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgICAwLjg0ODgzMl0gc2VyaW86IGk4MDQyIEtCRCBwb3J0
IGF0IDB4NjAsMHg2NCBpcnEgMQpEZWMgIDEgMTU6NTU6MjMgR3JpZG9zX05vZGUga2VybmVsOiBb
ICAgIDAuODQ4OTM2XSBzZXJpbzogaTgwNDIgQVVYIHBvcnQgYXQgMHg2MCwweDY0IGlycSAxMgpE
ZWMgIDEgMTU6NTU6MjMgR3JpZG9zX05vZGUga2VybmVsOiBbICAgIDAuODQ5NDExXSBtb3VzZWRl
djogUFMvMiBtb3VzZSBkZXZpY2UgY29tbW9uIGZvciBhbGwgbWljZQpEZWMgIDEgMTU6NTU6MjMg
R3JpZG9zX05vZGUga2VybmVsOiBbICAgIDAuODUwMDA5XSBjcHVpZGxlOiB1c2luZyBnb3Zlcm5v
ciBsYWRkZXIKRGVjICAxIDE1OjU1OjIzIEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgICAwLjg1MTc4
MV0gVENQIGN1YmljIHJlZ2lzdGVyZWQKRGVjICAxIDE1OjU1OjIzIEdyaWRvc19Ob2RlIGtlcm5l
bDogWyAgICAwLjg1MTg3M10gTkVUOiBSZWdpc3RlcmVkIHByb3RvY29sIGZhbWlseSAxNwpEZWMg
IDEgMTU6NTU6MjMgR3JpZG9zX05vZGUga2VybmVsOiBbICAgIDAuODUxOTk0XSBVc2luZyBJUEkg
Tm8tU2hvcnRjdXQgbW9kZQpEZWMgIDEgMTU6NTU6MjMgR3JpZG9zX05vZGUga2VybmVsOiBbICAg
IDAuODU0MjAwXSBkZWJ1ZzogdW5tYXBwaW5nIGluaXQgbWVtb3J5IGMxMzQ1MDAwLi5jMTNhNTAw
MApEZWMgIDEgMTU6NTU6MjMgR3JpZG9zX05vZGUga2VybmVsOiBbICAgIDAuODcwMTYwXSBuYXNo
LWhvdHBsdWcgKDM5KTogL3Byb2MvMzkvb29tX2FkaiBpcyBkZXByZWNhdGVkLCBwbGVhc2UgdXNl
IC9wcm9jLzM5L29vbV9zY29yZV9hZGogaW5zdGVhZC4KRGVjICAxIDE1OjU1OjIzIEdyaWRvc19O
b2RlIGtlcm5lbDogWyAgICAwLjkxMzgxMF0gaW5wdXQ6IEFUIFRyYW5zbGF0ZWQgU2V0IDIga2V5
Ym9hcmQgYXMgL2RldmljZXMvcGxhdGZvcm0vaTgwNDIvc2VyaW8wL2lucHV0L2lucHV0MApEZWMg
IDEgMTU6NTU6MjMgR3JpZG9zX05vZGUga2VybmVsOiBbICAgIDEuMTUxNjU1XSBTQ1NJIHN1YnN5
c3RlbSBpbml0aWFsaXplZApEZWMgIDEgMTU6NTU6MjMgR3JpZG9zX05vZGUga2VybmVsOiBbICAg
IDEuMTY2Njk5XSBGdXNpb24gTVBUIGJhc2UgZHJpdmVyIDMuMDQuMTkKRGVjICAxIDE1OjU1OjIz
IEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgICAxLjE2Njc5M10gQ29weXJpZ2h0IChjKSAxOTk5LTIw
MDggTFNJIENvcnBvcmF0aW9uCkRlYyAgMSAxNTo1NToyMyBHcmlkb3NfTm9kZSBrZXJuZWw6IFsg
ICAgMS4xNzQzNjhdIEZ1c2lvbiBNUFQgU1BJIEhvc3QgZHJpdmVyIDMuMDQuMTkKRGVjICAxIDE1
OjU1OjIzIEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgICAxLjE3NDU2NV0gbXB0c3BpIDAwMDA6MDI6
MDUuMDogUENJIElOVCBBIC0+IEdTSSAzNCAobGV2ZWwsIGxvdykgLT4gSVJRIDM0CkRlYyAgMSAx
NTo1NToyNCBHcmlkb3NfTm9kZSBrZXJuZWw6IFsgICAgMS4xNzgyNDhdIG1wdGJhc2U6IGlvYzA6
IEluaXRpYXRpbmcgYnJpbmd1cApEZWMgIDEgMTU6NTU6MjQgR3JpZG9zX05vZGUga2VybmVsOiBb
ICAgIDEuODEyODQ2XSBpbnB1dDogSW1FeFBTLzIgR2VuZXJpYyBFeHBsb3JlciBNb3VzZSBhcyAv
ZGV2aWNlcy9wbGF0Zm9ybS9pODA0Mi9zZXJpbzEvaW5wdXQvaW5wdXQxCkRlYyAgMSAxNTo1NToy
NCBHcmlkb3NfTm9kZSBrZXJuZWw6IFsgICAgMi40MjAwODhdIGlvYzA6IExTSTUzQzEwMzAgQzA6
IENhcGFiaWxpdGllcz17SW5pdGlhdG9yLFRhcmdldH0KRGVjICAxIDE1OjU1OjI0IEdyaWRvc19O
b2RlIGtlcm5lbDogWyAgICA0LjEwOTExMF0gc2NzaTAgOiBpb2MwOiBMU0k1M0MxMDMwIEMwLCBG
d1Jldj0wMTAzMjMwMGgsIFBvcnRzPTEsIE1heFE9MjU1LCBJUlE9MzQKRGVjICAxIDE1OjU1OjI0
IEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgICA0LjkwOTQyOV0gc2NzaSAwOjA6MDowOiBEaXJlY3Qt
QWNjZXNzICAgICBNQVhUT1IgICBBVExBUzEwSzRfNzNTQ0EgIERGTTAgUFE6IDAgQU5TSTogMwpE
ZWMgIDEgMTU6NTU6MjQgR3JpZG9zX05vZGUga2VybmVsOiBbICAgIDQuOTA5NTc1XSBzY3NpIHRh
cmdldDA6MDowOiBCZWdpbm5pbmcgRG9tYWluIFZhbGlkYXRpb24KRGVjICAxIDE1OjU1OjI0IEdy
aWRvc19Ob2RlIGtlcm5lbDogWyAgICA0LjkyMzk4Ml0gc2NzaSB0YXJnZXQwOjA6MDogRW5kaW5n
IERvbWFpbiBWYWxpZGF0aW9uCkRlYyAgMSAxNTo1NToyNCBHcmlkb3NfTm9kZSBrZXJuZWw6IFsg
ICAgNC45MjQyMjRdIHNjc2kgdGFyZ2V0MDowOjA6IEZBU1QtMTYwIFdJREUgU0NTSSAzMjAuMCBN
Qi9zIERUIElVIFJUSSAoNi4yNSBucywgb2Zmc2V0IDEyNykKRGVjICAxIDE1OjU1OjI0IEdyaWRv
c19Ob2RlIGtlcm5lbDogWyAgICA0LjkyNjQ0N10gc2QgMDowOjA6MDogW3NkYV0gMTQzMzc0NjUw
IDUxMi1ieXRlIGxvZ2ljYWwgYmxvY2tzOiAoNzMuNCBHQi82OC4zIEdpQikKRGVjICAxIDE1OjU1
OjI0IEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgICA0LjkyODQ3OF0gc2QgMDowOjA6MDogW3NkYV0g
V3JpdGUgUHJvdGVjdCBpcyBvZmYKRGVjICAxIDE1OjU1OjI0IEdyaWRvc19Ob2RlIGtlcm5lbDog
WyAgICA0LjkyOTc2N10gc2NzaSAwOjA6MTowOiBEaXJlY3QtQWNjZXNzICAgICBNQVhUT1IgICBB
VExBUzEwSzVfNzNTQ0EgIEpUMDAgUFE6IDAgQU5TSTogMwpEZWMgIDEgMTU6NTU6MjQgR3JpZG9z
X05vZGUga2VybmVsOiBbICAgIDQuOTI5OTgxXSBzY3NpIHRhcmdldDA6MDoxOiBCZWdpbm5pbmcg
RG9tYWluIFZhbGlkYXRpb24KRGVjICAxIDE1OjU1OjI0IEdyaWRvc19Ob2RlIGtlcm5lbDogWyAg
ICA0LjkzMTM5NV0gc2QgMDowOjA6MDogW3NkYV0gV3JpdGUgY2FjaGU6IGRpc2FibGVkLCByZWFk
IGNhY2hlOiBlbmFibGVkLCBzdXBwb3J0cyBEUE8gYW5kIEZVQQpEZWMgIDEgMTU6NTU6MjQgR3Jp
ZG9zX05vZGUga2VybmVsOiBbICAgIDQuOTQ2OTcwXSBzY3NpIHRhcmdldDA6MDoxOiBFbmRpbmcg
RG9tYWluIFZhbGlkYXRpb24KRGVjICAxIDE1OjU1OjI0IEdyaWRvc19Ob2RlIGtlcm5lbDogWyAg
ICA0Ljk0NzIxNF0gc2NzaSB0YXJnZXQwOjA6MTogRkFTVC0xNjAgV0lERSBTQ1NJIDMyMC4wIE1C
L3MgRFQgSVUgUlRJICg2LjI1IG5zLCBvZmZzZXQgMTI3KQpEZWMgIDEgMTU6NTU6MjQgR3JpZG9z
X05vZGUga2VybmVsOiBbICAgIDQuOTQ5MTAyXSBzZCAwOjA6MTowOiBbc2RiXSAxNDMzNzQ2NTAg
NTEyLWJ5dGUgbG9naWNhbCBibG9ja3M6ICg3My40IEdCLzY4LjMgR2lCKQpEZWMgIDEgMTU6NTU6
MjUgR3JpZG9zX05vZGUga2VybmVsOiBbICAgIDUuMjA1NDYxXSBzZCAwOjA6MTowOiBbc2RiXSBX
cml0ZSBQcm90ZWN0IGlzIG9mZgpEZWMgIDEgMTU6NTU6MjUgR3JpZG9zX05vZGUga2VybmVsOiBb
ICAgIDUuMjA1NzE3XSAgc2RhOiBzZGExIHNkYTIgc2RhMyBzZGE0IDwgc2RhNSA+CkRlYyAgMSAx
NTo1NToyNiBHcmlkb3NfTm9kZSBrZXJuZWw6IFsgICAgNS40NjIyNzNdIHNkIDA6MDoxOjA6IFtz
ZGJdIFdyaXRlIGNhY2hlOiBkaXNhYmxlZCwgcmVhZCBjYWNoZTogZW5hYmxlZCwgc3VwcG9ydHMg
RFBPIGFuZCBGVUEKRGVjICAxIDE1OjU1OjI3IEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgICA1Ljcy
MTc4MV0gc2QgMDowOjA6MDogW3NkYV0gQXR0YWNoZWQgU0NTSSBkaXNrCkRlYyAgMSAxNTo1NToy
OCBHcmlkb3NfTm9kZSBrZXJuZWw6IFsgICAgNS45NzgzMDNdICBzZGI6IHNkYjEKRGVjICAxIDE1
OjU1OjI4IEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgICA1Ljk4ODYyMF0gc2NzaSAwOjA6NjowOiBQ
cm9jZXNzb3IgICAgICAgICBQRS9QViAgICAxeDIgU0NTSSBCUCAgICAgIDEuMCAgUFE6IDAgQU5T
STogMgpEZWMgIDEgMTU6NTU6MjggR3JpZG9zX05vZGUga2VybmVsOiBbICAgIDUuOTg4NzcxXSBz
Y3NpIHRhcmdldDA6MDo2OiBCZWdpbm5pbmcgRG9tYWluIFZhbGlkYXRpb24KRGVjICAxIDE1OjU1
OjI4IEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgICA1Ljk5MzkxMV0gc2QgMDowOjE6MDogW3NkYl0g
QXR0YWNoZWQgU0NTSSBkaXNrCkRlYyAgMSAxNTo1NToyOCBHcmlkb3NfTm9kZSBrZXJuZWw6IFsg
ICAgNi4wMDk3MzJdIHNjc2kgdGFyZ2V0MDowOjY6IEVuZGluZyBEb21haW4gVmFsaWRhdGlvbgpE
ZWMgIDEgMTU6NTU6MjggR3JpZG9zX05vZGUga2VybmVsOiBbICAgIDYuMDA5OTc4XSBzY3NpIHRh
cmdldDA6MDo2OiBhc3luY2hyb25vdXMKRGVjICAxIDE1OjU1OjI5IEdyaWRvc19Ob2RlIHNtYXJ0
ZFsxOTk3XTogc21hcnRkIHZlcnNpb24gNS4zOCBbaTY4Ni1yZWRoYXQtbGludXgtZ251XSBDb3B5
cmlnaHQgKEMpIDIwMDItOCBCcnVjZSBBbGxlbiAKRGVjICAxIDE1OjU1OjI5IEdyaWRvc19Ob2Rl
IHNtYXJ0ZFsxOTk3XTogSG9tZSBwYWdlIGlzIGh0dHA6Ly9zbWFydG1vbnRvb2xzLnNvdXJjZWZv
cmdlLm5ldC8gIApEZWMgIDEgMTU6NTU6MjkgR3JpZG9zX05vZGUgc21hcnRkWzE5OTddOiBPcGVu
ZWQgY29uZmlndXJhdGlvbiBmaWxlIC9ldGMvc21hcnRkLmNvbmYgCkRlYyAgMSAxNTo1NToyOSBH
cmlkb3NfTm9kZSBzbWFydGRbMTk5N106IENvbmZpZ3VyYXRpb24gZmlsZSAvZXRjL3NtYXJ0ZC5j
b25mIHBhcnNlZC4gCkRlYyAgMSAxNTo1NToyOSBHcmlkb3NfTm9kZSBzbWFydGRbMTk5N106IERl
dmljZTogL2Rldi9zZGEsIG9wZW5lZCAKRGVjICAxIDE1OjU1OjI5IEdyaWRvc19Ob2RlIHNtYXJ0
ZFsxOTk3XTogRGV2aWNlOiAvZGV2L3NkYSwgaXMgU01BUlQgY2FwYWJsZS4gQWRkaW5nIHRvICJt
b25pdG9yIiBsaXN0LiAKRGVjICAxIDE1OjU1OjI5IEdyaWRvc19Ob2RlIHNtYXJ0ZFsxOTk3XTog
RGV2aWNlOiAvZGV2L3NkYiwgb3BlbmVkIApEZWMgIDEgMTU6NTU6MjkgR3JpZG9zX05vZGUgc21h
cnRkWzE5OTddOiBEZXZpY2U6IC9kZXYvc2RiLCBpcyBTTUFSVCBjYXBhYmxlLiBBZGRpbmcgdG8g
Im1vbml0b3IiIGxpc3QuIApEZWMgIDEgMTU6NTU6MjkgR3JpZG9zX05vZGUgc21hcnRkWzE5OTdd
OiBNb25pdG9yaW5nIDAgQVRBIGFuZCAyIFNDU0kgZGV2aWNlcyAKRGVjICAxIDE1OjU1OjMwIEdy
aWRvc19Ob2RlIHNtYXJ0ZFsxOTk5XTogc21hcnRkIGhhcyBmb3JrKCllZCBpbnRvIGJhY2tncm91
bmQgbW9kZS4gTmV3IFBJRD0xOTk5LiAKRGVjICAxIDE1OjU1OjM3IEdyaWRvc19Ob2RlIGtlcm5l
bDogWyAgICA4LjA4ODI5N10gRnVzaW9uIE1QVCBTQVMgSG9zdCBkcml2ZXIgMy4wNC4xOQpEZWMg
IDEgMTU6NTU6MzcgR3JpZG9zX05vZGUga2VybmVsOiBbICAgIDguMTA0NDA4XSBhdGFfcGlpeCAw
MDAwOjAwOjFmLjE6IGVuYWJsaW5nIGRldmljZSAoMDAwNSAtPiAwMDA3KQpEZWMgIDEgMTU6NTU6
MzcgR3JpZG9zX05vZGUga2VybmVsOiBbICAgIDguMTA0NTE0XSBhdGFfcGlpeCAwMDAwOjAwOjFm
LjE6IGNhbid0IGRlcml2ZSByb3V0aW5nIGZvciBQQ0kgSU5UIEEKRGVjICAxIDE1OjU1OjM3IEdy
aWRvc19Ob2RlIGtlcm5lbDogWyAgICA4LjEwNTM0OV0gYXRhX3BpaXggMDAwMDowMDoxZi4xOiBC
TURNQTogZmFpbGVkIHRvIHNldCBkbWEgbWFzaywgZmFsbGluZyBiYWNrIHRvIFBJTwpEZWMgIDEg
MTU6NTU6MzcgR3JpZG9zX05vZGUga2VybmVsOiBbICAgIDguMTA3MTgxXSBzY3NpMSA6IGF0YV9w
aWl4CkRlYyAgMSAxNTo1NTozNyBHcmlkb3NfTm9kZSBrZXJuZWw6IFsgICAgOC4xMDc3NDZdIHNj
c2kyIDogYXRhX3BpaXgKRGVjICAxIDE1OjU1OjM3IEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgICA4
LjEwODA3N10gYXRhMTogUEFUQSBtYXggUElPNCBjbWQgMHgxZjAgY3RsIDB4M2Y2IGJtZG1hIDB4
ZmMwMCBpcnEgMTQKRGVjICAxIDE1OjU1OjM3IEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgICA4LjEw
ODE3M10gYXRhMjogUEFUQSBtYXggUElPNCBjbWQgMHgxNzAgY3RsIDB4Mzc2IGJtZG1hIDB4ZmMw
OCBpcnEgMTUKRGVjICAxIDE1OjU1OjM3IEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgICA4LjI4MDQ0
OF0gYXRhMS4wMDogQVRBUEk6IFBISUxJUFMgRFZELVJPTSBTRFIwODksIFREMzYsIG1heCBVRE1B
LzMzCkRlYyAgMSAxNTo1NTozNyBHcmlkb3NfTm9kZSBrZXJuZWw6IFsgICAgOC4zMDAzMjZdIGF0
YTEuMDA6IGNvbmZpZ3VyZWQgZm9yIFBJTzQKRGVjICAxIDE1OjU1OjM3IEdyaWRvc19Ob2RlIGtl
cm5lbDogWyAgICA4LjMwMjA0OF0gc2NzaSAxOjA6MDowOiBDRC1ST00gICAgICAgICAgICBQSElM
SVBTICBEVkQtUk9NIFNEUjA4OSAgIFREMzYgUFE6IDAgQU5TSTogNQpEZWMgIDEgMTU6NTU6Mzcg
R3JpZG9zX05vZGUga2VybmVsOiBbICAgMTkuNTQ4NjUzXSBFWFQzLWZzOiBiYXJyaWVycyBub3Qg
ZW5hYmxlZApEZWMgIDEgMTU6NTU6MzcgR3JpZG9zX05vZGUga2VybmVsOiBbICAgMTkuNTY3NTI2
XSBram91cm5hbGQgc3RhcnRpbmcuICBDb21taXQgaW50ZXJ2YWwgNSBzZWNvbmRzCkRlYyAgMSAx
NTo1NTozNyBHcmlkb3NfTm9kZSBrZXJuZWw6IFsgICAxOS41Njc2NTddIEVYVDMtZnMgKHNkYTMp
OiBtb3VudGVkIGZpbGVzeXN0ZW0gd2l0aCBvcmRlcmVkIGRhdGEgbW9kZQpEZWMgIDEgMTU6NTU6
MzcgR3JpZG9zX05vZGUga2VybmVsOiBbICAgMjIuMTIxMDQwXSBpbnB1dDogUEMgU3BlYWtlciBh
cyAvZGV2aWNlcy9wbGF0Zm9ybS9wY3Nwa3IvaW5wdXQvaW5wdXQyCkRlYyAgMSAxNTo1NTozNyBH
cmlkb3NfTm9kZSBrZXJuZWw6IFsgICAyMi4yMDA1ODhdIHBhdGFfYWNwaSAwMDAwOjA5OjA2LjA6
IFBDSSBJTlQgQSAtPiBHU0kgMjMgKGxldmVsLCBsb3cpIC0+IElSUSAyMwpEZWMgIDEgMTU6NTU6
MzcgR3JpZG9zX05vZGUga2VybmVsOiBbICAgMjIuMjAwODUxXSBwYXRhX2FjcGkgMDAwMDowOTow
Ni4wOiBCTURNQTogZmFpbGVkIHRvIHNldCBkbWEgbWFzaywgZmFsbGluZyBiYWNrIHRvIFBJTwpE
ZWMgIDEgMTU6NTU6MzcgR3JpZG9zX05vZGUga2VybmVsOiBbICAgMjIuMjAxMDA0XSBwYXRhX2Fj
cGkgMDAwMDowOTowNi4wOiBQQ0kgSU5UIEEgZGlzYWJsZWQKRGVjICAxIDE1OjU1OjM3IEdyaWRv
c19Ob2RlIGtlcm5lbDogWyAgIDIyLjIxNzIwOV0gaVRDT192ZW5kb3Jfc3VwcG9ydDogdmVuZG9y
LXN1cHBvcnQ9MApEZWMgIDEgMTU6NTU6MzcgR3JpZG9zX05vZGUga2VybmVsOiBbICAgMjIuMjI0
NjA2XSBpVENPX3dkdDogSW50ZWwgVENPIFdhdGNoRG9nIFRpbWVyIERyaXZlciB2MS4wNgpEZWMg
IDEgMTU6NTU6MzcgR3JpZG9zX05vZGUga2VybmVsOiBbICAgMjIuMjI1MDEyXSBpVENPX3dkdDog
Rm91bmQgYSBJQ0g1IG9yIElDSDVSIFRDTyBkZXZpY2UgKFZlcnNpb249MSwgVENPQkFTRT0weDA4
NjApCkRlYyAgMSAxNTo1NTozNyBHcmlkb3NfTm9kZSBrZXJuZWw6IFsgICAyMi4yMjUyODBdIGlU
Q09fd2R0OiBpbml0aWFsaXplZC4gaGVhcnRiZWF0PTMwIHNlYyAobm93YXlvdXQ9MSkKRGVjICAx
IDE1OjU1OjM3IEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgIDIyLjI0NjUyMV0geGVuX21hcF9waXJx
X2dzaTogcmV0dXJuaW5nIGlycSAyMyBmb3IgZ3NpIDIzCkRlYyAgMSAxNTo1NTozOCBHcmlkb3Nf
Tm9kZSBrZXJuZWw6IFsgICAyMi4yNDY1NDVdIEFscmVhZHkgc2V0dXAgdGhlIEdTSSA6MjMKRGVj
ICAxIDE1OjU1OjM4IEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgIDIyLjI0NjU1Nl0gcGF0YV9zaWw2
ODAgMDAwMDowOTowNi4wOiBQQ0kgSU5UIEEgLT4gR1NJIDIzIChsZXZlbCwgbG93KSAtPiBJUlEg
MjMKRGVjICAxIDE1OjU1OjM4IEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgIDIyLjI0NjY1Ml0gc2ls
NjgwOiAxMzNNSHogY2xvY2suCkRlYyAgMSAxNTo1NTozOCBHcmlkb3NfTm9kZSBrZXJuZWw6IFsg
ICAyMi4yNDY4NDddIHBhdGFfc2lsNjgwIDAwMDA6MDk6MDYuMDogQk1ETUE6IGZhaWxlZCB0byBz
ZXQgZG1hIG1hc2ssIGZhbGxpbmcgYmFjayB0byBQSU8KRGVjICAxIDE1OjU1OjM4IEdyaWRvc19O
b2RlIGtlcm5lbDogWyAgIDIyLjI2NTQ4M10gc2NzaTMgOiBwYXRhX3NpbDY4MApEZWMgIDEgMTU6
NTU6MzggR3JpZG9zX05vZGUga2VybmVsOiBbICAgMjIuMjc2ODQ0XSBzY3NpNCA6IHBhdGFfc2ls
NjgwCkRlYyAgMSAxNTo1NTozOCBHcmlkb3NfTm9kZSBrZXJuZWw6IFsgICAyMi4yNzcyMzBdIGF0
YTM6IFBBVEEgbWF4IFBJTzQgY21kIDB4YmNmMCBjdGwgMHhiY2U0IGJtZG1hIDB4YmM3MCBpcnEg
MjMKRGVjICAxIDE1OjU1OjM4IEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgIDIyLjI3NzI0M10gYXRh
NDogUEFUQSBtYXggUElPNCBjbWQgMHhiY2Q4IGN0bCAweGJjZDAgYm1kbWEgMHhiYzc4IGlycSAy
MwpEZWMgIDEgMTU6NTU6MzggR3JpZG9zX05vZGUga2VybmVsOiBbICAgMjIuNDcxNTYxXSBhdGEz
LjAwOiBBVEFQSTogVklSVFVBTEZMT1BQWSBEUklWRSAgICAgICAgICAgICAgIEZsb3BweSwgLCBt
YXggUElPMwpEZWMgIDEgMTU6NTU6MzggR3JpZG9zX05vZGUga2VybmVsOiBbICAgMjIuNDcxNTc5
XSBhdGEzLjAxOiBBVEFQSTogVklSVFVBTENEUk9NIERSSVZFLCAsIG1heCBQSU8zCkRlYyAgMSAx
NTo1NTozOCBHcmlkb3NfTm9kZSBrZXJuZWw6IFsgICAyMi41MDIwMjhdIGF0YTMuMDA6IGNvbmZp
Z3VyZWQgZm9yIFBJTzMKRGVjICAxIDE1OjU1OjM4IEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgIDIy
LjUyMDQ3NV0gYXRhMy4wMTogY29uZmlndXJlZCBmb3IgUElPMwpEZWMgIDEgMTU6NTU6MzggR3Jp
ZG9zX05vZGUga2VybmVsOiBbICAgMjIuNTU0NDY4XSBzY3NpIDM6MDowOjA6IERpcmVjdC1BY2Nl
c3MgICAgIERFTEwgICAgICAgVlNGICAgICAgICAgICAgMDEyMyBQUTogMCBBTlNJOiA1CkRlYyAg
MSAxNTo1NTozOCBHcmlkb3NfTm9kZSBrZXJuZWw6IFsgICAyMi41NjQ1NzVdIHNjc2kgMzowOjE6
MDogQ0QtUk9NICAgICAgICAgICAgREVMTCAgICAgICBWQ0QgICAgICAgICAgICAwMTMzIFBROiAw
IEFOU0k6IDUKRGVjICAxIDE1OjU1OjM4IEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgIDIyLjYwNDY4
NV0gc2QgMzowOjA6MDogW3NkY10gQXR0YWNoZWQgU0NTSSByZW1vdmFibGUgZGlzawpEZWMgIDEg
MTU6NTU6MzggR3JpZG9zX05vZGUga2VybmVsOiBbICAgMjIuNjc1NzU2XSBGREMgMCBpcyBhIE5h
dGlvbmFsIFNlbWljb25kdWN0b3IgUEM4NzMwNgpEZWMgIDEgMTU6NTU6MzggR3JpZG9zX05vZGUg
a2VybmVsOiBbICAgMjIuODU0MDMyXSBpbnB1dDogUG93ZXIgQnV0dG9uIGFzIC9kZXZpY2VzL0xO
WFNZU1RNOjAwL0xOWFBXUkJOOjAwL2lucHV0L2lucHV0MwpEZWMgIDEgMTU6NTU6MzggR3JpZG9z
X05vZGUga2VybmVsOiBbICAgMjIuODU0MDUzXSBBQ1BJOiBQb3dlciBCdXR0b24gW1BXUkZdCkRl
YyAgMSAxNTo1NTozOCBHcmlkb3NfTm9kZSBrZXJuZWw6IFsgICAyMy4yODk0OTldIGUxMDAwOiBJ
bnRlbChSKSBQUk8vMTAwMCBOZXR3b3JrIERyaXZlciAtIHZlcnNpb24gNy4zLjIxLWs4LU5BUEkK
RGVjICAxIDE1OjU1OjM4IEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgIDIzLjI4OTUxM10gZTEwMDA6
IENvcHlyaWdodCAoYykgMTk5OS0yMDA2IEludGVsIENvcnBvcmF0aW9uLgpEZWMgIDEgMTU6NTU6
MzggR3JpZG9zX05vZGUga2VybmVsOiBbICAgMjMuMjg5Njc5XSBlMTAwMCAwMDAwOjA2OjA3LjA6
IFBDSSBJTlQgQSAtPiBHU0kgNjQgKGxldmVsLCBsb3cpIC0+IElSUSA2NApEZWMgIDEgMTU6NTU6
MzggR3JpZG9zX05vZGUga2VybmVsOiBbICAgMjMuMjkwMjY1XSBlMTAwMDogTm8gdXNhYmxlIERN
QSBjb25maWcsIGFib3J0aW5nCkRlYyAgMSAxNTo1NTozOCBHcmlkb3NfTm9kZSBrZXJuZWw6IFsg
ICAyMy4yOTA3MDFdIGUxMDAwIDAwMDA6MDY6MDcuMDogUENJIElOVCBBIGRpc2FibGVkCkRlYyAg
MSAxNTo1NTozOCBHcmlkb3NfTm9kZSBrZXJuZWw6IFsgICAyMy4yOTA3MjddIGUxMDAwOiBwcm9i
ZSBvZiAwMDAwOjA2OjA3LjAgZmFpbGVkIHdpdGggZXJyb3IgLTUKRGVjICAxIDE1OjU1OjM4IEdy
aWRvc19Ob2RlIGtlcm5lbDogWyAgIDIzLjI5MDgxMl0gZTEwMDAgMDAwMDowNzowOC4wOiBQQ0kg
SU5UIEEgLT4gR1NJIDY1IChsZXZlbCwgbG93KSAtPiBJUlEgNjUKRGVjICAxIDE1OjU1OjM4IEdy
aWRvc19Ob2RlIGtlcm5lbDogWyAgIDIzLjI5MTI4NF0gZTEwMDA6IE5vIHVzYWJsZSBETUEgY29u
ZmlnLCBhYm9ydGluZwpEZWMgIDEgMTU6NTU6MzggR3JpZG9zX05vZGUga2VybmVsOiBbICAgMjMu
MjkxNzE2XSBlMTAwMCAwMDAwOjA3OjA4LjA6IFBDSSBJTlQgQSBkaXNhYmxlZApEZWMgIDEgMTU6
NTU6MzggR3JpZG9zX05vZGUga2VybmVsOiBbICAgMjMuMjkxNzM0XSBlMTAwMDogcHJvYmUgb2Yg
MDAwMDowNzowOC4wIGZhaWxlZCB3aXRoIGVycm9yIC01CkRlYyAgMSAxNTo1NTozOCBHcmlkb3Nf
Tm9kZSBrZXJuZWw6IFsgICAzMy4wNDQ3NjJdIHNyMDogc2NzaTMtbW1jIGRyaXZlOiAyNHgvMjR4
IGNkL3J3IHhhL2Zvcm0yIGNkZGEgdHJheQpEZWMgIDEgMTU6NTU6MzggR3JpZG9zX05vZGUga2Vy
bmVsOiBbICAgMzMuMDQ0Nzg3XSBjZHJvbTogVW5pZm9ybSBDRC1ST00gZHJpdmVyIFJldmlzaW9u
OiAzLjIwCkRlYyAgMSAxNTo1NTozOCBHcmlkb3NfTm9kZSBrZXJuZWw6IFsgICAzMy4wODQ5ODhd
IHNyMTogc2NzaS0xIGRyaXZlCkRlYyAgMSAxNTo1NTozOCBHcmlkb3NfTm9kZSBrZXJuZWw6IFsg
ICAzMy4zNjE0NjNdIHNkIDA6MDowOjA6IEF0dGFjaGVkIHNjc2kgZ2VuZXJpYyBzZzAgdHlwZSAw
CkRlYyAgMSAxNTo1NTozOSBHcmlkb3NfTm9kZSBrZXJuZWw6IFsgICAzMy4zNjE2ODZdIHNkIDA6
MDoxOjA6IEF0dGFjaGVkIHNjc2kgZ2VuZXJpYyBzZzEgdHlwZSAwCkRlYyAgMSAxNTo1NTozOSBH
cmlkb3NfTm9kZSBrZXJuZWw6IFsgICAzMy4zNjE5MDddIHNjc2kgMDowOjY6MDogQXR0YWNoZWQg
c2NzaSBnZW5lcmljIHNnMiB0eXBlIDMKRGVjICAxIDE1OjU1OjM5IEdyaWRvc19Ob2RlIGtlcm5l
bDogWyAgIDMzLjM2MjE0MV0gc3IgMTowOjA6MDogQXR0YWNoZWQgc2NzaSBnZW5lcmljIHNnMyB0
eXBlIDUKRGVjICAxIDE1OjU1OjM5IEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgIDMzLjM2MjM3NV0g
c2QgMzowOjA6MDogQXR0YWNoZWQgc2NzaSBnZW5lcmljIHNnNCB0eXBlIDAKRGVjICAxIDE1OjU1
OjM5IEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgIDMzLjM2MjYwMF0gc3IgMzowOjE6MDogQXR0YWNo
ZWQgc2NzaSBnZW5lcmljIHNnNSB0eXBlIDUKRGVjICAxIDE1OjU1OjM5IEdyaWRvc19Ob2RlIGtl
cm5lbDogWyAgIDM0LjI2MTY3OV0gTm9uLXZvbGF0aWxlIG1lbW9yeSBkcml2ZXIgdjEuMwpEZWMg
IDEgMTU6NTU6MzkgR3JpZG9zX05vZGUga2VybmVsOiBbICAgMzQuNjYzMzYzXSBtZDogQXV0b2Rl
dGVjdGluZyBSQUlEIGFycmF5cy4KRGVjICAxIDE1OjU1OjM5IEdyaWRvc19Ob2RlIGtlcm5lbDog
WyAgIDM0LjY2MzM3MV0gbWQ6IFNjYW5uZWQgMCBhbmQgYWRkZWQgMCBkZXZpY2VzLgpEZWMgIDEg
MTU6NTU6MzkgR3JpZG9zX05vZGUga2VybmVsOiBbICAgMzQuNjYzMzc4XSBtZDogYXV0b3J1biAu
Li4KRGVjICAxIDE1OjU1OjM5IEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgIDM0LjY2MzM4M10gbWQ6
IC4uLiBhdXRvcnVuIERPTkUuCkRlYyAgMSAxNTo1NTozOSBHcmlkb3NfTm9kZSBrZXJuZWw6IFsg
ICAzNC43NjEzMDJdIGRldmljZS1tYXBwZXI6IGlvY3RsOiA0LjIwLjAtaW9jdGwgKDIwMTEtMDIt
MDIpIGluaXRpYWxpc2VkOiBkbS1kZXZlbEByZWRoYXQuY29tCkRlYyAgMSAxNTo1NTozOSBHcmlk
b3NfTm9kZSBrZXJuZWw6IFsgICAzNC44MjYyNjZdIGRldmljZS1tYXBwZXI6IG11bHRpcGF0aDog
dmVyc2lvbiAxLjMuMCBsb2FkZWQKRGVjICAxIDE1OjU1OjM5IEdyaWRvc19Ob2RlIGtlcm5lbDog
WyAgIDM1LjEyODU3NF0gbG9vcDogbW9kdWxlIGxvYWRlZApEZWMgIDEgMTU6NTU6MzkgR3JpZG9z
X05vZGUga2VybmVsOiBbICAgMzUuOTI4MjA0XSBFWFQzLWZzIChzZGEzKTogdXNpbmcgaW50ZXJu
YWwgam91cm5hbApEZWMgIDEgMTU6NTU6MzkgR3JpZG9zX05vZGUga2VybmVsOiBbICAgMzYuMDAx
OTE3XSBFWFQzLWZzOiBiYXJyaWVycyBub3QgZW5hYmxlZApEZWMgIDEgMTU6NTU6MzkgR3JpZG9z
X05vZGUga2VybmVsOiBbICAgMzYuMDAyMzU3XSBram91cm5hbGQgc3RhcnRpbmcuICBDb21taXQg
aW50ZXJ2YWwgNSBzZWNvbmRzCkRlYyAgMSAxNTo1NTozOSBHcmlkb3NfTm9kZSBrZXJuZWw6IFsg
ICAzNi4wMDg2ODNdIEVYVDMtZnMgKHNkYTIpOiB1c2luZyBpbnRlcm5hbCBqb3VybmFsCkRlYyAg
MSAxNTo1NTozOSBHcmlkb3NfTm9kZSBrZXJuZWw6IFsgICAzNi4wMDg2OTJdIEVYVDMtZnMgKHNk
YTIpOiBtb3VudGVkIGZpbGVzeXN0ZW0gd2l0aCBvcmRlcmVkIGRhdGEgbW9kZQpEZWMgIDEgMTU6
NTU6MzkgR3JpZG9zX05vZGUga2VybmVsOiBbICAgMzYuMDI0Mjg3XSBFWFQzLWZzOiBiYXJyaWVy
cyBub3QgZW5hYmxlZApEZWMgIDEgMTU6NTU6MzkgR3JpZG9zX05vZGUga2VybmVsOiBbICAgMzYu
MDI0NjkxXSBram91cm5hbGQgc3RhcnRpbmcuICBDb21taXQgaW50ZXJ2YWwgNSBzZWNvbmRzCkRl
YyAgMSAxNTo1NTozOSBHcmlkb3NfTm9kZSBrZXJuZWw6IFsgICAzNi4wMzA2MzddIEVYVDMtZnMg
KGRtLTApOiB1c2luZyBpbnRlcm5hbCBqb3VybmFsCkRlYyAgMSAxNTo1NTozOSBHcmlkb3NfTm9k
ZSBrZXJuZWw6IFsgICAzNi4wMzA2NDZdIEVYVDMtZnMgKGRtLTApOiBtb3VudGVkIGZpbGVzeXN0
ZW0gd2l0aCBvcmRlcmVkIGRhdGEgbW9kZQpEZWMgIDEgMTU6NTU6MzkgR3JpZG9zX05vZGUga2Vy
bmVsOiBbICAgMzYuOTQ0MzgzXSBORVQ6IFJlZ2lzdGVyZWQgcHJvdG9jb2wgZmFtaWx5IDEwCkRl
YyAgMSAxNTo1NTozOSBHcmlkb3NfTm9kZSBrZXJuZWw6IFsgICAzNy4wOTI1OTVdIGlwX3RhYmxl
czogKEMpIDIwMDAtMjAwNiBOZXRmaWx0ZXIgQ29yZSBUZWFtCkRlYyAgMSAxNTo1NTozOSBHcmlk
b3NfTm9kZSBrZXJuZWw6IFsgICA0Mi43OTA0NzddIHdhcm5pbmc6IGBkYnVzLWRhZW1vbicgdXNl
cyAzMi1iaXQgY2FwYWJpbGl0aWVzIChsZWdhY3kgc3VwcG9ydCBpbiB1c2UpCkRlYyAgMSAxNTo1
NTo1OSBHcmlkb3NfTm9kZSBhcHBsb2dpYzogVXNlciByb290IGhhcyBsb2dnZWQgaW50byBhbiBB
cHBMb2dpYyByZXN0cmljdGVkIGFyZWEuCkRlYyAgMSAxNTo1Nzo1MiBHcmlkb3NfTm9kZSBzaHV0
ZG93blsyNTQ4XTogc2h1dHRpbmcgZG93biBmb3Igc3lzdGVtIHJlYm9vdApEZWMgIDEgMTU6NTc6
NTIgR3JpZG9zX05vZGUgaW5pdDogU3dpdGNoaW5nIHRvIHJ1bmxldmVsOiA2CkRlYyAgMSAxNTo1
Nzo1MyBHcmlkb3NfTm9kZSBzbWFydGRbMTk5OV06IHNtYXJ0ZCByZWNlaXZlZCBzaWduYWwgMTU6
IFRlcm1pbmF0ZWQgCkRlYyAgMSAxNTo1Nzo1MyBHcmlkb3NfTm9kZSBzbWFydGRbMTk5OV06IHNt
YXJ0ZCBpcyBleGl0aW5nIChleGl0IHN0YXR1cyAwKSAKRGVjICAxIDE1OjU3OjU0IEdyaWRvc19O
b2RlIGtlcm5lbDogS2VybmVsIGxvZ2dpbmcgKHByb2MpIHN0b3BwZWQuCkRlYyAgMSAxNTo1Nzo1
NCBHcmlkb3NfTm9kZSBrZXJuZWw6IEtlcm5lbCBsb2cgZGFlbW9uIHRlcm1pbmF0aW5nLgpEZWMg
IDEgMTU6NTc6NTYgR3JpZG9zX05vZGUgZXhpdGluZyBvbiBzaWduYWwgMTUK

--_005_3E243B26F475504B9BB0BCC9728B0DA629E16E01USILMS110Acacom_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--_005_3E243B26F475504B9BB0BCC9728B0DA629E16E01USILMS110Acacom_--


From xen-devel-bounces@lists.xensource.com Fri Dec 09 20:21:23 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 20: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.xensource.com>)
	id 1RZ6w3-0005bO-NW; Fri, 09 Dec 2011 20:20:47 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Neal.Taylor@ca.com>) id 1RZ6w0-0005bJ-Lm
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 20:20:45 +0000
X-Env-Sender: Neal.Taylor@ca.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1323461956!56089715!1
X-Originating-IP: [74.125.149.211]
X-SpamReason: No, hits=0.9 required=7.0 tests=BODY_RANDOM_LONG,
	HTML_50_60,HTML_ATTR_UNIQUE,HTML_MESSAGE
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32395 invoked from network); 9 Dec 2011 20:19:19 -0000
Received: from na3sys009aog114.obsmtp.com (HELO na3sys009aog114.obsmtp.com)
	(74.125.149.211)
	by server-9.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 9 Dec 2011 20:19:19 -0000
Received: from USILMS191.ca.com ([141.202.246.45]) (using TLSv1) by
	na3sys009aob114.postini.com ([74.125.148.12]) with SMTP
	ID DSNKTuJtZV14JjFrCEb478Zzi6zSOjnnErqF@postini.com;
	Fri, 09 Dec 2011 12:19:51 PST
Received: from USILMS174.ca.com (141.202.6.24) by USILMS191.ca.com
	(141.202.246.45) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Fri, 9 Dec 2011 15:19:48 -0500
Received: from USILMS110A.ca.com ([169.254.1.109]) by usilms174.ca.com
	([141.202.6.24]) with mapi id 14.01.0289.001;
	Fri, 9 Dec 2011 15:19:48 -0500
From: "Taylor, Neal E" <Neal.Taylor@ca.com>
To: xen-devel <xen-devel@lists.xensource.com>
Thread-Topic: Buffers not reachable by PCI
Thread-Index: Acy2r+Ulg1PsfbmtTl6QVj0jZAx7mw==
Date: Fri, 9 Dec 2011 20:19:47 +0000
Message-ID: <3E243B26F475504B9BB0BCC9728B0DA629E16E01@USILMS110A.ca.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [138.42.46.108]
Content-Type: multipart/mixed;
	boundary="_005_3E243B26F475504B9BB0BCC9728B0DA629E16E01USILMS110Acacom_"
MIME-Version: 1.0
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>, "Kalev,
	Leonid" <Leonid.Kalev@ca.com>, "Dave, Tushar N" <tushar.n.dave@intel.com>
Subject: [Xen-devel] Buffers not reachable by PCI
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--_005_3E243B26F475504B9BB0BCC9728B0DA629E16E01USILMS110Acacom_
Content-Type: multipart/alternative;
	boundary="_000_3E243B26F475504B9BB0BCC9728B0DA629E16E01USILMS110Acacom_"

--_000_3E243B26F475504B9BB0BCC9728B0DA629E16E01USILMS110Acacom_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

We're running 64-bit Xex 4.1.1 and 32-bit Linux 3.0.4 Dom0 (Linux 3.1 shows=
 the same symptom.)

Several PCI drivers are unable to use DMA. Most fallback to using PIO but i=
n two instances the network drivers (e1000 and pcinet32) abort. The same ke=
rnel running on the same hardware without Xen works fine.

Digging through the code, in swiotlb-xen.c I find "DMA_BIT_MASK(32)" (0x000=
00000ffffffff) compared to "xen_virt_to_bus(xen_io_tlb_end - 1)" which reso=
lves to 0x1,20fd,feff. Since the address is larger than the mask, DMA is de=
clared as unsupportable.

In talking with others I hear Linux handles this situation with bounce buff=
ers. Is there a config setting I've missed to enable that for Xen? (Config =
file attached)


Relevant slice of source callback list:
xen_swiotlb_dma_supported (drivers/xen/swiotlb-xen.c: line 591)
dma_supported             (arch/x86/kernel/pci-dma.c: line 199)
dma_set_mask              (arch/x86/kernel/pci-dma.c: line 59)
e1000_probe               (drivers/net/e1000/e1000_main.c: line 986)


Relevant patches:

https://lkml.org/lkml/2011/9/1/100, "[PATCH v2] xen: x86_32: do not enable =
iterrupts when returning from exception in interrupt context"

http://xen.1045712.n5.nabble.com/PATCH-mm-sync-vmalloc-address-space-page-t=
ables-in-alloc-vm-area-td4757995.html "[PATCH] mm: sync vmalloc address spa=
ce page tables in alloc_vm_area()" (this patch was reverted for 3.1 but thi=
s is 3.0.4) and

an additional 2048 NR_IRQS to support (as I understand it) all the virtual =
devices we might support with 50 guests.

Not so relevant patches in md, nbd and loop.

lspci:
00:00.0 Host bridge: Intel Corporation E7520 Memory Controller Hub (rev 09)
00:02.0 PCI bridge: Intel Corporation E7525/E7520/E7320 PCI Express Port A =
(rev 09)
00:04.0 PCI bridge: Intel Corporation E7525/E7520 PCI Express Port B (rev 0=
9)
00:05.0 PCI bridge: Intel Corporation E7520 PCI Express Port B1 (rev 09)
00:06.0 PCI bridge: Intel Corporation E7520 PCI Express Port C (rev 09)
00:1d.0 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB UHCI =
Controller #1 (rev 02)
00:1d.1 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB UHCI =
Controller #2 (rev 02)
00:1d.2 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB UHCI =
Controller #3 (rev 02)
00:1d.7 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB2 EHCI=
 Controller (rev 02)
00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev c2)
00:1f.0 ISA bridge: Intel Corporation 82801EB/ER (ICH5/ICH5R) LPC Interface=
 Bridge (rev 02)
00:1f.1 IDE interface: Intel Corporation 82801EB/ER (ICH5/ICH5R) IDE Contro=
ller (rev 02)
01:00.0 PCI bridge: Intel Corporation 80332 [Dobson] I/O processor (A-Segme=
nt Bridge) (rev 06)
01:00.2 PCI bridge: Intel Corporation 80332 [Dobson] I/O processor (B-Segme=
nt Bridge) (rev 06)
02:05.0 SCSI storage controller: LSI Logic / Symbios Logic 53c1030 PCI-X Fu=
sion-MPT Dual Ultra320 SCSI (rev 08)
05:00.0 PCI bridge: Intel Corporation 6700PXH PCI Express-to-PCI Bridge A (=
rev 09)
05:00.2 PCI bridge: Intel Corporation 6700PXH PCI Express-to-PCI Bridge B (=
rev 09)
06:07.0 Ethernet controller: Intel Corporation 82541GI Gigabit Ethernet Con=
troller (rev 05)
07:08.0 Ethernet controller: Intel Corporation 82541GI Gigabit Ethernet Con=
troller (rev 05)
09:05.0 Class ff00: Dell Remote Access Card 4 Daughter Card
09:05.1 Class ff00: Dell Remote Access Card 4 Daughter Card Virtual UART
09:05.2 Class ff00: Dell Remote Access Card 4 Daughter Card SMIC interface
09:06.0 IDE interface: Silicon Image, Inc. PCI0680 Ultra ATA-133 Host Contr=
oller (rev 02)
09:0d.0 VGA compatible controller: ATI Technologies Inc Radeon RV100 QY [Ra=
deon 7000/VE]

     1  00:00.0 Host bridge: Intel Corporation E7520 Memory Controller Hub =
(rev 09)
     2  00:02.0 PCI bridge: Intel Corporation E7525/E7520/E7320 PCI Express=
 Port A (rev 09)
     3  00:04.0 PCI bridge: Intel Corporation E7525/E7520 PCI Express Port =
B (rev 09)
     4  00:05.0 PCI bridge: Intel Corporation E7520 PCI Express Port B1 (re=
v 09)
     5  00:06.0 PCI bridge: Intel Corporation E7520 PCI Express Port C (rev=
 09)
     6  00:1d.0 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) U=
SB UHCI Controller #1 (rev 02)
     7  00:1d.1 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) U=
SB UHCI Controller #2 (rev 02)
     8  00:1d.2 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) U=
SB UHCI Controller #3 (rev 02)
     9  00:1d.7 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) U=
SB2 EHCI Controller (rev 02)
    10  00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev c2)
    11  00:1f.0 ISA bridge: Intel Corporation 82801EB/ER (ICH5/ICH5R) LPC I=
nterface Bridge (rev 02)
    12  00:1f.1 IDE interface: Intel Corporation 82801EB/ER (ICH5/ICH5R) ID=
E Controller (rev 02)
    13  01:00.0 PCI bridge: Intel Corporation 80332 [Dobson] I/O processor =
(A-Segment Bridge) (rev 06)
    14  01:00.2 PCI bridge: Intel Corporation 80332 [Dobson] I/O processor =
(B-Segment Bridge) (rev 06)
    15  02:05.0 SCSI storage controller: LSI Logic / Symbios Logic 53c1030 =
PCI-X Fusion-MPT Dual Ultra320 SCSI (rev 08)
    16  05:00.0 PCI bridge: Intel Corporation 6700PXH PCI Express-to-PCI Br=
idge A (rev 09)
    17  05:00.2 PCI bridge: Intel Corporation 6700PXH PCI Express-to-PCI Br=
idge B (rev 09)
    18  06:07.0 Ethernet controller: Intel Corporation 82541GI Gigabit Ethe=
rnet Controller (rev 05)
    19  07:08.0 Ethernet controller: Intel Corporation 82541GI Gigabit Ethe=
rnet Controller (rev 05)
    20  09:05.0 Class ff00: Dell Remote Access Card 4 Daughter Card
    21  09:05.1 Class ff00: Dell Remote Access Card 4 Daughter Card Virtual=
 UART
    22  09:05.2 Class ff00: Dell Remote Access Card 4 Daughter Card SMIC in=
terface
    23  09:06.0 IDE interface: Silicon Image, Inc. PCI0680 Ultra ATA-133 Ho=
st Controller (rev 02)
    24  09:0d.0 VGA compatible controller: ATI Technologies Inc Radeon RV10=
0 QY [Radeon 7000/VE]

06:07.0 Ethernet controller: Intel Corporation 82541GI Gigabit Ethernet Con=
troller (rev 05)
        Subsystem: Dell PRO/1000 MT Network Connection
        Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV+ VGASnoop- ParErr-=
 Stepping- SERR+ FastB2B-
        Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=3Dmedium >TAbort- =
<TAbort- <MAbort- >SERR- <PERR-
        Interrupt: pin A routed to IRQ 64
        Region 0: Memory at dfae0000 (32-bit, non-prefetchable) [size=3D128=
K]
        Region 2: I/O ports at dcc0 [size=3D64]
        Capabilities: [dc] Power Management version 2
                Flags: PMEClk- DSI+ D1- D2- AuxCurrent=3D0mA PME(D0+,D1-,D2=
-,D3hot+,D3cold+)
                Status: D0 PME-Enable- DSel=3D0 DScale=3D1 PME-
        Capabilities: [e4] PCI-X non-bridge device
                Command: DPERE- ERO+ RBC=3D512 OST=3D1
                Status: Dev=3D00:00.0 64bit- 133MHz- SCD- USC- DC=3Dsimple =
DMMRBC=3D2048 DMOST=3D1 DMCRS=3D8 RSCEM- 266MHz- 533MHz-

log file attached.

--_000_3E243B26F475504B9BB0BCC9728B0DA629E16E01USILMS110Acacom_
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:x=3D"urn:schemas-microsoft-com:office:excel" xmlns:p=3D"urn:schemas-m=
icrosoft-com:office:powerpoint" xmlns:a=3D"urn:schemas-microsoft-com:office=
:access" xmlns:dt=3D"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s=3D"=
uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs=3D"urn:schemas-microsof=
t-com:rowset" xmlns:z=3D"#RowsetSchema" xmlns:b=3D"urn:schemas-microsoft-co=
m:office:publisher" xmlns:ss=3D"urn:schemas-microsoft-com:office:spreadshee=
t" xmlns:c=3D"urn:schemas-microsoft-com:office:component:spreadsheet" xmlns=
:odc=3D"urn:schemas-microsoft-com:office:odc" xmlns:oa=3D"urn:schemas-micro=
soft-com:office:activation" xmlns:html=3D"http://www.w3.org/TR/REC-html40" =
xmlns:q=3D"http://schemas.xmlsoap.org/soap/envelope/" xmlns:rtc=3D"http://m=
icrosoft.com/officenet/conferencing" xmlns:D=3D"DAV:" xmlns:Repl=3D"http://=
schemas.microsoft.com/repl/" xmlns:mt=3D"http://schemas.microsoft.com/share=
point/soap/meetings/" xmlns:x2=3D"http://schemas.microsoft.com/office/excel=
/2003/xml" xmlns:ppda=3D"http://www.passport.com/NameSpace.xsd" xmlns:ois=
=3D"http://schemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir=3D"http://=
schemas.microsoft.com/sharepoint/soap/directory/" xmlns:ds=3D"http://www.w3=
.org/2000/09/xmldsig#" xmlns:dsp=3D"http://schemas.microsoft.com/sharepoint=
/dsp" xmlns:udc=3D"http://schemas.microsoft.com/data/udc" xmlns:xsd=3D"http=
://www.w3.org/2001/XMLSchema" xmlns:sub=3D"http://schemas.microsoft.com/sha=
repoint/soap/2002/1/alerts/" xmlns:ec=3D"http://www.w3.org/2001/04/xmlenc#"=
 xmlns:sp=3D"http://schemas.microsoft.com/sharepoint/" xmlns:sps=3D"http://=
schemas.microsoft.com/sharepoint/soap/" xmlns:xsi=3D"http://www.w3.org/2001=
/XMLSchema-instance" xmlns:udcs=3D"http://schemas.microsoft.com/data/udc/so=
ap" xmlns:udcxf=3D"http://schemas.microsoft.com/data/udc/xmlfile" xmlns:udc=
p2p=3D"http://schemas.microsoft.com/data/udc/parttopart" xmlns:wf=3D"http:/=
/schemas.microsoft.com/sharepoint/soap/workflow/" xmlns:dsss=3D"http://sche=
mas.microsoft.com/office/2006/digsig-setup" xmlns:dssi=3D"http://schemas.mi=
crosoft.com/office/2006/digsig" xmlns:mdssi=3D"http://schemas.openxmlformat=
s.org/package/2006/digital-signature" xmlns:mver=3D"http://schemas.openxmlf=
ormats.org/markup-compatibility/2006" xmlns:m=3D"http://schemas.microsoft.c=
om/office/2004/12/omml" xmlns:mrels=3D"http://schemas.openxmlformats.org/pa=
ckage/2006/relationships" xmlns:spwp=3D"http://microsoft.com/sharepoint/web=
partpages" xmlns:ex12t=3D"http://schemas.microsoft.com/exchange/services/20=
06/types" xmlns:ex12m=3D"http://schemas.microsoft.com/exchange/services/200=
6/messages" xmlns:pptsl=3D"http://schemas.microsoft.com/sharepoint/soap/Sli=
deLibrary/" xmlns:spsl=3D"http://microsoft.com/webservices/SharePointPortal=
Server/PublishedLinksService" xmlns:Z=3D"urn:schemas-microsoft-com:" xmlns:=
st=3D"&#1;" xmlns=3D"http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3D"Generator" content=3D"Microsoft Word 12 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:"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: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";}
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;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
	{mso-style-priority:99;
	mso-style-link:"Plain Text Char";
	margin:0in;
	margin-bottom:.0001pt;
	font-size:10.5pt;
	font-family:Consolas;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
span.PlainTextChar
	{mso-style-name:"Plain Text Char";
	mso-style-priority:99;
	mso-style-link:"Plain Text";
	font-family:Consolas;}
.MsoChpDefault
	{mso-style-type:export-only;}
@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">We&#8217;re running 64-bit Xex 4.1.1 and 32-bit Linu=
x 3.0.4 Dom0 (Linux 3.1 shows the same symptom.)<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">Several PCI drivers are unable to use DMA. Most fall=
back to using PIO but in two instances the network drivers (e1000 and pcine=
t32) abort. The same kernel running on the same hardware without Xen works =
fine.<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">Digging through the code, in swiotlb-xen.c I find &#=
8220;DMA_BIT_MASK(32)&#8221; (0x00000000ffffffff) compared to &#8220;xen_vi=
rt_to_bus(xen_io_tlb_end - 1)&#8221; which resolves to 0x1,20fd,feff. Since=
 the address is larger than the mask, DMA is declared as unsupportable.<o:p=
></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">In talking with others I hear Linux handles this sit=
uation with bounce buffers. Is there a config setting I&#8217;ve missed to =
enable that for Xen? (Config file attached)<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">Relevant slice of source callback list:<o:p></o:p></=
p>
<p class=3D"MsoNormal"><span style=3D"font-family:&quot;Courier New&quot;">=
xen_swiotlb_dma_supported (drivers/xen/swiotlb-xen.c: line 591)<o:p></o:p><=
/span></p>
<p class=3D"MsoNormal"><span style=3D"font-family:&quot;Courier New&quot;">=
dma_supported&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp; (arch/x86/kernel/pci-dma.c: line 199)<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-family:&quot;Courier New&quot;">=
dma_set_mask&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;(arch/x86/kernel/pci-dma.c: line 59)<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-family:&quot;Courier New&quot;">=
e1000_probe&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp; (drivers/net/e1000/e1000_main.c: line 986)<o:p></o:p><=
/span></p>
<p class=3D"MsoNormal"><span style=3D"font-family:&quot;Courier New&quot;">=
<o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-family:&quot;Courier New&quot;">=
<o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal">Relevant patches:<o:p></o:p></p>
<p class=3D"MsoPlainText"><a href=3D"https://lkml.org/lkml/2011/9/1/100">ht=
tps://lkml.org/lkml/2011/9/1/100</a>, &quot;[PATCH v2] xen: x86_32: do not =
enable iterrupts when returning from exception in interrupt context&quot;<o=
:p></o:p></p>
<p class=3D"MsoPlainText"><a href=3D"http://xen.1045712.n5.nabble.com/PATCH=
-mm-sync-vmalloc-address-space-page-tables-in-alloc-vm-area-td4757995.html"=
>http://xen.1045712.n5.nabble.com/PATCH-mm-sync-vmalloc-address-space-page-=
tables-in-alloc-vm-area-td4757995.html</a>
 &quot;[PATCH] mm: sync vmalloc address space page tables in alloc_vm_area(=
)&quot; (this patch was reverted for 3.1 but this is 3.0.4) and
<o:p></o:p></p>
<p class=3D"MsoPlainText">an additional 2048 NR_IRQS to support (as I under=
stand it) all the virtual devices we might support with 50 guests.<o:p></o:=
p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">Not so relevant patches in md, nbd and loop.<o:p></o=
:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">lspci:<o:p></o:p></p>
<p class=3D"MsoNormal">00:00.0 Host bridge: Intel Corporation E7520 Memory =
Controller Hub (rev 09)<o:p></o:p></p>
<p class=3D"MsoNormal">00:02.0 PCI bridge: Intel Corporation E7525/E7520/E7=
320 PCI Express Port A (rev 09)<o:p></o:p></p>
<p class=3D"MsoNormal">00:04.0 PCI bridge: Intel Corporation E7525/E7520 PC=
I Express Port B (rev 09)<o:p></o:p></p>
<p class=3D"MsoNormal">00:05.0 PCI bridge: Intel Corporation E7520 PCI Expr=
ess Port B1 (rev 09)<o:p></o:p></p>
<p class=3D"MsoNormal">00:06.0 PCI bridge: Intel Corporation E7520 PCI Expr=
ess Port C (rev 09)<o:p></o:p></p>
<p class=3D"MsoNormal">00:1d.0 USB Controller: Intel Corporation 82801EB/ER=
 (ICH5/ICH5R) USB UHCI Controller #1 (rev 02)<o:p></o:p></p>
<p class=3D"MsoNormal">00:1d.1 USB Controller: Intel Corporation 82801EB/ER=
 (ICH5/ICH5R) USB UHCI Controller #2 (rev 02)<o:p></o:p></p>
<p class=3D"MsoNormal">00:1d.2 USB Controller: Intel Corporation 82801EB/ER=
 (ICH5/ICH5R) USB UHCI Controller #3 (rev 02)<o:p></o:p></p>
<p class=3D"MsoNormal">00:1d.7 USB Controller: Intel Corporation 82801EB/ER=
 (ICH5/ICH5R) USB2 EHCI Controller (rev 02)<o:p></o:p></p>
<p class=3D"MsoNormal">00:1e.0 PCI bridge: Intel Corporation 82801 PCI Brid=
ge (rev c2)<o:p></o:p></p>
<p class=3D"MsoNormal">00:1f.0 ISA bridge: Intel Corporation 82801EB/ER (IC=
H5/ICH5R) LPC Interface Bridge (rev 02)<o:p></o:p></p>
<p class=3D"MsoNormal">00:1f.1 IDE interface: Intel Corporation 82801EB/ER =
(ICH5/ICH5R) IDE Controller (rev 02)<o:p></o:p></p>
<p class=3D"MsoNormal">01:00.0 PCI bridge: Intel Corporation 80332 [Dobson]=
 I/O processor (A-Segment Bridge) (rev 06)<o:p></o:p></p>
<p class=3D"MsoNormal">01:00.2 PCI bridge: Intel Corporation 80332 [Dobson]=
 I/O processor (B-Segment Bridge) (rev 06)<o:p></o:p></p>
<p class=3D"MsoNormal">02:05.0 SCSI storage controller: LSI Logic / Symbios=
 Logic 53c1030 PCI-X Fusion-MPT Dual Ultra320 SCSI (rev 08)<o:p></o:p></p>
<p class=3D"MsoNormal">05:00.0 PCI bridge: Intel Corporation 6700PXH PCI Ex=
press-to-PCI Bridge A (rev 09)<o:p></o:p></p>
<p class=3D"MsoNormal">05:00.2 PCI bridge: Intel Corporation 6700PXH PCI Ex=
press-to-PCI Bridge B (rev 09)<o:p></o:p></p>
<p class=3D"MsoNormal">06:07.0 Ethernet controller: Intel Corporation 82541=
GI Gigabit Ethernet Controller (rev 05)<o:p></o:p></p>
<p class=3D"MsoNormal">07:08.0 Ethernet controller: Intel Corporation 82541=
GI Gigabit Ethernet Controller (rev 05)<o:p></o:p></p>
<p class=3D"MsoNormal">09:05.0 Class ff00: Dell Remote Access Card 4 Daught=
er Card<o:p></o:p></p>
<p class=3D"MsoNormal">09:05.1 Class ff00: Dell Remote Access Card 4 Daught=
er Card Virtual UART<o:p></o:p></p>
<p class=3D"MsoNormal">09:05.2 Class ff00: Dell Remote Access Card 4 Daught=
er Card SMIC interface<o:p></o:p></p>
<p class=3D"MsoNormal">09:06.0 IDE interface: Silicon Image, Inc. PCI0680 U=
ltra ATA-133 Host Controller (rev 02)<o:p></o:p></p>
<p class=3D"MsoNormal">09:0d.0 VGA compatible controller: ATI Technologies =
Inc Radeon RV100 QY [Radeon 7000/VE]<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">&nbsp;&nbsp;&nbsp;&nbsp; 1&nbsp; 00:00.0 Host bridge=
: Intel Corporation E7520 Memory Controller Hub (rev 09)<o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;&nbsp;&nbsp;&nbsp; 2&nbsp; 00:02.0 PCI bridge:=
 Intel Corporation E7525/E7520/E7320 PCI Express Port A (rev 09)<o:p></o:p>=
</p>
<p class=3D"MsoNormal">&nbsp;&nbsp;&nbsp;&nbsp; 3&nbsp; 00:04.0 PCI bridge:=
 Intel Corporation E7525/E7520 PCI Express Port B (rev 09)<o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;&nbsp;&nbsp;&nbsp; 4&nbsp; 00:05.0 PCI bridge:=
 Intel Corporation E7520 PCI Express Port B1 (rev 09)<o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;&nbsp;&nbsp;&nbsp; 5&nbsp; 00:06.0 PCI bridge:=
 Intel Corporation E7520 PCI Express Port C (rev 09)<o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;&nbsp;&nbsp;&nbsp; 6&nbsp; 00:1d.0 USB Control=
ler: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB UHCI Controller #1 (rev =
02)<o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;&nbsp;&nbsp;&nbsp; 7&nbsp; 00:1d.1 USB Control=
ler: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB UHCI Controller #2 (rev =
02)<o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;&nbsp;&nbsp;&nbsp; 8&nbsp; 00:1d.2 USB Control=
ler: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB UHCI Controller #3 (rev =
02)<o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;&nbsp;&nbsp;&nbsp; 9&nbsp; 00:1d.7 USB Control=
ler: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB2 EHCI Controller (rev 02=
)<o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;&nbsp;&nbsp; 10&nbsp; 00:1e.0 PCI bridge: Inte=
l Corporation 82801 PCI Bridge (rev c2)<o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;&nbsp;&nbsp; 11&nbsp; 00:1f.0 ISA bridge: Inte=
l Corporation 82801EB/ER (ICH5/ICH5R) LPC Interface Bridge (rev 02)<o:p></o=
:p></p>
<p class=3D"MsoNormal">&nbsp;&nbsp;&nbsp; 12&nbsp; 00:1f.1 IDE interface: I=
ntel Corporation 82801EB/ER (ICH5/ICH5R) IDE Controller (rev 02)<o:p></o:p>=
</p>
<p class=3D"MsoNormal">&nbsp;&nbsp;&nbsp; 13&nbsp; 01:00.0 PCI bridge: Inte=
l Corporation 80332 [Dobson] I/O processor (A-Segment Bridge) (rev 06)<o:p>=
</o:p></p>
<p class=3D"MsoNormal">&nbsp;&nbsp;&nbsp; 14&nbsp; 01:00.2 PCI bridge: Inte=
l Corporation 80332 [Dobson] I/O processor (B-Segment Bridge) (rev 06)<o:p>=
</o:p></p>
<p class=3D"MsoNormal">&nbsp;&nbsp;&nbsp; 15&nbsp; 02:05.0 SCSI storage con=
troller: LSI Logic / Symbios Logic 53c1030 PCI-X Fusion-MPT Dual Ultra320 S=
CSI (rev 08)<o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;&nbsp;&nbsp; 16 &nbsp;05:00.0 PCI bridge: Inte=
l Corporation 6700PXH PCI Express-to-PCI Bridge A (rev 09)<o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;&nbsp;&nbsp; 17&nbsp; 05:00.2 PCI bridge: Inte=
l Corporation 6700PXH PCI Express-to-PCI Bridge B (rev 09)<o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;&nbsp;&nbsp; 18&nbsp; 06:07.0 Ethernet control=
ler: Intel Corporation 82541GI Gigabit Ethernet Controller (rev 05)<o:p></o=
:p></p>
<p class=3D"MsoNormal">&nbsp;&nbsp;&nbsp; 19&nbsp; 07:08.0 Ethernet control=
ler: Intel Corporation 82541GI Gigabit Ethernet Controller (rev 05)<o:p></o=
:p></p>
<p class=3D"MsoNormal">&nbsp;&nbsp;&nbsp; 20&nbsp; 09:05.0 Class ff00: Dell=
 Remote Access Card 4 Daughter Card<o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;&nbsp;&nbsp; 21&nbsp; 09:05.1 Class ff00: Dell=
 Remote Access Card 4 Daughter Card Virtual UART<o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;&nbsp;&nbsp; 22&nbsp; 09:05.2 Class ff00: Dell=
 Remote Access Card 4 Daughter Card SMIC interface<o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;&nbsp;&nbsp; 23&nbsp; 09:06.0 IDE interface: S=
ilicon Image, Inc. PCI0680 Ultra ATA-133 Host Controller (rev 02)<o:p></o:p=
></p>
<p class=3D"MsoNormal">&nbsp;&nbsp;&nbsp; 24&nbsp; 09:0d.0 VGA compatible c=
ontroller: ATI Technologies Inc Radeon RV100 QY [Radeon 7000/VE]<o:p></o:p>=
</p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">06:07.0 Ethernet controller: Intel Corporation 82541=
GI Gigabit Ethernet Controller (rev 05)<o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Subsystem=
: Dell PRO/1000 MT Network Connection<o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Control: =
I/O&#43; Mem&#43; BusMaster- SpecCycle- MemWINV&#43; VGASnoop- ParErr- Step=
ping- SERR&#43; FastB2B-<o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Status: C=
ap&#43; 66MHz&#43; UDF- FastB2B- ParErr- DEVSEL=3Dmedium &gt;TAbort- &lt;TA=
bort- &lt;MAbort- &gt;SERR- &lt;PERR-<o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Interrupt=
: pin A routed to IRQ 64<o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Region 0:=
 Memory at dfae0000 (32-bit, non-prefetchable) [size=3D128K]<o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;Region 2:=
 I/O ports at dcc0 [size=3D64]<o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Capabilit=
ies: [dc] Power Management version 2<o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Flags: PMEClk- DSI&#43; D1- D2- AuxC=
urrent=3D0mA PME(D0&#43;,D1-,D2-,D3hot&#43;,D3cold&#43;)<o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Status: D0 PME-Enable- DSel=3D0 DSca=
le=3D1 PME-<o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Capabilit=
ies: [e4] PCI-X non-bridge device<o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Command: DPERE- ERO&#43; RBC=3D512 O=
ST=3D1<o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Status: Dev=3D00:00.0 64bit- 133MHz-=
 SCD- USC- DC=3Dsimple DMMRBC=3D2048 DMOST=3D1 DMCRS=3D8 RSCEM- 266MHz- 533=
MHz-<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">log file attached.<o:p></o:p></p>
</div>
</body>
</html>

--_000_3E243B26F475504B9BB0BCC9728B0DA629E16E01USILMS110Acacom_--

--_005_3E243B26F475504B9BB0BCC9728B0DA629E16E01USILMS110Acacom_
Content-Type: application/octet-stream; name="config-xen0.i386"
Content-Description: config-xen0.i386
Content-Disposition: attachment; filename="config-xen0.i386"; size=59186;
	creation-date="Fri, 09 Dec 2011 19:18:26 GMT";
	modification-date="Fri, 09 Dec 2011 19:16:35 GMT"
Content-Transfer-Encoding: base64

IwojIEF1dG9tYXRpY2FsbHkgZ2VuZXJhdGVkIG1ha2UgY29uZmlnOiBkb24ndCBlZGl0CiMgTGlu
dXgvaTM4NiAzLjAuNC0zMi54ZW4wIEtlcm5lbCBDb25maWd1cmF0aW9uCiMKIyBDT05GSUdfNjRC
SVQgaXMgbm90IHNldApDT05GSUdfWDg2XzMyPXkKIyBDT05GSUdfWDg2XzY0IGlzIG5vdCBzZXQK
Q09ORklHX1g4Nj15CkNPTkZJR19JTlNUUlVDVElPTl9ERUNPREVSPXkKQ09ORklHX09VVFBVVF9G
T1JNQVQ9ImVsZjMyLWkzODYiCkNPTkZJR19BUkNIX0RFRkNPTkZJRz0iYXJjaC94ODYvY29uZmln
cy9pMzg2X2RlZmNvbmZpZyIKQ09ORklHX0dFTkVSSUNfQ01PU19VUERBVEU9eQpDT05GSUdfQ0xP
Q0tTT1VSQ0VfV0FUQ0hET0c9eQpDT05GSUdfR0VORVJJQ19DTE9DS0VWRU5UUz15CkNPTkZJR19H
RU5FUklDX0NMT0NLRVZFTlRTX0JST0FEQ0FTVD15CkNPTkZJR19MT0NLREVQX1NVUFBPUlQ9eQpD
T05GSUdfU1RBQ0tUUkFDRV9TVVBQT1JUPXkKQ09ORklHX0hBVkVfTEFURU5DWVRPUF9TVVBQT1JU
PXkKQ09ORklHX01NVT15CkNPTkZJR19aT05FX0RNQT15CiMgQ09ORklHX05FRURfRE1BX01BUF9T
VEFURSBpcyBub3Qgc2V0CkNPTkZJR19ORUVEX1NHX0RNQV9MRU5HVEg9eQpDT05GSUdfR0VORVJJ
Q19JU0FfRE1BPXkKQ09ORklHX0dFTkVSSUNfSU9NQVA9eQpDT05GSUdfR0VORVJJQ19CVUc9eQpD
T05GSUdfR0VORVJJQ19IV0VJR0hUPXkKQ09ORklHX0FSQ0hfTUFZX0hBVkVfUENfRkRDPXkKIyBD
T05GSUdfUldTRU1fR0VORVJJQ19TUElOTE9DSyBpcyBub3Qgc2V0CkNPTkZJR19SV1NFTV9YQ0hH
QUREX0FMR09SSVRITT15CkNPTkZJR19BUkNIX0hBU19DUFVfSURMRV9XQUlUPXkKQ09ORklHX0dF
TkVSSUNfQ0FMSUJSQVRFX0RFTEFZPXkKIyBDT05GSUdfR0VORVJJQ19USU1FX1ZTWVNDQUxMIGlz
IG5vdCBzZXQKQ09ORklHX0FSQ0hfSEFTX0NQVV9SRUxBWD15CkNPTkZJR19BUkNIX0hBU19ERUZB
VUxUX0lETEU9eQpDT05GSUdfQVJDSF9IQVNfQ0FDSEVfTElORV9TSVpFPXkKQ09ORklHX0hBVkVf
U0VUVVBfUEVSX0NQVV9BUkVBPXkKQ09ORklHX05FRURfUEVSX0NQVV9FTUJFRF9GSVJTVF9DSFVO
Sz15CkNPTkZJR19ORUVEX1BFUl9DUFVfUEFHRV9GSVJTVF9DSFVOSz15CiMgQ09ORklHX0hBVkVf
Q1BVTUFTS19PRl9DUFVfTUFQIGlzIG5vdCBzZXQKQ09ORklHX0FSQ0hfSElCRVJOQVRJT05fUE9T
U0lCTEU9eQpDT05GSUdfQVJDSF9TVVNQRU5EX1BPU1NJQkxFPXkKIyBDT05GSUdfWk9ORV9ETUEz
MiBpcyBub3Qgc2V0CkNPTkZJR19BUkNIX1BPUFVMQVRFU19OT0RFX01BUD15CiMgQ09ORklHX0FV
RElUX0FSQ0ggaXMgbm90IHNldApDT05GSUdfQVJDSF9TVVBQT1JUU19PUFRJTUlaRURfSU5MSU5J
Tkc9eQpDT05GSUdfQVJDSF9TVVBQT1JUU19ERUJVR19QQUdFQUxMT0M9eQpDT05GSUdfWDg2XzMy
X1NNUD15CkNPTkZJR19YODZfSFQ9eQpDT05GSUdfWDg2XzMyX0xBWllfR1M9eQpDT05GSUdfQVJD
SF9IV0VJR0hUX0NGTEFHUz0iLWZjYWxsLXNhdmVkLWVjeCAtZmNhbGwtc2F2ZWQtZWR4IgpDT05G
SUdfS1RJTUVfU0NBTEFSPXkKQ09ORklHX0FSQ0hfQ1BVX1BST0JFX1JFTEVBU0U9eQpDT05GSUdf
REVGQ09ORklHX0xJU1Q9Ii9saWIvbW9kdWxlcy8kVU5BTUVfUkVMRUFTRS8uY29uZmlnIgpDT05G
SUdfSEFWRV9JUlFfV09SSz15CkNPTkZJR19JUlFfV09SSz15CgojCiMgR2VuZXJhbCBzZXR1cAoj
CkNPTkZJR19FWFBFUklNRU5UQUw9eQpDT05GSUdfSU5JVF9FTlZfQVJHX0xJTUlUPTMyCkNPTkZJ
R19DUk9TU19DT01QSUxFPSIiCkNPTkZJR19MT0NBTFZFUlNJT049IiIKIyBDT05GSUdfTE9DQUxW
RVJTSU9OX0FVVE8gaXMgbm90IHNldApDT05GSUdfSEFWRV9LRVJORUxfR1pJUD15CkNPTkZJR19I
QVZFX0tFUk5FTF9CWklQMj15CkNPTkZJR19IQVZFX0tFUk5FTF9MWk1BPXkKQ09ORklHX0hBVkVf
S0VSTkVMX1haPXkKQ09ORklHX0hBVkVfS0VSTkVMX0xaTz15CkNPTkZJR19LRVJORUxfR1pJUD15
CiMgQ09ORklHX0tFUk5FTF9CWklQMiBpcyBub3Qgc2V0CiMgQ09ORklHX0tFUk5FTF9MWk1BIGlz
IG5vdCBzZXQKIyBDT05GSUdfS0VSTkVMX1haIGlzIG5vdCBzZXQKIyBDT05GSUdfS0VSTkVMX0xa
TyBpcyBub3Qgc2V0CkNPTkZJR19ERUZBVUxUX0hPU1ROQU1FPSIobm9uZSkiCkNPTkZJR19TV0FQ
PXkKQ09ORklHX1NZU1ZJUEM9eQpDT05GSUdfU1lTVklQQ19TWVNDVEw9eQojIENPTkZJR19QT1NJ
WF9NUVVFVUUgaXMgbm90IHNldAojIENPTkZJR19CU0RfUFJPQ0VTU19BQ0NUIGlzIG5vdCBzZXQK
IyBDT05GSUdfRkhBTkRMRSBpcyBub3Qgc2V0CiMgQ09ORklHX1RBU0tTVEFUUyBpcyBub3Qgc2V0
CiMgQ09ORklHX0FVRElUIGlzIG5vdCBzZXQKQ09ORklHX0hBVkVfR0VORVJJQ19IQVJESVJRUz15
CgojCiMgSVJRIHN1YnN5c3RlbQojCkNPTkZJR19HRU5FUklDX0hBUkRJUlFTPXkKQ09ORklHX0hB
VkVfU1BBUlNFX0lSUT15CkNPTkZJR19HRU5FUklDX0lSUV9QUk9CRT15CkNPTkZJR19HRU5FUklD
X0lSUV9TSE9XPXkKQ09ORklHX0dFTkVSSUNfUEVORElOR19JUlE9eQpDT05GSUdfSVJRX0ZPUkNF
RF9USFJFQURJTkc9eQojIENPTkZJR19TUEFSU0VfSVJRIGlzIG5vdCBzZXQKCiMKIyBSQ1UgU3Vi
c3lzdGVtCiMKQ09ORklHX1RSRUVfUkNVPXkKIyBDT05GSUdfUFJFRU1QVF9SQ1UgaXMgbm90IHNl
dAojIENPTkZJR19SQ1VfVFJBQ0UgaXMgbm90IHNldApDT05GSUdfUkNVX0ZBTk9VVD0zMgojIENP
TkZJR19SQ1VfRkFOT1VUX0VYQUNUIGlzIG5vdCBzZXQKIyBDT05GSUdfUkNVX0ZBU1RfTk9fSFog
aXMgbm90IHNldAojIENPTkZJR19UUkVFX1JDVV9UUkFDRSBpcyBub3Qgc2V0CiMgQ09ORklHX0lL
Q09ORklHIGlzIG5vdCBzZXQKQ09ORklHX0xPR19CVUZfU0hJRlQ9MTcKQ09ORklHX0hBVkVfVU5T
VEFCTEVfU0NIRURfQ0xPQ0s9eQojIENPTkZJR19DR1JPVVBTIGlzIG5vdCBzZXQKQ09ORklHX05B
TUVTUEFDRVM9eQojIENPTkZJR19VVFNfTlMgaXMgbm90IHNldApDT05GSUdfSVBDX05TPXkKIyBD
T05GSUdfVVNFUl9OUyBpcyBub3Qgc2V0CiMgQ09ORklHX1BJRF9OUyBpcyBub3Qgc2V0CkNPTkZJ
R19ORVRfTlM9eQojIENPTkZJR19TQ0hFRF9BVVRPR1JPVVAgaXMgbm90IHNldApDT05GSUdfU1lT
RlNfREVQUkVDQVRFRD15CkNPTkZJR19TWVNGU19ERVBSRUNBVEVEX1YyPXkKIyBDT05GSUdfUkVM
QVkgaXMgbm90IHNldApDT05GSUdfQkxLX0RFVl9JTklUUkQ9eQpDT05GSUdfSU5JVFJBTUZTX1NP
VVJDRT0iIgpDT05GSUdfUkRfR1pJUD15CkNPTkZJR19SRF9CWklQMj15CiMgQ09ORklHX1JEX0xa
TUEgaXMgbm90IHNldAojIENPTkZJR19SRF9YWiBpcyBub3Qgc2V0CiMgQ09ORklHX1JEX0xaTyBp
cyBub3Qgc2V0CiMgQ09ORklHX0NDX09QVElNSVpFX0ZPUl9TSVpFIGlzIG5vdCBzZXQKQ09ORklH
X1NZU0NUTD15CkNPTkZJR19BTk9OX0lOT0RFUz15CkNPTkZJR19FWFBFUlQ9eQpDT05GSUdfVUlE
MTY9eQpDT05GSUdfU1lTQ1RMX1NZU0NBTEw9eQpDT05GSUdfS0FMTFNZTVM9eQpDT05GSUdfSE9U
UExVRz15CkNPTkZJR19QUklOVEs9eQpDT05GSUdfQlVHPXkKQ09ORklHX0VMRl9DT1JFPXkKQ09O
RklHX1BDU1BLUl9QTEFURk9STT15CkNPTkZJR19CQVNFX0ZVTEw9eQpDT05GSUdfRlVURVg9eQpD
T05GSUdfRVBPTEw9eQpDT05GSUdfU0lHTkFMRkQ9eQpDT05GSUdfVElNRVJGRD15CkNPTkZJR19F
VkVOVEZEPXkKQ09ORklHX1NITUVNPXkKQ09ORklHX0FJTz15CiMgQ09ORklHX0VNQkVEREVEIGlz
IG5vdCBzZXQKQ09ORklHX0hBVkVfUEVSRl9FVkVOVFM9eQoKIwojIEtlcm5lbCBQZXJmb3JtYW5j
ZSBFdmVudHMgQW5kIENvdW50ZXJzCiMKQ09ORklHX1BFUkZfRVZFTlRTPXkKIyBDT05GSUdfUEVS
Rl9DT1VOVEVSUyBpcyBub3Qgc2V0CkNPTkZJR19WTV9FVkVOVF9DT1VOVEVSUz15CkNPTkZJR19Q
Q0lfUVVJUktTPXkKIyBDT05GSUdfQ09NUEFUX0JSSyBpcyBub3Qgc2V0CkNPTkZJR19TTEFCPXkK
IyBDT05GSUdfU0xVQiBpcyBub3Qgc2V0CiMgQ09ORklHX1NMT0IgaXMgbm90IHNldAojIENPTkZJ
R19QUk9GSUxJTkcgaXMgbm90IHNldApDT05GSUdfSEFWRV9PUFJPRklMRT15CiMgQ09ORklHX0tQ
Uk9CRVMgaXMgbm90IHNldAojIENPTkZJR19KVU1QX0xBQkVMIGlzIG5vdCBzZXQKQ09ORklHX0hB
VkVfRUZGSUNJRU5UX1VOQUxJR05FRF9BQ0NFU1M9eQpDT05GSUdfSEFWRV9JT1JFTUFQX1BST1Q9
eQpDT05GSUdfSEFWRV9LUFJPQkVTPXkKQ09ORklHX0hBVkVfS1JFVFBST0JFUz15CkNPTkZJR19I
QVZFX09QVFBST0JFUz15CkNPTkZJR19IQVZFX0FSQ0hfVFJBQ0VIT09LPXkKQ09ORklHX0hBVkVf
RE1BX0FUVFJTPXkKQ09ORklHX1VTRV9HRU5FUklDX1NNUF9IRUxQRVJTPXkKQ09ORklHX0hBVkVf
UkVHU19BTkRfU1RBQ0tfQUNDRVNTX0FQST15CkNPTkZJR19IQVZFX0RNQV9BUElfREVCVUc9eQpD
T05GSUdfSEFWRV9IV19CUkVBS1BPSU5UPXkKQ09ORklHX0hBVkVfTUlYRURfQlJFQUtQT0lOVFNf
UkVHUz15CkNPTkZJR19IQVZFX1VTRVJfUkVUVVJOX05PVElGSUVSPXkKQ09ORklHX0hBVkVfUEVS
Rl9FVkVOVFNfTk1JPXkKQ09ORklHX0hBVkVfQVJDSF9KVU1QX0xBQkVMPXkKCiMKIyBHQ09WLWJh
c2VkIGtlcm5lbCBwcm9maWxpbmcKIwpDT05GSUdfSEFWRV9HRU5FUklDX0RNQV9DT0hFUkVOVD15
CkNPTkZJR19TTEFCSU5GTz15CkNPTkZJR19SVF9NVVRFWEVTPXkKQ09ORklHX0JBU0VfU01BTEw9
MApDT05GSUdfTU9EVUxFUz15CiMgQ09ORklHX01PRFVMRV9GT1JDRV9MT0FEIGlzIG5vdCBzZXQK
Q09ORklHX01PRFVMRV9VTkxPQUQ9eQojIENPTkZJR19NT0RVTEVfRk9SQ0VfVU5MT0FEIGlzIG5v
dCBzZXQKQ09ORklHX01PRFZFUlNJT05TPXkKIyBDT05GSUdfTU9EVUxFX1NSQ1ZFUlNJT05fQUxM
IGlzIG5vdCBzZXQKQ09ORklHX1NUT1BfTUFDSElORT15CkNPTkZJR19CTE9DSz15CkNPTkZJR19M
QkRBRj15CkNPTkZJR19CTEtfREVWX0JTRz15CiMgQ09ORklHX0JMS19ERVZfSU5URUdSSVRZIGlz
IG5vdCBzZXQKCiMKIyBJTyBTY2hlZHVsZXJzCiMKQ09ORklHX0lPU0NIRURfTk9PUD15CkNPTkZJ
R19JT1NDSEVEX0RFQURMSU5FPXkKQ09ORklHX0lPU0NIRURfQ0ZRPXkKIyBDT05GSUdfREVGQVVM
VF9ERUFETElORSBpcyBub3Qgc2V0CkNPTkZJR19ERUZBVUxUX0NGUT15CiMgQ09ORklHX0RFRkFV
TFRfTk9PUCBpcyBub3Qgc2V0CkNPTkZJR19ERUZBVUxUX0lPU0NIRUQ9ImNmcSIKIyBDT05GSUdf
SU5MSU5FX1NQSU5fVFJZTE9DSyBpcyBub3Qgc2V0CiMgQ09ORklHX0lOTElORV9TUElOX1RSWUxP
Q0tfQkggaXMgbm90IHNldAojIENPTkZJR19JTkxJTkVfU1BJTl9MT0NLIGlzIG5vdCBzZXQKIyBD
T05GSUdfSU5MSU5FX1NQSU5fTE9DS19CSCBpcyBub3Qgc2V0CiMgQ09ORklHX0lOTElORV9TUElO
X0xPQ0tfSVJRIGlzIG5vdCBzZXQKIyBDT05GSUdfSU5MSU5FX1NQSU5fTE9DS19JUlFTQVZFIGlz
IG5vdCBzZXQKQ09ORklHX0lOTElORV9TUElOX1VOTE9DSz15CiMgQ09ORklHX0lOTElORV9TUElO
X1VOTE9DS19CSCBpcyBub3Qgc2V0CkNPTkZJR19JTkxJTkVfU1BJTl9VTkxPQ0tfSVJRPXkKIyBD
T05GSUdfSU5MSU5FX1NQSU5fVU5MT0NLX0lSUVJFU1RPUkUgaXMgbm90IHNldAojIENPTkZJR19J
TkxJTkVfUkVBRF9UUllMT0NLIGlzIG5vdCBzZXQKIyBDT05GSUdfSU5MSU5FX1JFQURfTE9DSyBp
cyBub3Qgc2V0CiMgQ09ORklHX0lOTElORV9SRUFEX0xPQ0tfQkggaXMgbm90IHNldAojIENPTkZJ
R19JTkxJTkVfUkVBRF9MT0NLX0lSUSBpcyBub3Qgc2V0CiMgQ09ORklHX0lOTElORV9SRUFEX0xP
Q0tfSVJRU0FWRSBpcyBub3Qgc2V0CkNPTkZJR19JTkxJTkVfUkVBRF9VTkxPQ0s9eQojIENPTkZJ
R19JTkxJTkVfUkVBRF9VTkxPQ0tfQkggaXMgbm90IHNldApDT05GSUdfSU5MSU5FX1JFQURfVU5M
T0NLX0lSUT15CiMgQ09ORklHX0lOTElORV9SRUFEX1VOTE9DS19JUlFSRVNUT1JFIGlzIG5vdCBz
ZXQKIyBDT05GSUdfSU5MSU5FX1dSSVRFX1RSWUxPQ0sgaXMgbm90IHNldAojIENPTkZJR19JTkxJ
TkVfV1JJVEVfTE9DSyBpcyBub3Qgc2V0CiMgQ09ORklHX0lOTElORV9XUklURV9MT0NLX0JIIGlz
IG5vdCBzZXQKIyBDT05GSUdfSU5MSU5FX1dSSVRFX0xPQ0tfSVJRIGlzIG5vdCBzZXQKIyBDT05G
SUdfSU5MSU5FX1dSSVRFX0xPQ0tfSVJRU0FWRSBpcyBub3Qgc2V0CkNPTkZJR19JTkxJTkVfV1JJ
VEVfVU5MT0NLPXkKIyBDT05GSUdfSU5MSU5FX1dSSVRFX1VOTE9DS19CSCBpcyBub3Qgc2V0CkNP
TkZJR19JTkxJTkVfV1JJVEVfVU5MT0NLX0lSUT15CiMgQ09ORklHX0lOTElORV9XUklURV9VTkxP
Q0tfSVJRUkVTVE9SRSBpcyBub3Qgc2V0CkNPTkZJR19NVVRFWF9TUElOX09OX09XTkVSPXkKQ09O
RklHX0ZSRUVaRVI9eQoKIwojIFByb2Nlc3NvciB0eXBlIGFuZCBmZWF0dXJlcwojCkNPTkZJR19U
SUNLX09ORVNIT1Q9eQpDT05GSUdfTk9fSFo9eQojIENPTkZJR19ISUdIX1JFU19USU1FUlMgaXMg
bm90IHNldApDT05GSUdfR0VORVJJQ19DTE9DS0VWRU5UU19CVUlMRD15CkNPTkZJR19TTVA9eQpD
T05GSUdfWDg2X01QUEFSU0U9eQojIENPTkZJR19YODZfQklHU01QIGlzIG5vdCBzZXQKQ09ORklH
X1g4Nl9FWFRFTkRFRF9QTEFURk9STT15CiMgQ09ORklHX1g4Nl9NUlNUIGlzIG5vdCBzZXQKIyBD
T05GSUdfWDg2X1JEQzMyMVggaXMgbm90IHNldAojIENPTkZJR19YODZfMzJfTk9OX1NUQU5EQVJE
IGlzIG5vdCBzZXQKIyBDT05GSUdfWDg2XzMyX0lSSVMgaXMgbm90IHNldApDT05GSUdfU0NIRURf
T01JVF9GUkFNRV9QT0lOVEVSPXkKQ09ORklHX1BBUkFWSVJUX0dVRVNUPXkKQ09ORklHX1hFTj15
CkNPTkZJR19YRU5fRE9NMD15CkNPTkZJR19YRU5fUFJJVklMRUdFRF9HVUVTVD15CkNPTkZJR19Y
RU5fUFZIVk09eQpDT05GSUdfWEVOX01BWF9ET01BSU5fTUVNT1JZPTEyOApDT05GSUdfWEVOX1NB
VkVfUkVTVE9SRT15CiMgQ09ORklHX1hFTl9ERUJVRyBpcyBub3Qgc2V0CiMgQ09ORklHX0tWTV9D
TE9DSyBpcyBub3Qgc2V0CiMgQ09ORklHX0tWTV9HVUVTVCBpcyBub3Qgc2V0CiMgQ09ORklHX0xH
VUVTVF9HVUVTVCBpcyBub3Qgc2V0CkNPTkZJR19QQVJBVklSVD15CiMgQ09ORklHX1BBUkFWSVJU
X1NQSU5MT0NLUyBpcyBub3Qgc2V0CkNPTkZJR19QQVJBVklSVF9DTE9DSz15CkNPTkZJR19OT19C
T09UTUVNPXkKIyBDT05GSUdfTUVNVEVTVCBpcyBub3Qgc2V0CiMgQ09ORklHX00zODYgaXMgbm90
IHNldAojIENPTkZJR19NNDg2IGlzIG5vdCBzZXQKIyBDT05GSUdfTTU4NiBpcyBub3Qgc2V0CiMg
Q09ORklHX001ODZUU0MgaXMgbm90IHNldAojIENPTkZJR19NNTg2TU1YIGlzIG5vdCBzZXQKIyBD
T05GSUdfTTY4NiBpcyBub3Qgc2V0CiMgQ09ORklHX01QRU5USVVNSUkgaXMgbm90IHNldAojIENP
TkZJR19NUEVOVElVTUlJSSBpcyBub3Qgc2V0CiMgQ09ORklHX01QRU5USVVNTSBpcyBub3Qgc2V0
CkNPTkZJR19NUEVOVElVTTQ9eQojIENPTkZJR19NSzYgaXMgbm90IHNldAojIENPTkZJR19NSzcg
aXMgbm90IHNldAojIENPTkZJR19NSzggaXMgbm90IHNldAojIENPTkZJR19NQ1JVU09FIGlzIG5v
dCBzZXQKIyBDT05GSUdfTUVGRklDRU9OIGlzIG5vdCBzZXQKIyBDT05GSUdfTVdJTkNISVBDNiBp
cyBub3Qgc2V0CiMgQ09ORklHX01XSU5DSElQM0QgaXMgbm90IHNldAojIENPTkZJR19NRUxBTiBp
cyBub3Qgc2V0CiMgQ09ORklHX01HRU9ERUdYMSBpcyBub3Qgc2V0CiMgQ09ORklHX01HRU9ERV9M
WCBpcyBub3Qgc2V0CiMgQ09ORklHX01DWVJJWElJSSBpcyBub3Qgc2V0CiMgQ09ORklHX01WSUFD
M18yIGlzIG5vdCBzZXQKIyBDT05GSUdfTVZJQUM3IGlzIG5vdCBzZXQKIyBDT05GSUdfTUNPUkUy
IGlzIG5vdCBzZXQKIyBDT05GSUdfTUFUT00gaXMgbm90IHNldAojIENPTkZJR19YODZfR0VORVJJ
QyBpcyBub3Qgc2V0CkNPTkZJR19YODZfSU5URVJOT0RFX0NBQ0hFX1NISUZUPTcKQ09ORklHX1g4
Nl9DTVBYQ0hHPXkKQ09ORklHX0NNUFhDSEdfTE9DQUw9eQpDT05GSUdfWDg2X0wxX0NBQ0hFX1NI
SUZUPTcKQ09ORklHX1g4Nl9YQUREPXkKQ09ORklHX1g4Nl9XUF9XT1JLU19PSz15CkNPTkZJR19Y
ODZfSU5WTFBHPXkKQ09ORklHX1g4Nl9CU1dBUD15CkNPTkZJR19YODZfUE9QQURfT0s9eQpDT05G
SUdfWDg2X0lOVEVMX1VTRVJDT1BZPXkKQ09ORklHX1g4Nl9VU0VfUFBST19DSEVDS1NVTT15CkNP
TkZJR19YODZfVFNDPXkKQ09ORklHX1g4Nl9DTVBYQ0hHNjQ9eQpDT05GSUdfWDg2X0NNT1Y9eQpD
T05GSUdfWDg2X01JTklNVU1fQ1BVX0ZBTUlMWT01CkNPTkZJR19YODZfREVCVUdDVExNU1I9eQoj
IENPTkZJR19QUk9DRVNTT1JfU0VMRUNUIGlzIG5vdCBzZXQKQ09ORklHX0NQVV9TVVBfSU5URUw9
eQpDT05GSUdfQ1BVX1NVUF9DWVJJWF8zMj15CkNPTkZJR19DUFVfU1VQX0FNRD15CkNPTkZJR19D
UFVfU1VQX0NFTlRBVVI9eQpDT05GSUdfQ1BVX1NVUF9UUkFOU01FVEFfMzI9eQpDT05GSUdfQ1BV
X1NVUF9VTUNfMzI9eQojIENPTkZJR19IUEVUX1RJTUVSIGlzIG5vdCBzZXQKQ09ORklHX0RNST15
CkNPTkZJR19TV0lPVExCPXkKQ09ORklHX0lPTU1VX0hFTFBFUj15CiMgQ09ORklHX0lPTU1VX0FQ
SSBpcyBub3Qgc2V0CkNPTkZJR19OUl9DUFVTPTgKIyBDT05GSUdfU0NIRURfU01UIGlzIG5vdCBz
ZXQKQ09ORklHX1NDSEVEX01DPXkKIyBDT05GSUdfSVJRX1RJTUVfQUNDT1VOVElORyBpcyBub3Qg
c2V0CkNPTkZJR19QUkVFTVBUX05PTkU9eQojIENPTkZJR19QUkVFTVBUX1ZPTFVOVEFSWSBpcyBu
b3Qgc2V0CiMgQ09ORklHX1BSRUVNUFQgaXMgbm90IHNldApDT05GSUdfWDg2X0xPQ0FMX0FQSUM9
eQpDT05GSUdfWDg2X0lPX0FQSUM9eQojIENPTkZJR19YODZfUkVST1VURV9GT1JfQlJPS0VOX0JP
T1RfSVJRUyBpcyBub3Qgc2V0CiMgQ09ORklHX1g4Nl9NQ0UgaXMgbm90IHNldApDT05GSUdfVk04
Nj15CiMgQ09ORklHX1RPU0hJQkEgaXMgbm90IHNldAojIENPTkZJR19JOEsgaXMgbm90IHNldAoj
IENPTkZJR19YODZfUkVCT09URklYVVBTIGlzIG5vdCBzZXQKQ09ORklHX01JQ1JPQ09ERT15CkNP
TkZJR19NSUNST0NPREVfSU5URUw9eQojIENPTkZJR19NSUNST0NPREVfQU1EIGlzIG5vdCBzZXQK
Q09ORklHX01JQ1JPQ09ERV9PTERfSU5URVJGQUNFPXkKIyBDT05GSUdfWDg2X01TUiBpcyBub3Qg
c2V0CkNPTkZJR19YODZfQ1BVSUQ9eQojIENPTkZJR19OT0hJR0hNRU0gaXMgbm90IHNldAojIENP
TkZJR19ISUdITUVNNEcgaXMgbm90IHNldApDT05GSUdfSElHSE1FTTY0Rz15CkNPTkZJR19WTVNQ
TElUXzNHPXkKIyBDT05GSUdfVk1TUExJVF8yRyBpcyBub3Qgc2V0CiMgQ09ORklHX1ZNU1BMSVRf
MUcgaXMgbm90IHNldApDT05GSUdfUEFHRV9PRkZTRVQ9MHhDMDAwMDAwMApDT05GSUdfSElHSE1F
TT15CkNPTkZJR19YODZfUEFFPXkKQ09ORklHX0FSQ0hfUEhZU19BRERSX1RfNjRCSVQ9eQpDT05G
SUdfQVJDSF9ETUFfQUREUl9UXzY0QklUPXkKQ09ORklHX0FSQ0hfRkxBVE1FTV9FTkFCTEU9eQpD
T05GSUdfQVJDSF9TUEFSU0VNRU1fRU5BQkxFPXkKQ09ORklHX0FSQ0hfU0VMRUNUX01FTU9SWV9N
T0RFTD15CkNPTkZJR19JTExFR0FMX1BPSU5URVJfVkFMVUU9MApDT05GSUdfU0VMRUNUX01FTU9S
WV9NT0RFTD15CkNPTkZJR19GTEFUTUVNX01BTlVBTD15CiMgQ09ORklHX1NQQVJTRU1FTV9NQU5V
QUwgaXMgbm90IHNldApDT05GSUdfRkxBVE1FTT15CkNPTkZJR19GTEFUX05PREVfTUVNX01BUD15
CkNPTkZJR19TUEFSU0VNRU1fU1RBVElDPXkKQ09ORklHX0hBVkVfTUVNQkxPQ0s9eQpDT05GSUdf
UEFHRUZMQUdTX0VYVEVOREVEPXkKQ09ORklHX1NQTElUX1BUTE9DS19DUFVTPTQKIyBDT05GSUdf
Q09NUEFDVElPTiBpcyBub3Qgc2V0CkNPTkZJR19QSFlTX0FERFJfVF82NEJJVD15CkNPTkZJR19a
T05FX0RNQV9GTEFHPTEKQ09ORklHX0JPVU5DRT15CkNPTkZJR19WSVJUX1RPX0JVUz15CkNPTkZJ
R19NTVVfTk9USUZJRVI9eQojIENPTkZJR19LU00gaXMgbm90IHNldApDT05GSUdfREVGQVVMVF9N
TUFQX01JTl9BRERSPTQwOTYKIyBDT05GSUdfVFJBTlNQQVJFTlRfSFVHRVBBR0UgaXMgbm90IHNl
dAojIENPTkZJR19DTEVBTkNBQ0hFIGlzIG5vdCBzZXQKIyBDT05GSUdfSElHSFBURSBpcyBub3Qg
c2V0CiMgQ09ORklHX1g4Nl9DSEVDS19CSU9TX0NPUlJVUFRJT04gaXMgbm90IHNldApDT05GSUdf
WDg2X1JFU0VSVkVfTE9XPTY0CiMgQ09ORklHX01BVEhfRU1VTEFUSU9OIGlzIG5vdCBzZXQKQ09O
RklHX01UUlI9eQpDT05GSUdfTVRSUl9TQU5JVElaRVI9eQpDT05GSUdfTVRSUl9TQU5JVElaRVJf
RU5BQkxFX0RFRkFVTFQ9MApDT05GSUdfTVRSUl9TQU5JVElaRVJfU1BBUkVfUkVHX05SX0RFRkFV
TFQ9MQpDT05GSUdfWDg2X1BBVD15CkNPTkZJR19BUkNIX1VTRVNfUEdfVU5DQUNIRUQ9eQojIENP
TkZJR19FRkkgaXMgbm90IHNldApDT05GSUdfU0VDQ09NUD15CiMgQ09ORklHX0NDX1NUQUNLUFJP
VEVDVE9SIGlzIG5vdCBzZXQKQ09ORklHX0haXzEwMD15CiMgQ09ORklHX0haXzI1MCBpcyBub3Qg
c2V0CiMgQ09ORklHX0haXzMwMCBpcyBub3Qgc2V0CiMgQ09ORklHX0haXzEwMDAgaXMgbm90IHNl
dApDT05GSUdfSFo9MTAwCiMgQ09ORklHX1NDSEVEX0hSVElDSyBpcyBub3Qgc2V0CiMgQ09ORklH
X0tFWEVDIGlzIG5vdCBzZXQKIyBDT05GSUdfQ1JBU0hfRFVNUCBpcyBub3Qgc2V0CkNPTkZJR19Q
SFlTSUNBTF9TVEFSVD0weDEwMDAwMDAKQ09ORklHX1JFTE9DQVRBQkxFPXkKQ09ORklHX1g4Nl9O
RUVEX1JFTE9DUz15CkNPTkZJR19QSFlTSUNBTF9BTElHTj0weDEwMDAwMDAKQ09ORklHX0hPVFBM
VUdfQ1BVPXkKQ09ORklHX0NPTVBBVF9WRFNPPXkKIyBDT05GSUdfQ01ETElORV9CT09MIGlzIG5v
dCBzZXQKQ09ORklHX0FSQ0hfRU5BQkxFX01FTU9SWV9IT1RQTFVHPXkKCiMKIyBQb3dlciBtYW5h
Z2VtZW50IGFuZCBBQ1BJIG9wdGlvbnMKIwojIENPTkZJR19TVVNQRU5EIGlzIG5vdCBzZXQKQ09O
RklHX0hJQkVSTkFURV9DQUxMQkFDS1M9eQojIENPTkZJR19ISUJFUk5BVElPTiBpcyBub3Qgc2V0
CkNPTkZJR19QTV9TTEVFUD15CkNPTkZJR19QTV9TTEVFUF9TTVA9eQojIENPTkZJR19QTV9SVU5U
SU1FIGlzIG5vdCBzZXQKQ09ORklHX1BNPXkKIyBDT05GSUdfUE1fREVCVUcgaXMgbm90IHNldApD
T05GSUdfQUNQST15CiMgQ09ORklHX0FDUElfUFJPQ0ZTIGlzIG5vdCBzZXQKIyBDT05GSUdfQUNQ
SV9QUk9DRlNfUE9XRVIgaXMgbm90IHNldAojIENPTkZJR19BQ1BJX0VDX0RFQlVHRlMgaXMgbm90
IHNldApDT05GSUdfQUNQSV9QUk9DX0VWRU5UPXkKIyBDT05GSUdfQUNQSV9BQyBpcyBub3Qgc2V0
CiMgQ09ORklHX0FDUElfQkFUVEVSWSBpcyBub3Qgc2V0CkNPTkZJR19BQ1BJX0JVVFRPTj1tCkNP
TkZJR19BQ1BJX0ZBTj1tCiMgQ09ORklHX0FDUElfRE9DSyBpcyBub3Qgc2V0CkNPTkZJR19BQ1BJ
X1BST0NFU1NPUj15CiMgQ09ORklHX0FDUElfSVBNSSBpcyBub3Qgc2V0CkNPTkZJR19BQ1BJX0hP
VFBMVUdfQ1BVPXkKIyBDT05GSUdfQUNQSV9QUk9DRVNTT1JfQUdHUkVHQVRPUiBpcyBub3Qgc2V0
CkNPTkZJR19BQ1BJX1RIRVJNQUw9bQojIENPTkZJR19BQ1BJX0NVU1RPTV9EU0RUIGlzIG5vdCBz
ZXQKQ09ORklHX0FDUElfQkxBQ0tMSVNUX1lFQVI9MAojIENPTkZJR19BQ1BJX0RFQlVHIGlzIG5v
dCBzZXQKIyBDT05GSUdfQUNQSV9QQ0lfU0xPVCBpcyBub3Qgc2V0CkNPTkZJR19YODZfUE1fVElN
RVI9eQpDT05GSUdfQUNQSV9DT05UQUlORVI9eQojIENPTkZJR19BQ1BJX1NCUyBpcyBub3Qgc2V0
CiMgQ09ORklHX0FDUElfSEVEIGlzIG5vdCBzZXQKIyBDT05GSUdfQUNQSV9BUEVJIGlzIG5vdCBz
ZXQKIyBDT05GSUdfU0ZJIGlzIG5vdCBzZXQKIyBDT05GSUdfQVBNIGlzIG5vdCBzZXQKCiMKIyBD
UFUgRnJlcXVlbmN5IHNjYWxpbmcKIwojIENPTkZJR19DUFVfRlJFUSBpcyBub3Qgc2V0CkNPTkZJ
R19DUFVfSURMRT15CkNPTkZJR19DUFVfSURMRV9HT1ZfTEFEREVSPXkKQ09ORklHX0NQVV9JRExF
X0dPVl9NRU5VPXkKIyBDT05GSUdfSU5URUxfSURMRSBpcyBub3Qgc2V0CgojCiMgQnVzIG9wdGlv
bnMgKFBDSSBldGMuKQojCkNPTkZJR19QQ0k9eQojIENPTkZJR19QQ0lfR09CSU9TIGlzIG5vdCBz
ZXQKIyBDT05GSUdfUENJX0dPTU1DT05GSUcgaXMgbm90IHNldAojIENPTkZJR19QQ0lfR09ESVJF
Q1QgaXMgbm90IHNldApDT05GSUdfUENJX0dPQU5ZPXkKQ09ORklHX1BDSV9CSU9TPXkKQ09ORklH
X1BDSV9ESVJFQ1Q9eQpDT05GSUdfUENJX01NQ09ORklHPXkKQ09ORklHX1BDSV9YRU49eQpDT05G
SUdfUENJX0RPTUFJTlM9eQojIENPTkZJR19QQ0lfQ05CMjBMRV9RVUlSSyBpcyBub3Qgc2V0CiMg
Q09ORklHX0RNQVIgaXMgbm90IHNldApDT05GSUdfUENJRVBPUlRCVVM9eQojIENPTkZJR19IT1RQ
TFVHX1BDSV9QQ0lFIGlzIG5vdCBzZXQKQ09ORklHX1BDSUVBRVI9eQojIENPTkZJR19QQ0lFX0VD
UkMgaXMgbm90IHNldAojIENPTkZJR19QQ0lFQUVSX0lOSkVDVCBpcyBub3Qgc2V0CkNPTkZJR19Q
Q0lFQVNQTT15CiMgQ09ORklHX1BDSUVBU1BNX0RFQlVHIGlzIG5vdCBzZXQKQ09ORklHX0FSQ0hf
U1VQUE9SVFNfTVNJPXkKQ09ORklHX1BDSV9NU0k9eQojIENPTkZJR19QQ0lfU1RVQiBpcyBub3Qg
c2V0CiMgQ09ORklHX1hFTl9QQ0lERVZfRlJPTlRFTkQgaXMgbm90IHNldApDT05GSUdfSFRfSVJR
PXkKIyBDT05GSUdfUENJX0lPViBpcyBub3Qgc2V0CkNPTkZJR19QQ0lfSU9BUElDPXkKQ09ORklH
X1BDSV9MQUJFTD15CkNPTkZJR19JU0FfRE1BX0FQST15CiMgQ09ORklHX0lTQSBpcyBub3Qgc2V0
CiMgQ09ORklHX01DQSBpcyBub3Qgc2V0CiMgQ09ORklHX1NDeDIwMCBpcyBub3Qgc2V0CkNPTkZJ
R19BTURfTkI9eQojIENPTkZJR19QQ0NBUkQgaXMgbm90IHNldApDT05GSUdfSE9UUExVR19QQ0k9
bQpDT05GSUdfSE9UUExVR19QQ0lfRkFLRT1tCiMgQ09ORklHX0hPVFBMVUdfUENJX0NPTVBBUSBp
cyBub3Qgc2V0CiMgQ09ORklHX0hPVFBMVUdfUENJX0lCTSBpcyBub3Qgc2V0CkNPTkZJR19IT1RQ
TFVHX1BDSV9BQ1BJPW0KQ09ORklHX0hPVFBMVUdfUENJX0FDUElfSUJNPW0KQ09ORklHX0hPVFBM
VUdfUENJX0NQQ0k9eQojIENPTkZJR19IT1RQTFVHX1BDSV9DUENJX1pUNTU1MCBpcyBub3Qgc2V0
CiMgQ09ORklHX0hPVFBMVUdfUENJX0NQQ0lfR0VORVJJQyBpcyBub3Qgc2V0CiMgQ09ORklHX0hP
VFBMVUdfUENJX1NIUEMgaXMgbm90IHNldAojIENPTkZJR19SQVBJRElPIGlzIG5vdCBzZXQKCiMK
IyBFeGVjdXRhYmxlIGZpbGUgZm9ybWF0cyAvIEVtdWxhdGlvbnMKIwpDT05GSUdfQklORk1UX0VM
Rj15CkNPTkZJR19DT1JFX0RVTVBfREVGQVVMVF9FTEZfSEVBREVSUz15CkNPTkZJR19IQVZFX0FP
VVQ9eQojIENPTkZJR19CSU5GTVRfQU9VVCBpcyBub3Qgc2V0CiMgQ09ORklHX0JJTkZNVF9NSVND
IGlzIG5vdCBzZXQKQ09ORklHX0hBVkVfQVRPTUlDX0lPTUFQPXkKQ09ORklHX0hBVkVfVEVYVF9Q
T0tFX1NNUD15CkNPTkZJR19ORVQ9eQoKIwojIE5ldHdvcmtpbmcgb3B0aW9ucwojCkNPTkZJR19Q
QUNLRVQ9eQpDT05GSUdfVU5JWD15CkNPTkZJR19YRlJNPXkKIyBDT05GSUdfWEZSTV9VU0VSIGlz
IG5vdCBzZXQKIyBDT05GSUdfWEZSTV9TVUJfUE9MSUNZIGlzIG5vdCBzZXQKIyBDT05GSUdfWEZS
TV9NSUdSQVRFIGlzIG5vdCBzZXQKIyBDT05GSUdfWEZSTV9TVEFUSVNUSUNTIGlzIG5vdCBzZXQK
Q09ORklHX1hGUk1fSVBDT01QPW0KQ09ORklHX05FVF9LRVk9bQojIENPTkZJR19ORVRfS0VZX01J
R1JBVEUgaXMgbm90IHNldApDT05GSUdfSU5FVD15CiMgQ09ORklHX0lQX01VTFRJQ0FTVCBpcyBu
b3Qgc2V0CiMgQ09ORklHX0lQX0FEVkFOQ0VEX1JPVVRFUiBpcyBub3Qgc2V0CkNPTkZJR19JUF9S
T1VURV9DTEFTU0lEPXkKQ09ORklHX0lQX1BOUD15CkNPTkZJR19JUF9QTlBfREhDUD15CiMgQ09O
RklHX0lQX1BOUF9CT09UUCBpcyBub3Qgc2V0CiMgQ09ORklHX0lQX1BOUF9SQVJQIGlzIG5vdCBz
ZXQKIyBDT05GSUdfTkVUX0lQSVAgaXMgbm90IHNldAojIENPTkZJR19ORVRfSVBHUkVfREVNVVgg
aXMgbm90IHNldAojIENPTkZJR19BUlBEIGlzIG5vdCBzZXQKQ09ORklHX1NZTl9DT09LSUVTPXkK
Q09ORklHX0lORVRfQUg9bQpDT05GSUdfSU5FVF9FU1A9bQpDT05GSUdfSU5FVF9JUENPTVA9bQpD
T05GSUdfSU5FVF9YRlJNX1RVTk5FTD1tCkNPTkZJR19JTkVUX1RVTk5FTD1tCkNPTkZJR19JTkVU
X1hGUk1fTU9ERV9UUkFOU1BPUlQ9bQpDT05GSUdfSU5FVF9YRlJNX01PREVfVFVOTkVMPW0KQ09O
RklHX0lORVRfWEZSTV9NT0RFX0JFRVQ9eQpDT05GSUdfSU5FVF9MUk89bQpDT05GSUdfSU5FVF9E
SUFHPW0KQ09ORklHX0lORVRfVENQX0RJQUc9bQojIENPTkZJR19UQ1BfQ09OR19BRFZBTkNFRCBp
cyBub3Qgc2V0CkNPTkZJR19UQ1BfQ09OR19DVUJJQz15CkNPTkZJR19ERUZBVUxUX1RDUF9DT05H
PSJjdWJpYyIKIyBDT05GSUdfVENQX01ENVNJRyBpcyBub3Qgc2V0CkNPTkZJR19JUFY2PW0KQ09O
RklHX0lQVjZfUFJJVkFDWT15CiMgQ09ORklHX0lQVjZfUk9VVEVSX1BSRUYgaXMgbm90IHNldAoj
IENPTkZJR19JUFY2X09QVElNSVNUSUNfREFEIGlzIG5vdCBzZXQKQ09ORklHX0lORVQ2X0FIPW0K
Q09ORklHX0lORVQ2X0VTUD1tCkNPTkZJR19JTkVUNl9JUENPTVA9bQojIENPTkZJR19JUFY2X01J
UDYgaXMgbm90IHNldApDT05GSUdfSU5FVDZfWEZSTV9UVU5ORUw9bQpDT05GSUdfSU5FVDZfVFVO
TkVMPW0KQ09ORklHX0lORVQ2X1hGUk1fTU9ERV9UUkFOU1BPUlQ9bQpDT05GSUdfSU5FVDZfWEZS
TV9NT0RFX1RVTk5FTD1tCkNPTkZJR19JTkVUNl9YRlJNX01PREVfQkVFVD1tCiMgQ09ORklHX0lO
RVQ2X1hGUk1fTU9ERV9ST1VURU9QVElNSVpBVElPTiBpcyBub3Qgc2V0CkNPTkZJR19JUFY2X1NJ
VD1tCiMgQ09ORklHX0lQVjZfU0lUXzZSRCBpcyBub3Qgc2V0CkNPTkZJR19JUFY2X05ESVNDX05P
REVUWVBFPXkKQ09ORklHX0lQVjZfVFVOTkVMPW0KIyBDT05GSUdfSVBWNl9NVUxUSVBMRV9UQUJM
RVMgaXMgbm90IHNldAojIENPTkZJR19JUFY2X01ST1VURSBpcyBub3Qgc2V0CiMgQ09ORklHX05F
VFdPUktfU0VDTUFSSyBpcyBub3Qgc2V0CiMgQ09ORklHX05FVFdPUktfUEhZX1RJTUVTVEFNUElO
RyBpcyBub3Qgc2V0CkNPTkZJR19ORVRGSUxURVI9eQojIENPTkZJR19ORVRGSUxURVJfREVCVUcg
aXMgbm90IHNldApDT05GSUdfTkVURklMVEVSX0FEVkFOQ0VEPXkKQ09ORklHX0JSSURHRV9ORVRG
SUxURVI9eQoKIwojIENvcmUgTmV0ZmlsdGVyIENvbmZpZ3VyYXRpb24KIwpDT05GSUdfTkVURklM
VEVSX05FVExJTks9bQpDT05GSUdfTkVURklMVEVSX05FVExJTktfUVVFVUU9bQpDT05GSUdfTkVU
RklMVEVSX05FVExJTktfTE9HPW0KIyBDT05GSUdfTkZfQ09OTlRSQUNLIGlzIG5vdCBzZXQKIyBD
T05GSUdfTkVURklMVEVSX1RQUk9YWSBpcyBub3Qgc2V0CkNPTkZJR19ORVRGSUxURVJfWFRBQkxF
Uz1tCgojCiMgWHRhYmxlcyBjb21iaW5lZCBtb2R1bGVzCiMKQ09ORklHX05FVEZJTFRFUl9YVF9N
QVJLPW0KCiMKIyBYdGFibGVzIHRhcmdldHMKIwojIENPTkZJR19ORVRGSUxURVJfWFRfVEFSR0VU
X0NIRUNLU1VNIGlzIG5vdCBzZXQKQ09ORklHX05FVEZJTFRFUl9YVF9UQVJHRVRfQ0xBU1NJRlk9
bQojIENPTkZJR19ORVRGSUxURVJfWFRfVEFSR0VUX0RTQ1AgaXMgbm90IHNldApDT05GSUdfTkVU
RklMVEVSX1hUX1RBUkdFVF9ITD1tCiMgQ09ORklHX05FVEZJTFRFUl9YVF9UQVJHRVRfSURMRVRJ
TUVSIGlzIG5vdCBzZXQKQ09ORklHX05FVEZJTFRFUl9YVF9UQVJHRVRfTUFSSz1tCiMgQ09ORklH
X05FVEZJTFRFUl9YVF9UQVJHRVRfTkZMT0cgaXMgbm90IHNldApDT05GSUdfTkVURklMVEVSX1hU
X1RBUkdFVF9ORlFVRVVFPW0KIyBDT05GSUdfTkVURklMVEVSX1hUX1RBUkdFVF9SQVRFRVNUIGlz
IG5vdCBzZXQKIyBDT05GSUdfTkVURklMVEVSX1hUX1RBUkdFVF9URUUgaXMgbm90IHNldAojIENP
TkZJR19ORVRGSUxURVJfWFRfVEFSR0VUX1RSQUNFIGlzIG5vdCBzZXQKIyBDT05GSUdfTkVURklM
VEVSX1hUX1RBUkdFVF9UQ1BNU1MgaXMgbm90IHNldAojIENPTkZJR19ORVRGSUxURVJfWFRfVEFS
R0VUX1RDUE9QVFNUUklQIGlzIG5vdCBzZXQKCiMKIyBYdGFibGVzIG1hdGNoZXMKIwojIENPTkZJ
R19ORVRGSUxURVJfWFRfTUFUQ0hfQUREUlRZUEUgaXMgbm90IHNldApDT05GSUdfTkVURklMVEVS
X1hUX01BVENIX0NPTU1FTlQ9bQojIENPTkZJR19ORVRGSUxURVJfWFRfTUFUQ0hfQ1BVIGlzIG5v
dCBzZXQKQ09ORklHX05FVEZJTFRFUl9YVF9NQVRDSF9EQ0NQPW0KIyBDT05GSUdfTkVURklMVEVS
X1hUX01BVENIX0RFVkdST1VQIGlzIG5vdCBzZXQKIyBDT05GSUdfTkVURklMVEVSX1hUX01BVENI
X0RTQ1AgaXMgbm90IHNldApDT05GSUdfTkVURklMVEVSX1hUX01BVENIX0VTUD1tCiMgQ09ORklH
X05FVEZJTFRFUl9YVF9NQVRDSF9IQVNITElNSVQgaXMgbm90IHNldApDT05GSUdfTkVURklMVEVS
X1hUX01BVENIX0hMPW0KIyBDT05GSUdfTkVURklMVEVSX1hUX01BVENIX0lQUkFOR0UgaXMgbm90
IHNldApDT05GSUdfTkVURklMVEVSX1hUX01BVENIX0xFTkdUSD1tCkNPTkZJR19ORVRGSUxURVJf
WFRfTUFUQ0hfTElNSVQ9bQpDT05GSUdfTkVURklMVEVSX1hUX01BVENIX01BQz1tCkNPTkZJR19O
RVRGSUxURVJfWFRfTUFUQ0hfTUFSSz1tCkNPTkZJR19ORVRGSUxURVJfWFRfTUFUQ0hfTVVMVElQ
T1JUPW0KIyBDT05GSUdfTkVURklMVEVSX1hUX01BVENIX09TRiBpcyBub3Qgc2V0CiMgQ09ORklH
X05FVEZJTFRFUl9YVF9NQVRDSF9PV05FUiBpcyBub3Qgc2V0CkNPTkZJR19ORVRGSUxURVJfWFRf
TUFUQ0hfUE9MSUNZPW0KQ09ORklHX05FVEZJTFRFUl9YVF9NQVRDSF9QSFlTREVWPW0KQ09ORklH
X05FVEZJTFRFUl9YVF9NQVRDSF9QS1RUWVBFPW0KQ09ORklHX05FVEZJTFRFUl9YVF9NQVRDSF9R
VU9UQT1tCiMgQ09ORklHX05FVEZJTFRFUl9YVF9NQVRDSF9SQVRFRVNUIGlzIG5vdCBzZXQKQ09O
RklHX05FVEZJTFRFUl9YVF9NQVRDSF9SRUFMTT1tCiMgQ09ORklHX05FVEZJTFRFUl9YVF9NQVRD
SF9SRUNFTlQgaXMgbm90IHNldApDT05GSUdfTkVURklMVEVSX1hUX01BVENIX1NDVFA9bQpDT05G
SUdfTkVURklMVEVSX1hUX01BVENIX1NUQVRJU1RJQz1tCkNPTkZJR19ORVRGSUxURVJfWFRfTUFU
Q0hfU1RSSU5HPW0KQ09ORklHX05FVEZJTFRFUl9YVF9NQVRDSF9UQ1BNU1M9bQojIENPTkZJR19O
RVRGSUxURVJfWFRfTUFUQ0hfVElNRSBpcyBub3Qgc2V0CiMgQ09ORklHX05FVEZJTFRFUl9YVF9N
QVRDSF9VMzIgaXMgbm90IHNldAojIENPTkZJR19JUF9TRVQgaXMgbm90IHNldAojIENPTkZJR19J
UF9WUyBpcyBub3Qgc2V0CgojCiMgSVA6IE5ldGZpbHRlciBDb25maWd1cmF0aW9uCiMKIyBDT05G
SUdfTkZfREVGUkFHX0lQVjQgaXMgbm90IHNldAojIENPTkZJR19JUF9ORl9RVUVVRSBpcyBub3Qg
c2V0CkNPTkZJR19JUF9ORl9JUFRBQkxFUz1tCkNPTkZJR19JUF9ORl9NQVRDSF9BSD1tCkNPTkZJ
R19JUF9ORl9NQVRDSF9FQ049bQpDT05GSUdfSVBfTkZfTUFUQ0hfVFRMPW0KQ09ORklHX0lQX05G
X0ZJTFRFUj1tCkNPTkZJR19JUF9ORl9UQVJHRVRfUkVKRUNUPW0KQ09ORklHX0lQX05GX1RBUkdF
VF9MT0c9bQpDT05GSUdfSVBfTkZfVEFSR0VUX1VMT0c9bQpDT05GSUdfSVBfTkZfTUFOR0xFPW0K
Q09ORklHX0lQX05GX1RBUkdFVF9FQ049bQpDT05GSUdfSVBfTkZfVEFSR0VUX1RUTD1tCkNPTkZJ
R19JUF9ORl9SQVc9bQpDT05GSUdfSVBfTkZfQVJQVEFCTEVTPW0KQ09ORklHX0lQX05GX0FSUEZJ
TFRFUj1tCkNPTkZJR19JUF9ORl9BUlBfTUFOR0xFPW0KCiMKIyBJUHY2OiBOZXRmaWx0ZXIgQ29u
ZmlndXJhdGlvbgojCiMgQ09ORklHX05GX0RFRlJBR19JUFY2IGlzIG5vdCBzZXQKIyBDT05GSUdf
SVA2X05GX1FVRVVFIGlzIG5vdCBzZXQKIyBDT05GSUdfSVA2X05GX0lQVEFCTEVTIGlzIG5vdCBz
ZXQKQ09ORklHX0JSSURHRV9ORl9FQlRBQkxFUz1tCkNPTkZJR19CUklER0VfRUJUX0JST1VURT1t
CkNPTkZJR19CUklER0VfRUJUX1RfRklMVEVSPW0KQ09ORklHX0JSSURHRV9FQlRfVF9OQVQ9bQpD
T05GSUdfQlJJREdFX0VCVF84MDJfMz1tCkNPTkZJR19CUklER0VfRUJUX0FNT05HPW0KQ09ORklH
X0JSSURHRV9FQlRfQVJQPW0KQ09ORklHX0JSSURHRV9FQlRfSVA9bQojIENPTkZJR19CUklER0Vf
RUJUX0lQNiBpcyBub3Qgc2V0CkNPTkZJR19CUklER0VfRUJUX0xJTUlUPW0KQ09ORklHX0JSSURH
RV9FQlRfTUFSSz1tCkNPTkZJR19CUklER0VfRUJUX1BLVFRZUEU9bQpDT05GSUdfQlJJREdFX0VC
VF9TVFA9bQpDT05GSUdfQlJJREdFX0VCVF9WTEFOPW0KQ09ORklHX0JSSURHRV9FQlRfQVJQUkVQ
TFk9bQpDT05GSUdfQlJJREdFX0VCVF9ETkFUPW0KQ09ORklHX0JSSURHRV9FQlRfTUFSS19UPW0K
Q09ORklHX0JSSURHRV9FQlRfUkVESVJFQ1Q9bQpDT05GSUdfQlJJREdFX0VCVF9TTkFUPW0KQ09O
RklHX0JSSURHRV9FQlRfTE9HPW0KQ09ORklHX0JSSURHRV9FQlRfVUxPRz1tCiMgQ09ORklHX0JS
SURHRV9FQlRfTkZMT0cgaXMgbm90IHNldAojIENPTkZJR19JUF9EQ0NQIGlzIG5vdCBzZXQKQ09O
RklHX0lQX1NDVFA9bQojIENPTkZJR19TQ1RQX0RCR19NU0cgaXMgbm90IHNldAojIENPTkZJR19T
Q1RQX0RCR19PQkpDTlQgaXMgbm90IHNldAojIENPTkZJR19TQ1RQX0hNQUNfTk9ORSBpcyBub3Qg
c2V0CiMgQ09ORklHX1NDVFBfSE1BQ19TSEExIGlzIG5vdCBzZXQKQ09ORklHX1NDVFBfSE1BQ19N
RDU9eQojIENPTkZJR19SRFMgaXMgbm90IHNldAojIENPTkZJR19USVBDIGlzIG5vdCBzZXQKIyBD
T05GSUdfQVRNIGlzIG5vdCBzZXQKIyBDT05GSUdfTDJUUCBpcyBub3Qgc2V0CkNPTkZJR19TVFA9
bQpDT05GSUdfQlJJREdFPW0KQ09ORklHX0JSSURHRV9JR01QX1NOT09QSU5HPXkKIyBDT05GSUdf
TkVUX0RTQSBpcyBub3Qgc2V0CkNPTkZJR19WTEFOXzgwMjFRPW0KIyBDT05GSUdfVkxBTl84MDIx
UV9HVlJQIGlzIG5vdCBzZXQKIyBDT05GSUdfREVDTkVUIGlzIG5vdCBzZXQKQ09ORklHX0xMQz15
CiMgQ09ORklHX0xMQzIgaXMgbm90IHNldAojIENPTkZJR19JUFggaXMgbm90IHNldAojIENPTkZJ
R19BVEFMSyBpcyBub3Qgc2V0CiMgQ09ORklHX1gyNSBpcyBub3Qgc2V0CiMgQ09ORklHX0xBUEIg
aXMgbm90IHNldAojIENPTkZJR19FQ09ORVQgaXMgbm90IHNldAojIENPTkZJR19XQU5fUk9VVEVS
IGlzIG5vdCBzZXQKIyBDT05GSUdfUEhPTkVUIGlzIG5vdCBzZXQKIyBDT05GSUdfSUVFRTgwMjE1
NCBpcyBub3Qgc2V0CiMgQ09ORklHX05FVF9TQ0hFRCBpcyBub3Qgc2V0CiMgQ09ORklHX0RDQiBp
cyBub3Qgc2V0CiMgQ09ORklHX0JBVE1BTl9BRFYgaXMgbm90IHNldApDT05GSUdfUlBTPXkKQ09O
RklHX1JGU19BQ0NFTD15CkNPTkZJR19YUFM9eQoKIwojIE5ldHdvcmsgdGVzdGluZwojCiMgQ09O
RklHX05FVF9QS1RHRU4gaXMgbm90IHNldAojIENPTkZJR19IQU1SQURJTyBpcyBub3Qgc2V0CiMg
Q09ORklHX0NBTiBpcyBub3Qgc2V0CiMgQ09ORklHX0lSREEgaXMgbm90IHNldAojIENPTkZJR19C
VCBpcyBub3Qgc2V0CiMgQ09ORklHX0FGX1JYUlBDIGlzIG5vdCBzZXQKIyBDT05GSUdfV0lSRUxF
U1MgaXMgbm90IHNldAojIENPTkZJR19XSU1BWCBpcyBub3Qgc2V0CiMgQ09ORklHX1JGS0lMTCBp
cyBub3Qgc2V0CiMgQ09ORklHX05FVF85UCBpcyBub3Qgc2V0CiMgQ09ORklHX0NBSUYgaXMgbm90
IHNldAojIENPTkZJR19DRVBIX0xJQiBpcyBub3Qgc2V0CgojCiMgRGV2aWNlIERyaXZlcnMKIwoK
IwojIEdlbmVyaWMgRHJpdmVyIE9wdGlvbnMKIwpDT05GSUdfVUVWRU5UX0hFTFBFUl9QQVRIPSIi
CiMgQ09ORklHX0RFVlRNUEZTIGlzIG5vdCBzZXQKQ09ORklHX1NUQU5EQUxPTkU9eQpDT05GSUdf
UFJFVkVOVF9GSVJNV0FSRV9CVUlMRD15CkNPTkZJR19GV19MT0FERVI9eQojIENPTkZJR19GSVJN
V0FSRV9JTl9LRVJORUwgaXMgbm90IHNldApDT05GSUdfRVhUUkFfRklSTVdBUkU9IiIKQ09ORklH
X1NZU19IWVBFUlZJU09SPXkKIyBDT05GSUdfQ09OTkVDVE9SIGlzIG5vdCBzZXQKIyBDT05GSUdf
TVREIGlzIG5vdCBzZXQKQ09ORklHX1BBUlBPUlQ9bQpDT05GSUdfUEFSUE9SVF9QQz1tCkNPTkZJ
R19QQVJQT1JUX1NFUklBTD1tCiMgQ09ORklHX1BBUlBPUlRfUENfRklGTyBpcyBub3Qgc2V0CiMg
Q09ORklHX1BBUlBPUlRfUENfU1VQRVJJTyBpcyBub3Qgc2V0CiMgQ09ORklHX1BBUlBPUlRfR1ND
IGlzIG5vdCBzZXQKIyBDT05GSUdfUEFSUE9SVF9BWDg4Nzk2IGlzIG5vdCBzZXQKQ09ORklHX1BB
UlBPUlRfMTI4ND15CkNPTkZJR19QTlA9eQpDT05GSUdfUE5QX0RFQlVHX01FU1NBR0VTPXkKCiMK
IyBQcm90b2NvbHMKIwpDT05GSUdfUE5QQUNQST15CkNPTkZJR19CTEtfREVWPXkKQ09ORklHX0JM
S19ERVZfRkQ9bQojIENPTkZJR19QQVJJREUgaXMgbm90IHNldApDT05GSUdfQkxLX0NQUV9EQT1t
CkNPTkZJR19CTEtfQ1BRX0NJU1NfREE9bQpDT05GSUdfQ0lTU19TQ1NJX1RBUEU9eQpDT05GSUdf
QkxLX0RFVl9EQUM5NjA9bQpDT05GSUdfQkxLX0RFVl9VTUVNPW0KIyBDT05GSUdfQkxLX0RFVl9D
T1dfQ09NTU9OIGlzIG5vdCBzZXQKQ09ORklHX0JMS19ERVZfTE9PUD1tCkNPTkZJR19CTEtfREVW
X0NSWVBUT0xPT1A9bQoKIwojIERSQkQgZGlzYWJsZWQgYmVjYXVzZSBQUk9DX0ZTLCBJTkVUIG9y
IENPTk5FQ1RPUiBub3Qgc2VsZWN0ZWQKIwpDT05GSUdfQkxLX0RFVl9OQkQ9bQpDT05GSUdfQkxL
X0RFVl9TWDg9bQpDT05GSUdfQkxLX0RFVl9VQj1tCiMgQ09ORklHX0JMS19ERVZfUkFNIGlzIG5v
dCBzZXQKQ09ORklHX0NEUk9NX1BLVENEVkQ9bQpDT05GSUdfQ0RST01fUEtUQ0RWRF9CVUZGRVJT
PTgKIyBDT05GSUdfQ0RST01fUEtUQ0RWRF9XQ0FDSEUgaXMgbm90IHNldApDT05GSUdfQVRBX09W
RVJfRVRIPW0KIyBDT05GSUdfWEVOX0JMS0RFVl9GUk9OVEVORCBpcyBub3Qgc2V0CkNPTkZJR19Y
RU5fQkxLREVWX0JBQ0tFTkQ9eQojIENPTkZJR19CTEtfREVWX0hEIGlzIG5vdCBzZXQKIyBDT05G
SUdfQkxLX0RFVl9SQkQgaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JTX0xJUzNMVjAyRCBpcyBu
b3Qgc2V0CiMgQ09ORklHX01JU0NfREVWSUNFUyBpcyBub3Qgc2V0CkNPTkZJR19IQVZFX0lERT15
CiMgQ09ORklHX0lERSBpcyBub3Qgc2V0CgojCiMgU0NTSSBkZXZpY2Ugc3VwcG9ydAojCkNPTkZJ
R19TQ1NJX01PRD1tCkNPTkZJR19SQUlEX0FUVFJTPW0KQ09ORklHX1NDU0k9bQpDT05GSUdfU0NT
SV9ETUE9eQojIENPTkZJR19TQ1NJX1RHVCBpcyBub3Qgc2V0CkNPTkZJR19TQ1NJX05FVExJTks9
eQpDT05GSUdfU0NTSV9QUk9DX0ZTPXkKCiMKIyBTQ1NJIHN1cHBvcnQgdHlwZSAoZGlzaywgdGFw
ZSwgQ0QtUk9NKQojCkNPTkZJR19CTEtfREVWX1NEPW0KQ09ORklHX0NIUl9ERVZfU1Q9bQpDT05G
SUdfQ0hSX0RFVl9PU1NUPW0KQ09ORklHX0JMS19ERVZfU1I9bQpDT05GSUdfQkxLX0RFVl9TUl9W
RU5ET1I9eQpDT05GSUdfQ0hSX0RFVl9TRz1tCkNPTkZJR19DSFJfREVWX1NDSD1tCkNPTkZJR19T
Q1NJX01VTFRJX0xVTj15CkNPTkZJR19TQ1NJX0NPTlNUQU5UUz15CkNPTkZJR19TQ1NJX0xPR0dJ
Tkc9eQojIENPTkZJR19TQ1NJX1NDQU5fQVNZTkMgaXMgbm90IHNldApDT05GSUdfU0NTSV9XQUlU
X1NDQU49bQoKIwojIFNDU0kgVHJhbnNwb3J0cwojCkNPTkZJR19TQ1NJX1NQSV9BVFRSUz1tCkNP
TkZJR19TQ1NJX0ZDX0FUVFJTPW0KQ09ORklHX1NDU0lfSVNDU0lfQVRUUlM9bQpDT05GSUdfU0NT
SV9TQVNfQVRUUlM9bQpDT05GSUdfU0NTSV9TQVNfTElCU0FTPW0KIyBDT05GSUdfU0NTSV9TQVNf
QVRBIGlzIG5vdCBzZXQKQ09ORklHX1NDU0lfU0FTX0hPU1RfU01QPXkKQ09ORklHX1NDU0lfU1JQ
X0FUVFJTPW0KQ09ORklHX1NDU0lfTE9XTEVWRUw9eQpDT05GSUdfSVNDU0lfVENQPW0KIyBDT05G
SUdfSVNDU0lfQk9PVF9TWVNGUyBpcyBub3Qgc2V0CiMgQ09ORklHX1NDU0lfQ1hHQjNfSVNDU0kg
aXMgbm90IHNldAojIENPTkZJR19TQ1NJX0NYR0I0X0lTQ1NJIGlzIG5vdCBzZXQKIyBDT05GSUdf
U0NTSV9CTlgyX0lTQ1NJIGlzIG5vdCBzZXQKIyBDT05GSUdfU0NTSV9CTlgyWF9GQ09FIGlzIG5v
dCBzZXQKIyBDT05GSUdfQkUySVNDU0kgaXMgbm90IHNldApDT05GSUdfQkxLX0RFVl8zV19YWFhY
X1JBSUQ9bQojIENPTkZJR19TQ1NJX0hQU0EgaXMgbm90IHNldApDT05GSUdfU0NTSV8zV185WFhY
PW0KIyBDT05GSUdfU0NTSV8zV19TQVMgaXMgbm90IHNldApDT05GSUdfU0NTSV9BQ0FSRD1tCkNP
TkZJR19TQ1NJX0FBQ1JBSUQ9bQpDT05GSUdfU0NTSV9BSUM3WFhYPW0KQ09ORklHX0FJQzdYWFhf
Q01EU19QRVJfREVWSUNFPTMyCkNPTkZJR19BSUM3WFhYX1JFU0VUX0RFTEFZX01TPTE1MDAwCiMg
Q09ORklHX0FJQzdYWFhfREVCVUdfRU5BQkxFIGlzIG5vdCBzZXQKQ09ORklHX0FJQzdYWFhfREVC
VUdfTUFTSz0wCkNPTkZJR19BSUM3WFhYX1JFR19QUkVUVFlfUFJJTlQ9eQpDT05GSUdfU0NTSV9B
SUM3WFhYX09MRD1tCkNPTkZJR19TQ1NJX0FJQzc5WFg9bQpDT05GSUdfQUlDNzlYWF9DTURTX1BF
Ul9ERVZJQ0U9MzIKQ09ORklHX0FJQzc5WFhfUkVTRVRfREVMQVlfTVM9MTUwMDAKIyBDT05GSUdf
QUlDNzlYWF9ERUJVR19FTkFCTEUgaXMgbm90IHNldApDT05GSUdfQUlDNzlYWF9ERUJVR19NQVNL
PTAKQ09ORklHX0FJQzc5WFhfUkVHX1BSRVRUWV9QUklOVD15CkNPTkZJR19TQ1NJX0FJQzk0WFg9
bQojIENPTkZJR19BSUM5NFhYX0RFQlVHIGlzIG5vdCBzZXQKIyBDT05GSUdfU0NTSV9NVlNBUyBp
cyBub3Qgc2V0CkNPTkZJR19TQ1NJX0RQVF9JMk89bQpDT05GSUdfU0NTSV9BRFZBTlNZUz1tCkNP
TkZJR19TQ1NJX0FSQ01TUj1tCiMgQ09ORklHX1NDU0lfQVJDTVNSX0FFUiBpcyBub3Qgc2V0CkNP
TkZJR19NRUdBUkFJRF9ORVdHRU49eQpDT05GSUdfTUVHQVJBSURfTU09bQpDT05GSUdfTUVHQVJB
SURfTUFJTEJPWD1tCkNPTkZJR19NRUdBUkFJRF9MRUdBQ1k9bQpDT05GSUdfTUVHQVJBSURfU0FT
PW0KQ09ORklHX1NDU0lfTVBUMlNBUz1tCkNPTkZJR19TQ1NJX01QVDJTQVNfTUFYX1NHRT0xMjgK
IyBDT05GSUdfU0NTSV9NUFQyU0FTX0xPR0dJTkcgaXMgbm90IHNldApDT05GSUdfU0NTSV9IUFRJ
T1A9bQpDT05GSUdfU0NTSV9CVVNMT0dJQz1tCiMgQ09ORklHX1NDU0lfRkxBU0hQT0lOVCBpcyBu
b3Qgc2V0CiMgQ09ORklHX1ZNV0FSRV9QVlNDU0kgaXMgbm90IHNldAojIENPTkZJR19MSUJGQyBp
cyBub3Qgc2V0CiMgQ09ORklHX0xJQkZDT0UgaXMgbm90IHNldAojIENPTkZJR19GQ09FIGlzIG5v
dCBzZXQKIyBDT05GSUdfRkNPRV9GTklDIGlzIG5vdCBzZXQKQ09ORklHX1NDU0lfRE1YMzE5MUQ9
bQpDT05GSUdfU0NTSV9FQVRBPW0KIyBDT05GSUdfU0NTSV9FQVRBX1RBR0dFRF9RVUVVRSBpcyBu
b3Qgc2V0CiMgQ09ORklHX1NDU0lfRUFUQV9MSU5LRURfQ09NTUFORFMgaXMgbm90IHNldApDT05G
SUdfU0NTSV9FQVRBX01BWF9UQUdTPTE2CkNPTkZJR19TQ1NJX0ZVVFVSRV9ET01BSU49bQpDT05G
SUdfU0NTSV9HRFRIPW0KIyBDT05GSUdfU0NTSV9JU0NJIGlzIG5vdCBzZXQKQ09ORklHX1NDU0lf
SVBTPW0KQ09ORklHX1NDU0lfSU5JVElPPW0KQ09ORklHX1NDU0lfSU5JQTEwMD1tCkNPTkZJR19T
Q1NJX1BQQT1tCkNPTkZJR19TQ1NJX0lNTT1tCiMgQ09ORklHX1NDU0lfSVpJUF9FUFAxNiBpcyBu
b3Qgc2V0CiMgQ09ORklHX1NDU0lfSVpJUF9TTE9XX0NUUiBpcyBub3Qgc2V0CkNPTkZJR19TQ1NJ
X1NURVg9bQpDT05GSUdfU0NTSV9TWU01M0M4WFhfMj1tCkNPTkZJR19TQ1NJX1NZTTUzQzhYWF9E
TUFfQUREUkVTU0lOR19NT0RFPTEKQ09ORklHX1NDU0lfU1lNNTNDOFhYX0RFRkFVTFRfVEFHUz0x
NgpDT05GSUdfU0NTSV9TWU01M0M4WFhfTUFYX1RBR1M9NjQKQ09ORklHX1NDU0lfU1lNNTNDOFhY
X01NSU89eQpDT05GSUdfU0NTSV9JUFI9bQojIENPTkZJR19TQ1NJX0lQUl9UUkFDRSBpcyBub3Qg
c2V0CiMgQ09ORklHX1NDU0lfSVBSX0RVTVAgaXMgbm90IHNldApDT05GSUdfU0NTSV9RTE9HSUNf
MTI4MD1tCkNPTkZJR19TQ1NJX1FMQV9GQz1tCkNPTkZJR19TQ1NJX1FMQV9JU0NTST1tCkNPTkZJ
R19TQ1NJX0xQRkM9bQpDT05GSUdfU0NTSV9EQzM5NXg9bQpDT05GSUdfU0NTSV9EQzM5MFQ9bQpD
T05GSUdfU0NTSV9OU1AzMj1tCiMgQ09ORklHX1NDU0lfREVCVUcgaXMgbm90IHNldAojIENPTkZJ
R19TQ1NJX1BNQ1JBSUQgaXMgbm90IHNldAojIENPTkZJR19TQ1NJX1BNODAwMSBpcyBub3Qgc2V0
CiMgQ09ORklHX1NDU0lfU1JQIGlzIG5vdCBzZXQKIyBDT05GSUdfU0NTSV9CRkFfRkMgaXMgbm90
IHNldApDT05GSUdfU0NTSV9ESD1tCiMgQ09ORklHX1NDU0lfREhfUkRBQyBpcyBub3Qgc2V0CiMg
Q09ORklHX1NDU0lfREhfSFBfU1cgaXMgbm90IHNldAojIENPTkZJR19TQ1NJX0RIX0VNQyBpcyBu
b3Qgc2V0CiMgQ09ORklHX1NDU0lfREhfQUxVQSBpcyBub3Qgc2V0CiMgQ09ORklHX1NDU0lfT1NE
X0lOSVRJQVRPUiBpcyBub3Qgc2V0CkNPTkZJR19BVEE9bQojIENPTkZJR19BVEFfTk9OU1RBTkRB
UkQgaXMgbm90IHNldApDT05GSUdfQVRBX1ZFUkJPU0VfRVJST1I9eQpDT05GSUdfQVRBX0FDUEk9
eQpDT05GSUdfU0FUQV9QTVA9eQoKIwojIENvbnRyb2xsZXJzIHdpdGggbm9uLVNGRiBuYXRpdmUg
aW50ZXJmYWNlCiMKQ09ORklHX1NBVEFfQUhDST1tCkNPTkZJR19TQVRBX0FIQ0lfUExBVEZPUk09
bQpDT05GSUdfU0FUQV9JTklDMTYyWD1tCkNPTkZJR19TQVRBX0FDQVJEX0FIQ0k9bQpDT05GSUdf
U0FUQV9TSUwyND1tCkNPTkZJR19BVEFfU0ZGPXkKCiMKIyBTRkYgY29udHJvbGxlcnMgd2l0aCBj
dXN0b20gRE1BIGludGVyZmFjZQojCkNPTkZJR19QRENfQURNQT1tCkNPTkZJR19TQVRBX1FTVE9S
PW0KQ09ORklHX1NBVEFfU1g0PW0KQ09ORklHX0FUQV9CTURNQT15CgojCiMgU0FUQSBTRkYgY29u
dHJvbGxlcnMgd2l0aCBCTURNQQojCkNPTkZJR19BVEFfUElJWD1tCkNPTkZJR19TQVRBX01WPW0K
Q09ORklHX1NBVEFfTlY9bQpDT05GSUdfU0FUQV9QUk9NSVNFPW0KQ09ORklHX1NBVEFfU0lMPW0K
Q09ORklHX1NBVEFfU0lTPW0KQ09ORklHX1NBVEFfU1ZXPW0KQ09ORklHX1NBVEFfVUxJPW0KQ09O
RklHX1NBVEFfVklBPW0KQ09ORklHX1NBVEFfVklURVNTRT1tCgojCiMgUEFUQSBTRkYgY29udHJv
bGxlcnMgd2l0aCBCTURNQQojCkNPTkZJR19QQVRBX0FMST1tCkNPTkZJR19QQVRBX0FNRD1tCkNP
TkZJR19QQVRBX0FSQVNBTl9DRj1tCkNPTkZJR19QQVRBX0FSVE9QPW0KQ09ORklHX1BBVEFfQVRJ
SVhQPW0KQ09ORklHX1BBVEFfQVRQODY3WD1tCkNPTkZJR19QQVRBX0NNRDY0WD1tCkNPTkZJR19Q
QVRBX0NTNTUyMD1tCkNPTkZJR19QQVRBX0NTNTUzMD1tCkNPTkZJR19QQVRBX0NTNTUzNT1tCkNP
TkZJR19QQVRBX0NTNTUzNj1tCkNPTkZJR19QQVRBX0NZUFJFU1M9bQpDT05GSUdfUEFUQV9FRkFS
PW0KQ09ORklHX1BBVEFfSFBUMzY2PW0KQ09ORklHX1BBVEFfSFBUMzdYPW0KQ09ORklHX1BBVEFf
SFBUM1gyTj1tCkNPTkZJR19QQVRBX0hQVDNYMz1tCkNPTkZJR19QQVRBX0hQVDNYM19ETUE9eQpD
T05GSUdfUEFUQV9JVDgyMTM9bQpDT05GSUdfUEFUQV9JVDgyMVg9bQpDT05GSUdfUEFUQV9KTUlD
Uk9OPW0KQ09ORklHX1BBVEFfTUFSVkVMTD1tCkNPTkZJR19QQVRBX05FVENFTEw9bQpDT05GSUdf
UEFUQV9OSU5KQTMyPW0KQ09ORklHX1BBVEFfTlM4NzQxNT1tCkNPTkZJR19QQVRBX09MRFBJSVg9
bQpDT05GSUdfUEFUQV9PUFRJRE1BPW0KQ09ORklHX1BBVEFfUERDMjAyN1g9bQpDT05GSUdfUEFU
QV9QRENfT0xEPW0KQ09ORklHX1BBVEFfUkFESVNZUz1tCkNPTkZJR19QQVRBX1JEQz1tCkNPTkZJ
R19QQVRBX1NDMTIwMD1tCkNPTkZJR19QQVRBX1NDSD1tCkNPTkZJR19QQVRBX1NFUlZFUldPUktT
PW0KQ09ORklHX1BBVEFfU0lMNjgwPW0KQ09ORklHX1BBVEFfU0lTPW0KQ09ORklHX1BBVEFfVE9T
SElCQT1tCkNPTkZJR19QQVRBX1RSSUZMRVg9bQpDT05GSUdfUEFUQV9WSUE9bQpDT05GSUdfUEFU
QV9XSU5CT05EPW0KCiMKIyBQSU8tb25seSBTRkYgY29udHJvbGxlcnMKIwpDT05GSUdfUEFUQV9D
TUQ2NDBfUENJPW0KQ09ORklHX1BBVEFfTVBJSVg9bQpDT05GSUdfUEFUQV9OUzg3NDEwPW0KQ09O
RklHX1BBVEFfT1BUST1tCiMgQ09ORklHX1BBVEFfUExBVEZPUk0gaXMgbm90IHNldApDT05GSUdf
UEFUQV9SWjEwMDA9bQoKIwojIEdlbmVyaWMgZmFsbGJhY2sgLyBsZWdhY3kgZHJpdmVycwojCkNP
TkZJR19QQVRBX0FDUEk9bQpDT05GSUdfQVRBX0dFTkVSSUM9bQojIENPTkZJR19QQVRBX0xFR0FD
WSBpcyBub3Qgc2V0CkNPTkZJR19NRD15CkNPTkZJR19CTEtfREVWX01EPXkKQ09ORklHX01EX0FV
VE9ERVRFQ1Q9eQpDT05GSUdfTURfTElORUFSPW0KQ09ORklHX01EX1JBSUQwPW0KQ09ORklHX01E
X1JBSUQxPW0KQ09ORklHX01EX1JBSUQxMD1tCkNPTkZJR19NRF9SQUlENDU2PW0KIyBDT05GSUdf
TVVMVElDT1JFX1JBSUQ0NTYgaXMgbm90IHNldApDT05GSUdfTURfTVVMVElQQVRIPW0KIyBDT05G
SUdfTURfRkFVTFRZIGlzIG5vdCBzZXQKQ09ORklHX0JMS19ERVZfRE09bQojIENPTkZJR19ETV9E
RUJVRyBpcyBub3Qgc2V0CkNPTkZJR19ETV9DUllQVD1tCkNPTkZJR19ETV9TTkFQU0hPVD1tCkNP
TkZJR19ETV9NSVJST1I9bQojIENPTkZJR19ETV9SQUlEIGlzIG5vdCBzZXQKIyBDT05GSUdfRE1f
TE9HX1VTRVJTUEFDRSBpcyBub3Qgc2V0CkNPTkZJR19ETV9aRVJPPW0KQ09ORklHX0RNX01VTFRJ
UEFUSD1tCiMgQ09ORklHX0RNX01VTFRJUEFUSF9RTCBpcyBub3Qgc2V0CiMgQ09ORklHX0RNX01V
TFRJUEFUSF9TVCBpcyBub3Qgc2V0CiMgQ09ORklHX0RNX0RFTEFZIGlzIG5vdCBzZXQKIyBDT05G
SUdfRE1fVUVWRU5UIGlzIG5vdCBzZXQKIyBDT05GSUdfRE1fRkxBS0VZIGlzIG5vdCBzZXQKIyBD
T05GSUdfVEFSR0VUX0NPUkUgaXMgbm90IHNldApDT05GSUdfRlVTSU9OPXkKQ09ORklHX0ZVU0lP
Tl9TUEk9bQpDT05GSUdfRlVTSU9OX0ZDPW0KQ09ORklHX0ZVU0lPTl9TQVM9bQpDT05GSUdfRlVT
SU9OX01BWF9TR0U9MTI4CkNPTkZJR19GVVNJT05fQ1RMPW0KIyBDT05GSUdfRlVTSU9OX0xBTiBp
cyBub3Qgc2V0CiMgQ09ORklHX0ZVU0lPTl9MT0dHSU5HIGlzIG5vdCBzZXQKCiMKIyBJRUVFIDEz
OTQgKEZpcmVXaXJlKSBzdXBwb3J0CiMKIyBDT05GSUdfRklSRVdJUkUgaXMgbm90IHNldAojIENP
TkZJR19GSVJFV0lSRV9OT1NZIGlzIG5vdCBzZXQKQ09ORklHX0kyTz1tCkNPTkZJR19JMk9fTENU
X05PVElGWV9PTl9DSEFOR0VTPXkKQ09ORklHX0kyT19FWFRfQURBUFRFQz15CkNPTkZJR19JMk9f
RVhUX0FEQVBURUNfRE1BNjQ9eQpDT05GSUdfSTJPX0NPTkZJRz1tCkNPTkZJR19JMk9fQ09ORklH
X09MRF9JT0NUTD15CkNPTkZJR19JMk9fQlVTPW0KQ09ORklHX0kyT19CTE9DSz1tCkNPTkZJR19J
Mk9fU0NTST1tCkNPTkZJR19JMk9fUFJPQz1tCiMgQ09ORklHX01BQ0lOVE9TSF9EUklWRVJTIGlz
IG5vdCBzZXQKQ09ORklHX05FVERFVklDRVM9eQpDT05GSUdfRFVNTVk9bQpDT05GSUdfQk9ORElO
Rz1tCiMgQ09ORklHX01BQ1ZMQU4gaXMgbm90IHNldApDT05GSUdfRVFVQUxJWkVSPW0KQ09ORklH
X1RVTj1tCkNPTkZJR19WRVRIPW0KQ09ORklHX05FVF9TQjEwMDA9bQojIENPTkZJR19BUkNORVQg
aXMgbm90IHNldApDT05GSUdfTUlJPXkKQ09ORklHX1BIWUxJQj1tCgojCiMgTUlJIFBIWSBkZXZp
Y2UgZHJpdmVycwojCkNPTkZJR19NQVJWRUxMX1BIWT1tCkNPTkZJR19EQVZJQ09NX1BIWT1tCkNP
TkZJR19RU0VNSV9QSFk9bQpDT05GSUdfTFhUX1BIWT1tCkNPTkZJR19DSUNBREFfUEhZPW0KQ09O
RklHX1ZJVEVTU0VfUEhZPW0KQ09ORklHX1NNU0NfUEhZPW0KIyBDT05GSUdfQlJPQURDT01fUEhZ
IGlzIG5vdCBzZXQKIyBDT05GSUdfSUNQTFVTX1BIWSBpcyBub3Qgc2V0CiMgQ09ORklHX1JFQUxU
RUtfUEhZIGlzIG5vdCBzZXQKIyBDT05GSUdfTkFUSU9OQUxfUEhZIGlzIG5vdCBzZXQKIyBDT05G
SUdfU1RFMTBYUCBpcyBub3Qgc2V0CiMgQ09ORklHX0xTSV9FVDEwMTFDX1BIWSBpcyBub3Qgc2V0
CiMgQ09ORklHX01JQ1JFTF9QSFkgaXMgbm90IHNldAojIENPTkZJR19NRElPX0JJVEJBTkcgaXMg
bm90IHNldApDT05GSUdfTkVUX0VUSEVSTkVUPXkKQ09ORklHX0hBUFBZTUVBTD1tCkNPTkZJR19T
VU5HRU09bQpDT05GSUdfQ0FTU0lOST1tCkNPTkZJR19ORVRfVkVORE9SXzNDT009eQpDT05GSUdf
Vk9SVEVYPW0KQ09ORklHX1RZUEhPT049bQojIENPTkZJR19FVEhPQyBpcyBub3Qgc2V0CiMgQ09O
RklHX0RORVQgaXMgbm90IHNldApDT05GSUdfTkVUX1RVTElQPXkKQ09ORklHX0RFMjEwNFg9bQpD
T05GSUdfREUyMTA0WF9EU0w9MApDT05GSUdfVFVMSVA9bQojIENPTkZJR19UVUxJUF9NV0kgaXMg
bm90IHNldApDT05GSUdfVFVMSVBfTU1JTz15CiMgQ09ORklHX1RVTElQX05BUEkgaXMgbm90IHNl
dApDT05GSUdfREU0WDU9bQpDT05GSUdfV0lOQk9ORF84NDA9bQpDT05GSUdfRE05MTAyPW0KQ09O
RklHX1VMSTUyNlg9bQpDT05GSUdfSFAxMDA9bQojIENPTkZJR19JQk1fTkVXX0VNQUNfWk1JSSBp
cyBub3Qgc2V0CiMgQ09ORklHX0lCTV9ORVdfRU1BQ19SR01JSSBpcyBub3Qgc2V0CiMgQ09ORklH
X0lCTV9ORVdfRU1BQ19UQUggaXMgbm90IHNldAojIENPTkZJR19JQk1fTkVXX0VNQUNfRU1BQzQg
aXMgbm90IHNldAojIENPTkZJR19JQk1fTkVXX0VNQUNfTk9fRkxPV19DVFJMIGlzIG5vdCBzZXQK
IyBDT05GSUdfSUJNX05FV19FTUFDX01BTF9DTFJfSUNJTlRTVEFUIGlzIG5vdCBzZXQKIyBDT05G
SUdfSUJNX05FV19FTUFDX01BTF9DT01NT05fRVJSIGlzIG5vdCBzZXQKQ09ORklHX05FVF9QQ0k9
eQpDT05GSUdfUENORVQzMj1tCkNPTkZJR19BTUQ4MTExX0VUSD1tCkNPTkZJR19BREFQVEVDX1NU
QVJGSVJFPW0KIyBDT05GSUdfS1NaODg0WF9QQ0kgaXMgbm90IHNldApDT05GSUdfQjQ0PW0KQ09O
RklHX0I0NF9QQ0lfQVVUT1NFTEVDVD15CkNPTkZJR19CNDRfUENJQ09SRV9BVVRPU0VMRUNUPXkK
Q09ORklHX0I0NF9QQ0k9eQpDT05GSUdfRk9SQ0VERVRIPW0KQ09ORklHX0UxMDA9bQpDT05GSUdf
RkVBTE5YPW0KQ09ORklHX05BVFNFTUk9bQpDT05GSUdfTkUyS19QQ0k9bQpDT05GSUdfODEzOUNQ
PW0KQ09ORklHXzgxMzlUT089bQpDT05GSUdfODEzOVRPT19QSU89eQojIENPTkZJR184MTM5VE9P
X1RVTkVfVFdJU1RFUiBpcyBub3Qgc2V0CkNPTkZJR184MTM5VE9PXzgxMjk9eQojIENPTkZJR184
MTM5X09MRF9SWF9SRVNFVCBpcyBub3Qgc2V0CiMgQ09ORklHX1I2MDQwIGlzIG5vdCBzZXQKQ09O
RklHX1NJUzkwMD1tCkNPTkZJR19FUElDMTAwPW0KIyBDT05GSUdfU01TQzk0MjAgaXMgbm90IHNl
dApDT05GSUdfU1VOREFOQ0U9bQpDT05GSUdfU1VOREFOQ0VfTU1JTz15CkNPTkZJR19UTEFOPW0K
IyBDT05GSUdfS1M4ODQyIGlzIG5vdCBzZXQKIyBDT05GSUdfS1M4ODUxX01MTCBpcyBub3Qgc2V0
CkNPTkZJR19WSUFfUkhJTkU9bQpDT05GSUdfVklBX1JISU5FX01NSU89eQojIENPTkZJR19TQzky
MDMxIGlzIG5vdCBzZXQKQ09ORklHX05FVF9QT0NLRVQ9eQpDT05GSUdfQVRQPW0KQ09ORklHX0RF
NjAwPW0KQ09ORklHX0RFNjIwPW0KIyBDT05GSUdfQVRMMiBpcyBub3Qgc2V0CkNPTkZJR19ORVRE
RVZfMTAwMD15CkNPTkZJR19BQ0VOSUM9bQojIENPTkZJR19BQ0VOSUNfT01JVF9USUdPTl9JIGlz
IG5vdCBzZXQKQ09ORklHX0RMMks9bQpDT05GSUdfRTEwMDA9bQpDT05GSUdfRTEwMDBFPW0KQ09O
RklHX0lQMTAwMD1tCkNPTkZJR19JR0I9bQpDT05GSUdfSUdCX0RDQT15CkNPTkZJR19JR0JWRj1t
CkNPTkZJR19OUzgzODIwPW0KQ09ORklHX0hBTUFDSEk9bQpDT05GSUdfWUVMTE9XRklOPW0KQ09O
RklHX1I4MTY5PW0KQ09ORklHX1NJUzE5MD1tCkNPTkZJR19TS0dFPW0KQ09ORklHX1NLWTI9bQpD
T05GSUdfVklBX1ZFTE9DSVRZPW0KQ09ORklHX1RJR09OMz1tCkNPTkZJR19CTlgyPW0KIyBDT05G
SUdfQ05JQyBpcyBub3Qgc2V0CkNPTkZJR19RTEEzWFhYPW0KQ09ORklHX0FUTDE9bQpDT05GSUdf
QVRMMUU9bQpDT05GSUdfQVRMMUM9bQpDT05GSUdfSk1FPW0KQ09ORklHX1NUTU1BQ19FVEg9bQoj
IENPTkZJR19TVE1NQUNfREEgaXMgbm90IHNldAojIENPTkZJR19TVE1NQUNfRFVBTF9NQUMgaXMg
bm90IHNldApDT05GSUdfUENIX0dCRT15CkNPTkZJR19ORVRERVZfMTAwMDA9eQpDT05GSUdfTURJ
Tz1tCkNPTkZJR19DSEVMU0lPX1QxPW0KIyBDT05GSUdfQ0hFTFNJT19UMV8xRyBpcyBub3Qgc2V0
CkNPTkZJR19DSEVMU0lPX1QzPW0KQ09ORklHX0NIRUxTSU9fVDQ9bQpDT05GSUdfQ0hFTFNJT19U
NFZGPW0KQ09ORklHX0VOSUM9bQpDT05GSUdfSVhHQkU9bQpDT05GSUdfSVhHQkVfRENBPXkKQ09O
RklHX0lYR0JFVkY9bQpDT05GSUdfSVhHQj1tCkNPTkZJR19TMklPPW0KQ09ORklHX1ZYR0U9bQoj
IENPTkZJR19WWEdFX0RFQlVHX1RSQUNFX0FMTCBpcyBub3Qgc2V0CkNPTkZJR19NWVJJMTBHRT1t
CkNPTkZJR19NWVJJMTBHRV9EQ0E9eQpDT05GSUdfTkVUWEVOX05JQz1tCkNPTkZJR19OSVU9bQpD
T05GSUdfTUxYNF9FTj1tCkNPTkZJR19NTFg0X0NPUkU9bQpDT05GSUdfTUxYNF9ERUJVRz15CkNP
TkZJR19URUhVVEk9bQpDT05GSUdfQk5YMlg9bQpDT05GSUdfUUxDTklDPW0KQ09ORklHX1FMR0U9
bQpDT05GSUdfQk5BPW0KQ09ORklHX1NGQz1tCkNPTkZJR19CRTJORVQ9bQpDT05GSUdfVFI9eQpD
T05GSUdfSUJNT0w9bQpDT05GSUdfSUJNTFM9bQpDT05GSUdfM0MzNTk9bQojIENPTkZJR19UTVMz
ODBUUiBpcyBub3Qgc2V0CiMgQ09ORklHX1dMQU4gaXMgbm90IHNldAoKIwojIEVuYWJsZSBXaU1B
WCAoTmV0d29ya2luZyBvcHRpb25zKSB0byBzZWUgdGhlIFdpTUFYIGRyaXZlcnMKIwoKIwojIFVT
QiBOZXR3b3JrIEFkYXB0ZXJzCiMKIyBDT05GSUdfVVNCX0NBVEMgaXMgbm90IHNldAojIENPTkZJ
R19VU0JfS0FXRVRIIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX1BFR0FTVVMgaXMgbm90IHNldAoj
IENPTkZJR19VU0JfUlRMODE1MCBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9VU0JORVQgaXMgbm90
IHNldAojIENPTkZJR19VU0JfSVBIRVRIIGlzIG5vdCBzZXQKIyBDT05GSUdfV0FOIGlzIG5vdCBz
ZXQKCiMKIyBDQUlGIHRyYW5zcG9ydCBkcml2ZXJzCiMKIyBDT05GSUdfWEVOX05FVERFVl9GUk9O
VEVORCBpcyBub3Qgc2V0CkNPTkZJR19YRU5fTkVUREVWX0JBQ0tFTkQ9eQojIENPTkZJR19GRERJ
IGlzIG5vdCBzZXQKIyBDT05GSUdfSElQUEkgaXMgbm90IHNldAojIENPTkZJR19QTElQIGlzIG5v
dCBzZXQKQ09ORklHX1BQUD1tCkNPTkZJR19QUFBfTVVMVElMSU5LPXkKQ09ORklHX1BQUF9GSUxU
RVI9eQpDT05GSUdfUFBQX0FTWU5DPW0KQ09ORklHX1BQUF9TWU5DX1RUWT1tCkNPTkZJR19QUFBf
REVGTEFURT1tCkNPTkZJR19QUFBfQlNEQ09NUD1tCiMgQ09ORklHX1BQUF9NUFBFIGlzIG5vdCBz
ZXQKQ09ORklHX1BQUE9FPW0KQ09ORklHX1NMSVA9bQpDT05GSUdfU0xJUF9DT01QUkVTU0VEPXkK
Q09ORklHX1NMSEM9bQpDT05GSUdfU0xJUF9TTUFSVD15CiMgQ09ORklHX1NMSVBfTU9ERV9TTElQ
NiBpcyBub3Qgc2V0CkNPTkZJR19ORVRfRkM9eQpDT05GSUdfTkVUQ09OU09MRT1tCkNPTkZJR19O
RVRQT0xMPXkKQ09ORklHX05FVFBPTExfVFJBUD15CkNPTkZJR19ORVRfUE9MTF9DT05UUk9MTEVS
PXkKIyBDT05GSUdfVk1YTkVUMyBpcyBub3Qgc2V0CiMgQ09ORklHX0lTRE4gaXMgbm90IHNldAoj
IENPTkZJR19QSE9ORSBpcyBub3Qgc2V0CgojCiMgSW5wdXQgZGV2aWNlIHN1cHBvcnQKIwpDT05G
SUdfSU5QVVQ9eQojIENPTkZJR19JTlBVVF9GRl9NRU1MRVNTIGlzIG5vdCBzZXQKQ09ORklHX0lO
UFVUX1BPTExERVY9bQpDT05GSUdfSU5QVVRfU1BBUlNFS01BUD1tCgojCiMgVXNlcmxhbmQgaW50
ZXJmYWNlcwojCkNPTkZJR19JTlBVVF9NT1VTRURFVj15CkNPTkZJR19JTlBVVF9NT1VTRURFVl9Q
U0FVWD15CkNPTkZJR19JTlBVVF9NT1VTRURFVl9TQ1JFRU5fWD0xMDI0CkNPTkZJR19JTlBVVF9N
T1VTRURFVl9TQ1JFRU5fWT03NjgKIyBDT05GSUdfSU5QVVRfSk9ZREVWIGlzIG5vdCBzZXQKIyBD
T05GSUdfSU5QVVRfRVZERVYgaXMgbm90IHNldAojIENPTkZJR19JTlBVVF9FVkJVRyBpcyBub3Qg
c2V0CgojCiMgSW5wdXQgRGV2aWNlIERyaXZlcnMKIwpDT05GSUdfSU5QVVRfS0VZQk9BUkQ9eQoj
IENPTkZJR19LRVlCT0FSRF9BRFA1NTg4IGlzIG5vdCBzZXQKIyBDT05GSUdfS0VZQk9BUkRfQURQ
NTU4OSBpcyBub3Qgc2V0CkNPTkZJR19LRVlCT0FSRF9BVEtCRD15CiMgQ09ORklHX0tFWUJPQVJE
X1FUMTA3MCBpcyBub3Qgc2V0CiMgQ09ORklHX0tFWUJPQVJEX1FUMjE2MCBpcyBub3Qgc2V0CiMg
Q09ORklHX0tFWUJPQVJEX0xLS0JEIGlzIG5vdCBzZXQKIyBDT05GSUdfS0VZQk9BUkRfVENBNjQx
NiBpcyBub3Qgc2V0CiMgQ09ORklHX0tFWUJPQVJEX0xNODMyMyBpcyBub3Qgc2V0CiMgQ09ORklH
X0tFWUJPQVJEX01BWDczNTkgaXMgbm90IHNldAojIENPTkZJR19LRVlCT0FSRF9NQ1MgaXMgbm90
IHNldAojIENPTkZJR19LRVlCT0FSRF9NUFIxMjEgaXMgbm90IHNldAojIENPTkZJR19LRVlCT0FS
RF9ORVdUT04gaXMgbm90IHNldAojIENPTkZJR19LRVlCT0FSRF9PUEVOQ09SRVMgaXMgbm90IHNl
dAojIENPTkZJR19LRVlCT0FSRF9TVE9XQVdBWSBpcyBub3Qgc2V0CiMgQ09ORklHX0tFWUJPQVJE
X1NVTktCRCBpcyBub3Qgc2V0CiMgQ09ORklHX0tFWUJPQVJEX1hUS0JEIGlzIG5vdCBzZXQKIyBD
T05GSUdfSU5QVVRfTU9VU0UgaXMgbm90IHNldAojIENPTkZJR19JTlBVVF9KT1lTVElDSyBpcyBu
b3Qgc2V0CiMgQ09ORklHX0lOUFVUX1RBQkxFVCBpcyBub3Qgc2V0CiMgQ09ORklHX0lOUFVUX1RP
VUNIU0NSRUVOIGlzIG5vdCBzZXQKQ09ORklHX0lOUFVUX01JU0M9eQojIENPTkZJR19JTlBVVF9B
RDcxNFggaXMgbm90IHNldApDT05GSUdfSU5QVVRfUENTUEtSPW0KIyBDT05GSUdfSU5QVVRfQVBB
TkVMIGlzIG5vdCBzZXQKQ09ORklHX0lOUFVUX1dJU1RST05fQlROUz1tCiMgQ09ORklHX0lOUFVU
X0FUTEFTX0JUTlMgaXMgbm90IHNldAojIENPTkZJR19JTlBVVF9BVElfUkVNT1RFIGlzIG5vdCBz
ZXQKIyBDT05GSUdfSU5QVVRfQVRJX1JFTU9URTIgaXMgbm90IHNldAojIENPTkZJR19JTlBVVF9L
RVlTUEFOX1JFTU9URSBpcyBub3Qgc2V0CiMgQ09ORklHX0lOUFVUX1BPV0VSTUFURSBpcyBub3Qg
c2V0CiMgQ09ORklHX0lOUFVUX1lFQUxJTksgaXMgbm90IHNldAojIENPTkZJR19JTlBVVF9DTTEw
OSBpcyBub3Qgc2V0CkNPTkZJR19JTlBVVF9VSU5QVVQ9bQojIENPTkZJR19JTlBVVF9QQ0Y4NTc0
IGlzIG5vdCBzZXQKIyBDT05GSUdfSU5QVVRfQURYTDM0WCBpcyBub3Qgc2V0CiMgQ09ORklHX0lO
UFVUX0NNQTMwMDAgaXMgbm90IHNldAoKIwojIEhhcmR3YXJlIEkvTyBwb3J0cwojCkNPTkZJR19T
RVJJTz15CkNPTkZJR19TRVJJT19JODA0Mj15CkNPTkZJR19TRVJJT19TRVJQT1JUPXkKIyBDT05G
SUdfU0VSSU9fQ1Q4MkM3MTAgaXMgbm90IHNldAojIENPTkZJR19TRVJJT19QQVJLQkQgaXMgbm90
IHNldAojIENPTkZJR19TRVJJT19QQ0lQUzIgaXMgbm90IHNldApDT05GSUdfU0VSSU9fTElCUFMy
PXkKQ09ORklHX1NFUklPX1JBVz1tCiMgQ09ORklHX1NFUklPX0FMVEVSQV9QUzIgaXMgbm90IHNl
dAojIENPTkZJR19TRVJJT19QUzJNVUxUIGlzIG5vdCBzZXQKIyBDT05GSUdfR0FNRVBPUlQgaXMg
bm90IHNldAoKIwojIENoYXJhY3RlciBkZXZpY2VzCiMKQ09ORklHX1ZUPXkKQ09ORklHX0NPTlNP
TEVfVFJBTlNMQVRJT05TPXkKQ09ORklHX1ZUX0NPTlNPTEU9eQpDT05GSUdfSFdfQ09OU09MRT15
CkNPTkZJR19WVF9IV19DT05TT0xFX0JJTkRJTkc9eQpDT05GSUdfVU5JWDk4X1BUWVM9eQojIENP
TkZJR19ERVZQVFNfTVVMVElQTEVfSU5TVEFOQ0VTIGlzIG5vdCBzZXQKIyBDT05GSUdfTEVHQUNZ
X1BUWVMgaXMgbm90IHNldApDT05GSUdfU0VSSUFMX05PTlNUQU5EQVJEPXkKIyBDT05GSUdfUk9D
S0VUUE9SVCBpcyBub3Qgc2V0CkNPTkZJR19DWUNMQURFUz1tCiMgQ09ORklHX0NZWl9JTlRSIGlz
IG5vdCBzZXQKIyBDT05GSUdfTU9YQV9JTlRFTExJTyBpcyBub3Qgc2V0CiMgQ09ORklHX01PWEFf
U01BUlRJTyBpcyBub3Qgc2V0CkNPTkZJR19TWU5DTElOSz1tCkNPTkZJR19TWU5DTElOS01QPW0K
Q09ORklHX1NZTkNMSU5LX0dUPW0KIyBDT05GSUdfTk9aT01JIGlzIG5vdCBzZXQKIyBDT05GSUdf
SVNJIGlzIG5vdCBzZXQKQ09ORklHX05fSERMQz1tCiMgQ09ORklHX05fR1NNIGlzIG5vdCBzZXQK
IyBDT05GSUdfVFJBQ0VfU0lOSyBpcyBub3Qgc2V0CkNPTkZJR19ERVZLTUVNPXkKQ09ORklHX1NU
QUxEUlY9eQoKIwojIFNlcmlhbCBkcml2ZXJzCiMKQ09ORklHX1NFUklBTF84MjUwPXkKQ09ORklH
X1NFUklBTF84MjUwX0NPTlNPTEU9eQpDT05GSUdfRklYX0VBUkxZQ09OX01FTT15CkNPTkZJR19T
RVJJQUxfODI1MF9QQ0k9eQpDT05GSUdfU0VSSUFMXzgyNTBfUE5QPXkKQ09ORklHX1NFUklBTF84
MjUwX05SX1VBUlRTPTQKQ09ORklHX1NFUklBTF84MjUwX1JVTlRJTUVfVUFSVFM9NApDT05GSUdf
U0VSSUFMXzgyNTBfRVhURU5ERUQ9eQojIENPTkZJR19TRVJJQUxfODI1MF9NQU5ZX1BPUlRTIGlz
IG5vdCBzZXQKQ09ORklHX1NFUklBTF84MjUwX1NIQVJFX0lSUT15CkNPTkZJR19TRVJJQUxfODI1
MF9ERVRFQ1RfSVJRPXkKQ09ORklHX1NFUklBTF84MjUwX1JTQT15CgojCiMgTm9uLTgyNTAgc2Vy
aWFsIHBvcnQgc3VwcG9ydAojCiMgQ09ORklHX1NFUklBTF9NRkRfSFNVIGlzIG5vdCBzZXQKQ09O
RklHX1NFUklBTF9DT1JFPXkKQ09ORklHX1NFUklBTF9DT1JFX0NPTlNPTEU9eQpDT05GSUdfU0VS
SUFMX0pTTT1tCiMgQ09ORklHX1NFUklBTF9USU1CRVJEQUxFIGlzIG5vdCBzZXQKIyBDT05GSUdf
U0VSSUFMX0FMVEVSQV9KVEFHVUFSVCBpcyBub3Qgc2V0CiMgQ09ORklHX1NFUklBTF9BTFRFUkFf
VUFSVCBpcyBub3Qgc2V0CiMgQ09ORklHX1NFUklBTF9QQ0hfVUFSVCBpcyBub3Qgc2V0CiMgQ09O
RklHX1NFUklBTF9YSUxJTlhfUFNfVUFSVCBpcyBub3Qgc2V0CiMgQ09ORklHX1RUWV9QUklOVEsg
aXMgbm90IHNldAojIENPTkZJR19QUklOVEVSIGlzIG5vdCBzZXQKIyBDT05GSUdfUFBERVYgaXMg
bm90IHNldApDT05GSUdfSFZDX0RSSVZFUj15CkNPTkZJR19IVkNfSVJRPXkKQ09ORklHX0hWQ19Y
RU49eQpDT05GSUdfSVBNSV9IQU5ETEVSPW0KQ09ORklHX0lQTUlfUEFOSUNfRVZFTlQ9eQojIENP
TkZJR19JUE1JX1BBTklDX1NUUklORyBpcyBub3Qgc2V0CkNPTkZJR19JUE1JX0RFVklDRV9JTlRF
UkZBQ0U9bQpDT05GSUdfSVBNSV9TST1tCkNPTkZJR19JUE1JX1dBVENIRE9HPW0KQ09ORklHX0lQ
TUlfUE9XRVJPRkY9bQpDT05GSUdfSFdfUkFORE9NPXkKIyBDT05GSUdfSFdfUkFORE9NX1RJTUVS
SU9NRU0gaXMgbm90IHNldApDT05GSUdfSFdfUkFORE9NX0lOVEVMPXkKQ09ORklHX0hXX1JBTkRP
TV9BTUQ9eQpDT05GSUdfSFdfUkFORE9NX0dFT0RFPXkKQ09ORklHX0hXX1JBTkRPTV9WSUE9eQpD
T05GSUdfTlZSQU09bQpDT05GSUdfUlRDPXkKIyBDT05GSUdfUjM5NjQgaXMgbm90IHNldAojIENP
TkZJR19BUFBMSUNPTSBpcyBub3Qgc2V0CkNPTkZJR19TT05ZUEk9bQojIENPTkZJR19NV0FWRSBp
cyBub3Qgc2V0CkNPTkZJR19QQzg3MzZ4X0dQSU89bQpDT05GSUdfTlNDX0dQSU89bQpDT05GSUdf
UkFXX0RSSVZFUj1tCkNPTkZJR19NQVhfUkFXX0RFVlM9MjU2CiMgQ09ORklHX0hQRVQgaXMgbm90
IHNldAojIENPTkZJR19IQU5HQ0hFQ0tfVElNRVIgaXMgbm90IHNldAojIENPTkZJR19UQ0dfVFBN
IGlzIG5vdCBzZXQKIyBDT05GSUdfVEVMQ0xPQ0sgaXMgbm90IHNldApDT05GSUdfREVWUE9SVD15
CiMgQ09ORklHX1JBTU9PUFMgaXMgbm90IHNldApDT05GSUdfSTJDPW0KQ09ORklHX0kyQ19CT0FS
RElORk89eQpDT05GSUdfSTJDX0NPTVBBVD15CkNPTkZJR19JMkNfQ0hBUkRFVj1tCiMgQ09ORklH
X0kyQ19NVVggaXMgbm90IHNldApDT05GSUdfSTJDX0hFTFBFUl9BVVRPPXkKQ09ORklHX0kyQ19T
TUJVUz1tCkNPTkZJR19JMkNfQUxHT0JJVD1tCgojCiMgSTJDIEhhcmR3YXJlIEJ1cyBzdXBwb3J0
CiMKCiMKIyBQQyBTTUJ1cyBob3N0IGNvbnRyb2xsZXIgZHJpdmVycwojCkNPTkZJR19JMkNfQUxJ
MTUzNT1tCkNPTkZJR19JMkNfQUxJMTU2Mz1tCkNPTkZJR19JMkNfQUxJMTVYMz1tCkNPTkZJR19J
MkNfQU1ENzU2PW0KQ09ORklHX0kyQ19BTUQ3NTZfUzQ4ODI9bQpDT05GSUdfSTJDX0FNRDgxMTE9
bQpDT05GSUdfSTJDX0k4MDE9bQojIENPTkZJR19JMkNfSVNDSCBpcyBub3Qgc2V0CkNPTkZJR19J
MkNfUElJWDQ9bQpDT05GSUdfSTJDX05GT1JDRTI9bQojIENPTkZJR19JMkNfTkZPUkNFMl9TNDk4
NSBpcyBub3Qgc2V0CkNPTkZJR19JMkNfU0lTNTU5NT1tCkNPTkZJR19JMkNfU0lTNjMwPW0KQ09O
RklHX0kyQ19TSVM5Nlg9bQpDT05GSUdfSTJDX1ZJQT1tCkNPTkZJR19JMkNfVklBUFJPPW0KCiMK
IyBBQ1BJIGRyaXZlcnMKIwojIENPTkZJR19JMkNfU0NNSSBpcyBub3Qgc2V0CgojCiMgSTJDIHN5
c3RlbSBidXMgZHJpdmVycyAobW9zdGx5IGVtYmVkZGVkIC8gc3lzdGVtLW9uLWNoaXApCiMKIyBD
T05GSUdfSTJDX0lOVEVMX01JRCBpcyBub3Qgc2V0CiMgQ09ORklHX0kyQ19PQ09SRVMgaXMgbm90
IHNldAojIENPTkZJR19JMkNfUENBX1BMQVRGT1JNIGlzIG5vdCBzZXQKIyBDT05GSUdfSTJDX1BY
QV9QQ0kgaXMgbm90IHNldAojIENPTkZJR19JMkNfU0lNVEVDIGlzIG5vdCBzZXQKIyBDT05GSUdf
STJDX1hJTElOWCBpcyBub3Qgc2V0CiMgQ09ORklHX0kyQ19FRzIwVCBpcyBub3Qgc2V0CgojCiMg
RXh0ZXJuYWwgSTJDL1NNQnVzIGFkYXB0ZXIgZHJpdmVycwojCiMgQ09ORklHX0kyQ19ESU9MQU5f
VTJDIGlzIG5vdCBzZXQKQ09ORklHX0kyQ19QQVJQT1JUPW0KQ09ORklHX0kyQ19QQVJQT1JUX0xJ
R0hUPW0KIyBDT05GSUdfSTJDX1RBT1NfRVZNIGlzIG5vdCBzZXQKIyBDT05GSUdfSTJDX1RJTllf
VVNCIGlzIG5vdCBzZXQKCiMKIyBPdGhlciBJMkMvU01CdXMgYnVzIGRyaXZlcnMKIwpDT05GSUdf
STJDX1NUVUI9bQpDT05GSUdfU0N4MjAwX0FDQj1tCiMgQ09ORklHX0kyQ19ERUJVR19DT1JFIGlz
IG5vdCBzZXQKIyBDT05GSUdfSTJDX0RFQlVHX0FMR08gaXMgbm90IHNldAojIENPTkZJR19JMkNf
REVCVUdfQlVTIGlzIG5vdCBzZXQKIyBDT05GSUdfU1BJIGlzIG5vdCBzZXQKCiMKIyBQUFMgc3Vw
cG9ydAojCiMgQ09ORklHX1BQUyBpcyBub3Qgc2V0CgojCiMgUFBTIGdlbmVyYXRvcnMgc3VwcG9y
dAojCgojCiMgUFRQIGNsb2NrIHN1cHBvcnQKIwoKIwojIEVuYWJsZSBEZXZpY2UgRHJpdmVycyAt
PiBQUFMgdG8gc2VlIHRoZSBQVFAgY2xvY2sgb3B0aW9ucy4KIwpDT05GSUdfQVJDSF9XQU5UX09Q
VElPTkFMX0dQSU9MSUI9eQojIENPTkZJR19HUElPTElCIGlzIG5vdCBzZXQKIyBDT05GSUdfVzEg
aXMgbm90IHNldApDT05GSUdfUE9XRVJfU1VQUExZPW0KIyBDT05GSUdfUE9XRVJfU1VQUExZX0RF
QlVHIGlzIG5vdCBzZXQKIyBDT05GSUdfUERBX1BPV0VSIGlzIG5vdCBzZXQKIyBDT05GSUdfVEVT
VF9QT1dFUiBpcyBub3Qgc2V0CiMgQ09ORklHX0JBVFRFUllfRFMyNzgwIGlzIG5vdCBzZXQKIyBD
T05GSUdfQkFUVEVSWV9EUzI3ODIgaXMgbm90IHNldAojIENPTkZJR19CQVRURVJZX0JRMjBaNzUg
aXMgbm90IHNldAojIENPTkZJR19CQVRURVJZX0JRMjd4MDAgaXMgbm90IHNldAojIENPTkZJR19C
QVRURVJZX01BWDE3MDQwIGlzIG5vdCBzZXQKIyBDT05GSUdfQkFUVEVSWV9NQVgxNzA0MiBpcyBu
b3Qgc2V0CiMgQ09ORklHX0NIQVJHRVJfTUFYODkwMyBpcyBub3Qgc2V0CkNPTkZJR19IV01PTj1t
CkNPTkZJR19IV01PTl9WSUQ9bQojIENPTkZJR19IV01PTl9ERUJVR19DSElQIGlzIG5vdCBzZXQK
CiMKIyBOYXRpdmUgZHJpdmVycwojCkNPTkZJR19TRU5TT1JTX0FCSVRVR1VSVT1tCkNPTkZJR19T
RU5TT1JTX0FCSVRVR1VSVTM9bQpDT05GSUdfU0VOU09SU19BRDc0MTQ9bQpDT05GSUdfU0VOU09S
U19BRDc0MTg9bQpDT05GSUdfU0VOU09SU19BRE0xMDIxPW0KQ09ORklHX1NFTlNPUlNfQURNMTAy
NT1tCkNPTkZJR19TRU5TT1JTX0FETTEwMjY9bQpDT05GSUdfU0VOU09SU19BRE0xMDI5PW0KQ09O
RklHX1NFTlNPUlNfQURNMTAzMT1tCkNPTkZJR19TRU5TT1JTX0FETTkyNDA9bQpDT05GSUdfU0VO
U09SU19BRFQ3NDExPW0KQ09ORklHX1NFTlNPUlNfQURUNzQ2Mj1tCkNPTkZJR19TRU5TT1JTX0FE
VDc0NzA9bQpDT05GSUdfU0VOU09SU19BRFQ3NDc1PW0KQ09ORklHX1NFTlNPUlNfQVNDNzYyMT1t
CkNPTkZJR19TRU5TT1JTX0s4VEVNUD1tCkNPTkZJR19TRU5TT1JTX0sxMFRFTVA9bQpDT05GSUdf
U0VOU09SU19GQU0xNUhfUE9XRVI9bQpDT05GSUdfU0VOU09SU19BU0IxMDA9bQpDT05GSUdfU0VO
U09SU19BVFhQMT1tCkNPTkZJR19TRU5TT1JTX0RTNjIwPW0KQ09ORklHX1NFTlNPUlNfRFMxNjIx
PW0KQ09ORklHX1NFTlNPUlNfSTVLX0FNQj1tCkNPTkZJR19TRU5TT1JTX0Y3MTgwNUY9bQpDT05G
SUdfU0VOU09SU19GNzE4ODJGRz1tCkNPTkZJR19TRU5TT1JTX0Y3NTM3NVM9bQpDT05GSUdfU0VO
U09SU19GU0NITUQ9bQpDT05GSUdfU0VOU09SU19HNzYwQT1tCkNPTkZJR19TRU5TT1JTX0dMNTE4
U009bQpDT05GSUdfU0VOU09SU19HTDUyMFNNPW0KQ09ORklHX1NFTlNPUlNfQ09SRVRFTVA9bQpD
T05GSUdfU0VOU09SU19JQk1BRU09bQpDT05GSUdfU0VOU09SU19JQk1QRVg9bQpDT05GSUdfU0VO
U09SU19JVDg3PW0KQ09ORklHX1NFTlNPUlNfSkM0Mj1tCkNPTkZJR19TRU5TT1JTX0xJTkVBR0U9
bQpDT05GSUdfU0VOU09SU19MTTYzPW0KQ09ORklHX1NFTlNPUlNfTE03Mz1tCkNPTkZJR19TRU5T
T1JTX0xNNzU9bQpDT05GSUdfU0VOU09SU19MTTc3PW0KQ09ORklHX1NFTlNPUlNfTE03OD1tCkNP
TkZJR19TRU5TT1JTX0xNODA9bQpDT05GSUdfU0VOU09SU19MTTgzPW0KQ09ORklHX1NFTlNPUlNf
TE04NT1tCkNPTkZJR19TRU5TT1JTX0xNODc9bQpDT05GSUdfU0VOU09SU19MTTkwPW0KQ09ORklH
X1NFTlNPUlNfTE05Mj1tCkNPTkZJR19TRU5TT1JTX0xNOTM9bQpDT05GSUdfU0VOU09SU19MVEM0
MTUxPW0KQ09ORklHX1NFTlNPUlNfTFRDNDIxNT1tCkNPTkZJR19TRU5TT1JTX0xUQzQyNDU9bQpD
T05GSUdfU0VOU09SU19MVEM0MjYxPW0KQ09ORklHX1NFTlNPUlNfTE05NTI0MT1tCkNPTkZJR19T
RU5TT1JTX01BWDE2MDY1PW0KQ09ORklHX1NFTlNPUlNfTUFYMTYxOT1tCkNPTkZJR19TRU5TT1JT
X01BWDY2Mzk9bQpDT05GSUdfU0VOU09SU19NQVg2NjQyPW0KQ09ORklHX1NFTlNPUlNfTUFYNjY1
MD1tCkNPTkZJR19TRU5TT1JTX1BDODczNjA9bQpDT05GSUdfU0VOU09SU19QQzg3NDI3PW0KQ09O
RklHX1NFTlNPUlNfUENGODU5MT1tCkNPTkZJR19QTUJVUz1tCkNPTkZJR19TRU5TT1JTX1BNQlVT
PW0KQ09ORklHX1NFTlNPUlNfQURNMTI3NT1tCkNPTkZJR19TRU5TT1JTX01BWDE2MDY0PW0KQ09O
RklHX1NFTlNPUlNfTUFYMzQ0NDA9bQpDT05GSUdfU0VOU09SU19NQVg4Njg4PW0KQ09ORklHX1NF
TlNPUlNfVUNEOTAwMD1tCkNPTkZJR19TRU5TT1JTX1VDRDkyMDA9bQpDT05GSUdfU0VOU09SU19T
SFQyMT1tCkNPTkZJR19TRU5TT1JTX1NJUzU1OTU9bQpDT05GSUdfU0VOU09SU19TTU02NjU9bQpD
T05GSUdfU0VOU09SU19ETUUxNzM3PW0KQ09ORklHX1NFTlNPUlNfRU1DMTQwMz1tCkNPTkZJR19T
RU5TT1JTX0VNQzIxMDM9bQpDT05GSUdfU0VOU09SU19FTUM2VzIwMT1tCkNPTkZJR19TRU5TT1JT
X1NNU0M0N00xPW0KQ09ORklHX1NFTlNPUlNfU01TQzQ3TTE5Mj1tCkNPTkZJR19TRU5TT1JTX1NN
U0M0N0IzOTc9bQpDT05GSUdfU0VOU09SU19TQ0g1NjI3PW0KQ09ORklHX1NFTlNPUlNfQURTMTAx
NT1tCkNPTkZJR19TRU5TT1JTX0FEUzc4Mjg9bQpDT05GSUdfU0VOU09SU19BTUM2ODIxPW0KQ09O
RklHX1NFTlNPUlNfVEhNQzUwPW0KQ09ORklHX1NFTlNPUlNfVE1QMTAyPW0KQ09ORklHX1NFTlNP
UlNfVE1QNDAxPW0KQ09ORklHX1NFTlNPUlNfVE1QNDIxPW0KQ09ORklHX1NFTlNPUlNfVklBX0NQ
VVRFTVA9bQpDT05GSUdfU0VOU09SU19WSUE2ODZBPW0KQ09ORklHX1NFTlNPUlNfVlQxMjExPW0K
Q09ORklHX1NFTlNPUlNfVlQ4MjMxPW0KQ09ORklHX1NFTlNPUlNfVzgzNzgxRD1tCkNPTkZJR19T
RU5TT1JTX1c4Mzc5MUQ9bQpDT05GSUdfU0VOU09SU19XODM3OTJEPW0KQ09ORklHX1NFTlNPUlNf
VzgzNzkzPW0KQ09ORklHX1NFTlNPUlNfVzgzNzk1PW0KQ09ORklHX1NFTlNPUlNfVzgzNzk1X0ZB
TkNUUkw9eQpDT05GSUdfU0VOU09SU19XODNMNzg1VFM9bQpDT05GSUdfU0VOU09SU19XODNMNzg2
Tkc9bQpDT05GSUdfU0VOU09SU19XODM2MjdIRj1tCkNPTkZJR19TRU5TT1JTX1c4MzYyN0VIRj1t
CkNPTkZJR19TRU5TT1JTX0FQUExFU01DPW0KCiMKIyBBQ1BJIGRyaXZlcnMKIwpDT05GSUdfU0VO
U09SU19BQ1BJX1BPV0VSPW0KQ09ORklHX1NFTlNPUlNfQVRLMDExMD1tCkNPTkZJR19USEVSTUFM
PXkKQ09ORklHX1dBVENIRE9HPXkKQ09ORklHX1dBVENIRE9HX05PV0FZT1VUPXkKCiMKIyBXYXRj
aGRvZyBEZXZpY2UgRHJpdmVycwojCkNPTkZJR19TT0ZUX1dBVENIRE9HPW0KQ09ORklHX0FDUVVJ
UkVfV0RUPW0KQ09ORklHX0FEVkFOVEVDSF9XRFQ9bQpDT05GSUdfQUxJTTE1MzVfV0RUPW0KQ09O
RklHX0FMSU03MTAxX1dEVD1tCkNPTkZJR19GNzE4MDhFX1dEVD1tCkNPTkZJR19TUDUxMDBfVENP
PW0KQ09ORklHX1NDNTIwX1dEVD1tCkNPTkZJR19TQkNfRklUUEMyX1dBVENIRE9HPW0KQ09ORklH
X0VVUk9URUNIX1dEVD1tCkNPTkZJR19JQjcwMF9XRFQ9bQpDT05GSUdfSUJNQVNSPW0KQ09ORklH
X1dBRkVSX1dEVD1tCkNPTkZJR19JNjMwMEVTQl9XRFQ9bQpDT05GSUdfSVRDT19XRFQ9bQpDT05G
SUdfSVRDT19WRU5ET1JfU1VQUE9SVD15CkNPTkZJR19JVDg3MTJGX1dEVD1tCkNPTkZJR19JVDg3
X1dEVD1tCkNPTkZJR19IUF9XQVRDSERPRz1tCkNPTkZJR19IUFdEVF9OTUlfREVDT0RJTkc9eQpD
T05GSUdfU0MxMjAwX1dEVD1tCkNPTkZJR19QQzg3NDEzX1dEVD1tCkNPTkZJR19OVl9UQ089bQpD
T05GSUdfNjBYWF9XRFQ9bQpDT05GSUdfU0JDODM2MF9XRFQ9bQpDT05GSUdfU0JDNzI0MF9XRFQ9
bQpDT05GSUdfQ1BVNV9XRFQ9bQpDT05GSUdfU01TQ19TQ0gzMTFYX1dEVD1tCkNPTkZJR19TTVND
MzdCNzg3X1dEVD1tCkNPTkZJR19XODM2MjdIRl9XRFQ9bQpDT05GSUdfVzgzNjk3SEZfV0RUPW0K
Q09ORklHX1c4MzY5N1VHX1dEVD1tCkNPTkZJR19XODM4NzdGX1dEVD1tCkNPTkZJR19XODM5NzdG
X1dEVD1tCkNPTkZJR19NQUNIWl9XRFQ9bQpDT05GSUdfU0JDX0VQWF9DM19XQVRDSERPRz1tCiMg
Q09ORklHX1hFTl9XRFQgaXMgbm90IHNldAoKIwojIFBDSS1iYXNlZCBXYXRjaGRvZyBDYXJkcwoj
CkNPTkZJR19QQ0lQQ1dBVENIRE9HPW0KQ09ORklHX1dEVFBDST1tCgojCiMgVVNCLWJhc2VkIFdh
dGNoZG9nIENhcmRzCiMKQ09ORklHX1VTQlBDV0FUQ0hET0c9bQpDT05GSUdfU1NCX1BPU1NJQkxF
PXkKCiMKIyBTb25pY3MgU2lsaWNvbiBCYWNrcGxhbmUKIwpDT05GSUdfU1NCPW0KQ09ORklHX1NT
Ql9TUFJPTT15CkNPTkZJR19TU0JfUENJSE9TVF9QT1NTSUJMRT15CkNPTkZJR19TU0JfUENJSE9T
VD15CiMgQ09ORklHX1NTQl9CNDNfUENJX0JSSURHRSBpcyBub3Qgc2V0CiMgQ09ORklHX1NTQl9T
SUxFTlQgaXMgbm90IHNldAojIENPTkZJR19TU0JfREVCVUcgaXMgbm90IHNldApDT05GSUdfU1NC
X0RSSVZFUl9QQ0lDT1JFX1BPU1NJQkxFPXkKQ09ORklHX1NTQl9EUklWRVJfUENJQ09SRT15CkNP
TkZJR19CQ01BX1BPU1NJQkxFPXkKCiMKIyBCcm9hZGNvbSBzcGVjaWZpYyBBTUJBCiMKIyBDT05G
SUdfQkNNQSBpcyBub3Qgc2V0CiMgQ09ORklHX01GRF9TVVBQT1JUIGlzIG5vdCBzZXQKIyBDT05G
SUdfUkVHVUxBVE9SIGlzIG5vdCBzZXQKIyBDT05GSUdfTUVESUFfU1VQUE9SVCBpcyBub3Qgc2V0
CgojCiMgR3JhcGhpY3Mgc3VwcG9ydAojCiMgQ09ORklHX0FHUCBpcyBub3Qgc2V0CkNPTkZJR19W
R0FfQVJCPXkKQ09ORklHX1ZHQV9BUkJfTUFYX0dQVVM9MTYKIyBDT05GSUdfVkdBX1NXSVRDSEVS
T08gaXMgbm90IHNldAojIENPTkZJR19EUk0gaXMgbm90IHNldAojIENPTkZJR19TVFVCX1BPVUxT
Qk8gaXMgbm90IHNldAojIENPTkZJR19WR0FTVEFURSBpcyBub3Qgc2V0CiMgQ09ORklHX1ZJREVP
X09VVFBVVF9DT05UUk9MIGlzIG5vdCBzZXQKIyBDT05GSUdfRkIgaXMgbm90IHNldAojIENPTkZJ
R19CQUNLTElHSFRfTENEX1NVUFBPUlQgaXMgbm90IHNldAoKIwojIERpc3BsYXkgZGV2aWNlIHN1
cHBvcnQKIwojIENPTkZJR19ESVNQTEFZX1NVUFBPUlQgaXMgbm90IHNldAoKIwojIENvbnNvbGUg
ZGlzcGxheSBkcml2ZXIgc3VwcG9ydAojCkNPTkZJR19WR0FfQ09OU09MRT15CiMgQ09ORklHX1ZH
QUNPTl9TT0ZUX1NDUk9MTEJBQ0sgaXMgbm90IHNldApDT05GSUdfRFVNTVlfQ09OU09MRT15CiMg
Q09ORklHX1NPVU5EIGlzIG5vdCBzZXQKQ09ORklHX0hJRF9TVVBQT1JUPXkKQ09ORklHX0hJRD15
CiMgQ09ORklHX0hJRFJBVyBpcyBub3Qgc2V0CgojCiMgVVNCIElucHV0IERldmljZXMKIwpDT05G
SUdfVVNCX0hJRD15CiMgQ09ORklHX0hJRF9QSUQgaXMgbm90IHNldAojIENPTkZJR19VU0JfSElE
REVWIGlzIG5vdCBzZXQKCiMKIyBTcGVjaWFsIEhJRCBkcml2ZXJzCiMKQ09ORklHX0hJRF9BNFRF
Q0g9eQojIENPTkZJR19ISURfQUNSVVggaXMgbm90IHNldApDT05GSUdfSElEX0FQUExFPXkKQ09O
RklHX0hJRF9CRUxLSU49eQpDT05GSUdfSElEX0NIRVJSWT15CkNPTkZJR19ISURfQ0hJQ09OWT15
CkNPTkZJR19ISURfQ1lQUkVTUz15CiMgQ09ORklHX0hJRF9EUkFHT05SSVNFIGlzIG5vdCBzZXQK
IyBDT05GSUdfSElEX0VNU19GRiBpcyBub3Qgc2V0CkNPTkZJR19ISURfRVpLRVk9eQojIENPTkZJ
R19ISURfS0VZVE9VQ0ggaXMgbm90IHNldApDT05GSUdfSElEX0tZRT15CiMgQ09ORklHX0hJRF9V
Q0xPR0lDIGlzIG5vdCBzZXQKIyBDT05GSUdfSElEX1dBTFRPUCBpcyBub3Qgc2V0CiMgQ09ORklH
X0hJRF9HWVJBVElPTiBpcyBub3Qgc2V0CiMgQ09ORklHX0hJRF9UV0lOSEFOIGlzIG5vdCBzZXQK
Q09ORklHX0hJRF9LRU5TSU5HVE9OPXkKIyBDT05GSUdfSElEX0xDUE9XRVIgaXMgbm90IHNldApD
T05GSUdfSElEX0xPR0lURUNIPXkKIyBDT05GSUdfTE9HSVRFQ0hfRkYgaXMgbm90IHNldAojIENP
TkZJR19MT0dJUlVNQkxFUEFEMl9GRiBpcyBub3Qgc2V0CiMgQ09ORklHX0xPR0lHOTQwX0ZGIGlz
IG5vdCBzZXQKIyBDT05GSUdfTE9HSVdJSV9GRiBpcyBub3Qgc2V0CkNPTkZJR19ISURfTUlDUk9T
T0ZUPXkKQ09ORklHX0hJRF9NT05URVJFWT15CiMgQ09ORklHX0hJRF9NVUxUSVRPVUNIIGlzIG5v
dCBzZXQKIyBDT05GSUdfSElEX05UUklHIGlzIG5vdCBzZXQKIyBDT05GSUdfSElEX09SVEVLIGlz
IG5vdCBzZXQKIyBDT05GSUdfSElEX1BBTlRIRVJMT1JEIGlzIG5vdCBzZXQKIyBDT05GSUdfSElE
X1BFVEFMWU5YIGlzIG5vdCBzZXQKIyBDT05GSUdfSElEX1BJQ09MQ0QgaXMgbm90IHNldAojIENP
TkZJR19ISURfUVVBTlRBIGlzIG5vdCBzZXQKIyBDT05GSUdfSElEX1JPQ0NBVCBpcyBub3Qgc2V0
CiMgQ09ORklHX0hJRF9ST0NDQVRfQVJWTyBpcyBub3Qgc2V0CiMgQ09ORklHX0hJRF9ST0NDQVRf
S09ORSBpcyBub3Qgc2V0CiMgQ09ORklHX0hJRF9ST0NDQVRfS09ORVBMVVMgaXMgbm90IHNldAoj
IENPTkZJR19ISURfUk9DQ0FUX0tPVkFQTFVTIGlzIG5vdCBzZXQKIyBDT05GSUdfSElEX1JPQ0NB
VF9QWVJBIGlzIG5vdCBzZXQKIyBDT05GSUdfSElEX1NBTVNVTkcgaXMgbm90IHNldAojIENPTkZJ
R19ISURfU09OWSBpcyBub3Qgc2V0CiMgQ09ORklHX0hJRF9TVU5QTFVTIGlzIG5vdCBzZXQKIyBD
T05GSUdfSElEX0dSRUVOQVNJQSBpcyBub3Qgc2V0CiMgQ09ORklHX0hJRF9TTUFSVEpPWVBMVVMg
aXMgbm90IHNldAojIENPTkZJR19ISURfVE9QU0VFRCBpcyBub3Qgc2V0CiMgQ09ORklHX0hJRF9U
SFJVU1RNQVNURVIgaXMgbm90IHNldAojIENPTkZJR19ISURfWkVST1BMVVMgaXMgbm90IHNldAoj
IENPTkZJR19ISURfWllEQUNST04gaXMgbm90IHNldApDT05GSUdfVVNCX1NVUFBPUlQ9eQpDT05G
SUdfVVNCX0FSQ0hfSEFTX0hDRD15CkNPTkZJR19VU0JfQVJDSF9IQVNfT0hDST15CkNPTkZJR19V
U0JfQVJDSF9IQVNfRUhDST15CkNPTkZJR19VU0I9eQojIENPTkZJR19VU0JfREVCVUcgaXMgbm90
IHNldAojIENPTkZJR19VU0JfQU5OT1VOQ0VfTkVXX0RFVklDRVMgaXMgbm90IHNldAoKIwojIE1p
c2NlbGxhbmVvdXMgVVNCIG9wdGlvbnMKIwojIENPTkZJR19VU0JfREVWSUNFRlMgaXMgbm90IHNl
dAojIENPTkZJR19VU0JfREVWSUNFX0NMQVNTIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX0RZTkFN
SUNfTUlOT1JTIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX09UR19XSElURUxJU1QgaXMgbm90IHNl
dAojIENPTkZJR19VU0JfT1RHX0JMQUNLTElTVF9IVUIgaXMgbm90IHNldAojIENPTkZJR19VU0Jf
TU9OIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX1dVU0IgaXMgbm90IHNldAojIENPTkZJR19VU0Jf
V1VTQl9DQkFGIGlzIG5vdCBzZXQKCiMKIyBVU0IgSG9zdCBDb250cm9sbGVyIERyaXZlcnMKIwoj
IENPTkZJR19VU0JfQzY3WDAwX0hDRCBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9YSENJX0hDRCBp
cyBub3Qgc2V0CkNPTkZJR19VU0JfRUhDSV9IQ0Q9bQpDT05GSUdfVVNCX0VIQ0lfUk9PVF9IVUJf
VFQ9eQpDT05GSUdfVVNCX0VIQ0lfVFRfTkVXU0NIRUQ9eQojIENPTkZJR19VU0JfT1hVMjEwSFBf
SENEIGlzIG5vdCBzZXQKQ09ORklHX1VTQl9JU1AxMTZYX0hDRD1tCiMgQ09ORklHX1VTQl9JU1Ax
NzYwX0hDRCBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9JU1AxMzYyX0hDRCBpcyBub3Qgc2V0CkNP
TkZJR19VU0JfT0hDSV9IQ0Q9bQojIENPTkZJR19VU0JfT0hDSV9IQ0RfU1NCIGlzIG5vdCBzZXQK
IyBDT05GSUdfVVNCX09IQ0lfQklHX0VORElBTl9ERVNDIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNC
X09IQ0lfQklHX0VORElBTl9NTUlPIGlzIG5vdCBzZXQKQ09ORklHX1VTQl9PSENJX0xJVFRMRV9F
TkRJQU49eQpDT05GSUdfVVNCX1VIQ0lfSENEPW0KQ09ORklHX1VTQl9TTDgxMV9IQ0Q9bQojIENP
TkZJR19VU0JfU0w4MTFfSENEX0lTTyBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9SOEE2NjU5N19I
Q0QgaXMgbm90IHNldAojIENPTkZJR19VU0JfV0hDSV9IQ0QgaXMgbm90IHNldAojIENPTkZJR19V
U0JfSFdBX0hDRCBpcyBub3Qgc2V0CgojCiMgVVNCIERldmljZSBDbGFzcyBkcml2ZXJzCiMKIyBD
T05GSUdfVVNCX0FDTSBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9QUklOVEVSIGlzIG5vdCBzZXQK
IyBDT05GSUdfVVNCX1dETSBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9UTUMgaXMgbm90IHNldAoK
IwojIE5PVEU6IFVTQl9TVE9SQUdFIGRlcGVuZHMgb24gU0NTSSBidXQgQkxLX0RFVl9TRCBtYXkK
IwoKIwojIGFsc28gYmUgbmVlZGVkOyBzZWUgVVNCX1NUT1JBR0UgSGVscCBmb3IgbW9yZSBpbmZv
CiMKQ09ORklHX1VTQl9TVE9SQUdFPW0KIyBDT05GSUdfVVNCX1NUT1JBR0VfREVCVUcgaXMgbm90
IHNldAojIENPTkZJR19VU0JfU1RPUkFHRV9SRUFMVEVLIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNC
X1NUT1JBR0VfREFUQUZBQiBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9TVE9SQUdFX0ZSRUVDT00g
aXMgbm90IHNldAojIENPTkZJR19VU0JfU1RPUkFHRV9JU0QyMDAgaXMgbm90IHNldAojIENPTkZJ
R19VU0JfU1RPUkFHRV9VU0JBVCBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9TVE9SQUdFX1NERFIw
OSBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9TVE9SQUdFX1NERFI1NSBpcyBub3Qgc2V0CiMgQ09O
RklHX1VTQl9TVE9SQUdFX0pVTVBTSE9UIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX1NUT1JBR0Vf
QUxBVURBIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX1NUT1JBR0VfT05FVE9VQ0ggaXMgbm90IHNl
dAojIENPTkZJR19VU0JfU1RPUkFHRV9LQVJNQSBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9TVE9S
QUdFX0NZUFJFU1NfQVRBQ0IgaXMgbm90IHNldAojIENPTkZJR19VU0JfU1RPUkFHRV9FTkVfVUI2
MjUwIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX1VBUyBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9M
SUJVU1VBTCBpcyBub3Qgc2V0CgojCiMgVVNCIEltYWdpbmcgZGV2aWNlcwojCiMgQ09ORklHX1VT
Ql9NREM4MDAgaXMgbm90IHNldAojIENPTkZJR19VU0JfTUlDUk9URUsgaXMgbm90IHNldAoKIwoj
IFVTQiBwb3J0IGRyaXZlcnMKIwojIENPTkZJR19VU0JfVVNTNzIwIGlzIG5vdCBzZXQKIyBDT05G
SUdfVVNCX1NFUklBTCBpcyBub3Qgc2V0CgojCiMgVVNCIE1pc2NlbGxhbmVvdXMgZHJpdmVycwoj
CiMgQ09ORklHX1VTQl9FTUk2MiBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9FTUkyNiBpcyBub3Qg
c2V0CiMgQ09ORklHX1VTQl9BRFVUVVggaXMgbm90IHNldAojIENPTkZJR19VU0JfU0VWU0VHIGlz
IG5vdCBzZXQKIyBDT05GSUdfVVNCX1JJTzUwMCBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9MRUdP
VE9XRVIgaXMgbm90IHNldAojIENPTkZJR19VU0JfTENEIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNC
X0xFRCBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9DWVBSRVNTX0NZN0M2MyBpcyBub3Qgc2V0CiMg
Q09ORklHX1VTQl9DWVRIRVJNIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX0lETU9VU0UgaXMgbm90
IHNldAojIENPTkZJR19VU0JfRlRESV9FTEFOIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX0FQUExF
RElTUExBWSBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9TSVNVU0JWR0EgaXMgbm90IHNldAojIENP
TkZJR19VU0JfTEQgaXMgbm90IHNldAojIENPTkZJR19VU0JfVFJBTkNFVklCUkFUT1IgaXMgbm90
IHNldAojIENPTkZJR19VU0JfSU9XQVJSSU9SIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX1RFU1Qg
aXMgbm90IHNldAojIENPTkZJR19VU0JfSVNJR0hURlcgaXMgbm90IHNldAojIENPTkZJR19VU0Jf
WVVSRVggaXMgbm90IHNldAojIENPTkZJR19VU0JfR0FER0VUIGlzIG5vdCBzZXQKCiMKIyBPVEcg
YW5kIHJlbGF0ZWQgaW5mcmFzdHJ1Y3R1cmUKIwojIENPTkZJR19OT1BfVVNCX1hDRUlWIGlzIG5v
dCBzZXQKIyBDT05GSUdfVVdCIGlzIG5vdCBzZXQKIyBDT05GSUdfTU1DIGlzIG5vdCBzZXQKIyBD
T05GSUdfTUVNU1RJQ0sgaXMgbm90IHNldApDT05GSUdfTkVXX0xFRFM9eQpDT05GSUdfTEVEU19D
TEFTUz15CgojCiMgTEVEIGRyaXZlcnMKIwojIENPTkZJR19MRURTX0xNMzUzMCBpcyBub3Qgc2V0
CiMgQ09ORklHX0xFRFNfQUxJWDIgaXMgbm90IHNldAojIENPTkZJR19MRURTX1BDQTk1MzIgaXMg
bm90IHNldAojIENPTkZJR19MRURTX0xQMzk0NCBpcyBub3Qgc2V0CiMgQ09ORklHX0xFRFNfTFA1
NTIxIGlzIG5vdCBzZXQKIyBDT05GSUdfTEVEU19MUDU1MjMgaXMgbm90IHNldAojIENPTkZJR19M
RURTX0NMRVZPX01BSUwgaXMgbm90IHNldAojIENPTkZJR19MRURTX1BDQTk1NVggaXMgbm90IHNl
dAojIENPTkZJR19MRURTX0JEMjgwMiBpcyBub3Qgc2V0CiMgQ09ORklHX0xFRFNfSU5URUxfU1M0
MjAwIGlzIG5vdCBzZXQKIyBDT05GSUdfTEVEU19UUklHR0VSUyBpcyBub3Qgc2V0CgojCiMgTEVE
IFRyaWdnZXJzCiMKIyBDT05GSUdfTkZDX0RFVklDRVMgaXMgbm90IHNldAojIENPTkZJR19BQ0NF
U1NJQklMSVRZIGlzIG5vdCBzZXQKQ09ORklHX0lORklOSUJBTkQ9bQojIENPTkZJR19JTkZJTklC
QU5EX1VTRVJfTUFEIGlzIG5vdCBzZXQKIyBDT05GSUdfSU5GSU5JQkFORF9VU0VSX0FDQ0VTUyBp
cyBub3Qgc2V0CkNPTkZJR19JTkZJTklCQU5EX0FERFJfVFJBTlM9eQpDT05GSUdfSU5GSU5JQkFO
RF9NVEhDQT1tCkNPTkZJR19JTkZJTklCQU5EX01USENBX0RFQlVHPXkKIyBDT05GSUdfSU5GSU5J
QkFORF9BTVNPMTEwMCBpcyBub3Qgc2V0CiMgQ09ORklHX0lORklOSUJBTkRfQ1hHQjMgaXMgbm90
IHNldAojIENPTkZJR19JTkZJTklCQU5EX0NYR0I0IGlzIG5vdCBzZXQKIyBDT05GSUdfTUxYNF9J
TkZJTklCQU5EIGlzIG5vdCBzZXQKIyBDT05GSUdfSU5GSU5JQkFORF9ORVMgaXMgbm90IHNldApD
T05GSUdfSU5GSU5JQkFORF9JUE9JQj1tCiMgQ09ORklHX0lORklOSUJBTkRfSVBPSUJfQ00gaXMg
bm90IHNldApDT05GSUdfSU5GSU5JQkFORF9JUE9JQl9ERUJVRz15CiMgQ09ORklHX0lORklOSUJB
TkRfSVBPSUJfREVCVUdfREFUQSBpcyBub3Qgc2V0CkNPTkZJR19JTkZJTklCQU5EX1NSUD1tCkNP
TkZJR19JTkZJTklCQU5EX0lTRVI9bQojIENPTkZJR19FREFDIGlzIG5vdCBzZXQKIyBDT05GSUdf
UlRDX0NMQVNTIGlzIG5vdCBzZXQKQ09ORklHX0RNQURFVklDRVM9eQojIENPTkZJR19ETUFERVZJ
Q0VTX0RFQlVHIGlzIG5vdCBzZXQKCiMKIyBETUEgRGV2aWNlcwojCkNPTkZJR19JTlRFTF9NSURf
RE1BQz1tCkNPTkZJR19JTlRFTF9JT0FURE1BPW0KQ09ORklHX1RJTUJfRE1BPW0KQ09ORklHX1BD
SF9ETUE9bQpDT05GSUdfRE1BX0VOR0lORT15CgojCiMgRE1BIENsaWVudHMKIwpDT05GSUdfTkVU
X0RNQT15CkNPTkZJR19BU1lOQ19UWF9ETUE9eQpDT05GSUdfRE1BVEVTVD1tCkNPTkZJR19EQ0E9
bQojIENPTkZJR19BVVhESVNQTEFZIGlzIG5vdCBzZXQKIyBDT05GSUdfVUlPIGlzIG5vdCBzZXQK
CiMKIyBYZW4gZHJpdmVyIHN1cHBvcnQKIwpDT05GSUdfWEVOX0JBTExPT049eQpDT05GSUdfWEVO
X1NDUlVCX1BBR0VTPXkKQ09ORklHX1hFTl9ERVZfRVZUQ0hOPXkKQ09ORklHX1hFTl9CQUNLRU5E
PXkKQ09ORklHX1hFTkZTPW0KQ09ORklHX1hFTl9DT01QQVRfWEVORlM9eQpDT05GSUdfWEVOX1NZ
U19IWVBFUlZJU09SPXkKQ09ORklHX1hFTl9HTlRERVY9bQpDT05GSUdfWEVOX0dSQU5UX0RFVl9B
TExPQz1tCkNPTkZJR19YRU5fUExBVEZPUk1fUENJPW0KQ09ORklHX1NXSU9UTEJfWEVOPXkKIyBD
T05GSUdfU1RBR0lORyBpcyBub3Qgc2V0CiMgQ09ORklHX1g4Nl9QTEFURk9STV9ERVZJQ0VTIGlz
IG5vdCBzZXQKQ09ORklHX0NMS1NSQ19JODI1Mz15CgojCiMgRmlybXdhcmUgRHJpdmVycwojCiMg
Q09ORklHX0VERCBpcyBub3Qgc2V0CkNPTkZJR19GSVJNV0FSRV9NRU1NQVA9eQojIENPTkZJR19E
RUxMX1JCVSBpcyBub3Qgc2V0CiMgQ09ORklHX0RDREJBUyBpcyBub3Qgc2V0CkNPTkZJR19ETUlJ
RD15CiMgQ09ORklHX0RNSV9TWVNGUyBpcyBub3Qgc2V0CiMgQ09ORklHX0lTQ1NJX0lCRlRfRklO
RCBpcyBub3Qgc2V0CiMgQ09ORklHX1NJR01BIGlzIG5vdCBzZXQKIyBDT05GSUdfR09PR0xFX0ZJ
Uk1XQVJFIGlzIG5vdCBzZXQKCiMKIyBGaWxlIHN5c3RlbXMKIwpDT05GSUdfRVhUMl9GUz1tCiMg
Q09ORklHX0VYVDJfRlNfWEFUVFIgaXMgbm90IHNldAojIENPTkZJR19FWFQyX0ZTX1hJUCBpcyBu
b3Qgc2V0CkNPTkZJR19FWFQzX0ZTPW0KQ09ORklHX0VYVDNfREVGQVVMVFNfVE9fT1JERVJFRD15
CiMgQ09ORklHX0VYVDNfRlNfWEFUVFIgaXMgbm90IHNldApDT05GSUdfRVhUNF9GUz1tCiMgQ09O
RklHX0VYVDRfRlNfWEFUVFIgaXMgbm90IHNldAojIENPTkZJR19FWFQ0X0RFQlVHIGlzIG5vdCBz
ZXQKQ09ORklHX0pCRD1tCkNPTkZJR19KQkQyPW0KIyBDT05GSUdfUkVJU0VSRlNfRlMgaXMgbm90
IHNldAojIENPTkZJR19KRlNfRlMgaXMgbm90IHNldAojIENPTkZJR19YRlNfRlMgaXMgbm90IHNl
dAojIENPTkZJR19HRlMyX0ZTIGlzIG5vdCBzZXQKIyBDT05GSUdfQlRSRlNfRlMgaXMgbm90IHNl
dAojIENPTkZJR19OSUxGUzJfRlMgaXMgbm90IHNldApDT05GSUdfRlNfUE9TSVhfQUNMPXkKQ09O
RklHX0VYUE9SVEZTPW0KQ09ORklHX0ZJTEVfTE9DS0lORz15CkNPTkZJR19GU05PVElGWT15CkNP
TkZJR19ETk9USUZZPXkKQ09ORklHX0lOT1RJRllfVVNFUj15CiMgQ09ORklHX0ZBTk9USUZZIGlz
IG5vdCBzZXQKIyBDT05GSUdfUVVPVEEgaXMgbm90IHNldAojIENPTkZJR19RVU9UQUNUTCBpcyBu
b3Qgc2V0CkNPTkZJR19BVVRPRlM0X0ZTPXkKQ09ORklHX0ZVU0VfRlM9bQpDT05GSUdfQ1VTRT1t
CgojCiMgQ2FjaGVzCiMKIyBDT05GSUdfRlNDQUNIRSBpcyBub3Qgc2V0CgojCiMgQ0QtUk9NL0RW
RCBGaWxlc3lzdGVtcwojCkNPTkZJR19JU085NjYwX0ZTPW0KQ09ORklHX0pPTElFVD15CkNPTkZJ
R19aSVNPRlM9eQpDT05GSUdfVURGX0ZTPW0KQ09ORklHX1VERl9OTFM9eQoKIwojIERPUy9GQVQv
TlQgRmlsZXN5c3RlbXMKIwojIENPTkZJR19NU0RPU19GUyBpcyBub3Qgc2V0CiMgQ09ORklHX1ZG
QVRfRlMgaXMgbm90IHNldAojIENPTkZJR19OVEZTX0ZTIGlzIG5vdCBzZXQKCiMKIyBQc2V1ZG8g
ZmlsZXN5c3RlbXMKIwpDT05GSUdfUFJPQ19GUz15CkNPTkZJR19QUk9DX0tDT1JFPXkKQ09ORklH
X1BST0NfU1lTQ1RMPXkKQ09ORklHX1BST0NfUEFHRV9NT05JVE9SPXkKQ09ORklHX1NZU0ZTPXkK
Q09ORklHX1RNUEZTPXkKIyBDT05GSUdfVE1QRlNfUE9TSVhfQUNMIGlzIG5vdCBzZXQKIyBDT05G
SUdfVE1QRlNfWEFUVFIgaXMgbm90IHNldAojIENPTkZJR19IVUdFVExCRlMgaXMgbm90IHNldAoj
IENPTkZJR19IVUdFVExCX1BBR0UgaXMgbm90IHNldAojIENPTkZJR19DT05GSUdGU19GUyBpcyBu
b3Qgc2V0CkNPTkZJR19NSVNDX0ZJTEVTWVNURU1TPXkKIyBDT05GSUdfQURGU19GUyBpcyBub3Qg
c2V0CiMgQ09ORklHX0FGRlNfRlMgaXMgbm90IHNldAojIENPTkZJR19IRlNfRlMgaXMgbm90IHNl
dAojIENPTkZJR19IRlNQTFVTX0ZTIGlzIG5vdCBzZXQKIyBDT05GSUdfQkVGU19GUyBpcyBub3Qg
c2V0CiMgQ09ORklHX0JGU19GUyBpcyBub3Qgc2V0CiMgQ09ORklHX0VGU19GUyBpcyBub3Qgc2V0
CiMgQ09ORklHX0xPR0ZTIGlzIG5vdCBzZXQKQ09ORklHX0NSQU1GUz1tCiMgQ09ORklHX1NRVUFT
SEZTIGlzIG5vdCBzZXQKIyBDT05GSUdfVlhGU19GUyBpcyBub3Qgc2V0CiMgQ09ORklHX01JTklY
X0ZTIGlzIG5vdCBzZXQKIyBDT05GSUdfT01GU19GUyBpcyBub3Qgc2V0CiMgQ09ORklHX0hQRlNf
RlMgaXMgbm90IHNldAojIENPTkZJR19RTlg0RlNfRlMgaXMgbm90IHNldAojIENPTkZJR19ST01G
U19GUyBpcyBub3Qgc2V0CiMgQ09ORklHX1BTVE9SRSBpcyBub3Qgc2V0CiMgQ09ORklHX1NZU1Zf
RlMgaXMgbm90IHNldAojIENPTkZJR19VRlNfRlMgaXMgbm90IHNldApDT05GSUdfTkVUV09SS19G
SUxFU1lTVEVNUz15CkNPTkZJR19ORlNfRlM9bQpDT05GSUdfTkZTX1YzPXkKIyBDT05GSUdfTkZT
X1YzX0FDTCBpcyBub3Qgc2V0CiMgQ09ORklHX05GU19WNCBpcyBub3Qgc2V0CkNPTkZJR19ORlNE
PW0KQ09ORklHX05GU0RfREVQUkVDQVRFRD15CkNPTkZJR19ORlNEX1YyX0FDTD15CkNPTkZJR19O
RlNEX1YzPXkKQ09ORklHX05GU0RfVjNfQUNMPXkKQ09ORklHX05GU0RfVjQ9eQpDT05GSUdfTE9D
S0Q9bQpDT05GSUdfTE9DS0RfVjQ9eQpDT05GSUdfTkZTX0FDTF9TVVBQT1JUPW0KQ09ORklHX05G
U19DT01NT049eQpDT05GSUdfU1VOUlBDPW0KQ09ORklHX1NVTlJQQ19HU1M9bQpDT05GSUdfU1VO
UlBDX1hQUlRfUkRNQT1tCiMgQ09ORklHX0NFUEhfRlMgaXMgbm90IHNldApDT05GSUdfQ0lGUz1t
CiMgQ09ORklHX0NJRlNfU1RBVFMgaXMgbm90IHNldAojIENPTkZJR19DSUZTX1dFQUtfUFdfSEFT
SCBpcyBub3Qgc2V0CkNPTkZJR19DSUZTX1hBVFRSPXkKQ09ORklHX0NJRlNfUE9TSVg9eQojIENP
TkZJR19DSUZTX0RFQlVHMiBpcyBub3Qgc2V0CiMgQ09ORklHX05DUF9GUyBpcyBub3Qgc2V0CiMg
Q09ORklHX0NPREFfRlMgaXMgbm90IHNldAojIENPTkZJR19BRlNfRlMgaXMgbm90IHNldAoKIwoj
IFBhcnRpdGlvbiBUeXBlcwojCiMgQ09ORklHX1BBUlRJVElPTl9BRFZBTkNFRCBpcyBub3Qgc2V0
CkNPTkZJR19NU0RPU19QQVJUSVRJT049eQpDT05GSUdfTkxTPXkKQ09ORklHX05MU19ERUZBVUxU
PSJpc284ODU5LTEiCkNPTkZJR19OTFNfQ09ERVBBR0VfNDM3PXkKIyBDT05GSUdfTkxTX0NPREVQ
QUdFXzczNyBpcyBub3Qgc2V0CiMgQ09ORklHX05MU19DT0RFUEFHRV83NzUgaXMgbm90IHNldAoj
IENPTkZJR19OTFNfQ09ERVBBR0VfODUwIGlzIG5vdCBzZXQKIyBDT05GSUdfTkxTX0NPREVQQUdF
Xzg1MiBpcyBub3Qgc2V0CiMgQ09ORklHX05MU19DT0RFUEFHRV84NTUgaXMgbm90IHNldAojIENP
TkZJR19OTFNfQ09ERVBBR0VfODU3IGlzIG5vdCBzZXQKIyBDT05GSUdfTkxTX0NPREVQQUdFXzg2
MCBpcyBub3Qgc2V0CiMgQ09ORklHX05MU19DT0RFUEFHRV84NjEgaXMgbm90IHNldAojIENPTkZJ
R19OTFNfQ09ERVBBR0VfODYyIGlzIG5vdCBzZXQKIyBDT05GSUdfTkxTX0NPREVQQUdFXzg2MyBp
cyBub3Qgc2V0CiMgQ09ORklHX05MU19DT0RFUEFHRV84NjQgaXMgbm90IHNldAojIENPTkZJR19O
TFNfQ09ERVBBR0VfODY1IGlzIG5vdCBzZXQKIyBDT05GSUdfTkxTX0NPREVQQUdFXzg2NiBpcyBu
b3Qgc2V0CiMgQ09ORklHX05MU19DT0RFUEFHRV84NjkgaXMgbm90IHNldAojIENPTkZJR19OTFNf
Q09ERVBBR0VfOTM2IGlzIG5vdCBzZXQKIyBDT05GSUdfTkxTX0NPREVQQUdFXzk1MCBpcyBub3Qg
c2V0CiMgQ09ORklHX05MU19DT0RFUEFHRV85MzIgaXMgbm90IHNldAojIENPTkZJR19OTFNfQ09E
RVBBR0VfOTQ5IGlzIG5vdCBzZXQKIyBDT05GSUdfTkxTX0NPREVQQUdFXzg3NCBpcyBub3Qgc2V0
CiMgQ09ORklHX05MU19JU084ODU5XzggaXMgbm90IHNldAojIENPTkZJR19OTFNfQ09ERVBBR0Vf
MTI1MCBpcyBub3Qgc2V0CiMgQ09ORklHX05MU19DT0RFUEFHRV8xMjUxIGlzIG5vdCBzZXQKIyBD
T05GSUdfTkxTX0FTQ0lJIGlzIG5vdCBzZXQKQ09ORklHX05MU19JU084ODU5XzE9eQojIENPTkZJ
R19OTFNfSVNPODg1OV8yIGlzIG5vdCBzZXQKIyBDT05GSUdfTkxTX0lTTzg4NTlfMyBpcyBub3Qg
c2V0CiMgQ09ORklHX05MU19JU084ODU5XzQgaXMgbm90IHNldAojIENPTkZJR19OTFNfSVNPODg1
OV81IGlzIG5vdCBzZXQKIyBDT05GSUdfTkxTX0lTTzg4NTlfNiBpcyBub3Qgc2V0CiMgQ09ORklH
X05MU19JU084ODU5XzcgaXMgbm90IHNldAojIENPTkZJR19OTFNfSVNPODg1OV85IGlzIG5vdCBz
ZXQKIyBDT05GSUdfTkxTX0lTTzg4NTlfMTMgaXMgbm90IHNldAojIENPTkZJR19OTFNfSVNPODg1
OV8xNCBpcyBub3Qgc2V0CiMgQ09ORklHX05MU19JU084ODU5XzE1IGlzIG5vdCBzZXQKIyBDT05G
SUdfTkxTX0tPSThfUiBpcyBub3Qgc2V0CiMgQ09ORklHX05MU19LT0k4X1UgaXMgbm90IHNldApD
T05GSUdfTkxTX1VURjg9eQoKIwojIEtlcm5lbCBoYWNraW5nCiMKQ09ORklHX1RSQUNFX0lSUUZM
QUdTX1NVUFBPUlQ9eQpDT05GSUdfUFJJTlRLX1RJTUU9eQpDT05GSUdfREVGQVVMVF9NRVNTQUdF
X0xPR0xFVkVMPTQKQ09ORklHX0VOQUJMRV9XQVJOX0RFUFJFQ0FURUQ9eQpDT05GSUdfRU5BQkxF
X01VU1RfQ0hFQ0s9eQpDT05GSUdfRlJBTUVfV0FSTj0xMDI0CkNPTkZJR19NQUdJQ19TWVNSUT15
CiMgQ09ORklHX1NUUklQX0FTTV9TWU1TIGlzIG5vdCBzZXQKIyBDT05GSUdfVU5VU0VEX1NZTUJP
TFMgaXMgbm90IHNldAojIENPTkZJR19ERUJVR19GUyBpcyBub3Qgc2V0CiMgQ09ORklHX0hFQURF
UlNfQ0hFQ0sgaXMgbm90IHNldAojIENPTkZJR19ERUJVR19TRUNUSU9OX01JU01BVENIIGlzIG5v
dCBzZXQKIyBDT05GSUdfREVCVUdfS0VSTkVMIGlzIG5vdCBzZXQKIyBDT05GSUdfSEFSRExPQ0tV
UF9ERVRFQ1RPUiBpcyBub3Qgc2V0CiMgQ09ORklHX1NQQVJTRV9SQ1VfUE9JTlRFUiBpcyBub3Qg
c2V0CkNPTkZJR19ERUJVR19CVUdWRVJCT1NFPXkKQ09ORklHX0RFQlVHX01FTU9SWV9JTklUPXkK
Q09ORklHX0FSQ0hfV0FOVF9GUkFNRV9QT0lOVEVSUz15CkNPTkZJR19GUkFNRV9QT0lOVEVSPXkK
Q09ORklHX1JDVV9DUFVfU1RBTExfVElNRU9VVD02MAojIENPTkZJR19TWVNDVExfU1lTQ0FMTF9D
SEVDSyBpcyBub3Qgc2V0CkNPTkZJR19VU0VSX1NUQUNLVFJBQ0VfU1VQUE9SVD15CkNPTkZJR19I
QVZFX0ZVTkNUSU9OX1RSQUNFUj15CkNPTkZJR19IQVZFX0ZVTkNUSU9OX0dSQVBIX1RSQUNFUj15
CkNPTkZJR19IQVZFX0ZVTkNUSU9OX0dSQVBIX0ZQX1RFU1Q9eQpDT05GSUdfSEFWRV9GVU5DVElP
Tl9UUkFDRV9NQ09VTlRfVEVTVD15CkNPTkZJR19IQVZFX0RZTkFNSUNfRlRSQUNFPXkKQ09ORklH
X0hBVkVfRlRSQUNFX01DT1VOVF9SRUNPUkQ9eQpDT05GSUdfSEFWRV9TWVNDQUxMX1RSQUNFUE9J
TlRTPXkKQ09ORklHX0hBVkVfQ19SRUNPUkRNQ09VTlQ9eQpDT05GSUdfVFJBQ0lOR19TVVBQT1JU
PXkKIyBDT05GSUdfRlRSQUNFIGlzIG5vdCBzZXQKIyBDT05GSUdfUFJPVklERV9PSENJMTM5NF9E
TUFfSU5JVCBpcyBub3Qgc2V0CiMgQ09ORklHX0RNQV9BUElfREVCVUcgaXMgbm90IHNldAojIENP
TkZJR19BVE9NSUM2NF9TRUxGVEVTVCBpcyBub3Qgc2V0CiMgQ09ORklHX0FTWU5DX1JBSUQ2X1RF
U1QgaXMgbm90IHNldAojIENPTkZJR19TQU1QTEVTIGlzIG5vdCBzZXQKQ09ORklHX0hBVkVfQVJD
SF9LR0RCPXkKQ09ORklHX0hBVkVfQVJDSF9LTUVNQ0hFQ0s9eQojIENPTkZJR19URVNUX0tTVFJU
T1ggaXMgbm90IHNldAojIENPTkZJR19TVFJJQ1RfREVWTUVNIGlzIG5vdCBzZXQKQ09ORklHX1g4
Nl9WRVJCT1NFX0JPT1RVUD15CkNPTkZJR19FQVJMWV9QUklOVEs9eQojIENPTkZJR19FQVJMWV9Q
UklOVEtfREJHUCBpcyBub3Qgc2V0CiMgQ09ORklHX0RFQlVHX1NFVF9NT0RVTEVfUk9OWCBpcyBu
b3Qgc2V0CkNPTkZJR19ET1VCTEVGQVVMVD15CiMgQ09ORklHX0lPTU1VX1NUUkVTUyBpcyBub3Qg
c2V0CkNPTkZJR19IQVZFX01NSU9UUkFDRV9TVVBQT1JUPXkKQ09ORklHX0lPX0RFTEFZX1RZUEVf
MFg4MD0wCkNPTkZJR19JT19ERUxBWV9UWVBFXzBYRUQ9MQpDT05GSUdfSU9fREVMQVlfVFlQRV9V
REVMQVk9MgpDT05GSUdfSU9fREVMQVlfVFlQRV9OT05FPTMKQ09ORklHX0lPX0RFTEFZXzBYODA9
eQojIENPTkZJR19JT19ERUxBWV8wWEVEIGlzIG5vdCBzZXQKIyBDT05GSUdfSU9fREVMQVlfVURF
TEFZIGlzIG5vdCBzZXQKIyBDT05GSUdfSU9fREVMQVlfTk9ORSBpcyBub3Qgc2V0CkNPTkZJR19E
RUZBVUxUX0lPX0RFTEFZX1RZUEU9MAojIENPTkZJR19PUFRJTUlaRV9JTkxJTklORyBpcyBub3Qg
c2V0CgojCiMgU2VjdXJpdHkgb3B0aW9ucwojCiMgQ09ORklHX0tFWVMgaXMgbm90IHNldAojIENP
TkZJR19TRUNVUklUWV9ETUVTR19SRVNUUklDVCBpcyBub3Qgc2V0CiMgQ09ORklHX1NFQ1VSSVRZ
IGlzIG5vdCBzZXQKIyBDT05GSUdfU0VDVVJJVFlGUyBpcyBub3Qgc2V0CkNPTkZJR19ERUZBVUxU
X1NFQ1VSSVRZX0RBQz15CkNPTkZJR19ERUZBVUxUX1NFQ1VSSVRZPSIiCkNPTkZJR19YT1JfQkxP
Q0tTPW0KQ09ORklHX0FTWU5DX0NPUkU9bQpDT05GSUdfQVNZTkNfTUVNQ1BZPW0KQ09ORklHX0FT
WU5DX1hPUj1tCkNPTkZJR19BU1lOQ19QUT1tCkNPTkZJR19BU1lOQ19SQUlENl9SRUNPVj1tCkNP
TkZJR19BU1lOQ19UWF9ESVNBQkxFX1BRX1ZBTF9ETUE9eQpDT05GSUdfQVNZTkNfVFhfRElTQUJM
RV9YT1JfVkFMX0RNQT15CkNPTkZJR19DUllQVE89eQoKIwojIENyeXB0byBjb3JlIG9yIGhlbHBl
cgojCkNPTkZJR19DUllQVE9fQUxHQVBJPXkKQ09ORklHX0NSWVBUT19BTEdBUEkyPXkKQ09ORklH
X0NSWVBUT19BRUFEPW0KQ09ORklHX0NSWVBUT19BRUFEMj15CkNPTkZJR19DUllQVE9fQkxLQ0lQ
SEVSPW0KQ09ORklHX0NSWVBUT19CTEtDSVBIRVIyPXkKQ09ORklHX0NSWVBUT19IQVNIPXkKQ09O
RklHX0NSWVBUT19IQVNIMj15CkNPTkZJR19DUllQVE9fUk5HPW0KQ09ORklHX0NSWVBUT19STkcy
PXkKQ09ORklHX0NSWVBUT19QQ09NUDI9eQpDT05GSUdfQ1JZUFRPX01BTkFHRVI9eQpDT05GSUdf
Q1JZUFRPX01BTkFHRVIyPXkKQ09ORklHX0NSWVBUT19NQU5BR0VSX0RJU0FCTEVfVEVTVFM9eQoj
IENPTkZJR19DUllQVE9fR0YxMjhNVUwgaXMgbm90IHNldAojIENPTkZJR19DUllQVE9fTlVMTCBp
cyBub3Qgc2V0CiMgQ09ORklHX0NSWVBUT19QQ1JZUFQgaXMgbm90IHNldApDT05GSUdfQ1JZUFRP
X1dPUktRVUVVRT15CiMgQ09ORklHX0NSWVBUT19DUllQVEQgaXMgbm90IHNldApDT05GSUdfQ1JZ
UFRPX0FVVEhFTkM9bQojIENPTkZJR19DUllQVE9fVEVTVCBpcyBub3Qgc2V0CgojCiMgQXV0aGVu
dGljYXRlZCBFbmNyeXB0aW9uIHdpdGggQXNzb2NpYXRlZCBEYXRhCiMKIyBDT05GSUdfQ1JZUFRP
X0NDTSBpcyBub3Qgc2V0CiMgQ09ORklHX0NSWVBUT19HQ00gaXMgbm90IHNldAojIENPTkZJR19D
UllQVE9fU0VRSVYgaXMgbm90IHNldAoKIwojIEJsb2NrIG1vZGVzCiMKQ09ORklHX0NSWVBUT19D
QkM9bQojIENPTkZJR19DUllQVE9fQ1RSIGlzIG5vdCBzZXQKIyBDT05GSUdfQ1JZUFRPX0NUUyBp
cyBub3Qgc2V0CkNPTkZJR19DUllQVE9fRUNCPW0KIyBDT05GSUdfQ1JZUFRPX0xSVyBpcyBub3Qg
c2V0CiMgQ09ORklHX0NSWVBUT19QQ0JDIGlzIG5vdCBzZXQKIyBDT05GSUdfQ1JZUFRPX1hUUyBp
cyBub3Qgc2V0CgojCiMgSGFzaCBtb2RlcwojCkNPTkZJR19DUllQVE9fSE1BQz15CiMgQ09ORklH
X0NSWVBUT19YQ0JDIGlzIG5vdCBzZXQKIyBDT05GSUdfQ1JZUFRPX1ZNQUMgaXMgbm90IHNldAoK
IwojIERpZ2VzdAojCkNPTkZJR19DUllQVE9fQ1JDMzJDPXkKIyBDT05GSUdfQ1JZUFRPX0NSQzMy
Q19JTlRFTCBpcyBub3Qgc2V0CiMgQ09ORklHX0NSWVBUT19HSEFTSCBpcyBub3Qgc2V0CkNPTkZJ
R19DUllQVE9fTUQ0PW0KQ09ORklHX0NSWVBUT19NRDU9eQojIENPTkZJR19DUllQVE9fTUlDSEFF
TF9NSUMgaXMgbm90IHNldAojIENPTkZJR19DUllQVE9fUk1EMTI4IGlzIG5vdCBzZXQKIyBDT05G
SUdfQ1JZUFRPX1JNRDE2MCBpcyBub3Qgc2V0CiMgQ09ORklHX0NSWVBUT19STUQyNTYgaXMgbm90
IHNldAojIENPTkZJR19DUllQVE9fUk1EMzIwIGlzIG5vdCBzZXQKQ09ORklHX0NSWVBUT19TSEEx
PW0KIyBDT05GSUdfQ1JZUFRPX1NIQTI1NiBpcyBub3Qgc2V0CiMgQ09ORklHX0NSWVBUT19TSEE1
MTIgaXMgbm90IHNldAojIENPTkZJR19DUllQVE9fVEdSMTkyIGlzIG5vdCBzZXQKIyBDT05GSUdf
Q1JZUFRPX1dQNTEyIGlzIG5vdCBzZXQKCiMKIyBDaXBoZXJzCiMKQ09ORklHX0NSWVBUT19BRVM9
bQojIENPTkZJR19DUllQVE9fQUVTXzU4NiBpcyBub3Qgc2V0CiMgQ09ORklHX0NSWVBUT19BRVNf
TklfSU5URUwgaXMgbm90IHNldAojIENPTkZJR19DUllQVE9fQU5VQklTIGlzIG5vdCBzZXQKQ09O
RklHX0NSWVBUT19BUkM0PW0KIyBDT05GSUdfQ1JZUFRPX0JMT1dGSVNIIGlzIG5vdCBzZXQKIyBD
T05GSUdfQ1JZUFRPX0NBTUVMTElBIGlzIG5vdCBzZXQKIyBDT05GSUdfQ1JZUFRPX0NBU1Q1IGlz
IG5vdCBzZXQKIyBDT05GSUdfQ1JZUFRPX0NBU1Q2IGlzIG5vdCBzZXQKQ09ORklHX0NSWVBUT19E
RVM9bQojIENPTkZJR19DUllQVE9fRkNSWVBUIGlzIG5vdCBzZXQKIyBDT05GSUdfQ1JZUFRPX0tI
QVpBRCBpcyBub3Qgc2V0CiMgQ09ORklHX0NSWVBUT19TQUxTQTIwIGlzIG5vdCBzZXQKIyBDT05G
SUdfQ1JZUFRPX1NBTFNBMjBfNTg2IGlzIG5vdCBzZXQKIyBDT05GSUdfQ1JZUFRPX1NFRUQgaXMg
bm90IHNldAojIENPTkZJR19DUllQVE9fU0VSUEVOVCBpcyBub3Qgc2V0CiMgQ09ORklHX0NSWVBU
T19URUEgaXMgbm90IHNldAojIENPTkZJR19DUllQVE9fVFdPRklTSCBpcyBub3Qgc2V0CiMgQ09O
RklHX0NSWVBUT19UV09GSVNIXzU4NiBpcyBub3Qgc2V0CgojCiMgQ29tcHJlc3Npb24KIwpDT05G
SUdfQ1JZUFRPX0RFRkxBVEU9bQojIENPTkZJR19DUllQVE9fWkxJQiBpcyBub3Qgc2V0CiMgQ09O
RklHX0NSWVBUT19MWk8gaXMgbm90IHNldAoKIwojIFJhbmRvbSBOdW1iZXIgR2VuZXJhdGlvbgoj
CkNPTkZJR19DUllQVE9fQU5TSV9DUFJORz1tCiMgQ09ORklHX0NSWVBUT19VU0VSX0FQSV9IQVNI
IGlzIG5vdCBzZXQKIyBDT05GSUdfQ1JZUFRPX1VTRVJfQVBJX1NLQ0lQSEVSIGlzIG5vdCBzZXQK
Q09ORklHX0NSWVBUT19IVz15CiMgQ09ORklHX0NSWVBUT19ERVZfUEFETE9DSyBpcyBub3Qgc2V0
CiMgQ09ORklHX0NSWVBUT19ERVZfR0VPREUgaXMgbm90IHNldAojIENPTkZJR19DUllQVE9fREVW
X0hJRk5fNzk1WCBpcyBub3Qgc2V0CkNPTkZJR19IQVZFX0tWTT15CiMgQ09ORklHX1ZJUlRVQUxJ
WkFUSU9OIGlzIG5vdCBzZXQKIyBDT05GSUdfQklOQVJZX1BSSU5URiBpcyBub3Qgc2V0CgojCiMg
TGlicmFyeSByb3V0aW5lcwojCkNPTkZJR19SQUlENl9QUT1tCkNPTkZJR19CSVRSRVZFUlNFPXkK
Q09ORklHX0dFTkVSSUNfRklORF9GSVJTVF9CSVQ9eQpDT05GSUdfQ1JDX0NDSVRUPW0KQ09ORklH
X0NSQzE2PW0KIyBDT05GSUdfQ1JDX1QxMERJRiBpcyBub3Qgc2V0CkNPTkZJR19DUkNfSVRVX1Q9
bQpDT05GSUdfQ1JDMzI9eQojIENPTkZJR19DUkM3IGlzIG5vdCBzZXQKQ09ORklHX0xJQkNSQzMy
Qz15CkNPTkZJR19aTElCX0lORkxBVEU9eQpDT05GSUdfWkxJQl9ERUZMQVRFPW0KQ09ORklHX1ha
X0RFQz15CkNPTkZJR19YWl9ERUNfWDg2PXkKQ09ORklHX1haX0RFQ19QT1dFUlBDPXkKQ09ORklH
X1haX0RFQ19JQTY0PXkKQ09ORklHX1haX0RFQ19BUk09eQpDT05GSUdfWFpfREVDX0FSTVRIVU1C
PXkKQ09ORklHX1haX0RFQ19TUEFSQz15CkNPTkZJR19YWl9ERUNfQkNKPXkKIyBDT05GSUdfWFpf
REVDX1RFU1QgaXMgbm90IHNldApDT05GSUdfREVDT01QUkVTU19HWklQPXkKQ09ORklHX0RFQ09N
UFJFU1NfQlpJUDI9eQpDT05GSUdfVEVYVFNFQVJDSD15CkNPTkZJR19URVhUU0VBUkNIX0tNUD1t
CkNPTkZJR19URVhUU0VBUkNIX0JNPW0KQ09ORklHX1RFWFRTRUFSQ0hfRlNNPW0KQ09ORklHX0hB
U19JT01FTT15CkNPTkZJR19IQVNfSU9QT1JUPXkKQ09ORklHX0hBU19ETUE9eQpDT05GSUdfQ0hF
Q0tfU0lHTkFUVVJFPXkKQ09ORklHX0NQVV9STUFQPXkKQ09ORklHX05MQVRUUj15CiMgQ09ORklH
X0FWRVJBR0UgaXMgbm90IHNldAo=

--_005_3E243B26F475504B9BB0BCC9728B0DA629E16E01USILMS110Acacom_
Content-Type: application/octet-stream; name="messages"
Content-Description: messages
Content-Disposition: attachment; filename="messages"; size=45246;
	creation-date="Fri, 09 Dec 2011 20:00:35 GMT";
	modification-date="Fri, 09 Dec 2011 19:59:15 GMT"
Content-Transfer-Encoding: base64

RGVjICAxIDA0OjAyOjAxIEdyaWRvc19Ob2RlIHN5c2xvZ2QgMS40LjE6IHJlc3RhcnQuCkRlYyAg
MSAwNDowMjowMSBHcmlkb3NfTm9kZSBsb2dyb3RhdGU6IEFMRVJUIGV4aXRlZCBhYm5vcm1hbGx5
IHdpdGggWzFdCkRlYyAgMSAxNTo0NDowNSBHcmlkb3NfTm9kZSBzaHV0ZG93blsyMjkyNV06IHNo
dXR0aW5nIGRvd24gZm9yIHN5c3RlbSByZWJvb3QKRGVjICAxIDE1OjQ0OjA1IEdyaWRvc19Ob2Rl
IGluaXQ6IFN3aXRjaGluZyB0byBydW5sZXZlbDogNgpEZWMgIDEgMTU6NDQ6MDYgR3JpZG9zX05v
ZGUgc21hcnRkWzIwNjJdOiBzbWFydGQgcmVjZWl2ZWQgc2lnbmFsIDE1OiBUZXJtaW5hdGVkIApE
ZWMgIDEgMTU6NDQ6MDYgR3JpZG9zX05vZGUgc21hcnRkWzIwNjJdOiBzbWFydGQgaXMgZXhpdGlu
ZyAoZXhpdCBzdGF0dXMgMCkgCkRlYyAgMSAxNTo0NDowNyBHcmlkb3NfTm9kZSBrZXJuZWw6IEtl
cm5lbCBsb2dnaW5nIChwcm9jKSBzdG9wcGVkLgpEZWMgIDEgMTU6NDQ6MDcgR3JpZG9zX05vZGUg
a2VybmVsOiBLZXJuZWwgbG9nIGRhZW1vbiB0ZXJtaW5hdGluZy4KRGVjICAxIDE1OjQ0OjA4IEdy
aWRvc19Ob2RlIGV4aXRpbmcgb24gc2lnbmFsIDE1CkRlYyAgMSAxNTo1NToxNyBHcmlkb3NfTm9k
ZSBzeXNsb2dkIDEuNC4xOiByZXN0YXJ0LgpEZWMgIDEgMTU6NTU6MTcgR3JpZG9zX05vZGUga2Vy
bmVsOiBrbG9nZCAxLjQuMSwgbG9nIHNvdXJjZSA9IC9wcm9jL2ttc2cgc3RhcnRlZC4KRGVjICAx
IDE1OjU1OjE3IEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgICAwLjAwMDAwMF0gUmVzZXJ2aW5nIHZp
cnR1YWwgYWRkcmVzcyBzcGFjZSBhYm92ZSAweGZmODAwMDAwCkRlYyAgMSAxNTo1NToxNyBHcmlk
b3NfTm9kZSBrZXJuZWw6IFsgICAgMC4wMDAwMDBdIExpbnV4IHZlcnNpb24gMy4wLjQtMzMueGVu
MCAocm9vdEBudC1kZXYtQ2VudDU1LTMyKSAoZ2NjIHZlcnNpb24gNC4xLjIgMjAwODA3MDQgKFJl
ZCBIYXQgNC4xLjItNDgpKSAjMSBTTVAgTW9uIE5vdiAyMSAxODo0Njo1MCBFU1QgMjAxMQpEZWMg
IDEgMTU6NTU6MTcgR3JpZG9zX05vZGUga2VybmVsOiBbICAgIDAuMDAwMDAwXSByZWxlYXNlZCAw
IHBhZ2VzIG9mIHVudXNlZCBtZW1vcnkKRGVjICAxIDE1OjU1OjE3IEdyaWRvc19Ob2RlIGtlcm5l
bDogWyAgICAwLjAwMDAwMF0gU2V0IDI2MjMwNCBwYWdlKHMpIHRvIDEtMSBtYXBwaW5nLgpEZWMg
IDEgMTU6NTU6MTcgR3JpZG9zX05vZGUga2VybmVsOiBbICAgIDAuMDAwMDAwXSBCSU9TLXByb3Zp
ZGVkIHBoeXNpY2FsIFJBTSBtYXA6CkRlYyAgMSAxNTo1NToxNyBHcmlkb3NfTm9kZSBrZXJuZWw6
IFsgICAgMC4wMDAwMDBdICBYZW46IDAwMDAwMDAwMDAwMDAwMDAgLSAwMDAwMDAwMDAwMGEwMDAw
ICh1c2FibGUpCkRlYyAgMSAxNTo1NToxNyBHcmlkb3NfTm9kZSBrZXJuZWw6IFsgICAgMC4wMDAw
MDBdICBYZW46IDAwMDAwMDAwMDAwYTAwMDAgLSAwMDAwMDAwMDAwMTAwMDAwIChyZXNlcnZlZCkK
RGVjICAxIDE1OjU1OjE3IEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgICAwLjAwMDAwMF0gIFhlbjog
MDAwMDAwMDAwMDEwMDAwMCAtIDAwMDAwMDAwMjAwMDAwMDAgKHVzYWJsZSkKRGVjICAxIDE1OjU1
OjE3IEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgICAwLjAwMDAwMF0gIFhlbjogMDAwMDAwMDAyMDAw
MDAwMCAtIDAwMDAwMDAwYmZmYzAwMDAgKHVudXNhYmxlKQpEZWMgIDEgMTU6NTU6MTcgR3JpZG9z
X05vZGUga2VybmVsOiBbICAgIDAuMDAwMDAwXSAgWGVuOiAwMDAwMDAwMGJmZmMwMDAwIC0gMDAw
MDAwMDBiZmZjZmMwMCAoQUNQSSBkYXRhKQpEZWMgIDEgMTU6NTU6MTcgR3JpZG9zX05vZGUga2Vy
bmVsOiBbICAgIDAuMDAwMDAwXSAgWGVuOiAwMDAwMDAwMGJmZmNmYzAwIC0gMDAwMDAwMDBiZmZm
ZjAwMCAocmVzZXJ2ZWQpCkRlYyAgMSAxNTo1NToxNyBHcmlkb3NfTm9kZSBrZXJuZWw6IFsgICAg
MC4wMDAwMDBdICBYZW46IDAwMDAwMDAwZTAwMDAwMDAgLSAwMDAwMDAwMGZlYzkwMDAwIChyZXNl
cnZlZCkKRGVjICAxIDE1OjU1OjE3IEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgICAwLjAwMDAwMF0g
IFhlbjogMDAwMDAwMDBmZWQwMDAwMCAtIDAwMDAwMDAwZmVkMDA0MDAgKHJlc2VydmVkKQpEZWMg
IDEgMTU6NTU6MTcgR3JpZG9zX05vZGUga2VybmVsOiBbICAgIDAuMDAwMDAwXSAgWGVuOiAwMDAw
MDAwMGZlZTAwMDAwIC0gMDAwMDAwMDBmZWUxMDAwMCAocmVzZXJ2ZWQpCkRlYyAgMSAxNTo1NTox
NyBHcmlkb3NfTm9kZSBrZXJuZWw6IFsgICAgMC4wMDAwMDBdICBYZW46IDAwMDAwMDAwZmZiMDAw
MDAgLSAwMDAwMDAwMTAwMDAwMDAwIChyZXNlcnZlZCkKRGVjICAxIDE1OjU1OjE3IEdyaWRvc19O
b2RlIGtlcm5lbDogWyAgICAwLjAwMDAwMF0gIFhlbjogMDAwMDAwMDEwMDAwMDAwMCAtIDAwMDAw
MDAxZGZmYzAwMDAgKHVzYWJsZSkKRGVjICAxIDE1OjU1OjE3IEdyaWRvc19Ob2RlIGtlcm5lbDog
WyAgICAwLjAwMDAwMF0gTlggKEV4ZWN1dGUgRGlzYWJsZSkgcHJvdGVjdGlvbjogYWN0aXZlCkRl
YyAgMSAxNTo1NToxNyBHcmlkb3NfTm9kZSBrZXJuZWw6IFsgICAgMC4wMDAwMDBdIERNSSAyLjMg
cHJlc2VudC4KRGVjICAxIDE1OjU1OjE3IEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgICAwLjAwMDAw
MF0gbGFzdF9wZm4gPSAweDFkZmZjMCBtYXhfYXJjaF9wZm4gPSAweDEwMDAwMDAKRGVjICAxIDE1
OjU1OjE3IEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgICAwLjAwMDAwMF0gZm91bmQgU01QIE1QLXRh
YmxlIGF0IFtjMDBmZTcxMF0gZmU3MTAKRGVjICAxIDE1OjU1OjE3IEdyaWRvc19Ob2RlIGtlcm5l
bDogWyAgICAwLjAwMDAwMF0gaW5pdF9tZW1vcnlfbWFwcGluZzogMDAwMDAwMDAwMDAwMDAwMC0w
MDAwMDAwMDM3M2ZlMDAwCkRlYyAgMSAxNTo1NToxNyBHcmlkb3NfTm9kZSBrZXJuZWw6IFsgICAg
MC4wMDAwMDBdIFJBTURJU0s6IDAxNjY3MDAwIC0gMDFhMWUwMDAKRGVjICAxIDE1OjU1OjE3IEdy
aWRvc19Ob2RlIGtlcm5lbDogWyAgICAwLjAwMDAwMF0gQUNQSTogUlNEUCAwMDBmZDViMCAwMDAx
NCAodjAwIERFTEwgICkKRGVjICAxIDE1OjU1OjE3IEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgICAw
LjAwMDAwMF0gQUNQSTogUlNEVCAwMDBmZDVjNCAwMDAzOCAodjAxIERFTEwgICBQRSBCS0MgICAw
MDAwMDAwMSBNU0ZUIDAxMDAwMDBBKQpEZWMgIDEgMTU6NTU6MTcgR3JpZG9zX05vZGUga2VybmVs
OiBbICAgIDAuMDAwMDAwXSBBQ1BJOiBGQUNQIDAwMGZkNjIwIDAwMDc0ICh2MDEgREVMTCAgIFBF
IEJLQyAgIDAwMDAwMDAxIE1TRlQgMDEwMDAwMEEpCkRlYyAgMSAxNTo1NToxNyBHcmlkb3NfTm9k
ZSBrZXJuZWw6IFsgICAgMC4wMDAwMDBdIEFDUEk6IERTRFQgYmZmYzAwMDAgMDNDQ0QgKHYwMSBE
RUxMICAgUEUgQktDICAgMDAwMDAwMDEgTVNGVCAwMTAwMDAwRSkKRGVjICAxIDE1OjU1OjE3IEdy
aWRvc19Ob2RlIGtlcm5lbDogWyAgICAwLjAwMDAwMF0gQUNQSTogRkFDUyBiZmZjZmMwMCAwMDA0
MApEZWMgIDEgMTU6NTU6MTcgR3JpZG9zX05vZGUga2VybmVsOiBbICAgIDAuMDAwMDAwXSBBQ1BJ
OiBBUElDIDAwMGZkNjk0IDAwMEQ0ICh2MDEgREVMTCAgIFBFIEJLQyAgIDAwMDAwMDAxIE1TRlQg
MDEwMDAwMEEpCkRlYyAgMSAxNTo1NToxNyBHcmlkb3NfTm9kZSBrZXJuZWw6IFsgICAgMC4wMDAw
MDBdIEFDUEk6IFNQQ1IgMDAwZmQ3NzQgMDAwNTAgKHYwMSBERUxMICAgUEUgQktDICAgMDAwMDAw
MDEgTVNGVCAwMTAwMDAwQSkKRGVjICAxIDE1OjU1OjE3IEdyaWRvc19Ob2RlIGtlcm5lbDogWyAg
ICAwLjAwMDAwMF0gQUNQSTogSFBFVCAwMDBmZDdjNCAwMDAzOCAodjAxIERFTEwgICBQRSBCS0Mg
ICAwMDAwMDAwMSBNU0ZUIDAxMDAwMDBBKQpEZWMgIDEgMTU6NTU6MTcgR3JpZG9zX05vZGUga2Vy
bmVsOiBbICAgIDAuMDAwMDAwXSBBQ1BJOiBNQ0ZHIDAwMGZkN2ZjIDAwMDNDICh2MDEgREVMTCAg
IFBFIEJLQyAgIDAwMDAwMDAxIE1TRlQgMDEwMDAwMEEpCkRlYyAgMSAxNTo1NToxNyBHcmlkb3Nf
Tm9kZSBrZXJuZWw6IFsgICAgMC4wMDAwMDBdIDY3OTVNQiBISUdITUVNIGF2YWlsYWJsZS4KRGVj
ICAxIDE1OjU1OjE3IEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgICAwLjAwMDAwMF0gODgzTUIgTE9X
TUVNIGF2YWlsYWJsZS4KRGVjICAxIDE1OjU1OjE3IEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgICAw
LjAwMDAwMF0gICBtYXBwZWQgbG93IHJhbTogMCAtIDM3M2ZlMDAwCkRlYyAgMSAxNTo1NToxNyBH
cmlkb3NfTm9kZSBrZXJuZWw6IFsgICAgMC4wMDAwMDBdICAgbG93IHJhbTogMCAtIDM3M2ZlMDAw
CkRlYyAgMSAxNTo1NToxNyBHcmlkb3NfTm9kZSBrZXJuZWw6IFsgICAgMC4wMDAwMDBdIFpvbmUg
UEZOIHJhbmdlczoKRGVjICAxIDE1OjU1OjE3IEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgICAwLjAw
MDAwMF0gICBETUEgICAgICAweDAwMDAwMDEwIC0+IDB4MDAwMDEwMDAKRGVjICAxIDE1OjU1OjE3
IEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgICAwLjAwMDAwMF0gICBOb3JtYWwgICAweDAwMDAxMDAw
IC0+IDB4MDAwMzczZmUKRGVjICAxIDE1OjU1OjE3IEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgICAw
LjAwMDAwMF0gICBIaWdoTWVtICAweDAwMDM3M2ZlIC0+IDB4MDAxZGZmYzAKRGVjICAxIDE1OjU1
OjE3IEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgICAwLjAwMDAwMF0gTW92YWJsZSB6b25lIHN0YXJ0
IFBGTiBmb3IgZWFjaCBub2RlCkRlYyAgMSAxNTo1NToxNyBHcmlkb3NfTm9kZSBrZXJuZWw6IFsg
ICAgMC4wMDAwMDBdIGVhcmx5X25vZGVfbWFwWzNdIGFjdGl2ZSBQRk4gcmFuZ2VzCkRlYyAgMSAx
NTo1NToxNyBHcmlkb3NfTm9kZSBrZXJuZWw6IFsgICAgMC4wMDAwMDBdICAgICAwOiAweDAwMDAw
MDEwIC0+IDB4MDAwMDAwYTAKRGVjICAxIDE1OjU1OjE3IEdyaWRvc19Ob2RlIGtlcm5lbDogWyAg
ICAwLjAwMDAwMF0gICAgIDA6IDB4MDAwMDAxMDAgLT4gMHgwMDAyMDAwMApEZWMgIDEgMTU6NTU6
MTcgR3JpZG9zX05vZGUga2VybmVsOiBbICAgIDAuMDAwMDAwXSAgICAgMDogMHgwMDEwMDAwMCAt
PiAweDAwMWRmZmMwCkRlYyAgMSAxNTo1NToxOCBHcmlkb3NfTm9kZSBrZXJuZWw6IFsgICAgMC4w
MDAwMDBdIFVzaW5nIEFQSUMgZHJpdmVyIGRlZmF1bHQKRGVjICAxIDE1OjU1OjE4IEdyaWRvc19O
b2RlIGtlcm5lbDogWyAgICAwLjAwMDAwMF0gQUNQSTogUE0tVGltZXIgSU8gUG9ydDogMHg4MDgK
RGVjICAxIDE1OjU1OjE4IEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgICAwLjAwMDAwMF0gQUNQSTog
TEFQSUMgKGFjcGlfaWRbMHgwMV0gbGFwaWNfaWRbMHgwMF0gZW5hYmxlZCkKRGVjICAxIDE1OjU1
OjE4IEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgICAwLjAwMDAwMF0gQklPUyBidWc6IEFQSUMgdmVy
c2lvbiBpcyAwIGZvciBDUFUgMC8weDAsIGZpeGluZyB1cCB0byAweDEwCkRlYyAgMSAxNTo1NTox
OCBHcmlkb3NfTm9kZSBrZXJuZWw6IFsgICAgMC4wMDAwMDBdIEFDUEk6IExBUElDIChhY3BpX2lk
WzB4MDJdIGxhcGljX2lkWzB4MDZdIGVuYWJsZWQpCkRlYyAgMSAxNTo1NToxOCBHcmlkb3NfTm9k
ZSBrZXJuZWw6IFsgICAgMC4wMDAwMDBdIEFDUEk6IExBUElDIChhY3BpX2lkWzB4MDNdIGxhcGlj
X2lkWzB4MDFdIGVuYWJsZWQpCkRlYyAgMSAxNTo1NToxOCBHcmlkb3NfTm9kZSBrZXJuZWw6IFsg
ICAgMC4wMDAwMDBdIEFDUEk6IExBUElDIChhY3BpX2lkWzB4MDRdIGxhcGljX2lkWzB4MDddIGVu
YWJsZWQpCkRlYyAgMSAxNTo1NToxOCBHcmlkb3NfTm9kZSBrZXJuZWw6IFsgICAgMC4wMDAwMDBd
IEFDUEk6IExBUElDIChhY3BpX2lkWzB4MDVdIGxhcGljX2lkWzB4MDJdIGRpc2FibGVkKQpEZWMg
IDEgMTU6NTU6MTggR3JpZG9zX05vZGUga2VybmVsOiBbICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJ
QyAoYWNwaV9pZFsweDA2XSBsYXBpY19pZFsweDA0XSBkaXNhYmxlZCkKRGVjICAxIDE1OjU1OjE4
IEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgICAwLjAwMDAwMF0gQUNQSTogTEFQSUMgKGFjcGlfaWRb
MHgwN10gbGFwaWNfaWRbMHgwM10gZGlzYWJsZWQpCkRlYyAgMSAxNTo1NToxOCBHcmlkb3NfTm9k
ZSBrZXJuZWw6IFsgICAgMC4wMDAwMDBdIEFDUEk6IExBUElDIChhY3BpX2lkWzB4MDhdIGxhcGlj
X2lkWzB4MDVdIGRpc2FibGVkKQpEZWMgIDEgMTU6NTU6MTggR3JpZG9zX05vZGUga2VybmVsOiBb
ICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJQ19OTUkgKGFjcGlfaWRbMHgwMV0gaGlnaCBlZGdlIGxp
bnRbMHgxXSkKRGVjICAxIDE1OjU1OjE4IEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgICAwLjAwMDAw
MF0gQUNQSTogTEFQSUNfTk1JIChhY3BpX2lkWzB4MDJdIGhpZ2ggZWRnZSBsaW50WzB4MV0pCkRl
YyAgMSAxNTo1NToxOCBHcmlkb3NfTm9kZSBrZXJuZWw6IFsgICAgMC4wMDAwMDBdIEFDUEk6IExB
UElDX05NSSAoYWNwaV9pZFsweDAzXSBoaWdoIGVkZ2UgbGludFsweDFdKQpEZWMgIDEgMTU6NTU6
MTggR3JpZG9zX05vZGUga2VybmVsOiBbICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJQ19OTUkgKGFj
cGlfaWRbMHgwNF0gaGlnaCBlZGdlIGxpbnRbMHgxXSkKRGVjICAxIDE1OjU1OjE4IEdyaWRvc19O
b2RlIGtlcm5lbDogWyAgICAwLjAwMDAwMF0gQUNQSTogTEFQSUNfTk1JIChhY3BpX2lkWzB4MDVd
IGhpZ2ggZWRnZSBsaW50WzB4MV0pCkRlYyAgMSAxNTo1NToxOCBHcmlkb3NfTm9kZSBrZXJuZWw6
IFsgICAgMC4wMDAwMDBdIEFDUEk6IExBUElDX05NSSAoYWNwaV9pZFsweDA2XSBoaWdoIGVkZ2Ug
bGludFsweDFdKQpEZWMgIDEgMTU6NTU6MTggR3JpZG9zX05vZGUga2VybmVsOiBbICAgIDAuMDAw
MDAwXSBBQ1BJOiBMQVBJQ19OTUkgKGFjcGlfaWRbMHgwN10gaGlnaCBlZGdlIGxpbnRbMHgxXSkK
RGVjICAxIDE1OjU1OjE4IEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgICAwLjAwMDAwMF0gQUNQSTog
TEFQSUNfTk1JIChhY3BpX2lkWzB4MDhdIGhpZ2ggZWRnZSBsaW50WzB4MV0pCkRlYyAgMSAxNTo1
NToxOCBHcmlkb3NfTm9kZSBrZXJuZWw6IFsgICAgMC4wMDAwMDBdIEFDUEk6IElPQVBJQyAoaWRb
MHgwOF0gYWRkcmVzc1sweGZlYzAwMDAwXSBnc2lfYmFzZVswXSkKRGVjICAxIDE1OjU1OjE4IEdy
aWRvc19Ob2RlIGtlcm5lbDogWyAgICAwLjAwMDAwMF0gSU9BUElDWzBdOiBhcGljX2lkIDgsIHZl
cnNpb24gMjU1LCBhZGRyZXNzIDB4ZmVjMDAwMDAsIEdTSSAwLTI1NQpEZWMgIDEgMTU6NTU6MTgg
R3JpZG9zX05vZGUga2VybmVsOiBbICAgIDAuMDAwMDAwXSBBQ1BJOiBJT0FQSUMgKGlkWzB4MDld
IGFkZHJlc3NbMHhmZWM4MDAwMF0gZ3NpX2Jhc2VbMzJdKQpEZWMgIDEgMTU6NTU6MTggR3JpZG9z
X05vZGUga2VybmVsOiBbICAgIDAuMDAwMDAwXSBJT0FQSUNbMV06IGFwaWNfaWQgOSwgdmVyc2lv
biAyNTUsIGFkZHJlc3MgMHhmZWM4MDAwMCwgR1NJIDMyLTI4NwpEZWMgIDEgMTU6NTU6MTggR3Jp
ZG9zX05vZGUgYWlzZXhlYzogW01BSU4gXSBBSVMgRXhlY3V0aXZlIFNlcnZpY2UgUkVMRUFTRSAn
c3VicmV2IDExNTIgdmVyc2lvbiAwLjgwJyAKRGVjICAxIDE1OjU1OjE4IEdyaWRvc19Ob2RlIGtl
cm5lbDogWyAgICAwLjAwMDAwMF0gQUNQSTogSU9BUElDIChpZFsweDBhXSBhZGRyZXNzWzB4ZmVj
ODMwMDBdIGdzaV9iYXNlWzY0XSkKRGVjICAxIDE1OjU1OjE4IEdyaWRvc19Ob2RlIGFpc2V4ZWM6
IFtNQUlOIF0gQ29weXJpZ2h0IChDKSAyMDAyLTIwMDYgTW9udGFWaXN0YSBTb2Z0d2FyZSwgSW5j
IGFuZCBjb250cmlidXRvcnMuIApEZWMgIDEgMTU6NTU6MTggR3JpZG9zX05vZGUga2VybmVsOiBb
ICAgIDAuMDAwMDAwXSBJT0FQSUNbMl06IGFwaWNfaWQgMTAsIHZlcnNpb24gMjU1LCBhZGRyZXNz
IDB4ZmVjODMwMDAsIEdTSSA2NC0zMTkKRGVjICAxIDE1OjU1OjE4IEdyaWRvc19Ob2RlIGFpc2V4
ZWM6IFtNQUlOIF0gQ29weXJpZ2h0IChDKSAyMDA2IFJlZCBIYXQsIEluYy4gCkRlYyAgMSAxNTo1
NToxOCBHcmlkb3NfTm9kZSBrZXJuZWw6IFsgICAgMC4wMDAwMDBdIEFDUEk6IElOVF9TUkNfT1ZS
IChidXMgMCBidXNfaXJxIDAgZ2xvYmFsX2lycSAyIGRmbCBkZmwpCkRlYyAgMSAxNTo1NToxOCBH
cmlkb3NfTm9kZSBhaXNleGVjOiBbTUFJTiBdIEFJUyBFeGVjdXRpdmUgU2VydmljZTogc3RhcnRl
ZCBhbmQgcmVhZHkgdG8gcHJvdmlkZSBzZXJ2aWNlLiAKRGVjICAxIDE1OjU1OjE4IEdyaWRvc19O
b2RlIGtlcm5lbDogWyAgICAwLjAwMDAwMF0gQUNQSTogSU5UX1NSQ19PVlIgKGJ1cyAwIGJ1c19p
cnEgOSBnbG9iYWxfaXJxIDkgaGlnaCBsZXZlbCkKRGVjICAxIDE1OjU1OjE4IEdyaWRvc19Ob2Rl
IGFpc2V4ZWM6IFtNQUlOIF0gcGFyc2UgZXJyb3IgaW4gY29uZmlnOiBObyBtdWx0aWNhc3QgcG9y
dCBzcGVjaWZpZWQgCkRlYyAgMSAxNTo1NToxOCBHcmlkb3NfTm9kZSBhaXNleGVjOiBbTUFJTiBd
IEFJUyBFeGVjdXRpdmUgZXhpdGluZyAocmVhc29uOiBjb3VsZCBub3QgcmVhZCB0aGUgbWFpbiBj
b25maWd1cmF0aW9uIGZpbGUpLiAKRGVjICAxIDE1OjU1OjE4IEdyaWRvc19Ob2RlIGtlcm5lbDog
WyAgICAwLjAwMDAwMF0gVXNpbmcgQUNQSSAoTUFEVCkgZm9yIFNNUCBjb25maWd1cmF0aW9uIGlu
Zm9ybWF0aW9uCkRlYyAgMSAxNTo1NToxOCBHcmlkb3NfTm9kZSBrZXJuZWw6IFsgICAgMC4wMDAw
MDBdIFNNUDogQWxsb3dpbmcgOCBDUFVzLCA0IGhvdHBsdWcgQ1BVcwpEZWMgIDEgMTU6NTU6MTgg
R3JpZG9zX05vZGUga2VybmVsOiBbICAgIDAuMDAwMDAwXSBBbGxvY2F0aW5nIFBDSSByZXNvdXJj
ZXMgc3RhcnRpbmcgYXQgYmZmZmYwMDAgKGdhcDogYmZmZmYwMDA6MjAwMDEwMDApCkRlYyAgMSAx
NTo1NToxOCBHcmlkb3NfTm9kZSBrZXJuZWw6IFsgICAgMC4wMDAwMDBdIEJvb3RpbmcgcGFyYXZp
cnR1YWxpemVkIGtlcm5lbCBvbiBYZW4KRGVjICAxIDE1OjU1OjE4IEdyaWRvc19Ob2RlIGtlcm5l
bDogWyAgICAwLjAwMDAwMF0gWGVuIHZlcnNpb246IDQuMS4xIChwcmVzZXJ2ZS1BRCkKRGVjICAx
IDE1OjU1OjE4IEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgICAwLjAwMDAwMF0gc2V0dXBfcGVyY3B1
OiBOUl9DUFVTOjggbnJfY3B1bWFza19iaXRzOjggbnJfY3B1X2lkczo4IG5yX25vZGVfaWRzOjEK
RGVjICAxIDE1OjU1OjE4IEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgICAwLjAwMDAwMF0gUEVSQ1BV
OiBFbWJlZGRlZCAxMiBwYWdlcy9jcHUgQGRjMzhkMDAwIHMyNjYyNCByMCBkMjI1MjggdTQ5MTUy
CkRlYyAgMSAxNTo1NToxOCBHcmlkb3NfTm9kZSBrZXJuZWw6IFsgICAgMC4wMDAwMDBdIEJ1aWx0
IDEgem9uZWxpc3RzIGluIFpvbmUgb3JkZXIsIG1vYmlsaXR5IGdyb3VwaW5nIG9uLiAgVG90YWwg
cGFnZXM6IDEwMzMwNDAKRGVjICAxIDE1OjU1OjE4IEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgICAw
LjAwMDAwMF0gS2VybmVsIGNvbW1hbmQgbGluZTogbm91c2Igcm9vdD1MQUJFTD0vbW50L2FwbGJv
b3QxIHNlbGludXg9MCAgbWF4X2xvb3A9MjU2IGlvbW11PW9mZgpEZWMgIDEgMTU6NTU6MTggR3Jp
ZG9zX05vZGUga2VybmVsOiBbICAgIDAuMDAwMDAwXSBQSUQgaGFzaCB0YWJsZSBlbnRyaWVzOiAy
MDQ4IChvcmRlcjogMSwgODE5MiBieXRlcykKRGVjICAxIDE1OjU1OjE4IEdyaWRvc19Ob2RlIGtl
cm5lbDogWyAgICAwLjAwMDAwMF0gRGVudHJ5IGNhY2hlIGhhc2ggdGFibGUgZW50cmllczogNjU1
MzYgKG9yZGVyOiA2LCAyNjIxNDQgYnl0ZXMpCkRlYyAgMSAxNTo1NToxOCBHcmlkb3NfTm9kZSBr
ZXJuZWw6IFsgICAgMC4wMDAwMDBdIElub2RlLWNhY2hlIGhhc2ggdGFibGUgZW50cmllczogMzI3
NjggKG9yZGVyOiA1LCAxMzEwNzIgYnl0ZXMpCkRlYyAgMSAxNTo1NToxOCBHcmlkb3NfTm9kZSBr
ZXJuZWw6IFsgICAgMC4wMDAwMDBdIEluaXRpYWxpemluZyBDUFUjMApEZWMgIDEgMTU6NTU6MTgg
R3JpZG9zX05vZGUga2VybmVsOiBbICAgIDAuMDAwMDAwXSBQbGFjaW5nIDY0TUIgc29mdHdhcmUg
SU8gVExCIGJldHdlZW4gZDgzMmNmMDAgLSBkYzMyY2YwMApEZWMgIDEgMTU6NTU6MTggR3JpZG9z
X05vZGUga2VybmVsOiBbICAgIDAuMDAwMDAwXSBzb2Z0d2FyZSBJTyBUTEIgYXQgcGh5cyAweDE4
MzJjZjAwIC0gMHgxYzMyY2YwMApEZWMgIDEgMTU6NTU6MTggR3JpZG9zX05vZGUga2VybmVsOiBb
ICAgIDAuMDAwMDAwXSBJbml0aWFsaXppbmcgSGlnaE1lbSBmb3Igbm9kZSAwICgwMDAzNzNmZTow
MDFkZmZjMCkKRGVjICAxIDE1OjU1OjE4IEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgICAwLjAwMDAw
MF0gTWVtb3J5OiAzODUzOTZrLzc4NjQwNjRrIGF2YWlsYWJsZSAoMjM4M2sga2VybmVsIGNvZGUs
IDEzODQ0NGsgcmVzZXJ2ZWQsIDk2MmsgZGF0YSwgMzg0ayBpbml0LCAwayBoaWdobWVtKQpEZWMg
IDEgMTU6NTU6MTggR3JpZG9zX05vZGUga2VybmVsOiBbICAgIDAuMDAwMDAwXSB2aXJ0dWFsIGtl
cm5lbCBtZW1vcnkgbGF5b3V0OgpEZWMgIDEgMTU6NTU6MTggR3JpZG9zX05vZGUga2VybmVsOiBb
ICAgIDAuMDAwMDAwXSAgICAgZml4bWFwICA6IDB4ZmY3MTYwMDAgLSAweGZmN2ZmMDAwICAgKCA5
MzIga0IpCkRlYyAgMSAxNTo1NToxOCBHcmlkb3NfTm9kZSBrZXJuZWw6IFsgICAgMC4wMDAwMDBd
ICAgICBwa21hcCAgIDogMHhmZjQwMDAwMCAtIDB4ZmY2MDAwMDAgICAoMjA0OCBrQikKRGVjICAx
IDE1OjU1OjE4IEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgICAwLjAwMDAwMF0gICAgIHZtYWxsb2Mg
OiAweGY3YmZlMDAwIC0gMHhmZjNmZTAwMCAgICggMTIwIE1CKQpEZWMgIDEgMTU6NTU6MTkgR3Jp
ZG9zX05vZGUga2VybmVsOiBbICAgIDAuMDAwMDAwXSAgICAgbG93bWVtICA6IDB4YzAwMDAwMDAg
LSAweGY3M2ZlMDAwICAgKCA4ODMgTUIpCkRlYyAgMSAxNTo1NToxOSBHcmlkb3NfTm9kZSBrZXJu
ZWw6IFsgICAgMC4wMDAwMDBdICAgICAgIC5pbml0IDogMHhjMTM0NTAwMCAtIDB4YzEzYTUwMDAg
ICAoIDM4NCBrQikKRGVjICAxIDE1OjU1OjE5IEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgICAwLjAw
MDAwMF0gICAgICAgLmRhdGEgOiAweGMxMjUzZGE1IC0gMHhjMTM0NDkwMCAgICggOTYyIGtCKQpE
ZWMgIDEgMTU6NTU6MTkgR3JpZG9zX05vZGUga2VybmVsOiBbICAgIDAuMDAwMDAwXSAgICAgICAu
dGV4dCA6IDB4YzEwMDAwMDAgLSAweGMxMjUzZGE1ICAgKDIzODMga0IpCkRlYyAgMSAxNTo1NTox
OSBHcmlkb3NfTm9kZSBrZXJuZWw6IFsgICAgMC4wMDAwMDBdIEhpZXJhcmNoaWNhbCBSQ1UgaW1w
bGVtZW50YXRpb24uCkRlYyAgMSAxNTo1NToxOSBHcmlkb3NfTm9kZSBrZXJuZWw6IFsgICAgMC4w
MDAwMDBdIE5SX0lSUVM6NTEyCkRlYyAgMSAxNTo1NToxOSBHcmlkb3NfTm9kZSBrZXJuZWw6IFsg
ICAgMC4wMDAwMDBdIHhlbjogc2NpIG92ZXJyaWRlOiBnbG9iYWxfaXJxPTkgdHJpZ2dlcj0wIHBv
bGFyaXR5PTAKRGVjICAxIDE1OjU1OjE5IEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgICAwLjAwMDAw
MF0geGVuOiBhY3BpIHNjaSA5CkRlYyAgMSAxNTo1NToxOSBHcmlkb3NfTm9kZSBrZXJuZWw6IFsg
ICAgMC4wMDAwMDBdIHhlbl9tYXBfcGlycV9nc2k6IHJldHVybmluZyBpcnEgOSBmb3IgZ3NpIDkK
RGVjICAxIDE1OjU1OjE5IEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgICAwLjAwMDAwMF0gQ29uc29s
ZTogY29sb3VyIFZHQSsgODB4MjUKRGVjICAxIDE1OjU1OjE5IEdyaWRvc19Ob2RlIGtlcm5lbDog
WyAgICAwLjAwMDAwMF0gY29uc29sZSBbdHR5MF0gZW5hYmxlZApEZWMgIDEgMTU6NTU6MTkgR3Jp
ZG9zX05vZGUga2VybmVsOiBbICAgIDAuMDAwMDAwXSBpbnN0YWxsaW5nIFhlbiB0aW1lciBmb3Ig
Q1BVIDAKRGVjICAxIDE1OjU1OjE5IEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgICAwLjAwMDAwMF0g
RGV0ZWN0ZWQgMjk5Mi44MzYgTUh6IHByb2Nlc3Nvci4KRGVjICAxIDE1OjU1OjE5IEdyaWRvc19O
b2RlIGtlcm5lbDogWyAgICAwLjAxMDAwMF0gQ2FsaWJyYXRpbmcgZGVsYXkgbG9vcCAoc2tpcHBl
ZCksIHZhbHVlIGNhbGN1bGF0ZWQgdXNpbmcgdGltZXIgZnJlcXVlbmN5Li4gNTk4NS42NyBCb2dv
TUlQUyAobHBqPTI5OTI4MzYwKQpEZWMgIDEgMTU6NTU6MTkgR3JpZG9zX05vZGUga2VybmVsOiBb
ICAgIDAuMDEwMDAwXSBwaWRfbWF4OiBkZWZhdWx0OiAzMjc2OCBtaW5pbXVtOiAzMDEKRGVjICAx
IDE1OjU1OjE5IEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgICAwLjAxMDAwMF0gLS0tLS0tLS0tLS0t
WyBjdXQgaGVyZSBdLS0tLS0tLS0tLS0tCkRlYyAgMSAxNTo1NToxOSBHcmlkb3NfTm9kZSBrZXJu
ZWw6IFsgICAgMC4wMTAwMDBdIFdBUk5JTkc6IGF0IGFyY2gveDg2L3hlbi9tbXUuYzo0OTIgeGVu
X21ha2VfcHRlX2RlYnVnKzB4MTQ1LzB4MTg4KCkKRGVjICAxIDE1OjU1OjE5IEdyaWRvc19Ob2Rl
IGtlcm5lbDogWyAgICAwLjAxMDAwMF0gSGFyZHdhcmUgbmFtZTogUG93ZXJFZGdlIDE4NTAKRGVj
ICAxIDE1OjU1OjE5IEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgICAwLjAxMDAwMF0gMHgxN2MyYzAw
MCBpcyBtaXNzaW5nIFZNX0lPIChhbmQgd2Fzbid0IGZpeGVkKSEKRGVjICAxIDE1OjU1OjE5IEdy
aWRvc19Ob2RlIGtlcm5lbDogWyAgICAwLjAxMDAwMF0gTW9kdWxlcyBsaW5rZWQgaW46CkRlYyAg
MSAxNTo1NToxOSBHcmlkb3NfTm9kZSBrZXJuZWw6IFsgICAgMC4wMTAwMDBdIFBpZDogMCwgY29t
bTogc3dhcHBlciBOb3QgdGFpbnRlZCAzLjAuNC0zMy54ZW4wICMxCkRlYyAgMSAxNTo1NToxOSBH
cmlkb3NfTm9kZSBrZXJuZWw6IFsgICAgMC4wMTAwMDBdIENhbGwgVHJhY2U6CkRlYyAgMSAxNTo1
NToxOSBHcmlkb3NfTm9kZSBrZXJuZWw6IFsgICAgMC4wMTAwMDBdICBbPGMxMDA1NGU4Pl0gPyB4
ZW5fbWFrZV9wdGVfZGVidWcrMHgxNDUvMHgxODgKRGVjICAxIDE1OjU1OjE5IEdyaWRvc19Ob2Rl
IGtlcm5lbDogWyAgICAwLjAxMDAwMF0gIFs8YzEwMzQwMzA+XSB3YXJuX3Nsb3dwYXRoX2NvbW1v
bisweDc2LzB4OGIKRGVjICAxIDE1OjU1OjE5IEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgICAwLjAx
MDAwMF0gIFs8YzEwMDU0ZTg+XSA/IHhlbl9tYWtlX3B0ZV9kZWJ1ZysweDE0NS8weDE4OApEZWMg
IDEgMTU6NTU6MTkgR3JpZG9zX05vZGUga2VybmVsOiBbICAgIDAuMDEwMDAwXSAgWzxjMTAzNDBj
MT5dIHdhcm5fc2xvd3BhdGhfZm10KzB4MmUvMHgzMApEZWMgIDEgMTU6NTU6MTkgR3JpZG9zX05v
ZGUga2VybmVsOiBbICAgIDAuMDEwMDAwXSAgWzxjMTAwNTRlOD5dIHhlbl9tYWtlX3B0ZV9kZWJ1
ZysweDE0NS8weDE4OApEZWMgIDEgMTU6NTU6MTkgR3JpZG9zX05vZGUga2VybmVsOiBbICAgIDAu
MDEwMDAwXSAgWzxjMTAwMzY2ZT5dIF9fcmF3X2NhbGxlZV9zYXZlX3hlbl9tYWtlX3B0ZV9kZWJ1
ZysweDYvMHg4CkRlYyAgMSAxNTo1NToxOSBHcmlkb3NfTm9kZSBrZXJuZWw6IFsgICAgMC4wMTAw
MDBdICBbPGMxMDIzMmQxPl0gPyBfX2NoYW5nZV9wYWdlX2F0dHJfc2V0X2NscisweDlmNC8weGMy
ZQpEZWMgIDEgMTU6NTU6MTkgR3JpZG9zX05vZGUga2VybmVsOiBbICAgIDAuMDEwMDAwXSAgWzxj
MTAwNTk3Zj5dID8geGVuX2ZvcmNlX2V2dGNobl9jYWxsYmFjaysweGYvMHgxNApEZWMgIDEgMTU6
NTU6MTkgR3JpZG9zX05vZGUga2VybmVsOiBbICAgIDAuMDEwMDAwXSAgWzxjMTAwNTk3Zj5dID8g
eGVuX2ZvcmNlX2V2dGNobl9jYWxsYmFjaysweGYvMHgxNApEZWMgIDEgMTU6NTU6MTkgR3JpZG9z
X05vZGUga2VybmVsOiBbICAgIDAuMDEwMDAwXSAgWzxjMTAwNjBhMD5dID8gY2hlY2tfZXZlbnRz
KzB4OC8weGMKRGVjICAxIDE1OjU1OjE5IEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgICAwLjAxMDAw
MF0gIFs8YzEwMDYwOTc+XSA/IHhlbl9yZXN0b3JlX2ZsX2RpcmVjdF9yZWxvYysweDQvMHg0CkRl
YyAgMSAxNTo1NToxOSBHcmlkb3NfTm9kZSBrZXJuZWw6IFsgICAgMC4wMTAwMDBdICBbPGMxMDA0
MzRjPl0gPyB4ZW5fZmx1c2hfdGxiKzB4NWYvMHg2YwpEZWMgIDEgMTU6NTU6MTkgR3JpZG9zX05v
ZGUga2VybmVsOiBbICAgIDAuMDEwMDAwXSAgWzxjMTAyMzViNz5dID8ga2VybmVsX21hcF9wYWdl
cysweGFjLzB4MTA0CkRlYyAgMSAxNTo1NToxOSBHcmlkb3NfTm9kZSBrZXJuZWw6IFsgICAgMC4w
MTAwMDBdICBbPGMxMDcxNDhkPl0gPyBnZXRfcGFnZV9mcm9tX2ZyZWVsaXN0KzB4MjU1LzB4Mzlj
CkRlYyAgMSAxNTo1NToxOSBHcmlkb3NfTm9kZSBrZXJuZWw6IFsgICAgMC4wMTAwMDBdICBbPGMx
MDkyODJhPl0gPyBjaGVja19wb2lzb25fb2JqKzB4MjIvMHgxYWQKRGVjICAxIDE1OjU1OjE5IEdy
aWRvc19Ob2RlIGtlcm5lbDogWyAgICAwLjAxMDAwMF0gIFs8YzEwNzE3OWU+XSA/IF9fYWxsb2Nf
cGFnZXNfbm9kZW1hc2srMHhkOS8weDU2MQpEZWMgIDEgMTU6NTU6MTkgR3JpZG9zX05vZGUga2Vy
bmVsOiBbICAgIDAuMDEwMDAwXSAgWzxjMTA5MmI5ZD5dID8gcG9pc29uX29iaisweDMyLzB4M2YK
RGVjICAxIDE1OjU1OjE5IEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgICAwLjAxMDAwMF0gIFs8YzEw
OTI1NDM+XSA/IGRiZ19yZWR6b25lMSsweDExLzB4MWQKRGVjICAxIDE1OjU1OjE5IEdyaWRvc19O
b2RlIGtlcm5lbDogWyAgICAwLjAxMDAwMF0gIFs8YzEwMjM1Zjc+XSBrZXJuZWxfbWFwX3BhZ2Vz
KzB4ZWMvMHgxMDQKRGVjICAxIDE1OjU1OjE5IEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgICAwLjAx
MDAwMF0gIFs8YzEwOTNmYTM+XSBjYWNoZV9hbGxvY19yZWZpbGwrMHg2Y2QvMHg2ZDIKRGVjICAx
IDE1OjU1OjE5IEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgICAwLjAxMDAwMF0gIFs8YzEwOTQyYzg+
XSBrbWVtX2NhY2hlX2FsbG9jKzB4YzMvMHhjNwpEZWMgIDEgMTU6NTU6MTkgR3JpZG9zX05vZGUg
a2VybmVsOiBbICAgIDAuMDEwMDAwXSAgWzxjMTM1YjRiNT5dID8gcGlkbWFwX2luaXQrMHg3My8w
eGFkCkRlYyAgMSAxNTo1NToxOSBHcmlkb3NfTm9kZSBrZXJuZWw6IFsgICAgMC4wMTAwMDBdICBb
PGMxMzViNGI1Pl0gcGlkbWFwX2luaXQrMHg3My8weGFkCkRlYyAgMSAxNTo1NToxOSBHcmlkb3Nf
Tm9kZSBrZXJuZWw6IFsgICAgMC4wMTAwMDBdICBbPGMxMzQ1ODFlPl0gc3RhcnRfa2VybmVsKzB4
MjJmLzB4MzExCkRlYyAgMSAxNTo1NToxOSBHcmlkb3NfTm9kZSBrZXJuZWw6IFsgICAgMC4wMTAw
MDBdICBbPGMxMzQ1MjE3Pl0gPyBwYXJzZV9lYXJseV9vcHRpb25zKzB4MjUvMHgyNQpEZWMgIDEg
MTU6NTU6MTkgR3JpZG9zX05vZGUga2VybmVsOiBbICAgIDAuMDEwMDAwXSAgWzxjMTM0NTA4OT5d
IGkzODZfc3RhcnRfa2VybmVsKzB4NzgvMHhiZgpEZWMgIDEgMTU6NTU6MTkgR3JpZG9zX05vZGUg
a2VybmVsOiBbICAgIDAuMDEwMDAwXSAgWzxjMTM0N2I4MD5dIHhlbl9zdGFydF9rZXJuZWwrMHgz
ZTgvMHg0ZGQKRGVjICAxIDE1OjU1OjE5IEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgICAwLjAxMDAw
MF0gLS0tWyBlbmQgdHJhY2UgNGVhYTJhODZhOGUyZGEyMiBdLS0tCkRlYyAgMSAxNTo1NToyMCBH
cmlkb3NfTm9kZSBrZXJuZWw6IFsgICAgMC4wMTAwMDBdIE1vdW50LWNhY2hlIGhhc2ggdGFibGUg
ZW50cmllczogNTEyCkRlYyAgMSAxNTo1NToyMCBHcmlkb3NfTm9kZSBrZXJuZWw6IFsgICAgMC4w
MTAwMDBdIENQVTogUGh5c2ljYWwgUHJvY2Vzc29yIElEOiAwCkRlYyAgMSAxNTo1NToyMCBHcmlk
b3NfTm9kZSBrZXJuZWw6IFsgICAgMC4wMTAwMDBdIENQVTogUHJvY2Vzc29yIENvcmUgSUQ6IDAK
RGVjICAxIDE1OjU1OjIwIEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgICAwLjAxMDAwMF0gQUNQSTog
Q29yZSByZXZpc2lvbiAyMDExMDQxMwpEZWMgIDEgMTU6NTU6MjAgR3JpZG9zX05vZGUga2VybmVs
OiBbICAgIDAuMDI0NzUzXSBQZXJmb3JtYW5jZSBFdmVudHM6IHVuc3VwcG9ydGVkIE5ldGJ1cnN0
IENQVSBtb2RlbCA0IG5vIFBNVSBkcml2ZXIsIHNvZnR3YXJlIGV2ZW50cyBvbmx5LgpEZWMgIDEg
MTU6NTU6MjAgR3JpZG9zX05vZGUga2VybmVsOiBbICAgIDAuMDI4MTMzXSBpbnN0YWxsaW5nIFhl
biB0aW1lciBmb3IgQ1BVIDEKRGVjICAxIDE1OjU1OjIwIEdyaWRvc19Ob2RlIGtlcm5lbDogWyAg
ICAwLjAxMDAwMF0gSW5pdGlhbGl6aW5nIENQVSMxCkRlYyAgMSAxNTo1NToyMCBHcmlkb3NfTm9k
ZSBrZXJuZWw6IFsgICAgMC4wMzA1MjhdIGluc3RhbGxpbmcgWGVuIHRpbWVyIGZvciBDUFUgMgpE
ZWMgIDEgMTU6NTU6MjAgR3JpZG9zX05vZGUga2VybmVsOiBbICAgIDAuMDEwMDAwXSBJbml0aWFs
aXppbmcgQ1BVIzIKRGVjICAxIDE1OjU1OjIwIEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgICAwLjAz
Mjk1OF0gaW5zdGFsbGluZyBYZW4gdGltZXIgZm9yIENQVSAzCkRlYyAgMSAxNTo1NToyMCBHcmlk
b3NfTm9kZSBrZXJuZWw6IFsgICAgMC4wMTAwMDBdIEluaXRpYWxpemluZyBDUFUjMwpEZWMgIDEg
MTU6NTU6MjAgR3JpZG9zX05vZGUga2VybmVsOiBbICAgIDAuMDMzMjgxXSBCcm91Z2h0IHVwIDQg
Q1BVcwpEZWMgIDEgMTU6NTU6MjAgR3JpZG9zX05vZGUga2VybmVsOiBbICAgIDAuMDM5NTU5XSBH
cmFudCB0YWJsZSBpbml0aWFsaXplZApEZWMgIDEgMTU6NTU6MjAgR3JpZG9zX05vZGUga2VybmVs
OiBbICAgIDAuMDQwMDEzXSBORVQ6IFJlZ2lzdGVyZWQgcHJvdG9jb2wgZmFtaWx5IDE2CkRlYyAg
MSAxNTo1NToyMCBHcmlkb3NfTm9kZSBrZXJuZWw6IFsgICAgMC4wNDE0NDNdIEFDUEk6IGJ1cyB0
eXBlIHBjaSByZWdpc3RlcmVkCkRlYyAgMSAxNTo1NToyMCBHcmlkb3NfTm9kZSBrZXJuZWw6IFsg
ICAgMC4wNDE5NDhdIFBDSTogTU1DT05GSUcgZm9yIGRvbWFpbiAwMDAwIFtidXMgMDAtZmZdIGF0
IFttZW0gMHhlMDAwMDAwMC0weGVmZmZmZmZmXSAoYmFzZSAweGUwMDAwMDAwKQpEZWMgIDEgMTU6
NTU6MjAgR3JpZG9zX05vZGUga2VybmVsOiBbICAgIDAuMDQyMDYwXSBQQ0k6IEludGVsIENvcnBv
cmF0aW9uIEU3NTIwIE1lbW9yeSBDb250cm9sbGVyIEh1YiB3aXRoIE1NQ09ORklHIHN1cHBvcnQK
RGVjICAxIDE1OjU1OjIwIEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgICAwLjA0MjE4NV0gUENJOiBN
TUNPTkZJRyBhdCBbbWVtIDB4ZTAwMDAwMDAtMHhlZmZmZmZmZl0gcmVzZXJ2ZWQgaW4gRTgyMApE
ZWMgIDEgMTU6NTU6MjAgR3JpZG9zX05vZGUga2VybmVsOiBbICAgIDAuMDQyMjc4XSBQQ0k6IFVz
aW5nIE1NQ09ORklHIGZvciBleHRlbmRlZCBjb25maWcgc3BhY2UKRGVjICAxIDE1OjU1OjIwIEdy
aWRvc19Ob2RlIGtlcm5lbDogWyAgICAwLjA0MjM3MF0gUENJOiBVc2luZyBjb25maWd1cmF0aW9u
IHR5cGUgMSBmb3IgYmFzZSBhY2Nlc3MKRGVjICAxIDE1OjU1OjIwIEdyaWRvc19Ob2RlIGtlcm5l
bDogWyAgICAwLjA0OTI3Nl0gYmlvOiBjcmVhdGUgc2xhYiA8YmlvLTA+IGF0IDAKRGVjICAxIDE1
OjU1OjIwIEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgICAwLjA3ODczMl0gQUNQSTogSW50ZXJwcmV0
ZXIgZW5hYmxlZApEZWMgIDEgMTU6NTU6MjAgR3JpZG9zX05vZGUga2VybmVsOiBbICAgIDAuMDc4
ODI0XSBBQ1BJOiAoc3VwcG9ydHMgUzAgUzUpCkRlYyAgMSAxNTo1NToyMCBHcmlkb3NfTm9kZSBr
ZXJuZWw6IFsgICAgMC4wNzkxMDBdIEFDUEk6IFVzaW5nIElPQVBJQyBmb3IgaW50ZXJydXB0IHJv
dXRpbmcKRGVjICAxIDE1OjU1OjIwIEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgICAwLjEwNTA3NV0g
UENJOiBJZ25vcmluZyBob3N0IGJyaWRnZSB3aW5kb3dzIGZyb20gQUNQSTsgaWYgbmVjZXNzYXJ5
LCB1c2UgInBjaT11c2VfY3JzIiBhbmQgcmVwb3J0IGEgYnVnCkRlYyAgMSAxNTo1NToyMCBHcmlk
b3NfTm9kZSBrZXJuZWw6IFsgICAgMC4xMDY4NDFdIEFDUEk6IFBDSSBSb290IEJyaWRnZSBbUENJ
MF0gKGRvbWFpbiAwMDAwIFtidXMgMDAtZmZdKQpEZWMgIDEgMTU6NTU6MjAgR3JpZG9zX05vZGUg
a2VybmVsOiBbICAgIDAuMTE0NDA1XSBwY2kgMDAwMDowMTowMC4wOiBkaXNhYmxpbmcgQVNQTSBv
biBwcmUtMS4xIFBDSWUgZGV2aWNlLiAgWW91IGNhbiBlbmFibGUgaXQgd2l0aCAncGNpZV9hc3Bt
PWZvcmNlJwpEZWMgIDEgMTU6NTU6MjAgR3JpZG9zX05vZGUga2VybmVsOiBbICAgIDAuMTE0NTQ4
XSBwY2kgMDAwMDowMDowMi4wOiBQQ0kgYnJpZGdlIHRvIFtidXMgMDEtMDNdCkRlYyAgMSAxNTo1
NToyMCBHcmlkb3NfTm9kZSBrZXJuZWw6IFsgICAgMC4xMTUzMTBdIHBjaSAwMDAwOjAxOjAwLjA6
IFBDSSBicmlkZ2UgdG8gW2J1cyAwMi0wMl0KRGVjICAxIDE1OjU1OjIwIEdyaWRvc19Ob2RlIGtl
cm5lbDogWyAgICAwLjExNTcwOF0gcGNpIDAwMDA6MDE6MDAuMjogUENJIGJyaWRnZSB0byBbYnVz
IDAzLTAzXQpEZWMgIDEgMTU6NTU6MjAgR3JpZG9zX05vZGUga2VybmVsOiBbICAgIDAuMTE2MDI3
XSBwY2kgMDAwMDowMDowNC4wOiBQQ0kgYnJpZGdlIHRvIFtidXMgMDQtMDRdCkRlYyAgMSAxNTo1
NToyMCBHcmlkb3NfTm9kZSBrZXJuZWw6IFsgICAgMC4xMTY0MzNdIHBjaSAwMDAwOjA1OjAwLjA6
IFBYSCBxdWlyayBkZXRlY3RlZDsgU0hQQyBkZXZpY2UgTVNJIGRpc2FibGVkCkRlYyAgMSAxNTo1
NToyMCBHcmlkb3NfTm9kZSBrZXJuZWw6IFsgICAgMC4xMTY4ODldIHBjaSAwMDAwOjA1OjAwLjI6
IFBYSCBxdWlyayBkZXRlY3RlZDsgU0hQQyBkZXZpY2UgTVNJIGRpc2FibGVkCkRlYyAgMSAxNTo1
NToyMCBHcmlkb3NfTm9kZSBrZXJuZWw6IFsgICAgMC4xMTcyMzddIHBjaSAwMDAwOjA1OjAwLjA6
IGRpc2FibGluZyBBU1BNIG9uIHByZS0xLjEgUENJZSBkZXZpY2UuICBZb3UgY2FuIGVuYWJsZSBp
dCB3aXRoICdwY2llX2FzcG09Zm9yY2UnCkRlYyAgMSAxNTo1NToyMCBHcmlkb3NfTm9kZSBrZXJu
ZWw6IFsgICAgMC4xMTczNzhdIHBjaSAwMDAwOjAwOjA1LjA6IFBDSSBicmlkZ2UgdG8gW2J1cyAw
NS0wN10KRGVjICAxIDE1OjU1OjIwIEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgICAwLjExODEzM10g
cGNpIDAwMDA6MDU6MDAuMDogUENJIGJyaWRnZSB0byBbYnVzIDA2LTA2XQpEZWMgIDEgMTU6NTU6
MjEgR3JpZG9zX05vZGUga2VybmVsOiBbICAgIDAuMTE4OTAxXSBwY2kgMDAwMDowNTowMC4yOiBQ
Q0kgYnJpZGdlIHRvIFtidXMgMDctMDddCkRlYyAgMSAxNTo1NToyMSBHcmlkb3NfTm9kZSBrZXJu
ZWw6IFsgICAgMC4xMTkyMjBdIHBjaSAwMDAwOjAwOjA2LjA6IFBDSSBicmlkZ2UgdG8gW2J1cyAw
OC0wOF0KRGVjICAxIDE1OjU1OjIxIEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgICAwLjEyMTEyOF0g
cGNpIDAwMDA6MDA6MWUuMDogUENJIGJyaWRnZSB0byBbYnVzIDA5LTA5XSAoc3VidHJhY3RpdmUg
ZGVjb2RlKQpEZWMgIDEgMTU6NTU6MjEgR3JpZG9zX05vZGUga2VybmVsOiBbICAgIDAuMTI3Nzc0
XSAgcGNpMDAwMDowMDogUmVxdWVzdGluZyBBQ1BJIF9PU0MgY29udHJvbCAoMHgxZCkKRGVjICAx
IDE1OjU1OjIxIEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgICAwLjEyOTY4OV0gIHBjaTAwMDA6MDA6
IEFDUEkgX09TQyByZXF1ZXN0IGZhaWxlZCAoQUVfTk9UX0ZPVU5EKSwgcmV0dXJuZWQgY29udHJv
bCBtYXNrOiAweDFkCkRlYyAgMSAxNTo1NToyMSBHcmlkb3NfTm9kZSBrZXJuZWw6IFsgICAgMC4x
Mjk3OTldIEFDUEkgX09TQyBjb250cm9sIGZvciBQQ0llIG5vdCBncmFudGVkLCBkaXNhYmxpbmcg
QVNQTQpEZWMgIDEgMTU6NTU6MjEgR3JpZG9zX05vZGUga2VybmVsOiBbICAgIDAuMTQ0ODIyXSBB
Q1BJOiBQQ0kgSW50ZXJydXB0IExpbmsgW0xOS0FdIChJUlFzIDMgNCA1IDYgNyAxMCAqMTEgMTIp
CkRlYyAgMSAxNTo1NToyMSBHcmlkb3NfTm9kZSBrZXJuZWw6IFsgICAgMC4xNDU5MTZdIEFDUEk6
IFBDSSBJbnRlcnJ1cHQgTGluayBbTE5LQl0gKElSUXMgKjMgNCA1IDYgNyAxMCAxMSAxMikKRGVj
ICAxIDE1OjU1OjIxIEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgICAwLjE0NzAwNV0gQUNQSTogUENJ
IEludGVycnVwdCBMaW5rIFtMTktDXSAoSVJRcyAzIDQgNSA2ICo3IDEwIDExIDEyKQpEZWMgIDEg
MTU6NTU6MjEgR3JpZG9zX05vZGUga2VybmVsOiBbICAgIDAuMTQ4MDk1XSBBQ1BJOiBQQ0kgSW50
ZXJydXB0IExpbmsgW0xOS0RdIChJUlFzIDMgNCA1IDYgNyAqMTAgMTEgMTIpCkRlYyAgMSAxNTo1
NToyMSBHcmlkb3NfTm9kZSBrZXJuZWw6IFsgICAgMC4xNDkxOThdIEFDUEk6IFBDSSBJbnRlcnJ1
cHQgTGluayBbTE5LRV0gKElSUXMgMyA0IDUgNiA3IDEwICoxMSAxMikKRGVjICAxIDE1OjU1OjIx
IEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgICAwLjE1MDI0Nl0gQUNQSTogUENJIEludGVycnVwdCBM
aW5rIFtMTktGXSAoSVJRcyAzIDQgNSA2IDcgKjEwIDExIDEyKQpEZWMgIDEgMTU6NTU6MjEgR3Jp
ZG9zX05vZGUga2VybmVsOiBbICAgIDAuMTUxMzMwXSBBQ1BJOiBQQ0kgSW50ZXJydXB0IExpbmsg
W0xOS0ddIChJUlFzIDMgNCA1IDYgNyAxMCAxMSAxMikgKjAsIGRpc2FibGVkLgpEZWMgIDEgMTU6
NTU6MjEgR3JpZG9zX05vZGUga2VybmVsOiBbICAgIDAuMTUyNTg2XSBBQ1BJOiBQQ0kgSW50ZXJy
dXB0IExpbmsgW0xOS0hdIChJUlFzIDMgNCAqNSA2IDcgMTAgMTEgMTIpCkRlYyAgMSAxNTo1NToy
MSBHcmlkb3NfTm9kZSBrZXJuZWw6IFsgICAgMC4xNTM2MDZdIHhlbi9iYWxsb29uOiBJbml0aWFs
aXNpbmcgYmFsbG9vbiBkcml2ZXIuCkRlYyAgMSAxNTo1NToyMSBHcmlkb3NfTm9kZSBrZXJuZWw6
IFsgICAgMC4xNTM3MDFdIGxhc3RfcGZuID0gMHgxZGZmYzAgbWF4X2FyY2hfcGZuID0gMHgxMDAw
MDAwCkRlYyAgMSAxNTo1NToyMSBHcmlkb3NfTm9kZSBrZXJuZWw6IFsgICAgMC4xNzM0NTBdIHhl
bi1iYWxsb29uOiBJbml0aWFsaXNpbmcgYmFsbG9vbiBkcml2ZXIuCkRlYyAgMSAxNTo1NToyMSBH
cmlkb3NfTm9kZSBrZXJuZWw6IFsgICAgMC4xNzQwMzVdIHZnYWFyYjogZGV2aWNlIGFkZGVkOiBQ
Q0k6MDAwMDowOTowZC4wLGRlY29kZXM9aW8rbWVtLG93bnM9aW8rbWVtLGxvY2tzPW5vbmUKRGVj
ICAxIDE1OjU1OjIxIEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgICAwLjE3NDE0OV0gdmdhYXJiOiBs
b2FkZWQKRGVjICAxIDE1OjU1OjIxIEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgICAwLjE3NDIzN10g
dmdhYXJiOiBicmlkZ2UgY29udHJvbCBwb3NzaWJsZSAwMDAwOjA5OjBkLjAKRGVjICAxIDE1OjU1
OjIxIEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgICAwLjE3NDMzMF0gdXNiY29yZTogVVNCIHN1cHBv
cnQgZGlzYWJsZWQKRGVjICAxIDE1OjU1OjIxIEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgICAwLjE3
NTEwMV0gUENJOiBVc2luZyBBQ1BJIGZvciBJUlEgcm91dGluZwpEZWMgIDEgMTU6NTU6MjEgR3Jp
ZG9zX05vZGUga2VybmVsOiBbICAgIDAuMTgwODY5XSBTd2l0Y2hpbmcgdG8gY2xvY2tzb3VyY2Ug
eGVuCkRlYyAgMSAxNTo1NToyMSBHcmlkb3NfTm9kZSBrZXJuZWw6IFsgICAgMC4xODA5NzBdIHBu
cDogUG5QIEFDUEkgaW5pdApEZWMgIDEgMTU6NTU6MjEgR3JpZG9zX05vZGUga2VybmVsOiBbICAg
IDAuMTgwOTcwXSBBQ1BJOiBidXMgdHlwZSBwbnAgcmVnaXN0ZXJlZApEZWMgIDEgMTU6NTU6MjEg
R3JpZG9zX05vZGUga2VybmVsOiBbICAgIDAuMTgzNTU0XSB4ZW5fbWFwX3BpcnFfZ3NpOiByZXR1
cm5pbmcgaXJxIDEzIGZvciBnc2kgMTMKRGVjICAxIDE1OjU1OjIxIEdyaWRvc19Ob2RlIGtlcm5l
bDogWyAgICAwLjE4NDI0MF0geGVuX21hcF9waXJxX2dzaTogcmV0dXJuaW5nIGlycSA4IGZvciBn
c2kgOApEZWMgIDEgMTU6NTU6MjEgR3JpZG9zX05vZGUga2VybmVsOiBbICAgIDAuMTg1Njc2XSB4
ZW5fbWFwX3BpcnFfZ3NpOiByZXR1cm5pbmcgaXJxIDYgZm9yIGdzaSA2CkRlYyAgMSAxNTo1NToy
MSBHcmlkb3NfTm9kZSBrZXJuZWw6IFsgICAgMC4xODcxMDZdIHhlbl9tYXBfcGlycV9nc2k6IHJl
dHVybmluZyBpcnEgMSBmb3IgZ3NpIDEKRGVjICAxIDE1OjU1OjIxIEdyaWRvc19Ob2RlIGtlcm5l
bDogWyAgICAwLjE4OTEyMV0geGVuX21hcF9waXJxX2dzaTogcmV0dXJuaW5nIGlycSAxMiBmb3Ig
Z3NpIDEyCkRlYyAgMSAxNTo1NToyMSBHcmlkb3NfTm9kZSBrZXJuZWw6IFsgICAgMC4xOTAxOTRd
IHhlbl9tYXBfcGlycV9nc2k6IHJldHVybmluZyBpcnEgNCBmb3IgZ3NpIDQKRGVjICAxIDE1OjU1
OjIxIEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgICAwLjE5Mjk3Ml0gc3lzdGVtIDAwOjA5OiBbaW8g
IDB4MDgwMC0weDA4N2ZdIGhhcyBiZWVuIHJlc2VydmVkCkRlYyAgMSAxNTo1NToyMSBHcmlkb3Nf
Tm9kZSBrZXJuZWw6IFsgICAgMC4xOTI5NzRdIHN5c3RlbSAwMDowOTogW2lvICAweDA4ODAtMHgw
OGJmXSBoYXMgYmVlbiByZXNlcnZlZApEZWMgIDEgMTU6NTU6MjEgR3JpZG9zX05vZGUga2VybmVs
OiBbICAgIDAuMTkyOTc0XSBzeXN0ZW0gMDA6MDk6IFtpbyAgMHgwOGMwLTB4MDhkZl0gaGFzIGJl
ZW4gcmVzZXJ2ZWQKRGVjICAxIDE1OjU1OjIxIEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgICAwLjE5
Mjk3NF0gc3lzdGVtIDAwOjA5OiBbaW8gIDB4MDhlMC0weDA4ZTNdIGhhcyBiZWVuIHJlc2VydmVk
CkRlYyAgMSAxNTo1NToyMSBHcmlkb3NfTm9kZSBrZXJuZWw6IFsgICAgMC4xOTI5NzRdIHN5c3Rl
bSAwMDowOTogW2lvICAweDBjMDAtMHgwYzBmXSBoYXMgYmVlbiByZXNlcnZlZApEZWMgIDEgMTU6
NTU6MjEgR3JpZG9zX05vZGUga2VybmVsOiBbICAgIDAuMTkyOTc0XSBzeXN0ZW0gMDA6MDk6IFtp
byAgMHgwYzEwLTB4MGMxZl0gaGFzIGJlZW4gcmVzZXJ2ZWQKRGVjICAxIDE1OjU1OjIxIEdyaWRv
c19Ob2RlIGtlcm5lbDogWyAgICAwLjE5Mjk3NF0gc3lzdGVtIDAwOjA5OiBbaW8gIDB4MGNhMC0w
eDBjYTddIGhhcyBiZWVuIHJlc2VydmVkCkRlYyAgMSAxNTo1NToyMSBHcmlkb3NfTm9kZSBrZXJu
ZWw6IFsgICAgMC4xOTI5NzRdIHN5c3RlbSAwMDowOTogW2lvICAweDBjYTktMHgwY2FiXSBoYXMg
YmVlbiByZXNlcnZlZApEZWMgIDEgMTU6NTU6MjEgR3JpZG9zX05vZGUga2VybmVsOiBbICAgIDAu
MTkyOTc0XSBzeXN0ZW0gMDA6MDk6IFtpbyAgMHgwY2FkLTB4MGNhZl0gaGFzIGJlZW4gcmVzZXJ2
ZWQKRGVjICAxIDE1OjU1OjIxIEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgICAwLjE5Mjk3NF0gc3lz
dGVtIDAwOjA5OiBbaW8gIDB4MGMyMC0weDBjM2ZdIGhhcyBiZWVuIHJlc2VydmVkCkRlYyAgMSAx
NTo1NToyMSBHcmlkb3NfTm9kZSBrZXJuZWw6IFsgICAgMC4xOTI5NzRdIHN5c3RlbSAwMDowYjog
W21lbSAweGUwMDAwMDAwLTB4ZWZmZmZmZmZdIGhhcyBiZWVuIHJlc2VydmVkCkRlYyAgMSAxNTo1
NToyMSBHcmlkb3NfTm9kZSBrZXJuZWw6IFsgICAgMC4xOTI5NzRdIHBucDogUG5QIEFDUEk6IGZv
dW5kIDEzIGRldmljZXMKRGVjICAxIDE1OjU1OjIxIEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgICAw
LjE5Mjk3NF0gQUNQSTogQUNQSSBidXMgdHlwZSBwbnAgdW5yZWdpc3RlcmVkCkRlYyAgMSAxNTo1
NToyMSBHcmlkb3NfTm9kZSBrZXJuZWw6IFsgICAgMC4yMTY5MzJdIFBNLVRpbWVyIGZhaWxlZCBj
b25zaXN0ZW5jeSBjaGVjayAgKDB4MHhmZmZmZmYpIC0gYWJvcnRpbmcuCkRlYyAgMSAxNTo1NToy
MSBHcmlkb3NfTm9kZSBrZXJuZWw6IFsgICAgMC4yMTcwODNdIHBjaSAwMDAwOjA5OjA2LjA6IGFk
ZHJlc3Mgc3BhY2UgY29sbGlzaW9uOiBbbWVtIDB4ZGY2MDAwMDAtMHhkZjY3ZmZmZiBwcmVmXSBj
b25mbGljdHMgd2l0aCAwMDAwOjA5OjA1LjAgW21lbSAweGRmNjAwMDAwLTB4ZGY2MGZmZmYgcHJl
Zl0KRGVjICAxIDE1OjU1OjIxIEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgICAwLjIxNzQwMl0gcGNp
IDAwMDA6MDA6MWYuMTogQkFSIDU6IGFzc2lnbmVkIFttZW0gMHhiZmZmZjAwMC0weGJmZmZmM2Zm
XQpEZWMgIDEgMTU6NTU6MjEgR3JpZG9zX05vZGUga2VybmVsOiBbICAgIDAuMjE3NTA3XSBwY2kg
MDAwMDowMDoxZi4xOiBCQVIgNTogc2V0IHRvIFttZW0gMHhiZmZmZjAwMC0weGJmZmZmM2ZmXSAo
UENJIGFkZHJlc3MgWzB4YmZmZmYwMDAtMHhiZmZmZjNmZl0pCkRlYyAgMSAxNTo1NToyMSBHcmlk
b3NfTm9kZSBrZXJuZWw6IFsgICAgMC4yMTc2MjNdIHBjaSAwMDAwOjAxOjAwLjA6IFBDSSBicmlk
Z2UgdG8gW2J1cyAwMi0wMl0KRGVjICAxIDE1OjU1OjIxIEdyaWRvc19Ob2RlIGtlcm5lbDogWyAg
ICAwLjIxNzcyMF0gcGNpIDAwMDA6MDE6MDAuMDogICBicmlkZ2Ugd2luZG93IFtpbyAgMHhlMDAw
LTB4ZWZmZl0KRGVjICAxIDE1OjU1OjIxIEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgICAwLjIxNzgy
NV0gcGNpIDAwMDA6MDE6MDAuMDogICBicmlkZ2Ugd2luZG93IFttZW0gMHhkZmQwMDAwMC0weGRm
ZWZmZmZmXQpEZWMgIDEgMTU6NTU6MjEgR3JpZG9zX05vZGUga2VybmVsOiBbICAgIDAuMjE3OTI3
XSBwY2kgMDAwMDowMTowMC4wOiAgIGJyaWRnZSB3aW5kb3cgW21lbSAweGQ4MDAwMDAwLTB4ZDhm
ZmZmZmYgNjRiaXQgcHJlZl0KRGVjICAxIDE1OjU1OjIxIEdyaWRvc19Ob2RlIGtlcm5lbDogWyAg
ICAwLjIxODA1Ml0gcGNpIDAwMDA6MDE6MDAuMjogUENJIGJyaWRnZSB0byBbYnVzIDAzLTAzXQpE
ZWMgIDEgMTU6NTU6MjEgR3JpZG9zX05vZGUga2VybmVsOiBbICAgIDAuMjE4MTQ0XSBwY2kgMDAw
MDowMTowMC4yOiAgIGJyaWRnZSB3aW5kb3cgW2lvICBkaXNhYmxlZF0KRGVjICAxIDE1OjU1OjIx
IEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgICAwLjIxODI0N10gcGNpIDAwMDA6MDE6MDAuMjogICBi
cmlkZ2Ugd2luZG93IFttZW0gZGlzYWJsZWRdCkRlYyAgMSAxNTo1NToyMSBHcmlkb3NfTm9kZSBr
ZXJuZWw6IFsgICAgMC4yMTgzNDddIHBjaSAwMDAwOjAxOjAwLjI6ICAgYnJpZGdlIHdpbmRvdyBb
bWVtIHByZWYgZGlzYWJsZWRdCkRlYyAgMSAxNTo1NToyMSBHcmlkb3NfTm9kZSBrZXJuZWw6IFsg
ICAgMC4yMTg0NTRdIHBjaSAwMDAwOjAwOjAyLjA6IFBDSSBicmlkZ2UgdG8gW2J1cyAwMS0wM10K
RGVjICAxIDE1OjU1OjIyIEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgICAwLjIxODU1MV0gcGNpIDAw
MDA6MDA6MDIuMDogICBicmlkZ2Ugd2luZG93IFtpbyAgMHhlMDAwLTB4ZWZmZl0KRGVjICAxIDE1
OjU1OjIyIEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgICAwLjIxODY1NV0gcGNpIDAwMDA6MDA6MDIu
MDogICBicmlkZ2Ugd2luZG93IFttZW0gMHhkZmMwMDAwMC0weGRmZWZmZmZmXQpEZWMgIDEgMTU6
NTU6MjIgR3JpZG9zX05vZGUga2VybmVsOiBbICAgIDAuMjE4NzU3XSBwY2kgMDAwMDowMDowMi4w
OiAgIGJyaWRnZSB3aW5kb3cgW21lbSAweGQ4MDAwMDAwLTB4ZDhmZmZmZmYgNjRiaXQgcHJlZl0K
RGVjICAxIDE1OjU1OjIyIEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgICAwLjIxODg4MV0gcGNpIDAw
MDA6MDA6MDQuMDogUENJIGJyaWRnZSB0byBbYnVzIDA0LTA0XQpEZWMgIDEgMTU6NTU6MjIgR3Jp
ZG9zX05vZGUga2VybmVsOiBbICAgIDAuMjE4OTczXSBwY2kgMDAwMDowMDowNC4wOiAgIGJyaWRn
ZSB3aW5kb3cgW2lvICBkaXNhYmxlZF0KRGVjICAxIDE1OjU1OjIyIEdyaWRvc19Ob2RlIGtlcm5l
bDogWyAgICAwLjIxOTA3Nl0gcGNpIDAwMDA6MDA6MDQuMDogICBicmlkZ2Ugd2luZG93IFttZW0g
ZGlzYWJsZWRdCkRlYyAgMSAxNTo1NToyMiBHcmlkb3NfTm9kZSBrZXJuZWw6IFsgICAgMC4yMTkx
NzVdIHBjaSAwMDAwOjAwOjA0LjA6ICAgYnJpZGdlIHdpbmRvdyBbbWVtIHByZWYgZGlzYWJsZWRd
CkRlYyAgMSAxNTo1NToyMiBHcmlkb3NfTm9kZSBrZXJuZWw6IFsgICAgMC4yMTkyODNdIHBjaSAw
MDAwOjA1OjAwLjA6IFBDSSBicmlkZ2UgdG8gW2J1cyAwNi0wNl0KRGVjICAxIDE1OjU1OjIyIEdy
aWRvc19Ob2RlIGtlcm5lbDogWyAgICAwLjIxOTM4MF0gcGNpIDAwMDA6MDU6MDAuMDogICBicmlk
Z2Ugd2luZG93IFtpbyAgMHhkMDAwLTB4ZGZmZl0KRGVjICAxIDE1OjU1OjIyIEdyaWRvc19Ob2Rl
IGtlcm5lbDogWyAgICAwLjIxOTQ4NF0gcGNpIDAwMDA6MDU6MDAuMDogICBicmlkZ2Ugd2luZG93
IFttZW0gMHhkZmEwMDAwMC0weGRmYmZmZmZmXQpEZWMgIDEgMTU6NTU6MjIgR3JpZG9zX05vZGUg
a2VybmVsOiBbICAgIDAuMjE5NTg1XSBwY2kgMDAwMDowNTowMC4wOiAgIGJyaWRnZSB3aW5kb3cg
W21lbSBwcmVmIGRpc2FibGVkXQpEZWMgIDEgMTU6NTU6MjIgR3JpZG9zX05vZGUga2VybmVsOiBb
ICAgIDAuMjE5NjkzXSBwY2kgMDAwMDowNTowMC4yOiBQQ0kgYnJpZGdlIHRvIFtidXMgMDctMDdd
CkRlYyAgMSAxNTo1NToyMiBHcmlkb3NfTm9kZSBrZXJuZWw6IFsgICAgMC4yMTk3ODldIHBjaSAw
MDAwOjA1OjAwLjI6ICAgYnJpZGdlIHdpbmRvdyBbaW8gIDB4YzAwMC0weGNmZmZdCkRlYyAgMSAx
NTo1NToyMiBHcmlkb3NfTm9kZSBrZXJuZWw6IFsgICAgMC4yMTk4OTRdIHBjaSAwMDAwOjA1OjAw
LjI6ICAgYnJpZGdlIHdpbmRvdyBbbWVtIDB4ZGY4MDAwMDAtMHhkZjlmZmZmZl0KRGVjICAxIDE1
OjU1OjIyIEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgICAwLjIxOTk5NV0gcGNpIDAwMDA6MDU6MDAu
MjogICBicmlkZ2Ugd2luZG93IFttZW0gcHJlZiBkaXNhYmxlZF0KRGVjICAxIDE1OjU1OjIyIEdy
aWRvc19Ob2RlIGtlcm5lbDogWyAgICAwLjIyMDAzMV0gcGNpIDAwMDA6MDA6MDUuMDogUENJIGJy
aWRnZSB0byBbYnVzIDA1LTA3XQpEZWMgIDEgMTU6NTU6MjIgR3JpZG9zX05vZGUga2VybmVsOiBb
ICAgIDAuMjIwMDMxXSBwY2kgMDAwMDowMDowNS4wOiAgIGJyaWRnZSB3aW5kb3cgW2lvICAweGMw
MDAtMHhkZmZmXQpEZWMgIDEgMTU6NTU6MjIgR3JpZG9zX05vZGUga2VybmVsOiBbICAgIDAuMjIw
MDMxXSBwY2kgMDAwMDowMDowNS4wOiAgIGJyaWRnZSB3aW5kb3cgW21lbSAweGRmNzAwMDAwLTB4
ZGZiZmZmZmZdCkRlYyAgMSAxNTo1NToyMiBHcmlkb3NfTm9kZSBrZXJuZWw6IFsgICAgMC4yMjAw
MzFdIHBjaSAwMDAwOjAwOjA1LjA6ICAgYnJpZGdlIHdpbmRvdyBbbWVtIHByZWYgZGlzYWJsZWRd
CkRlYyAgMSAxNTo1NToyMiBHcmlkb3NfTm9kZSBrZXJuZWw6IFsgICAgMC4yMjAwMzFdIHBjaSAw
MDAwOjAwOjA2LjA6IFBDSSBicmlkZ2UgdG8gW2J1cyAwOC0wOF0KRGVjICAxIDE1OjU1OjIyIEdy
aWRvc19Ob2RlIGtlcm5lbDogWyAgICAwLjIyMDAzMV0gcGNpIDAwMDA6MDA6MDYuMDogICBicmlk
Z2Ugd2luZG93IFtpbyAgZGlzYWJsZWRdCkRlYyAgMSAxNTo1NToyMiBHcmlkb3NfTm9kZSBrZXJu
ZWw6IFsgICAgMC4yMjAwMzFdIHBjaSAwMDAwOjAwOjA2LjA6ICAgYnJpZGdlIHdpbmRvdyBbbWVt
IGRpc2FibGVkXQpEZWMgIDEgMTU6NTU6MjIgR3JpZG9zX05vZGUga2VybmVsOiBbICAgIDAuMjIw
MDMxXSBwY2kgMDAwMDowMDowNi4wOiAgIGJyaWRnZSB3aW5kb3cgW21lbSBwcmVmIGRpc2FibGVk
XQpEZWMgIDEgMTU6NTU6MjIgR3JpZG9zX05vZGUga2VybmVsOiBbICAgIDAuMjIwMDMxXSBwY2kg
MDAwMDowOTowNi4wOiBCQVIgNjogYXNzaWduZWQgW21lbSAweGQwMDAwMDAwLTB4ZDAwN2ZmZmYg
cHJlZl0KRGVjICAxIDE1OjU1OjIyIEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgICAwLjIyMDAzMV0g
cGNpIDAwMDA6MDk6MGQuMDogQkFSIDY6IGFzc2lnbmVkIFttZW0gMHhkMDA4MDAwMC0weGQwMDlm
ZmZmIHByZWZdCkRlYyAgMSAxNTo1NToyMiBHcmlkb3NfTm9kZSBrZXJuZWw6IFsgICAgMC4yMjAw
MzFdIHBjaSAwMDAwOjAwOjFlLjA6IFBDSSBicmlkZ2UgdG8gW2J1cyAwOS0wOV0KRGVjICAxIDE1
OjU1OjIyIEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgICAwLjIyMDAzMV0gcGNpIDAwMDA6MDA6MWUu
MDogICBicmlkZ2Ugd2luZG93IFtpbyAgMHhiMDAwLTB4YmZmZl0KRGVjICAxIDE1OjU1OjIyIEdy
aWRvc19Ob2RlIGtlcm5lbDogWyAgICAwLjIyMDAzMV0gcGNpIDAwMDA6MDA6MWUuMDogICBicmlk
Z2Ugd2luZG93IFttZW0gMHhkZjUwMDAwMC0weGRmNmZmZmZmXQpEZWMgIDEgMTU6NTU6MjIgR3Jp
ZG9zX05vZGUga2VybmVsOiBbICAgIDAuMjIwMDMxXSBwY2kgMDAwMDowMDoxZS4wOiAgIGJyaWRn
ZSB3aW5kb3cgW21lbSAweGM4MDAwMDAwLTB4ZDdmZmZmZmYgcHJlZl0KRGVjICAxIDE1OjU1OjIy
IEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgICAwLjIyMTYxOV0gcGNpIDAwMDA6MDA6MDIuMDogUENJ
IElOVCBBIC0+IEdTSSAxNiAobGV2ZWwsIGxvdykgLT4gSVJRIDE2CkRlYyAgMSAxNTo1NToyMiBH
cmlkb3NfTm9kZSBrZXJuZWw6IFsgICAgMC4yMjE4MDJdIHhlbl9tYXBfcGlycV9nc2k6IHJldHVy
bmluZyBpcnEgMTYgZm9yIGdzaSAxNgpEZWMgIDEgMTU6NTU6MjIgR3JpZG9zX05vZGUga2VybmVs
OiBbICAgIDAuMjIxOTAxXSBBbHJlYWR5IHNldHVwIHRoZSBHU0kgOjE2CkRlYyAgMSAxNTo1NToy
MiBHcmlkb3NfTm9kZSBrZXJuZWw6IFsgICAgMC4yMjE5OTJdIHBjaSAwMDAwOjAwOjA0LjA6IFBD
SSBJTlQgQSAtPiBHU0kgMTYgKGxldmVsLCBsb3cpIC0+IElSUSAxNgpEZWMgIDEgMTU6NTU6MjIg
R3JpZG9zX05vZGUga2VybmVsOiBbICAgIDAuMjIyMTI0XSB4ZW5fbWFwX3BpcnFfZ3NpOiByZXR1
cm5pbmcgaXJxIDE2IGZvciBnc2kgMTYKRGVjICAxIDE1OjU1OjIyIEdyaWRvc19Ob2RlIGtlcm5l
bDogWyAgICAwLjIyMjIyMl0gQWxyZWFkeSBzZXR1cCB0aGUgR1NJIDoxNgpEZWMgIDEgMTU6NTU6
MjIgR3JpZG9zX05vZGUga2VybmVsOiBbICAgIDAuMjIyMzEzXSBwY2kgMDAwMDowMDowNS4wOiBQ
Q0kgSU5UIEEgLT4gR1NJIDE2IChsZXZlbCwgbG93KSAtPiBJUlEgMTYKRGVjICAxIDE1OjU1OjIy
IEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgICAwLjIyMjQ5Nl0geGVuX21hcF9waXJxX2dzaTogcmV0
dXJuaW5nIGlycSAxNiBmb3IgZ3NpIDE2CkRlYyAgMSAxNTo1NToyMyBHcmlkb3NfTm9kZSBrZXJu
ZWw6IFsgICAgMC4yMjI1OTVdIEFscmVhZHkgc2V0dXAgdGhlIEdTSSA6MTYKRGVjICAxIDE1OjU1
OjIzIEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgICAwLjIyMjY4Nl0gcGNpIDAwMDA6MDA6MDYuMDog
UENJIElOVCBBIC0+IEdTSSAxNiAobGV2ZWwsIGxvdykgLT4gSVJRIDE2CkRlYyAgMSAxNTo1NToy
MyBHcmlkb3NfTm9kZSBrZXJuZWw6IFsgICAgMC4yMjM0OTJdIE5FVDogUmVnaXN0ZXJlZCBwcm90
b2NvbCBmYW1pbHkgMgpEZWMgIDEgMTU6NTU6MjMgR3JpZG9zX05vZGUga2VybmVsOiBbICAgIDAu
MjIzODU3XSBJUCByb3V0ZSBjYWNoZSBoYXNoIHRhYmxlIGVudHJpZXM6IDQwOTYgKG9yZGVyOiAy
LCAxNjM4NCBieXRlcykKRGVjICAxIDE1OjU1OjIzIEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgICAw
LjIyNTI1MV0gVENQIGVzdGFibGlzaGVkIGhhc2ggdGFibGUgZW50cmllczogMTYzODQgKG9yZGVy
OiA1LCAxMzEwNzIgYnl0ZXMpCkRlYyAgMSAxNTo1NToyMyBHcmlkb3NfTm9kZSBrZXJuZWw6IFsg
ICAgMC4yMjU0NzFdIFRDUCBiaW5kIGhhc2ggdGFibGUgZW50cmllczogMTYzODQgKG9yZGVyOiA1
LCAxMzEwNzIgYnl0ZXMpCkRlYyAgMSAxNTo1NToyMyBHcmlkb3NfTm9kZSBrZXJuZWw6IFsgICAg
MC4yMjU2MzddIFRDUDogSGFzaCB0YWJsZXMgY29uZmlndXJlZCAoZXN0YWJsaXNoZWQgMTYzODQg
YmluZCAxNjM4NCkKRGVjICAxIDE1OjU1OjIzIEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgICAwLjIy
NTczMV0gVENQIHJlbm8gcmVnaXN0ZXJlZApEZWMgIDEgMTU6NTU6MjMgR3JpZG9zX05vZGUga2Vy
bmVsOiBbICAgIDAuMjI1ODI3XSBVRFAgaGFzaCB0YWJsZSBlbnRyaWVzOiAyNTYgKG9yZGVyOiAx
LCA4MTkyIGJ5dGVzKQpEZWMgIDEgMTU6NTU6MjMgR3JpZG9zX05vZGUga2VybmVsOiBbICAgIDAu
MjI1OTI5XSBVRFAtTGl0ZSBoYXNoIHRhYmxlIGVudHJpZXM6IDI1NiAob3JkZXI6IDEsIDgxOTIg
Ynl0ZXMpCkRlYyAgMSAxNTo1NToyMyBHcmlkb3NfTm9kZSBrZXJuZWw6IFsgICAgMC4yMjY2MjRd
IE5FVDogUmVnaXN0ZXJlZCBwcm90b2NvbCBmYW1pbHkgMQpEZWMgIDEgMTU6NTU6MjMgR3JpZG9z
X05vZGUga2VybmVsOiBbICAgIDAuMjI3NzMxXSBVbnBhY2tpbmcgaW5pdHJhbWZzLi4uCkRlYyAg
MSAxNTo1NToyMyBHcmlkb3NfTm9kZSBrZXJuZWw6IFsgICAgMC4yNDUxNTZdIGRlYnVnOiB1bm1h
cHBpbmcgaW5pdCBtZW1vcnkgYzE2NjcwMDAuLmMxYTFlMDAwCkRlYyAgMSAxNTo1NToyMyBHcmlk
b3NfTm9kZSBrZXJuZWw6IFsgICAgMC4yNDkwNTRdIG1pY3JvY29kZTogQ1BVMCBzaWc9MHhmNDMs
IHBmPTB4MSwgcmV2aXNpb249MHg1CkRlYyAgMSAxNTo1NToyMyBHcmlkb3NfTm9kZSBrZXJuZWw6
IFsgICAgMC4yNDkxODRdIG1pY3JvY29kZTogQ1BVMSBzaWc9MHhmNDMsIHBmPTB4MSwgcmV2aXNp
b249MHg1CkRlYyAgMSAxNTo1NToyMyBHcmlkb3NfTm9kZSBrZXJuZWw6IFsgICAgMC4yNDkyOTld
IG1pY3JvY29kZTogQ1BVMiBzaWc9MHhmNDMsIHBmPTB4MSwgcmV2aXNpb249MHg1CkRlYyAgMSAx
NTo1NToyMyBHcmlkb3NfTm9kZSBrZXJuZWw6IFsgICAgMC4yNDk0MThdIG1pY3JvY29kZTogQ1BV
MyBzaWc9MHhmNDMsIHBmPTB4MSwgcmV2aXNpb249MHg1CkRlYyAgMSAxNTo1NToyMyBHcmlkb3Nf
Tm9kZSBrZXJuZWw6IFsgICAgMC4yNDk2NzBdIG1pY3JvY29kZTogTWljcm9jb2RlIFVwZGF0ZSBE
cml2ZXI6IHYyLjAwIDx0aWdyYW5AYWl2YXppYW4uZnNuZXQuY28udWs+LCBQZXRlciBPcnViYQpE
ZWMgIDEgMTU6NTU6MjMgR3JpZG9zX05vZGUga2VybmVsOiBbICAgIDAuMjU0NjY3XSBtc2dtbmkg
aGFzIGJlZW4gc2V0IHRvIDc1MgpEZWMgIDEgMTU6NTU6MjMgR3JpZG9zX05vZGUga2VybmVsOiBb
ICAgIDAuMjU2MDM5XSBCbG9jayBsYXllciBTQ1NJIGdlbmVyaWMgKGJzZykgZHJpdmVyIHZlcnNp
b24gMC40IGxvYWRlZCAobWFqb3IgMjU0KQpEZWMgIDEgMTU6NTU6MjMgR3JpZG9zX05vZGUga2Vy
bmVsOiBbICAgIDAuMjU2MTUxXSBpbyBzY2hlZHVsZXIgbm9vcCByZWdpc3RlcmVkCkRlYyAgMSAx
NTo1NToyMyBHcmlkb3NfTm9kZSBrZXJuZWw6IFsgICAgMC4yNTYyNDJdIGlvIHNjaGVkdWxlciBk
ZWFkbGluZSByZWdpc3RlcmVkCkRlYyAgMSAxNTo1NToyMyBHcmlkb3NfTm9kZSBrZXJuZWw6IFsg
ICAgMC4yNTY1MDhdIGlvIHNjaGVkdWxlciBjZnEgcmVnaXN0ZXJlZCAoZGVmYXVsdCkKRGVjICAx
IDE1OjU1OjIzIEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgICAwLjI2OTk5Nl0gRXZlbnQtY2hhbm5l
bCBkZXZpY2UgaW5zdGFsbGVkLgpEZWMgIDEgMTU6NTU6MjMgR3JpZG9zX05vZGUga2VybmVsOiBb
ICAgIDAuMjcxNjE2XSBTZXJpYWw6IDgyNTAvMTY1NTAgZHJpdmVyLCA0IHBvcnRzLCBJUlEgc2hh
cmluZyBlbmFibGVkCkRlYyAgMSAxNTo1NToyMyBHcmlkb3NfTm9kZSBrZXJuZWw6IFsgICAgMC41
NzAyNTddIHNlcmlhbDgyNTA6IHR0eVMwIGF0IEkvTyAweDNmOCAoaXJxID0gNCkgaXMgYSAxNjU1
MEEKRGVjICAxIDE1OjU1OjIzIEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgICAwLjczMDA1OV0gMDA6
MDg6IHR0eVMwIGF0IEkvTyAweDNmOCAoaXJxID0gNCkgaXMgYSAxNjU1MEEKRGVjICAxIDE1OjU1
OjIzIEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgICAwLjc5MDMyNl0gc2VyaWFsIDAwMDA6MDk6MDUu
MTogUENJIElOVCBCIC0+IEdTSSAyMSAobGV2ZWwsIGxvdykgLT4gSVJRIDIxCkRlYyAgMSAxNTo1
NToyMyBHcmlkb3NfTm9kZSBrZXJuZWw6IFsgICAgMC44MDAwNjBdIDAwMDA6MDk6MDUuMTogdHR5
UzEgYXQgSS9PIDB4YmM4MCAoaXJxID0gMjEpIGlzIGEgMTY1NTBBCkRlYyAgMSAxNTo1NToyMyBH
cmlkb3NfTm9kZSBrZXJuZWw6IFsgICAgMC44NDA0MTBdIFJlYWwgVGltZSBDbG9jayBEcml2ZXIg
djEuMTJiCkRlYyAgMSAxNTo1NToyMyBHcmlkb3NfTm9kZSBrZXJuZWw6IFsgICAgMC44NDA2NDZd
IGludGVsX3JuZzogRldIIG5vdCBkZXRlY3RlZApEZWMgIDEgMTU6NTU6MjMgR3JpZG9zX05vZGUg
a2VybmVsOiBbICAgIDAuODQ1OTE1XSBpODA0MjogUE5QOiBQUy8yIENvbnRyb2xsZXIgW1BOUDAz
MDM6S0JELFBOUDBmMTM6TU9VXSBhdCAweDYwLDB4NjQgaXJxIDEsMTIKRGVjICAxIDE1OjU1OjIz
IEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgICAwLjg0ODgzMl0gc2VyaW86IGk4MDQyIEtCRCBwb3J0
IGF0IDB4NjAsMHg2NCBpcnEgMQpEZWMgIDEgMTU6NTU6MjMgR3JpZG9zX05vZGUga2VybmVsOiBb
ICAgIDAuODQ4OTM2XSBzZXJpbzogaTgwNDIgQVVYIHBvcnQgYXQgMHg2MCwweDY0IGlycSAxMgpE
ZWMgIDEgMTU6NTU6MjMgR3JpZG9zX05vZGUga2VybmVsOiBbICAgIDAuODQ5NDExXSBtb3VzZWRl
djogUFMvMiBtb3VzZSBkZXZpY2UgY29tbW9uIGZvciBhbGwgbWljZQpEZWMgIDEgMTU6NTU6MjMg
R3JpZG9zX05vZGUga2VybmVsOiBbICAgIDAuODUwMDA5XSBjcHVpZGxlOiB1c2luZyBnb3Zlcm5v
ciBsYWRkZXIKRGVjICAxIDE1OjU1OjIzIEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgICAwLjg1MTc4
MV0gVENQIGN1YmljIHJlZ2lzdGVyZWQKRGVjICAxIDE1OjU1OjIzIEdyaWRvc19Ob2RlIGtlcm5l
bDogWyAgICAwLjg1MTg3M10gTkVUOiBSZWdpc3RlcmVkIHByb3RvY29sIGZhbWlseSAxNwpEZWMg
IDEgMTU6NTU6MjMgR3JpZG9zX05vZGUga2VybmVsOiBbICAgIDAuODUxOTk0XSBVc2luZyBJUEkg
Tm8tU2hvcnRjdXQgbW9kZQpEZWMgIDEgMTU6NTU6MjMgR3JpZG9zX05vZGUga2VybmVsOiBbICAg
IDAuODU0MjAwXSBkZWJ1ZzogdW5tYXBwaW5nIGluaXQgbWVtb3J5IGMxMzQ1MDAwLi5jMTNhNTAw
MApEZWMgIDEgMTU6NTU6MjMgR3JpZG9zX05vZGUga2VybmVsOiBbICAgIDAuODcwMTYwXSBuYXNo
LWhvdHBsdWcgKDM5KTogL3Byb2MvMzkvb29tX2FkaiBpcyBkZXByZWNhdGVkLCBwbGVhc2UgdXNl
IC9wcm9jLzM5L29vbV9zY29yZV9hZGogaW5zdGVhZC4KRGVjICAxIDE1OjU1OjIzIEdyaWRvc19O
b2RlIGtlcm5lbDogWyAgICAwLjkxMzgxMF0gaW5wdXQ6IEFUIFRyYW5zbGF0ZWQgU2V0IDIga2V5
Ym9hcmQgYXMgL2RldmljZXMvcGxhdGZvcm0vaTgwNDIvc2VyaW8wL2lucHV0L2lucHV0MApEZWMg
IDEgMTU6NTU6MjMgR3JpZG9zX05vZGUga2VybmVsOiBbICAgIDEuMTUxNjU1XSBTQ1NJIHN1YnN5
c3RlbSBpbml0aWFsaXplZApEZWMgIDEgMTU6NTU6MjMgR3JpZG9zX05vZGUga2VybmVsOiBbICAg
IDEuMTY2Njk5XSBGdXNpb24gTVBUIGJhc2UgZHJpdmVyIDMuMDQuMTkKRGVjICAxIDE1OjU1OjIz
IEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgICAxLjE2Njc5M10gQ29weXJpZ2h0IChjKSAxOTk5LTIw
MDggTFNJIENvcnBvcmF0aW9uCkRlYyAgMSAxNTo1NToyMyBHcmlkb3NfTm9kZSBrZXJuZWw6IFsg
ICAgMS4xNzQzNjhdIEZ1c2lvbiBNUFQgU1BJIEhvc3QgZHJpdmVyIDMuMDQuMTkKRGVjICAxIDE1
OjU1OjIzIEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgICAxLjE3NDU2NV0gbXB0c3BpIDAwMDA6MDI6
MDUuMDogUENJIElOVCBBIC0+IEdTSSAzNCAobGV2ZWwsIGxvdykgLT4gSVJRIDM0CkRlYyAgMSAx
NTo1NToyNCBHcmlkb3NfTm9kZSBrZXJuZWw6IFsgICAgMS4xNzgyNDhdIG1wdGJhc2U6IGlvYzA6
IEluaXRpYXRpbmcgYnJpbmd1cApEZWMgIDEgMTU6NTU6MjQgR3JpZG9zX05vZGUga2VybmVsOiBb
ICAgIDEuODEyODQ2XSBpbnB1dDogSW1FeFBTLzIgR2VuZXJpYyBFeHBsb3JlciBNb3VzZSBhcyAv
ZGV2aWNlcy9wbGF0Zm9ybS9pODA0Mi9zZXJpbzEvaW5wdXQvaW5wdXQxCkRlYyAgMSAxNTo1NToy
NCBHcmlkb3NfTm9kZSBrZXJuZWw6IFsgICAgMi40MjAwODhdIGlvYzA6IExTSTUzQzEwMzAgQzA6
IENhcGFiaWxpdGllcz17SW5pdGlhdG9yLFRhcmdldH0KRGVjICAxIDE1OjU1OjI0IEdyaWRvc19O
b2RlIGtlcm5lbDogWyAgICA0LjEwOTExMF0gc2NzaTAgOiBpb2MwOiBMU0k1M0MxMDMwIEMwLCBG
d1Jldj0wMTAzMjMwMGgsIFBvcnRzPTEsIE1heFE9MjU1LCBJUlE9MzQKRGVjICAxIDE1OjU1OjI0
IEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgICA0LjkwOTQyOV0gc2NzaSAwOjA6MDowOiBEaXJlY3Qt
QWNjZXNzICAgICBNQVhUT1IgICBBVExBUzEwSzRfNzNTQ0EgIERGTTAgUFE6IDAgQU5TSTogMwpE
ZWMgIDEgMTU6NTU6MjQgR3JpZG9zX05vZGUga2VybmVsOiBbICAgIDQuOTA5NTc1XSBzY3NpIHRh
cmdldDA6MDowOiBCZWdpbm5pbmcgRG9tYWluIFZhbGlkYXRpb24KRGVjICAxIDE1OjU1OjI0IEdy
aWRvc19Ob2RlIGtlcm5lbDogWyAgICA0LjkyMzk4Ml0gc2NzaSB0YXJnZXQwOjA6MDogRW5kaW5n
IERvbWFpbiBWYWxpZGF0aW9uCkRlYyAgMSAxNTo1NToyNCBHcmlkb3NfTm9kZSBrZXJuZWw6IFsg
ICAgNC45MjQyMjRdIHNjc2kgdGFyZ2V0MDowOjA6IEZBU1QtMTYwIFdJREUgU0NTSSAzMjAuMCBN
Qi9zIERUIElVIFJUSSAoNi4yNSBucywgb2Zmc2V0IDEyNykKRGVjICAxIDE1OjU1OjI0IEdyaWRv
c19Ob2RlIGtlcm5lbDogWyAgICA0LjkyNjQ0N10gc2QgMDowOjA6MDogW3NkYV0gMTQzMzc0NjUw
IDUxMi1ieXRlIGxvZ2ljYWwgYmxvY2tzOiAoNzMuNCBHQi82OC4zIEdpQikKRGVjICAxIDE1OjU1
OjI0IEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgICA0LjkyODQ3OF0gc2QgMDowOjA6MDogW3NkYV0g
V3JpdGUgUHJvdGVjdCBpcyBvZmYKRGVjICAxIDE1OjU1OjI0IEdyaWRvc19Ob2RlIGtlcm5lbDog
WyAgICA0LjkyOTc2N10gc2NzaSAwOjA6MTowOiBEaXJlY3QtQWNjZXNzICAgICBNQVhUT1IgICBB
VExBUzEwSzVfNzNTQ0EgIEpUMDAgUFE6IDAgQU5TSTogMwpEZWMgIDEgMTU6NTU6MjQgR3JpZG9z
X05vZGUga2VybmVsOiBbICAgIDQuOTI5OTgxXSBzY3NpIHRhcmdldDA6MDoxOiBCZWdpbm5pbmcg
RG9tYWluIFZhbGlkYXRpb24KRGVjICAxIDE1OjU1OjI0IEdyaWRvc19Ob2RlIGtlcm5lbDogWyAg
ICA0LjkzMTM5NV0gc2QgMDowOjA6MDogW3NkYV0gV3JpdGUgY2FjaGU6IGRpc2FibGVkLCByZWFk
IGNhY2hlOiBlbmFibGVkLCBzdXBwb3J0cyBEUE8gYW5kIEZVQQpEZWMgIDEgMTU6NTU6MjQgR3Jp
ZG9zX05vZGUga2VybmVsOiBbICAgIDQuOTQ2OTcwXSBzY3NpIHRhcmdldDA6MDoxOiBFbmRpbmcg
RG9tYWluIFZhbGlkYXRpb24KRGVjICAxIDE1OjU1OjI0IEdyaWRvc19Ob2RlIGtlcm5lbDogWyAg
ICA0Ljk0NzIxNF0gc2NzaSB0YXJnZXQwOjA6MTogRkFTVC0xNjAgV0lERSBTQ1NJIDMyMC4wIE1C
L3MgRFQgSVUgUlRJICg2LjI1IG5zLCBvZmZzZXQgMTI3KQpEZWMgIDEgMTU6NTU6MjQgR3JpZG9z
X05vZGUga2VybmVsOiBbICAgIDQuOTQ5MTAyXSBzZCAwOjA6MTowOiBbc2RiXSAxNDMzNzQ2NTAg
NTEyLWJ5dGUgbG9naWNhbCBibG9ja3M6ICg3My40IEdCLzY4LjMgR2lCKQpEZWMgIDEgMTU6NTU6
MjUgR3JpZG9zX05vZGUga2VybmVsOiBbICAgIDUuMjA1NDYxXSBzZCAwOjA6MTowOiBbc2RiXSBX
cml0ZSBQcm90ZWN0IGlzIG9mZgpEZWMgIDEgMTU6NTU6MjUgR3JpZG9zX05vZGUga2VybmVsOiBb
ICAgIDUuMjA1NzE3XSAgc2RhOiBzZGExIHNkYTIgc2RhMyBzZGE0IDwgc2RhNSA+CkRlYyAgMSAx
NTo1NToyNiBHcmlkb3NfTm9kZSBrZXJuZWw6IFsgICAgNS40NjIyNzNdIHNkIDA6MDoxOjA6IFtz
ZGJdIFdyaXRlIGNhY2hlOiBkaXNhYmxlZCwgcmVhZCBjYWNoZTogZW5hYmxlZCwgc3VwcG9ydHMg
RFBPIGFuZCBGVUEKRGVjICAxIDE1OjU1OjI3IEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgICA1Ljcy
MTc4MV0gc2QgMDowOjA6MDogW3NkYV0gQXR0YWNoZWQgU0NTSSBkaXNrCkRlYyAgMSAxNTo1NToy
OCBHcmlkb3NfTm9kZSBrZXJuZWw6IFsgICAgNS45NzgzMDNdICBzZGI6IHNkYjEKRGVjICAxIDE1
OjU1OjI4IEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgICA1Ljk4ODYyMF0gc2NzaSAwOjA6NjowOiBQ
cm9jZXNzb3IgICAgICAgICBQRS9QViAgICAxeDIgU0NTSSBCUCAgICAgIDEuMCAgUFE6IDAgQU5T
STogMgpEZWMgIDEgMTU6NTU6MjggR3JpZG9zX05vZGUga2VybmVsOiBbICAgIDUuOTg4NzcxXSBz
Y3NpIHRhcmdldDA6MDo2OiBCZWdpbm5pbmcgRG9tYWluIFZhbGlkYXRpb24KRGVjICAxIDE1OjU1
OjI4IEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgICA1Ljk5MzkxMV0gc2QgMDowOjE6MDogW3NkYl0g
QXR0YWNoZWQgU0NTSSBkaXNrCkRlYyAgMSAxNTo1NToyOCBHcmlkb3NfTm9kZSBrZXJuZWw6IFsg
ICAgNi4wMDk3MzJdIHNjc2kgdGFyZ2V0MDowOjY6IEVuZGluZyBEb21haW4gVmFsaWRhdGlvbgpE
ZWMgIDEgMTU6NTU6MjggR3JpZG9zX05vZGUga2VybmVsOiBbICAgIDYuMDA5OTc4XSBzY3NpIHRh
cmdldDA6MDo2OiBhc3luY2hyb25vdXMKRGVjICAxIDE1OjU1OjI5IEdyaWRvc19Ob2RlIHNtYXJ0
ZFsxOTk3XTogc21hcnRkIHZlcnNpb24gNS4zOCBbaTY4Ni1yZWRoYXQtbGludXgtZ251XSBDb3B5
cmlnaHQgKEMpIDIwMDItOCBCcnVjZSBBbGxlbiAKRGVjICAxIDE1OjU1OjI5IEdyaWRvc19Ob2Rl
IHNtYXJ0ZFsxOTk3XTogSG9tZSBwYWdlIGlzIGh0dHA6Ly9zbWFydG1vbnRvb2xzLnNvdXJjZWZv
cmdlLm5ldC8gIApEZWMgIDEgMTU6NTU6MjkgR3JpZG9zX05vZGUgc21hcnRkWzE5OTddOiBPcGVu
ZWQgY29uZmlndXJhdGlvbiBmaWxlIC9ldGMvc21hcnRkLmNvbmYgCkRlYyAgMSAxNTo1NToyOSBH
cmlkb3NfTm9kZSBzbWFydGRbMTk5N106IENvbmZpZ3VyYXRpb24gZmlsZSAvZXRjL3NtYXJ0ZC5j
b25mIHBhcnNlZC4gCkRlYyAgMSAxNTo1NToyOSBHcmlkb3NfTm9kZSBzbWFydGRbMTk5N106IERl
dmljZTogL2Rldi9zZGEsIG9wZW5lZCAKRGVjICAxIDE1OjU1OjI5IEdyaWRvc19Ob2RlIHNtYXJ0
ZFsxOTk3XTogRGV2aWNlOiAvZGV2L3NkYSwgaXMgU01BUlQgY2FwYWJsZS4gQWRkaW5nIHRvICJt
b25pdG9yIiBsaXN0LiAKRGVjICAxIDE1OjU1OjI5IEdyaWRvc19Ob2RlIHNtYXJ0ZFsxOTk3XTog
RGV2aWNlOiAvZGV2L3NkYiwgb3BlbmVkIApEZWMgIDEgMTU6NTU6MjkgR3JpZG9zX05vZGUgc21h
cnRkWzE5OTddOiBEZXZpY2U6IC9kZXYvc2RiLCBpcyBTTUFSVCBjYXBhYmxlLiBBZGRpbmcgdG8g
Im1vbml0b3IiIGxpc3QuIApEZWMgIDEgMTU6NTU6MjkgR3JpZG9zX05vZGUgc21hcnRkWzE5OTdd
OiBNb25pdG9yaW5nIDAgQVRBIGFuZCAyIFNDU0kgZGV2aWNlcyAKRGVjICAxIDE1OjU1OjMwIEdy
aWRvc19Ob2RlIHNtYXJ0ZFsxOTk5XTogc21hcnRkIGhhcyBmb3JrKCllZCBpbnRvIGJhY2tncm91
bmQgbW9kZS4gTmV3IFBJRD0xOTk5LiAKRGVjICAxIDE1OjU1OjM3IEdyaWRvc19Ob2RlIGtlcm5l
bDogWyAgICA4LjA4ODI5N10gRnVzaW9uIE1QVCBTQVMgSG9zdCBkcml2ZXIgMy4wNC4xOQpEZWMg
IDEgMTU6NTU6MzcgR3JpZG9zX05vZGUga2VybmVsOiBbICAgIDguMTA0NDA4XSBhdGFfcGlpeCAw
MDAwOjAwOjFmLjE6IGVuYWJsaW5nIGRldmljZSAoMDAwNSAtPiAwMDA3KQpEZWMgIDEgMTU6NTU6
MzcgR3JpZG9zX05vZGUga2VybmVsOiBbICAgIDguMTA0NTE0XSBhdGFfcGlpeCAwMDAwOjAwOjFm
LjE6IGNhbid0IGRlcml2ZSByb3V0aW5nIGZvciBQQ0kgSU5UIEEKRGVjICAxIDE1OjU1OjM3IEdy
aWRvc19Ob2RlIGtlcm5lbDogWyAgICA4LjEwNTM0OV0gYXRhX3BpaXggMDAwMDowMDoxZi4xOiBC
TURNQTogZmFpbGVkIHRvIHNldCBkbWEgbWFzaywgZmFsbGluZyBiYWNrIHRvIFBJTwpEZWMgIDEg
MTU6NTU6MzcgR3JpZG9zX05vZGUga2VybmVsOiBbICAgIDguMTA3MTgxXSBzY3NpMSA6IGF0YV9w
aWl4CkRlYyAgMSAxNTo1NTozNyBHcmlkb3NfTm9kZSBrZXJuZWw6IFsgICAgOC4xMDc3NDZdIHNj
c2kyIDogYXRhX3BpaXgKRGVjICAxIDE1OjU1OjM3IEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgICA4
LjEwODA3N10gYXRhMTogUEFUQSBtYXggUElPNCBjbWQgMHgxZjAgY3RsIDB4M2Y2IGJtZG1hIDB4
ZmMwMCBpcnEgMTQKRGVjICAxIDE1OjU1OjM3IEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgICA4LjEw
ODE3M10gYXRhMjogUEFUQSBtYXggUElPNCBjbWQgMHgxNzAgY3RsIDB4Mzc2IGJtZG1hIDB4ZmMw
OCBpcnEgMTUKRGVjICAxIDE1OjU1OjM3IEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgICA4LjI4MDQ0
OF0gYXRhMS4wMDogQVRBUEk6IFBISUxJUFMgRFZELVJPTSBTRFIwODksIFREMzYsIG1heCBVRE1B
LzMzCkRlYyAgMSAxNTo1NTozNyBHcmlkb3NfTm9kZSBrZXJuZWw6IFsgICAgOC4zMDAzMjZdIGF0
YTEuMDA6IGNvbmZpZ3VyZWQgZm9yIFBJTzQKRGVjICAxIDE1OjU1OjM3IEdyaWRvc19Ob2RlIGtl
cm5lbDogWyAgICA4LjMwMjA0OF0gc2NzaSAxOjA6MDowOiBDRC1ST00gICAgICAgICAgICBQSElM
SVBTICBEVkQtUk9NIFNEUjA4OSAgIFREMzYgUFE6IDAgQU5TSTogNQpEZWMgIDEgMTU6NTU6Mzcg
R3JpZG9zX05vZGUga2VybmVsOiBbICAgMTkuNTQ4NjUzXSBFWFQzLWZzOiBiYXJyaWVycyBub3Qg
ZW5hYmxlZApEZWMgIDEgMTU6NTU6MzcgR3JpZG9zX05vZGUga2VybmVsOiBbICAgMTkuNTY3NTI2
XSBram91cm5hbGQgc3RhcnRpbmcuICBDb21taXQgaW50ZXJ2YWwgNSBzZWNvbmRzCkRlYyAgMSAx
NTo1NTozNyBHcmlkb3NfTm9kZSBrZXJuZWw6IFsgICAxOS41Njc2NTddIEVYVDMtZnMgKHNkYTMp
OiBtb3VudGVkIGZpbGVzeXN0ZW0gd2l0aCBvcmRlcmVkIGRhdGEgbW9kZQpEZWMgIDEgMTU6NTU6
MzcgR3JpZG9zX05vZGUga2VybmVsOiBbICAgMjIuMTIxMDQwXSBpbnB1dDogUEMgU3BlYWtlciBh
cyAvZGV2aWNlcy9wbGF0Zm9ybS9wY3Nwa3IvaW5wdXQvaW5wdXQyCkRlYyAgMSAxNTo1NTozNyBH
cmlkb3NfTm9kZSBrZXJuZWw6IFsgICAyMi4yMDA1ODhdIHBhdGFfYWNwaSAwMDAwOjA5OjA2LjA6
IFBDSSBJTlQgQSAtPiBHU0kgMjMgKGxldmVsLCBsb3cpIC0+IElSUSAyMwpEZWMgIDEgMTU6NTU6
MzcgR3JpZG9zX05vZGUga2VybmVsOiBbICAgMjIuMjAwODUxXSBwYXRhX2FjcGkgMDAwMDowOTow
Ni4wOiBCTURNQTogZmFpbGVkIHRvIHNldCBkbWEgbWFzaywgZmFsbGluZyBiYWNrIHRvIFBJTwpE
ZWMgIDEgMTU6NTU6MzcgR3JpZG9zX05vZGUga2VybmVsOiBbICAgMjIuMjAxMDA0XSBwYXRhX2Fj
cGkgMDAwMDowOTowNi4wOiBQQ0kgSU5UIEEgZGlzYWJsZWQKRGVjICAxIDE1OjU1OjM3IEdyaWRv
c19Ob2RlIGtlcm5lbDogWyAgIDIyLjIxNzIwOV0gaVRDT192ZW5kb3Jfc3VwcG9ydDogdmVuZG9y
LXN1cHBvcnQ9MApEZWMgIDEgMTU6NTU6MzcgR3JpZG9zX05vZGUga2VybmVsOiBbICAgMjIuMjI0
NjA2XSBpVENPX3dkdDogSW50ZWwgVENPIFdhdGNoRG9nIFRpbWVyIERyaXZlciB2MS4wNgpEZWMg
IDEgMTU6NTU6MzcgR3JpZG9zX05vZGUga2VybmVsOiBbICAgMjIuMjI1MDEyXSBpVENPX3dkdDog
Rm91bmQgYSBJQ0g1IG9yIElDSDVSIFRDTyBkZXZpY2UgKFZlcnNpb249MSwgVENPQkFTRT0weDA4
NjApCkRlYyAgMSAxNTo1NTozNyBHcmlkb3NfTm9kZSBrZXJuZWw6IFsgICAyMi4yMjUyODBdIGlU
Q09fd2R0OiBpbml0aWFsaXplZC4gaGVhcnRiZWF0PTMwIHNlYyAobm93YXlvdXQ9MSkKRGVjICAx
IDE1OjU1OjM3IEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgIDIyLjI0NjUyMV0geGVuX21hcF9waXJx
X2dzaTogcmV0dXJuaW5nIGlycSAyMyBmb3IgZ3NpIDIzCkRlYyAgMSAxNTo1NTozOCBHcmlkb3Nf
Tm9kZSBrZXJuZWw6IFsgICAyMi4yNDY1NDVdIEFscmVhZHkgc2V0dXAgdGhlIEdTSSA6MjMKRGVj
ICAxIDE1OjU1OjM4IEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgIDIyLjI0NjU1Nl0gcGF0YV9zaWw2
ODAgMDAwMDowOTowNi4wOiBQQ0kgSU5UIEEgLT4gR1NJIDIzIChsZXZlbCwgbG93KSAtPiBJUlEg
MjMKRGVjICAxIDE1OjU1OjM4IEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgIDIyLjI0NjY1Ml0gc2ls
NjgwOiAxMzNNSHogY2xvY2suCkRlYyAgMSAxNTo1NTozOCBHcmlkb3NfTm9kZSBrZXJuZWw6IFsg
ICAyMi4yNDY4NDddIHBhdGFfc2lsNjgwIDAwMDA6MDk6MDYuMDogQk1ETUE6IGZhaWxlZCB0byBz
ZXQgZG1hIG1hc2ssIGZhbGxpbmcgYmFjayB0byBQSU8KRGVjICAxIDE1OjU1OjM4IEdyaWRvc19O
b2RlIGtlcm5lbDogWyAgIDIyLjI2NTQ4M10gc2NzaTMgOiBwYXRhX3NpbDY4MApEZWMgIDEgMTU6
NTU6MzggR3JpZG9zX05vZGUga2VybmVsOiBbICAgMjIuMjc2ODQ0XSBzY3NpNCA6IHBhdGFfc2ls
NjgwCkRlYyAgMSAxNTo1NTozOCBHcmlkb3NfTm9kZSBrZXJuZWw6IFsgICAyMi4yNzcyMzBdIGF0
YTM6IFBBVEEgbWF4IFBJTzQgY21kIDB4YmNmMCBjdGwgMHhiY2U0IGJtZG1hIDB4YmM3MCBpcnEg
MjMKRGVjICAxIDE1OjU1OjM4IEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgIDIyLjI3NzI0M10gYXRh
NDogUEFUQSBtYXggUElPNCBjbWQgMHhiY2Q4IGN0bCAweGJjZDAgYm1kbWEgMHhiYzc4IGlycSAy
MwpEZWMgIDEgMTU6NTU6MzggR3JpZG9zX05vZGUga2VybmVsOiBbICAgMjIuNDcxNTYxXSBhdGEz
LjAwOiBBVEFQSTogVklSVFVBTEZMT1BQWSBEUklWRSAgICAgICAgICAgICAgIEZsb3BweSwgLCBt
YXggUElPMwpEZWMgIDEgMTU6NTU6MzggR3JpZG9zX05vZGUga2VybmVsOiBbICAgMjIuNDcxNTc5
XSBhdGEzLjAxOiBBVEFQSTogVklSVFVBTENEUk9NIERSSVZFLCAsIG1heCBQSU8zCkRlYyAgMSAx
NTo1NTozOCBHcmlkb3NfTm9kZSBrZXJuZWw6IFsgICAyMi41MDIwMjhdIGF0YTMuMDA6IGNvbmZp
Z3VyZWQgZm9yIFBJTzMKRGVjICAxIDE1OjU1OjM4IEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgIDIy
LjUyMDQ3NV0gYXRhMy4wMTogY29uZmlndXJlZCBmb3IgUElPMwpEZWMgIDEgMTU6NTU6MzggR3Jp
ZG9zX05vZGUga2VybmVsOiBbICAgMjIuNTU0NDY4XSBzY3NpIDM6MDowOjA6IERpcmVjdC1BY2Nl
c3MgICAgIERFTEwgICAgICAgVlNGICAgICAgICAgICAgMDEyMyBQUTogMCBBTlNJOiA1CkRlYyAg
MSAxNTo1NTozOCBHcmlkb3NfTm9kZSBrZXJuZWw6IFsgICAyMi41NjQ1NzVdIHNjc2kgMzowOjE6
MDogQ0QtUk9NICAgICAgICAgICAgREVMTCAgICAgICBWQ0QgICAgICAgICAgICAwMTMzIFBROiAw
IEFOU0k6IDUKRGVjICAxIDE1OjU1OjM4IEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgIDIyLjYwNDY4
NV0gc2QgMzowOjA6MDogW3NkY10gQXR0YWNoZWQgU0NTSSByZW1vdmFibGUgZGlzawpEZWMgIDEg
MTU6NTU6MzggR3JpZG9zX05vZGUga2VybmVsOiBbICAgMjIuNjc1NzU2XSBGREMgMCBpcyBhIE5h
dGlvbmFsIFNlbWljb25kdWN0b3IgUEM4NzMwNgpEZWMgIDEgMTU6NTU6MzggR3JpZG9zX05vZGUg
a2VybmVsOiBbICAgMjIuODU0MDMyXSBpbnB1dDogUG93ZXIgQnV0dG9uIGFzIC9kZXZpY2VzL0xO
WFNZU1RNOjAwL0xOWFBXUkJOOjAwL2lucHV0L2lucHV0MwpEZWMgIDEgMTU6NTU6MzggR3JpZG9z
X05vZGUga2VybmVsOiBbICAgMjIuODU0MDUzXSBBQ1BJOiBQb3dlciBCdXR0b24gW1BXUkZdCkRl
YyAgMSAxNTo1NTozOCBHcmlkb3NfTm9kZSBrZXJuZWw6IFsgICAyMy4yODk0OTldIGUxMDAwOiBJ
bnRlbChSKSBQUk8vMTAwMCBOZXR3b3JrIERyaXZlciAtIHZlcnNpb24gNy4zLjIxLWs4LU5BUEkK
RGVjICAxIDE1OjU1OjM4IEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgIDIzLjI4OTUxM10gZTEwMDA6
IENvcHlyaWdodCAoYykgMTk5OS0yMDA2IEludGVsIENvcnBvcmF0aW9uLgpEZWMgIDEgMTU6NTU6
MzggR3JpZG9zX05vZGUga2VybmVsOiBbICAgMjMuMjg5Njc5XSBlMTAwMCAwMDAwOjA2OjA3LjA6
IFBDSSBJTlQgQSAtPiBHU0kgNjQgKGxldmVsLCBsb3cpIC0+IElSUSA2NApEZWMgIDEgMTU6NTU6
MzggR3JpZG9zX05vZGUga2VybmVsOiBbICAgMjMuMjkwMjY1XSBlMTAwMDogTm8gdXNhYmxlIERN
QSBjb25maWcsIGFib3J0aW5nCkRlYyAgMSAxNTo1NTozOCBHcmlkb3NfTm9kZSBrZXJuZWw6IFsg
ICAyMy4yOTA3MDFdIGUxMDAwIDAwMDA6MDY6MDcuMDogUENJIElOVCBBIGRpc2FibGVkCkRlYyAg
MSAxNTo1NTozOCBHcmlkb3NfTm9kZSBrZXJuZWw6IFsgICAyMy4yOTA3MjddIGUxMDAwOiBwcm9i
ZSBvZiAwMDAwOjA2OjA3LjAgZmFpbGVkIHdpdGggZXJyb3IgLTUKRGVjICAxIDE1OjU1OjM4IEdy
aWRvc19Ob2RlIGtlcm5lbDogWyAgIDIzLjI5MDgxMl0gZTEwMDAgMDAwMDowNzowOC4wOiBQQ0kg
SU5UIEEgLT4gR1NJIDY1IChsZXZlbCwgbG93KSAtPiBJUlEgNjUKRGVjICAxIDE1OjU1OjM4IEdy
aWRvc19Ob2RlIGtlcm5lbDogWyAgIDIzLjI5MTI4NF0gZTEwMDA6IE5vIHVzYWJsZSBETUEgY29u
ZmlnLCBhYm9ydGluZwpEZWMgIDEgMTU6NTU6MzggR3JpZG9zX05vZGUga2VybmVsOiBbICAgMjMu
MjkxNzE2XSBlMTAwMCAwMDAwOjA3OjA4LjA6IFBDSSBJTlQgQSBkaXNhYmxlZApEZWMgIDEgMTU6
NTU6MzggR3JpZG9zX05vZGUga2VybmVsOiBbICAgMjMuMjkxNzM0XSBlMTAwMDogcHJvYmUgb2Yg
MDAwMDowNzowOC4wIGZhaWxlZCB3aXRoIGVycm9yIC01CkRlYyAgMSAxNTo1NTozOCBHcmlkb3Nf
Tm9kZSBrZXJuZWw6IFsgICAzMy4wNDQ3NjJdIHNyMDogc2NzaTMtbW1jIGRyaXZlOiAyNHgvMjR4
IGNkL3J3IHhhL2Zvcm0yIGNkZGEgdHJheQpEZWMgIDEgMTU6NTU6MzggR3JpZG9zX05vZGUga2Vy
bmVsOiBbICAgMzMuMDQ0Nzg3XSBjZHJvbTogVW5pZm9ybSBDRC1ST00gZHJpdmVyIFJldmlzaW9u
OiAzLjIwCkRlYyAgMSAxNTo1NTozOCBHcmlkb3NfTm9kZSBrZXJuZWw6IFsgICAzMy4wODQ5ODhd
IHNyMTogc2NzaS0xIGRyaXZlCkRlYyAgMSAxNTo1NTozOCBHcmlkb3NfTm9kZSBrZXJuZWw6IFsg
ICAzMy4zNjE0NjNdIHNkIDA6MDowOjA6IEF0dGFjaGVkIHNjc2kgZ2VuZXJpYyBzZzAgdHlwZSAw
CkRlYyAgMSAxNTo1NTozOSBHcmlkb3NfTm9kZSBrZXJuZWw6IFsgICAzMy4zNjE2ODZdIHNkIDA6
MDoxOjA6IEF0dGFjaGVkIHNjc2kgZ2VuZXJpYyBzZzEgdHlwZSAwCkRlYyAgMSAxNTo1NTozOSBH
cmlkb3NfTm9kZSBrZXJuZWw6IFsgICAzMy4zNjE5MDddIHNjc2kgMDowOjY6MDogQXR0YWNoZWQg
c2NzaSBnZW5lcmljIHNnMiB0eXBlIDMKRGVjICAxIDE1OjU1OjM5IEdyaWRvc19Ob2RlIGtlcm5l
bDogWyAgIDMzLjM2MjE0MV0gc3IgMTowOjA6MDogQXR0YWNoZWQgc2NzaSBnZW5lcmljIHNnMyB0
eXBlIDUKRGVjICAxIDE1OjU1OjM5IEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgIDMzLjM2MjM3NV0g
c2QgMzowOjA6MDogQXR0YWNoZWQgc2NzaSBnZW5lcmljIHNnNCB0eXBlIDAKRGVjICAxIDE1OjU1
OjM5IEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgIDMzLjM2MjYwMF0gc3IgMzowOjE6MDogQXR0YWNo
ZWQgc2NzaSBnZW5lcmljIHNnNSB0eXBlIDUKRGVjICAxIDE1OjU1OjM5IEdyaWRvc19Ob2RlIGtl
cm5lbDogWyAgIDM0LjI2MTY3OV0gTm9uLXZvbGF0aWxlIG1lbW9yeSBkcml2ZXIgdjEuMwpEZWMg
IDEgMTU6NTU6MzkgR3JpZG9zX05vZGUga2VybmVsOiBbICAgMzQuNjYzMzYzXSBtZDogQXV0b2Rl
dGVjdGluZyBSQUlEIGFycmF5cy4KRGVjICAxIDE1OjU1OjM5IEdyaWRvc19Ob2RlIGtlcm5lbDog
WyAgIDM0LjY2MzM3MV0gbWQ6IFNjYW5uZWQgMCBhbmQgYWRkZWQgMCBkZXZpY2VzLgpEZWMgIDEg
MTU6NTU6MzkgR3JpZG9zX05vZGUga2VybmVsOiBbICAgMzQuNjYzMzc4XSBtZDogYXV0b3J1biAu
Li4KRGVjICAxIDE1OjU1OjM5IEdyaWRvc19Ob2RlIGtlcm5lbDogWyAgIDM0LjY2MzM4M10gbWQ6
IC4uLiBhdXRvcnVuIERPTkUuCkRlYyAgMSAxNTo1NTozOSBHcmlkb3NfTm9kZSBrZXJuZWw6IFsg
ICAzNC43NjEzMDJdIGRldmljZS1tYXBwZXI6IGlvY3RsOiA0LjIwLjAtaW9jdGwgKDIwMTEtMDIt
MDIpIGluaXRpYWxpc2VkOiBkbS1kZXZlbEByZWRoYXQuY29tCkRlYyAgMSAxNTo1NTozOSBHcmlk
b3NfTm9kZSBrZXJuZWw6IFsgICAzNC44MjYyNjZdIGRldmljZS1tYXBwZXI6IG11bHRpcGF0aDog
dmVyc2lvbiAxLjMuMCBsb2FkZWQKRGVjICAxIDE1OjU1OjM5IEdyaWRvc19Ob2RlIGtlcm5lbDog
WyAgIDM1LjEyODU3NF0gbG9vcDogbW9kdWxlIGxvYWRlZApEZWMgIDEgMTU6NTU6MzkgR3JpZG9z
X05vZGUga2VybmVsOiBbICAgMzUuOTI4MjA0XSBFWFQzLWZzIChzZGEzKTogdXNpbmcgaW50ZXJu
YWwgam91cm5hbApEZWMgIDEgMTU6NTU6MzkgR3JpZG9zX05vZGUga2VybmVsOiBbICAgMzYuMDAx
OTE3XSBFWFQzLWZzOiBiYXJyaWVycyBub3QgZW5hYmxlZApEZWMgIDEgMTU6NTU6MzkgR3JpZG9z
X05vZGUga2VybmVsOiBbICAgMzYuMDAyMzU3XSBram91cm5hbGQgc3RhcnRpbmcuICBDb21taXQg
aW50ZXJ2YWwgNSBzZWNvbmRzCkRlYyAgMSAxNTo1NTozOSBHcmlkb3NfTm9kZSBrZXJuZWw6IFsg
ICAzNi4wMDg2ODNdIEVYVDMtZnMgKHNkYTIpOiB1c2luZyBpbnRlcm5hbCBqb3VybmFsCkRlYyAg
MSAxNTo1NTozOSBHcmlkb3NfTm9kZSBrZXJuZWw6IFsgICAzNi4wMDg2OTJdIEVYVDMtZnMgKHNk
YTIpOiBtb3VudGVkIGZpbGVzeXN0ZW0gd2l0aCBvcmRlcmVkIGRhdGEgbW9kZQpEZWMgIDEgMTU6
NTU6MzkgR3JpZG9zX05vZGUga2VybmVsOiBbICAgMzYuMDI0Mjg3XSBFWFQzLWZzOiBiYXJyaWVy
cyBub3QgZW5hYmxlZApEZWMgIDEgMTU6NTU6MzkgR3JpZG9zX05vZGUga2VybmVsOiBbICAgMzYu
MDI0NjkxXSBram91cm5hbGQgc3RhcnRpbmcuICBDb21taXQgaW50ZXJ2YWwgNSBzZWNvbmRzCkRl
YyAgMSAxNTo1NTozOSBHcmlkb3NfTm9kZSBrZXJuZWw6IFsgICAzNi4wMzA2MzddIEVYVDMtZnMg
KGRtLTApOiB1c2luZyBpbnRlcm5hbCBqb3VybmFsCkRlYyAgMSAxNTo1NTozOSBHcmlkb3NfTm9k
ZSBrZXJuZWw6IFsgICAzNi4wMzA2NDZdIEVYVDMtZnMgKGRtLTApOiBtb3VudGVkIGZpbGVzeXN0
ZW0gd2l0aCBvcmRlcmVkIGRhdGEgbW9kZQpEZWMgIDEgMTU6NTU6MzkgR3JpZG9zX05vZGUga2Vy
bmVsOiBbICAgMzYuOTQ0MzgzXSBORVQ6IFJlZ2lzdGVyZWQgcHJvdG9jb2wgZmFtaWx5IDEwCkRl
YyAgMSAxNTo1NTozOSBHcmlkb3NfTm9kZSBrZXJuZWw6IFsgICAzNy4wOTI1OTVdIGlwX3RhYmxl
czogKEMpIDIwMDAtMjAwNiBOZXRmaWx0ZXIgQ29yZSBUZWFtCkRlYyAgMSAxNTo1NTozOSBHcmlk
b3NfTm9kZSBrZXJuZWw6IFsgICA0Mi43OTA0NzddIHdhcm5pbmc6IGBkYnVzLWRhZW1vbicgdXNl
cyAzMi1iaXQgY2FwYWJpbGl0aWVzIChsZWdhY3kgc3VwcG9ydCBpbiB1c2UpCkRlYyAgMSAxNTo1
NTo1OSBHcmlkb3NfTm9kZSBhcHBsb2dpYzogVXNlciByb290IGhhcyBsb2dnZWQgaW50byBhbiBB
cHBMb2dpYyByZXN0cmljdGVkIGFyZWEuCkRlYyAgMSAxNTo1Nzo1MiBHcmlkb3NfTm9kZSBzaHV0
ZG93blsyNTQ4XTogc2h1dHRpbmcgZG93biBmb3Igc3lzdGVtIHJlYm9vdApEZWMgIDEgMTU6NTc6
NTIgR3JpZG9zX05vZGUgaW5pdDogU3dpdGNoaW5nIHRvIHJ1bmxldmVsOiA2CkRlYyAgMSAxNTo1
Nzo1MyBHcmlkb3NfTm9kZSBzbWFydGRbMTk5OV06IHNtYXJ0ZCByZWNlaXZlZCBzaWduYWwgMTU6
IFRlcm1pbmF0ZWQgCkRlYyAgMSAxNTo1Nzo1MyBHcmlkb3NfTm9kZSBzbWFydGRbMTk5OV06IHNt
YXJ0ZCBpcyBleGl0aW5nIChleGl0IHN0YXR1cyAwKSAKRGVjICAxIDE1OjU3OjU0IEdyaWRvc19O
b2RlIGtlcm5lbDogS2VybmVsIGxvZ2dpbmcgKHByb2MpIHN0b3BwZWQuCkRlYyAgMSAxNTo1Nzo1
NCBHcmlkb3NfTm9kZSBrZXJuZWw6IEtlcm5lbCBsb2cgZGFlbW9uIHRlcm1pbmF0aW5nLgpEZWMg
IDEgMTU6NTc6NTYgR3JpZG9zX05vZGUgZXhpdGluZyBvbiBzaWduYWwgMTUK

--_005_3E243B26F475504B9BB0BCC9728B0DA629E16E01USILMS110Acacom_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--_005_3E243B26F475504B9BB0BCC9728B0DA629E16E01USILMS110Acacom_--


From xen-devel-bounces@lists.xensource.com Fri Dec 09 20:21:59 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 20:21:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZ6wm-0005dv-GL; Fri, 09 Dec 2011 20:21:32 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres.lagarcavilla@gmail.com>) id 1RZ6wl-0005dT-7G
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 20:21:31 +0000
X-Env-Sender: andres.lagarcavilla@gmail.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1323462039!4774891!1
X-Originating-IP: [209.85.212.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.2; banners=-,-,lists.xensource.com
X-VirusChecked: Checked
Received: (qmail 22702 invoked from network); 9 Dec 2011 20:20:41 -0000
Received: from mail-vw0-f43.google.com (HELO mail-vw0-f43.google.com)
	(209.85.212.43)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 20:20:41 -0000
Received: by vbbfq11 with SMTP id fq11so9826217vbb.30
	for <xen-devel@lists.xensource.com>;
	Fri, 09 Dec 2011 12:20:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:message-id:user-agent:date:from:to:cc;
	bh=YcJE4r+35Cp4ArzXfFvhM3pvMemxrr+6zOWgVfY4tnE=;
	b=LWi2FsxIoZmf18dtYFqoweLGanVUzKU4idA898soiJkIGmBPUy75gqXo3Ux0mLuPcx
	NnIHfk4ZS4E/PfLRclkrSB71ZQGC8JuzPklGFEowHfY6NNdZgJ8JapLLnXYLYumpqzcw
	JZd39GGiLC008CtkZDd+HgJzcGvdwPc8gRXYc=
Received: by 10.52.35.177 with SMTP id i17mr5522507vdj.21.1323462039348;
	Fri, 09 Dec 2011 12:20:39 -0800 (PST)
Received: from xdev.gridcentric.ca ([206.223.182.18])
	by mx.google.com with ESMTPS id jo9sm7951430vdb.7.2011.12.09.12.20.37
	(version=TLSv1/SSLv3 cipher=OTHER);
	Fri, 09 Dec 2011 12:20:38 -0800 (PST)
MIME-Version: 1.0
Message-Id: <patchbomb.1323462093@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Fri, 09 Dec 2011 15:21:33 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, keir.xen@gmail.com, tim@xen.org, JBeulich@suse.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 0 of 9] x86/mm: Memory Sharing Overhaul V2
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This patch series proposes a comprehensive overhaul of the
memory sharing code. We include

- Clean ups.
- A reworked locking discipline. We introduce the use of per
 page locks to protect additions and removals of gfns to
 shared pages. We use RCU to manage a global list of shared
 pages used for auditing. The end result is the removal of
 the sharing global lock.
- New features:
 + Polling stats via console.
 + More stats: frames that are shared, pages that are saved.
   due to sharing
 + New sharing domctl to add a shared page directly to a whole
   in the physmap.
 + New sharing domctl to perform audits.
Relevant tools patches sent in a separate series.

A consequence of our modifications is a change to the sharing
API. While we refresh the only user of the sharing API in the 
tree, we want to make sure we are not affecting any other
users of the sharing API.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Signed-off-by: Adin Scannell <adin@scannell.ca>

 xen/arch/x86/mm.c                 |    6 +-
 xen/arch/x86/mm/mem_sharing.c     |   91 +++--
 xen/arch/x86/mm/mem_sharing.c     |  560 +++++++++++++++++++------------------
 xen/include/asm-x86/mem_sharing.h |   19 +-
 xen/include/asm-x86/mm.h          |   11 +-
 xen/include/public/domctl.h       |    3 +
 xen/arch/x86/mm/mem_sharing.c     |   57 +++-
 xen/include/public/domctl.h       |    9 +
 xen/arch/x86/mm.c                 |    6 -
 xen/arch/x86/mm/mem_sharing.c     |   29 +
 xen/arch/x86/x86_64/compat/mm.c   |    6 +
 xen/arch/x86/x86_64/mm.c          |    7 +
 xen/include/asm-x86/mem_sharing.h |    1 +
 xen/include/public/memory.h       |    1 +
 xen/arch/x86/mm.c                 |   74 +----
 xen/arch/x86/mm/mem_sharing.c     |  280 +++++++++++++++++-
 xen/arch/x86/mm/mm-locks.h        |   31 +-
 xen/include/asm-x86/mm.h          |   28 +-
 xen/arch/x86/mm/mem_sharing.c     |  104 +++++++
 xen/include/public/domctl.h       |    3 +-
 xen/arch/ia64/xen/mm.c            |    6 +
 xen/arch/x86/mm/mem_sharing.c     |    8 +
 xen/common/keyhandler.c           |    7 +-
 xen/include/xen/mm.h              |    3 +
 xen/arch/x86/mm/mem_sharing.c     |   15 +-
 xen/include/public/domctl.h       |    1 +
 xen/arch/x86/mm/mem_sharing.c     |   83 ++---
 xen/arch/x86/mm/mm-locks.h        |   18 -
 xen/include/asm-x86/mem_sharing.h |    3 +-
 29 files changed, 957 insertions(+), 513 deletions(-)

______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
______________________________________________________________________

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 20:21:59 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 20:21:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZ6wm-0005dv-GL; Fri, 09 Dec 2011 20:21:32 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres.lagarcavilla@gmail.com>) id 1RZ6wl-0005dT-7G
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 20:21:31 +0000
X-Env-Sender: andres.lagarcavilla@gmail.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1323462039!4774891!1
X-Originating-IP: [209.85.212.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.2; banners=-,-,lists.xensource.com
X-VirusChecked: Checked
Received: (qmail 22702 invoked from network); 9 Dec 2011 20:20:41 -0000
Received: from mail-vw0-f43.google.com (HELO mail-vw0-f43.google.com)
	(209.85.212.43)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 20:20:41 -0000
Received: by vbbfq11 with SMTP id fq11so9826217vbb.30
	for <xen-devel@lists.xensource.com>;
	Fri, 09 Dec 2011 12:20:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:message-id:user-agent:date:from:to:cc;
	bh=YcJE4r+35Cp4ArzXfFvhM3pvMemxrr+6zOWgVfY4tnE=;
	b=LWi2FsxIoZmf18dtYFqoweLGanVUzKU4idA898soiJkIGmBPUy75gqXo3Ux0mLuPcx
	NnIHfk4ZS4E/PfLRclkrSB71ZQGC8JuzPklGFEowHfY6NNdZgJ8JapLLnXYLYumpqzcw
	JZd39GGiLC008CtkZDd+HgJzcGvdwPc8gRXYc=
Received: by 10.52.35.177 with SMTP id i17mr5522507vdj.21.1323462039348;
	Fri, 09 Dec 2011 12:20:39 -0800 (PST)
Received: from xdev.gridcentric.ca ([206.223.182.18])
	by mx.google.com with ESMTPS id jo9sm7951430vdb.7.2011.12.09.12.20.37
	(version=TLSv1/SSLv3 cipher=OTHER);
	Fri, 09 Dec 2011 12:20:38 -0800 (PST)
MIME-Version: 1.0
Message-Id: <patchbomb.1323462093@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Fri, 09 Dec 2011 15:21:33 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, keir.xen@gmail.com, tim@xen.org, JBeulich@suse.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 0 of 9] x86/mm: Memory Sharing Overhaul V2
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This patch series proposes a comprehensive overhaul of the
memory sharing code. We include

- Clean ups.
- A reworked locking discipline. We introduce the use of per
 page locks to protect additions and removals of gfns to
 shared pages. We use RCU to manage a global list of shared
 pages used for auditing. The end result is the removal of
 the sharing global lock.
- New features:
 + Polling stats via console.
 + More stats: frames that are shared, pages that are saved.
   due to sharing
 + New sharing domctl to add a shared page directly to a whole
   in the physmap.
 + New sharing domctl to perform audits.
Relevant tools patches sent in a separate series.

A consequence of our modifications is a change to the sharing
API. While we refresh the only user of the sharing API in the 
tree, we want to make sure we are not affecting any other
users of the sharing API.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Signed-off-by: Adin Scannell <adin@scannell.ca>

 xen/arch/x86/mm.c                 |    6 +-
 xen/arch/x86/mm/mem_sharing.c     |   91 +++--
 xen/arch/x86/mm/mem_sharing.c     |  560 +++++++++++++++++++------------------
 xen/include/asm-x86/mem_sharing.h |   19 +-
 xen/include/asm-x86/mm.h          |   11 +-
 xen/include/public/domctl.h       |    3 +
 xen/arch/x86/mm/mem_sharing.c     |   57 +++-
 xen/include/public/domctl.h       |    9 +
 xen/arch/x86/mm.c                 |    6 -
 xen/arch/x86/mm/mem_sharing.c     |   29 +
 xen/arch/x86/x86_64/compat/mm.c   |    6 +
 xen/arch/x86/x86_64/mm.c          |    7 +
 xen/include/asm-x86/mem_sharing.h |    1 +
 xen/include/public/memory.h       |    1 +
 xen/arch/x86/mm.c                 |   74 +----
 xen/arch/x86/mm/mem_sharing.c     |  280 +++++++++++++++++-
 xen/arch/x86/mm/mm-locks.h        |   31 +-
 xen/include/asm-x86/mm.h          |   28 +-
 xen/arch/x86/mm/mem_sharing.c     |  104 +++++++
 xen/include/public/domctl.h       |    3 +-
 xen/arch/ia64/xen/mm.c            |    6 +
 xen/arch/x86/mm/mem_sharing.c     |    8 +
 xen/common/keyhandler.c           |    7 +-
 xen/include/xen/mm.h              |    3 +
 xen/arch/x86/mm/mem_sharing.c     |   15 +-
 xen/include/public/domctl.h       |    1 +
 xen/arch/x86/mm/mem_sharing.c     |   83 ++---
 xen/arch/x86/mm/mm-locks.h        |   18 -
 xen/include/asm-x86/mem_sharing.h |    3 +-
 29 files changed, 957 insertions(+), 513 deletions(-)

______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
______________________________________________________________________

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 20:22:38 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 20:22:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZ6xd-0005lP-B2; Fri, 09 Dec 2011 20:22:25 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RZ6xb-0005iU-2E
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 20:22:23 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-8.tower-21.messagelabs.com!1323462092!7602345!1
X-Originating-IP: [208.97.132.145]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNDUgPT4gMTczNjI=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6505 invoked from network); 9 Dec 2011 20:21:32 -0000
Received: from caiajhbdcbef.dreamhost.com (HELO homiemail-a18.g.dreamhost.com)
	(208.97.132.145) by server-8.tower-21.messagelabs.com with SMTP;
	9 Dec 2011 20:21:32 -0000
Received: from homiemail-a18.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a18.g.dreamhost.com (Postfix) with ESMTP id E9453250069;
	Fri,  9 Dec 2011 12:21:31 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=evZRM0bgp1FlStx++0yfHQl13IDYv0Z8oIF0oug0H510
	oDFyMByxyDYMsR3bLnN6oInysL8vlORn/BYzWytbtxY2v1KyOP98jdY9moYy6cim
	T+bpiWOVBGtcUncuPgRSBdPFEKNsYSsyOWdQ6Hog4LockFqTdjF02InEGg+NLi4=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=eUMbjStWxYZWcnT32Gy1DF266UA=; b=GsAD1jI5TI6
	VHiy6lGVjsEo8J39sJN5pxuwJKjXkbAS266cYTA+5HMGRLLR5gz+rL9A3eaNc67u
	s6gShkYMKuSyO6PCmLri6N/Zh/y+ALZZCeZZYZGM+s1wgV4/7r9Nb6kFjKKWk1SN
	B/jmzdAhf7GJ4vYQeLaTZFsQNiZDDiiY=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a18.g.dreamhost.com (Postfix) with ESMTPSA id D903A25006B; 
	Fri,  9 Dec 2011 12:21:30 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: bfebf49b3eb63eb0975115db4d340a893c042268
Message-Id: <bfebf49b3eb63eb09751.1323462152@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1323462147@xdev.gridcentric.ca>
References: <patchbomb.1323462147@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Fri, 09 Dec 2011 15:22:32 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, keir.xen@gmail.com, tim@xen.org, JBeulich@suse.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 5 of 9] x86/mm: Add per-page locking for memory
 sharing, when audits are disabled
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/mm.c             |   74 +----------
 xen/arch/x86/mm/mem_sharing.c |  280 ++++++++++++++++++++++++++++++++++++++---
 xen/arch/x86/mm/mm-locks.h    |   31 ++++-
 xen/include/asm-x86/mm.h      |   28 +++-
 4 files changed, 310 insertions(+), 103 deletions(-)


With the removal of the hash table, all that is needed now is locking
of individual shared pages, as new (gfn,domain) pairs are removed or
added from the list of mappings.

We recycle PGT_locked and use it to lock individual pages. We ensure deadlock
is averted by locking pages in increasing order. We leverage an "external"
order enforcing construct from mm-locks.h to ensure the p2m_lock (needed to
modify gfn entries during sharing) is always taken after page_locks.

The global lock remains for the benefit of the auditing code, and is
thus enabled only as a compile-time option.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r dbfabd1bbfb1 -r bfebf49b3eb6 xen/arch/x86/mm.c
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -1718,7 +1718,7 @@ static int free_l4_table(struct page_inf
 #define free_l4_table(page, preemptible) (-EINVAL)
 #endif
 
-static int page_lock(struct page_info *page)
+int page_lock(struct page_info *page)
 {
     unsigned long x, nx;
 
@@ -1735,7 +1735,7 @@ static int page_lock(struct page_info *p
     return 1;
 }
 
-static void page_unlock(struct page_info *page)
+void page_unlock(struct page_info *page)
 {
     unsigned long x, nx, y = page->u.inuse.type_info;
 
@@ -4299,76 +4299,6 @@ int steal_page(
     return -1;
 }
 
-int page_make_sharable(struct domain *d, 
-                       struct page_info *page, 
-                       int expected_refcnt)
-{
-    spin_lock(&d->page_alloc_lock);
-
-    /* Change page type and count atomically */
-    if ( !get_page_and_type(page, d, PGT_shared_page) )
-    {
-        spin_unlock(&d->page_alloc_lock);
-        return -EINVAL;
-    }
-
-    /* Check it wasn't already sharable and undo if it was */
-    if ( (page->u.inuse.type_info & PGT_count_mask) != 1 )
-    {
-        put_page_and_type(page);
-        spin_unlock(&d->page_alloc_lock);
-        return -EEXIST;
-    }
-
-    /* Check if the ref count is 2. The first from PGC_allocated, and
-     * the second from get_page_and_type at the top of this function */
-    if ( page->count_info != (PGC_allocated | (2 + expected_refcnt)) )
-    {
-        /* Return type count back to zero */
-        put_page_and_type(page);
-        spin_unlock(&d->page_alloc_lock);
-        return -E2BIG;
-    }
-
-    page_set_owner(page, dom_cow);
-    d->tot_pages--;
-    page_list_del(page, &d->page_list);
-    spin_unlock(&d->page_alloc_lock);
-    return 0;
-}
-
-int page_make_private(struct domain *d, struct page_info *page)
-{
-    if ( !get_page(page, dom_cow) )
-        return -EINVAL;
-    
-    spin_lock(&d->page_alloc_lock);
-
-    /* We can only change the type if count is one */
-    if ( (page->u.inuse.type_info & (PGT_type_mask | PGT_count_mask))
-         != (PGT_shared_page | 1) )
-    {
-        put_page(page);
-        spin_unlock(&d->page_alloc_lock);
-        return -EEXIST;
-    }
-
-    /* Drop the final typecount */
-    put_page_and_type(page);
-
-    /* Change the owner */
-    ASSERT(page_get_owner(page) == dom_cow);
-    page_set_owner(page, d);
-
-    d->tot_pages++;
-    page_list_add_tail(page, &d->page_list);
-    spin_unlock(&d->page_alloc_lock);
-
-    put_page(page);
-
-    return 0;
-}
-
 static int __do_update_va_mapping(
     unsigned long va, u64 val64, unsigned long flags, struct domain *pg_owner)
 {
diff -r dbfabd1bbfb1 -r bfebf49b3eb6 xen/arch/x86/mm/mem_sharing.c
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -35,10 +35,29 @@
 
 #include "mm-locks.h"
 
+static shr_handle_t next_handle = 1;
+
+typedef struct pg_lock_data {
+    int mm_unlock_level;
+    unsigned short recurse_count;
+} pg_lock_data_t;
+
+#define DECLARE_PG_LOCK_DATA(name) \
+    pg_lock_data_t  name = { 0, 0 };
+
 #if MEM_SHARING_AUDIT
+
+static mm_lock_t shr_lock;
+
+#define shr_lock()          _shr_lock()
+#define shr_unlock()        _shr_unlock()
+#define shr_locked_by_me()  _shr_locked_by_me()
+
 static int mem_sharing_audit(void);
+
 #define MEM_SHARING_DEBUG(_f, _a...)                                  \
     debugtrace_printk("mem_sharing_debug: %s(): " _f, __func__, ##_a)
+
 static struct list_head shr_audit_list;
 
 static inline void audit_add_list(struct page_info *page)
@@ -50,7 +69,22 @@ static inline void audit_del_list(struct
 {
     list_del(&page->shared_info->entry);
 }
+
+static inline int mem_sharing_page_lock(struct page_info *p, 
+                                        pg_lock_data_t *l)
+{
+    return 1;
+}
+#define mem_sharing_page_unlock(p, l)   ((void)0)
+
+#define get_next_handle()   next_handle++;
 #else
+
+#define shr_lock()          ((void)0)
+#define shr_unlock()        ((void)0)
+/* Only used inside audit code */
+//#define shr_locked_by_me()  ((void)0)
+
 static inline int mem_sharing_audit(void)
 {
     return 0;
@@ -58,6 +92,41 @@ static inline int mem_sharing_audit(void
 
 #define audit_add_list(p)  ((void)0)
 #define audit_del_list(p)  ((void)0)
+
+static inline int mem_sharing_page_lock(struct page_info *pg,
+                                        pg_lock_data_t *pld)
+{
+    int rc;
+    page_sharing_mm_pre_lock();
+    rc = page_lock(pg);
+    if ( rc )
+    {
+        preempt_disable();
+        page_sharing_mm_post_lock(&pld->mm_unlock_level, 
+                                  &pld->recurse_count);
+    }
+    return rc;
+}
+
+static inline void mem_sharing_page_unlock(struct page_info *pg,
+                                           pg_lock_data_t *pld)
+{
+    page_sharing_mm_unlock(pld->mm_unlock_level, 
+                           &pld->recurse_count);
+    preempt_enable();
+    page_unlock(pg);
+}
+
+static inline shr_handle_t get_next_handle(void)
+{
+    /* Get the next handle get_page style */ 
+    uint64_t x, y = next_handle;
+    do {
+        x = y;
+    }
+    while ( (y = cmpxchg(&next_handle, x, x + 1)) != x );
+    return x + 1;
+}
 #endif /* MEM_SHARING_AUDIT */
 
 #define mem_sharing_enabled(d) \
@@ -70,7 +139,6 @@ static inline int mem_sharing_audit(void
 #undef page_to_mfn
 #define page_to_mfn(_pg) _mfn(__page_to_mfn(_pg))
 
-static shr_handle_t next_handle = 1;
 static atomic_t nr_saved_mfns   = ATOMIC_INIT(0); 
 static atomic_t nr_shared_mfns  = ATOMIC_INIT(0);
 
@@ -81,8 +149,6 @@ typedef struct gfn_info
     struct list_head list;
 } gfn_info_t;
 
-static mm_lock_t shr_lock;
-
 /* Returns true if list has only one entry. O(1) complexity. */
 static inline int list_has_one_entry(struct list_head *head)
 {
@@ -436,6 +502,117 @@ int mem_sharing_debug_gref(struct domain
     return mem_sharing_debug_gfn(d, gfn); 
 }
 
+/* Functions that change a page's type and ownership */
+static int page_make_sharable(struct domain *d, 
+                       struct page_info *page, 
+                       int expected_refcnt)
+{
+    spin_lock(&d->page_alloc_lock);
+
+    /* Change page type and count atomically */
+    if ( !get_page_and_type(page, d, PGT_shared_page) )
+    {
+        spin_unlock(&d->page_alloc_lock);
+        return -EINVAL;
+    }
+
+    /* Check it wasn't already sharable and undo if it was */
+    if ( (page->u.inuse.type_info & PGT_count_mask) != 1 )
+    {
+        put_page_and_type(page);
+        spin_unlock(&d->page_alloc_lock);
+        return -EEXIST;
+    }
+
+    /* Check if the ref count is 2. The first from PGC_allocated, and
+     * the second from get_page_and_type at the top of this function */
+    if ( page->count_info != (PGC_allocated | (2 + expected_refcnt)) )
+    {
+        /* Return type count back to zero */
+        put_page_and_type(page);
+        spin_unlock(&d->page_alloc_lock);
+        return -E2BIG;
+    }
+
+    page_set_owner(page, dom_cow);
+    d->tot_pages--;
+    page_list_del(page, &d->page_list);
+    spin_unlock(&d->page_alloc_lock);
+    return 0;
+}
+
+static int page_make_private(struct domain *d, struct page_info *page,
+                             pg_lock_data_t *pld)
+{
+    unsigned long expected_type;
+
+    if ( !get_page(page, dom_cow) )
+        return -EINVAL;
+    
+    spin_lock(&d->page_alloc_lock);
+
+    /* We can only change the type if count is one */
+    /* If we are locking pages individually, then we need to drop
+     * the lock here, while the page is typed. We cannot risk the 
+     * race of page_unlock and then put_page_type. */
+#if MEM_SHARING_AUDIT
+    expected_type = (PGT_shared_page | PGT_validated | 1);
+#else
+    expected_type = (PGT_shared_page | PGT_validated | PGT_locked | 2);
+#endif
+    if ( page->u.inuse.type_info != expected_type )
+    {
+        put_page(page);
+        spin_unlock(&d->page_alloc_lock);
+        return -EEXIST;
+    }
+
+    /* Drop the final typecount */
+    put_page_and_type(page);
+
+#if MEM_SHARING_AUDIT
+    (void)pld;
+#else
+    /* Now that we've dropped the type, we can unlock */
+    mem_sharing_page_unlock(page, pld);
+#endif
+
+    /* Change the owner */
+    ASSERT(page_get_owner(page) == dom_cow);
+    page_set_owner(page, d);
+
+    d->tot_pages++;
+    page_list_add_tail(page, &d->page_list);
+    spin_unlock(&d->page_alloc_lock);
+
+    put_page(page);
+
+    return 0;
+}
+
+static inline struct page_info *__grab_shared_page(mfn_t mfn,
+                                                    pg_lock_data_t *pld)
+{
+    struct page_info *pg = NULL;
+
+    if ( !mfn_valid(mfn) )
+        return NULL;
+    pg = mfn_to_page(mfn);
+
+    /* If the page is not validated we can't lock it, and if it's  
+     * not validated it's obviously not shared. */
+    if ( !mem_sharing_page_lock(pg, pld) )
+        return NULL;
+
+    if ( mem_sharing_lookup(mfn_x(mfn)) == NULL )
+    {
+        mem_sharing_page_unlock(pg, pld);
+        return NULL;
+    }
+
+    return pg;
+}
+
 int mem_sharing_nominate_page(struct domain *d,
                               unsigned long gfn,
                               int expected_refcnt,
@@ -443,9 +620,10 @@ int mem_sharing_nominate_page(struct dom
 {
     p2m_type_t p2mt;
     mfn_t mfn;
-    struct page_info *page;
+    struct page_info *page = NULL; /* gcc... */
     int ret;
     struct gfn_info *gfn_info;
+    DECLARE_PG_LOCK_DATA(pld);
 
     *phandle = 0UL;
 
@@ -458,10 +636,17 @@ int mem_sharing_nominate_page(struct dom
         goto out;
 
     /* Return the handle if the page is already shared */
-    page = mfn_to_page(mfn);
     if ( p2m_is_shared(p2mt) ) {
-        *phandle = page->shared_info->handle;
+        struct page_info *pg = __grab_shared_page(mfn, &pld);
+        if ( !pg )
+        {
+            gdprintk(XENLOG_ERR, "Shared p2m entry gfn %lx, but could not "
+                        "grab page %lx dom %d\n", gfn, mfn_x(mfn), d->domain_id);
+            BUG();
+        }
+        *phandle = pg->shared_info->handle;
         ret = 0;
+        mem_sharing_page_unlock(pg, &pld);
         goto out;
     }
 
@@ -470,16 +655,25 @@ int mem_sharing_nominate_page(struct dom
         goto out;
 
     /* Try to convert the mfn to the sharable type */
+    page = mfn_to_page(mfn);
     ret = page_make_sharable(d, page, expected_refcnt); 
     if ( ret ) 
         goto out;
 
+    /* Now that the page is validated, we can lock it. There is no 
+     * race because we're holding the p2m entry, so no one else 
+     * could be nominating this gfn */
+    ret = -ENOENT;
+    if ( !mem_sharing_page_lock(page, &pld) )
+        goto out;
+
     /* Initialize the shared state */
     ret = -ENOMEM;
     if ( (page->shared_info = 
             xmalloc(struct page_sharing_info)) == NULL )
     {
-        BUG_ON(page_make_private(d, page) != 0);
+        /* Making a page private atomically unlocks it */
+        BUG_ON(page_make_private(d, page, &pld) != 0);
         goto out;
     }
     page->shared_info->pg = page;
@@ -489,14 +683,14 @@ int mem_sharing_nominate_page(struct dom
 #endif
 
     /* Create the handle */
-    page->shared_info->handle = next_handle++;  
+    page->shared_info->handle = get_next_handle();  
 
     /* Create the local gfn info */
     if ( (gfn_info = mem_sharing_gfn_alloc(page, d, gfn)) == NULL )
     {
         xfree(page->shared_info);
         page->shared_info = NULL;
-        BUG_ON(page_make_private(d, page) != 0);
+        BUG_ON(page_make_private(d, page, &pld) != 0);
         goto out;
     }
 
@@ -511,7 +705,7 @@ int mem_sharing_nominate_page(struct dom
         xfree(page->shared_info);
         page->shared_info = NULL;
         /* NOTE: We haven't yet added this to the audit list. */
-        BUG_ON(page_make_private(d, page) != 0);
+        BUG_ON(page_make_private(d, page, &pld) != 0);
         goto out;
     }
 
@@ -520,6 +714,7 @@ int mem_sharing_nominate_page(struct dom
 
     *phandle = page->shared_info->handle;
     audit_add_list(page);
+    mem_sharing_page_unlock(page, &pld);
     ret = 0;
 
 out:
@@ -531,13 +726,14 @@ out:
 int mem_sharing_share_pages(struct domain *sd, unsigned long sgfn, shr_handle_t sh,
                             struct domain *cd, unsigned long cgfn, shr_handle_t ch) 
 {
-    struct page_info *spage, *cpage;
+    struct page_info *spage, *cpage, *firstpg, *secondpg;
     struct list_head *le, *te;
     gfn_info_t *gfn;
     struct domain *d;
     int ret = -EINVAL, single_client_gfn, single_source_gfn;
     mfn_t smfn, cmfn;
     p2m_type_t smfn_type, cmfn_type;
+    DECLARE_PG_LOCK_DATA(pld);
 
     shr_lock();
 
@@ -546,26 +742,53 @@ int mem_sharing_share_pages(struct domai
     smfn = get_gfn(sd, sgfn, &smfn_type);
     cmfn = get_gfn(cd, cgfn, &cmfn_type);
 
-    ret = XEN_DOMCTL_MEM_SHARING_S_HANDLE_INVALID;
-    spage = mem_sharing_lookup(mfn_x(smfn));
-    if ( spage == NULL )
-        goto err_out;
+    /* This tricky business is to avoid two callers deadlocking if 
+     * grabbing pages in opposite client/source order */
+    if ( mfn_x(smfn) < mfn_x(cmfn) )
+    {
+        ret = XEN_DOMCTL_MEM_SHARING_S_HANDLE_INVALID;
+        spage = firstpg = __grab_shared_page(smfn, &pld);
+        if ( spage == NULL )
+            goto err_out;
+
+        ret = XEN_DOMCTL_MEM_SHARING_C_HANDLE_INVALID;
+        cpage = secondpg = __grab_shared_page(cmfn, &pld);
+        if ( cpage == NULL )
+        {
+            mem_sharing_page_unlock(spage, &pld);
+            goto err_out;
+        }
+    } else {
+        ret = XEN_DOMCTL_MEM_SHARING_C_HANDLE_INVALID;
+        cpage = firstpg = __grab_shared_page(cmfn, &pld);
+        if ( cpage == NULL )
+            goto err_out;
+
+        ret = XEN_DOMCTL_MEM_SHARING_S_HANDLE_INVALID;
+        spage = secondpg = __grab_shared_page(smfn, &pld);
+        if ( spage == NULL )
+        {
+            mem_sharing_page_unlock(cpage, &pld);
+            goto err_out;
+        }
+    }
+
     ASSERT(smfn_type == p2m_ram_shared);
-    ret = XEN_DOMCTL_MEM_SHARING_C_HANDLE_INVALID;
-    cpage = mem_sharing_lookup(mfn_x(cmfn));
-    if ( cpage == NULL )
-        goto err_out;
     ASSERT(cmfn_type == p2m_ram_shared);
 
     /* Check that the handles match */
     if ( spage->shared_info->handle != sh )
     {
         ret = XEN_DOMCTL_MEM_SHARING_S_HANDLE_INVALID;
+        mem_sharing_page_unlock(secondpg, &pld);
+        mem_sharing_page_unlock(firstpg, &pld);
         goto err_out;
     }
     if ( cpage->shared_info->handle != ch )
     {
         ret = XEN_DOMCTL_MEM_SHARING_C_HANDLE_INVALID;
+        mem_sharing_page_unlock(secondpg, &pld);
+        mem_sharing_page_unlock(firstpg, &pld);
         goto err_out;
     }
 
@@ -611,6 +834,9 @@ int mem_sharing_share_pages(struct domai
     xfree(cpage->shared_info);
     cpage->shared_info = NULL;
 
+    mem_sharing_page_unlock(secondpg, &pld);
+    mem_sharing_page_unlock(firstpg, &pld);
+
     /* Free the client page */
     if(test_and_clear_bit(_PGC_allocated, &cpage->count_info))
         put_page(cpage);
@@ -636,6 +862,7 @@ int mem_sharing_unshare_page(struct doma
     int last_gfn;
     gfn_info_t *gfn_info = NULL;
     struct list_head *le;
+    DECLARE_PG_LOCK_DATA(pld);
    
     /* This is one of the reasons why we can't enforce ordering
      * between shr_lock and p2m fine-grained locks in mm-lock. 
@@ -651,7 +878,7 @@ int mem_sharing_unshare_page(struct doma
         return 0;
     }
 
-    page = mem_sharing_lookup(mfn_x(mfn));
+    page = __grab_shared_page(mfn, &pld);
     if ( page == NULL )
     {
         gdprintk(XENLOG_ERR, "Domain p2m is shared, but page is not: "
@@ -700,19 +927,21 @@ gfn_found:
      * (possibly freeing the page), and exit early */
     if ( flags & MEM_SHARING_DESTROY_GFN )
     {
-        put_gfn(d, gfn);
-        shr_unlock();
         put_page_and_type(page);
+        mem_sharing_page_unlock(page, &pld);
         if( last_gfn && 
             test_and_clear_bit(_PGC_allocated, &page->count_info)) 
             put_page(page);
+        put_gfn(d, gfn);
+        shr_unlock();
 
         return 0;
     }
  
     if ( last_gfn )
     {
-        BUG_ON(page_make_private(d, page) != 0);
+        /* Making a page private atomically unlocks it */
+        BUG_ON(page_make_private(d, page, &pld) != 0);
         goto private_page_found;
     }
         
@@ -720,6 +949,7 @@ gfn_found:
     page = mem_sharing_alloc_page(d, gfn);
     if ( !page ) 
     {
+        mem_sharing_page_unlock(old_page, &pld);
         put_gfn(d, gfn);
         shr_unlock();
         return -ENOMEM;
@@ -732,6 +962,7 @@ gfn_found:
     unmap_domain_page(t);
 
     BUG_ON(set_shared_p2m_entry(d, gfn, page_to_mfn(page)) == 0);
+    mem_sharing_page_unlock(old_page, &pld);
     put_page_and_type(old_page);
 
 private_page_found:    
@@ -749,6 +980,7 @@ private_page_found:
     /* Now that the gfn<->mfn map is properly established,
      * marking dirty is feasible */
     paging_mark_dirty(d, mfn_x(page_to_mfn(page)));
+    /* We do not need to unlock a private page */
     put_gfn(d, gfn);
     shr_unlock();
     return 0;
@@ -897,8 +1129,8 @@ int mem_sharing_domctl(struct domain *d,
 void __init mem_sharing_init(void)
 {
     printk("Initing memory sharing.\n");
+#if MEM_SHARING_AUDIT
     mm_lock_init(&shr_lock);
-#if MEM_SHARING_AUDIT
     INIT_LIST_HEAD(&shr_audit_list);
 #endif
 }
diff -r dbfabd1bbfb1 -r bfebf49b3eb6 xen/arch/x86/mm/mm-locks.h
--- a/xen/arch/x86/mm/mm-locks.h
+++ b/xen/arch/x86/mm/mm-locks.h
@@ -26,6 +26,8 @@
 #ifndef _MM_LOCKS_H
 #define _MM_LOCKS_H
 
+#include <asm/mem_sharing.h>
+
 /* Per-CPU variable for enforcing the lock ordering */
 DECLARE_PER_CPU(int, mm_lock_level);
 #define __get_lock_level()  (this_cpu(mm_lock_level))
@@ -141,15 +143,38 @@ static inline void mm_enforce_order_unlo
  *                                                                      *
  ************************************************************************/
 
+#if MEM_SHARING_AUDIT
 /* Page-sharing lock (global) 
  *
  * A single global lock that protects the memory-sharing code's
  * hash tables. */
 
 declare_mm_lock(shr)
-#define shr_lock()         mm_lock(shr, &shr_lock)
-#define shr_unlock()       mm_unlock(&shr_lock)
-#define shr_locked_by_me() mm_locked_by_me(&shr_lock)
+#define _shr_lock()         mm_lock(shr, &shr_lock)
+#define _shr_unlock()       mm_unlock(&shr_lock)
+#define _shr_locked_by_me() mm_locked_by_me(&shr_lock)
+
+#else
+
+/* Sharing per page lock
+ *
+ * This is an external lock, not represented by an mm_lock_t. The memory
+ * sharing lock uses it to protect addition and removal of (gfn,domain)
+ * tuples to a shared page. We enforce order here against the p2m lock,
+ * which is taken after the page_lock to change the gfn's p2m entry.
+ *
+ * Note that in sharing audit mode, we use the global page lock above, 
+ * instead.
+ *
+ * The lock is recursive because during share we lock two pages. */
+
+declare_mm_order_constraint(per_page_sharing)
+#define page_sharing_mm_pre_lock()   mm_enforce_order_lock_pre_per_page_sharing()
+#define page_sharing_mm_post_lock(l, r) \
+        mm_enforce_order_lock_post_per_page_sharing((l), (r))
+#define page_sharing_mm_unlock(l, r) mm_enforce_order_unlock((l), (r))
+
+#endif /* MEM_SHARING_AUDIT */
 
 /* Nested P2M lock (per-domain)
  *
diff -r dbfabd1bbfb1 -r bfebf49b3eb6 xen/include/asm-x86/mm.h
--- a/xen/include/asm-x86/mm.h
+++ b/xen/include/asm-x86/mm.h
@@ -337,6 +337,30 @@ int is_iomem_page(unsigned long mfn);
 
 void clear_superpage_mark(struct page_info *page);
 
+/* Per page locks:
+ * page_lock() is used for two purposes: pte serialization, and memory sharing.
+ *
+ * All users of page lock for pte serialization live in mm.c, use it
+ * to lock a page table page during pte updates, do not take other locks within
+ * the critical section delimited by page_lock/unlock, and perform no
+ * nesting. 
+ *
+ * All users of page lock for memory sharing live in mm/mem_sharing.c. Page_lock
+ * is used in memory sharing to protect addition (share) and removal (unshare) 
+ * of (gfn,domain) tupples to a list of gfn's that the shared page is currently 
+ * backing. Nesting may happen when sharing (and locking) two pages -- deadlock 
+ * is avoided by locking pages in increasing order.
+ * Memory sharing may take the p2m_lock within a page_lock/unlock
+ * critical section. We enforce ordering between page_lock and p2m_lock using an
+ * mm-locks.h construct. 
+ *
+ * These two users (pte serialization and memory sharing) do not collide, since
+ * sharing is only supported for hvm guests, which do not perform pv pte updates.
+ * 
+ */
+int page_lock(struct page_info *page);
+void page_unlock(struct page_info *page);
+
 struct domain *page_get_owner_and_reference(struct page_info *page);
 void put_page(struct page_info *page);
 int  get_page(struct page_info *page, struct domain *domain);
@@ -588,10 +612,6 @@ int steal_page(
     struct domain *d, struct page_info *page, unsigned int memflags);
 int donate_page(
     struct domain *d, struct page_info *page, unsigned int memflags);
-int page_make_sharable(struct domain *d, 
-                       struct page_info *page, 
-                       int expected_refcnt);
-int page_make_private(struct domain *d, struct page_info *page);
 
 int map_ldt_shadow_page(unsigned int);
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 20:22:38 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 20:22:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZ6xd-0005lP-B2; Fri, 09 Dec 2011 20:22:25 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RZ6xb-0005iU-2E
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 20:22:23 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-8.tower-21.messagelabs.com!1323462092!7602345!1
X-Originating-IP: [208.97.132.145]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNDUgPT4gMTczNjI=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6505 invoked from network); 9 Dec 2011 20:21:32 -0000
Received: from caiajhbdcbef.dreamhost.com (HELO homiemail-a18.g.dreamhost.com)
	(208.97.132.145) by server-8.tower-21.messagelabs.com with SMTP;
	9 Dec 2011 20:21:32 -0000
Received: from homiemail-a18.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a18.g.dreamhost.com (Postfix) with ESMTP id E9453250069;
	Fri,  9 Dec 2011 12:21:31 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=evZRM0bgp1FlStx++0yfHQl13IDYv0Z8oIF0oug0H510
	oDFyMByxyDYMsR3bLnN6oInysL8vlORn/BYzWytbtxY2v1KyOP98jdY9moYy6cim
	T+bpiWOVBGtcUncuPgRSBdPFEKNsYSsyOWdQ6Hog4LockFqTdjF02InEGg+NLi4=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=eUMbjStWxYZWcnT32Gy1DF266UA=; b=GsAD1jI5TI6
	VHiy6lGVjsEo8J39sJN5pxuwJKjXkbAS266cYTA+5HMGRLLR5gz+rL9A3eaNc67u
	s6gShkYMKuSyO6PCmLri6N/Zh/y+ALZZCeZZYZGM+s1wgV4/7r9Nb6kFjKKWk1SN
	B/jmzdAhf7GJ4vYQeLaTZFsQNiZDDiiY=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a18.g.dreamhost.com (Postfix) with ESMTPSA id D903A25006B; 
	Fri,  9 Dec 2011 12:21:30 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: bfebf49b3eb63eb0975115db4d340a893c042268
Message-Id: <bfebf49b3eb63eb09751.1323462152@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1323462147@xdev.gridcentric.ca>
References: <patchbomb.1323462147@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Fri, 09 Dec 2011 15:22:32 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, keir.xen@gmail.com, tim@xen.org, JBeulich@suse.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 5 of 9] x86/mm: Add per-page locking for memory
 sharing, when audits are disabled
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/mm.c             |   74 +----------
 xen/arch/x86/mm/mem_sharing.c |  280 ++++++++++++++++++++++++++++++++++++++---
 xen/arch/x86/mm/mm-locks.h    |   31 ++++-
 xen/include/asm-x86/mm.h      |   28 +++-
 4 files changed, 310 insertions(+), 103 deletions(-)


With the removal of the hash table, all that is needed now is locking
of individual shared pages, as new (gfn,domain) pairs are removed or
added from the list of mappings.

We recycle PGT_locked and use it to lock individual pages. We ensure deadlock
is averted by locking pages in increasing order. We leverage an "external"
order enforcing construct from mm-locks.h to ensure the p2m_lock (needed to
modify gfn entries during sharing) is always taken after page_locks.

The global lock remains for the benefit of the auditing code, and is
thus enabled only as a compile-time option.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r dbfabd1bbfb1 -r bfebf49b3eb6 xen/arch/x86/mm.c
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -1718,7 +1718,7 @@ static int free_l4_table(struct page_inf
 #define free_l4_table(page, preemptible) (-EINVAL)
 #endif
 
-static int page_lock(struct page_info *page)
+int page_lock(struct page_info *page)
 {
     unsigned long x, nx;
 
@@ -1735,7 +1735,7 @@ static int page_lock(struct page_info *p
     return 1;
 }
 
-static void page_unlock(struct page_info *page)
+void page_unlock(struct page_info *page)
 {
     unsigned long x, nx, y = page->u.inuse.type_info;
 
@@ -4299,76 +4299,6 @@ int steal_page(
     return -1;
 }
 
-int page_make_sharable(struct domain *d, 
-                       struct page_info *page, 
-                       int expected_refcnt)
-{
-    spin_lock(&d->page_alloc_lock);
-
-    /* Change page type and count atomically */
-    if ( !get_page_and_type(page, d, PGT_shared_page) )
-    {
-        spin_unlock(&d->page_alloc_lock);
-        return -EINVAL;
-    }
-
-    /* Check it wasn't already sharable and undo if it was */
-    if ( (page->u.inuse.type_info & PGT_count_mask) != 1 )
-    {
-        put_page_and_type(page);
-        spin_unlock(&d->page_alloc_lock);
-        return -EEXIST;
-    }
-
-    /* Check if the ref count is 2. The first from PGC_allocated, and
-     * the second from get_page_and_type at the top of this function */
-    if ( page->count_info != (PGC_allocated | (2 + expected_refcnt)) )
-    {
-        /* Return type count back to zero */
-        put_page_and_type(page);
-        spin_unlock(&d->page_alloc_lock);
-        return -E2BIG;
-    }
-
-    page_set_owner(page, dom_cow);
-    d->tot_pages--;
-    page_list_del(page, &d->page_list);
-    spin_unlock(&d->page_alloc_lock);
-    return 0;
-}
-
-int page_make_private(struct domain *d, struct page_info *page)
-{
-    if ( !get_page(page, dom_cow) )
-        return -EINVAL;
-    
-    spin_lock(&d->page_alloc_lock);
-
-    /* We can only change the type if count is one */
-    if ( (page->u.inuse.type_info & (PGT_type_mask | PGT_count_mask))
-         != (PGT_shared_page | 1) )
-    {
-        put_page(page);
-        spin_unlock(&d->page_alloc_lock);
-        return -EEXIST;
-    }
-
-    /* Drop the final typecount */
-    put_page_and_type(page);
-
-    /* Change the owner */
-    ASSERT(page_get_owner(page) == dom_cow);
-    page_set_owner(page, d);
-
-    d->tot_pages++;
-    page_list_add_tail(page, &d->page_list);
-    spin_unlock(&d->page_alloc_lock);
-
-    put_page(page);
-
-    return 0;
-}
-
 static int __do_update_va_mapping(
     unsigned long va, u64 val64, unsigned long flags, struct domain *pg_owner)
 {
diff -r dbfabd1bbfb1 -r bfebf49b3eb6 xen/arch/x86/mm/mem_sharing.c
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -35,10 +35,29 @@
 
 #include "mm-locks.h"
 
+static shr_handle_t next_handle = 1;
+
+typedef struct pg_lock_data {
+    int mm_unlock_level;
+    unsigned short recurse_count;
+} pg_lock_data_t;
+
+#define DECLARE_PG_LOCK_DATA(name) \
+    pg_lock_data_t  name = { 0, 0 };
+
 #if MEM_SHARING_AUDIT
+
+static mm_lock_t shr_lock;
+
+#define shr_lock()          _shr_lock()
+#define shr_unlock()        _shr_unlock()
+#define shr_locked_by_me()  _shr_locked_by_me()
+
 static int mem_sharing_audit(void);
+
 #define MEM_SHARING_DEBUG(_f, _a...)                                  \
     debugtrace_printk("mem_sharing_debug: %s(): " _f, __func__, ##_a)
+
 static struct list_head shr_audit_list;
 
 static inline void audit_add_list(struct page_info *page)
@@ -50,7 +69,22 @@ static inline void audit_del_list(struct
 {
     list_del(&page->shared_info->entry);
 }
+
+static inline int mem_sharing_page_lock(struct page_info *p, 
+                                        pg_lock_data_t *l)
+{
+    return 1;
+}
+#define mem_sharing_page_unlock(p, l)   ((void)0)
+
+#define get_next_handle()   next_handle++;
 #else
+
+#define shr_lock()          ((void)0)
+#define shr_unlock()        ((void)0)
+/* Only used inside audit code */
+//#define shr_locked_by_me()  ((void)0)
+
 static inline int mem_sharing_audit(void)
 {
     return 0;
@@ -58,6 +92,41 @@ static inline int mem_sharing_audit(void
 
 #define audit_add_list(p)  ((void)0)
 #define audit_del_list(p)  ((void)0)
+
+static inline int mem_sharing_page_lock(struct page_info *pg,
+                                        pg_lock_data_t *pld)
+{
+    int rc;
+    page_sharing_mm_pre_lock();
+    rc = page_lock(pg);
+    if ( rc )
+    {
+        preempt_disable();
+        page_sharing_mm_post_lock(&pld->mm_unlock_level, 
+                                  &pld->recurse_count);
+    }
+    return rc;
+}
+
+static inline void mem_sharing_page_unlock(struct page_info *pg,
+                                           pg_lock_data_t *pld)
+{
+    page_sharing_mm_unlock(pld->mm_unlock_level, 
+                           &pld->recurse_count);
+    preempt_enable();
+    page_unlock(pg);
+}
+
+static inline shr_handle_t get_next_handle(void)
+{
+    /* Get the next handle get_page style */ 
+    uint64_t x, y = next_handle;
+    do {
+        x = y;
+    }
+    while ( (y = cmpxchg(&next_handle, x, x + 1)) != x );
+    return x + 1;
+}
 #endif /* MEM_SHARING_AUDIT */
 
 #define mem_sharing_enabled(d) \
@@ -70,7 +139,6 @@ static inline int mem_sharing_audit(void
 #undef page_to_mfn
 #define page_to_mfn(_pg) _mfn(__page_to_mfn(_pg))
 
-static shr_handle_t next_handle = 1;
 static atomic_t nr_saved_mfns   = ATOMIC_INIT(0); 
 static atomic_t nr_shared_mfns  = ATOMIC_INIT(0);
 
@@ -81,8 +149,6 @@ typedef struct gfn_info
     struct list_head list;
 } gfn_info_t;
 
-static mm_lock_t shr_lock;
-
 /* Returns true if list has only one entry. O(1) complexity. */
 static inline int list_has_one_entry(struct list_head *head)
 {
@@ -436,6 +502,117 @@ int mem_sharing_debug_gref(struct domain
     return mem_sharing_debug_gfn(d, gfn); 
 }
 
+/* Functions that change a page's type and ownership */
+static int page_make_sharable(struct domain *d, 
+                       struct page_info *page, 
+                       int expected_refcnt)
+{
+    spin_lock(&d->page_alloc_lock);
+
+    /* Change page type and count atomically */
+    if ( !get_page_and_type(page, d, PGT_shared_page) )
+    {
+        spin_unlock(&d->page_alloc_lock);
+        return -EINVAL;
+    }
+
+    /* Check it wasn't already sharable and undo if it was */
+    if ( (page->u.inuse.type_info & PGT_count_mask) != 1 )
+    {
+        put_page_and_type(page);
+        spin_unlock(&d->page_alloc_lock);
+        return -EEXIST;
+    }
+
+    /* Check if the ref count is 2. The first from PGC_allocated, and
+     * the second from get_page_and_type at the top of this function */
+    if ( page->count_info != (PGC_allocated | (2 + expected_refcnt)) )
+    {
+        /* Return type count back to zero */
+        put_page_and_type(page);
+        spin_unlock(&d->page_alloc_lock);
+        return -E2BIG;
+    }
+
+    page_set_owner(page, dom_cow);
+    d->tot_pages--;
+    page_list_del(page, &d->page_list);
+    spin_unlock(&d->page_alloc_lock);
+    return 0;
+}
+
+static int page_make_private(struct domain *d, struct page_info *page,
+                             pg_lock_data_t *pld)
+{
+    unsigned long expected_type;
+
+    if ( !get_page(page, dom_cow) )
+        return -EINVAL;
+    
+    spin_lock(&d->page_alloc_lock);
+
+    /* We can only change the type if count is one */
+    /* If we are locking pages individually, then we need to drop
+     * the lock here, while the page is typed. We cannot risk the 
+     * race of page_unlock and then put_page_type. */
+#if MEM_SHARING_AUDIT
+    expected_type = (PGT_shared_page | PGT_validated | 1);
+#else
+    expected_type = (PGT_shared_page | PGT_validated | PGT_locked | 2);
+#endif
+    if ( page->u.inuse.type_info != expected_type )
+    {
+        put_page(page);
+        spin_unlock(&d->page_alloc_lock);
+        return -EEXIST;
+    }
+
+    /* Drop the final typecount */
+    put_page_and_type(page);
+
+#if MEM_SHARING_AUDIT
+    (void)pld;
+#else
+    /* Now that we've dropped the type, we can unlock */
+    mem_sharing_page_unlock(page, pld);
+#endif
+
+    /* Change the owner */
+    ASSERT(page_get_owner(page) == dom_cow);
+    page_set_owner(page, d);
+
+    d->tot_pages++;
+    page_list_add_tail(page, &d->page_list);
+    spin_unlock(&d->page_alloc_lock);
+
+    put_page(page);
+
+    return 0;
+}
+
+static inline struct page_info *__grab_shared_page(mfn_t mfn,
+                                                    pg_lock_data_t *pld)
+{
+    struct page_info *pg = NULL;
+
+    if ( !mfn_valid(mfn) )
+        return NULL;
+    pg = mfn_to_page(mfn);
+
+    /* If the page is not validated we can't lock it, and if it's  
+     * not validated it's obviously not shared. */
+    if ( !mem_sharing_page_lock(pg, pld) )
+        return NULL;
+
+    if ( mem_sharing_lookup(mfn_x(mfn)) == NULL )
+    {
+        mem_sharing_page_unlock(pg, pld);
+        return NULL;
+    }
+
+    return pg;
+}
+
 int mem_sharing_nominate_page(struct domain *d,
                               unsigned long gfn,
                               int expected_refcnt,
@@ -443,9 +620,10 @@ int mem_sharing_nominate_page(struct dom
 {
     p2m_type_t p2mt;
     mfn_t mfn;
-    struct page_info *page;
+    struct page_info *page = NULL; /* gcc... */
     int ret;
     struct gfn_info *gfn_info;
+    DECLARE_PG_LOCK_DATA(pld);
 
     *phandle = 0UL;
 
@@ -458,10 +636,17 @@ int mem_sharing_nominate_page(struct dom
         goto out;
 
     /* Return the handle if the page is already shared */
-    page = mfn_to_page(mfn);
     if ( p2m_is_shared(p2mt) ) {
-        *phandle = page->shared_info->handle;
+        struct page_info *pg = __grab_shared_page(mfn, &pld);
+        if ( !pg )
+        {
+            gdprintk(XENLOG_ERR, "Shared p2m entry gfn %lx, but could not "
+                        "grab page %lx dom %d\n", gfn, mfn_x(mfn), d->domain_id);
+            BUG();
+        }
+        *phandle = pg->shared_info->handle;
         ret = 0;
+        mem_sharing_page_unlock(pg, &pld);
         goto out;
     }
 
@@ -470,16 +655,25 @@ int mem_sharing_nominate_page(struct dom
         goto out;
 
     /* Try to convert the mfn to the sharable type */
+    page = mfn_to_page(mfn);
     ret = page_make_sharable(d, page, expected_refcnt); 
     if ( ret ) 
         goto out;
 
+    /* Now that the page is validated, we can lock it. There is no 
+     * race because we're holding the p2m entry, so no one else 
+     * could be nominating this gfn */
+    ret = -ENOENT;
+    if ( !mem_sharing_page_lock(page, &pld) )
+        goto out;
+
     /* Initialize the shared state */
     ret = -ENOMEM;
     if ( (page->shared_info = 
             xmalloc(struct page_sharing_info)) == NULL )
     {
-        BUG_ON(page_make_private(d, page) != 0);
+        /* Making a page private atomically unlocks it */
+        BUG_ON(page_make_private(d, page, &pld) != 0);
         goto out;
     }
     page->shared_info->pg = page;
@@ -489,14 +683,14 @@ int mem_sharing_nominate_page(struct dom
 #endif
 
     /* Create the handle */
-    page->shared_info->handle = next_handle++;  
+    page->shared_info->handle = get_next_handle();  
 
     /* Create the local gfn info */
     if ( (gfn_info = mem_sharing_gfn_alloc(page, d, gfn)) == NULL )
     {
         xfree(page->shared_info);
         page->shared_info = NULL;
-        BUG_ON(page_make_private(d, page) != 0);
+        BUG_ON(page_make_private(d, page, &pld) != 0);
         goto out;
     }
 
@@ -511,7 +705,7 @@ int mem_sharing_nominate_page(struct dom
         xfree(page->shared_info);
         page->shared_info = NULL;
         /* NOTE: We haven't yet added this to the audit list. */
-        BUG_ON(page_make_private(d, page) != 0);
+        BUG_ON(page_make_private(d, page, &pld) != 0);
         goto out;
     }
 
@@ -520,6 +714,7 @@ int mem_sharing_nominate_page(struct dom
 
     *phandle = page->shared_info->handle;
     audit_add_list(page);
+    mem_sharing_page_unlock(page, &pld);
     ret = 0;
 
 out:
@@ -531,13 +726,14 @@ out:
 int mem_sharing_share_pages(struct domain *sd, unsigned long sgfn, shr_handle_t sh,
                             struct domain *cd, unsigned long cgfn, shr_handle_t ch) 
 {
-    struct page_info *spage, *cpage;
+    struct page_info *spage, *cpage, *firstpg, *secondpg;
     struct list_head *le, *te;
     gfn_info_t *gfn;
     struct domain *d;
     int ret = -EINVAL, single_client_gfn, single_source_gfn;
     mfn_t smfn, cmfn;
     p2m_type_t smfn_type, cmfn_type;
+    DECLARE_PG_LOCK_DATA(pld);
 
     shr_lock();
 
@@ -546,26 +742,53 @@ int mem_sharing_share_pages(struct domai
     smfn = get_gfn(sd, sgfn, &smfn_type);
     cmfn = get_gfn(cd, cgfn, &cmfn_type);
 
-    ret = XEN_DOMCTL_MEM_SHARING_S_HANDLE_INVALID;
-    spage = mem_sharing_lookup(mfn_x(smfn));
-    if ( spage == NULL )
-        goto err_out;
+    /* This tricky business is to avoid two callers deadlocking if 
+     * grabbing pages in opposite client/source order */
+    if ( mfn_x(smfn) < mfn_x(cmfn) )
+    {
+        ret = XEN_DOMCTL_MEM_SHARING_S_HANDLE_INVALID;
+        spage = firstpg = __grab_shared_page(smfn, &pld);
+        if ( spage == NULL )
+            goto err_out;
+
+        ret = XEN_DOMCTL_MEM_SHARING_C_HANDLE_INVALID;
+        cpage = secondpg = __grab_shared_page(cmfn, &pld);
+        if ( cpage == NULL )
+        {
+            mem_sharing_page_unlock(spage, &pld);
+            goto err_out;
+        }
+    } else {
+        ret = XEN_DOMCTL_MEM_SHARING_C_HANDLE_INVALID;
+        cpage = firstpg = __grab_shared_page(cmfn, &pld);
+        if ( cpage == NULL )
+            goto err_out;
+
+        ret = XEN_DOMCTL_MEM_SHARING_S_HANDLE_INVALID;
+        spage = secondpg = __grab_shared_page(smfn, &pld);
+        if ( spage == NULL )
+        {
+            mem_sharing_page_unlock(cpage, &pld);
+            goto err_out;
+        }
+    }
+
     ASSERT(smfn_type == p2m_ram_shared);
-    ret = XEN_DOMCTL_MEM_SHARING_C_HANDLE_INVALID;
-    cpage = mem_sharing_lookup(mfn_x(cmfn));
-    if ( cpage == NULL )
-        goto err_out;
     ASSERT(cmfn_type == p2m_ram_shared);
 
     /* Check that the handles match */
     if ( spage->shared_info->handle != sh )
     {
         ret = XEN_DOMCTL_MEM_SHARING_S_HANDLE_INVALID;
+        mem_sharing_page_unlock(secondpg, &pld);
+        mem_sharing_page_unlock(firstpg, &pld);
         goto err_out;
     }
     if ( cpage->shared_info->handle != ch )
     {
         ret = XEN_DOMCTL_MEM_SHARING_C_HANDLE_INVALID;
+        mem_sharing_page_unlock(secondpg, &pld);
+        mem_sharing_page_unlock(firstpg, &pld);
         goto err_out;
     }
 
@@ -611,6 +834,9 @@ int mem_sharing_share_pages(struct domai
     xfree(cpage->shared_info);
     cpage->shared_info = NULL;
 
+    mem_sharing_page_unlock(secondpg, &pld);
+    mem_sharing_page_unlock(firstpg, &pld);
+
     /* Free the client page */
     if(test_and_clear_bit(_PGC_allocated, &cpage->count_info))
         put_page(cpage);
@@ -636,6 +862,7 @@ int mem_sharing_unshare_page(struct doma
     int last_gfn;
     gfn_info_t *gfn_info = NULL;
     struct list_head *le;
+    DECLARE_PG_LOCK_DATA(pld);
    
     /* This is one of the reasons why we can't enforce ordering
      * between shr_lock and p2m fine-grained locks in mm-lock. 
@@ -651,7 +878,7 @@ int mem_sharing_unshare_page(struct doma
         return 0;
     }
 
-    page = mem_sharing_lookup(mfn_x(mfn));
+    page = __grab_shared_page(mfn, &pld);
     if ( page == NULL )
     {
         gdprintk(XENLOG_ERR, "Domain p2m is shared, but page is not: "
@@ -700,19 +927,21 @@ gfn_found:
      * (possibly freeing the page), and exit early */
     if ( flags & MEM_SHARING_DESTROY_GFN )
     {
-        put_gfn(d, gfn);
-        shr_unlock();
         put_page_and_type(page);
+        mem_sharing_page_unlock(page, &pld);
         if( last_gfn && 
             test_and_clear_bit(_PGC_allocated, &page->count_info)) 
             put_page(page);
+        put_gfn(d, gfn);
+        shr_unlock();
 
         return 0;
     }
  
     if ( last_gfn )
     {
-        BUG_ON(page_make_private(d, page) != 0);
+        /* Making a page private atomically unlocks it */
+        BUG_ON(page_make_private(d, page, &pld) != 0);
         goto private_page_found;
     }
         
@@ -720,6 +949,7 @@ gfn_found:
     page = mem_sharing_alloc_page(d, gfn);
     if ( !page ) 
     {
+        mem_sharing_page_unlock(old_page, &pld);
         put_gfn(d, gfn);
         shr_unlock();
         return -ENOMEM;
@@ -732,6 +962,7 @@ gfn_found:
     unmap_domain_page(t);
 
     BUG_ON(set_shared_p2m_entry(d, gfn, page_to_mfn(page)) == 0);
+    mem_sharing_page_unlock(old_page, &pld);
     put_page_and_type(old_page);
 
 private_page_found:    
@@ -749,6 +980,7 @@ private_page_found:
     /* Now that the gfn<->mfn map is properly established,
      * marking dirty is feasible */
     paging_mark_dirty(d, mfn_x(page_to_mfn(page)));
+    /* We do not need to unlock a private page */
     put_gfn(d, gfn);
     shr_unlock();
     return 0;
@@ -897,8 +1129,8 @@ int mem_sharing_domctl(struct domain *d,
 void __init mem_sharing_init(void)
 {
     printk("Initing memory sharing.\n");
+#if MEM_SHARING_AUDIT
     mm_lock_init(&shr_lock);
-#if MEM_SHARING_AUDIT
     INIT_LIST_HEAD(&shr_audit_list);
 #endif
 }
diff -r dbfabd1bbfb1 -r bfebf49b3eb6 xen/arch/x86/mm/mm-locks.h
--- a/xen/arch/x86/mm/mm-locks.h
+++ b/xen/arch/x86/mm/mm-locks.h
@@ -26,6 +26,8 @@
 #ifndef _MM_LOCKS_H
 #define _MM_LOCKS_H
 
+#include <asm/mem_sharing.h>
+
 /* Per-CPU variable for enforcing the lock ordering */
 DECLARE_PER_CPU(int, mm_lock_level);
 #define __get_lock_level()  (this_cpu(mm_lock_level))
@@ -141,15 +143,38 @@ static inline void mm_enforce_order_unlo
  *                                                                      *
  ************************************************************************/
 
+#if MEM_SHARING_AUDIT
 /* Page-sharing lock (global) 
  *
  * A single global lock that protects the memory-sharing code's
  * hash tables. */
 
 declare_mm_lock(shr)
-#define shr_lock()         mm_lock(shr, &shr_lock)
-#define shr_unlock()       mm_unlock(&shr_lock)
-#define shr_locked_by_me() mm_locked_by_me(&shr_lock)
+#define _shr_lock()         mm_lock(shr, &shr_lock)
+#define _shr_unlock()       mm_unlock(&shr_lock)
+#define _shr_locked_by_me() mm_locked_by_me(&shr_lock)
+
+#else
+
+/* Sharing per page lock
+ *
+ * This is an external lock, not represented by an mm_lock_t. The memory
+ * sharing lock uses it to protect addition and removal of (gfn,domain)
+ * tuples to a shared page. We enforce order here against the p2m lock,
+ * which is taken after the page_lock to change the gfn's p2m entry.
+ *
+ * Note that in sharing audit mode, we use the global page lock above, 
+ * instead.
+ *
+ * The lock is recursive because during share we lock two pages. */
+
+declare_mm_order_constraint(per_page_sharing)
+#define page_sharing_mm_pre_lock()   mm_enforce_order_lock_pre_per_page_sharing()
+#define page_sharing_mm_post_lock(l, r) \
+        mm_enforce_order_lock_post_per_page_sharing((l), (r))
+#define page_sharing_mm_unlock(l, r) mm_enforce_order_unlock((l), (r))
+
+#endif /* MEM_SHARING_AUDIT */
 
 /* Nested P2M lock (per-domain)
  *
diff -r dbfabd1bbfb1 -r bfebf49b3eb6 xen/include/asm-x86/mm.h
--- a/xen/include/asm-x86/mm.h
+++ b/xen/include/asm-x86/mm.h
@@ -337,6 +337,30 @@ int is_iomem_page(unsigned long mfn);
 
 void clear_superpage_mark(struct page_info *page);
 
+/* Per page locks:
+ * page_lock() is used for two purposes: pte serialization, and memory sharing.
+ *
+ * All users of page lock for pte serialization live in mm.c, use it
+ * to lock a page table page during pte updates, do not take other locks within
+ * the critical section delimited by page_lock/unlock, and perform no
+ * nesting. 
+ *
+ * All users of page lock for memory sharing live in mm/mem_sharing.c. Page_lock
+ * is used in memory sharing to protect addition (share) and removal (unshare) 
+ * of (gfn,domain) tupples to a list of gfn's that the shared page is currently 
+ * backing. Nesting may happen when sharing (and locking) two pages -- deadlock 
+ * is avoided by locking pages in increasing order.
+ * Memory sharing may take the p2m_lock within a page_lock/unlock
+ * critical section. We enforce ordering between page_lock and p2m_lock using an
+ * mm-locks.h construct. 
+ *
+ * These two users (pte serialization and memory sharing) do not collide, since
+ * sharing is only supported for hvm guests, which do not perform pv pte updates.
+ * 
+ */
+int page_lock(struct page_info *page);
+void page_unlock(struct page_info *page);
+
 struct domain *page_get_owner_and_reference(struct page_info *page);
 void put_page(struct page_info *page);
 int  get_page(struct page_info *page, struct domain *domain);
@@ -588,10 +612,6 @@ int steal_page(
     struct domain *d, struct page_info *page, unsigned int memflags);
 int donate_page(
     struct domain *d, struct page_info *page, unsigned int memflags);
-int page_make_sharable(struct domain *d, 
-                       struct page_info *page, 
-                       int expected_refcnt);
-int page_make_private(struct domain *d, struct page_info *page);
 
 int map_ldt_shadow_page(unsigned int);
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 20:22:38 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 20:22:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZ6xg-0005oF-On; Fri, 09 Dec 2011 20:22:28 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RZ6xf-0005jU-Fv
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 20:22:27 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-4.tower-182.messagelabs.com!1323462097!6622073!1
X-Originating-IP: [208.97.132.177]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNzcgPT4gMTQyMDg=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29644 invoked from network); 9 Dec 2011 20:21:37 -0000
Received: from caiajhbdcbhh.dreamhost.com (HELO homiemail-a18.g.dreamhost.com)
	(208.97.132.177) by server-4.tower-182.messagelabs.com with SMTP;
	9 Dec 2011 20:21:37 -0000
Received: from homiemail-a18.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a18.g.dreamhost.com (Postfix) with ESMTP id BDDDF250069;
	Fri,  9 Dec 2011 12:21:36 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=vYEsrvxgc2I2Vdn55xvWSKxIJCzEyFW5DWLd9iG1kVrr
	yv0zBwJgidwVNGHEzn6yYXOvjH+UOnFHmsN5E97iBOTxCcDCOzqEHddue8WI+tU8
	r5Kprwp3Q/5hHnzwVzIckitfOW4u21RrOjBwg//4BlxSqWWTtHo3NiI3Fc6c9h8=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=oRVpRkzEQ52ZZmp6jm+AhkzeTIE=; b=T04tn6yi4h9
	puvYHwR7C6Y8qfk9MQkdDcfETkRR1itV9uqL7LdbPa9jidCd2eWOvU04RDmx0c8h
	2XnkygzVo91uF4DhZTAwHiQ+mj17FaqfBqlU7f/CdmeXrBin2p4AAsFzavI7N2bV
	XFdTXrXEoUNARvBW7wb3OB+YGuAamb1E=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a18.g.dreamhost.com (Postfix) with ESMTPSA id 8E4C625006B; 
	Fri,  9 Dec 2011 12:21:35 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 835be7c121b7ace74c5c05d0cf268882f53ca165
Message-Id: <835be7c121b7ace74c5c.1323462156@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1323462147@xdev.gridcentric.ca>
References: <patchbomb.1323462147@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Fri, 09 Dec 2011 15:22:36 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, keir.xen@gmail.com, tim@xen.org, JBeulich@suse.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 9 of 9] x86/mm: use RCU in mem sharing audit
 list, eliminate global lock completely
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/mm/mem_sharing.c     |  83 +++++++++++++++-----------------------
 xen/arch/x86/mm/mm-locks.h        |  18 --------
 xen/include/asm-x86/mem_sharing.h |   3 +-
 3 files changed, 35 insertions(+), 69 deletions(-)


Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 5b9b36648e43 -r 835be7c121b7 xen/arch/x86/mm/mem_sharing.c
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -32,6 +32,7 @@
 #include <asm/p2m.h>
 #include <asm/mem_event.h>
 #include <asm/atomic.h>
+#include <xen/rcupdate.h>
 
 #include "mm-locks.h"
 
@@ -47,44 +48,33 @@ typedef struct pg_lock_data {
 
 #if MEM_SHARING_AUDIT
 
-static mm_lock_t shr_lock;
-
-#define shr_lock()          _shr_lock()
-#define shr_unlock()        _shr_unlock()
-#define shr_locked_by_me()  _shr_locked_by_me()
-
 static int mem_sharing_audit(void);
 
 #define MEM_SHARING_DEBUG(_f, _a...)                                  \
     debugtrace_printk("mem_sharing_debug: %s(): " _f, __func__, ##_a)
 
 static struct list_head shr_audit_list;
+static spinlock_t shr_audit_lock;
+DEFINE_RCU_READ_LOCK(shr_audit_read_lock);
+
+/* RCU delayed free of audit list entry */
+static void _free_pg_shared_info(struct rcu_head *head)
+{
+    xfree(container_of(head, struct page_sharing_info, rcu_head));
+}
 
 static inline void audit_add_list(struct page_info *page)
 {
-    list_add(&page->shared_info->entry, &shr_audit_list);
+    list_add_rcu(&page->shared_info->entry, &shr_audit_list);
 }
 
 static inline void audit_del_list(struct page_info *page)
 {
-    list_del(&page->shared_info->entry);
+    list_del_rcu(&page->shared_info->entry);
+    call_rcu(&page->shared_info->rcu_head, _free_pg_shared_info);
 }
-
-static inline int mem_sharing_page_lock(struct page_info *p, 
-                                        pg_lock_data_t *l)
-{
-    return 1;
-}
-#define mem_sharing_page_unlock(p, l)   ((void)0)
-
-#define get_next_handle()   next_handle++;
 #else
 
-#define shr_lock()          ((void)0)
-#define shr_unlock()        ((void)0)
-/* Only used inside audit code */
-//#define shr_locked_by_me()  ((void)0)
-
 static inline int mem_sharing_audit(void)
 {
     return 0;
@@ -93,6 +83,8 @@ static inline int mem_sharing_audit(void
 #define audit_add_list(p)  ((void)0)
 #define audit_del_list(p)  ((void)0)
 
+#endif /* MEM_SHARING_AUDIT */
+
 static inline int mem_sharing_page_lock(struct page_info *pg,
                                         pg_lock_data_t *pld)
 {
@@ -127,7 +119,6 @@ static inline shr_handle_t get_next_hand
     while ( (y = cmpxchg(&next_handle, x, x + 1)) != x );
     return x + 1;
 }
-#endif /* MEM_SHARING_AUDIT */
 
 #define mem_sharing_enabled(d) \
     (is_hvm_domain(d) && (d)->arch.hvm_domain.mem_sharing_enabled)
@@ -220,11 +211,13 @@ static int mem_sharing_audit(void)
     unsigned long count_expected;
     unsigned long count_found = 0;
     struct list_head *ae;
+    DECLARE_PG_LOCK_DATA(pld);
 
-    ASSERT(shr_locked_by_me());
     count_expected = atomic_read(&nr_shared_mfns);
 
-    list_for_each(ae, &shr_audit_list)
+    rcu_read_lock(&shr_audit_read_lock);
+
+    list_for_each_rcu(ae, &shr_audit_list)
     {
         struct page_sharing_info *shared_info;
         unsigned long nr_gfns = 0;
@@ -236,6 +229,15 @@ static int mem_sharing_audit(void)
         pg = shared_info->pg;
         mfn = page_to_mfn(pg);
 
+        /* If we can't lock it, it's definitely not a shared page */
+        if ( !mem_sharing_page_lock(pg, &pld) )
+        {
+           MEM_SHARING_DEBUG("mfn %lx in audit list, but cannot be locked (%lx)!\n",
+                              mfn_x(mfn), pg->u.inuse.type_info);
+           errors++;
+           continue;
+        }
+
         /* Check if the MFN has correct type, owner and handle. */ 
         if ( !(pg->u.inuse.type_info & PGT_shared_page) )
         {
@@ -317,8 +319,12 @@ static int mem_sharing_audit(void)
                               (pg->u.inuse.type_info & PGT_count_mask));
             errors++;
         }
+
+        mem_sharing_page_unlock(pg, &pld);
     }
 
+    rcu_read_unlock(&shr_audit_read_lock);
+
     if ( count_found != count_expected )
     {
         MEM_SHARING_DEBUG("Expected %ld shared mfns, found %ld.",
@@ -552,14 +558,10 @@ static int page_make_private(struct doma
     spin_lock(&d->page_alloc_lock);
 
     /* We can only change the type if count is one */
-    /* If we are locking pages individually, then we need to drop
+    /* Because we are locking pages individually, we need to drop
      * the lock here, while the page is typed. We cannot risk the 
      * race of page_unlock and then put_page_type. */
-#if MEM_SHARING_AUDIT
-    expected_type = (PGT_shared_page | PGT_validated | 1);
-#else
     expected_type = (PGT_shared_page | PGT_validated | PGT_locked | 2);
-#endif
     if ( page->u.inuse.type_info != expected_type )
     {
         put_page(page);
@@ -570,12 +572,8 @@ static int page_make_private(struct doma
     /* Drop the final typecount */
     put_page_and_type(page);
 
-#if MEM_SHARING_AUDIT
-    (void)pld;
-#else
     /* Now that we've dropped the type, we can unlock */
     mem_sharing_page_unlock(page, pld);
-#endif
 
     /* Change the owner */
     ASSERT(page_get_owner(page) == dom_cow);
@@ -627,7 +625,6 @@ int mem_sharing_nominate_page(struct dom
 
     *phandle = 0UL;
 
-    shr_lock(); 
     mfn = get_gfn(d, gfn, &p2mt);
 
     /* Check if mfn is valid */
@@ -719,7 +716,6 @@ int mem_sharing_nominate_page(struct dom
 
 out:
     put_gfn(d, gfn);
-    shr_unlock();
     return ret;
 }
 
@@ -735,8 +731,6 @@ int mem_sharing_share_pages(struct domai
     p2m_type_t smfn_type, cmfn_type;
     DECLARE_PG_LOCK_DATA(pld);
 
-    shr_lock();
-
     /* XXX if sd == cd handle potential deadlock by ordering
      * the get_ and put_gfn's */
     smfn = get_gfn(sd, sgfn, &smfn_type);
@@ -831,7 +825,6 @@ int mem_sharing_share_pages(struct domai
 
     /* Clear the rest of the shared state */
     audit_del_list(cpage);
-    xfree(cpage->shared_info);
     cpage->shared_info = NULL;
 
     mem_sharing_page_unlock(secondpg, &pld);
@@ -847,7 +840,6 @@ int mem_sharing_share_pages(struct domai
 err_out:
     put_gfn(cd, cgfn);
     put_gfn(sd, sgfn);
-    shr_unlock();
     return ret;
 }
 
@@ -932,16 +924,11 @@ int mem_sharing_unshare_page(struct doma
     struct list_head *le;
     DECLARE_PG_LOCK_DATA(pld);
    
-    /* This is one of the reasons why we can't enforce ordering
-     * between shr_lock and p2m fine-grained locks in mm-lock. 
-     * Callers may walk in here already holding the lock for this gfn */
-    shr_lock();
     mfn = get_gfn(d, gfn, &p2mt);
     
     /* Has someone already unshared it? */
     if ( !p2m_is_shared(p2mt) ) {
         put_gfn(d, gfn);
-        shr_unlock();
         return 0;
     }
 
@@ -986,7 +973,6 @@ gfn_found:
     } else {
         /* Clean up shared state */
         audit_del_list(page);
-        xfree(page->shared_info);
         page->shared_info = NULL;
     }
 
@@ -1000,7 +986,6 @@ gfn_found:
             test_and_clear_bit(_PGC_allocated, &page->count_info)) 
             put_page(page);
         put_gfn(d, gfn);
-        shr_unlock();
 
         return 0;
     }
@@ -1018,7 +1003,6 @@ gfn_found:
     {
         mem_sharing_page_unlock(old_page, &pld);
         put_gfn(d, gfn);
-        shr_unlock();
         return -ENOMEM;
     }
 
@@ -1049,7 +1033,6 @@ private_page_found:
     paging_mark_dirty(d, mfn_x(page_to_mfn(page)));
     /* We do not need to unlock a private page */
     put_gfn(d, gfn);
-    shr_unlock();
     return 0;
 }
 
@@ -1247,7 +1230,7 @@ void __init mem_sharing_init(void)
 {
     printk("Initing memory sharing.\n");
 #if MEM_SHARING_AUDIT
-    mm_lock_init(&shr_lock);
+    spin_lock_init(&shr_audit_lock);
     INIT_LIST_HEAD(&shr_audit_list);
 #endif
 }
diff -r 5b9b36648e43 -r 835be7c121b7 xen/arch/x86/mm/mm-locks.h
--- a/xen/arch/x86/mm/mm-locks.h
+++ b/xen/arch/x86/mm/mm-locks.h
@@ -143,19 +143,6 @@ static inline void mm_enforce_order_unlo
  *                                                                      *
  ************************************************************************/
 
-#if MEM_SHARING_AUDIT
-/* Page-sharing lock (global) 
- *
- * A single global lock that protects the memory-sharing code's
- * hash tables. */
-
-declare_mm_lock(shr)
-#define _shr_lock()         mm_lock(shr, &shr_lock)
-#define _shr_unlock()       mm_unlock(&shr_lock)
-#define _shr_locked_by_me() mm_locked_by_me(&shr_lock)
-
-#else
-
 /* Sharing per page lock
  *
  * This is an external lock, not represented by an mm_lock_t. The memory
@@ -163,9 +150,6 @@ declare_mm_lock(shr)
  * tuples to a shared page. We enforce order here against the p2m lock,
  * which is taken after the page_lock to change the gfn's p2m entry.
  *
- * Note that in sharing audit mode, we use the global page lock above, 
- * instead.
- *
  * The lock is recursive because during share we lock two pages. */
 
 declare_mm_order_constraint(per_page_sharing)
@@ -174,8 +158,6 @@ declare_mm_order_constraint(per_page_sha
         mm_enforce_order_lock_post_per_page_sharing((l), (r))
 #define page_sharing_mm_unlock(l, r) mm_enforce_order_unlock((l), (r))
 
-#endif /* MEM_SHARING_AUDIT */
-
 /* Nested P2M lock (per-domain)
  *
  * A per-domain lock that protects the mapping from nested-CR3 to 
diff -r 5b9b36648e43 -r 835be7c121b7 xen/include/asm-x86/mem_sharing.h
--- a/xen/include/asm-x86/mem_sharing.h
+++ b/xen/include/asm-x86/mem_sharing.h
@@ -25,7 +25,7 @@
 #include <public/domctl.h>
 
 /* Auditing of memory sharing code? */
-#define MEM_SHARING_AUDIT 0
+#define MEM_SHARING_AUDIT 1
 
 typedef uint64_t shr_handle_t; 
 
@@ -35,6 +35,7 @@ struct page_sharing_info
     shr_handle_t handle;    /* Globally unique version / handle. */
 #if MEM_SHARING_AUDIT
     struct list_head entry; /* List of all shared pages (entry). */
+    struct rcu_head rcu_head; /* List of all shared pages (entry). */
 #endif
     struct list_head gfns;  /* List of domains and gfns for this page (head). */
 };

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 20:22:38 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 20:22:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZ6xg-0005oF-On; Fri, 09 Dec 2011 20:22:28 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RZ6xf-0005jU-Fv
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 20:22:27 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-4.tower-182.messagelabs.com!1323462097!6622073!1
X-Originating-IP: [208.97.132.177]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNzcgPT4gMTQyMDg=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29644 invoked from network); 9 Dec 2011 20:21:37 -0000
Received: from caiajhbdcbhh.dreamhost.com (HELO homiemail-a18.g.dreamhost.com)
	(208.97.132.177) by server-4.tower-182.messagelabs.com with SMTP;
	9 Dec 2011 20:21:37 -0000
Received: from homiemail-a18.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a18.g.dreamhost.com (Postfix) with ESMTP id BDDDF250069;
	Fri,  9 Dec 2011 12:21:36 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=vYEsrvxgc2I2Vdn55xvWSKxIJCzEyFW5DWLd9iG1kVrr
	yv0zBwJgidwVNGHEzn6yYXOvjH+UOnFHmsN5E97iBOTxCcDCOzqEHddue8WI+tU8
	r5Kprwp3Q/5hHnzwVzIckitfOW4u21RrOjBwg//4BlxSqWWTtHo3NiI3Fc6c9h8=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=oRVpRkzEQ52ZZmp6jm+AhkzeTIE=; b=T04tn6yi4h9
	puvYHwR7C6Y8qfk9MQkdDcfETkRR1itV9uqL7LdbPa9jidCd2eWOvU04RDmx0c8h
	2XnkygzVo91uF4DhZTAwHiQ+mj17FaqfBqlU7f/CdmeXrBin2p4AAsFzavI7N2bV
	XFdTXrXEoUNARvBW7wb3OB+YGuAamb1E=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a18.g.dreamhost.com (Postfix) with ESMTPSA id 8E4C625006B; 
	Fri,  9 Dec 2011 12:21:35 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 835be7c121b7ace74c5c05d0cf268882f53ca165
Message-Id: <835be7c121b7ace74c5c.1323462156@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1323462147@xdev.gridcentric.ca>
References: <patchbomb.1323462147@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Fri, 09 Dec 2011 15:22:36 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, keir.xen@gmail.com, tim@xen.org, JBeulich@suse.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 9 of 9] x86/mm: use RCU in mem sharing audit
 list, eliminate global lock completely
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/mm/mem_sharing.c     |  83 +++++++++++++++-----------------------
 xen/arch/x86/mm/mm-locks.h        |  18 --------
 xen/include/asm-x86/mem_sharing.h |   3 +-
 3 files changed, 35 insertions(+), 69 deletions(-)


Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 5b9b36648e43 -r 835be7c121b7 xen/arch/x86/mm/mem_sharing.c
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -32,6 +32,7 @@
 #include <asm/p2m.h>
 #include <asm/mem_event.h>
 #include <asm/atomic.h>
+#include <xen/rcupdate.h>
 
 #include "mm-locks.h"
 
@@ -47,44 +48,33 @@ typedef struct pg_lock_data {
 
 #if MEM_SHARING_AUDIT
 
-static mm_lock_t shr_lock;
-
-#define shr_lock()          _shr_lock()
-#define shr_unlock()        _shr_unlock()
-#define shr_locked_by_me()  _shr_locked_by_me()
-
 static int mem_sharing_audit(void);
 
 #define MEM_SHARING_DEBUG(_f, _a...)                                  \
     debugtrace_printk("mem_sharing_debug: %s(): " _f, __func__, ##_a)
 
 static struct list_head shr_audit_list;
+static spinlock_t shr_audit_lock;
+DEFINE_RCU_READ_LOCK(shr_audit_read_lock);
+
+/* RCU delayed free of audit list entry */
+static void _free_pg_shared_info(struct rcu_head *head)
+{
+    xfree(container_of(head, struct page_sharing_info, rcu_head));
+}
 
 static inline void audit_add_list(struct page_info *page)
 {
-    list_add(&page->shared_info->entry, &shr_audit_list);
+    list_add_rcu(&page->shared_info->entry, &shr_audit_list);
 }
 
 static inline void audit_del_list(struct page_info *page)
 {
-    list_del(&page->shared_info->entry);
+    list_del_rcu(&page->shared_info->entry);
+    call_rcu(&page->shared_info->rcu_head, _free_pg_shared_info);
 }
-
-static inline int mem_sharing_page_lock(struct page_info *p, 
-                                        pg_lock_data_t *l)
-{
-    return 1;
-}
-#define mem_sharing_page_unlock(p, l)   ((void)0)
-
-#define get_next_handle()   next_handle++;
 #else
 
-#define shr_lock()          ((void)0)
-#define shr_unlock()        ((void)0)
-/* Only used inside audit code */
-//#define shr_locked_by_me()  ((void)0)
-
 static inline int mem_sharing_audit(void)
 {
     return 0;
@@ -93,6 +83,8 @@ static inline int mem_sharing_audit(void
 #define audit_add_list(p)  ((void)0)
 #define audit_del_list(p)  ((void)0)
 
+#endif /* MEM_SHARING_AUDIT */
+
 static inline int mem_sharing_page_lock(struct page_info *pg,
                                         pg_lock_data_t *pld)
 {
@@ -127,7 +119,6 @@ static inline shr_handle_t get_next_hand
     while ( (y = cmpxchg(&next_handle, x, x + 1)) != x );
     return x + 1;
 }
-#endif /* MEM_SHARING_AUDIT */
 
 #define mem_sharing_enabled(d) \
     (is_hvm_domain(d) && (d)->arch.hvm_domain.mem_sharing_enabled)
@@ -220,11 +211,13 @@ static int mem_sharing_audit(void)
     unsigned long count_expected;
     unsigned long count_found = 0;
     struct list_head *ae;
+    DECLARE_PG_LOCK_DATA(pld);
 
-    ASSERT(shr_locked_by_me());
     count_expected = atomic_read(&nr_shared_mfns);
 
-    list_for_each(ae, &shr_audit_list)
+    rcu_read_lock(&shr_audit_read_lock);
+
+    list_for_each_rcu(ae, &shr_audit_list)
     {
         struct page_sharing_info *shared_info;
         unsigned long nr_gfns = 0;
@@ -236,6 +229,15 @@ static int mem_sharing_audit(void)
         pg = shared_info->pg;
         mfn = page_to_mfn(pg);
 
+        /* If we can't lock it, it's definitely not a shared page */
+        if ( !mem_sharing_page_lock(pg, &pld) )
+        {
+           MEM_SHARING_DEBUG("mfn %lx in audit list, but cannot be locked (%lx)!\n",
+                              mfn_x(mfn), pg->u.inuse.type_info);
+           errors++;
+           continue;
+        }
+
         /* Check if the MFN has correct type, owner and handle. */ 
         if ( !(pg->u.inuse.type_info & PGT_shared_page) )
         {
@@ -317,8 +319,12 @@ static int mem_sharing_audit(void)
                               (pg->u.inuse.type_info & PGT_count_mask));
             errors++;
         }
+
+        mem_sharing_page_unlock(pg, &pld);
     }
 
+    rcu_read_unlock(&shr_audit_read_lock);
+
     if ( count_found != count_expected )
     {
         MEM_SHARING_DEBUG("Expected %ld shared mfns, found %ld.",
@@ -552,14 +558,10 @@ static int page_make_private(struct doma
     spin_lock(&d->page_alloc_lock);
 
     /* We can only change the type if count is one */
-    /* If we are locking pages individually, then we need to drop
+    /* Because we are locking pages individually, we need to drop
      * the lock here, while the page is typed. We cannot risk the 
      * race of page_unlock and then put_page_type. */
-#if MEM_SHARING_AUDIT
-    expected_type = (PGT_shared_page | PGT_validated | 1);
-#else
     expected_type = (PGT_shared_page | PGT_validated | PGT_locked | 2);
-#endif
     if ( page->u.inuse.type_info != expected_type )
     {
         put_page(page);
@@ -570,12 +572,8 @@ static int page_make_private(struct doma
     /* Drop the final typecount */
     put_page_and_type(page);
 
-#if MEM_SHARING_AUDIT
-    (void)pld;
-#else
     /* Now that we've dropped the type, we can unlock */
     mem_sharing_page_unlock(page, pld);
-#endif
 
     /* Change the owner */
     ASSERT(page_get_owner(page) == dom_cow);
@@ -627,7 +625,6 @@ int mem_sharing_nominate_page(struct dom
 
     *phandle = 0UL;
 
-    shr_lock(); 
     mfn = get_gfn(d, gfn, &p2mt);
 
     /* Check if mfn is valid */
@@ -719,7 +716,6 @@ int mem_sharing_nominate_page(struct dom
 
 out:
     put_gfn(d, gfn);
-    shr_unlock();
     return ret;
 }
 
@@ -735,8 +731,6 @@ int mem_sharing_share_pages(struct domai
     p2m_type_t smfn_type, cmfn_type;
     DECLARE_PG_LOCK_DATA(pld);
 
-    shr_lock();
-
     /* XXX if sd == cd handle potential deadlock by ordering
      * the get_ and put_gfn's */
     smfn = get_gfn(sd, sgfn, &smfn_type);
@@ -831,7 +825,6 @@ int mem_sharing_share_pages(struct domai
 
     /* Clear the rest of the shared state */
     audit_del_list(cpage);
-    xfree(cpage->shared_info);
     cpage->shared_info = NULL;
 
     mem_sharing_page_unlock(secondpg, &pld);
@@ -847,7 +840,6 @@ int mem_sharing_share_pages(struct domai
 err_out:
     put_gfn(cd, cgfn);
     put_gfn(sd, sgfn);
-    shr_unlock();
     return ret;
 }
 
@@ -932,16 +924,11 @@ int mem_sharing_unshare_page(struct doma
     struct list_head *le;
     DECLARE_PG_LOCK_DATA(pld);
    
-    /* This is one of the reasons why we can't enforce ordering
-     * between shr_lock and p2m fine-grained locks in mm-lock. 
-     * Callers may walk in here already holding the lock for this gfn */
-    shr_lock();
     mfn = get_gfn(d, gfn, &p2mt);
     
     /* Has someone already unshared it? */
     if ( !p2m_is_shared(p2mt) ) {
         put_gfn(d, gfn);
-        shr_unlock();
         return 0;
     }
 
@@ -986,7 +973,6 @@ gfn_found:
     } else {
         /* Clean up shared state */
         audit_del_list(page);
-        xfree(page->shared_info);
         page->shared_info = NULL;
     }
 
@@ -1000,7 +986,6 @@ gfn_found:
             test_and_clear_bit(_PGC_allocated, &page->count_info)) 
             put_page(page);
         put_gfn(d, gfn);
-        shr_unlock();
 
         return 0;
     }
@@ -1018,7 +1003,6 @@ gfn_found:
     {
         mem_sharing_page_unlock(old_page, &pld);
         put_gfn(d, gfn);
-        shr_unlock();
         return -ENOMEM;
     }
 
@@ -1049,7 +1033,6 @@ private_page_found:
     paging_mark_dirty(d, mfn_x(page_to_mfn(page)));
     /* We do not need to unlock a private page */
     put_gfn(d, gfn);
-    shr_unlock();
     return 0;
 }
 
@@ -1247,7 +1230,7 @@ void __init mem_sharing_init(void)
 {
     printk("Initing memory sharing.\n");
 #if MEM_SHARING_AUDIT
-    mm_lock_init(&shr_lock);
+    spin_lock_init(&shr_audit_lock);
     INIT_LIST_HEAD(&shr_audit_list);
 #endif
 }
diff -r 5b9b36648e43 -r 835be7c121b7 xen/arch/x86/mm/mm-locks.h
--- a/xen/arch/x86/mm/mm-locks.h
+++ b/xen/arch/x86/mm/mm-locks.h
@@ -143,19 +143,6 @@ static inline void mm_enforce_order_unlo
  *                                                                      *
  ************************************************************************/
 
-#if MEM_SHARING_AUDIT
-/* Page-sharing lock (global) 
- *
- * A single global lock that protects the memory-sharing code's
- * hash tables. */
-
-declare_mm_lock(shr)
-#define _shr_lock()         mm_lock(shr, &shr_lock)
-#define _shr_unlock()       mm_unlock(&shr_lock)
-#define _shr_locked_by_me() mm_locked_by_me(&shr_lock)
-
-#else
-
 /* Sharing per page lock
  *
  * This is an external lock, not represented by an mm_lock_t. The memory
@@ -163,9 +150,6 @@ declare_mm_lock(shr)
  * tuples to a shared page. We enforce order here against the p2m lock,
  * which is taken after the page_lock to change the gfn's p2m entry.
  *
- * Note that in sharing audit mode, we use the global page lock above, 
- * instead.
- *
  * The lock is recursive because during share we lock two pages. */
 
 declare_mm_order_constraint(per_page_sharing)
@@ -174,8 +158,6 @@ declare_mm_order_constraint(per_page_sha
         mm_enforce_order_lock_post_per_page_sharing((l), (r))
 #define page_sharing_mm_unlock(l, r) mm_enforce_order_unlock((l), (r))
 
-#endif /* MEM_SHARING_AUDIT */
-
 /* Nested P2M lock (per-domain)
  *
  * A per-domain lock that protects the mapping from nested-CR3 to 
diff -r 5b9b36648e43 -r 835be7c121b7 xen/include/asm-x86/mem_sharing.h
--- a/xen/include/asm-x86/mem_sharing.h
+++ b/xen/include/asm-x86/mem_sharing.h
@@ -25,7 +25,7 @@
 #include <public/domctl.h>
 
 /* Auditing of memory sharing code? */
-#define MEM_SHARING_AUDIT 0
+#define MEM_SHARING_AUDIT 1
 
 typedef uint64_t shr_handle_t; 
 
@@ -35,6 +35,7 @@ struct page_sharing_info
     shr_handle_t handle;    /* Globally unique version / handle. */
 #if MEM_SHARING_AUDIT
     struct list_head entry; /* List of all shared pages (entry). */
+    struct rcu_head rcu_head; /* List of all shared pages (entry). */
 #endif
     struct list_head gfns;  /* List of domains and gfns for this page (head). */
 };

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 20:22:38 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 20:22:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZ6xe-0005mP-BI; Fri, 09 Dec 2011 20:22:26 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RZ6xd-0005ix-LZ
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 20:22:25 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-9.tower-174.messagelabs.com!1323462093!4963750!2
X-Originating-IP: [208.97.132.74]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi43NCA9PiAxNDk1Mw==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19905 invoked from network); 9 Dec 2011 20:21:35 -0000
Received: from caiajhbdcahe.dreamhost.com (HELO homiemail-a18.g.dreamhost.com)
	(208.97.132.74) by server-9.tower-174.messagelabs.com with SMTP;
	9 Dec 2011 20:21:35 -0000
Received: from homiemail-a18.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a18.g.dreamhost.com (Postfix) with ESMTP id 5CE58250075;
	Fri,  9 Dec 2011 12:21:35 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=G37pjOOCwNNfbOgvG+XvUMq51ySyHE609ndpceCy54xB
	yoinG6/ft8fRGsfPG/O89qXLdADubMuj5mqq2us2buf8yZ9iKxr6+Lx2NSz0wBPh
	ipQkFTUY3ea0kSgczOTFY3DOJI8S8Gx3A8DmDxsU9gzVrhfUnQ8qtXMyI3sOm38=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=kS6mC3AipTr2ylKJvfeJnsK4HvM=; b=S6aNAFyMG4w
	DIHWZ9oS+uCYqlkGHJ+7F9tnbYyEyvZuOiB57XkiVlrIfCh4r8oKzbwJEA8j75hj
	KSkym+N+LgLk++1lJpEYDUv0b1c+Lo3BmfCQoGM18tNJybb+TRaKHO/PW1qrAM2E
	xNZMOrH09xkGaG/CtoNzfrsye9kXW0FQ=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a18.g.dreamhost.com (Postfix) with ESMTPSA id 9879025006B; 
	Fri,  9 Dec 2011 12:21:34 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 5b9b36648e439bca97b07d4729ce51ce196596da
Message-Id: <5b9b36648e439bca97b0.1323462155@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1323462147@xdev.gridcentric.ca>
References: <patchbomb.1323462147@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Fri, 09 Dec 2011 15:22:35 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, keir.xen@gmail.com, tim@xen.org, JBeulich@suse.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 8 of 9] x86/mm: New domctl: Perform sharing audit
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/mm/mem_sharing.c |  15 ++++++++++-----
 xen/include/public/domctl.h   |   1 +
 2 files changed, 11 insertions(+), 5 deletions(-)


Sharing audits are heavyweight, so instead of performing them inline,
we make them callable via a domctl.

Signed-off-by: Adin Scannell <adin@scannell.ca>

diff -r 82d9d136bad6 -r 5b9b36648e43 xen/arch/x86/mm/mem_sharing.c
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -936,7 +936,6 @@ int mem_sharing_unshare_page(struct doma
      * between shr_lock and p2m fine-grained locks in mm-lock. 
      * Callers may walk in here already holding the lock for this gfn */
     shr_lock();
-    mem_sharing_audit();
     mfn = get_gfn(d, gfn, &p2mt);
     
     /* Has someone already unshared it? */
@@ -1218,15 +1217,21 @@ int mem_sharing_domctl(struct domain *d,
         }
         break;
 
+        case XEN_DOMCTL_MEM_EVENT_OP_SHARING_AUDIT:
+        {
+#if MEM_SHARING_AUDIT
+            rc = mem_sharing_audit();
+#else
+            rc = -ENOSYS;
+#endif
+            break;
+        }
+
         default:
             rc = -ENOSYS;
             break;
     }
 
-    shr_lock();
-    mem_sharing_audit();
-    shr_unlock();
-
     return rc;
 }
 
diff -r 82d9d136bad6 -r 5b9b36648e43 xen/include/public/domctl.h
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -772,6 +772,7 @@ DEFINE_XEN_GUEST_HANDLE(xen_domctl_mem_e
 #define XEN_DOMCTL_MEM_EVENT_OP_SHARING_DEBUG_MFN      6
 #define XEN_DOMCTL_MEM_EVENT_OP_SHARING_DEBUG_GREF     7
 #define XEN_DOMCTL_MEM_EVENT_OP_SHARING_ADD_PHYSMAP    8
+#define XEN_DOMCTL_MEM_EVENT_OP_SHARING_AUDIT          9
 
 #define XEN_DOMCTL_MEM_SHARING_S_HANDLE_INVALID  (-10)
 #define XEN_DOMCTL_MEM_SHARING_C_HANDLE_INVALID  (-9)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 20:22:38 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 20:22:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZ6xb-0005k2-08; Fri, 09 Dec 2011 20:22:23 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RZ6xY-0005i5-Ql
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 20:22:21 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-10.tower-216.messagelabs.com!1323462089!6759091!1
X-Originating-IP: [208.97.132.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMDguOTcuMTMyLjgxID0+IDE3MzQ2\n,sa_preprocessor: 
	QmFkIElQOiAyMDguOTcuMTMyLjgxID0+IDE3MzQ2\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26391 invoked from network); 9 Dec 2011 20:21:29 -0000
Received: from caiajhbdcaib.dreamhost.com (HELO homiemail-a18.g.dreamhost.com)
	(208.97.132.81) by server-10.tower-216.messagelabs.com with SMTP;
	9 Dec 2011 20:21:29 -0000
Received: from homiemail-a18.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a18.g.dreamhost.com (Postfix) with ESMTP id D119B250078;
	Fri,  9 Dec 2011 12:21:28 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=hLLd9wr9fKIVtxaXzAFB9rusYingDNSladXjNAzBSe4W
	GLmomz7l+UKcz0EN2V/JoUzDbWy2GGO83lpOmNIVCGPfpgwOAvp9qMxDld7lViY4
	TWnLXFu/GXSf1xUiLVGXwujZWNtoozfZyjjpZhjLMLzfhq4yBHaToXPyQwFBn/o=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=Wo45WRkY7F3+d8LGM9IYV9PXB5Q=; b=hzvH446H6p5
	JiBUa48k3mqLl5quu0g9sY5x8L+r3uxanSuKKno0JiEjfYMnUa2ekUFshdN+MxMN
	eAOt3gy90bl1Q58LH30GuteqbSRj+LqnXBFVf5z1LQ5cQqma9u2XMLZ8wAVw0agX
	z9FBlfMcJumCCN9ESdUeke1Dhvek9K/c=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a18.g.dreamhost.com (Postfix) with ESMTPSA id C15E525006B; 
	Fri,  9 Dec 2011 12:21:27 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 4862cca21d3c38f33803068140313111a72ea0bc
Message-Id: <4862cca21d3c38f33803.1323462149@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1323462147@xdev.gridcentric.ca>
References: <patchbomb.1323462147@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Fri, 09 Dec 2011 15:22:29 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, keir.xen@gmail.com, tim@xen.org, JBeulich@suse.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 2 of 9] x86/mm: Eliminate hash table in sharing
 code as index of shared mfns
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/mm/mem_sharing.c     |  560 +++++++++++++++++++------------------
 xen/include/asm-x86/mem_sharing.h |   19 +-
 xen/include/asm-x86/mm.h          |   11 +-
 xen/include/public/domctl.h       |    3 +
 4 files changed, 322 insertions(+), 271 deletions(-)


The hashtable mechanism used by the sharing code is a bit odd.  It seems
unnecessary and adds complexity.  Instead, we replace this by storing a list
head directly in the page info for the case when the page is shared.  This does
not add any extra space to the page_info and serves to remove significant
complexity from sharing.

Signed-off-by: Adin Scannell <adin@scannell.ca>
Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r d29cba447de1 -r 4862cca21d3c xen/arch/x86/mm/mem_sharing.c
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -3,6 +3,7 @@
  *
  * Memory sharing support.
  *
+ * Copyright (c) 2011 GridCentric, Inc. (Adin Scannell & Andres Lagar-Cavilla)
  * Copyright (c) 2009 Citrix Systems, Inc. (Grzegorz Milos)
  *
  * This program is free software; you can redistribute it and/or modify
@@ -34,15 +35,29 @@
 
 #include "mm-locks.h"
 
-/* Auditing of memory sharing code? */
-#define MEM_SHARING_AUDIT 0
-
 #if MEM_SHARING_AUDIT
-static void mem_sharing_audit(void);
+static int mem_sharing_audit(void);
 #define MEM_SHARING_DEBUG(_f, _a...)                                  \
     debugtrace_printk("mem_sharing_debug: %s(): " _f, __func__, ##_a)
+static struct list_head shr_audit_list;
+
+static inline void audit_add_list(struct page_info *page)
+{
+    list_add(&page->shared_info->entry, &shr_audit_list);
+}
+
+static inline void audit_del_list(struct page_info *page)
+{
+    list_del(&page->shared_info->entry);
+}
 #else
-#define mem_sharing_audit() do {} while(0)
+static inline int mem_sharing_audit(void)
+{
+    return 0;
+}
+
+#define audit_add_list(p)  ((void)0)
+#define audit_del_list(p)  ((void)0)
 #endif /* MEM_SHARING_AUDIT */
 
 #define mem_sharing_enabled(d) \
@@ -58,17 +73,6 @@ static void mem_sharing_audit(void);
 static shr_handle_t next_handle = 1;
 static atomic_t nr_saved_mfns   = ATOMIC_INIT(0); 
 
-typedef struct shr_hash_entry 
-{
-    shr_handle_t handle;
-    mfn_t mfn; 
-    struct shr_hash_entry *next;
-    struct list_head gfns;
-} shr_hash_entry_t;
-
-#define SHR_HASH_LENGTH 1000
-static shr_hash_entry_t *shr_hash[SHR_HASH_LENGTH];
-
 typedef struct gfn_info
 {
     unsigned long gfn;
@@ -89,36 +93,30 @@ static inline gfn_info_t *gfn_get_info(s
     return list_entry(list->next, gfn_info_t, list);
 }
 
-static void __init mem_sharing_hash_init(void)
+static inline gfn_info_t *mem_sharing_gfn_alloc(struct page_info *page,
+                                         struct domain *d,
+                                         unsigned long gfn)
 {
-    int i;
+    gfn_info_t *gfn_info = xmalloc(gfn_info_t);
 
-    mm_lock_init(&shr_lock);
-    for(i=0; i<SHR_HASH_LENGTH; i++)
-        shr_hash[i] = NULL;
+    if ( gfn_info == NULL )
+        return NULL; 
+
+    gfn_info->gfn = gfn;
+    gfn_info->domain = d->domain_id;
+    INIT_LIST_HEAD(&gfn_info->list);
+    list_add(&gfn_info->list, &page->shared_info->gfns);
+
+    return gfn_info;
 }
 
-static shr_hash_entry_t *mem_sharing_hash_alloc(void)
-{
-    return xmalloc(shr_hash_entry_t); 
-}
-
-static void mem_sharing_hash_destroy(shr_hash_entry_t *e)
-{
-    xfree(e);
-}
-
-static gfn_info_t *mem_sharing_gfn_alloc(void)
-{
-    return xmalloc(gfn_info_t); 
-}
-
-static void mem_sharing_gfn_destroy(gfn_info_t *gfn, int was_shared)
+static inline void mem_sharing_gfn_destroy(gfn_info_t *gfn_info,
+                                    int was_shared)
 {
     /* Decrement the number of pages, if the gfn was shared before */
     if ( was_shared )
     {
-        struct domain *d = get_domain_by_id(gfn->domain);
+        struct domain *d = get_domain_by_id(gfn_info->domain);
         /* Domain may have been destroyed by now *
          * (if we are called from p2m_teardown)  */
         if ( d )
@@ -127,128 +125,127 @@ static void mem_sharing_gfn_destroy(gfn_
             put_domain(d);
         }
     }
-    xfree(gfn);
+
+    list_del(&gfn_info->list);
+    xfree(gfn_info);
 }
 
-static shr_hash_entry_t* mem_sharing_hash_lookup(shr_handle_t handle)
+static struct page_info* mem_sharing_lookup(unsigned long mfn)
 {
-    shr_hash_entry_t *e;
-    
-    e = shr_hash[handle % SHR_HASH_LENGTH]; 
-    while(e != NULL)
+    if ( mfn_valid(_mfn(mfn)) )
     {
-        if(e->handle == handle)
-            return e;
-        e = e->next;
+        struct page_info* page = mfn_to_page(_mfn(mfn));
+        if ( page_get_owner(page) == dom_cow )
+        {
+            ASSERT(page->u.inuse.type_info & PGT_type_mask); 
+            ASSERT(get_gpfn_from_mfn(mfn) == SHARED_M2P_ENTRY); 
+            return page;
+        }
     }
 
     return NULL;
 }
 
-static shr_hash_entry_t* mem_sharing_hash_insert(shr_handle_t handle, mfn_t mfn)
+#if MEM_SHARING_AUDIT
+static int mem_sharing_audit(void)
 {
-    shr_hash_entry_t *e, **ee;
-    
-    e = mem_sharing_hash_alloc();
-    if(e == NULL) return NULL;
-    e->handle = handle;
-    e->mfn = mfn;
-    ee = &shr_hash[handle % SHR_HASH_LENGTH]; 
-    e->next = *ee;
-    *ee = e;
-    return e;
-}
-
-static void mem_sharing_hash_delete(shr_handle_t handle)
-{
-    shr_hash_entry_t **pprev, *e;  
-
-    pprev = &shr_hash[handle % SHR_HASH_LENGTH];
-    e = *pprev;
-    while(e != NULL)
-    {
-        if(e->handle == handle)
-        {
-            *pprev = e->next;
-            mem_sharing_hash_destroy(e);
-            return;
-        }
-        pprev = &e->next;
-        e = e->next;
-    }
-    printk("Could not find shr entry for handle %"PRIx64"\n", handle);
-    BUG();
-} 
-
-#if MEM_SHARING_AUDIT
-static void mem_sharing_audit(void)
-{
-    shr_hash_entry_t *e;
-    struct list_head *le;
-    gfn_info_t *g;
-    int bucket;
-    struct page_info *pg;
+    int errors = 0;
+    struct list_head *ae;
 
     ASSERT(shr_locked_by_me());
 
-    for(bucket=0; bucket < SHR_HASH_LENGTH; bucket++)
+    list_for_each(ae, &shr_audit_list)
     {
-        e = shr_hash[bucket];    
-        /* Loop over all shr_hash_entries */ 
-        while(e != NULL)
+        struct page_sharing_info *shared_info;
+        unsigned long nr_gfns = 0;
+        struct page_info *pg;
+        struct list_head *le;
+        mfn_t mfn;
+
+        shared_info = list_entry(ae, struct page_sharing_info, entry);
+        pg = shared_info->pg;
+        mfn = page_to_mfn(pg);
+
+        /* Check if the MFN has correct type, owner and handle. */ 
+        if ( !(pg->u.inuse.type_info & PGT_shared_page) )
         {
-            int nr_gfns=0;
+           MEM_SHARING_DEBUG("mfn %lx in audit list, but not PGT_shared_page (%d)!\n",
+                              mfn_x(mfn), pg->u.inuse.type_info & PGT_type_mask);
+           errors++;
+           continue;
+        }
 
-            /* Check if the MFN has correct type, owner and handle */ 
-            pg = mfn_to_page(e->mfn);
-            if((pg->u.inuse.type_info & PGT_type_mask) != PGT_shared_page)
-                MEM_SHARING_DEBUG("mfn %lx not shared, but in the hash!\n",
-                                   mfn_x(e->mfn));
-            if(page_get_owner(pg) != dom_cow)
-                MEM_SHARING_DEBUG("mfn %lx shared, but wrong owner (%d)!\n",
-                                   mfn_x(e->mfn), 
-                                   page_get_owner(pg)->domain_id);
-            if(e->handle != pg->shr_handle)
-                MEM_SHARING_DEBUG("mfn %lx shared, but wrong handle "
-                                  "(%ld != %ld)!\n",
-                                   mfn_x(e->mfn), pg->shr_handle, e->handle);
-            /* Check if all GFNs map to the MFN, and the p2m types */
-            list_for_each(le, &e->gfns)
+        /* Check the page owner. */
+        if ( page_get_owner(pg) != dom_cow )
+        {
+           MEM_SHARING_DEBUG("mfn %lx shared, but wrong owner (%d)!\n",
+                             mfn_x(mfn), page_get_owner(pg)->domain_id);
+           errors++;
+        }
+
+        /* Check the m2p entry */
+        if ( get_gpfn_from_mfn(mfn_x(mfn)) != SHARED_M2P_ENTRY )
+        {
+           MEM_SHARING_DEBUG("mfn %lx shared, but wrong m2p entry (%lx)!\n",
+                             mfn_x(mfn), get_gpfn_from_mfn(mfn_x(mfn)));
+           errors++;
+        }
+
+        /* Check we have a list */
+        if ( (!pg->shared_info) || (list_empty(&pg->shared_info->gfns)) )
+        {
+           MEM_SHARING_DEBUG("mfn %lx shared, but empty gfn list!\n",
+                             mfn_x(mfn));
+           errors++;
+           continue;
+        }
+
+        /* Check if all GFNs map to the MFN, and the p2m types */
+        list_for_each(le, &pg->shared_info->gfns)
+        {
+            struct domain *d;
+            p2m_type_t t;
+            mfn_t o_mfn;
+            gfn_info_t *g;
+
+            g = list_entry(le, gfn_info_t, list);
+            d = get_domain_by_id(g->domain);
+            if ( d == NULL )
             {
-                struct domain *d;
-                p2m_type_t t;
-                mfn_t mfn;
-
-                g = list_entry(le, struct gfn_info, list);
-                d = get_domain_by_id(g->domain);
-                if(d == NULL)
-                {
-                    MEM_SHARING_DEBUG("Unknow dom: %d, for PFN=%lx, MFN=%lx\n",
-                            g->domain, g->gfn, mfn_x(e->mfn));
-                    continue;
-                }
-                mfn = get_gfn_unlocked(d, g->gfn, &t); 
-                if(mfn_x(mfn) != mfn_x(e->mfn))
-                    MEM_SHARING_DEBUG("Incorrect P2M for d=%d, PFN=%lx."
-                                      "Expecting MFN=%ld, got %ld\n",
-                                      g->domain, g->gfn, mfn_x(e->mfn),
-                                      mfn_x(mfn));
-                if(t != p2m_ram_shared)
-                    MEM_SHARING_DEBUG("Incorrect P2M type for d=%d, PFN=%lx."
-                                      "Expecting t=%d, got %d\n",
-                                      g->domain, g->gfn, mfn_x(e->mfn),
-                                      p2m_ram_shared, t);
-                put_domain(d);
-                nr_gfns++;
-            } 
-            if(nr_gfns != (pg->u.inuse.type_info & PGT_count_mask))
-                MEM_SHARING_DEBUG("Mismatched counts for MFN=%lx."
-                                  "nr_gfns in hash %d, in type_info %d\n",
-                                  mfn_x(e->mfn), nr_gfns, 
-                                 (pg->u.inuse.type_info & PGT_count_mask));
-            e = e->next;
+                MEM_SHARING_DEBUG("Unknown dom: %d, for PFN=%lx, MFN=%lx\n",
+                                  g->domain, g->gfn, mfn);
+                errors++;
+                continue;
+            }
+            o_mfn = get_gfn_query_unlocked(d, g->gfn, &t); 
+            if ( mfn_x(o_mfn) != mfn_x(mfn) )
+            {
+                MEM_SHARING_DEBUG("Incorrect P2M for d=%d, PFN=%lx."
+                                  "Expecting MFN=%ld, got %ld\n",
+                                  g->domain, g->gfn, mfn, mfn_x(o_mfn));
+                errors++;
+            }
+            if ( t != p2m_ram_shared )
+            {
+                MEM_SHARING_DEBUG("Incorrect P2M type for d=%d, PFN=%lx."
+                                  "Expecting t=%d, got %d\n",
+                                  g->domain, g->gfn, mfn, p2m_ram_shared, t);
+                errors++;
+            }
+            put_domain(d);
+            nr_gfns++;
+        }
+        if ( nr_gfns != (pg->u.inuse.type_info & PGT_count_mask) )
+        {
+            MEM_SHARING_DEBUG("Mismatched counts for MFN=%lx."
+                              "nr_gfns in hash %d, in type_info %d\n",
+                              mfn_x(mfn), nr_gfns, 
+                              (pg->u.inuse.type_info & PGT_count_mask));
+            errors++;
         }
     }
+
+    return errors;
 }
 #endif
 
@@ -391,36 +388,6 @@ static int mem_sharing_gref_to_gfn(struc
     return 0;
 }
 
-/* Account for a GFN being shared/unshared.
- * When sharing this function needs to be called _before_ gfn lists are merged
- * together, but _after_ gfn is removed from the list when unsharing.
- */
-static int mem_sharing_gfn_account(struct gfn_info *gfn, int sharing)
-{
-    struct domain *d;
-
-    /* A) When sharing:
-     * if the gfn being shared is in > 1 long list, its already been 
-     * accounted for
-     * B) When unsharing:
-     * if the list is longer than > 1, we don't have to account yet. 
-     */
-    if(list_has_one_entry(&gfn->list))
-    {
-        d = get_domain_by_id(gfn->domain);
-        BUG_ON(!d);
-        if(sharing) 
-            atomic_inc(&d->shr_pages);
-        else
-            atomic_dec(&d->shr_pages);
-        put_domain(d);
-
-        return 1;
-    }
-    mem_sharing_audit();
-
-    return 0;
-}
 
 int mem_sharing_debug_gref(struct domain *d, grant_ref_t ref)
 {
@@ -458,8 +425,6 @@ int mem_sharing_nominate_page(struct dom
     mfn_t mfn;
     struct page_info *page;
     int ret;
-    shr_handle_t handle;
-    shr_hash_entry_t *hash_entry;
     struct gfn_info *gfn_info;
 
     *phandle = 0UL;
@@ -475,7 +440,7 @@ int mem_sharing_nominate_page(struct dom
     /* Return the handle if the page is already shared */
     page = mfn_to_page(mfn);
     if ( p2m_is_shared(p2mt) ) {
-        *phandle = page->shr_handle;
+        *phandle = page->shared_info->handle;
         ret = 0;
         goto out;
     }
@@ -489,16 +454,29 @@ int mem_sharing_nominate_page(struct dom
     if ( ret ) 
         goto out;
 
-    /* Create the handle */
+    /* Initialize the shared state */
     ret = -ENOMEM;
-    handle = next_handle++;  
-    if((hash_entry = mem_sharing_hash_insert(handle, mfn)) == NULL)
+    if ( (page->shared_info = 
+            xmalloc(struct page_sharing_info)) == NULL )
     {
+        BUG_ON(page_make_private(d, page) != 0);
         goto out;
     }
-    if((gfn_info = mem_sharing_gfn_alloc()) == NULL)
+    page->shared_info->pg = page;
+    INIT_LIST_HEAD(&page->shared_info->gfns);
+#if MEM_SHARING_AUDIT
+    INIT_LIST_HEAD(&page->shared_info->entry);
+#endif
+
+    /* Create the handle */
+    page->shared_info->handle = next_handle++;  
+
+    /* Create the local gfn info */
+    if ( (gfn_info = mem_sharing_gfn_alloc(page, d, gfn)) == NULL )
     {
-        mem_sharing_hash_destroy(hash_entry);
+        xfree(page->shared_info);
+        page->shared_info = NULL;
+        BUG_ON(page_make_private(d, page) != 0);
         goto out;
     }
 
@@ -509,23 +487,19 @@ int mem_sharing_nominate_page(struct dom
          * it a few lines above.
          * The mfn needs to revert back to rw type. This should never fail,
          * since no-one knew that the mfn was temporarily sharable */
+        mem_sharing_gfn_destroy(gfn_info, 0);
+        xfree(page->shared_info);
+        page->shared_info = NULL;
+        /* NOTE: We haven't yet added this to the audit list. */
         BUG_ON(page_make_private(d, page) != 0);
-        mem_sharing_hash_destroy(hash_entry);
-        mem_sharing_gfn_destroy(gfn_info, 0);
         goto out;
     }
 
     /* Update m2p entry to SHARED_M2P_ENTRY */
     set_gpfn_from_mfn(mfn_x(mfn), SHARED_M2P_ENTRY);
 
-    INIT_LIST_HEAD(&hash_entry->gfns);
-    INIT_LIST_HEAD(&gfn_info->list);
-    list_add(&gfn_info->list, &hash_entry->gfns);
-    gfn_info->gfn = gfn;
-    gfn_info->domain = d->domain_id;
-    page->shr_handle = handle;
-    *phandle = handle;
-
+    *phandle = page->shared_info->handle;
+    audit_add_list(page);
     ret = 0;
 
 out:
@@ -534,54 +508,92 @@ out:
     return ret;
 }
 
-int mem_sharing_share_pages(shr_handle_t sh, shr_handle_t ch) 
+int mem_sharing_share_pages(struct domain *sd, unsigned long sgfn, shr_handle_t sh,
+                            struct domain *cd, unsigned long cgfn, shr_handle_t ch) 
 {
-    shr_hash_entry_t *se, *ce;
     struct page_info *spage, *cpage;
     struct list_head *le, *te;
-    struct gfn_info *gfn;
+    gfn_info_t *gfn;
     struct domain *d;
-    int ret;
+    int ret = -EINVAL, single_client_gfn, single_source_gfn;
+    mfn_t smfn, cmfn;
+    p2m_type_t smfn_type, cmfn_type;
 
     shr_lock();
 
+    /* XXX if sd == cd handle potential deadlock by ordering
+     * the get_ and put_gfn's */
+    smfn = get_gfn(sd, sgfn, &smfn_type);
+    cmfn = get_gfn(cd, cgfn, &cmfn_type);
+
     ret = XEN_DOMCTL_MEM_SHARING_S_HANDLE_INVALID;
-    se = mem_sharing_hash_lookup(sh);
-    if(se == NULL) goto err_out;
+    spage = mem_sharing_lookup(mfn_x(smfn));
+    if ( spage == NULL )
+        goto err_out;
+    ASSERT(smfn_type == p2m_ram_shared);
     ret = XEN_DOMCTL_MEM_SHARING_C_HANDLE_INVALID;
-    ce = mem_sharing_hash_lookup(ch);
-    if(ce == NULL) goto err_out;
-    spage = mfn_to_page(se->mfn); 
-    cpage = mfn_to_page(ce->mfn); 
-    /* gfn lists always have at least one entry => save to call list_entry */
-    mem_sharing_gfn_account(gfn_get_info(&ce->gfns), 1);
-    mem_sharing_gfn_account(gfn_get_info(&se->gfns), 1);
-    list_for_each_safe(le, te, &ce->gfns)
+    cpage = mem_sharing_lookup(mfn_x(cmfn));
+    if ( cpage == NULL )
+        goto err_out;
+    ASSERT(cmfn_type == p2m_ram_shared);
+
+    /* Check that the handles match */
+    if ( spage->shared_info->handle != sh )
     {
-        gfn = list_entry(le, struct gfn_info, list);
-        /* Get the source page and type, this should never fail 
-         * because we are under shr lock, and got non-null se */
+        ret = XEN_DOMCTL_MEM_SHARING_S_HANDLE_INVALID;
+        goto err_out;
+    }
+    if ( cpage->shared_info->handle != ch )
+    {
+        ret = XEN_DOMCTL_MEM_SHARING_C_HANDLE_INVALID;
+        goto err_out;
+    }
+
+    /* Merge the lists together */
+    single_source_gfn = list_has_one_entry(&spage->shared_info->gfns);
+    single_client_gfn = list_has_one_entry(&cpage->shared_info->gfns);
+    list_for_each_safe(le, te, &cpage->shared_info->gfns)
+    {
+        gfn = list_entry(le, gfn_info_t, list);
+        /* Get the source page and type, this should never fail: 
+         * we are under shr lock, and got a successful lookup */
         BUG_ON(!get_page_and_type(spage, dom_cow, PGT_shared_page));
-        /* Move the gfn_info from ce list to se list */
+        /* Move the gfn_info from client list to source list */
         list_del(&gfn->list);
+        list_add(&gfn->list, &spage->shared_info->gfns);
+        put_page_and_type(cpage);
         d = get_domain_by_id(gfn->domain);
         BUG_ON(!d);
-        BUG_ON(set_shared_p2m_entry(d, gfn->gfn, se->mfn) == 0);
+        BUG_ON(set_shared_p2m_entry(d, gfn->gfn, smfn) == 0);
+        if ( single_client_gfn )
+        {
+            /* Only increase the per-domain count when we are actually
+             * sharing. And don't increase it should we ever re-share */
+            atomic_inc(&d->shr_pages);
+            ASSERT( cd == d );
+        }
         put_domain(d);
-        list_add(&gfn->list, &se->gfns);
-        put_page_and_type(cpage);
-    } 
-    ASSERT(list_empty(&ce->gfns));
-    mem_sharing_hash_delete(ch);
-    atomic_inc(&nr_saved_mfns);
+    }
+    ASSERT(list_empty(&cpage->shared_info->gfns));
+    if ( single_source_gfn )
+        atomic_inc(&sd->shr_pages);
+
+    /* Clear the rest of the shared state */
+    audit_del_list(cpage);
+    xfree(cpage->shared_info);
+    cpage->shared_info = NULL;
+
     /* Free the client page */
     if(test_and_clear_bit(_PGC_allocated, &cpage->count_info))
         put_page(cpage);
+
+    atomic_inc(&nr_saved_mfns);
     ret = 0;
     
 err_out:
+    put_gfn(cd, cgfn);
+    put_gfn(sd, sgfn);
     shr_unlock();
-
     return ret;
 }
 
@@ -593,13 +605,9 @@ int mem_sharing_unshare_page(struct doma
     mfn_t mfn;
     struct page_info *page, *old_page;
     void *s, *t;
-    int ret, last_gfn;
-    shr_hash_entry_t *hash_entry;
-    struct gfn_info *gfn_info = NULL;
-    shr_handle_t handle;
+    int last_gfn;
+    gfn_info_t *gfn_info = NULL;
     struct list_head *le;
-
-    /* Remove the gfn_info from the list */
    
     /* This is one of the reasons why we can't enforce ordering
      * between shr_lock and p2m fine-grained locks in mm-lock. 
@@ -615,56 +623,74 @@ int mem_sharing_unshare_page(struct doma
         return 0;
     }
 
-    page = mfn_to_page(mfn);
-    handle = page->shr_handle;
- 
-    hash_entry = mem_sharing_hash_lookup(handle); 
-    list_for_each(le, &hash_entry->gfns)
+    page = mem_sharing_lookup(mfn_x(mfn));
+    if ( page == NULL )
     {
-        gfn_info = list_entry(le, struct gfn_info, list);
+        gdprintk(XENLOG_ERR, "Domain p2m is shared, but page is not: "
+                                "%lx\n", gfn);
+        BUG();
+    }
+
+    list_for_each(le, &page->shared_info->gfns)
+    {
+        gfn_info = list_entry(le, gfn_info_t, list);
         if ( (gfn_info->gfn == gfn) && (gfn_info->domain == d->domain_id) )
             goto gfn_found;
     }
     gdprintk(XENLOG_ERR, "Could not find gfn_info for shared gfn: "
                             "%lx\n", gfn);
     BUG();
-gfn_found: 
-    /* Delete gfn_info from the list, but hold on to it, until we've allocated
-     * memory to make a copy */
-    list_del(&gfn_info->list);
-    last_gfn = list_empty(&hash_entry->gfns);
+
+gfn_found:
+    /* Do the accounting first. If anything fails below, we have bigger
+     * bigger fish to fry. First, remove the gfn from the list. */ 
+    last_gfn = list_has_one_entry(&page->shared_info->gfns);
+    mem_sharing_gfn_destroy(gfn_info, !last_gfn);
+    if ( !last_gfn )
+    {
+        atomic_dec(&nr_saved_mfns);
+        /* Update stats if only one gfn is left for this shared page.
+         * This really isn't a shared page anymore. */
+        if ( list_has_one_entry(&page->shared_info->gfns) )
+        {
+            struct list_head *pos = page->shared_info->gfns.next;
+            gfn_info_t *gfn_info = list_entry(pos, gfn_info_t, list);
+            struct domain *d = get_domain_by_id(gfn_info->domain);
+            BUG_ON(!d);
+            atomic_dec(&d->shr_pages);
+            put_domain(d);
+        }
+    } else {
+        /* Clean up shared state */
+        audit_del_list(page);
+        xfree(page->shared_info);
+        page->shared_info = NULL;
+    }
 
     /* If the GFN is getting destroyed drop the references to MFN 
      * (possibly freeing the page), and exit early */
     if ( flags & MEM_SHARING_DESTROY_GFN )
     {
-        mem_sharing_gfn_destroy(gfn_info, !last_gfn);
-        if(last_gfn) 
-            mem_sharing_hash_delete(handle);
-        else 
-            /* Even though we don't allocate a private page, we have to account
-             * for the MFN that originally backed this PFN. */
-            atomic_dec(&nr_saved_mfns);
         put_gfn(d, gfn);
         shr_unlock();
         put_page_and_type(page);
-        if(last_gfn && 
-           test_and_clear_bit(_PGC_allocated, &page->count_info)) 
+        if( last_gfn && 
+            test_and_clear_bit(_PGC_allocated, &page->count_info)) 
             put_page(page);
+
         return 0;
     }
  
-    ret = page_make_private(d, page);
-    BUG_ON(last_gfn & ret);
-    if(ret == 0) goto private_page_found;
+    if ( last_gfn )
+    {
+        BUG_ON(page_make_private(d, page) != 0);
+        goto private_page_found;
+    }
         
     old_page = page;
     page = mem_sharing_alloc_page(d, gfn);
-    if(!page) 
+    if ( !page ) 
     {
-        /* We've failed to obtain memory for private page. Need to re-add the
-         * gfn_info to relevant list */
-        list_add(&gfn_info->list, &hash_entry->gfns);
         put_gfn(d, gfn);
         shr_unlock();
         return -ENOMEM;
@@ -676,30 +702,18 @@ gfn_found:
     unmap_domain_page(s);
     unmap_domain_page(t);
 
-    /* NOTE: set_shared_p2m_entry will switch the underlying mfn. If
-     * we do get_page withing get_gfn, the correct sequence here
-     * should be
-       get_page(page);
-       put_page(old_page);
-     * so that the ref to the old page is dropped, and a ref to
-     * the new page is obtained to later be dropped in put_gfn */
     BUG_ON(set_shared_p2m_entry(d, gfn, page_to_mfn(page)) == 0);
     put_page_and_type(old_page);
 
 private_page_found:    
-    /* We've got a private page, we can commit the gfn destruction */
-    mem_sharing_gfn_destroy(gfn_info, !last_gfn);
-    if(last_gfn) 
-        mem_sharing_hash_delete(handle);
-    else
-        atomic_dec(&nr_saved_mfns);
-
     if ( p2m_change_type(d, gfn, p2m_ram_shared, p2m_ram_rw) != 
                                                 p2m_ram_shared ) 
     {
-        printk("Could not change p2m type.\n");
+        gdprintk(XENLOG_ERR, "Could not change p2m type d %hu gfn %lx.\n", 
+                                d->domain_id, gfn);
         BUG();
     }
+
     /* Update m2p entry */
     set_gpfn_from_mfn(mfn_x(page_to_mfn(page)), gfn);
 
@@ -756,9 +770,18 @@ int mem_sharing_domctl(struct domain *d,
 
         case XEN_DOMCTL_MEM_EVENT_OP_SHARING_SHARE:
         {
-            shr_handle_t sh = mec->u.share.source_handle;
-            shr_handle_t ch = mec->u.share.client_handle;
-            rc = mem_sharing_share_pages(sh, ch); 
+            unsigned long sgfn  = mec->u.share.source_gfn;
+            shr_handle_t sh     = mec->u.share.source_handle;
+            struct domain *cd   = get_domain_by_id(mec->u.share.client_domain);
+            if ( cd )
+            {
+                unsigned long cgfn  = mec->u.share.client_gfn;
+                shr_handle_t ch     = mec->u.share.client_handle;
+                rc = mem_sharing_share_pages(d, sgfn, sh, cd, cgfn, ch); 
+                put_domain(cd);
+            }
+            else
+                return -EEXIST;
         }
         break;
 
@@ -806,6 +829,9 @@ int mem_sharing_domctl(struct domain *d,
 void __init mem_sharing_init(void)
 {
     printk("Initing memory sharing.\n");
-    mem_sharing_hash_init();
+    mm_lock_init(&shr_lock);
+#if MEM_SHARING_AUDIT
+    INIT_LIST_HEAD(&shr_audit_list);
+#endif
 }
 
diff -r d29cba447de1 -r 4862cca21d3c xen/include/asm-x86/mem_sharing.h
--- a/xen/include/asm-x86/mem_sharing.h
+++ b/xen/include/asm-x86/mem_sharing.h
@@ -22,13 +22,28 @@
 #ifndef __MEM_SHARING_H__
 #define __MEM_SHARING_H__
 
+#include <public/domctl.h>
+
+/* Auditing of memory sharing code? */
+#define MEM_SHARING_AUDIT 0
+
+typedef uint64_t shr_handle_t; 
+
+struct page_sharing_info
+{
+    struct page_info *pg;   /* Back pointer to the page. */
+    shr_handle_t handle;    /* Globally unique version / handle. */
+#if MEM_SHARING_AUDIT
+    struct list_head entry; /* List of all shared pages (entry). */
+#endif
+    struct list_head gfns;  /* List of domains and gfns for this page (head). */
+};
+
 #ifdef __x86_64__
 
 #define sharing_supported(_d) \
     (is_hvm_domain(_d) && paging_mode_hap(_d)) 
 
-typedef uint64_t shr_handle_t; 
-
 unsigned int mem_sharing_get_nr_saved_mfns(void);
 int mem_sharing_nominate_page(struct domain *d, 
                               unsigned long gfn,
diff -r d29cba447de1 -r 4862cca21d3c xen/include/asm-x86/mm.h
--- a/xen/include/asm-x86/mm.h
+++ b/xen/include/asm-x86/mm.h
@@ -31,6 +31,8 @@ struct page_list_entry
     __pdx_t next, prev;
 };
 
+struct page_sharing_info;
+
 struct page_info
 {
     union {
@@ -49,8 +51,13 @@ struct page_info
         /* For non-pinnable single-page shadows, a higher entry that points
          * at us. */
         paddr_t up;
-        /* For shared/sharable pages the sharing handle */
-        uint64_t shr_handle; 
+        /* For shared/sharable pages, we use a doubly-linked list
+         * of all the {pfn,domain} pairs that map this page. We also include
+         * an opaque handle, which is effectively a version, so that clients
+         * of sharing share the version they expect to.
+         * This list is allocated and freed when a page is shared/unshared.
+         */
+        struct page_sharing_info *shared_info;
     };
 
     /* Reference count and various PGC_xxx flags and fields. */
diff -r d29cba447de1 -r 4862cca21d3c xen/include/public/domctl.h
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -789,7 +789,10 @@ struct xen_domctl_mem_sharing_op {
             uint64_aligned_t  handle;     /* OUT: the handle           */
         } nominate;
         struct mem_sharing_op_share {     /* OP_SHARE */
+            uint64_aligned_t source_gfn;    /* IN: the gfn of the source page */
             uint64_aligned_t source_handle; /* IN: handle to the source page */
+            uint64_aligned_t client_domain; /* IN: the client domain id */
+            uint64_aligned_t client_gfn;    /* IN: the client gfn */
             uint64_aligned_t client_handle; /* IN: handle to the client page */
         } share; 
         struct mem_sharing_op_debug {     /* OP_DEBUG_xxx */

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 20:22:38 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 20:22:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZ6xd-0005lz-TB; Fri, 09 Dec 2011 20:22:25 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RZ6xc-0005if-E1
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 20:22:24 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-9.tower-174.messagelabs.com!1323462093!4963750!1
X-Originating-IP: [208.97.132.74]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi43NCA9PiAxNDk1Mw==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19887 invoked from network); 9 Dec 2011 20:21:34 -0000
Received: from caiajhbdcahe.dreamhost.com (HELO homiemail-a18.g.dreamhost.com)
	(208.97.132.74) by server-9.tower-174.messagelabs.com with SMTP;
	9 Dec 2011 20:21:34 -0000
Received: from homiemail-a18.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a18.g.dreamhost.com (Postfix) with ESMTP id 34CD125006C;
	Fri,  9 Dec 2011 12:21:33 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=sAvsmyi8NbBLoIq6Q9KUutk+aF+JG9sMOJq4adeRAS/P
	jQmz0rHemCB/7+1cJl+2A2e86plTQZXxMD2hctBI5tnk1hjER7QKkSDDcqksy8/P
	PGHRduZeVBO6LYcYFhCYgwQvzJB2fBwQzOXDX9++BSkGEjksSieZwGEBCqDFjKA=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=ifP0T1tuISmigIOinAhDw/Yj/H0=; b=ies8s7zLVi7
	ixjfBoMpobOoz9dz5LbEVeKNE5MENBporRqRMndjO3Sbr+FfhT9WQzLftXSvx8/8
	1GnZvPD0PFQiqFS/VtEjfEYCGsS9tEyl8Nk27xNy5MMgskk1dxYGtq8wBVwIH9eV
	TNBVEKzb8z6bSt1nrISyy95u50kVFOnk=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a18.g.dreamhost.com (Postfix) with ESMTPSA id 2201625006B; 
	Fri,  9 Dec 2011 12:21:32 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: bba44de8394a5cce612352622489d68502d25498
Message-Id: <bba44de8394a5cce6123.1323462153@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1323462147@xdev.gridcentric.ca>
References: <patchbomb.1323462147@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Fri, 09 Dec 2011 15:22:33 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, keir.xen@gmail.com, tim@xen.org, JBeulich@suse.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 6 of 9] x86/mm: New domctl: add a shared page to
	the physmap
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/mm/mem_sharing.c |  104 ++++++++++++++++++++++++++++++++++++++++++
 xen/include/public/domctl.h   |    3 +-
 2 files changed, 106 insertions(+), 1 deletions(-)


This domctl is useful to, for example, populate parts of a domain's
physmap with shared frames, directly.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r bfebf49b3eb6 -r bba44de8394a xen/arch/x86/mm/mem_sharing.c
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -851,6 +851,74 @@ err_out:
     return ret;
 }
 
+int mem_sharing_add_to_physmap(struct domain *sd, unsigned long sgfn, shr_handle_t sh,
+                            struct domain *cd, unsigned long cgfn) 
+{
+    struct page_info *spage;
+    int ret = -EINVAL;
+    mfn_t smfn, cmfn;
+    p2m_type_t smfn_type, cmfn_type;
+    struct gfn_info *gfn_info;
+    struct p2m_domain *p2m = p2m_get_hostp2m(cd);
+    p2m_access_t a;
+    DECLARE_PG_LOCK_DATA(pld);
+    
+    /* XXX if sd == cd handle potential deadlock by ordering
+     * the get_ and put_gfn's */
+    smfn = get_gfn_query(sd, sgfn, &smfn_type);
+    cmfn = get_gfn_type_access(p2m, cgfn, &cmfn_type, &a, p2m_query, NULL);
+
+    /* Get the source shared page, check and lock */
+    ret = XEN_DOMCTL_MEM_SHARING_S_HANDLE_INVALID;
+    spage = __grab_shared_page(smfn, &pld);
+    if ( spage == NULL )
+        goto err_out;
+    ASSERT(smfn_type == p2m_ram_shared);
+
+    /* Check that the handles match */
+    if ( spage->shared_info->handle != sh )
+        goto err_unlock;
+
+    /* Make sure the target page is a hole in the physmap */
+    if ( mfn_valid(cmfn) ||
+         (!(p2m_is_ram(cmfn_type))) )
+    {
+        ret = XEN_DOMCTL_MEM_SHARING_C_HANDLE_INVALID;
+        goto err_unlock;
+    }
+
+    /* This is simpler than regular sharing */
+    BUG_ON(!get_page_and_type(spage, dom_cow, PGT_shared_page));
+    if ( (gfn_info = mem_sharing_gfn_alloc(spage, cd, cgfn)) == NULL )
+    {
+        put_page_and_type(spage);
+        ret = -ENOMEM;
+        goto err_unlock;
+    }
+
+    p2m_lock(p2m);
+    ret = set_p2m_entry(p2m, cgfn, smfn, PAGE_ORDER_4K, p2m_ram_shared, a);
+    p2m_unlock(p2m);
+
+    /* Tempted to turn this into an assert */
+    if ( !ret ) {
+        ret = -ENOENT;
+        mem_sharing_gfn_destroy(gfn_info, 0);
+        put_page_and_type(spage);
+    } else {
+        atomic_inc(&cd->shr_pages);
+        atomic_inc(&nr_shared_mfns);
+        ret = 0;
+    }
+
+err_unlock:
+    mem_sharing_page_unlock(spage, &pld);
+err_out:
+    put_gfn(cd, cgfn);
+    put_gfn(sd, sgfn);
+    return ret;
+}
+
 int mem_sharing_unshare_page(struct domain *d,
                              unsigned long gfn, 
                              uint16_t flags)
@@ -1085,6 +1153,42 @@ int mem_sharing_domctl(struct domain *d,
         }
         break;
 
+        case XEN_DOMCTL_MEM_EVENT_OP_SHARING_ADD_PHYSMAP:
+        {
+            unsigned long sgfn, cgfn;
+            struct domain *cd;
+            shr_handle_t sh;
+
+            if ( !mem_sharing_enabled(d) )
+                return -EINVAL;
+
+            cd = get_domain_by_id(mec->u.share.client_domain);
+            if ( !cd )
+                return -ESRCH;
+
+            if ( !mem_sharing_enabled(cd) )
+            {
+                put_domain(cd);
+                return -EINVAL;
+            }
+
+            if ( XEN_DOMCTL_MEM_SHARING_FIELD_IS_GREF(mec->u.share.source_gfn) )
+            {
+                /* Cannot add a gref to the physmap */
+                put_domain(cd);
+                return -EINVAL;
+            }
+
+            sgfn    = mec->u.share.source_gfn;
+            sh      = mec->u.share.source_handle;
+            cgfn    = mec->u.share.client_gfn;
+
+            rc = mem_sharing_add_to_physmap(d, sgfn, sh, cd, cgfn); 
+
+            put_domain(cd);
+        }
+        break;
+
         case XEN_DOMCTL_MEM_EVENT_OP_SHARING_RESUME:
         {
             if ( !mem_sharing_enabled(d) )
diff -r bfebf49b3eb6 -r bba44de8394a xen/include/public/domctl.h
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -771,6 +771,7 @@ DEFINE_XEN_GUEST_HANDLE(xen_domctl_mem_e
 #define XEN_DOMCTL_MEM_EVENT_OP_SHARING_DEBUG_GFN      5
 #define XEN_DOMCTL_MEM_EVENT_OP_SHARING_DEBUG_MFN      6
 #define XEN_DOMCTL_MEM_EVENT_OP_SHARING_DEBUG_GREF     7
+#define XEN_DOMCTL_MEM_EVENT_OP_SHARING_ADD_PHYSMAP    8
 
 #define XEN_DOMCTL_MEM_SHARING_S_HANDLE_INVALID  (-10)
 #define XEN_DOMCTL_MEM_SHARING_C_HANDLE_INVALID  (-9)
@@ -797,7 +798,7 @@ struct xen_domctl_mem_sharing_op {
             } u;
             uint64_aligned_t  handle;     /* OUT: the handle           */
         } nominate;
-        struct mem_sharing_op_share {     /* OP_SHARE */
+        struct mem_sharing_op_share {     /* OP_SHARE/ADD_PHYSMAP */
             uint64_aligned_t source_gfn;    /* IN: the gfn of the source page */
             uint64_aligned_t source_handle; /* IN: handle to the source page */
             uint64_aligned_t client_domain; /* IN: the client domain id */

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 20:22:38 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 20:22:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZ6xe-0005mP-BI; Fri, 09 Dec 2011 20:22:26 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RZ6xd-0005ix-LZ
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 20:22:25 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-9.tower-174.messagelabs.com!1323462093!4963750!2
X-Originating-IP: [208.97.132.74]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi43NCA9PiAxNDk1Mw==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19905 invoked from network); 9 Dec 2011 20:21:35 -0000
Received: from caiajhbdcahe.dreamhost.com (HELO homiemail-a18.g.dreamhost.com)
	(208.97.132.74) by server-9.tower-174.messagelabs.com with SMTP;
	9 Dec 2011 20:21:35 -0000
Received: from homiemail-a18.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a18.g.dreamhost.com (Postfix) with ESMTP id 5CE58250075;
	Fri,  9 Dec 2011 12:21:35 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=G37pjOOCwNNfbOgvG+XvUMq51ySyHE609ndpceCy54xB
	yoinG6/ft8fRGsfPG/O89qXLdADubMuj5mqq2us2buf8yZ9iKxr6+Lx2NSz0wBPh
	ipQkFTUY3ea0kSgczOTFY3DOJI8S8Gx3A8DmDxsU9gzVrhfUnQ8qtXMyI3sOm38=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=kS6mC3AipTr2ylKJvfeJnsK4HvM=; b=S6aNAFyMG4w
	DIHWZ9oS+uCYqlkGHJ+7F9tnbYyEyvZuOiB57XkiVlrIfCh4r8oKzbwJEA8j75hj
	KSkym+N+LgLk++1lJpEYDUv0b1c+Lo3BmfCQoGM18tNJybb+TRaKHO/PW1qrAM2E
	xNZMOrH09xkGaG/CtoNzfrsye9kXW0FQ=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a18.g.dreamhost.com (Postfix) with ESMTPSA id 9879025006B; 
	Fri,  9 Dec 2011 12:21:34 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 5b9b36648e439bca97b07d4729ce51ce196596da
Message-Id: <5b9b36648e439bca97b0.1323462155@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1323462147@xdev.gridcentric.ca>
References: <patchbomb.1323462147@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Fri, 09 Dec 2011 15:22:35 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, keir.xen@gmail.com, tim@xen.org, JBeulich@suse.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 8 of 9] x86/mm: New domctl: Perform sharing audit
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/mm/mem_sharing.c |  15 ++++++++++-----
 xen/include/public/domctl.h   |   1 +
 2 files changed, 11 insertions(+), 5 deletions(-)


Sharing audits are heavyweight, so instead of performing them inline,
we make them callable via a domctl.

Signed-off-by: Adin Scannell <adin@scannell.ca>

diff -r 82d9d136bad6 -r 5b9b36648e43 xen/arch/x86/mm/mem_sharing.c
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -936,7 +936,6 @@ int mem_sharing_unshare_page(struct doma
      * between shr_lock and p2m fine-grained locks in mm-lock. 
      * Callers may walk in here already holding the lock for this gfn */
     shr_lock();
-    mem_sharing_audit();
     mfn = get_gfn(d, gfn, &p2mt);
     
     /* Has someone already unshared it? */
@@ -1218,15 +1217,21 @@ int mem_sharing_domctl(struct domain *d,
         }
         break;
 
+        case XEN_DOMCTL_MEM_EVENT_OP_SHARING_AUDIT:
+        {
+#if MEM_SHARING_AUDIT
+            rc = mem_sharing_audit();
+#else
+            rc = -ENOSYS;
+#endif
+            break;
+        }
+
         default:
             rc = -ENOSYS;
             break;
     }
 
-    shr_lock();
-    mem_sharing_audit();
-    shr_unlock();
-
     return rc;
 }
 
diff -r 82d9d136bad6 -r 5b9b36648e43 xen/include/public/domctl.h
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -772,6 +772,7 @@ DEFINE_XEN_GUEST_HANDLE(xen_domctl_mem_e
 #define XEN_DOMCTL_MEM_EVENT_OP_SHARING_DEBUG_MFN      6
 #define XEN_DOMCTL_MEM_EVENT_OP_SHARING_DEBUG_GREF     7
 #define XEN_DOMCTL_MEM_EVENT_OP_SHARING_ADD_PHYSMAP    8
+#define XEN_DOMCTL_MEM_EVENT_OP_SHARING_AUDIT          9
 
 #define XEN_DOMCTL_MEM_SHARING_S_HANDLE_INVALID  (-10)
 #define XEN_DOMCTL_MEM_SHARING_C_HANDLE_INVALID  (-9)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 20:22:38 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 20:22:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZ6xb-0005k2-08; Fri, 09 Dec 2011 20:22:23 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RZ6xY-0005i5-Ql
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 20:22:21 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-10.tower-216.messagelabs.com!1323462089!6759091!1
X-Originating-IP: [208.97.132.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMDguOTcuMTMyLjgxID0+IDE3MzQ2\n,sa_preprocessor: 
	QmFkIElQOiAyMDguOTcuMTMyLjgxID0+IDE3MzQ2\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26391 invoked from network); 9 Dec 2011 20:21:29 -0000
Received: from caiajhbdcaib.dreamhost.com (HELO homiemail-a18.g.dreamhost.com)
	(208.97.132.81) by server-10.tower-216.messagelabs.com with SMTP;
	9 Dec 2011 20:21:29 -0000
Received: from homiemail-a18.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a18.g.dreamhost.com (Postfix) with ESMTP id D119B250078;
	Fri,  9 Dec 2011 12:21:28 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=hLLd9wr9fKIVtxaXzAFB9rusYingDNSladXjNAzBSe4W
	GLmomz7l+UKcz0EN2V/JoUzDbWy2GGO83lpOmNIVCGPfpgwOAvp9qMxDld7lViY4
	TWnLXFu/GXSf1xUiLVGXwujZWNtoozfZyjjpZhjLMLzfhq4yBHaToXPyQwFBn/o=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=Wo45WRkY7F3+d8LGM9IYV9PXB5Q=; b=hzvH446H6p5
	JiBUa48k3mqLl5quu0g9sY5x8L+r3uxanSuKKno0JiEjfYMnUa2ekUFshdN+MxMN
	eAOt3gy90bl1Q58LH30GuteqbSRj+LqnXBFVf5z1LQ5cQqma9u2XMLZ8wAVw0agX
	z9FBlfMcJumCCN9ESdUeke1Dhvek9K/c=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a18.g.dreamhost.com (Postfix) with ESMTPSA id C15E525006B; 
	Fri,  9 Dec 2011 12:21:27 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 4862cca21d3c38f33803068140313111a72ea0bc
Message-Id: <4862cca21d3c38f33803.1323462149@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1323462147@xdev.gridcentric.ca>
References: <patchbomb.1323462147@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Fri, 09 Dec 2011 15:22:29 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, keir.xen@gmail.com, tim@xen.org, JBeulich@suse.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 2 of 9] x86/mm: Eliminate hash table in sharing
 code as index of shared mfns
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/mm/mem_sharing.c     |  560 +++++++++++++++++++------------------
 xen/include/asm-x86/mem_sharing.h |   19 +-
 xen/include/asm-x86/mm.h          |   11 +-
 xen/include/public/domctl.h       |    3 +
 4 files changed, 322 insertions(+), 271 deletions(-)


The hashtable mechanism used by the sharing code is a bit odd.  It seems
unnecessary and adds complexity.  Instead, we replace this by storing a list
head directly in the page info for the case when the page is shared.  This does
not add any extra space to the page_info and serves to remove significant
complexity from sharing.

Signed-off-by: Adin Scannell <adin@scannell.ca>
Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r d29cba447de1 -r 4862cca21d3c xen/arch/x86/mm/mem_sharing.c
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -3,6 +3,7 @@
  *
  * Memory sharing support.
  *
+ * Copyright (c) 2011 GridCentric, Inc. (Adin Scannell & Andres Lagar-Cavilla)
  * Copyright (c) 2009 Citrix Systems, Inc. (Grzegorz Milos)
  *
  * This program is free software; you can redistribute it and/or modify
@@ -34,15 +35,29 @@
 
 #include "mm-locks.h"
 
-/* Auditing of memory sharing code? */
-#define MEM_SHARING_AUDIT 0
-
 #if MEM_SHARING_AUDIT
-static void mem_sharing_audit(void);
+static int mem_sharing_audit(void);
 #define MEM_SHARING_DEBUG(_f, _a...)                                  \
     debugtrace_printk("mem_sharing_debug: %s(): " _f, __func__, ##_a)
+static struct list_head shr_audit_list;
+
+static inline void audit_add_list(struct page_info *page)
+{
+    list_add(&page->shared_info->entry, &shr_audit_list);
+}
+
+static inline void audit_del_list(struct page_info *page)
+{
+    list_del(&page->shared_info->entry);
+}
 #else
-#define mem_sharing_audit() do {} while(0)
+static inline int mem_sharing_audit(void)
+{
+    return 0;
+}
+
+#define audit_add_list(p)  ((void)0)
+#define audit_del_list(p)  ((void)0)
 #endif /* MEM_SHARING_AUDIT */
 
 #define mem_sharing_enabled(d) \
@@ -58,17 +73,6 @@ static void mem_sharing_audit(void);
 static shr_handle_t next_handle = 1;
 static atomic_t nr_saved_mfns   = ATOMIC_INIT(0); 
 
-typedef struct shr_hash_entry 
-{
-    shr_handle_t handle;
-    mfn_t mfn; 
-    struct shr_hash_entry *next;
-    struct list_head gfns;
-} shr_hash_entry_t;
-
-#define SHR_HASH_LENGTH 1000
-static shr_hash_entry_t *shr_hash[SHR_HASH_LENGTH];
-
 typedef struct gfn_info
 {
     unsigned long gfn;
@@ -89,36 +93,30 @@ static inline gfn_info_t *gfn_get_info(s
     return list_entry(list->next, gfn_info_t, list);
 }
 
-static void __init mem_sharing_hash_init(void)
+static inline gfn_info_t *mem_sharing_gfn_alloc(struct page_info *page,
+                                         struct domain *d,
+                                         unsigned long gfn)
 {
-    int i;
+    gfn_info_t *gfn_info = xmalloc(gfn_info_t);
 
-    mm_lock_init(&shr_lock);
-    for(i=0; i<SHR_HASH_LENGTH; i++)
-        shr_hash[i] = NULL;
+    if ( gfn_info == NULL )
+        return NULL; 
+
+    gfn_info->gfn = gfn;
+    gfn_info->domain = d->domain_id;
+    INIT_LIST_HEAD(&gfn_info->list);
+    list_add(&gfn_info->list, &page->shared_info->gfns);
+
+    return gfn_info;
 }
 
-static shr_hash_entry_t *mem_sharing_hash_alloc(void)
-{
-    return xmalloc(shr_hash_entry_t); 
-}
-
-static void mem_sharing_hash_destroy(shr_hash_entry_t *e)
-{
-    xfree(e);
-}
-
-static gfn_info_t *mem_sharing_gfn_alloc(void)
-{
-    return xmalloc(gfn_info_t); 
-}
-
-static void mem_sharing_gfn_destroy(gfn_info_t *gfn, int was_shared)
+static inline void mem_sharing_gfn_destroy(gfn_info_t *gfn_info,
+                                    int was_shared)
 {
     /* Decrement the number of pages, if the gfn was shared before */
     if ( was_shared )
     {
-        struct domain *d = get_domain_by_id(gfn->domain);
+        struct domain *d = get_domain_by_id(gfn_info->domain);
         /* Domain may have been destroyed by now *
          * (if we are called from p2m_teardown)  */
         if ( d )
@@ -127,128 +125,127 @@ static void mem_sharing_gfn_destroy(gfn_
             put_domain(d);
         }
     }
-    xfree(gfn);
+
+    list_del(&gfn_info->list);
+    xfree(gfn_info);
 }
 
-static shr_hash_entry_t* mem_sharing_hash_lookup(shr_handle_t handle)
+static struct page_info* mem_sharing_lookup(unsigned long mfn)
 {
-    shr_hash_entry_t *e;
-    
-    e = shr_hash[handle % SHR_HASH_LENGTH]; 
-    while(e != NULL)
+    if ( mfn_valid(_mfn(mfn)) )
     {
-        if(e->handle == handle)
-            return e;
-        e = e->next;
+        struct page_info* page = mfn_to_page(_mfn(mfn));
+        if ( page_get_owner(page) == dom_cow )
+        {
+            ASSERT(page->u.inuse.type_info & PGT_type_mask); 
+            ASSERT(get_gpfn_from_mfn(mfn) == SHARED_M2P_ENTRY); 
+            return page;
+        }
     }
 
     return NULL;
 }
 
-static shr_hash_entry_t* mem_sharing_hash_insert(shr_handle_t handle, mfn_t mfn)
+#if MEM_SHARING_AUDIT
+static int mem_sharing_audit(void)
 {
-    shr_hash_entry_t *e, **ee;
-    
-    e = mem_sharing_hash_alloc();
-    if(e == NULL) return NULL;
-    e->handle = handle;
-    e->mfn = mfn;
-    ee = &shr_hash[handle % SHR_HASH_LENGTH]; 
-    e->next = *ee;
-    *ee = e;
-    return e;
-}
-
-static void mem_sharing_hash_delete(shr_handle_t handle)
-{
-    shr_hash_entry_t **pprev, *e;  
-
-    pprev = &shr_hash[handle % SHR_HASH_LENGTH];
-    e = *pprev;
-    while(e != NULL)
-    {
-        if(e->handle == handle)
-        {
-            *pprev = e->next;
-            mem_sharing_hash_destroy(e);
-            return;
-        }
-        pprev = &e->next;
-        e = e->next;
-    }
-    printk("Could not find shr entry for handle %"PRIx64"\n", handle);
-    BUG();
-} 
-
-#if MEM_SHARING_AUDIT
-static void mem_sharing_audit(void)
-{
-    shr_hash_entry_t *e;
-    struct list_head *le;
-    gfn_info_t *g;
-    int bucket;
-    struct page_info *pg;
+    int errors = 0;
+    struct list_head *ae;
 
     ASSERT(shr_locked_by_me());
 
-    for(bucket=0; bucket < SHR_HASH_LENGTH; bucket++)
+    list_for_each(ae, &shr_audit_list)
     {
-        e = shr_hash[bucket];    
-        /* Loop over all shr_hash_entries */ 
-        while(e != NULL)
+        struct page_sharing_info *shared_info;
+        unsigned long nr_gfns = 0;
+        struct page_info *pg;
+        struct list_head *le;
+        mfn_t mfn;
+
+        shared_info = list_entry(ae, struct page_sharing_info, entry);
+        pg = shared_info->pg;
+        mfn = page_to_mfn(pg);
+
+        /* Check if the MFN has correct type, owner and handle. */ 
+        if ( !(pg->u.inuse.type_info & PGT_shared_page) )
         {
-            int nr_gfns=0;
+           MEM_SHARING_DEBUG("mfn %lx in audit list, but not PGT_shared_page (%d)!\n",
+                              mfn_x(mfn), pg->u.inuse.type_info & PGT_type_mask);
+           errors++;
+           continue;
+        }
 
-            /* Check if the MFN has correct type, owner and handle */ 
-            pg = mfn_to_page(e->mfn);
-            if((pg->u.inuse.type_info & PGT_type_mask) != PGT_shared_page)
-                MEM_SHARING_DEBUG("mfn %lx not shared, but in the hash!\n",
-                                   mfn_x(e->mfn));
-            if(page_get_owner(pg) != dom_cow)
-                MEM_SHARING_DEBUG("mfn %lx shared, but wrong owner (%d)!\n",
-                                   mfn_x(e->mfn), 
-                                   page_get_owner(pg)->domain_id);
-            if(e->handle != pg->shr_handle)
-                MEM_SHARING_DEBUG("mfn %lx shared, but wrong handle "
-                                  "(%ld != %ld)!\n",
-                                   mfn_x(e->mfn), pg->shr_handle, e->handle);
-            /* Check if all GFNs map to the MFN, and the p2m types */
-            list_for_each(le, &e->gfns)
+        /* Check the page owner. */
+        if ( page_get_owner(pg) != dom_cow )
+        {
+           MEM_SHARING_DEBUG("mfn %lx shared, but wrong owner (%d)!\n",
+                             mfn_x(mfn), page_get_owner(pg)->domain_id);
+           errors++;
+        }
+
+        /* Check the m2p entry */
+        if ( get_gpfn_from_mfn(mfn_x(mfn)) != SHARED_M2P_ENTRY )
+        {
+           MEM_SHARING_DEBUG("mfn %lx shared, but wrong m2p entry (%lx)!\n",
+                             mfn_x(mfn), get_gpfn_from_mfn(mfn_x(mfn)));
+           errors++;
+        }
+
+        /* Check we have a list */
+        if ( (!pg->shared_info) || (list_empty(&pg->shared_info->gfns)) )
+        {
+           MEM_SHARING_DEBUG("mfn %lx shared, but empty gfn list!\n",
+                             mfn_x(mfn));
+           errors++;
+           continue;
+        }
+
+        /* Check if all GFNs map to the MFN, and the p2m types */
+        list_for_each(le, &pg->shared_info->gfns)
+        {
+            struct domain *d;
+            p2m_type_t t;
+            mfn_t o_mfn;
+            gfn_info_t *g;
+
+            g = list_entry(le, gfn_info_t, list);
+            d = get_domain_by_id(g->domain);
+            if ( d == NULL )
             {
-                struct domain *d;
-                p2m_type_t t;
-                mfn_t mfn;
-
-                g = list_entry(le, struct gfn_info, list);
-                d = get_domain_by_id(g->domain);
-                if(d == NULL)
-                {
-                    MEM_SHARING_DEBUG("Unknow dom: %d, for PFN=%lx, MFN=%lx\n",
-                            g->domain, g->gfn, mfn_x(e->mfn));
-                    continue;
-                }
-                mfn = get_gfn_unlocked(d, g->gfn, &t); 
-                if(mfn_x(mfn) != mfn_x(e->mfn))
-                    MEM_SHARING_DEBUG("Incorrect P2M for d=%d, PFN=%lx."
-                                      "Expecting MFN=%ld, got %ld\n",
-                                      g->domain, g->gfn, mfn_x(e->mfn),
-                                      mfn_x(mfn));
-                if(t != p2m_ram_shared)
-                    MEM_SHARING_DEBUG("Incorrect P2M type for d=%d, PFN=%lx."
-                                      "Expecting t=%d, got %d\n",
-                                      g->domain, g->gfn, mfn_x(e->mfn),
-                                      p2m_ram_shared, t);
-                put_domain(d);
-                nr_gfns++;
-            } 
-            if(nr_gfns != (pg->u.inuse.type_info & PGT_count_mask))
-                MEM_SHARING_DEBUG("Mismatched counts for MFN=%lx."
-                                  "nr_gfns in hash %d, in type_info %d\n",
-                                  mfn_x(e->mfn), nr_gfns, 
-                                 (pg->u.inuse.type_info & PGT_count_mask));
-            e = e->next;
+                MEM_SHARING_DEBUG("Unknown dom: %d, for PFN=%lx, MFN=%lx\n",
+                                  g->domain, g->gfn, mfn);
+                errors++;
+                continue;
+            }
+            o_mfn = get_gfn_query_unlocked(d, g->gfn, &t); 
+            if ( mfn_x(o_mfn) != mfn_x(mfn) )
+            {
+                MEM_SHARING_DEBUG("Incorrect P2M for d=%d, PFN=%lx."
+                                  "Expecting MFN=%ld, got %ld\n",
+                                  g->domain, g->gfn, mfn, mfn_x(o_mfn));
+                errors++;
+            }
+            if ( t != p2m_ram_shared )
+            {
+                MEM_SHARING_DEBUG("Incorrect P2M type for d=%d, PFN=%lx."
+                                  "Expecting t=%d, got %d\n",
+                                  g->domain, g->gfn, mfn, p2m_ram_shared, t);
+                errors++;
+            }
+            put_domain(d);
+            nr_gfns++;
+        }
+        if ( nr_gfns != (pg->u.inuse.type_info & PGT_count_mask) )
+        {
+            MEM_SHARING_DEBUG("Mismatched counts for MFN=%lx."
+                              "nr_gfns in hash %d, in type_info %d\n",
+                              mfn_x(mfn), nr_gfns, 
+                              (pg->u.inuse.type_info & PGT_count_mask));
+            errors++;
         }
     }
+
+    return errors;
 }
 #endif
 
@@ -391,36 +388,6 @@ static int mem_sharing_gref_to_gfn(struc
     return 0;
 }
 
-/* Account for a GFN being shared/unshared.
- * When sharing this function needs to be called _before_ gfn lists are merged
- * together, but _after_ gfn is removed from the list when unsharing.
- */
-static int mem_sharing_gfn_account(struct gfn_info *gfn, int sharing)
-{
-    struct domain *d;
-
-    /* A) When sharing:
-     * if the gfn being shared is in > 1 long list, its already been 
-     * accounted for
-     * B) When unsharing:
-     * if the list is longer than > 1, we don't have to account yet. 
-     */
-    if(list_has_one_entry(&gfn->list))
-    {
-        d = get_domain_by_id(gfn->domain);
-        BUG_ON(!d);
-        if(sharing) 
-            atomic_inc(&d->shr_pages);
-        else
-            atomic_dec(&d->shr_pages);
-        put_domain(d);
-
-        return 1;
-    }
-    mem_sharing_audit();
-
-    return 0;
-}
 
 int mem_sharing_debug_gref(struct domain *d, grant_ref_t ref)
 {
@@ -458,8 +425,6 @@ int mem_sharing_nominate_page(struct dom
     mfn_t mfn;
     struct page_info *page;
     int ret;
-    shr_handle_t handle;
-    shr_hash_entry_t *hash_entry;
     struct gfn_info *gfn_info;
 
     *phandle = 0UL;
@@ -475,7 +440,7 @@ int mem_sharing_nominate_page(struct dom
     /* Return the handle if the page is already shared */
     page = mfn_to_page(mfn);
     if ( p2m_is_shared(p2mt) ) {
-        *phandle = page->shr_handle;
+        *phandle = page->shared_info->handle;
         ret = 0;
         goto out;
     }
@@ -489,16 +454,29 @@ int mem_sharing_nominate_page(struct dom
     if ( ret ) 
         goto out;
 
-    /* Create the handle */
+    /* Initialize the shared state */
     ret = -ENOMEM;
-    handle = next_handle++;  
-    if((hash_entry = mem_sharing_hash_insert(handle, mfn)) == NULL)
+    if ( (page->shared_info = 
+            xmalloc(struct page_sharing_info)) == NULL )
     {
+        BUG_ON(page_make_private(d, page) != 0);
         goto out;
     }
-    if((gfn_info = mem_sharing_gfn_alloc()) == NULL)
+    page->shared_info->pg = page;
+    INIT_LIST_HEAD(&page->shared_info->gfns);
+#if MEM_SHARING_AUDIT
+    INIT_LIST_HEAD(&page->shared_info->entry);
+#endif
+
+    /* Create the handle */
+    page->shared_info->handle = next_handle++;  
+
+    /* Create the local gfn info */
+    if ( (gfn_info = mem_sharing_gfn_alloc(page, d, gfn)) == NULL )
     {
-        mem_sharing_hash_destroy(hash_entry);
+        xfree(page->shared_info);
+        page->shared_info = NULL;
+        BUG_ON(page_make_private(d, page) != 0);
         goto out;
     }
 
@@ -509,23 +487,19 @@ int mem_sharing_nominate_page(struct dom
          * it a few lines above.
          * The mfn needs to revert back to rw type. This should never fail,
          * since no-one knew that the mfn was temporarily sharable */
+        mem_sharing_gfn_destroy(gfn_info, 0);
+        xfree(page->shared_info);
+        page->shared_info = NULL;
+        /* NOTE: We haven't yet added this to the audit list. */
         BUG_ON(page_make_private(d, page) != 0);
-        mem_sharing_hash_destroy(hash_entry);
-        mem_sharing_gfn_destroy(gfn_info, 0);
         goto out;
     }
 
     /* Update m2p entry to SHARED_M2P_ENTRY */
     set_gpfn_from_mfn(mfn_x(mfn), SHARED_M2P_ENTRY);
 
-    INIT_LIST_HEAD(&hash_entry->gfns);
-    INIT_LIST_HEAD(&gfn_info->list);
-    list_add(&gfn_info->list, &hash_entry->gfns);
-    gfn_info->gfn = gfn;
-    gfn_info->domain = d->domain_id;
-    page->shr_handle = handle;
-    *phandle = handle;
-
+    *phandle = page->shared_info->handle;
+    audit_add_list(page);
     ret = 0;
 
 out:
@@ -534,54 +508,92 @@ out:
     return ret;
 }
 
-int mem_sharing_share_pages(shr_handle_t sh, shr_handle_t ch) 
+int mem_sharing_share_pages(struct domain *sd, unsigned long sgfn, shr_handle_t sh,
+                            struct domain *cd, unsigned long cgfn, shr_handle_t ch) 
 {
-    shr_hash_entry_t *se, *ce;
     struct page_info *spage, *cpage;
     struct list_head *le, *te;
-    struct gfn_info *gfn;
+    gfn_info_t *gfn;
     struct domain *d;
-    int ret;
+    int ret = -EINVAL, single_client_gfn, single_source_gfn;
+    mfn_t smfn, cmfn;
+    p2m_type_t smfn_type, cmfn_type;
 
     shr_lock();
 
+    /* XXX if sd == cd handle potential deadlock by ordering
+     * the get_ and put_gfn's */
+    smfn = get_gfn(sd, sgfn, &smfn_type);
+    cmfn = get_gfn(cd, cgfn, &cmfn_type);
+
     ret = XEN_DOMCTL_MEM_SHARING_S_HANDLE_INVALID;
-    se = mem_sharing_hash_lookup(sh);
-    if(se == NULL) goto err_out;
+    spage = mem_sharing_lookup(mfn_x(smfn));
+    if ( spage == NULL )
+        goto err_out;
+    ASSERT(smfn_type == p2m_ram_shared);
     ret = XEN_DOMCTL_MEM_SHARING_C_HANDLE_INVALID;
-    ce = mem_sharing_hash_lookup(ch);
-    if(ce == NULL) goto err_out;
-    spage = mfn_to_page(se->mfn); 
-    cpage = mfn_to_page(ce->mfn); 
-    /* gfn lists always have at least one entry => save to call list_entry */
-    mem_sharing_gfn_account(gfn_get_info(&ce->gfns), 1);
-    mem_sharing_gfn_account(gfn_get_info(&se->gfns), 1);
-    list_for_each_safe(le, te, &ce->gfns)
+    cpage = mem_sharing_lookup(mfn_x(cmfn));
+    if ( cpage == NULL )
+        goto err_out;
+    ASSERT(cmfn_type == p2m_ram_shared);
+
+    /* Check that the handles match */
+    if ( spage->shared_info->handle != sh )
     {
-        gfn = list_entry(le, struct gfn_info, list);
-        /* Get the source page and type, this should never fail 
-         * because we are under shr lock, and got non-null se */
+        ret = XEN_DOMCTL_MEM_SHARING_S_HANDLE_INVALID;
+        goto err_out;
+    }
+    if ( cpage->shared_info->handle != ch )
+    {
+        ret = XEN_DOMCTL_MEM_SHARING_C_HANDLE_INVALID;
+        goto err_out;
+    }
+
+    /* Merge the lists together */
+    single_source_gfn = list_has_one_entry(&spage->shared_info->gfns);
+    single_client_gfn = list_has_one_entry(&cpage->shared_info->gfns);
+    list_for_each_safe(le, te, &cpage->shared_info->gfns)
+    {
+        gfn = list_entry(le, gfn_info_t, list);
+        /* Get the source page and type, this should never fail: 
+         * we are under shr lock, and got a successful lookup */
         BUG_ON(!get_page_and_type(spage, dom_cow, PGT_shared_page));
-        /* Move the gfn_info from ce list to se list */
+        /* Move the gfn_info from client list to source list */
         list_del(&gfn->list);
+        list_add(&gfn->list, &spage->shared_info->gfns);
+        put_page_and_type(cpage);
         d = get_domain_by_id(gfn->domain);
         BUG_ON(!d);
-        BUG_ON(set_shared_p2m_entry(d, gfn->gfn, se->mfn) == 0);
+        BUG_ON(set_shared_p2m_entry(d, gfn->gfn, smfn) == 0);
+        if ( single_client_gfn )
+        {
+            /* Only increase the per-domain count when we are actually
+             * sharing. And don't increase it should we ever re-share */
+            atomic_inc(&d->shr_pages);
+            ASSERT( cd == d );
+        }
         put_domain(d);
-        list_add(&gfn->list, &se->gfns);
-        put_page_and_type(cpage);
-    } 
-    ASSERT(list_empty(&ce->gfns));
-    mem_sharing_hash_delete(ch);
-    atomic_inc(&nr_saved_mfns);
+    }
+    ASSERT(list_empty(&cpage->shared_info->gfns));
+    if ( single_source_gfn )
+        atomic_inc(&sd->shr_pages);
+
+    /* Clear the rest of the shared state */
+    audit_del_list(cpage);
+    xfree(cpage->shared_info);
+    cpage->shared_info = NULL;
+
     /* Free the client page */
     if(test_and_clear_bit(_PGC_allocated, &cpage->count_info))
         put_page(cpage);
+
+    atomic_inc(&nr_saved_mfns);
     ret = 0;
     
 err_out:
+    put_gfn(cd, cgfn);
+    put_gfn(sd, sgfn);
     shr_unlock();
-
     return ret;
 }
 
@@ -593,13 +605,9 @@ int mem_sharing_unshare_page(struct doma
     mfn_t mfn;
     struct page_info *page, *old_page;
     void *s, *t;
-    int ret, last_gfn;
-    shr_hash_entry_t *hash_entry;
-    struct gfn_info *gfn_info = NULL;
-    shr_handle_t handle;
+    int last_gfn;
+    gfn_info_t *gfn_info = NULL;
     struct list_head *le;
-
-    /* Remove the gfn_info from the list */
    
     /* This is one of the reasons why we can't enforce ordering
      * between shr_lock and p2m fine-grained locks in mm-lock. 
@@ -615,56 +623,74 @@ int mem_sharing_unshare_page(struct doma
         return 0;
     }
 
-    page = mfn_to_page(mfn);
-    handle = page->shr_handle;
- 
-    hash_entry = mem_sharing_hash_lookup(handle); 
-    list_for_each(le, &hash_entry->gfns)
+    page = mem_sharing_lookup(mfn_x(mfn));
+    if ( page == NULL )
     {
-        gfn_info = list_entry(le, struct gfn_info, list);
+        gdprintk(XENLOG_ERR, "Domain p2m is shared, but page is not: "
+                                "%lx\n", gfn);
+        BUG();
+    }
+
+    list_for_each(le, &page->shared_info->gfns)
+    {
+        gfn_info = list_entry(le, gfn_info_t, list);
         if ( (gfn_info->gfn == gfn) && (gfn_info->domain == d->domain_id) )
             goto gfn_found;
     }
     gdprintk(XENLOG_ERR, "Could not find gfn_info for shared gfn: "
                             "%lx\n", gfn);
     BUG();
-gfn_found: 
-    /* Delete gfn_info from the list, but hold on to it, until we've allocated
-     * memory to make a copy */
-    list_del(&gfn_info->list);
-    last_gfn = list_empty(&hash_entry->gfns);
+
+gfn_found:
+    /* Do the accounting first. If anything fails below, we have bigger
+     * bigger fish to fry. First, remove the gfn from the list. */ 
+    last_gfn = list_has_one_entry(&page->shared_info->gfns);
+    mem_sharing_gfn_destroy(gfn_info, !last_gfn);
+    if ( !last_gfn )
+    {
+        atomic_dec(&nr_saved_mfns);
+        /* Update stats if only one gfn is left for this shared page.
+         * This really isn't a shared page anymore. */
+        if ( list_has_one_entry(&page->shared_info->gfns) )
+        {
+            struct list_head *pos = page->shared_info->gfns.next;
+            gfn_info_t *gfn_info = list_entry(pos, gfn_info_t, list);
+            struct domain *d = get_domain_by_id(gfn_info->domain);
+            BUG_ON(!d);
+            atomic_dec(&d->shr_pages);
+            put_domain(d);
+        }
+    } else {
+        /* Clean up shared state */
+        audit_del_list(page);
+        xfree(page->shared_info);
+        page->shared_info = NULL;
+    }
 
     /* If the GFN is getting destroyed drop the references to MFN 
      * (possibly freeing the page), and exit early */
     if ( flags & MEM_SHARING_DESTROY_GFN )
     {
-        mem_sharing_gfn_destroy(gfn_info, !last_gfn);
-        if(last_gfn) 
-            mem_sharing_hash_delete(handle);
-        else 
-            /* Even though we don't allocate a private page, we have to account
-             * for the MFN that originally backed this PFN. */
-            atomic_dec(&nr_saved_mfns);
         put_gfn(d, gfn);
         shr_unlock();
         put_page_and_type(page);
-        if(last_gfn && 
-           test_and_clear_bit(_PGC_allocated, &page->count_info)) 
+        if( last_gfn && 
+            test_and_clear_bit(_PGC_allocated, &page->count_info)) 
             put_page(page);
+
         return 0;
     }
  
-    ret = page_make_private(d, page);
-    BUG_ON(last_gfn & ret);
-    if(ret == 0) goto private_page_found;
+    if ( last_gfn )
+    {
+        BUG_ON(page_make_private(d, page) != 0);
+        goto private_page_found;
+    }
         
     old_page = page;
     page = mem_sharing_alloc_page(d, gfn);
-    if(!page) 
+    if ( !page ) 
     {
-        /* We've failed to obtain memory for private page. Need to re-add the
-         * gfn_info to relevant list */
-        list_add(&gfn_info->list, &hash_entry->gfns);
         put_gfn(d, gfn);
         shr_unlock();
         return -ENOMEM;
@@ -676,30 +702,18 @@ gfn_found:
     unmap_domain_page(s);
     unmap_domain_page(t);
 
-    /* NOTE: set_shared_p2m_entry will switch the underlying mfn. If
-     * we do get_page withing get_gfn, the correct sequence here
-     * should be
-       get_page(page);
-       put_page(old_page);
-     * so that the ref to the old page is dropped, and a ref to
-     * the new page is obtained to later be dropped in put_gfn */
     BUG_ON(set_shared_p2m_entry(d, gfn, page_to_mfn(page)) == 0);
     put_page_and_type(old_page);
 
 private_page_found:    
-    /* We've got a private page, we can commit the gfn destruction */
-    mem_sharing_gfn_destroy(gfn_info, !last_gfn);
-    if(last_gfn) 
-        mem_sharing_hash_delete(handle);
-    else
-        atomic_dec(&nr_saved_mfns);
-
     if ( p2m_change_type(d, gfn, p2m_ram_shared, p2m_ram_rw) != 
                                                 p2m_ram_shared ) 
     {
-        printk("Could not change p2m type.\n");
+        gdprintk(XENLOG_ERR, "Could not change p2m type d %hu gfn %lx.\n", 
+                                d->domain_id, gfn);
         BUG();
     }
+
     /* Update m2p entry */
     set_gpfn_from_mfn(mfn_x(page_to_mfn(page)), gfn);
 
@@ -756,9 +770,18 @@ int mem_sharing_domctl(struct domain *d,
 
         case XEN_DOMCTL_MEM_EVENT_OP_SHARING_SHARE:
         {
-            shr_handle_t sh = mec->u.share.source_handle;
-            shr_handle_t ch = mec->u.share.client_handle;
-            rc = mem_sharing_share_pages(sh, ch); 
+            unsigned long sgfn  = mec->u.share.source_gfn;
+            shr_handle_t sh     = mec->u.share.source_handle;
+            struct domain *cd   = get_domain_by_id(mec->u.share.client_domain);
+            if ( cd )
+            {
+                unsigned long cgfn  = mec->u.share.client_gfn;
+                shr_handle_t ch     = mec->u.share.client_handle;
+                rc = mem_sharing_share_pages(d, sgfn, sh, cd, cgfn, ch); 
+                put_domain(cd);
+            }
+            else
+                return -EEXIST;
         }
         break;
 
@@ -806,6 +829,9 @@ int mem_sharing_domctl(struct domain *d,
 void __init mem_sharing_init(void)
 {
     printk("Initing memory sharing.\n");
-    mem_sharing_hash_init();
+    mm_lock_init(&shr_lock);
+#if MEM_SHARING_AUDIT
+    INIT_LIST_HEAD(&shr_audit_list);
+#endif
 }
 
diff -r d29cba447de1 -r 4862cca21d3c xen/include/asm-x86/mem_sharing.h
--- a/xen/include/asm-x86/mem_sharing.h
+++ b/xen/include/asm-x86/mem_sharing.h
@@ -22,13 +22,28 @@
 #ifndef __MEM_SHARING_H__
 #define __MEM_SHARING_H__
 
+#include <public/domctl.h>
+
+/* Auditing of memory sharing code? */
+#define MEM_SHARING_AUDIT 0
+
+typedef uint64_t shr_handle_t; 
+
+struct page_sharing_info
+{
+    struct page_info *pg;   /* Back pointer to the page. */
+    shr_handle_t handle;    /* Globally unique version / handle. */
+#if MEM_SHARING_AUDIT
+    struct list_head entry; /* List of all shared pages (entry). */
+#endif
+    struct list_head gfns;  /* List of domains and gfns for this page (head). */
+};
+
 #ifdef __x86_64__
 
 #define sharing_supported(_d) \
     (is_hvm_domain(_d) && paging_mode_hap(_d)) 
 
-typedef uint64_t shr_handle_t; 
-
 unsigned int mem_sharing_get_nr_saved_mfns(void);
 int mem_sharing_nominate_page(struct domain *d, 
                               unsigned long gfn,
diff -r d29cba447de1 -r 4862cca21d3c xen/include/asm-x86/mm.h
--- a/xen/include/asm-x86/mm.h
+++ b/xen/include/asm-x86/mm.h
@@ -31,6 +31,8 @@ struct page_list_entry
     __pdx_t next, prev;
 };
 
+struct page_sharing_info;
+
 struct page_info
 {
     union {
@@ -49,8 +51,13 @@ struct page_info
         /* For non-pinnable single-page shadows, a higher entry that points
          * at us. */
         paddr_t up;
-        /* For shared/sharable pages the sharing handle */
-        uint64_t shr_handle; 
+        /* For shared/sharable pages, we use a doubly-linked list
+         * of all the {pfn,domain} pairs that map this page. We also include
+         * an opaque handle, which is effectively a version, so that clients
+         * of sharing share the version they expect to.
+         * This list is allocated and freed when a page is shared/unshared.
+         */
+        struct page_sharing_info *shared_info;
     };
 
     /* Reference count and various PGC_xxx flags and fields. */
diff -r d29cba447de1 -r 4862cca21d3c xen/include/public/domctl.h
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -789,7 +789,10 @@ struct xen_domctl_mem_sharing_op {
             uint64_aligned_t  handle;     /* OUT: the handle           */
         } nominate;
         struct mem_sharing_op_share {     /* OP_SHARE */
+            uint64_aligned_t source_gfn;    /* IN: the gfn of the source page */
             uint64_aligned_t source_handle; /* IN: handle to the source page */
+            uint64_aligned_t client_domain; /* IN: the client domain id */
+            uint64_aligned_t client_gfn;    /* IN: the client gfn */
             uint64_aligned_t client_handle; /* IN: handle to the client page */
         } share; 
         struct mem_sharing_op_debug {     /* OP_DEBUG_xxx */

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 20:22:38 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 20:22:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZ6xd-0005lz-TB; Fri, 09 Dec 2011 20:22:25 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RZ6xc-0005if-E1
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 20:22:24 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-9.tower-174.messagelabs.com!1323462093!4963750!1
X-Originating-IP: [208.97.132.74]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi43NCA9PiAxNDk1Mw==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19887 invoked from network); 9 Dec 2011 20:21:34 -0000
Received: from caiajhbdcahe.dreamhost.com (HELO homiemail-a18.g.dreamhost.com)
	(208.97.132.74) by server-9.tower-174.messagelabs.com with SMTP;
	9 Dec 2011 20:21:34 -0000
Received: from homiemail-a18.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a18.g.dreamhost.com (Postfix) with ESMTP id 34CD125006C;
	Fri,  9 Dec 2011 12:21:33 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=sAvsmyi8NbBLoIq6Q9KUutk+aF+JG9sMOJq4adeRAS/P
	jQmz0rHemCB/7+1cJl+2A2e86plTQZXxMD2hctBI5tnk1hjER7QKkSDDcqksy8/P
	PGHRduZeVBO6LYcYFhCYgwQvzJB2fBwQzOXDX9++BSkGEjksSieZwGEBCqDFjKA=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=ifP0T1tuISmigIOinAhDw/Yj/H0=; b=ies8s7zLVi7
	ixjfBoMpobOoz9dz5LbEVeKNE5MENBporRqRMndjO3Sbr+FfhT9WQzLftXSvx8/8
	1GnZvPD0PFQiqFS/VtEjfEYCGsS9tEyl8Nk27xNy5MMgskk1dxYGtq8wBVwIH9eV
	TNBVEKzb8z6bSt1nrISyy95u50kVFOnk=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a18.g.dreamhost.com (Postfix) with ESMTPSA id 2201625006B; 
	Fri,  9 Dec 2011 12:21:32 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: bba44de8394a5cce612352622489d68502d25498
Message-Id: <bba44de8394a5cce6123.1323462153@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1323462147@xdev.gridcentric.ca>
References: <patchbomb.1323462147@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Fri, 09 Dec 2011 15:22:33 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, keir.xen@gmail.com, tim@xen.org, JBeulich@suse.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 6 of 9] x86/mm: New domctl: add a shared page to
	the physmap
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/mm/mem_sharing.c |  104 ++++++++++++++++++++++++++++++++++++++++++
 xen/include/public/domctl.h   |    3 +-
 2 files changed, 106 insertions(+), 1 deletions(-)


This domctl is useful to, for example, populate parts of a domain's
physmap with shared frames, directly.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r bfebf49b3eb6 -r bba44de8394a xen/arch/x86/mm/mem_sharing.c
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -851,6 +851,74 @@ err_out:
     return ret;
 }
 
+int mem_sharing_add_to_physmap(struct domain *sd, unsigned long sgfn, shr_handle_t sh,
+                            struct domain *cd, unsigned long cgfn) 
+{
+    struct page_info *spage;
+    int ret = -EINVAL;
+    mfn_t smfn, cmfn;
+    p2m_type_t smfn_type, cmfn_type;
+    struct gfn_info *gfn_info;
+    struct p2m_domain *p2m = p2m_get_hostp2m(cd);
+    p2m_access_t a;
+    DECLARE_PG_LOCK_DATA(pld);
+    
+    /* XXX if sd == cd handle potential deadlock by ordering
+     * the get_ and put_gfn's */
+    smfn = get_gfn_query(sd, sgfn, &smfn_type);
+    cmfn = get_gfn_type_access(p2m, cgfn, &cmfn_type, &a, p2m_query, NULL);
+
+    /* Get the source shared page, check and lock */
+    ret = XEN_DOMCTL_MEM_SHARING_S_HANDLE_INVALID;
+    spage = __grab_shared_page(smfn, &pld);
+    if ( spage == NULL )
+        goto err_out;
+    ASSERT(smfn_type == p2m_ram_shared);
+
+    /* Check that the handles match */
+    if ( spage->shared_info->handle != sh )
+        goto err_unlock;
+
+    /* Make sure the target page is a hole in the physmap */
+    if ( mfn_valid(cmfn) ||
+         (!(p2m_is_ram(cmfn_type))) )
+    {
+        ret = XEN_DOMCTL_MEM_SHARING_C_HANDLE_INVALID;
+        goto err_unlock;
+    }
+
+    /* This is simpler than regular sharing */
+    BUG_ON(!get_page_and_type(spage, dom_cow, PGT_shared_page));
+    if ( (gfn_info = mem_sharing_gfn_alloc(spage, cd, cgfn)) == NULL )
+    {
+        put_page_and_type(spage);
+        ret = -ENOMEM;
+        goto err_unlock;
+    }
+
+    p2m_lock(p2m);
+    ret = set_p2m_entry(p2m, cgfn, smfn, PAGE_ORDER_4K, p2m_ram_shared, a);
+    p2m_unlock(p2m);
+
+    /* Tempted to turn this into an assert */
+    if ( !ret ) {
+        ret = -ENOENT;
+        mem_sharing_gfn_destroy(gfn_info, 0);
+        put_page_and_type(spage);
+    } else {
+        atomic_inc(&cd->shr_pages);
+        atomic_inc(&nr_shared_mfns);
+        ret = 0;
+    }
+
+err_unlock:
+    mem_sharing_page_unlock(spage, &pld);
+err_out:
+    put_gfn(cd, cgfn);
+    put_gfn(sd, sgfn);
+    return ret;
+}
+
 int mem_sharing_unshare_page(struct domain *d,
                              unsigned long gfn, 
                              uint16_t flags)
@@ -1085,6 +1153,42 @@ int mem_sharing_domctl(struct domain *d,
         }
         break;
 
+        case XEN_DOMCTL_MEM_EVENT_OP_SHARING_ADD_PHYSMAP:
+        {
+            unsigned long sgfn, cgfn;
+            struct domain *cd;
+            shr_handle_t sh;
+
+            if ( !mem_sharing_enabled(d) )
+                return -EINVAL;
+
+            cd = get_domain_by_id(mec->u.share.client_domain);
+            if ( !cd )
+                return -ESRCH;
+
+            if ( !mem_sharing_enabled(cd) )
+            {
+                put_domain(cd);
+                return -EINVAL;
+            }
+
+            if ( XEN_DOMCTL_MEM_SHARING_FIELD_IS_GREF(mec->u.share.source_gfn) )
+            {
+                /* Cannot add a gref to the physmap */
+                put_domain(cd);
+                return -EINVAL;
+            }
+
+            sgfn    = mec->u.share.source_gfn;
+            sh      = mec->u.share.source_handle;
+            cgfn    = mec->u.share.client_gfn;
+
+            rc = mem_sharing_add_to_physmap(d, sgfn, sh, cd, cgfn); 
+
+            put_domain(cd);
+        }
+        break;
+
         case XEN_DOMCTL_MEM_EVENT_OP_SHARING_RESUME:
         {
             if ( !mem_sharing_enabled(d) )
diff -r bfebf49b3eb6 -r bba44de8394a xen/include/public/domctl.h
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -771,6 +771,7 @@ DEFINE_XEN_GUEST_HANDLE(xen_domctl_mem_e
 #define XEN_DOMCTL_MEM_EVENT_OP_SHARING_DEBUG_GFN      5
 #define XEN_DOMCTL_MEM_EVENT_OP_SHARING_DEBUG_MFN      6
 #define XEN_DOMCTL_MEM_EVENT_OP_SHARING_DEBUG_GREF     7
+#define XEN_DOMCTL_MEM_EVENT_OP_SHARING_ADD_PHYSMAP    8
 
 #define XEN_DOMCTL_MEM_SHARING_S_HANDLE_INVALID  (-10)
 #define XEN_DOMCTL_MEM_SHARING_C_HANDLE_INVALID  (-9)
@@ -797,7 +798,7 @@ struct xen_domctl_mem_sharing_op {
             } u;
             uint64_aligned_t  handle;     /* OUT: the handle           */
         } nominate;
-        struct mem_sharing_op_share {     /* OP_SHARE */
+        struct mem_sharing_op_share {     /* OP_SHARE/ADD_PHYSMAP */
             uint64_aligned_t source_gfn;    /* IN: the gfn of the source page */
             uint64_aligned_t source_handle; /* IN: handle to the source page */
             uint64_aligned_t client_domain; /* IN: the client domain id */

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 20:22:38 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 20:22:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZ6xc-0005l7-Rg; Fri, 09 Dec 2011 20:22:24 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RZ6xb-0005ir-5l
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 20:22:23 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-4.tower-27.messagelabs.com!1323462058!51825658!3
X-Originating-IP: [208.97.132.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMDguOTcuMTMyLjgxID0+IDE3MzQ2\n,sa_preprocessor: 
	QmFkIElQOiAyMDguOTcuMTMyLjgxID0+IDE3MzQ2\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1209 invoked from network); 9 Dec 2011 20:21:01 -0000
Received: from caiajhbdcaib.dreamhost.com (HELO homiemail-a18.g.dreamhost.com)
	(208.97.132.81) by server-4.tower-27.messagelabs.com with SMTP;
	9 Dec 2011 20:21:01 -0000
Received: from homiemail-a18.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a18.g.dreamhost.com (Postfix) with ESMTP id 6911A250069;
	Fri,  9 Dec 2011 12:21:34 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=CxuJcw8KJ5gSikOiPx6lmZUlG7Rll1UWhYcUqbdx9Cui
	3DJy6lvInSpnSdU0ak/hdTTxC3vUUlojjqlksTUJ5/APPP/s8dznrHz1tKzMUTXH
	wlQ3e322PjWJosfVmmVHEnxKGWeqIJiY4kVNjfZ7axcPDXUVlQAimTWZ8h/Uj8g=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=W453PQ2so0dXF6Y8Itoln37ZbMw=; b=UNvaEPrY8/N
	u/kh4h9VC7lvdz+DDDM4euj6XH23XHPev/PzJuBxy1dtFjNFhNdMQ4d3aVejytKE
	uuYy7hzYlIBtkLQBWOt12T/bPEQUxts0l5ah03o8oY1aP8fj1haoCTHI69D7o5et
	hcMBGwq+7mlPx30uqdoSo27f/HKAcXA8=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a18.g.dreamhost.com (Postfix) with ESMTPSA id 65A26250075; 
	Fri,  9 Dec 2011 12:21:33 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 82d9d136bad68b0342cbef2d981499d970c85f44
Message-Id: <82d9d136bad68b0342cb.1323462154@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1323462147@xdev.gridcentric.ca>
References: <patchbomb.1323462147@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Fri, 09 Dec 2011 15:22:34 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, keir.xen@gmail.com, tim@xen.org, JBeulich@suse.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 7 of 9] Add the ability to poll stats about
 shared memory via the console
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/ia64/xen/mm.c        |  6 ++++++
 xen/arch/x86/mm/mem_sharing.c |  8 ++++++++
 xen/common/keyhandler.c       |  7 +++++--
 xen/include/xen/mm.h          |  3 +++
 4 files changed, 22 insertions(+), 2 deletions(-)


Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r bba44de8394a -r 82d9d136bad6 xen/arch/ia64/xen/mm.c
--- a/xen/arch/ia64/xen/mm.c
+++ b/xen/arch/ia64/xen/mm.c
@@ -3565,6 +3565,12 @@ p2m_pod_decrease_reservation(struct doma
     return 0;
 }
 
+/* Simple no-op */
+void arch_dump_shared_mem_info(void)
+{
+    printk("Shared memory not supported yet\n");
+}
+
 /*
  * Local variables:
  * mode: C
diff -r bba44de8394a -r 82d9d136bad6 xen/arch/x86/mm/mem_sharing.c
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -1230,6 +1230,14 @@ int mem_sharing_domctl(struct domain *d,
     return rc;
 }
 
+void arch_dump_shared_mem_info(void)
+{
+    printk("Shared pages %u -- Saved frames %u -- Dom CoW footprintf %u\n",
+            mem_sharing_get_nr_shared_mfns(),
+            mem_sharing_get_nr_saved_mfns(),
+            dom_cow->tot_pages);
+}
+
 void __init mem_sharing_init(void)
 {
     printk("Initing memory sharing.\n");
diff -r bba44de8394a -r 82d9d136bad6 xen/common/keyhandler.c
--- a/xen/common/keyhandler.c
+++ b/xen/common/keyhandler.c
@@ -15,6 +15,7 @@
 #include <xen/compat.h>
 #include <xen/ctype.h>
 #include <xen/perfc.h>
+#include <xen/mm.h>
 #include <asm/debugger.h>
 #include <asm/div64.h>
 
@@ -248,8 +249,8 @@ static void dump_domains(unsigned char k
         printk("    refcnt=%d dying=%d pause_count=%d\n",
                atomic_read(&d->refcnt), d->is_dying,
                atomic_read(&d->pause_count));
-        printk("    nr_pages=%d xenheap_pages=%d dirty_cpus=%s max_pages=%u\n",
-               d->tot_pages, d->xenheap_pages, tmpstr, d->max_pages);
+        printk("    nr_pages=%d xenheap_pages=%d shared_pages=%u dirty_cpus=%s max_pages=%u\n",
+               d->tot_pages, d->xenheap_pages, atomic_read(&d->shr_pages), tmpstr, d->max_pages);
         printk("    handle=%02x%02x%02x%02x-%02x%02x-%02x%02x-"
                "%02x%02x-%02x%02x%02x%02x%02x%02x vm_assist=%08lx\n",
                d->handle[ 0], d->handle[ 1], d->handle[ 2], d->handle[ 3],
@@ -308,6 +309,8 @@ static void dump_domains(unsigned char k
         }
     }
 
+    arch_dump_shared_mem_info();
+
     rcu_read_unlock(&domlist_read_lock);
 #undef tmpstr
 }
diff -r bba44de8394a -r 82d9d136bad6 xen/include/xen/mm.h
--- a/xen/include/xen/mm.h
+++ b/xen/include/xen/mm.h
@@ -73,6 +73,9 @@ int assign_pages(
     unsigned int order,
     unsigned int memflags);
 
+/* Dump info to serial console */
+void arch_dump_shared_mem_info(void);
+
 /* memflags: */
 #define _MEMF_no_refcount 0
 #define  MEMF_no_refcount (1U<<_MEMF_no_refcount)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 20:22:38 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 20:22:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZ6xc-0005l7-Rg; Fri, 09 Dec 2011 20:22:24 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RZ6xb-0005ir-5l
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 20:22:23 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-4.tower-27.messagelabs.com!1323462058!51825658!3
X-Originating-IP: [208.97.132.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMDguOTcuMTMyLjgxID0+IDE3MzQ2\n,sa_preprocessor: 
	QmFkIElQOiAyMDguOTcuMTMyLjgxID0+IDE3MzQ2\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1209 invoked from network); 9 Dec 2011 20:21:01 -0000
Received: from caiajhbdcaib.dreamhost.com (HELO homiemail-a18.g.dreamhost.com)
	(208.97.132.81) by server-4.tower-27.messagelabs.com with SMTP;
	9 Dec 2011 20:21:01 -0000
Received: from homiemail-a18.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a18.g.dreamhost.com (Postfix) with ESMTP id 6911A250069;
	Fri,  9 Dec 2011 12:21:34 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=CxuJcw8KJ5gSikOiPx6lmZUlG7Rll1UWhYcUqbdx9Cui
	3DJy6lvInSpnSdU0ak/hdTTxC3vUUlojjqlksTUJ5/APPP/s8dznrHz1tKzMUTXH
	wlQ3e322PjWJosfVmmVHEnxKGWeqIJiY4kVNjfZ7axcPDXUVlQAimTWZ8h/Uj8g=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=W453PQ2so0dXF6Y8Itoln37ZbMw=; b=UNvaEPrY8/N
	u/kh4h9VC7lvdz+DDDM4euj6XH23XHPev/PzJuBxy1dtFjNFhNdMQ4d3aVejytKE
	uuYy7hzYlIBtkLQBWOt12T/bPEQUxts0l5ah03o8oY1aP8fj1haoCTHI69D7o5et
	hcMBGwq+7mlPx30uqdoSo27f/HKAcXA8=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a18.g.dreamhost.com (Postfix) with ESMTPSA id 65A26250075; 
	Fri,  9 Dec 2011 12:21:33 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 82d9d136bad68b0342cbef2d981499d970c85f44
Message-Id: <82d9d136bad68b0342cb.1323462154@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1323462147@xdev.gridcentric.ca>
References: <patchbomb.1323462147@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Fri, 09 Dec 2011 15:22:34 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, keir.xen@gmail.com, tim@xen.org, JBeulich@suse.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 7 of 9] Add the ability to poll stats about
 shared memory via the console
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/ia64/xen/mm.c        |  6 ++++++
 xen/arch/x86/mm/mem_sharing.c |  8 ++++++++
 xen/common/keyhandler.c       |  7 +++++--
 xen/include/xen/mm.h          |  3 +++
 4 files changed, 22 insertions(+), 2 deletions(-)


Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r bba44de8394a -r 82d9d136bad6 xen/arch/ia64/xen/mm.c
--- a/xen/arch/ia64/xen/mm.c
+++ b/xen/arch/ia64/xen/mm.c
@@ -3565,6 +3565,12 @@ p2m_pod_decrease_reservation(struct doma
     return 0;
 }
 
+/* Simple no-op */
+void arch_dump_shared_mem_info(void)
+{
+    printk("Shared memory not supported yet\n");
+}
+
 /*
  * Local variables:
  * mode: C
diff -r bba44de8394a -r 82d9d136bad6 xen/arch/x86/mm/mem_sharing.c
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -1230,6 +1230,14 @@ int mem_sharing_domctl(struct domain *d,
     return rc;
 }
 
+void arch_dump_shared_mem_info(void)
+{
+    printk("Shared pages %u -- Saved frames %u -- Dom CoW footprintf %u\n",
+            mem_sharing_get_nr_shared_mfns(),
+            mem_sharing_get_nr_saved_mfns(),
+            dom_cow->tot_pages);
+}
+
 void __init mem_sharing_init(void)
 {
     printk("Initing memory sharing.\n");
diff -r bba44de8394a -r 82d9d136bad6 xen/common/keyhandler.c
--- a/xen/common/keyhandler.c
+++ b/xen/common/keyhandler.c
@@ -15,6 +15,7 @@
 #include <xen/compat.h>
 #include <xen/ctype.h>
 #include <xen/perfc.h>
+#include <xen/mm.h>
 #include <asm/debugger.h>
 #include <asm/div64.h>
 
@@ -248,8 +249,8 @@ static void dump_domains(unsigned char k
         printk("    refcnt=%d dying=%d pause_count=%d\n",
                atomic_read(&d->refcnt), d->is_dying,
                atomic_read(&d->pause_count));
-        printk("    nr_pages=%d xenheap_pages=%d dirty_cpus=%s max_pages=%u\n",
-               d->tot_pages, d->xenheap_pages, tmpstr, d->max_pages);
+        printk("    nr_pages=%d xenheap_pages=%d shared_pages=%u dirty_cpus=%s max_pages=%u\n",
+               d->tot_pages, d->xenheap_pages, atomic_read(&d->shr_pages), tmpstr, d->max_pages);
         printk("    handle=%02x%02x%02x%02x-%02x%02x-%02x%02x-"
                "%02x%02x-%02x%02x%02x%02x%02x%02x vm_assist=%08lx\n",
                d->handle[ 0], d->handle[ 1], d->handle[ 2], d->handle[ 3],
@@ -308,6 +309,8 @@ static void dump_domains(unsigned char k
         }
     }
 
+    arch_dump_shared_mem_info();
+
     rcu_read_unlock(&domlist_read_lock);
 #undef tmpstr
 }
diff -r bba44de8394a -r 82d9d136bad6 xen/include/xen/mm.h
--- a/xen/include/xen/mm.h
+++ b/xen/include/xen/mm.h
@@ -73,6 +73,9 @@ int assign_pages(
     unsigned int order,
     unsigned int memflags);
 
+/* Dump info to serial console */
+void arch_dump_shared_mem_info(void);
+
 /* memflags: */
 #define _MEMF_no_refcount 0
 #define  MEMF_no_refcount (1U<<_MEMF_no_refcount)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 20:22:39 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 20:22:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZ6xZ-0005jQ-VT; Fri, 09 Dec 2011 20:22:21 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RZ6xY-0005i1-DY
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 20:22:20 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-16.tower-174.messagelabs.com!1323462090!4774948!1
X-Originating-IP: [208.97.132.74]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi43NCA9PiAxNDk1Mw==\n
X-StarScan-Version: 6.4.2; banners=-,-,lists.xensource.com
X-VirusChecked: Checked
Received: (qmail 24116 invoked from network); 9 Dec 2011 20:21:30 -0000
Received: from caiajhbdcahe.dreamhost.com (HELO homiemail-a18.g.dreamhost.com)
	(208.97.132.74) by server-16.tower-174.messagelabs.com with SMTP;
	9 Dec 2011 20:21:30 -0000
Received: from homiemail-a18.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a18.g.dreamhost.com (Postfix) with ESMTP id D0358250069;
	Fri,  9 Dec 2011 12:21:29 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=l+jT+56CJwLQNzBj6ws6Fi9thlCUARp5NnBGQjhqJFbn
	AhAhfbzCk0zWp5XcfyukpCivDzqsszaciuoJBqt5fkUjz21D+OnItKPdPPjkf3it
	6TIfD57VH8mb02oFMcFxrNosdSWcuculWtOeWTVLvwUYyVYachz0EKqxVd9Abb4=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=xHdavJYDNtdZ6Fi9IYfBPl2dFok=; b=jIXGPMzs46a
	IQVXEuS4kCd9IemkMC6NRwxYUnW7jSC7stYvWeDBn0ZkD6cSx0p5yPhUhKmn/PgR
	KDOnujMpamBzaXZfAtU7Jrvea0Gb5kUA8iuH4nv/Z5WHtC/eGK96nXZNF0gag96O
	AE0Q+LS4H2Zt0D2X2cEg5EF7/j2rCBa0=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a18.g.dreamhost.com (Postfix) with ESMTPSA id 09400250079; 
	Fri,  9 Dec 2011 12:21:28 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 4a189125d71e35bd9dbaf549f45584ac99759e1c
Message-Id: <4a189125d71e35bd9dba.1323462150@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1323462147@xdev.gridcentric.ca>
References: <patchbomb.1323462147@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Fri, 09 Dec 2011 15:22:30 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, keir.xen@gmail.com, tim@xen.org, JBeulich@suse.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 3 of 9] x86/mm: Update mem sharing interface to
 (re)allow sharing of grants
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/mm/mem_sharing.c |  57 ++++++++++++++++++++++++++++++++++++------
 xen/include/public/domctl.h   |   9 ++++++
 2 files changed, 57 insertions(+), 9 deletions(-)


Previosuly, the mem sharing code would return an opaque handle
to index shared pages (and nominees) in its global hash table.
By removing the hash table, the new interfaces requires a gfn
and a version. However, when sharing grants, the caller only
has a grant ref and a version. Update interface to handle this
case.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 4862cca21d3c -r 4a189125d71e xen/arch/x86/mm/mem_sharing.c
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -770,18 +770,57 @@ int mem_sharing_domctl(struct domain *d,
 
         case XEN_DOMCTL_MEM_EVENT_OP_SHARING_SHARE:
         {
-            unsigned long sgfn  = mec->u.share.source_gfn;
-            shr_handle_t sh     = mec->u.share.source_handle;
-            struct domain *cd   = get_domain_by_id(mec->u.share.client_domain);
-            if ( cd )
+            unsigned long sgfn, cgfn;
+            struct domain *cd;
+            shr_handle_t sh, ch;
+
+            if ( !mem_sharing_enabled(d) )
+                return -EINVAL;
+
+            cd = get_domain_by_id(mec->u.share.client_domain);
+            if ( !cd )
+                return -ESRCH;
+
+            if ( !mem_sharing_enabled(cd) )
             {
-                unsigned long cgfn  = mec->u.share.client_gfn;
-                shr_handle_t ch     = mec->u.share.client_handle;
-                rc = mem_sharing_share_pages(d, sgfn, sh, cd, cgfn, ch); 
                 put_domain(cd);
+                return -EINVAL;
             }
-            else
-                return -EEXIST;
+
+            if ( XEN_DOMCTL_MEM_SHARING_FIELD_IS_GREF(mec->u.share.source_gfn) )
+            {
+                grant_ref_t gref = (grant_ref_t) 
+                                    (XEN_DOMCTL_MEM_SHARING_FIELD_GET_GREF(
+                                        mec->u.share.source_gfn));
+                if ( mem_sharing_gref_to_gfn(d, gref, &sgfn) < 0 )
+                {
+                    put_domain(cd);
+                    return -EINVAL;
+                }
+            } else {
+                sgfn  = mec->u.share.source_gfn;
+            }
+
+            if ( XEN_DOMCTL_MEM_SHARING_FIELD_IS_GREF(mec->u.share.client_gfn) )
+            {
+                grant_ref_t gref = (grant_ref_t) 
+                                    (XEN_DOMCTL_MEM_SHARING_FIELD_GET_GREF(
+                                        mec->u.share.client_gfn));
+                if ( mem_sharing_gref_to_gfn(cd, gref, &cgfn) < 0 )
+                {
+                    put_domain(cd);
+                    return -EINVAL;
+                }
+            } else {
+                cgfn  = mec->u.share.client_gfn;
+            }
+
+            sh = mec->u.share.source_handle;
+            ch = mec->u.share.client_handle;
+
+            rc = mem_sharing_share_pages(d, sgfn, sh, cd, cgfn, ch); 
+
+            put_domain(cd);
         }
         break;
 
diff -r 4862cca21d3c -r 4a189125d71e xen/include/public/domctl.h
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -775,6 +775,15 @@ DEFINE_XEN_GUEST_HANDLE(xen_domctl_mem_e
 #define XEN_DOMCTL_MEM_SHARING_S_HANDLE_INVALID  (-10)
 #define XEN_DOMCTL_MEM_SHARING_C_HANDLE_INVALID  (-9)
 
+#define XEN_DOMCTL_MEM_SHARING_FIELD_IS_GREF_FLAG   (1ULL << 62)
+
+#define XEN_DOMCTL_MEM_SHARING_FIELD_MAKE_GREF(field, val)  \
+    (field) = (XEN_DOMCTL_MEM_SHARING_FIELD_IS_GREF_FLAG | val)
+#define XEN_DOMCTL_MEM_SHARING_FIELD_IS_GREF(field)         \
+    ((field) & XEN_DOMCTL_MEM_SHARING_FIELD_IS_GREF_FLAG)
+#define XEN_DOMCTL_MEM_SHARING_FIELD_GET_GREF(field)        \
+    ((field) & (~XEN_DOMCTL_MEM_SHARING_FIELD_IS_GREF_FLAG))
+
 struct xen_domctl_mem_sharing_op {
     uint8_t op; /* XEN_DOMCTL_MEM_EVENT_OP_* */
 

______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
______________________________________________________________________

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 20:22:39 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 20:22:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZ6xZ-0005jQ-VT; Fri, 09 Dec 2011 20:22:21 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RZ6xY-0005i1-DY
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 20:22:20 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-16.tower-174.messagelabs.com!1323462090!4774948!1
X-Originating-IP: [208.97.132.74]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi43NCA9PiAxNDk1Mw==\n
X-StarScan-Version: 6.4.2; banners=-,-,lists.xensource.com
X-VirusChecked: Checked
Received: (qmail 24116 invoked from network); 9 Dec 2011 20:21:30 -0000
Received: from caiajhbdcahe.dreamhost.com (HELO homiemail-a18.g.dreamhost.com)
	(208.97.132.74) by server-16.tower-174.messagelabs.com with SMTP;
	9 Dec 2011 20:21:30 -0000
Received: from homiemail-a18.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a18.g.dreamhost.com (Postfix) with ESMTP id D0358250069;
	Fri,  9 Dec 2011 12:21:29 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=l+jT+56CJwLQNzBj6ws6Fi9thlCUARp5NnBGQjhqJFbn
	AhAhfbzCk0zWp5XcfyukpCivDzqsszaciuoJBqt5fkUjz21D+OnItKPdPPjkf3it
	6TIfD57VH8mb02oFMcFxrNosdSWcuculWtOeWTVLvwUYyVYachz0EKqxVd9Abb4=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=xHdavJYDNtdZ6Fi9IYfBPl2dFok=; b=jIXGPMzs46a
	IQVXEuS4kCd9IemkMC6NRwxYUnW7jSC7stYvWeDBn0ZkD6cSx0p5yPhUhKmn/PgR
	KDOnujMpamBzaXZfAtU7Jrvea0Gb5kUA8iuH4nv/Z5WHtC/eGK96nXZNF0gag96O
	AE0Q+LS4H2Zt0D2X2cEg5EF7/j2rCBa0=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a18.g.dreamhost.com (Postfix) with ESMTPSA id 09400250079; 
	Fri,  9 Dec 2011 12:21:28 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 4a189125d71e35bd9dbaf549f45584ac99759e1c
Message-Id: <4a189125d71e35bd9dba.1323462150@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1323462147@xdev.gridcentric.ca>
References: <patchbomb.1323462147@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Fri, 09 Dec 2011 15:22:30 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, keir.xen@gmail.com, tim@xen.org, JBeulich@suse.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 3 of 9] x86/mm: Update mem sharing interface to
 (re)allow sharing of grants
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/mm/mem_sharing.c |  57 ++++++++++++++++++++++++++++++++++++------
 xen/include/public/domctl.h   |   9 ++++++
 2 files changed, 57 insertions(+), 9 deletions(-)


Previosuly, the mem sharing code would return an opaque handle
to index shared pages (and nominees) in its global hash table.
By removing the hash table, the new interfaces requires a gfn
and a version. However, when sharing grants, the caller only
has a grant ref and a version. Update interface to handle this
case.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 4862cca21d3c -r 4a189125d71e xen/arch/x86/mm/mem_sharing.c
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -770,18 +770,57 @@ int mem_sharing_domctl(struct domain *d,
 
         case XEN_DOMCTL_MEM_EVENT_OP_SHARING_SHARE:
         {
-            unsigned long sgfn  = mec->u.share.source_gfn;
-            shr_handle_t sh     = mec->u.share.source_handle;
-            struct domain *cd   = get_domain_by_id(mec->u.share.client_domain);
-            if ( cd )
+            unsigned long sgfn, cgfn;
+            struct domain *cd;
+            shr_handle_t sh, ch;
+
+            if ( !mem_sharing_enabled(d) )
+                return -EINVAL;
+
+            cd = get_domain_by_id(mec->u.share.client_domain);
+            if ( !cd )
+                return -ESRCH;
+
+            if ( !mem_sharing_enabled(cd) )
             {
-                unsigned long cgfn  = mec->u.share.client_gfn;
-                shr_handle_t ch     = mec->u.share.client_handle;
-                rc = mem_sharing_share_pages(d, sgfn, sh, cd, cgfn, ch); 
                 put_domain(cd);
+                return -EINVAL;
             }
-            else
-                return -EEXIST;
+
+            if ( XEN_DOMCTL_MEM_SHARING_FIELD_IS_GREF(mec->u.share.source_gfn) )
+            {
+                grant_ref_t gref = (grant_ref_t) 
+                                    (XEN_DOMCTL_MEM_SHARING_FIELD_GET_GREF(
+                                        mec->u.share.source_gfn));
+                if ( mem_sharing_gref_to_gfn(d, gref, &sgfn) < 0 )
+                {
+                    put_domain(cd);
+                    return -EINVAL;
+                }
+            } else {
+                sgfn  = mec->u.share.source_gfn;
+            }
+
+            if ( XEN_DOMCTL_MEM_SHARING_FIELD_IS_GREF(mec->u.share.client_gfn) )
+            {
+                grant_ref_t gref = (grant_ref_t) 
+                                    (XEN_DOMCTL_MEM_SHARING_FIELD_GET_GREF(
+                                        mec->u.share.client_gfn));
+                if ( mem_sharing_gref_to_gfn(cd, gref, &cgfn) < 0 )
+                {
+                    put_domain(cd);
+                    return -EINVAL;
+                }
+            } else {
+                cgfn  = mec->u.share.client_gfn;
+            }
+
+            sh = mec->u.share.source_handle;
+            ch = mec->u.share.client_handle;
+
+            rc = mem_sharing_share_pages(d, sgfn, sh, cd, cgfn, ch); 
+
+            put_domain(cd);
         }
         break;
 
diff -r 4862cca21d3c -r 4a189125d71e xen/include/public/domctl.h
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -775,6 +775,15 @@ DEFINE_XEN_GUEST_HANDLE(xen_domctl_mem_e
 #define XEN_DOMCTL_MEM_SHARING_S_HANDLE_INVALID  (-10)
 #define XEN_DOMCTL_MEM_SHARING_C_HANDLE_INVALID  (-9)
 
+#define XEN_DOMCTL_MEM_SHARING_FIELD_IS_GREF_FLAG   (1ULL << 62)
+
+#define XEN_DOMCTL_MEM_SHARING_FIELD_MAKE_GREF(field, val)  \
+    (field) = (XEN_DOMCTL_MEM_SHARING_FIELD_IS_GREF_FLAG | val)
+#define XEN_DOMCTL_MEM_SHARING_FIELD_IS_GREF(field)         \
+    ((field) & XEN_DOMCTL_MEM_SHARING_FIELD_IS_GREF_FLAG)
+#define XEN_DOMCTL_MEM_SHARING_FIELD_GET_GREF(field)        \
+    ((field) & (~XEN_DOMCTL_MEM_SHARING_FIELD_IS_GREF_FLAG))
+
 struct xen_domctl_mem_sharing_op {
     uint8_t op; /* XEN_DOMCTL_MEM_EVENT_OP_* */
 

______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
______________________________________________________________________

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 20:22:39 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 20:22:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZ6xY-0005iy-D2; Fri, 09 Dec 2011 20:22:20 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RZ6xW-0005i4-Rj
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 20:22:19 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-9.tower-27.messagelabs.com!1323462055!56089792!1
X-Originating-IP: [208.97.132.145]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNDUgPT4gMTczNjI=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1439 invoked from network); 9 Dec 2011 20:20:55 -0000
Received: from caiajhbdcbef.dreamhost.com (HELO homiemail-a18.g.dreamhost.com)
	(208.97.132.145) by server-9.tower-27.messagelabs.com with SMTP;
	9 Dec 2011 20:20:55 -0000
Received: from homiemail-a18.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a18.g.dreamhost.com (Postfix) with ESMTP id 8BB39250074;
	Fri,  9 Dec 2011 12:21:27 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=ptxFAtixNj6a5Zfa06zVucaBSO/7xhjf4jEAccopH2BA
	tu30A9BmcPTW75du3s4uCGXj6+WglbMUVFZzf6GzjEhCsEkLoRKBz2GKcosqVgmn
	kxAUR19yxDsB+OwIWlqEGjmgLp3m0NDmn/8Z0re5U2vYBh6TeJha403TpshodRs=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=z8TSkFSfTQavq8/ehghdtZ9egOs=; b=YhyZK4F9aKW
	lPdvmon0+WeLSpxVsgjzULoqbFkgkHIF236dQXZUzqMyphBusdJ2M45MZxRltqL1
	SNNOp/jAonQhce24vQpR71OcWTiw/jjn9b5X5kVjPCk2kHuHp9ogE75aRNj6YmJx
	gMJJGvcaWxFXxOT5aoubk/K8XXvE0yvw=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a18.g.dreamhost.com (Postfix) with ESMTPSA id 991F125006B; 
	Fri,  9 Dec 2011 12:21:26 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: d29cba447de1fe6b788e5f543191990de39c193c
Message-Id: <d29cba447de1fe6b788e.1323462148@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1323462147@xdev.gridcentric.ca>
References: <patchbomb.1323462147@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Fri, 09 Dec 2011 15:22:28 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, keir.xen@gmail.com, tim@xen.org, JBeulich@suse.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 1 of 9] x86/mm: Code style fixes in mem_sharing.c
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/mm.c             |   6 +-
 xen/arch/x86/mm/mem_sharing.c |  91 ++++++++++++++++++++++--------------------
 2 files changed, 50 insertions(+), 47 deletions(-)


No functional changes, only code style issues.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r f232d335de98 -r d29cba447de1 xen/arch/x86/mm.c
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -4321,9 +4321,9 @@ int page_make_sharable(struct domain *d,
         return -EEXIST;
     }
 
-    /* Check if the ref count is 2. The first from PGT_allocated, and
+    /* Check if the ref count is 2. The first from PGC_allocated, and
      * the second from get_page_and_type at the top of this function */
-    if(page->count_info != (PGC_allocated | (2 + expected_refcnt)))
+    if ( page->count_info != (PGC_allocated | (2 + expected_refcnt)) )
     {
         /* Return type count back to zero */
         put_page_and_type(page);
@@ -4340,7 +4340,7 @@ int page_make_sharable(struct domain *d,
 
 int page_make_private(struct domain *d, struct page_info *page)
 {
-    if(!get_page(page, dom_cow))
+    if ( !get_page(page, dom_cow) )
         return -EINVAL;
     
     spin_lock(&d->page_alloc_lock);
diff -r f232d335de98 -r d29cba447de1 xen/arch/x86/mm/mem_sharing.c
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -35,14 +35,14 @@
 #include "mm-locks.h"
 
 /* Auditing of memory sharing code? */
-#define MEM_SHARING_AUDIT  0
+#define MEM_SHARING_AUDIT 0
 
 #if MEM_SHARING_AUDIT
 static void mem_sharing_audit(void);
 #define MEM_SHARING_DEBUG(_f, _a...)                                  \
     debugtrace_printk("mem_sharing_debug: %s(): " _f, __func__, ##_a)
 #else
-# define mem_sharing_audit() do {} while(0)
+#define mem_sharing_audit() do {} while(0)
 #endif /* MEM_SHARING_AUDIT */
 
 #define mem_sharing_enabled(d) \
@@ -56,7 +56,7 @@ static void mem_sharing_audit(void);
 #define page_to_mfn(_pg) _mfn(__page_to_mfn(_pg))
 
 static shr_handle_t next_handle = 1;
-static atomic_t nr_saved_mfns = ATOMIC_INIT(0); 
+static atomic_t nr_saved_mfns   = ATOMIC_INIT(0); 
 
 typedef struct shr_hash_entry 
 {
@@ -84,9 +84,9 @@ static inline int list_has_one_entry(str
     return (head->next != head) && (head->next->next == head);
 }
 
-static inline struct gfn_info* gfn_get_info(struct list_head *list)
+static inline gfn_info_t *gfn_get_info(struct list_head *list)
 {
-    return list_entry(list->next, struct gfn_info, list);
+    return list_entry(list->next, gfn_info_t, list);
 }
 
 static void __init mem_sharing_hash_init(void)
@@ -116,12 +116,12 @@ static gfn_info_t *mem_sharing_gfn_alloc
 static void mem_sharing_gfn_destroy(gfn_info_t *gfn, int was_shared)
 {
     /* Decrement the number of pages, if the gfn was shared before */
-    if(was_shared)
+    if ( was_shared )
     {
         struct domain *d = get_domain_by_id(gfn->domain);
-        /* Domain may have been destroyed by now, if we are called from
-         * p2m_teardown */
-        if(d)
+        /* Domain may have been destroyed by now *
+         * (if we are called from p2m_teardown)  */
+        if ( d )
         {
             atomic_dec(&d->shr_pages);
             put_domain(d);
@@ -261,7 +261,8 @@ static struct page_info* mem_sharing_all
     mem_event_request_t req;
 
     page = alloc_domheap_page(d, 0); 
-    if(page != NULL) return page;
+    if ( page != NULL )
+        return page;
 
     memset(&req, 0, sizeof(req));
     req.type = MEM_EVENT_TYPE_SHARED;
@@ -293,7 +294,7 @@ static struct page_info* mem_sharing_all
 
 unsigned int mem_sharing_get_nr_saved_mfns(void)
 {
-    return (unsigned int)atomic_read(&nr_saved_mfns);
+    return ((unsigned int)atomic_read(&nr_saved_mfns));
 }
 
 int mem_sharing_sharing_resume(struct domain *d)
@@ -317,14 +318,15 @@ int mem_sharing_debug_mfn(unsigned long 
 {
     struct page_info *page;
 
-    if(!mfn_valid(_mfn(mfn)))
+    if ( !mfn_valid(_mfn(mfn)) )
     {
-        printk("Invalid MFN=%lx\n", mfn);
+        gdprintk(XENLOG_ERR, "Invalid MFN=%lx\n", mfn);
         return -1;
     }
     page = mfn_to_page(_mfn(mfn));
 
-    printk("Debug page: MFN=%lx is ci=%lx, ti=%lx, owner_id=%d\n",
+    gdprintk(XENLOG_DEBUG, 
+            "Debug page: MFN=%lx is ci=%lx, ti=%lx, owner_id=%d\n",
             mfn_x(page_to_mfn(page)), 
             page->count_info, 
             page->u.inuse.type_info,
@@ -340,9 +342,9 @@ int mem_sharing_debug_gfn(struct domain 
 
     mfn = get_gfn_unlocked(d, gfn, &p2mt);
 
-    printk("Debug for domain=%d, gfn=%lx, ", 
-            d->domain_id, 
-            gfn);
+    gdprintk(XENLOG_DEBUG, "Debug for domain=%d, gfn=%lx, ", 
+               d->domain_id, 
+               gfn);
     return mem_sharing_debug_mfn(mfn_x(mfn));
 }
 
@@ -359,8 +361,8 @@ int mem_sharing_debug_gfn(struct domain 
 static grant_entry_header_t *
 shared_entry_header(struct grant_table *t, grant_ref_t ref)
 {
-    ASSERT(t->gt_version != 0);
-    if (t->gt_version == 1)
+    ASSERT (t->gt_version != 0);
+    if ( t->gt_version == 1 )
         return (grant_entry_header_t*)&shared_entry_v1(t, ref);
     else
         return &shared_entry_v2(t, ref).hdr;
@@ -370,25 +372,23 @@ static int mem_sharing_gref_to_gfn(struc
                                    grant_ref_t ref, 
                                    unsigned long *gfn)
 {
-    if(d->grant_table->gt_version < 1)
+    if ( d->grant_table->gt_version < 1 )
         return -1;
 
-    if (d->grant_table->gt_version == 1) 
+    if ( d->grant_table->gt_version == 1 ) 
     {
         grant_entry_v1_t *sha1;
         sha1 = &shared_entry_v1(d->grant_table, ref);
         *gfn = sha1->frame;
-        return 0;
     } 
     else 
     {
         grant_entry_v2_t *sha2;
         sha2 = &shared_entry_v2(d->grant_table, ref);
         *gfn = sha2->full_page.frame;
-        return 0;
     }
  
-    return -2;
+    return 0;
 }
 
 /* Account for a GFN being shared/unshared.
@@ -428,20 +428,22 @@ int mem_sharing_debug_gref(struct domain
     uint16_t status;
     unsigned long gfn;
 
-    if(d->grant_table->gt_version < 1)
+    if ( d->grant_table->gt_version < 1 )
     {
-        printk("Asked to debug [dom=%d,gref=%d], but not yet inited.\n",
+        gdprintk(XENLOG_ERR, 
+                "Asked to debug [dom=%d,gref=%d], but not yet inited.\n",
                 d->domain_id, ref);
         return -1;
     }
-    mem_sharing_gref_to_gfn(d, ref, &gfn); 
+    (void)mem_sharing_gref_to_gfn(d, ref, &gfn); 
     shah = shared_entry_header(d->grant_table, ref);
-    if (d->grant_table->gt_version == 1) 
+    if ( d->grant_table->gt_version == 1 ) 
         status = shah->flags;
     else 
         status = status_entry(d->grant_table, ref);
     
-    printk("==> Grant [dom=%d,ref=%d], status=%x. ", 
+    gdprintk(XENLOG_DEBUG,
+            "==> Grant [dom=%d,ref=%d], status=%x. ", 
             d->domain_id, ref, status);
 
     return mem_sharing_debug_gfn(d, gfn); 
@@ -467,24 +469,24 @@ int mem_sharing_nominate_page(struct dom
 
     /* Check if mfn is valid */
     ret = -EINVAL;
-    if (!mfn_valid(mfn))
+    if ( !mfn_valid(mfn) )
         goto out;
 
     /* Return the handle if the page is already shared */
     page = mfn_to_page(mfn);
-    if (p2m_is_shared(p2mt)) {
+    if ( p2m_is_shared(p2mt) ) {
         *phandle = page->shr_handle;
         ret = 0;
         goto out;
     }
 
     /* Check p2m type */
-    if (!p2m_is_sharable(p2mt))
+    if ( !p2m_is_sharable(p2mt) )
         goto out;
 
     /* Try to convert the mfn to the sharable type */
     ret = page_make_sharable(d, page, expected_refcnt); 
-    if(ret) 
+    if ( ret ) 
         goto out;
 
     /* Create the handle */
@@ -501,7 +503,7 @@ int mem_sharing_nominate_page(struct dom
     }
 
     /* Change the p2m type */
-    if(p2m_change_type(d, gfn, p2mt, p2m_ram_shared) != p2mt) 
+    if ( p2m_change_type(d, gfn, p2mt, p2m_ram_shared) != p2mt ) 
     {
         /* This is unlikely, as the type must have changed since we've checked
          * it a few lines above.
@@ -607,7 +609,7 @@ int mem_sharing_unshare_page(struct doma
     mfn = get_gfn(d, gfn, &p2mt);
     
     /* Has someone already unshared it? */
-    if (!p2m_is_shared(p2mt)) {
+    if ( !p2m_is_shared(p2mt) ) {
         put_gfn(d, gfn);
         shr_unlock();
         return 0;
@@ -620,10 +622,11 @@ int mem_sharing_unshare_page(struct doma
     list_for_each(le, &hash_entry->gfns)
     {
         gfn_info = list_entry(le, struct gfn_info, list);
-        if((gfn_info->gfn == gfn) && (gfn_info->domain == d->domain_id))
+        if ( (gfn_info->gfn == gfn) && (gfn_info->domain == d->domain_id) )
             goto gfn_found;
     }
-    printk("Could not find gfn_info for shared gfn: %lx\n", gfn);
+    gdprintk(XENLOG_ERR, "Could not find gfn_info for shared gfn: "
+                            "%lx\n", gfn);
     BUG();
 gfn_found: 
     /* Delete gfn_info from the list, but hold on to it, until we've allocated
@@ -633,7 +636,7 @@ gfn_found:
 
     /* If the GFN is getting destroyed drop the references to MFN 
      * (possibly freeing the page), and exit early */
-    if(flags & MEM_SHARING_DESTROY_GFN)
+    if ( flags & MEM_SHARING_DESTROY_GFN )
     {
         mem_sharing_gfn_destroy(gfn_info, !last_gfn);
         if(last_gfn) 
@@ -691,8 +694,8 @@ private_page_found:
     else
         atomic_dec(&nr_saved_mfns);
 
-    if(p2m_change_type(d, gfn, p2m_ram_shared, p2m_ram_rw) != 
-                                                p2m_ram_shared) 
+    if ( p2m_change_type(d, gfn, p2m_ram_shared, p2m_ram_rw) != 
+                                                p2m_ram_shared ) 
     {
         printk("Could not change p2m type.\n");
         BUG();
@@ -729,7 +732,7 @@ int mem_sharing_domctl(struct domain *d,
         {
             unsigned long gfn = mec->u.nominate.u.gfn;
             shr_handle_t handle;
-            if(!mem_sharing_enabled(d))
+            if ( !mem_sharing_enabled(d) )
                 return -EINVAL;
             rc = mem_sharing_nominate_page(d, gfn, 0, &handle);
             mec->u.nominate.handle = handle;
@@ -742,9 +745,9 @@ int mem_sharing_domctl(struct domain *d,
             unsigned long gfn;
             shr_handle_t handle;
 
-            if(!mem_sharing_enabled(d))
+            if ( !mem_sharing_enabled(d) )
                 return -EINVAL;
-            if(mem_sharing_gref_to_gfn(d, gref, &gfn) < 0)
+            if ( mem_sharing_gref_to_gfn(d, gref, &gfn) < 0 )
                 return -EINVAL;
             rc = mem_sharing_nominate_page(d, gfn, 3, &handle);
             mec->u.nominate.handle = handle;
@@ -761,7 +764,7 @@ int mem_sharing_domctl(struct domain *d,
 
         case XEN_DOMCTL_MEM_EVENT_OP_SHARING_RESUME:
         {
-            if(!mem_sharing_enabled(d))
+            if ( !mem_sharing_enabled(d) )
                 return -EINVAL;
             rc = mem_sharing_sharing_resume(d);
         }

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 20:22:39 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 20:22:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZ6xa-0005jp-Ju; Fri, 09 Dec 2011 20:22:22 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RZ6xY-0005i6-Vm
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 20:22:21 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-10.tower-216.messagelabs.com!1323462089!6759091!2
X-Originating-IP: [208.97.132.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMDguOTcuMTMyLjgxID0+IDE3MzQ2\n,sa_preprocessor: 
	QmFkIElQOiAyMDguOTcuMTMyLjgxID0+IDE3MzQ2\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26468 invoked from network); 9 Dec 2011 20:21:31 -0000
Received: from caiajhbdcaib.dreamhost.com (HELO homiemail-a18.g.dreamhost.com)
	(208.97.132.81) by server-10.tower-216.messagelabs.com with SMTP;
	9 Dec 2011 20:21:31 -0000
Received: from homiemail-a18.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a18.g.dreamhost.com (Postfix) with ESMTP id AB5AE25006C;
	Fri,  9 Dec 2011 12:21:30 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=CJbeb4/ITpoG+16M6DftadChkR4Y/i0Irpmx4Vj31Qoy
	kdyC3K4OXO54h3OzHn69d0WKbvE7xty/yWJMKdHwBIROr4d64f2v6XRqfPdWk/Xj
	DeMA7vhoFtKfJllbgd0YtnlbId1PdoFMFQqDeTAhgwsMkmklwDfwZG4Im/JCRKs=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=PlaWS/RNVaBTD3c6CT2l2sBdPaA=; b=KjLVxLaaZsr
	s2NsVIsLqkv4f9C2NK/tJT2xphHBD2CGVEXjTrlr/WXWsaGFU/nGDCknqFIihbjI
	+ZtjwVAsJPVxQvQMDviCySRgF8UU7FI/wZ8wGvSuuI0Fow0Vl5ieHiJIjel+vH7/
	wENbthwjpFJQs6uWdNeokQqudWue/23U=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a18.g.dreamhost.com (Postfix) with ESMTPSA id 09BD625006B; 
	Fri,  9 Dec 2011 12:21:29 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: dbfabd1bbfb1bdc11d98f305c97d50265bda61a1
Message-Id: <dbfabd1bbfb1bdc11d98.1323462151@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1323462147@xdev.gridcentric.ca>
References: <patchbomb.1323462147@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Fri, 09 Dec 2011 15:22:31 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, keir.xen@gmail.com, tim@xen.org, JBeulich@suse.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 4 of 9] x86/mm: Check how many mfns are shared,
 in addition to how many are saved
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/mm.c                 |   6 ------
 xen/arch/x86/mm/mem_sharing.c     |  29 +++++++++++++++++++++++++++++
 xen/arch/x86/x86_64/compat/mm.c   |   6 ++++++
 xen/arch/x86/x86_64/mm.c          |   7 +++++++
 xen/include/asm-x86/mem_sharing.h |   1 +
 xen/include/public/memory.h       |   1 +
 6 files changed, 44 insertions(+), 6 deletions(-)


This patch also moves the existing sharing-related memory op to the
correct location, and adds logic to the audit() method that uses the
new information.

This patch only provides the Xen implementation of the domctls.

Signed-off-by: Andres Lagar-Cavilla <andres@scannell.ca>
Signed-off-by: Adin Scannell <adin@scannell.ca>

diff -r 4a189125d71e -r dbfabd1bbfb1 xen/arch/x86/mm.c
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -119,7 +119,6 @@
 #include <xen/trace.h>
 #include <asm/setup.h>
 #include <asm/fixmap.h>
-#include <asm/mem_sharing.h>
 
 /*
  * Mapping of first 2 or 4 megabytes of memory. This is mapped with 4kB
@@ -5093,11 +5092,6 @@ long arch_memory_op(int op, XEN_GUEST_HA
         return rc;
     }
 
-#ifdef __x86_64__
-    case XENMEM_get_sharing_freed_pages:
-        return mem_sharing_get_nr_saved_mfns();
-#endif
-
     default:
         return subarch_memory_op(op, arg);
     }
diff -r 4a189125d71e -r dbfabd1bbfb1 xen/arch/x86/mm/mem_sharing.c
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -72,6 +72,7 @@ static inline int mem_sharing_audit(void
 
 static shr_handle_t next_handle = 1;
 static atomic_t nr_saved_mfns   = ATOMIC_INIT(0); 
+static atomic_t nr_shared_mfns  = ATOMIC_INIT(0);
 
 typedef struct gfn_info
 {
@@ -150,9 +151,12 @@ static struct page_info* mem_sharing_loo
 static int mem_sharing_audit(void)
 {
     int errors = 0;
+    unsigned long count_expected;
+    unsigned long count_found = 0;
     struct list_head *ae;
 
     ASSERT(shr_locked_by_me());
+    count_expected = atomic_read(&nr_shared_mfns);
 
     list_for_each(ae, &shr_audit_list)
     {
@@ -200,6 +204,10 @@ static int mem_sharing_audit(void)
            continue;
         }
 
+        /* Only increase our expected count for pages that are actually shared */
+        if ( !list_has_one_entry(&pg->shared_info->gfns) )
+            count_found++;
+
         /* Check if all GFNs map to the MFN, and the p2m types */
         list_for_each(le, &pg->shared_info->gfns)
         {
@@ -245,6 +253,13 @@ static int mem_sharing_audit(void)
         }
     }
 
+    if ( count_found != count_expected )
+    {
+        MEM_SHARING_DEBUG("Expected %ld shared mfns, found %ld.",
+                          count_expected, count_found);
+        errors++;
+    }
+
     return errors;
 }
 #endif
@@ -294,6 +309,11 @@ unsigned int mem_sharing_get_nr_saved_mf
     return ((unsigned int)atomic_read(&nr_saved_mfns));
 }
 
+unsigned int mem_sharing_get_nr_shared_mfns(void)
+{
+    return (unsigned int)atomic_read(&nr_shared_mfns);
+}
+
 int mem_sharing_sharing_resume(struct domain *d)
 {
     mem_event_response_t rsp;
@@ -577,6 +597,14 @@ int mem_sharing_share_pages(struct domai
     ASSERT(list_empty(&cpage->shared_info->gfns));
     if ( single_source_gfn )
         atomic_inc(&sd->shr_pages);
+    /* We only increase the number of shared pages when 
+     * sharing for the first time */
+    if ( single_source_gfn && single_client_gfn )
+        atomic_inc(&nr_shared_mfns);
+    /* And we decrease it when re-sharing already shared
+     * (because one of them becomes a "saved" page). */
+    if ( !single_source_gfn && !single_client_gfn )
+        atomic_dec(&nr_shared_mfns);
 
     /* Clear the rest of the shared state */
     audit_del_list(cpage);
@@ -659,6 +687,7 @@ gfn_found:
             BUG_ON(!d);
             atomic_dec(&d->shr_pages);
             put_domain(d);
+            atomic_dec(&nr_shared_mfns);
         }
     } else {
         /* Clean up shared state */
diff -r 4a189125d71e -r dbfabd1bbfb1 xen/arch/x86/x86_64/compat/mm.c
--- a/xen/arch/x86/x86_64/compat/mm.c
+++ b/xen/arch/x86/x86_64/compat/mm.c
@@ -205,6 +205,12 @@ int compat_arch_memory_op(int op, XEN_GU
         break;
     }
 
+    case XENMEM_get_sharing_freed_pages:
+        return mem_sharing_get_nr_saved_mfns();
+
+    case XENMEM_get_sharing_shared_pages:
+        return mem_sharing_get_nr_shared_mfns();
+
     default:
         rc = -ENOSYS;
         break;
diff -r 4a189125d71e -r dbfabd1bbfb1 xen/arch/x86/x86_64/mm.c
--- a/xen/arch/x86/x86_64/mm.c
+++ b/xen/arch/x86/x86_64/mm.c
@@ -34,6 +34,7 @@
 #include <asm/msr.h>
 #include <asm/setup.h>
 #include <asm/numa.h>
+#include <asm/mem_sharing.h>
 #include <public/memory.h>
 
 /* Parameters for PFN/MADDR compression. */
@@ -1090,6 +1091,12 @@ long subarch_memory_op(int op, XEN_GUEST
 
         break;
 
+    case XENMEM_get_sharing_freed_pages:
+        return mem_sharing_get_nr_saved_mfns();
+
+    case XENMEM_get_sharing_shared_pages:
+        return mem_sharing_get_nr_shared_mfns();
+
     default:
         rc = -ENOSYS;
         break;
diff -r 4a189125d71e -r dbfabd1bbfb1 xen/include/asm-x86/mem_sharing.h
--- a/xen/include/asm-x86/mem_sharing.h
+++ b/xen/include/asm-x86/mem_sharing.h
@@ -45,6 +45,7 @@ struct page_sharing_info
     (is_hvm_domain(_d) && paging_mode_hap(_d)) 
 
 unsigned int mem_sharing_get_nr_saved_mfns(void);
+unsigned int mem_sharing_get_nr_shared_mfns(void);
 int mem_sharing_nominate_page(struct domain *d, 
                               unsigned long gfn,
                               int expected_refcnt,
diff -r 4a189125d71e -r dbfabd1bbfb1 xen/include/public/memory.h
--- a/xen/include/public/memory.h
+++ b/xen/include/public/memory.h
@@ -294,6 +294,7 @@ typedef struct xen_pod_target xen_pod_ta
  * The call never fails. 
  */
 #define XENMEM_get_sharing_freed_pages    18
+#define XENMEM_get_sharing_shared_pages   19
 
 #endif /* __XEN_PUBLIC_MEMORY_H__ */
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 20:22:39 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 20:22:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZ6xa-0005jp-Ju; Fri, 09 Dec 2011 20:22:22 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RZ6xY-0005i6-Vm
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 20:22:21 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-10.tower-216.messagelabs.com!1323462089!6759091!2
X-Originating-IP: [208.97.132.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMDguOTcuMTMyLjgxID0+IDE3MzQ2\n,sa_preprocessor: 
	QmFkIElQOiAyMDguOTcuMTMyLjgxID0+IDE3MzQ2\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26468 invoked from network); 9 Dec 2011 20:21:31 -0000
Received: from caiajhbdcaib.dreamhost.com (HELO homiemail-a18.g.dreamhost.com)
	(208.97.132.81) by server-10.tower-216.messagelabs.com with SMTP;
	9 Dec 2011 20:21:31 -0000
Received: from homiemail-a18.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a18.g.dreamhost.com (Postfix) with ESMTP id AB5AE25006C;
	Fri,  9 Dec 2011 12:21:30 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=CJbeb4/ITpoG+16M6DftadChkR4Y/i0Irpmx4Vj31Qoy
	kdyC3K4OXO54h3OzHn69d0WKbvE7xty/yWJMKdHwBIROr4d64f2v6XRqfPdWk/Xj
	DeMA7vhoFtKfJllbgd0YtnlbId1PdoFMFQqDeTAhgwsMkmklwDfwZG4Im/JCRKs=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=PlaWS/RNVaBTD3c6CT2l2sBdPaA=; b=KjLVxLaaZsr
	s2NsVIsLqkv4f9C2NK/tJT2xphHBD2CGVEXjTrlr/WXWsaGFU/nGDCknqFIihbjI
	+ZtjwVAsJPVxQvQMDviCySRgF8UU7FI/wZ8wGvSuuI0Fow0Vl5ieHiJIjel+vH7/
	wENbthwjpFJQs6uWdNeokQqudWue/23U=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a18.g.dreamhost.com (Postfix) with ESMTPSA id 09BD625006B; 
	Fri,  9 Dec 2011 12:21:29 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: dbfabd1bbfb1bdc11d98f305c97d50265bda61a1
Message-Id: <dbfabd1bbfb1bdc11d98.1323462151@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1323462147@xdev.gridcentric.ca>
References: <patchbomb.1323462147@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Fri, 09 Dec 2011 15:22:31 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, keir.xen@gmail.com, tim@xen.org, JBeulich@suse.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 4 of 9] x86/mm: Check how many mfns are shared,
 in addition to how many are saved
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/mm.c                 |   6 ------
 xen/arch/x86/mm/mem_sharing.c     |  29 +++++++++++++++++++++++++++++
 xen/arch/x86/x86_64/compat/mm.c   |   6 ++++++
 xen/arch/x86/x86_64/mm.c          |   7 +++++++
 xen/include/asm-x86/mem_sharing.h |   1 +
 xen/include/public/memory.h       |   1 +
 6 files changed, 44 insertions(+), 6 deletions(-)


This patch also moves the existing sharing-related memory op to the
correct location, and adds logic to the audit() method that uses the
new information.

This patch only provides the Xen implementation of the domctls.

Signed-off-by: Andres Lagar-Cavilla <andres@scannell.ca>
Signed-off-by: Adin Scannell <adin@scannell.ca>

diff -r 4a189125d71e -r dbfabd1bbfb1 xen/arch/x86/mm.c
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -119,7 +119,6 @@
 #include <xen/trace.h>
 #include <asm/setup.h>
 #include <asm/fixmap.h>
-#include <asm/mem_sharing.h>
 
 /*
  * Mapping of first 2 or 4 megabytes of memory. This is mapped with 4kB
@@ -5093,11 +5092,6 @@ long arch_memory_op(int op, XEN_GUEST_HA
         return rc;
     }
 
-#ifdef __x86_64__
-    case XENMEM_get_sharing_freed_pages:
-        return mem_sharing_get_nr_saved_mfns();
-#endif
-
     default:
         return subarch_memory_op(op, arg);
     }
diff -r 4a189125d71e -r dbfabd1bbfb1 xen/arch/x86/mm/mem_sharing.c
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -72,6 +72,7 @@ static inline int mem_sharing_audit(void
 
 static shr_handle_t next_handle = 1;
 static atomic_t nr_saved_mfns   = ATOMIC_INIT(0); 
+static atomic_t nr_shared_mfns  = ATOMIC_INIT(0);
 
 typedef struct gfn_info
 {
@@ -150,9 +151,12 @@ static struct page_info* mem_sharing_loo
 static int mem_sharing_audit(void)
 {
     int errors = 0;
+    unsigned long count_expected;
+    unsigned long count_found = 0;
     struct list_head *ae;
 
     ASSERT(shr_locked_by_me());
+    count_expected = atomic_read(&nr_shared_mfns);
 
     list_for_each(ae, &shr_audit_list)
     {
@@ -200,6 +204,10 @@ static int mem_sharing_audit(void)
            continue;
         }
 
+        /* Only increase our expected count for pages that are actually shared */
+        if ( !list_has_one_entry(&pg->shared_info->gfns) )
+            count_found++;
+
         /* Check if all GFNs map to the MFN, and the p2m types */
         list_for_each(le, &pg->shared_info->gfns)
         {
@@ -245,6 +253,13 @@ static int mem_sharing_audit(void)
         }
     }
 
+    if ( count_found != count_expected )
+    {
+        MEM_SHARING_DEBUG("Expected %ld shared mfns, found %ld.",
+                          count_expected, count_found);
+        errors++;
+    }
+
     return errors;
 }
 #endif
@@ -294,6 +309,11 @@ unsigned int mem_sharing_get_nr_saved_mf
     return ((unsigned int)atomic_read(&nr_saved_mfns));
 }
 
+unsigned int mem_sharing_get_nr_shared_mfns(void)
+{
+    return (unsigned int)atomic_read(&nr_shared_mfns);
+}
+
 int mem_sharing_sharing_resume(struct domain *d)
 {
     mem_event_response_t rsp;
@@ -577,6 +597,14 @@ int mem_sharing_share_pages(struct domai
     ASSERT(list_empty(&cpage->shared_info->gfns));
     if ( single_source_gfn )
         atomic_inc(&sd->shr_pages);
+    /* We only increase the number of shared pages when 
+     * sharing for the first time */
+    if ( single_source_gfn && single_client_gfn )
+        atomic_inc(&nr_shared_mfns);
+    /* And we decrease it when re-sharing already shared
+     * (because one of them becomes a "saved" page). */
+    if ( !single_source_gfn && !single_client_gfn )
+        atomic_dec(&nr_shared_mfns);
 
     /* Clear the rest of the shared state */
     audit_del_list(cpage);
@@ -659,6 +687,7 @@ gfn_found:
             BUG_ON(!d);
             atomic_dec(&d->shr_pages);
             put_domain(d);
+            atomic_dec(&nr_shared_mfns);
         }
     } else {
         /* Clean up shared state */
diff -r 4a189125d71e -r dbfabd1bbfb1 xen/arch/x86/x86_64/compat/mm.c
--- a/xen/arch/x86/x86_64/compat/mm.c
+++ b/xen/arch/x86/x86_64/compat/mm.c
@@ -205,6 +205,12 @@ int compat_arch_memory_op(int op, XEN_GU
         break;
     }
 
+    case XENMEM_get_sharing_freed_pages:
+        return mem_sharing_get_nr_saved_mfns();
+
+    case XENMEM_get_sharing_shared_pages:
+        return mem_sharing_get_nr_shared_mfns();
+
     default:
         rc = -ENOSYS;
         break;
diff -r 4a189125d71e -r dbfabd1bbfb1 xen/arch/x86/x86_64/mm.c
--- a/xen/arch/x86/x86_64/mm.c
+++ b/xen/arch/x86/x86_64/mm.c
@@ -34,6 +34,7 @@
 #include <asm/msr.h>
 #include <asm/setup.h>
 #include <asm/numa.h>
+#include <asm/mem_sharing.h>
 #include <public/memory.h>
 
 /* Parameters for PFN/MADDR compression. */
@@ -1090,6 +1091,12 @@ long subarch_memory_op(int op, XEN_GUEST
 
         break;
 
+    case XENMEM_get_sharing_freed_pages:
+        return mem_sharing_get_nr_saved_mfns();
+
+    case XENMEM_get_sharing_shared_pages:
+        return mem_sharing_get_nr_shared_mfns();
+
     default:
         rc = -ENOSYS;
         break;
diff -r 4a189125d71e -r dbfabd1bbfb1 xen/include/asm-x86/mem_sharing.h
--- a/xen/include/asm-x86/mem_sharing.h
+++ b/xen/include/asm-x86/mem_sharing.h
@@ -45,6 +45,7 @@ struct page_sharing_info
     (is_hvm_domain(_d) && paging_mode_hap(_d)) 
 
 unsigned int mem_sharing_get_nr_saved_mfns(void);
+unsigned int mem_sharing_get_nr_shared_mfns(void);
 int mem_sharing_nominate_page(struct domain *d, 
                               unsigned long gfn,
                               int expected_refcnt,
diff -r 4a189125d71e -r dbfabd1bbfb1 xen/include/public/memory.h
--- a/xen/include/public/memory.h
+++ b/xen/include/public/memory.h
@@ -294,6 +294,7 @@ typedef struct xen_pod_target xen_pod_ta
  * The call never fails. 
  */
 #define XENMEM_get_sharing_freed_pages    18
+#define XENMEM_get_sharing_shared_pages   19
 
 #endif /* __XEN_PUBLIC_MEMORY_H__ */
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 20:22:39 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 20:22:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZ6xU-0005iH-W3; Fri, 09 Dec 2011 20:22:16 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RZ6xT-0005hm-FI
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 20:22:15 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-4.tower-27.messagelabs.com!1323462054!51825651!1
X-Originating-IP: [208.97.132.119]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xMTkgPT4gMTU5NzU=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1006 invoked from network); 9 Dec 2011 20:20:54 -0000
Received: from caiajhbdcbbj.dreamhost.com (HELO homiemail-a18.g.dreamhost.com)
	(208.97.132.119) by server-4.tower-27.messagelabs.com with SMTP;
	9 Dec 2011 20:20:54 -0000
Received: from homiemail-a18.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a18.g.dreamhost.com (Postfix) with ESMTP id 6C50225006C;
	Fri,  9 Dec 2011 12:21:26 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id:date
	:from:to:cc; q=dns; s=lagarcavilla.org; b=bwXUY+qqUKkBBUfb97/zUK
	QEpv4Gk50fYwl+apSoE967PE4+8FAgB6cOmvQTu+zFHt6Ll+OcF+twsETSOJvhFR
	Al52guc1msQ/O7eqB1PAAt6vI4NWGp5MtRvj6MjRny0KeCQwgZ+tWAOAmqd/5/Nq
	CZOOFe3kKIyM3h8wCBe+4=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:date:from:to:cc; s=lagarcavilla.org; bh=NJs2tKhuJdl/
	np85fEKyymyxd10=; b=UMITma7qx5xts313iWWxA5rVzwoetM7VvSPrrlNqPLkR
	HBavoMsnALPd7G1G+uzCeKS868ld503XpVrpKJlIcqqsMxpG4NkTmV3vO2wnTJeE
	bWmbsld0Id9Ng3tuJf+wOwq1Ni5nvDURHph+ep/cekWvhaquU2aIsfPaE+i3Im0=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a18.g.dreamhost.com (Postfix) with ESMTPSA id 815C225006B; 
	Fri,  9 Dec 2011 12:21:25 -0800 (PST)
MIME-Version: 1.0
Message-Id: <patchbomb.1323462147@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Fri, 09 Dec 2011 15:22:27 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, keir.xen@gmail.com, tim@xen.org, JBeulich@suse.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 0 of 9] x86/mm: Memory Sharing Overhaul V2
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This patch series proposes a comprehensive overhaul of the
memory sharing code. We include

- Clean ups.
- A reworked locking discipline. We introduce the use of per
 page locks to protect additions and removals of gfns to
 shared pages. We use RCU to manage a global list of shared
 pages used for auditing. The end result is the removal of
 the sharing global lock.
- New features:
 + Polling stats via console.
 + More stats: frames that are shared, pages that are saved.
   due to sharing
 + New sharing domctl to add a shared page directly to a whole
   in the physmap.
 + New sharing domctl to perform audits.
Relevant tools patches sent in a separate series.

A consequence of our modifications is a change to the sharing
API. While we refresh the only user of the sharing API in the 
tree, we want to make sure we are not affecting any other
users of the sharing API.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Signed-off-by: Adin Scannell <adin@scannell.ca>

 xen/arch/x86/mm.c                 |    6 +-
 xen/arch/x86/mm/mem_sharing.c     |   91 +++--
 xen/arch/x86/mm/mem_sharing.c     |  560 +++++++++++++++++++------------------
 xen/include/asm-x86/mem_sharing.h |   19 +-
 xen/include/asm-x86/mm.h          |   11 +-
 xen/include/public/domctl.h       |    3 +
 xen/arch/x86/mm/mem_sharing.c     |   57 +++-
 xen/include/public/domctl.h       |    9 +
 xen/arch/x86/mm.c                 |    6 -
 xen/arch/x86/mm/mem_sharing.c     |   29 +
 xen/arch/x86/x86_64/compat/mm.c   |    6 +
 xen/arch/x86/x86_64/mm.c          |    7 +
 xen/include/asm-x86/mem_sharing.h |    1 +
 xen/include/public/memory.h       |    1 +
 xen/arch/x86/mm.c                 |   74 +----
 xen/arch/x86/mm/mem_sharing.c     |  280 +++++++++++++++++-
 xen/arch/x86/mm/mm-locks.h        |   31 +-
 xen/include/asm-x86/mm.h          |   28 +-
 xen/arch/x86/mm/mem_sharing.c     |  104 +++++++
 xen/include/public/domctl.h       |    3 +-
 xen/arch/ia64/xen/mm.c            |    6 +
 xen/arch/x86/mm/mem_sharing.c     |    8 +
 xen/common/keyhandler.c           |    7 +-
 xen/include/xen/mm.h              |    3 +
 xen/arch/x86/mm/mem_sharing.c     |   15 +-
 xen/include/public/domctl.h       |    1 +
 xen/arch/x86/mm/mem_sharing.c     |   83 ++---
 xen/arch/x86/mm/mm-locks.h        |   18 -
 xen/include/asm-x86/mem_sharing.h |    3 +-
 29 files changed, 957 insertions(+), 513 deletions(-)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 20:22:39 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 20:22:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZ6xY-0005iy-D2; Fri, 09 Dec 2011 20:22:20 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RZ6xW-0005i4-Rj
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 20:22:19 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-9.tower-27.messagelabs.com!1323462055!56089792!1
X-Originating-IP: [208.97.132.145]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNDUgPT4gMTczNjI=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1439 invoked from network); 9 Dec 2011 20:20:55 -0000
Received: from caiajhbdcbef.dreamhost.com (HELO homiemail-a18.g.dreamhost.com)
	(208.97.132.145) by server-9.tower-27.messagelabs.com with SMTP;
	9 Dec 2011 20:20:55 -0000
Received: from homiemail-a18.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a18.g.dreamhost.com (Postfix) with ESMTP id 8BB39250074;
	Fri,  9 Dec 2011 12:21:27 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=ptxFAtixNj6a5Zfa06zVucaBSO/7xhjf4jEAccopH2BA
	tu30A9BmcPTW75du3s4uCGXj6+WglbMUVFZzf6GzjEhCsEkLoRKBz2GKcosqVgmn
	kxAUR19yxDsB+OwIWlqEGjmgLp3m0NDmn/8Z0re5U2vYBh6TeJha403TpshodRs=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=z8TSkFSfTQavq8/ehghdtZ9egOs=; b=YhyZK4F9aKW
	lPdvmon0+WeLSpxVsgjzULoqbFkgkHIF236dQXZUzqMyphBusdJ2M45MZxRltqL1
	SNNOp/jAonQhce24vQpR71OcWTiw/jjn9b5X5kVjPCk2kHuHp9ogE75aRNj6YmJx
	gMJJGvcaWxFXxOT5aoubk/K8XXvE0yvw=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a18.g.dreamhost.com (Postfix) with ESMTPSA id 991F125006B; 
	Fri,  9 Dec 2011 12:21:26 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: d29cba447de1fe6b788e5f543191990de39c193c
Message-Id: <d29cba447de1fe6b788e.1323462148@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1323462147@xdev.gridcentric.ca>
References: <patchbomb.1323462147@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Fri, 09 Dec 2011 15:22:28 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, keir.xen@gmail.com, tim@xen.org, JBeulich@suse.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 1 of 9] x86/mm: Code style fixes in mem_sharing.c
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/mm.c             |   6 +-
 xen/arch/x86/mm/mem_sharing.c |  91 ++++++++++++++++++++++--------------------
 2 files changed, 50 insertions(+), 47 deletions(-)


No functional changes, only code style issues.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r f232d335de98 -r d29cba447de1 xen/arch/x86/mm.c
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -4321,9 +4321,9 @@ int page_make_sharable(struct domain *d,
         return -EEXIST;
     }
 
-    /* Check if the ref count is 2. The first from PGT_allocated, and
+    /* Check if the ref count is 2. The first from PGC_allocated, and
      * the second from get_page_and_type at the top of this function */
-    if(page->count_info != (PGC_allocated | (2 + expected_refcnt)))
+    if ( page->count_info != (PGC_allocated | (2 + expected_refcnt)) )
     {
         /* Return type count back to zero */
         put_page_and_type(page);
@@ -4340,7 +4340,7 @@ int page_make_sharable(struct domain *d,
 
 int page_make_private(struct domain *d, struct page_info *page)
 {
-    if(!get_page(page, dom_cow))
+    if ( !get_page(page, dom_cow) )
         return -EINVAL;
     
     spin_lock(&d->page_alloc_lock);
diff -r f232d335de98 -r d29cba447de1 xen/arch/x86/mm/mem_sharing.c
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -35,14 +35,14 @@
 #include "mm-locks.h"
 
 /* Auditing of memory sharing code? */
-#define MEM_SHARING_AUDIT  0
+#define MEM_SHARING_AUDIT 0
 
 #if MEM_SHARING_AUDIT
 static void mem_sharing_audit(void);
 #define MEM_SHARING_DEBUG(_f, _a...)                                  \
     debugtrace_printk("mem_sharing_debug: %s(): " _f, __func__, ##_a)
 #else
-# define mem_sharing_audit() do {} while(0)
+#define mem_sharing_audit() do {} while(0)
 #endif /* MEM_SHARING_AUDIT */
 
 #define mem_sharing_enabled(d) \
@@ -56,7 +56,7 @@ static void mem_sharing_audit(void);
 #define page_to_mfn(_pg) _mfn(__page_to_mfn(_pg))
 
 static shr_handle_t next_handle = 1;
-static atomic_t nr_saved_mfns = ATOMIC_INIT(0); 
+static atomic_t nr_saved_mfns   = ATOMIC_INIT(0); 
 
 typedef struct shr_hash_entry 
 {
@@ -84,9 +84,9 @@ static inline int list_has_one_entry(str
     return (head->next != head) && (head->next->next == head);
 }
 
-static inline struct gfn_info* gfn_get_info(struct list_head *list)
+static inline gfn_info_t *gfn_get_info(struct list_head *list)
 {
-    return list_entry(list->next, struct gfn_info, list);
+    return list_entry(list->next, gfn_info_t, list);
 }
 
 static void __init mem_sharing_hash_init(void)
@@ -116,12 +116,12 @@ static gfn_info_t *mem_sharing_gfn_alloc
 static void mem_sharing_gfn_destroy(gfn_info_t *gfn, int was_shared)
 {
     /* Decrement the number of pages, if the gfn was shared before */
-    if(was_shared)
+    if ( was_shared )
     {
         struct domain *d = get_domain_by_id(gfn->domain);
-        /* Domain may have been destroyed by now, if we are called from
-         * p2m_teardown */
-        if(d)
+        /* Domain may have been destroyed by now *
+         * (if we are called from p2m_teardown)  */
+        if ( d )
         {
             atomic_dec(&d->shr_pages);
             put_domain(d);
@@ -261,7 +261,8 @@ static struct page_info* mem_sharing_all
     mem_event_request_t req;
 
     page = alloc_domheap_page(d, 0); 
-    if(page != NULL) return page;
+    if ( page != NULL )
+        return page;
 
     memset(&req, 0, sizeof(req));
     req.type = MEM_EVENT_TYPE_SHARED;
@@ -293,7 +294,7 @@ static struct page_info* mem_sharing_all
 
 unsigned int mem_sharing_get_nr_saved_mfns(void)
 {
-    return (unsigned int)atomic_read(&nr_saved_mfns);
+    return ((unsigned int)atomic_read(&nr_saved_mfns));
 }
 
 int mem_sharing_sharing_resume(struct domain *d)
@@ -317,14 +318,15 @@ int mem_sharing_debug_mfn(unsigned long 
 {
     struct page_info *page;
 
-    if(!mfn_valid(_mfn(mfn)))
+    if ( !mfn_valid(_mfn(mfn)) )
     {
-        printk("Invalid MFN=%lx\n", mfn);
+        gdprintk(XENLOG_ERR, "Invalid MFN=%lx\n", mfn);
         return -1;
     }
     page = mfn_to_page(_mfn(mfn));
 
-    printk("Debug page: MFN=%lx is ci=%lx, ti=%lx, owner_id=%d\n",
+    gdprintk(XENLOG_DEBUG, 
+            "Debug page: MFN=%lx is ci=%lx, ti=%lx, owner_id=%d\n",
             mfn_x(page_to_mfn(page)), 
             page->count_info, 
             page->u.inuse.type_info,
@@ -340,9 +342,9 @@ int mem_sharing_debug_gfn(struct domain 
 
     mfn = get_gfn_unlocked(d, gfn, &p2mt);
 
-    printk("Debug for domain=%d, gfn=%lx, ", 
-            d->domain_id, 
-            gfn);
+    gdprintk(XENLOG_DEBUG, "Debug for domain=%d, gfn=%lx, ", 
+               d->domain_id, 
+               gfn);
     return mem_sharing_debug_mfn(mfn_x(mfn));
 }
 
@@ -359,8 +361,8 @@ int mem_sharing_debug_gfn(struct domain 
 static grant_entry_header_t *
 shared_entry_header(struct grant_table *t, grant_ref_t ref)
 {
-    ASSERT(t->gt_version != 0);
-    if (t->gt_version == 1)
+    ASSERT (t->gt_version != 0);
+    if ( t->gt_version == 1 )
         return (grant_entry_header_t*)&shared_entry_v1(t, ref);
     else
         return &shared_entry_v2(t, ref).hdr;
@@ -370,25 +372,23 @@ static int mem_sharing_gref_to_gfn(struc
                                    grant_ref_t ref, 
                                    unsigned long *gfn)
 {
-    if(d->grant_table->gt_version < 1)
+    if ( d->grant_table->gt_version < 1 )
         return -1;
 
-    if (d->grant_table->gt_version == 1) 
+    if ( d->grant_table->gt_version == 1 ) 
     {
         grant_entry_v1_t *sha1;
         sha1 = &shared_entry_v1(d->grant_table, ref);
         *gfn = sha1->frame;
-        return 0;
     } 
     else 
     {
         grant_entry_v2_t *sha2;
         sha2 = &shared_entry_v2(d->grant_table, ref);
         *gfn = sha2->full_page.frame;
-        return 0;
     }
  
-    return -2;
+    return 0;
 }
 
 /* Account for a GFN being shared/unshared.
@@ -428,20 +428,22 @@ int mem_sharing_debug_gref(struct domain
     uint16_t status;
     unsigned long gfn;
 
-    if(d->grant_table->gt_version < 1)
+    if ( d->grant_table->gt_version < 1 )
     {
-        printk("Asked to debug [dom=%d,gref=%d], but not yet inited.\n",
+        gdprintk(XENLOG_ERR, 
+                "Asked to debug [dom=%d,gref=%d], but not yet inited.\n",
                 d->domain_id, ref);
         return -1;
     }
-    mem_sharing_gref_to_gfn(d, ref, &gfn); 
+    (void)mem_sharing_gref_to_gfn(d, ref, &gfn); 
     shah = shared_entry_header(d->grant_table, ref);
-    if (d->grant_table->gt_version == 1) 
+    if ( d->grant_table->gt_version == 1 ) 
         status = shah->flags;
     else 
         status = status_entry(d->grant_table, ref);
     
-    printk("==> Grant [dom=%d,ref=%d], status=%x. ", 
+    gdprintk(XENLOG_DEBUG,
+            "==> Grant [dom=%d,ref=%d], status=%x. ", 
             d->domain_id, ref, status);
 
     return mem_sharing_debug_gfn(d, gfn); 
@@ -467,24 +469,24 @@ int mem_sharing_nominate_page(struct dom
 
     /* Check if mfn is valid */
     ret = -EINVAL;
-    if (!mfn_valid(mfn))
+    if ( !mfn_valid(mfn) )
         goto out;
 
     /* Return the handle if the page is already shared */
     page = mfn_to_page(mfn);
-    if (p2m_is_shared(p2mt)) {
+    if ( p2m_is_shared(p2mt) ) {
         *phandle = page->shr_handle;
         ret = 0;
         goto out;
     }
 
     /* Check p2m type */
-    if (!p2m_is_sharable(p2mt))
+    if ( !p2m_is_sharable(p2mt) )
         goto out;
 
     /* Try to convert the mfn to the sharable type */
     ret = page_make_sharable(d, page, expected_refcnt); 
-    if(ret) 
+    if ( ret ) 
         goto out;
 
     /* Create the handle */
@@ -501,7 +503,7 @@ int mem_sharing_nominate_page(struct dom
     }
 
     /* Change the p2m type */
-    if(p2m_change_type(d, gfn, p2mt, p2m_ram_shared) != p2mt) 
+    if ( p2m_change_type(d, gfn, p2mt, p2m_ram_shared) != p2mt ) 
     {
         /* This is unlikely, as the type must have changed since we've checked
          * it a few lines above.
@@ -607,7 +609,7 @@ int mem_sharing_unshare_page(struct doma
     mfn = get_gfn(d, gfn, &p2mt);
     
     /* Has someone already unshared it? */
-    if (!p2m_is_shared(p2mt)) {
+    if ( !p2m_is_shared(p2mt) ) {
         put_gfn(d, gfn);
         shr_unlock();
         return 0;
@@ -620,10 +622,11 @@ int mem_sharing_unshare_page(struct doma
     list_for_each(le, &hash_entry->gfns)
     {
         gfn_info = list_entry(le, struct gfn_info, list);
-        if((gfn_info->gfn == gfn) && (gfn_info->domain == d->domain_id))
+        if ( (gfn_info->gfn == gfn) && (gfn_info->domain == d->domain_id) )
             goto gfn_found;
     }
-    printk("Could not find gfn_info for shared gfn: %lx\n", gfn);
+    gdprintk(XENLOG_ERR, "Could not find gfn_info for shared gfn: "
+                            "%lx\n", gfn);
     BUG();
 gfn_found: 
     /* Delete gfn_info from the list, but hold on to it, until we've allocated
@@ -633,7 +636,7 @@ gfn_found:
 
     /* If the GFN is getting destroyed drop the references to MFN 
      * (possibly freeing the page), and exit early */
-    if(flags & MEM_SHARING_DESTROY_GFN)
+    if ( flags & MEM_SHARING_DESTROY_GFN )
     {
         mem_sharing_gfn_destroy(gfn_info, !last_gfn);
         if(last_gfn) 
@@ -691,8 +694,8 @@ private_page_found:
     else
         atomic_dec(&nr_saved_mfns);
 
-    if(p2m_change_type(d, gfn, p2m_ram_shared, p2m_ram_rw) != 
-                                                p2m_ram_shared) 
+    if ( p2m_change_type(d, gfn, p2m_ram_shared, p2m_ram_rw) != 
+                                                p2m_ram_shared ) 
     {
         printk("Could not change p2m type.\n");
         BUG();
@@ -729,7 +732,7 @@ int mem_sharing_domctl(struct domain *d,
         {
             unsigned long gfn = mec->u.nominate.u.gfn;
             shr_handle_t handle;
-            if(!mem_sharing_enabled(d))
+            if ( !mem_sharing_enabled(d) )
                 return -EINVAL;
             rc = mem_sharing_nominate_page(d, gfn, 0, &handle);
             mec->u.nominate.handle = handle;
@@ -742,9 +745,9 @@ int mem_sharing_domctl(struct domain *d,
             unsigned long gfn;
             shr_handle_t handle;
 
-            if(!mem_sharing_enabled(d))
+            if ( !mem_sharing_enabled(d) )
                 return -EINVAL;
-            if(mem_sharing_gref_to_gfn(d, gref, &gfn) < 0)
+            if ( mem_sharing_gref_to_gfn(d, gref, &gfn) < 0 )
                 return -EINVAL;
             rc = mem_sharing_nominate_page(d, gfn, 3, &handle);
             mec->u.nominate.handle = handle;
@@ -761,7 +764,7 @@ int mem_sharing_domctl(struct domain *d,
 
         case XEN_DOMCTL_MEM_EVENT_OP_SHARING_RESUME:
         {
-            if(!mem_sharing_enabled(d))
+            if ( !mem_sharing_enabled(d) )
                 return -EINVAL;
             rc = mem_sharing_sharing_resume(d);
         }

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 20:22:39 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 20:22:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZ6xU-0005iH-W3; Fri, 09 Dec 2011 20:22:16 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RZ6xT-0005hm-FI
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 20:22:15 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-4.tower-27.messagelabs.com!1323462054!51825651!1
X-Originating-IP: [208.97.132.119]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xMTkgPT4gMTU5NzU=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1006 invoked from network); 9 Dec 2011 20:20:54 -0000
Received: from caiajhbdcbbj.dreamhost.com (HELO homiemail-a18.g.dreamhost.com)
	(208.97.132.119) by server-4.tower-27.messagelabs.com with SMTP;
	9 Dec 2011 20:20:54 -0000
Received: from homiemail-a18.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a18.g.dreamhost.com (Postfix) with ESMTP id 6C50225006C;
	Fri,  9 Dec 2011 12:21:26 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id:date
	:from:to:cc; q=dns; s=lagarcavilla.org; b=bwXUY+qqUKkBBUfb97/zUK
	QEpv4Gk50fYwl+apSoE967PE4+8FAgB6cOmvQTu+zFHt6Ll+OcF+twsETSOJvhFR
	Al52guc1msQ/O7eqB1PAAt6vI4NWGp5MtRvj6MjRny0KeCQwgZ+tWAOAmqd/5/Nq
	CZOOFe3kKIyM3h8wCBe+4=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:date:from:to:cc; s=lagarcavilla.org; bh=NJs2tKhuJdl/
	np85fEKyymyxd10=; b=UMITma7qx5xts313iWWxA5rVzwoetM7VvSPrrlNqPLkR
	HBavoMsnALPd7G1G+uzCeKS868ld503XpVrpKJlIcqqsMxpG4NkTmV3vO2wnTJeE
	bWmbsld0Id9Ng3tuJf+wOwq1Ni5nvDURHph+ep/cekWvhaquU2aIsfPaE+i3Im0=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a18.g.dreamhost.com (Postfix) with ESMTPSA id 815C225006B; 
	Fri,  9 Dec 2011 12:21:25 -0800 (PST)
MIME-Version: 1.0
Message-Id: <patchbomb.1323462147@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Fri, 09 Dec 2011 15:22:27 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, keir.xen@gmail.com, tim@xen.org, JBeulich@suse.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 0 of 9] x86/mm: Memory Sharing Overhaul V2
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This patch series proposes a comprehensive overhaul of the
memory sharing code. We include

- Clean ups.
- A reworked locking discipline. We introduce the use of per
 page locks to protect additions and removals of gfns to
 shared pages. We use RCU to manage a global list of shared
 pages used for auditing. The end result is the removal of
 the sharing global lock.
- New features:
 + Polling stats via console.
 + More stats: frames that are shared, pages that are saved.
   due to sharing
 + New sharing domctl to add a shared page directly to a whole
   in the physmap.
 + New sharing domctl to perform audits.
Relevant tools patches sent in a separate series.

A consequence of our modifications is a change to the sharing
API. While we refresh the only user of the sharing API in the 
tree, we want to make sure we are not affecting any other
users of the sharing API.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Signed-off-by: Adin Scannell <adin@scannell.ca>

 xen/arch/x86/mm.c                 |    6 +-
 xen/arch/x86/mm/mem_sharing.c     |   91 +++--
 xen/arch/x86/mm/mem_sharing.c     |  560 +++++++++++++++++++------------------
 xen/include/asm-x86/mem_sharing.h |   19 +-
 xen/include/asm-x86/mm.h          |   11 +-
 xen/include/public/domctl.h       |    3 +
 xen/arch/x86/mm/mem_sharing.c     |   57 +++-
 xen/include/public/domctl.h       |    9 +
 xen/arch/x86/mm.c                 |    6 -
 xen/arch/x86/mm/mem_sharing.c     |   29 +
 xen/arch/x86/x86_64/compat/mm.c   |    6 +
 xen/arch/x86/x86_64/mm.c          |    7 +
 xen/include/asm-x86/mem_sharing.h |    1 +
 xen/include/public/memory.h       |    1 +
 xen/arch/x86/mm.c                 |   74 +----
 xen/arch/x86/mm/mem_sharing.c     |  280 +++++++++++++++++-
 xen/arch/x86/mm/mm-locks.h        |   31 +-
 xen/include/asm-x86/mm.h          |   28 +-
 xen/arch/x86/mm/mem_sharing.c     |  104 +++++++
 xen/include/public/domctl.h       |    3 +-
 xen/arch/ia64/xen/mm.c            |    6 +
 xen/arch/x86/mm/mem_sharing.c     |    8 +
 xen/common/keyhandler.c           |    7 +-
 xen/include/xen/mm.h              |    3 +
 xen/arch/x86/mm/mem_sharing.c     |   15 +-
 xen/include/public/domctl.h       |    1 +
 xen/arch/x86/mm/mem_sharing.c     |   83 ++---
 xen/arch/x86/mm/mm-locks.h        |   18 -
 xen/include/asm-x86/mem_sharing.h |    3 +-
 29 files changed, 957 insertions(+), 513 deletions(-)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 20:32:30 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 20:32:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZ76l-0007fB-S0; Fri, 09 Dec 2011 20:31:51 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1RZ76j-0007f6-RS
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 20:31:50 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-5.tower-174.messagelabs.com!1323462658!4960569!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4986 invoked from network); 9 Dec 2011 20:31:00 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-5.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 9 Dec 2011 20:31:00 -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
	pB9KUB88017092
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Fri, 9 Dec 2011 15:30:11 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pB9KUA0j017090;
	Fri, 9 Dec 2011 15:30:10 -0500
Date: Fri, 9 Dec 2011 16:30:10 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: "Taylor, Neal E" <Neal.Taylor@ca.com>
Message-ID: <20111209203010.GA14412@andromeda.dapyr.net>
References: <3E243B26F475504B9BB0BCC9728B0DA629E16E01@USILMS110A.ca.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <3E243B26F475504B9BB0BCC9728B0DA629E16E01@USILMS110A.ca.com>
User-Agent: Mutt/1.5.9i
Cc: xen-devel <xen-devel@lists.xensource.com>, "Kalev,
	Leonid" <Leonid.Kalev@ca.com>, "Dave, Tushar N" <tushar.n.dave@intel.com>
Subject: Re: [Xen-devel] Buffers not reachable by PCI
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Dec 09, 2011 at 08:19:47PM +0000, Taylor, Neal E wrote:
> We're running 64-bit Xex 4.1.1 and 32-bit Linux 3.0.4 Dom0 (Linux 3.1 shows the same symptom.)

Hm, 32-bit. Did it work if the Dom0 was 64-bit?
> 
> Several PCI drivers are unable to use DMA. Most fallback to using PIO but in two instances the network drivers (e1000 and pcinet32) abort. The same kernel running on the same hardware without Xen works fine.
> 
> Digging through the code, in swiotlb-xen.c I find "DMA_BIT_MASK(32)" (0x00000000ffffffff) compared to "xen_virt_to_bus(xen_io_tlb_end - 1)" which resolves to 0x1,20fd,feff. Since the address is larger than the mask, DMA is declared as unsupportable.

<blinks>

xen_io_tlb_end resolved to 120fdfeff? That is a definite bug. Can you
attach you full bootup serial log with 'debug loglevel=8' parameters on
the Linux line please?



> In talking with others I hear Linux handles this situation with bounce buffers. Is there a config setting I've missed to enable that for Xen? (Config file attached)

The Xen SWIOTLB is by default enabled, so it is on, but the
xen_virt_to_bus(xen_io_tlb_end - 1) _MUST_ never be above 4GB. In your
case it is, which is bad. It is rather surprising as I had not seen this
ever happen.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 20:32:30 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 20:32:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZ76l-0007fB-S0; Fri, 09 Dec 2011 20:31:51 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1RZ76j-0007f6-RS
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 20:31:50 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-5.tower-174.messagelabs.com!1323462658!4960569!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4986 invoked from network); 9 Dec 2011 20:31:00 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-5.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 9 Dec 2011 20:31:00 -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
	pB9KUB88017092
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Fri, 9 Dec 2011 15:30:11 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pB9KUA0j017090;
	Fri, 9 Dec 2011 15:30:10 -0500
Date: Fri, 9 Dec 2011 16:30:10 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: "Taylor, Neal E" <Neal.Taylor@ca.com>
Message-ID: <20111209203010.GA14412@andromeda.dapyr.net>
References: <3E243B26F475504B9BB0BCC9728B0DA629E16E01@USILMS110A.ca.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <3E243B26F475504B9BB0BCC9728B0DA629E16E01@USILMS110A.ca.com>
User-Agent: Mutt/1.5.9i
Cc: xen-devel <xen-devel@lists.xensource.com>, "Kalev,
	Leonid" <Leonid.Kalev@ca.com>, "Dave, Tushar N" <tushar.n.dave@intel.com>
Subject: Re: [Xen-devel] Buffers not reachable by PCI
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Dec 09, 2011 at 08:19:47PM +0000, Taylor, Neal E wrote:
> We're running 64-bit Xex 4.1.1 and 32-bit Linux 3.0.4 Dom0 (Linux 3.1 shows the same symptom.)

Hm, 32-bit. Did it work if the Dom0 was 64-bit?
> 
> Several PCI drivers are unable to use DMA. Most fallback to using PIO but in two instances the network drivers (e1000 and pcinet32) abort. The same kernel running on the same hardware without Xen works fine.
> 
> Digging through the code, in swiotlb-xen.c I find "DMA_BIT_MASK(32)" (0x00000000ffffffff) compared to "xen_virt_to_bus(xen_io_tlb_end - 1)" which resolves to 0x1,20fd,feff. Since the address is larger than the mask, DMA is declared as unsupportable.

<blinks>

xen_io_tlb_end resolved to 120fdfeff? That is a definite bug. Can you
attach you full bootup serial log with 'debug loglevel=8' parameters on
the Linux line please?



> In talking with others I hear Linux handles this situation with bounce buffers. Is there a config setting I've missed to enable that for Xen? (Config file attached)

The Xen SWIOTLB is by default enabled, so it is on, but the
xen_virt_to_bus(xen_io_tlb_end - 1) _MUST_ never be above 4GB. In your
case it is, which is bad. It is rather surprising as I had not seen this
ever happen.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 20:43:22 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 20:43:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZ7H1-0007wj-6q; Fri, 09 Dec 2011 20:42:27 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RZ7Gz-0007we-3d
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 20:42:25 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1323463294!7503594!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI2MQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16482 invoked from network); 9 Dec 2011 20:41:35 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 20:41:35 -0000
X-IronPort-AV: E=Sophos;i="4.71,328,1320624000"; 
   d="scan'208";a="9393447"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 20:41:34 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 9 Dec 2011
	20:41:33 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
In-Reply-To: <20194.22539.574524.956955@mariner.uk.xensource.com>
References: <1323108621-22654-1-git-send-email-ian.jackson@eu.citrix.com>
	<1323108621-22654-16-git-send-email-ian.jackson@eu.citrix.com>
	<alpine.DEB.2.00.1112091558300.3517@kaball-desktop>
	<20194.22539.574524.956955@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
Date: Fri, 9 Dec 2011 20:41:33 +0000
Message-ID: <1323463293.20936.11.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
X-Mailer: Evolution 2.32.3 
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 15/15] libxl: New event generation API
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2011-12-09 at 18:48 +0000, Ian Jackson wrote:
> Now Linux and Xen have a tendency, when they need a name for an
> unlocked version of foo, to use the name _foo.  Obviously this is no
> good in a userspace program and anyway I think it is a completely
> ridiculous convention.  We need something much clearer.
> 
> foo_internal is a possibility but that merely suggests that the
> GC_INIT has been done, and doesn't make it 100% clear that the caller
> must already have done CTX_LOCK. 

Some places also use foo_raw, not sure how much of an improvement that
is though.

Maybe a simple comment is sufficient:

/* Must be called with $LOCK held */
int libxl_event_check(libxl_ctx *ctx, libxl_event **event_r,
	...

It's a shame there is no pthread_mutex_is_locked or an assert containing
it would be nicely self documenting. I suppose CTX_LOCK could set a flag
in the context which we could assert on, but, ick.

Stepping back a bit: Since the lock is recursive do we really need the
unlocked version? All the callers of event_check_unlocked (apart from
libxl_event_check) could call libxl_event_check instead.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 20:43:22 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 20:43:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZ7H1-0007wj-6q; Fri, 09 Dec 2011 20:42:27 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RZ7Gz-0007we-3d
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 20:42:25 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1323463294!7503594!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI2MQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16482 invoked from network); 9 Dec 2011 20:41:35 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 20:41:35 -0000
X-IronPort-AV: E=Sophos;i="4.71,328,1320624000"; 
   d="scan'208";a="9393447"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 20:41:34 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 9 Dec 2011
	20:41:33 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
In-Reply-To: <20194.22539.574524.956955@mariner.uk.xensource.com>
References: <1323108621-22654-1-git-send-email-ian.jackson@eu.citrix.com>
	<1323108621-22654-16-git-send-email-ian.jackson@eu.citrix.com>
	<alpine.DEB.2.00.1112091558300.3517@kaball-desktop>
	<20194.22539.574524.956955@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
Date: Fri, 9 Dec 2011 20:41:33 +0000
Message-ID: <1323463293.20936.11.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
X-Mailer: Evolution 2.32.3 
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 15/15] libxl: New event generation API
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2011-12-09 at 18:48 +0000, Ian Jackson wrote:
> Now Linux and Xen have a tendency, when they need a name for an
> unlocked version of foo, to use the name _foo.  Obviously this is no
> good in a userspace program and anyway I think it is a completely
> ridiculous convention.  We need something much clearer.
> 
> foo_internal is a possibility but that merely suggests that the
> GC_INIT has been done, and doesn't make it 100% clear that the caller
> must already have done CTX_LOCK. 

Some places also use foo_raw, not sure how much of an improvement that
is though.

Maybe a simple comment is sufficient:

/* Must be called with $LOCK held */
int libxl_event_check(libxl_ctx *ctx, libxl_event **event_r,
	...

It's a shame there is no pthread_mutex_is_locked or an assert containing
it would be nicely self documenting. I suppose CTX_LOCK could set a flag
in the context which we could assert on, but, ick.

Stepping back a bit: Since the lock is recursive do we really need the
unlocked version? All the callers of event_check_unlocked (apart from
libxl_event_check) could call libxl_event_check instead.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 20:44:43 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 20: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.xensource.com>)
	id 1RZ7Ih-000846-S2; Fri, 09 Dec 2011 20:44:11 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RZ7Ig-00083Y-Mi
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 20:44:10 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1323463400!6618596!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI2MQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21147 invoked from network); 9 Dec 2011 20:43:21 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 20:43:21 -0000
X-IronPort-AV: E=Sophos;i="4.71,328,1320624000"; 
   d="scan'208";a="9393451"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 20:43:08 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 9 Dec 2011
	20:43:08 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
In-Reply-To: <1323456877-15315-13-git-send-email-ian.jackson@eu.citrix.com>
References: <1323456877-15315-1-git-send-email-ian.jackson@eu.citrix.com>
	<1323456877-15315-13-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
Date: Fri, 9 Dec 2011 20:43:07 +0000
Message-ID: <1323463387.20936.13.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
X-Mailer: Evolution 2.32.3 
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 12/18] libxl: libxl_ctx_free should free the
 ctx
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2011-12-09 at 18:54 +0000, Ian Jackson wrote:
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

I introduced this error when I switch things from libxl_ctx_init to
libxl_ctx_alloc, sorry. By way of making up for it:

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> ---
>  tools/libxl/libxl.c |    1 +
>  1 files changed, 1 insertions(+), 0 deletions(-)
> 
> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> index 7488538..5a29c29 100644
> --- a/tools/libxl/libxl.c
> +++ b/tools/libxl/libxl.c
> @@ -93,6 +93,7 @@ int libxl_ctx_free(libxl_ctx *ctx)
>      if (ctx->xch) xc_interface_close(ctx->xch);
>      libxl_version_info_dispose(&ctx->version_info);
>      if (ctx->xsh) xs_daemon_close(ctx->xsh);
> +    free(ctx);
>      return 0;
>  }
>  



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 20:44:43 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 20: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.xensource.com>)
	id 1RZ7Ih-000846-S2; Fri, 09 Dec 2011 20:44:11 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RZ7Ig-00083Y-Mi
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 20:44:10 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1323463400!6618596!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI2MQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21147 invoked from network); 9 Dec 2011 20:43:21 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 20:43:21 -0000
X-IronPort-AV: E=Sophos;i="4.71,328,1320624000"; 
   d="scan'208";a="9393451"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 20:43:08 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 9 Dec 2011
	20:43:08 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
In-Reply-To: <1323456877-15315-13-git-send-email-ian.jackson@eu.citrix.com>
References: <1323456877-15315-1-git-send-email-ian.jackson@eu.citrix.com>
	<1323456877-15315-13-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
Date: Fri, 9 Dec 2011 20:43:07 +0000
Message-ID: <1323463387.20936.13.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
X-Mailer: Evolution 2.32.3 
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 12/18] libxl: libxl_ctx_free should free the
 ctx
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2011-12-09 at 18:54 +0000, Ian Jackson wrote:
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

I introduced this error when I switch things from libxl_ctx_init to
libxl_ctx_alloc, sorry. By way of making up for it:

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> ---
>  tools/libxl/libxl.c |    1 +
>  1 files changed, 1 insertions(+), 0 deletions(-)
> 
> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> index 7488538..5a29c29 100644
> --- a/tools/libxl/libxl.c
> +++ b/tools/libxl/libxl.c
> @@ -93,6 +93,7 @@ int libxl_ctx_free(libxl_ctx *ctx)
>      if (ctx->xch) xc_interface_close(ctx->xch);
>      libxl_version_info_dispose(&ctx->version_info);
>      if (ctx->xsh) xs_daemon_close(ctx->xsh);
> +    free(ctx);
>      return 0;
>  }
>  



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 20:50:49 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 20:50:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZ7Ow-0008KZ-Na; Fri, 09 Dec 2011 20:50:38 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RZ7Ov-0008KR-Lp
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 20:50:37 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1323463788!6266417!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDMwNg==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26154 invoked from network); 9 Dec 2011 20:49:48 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 20:49:48 -0000
X-IronPort-AV: E=Sophos;i="4.71,328,1320624000"; 
   d="scan'208";a="9393471"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 20:49:47 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 9 Dec 2011
	20:49:47 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
In-Reply-To: <1323456877-15315-16-git-send-email-ian.jackson@eu.citrix.com>
References: <1323456877-15315-1-git-send-email-ian.jackson@eu.citrix.com>
	<1323456877-15315-16-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
Date: Fri, 9 Dec 2011 20:49:46 +0000
Message-ID: <1323463786.20936.19.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
X-Mailer: Evolution 2.32.3 
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 15/18] xenstore: New function
 xs_path_is_subpath
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2011-12-09 at 18:54 +0000, Ian Jackson wrote:
> This utility function compares two paths, textually and reports
> whether one is a subpath (a child path) of the other.
> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
> ---
>  tools/xenstore/xs.c |   17 +++++++++++++++++
>  tools/xenstore/xs.h |    7 +++++++
>  2 files changed, 24 insertions(+), 0 deletions(-)
> 
> diff --git a/tools/xenstore/xs.c b/tools/xenstore/xs.c
> index 8e54fe0..0a01675 100644
> --- a/tools/xenstore/xs.c
> +++ b/tools/xenstore/xs.c
> @@ -950,6 +950,23 @@ char *xs_get_domain_path(struct xs_handle *h, unsigned int domid)
>  	return xs_single(h, XBT_NULL, XS_GET_DOMAIN_PATH, domid_str, NULL);
>  }
>  
> +bool xs_path_is_subpath(const char *parent, const char *child)
> +{
> +        size_t childlen = strlen(child);
> +        size_t parentlen = strlen(parent);
> +
> +	if (childlen < parentlen)
> +		return false;
> +
> +	if (memcmp(child, parent, parentlen))
> +		return false;
> +
> +	if (childlen > parentlen && child[parentlen] != '/')
> +		return false;

It took me a second to figure that this last statement was preventing
false positives from sibling directories where one is a substring of the
other. Worth a comment?

Doesn't the correctness of this depend on whether parent has a trailing
slash or not though?

	parent	= "foo"			len = 3
	child 	= "foo/bar"
	=> child[3] == '/' => GOOD

	parent	= "foo/"		len = 4
	child	= "foo/bar
	=> child[4] == 'b' => BAD.

Does adding
	if parent[parentlen] == '/' parentlen--;
beforehand help?

> +
> +	return true;
> +}
> +
>  bool xs_is_domain_introduced(struct xs_handle *h, unsigned int domid)
>  {
>  	char *domain = single_with_domid(h, XS_IS_DOMAIN_INTRODUCED, domid);
> diff --git a/tools/xenstore/xs.h b/tools/xenstore/xs.h
> index 63f535d..8d49e50 100644
> --- a/tools/xenstore/xs.h
> +++ b/tools/xenstore/xs.h
> @@ -207,6 +207,13 @@ bool xs_release_domain(struct xs_handle *h, unsigned int domid);
>   */
>  char *xs_get_domain_path(struct xs_handle *h, unsigned int domid);
>  
> +/* Returns true if child is either equal to parent, or a node underneath
> + * parent; or false otherwise.  Done by string comparison, so relative and
> + * absolute pathnames never in a parent/child relationship by this
> + * definition.  Cannot fail.
> + */
> +bool xs_path_is_subpath(const char *parent, const char *child);
> +
>  /* Return whether the domain specified has been introduced to xenstored.
>   */
>  bool xs_is_domain_introduced(struct xs_handle *h, unsigned int domid);



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 20:50:49 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 20:50:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZ7Ow-0008KZ-Na; Fri, 09 Dec 2011 20:50:38 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RZ7Ov-0008KR-Lp
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 20:50:37 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1323463788!6266417!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDMwNg==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26154 invoked from network); 9 Dec 2011 20:49:48 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 20:49:48 -0000
X-IronPort-AV: E=Sophos;i="4.71,328,1320624000"; 
   d="scan'208";a="9393471"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 20:49:47 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 9 Dec 2011
	20:49:47 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
In-Reply-To: <1323456877-15315-16-git-send-email-ian.jackson@eu.citrix.com>
References: <1323456877-15315-1-git-send-email-ian.jackson@eu.citrix.com>
	<1323456877-15315-16-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
Date: Fri, 9 Dec 2011 20:49:46 +0000
Message-ID: <1323463786.20936.19.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
X-Mailer: Evolution 2.32.3 
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 15/18] xenstore: New function
 xs_path_is_subpath
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2011-12-09 at 18:54 +0000, Ian Jackson wrote:
> This utility function compares two paths, textually and reports
> whether one is a subpath (a child path) of the other.
> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
> ---
>  tools/xenstore/xs.c |   17 +++++++++++++++++
>  tools/xenstore/xs.h |    7 +++++++
>  2 files changed, 24 insertions(+), 0 deletions(-)
> 
> diff --git a/tools/xenstore/xs.c b/tools/xenstore/xs.c
> index 8e54fe0..0a01675 100644
> --- a/tools/xenstore/xs.c
> +++ b/tools/xenstore/xs.c
> @@ -950,6 +950,23 @@ char *xs_get_domain_path(struct xs_handle *h, unsigned int domid)
>  	return xs_single(h, XBT_NULL, XS_GET_DOMAIN_PATH, domid_str, NULL);
>  }
>  
> +bool xs_path_is_subpath(const char *parent, const char *child)
> +{
> +        size_t childlen = strlen(child);
> +        size_t parentlen = strlen(parent);
> +
> +	if (childlen < parentlen)
> +		return false;
> +
> +	if (memcmp(child, parent, parentlen))
> +		return false;
> +
> +	if (childlen > parentlen && child[parentlen] != '/')
> +		return false;

It took me a second to figure that this last statement was preventing
false positives from sibling directories where one is a substring of the
other. Worth a comment?

Doesn't the correctness of this depend on whether parent has a trailing
slash or not though?

	parent	= "foo"			len = 3
	child 	= "foo/bar"
	=> child[3] == '/' => GOOD

	parent	= "foo/"		len = 4
	child	= "foo/bar
	=> child[4] == 'b' => BAD.

Does adding
	if parent[parentlen] == '/' parentlen--;
beforehand help?

> +
> +	return true;
> +}
> +
>  bool xs_is_domain_introduced(struct xs_handle *h, unsigned int domid)
>  {
>  	char *domain = single_with_domid(h, XS_IS_DOMAIN_INTRODUCED, domid);
> diff --git a/tools/xenstore/xs.h b/tools/xenstore/xs.h
> index 63f535d..8d49e50 100644
> --- a/tools/xenstore/xs.h
> +++ b/tools/xenstore/xs.h
> @@ -207,6 +207,13 @@ bool xs_release_domain(struct xs_handle *h, unsigned int domid);
>   */
>  char *xs_get_domain_path(struct xs_handle *h, unsigned int domid);
>  
> +/* Returns true if child is either equal to parent, or a node underneath
> + * parent; or false otherwise.  Done by string comparison, so relative and
> + * absolute pathnames never in a parent/child relationship by this
> + * definition.  Cannot fail.
> + */
> +bool xs_path_is_subpath(const char *parent, const char *child);
> +
>  /* Return whether the domain specified has been introduced to xenstored.
>   */
>  bool xs_is_domain_introduced(struct xs_handle *h, unsigned int domid);



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 20:51:26 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 20: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.xensource.com>)
	id 1RZ7Pa-0008Mz-5N; Fri, 09 Dec 2011 20:51:18 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RZ7PY-0008MJ-9m
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 20:51:16 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1323463826!6842447!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI2MQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30585 invoked from network); 9 Dec 2011 20:50:26 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 20:50:26 -0000
X-IronPort-AV: E=Sophos;i="4.71,328,1320624000"; 
   d="scan'208";a="9393477"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 20:50:26 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 9 Dec 2011
	20:50:26 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
In-Reply-To: <1323456877-15315-17-git-send-email-ian.jackson@eu.citrix.com>
References: <1323456877-15315-1-git-send-email-ian.jackson@eu.citrix.com>
	<1323456877-15315-17-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
Date: Fri, 9 Dec 2011 20:50:25 +0000
Message-ID: <1323463825.20936.20.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
X-Mailer: Evolution 2.32.3 
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 16/18] libxl: rename libxl__free_all
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2011-12-09 at 18:54 +0000, Ian Jackson wrote:
> libxl__free_all is going to gain some extra functionality, which will
> mean that the name is no longer accurate.  Rename it to
> libxl__gc_cleanup.
> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 20:51:26 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 20: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.xensource.com>)
	id 1RZ7Pa-0008Mz-5N; Fri, 09 Dec 2011 20:51:18 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RZ7PY-0008MJ-9m
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 20:51:16 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1323463826!6842447!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI2MQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30585 invoked from network); 9 Dec 2011 20:50:26 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 20:50:26 -0000
X-IronPort-AV: E=Sophos;i="4.71,328,1320624000"; 
   d="scan'208";a="9393477"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 20:50:26 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 9 Dec 2011
	20:50:26 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
In-Reply-To: <1323456877-15315-17-git-send-email-ian.jackson@eu.citrix.com>
References: <1323456877-15315-1-git-send-email-ian.jackson@eu.citrix.com>
	<1323456877-15315-17-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
Date: Fri, 9 Dec 2011 20:50:25 +0000
Message-ID: <1323463825.20936.20.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
X-Mailer: Evolution 2.32.3 
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 16/18] libxl: rename libxl__free_all
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2011-12-09 at 18:54 +0000, Ian Jackson wrote:
> libxl__free_all is going to gain some extra functionality, which will
> mean that the name is no longer accurate.  Rename it to
> libxl__gc_cleanup.
> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 21:24:36 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 21: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.xensource.com>)
	id 1RZ7vL-0000T6-Ul; Fri, 09 Dec 2011 21:24:07 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RZ7vK-0000T1-Nf
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 21:24:06 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1323465796!6625802!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI2MQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16773 invoked from network); 9 Dec 2011 21:23:16 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 21:23:16 -0000
X-IronPort-AV: E=Sophos;i="4.71,328,1320624000"; 
   d="scan'208";a="9393870"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 21:23:02 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 9 Dec 2011
	21:23:01 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: David Miller <davem@davemloft.net>
In-Reply-To: <20111209.134514.2071890208094978847.davem@davemloft.net>
References: <1323430738-3798-1-git-send-email-lersek@redhat.com>
	<20111209.134514.2071890208094978847.davem@davemloft.net>
Organization: Citrix Systems, Inc.
Date: Fri, 9 Dec 2011 21:23:00 +0000
Message-ID: <1323465781.20936.49.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
X-Mailer: Evolution 2.32.3 
Cc: "jeremy@goop.org" <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"virtualization@lists.linux-foundation.org"
	<virtualization@lists.linux-foundation.org>,
	"lersek@redhat.com" <lersek@redhat.com>
Subject: Re: [Xen-devel] [PATCH v3 REPOST] xen-netfront: delay gARP until
 backend switches to Connected
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2011-12-09 at 18:45 +0000, David Miller wrote:
> From: Laszlo Ersek <lersek@redhat.com>
> Date: Fri,  9 Dec 2011 12:38:58 +0100
> 
> > These two together provide complete ordering. Sub-condition (1) is
> > satisfied by pvops commit 43223efd9bfd.
> 
> I don't see this commit in Linus's tree,

The referenced commit is in
git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git#xen/next-2.6.32  some people call the "pvops tree" but there's no reason to expect someone outside the Xen world to know that...

A better reference would have been 6b0b80ca7165 in
git://xenbits.xen.org/people/ianc/linux-2.6.git#upstream/dom0/backend/netback-history which is the precise branch that was flattened to make f942dc2552b8, which is the upstream commit that added netback, so this change is already in upstream.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 21:24:36 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 21: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.xensource.com>)
	id 1RZ7vL-0000T6-Ul; Fri, 09 Dec 2011 21:24:07 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RZ7vK-0000T1-Nf
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 21:24:06 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1323465796!6625802!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI2MQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16773 invoked from network); 9 Dec 2011 21:23:16 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 21:23:16 -0000
X-IronPort-AV: E=Sophos;i="4.71,328,1320624000"; 
   d="scan'208";a="9393870"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 21:23:02 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 9 Dec 2011
	21:23:01 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: David Miller <davem@davemloft.net>
In-Reply-To: <20111209.134514.2071890208094978847.davem@davemloft.net>
References: <1323430738-3798-1-git-send-email-lersek@redhat.com>
	<20111209.134514.2071890208094978847.davem@davemloft.net>
Organization: Citrix Systems, Inc.
Date: Fri, 9 Dec 2011 21:23:00 +0000
Message-ID: <1323465781.20936.49.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
X-Mailer: Evolution 2.32.3 
Cc: "jeremy@goop.org" <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"virtualization@lists.linux-foundation.org"
	<virtualization@lists.linux-foundation.org>,
	"lersek@redhat.com" <lersek@redhat.com>
Subject: Re: [Xen-devel] [PATCH v3 REPOST] xen-netfront: delay gARP until
 backend switches to Connected
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2011-12-09 at 18:45 +0000, David Miller wrote:
> From: Laszlo Ersek <lersek@redhat.com>
> Date: Fri,  9 Dec 2011 12:38:58 +0100
> 
> > These two together provide complete ordering. Sub-condition (1) is
> > satisfied by pvops commit 43223efd9bfd.
> 
> I don't see this commit in Linus's tree,

The referenced commit is in
git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git#xen/next-2.6.32  some people call the "pvops tree" but there's no reason to expect someone outside the Xen world to know that...

A better reference would have been 6b0b80ca7165 in
git://xenbits.xen.org/people/ianc/linux-2.6.git#upstream/dom0/backend/netback-history which is the precise branch that was flattened to make f942dc2552b8, which is the upstream commit that added netback, so this change is already in upstream.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 21:55:52 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 21:55:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZ8Pd-0000oI-Jp; Fri, 09 Dec 2011 21:55:25 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1RZ8Pc-0000o4-0r
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 21:55:24 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1323467672!6877235!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMTkxNzY=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18273 invoked from network); 9 Dec 2011 21:54:33 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 21:54:33 -0000
X-IronPort-AV: E=Sophos;i="4.71,328,1320642000"; d="scan'208";a="173624335"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 16:54:31 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 16:54:31 -0500
Received: from perard.uk.xensource.com (dhcp-3-28.uk.xensource.com
	[10.80.3.28] (may be forged))	by smtp01.ad.xensource.com
	(8.13.1/8.13.1) with
	ESMTP id pB9LsThE011070;	Fri, 9 Dec 2011 13:54:30 -0800
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Fri, 9 Dec 2011 21:54:00 +0000
Message-ID: <1323467645-24271-1-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH V2 0/5] Have a working migration with Xen
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi all,

This patch series provide some fix to have migration working with Xen. The main
issue with Xen is that the guest RAM is not handle by QEMU.

So, first of all, the RAM will not be saved in the QEMU state file.

- For this, we can also unregister the ram_save_live function later in xen code
  instead of having this extra "if xen" but I'm not sure of wish one would be
  the best choice.

Then, during the initialisation that append before the migration, QEMU should
not try to allocate again the VRAM of the vga emulation, because it's already
there. (The guest RAM is restored before calling QEMU)

And last but not least, in QEMU with Xen, a call to set_memory (with different
address for start_addr and phys_offset) actually move the the memory, and the
only way to have a pointer to this memory is to ask a ptr with the new addr.
So, there is a patch that check for the right guest address to map.

There is probably a better way to do some of this.

Change since v1:
  - rename xen_addr_actually_is to xen_phys_offset_to_gaddr.
  - give phys_offset_to_gaddr as a pointer to map_cache_init
    (no more global var in xen-all.c).
  - call xen_phys_offset_to_gaddr only if the first try fail.
  - also change a comment in the last patch.

Regards,


Anthony PERARD (5):
  vl.c: Do not save RAM state when Xen is used.
  xen mapcache: Check if a memory space has moved.
  Introduce premigrate RunState.
  xen: Change memory access behavior during migration.
  vga-cirrus: Workaround during restore when using Xen.

 hw/cirrus_vga.c  |   16 +++++++++++++---
 qapi-schema.json |    2 +-
 vl.c             |   10 ++++++++--
 xen-all.c        |   31 ++++++++++++++++++++++++++++++-
 xen-mapcache.c   |   22 +++++++++++++++++++---
 xen-mapcache.h   |    9 +++++++--
 6 files changed, 78 insertions(+), 12 deletions(-)

-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 21:55:52 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 21:55:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZ8Pd-0000oI-Jp; Fri, 09 Dec 2011 21:55:25 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1RZ8Pc-0000o4-0r
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 21:55:24 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1323467672!6877235!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMTkxNzY=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18273 invoked from network); 9 Dec 2011 21:54:33 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 21:54:33 -0000
X-IronPort-AV: E=Sophos;i="4.71,328,1320642000"; d="scan'208";a="173624335"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 16:54:31 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 16:54:31 -0500
Received: from perard.uk.xensource.com (dhcp-3-28.uk.xensource.com
	[10.80.3.28] (may be forged))	by smtp01.ad.xensource.com
	(8.13.1/8.13.1) with
	ESMTP id pB9LsThE011070;	Fri, 9 Dec 2011 13:54:30 -0800
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Fri, 9 Dec 2011 21:54:00 +0000
Message-ID: <1323467645-24271-1-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH V2 0/5] Have a working migration with Xen
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi all,

This patch series provide some fix to have migration working with Xen. The main
issue with Xen is that the guest RAM is not handle by QEMU.

So, first of all, the RAM will not be saved in the QEMU state file.

- For this, we can also unregister the ram_save_live function later in xen code
  instead of having this extra "if xen" but I'm not sure of wish one would be
  the best choice.

Then, during the initialisation that append before the migration, QEMU should
not try to allocate again the VRAM of the vga emulation, because it's already
there. (The guest RAM is restored before calling QEMU)

And last but not least, in QEMU with Xen, a call to set_memory (with different
address for start_addr and phys_offset) actually move the the memory, and the
only way to have a pointer to this memory is to ask a ptr with the new addr.
So, there is a patch that check for the right guest address to map.

There is probably a better way to do some of this.

Change since v1:
  - rename xen_addr_actually_is to xen_phys_offset_to_gaddr.
  - give phys_offset_to_gaddr as a pointer to map_cache_init
    (no more global var in xen-all.c).
  - call xen_phys_offset_to_gaddr only if the first try fail.
  - also change a comment in the last patch.

Regards,


Anthony PERARD (5):
  vl.c: Do not save RAM state when Xen is used.
  xen mapcache: Check if a memory space has moved.
  Introduce premigrate RunState.
  xen: Change memory access behavior during migration.
  vga-cirrus: Workaround during restore when using Xen.

 hw/cirrus_vga.c  |   16 +++++++++++++---
 qapi-schema.json |    2 +-
 vl.c             |   10 ++++++++--
 xen-all.c        |   31 ++++++++++++++++++++++++++++++-
 xen-mapcache.c   |   22 +++++++++++++++++++---
 xen-mapcache.h   |    9 +++++++--
 6 files changed, 78 insertions(+), 12 deletions(-)

-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 21:55:52 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 21:55:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZ8Pf-0000of-Dm; Fri, 09 Dec 2011 21:55:27 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1RZ8Pd-0000o6-Gt
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 21:55:25 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1323467674!4965121!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDQ0MTg=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21724 invoked from network); 9 Dec 2011 21:54:35 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 21:54:35 -0000
X-IronPort-AV: E=Sophos;i="4.71,328,1320642000"; d="scan'208";a="19829077"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 16:54:33 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 16:54:32 -0500
Received: from perard.uk.xensource.com (dhcp-3-28.uk.xensource.com
	[10.80.3.28] (may be forged))	by smtp01.ad.xensource.com
	(8.13.1/8.13.1) with
	ESMTP id pB9LsThF011070;	Fri, 9 Dec 2011 13:54:31 -0800
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Fri, 9 Dec 2011 21:54:01 +0000
Message-ID: <1323467645-24271-2-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1323467645-24271-1-git-send-email-anthony.perard@citrix.com>
References: <1323467645-24271-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH V2 1/5] vl.c: Do not save RAM state when Xen is
	used.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

In Xen case, the guest RAM is not handle by QEMU, and it is saved by Xen tools.
So, we just avoid to register the RAM save state handler.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 vl.c |    6 ++++--
 1 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/vl.c b/vl.c
index f5afed4..e7dced2 100644
--- a/vl.c
+++ b/vl.c
@@ -3273,8 +3273,10 @@ int main(int argc, char **argv, char **envp)
     default_drive(default_sdcard, snapshot, machine->use_scsi,
                   IF_SD, 0, SD_OPTS);
 
-    register_savevm_live(NULL, "ram", 0, 4, NULL, ram_save_live, NULL,
-                         ram_load, NULL);
+    if (!xen_enabled()) {
+        register_savevm_live(NULL, "ram", 0, 4, NULL, ram_save_live, NULL,
+                             ram_load, NULL);
+    }
 
     if (nb_numa_nodes > 0) {
         int i;
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 21:55:52 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 21:55:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZ8Pf-0000of-Dm; Fri, 09 Dec 2011 21:55:27 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1RZ8Pd-0000o6-Gt
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 21:55:25 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1323467674!4965121!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDQ0MTg=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21724 invoked from network); 9 Dec 2011 21:54:35 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 21:54:35 -0000
X-IronPort-AV: E=Sophos;i="4.71,328,1320642000"; d="scan'208";a="19829077"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 16:54:33 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 16:54:32 -0500
Received: from perard.uk.xensource.com (dhcp-3-28.uk.xensource.com
	[10.80.3.28] (may be forged))	by smtp01.ad.xensource.com
	(8.13.1/8.13.1) with
	ESMTP id pB9LsThF011070;	Fri, 9 Dec 2011 13:54:31 -0800
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Fri, 9 Dec 2011 21:54:01 +0000
Message-ID: <1323467645-24271-2-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1323467645-24271-1-git-send-email-anthony.perard@citrix.com>
References: <1323467645-24271-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH V2 1/5] vl.c: Do not save RAM state when Xen is
	used.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

In Xen case, the guest RAM is not handle by QEMU, and it is saved by Xen tools.
So, we just avoid to register the RAM save state handler.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 vl.c |    6 ++++--
 1 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/vl.c b/vl.c
index f5afed4..e7dced2 100644
--- a/vl.c
+++ b/vl.c
@@ -3273,8 +3273,10 @@ int main(int argc, char **argv, char **envp)
     default_drive(default_sdcard, snapshot, machine->use_scsi,
                   IF_SD, 0, SD_OPTS);
 
-    register_savevm_live(NULL, "ram", 0, 4, NULL, ram_save_live, NULL,
-                         ram_load, NULL);
+    if (!xen_enabled()) {
+        register_savevm_live(NULL, "ram", 0, 4, NULL, ram_save_live, NULL,
+                             ram_load, NULL);
+    }
 
     if (nb_numa_nodes > 0) {
         int i;
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 21:55:53 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 21: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.xensource.com>)
	id 1RZ8Pf-0000oX-0Q; Fri, 09 Dec 2011 21:55:27 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1RZ8Pc-0000o5-Oh
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 21:55:24 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1323467672!6877235!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMTkxNzY=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18300 invoked from network); 9 Dec 2011 21:54:34 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 21:54:34 -0000
X-IronPort-AV: E=Sophos;i="4.71,328,1320642000"; d="scan'208";a="173624337"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 16:54:34 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 16:54:34 -0500
Received: from perard.uk.xensource.com (dhcp-3-28.uk.xensource.com
	[10.80.3.28] (may be forged))	by smtp01.ad.xensource.com
	(8.13.1/8.13.1) with
	ESMTP id pB9LsThG011070;	Fri, 9 Dec 2011 13:54:32 -0800
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Fri, 9 Dec 2011 21:54:02 +0000
Message-ID: <1323467645-24271-3-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1323467645-24271-1-git-send-email-anthony.perard@citrix.com>
References: <1323467645-24271-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH V2 2/5] xen mapcache: Check if a memory space
	has moved.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This patch change the xen_map_cache behavior. Before trying to map a guest
addr, mapcache will look into the list of range of address that have been moved
(physmap/set_memory). There is currently one memory space like this, the vram,
"moved" from were it's allocated to were the guest will look into.

This help to have a succefull migration.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 xen-all.c      |   18 +++++++++++++++++-
 xen-mapcache.c |   22 +++++++++++++++++++---
 xen-mapcache.h |    9 +++++++--
 3 files changed, 43 insertions(+), 6 deletions(-)

diff --git a/xen-all.c b/xen-all.c
index b5e28ab..b2e9853 100644
--- a/xen-all.c
+++ b/xen-all.c
@@ -218,6 +218,22 @@ static XenPhysmap *get_physmapping(XenIOState *state,
     return NULL;
 }
 
+static target_phys_addr_t xen_phys_offset_to_gaddr(target_phys_addr_t start_addr,
+                                                   ram_addr_t size, void *opaque)
+{
+    target_phys_addr_t addr = start_addr & TARGET_PAGE_MASK;
+    XenIOState *xen_io_state = opaque;
+    XenPhysmap *physmap = NULL;
+
+    QLIST_FOREACH(physmap, &xen_io_state->physmap, list) {
+        if (range_covers_byte(physmap->phys_offset, physmap->size, addr)) {
+            return physmap->start_addr;
+        }
+    }
+
+    return start_addr;
+}
+
 #if CONFIG_XEN_CTRL_INTERFACE_VERSION >= 340
 static int xen_add_to_physmap(XenIOState *state,
                               target_phys_addr_t start_addr,
@@ -938,7 +954,7 @@ int xen_hvm_init(void)
     }
 
     /* Init RAM management */
-    xen_map_cache_init();
+    xen_map_cache_init(xen_phys_offset_to_gaddr, state);
     xen_ram_init(ram_size);
 
     qemu_add_vm_change_state_handler(xen_hvm_change_state_handler, state);
diff --git a/xen-mapcache.c b/xen-mapcache.c
index 7bcb86e..d5f52b2 100644
--- a/xen-mapcache.c
+++ b/xen-mapcache.c
@@ -76,6 +76,9 @@ typedef struct MapCache {
     uint8_t *last_address_vaddr;
     unsigned long max_mcache_size;
     unsigned int mcache_bucket_shift;
+
+    phys_offset_to_gaddr_t phys_offset_to_gaddr;
+    void *opaque;
 } MapCache;
 
 static MapCache *mapcache;
@@ -89,13 +92,16 @@ static inline int test_bits(int nr, int size, const unsigned long *addr)
         return 0;
 }
 
-void xen_map_cache_init(void)
+void xen_map_cache_init(phys_offset_to_gaddr_t f, void *opaque)
 {
     unsigned long size;
     struct rlimit rlimit_as;
 
     mapcache = g_malloc0(sizeof (MapCache));
 
+    mapcache->phys_offset_to_gaddr = f;
+    mapcache->opaque = opaque;
+
     QTAILQ_INIT(&mapcache->locked_entries);
     mapcache->last_address_index = -1;
 
@@ -191,9 +197,14 @@ uint8_t *xen_map_cache(target_phys_addr_t phys_addr, target_phys_addr_t size,
                        uint8_t lock)
 {
     MapCacheEntry *entry, *pentry = NULL;
-    target_phys_addr_t address_index  = phys_addr >> MCACHE_BUCKET_SHIFT;
-    target_phys_addr_t address_offset = phys_addr & (MCACHE_BUCKET_SIZE - 1);
+    target_phys_addr_t address_index;
+    target_phys_addr_t address_offset;
     target_phys_addr_t __size = size;
+    bool translated = false;
+
+tryagain:
+    address_index  = phys_addr >> MCACHE_BUCKET_SHIFT;
+    address_offset = phys_addr & (MCACHE_BUCKET_SIZE - 1);
 
     trace_xen_map_cache(phys_addr);
 
@@ -235,6 +246,11 @@ uint8_t *xen_map_cache(target_phys_addr_t phys_addr, target_phys_addr_t size,
     if(!test_bits(address_offset >> XC_PAGE_SHIFT, size >> XC_PAGE_SHIFT,
                 entry->valid_mapping)) {
         mapcache->last_address_index = -1;
+        if (!translated && mapcache->phys_offset_to_gaddr) {
+            phys_addr = mapcache->phys_offset_to_gaddr(phys_addr, size, mapcache->opaque);
+            translated = true;
+            goto tryagain;
+        }
         trace_xen_map_cache_return(NULL);
         return NULL;
     }
diff --git a/xen-mapcache.h b/xen-mapcache.h
index da874ca..70301a5 100644
--- a/xen-mapcache.h
+++ b/xen-mapcache.h
@@ -11,9 +11,13 @@
 
 #include <stdlib.h>
 
+typedef target_phys_addr_t (*phys_offset_to_gaddr_t)(target_phys_addr_t start_addr,
+                                                     ram_addr_t size,
+                                                     void *opaque);
 #ifdef CONFIG_XEN
 
-void xen_map_cache_init(void);
+void xen_map_cache_init(phys_offset_to_gaddr_t f,
+                        void *opaque);
 uint8_t *xen_map_cache(target_phys_addr_t phys_addr, target_phys_addr_t size,
                        uint8_t lock);
 ram_addr_t xen_ram_addr_from_mapcache(void *ptr);
@@ -22,7 +26,8 @@ void xen_invalidate_map_cache(void);
 
 #else
 
-static inline void xen_map_cache_init(void)
+static inline void xen_map_cache_init(phys_offset_to_gaddr_t f,
+                                      void *opaque)
 {
 }
 
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 21:55:53 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 21: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.xensource.com>)
	id 1RZ8Pf-0000oX-0Q; Fri, 09 Dec 2011 21:55:27 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1RZ8Pc-0000o5-Oh
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 21:55:24 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1323467672!6877235!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMTkxNzY=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18300 invoked from network); 9 Dec 2011 21:54:34 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 21:54:34 -0000
X-IronPort-AV: E=Sophos;i="4.71,328,1320642000"; d="scan'208";a="173624337"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 16:54:34 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 16:54:34 -0500
Received: from perard.uk.xensource.com (dhcp-3-28.uk.xensource.com
	[10.80.3.28] (may be forged))	by smtp01.ad.xensource.com
	(8.13.1/8.13.1) with
	ESMTP id pB9LsThG011070;	Fri, 9 Dec 2011 13:54:32 -0800
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Fri, 9 Dec 2011 21:54:02 +0000
Message-ID: <1323467645-24271-3-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1323467645-24271-1-git-send-email-anthony.perard@citrix.com>
References: <1323467645-24271-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH V2 2/5] xen mapcache: Check if a memory space
	has moved.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This patch change the xen_map_cache behavior. Before trying to map a guest
addr, mapcache will look into the list of range of address that have been moved
(physmap/set_memory). There is currently one memory space like this, the vram,
"moved" from were it's allocated to were the guest will look into.

This help to have a succefull migration.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 xen-all.c      |   18 +++++++++++++++++-
 xen-mapcache.c |   22 +++++++++++++++++++---
 xen-mapcache.h |    9 +++++++--
 3 files changed, 43 insertions(+), 6 deletions(-)

diff --git a/xen-all.c b/xen-all.c
index b5e28ab..b2e9853 100644
--- a/xen-all.c
+++ b/xen-all.c
@@ -218,6 +218,22 @@ static XenPhysmap *get_physmapping(XenIOState *state,
     return NULL;
 }
 
+static target_phys_addr_t xen_phys_offset_to_gaddr(target_phys_addr_t start_addr,
+                                                   ram_addr_t size, void *opaque)
+{
+    target_phys_addr_t addr = start_addr & TARGET_PAGE_MASK;
+    XenIOState *xen_io_state = opaque;
+    XenPhysmap *physmap = NULL;
+
+    QLIST_FOREACH(physmap, &xen_io_state->physmap, list) {
+        if (range_covers_byte(physmap->phys_offset, physmap->size, addr)) {
+            return physmap->start_addr;
+        }
+    }
+
+    return start_addr;
+}
+
 #if CONFIG_XEN_CTRL_INTERFACE_VERSION >= 340
 static int xen_add_to_physmap(XenIOState *state,
                               target_phys_addr_t start_addr,
@@ -938,7 +954,7 @@ int xen_hvm_init(void)
     }
 
     /* Init RAM management */
-    xen_map_cache_init();
+    xen_map_cache_init(xen_phys_offset_to_gaddr, state);
     xen_ram_init(ram_size);
 
     qemu_add_vm_change_state_handler(xen_hvm_change_state_handler, state);
diff --git a/xen-mapcache.c b/xen-mapcache.c
index 7bcb86e..d5f52b2 100644
--- a/xen-mapcache.c
+++ b/xen-mapcache.c
@@ -76,6 +76,9 @@ typedef struct MapCache {
     uint8_t *last_address_vaddr;
     unsigned long max_mcache_size;
     unsigned int mcache_bucket_shift;
+
+    phys_offset_to_gaddr_t phys_offset_to_gaddr;
+    void *opaque;
 } MapCache;
 
 static MapCache *mapcache;
@@ -89,13 +92,16 @@ static inline int test_bits(int nr, int size, const unsigned long *addr)
         return 0;
 }
 
-void xen_map_cache_init(void)
+void xen_map_cache_init(phys_offset_to_gaddr_t f, void *opaque)
 {
     unsigned long size;
     struct rlimit rlimit_as;
 
     mapcache = g_malloc0(sizeof (MapCache));
 
+    mapcache->phys_offset_to_gaddr = f;
+    mapcache->opaque = opaque;
+
     QTAILQ_INIT(&mapcache->locked_entries);
     mapcache->last_address_index = -1;
 
@@ -191,9 +197,14 @@ uint8_t *xen_map_cache(target_phys_addr_t phys_addr, target_phys_addr_t size,
                        uint8_t lock)
 {
     MapCacheEntry *entry, *pentry = NULL;
-    target_phys_addr_t address_index  = phys_addr >> MCACHE_BUCKET_SHIFT;
-    target_phys_addr_t address_offset = phys_addr & (MCACHE_BUCKET_SIZE - 1);
+    target_phys_addr_t address_index;
+    target_phys_addr_t address_offset;
     target_phys_addr_t __size = size;
+    bool translated = false;
+
+tryagain:
+    address_index  = phys_addr >> MCACHE_BUCKET_SHIFT;
+    address_offset = phys_addr & (MCACHE_BUCKET_SIZE - 1);
 
     trace_xen_map_cache(phys_addr);
 
@@ -235,6 +246,11 @@ uint8_t *xen_map_cache(target_phys_addr_t phys_addr, target_phys_addr_t size,
     if(!test_bits(address_offset >> XC_PAGE_SHIFT, size >> XC_PAGE_SHIFT,
                 entry->valid_mapping)) {
         mapcache->last_address_index = -1;
+        if (!translated && mapcache->phys_offset_to_gaddr) {
+            phys_addr = mapcache->phys_offset_to_gaddr(phys_addr, size, mapcache->opaque);
+            translated = true;
+            goto tryagain;
+        }
         trace_xen_map_cache_return(NULL);
         return NULL;
     }
diff --git a/xen-mapcache.h b/xen-mapcache.h
index da874ca..70301a5 100644
--- a/xen-mapcache.h
+++ b/xen-mapcache.h
@@ -11,9 +11,13 @@
 
 #include <stdlib.h>
 
+typedef target_phys_addr_t (*phys_offset_to_gaddr_t)(target_phys_addr_t start_addr,
+                                                     ram_addr_t size,
+                                                     void *opaque);
 #ifdef CONFIG_XEN
 
-void xen_map_cache_init(void);
+void xen_map_cache_init(phys_offset_to_gaddr_t f,
+                        void *opaque);
 uint8_t *xen_map_cache(target_phys_addr_t phys_addr, target_phys_addr_t size,
                        uint8_t lock);
 ram_addr_t xen_ram_addr_from_mapcache(void *ptr);
@@ -22,7 +26,8 @@ void xen_invalidate_map_cache(void);
 
 #else
 
-static inline void xen_map_cache_init(void)
+static inline void xen_map_cache_init(phys_offset_to_gaddr_t f,
+                                      void *opaque)
 {
 }
 
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 21:55:53 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 21: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.xensource.com>)
	id 1RZ8Ph-0000pF-Cy; Fri, 09 Dec 2011 21:55:29 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1RZ8Pf-0000o8-5L
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 21:55:27 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1323467672!6877235!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMTkxNzY=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18315 invoked from network); 9 Dec 2011 21:54:37 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 21:54:37 -0000
X-IronPort-AV: E=Sophos;i="4.71,328,1320642000"; d="scan'208";a="173624343"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 16:54:36 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 16:54:36 -0500
Received: from perard.uk.xensource.com (dhcp-3-28.uk.xensource.com
	[10.80.3.28] (may be forged))	by smtp01.ad.xensource.com
	(8.13.1/8.13.1) with
	ESMTP id pB9LsThI011070;	Fri, 9 Dec 2011 13:54:35 -0800
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Fri, 9 Dec 2011 21:54:04 +0000
Message-ID: <1323467645-24271-5-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1323467645-24271-1-git-send-email-anthony.perard@citrix.com>
References: <1323467645-24271-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH V2 4/5] xen: Change memory access behavior
	during migration.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Do not allocate RAM during pre-migration runstate.
Do not actually "do" set_memory during migration.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 xen-all.c |   13 +++++++++++++
 1 files changed, 13 insertions(+), 0 deletions(-)

diff --git a/xen-all.c b/xen-all.c
index b2e9853..c1fed87 100644
--- a/xen-all.c
+++ b/xen-all.c
@@ -189,6 +189,11 @@ void xen_ram_alloc(ram_addr_t ram_addr, ram_addr_t size)
 
     trace_xen_ram_alloc(ram_addr, size);
 
+    if (runstate_check(RUN_STATE_PREMIGRATE)) {
+        /* RAM already populated in Xen */
+        return;
+    }
+
     nr_pfn = size >> TARGET_PAGE_BITS;
     pfn_list = g_malloc(sizeof (*pfn_list) * nr_pfn);
 
@@ -269,6 +274,13 @@ go_physmap:
     DPRINTF("mapping vram to %llx - %llx, from %llx\n",
             start_addr, start_addr + size, phys_offset);
 
+    if (runstate_check(RUN_STATE_INMIGRATE)) {
+        /* The mapping should already be done and can not be done a second
+         * time. So we just add to the physmap list instead.
+         */
+        goto done;
+    }
+
     pfn = phys_offset >> TARGET_PAGE_BITS;
     start_gpfn = start_addr >> TARGET_PAGE_BITS;
     for (i = 0; i < size >> TARGET_PAGE_BITS; i++) {
@@ -283,6 +295,7 @@ go_physmap:
         }
     }
 
+done:
     physmap = g_malloc(sizeof (XenPhysmap));
 
     physmap->start_addr = start_addr;
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 21:55:53 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 21: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.xensource.com>)
	id 1RZ8Ph-0000pF-Cy; Fri, 09 Dec 2011 21:55:29 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1RZ8Pf-0000o8-5L
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 21:55:27 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1323467672!6877235!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMTkxNzY=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18315 invoked from network); 9 Dec 2011 21:54:37 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 21:54:37 -0000
X-IronPort-AV: E=Sophos;i="4.71,328,1320642000"; d="scan'208";a="173624343"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 16:54:36 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 16:54:36 -0500
Received: from perard.uk.xensource.com (dhcp-3-28.uk.xensource.com
	[10.80.3.28] (may be forged))	by smtp01.ad.xensource.com
	(8.13.1/8.13.1) with
	ESMTP id pB9LsThI011070;	Fri, 9 Dec 2011 13:54:35 -0800
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Fri, 9 Dec 2011 21:54:04 +0000
Message-ID: <1323467645-24271-5-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1323467645-24271-1-git-send-email-anthony.perard@citrix.com>
References: <1323467645-24271-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH V2 4/5] xen: Change memory access behavior
	during migration.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Do not allocate RAM during pre-migration runstate.
Do not actually "do" set_memory during migration.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 xen-all.c |   13 +++++++++++++
 1 files changed, 13 insertions(+), 0 deletions(-)

diff --git a/xen-all.c b/xen-all.c
index b2e9853..c1fed87 100644
--- a/xen-all.c
+++ b/xen-all.c
@@ -189,6 +189,11 @@ void xen_ram_alloc(ram_addr_t ram_addr, ram_addr_t size)
 
     trace_xen_ram_alloc(ram_addr, size);
 
+    if (runstate_check(RUN_STATE_PREMIGRATE)) {
+        /* RAM already populated in Xen */
+        return;
+    }
+
     nr_pfn = size >> TARGET_PAGE_BITS;
     pfn_list = g_malloc(sizeof (*pfn_list) * nr_pfn);
 
@@ -269,6 +274,13 @@ go_physmap:
     DPRINTF("mapping vram to %llx - %llx, from %llx\n",
             start_addr, start_addr + size, phys_offset);
 
+    if (runstate_check(RUN_STATE_INMIGRATE)) {
+        /* The mapping should already be done and can not be done a second
+         * time. So we just add to the physmap list instead.
+         */
+        goto done;
+    }
+
     pfn = phys_offset >> TARGET_PAGE_BITS;
     start_gpfn = start_addr >> TARGET_PAGE_BITS;
     for (i = 0; i < size >> TARGET_PAGE_BITS; i++) {
@@ -283,6 +295,7 @@ go_physmap:
         }
     }
 
+done:
     physmap = g_malloc(sizeof (XenPhysmap));
 
     physmap->start_addr = start_addr;
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 21:55:53 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 21: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.xensource.com>)
	id 1RZ8Pf-0000op-Pz; Fri, 09 Dec 2011 21:55:27 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1RZ8Pd-0000o7-SH
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 21:55:26 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1323467674!4965121!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDQ0MTg=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21914 invoked from network); 9 Dec 2011 21:54:36 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 21:54:36 -0000
X-IronPort-AV: E=Sophos;i="4.71,328,1320642000"; d="scan'208";a="19829078"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 16:54:35 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 16:54:35 -0500
Received: from perard.uk.xensource.com (dhcp-3-28.uk.xensource.com
	[10.80.3.28] (may be forged))	by smtp01.ad.xensource.com
	(8.13.1/8.13.1) with
	ESMTP id pB9LsThH011070;	Fri, 9 Dec 2011 13:54:33 -0800
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Fri, 9 Dec 2011 21:54:03 +0000
Message-ID: <1323467645-24271-4-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1323467645-24271-1-git-send-email-anthony.perard@citrix.com>
References: <1323467645-24271-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH V2 3/5] Introduce premigrate RunState.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This new state will be used by Xen functions to know QEMU will wait for a
migration. This is important to know for memory related function because the
memory is already allocated and reallocated them will not works.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 qapi-schema.json |    2 +-
 vl.c             |    4 ++++
 2 files changed, 5 insertions(+), 1 deletions(-)

diff --git a/qapi-schema.json b/qapi-schema.json
index cb1ba77..bd77444 100644
--- a/qapi-schema.json
+++ b/qapi-schema.json
@@ -121,7 +121,7 @@
 { 'enum': 'RunState',
   'data': [ 'debug', 'inmigrate', 'internal-error', 'io-error', 'paused',
             'postmigrate', 'prelaunch', 'finish-migrate', 'restore-vm',
-            'running', 'save-vm', 'shutdown', 'watchdog' ] }
+            'running', 'save-vm', 'shutdown', 'watchdog', 'premigrate' ] }
 
 ##
 # @StatusInfo:
diff --git a/vl.c b/vl.c
index e7dced2..a291416 100644
--- a/vl.c
+++ b/vl.c
@@ -351,8 +351,11 @@ static const RunStateTransition runstate_transitions_def[] = {
 
     { RUN_STATE_PRELAUNCH, RUN_STATE_RUNNING },
     { RUN_STATE_PRELAUNCH, RUN_STATE_FINISH_MIGRATE },
+    { RUN_STATE_PRELAUNCH, RUN_STATE_PREMIGRATE },
     { RUN_STATE_PRELAUNCH, RUN_STATE_INMIGRATE },
 
+    { RUN_STATE_PREMIGRATE, RUN_STATE_INMIGRATE },
+
     { RUN_STATE_FINISH_MIGRATE, RUN_STATE_RUNNING },
     { RUN_STATE_FINISH_MIGRATE, RUN_STATE_POSTMIGRATE },
 
@@ -2975,6 +2978,7 @@ int main(int argc, char **argv, char **envp)
                 break;
             case QEMU_OPTION_incoming:
                 incoming = optarg;
+                runstate_set(RUN_STATE_PREMIGRATE);
                 break;
             case QEMU_OPTION_nodefaults:
                 default_serial = 0;
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 21:55:53 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 21: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.xensource.com>)
	id 1RZ8Pf-0000op-Pz; Fri, 09 Dec 2011 21:55:27 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1RZ8Pd-0000o7-SH
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 21:55:26 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1323467674!4965121!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDQ0MTg=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21914 invoked from network); 9 Dec 2011 21:54:36 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 21:54:36 -0000
X-IronPort-AV: E=Sophos;i="4.71,328,1320642000"; d="scan'208";a="19829078"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 16:54:35 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 16:54:35 -0500
Received: from perard.uk.xensource.com (dhcp-3-28.uk.xensource.com
	[10.80.3.28] (may be forged))	by smtp01.ad.xensource.com
	(8.13.1/8.13.1) with
	ESMTP id pB9LsThH011070;	Fri, 9 Dec 2011 13:54:33 -0800
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Fri, 9 Dec 2011 21:54:03 +0000
Message-ID: <1323467645-24271-4-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1323467645-24271-1-git-send-email-anthony.perard@citrix.com>
References: <1323467645-24271-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH V2 3/5] Introduce premigrate RunState.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This new state will be used by Xen functions to know QEMU will wait for a
migration. This is important to know for memory related function because the
memory is already allocated and reallocated them will not works.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 qapi-schema.json |    2 +-
 vl.c             |    4 ++++
 2 files changed, 5 insertions(+), 1 deletions(-)

diff --git a/qapi-schema.json b/qapi-schema.json
index cb1ba77..bd77444 100644
--- a/qapi-schema.json
+++ b/qapi-schema.json
@@ -121,7 +121,7 @@
 { 'enum': 'RunState',
   'data': [ 'debug', 'inmigrate', 'internal-error', 'io-error', 'paused',
             'postmigrate', 'prelaunch', 'finish-migrate', 'restore-vm',
-            'running', 'save-vm', 'shutdown', 'watchdog' ] }
+            'running', 'save-vm', 'shutdown', 'watchdog', 'premigrate' ] }
 
 ##
 # @StatusInfo:
diff --git a/vl.c b/vl.c
index e7dced2..a291416 100644
--- a/vl.c
+++ b/vl.c
@@ -351,8 +351,11 @@ static const RunStateTransition runstate_transitions_def[] = {
 
     { RUN_STATE_PRELAUNCH, RUN_STATE_RUNNING },
     { RUN_STATE_PRELAUNCH, RUN_STATE_FINISH_MIGRATE },
+    { RUN_STATE_PRELAUNCH, RUN_STATE_PREMIGRATE },
     { RUN_STATE_PRELAUNCH, RUN_STATE_INMIGRATE },
 
+    { RUN_STATE_PREMIGRATE, RUN_STATE_INMIGRATE },
+
     { RUN_STATE_FINISH_MIGRATE, RUN_STATE_RUNNING },
     { RUN_STATE_FINISH_MIGRATE, RUN_STATE_POSTMIGRATE },
 
@@ -2975,6 +2978,7 @@ int main(int argc, char **argv, char **envp)
                 break;
             case QEMU_OPTION_incoming:
                 incoming = optarg;
+                runstate_set(RUN_STATE_PREMIGRATE);
                 break;
             case QEMU_OPTION_nodefaults:
                 default_serial = 0;
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 21:55:54 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 21:55:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZ8Ph-0000pO-Rm; Fri, 09 Dec 2011 21:55:29 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1RZ8Pg-0000o9-9w
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 21:55:28 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1323467672!6877235!4
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMTkxNzY=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18341 invoked from network); 9 Dec 2011 21:54:38 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 21:54:38 -0000
X-IronPort-AV: E=Sophos;i="4.71,328,1320642000"; d="scan'208";a="173624346"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 16:54:37 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 16:54:37 -0500
Received: from perard.uk.xensource.com (dhcp-3-28.uk.xensource.com
	[10.80.3.28] (may be forged))	by smtp01.ad.xensource.com
	(8.13.1/8.13.1) with
	ESMTP id pB9LsThJ011070;	Fri, 9 Dec 2011 13:54:36 -0800
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Fri, 9 Dec 2011 21:54:05 +0000
Message-ID: <1323467645-24271-6-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1323467645-24271-1-git-send-email-anthony.perard@citrix.com>
References: <1323467645-24271-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH V2 5/5] vga-cirrus: Workaround during restore
	when using Xen.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

During the initialisation of the machine at restore time, the access to the
VRAM will fail because QEMU does not know yet the right guest address to map,
so the vram_ptr is NULL.

So this patch avoid using a NULL pointer during initialisation, and try to get
another vram_ptr if the call failed the first time.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 hw/cirrus_vga.c |   16 +++++++++++++---
 1 files changed, 13 insertions(+), 3 deletions(-)

diff --git a/hw/cirrus_vga.c b/hw/cirrus_vga.c
index c7e365b..2e049c9 100644
--- a/hw/cirrus_vga.c
+++ b/hw/cirrus_vga.c
@@ -32,6 +32,7 @@
 #include "console.h"
 #include "vga_int.h"
 #include "loader.h"
+#include "sysemu.h"
 
 /*
  * TODO:
@@ -2696,6 +2697,13 @@ static int cirrus_post_load(void *opaque, int version_id)
     s->vga.gr[0x01] = s->cirrus_shadow_gr1 & 0x0f;
 
     cirrus_update_memory_access(s);
+    if (!s->vga.vram_ptr) {
+        /* At this point vga.vram_ptr can be invalid on Xen because we need to
+         * know the position of the videoram in the guest physical address space in
+         * order to be able to map it. After cirrus_update_memory_access we do know
+         * where the videoram is, so let's map it now. */
+        s->vga.vram_ptr = memory_region_get_ram_ptr(&s->vga.vram);
+    }
     /* force refresh */
     s->vga.graphic_mode = -1;
     cirrus_update_bank_ptr(s, 0);
@@ -2784,9 +2792,11 @@ static void cirrus_reset(void *opaque)
     }
     s->vga.cr[0x27] = s->device_id;
 
-    /* Win2K seems to assume that the pattern buffer is at 0xff
-       initially ! */
-    memset(s->vga.vram_ptr, 0xff, s->real_vram_size);
+    if (!runstate_check(RUN_STATE_PREMIGRATE)) {
+        /* Win2K seems to assume that the pattern buffer is at 0xff
+           initially ! */
+        memset(s->vga.vram_ptr, 0xff, s->real_vram_size);
+    }
 
     s->cirrus_hidden_dac_lockindex = 5;
     s->cirrus_hidden_dac_data = 0;
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 21:55:54 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 21:55:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZ8Ph-0000pO-Rm; Fri, 09 Dec 2011 21:55:29 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1RZ8Pg-0000o9-9w
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 21:55:28 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1323467672!6877235!4
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMTkxNzY=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18341 invoked from network); 9 Dec 2011 21:54:38 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 21:54:38 -0000
X-IronPort-AV: E=Sophos;i="4.71,328,1320642000"; d="scan'208";a="173624346"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 16:54:37 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 16:54:37 -0500
Received: from perard.uk.xensource.com (dhcp-3-28.uk.xensource.com
	[10.80.3.28] (may be forged))	by smtp01.ad.xensource.com
	(8.13.1/8.13.1) with
	ESMTP id pB9LsThJ011070;	Fri, 9 Dec 2011 13:54:36 -0800
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Fri, 9 Dec 2011 21:54:05 +0000
Message-ID: <1323467645-24271-6-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1323467645-24271-1-git-send-email-anthony.perard@citrix.com>
References: <1323467645-24271-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH V2 5/5] vga-cirrus: Workaround during restore
	when using Xen.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

During the initialisation of the machine at restore time, the access to the
VRAM will fail because QEMU does not know yet the right guest address to map,
so the vram_ptr is NULL.

So this patch avoid using a NULL pointer during initialisation, and try to get
another vram_ptr if the call failed the first time.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 hw/cirrus_vga.c |   16 +++++++++++++---
 1 files changed, 13 insertions(+), 3 deletions(-)

diff --git a/hw/cirrus_vga.c b/hw/cirrus_vga.c
index c7e365b..2e049c9 100644
--- a/hw/cirrus_vga.c
+++ b/hw/cirrus_vga.c
@@ -32,6 +32,7 @@
 #include "console.h"
 #include "vga_int.h"
 #include "loader.h"
+#include "sysemu.h"
 
 /*
  * TODO:
@@ -2696,6 +2697,13 @@ static int cirrus_post_load(void *opaque, int version_id)
     s->vga.gr[0x01] = s->cirrus_shadow_gr1 & 0x0f;
 
     cirrus_update_memory_access(s);
+    if (!s->vga.vram_ptr) {
+        /* At this point vga.vram_ptr can be invalid on Xen because we need to
+         * know the position of the videoram in the guest physical address space in
+         * order to be able to map it. After cirrus_update_memory_access we do know
+         * where the videoram is, so let's map it now. */
+        s->vga.vram_ptr = memory_region_get_ram_ptr(&s->vga.vram);
+    }
     /* force refresh */
     s->vga.graphic_mode = -1;
     cirrus_update_bank_ptr(s, 0);
@@ -2784,9 +2792,11 @@ static void cirrus_reset(void *opaque)
     }
     s->vga.cr[0x27] = s->device_id;
 
-    /* Win2K seems to assume that the pattern buffer is at 0xff
-       initially ! */
-    memset(s->vga.vram_ptr, 0xff, s->real_vram_size);
+    if (!runstate_check(RUN_STATE_PREMIGRATE)) {
+        /* Win2K seems to assume that the pattern buffer is at 0xff
+           initially ! */
+        memset(s->vga.vram_ptr, 0xff, s->real_vram_size);
+    }
 
     s->cirrus_hidden_dac_lockindex = 5;
     s->cirrus_hidden_dac_data = 0;
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 22:03:44 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 22:03:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZ8XO-0001vV-RK; Fri, 09 Dec 2011 22:03:26 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <thunderbird2k@gmail.com>) id 1RZ8XM-0001v5-Lp
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 22:03:25 +0000
X-Env-Sender: thunderbird2k@gmail.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1323468151!4774342!1
X-Originating-IP: [209.85.213.171]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22818 invoked from network); 9 Dec 2011 22:02:33 -0000
Received: from mail-yx0-f171.google.com (HELO mail-yx0-f171.google.com)
	(209.85.213.171)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 22:02:33 -0000
Received: by yenr9 with SMTP id r9so50751721yen.30
	for <xen-devel@lists.xensource.com>;
	Fri, 09 Dec 2011 14:02:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	bh=CsWrM6RZVSRtcmxIV/Det5MbMkAtyI0wZ0FqYFUn26E=;
	b=gWx2163c2TdGC2t6Js4SpQQSXls5KD6UEoFquAHaI0VqHEf9k7YggXTGVUDAN7jfsZ
	U+Q918jkjs23LHP8deG5fKeB0go2d2mirGnTD8PdSpAT+Ck8ewWXShxsIJODGZyfez06
	zdBaKQYXKyFmpZ/Xc748OdluKRyAhvEV0h9OM=
MIME-Version: 1.0
Received: by 10.236.155.170 with SMTP id j30mr14914913yhk.56.1323468151102;
	Fri, 09 Dec 2011 14:02:31 -0800 (PST)
Received: by 10.100.48.10 with HTTP; Fri, 9 Dec 2011 14:02:31 -0800 (PST)
In-Reply-To: <CAEc3jaC9=HiMoxSYZmXKRzoFcMYRaT9jrX3m1ZQO+M8CrH35Fg@mail.gmail.com>
References: <CAEc3jaBds7xmiKH8RMfmEHQumkEeZ3PopVfbZPs_B-Kz8-DsWw@mail.gmail.com>
	<4ED51291.1010308@hfp.de>
	<CAEc3jaAa7y8C2NNBn1=L3AhS0uuYFP6ze8o1cZ9yG2VYHx6qMA@mail.gmail.com>
	<4ED5215D.1010403@hfp.de>
	<20111129230212.GA23958@andromeda.dapyr.net>
	<CAEc3jaAO0JhtOt6phQHwtE_A+NF7uGHGZ8uJv3BirEYybfVceg@mail.gmail.com>
	<CAEc3jaACffpr9D1Hq_012vHAGhPLEfvsZjh7YyJ=Q-3FdtHS0Q@mail.gmail.com>
	<CAPbh3rtOQ1HTPReqYcpE3vzk+-na0MTLLHZD15=Fg4yxB+ypaA@mail.gmail.com>
	<CAEc3jaBdQKmVJToNZRf+25GtJXqGc274ieHf_yHKRJ+YOKWdgA@mail.gmail.com>
	<20111208234624.GD32474@konrad-lan>
	<CAEc3jaC9=HiMoxSYZmXKRzoFcMYRaT9jrX3m1ZQO+M8CrH35Fg@mail.gmail.com>
Date: Fri, 9 Dec 2011 14:02:31 -0800
Message-ID: <CAEc3jaBBYBME0G3Ku_sTvzQz+oKQnpBPffA+bRUKxxRPABAeww@mail.gmail.com>
From: Roderick Colenbrander <thunderbird2k@gmail.com>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
Cc: xen-devel@lists.xensource.com, Andreas Kinzler <ml-xen-devel@hfp.de>
Subject: Re: [Xen-devel] Questions about GPLPV stability tests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

One interesting observation. This morning I had another of my stress
machines with the problem. I never had it on this problem before and
it didn't have any of the new logging / software updates yet.

The system was in the same state as the other machine which I reported
about before. I tried SysRq stuff and other things. While I was about
to reboot the system, a login prompt appeared again on the VGA. I
don't know whether any of the stuff I did triggered it or not. Anyway
it means Linux is not really dead. I tried logging, but I don't even
see characters appearing. The system feels to be very, very, very
slow.

The other tests are still running.

Roderick

On Thu, Dec 8, 2011 at 5:33 PM, Roderick Colenbrander
<thunderbird2k@gmail.com> wrote:
> On Thu, Dec 8, 2011 at 11:46 PM, Konrad Rzeszutek Wilk
> <konrad@darnok.org> wrote:
>> On Wed, Dec 07, 2011 at 08:44:19PM +0000, Roderick Colenbrander wrote:
>>> On Wed, Dec 7, 2011 at 8:38 PM, Konrad Rzeszutek Wilk <konrad@darnok.or=
g> wrote:
>>> >> It took about a week, but the systems went down again. Linux is down,
>>> >> but the hypervisor is still reachable on the serial console. Is there
>>> >> anything interesting to dump from there?
>>> >>
>>> > Just the interrupts information. I think that is Ctrl-A, Ctrl-A,
>>> > Ctrl-A, and then '*' to capture everything (I don't remember the right
>>> > one for just interrupts).
>>>
>>> Here's the interrupt information:
>>> (XEN) [2011-12-06 19:13:37] [i: dump interrupt bindings]
>>> (XEN) [2011-12-06 19:13:37] Guest interrupt information:
>>> (XEN) [2011-12-06 19:13:37] =A0 =A0IRQ: =A0 0
>>> affinity:00000000,00000000,00000000,00000001 vec:f0 type=3DIO-APIC-edge
>>> =A0 status=3D00000000 mapped, unbound
>>> (XEN) [2011-12-06 19:13:37] =A0 =A0IRQ: =A0 1
>>> affinity:00000000,00000000,00000000,00000001 vec:30 type=3DIO-APIC-edge
>>> =A0 status=3D00000014 in-flight=3D0 domain-list=3D0: =A01(-S--),
>>> (XEN) [2011-12-06 19:13:37] =A0 =A0IRQ: =A0 2
>>> affinity:ffffffff,ffffffff,ffffffff,ffffffff vec:e2 type=3DXT-PIC
>>> =A0 status=3D00000000 mapped, unbound
>>> (XEN) [2011-12-06 19:13:37] =A0 =A0IRQ: =A0 3
>>> affinity:00000000,00000000,00000000,00000001 vec:38 type=3DIO-APIC-edge
>>> =A0 status=3D00000006 mapped, unbound
>>> (XEN) [2011-12-06 19:13:37] =A0 =A0IRQ: =A0 4
>>> affinity:00000000,00000000,00000000,00000001 vec:40 type=3DIO-APIC-edge
>>> =A0 status=3D00000002 mapped, unbound
>>> (XEN) [2011-12-06 19:13:37] =A0 =A0IRQ: =A0 5
>>> affinity:00000000,00000000,00000000,00000001 vec:f1 type=3DIO-APIC-edge
>>> =A0 status=3D00000000 mapped, unbound
>>> (XEN) [2011-12-06 19:13:37] =A0 =A0IRQ: =A0 6
>>> affinity:00000000,00000000,00000000,00000001 vec:48 type=3DIO-APIC-edge
>>> =A0 status=3D00000002 mapped, unbound
>>> (XEN) [2011-12-06 19:13:37] =A0 =A0IRQ: =A0 7
>>> affinity:00000000,00000000,00000000,00000001 vec:50 type=3DIO-APIC-edge
>>> =A0 status=3D00000002 mapped, unbound
>>> (XEN) [2011-12-06 19:13:37] =A0 =A0IRQ: =A0 8
>>> affinity:00000000,00000000,00000000,00000001 vec:58 type=3DIO-APIC-edge
>>> =A0 status=3D00000010 in-flight=3D0 domain-list=3D0: =A08(-S--),
>>> (XEN) [2011-12-06 19:13:37] =A0 =A0IRQ: =A0 9
>>> affinity:00000000,00000000,00000000,00000001 vec:60 type=3DIO-APIC-level
>>> =A0 status=3D00000010 in-flight=3D0 domain-list=3D0: =A09(-S--),
>>> (XEN) [2011-12-06 19:13:37] =A0 =A0IRQ: =A010
>>> affinity:00000000,00000000,00000000,00000001 vec:68 type=3DIO-APIC-edge
>>> =A0 status=3D00000002 mapped, unbound
>>> (XEN) [2011-12-06 19:13:37] =A0 =A0IRQ: =A011
>>> affinity:00000000,00000000,00000000,00000001 vec:70 type=3DIO-APIC-edge
>>> =A0 status=3D00000002 mapped, unbound
>>> (XEN) [2011-12-06 19:13:37] =A0 =A0IRQ: =A012
>>> affinity:00000000,00000000,00000000,00000001 vec:78 type=3DIO-APIC-edge
>>> =A0 status=3D00000010 in-flight=3D0 domain-list=3D0: 12(-S--),
>>> (XEN) [2011-12-06 19:13:37] =A0 =A0IRQ: =A013
>>> affinity:00000000,00000000,00000000,00000001 vec:88 type=3DIO-APIC-edge
>>> =A0 status=3D00000002 mapped, unbound
>>> (XEN) [2011-12-06 19:13:37] =A0 =A0IRQ: =A014
>>> affinity:00000000,00000000,00000000,00000001 vec:90 type=3DIO-APIC-edge
>>> =A0 status=3D00000002 mapped, unbound
>>> (XEN) [2011-12-06 19:13:37] =A0 =A0IRQ: =A015
>>> affinity:00000000,00000000,00000000,00000001 vec:98 type=3DIO-APIC-edge
>>> =A0 status=3D00000002 mapped, unbound
>>> (XEN) [2011-12-06 19:13:37] =A0 =A0IRQ: =A016
>>> affinity:00000000,00000000,00000000,00000001 vec:c8 type=3DIO-APIC-level
>>> =A0 status=3D00000010 in-flight=3D0 domain-list=3D0: 16(-S--),1201: 16(=
--M-),
>>> (XEN) [2011-12-06 19:13:37] =A0 =A0IRQ: =A018
>>> affinity:00000000,00000000,00000000,00000001 vec:51 type=3DIO-APIC-level
>>> =A0 status=3D00000010 in-flight=3D0 domain-list=3D0: 18(-S--),
>>> (XEN) [2011-12-06 19:13:37] =A0 =A0IRQ: =A019
>>> affinity:00000000,00000000,00000000,00000001 vec:d0 type=3DIO-APIC-level
>>> =A0 status=3D00000010 in-flight=3D0 domain-list=3D0: 19(-S--),
>>> (XEN) [2011-12-06 19:13:37] =A0 =A0IRQ: =A021
>>> affinity:00000000,00000000,00000000,00000001 vec:61 type=3DIO-APIC-level
>>> =A0 status=3D00000010 in-flight=3D0 domain-list=3D0: 21(-S--),
>>> (XEN) [2011-12-06 19:13:37] =A0 =A0IRQ: =A023
>>> affinity:00000000,00000000,00000000,00000001 vec:59 type=3DIO-APIC-level
>>> =A0 status=3D00000010 in-flight=3D1 domain-list=3D0: 23(PS-M),
>>> (XEN) [2011-12-06 19:13:37] =A0 =A0IRQ: =A024
>>> affinity:00000000,00000000,00000000,00000001 vec:28 type=3DDMA_MSI
>>> =A0 status=3D00000000 mapped, unbound
>>> (XEN) [2011-12-06 19:13:38] =A0 =A0IRQ: =A025
>>> affinity:00000000,00000000,00000000,00000001 vec:a0 type=3DPCI-MSI
>>> =A0 status=3D00000002 mapped, unbound
>>> (XEN) [2011-12-06 19:13:38] =A0 =A0IRQ: =A026
>>> affinity:00000000,00000000,00000000,00000001 vec:a8 type=3DPCI-MSI
>>> =A0 status=3D00000002 mapped, unbound
>>> (XEN) [2011-12-06 19:13:38] =A0 =A0IRQ: =A027
>>> affinity:00000000,00000000,00000000,00000001 vec:b0 type=3DPCI-MSI
>>> =A0 status=3D00000002 mapped, unbound
>>> (XEN) [2011-12-06 19:13:38] =A0 =A0IRQ: =A028
>>> affinity:00000000,00000000,00000000,00000001 vec:b8 type=3DPCI-MSI
>>> =A0 status=3D00000002 mapped, unbound
>>> (XEN) [2011-12-06 19:13:38] =A0 =A0IRQ: =A029
>>> affinity:00000000,00000000,00000000,00000001 vec:c0 type=3DPCI-MSI
>>> =A0 status=3D00000002 mapped, unbound
>>> (XEN) [2011-12-06 19:13:38] =A0 =A0IRQ: =A030
>>> affinity:00000000,00000000,00000000,00000001 vec:d8 type=3DPCI-MSI
>>> =A0 status=3D00000014 in-flight=3D0 domain-list=3D0:274(PS--),
>>> (XEN) [2011-12-06 19:13:38] =A0 =A0IRQ: =A031
>>> affinity:00000000,00000000,00000000,00000001 vec:21 type=3DPCI-MSI
>>> =A0 status=3D00000010 in-flight=3D0 domain-list=3D0:273(PS--),
>>> (XEN) [2011-12-06 19:13:38] =A0 =A0IRQ: =A032
>>> affinity:00000000,00000000,00000000,00000001 vec:29 type=3DPCI-MSI
>>> =A0 status=3D00000010 in-flight=3D0 domain-list=3D0:272(PS--),
>>> (XEN) [2011-12-06 19:13:38] =A0 =A0IRQ: =A033
>>> affinity:00000000,00000000,00000000,00000001 vec:31 type=3DPCI-MSI
>>> =A0 status=3D00000010 in-flight=3D0 domain-list=3D0:271(PS--),
>>> (XEN) [2011-12-06 19:13:38] =A0 =A0IRQ: =A034
>>> affinity:ffffffff,ffffffff,ffffffff,ffffffff vec:39 type=3DPCI-MSI
>>> =A0 status=3D00000002 mapped, unbound
>>> (XEN) [2011-12-06 19:13:38] =A0 =A0IRQ: =A035
>>> affinity:ffffffff,ffffffff,ffffffff,ffffffff vec:41 type=3DPCI-MSI
>>> =A0 status=3D00000002 mapped, unbound
>>> (XEN) [2011-12-06 19:13:38] =A0 =A0IRQ: =A036
>>> affinity:ffffffff,ffffffff,ffffffff,ffffffff vec:49 type=3DPCI-MSI
>>> =A0 status=3D00000002 mapped, unbound
>>> (XEN) [2011-12-06 19:13:38] =A0 =A0IRQ: =A037
>>> affinity:00000000,00000000,00000000,00000010 vec:65 type=3DPCI-MSI
>>> =A0 status=3D00000010 in-flight=3D0 domain-list=3D1201: 55(--M-),
>>> (XEN) [2011-12-06 19:13:38] IO-APIC interrupt information:
>>> (XEN) [2011-12-06 19:13:38] =A0 =A0 IRQ =A00 Vec240:
>>> (XEN) [2011-12-06 19:13:38] =A0 =A0 =A0 Apic 0x00, Pin =A02: vector=3D2=
40,
>>> delivery_mode=3D1, dest_mode=3Dlogical, delivery_status=3D0, polarity=
=3D0,
>>> irr=3D0, trigger=3Dedge, mask=3D0, dest_id:1
>>> (XEN) [2011-12-06 19:13:38] =A0 =A0 IRQ =A01 Vec 48:
>>> (XEN) [2011-12-06 19:13:38] =A0 =A0 =A0 Apic 0x00, Pin =A01: vector=3D4=
8,
>>> delivery_mode=3D1, dest_mode=3Dlogical, delivery_status=3D0, polarity=
=3D0,
>>> irr=3D0, trigger=3Dedge, mask=3D0, dest_id:1
>>> (XEN) [2011-12-06 19:13:38] =A0 =A0 IRQ =A03 Vec 56:
>>> (XEN) [2011-12-06 19:13:38] =A0 =A0 =A0 Apic 0x00, Pin =A03: vector=3D5=
6,
>>> delivery_mode=3D1, dest_mode=3Dlogical, delivery_status=3D0, polarity=
=3D0,
>>> irr=3D0, trigger=3Dedge, mask=3D0, dest_id:1
>>> (XEN) [2011-12-06 19:13:38] =A0 =A0 IRQ =A04 Vec 64:
>>> (XEN) [2011-12-06 19:13:38] =A0 =A0 =A0 Apic 0x00, Pin =A04: vector=3D6=
4,
>>> delivery_mode=3D1, dest_mode=3Dlogical, delivery_status=3D0, polarity=
=3D0,
>>> irr=3D0, trigger=3Dedge, mask=3D0, dest_id:1
>>> (XEN) [2011-12-06 19:13:38] =A0 =A0 IRQ =A05 Vec241:
>>> (XEN) [2011-12-06 19:13:38] =A0 =A0 =A0 Apic 0x00, Pin =A05: vector=3D2=
41,
>>> delivery_mode=3D1, dest_mode=3Dlogical, delivery_status=3D0, polarity=
=3D0,
>>> irr=3D0, trigger=3Dedge, mask=3D0, dest_id:1
>>> (XEN) [2011-12-06 19:13:38] =A0 =A0 IRQ =A06 Vec 72:
>>> (XEN) [2011-12-06 19:13:38] =A0 =A0 =A0 Apic 0x00, Pin =A06: vector=3D7=
2,
>>> delivery_mode=3D1, dest_mode=3Dlogical, delivery_status=3D0, polarity=
=3D0,
>>> irr=3D0, trigger=3Dedge, mask=3D0, dest_id:1
>>> (XEN) [2011-12-06 19:13:38] =A0 =A0 IRQ =A07 Vec 80:
>>> (XEN) [2011-12-06 19:13:38] =A0 =A0 =A0 Apic 0x00, Pin =A07: vector=3D8=
0,
>>> delivery_mode=3D1, dest_mode=3Dlogical, delivery_status=3D0, polarity=
=3D0,
>>> irr=3D0, trigger=3Dedge, mask=3D0, dest_id:1
>>> (XEN) [2011-12-06 19:13:38] =A0 =A0 IRQ =A08 Vec 88:
>>> (XEN) [2011-12-06 19:13:38] =A0 =A0 =A0 Apic 0x00, Pin =A08: vector=3D8=
8,
>>> delivery_mode=3D1, dest_mode=3Dlogical, delivery_status=3D0, polarity=
=3D0,
>>> irr=3D0, trigger=3Dedge, mask=3D0, dest_id:1
>>> (XEN) [2011-12-06 19:13:38] =A0 =A0 IRQ =A09 Vec 96:
>>> (XEN) [2011-12-06 19:13:38] =A0 =A0 =A0 Apic 0x00, Pin =A09: vector=3D9=
6,
>>> delivery_mode=3D1, dest_mode=3Dlogical, delivery_status=3D0, polarity=
=3D0,
>>> irr=3D0, trigger=3Dlevel, mask=3D0, dest_id:1
>>> (XEN) [2011-12-06 19:13:38] =A0 =A0 IRQ 10 Vec104:
>>> (XEN) [2011-12-06 19:13:38] =A0 =A0 =A0 Apic 0x00, Pin 10: vector=3D104,
>>> delivery_mode=3D1, dest_mode=3Dlogical, delivery_status=3D0, polarity=
=3D0,
>>> irr=3D0, trigger=3Dedge, mask=3D0, dest_id:1
>>> (XEN) [2011-12-06 19:13:38] =A0 =A0 IRQ 11 Vec112:
>>> (XEN) [2011-12-06 19:13:38] =A0 =A0 =A0 Apic 0x00, Pin 11: vector=3D112,
>>> delivery_mode=3D1, dest_mode=3Dlogical, delivery_status=3D0, polarity=
=3D0,
>>> irr=3D0, trigger=3Dedge, mask=3D0, dest_id:1
>>> (XEN) [2011-12-06 19:13:38] =A0 =A0 IRQ 12 Vec120:
>>> (XEN) [2011-12-06 19:13:38] =A0 =A0 =A0 Apic 0x00, Pin 12: vector=3D120,
>>> delivery_mode=3D1, dest_mode=3Dlogical, delivery_status=3D0, polarity=
=3D0,
>>> irr=3D0, trigger=3Dedge, mask=3D0, dest_id:1
>>> (XEN) [2011-12-06 19:13:38] =A0 =A0 IRQ 13 Vec136:
>>> (XEN) [2011-12-06 19:13:38] =A0 =A0 =A0 Apic 0x00, Pin 13: vector=3D136,
>>> delivery_mode=3D1, dest_mode=3Dlogical, delivery_status=3D0, polarity=
=3D0,
>>> irr=3D0, trigger=3Dedge, mask=3D0, dest_id:1
>>> (XEN) [2011-12-06 19:13:38] =A0 =A0 IRQ 14 Vec144:
>>> (XEN) [2011-12-06 19:13:38] =A0 =A0 =A0 Apic 0x00, Pin 14: vector=3D144,
>>> delivery_mode=3D1, dest_mode=3Dlogical, delivery_status=3D0, polarity=
=3D0,
>>> irr=3D0, trigger=3Dedge, mask=3D0, dest_id:1
>>> (XEN) [2011-12-06 19:13:38] =A0 =A0 IRQ 15 Vec152:
>>> (XEN) [2011-12-06 19:13:38] =A0 =A0 =A0 Apic 0x00, Pin 15: vector=3D152,
>>> delivery_mode=3D1, dest_mode=3Dlogical, delivery_status=3D0, polarity=
=3D0,
>>> irr=3D0, trigger=3Dedge, mask=3D0, dest_id:1
>>> (XEN) [2011-12-06 19:13:38] =A0 =A0 IRQ 16 Vec200:
>>> (XEN) [2011-12-06 19:13:38] =A0 =A0 =A0 Apic 0x00, Pin 16: vector=3D200,
>>> delivery_mode=3D1, dest_mode=3Dlogical, delivery_status=3D0, polarity=
=3D1,
>>> irr=3D0, trigger=3Dlevel, mask=3D0, dest_id:1
>>> (XEN) [2011-12-06 19:13:38] =A0 =A0 IRQ 18 Vec 81:
>>> (XEN) [2011-12-06 19:13:38] =A0 =A0 =A0 Apic 0x00, Pin 18: vector=3D81,
>>> delivery_mode=3D1, dest_mode=3Dlogical, delivery_status=3D0, polarity=
=3D1,
>>> irr=3D0, trigger=3Dlevel, mask=3D0, dest_id:1
>>> (XEN) [2011-12-06 19:13:38] =A0 =A0 IRQ 19 Vec208:
>>> (XEN) [2011-12-06 19:13:38] =A0 =A0 =A0 Apic 0x00, Pin 19: vector=3D208,
>>> delivery_mode=3D1, dest_mode=3Dlogical, delivery_status=3D0, polarity=
=3D1,
>>> irr=3D0, trigger=3Dlevel, mask=3D0, dest_id:1
>>> (XEN) [2011-12-06 19:13:38] =A0 =A0 IRQ 21 Vec 97:
>>> (XEN) [2011-12-06 19:13:38] =A0 =A0 =A0 Apic 0x00, Pin 21: vector=3D97,
>>> delivery_mode=3D1, dest_mode=3Dlogical, delivery_status=3D0, polarity=
=3D1,
>>> irr=3D0, trigger=3Dlevel, mask=3D0, dest_id:1
>>> (XEN) [2011-12-06 19:13:38] =A0 =A0 IRQ 23 Vec 89:
>>> (XEN) [2011-12-06 19:13:38] =A0 =A0 =A0 Apic 0x00, Pin 23: vector=3D89,
>>> delivery_mode=3D1, dest_mode=3Dlogical, delivery_status=3D1, polarity=
=3D1,
>>> irr=3D1, trigger=3Dlevel, mask=3D0, dest_id:1
>>>
>>> I noticed some potential interesting things. The system in question is
>>> using PCI passthrough. On the serial console I remember seeing that
>>> the PCI device got unmapped from DomU and got mapped again in Dom0.
>>> The serial console log still had a lot of information about this DomU
>>> which I guess was going down. I guess it wasn't fully down yet.
>>
>> One of the debug informations that gets printed with '*' is the guest
>> PCI passthrough data. Such as which IRQ, BAR, etc are mapped in. Did any
>> of those exist?
>
> There is not much PCI related information. Just interrupt stuff, no
> PCI BARs or other interesting PCI stuff:
> (XEN) [2011-12-06 19:13:20] 03:00.0 - dom 1201 - MSIs < 37 >
> (XEN) [2011-12-06 19:13:20] =A0MSI =A0 =A037 vec=3D65 lowest =A0edge =A0 =
assert
> log lowest dest=3D00000010 mask=3D0/0/-1
>
>
>> My original thought of what is going on is that the interrupts either
>> stopped completly working (does not look like - it looks like the
>> interrupts are firring and the event channels that are bound to it have
>> the bits set saying - hey I am pending). Oddly there are bunch of MSI
>> ones that are masked which usually means they are disabled.
>>
>> Then there is the
>> =A0affinity:00000000,00000000,00000000,00000001 vec:c8 type=3DIO-APIC-le=
vel
>> =A0 status=3D00000010 in-flight=3D0 domain-list=3D0: 16(-S--),1201: 16(-=
-M-),
>> =A0affinity:00000000,00000000,00000000,00000010 vec:65 type=3DPCI-MSI
>> =A0 status=3D00000010 in-flight=3D0 domain-list=3D1201: 55(--M-),
>>
>> The guest has masked both interrupts - so it is off//dying, but somehow
>> the unmapping has not happend. In other words, what you just analyzed
>> and found out.
>>
>> Sadly, there is no smoking gun..
>>
>> So a couple of things that I would do is to ensure that the Xen
>> hypervisor boots with 'sync_console console_to_ring' and when this
>> crash happens see if I can get a stack trace from both the Xen
>> hypervisor (there are some debug parameters to get that - I think it is
>> 'r'?), and also from the Linux kernel.
>
> I set up some new tests, so that will take some days to get a crash.
> For what it is worth, I do have a '*' log left from this system and it
> has some stack trace. If you think it is useful, I could send it
> gzipped, but I don't want to spam this list if it may not be useful.
>
> One thing I did notice was the following:
> (XEN) [2011-12-06 19:13:39] active vcpus:
> (XEN) [2011-12-06 19:13:39] =A0 =A0 =A0 1: [1201.2] pri=3D-2 flags=3D0 cp=
u=3D6
> credit=3D-2411 [w=3D256]
> (XEN) [2011-12-06 19:13:39] =A0 =A0 =A0 2: [1201.1] pri=3D-2 flags=3D0 cp=
u=3D5
> credit=3D-2460 [w=3D256]
> (XEN) [2011-12-06 19:13:39] =A0 =A0 =A0 3: [0.2] pri=3D0 flags=3D0 cpu=3D2
> credit=3D142 [w=3D256]
> (XEN) [2011-12-06 19:13:39] =A0 =A0 =A0 4: [0.1] pri=3D-2 flags=3D0 cpu=
=3D1
> credit=3D-2612 [w=3D256]
> (XEN) [2011-12-06 19:13:39] CPU[00] =A0sort=3D12511062,
> sibling=3D00000000,00000000,00000000,00000003,
> core=3D00000000,00000000,00000000,000000ff
> (XEN) [2011-12-06 19:13:39] =A0 =A0 run: [32767.0] pri=3D0 flags=3D0 cpu=
=3D0
> (XEN) [2011-12-06 19:13:39] =A0 =A0 =A0 1: [0.0] pri=3D-1 flags=3D0 cpu=
=3D0
> credit=3D333 [w=3D256]
> (XEN) [2011-12-06 19:13:39] CPU[01] =A0sort=3D12511063,
> sibling=3D00000000,00000000,00000000,00000003,
> core=3D00000000,00000000,00000000,000000ff
> (XEN) [2011-12-06 19:13:39] =A0 =A0 run: [0.1] pri=3D-2 flags=3D0 cpu=3D1
> credit=3D-2914 [w=3D256]
> (XEN) [2011-12-06 19:13:39] =A0 =A0 =A0 1: [32767.1] pri=3D-64 flags=3D0 =
cpu=3D1
> (XEN) [2011-12-06 19:13:39] CPU[02] =A0sort=3D12511063,
> sibling=3D00000000,00000000,00000000,0000000c,
> core=3D00000000,00000000,00000000,000000ff
> (XEN) [2011-12-06 19:13:39] =A0 =A0 run: [32767.2] pri=3D-64 flags=3D0 cp=
u=3D2
> (XEN) [2011-12-06 19:13:39] CPU[03] =A0sort=3D12511063,
> sibling=3D00000000,00000000,00000000,0000000c,
> core=3D00000000,00000000,00000000,000000ff
> (XEN) [2011-12-06 19:13:39] =A0 =A0 run: [32767.3] pri=3D-64 flags=3D0 cp=
u=3D3
> (XEN) [2011-12-06 19:13:39] CPU[04] =A0sort=3D12511063,
> sibling=3D00000000,00000000,00000000,00000030,
> core=3D00000000,00000000,00000000,000000ff
> (XEN) [2011-12-06 19:13:39] =A0 =A0 run: [32767.4] pri=3D-64 flags=3D0 cp=
u=3D4
> (XEN) [2011-12-06 19:13:39] CPU[05] =A0sort=3D12511063,
> sibling=3D00000000,00000000,00000000,00000030,
> core=3D00000000,00000000,00000000,000000ff
> (XEN) [2011-12-06 19:13:39] =A0 =A0 run: [1201.1] pri=3D-2 flags=3D0 cpu=
=3D5
> credit=3D-3617 [w=3D256]
> (XEN) [2011-12-06 19:13:39] =A0 =A0 =A0 1: [32767.5] pri=3D-64 flags=3D0 =
cpu=3D5
> (XEN) [2011-12-06 19:13:39] CPU[06] =A0sort=3D12511063,
> sibling=3D00000000,00000000,00000000,000000c0,
> core=3D00000000,00000000,00000000,000000ff
> (XEN) [2011-12-06 19:13:39] =A0 =A0 run: [1201.2] pri=3D-2 flags=3D0 cpu=
=3D6
> credit=3D-3918 [w=3D256]
> (XEN) [2011-12-06 19:13:39] =A0 =A0 =A0 1: [32767.6] pri=3D-64 flags=3D0 =
cpu=3D6
> (XEN) [2011-12-06 19:13:39] CPU[07] =A0sort=3D12511063,
> sibling=3D00000000,00000000,00000000,000000c0,
> core=3D00000000,00000000,00000000,000000ff
> (XEN) [2011-12-06 19:13:39] =A0 =A0 run: [32767.7] pri=3D-64 flags=3D0 cp=
u=3D7
>
> The system in question has a 4-core i7 CPU where Dom0 is pinned to
> core 0-3 and DomU is pinned 4-7. Aren't the negative credit numbers
> quite big?
>
>>
>> But also see if the problem disappears with the latest 4.1.x hypervisor.
>> And it might also be worth upgrading the dom0 to a 3.0. Hmm, it would be
>> very interesting to see where the dom0 _is_ stuck at. The hypervisor is
>> running fine so it all points to dom0 crashing somewhere..
>>
>> Can you make sure that dom0 runs with 'debug loglevel=3D8' as well. That
>> should give some wealth of information when/if a crash happens.
>> Oh, and try to pass in Ctrl-Alt-SysRQ-t (on serial concentrators I think
>> you just need to type 'break' on the telnet line)and then t. But I am
>> not entirely sure about it - might want to double check Google and see
>> how to enable Alt-SysRQ.
>
> I tried to get SysRq working. It worked fine on some of my other
> machines (sysrq=3D 'shift-control-o'), but not on this broken box.
> Apparently the kernel is stuck in some place where SysRq doesn't work.
>
> I'm going to retest with the relevant logging turned on. I also
> upgraded to the latest 2.6.32 kernel (.48 I think). I will also
> upgrade to the latest 4.1.x build from the mercurial repository. It
> will take a few days before I get crash.
>
> Thanks so far!
> Roderick

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 22:03:44 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 22:03:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZ8XO-0001vV-RK; Fri, 09 Dec 2011 22:03:26 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <thunderbird2k@gmail.com>) id 1RZ8XM-0001v5-Lp
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 22:03:25 +0000
X-Env-Sender: thunderbird2k@gmail.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1323468151!4774342!1
X-Originating-IP: [209.85.213.171]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22818 invoked from network); 9 Dec 2011 22:02:33 -0000
Received: from mail-yx0-f171.google.com (HELO mail-yx0-f171.google.com)
	(209.85.213.171)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 22:02:33 -0000
Received: by yenr9 with SMTP id r9so50751721yen.30
	for <xen-devel@lists.xensource.com>;
	Fri, 09 Dec 2011 14:02:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	bh=CsWrM6RZVSRtcmxIV/Det5MbMkAtyI0wZ0FqYFUn26E=;
	b=gWx2163c2TdGC2t6Js4SpQQSXls5KD6UEoFquAHaI0VqHEf9k7YggXTGVUDAN7jfsZ
	U+Q918jkjs23LHP8deG5fKeB0go2d2mirGnTD8PdSpAT+Ck8ewWXShxsIJODGZyfez06
	zdBaKQYXKyFmpZ/Xc748OdluKRyAhvEV0h9OM=
MIME-Version: 1.0
Received: by 10.236.155.170 with SMTP id j30mr14914913yhk.56.1323468151102;
	Fri, 09 Dec 2011 14:02:31 -0800 (PST)
Received: by 10.100.48.10 with HTTP; Fri, 9 Dec 2011 14:02:31 -0800 (PST)
In-Reply-To: <CAEc3jaC9=HiMoxSYZmXKRzoFcMYRaT9jrX3m1ZQO+M8CrH35Fg@mail.gmail.com>
References: <CAEc3jaBds7xmiKH8RMfmEHQumkEeZ3PopVfbZPs_B-Kz8-DsWw@mail.gmail.com>
	<4ED51291.1010308@hfp.de>
	<CAEc3jaAa7y8C2NNBn1=L3AhS0uuYFP6ze8o1cZ9yG2VYHx6qMA@mail.gmail.com>
	<4ED5215D.1010403@hfp.de>
	<20111129230212.GA23958@andromeda.dapyr.net>
	<CAEc3jaAO0JhtOt6phQHwtE_A+NF7uGHGZ8uJv3BirEYybfVceg@mail.gmail.com>
	<CAEc3jaACffpr9D1Hq_012vHAGhPLEfvsZjh7YyJ=Q-3FdtHS0Q@mail.gmail.com>
	<CAPbh3rtOQ1HTPReqYcpE3vzk+-na0MTLLHZD15=Fg4yxB+ypaA@mail.gmail.com>
	<CAEc3jaBdQKmVJToNZRf+25GtJXqGc274ieHf_yHKRJ+YOKWdgA@mail.gmail.com>
	<20111208234624.GD32474@konrad-lan>
	<CAEc3jaC9=HiMoxSYZmXKRzoFcMYRaT9jrX3m1ZQO+M8CrH35Fg@mail.gmail.com>
Date: Fri, 9 Dec 2011 14:02:31 -0800
Message-ID: <CAEc3jaBBYBME0G3Ku_sTvzQz+oKQnpBPffA+bRUKxxRPABAeww@mail.gmail.com>
From: Roderick Colenbrander <thunderbird2k@gmail.com>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
Cc: xen-devel@lists.xensource.com, Andreas Kinzler <ml-xen-devel@hfp.de>
Subject: Re: [Xen-devel] Questions about GPLPV stability tests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

One interesting observation. This morning I had another of my stress
machines with the problem. I never had it on this problem before and
it didn't have any of the new logging / software updates yet.

The system was in the same state as the other machine which I reported
about before. I tried SysRq stuff and other things. While I was about
to reboot the system, a login prompt appeared again on the VGA. I
don't know whether any of the stuff I did triggered it or not. Anyway
it means Linux is not really dead. I tried logging, but I don't even
see characters appearing. The system feels to be very, very, very
slow.

The other tests are still running.

Roderick

On Thu, Dec 8, 2011 at 5:33 PM, Roderick Colenbrander
<thunderbird2k@gmail.com> wrote:
> On Thu, Dec 8, 2011 at 11:46 PM, Konrad Rzeszutek Wilk
> <konrad@darnok.org> wrote:
>> On Wed, Dec 07, 2011 at 08:44:19PM +0000, Roderick Colenbrander wrote:
>>> On Wed, Dec 7, 2011 at 8:38 PM, Konrad Rzeszutek Wilk <konrad@darnok.or=
g> wrote:
>>> >> It took about a week, but the systems went down again. Linux is down,
>>> >> but the hypervisor is still reachable on the serial console. Is there
>>> >> anything interesting to dump from there?
>>> >>
>>> > Just the interrupts information. I think that is Ctrl-A, Ctrl-A,
>>> > Ctrl-A, and then '*' to capture everything (I don't remember the right
>>> > one for just interrupts).
>>>
>>> Here's the interrupt information:
>>> (XEN) [2011-12-06 19:13:37] [i: dump interrupt bindings]
>>> (XEN) [2011-12-06 19:13:37] Guest interrupt information:
>>> (XEN) [2011-12-06 19:13:37] =A0 =A0IRQ: =A0 0
>>> affinity:00000000,00000000,00000000,00000001 vec:f0 type=3DIO-APIC-edge
>>> =A0 status=3D00000000 mapped, unbound
>>> (XEN) [2011-12-06 19:13:37] =A0 =A0IRQ: =A0 1
>>> affinity:00000000,00000000,00000000,00000001 vec:30 type=3DIO-APIC-edge
>>> =A0 status=3D00000014 in-flight=3D0 domain-list=3D0: =A01(-S--),
>>> (XEN) [2011-12-06 19:13:37] =A0 =A0IRQ: =A0 2
>>> affinity:ffffffff,ffffffff,ffffffff,ffffffff vec:e2 type=3DXT-PIC
>>> =A0 status=3D00000000 mapped, unbound
>>> (XEN) [2011-12-06 19:13:37] =A0 =A0IRQ: =A0 3
>>> affinity:00000000,00000000,00000000,00000001 vec:38 type=3DIO-APIC-edge
>>> =A0 status=3D00000006 mapped, unbound
>>> (XEN) [2011-12-06 19:13:37] =A0 =A0IRQ: =A0 4
>>> affinity:00000000,00000000,00000000,00000001 vec:40 type=3DIO-APIC-edge
>>> =A0 status=3D00000002 mapped, unbound
>>> (XEN) [2011-12-06 19:13:37] =A0 =A0IRQ: =A0 5
>>> affinity:00000000,00000000,00000000,00000001 vec:f1 type=3DIO-APIC-edge
>>> =A0 status=3D00000000 mapped, unbound
>>> (XEN) [2011-12-06 19:13:37] =A0 =A0IRQ: =A0 6
>>> affinity:00000000,00000000,00000000,00000001 vec:48 type=3DIO-APIC-edge
>>> =A0 status=3D00000002 mapped, unbound
>>> (XEN) [2011-12-06 19:13:37] =A0 =A0IRQ: =A0 7
>>> affinity:00000000,00000000,00000000,00000001 vec:50 type=3DIO-APIC-edge
>>> =A0 status=3D00000002 mapped, unbound
>>> (XEN) [2011-12-06 19:13:37] =A0 =A0IRQ: =A0 8
>>> affinity:00000000,00000000,00000000,00000001 vec:58 type=3DIO-APIC-edge
>>> =A0 status=3D00000010 in-flight=3D0 domain-list=3D0: =A08(-S--),
>>> (XEN) [2011-12-06 19:13:37] =A0 =A0IRQ: =A0 9
>>> affinity:00000000,00000000,00000000,00000001 vec:60 type=3DIO-APIC-level
>>> =A0 status=3D00000010 in-flight=3D0 domain-list=3D0: =A09(-S--),
>>> (XEN) [2011-12-06 19:13:37] =A0 =A0IRQ: =A010
>>> affinity:00000000,00000000,00000000,00000001 vec:68 type=3DIO-APIC-edge
>>> =A0 status=3D00000002 mapped, unbound
>>> (XEN) [2011-12-06 19:13:37] =A0 =A0IRQ: =A011
>>> affinity:00000000,00000000,00000000,00000001 vec:70 type=3DIO-APIC-edge
>>> =A0 status=3D00000002 mapped, unbound
>>> (XEN) [2011-12-06 19:13:37] =A0 =A0IRQ: =A012
>>> affinity:00000000,00000000,00000000,00000001 vec:78 type=3DIO-APIC-edge
>>> =A0 status=3D00000010 in-flight=3D0 domain-list=3D0: 12(-S--),
>>> (XEN) [2011-12-06 19:13:37] =A0 =A0IRQ: =A013
>>> affinity:00000000,00000000,00000000,00000001 vec:88 type=3DIO-APIC-edge
>>> =A0 status=3D00000002 mapped, unbound
>>> (XEN) [2011-12-06 19:13:37] =A0 =A0IRQ: =A014
>>> affinity:00000000,00000000,00000000,00000001 vec:90 type=3DIO-APIC-edge
>>> =A0 status=3D00000002 mapped, unbound
>>> (XEN) [2011-12-06 19:13:37] =A0 =A0IRQ: =A015
>>> affinity:00000000,00000000,00000000,00000001 vec:98 type=3DIO-APIC-edge
>>> =A0 status=3D00000002 mapped, unbound
>>> (XEN) [2011-12-06 19:13:37] =A0 =A0IRQ: =A016
>>> affinity:00000000,00000000,00000000,00000001 vec:c8 type=3DIO-APIC-level
>>> =A0 status=3D00000010 in-flight=3D0 domain-list=3D0: 16(-S--),1201: 16(=
--M-),
>>> (XEN) [2011-12-06 19:13:37] =A0 =A0IRQ: =A018
>>> affinity:00000000,00000000,00000000,00000001 vec:51 type=3DIO-APIC-level
>>> =A0 status=3D00000010 in-flight=3D0 domain-list=3D0: 18(-S--),
>>> (XEN) [2011-12-06 19:13:37] =A0 =A0IRQ: =A019
>>> affinity:00000000,00000000,00000000,00000001 vec:d0 type=3DIO-APIC-level
>>> =A0 status=3D00000010 in-flight=3D0 domain-list=3D0: 19(-S--),
>>> (XEN) [2011-12-06 19:13:37] =A0 =A0IRQ: =A021
>>> affinity:00000000,00000000,00000000,00000001 vec:61 type=3DIO-APIC-level
>>> =A0 status=3D00000010 in-flight=3D0 domain-list=3D0: 21(-S--),
>>> (XEN) [2011-12-06 19:13:37] =A0 =A0IRQ: =A023
>>> affinity:00000000,00000000,00000000,00000001 vec:59 type=3DIO-APIC-level
>>> =A0 status=3D00000010 in-flight=3D1 domain-list=3D0: 23(PS-M),
>>> (XEN) [2011-12-06 19:13:37] =A0 =A0IRQ: =A024
>>> affinity:00000000,00000000,00000000,00000001 vec:28 type=3DDMA_MSI
>>> =A0 status=3D00000000 mapped, unbound
>>> (XEN) [2011-12-06 19:13:38] =A0 =A0IRQ: =A025
>>> affinity:00000000,00000000,00000000,00000001 vec:a0 type=3DPCI-MSI
>>> =A0 status=3D00000002 mapped, unbound
>>> (XEN) [2011-12-06 19:13:38] =A0 =A0IRQ: =A026
>>> affinity:00000000,00000000,00000000,00000001 vec:a8 type=3DPCI-MSI
>>> =A0 status=3D00000002 mapped, unbound
>>> (XEN) [2011-12-06 19:13:38] =A0 =A0IRQ: =A027
>>> affinity:00000000,00000000,00000000,00000001 vec:b0 type=3DPCI-MSI
>>> =A0 status=3D00000002 mapped, unbound
>>> (XEN) [2011-12-06 19:13:38] =A0 =A0IRQ: =A028
>>> affinity:00000000,00000000,00000000,00000001 vec:b8 type=3DPCI-MSI
>>> =A0 status=3D00000002 mapped, unbound
>>> (XEN) [2011-12-06 19:13:38] =A0 =A0IRQ: =A029
>>> affinity:00000000,00000000,00000000,00000001 vec:c0 type=3DPCI-MSI
>>> =A0 status=3D00000002 mapped, unbound
>>> (XEN) [2011-12-06 19:13:38] =A0 =A0IRQ: =A030
>>> affinity:00000000,00000000,00000000,00000001 vec:d8 type=3DPCI-MSI
>>> =A0 status=3D00000014 in-flight=3D0 domain-list=3D0:274(PS--),
>>> (XEN) [2011-12-06 19:13:38] =A0 =A0IRQ: =A031
>>> affinity:00000000,00000000,00000000,00000001 vec:21 type=3DPCI-MSI
>>> =A0 status=3D00000010 in-flight=3D0 domain-list=3D0:273(PS--),
>>> (XEN) [2011-12-06 19:13:38] =A0 =A0IRQ: =A032
>>> affinity:00000000,00000000,00000000,00000001 vec:29 type=3DPCI-MSI
>>> =A0 status=3D00000010 in-flight=3D0 domain-list=3D0:272(PS--),
>>> (XEN) [2011-12-06 19:13:38] =A0 =A0IRQ: =A033
>>> affinity:00000000,00000000,00000000,00000001 vec:31 type=3DPCI-MSI
>>> =A0 status=3D00000010 in-flight=3D0 domain-list=3D0:271(PS--),
>>> (XEN) [2011-12-06 19:13:38] =A0 =A0IRQ: =A034
>>> affinity:ffffffff,ffffffff,ffffffff,ffffffff vec:39 type=3DPCI-MSI
>>> =A0 status=3D00000002 mapped, unbound
>>> (XEN) [2011-12-06 19:13:38] =A0 =A0IRQ: =A035
>>> affinity:ffffffff,ffffffff,ffffffff,ffffffff vec:41 type=3DPCI-MSI
>>> =A0 status=3D00000002 mapped, unbound
>>> (XEN) [2011-12-06 19:13:38] =A0 =A0IRQ: =A036
>>> affinity:ffffffff,ffffffff,ffffffff,ffffffff vec:49 type=3DPCI-MSI
>>> =A0 status=3D00000002 mapped, unbound
>>> (XEN) [2011-12-06 19:13:38] =A0 =A0IRQ: =A037
>>> affinity:00000000,00000000,00000000,00000010 vec:65 type=3DPCI-MSI
>>> =A0 status=3D00000010 in-flight=3D0 domain-list=3D1201: 55(--M-),
>>> (XEN) [2011-12-06 19:13:38] IO-APIC interrupt information:
>>> (XEN) [2011-12-06 19:13:38] =A0 =A0 IRQ =A00 Vec240:
>>> (XEN) [2011-12-06 19:13:38] =A0 =A0 =A0 Apic 0x00, Pin =A02: vector=3D2=
40,
>>> delivery_mode=3D1, dest_mode=3Dlogical, delivery_status=3D0, polarity=
=3D0,
>>> irr=3D0, trigger=3Dedge, mask=3D0, dest_id:1
>>> (XEN) [2011-12-06 19:13:38] =A0 =A0 IRQ =A01 Vec 48:
>>> (XEN) [2011-12-06 19:13:38] =A0 =A0 =A0 Apic 0x00, Pin =A01: vector=3D4=
8,
>>> delivery_mode=3D1, dest_mode=3Dlogical, delivery_status=3D0, polarity=
=3D0,
>>> irr=3D0, trigger=3Dedge, mask=3D0, dest_id:1
>>> (XEN) [2011-12-06 19:13:38] =A0 =A0 IRQ =A03 Vec 56:
>>> (XEN) [2011-12-06 19:13:38] =A0 =A0 =A0 Apic 0x00, Pin =A03: vector=3D5=
6,
>>> delivery_mode=3D1, dest_mode=3Dlogical, delivery_status=3D0, polarity=
=3D0,
>>> irr=3D0, trigger=3Dedge, mask=3D0, dest_id:1
>>> (XEN) [2011-12-06 19:13:38] =A0 =A0 IRQ =A04 Vec 64:
>>> (XEN) [2011-12-06 19:13:38] =A0 =A0 =A0 Apic 0x00, Pin =A04: vector=3D6=
4,
>>> delivery_mode=3D1, dest_mode=3Dlogical, delivery_status=3D0, polarity=
=3D0,
>>> irr=3D0, trigger=3Dedge, mask=3D0, dest_id:1
>>> (XEN) [2011-12-06 19:13:38] =A0 =A0 IRQ =A05 Vec241:
>>> (XEN) [2011-12-06 19:13:38] =A0 =A0 =A0 Apic 0x00, Pin =A05: vector=3D2=
41,
>>> delivery_mode=3D1, dest_mode=3Dlogical, delivery_status=3D0, polarity=
=3D0,
>>> irr=3D0, trigger=3Dedge, mask=3D0, dest_id:1
>>> (XEN) [2011-12-06 19:13:38] =A0 =A0 IRQ =A06 Vec 72:
>>> (XEN) [2011-12-06 19:13:38] =A0 =A0 =A0 Apic 0x00, Pin =A06: vector=3D7=
2,
>>> delivery_mode=3D1, dest_mode=3Dlogical, delivery_status=3D0, polarity=
=3D0,
>>> irr=3D0, trigger=3Dedge, mask=3D0, dest_id:1
>>> (XEN) [2011-12-06 19:13:38] =A0 =A0 IRQ =A07 Vec 80:
>>> (XEN) [2011-12-06 19:13:38] =A0 =A0 =A0 Apic 0x00, Pin =A07: vector=3D8=
0,
>>> delivery_mode=3D1, dest_mode=3Dlogical, delivery_status=3D0, polarity=
=3D0,
>>> irr=3D0, trigger=3Dedge, mask=3D0, dest_id:1
>>> (XEN) [2011-12-06 19:13:38] =A0 =A0 IRQ =A08 Vec 88:
>>> (XEN) [2011-12-06 19:13:38] =A0 =A0 =A0 Apic 0x00, Pin =A08: vector=3D8=
8,
>>> delivery_mode=3D1, dest_mode=3Dlogical, delivery_status=3D0, polarity=
=3D0,
>>> irr=3D0, trigger=3Dedge, mask=3D0, dest_id:1
>>> (XEN) [2011-12-06 19:13:38] =A0 =A0 IRQ =A09 Vec 96:
>>> (XEN) [2011-12-06 19:13:38] =A0 =A0 =A0 Apic 0x00, Pin =A09: vector=3D9=
6,
>>> delivery_mode=3D1, dest_mode=3Dlogical, delivery_status=3D0, polarity=
=3D0,
>>> irr=3D0, trigger=3Dlevel, mask=3D0, dest_id:1
>>> (XEN) [2011-12-06 19:13:38] =A0 =A0 IRQ 10 Vec104:
>>> (XEN) [2011-12-06 19:13:38] =A0 =A0 =A0 Apic 0x00, Pin 10: vector=3D104,
>>> delivery_mode=3D1, dest_mode=3Dlogical, delivery_status=3D0, polarity=
=3D0,
>>> irr=3D0, trigger=3Dedge, mask=3D0, dest_id:1
>>> (XEN) [2011-12-06 19:13:38] =A0 =A0 IRQ 11 Vec112:
>>> (XEN) [2011-12-06 19:13:38] =A0 =A0 =A0 Apic 0x00, Pin 11: vector=3D112,
>>> delivery_mode=3D1, dest_mode=3Dlogical, delivery_status=3D0, polarity=
=3D0,
>>> irr=3D0, trigger=3Dedge, mask=3D0, dest_id:1
>>> (XEN) [2011-12-06 19:13:38] =A0 =A0 IRQ 12 Vec120:
>>> (XEN) [2011-12-06 19:13:38] =A0 =A0 =A0 Apic 0x00, Pin 12: vector=3D120,
>>> delivery_mode=3D1, dest_mode=3Dlogical, delivery_status=3D0, polarity=
=3D0,
>>> irr=3D0, trigger=3Dedge, mask=3D0, dest_id:1
>>> (XEN) [2011-12-06 19:13:38] =A0 =A0 IRQ 13 Vec136:
>>> (XEN) [2011-12-06 19:13:38] =A0 =A0 =A0 Apic 0x00, Pin 13: vector=3D136,
>>> delivery_mode=3D1, dest_mode=3Dlogical, delivery_status=3D0, polarity=
=3D0,
>>> irr=3D0, trigger=3Dedge, mask=3D0, dest_id:1
>>> (XEN) [2011-12-06 19:13:38] =A0 =A0 IRQ 14 Vec144:
>>> (XEN) [2011-12-06 19:13:38] =A0 =A0 =A0 Apic 0x00, Pin 14: vector=3D144,
>>> delivery_mode=3D1, dest_mode=3Dlogical, delivery_status=3D0, polarity=
=3D0,
>>> irr=3D0, trigger=3Dedge, mask=3D0, dest_id:1
>>> (XEN) [2011-12-06 19:13:38] =A0 =A0 IRQ 15 Vec152:
>>> (XEN) [2011-12-06 19:13:38] =A0 =A0 =A0 Apic 0x00, Pin 15: vector=3D152,
>>> delivery_mode=3D1, dest_mode=3Dlogical, delivery_status=3D0, polarity=
=3D0,
>>> irr=3D0, trigger=3Dedge, mask=3D0, dest_id:1
>>> (XEN) [2011-12-06 19:13:38] =A0 =A0 IRQ 16 Vec200:
>>> (XEN) [2011-12-06 19:13:38] =A0 =A0 =A0 Apic 0x00, Pin 16: vector=3D200,
>>> delivery_mode=3D1, dest_mode=3Dlogical, delivery_status=3D0, polarity=
=3D1,
>>> irr=3D0, trigger=3Dlevel, mask=3D0, dest_id:1
>>> (XEN) [2011-12-06 19:13:38] =A0 =A0 IRQ 18 Vec 81:
>>> (XEN) [2011-12-06 19:13:38] =A0 =A0 =A0 Apic 0x00, Pin 18: vector=3D81,
>>> delivery_mode=3D1, dest_mode=3Dlogical, delivery_status=3D0, polarity=
=3D1,
>>> irr=3D0, trigger=3Dlevel, mask=3D0, dest_id:1
>>> (XEN) [2011-12-06 19:13:38] =A0 =A0 IRQ 19 Vec208:
>>> (XEN) [2011-12-06 19:13:38] =A0 =A0 =A0 Apic 0x00, Pin 19: vector=3D208,
>>> delivery_mode=3D1, dest_mode=3Dlogical, delivery_status=3D0, polarity=
=3D1,
>>> irr=3D0, trigger=3Dlevel, mask=3D0, dest_id:1
>>> (XEN) [2011-12-06 19:13:38] =A0 =A0 IRQ 21 Vec 97:
>>> (XEN) [2011-12-06 19:13:38] =A0 =A0 =A0 Apic 0x00, Pin 21: vector=3D97,
>>> delivery_mode=3D1, dest_mode=3Dlogical, delivery_status=3D0, polarity=
=3D1,
>>> irr=3D0, trigger=3Dlevel, mask=3D0, dest_id:1
>>> (XEN) [2011-12-06 19:13:38] =A0 =A0 IRQ 23 Vec 89:
>>> (XEN) [2011-12-06 19:13:38] =A0 =A0 =A0 Apic 0x00, Pin 23: vector=3D89,
>>> delivery_mode=3D1, dest_mode=3Dlogical, delivery_status=3D1, polarity=
=3D1,
>>> irr=3D1, trigger=3Dlevel, mask=3D0, dest_id:1
>>>
>>> I noticed some potential interesting things. The system in question is
>>> using PCI passthrough. On the serial console I remember seeing that
>>> the PCI device got unmapped from DomU and got mapped again in Dom0.
>>> The serial console log still had a lot of information about this DomU
>>> which I guess was going down. I guess it wasn't fully down yet.
>>
>> One of the debug informations that gets printed with '*' is the guest
>> PCI passthrough data. Such as which IRQ, BAR, etc are mapped in. Did any
>> of those exist?
>
> There is not much PCI related information. Just interrupt stuff, no
> PCI BARs or other interesting PCI stuff:
> (XEN) [2011-12-06 19:13:20] 03:00.0 - dom 1201 - MSIs < 37 >
> (XEN) [2011-12-06 19:13:20] =A0MSI =A0 =A037 vec=3D65 lowest =A0edge =A0 =
assert
> log lowest dest=3D00000010 mask=3D0/0/-1
>
>
>> My original thought of what is going on is that the interrupts either
>> stopped completly working (does not look like - it looks like the
>> interrupts are firring and the event channels that are bound to it have
>> the bits set saying - hey I am pending). Oddly there are bunch of MSI
>> ones that are masked which usually means they are disabled.
>>
>> Then there is the
>> =A0affinity:00000000,00000000,00000000,00000001 vec:c8 type=3DIO-APIC-le=
vel
>> =A0 status=3D00000010 in-flight=3D0 domain-list=3D0: 16(-S--),1201: 16(-=
-M-),
>> =A0affinity:00000000,00000000,00000000,00000010 vec:65 type=3DPCI-MSI
>> =A0 status=3D00000010 in-flight=3D0 domain-list=3D1201: 55(--M-),
>>
>> The guest has masked both interrupts - so it is off//dying, but somehow
>> the unmapping has not happend. In other words, what you just analyzed
>> and found out.
>>
>> Sadly, there is no smoking gun..
>>
>> So a couple of things that I would do is to ensure that the Xen
>> hypervisor boots with 'sync_console console_to_ring' and when this
>> crash happens see if I can get a stack trace from both the Xen
>> hypervisor (there are some debug parameters to get that - I think it is
>> 'r'?), and also from the Linux kernel.
>
> I set up some new tests, so that will take some days to get a crash.
> For what it is worth, I do have a '*' log left from this system and it
> has some stack trace. If you think it is useful, I could send it
> gzipped, but I don't want to spam this list if it may not be useful.
>
> One thing I did notice was the following:
> (XEN) [2011-12-06 19:13:39] active vcpus:
> (XEN) [2011-12-06 19:13:39] =A0 =A0 =A0 1: [1201.2] pri=3D-2 flags=3D0 cp=
u=3D6
> credit=3D-2411 [w=3D256]
> (XEN) [2011-12-06 19:13:39] =A0 =A0 =A0 2: [1201.1] pri=3D-2 flags=3D0 cp=
u=3D5
> credit=3D-2460 [w=3D256]
> (XEN) [2011-12-06 19:13:39] =A0 =A0 =A0 3: [0.2] pri=3D0 flags=3D0 cpu=3D2
> credit=3D142 [w=3D256]
> (XEN) [2011-12-06 19:13:39] =A0 =A0 =A0 4: [0.1] pri=3D-2 flags=3D0 cpu=
=3D1
> credit=3D-2612 [w=3D256]
> (XEN) [2011-12-06 19:13:39] CPU[00] =A0sort=3D12511062,
> sibling=3D00000000,00000000,00000000,00000003,
> core=3D00000000,00000000,00000000,000000ff
> (XEN) [2011-12-06 19:13:39] =A0 =A0 run: [32767.0] pri=3D0 flags=3D0 cpu=
=3D0
> (XEN) [2011-12-06 19:13:39] =A0 =A0 =A0 1: [0.0] pri=3D-1 flags=3D0 cpu=
=3D0
> credit=3D333 [w=3D256]
> (XEN) [2011-12-06 19:13:39] CPU[01] =A0sort=3D12511063,
> sibling=3D00000000,00000000,00000000,00000003,
> core=3D00000000,00000000,00000000,000000ff
> (XEN) [2011-12-06 19:13:39] =A0 =A0 run: [0.1] pri=3D-2 flags=3D0 cpu=3D1
> credit=3D-2914 [w=3D256]
> (XEN) [2011-12-06 19:13:39] =A0 =A0 =A0 1: [32767.1] pri=3D-64 flags=3D0 =
cpu=3D1
> (XEN) [2011-12-06 19:13:39] CPU[02] =A0sort=3D12511063,
> sibling=3D00000000,00000000,00000000,0000000c,
> core=3D00000000,00000000,00000000,000000ff
> (XEN) [2011-12-06 19:13:39] =A0 =A0 run: [32767.2] pri=3D-64 flags=3D0 cp=
u=3D2
> (XEN) [2011-12-06 19:13:39] CPU[03] =A0sort=3D12511063,
> sibling=3D00000000,00000000,00000000,0000000c,
> core=3D00000000,00000000,00000000,000000ff
> (XEN) [2011-12-06 19:13:39] =A0 =A0 run: [32767.3] pri=3D-64 flags=3D0 cp=
u=3D3
> (XEN) [2011-12-06 19:13:39] CPU[04] =A0sort=3D12511063,
> sibling=3D00000000,00000000,00000000,00000030,
> core=3D00000000,00000000,00000000,000000ff
> (XEN) [2011-12-06 19:13:39] =A0 =A0 run: [32767.4] pri=3D-64 flags=3D0 cp=
u=3D4
> (XEN) [2011-12-06 19:13:39] CPU[05] =A0sort=3D12511063,
> sibling=3D00000000,00000000,00000000,00000030,
> core=3D00000000,00000000,00000000,000000ff
> (XEN) [2011-12-06 19:13:39] =A0 =A0 run: [1201.1] pri=3D-2 flags=3D0 cpu=
=3D5
> credit=3D-3617 [w=3D256]
> (XEN) [2011-12-06 19:13:39] =A0 =A0 =A0 1: [32767.5] pri=3D-64 flags=3D0 =
cpu=3D5
> (XEN) [2011-12-06 19:13:39] CPU[06] =A0sort=3D12511063,
> sibling=3D00000000,00000000,00000000,000000c0,
> core=3D00000000,00000000,00000000,000000ff
> (XEN) [2011-12-06 19:13:39] =A0 =A0 run: [1201.2] pri=3D-2 flags=3D0 cpu=
=3D6
> credit=3D-3918 [w=3D256]
> (XEN) [2011-12-06 19:13:39] =A0 =A0 =A0 1: [32767.6] pri=3D-64 flags=3D0 =
cpu=3D6
> (XEN) [2011-12-06 19:13:39] CPU[07] =A0sort=3D12511063,
> sibling=3D00000000,00000000,00000000,000000c0,
> core=3D00000000,00000000,00000000,000000ff
> (XEN) [2011-12-06 19:13:39] =A0 =A0 run: [32767.7] pri=3D-64 flags=3D0 cp=
u=3D7
>
> The system in question has a 4-core i7 CPU where Dom0 is pinned to
> core 0-3 and DomU is pinned 4-7. Aren't the negative credit numbers
> quite big?
>
>>
>> But also see if the problem disappears with the latest 4.1.x hypervisor.
>> And it might also be worth upgrading the dom0 to a 3.0. Hmm, it would be
>> very interesting to see where the dom0 _is_ stuck at. The hypervisor is
>> running fine so it all points to dom0 crashing somewhere..
>>
>> Can you make sure that dom0 runs with 'debug loglevel=3D8' as well. That
>> should give some wealth of information when/if a crash happens.
>> Oh, and try to pass in Ctrl-Alt-SysRQ-t (on serial concentrators I think
>> you just need to type 'break' on the telnet line)and then t. But I am
>> not entirely sure about it - might want to double check Google and see
>> how to enable Alt-SysRQ.
>
> I tried to get SysRq working. It worked fine on some of my other
> machines (sysrq=3D 'shift-control-o'), but not on this broken box.
> Apparently the kernel is stuck in some place where SysRq doesn't work.
>
> I'm going to retest with the relevant logging turned on. I also
> upgraded to the latest 2.6.32 kernel (.48 I think). I will also
> upgrade to the latest 4.1.x build from the mercurial repository. It
> will take a few days before I get crash.
>
> Thanks so far!
> Roderick

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 23:15:20 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 23:15:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZ9e3-0002aw-QM; Fri, 09 Dec 2011 23:14:23 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RZ9e2-0002ar-Kw
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 23:14:22 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1323472307!55571624!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI2MQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3489 invoked from network); 9 Dec 2011 23:11:48 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 23:11:48 -0000
X-IronPort-AV: E=Sophos;i="4.71,329,1320624000"; 
   d="scan'208";a="9394382"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 23:12:54 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 23:12:54 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RZ9cc-00043v-D4;
	Fri, 09 Dec 2011 23:12:54 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RZ9cc-0004Sa-7N;
	Fri, 09 Dec 2011 23:12:54 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10468-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 9 Dec 2011 23:12:54 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10468: FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10468 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10468/

Failures and problems with tests :-(

Tests which did not succeed and are blocking:
 test-amd64-i386-rhel6hvm-intel  3 host-install(3)              broken in 10460
 test-i386-i386-pv             3 host-install(3)              broken   in 10460
 test-amd64-amd64-xl-sedf      3 host-install(3)              broken   in 10460

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-win-vcpus1  7 windows-install            fail pass in 10460
 test-i386-i386-xl-win         7 windows-install             fail pass in 10466
 test-amd64-i386-win-vcpus1    7 windows-install    fail in 10460 pass in 10468
 test-amd64-amd64-xl-win       7 windows-install    fail in 10460 pass in 10468
 test-amd64-amd64-xl-sedf      9 guest-start        fail in 10466 pass in 10468

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-i386-i386-xl-winxpsp3    7 windows-install              fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install          fail never pass
 test-amd64-i386-xl-win7-amd64  7 windows-install              fail  never pass
 test-amd64-i386-xend-winxpsp3  7 windows-install              fail  never pass
 test-amd64-amd64-xl-win7-amd64  7 windows-install              fail never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop           fail in 10460 never pass
 test-i386-i386-xl-win        13 guest-stop            fail in 10466 never pass

version targeted for testing:
 xen                  1c58bb664d8d
baseline version:
 xen                  62ff6a318c5d

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scanneel.ca>
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Andres Lagar-Cavilla <andres@lagarcavilla>
  Andrew Cooper <andrew.cooper3@citrix.com>
  Anthony PERARD <anthony.perard@citrix.com>
  Brendan Cully <brendan@cs.ubc.ca>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Haitao Shan <haitao.shan@intel.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@novell.com>
  Jan Beulich <jbeulich@suse.com>
  Jonathan Davies <jonathan.davies@citrix.com>
  juergen.gross@ts.fujitsu.com
  Keir Fraser <keir@xen.org>
  Liu, Jinsong <jinsong.liu@intel.com>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
  Philipp Hahn <hahn@univention.de>
  Shriram Rajagopalan <rshriram@cs.ubc.ca>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang2 <wei.wang2@amd.com>
  Xudong Hao <xudong.hao@intel.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 1522 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 23:15:20 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 23:15:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZ9e3-0002aw-QM; Fri, 09 Dec 2011 23:14:23 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RZ9e2-0002ar-Kw
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 23:14:22 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1323472307!55571624!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI2MQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3489 invoked from network); 9 Dec 2011 23:11:48 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2011 23:11:48 -0000
X-IronPort-AV: E=Sophos;i="4.71,329,1320624000"; 
   d="scan'208";a="9394382"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Dec 2011 23:12:54 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 9 Dec 2011 23:12:54 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RZ9cc-00043v-D4;
	Fri, 09 Dec 2011 23:12:54 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RZ9cc-0004Sa-7N;
	Fri, 09 Dec 2011 23:12:54 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10468-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 9 Dec 2011 23:12:54 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10468: FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10468 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10468/

Failures and problems with tests :-(

Tests which did not succeed and are blocking:
 test-amd64-i386-rhel6hvm-intel  3 host-install(3)              broken in 10460
 test-i386-i386-pv             3 host-install(3)              broken   in 10460
 test-amd64-amd64-xl-sedf      3 host-install(3)              broken   in 10460

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-win-vcpus1  7 windows-install            fail pass in 10460
 test-i386-i386-xl-win         7 windows-install             fail pass in 10466
 test-amd64-i386-win-vcpus1    7 windows-install    fail in 10460 pass in 10468
 test-amd64-amd64-xl-win       7 windows-install    fail in 10460 pass in 10468
 test-amd64-amd64-xl-sedf      9 guest-start        fail in 10466 pass in 10468

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-i386-i386-xl-winxpsp3    7 windows-install              fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install          fail never pass
 test-amd64-i386-xl-win7-amd64  7 windows-install              fail  never pass
 test-amd64-i386-xend-winxpsp3  7 windows-install              fail  never pass
 test-amd64-amd64-xl-win7-amd64  7 windows-install              fail never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop           fail in 10460 never pass
 test-i386-i386-xl-win        13 guest-stop            fail in 10466 never pass

version targeted for testing:
 xen                  1c58bb664d8d
baseline version:
 xen                  62ff6a318c5d

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scanneel.ca>
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Andres Lagar-Cavilla <andres@lagarcavilla>
  Andrew Cooper <andrew.cooper3@citrix.com>
  Anthony PERARD <anthony.perard@citrix.com>
  Brendan Cully <brendan@cs.ubc.ca>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Haitao Shan <haitao.shan@intel.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@novell.com>
  Jan Beulich <jbeulich@suse.com>
  Jonathan Davies <jonathan.davies@citrix.com>
  juergen.gross@ts.fujitsu.com
  Keir Fraser <keir@xen.org>
  Liu, Jinsong <jinsong.liu@intel.com>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
  Philipp Hahn <hahn@univention.de>
  Shriram Rajagopalan <rshriram@cs.ubc.ca>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang2 <wei.wang2@amd.com>
  Xudong Hao <xudong.hao@intel.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 1522 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 23:16:23 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 23: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.xensource.com>)
	id 1RZ9fJ-0002eO-5W; Fri, 09 Dec 2011 23:15:41 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RZ9fH-0002dR-2f
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 23:15:39 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-14.tower-216.messagelabs.com!1323472488!6306047!1
X-Originating-IP: [208.97.132.207]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4yMDcgPT4gMTU1MTU=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17545 invoked from network); 9 Dec 2011 23:14:49 -0000
Received: from caiajhbdccah.dreamhost.com (HELO homiemail-a76.g.dreamhost.com)
	(208.97.132.207) by server-14.tower-216.messagelabs.com with SMTP;
	9 Dec 2011 23:14:49 -0000
Received: from homiemail-a76.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTP id 740D7458084;
	Fri,  9 Dec 2011 15:14:48 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=oSjXaSwkinPBPpuTrOmOlNkXihZUl60V0568vNpaTxo7
	2RqDL93ADhe+YNgz9y15Q8v3N9x4X9N39NDYp4WrZRLwygYg1HZUl14C70h7OI6W
	KLA9PsUf/nHhgVeIOPZpc5TbdMmKzHGShmbnqY6pTeo/AnSka1wImHGWFvAaGmQ=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=l7Udmpr6INk3Y7iHo0bQdxqjBJ0=; b=TkzZcctjXln
	07K9q9eCM/f004pfaQqPyj651c2T4u2MGfbE6uDJDc0IkRNWeHNp6WhgX4I7DhR+
	hyCAsltm9otSZ9wkEbrga1DIHW/3mny+yyZ2t4RXUERqDKXxl0Q2d7NUw8lIX68t
	dvln/ss+8mgVBUbpZrHXUvOtxpzuTyVc=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTPSA id A654D458083; 
	Fri,  9 Dec 2011 15:14:47 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 892049dfc1c98a65fb0f01565e789b21f1bfad16
Message-Id: <892049dfc1c98a65fb0f.1323472552@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1323472550@xdev.gridcentric.ca>
References: <patchbomb.1323472550@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Fri, 09 Dec 2011 18:15:52 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com, andres@gridcentric.ca, tim@xen.org,
	ian.campbell@citrix.com, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 2 of 8] Tools: Update libxc mem sharing interface
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 tools/libxc/xc_memshr.c |  19 ++++++++++++++++++-
 tools/libxc/xenctrl.h   |   7 ++++++-
 2 files changed, 24 insertions(+), 2 deletions(-)


Previosuly, the mem sharing code would return an opaque handle
to index shared pages (and nominees) in its global hash table.
By removing the hash table, the handle becomes a version, to
avoid sharing a stale version of a page. Thus, libxc wrappers
need to be updated accordingly.

Signed-off-by: Adin Scannell <adin@scannell.ca>
Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 6f58de995103 -r 892049dfc1c9 tools/libxc/xc_memshr.c
--- a/tools/libxc/xc_memshr.c
+++ b/tools/libxc/xc_memshr.c
@@ -88,8 +88,13 @@ int xc_memshr_nominate_gref(xc_interface
 
 int xc_memshr_share(xc_interface *xch,
                     uint32_t source_domain,
+                    uint64_t source_gfn,
                     uint64_t source_handle,
-                    uint64_t client_handle)
+                    int source_is_gref,
+                    uint32_t client_domain,
+                    uint64_t client_gfn,
+                    uint64_t client_handle,
+                    int client_is_gref)
 {
     DECLARE_DOMCTL;
     struct xen_domctl_mem_sharing_op *op;
@@ -100,8 +105,20 @@ int xc_memshr_share(xc_interface *xch,
     op = &(domctl.u.mem_sharing_op);
     op->op = XEN_DOMCTL_MEM_EVENT_OP_SHARING_SHARE;
     op->u.share.source_handle = source_handle;
+    op->u.share.client_domain = (uint64_t) client_domain;
     op->u.share.client_handle = client_handle;
 
+    if (source_is_gref)
+        XEN_DOMCTL_MEM_SHARING_FIELD_MAKE_GREF(
+                op->u.share.source_gfn, source_gfn);
+    else
+        op->u.share.source_gfn = source_gfn;
+    if (client_is_gref)
+        XEN_DOMCTL_MEM_SHARING_FIELD_MAKE_GREF(
+                op->u.share.client_gfn, client_gfn);
+    else
+        op->u.share.client_gfn = client_gfn;
+
     return do_domctl(xch, &domctl);
 }
 
diff -r 6f58de995103 -r 892049dfc1c9 tools/libxc/xenctrl.h
--- a/tools/libxc/xenctrl.h
+++ b/tools/libxc/xenctrl.h
@@ -1893,8 +1893,13 @@ int xc_memshr_nominate_gref(xc_interface
                             uint64_t *handle);
 int xc_memshr_share(xc_interface *xch,
                     uint32_t source_domain,
+                    uint64_t source_gfn,
                     uint64_t source_handle,
-                    uint64_t client_handle);
+                    int source_is_gref,
+                    uint32_t client_domain,
+                    uint64_t client_gfn,
+                    uint64_t client_handle,
+                    int dest_is_gref);
 int xc_memshr_domain_resume(xc_interface *xch,
                             uint32_t domid);
 int xc_memshr_debug_gfn(xc_interface *xch,

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 23:16:23 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 23: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.xensource.com>)
	id 1RZ9fJ-0002eO-5W; Fri, 09 Dec 2011 23:15:41 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RZ9fH-0002dR-2f
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 23:15:39 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-14.tower-216.messagelabs.com!1323472488!6306047!1
X-Originating-IP: [208.97.132.207]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4yMDcgPT4gMTU1MTU=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17545 invoked from network); 9 Dec 2011 23:14:49 -0000
Received: from caiajhbdccah.dreamhost.com (HELO homiemail-a76.g.dreamhost.com)
	(208.97.132.207) by server-14.tower-216.messagelabs.com with SMTP;
	9 Dec 2011 23:14:49 -0000
Received: from homiemail-a76.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTP id 740D7458084;
	Fri,  9 Dec 2011 15:14:48 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=oSjXaSwkinPBPpuTrOmOlNkXihZUl60V0568vNpaTxo7
	2RqDL93ADhe+YNgz9y15Q8v3N9x4X9N39NDYp4WrZRLwygYg1HZUl14C70h7OI6W
	KLA9PsUf/nHhgVeIOPZpc5TbdMmKzHGShmbnqY6pTeo/AnSka1wImHGWFvAaGmQ=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=l7Udmpr6INk3Y7iHo0bQdxqjBJ0=; b=TkzZcctjXln
	07K9q9eCM/f004pfaQqPyj651c2T4u2MGfbE6uDJDc0IkRNWeHNp6WhgX4I7DhR+
	hyCAsltm9otSZ9wkEbrga1DIHW/3mny+yyZ2t4RXUERqDKXxl0Q2d7NUw8lIX68t
	dvln/ss+8mgVBUbpZrHXUvOtxpzuTyVc=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTPSA id A654D458083; 
	Fri,  9 Dec 2011 15:14:47 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 892049dfc1c98a65fb0f01565e789b21f1bfad16
Message-Id: <892049dfc1c98a65fb0f.1323472552@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1323472550@xdev.gridcentric.ca>
References: <patchbomb.1323472550@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Fri, 09 Dec 2011 18:15:52 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com, andres@gridcentric.ca, tim@xen.org,
	ian.campbell@citrix.com, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 2 of 8] Tools: Update libxc mem sharing interface
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 tools/libxc/xc_memshr.c |  19 ++++++++++++++++++-
 tools/libxc/xenctrl.h   |   7 ++++++-
 2 files changed, 24 insertions(+), 2 deletions(-)


Previosuly, the mem sharing code would return an opaque handle
to index shared pages (and nominees) in its global hash table.
By removing the hash table, the handle becomes a version, to
avoid sharing a stale version of a page. Thus, libxc wrappers
need to be updated accordingly.

Signed-off-by: Adin Scannell <adin@scannell.ca>
Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 6f58de995103 -r 892049dfc1c9 tools/libxc/xc_memshr.c
--- a/tools/libxc/xc_memshr.c
+++ b/tools/libxc/xc_memshr.c
@@ -88,8 +88,13 @@ int xc_memshr_nominate_gref(xc_interface
 
 int xc_memshr_share(xc_interface *xch,
                     uint32_t source_domain,
+                    uint64_t source_gfn,
                     uint64_t source_handle,
-                    uint64_t client_handle)
+                    int source_is_gref,
+                    uint32_t client_domain,
+                    uint64_t client_gfn,
+                    uint64_t client_handle,
+                    int client_is_gref)
 {
     DECLARE_DOMCTL;
     struct xen_domctl_mem_sharing_op *op;
@@ -100,8 +105,20 @@ int xc_memshr_share(xc_interface *xch,
     op = &(domctl.u.mem_sharing_op);
     op->op = XEN_DOMCTL_MEM_EVENT_OP_SHARING_SHARE;
     op->u.share.source_handle = source_handle;
+    op->u.share.client_domain = (uint64_t) client_domain;
     op->u.share.client_handle = client_handle;
 
+    if (source_is_gref)
+        XEN_DOMCTL_MEM_SHARING_FIELD_MAKE_GREF(
+                op->u.share.source_gfn, source_gfn);
+    else
+        op->u.share.source_gfn = source_gfn;
+    if (client_is_gref)
+        XEN_DOMCTL_MEM_SHARING_FIELD_MAKE_GREF(
+                op->u.share.client_gfn, client_gfn);
+    else
+        op->u.share.client_gfn = client_gfn;
+
     return do_domctl(xch, &domctl);
 }
 
diff -r 6f58de995103 -r 892049dfc1c9 tools/libxc/xenctrl.h
--- a/tools/libxc/xenctrl.h
+++ b/tools/libxc/xenctrl.h
@@ -1893,8 +1893,13 @@ int xc_memshr_nominate_gref(xc_interface
                             uint64_t *handle);
 int xc_memshr_share(xc_interface *xch,
                     uint32_t source_domain,
+                    uint64_t source_gfn,
                     uint64_t source_handle,
-                    uint64_t client_handle);
+                    int source_is_gref,
+                    uint32_t client_domain,
+                    uint64_t client_gfn,
+                    uint64_t client_handle,
+                    int dest_is_gref);
 int xc_memshr_domain_resume(xc_interface *xch,
                             uint32_t domid);
 int xc_memshr_debug_gfn(xc_interface *xch,

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 23:16:23 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 23: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.xensource.com>)
	id 1RZ9fL-0002fG-5U; Fri, 09 Dec 2011 23:15:43 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RZ9fJ-0002dm-9q
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 23:15:41 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-16.tower-21.messagelabs.com!1323472490!915187!1
X-Originating-IP: [208.97.132.119]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xMTkgPT4gMTU5NzU=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12809 invoked from network); 9 Dec 2011 23:14:51 -0000
Received: from caiajhbdcbbj.dreamhost.com (HELO homiemail-a76.g.dreamhost.com)
	(208.97.132.119) by server-16.tower-21.messagelabs.com with SMTP;
	9 Dec 2011 23:14:51 -0000
Received: from homiemail-a76.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTP id 7F5CD458083;
	Fri,  9 Dec 2011 15:14:50 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=DIqSBiIPxo7AxAZLenAPXXzd6A+7wQ3z91X/RjPhv27c
	YeYU9LwF9p4AhW7hWjyYM/rk+V+kQj2CpRk6kMnBHVuvtsNac3Ln7y0a20QSOptW
	rfeaFoFsBBnZGUKF4kPnPcFDXCKcxkrAuUeRjDy0texOhwCOgYnODWKEtH4ZoF4=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=sc3eMmqquJSHIG2JJy3tTqwTiEM=; b=GC/9FNQWcmS
	XXIhRHtCLdRI00JZ8RuaiY01hIIRJgPrwLTEbXg02m6pPfxwoQQEGlFP6T7zr0d2
	kHrhdSQNBYwrBuYwbTAdJZu8AWJcIweR5dvApJrOiv3Gk65QrviYgq/rB6Y4Oa6m
	B6q0J9z7u+PTybdwDqzJBZONEZe48Mgo=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTPSA id CCB50458081; 
	Fri,  9 Dec 2011 15:14:49 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: a22140d92931036b591c506ae74c1adf383fd523
Message-Id: <a22140d92931036b591c.1323472554@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1323472550@xdev.gridcentric.ca>
References: <patchbomb.1323472550@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Fri, 09 Dec 2011 18:15:54 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com, andres@gridcentric.ca, tim@xen.org,
	ian.campbell@citrix.com, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 4 of 8] Tools: Add a sharing command to xl for
 information about shared pages
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 docs/man/xl.pod.1         |  18 +++++++++
 tools/libxl/xl.h          |   1 +
 tools/libxl/xl_cmdimpl.c  |  85 +++++++++++++++++++++++++++++++++++++++++++++++
 tools/libxl/xl_cmdtable.c |   6 +++
 4 files changed, 110 insertions(+), 0 deletions(-)


Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Signed-off-by: Adin Scannell <adin@scannell.ca>

diff -r e16f5d2643c9 -r a22140d92931 docs/man/xl.pod.1
--- a/docs/man/xl.pod.1
+++ b/docs/man/xl.pod.1
@@ -280,6 +280,24 @@ B<Warning:> There is no good way to know
 mem-set will make a domain unstable and cause it to crash.  Be very
 careful when using this command on running domains.
 
+=item B<sharing> [I<-t> I<--totals>] [I<domain-id>]
+
+List count of shared pages. 
+
+B<OPTIONS>
+
+=over 4
+
+=item I<domain_id>
+
+List specifically for that domain. Otherwise, list for all domains.
+
+=item I<-t>, I<--totals>
+
+Also print global count of shared pages for this host.
+
+=back
+
 =item B<migrate> [I<OPTIONS>] I<domain-id> I<host>
 
 Migrate a domain to another host machine. By default B<xl> relies on ssh as a
diff -r e16f5d2643c9 -r a22140d92931 tools/libxl/xl.h
--- a/tools/libxl/xl.h
+++ b/tools/libxl/xl.h
@@ -28,6 +28,7 @@ struct cmd_spec {
 
 int main_vcpulist(int argc, char **argv);
 int main_info(int argc, char **argv);
+int main_sharing(int argc, char **argv);
 int main_cd_eject(int argc, char **argv);
 int main_cd_insert(int argc, char **argv);
 int main_console(int argc, char **argv);
diff -r e16f5d2643c9 -r a22140d92931 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -3755,6 +3755,91 @@ int main_info(int argc, char **argv)
     return 0;
 }
 
+static void sharing(int totals, const libxl_dominfo *info, int nb_domain)
+{
+    int i;
+
+    printf("Name                                        ID   Mem Shared\n");
+
+    for (i = 0; i < nb_domain; i++) {
+        char *domname;
+        unsigned shutdown_reason;
+        domname = libxl_domid_to_name(ctx, info[i].domid);
+        shutdown_reason = info[i].shutdown ? info[i].shutdown_reason : 0;
+        printf("%-40s %5d %5lu  %5lu\n",
+                domname,
+                info[i].domid,
+                (unsigned long) (info[i].current_memkb / 1024),
+                (unsigned long) (info[i].shared_memkb / 1024));
+        free(domname);
+    }
+
+    if (totals)
+    {
+        /* To be added with a future patch. */
+    }
+}
+
+int main_sharing(int argc, char **argv)
+{
+    int opt;
+    int option_index = 0;
+    static struct option long_options[] = {
+        {"help", 0, 0, 'h'},
+        {"totals", 0, 0, 't'},
+        {0, 0, 0, 0}
+    };
+    int totals = 0;
+
+    libxl_dominfo info_buf;
+    libxl_dominfo *info, *info_free=0;
+    int nb_domain, rc;
+
+    while ((opt = getopt_long(argc, argv, "ht", long_options, &option_index)) != -1) {
+        switch (opt) {
+        case 'h':
+            help("sharing");
+            return 0;
+        case 't':
+            totals = 1;
+            break;
+        default:
+            fprintf(stderr, "option `%c' not supported.\n", optopt);
+            break;
+        }
+    }
+
+    if (optind >= argc) {
+        info = libxl_list_domain(ctx, &nb_domain);
+        if (!info) {
+            fprintf(stderr, "libxl_domain_infolist failed.\n");
+            return 1;
+        }
+        info_free = info;
+    } else if (optind == argc-1) {
+        find_domain(argv[optind]);
+        rc = libxl_domain_info(ctx, &info_buf, domid);
+        if (rc == ERROR_INVAL) {
+            fprintf(stderr, "Error: Domain \'%s\' does not exist.\n",
+                argv[optind]);
+            return -rc;
+        }
+        if (rc) {
+            fprintf(stderr, "libxl_domain_info failed (code %d).\n", rc);
+            return -rc;
+        }
+        info = &info_buf;
+        nb_domain = 1;
+    } else {
+        help("sharing");
+        return 2;
+    }
+
+    sharing(totals, info, nb_domain);
+
+    return 0;
+}
+
 static int sched_credit_domain_get(
     int domid, libxl_sched_credit *scinfo)
 {
diff -r e16f5d2643c9 -r a22140d92931 tools/libxl/xl_cmdtable.c
--- a/tools/libxl/xl_cmdtable.c
+++ b/tools/libxl/xl_cmdtable.c
@@ -189,6 +189,12 @@ struct cmd_spec cmd_table[] = {
       "Get information about Xen host",
       "-n, --numa         List host NUMA topology information",
     },
+    { "sharing",
+      &main_sharing, 0,
+      "Get information about page sharing",
+      "[options] [Domain]", 
+      "-t, --totals              Include host totals in the output",
+    },
     { "sched-credit",
       &main_sched_credit, 0,
       "Get/set credit scheduler parameters",

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 23:16:23 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 23: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.xensource.com>)
	id 1RZ9fL-0002fG-5U; Fri, 09 Dec 2011 23:15:43 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RZ9fJ-0002dm-9q
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 23:15:41 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-16.tower-21.messagelabs.com!1323472490!915187!1
X-Originating-IP: [208.97.132.119]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xMTkgPT4gMTU5NzU=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12809 invoked from network); 9 Dec 2011 23:14:51 -0000
Received: from caiajhbdcbbj.dreamhost.com (HELO homiemail-a76.g.dreamhost.com)
	(208.97.132.119) by server-16.tower-21.messagelabs.com with SMTP;
	9 Dec 2011 23:14:51 -0000
Received: from homiemail-a76.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTP id 7F5CD458083;
	Fri,  9 Dec 2011 15:14:50 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=DIqSBiIPxo7AxAZLenAPXXzd6A+7wQ3z91X/RjPhv27c
	YeYU9LwF9p4AhW7hWjyYM/rk+V+kQj2CpRk6kMnBHVuvtsNac3Ln7y0a20QSOptW
	rfeaFoFsBBnZGUKF4kPnPcFDXCKcxkrAuUeRjDy0texOhwCOgYnODWKEtH4ZoF4=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=sc3eMmqquJSHIG2JJy3tTqwTiEM=; b=GC/9FNQWcmS
	XXIhRHtCLdRI00JZ8RuaiY01hIIRJgPrwLTEbXg02m6pPfxwoQQEGlFP6T7zr0d2
	kHrhdSQNBYwrBuYwbTAdJZu8AWJcIweR5dvApJrOiv3Gk65QrviYgq/rB6Y4Oa6m
	B6q0J9z7u+PTybdwDqzJBZONEZe48Mgo=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTPSA id CCB50458081; 
	Fri,  9 Dec 2011 15:14:49 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: a22140d92931036b591c506ae74c1adf383fd523
Message-Id: <a22140d92931036b591c.1323472554@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1323472550@xdev.gridcentric.ca>
References: <patchbomb.1323472550@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Fri, 09 Dec 2011 18:15:54 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com, andres@gridcentric.ca, tim@xen.org,
	ian.campbell@citrix.com, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 4 of 8] Tools: Add a sharing command to xl for
 information about shared pages
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 docs/man/xl.pod.1         |  18 +++++++++
 tools/libxl/xl.h          |   1 +
 tools/libxl/xl_cmdimpl.c  |  85 +++++++++++++++++++++++++++++++++++++++++++++++
 tools/libxl/xl_cmdtable.c |   6 +++
 4 files changed, 110 insertions(+), 0 deletions(-)


Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Signed-off-by: Adin Scannell <adin@scannell.ca>

diff -r e16f5d2643c9 -r a22140d92931 docs/man/xl.pod.1
--- a/docs/man/xl.pod.1
+++ b/docs/man/xl.pod.1
@@ -280,6 +280,24 @@ B<Warning:> There is no good way to know
 mem-set will make a domain unstable and cause it to crash.  Be very
 careful when using this command on running domains.
 
+=item B<sharing> [I<-t> I<--totals>] [I<domain-id>]
+
+List count of shared pages. 
+
+B<OPTIONS>
+
+=over 4
+
+=item I<domain_id>
+
+List specifically for that domain. Otherwise, list for all domains.
+
+=item I<-t>, I<--totals>
+
+Also print global count of shared pages for this host.
+
+=back
+
 =item B<migrate> [I<OPTIONS>] I<domain-id> I<host>
 
 Migrate a domain to another host machine. By default B<xl> relies on ssh as a
diff -r e16f5d2643c9 -r a22140d92931 tools/libxl/xl.h
--- a/tools/libxl/xl.h
+++ b/tools/libxl/xl.h
@@ -28,6 +28,7 @@ struct cmd_spec {
 
 int main_vcpulist(int argc, char **argv);
 int main_info(int argc, char **argv);
+int main_sharing(int argc, char **argv);
 int main_cd_eject(int argc, char **argv);
 int main_cd_insert(int argc, char **argv);
 int main_console(int argc, char **argv);
diff -r e16f5d2643c9 -r a22140d92931 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -3755,6 +3755,91 @@ int main_info(int argc, char **argv)
     return 0;
 }
 
+static void sharing(int totals, const libxl_dominfo *info, int nb_domain)
+{
+    int i;
+
+    printf("Name                                        ID   Mem Shared\n");
+
+    for (i = 0; i < nb_domain; i++) {
+        char *domname;
+        unsigned shutdown_reason;
+        domname = libxl_domid_to_name(ctx, info[i].domid);
+        shutdown_reason = info[i].shutdown ? info[i].shutdown_reason : 0;
+        printf("%-40s %5d %5lu  %5lu\n",
+                domname,
+                info[i].domid,
+                (unsigned long) (info[i].current_memkb / 1024),
+                (unsigned long) (info[i].shared_memkb / 1024));
+        free(domname);
+    }
+
+    if (totals)
+    {
+        /* To be added with a future patch. */
+    }
+}
+
+int main_sharing(int argc, char **argv)
+{
+    int opt;
+    int option_index = 0;
+    static struct option long_options[] = {
+        {"help", 0, 0, 'h'},
+        {"totals", 0, 0, 't'},
+        {0, 0, 0, 0}
+    };
+    int totals = 0;
+
+    libxl_dominfo info_buf;
+    libxl_dominfo *info, *info_free=0;
+    int nb_domain, rc;
+
+    while ((opt = getopt_long(argc, argv, "ht", long_options, &option_index)) != -1) {
+        switch (opt) {
+        case 'h':
+            help("sharing");
+            return 0;
+        case 't':
+            totals = 1;
+            break;
+        default:
+            fprintf(stderr, "option `%c' not supported.\n", optopt);
+            break;
+        }
+    }
+
+    if (optind >= argc) {
+        info = libxl_list_domain(ctx, &nb_domain);
+        if (!info) {
+            fprintf(stderr, "libxl_domain_infolist failed.\n");
+            return 1;
+        }
+        info_free = info;
+    } else if (optind == argc-1) {
+        find_domain(argv[optind]);
+        rc = libxl_domain_info(ctx, &info_buf, domid);
+        if (rc == ERROR_INVAL) {
+            fprintf(stderr, "Error: Domain \'%s\' does not exist.\n",
+                argv[optind]);
+            return -rc;
+        }
+        if (rc) {
+            fprintf(stderr, "libxl_domain_info failed (code %d).\n", rc);
+            return -rc;
+        }
+        info = &info_buf;
+        nb_domain = 1;
+    } else {
+        help("sharing");
+        return 2;
+    }
+
+    sharing(totals, info, nb_domain);
+
+    return 0;
+}
+
 static int sched_credit_domain_get(
     int domid, libxl_sched_credit *scinfo)
 {
diff -r e16f5d2643c9 -r a22140d92931 tools/libxl/xl_cmdtable.c
--- a/tools/libxl/xl_cmdtable.c
+++ b/tools/libxl/xl_cmdtable.c
@@ -189,6 +189,12 @@ struct cmd_spec cmd_table[] = {
       "Get information about Xen host",
       "-n, --numa         List host NUMA topology information",
     },
+    { "sharing",
+      &main_sharing, 0,
+      "Get information about page sharing",
+      "[options] [Domain]", 
+      "-t, --totals              Include host totals in the output",
+    },
     { "sched-credit",
       &main_sched_credit, 0,
       "Get/set credit scheduler parameters",

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 23:16:23 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 23: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.xensource.com>)
	id 1RZ9fD-0002dd-A5; Fri, 09 Dec 2011 23:15:35 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RZ9fB-0002dO-It
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 23:15:33 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-7.tower-27.messagelabs.com!1323472437!60155677!1
X-Originating-IP: [208.97.132.74]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi43NCA9PiAxNDk5OQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10401 invoked from network); 9 Dec 2011 23:13:57 -0000
Received: from caiajhbdcahe.dreamhost.com (HELO homiemail-a76.g.dreamhost.com)
	(208.97.132.74) by server-7.tower-27.messagelabs.com with SMTP;
	9 Dec 2011 23:13:57 -0000
Received: from homiemail-a76.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTP id 70F7B458080;
	Fri,  9 Dec 2011 15:14:46 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id:date
	:from:to:cc; q=dns; s=lagarcavilla.org; b=uMFo7E40UadZdmGRsyaOE1
	jfk1s78FzBGw5GN7joZnR9/fgnn0XhnhPegX3GSfIALnXMT+zKg9bsZpX43ZwPrm
	Pmuw8qP7HuzthPXoYqeGasNnRinPL7xnnOwU/eiJGL4CDjX1Ks6EUg/1jmv/KdCi
	yz6gIiGuh5FzQ9desuks8=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:date:from:to:cc; s=lagarcavilla.org; bh=xIExyit8ET5G
	5ASWwatVRkaDqUU=; b=IWiDC3Wht6brcy9Lz+mHJhQpgnpmYWAPZCavk8rmayrG
	jrwJgNqcgMdxroZ4+782SAXaLhP9UqETWSdBK6Z6RKdEGhsN7Sj2iWK4z6IDLDKO
	lspNXPucDGyhjKXPj1dm3yNW/N6HafjwqdwwLEKuQSrp9iXa2RKKvJZC0DFiEr8=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTPSA id A06C9458081; 
	Fri,  9 Dec 2011 15:14:45 -0800 (PST)
MIME-Version: 1.0
Message-Id: <patchbomb.1323472550@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Fri, 09 Dec 2011 18:15:50 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com, andres@gridcentric.ca, tim@xen.org,
	ian.campbell@citrix.com, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 0 of 8] Tools: Memory sharing interface updates
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

In this patch series we update the toolstack to support changes to
the sharing interface:

- Refresh to be compatible with new hypervisor API
- Refresh tools/memshr
- Polling of more stats
- xl sharing command to output the stats
- Support for new domctls.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Signed-off-by: Adin Scannell <adin@scannell.ca>

 tools/libxc/xc_memshr.c               |   3 +-
 tools/libxc/xenctrl.h                 |   1 +
 tools/libxc/xc_memshr.c               |  19 +++++++-
 tools/libxc/xenctrl.h                 |   7 ++-
 tools/blktap2/drivers/Makefile        |   2 +-
 tools/blktap2/drivers/tapdisk-image.c |   2 +-
 tools/blktap2/drivers/tapdisk-vbd.c   |   6 +-
 tools/blktap2/drivers/tapdisk.h       |   6 ++-
 tools/memshr/bidir-daemon.c           |  34 +++++++++----
 tools/memshr/bidir-hash.h             |  13 +++--
 tools/memshr/interface.c              |  30 +++++++----
 tools/memshr/memshr.h                 |  11 +++-
 docs/man/xl.pod.1                     |  18 +++++++
 tools/libxl/xl.h                      |   1 +
 tools/libxl/xl_cmdimpl.c              |  85 +++++++++++++++++++++++++++++++++++
 tools/libxl/xl_cmdtable.c             |   6 ++
 tools/libxc/xc_private.c              |  10 ++++
 tools/libxc/xenctrl.h                 |   4 +
 tools/libxl/libxl.c                   |  10 ++++
 tools/libxl/libxl.h                   |   3 +
 tools/libxl/xl_cmdimpl.c              |  12 +++-
 tools/libxc/xc_memshr.c               |  23 +++++++++
 tools/libxc/xenctrl.h                 |   6 ++
 tools/libxc/xc_memshr.c               |  14 +++++
 tools/libxc/xenctrl.h                 |   2 +
 25 files changed, 287 insertions(+), 41 deletions(-)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 23:16:23 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 23: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.xensource.com>)
	id 1RZ9fH-0002e8-Nr; Fri, 09 Dec 2011 23:15:39 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RZ9fG-0002dN-IG
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 23:15:38 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-6.tower-174.messagelabs.com!1323472488!4966783!1
X-Originating-IP: [208.97.132.207]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4yMDcgPT4gMTU0OTI=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17412 invoked from network); 9 Dec 2011 23:14:48 -0000
Received: from caiajhbdccah.dreamhost.com (HELO homiemail-a76.g.dreamhost.com)
	(208.97.132.207) by server-6.tower-174.messagelabs.com with SMTP;
	9 Dec 2011 23:14:48 -0000
Received: from homiemail-a76.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTP id 76FF6458081;
	Fri,  9 Dec 2011 15:14:47 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=vK8R4l3+AsBtg2cPyqddK5G2y5CXhvDN/19+3HUWfEZq
	sZSrk+V1oaEGmMEqSdGMTHN74CfkzT3q3q8q/kmRx1vSmXi6RQePnPEjR4L3ClO7
	mqaWc8KVaxJARvHZCUcCuUAQ6s0ko/3qdUEwa1vd9yE5fjXBuiocnlI6AeDhH40=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=pJBXnhD3+0nsvGWwoKQgWQ0bhM4=; b=Z6CNEBUuaXQ
	3NDq4uwWjaI0iCES/BqnK5TJwmj2rly6kZFEBlLT5oz6WLyXIYb8RbdvelJHaiNZ
	zdkpVOcuLDjfEugj92+K2kVwgzHvr37cQNnIqaCOYdw0+WqONyJi78V0YvwlwH+w
	kUVpXG5RNNdh3cn6YzfDgyxS0E0M9Cws=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTPSA id 9EED3458083; 
	Fri,  9 Dec 2011 15:14:46 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 6f58de995103b7bf415359ca0920ee97296de379
Message-Id: <6f58de995103b7bf4153.1323472551@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1323472550@xdev.gridcentric.ca>
References: <patchbomb.1323472550@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Fri, 09 Dec 2011 18:15:51 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com, andres@gridcentric.ca, tim@xen.org,
	ian.campbell@citrix.com, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 1 of 8] Tools: Do not assume sharing target is
 dom0 in libxc wrappers
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 tools/libxc/xc_memshr.c |  3 ++-
 tools/libxc/xenctrl.h   |  1 +
 2 files changed, 3 insertions(+), 1 deletions(-)


The libxc wrapper that shares two pages always assumed one
of the pages was mapped by dom0. Expand the API to specify
both sharing domains.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 835be7c121b7 -r 6f58de995103 tools/libxc/xc_memshr.c
--- a/tools/libxc/xc_memshr.c
+++ b/tools/libxc/xc_memshr.c
@@ -87,6 +87,7 @@ int xc_memshr_nominate_gref(xc_interface
 }
 
 int xc_memshr_share(xc_interface *xch,
+                    uint32_t source_domain,
                     uint64_t source_handle,
                     uint64_t client_handle)
 {
@@ -95,7 +96,7 @@ int xc_memshr_share(xc_interface *xch,
 
     domctl.cmd = XEN_DOMCTL_mem_sharing_op;
     domctl.interface_version = XEN_DOMCTL_INTERFACE_VERSION;
-    domctl.domain = 0;
+    domctl.domain = (domid_t) source_domain;
     op = &(domctl.u.mem_sharing_op);
     op->op = XEN_DOMCTL_MEM_EVENT_OP_SHARING_SHARE;
     op->u.share.source_handle = source_handle;
diff -r 835be7c121b7 -r 6f58de995103 tools/libxc/xenctrl.h
--- a/tools/libxc/xenctrl.h
+++ b/tools/libxc/xenctrl.h
@@ -1892,6 +1892,7 @@ int xc_memshr_nominate_gref(xc_interface
                             grant_ref_t gref,
                             uint64_t *handle);
 int xc_memshr_share(xc_interface *xch,
+                    uint32_t source_domain,
                     uint64_t source_handle,
                     uint64_t client_handle);
 int xc_memshr_domain_resume(xc_interface *xch,

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 23:16:23 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 23: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.xensource.com>)
	id 1RZ9fD-0002dd-A5; Fri, 09 Dec 2011 23:15:35 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RZ9fB-0002dO-It
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 23:15:33 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-7.tower-27.messagelabs.com!1323472437!60155677!1
X-Originating-IP: [208.97.132.74]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi43NCA9PiAxNDk5OQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10401 invoked from network); 9 Dec 2011 23:13:57 -0000
Received: from caiajhbdcahe.dreamhost.com (HELO homiemail-a76.g.dreamhost.com)
	(208.97.132.74) by server-7.tower-27.messagelabs.com with SMTP;
	9 Dec 2011 23:13:57 -0000
Received: from homiemail-a76.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTP id 70F7B458080;
	Fri,  9 Dec 2011 15:14:46 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id:date
	:from:to:cc; q=dns; s=lagarcavilla.org; b=uMFo7E40UadZdmGRsyaOE1
	jfk1s78FzBGw5GN7joZnR9/fgnn0XhnhPegX3GSfIALnXMT+zKg9bsZpX43ZwPrm
	Pmuw8qP7HuzthPXoYqeGasNnRinPL7xnnOwU/eiJGL4CDjX1Ks6EUg/1jmv/KdCi
	yz6gIiGuh5FzQ9desuks8=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:date:from:to:cc; s=lagarcavilla.org; bh=xIExyit8ET5G
	5ASWwatVRkaDqUU=; b=IWiDC3Wht6brcy9Lz+mHJhQpgnpmYWAPZCavk8rmayrG
	jrwJgNqcgMdxroZ4+782SAXaLhP9UqETWSdBK6Z6RKdEGhsN7Sj2iWK4z6IDLDKO
	lspNXPucDGyhjKXPj1dm3yNW/N6HafjwqdwwLEKuQSrp9iXa2RKKvJZC0DFiEr8=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTPSA id A06C9458081; 
	Fri,  9 Dec 2011 15:14:45 -0800 (PST)
MIME-Version: 1.0
Message-Id: <patchbomb.1323472550@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Fri, 09 Dec 2011 18:15:50 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com, andres@gridcentric.ca, tim@xen.org,
	ian.campbell@citrix.com, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 0 of 8] Tools: Memory sharing interface updates
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

In this patch series we update the toolstack to support changes to
the sharing interface:

- Refresh to be compatible with new hypervisor API
- Refresh tools/memshr
- Polling of more stats
- xl sharing command to output the stats
- Support for new domctls.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Signed-off-by: Adin Scannell <adin@scannell.ca>

 tools/libxc/xc_memshr.c               |   3 +-
 tools/libxc/xenctrl.h                 |   1 +
 tools/libxc/xc_memshr.c               |  19 +++++++-
 tools/libxc/xenctrl.h                 |   7 ++-
 tools/blktap2/drivers/Makefile        |   2 +-
 tools/blktap2/drivers/tapdisk-image.c |   2 +-
 tools/blktap2/drivers/tapdisk-vbd.c   |   6 +-
 tools/blktap2/drivers/tapdisk.h       |   6 ++-
 tools/memshr/bidir-daemon.c           |  34 +++++++++----
 tools/memshr/bidir-hash.h             |  13 +++--
 tools/memshr/interface.c              |  30 +++++++----
 tools/memshr/memshr.h                 |  11 +++-
 docs/man/xl.pod.1                     |  18 +++++++
 tools/libxl/xl.h                      |   1 +
 tools/libxl/xl_cmdimpl.c              |  85 +++++++++++++++++++++++++++++++++++
 tools/libxl/xl_cmdtable.c             |   6 ++
 tools/libxc/xc_private.c              |  10 ++++
 tools/libxc/xenctrl.h                 |   4 +
 tools/libxl/libxl.c                   |  10 ++++
 tools/libxl/libxl.h                   |   3 +
 tools/libxl/xl_cmdimpl.c              |  12 +++-
 tools/libxc/xc_memshr.c               |  23 +++++++++
 tools/libxc/xenctrl.h                 |   6 ++
 tools/libxc/xc_memshr.c               |  14 +++++
 tools/libxc/xenctrl.h                 |   2 +
 25 files changed, 287 insertions(+), 41 deletions(-)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 23:16:23 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 23: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.xensource.com>)
	id 1RZ9fH-0002e8-Nr; Fri, 09 Dec 2011 23:15:39 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RZ9fG-0002dN-IG
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 23:15:38 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-6.tower-174.messagelabs.com!1323472488!4966783!1
X-Originating-IP: [208.97.132.207]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4yMDcgPT4gMTU0OTI=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17412 invoked from network); 9 Dec 2011 23:14:48 -0000
Received: from caiajhbdccah.dreamhost.com (HELO homiemail-a76.g.dreamhost.com)
	(208.97.132.207) by server-6.tower-174.messagelabs.com with SMTP;
	9 Dec 2011 23:14:48 -0000
Received: from homiemail-a76.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTP id 76FF6458081;
	Fri,  9 Dec 2011 15:14:47 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=vK8R4l3+AsBtg2cPyqddK5G2y5CXhvDN/19+3HUWfEZq
	sZSrk+V1oaEGmMEqSdGMTHN74CfkzT3q3q8q/kmRx1vSmXi6RQePnPEjR4L3ClO7
	mqaWc8KVaxJARvHZCUcCuUAQ6s0ko/3qdUEwa1vd9yE5fjXBuiocnlI6AeDhH40=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=pJBXnhD3+0nsvGWwoKQgWQ0bhM4=; b=Z6CNEBUuaXQ
	3NDq4uwWjaI0iCES/BqnK5TJwmj2rly6kZFEBlLT5oz6WLyXIYb8RbdvelJHaiNZ
	zdkpVOcuLDjfEugj92+K2kVwgzHvr37cQNnIqaCOYdw0+WqONyJi78V0YvwlwH+w
	kUVpXG5RNNdh3cn6YzfDgyxS0E0M9Cws=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTPSA id 9EED3458083; 
	Fri,  9 Dec 2011 15:14:46 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 6f58de995103b7bf415359ca0920ee97296de379
Message-Id: <6f58de995103b7bf4153.1323472551@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1323472550@xdev.gridcentric.ca>
References: <patchbomb.1323472550@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Fri, 09 Dec 2011 18:15:51 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com, andres@gridcentric.ca, tim@xen.org,
	ian.campbell@citrix.com, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 1 of 8] Tools: Do not assume sharing target is
 dom0 in libxc wrappers
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 tools/libxc/xc_memshr.c |  3 ++-
 tools/libxc/xenctrl.h   |  1 +
 2 files changed, 3 insertions(+), 1 deletions(-)


The libxc wrapper that shares two pages always assumed one
of the pages was mapped by dom0. Expand the API to specify
both sharing domains.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 835be7c121b7 -r 6f58de995103 tools/libxc/xc_memshr.c
--- a/tools/libxc/xc_memshr.c
+++ b/tools/libxc/xc_memshr.c
@@ -87,6 +87,7 @@ int xc_memshr_nominate_gref(xc_interface
 }
 
 int xc_memshr_share(xc_interface *xch,
+                    uint32_t source_domain,
                     uint64_t source_handle,
                     uint64_t client_handle)
 {
@@ -95,7 +96,7 @@ int xc_memshr_share(xc_interface *xch,
 
     domctl.cmd = XEN_DOMCTL_mem_sharing_op;
     domctl.interface_version = XEN_DOMCTL_INTERFACE_VERSION;
-    domctl.domain = 0;
+    domctl.domain = (domid_t) source_domain;
     op = &(domctl.u.mem_sharing_op);
     op->op = XEN_DOMCTL_MEM_EVENT_OP_SHARING_SHARE;
     op->u.share.source_handle = source_handle;
diff -r 835be7c121b7 -r 6f58de995103 tools/libxc/xenctrl.h
--- a/tools/libxc/xenctrl.h
+++ b/tools/libxc/xenctrl.h
@@ -1892,6 +1892,7 @@ int xc_memshr_nominate_gref(xc_interface
                             grant_ref_t gref,
                             uint64_t *handle);
 int xc_memshr_share(xc_interface *xch,
+                    uint32_t source_domain,
                     uint64_t source_handle,
                     uint64_t client_handle);
 int xc_memshr_domain_resume(xc_interface *xch,

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 23:16:23 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 23: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.xensource.com>)
	id 1RZ9fN-0002g1-RX; Fri, 09 Dec 2011 23:15:45 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RZ9fL-0002dt-S3
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 23:15:44 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-16.tower-21.messagelabs.com!1323472493!915189!1
X-Originating-IP: [208.97.132.83]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi44MyA9PiAxNTY3Mw==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12842 invoked from network); 9 Dec 2011 23:14:53 -0000
Received: from caiajhbdcaid.dreamhost.com (HELO homiemail-a76.g.dreamhost.com)
	(208.97.132.83) by server-16.tower-21.messagelabs.com with SMTP;
	9 Dec 2011 23:14:53 -0000
Received: from homiemail-a76.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTP id A7FB1458083;
	Fri,  9 Dec 2011 15:14:52 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=ebRBmvtCUVIIG6fsf5cP9bVzJZt32/NNMmJZPZ/b0ZzF
	3m/WxOxSDr01Lw3bZweTt7UxuGFRpYkq4YtLy75jiq/dD/7tSkDOSzDdirAzVFou
	tjzbV4vqZm2Y4f0bSwB2KrhtvDr7qRsE1W3J4EAGDIFGNGfgxnWO1LtL3nRb41g=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=zgdhK0YDc8FTVvomLClRIEHM8Sc=; b=WN2lk7pYRHV
	eEyQAUgyhlAz5H800tJUU7/3FVrINFvwGF2mfLcWhaFchuGqzsmVXNMS/2V/J9Nu
	7yR4tE6OwmDt865wA6v+52C1LFzFBplcH+ybuVIp4abXfkrYY6/jGenZJiWYbM0w
	tToQGnFr8U9IAQGpiELCYgmhGp2IlYV8=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTPSA id C4BE1458081; 
	Fri,  9 Dec 2011 15:14:51 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 3fc7875c8d98cbc74598001d721c79f9bd32299d
Message-Id: <3fc7875c8d98cbc74598.1323472556@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1323472550@xdev.gridcentric.ca>
References: <patchbomb.1323472550@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Fri, 09 Dec 2011 18:15:56 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com, andres@gridcentric.ca, tim@xen.org,
	ian.campbell@citrix.com, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 6 of 8] Tools: Allow libxl/xl to expose the
 total number of shared frames and space saved
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 tools/libxl/libxl.c      |  10 ++++++++++
 tools/libxl/libxl.h      |   3 +++
 tools/libxl/xl_cmdimpl.c |  12 +++++++++---
 3 files changed, 22 insertions(+), 3 deletions(-)


Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Signed-off-by: Adin Scannell <adin@scannell.ca>

diff -r 6e8b8fb2c8b2 -r 3fc7875c8d98 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -499,6 +499,16 @@ int libxl_domain_pause(libxl_ctx *ctx, u
     return 0;
 }
 
+long libxl_sharing_used_frames(libxl_ctx *ctx)
+{
+    return xc_sharing_used_frames(ctx->xch);
+}
+
+long libxl_sharing_freed_pages(libxl_ctx *ctx)
+{
+    return xc_sharing_freed_pages(ctx->xch);
+}
+
 int libxl_domain_core_dump(libxl_ctx *ctx, uint32_t domid,
                            const char *filename)
 {
diff -r 6e8b8fb2c8b2 -r 3fc7875c8d98 tools/libxl/libxl.h
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -350,6 +350,9 @@ int libxl_domain_rename(libxl_ctx *ctx, 
 int libxl_domain_pause(libxl_ctx *ctx, uint32_t domid);
 int libxl_domain_unpause(libxl_ctx *ctx, uint32_t domid);
 
+long libxl_sharing_used_frames(libxl_ctx *ctx);
+long libxl_sharing_freed_pages(libxl_ctx *ctx);
+
 int libxl_domain_core_dump(libxl_ctx *ctx, uint32_t domid, const char *filename);
 
 int libxl_domain_setmaxmem(libxl_ctx *ctx, uint32_t domid, uint32_t target_memkb);
diff -r 6e8b8fb2c8b2 -r 3fc7875c8d98 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -3758,6 +3758,7 @@ int main_info(int argc, char **argv)
 static void sharing(int totals, const libxl_dominfo *info, int nb_domain)
 {
     int i;
+    const libxl_version_info *vinfo;
 
     printf("Name                                        ID   Mem Shared\n");
 
@@ -3774,9 +3775,14 @@ static void sharing(int totals, const li
         free(domname);
     }
 
-    if (totals)
-    {
-        /* To be added with a future patch. */
+    if (totals) {
+        vinfo = libxl_get_version_info(ctx);
+        if (vinfo) {
+            i = (1 << 20) / vinfo->pagesize;
+            printf("Freed with sharing: %ld  Total physical shared: %ld\n", 
+            libxl_sharing_freed_pages(ctx) / i,
+            libxl_sharing_used_frames(ctx) / i);
+        }
     }
 }
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 23:16:23 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 23: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.xensource.com>)
	id 1RZ9fP-0002hF-Lx; Fri, 09 Dec 2011 23:15:47 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RZ9fM-0002e2-Ou
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 23:15:45 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-15.tower-182.messagelabs.com!1323472493!6572784!1
X-Originating-IP: [208.97.132.145]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNDUgPT4gMTcyMjQ=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 502 invoked from network); 9 Dec 2011 23:14:54 -0000
Received: from caiajhbdcbef.dreamhost.com (HELO homiemail-a76.g.dreamhost.com)
	(208.97.132.145) by server-15.tower-182.messagelabs.com with SMTP;
	9 Dec 2011 23:14:54 -0000
Received: from homiemail-a76.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTP id 8F60A458081;
	Fri,  9 Dec 2011 15:14:53 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=YEss3tSa0QluQFWY8hR90gHbCe3y6DtGM7HkTumVtDRz
	u84dPafripGv455hNZWm70Aj+iJdPghqI+Sf+u0HrIYTxe/KwEYmchYocVd4GVO+
	rBFhe2i9GBzSuIjQa97RsNseuSYbR+mxxAoO9pT46Ziz7Z19ofp538gei6hA7G0=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=Pko7KFgCM+/jQtejzAsFmipqCTo=; b=PQ5QiUzkVPK
	aimq2+4do4+QvH+wraH1/UOg1sbuFErUoON6pcj6uNEvUOe2H6iFdGXNf+xMEumM
	IAYWXlsCLiHVTkQ5M88aTYr0aQBVwkqIZ3eg96dkd47iE8S9eHbpkwAnNi9T5zxI
	Ja0X1u90xzFx8LO8Kt0QavVuc9w9rQXI=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTPSA id D6194458080; 
	Fri,  9 Dec 2011 15:14:52 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 33935769e2577e85d24a91f5ee3b8e8cad719fe2
Message-Id: <33935769e2577e85d24a.1323472557@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1323472550@xdev.gridcentric.ca>
References: <patchbomb.1323472550@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Fri, 09 Dec 2011 18:15:57 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com, andres@gridcentric.ca, tim@xen.org,
	ian.campbell@citrix.com, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 7 of 8] Tools: Libxc wrappers to add shared
	pages to physmap
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 tools/libxc/xc_memshr.c |  23 +++++++++++++++++++++++
 tools/libxc/xenctrl.h   |   6 ++++++
 2 files changed, 29 insertions(+), 0 deletions(-)


Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 3fc7875c8d98 -r 33935769e257 tools/libxc/xc_memshr.c
--- a/tools/libxc/xc_memshr.c
+++ b/tools/libxc/xc_memshr.c
@@ -86,6 +86,29 @@ int xc_memshr_nominate_gref(xc_interface
     return ret;
 }
 
+int xc_memshr_add_to_physmap(xc_interface *xch,
+                    uint32_t source_domain,
+                    uint64_t source_gfn,
+                    uint64_t source_handle,
+                    uint32_t client_domain,
+                    uint64_t client_gfn)
+{
+    DECLARE_DOMCTL;
+    struct xen_domctl_mem_sharing_op *op;
+
+    domctl.cmd                  = XEN_DOMCTL_mem_sharing_op;
+    domctl.interface_version    = XEN_DOMCTL_INTERFACE_VERSION;
+    domctl.domain               = (domid_t) source_domain;
+    op = &(domctl.u.mem_sharing_op);
+    op->op = XEN_DOMCTL_MEM_EVENT_OP_SHARING_ADD_PHYSMAP;
+    op->u.share.source_gfn      = source_gfn;
+    op->u.share.source_handle   = source_handle;
+    op->u.share.client_gfn      = client_gfn;
+    op->u.share.client_domain   = (uint64_t) client_domain;
+
+    return do_domctl(xch, &domctl);
+}
+
 int xc_memshr_share(xc_interface *xch,
                     uint32_t source_domain,
                     uint64_t source_gfn,
diff -r 3fc7875c8d98 -r 33935769e257 tools/libxc/xenctrl.h
--- a/tools/libxc/xenctrl.h
+++ b/tools/libxc/xenctrl.h
@@ -1895,6 +1895,12 @@ int xc_memshr_nominate_gref(xc_interface
                             uint32_t domid,
                             grant_ref_t gref,
                             uint64_t *handle);
+int xc_memshr_add_to_physmap(xc_interface *xch,
+                    uint32_t source_domain,
+                    uint64_t source_gfn,
+                    uint64_t source_handle,
+                    uint32_t client_domain,
+                    uint64_t client_gfn);
 int xc_memshr_share(xc_interface *xch,
                     uint32_t source_domain,
                     uint64_t source_gfn,

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 23:16:23 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 23: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.xensource.com>)
	id 1RZ9fJ-0002eW-Id; Fri, 09 Dec 2011 23:15:41 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RZ9fI-0002dc-DN
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 23:15:40 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-10.tower-216.messagelabs.com!1323472489!6769216!1
X-Originating-IP: [208.97.132.145]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNDUgPT4gMTczNjI=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30456 invoked from network); 9 Dec 2011 23:14:50 -0000
Received: from caiajhbdcbef.dreamhost.com (HELO homiemail-a76.g.dreamhost.com)
	(208.97.132.145) by server-10.tower-216.messagelabs.com with SMTP;
	9 Dec 2011 23:14:50 -0000
Received: from homiemail-a76.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTP id 8FB50458080;
	Fri,  9 Dec 2011 15:14:49 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=GxgHf0fEXWcFQlJaYeJDVXigey6++YUCkAcvHgJ8ohZo
	4xjx7hs29dpIctHP83zSAzL3eVmd9F1BW/MDF3zfWLZDQUInZBeESX3A04jRjnAg
	Mt92VBXJg3M6q01l5TOzC2+IsJXKHn6WkiUg1+FI08W80EZPW6Xl+zdvRIEfNt8=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=4aX5tLQJVHtR5FJCOInWnM+sraQ=; b=PArlvsVAGv2
	2ZFyWd8G81k2ORHVQJV+L0Ll4II5NuuGdxNFy1Z370HUtyfkBO+2RreujGmV96fF
	yj5AJDHEA5JRa5zF9x2Pyy5sOWWf1eQqTc9XfShR/7RY9RuKYMIvOeFpjl7FbHBI
	1wt7XCAluMo1kNDGUSqZ/0H/gW1SzGiY=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTPSA id A4975458083; 
	Fri,  9 Dec 2011 15:14:48 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: e16f5d2643c910d9b8c1dfe967db94a121636bdd
Message-Id: <e16f5d2643c910d9b8c1.1323472553@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1323472550@xdev.gridcentric.ca>
References: <patchbomb.1323472550@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Fri, 09 Dec 2011 18:15:53 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com, andres@gridcentric.ca, tim@xen.org,
	ian.campbell@citrix.com, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 3 of 8] Tools: Update memshr tool to use new
	sharing API
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 tools/blktap2/drivers/Makefile        |   2 +-
 tools/blktap2/drivers/tapdisk-image.c |   2 +-
 tools/blktap2/drivers/tapdisk-vbd.c   |   6 +++---
 tools/blktap2/drivers/tapdisk.h       |   6 +++++-
 tools/memshr/bidir-daemon.c           |  34 ++++++++++++++++++++++++----------
 tools/memshr/bidir-hash.h             |  13 ++++++++-----
 tools/memshr/interface.c              |  30 ++++++++++++++++++------------
 tools/memshr/memshr.h                 |  11 +++++++++--
 8 files changed, 69 insertions(+), 35 deletions(-)


The only (in-tree, that we know of) consumer of the mem sharing API
is the memshr tool (conditionally linked into blktap2). Update it to
use the new API.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 892049dfc1c9 -r e16f5d2643c9 tools/blktap2/drivers/Makefile
--- a/tools/blktap2/drivers/Makefile
+++ b/tools/blktap2/drivers/Makefile
@@ -43,7 +43,7 @@ MEMSHR_DIR = $(XEN_ROOT)/tools/memshr
 MEMSHRLIBS :=
 ifeq ($(CONFIG_Linux), __fixme__)
 CFLAGS += -DMEMSHR
-MEMSHRLIBS += $(MEMSHR_DIR)/libmemshr.a
+MEMSHRLIBS += -L$(XEN_ROOT)/tools/libxc -lxenctrl $(MEMSHR_DIR)/libmemshr.a
 endif
 
 ifeq ($(VHD_STATIC),y)
diff -r 892049dfc1c9 -r e16f5d2643c9 tools/blktap2/drivers/tapdisk-image.c
--- a/tools/blktap2/drivers/tapdisk-image.c
+++ b/tools/blktap2/drivers/tapdisk-image.c
@@ -60,7 +60,7 @@ tapdisk_image_allocate(const char *file,
 	image->storage   = storage;
 	image->private   = private;
 #ifdef MEMSHR
-	image->memshr_id = memshr_vbd_image_get(file);
+	image->memshr_id = memshr_vbd_image_get((char *)file);
 #endif
 	INIT_LIST_HEAD(&image->next);
 
diff -r 892049dfc1c9 -r e16f5d2643c9 tools/blktap2/drivers/tapdisk-vbd.c
--- a/tools/blktap2/drivers/tapdisk-vbd.c
+++ b/tools/blktap2/drivers/tapdisk-vbd.c
@@ -1218,14 +1218,14 @@ __tapdisk_vbd_complete_td_request(td_vbd
 #ifdef MEMSHR
 		if (treq.op == TD_OP_READ
 		   && td_flag_test(image->flags, TD_OPEN_RDONLY)) {
-			uint64_t hnd  = treq.memshr_hnd;
+			share_tuple_t hnd = treq.memshr_hnd;
 			uint16_t uid  = image->memshr_id;
 			blkif_request_t *breq = &vreq->req;
 			uint64_t sec  = tapdisk_vbd_breq_get_sector(breq, treq);
 			int secs = breq->seg[treq.sidx].last_sect -
 			    breq->seg[treq.sidx].first_sect + 1;
 
-			if (hnd != 0)
+			if (hnd.handle != 0)
 				memshr_vbd_complete_ro_request(hnd, uid,
 								sec, secs);
 		}
@@ -1297,7 +1297,7 @@ __tapdisk_vbd_reissue_td_request(td_vbd_
 				/* Reset memshr handle. This'll prevent
 				 * memshr_vbd_complete_ro_request being called
 				 */
-				treq.memshr_hnd = 0;
+				treq.memshr_hnd.handle = 0;
 				td_complete_request(treq, 0);
 			} else
 				td_queue_read(parent, treq);
diff -r 892049dfc1c9 -r e16f5d2643c9 tools/blktap2/drivers/tapdisk.h
--- a/tools/blktap2/drivers/tapdisk.h
+++ b/tools/blktap2/drivers/tapdisk.h
@@ -64,6 +64,10 @@
 #include "tapdisk-log.h"
 #include "tapdisk-utils.h"
 
+#ifdef MEMSHR
+#include "memshr.h"
+#endif
+
 #define DPRINTF(_f, _a...)           syslog(LOG_INFO, _f, ##_a)
 #define EPRINTF(_f, _a...)           syslog(LOG_ERR, "tap-err:%s: " _f, __func__, ##_a)
 #define PERROR(_f, _a...)            EPRINTF(_f ": %s", ##_a, strerror(errno))
@@ -136,7 +140,7 @@ struct td_request {
 	void                        *private;
     
 #ifdef MEMSHR
-	uint64_t                     memshr_hnd;
+	share_tuple_t                memshr_hnd;
 #endif
 };
 
diff -r 892049dfc1c9 -r e16f5d2643c9 tools/memshr/bidir-daemon.c
--- a/tools/memshr/bidir-daemon.c
+++ b/tools/memshr/bidir-daemon.c
@@ -19,16 +19,25 @@
 #include <pthread.h>
 #include <inttypes.h>
 #include <unistd.h>
+#include <errno.h>
 
 #include "bidir-hash.h"
 #include "memshr-priv.h"
 
 static struct blockshr_hash *blks_hash;
 
+/* Callback in the iterator, remember this value, and leave */
+int find_one(vbdblk_t k, share_tuple_t v, void *priv)
+{
+    share_tuple_t *rv = (share_tuple_t *) priv;
+    *rv = v;
+    /* Break out of iterator loop */
+    return 1;
+}
+
 void* bidir_daemon(void *unused)
 {
     uint32_t nr_ent, max_nr_ent, tab_size, max_load, min_load;
-    static uint64_t shrhnd = 1;
 
     while(1)
     {
@@ -41,20 +50,30 @@ void* bidir_daemon(void *unused)
         /* Remove some hints as soon as we get to 90% capacity */ 
         if(10 * nr_ent > 9 * max_nr_ent)
         {
-            uint64_t next_remove = shrhnd;
+            share_tuple_t next_remove;
             int to_remove;
             int ret;
 
             to_remove = 0.1 * max_nr_ent; 
             while(to_remove > 0) 
             {
-                ret = blockshr_shrhnd_remove(blks_hash, next_remove, NULL);
-                if(ret < 0)
+                /* We use the iterator to get one entry */
+                next_remove.handle = 0;
+                ret = blockshr_hash_iterator(blks_hash, find_one, &next_remove);
+
+                if ( !ret )
+                    if ( next_remove.handle == 0 )
+                        ret = -ESRCH;
+
+                if ( !ret )
+                    ret = blockshr_shrhnd_remove(blks_hash, next_remove, NULL);
+
+                if(ret <= 0)
                 {
                     /* We failed to remove an entry, because of a serious hash
                      * table error */
                     DPRINTF("Could not remove handle %"PRId64", error: %d\n",
-                            next_remove, ret);
+                            next_remove.handle, ret);
                     /* Force to exit the loop early */
                     to_remove = 0;
                 } else 
@@ -62,12 +81,7 @@ void* bidir_daemon(void *unused)
                 {
                     /* Managed to remove the entry. Note next_remove not
                      * incremented, in case there are duplicates */
-                    shrhnd = next_remove;
                     to_remove--;
-                } else
-                {
-                    /* Failed to remove, because there is no such handle */
-                    next_remove++;
                 }
             }
         }
diff -r 892049dfc1c9 -r e16f5d2643c9 tools/memshr/bidir-hash.h
--- a/tools/memshr/bidir-hash.h
+++ b/tools/memshr/bidir-hash.h
@@ -81,15 +81,16 @@ static int fgprtshr_mfn_cmp(uint32_t m1,
 #undef BIDIR_VALUE
 #undef BIDIR_KEY_T
 #undef BIDIR_VALUE_T
+
 /* TODO better hashes! */
 static inline uint32_t blockshr_block_hash(vbdblk_t block)
 {
     return (uint32_t)(block.sec) ^ (uint32_t)(block.disk_id);
 }
 
-static inline uint32_t blockshr_shrhnd_hash(uint64_t shrhnd)
+static inline uint32_t blockshr_shrhnd_hash(share_tuple_t shrhnd)
 {
-    return (uint32_t)shrhnd;
+    return ((uint32_t) shrhnd.handle);
 }
 
 static inline int blockshr_block_cmp(vbdblk_t b1, vbdblk_t b2)
@@ -97,15 +98,17 @@ static inline int blockshr_block_cmp(vbd
     return (b1.sec == b2.sec) && (b1.disk_id == b2.disk_id);
 }
 
-static inline int blockshr_shrhnd_cmp(uint64_t h1, uint64_t h2)
+static inline int blockshr_shrhnd_cmp(share_tuple_t h1, share_tuple_t h2)
 {
-    return (h1 == h2);
+    return ( (h1.domain == h2.domain) &&
+             (h1.frame  == h2.frame) &&
+             (h1.handle == h2.handle) );
 }
 #define BIDIR_NAME_PREFIX       blockshr
 #define BIDIR_KEY               block
 #define BIDIR_VALUE             shrhnd
 #define BIDIR_KEY_T             vbdblk_t
-#define BIDIR_VALUE_T           uint64_t
+#define BIDIR_VALUE_T           share_tuple_t
 #include "bidir-namedefs.h"
 
 #endif /* BLOCK_MAP */
diff -r 892049dfc1c9 -r e16f5d2643c9 tools/memshr/interface.c
--- a/tools/memshr/interface.c
+++ b/tools/memshr/interface.c
@@ -145,16 +145,17 @@ void memshr_vbd_image_put(uint16_t memsh
     
 int memshr_vbd_issue_ro_request(char *buf,
                                 grant_ref_t gref,
-                                uint16_t file_id, 
+                                uint16_t file_id,
                                 uint64_t sec, 
                                 int secs,
-                                uint64_t *hnd)
+                                share_tuple_t *hnd)
 {
     vbdblk_t blk;
-    uint64_t s_hnd, c_hnd;
+    share_tuple_t source_st, client_st;
+    uint64_t c_hnd;
     int ret;
 
-    *hnd = 0;
+    *hnd = (share_tuple_t){ 0, 0, 0 };
     if(!vbd_info.enabled) 
         return -1;
 
@@ -169,26 +170,31 @@ int memshr_vbd_issue_ro_request(char *bu
     /* If page couldn't be made sharable, we cannot do anything about it */
     if(ret != 0)
         return -3;
-    *hnd = c_hnd;
+
+    *(&client_st) = (share_tuple_t){ vbd_info.domid, gref, c_hnd };
+    *hnd = client_st;
 
     /* Check if we've read matching disk block previously */
     blk.sec     = sec;
     blk.disk_id = file_id;
-    if(blockshr_block_lookup(memshr.blks, blk, &s_hnd) > 0)
+    if(blockshr_block_lookup(memshr.blks, blk, &source_st) > 0)
     {
-        ret = xc_memshr_share(vbd_info.xc_handle, s_hnd, c_hnd);
+        ret = xc_memshr_share(vbd_info.xc_handle, source_st.domain, source_st.frame, 
+                                source_st.handle, 1, vbd_info.domid, gref, c_hnd, 1);
         if(!ret) return 0;
         /* Handles failed to be shared => at least one of them must be invalid,
            remove the relevant ones from the map */
         switch(ret)
         {
             case XEN_DOMCTL_MEM_SHARING_S_HANDLE_INVALID:
-                ret = blockshr_shrhnd_remove(memshr.blks, s_hnd, NULL);
-                if(ret) DPRINTF("Could not rm invl s_hnd: %"PRId64"\n", s_hnd);
+                ret = blockshr_shrhnd_remove(memshr.blks, source_st, NULL);
+                if(ret) DPRINTF("Could not rm invl s_hnd: %u %"PRId64" %"PRId64"\n", 
+                                    source_st.domain, source_st.frame, source_st.handle);
                 break;
             case XEN_DOMCTL_MEM_SHARING_C_HANDLE_INVALID:
-                ret = blockshr_shrhnd_remove(memshr.blks, c_hnd, NULL);
-                if(ret) DPRINTF("Could not rm invl c_hnd: %"PRId64"\n", c_hnd);
+                ret = blockshr_shrhnd_remove(memshr.blks, client_st, NULL);
+                if(ret) DPRINTF("Could not rm invl c_hnd: %u %"PRId64" %"PRId64"\n", 
+                                    client_st.domain, client_st.frame, client_st.handle);
                 break;
             default:
                 break;
@@ -199,7 +205,7 @@ int memshr_vbd_issue_ro_request(char *bu
     return -4;
 }
 
-void memshr_vbd_complete_ro_request(uint64_t hnd,
+void memshr_vbd_complete_ro_request(share_tuple_t hnd,
                                     uint16_t file_id, 
                                     uint64_t sec, 
                                     int secs)
diff -r 892049dfc1c9 -r e16f5d2643c9 tools/memshr/memshr.h
--- a/tools/memshr/memshr.h
+++ b/tools/memshr/memshr.h
@@ -25,6 +25,13 @@
 
 typedef uint64_t xen_mfn_t;
 
+typedef struct share_tuple 
+{
+    uint32_t domain;
+    uint64_t frame;
+    uint64_t handle;
+} share_tuple_t;
+
 extern void memshr_set_domid(int domid);
 extern void memshr_daemon_initialize(void);
 extern void memshr_vbd_initialize(void);
@@ -35,9 +42,9 @@ extern int memshr_vbd_issue_ro_request(c
                                        uint16_t file_id, 
                                        uint64_t sec, 
                                        int secs,
-                                       uint64_t *hnd);
+                                       share_tuple_t *hnd);
 extern void memshr_vbd_complete_ro_request(
-                                       uint64_t hnd,
+                                       share_tuple_t hnd,
                                        uint16_t file_id, 
                                        uint64_t sec, 
                                        int secs);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 23:16:23 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 23: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.xensource.com>)
	id 1RZ9fN-0002g1-RX; Fri, 09 Dec 2011 23:15:45 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RZ9fL-0002dt-S3
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 23:15:44 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-16.tower-21.messagelabs.com!1323472493!915189!1
X-Originating-IP: [208.97.132.83]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi44MyA9PiAxNTY3Mw==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12842 invoked from network); 9 Dec 2011 23:14:53 -0000
Received: from caiajhbdcaid.dreamhost.com (HELO homiemail-a76.g.dreamhost.com)
	(208.97.132.83) by server-16.tower-21.messagelabs.com with SMTP;
	9 Dec 2011 23:14:53 -0000
Received: from homiemail-a76.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTP id A7FB1458083;
	Fri,  9 Dec 2011 15:14:52 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=ebRBmvtCUVIIG6fsf5cP9bVzJZt32/NNMmJZPZ/b0ZzF
	3m/WxOxSDr01Lw3bZweTt7UxuGFRpYkq4YtLy75jiq/dD/7tSkDOSzDdirAzVFou
	tjzbV4vqZm2Y4f0bSwB2KrhtvDr7qRsE1W3J4EAGDIFGNGfgxnWO1LtL3nRb41g=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=zgdhK0YDc8FTVvomLClRIEHM8Sc=; b=WN2lk7pYRHV
	eEyQAUgyhlAz5H800tJUU7/3FVrINFvwGF2mfLcWhaFchuGqzsmVXNMS/2V/J9Nu
	7yR4tE6OwmDt865wA6v+52C1LFzFBplcH+ybuVIp4abXfkrYY6/jGenZJiWYbM0w
	tToQGnFr8U9IAQGpiELCYgmhGp2IlYV8=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTPSA id C4BE1458081; 
	Fri,  9 Dec 2011 15:14:51 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 3fc7875c8d98cbc74598001d721c79f9bd32299d
Message-Id: <3fc7875c8d98cbc74598.1323472556@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1323472550@xdev.gridcentric.ca>
References: <patchbomb.1323472550@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Fri, 09 Dec 2011 18:15:56 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com, andres@gridcentric.ca, tim@xen.org,
	ian.campbell@citrix.com, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 6 of 8] Tools: Allow libxl/xl to expose the
 total number of shared frames and space saved
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 tools/libxl/libxl.c      |  10 ++++++++++
 tools/libxl/libxl.h      |   3 +++
 tools/libxl/xl_cmdimpl.c |  12 +++++++++---
 3 files changed, 22 insertions(+), 3 deletions(-)


Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Signed-off-by: Adin Scannell <adin@scannell.ca>

diff -r 6e8b8fb2c8b2 -r 3fc7875c8d98 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -499,6 +499,16 @@ int libxl_domain_pause(libxl_ctx *ctx, u
     return 0;
 }
 
+long libxl_sharing_used_frames(libxl_ctx *ctx)
+{
+    return xc_sharing_used_frames(ctx->xch);
+}
+
+long libxl_sharing_freed_pages(libxl_ctx *ctx)
+{
+    return xc_sharing_freed_pages(ctx->xch);
+}
+
 int libxl_domain_core_dump(libxl_ctx *ctx, uint32_t domid,
                            const char *filename)
 {
diff -r 6e8b8fb2c8b2 -r 3fc7875c8d98 tools/libxl/libxl.h
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -350,6 +350,9 @@ int libxl_domain_rename(libxl_ctx *ctx, 
 int libxl_domain_pause(libxl_ctx *ctx, uint32_t domid);
 int libxl_domain_unpause(libxl_ctx *ctx, uint32_t domid);
 
+long libxl_sharing_used_frames(libxl_ctx *ctx);
+long libxl_sharing_freed_pages(libxl_ctx *ctx);
+
 int libxl_domain_core_dump(libxl_ctx *ctx, uint32_t domid, const char *filename);
 
 int libxl_domain_setmaxmem(libxl_ctx *ctx, uint32_t domid, uint32_t target_memkb);
diff -r 6e8b8fb2c8b2 -r 3fc7875c8d98 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -3758,6 +3758,7 @@ int main_info(int argc, char **argv)
 static void sharing(int totals, const libxl_dominfo *info, int nb_domain)
 {
     int i;
+    const libxl_version_info *vinfo;
 
     printf("Name                                        ID   Mem Shared\n");
 
@@ -3774,9 +3775,14 @@ static void sharing(int totals, const li
         free(domname);
     }
 
-    if (totals)
-    {
-        /* To be added with a future patch. */
+    if (totals) {
+        vinfo = libxl_get_version_info(ctx);
+        if (vinfo) {
+            i = (1 << 20) / vinfo->pagesize;
+            printf("Freed with sharing: %ld  Total physical shared: %ld\n", 
+            libxl_sharing_freed_pages(ctx) / i,
+            libxl_sharing_used_frames(ctx) / i);
+        }
     }
 }
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 23:16:23 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 23: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.xensource.com>)
	id 1RZ9fP-0002hF-Lx; Fri, 09 Dec 2011 23:15:47 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RZ9fM-0002e2-Ou
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 23:15:45 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-15.tower-182.messagelabs.com!1323472493!6572784!1
X-Originating-IP: [208.97.132.145]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNDUgPT4gMTcyMjQ=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 502 invoked from network); 9 Dec 2011 23:14:54 -0000
Received: from caiajhbdcbef.dreamhost.com (HELO homiemail-a76.g.dreamhost.com)
	(208.97.132.145) by server-15.tower-182.messagelabs.com with SMTP;
	9 Dec 2011 23:14:54 -0000
Received: from homiemail-a76.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTP id 8F60A458081;
	Fri,  9 Dec 2011 15:14:53 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=YEss3tSa0QluQFWY8hR90gHbCe3y6DtGM7HkTumVtDRz
	u84dPafripGv455hNZWm70Aj+iJdPghqI+Sf+u0HrIYTxe/KwEYmchYocVd4GVO+
	rBFhe2i9GBzSuIjQa97RsNseuSYbR+mxxAoO9pT46Ziz7Z19ofp538gei6hA7G0=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=Pko7KFgCM+/jQtejzAsFmipqCTo=; b=PQ5QiUzkVPK
	aimq2+4do4+QvH+wraH1/UOg1sbuFErUoON6pcj6uNEvUOe2H6iFdGXNf+xMEumM
	IAYWXlsCLiHVTkQ5M88aTYr0aQBVwkqIZ3eg96dkd47iE8S9eHbpkwAnNi9T5zxI
	Ja0X1u90xzFx8LO8Kt0QavVuc9w9rQXI=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTPSA id D6194458080; 
	Fri,  9 Dec 2011 15:14:52 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 33935769e2577e85d24a91f5ee3b8e8cad719fe2
Message-Id: <33935769e2577e85d24a.1323472557@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1323472550@xdev.gridcentric.ca>
References: <patchbomb.1323472550@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Fri, 09 Dec 2011 18:15:57 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com, andres@gridcentric.ca, tim@xen.org,
	ian.campbell@citrix.com, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 7 of 8] Tools: Libxc wrappers to add shared
	pages to physmap
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 tools/libxc/xc_memshr.c |  23 +++++++++++++++++++++++
 tools/libxc/xenctrl.h   |   6 ++++++
 2 files changed, 29 insertions(+), 0 deletions(-)


Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 3fc7875c8d98 -r 33935769e257 tools/libxc/xc_memshr.c
--- a/tools/libxc/xc_memshr.c
+++ b/tools/libxc/xc_memshr.c
@@ -86,6 +86,29 @@ int xc_memshr_nominate_gref(xc_interface
     return ret;
 }
 
+int xc_memshr_add_to_physmap(xc_interface *xch,
+                    uint32_t source_domain,
+                    uint64_t source_gfn,
+                    uint64_t source_handle,
+                    uint32_t client_domain,
+                    uint64_t client_gfn)
+{
+    DECLARE_DOMCTL;
+    struct xen_domctl_mem_sharing_op *op;
+
+    domctl.cmd                  = XEN_DOMCTL_mem_sharing_op;
+    domctl.interface_version    = XEN_DOMCTL_INTERFACE_VERSION;
+    domctl.domain               = (domid_t) source_domain;
+    op = &(domctl.u.mem_sharing_op);
+    op->op = XEN_DOMCTL_MEM_EVENT_OP_SHARING_ADD_PHYSMAP;
+    op->u.share.source_gfn      = source_gfn;
+    op->u.share.source_handle   = source_handle;
+    op->u.share.client_gfn      = client_gfn;
+    op->u.share.client_domain   = (uint64_t) client_domain;
+
+    return do_domctl(xch, &domctl);
+}
+
 int xc_memshr_share(xc_interface *xch,
                     uint32_t source_domain,
                     uint64_t source_gfn,
diff -r 3fc7875c8d98 -r 33935769e257 tools/libxc/xenctrl.h
--- a/tools/libxc/xenctrl.h
+++ b/tools/libxc/xenctrl.h
@@ -1895,6 +1895,12 @@ int xc_memshr_nominate_gref(xc_interface
                             uint32_t domid,
                             grant_ref_t gref,
                             uint64_t *handle);
+int xc_memshr_add_to_physmap(xc_interface *xch,
+                    uint32_t source_domain,
+                    uint64_t source_gfn,
+                    uint64_t source_handle,
+                    uint32_t client_domain,
+                    uint64_t client_gfn);
 int xc_memshr_share(xc_interface *xch,
                     uint32_t source_domain,
                     uint64_t source_gfn,

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 23:16:23 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 23: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.xensource.com>)
	id 1RZ9fJ-0002eW-Id; Fri, 09 Dec 2011 23:15:41 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RZ9fI-0002dc-DN
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 23:15:40 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-10.tower-216.messagelabs.com!1323472489!6769216!1
X-Originating-IP: [208.97.132.145]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNDUgPT4gMTczNjI=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30456 invoked from network); 9 Dec 2011 23:14:50 -0000
Received: from caiajhbdcbef.dreamhost.com (HELO homiemail-a76.g.dreamhost.com)
	(208.97.132.145) by server-10.tower-216.messagelabs.com with SMTP;
	9 Dec 2011 23:14:50 -0000
Received: from homiemail-a76.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTP id 8FB50458080;
	Fri,  9 Dec 2011 15:14:49 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=GxgHf0fEXWcFQlJaYeJDVXigey6++YUCkAcvHgJ8ohZo
	4xjx7hs29dpIctHP83zSAzL3eVmd9F1BW/MDF3zfWLZDQUInZBeESX3A04jRjnAg
	Mt92VBXJg3M6q01l5TOzC2+IsJXKHn6WkiUg1+FI08W80EZPW6Xl+zdvRIEfNt8=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=4aX5tLQJVHtR5FJCOInWnM+sraQ=; b=PArlvsVAGv2
	2ZFyWd8G81k2ORHVQJV+L0Ll4II5NuuGdxNFy1Z370HUtyfkBO+2RreujGmV96fF
	yj5AJDHEA5JRa5zF9x2Pyy5sOWWf1eQqTc9XfShR/7RY9RuKYMIvOeFpjl7FbHBI
	1wt7XCAluMo1kNDGUSqZ/0H/gW1SzGiY=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTPSA id A4975458083; 
	Fri,  9 Dec 2011 15:14:48 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: e16f5d2643c910d9b8c1dfe967db94a121636bdd
Message-Id: <e16f5d2643c910d9b8c1.1323472553@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1323472550@xdev.gridcentric.ca>
References: <patchbomb.1323472550@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Fri, 09 Dec 2011 18:15:53 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com, andres@gridcentric.ca, tim@xen.org,
	ian.campbell@citrix.com, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 3 of 8] Tools: Update memshr tool to use new
	sharing API
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 tools/blktap2/drivers/Makefile        |   2 +-
 tools/blktap2/drivers/tapdisk-image.c |   2 +-
 tools/blktap2/drivers/tapdisk-vbd.c   |   6 +++---
 tools/blktap2/drivers/tapdisk.h       |   6 +++++-
 tools/memshr/bidir-daemon.c           |  34 ++++++++++++++++++++++++----------
 tools/memshr/bidir-hash.h             |  13 ++++++++-----
 tools/memshr/interface.c              |  30 ++++++++++++++++++------------
 tools/memshr/memshr.h                 |  11 +++++++++--
 8 files changed, 69 insertions(+), 35 deletions(-)


The only (in-tree, that we know of) consumer of the mem sharing API
is the memshr tool (conditionally linked into blktap2). Update it to
use the new API.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 892049dfc1c9 -r e16f5d2643c9 tools/blktap2/drivers/Makefile
--- a/tools/blktap2/drivers/Makefile
+++ b/tools/blktap2/drivers/Makefile
@@ -43,7 +43,7 @@ MEMSHR_DIR = $(XEN_ROOT)/tools/memshr
 MEMSHRLIBS :=
 ifeq ($(CONFIG_Linux), __fixme__)
 CFLAGS += -DMEMSHR
-MEMSHRLIBS += $(MEMSHR_DIR)/libmemshr.a
+MEMSHRLIBS += -L$(XEN_ROOT)/tools/libxc -lxenctrl $(MEMSHR_DIR)/libmemshr.a
 endif
 
 ifeq ($(VHD_STATIC),y)
diff -r 892049dfc1c9 -r e16f5d2643c9 tools/blktap2/drivers/tapdisk-image.c
--- a/tools/blktap2/drivers/tapdisk-image.c
+++ b/tools/blktap2/drivers/tapdisk-image.c
@@ -60,7 +60,7 @@ tapdisk_image_allocate(const char *file,
 	image->storage   = storage;
 	image->private   = private;
 #ifdef MEMSHR
-	image->memshr_id = memshr_vbd_image_get(file);
+	image->memshr_id = memshr_vbd_image_get((char *)file);
 #endif
 	INIT_LIST_HEAD(&image->next);
 
diff -r 892049dfc1c9 -r e16f5d2643c9 tools/blktap2/drivers/tapdisk-vbd.c
--- a/tools/blktap2/drivers/tapdisk-vbd.c
+++ b/tools/blktap2/drivers/tapdisk-vbd.c
@@ -1218,14 +1218,14 @@ __tapdisk_vbd_complete_td_request(td_vbd
 #ifdef MEMSHR
 		if (treq.op == TD_OP_READ
 		   && td_flag_test(image->flags, TD_OPEN_RDONLY)) {
-			uint64_t hnd  = treq.memshr_hnd;
+			share_tuple_t hnd = treq.memshr_hnd;
 			uint16_t uid  = image->memshr_id;
 			blkif_request_t *breq = &vreq->req;
 			uint64_t sec  = tapdisk_vbd_breq_get_sector(breq, treq);
 			int secs = breq->seg[treq.sidx].last_sect -
 			    breq->seg[treq.sidx].first_sect + 1;
 
-			if (hnd != 0)
+			if (hnd.handle != 0)
 				memshr_vbd_complete_ro_request(hnd, uid,
 								sec, secs);
 		}
@@ -1297,7 +1297,7 @@ __tapdisk_vbd_reissue_td_request(td_vbd_
 				/* Reset memshr handle. This'll prevent
 				 * memshr_vbd_complete_ro_request being called
 				 */
-				treq.memshr_hnd = 0;
+				treq.memshr_hnd.handle = 0;
 				td_complete_request(treq, 0);
 			} else
 				td_queue_read(parent, treq);
diff -r 892049dfc1c9 -r e16f5d2643c9 tools/blktap2/drivers/tapdisk.h
--- a/tools/blktap2/drivers/tapdisk.h
+++ b/tools/blktap2/drivers/tapdisk.h
@@ -64,6 +64,10 @@
 #include "tapdisk-log.h"
 #include "tapdisk-utils.h"
 
+#ifdef MEMSHR
+#include "memshr.h"
+#endif
+
 #define DPRINTF(_f, _a...)           syslog(LOG_INFO, _f, ##_a)
 #define EPRINTF(_f, _a...)           syslog(LOG_ERR, "tap-err:%s: " _f, __func__, ##_a)
 #define PERROR(_f, _a...)            EPRINTF(_f ": %s", ##_a, strerror(errno))
@@ -136,7 +140,7 @@ struct td_request {
 	void                        *private;
     
 #ifdef MEMSHR
-	uint64_t                     memshr_hnd;
+	share_tuple_t                memshr_hnd;
 #endif
 };
 
diff -r 892049dfc1c9 -r e16f5d2643c9 tools/memshr/bidir-daemon.c
--- a/tools/memshr/bidir-daemon.c
+++ b/tools/memshr/bidir-daemon.c
@@ -19,16 +19,25 @@
 #include <pthread.h>
 #include <inttypes.h>
 #include <unistd.h>
+#include <errno.h>
 
 #include "bidir-hash.h"
 #include "memshr-priv.h"
 
 static struct blockshr_hash *blks_hash;
 
+/* Callback in the iterator, remember this value, and leave */
+int find_one(vbdblk_t k, share_tuple_t v, void *priv)
+{
+    share_tuple_t *rv = (share_tuple_t *) priv;
+    *rv = v;
+    /* Break out of iterator loop */
+    return 1;
+}
+
 void* bidir_daemon(void *unused)
 {
     uint32_t nr_ent, max_nr_ent, tab_size, max_load, min_load;
-    static uint64_t shrhnd = 1;
 
     while(1)
     {
@@ -41,20 +50,30 @@ void* bidir_daemon(void *unused)
         /* Remove some hints as soon as we get to 90% capacity */ 
         if(10 * nr_ent > 9 * max_nr_ent)
         {
-            uint64_t next_remove = shrhnd;
+            share_tuple_t next_remove;
             int to_remove;
             int ret;
 
             to_remove = 0.1 * max_nr_ent; 
             while(to_remove > 0) 
             {
-                ret = blockshr_shrhnd_remove(blks_hash, next_remove, NULL);
-                if(ret < 0)
+                /* We use the iterator to get one entry */
+                next_remove.handle = 0;
+                ret = blockshr_hash_iterator(blks_hash, find_one, &next_remove);
+
+                if ( !ret )
+                    if ( next_remove.handle == 0 )
+                        ret = -ESRCH;
+
+                if ( !ret )
+                    ret = blockshr_shrhnd_remove(blks_hash, next_remove, NULL);
+
+                if(ret <= 0)
                 {
                     /* We failed to remove an entry, because of a serious hash
                      * table error */
                     DPRINTF("Could not remove handle %"PRId64", error: %d\n",
-                            next_remove, ret);
+                            next_remove.handle, ret);
                     /* Force to exit the loop early */
                     to_remove = 0;
                 } else 
@@ -62,12 +81,7 @@ void* bidir_daemon(void *unused)
                 {
                     /* Managed to remove the entry. Note next_remove not
                      * incremented, in case there are duplicates */
-                    shrhnd = next_remove;
                     to_remove--;
-                } else
-                {
-                    /* Failed to remove, because there is no such handle */
-                    next_remove++;
                 }
             }
         }
diff -r 892049dfc1c9 -r e16f5d2643c9 tools/memshr/bidir-hash.h
--- a/tools/memshr/bidir-hash.h
+++ b/tools/memshr/bidir-hash.h
@@ -81,15 +81,16 @@ static int fgprtshr_mfn_cmp(uint32_t m1,
 #undef BIDIR_VALUE
 #undef BIDIR_KEY_T
 #undef BIDIR_VALUE_T
+
 /* TODO better hashes! */
 static inline uint32_t blockshr_block_hash(vbdblk_t block)
 {
     return (uint32_t)(block.sec) ^ (uint32_t)(block.disk_id);
 }
 
-static inline uint32_t blockshr_shrhnd_hash(uint64_t shrhnd)
+static inline uint32_t blockshr_shrhnd_hash(share_tuple_t shrhnd)
 {
-    return (uint32_t)shrhnd;
+    return ((uint32_t) shrhnd.handle);
 }
 
 static inline int blockshr_block_cmp(vbdblk_t b1, vbdblk_t b2)
@@ -97,15 +98,17 @@ static inline int blockshr_block_cmp(vbd
     return (b1.sec == b2.sec) && (b1.disk_id == b2.disk_id);
 }
 
-static inline int blockshr_shrhnd_cmp(uint64_t h1, uint64_t h2)
+static inline int blockshr_shrhnd_cmp(share_tuple_t h1, share_tuple_t h2)
 {
-    return (h1 == h2);
+    return ( (h1.domain == h2.domain) &&
+             (h1.frame  == h2.frame) &&
+             (h1.handle == h2.handle) );
 }
 #define BIDIR_NAME_PREFIX       blockshr
 #define BIDIR_KEY               block
 #define BIDIR_VALUE             shrhnd
 #define BIDIR_KEY_T             vbdblk_t
-#define BIDIR_VALUE_T           uint64_t
+#define BIDIR_VALUE_T           share_tuple_t
 #include "bidir-namedefs.h"
 
 #endif /* BLOCK_MAP */
diff -r 892049dfc1c9 -r e16f5d2643c9 tools/memshr/interface.c
--- a/tools/memshr/interface.c
+++ b/tools/memshr/interface.c
@@ -145,16 +145,17 @@ void memshr_vbd_image_put(uint16_t memsh
     
 int memshr_vbd_issue_ro_request(char *buf,
                                 grant_ref_t gref,
-                                uint16_t file_id, 
+                                uint16_t file_id,
                                 uint64_t sec, 
                                 int secs,
-                                uint64_t *hnd)
+                                share_tuple_t *hnd)
 {
     vbdblk_t blk;
-    uint64_t s_hnd, c_hnd;
+    share_tuple_t source_st, client_st;
+    uint64_t c_hnd;
     int ret;
 
-    *hnd = 0;
+    *hnd = (share_tuple_t){ 0, 0, 0 };
     if(!vbd_info.enabled) 
         return -1;
 
@@ -169,26 +170,31 @@ int memshr_vbd_issue_ro_request(char *bu
     /* If page couldn't be made sharable, we cannot do anything about it */
     if(ret != 0)
         return -3;
-    *hnd = c_hnd;
+
+    *(&client_st) = (share_tuple_t){ vbd_info.domid, gref, c_hnd };
+    *hnd = client_st;
 
     /* Check if we've read matching disk block previously */
     blk.sec     = sec;
     blk.disk_id = file_id;
-    if(blockshr_block_lookup(memshr.blks, blk, &s_hnd) > 0)
+    if(blockshr_block_lookup(memshr.blks, blk, &source_st) > 0)
     {
-        ret = xc_memshr_share(vbd_info.xc_handle, s_hnd, c_hnd);
+        ret = xc_memshr_share(vbd_info.xc_handle, source_st.domain, source_st.frame, 
+                                source_st.handle, 1, vbd_info.domid, gref, c_hnd, 1);
         if(!ret) return 0;
         /* Handles failed to be shared => at least one of them must be invalid,
            remove the relevant ones from the map */
         switch(ret)
         {
             case XEN_DOMCTL_MEM_SHARING_S_HANDLE_INVALID:
-                ret = blockshr_shrhnd_remove(memshr.blks, s_hnd, NULL);
-                if(ret) DPRINTF("Could not rm invl s_hnd: %"PRId64"\n", s_hnd);
+                ret = blockshr_shrhnd_remove(memshr.blks, source_st, NULL);
+                if(ret) DPRINTF("Could not rm invl s_hnd: %u %"PRId64" %"PRId64"\n", 
+                                    source_st.domain, source_st.frame, source_st.handle);
                 break;
             case XEN_DOMCTL_MEM_SHARING_C_HANDLE_INVALID:
-                ret = blockshr_shrhnd_remove(memshr.blks, c_hnd, NULL);
-                if(ret) DPRINTF("Could not rm invl c_hnd: %"PRId64"\n", c_hnd);
+                ret = blockshr_shrhnd_remove(memshr.blks, client_st, NULL);
+                if(ret) DPRINTF("Could not rm invl c_hnd: %u %"PRId64" %"PRId64"\n", 
+                                    client_st.domain, client_st.frame, client_st.handle);
                 break;
             default:
                 break;
@@ -199,7 +205,7 @@ int memshr_vbd_issue_ro_request(char *bu
     return -4;
 }
 
-void memshr_vbd_complete_ro_request(uint64_t hnd,
+void memshr_vbd_complete_ro_request(share_tuple_t hnd,
                                     uint16_t file_id, 
                                     uint64_t sec, 
                                     int secs)
diff -r 892049dfc1c9 -r e16f5d2643c9 tools/memshr/memshr.h
--- a/tools/memshr/memshr.h
+++ b/tools/memshr/memshr.h
@@ -25,6 +25,13 @@
 
 typedef uint64_t xen_mfn_t;
 
+typedef struct share_tuple 
+{
+    uint32_t domain;
+    uint64_t frame;
+    uint64_t handle;
+} share_tuple_t;
+
 extern void memshr_set_domid(int domid);
 extern void memshr_daemon_initialize(void);
 extern void memshr_vbd_initialize(void);
@@ -35,9 +42,9 @@ extern int memshr_vbd_issue_ro_request(c
                                        uint16_t file_id, 
                                        uint64_t sec, 
                                        int secs,
-                                       uint64_t *hnd);
+                                       share_tuple_t *hnd);
 extern void memshr_vbd_complete_ro_request(
-                                       uint64_t hnd,
+                                       share_tuple_t hnd,
                                        uint16_t file_id, 
                                        uint64_t sec, 
                                        int secs);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 23:16:23 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 23: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.xensource.com>)
	id 1RZ9fP-0002gz-94; Fri, 09 Dec 2011 23:15:47 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RZ9fN-0002eE-HP
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 23:15:45 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-10.tower-182.messagelabs.com!1323472495!6632717!1
X-Originating-IP: [208.97.132.177]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNzcgPT4gMTQ0MDg=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5003 invoked from network); 9 Dec 2011 23:14:55 -0000
Received: from caiajhbdcbhh.dreamhost.com (HELO homiemail-a76.g.dreamhost.com)
	(208.97.132.177) by server-10.tower-182.messagelabs.com with SMTP;
	9 Dec 2011 23:14:55 -0000
Received: from homiemail-a76.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTP id C2C48458083;
	Fri,  9 Dec 2011 15:14:54 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=PLPwXZLWgmTncRMAFtYgS7+NCjtPOrL+ZAoPRSr9HA4E
	7osbSB3uhvoO57E4lpqjdJfEkj3xI5ZHMIf9b8O4CUaLyDcAV4OLmPF4ietm/7Rx
	SSrni+G356+tnQt12yTiEL436VXXEq0PM1J3ZMYMaJp/kPqgK3ijGG4Ttq1I10g=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=iPOw/2UTqQhYdd9zkbB3i+EBXYU=; b=pKib9S2PuAl
	U4rZp5GGJEkVsuj10zvN7FPkqDy6DUKJZRlr1bIzw4jG+fQg+knxuthsDra+e2Hf
	+0VyDrxByYJEXxANsQmohTaGqCGCUr/X7euChvIrfn/Z1ugnUklfavI/UxM3mpMe
	Ro9k7y8kSTcT/I6rWkV2qjqJnbd4+7Ik=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTPSA id BDB26458080; 
	Fri,  9 Dec 2011 15:14:53 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 6514004012c70975ba3027116c37b4adcfcd8804
Message-Id: <6514004012c70975ba30.1323472558@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1323472550@xdev.gridcentric.ca>
References: <patchbomb.1323472550@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Fri, 09 Dec 2011 18:15:58 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com, andres@gridcentric.ca, tim@xen.org,
	ian.campbell@citrix.com, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 8 of 8] Tools: Libxc wrapper for the new sharing
	audit domctl
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 tools/libxc/xc_memshr.c |  14 ++++++++++++++
 tools/libxc/xenctrl.h   |   2 ++
 2 files changed, 16 insertions(+), 0 deletions(-)


Signed-off-by: Adin Scannell <adin@scannell.ca>

diff -r 33935769e257 -r 6514004012c7 tools/libxc/xc_memshr.c
--- a/tools/libxc/xc_memshr.c
+++ b/tools/libxc/xc_memshr.c
@@ -211,3 +211,17 @@ int xc_memshr_debug_gref(xc_interface *x
     return do_domctl(xch, &domctl);
 }
 
+int xc_memshr_audit(xc_interface *xch,
+                    uint32_t domid)
+{
+    DECLARE_DOMCTL;
+    struct xen_domctl_mem_sharing_op *op;
+
+    domctl.cmd = XEN_DOMCTL_mem_sharing_op;
+    domctl.interface_version = XEN_DOMCTL_INTERFACE_VERSION;
+    domctl.domain = (domid_t)domid;
+    op = &(domctl.u.mem_sharing_op);
+    op->op = XEN_DOMCTL_MEM_EVENT_OP_SHARING_AUDIT;
+
+    return do_domctl(xch, &domctl);
+}
diff -r 33935769e257 -r 6514004012c7 tools/libxc/xenctrl.h
--- a/tools/libxc/xenctrl.h
+++ b/tools/libxc/xenctrl.h
@@ -1921,6 +1921,8 @@ int xc_memshr_debug_mfn(xc_interface *xc
 int xc_memshr_debug_gref(xc_interface *xch,
                          uint32_t domid,
                          grant_ref_t gref);
+int xc_memshr_audit(xc_interface *xch,
+                    uint32_t domid);
 
 int xc_flask_load(xc_interface *xc_handle, char *buf, uint32_t size);
 int xc_flask_context_to_sid(xc_interface *xc_handle, char *buf, uint32_t size, uint32_t *sid);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 23:16:23 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 23: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.xensource.com>)
	id 1RZ9fP-0002gz-94; Fri, 09 Dec 2011 23:15:47 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RZ9fN-0002eE-HP
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 23:15:45 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-10.tower-182.messagelabs.com!1323472495!6632717!1
X-Originating-IP: [208.97.132.177]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNzcgPT4gMTQ0MDg=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5003 invoked from network); 9 Dec 2011 23:14:55 -0000
Received: from caiajhbdcbhh.dreamhost.com (HELO homiemail-a76.g.dreamhost.com)
	(208.97.132.177) by server-10.tower-182.messagelabs.com with SMTP;
	9 Dec 2011 23:14:55 -0000
Received: from homiemail-a76.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTP id C2C48458083;
	Fri,  9 Dec 2011 15:14:54 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=PLPwXZLWgmTncRMAFtYgS7+NCjtPOrL+ZAoPRSr9HA4E
	7osbSB3uhvoO57E4lpqjdJfEkj3xI5ZHMIf9b8O4CUaLyDcAV4OLmPF4ietm/7Rx
	SSrni+G356+tnQt12yTiEL436VXXEq0PM1J3ZMYMaJp/kPqgK3ijGG4Ttq1I10g=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=iPOw/2UTqQhYdd9zkbB3i+EBXYU=; b=pKib9S2PuAl
	U4rZp5GGJEkVsuj10zvN7FPkqDy6DUKJZRlr1bIzw4jG+fQg+knxuthsDra+e2Hf
	+0VyDrxByYJEXxANsQmohTaGqCGCUr/X7euChvIrfn/Z1ugnUklfavI/UxM3mpMe
	Ro9k7y8kSTcT/I6rWkV2qjqJnbd4+7Ik=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTPSA id BDB26458080; 
	Fri,  9 Dec 2011 15:14:53 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 6514004012c70975ba3027116c37b4adcfcd8804
Message-Id: <6514004012c70975ba30.1323472558@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1323472550@xdev.gridcentric.ca>
References: <patchbomb.1323472550@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Fri, 09 Dec 2011 18:15:58 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com, andres@gridcentric.ca, tim@xen.org,
	ian.campbell@citrix.com, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 8 of 8] Tools: Libxc wrapper for the new sharing
	audit domctl
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 tools/libxc/xc_memshr.c |  14 ++++++++++++++
 tools/libxc/xenctrl.h   |   2 ++
 2 files changed, 16 insertions(+), 0 deletions(-)


Signed-off-by: Adin Scannell <adin@scannell.ca>

diff -r 33935769e257 -r 6514004012c7 tools/libxc/xc_memshr.c
--- a/tools/libxc/xc_memshr.c
+++ b/tools/libxc/xc_memshr.c
@@ -211,3 +211,17 @@ int xc_memshr_debug_gref(xc_interface *x
     return do_domctl(xch, &domctl);
 }
 
+int xc_memshr_audit(xc_interface *xch,
+                    uint32_t domid)
+{
+    DECLARE_DOMCTL;
+    struct xen_domctl_mem_sharing_op *op;
+
+    domctl.cmd = XEN_DOMCTL_mem_sharing_op;
+    domctl.interface_version = XEN_DOMCTL_INTERFACE_VERSION;
+    domctl.domain = (domid_t)domid;
+    op = &(domctl.u.mem_sharing_op);
+    op->op = XEN_DOMCTL_MEM_EVENT_OP_SHARING_AUDIT;
+
+    return do_domctl(xch, &domctl);
+}
diff -r 33935769e257 -r 6514004012c7 tools/libxc/xenctrl.h
--- a/tools/libxc/xenctrl.h
+++ b/tools/libxc/xenctrl.h
@@ -1921,6 +1921,8 @@ int xc_memshr_debug_mfn(xc_interface *xc
 int xc_memshr_debug_gref(xc_interface *xch,
                          uint32_t domid,
                          grant_ref_t gref);
+int xc_memshr_audit(xc_interface *xch,
+                    uint32_t domid);
 
 int xc_flask_load(xc_interface *xc_handle, char *buf, uint32_t size);
 int xc_flask_context_to_sid(xc_interface *xc_handle, char *buf, uint32_t size, uint32_t *sid);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 23:16:24 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 23:16:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZ9fL-0002fS-Ji; Fri, 09 Dec 2011 23:15:43 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RZ9fK-0002dp-0o
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 23:15:42 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-15.tower-174.messagelabs.com!1323472490!4778266!2
X-Originating-IP: [208.97.132.66]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi42NiA9PiAxNTY0OQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13393 invoked from network); 9 Dec 2011 23:14:51 -0000
Received: from caiajhbdcagg.dreamhost.com (HELO homiemail-a76.g.dreamhost.com)
	(208.97.132.66) by server-15.tower-174.messagelabs.com with SMTP;
	9 Dec 2011 23:14:51 -0000
Received: from homiemail-a76.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTP id 862F1458080;
	Fri,  9 Dec 2011 15:14:51 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=X2lzUcHAHtr7GYUipR2nV5GBiLlHDEIpzbGDL4HBykRB
	ZuTCf3GxRhBXE7n1qCzrO4b9fhLi9m3nb975RX6FdgjbxVhF4gQT1MXOpQOUpISs
	l0e0orniWAObRO9HrjCdmWr+h2QAad/xNrYFjeGu8xi5qKToOT5ZO7jyTCh2z7E=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=nOzWCzKEAhWy4+uOMXCQhcXjYk8=; b=pDioCK4FJp6
	db2TOGxtR8aNAUC07eXKMFIL2PSwLeHCkyBobG0gl1e9Uj5SkjCk3WPwVBWgxaNf
	zmBmJfbdRKfBnAOa7DmNyh68/460b0XF4fNKHx6/NnaaMooCgciiOtSCxfHhm+fF
	lIERDB8Idh8E6GrpssQ1fRgTsQFcU0hY=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTPSA id BA7B0458081; 
	Fri,  9 Dec 2011 15:14:50 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 6e8b8fb2c8b23e39d9103d0e4b52a81dc7216aa1
Message-Id: <6e8b8fb2c8b23e39d910.1323472555@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1323472550@xdev.gridcentric.ca>
References: <patchbomb.1323472550@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Fri, 09 Dec 2011 18:15:55 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com, andres@gridcentric.ca, tim@xen.org,
	ian.campbell@citrix.com, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 5 of 8] Tools: Expose to libxc the total number
 of shared frames and space saved
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 tools/libxc/xc_private.c |  10 ++++++++++
 tools/libxc/xenctrl.h    |   4 ++++
 2 files changed, 14 insertions(+), 0 deletions(-)


Signed-off-by: Adin Scannell <adin@scannell.ca>

diff -r a22140d92931 -r 6e8b8fb2c8b2 tools/libxc/xc_private.c
--- a/tools/libxc/xc_private.c
+++ b/tools/libxc/xc_private.c
@@ -533,6 +533,16 @@ long xc_maximum_ram_page(xc_interface *x
     return do_memory_op(xch, XENMEM_maximum_ram_page, NULL, 0);
 }
 
+long xc_sharing_freed_pages(xc_interface *xch)
+{
+    return do_memory_op(xch, XENMEM_get_sharing_freed_pages, NULL, 0);
+}
+
+long xc_sharing_used_frames(xc_interface *xch)
+{
+    return do_memory_op(xch, XENMEM_get_sharing_shared_pages, NULL, 0);
+}
+
 long long xc_domain_get_cpu_usage( xc_interface *xch, domid_t domid, int vcpu )
 {
     DECLARE_DOMCTL;
diff -r a22140d92931 -r 6e8b8fb2c8b2 tools/libxc/xenctrl.h
--- a/tools/libxc/xenctrl.h
+++ b/tools/libxc/xenctrl.h
@@ -1227,6 +1227,10 @@ int xc_mmuext_op(xc_interface *xch, stru
 /* System wide memory properties */
 long xc_maximum_ram_page(xc_interface *xch);
 
+long xc_sharing_freed_pages(xc_interface *xch);
+
+long xc_sharing_used_frames(xc_interface *xch);
+
 /* Get current total pages allocated to a domain. */
 long xc_get_tot_pages(xc_interface *xch, uint32_t domid);
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 09 23:16:24 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 Dec 2011 23:16:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZ9fL-0002fS-Ji; Fri, 09 Dec 2011 23:15:43 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RZ9fK-0002dp-0o
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 23:15:42 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-15.tower-174.messagelabs.com!1323472490!4778266!2
X-Originating-IP: [208.97.132.66]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi42NiA9PiAxNTY0OQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13393 invoked from network); 9 Dec 2011 23:14:51 -0000
Received: from caiajhbdcagg.dreamhost.com (HELO homiemail-a76.g.dreamhost.com)
	(208.97.132.66) by server-15.tower-174.messagelabs.com with SMTP;
	9 Dec 2011 23:14:51 -0000
Received: from homiemail-a76.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTP id 862F1458080;
	Fri,  9 Dec 2011 15:14:51 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=X2lzUcHAHtr7GYUipR2nV5GBiLlHDEIpzbGDL4HBykRB
	ZuTCf3GxRhBXE7n1qCzrO4b9fhLi9m3nb975RX6FdgjbxVhF4gQT1MXOpQOUpISs
	l0e0orniWAObRO9HrjCdmWr+h2QAad/xNrYFjeGu8xi5qKToOT5ZO7jyTCh2z7E=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=nOzWCzKEAhWy4+uOMXCQhcXjYk8=; b=pDioCK4FJp6
	db2TOGxtR8aNAUC07eXKMFIL2PSwLeHCkyBobG0gl1e9Uj5SkjCk3WPwVBWgxaNf
	zmBmJfbdRKfBnAOa7DmNyh68/460b0XF4fNKHx6/NnaaMooCgciiOtSCxfHhm+fF
	lIERDB8Idh8E6GrpssQ1fRgTsQFcU0hY=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTPSA id BA7B0458081; 
	Fri,  9 Dec 2011 15:14:50 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 6e8b8fb2c8b23e39d9103d0e4b52a81dc7216aa1
Message-Id: <6e8b8fb2c8b23e39d910.1323472555@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1323472550@xdev.gridcentric.ca>
References: <patchbomb.1323472550@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Fri, 09 Dec 2011 18:15:55 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com, andres@gridcentric.ca, tim@xen.org,
	ian.campbell@citrix.com, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 5 of 8] Tools: Expose to libxc the total number
 of shared frames and space saved
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 tools/libxc/xc_private.c |  10 ++++++++++
 tools/libxc/xenctrl.h    |   4 ++++
 2 files changed, 14 insertions(+), 0 deletions(-)


Signed-off-by: Adin Scannell <adin@scannell.ca>

diff -r a22140d92931 -r 6e8b8fb2c8b2 tools/libxc/xc_private.c
--- a/tools/libxc/xc_private.c
+++ b/tools/libxc/xc_private.c
@@ -533,6 +533,16 @@ long xc_maximum_ram_page(xc_interface *x
     return do_memory_op(xch, XENMEM_maximum_ram_page, NULL, 0);
 }
 
+long xc_sharing_freed_pages(xc_interface *xch)
+{
+    return do_memory_op(xch, XENMEM_get_sharing_freed_pages, NULL, 0);
+}
+
+long xc_sharing_used_frames(xc_interface *xch)
+{
+    return do_memory_op(xch, XENMEM_get_sharing_shared_pages, NULL, 0);
+}
+
 long long xc_domain_get_cpu_usage( xc_interface *xch, domid_t domid, int vcpu )
 {
     DECLARE_DOMCTL;
diff -r a22140d92931 -r 6e8b8fb2c8b2 tools/libxc/xenctrl.h
--- a/tools/libxc/xenctrl.h
+++ b/tools/libxc/xenctrl.h
@@ -1227,6 +1227,10 @@ int xc_mmuext_op(xc_interface *xch, stru
 /* System wide memory properties */
 long xc_maximum_ram_page(xc_interface *xch);
 
+long xc_sharing_freed_pages(xc_interface *xch);
+
+long xc_sharing_used_frames(xc_interface *xch);
+
 /* Get current total pages allocated to a domain. */
 long xc_get_tot_pages(xc_interface *xch, uint32_t domid);
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Dec 10 00:28:11 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 10 Dec 2011 00: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.xensource.com>)
	id 1RZAmw-0005FW-7Y; Sat, 10 Dec 2011 00:27:38 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <davem@davemloft.net>) id 1RZAmu-0005FP-G0
	for xen-devel@lists.xensource.com; Sat, 10 Dec 2011 00:27:36 +0000
X-Env-Sender: davem@davemloft.net
X-Msg-Ref: server-15.tower-27.messagelabs.com!1323476792!58355490!1
X-Originating-IP: [198.137.202.13]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14210 invoked from network); 10 Dec 2011 00:26:33 -0000
Received: from shards.monkeyblade.net (HELO shards.monkeyblade.net)
	(198.137.202.13)
	by server-15.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 10 Dec 2011 00:26:33 -0000
Received: from localhost (cpe-66-65-61-233.nyc.res.rr.com [66.65.61.233])
	(authenticated bits=0)
	by shards.monkeyblade.net (8.14.4/8.14.4) with ESMTP id pBA0OdUQ007953
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO);
	Fri, 9 Dec 2011 16:24:40 -0800
Date: Fri, 09 Dec 2011 19:24:39 -0500 (EST)
Message-Id: <20111209.192439.275865894437319638.davem@davemloft.net>
To: Ian.Campbell@citrix.com
From: David Miller <davem@davemloft.net>
In-Reply-To: <1323465781.20936.49.camel@dagon.hellion.org.uk>
References: <1323430738-3798-1-git-send-email-lersek@redhat.com>
	<20111209.134514.2071890208094978847.davem@davemloft.net>
	<1323465781.20936.49.camel@dagon.hellion.org.uk>
X-Mailer: Mew version 6.4 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6
	(shards.monkeyblade.net [198.137.202.13]);
	Fri, 09 Dec 2011 16:24:42 -0800 (PST)
Cc: jeremy@goop.org, xen-devel@lists.xensource.com, konrad.wilk@oracle.com,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
	virtualization@lists.linux-foundation.org, lersek@redhat.com
Subject: Re: [Xen-devel] [PATCH v3 REPOST] xen-netfront: delay gARP until
 backend switches to Connected
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Ian Campbell <Ian.Campbell@citrix.com>
Date: Fri, 9 Dec 2011 21:23:00 +0000

> On Fri, 2011-12-09 at 18:45 +0000, David Miller wrote:
>> From: Laszlo Ersek <lersek@redhat.com>
>> Date: Fri,  9 Dec 2011 12:38:58 +0100
>> 
>> > These two together provide complete ordering. Sub-condition (1) is
>> > satisfied by pvops commit 43223efd9bfd.
>> 
>> I don't see this commit in Linus's tree,
> 
> The referenced commit is in
> git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git#xen/next-2.6.32  some people call the "pvops tree" but there's no reason to expect someone outside the Xen world to know that...
> 
> A better reference would have been 6b0b80ca7165 in
> git://xenbits.xen.org/people/ianc/linux-2.6.git#upstream/dom0/backend/netback-history which is the precise branch that was flattened to make f942dc2552b8, which is the upstream commit that added netback, so this change is already in upstream.

I want the commit message fixed so someone seeing the commit ID can
figure out what it actually refers to.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Dec 10 00:28:11 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 10 Dec 2011 00: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.xensource.com>)
	id 1RZAmw-0005FW-7Y; Sat, 10 Dec 2011 00:27:38 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <davem@davemloft.net>) id 1RZAmu-0005FP-G0
	for xen-devel@lists.xensource.com; Sat, 10 Dec 2011 00:27:36 +0000
X-Env-Sender: davem@davemloft.net
X-Msg-Ref: server-15.tower-27.messagelabs.com!1323476792!58355490!1
X-Originating-IP: [198.137.202.13]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14210 invoked from network); 10 Dec 2011 00:26:33 -0000
Received: from shards.monkeyblade.net (HELO shards.monkeyblade.net)
	(198.137.202.13)
	by server-15.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 10 Dec 2011 00:26:33 -0000
Received: from localhost (cpe-66-65-61-233.nyc.res.rr.com [66.65.61.233])
	(authenticated bits=0)
	by shards.monkeyblade.net (8.14.4/8.14.4) with ESMTP id pBA0OdUQ007953
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO);
	Fri, 9 Dec 2011 16:24:40 -0800
Date: Fri, 09 Dec 2011 19:24:39 -0500 (EST)
Message-Id: <20111209.192439.275865894437319638.davem@davemloft.net>
To: Ian.Campbell@citrix.com
From: David Miller <davem@davemloft.net>
In-Reply-To: <1323465781.20936.49.camel@dagon.hellion.org.uk>
References: <1323430738-3798-1-git-send-email-lersek@redhat.com>
	<20111209.134514.2071890208094978847.davem@davemloft.net>
	<1323465781.20936.49.camel@dagon.hellion.org.uk>
X-Mailer: Mew version 6.4 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6
	(shards.monkeyblade.net [198.137.202.13]);
	Fri, 09 Dec 2011 16:24:42 -0800 (PST)
Cc: jeremy@goop.org, xen-devel@lists.xensource.com, konrad.wilk@oracle.com,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
	virtualization@lists.linux-foundation.org, lersek@redhat.com
Subject: Re: [Xen-devel] [PATCH v3 REPOST] xen-netfront: delay gARP until
 backend switches to Connected
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Ian Campbell <Ian.Campbell@citrix.com>
Date: Fri, 9 Dec 2011 21:23:00 +0000

> On Fri, 2011-12-09 at 18:45 +0000, David Miller wrote:
>> From: Laszlo Ersek <lersek@redhat.com>
>> Date: Fri,  9 Dec 2011 12:38:58 +0100
>> 
>> > These two together provide complete ordering. Sub-condition (1) is
>> > satisfied by pvops commit 43223efd9bfd.
>> 
>> I don't see this commit in Linus's tree,
> 
> The referenced commit is in
> git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git#xen/next-2.6.32  some people call the "pvops tree" but there's no reason to expect someone outside the Xen world to know that...
> 
> A better reference would have been 6b0b80ca7165 in
> git://xenbits.xen.org/people/ianc/linux-2.6.git#upstream/dom0/backend/netback-history which is the precise branch that was flattened to make f942dc2552b8, which is the upstream commit that added netback, so this change is already in upstream.

I want the commit message fixed so someone seeing the commit ID can
figure out what it actually refers to.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Dec 10 01:53:31 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 10 Dec 2011 01: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.xensource.com>)
	id 1RZC7V-0002TZ-5E; Sat, 10 Dec 2011 01:52:57 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mukesh.rathor@oracle.com>) id 1RZC7T-0002TU-R2
	for Xen-devel@lists.xensource.com; Sat, 10 Dec 2011 01:52:56 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1323481924!6640317!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDI4OTkx\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23089 invoked from network); 10 Dec 2011 01:52:05 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-2.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 10 Dec 2011 01:52:05 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pBA1pwtk005516
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sat, 10 Dec 2011 01:51:58 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pBA1pvDm015496
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Sat, 10 Dec 2011 01:51:57 GMT
Received: from abhmt109.oracle.com (abhmt109.oracle.com [141.146.116.61])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pBA1ppjx010884; Fri, 9 Dec 2011 19:51:51 -0600
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 09 Dec 2011 17:51:51 -0800
Date: Fri, 9 Dec 2011 17:51:49 -0800
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>, Ian
	Campbell <Ian.Campbell@citrix.com>
Message-ID: <20111209175149.1e50bae0@mantra.us.oracle.com>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090204.4EE2BB3F.0052,ss=1,re=0.000,fgs=0
Subject: [Xen-devel] HYBRID: SMP without HAP (PV MMU)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi,

I have hybrid smp running with autoxlate. However, without autoxlate, I am
running into issues realted to TLB flush.  The guest in this case makes
multicalls as part of which cache is flushed (__do_update_va_mapping,
etc..). However, the guest is using VPIDs and it is getting complicated.
I can just xen not do any TLB management and let the guest just do it
after return from the hypercall. That would be simpler than hacking xen
further to put in hooks for hybrid. However, before doing that, I am wondering
if there is even a usecase for hybrid without HAP. The only case I can think
of is dom0. For backend grant frames mapping with autoxlate/HAP, it would
need to update the HAP for every frame, and don't know if that would be
a significant overhead. If not, then we don't really have a use case for
running hybrid autoxlate off, and no point in spending time on it.

Thanks for any input.
Mukesh


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Dec 10 01:53:31 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 10 Dec 2011 01: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.xensource.com>)
	id 1RZC7V-0002TZ-5E; Sat, 10 Dec 2011 01:52:57 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mukesh.rathor@oracle.com>) id 1RZC7T-0002TU-R2
	for Xen-devel@lists.xensource.com; Sat, 10 Dec 2011 01:52:56 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1323481924!6640317!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDI4OTkx\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23089 invoked from network); 10 Dec 2011 01:52:05 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-2.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 10 Dec 2011 01:52:05 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pBA1pwtk005516
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sat, 10 Dec 2011 01:51:58 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pBA1pvDm015496
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Sat, 10 Dec 2011 01:51:57 GMT
Received: from abhmt109.oracle.com (abhmt109.oracle.com [141.146.116.61])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pBA1ppjx010884; Fri, 9 Dec 2011 19:51:51 -0600
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 09 Dec 2011 17:51:51 -0800
Date: Fri, 9 Dec 2011 17:51:49 -0800
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>, Ian
	Campbell <Ian.Campbell@citrix.com>
Message-ID: <20111209175149.1e50bae0@mantra.us.oracle.com>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090204.4EE2BB3F.0052,ss=1,re=0.000,fgs=0
Subject: [Xen-devel] HYBRID: SMP without HAP (PV MMU)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi,

I have hybrid smp running with autoxlate. However, without autoxlate, I am
running into issues realted to TLB flush.  The guest in this case makes
multicalls as part of which cache is flushed (__do_update_va_mapping,
etc..). However, the guest is using VPIDs and it is getting complicated.
I can just xen not do any TLB management and let the guest just do it
after return from the hypercall. That would be simpler than hacking xen
further to put in hooks for hybrid. However, before doing that, I am wondering
if there is even a usecase for hybrid without HAP. The only case I can think
of is dom0. For backend grant frames mapping with autoxlate/HAP, it would
need to update the HAP for every frame, and don't know if that would be
a significant overhead. If not, then we don't really have a use case for
running hybrid autoxlate off, and no point in spending time on it.

Thanks for any input.
Mukesh


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Dec 10 03:10:53 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 10 Dec 2011 03:10:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZDKD-0003ZP-B6; Sat, 10 Dec 2011 03:10:09 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RZDKB-0003ZK-LH
	for xen-devel@lists.xensource.com; Sat, 10 Dec 2011 03:10:07 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1323486524!46141520!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDMwNg==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24300 invoked from network); 10 Dec 2011 03:08:44 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Dec 2011 03:08:44 -0000
X-IronPort-AV: E=Sophos;i="4.71,330,1320624000"; 
   d="scan'208";a="9395277"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Dec 2011 03:09:21 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sat, 10 Dec 2011 03:09:21 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RZDJR-0005M1-2c;
	Sat, 10 Dec 2011 03:09:21 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RZDJQ-0004yL-RS;
	Sat, 10 Dec 2011 03:09:20 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10470-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 10 Dec 2011 03:09:20 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10470: FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10470 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10470/

Failures and problems with tests :-(

Tests which did not succeed and are blocking:
 test-amd64-i386-rhel6hvm-intel  3 host-install(3)              broken in 10460
 test-i386-i386-pv             3 host-install(3)              broken   in 10460
 test-amd64-amd64-xl-sedf      3 host-install(3)              broken   in 10460

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-credit2    7 debian-install              fail pass in 10468
 test-amd64-amd64-xl-win       7 windows-install             fail pass in 10468
 test-amd64-i386-xl-win-vcpus1  7 windows-install            fail pass in 10460
 test-i386-i386-xl-win         7 windows-install    fail in 10468 pass in 10470
 test-amd64-i386-win-vcpus1    7 windows-install    fail in 10460 pass in 10470

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-i386-i386-xl-winxpsp3    7 windows-install              fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install          fail never pass
 test-amd64-i386-xl-win7-amd64  7 windows-install              fail  never pass
 test-amd64-i386-xend-winxpsp3  7 windows-install              fail  never pass
 test-amd64-amd64-xl-win7-amd64  7 windows-install              fail never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop            fail in 10468 never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop           fail in 10460 never pass

version targeted for testing:
 xen                  1c58bb664d8d
baseline version:
 xen                  62ff6a318c5d

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scanneel.ca>
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Andres Lagar-Cavilla <andres@lagarcavilla>
  Andrew Cooper <andrew.cooper3@citrix.com>
  Anthony PERARD <anthony.perard@citrix.com>
  Brendan Cully <brendan@cs.ubc.ca>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Haitao Shan <haitao.shan@intel.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@novell.com>
  Jan Beulich <jbeulich@suse.com>
  Jonathan Davies <jonathan.davies@citrix.com>
  juergen.gross@ts.fujitsu.com
  Keir Fraser <keir@xen.org>
  Liu, Jinsong <jinsong.liu@intel.com>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
  Philipp Hahn <hahn@univention.de>
  Shriram Rajagopalan <rshriram@cs.ubc.ca>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang2 <wei.wang2@amd.com>
  Xudong Hao <xudong.hao@intel.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 1522 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Dec 10 03:10:53 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 10 Dec 2011 03:10:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZDKD-0003ZP-B6; Sat, 10 Dec 2011 03:10:09 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RZDKB-0003ZK-LH
	for xen-devel@lists.xensource.com; Sat, 10 Dec 2011 03:10:07 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1323486524!46141520!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDMwNg==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24300 invoked from network); 10 Dec 2011 03:08:44 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Dec 2011 03:08:44 -0000
X-IronPort-AV: E=Sophos;i="4.71,330,1320624000"; 
   d="scan'208";a="9395277"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Dec 2011 03:09:21 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sat, 10 Dec 2011 03:09:21 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RZDJR-0005M1-2c;
	Sat, 10 Dec 2011 03:09:21 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RZDJQ-0004yL-RS;
	Sat, 10 Dec 2011 03:09:20 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10470-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 10 Dec 2011 03:09:20 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10470: FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10470 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10470/

Failures and problems with tests :-(

Tests which did not succeed and are blocking:
 test-amd64-i386-rhel6hvm-intel  3 host-install(3)              broken in 10460
 test-i386-i386-pv             3 host-install(3)              broken   in 10460
 test-amd64-amd64-xl-sedf      3 host-install(3)              broken   in 10460

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-credit2    7 debian-install              fail pass in 10468
 test-amd64-amd64-xl-win       7 windows-install             fail pass in 10468
 test-amd64-i386-xl-win-vcpus1  7 windows-install            fail pass in 10460
 test-i386-i386-xl-win         7 windows-install    fail in 10468 pass in 10470
 test-amd64-i386-win-vcpus1    7 windows-install    fail in 10460 pass in 10470

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-i386-i386-xl-winxpsp3    7 windows-install              fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install          fail never pass
 test-amd64-i386-xl-win7-amd64  7 windows-install              fail  never pass
 test-amd64-i386-xend-winxpsp3  7 windows-install              fail  never pass
 test-amd64-amd64-xl-win7-amd64  7 windows-install              fail never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop            fail in 10468 never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop           fail in 10460 never pass

version targeted for testing:
 xen                  1c58bb664d8d
baseline version:
 xen                  62ff6a318c5d

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scanneel.ca>
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Andres Lagar-Cavilla <andres@lagarcavilla>
  Andrew Cooper <andrew.cooper3@citrix.com>
  Anthony PERARD <anthony.perard@citrix.com>
  Brendan Cully <brendan@cs.ubc.ca>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Haitao Shan <haitao.shan@intel.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@novell.com>
  Jan Beulich <jbeulich@suse.com>
  Jonathan Davies <jonathan.davies@citrix.com>
  juergen.gross@ts.fujitsu.com
  Keir Fraser <keir@xen.org>
  Liu, Jinsong <jinsong.liu@intel.com>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
  Philipp Hahn <hahn@univention.de>
  Shriram Rajagopalan <rshriram@cs.ubc.ca>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang2 <wei.wang2@amd.com>
  Xudong Hao <xudong.hao@intel.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 1522 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Dec 10 05:24:19 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 10 Dec 2011 05: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.xensource.com>)
	id 1RZFPH-0004lj-EB; Sat, 10 Dec 2011 05:23:31 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RZFPF-0004le-Cz
	for xen-devel@lists.xensource.com; Sat, 10 Dec 2011 05:23:29 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-5.tower-174.messagelabs.com!1323494557!4988609!1
X-Originating-IP: [208.97.132.202]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4yMDIgPT4gMTYxMTU=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9908 invoked from network); 10 Dec 2011 05:22:37 -0000
Received: from caiajhbdccac.dreamhost.com (HELO homiemail-a15.g.dreamhost.com)
	(208.97.132.202) by server-5.tower-174.messagelabs.com with SMTP;
	10 Dec 2011 05:22:37 -0000
Received: from homiemail-a15.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a15.g.dreamhost.com (Postfix) with ESMTP id 86EEC76C069;
	Fri,  9 Dec 2011 21:22:36 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=nfucxY/jnBF14LZ0voJ3k3ujxp3NYQAze2WNNK117l9H
	15PJPInWS+K0AT2rg3GxUFiSN85XSsl0FbQTt6kxaKyoX5dwLlBQfAgEb9cRYrv9
	bx4fmjbNV+LlwrNAlRmR85XLUHd9MvS5efxOrAdPPT1HI+rzSSqHl9wxhkDF04A=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=fDKxYC9sCS1ejWNYbaGdaExYP+I=; b=EVGbwF7R
	NB/N3szSdfidEsy0F1nYuN6utt+AfLYKGGQRkYxFYBb2V/oI0220DpCmakYCrq02
	jE7lxiBAEQ3JqVIFX1XlCTk7BDj4PtcgfsJ0CS5VDVNDNwliT782dGRWHKSiocLo
	4W32vnQEQqR3N1k5TGY0gYpaDxwVdXEh9gY=
Received: from webmail.lagarcavilla.org (ahfbbjcaiaae.dreamhost.com
	[75.119.208.4]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a15.g.dreamhost.com (Postfix) with ESMTPA id 0109976C065; 
	Fri,  9 Dec 2011 21:22:35 -0800 (PST)
Received: from 184.175.1.54 (proxying for 184.175.1.54)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP; Fri, 9 Dec 2011 21:22:36 -0800
Message-ID: <449af29a31a68b8381c2ea83ee08af52.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <mailman.3873.1323460242.12970.xen-devel@lists.xensource.com>
References: <mailman.3873.1323460242.12970.xen-devel@lists.xensource.com>
Date: Fri, 9 Dec 2011 21:22:36 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: olaf@aepfle.de, tim@xen.org
Subject: Re: [Xen-devel] [PATCH] mem_event: use wait queue when ring is full
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Olaf,
Tim pointed out we need both solutions to ring management in the
hypervisor. With our patch ("Improve ring management for memory events. Do
not lose guest events."), we can handle the common case quickly, without
preempting VMs. With your patch, we can handle extreme situations of ring
congestion with the big hammer called wait queue.

After thinking a little bit about how to integrate both solutions, I've
come to one way of doing it. Might not be the best, but it's an option.

In our patch, we have this pseudo-code snippet
arch/x86/mm/mem_event.c: mem_event_put_request
{
    if (foreign vcpu) and (space_in_ring < vcpus)
        /* Foreign vcpus need to retry. No mercy */
        return -EAGAIN

    if ( mem_event_ring_free(d, med) == 0 )
    {
        /* This *should* never happen */
        gdprintk(XENLOG_WARNING, "possible lost mem_event for domain %d\n",
                                 d->domain_id);
        ret = -EBUSY; <-- *go to sleep on a waitqueue here, instead*
    }
    else
        put_event

    if (space_in_ring < vcpus) && (guest vcpu)
        pause this vcpu
        ret = -EBUSY
}

I hope my pseudo-code description makes sense. All the meta data for queue
management from your patch is necessary. But there is one single,
well-defined, point for wait queue invocation. And the rest is taken care
of (hopefully)

A thought,
Andres
> Date: Fri, 09 Dec 2011 20:23:55 +0100
> From: Olaf Hering <olaf@aepfle.de>
> To: xen-devel@lists.xensource.com
> Subject: [Xen-devel] [PATCH] mem_event: use wait queue when ring is
> 	full
> Message-ID: <b25b2bcc2c6a987086bf.1323458635@probook.site>
> Content-Type: text/plain; charset="us-ascii"
>
> # HG changeset patch
> # User Olaf Hering <olaf@aepfle.de>
> # Date 1323456817 -3600
> # Node ID b25b2bcc2c6a987086bf37ec67a64d989813eb4d
> # Parent  1c58bb664d8d55e475d179cb5f81693991859fc8
> mem_event: use wait queue when ring is full
>
> This change is based on an idea/patch from Adin Scannell.
>
> If the ring is full, put the current vcpu to sleep if it belongs to the
> target domain. The wakeup happens in the p2m_*_resume functions. Wakeup
> will take the number of free slots into account.
>
> A request from foreign domain has to succeed once a slot was claimed
> because such vcpus can not sleep.
>
> This change fixes also a bug in p2m_mem_paging_drop_page(). Up to now a
> full ring will lead to harmless inconsistency in the pager.
>
> v6:
>   - take foreign requests into account before calling wake_up_nr()
>   - call wake_up_nr() outside of ring lock
>  - rename ->bit to ->pause_flag
>  - update comment in mem_event_enable()
>
> v5:
>   - rename mem_event_check_ring() to mem_event_claim_slot()
>   - rename mem_event_put_req_producers() to mem_event_release_slot()
>   - add local/foreign request accounting
>   - keep room for at least one guest request
>
> v4:
>  - fix off-by-one bug in _mem_event_put_request
>  - add mem_event_wake_requesters() and use wake_up_nr()
>  - rename mem_event_mark_and_pause() and mem_event_mark_and_pause()
> functions
>  - req_producers counts foreign request producers, rename member
>
> v3:
>  - rename ->mem_event_bit to ->bit
>  - remove me_ from new VPF_ defines
>
> v2:
>  - p2m_mem_paging_populate: move vcpu_pause after put_request, otherwise
> the
>    vcpu will not wake_up after a wait_event because the pause_count was
>    increased twice. Fixes guest hangs.
>  - update free space check in _mem_event_put_request()
>  - simplify mem_event_put_request()
>
> Signed-off-by: Olaf Hering <olaf@aepfle.de>
>
> diff -r 1c58bb664d8d -r b25b2bcc2c6a xen/arch/x86/hvm/hvm.c
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -4172,8 +4172,8 @@ static int hvm_memory_event_traps(long p
>      if ( (p & HVMPME_onchangeonly) && (value == old) )
>          return 1;
>
> -    rc = mem_event_check_ring(d, &d->mem_event->access);
> -    if ( rc )
> +    rc = mem_event_claim_slot(d, &d->mem_event->access);
> +    if ( rc < 0 )
>          return rc;
>
>      memset(&req, 0, sizeof(req));
> diff -r 1c58bb664d8d -r b25b2bcc2c6a xen/arch/x86/mm/mem_event.c
> --- a/xen/arch/x86/mm/mem_event.c
> +++ b/xen/arch/x86/mm/mem_event.c
> @@ -23,6 +23,7 @@
>
>  #include <asm/domain.h>
>  #include <xen/event.h>
> +#include <xen/wait.h>
>  #include <asm/p2m.h>
>  #include <asm/mem_event.h>
>  #include <asm/mem_paging.h>
> @@ -41,6 +42,7 @@ static int mem_event_enable(
>      struct domain *d,
>      xen_domctl_mem_event_op_t *mec,
>      struct mem_event_domain *med,
> +    int pause_flag,
>      xen_event_channel_notification_t notification_fn)
>  {
>      int rc;
> @@ -110,8 +112,12 @@ static int mem_event_enable(
>
>      mem_event_ring_lock_init(med);
>
> -    /* Wake any VCPUs paused for memory events */
> -    mem_event_unpause_vcpus(d);
> +    med->pause_flag = pause_flag;
> +
> +    init_waitqueue_head(&med->wq);
> +
> +    /* Wake any VCPUs waiting for the ring to appear */
> +    mem_event_wake_waiters(d, med);
>
>      return 0;
>
> @@ -127,6 +133,9 @@ static int mem_event_enable(
>
>  static int mem_event_disable(struct mem_event_domain *med)
>  {
> +    if (!list_empty(&med->wq.list))
> +        return -EBUSY;
> +
>      unmap_domain_page(med->ring_page);
>      med->ring_page = NULL;
>
> @@ -136,13 +145,24 @@ static int mem_event_disable(struct mem_
>      return 0;
>  }
>
> -void mem_event_put_request(struct domain *d, struct mem_event_domain
> *med, mem_event_request_t *req)
> +static int _mem_event_put_request(struct domain *d,
> +                                  struct mem_event_domain *med,
> +                                  mem_event_request_t *req)
>  {
>      mem_event_front_ring_t *front_ring;
> +    int free_req, claimed_req;
>      RING_IDX req_prod;
>
>      mem_event_ring_lock(med);
>
> +    free_req = RING_FREE_REQUESTS(&med->front_ring);
> +    /* Foreign requests must succeed because their vcpus can not sleep */
> +    claimed_req = med->foreign_producers;
> +    if ( !free_req || ( current->domain == d && free_req <= claimed_req )
> ) {
> +        mem_event_ring_unlock(med);
> +        return 0;
> +    }
> +
>      front_ring = &med->front_ring;
>      req_prod = front_ring->req_prod_pvt;
>
> @@ -156,14 +176,35 @@ void mem_event_put_request(struct domain
>      memcpy(RING_GET_REQUEST(front_ring, req_prod), req, sizeof(*req));
>      req_prod++;
>
> +    /* Update accounting */
> +    if ( current->domain == d )
> +        med->target_producers--;
> +    else
> +        med->foreign_producers--;
> +
>      /* Update ring */
> -    med->req_producers--;
>      front_ring->req_prod_pvt = req_prod;
>      RING_PUSH_REQUESTS(front_ring);
>
>      mem_event_ring_unlock(med);
>
>      notify_via_xen_event_channel(d, med->xen_port);
> +
> +    return 1;
> +}
> +
> +void mem_event_put_request(struct domain *d, struct mem_event_domain
> *med,
> +                           mem_event_request_t *req)
> +{
> +    /* Go to sleep if request came from guest */
> +    if (current->domain == d) {
> +        wait_event(med->wq, _mem_event_put_request(d, med, req));
> +        return;
> +    }
> +    /* Ring was full anyway, unable to sleep in non-guest context */
> +    if (!_mem_event_put_request(d, med, req))
> +        printk("Failed to put memreq: d %u t %x f %x gfn %lx\n",
> d->domain_id,
> +                req->type, req->flags, (unsigned long)req->gfn);
>  }
>
>  int mem_event_get_response(struct mem_event_domain *med,
> mem_event_response_t *rsp)
> @@ -195,32 +236,97 @@ int mem_event_get_response(struct mem_ev
>      return 1;
>  }
>
> -void mem_event_unpause_vcpus(struct domain *d)
> +/**
> + * mem_event_wake_requesters - Wake vcpus waiting for room in the ring
> + * @d: guest domain
> + * @med: mem_event ring
> + *
> + * mem_event_wake_requesters() will wakeup vcpus waiting for room in the
> + * ring. Only as many as can place another request in the ring will
> + * resume execution.
> + */
> +void mem_event_wake_requesters(struct mem_event_domain *med)
> +{
> +    int free_req;
> +
> +    mem_event_ring_lock(med);
> +    free_req = RING_FREE_REQUESTS(&med->front_ring);
> +    free_req -= med->foreign_producers;
> +    mem_event_ring_unlock(med);
> +
> +    if ( free_req )
> +        wake_up_nr(&med->wq, free_req);
> +}
> +
> +/**
> + * mem_event_wake_waiters - Wake all vcpus waiting for the ring
> + * @d: guest domain
> + * @med: mem_event ring
> + *
> + * mem_event_wake_waiters() will wakeup all vcpus waiting for the ring to
> + * become available.
> + */
> +void mem_event_wake_waiters(struct domain *d, struct mem_event_domain
> *med)
>  {
>      struct vcpu *v;
>
>      for_each_vcpu ( d, v )
> -        if ( test_and_clear_bit(_VPF_mem_event, &v->pause_flags) )
> +        if ( test_and_clear_bit(med->pause_flag, &v->pause_flags) )
>              vcpu_wake(v);
>  }
>
> -void mem_event_mark_and_pause(struct vcpu *v)
> +/**
> + * mem_event_mark_and_sleep - Put vcpu to sleep
> + * @v: guest vcpu
> + * @med: mem_event ring
> + *
> + * mem_event_mark_and_sleep() tags vcpu and put it to sleep.
> + * The vcpu will resume execution in mem_event_wake_waiters().
> + */
> +void mem_event_mark_and_sleep(struct vcpu *v, struct mem_event_domain
> *med)
>  {
> -    set_bit(_VPF_mem_event, &v->pause_flags);
> +    set_bit(med->pause_flag, &v->pause_flags);
>      vcpu_sleep_nosync(v);
>  }
>
> -void mem_event_put_req_producers(struct mem_event_domain *med)
> +/**
> + * mem_event_release_slot - Release a claimed slot
> + * @med: mem_event ring
> + *
> + * mem_event_release_slot() releases a claimed slot in the mem_event
> ring.
> + */
> +void mem_event_release_slot(struct domain *d, struct mem_event_domain
> *med)
>  {
>      mem_event_ring_lock(med);
> -    med->req_producers--;
> +    if ( current->domain == d )
> +        med->target_producers--;
> +    else
> +        med->foreign_producers--;
>      mem_event_ring_unlock(med);
>  }
>
> -int mem_event_check_ring(struct domain *d, struct mem_event_domain *med)
> +/**
> + * mem_event_claim_slot - Check state of a mem_event ring
> + * @d: guest domain
> + * @med: mem_event ring
> + *
> + * Return codes: < 0: the ring is not yet configured
> + *                 0: the ring has some room
> + *               > 0: the ring is full
> + *
> + * mem_event_claim_slot() checks the state of the given mem_event ring.
> + * If the current vcpu belongs to the guest domain, the function assumes
> that
> + * mem_event_put_request() will sleep until the ring has room again.
> + * A guest can always place at least one request.
> + *
> + * If the current vcpu does not belong to the target domain the caller
> must try
> + * again until there is room. A slot is claimed and the caller can place
> a
> + * request. If the caller does not need to send a request, the claimed
> slot has
> + * to be released with mem_event_release_slot().
> + */
> +int mem_event_claim_slot(struct domain *d, struct mem_event_domain *med)
>  {
> -    struct vcpu *curr = current;
> -    int free_requests;
> +    int free_req;
>      int ring_full = 1;
>
>      if ( !med->ring_page )
> @@ -228,16 +334,17 @@ int mem_event_check_ring(struct domain *
>
>      mem_event_ring_lock(med);
>
> -    free_requests = RING_FREE_REQUESTS(&med->front_ring);
> -    if ( med->req_producers < free_requests )
> +    free_req = RING_FREE_REQUESTS(&med->front_ring);
> +
> +    if ( current->domain == d ) {
> +        med->target_producers++;
> +        ring_full = 0;
> +    } else if ( med->foreign_producers + med->target_producers + 1 <
> free_req )
>      {
> -        med->req_producers++;
> +        med->foreign_producers++;
>          ring_full = 0;
>      }
>
> -    if ( ring_full && (curr->domain == d) )
> -        mem_event_mark_and_pause(curr);
> -
>      mem_event_ring_unlock(med);
>
>      return ring_full;
> @@ -316,7 +423,7 @@ int mem_event_domctl(struct domain *d, x
>              if ( p2m->pod.entry_count )
>                  break;
>
> -            rc = mem_event_enable(d, mec, med, mem_paging_notification);
> +            rc = mem_event_enable(d, mec, med, _VPF_mem_paging,
> mem_paging_notification);
>          }
>          break;
>
> @@ -355,7 +462,7 @@ int mem_event_domctl(struct domain *d, x
>              if ( boot_cpu_data.x86_vendor != X86_VENDOR_INTEL )
>                  break;
>
> -            rc = mem_event_enable(d, mec, med, mem_access_notification);
> +            rc = mem_event_enable(d, mec, med, _VPF_mem_access,
> mem_access_notification);
>          }
>          break;
>
> diff -r 1c58bb664d8d -r b25b2bcc2c6a xen/arch/x86/mm/mem_sharing.c
> --- a/xen/arch/x86/mm/mem_sharing.c
> +++ b/xen/arch/x86/mm/mem_sharing.c
> @@ -253,18 +253,10 @@ static void mem_sharing_audit(void)
>  #endif
>
>
> -static struct page_info* mem_sharing_alloc_page(struct domain *d,
> -                                                unsigned long gfn)
> +static void mem_sharing_notify_helper(struct domain *d, unsigned long
> gfn)
>  {
> -    struct page_info* page;
>      struct vcpu *v = current;
> -    mem_event_request_t req;
> -
> -    page = alloc_domheap_page(d, 0);
> -    if(page != NULL) return page;
> -
> -    memset(&req, 0, sizeof(req));
> -    req.type = MEM_EVENT_TYPE_SHARED;
> +    mem_event_request_t req = { .type = MEM_EVENT_TYPE_SHARED };
>
>      if ( v->domain != d )
>      {
> @@ -275,20 +267,18 @@ static struct page_info* mem_sharing_all
>          gdprintk(XENLOG_ERR,
>                   "Failed alloc on unshare path for foreign (%d)
> lookup\n",
>                   d->domain_id);
> -        return page;
> +        return;
>      }
>
> -    vcpu_pause_nosync(v);
> -    req.flags |= MEM_EVENT_FLAG_VCPU_PAUSED;
> +    if (mem_event_claim_slot(d, &d->mem_event->share) < 0)
> +        return;
>
> -    if(mem_event_check_ring(d, &d->mem_event->share)) return page;
> -
> +    req.flags = MEM_EVENT_FLAG_VCPU_PAUSED;
>      req.gfn = gfn;
>      req.p2mt = p2m_ram_shared;
>      req.vcpu_id = v->vcpu_id;
>      mem_event_put_request(d, &d->mem_event->share, &req);
> -
> -    return page;
> +    vcpu_pause_nosync(v);
>  }
>
>  unsigned int mem_sharing_get_nr_saved_mfns(void)
> @@ -656,7 +646,7 @@ gfn_found:
>      if(ret == 0) goto private_page_found;
>
>      old_page = page;
> -    page = mem_sharing_alloc_page(d, gfn);
> +    page = alloc_domheap_page(d, 0);
>      if(!page)
>      {
>          /* We've failed to obtain memory for private page. Need to re-add
> the
> @@ -664,6 +654,7 @@ gfn_found:
>          list_add(&gfn_info->list, &hash_entry->gfns);
>          put_gfn(d, gfn);
>          shr_unlock();
> +        mem_sharing_notify_helper(d, gfn);
>          return -ENOMEM;
>      }
>
> diff -r 1c58bb664d8d -r b25b2bcc2c6a xen/arch/x86/mm/p2m.c
> --- a/xen/arch/x86/mm/p2m.c
> +++ b/xen/arch/x86/mm/p2m.c
> @@ -861,20 +861,12 @@ int p2m_mem_paging_evict(struct domain *
>   */
>  void p2m_mem_paging_drop_page(struct domain *d, unsigned long gfn)
>  {
> -    struct vcpu *v = current;
> -    mem_event_request_t req;
> +    mem_event_request_t req = { .type = MEM_EVENT_TYPE_PAGING, .gfn = gfn
> };
>
> -    /* Check that there's space on the ring for this request */
> -    if ( mem_event_check_ring(d, &d->mem_event->paging) == 0)
> -    {
> -        /* Send release notification to pager */
> -        memset(&req, 0, sizeof(req));
> -        req.flags |= MEM_EVENT_FLAG_DROP_PAGE;
> -        req.gfn = gfn;
> -        req.vcpu_id = v->vcpu_id;
> +    /* Send release notification to pager */
> +    req.flags = MEM_EVENT_FLAG_DROP_PAGE;
>
> -        mem_event_put_request(d, &d->mem_event->paging, &req);
> -    }
> +    mem_event_put_request(d, &d->mem_event->paging, &req);
>  }
>
>  /**
> @@ -908,7 +900,7 @@ void p2m_mem_paging_populate(struct doma
>      struct p2m_domain *p2m = p2m_get_hostp2m(d);
>
>      /* Check that there's space on the ring for this request */
> -    if ( mem_event_check_ring(d, &d->mem_event->paging) )
> +    if ( mem_event_claim_slot(d, &d->mem_event->paging) )
>          return;
>
>      memset(&req, 0, sizeof(req));
> @@ -938,7 +930,7 @@ void p2m_mem_paging_populate(struct doma
>      else if ( p2mt != p2m_ram_paging_out && p2mt != p2m_ram_paged )
>      {
>          /* gfn is already on its way back and vcpu is not paused */
> -        mem_event_put_req_producers(&d->mem_event->paging);
> +        mem_event_release_slot(d, &d->mem_event->paging);
>          return;
>      }
>
> @@ -1080,8 +1072,8 @@ void p2m_mem_paging_resume(struct domain
>              vcpu_unpause(d->vcpu[rsp.vcpu_id]);
>      }
>
> -    /* Unpause any domains that were paused because the ring was full */
> -    mem_event_unpause_vcpus(d);
> +    /* Wake vcpus waiting for room in the ring */
> +    mem_event_wake_requesters(&d->mem_event->paging);
>  }
>
>  bool_t p2m_mem_access_check(unsigned long gpa, bool_t gla_valid, unsigned
> long gla,
> @@ -1115,7 +1107,7 @@ bool_t p2m_mem_access_check(unsigned lon
>      p2m_unlock(p2m);
>
>      /* Otherwise, check if there is a memory event listener, and send the
> message along */
> -    res = mem_event_check_ring(d, &d->mem_event->access);
> +    res = mem_event_claim_slot(d, &d->mem_event->access);
>      if ( res < 0 )
>      {
>          /* No listener */
> @@ -1125,7 +1117,7 @@ bool_t p2m_mem_access_check(unsigned lon
>                     "Memory access permissions failure, no mem_event
> listener: pausing VCPU %d, dom %d\n",
>                     v->vcpu_id, d->domain_id);
>
> -            mem_event_mark_and_pause(v);
> +            mem_event_mark_and_sleep(v, &d->mem_event->access);
>          }
>          else
>          {
> @@ -1186,9 +1178,11 @@ void p2m_mem_access_resume(struct domain
>              vcpu_unpause(d->vcpu[rsp.vcpu_id]);
>      }
>
> -    /* Unpause any domains that were paused because the ring was full or
> no listener
> -     * was available */
> -    mem_event_unpause_vcpus(d);
> +    /* Wake vcpus waiting for room in the ring */
> +    mem_event_wake_requesters(&d->mem_event->access);
> +
> +    /* Unpause all vcpus that were paused because no listener was
> available */
> +    mem_event_wake_waiters(d, &d->mem_event->access);
>  }
>
>
> diff -r 1c58bb664d8d -r b25b2bcc2c6a xen/include/asm-x86/mem_event.h
> --- a/xen/include/asm-x86/mem_event.h
> +++ b/xen/include/asm-x86/mem_event.h
> @@ -24,13 +24,13 @@
>  #ifndef __MEM_EVENT_H__
>  #define __MEM_EVENT_H__
>
> -/* Pauses VCPU while marking pause flag for mem event */
> -void mem_event_mark_and_pause(struct vcpu *v);
> -int mem_event_check_ring(struct domain *d, struct mem_event_domain *med);
> -void mem_event_put_req_producers(struct mem_event_domain *med);
> +int mem_event_claim_slot(struct domain *d, struct mem_event_domain *med);
> +void mem_event_release_slot(struct domain *d, struct mem_event_domain
> *med);
>  void mem_event_put_request(struct domain *d, struct mem_event_domain
> *med, mem_event_request_t *req);
>  int mem_event_get_response(struct mem_event_domain *med,
> mem_event_response_t *rsp);
> -void mem_event_unpause_vcpus(struct domain *d);
> +void mem_event_wake_requesters(struct mem_event_domain *med);
> +void mem_event_wake_waiters(struct domain *d, struct mem_event_domain
> *med);
> +void mem_event_mark_and_sleep(struct vcpu *v, struct mem_event_domain
> *med);
>
>  int mem_event_domctl(struct domain *d, xen_domctl_mem_event_op_t *mec,
>                       XEN_GUEST_HANDLE(void) u_domctl);
> diff -r 1c58bb664d8d -r b25b2bcc2c6a xen/include/xen/sched.h
> --- a/xen/include/xen/sched.h
> +++ b/xen/include/xen/sched.h
> @@ -14,6 +14,7 @@
>  #include <xen/nodemask.h>
>  #include <xen/radix-tree.h>
>  #include <xen/multicall.h>
> +#include <xen/wait.h>
>  #include <public/xen.h>
>  #include <public/domctl.h>
>  #include <public/sysctl.h>
> @@ -183,7 +184,8 @@ struct mem_event_domain
>  {
>      /* ring lock */
>      spinlock_t ring_lock;
> -    unsigned int req_producers;
> +    unsigned short foreign_producers;
> +    unsigned short target_producers;
>      /* shared page */
>      mem_event_shared_page_t *shared_page;
>      /* shared ring page */
> @@ -192,6 +194,10 @@ struct mem_event_domain
>      mem_event_front_ring_t front_ring;
>      /* event channel port (vcpu0 only) */
>      int xen_port;
> +    /* mem_event bit for vcpu->pause_flags */
> +    int pause_flag;
> +    /* list of vcpus waiting for room in the ring */
> +    struct waitqueue_head wq;
>  };
>
>  struct mem_event_per_domain
> @@ -615,9 +621,12 @@ static inline struct domain *next_domain
>   /* VCPU affinity has changed: migrating to a new CPU. */
>  #define _VPF_migrating       3
>  #define VPF_migrating        (1UL<<_VPF_migrating)
> - /* VCPU is blocked on memory-event ring. */
> -#define _VPF_mem_event       4
> -#define VPF_mem_event        (1UL<<_VPF_mem_event)
> + /* VCPU is blocked due to missing mem_paging ring. */
> +#define _VPF_mem_paging      4
> +#define VPF_mem_paging       (1UL<<_VPF_mem_paging)
> + /* VCPU is blocked due to missing mem_access ring. */
> +#define _VPF_mem_access      5
> +#define VPF_mem_access       (1UL<<_VPF_mem_access)
>
>  static inline int vcpu_runnable(struct vcpu *v)
>  {
>
>
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Dec 10 05:24:19 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 10 Dec 2011 05: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.xensource.com>)
	id 1RZFPH-0004lj-EB; Sat, 10 Dec 2011 05:23:31 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RZFPF-0004le-Cz
	for xen-devel@lists.xensource.com; Sat, 10 Dec 2011 05:23:29 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-5.tower-174.messagelabs.com!1323494557!4988609!1
X-Originating-IP: [208.97.132.202]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4yMDIgPT4gMTYxMTU=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9908 invoked from network); 10 Dec 2011 05:22:37 -0000
Received: from caiajhbdccac.dreamhost.com (HELO homiemail-a15.g.dreamhost.com)
	(208.97.132.202) by server-5.tower-174.messagelabs.com with SMTP;
	10 Dec 2011 05:22:37 -0000
Received: from homiemail-a15.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a15.g.dreamhost.com (Postfix) with ESMTP id 86EEC76C069;
	Fri,  9 Dec 2011 21:22:36 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=nfucxY/jnBF14LZ0voJ3k3ujxp3NYQAze2WNNK117l9H
	15PJPInWS+K0AT2rg3GxUFiSN85XSsl0FbQTt6kxaKyoX5dwLlBQfAgEb9cRYrv9
	bx4fmjbNV+LlwrNAlRmR85XLUHd9MvS5efxOrAdPPT1HI+rzSSqHl9wxhkDF04A=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=fDKxYC9sCS1ejWNYbaGdaExYP+I=; b=EVGbwF7R
	NB/N3szSdfidEsy0F1nYuN6utt+AfLYKGGQRkYxFYBb2V/oI0220DpCmakYCrq02
	jE7lxiBAEQ3JqVIFX1XlCTk7BDj4PtcgfsJ0CS5VDVNDNwliT782dGRWHKSiocLo
	4W32vnQEQqR3N1k5TGY0gYpaDxwVdXEh9gY=
Received: from webmail.lagarcavilla.org (ahfbbjcaiaae.dreamhost.com
	[75.119.208.4]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a15.g.dreamhost.com (Postfix) with ESMTPA id 0109976C065; 
	Fri,  9 Dec 2011 21:22:35 -0800 (PST)
Received: from 184.175.1.54 (proxying for 184.175.1.54)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP; Fri, 9 Dec 2011 21:22:36 -0800
Message-ID: <449af29a31a68b8381c2ea83ee08af52.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <mailman.3873.1323460242.12970.xen-devel@lists.xensource.com>
References: <mailman.3873.1323460242.12970.xen-devel@lists.xensource.com>
Date: Fri, 9 Dec 2011 21:22:36 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: olaf@aepfle.de, tim@xen.org
Subject: Re: [Xen-devel] [PATCH] mem_event: use wait queue when ring is full
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Olaf,
Tim pointed out we need both solutions to ring management in the
hypervisor. With our patch ("Improve ring management for memory events. Do
not lose guest events."), we can handle the common case quickly, without
preempting VMs. With your patch, we can handle extreme situations of ring
congestion with the big hammer called wait queue.

After thinking a little bit about how to integrate both solutions, I've
come to one way of doing it. Might not be the best, but it's an option.

In our patch, we have this pseudo-code snippet
arch/x86/mm/mem_event.c: mem_event_put_request
{
    if (foreign vcpu) and (space_in_ring < vcpus)
        /* Foreign vcpus need to retry. No mercy */
        return -EAGAIN

    if ( mem_event_ring_free(d, med) == 0 )
    {
        /* This *should* never happen */
        gdprintk(XENLOG_WARNING, "possible lost mem_event for domain %d\n",
                                 d->domain_id);
        ret = -EBUSY; <-- *go to sleep on a waitqueue here, instead*
    }
    else
        put_event

    if (space_in_ring < vcpus) && (guest vcpu)
        pause this vcpu
        ret = -EBUSY
}

I hope my pseudo-code description makes sense. All the meta data for queue
management from your patch is necessary. But there is one single,
well-defined, point for wait queue invocation. And the rest is taken care
of (hopefully)

A thought,
Andres
> Date: Fri, 09 Dec 2011 20:23:55 +0100
> From: Olaf Hering <olaf@aepfle.de>
> To: xen-devel@lists.xensource.com
> Subject: [Xen-devel] [PATCH] mem_event: use wait queue when ring is
> 	full
> Message-ID: <b25b2bcc2c6a987086bf.1323458635@probook.site>
> Content-Type: text/plain; charset="us-ascii"
>
> # HG changeset patch
> # User Olaf Hering <olaf@aepfle.de>
> # Date 1323456817 -3600
> # Node ID b25b2bcc2c6a987086bf37ec67a64d989813eb4d
> # Parent  1c58bb664d8d55e475d179cb5f81693991859fc8
> mem_event: use wait queue when ring is full
>
> This change is based on an idea/patch from Adin Scannell.
>
> If the ring is full, put the current vcpu to sleep if it belongs to the
> target domain. The wakeup happens in the p2m_*_resume functions. Wakeup
> will take the number of free slots into account.
>
> A request from foreign domain has to succeed once a slot was claimed
> because such vcpus can not sleep.
>
> This change fixes also a bug in p2m_mem_paging_drop_page(). Up to now a
> full ring will lead to harmless inconsistency in the pager.
>
> v6:
>   - take foreign requests into account before calling wake_up_nr()
>   - call wake_up_nr() outside of ring lock
>  - rename ->bit to ->pause_flag
>  - update comment in mem_event_enable()
>
> v5:
>   - rename mem_event_check_ring() to mem_event_claim_slot()
>   - rename mem_event_put_req_producers() to mem_event_release_slot()
>   - add local/foreign request accounting
>   - keep room for at least one guest request
>
> v4:
>  - fix off-by-one bug in _mem_event_put_request
>  - add mem_event_wake_requesters() and use wake_up_nr()
>  - rename mem_event_mark_and_pause() and mem_event_mark_and_pause()
> functions
>  - req_producers counts foreign request producers, rename member
>
> v3:
>  - rename ->mem_event_bit to ->bit
>  - remove me_ from new VPF_ defines
>
> v2:
>  - p2m_mem_paging_populate: move vcpu_pause after put_request, otherwise
> the
>    vcpu will not wake_up after a wait_event because the pause_count was
>    increased twice. Fixes guest hangs.
>  - update free space check in _mem_event_put_request()
>  - simplify mem_event_put_request()
>
> Signed-off-by: Olaf Hering <olaf@aepfle.de>
>
> diff -r 1c58bb664d8d -r b25b2bcc2c6a xen/arch/x86/hvm/hvm.c
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -4172,8 +4172,8 @@ static int hvm_memory_event_traps(long p
>      if ( (p & HVMPME_onchangeonly) && (value == old) )
>          return 1;
>
> -    rc = mem_event_check_ring(d, &d->mem_event->access);
> -    if ( rc )
> +    rc = mem_event_claim_slot(d, &d->mem_event->access);
> +    if ( rc < 0 )
>          return rc;
>
>      memset(&req, 0, sizeof(req));
> diff -r 1c58bb664d8d -r b25b2bcc2c6a xen/arch/x86/mm/mem_event.c
> --- a/xen/arch/x86/mm/mem_event.c
> +++ b/xen/arch/x86/mm/mem_event.c
> @@ -23,6 +23,7 @@
>
>  #include <asm/domain.h>
>  #include <xen/event.h>
> +#include <xen/wait.h>
>  #include <asm/p2m.h>
>  #include <asm/mem_event.h>
>  #include <asm/mem_paging.h>
> @@ -41,6 +42,7 @@ static int mem_event_enable(
>      struct domain *d,
>      xen_domctl_mem_event_op_t *mec,
>      struct mem_event_domain *med,
> +    int pause_flag,
>      xen_event_channel_notification_t notification_fn)
>  {
>      int rc;
> @@ -110,8 +112,12 @@ static int mem_event_enable(
>
>      mem_event_ring_lock_init(med);
>
> -    /* Wake any VCPUs paused for memory events */
> -    mem_event_unpause_vcpus(d);
> +    med->pause_flag = pause_flag;
> +
> +    init_waitqueue_head(&med->wq);
> +
> +    /* Wake any VCPUs waiting for the ring to appear */
> +    mem_event_wake_waiters(d, med);
>
>      return 0;
>
> @@ -127,6 +133,9 @@ static int mem_event_enable(
>
>  static int mem_event_disable(struct mem_event_domain *med)
>  {
> +    if (!list_empty(&med->wq.list))
> +        return -EBUSY;
> +
>      unmap_domain_page(med->ring_page);
>      med->ring_page = NULL;
>
> @@ -136,13 +145,24 @@ static int mem_event_disable(struct mem_
>      return 0;
>  }
>
> -void mem_event_put_request(struct domain *d, struct mem_event_domain
> *med, mem_event_request_t *req)
> +static int _mem_event_put_request(struct domain *d,
> +                                  struct mem_event_domain *med,
> +                                  mem_event_request_t *req)
>  {
>      mem_event_front_ring_t *front_ring;
> +    int free_req, claimed_req;
>      RING_IDX req_prod;
>
>      mem_event_ring_lock(med);
>
> +    free_req = RING_FREE_REQUESTS(&med->front_ring);
> +    /* Foreign requests must succeed because their vcpus can not sleep */
> +    claimed_req = med->foreign_producers;
> +    if ( !free_req || ( current->domain == d && free_req <= claimed_req )
> ) {
> +        mem_event_ring_unlock(med);
> +        return 0;
> +    }
> +
>      front_ring = &med->front_ring;
>      req_prod = front_ring->req_prod_pvt;
>
> @@ -156,14 +176,35 @@ void mem_event_put_request(struct domain
>      memcpy(RING_GET_REQUEST(front_ring, req_prod), req, sizeof(*req));
>      req_prod++;
>
> +    /* Update accounting */
> +    if ( current->domain == d )
> +        med->target_producers--;
> +    else
> +        med->foreign_producers--;
> +
>      /* Update ring */
> -    med->req_producers--;
>      front_ring->req_prod_pvt = req_prod;
>      RING_PUSH_REQUESTS(front_ring);
>
>      mem_event_ring_unlock(med);
>
>      notify_via_xen_event_channel(d, med->xen_port);
> +
> +    return 1;
> +}
> +
> +void mem_event_put_request(struct domain *d, struct mem_event_domain
> *med,
> +                           mem_event_request_t *req)
> +{
> +    /* Go to sleep if request came from guest */
> +    if (current->domain == d) {
> +        wait_event(med->wq, _mem_event_put_request(d, med, req));
> +        return;
> +    }
> +    /* Ring was full anyway, unable to sleep in non-guest context */
> +    if (!_mem_event_put_request(d, med, req))
> +        printk("Failed to put memreq: d %u t %x f %x gfn %lx\n",
> d->domain_id,
> +                req->type, req->flags, (unsigned long)req->gfn);
>  }
>
>  int mem_event_get_response(struct mem_event_domain *med,
> mem_event_response_t *rsp)
> @@ -195,32 +236,97 @@ int mem_event_get_response(struct mem_ev
>      return 1;
>  }
>
> -void mem_event_unpause_vcpus(struct domain *d)
> +/**
> + * mem_event_wake_requesters - Wake vcpus waiting for room in the ring
> + * @d: guest domain
> + * @med: mem_event ring
> + *
> + * mem_event_wake_requesters() will wakeup vcpus waiting for room in the
> + * ring. Only as many as can place another request in the ring will
> + * resume execution.
> + */
> +void mem_event_wake_requesters(struct mem_event_domain *med)
> +{
> +    int free_req;
> +
> +    mem_event_ring_lock(med);
> +    free_req = RING_FREE_REQUESTS(&med->front_ring);
> +    free_req -= med->foreign_producers;
> +    mem_event_ring_unlock(med);
> +
> +    if ( free_req )
> +        wake_up_nr(&med->wq, free_req);
> +}
> +
> +/**
> + * mem_event_wake_waiters - Wake all vcpus waiting for the ring
> + * @d: guest domain
> + * @med: mem_event ring
> + *
> + * mem_event_wake_waiters() will wakeup all vcpus waiting for the ring to
> + * become available.
> + */
> +void mem_event_wake_waiters(struct domain *d, struct mem_event_domain
> *med)
>  {
>      struct vcpu *v;
>
>      for_each_vcpu ( d, v )
> -        if ( test_and_clear_bit(_VPF_mem_event, &v->pause_flags) )
> +        if ( test_and_clear_bit(med->pause_flag, &v->pause_flags) )
>              vcpu_wake(v);
>  }
>
> -void mem_event_mark_and_pause(struct vcpu *v)
> +/**
> + * mem_event_mark_and_sleep - Put vcpu to sleep
> + * @v: guest vcpu
> + * @med: mem_event ring
> + *
> + * mem_event_mark_and_sleep() tags vcpu and put it to sleep.
> + * The vcpu will resume execution in mem_event_wake_waiters().
> + */
> +void mem_event_mark_and_sleep(struct vcpu *v, struct mem_event_domain
> *med)
>  {
> -    set_bit(_VPF_mem_event, &v->pause_flags);
> +    set_bit(med->pause_flag, &v->pause_flags);
>      vcpu_sleep_nosync(v);
>  }
>
> -void mem_event_put_req_producers(struct mem_event_domain *med)
> +/**
> + * mem_event_release_slot - Release a claimed slot
> + * @med: mem_event ring
> + *
> + * mem_event_release_slot() releases a claimed slot in the mem_event
> ring.
> + */
> +void mem_event_release_slot(struct domain *d, struct mem_event_domain
> *med)
>  {
>      mem_event_ring_lock(med);
> -    med->req_producers--;
> +    if ( current->domain == d )
> +        med->target_producers--;
> +    else
> +        med->foreign_producers--;
>      mem_event_ring_unlock(med);
>  }
>
> -int mem_event_check_ring(struct domain *d, struct mem_event_domain *med)
> +/**
> + * mem_event_claim_slot - Check state of a mem_event ring
> + * @d: guest domain
> + * @med: mem_event ring
> + *
> + * Return codes: < 0: the ring is not yet configured
> + *                 0: the ring has some room
> + *               > 0: the ring is full
> + *
> + * mem_event_claim_slot() checks the state of the given mem_event ring.
> + * If the current vcpu belongs to the guest domain, the function assumes
> that
> + * mem_event_put_request() will sleep until the ring has room again.
> + * A guest can always place at least one request.
> + *
> + * If the current vcpu does not belong to the target domain the caller
> must try
> + * again until there is room. A slot is claimed and the caller can place
> a
> + * request. If the caller does not need to send a request, the claimed
> slot has
> + * to be released with mem_event_release_slot().
> + */
> +int mem_event_claim_slot(struct domain *d, struct mem_event_domain *med)
>  {
> -    struct vcpu *curr = current;
> -    int free_requests;
> +    int free_req;
>      int ring_full = 1;
>
>      if ( !med->ring_page )
> @@ -228,16 +334,17 @@ int mem_event_check_ring(struct domain *
>
>      mem_event_ring_lock(med);
>
> -    free_requests = RING_FREE_REQUESTS(&med->front_ring);
> -    if ( med->req_producers < free_requests )
> +    free_req = RING_FREE_REQUESTS(&med->front_ring);
> +
> +    if ( current->domain == d ) {
> +        med->target_producers++;
> +        ring_full = 0;
> +    } else if ( med->foreign_producers + med->target_producers + 1 <
> free_req )
>      {
> -        med->req_producers++;
> +        med->foreign_producers++;
>          ring_full = 0;
>      }
>
> -    if ( ring_full && (curr->domain == d) )
> -        mem_event_mark_and_pause(curr);
> -
>      mem_event_ring_unlock(med);
>
>      return ring_full;
> @@ -316,7 +423,7 @@ int mem_event_domctl(struct domain *d, x
>              if ( p2m->pod.entry_count )
>                  break;
>
> -            rc = mem_event_enable(d, mec, med, mem_paging_notification);
> +            rc = mem_event_enable(d, mec, med, _VPF_mem_paging,
> mem_paging_notification);
>          }
>          break;
>
> @@ -355,7 +462,7 @@ int mem_event_domctl(struct domain *d, x
>              if ( boot_cpu_data.x86_vendor != X86_VENDOR_INTEL )
>                  break;
>
> -            rc = mem_event_enable(d, mec, med, mem_access_notification);
> +            rc = mem_event_enable(d, mec, med, _VPF_mem_access,
> mem_access_notification);
>          }
>          break;
>
> diff -r 1c58bb664d8d -r b25b2bcc2c6a xen/arch/x86/mm/mem_sharing.c
> --- a/xen/arch/x86/mm/mem_sharing.c
> +++ b/xen/arch/x86/mm/mem_sharing.c
> @@ -253,18 +253,10 @@ static void mem_sharing_audit(void)
>  #endif
>
>
> -static struct page_info* mem_sharing_alloc_page(struct domain *d,
> -                                                unsigned long gfn)
> +static void mem_sharing_notify_helper(struct domain *d, unsigned long
> gfn)
>  {
> -    struct page_info* page;
>      struct vcpu *v = current;
> -    mem_event_request_t req;
> -
> -    page = alloc_domheap_page(d, 0);
> -    if(page != NULL) return page;
> -
> -    memset(&req, 0, sizeof(req));
> -    req.type = MEM_EVENT_TYPE_SHARED;
> +    mem_event_request_t req = { .type = MEM_EVENT_TYPE_SHARED };
>
>      if ( v->domain != d )
>      {
> @@ -275,20 +267,18 @@ static struct page_info* mem_sharing_all
>          gdprintk(XENLOG_ERR,
>                   "Failed alloc on unshare path for foreign (%d)
> lookup\n",
>                   d->domain_id);
> -        return page;
> +        return;
>      }
>
> -    vcpu_pause_nosync(v);
> -    req.flags |= MEM_EVENT_FLAG_VCPU_PAUSED;
> +    if (mem_event_claim_slot(d, &d->mem_event->share) < 0)
> +        return;
>
> -    if(mem_event_check_ring(d, &d->mem_event->share)) return page;
> -
> +    req.flags = MEM_EVENT_FLAG_VCPU_PAUSED;
>      req.gfn = gfn;
>      req.p2mt = p2m_ram_shared;
>      req.vcpu_id = v->vcpu_id;
>      mem_event_put_request(d, &d->mem_event->share, &req);
> -
> -    return page;
> +    vcpu_pause_nosync(v);
>  }
>
>  unsigned int mem_sharing_get_nr_saved_mfns(void)
> @@ -656,7 +646,7 @@ gfn_found:
>      if(ret == 0) goto private_page_found;
>
>      old_page = page;
> -    page = mem_sharing_alloc_page(d, gfn);
> +    page = alloc_domheap_page(d, 0);
>      if(!page)
>      {
>          /* We've failed to obtain memory for private page. Need to re-add
> the
> @@ -664,6 +654,7 @@ gfn_found:
>          list_add(&gfn_info->list, &hash_entry->gfns);
>          put_gfn(d, gfn);
>          shr_unlock();
> +        mem_sharing_notify_helper(d, gfn);
>          return -ENOMEM;
>      }
>
> diff -r 1c58bb664d8d -r b25b2bcc2c6a xen/arch/x86/mm/p2m.c
> --- a/xen/arch/x86/mm/p2m.c
> +++ b/xen/arch/x86/mm/p2m.c
> @@ -861,20 +861,12 @@ int p2m_mem_paging_evict(struct domain *
>   */
>  void p2m_mem_paging_drop_page(struct domain *d, unsigned long gfn)
>  {
> -    struct vcpu *v = current;
> -    mem_event_request_t req;
> +    mem_event_request_t req = { .type = MEM_EVENT_TYPE_PAGING, .gfn = gfn
> };
>
> -    /* Check that there's space on the ring for this request */
> -    if ( mem_event_check_ring(d, &d->mem_event->paging) == 0)
> -    {
> -        /* Send release notification to pager */
> -        memset(&req, 0, sizeof(req));
> -        req.flags |= MEM_EVENT_FLAG_DROP_PAGE;
> -        req.gfn = gfn;
> -        req.vcpu_id = v->vcpu_id;
> +    /* Send release notification to pager */
> +    req.flags = MEM_EVENT_FLAG_DROP_PAGE;
>
> -        mem_event_put_request(d, &d->mem_event->paging, &req);
> -    }
> +    mem_event_put_request(d, &d->mem_event->paging, &req);
>  }
>
>  /**
> @@ -908,7 +900,7 @@ void p2m_mem_paging_populate(struct doma
>      struct p2m_domain *p2m = p2m_get_hostp2m(d);
>
>      /* Check that there's space on the ring for this request */
> -    if ( mem_event_check_ring(d, &d->mem_event->paging) )
> +    if ( mem_event_claim_slot(d, &d->mem_event->paging) )
>          return;
>
>      memset(&req, 0, sizeof(req));
> @@ -938,7 +930,7 @@ void p2m_mem_paging_populate(struct doma
>      else if ( p2mt != p2m_ram_paging_out && p2mt != p2m_ram_paged )
>      {
>          /* gfn is already on its way back and vcpu is not paused */
> -        mem_event_put_req_producers(&d->mem_event->paging);
> +        mem_event_release_slot(d, &d->mem_event->paging);
>          return;
>      }
>
> @@ -1080,8 +1072,8 @@ void p2m_mem_paging_resume(struct domain
>              vcpu_unpause(d->vcpu[rsp.vcpu_id]);
>      }
>
> -    /* Unpause any domains that were paused because the ring was full */
> -    mem_event_unpause_vcpus(d);
> +    /* Wake vcpus waiting for room in the ring */
> +    mem_event_wake_requesters(&d->mem_event->paging);
>  }
>
>  bool_t p2m_mem_access_check(unsigned long gpa, bool_t gla_valid, unsigned
> long gla,
> @@ -1115,7 +1107,7 @@ bool_t p2m_mem_access_check(unsigned lon
>      p2m_unlock(p2m);
>
>      /* Otherwise, check if there is a memory event listener, and send the
> message along */
> -    res = mem_event_check_ring(d, &d->mem_event->access);
> +    res = mem_event_claim_slot(d, &d->mem_event->access);
>      if ( res < 0 )
>      {
>          /* No listener */
> @@ -1125,7 +1117,7 @@ bool_t p2m_mem_access_check(unsigned lon
>                     "Memory access permissions failure, no mem_event
> listener: pausing VCPU %d, dom %d\n",
>                     v->vcpu_id, d->domain_id);
>
> -            mem_event_mark_and_pause(v);
> +            mem_event_mark_and_sleep(v, &d->mem_event->access);
>          }
>          else
>          {
> @@ -1186,9 +1178,11 @@ void p2m_mem_access_resume(struct domain
>              vcpu_unpause(d->vcpu[rsp.vcpu_id]);
>      }
>
> -    /* Unpause any domains that were paused because the ring was full or
> no listener
> -     * was available */
> -    mem_event_unpause_vcpus(d);
> +    /* Wake vcpus waiting for room in the ring */
> +    mem_event_wake_requesters(&d->mem_event->access);
> +
> +    /* Unpause all vcpus that were paused because no listener was
> available */
> +    mem_event_wake_waiters(d, &d->mem_event->access);
>  }
>
>
> diff -r 1c58bb664d8d -r b25b2bcc2c6a xen/include/asm-x86/mem_event.h
> --- a/xen/include/asm-x86/mem_event.h
> +++ b/xen/include/asm-x86/mem_event.h
> @@ -24,13 +24,13 @@
>  #ifndef __MEM_EVENT_H__
>  #define __MEM_EVENT_H__
>
> -/* Pauses VCPU while marking pause flag for mem event */
> -void mem_event_mark_and_pause(struct vcpu *v);
> -int mem_event_check_ring(struct domain *d, struct mem_event_domain *med);
> -void mem_event_put_req_producers(struct mem_event_domain *med);
> +int mem_event_claim_slot(struct domain *d, struct mem_event_domain *med);
> +void mem_event_release_slot(struct domain *d, struct mem_event_domain
> *med);
>  void mem_event_put_request(struct domain *d, struct mem_event_domain
> *med, mem_event_request_t *req);
>  int mem_event_get_response(struct mem_event_domain *med,
> mem_event_response_t *rsp);
> -void mem_event_unpause_vcpus(struct domain *d);
> +void mem_event_wake_requesters(struct mem_event_domain *med);
> +void mem_event_wake_waiters(struct domain *d, struct mem_event_domain
> *med);
> +void mem_event_mark_and_sleep(struct vcpu *v, struct mem_event_domain
> *med);
>
>  int mem_event_domctl(struct domain *d, xen_domctl_mem_event_op_t *mec,
>                       XEN_GUEST_HANDLE(void) u_domctl);
> diff -r 1c58bb664d8d -r b25b2bcc2c6a xen/include/xen/sched.h
> --- a/xen/include/xen/sched.h
> +++ b/xen/include/xen/sched.h
> @@ -14,6 +14,7 @@
>  #include <xen/nodemask.h>
>  #include <xen/radix-tree.h>
>  #include <xen/multicall.h>
> +#include <xen/wait.h>
>  #include <public/xen.h>
>  #include <public/domctl.h>
>  #include <public/sysctl.h>
> @@ -183,7 +184,8 @@ struct mem_event_domain
>  {
>      /* ring lock */
>      spinlock_t ring_lock;
> -    unsigned int req_producers;
> +    unsigned short foreign_producers;
> +    unsigned short target_producers;
>      /* shared page */
>      mem_event_shared_page_t *shared_page;
>      /* shared ring page */
> @@ -192,6 +194,10 @@ struct mem_event_domain
>      mem_event_front_ring_t front_ring;
>      /* event channel port (vcpu0 only) */
>      int xen_port;
> +    /* mem_event bit for vcpu->pause_flags */
> +    int pause_flag;
> +    /* list of vcpus waiting for room in the ring */
> +    struct waitqueue_head wq;
>  };
>
>  struct mem_event_per_domain
> @@ -615,9 +621,12 @@ static inline struct domain *next_domain
>   /* VCPU affinity has changed: migrating to a new CPU. */
>  #define _VPF_migrating       3
>  #define VPF_migrating        (1UL<<_VPF_migrating)
> - /* VCPU is blocked on memory-event ring. */
> -#define _VPF_mem_event       4
> -#define VPF_mem_event        (1UL<<_VPF_mem_event)
> + /* VCPU is blocked due to missing mem_paging ring. */
> +#define _VPF_mem_paging      4
> +#define VPF_mem_paging       (1UL<<_VPF_mem_paging)
> + /* VCPU is blocked due to missing mem_access ring. */
> +#define _VPF_mem_access      5
> +#define VPF_mem_access       (1UL<<_VPF_mem_access)
>
>  static inline int vcpu_runnable(struct vcpu *v)
>  {
>
>
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Dec 10 06:43:37 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 10 Dec 2011 06: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.xensource.com>)
	id 1RZGdE-0005uO-00; Sat, 10 Dec 2011 06:42:00 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RZGdC-0005uF-3t
	for xen-devel@lists.xensource.com; Sat, 10 Dec 2011 06:41:58 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1323499266!6656092!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDMwNg==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6159 invoked from network); 10 Dec 2011 06:41:06 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Dec 2011 06:41:06 -0000
X-IronPort-AV: E=Sophos;i="4.71,331,1320624000"; 
   d="scan'208";a="9395760"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Dec 2011 06:41:05 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sat, 10 Dec 2011 06:41:05 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RZGcL-0006Xg-25;
	Sat, 10 Dec 2011 06:41:05 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RZGcK-0006Ej-UJ;
	Sat, 10 Dec 2011 06:41:04 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10471-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 10 Dec 2011 06:41:04 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10471: FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10471 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10471/

Failures and problems with tests :-(

Tests which did not succeed and are blocking:
 test-amd64-i386-rhel6hvm-intel  3 host-install(3)              broken in 10460
 test-i386-i386-pv             3 host-install(3)              broken   in 10460
 test-amd64-amd64-xl-sedf      3 host-install(3)              broken   in 10460

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-win-vcpus1  7 windows-install            fail pass in 10460
 test-amd64-i386-win-vcpus1    7 windows-install    fail in 10460 pass in 10471
 test-amd64-amd64-xl-win       7 windows-install    fail in 10460 pass in 10471
 test-i386-i386-xl-win         7 windows-install    fail in 10460 pass in 10471

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-i386-i386-xl-winxpsp3    7 windows-install              fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install          fail never pass
 test-amd64-i386-xl-win7-amd64  7 windows-install              fail  never pass
 test-amd64-i386-xend-winxpsp3  7 windows-install              fail  never pass
 test-amd64-amd64-xl-win7-amd64  7 windows-install              fail never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop           fail in 10460 never pass

version targeted for testing:
 xen                  1c58bb664d8d
baseline version:
 xen                  62ff6a318c5d

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scanneel.ca>
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Andres Lagar-Cavilla <andres@lagarcavilla>
  Andrew Cooper <andrew.cooper3@citrix.com>
  Anthony PERARD <anthony.perard@citrix.com>
  Brendan Cully <brendan@cs.ubc.ca>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Haitao Shan <haitao.shan@intel.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@novell.com>
  Jan Beulich <jbeulich@suse.com>
  Jonathan Davies <jonathan.davies@citrix.com>
  juergen.gross@ts.fujitsu.com
  Keir Fraser <keir@xen.org>
  Liu, Jinsong <jinsong.liu@intel.com>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
  Philipp Hahn <hahn@univention.de>
  Shriram Rajagopalan <rshriram@cs.ubc.ca>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang2 <wei.wang2@amd.com>
  Xudong Hao <xudong.hao@intel.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 1522 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Dec 10 06:43:37 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 10 Dec 2011 06: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.xensource.com>)
	id 1RZGdE-0005uO-00; Sat, 10 Dec 2011 06:42:00 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RZGdC-0005uF-3t
	for xen-devel@lists.xensource.com; Sat, 10 Dec 2011 06:41:58 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1323499266!6656092!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDMwNg==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6159 invoked from network); 10 Dec 2011 06:41:06 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Dec 2011 06:41:06 -0000
X-IronPort-AV: E=Sophos;i="4.71,331,1320624000"; 
   d="scan'208";a="9395760"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Dec 2011 06:41:05 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sat, 10 Dec 2011 06:41:05 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RZGcL-0006Xg-25;
	Sat, 10 Dec 2011 06:41:05 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RZGcK-0006Ej-UJ;
	Sat, 10 Dec 2011 06:41:04 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10471-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 10 Dec 2011 06:41:04 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10471: FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10471 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10471/

Failures and problems with tests :-(

Tests which did not succeed and are blocking:
 test-amd64-i386-rhel6hvm-intel  3 host-install(3)              broken in 10460
 test-i386-i386-pv             3 host-install(3)              broken   in 10460
 test-amd64-amd64-xl-sedf      3 host-install(3)              broken   in 10460

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-win-vcpus1  7 windows-install            fail pass in 10460
 test-amd64-i386-win-vcpus1    7 windows-install    fail in 10460 pass in 10471
 test-amd64-amd64-xl-win       7 windows-install    fail in 10460 pass in 10471
 test-i386-i386-xl-win         7 windows-install    fail in 10460 pass in 10471

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-i386-i386-xl-winxpsp3    7 windows-install              fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install          fail never pass
 test-amd64-i386-xl-win7-amd64  7 windows-install              fail  never pass
 test-amd64-i386-xend-winxpsp3  7 windows-install              fail  never pass
 test-amd64-amd64-xl-win7-amd64  7 windows-install              fail never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop           fail in 10460 never pass

version targeted for testing:
 xen                  1c58bb664d8d
baseline version:
 xen                  62ff6a318c5d

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scanneel.ca>
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Andres Lagar-Cavilla <andres@lagarcavilla>
  Andrew Cooper <andrew.cooper3@citrix.com>
  Anthony PERARD <anthony.perard@citrix.com>
  Brendan Cully <brendan@cs.ubc.ca>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Haitao Shan <haitao.shan@intel.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@novell.com>
  Jan Beulich <jbeulich@suse.com>
  Jonathan Davies <jonathan.davies@citrix.com>
  juergen.gross@ts.fujitsu.com
  Keir Fraser <keir@xen.org>
  Liu, Jinsong <jinsong.liu@intel.com>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
  Philipp Hahn <hahn@univention.de>
  Shriram Rajagopalan <rshriram@cs.ubc.ca>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang2 <wei.wang2@amd.com>
  Xudong Hao <xudong.hao@intel.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 1522 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Dec 10 08:13:53 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 10 Dec 2011 08:13:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZI3W-0007Z7-Ch; Sat, 10 Dec 2011 08:13:14 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <sythrar@gmail.com>) id 1RZI3U-0007Z2-Mi
	for xen-devel@lists.xensource.com; Sat, 10 Dec 2011 08:13:12 +0000
X-Env-Sender: sythrar@gmail.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1323504741!6839883!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26651 invoked from network); 10 Dec 2011 08:12:22 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-11.tower-216.messagelabs.com with AES256-SHA encrypted SMTP;
	10 Dec 2011 08:12:22 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <sythrar@gmail.com>) id 1RZI2e-0005q4-G9
	for xen-devel@lists.xensource.com; Sat, 10 Dec 2011 00:12:20 -0800
Date: Sat, 10 Dec 2011 00:12:20 -0800 (PST)
From: Sythrar <sythrar@gmail.com>
To: xen-devel@lists.xensource.com
Message-ID: <1323504740494-5063848.post@n5.nabble.com>
In-Reply-To: <1323170568.90631.YahooMailNeo@web29813.mail.ird.yahoo.com>
References: <1316777654598-4833174.post@n5.nabble.com>
	<1316786412428-4833637.post@n5.nabble.com>
	<20110923172115.GI12984@reaktio.net>
	<1318672856439-4904945.post@n5.nabble.com>
	<1319630071722-4939528.post@n5.nabble.com>
	<1319636130.20499.YahooMailNeo@web29808.mail.ird.yahoo.com>
	<1319695116310-4942047.post@n5.nabble.com>
	<1319710499.206.YahooMailNeo@web29804.mail.ird.yahoo.com>
	<1323123990448-5050354.post@n5.nabble.com>
	<1323170568.90631.YahooMailNeo@web29813.mail.ird.yahoo.com>
MIME-Version: 1.0
Subject: Re: [Xen-devel] Re : Re : Re : Re : Re : Re : Re : Re: Patches for
 VGA-Passthrough XEN 4.2 unstable
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

n4rC0t1C, DomU VNC you tested with, if so, has good performance in game? 

--
View this message in context: http://xen.1045712.n5.nabble.com/Patches-for-VGA-Passthrough-XEN-4-2-unstable-tp4406265p5063848.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Dec 10 08:13:53 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 10 Dec 2011 08:13:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZI3W-0007Z7-Ch; Sat, 10 Dec 2011 08:13:14 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <sythrar@gmail.com>) id 1RZI3U-0007Z2-Mi
	for xen-devel@lists.xensource.com; Sat, 10 Dec 2011 08:13:12 +0000
X-Env-Sender: sythrar@gmail.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1323504741!6839883!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26651 invoked from network); 10 Dec 2011 08:12:22 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-11.tower-216.messagelabs.com with AES256-SHA encrypted SMTP;
	10 Dec 2011 08:12:22 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <sythrar@gmail.com>) id 1RZI2e-0005q4-G9
	for xen-devel@lists.xensource.com; Sat, 10 Dec 2011 00:12:20 -0800
Date: Sat, 10 Dec 2011 00:12:20 -0800 (PST)
From: Sythrar <sythrar@gmail.com>
To: xen-devel@lists.xensource.com
Message-ID: <1323504740494-5063848.post@n5.nabble.com>
In-Reply-To: <1323170568.90631.YahooMailNeo@web29813.mail.ird.yahoo.com>
References: <1316777654598-4833174.post@n5.nabble.com>
	<1316786412428-4833637.post@n5.nabble.com>
	<20110923172115.GI12984@reaktio.net>
	<1318672856439-4904945.post@n5.nabble.com>
	<1319630071722-4939528.post@n5.nabble.com>
	<1319636130.20499.YahooMailNeo@web29808.mail.ird.yahoo.com>
	<1319695116310-4942047.post@n5.nabble.com>
	<1319710499.206.YahooMailNeo@web29804.mail.ird.yahoo.com>
	<1323123990448-5050354.post@n5.nabble.com>
	<1323170568.90631.YahooMailNeo@web29813.mail.ird.yahoo.com>
MIME-Version: 1.0
Subject: Re: [Xen-devel] Re : Re : Re : Re : Re : Re : Re : Re: Patches for
 VGA-Passthrough XEN 4.2 unstable
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

n4rC0t1C, DomU VNC you tested with, if so, has good performance in game? 

--
View this message in context: http://xen.1045712.n5.nabble.com/Patches-for-VGA-Passthrough-XEN-4-2-unstable-tp4406265p5063848.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Dec 10 09:29:19 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 10 Dec 2011 09: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.xensource.com>)
	id 1RZJEW-0000Of-IS; Sat, 10 Dec 2011 09:28:40 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RZJEU-0000OX-Tc
	for xen-devel@lists.xensource.com; Sat, 10 Dec 2011 09:28:39 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1323509268!4818617!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDMwNg==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18962 invoked from network); 10 Dec 2011 09:27:48 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Dec 2011 09:27:48 -0000
X-IronPort-AV: E=Sophos;i="4.71,331,1320624000"; 
   d="scan'208";a="9396665"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Dec 2011 09:27:47 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sat, 10 Dec 2011 09:27:47 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RZJDe-0007S5-4w;
	Sat, 10 Dec 2011 09:27:46 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RZJDe-0005LS-0J;
	Sat, 10 Dec 2011 09:27:46 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10472-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 10 Dec 2011 09:27:46 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10472: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10472 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10472/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf     14 guest-localmigrate/x10      fail pass in 10471
 test-amd64-i386-xl-win-vcpus1  7 windows-install   fail in 10471 pass in 10472

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-i386-i386-xl-winxpsp3    7 windows-install              fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install          fail never pass
 test-amd64-i386-xl-win7-amd64  7 windows-install              fail  never pass
 test-amd64-i386-xend-winxpsp3  7 windows-install              fail  never pass
 test-amd64-amd64-xl-win7-amd64  7 windows-install              fail never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  1c58bb664d8d
baseline version:
 xen                  62ff6a318c5d

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scanneel.ca>
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Andres Lagar-Cavilla <andres@lagarcavilla>
  Andrew Cooper <andrew.cooper3@citrix.com>
  Anthony PERARD <anthony.perard@citrix.com>
  Brendan Cully <brendan@cs.ubc.ca>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Haitao Shan <haitao.shan@intel.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@novell.com>
  Jan Beulich <jbeulich@suse.com>
  Jonathan Davies <jonathan.davies@citrix.com>
  juergen.gross@ts.fujitsu.com
  Keir Fraser <keir@xen.org>
  Liu, Jinsong <jinsong.liu@intel.com>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
  Philipp Hahn <hahn@univention.de>
  Shriram Rajagopalan <rshriram@cs.ubc.ca>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang2 <wei.wang2@amd.com>
  Xudong Hao <xudong.hao@intel.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-unstable
+ revision=1c58bb664d8d
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-unstable 1c58bb664d8d
+ branch=xen-unstable
+ revision=1c58bb664d8d
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ : xen@xenbits.xensource.com
+ : xen@xenbits.xensource.com:git/linux-pvops
+ : master
+ : tested/2.6.39.x
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r 1c58bb664d8d ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 100 changesets with 239 changes to 121 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Dec 10 09:29:19 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 10 Dec 2011 09: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.xensource.com>)
	id 1RZJEW-0000Of-IS; Sat, 10 Dec 2011 09:28:40 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RZJEU-0000OX-Tc
	for xen-devel@lists.xensource.com; Sat, 10 Dec 2011 09:28:39 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1323509268!4818617!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDMwNg==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18962 invoked from network); 10 Dec 2011 09:27:48 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Dec 2011 09:27:48 -0000
X-IronPort-AV: E=Sophos;i="4.71,331,1320624000"; 
   d="scan'208";a="9396665"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Dec 2011 09:27:47 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sat, 10 Dec 2011 09:27:47 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RZJDe-0007S5-4w;
	Sat, 10 Dec 2011 09:27:46 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RZJDe-0005LS-0J;
	Sat, 10 Dec 2011 09:27:46 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10472-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 10 Dec 2011 09:27:46 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10472: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10472 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10472/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf     14 guest-localmigrate/x10      fail pass in 10471
 test-amd64-i386-xl-win-vcpus1  7 windows-install   fail in 10471 pass in 10472

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-i386-i386-xl-winxpsp3    7 windows-install              fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install          fail never pass
 test-amd64-i386-xl-win7-amd64  7 windows-install              fail  never pass
 test-amd64-i386-xend-winxpsp3  7 windows-install              fail  never pass
 test-amd64-amd64-xl-win7-amd64  7 windows-install              fail never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  1c58bb664d8d
baseline version:
 xen                  62ff6a318c5d

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scanneel.ca>
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Andres Lagar-Cavilla <andres@lagarcavilla>
  Andrew Cooper <andrew.cooper3@citrix.com>
  Anthony PERARD <anthony.perard@citrix.com>
  Brendan Cully <brendan@cs.ubc.ca>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Haitao Shan <haitao.shan@intel.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@novell.com>
  Jan Beulich <jbeulich@suse.com>
  Jonathan Davies <jonathan.davies@citrix.com>
  juergen.gross@ts.fujitsu.com
  Keir Fraser <keir@xen.org>
  Liu, Jinsong <jinsong.liu@intel.com>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
  Philipp Hahn <hahn@univention.de>
  Shriram Rajagopalan <rshriram@cs.ubc.ca>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang2 <wei.wang2@amd.com>
  Xudong Hao <xudong.hao@intel.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-unstable
+ revision=1c58bb664d8d
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-unstable 1c58bb664d8d
+ branch=xen-unstable
+ revision=1c58bb664d8d
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ : xen@xenbits.xensource.com
+ : xen@xenbits.xensource.com:git/linux-pvops
+ : master
+ : tested/2.6.39.x
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r 1c58bb664d8d ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 100 changesets with 239 changes to 121 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Dec 10 09:55:37 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 10 Dec 2011 09:55:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZJeA-0002TU-DG; Sat, 10 Dec 2011 09:55:10 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <hn_nemati1985@yahoo.com>) id 1RZJe8-0002TA-QO
	for xen-devel@lists.xensource.com; Sat, 10 Dec 2011 09:55:09 +0000
X-Env-Sender: hn_nemati1985@yahoo.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1323510857!6805120!1
X-Originating-IP: [98.139.213.140]
X-SpamReason: No, hits=0.7 required=7.0 tests=FROM_HAS_ULINE_NUMS,
	HTML_MESSAGE, ML_RADAR_SPEW_LINKS_12, ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11949 invoked from network); 10 Dec 2011 09:54:18 -0000
Received: from nm12-vm0.bullet.mail.bf1.yahoo.com (HELO
	nm12-vm0.bullet.mail.bf1.yahoo.com) (98.139.213.140)
	by server-10.tower-216.messagelabs.com with SMTP;
	10 Dec 2011 09:54:18 -0000
Received: from [98.139.212.149] by nm12.bullet.mail.bf1.yahoo.com with NNFMP;
	10 Dec 2011 09:54:17 -0000
Received: from [98.139.212.229] by tm6.bullet.mail.bf1.yahoo.com with NNFMP;
	10 Dec 2011 09:54:17 -0000
Received: from [127.0.0.1] by omp1038.mail.bf1.yahoo.com with NNFMP;
	10 Dec 2011 09:54:17 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 518434.42681.bm@omp1038.mail.bf1.yahoo.com
Received: (qmail 14639 invoked by uid 60001); 10 Dec 2011 09:54:17 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024;
	t=1323510857; bh=HOuZRRtOsfQY33j8+vf3N3tGWlrMOdXbWgC3ty6x0s4=;
	h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type;
	b=wEhCFC27yDP+jrmZIS5XXUmuwJCWKRQXsStsmMOCKdYkpH4i3EnISNZKJRrWoGT8vBaZuFaToNJRnXKDfmFanpPD3rMjjO+tBG0Myk1FHI+ouOhA7sUzp8w8AOF2/aC717MtFgxTRZxNIWCUIl98ZREVgMpp0u5wI+Cv7dEg3Yg=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com;
	h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type;
	b=mVCvFD1QzJfrbadRnUxAnXglJzWN83Dg0ZsRjRwtGbbEOmSJZmdMLq432IosZEc9cJdKlJYtGiEukPyQ/l4JpGVgEWYi/rAxsx7Ooa3ELcPFmoOMC9UBKBOErMUUNUQUlEvXMdV/PjdYf0GBxouSEVINl6MqtNnwcWMCOnQDT44=;
X-YMail-OSG: Fr8Z7SEVM1koYUAHGCB01Ubokk4cF1nh2izF_JPL1sf8B9N
	EBya47.b4dC0xv3LzLEqCa.0igJmqnc3BtVl_TpwiTVlP31vhkuegN223GIK
	kEAFHncnmB_WTV9sbCcP6v9M7Hq9xQxPYm8R1uP52Jey86W196ZpEumFda8S
	hjAi20WEUoFuU5J5ZolqdXTjS0tmXYJZ0ca6O6U5MW0RC6vqsX_2KCP6vVTM
	WwAxp4NWfbbodrblfSn0XJpHtzfFHFtF.l.lldtfGKUmD6JMe62v4clo_Emm
	7wbwUmrWTEpFU9Oyn7Pb_HkRn191UacKO4j2T6RVx_TzWQNoby8N1NRmMpM.
	ZJWqqFO8NCEZ4qQt9Z5Ytd.U23KWlua.Ix.ILlmTuWlRR8tWf.9wGH6VvYcA
	i2TdmRy5X82P1ksn0CMyV1Xa0vhs4oh3J_F5OMB2B62.WLuk-
Received: from [76.73.45.34] by web160903.mail.bf1.yahoo.com via HTTP;
	Sat, 10 Dec 2011 01:54:17 PST
X-Mailer: YahooMailClassic/15.0.4 YahooMailWebService/0.8.115.331698
Message-ID: <1323510857.14508.YahooMailClassic@web160903.mail.bf1.yahoo.com>
Date: Sat, 10 Dec 2011 01:54:17 -0800 (PST)
From: jack nemati <hn_nemati1985@yahoo.com>
To: xen-devel@lists.xensource.com
MIME-Version: 1.0
Subject: [Xen-devel] Xen shadow page table
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============5873174796902806872=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============5873174796902806872==
Content-Type: multipart/alternative; boundary="980202461-1647533472-1323510857=:14508"

--980202461-1647533472-1323510857=:14508
Content-Type: text/plain; charset=us-ascii

Dear friends,

I'm working on Xen's Dom0, my question is how we can enable the shadow page table or hardware assistant page table for it (the Dom0). Thanks in advance.

Regards
--980202461-1647533472-1323510857=:14508
Content-Type: text/html; charset=us-ascii

<table cellspacing="0" cellpadding="0" border="0" ><tr><td valign="top" style="font: inherit;"><span class="Apple-style-span" style="color: rgb(0, 0, 0); font-family: Verdana,Arial,Helvetica,sans-serif; font-size: 13px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; background-color: rgb(255, 255, 255);">Dear friends,<br><br>I'm working on Xen's Dom0, my question is how we can enable the shadow page table or hardware assistant page table for it (the Dom0). Thanks in advance.<br><br>Regards</span></td></tr></table>
--980202461-1647533472-1323510857=:14508--


--===============5873174796902806872==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============5873174796902806872==--


From xen-devel-bounces@lists.xensource.com Sat Dec 10 09:55:37 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 10 Dec 2011 09:55:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZJeA-0002TU-DG; Sat, 10 Dec 2011 09:55:10 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <hn_nemati1985@yahoo.com>) id 1RZJe8-0002TA-QO
	for xen-devel@lists.xensource.com; Sat, 10 Dec 2011 09:55:09 +0000
X-Env-Sender: hn_nemati1985@yahoo.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1323510857!6805120!1
X-Originating-IP: [98.139.213.140]
X-SpamReason: No, hits=0.7 required=7.0 tests=FROM_HAS_ULINE_NUMS,
	HTML_MESSAGE, ML_RADAR_SPEW_LINKS_12, ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11949 invoked from network); 10 Dec 2011 09:54:18 -0000
Received: from nm12-vm0.bullet.mail.bf1.yahoo.com (HELO
	nm12-vm0.bullet.mail.bf1.yahoo.com) (98.139.213.140)
	by server-10.tower-216.messagelabs.com with SMTP;
	10 Dec 2011 09:54:18 -0000
Received: from [98.139.212.149] by nm12.bullet.mail.bf1.yahoo.com with NNFMP;
	10 Dec 2011 09:54:17 -0000
Received: from [98.139.212.229] by tm6.bullet.mail.bf1.yahoo.com with NNFMP;
	10 Dec 2011 09:54:17 -0000
Received: from [127.0.0.1] by omp1038.mail.bf1.yahoo.com with NNFMP;
	10 Dec 2011 09:54:17 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 518434.42681.bm@omp1038.mail.bf1.yahoo.com
Received: (qmail 14639 invoked by uid 60001); 10 Dec 2011 09:54:17 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024;
	t=1323510857; bh=HOuZRRtOsfQY33j8+vf3N3tGWlrMOdXbWgC3ty6x0s4=;
	h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type;
	b=wEhCFC27yDP+jrmZIS5XXUmuwJCWKRQXsStsmMOCKdYkpH4i3EnISNZKJRrWoGT8vBaZuFaToNJRnXKDfmFanpPD3rMjjO+tBG0Myk1FHI+ouOhA7sUzp8w8AOF2/aC717MtFgxTRZxNIWCUIl98ZREVgMpp0u5wI+Cv7dEg3Yg=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com;
	h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type;
	b=mVCvFD1QzJfrbadRnUxAnXglJzWN83Dg0ZsRjRwtGbbEOmSJZmdMLq432IosZEc9cJdKlJYtGiEukPyQ/l4JpGVgEWYi/rAxsx7Ooa3ELcPFmoOMC9UBKBOErMUUNUQUlEvXMdV/PjdYf0GBxouSEVINl6MqtNnwcWMCOnQDT44=;
X-YMail-OSG: Fr8Z7SEVM1koYUAHGCB01Ubokk4cF1nh2izF_JPL1sf8B9N
	EBya47.b4dC0xv3LzLEqCa.0igJmqnc3BtVl_TpwiTVlP31vhkuegN223GIK
	kEAFHncnmB_WTV9sbCcP6v9M7Hq9xQxPYm8R1uP52Jey86W196ZpEumFda8S
	hjAi20WEUoFuU5J5ZolqdXTjS0tmXYJZ0ca6O6U5MW0RC6vqsX_2KCP6vVTM
	WwAxp4NWfbbodrblfSn0XJpHtzfFHFtF.l.lldtfGKUmD6JMe62v4clo_Emm
	7wbwUmrWTEpFU9Oyn7Pb_HkRn191UacKO4j2T6RVx_TzWQNoby8N1NRmMpM.
	ZJWqqFO8NCEZ4qQt9Z5Ytd.U23KWlua.Ix.ILlmTuWlRR8tWf.9wGH6VvYcA
	i2TdmRy5X82P1ksn0CMyV1Xa0vhs4oh3J_F5OMB2B62.WLuk-
Received: from [76.73.45.34] by web160903.mail.bf1.yahoo.com via HTTP;
	Sat, 10 Dec 2011 01:54:17 PST
X-Mailer: YahooMailClassic/15.0.4 YahooMailWebService/0.8.115.331698
Message-ID: <1323510857.14508.YahooMailClassic@web160903.mail.bf1.yahoo.com>
Date: Sat, 10 Dec 2011 01:54:17 -0800 (PST)
From: jack nemati <hn_nemati1985@yahoo.com>
To: xen-devel@lists.xensource.com
MIME-Version: 1.0
Subject: [Xen-devel] Xen shadow page table
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============5873174796902806872=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============5873174796902806872==
Content-Type: multipart/alternative; boundary="980202461-1647533472-1323510857=:14508"

--980202461-1647533472-1323510857=:14508
Content-Type: text/plain; charset=us-ascii

Dear friends,

I'm working on Xen's Dom0, my question is how we can enable the shadow page table or hardware assistant page table for it (the Dom0). Thanks in advance.

Regards
--980202461-1647533472-1323510857=:14508
Content-Type: text/html; charset=us-ascii

<table cellspacing="0" cellpadding="0" border="0" ><tr><td valign="top" style="font: inherit;"><span class="Apple-style-span" style="color: rgb(0, 0, 0); font-family: Verdana,Arial,Helvetica,sans-serif; font-size: 13px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; background-color: rgb(255, 255, 255);">Dear friends,<br><br>I'm working on Xen's Dom0, my question is how we can enable the shadow page table or hardware assistant page table for it (the Dom0). Thanks in advance.<br><br>Regards</span></td></tr></table>
--980202461-1647533472-1323510857=:14508--


--===============5873174796902806872==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============5873174796902806872==--


From xen-devel-bounces@lists.xensource.com Sat Dec 10 10:46:40 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 10 Dec 2011 10:46:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZKRO-0005Ju-Qa; Sat, 10 Dec 2011 10:46:02 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jan.kiszka@web.de>) id 1RZKRM-0005Jp-RF
	for xen-devel@lists.xensource.com; Sat, 10 Dec 2011 10:46:01 +0000
X-Env-Sender: jan.kiszka@web.de
X-Msg-Ref: server-15.tower-182.messagelabs.com!1323513909!6612760!1
X-Originating-IP: [217.72.192.221]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMTcuNzIuMTkyLjIyMSA9PiA4NjI2\n,sa_preprocessor: 
	QmFkIElQOiAyMTcuNzIuMTkyLjIyMSA9PiA4NjI2\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16788 invoked from network); 10 Dec 2011 10:45:09 -0000
Received: from fmmailgate01.web.de (HELO fmmailgate01.web.de) (217.72.192.221)
	by server-15.tower-182.messagelabs.com with SMTP;
	10 Dec 2011 10:45:09 -0000
Received: from moweb001.kundenserver.de (moweb001.kundenserver.de
	[172.19.20.114])
	by fmmailgate01.web.de (Postfix) with ESMTP id 42D1B1A43F42F
	for <xen-devel@lists.xensource.com>;
	Sat, 10 Dec 2011 11:45:09 +0100 (CET)
Received: from mchn199C.mchp.siemens.de ([88.64.22.151]) by smtp.web.de
	(mrweb002) with ESMTPA (Nemesis) id 0MbQbk-1RIu2R0WJg-00Ihvp;
	Sat, 10 Dec 2011 11:45:07 +0100
Message-ID: <4EE3382D.80903@web.de>
Date: Sat, 10 Dec 2011 11:45:01 +0100
From: Jan Kiszka <jan.kiszka@web.de>
User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de;
	rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12
	Mnenhy/0.7.5.666
MIME-Version: 1.0
To: Anthony PERARD <anthony.perard@citrix.com>
References: <1323467645-24271-1-git-send-email-anthony.perard@citrix.com>
	<1323467645-24271-6-git-send-email-anthony.perard@citrix.com>
In-Reply-To: <1323467645-24271-6-git-send-email-anthony.perard@citrix.com>
X-Enigmail-Version: 1.3.3
X-Provags-ID: V02:K0:eurNX+E34bpg0IK83+6F7l0vSf3/X6Lcgtu01qxzhcG
	eeMPSH4vjEUkHZOeMwaNO8Ft49VwzlwKUF4f2M5qJdgraHr4h3
	+T8mxaoGBb9s7RYwp9kWxqH+WieVMWf64DdLOZ7dgIZi/Xd1ld
	JOTHh/SC1Pb3ogJvu9ip5N1yM1ZrMzZBZ8MPkIk09wsBctetKb
	Y+U8hw7CZZLhXnvzR6u/Q==
Cc: Xen Devel <xen-devel@lists.xensource.com>,
	QEMU-devel <qemu-devel@nongnu.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH V2 5/5] vga-cirrus: Workaround during
 restore when using Xen.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============5676172799192526696=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--===============5676172799192526696==
Content-Type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature";
 boundary="------------enig08CBD72951CA10E90D48A03B"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig08CBD72951CA10E90D48A03B
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 2011-12-09 22:54, Anthony PERARD wrote:
> During the initialisation of the machine at restore time, the access to=
 the
> VRAM will fail because QEMU does not know yet the right guest address t=
o map,
> so the vram_ptr is NULL.
>=20
> So this patch avoid using a NULL pointer during initialisation, and try=
 to get
> another vram_ptr if the call failed the first time.
>=20
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> ---
>  hw/cirrus_vga.c |   16 +++++++++++++---
>  1 files changed, 13 insertions(+), 3 deletions(-)
>=20
> diff --git a/hw/cirrus_vga.c b/hw/cirrus_vga.c
> index c7e365b..2e049c9 100644
> --- a/hw/cirrus_vga.c
> +++ b/hw/cirrus_vga.c
> @@ -32,6 +32,7 @@
>  #include "console.h"
>  #include "vga_int.h"
>  #include "loader.h"
> +#include "sysemu.h"
> =20
>  /*
>   * TODO:
> @@ -2696,6 +2697,13 @@ static int cirrus_post_load(void *opaque, int ve=
rsion_id)
>      s->vga.gr[0x01] =3D s->cirrus_shadow_gr1 & 0x0f;
> =20
>      cirrus_update_memory_access(s);
> +    if (!s->vga.vram_ptr) {
> +        /* At this point vga.vram_ptr can be invalid on Xen because we=
 need to
> +         * know the position of the videoram in the guest physical add=
ress space in
> +         * order to be able to map it. After cirrus_update_memory_acce=
ss we do know
> +         * where the videoram is, so let's map it now. */
> +        s->vga.vram_ptr =3D memory_region_get_ram_ptr(&s->vga.vram);
> +    }
>      /* force refresh */
>      s->vga.graphic_mode =3D -1;
>      cirrus_update_bank_ptr(s, 0);
> @@ -2784,9 +2792,11 @@ static void cirrus_reset(void *opaque)
>      }
>      s->vga.cr[0x27] =3D s->device_id;
> =20
> -    /* Win2K seems to assume that the pattern buffer is at 0xff
> -       initially ! */
> -    memset(s->vga.vram_ptr, 0xff, s->real_vram_size);
> +    if (!runstate_check(RUN_STATE_PREMIGRATE)) {
> +        /* Win2K seems to assume that the pattern buffer is at 0xff
> +           initially ! */
> +        memset(s->vga.vram_ptr, 0xff, s->real_vram_size);
> +    }
> =20
>      s->cirrus_hidden_dac_lockindex =3D 5;
>      s->cirrus_hidden_dac_data =3D 0;

Is there really no way to fix this properly in the Xen layer? This looks
highly fragile as specifically the second hunk appears unrelated to Xen.

Also, is this the only device affected by the shortcoming? What about
other VGA adapters e.g.?

Jan


--------------enig08CBD72951CA10E90D48A03B
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk7jODIACgkQitSsb3rl5xS8+QCdFbSDn7kzL54Agbm65iS/X01a
500AnRozhuTqQ0RYY9tyJWlrQheC6p3K
=YFZ1
-----END PGP SIGNATURE-----

--------------enig08CBD72951CA10E90D48A03B--


--===============5676172799192526696==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============5676172799192526696==--


From xen-devel-bounces@lists.xensource.com Sat Dec 10 10:46:40 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 10 Dec 2011 10:46:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZKRO-0005Ju-Qa; Sat, 10 Dec 2011 10:46:02 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jan.kiszka@web.de>) id 1RZKRM-0005Jp-RF
	for xen-devel@lists.xensource.com; Sat, 10 Dec 2011 10:46:01 +0000
X-Env-Sender: jan.kiszka@web.de
X-Msg-Ref: server-15.tower-182.messagelabs.com!1323513909!6612760!1
X-Originating-IP: [217.72.192.221]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMTcuNzIuMTkyLjIyMSA9PiA4NjI2\n,sa_preprocessor: 
	QmFkIElQOiAyMTcuNzIuMTkyLjIyMSA9PiA4NjI2\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16788 invoked from network); 10 Dec 2011 10:45:09 -0000
Received: from fmmailgate01.web.de (HELO fmmailgate01.web.de) (217.72.192.221)
	by server-15.tower-182.messagelabs.com with SMTP;
	10 Dec 2011 10:45:09 -0000
Received: from moweb001.kundenserver.de (moweb001.kundenserver.de
	[172.19.20.114])
	by fmmailgate01.web.de (Postfix) with ESMTP id 42D1B1A43F42F
	for <xen-devel@lists.xensource.com>;
	Sat, 10 Dec 2011 11:45:09 +0100 (CET)
Received: from mchn199C.mchp.siemens.de ([88.64.22.151]) by smtp.web.de
	(mrweb002) with ESMTPA (Nemesis) id 0MbQbk-1RIu2R0WJg-00Ihvp;
	Sat, 10 Dec 2011 11:45:07 +0100
Message-ID: <4EE3382D.80903@web.de>
Date: Sat, 10 Dec 2011 11:45:01 +0100
From: Jan Kiszka <jan.kiszka@web.de>
User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de;
	rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12
	Mnenhy/0.7.5.666
MIME-Version: 1.0
To: Anthony PERARD <anthony.perard@citrix.com>
References: <1323467645-24271-1-git-send-email-anthony.perard@citrix.com>
	<1323467645-24271-6-git-send-email-anthony.perard@citrix.com>
In-Reply-To: <1323467645-24271-6-git-send-email-anthony.perard@citrix.com>
X-Enigmail-Version: 1.3.3
X-Provags-ID: V02:K0:eurNX+E34bpg0IK83+6F7l0vSf3/X6Lcgtu01qxzhcG
	eeMPSH4vjEUkHZOeMwaNO8Ft49VwzlwKUF4f2M5qJdgraHr4h3
	+T8mxaoGBb9s7RYwp9kWxqH+WieVMWf64DdLOZ7dgIZi/Xd1ld
	JOTHh/SC1Pb3ogJvu9ip5N1yM1ZrMzZBZ8MPkIk09wsBctetKb
	Y+U8hw7CZZLhXnvzR6u/Q==
Cc: Xen Devel <xen-devel@lists.xensource.com>,
	QEMU-devel <qemu-devel@nongnu.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH V2 5/5] vga-cirrus: Workaround during
 restore when using Xen.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============5676172799192526696=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--===============5676172799192526696==
Content-Type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature";
 boundary="------------enig08CBD72951CA10E90D48A03B"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig08CBD72951CA10E90D48A03B
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 2011-12-09 22:54, Anthony PERARD wrote:
> During the initialisation of the machine at restore time, the access to=
 the
> VRAM will fail because QEMU does not know yet the right guest address t=
o map,
> so the vram_ptr is NULL.
>=20
> So this patch avoid using a NULL pointer during initialisation, and try=
 to get
> another vram_ptr if the call failed the first time.
>=20
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> ---
>  hw/cirrus_vga.c |   16 +++++++++++++---
>  1 files changed, 13 insertions(+), 3 deletions(-)
>=20
> diff --git a/hw/cirrus_vga.c b/hw/cirrus_vga.c
> index c7e365b..2e049c9 100644
> --- a/hw/cirrus_vga.c
> +++ b/hw/cirrus_vga.c
> @@ -32,6 +32,7 @@
>  #include "console.h"
>  #include "vga_int.h"
>  #include "loader.h"
> +#include "sysemu.h"
> =20
>  /*
>   * TODO:
> @@ -2696,6 +2697,13 @@ static int cirrus_post_load(void *opaque, int ve=
rsion_id)
>      s->vga.gr[0x01] =3D s->cirrus_shadow_gr1 & 0x0f;
> =20
>      cirrus_update_memory_access(s);
> +    if (!s->vga.vram_ptr) {
> +        /* At this point vga.vram_ptr can be invalid on Xen because we=
 need to
> +         * know the position of the videoram in the guest physical add=
ress space in
> +         * order to be able to map it. After cirrus_update_memory_acce=
ss we do know
> +         * where the videoram is, so let's map it now. */
> +        s->vga.vram_ptr =3D memory_region_get_ram_ptr(&s->vga.vram);
> +    }
>      /* force refresh */
>      s->vga.graphic_mode =3D -1;
>      cirrus_update_bank_ptr(s, 0);
> @@ -2784,9 +2792,11 @@ static void cirrus_reset(void *opaque)
>      }
>      s->vga.cr[0x27] =3D s->device_id;
> =20
> -    /* Win2K seems to assume that the pattern buffer is at 0xff
> -       initially ! */
> -    memset(s->vga.vram_ptr, 0xff, s->real_vram_size);
> +    if (!runstate_check(RUN_STATE_PREMIGRATE)) {
> +        /* Win2K seems to assume that the pattern buffer is at 0xff
> +           initially ! */
> +        memset(s->vga.vram_ptr, 0xff, s->real_vram_size);
> +    }
> =20
>      s->cirrus_hidden_dac_lockindex =3D 5;
>      s->cirrus_hidden_dac_data =3D 0;

Is there really no way to fix this properly in the Xen layer? This looks
highly fragile as specifically the second hunk appears unrelated to Xen.

Also, is this the only device affected by the shortcoming? What about
other VGA adapters e.g.?

Jan


--------------enig08CBD72951CA10E90D48A03B
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk7jODIACgkQitSsb3rl5xS8+QCdFbSDn7kzL54Agbm65iS/X01a
500AnRozhuTqQ0RYY9tyJWlrQheC6p3K
=YFZ1
-----END PGP SIGNATURE-----

--------------enig08CBD72951CA10E90D48A03B--


--===============5676172799192526696==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============5676172799192526696==--


From xen-devel-bounces@lists.xensource.com Sat Dec 10 12:31:46 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 10 Dec 2011 12:31:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZM4l-0006eW-5M; Sat, 10 Dec 2011 12:30:47 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <shandivo@gmail.com>) id 1RZM4j-0006e0-LN
	for xen-devel@lists.xensource.com; Sat, 10 Dec 2011 12:30:46 +0000
X-Env-Sender: shandivo@gmail.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1323520194!5721533!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3658 invoked from network); 10 Dec 2011 12:29:55 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-13.tower-21.messagelabs.com with AES256-SHA encrypted SMTP;
	10 Dec 2011 12:29:55 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <shandivo@gmail.com>) id 1RZM3t-0002wN-Cm
	for xen-devel@lists.xensource.com; Sat, 10 Dec 2011 04:29:53 -0800
Date: Sat, 10 Dec 2011 04:29:53 -0800 (PST)
From: n4rC0t1C <shandivo@gmail.com>
To: xen-devel@lists.xensource.com
Message-ID: <1323520193389-5064245.post@n5.nabble.com>
In-Reply-To: <1323504740494-5063848.post@n5.nabble.com>
References: <1316786412428-4833637.post@n5.nabble.com>
	<20110923172115.GI12984@reaktio.net>
	<1318672856439-4904945.post@n5.nabble.com>
	<1319630071722-4939528.post@n5.nabble.com>
	<1319636130.20499.YahooMailNeo@web29808.mail.ird.yahoo.com>
	<1319695116310-4942047.post@n5.nabble.com>
	<1319710499.206.YahooMailNeo@web29804.mail.ird.yahoo.com>
	<1323123990448-5050354.post@n5.nabble.com>
	<1323170568.90631.YahooMailNeo@web29813.mail.ird.yahoo.com>
	<1323504740494-5063848.post@n5.nabble.com>
MIME-Version: 1.0
Subject: Re: [Xen-devel] Re : Re : Re : Re : Re : Re : Re : Re: Patches for
 VGA-Passthrough XEN 4.2 unstable
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

No vnc, physical DVI screen. And performances are really good, you'll not
notice you're under a domU, especially in 3D games.

--
View this message in context: http://xen.1045712.n5.nabble.com/Patches-for-VGA-Passthrough-XEN-4-2-unstable-tp4406265p5064245.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Dec 10 12:31:46 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 10 Dec 2011 12:31:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZM4l-0006eW-5M; Sat, 10 Dec 2011 12:30:47 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <shandivo@gmail.com>) id 1RZM4j-0006e0-LN
	for xen-devel@lists.xensource.com; Sat, 10 Dec 2011 12:30:46 +0000
X-Env-Sender: shandivo@gmail.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1323520194!5721533!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3658 invoked from network); 10 Dec 2011 12:29:55 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-13.tower-21.messagelabs.com with AES256-SHA encrypted SMTP;
	10 Dec 2011 12:29:55 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <shandivo@gmail.com>) id 1RZM3t-0002wN-Cm
	for xen-devel@lists.xensource.com; Sat, 10 Dec 2011 04:29:53 -0800
Date: Sat, 10 Dec 2011 04:29:53 -0800 (PST)
From: n4rC0t1C <shandivo@gmail.com>
To: xen-devel@lists.xensource.com
Message-ID: <1323520193389-5064245.post@n5.nabble.com>
In-Reply-To: <1323504740494-5063848.post@n5.nabble.com>
References: <1316786412428-4833637.post@n5.nabble.com>
	<20110923172115.GI12984@reaktio.net>
	<1318672856439-4904945.post@n5.nabble.com>
	<1319630071722-4939528.post@n5.nabble.com>
	<1319636130.20499.YahooMailNeo@web29808.mail.ird.yahoo.com>
	<1319695116310-4942047.post@n5.nabble.com>
	<1319710499.206.YahooMailNeo@web29804.mail.ird.yahoo.com>
	<1323123990448-5050354.post@n5.nabble.com>
	<1323170568.90631.YahooMailNeo@web29813.mail.ird.yahoo.com>
	<1323504740494-5063848.post@n5.nabble.com>
MIME-Version: 1.0
Subject: Re: [Xen-devel] Re : Re : Re : Re : Re : Re : Re : Re: Patches for
 VGA-Passthrough XEN 4.2 unstable
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

No vnc, physical DVI screen. And performances are really good, you'll not
notice you're under a domU, especially in 3D games.

--
View this message in context: http://xen.1045712.n5.nabble.com/Patches-for-VGA-Passthrough-XEN-4-2-unstable-tp4406265p5064245.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Dec 10 12:31:48 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 10 Dec 2011 12:31:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZM4s-0006fm-Hr; Sat, 10 Dec 2011 12:30:54 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <shandivo@gmail.com>) id 1RZM4q-0006eV-8P
	for xen-devel@lists.xensource.com; Sat, 10 Dec 2011 12:30:52 +0000
X-Env-Sender: shandivo@gmail.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1323520200!6690999!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.3 required=7.0 tests=HTML_60_70,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,spamassassin: 
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11343 invoked from network); 10 Dec 2011 12:30:01 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-3.tower-182.messagelabs.com with AES256-SHA encrypted SMTP;
	10 Dec 2011 12:30:01 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <shandivo@gmail.com>) id 1RZM3z-0002xJ-RQ
	for xen-devel@lists.xensource.com; Sat, 10 Dec 2011 04:29:59 -0800
Date: Sat, 10 Dec 2011 04:29:59 -0800 (PST)
From: n4rC0t1C <shandivo@gmail.com>
To: xen-devel@lists.xensource.com
Message-ID: <CACA08Dxiko+Swo-zhVfdjK3eb=tMz+cT5PKfLj-hhxSuoNnWjg@mail.gmail.com>
In-Reply-To: <1323504740494-5063848.post@n5.nabble.com>
References: <1316786412428-4833637.post@n5.nabble.com>
	<20110923172115.GI12984@reaktio.net>
	<1318672856439-4904945.post@n5.nabble.com>
	<1319630071722-4939528.post@n5.nabble.com>
	<1319636130.20499.YahooMailNeo@web29808.mail.ird.yahoo.com>
	<1319695116310-4942047.post@n5.nabble.com>
	<1319710499.206.YahooMailNeo@web29804.mail.ird.yahoo.com>
	<1323123990448-5050354.post@n5.nabble.com>
	<1323170568.90631.YahooMailNeo@web29813.mail.ird.yahoo.com>
	<1323504740494-5063848.post@n5.nabble.com>
MIME-Version: 1.0
Subject: Re: [Xen-devel] Re : Re : Re : Re : Re : Re : Re : Re: Patches for
 VGA-Passthrough XEN 4.2 unstable
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6163465316981520989=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============6163465316981520989==
Content-Type: multipart/alternative; 
	boundary="----=_Part_3960_1226109.1323520199845"

------=_Part_3960_1226109.1323520199845
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

No vnc, physical DVI screen. And performances are really good, you'll not
notice you're under a domU, especially in 3D games.

On Sat, Dec 10, 2011 at 9:12 AM, Sythrar [via Xen] <
ml-node+s1045712n5063848h66@n5.nabble.com> wrote:

> n4rC0t1C, DomU VNC you tested with, if so, has good performance in game?
>
> ------------------------------
>  If you reply to this email, your message will be added to the discussion
> below:
>
> http://xen.1045712.n5.nabble.com/Patches-for-VGA-Passthrough-XEN-4-2-unstable-tp4406265p5063848.html
>  To unsubscribe from Patches for VGA-Passthrough XEN 4.2 unstable, click
> here<http://xen.1045712.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=4406265&code=c2hhbmRpdm9AZ21haWwuY29tfDQ0MDYyNjV8LTE0MDgyODU1MjU=>
> .
> NAML<http://xen.1045712.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.InstantMailNamespace&breadcrumbs=instant+emails%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>


--
View this message in context: http://xen.1045712.n5.nabble.com/Patches-for-VGA-Passthrough-XEN-4-2-unstable-tp4406265p5064246.html
Sent from the Xen - Dev mailing list archive at Nabble.com.
------=_Part_3960_1226109.1323520199845
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

No vnc, physical DVI screen. And performances are really good, you&#39;ll not notice you&#39;re under a domU, especially in 3D games.<br><br><div class="gmail_quote">On Sat, Dec 10, 2011 at 9:12 AM, Sythrar [via Xen] <span dir="ltr">&lt;<a href="/user/SendEmail.jtp?type=node&node=5064246&i=0" target="_top" rel="nofollow" link="external">[hidden email]</a>&gt;</span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">

	n4rC0t1C, DomU VNC you tested with, if so, has good performance in game? 
	
	<br>
	<br>
	<hr noshade size="1" color="#cccccc">
	</div><div style="color:#444;font:12px tahoma,geneva,helvetica,arial,sans-serif"><div class="im">
		<div style="font-weight:bold">If you reply to this email, your message will be added to the discussion below:</div>
		</div><a href="http://xen.1045712.n5.nabble.com/Patches-for-VGA-Passthrough-XEN-4-2-unstable-tp4406265p5063848.html" target="_blank" rel="nofollow" link="external">http://xen.1045712.n5.nabble.com/Patches-for-VGA-Passthrough-XEN-4-2-unstable-tp4406265p5063848.html</a>
	</div>
	<div style="color:#666;font:11px tahoma,geneva,helvetica,arial,sans-serif;margin-top:.4em;line-height:1.5em">
		
		To unsubscribe from Patches for VGA-Passthrough XEN 4.2 unstable, <a href="" target="_blank" rel="nofollow" link="external">click here</a>.<br>


		<a href="http://xen.1045712.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&amp;id=instant_html%21nabble%3Aemail.naml&amp;base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.InstantMailNamespace&amp;breadcrumbs=instant+emails%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml" rel="nofollow" style="font:9px serif" target="_blank" link="external">NAML</a>
	</div></blockquote></div><br>

	
<br/><hr align="left" width="300" />
View this message in context: <a href="http://xen.1045712.n5.nabble.com/Patches-for-VGA-Passthrough-XEN-4-2-unstable-tp4406265p5064246.html">Re: Re : Re : Re : Re : Re : Re : Re : Re: Patches for VGA-Passthrough XEN 4.2 unstable</a><br/>
Sent from the <a href="http://xen.1045712.n5.nabble.com/Xen-Dev-f2473738.html">Xen - Dev mailing list archive</a> at Nabble.com.<br/>
------=_Part_3960_1226109.1323520199845--


--===============6163465316981520989==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============6163465316981520989==--


From xen-devel-bounces@lists.xensource.com Sat Dec 10 12:31:48 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 10 Dec 2011 12:31:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZM4s-0006fm-Hr; Sat, 10 Dec 2011 12:30:54 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <shandivo@gmail.com>) id 1RZM4q-0006eV-8P
	for xen-devel@lists.xensource.com; Sat, 10 Dec 2011 12:30:52 +0000
X-Env-Sender: shandivo@gmail.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1323520200!6690999!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.3 required=7.0 tests=HTML_60_70,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,spamassassin: 
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11343 invoked from network); 10 Dec 2011 12:30:01 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-3.tower-182.messagelabs.com with AES256-SHA encrypted SMTP;
	10 Dec 2011 12:30:01 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <shandivo@gmail.com>) id 1RZM3z-0002xJ-RQ
	for xen-devel@lists.xensource.com; Sat, 10 Dec 2011 04:29:59 -0800
Date: Sat, 10 Dec 2011 04:29:59 -0800 (PST)
From: n4rC0t1C <shandivo@gmail.com>
To: xen-devel@lists.xensource.com
Message-ID: <CACA08Dxiko+Swo-zhVfdjK3eb=tMz+cT5PKfLj-hhxSuoNnWjg@mail.gmail.com>
In-Reply-To: <1323504740494-5063848.post@n5.nabble.com>
References: <1316786412428-4833637.post@n5.nabble.com>
	<20110923172115.GI12984@reaktio.net>
	<1318672856439-4904945.post@n5.nabble.com>
	<1319630071722-4939528.post@n5.nabble.com>
	<1319636130.20499.YahooMailNeo@web29808.mail.ird.yahoo.com>
	<1319695116310-4942047.post@n5.nabble.com>
	<1319710499.206.YahooMailNeo@web29804.mail.ird.yahoo.com>
	<1323123990448-5050354.post@n5.nabble.com>
	<1323170568.90631.YahooMailNeo@web29813.mail.ird.yahoo.com>
	<1323504740494-5063848.post@n5.nabble.com>
MIME-Version: 1.0
Subject: Re: [Xen-devel] Re : Re : Re : Re : Re : Re : Re : Re: Patches for
 VGA-Passthrough XEN 4.2 unstable
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6163465316981520989=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============6163465316981520989==
Content-Type: multipart/alternative; 
	boundary="----=_Part_3960_1226109.1323520199845"

------=_Part_3960_1226109.1323520199845
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

No vnc, physical DVI screen. And performances are really good, you'll not
notice you're under a domU, especially in 3D games.

On Sat, Dec 10, 2011 at 9:12 AM, Sythrar [via Xen] <
ml-node+s1045712n5063848h66@n5.nabble.com> wrote:

> n4rC0t1C, DomU VNC you tested with, if so, has good performance in game?
>
> ------------------------------
>  If you reply to this email, your message will be added to the discussion
> below:
>
> http://xen.1045712.n5.nabble.com/Patches-for-VGA-Passthrough-XEN-4-2-unstable-tp4406265p5063848.html
>  To unsubscribe from Patches for VGA-Passthrough XEN 4.2 unstable, click
> here<http://xen.1045712.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=4406265&code=c2hhbmRpdm9AZ21haWwuY29tfDQ0MDYyNjV8LTE0MDgyODU1MjU=>
> .
> NAML<http://xen.1045712.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.InstantMailNamespace&breadcrumbs=instant+emails%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>


--
View this message in context: http://xen.1045712.n5.nabble.com/Patches-for-VGA-Passthrough-XEN-4-2-unstable-tp4406265p5064246.html
Sent from the Xen - Dev mailing list archive at Nabble.com.
------=_Part_3960_1226109.1323520199845
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

No vnc, physical DVI screen. And performances are really good, you&#39;ll not notice you&#39;re under a domU, especially in 3D games.<br><br><div class="gmail_quote">On Sat, Dec 10, 2011 at 9:12 AM, Sythrar [via Xen] <span dir="ltr">&lt;<a href="/user/SendEmail.jtp?type=node&node=5064246&i=0" target="_top" rel="nofollow" link="external">[hidden email]</a>&gt;</span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">

	n4rC0t1C, DomU VNC you tested with, if so, has good performance in game? 
	
	<br>
	<br>
	<hr noshade size="1" color="#cccccc">
	</div><div style="color:#444;font:12px tahoma,geneva,helvetica,arial,sans-serif"><div class="im">
		<div style="font-weight:bold">If you reply to this email, your message will be added to the discussion below:</div>
		</div><a href="http://xen.1045712.n5.nabble.com/Patches-for-VGA-Passthrough-XEN-4-2-unstable-tp4406265p5063848.html" target="_blank" rel="nofollow" link="external">http://xen.1045712.n5.nabble.com/Patches-for-VGA-Passthrough-XEN-4-2-unstable-tp4406265p5063848.html</a>
	</div>
	<div style="color:#666;font:11px tahoma,geneva,helvetica,arial,sans-serif;margin-top:.4em;line-height:1.5em">
		
		To unsubscribe from Patches for VGA-Passthrough XEN 4.2 unstable, <a href="" target="_blank" rel="nofollow" link="external">click here</a>.<br>


		<a href="http://xen.1045712.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&amp;id=instant_html%21nabble%3Aemail.naml&amp;base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.InstantMailNamespace&amp;breadcrumbs=instant+emails%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml" rel="nofollow" style="font:9px serif" target="_blank" link="external">NAML</a>
	</div></blockquote></div><br>

	
<br/><hr align="left" width="300" />
View this message in context: <a href="http://xen.1045712.n5.nabble.com/Patches-for-VGA-Passthrough-XEN-4-2-unstable-tp4406265p5064246.html">Re: Re : Re : Re : Re : Re : Re : Re : Re: Patches for VGA-Passthrough XEN 4.2 unstable</a><br/>
Sent from the <a href="http://xen.1045712.n5.nabble.com/Xen-Dev-f2473738.html">Xen - Dev mailing list archive</a> at Nabble.com.<br/>
------=_Part_3960_1226109.1323520199845--


--===============6163465316981520989==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============6163465316981520989==--


From xen-devel-bounces@lists.xensource.com Sat Dec 10 16:09:37 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 10 Dec 2011 16:09:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZPTp-0000cg-RZ; Sat, 10 Dec 2011 16:08:53 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <bastian@waldi.eu.org>) id 1RZPTo-0000cb-7T
	for xen-devel@lists.xensource.com; Sat, 10 Dec 2011 16:08:52 +0000
X-Env-Sender: bastian@waldi.eu.org
X-Msg-Ref: server-13.tower-27.messagelabs.com!1323533263!51642309!1
X-Originating-IP: [82.139.201.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32323 invoked from network); 10 Dec 2011 16:07:44 -0000
Received: from wavehammer.waldi.eu.org (HELO wavehammer.waldi.eu.org)
	(82.139.201.20)
	by server-13.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 10 Dec 2011 16:07:44 -0000
Received: by wavehammer.waldi.eu.org (Postfix, from userid 1000)
	id 864345415B; Sat, 10 Dec 2011 17:08:03 +0100 (CET)
Date: Sat, 10 Dec 2011 17:08:03 +0100
From: Bastian Blank <bastian@waldi.eu.org>
To: David Vrabel <david.vrabel@citrix.com>
Message-ID: <20111210160803.GA15557@wavehammer.waldi.eu.org>
Mail-Followup-To: Bastian Blank <bastian@waldi.eu.org>,
	David Vrabel <david.vrabel@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
References: <1323292396-19523-1-git-send-email-waldi@debian.org>
	<1323333259.2969.56.camel@zakaz.uk.xensource.com>
	<20111208092855.GB22678@wavehammer.waldi.eu.org>
	<4EE09B42.4090801@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4EE09B42.4090801@citrix.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [Xen-devel] [PATCH 0/4] V2, Move stuff out of xenfs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Dec 08, 2011 at 11:10:58AM +0000, David Vrabel wrote:
> On 08/12/11 09:28, Bastian Blank wrote:
> > On Thu, Dec 08, 2011 at 08:34:19AM +0000, Ian Campbell wrote:
> >> How are we doing on the corresponding toolstack changes?
> > I have at least parts of it somewhere on my workstation. I'll polish and
> > submit them also.
> I assume the toolstack will fall back to xenfs if the devices don't exist?

This was the plan.

Bastian

-- 
	"Get back to your stations!"
	"We're beaming down to the planet, sir."
		-- Kirk and Mr. Leslie, "This Side of Paradise",
		   stardate 3417.3

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Dec 10 16:09:37 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 10 Dec 2011 16:09:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZPTp-0000cg-RZ; Sat, 10 Dec 2011 16:08:53 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <bastian@waldi.eu.org>) id 1RZPTo-0000cb-7T
	for xen-devel@lists.xensource.com; Sat, 10 Dec 2011 16:08:52 +0000
X-Env-Sender: bastian@waldi.eu.org
X-Msg-Ref: server-13.tower-27.messagelabs.com!1323533263!51642309!1
X-Originating-IP: [82.139.201.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32323 invoked from network); 10 Dec 2011 16:07:44 -0000
Received: from wavehammer.waldi.eu.org (HELO wavehammer.waldi.eu.org)
	(82.139.201.20)
	by server-13.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 10 Dec 2011 16:07:44 -0000
Received: by wavehammer.waldi.eu.org (Postfix, from userid 1000)
	id 864345415B; Sat, 10 Dec 2011 17:08:03 +0100 (CET)
Date: Sat, 10 Dec 2011 17:08:03 +0100
From: Bastian Blank <bastian@waldi.eu.org>
To: David Vrabel <david.vrabel@citrix.com>
Message-ID: <20111210160803.GA15557@wavehammer.waldi.eu.org>
Mail-Followup-To: Bastian Blank <bastian@waldi.eu.org>,
	David Vrabel <david.vrabel@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
References: <1323292396-19523-1-git-send-email-waldi@debian.org>
	<1323333259.2969.56.camel@zakaz.uk.xensource.com>
	<20111208092855.GB22678@wavehammer.waldi.eu.org>
	<4EE09B42.4090801@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4EE09B42.4090801@citrix.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [Xen-devel] [PATCH 0/4] V2, Move stuff out of xenfs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Dec 08, 2011 at 11:10:58AM +0000, David Vrabel wrote:
> On 08/12/11 09:28, Bastian Blank wrote:
> > On Thu, Dec 08, 2011 at 08:34:19AM +0000, Ian Campbell wrote:
> >> How are we doing on the corresponding toolstack changes?
> > I have at least parts of it somewhere on my workstation. I'll polish and
> > submit them also.
> I assume the toolstack will fall back to xenfs if the devices don't exist?

This was the plan.

Bastian

-- 
	"Get back to your stations!"
	"We're beaming down to the planet, sir."
		-- Kirk and Mr. Leslie, "This Side of Paradise",
		   stardate 3417.3

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Dec 10 16:10:14 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 10 Dec 2011 16:10:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZPUb-0000eL-97; Sat, 10 Dec 2011 16:09:41 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <bastian@waldi.eu.org>) id 1RZPUa-0000dh-HX
	for xen-devel@lists.xensource.com; Sat, 10 Dec 2011 16:09:40 +0000
X-Env-Sender: bastian@waldi.eu.org
X-Msg-Ref: server-2.tower-182.messagelabs.com!1323533329!6692887!1
X-Originating-IP: [82.139.201.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25835 invoked from network); 10 Dec 2011 16:08:49 -0000
Received: from wavehammer.waldi.eu.org (HELO wavehammer.waldi.eu.org)
	(82.139.201.20)
	by server-2.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 10 Dec 2011 16:08:49 -0000
Received: by wavehammer.waldi.eu.org (Postfix, from userid 1000)
	id 086595415B; Sat, 10 Dec 2011 17:08:48 +0100 (CET)
Date: Sat, 10 Dec 2011 17:08:48 +0100
From: Bastian Blank <bastian@waldi.eu.org>
To: David Vrabel <david.vrabel@citrix.com>
Message-ID: <20111210160848.GB15557@wavehammer.waldi.eu.org>
Mail-Followup-To: Bastian Blank <bastian@waldi.eu.org>,
	David Vrabel <david.vrabel@citrix.com>,
	xen-devel@lists.xensource.com
References: <1323292396-19523-1-git-send-email-waldi@debian.org>
	<4EE09AE1.3080703@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4EE09AE1.3080703@citrix.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 0/4] V2, Move stuff out of xenfs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Dec 08, 2011 at 11:09:21AM +0000, David Vrabel wrote:
> On 07/12/2011 21:13, Bastian Blank wrote:
> > In<20100605162947.GA31336@wavehammer.waldi.eu.org>  I started the
> > discussion about xenfs and the usage of it. This is the second try to
> > move stuff over into normal device drivers.
> You still don't say why this is needed in the commit messages.  I can't
> find the message you refer to in the previous thread (the mail archives
> don't let you search by message-id).

I prefer gmane to this problem.
http://mid.gmane.org/20100605162947.GA31336@wavehammer.waldi.eu.org
works fine.

-- 
Each kiss is as the first.
		-- Miramanee, Kirk's wife, "The Paradise Syndrome",
		   stardate 4842.6

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Dec 10 16:10:14 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 10 Dec 2011 16:10:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZPUb-0000eL-97; Sat, 10 Dec 2011 16:09:41 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <bastian@waldi.eu.org>) id 1RZPUa-0000dh-HX
	for xen-devel@lists.xensource.com; Sat, 10 Dec 2011 16:09:40 +0000
X-Env-Sender: bastian@waldi.eu.org
X-Msg-Ref: server-2.tower-182.messagelabs.com!1323533329!6692887!1
X-Originating-IP: [82.139.201.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25835 invoked from network); 10 Dec 2011 16:08:49 -0000
Received: from wavehammer.waldi.eu.org (HELO wavehammer.waldi.eu.org)
	(82.139.201.20)
	by server-2.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 10 Dec 2011 16:08:49 -0000
Received: by wavehammer.waldi.eu.org (Postfix, from userid 1000)
	id 086595415B; Sat, 10 Dec 2011 17:08:48 +0100 (CET)
Date: Sat, 10 Dec 2011 17:08:48 +0100
From: Bastian Blank <bastian@waldi.eu.org>
To: David Vrabel <david.vrabel@citrix.com>
Message-ID: <20111210160848.GB15557@wavehammer.waldi.eu.org>
Mail-Followup-To: Bastian Blank <bastian@waldi.eu.org>,
	David Vrabel <david.vrabel@citrix.com>,
	xen-devel@lists.xensource.com
References: <1323292396-19523-1-git-send-email-waldi@debian.org>
	<4EE09AE1.3080703@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4EE09AE1.3080703@citrix.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 0/4] V2, Move stuff out of xenfs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Dec 08, 2011 at 11:09:21AM +0000, David Vrabel wrote:
> On 07/12/2011 21:13, Bastian Blank wrote:
> > In<20100605162947.GA31336@wavehammer.waldi.eu.org>  I started the
> > discussion about xenfs and the usage of it. This is the second try to
> > move stuff over into normal device drivers.
> You still don't say why this is needed in the commit messages.  I can't
> find the message you refer to in the previous thread (the mail archives
> don't let you search by message-id).

I prefer gmane to this problem.
http://mid.gmane.org/20100605162947.GA31336@wavehammer.waldi.eu.org
works fine.

-- 
Each kiss is as the first.
		-- Miramanee, Kirk's wife, "The Paradise Syndrome",
		   stardate 4842.6

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Dec 10 18:31:25 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 10 Dec 2011 18: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.xensource.com>)
	id 1RZRhD-0001Sv-Ov; Sat, 10 Dec 2011 18:30:51 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <bastian@waldi.eu.org>) id 1RZRhB-0001Rq-Q6
	for xen-devel@lists.xensource.com; Sat, 10 Dec 2011 18:30:50 +0000
X-Env-Sender: bastian@waldi.eu.org
X-Msg-Ref: server-2.tower-216.messagelabs.com!1323541797!8278046!1
X-Originating-IP: [82.139.201.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30268 invoked from network); 10 Dec 2011 18:29:58 -0000
Received: from wavehammer.waldi.eu.org (HELO wavehammer.waldi.eu.org)
	(82.139.201.20)
	by server-2.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 10 Dec 2011 18:29:58 -0000
Received: by wavehammer.waldi.eu.org (Postfix, from userid 1000)
	id CAC485426E; Sat, 10 Dec 2011 19:29:56 +0100 (CET)
From: Bastian Blank <waldi@debian.org>
To: xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org
Date: Sat, 10 Dec 2011 19:29:48 +0100
Message-Id: <1323541791-18006-4-git-send-email-waldi@debian.org>
X-Mailer: git-send-email 1.7.7.3
In-Reply-To: <1323541791-18006-1-git-send-email-waldi@debian.org>
References: <1323541791-18006-1-git-send-email-waldi@debian.org>
Cc: konrad.wilk@oracle.com
Subject: [Xen-devel] [PATCH 3/6] xen: Add xenbus_backend device
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Access for xenstored to the event channel and pre-allocated ring is
managed via xenfs.  This adds its own character device featuring mmap
for the ring and an ioctl for the event channel.

Signed-off-by: Bastian Blank <waldi@debian.org>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 drivers/xen/xenbus/Makefile             |    1 +
 drivers/xen/xenbus/xenbus_dev_backend.c |   89 +++++++++++++++++++++++++++++++
 include/xen/xenbus_dev.h                |   41 ++++++++++++++
 3 files changed, 131 insertions(+), 0 deletions(-)
 create mode 100644 drivers/xen/xenbus/xenbus_dev_backend.c
 create mode 100644 include/xen/xenbus_dev.h

diff --git a/drivers/xen/xenbus/Makefile b/drivers/xen/xenbus/Makefile
index a2ea363..31e2e90 100644
--- a/drivers/xen/xenbus/Makefile
+++ b/drivers/xen/xenbus/Makefile
@@ -10,4 +10,5 @@ xenbus-objs += xenbus_probe.o
 xenbus-be-objs-$(CONFIG_XEN_BACKEND) += xenbus_probe_backend.o
 xenbus-objs += $(xenbus-be-objs-y)
 
+obj-$(CONFIG_XEN_BACKEND) += xenbus_dev_backend.o
 obj-$(CONFIG_XEN_XENBUS_FRONTEND) += xenbus_probe_frontend.o
diff --git a/drivers/xen/xenbus/xenbus_dev_backend.c b/drivers/xen/xenbus/xenbus_dev_backend.c
new file mode 100644
index 0000000..a2092bd
--- /dev/null
+++ b/drivers/xen/xenbus/xenbus_dev_backend.c
@@ -0,0 +1,89 @@
+#include <linux/slab.h>
+#include <linux/types.h>
+#include <linux/mm.h>
+#include <linux/fs.h>
+#include <linux/miscdevice.h>
+#include <linux/module.h>
+#include <linux/capability.h>
+
+#include <xen/page.h>
+#include <xen/xenbus_dev.h>
+
+#include "xenbus_comms.h"
+
+MODULE_LICENSE("GPL");
+
+static int xenbus_backend_open(struct inode *inode, struct file *filp)
+{
+	if (!capable(CAP_SYS_ADMIN))
+		return -EPERM;
+
+	return nonseekable_open(inode, filp);
+}
+
+static long xenbus_backend_ioctl(struct file *file, unsigned int cmd, unsigned long data)
+{
+	if (!capable(CAP_SYS_ADMIN))
+		return -EPERM;
+
+	switch (cmd) {
+		case IOCTL_XENBUS_BACKEND_EVTCHN:
+			if (xen_store_evtchn > 0)
+				return xen_store_evtchn;
+			return -ENODEV;
+
+		default:
+			return -ENOTTY;
+	}
+}
+
+static int xenbus_backend_mmap(struct file *file, struct vm_area_struct *vma)
+{
+	size_t size = vma->vm_end - vma->vm_start;
+
+	if (!capable(CAP_SYS_ADMIN))
+		return -EPERM;
+
+	if ((size > PAGE_SIZE) || (vma->vm_pgoff != 0))
+		return -EINVAL;
+
+	if (remap_pfn_range(vma, vma->vm_start,
+			    virt_to_pfn(xen_store_interface),
+			    size, vma->vm_page_prot))
+		return -EAGAIN;
+
+	return 0;
+}
+
+const struct file_operations xenbus_backend_fops = {
+	.open = xenbus_backend_open,
+	.mmap = xenbus_backend_mmap,
+	.unlocked_ioctl = xenbus_backend_ioctl,
+};
+
+static struct miscdevice xenbus_backend_dev = {
+	.minor = MISC_DYNAMIC_MINOR,
+	.name = "xen/xenbus_backend",
+	.fops = &xenbus_backend_fops,
+};
+
+static int __init xenbus_backend_init(void)
+{
+	int err;
+
+	if (!xen_initial_domain())
+		return -ENODEV;
+
+	err = misc_register(&xenbus_backend_dev);
+	if (err)
+		printk(KERN_ERR "Could not register xenbus backend device\n");
+	return err;
+}
+
+static void __exit xenbus_backend_exit(void)
+{
+	misc_deregister(&xenbus_backend_dev);
+}
+
+module_init(xenbus_backend_init);
+module_exit(xenbus_backend_exit);
diff --git a/include/xen/xenbus_dev.h b/include/xen/xenbus_dev.h
new file mode 100644
index 0000000..ac5f0fe
--- /dev/null
+++ b/include/xen/xenbus_dev.h
@@ -0,0 +1,41 @@
+/******************************************************************************
+ * evtchn.h
+ *
+ * Interface to /dev/xen/xenbus_backend.
+ *
+ * Copyright (c) 2011 Bastian Blank <waldi@debian.org>
+ *
+ * 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 __LINUX_XEN_XENBUS_DEV_H__
+#define __LINUX_XEN_XENBUS_DEV_H__
+
+#include <linux/ioctl.h>
+
+#define IOCTL_XENBUS_BACKEND_EVTCHN			\
+	_IOC(_IOC_NONE, 'B', 0, 0)
+
+#endif /* __LINUX_XEN_XENBUS_DEV_H__ */
-- 
1.7.7.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Dec 10 18:31:25 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 10 Dec 2011 18: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.xensource.com>)
	id 1RZRhD-0001Sv-Ov; Sat, 10 Dec 2011 18:30:51 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <bastian@waldi.eu.org>) id 1RZRhB-0001Rq-Q6
	for xen-devel@lists.xensource.com; Sat, 10 Dec 2011 18:30:50 +0000
X-Env-Sender: bastian@waldi.eu.org
X-Msg-Ref: server-2.tower-216.messagelabs.com!1323541797!8278046!1
X-Originating-IP: [82.139.201.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30268 invoked from network); 10 Dec 2011 18:29:58 -0000
Received: from wavehammer.waldi.eu.org (HELO wavehammer.waldi.eu.org)
	(82.139.201.20)
	by server-2.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 10 Dec 2011 18:29:58 -0000
Received: by wavehammer.waldi.eu.org (Postfix, from userid 1000)
	id CAC485426E; Sat, 10 Dec 2011 19:29:56 +0100 (CET)
From: Bastian Blank <waldi@debian.org>
To: xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org
Date: Sat, 10 Dec 2011 19:29:48 +0100
Message-Id: <1323541791-18006-4-git-send-email-waldi@debian.org>
X-Mailer: git-send-email 1.7.7.3
In-Reply-To: <1323541791-18006-1-git-send-email-waldi@debian.org>
References: <1323541791-18006-1-git-send-email-waldi@debian.org>
Cc: konrad.wilk@oracle.com
Subject: [Xen-devel] [PATCH 3/6] xen: Add xenbus_backend device
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Access for xenstored to the event channel and pre-allocated ring is
managed via xenfs.  This adds its own character device featuring mmap
for the ring and an ioctl for the event channel.

Signed-off-by: Bastian Blank <waldi@debian.org>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 drivers/xen/xenbus/Makefile             |    1 +
 drivers/xen/xenbus/xenbus_dev_backend.c |   89 +++++++++++++++++++++++++++++++
 include/xen/xenbus_dev.h                |   41 ++++++++++++++
 3 files changed, 131 insertions(+), 0 deletions(-)
 create mode 100644 drivers/xen/xenbus/xenbus_dev_backend.c
 create mode 100644 include/xen/xenbus_dev.h

diff --git a/drivers/xen/xenbus/Makefile b/drivers/xen/xenbus/Makefile
index a2ea363..31e2e90 100644
--- a/drivers/xen/xenbus/Makefile
+++ b/drivers/xen/xenbus/Makefile
@@ -10,4 +10,5 @@ xenbus-objs += xenbus_probe.o
 xenbus-be-objs-$(CONFIG_XEN_BACKEND) += xenbus_probe_backend.o
 xenbus-objs += $(xenbus-be-objs-y)
 
+obj-$(CONFIG_XEN_BACKEND) += xenbus_dev_backend.o
 obj-$(CONFIG_XEN_XENBUS_FRONTEND) += xenbus_probe_frontend.o
diff --git a/drivers/xen/xenbus/xenbus_dev_backend.c b/drivers/xen/xenbus/xenbus_dev_backend.c
new file mode 100644
index 0000000..a2092bd
--- /dev/null
+++ b/drivers/xen/xenbus/xenbus_dev_backend.c
@@ -0,0 +1,89 @@
+#include <linux/slab.h>
+#include <linux/types.h>
+#include <linux/mm.h>
+#include <linux/fs.h>
+#include <linux/miscdevice.h>
+#include <linux/module.h>
+#include <linux/capability.h>
+
+#include <xen/page.h>
+#include <xen/xenbus_dev.h>
+
+#include "xenbus_comms.h"
+
+MODULE_LICENSE("GPL");
+
+static int xenbus_backend_open(struct inode *inode, struct file *filp)
+{
+	if (!capable(CAP_SYS_ADMIN))
+		return -EPERM;
+
+	return nonseekable_open(inode, filp);
+}
+
+static long xenbus_backend_ioctl(struct file *file, unsigned int cmd, unsigned long data)
+{
+	if (!capable(CAP_SYS_ADMIN))
+		return -EPERM;
+
+	switch (cmd) {
+		case IOCTL_XENBUS_BACKEND_EVTCHN:
+			if (xen_store_evtchn > 0)
+				return xen_store_evtchn;
+			return -ENODEV;
+
+		default:
+			return -ENOTTY;
+	}
+}
+
+static int xenbus_backend_mmap(struct file *file, struct vm_area_struct *vma)
+{
+	size_t size = vma->vm_end - vma->vm_start;
+
+	if (!capable(CAP_SYS_ADMIN))
+		return -EPERM;
+
+	if ((size > PAGE_SIZE) || (vma->vm_pgoff != 0))
+		return -EINVAL;
+
+	if (remap_pfn_range(vma, vma->vm_start,
+			    virt_to_pfn(xen_store_interface),
+			    size, vma->vm_page_prot))
+		return -EAGAIN;
+
+	return 0;
+}
+
+const struct file_operations xenbus_backend_fops = {
+	.open = xenbus_backend_open,
+	.mmap = xenbus_backend_mmap,
+	.unlocked_ioctl = xenbus_backend_ioctl,
+};
+
+static struct miscdevice xenbus_backend_dev = {
+	.minor = MISC_DYNAMIC_MINOR,
+	.name = "xen/xenbus_backend",
+	.fops = &xenbus_backend_fops,
+};
+
+static int __init xenbus_backend_init(void)
+{
+	int err;
+
+	if (!xen_initial_domain())
+		return -ENODEV;
+
+	err = misc_register(&xenbus_backend_dev);
+	if (err)
+		printk(KERN_ERR "Could not register xenbus backend device\n");
+	return err;
+}
+
+static void __exit xenbus_backend_exit(void)
+{
+	misc_deregister(&xenbus_backend_dev);
+}
+
+module_init(xenbus_backend_init);
+module_exit(xenbus_backend_exit);
diff --git a/include/xen/xenbus_dev.h b/include/xen/xenbus_dev.h
new file mode 100644
index 0000000..ac5f0fe
--- /dev/null
+++ b/include/xen/xenbus_dev.h
@@ -0,0 +1,41 @@
+/******************************************************************************
+ * evtchn.h
+ *
+ * Interface to /dev/xen/xenbus_backend.
+ *
+ * Copyright (c) 2011 Bastian Blank <waldi@debian.org>
+ *
+ * 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 __LINUX_XEN_XENBUS_DEV_H__
+#define __LINUX_XEN_XENBUS_DEV_H__
+
+#include <linux/ioctl.h>
+
+#define IOCTL_XENBUS_BACKEND_EVTCHN			\
+	_IOC(_IOC_NONE, 'B', 0, 0)
+
+#endif /* __LINUX_XEN_XENBUS_DEV_H__ */
-- 
1.7.7.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Dec 10 18:31:25 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 10 Dec 2011 18: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.xensource.com>)
	id 1RZRhC-0001SL-7n; Sat, 10 Dec 2011 18:30:50 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <bastian@waldi.eu.org>) id 1RZRhA-0001Rl-Rd
	for xen-devel@lists.xensource.com; Sat, 10 Dec 2011 18:30:49 +0000
X-Env-Sender: bastian@waldi.eu.org
X-Msg-Ref: server-16.tower-174.messagelabs.com!1323541797!4852807!1
X-Originating-IP: [82.139.201.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24554 invoked from network); 10 Dec 2011 18:29:58 -0000
Received: from wavehammer.waldi.eu.org (HELO wavehammer.waldi.eu.org)
	(82.139.201.20)
	by server-16.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 10 Dec 2011 18:29:58 -0000
Received: by wavehammer.waldi.eu.org (Postfix, from userid 1000)
	id 7FA7C5415D; Sat, 10 Dec 2011 19:29:56 +0100 (CET)
From: Bastian Blank <waldi@debian.org>
To: xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org
Date: Sat, 10 Dec 2011 19:29:45 +0100
Message-Id: <1323541791-18006-1-git-send-email-waldi@debian.org>
X-Mailer: git-send-email 1.7.7.3
Cc: konrad.wilk@oracle.com
Subject: [Xen-devel] [PATCH 0/6] V3, Move stuff out of xenfs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Changes from v2:
- Rename xenbusd to xenbus_backend
- Register xenbus_backend device only if ring is local
- Use more correct error value: EPERM

Bastian


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Dec 10 18:31:25 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 10 Dec 2011 18: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.xensource.com>)
	id 1RZRhC-0001SL-7n; Sat, 10 Dec 2011 18:30:50 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <bastian@waldi.eu.org>) id 1RZRhA-0001Rl-Rd
	for xen-devel@lists.xensource.com; Sat, 10 Dec 2011 18:30:49 +0000
X-Env-Sender: bastian@waldi.eu.org
X-Msg-Ref: server-16.tower-174.messagelabs.com!1323541797!4852807!1
X-Originating-IP: [82.139.201.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24554 invoked from network); 10 Dec 2011 18:29:58 -0000
Received: from wavehammer.waldi.eu.org (HELO wavehammer.waldi.eu.org)
	(82.139.201.20)
	by server-16.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 10 Dec 2011 18:29:58 -0000
Received: by wavehammer.waldi.eu.org (Postfix, from userid 1000)
	id 7FA7C5415D; Sat, 10 Dec 2011 19:29:56 +0100 (CET)
From: Bastian Blank <waldi@debian.org>
To: xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org
Date: Sat, 10 Dec 2011 19:29:45 +0100
Message-Id: <1323541791-18006-1-git-send-email-waldi@debian.org>
X-Mailer: git-send-email 1.7.7.3
Cc: konrad.wilk@oracle.com
Subject: [Xen-devel] [PATCH 0/6] V3, Move stuff out of xenfs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Changes from v2:
- Rename xenbusd to xenbus_backend
- Register xenbus_backend device only if ring is local
- Use more correct error value: EPERM

Bastian


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Dec 10 18:31:25 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 10 Dec 2011 18: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.xensource.com>)
	id 1RZRhC-0001SS-K8; Sat, 10 Dec 2011 18:30:50 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <bastian@waldi.eu.org>) id 1RZRhB-0001Rn-68
	for xen-devel@lists.xensource.com; Sat, 10 Dec 2011 18:30:49 +0000
X-Env-Sender: bastian@waldi.eu.org
X-Msg-Ref: server-13.tower-182.messagelabs.com!1323541797!6170040!1
X-Originating-IP: [82.139.201.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25969 invoked from network); 10 Dec 2011 18:29:58 -0000
Received: from wavehammer.waldi.eu.org (HELO wavehammer.waldi.eu.org)
	(82.139.201.20)
	by server-13.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 10 Dec 2011 18:29:58 -0000
Received: by wavehammer.waldi.eu.org (Postfix, from userid 1000)
	id D3A1E5426D; Sat, 10 Dec 2011 19:29:56 +0100 (CET)
From: Bastian Blank <waldi@debian.org>
To: xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org
Date: Sat, 10 Dec 2011 19:29:49 +0100
Message-Id: <1323541791-18006-5-git-send-email-waldi@debian.org>
X-Mailer: git-send-email 1.7.7.3
In-Reply-To: <1323541791-18006-1-git-send-email-waldi@debian.org>
References: <1323541791-18006-1-git-send-email-waldi@debian.org>
Cc: konrad.wilk@oracle.com
Subject: [Xen-devel] [PATCH 4/6] xen/privcmd: Remove unused support for arch
	specific privcmp mmap
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This was used for ia64. But there is no working ia64 support in sight,
so remove it for now.

Signed-off-by: Bastian Blank <waldi@debian.org>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 drivers/xen/privcmd.c |    2 --
 1 files changed, 0 insertions(+), 2 deletions(-)

diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
index 4e8d3da..ccee0f1 100644
--- a/drivers/xen/privcmd.c
+++ b/drivers/xen/privcmd.c
@@ -365,7 +365,6 @@ static long privcmd_ioctl(struct file *file,
 	return ret;
 }
 
-#ifndef HAVE_ARCH_PRIVCMD_MMAP
 static int privcmd_fault(struct vm_area_struct *vma, struct vm_fault *vmf)
 {
 	printk(KERN_DEBUG "privcmd_fault: vma=%p %lx-%lx, pgoff=%lx, uv=%p\n",
@@ -398,7 +397,6 @@ static int privcmd_enforce_singleshot_mapping(struct vm_area_struct *vma)
 {
 	return (xchg(&vma->vm_private_data, (void *)1) == NULL);
 }
-#endif
 
 const struct file_operations xen_privcmd_fops = {
 	.owner = THIS_MODULE,
-- 
1.7.7.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Dec 10 18:31:26 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 10 Dec 2011 18:31:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZRhE-0001TL-NN; Sat, 10 Dec 2011 18:30:52 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <bastian@waldi.eu.org>) id 1RZRhD-0001Rv-67
	for xen-devel@lists.xensource.com; Sat, 10 Dec 2011 18:30:51 +0000
X-Env-Sender: bastian@waldi.eu.org
X-Msg-Ref: server-14.tower-182.messagelabs.com!1323541799!6696282!1
X-Originating-IP: [82.139.201.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1864 invoked from network); 10 Dec 2011 18:30:00 -0000
Received: from wavehammer.waldi.eu.org (HELO wavehammer.waldi.eu.org)
	(82.139.201.20)
	by server-14.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 10 Dec 2011 18:30:00 -0000
Received: by wavehammer.waldi.eu.org (Postfix, from userid 1000)
	id EB6485426F; Sat, 10 Dec 2011 19:29:56 +0100 (CET)
From: Bastian Blank <waldi@debian.org>
To: xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org
Date: Sat, 10 Dec 2011 19:29:50 +0100
Message-Id: <1323541791-18006-6-git-send-email-waldi@debian.org>
X-Mailer: git-send-email 1.7.7.3
In-Reply-To: <1323541791-18006-1-git-send-email-waldi@debian.org>
References: <1323541791-18006-1-git-send-email-waldi@debian.org>
Cc: konrad.wilk@oracle.com
Subject: [Xen-devel] [PATCH 5/6] xen/xenbus-frontend: Make error message
	more clear
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Add the work frontend to the error message because we now also have a
backend device.

Signed-off-by: Bastian Blank <waldi@debian.org>
---
 drivers/xen/xenbus/xenbus_dev_frontend.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/xen/xenbus/xenbus_dev_frontend.c b/drivers/xen/xenbus/xenbus_dev_frontend.c
index fb30cff..9f6be7d 100644
--- a/drivers/xen/xenbus/xenbus_dev_frontend.c
+++ b/drivers/xen/xenbus/xenbus_dev_frontend.c
@@ -611,7 +611,7 @@ static int __init xenbus_init(void)
 
 	err = misc_register(&xenbus_dev);
 	if (err)
-		printk(KERN_ERR "Could not register xenbus device\n");
+		printk(KERN_ERR "Could not register xenbus frontend device\n");
 	return err;
 }
 
-- 
1.7.7.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Dec 10 18:31:25 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 10 Dec 2011 18: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.xensource.com>)
	id 1RZRhC-0001SS-K8; Sat, 10 Dec 2011 18:30:50 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <bastian@waldi.eu.org>) id 1RZRhB-0001Rn-68
	for xen-devel@lists.xensource.com; Sat, 10 Dec 2011 18:30:49 +0000
X-Env-Sender: bastian@waldi.eu.org
X-Msg-Ref: server-13.tower-182.messagelabs.com!1323541797!6170040!1
X-Originating-IP: [82.139.201.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25969 invoked from network); 10 Dec 2011 18:29:58 -0000
Received: from wavehammer.waldi.eu.org (HELO wavehammer.waldi.eu.org)
	(82.139.201.20)
	by server-13.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 10 Dec 2011 18:29:58 -0000
Received: by wavehammer.waldi.eu.org (Postfix, from userid 1000)
	id D3A1E5426D; Sat, 10 Dec 2011 19:29:56 +0100 (CET)
From: Bastian Blank <waldi@debian.org>
To: xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org
Date: Sat, 10 Dec 2011 19:29:49 +0100
Message-Id: <1323541791-18006-5-git-send-email-waldi@debian.org>
X-Mailer: git-send-email 1.7.7.3
In-Reply-To: <1323541791-18006-1-git-send-email-waldi@debian.org>
References: <1323541791-18006-1-git-send-email-waldi@debian.org>
Cc: konrad.wilk@oracle.com
Subject: [Xen-devel] [PATCH 4/6] xen/privcmd: Remove unused support for arch
	specific privcmp mmap
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This was used for ia64. But there is no working ia64 support in sight,
so remove it for now.

Signed-off-by: Bastian Blank <waldi@debian.org>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 drivers/xen/privcmd.c |    2 --
 1 files changed, 0 insertions(+), 2 deletions(-)

diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
index 4e8d3da..ccee0f1 100644
--- a/drivers/xen/privcmd.c
+++ b/drivers/xen/privcmd.c
@@ -365,7 +365,6 @@ static long privcmd_ioctl(struct file *file,
 	return ret;
 }
 
-#ifndef HAVE_ARCH_PRIVCMD_MMAP
 static int privcmd_fault(struct vm_area_struct *vma, struct vm_fault *vmf)
 {
 	printk(KERN_DEBUG "privcmd_fault: vma=%p %lx-%lx, pgoff=%lx, uv=%p\n",
@@ -398,7 +397,6 @@ static int privcmd_enforce_singleshot_mapping(struct vm_area_struct *vma)
 {
 	return (xchg(&vma->vm_private_data, (void *)1) == NULL);
 }
-#endif
 
 const struct file_operations xen_privcmd_fops = {
 	.owner = THIS_MODULE,
-- 
1.7.7.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Dec 10 18:31:26 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 10 Dec 2011 18:31:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZRhE-0001TL-NN; Sat, 10 Dec 2011 18:30:52 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <bastian@waldi.eu.org>) id 1RZRhD-0001Rv-67
	for xen-devel@lists.xensource.com; Sat, 10 Dec 2011 18:30:51 +0000
X-Env-Sender: bastian@waldi.eu.org
X-Msg-Ref: server-14.tower-182.messagelabs.com!1323541799!6696282!1
X-Originating-IP: [82.139.201.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1864 invoked from network); 10 Dec 2011 18:30:00 -0000
Received: from wavehammer.waldi.eu.org (HELO wavehammer.waldi.eu.org)
	(82.139.201.20)
	by server-14.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 10 Dec 2011 18:30:00 -0000
Received: by wavehammer.waldi.eu.org (Postfix, from userid 1000)
	id EB6485426F; Sat, 10 Dec 2011 19:29:56 +0100 (CET)
From: Bastian Blank <waldi@debian.org>
To: xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org
Date: Sat, 10 Dec 2011 19:29:50 +0100
Message-Id: <1323541791-18006-6-git-send-email-waldi@debian.org>
X-Mailer: git-send-email 1.7.7.3
In-Reply-To: <1323541791-18006-1-git-send-email-waldi@debian.org>
References: <1323541791-18006-1-git-send-email-waldi@debian.org>
Cc: konrad.wilk@oracle.com
Subject: [Xen-devel] [PATCH 5/6] xen/xenbus-frontend: Make error message
	more clear
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Add the work frontend to the error message because we now also have a
backend device.

Signed-off-by: Bastian Blank <waldi@debian.org>
---
 drivers/xen/xenbus/xenbus_dev_frontend.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/xen/xenbus/xenbus_dev_frontend.c b/drivers/xen/xenbus/xenbus_dev_frontend.c
index fb30cff..9f6be7d 100644
--- a/drivers/xen/xenbus/xenbus_dev_frontend.c
+++ b/drivers/xen/xenbus/xenbus_dev_frontend.c
@@ -611,7 +611,7 @@ static int __init xenbus_init(void)
 
 	err = misc_register(&xenbus_dev);
 	if (err)
-		printk(KERN_ERR "Could not register xenbus device\n");
+		printk(KERN_ERR "Could not register xenbus frontend device\n");
 	return err;
 }
 
-- 
1.7.7.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Dec 10 18:31:26 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 10 Dec 2011 18:31:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZRhD-0001Sk-Ci; Sat, 10 Dec 2011 18:30:51 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <bastian@waldi.eu.org>) id 1RZRhB-0001Rp-K1
	for xen-devel@lists.xensource.com; Sat, 10 Dec 2011 18:30:49 +0000
X-Env-Sender: bastian@waldi.eu.org
X-Msg-Ref: server-11.tower-182.messagelabs.com!1323541797!6689733!1
X-Originating-IP: [82.139.201.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3323 invoked from network); 10 Dec 2011 18:29:58 -0000
Received: from wavehammer.waldi.eu.org (HELO wavehammer.waldi.eu.org)
	(82.139.201.20)
	by server-11.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 10 Dec 2011 18:29:58 -0000
Received: by wavehammer.waldi.eu.org (Postfix, from userid 1000)
	id A5BC4540FF; Sat, 10 Dec 2011 19:29:56 +0100 (CET)
From: Bastian Blank <waldi@debian.org>
To: xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org
Date: Sat, 10 Dec 2011 19:29:47 +0100
Message-Id: <1323541791-18006-3-git-send-email-waldi@debian.org>
X-Mailer: git-send-email 1.7.7.3
In-Reply-To: <1323541791-18006-1-git-send-email-waldi@debian.org>
References: <1323541791-18006-1-git-send-email-waldi@debian.org>
Cc: konrad.wilk@oracle.com
Subject: [Xen-devel] [PATCH 2/6] xen: Add xenbus device driver
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Access to xenbus is currently handled via xenfs. This adds a device
driver for xenbus and makes xenfs use this code.

Signed-off-by: Bastian Blank <waldi@debian.org>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 drivers/xen/xenbus/Makefile                        |    1 +
 drivers/xen/xenbus/xenbus_comms.h                  |    4 ++
 .../xenbus.c => xenbus/xenbus_dev_frontend.c}      |   37 ++++++++++++++++++--
 drivers/xen/xenfs/Makefile                         |    2 +-
 drivers/xen/xenfs/super.c                          |    3 +-
 drivers/xen/xenfs/xenfs.h                          |    1 -
 6 files changed, 42 insertions(+), 6 deletions(-)
 rename drivers/xen/{xenfs/xenbus.c => xenbus/xenbus_dev_frontend.c} (95%)

diff --git a/drivers/xen/xenbus/Makefile b/drivers/xen/xenbus/Makefile
index 8dca685..a2ea363 100644
--- a/drivers/xen/xenbus/Makefile
+++ b/drivers/xen/xenbus/Makefile
@@ -1,4 +1,5 @@
 obj-y	+= xenbus.o
+obj-y	+= xenbus_dev_frontend.o
 
 xenbus-objs =
 xenbus-objs += xenbus_client.o
diff --git a/drivers/xen/xenbus/xenbus_comms.h b/drivers/xen/xenbus/xenbus_comms.h
index c21db75..6e42800 100644
--- a/drivers/xen/xenbus/xenbus_comms.h
+++ b/drivers/xen/xenbus/xenbus_comms.h
@@ -31,6 +31,8 @@
 #ifndef _XENBUS_COMMS_H
 #define _XENBUS_COMMS_H
 
+#include <linux/fs.h>
+
 int xs_init(void);
 int xb_init_comms(void);
 
@@ -43,4 +45,6 @@ int xs_input_avail(void);
 extern struct xenstore_domain_interface *xen_store_interface;
 extern int xen_store_evtchn;
 
+extern const struct file_operations xen_xenbus_fops;
+
 #endif /* _XENBUS_COMMS_H */
diff --git a/drivers/xen/xenfs/xenbus.c b/drivers/xen/xenbus/xenbus_dev_frontend.c
similarity index 95%
rename from drivers/xen/xenfs/xenbus.c
rename to drivers/xen/xenbus/xenbus_dev_frontend.c
index bbd000f..fb30cff 100644
--- a/drivers/xen/xenfs/xenbus.c
+++ b/drivers/xen/xenbus/xenbus_dev_frontend.c
@@ -52,13 +52,16 @@
 #include <linux/namei.h>
 #include <linux/string.h>
 #include <linux/slab.h>
+#include <linux/miscdevice.h>
+#include <linux/module.h>
 
-#include "xenfs.h"
-#include "../xenbus/xenbus_comms.h"
+#include "xenbus_comms.h"
 
 #include <xen/xenbus.h>
 #include <asm/xen/hypervisor.h>
 
+MODULE_LICENSE("GPL");
+
 /*
  * An element of a list of outstanding transactions, for which we're
  * still waiting a reply.
@@ -583,7 +586,7 @@ static unsigned int xenbus_file_poll(struct file *file, poll_table *wait)
 	return 0;
 }
 
-const struct file_operations xenbus_file_ops = {
+const struct file_operations xen_xenbus_fops = {
 	.read = xenbus_file_read,
 	.write = xenbus_file_write,
 	.open = xenbus_file_open,
@@ -591,3 +594,31 @@ const struct file_operations xenbus_file_ops = {
 	.poll = xenbus_file_poll,
 	.llseek = no_llseek,
 };
+EXPORT_SYMBOL_GPL(xen_xenbus_fops);
+
+static struct miscdevice xenbus_dev = {
+	.minor = MISC_DYNAMIC_MINOR,
+	.name = "xen/xenbus",
+	.fops = &xen_xenbus_fops,
+};
+
+static int __init xenbus_init(void)
+{
+	int err;
+
+	if (!xen_domain())
+		return -ENODEV;
+
+	err = misc_register(&xenbus_dev);
+	if (err)
+		printk(KERN_ERR "Could not register xenbus device\n");
+	return err;
+}
+
+static void __exit xenbus_exit(void)
+{
+	misc_deregister(&xenbus_dev);
+}
+
+module_init(xenbus_init);
+module_exit(xenbus_exit);
diff --git a/drivers/xen/xenfs/Makefile b/drivers/xen/xenfs/Makefile
index 5d45ff1..b019865 100644
--- a/drivers/xen/xenfs/Makefile
+++ b/drivers/xen/xenfs/Makefile
@@ -1,4 +1,4 @@
 obj-$(CONFIG_XENFS) += xenfs.o
 
-xenfs-y			  = super.o xenbus.o
+xenfs-y			  = super.o
 xenfs-$(CONFIG_XEN_DOM0) += xenstored.o
diff --git a/drivers/xen/xenfs/super.c b/drivers/xen/xenfs/super.c
index a55fbf9..a84b53c 100644
--- a/drivers/xen/xenfs/super.c
+++ b/drivers/xen/xenfs/super.c
@@ -17,6 +17,7 @@
 
 #include "xenfs.h"
 #include "../privcmd.h"
+#include "../xenbus/xenbus_comms.h"
 
 #include <asm/xen/hypervisor.h>
 
@@ -83,7 +84,7 @@ static int xenfs_fill_super(struct super_block *sb, void *data, int silent)
 {
 	static struct tree_descr xenfs_files[] = {
 		[1] = {},
-		{ "xenbus", &xenbus_file_ops, S_IRUSR|S_IWUSR },
+		{ "xenbus", &xen_xenbus_fops, S_IRUSR|S_IWUSR },
 		{ "capabilities", &capabilities_file_ops, S_IRUGO },
 		{ "privcmd", &xen_privcmd_fops, S_IRUSR|S_IWUSR },
 		{""},
diff --git a/drivers/xen/xenfs/xenfs.h b/drivers/xen/xenfs/xenfs.h
index 5056306..6b80c77 100644
--- a/drivers/xen/xenfs/xenfs.h
+++ b/drivers/xen/xenfs/xenfs.h
@@ -1,7 +1,6 @@
 #ifndef _XENFS_XENBUS_H
 #define _XENFS_XENBUS_H
 
-extern const struct file_operations xenbus_file_ops;
 extern const struct file_operations xsd_kva_file_ops;
 extern const struct file_operations xsd_port_file_ops;
 
-- 
1.7.7.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Dec 10 18:31:26 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 10 Dec 2011 18:31:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZRhD-0001Sk-Ci; Sat, 10 Dec 2011 18:30:51 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <bastian@waldi.eu.org>) id 1RZRhB-0001Rp-K1
	for xen-devel@lists.xensource.com; Sat, 10 Dec 2011 18:30:49 +0000
X-Env-Sender: bastian@waldi.eu.org
X-Msg-Ref: server-11.tower-182.messagelabs.com!1323541797!6689733!1
X-Originating-IP: [82.139.201.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3323 invoked from network); 10 Dec 2011 18:29:58 -0000
Received: from wavehammer.waldi.eu.org (HELO wavehammer.waldi.eu.org)
	(82.139.201.20)
	by server-11.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 10 Dec 2011 18:29:58 -0000
Received: by wavehammer.waldi.eu.org (Postfix, from userid 1000)
	id A5BC4540FF; Sat, 10 Dec 2011 19:29:56 +0100 (CET)
From: Bastian Blank <waldi@debian.org>
To: xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org
Date: Sat, 10 Dec 2011 19:29:47 +0100
Message-Id: <1323541791-18006-3-git-send-email-waldi@debian.org>
X-Mailer: git-send-email 1.7.7.3
In-Reply-To: <1323541791-18006-1-git-send-email-waldi@debian.org>
References: <1323541791-18006-1-git-send-email-waldi@debian.org>
Cc: konrad.wilk@oracle.com
Subject: [Xen-devel] [PATCH 2/6] xen: Add xenbus device driver
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Access to xenbus is currently handled via xenfs. This adds a device
driver for xenbus and makes xenfs use this code.

Signed-off-by: Bastian Blank <waldi@debian.org>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 drivers/xen/xenbus/Makefile                        |    1 +
 drivers/xen/xenbus/xenbus_comms.h                  |    4 ++
 .../xenbus.c => xenbus/xenbus_dev_frontend.c}      |   37 ++++++++++++++++++--
 drivers/xen/xenfs/Makefile                         |    2 +-
 drivers/xen/xenfs/super.c                          |    3 +-
 drivers/xen/xenfs/xenfs.h                          |    1 -
 6 files changed, 42 insertions(+), 6 deletions(-)
 rename drivers/xen/{xenfs/xenbus.c => xenbus/xenbus_dev_frontend.c} (95%)

diff --git a/drivers/xen/xenbus/Makefile b/drivers/xen/xenbus/Makefile
index 8dca685..a2ea363 100644
--- a/drivers/xen/xenbus/Makefile
+++ b/drivers/xen/xenbus/Makefile
@@ -1,4 +1,5 @@
 obj-y	+= xenbus.o
+obj-y	+= xenbus_dev_frontend.o
 
 xenbus-objs =
 xenbus-objs += xenbus_client.o
diff --git a/drivers/xen/xenbus/xenbus_comms.h b/drivers/xen/xenbus/xenbus_comms.h
index c21db75..6e42800 100644
--- a/drivers/xen/xenbus/xenbus_comms.h
+++ b/drivers/xen/xenbus/xenbus_comms.h
@@ -31,6 +31,8 @@
 #ifndef _XENBUS_COMMS_H
 #define _XENBUS_COMMS_H
 
+#include <linux/fs.h>
+
 int xs_init(void);
 int xb_init_comms(void);
 
@@ -43,4 +45,6 @@ int xs_input_avail(void);
 extern struct xenstore_domain_interface *xen_store_interface;
 extern int xen_store_evtchn;
 
+extern const struct file_operations xen_xenbus_fops;
+
 #endif /* _XENBUS_COMMS_H */
diff --git a/drivers/xen/xenfs/xenbus.c b/drivers/xen/xenbus/xenbus_dev_frontend.c
similarity index 95%
rename from drivers/xen/xenfs/xenbus.c
rename to drivers/xen/xenbus/xenbus_dev_frontend.c
index bbd000f..fb30cff 100644
--- a/drivers/xen/xenfs/xenbus.c
+++ b/drivers/xen/xenbus/xenbus_dev_frontend.c
@@ -52,13 +52,16 @@
 #include <linux/namei.h>
 #include <linux/string.h>
 #include <linux/slab.h>
+#include <linux/miscdevice.h>
+#include <linux/module.h>
 
-#include "xenfs.h"
-#include "../xenbus/xenbus_comms.h"
+#include "xenbus_comms.h"
 
 #include <xen/xenbus.h>
 #include <asm/xen/hypervisor.h>
 
+MODULE_LICENSE("GPL");
+
 /*
  * An element of a list of outstanding transactions, for which we're
  * still waiting a reply.
@@ -583,7 +586,7 @@ static unsigned int xenbus_file_poll(struct file *file, poll_table *wait)
 	return 0;
 }
 
-const struct file_operations xenbus_file_ops = {
+const struct file_operations xen_xenbus_fops = {
 	.read = xenbus_file_read,
 	.write = xenbus_file_write,
 	.open = xenbus_file_open,
@@ -591,3 +594,31 @@ const struct file_operations xenbus_file_ops = {
 	.poll = xenbus_file_poll,
 	.llseek = no_llseek,
 };
+EXPORT_SYMBOL_GPL(xen_xenbus_fops);
+
+static struct miscdevice xenbus_dev = {
+	.minor = MISC_DYNAMIC_MINOR,
+	.name = "xen/xenbus",
+	.fops = &xen_xenbus_fops,
+};
+
+static int __init xenbus_init(void)
+{
+	int err;
+
+	if (!xen_domain())
+		return -ENODEV;
+
+	err = misc_register(&xenbus_dev);
+	if (err)
+		printk(KERN_ERR "Could not register xenbus device\n");
+	return err;
+}
+
+static void __exit xenbus_exit(void)
+{
+	misc_deregister(&xenbus_dev);
+}
+
+module_init(xenbus_init);
+module_exit(xenbus_exit);
diff --git a/drivers/xen/xenfs/Makefile b/drivers/xen/xenfs/Makefile
index 5d45ff1..b019865 100644
--- a/drivers/xen/xenfs/Makefile
+++ b/drivers/xen/xenfs/Makefile
@@ -1,4 +1,4 @@
 obj-$(CONFIG_XENFS) += xenfs.o
 
-xenfs-y			  = super.o xenbus.o
+xenfs-y			  = super.o
 xenfs-$(CONFIG_XEN_DOM0) += xenstored.o
diff --git a/drivers/xen/xenfs/super.c b/drivers/xen/xenfs/super.c
index a55fbf9..a84b53c 100644
--- a/drivers/xen/xenfs/super.c
+++ b/drivers/xen/xenfs/super.c
@@ -17,6 +17,7 @@
 
 #include "xenfs.h"
 #include "../privcmd.h"
+#include "../xenbus/xenbus_comms.h"
 
 #include <asm/xen/hypervisor.h>
 
@@ -83,7 +84,7 @@ static int xenfs_fill_super(struct super_block *sb, void *data, int silent)
 {
 	static struct tree_descr xenfs_files[] = {
 		[1] = {},
-		{ "xenbus", &xenbus_file_ops, S_IRUSR|S_IWUSR },
+		{ "xenbus", &xen_xenbus_fops, S_IRUSR|S_IWUSR },
 		{ "capabilities", &capabilities_file_ops, S_IRUGO },
 		{ "privcmd", &xen_privcmd_fops, S_IRUSR|S_IWUSR },
 		{""},
diff --git a/drivers/xen/xenfs/xenfs.h b/drivers/xen/xenfs/xenfs.h
index 5056306..6b80c77 100644
--- a/drivers/xen/xenfs/xenfs.h
+++ b/drivers/xen/xenfs/xenfs.h
@@ -1,7 +1,6 @@
 #ifndef _XENFS_XENBUS_H
 #define _XENFS_XENBUS_H
 
-extern const struct file_operations xenbus_file_ops;
 extern const struct file_operations xsd_kva_file_ops;
 extern const struct file_operations xsd_port_file_ops;
 
-- 
1.7.7.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Dec 10 18:31:26 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 10 Dec 2011 18:31:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZRhE-0001TD-Ai; Sat, 10 Dec 2011 18:30:52 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <bastian@waldi.eu.org>) id 1RZRhC-0001Rt-LA
	for xen-devel@lists.xensource.com; Sat, 10 Dec 2011 18:30:50 +0000
X-Env-Sender: bastian@waldi.eu.org
X-Msg-Ref: server-2.tower-182.messagelabs.com!1323541798!6701553!1
X-Originating-IP: [82.139.201.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11289 invoked from network); 10 Dec 2011 18:29:59 -0000
Received: from wavehammer.waldi.eu.org (HELO wavehammer.waldi.eu.org)
	(82.139.201.20)
	by server-2.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 10 Dec 2011 18:29:59 -0000
Received: by wavehammer.waldi.eu.org (Postfix, from userid 1000)
	id 1B63A54270; Sat, 10 Dec 2011 19:29:57 +0100 (CET)
From: Bastian Blank <waldi@debian.org>
To: xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org
Date: Sat, 10 Dec 2011 19:29:51 +0100
Message-Id: <1323541791-18006-7-git-send-email-waldi@debian.org>
X-Mailer: git-send-email 1.7.7.3
In-Reply-To: <1323541791-18006-1-git-send-email-waldi@debian.org>
References: <1323541791-18006-1-git-send-email-waldi@debian.org>
Cc: konrad.wilk@oracle.com
Subject: [Xen-devel] [PATCH 6/6] xen/xenbus-backend: Only register device if
	communication ring is local
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Signed-off-by: Bastian Blank <waldi@debian.org>
---
 drivers/xen/xenbus/Makefile             |    2 +-
 drivers/xen/xenbus/xenbus_dev_backend.c |   13 ++-----------
 drivers/xen/xenbus/xenbus_dev_backend.h |    2 ++
 drivers/xen/xenbus/xenbus_probe.c       |   18 ++++++++++++++++++
 4 files changed, 23 insertions(+), 12 deletions(-)
 create mode 100644 drivers/xen/xenbus/xenbus_dev_backend.h

diff --git a/drivers/xen/xenbus/Makefile b/drivers/xen/xenbus/Makefile
index 31e2e90..d751f45 100644
--- a/drivers/xen/xenbus/Makefile
+++ b/drivers/xen/xenbus/Makefile
@@ -7,8 +7,8 @@ xenbus-objs += xenbus_comms.o
 xenbus-objs += xenbus_xs.o
 xenbus-objs += xenbus_probe.o
 
+xenbus-be-objs-$(CONFIG_XEN_BACKEND) += xenbus_dev_backend.o
 xenbus-be-objs-$(CONFIG_XEN_BACKEND) += xenbus_probe_backend.o
 xenbus-objs += $(xenbus-be-objs-y)
 
-obj-$(CONFIG_XEN_BACKEND) += xenbus_dev_backend.o
 obj-$(CONFIG_XEN_XENBUS_FRONTEND) += xenbus_probe_frontend.o
diff --git a/drivers/xen/xenbus/xenbus_dev_backend.c b/drivers/xen/xenbus/xenbus_dev_backend.c
index a2092bd..fb87f1b 100644
--- a/drivers/xen/xenbus/xenbus_dev_backend.c
+++ b/drivers/xen/xenbus/xenbus_dev_backend.c
@@ -3,7 +3,6 @@
 #include <linux/mm.h>
 #include <linux/fs.h>
 #include <linux/miscdevice.h>
-#include <linux/module.h>
 #include <linux/capability.h>
 
 #include <xen/page.h>
@@ -11,8 +10,6 @@
 
 #include "xenbus_comms.h"
 
-MODULE_LICENSE("GPL");
-
 static int xenbus_backend_open(struct inode *inode, struct file *filp)
 {
 	if (!capable(CAP_SYS_ADMIN))
@@ -67,23 +64,17 @@ static struct miscdevice xenbus_backend_dev = {
 	.fops = &xenbus_backend_fops,
 };
 
-static int __init xenbus_backend_init(void)
+int __init xenbus_backend_init(void)
 {
 	int err;
 
-	if (!xen_initial_domain())
-		return -ENODEV;
-
 	err = misc_register(&xenbus_backend_dev);
 	if (err)
 		printk(KERN_ERR "Could not register xenbus backend device\n");
 	return err;
 }
 
-static void __exit xenbus_backend_exit(void)
+void __exit xenbus_backend_exit(void)
 {
 	misc_deregister(&xenbus_backend_dev);
 }
-
-module_init(xenbus_backend_init);
-module_exit(xenbus_backend_exit);
diff --git a/drivers/xen/xenbus/xenbus_dev_backend.h b/drivers/xen/xenbus/xenbus_dev_backend.h
new file mode 100644
index 0000000..d986853
--- /dev/null
+++ b/drivers/xen/xenbus/xenbus_dev_backend.h
@@ -0,0 +1,2 @@
+int xenbus_backend_init(void);
+void xenbus_backend_exit(void);
diff --git a/drivers/xen/xenbus/xenbus_probe.c b/drivers/xen/xenbus/xenbus_probe.c
index 1b178c6..4eff095 100644
--- a/drivers/xen/xenbus/xenbus_probe.c
+++ b/drivers/xen/xenbus/xenbus_probe.c
@@ -60,6 +60,7 @@
 #include <xen/hvm.h>
 
 #include "xenbus_comms.h"
+#include "xenbus_dev_backend.h"
 #include "xenbus_probe.h"
 
 
@@ -641,6 +642,10 @@ EXPORT_SYMBOL_GPL(xenbus_dev_cancel);
 /* A flag to determine if xenstored is 'ready' (i.e. has started) */
 int xenstored_ready;
 
+/* A flag to determine if xenstored is 'local' */
+#ifdef CONFIG_XEN_BACKEND
+static int xenstored_local;
+#endif
 
 int register_xenstore_notifier(struct notifier_block *nb)
 {
@@ -675,6 +680,14 @@ static int __init xenbus_probe_initcall(void)
 	if (!xen_domain())
 		return -ENODEV;
 
+#ifdef CONFIG_XEN_BACKEND
+	if (xenstored_local) {
+		int ret = xenbus_backend_init();
+		if (ret)
+			return ret;
+	}
+#endif
+
 	if (xen_initial_domain() || xen_hvm_domain())
 		return 0;
 
@@ -747,9 +760,14 @@ static int __init xenbus_init(void)
 		if (xen_store_evtchn)
 			xenstored_ready = 1;
 		else {
+#ifdef CONFIG_XEN_BACKEND
+			xenstored_local = 1;
 			err = xenstored_local_init();
 			if (err)
 				goto out_error;
+#else
+			BUG();
+#endif
 		}
 		xen_store_interface = mfn_to_virt(xen_store_mfn);
 	}
-- 
1.7.7.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Dec 10 18:31:26 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 10 Dec 2011 18:31:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZRhE-0001TD-Ai; Sat, 10 Dec 2011 18:30:52 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <bastian@waldi.eu.org>) id 1RZRhC-0001Rt-LA
	for xen-devel@lists.xensource.com; Sat, 10 Dec 2011 18:30:50 +0000
X-Env-Sender: bastian@waldi.eu.org
X-Msg-Ref: server-2.tower-182.messagelabs.com!1323541798!6701553!1
X-Originating-IP: [82.139.201.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11289 invoked from network); 10 Dec 2011 18:29:59 -0000
Received: from wavehammer.waldi.eu.org (HELO wavehammer.waldi.eu.org)
	(82.139.201.20)
	by server-2.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 10 Dec 2011 18:29:59 -0000
Received: by wavehammer.waldi.eu.org (Postfix, from userid 1000)
	id 1B63A54270; Sat, 10 Dec 2011 19:29:57 +0100 (CET)
From: Bastian Blank <waldi@debian.org>
To: xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org
Date: Sat, 10 Dec 2011 19:29:51 +0100
Message-Id: <1323541791-18006-7-git-send-email-waldi@debian.org>
X-Mailer: git-send-email 1.7.7.3
In-Reply-To: <1323541791-18006-1-git-send-email-waldi@debian.org>
References: <1323541791-18006-1-git-send-email-waldi@debian.org>
Cc: konrad.wilk@oracle.com
Subject: [Xen-devel] [PATCH 6/6] xen/xenbus-backend: Only register device if
	communication ring is local
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Signed-off-by: Bastian Blank <waldi@debian.org>
---
 drivers/xen/xenbus/Makefile             |    2 +-
 drivers/xen/xenbus/xenbus_dev_backend.c |   13 ++-----------
 drivers/xen/xenbus/xenbus_dev_backend.h |    2 ++
 drivers/xen/xenbus/xenbus_probe.c       |   18 ++++++++++++++++++
 4 files changed, 23 insertions(+), 12 deletions(-)
 create mode 100644 drivers/xen/xenbus/xenbus_dev_backend.h

diff --git a/drivers/xen/xenbus/Makefile b/drivers/xen/xenbus/Makefile
index 31e2e90..d751f45 100644
--- a/drivers/xen/xenbus/Makefile
+++ b/drivers/xen/xenbus/Makefile
@@ -7,8 +7,8 @@ xenbus-objs += xenbus_comms.o
 xenbus-objs += xenbus_xs.o
 xenbus-objs += xenbus_probe.o
 
+xenbus-be-objs-$(CONFIG_XEN_BACKEND) += xenbus_dev_backend.o
 xenbus-be-objs-$(CONFIG_XEN_BACKEND) += xenbus_probe_backend.o
 xenbus-objs += $(xenbus-be-objs-y)
 
-obj-$(CONFIG_XEN_BACKEND) += xenbus_dev_backend.o
 obj-$(CONFIG_XEN_XENBUS_FRONTEND) += xenbus_probe_frontend.o
diff --git a/drivers/xen/xenbus/xenbus_dev_backend.c b/drivers/xen/xenbus/xenbus_dev_backend.c
index a2092bd..fb87f1b 100644
--- a/drivers/xen/xenbus/xenbus_dev_backend.c
+++ b/drivers/xen/xenbus/xenbus_dev_backend.c
@@ -3,7 +3,6 @@
 #include <linux/mm.h>
 #include <linux/fs.h>
 #include <linux/miscdevice.h>
-#include <linux/module.h>
 #include <linux/capability.h>
 
 #include <xen/page.h>
@@ -11,8 +10,6 @@
 
 #include "xenbus_comms.h"
 
-MODULE_LICENSE("GPL");
-
 static int xenbus_backend_open(struct inode *inode, struct file *filp)
 {
 	if (!capable(CAP_SYS_ADMIN))
@@ -67,23 +64,17 @@ static struct miscdevice xenbus_backend_dev = {
 	.fops = &xenbus_backend_fops,
 };
 
-static int __init xenbus_backend_init(void)
+int __init xenbus_backend_init(void)
 {
 	int err;
 
-	if (!xen_initial_domain())
-		return -ENODEV;
-
 	err = misc_register(&xenbus_backend_dev);
 	if (err)
 		printk(KERN_ERR "Could not register xenbus backend device\n");
 	return err;
 }
 
-static void __exit xenbus_backend_exit(void)
+void __exit xenbus_backend_exit(void)
 {
 	misc_deregister(&xenbus_backend_dev);
 }
-
-module_init(xenbus_backend_init);
-module_exit(xenbus_backend_exit);
diff --git a/drivers/xen/xenbus/xenbus_dev_backend.h b/drivers/xen/xenbus/xenbus_dev_backend.h
new file mode 100644
index 0000000..d986853
--- /dev/null
+++ b/drivers/xen/xenbus/xenbus_dev_backend.h
@@ -0,0 +1,2 @@
+int xenbus_backend_init(void);
+void xenbus_backend_exit(void);
diff --git a/drivers/xen/xenbus/xenbus_probe.c b/drivers/xen/xenbus/xenbus_probe.c
index 1b178c6..4eff095 100644
--- a/drivers/xen/xenbus/xenbus_probe.c
+++ b/drivers/xen/xenbus/xenbus_probe.c
@@ -60,6 +60,7 @@
 #include <xen/hvm.h>
 
 #include "xenbus_comms.h"
+#include "xenbus_dev_backend.h"
 #include "xenbus_probe.h"
 
 
@@ -641,6 +642,10 @@ EXPORT_SYMBOL_GPL(xenbus_dev_cancel);
 /* A flag to determine if xenstored is 'ready' (i.e. has started) */
 int xenstored_ready;
 
+/* A flag to determine if xenstored is 'local' */
+#ifdef CONFIG_XEN_BACKEND
+static int xenstored_local;
+#endif
 
 int register_xenstore_notifier(struct notifier_block *nb)
 {
@@ -675,6 +680,14 @@ static int __init xenbus_probe_initcall(void)
 	if (!xen_domain())
 		return -ENODEV;
 
+#ifdef CONFIG_XEN_BACKEND
+	if (xenstored_local) {
+		int ret = xenbus_backend_init();
+		if (ret)
+			return ret;
+	}
+#endif
+
 	if (xen_initial_domain() || xen_hvm_domain())
 		return 0;
 
@@ -747,9 +760,14 @@ static int __init xenbus_init(void)
 		if (xen_store_evtchn)
 			xenstored_ready = 1;
 		else {
+#ifdef CONFIG_XEN_BACKEND
+			xenstored_local = 1;
 			err = xenstored_local_init();
 			if (err)
 				goto out_error;
+#else
+			BUG();
+#endif
 		}
 		xen_store_interface = mfn_to_virt(xen_store_mfn);
 	}
-- 
1.7.7.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Dec 10 18:31:27 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 10 Dec 2011 18:31:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZRhD-0001Sd-0C; Sat, 10 Dec 2011 18:30:51 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <bastian@waldi.eu.org>) id 1RZRhB-0001Ro-I8
	for xen-devel@lists.xensource.com; Sat, 10 Dec 2011 18:30:49 +0000
X-Env-Sender: bastian@waldi.eu.org
X-Msg-Ref: server-12.tower-182.messagelabs.com!1323541797!6712170!1
X-Originating-IP: [82.139.201.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31570 invoked from network); 10 Dec 2011 18:29:58 -0000
Received: from wavehammer.waldi.eu.org (HELO wavehammer.waldi.eu.org)
	(82.139.201.20)
	by server-12.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 10 Dec 2011 18:29:58 -0000
Received: by wavehammer.waldi.eu.org (Postfix, from userid 1000)
	id C0CD554229; Sat, 10 Dec 2011 19:29:56 +0100 (CET)
From: Bastian Blank <waldi@debian.org>
To: xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org
Date: Sat, 10 Dec 2011 19:29:46 +0100
Message-Id: <1323541791-18006-2-git-send-email-waldi@debian.org>
X-Mailer: git-send-email 1.7.7.3
In-Reply-To: <1323541791-18006-1-git-send-email-waldi@debian.org>
References: <1323541791-18006-1-git-send-email-waldi@debian.org>
Cc: konrad.wilk@oracle.com
Subject: [Xen-devel] [PATCH 1/6] xen: Add privcmd device driver
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Access to arbitrary hypercalls is currently provided via xenfs. This
adds a standard character device to handle this. The support in xenfs
remains for backward compatibility and uses the device driver code.

Signed-off-by: Bastian Blank <waldi@debian.org>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 drivers/xen/Kconfig               |    7 ++++++
 drivers/xen/Makefile              |    2 +
 drivers/xen/{xenfs => }/privcmd.c |   39 ++++++++++++++++++++++++++++++++++++-
 drivers/xen/privcmd.h             |    3 ++
 drivers/xen/xenfs/Makefile        |    2 +-
 drivers/xen/xenfs/super.c         |    3 +-
 drivers/xen/xenfs/xenfs.h         |    1 -
 7 files changed, 53 insertions(+), 4 deletions(-)
 rename drivers/xen/{xenfs => }/privcmd.c (92%)
 create mode 100644 drivers/xen/privcmd.h

diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
index 8795480..a1ced52 100644
--- a/drivers/xen/Kconfig
+++ b/drivers/xen/Kconfig
@@ -86,6 +86,7 @@ config XEN_BACKEND
 
 config XENFS
 	tristate "Xen filesystem"
+	select XEN_PRIVCMD
 	default y
 	help
 	  The xen filesystem provides a way for domains to share
@@ -171,4 +172,10 @@ config XEN_PCIDEV_BACKEND
 	  xen-pciback.hide=(03:00.0)(04:00.0)
 
 	  If in doubt, say m.
+
+config XEN_PRIVCMD
+	tristate
+	depends on XEN
+	default m
+
 endmenu
diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
index 974fffd..aa31337 100644
--- a/drivers/xen/Makefile
+++ b/drivers/xen/Makefile
@@ -19,7 +19,9 @@ obj-$(CONFIG_XEN_TMEM)			+= tmem.o
 obj-$(CONFIG_SWIOTLB_XEN)		+= swiotlb-xen.o
 obj-$(CONFIG_XEN_DOM0)			+= pci.o
 obj-$(CONFIG_XEN_PCIDEV_BACKEND)	+= xen-pciback/
+obj-$(CONFIG_XEN_PRIVCMD)		+= xen-privcmd.o
 
 xen-evtchn-y				:= evtchn.o
 xen-gntdev-y				:= gntdev.o
 xen-gntalloc-y				:= gntalloc.o
+xen-privcmd-y				:= privcmd.o
diff --git a/drivers/xen/xenfs/privcmd.c b/drivers/xen/privcmd.c
similarity index 92%
rename from drivers/xen/xenfs/privcmd.c
rename to drivers/xen/privcmd.c
index dbd3b16..4e8d3da 100644
--- a/drivers/xen/xenfs/privcmd.c
+++ b/drivers/xen/privcmd.c
@@ -7,6 +7,7 @@
  */
 
 #include <linux/kernel.h>
+#include <linux/module.h>
 #include <linux/sched.h>
 #include <linux/slab.h>
 #include <linux/string.h>
@@ -18,6 +19,7 @@
 #include <linux/highmem.h>
 #include <linux/pagemap.h>
 #include <linux/seq_file.h>
+#include <linux/miscdevice.h>
 
 #include <asm/pgalloc.h>
 #include <asm/pgtable.h>
@@ -32,6 +34,10 @@
 #include <xen/page.h>
 #include <xen/xen-ops.h>
 
+#include "privcmd.h"
+
+MODULE_LICENSE("GPL");
+
 #ifndef HAVE_ARCH_PRIVCMD_MMAP
 static int privcmd_enforce_singleshot_mapping(struct vm_area_struct *vma);
 #endif
@@ -394,7 +400,38 @@ static int privcmd_enforce_singleshot_mapping(struct vm_area_struct *vma)
 }
 #endif
 
-const struct file_operations privcmd_file_ops = {
+const struct file_operations xen_privcmd_fops = {
+	.owner = THIS_MODULE,
 	.unlocked_ioctl = privcmd_ioctl,
 	.mmap = privcmd_mmap,
 };
+EXPORT_SYMBOL_GPL(xen_privcmd_fops);
+
+static struct miscdevice privcmd_dev = {
+	.minor = MISC_DYNAMIC_MINOR,
+	.name = "xen/privcmd",
+	.fops = &xen_privcmd_fops,
+};
+
+static int __init privcmd_init(void)
+{
+	int err;
+
+	if (!xen_domain())
+		return -ENODEV;
+
+	err = misc_register(&privcmd_dev);
+	if (err != 0) {
+		printk(KERN_ERR "Could not register Xen privcmd device\n");
+		return err;
+	}
+	return 0;
+}
+
+static void __exit privcmd_exit(void)
+{
+	misc_deregister(&privcmd_dev);
+}
+
+module_init(privcmd_init);
+module_exit(privcmd_exit);
diff --git a/drivers/xen/privcmd.h b/drivers/xen/privcmd.h
new file mode 100644
index 0000000..14facae
--- /dev/null
+++ b/drivers/xen/privcmd.h
@@ -0,0 +1,3 @@
+#include <linux/fs.h>
+
+extern const struct file_operations xen_privcmd_fops;
diff --git a/drivers/xen/xenfs/Makefile b/drivers/xen/xenfs/Makefile
index 4fde944..5d45ff1 100644
--- a/drivers/xen/xenfs/Makefile
+++ b/drivers/xen/xenfs/Makefile
@@ -1,4 +1,4 @@
 obj-$(CONFIG_XENFS) += xenfs.o
 
-xenfs-y			  = super.o xenbus.o privcmd.o
+xenfs-y			  = super.o xenbus.o
 xenfs-$(CONFIG_XEN_DOM0) += xenstored.o
diff --git a/drivers/xen/xenfs/super.c b/drivers/xen/xenfs/super.c
index 1aa3897..a55fbf9 100644
--- a/drivers/xen/xenfs/super.c
+++ b/drivers/xen/xenfs/super.c
@@ -16,6 +16,7 @@
 #include <xen/xen.h>
 
 #include "xenfs.h"
+#include "../privcmd.h"
 
 #include <asm/xen/hypervisor.h>
 
@@ -84,7 +85,7 @@ static int xenfs_fill_super(struct super_block *sb, void *data, int silent)
 		[1] = {},
 		{ "xenbus", &xenbus_file_ops, S_IRUSR|S_IWUSR },
 		{ "capabilities", &capabilities_file_ops, S_IRUGO },
-		{ "privcmd", &privcmd_file_ops, S_IRUSR|S_IWUSR },
+		{ "privcmd", &xen_privcmd_fops, S_IRUSR|S_IWUSR },
 		{""},
 	};
 	int rc;
diff --git a/drivers/xen/xenfs/xenfs.h b/drivers/xen/xenfs/xenfs.h
index b68aa62..5056306 100644
--- a/drivers/xen/xenfs/xenfs.h
+++ b/drivers/xen/xenfs/xenfs.h
@@ -2,7 +2,6 @@
 #define _XENFS_XENBUS_H
 
 extern const struct file_operations xenbus_file_ops;
-extern const struct file_operations privcmd_file_ops;
 extern const struct file_operations xsd_kva_file_ops;
 extern const struct file_operations xsd_port_file_ops;
 
-- 
1.7.7.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Dec 10 18:31:27 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 10 Dec 2011 18:31:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZRhD-0001Sd-0C; Sat, 10 Dec 2011 18:30:51 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <bastian@waldi.eu.org>) id 1RZRhB-0001Ro-I8
	for xen-devel@lists.xensource.com; Sat, 10 Dec 2011 18:30:49 +0000
X-Env-Sender: bastian@waldi.eu.org
X-Msg-Ref: server-12.tower-182.messagelabs.com!1323541797!6712170!1
X-Originating-IP: [82.139.201.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31570 invoked from network); 10 Dec 2011 18:29:58 -0000
Received: from wavehammer.waldi.eu.org (HELO wavehammer.waldi.eu.org)
	(82.139.201.20)
	by server-12.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 10 Dec 2011 18:29:58 -0000
Received: by wavehammer.waldi.eu.org (Postfix, from userid 1000)
	id C0CD554229; Sat, 10 Dec 2011 19:29:56 +0100 (CET)
From: Bastian Blank <waldi@debian.org>
To: xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org
Date: Sat, 10 Dec 2011 19:29:46 +0100
Message-Id: <1323541791-18006-2-git-send-email-waldi@debian.org>
X-Mailer: git-send-email 1.7.7.3
In-Reply-To: <1323541791-18006-1-git-send-email-waldi@debian.org>
References: <1323541791-18006-1-git-send-email-waldi@debian.org>
Cc: konrad.wilk@oracle.com
Subject: [Xen-devel] [PATCH 1/6] xen: Add privcmd device driver
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Access to arbitrary hypercalls is currently provided via xenfs. This
adds a standard character device to handle this. The support in xenfs
remains for backward compatibility and uses the device driver code.

Signed-off-by: Bastian Blank <waldi@debian.org>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 drivers/xen/Kconfig               |    7 ++++++
 drivers/xen/Makefile              |    2 +
 drivers/xen/{xenfs => }/privcmd.c |   39 ++++++++++++++++++++++++++++++++++++-
 drivers/xen/privcmd.h             |    3 ++
 drivers/xen/xenfs/Makefile        |    2 +-
 drivers/xen/xenfs/super.c         |    3 +-
 drivers/xen/xenfs/xenfs.h         |    1 -
 7 files changed, 53 insertions(+), 4 deletions(-)
 rename drivers/xen/{xenfs => }/privcmd.c (92%)
 create mode 100644 drivers/xen/privcmd.h

diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
index 8795480..a1ced52 100644
--- a/drivers/xen/Kconfig
+++ b/drivers/xen/Kconfig
@@ -86,6 +86,7 @@ config XEN_BACKEND
 
 config XENFS
 	tristate "Xen filesystem"
+	select XEN_PRIVCMD
 	default y
 	help
 	  The xen filesystem provides a way for domains to share
@@ -171,4 +172,10 @@ config XEN_PCIDEV_BACKEND
 	  xen-pciback.hide=(03:00.0)(04:00.0)
 
 	  If in doubt, say m.
+
+config XEN_PRIVCMD
+	tristate
+	depends on XEN
+	default m
+
 endmenu
diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
index 974fffd..aa31337 100644
--- a/drivers/xen/Makefile
+++ b/drivers/xen/Makefile
@@ -19,7 +19,9 @@ obj-$(CONFIG_XEN_TMEM)			+= tmem.o
 obj-$(CONFIG_SWIOTLB_XEN)		+= swiotlb-xen.o
 obj-$(CONFIG_XEN_DOM0)			+= pci.o
 obj-$(CONFIG_XEN_PCIDEV_BACKEND)	+= xen-pciback/
+obj-$(CONFIG_XEN_PRIVCMD)		+= xen-privcmd.o
 
 xen-evtchn-y				:= evtchn.o
 xen-gntdev-y				:= gntdev.o
 xen-gntalloc-y				:= gntalloc.o
+xen-privcmd-y				:= privcmd.o
diff --git a/drivers/xen/xenfs/privcmd.c b/drivers/xen/privcmd.c
similarity index 92%
rename from drivers/xen/xenfs/privcmd.c
rename to drivers/xen/privcmd.c
index dbd3b16..4e8d3da 100644
--- a/drivers/xen/xenfs/privcmd.c
+++ b/drivers/xen/privcmd.c
@@ -7,6 +7,7 @@
  */
 
 #include <linux/kernel.h>
+#include <linux/module.h>
 #include <linux/sched.h>
 #include <linux/slab.h>
 #include <linux/string.h>
@@ -18,6 +19,7 @@
 #include <linux/highmem.h>
 #include <linux/pagemap.h>
 #include <linux/seq_file.h>
+#include <linux/miscdevice.h>
 
 #include <asm/pgalloc.h>
 #include <asm/pgtable.h>
@@ -32,6 +34,10 @@
 #include <xen/page.h>
 #include <xen/xen-ops.h>
 
+#include "privcmd.h"
+
+MODULE_LICENSE("GPL");
+
 #ifndef HAVE_ARCH_PRIVCMD_MMAP
 static int privcmd_enforce_singleshot_mapping(struct vm_area_struct *vma);
 #endif
@@ -394,7 +400,38 @@ static int privcmd_enforce_singleshot_mapping(struct vm_area_struct *vma)
 }
 #endif
 
-const struct file_operations privcmd_file_ops = {
+const struct file_operations xen_privcmd_fops = {
+	.owner = THIS_MODULE,
 	.unlocked_ioctl = privcmd_ioctl,
 	.mmap = privcmd_mmap,
 };
+EXPORT_SYMBOL_GPL(xen_privcmd_fops);
+
+static struct miscdevice privcmd_dev = {
+	.minor = MISC_DYNAMIC_MINOR,
+	.name = "xen/privcmd",
+	.fops = &xen_privcmd_fops,
+};
+
+static int __init privcmd_init(void)
+{
+	int err;
+
+	if (!xen_domain())
+		return -ENODEV;
+
+	err = misc_register(&privcmd_dev);
+	if (err != 0) {
+		printk(KERN_ERR "Could not register Xen privcmd device\n");
+		return err;
+	}
+	return 0;
+}
+
+static void __exit privcmd_exit(void)
+{
+	misc_deregister(&privcmd_dev);
+}
+
+module_init(privcmd_init);
+module_exit(privcmd_exit);
diff --git a/drivers/xen/privcmd.h b/drivers/xen/privcmd.h
new file mode 100644
index 0000000..14facae
--- /dev/null
+++ b/drivers/xen/privcmd.h
@@ -0,0 +1,3 @@
+#include <linux/fs.h>
+
+extern const struct file_operations xen_privcmd_fops;
diff --git a/drivers/xen/xenfs/Makefile b/drivers/xen/xenfs/Makefile
index 4fde944..5d45ff1 100644
--- a/drivers/xen/xenfs/Makefile
+++ b/drivers/xen/xenfs/Makefile
@@ -1,4 +1,4 @@
 obj-$(CONFIG_XENFS) += xenfs.o
 
-xenfs-y			  = super.o xenbus.o privcmd.o
+xenfs-y			  = super.o xenbus.o
 xenfs-$(CONFIG_XEN_DOM0) += xenstored.o
diff --git a/drivers/xen/xenfs/super.c b/drivers/xen/xenfs/super.c
index 1aa3897..a55fbf9 100644
--- a/drivers/xen/xenfs/super.c
+++ b/drivers/xen/xenfs/super.c
@@ -16,6 +16,7 @@
 #include <xen/xen.h>
 
 #include "xenfs.h"
+#include "../privcmd.h"
 
 #include <asm/xen/hypervisor.h>
 
@@ -84,7 +85,7 @@ static int xenfs_fill_super(struct super_block *sb, void *data, int silent)
 		[1] = {},
 		{ "xenbus", &xenbus_file_ops, S_IRUSR|S_IWUSR },
 		{ "capabilities", &capabilities_file_ops, S_IRUGO },
-		{ "privcmd", &privcmd_file_ops, S_IRUSR|S_IWUSR },
+		{ "privcmd", &xen_privcmd_fops, S_IRUSR|S_IWUSR },
 		{""},
 	};
 	int rc;
diff --git a/drivers/xen/xenfs/xenfs.h b/drivers/xen/xenfs/xenfs.h
index b68aa62..5056306 100644
--- a/drivers/xen/xenfs/xenfs.h
+++ b/drivers/xen/xenfs/xenfs.h
@@ -2,7 +2,6 @@
 #define _XENFS_XENBUS_H
 
 extern const struct file_operations xenbus_file_ops;
-extern const struct file_operations privcmd_file_ops;
 extern const struct file_operations xsd_kva_file_ops;
 extern const struct file_operations xsd_port_file_ops;
 
-- 
1.7.7.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Dec 11 05:32:58 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 11 Dec 2011 05:32:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZc07-0002ZY-ER; Sun, 11 Dec 2011 05:31:03 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RZc06-0002ZT-1r
	for xen-devel@lists.xensource.com; Sun, 11 Dec 2011 05:31:02 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1323581376!47366546!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDc4Mg==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32607 invoked from network); 11 Dec 2011 05:29:36 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Dec 2011 05:29:36 -0000
X-IronPort-AV: E=Sophos;i="4.71,333,1320624000"; 
   d="scan'208";a="9401409"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Dec 2011 05:30:14 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sun, 11 Dec 2011 05:30:14 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RZbzK-0005QS-OB;
	Sun, 11 Dec 2011 05:30:14 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RZbzK-00065k-7w;
	Sun, 11 Dec 2011 05:30:14 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10473-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 11 Dec 2011 05:30:14 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10473: tolerable FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10473 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10473/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf      7 debian-install              fail pass in 10472
 test-amd64-i386-win           7 windows-install             fail pass in 10472
 test-amd64-amd64-xl-sedf 14 guest-localmigrate/x10 fail in 10472 pass in 10471

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-i386-i386-xl-winxpsp3    7 windows-install              fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install          fail never pass
 test-amd64-i386-xl-win7-amd64  7 windows-install              fail  never pass
 test-amd64-i386-xend-winxpsp3  7 windows-install              fail  never pass
 test-amd64-amd64-xl-win7-amd64  7 windows-install              fail never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win-vcpus1  7 windows-install              fail  like 10471
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-i386-win          16 leak-check/check      fail in 10472 never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop           fail in 10472 never pass

version targeted for testing:
 xen                  1c58bb664d8d
baseline version:
 xen                  1c58bb664d8d

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Dec 11 05:32:58 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 11 Dec 2011 05:32:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZc07-0002ZY-ER; Sun, 11 Dec 2011 05:31:03 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RZc06-0002ZT-1r
	for xen-devel@lists.xensource.com; Sun, 11 Dec 2011 05:31:02 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1323581376!47366546!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDc4Mg==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32607 invoked from network); 11 Dec 2011 05:29:36 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Dec 2011 05:29:36 -0000
X-IronPort-AV: E=Sophos;i="4.71,333,1320624000"; 
   d="scan'208";a="9401409"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Dec 2011 05:30:14 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sun, 11 Dec 2011 05:30:14 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RZbzK-0005QS-OB;
	Sun, 11 Dec 2011 05:30:14 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RZbzK-00065k-7w;
	Sun, 11 Dec 2011 05:30:14 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10473-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 11 Dec 2011 05:30:14 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10473: tolerable FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10473 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10473/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf      7 debian-install              fail pass in 10472
 test-amd64-i386-win           7 windows-install             fail pass in 10472
 test-amd64-amd64-xl-sedf 14 guest-localmigrate/x10 fail in 10472 pass in 10471

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-i386-i386-xl-winxpsp3    7 windows-install              fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install          fail never pass
 test-amd64-i386-xl-win7-amd64  7 windows-install              fail  never pass
 test-amd64-i386-xend-winxpsp3  7 windows-install              fail  never pass
 test-amd64-amd64-xl-win7-amd64  7 windows-install              fail never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win-vcpus1  7 windows-install              fail  like 10471
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-i386-win          16 leak-check/check      fail in 10472 never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop           fail in 10472 never pass

version targeted for testing:
 xen                  1c58bb664d8d
baseline version:
 xen                  1c58bb664d8d

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Dec 11 06:07:52 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 11 Dec 2011 06:07:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZcYv-0002qI-Ii; Sun, 11 Dec 2011 06:07:01 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <annie.li@oracle.com>) id 1RZcYt-0002qA-PS
	for xen-devel@lists.xensource.com; Sun, 11 Dec 2011 06:06:59 +0000
X-Env-Sender: annie.li@oracle.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1323583554!58438572!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQyODExNQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24208 invoked from network); 11 Dec 2011 06:05:55 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-15.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Dec 2011 06:05:55 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pBB667q4027880
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sun, 11 Dec 2011 06:06:08 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pBB663YW021594
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Sun, 11 Dec 2011 06:06:04 GMT
Received: from abhmt103.oracle.com (abhmt103.oracle.com [141.146.116.55])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pBB65tBH017591; Sun, 11 Dec 2011 00:05:56 -0600
Received: from [123.113.70.102] (/123.113.70.102)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Sat, 10 Dec 2011 22:05:55 -0800
Message-ID: <4EE44831.8060002@oracle.com>
Date: Sun, 11 Dec 2011 14:05:37 +0800
From: ANNIE LI <annie.li@oracle.com>
Organization: Oracle Corporation
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.9.2.24) Gecko/20111103 Thunderbird/3.1.16
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1323430321-5465-1-git-send-email-annie.li@oracle.com>	
	<1323430372-5503-1-git-send-email-annie.li@oracle.com>
	<1323452339.20077.92.camel@zakaz.uk.xensource.com>
In-Reply-To: <1323452339.20077.92.camel@zakaz.uk.xensource.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090209.4EE44851.0016,ss=1,re=0.000,fgs=0
Cc: "jeremy@goop.org" <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	"kurt.hackel@oracle.com" <kurt.hackel@oracle.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Paul Durrant <Paul.Durrant@citrix.com>
Subject: Re: [Xen-devel] [PATCH V3 1/2] xen/granttable: Support sub-page
	grants
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com



On 2011-12-10 1:38, Ian Campbell wrote:
> On Fri, 2011-12-09 at 11:32 +0000, annie.li@oracle.com wrote:
>> -- They can't be used to map the page (so can only be used in a GNTTABOP_copy
>>         hypercall).
>>      -- It's possible to grant access with a finer granularity than whole pages.
>>      -- Xen guarantees that they can be revoked quickly (a normal map grant can
>>         only be revoked with the cooperation of the domain which has been granted
>>         access).
>>
>> Signed-off-by: Annie Li<annie.li@oracle.com>
>> ---
>>   drivers/xen/grant-table.c |   71 +++++++++++++++++++++++++++++++++++++++++++++
>>   include/xen/grant_table.h |   13 ++++++++
>>   2 files changed, 84 insertions(+), 0 deletions(-)
>>
>> diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
>> index bd325fd..0ac16fa 100644
>> --- a/drivers/xen/grant-table.c
>> +++ b/drivers/xen/grant-table.c
>> @@ -120,6 +120,16 @@ struct gnttab_ops {
>>   	 * by bit operations.
>>   	 */
>>   	int (*query_foreign_access)(grant_ref_t);
>> +	/*
>> +	 * Grant a domain to access a range of bytes within the page referred by
>> +	 * an available grant entry. First parameter is grant entry reference
>> +	 * number, second one is id of grantee domain, third one is frame
>> +	 * address of subpage grant, forth one is grant type and flag
>> +	 * information, fifth one is offset of the range of bytes, and last one
>> +	 * is length of bytes to be accessed.
>> +	 */
>> +	void (*update_subpage_entry)(grant_ref_t, domid_t, unsigned long, int,
>> +				     unsigned, unsigned);
> Please can you name the arguments here and then refer to them by name in
> the comments instead of all this "First parameter", "second one" stuff.
>
> Similarly for the existing comments sorry I didn't notice this in
> previous review.
Ok, I will do this in another separate patch.

Thanks,
Annie.
> Ian.
>
>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Dec 11 06:07:52 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 11 Dec 2011 06:07:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZcYv-0002qI-Ii; Sun, 11 Dec 2011 06:07:01 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <annie.li@oracle.com>) id 1RZcYt-0002qA-PS
	for xen-devel@lists.xensource.com; Sun, 11 Dec 2011 06:06:59 +0000
X-Env-Sender: annie.li@oracle.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1323583554!58438572!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQyODExNQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24208 invoked from network); 11 Dec 2011 06:05:55 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-15.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Dec 2011 06:05:55 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pBB667q4027880
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sun, 11 Dec 2011 06:06:08 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pBB663YW021594
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Sun, 11 Dec 2011 06:06:04 GMT
Received: from abhmt103.oracle.com (abhmt103.oracle.com [141.146.116.55])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pBB65tBH017591; Sun, 11 Dec 2011 00:05:56 -0600
Received: from [123.113.70.102] (/123.113.70.102)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Sat, 10 Dec 2011 22:05:55 -0800
Message-ID: <4EE44831.8060002@oracle.com>
Date: Sun, 11 Dec 2011 14:05:37 +0800
From: ANNIE LI <annie.li@oracle.com>
Organization: Oracle Corporation
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.9.2.24) Gecko/20111103 Thunderbird/3.1.16
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1323430321-5465-1-git-send-email-annie.li@oracle.com>	
	<1323430372-5503-1-git-send-email-annie.li@oracle.com>
	<1323452339.20077.92.camel@zakaz.uk.xensource.com>
In-Reply-To: <1323452339.20077.92.camel@zakaz.uk.xensource.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090209.4EE44851.0016,ss=1,re=0.000,fgs=0
Cc: "jeremy@goop.org" <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	"kurt.hackel@oracle.com" <kurt.hackel@oracle.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Paul Durrant <Paul.Durrant@citrix.com>
Subject: Re: [Xen-devel] [PATCH V3 1/2] xen/granttable: Support sub-page
	grants
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com



On 2011-12-10 1:38, Ian Campbell wrote:
> On Fri, 2011-12-09 at 11:32 +0000, annie.li@oracle.com wrote:
>> -- They can't be used to map the page (so can only be used in a GNTTABOP_copy
>>         hypercall).
>>      -- It's possible to grant access with a finer granularity than whole pages.
>>      -- Xen guarantees that they can be revoked quickly (a normal map grant can
>>         only be revoked with the cooperation of the domain which has been granted
>>         access).
>>
>> Signed-off-by: Annie Li<annie.li@oracle.com>
>> ---
>>   drivers/xen/grant-table.c |   71 +++++++++++++++++++++++++++++++++++++++++++++
>>   include/xen/grant_table.h |   13 ++++++++
>>   2 files changed, 84 insertions(+), 0 deletions(-)
>>
>> diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
>> index bd325fd..0ac16fa 100644
>> --- a/drivers/xen/grant-table.c
>> +++ b/drivers/xen/grant-table.c
>> @@ -120,6 +120,16 @@ struct gnttab_ops {
>>   	 * by bit operations.
>>   	 */
>>   	int (*query_foreign_access)(grant_ref_t);
>> +	/*
>> +	 * Grant a domain to access a range of bytes within the page referred by
>> +	 * an available grant entry. First parameter is grant entry reference
>> +	 * number, second one is id of grantee domain, third one is frame
>> +	 * address of subpage grant, forth one is grant type and flag
>> +	 * information, fifth one is offset of the range of bytes, and last one
>> +	 * is length of bytes to be accessed.
>> +	 */
>> +	void (*update_subpage_entry)(grant_ref_t, domid_t, unsigned long, int,
>> +				     unsigned, unsigned);
> Please can you name the arguments here and then refer to them by name in
> the comments instead of all this "First parameter", "second one" stuff.
>
> Similarly for the existing comments sorry I didn't notice this in
> previous review.
Ok, I will do this in another separate patch.

Thanks,
Annie.
> Ian.
>
>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Dec 11 11:49:20 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 11 Dec 2011 11:49:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZhtC-0004JI-Mh; Sun, 11 Dec 2011 11:48:18 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <lersek@redhat.com>) id 1RZhtB-0004JD-0b
	for xen-devel@lists.xensource.com; Sun, 11 Dec 2011 11:48:17 +0000
X-Env-Sender: lersek@redhat.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1323604044!6989935!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDYzMDk=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30706 invoked from network); 11 Dec 2011 11:47:25 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-7.tower-216.messagelabs.com with SMTP;
	11 Dec 2011 11:47:25 -0000
Received: from int-mx12.intmail.prod.int.phx2.redhat.com
	(int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id pBBBl9Jk003797
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sun, 11 Dec 2011 06:47:09 -0500
Received: from lacos-laptop.redhat.com (vpn1-6-116.ams2.redhat.com
	[10.36.6.116])
	by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id pBBBl5Dw011101; Sun, 11 Dec 2011 06:47:06 -0500
From: Laszlo Ersek <lersek@redhat.com>
To: konrad.wilk@oracle.com, jeremy@goop.org, xen-devel@lists.xensource.com,
	virtualization@lists.linux-foundation.org, netdev@vger.kernel.org,
	linux-kernel@vger.kernel.org
Date: Sun, 11 Dec 2011 12:48:59 +0100
Message-Id: <1323604139-3890-1-git-send-email-lersek@redhat.com>
In-Reply-To: <20111209.192439.275865894437319638.davem@davemloft.net>
References: <20111209.192439.275865894437319638.davem@davemloft.net>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.25
Subject: [Xen-devel] [PATCH net-next v4] xen-netfront: delay gARP until
	backend switches to Connected
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

After a guest is live migrated, the xen-netfront driver emits a gratuitous
ARP message, so that networking hardware on the target host's subnet can
take notice, and public routing to the guest is re-established. However,
if the packet appears on the backend interface before the backend is added
to the target host's bridge, the packet is lost, and the migrated guest's
peers become unable to talk to the guest.

A sufficient two-parts condition to prevent the above is:

(1) ensure that the backend only moves to Connected xenbus state after its
hotplug scripts completed, ie. the netback interface got added to the
bridge; and

(2) ensure the frontend only queues the gARP when it sees the backend move
to Connected.

These two together provide complete ordering. Sub-condition (1) is already
satisfied by commit f942dc2552b8 in Linus' tree, based on commit
6b0b80ca7165 from [1].

In general, the full condition is sufficient, not necessary, because,
according to [2], live migration has been working for a long time without
satisfying sub-condition (2). However, after 6b0b80ca7165 was backported
to the RHEL-5 host to ensure (1), (2) still proved necessary in the RHEL-6
guest. This patch intends to provide (2) for upstream.

The Reviewed-by line comes from [3].

[1] git://xenbits.xen.org/people/ianc/linux-2.6.git#upstream/dom0/backend/netback-history
[2] http://old-list-archives.xen.org/xen-devel/2011-06/msg01969.html
[3] http://old-list-archives.xen.org/xen-devel/2011-07/msg00484.html

Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ian Campbell <ian.campbell@citrix.com>
---
 drivers/net/xen-netfront.c |    4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
index d29365a..f033656 100644
--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -1646,7 +1646,6 @@ static void netback_changed(struct xenbus_device *dev,
 	case XenbusStateInitialised:
 	case XenbusStateReconfiguring:
 	case XenbusStateReconfigured:
-	case XenbusStateConnected:
 	case XenbusStateUnknown:
 	case XenbusStateClosed:
 		break;
@@ -1657,6 +1656,9 @@ static void netback_changed(struct xenbus_device *dev,
 		if (xennet_connect(netdev) != 0)
 			break;
 		xenbus_switch_state(dev, XenbusStateConnected);
+		break;
+
+	case XenbusStateConnected:
 		netif_notify_peers(netdev);
 		break;
 
-- 
1.7.4.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Dec 11 11:49:20 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 11 Dec 2011 11:49:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZhtC-0004JI-Mh; Sun, 11 Dec 2011 11:48:18 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <lersek@redhat.com>) id 1RZhtB-0004JD-0b
	for xen-devel@lists.xensource.com; Sun, 11 Dec 2011 11:48:17 +0000
X-Env-Sender: lersek@redhat.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1323604044!6989935!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDYzMDk=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30706 invoked from network); 11 Dec 2011 11:47:25 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-7.tower-216.messagelabs.com with SMTP;
	11 Dec 2011 11:47:25 -0000
Received: from int-mx12.intmail.prod.int.phx2.redhat.com
	(int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id pBBBl9Jk003797
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sun, 11 Dec 2011 06:47:09 -0500
Received: from lacos-laptop.redhat.com (vpn1-6-116.ams2.redhat.com
	[10.36.6.116])
	by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id pBBBl5Dw011101; Sun, 11 Dec 2011 06:47:06 -0500
From: Laszlo Ersek <lersek@redhat.com>
To: konrad.wilk@oracle.com, jeremy@goop.org, xen-devel@lists.xensource.com,
	virtualization@lists.linux-foundation.org, netdev@vger.kernel.org,
	linux-kernel@vger.kernel.org
Date: Sun, 11 Dec 2011 12:48:59 +0100
Message-Id: <1323604139-3890-1-git-send-email-lersek@redhat.com>
In-Reply-To: <20111209.192439.275865894437319638.davem@davemloft.net>
References: <20111209.192439.275865894437319638.davem@davemloft.net>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.25
Subject: [Xen-devel] [PATCH net-next v4] xen-netfront: delay gARP until
	backend switches to Connected
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

After a guest is live migrated, the xen-netfront driver emits a gratuitous
ARP message, so that networking hardware on the target host's subnet can
take notice, and public routing to the guest is re-established. However,
if the packet appears on the backend interface before the backend is added
to the target host's bridge, the packet is lost, and the migrated guest's
peers become unable to talk to the guest.

A sufficient two-parts condition to prevent the above is:

(1) ensure that the backend only moves to Connected xenbus state after its
hotplug scripts completed, ie. the netback interface got added to the
bridge; and

(2) ensure the frontend only queues the gARP when it sees the backend move
to Connected.

These two together provide complete ordering. Sub-condition (1) is already
satisfied by commit f942dc2552b8 in Linus' tree, based on commit
6b0b80ca7165 from [1].

In general, the full condition is sufficient, not necessary, because,
according to [2], live migration has been working for a long time without
satisfying sub-condition (2). However, after 6b0b80ca7165 was backported
to the RHEL-5 host to ensure (1), (2) still proved necessary in the RHEL-6
guest. This patch intends to provide (2) for upstream.

The Reviewed-by line comes from [3].

[1] git://xenbits.xen.org/people/ianc/linux-2.6.git#upstream/dom0/backend/netback-history
[2] http://old-list-archives.xen.org/xen-devel/2011-06/msg01969.html
[3] http://old-list-archives.xen.org/xen-devel/2011-07/msg00484.html

Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ian Campbell <ian.campbell@citrix.com>
---
 drivers/net/xen-netfront.c |    4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
index d29365a..f033656 100644
--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -1646,7 +1646,6 @@ static void netback_changed(struct xenbus_device *dev,
 	case XenbusStateInitialised:
 	case XenbusStateReconfiguring:
 	case XenbusStateReconfigured:
-	case XenbusStateConnected:
 	case XenbusStateUnknown:
 	case XenbusStateClosed:
 		break;
@@ -1657,6 +1656,9 @@ static void netback_changed(struct xenbus_device *dev,
 		if (xennet_connect(netdev) != 0)
 			break;
 		xenbus_switch_state(dev, XenbusStateConnected);
+		break;
+
+	case XenbusStateConnected:
 		netif_notify_peers(netdev);
 		break;
 
-- 
1.7.4.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Dec 11 12:54:32 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 11 Dec 2011 12:54:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZiuW-0004jY-DO; Sun, 11 Dec 2011 12:53:44 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pasik@iki.fi>) id 1RZiuV-0004jS-1D
	for xen-devel@lists.xensource.com; Sun, 11 Dec 2011 12:53:43 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-4.tower-21.messagelabs.com!1323607970!1464313!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA0MTMxODk=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11918 invoked from network); 11 Dec 2011 12:52:51 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-4.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Dec 2011 12:52:51 -0000
X-Originating-Ip: [194.89.68.22]
Received: from ydin.reaktio.net (reaktio.net [194.89.68.22])
	by smtp.tele.fi (Postfix) with ESMTP id AEFC72C7C;
	Sun, 11 Dec 2011 14:52:48 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 0EB7120097; Sun, 11 Dec 2011 14:52:48 +0200 (EET)
Date: Sun, 11 Dec 2011 14:52:47 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Roderick Colenbrander <thunderbird2k@gmail.com>
Message-ID: <20111211125247.GQ12984@reaktio.net>
References: <CAEc3jaAa7y8C2NNBn1=L3AhS0uuYFP6ze8o1cZ9yG2VYHx6qMA@mail.gmail.com>
	<4ED5215D.1010403@hfp.de>
	<20111129230212.GA23958@andromeda.dapyr.net>
	<CAEc3jaAO0JhtOt6phQHwtE_A+NF7uGHGZ8uJv3BirEYybfVceg@mail.gmail.com>
	<CAEc3jaACffpr9D1Hq_012vHAGhPLEfvsZjh7YyJ=Q-3FdtHS0Q@mail.gmail.com>
	<CAPbh3rtOQ1HTPReqYcpE3vzk+-na0MTLLHZD15=Fg4yxB+ypaA@mail.gmail.com>
	<CAEc3jaBdQKmVJToNZRf+25GtJXqGc274ieHf_yHKRJ+YOKWdgA@mail.gmail.com>
	<20111208234624.GD32474@konrad-lan>
	<CAEc3jaC9=HiMoxSYZmXKRzoFcMYRaT9jrX3m1ZQO+M8CrH35Fg@mail.gmail.com>
	<CAEc3jaBBYBME0G3Ku_sTvzQz+oKQnpBPffA+bRUKxxRPABAeww@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAEc3jaBBYBME0G3Ku_sTvzQz+oKQnpBPffA+bRUKxxRPABAeww@mail.gmail.com>
User-Agent: Mutt/1.5.18 (2008-05-17)
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>, xen-devel@lists.xensource.com,
	Andreas Kinzler <ml-xen-devel@hfp.de>
Subject: Re: [Xen-devel] Questions about GPLPV stability tests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Dec 09, 2011 at 02:02:31PM -0800, Roderick Colenbrander wrote:
> One interesting observation. This morning I had another of my stress
> machines with the problem. I never had it on this problem before and
> it didn't have any of the new logging / software updates yet.
> =

> The system was in the same state as the other machine which I reported
> about before. I tried SysRq stuff and other things. While I was about
> to reboot the system, a login prompt appeared again on the VGA. I
> don't know whether any of the stuff I did triggered it or not. Anyway
> it means Linux is not really dead. I tried logging, but I don't even
> see characters appearing. The system feels to be very, very, very
> slow.
> =


Hmm.. I wonder if this is the same issue I'm sometimes seeing on my laptop.=
. =

suddenly it starts becoming slower, and after a while it's *very* slow.. =

not dead, but unusably slow..

I haven't had time to (try to) debug it..

-- Pasi


> The other tests are still running.
> =

> Roderick
> =

> On Thu, Dec 8, 2011 at 5:33 PM, Roderick Colenbrander
> <thunderbird2k@gmail.com> wrote:
> > On Thu, Dec 8, 2011 at 11:46 PM, Konrad Rzeszutek Wilk
> > <konrad@darnok.org> wrote:
> >> On Wed, Dec 07, 2011 at 08:44:19PM +0000, Roderick Colenbrander wrote:
> >>> On Wed, Dec 7, 2011 at 8:38 PM, Konrad Rzeszutek Wilk <konrad@darnok.=
org> wrote:
> >>> >> It took about a week, but the systems went down again. Linux is do=
wn,
> >>> >> but the hypervisor is still reachable on the serial console. Is th=
ere
> >>> >> anything interesting to dump from there?
> >>> >>
> >>> > Just the interrupts information. I think that is Ctrl-A, Ctrl-A,
> >>> > Ctrl-A, and then '*' to capture everything (I don't remember the ri=
ght
> >>> > one for just interrupts).
> >>>
> >>> Here's the interrupt information:
> >>> (XEN) [2011-12-06 19:13:37] [i: dump interrupt bindings]
> >>> (XEN) [2011-12-06 19:13:37] Guest interrupt information:
> >>> (XEN) [2011-12-06 19:13:37] =A0 =A0IRQ: =A0 0
> >>> affinity:00000000,00000000,00000000,00000001 vec:f0 type=3DIO-APIC-ed=
ge
> >>> =A0 status=3D00000000 mapped, unbound
> >>> (XEN) [2011-12-06 19:13:37] =A0 =A0IRQ: =A0 1
> >>> affinity:00000000,00000000,00000000,00000001 vec:30 type=3DIO-APIC-ed=
ge
> >>> =A0 status=3D00000014 in-flight=3D0 domain-list=3D0: =A01(-S--),
> >>> (XEN) [2011-12-06 19:13:37] =A0 =A0IRQ: =A0 2
> >>> affinity:ffffffff,ffffffff,ffffffff,ffffffff vec:e2 type=3DXT-PIC
> >>> =A0 status=3D00000000 mapped, unbound
> >>> (XEN) [2011-12-06 19:13:37] =A0 =A0IRQ: =A0 3
> >>> affinity:00000000,00000000,00000000,00000001 vec:38 type=3DIO-APIC-ed=
ge
> >>> =A0 status=3D00000006 mapped, unbound
> >>> (XEN) [2011-12-06 19:13:37] =A0 =A0IRQ: =A0 4
> >>> affinity:00000000,00000000,00000000,00000001 vec:40 type=3DIO-APIC-ed=
ge
> >>> =A0 status=3D00000002 mapped, unbound
> >>> (XEN) [2011-12-06 19:13:37] =A0 =A0IRQ: =A0 5
> >>> affinity:00000000,00000000,00000000,00000001 vec:f1 type=3DIO-APIC-ed=
ge
> >>> =A0 status=3D00000000 mapped, unbound
> >>> (XEN) [2011-12-06 19:13:37] =A0 =A0IRQ: =A0 6
> >>> affinity:00000000,00000000,00000000,00000001 vec:48 type=3DIO-APIC-ed=
ge
> >>> =A0 status=3D00000002 mapped, unbound
> >>> (XEN) [2011-12-06 19:13:37] =A0 =A0IRQ: =A0 7
> >>> affinity:00000000,00000000,00000000,00000001 vec:50 type=3DIO-APIC-ed=
ge
> >>> =A0 status=3D00000002 mapped, unbound
> >>> (XEN) [2011-12-06 19:13:37] =A0 =A0IRQ: =A0 8
> >>> affinity:00000000,00000000,00000000,00000001 vec:58 type=3DIO-APIC-ed=
ge
> >>> =A0 status=3D00000010 in-flight=3D0 domain-list=3D0: =A08(-S--),
> >>> (XEN) [2011-12-06 19:13:37] =A0 =A0IRQ: =A0 9
> >>> affinity:00000000,00000000,00000000,00000001 vec:60 type=3DIO-APIC-le=
vel
> >>> =A0 status=3D00000010 in-flight=3D0 domain-list=3D0: =A09(-S--),
> >>> (XEN) [2011-12-06 19:13:37] =A0 =A0IRQ: =A010
> >>> affinity:00000000,00000000,00000000,00000001 vec:68 type=3DIO-APIC-ed=
ge
> >>> =A0 status=3D00000002 mapped, unbound
> >>> (XEN) [2011-12-06 19:13:37] =A0 =A0IRQ: =A011
> >>> affinity:00000000,00000000,00000000,00000001 vec:70 type=3DIO-APIC-ed=
ge
> >>> =A0 status=3D00000002 mapped, unbound
> >>> (XEN) [2011-12-06 19:13:37] =A0 =A0IRQ: =A012
> >>> affinity:00000000,00000000,00000000,00000001 vec:78 type=3DIO-APIC-ed=
ge
> >>> =A0 status=3D00000010 in-flight=3D0 domain-list=3D0: 12(-S--),
> >>> (XEN) [2011-12-06 19:13:37] =A0 =A0IRQ: =A013
> >>> affinity:00000000,00000000,00000000,00000001 vec:88 type=3DIO-APIC-ed=
ge
> >>> =A0 status=3D00000002 mapped, unbound
> >>> (XEN) [2011-12-06 19:13:37] =A0 =A0IRQ: =A014
> >>> affinity:00000000,00000000,00000000,00000001 vec:90 type=3DIO-APIC-ed=
ge
> >>> =A0 status=3D00000002 mapped, unbound
> >>> (XEN) [2011-12-06 19:13:37] =A0 =A0IRQ: =A015
> >>> affinity:00000000,00000000,00000000,00000001 vec:98 type=3DIO-APIC-ed=
ge
> >>> =A0 status=3D00000002 mapped, unbound
> >>> (XEN) [2011-12-06 19:13:37] =A0 =A0IRQ: =A016
> >>> affinity:00000000,00000000,00000000,00000001 vec:c8 type=3DIO-APIC-le=
vel
> >>> =A0 status=3D00000010 in-flight=3D0 domain-list=3D0: 16(-S--),1201: 1=
6(--M-),
> >>> (XEN) [2011-12-06 19:13:37] =A0 =A0IRQ: =A018
> >>> affinity:00000000,00000000,00000000,00000001 vec:51 type=3DIO-APIC-le=
vel
> >>> =A0 status=3D00000010 in-flight=3D0 domain-list=3D0: 18(-S--),
> >>> (XEN) [2011-12-06 19:13:37] =A0 =A0IRQ: =A019
> >>> affinity:00000000,00000000,00000000,00000001 vec:d0 type=3DIO-APIC-le=
vel
> >>> =A0 status=3D00000010 in-flight=3D0 domain-list=3D0: 19(-S--),
> >>> (XEN) [2011-12-06 19:13:37] =A0 =A0IRQ: =A021
> >>> affinity:00000000,00000000,00000000,00000001 vec:61 type=3DIO-APIC-le=
vel
> >>> =A0 status=3D00000010 in-flight=3D0 domain-list=3D0: 21(-S--),
> >>> (XEN) [2011-12-06 19:13:37] =A0 =A0IRQ: =A023
> >>> affinity:00000000,00000000,00000000,00000001 vec:59 type=3DIO-APIC-le=
vel
> >>> =A0 status=3D00000010 in-flight=3D1 domain-list=3D0: 23(PS-M),
> >>> (XEN) [2011-12-06 19:13:37] =A0 =A0IRQ: =A024
> >>> affinity:00000000,00000000,00000000,00000001 vec:28 type=3DDMA_MSI
> >>> =A0 status=3D00000000 mapped, unbound
> >>> (XEN) [2011-12-06 19:13:38] =A0 =A0IRQ: =A025
> >>> affinity:00000000,00000000,00000000,00000001 vec:a0 type=3DPCI-MSI
> >>> =A0 status=3D00000002 mapped, unbound
> >>> (XEN) [2011-12-06 19:13:38] =A0 =A0IRQ: =A026
> >>> affinity:00000000,00000000,00000000,00000001 vec:a8 type=3DPCI-MSI
> >>> =A0 status=3D00000002 mapped, unbound
> >>> (XEN) [2011-12-06 19:13:38] =A0 =A0IRQ: =A027
> >>> affinity:00000000,00000000,00000000,00000001 vec:b0 type=3DPCI-MSI
> >>> =A0 status=3D00000002 mapped, unbound
> >>> (XEN) [2011-12-06 19:13:38] =A0 =A0IRQ: =A028
> >>> affinity:00000000,00000000,00000000,00000001 vec:b8 type=3DPCI-MSI
> >>> =A0 status=3D00000002 mapped, unbound
> >>> (XEN) [2011-12-06 19:13:38] =A0 =A0IRQ: =A029
> >>> affinity:00000000,00000000,00000000,00000001 vec:c0 type=3DPCI-MSI
> >>> =A0 status=3D00000002 mapped, unbound
> >>> (XEN) [2011-12-06 19:13:38] =A0 =A0IRQ: =A030
> >>> affinity:00000000,00000000,00000000,00000001 vec:d8 type=3DPCI-MSI
> >>> =A0 status=3D00000014 in-flight=3D0 domain-list=3D0:274(PS--),
> >>> (XEN) [2011-12-06 19:13:38] =A0 =A0IRQ: =A031
> >>> affinity:00000000,00000000,00000000,00000001 vec:21 type=3DPCI-MSI
> >>> =A0 status=3D00000010 in-flight=3D0 domain-list=3D0:273(PS--),
> >>> (XEN) [2011-12-06 19:13:38] =A0 =A0IRQ: =A032
> >>> affinity:00000000,00000000,00000000,00000001 vec:29 type=3DPCI-MSI
> >>> =A0 status=3D00000010 in-flight=3D0 domain-list=3D0:272(PS--),
> >>> (XEN) [2011-12-06 19:13:38] =A0 =A0IRQ: =A033
> >>> affinity:00000000,00000000,00000000,00000001 vec:31 type=3DPCI-MSI
> >>> =A0 status=3D00000010 in-flight=3D0 domain-list=3D0:271(PS--),
> >>> (XEN) [2011-12-06 19:13:38] =A0 =A0IRQ: =A034
> >>> affinity:ffffffff,ffffffff,ffffffff,ffffffff vec:39 type=3DPCI-MSI
> >>> =A0 status=3D00000002 mapped, unbound
> >>> (XEN) [2011-12-06 19:13:38] =A0 =A0IRQ: =A035
> >>> affinity:ffffffff,ffffffff,ffffffff,ffffffff vec:41 type=3DPCI-MSI
> >>> =A0 status=3D00000002 mapped, unbound
> >>> (XEN) [2011-12-06 19:13:38] =A0 =A0IRQ: =A036
> >>> affinity:ffffffff,ffffffff,ffffffff,ffffffff vec:49 type=3DPCI-MSI
> >>> =A0 status=3D00000002 mapped, unbound
> >>> (XEN) [2011-12-06 19:13:38] =A0 =A0IRQ: =A037
> >>> affinity:00000000,00000000,00000000,00000010 vec:65 type=3DPCI-MSI
> >>> =A0 status=3D00000010 in-flight=3D0 domain-list=3D1201: 55(--M-),
> >>> (XEN) [2011-12-06 19:13:38] IO-APIC interrupt information:
> >>> (XEN) [2011-12-06 19:13:38] =A0 =A0 IRQ =A00 Vec240:
> >>> (XEN) [2011-12-06 19:13:38] =A0 =A0 =A0 Apic 0x00, Pin =A02: vector=
=3D240,
> >>> delivery_mode=3D1, dest_mode=3Dlogical, delivery_status=3D0, polarity=
=3D0,
> >>> irr=3D0, trigger=3Dedge, mask=3D0, dest_id:1
> >>> (XEN) [2011-12-06 19:13:38] =A0 =A0 IRQ =A01 Vec 48:
> >>> (XEN) [2011-12-06 19:13:38] =A0 =A0 =A0 Apic 0x00, Pin =A01: vector=
=3D48,
> >>> delivery_mode=3D1, dest_mode=3Dlogical, delivery_status=3D0, polarity=
=3D0,
> >>> irr=3D0, trigger=3Dedge, mask=3D0, dest_id:1
> >>> (XEN) [2011-12-06 19:13:38] =A0 =A0 IRQ =A03 Vec 56:
> >>> (XEN) [2011-12-06 19:13:38] =A0 =A0 =A0 Apic 0x00, Pin =A03: vector=
=3D56,
> >>> delivery_mode=3D1, dest_mode=3Dlogical, delivery_status=3D0, polarity=
=3D0,
> >>> irr=3D0, trigger=3Dedge, mask=3D0, dest_id:1
> >>> (XEN) [2011-12-06 19:13:38] =A0 =A0 IRQ =A04 Vec 64:
> >>> (XEN) [2011-12-06 19:13:38] =A0 =A0 =A0 Apic 0x00, Pin =A04: vector=
=3D64,
> >>> delivery_mode=3D1, dest_mode=3Dlogical, delivery_status=3D0, polarity=
=3D0,
> >>> irr=3D0, trigger=3Dedge, mask=3D0, dest_id:1
> >>> (XEN) [2011-12-06 19:13:38] =A0 =A0 IRQ =A05 Vec241:
> >>> (XEN) [2011-12-06 19:13:38] =A0 =A0 =A0 Apic 0x00, Pin =A05: vector=
=3D241,
> >>> delivery_mode=3D1, dest_mode=3Dlogical, delivery_status=3D0, polarity=
=3D0,
> >>> irr=3D0, trigger=3Dedge, mask=3D0, dest_id:1
> >>> (XEN) [2011-12-06 19:13:38] =A0 =A0 IRQ =A06 Vec 72:
> >>> (XEN) [2011-12-06 19:13:38] =A0 =A0 =A0 Apic 0x00, Pin =A06: vector=
=3D72,
> >>> delivery_mode=3D1, dest_mode=3Dlogical, delivery_status=3D0, polarity=
=3D0,
> >>> irr=3D0, trigger=3Dedge, mask=3D0, dest_id:1
> >>> (XEN) [2011-12-06 19:13:38] =A0 =A0 IRQ =A07 Vec 80:
> >>> (XEN) [2011-12-06 19:13:38] =A0 =A0 =A0 Apic 0x00, Pin =A07: vector=
=3D80,
> >>> delivery_mode=3D1, dest_mode=3Dlogical, delivery_status=3D0, polarity=
=3D0,
> >>> irr=3D0, trigger=3Dedge, mask=3D0, dest_id:1
> >>> (XEN) [2011-12-06 19:13:38] =A0 =A0 IRQ =A08 Vec 88:
> >>> (XEN) [2011-12-06 19:13:38] =A0 =A0 =A0 Apic 0x00, Pin =A08: vector=
=3D88,
> >>> delivery_mode=3D1, dest_mode=3Dlogical, delivery_status=3D0, polarity=
=3D0,
> >>> irr=3D0, trigger=3Dedge, mask=3D0, dest_id:1
> >>> (XEN) [2011-12-06 19:13:38] =A0 =A0 IRQ =A09 Vec 96:
> >>> (XEN) [2011-12-06 19:13:38] =A0 =A0 =A0 Apic 0x00, Pin =A09: vector=
=3D96,
> >>> delivery_mode=3D1, dest_mode=3Dlogical, delivery_status=3D0, polarity=
=3D0,
> >>> irr=3D0, trigger=3Dlevel, mask=3D0, dest_id:1
> >>> (XEN) [2011-12-06 19:13:38] =A0 =A0 IRQ 10 Vec104:
> >>> (XEN) [2011-12-06 19:13:38] =A0 =A0 =A0 Apic 0x00, Pin 10: vector=3D1=
04,
> >>> delivery_mode=3D1, dest_mode=3Dlogical, delivery_status=3D0, polarity=
=3D0,
> >>> irr=3D0, trigger=3Dedge, mask=3D0, dest_id:1
> >>> (XEN) [2011-12-06 19:13:38] =A0 =A0 IRQ 11 Vec112:
> >>> (XEN) [2011-12-06 19:13:38] =A0 =A0 =A0 Apic 0x00, Pin 11: vector=3D1=
12,
> >>> delivery_mode=3D1, dest_mode=3Dlogical, delivery_status=3D0, polarity=
=3D0,
> >>> irr=3D0, trigger=3Dedge, mask=3D0, dest_id:1
> >>> (XEN) [2011-12-06 19:13:38] =A0 =A0 IRQ 12 Vec120:
> >>> (XEN) [2011-12-06 19:13:38] =A0 =A0 =A0 Apic 0x00, Pin 12: vector=3D1=
20,
> >>> delivery_mode=3D1, dest_mode=3Dlogical, delivery_status=3D0, polarity=
=3D0,
> >>> irr=3D0, trigger=3Dedge, mask=3D0, dest_id:1
> >>> (XEN) [2011-12-06 19:13:38] =A0 =A0 IRQ 13 Vec136:
> >>> (XEN) [2011-12-06 19:13:38] =A0 =A0 =A0 Apic 0x00, Pin 13: vector=3D1=
36,
> >>> delivery_mode=3D1, dest_mode=3Dlogical, delivery_status=3D0, polarity=
=3D0,
> >>> irr=3D0, trigger=3Dedge, mask=3D0, dest_id:1
> >>> (XEN) [2011-12-06 19:13:38] =A0 =A0 IRQ 14 Vec144:
> >>> (XEN) [2011-12-06 19:13:38] =A0 =A0 =A0 Apic 0x00, Pin 14: vector=3D1=
44,
> >>> delivery_mode=3D1, dest_mode=3Dlogical, delivery_status=3D0, polarity=
=3D0,
> >>> irr=3D0, trigger=3Dedge, mask=3D0, dest_id:1
> >>> (XEN) [2011-12-06 19:13:38] =A0 =A0 IRQ 15 Vec152:
> >>> (XEN) [2011-12-06 19:13:38] =A0 =A0 =A0 Apic 0x00, Pin 15: vector=3D1=
52,
> >>> delivery_mode=3D1, dest_mode=3Dlogical, delivery_status=3D0, polarity=
=3D0,
> >>> irr=3D0, trigger=3Dedge, mask=3D0, dest_id:1
> >>> (XEN) [2011-12-06 19:13:38] =A0 =A0 IRQ 16 Vec200:
> >>> (XEN) [2011-12-06 19:13:38] =A0 =A0 =A0 Apic 0x00, Pin 16: vector=3D2=
00,
> >>> delivery_mode=3D1, dest_mode=3Dlogical, delivery_status=3D0, polarity=
=3D1,
> >>> irr=3D0, trigger=3Dlevel, mask=3D0, dest_id:1
> >>> (XEN) [2011-12-06 19:13:38] =A0 =A0 IRQ 18 Vec 81:
> >>> (XEN) [2011-12-06 19:13:38] =A0 =A0 =A0 Apic 0x00, Pin 18: vector=3D8=
1,
> >>> delivery_mode=3D1, dest_mode=3Dlogical, delivery_status=3D0, polarity=
=3D1,
> >>> irr=3D0, trigger=3Dlevel, mask=3D0, dest_id:1
> >>> (XEN) [2011-12-06 19:13:38] =A0 =A0 IRQ 19 Vec208:
> >>> (XEN) [2011-12-06 19:13:38] =A0 =A0 =A0 Apic 0x00, Pin 19: vector=3D2=
08,
> >>> delivery_mode=3D1, dest_mode=3Dlogical, delivery_status=3D0, polarity=
=3D1,
> >>> irr=3D0, trigger=3Dlevel, mask=3D0, dest_id:1
> >>> (XEN) [2011-12-06 19:13:38] =A0 =A0 IRQ 21 Vec 97:
> >>> (XEN) [2011-12-06 19:13:38] =A0 =A0 =A0 Apic 0x00, Pin 21: vector=3D9=
7,
> >>> delivery_mode=3D1, dest_mode=3Dlogical, delivery_status=3D0, polarity=
=3D1,
> >>> irr=3D0, trigger=3Dlevel, mask=3D0, dest_id:1
> >>> (XEN) [2011-12-06 19:13:38] =A0 =A0 IRQ 23 Vec 89:
> >>> (XEN) [2011-12-06 19:13:38] =A0 =A0 =A0 Apic 0x00, Pin 23: vector=3D8=
9,
> >>> delivery_mode=3D1, dest_mode=3Dlogical, delivery_status=3D1, polarity=
=3D1,
> >>> irr=3D1, trigger=3Dlevel, mask=3D0, dest_id:1
> >>>
> >>> I noticed some potential interesting things. The system in question is
> >>> using PCI passthrough. On the serial console I remember seeing that
> >>> the PCI device got unmapped from DomU and got mapped again in Dom0.
> >>> The serial console log still had a lot of information about this DomU
> >>> which I guess was going down. I guess it wasn't fully down yet.
> >>
> >> One of the debug informations that gets printed with '*' is the guest
> >> PCI passthrough data. Such as which IRQ, BAR, etc are mapped in. Did a=
ny
> >> of those exist?
> >
> > There is not much PCI related information. Just interrupt stuff, no
> > PCI BARs or other interesting PCI stuff:
> > (XEN) [2011-12-06 19:13:20] 03:00.0 - dom 1201 - MSIs < 37 >
> > (XEN) [2011-12-06 19:13:20] =A0MSI =A0 =A037 vec=3D65 lowest =A0edge =
=A0 assert
> > log lowest dest=3D00000010 mask=3D0/0/-1
> >
> >
> >> My original thought of what is going on is that the interrupts either
> >> stopped completly working (does not look like - it looks like the
> >> interrupts are firring and the event channels that are bound to it have
> >> the bits set saying - hey I am pending). Oddly there are bunch of MSI
> >> ones that are masked which usually means they are disabled.
> >>
> >> Then there is the
> >> =A0affinity:00000000,00000000,00000000,00000001 vec:c8 type=3DIO-APIC-=
level
> >> =A0 status=3D00000010 in-flight=3D0 domain-list=3D0: 16(-S--),1201: 16=
(--M-),
> >> =A0affinity:00000000,00000000,00000000,00000010 vec:65 type=3DPCI-MSI
> >> =A0 status=3D00000010 in-flight=3D0 domain-list=3D1201: 55(--M-),
> >>
> >> The guest has masked both interrupts - so it is off//dying, but somehow
> >> the unmapping has not happend. In other words, what you just analyzed
> >> and found out.
> >>
> >> Sadly, there is no smoking gun..
> >>
> >> So a couple of things that I would do is to ensure that the Xen
> >> hypervisor boots with 'sync_console console_to_ring' and when this
> >> crash happens see if I can get a stack trace from both the Xen
> >> hypervisor (there are some debug parameters to get that - I think it is
> >> 'r'?), and also from the Linux kernel.
> >
> > I set up some new tests, so that will take some days to get a crash.
> > For what it is worth, I do have a '*' log left from this system and it
> > has some stack trace. If you think it is useful, I could send it
> > gzipped, but I don't want to spam this list if it may not be useful.
> >
> > One thing I did notice was the following:
> > (XEN) [2011-12-06 19:13:39] active vcpus:
> > (XEN) [2011-12-06 19:13:39] =A0 =A0 =A0 1: [1201.2] pri=3D-2 flags=3D0 =
cpu=3D6
> > credit=3D-2411 [w=3D256]
> > (XEN) [2011-12-06 19:13:39] =A0 =A0 =A0 2: [1201.1] pri=3D-2 flags=3D0 =
cpu=3D5
> > credit=3D-2460 [w=3D256]
> > (XEN) [2011-12-06 19:13:39] =A0 =A0 =A0 3: [0.2] pri=3D0 flags=3D0 cpu=
=3D2
> > credit=3D142 [w=3D256]
> > (XEN) [2011-12-06 19:13:39] =A0 =A0 =A0 4: [0.1] pri=3D-2 flags=3D0 cpu=
=3D1
> > credit=3D-2612 [w=3D256]
> > (XEN) [2011-12-06 19:13:39] CPU[00] =A0sort=3D12511062,
> > sibling=3D00000000,00000000,00000000,00000003,
> > core=3D00000000,00000000,00000000,000000ff
> > (XEN) [2011-12-06 19:13:39] =A0 =A0 run: [32767.0] pri=3D0 flags=3D0 cp=
u=3D0
> > (XEN) [2011-12-06 19:13:39] =A0 =A0 =A0 1: [0.0] pri=3D-1 flags=3D0 cpu=
=3D0
> > credit=3D333 [w=3D256]
> > (XEN) [2011-12-06 19:13:39] CPU[01] =A0sort=3D12511063,
> > sibling=3D00000000,00000000,00000000,00000003,
> > core=3D00000000,00000000,00000000,000000ff
> > (XEN) [2011-12-06 19:13:39] =A0 =A0 run: [0.1] pri=3D-2 flags=3D0 cpu=
=3D1
> > credit=3D-2914 [w=3D256]
> > (XEN) [2011-12-06 19:13:39] =A0 =A0 =A0 1: [32767.1] pri=3D-64 flags=3D=
0 cpu=3D1
> > (XEN) [2011-12-06 19:13:39] CPU[02] =A0sort=3D12511063,
> > sibling=3D00000000,00000000,00000000,0000000c,
> > core=3D00000000,00000000,00000000,000000ff
> > (XEN) [2011-12-06 19:13:39] =A0 =A0 run: [32767.2] pri=3D-64 flags=3D0 =
cpu=3D2
> > (XEN) [2011-12-06 19:13:39] CPU[03] =A0sort=3D12511063,
> > sibling=3D00000000,00000000,00000000,0000000c,
> > core=3D00000000,00000000,00000000,000000ff
> > (XEN) [2011-12-06 19:13:39] =A0 =A0 run: [32767.3] pri=3D-64 flags=3D0 =
cpu=3D3
> > (XEN) [2011-12-06 19:13:39] CPU[04] =A0sort=3D12511063,
> > sibling=3D00000000,00000000,00000000,00000030,
> > core=3D00000000,00000000,00000000,000000ff
> > (XEN) [2011-12-06 19:13:39] =A0 =A0 run: [32767.4] pri=3D-64 flags=3D0 =
cpu=3D4
> > (XEN) [2011-12-06 19:13:39] CPU[05] =A0sort=3D12511063,
> > sibling=3D00000000,00000000,00000000,00000030,
> > core=3D00000000,00000000,00000000,000000ff
> > (XEN) [2011-12-06 19:13:39] =A0 =A0 run: [1201.1] pri=3D-2 flags=3D0 cp=
u=3D5
> > credit=3D-3617 [w=3D256]
> > (XEN) [2011-12-06 19:13:39] =A0 =A0 =A0 1: [32767.5] pri=3D-64 flags=3D=
0 cpu=3D5
> > (XEN) [2011-12-06 19:13:39] CPU[06] =A0sort=3D12511063,
> > sibling=3D00000000,00000000,00000000,000000c0,
> > core=3D00000000,00000000,00000000,000000ff
> > (XEN) [2011-12-06 19:13:39] =A0 =A0 run: [1201.2] pri=3D-2 flags=3D0 cp=
u=3D6
> > credit=3D-3918 [w=3D256]
> > (XEN) [2011-12-06 19:13:39] =A0 =A0 =A0 1: [32767.6] pri=3D-64 flags=3D=
0 cpu=3D6
> > (XEN) [2011-12-06 19:13:39] CPU[07] =A0sort=3D12511063,
> > sibling=3D00000000,00000000,00000000,000000c0,
> > core=3D00000000,00000000,00000000,000000ff
> > (XEN) [2011-12-06 19:13:39] =A0 =A0 run: [32767.7] pri=3D-64 flags=3D0 =
cpu=3D7
> >
> > The system in question has a 4-core i7 CPU where Dom0 is pinned to
> > core 0-3 and DomU is pinned 4-7. Aren't the negative credit numbers
> > quite big?
> >
> >>
> >> But also see if the problem disappears with the latest 4.1.x hyperviso=
r.
> >> And it might also be worth upgrading the dom0 to a 3.0. Hmm, it would =
be
> >> very interesting to see where the dom0 _is_ stuck at. The hypervisor is
> >> running fine so it all points to dom0 crashing somewhere..
> >>
> >> Can you make sure that dom0 runs with 'debug loglevel=3D8' as well. Th=
at
> >> should give some wealth of information when/if a crash happens.
> >> Oh, and try to pass in Ctrl-Alt-SysRQ-t (on serial concentrators I thi=
nk
> >> you just need to type 'break' on the telnet line)and then t. But I am
> >> not entirely sure about it - might want to double check Google and see
> >> how to enable Alt-SysRQ.
> >
> > I tried to get SysRq working. It worked fine on some of my other
> > machines (sysrq=3D 'shift-control-o'), but not on this broken box.
> > Apparently the kernel is stuck in some place where SysRq doesn't work.
> >
> > I'm going to retest with the relevant logging turned on. I also
> > upgraded to the latest 2.6.32 kernel (.48 I think). I will also
> > upgrade to the latest 4.1.x build from the mercurial repository. It
> > will take a few days before I get crash.
> >
> > Thanks so far!
> > Roderick
> =

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Dec 11 12:54:32 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 11 Dec 2011 12:54:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZiuW-0004jY-DO; Sun, 11 Dec 2011 12:53:44 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pasik@iki.fi>) id 1RZiuV-0004jS-1D
	for xen-devel@lists.xensource.com; Sun, 11 Dec 2011 12:53:43 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-4.tower-21.messagelabs.com!1323607970!1464313!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA0MTMxODk=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11918 invoked from network); 11 Dec 2011 12:52:51 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-4.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Dec 2011 12:52:51 -0000
X-Originating-Ip: [194.89.68.22]
Received: from ydin.reaktio.net (reaktio.net [194.89.68.22])
	by smtp.tele.fi (Postfix) with ESMTP id AEFC72C7C;
	Sun, 11 Dec 2011 14:52:48 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 0EB7120097; Sun, 11 Dec 2011 14:52:48 +0200 (EET)
Date: Sun, 11 Dec 2011 14:52:47 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Roderick Colenbrander <thunderbird2k@gmail.com>
Message-ID: <20111211125247.GQ12984@reaktio.net>
References: <CAEc3jaAa7y8C2NNBn1=L3AhS0uuYFP6ze8o1cZ9yG2VYHx6qMA@mail.gmail.com>
	<4ED5215D.1010403@hfp.de>
	<20111129230212.GA23958@andromeda.dapyr.net>
	<CAEc3jaAO0JhtOt6phQHwtE_A+NF7uGHGZ8uJv3BirEYybfVceg@mail.gmail.com>
	<CAEc3jaACffpr9D1Hq_012vHAGhPLEfvsZjh7YyJ=Q-3FdtHS0Q@mail.gmail.com>
	<CAPbh3rtOQ1HTPReqYcpE3vzk+-na0MTLLHZD15=Fg4yxB+ypaA@mail.gmail.com>
	<CAEc3jaBdQKmVJToNZRf+25GtJXqGc274ieHf_yHKRJ+YOKWdgA@mail.gmail.com>
	<20111208234624.GD32474@konrad-lan>
	<CAEc3jaC9=HiMoxSYZmXKRzoFcMYRaT9jrX3m1ZQO+M8CrH35Fg@mail.gmail.com>
	<CAEc3jaBBYBME0G3Ku_sTvzQz+oKQnpBPffA+bRUKxxRPABAeww@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAEc3jaBBYBME0G3Ku_sTvzQz+oKQnpBPffA+bRUKxxRPABAeww@mail.gmail.com>
User-Agent: Mutt/1.5.18 (2008-05-17)
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>, xen-devel@lists.xensource.com,
	Andreas Kinzler <ml-xen-devel@hfp.de>
Subject: Re: [Xen-devel] Questions about GPLPV stability tests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Dec 09, 2011 at 02:02:31PM -0800, Roderick Colenbrander wrote:
> One interesting observation. This morning I had another of my stress
> machines with the problem. I never had it on this problem before and
> it didn't have any of the new logging / software updates yet.
> =

> The system was in the same state as the other machine which I reported
> about before. I tried SysRq stuff and other things. While I was about
> to reboot the system, a login prompt appeared again on the VGA. I
> don't know whether any of the stuff I did triggered it or not. Anyway
> it means Linux is not really dead. I tried logging, but I don't even
> see characters appearing. The system feels to be very, very, very
> slow.
> =


Hmm.. I wonder if this is the same issue I'm sometimes seeing on my laptop.=
. =

suddenly it starts becoming slower, and after a while it's *very* slow.. =

not dead, but unusably slow..

I haven't had time to (try to) debug it..

-- Pasi


> The other tests are still running.
> =

> Roderick
> =

> On Thu, Dec 8, 2011 at 5:33 PM, Roderick Colenbrander
> <thunderbird2k@gmail.com> wrote:
> > On Thu, Dec 8, 2011 at 11:46 PM, Konrad Rzeszutek Wilk
> > <konrad@darnok.org> wrote:
> >> On Wed, Dec 07, 2011 at 08:44:19PM +0000, Roderick Colenbrander wrote:
> >>> On Wed, Dec 7, 2011 at 8:38 PM, Konrad Rzeszutek Wilk <konrad@darnok.=
org> wrote:
> >>> >> It took about a week, but the systems went down again. Linux is do=
wn,
> >>> >> but the hypervisor is still reachable on the serial console. Is th=
ere
> >>> >> anything interesting to dump from there?
> >>> >>
> >>> > Just the interrupts information. I think that is Ctrl-A, Ctrl-A,
> >>> > Ctrl-A, and then '*' to capture everything (I don't remember the ri=
ght
> >>> > one for just interrupts).
> >>>
> >>> Here's the interrupt information:
> >>> (XEN) [2011-12-06 19:13:37] [i: dump interrupt bindings]
> >>> (XEN) [2011-12-06 19:13:37] Guest interrupt information:
> >>> (XEN) [2011-12-06 19:13:37] =A0 =A0IRQ: =A0 0
> >>> affinity:00000000,00000000,00000000,00000001 vec:f0 type=3DIO-APIC-ed=
ge
> >>> =A0 status=3D00000000 mapped, unbound
> >>> (XEN) [2011-12-06 19:13:37] =A0 =A0IRQ: =A0 1
> >>> affinity:00000000,00000000,00000000,00000001 vec:30 type=3DIO-APIC-ed=
ge
> >>> =A0 status=3D00000014 in-flight=3D0 domain-list=3D0: =A01(-S--),
> >>> (XEN) [2011-12-06 19:13:37] =A0 =A0IRQ: =A0 2
> >>> affinity:ffffffff,ffffffff,ffffffff,ffffffff vec:e2 type=3DXT-PIC
> >>> =A0 status=3D00000000 mapped, unbound
> >>> (XEN) [2011-12-06 19:13:37] =A0 =A0IRQ: =A0 3
> >>> affinity:00000000,00000000,00000000,00000001 vec:38 type=3DIO-APIC-ed=
ge
> >>> =A0 status=3D00000006 mapped, unbound
> >>> (XEN) [2011-12-06 19:13:37] =A0 =A0IRQ: =A0 4
> >>> affinity:00000000,00000000,00000000,00000001 vec:40 type=3DIO-APIC-ed=
ge
> >>> =A0 status=3D00000002 mapped, unbound
> >>> (XEN) [2011-12-06 19:13:37] =A0 =A0IRQ: =A0 5
> >>> affinity:00000000,00000000,00000000,00000001 vec:f1 type=3DIO-APIC-ed=
ge
> >>> =A0 status=3D00000000 mapped, unbound
> >>> (XEN) [2011-12-06 19:13:37] =A0 =A0IRQ: =A0 6
> >>> affinity:00000000,00000000,00000000,00000001 vec:48 type=3DIO-APIC-ed=
ge
> >>> =A0 status=3D00000002 mapped, unbound
> >>> (XEN) [2011-12-06 19:13:37] =A0 =A0IRQ: =A0 7
> >>> affinity:00000000,00000000,00000000,00000001 vec:50 type=3DIO-APIC-ed=
ge
> >>> =A0 status=3D00000002 mapped, unbound
> >>> (XEN) [2011-12-06 19:13:37] =A0 =A0IRQ: =A0 8
> >>> affinity:00000000,00000000,00000000,00000001 vec:58 type=3DIO-APIC-ed=
ge
> >>> =A0 status=3D00000010 in-flight=3D0 domain-list=3D0: =A08(-S--),
> >>> (XEN) [2011-12-06 19:13:37] =A0 =A0IRQ: =A0 9
> >>> affinity:00000000,00000000,00000000,00000001 vec:60 type=3DIO-APIC-le=
vel
> >>> =A0 status=3D00000010 in-flight=3D0 domain-list=3D0: =A09(-S--),
> >>> (XEN) [2011-12-06 19:13:37] =A0 =A0IRQ: =A010
> >>> affinity:00000000,00000000,00000000,00000001 vec:68 type=3DIO-APIC-ed=
ge
> >>> =A0 status=3D00000002 mapped, unbound
> >>> (XEN) [2011-12-06 19:13:37] =A0 =A0IRQ: =A011
> >>> affinity:00000000,00000000,00000000,00000001 vec:70 type=3DIO-APIC-ed=
ge
> >>> =A0 status=3D00000002 mapped, unbound
> >>> (XEN) [2011-12-06 19:13:37] =A0 =A0IRQ: =A012
> >>> affinity:00000000,00000000,00000000,00000001 vec:78 type=3DIO-APIC-ed=
ge
> >>> =A0 status=3D00000010 in-flight=3D0 domain-list=3D0: 12(-S--),
> >>> (XEN) [2011-12-06 19:13:37] =A0 =A0IRQ: =A013
> >>> affinity:00000000,00000000,00000000,00000001 vec:88 type=3DIO-APIC-ed=
ge
> >>> =A0 status=3D00000002 mapped, unbound
> >>> (XEN) [2011-12-06 19:13:37] =A0 =A0IRQ: =A014
> >>> affinity:00000000,00000000,00000000,00000001 vec:90 type=3DIO-APIC-ed=
ge
> >>> =A0 status=3D00000002 mapped, unbound
> >>> (XEN) [2011-12-06 19:13:37] =A0 =A0IRQ: =A015
> >>> affinity:00000000,00000000,00000000,00000001 vec:98 type=3DIO-APIC-ed=
ge
> >>> =A0 status=3D00000002 mapped, unbound
> >>> (XEN) [2011-12-06 19:13:37] =A0 =A0IRQ: =A016
> >>> affinity:00000000,00000000,00000000,00000001 vec:c8 type=3DIO-APIC-le=
vel
> >>> =A0 status=3D00000010 in-flight=3D0 domain-list=3D0: 16(-S--),1201: 1=
6(--M-),
> >>> (XEN) [2011-12-06 19:13:37] =A0 =A0IRQ: =A018
> >>> affinity:00000000,00000000,00000000,00000001 vec:51 type=3DIO-APIC-le=
vel
> >>> =A0 status=3D00000010 in-flight=3D0 domain-list=3D0: 18(-S--),
> >>> (XEN) [2011-12-06 19:13:37] =A0 =A0IRQ: =A019
> >>> affinity:00000000,00000000,00000000,00000001 vec:d0 type=3DIO-APIC-le=
vel
> >>> =A0 status=3D00000010 in-flight=3D0 domain-list=3D0: 19(-S--),
> >>> (XEN) [2011-12-06 19:13:37] =A0 =A0IRQ: =A021
> >>> affinity:00000000,00000000,00000000,00000001 vec:61 type=3DIO-APIC-le=
vel
> >>> =A0 status=3D00000010 in-flight=3D0 domain-list=3D0: 21(-S--),
> >>> (XEN) [2011-12-06 19:13:37] =A0 =A0IRQ: =A023
> >>> affinity:00000000,00000000,00000000,00000001 vec:59 type=3DIO-APIC-le=
vel
> >>> =A0 status=3D00000010 in-flight=3D1 domain-list=3D0: 23(PS-M),
> >>> (XEN) [2011-12-06 19:13:37] =A0 =A0IRQ: =A024
> >>> affinity:00000000,00000000,00000000,00000001 vec:28 type=3DDMA_MSI
> >>> =A0 status=3D00000000 mapped, unbound
> >>> (XEN) [2011-12-06 19:13:38] =A0 =A0IRQ: =A025
> >>> affinity:00000000,00000000,00000000,00000001 vec:a0 type=3DPCI-MSI
> >>> =A0 status=3D00000002 mapped, unbound
> >>> (XEN) [2011-12-06 19:13:38] =A0 =A0IRQ: =A026
> >>> affinity:00000000,00000000,00000000,00000001 vec:a8 type=3DPCI-MSI
> >>> =A0 status=3D00000002 mapped, unbound
> >>> (XEN) [2011-12-06 19:13:38] =A0 =A0IRQ: =A027
> >>> affinity:00000000,00000000,00000000,00000001 vec:b0 type=3DPCI-MSI
> >>> =A0 status=3D00000002 mapped, unbound
> >>> (XEN) [2011-12-06 19:13:38] =A0 =A0IRQ: =A028
> >>> affinity:00000000,00000000,00000000,00000001 vec:b8 type=3DPCI-MSI
> >>> =A0 status=3D00000002 mapped, unbound
> >>> (XEN) [2011-12-06 19:13:38] =A0 =A0IRQ: =A029
> >>> affinity:00000000,00000000,00000000,00000001 vec:c0 type=3DPCI-MSI
> >>> =A0 status=3D00000002 mapped, unbound
> >>> (XEN) [2011-12-06 19:13:38] =A0 =A0IRQ: =A030
> >>> affinity:00000000,00000000,00000000,00000001 vec:d8 type=3DPCI-MSI
> >>> =A0 status=3D00000014 in-flight=3D0 domain-list=3D0:274(PS--),
> >>> (XEN) [2011-12-06 19:13:38] =A0 =A0IRQ: =A031
> >>> affinity:00000000,00000000,00000000,00000001 vec:21 type=3DPCI-MSI
> >>> =A0 status=3D00000010 in-flight=3D0 domain-list=3D0:273(PS--),
> >>> (XEN) [2011-12-06 19:13:38] =A0 =A0IRQ: =A032
> >>> affinity:00000000,00000000,00000000,00000001 vec:29 type=3DPCI-MSI
> >>> =A0 status=3D00000010 in-flight=3D0 domain-list=3D0:272(PS--),
> >>> (XEN) [2011-12-06 19:13:38] =A0 =A0IRQ: =A033
> >>> affinity:00000000,00000000,00000000,00000001 vec:31 type=3DPCI-MSI
> >>> =A0 status=3D00000010 in-flight=3D0 domain-list=3D0:271(PS--),
> >>> (XEN) [2011-12-06 19:13:38] =A0 =A0IRQ: =A034
> >>> affinity:ffffffff,ffffffff,ffffffff,ffffffff vec:39 type=3DPCI-MSI
> >>> =A0 status=3D00000002 mapped, unbound
> >>> (XEN) [2011-12-06 19:13:38] =A0 =A0IRQ: =A035
> >>> affinity:ffffffff,ffffffff,ffffffff,ffffffff vec:41 type=3DPCI-MSI
> >>> =A0 status=3D00000002 mapped, unbound
> >>> (XEN) [2011-12-06 19:13:38] =A0 =A0IRQ: =A036
> >>> affinity:ffffffff,ffffffff,ffffffff,ffffffff vec:49 type=3DPCI-MSI
> >>> =A0 status=3D00000002 mapped, unbound
> >>> (XEN) [2011-12-06 19:13:38] =A0 =A0IRQ: =A037
> >>> affinity:00000000,00000000,00000000,00000010 vec:65 type=3DPCI-MSI
> >>> =A0 status=3D00000010 in-flight=3D0 domain-list=3D1201: 55(--M-),
> >>> (XEN) [2011-12-06 19:13:38] IO-APIC interrupt information:
> >>> (XEN) [2011-12-06 19:13:38] =A0 =A0 IRQ =A00 Vec240:
> >>> (XEN) [2011-12-06 19:13:38] =A0 =A0 =A0 Apic 0x00, Pin =A02: vector=
=3D240,
> >>> delivery_mode=3D1, dest_mode=3Dlogical, delivery_status=3D0, polarity=
=3D0,
> >>> irr=3D0, trigger=3Dedge, mask=3D0, dest_id:1
> >>> (XEN) [2011-12-06 19:13:38] =A0 =A0 IRQ =A01 Vec 48:
> >>> (XEN) [2011-12-06 19:13:38] =A0 =A0 =A0 Apic 0x00, Pin =A01: vector=
=3D48,
> >>> delivery_mode=3D1, dest_mode=3Dlogical, delivery_status=3D0, polarity=
=3D0,
> >>> irr=3D0, trigger=3Dedge, mask=3D0, dest_id:1
> >>> (XEN) [2011-12-06 19:13:38] =A0 =A0 IRQ =A03 Vec 56:
> >>> (XEN) [2011-12-06 19:13:38] =A0 =A0 =A0 Apic 0x00, Pin =A03: vector=
=3D56,
> >>> delivery_mode=3D1, dest_mode=3Dlogical, delivery_status=3D0, polarity=
=3D0,
> >>> irr=3D0, trigger=3Dedge, mask=3D0, dest_id:1
> >>> (XEN) [2011-12-06 19:13:38] =A0 =A0 IRQ =A04 Vec 64:
> >>> (XEN) [2011-12-06 19:13:38] =A0 =A0 =A0 Apic 0x00, Pin =A04: vector=
=3D64,
> >>> delivery_mode=3D1, dest_mode=3Dlogical, delivery_status=3D0, polarity=
=3D0,
> >>> irr=3D0, trigger=3Dedge, mask=3D0, dest_id:1
> >>> (XEN) [2011-12-06 19:13:38] =A0 =A0 IRQ =A05 Vec241:
> >>> (XEN) [2011-12-06 19:13:38] =A0 =A0 =A0 Apic 0x00, Pin =A05: vector=
=3D241,
> >>> delivery_mode=3D1, dest_mode=3Dlogical, delivery_status=3D0, polarity=
=3D0,
> >>> irr=3D0, trigger=3Dedge, mask=3D0, dest_id:1
> >>> (XEN) [2011-12-06 19:13:38] =A0 =A0 IRQ =A06 Vec 72:
> >>> (XEN) [2011-12-06 19:13:38] =A0 =A0 =A0 Apic 0x00, Pin =A06: vector=
=3D72,
> >>> delivery_mode=3D1, dest_mode=3Dlogical, delivery_status=3D0, polarity=
=3D0,
> >>> irr=3D0, trigger=3Dedge, mask=3D0, dest_id:1
> >>> (XEN) [2011-12-06 19:13:38] =A0 =A0 IRQ =A07 Vec 80:
> >>> (XEN) [2011-12-06 19:13:38] =A0 =A0 =A0 Apic 0x00, Pin =A07: vector=
=3D80,
> >>> delivery_mode=3D1, dest_mode=3Dlogical, delivery_status=3D0, polarity=
=3D0,
> >>> irr=3D0, trigger=3Dedge, mask=3D0, dest_id:1
> >>> (XEN) [2011-12-06 19:13:38] =A0 =A0 IRQ =A08 Vec 88:
> >>> (XEN) [2011-12-06 19:13:38] =A0 =A0 =A0 Apic 0x00, Pin =A08: vector=
=3D88,
> >>> delivery_mode=3D1, dest_mode=3Dlogical, delivery_status=3D0, polarity=
=3D0,
> >>> irr=3D0, trigger=3Dedge, mask=3D0, dest_id:1
> >>> (XEN) [2011-12-06 19:13:38] =A0 =A0 IRQ =A09 Vec 96:
> >>> (XEN) [2011-12-06 19:13:38] =A0 =A0 =A0 Apic 0x00, Pin =A09: vector=
=3D96,
> >>> delivery_mode=3D1, dest_mode=3Dlogical, delivery_status=3D0, polarity=
=3D0,
> >>> irr=3D0, trigger=3Dlevel, mask=3D0, dest_id:1
> >>> (XEN) [2011-12-06 19:13:38] =A0 =A0 IRQ 10 Vec104:
> >>> (XEN) [2011-12-06 19:13:38] =A0 =A0 =A0 Apic 0x00, Pin 10: vector=3D1=
04,
> >>> delivery_mode=3D1, dest_mode=3Dlogical, delivery_status=3D0, polarity=
=3D0,
> >>> irr=3D0, trigger=3Dedge, mask=3D0, dest_id:1
> >>> (XEN) [2011-12-06 19:13:38] =A0 =A0 IRQ 11 Vec112:
> >>> (XEN) [2011-12-06 19:13:38] =A0 =A0 =A0 Apic 0x00, Pin 11: vector=3D1=
12,
> >>> delivery_mode=3D1, dest_mode=3Dlogical, delivery_status=3D0, polarity=
=3D0,
> >>> irr=3D0, trigger=3Dedge, mask=3D0, dest_id:1
> >>> (XEN) [2011-12-06 19:13:38] =A0 =A0 IRQ 12 Vec120:
> >>> (XEN) [2011-12-06 19:13:38] =A0 =A0 =A0 Apic 0x00, Pin 12: vector=3D1=
20,
> >>> delivery_mode=3D1, dest_mode=3Dlogical, delivery_status=3D0, polarity=
=3D0,
> >>> irr=3D0, trigger=3Dedge, mask=3D0, dest_id:1
> >>> (XEN) [2011-12-06 19:13:38] =A0 =A0 IRQ 13 Vec136:
> >>> (XEN) [2011-12-06 19:13:38] =A0 =A0 =A0 Apic 0x00, Pin 13: vector=3D1=
36,
> >>> delivery_mode=3D1, dest_mode=3Dlogical, delivery_status=3D0, polarity=
=3D0,
> >>> irr=3D0, trigger=3Dedge, mask=3D0, dest_id:1
> >>> (XEN) [2011-12-06 19:13:38] =A0 =A0 IRQ 14 Vec144:
> >>> (XEN) [2011-12-06 19:13:38] =A0 =A0 =A0 Apic 0x00, Pin 14: vector=3D1=
44,
> >>> delivery_mode=3D1, dest_mode=3Dlogical, delivery_status=3D0, polarity=
=3D0,
> >>> irr=3D0, trigger=3Dedge, mask=3D0, dest_id:1
> >>> (XEN) [2011-12-06 19:13:38] =A0 =A0 IRQ 15 Vec152:
> >>> (XEN) [2011-12-06 19:13:38] =A0 =A0 =A0 Apic 0x00, Pin 15: vector=3D1=
52,
> >>> delivery_mode=3D1, dest_mode=3Dlogical, delivery_status=3D0, polarity=
=3D0,
> >>> irr=3D0, trigger=3Dedge, mask=3D0, dest_id:1
> >>> (XEN) [2011-12-06 19:13:38] =A0 =A0 IRQ 16 Vec200:
> >>> (XEN) [2011-12-06 19:13:38] =A0 =A0 =A0 Apic 0x00, Pin 16: vector=3D2=
00,
> >>> delivery_mode=3D1, dest_mode=3Dlogical, delivery_status=3D0, polarity=
=3D1,
> >>> irr=3D0, trigger=3Dlevel, mask=3D0, dest_id:1
> >>> (XEN) [2011-12-06 19:13:38] =A0 =A0 IRQ 18 Vec 81:
> >>> (XEN) [2011-12-06 19:13:38] =A0 =A0 =A0 Apic 0x00, Pin 18: vector=3D8=
1,
> >>> delivery_mode=3D1, dest_mode=3Dlogical, delivery_status=3D0, polarity=
=3D1,
> >>> irr=3D0, trigger=3Dlevel, mask=3D0, dest_id:1
> >>> (XEN) [2011-12-06 19:13:38] =A0 =A0 IRQ 19 Vec208:
> >>> (XEN) [2011-12-06 19:13:38] =A0 =A0 =A0 Apic 0x00, Pin 19: vector=3D2=
08,
> >>> delivery_mode=3D1, dest_mode=3Dlogical, delivery_status=3D0, polarity=
=3D1,
> >>> irr=3D0, trigger=3Dlevel, mask=3D0, dest_id:1
> >>> (XEN) [2011-12-06 19:13:38] =A0 =A0 IRQ 21 Vec 97:
> >>> (XEN) [2011-12-06 19:13:38] =A0 =A0 =A0 Apic 0x00, Pin 21: vector=3D9=
7,
> >>> delivery_mode=3D1, dest_mode=3Dlogical, delivery_status=3D0, polarity=
=3D1,
> >>> irr=3D0, trigger=3Dlevel, mask=3D0, dest_id:1
> >>> (XEN) [2011-12-06 19:13:38] =A0 =A0 IRQ 23 Vec 89:
> >>> (XEN) [2011-12-06 19:13:38] =A0 =A0 =A0 Apic 0x00, Pin 23: vector=3D8=
9,
> >>> delivery_mode=3D1, dest_mode=3Dlogical, delivery_status=3D1, polarity=
=3D1,
> >>> irr=3D1, trigger=3Dlevel, mask=3D0, dest_id:1
> >>>
> >>> I noticed some potential interesting things. The system in question is
> >>> using PCI passthrough. On the serial console I remember seeing that
> >>> the PCI device got unmapped from DomU and got mapped again in Dom0.
> >>> The serial console log still had a lot of information about this DomU
> >>> which I guess was going down. I guess it wasn't fully down yet.
> >>
> >> One of the debug informations that gets printed with '*' is the guest
> >> PCI passthrough data. Such as which IRQ, BAR, etc are mapped in. Did a=
ny
> >> of those exist?
> >
> > There is not much PCI related information. Just interrupt stuff, no
> > PCI BARs or other interesting PCI stuff:
> > (XEN) [2011-12-06 19:13:20] 03:00.0 - dom 1201 - MSIs < 37 >
> > (XEN) [2011-12-06 19:13:20] =A0MSI =A0 =A037 vec=3D65 lowest =A0edge =
=A0 assert
> > log lowest dest=3D00000010 mask=3D0/0/-1
> >
> >
> >> My original thought of what is going on is that the interrupts either
> >> stopped completly working (does not look like - it looks like the
> >> interrupts are firring and the event channels that are bound to it have
> >> the bits set saying - hey I am pending). Oddly there are bunch of MSI
> >> ones that are masked which usually means they are disabled.
> >>
> >> Then there is the
> >> =A0affinity:00000000,00000000,00000000,00000001 vec:c8 type=3DIO-APIC-=
level
> >> =A0 status=3D00000010 in-flight=3D0 domain-list=3D0: 16(-S--),1201: 16=
(--M-),
> >> =A0affinity:00000000,00000000,00000000,00000010 vec:65 type=3DPCI-MSI
> >> =A0 status=3D00000010 in-flight=3D0 domain-list=3D1201: 55(--M-),
> >>
> >> The guest has masked both interrupts - so it is off//dying, but somehow
> >> the unmapping has not happend. In other words, what you just analyzed
> >> and found out.
> >>
> >> Sadly, there is no smoking gun..
> >>
> >> So a couple of things that I would do is to ensure that the Xen
> >> hypervisor boots with 'sync_console console_to_ring' and when this
> >> crash happens see if I can get a stack trace from both the Xen
> >> hypervisor (there are some debug parameters to get that - I think it is
> >> 'r'?), and also from the Linux kernel.
> >
> > I set up some new tests, so that will take some days to get a crash.
> > For what it is worth, I do have a '*' log left from this system and it
> > has some stack trace. If you think it is useful, I could send it
> > gzipped, but I don't want to spam this list if it may not be useful.
> >
> > One thing I did notice was the following:
> > (XEN) [2011-12-06 19:13:39] active vcpus:
> > (XEN) [2011-12-06 19:13:39] =A0 =A0 =A0 1: [1201.2] pri=3D-2 flags=3D0 =
cpu=3D6
> > credit=3D-2411 [w=3D256]
> > (XEN) [2011-12-06 19:13:39] =A0 =A0 =A0 2: [1201.1] pri=3D-2 flags=3D0 =
cpu=3D5
> > credit=3D-2460 [w=3D256]
> > (XEN) [2011-12-06 19:13:39] =A0 =A0 =A0 3: [0.2] pri=3D0 flags=3D0 cpu=
=3D2
> > credit=3D142 [w=3D256]
> > (XEN) [2011-12-06 19:13:39] =A0 =A0 =A0 4: [0.1] pri=3D-2 flags=3D0 cpu=
=3D1
> > credit=3D-2612 [w=3D256]
> > (XEN) [2011-12-06 19:13:39] CPU[00] =A0sort=3D12511062,
> > sibling=3D00000000,00000000,00000000,00000003,
> > core=3D00000000,00000000,00000000,000000ff
> > (XEN) [2011-12-06 19:13:39] =A0 =A0 run: [32767.0] pri=3D0 flags=3D0 cp=
u=3D0
> > (XEN) [2011-12-06 19:13:39] =A0 =A0 =A0 1: [0.0] pri=3D-1 flags=3D0 cpu=
=3D0
> > credit=3D333 [w=3D256]
> > (XEN) [2011-12-06 19:13:39] CPU[01] =A0sort=3D12511063,
> > sibling=3D00000000,00000000,00000000,00000003,
> > core=3D00000000,00000000,00000000,000000ff
> > (XEN) [2011-12-06 19:13:39] =A0 =A0 run: [0.1] pri=3D-2 flags=3D0 cpu=
=3D1
> > credit=3D-2914 [w=3D256]
> > (XEN) [2011-12-06 19:13:39] =A0 =A0 =A0 1: [32767.1] pri=3D-64 flags=3D=
0 cpu=3D1
> > (XEN) [2011-12-06 19:13:39] CPU[02] =A0sort=3D12511063,
> > sibling=3D00000000,00000000,00000000,0000000c,
> > core=3D00000000,00000000,00000000,000000ff
> > (XEN) [2011-12-06 19:13:39] =A0 =A0 run: [32767.2] pri=3D-64 flags=3D0 =
cpu=3D2
> > (XEN) [2011-12-06 19:13:39] CPU[03] =A0sort=3D12511063,
> > sibling=3D00000000,00000000,00000000,0000000c,
> > core=3D00000000,00000000,00000000,000000ff
> > (XEN) [2011-12-06 19:13:39] =A0 =A0 run: [32767.3] pri=3D-64 flags=3D0 =
cpu=3D3
> > (XEN) [2011-12-06 19:13:39] CPU[04] =A0sort=3D12511063,
> > sibling=3D00000000,00000000,00000000,00000030,
> > core=3D00000000,00000000,00000000,000000ff
> > (XEN) [2011-12-06 19:13:39] =A0 =A0 run: [32767.4] pri=3D-64 flags=3D0 =
cpu=3D4
> > (XEN) [2011-12-06 19:13:39] CPU[05] =A0sort=3D12511063,
> > sibling=3D00000000,00000000,00000000,00000030,
> > core=3D00000000,00000000,00000000,000000ff
> > (XEN) [2011-12-06 19:13:39] =A0 =A0 run: [1201.1] pri=3D-2 flags=3D0 cp=
u=3D5
> > credit=3D-3617 [w=3D256]
> > (XEN) [2011-12-06 19:13:39] =A0 =A0 =A0 1: [32767.5] pri=3D-64 flags=3D=
0 cpu=3D5
> > (XEN) [2011-12-06 19:13:39] CPU[06] =A0sort=3D12511063,
> > sibling=3D00000000,00000000,00000000,000000c0,
> > core=3D00000000,00000000,00000000,000000ff
> > (XEN) [2011-12-06 19:13:39] =A0 =A0 run: [1201.2] pri=3D-2 flags=3D0 cp=
u=3D6
> > credit=3D-3918 [w=3D256]
> > (XEN) [2011-12-06 19:13:39] =A0 =A0 =A0 1: [32767.6] pri=3D-64 flags=3D=
0 cpu=3D6
> > (XEN) [2011-12-06 19:13:39] CPU[07] =A0sort=3D12511063,
> > sibling=3D00000000,00000000,00000000,000000c0,
> > core=3D00000000,00000000,00000000,000000ff
> > (XEN) [2011-12-06 19:13:39] =A0 =A0 run: [32767.7] pri=3D-64 flags=3D0 =
cpu=3D7
> >
> > The system in question has a 4-core i7 CPU where Dom0 is pinned to
> > core 0-3 and DomU is pinned 4-7. Aren't the negative credit numbers
> > quite big?
> >
> >>
> >> But also see if the problem disappears with the latest 4.1.x hyperviso=
r.
> >> And it might also be worth upgrading the dom0 to a 3.0. Hmm, it would =
be
> >> very interesting to see where the dom0 _is_ stuck at. The hypervisor is
> >> running fine so it all points to dom0 crashing somewhere..
> >>
> >> Can you make sure that dom0 runs with 'debug loglevel=3D8' as well. Th=
at
> >> should give some wealth of information when/if a crash happens.
> >> Oh, and try to pass in Ctrl-Alt-SysRQ-t (on serial concentrators I thi=
nk
> >> you just need to type 'break' on the telnet line)and then t. But I am
> >> not entirely sure about it - might want to double check Google and see
> >> how to enable Alt-SysRQ.
> >
> > I tried to get SysRq working. It worked fine on some of my other
> > machines (sysrq=3D 'shift-control-o'), but not on this broken box.
> > Apparently the kernel is stuck in some place where SysRq doesn't work.
> >
> > I'm going to retest with the relevant logging turned on. I also
> > upgraded to the latest 2.6.32 kernel (.48 I think). I will also
> > upgrade to the latest 4.1.x build from the mercurial repository. It
> > will take a few days before I get crash.
> >
> > Thanks so far!
> > Roderick
> =

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Dec 11 15:29:41 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 11 Dec 2011 15:29:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZlKi-00060C-Bv; Sun, 11 Dec 2011 15:28:56 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <hui.lv@intel.com>) id 1RZlKf-000607-Pi
	for xen-devel@lists.xensource.com; Sun, 11 Dec 2011 15:28:54 +0000
X-Env-Sender: hui.lv@intel.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1323617280!5098091!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDI5NjA5NA==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4683 invoked from network); 11 Dec 2011 15:28:00 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-11.tower-174.messagelabs.com with SMTP;
	11 Dec 2011 15:28:00 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga102.fm.intel.com with ESMTP; 11 Dec 2011 07:27:59 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; 
	d="xml'?xlsx'72,48?scan'72,48,72,48,208?rels'72,48,72,48,208?diff'72,48,72,48,208";
	a="94933637"
Received: from pgsmsx601.gar.corp.intel.com ([10.221.43.69])
	by fmsmga001.fm.intel.com with ESMTP; 11 Dec 2011 07:27:57 -0800
Received: from pgsmsx509.gar.corp.intel.com (172.30.13.17) by
	pgsmsx601.gar.corp.intel.com (10.221.43.69) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Sun, 11 Dec 2011 23:27:57 +0800
Received: from shsmsx602.ccr.corp.intel.com (10.239.4.104) by
	PGSMSX509.gar.corp.intel.com (172.30.13.17) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Sun, 11 Dec 2011 23:27:56 +0800
Received: from shsmsx502.ccr.corp.intel.com ([10.239.4.96]) by
	SHSMSX602.ccr.corp.intel.com ([10.239.4.104]) with mapi;
	Sun, 11 Dec 2011 23:27:55 +0800
From: "Lv, Hui" <hui.lv@intel.com>
To: George Dunlap <George.Dunlap@eu.citrix.com>
Date: Sun, 11 Dec 2011 23:27:54 +0800
Thread-Topic: [Xen-devel] [PATCH] scheduler rate controller
Thread-Index: AcywTKEQpqSflkXmRa6gWOoeZKGM1QHqYimQ
Message-ID: <C10D3FB0CD45994C8A51FEC1227CE22F37666D5EA5@shsmsx502.ccr.corp.intel.com>
References: <C10D3FB0CD45994C8A51FEC1227CE22F340768D793@shsmsx502.ccr.corp.intel.com>
	<CAFLBxZZ9nqeb7CVqTZCsEtJRjgGMTHF2Ak929kvauj2KUFSOyg@mail.gmail.com>
	<C10D3FB0CD45994C8A51FEC1227CE22F3428CB5EF9@shsmsx502.ccr.corp.intel.com>
	<1319789425.19320.12.camel@Abyss>
	<C10D3FB0CD45994C8A51FEC1227CE22F3428CB61F2@shsmsx502.ccr.corp.intel.com>
	<1319796584.19320.31.camel@Abyss>	<1319818714.21033.414.camel@elijah>
	<C10D3FB0CD45994C8A51FEC1227CE22F34B3905D03@shsmsx502.ccr.corp.intel.com>
	<CAFLBxZa5v_YgnC1LTa4a5wis4h6eQPijCAfUDLDsR4ucMuBXWg@mail.gmail.com>
	<C10D3FB0CD45994C8A51FEC1227CE22F37499C2733@shsmsx502.ccr.corp.intel.com>
	<CAFLBxZZ-F2hNTNHtiBCuQ0tVqJDe6btPnvofHK4KaDDQz8Rxtw@mail.gmail.com>
In-Reply-To: <CAFLBxZZ-F2hNTNHtiBCuQ0tVqJDe6btPnvofHK4KaDDQz8Rxtw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/mixed;
	boundary="_003_C10D3FB0CD45994C8A51FEC1227CE22F37666D5EA5shsmsx502ccrc_"
MIME-Version: 1.0
Cc: "Tian, Kevin" <kevin.tian@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, "Dong, Eddie" <eddie.dong@intel.com>,
	George Dunlap <george.dunlap@citrix.com>, "Duan,
	Jiangang" <jiangang.duan@intel.com>, Dario Faggioli <raistlin@linux.it>
Subject: Re: [Xen-devel] [PATCH] scheduler rate controller
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--_003_C10D3FB0CD45994C8A51FEC1227CE22F37666D5EA5shsmsx502ccrc_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi George,

Thank you very much for your feedbacks.
I have finished the measurement work based on the delay method. From the co=
mparable results, 1ms-delay can do as well as SRC patch to gain significant=
 performance boost without obvious drawbacks.

1. Basically, the "delay method" can achieve nearly the same benefits as my=
 previous SRC patch, 11% overall performance boost for SPECvirt than origin=
al credit scheduler.
2. I have tried 1ms delay and 10ms delay, there is no big difference betwee=
n these two configurations. (1ms is enough to achieve a good performance)
3. I have compared different load level response time/latency (low, high, p=
eak), "delay method" didn't bring very much Qos increase.
4. 1ms delay can reduce 30% context switch at peak performance, where produ=
ces the benefits.

You can find the raw data from the attached excel file.
The attached credit_1.diff patch works stable at my side.


> Looks fine overall.  One issue with the patch is that it will not only fa=
il to
> preempt for a higher-priority vcpu, it will also fail to preempt for task=
lets.
> Tasklet work must be done immediately.  Perhaps we can add
> "!tasklet_work_scheduled" to the list of conditions for

Yes, added "!tasklet_work_scheduled". I have done the experiments to compar=
e with/without this, there is not big difference.=20
>=20
> Why did you change "MICROSECS" to "MILLISECS" when calculating timeslice?
> In this case, it will set the timeslice to a full second!
> Not what we want...
Sorry , it's my typo, I have changed

> From a software maintenance perspective, I'm not a fan of early returns f=
rom
> functions.  I think it's too easy not to notice that there's a different =
return
> path.  In this case, I think I'd prefer adding a label, and using "goto o=
ut;"
> instead.

Followed this code style.

> If you were using mercurial queues, you could put this after the last one=
, and it
> would be easier to see the proposed "adaptive" part of the code. :-)
>=20
> Hypervisors are very complicated; it's best to keep things as absolutely =
simple
> as possible.  This kind of mechanism is exactly the sort of thing that ma=
kes it
> very hard to predict what will happen.  I think unless you can show that =
it adds
> a significant benefit, it's better just to use the min timeslice.

In fact, I have tested the results with 1ms delay and 10ms delay, there is =
no significant performance improvement. It means, even though we select ada=
ptive method, there is also no significant performance boost with compariso=
n to 1ms.
1ms is good enough insofar.=20

> Regarding this particular code, a couple of items, just for feedback:
> * All of the ratelimiting code and data structures should be in the plugg=
able
> scheduler, not in common code.
Agreed.


> an adaptive solution, you'd need to make a per-cpu variable with the per-=
cpu
> rate scheduling; and then set it to the global variable (which is the use=
r
> configuration).

It seems no need to make it adaptive now :)

> I've taken your two patches, given them the proper formating, and made th=
em
> into a patch series (the first adding the ratelimiting, the second adding=
 the
> adaptive bit); they are attached.  You should be able to easily pull them=
 into a
> mercurial patchqueue using "hg qimport /path/to/patches/*.diff".  In the
> future, I will not look at any patches which do not apply using either "p=
atch -p1"
> or "hg qimport."

Thanks for the coach to submit patch in a right way.
>=20
>  -George

--_003_C10D3FB0CD45994C8A51FEC1227CE22F37666D5EA5shsmsx502ccrc_
Content-Type: application/octet-stream; name="credit_1.diff"
Content-Description: credit_1.diff
Content-Disposition: attachment; filename="credit_1.diff"; size=4021;
	creation-date="Sun, 11 Dec 2011 22:57:10 GMT";
	modification-date="Sun, 11 Dec 2011 15:57:00 GMT"
Content-Transfer-Encoding: base64

ZGlmZiAtciAxYzU4YmI2NjRkOGQgeGVuL2NvbW1vbi9zY2hlZF9jcmVkaXQuYwotLS0gYS94ZW4v
Y29tbW9uL3NjaGVkX2NyZWRpdC5jCVRodSBEZWMgMDggMTc6MTU6MTYgMjAxMSArMDAwMAorKysg
Yi94ZW4vY29tbW9uL3NjaGVkX2NyZWRpdC5jCVN1biBEZWMgMTEgMDI6Mzk6MDcgMjAxMSAtMDUw
MApAQCAtMTA5LDcgKzEwOSw5IEBAIHN0YXRpYyBib29sX3QgX19yZWFkX21vc3RseSBzY2hlZF9j
cmVkaXQKIGJvb2xlYW5fcGFyYW0oInNjaGVkX2NyZWRpdF9kZWZhdWx0X3lpZWxkIiwgc2NoZWRf
Y3JlZGl0X2RlZmF1bHRfeWllbGQpOwogc3RhdGljIGludCBfX3JlYWRfbW9zdGx5IHNjaGVkX2Ny
ZWRpdF90c2xpY2VfbXMgPSBDU0NIRURfREVGQVVMVF9UU0xJQ0VfTVM7CiBpbnRlZ2VyX3BhcmFt
KCJzY2hlZF9jcmVkaXRfdHNsaWNlX21zIiwgc2NoZWRfY3JlZGl0X3RzbGljZV9tcyk7Ci0KKy8q
IFNjaGVkdWxlciBnZW5lcmljIHBhcmFtZXRlcnMKKyovCitleHRlcm4gaW50IHNjaGVkX3JhdGVs
aW1pdF91czsKIC8qCiAgKiBQaHlzaWNhbCBDUFUKICAqLwpAQCAtMTI5NywxMCArMTI5OSwxNSBA
QCBjc2NoZWRfc2NoZWR1bGUoCiAgICAgc3RydWN0IGNzY2hlZF9wcml2YXRlICpwcnYgPSBDU0NI
RURfUFJJVihvcHMpOwogICAgIHN0cnVjdCBjc2NoZWRfdmNwdSAqc25leHQ7CiAgICAgc3RydWN0
IHRhc2tfc2xpY2UgcmV0OworICAgIHNfdGltZV90IHJ1bnRpbWUsIHRzbGljZTsKIAogICAgIENT
Q0hFRF9TVEFUX0NSQU5LKHNjaGVkdWxlKTsKICAgICBDU0NIRURfVkNQVV9DSEVDSyhjdXJyZW50
KTsKIAorICAgIHJ1bnRpbWUgPSBub3cgLSBjdXJyZW50LT5ydW5zdGF0ZS5zdGF0ZV9lbnRyeV90
aW1lOworICAgIGlmICggcnVudGltZSA8IDAgKSAvKiBEb2VzIHRoaXMgZXZlciBoYXBwZW4/ICov
CisgICAgICAgIHJ1bnRpbWUgPSAwOworCiAgICAgaWYgKCAhaXNfaWRsZV92Y3B1KHNjdXJyLT52
Y3B1KSApCiAgICAgewogICAgICAgICAvKiBVcGRhdGUgY3JlZGl0cyBvZiBhIG5vbi1pZGxlIFZD
UFUuICovCkBAIC0xMzEzLDYgKzEzMjAsNDEgQEAgY3NjaGVkX3NjaGVkdWxlKAogICAgICAgICBz
Y3Vyci0+cHJpID0gQ1NDSEVEX1BSSV9JRExFOwogICAgIH0KIAorICAgIC8qIENob2ljZXMsIGNo
b2ljZXM6CisgICAgICogLSBJZiB3ZSBoYXZlIGEgdGFza2xldCwgd2UgbmVlZCB0byBydW4gdGhl
IGlkbGUgdmNwdSBubyBtYXR0ZXIgd2hhdC4KKyAgICAgKiAtIElmIHNjaGVkIHJhdGUgbGltaXRp
bmcgaXMgaW4gZWZmZWN0LCBhbmQgdGhlIGN1cnJlbnQgdmNwdSBoYXMKKyAgICAgKiAgIHJ1biBm
b3IgbGVzcyB0aGFuIHRoYXQgYW1vdW50IG9mIHRpbWUsIGNvbnRpbnVlIHRoZSBjdXJyZW50IG9u
ZSwKKyAgICAgKiAgIGJ1dCB3aXRoIGEgc2hvcnRlciB0aW1lc2xpY2UgYW5kIHJldHVybiBpdCBp
bW1lZGlhdGVseQorICAgICAqIC0gT3RoZXJ3aXNlLCBjaG9zZSB0aGUgb25lIHdpdGggdGhlIGhp
Z2hlc3QgcHJpb3JpdHkgKHdoaWNoIG1heQorICAgICAqICAgYmUgdGhlIG9uZSBjdXJyZW50bHkg
cnVubmluZykKKyAgICAgKiAtIElmIHRoZSBjdXJyZW50bHkgcnVubmluZyBvbmUgaXMgVFNfT1ZF
Uiwgc2VlIGlmIHRoZXJlCisgICAgICogICBpcyBhIGhpZ2hlciBwcmlvcml0eSBvbmUgd2FpdGlu
ZyBvbiB0aGUgcnVucXVldWUgb2YgYW5vdGhlcgorICAgICAqICAgY3B1IGFuZCBzdGVhbCBpdC4K
KyAgICAgKi8KKworICAgIC8qIElmIHdlIGhhdmUgc2NoZWR1bGUgcmF0ZSBsaW1pdGluZyBlbmFi
bGVkLCBjaGVjayB0byBzZWUKKyAgICAgKiBob3cgbG9uZyB3ZSd2ZSBydW4gZm9yLiAqLyAgCisg
ICAgaWYgKCBzY2hlZF9yYXRlbGltaXRfdXMKKwkgJiYgIXRhc2tsZXRfd29ya19zY2hlZHVsZWQK
KyAgICAgICAgICYmIHZjcHVfcnVubmFibGUoY3VycmVudCkKKyAgICAgICAgICYmICFpc19pZGxl
X3ZjcHUoY3VycmVudCkKKyAgICAgICAgICYmIHJ1bnRpbWUgPCBNSUNST1NFQ1Moc2NoZWRfcmF0
ZWxpbWl0X3VzKSApCisgICAgeworICAgICAgICBzbmV4dCA9IHNjdXJyOworCXNuZXh0LT5zdGFy
dF90aW1lICs9IG5vdzsKKyAgICAgICAgcGVyZmNfaW5jcihkZWxheV9tcyk7CisgICAgICAgIHRz
bGljZSA9IE1JQ1JPU0VDUyhzY2hlZF9yYXRlbGltaXRfdXMpOworCXJldC5taWdyYXRlZCA9IDA7
CisJZ290byBvdXQ7CisgICAgfQorICAgIGVsc2UKKyAgICB7CisgICAgICAgIC8qCisgICAgICAg
ICAqIFNlbGVjdCBuZXh0IHJ1bm5hYmxlIGxvY2FsIFZDUFUgKGllIHRvcCBvZiBsb2NhbCBydW5x
KQorICAgICAgICAgKi8KKyAgICAgICAgdHNsaWNlID0gTUlMTElTRUNTKHBydi0+dHNsaWNlX21z
KTsKKyAgICB9CisgICAgCiAgICAgLyoKICAgICAgKiBTZWxlY3QgbmV4dCBydW5uYWJsZSBsb2Nh
bCBWQ1BVIChpZSB0b3Agb2YgbG9jYWwgcnVucSkKICAgICAgKi8KQEAgLTEzNjcsMTEgKzE0MDks
MTIgQEAgY3NjaGVkX3NjaGVkdWxlKAogICAgIGlmICggIWlzX2lkbGVfdmNwdShzbmV4dC0+dmNw
dSkgKQogICAgICAgICBzbmV4dC0+c3RhcnRfdGltZSArPSBub3c7CiAKK291dDoKICAgICAvKgog
ICAgICAqIFJldHVybiB0YXNrIHRvIHJ1biBuZXh0Li4uCiAgICAgICovCiAgICAgcmV0LnRpbWUg
PSAoaXNfaWRsZV92Y3B1KHNuZXh0LT52Y3B1KSA/Ci0gICAgICAgICAgICAgICAgLTEgOiBNSUxM
SVNFQ1MocHJ2LT50c2xpY2VfbXMpKTsKKyAgICAgICAgICAgICAgICAtMSA6IHRzbGljZSk7CiAg
ICAgcmV0LnRhc2sgPSBzbmV4dC0+dmNwdTsKIAogICAgIENTQ0hFRF9WQ1BVX0NIRUNLKHJldC50
YXNrKTsKZGlmZiAtciAxYzU4YmI2NjRkOGQgeGVuL2NvbW1vbi9zY2hlZHVsZS5jCi0tLSBhL3hl
bi9jb21tb24vc2NoZWR1bGUuYwlUaHUgRGVjIDA4IDE3OjE1OjE2IDIwMTEgKzAwMDAKKysrIGIv
eGVuL2NvbW1vbi9zY2hlZHVsZS5jCVN1biBEZWMgMTEgMDI6Mzk6MDcgMjAxMSAtMDUwMApAQCAt
NDcsNiArNDcsMTAgQEAgc3RyaW5nX3BhcmFtKCJzY2hlZCIsIG9wdF9zY2hlZCk7CiBib29sX3Qg
c2NoZWRfc210X3Bvd2VyX3NhdmluZ3MgPSAwOwogYm9vbGVhbl9wYXJhbSgic2NoZWRfc210X3Bv
d2VyX3NhdmluZ3MiLCBzY2hlZF9zbXRfcG93ZXJfc2F2aW5ncyk7CiAKKy8qIERlZmF1bHQgc2No
ZWR1bGluZyByYXRlIGxpbWl0OiAxbXMgKi8KK2ludCBzY2hlZF9yYXRlbGltaXRfdXMgPSAxMDAw
OworaW50ZWdlcl9wYXJhbSgic2NoZWRfcmF0ZWxpbWl0X3VzIiwgc2NoZWRfcmF0ZWxpbWl0X3Vz
KTsKKwogLyogVmFyaW91cyB0aW1lciBoYW5kbGVycy4gKi8KIHN0YXRpYyB2b2lkIHNfdGltZXJf
Zm4odm9pZCAqdW51c2VkKTsKIHN0YXRpYyB2b2lkIHZjcHVfcGVyaW9kaWNfdGltZXJfZm4odm9p
ZCAqZGF0YSk7CmRpZmYgLXIgMWM1OGJiNjY0ZDhkIHhlbi9pbmNsdWRlL3hlbi9wZXJmY19kZWZu
LmgKLS0tIGEveGVuL2luY2x1ZGUveGVuL3BlcmZjX2RlZm4uaAlUaHUgRGVjIDA4IDE3OjE1OjE2
IDIwMTEgKzAwMDAKKysrIGIveGVuL2luY2x1ZGUveGVuL3BlcmZjX2RlZm4uaAlTdW4gRGVjIDEx
IDAyOjM5OjA3IDIwMTEgLTA1MDAKQEAgLTE1LDcgKzE1LDcgQEAgUEVSRkNPVU5URVIoaXBpcywg
ICAgICAgICAgICAgICAgICAgIiNJUAogUEVSRkNPVU5URVIoc2NoZWRfaXJxLCAgICAgICAgICAg
ICAgInNjaGVkOiB0aW1lciIpCiBQRVJGQ09VTlRFUihzY2hlZF9ydW4sICAgICAgICAgICAgICAi
c2NoZWQ6IHJ1bnMgdGhyb3VnaCBzY2hlZHVsZXIiKQogUEVSRkNPVU5URVIoc2NoZWRfY3R4LCAg
ICAgICAgICAgICAgInNjaGVkOiBjb250ZXh0IHN3aXRjaGVzIikKLQorUEVSRkNPVU5URVIoZGVs
YXlfbXMsCQkgICAgImNzY2hlZDogZGVsYXkiKQogUEVSRkNPVU5URVIodmNwdV9jaGVjaywgICAg
ICAgICAgICAgImNzY2hlZDogdmNwdV9jaGVjayIpCiBQRVJGQ09VTlRFUihzY2hlZHVsZSwgICAg
ICAgICAgICAgICAiY3NjaGVkOiBzY2hlZHVsZSIpCiBQRVJGQ09VTlRFUihhY2N0X3J1biwgICAg
ICAgICAgICAgICAiY3NjaGVkOiBhY2N0X3J1biIpCg==

--_003_C10D3FB0CD45994C8A51FEC1227CE22F37666D5EA5shsmsx502ccrc_
Content-Type: application/vnd.openxmlformats-officedocument.spreadsheetml.sheet;
	name="scheduler comparison.xlsx"
Content-Description: scheduler comparison.xlsx
Content-Disposition: attachment; filename="scheduler comparison.xlsx";
	size=12105; creation-date="Sun, 11 Dec 2011 23:19:48 GMT";
	modification-date="Sun, 11 Dec 2011 23:19:48 GMT"
Content-Transfer-Encoding: base64

UEsDBBQABgAIAAAAIQB8bJgWbAEAAKAFAAATAAgCW0NvbnRlbnRfVHlwZXNdLnhtbCCiBAIooAAC
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADM
lF1LwzAUhu8F/0PJrTTZJojIul34cakD5w+IzekaliYhJ5vbv/c0+0CkbgwHetPQ5pz3fZI073C8
aky2hIDa2YL1eY9lYEuntJ0V7G36lN+yDKO0ShpnoWBrQDYeXV4Mp2sPmFG3xYLVMfo7IbCsoZHI
nQdLM5ULjYz0GmbCy3IuZyAGvd6NKJ2NYGMeWw02Gj5AJRcmZo8r+rwhCWCQZfebwtarYNJ7o0sZ
iVQsrfrmkm8dOHWmGqy1xyvCYKLToZ352WDb90JbE7SCbCJDfJYNYYiVER8uzN+dm/PDIh2Urqp0
CcqVi4Z2gKMPIBXWALExPI28kdruuA/4p2IUaeifGaRdXxI+kWPwTziu/4gj0v8PIj1/fyRJ5sgB
YFwbwDOvdiN6zLmWAdRrDJQUZwf4qn2Ig+7RJDiPlCgBTt+FXWS03bknIQhRwz40ui7f3pHS6HTD
b7cf2rxToDq8RcrX0ScAAAD//wMAUEsDBBQABgAIAAAAIQC1VTAj9QAAAEwCAAALAAgCX3JlbHMv
LnJlbHMgogQCKKAAAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAjJLPTsMwDMbvSLxD5PvqbkgIoaW7TEi7IVQewCTuH7WNoyRA9/aEA4JKY9vR
9ufPP1ve7uZpVB8cYi9Ow7ooQbEzYnvXanitn1YPoGIiZ2kUxxqOHGFX3d5sX3iklJti1/uosouL
GrqU/CNiNB1PFAvx7HKlkTBRymFo0ZMZqGXclOU9hr8eUC081cFqCAd7B6o++jz5src0TW94L+Z9
YpdOjECeEzvLduVDZgupz9uomkLLSYMV85zTEcn7ImMDnibaXE/0/7Y4cSJLidBI4PM834pzQOvr
gS6faKn4vc484qeE4U1k+GHBxQ9UXwAAAP//AwBQSwMEFAAGAAgAAAAhAN4J/SgCAQAA1AMAABoA
CAF4bC9fcmVscy93b3JrYm9vay54bWwucmVscyCiBAEooAABAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAALyTz2rDMAzG74O9g9F9cZJuZZQ6vYxBr1v3ACZR4tDENpb2J28/k0O6QMkuoReDJPx9
P9Cn/eGn78QXBmqdVZAlKQi0pata2yj4OL0+PIMg1rbSnbOoYECCQ3F/t3/DTnP8RKb1JKKKJQWG
2e+kpNJgrylxHm2c1C70mmMZGul1edYNyjxNtzL81YBipimOlYJwrDYgToOPzv9ru7puS3xx5WeP
lq9YyG8XzmQQOYrq0CArmFokx8kmicQgr8PkN4bJl2CyG8NkSzDbNWHI6IDVO4eYQrqsatZegnla
FYaHLoZ+CgyN9ZL945r2HE8JL+5jKcd32oec3WLxCwAA//8DAFBLAwQUAAYACAAAACEAMDLFhWIB
AABxAgAADwAAAHhsL3dvcmtib29rLnhtbIxSy27CMBC8V+o/WL6XJA6kFJEgVW1VLlWlUji78YZY
OHZkOw38fTdGPCQuPe2udzKeGWe+2DeK/IJ10uicJqOYEtClEVJvc/q9enuYUuI814IroyGnB3B0
UdzfzXtjdz/G7AgSaJfT2vt2FkWurKHhbmRa0LipjG24x9FuI9da4MLVAL5REYvjLGq41PTIMLP/
4TBVJUt4MWXXgPZHEguKe5Tvatk6WswrqWB9dER4237wBnXvFSWKO/8qpAeR0wmOpofLwZgS27XP
nVS4fUpjRqPibPLTEgEV75Rfob0TO+bFxoxlA3KIYi2hd5ePhpHsN1IL0+c0zTDaw2lKUhTQh9VG
Cl8j1SO7nL2D3NY+p1M2jQf26Io+BIjXhEp0cPc1hJrgSw11iQawtzOJjV2KZGC4QbMrNPZndPB9
g06v0Nif0WlQF+AoqeSqxKiGEkSMJxkLt0env6X4AwAA//8DAFBLAwQUAAYACAAAACEA+2KlbZQG
AACnGwAAEwAAAHhsL3RoZW1lL3RoZW1lMS54bWzsWU9v2zYUvw/YdyB0b20nthsHdYrYsZutTRvE
boceaZmWWFOiQNJJfRva44ABw7phlwG77TBsK9ACu3SfJluHrQP6FfZISrIYy0vSBhvW1YdEIn98
/9/jI3X12oOIoUMiJOVx26tdrnqIxD4f0zhoe3eG/UsbHpIKx2PMeEza3pxI79rW++9dxZsqJBFB
sD6Wm7jthUolm5WK9GEYy8s8ITHMTbiIsIJXEVTGAh8B3YhV1qrVZiXCNPZQjCMge3syoT5BQ03S
28qI9xi8xkrqAZ+JgSZNnBUGO57WNELOZZcJdIhZ2wM+Y340JA+UhxiWCibaXtX8vMrW1QreTBcx
tWJtYV3f/NJ16YLxdM3wFMEoZ1rr11tXdnL6BsDUMq7X63V7tZyeAWDfB02tLEWa9f5GrZPRLIDs
4zLtbrVRrbv4Av31JZlbnU6n0UplsUQNyD7Wl/Ab1WZ9e83BG5DFN5bw9c52t9t08AZk8c0lfP9K
q1l38QYUMhpPl9Daof1+Sj2HTDjbLYVvAHyjmsIXKIiGPLo0iwmP1apYi/B9LvoA0ECGFY2Rmidk
gn2I4i6ORoJizQBvElyYsUO+XBrSvJD0BU1U2/swwZARC3qvnn//6vlT9Or5k+OHz44f/nT86NHx
wx8tLWfhLo6D4sKX337259cfoz+efvPy8RfleFnE//rDJ7/8/Hk5EDJoIdGLL5/89uzJi68+/f27
xyXwbYFHRfiQRkSiW+QIHfAIdDOGcSUnI3G+FcMQU2cFDoF2CemeCh3grTlmZbgOcY13V0DxKANe
n913ZB2EYqZoCecbYeQA9zhnHS5KDXBD8ypYeDiLg3LmYlbEHWB8WMa7i2PHtb1ZAlUzC0rH9t2Q
OGLuMxwrHJCYKKTn+JSQEu3uUerYdY/6gks+UegeRR1MS00ypCMnkBaLdmkEfpmX6Qyudmyzdxd1
OCvTeoccukhICMxKhB8S5pjxOp4pHJWRHOKIFQ1+E6uwTMjBXPhFXE8q8HRAGEe9MZGybM1tAfoW
nH4DQ70qdfsem0cuUig6LaN5E3NeRO7waTfEUVKGHdA4LGI/kFMIUYz2uSqD73E3Q/Q7+AHHK919
lxLH3acXgjs0cERaBIiemYkSX14n3InfwZxNMDFVBkq6U6kjGv9d2WYU6rbl8K5st71t2MTKkmf3
RLFehfsPlugdPIv3CWTF8hb1rkK/q9DeW1+hV+XyxdflRSmGKq0bEttrm847Wtl4TyhjAzVn5KY0
vbeEDWjch0G9zhw6SX4QS0J41JkMDBxcILBZgwRXH1EVDkKcQN9e8zSRQKakA4kSLuG8aIZLaWs8
9P7KnjYb+hxiK4fEao+P7fC6Hs6OGzkZI1VgzrQZo3VN4KzM1q+kREG312FW00KdmVvNiGaKosMt
V1mb2JzLweS5ajCYWxM6GwT9EFi5Ccd+zRrOO5iRsba79VHmFuOFi3SRDPGYpD7Sei/7qGaclMXK
kiJaDxsM+ux4itUK3Fqa7BtwO4uTiuzqK9hl3nsTL2URvPASUDuZjiwuJieL0VHbazXWGh7ycdL2
JnBUhscoAa9L3UxiFsB9k6+EDftTk9lk+cKbrUwxNwlqcPth7b6ksFMHEiHVDpahDQ0zlYYAizUn
K/9aA8x6UQqUVKOzSbG+AcHwr0kBdnRdSyYT4quiswsj2nb2NS2lfKaIGITjIzRiM3GAwf06VEGf
MZVw42Eqgn6B6zltbTPlFuc06YqXYgZnxzFLQpyWW52iWSZbuClIuQzmrSAe6FYqu1Hu/KqYlL8g
VYph/D9TRe8ncAWxPtYe8OF2WGCkM6XtcaFCDlUoCanfF9A4mNoB0QJXvDANQQV31Oa/IIf6v805
S8OkNZwk1QENkKCwH6lQELIPZclE3ynEauneZUmylJCJqIK4MrFij8ghYUNdA5t6b/dQCKFuqkla
BgzuZPy572kGjQLd5BTzzalk+d5rc+Cf7nxsMoNSbh02DU1m/1zEvD1Y7Kp2vVme7b1FRfTEos2q
Z1kBzApbQStN+9cU4Zxbra1YSxqvNTLhwIvLGsNg3hAlcJGE9B/Y/6jwmf3goTfUIT+A2org+4Um
BmEDUX3JNh5IF0g7OILGyQ7aYNKkrGnT1klbLdusL7jTzfmeMLaW7Cz+Pqex8+bMZefk4kUaO7Ww
Y2s7ttLU4NmTKQpDk+wgYxxjvpQVP2bx0X1w9A58NpgxJU0wwacqgaGHHpg8gOS3HM3Srb8AAAD/
/wMAUEsDBBQABgAIAAAAIQDCwSunegEAAKICAAAYAAAAeGwvd29ya3NoZWV0cy9zaGVldDIueG1s
jJJPSwMxEMXvgt8h5O5mq9Y/pVsRS7EHQUS9p9nZ3dBNJiRT2357J1srQi/eMiT5vXlvZvqwc734
gpgs+kqOilIK8AZr69tKfrwvLu6kSKR9rXv0UMk9JPkwOz+bbjGuUwdAggk+VbIjChOlkunA6VRg
AM83DUanicvYqhQi6Hr45Hp1WZY3ymnr5YEwif9hYNNYA3M0GweeDpAIvSbuP3U2pCPNmf/gnI7r
Tbgw6AIjVra3tB+gUjgzWbYeo1717Hs3utbmyB6KE7yzJmLChgrGqUOjp57v1b1i0mxaW3aQYxcR
mko+jqSaTYdwPi1s05+zyFmvENf5YllXssxP1cnbxZD1axQ1NHrT0xtun8G2HfFgr4oxd59NTOr9
HJLh9BhUjMa/snNNmrmh40GTNcxp0FPWu5GC9oFT8PiE/mdb8r+gW3jRsbU+iR6agXgrRTyIlgWf
CUPWuWX5FRKhO1Yd7wLwzMviSrIS0rHI3n63a/YNAAD//wMAUEsDBBQABgAIAAAAIQDCwSunegEA
AKICAAAYAAAAeGwvd29ya3NoZWV0cy9zaGVldDMueG1sjJJPSwMxEMXvgt8h5O5mq9Y/pVsRS7EH
QUS9p9nZ3dBNJiRT2357J1srQi/eMiT5vXlvZvqwc734gpgs+kqOilIK8AZr69tKfrwvLu6kSKR9
rXv0UMk9JPkwOz+bbjGuUwdAggk+VbIjChOlkunA6VRgAM83DUanicvYqhQi6Hr45Hp1WZY3ymnr
5YEwif9hYNNYA3M0GweeDpAIvSbuP3U2pCPNmf/gnI7rTbgw6AIjVra3tB+gUjgzWbYeo1717Hs3
utbmyB6KE7yzJmLChgrGqUOjp57v1b1i0mxaW3aQYxcRmko+jqSaTYdwPi1s05+zyFmvENf5YllX
ssxP1cnbxZD1axQ1NHrT0xtun8G2HfFgr4oxd59NTOr9HJLh9BhUjMa/snNNmrmh40GTNcxp0FPW
u5GC9oFT8PiE/mdb8r+gW3jRsbU+iR6agXgrRTyIlgWfCUPWuWX5FRKhO1Yd7wLwzMviSrIS0rHI
3n63a/YNAAD//wMAUEsDBBQABgAIAAAAIQB0L7BAygkAAAUlAAAYAAAAeGwvd29ya3NoZWV0cy9z
aGVldDEueG1spFpbc+I8En3fqv0PFO9jLFm+UUm+qvi287BVW3t9JsRJqAHMgpPM/Ps9utlWixAm
mwcg6qOWdLpbOgjf/PFzt529tcfTptvfzlkQzmftft09bvbPt/N//bP+ls1np361f1xtu317O//V
nuZ/3P35Tzfv3fHH6aVt+xk87E+385e+PywXi9P6pd2tTkF3aPewPHXH3arHv8fnxelwbFePqtNu
u+BhmCx2q81+rj0sj9f46J6eNuu27Navu3bfayfHdrvqMf/Ty+Zwst5262vc7VbHH6+Hb+tud4CL
h8120/9STuez3Xr5/XnfHVcPW6z7JxOrtfWt/vHc7zbrY3fqnvoA7hZ6ov6a80W+gKe7m8cNViBp
nx3bp9v5PVs2EZsv7m4UQf/etO+nyedZv3r4R7tt1337iDjNZ5L/h677IYHf0RTC5UkBpMvVut+8
tUW73d7Ov8sQ/lcNgo8YYDGMMP1sR6tVxP52nD22T6vXbf/37v0v7eb5pcewURCDA0nF8vFX2Z7W
iAGGDlgs/a67LZzgdbbbIJk4OFz9VO/vm8f+BZ8wk/Xrqe92/9ENar1Dh8h0wLvpgAETjiEvdBKm
E95tJx5k6eVOsKqp4d12ij7tlJhOeLedRPDJ7FLTB++2Dw/OT26h6VOxKVf96u7m2L3PUBQI9umw
kiXGl/CjAqEH7l826x/3nYzM2bBwGRXjBdGYejkfRERPjngvwbfzfD6D6xMS6+0uvFm8IVvWBlFo
BMO4A4S5kNJAEM0Bwl1IdQYSuZD6DES4kMZAEMxhoHiALLD+gQTMZUrCb1FpuZE+QHioMl6yVZgW
xbbirzQtYsBUXkvttTSmJZG9nGkjt6fTvhw7Cb6dC5TawEYysKGmVxhIriKbpyIY6dLz14BY7ilv
d3maBjRwBsAMgPSvXTMj5saYueqNMyeJQ55GnItQRCkbZ+uQgPBeT4IE384jlOpAQkpIMBChJhEG
uWsutZnrFcJMsrv6xF5TO01aYx+Gj1MhkizMYhYmURaNlDkkYEHXkyDBhITMXWWhIcJEIsywOU3+
CLo06EjHLUyxZ4qExZF5dX1XFM0CwbM4ZfqV1rmDzuEaycDjOGI5EyQ2jcGmJn8Y41HCshSCIkmz
bIyUQx22zuupk2BCHZlEYSCajCQT47C6hrSd6SJLRE5LyLUj8i59tWNPQ0byt9F2PiRQKnKWhXEC
uqKYxR9UkdQCk8Pk8lYiwYQFRg8Cg9E0iIiTPC+13dAgYmqvXHsmCE21Y0eUx3Upmhttj/X4YZDk
WY4NK0oyHodZNmHdSQYcbdfTIMGUBhLtwmD0NHiUk/Qutd3QwLKY0FhpO4f8HjYsRqlwfBAHjXGA
beWcA2fxOLuc1X/pGFROwArScByQrLqwoNhssiyPUaXjH2GxNHieWHziwEOCryxe7wTQoaRIagsY
HGaJGIcPqcPG4jOztYQC+cTTMMoSniThuAe4hP4/Es3qCqmlkGYsHURD4TeVflPlN9V+U2Ob9DeA
qShiUj9dvScotKsNGan5wmDkkGNuuNtbaTEQPQOGJHx1DkNSrD6HIfNpLGZaHB8csEyKsAkZX6sN
o+QmGlH5RXQnItE2TVSi31T7TY1t8oUik8pqMvvL27tCfyIVLUYfY1lGtp3S2GOtkzx7RezpWEFq
+64/sTfWPmjFkLEoTeJE8DSNs/HQdAtSqqvredBa7KJaxDdcdQjY45YupDSAQTCOM1MLrT6x156d
FENjAXYGeRIJJoaXeEx6lwoplq6nQksrhwqykoIZ+aU3dYZ4BDmkewzdynP8RwvdwPUWzFhIUqiy
/gwgzDN8Q3ad1BSTsiCPGcd5ol48rsyYViGGUc7iOBacMZHhb/DuUiUl1fVUaQHmUEWyu8BmrrJG
y4IUiTuMrEWiARhdkLKYeKgIQCTEQ00AMSMeGgMYhWIGhlnMIpHnLAIpw5RcMqSwup4MLcMcMjyp
yAxIs5FEdC2lAVjNHEYklyoKEN55r4ewHpCRw+q0XDQeRjZiHPBMRLFIBMpp8jXPZUPKq+vZ0GLM
ZYOkdIE5TnMjJWVRGrtZSs7JSipjvywZXSdkiMa6mJ6LE9XpMCDHmTLwpYNROVGiUV4XqssT26QV
FyQcvvS5MSsNhOszCBCaFh5AsNz5cx3Wdkx9vyEdJkRZNtalnRb4ZwwCEPtXLtIs+qBqsP07LF0+
gBXalXx+U+k3VX5T7Tc1tsmXfJxIvq8F09y7TQSr8ussqPSbKr+p9psa23Rm9kSjfUKyEWMTnTm5
YjJJqDF4HbQoSYiSa8i0VGhFnoGQTK3PQMZM0juUgUy/V40F4ZYkUXtfi6K+jBt1aYG9UW5Moywt
TYvSm2qSlddSey2NaTkTP6mlrt5M5Q27nA529iE45BAsLMbeaOIWyy350iCMToXEoJeSFUGkuEpw
fdQEMaoIEzg90VhLVVwZ5tCpUZgwXGyKLE/HjHKjKLXK9WxoZeMcLWStBb4+q5NFsyECfHGd/kXV
N5K5pemBkpMXviJIE2f7zL0eld9jOkToj1HTHrGPaSxGa1zcDPMsyVPcGaYiynn+UR38lm7jZ3Qb
CWVhMEJLXC4laZhkSZLHPM1ymhilhWsFy8MYyQMhljNcxnHcyLl5VHlwHkQ4VriIsFhBU7cmcJZE
gZRtYRZlWcyJ88aix68JecblHS1mxTP+kfaVP839RhYaJYdEG2qSVEuhPOKs12oP+eSyUBq70Tcs
pLcIlQcg8qWmgNDbSvU0sRGpn7BQkXGIsPAwwm0xj0fq3IL8La0HVaKKbUqFp3wtyHDhaT1jN1zk
KcnHitjFWAhq66mJnSZoY+yGCNRVyMABEhQ/OuDSfIiMw0NEFN/lY1ah6S0pmWdhQEILL06WWRoz
TkAZr4nG0oeONV+8JLUg7YOkTGOt02P8I8WLX+OdkvjS8aqcfHZNakBCX6KkAVGvsbf9ltat7RG6
+7XwelS2h97ic/za7XbxetRujyyI3EHObN+mB+pS1xt2TOx/KLg0RU5H0RhvnWj6QQT9Y/euPT6r
BxZOs3X3Kh8rwFe1u5uh2TwlwZf3kbwgJe24TlyWuBfzLbhEXFZnLbg6XMrrNb8PLgyX8pbNtxR8
iZ97/fYSw59rrzD4ufYaQ59rbzDwufZ7Hi3vUb7+yAUsUrL5FkjWpZRuvqWCRUo43wKBupRSzrc0
sEhJ51vuwdb9ebZgKbRlMQQMj4gcXvAsUb9Z4yGTp27fy8dX5Pb564AHbfZd0e3NA0lysMPquf3r
6vi82Z9m2/YJeREGOMGP+okU9bnvDqoVRf3Q9Xi6xP73gseNWvxCHwYQ709d19t/4Hfxbh9guvsf
AAAA//8DAFBLAwQUAAYACAAAACEAZp0jhCYBAABwAgAAFAAAAHhsL3NoYXJlZFN0cmluZ3MueG1s
dJLLTsMwEEX3SPzDyAipLFqnqAKEknRRCbGoRHh0jUw8JBbxuHgc2v49brvCDUvfc+fOQ87nW9vB
D3o2jgoxnWQCkGqnDTWFWL09jO8EcFCkVecIC7FDFvPy/CxnDhBriQvRhrC+l5LrFq3iiVsjRfLp
vFUhPn0jee1RaW4Rg+3kdZbdSKsMCahdT6EQs5mAnsx3j4ujML0VZc6mzENZofqCpVM6l6HM5V48
gqll0Nip3QnI/iOvL4vU7LxpDKku1WP6+yFdPnmTwgr9YT2qMUWLanWZanu7HAL7k+m+Q/A9QWi9
65sWRheSr9KI2lHAbQDemFC3MGw6zAvU2w/0w45xmvvsGEaMMV6f9Hw0cZqhy//pM9xo6TZJqYw/
pvwFAAD//wMAUEsDBBQABgAIAAAAIQCpxHlInAYAAF8zAAANAAAAeGwvc3R5bGVzLnhtbNRb3Y7i
NhS+r9R3iDJStVuVCWFgGFhg2mEWaaXtaqWZSr1YaRSCA9EmMU3MLGzVJ+hl36Nv0Ldp36PHdpwA
wYnJhNksN8SOffyd7xwf/2ZwvfY97RGFkYuDoW6eN3UNBTaeucF8qP9yP2lc6VpErGBmeThAQ32D
Iv169O03g4hsPHS3QIhoICKIhvqCkGXfMCJ7gXwrOsdLFMAbB4e+RSAZzo1oGSJrFtFKvme0ms1L
w7fcQOcS+r6tIsS3wo+rZcPG/tIi7tT1XLJhsnTNt/tv5gEOrakHUNdm27KFbJbIiPddO8QRdsg5
iDOw47g2yqLsGT0DJI0Gwcqf+CTSbLwKyFBvJ1kaf/NmBhR2L3WNKz3GM4Dx8OJ77eyHs7PmebP5
8PIVTX54ITI+8Izvflth8qrB/66vWbEfH17qhmhzp4GupIFd6aVEg7Vl2LPgm6Wa6O02QWlpUkWN
mN3RwMFBSjIoy2zX/xjgT8GEvgKSgXlaajSIPmuPlgc5JpVhYw+HGgEHBOJZTmD5iJf47+8///3n
L1rKsXzX2/DcFqu2sMIIHJlLumjTPObGcVXfBaeimQZvtMKmyzUTzqdDfQI/4I6Rp6TmsW0VCb34
ctxV3HTM55jSeQo+e5SpIjpLuSLzyAh82vW8JDBd0O4BGaMBhEiCwmACCS1+vt8soXMEEM25R7Ny
BaXnobUxWx31ChH23BlFMR+zLpk4LHVZKmYav3CDGVojiJuXrNcZW4Bpd2Pg2B/oOMXhDEYqEX5b
NArwvNHAQw4BsaE7X9B/gpe0EUwIxPXRYOZacxxYHjwaoob4pzVhiIPRbKj7aOaufBDLA8k+OFo0
bkOxBsPD4ChWAOD1wp3QqKgA51ydcrKACcARhOeWz9KdW3yLbKFdbvlT61bgfl+5drnUPl23AvK+
ettVpB/0Z8a1ksM/3Sq5Rle1yTNjrohpwXCBuCoGlVyWTx3laqhfASRVv3sGC2aG11xTqgIv2WFO
A0awmKvZgV6QWz6NTPUCXeB5zwW7AEZ5toUxCxrYijlgn9NNv8v6SAF81X4m2MiFUVOyT4Q50x2/
MNUFzacdUtiyoEI5zz6W7AIQKeoq6Y6XxrDStpHn3dEl8a9OstymmwprZ2sjEraK6UYY3fSkj7BU
jx/5yponRgPLc+eBjwLYXkMhcW26W2dDEvEdtbUjF2tKxYLaO1jiXVeORl5Ns5ZLbzMB1AwzTwHw
NHXD9hjS9E8CfZr1PsQE2YRtmPOdy226OHlbvHXoNvEOWCXitLVTAYMXEgaBIi4fHrY4ESnBgkhv
sUA3XVKTLnDofgY6qVFpnNOPN7IMYqv+EM3OCTCyvl0hjyacR1Ru68pB0m1+5vDC5XgnFalSDlk5
SDgdqT9IOF/JA0m3gunZCO/2teC1BQGxppDb9Y+fMog1ip8yiLWKn1KQdYqfUpB1ip9SkHWKn1KQ
9Y2fMsg1jp8wzkgWBnsRPx2Iyk7t+QgCUS93PrsvfWsuLsMKE9Td0UmO9WnSOHKluTaf2oAyRmb9
xO5X5C+EMhq9W/lTFE7YVZ1Dk4N91swyih7bSJk2ZLObjAL8lk4+TdDfTuZUiewKZmIH3cDssrs8
+Rom6xfRbQ7bSDYXz7J6TJtC88NtyjuZ0lo/GbSFZuo6KHSghDdVHQ507Sx5xzQs1DpMnkxZBRgK
vS6jfZ6tjlFKlc196hQwZ+ZHcswKiDPSDptB3oZS70ymS+WMXYIlUL3CoY6OEqrizK4C7Qkhqo6i
4O8qQ9mTzV3GQVWHMgXZGd7yHBOUdeJtXaBZzN7ABadsa5RuSiZ8HOOYMn0O2Ei2w5gz6zG7CriT
eU+dcLPrwplheofvZLIgcO/Gdxmz+wFAiaNKbVsKQaVWyiLY4hvoPOjfFfGt0DPh2rJyiFQRBxqp
RlwVcYkpRMBNA8eBbrvP9RNb2BenNO8zC2yXKpArHqY4FXuGQQ+J4Fho63Bt52gtOUPS6D3hoT7G
vm9piT355WBxLBeXeUcXbJ4wOdA9XbkecQN+cAQK7gvlFVKp7Io8Q8ZO+wDcbJ2e+LHDLUI/puBv
xcVbaGiGHGvlkfvk5VBPn39mt2gBelzqvfuICRMx1NPnt/SqLhxOAEy0Jm8juFkL/9oqdIf6769v
ur3b15NW46p5c9VoX6BOo9e5uW102uOb29tJr9lqjv8AxemXJ334PuAJX3awL1DghM5s9yMPvv8I
Y2Vj8Hdp3lDfSnD47EY0wIaFuFDCiJIvY0b/AwAA//8DAFBLAwQUAAYACAAAACEAjNwihp4BAABY
AwAAEAAIAWRvY1Byb3BzL2FwcC54bWwgogQBKKAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AACck0FP4zAQhe9I/IfId+q0RStUOUarAgJpV1RqgbPXmTQWjm15hqjdX4+TqDQF9rK38bynp88z
trjeNTZrIaLxrmDTSc4ycNqXxm0L9rS5u7hiGZJypbLeQcH2gOxanp+JVfQBIhnALEU4LFhNFBac
o66hUThJsktK5WOjKB3jlvuqMhpuvH5rwBGf5fkPDjsCV0J5ET4C2ZC4aOl/Q0uvOz583uxDApbi
ZwjWaEXplvK30dGjryi73Wmwgo9FkejWoN+iob3MBR8fxVorC8sULCtlEQQ/NsQ9qG5oK2UiStHS
ogVNPmZo/qaxzVj2RyF0OAVrVTTKUcLqbMOhr21AivLFx1esAQgFT4ah2Zdj77g2l3LeG1JxauwC
BpAknCJuDFnAx2qlIn1DPB8T9wwD74Cz7vimY74P0l6a/VsaSMe36geV+D4RLX0TlNvLB0dgs6WP
wcd+g4IfJPHLuFd8Cht/owgOWzltinWtIpRpkQf92BD3aSHRdiHLWrktlAfPV6F7Q8/DR5HTy0k+
z9PzGPUEP34J+Q4AAP//AwBQSwMEFAAGAAgAAAAhABg6Wmw8AQAAWQIAABEACAFkb2NQcm9wcy9j
b3JlLnhtbCCiBAEooAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJSSzU7DMBCE70i8Q+R7
4jgFVKwklQD1RCUkioq4Wfa2tYgdyzZN+/Y4Pw1B5cLRO7Pfzq6cL46qig5gnax1gUiSogg0r4XU
uwK9rZfxHEXOMy1YVWso0AkcWpTXVzk3lNcWXmxtwHoJLgok7Sg3Bdp7byjGju9BMZcEhw7itraK
+fC0O2wY/2Q7wFma3mEFngnmGW6BsRmJaEAKPiLNl606gOAYKlCgvcMkIfjH68Eq92dDp0ycSvqT
CTsNcadswXtxdB+dHI1N0yTNrIsR8hP8vnp+7VaNpW5vxQGVueCUW2C+tuW+OmQ5nhTa41XM+VW4
81aCeDgNnst64HSxexiIKAShfeyzspk9Pq2XqMxSQmKSxYSsyS0l9zQlH+3YX/1tsL6ghuH/Id7M
J8QzoMzxxWcovwEAAP//AwBQSwECLQAUAAYACAAAACEAfGyYFmwBAACgBQAAEwAAAAAAAAAAAAAA
AAAAAAAAW0NvbnRlbnRfVHlwZXNdLnhtbFBLAQItABQABgAIAAAAIQC1VTAj9QAAAEwCAAALAAAA
AAAAAAAAAAAAAKUDAABfcmVscy8ucmVsc1BLAQItABQABgAIAAAAIQDeCf0oAgEAANQDAAAaAAAA
AAAAAAAAAAAAAMsGAAB4bC9fcmVscy93b3JrYm9vay54bWwucmVsc1BLAQItABQABgAIAAAAIQAw
MsWFYgEAAHECAAAPAAAAAAAAAAAAAAAAAA0JAAB4bC93b3JrYm9vay54bWxQSwECLQAUAAYACAAA
ACEA+2KlbZQGAACnGwAAEwAAAAAAAAAAAAAAAACcCgAAeGwvdGhlbWUvdGhlbWUxLnhtbFBLAQIt
ABQABgAIAAAAIQDCwSunegEAAKICAAAYAAAAAAAAAAAAAAAAAGERAAB4bC93b3Jrc2hlZXRzL3No
ZWV0Mi54bWxQSwECLQAUAAYACAAAACEAwsErp3oBAACiAgAAGAAAAAAAAAAAAAAAAAAREwAAeGwv
d29ya3NoZWV0cy9zaGVldDMueG1sUEsBAi0AFAAGAAgAAAAhAHQvsEDKCQAABSUAABgAAAAAAAAA
AAAAAAAAwRQAAHhsL3dvcmtzaGVldHMvc2hlZXQxLnhtbFBLAQItABQABgAIAAAAIQBmnSOEJgEA
AHACAAAUAAAAAAAAAAAAAAAAAMEeAAB4bC9zaGFyZWRTdHJpbmdzLnhtbFBLAQItABQABgAIAAAA
IQCpxHlInAYAAF8zAAANAAAAAAAAAAAAAAAAABkgAAB4bC9zdHlsZXMueG1sUEsBAi0AFAAGAAgA
AAAhAIzcIoaeAQAAWAMAABAAAAAAAAAAAAAAAAAA4CYAAGRvY1Byb3BzL2FwcC54bWxQSwECLQAU
AAYACAAAACEAGDpabDwBAABZAgAAEQAAAAAAAAAAAAAAAAC0KQAAZG9jUHJvcHMvY29yZS54bWxQ
SwUGAAAAAAwADAAMAwAAJywAAAAA

--_003_C10D3FB0CD45994C8A51FEC1227CE22F37666D5EA5shsmsx502ccrc_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--_003_C10D3FB0CD45994C8A51FEC1227CE22F37666D5EA5shsmsx502ccrc_--


From xen-devel-bounces@lists.xensource.com Sun Dec 11 15:29:41 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 11 Dec 2011 15:29:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZlKi-00060C-Bv; Sun, 11 Dec 2011 15:28:56 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <hui.lv@intel.com>) id 1RZlKf-000607-Pi
	for xen-devel@lists.xensource.com; Sun, 11 Dec 2011 15:28:54 +0000
X-Env-Sender: hui.lv@intel.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1323617280!5098091!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDI5NjA5NA==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4683 invoked from network); 11 Dec 2011 15:28:00 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-11.tower-174.messagelabs.com with SMTP;
	11 Dec 2011 15:28:00 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga102.fm.intel.com with ESMTP; 11 Dec 2011 07:27:59 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; 
	d="xml'?xlsx'72,48?scan'72,48,72,48,208?rels'72,48,72,48,208?diff'72,48,72,48,208";
	a="94933637"
Received: from pgsmsx601.gar.corp.intel.com ([10.221.43.69])
	by fmsmga001.fm.intel.com with ESMTP; 11 Dec 2011 07:27:57 -0800
Received: from pgsmsx509.gar.corp.intel.com (172.30.13.17) by
	pgsmsx601.gar.corp.intel.com (10.221.43.69) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Sun, 11 Dec 2011 23:27:57 +0800
Received: from shsmsx602.ccr.corp.intel.com (10.239.4.104) by
	PGSMSX509.gar.corp.intel.com (172.30.13.17) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Sun, 11 Dec 2011 23:27:56 +0800
Received: from shsmsx502.ccr.corp.intel.com ([10.239.4.96]) by
	SHSMSX602.ccr.corp.intel.com ([10.239.4.104]) with mapi;
	Sun, 11 Dec 2011 23:27:55 +0800
From: "Lv, Hui" <hui.lv@intel.com>
To: George Dunlap <George.Dunlap@eu.citrix.com>
Date: Sun, 11 Dec 2011 23:27:54 +0800
Thread-Topic: [Xen-devel] [PATCH] scheduler rate controller
Thread-Index: AcywTKEQpqSflkXmRa6gWOoeZKGM1QHqYimQ
Message-ID: <C10D3FB0CD45994C8A51FEC1227CE22F37666D5EA5@shsmsx502.ccr.corp.intel.com>
References: <C10D3FB0CD45994C8A51FEC1227CE22F340768D793@shsmsx502.ccr.corp.intel.com>
	<CAFLBxZZ9nqeb7CVqTZCsEtJRjgGMTHF2Ak929kvauj2KUFSOyg@mail.gmail.com>
	<C10D3FB0CD45994C8A51FEC1227CE22F3428CB5EF9@shsmsx502.ccr.corp.intel.com>
	<1319789425.19320.12.camel@Abyss>
	<C10D3FB0CD45994C8A51FEC1227CE22F3428CB61F2@shsmsx502.ccr.corp.intel.com>
	<1319796584.19320.31.camel@Abyss>	<1319818714.21033.414.camel@elijah>
	<C10D3FB0CD45994C8A51FEC1227CE22F34B3905D03@shsmsx502.ccr.corp.intel.com>
	<CAFLBxZa5v_YgnC1LTa4a5wis4h6eQPijCAfUDLDsR4ucMuBXWg@mail.gmail.com>
	<C10D3FB0CD45994C8A51FEC1227CE22F37499C2733@shsmsx502.ccr.corp.intel.com>
	<CAFLBxZZ-F2hNTNHtiBCuQ0tVqJDe6btPnvofHK4KaDDQz8Rxtw@mail.gmail.com>
In-Reply-To: <CAFLBxZZ-F2hNTNHtiBCuQ0tVqJDe6btPnvofHK4KaDDQz8Rxtw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/mixed;
	boundary="_003_C10D3FB0CD45994C8A51FEC1227CE22F37666D5EA5shsmsx502ccrc_"
MIME-Version: 1.0
Cc: "Tian, Kevin" <kevin.tian@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, "Dong, Eddie" <eddie.dong@intel.com>,
	George Dunlap <george.dunlap@citrix.com>, "Duan,
	Jiangang" <jiangang.duan@intel.com>, Dario Faggioli <raistlin@linux.it>
Subject: Re: [Xen-devel] [PATCH] scheduler rate controller
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--_003_C10D3FB0CD45994C8A51FEC1227CE22F37666D5EA5shsmsx502ccrc_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi George,

Thank you very much for your feedbacks.
I have finished the measurement work based on the delay method. From the co=
mparable results, 1ms-delay can do as well as SRC patch to gain significant=
 performance boost without obvious drawbacks.

1. Basically, the "delay method" can achieve nearly the same benefits as my=
 previous SRC patch, 11% overall performance boost for SPECvirt than origin=
al credit scheduler.
2. I have tried 1ms delay and 10ms delay, there is no big difference betwee=
n these two configurations. (1ms is enough to achieve a good performance)
3. I have compared different load level response time/latency (low, high, p=
eak), "delay method" didn't bring very much Qos increase.
4. 1ms delay can reduce 30% context switch at peak performance, where produ=
ces the benefits.

You can find the raw data from the attached excel file.
The attached credit_1.diff patch works stable at my side.


> Looks fine overall.  One issue with the patch is that it will not only fa=
il to
> preempt for a higher-priority vcpu, it will also fail to preempt for task=
lets.
> Tasklet work must be done immediately.  Perhaps we can add
> "!tasklet_work_scheduled" to the list of conditions for

Yes, added "!tasklet_work_scheduled". I have done the experiments to compar=
e with/without this, there is not big difference.=20
>=20
> Why did you change "MICROSECS" to "MILLISECS" when calculating timeslice?
> In this case, it will set the timeslice to a full second!
> Not what we want...
Sorry , it's my typo, I have changed

> From a software maintenance perspective, I'm not a fan of early returns f=
rom
> functions.  I think it's too easy not to notice that there's a different =
return
> path.  In this case, I think I'd prefer adding a label, and using "goto o=
ut;"
> instead.

Followed this code style.

> If you were using mercurial queues, you could put this after the last one=
, and it
> would be easier to see the proposed "adaptive" part of the code. :-)
>=20
> Hypervisors are very complicated; it's best to keep things as absolutely =
simple
> as possible.  This kind of mechanism is exactly the sort of thing that ma=
kes it
> very hard to predict what will happen.  I think unless you can show that =
it adds
> a significant benefit, it's better just to use the min timeslice.

In fact, I have tested the results with 1ms delay and 10ms delay, there is =
no significant performance improvement. It means, even though we select ada=
ptive method, there is also no significant performance boost with compariso=
n to 1ms.
1ms is good enough insofar.=20

> Regarding this particular code, a couple of items, just for feedback:
> * All of the ratelimiting code and data structures should be in the plugg=
able
> scheduler, not in common code.
Agreed.


> an adaptive solution, you'd need to make a per-cpu variable with the per-=
cpu
> rate scheduling; and then set it to the global variable (which is the use=
r
> configuration).

It seems no need to make it adaptive now :)

> I've taken your two patches, given them the proper formating, and made th=
em
> into a patch series (the first adding the ratelimiting, the second adding=
 the
> adaptive bit); they are attached.  You should be able to easily pull them=
 into a
> mercurial patchqueue using "hg qimport /path/to/patches/*.diff".  In the
> future, I will not look at any patches which do not apply using either "p=
atch -p1"
> or "hg qimport."

Thanks for the coach to submit patch in a right way.
>=20
>  -George

--_003_C10D3FB0CD45994C8A51FEC1227CE22F37666D5EA5shsmsx502ccrc_
Content-Type: application/octet-stream; name="credit_1.diff"
Content-Description: credit_1.diff
Content-Disposition: attachment; filename="credit_1.diff"; size=4021;
	creation-date="Sun, 11 Dec 2011 22:57:10 GMT";
	modification-date="Sun, 11 Dec 2011 15:57:00 GMT"
Content-Transfer-Encoding: base64

ZGlmZiAtciAxYzU4YmI2NjRkOGQgeGVuL2NvbW1vbi9zY2hlZF9jcmVkaXQuYwotLS0gYS94ZW4v
Y29tbW9uL3NjaGVkX2NyZWRpdC5jCVRodSBEZWMgMDggMTc6MTU6MTYgMjAxMSArMDAwMAorKysg
Yi94ZW4vY29tbW9uL3NjaGVkX2NyZWRpdC5jCVN1biBEZWMgMTEgMDI6Mzk6MDcgMjAxMSAtMDUw
MApAQCAtMTA5LDcgKzEwOSw5IEBAIHN0YXRpYyBib29sX3QgX19yZWFkX21vc3RseSBzY2hlZF9j
cmVkaXQKIGJvb2xlYW5fcGFyYW0oInNjaGVkX2NyZWRpdF9kZWZhdWx0X3lpZWxkIiwgc2NoZWRf
Y3JlZGl0X2RlZmF1bHRfeWllbGQpOwogc3RhdGljIGludCBfX3JlYWRfbW9zdGx5IHNjaGVkX2Ny
ZWRpdF90c2xpY2VfbXMgPSBDU0NIRURfREVGQVVMVF9UU0xJQ0VfTVM7CiBpbnRlZ2VyX3BhcmFt
KCJzY2hlZF9jcmVkaXRfdHNsaWNlX21zIiwgc2NoZWRfY3JlZGl0X3RzbGljZV9tcyk7Ci0KKy8q
IFNjaGVkdWxlciBnZW5lcmljIHBhcmFtZXRlcnMKKyovCitleHRlcm4gaW50IHNjaGVkX3JhdGVs
aW1pdF91czsKIC8qCiAgKiBQaHlzaWNhbCBDUFUKICAqLwpAQCAtMTI5NywxMCArMTI5OSwxNSBA
QCBjc2NoZWRfc2NoZWR1bGUoCiAgICAgc3RydWN0IGNzY2hlZF9wcml2YXRlICpwcnYgPSBDU0NI
RURfUFJJVihvcHMpOwogICAgIHN0cnVjdCBjc2NoZWRfdmNwdSAqc25leHQ7CiAgICAgc3RydWN0
IHRhc2tfc2xpY2UgcmV0OworICAgIHNfdGltZV90IHJ1bnRpbWUsIHRzbGljZTsKIAogICAgIENT
Q0hFRF9TVEFUX0NSQU5LKHNjaGVkdWxlKTsKICAgICBDU0NIRURfVkNQVV9DSEVDSyhjdXJyZW50
KTsKIAorICAgIHJ1bnRpbWUgPSBub3cgLSBjdXJyZW50LT5ydW5zdGF0ZS5zdGF0ZV9lbnRyeV90
aW1lOworICAgIGlmICggcnVudGltZSA8IDAgKSAvKiBEb2VzIHRoaXMgZXZlciBoYXBwZW4/ICov
CisgICAgICAgIHJ1bnRpbWUgPSAwOworCiAgICAgaWYgKCAhaXNfaWRsZV92Y3B1KHNjdXJyLT52
Y3B1KSApCiAgICAgewogICAgICAgICAvKiBVcGRhdGUgY3JlZGl0cyBvZiBhIG5vbi1pZGxlIFZD
UFUuICovCkBAIC0xMzEzLDYgKzEzMjAsNDEgQEAgY3NjaGVkX3NjaGVkdWxlKAogICAgICAgICBz
Y3Vyci0+cHJpID0gQ1NDSEVEX1BSSV9JRExFOwogICAgIH0KIAorICAgIC8qIENob2ljZXMsIGNo
b2ljZXM6CisgICAgICogLSBJZiB3ZSBoYXZlIGEgdGFza2xldCwgd2UgbmVlZCB0byBydW4gdGhl
IGlkbGUgdmNwdSBubyBtYXR0ZXIgd2hhdC4KKyAgICAgKiAtIElmIHNjaGVkIHJhdGUgbGltaXRp
bmcgaXMgaW4gZWZmZWN0LCBhbmQgdGhlIGN1cnJlbnQgdmNwdSBoYXMKKyAgICAgKiAgIHJ1biBm
b3IgbGVzcyB0aGFuIHRoYXQgYW1vdW50IG9mIHRpbWUsIGNvbnRpbnVlIHRoZSBjdXJyZW50IG9u
ZSwKKyAgICAgKiAgIGJ1dCB3aXRoIGEgc2hvcnRlciB0aW1lc2xpY2UgYW5kIHJldHVybiBpdCBp
bW1lZGlhdGVseQorICAgICAqIC0gT3RoZXJ3aXNlLCBjaG9zZSB0aGUgb25lIHdpdGggdGhlIGhp
Z2hlc3QgcHJpb3JpdHkgKHdoaWNoIG1heQorICAgICAqICAgYmUgdGhlIG9uZSBjdXJyZW50bHkg
cnVubmluZykKKyAgICAgKiAtIElmIHRoZSBjdXJyZW50bHkgcnVubmluZyBvbmUgaXMgVFNfT1ZF
Uiwgc2VlIGlmIHRoZXJlCisgICAgICogICBpcyBhIGhpZ2hlciBwcmlvcml0eSBvbmUgd2FpdGlu
ZyBvbiB0aGUgcnVucXVldWUgb2YgYW5vdGhlcgorICAgICAqICAgY3B1IGFuZCBzdGVhbCBpdC4K
KyAgICAgKi8KKworICAgIC8qIElmIHdlIGhhdmUgc2NoZWR1bGUgcmF0ZSBsaW1pdGluZyBlbmFi
bGVkLCBjaGVjayB0byBzZWUKKyAgICAgKiBob3cgbG9uZyB3ZSd2ZSBydW4gZm9yLiAqLyAgCisg
ICAgaWYgKCBzY2hlZF9yYXRlbGltaXRfdXMKKwkgJiYgIXRhc2tsZXRfd29ya19zY2hlZHVsZWQK
KyAgICAgICAgICYmIHZjcHVfcnVubmFibGUoY3VycmVudCkKKyAgICAgICAgICYmICFpc19pZGxl
X3ZjcHUoY3VycmVudCkKKyAgICAgICAgICYmIHJ1bnRpbWUgPCBNSUNST1NFQ1Moc2NoZWRfcmF0
ZWxpbWl0X3VzKSApCisgICAgeworICAgICAgICBzbmV4dCA9IHNjdXJyOworCXNuZXh0LT5zdGFy
dF90aW1lICs9IG5vdzsKKyAgICAgICAgcGVyZmNfaW5jcihkZWxheV9tcyk7CisgICAgICAgIHRz
bGljZSA9IE1JQ1JPU0VDUyhzY2hlZF9yYXRlbGltaXRfdXMpOworCXJldC5taWdyYXRlZCA9IDA7
CisJZ290byBvdXQ7CisgICAgfQorICAgIGVsc2UKKyAgICB7CisgICAgICAgIC8qCisgICAgICAg
ICAqIFNlbGVjdCBuZXh0IHJ1bm5hYmxlIGxvY2FsIFZDUFUgKGllIHRvcCBvZiBsb2NhbCBydW5x
KQorICAgICAgICAgKi8KKyAgICAgICAgdHNsaWNlID0gTUlMTElTRUNTKHBydi0+dHNsaWNlX21z
KTsKKyAgICB9CisgICAgCiAgICAgLyoKICAgICAgKiBTZWxlY3QgbmV4dCBydW5uYWJsZSBsb2Nh
bCBWQ1BVIChpZSB0b3Agb2YgbG9jYWwgcnVucSkKICAgICAgKi8KQEAgLTEzNjcsMTEgKzE0MDks
MTIgQEAgY3NjaGVkX3NjaGVkdWxlKAogICAgIGlmICggIWlzX2lkbGVfdmNwdShzbmV4dC0+dmNw
dSkgKQogICAgICAgICBzbmV4dC0+c3RhcnRfdGltZSArPSBub3c7CiAKK291dDoKICAgICAvKgog
ICAgICAqIFJldHVybiB0YXNrIHRvIHJ1biBuZXh0Li4uCiAgICAgICovCiAgICAgcmV0LnRpbWUg
PSAoaXNfaWRsZV92Y3B1KHNuZXh0LT52Y3B1KSA/Ci0gICAgICAgICAgICAgICAgLTEgOiBNSUxM
SVNFQ1MocHJ2LT50c2xpY2VfbXMpKTsKKyAgICAgICAgICAgICAgICAtMSA6IHRzbGljZSk7CiAg
ICAgcmV0LnRhc2sgPSBzbmV4dC0+dmNwdTsKIAogICAgIENTQ0hFRF9WQ1BVX0NIRUNLKHJldC50
YXNrKTsKZGlmZiAtciAxYzU4YmI2NjRkOGQgeGVuL2NvbW1vbi9zY2hlZHVsZS5jCi0tLSBhL3hl
bi9jb21tb24vc2NoZWR1bGUuYwlUaHUgRGVjIDA4IDE3OjE1OjE2IDIwMTEgKzAwMDAKKysrIGIv
eGVuL2NvbW1vbi9zY2hlZHVsZS5jCVN1biBEZWMgMTEgMDI6Mzk6MDcgMjAxMSAtMDUwMApAQCAt
NDcsNiArNDcsMTAgQEAgc3RyaW5nX3BhcmFtKCJzY2hlZCIsIG9wdF9zY2hlZCk7CiBib29sX3Qg
c2NoZWRfc210X3Bvd2VyX3NhdmluZ3MgPSAwOwogYm9vbGVhbl9wYXJhbSgic2NoZWRfc210X3Bv
d2VyX3NhdmluZ3MiLCBzY2hlZF9zbXRfcG93ZXJfc2F2aW5ncyk7CiAKKy8qIERlZmF1bHQgc2No
ZWR1bGluZyByYXRlIGxpbWl0OiAxbXMgKi8KK2ludCBzY2hlZF9yYXRlbGltaXRfdXMgPSAxMDAw
OworaW50ZWdlcl9wYXJhbSgic2NoZWRfcmF0ZWxpbWl0X3VzIiwgc2NoZWRfcmF0ZWxpbWl0X3Vz
KTsKKwogLyogVmFyaW91cyB0aW1lciBoYW5kbGVycy4gKi8KIHN0YXRpYyB2b2lkIHNfdGltZXJf
Zm4odm9pZCAqdW51c2VkKTsKIHN0YXRpYyB2b2lkIHZjcHVfcGVyaW9kaWNfdGltZXJfZm4odm9p
ZCAqZGF0YSk7CmRpZmYgLXIgMWM1OGJiNjY0ZDhkIHhlbi9pbmNsdWRlL3hlbi9wZXJmY19kZWZu
LmgKLS0tIGEveGVuL2luY2x1ZGUveGVuL3BlcmZjX2RlZm4uaAlUaHUgRGVjIDA4IDE3OjE1OjE2
IDIwMTEgKzAwMDAKKysrIGIveGVuL2luY2x1ZGUveGVuL3BlcmZjX2RlZm4uaAlTdW4gRGVjIDEx
IDAyOjM5OjA3IDIwMTEgLTA1MDAKQEAgLTE1LDcgKzE1LDcgQEAgUEVSRkNPVU5URVIoaXBpcywg
ICAgICAgICAgICAgICAgICAgIiNJUAogUEVSRkNPVU5URVIoc2NoZWRfaXJxLCAgICAgICAgICAg
ICAgInNjaGVkOiB0aW1lciIpCiBQRVJGQ09VTlRFUihzY2hlZF9ydW4sICAgICAgICAgICAgICAi
c2NoZWQ6IHJ1bnMgdGhyb3VnaCBzY2hlZHVsZXIiKQogUEVSRkNPVU5URVIoc2NoZWRfY3R4LCAg
ICAgICAgICAgICAgInNjaGVkOiBjb250ZXh0IHN3aXRjaGVzIikKLQorUEVSRkNPVU5URVIoZGVs
YXlfbXMsCQkgICAgImNzY2hlZDogZGVsYXkiKQogUEVSRkNPVU5URVIodmNwdV9jaGVjaywgICAg
ICAgICAgICAgImNzY2hlZDogdmNwdV9jaGVjayIpCiBQRVJGQ09VTlRFUihzY2hlZHVsZSwgICAg
ICAgICAgICAgICAiY3NjaGVkOiBzY2hlZHVsZSIpCiBQRVJGQ09VTlRFUihhY2N0X3J1biwgICAg
ICAgICAgICAgICAiY3NjaGVkOiBhY2N0X3J1biIpCg==

--_003_C10D3FB0CD45994C8A51FEC1227CE22F37666D5EA5shsmsx502ccrc_
Content-Type: application/vnd.openxmlformats-officedocument.spreadsheetml.sheet;
	name="scheduler comparison.xlsx"
Content-Description: scheduler comparison.xlsx
Content-Disposition: attachment; filename="scheduler comparison.xlsx";
	size=12105; creation-date="Sun, 11 Dec 2011 23:19:48 GMT";
	modification-date="Sun, 11 Dec 2011 23:19:48 GMT"
Content-Transfer-Encoding: base64

UEsDBBQABgAIAAAAIQB8bJgWbAEAAKAFAAATAAgCW0NvbnRlbnRfVHlwZXNdLnhtbCCiBAIooAAC
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADM
lF1LwzAUhu8F/0PJrTTZJojIul34cakD5w+IzekaliYhJ5vbv/c0+0CkbgwHetPQ5pz3fZI073C8
aky2hIDa2YL1eY9lYEuntJ0V7G36lN+yDKO0ShpnoWBrQDYeXV4Mp2sPmFG3xYLVMfo7IbCsoZHI
nQdLM5ULjYz0GmbCy3IuZyAGvd6NKJ2NYGMeWw02Gj5AJRcmZo8r+rwhCWCQZfebwtarYNJ7o0sZ
iVQsrfrmkm8dOHWmGqy1xyvCYKLToZ352WDb90JbE7SCbCJDfJYNYYiVER8uzN+dm/PDIh2Urqp0
CcqVi4Z2gKMPIBXWALExPI28kdruuA/4p2IUaeifGaRdXxI+kWPwTziu/4gj0v8PIj1/fyRJ5sgB
YFwbwDOvdiN6zLmWAdRrDJQUZwf4qn2Ig+7RJDiPlCgBTt+FXWS03bknIQhRwz40ui7f3pHS6HTD
b7cf2rxToDq8RcrX0ScAAAD//wMAUEsDBBQABgAIAAAAIQC1VTAj9QAAAEwCAAALAAgCX3JlbHMv
LnJlbHMgogQCKKAAAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAjJLPTsMwDMbvSLxD5PvqbkgIoaW7TEi7IVQewCTuH7WNoyRA9/aEA4JKY9vR
9ufPP1ve7uZpVB8cYi9Ow7ooQbEzYnvXanitn1YPoGIiZ2kUxxqOHGFX3d5sX3iklJti1/uosouL
GrqU/CNiNB1PFAvx7HKlkTBRymFo0ZMZqGXclOU9hr8eUC081cFqCAd7B6o++jz5src0TW94L+Z9
YpdOjECeEzvLduVDZgupz9uomkLLSYMV85zTEcn7ImMDnibaXE/0/7Y4cSJLidBI4PM834pzQOvr
gS6faKn4vc484qeE4U1k+GHBxQ9UXwAAAP//AwBQSwMEFAAGAAgAAAAhAN4J/SgCAQAA1AMAABoA
CAF4bC9fcmVscy93b3JrYm9vay54bWwucmVscyCiBAEooAABAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAALyTz2rDMAzG74O9g9F9cZJuZZQ6vYxBr1v3ACZR4tDENpb2J28/k0O6QMkuoReDJPx9
P9Cn/eGn78QXBmqdVZAlKQi0pata2yj4OL0+PIMg1rbSnbOoYECCQ3F/t3/DTnP8RKb1JKKKJQWG
2e+kpNJgrylxHm2c1C70mmMZGul1edYNyjxNtzL81YBipimOlYJwrDYgToOPzv9ru7puS3xx5WeP
lq9YyG8XzmQQOYrq0CArmFokx8kmicQgr8PkN4bJl2CyG8NkSzDbNWHI6IDVO4eYQrqsatZegnla
FYaHLoZ+CgyN9ZL945r2HE8JL+5jKcd32oec3WLxCwAA//8DAFBLAwQUAAYACAAAACEAMDLFhWIB
AABxAgAADwAAAHhsL3dvcmtib29rLnhtbIxSy27CMBC8V+o/WL6XJA6kFJEgVW1VLlWlUji78YZY
OHZkOw38fTdGPCQuPe2udzKeGWe+2DeK/IJ10uicJqOYEtClEVJvc/q9enuYUuI814IroyGnB3B0
UdzfzXtjdz/G7AgSaJfT2vt2FkWurKHhbmRa0LipjG24x9FuI9da4MLVAL5REYvjLGq41PTIMLP/
4TBVJUt4MWXXgPZHEguKe5Tvatk6WswrqWB9dER4237wBnXvFSWKO/8qpAeR0wmOpofLwZgS27XP
nVS4fUpjRqPibPLTEgEV75Rfob0TO+bFxoxlA3KIYi2hd5ePhpHsN1IL0+c0zTDaw2lKUhTQh9VG
Cl8j1SO7nL2D3NY+p1M2jQf26Io+BIjXhEp0cPc1hJrgSw11iQawtzOJjV2KZGC4QbMrNPZndPB9
g06v0Nif0WlQF+AoqeSqxKiGEkSMJxkLt0env6X4AwAA//8DAFBLAwQUAAYACAAAACEA+2KlbZQG
AACnGwAAEwAAAHhsL3RoZW1lL3RoZW1lMS54bWzsWU9v2zYUvw/YdyB0b20nthsHdYrYsZutTRvE
boceaZmWWFOiQNJJfRva44ABw7phlwG77TBsK9ACu3SfJluHrQP6FfZISrIYy0vSBhvW1YdEIn98
/9/jI3X12oOIoUMiJOVx26tdrnqIxD4f0zhoe3eG/UsbHpIKx2PMeEza3pxI79rW++9dxZsqJBFB
sD6Wm7jthUolm5WK9GEYy8s8ITHMTbiIsIJXEVTGAh8B3YhV1qrVZiXCNPZQjCMge3syoT5BQ03S
28qI9xi8xkrqAZ+JgSZNnBUGO57WNELOZZcJdIhZ2wM+Y340JA+UhxiWCibaXtX8vMrW1QreTBcx
tWJtYV3f/NJ16YLxdM3wFMEoZ1rr11tXdnL6BsDUMq7X63V7tZyeAWDfB02tLEWa9f5GrZPRLIDs
4zLtbrVRrbv4Av31JZlbnU6n0UplsUQNyD7Wl/Ab1WZ9e83BG5DFN5bw9c52t9t08AZk8c0lfP9K
q1l38QYUMhpPl9Daof1+Sj2HTDjbLYVvAHyjmsIXKIiGPLo0iwmP1apYi/B9LvoA0ECGFY2Rmidk
gn2I4i6ORoJizQBvElyYsUO+XBrSvJD0BU1U2/swwZARC3qvnn//6vlT9Or5k+OHz44f/nT86NHx
wx8tLWfhLo6D4sKX337259cfoz+efvPy8RfleFnE//rDJ7/8/Hk5EDJoIdGLL5/89uzJi68+/f27
xyXwbYFHRfiQRkSiW+QIHfAIdDOGcSUnI3G+FcMQU2cFDoF2CemeCh3grTlmZbgOcY13V0DxKANe
n913ZB2EYqZoCecbYeQA9zhnHS5KDXBD8ypYeDiLg3LmYlbEHWB8WMa7i2PHtb1ZAlUzC0rH9t2Q
OGLuMxwrHJCYKKTn+JSQEu3uUerYdY/6gks+UegeRR1MS00ypCMnkBaLdmkEfpmX6Qyudmyzdxd1
OCvTeoccukhICMxKhB8S5pjxOp4pHJWRHOKIFQ1+E6uwTMjBXPhFXE8q8HRAGEe9MZGybM1tAfoW
nH4DQ70qdfsem0cuUig6LaN5E3NeRO7waTfEUVKGHdA4LGI/kFMIUYz2uSqD73E3Q/Q7+AHHK919
lxLH3acXgjs0cERaBIiemYkSX14n3InfwZxNMDFVBkq6U6kjGv9d2WYU6rbl8K5st71t2MTKkmf3
RLFehfsPlugdPIv3CWTF8hb1rkK/q9DeW1+hV+XyxdflRSmGKq0bEttrm847Wtl4TyhjAzVn5KY0
vbeEDWjch0G9zhw6SX4QS0J41JkMDBxcILBZgwRXH1EVDkKcQN9e8zSRQKakA4kSLuG8aIZLaWs8
9P7KnjYb+hxiK4fEao+P7fC6Hs6OGzkZI1VgzrQZo3VN4KzM1q+kREG312FW00KdmVvNiGaKosMt
V1mb2JzLweS5ajCYWxM6GwT9EFi5Ccd+zRrOO5iRsba79VHmFuOFi3SRDPGYpD7Sei/7qGaclMXK
kiJaDxsM+ux4itUK3Fqa7BtwO4uTiuzqK9hl3nsTL2URvPASUDuZjiwuJieL0VHbazXWGh7ycdL2
JnBUhscoAa9L3UxiFsB9k6+EDftTk9lk+cKbrUwxNwlqcPth7b6ksFMHEiHVDpahDQ0zlYYAizUn
K/9aA8x6UQqUVKOzSbG+AcHwr0kBdnRdSyYT4quiswsj2nb2NS2lfKaIGITjIzRiM3GAwf06VEGf
MZVw42Eqgn6B6zltbTPlFuc06YqXYgZnxzFLQpyWW52iWSZbuClIuQzmrSAe6FYqu1Hu/KqYlL8g
VYph/D9TRe8ncAWxPtYe8OF2WGCkM6XtcaFCDlUoCanfF9A4mNoB0QJXvDANQQV31Oa/IIf6v805
S8OkNZwk1QENkKCwH6lQELIPZclE3ynEauneZUmylJCJqIK4MrFij8ghYUNdA5t6b/dQCKFuqkla
BgzuZPy572kGjQLd5BTzzalk+d5rc+Cf7nxsMoNSbh02DU1m/1zEvD1Y7Kp2vVme7b1FRfTEos2q
Z1kBzApbQStN+9cU4Zxbra1YSxqvNTLhwIvLGsNg3hAlcJGE9B/Y/6jwmf3goTfUIT+A2org+4Um
BmEDUX3JNh5IF0g7OILGyQ7aYNKkrGnT1klbLdusL7jTzfmeMLaW7Cz+Pqex8+bMZefk4kUaO7Ww
Y2s7ttLU4NmTKQpDk+wgYxxjvpQVP2bx0X1w9A58NpgxJU0wwacqgaGHHpg8gOS3HM3Srb8AAAD/
/wMAUEsDBBQABgAIAAAAIQDCwSunegEAAKICAAAYAAAAeGwvd29ya3NoZWV0cy9zaGVldDIueG1s
jJJPSwMxEMXvgt8h5O5mq9Y/pVsRS7EHQUS9p9nZ3dBNJiRT2357J1srQi/eMiT5vXlvZvqwc734
gpgs+kqOilIK8AZr69tKfrwvLu6kSKR9rXv0UMk9JPkwOz+bbjGuUwdAggk+VbIjChOlkunA6VRg
AM83DUanicvYqhQi6Hr45Hp1WZY3ymnr5YEwif9hYNNYA3M0GweeDpAIvSbuP3U2pCPNmf/gnI7r
Tbgw6AIjVra3tB+gUjgzWbYeo1717Hs3utbmyB6KE7yzJmLChgrGqUOjp57v1b1i0mxaW3aQYxcR
mko+jqSaTYdwPi1s05+zyFmvENf5YllXssxP1cnbxZD1axQ1NHrT0xtun8G2HfFgr4oxd59NTOr9
HJLh9BhUjMa/snNNmrmh40GTNcxp0FPWu5GC9oFT8PiE/mdb8r+gW3jRsbU+iR6agXgrRTyIlgWf
CUPWuWX5FRKhO1Yd7wLwzMviSrIS0rHI3n63a/YNAAD//wMAUEsDBBQABgAIAAAAIQDCwSunegEA
AKICAAAYAAAAeGwvd29ya3NoZWV0cy9zaGVldDMueG1sjJJPSwMxEMXvgt8h5O5mq9Y/pVsRS7EH
QUS9p9nZ3dBNJiRT2357J1srQi/eMiT5vXlvZvqwc734gpgs+kqOilIK8AZr69tKfrwvLu6kSKR9
rXv0UMk9JPkwOz+bbjGuUwdAggk+VbIjChOlkunA6VRgAM83DUanicvYqhQi6Hr45Hp1WZY3ymnr
5YEwif9hYNNYA3M0GweeDpAIvSbuP3U2pCPNmf/gnI7rTbgw6AIjVra3tB+gUjgzWbYeo1717Hs3
utbmyB6KE7yzJmLChgrGqUOjp57v1b1i0mxaW3aQYxcRmko+jqSaTYdwPi1s05+zyFmvENf5YllX
ssxP1cnbxZD1axQ1NHrT0xtun8G2HfFgr4oxd59NTOr9HJLh9BhUjMa/snNNmrmh40GTNcxp0FPW
u5GC9oFT8PiE/mdb8r+gW3jRsbU+iR6agXgrRTyIlgWfCUPWuWX5FRKhO1Yd7wLwzMviSrIS0rHI
3n63a/YNAAD//wMAUEsDBBQABgAIAAAAIQB0L7BAygkAAAUlAAAYAAAAeGwvd29ya3NoZWV0cy9z
aGVldDEueG1spFpbc+I8En3fqv0PFO9jLFm+UUm+qvi287BVW3t9JsRJqAHMgpPM/Ps9utlWixAm
mwcg6qOWdLpbOgjf/PFzt529tcfTptvfzlkQzmftft09bvbPt/N//bP+ls1np361f1xtu317O//V
nuZ/3P35Tzfv3fHH6aVt+xk87E+385e+PywXi9P6pd2tTkF3aPewPHXH3arHv8fnxelwbFePqtNu
u+BhmCx2q81+rj0sj9f46J6eNuu27Navu3bfayfHdrvqMf/Ty+Zwst5262vc7VbHH6+Hb+tud4CL
h8120/9STuez3Xr5/XnfHVcPW6z7JxOrtfWt/vHc7zbrY3fqnvoA7hZ6ov6a80W+gKe7m8cNViBp
nx3bp9v5PVs2EZsv7m4UQf/etO+nyedZv3r4R7tt1337iDjNZ5L/h677IYHf0RTC5UkBpMvVut+8
tUW73d7Ov8sQ/lcNgo8YYDGMMP1sR6tVxP52nD22T6vXbf/37v0v7eb5pcewURCDA0nF8vFX2Z7W
iAGGDlgs/a67LZzgdbbbIJk4OFz9VO/vm8f+BZ8wk/Xrqe92/9ENar1Dh8h0wLvpgAETjiEvdBKm
E95tJx5k6eVOsKqp4d12ij7tlJhOeLedRPDJ7FLTB++2Dw/OT26h6VOxKVf96u7m2L3PUBQI9umw
kiXGl/CjAqEH7l826x/3nYzM2bBwGRXjBdGYejkfRERPjngvwbfzfD6D6xMS6+0uvFm8IVvWBlFo
BMO4A4S5kNJAEM0Bwl1IdQYSuZD6DES4kMZAEMxhoHiALLD+gQTMZUrCb1FpuZE+QHioMl6yVZgW
xbbirzQtYsBUXkvttTSmJZG9nGkjt6fTvhw7Cb6dC5TawEYysKGmVxhIriKbpyIY6dLz14BY7ilv
d3maBjRwBsAMgPSvXTMj5saYueqNMyeJQ55GnItQRCkbZ+uQgPBeT4IE384jlOpAQkpIMBChJhEG
uWsutZnrFcJMsrv6xF5TO01aYx+Gj1MhkizMYhYmURaNlDkkYEHXkyDBhITMXWWhIcJEIsywOU3+
CLo06EjHLUyxZ4qExZF5dX1XFM0CwbM4ZfqV1rmDzuEaycDjOGI5EyQ2jcGmJn8Y41HCshSCIkmz
bIyUQx22zuupk2BCHZlEYSCajCQT47C6hrSd6SJLRE5LyLUj8i59tWNPQ0byt9F2PiRQKnKWhXEC
uqKYxR9UkdQCk8Pk8lYiwYQFRg8Cg9E0iIiTPC+13dAgYmqvXHsmCE21Y0eUx3Upmhttj/X4YZDk
WY4NK0oyHodZNmHdSQYcbdfTIMGUBhLtwmD0NHiUk/Qutd3QwLKY0FhpO4f8HjYsRqlwfBAHjXGA
beWcA2fxOLuc1X/pGFROwArScByQrLqwoNhssiyPUaXjH2GxNHieWHziwEOCryxe7wTQoaRIagsY
HGaJGIcPqcPG4jOztYQC+cTTMMoSniThuAe4hP4/Es3qCqmlkGYsHURD4TeVflPlN9V+U2Ob9DeA
qShiUj9dvScotKsNGan5wmDkkGNuuNtbaTEQPQOGJHx1DkNSrD6HIfNpLGZaHB8csEyKsAkZX6sN
o+QmGlH5RXQnItE2TVSi31T7TY1t8oUik8pqMvvL27tCfyIVLUYfY1lGtp3S2GOtkzx7RezpWEFq
+64/sTfWPmjFkLEoTeJE8DSNs/HQdAtSqqvredBa7KJaxDdcdQjY45YupDSAQTCOM1MLrT6x156d
FENjAXYGeRIJJoaXeEx6lwoplq6nQksrhwqykoIZ+aU3dYZ4BDmkewzdynP8RwvdwPUWzFhIUqiy
/gwgzDN8Q3ad1BSTsiCPGcd5ol48rsyYViGGUc7iOBacMZHhb/DuUiUl1fVUaQHmUEWyu8BmrrJG
y4IUiTuMrEWiARhdkLKYeKgIQCTEQ00AMSMeGgMYhWIGhlnMIpHnLAIpw5RcMqSwup4MLcMcMjyp
yAxIs5FEdC2lAVjNHEYklyoKEN55r4ewHpCRw+q0XDQeRjZiHPBMRLFIBMpp8jXPZUPKq+vZ0GLM
ZYOkdIE5TnMjJWVRGrtZSs7JSipjvywZXSdkiMa6mJ6LE9XpMCDHmTLwpYNROVGiUV4XqssT26QV
FyQcvvS5MSsNhOszCBCaFh5AsNz5cx3Wdkx9vyEdJkRZNtalnRb4ZwwCEPtXLtIs+qBqsP07LF0+
gBXalXx+U+k3VX5T7Tc1tsmXfJxIvq8F09y7TQSr8ussqPSbKr+p9psa23Rm9kSjfUKyEWMTnTm5
YjJJqDF4HbQoSYiSa8i0VGhFnoGQTK3PQMZM0juUgUy/V40F4ZYkUXtfi6K+jBt1aYG9UW5Moywt
TYvSm2qSlddSey2NaTkTP6mlrt5M5Q27nA529iE45BAsLMbeaOIWyy350iCMToXEoJeSFUGkuEpw
fdQEMaoIEzg90VhLVVwZ5tCpUZgwXGyKLE/HjHKjKLXK9WxoZeMcLWStBb4+q5NFsyECfHGd/kXV
N5K5pemBkpMXviJIE2f7zL0eld9jOkToj1HTHrGPaSxGa1zcDPMsyVPcGaYiynn+UR38lm7jZ3Qb
CWVhMEJLXC4laZhkSZLHPM1ymhilhWsFy8MYyQMhljNcxnHcyLl5VHlwHkQ4VriIsFhBU7cmcJZE
gZRtYRZlWcyJ88aix68JecblHS1mxTP+kfaVP839RhYaJYdEG2qSVEuhPOKs12oP+eSyUBq70Tcs
pLcIlQcg8qWmgNDbSvU0sRGpn7BQkXGIsPAwwm0xj0fq3IL8La0HVaKKbUqFp3wtyHDhaT1jN1zk
KcnHitjFWAhq66mJnSZoY+yGCNRVyMABEhQ/OuDSfIiMw0NEFN/lY1ah6S0pmWdhQEILL06WWRoz
TkAZr4nG0oeONV+8JLUg7YOkTGOt02P8I8WLX+OdkvjS8aqcfHZNakBCX6KkAVGvsbf9ltat7RG6
+7XwelS2h97ic/za7XbxetRujyyI3EHObN+mB+pS1xt2TOx/KLg0RU5H0RhvnWj6QQT9Y/euPT6r
BxZOs3X3Kh8rwFe1u5uh2TwlwZf3kbwgJe24TlyWuBfzLbhEXFZnLbg6XMrrNb8PLgyX8pbNtxR8
iZ97/fYSw59rrzD4ufYaQ59rbzDwufZ7Hi3vUb7+yAUsUrL5FkjWpZRuvqWCRUo43wKBupRSzrc0
sEhJ51vuwdb9ebZgKbRlMQQMj4gcXvAsUb9Z4yGTp27fy8dX5Pb564AHbfZd0e3NA0lysMPquf3r
6vi82Z9m2/YJeREGOMGP+okU9bnvDqoVRf3Q9Xi6xP73gseNWvxCHwYQ709d19t/4Hfxbh9guvsf
AAAA//8DAFBLAwQUAAYACAAAACEAZp0jhCYBAABwAgAAFAAAAHhsL3NoYXJlZFN0cmluZ3MueG1s
dJLLTsMwEEX3SPzDyAipLFqnqAKEknRRCbGoRHh0jUw8JBbxuHgc2v49brvCDUvfc+fOQ87nW9vB
D3o2jgoxnWQCkGqnDTWFWL09jO8EcFCkVecIC7FDFvPy/CxnDhBriQvRhrC+l5LrFq3iiVsjRfLp
vFUhPn0jee1RaW4Rg+3kdZbdSKsMCahdT6EQs5mAnsx3j4ujML0VZc6mzENZofqCpVM6l6HM5V48
gqll0Nip3QnI/iOvL4vU7LxpDKku1WP6+yFdPnmTwgr9YT2qMUWLanWZanu7HAL7k+m+Q/A9QWi9
65sWRheSr9KI2lHAbQDemFC3MGw6zAvU2w/0w45xmvvsGEaMMV6f9Hw0cZqhy//pM9xo6TZJqYw/
pvwFAAD//wMAUEsDBBQABgAIAAAAIQCpxHlInAYAAF8zAAANAAAAeGwvc3R5bGVzLnhtbNRb3Y7i
NhS+r9R3iDJStVuVCWFgGFhg2mEWaaXtaqWZSr1YaRSCA9EmMU3MLGzVJ+hl36Nv0Ldp36PHdpwA
wYnJhNksN8SOffyd7xwf/2ZwvfY97RGFkYuDoW6eN3UNBTaeucF8qP9yP2lc6VpErGBmeThAQ32D
Iv169O03g4hsPHS3QIhoICKIhvqCkGXfMCJ7gXwrOsdLFMAbB4e+RSAZzo1oGSJrFtFKvme0ms1L
w7fcQOcS+r6tIsS3wo+rZcPG/tIi7tT1XLJhsnTNt/tv5gEOrakHUNdm27KFbJbIiPddO8QRdsg5
iDOw47g2yqLsGT0DJI0Gwcqf+CTSbLwKyFBvJ1kaf/NmBhR2L3WNKz3GM4Dx8OJ77eyHs7PmebP5
8PIVTX54ITI+8Izvflth8qrB/66vWbEfH17qhmhzp4GupIFd6aVEg7Vl2LPgm6Wa6O02QWlpUkWN
mN3RwMFBSjIoy2zX/xjgT8GEvgKSgXlaajSIPmuPlgc5JpVhYw+HGgEHBOJZTmD5iJf47+8///3n
L1rKsXzX2/DcFqu2sMIIHJlLumjTPObGcVXfBaeimQZvtMKmyzUTzqdDfQI/4I6Rp6TmsW0VCb34
ctxV3HTM55jSeQo+e5SpIjpLuSLzyAh82vW8JDBd0O4BGaMBhEiCwmACCS1+vt8soXMEEM25R7Ny
BaXnobUxWx31ChH23BlFMR+zLpk4LHVZKmYav3CDGVojiJuXrNcZW4Bpd2Pg2B/oOMXhDEYqEX5b
NArwvNHAQw4BsaE7X9B/gpe0EUwIxPXRYOZacxxYHjwaoob4pzVhiIPRbKj7aOaufBDLA8k+OFo0
bkOxBsPD4ChWAOD1wp3QqKgA51ydcrKACcARhOeWz9KdW3yLbKFdbvlT61bgfl+5drnUPl23AvK+
ettVpB/0Z8a1ksM/3Sq5Rle1yTNjrohpwXCBuCoGlVyWTx3laqhfASRVv3sGC2aG11xTqgIv2WFO
A0awmKvZgV6QWz6NTPUCXeB5zwW7AEZ5toUxCxrYijlgn9NNv8v6SAF81X4m2MiFUVOyT4Q50x2/
MNUFzacdUtiyoEI5zz6W7AIQKeoq6Y6XxrDStpHn3dEl8a9OstymmwprZ2sjEraK6UYY3fSkj7BU
jx/5yponRgPLc+eBjwLYXkMhcW26W2dDEvEdtbUjF2tKxYLaO1jiXVeORl5Ns5ZLbzMB1AwzTwHw
NHXD9hjS9E8CfZr1PsQE2YRtmPOdy226OHlbvHXoNvEOWCXitLVTAYMXEgaBIi4fHrY4ESnBgkhv
sUA3XVKTLnDofgY6qVFpnNOPN7IMYqv+EM3OCTCyvl0hjyacR1Ru68pB0m1+5vDC5XgnFalSDlk5
SDgdqT9IOF/JA0m3gunZCO/2teC1BQGxppDb9Y+fMog1ip8yiLWKn1KQdYqfUpB1ip9SkHWKn1KQ
9Y2fMsg1jp8wzkgWBnsRPx2Iyk7t+QgCUS93PrsvfWsuLsMKE9Td0UmO9WnSOHKluTaf2oAyRmb9
xO5X5C+EMhq9W/lTFE7YVZ1Dk4N91swyih7bSJk2ZLObjAL8lk4+TdDfTuZUiewKZmIH3cDssrs8
+Rom6xfRbQ7bSDYXz7J6TJtC88NtyjuZ0lo/GbSFZuo6KHSghDdVHQ507Sx5xzQs1DpMnkxZBRgK
vS6jfZ6tjlFKlc196hQwZ+ZHcswKiDPSDptB3oZS70ymS+WMXYIlUL3CoY6OEqrizK4C7Qkhqo6i
4O8qQ9mTzV3GQVWHMgXZGd7yHBOUdeJtXaBZzN7ABadsa5RuSiZ8HOOYMn0O2Ei2w5gz6zG7CriT
eU+dcLPrwplheofvZLIgcO/Gdxmz+wFAiaNKbVsKQaVWyiLY4hvoPOjfFfGt0DPh2rJyiFQRBxqp
RlwVcYkpRMBNA8eBbrvP9RNb2BenNO8zC2yXKpArHqY4FXuGQQ+J4Fho63Bt52gtOUPS6D3hoT7G
vm9piT355WBxLBeXeUcXbJ4wOdA9XbkecQN+cAQK7gvlFVKp7Io8Q8ZO+wDcbJ2e+LHDLUI/puBv
xcVbaGiGHGvlkfvk5VBPn39mt2gBelzqvfuICRMx1NPnt/SqLhxOAEy0Jm8juFkL/9oqdIf6769v
ur3b15NW46p5c9VoX6BOo9e5uW102uOb29tJr9lqjv8AxemXJ334PuAJX3awL1DghM5s9yMPvv8I
Y2Vj8Hdp3lDfSnD47EY0wIaFuFDCiJIvY0b/AwAA//8DAFBLAwQUAAYACAAAACEAjNwihp4BAABY
AwAAEAAIAWRvY1Byb3BzL2FwcC54bWwgogQBKKAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AACck0FP4zAQhe9I/IfId+q0RStUOUarAgJpV1RqgbPXmTQWjm15hqjdX4+TqDQF9rK38bynp88z
trjeNTZrIaLxrmDTSc4ycNqXxm0L9rS5u7hiGZJypbLeQcH2gOxanp+JVfQBIhnALEU4LFhNFBac
o66hUThJsktK5WOjKB3jlvuqMhpuvH5rwBGf5fkPDjsCV0J5ET4C2ZC4aOl/Q0uvOz583uxDApbi
ZwjWaEXplvK30dGjryi73Wmwgo9FkejWoN+iob3MBR8fxVorC8sULCtlEQQ/NsQ9qG5oK2UiStHS
ogVNPmZo/qaxzVj2RyF0OAVrVTTKUcLqbMOhr21AivLFx1esAQgFT4ah2Zdj77g2l3LeG1JxauwC
BpAknCJuDFnAx2qlIn1DPB8T9wwD74Cz7vimY74P0l6a/VsaSMe36geV+D4RLX0TlNvLB0dgs6WP
wcd+g4IfJPHLuFd8Cht/owgOWzltinWtIpRpkQf92BD3aSHRdiHLWrktlAfPV6F7Q8/DR5HTy0k+
z9PzGPUEP34J+Q4AAP//AwBQSwMEFAAGAAgAAAAhABg6Wmw8AQAAWQIAABEACAFkb2NQcm9wcy9j
b3JlLnhtbCCiBAEooAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJSSzU7DMBCE70i8Q+R7
4jgFVKwklQD1RCUkioq4Wfa2tYgdyzZN+/Y4Pw1B5cLRO7Pfzq6cL46qig5gnax1gUiSogg0r4XU
uwK9rZfxHEXOMy1YVWso0AkcWpTXVzk3lNcWXmxtwHoJLgok7Sg3Bdp7byjGju9BMZcEhw7itraK
+fC0O2wY/2Q7wFma3mEFngnmGW6BsRmJaEAKPiLNl606gOAYKlCgvcMkIfjH68Eq92dDp0ycSvqT
CTsNcadswXtxdB+dHI1N0yTNrIsR8hP8vnp+7VaNpW5vxQGVueCUW2C+tuW+OmQ5nhTa41XM+VW4
81aCeDgNnst64HSxexiIKAShfeyzspk9Pq2XqMxSQmKSxYSsyS0l9zQlH+3YX/1tsL6ghuH/Id7M
J8QzoMzxxWcovwEAAP//AwBQSwECLQAUAAYACAAAACEAfGyYFmwBAACgBQAAEwAAAAAAAAAAAAAA
AAAAAAAAW0NvbnRlbnRfVHlwZXNdLnhtbFBLAQItABQABgAIAAAAIQC1VTAj9QAAAEwCAAALAAAA
AAAAAAAAAAAAAKUDAABfcmVscy8ucmVsc1BLAQItABQABgAIAAAAIQDeCf0oAgEAANQDAAAaAAAA
AAAAAAAAAAAAAMsGAAB4bC9fcmVscy93b3JrYm9vay54bWwucmVsc1BLAQItABQABgAIAAAAIQAw
MsWFYgEAAHECAAAPAAAAAAAAAAAAAAAAAA0JAAB4bC93b3JrYm9vay54bWxQSwECLQAUAAYACAAA
ACEA+2KlbZQGAACnGwAAEwAAAAAAAAAAAAAAAACcCgAAeGwvdGhlbWUvdGhlbWUxLnhtbFBLAQIt
ABQABgAIAAAAIQDCwSunegEAAKICAAAYAAAAAAAAAAAAAAAAAGERAAB4bC93b3Jrc2hlZXRzL3No
ZWV0Mi54bWxQSwECLQAUAAYACAAAACEAwsErp3oBAACiAgAAGAAAAAAAAAAAAAAAAAAREwAAeGwv
d29ya3NoZWV0cy9zaGVldDMueG1sUEsBAi0AFAAGAAgAAAAhAHQvsEDKCQAABSUAABgAAAAAAAAA
AAAAAAAAwRQAAHhsL3dvcmtzaGVldHMvc2hlZXQxLnhtbFBLAQItABQABgAIAAAAIQBmnSOEJgEA
AHACAAAUAAAAAAAAAAAAAAAAAMEeAAB4bC9zaGFyZWRTdHJpbmdzLnhtbFBLAQItABQABgAIAAAA
IQCpxHlInAYAAF8zAAANAAAAAAAAAAAAAAAAABkgAAB4bC9zdHlsZXMueG1sUEsBAi0AFAAGAAgA
AAAhAIzcIoaeAQAAWAMAABAAAAAAAAAAAAAAAAAA4CYAAGRvY1Byb3BzL2FwcC54bWxQSwECLQAU
AAYACAAAACEAGDpabDwBAABZAgAAEQAAAAAAAAAAAAAAAAC0KQAAZG9jUHJvcHMvY29yZS54bWxQ
SwUGAAAAAAwADAAMAwAAJywAAAAA

--_003_C10D3FB0CD45994C8A51FEC1227CE22F37666D5EA5shsmsx502ccrc_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--_003_C10D3FB0CD45994C8A51FEC1227CE22F37666D5EA5shsmsx502ccrc_--


From xen-devel-bounces@lists.xensource.com Sun Dec 11 17:23:32 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 11 Dec 2011 17:23:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZn6q-0007BW-Jv; Sun, 11 Dec 2011 17:22:44 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <svenvan.van@gmail.com>) id 1RZn6p-0007BR-HY
	for xen-devel@lists.xensource.com; Sun, 11 Dec 2011 17:22:43 +0000
X-Env-Sender: svenvan.van@gmail.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1323624065!56828456!1
X-Originating-IP: [74.125.82.41]
X-SpamReason: No, hits=1.4 required=7.0 tests=BODY_RANDOM_LONG,
	HTML_40_50, HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,
	spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15549 invoked from network); 11 Dec 2011 17:21:05 -0000
Received: from mail-ww0-f41.google.com (HELO mail-ww0-f41.google.com)
	(74.125.82.41)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Dec 2011 17:21:05 -0000
Received: by wgbdt12 with SMTP id dt12so7773868wgb.0
	for <xen-devel@lists.xensource.com>;
	Sun, 11 Dec 2011 09:21:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:content-type; bh=BdwCfTq/poqi62kklgy+xiRmIiVIKL18C+a77t5nMo8=;
	b=aMiw0VT9bTM2Zm6T+kvcqFm9fsqEEE0p1pOH3iYxXwlbURIevGTx/ct3pPHongs0w4
	IAwH3mP4tq+DFgwIwULifIuKtWAwVQbaD3MhcV4Ab21j0BVxs6pVkPi3YFVfcGQ3g9ng
	V4wzrEPEzoiJ8CnMtJ0hAwJfoHR4OCk+mlJjQ=
MIME-Version: 1.0
Received: by 10.180.4.102 with SMTP id j6mr19127736wij.38.1323624112831; Sun,
	11 Dec 2011 09:21:52 -0800 (PST)
Received: by 10.223.76.15 with HTTP; Sun, 11 Dec 2011 09:21:52 -0800 (PST)
In-Reply-To: <CAJmQyTik==F8PuR+j3SVRjxQQ_aVLjHeBZdboekD3iOVRR9Y0A@mail.gmail.com>
References: <CAJmQyTik==F8PuR+j3SVRjxQQ_aVLjHeBZdboekD3iOVRR9Y0A@mail.gmail.com>
Date: Sun, 11 Dec 2011 18:21:52 +0100
Message-ID: <CAJmQyThnnRjvuHBzB-2P43FvHOu8=C8dkD_0yYGLFew3HnoAXg@mail.gmail.com>
From: svenvan svenvan <svenvan.van@gmail.com>
To: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] xen 4.0.1/w 2.6.32 swapper: page allocation failure
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3981121215690052007=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============3981121215690052007==
Content-Type: multipart/alternative; boundary=f46d041554780fbba604b3d441f3

--f46d041554780fbba604b3d441f3
Content-Type: text/plain; charset=ISO-8859-1

2011/12/5 svenvan svenvan <svenvan.van@gmail.com>

> hi
> xen 4.0.1 w/2.6.32.41
>
> Last week dom0 experienced an hard crash and box need to be restarted
> manually (despite kernel.panic=20).
> Serial console was not setup, only netconsole.  No relevant entries
> through netconsole, but analyzing logs I see some crashes twenty minutes
> before fatal hang.
>
>
Browsing archive I found a reply from  Konrad Rzeszutek about something
similar:
http://old-list-archives.xen.org/archives/html/xen-devel/2011-09/msg00600.html

Someone can confirm if it's the same issue or not?  Konrad maybe?
Thanks

--f46d041554780fbba604b3d441f3
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote">2011/12/5 svenvan svenvan <span dir=3D"ltr">&lt;=
<a href=3D"mailto:svenvan.van@gmail.com">svenvan.van@gmail.com</a>&gt;</spa=
n><br><blockquote class=3D"gmail_quote" style=3D"margin:0pt 0pt 0pt 0.8ex;b=
order-left:1px solid rgb(204,204,204);padding-left:1ex">
hi<br>xen 4.0.1 w/<a href=3D"http://2.6.32.41" target=3D"_blank">2.6.32.41<=
/a><br><br>Last week dom0 experienced an hard crash and box need to be rest=
arted manually (despite kernel.panic=3D20).<br>Serial console was not setup=
, only netconsole.=A0 No relevant entries through netconsole, but analyzing=
 logs I see some crashes twenty minutes before fatal hang.<br>
<br></blockquote><div><br>Browsing archive I found a reply from=A0 Konrad R=
zeszutek about something similar:<br><a href=3D"http://old-list-archives.xe=
n.org/archives/html/xen-devel/2011-09/msg00600.html">http://old-list-archiv=
es.xen.org/archives/html/xen-devel/2011-09/msg00600.html</a><br>
<br>Someone can confirm if it&#39;s the same issue or not?=A0 Konrad maybe?=
<br>Thanks<br></div></div>

--f46d041554780fbba604b3d441f3--


--===============3981121215690052007==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============3981121215690052007==--


From xen-devel-bounces@lists.xensource.com Sun Dec 11 17:23:32 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 11 Dec 2011 17:23:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZn6q-0007BW-Jv; Sun, 11 Dec 2011 17:22:44 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <svenvan.van@gmail.com>) id 1RZn6p-0007BR-HY
	for xen-devel@lists.xensource.com; Sun, 11 Dec 2011 17:22:43 +0000
X-Env-Sender: svenvan.van@gmail.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1323624065!56828456!1
X-Originating-IP: [74.125.82.41]
X-SpamReason: No, hits=1.4 required=7.0 tests=BODY_RANDOM_LONG,
	HTML_40_50, HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,
	spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15549 invoked from network); 11 Dec 2011 17:21:05 -0000
Received: from mail-ww0-f41.google.com (HELO mail-ww0-f41.google.com)
	(74.125.82.41)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Dec 2011 17:21:05 -0000
Received: by wgbdt12 with SMTP id dt12so7773868wgb.0
	for <xen-devel@lists.xensource.com>;
	Sun, 11 Dec 2011 09:21:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:content-type; bh=BdwCfTq/poqi62kklgy+xiRmIiVIKL18C+a77t5nMo8=;
	b=aMiw0VT9bTM2Zm6T+kvcqFm9fsqEEE0p1pOH3iYxXwlbURIevGTx/ct3pPHongs0w4
	IAwH3mP4tq+DFgwIwULifIuKtWAwVQbaD3MhcV4Ab21j0BVxs6pVkPi3YFVfcGQ3g9ng
	V4wzrEPEzoiJ8CnMtJ0hAwJfoHR4OCk+mlJjQ=
MIME-Version: 1.0
Received: by 10.180.4.102 with SMTP id j6mr19127736wij.38.1323624112831; Sun,
	11 Dec 2011 09:21:52 -0800 (PST)
Received: by 10.223.76.15 with HTTP; Sun, 11 Dec 2011 09:21:52 -0800 (PST)
In-Reply-To: <CAJmQyTik==F8PuR+j3SVRjxQQ_aVLjHeBZdboekD3iOVRR9Y0A@mail.gmail.com>
References: <CAJmQyTik==F8PuR+j3SVRjxQQ_aVLjHeBZdboekD3iOVRR9Y0A@mail.gmail.com>
Date: Sun, 11 Dec 2011 18:21:52 +0100
Message-ID: <CAJmQyThnnRjvuHBzB-2P43FvHOu8=C8dkD_0yYGLFew3HnoAXg@mail.gmail.com>
From: svenvan svenvan <svenvan.van@gmail.com>
To: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] xen 4.0.1/w 2.6.32 swapper: page allocation failure
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3981121215690052007=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============3981121215690052007==
Content-Type: multipart/alternative; boundary=f46d041554780fbba604b3d441f3

--f46d041554780fbba604b3d441f3
Content-Type: text/plain; charset=ISO-8859-1

2011/12/5 svenvan svenvan <svenvan.van@gmail.com>

> hi
> xen 4.0.1 w/2.6.32.41
>
> Last week dom0 experienced an hard crash and box need to be restarted
> manually (despite kernel.panic=20).
> Serial console was not setup, only netconsole.  No relevant entries
> through netconsole, but analyzing logs I see some crashes twenty minutes
> before fatal hang.
>
>
Browsing archive I found a reply from  Konrad Rzeszutek about something
similar:
http://old-list-archives.xen.org/archives/html/xen-devel/2011-09/msg00600.html

Someone can confirm if it's the same issue or not?  Konrad maybe?
Thanks

--f46d041554780fbba604b3d441f3
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote">2011/12/5 svenvan svenvan <span dir=3D"ltr">&lt;=
<a href=3D"mailto:svenvan.van@gmail.com">svenvan.van@gmail.com</a>&gt;</spa=
n><br><blockquote class=3D"gmail_quote" style=3D"margin:0pt 0pt 0pt 0.8ex;b=
order-left:1px solid rgb(204,204,204);padding-left:1ex">
hi<br>xen 4.0.1 w/<a href=3D"http://2.6.32.41" target=3D"_blank">2.6.32.41<=
/a><br><br>Last week dom0 experienced an hard crash and box need to be rest=
arted manually (despite kernel.panic=3D20).<br>Serial console was not setup=
, only netconsole.=A0 No relevant entries through netconsole, but analyzing=
 logs I see some crashes twenty minutes before fatal hang.<br>
<br></blockquote><div><br>Browsing archive I found a reply from=A0 Konrad R=
zeszutek about something similar:<br><a href=3D"http://old-list-archives.xe=
n.org/archives/html/xen-devel/2011-09/msg00600.html">http://old-list-archiv=
es.xen.org/archives/html/xen-devel/2011-09/msg00600.html</a><br>
<br>Someone can confirm if it&#39;s the same issue or not?=A0 Konrad maybe?=
<br>Thanks<br></div></div>

--f46d041554780fbba604b3d441f3--


--===============3981121215690052007==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============3981121215690052007==--


From xen-devel-bounces@lists.xensource.com Sun Dec 11 18:19:07 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 11 Dec 2011 18:19:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZnyl-0007UY-06; Sun, 11 Dec 2011 18:18:27 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RZnyj-0007UT-A3
	for xen-devel@lists.xensource.com; Sun, 11 Dec 2011 18:18:25 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1323627451!7582148!1
X-Originating-IP: [209.85.210.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15836 invoked from network); 11 Dec 2011 18:17:32 -0000
Received: from mail-pz0-f43.google.com (HELO mail-pz0-f43.google.com)
	(209.85.210.43)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Dec 2011 18:17:32 -0000
Received: by daec6 with SMTP id c6so6224151dae.30
	for <xen-devel@lists.xensource.com>;
	Sun, 11 Dec 2011 10:17:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=dsOkTvS1uuuSgelCiHkOVUEsQd91F+OL2SMMxOzRN3s=;
	b=Mhe0jLp2ypzkORCdBnuXPGA1tVGZF1pN7Ec3bGMB9tPHlpsWAhg8Edzr16ko9p+FZc
	/wUSNFpq9nGWrD6VNVnowbLj8UP01RJ8qDan648VUMw3kOkGxIW8/PwnhbfDWWOt+yYD
	uzP/uq7E8bCbX6DCogU6DCqq4GlBhbz7A3ZHg=
MIME-Version: 1.0
Received: by 10.68.73.103 with SMTP id k7mr25961959pbv.132.1323627008718; Sun,
	11 Dec 2011 10:10:08 -0800 (PST)
Received: by 10.142.47.17 with HTTP; Sun, 11 Dec 2011 10:10:08 -0800 (PST)
In-Reply-To: <3b7ac401f144206c3044.1323448644@cosworth.uk.xensource.com>
References: <patchbomb.1323448640@cosworth.uk.xensource.com>
	<3b7ac401f144206c3044.1323448644@cosworth.uk.xensource.com>
Date: Sun, 11 Dec 2011 19:10:08 +0100
X-Google-Sender-Auth: IqUO8CserzjTtTww-BONDEA_-yw
Message-ID: <CAPLaKK5dcMWKffM9BDJvhPYieP3gMCHKDNOwv0iaFr4M5LoHCA@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Campbell <ian.campbell@citrix.com>
Cc: Olaf Hering <olaf@aepfle.de>, xen-devel@lists.xensource.com,
	konrad.wilk@oracle.com, Vincent Hanquez <Vincent.Hanquez@eu.citrix.com>,
	Jonathan Ludlam <Jonathan.Ludlam@eu.citrix.com>, ian.jackson@citrix.com
Subject: Re: [Xen-devel] [PATCH 4 of 4] Linux/xencommons: Use oxenstored by
 default when available
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

MjAxMS8xMi85IElhbiBDYW1wYmVsbCA8aWFuLmNhbXBiZWxsQGNpdHJpeC5jb20+Ogo+ICMgSEcg
Y2hhbmdlc2V0IHBhdGNoCj4gIyBVc2VyIElhbiBDYW1wYmVsbCA8aWFuLmNhbXBiZWxsQGNpdHJp
eC5jb20+Cj4gIyBEYXRlIDEzMjM0NDg2MzYgMAo+ICMgTm9kZSBJRCAzYjdhYzQwMWYxNDQyMDZj
MzA0NDBmYmI0MWM3NGIxM2ZhMjBiOGNiCj4gIyBQYXJlbnQgwqA3NGY5NGUxNWJmZTFkYWQ0MTJk
MDM0MmFlYWJkYmQ4OTU2NTdmNTRmCj4gTGludXgveGVuY29tbW9uczogVXNlIG94ZW5zdG9yZWQg
YnkgZGVmYXVsdCB3aGVuIGF2YWlsYWJsZQo+Cj4gb3hlbnN0b3JlZCBpcyBhbiBvY2FtbCBpbXBs
ZW1lbnRhdGlvbiBvZiB0aGUgeGVuc3RvcmUgZGFlbW9uLiBJdCBpcyBmYXN0ZXIsCj4gbW9yZSBz
Y2FsYWJsZSBhbmQgbW9yZSByZWxpYWJsZSB0aGFuIHRoZSBDIHhlbnN0b3JlZC4KClRoaXMgbWVh
bnMgdGhhdCBDIHhlbnN0b3JlIGlzIGdvaW5nIHRoZSB3YXkgb2YgdGhlIERvZG8/IE9yIGFyZSB3
ZQpnb2luZyB0byBtYWludGFpbiBib3RoIGltcGxlbWVudGF0aW9ucyAob2NhbG0gYW5kIEMpPwoK
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVs
IG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuc291cmNlLmNvbQpodHRwOi8vbGlzdHMu
eGVuc291cmNlLmNvbS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Sun Dec 11 18:19:07 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 11 Dec 2011 18:19:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZnyl-0007UY-06; Sun, 11 Dec 2011 18:18:27 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RZnyj-0007UT-A3
	for xen-devel@lists.xensource.com; Sun, 11 Dec 2011 18:18:25 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1323627451!7582148!1
X-Originating-IP: [209.85.210.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15836 invoked from network); 11 Dec 2011 18:17:32 -0000
Received: from mail-pz0-f43.google.com (HELO mail-pz0-f43.google.com)
	(209.85.210.43)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Dec 2011 18:17:32 -0000
Received: by daec6 with SMTP id c6so6224151dae.30
	for <xen-devel@lists.xensource.com>;
	Sun, 11 Dec 2011 10:17:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=dsOkTvS1uuuSgelCiHkOVUEsQd91F+OL2SMMxOzRN3s=;
	b=Mhe0jLp2ypzkORCdBnuXPGA1tVGZF1pN7Ec3bGMB9tPHlpsWAhg8Edzr16ko9p+FZc
	/wUSNFpq9nGWrD6VNVnowbLj8UP01RJ8qDan648VUMw3kOkGxIW8/PwnhbfDWWOt+yYD
	uzP/uq7E8bCbX6DCogU6DCqq4GlBhbz7A3ZHg=
MIME-Version: 1.0
Received: by 10.68.73.103 with SMTP id k7mr25961959pbv.132.1323627008718; Sun,
	11 Dec 2011 10:10:08 -0800 (PST)
Received: by 10.142.47.17 with HTTP; Sun, 11 Dec 2011 10:10:08 -0800 (PST)
In-Reply-To: <3b7ac401f144206c3044.1323448644@cosworth.uk.xensource.com>
References: <patchbomb.1323448640@cosworth.uk.xensource.com>
	<3b7ac401f144206c3044.1323448644@cosworth.uk.xensource.com>
Date: Sun, 11 Dec 2011 19:10:08 +0100
X-Google-Sender-Auth: IqUO8CserzjTtTww-BONDEA_-yw
Message-ID: <CAPLaKK5dcMWKffM9BDJvhPYieP3gMCHKDNOwv0iaFr4M5LoHCA@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Campbell <ian.campbell@citrix.com>
Cc: Olaf Hering <olaf@aepfle.de>, xen-devel@lists.xensource.com,
	konrad.wilk@oracle.com, Vincent Hanquez <Vincent.Hanquez@eu.citrix.com>,
	Jonathan Ludlam <Jonathan.Ludlam@eu.citrix.com>, ian.jackson@citrix.com
Subject: Re: [Xen-devel] [PATCH 4 of 4] Linux/xencommons: Use oxenstored by
 default when available
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

MjAxMS8xMi85IElhbiBDYW1wYmVsbCA8aWFuLmNhbXBiZWxsQGNpdHJpeC5jb20+Ogo+ICMgSEcg
Y2hhbmdlc2V0IHBhdGNoCj4gIyBVc2VyIElhbiBDYW1wYmVsbCA8aWFuLmNhbXBiZWxsQGNpdHJp
eC5jb20+Cj4gIyBEYXRlIDEzMjM0NDg2MzYgMAo+ICMgTm9kZSBJRCAzYjdhYzQwMWYxNDQyMDZj
MzA0NDBmYmI0MWM3NGIxM2ZhMjBiOGNiCj4gIyBQYXJlbnQgwqA3NGY5NGUxNWJmZTFkYWQ0MTJk
MDM0MmFlYWJkYmQ4OTU2NTdmNTRmCj4gTGludXgveGVuY29tbW9uczogVXNlIG94ZW5zdG9yZWQg
YnkgZGVmYXVsdCB3aGVuIGF2YWlsYWJsZQo+Cj4gb3hlbnN0b3JlZCBpcyBhbiBvY2FtbCBpbXBs
ZW1lbnRhdGlvbiBvZiB0aGUgeGVuc3RvcmUgZGFlbW9uLiBJdCBpcyBmYXN0ZXIsCj4gbW9yZSBz
Y2FsYWJsZSBhbmQgbW9yZSByZWxpYWJsZSB0aGFuIHRoZSBDIHhlbnN0b3JlZC4KClRoaXMgbWVh
bnMgdGhhdCBDIHhlbnN0b3JlIGlzIGdvaW5nIHRoZSB3YXkgb2YgdGhlIERvZG8/IE9yIGFyZSB3
ZQpnb2luZyB0byBtYWludGFpbiBib3RoIGltcGxlbWVudGF0aW9ucyAob2NhbG0gYW5kIEMpPwoK
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVs
IG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuc291cmNlLmNvbQpodHRwOi8vbGlzdHMu
eGVuc291cmNlLmNvbS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Sun Dec 11 19:00:20 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 11 Dec 2011 19:00:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZocW-0007iY-B1; Sun, 11 Dec 2011 18:59:32 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <thunderbird2k@gmail.com>) id 1RZocT-0007iT-U7
	for xen-devel@lists.xensource.com; Sun, 11 Dec 2011 18:59:30 +0000
X-Env-Sender: thunderbird2k@gmail.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1323629873!56832853!1
X-Originating-IP: [209.85.213.171]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32329 invoked from network); 11 Dec 2011 18:57:54 -0000
Received: from mail-yx0-f171.google.com (HELO mail-yx0-f171.google.com)
	(209.85.213.171)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Dec 2011 18:57:54 -0000
Received: by yenr9 with SMTP id r9so80937451yen.30
	for <xen-devel@lists.xensource.com>;
	Sun, 11 Dec 2011 10:58:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	bh=gqDI2FfwbJj0ZdzmPS1mqVfJw/BYeswN1A3Ycf2K1ME=;
	b=G4sR1XqwOKLptsi7CFP3gw/SdQmMFX/UdMZZHJa58Qgii8biRHoYol3VlMxIweq2Qj
	3khUD9ThdemT5ar6sMERpv482HiSCefByDnvAhVGovyJwkxbzw0QIcXPtS/d5Seo7DyM
	eygOT9nBPw2Csap8tyljrVDt/kqcnXfxoNWjo=
MIME-Version: 1.0
Received: by 10.236.181.164 with SMTP id l24mr22694610yhm.22.1323629920844;
	Sun, 11 Dec 2011 10:58:40 -0800 (PST)
Received: by 10.100.48.10 with HTTP; Sun, 11 Dec 2011 10:58:40 -0800 (PST)
In-Reply-To: <20111211125247.GQ12984@reaktio.net>
References: <CAEc3jaAa7y8C2NNBn1=L3AhS0uuYFP6ze8o1cZ9yG2VYHx6qMA@mail.gmail.com>
	<4ED5215D.1010403@hfp.de>
	<20111129230212.GA23958@andromeda.dapyr.net>
	<CAEc3jaAO0JhtOt6phQHwtE_A+NF7uGHGZ8uJv3BirEYybfVceg@mail.gmail.com>
	<CAEc3jaACffpr9D1Hq_012vHAGhPLEfvsZjh7YyJ=Q-3FdtHS0Q@mail.gmail.com>
	<CAPbh3rtOQ1HTPReqYcpE3vzk+-na0MTLLHZD15=Fg4yxB+ypaA@mail.gmail.com>
	<CAEc3jaBdQKmVJToNZRf+25GtJXqGc274ieHf_yHKRJ+YOKWdgA@mail.gmail.com>
	<20111208234624.GD32474@konrad-lan>
	<CAEc3jaC9=HiMoxSYZmXKRzoFcMYRaT9jrX3m1ZQO+M8CrH35Fg@mail.gmail.com>
	<CAEc3jaBBYBME0G3Ku_sTvzQz+oKQnpBPffA+bRUKxxRPABAeww@mail.gmail.com>
	<20111211125247.GQ12984@reaktio.net>
Date: Sun, 11 Dec 2011 10:58:40 -0800
Message-ID: <CAEc3jaCJ6wP27Ffm0wpOggWMgqcSNJiGxhtkszq6jgRD1nrZLg@mail.gmail.com>
From: Roderick Colenbrander <thunderbird2k@gmail.com>
To: =?ISO-8859-1?Q?Pasi_K=E4rkk=E4inen?= <pasik@iki.fi>
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>, xen-devel@lists.xensource.com,
	Andreas Kinzler <ml-xen-devel@hfp.de>
Subject: Re: [Xen-devel] Questions about GPLPV stability tests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Sun, Dec 11, 2011 at 4:52 AM, Pasi K=E4rkk=E4inen <pasik@iki.fi> wrote:
> On Fri, Dec 09, 2011 at 02:02:31PM -0800, Roderick Colenbrander wrote:
>> One interesting observation. This morning I had another of my stress
>> machines with the problem. I never had it on this problem before and
>> it didn't have any of the new logging / software updates yet.
>>
>> The system was in the same state as the other machine which I reported
>> about before. I tried SysRq stuff and other things. While I was about
>> to reboot the system, a login prompt appeared again on the VGA. I
>> don't know whether any of the stuff I did triggered it or not. Anyway
>> it means Linux is not really dead. I tried logging, but I don't even
>> see characters appearing. The system feels to be very, very, very
>> slow.
>>
>
> Hmm.. I wonder if this is the same issue I'm sometimes seeing on my lapto=
p..
> suddenly it starts becoming slower, and after a while it's *very* slow..
> not dead, but unusably slow..
>
> I haven't had time to (try to) debug it..
>
> -- Pasi
>

I'm seeing slowness issues on our systems as well. As in some code
starts running really, really slowly. Local TCP 'heartbeat' like
mechanism from Dom0 to a DomU timing out. Code which should execute
quickly becoming orders of magnitude slower for no obvious reason.
Typically we see evidence of this in logging.

I felt there was a connection between this slowness and the
'unresponsive Dom0' but I haven't been able to confirm this. Normally
we see weird things in our logs, but on the unresponsive systems I
didn't see anything strange in the logs yet. Most likely the logs
weren't synced to disk yet.

After more investigation it seems that in my case all issues, seem to
happen after the DomU is up and we somehow 'start' using it. During
startup of our own software, both DomU and Dom0 would at least see a
spike in cpu/disk activity before things settle down a bit. My feeling
is (based on some logs) that this is when Dom0 sometimes becomes
unresponsive.

I'm still running tests on a number of machines, but it takes ages to
get results.

Roderick

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Dec 11 19:00:20 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 11 Dec 2011 19:00:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZocW-0007iY-B1; Sun, 11 Dec 2011 18:59:32 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <thunderbird2k@gmail.com>) id 1RZocT-0007iT-U7
	for xen-devel@lists.xensource.com; Sun, 11 Dec 2011 18:59:30 +0000
X-Env-Sender: thunderbird2k@gmail.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1323629873!56832853!1
X-Originating-IP: [209.85.213.171]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32329 invoked from network); 11 Dec 2011 18:57:54 -0000
Received: from mail-yx0-f171.google.com (HELO mail-yx0-f171.google.com)
	(209.85.213.171)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Dec 2011 18:57:54 -0000
Received: by yenr9 with SMTP id r9so80937451yen.30
	for <xen-devel@lists.xensource.com>;
	Sun, 11 Dec 2011 10:58:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	bh=gqDI2FfwbJj0ZdzmPS1mqVfJw/BYeswN1A3Ycf2K1ME=;
	b=G4sR1XqwOKLptsi7CFP3gw/SdQmMFX/UdMZZHJa58Qgii8biRHoYol3VlMxIweq2Qj
	3khUD9ThdemT5ar6sMERpv482HiSCefByDnvAhVGovyJwkxbzw0QIcXPtS/d5Seo7DyM
	eygOT9nBPw2Csap8tyljrVDt/kqcnXfxoNWjo=
MIME-Version: 1.0
Received: by 10.236.181.164 with SMTP id l24mr22694610yhm.22.1323629920844;
	Sun, 11 Dec 2011 10:58:40 -0800 (PST)
Received: by 10.100.48.10 with HTTP; Sun, 11 Dec 2011 10:58:40 -0800 (PST)
In-Reply-To: <20111211125247.GQ12984@reaktio.net>
References: <CAEc3jaAa7y8C2NNBn1=L3AhS0uuYFP6ze8o1cZ9yG2VYHx6qMA@mail.gmail.com>
	<4ED5215D.1010403@hfp.de>
	<20111129230212.GA23958@andromeda.dapyr.net>
	<CAEc3jaAO0JhtOt6phQHwtE_A+NF7uGHGZ8uJv3BirEYybfVceg@mail.gmail.com>
	<CAEc3jaACffpr9D1Hq_012vHAGhPLEfvsZjh7YyJ=Q-3FdtHS0Q@mail.gmail.com>
	<CAPbh3rtOQ1HTPReqYcpE3vzk+-na0MTLLHZD15=Fg4yxB+ypaA@mail.gmail.com>
	<CAEc3jaBdQKmVJToNZRf+25GtJXqGc274ieHf_yHKRJ+YOKWdgA@mail.gmail.com>
	<20111208234624.GD32474@konrad-lan>
	<CAEc3jaC9=HiMoxSYZmXKRzoFcMYRaT9jrX3m1ZQO+M8CrH35Fg@mail.gmail.com>
	<CAEc3jaBBYBME0G3Ku_sTvzQz+oKQnpBPffA+bRUKxxRPABAeww@mail.gmail.com>
	<20111211125247.GQ12984@reaktio.net>
Date: Sun, 11 Dec 2011 10:58:40 -0800
Message-ID: <CAEc3jaCJ6wP27Ffm0wpOggWMgqcSNJiGxhtkszq6jgRD1nrZLg@mail.gmail.com>
From: Roderick Colenbrander <thunderbird2k@gmail.com>
To: =?ISO-8859-1?Q?Pasi_K=E4rkk=E4inen?= <pasik@iki.fi>
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>, xen-devel@lists.xensource.com,
	Andreas Kinzler <ml-xen-devel@hfp.de>
Subject: Re: [Xen-devel] Questions about GPLPV stability tests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Sun, Dec 11, 2011 at 4:52 AM, Pasi K=E4rkk=E4inen <pasik@iki.fi> wrote:
> On Fri, Dec 09, 2011 at 02:02:31PM -0800, Roderick Colenbrander wrote:
>> One interesting observation. This morning I had another of my stress
>> machines with the problem. I never had it on this problem before and
>> it didn't have any of the new logging / software updates yet.
>>
>> The system was in the same state as the other machine which I reported
>> about before. I tried SysRq stuff and other things. While I was about
>> to reboot the system, a login prompt appeared again on the VGA. I
>> don't know whether any of the stuff I did triggered it or not. Anyway
>> it means Linux is not really dead. I tried logging, but I don't even
>> see characters appearing. The system feels to be very, very, very
>> slow.
>>
>
> Hmm.. I wonder if this is the same issue I'm sometimes seeing on my lapto=
p..
> suddenly it starts becoming slower, and after a while it's *very* slow..
> not dead, but unusably slow..
>
> I haven't had time to (try to) debug it..
>
> -- Pasi
>

I'm seeing slowness issues on our systems as well. As in some code
starts running really, really slowly. Local TCP 'heartbeat' like
mechanism from Dom0 to a DomU timing out. Code which should execute
quickly becoming orders of magnitude slower for no obvious reason.
Typically we see evidence of this in logging.

I felt there was a connection between this slowness and the
'unresponsive Dom0' but I haven't been able to confirm this. Normally
we see weird things in our logs, but on the unresponsive systems I
didn't see anything strange in the logs yet. Most likely the logs
weren't synced to disk yet.

After more investigation it seems that in my case all issues, seem to
happen after the DomU is up and we somehow 'start' using it. During
startup of our own software, both DomU and Dom0 would at least see a
spike in cpu/disk activity before things settle down a bit. My feeling
is (based on some logs) that this is when Dom0 sometimes becomes
unresponsive.

I'm still running tests on a number of machines, but it takes ages to
get results.

Roderick

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Dec 11 22:29:45 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 11 Dec 2011 22:29:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZrtK-00019j-L7; Sun, 11 Dec 2011 22:29:06 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <oor@cs.cmu.edu>) id 1RZrtJ-00019X-OR
	for xen-devel@lists.xensource.com; Sun, 11 Dec 2011 22:29:05 +0000
X-Env-Sender: oor@cs.cmu.edu
X-Msg-Ref: server-2.tower-27.messagelabs.com!1323642449!56842207!1
X-Originating-IP: [128.2.217.197]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11966 invoked from network); 11 Dec 2011 22:27:30 -0000
Received: from smtp02.srv.cs.cmu.edu (HELO smtp02.srv.cs.cmu.edu)
	(128.2.217.197)
	by server-2.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Dec 2011 22:27:30 -0000
Received: from webmail.cs.cmu.edu (TOMENTOSA.SRV.CS.CMU.EDU [128.2.172.30])
	by smtp02.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id pBBMSGot003549
	for <xen-devel@lists.xensource.com>;
	Sun, 11 Dec 2011 17:28:16 -0500 (EST)
Received: from 71.199.121.110
	(SquirrelMail authenticated user oor/mail@CS.CMU.EDU)
	by webmail.cs.cmu.edu with HTTP;
	Sun, 11 Dec 2011 17:28:16 -0500 (EST)
Message-ID: <63429.71.199.121.110.1323642496.squirrel@webmail.cs.cmu.edu>
Date: Sun, 11 Dec 2011 17:28:16 -0500 (EST)
From: "Olatunji Ruwase" <oor@cs.cmu.edu>
To: xen-devel@lists.xensource.com
User-Agent: SquirrelMail/1.5.1
MIME-Version: 1.0
X-Scanned-By: mimedefang-cmuscs on 128.2.217.197
Subject: [Xen-devel] Running domU in ring 2
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hello,
 I am curious as to whether it is possible/practical to run a PV driver
domain in the x86 protection ring 2 as opposed to ring 1. I m working on
using hardware logging to capture instruction-grained traces of
kernel-mode device drivers. My implementation is based on running Xen 3.3
on Simics simulated hardware. Distinguishing the kernel-mode executions
of the dom0 and domU (driver domain) in the simulation framework will be
easier if the kernels ran in different rings, dom0 in ring 1 and domU in
ring 2.

Thanks,

tunji


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Dec 11 22:29:45 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 11 Dec 2011 22:29:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZrtK-00019j-L7; Sun, 11 Dec 2011 22:29:06 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <oor@cs.cmu.edu>) id 1RZrtJ-00019X-OR
	for xen-devel@lists.xensource.com; Sun, 11 Dec 2011 22:29:05 +0000
X-Env-Sender: oor@cs.cmu.edu
X-Msg-Ref: server-2.tower-27.messagelabs.com!1323642449!56842207!1
X-Originating-IP: [128.2.217.197]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11966 invoked from network); 11 Dec 2011 22:27:30 -0000
Received: from smtp02.srv.cs.cmu.edu (HELO smtp02.srv.cs.cmu.edu)
	(128.2.217.197)
	by server-2.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Dec 2011 22:27:30 -0000
Received: from webmail.cs.cmu.edu (TOMENTOSA.SRV.CS.CMU.EDU [128.2.172.30])
	by smtp02.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id pBBMSGot003549
	for <xen-devel@lists.xensource.com>;
	Sun, 11 Dec 2011 17:28:16 -0500 (EST)
Received: from 71.199.121.110
	(SquirrelMail authenticated user oor/mail@CS.CMU.EDU)
	by webmail.cs.cmu.edu with HTTP;
	Sun, 11 Dec 2011 17:28:16 -0500 (EST)
Message-ID: <63429.71.199.121.110.1323642496.squirrel@webmail.cs.cmu.edu>
Date: Sun, 11 Dec 2011 17:28:16 -0500 (EST)
From: "Olatunji Ruwase" <oor@cs.cmu.edu>
To: xen-devel@lists.xensource.com
User-Agent: SquirrelMail/1.5.1
MIME-Version: 1.0
X-Scanned-By: mimedefang-cmuscs on 128.2.217.197
Subject: [Xen-devel] Running domU in ring 2
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hello,
 I am curious as to whether it is possible/practical to run a PV driver
domain in the x86 protection ring 2 as opposed to ring 1. I m working on
using hardware logging to capture instruction-grained traces of
kernel-mode device drivers. My implementation is based on running Xen 3.3
on Simics simulated hardware. Distinguishing the kernel-mode executions
of the dom0 and domU (driver domain) in the simulation framework will be
easier if the kernels ran in different rings, dom0 in ring 1 and domU in
ring 2.

Thanks,

tunji


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Dec 11 23:45:08 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 11 Dec 2011 23:45:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZt4C-0001lr-Mj; Sun, 11 Dec 2011 23:44:24 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <george.shuklin@gmail.com>) id 1RZt4B-0001ll-1M
	for xen-devel@lists.xensource.com; Sun, 11 Dec 2011 23:44:23 +0000
X-Env-Sender: george.shuklin@gmail.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1323647009!5112578!1
X-Originating-IP: [209.85.214.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1693 invoked from network); 11 Dec 2011 23:43:30 -0000
Received: from mail-bw0-f43.google.com (HELO mail-bw0-f43.google.com)
	(209.85.214.43)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Dec 2011 23:43:30 -0000
Received: by bkbzs2 with SMTP id zs2so16168319bkb.30
	for <xen-devel@lists.xensource.com>;
	Sun, 11 Dec 2011 15:43:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=message-id:date:from:user-agent:mime-version:to:subject:references
	:in-reply-to:content-type:content-transfer-encoding;
	bh=voVPr+SaXp0i+9Ecv6fkMIOb2LvruaeSLigjQ93o31Q=;
	b=H2y1pgxyZUx0njpdG7zgPqGckuSZiodhty7lLPe1f8mjYEK8llag4shlxOmizcJclu
	3g5loLztsNBeeqjGA1LO66TW+oLIHS7NYg04UH8MpO/Wyp7bUZ8+gPCHPzEPNe7RR591
	cvYoE4cn0hIFEWz0I2WQgYLQHrCA6MMcW7c70=
Received: by 10.204.136.193 with SMTP id s1mr8845922bkt.111.1323647007636;
	Sun, 11 Dec 2011 15:43:27 -0800 (PST)
Received: from [192.168.0.220] (desunote.ru. [95.161.2.76])
	by mx.google.com with ESMTPS id il2sm27330515bkc.10.2011.12.11.15.43.25
	(version=SSLv3 cipher=OTHER); Sun, 11 Dec 2011 15:43:26 -0800 (PST)
Message-ID: <4EE5401C.9050702@gmail.com>
Date: Mon, 12 Dec 2011 03:43:24 +0400
From: George Shuklin <george.shuklin@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:9.0) Gecko/20111209 Thunderbird/9.0
MIME-Version: 1.0
To: xen-devel@lists.xensource.com
References: <63429.71.199.121.110.1323642496.squirrel@webmail.cs.cmu.edu>
In-Reply-To: <63429.71.199.121.110.1323642496.squirrel@webmail.cs.cmu.edu>
Subject: Re: [Xen-devel] Running domU in ring 2
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Where is your ring 2 in x86_64 architecture? They killed It!

On 12.12.2011 02:28, Olatunji Ruwase wrote:
> Hello,
>   I am curious as to whether it is possible/practical to run a PV driver
> domain in the x86 protection ring 2 as opposed to ring 1. I m working on
> using hardware logging to capture instruction-grained traces of
> kernel-mode device drivers. My implementation is based on running Xen 3.3
> on Simics simulated hardware. Distinguishing the kernel-mode executions
> of the dom0 and domU (driver domain) in the simulation framework will be
> easier if the kernels ran in different rings, dom0 in ring 1 and domU in
> ring 2.
>
> Thanks,
>
> tunji
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Dec 11 23:45:08 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 11 Dec 2011 23:45:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZt4C-0001lr-Mj; Sun, 11 Dec 2011 23:44:24 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <george.shuklin@gmail.com>) id 1RZt4B-0001ll-1M
	for xen-devel@lists.xensource.com; Sun, 11 Dec 2011 23:44:23 +0000
X-Env-Sender: george.shuklin@gmail.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1323647009!5112578!1
X-Originating-IP: [209.85.214.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1693 invoked from network); 11 Dec 2011 23:43:30 -0000
Received: from mail-bw0-f43.google.com (HELO mail-bw0-f43.google.com)
	(209.85.214.43)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Dec 2011 23:43:30 -0000
Received: by bkbzs2 with SMTP id zs2so16168319bkb.30
	for <xen-devel@lists.xensource.com>;
	Sun, 11 Dec 2011 15:43:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=message-id:date:from:user-agent:mime-version:to:subject:references
	:in-reply-to:content-type:content-transfer-encoding;
	bh=voVPr+SaXp0i+9Ecv6fkMIOb2LvruaeSLigjQ93o31Q=;
	b=H2y1pgxyZUx0njpdG7zgPqGckuSZiodhty7lLPe1f8mjYEK8llag4shlxOmizcJclu
	3g5loLztsNBeeqjGA1LO66TW+oLIHS7NYg04UH8MpO/Wyp7bUZ8+gPCHPzEPNe7RR591
	cvYoE4cn0hIFEWz0I2WQgYLQHrCA6MMcW7c70=
Received: by 10.204.136.193 with SMTP id s1mr8845922bkt.111.1323647007636;
	Sun, 11 Dec 2011 15:43:27 -0800 (PST)
Received: from [192.168.0.220] (desunote.ru. [95.161.2.76])
	by mx.google.com with ESMTPS id il2sm27330515bkc.10.2011.12.11.15.43.25
	(version=SSLv3 cipher=OTHER); Sun, 11 Dec 2011 15:43:26 -0800 (PST)
Message-ID: <4EE5401C.9050702@gmail.com>
Date: Mon, 12 Dec 2011 03:43:24 +0400
From: George Shuklin <george.shuklin@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:9.0) Gecko/20111209 Thunderbird/9.0
MIME-Version: 1.0
To: xen-devel@lists.xensource.com
References: <63429.71.199.121.110.1323642496.squirrel@webmail.cs.cmu.edu>
In-Reply-To: <63429.71.199.121.110.1323642496.squirrel@webmail.cs.cmu.edu>
Subject: Re: [Xen-devel] Running domU in ring 2
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Where is your ring 2 in x86_64 architecture? They killed It!

On 12.12.2011 02:28, Olatunji Ruwase wrote:
> Hello,
>   I am curious as to whether it is possible/practical to run a PV driver
> domain in the x86 protection ring 2 as opposed to ring 1. I m working on
> using hardware logging to capture instruction-grained traces of
> kernel-mode device drivers. My implementation is based on running Xen 3.3
> on Simics simulated hardware. Distinguishing the kernel-mode executions
> of the dom0 and domU (driver domain) in the simulation framework will be
> easier if the kernels ran in different rings, dom0 in ring 1 and domU in
> ring 2.
>
> Thanks,
>
> tunji
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 03:18:17 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 03:18:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZwOU-00088a-6a; Mon, 12 Dec 2011 03:17:34 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <annie.li@oracle.com>) id 1RZwOS-00088B-K5
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 03:17:32 +0000
X-Env-Sender: annie.li@oracle.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1323659798!7751800!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDMxNDIw\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21052 invoked from network); 12 Dec 2011 03:16:40 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-10.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Dec 2011 03:16:40 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pBC3GYat011008
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 12 Dec 2011 03:16:34 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pBC3GViM022611
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 12 Dec 2011 03:16:31 GMT
Received: from abhmt115.oracle.com (abhmt115.oracle.com [141.146.116.67])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pBC3GNVd000847; Sun, 11 Dec 2011 21:16:23 -0600
Received: from [10.182.39.81] (/10.182.39.81)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Sun, 11 Dec 2011 19:16:23 -0800
Message-ID: <4EE57204.4030509@oracle.com>
Date: Mon, 12 Dec 2011 11:16:20 +0800
From: ANNIE LI <annie.li@oracle.com>
Organization: Oracle Corporation
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.9.2.24) Gecko/20111103 Thunderbird/3.1.16
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1323430321-5465-1-git-send-email-annie.li@oracle.com>	
	<1323430372-5503-1-git-send-email-annie.li@oracle.com>
	<1323452339.20077.92.camel@zakaz.uk.xensource.com>
In-Reply-To: <1323452339.20077.92.camel@zakaz.uk.xensource.com>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090206.4EE57213.0077,ss=1,re=0.000,fgs=0
Cc: "jeremy@goop.org" <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	"kurt.hackel@oracle.com" <kurt.hackel@oracle.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Paul Durrant <Paul.Durrant@citrix.com>
Subject: Re: [Xen-devel] [PATCH V3 1/2] xen/granttable: Support sub-page
	grants
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


> Please can you name the arguments here and then refer to them by name in
> the comments instead of all this "First parameter", "second one" stuff.
>
> Similarly for the existing comments sorry I didn't notice this in
> previous review.
Please check following comments in gnttab_ops, I changed the "First 
parameter", "second one" into parameter name. However, it looks not very 
consistent with parameters format of function fn since only parameter 
type exists, not name.

struct gnttab_ops {
         /*
          * Mapping a list of frames for storing grant entries. Frames 
parameter
          * is used to store grant table address when grant table being 
setup,
          * nr_gframes is the number of frames to map grant table. Returning
          * GNTST_okay means success and negative value means failure.
          */
         int (*map_frames)(unsigned long *, unsigned int);
         /*
          * Release a list of frames which are mapped in map_frames for 
grant
          * entry status.
          */
         void (*unmap_frames)(void);
         /*
          * Introducing a valid entry into the grant table, granting the 
frame
          * of this grant entry to domain for accessing, or transfering, or
          * transitively accessing. Ref parameter is reference of this 
introduced
          * grant entry, domid is id of granted domain, frame is the 
page frame
          * to be granted, and flags is status of the grant entry to be 
updated.
          */
         void (*update_entry)(grant_ref_t, domid_t, unsigned long, 
unsigned);
         /*
          * Stop granting a grant entry to domain for accessing. Ref 
parameter is
          * reference of a grant entry whose grant access will be stopped,
          * readonly is not in use in this function. If the grant entry is
          * currently mapped for reading or writing, just return 
failure(==0)
          * directly and don't tear down the grant access. Otherwise, 
stop grant
          * access for this entry and return success(==1).
          */
         int (*end_foreign_access_ref)(grant_ref_t, int);
         /*
          * Stop granting a grant entry to domain for transfer. If 
tranfer has
          * not started, just reclaim the grant entry and return 
failure(==0).
          * Otherwise, wait for the transfer to complete and then return the
          * frame.
          */
         unsigned long (*end_foreign_transfer_ref)(grant_ref_t);
         /*
          * Query the status of a grant entry. Ref parameter is reference of
          * queried grant entry, return value is the status of queried 
entry.
          * Detailed status(writing/reading) can be gotten from the 
return value
          * by bit operations.
          */
         int (*query_foreign_access)(grant_ref_t);
         /*
          * Grant a domain to access a range of bytes within the page 
referred by
          * an available grant entry. Ref parameter is grant entry reference
          * number, domid is id of grantee domain, frame is frame address of
          * subpage grant, flags is grant type and flag information, 
page_off is
          * offset of the range of bytes, and length is length of bytes 
to be
          * accessed.
          */
         void (*update_subpage_entry)(grant_ref_t, domid_t, unsigned 
long, int,
                                      unsigned, unsigned);
         /*
          * Redirect an available grant entry on domain A to another grant
          * reference of domain B, then allow domain C to use grant 
reference
          * of domain B transitively. Ref parameter is an available 
grant entry
          * reference on domain A, domid is id of domain C which 
accesses grant
          * entry transitively, flags is grant type and flag information,
          * trans_domid is id of domain B whose grant entry is finally 
accessed
          * transitively, trans_gref is grant entry transitive reference of
          * domain B.
          */
         void (*update_trans_entry)(grant_ref_t, domid_t, int, domid_t,
                                    grant_ref_t);
Thanks
Annie
> Ian.
>
>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 03:18:17 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 03:18:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RZwOU-00088a-6a; Mon, 12 Dec 2011 03:17:34 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <annie.li@oracle.com>) id 1RZwOS-00088B-K5
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 03:17:32 +0000
X-Env-Sender: annie.li@oracle.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1323659798!7751800!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDMxNDIw\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21052 invoked from network); 12 Dec 2011 03:16:40 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-10.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Dec 2011 03:16:40 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pBC3GYat011008
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 12 Dec 2011 03:16:34 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pBC3GViM022611
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 12 Dec 2011 03:16:31 GMT
Received: from abhmt115.oracle.com (abhmt115.oracle.com [141.146.116.67])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pBC3GNVd000847; Sun, 11 Dec 2011 21:16:23 -0600
Received: from [10.182.39.81] (/10.182.39.81)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Sun, 11 Dec 2011 19:16:23 -0800
Message-ID: <4EE57204.4030509@oracle.com>
Date: Mon, 12 Dec 2011 11:16:20 +0800
From: ANNIE LI <annie.li@oracle.com>
Organization: Oracle Corporation
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.9.2.24) Gecko/20111103 Thunderbird/3.1.16
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1323430321-5465-1-git-send-email-annie.li@oracle.com>	
	<1323430372-5503-1-git-send-email-annie.li@oracle.com>
	<1323452339.20077.92.camel@zakaz.uk.xensource.com>
In-Reply-To: <1323452339.20077.92.camel@zakaz.uk.xensource.com>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090206.4EE57213.0077,ss=1,re=0.000,fgs=0
Cc: "jeremy@goop.org" <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	"kurt.hackel@oracle.com" <kurt.hackel@oracle.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Paul Durrant <Paul.Durrant@citrix.com>
Subject: Re: [Xen-devel] [PATCH V3 1/2] xen/granttable: Support sub-page
	grants
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


> Please can you name the arguments here and then refer to them by name in
> the comments instead of all this "First parameter", "second one" stuff.
>
> Similarly for the existing comments sorry I didn't notice this in
> previous review.
Please check following comments in gnttab_ops, I changed the "First 
parameter", "second one" into parameter name. However, it looks not very 
consistent with parameters format of function fn since only parameter 
type exists, not name.

struct gnttab_ops {
         /*
          * Mapping a list of frames for storing grant entries. Frames 
parameter
          * is used to store grant table address when grant table being 
setup,
          * nr_gframes is the number of frames to map grant table. Returning
          * GNTST_okay means success and negative value means failure.
          */
         int (*map_frames)(unsigned long *, unsigned int);
         /*
          * Release a list of frames which are mapped in map_frames for 
grant
          * entry status.
          */
         void (*unmap_frames)(void);
         /*
          * Introducing a valid entry into the grant table, granting the 
frame
          * of this grant entry to domain for accessing, or transfering, or
          * transitively accessing. Ref parameter is reference of this 
introduced
          * grant entry, domid is id of granted domain, frame is the 
page frame
          * to be granted, and flags is status of the grant entry to be 
updated.
          */
         void (*update_entry)(grant_ref_t, domid_t, unsigned long, 
unsigned);
         /*
          * Stop granting a grant entry to domain for accessing. Ref 
parameter is
          * reference of a grant entry whose grant access will be stopped,
          * readonly is not in use in this function. If the grant entry is
          * currently mapped for reading or writing, just return 
failure(==0)
          * directly and don't tear down the grant access. Otherwise, 
stop grant
          * access for this entry and return success(==1).
          */
         int (*end_foreign_access_ref)(grant_ref_t, int);
         /*
          * Stop granting a grant entry to domain for transfer. If 
tranfer has
          * not started, just reclaim the grant entry and return 
failure(==0).
          * Otherwise, wait for the transfer to complete and then return the
          * frame.
          */
         unsigned long (*end_foreign_transfer_ref)(grant_ref_t);
         /*
          * Query the status of a grant entry. Ref parameter is reference of
          * queried grant entry, return value is the status of queried 
entry.
          * Detailed status(writing/reading) can be gotten from the 
return value
          * by bit operations.
          */
         int (*query_foreign_access)(grant_ref_t);
         /*
          * Grant a domain to access a range of bytes within the page 
referred by
          * an available grant entry. Ref parameter is grant entry reference
          * number, domid is id of grantee domain, frame is frame address of
          * subpage grant, flags is grant type and flag information, 
page_off is
          * offset of the range of bytes, and length is length of bytes 
to be
          * accessed.
          */
         void (*update_subpage_entry)(grant_ref_t, domid_t, unsigned 
long, int,
                                      unsigned, unsigned);
         /*
          * Redirect an available grant entry on domain A to another grant
          * reference of domain B, then allow domain C to use grant 
reference
          * of domain B transitively. Ref parameter is an available 
grant entry
          * reference on domain A, domid is id of domain C which 
accesses grant
          * entry transitively, flags is grant type and flag information,
          * trans_domid is id of domain B whose grant entry is finally 
accessed
          * transitively, trans_gref is grant entry transitive reference of
          * domain B.
          */
         void (*update_trans_entry)(grant_ref_t, domid_t, int, domid_t,
                                    grant_ref_t);
Thanks
Annie
> Ian.
>
>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 04:37:54 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 04: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.xensource.com>)
	id 1RZxdZ-0001C2-DL; Mon, 12 Dec 2011 04:37:13 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RZxdX-0001Bt-HT
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 04:37:11 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1323664577!5120578!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDc4Ng==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9354 invoked from network); 12 Dec 2011 04:36:17 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Dec 2011 04:36:17 -0000
X-IronPort-AV: E=Sophos;i="4.71,337,1320624000"; 
   d="scan'208";a="9406683"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Dec 2011 04:36:17 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 12 Dec 2011 04:36:17 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RZxce-0004Rz-Nl;
	Mon, 12 Dec 2011 04:36:16 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RZxce-0004oD-G3;
	Mon, 12 Dec 2011 04:36:16 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10474-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 12 Dec 2011 04:36:16 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10474: tolerable FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10474 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10474/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-i386-i386-xl-winxpsp3    7 windows-install              fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install          fail never pass
 test-amd64-i386-xl-win7-amd64  7 windows-install              fail  never pass
 test-amd64-i386-xend-winxpsp3  7 windows-install              fail  never pass
 test-amd64-amd64-xl-win7-amd64  7 windows-install              fail never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-amd64-xl-sedf     14 guest-localmigrate/x10       fail   like 10472
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  1c58bb664d8d
baseline version:
 xen                  1c58bb664d8d

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 04:37:54 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 04: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.xensource.com>)
	id 1RZxdZ-0001C2-DL; Mon, 12 Dec 2011 04:37:13 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RZxdX-0001Bt-HT
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 04:37:11 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1323664577!5120578!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDc4Ng==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9354 invoked from network); 12 Dec 2011 04:36:17 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Dec 2011 04:36:17 -0000
X-IronPort-AV: E=Sophos;i="4.71,337,1320624000"; 
   d="scan'208";a="9406683"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Dec 2011 04:36:17 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 12 Dec 2011 04:36:17 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RZxce-0004Rz-Nl;
	Mon, 12 Dec 2011 04:36:16 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RZxce-0004oD-G3;
	Mon, 12 Dec 2011 04:36:16 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10474-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 12 Dec 2011 04:36:16 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10474: tolerable FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10474 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10474/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-i386-i386-xl-winxpsp3    7 windows-install              fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install          fail never pass
 test-amd64-i386-xl-win7-amd64  7 windows-install              fail  never pass
 test-amd64-i386-xend-winxpsp3  7 windows-install              fail  never pass
 test-amd64-amd64-xl-win7-amd64  7 windows-install              fail never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-amd64-xl-sedf     14 guest-localmigrate/x10       fail   like 10472
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  1c58bb664d8d
baseline version:
 xen                  1c58bb664d8d

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 07:12:20 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 07: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.xensource.com>)
	id 1Ra02r-0002CO-HX; Mon, 12 Dec 2011 07:11:29 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Ra02p-0002CJ-Fk
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 07:11:27 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1323673834!5138215!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDc4Ng==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12369 invoked from network); 12 Dec 2011 07:10:34 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Dec 2011 07:10:34 -0000
X-IronPort-AV: E=Sophos;i="4.71,337,1320624000"; 
   d="scan'208";a="9407400"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Dec 2011 07:10:34 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 12 Dec 2011 07:10:33 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: ANNIE LI <annie.li@oracle.com>
In-Reply-To: <4EE57204.4030509@oracle.com>
References: <1323430321-5465-1-git-send-email-annie.li@oracle.com>
	<1323430372-5503-1-git-send-email-annie.li@oracle.com>
	<1323452339.20077.92.camel@zakaz.uk.xensource.com>
	<4EE57204.4030509@oracle.com>
Organization: Citrix Systems, Inc.
Date: Mon, 12 Dec 2011 07:10:33 +0000
Message-ID: <1323673833.20936.65.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
X-Mailer: Evolution 2.32.3 
Cc: "jeremy@goop.org" <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	"kurt.hackel@oracle.com" <kurt.hackel@oracle.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Paul Durrant <Paul.Durrant@citrix.com>
Subject: Re: [Xen-devel] [PATCH V3 1/2] xen/granttable: Support sub-page
	grants
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2011-12-12 at 03:16 +0000, ANNIE LI wrote:
> > Please can you name the arguments here and then refer to them by name in
> > the comments instead of all this "First parameter", "second one" stuff.
> >
> > Similarly for the existing comments sorry I didn't notice this in
> > previous review.
> Please check following comments in gnttab_ops, I changed the "First 
> parameter", "second one" into parameter name. However, it looks not very 
> consistent with parameters format of function fn since only parameter 
> type exists, not name.

You can give the parameters names in the function pointers too, that's
what I was suggesting.

e.g.:
         int (*map_frames)(unsigned long *frames, unsigned int nr);

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 07:12:20 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 07: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.xensource.com>)
	id 1Ra02r-0002CO-HX; Mon, 12 Dec 2011 07:11:29 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Ra02p-0002CJ-Fk
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 07:11:27 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1323673834!5138215!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDc4Ng==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12369 invoked from network); 12 Dec 2011 07:10:34 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Dec 2011 07:10:34 -0000
X-IronPort-AV: E=Sophos;i="4.71,337,1320624000"; 
   d="scan'208";a="9407400"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Dec 2011 07:10:34 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 12 Dec 2011 07:10:33 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: ANNIE LI <annie.li@oracle.com>
In-Reply-To: <4EE57204.4030509@oracle.com>
References: <1323430321-5465-1-git-send-email-annie.li@oracle.com>
	<1323430372-5503-1-git-send-email-annie.li@oracle.com>
	<1323452339.20077.92.camel@zakaz.uk.xensource.com>
	<4EE57204.4030509@oracle.com>
Organization: Citrix Systems, Inc.
Date: Mon, 12 Dec 2011 07:10:33 +0000
Message-ID: <1323673833.20936.65.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
X-Mailer: Evolution 2.32.3 
Cc: "jeremy@goop.org" <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	"kurt.hackel@oracle.com" <kurt.hackel@oracle.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Paul Durrant <Paul.Durrant@citrix.com>
Subject: Re: [Xen-devel] [PATCH V3 1/2] xen/granttable: Support sub-page
	grants
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2011-12-12 at 03:16 +0000, ANNIE LI wrote:
> > Please can you name the arguments here and then refer to them by name in
> > the comments instead of all this "First parameter", "second one" stuff.
> >
> > Similarly for the existing comments sorry I didn't notice this in
> > previous review.
> Please check following comments in gnttab_ops, I changed the "First 
> parameter", "second one" into parameter name. However, it looks not very 
> consistent with parameters format of function fn since only parameter 
> type exists, not name.

You can give the parameters names in the function pointers too, that's
what I was suggesting.

e.g.:
         int (*map_frames)(unsigned long *frames, unsigned int nr);

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 07:33:58 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 07:33:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ra0Nw-0002Ox-Hv; Mon, 12 Dec 2011 07:33:16 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <annie.li@oracle.com>) id 1Ra0Nu-0002Os-Vh
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 07:33:15 +0000
X-Env-Sender: annie.li@oracle.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1323675141!6459225!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQyODUwNw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25935 invoked from network); 12 Dec 2011 07:32:22 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-13.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 12 Dec 2011 07:32:22 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pBC7WH9q023890
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 12 Dec 2011 07:32:17 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pBC7WGqh024529
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 12 Dec 2011 07:32:16 GMT
Received: from abhmt117.oracle.com (abhmt117.oracle.com [141.146.116.69])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pBC7WAfO009662; Mon, 12 Dec 2011 01:32:10 -0600
Received: from [10.182.39.81] (/10.182.39.81)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Sun, 11 Dec 2011 23:32:10 -0800
Message-ID: <4EE5ADF7.7080400@oracle.com>
Date: Mon, 12 Dec 2011 15:32:07 +0800
From: ANNIE LI <annie.li@oracle.com>
Organization: Oracle Corporation
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.9.2.24) Gecko/20111103 Thunderbird/3.1.16
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1323430321-5465-1-git-send-email-annie.li@oracle.com>	
	<1323430372-5503-1-git-send-email-annie.li@oracle.com>	
	<1323452339.20077.92.camel@zakaz.uk.xensource.com>	
	<4EE57204.4030509@oracle.com>
	<1323673833.20936.65.camel@dagon.hellion.org.uk>
In-Reply-To: <1323673833.20936.65.camel@dagon.hellion.org.uk>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090206.4EE5AE02.0090,ss=1,re=0.000,fgs=0
Cc: "jeremy@goop.org" <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	"kurt.hackel@oracle.com" <kurt.hackel@oracle.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Paul Durrant <Paul.Durrant@citrix.com>
Subject: Re: [Xen-devel] [PATCH V3 1/2] xen/granttable: Support sub-page
	grants
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com



On 2011-12-12 15:10, Ian Campbell wrote:
> On Mon, 2011-12-12 at 03:16 +0000, ANNIE LI wrote:
>>> Please can you name the arguments here and then refer to them by name in
>>> the comments instead of all this "First parameter", "second one" stuff.
>>>
>>> Similarly for the existing comments sorry I didn't notice this in
>>> previous review.
>> Please check following comments in gnttab_ops, I changed the "First
>> parameter", "second one" into parameter name. However, it looks not very
>> consistent with parameters format of function fn since only parameter
>> type exists, not name.
> You can give the parameters names in the function pointers too, that's
> what I was suggesting.
>
> e.g.:
>           int (*map_frames)(unsigned long *frames, unsigned int nr);
>
Ok, I will correct comments and add parameter names of existing function 
in a third patch.
Sub-page and trans patches should contain corrected comments and 
parameter names directly.

Thanks
Annie
> Ian.
>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 07:33:58 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 07:33:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ra0Nw-0002Ox-Hv; Mon, 12 Dec 2011 07:33:16 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <annie.li@oracle.com>) id 1Ra0Nu-0002Os-Vh
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 07:33:15 +0000
X-Env-Sender: annie.li@oracle.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1323675141!6459225!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQyODUwNw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25935 invoked from network); 12 Dec 2011 07:32:22 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-13.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 12 Dec 2011 07:32:22 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pBC7WH9q023890
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 12 Dec 2011 07:32:17 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pBC7WGqh024529
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 12 Dec 2011 07:32:16 GMT
Received: from abhmt117.oracle.com (abhmt117.oracle.com [141.146.116.69])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pBC7WAfO009662; Mon, 12 Dec 2011 01:32:10 -0600
Received: from [10.182.39.81] (/10.182.39.81)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Sun, 11 Dec 2011 23:32:10 -0800
Message-ID: <4EE5ADF7.7080400@oracle.com>
Date: Mon, 12 Dec 2011 15:32:07 +0800
From: ANNIE LI <annie.li@oracle.com>
Organization: Oracle Corporation
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.9.2.24) Gecko/20111103 Thunderbird/3.1.16
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1323430321-5465-1-git-send-email-annie.li@oracle.com>	
	<1323430372-5503-1-git-send-email-annie.li@oracle.com>	
	<1323452339.20077.92.camel@zakaz.uk.xensource.com>	
	<4EE57204.4030509@oracle.com>
	<1323673833.20936.65.camel@dagon.hellion.org.uk>
In-Reply-To: <1323673833.20936.65.camel@dagon.hellion.org.uk>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090206.4EE5AE02.0090,ss=1,re=0.000,fgs=0
Cc: "jeremy@goop.org" <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	"kurt.hackel@oracle.com" <kurt.hackel@oracle.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Paul Durrant <Paul.Durrant@citrix.com>
Subject: Re: [Xen-devel] [PATCH V3 1/2] xen/granttable: Support sub-page
	grants
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com



On 2011-12-12 15:10, Ian Campbell wrote:
> On Mon, 2011-12-12 at 03:16 +0000, ANNIE LI wrote:
>>> Please can you name the arguments here and then refer to them by name in
>>> the comments instead of all this "First parameter", "second one" stuff.
>>>
>>> Similarly for the existing comments sorry I didn't notice this in
>>> previous review.
>> Please check following comments in gnttab_ops, I changed the "First
>> parameter", "second one" into parameter name. However, it looks not very
>> consistent with parameters format of function fn since only parameter
>> type exists, not name.
> You can give the parameters names in the function pointers too, that's
> what I was suggesting.
>
> e.g.:
>           int (*map_frames)(unsigned long *frames, unsigned int nr);
>
Ok, I will correct comments and add parameter names of existing function 
in a third patch.
Sub-page and trans patches should contain corrected comments and 
parameter names directly.

Thanks
Annie
> Ian.
>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 09:07:43 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 09: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.xensource.com>)
	id 1Ra1qg-0003cf-Ou; Mon, 12 Dec 2011 09:07:02 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Ra1qf-0003cX-KS
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 09:07:01 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1323680768!6776349!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21428 invoked from network); 12 Dec 2011 09:06:08 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-15.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 12 Dec 2011 09:06:08 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 12 Dec 2011 09:06:07 +0000
Message-Id: <4EE5D20B0200007800066DB8@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 12 Dec 2011 09:06:03 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Jackson" <Ian.Jackson@eu.citrix.com>
References: <CAFQ2Z+fpR1UkxFEAYTD6irBUBeA3c7eJ3x1bXE0jzpdfQtH64w@mail.gmail.com>
	<alpine.DEB.2.00.1112021223190.31179@kaball-desktop>
	<4EDE367D0200007800065B6B@nat28.tlf.novell.com>
	<alpine.DEB.2.00.1112061906550.31179@kaball-desktop>
	<04F972F38B3C4E4E91C4697DA8BF9F52846C7517E8@shsmsx502.ccr.corp.intel.com>
In-Reply-To: <04F972F38B3C4E4E91C4697DA8BF9F52846C7517E8@shsmsx502.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Haitao Shan <maillists.shan@gmail.com>, "Keir \(Xen.org\)" <keir@xen.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Haitao Shan <haitao.shan@intel.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] Qemu MSI Cleaning Up
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 09.12.11 at 07:01, "Shan, Haitao" <haitao.shan@intel.com> wrote:
> Fine to me! Thanks, Jan!
> 
> Shan Haitao

Ian,

any chance to get this committed then?

Also, how are we going to deal with the "modern" qemu tree (is
passthrough for Xen implemented at all in that tree)?

Thanks, Jan


>> -----Original Message-----
>> From: Stefano Stabellini [mailto:stefano.stabellini@eu.citrix.com]
>> Sent: Wednesday, December 07, 2011 3:08 AM
>> To: Jan Beulich
>> Cc: Stefano Stabellini; Haitao Shan; Ian Jackson; Shan, Haitao; xen-
>> devel@lists.xensource.com; Keir (Xen.org)
>> Subject: Re: [Xen-devel] [PATCH] Qemu MSI Cleaning Up
>> 
>> On Tue, 6 Dec 2011, Jan Beulich wrote:
>> > >>> On 02.12.11 at 13:40, Stefano Stabellini
>> <stefano.stabellini@eu.citrix.com> wrote:
>> > > The two mapping and unmapping big chuncks of code looks very similar
>> > > apart from the DPCI_ADD_MAPPING/DPCI_REMOVE_MAPPING
>> parameter.
>> > > Could they be refactored into a single function called
>> > > "change_msix_mappings"?
>> > > This is more or less what I have in mind:
>> > >
>> > > change_msix_mappings(assigned_device, DPCI_REMOVE_MAPPING);
>> > >
>> > > update mmio_base_addr
>> > >
>> > > change_msix_mappings(assigned_device, DPCI_ADD_MAPPING);
>> >
>> > Please see below/attached for the outcome. Without MSI-X capable
>> > devices to pass through, I have to rely on others to do some testing
>> > on this.
>> 
>> It looks fine.
>> Haitao, are you happy with the new patch?




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 09:07:43 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 09: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.xensource.com>)
	id 1Ra1qg-0003cf-Ou; Mon, 12 Dec 2011 09:07:02 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Ra1qf-0003cX-KS
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 09:07:01 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1323680768!6776349!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21428 invoked from network); 12 Dec 2011 09:06:08 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-15.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 12 Dec 2011 09:06:08 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 12 Dec 2011 09:06:07 +0000
Message-Id: <4EE5D20B0200007800066DB8@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 12 Dec 2011 09:06:03 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Jackson" <Ian.Jackson@eu.citrix.com>
References: <CAFQ2Z+fpR1UkxFEAYTD6irBUBeA3c7eJ3x1bXE0jzpdfQtH64w@mail.gmail.com>
	<alpine.DEB.2.00.1112021223190.31179@kaball-desktop>
	<4EDE367D0200007800065B6B@nat28.tlf.novell.com>
	<alpine.DEB.2.00.1112061906550.31179@kaball-desktop>
	<04F972F38B3C4E4E91C4697DA8BF9F52846C7517E8@shsmsx502.ccr.corp.intel.com>
In-Reply-To: <04F972F38B3C4E4E91C4697DA8BF9F52846C7517E8@shsmsx502.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Haitao Shan <maillists.shan@gmail.com>, "Keir \(Xen.org\)" <keir@xen.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Haitao Shan <haitao.shan@intel.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] Qemu MSI Cleaning Up
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 09.12.11 at 07:01, "Shan, Haitao" <haitao.shan@intel.com> wrote:
> Fine to me! Thanks, Jan!
> 
> Shan Haitao

Ian,

any chance to get this committed then?

Also, how are we going to deal with the "modern" qemu tree (is
passthrough for Xen implemented at all in that tree)?

Thanks, Jan


>> -----Original Message-----
>> From: Stefano Stabellini [mailto:stefano.stabellini@eu.citrix.com]
>> Sent: Wednesday, December 07, 2011 3:08 AM
>> To: Jan Beulich
>> Cc: Stefano Stabellini; Haitao Shan; Ian Jackson; Shan, Haitao; xen-
>> devel@lists.xensource.com; Keir (Xen.org)
>> Subject: Re: [Xen-devel] [PATCH] Qemu MSI Cleaning Up
>> 
>> On Tue, 6 Dec 2011, Jan Beulich wrote:
>> > >>> On 02.12.11 at 13:40, Stefano Stabellini
>> <stefano.stabellini@eu.citrix.com> wrote:
>> > > The two mapping and unmapping big chuncks of code looks very similar
>> > > apart from the DPCI_ADD_MAPPING/DPCI_REMOVE_MAPPING
>> parameter.
>> > > Could they be refactored into a single function called
>> > > "change_msix_mappings"?
>> > > This is more or less what I have in mind:
>> > >
>> > > change_msix_mappings(assigned_device, DPCI_REMOVE_MAPPING);
>> > >
>> > > update mmio_base_addr
>> > >
>> > > change_msix_mappings(assigned_device, DPCI_ADD_MAPPING);
>> >
>> > Please see below/attached for the outcome. Without MSI-X capable
>> > devices to pass through, I have to rely on others to do some testing
>> > on this.
>> 
>> It looks fine.
>> Haitao, are you happy with the new patch?




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 09:22:28 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 09:22:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ra253-00043D-V4; Mon, 12 Dec 2011 09:21:53 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Ra252-000433-7I
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 09:21:52 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1323681659!7008991!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDc4Ng==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31757 invoked from network); 12 Dec 2011 09:20:59 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Dec 2011 09:20:59 -0000
X-IronPort-AV: E=Sophos;i="4.71,337,1320624000"; 
   d="scan'208";a="9409776"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Dec 2011 09:19:58 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 12 Dec 2011 09:19:57 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Date: Mon, 12 Dec 2011 09:19:57 +0000
In-Reply-To: <alpine.DEB.2.00.1112091731500.3517@kaball-desktop>
References: <patchbomb.1323448640@cosworth.uk.xensource.com>
	<3b7ac401f144206c3044.1323448644@cosworth.uk.xensource.com>
	<20111209165111.GA24038@aepfle.de>
	<1323450675.20077.89.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1112091731500.3517@kaball-desktop>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323681597.20077.95.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Olaf Hering <olaf@aepfle.de>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	Vincent Hanquez <Vincent.Hanquez@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Jonathan Ludlam <Jonathan.Ludlam@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 4 of 4] Linux/xencommons: Use oxenstored by
 default when available
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2011-12-09 at 17:32 +0000, Stefano Stabellini wrote:
> On Fri, 9 Dec 2011, Ian Campbell wrote:
> > On Fri, 2011-12-09 at 16:51 +0000, Olaf Hering wrote:
> > > On Fri, Dec 09, Ian Campbell wrote:
> > > 
> > > > # HG changeset patch
> > > > # User Ian Campbell <ian.campbell@citrix.com>
> > > > # Date 1323448636 0
> > > > # Node ID 3b7ac401f144206c30440fbb41c74b13fa20b8cb
> > > > # Parent  74f94e15bfe1dad412d0342aeabdbd895657f54f
> > > > Linux/xencommons: Use oxenstored by default when available
> > > 
> > > Assuming this has been tested:
> > 
> > I've been running with it for quite a while. Perhaps more importantly
> > XenServer has been using it since, well, since I can't remember when but
> > it was several years ago when they switched and they pound it pretty
> > hard in their testing. Harder than C xenstored could cope with which is
> > why this one got written...
> 
> However is our version up in sync with theirs I wonder... Are we missing
> any important bug fix?

XenServer switched to the one in the xen tree in March by the looks of
things, at least that's when the copy in xen-api.git was removed.

There is nothing of interest in xen-api.git's copy from the point it was
imported into xen-unstable until now, if anything xen-unstable has been
the one getting fixes.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 09:22:28 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 09:22:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ra253-00043D-V4; Mon, 12 Dec 2011 09:21:53 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Ra252-000433-7I
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 09:21:52 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1323681659!7008991!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDc4Ng==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31757 invoked from network); 12 Dec 2011 09:20:59 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Dec 2011 09:20:59 -0000
X-IronPort-AV: E=Sophos;i="4.71,337,1320624000"; 
   d="scan'208";a="9409776"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Dec 2011 09:19:58 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 12 Dec 2011 09:19:57 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Date: Mon, 12 Dec 2011 09:19:57 +0000
In-Reply-To: <alpine.DEB.2.00.1112091731500.3517@kaball-desktop>
References: <patchbomb.1323448640@cosworth.uk.xensource.com>
	<3b7ac401f144206c3044.1323448644@cosworth.uk.xensource.com>
	<20111209165111.GA24038@aepfle.de>
	<1323450675.20077.89.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1112091731500.3517@kaball-desktop>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323681597.20077.95.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Olaf Hering <olaf@aepfle.de>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	Vincent Hanquez <Vincent.Hanquez@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Jonathan Ludlam <Jonathan.Ludlam@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 4 of 4] Linux/xencommons: Use oxenstored by
 default when available
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2011-12-09 at 17:32 +0000, Stefano Stabellini wrote:
> On Fri, 9 Dec 2011, Ian Campbell wrote:
> > On Fri, 2011-12-09 at 16:51 +0000, Olaf Hering wrote:
> > > On Fri, Dec 09, Ian Campbell wrote:
> > > 
> > > > # HG changeset patch
> > > > # User Ian Campbell <ian.campbell@citrix.com>
> > > > # Date 1323448636 0
> > > > # Node ID 3b7ac401f144206c30440fbb41c74b13fa20b8cb
> > > > # Parent  74f94e15bfe1dad412d0342aeabdbd895657f54f
> > > > Linux/xencommons: Use oxenstored by default when available
> > > 
> > > Assuming this has been tested:
> > 
> > I've been running with it for quite a while. Perhaps more importantly
> > XenServer has been using it since, well, since I can't remember when but
> > it was several years ago when they switched and they pound it pretty
> > hard in their testing. Harder than C xenstored could cope with which is
> > why this one got written...
> 
> However is our version up in sync with theirs I wonder... Are we missing
> any important bug fix?

XenServer switched to the one in the xen tree in March by the looks of
things, at least that's when the copy in xen-api.git was removed.

There is nothing of interest in xen-api.git's copy from the point it was
imported into xen-unstable until now, if anything xen-unstable has been
the one getting fixes.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 09:27:04 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 09:27:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ra29X-0004CZ-MX; Mon, 12 Dec 2011 09:26:31 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Ra29W-0004CM-1S
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 09:26:30 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1323681918!49117370!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDc4NQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26148 invoked from network); 12 Dec 2011 09:25:18 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Dec 2011 09:25:18 -0000
X-IronPort-AV: E=Sophos;i="4.71,337,1320624000"; 
   d="scan'208";a="9410021"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Dec 2011 09:25:37 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 12 Dec 2011 09:25:37 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Bastian Blank <waldi@debian.org>
Date: Mon, 12 Dec 2011 09:25:37 +0000
In-Reply-To: <1323541791-18006-6-git-send-email-waldi@debian.org>
References: <1323541791-18006-1-git-send-email-waldi@debian.org>
	<1323541791-18006-6-git-send-email-waldi@debian.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323681937.20077.97.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH 5/6] xen/xenbus-frontend: Make error message
 more clear
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Sat, 2011-12-10 at 18:29 +0000, Bastian Blank wrote:
> Add the work frontend to the error message because we now also have a
> backend device.
> 
> Signed-off-by: Bastian Blank <waldi@debian.org>
Acked-by: Ian Campbell <ian.campbell@citrix.com>

> ---
>  drivers/xen/xenbus/xenbus_dev_frontend.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/xen/xenbus/xenbus_dev_frontend.c b/drivers/xen/xenbus/xenbus_dev_frontend.c
> index fb30cff..9f6be7d 100644
> --- a/drivers/xen/xenbus/xenbus_dev_frontend.c
> +++ b/drivers/xen/xenbus/xenbus_dev_frontend.c
> @@ -611,7 +611,7 @@ static int __init xenbus_init(void)
>  
>  	err = misc_register(&xenbus_dev);
>  	if (err)
> -		printk(KERN_ERR "Could not register xenbus device\n");
> +		printk(KERN_ERR "Could not register xenbus frontend device\n");
>  	return err;
>  }
>  



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 09:27:04 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 09:27:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ra29X-0004CZ-MX; Mon, 12 Dec 2011 09:26:31 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Ra29W-0004CM-1S
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 09:26:30 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1323681918!49117370!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDc4NQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26148 invoked from network); 12 Dec 2011 09:25:18 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Dec 2011 09:25:18 -0000
X-IronPort-AV: E=Sophos;i="4.71,337,1320624000"; 
   d="scan'208";a="9410021"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Dec 2011 09:25:37 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 12 Dec 2011 09:25:37 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Bastian Blank <waldi@debian.org>
Date: Mon, 12 Dec 2011 09:25:37 +0000
In-Reply-To: <1323541791-18006-6-git-send-email-waldi@debian.org>
References: <1323541791-18006-1-git-send-email-waldi@debian.org>
	<1323541791-18006-6-git-send-email-waldi@debian.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323681937.20077.97.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH 5/6] xen/xenbus-frontend: Make error message
 more clear
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Sat, 2011-12-10 at 18:29 +0000, Bastian Blank wrote:
> Add the work frontend to the error message because we now also have a
> backend device.
> 
> Signed-off-by: Bastian Blank <waldi@debian.org>
Acked-by: Ian Campbell <ian.campbell@citrix.com>

> ---
>  drivers/xen/xenbus/xenbus_dev_frontend.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/xen/xenbus/xenbus_dev_frontend.c b/drivers/xen/xenbus/xenbus_dev_frontend.c
> index fb30cff..9f6be7d 100644
> --- a/drivers/xen/xenbus/xenbus_dev_frontend.c
> +++ b/drivers/xen/xenbus/xenbus_dev_frontend.c
> @@ -611,7 +611,7 @@ static int __init xenbus_init(void)
>  
>  	err = misc_register(&xenbus_dev);
>  	if (err)
> -		printk(KERN_ERR "Could not register xenbus device\n");
> +		printk(KERN_ERR "Could not register xenbus frontend device\n");
>  	return err;
>  }
>  



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 09:31:09 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 09:31:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ra2DS-0004PM-Bx; Mon, 12 Dec 2011 09:30:34 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Ra2DR-0004P5-CY
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 09:30:33 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1323682180!5175025!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25054 invoked from network); 12 Dec 2011 09:29:40 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-9.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 12 Dec 2011 09:29:40 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 12 Dec 2011 09:29:39 +0000
Message-Id: <4EE5D7910200007800066DD9@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 12 Dec 2011 09:29:37 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>,
	"Tim Deegan" <tim@xen.org>
References: <patchbomb.1323462147@xdev.gridcentric.ca>
	<bfebf49b3eb63eb09751.1323462152@xdev.gridcentric.ca>
In-Reply-To: <bfebf49b3eb63eb09751.1323462152@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
Cc: andres@gridcentric.ca, keir.xen@gmail.com, xen-devel@lists.xensource.com,
	adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 5 of 9] x86/mm: Add per-page locking for
 memory sharing, when audits are disabled
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 >>> On 09.12.11 at 21:22, Andres Lagar-Cavilla <andres@lagarcavilla.org> wrote:
> With the removal of the hash table, all that is needed now is locking
> of individual shared pages, as new (gfn,domain) pairs are removed or
> added from the list of mappings.
> 
> We recycle PGT_locked and use it to lock individual pages. We ensure 
> deadlock
> is averted by locking pages in increasing order. We leverage an "external"
> order enforcing construct from mm-locks.h to ensure the p2m_lock (needed to
> modify gfn entries during sharing) is always taken after page_locks.

As said before, I view taking a coarse lock inside a fine grained one as
inappropriate, and hence recommend to not apply this patch without
knowing if/when the promised follow-up patch will make it in.

Jan

> The global lock remains for the benefit of the auditing code, and is
> thus enabled only as a compile-time option.
> 
> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 09:31:09 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 09:31:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ra2DS-0004PM-Bx; Mon, 12 Dec 2011 09:30:34 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Ra2DR-0004P5-CY
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 09:30:33 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1323682180!5175025!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25054 invoked from network); 12 Dec 2011 09:29:40 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-9.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 12 Dec 2011 09:29:40 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 12 Dec 2011 09:29:39 +0000
Message-Id: <4EE5D7910200007800066DD9@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 12 Dec 2011 09:29:37 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>,
	"Tim Deegan" <tim@xen.org>
References: <patchbomb.1323462147@xdev.gridcentric.ca>
	<bfebf49b3eb63eb09751.1323462152@xdev.gridcentric.ca>
In-Reply-To: <bfebf49b3eb63eb09751.1323462152@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
Cc: andres@gridcentric.ca, keir.xen@gmail.com, xen-devel@lists.xensource.com,
	adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 5 of 9] x86/mm: Add per-page locking for
 memory sharing, when audits are disabled
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 >>> On 09.12.11 at 21:22, Andres Lagar-Cavilla <andres@lagarcavilla.org> wrote:
> With the removal of the hash table, all that is needed now is locking
> of individual shared pages, as new (gfn,domain) pairs are removed or
> added from the list of mappings.
> 
> We recycle PGT_locked and use it to lock individual pages. We ensure 
> deadlock
> is averted by locking pages in increasing order. We leverage an "external"
> order enforcing construct from mm-locks.h to ensure the p2m_lock (needed to
> modify gfn entries during sharing) is always taken after page_locks.

As said before, I view taking a coarse lock inside a fine grained one as
inappropriate, and hence recommend to not apply this patch without
knowing if/when the promised follow-up patch will make it in.

Jan

> The global lock remains for the benefit of the auditing code, and is
> thus enabled only as a compile-time option.
> 
> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 09:31:48 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 09:31:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ra2EK-0004TE-RY; Mon, 12 Dec 2011 09:31:28 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Ra2EJ-0004Sh-CK
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 09:31:27 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1323682234!5171664!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDc4NQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1538 invoked from network); 12 Dec 2011 09:30:34 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Dec 2011 09:30:34 -0000
X-IronPort-AV: E=Sophos;i="4.71,337,1320624000"; 
   d="scan'208";a="9410180"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Dec 2011 09:30:33 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 12 Dec 2011 09:30:33 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Bastian Blank <waldi@debian.org>
Date: Mon, 12 Dec 2011 09:30:33 +0000
In-Reply-To: <1323541791-18006-7-git-send-email-waldi@debian.org>
References: <1323541791-18006-1-git-send-email-waldi@debian.org>
	<1323541791-18006-7-git-send-email-waldi@debian.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323682233.20077.100.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH 6/6] xen/xenbus-backend: Only register
 device if communication ring is local
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Sat, 2011-12-10 at 18:29 +0000, Bastian Blank wrote:
> +/* A flag to determine if xenstored is 'local' */
> +#ifdef CONFIG_XEN_BACKEND
> +static int xenstored_local;
> +#endif

I think this can be __initdata since all the users are __init.

> +#ifdef CONFIG_XEN_BACKEND
> +			xenstored_local = 1;

I would push this down into xenstore_local_init() and only set it on
success.

>  			err = xenstored_local_init();

This is now only called if CONFIG_XEN_BACKEND. You should add a similar
#ifdef around the function definition.

Ian.

>  			if (err)
>  				goto out_error;
> +#else
> +			BUG();
> +#endif
>  		}
>  		xen_store_interface = mfn_to_virt(xen_store_mfn);
>  	}



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 09:31:48 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 09:31:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ra2EK-0004TE-RY; Mon, 12 Dec 2011 09:31:28 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Ra2EJ-0004Sh-CK
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 09:31:27 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1323682234!5171664!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDc4NQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1538 invoked from network); 12 Dec 2011 09:30:34 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Dec 2011 09:30:34 -0000
X-IronPort-AV: E=Sophos;i="4.71,337,1320624000"; 
   d="scan'208";a="9410180"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Dec 2011 09:30:33 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 12 Dec 2011 09:30:33 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Bastian Blank <waldi@debian.org>
Date: Mon, 12 Dec 2011 09:30:33 +0000
In-Reply-To: <1323541791-18006-7-git-send-email-waldi@debian.org>
References: <1323541791-18006-1-git-send-email-waldi@debian.org>
	<1323541791-18006-7-git-send-email-waldi@debian.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323682233.20077.100.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH 6/6] xen/xenbus-backend: Only register
 device if communication ring is local
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Sat, 2011-12-10 at 18:29 +0000, Bastian Blank wrote:
> +/* A flag to determine if xenstored is 'local' */
> +#ifdef CONFIG_XEN_BACKEND
> +static int xenstored_local;
> +#endif

I think this can be __initdata since all the users are __init.

> +#ifdef CONFIG_XEN_BACKEND
> +			xenstored_local = 1;

I would push this down into xenstore_local_init() and only set it on
success.

>  			err = xenstored_local_init();

This is now only called if CONFIG_XEN_BACKEND. You should add a similar
#ifdef around the function definition.

Ian.

>  			if (err)
>  				goto out_error;
> +#else
> +			BUG();
> +#endif
>  		}
>  		xen_store_interface = mfn_to_virt(xen_store_mfn);
>  	}



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 09:33:41 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 09:33:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ra2G9-0004dH-C6; Mon, 12 Dec 2011 09:33:21 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Ra2G7-0004cq-HF
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 09:33:19 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1323682345!7001011!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25951 invoked from network); 12 Dec 2011 09:32:25 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-14.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 12 Dec 2011 09:32:25 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 12 Dec 2011 09:32:24 +0000
Message-Id: <4EE5D8310200007800066DDC@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 12 Dec 2011 09:32:17 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>,<tim@xen.org>
References: <patchbomb.1323462147@xdev.gridcentric.ca>
	<bba44de8394a5cce6123.1323462153@xdev.gridcentric.ca>
In-Reply-To: <bba44de8394a5cce6123.1323462153@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
Cc: andres@gridcentric.ca, keir.xen@gmail.com, xen-devel@lists.xensource.com,
	adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 6 of 9] x86/mm: New domctl: add a shared
 page to the physmap
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 >>> On 09.12.11 at 21:22, Andres Lagar-Cavilla <andres@lagarcavilla.org> wrote:
> This domctl is useful to, for example, populate parts of a domain's
> physmap with shared frames, directly.

As said before - there's no consumer of this new code within the series,
and hence you're asking to add dead code. That's no appropriate imo.

Jan

> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
> 
> diff -r bfebf49b3eb6 -r bba44de8394a xen/arch/x86/mm/mem_sharing.c
> --- a/xen/arch/x86/mm/mem_sharing.c
> +++ b/xen/arch/x86/mm/mem_sharing.c
> @@ -851,6 +851,74 @@ err_out:
>      return ret;
>  }
>  
> +int mem_sharing_add_to_physmap(struct domain *sd, unsigned long sgfn, 
> shr_handle_t sh,
> +                            struct domain *cd, unsigned long cgfn) 
> +{
> +    struct page_info *spage;
> +    int ret = -EINVAL;
> +    mfn_t smfn, cmfn;
> +    p2m_type_t smfn_type, cmfn_type;
> +    struct gfn_info *gfn_info;
> +    struct p2m_domain *p2m = p2m_get_hostp2m(cd);
> +    p2m_access_t a;
> +    DECLARE_PG_LOCK_DATA(pld);
> +    
> +    /* XXX if sd == cd handle potential deadlock by ordering
> +     * the get_ and put_gfn's */
> +    smfn = get_gfn_query(sd, sgfn, &smfn_type);
> +    cmfn = get_gfn_type_access(p2m, cgfn, &cmfn_type, &a, p2m_query, NULL);
> +
> +    /* Get the source shared page, check and lock */
> +    ret = XEN_DOMCTL_MEM_SHARING_S_HANDLE_INVALID;
> +    spage = __grab_shared_page(smfn, &pld);
> +    if ( spage == NULL )
> +        goto err_out;
> +    ASSERT(smfn_type == p2m_ram_shared);
> +
> +    /* Check that the handles match */
> +    if ( spage->shared_info->handle != sh )
> +        goto err_unlock;
> +
> +    /* Make sure the target page is a hole in the physmap */
> +    if ( mfn_valid(cmfn) ||
> +         (!(p2m_is_ram(cmfn_type))) )
> +    {
> +        ret = XEN_DOMCTL_MEM_SHARING_C_HANDLE_INVALID;
> +        goto err_unlock;
> +    }
> +
> +    /* This is simpler than regular sharing */
> +    BUG_ON(!get_page_and_type(spage, dom_cow, PGT_shared_page));
> +    if ( (gfn_info = mem_sharing_gfn_alloc(spage, cd, cgfn)) == NULL )
> +    {
> +        put_page_and_type(spage);
> +        ret = -ENOMEM;
> +        goto err_unlock;
> +    }
> +
> +    p2m_lock(p2m);
> +    ret = set_p2m_entry(p2m, cgfn, smfn, PAGE_ORDER_4K, p2m_ram_shared, a);
> +    p2m_unlock(p2m);
> +
> +    /* Tempted to turn this into an assert */
> +    if ( !ret ) {
> +        ret = -ENOENT;
> +        mem_sharing_gfn_destroy(gfn_info, 0);
> +        put_page_and_type(spage);
> +    } else {
> +        atomic_inc(&cd->shr_pages);
> +        atomic_inc(&nr_shared_mfns);
> +        ret = 0;
> +    }
> +
> +err_unlock:
> +    mem_sharing_page_unlock(spage, &pld);
> +err_out:
> +    put_gfn(cd, cgfn);
> +    put_gfn(sd, sgfn);
> +    return ret;
> +}
> +
>  int mem_sharing_unshare_page(struct domain *d,
>                               unsigned long gfn, 
>                               uint16_t flags)
> @@ -1085,6 +1153,42 @@ int mem_sharing_domctl(struct domain *d,
>          }
>          break;
>  
> +        case XEN_DOMCTL_MEM_EVENT_OP_SHARING_ADD_PHYSMAP:
> +        {
> +            unsigned long sgfn, cgfn;
> +            struct domain *cd;
> +            shr_handle_t sh;
> +
> +            if ( !mem_sharing_enabled(d) )
> +                return -EINVAL;
> +
> +            cd = get_domain_by_id(mec->u.share.client_domain);
> +            if ( !cd )
> +                return -ESRCH;
> +
> +            if ( !mem_sharing_enabled(cd) )
> +            {
> +                put_domain(cd);
> +                return -EINVAL;
> +            }
> +
> +            if ( 
> XEN_DOMCTL_MEM_SHARING_FIELD_IS_GREF(mec->u.share.source_gfn) )
> +            {
> +                /* Cannot add a gref to the physmap */
> +                put_domain(cd);
> +                return -EINVAL;
> +            }
> +
> +            sgfn    = mec->u.share.source_gfn;
> +            sh      = mec->u.share.source_handle;
> +            cgfn    = mec->u.share.client_gfn;
> +
> +            rc = mem_sharing_add_to_physmap(d, sgfn, sh, cd, cgfn); 
> +
> +            put_domain(cd);
> +        }
> +        break;
> +
>          case XEN_DOMCTL_MEM_EVENT_OP_SHARING_RESUME:
>          {
>              if ( !mem_sharing_enabled(d) )
> diff -r bfebf49b3eb6 -r bba44de8394a xen/include/public/domctl.h
> --- a/xen/include/public/domctl.h
> +++ b/xen/include/public/domctl.h
> @@ -771,6 +771,7 @@ DEFINE_XEN_GUEST_HANDLE(xen_domctl_mem_e
>  #define XEN_DOMCTL_MEM_EVENT_OP_SHARING_DEBUG_GFN      5
>  #define XEN_DOMCTL_MEM_EVENT_OP_SHARING_DEBUG_MFN      6
>  #define XEN_DOMCTL_MEM_EVENT_OP_SHARING_DEBUG_GREF     7
> +#define XEN_DOMCTL_MEM_EVENT_OP_SHARING_ADD_PHYSMAP    8
>  
>  #define XEN_DOMCTL_MEM_SHARING_S_HANDLE_INVALID  (-10)
>  #define XEN_DOMCTL_MEM_SHARING_C_HANDLE_INVALID  (-9)
> @@ -797,7 +798,7 @@ struct xen_domctl_mem_sharing_op {
>              } u;
>              uint64_aligned_t  handle;     /* OUT: the handle           */
>          } nominate;
> -        struct mem_sharing_op_share {     /* OP_SHARE */
> +        struct mem_sharing_op_share {     /* OP_SHARE/ADD_PHYSMAP */
>              uint64_aligned_t source_gfn;    /* IN: the gfn of the source 
> page */
>              uint64_aligned_t source_handle; /* IN: handle to the source 
> page */
>              uint64_aligned_t client_domain; /* IN: the client domain id */



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 09:33:41 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 09:33:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ra2G9-0004dH-C6; Mon, 12 Dec 2011 09:33:21 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Ra2G7-0004cq-HF
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 09:33:19 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1323682345!7001011!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25951 invoked from network); 12 Dec 2011 09:32:25 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-14.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 12 Dec 2011 09:32:25 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 12 Dec 2011 09:32:24 +0000
Message-Id: <4EE5D8310200007800066DDC@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 12 Dec 2011 09:32:17 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>,<tim@xen.org>
References: <patchbomb.1323462147@xdev.gridcentric.ca>
	<bba44de8394a5cce6123.1323462153@xdev.gridcentric.ca>
In-Reply-To: <bba44de8394a5cce6123.1323462153@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
Cc: andres@gridcentric.ca, keir.xen@gmail.com, xen-devel@lists.xensource.com,
	adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 6 of 9] x86/mm: New domctl: add a shared
 page to the physmap
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 >>> On 09.12.11 at 21:22, Andres Lagar-Cavilla <andres@lagarcavilla.org> wrote:
> This domctl is useful to, for example, populate parts of a domain's
> physmap with shared frames, directly.

As said before - there's no consumer of this new code within the series,
and hence you're asking to add dead code. That's no appropriate imo.

Jan

> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
> 
> diff -r bfebf49b3eb6 -r bba44de8394a xen/arch/x86/mm/mem_sharing.c
> --- a/xen/arch/x86/mm/mem_sharing.c
> +++ b/xen/arch/x86/mm/mem_sharing.c
> @@ -851,6 +851,74 @@ err_out:
>      return ret;
>  }
>  
> +int mem_sharing_add_to_physmap(struct domain *sd, unsigned long sgfn, 
> shr_handle_t sh,
> +                            struct domain *cd, unsigned long cgfn) 
> +{
> +    struct page_info *spage;
> +    int ret = -EINVAL;
> +    mfn_t smfn, cmfn;
> +    p2m_type_t smfn_type, cmfn_type;
> +    struct gfn_info *gfn_info;
> +    struct p2m_domain *p2m = p2m_get_hostp2m(cd);
> +    p2m_access_t a;
> +    DECLARE_PG_LOCK_DATA(pld);
> +    
> +    /* XXX if sd == cd handle potential deadlock by ordering
> +     * the get_ and put_gfn's */
> +    smfn = get_gfn_query(sd, sgfn, &smfn_type);
> +    cmfn = get_gfn_type_access(p2m, cgfn, &cmfn_type, &a, p2m_query, NULL);
> +
> +    /* Get the source shared page, check and lock */
> +    ret = XEN_DOMCTL_MEM_SHARING_S_HANDLE_INVALID;
> +    spage = __grab_shared_page(smfn, &pld);
> +    if ( spage == NULL )
> +        goto err_out;
> +    ASSERT(smfn_type == p2m_ram_shared);
> +
> +    /* Check that the handles match */
> +    if ( spage->shared_info->handle != sh )
> +        goto err_unlock;
> +
> +    /* Make sure the target page is a hole in the physmap */
> +    if ( mfn_valid(cmfn) ||
> +         (!(p2m_is_ram(cmfn_type))) )
> +    {
> +        ret = XEN_DOMCTL_MEM_SHARING_C_HANDLE_INVALID;
> +        goto err_unlock;
> +    }
> +
> +    /* This is simpler than regular sharing */
> +    BUG_ON(!get_page_and_type(spage, dom_cow, PGT_shared_page));
> +    if ( (gfn_info = mem_sharing_gfn_alloc(spage, cd, cgfn)) == NULL )
> +    {
> +        put_page_and_type(spage);
> +        ret = -ENOMEM;
> +        goto err_unlock;
> +    }
> +
> +    p2m_lock(p2m);
> +    ret = set_p2m_entry(p2m, cgfn, smfn, PAGE_ORDER_4K, p2m_ram_shared, a);
> +    p2m_unlock(p2m);
> +
> +    /* Tempted to turn this into an assert */
> +    if ( !ret ) {
> +        ret = -ENOENT;
> +        mem_sharing_gfn_destroy(gfn_info, 0);
> +        put_page_and_type(spage);
> +    } else {
> +        atomic_inc(&cd->shr_pages);
> +        atomic_inc(&nr_shared_mfns);
> +        ret = 0;
> +    }
> +
> +err_unlock:
> +    mem_sharing_page_unlock(spage, &pld);
> +err_out:
> +    put_gfn(cd, cgfn);
> +    put_gfn(sd, sgfn);
> +    return ret;
> +}
> +
>  int mem_sharing_unshare_page(struct domain *d,
>                               unsigned long gfn, 
>                               uint16_t flags)
> @@ -1085,6 +1153,42 @@ int mem_sharing_domctl(struct domain *d,
>          }
>          break;
>  
> +        case XEN_DOMCTL_MEM_EVENT_OP_SHARING_ADD_PHYSMAP:
> +        {
> +            unsigned long sgfn, cgfn;
> +            struct domain *cd;
> +            shr_handle_t sh;
> +
> +            if ( !mem_sharing_enabled(d) )
> +                return -EINVAL;
> +
> +            cd = get_domain_by_id(mec->u.share.client_domain);
> +            if ( !cd )
> +                return -ESRCH;
> +
> +            if ( !mem_sharing_enabled(cd) )
> +            {
> +                put_domain(cd);
> +                return -EINVAL;
> +            }
> +
> +            if ( 
> XEN_DOMCTL_MEM_SHARING_FIELD_IS_GREF(mec->u.share.source_gfn) )
> +            {
> +                /* Cannot add a gref to the physmap */
> +                put_domain(cd);
> +                return -EINVAL;
> +            }
> +
> +            sgfn    = mec->u.share.source_gfn;
> +            sh      = mec->u.share.source_handle;
> +            cgfn    = mec->u.share.client_gfn;
> +
> +            rc = mem_sharing_add_to_physmap(d, sgfn, sh, cd, cgfn); 
> +
> +            put_domain(cd);
> +        }
> +        break;
> +
>          case XEN_DOMCTL_MEM_EVENT_OP_SHARING_RESUME:
>          {
>              if ( !mem_sharing_enabled(d) )
> diff -r bfebf49b3eb6 -r bba44de8394a xen/include/public/domctl.h
> --- a/xen/include/public/domctl.h
> +++ b/xen/include/public/domctl.h
> @@ -771,6 +771,7 @@ DEFINE_XEN_GUEST_HANDLE(xen_domctl_mem_e
>  #define XEN_DOMCTL_MEM_EVENT_OP_SHARING_DEBUG_GFN      5
>  #define XEN_DOMCTL_MEM_EVENT_OP_SHARING_DEBUG_MFN      6
>  #define XEN_DOMCTL_MEM_EVENT_OP_SHARING_DEBUG_GREF     7
> +#define XEN_DOMCTL_MEM_EVENT_OP_SHARING_ADD_PHYSMAP    8
>  
>  #define XEN_DOMCTL_MEM_SHARING_S_HANDLE_INVALID  (-10)
>  #define XEN_DOMCTL_MEM_SHARING_C_HANDLE_INVALID  (-9)
> @@ -797,7 +798,7 @@ struct xen_domctl_mem_sharing_op {
>              } u;
>              uint64_aligned_t  handle;     /* OUT: the handle           */
>          } nominate;
> -        struct mem_sharing_op_share {     /* OP_SHARE */
> +        struct mem_sharing_op_share {     /* OP_SHARE/ADD_PHYSMAP */
>              uint64_aligned_t source_gfn;    /* IN: the gfn of the source 
> page */
>              uint64_aligned_t source_handle; /* IN: handle to the source 
> page */
>              uint64_aligned_t client_domain; /* IN: the client domain id */



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 09:34:28 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 09:34:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ra2Gv-0004j8-0Y; Mon, 12 Dec 2011 09:34:09 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Ra2Gt-0004iM-Fg
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 09:34:07 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1323682393!6834015!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26202 invoked from network); 12 Dec 2011 09:33:14 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-14.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 12 Dec 2011 09:33:14 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 12 Dec 2011 09:33:13 +0000
Message-Id: <4EE5D8640200007800066DDF@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 12 Dec 2011 09:33:08 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>,<tim@xen.org>
References: <patchbomb.1323462147@xdev.gridcentric.ca>
	<5b9b36648e439bca97b0.1323462155@xdev.gridcentric.ca>
In-Reply-To: <5b9b36648e439bca97b0.1323462155@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
Cc: andres@gridcentric.ca, keir.xen@gmail.com, xen-devel@lists.xensource.com,
	adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 8 of 9] x86/mm: New domctl: Perform sharing
	audit
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 >>> On 09.12.11 at 21:22, Andres Lagar-Cavilla <andres@lagarcavilla.org> wrote:
> Sharing audits are heavyweight, so instead of performing them inline,
> we make them callable via a domctl.

As said before - there's again no consumer of this new code within the
series, and hence you're asking to add dead code.

Jan

> Signed-off-by: Adin Scannell <adin@scannell.ca>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 09:34:28 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 09:34:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ra2Gv-0004j8-0Y; Mon, 12 Dec 2011 09:34:09 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Ra2Gt-0004iM-Fg
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 09:34:07 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1323682393!6834015!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26202 invoked from network); 12 Dec 2011 09:33:14 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-14.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 12 Dec 2011 09:33:14 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 12 Dec 2011 09:33:13 +0000
Message-Id: <4EE5D8640200007800066DDF@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 12 Dec 2011 09:33:08 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>,<tim@xen.org>
References: <patchbomb.1323462147@xdev.gridcentric.ca>
	<5b9b36648e439bca97b0.1323462155@xdev.gridcentric.ca>
In-Reply-To: <5b9b36648e439bca97b0.1323462155@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
Cc: andres@gridcentric.ca, keir.xen@gmail.com, xen-devel@lists.xensource.com,
	adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 8 of 9] x86/mm: New domctl: Perform sharing
	audit
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 >>> On 09.12.11 at 21:22, Andres Lagar-Cavilla <andres@lagarcavilla.org> wrote:
> Sharing audits are heavyweight, so instead of performing them inline,
> we make them callable via a domctl.

As said before - there's again no consumer of this new code within the
series, and hence you're asking to add dead code.

Jan

> Signed-off-by: Adin Scannell <adin@scannell.ca>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 09:52:15 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 09: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.xensource.com>)
	id 1Ra2Y3-00057m-Og; Mon, 12 Dec 2011 09:51:51 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Ra2Y2-00057g-EH
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 09:51:50 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1323683457!7055333!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDc4NQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23866 invoked from network); 12 Dec 2011 09:50:57 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Dec 2011 09:50:57 -0000
X-IronPort-AV: E=Sophos;i="4.71,337,1320624000"; 
   d="scan'208";a="9410787"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Dec 2011 09:50:57 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 12 Dec 2011 09:50:57 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Date: Mon, 12 Dec 2011 09:50:56 +0000
In-Reply-To: <6f58de995103b7bf4153.1323472551@xdev.gridcentric.ca>
References: <patchbomb.1323472550@xdev.gridcentric.ca>
	<6f58de995103b7bf4153.1323472551@xdev.gridcentric.ca>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323683457.20077.103.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"andres@gridcentric.ca" <andres@gridcentric.ca>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Tim
	\(Xen.org\)" <tim@xen.org>, "adin@gridcentric.ca" <adin@gridcentric.ca>
Subject: Re: [Xen-devel] [PATCH 1 of 8] Tools: Do not assume sharing target
 is dom0 in libxc wrappers
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2011-12-09 at 23:15 +0000, Andres Lagar-Cavilla wrote:
> tools/libxc/xc_memshr.c |  3 ++-
>  tools/libxc/xenctrl.h   |  1 +
>  2 files changed, 3 insertions(+), 1 deletions(-)
> 
> 
> The libxc wrapper that shares two pages always assumed one
> of the pages was mapped by dom0. Expand the API to specify
> both sharing domains.
> 
> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
> 
> diff -r 835be7c121b7 -r 6f58de995103 tools/libxc/xc_memshr.c
> --- a/tools/libxc/xc_memshr.c
> +++ b/tools/libxc/xc_memshr.c
> @@ -87,6 +87,7 @@ int xc_memshr_nominate_gref(xc_interface
>  }
>  
>  int xc_memshr_share(xc_interface *xch,
> +                    uint32_t source_domain,
>                      uint64_t source_handle,
>                      uint64_t client_handle)
>  {
> @@ -95,7 +96,7 @@ int xc_memshr_share(xc_interface *xch,
>  
>      domctl.cmd = XEN_DOMCTL_mem_sharing_op;
>      domctl.interface_version = XEN_DOMCTL_INTERFACE_VERSION;
> -    domctl.domain = 0;
> +    domctl.domain = (domid_t) source_domain;

domid_t is fair game in xenctrl.h, why not just use it?

There is an existing caller of this function in tools/memshr/interface.c
so this change will break the build. I suspect your 3/8 patch fixes this
but you must update the users at the same time, at least with the
minimal "no semantic change" patch, e.g. pass source_domain as 0, such
that everything still works at each step.

The changelog says "specify both sharing domains" yet you only add the
source domain here, where is the tgt domain?

>      op = &(domctl.u.mem_sharing_op);
>      op->op = XEN_DOMCTL_MEM_EVENT_OP_SHARING_SHARE;
>      op->u.share.source_handle = source_handle;
> diff -r 835be7c121b7 -r 6f58de995103 tools/libxc/xenctrl.h
> --- a/tools/libxc/xenctrl.h
> +++ b/tools/libxc/xenctrl.h
> @@ -1892,6 +1892,7 @@ int xc_memshr_nominate_gref(xc_interface
>                              grant_ref_t gref,
>                              uint64_t *handle);
>  int xc_memshr_share(xc_interface *xch,
> +                    uint32_t source_domain,
>                      uint64_t source_handle,
>                      uint64_t client_handle);
>  int xc_memshr_domain_resume(xc_interface *xch,



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 09:52:15 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 09: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.xensource.com>)
	id 1Ra2Y3-00057m-Og; Mon, 12 Dec 2011 09:51:51 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Ra2Y2-00057g-EH
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 09:51:50 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1323683457!7055333!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDc4NQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23866 invoked from network); 12 Dec 2011 09:50:57 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Dec 2011 09:50:57 -0000
X-IronPort-AV: E=Sophos;i="4.71,337,1320624000"; 
   d="scan'208";a="9410787"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Dec 2011 09:50:57 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 12 Dec 2011 09:50:57 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Date: Mon, 12 Dec 2011 09:50:56 +0000
In-Reply-To: <6f58de995103b7bf4153.1323472551@xdev.gridcentric.ca>
References: <patchbomb.1323472550@xdev.gridcentric.ca>
	<6f58de995103b7bf4153.1323472551@xdev.gridcentric.ca>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323683457.20077.103.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"andres@gridcentric.ca" <andres@gridcentric.ca>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Tim
	\(Xen.org\)" <tim@xen.org>, "adin@gridcentric.ca" <adin@gridcentric.ca>
Subject: Re: [Xen-devel] [PATCH 1 of 8] Tools: Do not assume sharing target
 is dom0 in libxc wrappers
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2011-12-09 at 23:15 +0000, Andres Lagar-Cavilla wrote:
> tools/libxc/xc_memshr.c |  3 ++-
>  tools/libxc/xenctrl.h   |  1 +
>  2 files changed, 3 insertions(+), 1 deletions(-)
> 
> 
> The libxc wrapper that shares two pages always assumed one
> of the pages was mapped by dom0. Expand the API to specify
> both sharing domains.
> 
> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
> 
> diff -r 835be7c121b7 -r 6f58de995103 tools/libxc/xc_memshr.c
> --- a/tools/libxc/xc_memshr.c
> +++ b/tools/libxc/xc_memshr.c
> @@ -87,6 +87,7 @@ int xc_memshr_nominate_gref(xc_interface
>  }
>  
>  int xc_memshr_share(xc_interface *xch,
> +                    uint32_t source_domain,
>                      uint64_t source_handle,
>                      uint64_t client_handle)
>  {
> @@ -95,7 +96,7 @@ int xc_memshr_share(xc_interface *xch,
>  
>      domctl.cmd = XEN_DOMCTL_mem_sharing_op;
>      domctl.interface_version = XEN_DOMCTL_INTERFACE_VERSION;
> -    domctl.domain = 0;
> +    domctl.domain = (domid_t) source_domain;

domid_t is fair game in xenctrl.h, why not just use it?

There is an existing caller of this function in tools/memshr/interface.c
so this change will break the build. I suspect your 3/8 patch fixes this
but you must update the users at the same time, at least with the
minimal "no semantic change" patch, e.g. pass source_domain as 0, such
that everything still works at each step.

The changelog says "specify both sharing domains" yet you only add the
source domain here, where is the tgt domain?

>      op = &(domctl.u.mem_sharing_op);
>      op->op = XEN_DOMCTL_MEM_EVENT_OP_SHARING_SHARE;
>      op->u.share.source_handle = source_handle;
> diff -r 835be7c121b7 -r 6f58de995103 tools/libxc/xenctrl.h
> --- a/tools/libxc/xenctrl.h
> +++ b/tools/libxc/xenctrl.h
> @@ -1892,6 +1892,7 @@ int xc_memshr_nominate_gref(xc_interface
>                              grant_ref_t gref,
>                              uint64_t *handle);
>  int xc_memshr_share(xc_interface *xch,
> +                    uint32_t source_domain,
>                      uint64_t source_handle,
>                      uint64_t client_handle);
>  int xc_memshr_domain_resume(xc_interface *xch,



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 09:57:59 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 09: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.xensource.com>)
	id 1Ra2dj-0005Ha-JA; Mon, 12 Dec 2011 09:57:43 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Ra2dh-0005HO-Gi
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 09:57:41 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1323683807!4983068!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDc4NQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28497 invoked from network); 12 Dec 2011 09:56:48 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Dec 2011 09:56:48 -0000
X-IronPort-AV: E=Sophos;i="4.71,337,1320624000"; 
   d="scan'208";a="9410950"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Dec 2011 09:56:46 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 12 Dec 2011 09:56:46 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Date: Mon, 12 Dec 2011 09:56:46 +0000
In-Reply-To: <892049dfc1c98a65fb0f.1323472552@xdev.gridcentric.ca>
References: <patchbomb.1323472550@xdev.gridcentric.ca>
	<892049dfc1c98a65fb0f.1323472552@xdev.gridcentric.ca>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323683806.20077.107.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"andres@gridcentric.ca" <andres@gridcentric.ca>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Tim
	\(Xen.org\)" <tim@xen.org>, "adin@gridcentric.ca" <adin@gridcentric.ca>
Subject: Re: [Xen-devel] [PATCH 2 of 8] Tools: Update libxc mem sharing
	interface
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2011-12-09 at 23:15 +0000, Andres Lagar-Cavilla wrote:
> tools/libxc/xc_memshr.c |  19 ++++++++++++++++++-
>  tools/libxc/xenctrl.h   |   7 ++++++-
>  2 files changed, 24 insertions(+), 2 deletions(-)
> 
> 
> Previosuly, the mem sharing code would return an opaque handle
> to index shared pages (and nominees) in its global hash table.
> By removing the hash table, the handle becomes a version, to
> avoid sharing a stale version of a page. Thus, libxc wrappers
> need to be updated accordingly.

Same comment wrt breaking the build as the previous patch.

> 
> Signed-off-by: Adin Scannell <adin@scannell.ca>
> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
> 
> diff -r 6f58de995103 -r 892049dfc1c9 tools/libxc/xc_memshr.c
> --- a/tools/libxc/xc_memshr.c
> +++ b/tools/libxc/xc_memshr.c
> @@ -88,8 +88,13 @@ int xc_memshr_nominate_gref(xc_interface
>  
>  int xc_memshr_share(xc_interface *xch,
>                      uint32_t source_domain,
> +                    uint64_t source_gfn,
>                      uint64_t source_handle,
> -                    uint64_t client_handle)
> +                    int source_is_gref,
> +                    uint32_t client_domain,
> +                    uint64_t client_gfn,
> +                    uint64_t client_handle,
> +                    int client_is_gref)
>  {
>      DECLARE_DOMCTL;
>      struct xen_domctl_mem_sharing_op *op;
> @@ -100,8 +105,20 @@ int xc_memshr_share(xc_interface *xch,
>      op = &(domctl.u.mem_sharing_op);
>      op->op = XEN_DOMCTL_MEM_EVENT_OP_SHARING_SHARE;
>      op->u.share.source_handle = source_handle;
> +    op->u.share.client_domain = (uint64_t) client_domain;

Why this disconnect between xc and hypercall API? 

>      op->u.share.client_handle = client_handle;
>  
> +    if (source_is_gref)
> +        XEN_DOMCTL_MEM_SHARING_FIELD_MAKE_GREF(

Is there an outstanding patch somewhere which adds this macro? I don't
see it in staging/xen-unstable.hg. Ah, yes, found it in another mail:

+#define XEN_DOMCTL_MEM_SHARING_FIELD_MAKE_GREF(field, val)  \
+    (field) = (XEN_DOMCTL_MEM_SHARING_FIELD_IS_GREF_FLAG | val)

Since this just adds a flag to the gfn why not just expose that to the
caller of this function rather than adding a separate flag as a
parameter?

> +                op->u.share.source_gfn, source_gfn);
> +    else
> +        op->u.share.source_gfn = source_gfn;
> +    if (client_is_gref)
> +        XEN_DOMCTL_MEM_SHARING_FIELD_MAKE_GREF(
> +                op->u.share.client_gfn, client_gfn);
> +    else
> +        op->u.share.client_gfn = client_gfn;
> +
>      return do_domctl(xch, &domctl);
>  }
>  
> diff -r 6f58de995103 -r 892049dfc1c9 tools/libxc/xenctrl.h
> --- a/tools/libxc/xenctrl.h
> +++ b/tools/libxc/xenctrl.h
> @@ -1893,8 +1893,13 @@ int xc_memshr_nominate_gref(xc_interface
>                              uint64_t *handle);
>  int xc_memshr_share(xc_interface *xch,
>                      uint32_t source_domain,
> +                    uint64_t source_gfn,
>                      uint64_t source_handle,
> -                    uint64_t client_handle);
> +                    int source_is_gref,
> +                    uint32_t client_domain,
> +                    uint64_t client_gfn,
> +                    uint64_t client_handle,
> +                    int dest_is_gref);
>  int xc_memshr_domain_resume(xc_interface *xch,
>                              uint32_t domid);
>  int xc_memshr_debug_gfn(xc_interface *xch,



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 09:57:59 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 09: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.xensource.com>)
	id 1Ra2dj-0005Ha-JA; Mon, 12 Dec 2011 09:57:43 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Ra2dh-0005HO-Gi
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 09:57:41 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1323683807!4983068!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDc4NQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28497 invoked from network); 12 Dec 2011 09:56:48 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Dec 2011 09:56:48 -0000
X-IronPort-AV: E=Sophos;i="4.71,337,1320624000"; 
   d="scan'208";a="9410950"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Dec 2011 09:56:46 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 12 Dec 2011 09:56:46 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Date: Mon, 12 Dec 2011 09:56:46 +0000
In-Reply-To: <892049dfc1c98a65fb0f.1323472552@xdev.gridcentric.ca>
References: <patchbomb.1323472550@xdev.gridcentric.ca>
	<892049dfc1c98a65fb0f.1323472552@xdev.gridcentric.ca>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323683806.20077.107.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"andres@gridcentric.ca" <andres@gridcentric.ca>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Tim
	\(Xen.org\)" <tim@xen.org>, "adin@gridcentric.ca" <adin@gridcentric.ca>
Subject: Re: [Xen-devel] [PATCH 2 of 8] Tools: Update libxc mem sharing
	interface
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2011-12-09 at 23:15 +0000, Andres Lagar-Cavilla wrote:
> tools/libxc/xc_memshr.c |  19 ++++++++++++++++++-
>  tools/libxc/xenctrl.h   |   7 ++++++-
>  2 files changed, 24 insertions(+), 2 deletions(-)
> 
> 
> Previosuly, the mem sharing code would return an opaque handle
> to index shared pages (and nominees) in its global hash table.
> By removing the hash table, the handle becomes a version, to
> avoid sharing a stale version of a page. Thus, libxc wrappers
> need to be updated accordingly.

Same comment wrt breaking the build as the previous patch.

> 
> Signed-off-by: Adin Scannell <adin@scannell.ca>
> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
> 
> diff -r 6f58de995103 -r 892049dfc1c9 tools/libxc/xc_memshr.c
> --- a/tools/libxc/xc_memshr.c
> +++ b/tools/libxc/xc_memshr.c
> @@ -88,8 +88,13 @@ int xc_memshr_nominate_gref(xc_interface
>  
>  int xc_memshr_share(xc_interface *xch,
>                      uint32_t source_domain,
> +                    uint64_t source_gfn,
>                      uint64_t source_handle,
> -                    uint64_t client_handle)
> +                    int source_is_gref,
> +                    uint32_t client_domain,
> +                    uint64_t client_gfn,
> +                    uint64_t client_handle,
> +                    int client_is_gref)
>  {
>      DECLARE_DOMCTL;
>      struct xen_domctl_mem_sharing_op *op;
> @@ -100,8 +105,20 @@ int xc_memshr_share(xc_interface *xch,
>      op = &(domctl.u.mem_sharing_op);
>      op->op = XEN_DOMCTL_MEM_EVENT_OP_SHARING_SHARE;
>      op->u.share.source_handle = source_handle;
> +    op->u.share.client_domain = (uint64_t) client_domain;

Why this disconnect between xc and hypercall API? 

>      op->u.share.client_handle = client_handle;
>  
> +    if (source_is_gref)
> +        XEN_DOMCTL_MEM_SHARING_FIELD_MAKE_GREF(

Is there an outstanding patch somewhere which adds this macro? I don't
see it in staging/xen-unstable.hg. Ah, yes, found it in another mail:

+#define XEN_DOMCTL_MEM_SHARING_FIELD_MAKE_GREF(field, val)  \
+    (field) = (XEN_DOMCTL_MEM_SHARING_FIELD_IS_GREF_FLAG | val)

Since this just adds a flag to the gfn why not just expose that to the
caller of this function rather than adding a separate flag as a
parameter?

> +                op->u.share.source_gfn, source_gfn);
> +    else
> +        op->u.share.source_gfn = source_gfn;
> +    if (client_is_gref)
> +        XEN_DOMCTL_MEM_SHARING_FIELD_MAKE_GREF(
> +                op->u.share.client_gfn, client_gfn);
> +    else
> +        op->u.share.client_gfn = client_gfn;
> +
>      return do_domctl(xch, &domctl);
>  }
>  
> diff -r 6f58de995103 -r 892049dfc1c9 tools/libxc/xenctrl.h
> --- a/tools/libxc/xenctrl.h
> +++ b/tools/libxc/xenctrl.h
> @@ -1893,8 +1893,13 @@ int xc_memshr_nominate_gref(xc_interface
>                              uint64_t *handle);
>  int xc_memshr_share(xc_interface *xch,
>                      uint32_t source_domain,
> +                    uint64_t source_gfn,
>                      uint64_t source_handle,
> -                    uint64_t client_handle);
> +                    int source_is_gref,
> +                    uint32_t client_domain,
> +                    uint64_t client_gfn,
> +                    uint64_t client_handle,
> +                    int dest_is_gref);
>  int xc_memshr_domain_resume(xc_interface *xch,
>                              uint32_t domid);
>  int xc_memshr_debug_gfn(xc_interface *xch,



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 10:07:08 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 10: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.xensource.com>)
	id 1Ra2mV-0005XK-R6; Mon, 12 Dec 2011 10:06:47 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1Ra2mU-0005XA-LV
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 10:06:46 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1323684352!5175804!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=0.6 required=7.0 tests=HTML_60_70,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1592 invoked from network); 12 Dec 2011 10:05:53 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Dec 2011 10:05:53 -0000
Received: by iaen33 with SMTP id n33so33031444iae.30
	for <xen-devel@lists.xensource.com>;
	Mon, 12 Dec 2011 02:05:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=/fcq7O8RRefXr8QBQgW7c6z04Bq/p7iMiUSV4y+hcgQ=;
	b=BtXh2rM3NfqDdevpe3nbbW1+RDXYfQtC7fpgSwoSa0YIxk9tTWUPF19cEKU0QRtnDg
	9SMHltmKkg7yf5Loi0FsBKrxSkdmat3DK/XGrVjscbN20M3xmxn5g4mOpQwelVqlholI
	mlfzN01CY/U2nVYCzWuTMA3vfNLViFB4z0W+g=
MIME-Version: 1.0
Received: by 10.50.12.197 with SMTP id a5mr5350829igc.6.1323684351575; Mon, 12
	Dec 2011 02:05:51 -0800 (PST)
Received: by 10.231.146.21 with HTTP; Mon, 12 Dec 2011 02:05:51 -0800 (PST)
In-Reply-To: <1323510857.14508.YahooMailClassic@web160903.mail.bf1.yahoo.com>
References: <1323510857.14508.YahooMailClassic@web160903.mail.bf1.yahoo.com>
Date: Mon, 12 Dec 2011 10:05:51 +0000
X-Google-Sender-Auth: e2ZWuTVyqVjsBn5qKd9HeSRsTw8
Message-ID: <CAFLBxZZp38E+gx42QTP5jqQV4EWYXk3Rx=kLk8NpZMMVETemuQ@mail.gmail.com>
From: George Dunlap <dunlapg@umich.edu>
To: jack nemati <hn_nemati1985@yahoo.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Xen shadow page table
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============2292055468902728965=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============2292055468902728965==
Content-Type: multipart/alternative; boundary=14dae934095b92065004b3e2479d

--14dae934095b92065004b3e2479d
Content-Type: text/plain; charset=ISO-8859-1

On Sat, Dec 10, 2011 at 9:54 AM, jack nemati <hn_nemati1985@yahoo.com>wrote:

> Dear friends,
>
> I'm working on Xen's Dom0, my question is how we can enable the shadow
> page table or hardware assistant page table for it (the Dom0). Thanks in
> advance.
>
> You can't enable HAP at the moment.  What do you want to do with shadow
pagetables?

 -George

--14dae934095b92065004b3e2479d
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Sat, Dec 10, 2011 at 9:54 AM, jack nemati <span dir=3D"ltr">&lt;<a href=
=3D"mailto:hn_nemati1985@yahoo.com">hn_nemati1985@yahoo.com</a>&gt;</span> =
wrote:<br><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);paddin=
g-left:1ex">
<table cellpadding=3D"0" cellspacing=3D"0" border=3D"0"><tbody><tr><td styl=
e=3D"font:inherit" valign=3D"top"><span style=3D"color:rgb(0,0,0);font-fami=
ly:Verdana,Arial,Helvetica,sans-serif;font-size:13px;font-style:normal;font=
-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal=
;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;ba=
ckground-color:rgb(255,255,255)">Dear friends,<br>
<br>I&#39;m working on Xen&#39;s Dom0, my question is how we can enable the=
 shadow page table or hardware assistant page table for it (the Dom0). Than=
ks in advance.<br><br></span></td></tr></tbody></table></blockquote><div>
You can&#39;t enable HAP at the moment.=A0 What do you want to do with shad=
ow pagetables?<br><br></div></div>=A0-George<br>

--14dae934095b92065004b3e2479d--


--===============2292055468902728965==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============2292055468902728965==--


From xen-devel-bounces@lists.xensource.com Mon Dec 12 10:07:08 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 10: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.xensource.com>)
	id 1Ra2mV-0005XK-R6; Mon, 12 Dec 2011 10:06:47 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1Ra2mU-0005XA-LV
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 10:06:46 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1323684352!5175804!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=0.6 required=7.0 tests=HTML_60_70,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1592 invoked from network); 12 Dec 2011 10:05:53 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Dec 2011 10:05:53 -0000
Received: by iaen33 with SMTP id n33so33031444iae.30
	for <xen-devel@lists.xensource.com>;
	Mon, 12 Dec 2011 02:05:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=/fcq7O8RRefXr8QBQgW7c6z04Bq/p7iMiUSV4y+hcgQ=;
	b=BtXh2rM3NfqDdevpe3nbbW1+RDXYfQtC7fpgSwoSa0YIxk9tTWUPF19cEKU0QRtnDg
	9SMHltmKkg7yf5Loi0FsBKrxSkdmat3DK/XGrVjscbN20M3xmxn5g4mOpQwelVqlholI
	mlfzN01CY/U2nVYCzWuTMA3vfNLViFB4z0W+g=
MIME-Version: 1.0
Received: by 10.50.12.197 with SMTP id a5mr5350829igc.6.1323684351575; Mon, 12
	Dec 2011 02:05:51 -0800 (PST)
Received: by 10.231.146.21 with HTTP; Mon, 12 Dec 2011 02:05:51 -0800 (PST)
In-Reply-To: <1323510857.14508.YahooMailClassic@web160903.mail.bf1.yahoo.com>
References: <1323510857.14508.YahooMailClassic@web160903.mail.bf1.yahoo.com>
Date: Mon, 12 Dec 2011 10:05:51 +0000
X-Google-Sender-Auth: e2ZWuTVyqVjsBn5qKd9HeSRsTw8
Message-ID: <CAFLBxZZp38E+gx42QTP5jqQV4EWYXk3Rx=kLk8NpZMMVETemuQ@mail.gmail.com>
From: George Dunlap <dunlapg@umich.edu>
To: jack nemati <hn_nemati1985@yahoo.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Xen shadow page table
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============2292055468902728965=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============2292055468902728965==
Content-Type: multipart/alternative; boundary=14dae934095b92065004b3e2479d

--14dae934095b92065004b3e2479d
Content-Type: text/plain; charset=ISO-8859-1

On Sat, Dec 10, 2011 at 9:54 AM, jack nemati <hn_nemati1985@yahoo.com>wrote:

> Dear friends,
>
> I'm working on Xen's Dom0, my question is how we can enable the shadow
> page table or hardware assistant page table for it (the Dom0). Thanks in
> advance.
>
> You can't enable HAP at the moment.  What do you want to do with shadow
pagetables?

 -George

--14dae934095b92065004b3e2479d
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Sat, Dec 10, 2011 at 9:54 AM, jack nemati <span dir=3D"ltr">&lt;<a href=
=3D"mailto:hn_nemati1985@yahoo.com">hn_nemati1985@yahoo.com</a>&gt;</span> =
wrote:<br><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);paddin=
g-left:1ex">
<table cellpadding=3D"0" cellspacing=3D"0" border=3D"0"><tbody><tr><td styl=
e=3D"font:inherit" valign=3D"top"><span style=3D"color:rgb(0,0,0);font-fami=
ly:Verdana,Arial,Helvetica,sans-serif;font-size:13px;font-style:normal;font=
-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal=
;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;ba=
ckground-color:rgb(255,255,255)">Dear friends,<br>
<br>I&#39;m working on Xen&#39;s Dom0, my question is how we can enable the=
 shadow page table or hardware assistant page table for it (the Dom0). Than=
ks in advance.<br><br></span></td></tr></tbody></table></blockquote><div>
You can&#39;t enable HAP at the moment.=A0 What do you want to do with shad=
ow pagetables?<br><br></div></div>=A0-George<br>

--14dae934095b92065004b3e2479d--


--===============2292055468902728965==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============2292055468902728965==--


From xen-devel-bounces@lists.xensource.com Mon Dec 12 10:15:30 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 10:15:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ra2tn-0005hy-DE; Mon, 12 Dec 2011 10:14:19 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <annie.li@oracle.com>) id 1Ra2tm-0005hr-GA
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 10:14:18 +0000
X-Env-Sender: annie.li@oracle.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1323684804!7091851!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQyODgzMQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6722 invoked from network); 12 Dec 2011 10:13:25 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-12.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 12 Dec 2011 10:13:25 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pBCADJ7q012007
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 12 Dec 2011 10:13:21 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pBCADHso007837
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 12 Dec 2011 10:13:18 GMT
Received: from abhmt105.oracle.com (abhmt105.oracle.com [141.146.116.57])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pBCADAot018385; Mon, 12 Dec 2011 04:13:10 -0600
Received: from annie2.cn.oracle.com.com (/10.182.37.169)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 12 Dec 2011 02:13:10 -0800
From: annie.li@oracle.com
To: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org,
	konrad.wilk@oracle.com, jeremy@goop.org, paul.durrant@citrix.com,
	Ian.Campbell@citrix.com
Date: Mon, 12 Dec 2011 18:13:12 +0800
Message-Id: <1323684792-5101-1-git-send-email-annie.li@oracle.com>
X-Mailer: git-send-email 1.7.6.4
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090202.4EE5D3C1.01C8,ss=1,re=0.000,fgs=0
Cc: kurt.hackel@oracle.com, annie.li@oracle.com
Subject: [Xen-devel] [PATCH V4 0/3] xen: patches for supporting sub-page and
	transitive grants
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi

Following patches introduce and implement interfaces for sub-page and transitive grants, and they are based on linux-next branch of linux/kernel/git/konrad/xen.git(3.2.0-rc2+). Sub-page and transitive grants are new types of grant table V2.

Descriptions for those patches:

Through sub-page grant table interfaces, a domain can grant another domain access to a range of bytes within a page, and Xen will then prevent the grantee domain accessing outside that range.  For obvious reasons, it isn't possible to map these grant references, and domains are expected to use the grant copy hypercall instead.

Through transitive grant interfaces,  a domain can create grant reference which redirects to another grant reference, so that any attempt to access the first grant reference will be redirected to the second one.  This is used to implement receiver-side copy on inter-domain traffic: rather than copying the packet in dom0, dom0 creates a transitive grant referencing the original transmit buffer, and passes that to the receiving domain.

Annie Li (3):
  xen/granttable: Improve comments for function pointers
  xen/granttable: Support sub-page grants
  xen/granttable: Support transitive grants

 drivers/xen/grant-table.c |  190 +++++++++++++++++++++++++++++++++++++++------
 include/xen/grant_table.h |   25 ++++++
 2 files changed, 191 insertions(+), 24 deletions(-)

Thanks,
Annie.
-- 
1.7.6.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 10:15:30 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 10:15:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ra2tn-0005hy-DE; Mon, 12 Dec 2011 10:14:19 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <annie.li@oracle.com>) id 1Ra2tm-0005hr-GA
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 10:14:18 +0000
X-Env-Sender: annie.li@oracle.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1323684804!7091851!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQyODgzMQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6722 invoked from network); 12 Dec 2011 10:13:25 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-12.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 12 Dec 2011 10:13:25 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pBCADJ7q012007
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 12 Dec 2011 10:13:21 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pBCADHso007837
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 12 Dec 2011 10:13:18 GMT
Received: from abhmt105.oracle.com (abhmt105.oracle.com [141.146.116.57])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pBCADAot018385; Mon, 12 Dec 2011 04:13:10 -0600
Received: from annie2.cn.oracle.com.com (/10.182.37.169)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 12 Dec 2011 02:13:10 -0800
From: annie.li@oracle.com
To: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org,
	konrad.wilk@oracle.com, jeremy@goop.org, paul.durrant@citrix.com,
	Ian.Campbell@citrix.com
Date: Mon, 12 Dec 2011 18:13:12 +0800
Message-Id: <1323684792-5101-1-git-send-email-annie.li@oracle.com>
X-Mailer: git-send-email 1.7.6.4
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090202.4EE5D3C1.01C8,ss=1,re=0.000,fgs=0
Cc: kurt.hackel@oracle.com, annie.li@oracle.com
Subject: [Xen-devel] [PATCH V4 0/3] xen: patches for supporting sub-page and
	transitive grants
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi

Following patches introduce and implement interfaces for sub-page and transitive grants, and they are based on linux-next branch of linux/kernel/git/konrad/xen.git(3.2.0-rc2+). Sub-page and transitive grants are new types of grant table V2.

Descriptions for those patches:

Through sub-page grant table interfaces, a domain can grant another domain access to a range of bytes within a page, and Xen will then prevent the grantee domain accessing outside that range.  For obvious reasons, it isn't possible to map these grant references, and domains are expected to use the grant copy hypercall instead.

Through transitive grant interfaces,  a domain can create grant reference which redirects to another grant reference, so that any attempt to access the first grant reference will be redirected to the second one.  This is used to implement receiver-side copy on inter-domain traffic: rather than copying the packet in dom0, dom0 creates a transitive grant referencing the original transmit buffer, and passes that to the receiving domain.

Annie Li (3):
  xen/granttable: Improve comments for function pointers
  xen/granttable: Support sub-page grants
  xen/granttable: Support transitive grants

 drivers/xen/grant-table.c |  190 +++++++++++++++++++++++++++++++++++++++------
 include/xen/grant_table.h |   25 ++++++
 2 files changed, 191 insertions(+), 24 deletions(-)

Thanks,
Annie.
-- 
1.7.6.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 10:15:38 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 10:15:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ra2uN-0005iw-OF; Mon, 12 Dec 2011 10:14:55 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <annie.li@oracle.com>) id 1Ra2uM-0005ih-U7
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 10:14:55 +0000
X-Env-Sender: annie.li@oracle.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1323684804!50382729!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDMxNzYw\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2548 invoked from network); 12 Dec 2011 10:13:25 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-6.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Dec 2011 10:13:25 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pBCADxU4029310
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 12 Dec 2011 10:13:59 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pBCADwOs026781
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 12 Dec 2011 10:13:58 GMT
Received: from abhmt107.oracle.com (abhmt107.oracle.com [141.146.116.59])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pBCADq2L027600; Mon, 12 Dec 2011 04:13:52 -0600
Received: from annie2.cn.oracle.com.com (/10.182.37.169)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 12 Dec 2011 02:13:52 -0800
From: annie.li@oracle.com
To: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org,
	konrad.wilk@oracle.com, jeremy@goop.org, paul.durrant@citrix.com,
	Ian.Campbell@citrix.com
Date: Mon, 12 Dec 2011 18:13:57 +0800
Message-Id: <1323684837-5140-1-git-send-email-annie.li@oracle.com>
X-Mailer: git-send-email 1.7.6.4
In-Reply-To: <1323684792-5101-1-git-send-email-annie.li@oracle.com>
References: <1323684792-5101-1-git-send-email-annie.li@oracle.com>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090209.4EE5D3E8.0071,ss=1,re=0.000,fgs=0
Cc: kurt.hackel@oracle.com, annie.li@oracle.com
Subject: [Xen-devel] [PATCH V4 1/3] xen/granttable: Improve comments for
	function pointers
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Signed-off-by: Annie Li <annie.li@oracle.com>
---
 drivers/xen/grant-table.c |   48 ++++++++++++++++++++++----------------------
 1 files changed, 24 insertions(+), 24 deletions(-)

diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
index bd325fd..1589ea1 100644
--- a/drivers/xen/grant-table.c
+++ b/drivers/xen/grant-table.c
@@ -76,50 +76,50 @@ static union {
 /*This is a structure of function pointers for grant table*/
 struct gnttab_ops {
 	/*
-	 * Mapping a list of frames for storing grant entries. First input
-	 * parameter is used to storing grant table address when grant table
-	 * being setup, second parameter is the number of frames to map grant
-	 * table. Returning GNTST_okay means success and negative value means
-	 * failure.
+	 * Mapping a list of frames for storing grant entries. Frames parameter
+	 * is used to store grant table address when grant table being setup,
+	 * nr_gframes is the number of frames to map grant table. Returning
+	 * GNTST_okay means success and negative value means failure.
 	 */
-	int (*map_frames)(unsigned long *, unsigned int);
+	int (*map_frames)(unsigned long *frames, unsigned int nr_gframes);
 	/*
 	 * Release a list of frames which are mapped in map_frames for grant
 	 * entry status.
 	 */
 	void (*unmap_frames)(void);
 	/*
-	 * Introducing a valid entry into the grant table, granting the frame
-	 * of this grant entry to domain for accessing, or transfering, or
-	 * transitively accessing. First input parameter is reference of this
-	 * introduced grant entry, second one is domid of granted domain, third
-	 * one is the frame to be granted, and the last one is status of the
-	 * grant entry to be updated.
+	 * Introducing a valid entry into the grant table, granting the frame of
+	 * this grant entry to domain for accessing or transfering. Ref
+	 * parameter is reference of this introduced grant entry, domid is id of
+	 * granted domain, frame is the page frame to be granted, and flags is
+	 * status of the grant entry to be updated.
 	 */
-	void (*update_entry)(grant_ref_t, domid_t, unsigned long, unsigned);
+	void (*update_entry)(grant_ref_t ref, domid_t domid,
+			     unsigned long frame, unsigned flags);
 	/*
-	 * Stop granting a grant entry to domain for accessing. First input
-	 * parameter is reference of a grant entry whose grant access will be
-	 * stopped, second one is not in use now. If the grant entry is
+	 * Stop granting a grant entry to domain for accessing. Ref parameter is
+	 * reference of a grant entry whose grant access will be stopped,
+	 * readonly is not in use in this function. If the grant entry is
 	 * currently mapped for reading or writing, just return failure(==0)
 	 * directly and don't tear down the grant access. Otherwise, stop grant
 	 * access for this entry and return success(==1).
 	 */
-	int (*end_foreign_access_ref)(grant_ref_t, int);
+	int (*end_foreign_access_ref)(grant_ref_t ref, int readonly);
 	/*
-	 * Stop granting a grant entry to domain for transfer. If tranfer has
-	 * not started, just reclaim the grant entry and return failure(==0).
-	 * Otherwise, wait for the transfer to complete and then return the
-	 * frame.
+	 * Stop granting a grant entry to domain for transfer. Ref parameter is
+	 * reference of a grant entry whose grant transfer will be stopped. If
+	 * tranfer has not started, just reclaim the grant entry and return
+	 * failure(==0). Otherwise, wait for the transfer to complete and then
+	 * return the frame.
 	 */
-	unsigned long (*end_foreign_transfer_ref)(grant_ref_t);
+	unsigned long (*end_foreign_transfer_ref)(grant_ref_t ref);
 	/*
-	 * Query the status of a grant entry. Input parameter is reference of
+	 * Query the status of a grant entry. Ref parameter is reference of
 	 * queried grant entry, return value is the status of queried entry.
 	 * Detailed status(writing/reading) can be gotten from the return value
 	 * by bit operations.
 	 */
-	int (*query_foreign_access)(grant_ref_t);
+	int (*query_foreign_access)(grant_ref_t ref);
 };
 
 static struct gnttab_ops *gnttab_interface;
-- 
1.7.6.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 10:15:38 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 10:15:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ra2uN-0005iw-OF; Mon, 12 Dec 2011 10:14:55 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <annie.li@oracle.com>) id 1Ra2uM-0005ih-U7
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 10:14:55 +0000
X-Env-Sender: annie.li@oracle.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1323684804!50382729!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDMxNzYw\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2548 invoked from network); 12 Dec 2011 10:13:25 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-6.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Dec 2011 10:13:25 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pBCADxU4029310
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 12 Dec 2011 10:13:59 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pBCADwOs026781
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 12 Dec 2011 10:13:58 GMT
Received: from abhmt107.oracle.com (abhmt107.oracle.com [141.146.116.59])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pBCADq2L027600; Mon, 12 Dec 2011 04:13:52 -0600
Received: from annie2.cn.oracle.com.com (/10.182.37.169)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 12 Dec 2011 02:13:52 -0800
From: annie.li@oracle.com
To: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org,
	konrad.wilk@oracle.com, jeremy@goop.org, paul.durrant@citrix.com,
	Ian.Campbell@citrix.com
Date: Mon, 12 Dec 2011 18:13:57 +0800
Message-Id: <1323684837-5140-1-git-send-email-annie.li@oracle.com>
X-Mailer: git-send-email 1.7.6.4
In-Reply-To: <1323684792-5101-1-git-send-email-annie.li@oracle.com>
References: <1323684792-5101-1-git-send-email-annie.li@oracle.com>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090209.4EE5D3E8.0071,ss=1,re=0.000,fgs=0
Cc: kurt.hackel@oracle.com, annie.li@oracle.com
Subject: [Xen-devel] [PATCH V4 1/3] xen/granttable: Improve comments for
	function pointers
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Signed-off-by: Annie Li <annie.li@oracle.com>
---
 drivers/xen/grant-table.c |   48 ++++++++++++++++++++++----------------------
 1 files changed, 24 insertions(+), 24 deletions(-)

diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
index bd325fd..1589ea1 100644
--- a/drivers/xen/grant-table.c
+++ b/drivers/xen/grant-table.c
@@ -76,50 +76,50 @@ static union {
 /*This is a structure of function pointers for grant table*/
 struct gnttab_ops {
 	/*
-	 * Mapping a list of frames for storing grant entries. First input
-	 * parameter is used to storing grant table address when grant table
-	 * being setup, second parameter is the number of frames to map grant
-	 * table. Returning GNTST_okay means success and negative value means
-	 * failure.
+	 * Mapping a list of frames for storing grant entries. Frames parameter
+	 * is used to store grant table address when grant table being setup,
+	 * nr_gframes is the number of frames to map grant table. Returning
+	 * GNTST_okay means success and negative value means failure.
 	 */
-	int (*map_frames)(unsigned long *, unsigned int);
+	int (*map_frames)(unsigned long *frames, unsigned int nr_gframes);
 	/*
 	 * Release a list of frames which are mapped in map_frames for grant
 	 * entry status.
 	 */
 	void (*unmap_frames)(void);
 	/*
-	 * Introducing a valid entry into the grant table, granting the frame
-	 * of this grant entry to domain for accessing, or transfering, or
-	 * transitively accessing. First input parameter is reference of this
-	 * introduced grant entry, second one is domid of granted domain, third
-	 * one is the frame to be granted, and the last one is status of the
-	 * grant entry to be updated.
+	 * Introducing a valid entry into the grant table, granting the frame of
+	 * this grant entry to domain for accessing or transfering. Ref
+	 * parameter is reference of this introduced grant entry, domid is id of
+	 * granted domain, frame is the page frame to be granted, and flags is
+	 * status of the grant entry to be updated.
 	 */
-	void (*update_entry)(grant_ref_t, domid_t, unsigned long, unsigned);
+	void (*update_entry)(grant_ref_t ref, domid_t domid,
+			     unsigned long frame, unsigned flags);
 	/*
-	 * Stop granting a grant entry to domain for accessing. First input
-	 * parameter is reference of a grant entry whose grant access will be
-	 * stopped, second one is not in use now. If the grant entry is
+	 * Stop granting a grant entry to domain for accessing. Ref parameter is
+	 * reference of a grant entry whose grant access will be stopped,
+	 * readonly is not in use in this function. If the grant entry is
 	 * currently mapped for reading or writing, just return failure(==0)
 	 * directly and don't tear down the grant access. Otherwise, stop grant
 	 * access for this entry and return success(==1).
 	 */
-	int (*end_foreign_access_ref)(grant_ref_t, int);
+	int (*end_foreign_access_ref)(grant_ref_t ref, int readonly);
 	/*
-	 * Stop granting a grant entry to domain for transfer. If tranfer has
-	 * not started, just reclaim the grant entry and return failure(==0).
-	 * Otherwise, wait for the transfer to complete and then return the
-	 * frame.
+	 * Stop granting a grant entry to domain for transfer. Ref parameter is
+	 * reference of a grant entry whose grant transfer will be stopped. If
+	 * tranfer has not started, just reclaim the grant entry and return
+	 * failure(==0). Otherwise, wait for the transfer to complete and then
+	 * return the frame.
 	 */
-	unsigned long (*end_foreign_transfer_ref)(grant_ref_t);
+	unsigned long (*end_foreign_transfer_ref)(grant_ref_t ref);
 	/*
-	 * Query the status of a grant entry. Input parameter is reference of
+	 * Query the status of a grant entry. Ref parameter is reference of
 	 * queried grant entry, return value is the status of queried entry.
 	 * Detailed status(writing/reading) can be gotten from the return value
 	 * by bit operations.
 	 */
-	int (*query_foreign_access)(grant_ref_t);
+	int (*query_foreign_access)(grant_ref_t ref);
 };
 
 static struct gnttab_ops *gnttab_interface;
-- 
1.7.6.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 10:15:39 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 10: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.xensource.com>)
	id 1Ra2uF-0005iH-QJ; Mon, 12 Dec 2011 10:14:47 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Ra2uE-0005i8-A2
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 10:14:46 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1323684833!7716639!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDc4NQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25889 invoked from network); 12 Dec 2011 10:13:53 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Dec 2011 10:13:53 -0000
X-IronPort-AV: E=Sophos;i="4.71,337,1320624000"; 
   d="scan'208";a="9411488"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Dec 2011 10:13:53 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 12 Dec 2011 10:13:52 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Date: Mon, 12 Dec 2011 10:13:52 +0000
In-Reply-To: <e16f5d2643c910d9b8c1.1323472553@xdev.gridcentric.ca>
References: <patchbomb.1323472550@xdev.gridcentric.ca>
	<e16f5d2643c910d9b8c1.1323472553@xdev.gridcentric.ca>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323684832.20077.120.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"andres@gridcentric.ca" <andres@gridcentric.ca>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Tim
	\(Xen.org\)" <tim@xen.org>, "adin@gridcentric.ca" <adin@gridcentric.ca>
Subject: Re: [Xen-devel] [PATCH 3 of 8] Tools: Update memshr tool to use new
	sharing API
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2011-12-09 at 23:15 +0000, Andres Lagar-Cavilla wrote:
> tools/blktap2/drivers/Makefile        |   2 +-
>  tools/blktap2/drivers/tapdisk-image.c |   2 +-
>  tools/blktap2/drivers/tapdisk-vbd.c   |   6 +++---
>  tools/blktap2/drivers/tapdisk.h       |   6 +++++-
>  tools/memshr/bidir-daemon.c           |  34 ++++++++++++++++++++++++----------
>  tools/memshr/bidir-hash.h             |  13 ++++++++-----
>  tools/memshr/interface.c              |  30 ++++++++++++++++++------------
>  tools/memshr/memshr.h                 |  11 +++++++++--
>  8 files changed, 69 insertions(+), 35 deletions(-)
> 
> 
> The only (in-tree, that we know of) consumer of the mem sharing API
> is the memshr tool (conditionally linked into blktap2). Update it to
> use the new API.

At least some of this must happen in the previous 2 patches so that the
build is not broken.

Is there any benefit to conditionally linking this stuff? Is it lots of
code or does it have some other undesirable impact when built even when
it is quiescent? Seems like a recipe for bit rot to not build it, plus
it makes it harder for people to consume via distro packages etc.

> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
> 
> diff -r 892049dfc1c9 -r e16f5d2643c9 tools/blktap2/drivers/Makefile
> --- a/tools/blktap2/drivers/Makefile
> +++ b/tools/blktap2/drivers/Makefile
> @@ -43,7 +43,7 @@ MEMSHR_DIR = $(XEN_ROOT)/tools/memshr
>  MEMSHRLIBS :=
>  ifeq ($(CONFIG_Linux), __fixme__)
>  CFLAGS += -DMEMSHR
> -MEMSHRLIBS += $(MEMSHR_DIR)/libmemshr.a
> +MEMSHRLIBS += -L$(XEN_ROOT)/tools/libxc -lxenctrl $(MEMSHR_DIR)/libmemshr.a

Please use $(LDLIBS_libxenctrl).

Is there a reason libmemshr is not a shared library?

>  endif
> 
>  ifeq ($(VHD_STATIC),y)
> diff -r 892049dfc1c9 -r e16f5d2643c9 tools/blktap2/drivers/tapdisk-image.c
> --- a/tools/blktap2/drivers/tapdisk-image.c
> +++ b/tools/blktap2/drivers/tapdisk-image.c
> @@ -60,7 +60,7 @@ tapdisk_image_allocate(const char *file,
>         image->storage   = storage;
>         image->private   = private;
>  #ifdef MEMSHR
> -       image->memshr_id = memshr_vbd_image_get(file);
> +       image->memshr_id = memshr_vbd_image_get((char *)file);

Casting away the const here raises a big red flag. Why is this
necessary? You should either fix the API of memshr_vbd_image_get or
tapdisk_image_allocate IMHO and propagate the change as necessary.
AFAICT there is no reason not to push the const'ness down into the
memshr API.

>  #endif
>         INIT_LIST_HEAD(&image->next);
> 
[...]

> diff -r 892049dfc1c9 -r e16f5d2643c9 tools/memshr/bidir-hash.h
> --- a/tools/memshr/bidir-hash.h
> +++ b/tools/memshr/bidir-hash.h
> @@ -81,15 +81,16 @@ static int fgprtshr_mfn_cmp(uint32_t m1,
>  #undef BIDIR_VALUE
>  #undef BIDIR_KEY_T
>  #undef BIDIR_VALUE_T
> +
>  /* TODO better hashes! */
>  static inline uint32_t blockshr_block_hash(vbdblk_t block)
>  {
>      return (uint32_t)(block.sec) ^ (uint32_t)(block.disk_id);
>  }
> 
> -static inline uint32_t blockshr_shrhnd_hash(uint64_t shrhnd)
> +static inline uint32_t blockshr_shrhnd_hash(share_tuple_t shrhnd)
>  {
> -    return (uint32_t)shrhnd;
> +    return ((uint32_t) shrhnd.handle);
>  }
> 
>  static inline int blockshr_block_cmp(vbdblk_t b1, vbdblk_t b2)
> @@ -97,15 +98,17 @@ static inline int blockshr_block_cmp(vbd
>      return (b1.sec == b2.sec) && (b1.disk_id == b2.disk_id);
>  }
> 
> -static inline int blockshr_shrhnd_cmp(uint64_t h1, uint64_t h2)
> +static inline int blockshr_shrhnd_cmp(share_tuple_t h1, share_tuple_t h2)
>  {
> -    return (h1 == h2);
> +    return ( (h1.domain == h2.domain) &&
> +             (h1.frame  == h2.frame) &&
> +             (h1.handle == h2.handle) );

memcmp?

>  }
>  #define BIDIR_NAME_PREFIX       blockshr
>  #define BIDIR_KEY               block
>  #define BIDIR_VALUE             shrhnd
>  #define BIDIR_KEY_T             vbdblk_t
> -#define BIDIR_VALUE_T           uint64_t
> +#define BIDIR_VALUE_T           share_tuple_t
>  #include "bidir-namedefs.h"
> 
>  #endif /* BLOCK_MAP */
> diff -r 892049dfc1c9 -r e16f5d2643c9 tools/memshr/interface.c
> --- a/tools/memshr/interface.c
> +++ b/tools/memshr/interface.c
> @@ -145,16 +145,17 @@ void memshr_vbd_image_put(uint16_t memsh
> 
>  int memshr_vbd_issue_ro_request(char *buf,
>                                  grant_ref_t gref,
> -                                uint16_t file_id,
> +                                uint16_t file_id,
>                                  uint64_t sec,
>                                  int secs,
> -                                uint64_t *hnd)
> +                                share_tuple_t *hnd)
>  {
>      vbdblk_t blk;
> -    uint64_t s_hnd, c_hnd;
> +    share_tuple_t source_st, client_st;
> +    uint64_t c_hnd;
>      int ret;
> 
> -    *hnd = 0;
> +    *hnd = (share_tuple_t){ 0, 0, 0 };
>      if(!vbd_info.enabled)
>          return -1;
> 
> @@ -169,26 +170,31 @@ int memshr_vbd_issue_ro_request(char *bu
>      /* If page couldn't be made sharable, we cannot do anything about it */
>      if(ret != 0)
>          return -3;
> -    *hnd = c_hnd;
> +
> +    *(&client_st) = (share_tuple_t){ vbd_info.domid, gref, c_hnd };

Is "*(&thing)" somehow different to "thing"?

> +    *hnd = client_st;
> 
>      /* Check if we've read matching disk block previously */
>      blk.sec     = sec;
>      blk.disk_id = file_id;
> -    if(blockshr_block_lookup(memshr.blks, blk, &s_hnd) > 0)
> +    if(blockshr_block_lookup(memshr.blks, blk, &source_st) > 0)
>      {
> -        ret = xc_memshr_share(vbd_info.xc_handle, s_hnd, c_hnd);
> +        ret = xc_memshr_share(vbd_info.xc_handle, source_st.domain, source_st.frame,
> +                                source_st.handle, 1, vbd_info.domid, gref, c_hnd, 1);

These 1's == is a gref but I only know that because I was just reading
that patch. If you decide you do need to keep the flag separate then
this would be better as a flags argument with named values
XC_MEMSHR_SOURCE_IS_GREF etc.

> diff -r 892049dfc1c9 -r e16f5d2643c9 tools/memshr/memshr.h
> --- a/tools/memshr/memshr.h
> +++ b/tools/memshr/memshr.h
> @@ -25,6 +25,13 @@
> 
>  typedef uint64_t xen_mfn_t;
> 
> +typedef struct share_tuple
> +{
> +    uint32_t domain;
> +    uint64_t frame;
> +    uint64_t handle;
> +} share_tuple_t;

Didn't you just add these as three separate parameters to
xc_memshr_share? Seems like this could be xc_memshr_tuple (or some
better name with more meaning than "tuple") and used throughout.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 10:15:39 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 10: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.xensource.com>)
	id 1Ra2uF-0005iH-QJ; Mon, 12 Dec 2011 10:14:47 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Ra2uE-0005i8-A2
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 10:14:46 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1323684833!7716639!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDc4NQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25889 invoked from network); 12 Dec 2011 10:13:53 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Dec 2011 10:13:53 -0000
X-IronPort-AV: E=Sophos;i="4.71,337,1320624000"; 
   d="scan'208";a="9411488"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Dec 2011 10:13:53 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 12 Dec 2011 10:13:52 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Date: Mon, 12 Dec 2011 10:13:52 +0000
In-Reply-To: <e16f5d2643c910d9b8c1.1323472553@xdev.gridcentric.ca>
References: <patchbomb.1323472550@xdev.gridcentric.ca>
	<e16f5d2643c910d9b8c1.1323472553@xdev.gridcentric.ca>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323684832.20077.120.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"andres@gridcentric.ca" <andres@gridcentric.ca>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Tim
	\(Xen.org\)" <tim@xen.org>, "adin@gridcentric.ca" <adin@gridcentric.ca>
Subject: Re: [Xen-devel] [PATCH 3 of 8] Tools: Update memshr tool to use new
	sharing API
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2011-12-09 at 23:15 +0000, Andres Lagar-Cavilla wrote:
> tools/blktap2/drivers/Makefile        |   2 +-
>  tools/blktap2/drivers/tapdisk-image.c |   2 +-
>  tools/blktap2/drivers/tapdisk-vbd.c   |   6 +++---
>  tools/blktap2/drivers/tapdisk.h       |   6 +++++-
>  tools/memshr/bidir-daemon.c           |  34 ++++++++++++++++++++++++----------
>  tools/memshr/bidir-hash.h             |  13 ++++++++-----
>  tools/memshr/interface.c              |  30 ++++++++++++++++++------------
>  tools/memshr/memshr.h                 |  11 +++++++++--
>  8 files changed, 69 insertions(+), 35 deletions(-)
> 
> 
> The only (in-tree, that we know of) consumer of the mem sharing API
> is the memshr tool (conditionally linked into blktap2). Update it to
> use the new API.

At least some of this must happen in the previous 2 patches so that the
build is not broken.

Is there any benefit to conditionally linking this stuff? Is it lots of
code or does it have some other undesirable impact when built even when
it is quiescent? Seems like a recipe for bit rot to not build it, plus
it makes it harder for people to consume via distro packages etc.

> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
> 
> diff -r 892049dfc1c9 -r e16f5d2643c9 tools/blktap2/drivers/Makefile
> --- a/tools/blktap2/drivers/Makefile
> +++ b/tools/blktap2/drivers/Makefile
> @@ -43,7 +43,7 @@ MEMSHR_DIR = $(XEN_ROOT)/tools/memshr
>  MEMSHRLIBS :=
>  ifeq ($(CONFIG_Linux), __fixme__)
>  CFLAGS += -DMEMSHR
> -MEMSHRLIBS += $(MEMSHR_DIR)/libmemshr.a
> +MEMSHRLIBS += -L$(XEN_ROOT)/tools/libxc -lxenctrl $(MEMSHR_DIR)/libmemshr.a

Please use $(LDLIBS_libxenctrl).

Is there a reason libmemshr is not a shared library?

>  endif
> 
>  ifeq ($(VHD_STATIC),y)
> diff -r 892049dfc1c9 -r e16f5d2643c9 tools/blktap2/drivers/tapdisk-image.c
> --- a/tools/blktap2/drivers/tapdisk-image.c
> +++ b/tools/blktap2/drivers/tapdisk-image.c
> @@ -60,7 +60,7 @@ tapdisk_image_allocate(const char *file,
>         image->storage   = storage;
>         image->private   = private;
>  #ifdef MEMSHR
> -       image->memshr_id = memshr_vbd_image_get(file);
> +       image->memshr_id = memshr_vbd_image_get((char *)file);

Casting away the const here raises a big red flag. Why is this
necessary? You should either fix the API of memshr_vbd_image_get or
tapdisk_image_allocate IMHO and propagate the change as necessary.
AFAICT there is no reason not to push the const'ness down into the
memshr API.

>  #endif
>         INIT_LIST_HEAD(&image->next);
> 
[...]

> diff -r 892049dfc1c9 -r e16f5d2643c9 tools/memshr/bidir-hash.h
> --- a/tools/memshr/bidir-hash.h
> +++ b/tools/memshr/bidir-hash.h
> @@ -81,15 +81,16 @@ static int fgprtshr_mfn_cmp(uint32_t m1,
>  #undef BIDIR_VALUE
>  #undef BIDIR_KEY_T
>  #undef BIDIR_VALUE_T
> +
>  /* TODO better hashes! */
>  static inline uint32_t blockshr_block_hash(vbdblk_t block)
>  {
>      return (uint32_t)(block.sec) ^ (uint32_t)(block.disk_id);
>  }
> 
> -static inline uint32_t blockshr_shrhnd_hash(uint64_t shrhnd)
> +static inline uint32_t blockshr_shrhnd_hash(share_tuple_t shrhnd)
>  {
> -    return (uint32_t)shrhnd;
> +    return ((uint32_t) shrhnd.handle);
>  }
> 
>  static inline int blockshr_block_cmp(vbdblk_t b1, vbdblk_t b2)
> @@ -97,15 +98,17 @@ static inline int blockshr_block_cmp(vbd
>      return (b1.sec == b2.sec) && (b1.disk_id == b2.disk_id);
>  }
> 
> -static inline int blockshr_shrhnd_cmp(uint64_t h1, uint64_t h2)
> +static inline int blockshr_shrhnd_cmp(share_tuple_t h1, share_tuple_t h2)
>  {
> -    return (h1 == h2);
> +    return ( (h1.domain == h2.domain) &&
> +             (h1.frame  == h2.frame) &&
> +             (h1.handle == h2.handle) );

memcmp?

>  }
>  #define BIDIR_NAME_PREFIX       blockshr
>  #define BIDIR_KEY               block
>  #define BIDIR_VALUE             shrhnd
>  #define BIDIR_KEY_T             vbdblk_t
> -#define BIDIR_VALUE_T           uint64_t
> +#define BIDIR_VALUE_T           share_tuple_t
>  #include "bidir-namedefs.h"
> 
>  #endif /* BLOCK_MAP */
> diff -r 892049dfc1c9 -r e16f5d2643c9 tools/memshr/interface.c
> --- a/tools/memshr/interface.c
> +++ b/tools/memshr/interface.c
> @@ -145,16 +145,17 @@ void memshr_vbd_image_put(uint16_t memsh
> 
>  int memshr_vbd_issue_ro_request(char *buf,
>                                  grant_ref_t gref,
> -                                uint16_t file_id,
> +                                uint16_t file_id,
>                                  uint64_t sec,
>                                  int secs,
> -                                uint64_t *hnd)
> +                                share_tuple_t *hnd)
>  {
>      vbdblk_t blk;
> -    uint64_t s_hnd, c_hnd;
> +    share_tuple_t source_st, client_st;
> +    uint64_t c_hnd;
>      int ret;
> 
> -    *hnd = 0;
> +    *hnd = (share_tuple_t){ 0, 0, 0 };
>      if(!vbd_info.enabled)
>          return -1;
> 
> @@ -169,26 +170,31 @@ int memshr_vbd_issue_ro_request(char *bu
>      /* If page couldn't be made sharable, we cannot do anything about it */
>      if(ret != 0)
>          return -3;
> -    *hnd = c_hnd;
> +
> +    *(&client_st) = (share_tuple_t){ vbd_info.domid, gref, c_hnd };

Is "*(&thing)" somehow different to "thing"?

> +    *hnd = client_st;
> 
>      /* Check if we've read matching disk block previously */
>      blk.sec     = sec;
>      blk.disk_id = file_id;
> -    if(blockshr_block_lookup(memshr.blks, blk, &s_hnd) > 0)
> +    if(blockshr_block_lookup(memshr.blks, blk, &source_st) > 0)
>      {
> -        ret = xc_memshr_share(vbd_info.xc_handle, s_hnd, c_hnd);
> +        ret = xc_memshr_share(vbd_info.xc_handle, source_st.domain, source_st.frame,
> +                                source_st.handle, 1, vbd_info.domid, gref, c_hnd, 1);

These 1's == is a gref but I only know that because I was just reading
that patch. If you decide you do need to keep the flag separate then
this would be better as a flags argument with named values
XC_MEMSHR_SOURCE_IS_GREF etc.

> diff -r 892049dfc1c9 -r e16f5d2643c9 tools/memshr/memshr.h
> --- a/tools/memshr/memshr.h
> +++ b/tools/memshr/memshr.h
> @@ -25,6 +25,13 @@
> 
>  typedef uint64_t xen_mfn_t;
> 
> +typedef struct share_tuple
> +{
> +    uint32_t domain;
> +    uint64_t frame;
> +    uint64_t handle;
> +} share_tuple_t;

Didn't you just add these as three separate parameters to
xc_memshr_share? Seems like this could be xc_memshr_tuple (or some
better name with more meaning than "tuple") and used throughout.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 10:15:59 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 10:15:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ra2vA-0005no-6q; Mon, 12 Dec 2011 10:15:44 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <annie.li@oracle.com>) id 1Ra2v8-0005m1-7S
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 10:15:42 +0000
X-Env-Sender: annie.li@oracle.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1323684887!2287405!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQyODgzMQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29491 invoked from network); 12 Dec 2011 10:14:49 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-8.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Dec 2011 10:14:49 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pBCAEirI013507
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 12 Dec 2011 10:14:45 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pBCAEhFp027952
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 12 Dec 2011 10:14:44 GMT
Received: from abhmt106.oracle.com (abhmt106.oracle.com [141.146.116.58])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pBCAEbPn009085; Mon, 12 Dec 2011 04:14:38 -0600
Received: from annie2.cn.oracle.com.com (/10.182.37.169)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 12 Dec 2011 02:14:37 -0800
From: annie.li@oracle.com
To: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org,
	konrad.wilk@oracle.com, jeremy@goop.org, paul.durrant@citrix.com,
	Ian.Campbell@citrix.com
Date: Mon, 12 Dec 2011 18:14:42 +0800
Message-Id: <1323684882-5171-1-git-send-email-annie.li@oracle.com>
X-Mailer: git-send-email 1.7.6.4
In-Reply-To: <1323684792-5101-1-git-send-email-annie.li@oracle.com>
References: <1323684792-5101-1-git-send-email-annie.li@oracle.com>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090207.4EE5D416.004F,ss=1,re=0.000,fgs=0
Cc: kurt.hackel@oracle.com, annie.li@oracle.com
Subject: [Xen-devel] [PATCH V4 2/3] xen/granttable: Support sub-page grants
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

    -- They can't be used to map the page (so can only be used in a GNTTABOP_copy
       hypercall).
    -- It's possible to grant access with a finer granularity than whole pages.
    -- Xen guarantees that they can be revoked quickly (a normal map grant can
       only be revoked with the cooperation of the domain which has been granted
       access).

Signed-off-by: Annie Li <annie.li@oracle.com>
---
 drivers/xen/grant-table.c |   72 +++++++++++++++++++++++++++++++++++++++++++++
 include/xen/grant_table.h |   13 ++++++++
 2 files changed, 85 insertions(+), 0 deletions(-)

diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
index 1589ea1..c8312c7 100644
--- a/drivers/xen/grant-table.c
+++ b/drivers/xen/grant-table.c
@@ -120,6 +120,17 @@ struct gnttab_ops {
 	 * by bit operations.
 	 */
 	int (*query_foreign_access)(grant_ref_t ref);
+	/*
+	 * Grant a domain to access a range of bytes within the page referred by
+	 * an available grant entry. Ref parameter is reference of a grant entry
+	 * which will be sub-page accessed, domid is id of grantee domain, frame
+	 * is frame address of subpage grant, flags is grant type and flag
+	 * information, page_off is offset of the range of bytes, and length is
+	 * length of bytes to be accessed.
+	 */
+	void (*update_subpage_entry)(grant_ref_t ref, domid_t domid,
+				     unsigned long frame, int flags,
+				     unsigned page_off, unsigned length);
 };
 
 static struct gnttab_ops *gnttab_interface;
@@ -261,6 +272,66 @@ int gnttab_grant_foreign_access(domid_t domid, unsigned long frame,
 }
 EXPORT_SYMBOL_GPL(gnttab_grant_foreign_access);
 
+void gnttab_update_subpage_entry_v2(grant_ref_t ref, domid_t domid,
+				    unsigned long frame, int flags,
+				    unsigned page_off,
+				    unsigned length)
+{
+	gnttab_shared.v2[ref].sub_page.frame = frame;
+	gnttab_shared.v2[ref].sub_page.page_off = page_off;
+	gnttab_shared.v2[ref].sub_page.length = length;
+	gnttab_shared.v2[ref].hdr.domid = domid;
+	wmb();
+	gnttab_shared.v2[ref].hdr.flags =
+				GTF_permit_access | GTF_sub_page | flags;
+}
+
+int gnttab_grant_foreign_access_subpage_ref(grant_ref_t ref, domid_t domid,
+					    unsigned long frame, int flags,
+					    unsigned page_off,
+					    unsigned length)
+{
+	if (flags & (GTF_accept_transfer | GTF_reading |
+		     GTF_writing | GTF_transitive))
+		return -EPERM;
+
+	if (gnttab_interface->update_subpage_entry == NULL)
+		return -ENOSYS;
+
+	gnttab_interface->update_subpage_entry(ref, domid, frame, flags,
+					       page_off, length);
+
+	return 0;
+}
+EXPORT_SYMBOL_GPL(gnttab_grant_foreign_access_subpage_ref);
+
+int gnttab_grant_foreign_access_subpage(domid_t domid, unsigned long frame,
+					int flags, unsigned page_off,
+					unsigned length)
+{
+	int ref, rc;
+
+	ref = get_free_entries(1);
+	if (unlikely(ref < 0))
+		return -ENOSPC;
+
+	rc = gnttab_grant_foreign_access_subpage_ref(ref, domid, frame, flags,
+						     page_off, length);
+	if (rc < 0) {
+		put_free_entry(ref);
+		return rc;
+	}
+
+	return ref;
+}
+EXPORT_SYMBOL_GPL(gnttab_grant_foreign_access_subpage);
+
+bool gnttab_subpage_grants_available(void)
+{
+	return gnttab_interface->update_subpage_entry != NULL;
+}
+EXPORT_SYMBOL_GPL(gnttab_subpage_grants_available);
+
 static int gnttab_query_foreign_access_v1(grant_ref_t ref)
 {
 	return gnttab_shared.v1[ref].flags & (GTF_reading|GTF_writing);
@@ -813,6 +884,7 @@ static struct gnttab_ops gnttab_v2_ops = {
 	.end_foreign_access_ref		= gnttab_end_foreign_access_ref_v2,
 	.end_foreign_transfer_ref	= gnttab_end_foreign_transfer_ref_v2,
 	.query_foreign_access		= gnttab_query_foreign_access_v2,
+	.update_subpage_entry		= gnttab_update_subpage_entry_v2,
 };
 
 static void gnttab_request_version(void)
diff --git a/include/xen/grant_table.h b/include/xen/grant_table.h
index fea4954..2b492b9 100644
--- a/include/xen/grant_table.h
+++ b/include/xen/grant_table.h
@@ -62,6 +62,15 @@ int gnttab_resume(void);
 
 int gnttab_grant_foreign_access(domid_t domid, unsigned long frame,
 				int readonly);
+int gnttab_grant_foreign_access_subpage(domid_t domid, unsigned long frame,
+					int flags, unsigned page_off,
+					unsigned length);
+
+/*
+ * Are sub-page grants available on this version of Xen?  Returns true if they
+ * are, and false if they're not.
+ */
+bool gnttab_subpage_grants_available(void);
 
 /*
  * End access through the given grant reference, iff the grant entry is no
@@ -108,6 +117,10 @@ void gnttab_cancel_free_callback(struct gnttab_free_callback *callback);
 
 void gnttab_grant_foreign_access_ref(grant_ref_t ref, domid_t domid,
 				     unsigned long frame, int readonly);
+int gnttab_grant_foreign_access_subpage_ref(grant_ref_t ref, domid_t domid,
+					    unsigned long frame, int flags,
+					    unsigned page_off,
+					    unsigned length);
 
 void gnttab_grant_foreign_transfer_ref(grant_ref_t, domid_t domid,
 				       unsigned long pfn);
-- 
1.7.6.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 10:15:59 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 10:15:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ra2vA-0005no-6q; Mon, 12 Dec 2011 10:15:44 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <annie.li@oracle.com>) id 1Ra2v8-0005m1-7S
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 10:15:42 +0000
X-Env-Sender: annie.li@oracle.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1323684887!2287405!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQyODgzMQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29491 invoked from network); 12 Dec 2011 10:14:49 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-8.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Dec 2011 10:14:49 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pBCAEirI013507
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 12 Dec 2011 10:14:45 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pBCAEhFp027952
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 12 Dec 2011 10:14:44 GMT
Received: from abhmt106.oracle.com (abhmt106.oracle.com [141.146.116.58])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pBCAEbPn009085; Mon, 12 Dec 2011 04:14:38 -0600
Received: from annie2.cn.oracle.com.com (/10.182.37.169)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 12 Dec 2011 02:14:37 -0800
From: annie.li@oracle.com
To: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org,
	konrad.wilk@oracle.com, jeremy@goop.org, paul.durrant@citrix.com,
	Ian.Campbell@citrix.com
Date: Mon, 12 Dec 2011 18:14:42 +0800
Message-Id: <1323684882-5171-1-git-send-email-annie.li@oracle.com>
X-Mailer: git-send-email 1.7.6.4
In-Reply-To: <1323684792-5101-1-git-send-email-annie.li@oracle.com>
References: <1323684792-5101-1-git-send-email-annie.li@oracle.com>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090207.4EE5D416.004F,ss=1,re=0.000,fgs=0
Cc: kurt.hackel@oracle.com, annie.li@oracle.com
Subject: [Xen-devel] [PATCH V4 2/3] xen/granttable: Support sub-page grants
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

    -- They can't be used to map the page (so can only be used in a GNTTABOP_copy
       hypercall).
    -- It's possible to grant access with a finer granularity than whole pages.
    -- Xen guarantees that they can be revoked quickly (a normal map grant can
       only be revoked with the cooperation of the domain which has been granted
       access).

Signed-off-by: Annie Li <annie.li@oracle.com>
---
 drivers/xen/grant-table.c |   72 +++++++++++++++++++++++++++++++++++++++++++++
 include/xen/grant_table.h |   13 ++++++++
 2 files changed, 85 insertions(+), 0 deletions(-)

diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
index 1589ea1..c8312c7 100644
--- a/drivers/xen/grant-table.c
+++ b/drivers/xen/grant-table.c
@@ -120,6 +120,17 @@ struct gnttab_ops {
 	 * by bit operations.
 	 */
 	int (*query_foreign_access)(grant_ref_t ref);
+	/*
+	 * Grant a domain to access a range of bytes within the page referred by
+	 * an available grant entry. Ref parameter is reference of a grant entry
+	 * which will be sub-page accessed, domid is id of grantee domain, frame
+	 * is frame address of subpage grant, flags is grant type and flag
+	 * information, page_off is offset of the range of bytes, and length is
+	 * length of bytes to be accessed.
+	 */
+	void (*update_subpage_entry)(grant_ref_t ref, domid_t domid,
+				     unsigned long frame, int flags,
+				     unsigned page_off, unsigned length);
 };
 
 static struct gnttab_ops *gnttab_interface;
@@ -261,6 +272,66 @@ int gnttab_grant_foreign_access(domid_t domid, unsigned long frame,
 }
 EXPORT_SYMBOL_GPL(gnttab_grant_foreign_access);
 
+void gnttab_update_subpage_entry_v2(grant_ref_t ref, domid_t domid,
+				    unsigned long frame, int flags,
+				    unsigned page_off,
+				    unsigned length)
+{
+	gnttab_shared.v2[ref].sub_page.frame = frame;
+	gnttab_shared.v2[ref].sub_page.page_off = page_off;
+	gnttab_shared.v2[ref].sub_page.length = length;
+	gnttab_shared.v2[ref].hdr.domid = domid;
+	wmb();
+	gnttab_shared.v2[ref].hdr.flags =
+				GTF_permit_access | GTF_sub_page | flags;
+}
+
+int gnttab_grant_foreign_access_subpage_ref(grant_ref_t ref, domid_t domid,
+					    unsigned long frame, int flags,
+					    unsigned page_off,
+					    unsigned length)
+{
+	if (flags & (GTF_accept_transfer | GTF_reading |
+		     GTF_writing | GTF_transitive))
+		return -EPERM;
+
+	if (gnttab_interface->update_subpage_entry == NULL)
+		return -ENOSYS;
+
+	gnttab_interface->update_subpage_entry(ref, domid, frame, flags,
+					       page_off, length);
+
+	return 0;
+}
+EXPORT_SYMBOL_GPL(gnttab_grant_foreign_access_subpage_ref);
+
+int gnttab_grant_foreign_access_subpage(domid_t domid, unsigned long frame,
+					int flags, unsigned page_off,
+					unsigned length)
+{
+	int ref, rc;
+
+	ref = get_free_entries(1);
+	if (unlikely(ref < 0))
+		return -ENOSPC;
+
+	rc = gnttab_grant_foreign_access_subpage_ref(ref, domid, frame, flags,
+						     page_off, length);
+	if (rc < 0) {
+		put_free_entry(ref);
+		return rc;
+	}
+
+	return ref;
+}
+EXPORT_SYMBOL_GPL(gnttab_grant_foreign_access_subpage);
+
+bool gnttab_subpage_grants_available(void)
+{
+	return gnttab_interface->update_subpage_entry != NULL;
+}
+EXPORT_SYMBOL_GPL(gnttab_subpage_grants_available);
+
 static int gnttab_query_foreign_access_v1(grant_ref_t ref)
 {
 	return gnttab_shared.v1[ref].flags & (GTF_reading|GTF_writing);
@@ -813,6 +884,7 @@ static struct gnttab_ops gnttab_v2_ops = {
 	.end_foreign_access_ref		= gnttab_end_foreign_access_ref_v2,
 	.end_foreign_transfer_ref	= gnttab_end_foreign_transfer_ref_v2,
 	.query_foreign_access		= gnttab_query_foreign_access_v2,
+	.update_subpage_entry		= gnttab_update_subpage_entry_v2,
 };
 
 static void gnttab_request_version(void)
diff --git a/include/xen/grant_table.h b/include/xen/grant_table.h
index fea4954..2b492b9 100644
--- a/include/xen/grant_table.h
+++ b/include/xen/grant_table.h
@@ -62,6 +62,15 @@ int gnttab_resume(void);
 
 int gnttab_grant_foreign_access(domid_t domid, unsigned long frame,
 				int readonly);
+int gnttab_grant_foreign_access_subpage(domid_t domid, unsigned long frame,
+					int flags, unsigned page_off,
+					unsigned length);
+
+/*
+ * Are sub-page grants available on this version of Xen?  Returns true if they
+ * are, and false if they're not.
+ */
+bool gnttab_subpage_grants_available(void);
 
 /*
  * End access through the given grant reference, iff the grant entry is no
@@ -108,6 +117,10 @@ void gnttab_cancel_free_callback(struct gnttab_free_callback *callback);
 
 void gnttab_grant_foreign_access_ref(grant_ref_t ref, domid_t domid,
 				     unsigned long frame, int readonly);
+int gnttab_grant_foreign_access_subpage_ref(grant_ref_t ref, domid_t domid,
+					    unsigned long frame, int flags,
+					    unsigned page_off,
+					    unsigned length);
 
 void gnttab_grant_foreign_transfer_ref(grant_ref_t, domid_t domid,
 				       unsigned long pfn);
-- 
1.7.6.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 10:16:18 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 10:16:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ra2vZ-0005sD-LS; Mon, 12 Dec 2011 10:16:09 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <annie.li@oracle.com>) id 1Ra2vX-0005rJ-EQ
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 10:16:07 +0000
X-Env-Sender: annie.li@oracle.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1323684892!51776868!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQyODgzMQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27313 invoked from network); 12 Dec 2011 10:14:53 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-13.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Dec 2011 10:14:53 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pBCAFC71014142
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 12 Dec 2011 10:15:13 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pBCAFBe9010849
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 12 Dec 2011 10:15:11 GMT
Received: from abhmt113.oracle.com (abhmt113.oracle.com [141.146.116.65])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pBCAF52w019618; Mon, 12 Dec 2011 04:15:05 -0600
Received: from annie2.cn.oracle.com.com (/10.182.37.169)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 12 Dec 2011 02:15:05 -0800
From: annie.li@oracle.com
To: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org,
	konrad.wilk@oracle.com, jeremy@goop.org, paul.durrant@citrix.com,
	Ian.Campbell@citrix.com
Date: Mon, 12 Dec 2011 18:15:07 +0800
Message-Id: <1323684907-5208-1-git-send-email-annie.li@oracle.com>
X-Mailer: git-send-email 1.7.6.4
In-Reply-To: <1323684792-5101-1-git-send-email-annie.li@oracle.com>
References: <1323684792-5101-1-git-send-email-annie.li@oracle.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090207.4EE5D431.00F7,ss=1,re=0.000,fgs=0
Cc: kurt.hackel@oracle.com, annie.li@oracle.com
Subject: [Xen-devel] [PATCH V4 3/3] xen/granttable: Support transitive grants
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

These allow a domain A which has been granted access on a page of domain B's
memory to issue domain C with a copy-grant on the same page.  This is useful
e.g. for forwarding packets between domains.

Signed-off-by: Annie Li <annie.li@oracle.com>
---
 drivers/xen/grant-table.c |   70 +++++++++++++++++++++++++++++++++++++++++++++
 include/xen/grant_table.h |   12 ++++++++
 2 files changed, 82 insertions(+), 0 deletions(-)

diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
index c8312c7..a3d0e1e 100644
--- a/drivers/xen/grant-table.c
+++ b/drivers/xen/grant-table.c
@@ -131,6 +131,18 @@ struct gnttab_ops {
 	void (*update_subpage_entry)(grant_ref_t ref, domid_t domid,
 				     unsigned long frame, int flags,
 				     unsigned page_off, unsigned length);
+	/*
+	 * Redirect an available grant entry on domain A to another grant
+	 * reference of domain B, then allow domain C to use grant reference
+	 * of domain B transitively. Ref parameter is an available grant entry
+	 * reference on domain A, domid is id of domain C which accesses grant
+	 * entry transitively, flags is grant type and flag information,
+	 * trans_domid is id of domain B whose grant entry is finally accessed
+	 * transitively, trans_gref is grant entry transitive reference of
+	 * domain B.
+	 */
+	void (*update_trans_entry)(grant_ref_t ref, domid_t domid, int flags,
+				   domid_t trans_domid, grant_ref_t trans_gref);
 };
 
 static struct gnttab_ops *gnttab_interface;
@@ -332,6 +344,63 @@ bool gnttab_subpage_grants_available(void)
 }
 EXPORT_SYMBOL_GPL(gnttab_subpage_grants_available);
 
+void gnttab_update_trans_entry_v2(grant_ref_t ref, domid_t domid,
+				  int flags, domid_t trans_domid,
+				  grant_ref_t trans_gref)
+{
+	gnttab_shared.v2[ref].transitive.trans_domid = trans_domid;
+	gnttab_shared.v2[ref].transitive.gref = trans_gref;
+	gnttab_shared.v2[ref].hdr.domid = domid;
+	wmb();
+	gnttab_shared.v2[ref].hdr.flags =
+				GTF_permit_access | GTF_transitive | flags;
+}
+
+int gnttab_grant_foreign_access_trans_ref(grant_ref_t ref, domid_t domid,
+					  int flags, domid_t trans_domid,
+					  grant_ref_t trans_gref)
+{
+	if (flags & (GTF_accept_transfer | GTF_reading |
+		     GTF_writing | GTF_sub_page))
+		return -EPERM;
+
+	if (gnttab_interface->update_trans_entry == NULL)
+		return -ENOSYS;
+
+	gnttab_interface->update_trans_entry(ref, domid, flags, trans_domid,
+					     trans_gref);
+
+	return 0;
+}
+EXPORT_SYMBOL_GPL(gnttab_grant_foreign_access_trans_ref);
+
+int gnttab_grant_foreign_access_trans(domid_t domid, int flags,
+				      domid_t trans_domid,
+				      grant_ref_t trans_gref)
+{
+	int ref, rc;
+
+	ref = get_free_entries(1);
+	if (unlikely(ref < 0))
+		return -ENOSPC;
+
+	rc = gnttab_grant_foreign_access_trans_ref(ref, domid, flags,
+						   trans_domid, trans_gref);
+	if (rc < 0) {
+		put_free_entry(ref);
+		return rc;
+	}
+
+	return ref;
+}
+EXPORT_SYMBOL_GPL(gnttab_grant_foreign_access_trans);
+
+bool gnttab_trans_grants_available(void)
+{
+	return gnttab_interface->update_trans_entry != NULL;
+}
+EXPORT_SYMBOL_GPL(gnttab_trans_grants_available);
+
 static int gnttab_query_foreign_access_v1(grant_ref_t ref)
 {
 	return gnttab_shared.v1[ref].flags & (GTF_reading|GTF_writing);
@@ -885,6 +954,7 @@ static struct gnttab_ops gnttab_v2_ops = {
 	.end_foreign_transfer_ref	= gnttab_end_foreign_transfer_ref_v2,
 	.query_foreign_access		= gnttab_query_foreign_access_v2,
 	.update_subpage_entry		= gnttab_update_subpage_entry_v2,
+	.update_trans_entry		= gnttab_update_trans_entry_v2,
 };
 
 static void gnttab_request_version(void)
diff --git a/include/xen/grant_table.h b/include/xen/grant_table.h
index 2b492b9..f1e17b7 100644
--- a/include/xen/grant_table.h
+++ b/include/xen/grant_table.h
@@ -65,6 +65,9 @@ int gnttab_grant_foreign_access(domid_t domid, unsigned long frame,
 int gnttab_grant_foreign_access_subpage(domid_t domid, unsigned long frame,
 					int flags, unsigned page_off,
 					unsigned length);
+int gnttab_grant_foreign_access_trans(domid_t domid, int flags,
+				      domid_t trans_domid,
+				      grant_ref_t trans_gref);
 
 /*
  * Are sub-page grants available on this version of Xen?  Returns true if they
@@ -73,6 +76,12 @@ int gnttab_grant_foreign_access_subpage(domid_t domid, unsigned long frame,
 bool gnttab_subpage_grants_available(void);
 
 /*
+ * Are transitive grants available on this version of Xen?  Returns true if they
+ * are, and false if they're not.
+ */
+bool gnttab_trans_grants_available(void);
+
+/*
  * End access through the given grant reference, iff the grant entry is no
  * longer in use.  Return 1 if the grant entry was freed, 0 if it is still in
  * use.
@@ -121,6 +130,9 @@ int gnttab_grant_foreign_access_subpage_ref(grant_ref_t ref, domid_t domid,
 					    unsigned long frame, int flags,
 					    unsigned page_off,
 					    unsigned length);
+int gnttab_grant_foreign_access_trans_ref(grant_ref_t ref, domid_t domid,
+					  int flags, domid_t trans_domid,
+					  grant_ref_t trans_gref);
 
 void gnttab_grant_foreign_transfer_ref(grant_ref_t, domid_t domid,
 				       unsigned long pfn);
-- 
1.7.6.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 10:16:18 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 10:16:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ra2vZ-0005sD-LS; Mon, 12 Dec 2011 10:16:09 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <annie.li@oracle.com>) id 1Ra2vX-0005rJ-EQ
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 10:16:07 +0000
X-Env-Sender: annie.li@oracle.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1323684892!51776868!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQyODgzMQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27313 invoked from network); 12 Dec 2011 10:14:53 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-13.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Dec 2011 10:14:53 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pBCAFC71014142
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 12 Dec 2011 10:15:13 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pBCAFBe9010849
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 12 Dec 2011 10:15:11 GMT
Received: from abhmt113.oracle.com (abhmt113.oracle.com [141.146.116.65])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pBCAF52w019618; Mon, 12 Dec 2011 04:15:05 -0600
Received: from annie2.cn.oracle.com.com (/10.182.37.169)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 12 Dec 2011 02:15:05 -0800
From: annie.li@oracle.com
To: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org,
	konrad.wilk@oracle.com, jeremy@goop.org, paul.durrant@citrix.com,
	Ian.Campbell@citrix.com
Date: Mon, 12 Dec 2011 18:15:07 +0800
Message-Id: <1323684907-5208-1-git-send-email-annie.li@oracle.com>
X-Mailer: git-send-email 1.7.6.4
In-Reply-To: <1323684792-5101-1-git-send-email-annie.li@oracle.com>
References: <1323684792-5101-1-git-send-email-annie.li@oracle.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090207.4EE5D431.00F7,ss=1,re=0.000,fgs=0
Cc: kurt.hackel@oracle.com, annie.li@oracle.com
Subject: [Xen-devel] [PATCH V4 3/3] xen/granttable: Support transitive grants
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

These allow a domain A which has been granted access on a page of domain B's
memory to issue domain C with a copy-grant on the same page.  This is useful
e.g. for forwarding packets between domains.

Signed-off-by: Annie Li <annie.li@oracle.com>
---
 drivers/xen/grant-table.c |   70 +++++++++++++++++++++++++++++++++++++++++++++
 include/xen/grant_table.h |   12 ++++++++
 2 files changed, 82 insertions(+), 0 deletions(-)

diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
index c8312c7..a3d0e1e 100644
--- a/drivers/xen/grant-table.c
+++ b/drivers/xen/grant-table.c
@@ -131,6 +131,18 @@ struct gnttab_ops {
 	void (*update_subpage_entry)(grant_ref_t ref, domid_t domid,
 				     unsigned long frame, int flags,
 				     unsigned page_off, unsigned length);
+	/*
+	 * Redirect an available grant entry on domain A to another grant
+	 * reference of domain B, then allow domain C to use grant reference
+	 * of domain B transitively. Ref parameter is an available grant entry
+	 * reference on domain A, domid is id of domain C which accesses grant
+	 * entry transitively, flags is grant type and flag information,
+	 * trans_domid is id of domain B whose grant entry is finally accessed
+	 * transitively, trans_gref is grant entry transitive reference of
+	 * domain B.
+	 */
+	void (*update_trans_entry)(grant_ref_t ref, domid_t domid, int flags,
+				   domid_t trans_domid, grant_ref_t trans_gref);
 };
 
 static struct gnttab_ops *gnttab_interface;
@@ -332,6 +344,63 @@ bool gnttab_subpage_grants_available(void)
 }
 EXPORT_SYMBOL_GPL(gnttab_subpage_grants_available);
 
+void gnttab_update_trans_entry_v2(grant_ref_t ref, domid_t domid,
+				  int flags, domid_t trans_domid,
+				  grant_ref_t trans_gref)
+{
+	gnttab_shared.v2[ref].transitive.trans_domid = trans_domid;
+	gnttab_shared.v2[ref].transitive.gref = trans_gref;
+	gnttab_shared.v2[ref].hdr.domid = domid;
+	wmb();
+	gnttab_shared.v2[ref].hdr.flags =
+				GTF_permit_access | GTF_transitive | flags;
+}
+
+int gnttab_grant_foreign_access_trans_ref(grant_ref_t ref, domid_t domid,
+					  int flags, domid_t trans_domid,
+					  grant_ref_t trans_gref)
+{
+	if (flags & (GTF_accept_transfer | GTF_reading |
+		     GTF_writing | GTF_sub_page))
+		return -EPERM;
+
+	if (gnttab_interface->update_trans_entry == NULL)
+		return -ENOSYS;
+
+	gnttab_interface->update_trans_entry(ref, domid, flags, trans_domid,
+					     trans_gref);
+
+	return 0;
+}
+EXPORT_SYMBOL_GPL(gnttab_grant_foreign_access_trans_ref);
+
+int gnttab_grant_foreign_access_trans(domid_t domid, int flags,
+				      domid_t trans_domid,
+				      grant_ref_t trans_gref)
+{
+	int ref, rc;
+
+	ref = get_free_entries(1);
+	if (unlikely(ref < 0))
+		return -ENOSPC;
+
+	rc = gnttab_grant_foreign_access_trans_ref(ref, domid, flags,
+						   trans_domid, trans_gref);
+	if (rc < 0) {
+		put_free_entry(ref);
+		return rc;
+	}
+
+	return ref;
+}
+EXPORT_SYMBOL_GPL(gnttab_grant_foreign_access_trans);
+
+bool gnttab_trans_grants_available(void)
+{
+	return gnttab_interface->update_trans_entry != NULL;
+}
+EXPORT_SYMBOL_GPL(gnttab_trans_grants_available);
+
 static int gnttab_query_foreign_access_v1(grant_ref_t ref)
 {
 	return gnttab_shared.v1[ref].flags & (GTF_reading|GTF_writing);
@@ -885,6 +954,7 @@ static struct gnttab_ops gnttab_v2_ops = {
 	.end_foreign_transfer_ref	= gnttab_end_foreign_transfer_ref_v2,
 	.query_foreign_access		= gnttab_query_foreign_access_v2,
 	.update_subpage_entry		= gnttab_update_subpage_entry_v2,
+	.update_trans_entry		= gnttab_update_trans_entry_v2,
 };
 
 static void gnttab_request_version(void)
diff --git a/include/xen/grant_table.h b/include/xen/grant_table.h
index 2b492b9..f1e17b7 100644
--- a/include/xen/grant_table.h
+++ b/include/xen/grant_table.h
@@ -65,6 +65,9 @@ int gnttab_grant_foreign_access(domid_t domid, unsigned long frame,
 int gnttab_grant_foreign_access_subpage(domid_t domid, unsigned long frame,
 					int flags, unsigned page_off,
 					unsigned length);
+int gnttab_grant_foreign_access_trans(domid_t domid, int flags,
+				      domid_t trans_domid,
+				      grant_ref_t trans_gref);
 
 /*
  * Are sub-page grants available on this version of Xen?  Returns true if they
@@ -73,6 +76,12 @@ int gnttab_grant_foreign_access_subpage(domid_t domid, unsigned long frame,
 bool gnttab_subpage_grants_available(void);
 
 /*
+ * Are transitive grants available on this version of Xen?  Returns true if they
+ * are, and false if they're not.
+ */
+bool gnttab_trans_grants_available(void);
+
+/*
  * End access through the given grant reference, iff the grant entry is no
  * longer in use.  Return 1 if the grant entry was freed, 0 if it is still in
  * use.
@@ -121,6 +130,9 @@ int gnttab_grant_foreign_access_subpage_ref(grant_ref_t ref, domid_t domid,
 					    unsigned long frame, int flags,
 					    unsigned page_off,
 					    unsigned length);
+int gnttab_grant_foreign_access_trans_ref(grant_ref_t ref, domid_t domid,
+					  int flags, domid_t trans_domid,
+					  grant_ref_t trans_gref);
 
 void gnttab_grant_foreign_transfer_ref(grant_ref_t, domid_t domid,
 				       unsigned long pfn);
-- 
1.7.6.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 10:28:02 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 10: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.xensource.com>)
	id 1Ra36q-0006UH-U5; Mon, 12 Dec 2011 10:27:48 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Ra36q-0006UC-0B
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 10:27:48 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1323685612!5185426!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDc4NQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32113 invoked from network); 12 Dec 2011 10:26:53 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Dec 2011 10:26:53 -0000
X-IronPort-AV: E=Sophos;i="4.71,337,1320624000"; 
   d="scan'208";a="9411888"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Dec 2011 10:26:51 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 12 Dec 2011 10:26:51 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Date: Mon, 12 Dec 2011 10:26:51 +0000
In-Reply-To: <a22140d92931036b591c.1323472554@xdev.gridcentric.ca>
References: <patchbomb.1323472550@xdev.gridcentric.ca>
	<a22140d92931036b591c.1323472554@xdev.gridcentric.ca>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323685611.20077.124.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"andres@gridcentric.ca" <andres@gridcentric.ca>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Tim
	\(Xen.org\)" <tim@xen.org>, "adin@gridcentric.ca" <adin@gridcentric.ca>
Subject: Re: [Xen-devel] [PATCH 4 of 8] Tools: Add a sharing command to xl
 for information about shared pages
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2011-12-09 at 23:15 +0000, Andres Lagar-Cavilla wrote:
> docs/man/xl.pod.1         |  18 +++++++++
>  tools/libxl/xl.h          |   1 +
>  tools/libxl/xl_cmdimpl.c  |  85 +++++++++++++++++++++++++++++++++++++++++++++++
>  tools/libxl/xl_cmdtable.c |   6 +++
>  4 files changed, 110 insertions(+), 0 deletions(-)
> 
> 
> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
> Signed-off-by: Adin Scannell <adin@scannell.ca>
> 
> diff -r e16f5d2643c9 -r a22140d92931 docs/man/xl.pod.1
> --- a/docs/man/xl.pod.1
> +++ b/docs/man/xl.pod.1
> @@ -280,6 +280,24 @@ B<Warning:> There is no good way to know
>  mem-set will make a domain unstable and cause it to crash.  Be very
>  careful when using this command on running domains.
>  
> +=item B<sharing> [I<-t> I<--totals>] [I<domain-id>]
[...]
>  =item B<migrate> [I<OPTIONS>] I<domain-id> I<host>

The commands are (supposed to be) alphabetical within each section.

[...]
> diff -r e16f5d2643c9 -r a22140d92931 tools/libxl/xl_cmdimpl.c
> --- a/tools/libxl/xl_cmdimpl.c
> +++ b/tools/libxl/xl_cmdimpl.c
> @@ -3755,6 +3755,91 @@ int main_info(int argc, char **argv)
[...]
> +int main_sharing(int argc, char **argv)
> +{
> +    int opt;
> +    int option_index = 0;
> +    static struct option long_options[] = {
> +        {"help", 0, 0, 'h'},
> +        {"totals", 0, 0, 't'},
> +        {0, 0, 0, 0}
> +    };
> +    int totals = 0;
> +
> +    libxl_dominfo info_buf;
> +    libxl_dominfo *info, *info_free=0;
> +    int nb_domain, rc;
> +
> +    while ((opt = getopt_long(argc, argv, "ht", long_options, &option_index)) != -1) {

Please use def_getopt().

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 10:28:02 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 10: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.xensource.com>)
	id 1Ra36q-0006UH-U5; Mon, 12 Dec 2011 10:27:48 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Ra36q-0006UC-0B
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 10:27:48 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1323685612!5185426!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDc4NQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32113 invoked from network); 12 Dec 2011 10:26:53 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Dec 2011 10:26:53 -0000
X-IronPort-AV: E=Sophos;i="4.71,337,1320624000"; 
   d="scan'208";a="9411888"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Dec 2011 10:26:51 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 12 Dec 2011 10:26:51 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Date: Mon, 12 Dec 2011 10:26:51 +0000
In-Reply-To: <a22140d92931036b591c.1323472554@xdev.gridcentric.ca>
References: <patchbomb.1323472550@xdev.gridcentric.ca>
	<a22140d92931036b591c.1323472554@xdev.gridcentric.ca>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323685611.20077.124.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"andres@gridcentric.ca" <andres@gridcentric.ca>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Tim
	\(Xen.org\)" <tim@xen.org>, "adin@gridcentric.ca" <adin@gridcentric.ca>
Subject: Re: [Xen-devel] [PATCH 4 of 8] Tools: Add a sharing command to xl
 for information about shared pages
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2011-12-09 at 23:15 +0000, Andres Lagar-Cavilla wrote:
> docs/man/xl.pod.1         |  18 +++++++++
>  tools/libxl/xl.h          |   1 +
>  tools/libxl/xl_cmdimpl.c  |  85 +++++++++++++++++++++++++++++++++++++++++++++++
>  tools/libxl/xl_cmdtable.c |   6 +++
>  4 files changed, 110 insertions(+), 0 deletions(-)
> 
> 
> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
> Signed-off-by: Adin Scannell <adin@scannell.ca>
> 
> diff -r e16f5d2643c9 -r a22140d92931 docs/man/xl.pod.1
> --- a/docs/man/xl.pod.1
> +++ b/docs/man/xl.pod.1
> @@ -280,6 +280,24 @@ B<Warning:> There is no good way to know
>  mem-set will make a domain unstable and cause it to crash.  Be very
>  careful when using this command on running domains.
>  
> +=item B<sharing> [I<-t> I<--totals>] [I<domain-id>]
[...]
>  =item B<migrate> [I<OPTIONS>] I<domain-id> I<host>

The commands are (supposed to be) alphabetical within each section.

[...]
> diff -r e16f5d2643c9 -r a22140d92931 tools/libxl/xl_cmdimpl.c
> --- a/tools/libxl/xl_cmdimpl.c
> +++ b/tools/libxl/xl_cmdimpl.c
> @@ -3755,6 +3755,91 @@ int main_info(int argc, char **argv)
[...]
> +int main_sharing(int argc, char **argv)
> +{
> +    int opt;
> +    int option_index = 0;
> +    static struct option long_options[] = {
> +        {"help", 0, 0, 'h'},
> +        {"totals", 0, 0, 't'},
> +        {0, 0, 0, 0}
> +    };
> +    int totals = 0;
> +
> +    libxl_dominfo info_buf;
> +    libxl_dominfo *info, *info_free=0;
> +    int nb_domain, rc;
> +
> +    while ((opt = getopt_long(argc, argv, "ht", long_options, &option_index)) != -1) {

Please use def_getopt().

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 10:40:32 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 10:40:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ra3Iq-0006gt-7C; Mon, 12 Dec 2011 10:40:12 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Ra3Io-0006go-Dm
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 10:40:10 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1323686357!2292244!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDc4NQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11962 invoked from network); 12 Dec 2011 10:39:17 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Dec 2011 10:39:17 -0000
X-IronPort-AV: E=Sophos;i="4.71,337,1320624000"; 
   d="scan'208";a="9412359"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Dec 2011 10:39:16 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 12 Dec 2011 10:39:16 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Date: Mon, 12 Dec 2011 10:39:16 +0000
In-Reply-To: <6e8b8fb2c8b23e39d910.1323472555@xdev.gridcentric.ca>
References: <patchbomb.1323472550@xdev.gridcentric.ca>
	<6e8b8fb2c8b23e39d910.1323472555@xdev.gridcentric.ca>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323686356.20077.133.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"andres@gridcentric.ca" <andres@gridcentric.ca>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Tim
	\(Xen.org\)" <tim@xen.org>, "adin@gridcentric.ca" <adin@gridcentric.ca>
Subject: Re: [Xen-devel] [PATCH 5 of 8] Tools: Expose to libxc the total
 number of shared frames and space saved
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2011-12-09 at 23:15 +0000, Andres Lagar-Cavilla wrote:
> tools/libxc/xc_private.c |  10 ++++++++++
>  tools/libxc/xenctrl.h    |   4 ++++
>  2 files changed, 14 insertions(+), 0 deletions(-)
> 
> 
> Signed-off-by: Adin Scannell <adin@scannell.ca>

If you pass on someone elses work I think it is normal to add your own
Signed-off-by (per DCO clause (c)).

[...]
> diff -r a22140d92931 -r 6e8b8fb2c8b2 tools/libxc/xenctrl.h
> --- a/tools/libxc/xenctrl.h
> +++ b/tools/libxc/xenctrl.h
> @@ -1227,6 +1227,10 @@ int xc_mmuext_op(xc_interface *xch, stru
>  /* System wide memory properties */
>  long xc_maximum_ram_page(xc_interface *xch);
>  
> +long xc_sharing_freed_pages(xc_interface *xch);
> +
> +long xc_sharing_used_frames(xc_interface *xch);

A quick comment on what each function returns might be worthwhile, maybe
it's obvious to someone who knows the sharing stuff, but e.g. does
"used" mean used right now or does it mean have ever been used? I
suppose "freed" must be historical.

Also why pages vs frames? The underlying domctl is always pages.

Ian.

> +
>  /* Get current total pages allocated to a domain. */
>  long xc_get_tot_pages(xc_interface *xch, uint32_t domid);
>  



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 10:40:32 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 10:40:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ra3Iq-0006gt-7C; Mon, 12 Dec 2011 10:40:12 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Ra3Io-0006go-Dm
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 10:40:10 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1323686357!2292244!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDc4NQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11962 invoked from network); 12 Dec 2011 10:39:17 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Dec 2011 10:39:17 -0000
X-IronPort-AV: E=Sophos;i="4.71,337,1320624000"; 
   d="scan'208";a="9412359"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Dec 2011 10:39:16 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 12 Dec 2011 10:39:16 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Date: Mon, 12 Dec 2011 10:39:16 +0000
In-Reply-To: <6e8b8fb2c8b23e39d910.1323472555@xdev.gridcentric.ca>
References: <patchbomb.1323472550@xdev.gridcentric.ca>
	<6e8b8fb2c8b23e39d910.1323472555@xdev.gridcentric.ca>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323686356.20077.133.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"andres@gridcentric.ca" <andres@gridcentric.ca>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Tim
	\(Xen.org\)" <tim@xen.org>, "adin@gridcentric.ca" <adin@gridcentric.ca>
Subject: Re: [Xen-devel] [PATCH 5 of 8] Tools: Expose to libxc the total
 number of shared frames and space saved
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2011-12-09 at 23:15 +0000, Andres Lagar-Cavilla wrote:
> tools/libxc/xc_private.c |  10 ++++++++++
>  tools/libxc/xenctrl.h    |   4 ++++
>  2 files changed, 14 insertions(+), 0 deletions(-)
> 
> 
> Signed-off-by: Adin Scannell <adin@scannell.ca>

If you pass on someone elses work I think it is normal to add your own
Signed-off-by (per DCO clause (c)).

[...]
> diff -r a22140d92931 -r 6e8b8fb2c8b2 tools/libxc/xenctrl.h
> --- a/tools/libxc/xenctrl.h
> +++ b/tools/libxc/xenctrl.h
> @@ -1227,6 +1227,10 @@ int xc_mmuext_op(xc_interface *xch, stru
>  /* System wide memory properties */
>  long xc_maximum_ram_page(xc_interface *xch);
>  
> +long xc_sharing_freed_pages(xc_interface *xch);
> +
> +long xc_sharing_used_frames(xc_interface *xch);

A quick comment on what each function returns might be worthwhile, maybe
it's obvious to someone who knows the sharing stuff, but e.g. does
"used" mean used right now or does it mean have ever been used? I
suppose "freed" must be historical.

Also why pages vs frames? The underlying domctl is always pages.

Ian.

> +
>  /* Get current total pages allocated to a domain. */
>  long xc_get_tot_pages(xc_interface *xch, uint32_t domid);
>  



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 10:45:04 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 10:45:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ra3NE-0006qs-6C; Mon, 12 Dec 2011 10:44:44 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Ra3NC-0006qh-1M
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 10:44:42 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1323686627!5130373!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDc4NQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21438 invoked from network); 12 Dec 2011 10:43:48 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Dec 2011 10:43:48 -0000
X-IronPort-AV: E=Sophos;i="4.71,337,1320624000"; 
   d="scan'208";a="9412480"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Dec 2011 10:43:47 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 12 Dec 2011 10:43:47 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Date: Mon, 12 Dec 2011 10:43:47 +0000
In-Reply-To: <3fc7875c8d98cbc74598.1323472556@xdev.gridcentric.ca>
References: <patchbomb.1323472550@xdev.gridcentric.ca>
	<3fc7875c8d98cbc74598.1323472556@xdev.gridcentric.ca>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323686627.20077.137.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"andres@gridcentric.ca" <andres@gridcentric.ca>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Tim
	\(Xen.org\)" <tim@xen.org>, "adin@gridcentric.ca" <adin@gridcentric.ca>
Subject: Re: [Xen-devel] [PATCH 6 of 8] Tools: Allow libxl/xl to expose the
 total number of shared frames and space saved
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2011-12-09 at 23:15 +0000, Andres Lagar-Cavilla wrote:
> diff -r 6e8b8fb2c8b2 -r 3fc7875c8d98 tools/libxl/libxl.h
> --- a/tools/libxl/libxl.h
> +++ b/tools/libxl/libxl.h
> @@ -350,6 +350,9 @@ int libxl_domain_rename(libxl_ctx *ctx, 
>  int libxl_domain_pause(libxl_ctx *ctx, uint32_t domid);
>  int libxl_domain_unpause(libxl_ctx *ctx, uint32_t domid);
>  
> +long libxl_sharing_used_frames(libxl_ctx *ctx);
> +long libxl_sharing_freed_pages(libxl_ctx *ctx);

I'm undecided but perhaps it would be appropriate to add these to
libxl_physinfo? In which case the output of "xl physinfo" or "xl info"
would be a nice home for these. Or perhaps a new meminfo or hostinfo
struct?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 10:45:04 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 10:45:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ra3NE-0006qs-6C; Mon, 12 Dec 2011 10:44:44 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Ra3NC-0006qh-1M
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 10:44:42 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1323686627!5130373!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDc4NQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21438 invoked from network); 12 Dec 2011 10:43:48 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Dec 2011 10:43:48 -0000
X-IronPort-AV: E=Sophos;i="4.71,337,1320624000"; 
   d="scan'208";a="9412480"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Dec 2011 10:43:47 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 12 Dec 2011 10:43:47 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Date: Mon, 12 Dec 2011 10:43:47 +0000
In-Reply-To: <3fc7875c8d98cbc74598.1323472556@xdev.gridcentric.ca>
References: <patchbomb.1323472550@xdev.gridcentric.ca>
	<3fc7875c8d98cbc74598.1323472556@xdev.gridcentric.ca>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323686627.20077.137.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"andres@gridcentric.ca" <andres@gridcentric.ca>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Tim
	\(Xen.org\)" <tim@xen.org>, "adin@gridcentric.ca" <adin@gridcentric.ca>
Subject: Re: [Xen-devel] [PATCH 6 of 8] Tools: Allow libxl/xl to expose the
 total number of shared frames and space saved
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2011-12-09 at 23:15 +0000, Andres Lagar-Cavilla wrote:
> diff -r 6e8b8fb2c8b2 -r 3fc7875c8d98 tools/libxl/libxl.h
> --- a/tools/libxl/libxl.h
> +++ b/tools/libxl/libxl.h
> @@ -350,6 +350,9 @@ int libxl_domain_rename(libxl_ctx *ctx, 
>  int libxl_domain_pause(libxl_ctx *ctx, uint32_t domid);
>  int libxl_domain_unpause(libxl_ctx *ctx, uint32_t domid);
>  
> +long libxl_sharing_used_frames(libxl_ctx *ctx);
> +long libxl_sharing_freed_pages(libxl_ctx *ctx);

I'm undecided but perhaps it would be appropriate to add these to
libxl_physinfo? In which case the output of "xl physinfo" or "xl info"
would be a nice home for these. Or perhaps a new meminfo or hostinfo
struct?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 10:49:58 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 10:49:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ra3S0-00070r-Tp; Mon, 12 Dec 2011 10:49:40 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Ra3Rz-00070e-KZ
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 10:49:39 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1323686926!6323276!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDc4NQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9355 invoked from network); 12 Dec 2011 10:48:46 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Dec 2011 10:48:46 -0000
X-IronPort-AV: E=Sophos;i="4.71,337,1320624000"; 
   d="scan'208";a="9412590"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Dec 2011 10:48:35 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 12 Dec 2011 10:48:35 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Date: Mon, 12 Dec 2011 10:48:35 +0000
In-Reply-To: <33935769e2577e85d24a.1323472557@xdev.gridcentric.ca>
References: <patchbomb.1323472550@xdev.gridcentric.ca>
	<33935769e2577e85d24a.1323472557@xdev.gridcentric.ca>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323686915.20077.140.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"andres@gridcentric.ca" <andres@gridcentric.ca>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Tim
	\(Xen.org\)" <tim@xen.org>, "adin@gridcentric.ca" <adin@gridcentric.ca>
Subject: Re: [Xen-devel] [PATCH 7 of 8] Tools: Libxc wrappers to add shared
 pages to physmap
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2011-12-09 at 23:15 +0000, Andres Lagar-Cavilla wrote:
> tools/libxc/xc_memshr.c |  23 +++++++++++++++++++++++
>  tools/libxc/xenctrl.h   |   6 ++++++
>  2 files changed, 29 insertions(+), 0 deletions(-)
> 
> 
> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
> 
> diff -r 3fc7875c8d98 -r 33935769e257 tools/libxc/xc_memshr.c
> --- a/tools/libxc/xc_memshr.c
> +++ b/tools/libxc/xc_memshr.c
> @@ -86,6 +86,29 @@ int xc_memshr_nominate_gref(xc_interface
>      return ret;
>  }
>  
> +int xc_memshr_add_to_physmap(xc_interface *xch,

Who uses this?

> +                    uint32_t source_domain,
> +                    uint64_t source_gfn,
> +                    uint64_t source_handle,
> +                    uint32_t client_domain,
> +                    uint64_t client_gfn)
> +{
> +    DECLARE_DOMCTL;
> +    struct xen_domctl_mem_sharing_op *op;
> +
> +    domctl.cmd                  = XEN_DOMCTL_mem_sharing_op;
> +    domctl.interface_version    = XEN_DOMCTL_INTERFACE_VERSION;

do_domctl already takes care of this, although this seems to be the
prevalent form in xc_memchr.c.

> +    domctl.domain               = (domid_t) source_domain;
> +    op = &(domctl.u.mem_sharing_op);
> +    op->op = XEN_DOMCTL_MEM_EVENT_OP_SHARING_ADD_PHYSMAP;
> +    op->u.share.source_gfn      = source_gfn;
> +    op->u.share.source_handle   = source_handle;
> +    op->u.share.client_gfn      = client_gfn;
> +    op->u.share.client_domain   = (uint64_t) client_domain;
> +
> +    return do_domctl(xch, &domctl);
> +}
> +
>  int xc_memshr_share(xc_interface *xch,
>                      uint32_t source_domain,
>                      uint64_t source_gfn,
> diff -r 3fc7875c8d98 -r 33935769e257 tools/libxc/xenctrl.h
> --- a/tools/libxc/xenctrl.h
> +++ b/tools/libxc/xenctrl.h
> @@ -1895,6 +1895,12 @@ int xc_memshr_nominate_gref(xc_interface
>                              uint32_t domid,
>                              grant_ref_t gref,
>                              uint64_t *handle);
> +int xc_memshr_add_to_physmap(xc_interface *xch,
> +                    uint32_t source_domain,
> +                    uint64_t source_gfn,
> +                    uint64_t source_handle,
> +                    uint32_t client_domain,
> +                    uint64_t client_gfn);
>  int xc_memshr_share(xc_interface *xch,
>                      uint32_t source_domain,
>                      uint64_t source_gfn,



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 10:49:58 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 10:49:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ra3S0-00070r-Tp; Mon, 12 Dec 2011 10:49:40 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Ra3Rz-00070e-KZ
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 10:49:39 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1323686926!6323276!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDc4NQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9355 invoked from network); 12 Dec 2011 10:48:46 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Dec 2011 10:48:46 -0000
X-IronPort-AV: E=Sophos;i="4.71,337,1320624000"; 
   d="scan'208";a="9412590"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Dec 2011 10:48:35 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 12 Dec 2011 10:48:35 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Date: Mon, 12 Dec 2011 10:48:35 +0000
In-Reply-To: <33935769e2577e85d24a.1323472557@xdev.gridcentric.ca>
References: <patchbomb.1323472550@xdev.gridcentric.ca>
	<33935769e2577e85d24a.1323472557@xdev.gridcentric.ca>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323686915.20077.140.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"andres@gridcentric.ca" <andres@gridcentric.ca>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Tim
	\(Xen.org\)" <tim@xen.org>, "adin@gridcentric.ca" <adin@gridcentric.ca>
Subject: Re: [Xen-devel] [PATCH 7 of 8] Tools: Libxc wrappers to add shared
 pages to physmap
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2011-12-09 at 23:15 +0000, Andres Lagar-Cavilla wrote:
> tools/libxc/xc_memshr.c |  23 +++++++++++++++++++++++
>  tools/libxc/xenctrl.h   |   6 ++++++
>  2 files changed, 29 insertions(+), 0 deletions(-)
> 
> 
> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
> 
> diff -r 3fc7875c8d98 -r 33935769e257 tools/libxc/xc_memshr.c
> --- a/tools/libxc/xc_memshr.c
> +++ b/tools/libxc/xc_memshr.c
> @@ -86,6 +86,29 @@ int xc_memshr_nominate_gref(xc_interface
>      return ret;
>  }
>  
> +int xc_memshr_add_to_physmap(xc_interface *xch,

Who uses this?

> +                    uint32_t source_domain,
> +                    uint64_t source_gfn,
> +                    uint64_t source_handle,
> +                    uint32_t client_domain,
> +                    uint64_t client_gfn)
> +{
> +    DECLARE_DOMCTL;
> +    struct xen_domctl_mem_sharing_op *op;
> +
> +    domctl.cmd                  = XEN_DOMCTL_mem_sharing_op;
> +    domctl.interface_version    = XEN_DOMCTL_INTERFACE_VERSION;

do_domctl already takes care of this, although this seems to be the
prevalent form in xc_memchr.c.

> +    domctl.domain               = (domid_t) source_domain;
> +    op = &(domctl.u.mem_sharing_op);
> +    op->op = XEN_DOMCTL_MEM_EVENT_OP_SHARING_ADD_PHYSMAP;
> +    op->u.share.source_gfn      = source_gfn;
> +    op->u.share.source_handle   = source_handle;
> +    op->u.share.client_gfn      = client_gfn;
> +    op->u.share.client_domain   = (uint64_t) client_domain;
> +
> +    return do_domctl(xch, &domctl);
> +}
> +
>  int xc_memshr_share(xc_interface *xch,
>                      uint32_t source_domain,
>                      uint64_t source_gfn,
> diff -r 3fc7875c8d98 -r 33935769e257 tools/libxc/xenctrl.h
> --- a/tools/libxc/xenctrl.h
> +++ b/tools/libxc/xenctrl.h
> @@ -1895,6 +1895,12 @@ int xc_memshr_nominate_gref(xc_interface
>                              uint32_t domid,
>                              grant_ref_t gref,
>                              uint64_t *handle);
> +int xc_memshr_add_to_physmap(xc_interface *xch,
> +                    uint32_t source_domain,
> +                    uint64_t source_gfn,
> +                    uint64_t source_handle,
> +                    uint32_t client_domain,
> +                    uint64_t client_gfn);
>  int xc_memshr_share(xc_interface *xch,
>                      uint32_t source_domain,
>                      uint64_t source_gfn,



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 10:51:43 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 10:51:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ra3Th-000762-E2; Mon, 12 Dec 2011 10:51:25 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Ra3Tf-00075r-PE
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 10:51:23 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1323686996!47475998!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDc4NQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12375 invoked from network); 12 Dec 2011 10:49:56 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Dec 2011 10:49:56 -0000
X-IronPort-AV: E=Sophos;i="4.71,337,1320624000"; 
   d="scan'208";a="9412642"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Dec 2011 10:50:35 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 12 Dec 2011 10:50:35 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Date: Mon, 12 Dec 2011 10:50:35 +0000
In-Reply-To: <33935769e2577e85d24a.1323472557@xdev.gridcentric.ca>
References: <patchbomb.1323472550@xdev.gridcentric.ca>
	<33935769e2577e85d24a.1323472557@xdev.gridcentric.ca>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323687035.20077.141.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"andres@gridcentric.ca" <andres@gridcentric.ca>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Tim
	\(Xen.org\)" <tim@xen.org>, "adin@gridcentric.ca" <adin@gridcentric.ca>
Subject: Re: [Xen-devel] [PATCH 7 of 8] Tools: Libxc wrappers to add shared
 pages to physmap
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2011-12-09 at 23:15 +0000, Andres Lagar-Cavilla wrote:
> tools/libxc/xc_memshr.c |  23 +++++++++++++++++++++++
>  tools/libxc/xenctrl.h   |   6 ++++++
>  2 files changed, 29 insertions(+), 0 deletions(-)
> 
> 
> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
> 
> diff -r 3fc7875c8d98 -r 33935769e257 tools/libxc/xc_memshr.c
> --- a/tools/libxc/xc_memshr.c
> +++ b/tools/libxc/xc_memshr.c
> @@ -86,6 +86,29 @@ int xc_memshr_nominate_gref(xc_interface
>      return ret;
>  }
>  
> +int xc_memshr_add_to_physmap(xc_interface *xch,
> +                    uint32_t source_domain,
> +                    uint64_t source_gfn,
> +                    uint64_t source_handle,
> +                    uint32_t client_domain,
> +                    uint64_t client_gfn)
> +{
> +    DECLARE_DOMCTL;
> +    struct xen_domctl_mem_sharing_op *op;
> +
> +    domctl.cmd                  = XEN_DOMCTL_mem_sharing_op;
> +    domctl.interface_version    = XEN_DOMCTL_INTERFACE_VERSION;
> +    domctl.domain               = (domid_t) source_domain;

Why not use domid_t in the interface?

> +    op = &(domctl.u.mem_sharing_op);
> +    op->op = XEN_DOMCTL_MEM_EVENT_OP_SHARING_ADD_PHYSMAP;
> +    op->u.share.source_gfn      = source_gfn;
> +    op->u.share.source_handle   = source_handle;
> +    op->u.share.client_gfn      = client_gfn;
> +    op->u.share.client_domain   = (uint64_t) client_domain;

Why not uint64_t in the interface?

> +
> +    return do_domctl(xch, &domctl);
> +}
> +
>  int xc_memshr_share(xc_interface *xch,
>                      uint32_t source_domain,
>                      uint64_t source_gfn,
> diff -r 3fc7875c8d98 -r 33935769e257 tools/libxc/xenctrl.h
> --- a/tools/libxc/xenctrl.h
> +++ b/tools/libxc/xenctrl.h
> @@ -1895,6 +1895,12 @@ int xc_memshr_nominate_gref(xc_interface
>                              uint32_t domid,
>                              grant_ref_t gref,
>                              uint64_t *handle);
> +int xc_memshr_add_to_physmap(xc_interface *xch,
> +                    uint32_t source_domain,
> +                    uint64_t source_gfn,
> +                    uint64_t source_handle,
> +                    uint32_t client_domain,
> +                    uint64_t client_gfn);
>  int xc_memshr_share(xc_interface *xch,
>                      uint32_t source_domain,
>                      uint64_t source_gfn,



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 10:51:43 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 10:51:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ra3Th-000762-E2; Mon, 12 Dec 2011 10:51:25 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Ra3Tf-00075r-PE
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 10:51:23 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1323686996!47475998!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDc4NQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12375 invoked from network); 12 Dec 2011 10:49:56 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Dec 2011 10:49:56 -0000
X-IronPort-AV: E=Sophos;i="4.71,337,1320624000"; 
   d="scan'208";a="9412642"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Dec 2011 10:50:35 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 12 Dec 2011 10:50:35 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Date: Mon, 12 Dec 2011 10:50:35 +0000
In-Reply-To: <33935769e2577e85d24a.1323472557@xdev.gridcentric.ca>
References: <patchbomb.1323472550@xdev.gridcentric.ca>
	<33935769e2577e85d24a.1323472557@xdev.gridcentric.ca>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323687035.20077.141.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"andres@gridcentric.ca" <andres@gridcentric.ca>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Tim
	\(Xen.org\)" <tim@xen.org>, "adin@gridcentric.ca" <adin@gridcentric.ca>
Subject: Re: [Xen-devel] [PATCH 7 of 8] Tools: Libxc wrappers to add shared
 pages to physmap
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2011-12-09 at 23:15 +0000, Andres Lagar-Cavilla wrote:
> tools/libxc/xc_memshr.c |  23 +++++++++++++++++++++++
>  tools/libxc/xenctrl.h   |   6 ++++++
>  2 files changed, 29 insertions(+), 0 deletions(-)
> 
> 
> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
> 
> diff -r 3fc7875c8d98 -r 33935769e257 tools/libxc/xc_memshr.c
> --- a/tools/libxc/xc_memshr.c
> +++ b/tools/libxc/xc_memshr.c
> @@ -86,6 +86,29 @@ int xc_memshr_nominate_gref(xc_interface
>      return ret;
>  }
>  
> +int xc_memshr_add_to_physmap(xc_interface *xch,
> +                    uint32_t source_domain,
> +                    uint64_t source_gfn,
> +                    uint64_t source_handle,
> +                    uint32_t client_domain,
> +                    uint64_t client_gfn)
> +{
> +    DECLARE_DOMCTL;
> +    struct xen_domctl_mem_sharing_op *op;
> +
> +    domctl.cmd                  = XEN_DOMCTL_mem_sharing_op;
> +    domctl.interface_version    = XEN_DOMCTL_INTERFACE_VERSION;
> +    domctl.domain               = (domid_t) source_domain;

Why not use domid_t in the interface?

> +    op = &(domctl.u.mem_sharing_op);
> +    op->op = XEN_DOMCTL_MEM_EVENT_OP_SHARING_ADD_PHYSMAP;
> +    op->u.share.source_gfn      = source_gfn;
> +    op->u.share.source_handle   = source_handle;
> +    op->u.share.client_gfn      = client_gfn;
> +    op->u.share.client_domain   = (uint64_t) client_domain;

Why not uint64_t in the interface?

> +
> +    return do_domctl(xch, &domctl);
> +}
> +
>  int xc_memshr_share(xc_interface *xch,
>                      uint32_t source_domain,
>                      uint64_t source_gfn,
> diff -r 3fc7875c8d98 -r 33935769e257 tools/libxc/xenctrl.h
> --- a/tools/libxc/xenctrl.h
> +++ b/tools/libxc/xenctrl.h
> @@ -1895,6 +1895,12 @@ int xc_memshr_nominate_gref(xc_interface
>                              uint32_t domid,
>                              grant_ref_t gref,
>                              uint64_t *handle);
> +int xc_memshr_add_to_physmap(xc_interface *xch,
> +                    uint32_t source_domain,
> +                    uint64_t source_gfn,
> +                    uint64_t source_handle,
> +                    uint32_t client_domain,
> +                    uint64_t client_gfn);
>  int xc_memshr_share(xc_interface *xch,
>                      uint32_t source_domain,
>                      uint64_t source_gfn,



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 10:53:12 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 10: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.xensource.com>)
	id 1Ra3VA-0007Bi-Tp; Mon, 12 Dec 2011 10:52:56 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Ra3V9-0007BM-6h
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 10:52:55 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1323687013!55769172!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDc4NQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1307 invoked from network); 12 Dec 2011 10:50:13 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Dec 2011 10:50:13 -0000
X-IronPort-AV: E=Sophos;i="4.71,337,1320624000"; 
   d="scan'208";a="9412672"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Dec 2011 10:52:02 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 12 Dec 2011 10:52:02 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Date: Mon, 12 Dec 2011 10:52:01 +0000
In-Reply-To: <6514004012c70975ba30.1323472558@xdev.gridcentric.ca>
References: <patchbomb.1323472550@xdev.gridcentric.ca>
	<6514004012c70975ba30.1323472558@xdev.gridcentric.ca>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323687122.20077.143.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"andres@gridcentric.ca" <andres@gridcentric.ca>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Tim
	\(Xen.org\)" <tim@xen.org>, "adin@gridcentric.ca" <adin@gridcentric.ca>
Subject: Re: [Xen-devel] [PATCH 8 of 8] Tools: Libxc wrapper for the new
 sharing audit domctl
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2011-12-09 at 23:15 +0000, Andres Lagar-Cavilla wrote:
> tools/libxc/xc_memshr.c |  14 ++++++++++++++
>  tools/libxc/xenctrl.h   |   2 ++
>  2 files changed, 16 insertions(+), 0 deletions(-)

This is something you'd trigger manually as a debug aid? Or would the
memshr daemon do it occasionally?

> 
> 
> Signed-off-by: Adin Scannell <adin@scannell.ca>
> 
> diff -r 33935769e257 -r 6514004012c7 tools/libxc/xc_memshr.c
> --- a/tools/libxc/xc_memshr.c
> +++ b/tools/libxc/xc_memshr.c
> @@ -211,3 +211,17 @@ int xc_memshr_debug_gref(xc_interface *x
>      return do_domctl(xch, &domctl);
>  }
>  
> +int xc_memshr_audit(xc_interface *xch,
> +                    uint32_t domid)
> +{
> +    DECLARE_DOMCTL;
> +    struct xen_domctl_mem_sharing_op *op;
> +
> +    domctl.cmd = XEN_DOMCTL_mem_sharing_op;
> +    domctl.interface_version = XEN_DOMCTL_INTERFACE_VERSION;
> +    domctl.domain = (domid_t)domid;
> +    op = &(domctl.u.mem_sharing_op);
> +    op->op = XEN_DOMCTL_MEM_EVENT_OP_SHARING_AUDIT;
> +
> +    return do_domctl(xch, &domctl);
> +}
> diff -r 33935769e257 -r 6514004012c7 tools/libxc/xenctrl.h
> --- a/tools/libxc/xenctrl.h
> +++ b/tools/libxc/xenctrl.h
> @@ -1921,6 +1921,8 @@ int xc_memshr_debug_mfn(xc_interface *xc
>  int xc_memshr_debug_gref(xc_interface *xch,
>                           uint32_t domid,
>                           grant_ref_t gref);
> +int xc_memshr_audit(xc_interface *xch,
> +                    uint32_t domid);
>  
>  int xc_flask_load(xc_interface *xc_handle, char *buf, uint32_t size);
>  int xc_flask_context_to_sid(xc_interface *xc_handle, char *buf, uint32_t size, uint32_t *sid);



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 10:53:12 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 10: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.xensource.com>)
	id 1Ra3VA-0007Bi-Tp; Mon, 12 Dec 2011 10:52:56 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Ra3V9-0007BM-6h
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 10:52:55 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1323687013!55769172!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDc4NQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1307 invoked from network); 12 Dec 2011 10:50:13 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Dec 2011 10:50:13 -0000
X-IronPort-AV: E=Sophos;i="4.71,337,1320624000"; 
   d="scan'208";a="9412672"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Dec 2011 10:52:02 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 12 Dec 2011 10:52:02 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Date: Mon, 12 Dec 2011 10:52:01 +0000
In-Reply-To: <6514004012c70975ba30.1323472558@xdev.gridcentric.ca>
References: <patchbomb.1323472550@xdev.gridcentric.ca>
	<6514004012c70975ba30.1323472558@xdev.gridcentric.ca>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323687122.20077.143.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"andres@gridcentric.ca" <andres@gridcentric.ca>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Tim
	\(Xen.org\)" <tim@xen.org>, "adin@gridcentric.ca" <adin@gridcentric.ca>
Subject: Re: [Xen-devel] [PATCH 8 of 8] Tools: Libxc wrapper for the new
 sharing audit domctl
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2011-12-09 at 23:15 +0000, Andres Lagar-Cavilla wrote:
> tools/libxc/xc_memshr.c |  14 ++++++++++++++
>  tools/libxc/xenctrl.h   |   2 ++
>  2 files changed, 16 insertions(+), 0 deletions(-)

This is something you'd trigger manually as a debug aid? Or would the
memshr daemon do it occasionally?

> 
> 
> Signed-off-by: Adin Scannell <adin@scannell.ca>
> 
> diff -r 33935769e257 -r 6514004012c7 tools/libxc/xc_memshr.c
> --- a/tools/libxc/xc_memshr.c
> +++ b/tools/libxc/xc_memshr.c
> @@ -211,3 +211,17 @@ int xc_memshr_debug_gref(xc_interface *x
>      return do_domctl(xch, &domctl);
>  }
>  
> +int xc_memshr_audit(xc_interface *xch,
> +                    uint32_t domid)
> +{
> +    DECLARE_DOMCTL;
> +    struct xen_domctl_mem_sharing_op *op;
> +
> +    domctl.cmd = XEN_DOMCTL_mem_sharing_op;
> +    domctl.interface_version = XEN_DOMCTL_INTERFACE_VERSION;
> +    domctl.domain = (domid_t)domid;
> +    op = &(domctl.u.mem_sharing_op);
> +    op->op = XEN_DOMCTL_MEM_EVENT_OP_SHARING_AUDIT;
> +
> +    return do_domctl(xch, &domctl);
> +}
> diff -r 33935769e257 -r 6514004012c7 tools/libxc/xenctrl.h
> --- a/tools/libxc/xenctrl.h
> +++ b/tools/libxc/xenctrl.h
> @@ -1921,6 +1921,8 @@ int xc_memshr_debug_mfn(xc_interface *xc
>  int xc_memshr_debug_gref(xc_interface *xch,
>                           uint32_t domid,
>                           grant_ref_t gref);
> +int xc_memshr_audit(xc_interface *xch,
> +                    uint32_t domid);
>  
>  int xc_flask_load(xc_interface *xc_handle, char *buf, uint32_t size);
>  int xc_flask_context_to_sid(xc_interface *xc_handle, char *buf, uint32_t size, uint32_t *sid);



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 11:06:01 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 11: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.xensource.com>)
	id 1Ra3hV-0007ad-BN; Mon, 12 Dec 2011 11:05:41 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <hn_nemati1985@yahoo.com>) id 1Ra3hU-0007aU-B9
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 11:05:40 +0000
X-Env-Sender: hn_nemati1985@yahoo.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1323687779!55772014!1
X-Originating-IP: [98.139.213.161]
X-SpamReason: No, hits=0.9 required=7.0 tests=FROM_HAS_ULINE_NUMS,
	HTML_50_60, HTML_MESSAGE, ML_RADAR_SPEW_LINKS_12, ML_RADAR_SPEW_LINKS_14,
	ML_RADAR_SPEW_LINKS_6,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 893 invoked from network); 12 Dec 2011 11:02:59 -0000
Received: from nm24-vm0.bullet.mail.bf1.yahoo.com (HELO
	nm24-vm0.bullet.mail.bf1.yahoo.com) (98.139.213.161)
	by server-8.tower-27.messagelabs.com with SMTP;
	12 Dec 2011 11:02:59 -0000
Received: from [98.139.212.152] by nm24.bullet.mail.bf1.yahoo.com with NNFMP;
	12 Dec 2011 11:02:39 -0000
Received: from [98.139.212.232] by tm9.bullet.mail.bf1.yahoo.com with NNFMP;
	12 Dec 2011 11:02:39 -0000
Received: from [127.0.0.1] by omp1041.mail.bf1.yahoo.com with NNFMP;
	12 Dec 2011 11:02:39 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 710754.22610.bm@omp1041.mail.bf1.yahoo.com
Received: (qmail 29950 invoked by uid 60001); 12 Dec 2011 11:02:39 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024;
	t=1323687759; bh=RXjfcF81RRwkhMs9Tp9WW3vbgHkr9+Pqo1eLoDO0hR8=;
	h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:Cc:MIME-Version:Content-Type;
	b=lVNEQ/yX83tPuLUwmpYSXZGMB+UrMcR7Uullo9h5O8drImvjrqXMskYkq3JlnzanlqwQ3OPwDsCEUbmSCZY+qa/AkJTgJGwG71JOTUAfvnGY18Eo5OVwyu4PuyMM372qUipCrRk1kEJ9PG+fhILRjwy1dlWfusK/RyHB6cepheU=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com;
	h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:Cc:MIME-Version:Content-Type;
	b=lNOZI9ff/4gv7hrH8mLzA6CWDDnhMIhdjeRm4StIA9QGdLkAqvCARwXQEdAhxpQ5r+Ly+SyXQ7XkCT0/pjvuYNVECOnHiV/N6XqoRYVBxmuvcRO4dngw2kJN/VvHKnBSGVfCi2M/u0KOuI2u5ZhiYpNsLmr4qjdAlcDYQtgTmvc=;
X-YMail-OSG: HDsmYxsVM1ltVzceyrAj8Re2v88IKqfWZcQVZHRjK8g3ubf
	UJtHvCFvrPI08wug8NwsGuSJgOG92po70Yc520UqMQQFeP6l1C3EhV6RVsRD
	T6Xb8KxshuHkzVcho22a8ygtbjulSgD9R8VDyPjd.Gq9XO7ZwkK.GnRmWQFG
	qaDnbcHE2D.CU03eKEb9iiKfRdJDSa6LmATmyxefa_90Yr_kFmLX0XtjnWlM
	_YeTgtiBm25Qx8KAyLiS1dUZJMjTvA5itpOVLJy0pGLWOb3l5Jd8hD3EQHdu
	_yyUV8NgOD0aeoVBsTobcPx8byI6kseURCR3MQ1ZgjLPh9Guo8tL3z53EPPh
	aod0Qnw2yLaHxWJPjBypp8Ocbv3thegJ2ksYqGnwVgJsIT.i.39caBuaApcK
	Tha2f_E93zTcesRIQR3LKr3uw5C1cOjlJU58MnVsFxLXxxG_hr8yDMDPU8bI
	1oFXOqqgPBbjP_h4-
Received: from [76.73.45.34] by web160906.mail.bf1.yahoo.com via HTTP;
	Mon, 12 Dec 2011 03:02:39 PST
X-Mailer: YahooMailClassic/15.0.4 YahooMailWebService/0.8.115.331698
Message-ID: <1323687759.14650.YahooMailClassic@web160906.mail.bf1.yahoo.com>
Date: Mon, 12 Dec 2011 03:02:39 -0800 (PST)
From: jack nemati <hn_nemati1985@yahoo.com>
To: George Dunlap <dunlapg@umich.edu>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Xen shadow page table
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============4443567692715116280=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============4443567692715116280==
Content-Type: multipart/alternative; boundary="967773369-793035562-1323687759=:14650"

--967773369-793035562-1323687759=:14650
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

Dear George Dunlap,

I just need to enable the Xen shadow page table ( if HAP is not possible) i=
n that I need to take the control of dom0's pages in order to modify their =
control flags. is there any solution for this problem.

it's noticeable that, I have enabled this feature by directly setting of th=
e opt_dom0_shadow
init variable but I cause some CPU stall.

thanks in advance. Regards


--- On Mon, 12/12/11, George Dunlap <dunlapg@umich.edu> wrote:

From: George Dunlap <dunlapg@umich.edu>
Subject: Re: [Xen-devel] Xen shadow page table
To: "jack nemati" <hn_nemati1985@yahoo.com>
Cc: xen-devel@lists.xensource.com
Date: Monday, December 12, 2011,=0A 5:05 AM

On Sat, Dec 10, 2011 at 9:54 AM, jack nemati <hn_nemati1985@yahoo.com> wrot=
e:
=0ADear friends,
=0A
I'm working on Xen's Dom0, my question is how we can enable the shadow page=
 table or hardware assistant page table for it (the Dom0). Thanks in advanc=
e.

=0AYou can't enable HAP at the moment.=A0 What do you want to do with shado=
w pagetables?

=A0-George
=0A
-----Inline Attachment Follows-----

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--967773369-793035562-1323687759=:14650
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

<table cellspacing=3D"0" cellpadding=3D"0" border=3D"0" ><tr><td valign=3D"=
top" style=3D"font: inherit;"><blockquote style=3D"border-left: 2px solid r=
gb(16, 16, 255); margin-left: 5px; padding-left: 5px;"><div id=3D"yiv460596=
804"><table border=3D"0" cellpadding=3D"0" cellspacing=3D"0"><tbody><tr><td=
 style=3D"font:inherit;" valign=3D"top">Dear George Dunlap,<br><br>I just n=
eed to enable the Xen shadow page table ( if HAP is not possible) in that I=
 need to take the control of dom0's pages in order to modify their control =
flags. is there any solution for this problem.<br><br>it's noticeable that,=
 I have enabled this feature by directly setting of the opt_dom0_shadow<br>=
init variable but I cause some CPU stall<span class=3D"yiv460596804st"><em>=
</em></span>.<b><br><br>thanks in advance. Regards<br><br></b><br>--- On <b=
>Mon, 12/12/11, George Dunlap <i>&lt;dunlapg@umich.edu&gt;</i></b> wrote:<b=
r><blockquote style=3D"border-left:2px solid rgb(16, 16,
 255);margin-left:5px;padding-left:5px;"><br>From: George Dunlap &lt;dunlap=
g@umich.edu&gt;<br>Subject: Re: [Xen-devel] Xen shadow page table<br>To: "j=
ack nemati" &lt;hn_nemati1985@yahoo.com&gt;<br>Cc: xen-devel@lists.xensourc=
e.com<br>Date: Monday, December 12, 2011,=0A 5:05 AM<br><br><div id=3D"yiv4=
60596804">On Sat, Dec 10, 2011 at 9:54 AM, jack nemati <span dir=3D"ltr">&l=
t;<a rel=3D"nofollow">hn_nemati1985@yahoo.com</a>&gt;</span> wrote:<br><div=
 class=3D"yiv460596804gmail_quote"><blockquote class=3D"yiv460596804gmail_q=
uote" style=3D"margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,2=
04);padding-left:1ex;">=0A<table border=3D"0" cellpadding=3D"0" cellspacing=
=3D"0"><tbody><tr><td style=3D"font:inherit;" valign=3D"top"><span style=3D=
"color:rgb(0,0,0);font-family:Verdana, Arial, Helvetica, sans-serif;font-si=
ze:13px;font-style:normal;font-variant:normal;font-weight:normal;letter-spa=
cing:normal;line-height:normal;text-indent:0px;text-transform:none;white-sp=
ace:normal;word-spacing:0px;background-color:rgb(255,255,255);">Dear friend=
s,<br>=0A<br>I'm working on Xen's Dom0, my question is how we can enable th=
e shadow page table or hardware assistant page table for it (the Dom0). Tha=
nks in advance.<br><br></span></td></tr></tbody></table></blockquote><div>=
=0AYou can't enable HAP at the moment.&nbsp; What do you want to do with sh=
adow pagetables?<br><br></div></div>&nbsp;-George<br>=0A</div><br>-----Inli=
ne Attachment Follows-----<br><br><div class=3D"yiv460596804plainMail">____=
___________________________________________<br>Xen-devel mailing list<br><a=
 rel=3D"nofollow">Xen-devel@lists.xensource.com</a><br><a rel=3D"nofollow" =
target=3D"_blank" href=3D"http://lists.xensource.com/xen-devel">http://list=
s.xensource.com/xen-devel</a><br></div></blockquote></td></tr></tbody></tab=
le></div></blockquote></td></tr></table>
--967773369-793035562-1323687759=:14650--


--===============4443567692715116280==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============4443567692715116280==--


From xen-devel-bounces@lists.xensource.com Mon Dec 12 11:06:01 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 11: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.xensource.com>)
	id 1Ra3hV-0007ad-BN; Mon, 12 Dec 2011 11:05:41 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <hn_nemati1985@yahoo.com>) id 1Ra3hU-0007aU-B9
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 11:05:40 +0000
X-Env-Sender: hn_nemati1985@yahoo.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1323687779!55772014!1
X-Originating-IP: [98.139.213.161]
X-SpamReason: No, hits=0.9 required=7.0 tests=FROM_HAS_ULINE_NUMS,
	HTML_50_60, HTML_MESSAGE, ML_RADAR_SPEW_LINKS_12, ML_RADAR_SPEW_LINKS_14,
	ML_RADAR_SPEW_LINKS_6,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 893 invoked from network); 12 Dec 2011 11:02:59 -0000
Received: from nm24-vm0.bullet.mail.bf1.yahoo.com (HELO
	nm24-vm0.bullet.mail.bf1.yahoo.com) (98.139.213.161)
	by server-8.tower-27.messagelabs.com with SMTP;
	12 Dec 2011 11:02:59 -0000
Received: from [98.139.212.152] by nm24.bullet.mail.bf1.yahoo.com with NNFMP;
	12 Dec 2011 11:02:39 -0000
Received: from [98.139.212.232] by tm9.bullet.mail.bf1.yahoo.com with NNFMP;
	12 Dec 2011 11:02:39 -0000
Received: from [127.0.0.1] by omp1041.mail.bf1.yahoo.com with NNFMP;
	12 Dec 2011 11:02:39 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 710754.22610.bm@omp1041.mail.bf1.yahoo.com
Received: (qmail 29950 invoked by uid 60001); 12 Dec 2011 11:02:39 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024;
	t=1323687759; bh=RXjfcF81RRwkhMs9Tp9WW3vbgHkr9+Pqo1eLoDO0hR8=;
	h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:Cc:MIME-Version:Content-Type;
	b=lVNEQ/yX83tPuLUwmpYSXZGMB+UrMcR7Uullo9h5O8drImvjrqXMskYkq3JlnzanlqwQ3OPwDsCEUbmSCZY+qa/AkJTgJGwG71JOTUAfvnGY18Eo5OVwyu4PuyMM372qUipCrRk1kEJ9PG+fhILRjwy1dlWfusK/RyHB6cepheU=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com;
	h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:Cc:MIME-Version:Content-Type;
	b=lNOZI9ff/4gv7hrH8mLzA6CWDDnhMIhdjeRm4StIA9QGdLkAqvCARwXQEdAhxpQ5r+Ly+SyXQ7XkCT0/pjvuYNVECOnHiV/N6XqoRYVBxmuvcRO4dngw2kJN/VvHKnBSGVfCi2M/u0KOuI2u5ZhiYpNsLmr4qjdAlcDYQtgTmvc=;
X-YMail-OSG: HDsmYxsVM1ltVzceyrAj8Re2v88IKqfWZcQVZHRjK8g3ubf
	UJtHvCFvrPI08wug8NwsGuSJgOG92po70Yc520UqMQQFeP6l1C3EhV6RVsRD
	T6Xb8KxshuHkzVcho22a8ygtbjulSgD9R8VDyPjd.Gq9XO7ZwkK.GnRmWQFG
	qaDnbcHE2D.CU03eKEb9iiKfRdJDSa6LmATmyxefa_90Yr_kFmLX0XtjnWlM
	_YeTgtiBm25Qx8KAyLiS1dUZJMjTvA5itpOVLJy0pGLWOb3l5Jd8hD3EQHdu
	_yyUV8NgOD0aeoVBsTobcPx8byI6kseURCR3MQ1ZgjLPh9Guo8tL3z53EPPh
	aod0Qnw2yLaHxWJPjBypp8Ocbv3thegJ2ksYqGnwVgJsIT.i.39caBuaApcK
	Tha2f_E93zTcesRIQR3LKr3uw5C1cOjlJU58MnVsFxLXxxG_hr8yDMDPU8bI
	1oFXOqqgPBbjP_h4-
Received: from [76.73.45.34] by web160906.mail.bf1.yahoo.com via HTTP;
	Mon, 12 Dec 2011 03:02:39 PST
X-Mailer: YahooMailClassic/15.0.4 YahooMailWebService/0.8.115.331698
Message-ID: <1323687759.14650.YahooMailClassic@web160906.mail.bf1.yahoo.com>
Date: Mon, 12 Dec 2011 03:02:39 -0800 (PST)
From: jack nemati <hn_nemati1985@yahoo.com>
To: George Dunlap <dunlapg@umich.edu>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Xen shadow page table
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============4443567692715116280=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============4443567692715116280==
Content-Type: multipart/alternative; boundary="967773369-793035562-1323687759=:14650"

--967773369-793035562-1323687759=:14650
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

Dear George Dunlap,

I just need to enable the Xen shadow page table ( if HAP is not possible) i=
n that I need to take the control of dom0's pages in order to modify their =
control flags. is there any solution for this problem.

it's noticeable that, I have enabled this feature by directly setting of th=
e opt_dom0_shadow
init variable but I cause some CPU stall.

thanks in advance. Regards


--- On Mon, 12/12/11, George Dunlap <dunlapg@umich.edu> wrote:

From: George Dunlap <dunlapg@umich.edu>
Subject: Re: [Xen-devel] Xen shadow page table
To: "jack nemati" <hn_nemati1985@yahoo.com>
Cc: xen-devel@lists.xensource.com
Date: Monday, December 12, 2011,=0A 5:05 AM

On Sat, Dec 10, 2011 at 9:54 AM, jack nemati <hn_nemati1985@yahoo.com> wrot=
e:
=0ADear friends,
=0A
I'm working on Xen's Dom0, my question is how we can enable the shadow page=
 table or hardware assistant page table for it (the Dom0). Thanks in advanc=
e.

=0AYou can't enable HAP at the moment.=A0 What do you want to do with shado=
w pagetables?

=A0-George
=0A
-----Inline Attachment Follows-----

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--967773369-793035562-1323687759=:14650
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

<table cellspacing=3D"0" cellpadding=3D"0" border=3D"0" ><tr><td valign=3D"=
top" style=3D"font: inherit;"><blockquote style=3D"border-left: 2px solid r=
gb(16, 16, 255); margin-left: 5px; padding-left: 5px;"><div id=3D"yiv460596=
804"><table border=3D"0" cellpadding=3D"0" cellspacing=3D"0"><tbody><tr><td=
 style=3D"font:inherit;" valign=3D"top">Dear George Dunlap,<br><br>I just n=
eed to enable the Xen shadow page table ( if HAP is not possible) in that I=
 need to take the control of dom0's pages in order to modify their control =
flags. is there any solution for this problem.<br><br>it's noticeable that,=
 I have enabled this feature by directly setting of the opt_dom0_shadow<br>=
init variable but I cause some CPU stall<span class=3D"yiv460596804st"><em>=
</em></span>.<b><br><br>thanks in advance. Regards<br><br></b><br>--- On <b=
>Mon, 12/12/11, George Dunlap <i>&lt;dunlapg@umich.edu&gt;</i></b> wrote:<b=
r><blockquote style=3D"border-left:2px solid rgb(16, 16,
 255);margin-left:5px;padding-left:5px;"><br>From: George Dunlap &lt;dunlap=
g@umich.edu&gt;<br>Subject: Re: [Xen-devel] Xen shadow page table<br>To: "j=
ack nemati" &lt;hn_nemati1985@yahoo.com&gt;<br>Cc: xen-devel@lists.xensourc=
e.com<br>Date: Monday, December 12, 2011,=0A 5:05 AM<br><br><div id=3D"yiv4=
60596804">On Sat, Dec 10, 2011 at 9:54 AM, jack nemati <span dir=3D"ltr">&l=
t;<a rel=3D"nofollow">hn_nemati1985@yahoo.com</a>&gt;</span> wrote:<br><div=
 class=3D"yiv460596804gmail_quote"><blockquote class=3D"yiv460596804gmail_q=
uote" style=3D"margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,2=
04);padding-left:1ex;">=0A<table border=3D"0" cellpadding=3D"0" cellspacing=
=3D"0"><tbody><tr><td style=3D"font:inherit;" valign=3D"top"><span style=3D=
"color:rgb(0,0,0);font-family:Verdana, Arial, Helvetica, sans-serif;font-si=
ze:13px;font-style:normal;font-variant:normal;font-weight:normal;letter-spa=
cing:normal;line-height:normal;text-indent:0px;text-transform:none;white-sp=
ace:normal;word-spacing:0px;background-color:rgb(255,255,255);">Dear friend=
s,<br>=0A<br>I'm working on Xen's Dom0, my question is how we can enable th=
e shadow page table or hardware assistant page table for it (the Dom0). Tha=
nks in advance.<br><br></span></td></tr></tbody></table></blockquote><div>=
=0AYou can't enable HAP at the moment.&nbsp; What do you want to do with sh=
adow pagetables?<br><br></div></div>&nbsp;-George<br>=0A</div><br>-----Inli=
ne Attachment Follows-----<br><br><div class=3D"yiv460596804plainMail">____=
___________________________________________<br>Xen-devel mailing list<br><a=
 rel=3D"nofollow">Xen-devel@lists.xensource.com</a><br><a rel=3D"nofollow" =
target=3D"_blank" href=3D"http://lists.xensource.com/xen-devel">http://list=
s.xensource.com/xen-devel</a><br></div></blockquote></td></tr></tbody></tab=
le></div></blockquote></td></tr></table>
--967773369-793035562-1323687759=:14650--


--===============4443567692715116280==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============4443567692715116280==--


From xen-devel-bounces@lists.xensource.com Mon Dec 12 11:06:04 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 11:06:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ra3hf-0007b9-OM; Mon, 12 Dec 2011 11:05:51 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Ra3he-0007an-A9
	for Xen-devel@lists.xensource.com; Mon, 12 Dec 2011 11:05:50 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1323687897!6860426!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDc4NQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3302 invoked from network); 12 Dec 2011 11:04:57 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Dec 2011 11:04:57 -0000
X-IronPort-AV: E=Sophos;i="4.71,337,1320624000"; 
   d="scan'208";a="9413056"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Dec 2011 11:04:57 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 12 Dec 2011 11:04:57 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Mukesh Rathor <mukesh.rathor@oracle.com>
Date: Mon, 12 Dec 2011 11:04:57 +0000
In-Reply-To: <20111209175149.1e50bae0@mantra.us.oracle.com>
References: <20111209175149.1e50bae0@mantra.us.oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323687897.20077.153.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] HYBRID: SMP without HAP (PV MMU)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Sat, 2011-12-10 at 01:51 +0000, Mukesh Rathor wrote:
> Hi,
> 
> I have hybrid smp running with autoxlate. However, without autoxlate, I am
> running into issues realted to TLB flush.  The guest in this case makes
> multicalls as part of which cache is flushed (__do_update_va_mapping,
> etc..). However, the guest is using VPIDs and it is getting complicated.
> I can just xen not do any TLB management and let the guest just do it
> after return from the hypercall. That would be simpler than hacking xen
> further to put in hooks for hybrid. However, before doing that, I am wondering
> if there is even a usecase for hybrid without HAP. The only case I can think
> of is dom0. For backend grant frames mapping with autoxlate/HAP, it would
> need to update the HAP for every frame, and don't know if that would be
> a significant overhead.

I hadn't thought of that case. There was a talk on a related topic
("Moving Backend Drivers from Dom0 to HVM Domain") at XenSummit NA 2010
[0] by Jun Nakajima. I think this involved PV protocol changes though.

My (relatively uninformed) intuition is that a grant mapping for a HAP
domain is not going to be much different to a grant mapping for a PV
domain, it's effectively the same operation, you are just modifying a
different set of pagetables is all. The relative cost of hypercalls in
PV vs Hybrid might be a factor. I think just measuring it is the way to
go.

[0] http://xen.org/xensummit/xensummit_spring_2010.html

>  If not, then we don't really have a use case for
> running hybrid autoxlate off, and no point in spending time on it.

My expectation (until you mentioned the above) was that the option to
run without HAP would be only really used as a debug aid or to measure
the specific impact of HAP so it wasn't really that important if it
turned out to be hard.

I suppose there is also the use case of hardware where HAP is not
available although I think your numbers previously suggested that you
would be better off with full-PV rather than hybrid in this case?

Ian.

> Thanks for any input.
> Mukesh
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 11:06:04 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 11:06:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ra3hf-0007b9-OM; Mon, 12 Dec 2011 11:05:51 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Ra3he-0007an-A9
	for Xen-devel@lists.xensource.com; Mon, 12 Dec 2011 11:05:50 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1323687897!6860426!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDc4NQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3302 invoked from network); 12 Dec 2011 11:04:57 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Dec 2011 11:04:57 -0000
X-IronPort-AV: E=Sophos;i="4.71,337,1320624000"; 
   d="scan'208";a="9413056"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Dec 2011 11:04:57 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 12 Dec 2011 11:04:57 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Mukesh Rathor <mukesh.rathor@oracle.com>
Date: Mon, 12 Dec 2011 11:04:57 +0000
In-Reply-To: <20111209175149.1e50bae0@mantra.us.oracle.com>
References: <20111209175149.1e50bae0@mantra.us.oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323687897.20077.153.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] HYBRID: SMP without HAP (PV MMU)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Sat, 2011-12-10 at 01:51 +0000, Mukesh Rathor wrote:
> Hi,
> 
> I have hybrid smp running with autoxlate. However, without autoxlate, I am
> running into issues realted to TLB flush.  The guest in this case makes
> multicalls as part of which cache is flushed (__do_update_va_mapping,
> etc..). However, the guest is using VPIDs and it is getting complicated.
> I can just xen not do any TLB management and let the guest just do it
> after return from the hypercall. That would be simpler than hacking xen
> further to put in hooks for hybrid. However, before doing that, I am wondering
> if there is even a usecase for hybrid without HAP. The only case I can think
> of is dom0. For backend grant frames mapping with autoxlate/HAP, it would
> need to update the HAP for every frame, and don't know if that would be
> a significant overhead.

I hadn't thought of that case. There was a talk on a related topic
("Moving Backend Drivers from Dom0 to HVM Domain") at XenSummit NA 2010
[0] by Jun Nakajima. I think this involved PV protocol changes though.

My (relatively uninformed) intuition is that a grant mapping for a HAP
domain is not going to be much different to a grant mapping for a PV
domain, it's effectively the same operation, you are just modifying a
different set of pagetables is all. The relative cost of hypercalls in
PV vs Hybrid might be a factor. I think just measuring it is the way to
go.

[0] http://xen.org/xensummit/xensummit_spring_2010.html

>  If not, then we don't really have a use case for
> running hybrid autoxlate off, and no point in spending time on it.

My expectation (until you mentioned the above) was that the option to
run without HAP would be only really used as a debug aid or to measure
the specific impact of HAP so it wasn't really that important if it
turned out to be hard.

I suppose there is also the use case of hardware where HAP is not
available although I think your numbers previously suggested that you
would be better off with full-PV rather than hybrid in this case?

Ian.

> Thanks for any input.
> Mukesh
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 11:20:45 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 11:20:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ra3vq-0007ut-7Y; Mon, 12 Dec 2011 11:20:30 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Ra3vo-0007uo-PL
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 11:20:28 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1323688775!6861563!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDc4NQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23512 invoked from network); 12 Dec 2011 11:19:36 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Dec 2011 11:19:36 -0000
X-IronPort-AV: E=Sophos;i="4.71,338,1320624000"; 
   d="scan'208";a="9413448"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Dec 2011 11:19:35 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 12 Dec 2011 11:19:35 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau =?ISO-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
Date: Mon, 12 Dec 2011 11:19:35 +0000
In-Reply-To: <CAPLaKK5dcMWKffM9BDJvhPYieP3gMCHKDNOwv0iaFr4M5LoHCA@mail.gmail.com>
References: <patchbomb.1323448640@cosworth.uk.xensource.com>
	<3b7ac401f144206c3044.1323448644@cosworth.uk.xensource.com>
	<CAPLaKK5dcMWKffM9BDJvhPYieP3gMCHKDNOwv0iaFr4M5LoHCA@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323688775.20077.164.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Olaf Hering <olaf@aepfle.de>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>, Ian
	Jackson <Ian.Jackson@eu.citrix.com>, Vincent
	Hanquez <Vincent.Hanquez@eu.citrix.com>,
	Jonathan Ludlam <Jonathan.Ludlam@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 4 of 4] Linux/xencommons: Use oxenstored by
 default when available
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gU3VuLCAyMDExLTEyLTExIGF0IDE4OjEwICswMDAwLCBSb2dlciBQYXUgTW9ubsOpIHdyb3Rl
Ogo+IDIwMTEvMTIvOSBJYW4gQ2FtcGJlbGwgPGlhbi5jYW1wYmVsbEBjaXRyaXguY29tPjoKPiA+
ICMgSEcgY2hhbmdlc2V0IHBhdGNoCj4gPiAjIFVzZXIgSWFuIENhbXBiZWxsIDxpYW4uY2FtcGJl
bGxAY2l0cml4LmNvbT4KPiA+ICMgRGF0ZSAxMzIzNDQ4NjM2IDAKPiA+ICMgTm9kZSBJRCAzYjdh
YzQwMWYxNDQyMDZjMzA0NDBmYmI0MWM3NGIxM2ZhMjBiOGNiCj4gPiAjIFBhcmVudCAgNzRmOTRl
MTViZmUxZGFkNDEyZDAzNDJhZWFiZGJkODk1NjU3ZjU0Zgo+ID4gTGludXgveGVuY29tbW9uczog
VXNlIG94ZW5zdG9yZWQgYnkgZGVmYXVsdCB3aGVuIGF2YWlsYWJsZQo+ID4KPiA+IG94ZW5zdG9y
ZWQgaXMgYW4gb2NhbWwgaW1wbGVtZW50YXRpb24gb2YgdGhlIHhlbnN0b3JlIGRhZW1vbi4gSXQg
aXMgZmFzdGVyLAo+ID4gbW9yZSBzY2FsYWJsZSBhbmQgbW9yZSByZWxpYWJsZSB0aGFuIHRoZSBD
IHhlbnN0b3JlZC4KPiAKPiBUaGlzIG1lYW5zIHRoYXQgQyB4ZW5zdG9yZSBpcyBnb2luZyB0aGUg
d2F5IG9mIHRoZSBEb2RvPyBPciBhcmUgd2UKPiBnb2luZyB0byBtYWludGFpbiBib3RoIGltcGxl
bWVudGF0aW9ucyAob2NhbG0gYW5kIEMpPwoKSSBob25lc3RseSBkb24ndCBrbm93LgoKVGhleSBh
cmUgYm90aCByZWFzb25hYmx5IGxvdyBtYWludGVuYW5jZSBhbmQgcmFyZWx5IGNoYW5nZSBvciBo
YXZlIGJ1Z3MKcmVwb3J0ZWQuIFdlIGRvbid0IGFjdHVhbGx5IHNlZSBtYW55IGJ1ZyByZXBvcnRz
IGFib3V0IEMgeGVuc3RvcmVkCmFsdGhvdWdoIGl0J3Mgc2hvcnQgY29taW5ncyBvbmx5IHRlbmQg
dG8gYmVjb21lIGFwcGFyZW50IGF0IHNjYWxlIGFuZCBJCnN1c3BlY3QgbG90cyBvZiBwZW9wbGUg
dXNlIHdvcmthcm91bmRzIGxpa2UgbnVraW5nIHRoZSB0ZGIgb24gYm9vdAphbmQvb3IgcHV0dGlu
ZyBpdCBvbiBhIHRtcGZzLgoKT24gdGhlIG90aGVyIGhhbmQgaGF2aW5nIHR3byBjb2RlIGJhc2Vz
IHByb3ZpZGluZyB0aGUgc2FtZSBzZXJ2aWNlIGhhcwppdHMgb3duIGRvd25zaWRlcy4KCkkgZXhw
ZWN0IG91ciAob3IgYXQgbGVhc3QgbXkpIGZpcnN0IHJlc3BvbnNlIHRvIGEgbm9uLW9idmlvdXMg
YnVnIHJlcG9ydAppbiBDIHhlbnN0b3JlZCB3b3VsZCBiZSAiaGF2ZSB5b3UgdHJpZWQgb3hlbnN0
b3JlZD8iLgoKRldJVyBteSBpbnRlbnRpb24gKHdoZW4gSSBldmVudHVhbGx5IGdldCB0byBpdCBh
bmQgcmVzdXJyZWN0IHRob3NlCnBhdGNoZXMpIGlzIGZvciBzdHViLXhlbnN0b3JlZCB0byBiZSBh
biBveGVuc3RvcmVkIG9ubHkgdGhpbmcuCgpJYW4uCgoKX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxA
bGlzdHMueGVuc291cmNlLmNvbQpodHRwOi8vbGlzdHMueGVuc291cmNlLmNvbS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Mon Dec 12 11:20:45 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 11:20:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ra3vq-0007ut-7Y; Mon, 12 Dec 2011 11:20:30 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Ra3vo-0007uo-PL
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 11:20:28 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1323688775!6861563!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDc4NQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23512 invoked from network); 12 Dec 2011 11:19:36 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Dec 2011 11:19:36 -0000
X-IronPort-AV: E=Sophos;i="4.71,338,1320624000"; 
   d="scan'208";a="9413448"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Dec 2011 11:19:35 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 12 Dec 2011 11:19:35 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau =?ISO-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
Date: Mon, 12 Dec 2011 11:19:35 +0000
In-Reply-To: <CAPLaKK5dcMWKffM9BDJvhPYieP3gMCHKDNOwv0iaFr4M5LoHCA@mail.gmail.com>
References: <patchbomb.1323448640@cosworth.uk.xensource.com>
	<3b7ac401f144206c3044.1323448644@cosworth.uk.xensource.com>
	<CAPLaKK5dcMWKffM9BDJvhPYieP3gMCHKDNOwv0iaFr4M5LoHCA@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323688775.20077.164.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Olaf Hering <olaf@aepfle.de>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>, Ian
	Jackson <Ian.Jackson@eu.citrix.com>, Vincent
	Hanquez <Vincent.Hanquez@eu.citrix.com>,
	Jonathan Ludlam <Jonathan.Ludlam@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 4 of 4] Linux/xencommons: Use oxenstored by
 default when available
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gU3VuLCAyMDExLTEyLTExIGF0IDE4OjEwICswMDAwLCBSb2dlciBQYXUgTW9ubsOpIHdyb3Rl
Ogo+IDIwMTEvMTIvOSBJYW4gQ2FtcGJlbGwgPGlhbi5jYW1wYmVsbEBjaXRyaXguY29tPjoKPiA+
ICMgSEcgY2hhbmdlc2V0IHBhdGNoCj4gPiAjIFVzZXIgSWFuIENhbXBiZWxsIDxpYW4uY2FtcGJl
bGxAY2l0cml4LmNvbT4KPiA+ICMgRGF0ZSAxMzIzNDQ4NjM2IDAKPiA+ICMgTm9kZSBJRCAzYjdh
YzQwMWYxNDQyMDZjMzA0NDBmYmI0MWM3NGIxM2ZhMjBiOGNiCj4gPiAjIFBhcmVudCAgNzRmOTRl
MTViZmUxZGFkNDEyZDAzNDJhZWFiZGJkODk1NjU3ZjU0Zgo+ID4gTGludXgveGVuY29tbW9uczog
VXNlIG94ZW5zdG9yZWQgYnkgZGVmYXVsdCB3aGVuIGF2YWlsYWJsZQo+ID4KPiA+IG94ZW5zdG9y
ZWQgaXMgYW4gb2NhbWwgaW1wbGVtZW50YXRpb24gb2YgdGhlIHhlbnN0b3JlIGRhZW1vbi4gSXQg
aXMgZmFzdGVyLAo+ID4gbW9yZSBzY2FsYWJsZSBhbmQgbW9yZSByZWxpYWJsZSB0aGFuIHRoZSBD
IHhlbnN0b3JlZC4KPiAKPiBUaGlzIG1lYW5zIHRoYXQgQyB4ZW5zdG9yZSBpcyBnb2luZyB0aGUg
d2F5IG9mIHRoZSBEb2RvPyBPciBhcmUgd2UKPiBnb2luZyB0byBtYWludGFpbiBib3RoIGltcGxl
bWVudGF0aW9ucyAob2NhbG0gYW5kIEMpPwoKSSBob25lc3RseSBkb24ndCBrbm93LgoKVGhleSBh
cmUgYm90aCByZWFzb25hYmx5IGxvdyBtYWludGVuYW5jZSBhbmQgcmFyZWx5IGNoYW5nZSBvciBo
YXZlIGJ1Z3MKcmVwb3J0ZWQuIFdlIGRvbid0IGFjdHVhbGx5IHNlZSBtYW55IGJ1ZyByZXBvcnRz
IGFib3V0IEMgeGVuc3RvcmVkCmFsdGhvdWdoIGl0J3Mgc2hvcnQgY29taW5ncyBvbmx5IHRlbmQg
dG8gYmVjb21lIGFwcGFyZW50IGF0IHNjYWxlIGFuZCBJCnN1c3BlY3QgbG90cyBvZiBwZW9wbGUg
dXNlIHdvcmthcm91bmRzIGxpa2UgbnVraW5nIHRoZSB0ZGIgb24gYm9vdAphbmQvb3IgcHV0dGlu
ZyBpdCBvbiBhIHRtcGZzLgoKT24gdGhlIG90aGVyIGhhbmQgaGF2aW5nIHR3byBjb2RlIGJhc2Vz
IHByb3ZpZGluZyB0aGUgc2FtZSBzZXJ2aWNlIGhhcwppdHMgb3duIGRvd25zaWRlcy4KCkkgZXhw
ZWN0IG91ciAob3IgYXQgbGVhc3QgbXkpIGZpcnN0IHJlc3BvbnNlIHRvIGEgbm9uLW9idmlvdXMg
YnVnIHJlcG9ydAppbiBDIHhlbnN0b3JlZCB3b3VsZCBiZSAiaGF2ZSB5b3UgdHJpZWQgb3hlbnN0
b3JlZD8iLgoKRldJVyBteSBpbnRlbnRpb24gKHdoZW4gSSBldmVudHVhbGx5IGdldCB0byBpdCBh
bmQgcmVzdXJyZWN0IHRob3NlCnBhdGNoZXMpIGlzIGZvciBzdHViLXhlbnN0b3JlZCB0byBiZSBh
biBveGVuc3RvcmVkIG9ubHkgdGhpbmcuCgpJYW4uCgoKX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxA
bGlzdHMueGVuc291cmNlLmNvbQpodHRwOi8vbGlzdHMueGVuc291cmNlLmNvbS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Mon Dec 12 11:32:36 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 11:32:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ra47A-0008AM-Pr; Mon, 12 Dec 2011 11:32:12 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>)
	id 1Ra479-0008A9-6d; Mon, 12 Dec 2011 11:32:11 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1323689478!7074557!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDc4NQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25497 invoked from network); 12 Dec 2011 11:31:18 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Dec 2011 11:31:18 -0000
X-IronPort-AV: E=Sophos;i="4.71,338,1320624000"; 
   d="scan'208";a="9413751"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Dec 2011 11:31:18 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 12 Dec 2011 11:31:18 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: George Shuklin <george.shuklin@gmail.com>
Date: Mon, 12 Dec 2011 11:31:17 +0000
In-Reply-To: <4EE2665C.8090602@gmail.com>
References: <4EE2665C.8090602@gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323689477.20077.173.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-hosting@googlegroups.com" <xen-hosting@googlegroups.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	xen-api@lists.xensource.com
Subject: Re: [Xen-devel] bug in xenstored? No notification to subscription
 on @introduceDomain
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2011-12-09 at 19:49 +0000, George Shuklin wrote:
> Good day.
> 
> I think I met some strange bug in xenstored.

If you are using XCP then this will be using oxenstored. I've CC'd
xen-api@ since that is the correct place for XCP discussions.

It's also plausibly a bug in the C client library or the python bindings
to that library (or indeed your application).

> I using XCP for long time and all that time we have some funny bug we 
> was not able to debug enough due product environment and very low chance 
> to appear, now we was able to catch it in testing environment and done 
> some research.
> 
> We have python application running in dom0 and waiting domain 
> appearance. This implemented this via subscription to @introduceDomain 
> xenstore key. Under some conditions we stops to receive notification on 
> subscription. If we ran application as second instance it will receive 
> that notification, if we restart application it will  receive too.

You lose both @introduce and @release notifications or just @introduce?

Does the app do any other XS stuff, e.g. other watches or read/write? Do
these stop working also?

oxenstored (at least in XCP) logs to /var/log/xenstore-access.log -- do
you see any activity in there? There is also /var/log/xenstored.log

Does strace show the daemon writing (or trying to write) to the socket
associated with this client? What about on the client side? (nb:
libxenstore uses a thread to handle watches so be sure to use the
appropriate options to strace.) Identifying the fd associated with the
connection on either end might be tricky, /proc/<pid>/fd and/or netstat
might help narrow it down.

The app being python presumably makes it hard to attach gdb to and get
anything sensible, likewise the daemon being ocaml. If anyone has any
hints on attaching a debugging to an existing process of these types
then that might be useful.

Other than that I'm afraid I really don't have any idea what might be
going wrong, or indeed what other next steps can be taken to diagnose
the issue :-(

Ian.

> I unable to pinpoint exact condition for this, but this
> a) Happens occasionally but consistently (about once a month in farm of 
> 50 hosts at least at one host)
> b) Not related to xenstored uptime
> c) Not related to load on xen or dom0
> d) Not related to amount of domains
> e) Occur at least at XCP 0.5, 1.0 and 1.1 (I don't know how to get 
> version from xenstored)
> 
> Last time I got that on two hosts in lab at same time (with single guest 
> domain without any high load) and done some experiments - so I can say 
> exactly I wrote above.
> 
> The pieces from python code we ran:
> 
> from xen.lowlevel.xs import xs
> conn = xs.xs()
> conn.watch("@introduceDomain", "+")
> conn.watch("@releaseDomain", "-")
> conn.read_watch()
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 11:32:36 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 11:32:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ra47A-0008AM-Pr; Mon, 12 Dec 2011 11:32:12 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>)
	id 1Ra479-0008A9-6d; Mon, 12 Dec 2011 11:32:11 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1323689478!7074557!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDc4NQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25497 invoked from network); 12 Dec 2011 11:31:18 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Dec 2011 11:31:18 -0000
X-IronPort-AV: E=Sophos;i="4.71,338,1320624000"; 
   d="scan'208";a="9413751"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Dec 2011 11:31:18 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 12 Dec 2011 11:31:18 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: George Shuklin <george.shuklin@gmail.com>
Date: Mon, 12 Dec 2011 11:31:17 +0000
In-Reply-To: <4EE2665C.8090602@gmail.com>
References: <4EE2665C.8090602@gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323689477.20077.173.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-hosting@googlegroups.com" <xen-hosting@googlegroups.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	xen-api@lists.xensource.com
Subject: Re: [Xen-devel] bug in xenstored? No notification to subscription
 on @introduceDomain
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2011-12-09 at 19:49 +0000, George Shuklin wrote:
> Good day.
> 
> I think I met some strange bug in xenstored.

If you are using XCP then this will be using oxenstored. I've CC'd
xen-api@ since that is the correct place for XCP discussions.

It's also plausibly a bug in the C client library or the python bindings
to that library (or indeed your application).

> I using XCP for long time and all that time we have some funny bug we 
> was not able to debug enough due product environment and very low chance 
> to appear, now we was able to catch it in testing environment and done 
> some research.
> 
> We have python application running in dom0 and waiting domain 
> appearance. This implemented this via subscription to @introduceDomain 
> xenstore key. Under some conditions we stops to receive notification on 
> subscription. If we ran application as second instance it will receive 
> that notification, if we restart application it will  receive too.

You lose both @introduce and @release notifications or just @introduce?

Does the app do any other XS stuff, e.g. other watches or read/write? Do
these stop working also?

oxenstored (at least in XCP) logs to /var/log/xenstore-access.log -- do
you see any activity in there? There is also /var/log/xenstored.log

Does strace show the daemon writing (or trying to write) to the socket
associated with this client? What about on the client side? (nb:
libxenstore uses a thread to handle watches so be sure to use the
appropriate options to strace.) Identifying the fd associated with the
connection on either end might be tricky, /proc/<pid>/fd and/or netstat
might help narrow it down.

The app being python presumably makes it hard to attach gdb to and get
anything sensible, likewise the daemon being ocaml. If anyone has any
hints on attaching a debugging to an existing process of these types
then that might be useful.

Other than that I'm afraid I really don't have any idea what might be
going wrong, or indeed what other next steps can be taken to diagnose
the issue :-(

Ian.

> I unable to pinpoint exact condition for this, but this
> a) Happens occasionally but consistently (about once a month in farm of 
> 50 hosts at least at one host)
> b) Not related to xenstored uptime
> c) Not related to load on xen or dom0
> d) Not related to amount of domains
> e) Occur at least at XCP 0.5, 1.0 and 1.1 (I don't know how to get 
> version from xenstored)
> 
> Last time I got that on two hosts in lab at same time (with single guest 
> domain without any high load) and done some experiments - so I can say 
> exactly I wrote above.
> 
> The pieces from python code we ran:
> 
> from xen.lowlevel.xs import xs
> conn = xs.xs()
> conn.watch("@introduceDomain", "+")
> conn.watch("@releaseDomain", "-")
> conn.read_watch()
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 11:41:40 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 11:41:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ra4Fv-0008OC-Ss; Mon, 12 Dec 2011 11:41:15 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Ra4Fu-0008O6-Gp
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 11:41:14 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1323690021!7103109!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDc4NQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15958 invoked from network); 12 Dec 2011 11:40:21 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Dec 2011 11:40:21 -0000
X-IronPort-AV: E=Sophos;i="4.71,338,1320624000"; 
   d="scan'208";a="9413962"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Dec 2011 11:40:21 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 12 Dec 2011 11:40:21 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Ra4F2-0006hn-Ua; Mon, 12 Dec 2011 11:40:20 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Ra4F2-0005ta-Rk;
	Mon, 12 Dec 2011 11:40:20 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20197.59428.699013.507183@mariner.uk.xensource.com>
Date: Mon, 12 Dec 2011 11:40:20 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1323463293.20936.11.camel@dagon.hellion.org.uk>
References: <1323108621-22654-1-git-send-email-ian.jackson@eu.citrix.com>
	<1323108621-22654-16-git-send-email-ian.jackson@eu.citrix.com>
	<alpine.DEB.2.00.1112091558300.3517@kaball-desktop>
	<20194.22539.574524.956955@mariner.uk.xensource.com>
	<1323463293.20936.11.camel@dagon.hellion.org.uk>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 15/15] libxl: New event generation API
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("Re: [Xen-devel] [PATCH 15/15] libxl: New event generation API"):
> Stepping back a bit: Since the lock is recursive do we really need the
> unlocked version? All the callers of event_check_unlocked (apart from
> libxl_event_check) could call libxl_event_check instead.

Well, we have to have an internal version because we don't want to
call GC_INIT again, obviously.  Since the callers all take the lock
the internal version doesn't have to.

It would be possible to have these functions pointlessly reacquire the
lock, I guess, and rename it to "beforepoll_internal" etc.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 11:41:40 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 11:41:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ra4Fv-0008OC-Ss; Mon, 12 Dec 2011 11:41:15 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Ra4Fu-0008O6-Gp
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 11:41:14 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1323690021!7103109!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDc4NQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15958 invoked from network); 12 Dec 2011 11:40:21 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Dec 2011 11:40:21 -0000
X-IronPort-AV: E=Sophos;i="4.71,338,1320624000"; 
   d="scan'208";a="9413962"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Dec 2011 11:40:21 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 12 Dec 2011 11:40:21 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Ra4F2-0006hn-Ua; Mon, 12 Dec 2011 11:40:20 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Ra4F2-0005ta-Rk;
	Mon, 12 Dec 2011 11:40:20 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20197.59428.699013.507183@mariner.uk.xensource.com>
Date: Mon, 12 Dec 2011 11:40:20 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1323463293.20936.11.camel@dagon.hellion.org.uk>
References: <1323108621-22654-1-git-send-email-ian.jackson@eu.citrix.com>
	<1323108621-22654-16-git-send-email-ian.jackson@eu.citrix.com>
	<alpine.DEB.2.00.1112091558300.3517@kaball-desktop>
	<20194.22539.574524.956955@mariner.uk.xensource.com>
	<1323463293.20936.11.camel@dagon.hellion.org.uk>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 15/15] libxl: New event generation API
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("Re: [Xen-devel] [PATCH 15/15] libxl: New event generation API"):
> Stepping back a bit: Since the lock is recursive do we really need the
> unlocked version? All the callers of event_check_unlocked (apart from
> libxl_event_check) could call libxl_event_check instead.

Well, we have to have an internal version because we don't want to
call GC_INIT again, obviously.  Since the callers all take the lock
the internal version doesn't have to.

It would be possible to have these functions pointlessly reacquire the
lock, I guess, and rename it to "beforepoll_internal" etc.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 11:44:59 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 11:44:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ra4J7-0008Uk-Ga; Mon, 12 Dec 2011 11:44:33 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1Ra4J5-0008Uf-SX
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 11:44:32 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1323690217!6995121!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22385 invoked from network); 12 Dec 2011 11:43:38 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Dec 2011 11:43:38 -0000
Received: by iaen33 with SMTP id n33so33495917iae.30
	for <xen-devel@lists.xensource.com>;
	Mon, 12 Dec 2011 03:43:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=Ith2MKAxmj9kpYEMJL+h/5IzhIJt85+SqWG2lqZDVJQ=;
	b=wTF9LCyRyk0Wq74/8D0JzOS2ZGaqxyTb082aUqBnoOHmaCWBAu6ja07um6nIZcfS2h
	1q3fs/ehppGEDRNNcSdRzxs9Xgt/5JVjVq8YK6r5GxhHrmS3EqJf+aqBcebCYMGT7LRA
	wJQwkJ6+qJNcHPtqvTqrCMpv1qMkRuWjX3qL0=
MIME-Version: 1.0
Received: by 10.50.242.1 with SMTP id wm1mr14946105igc.30.1323690217031; Mon,
	12 Dec 2011 03:43:37 -0800 (PST)
Received: by 10.231.146.21 with HTTP; Mon, 12 Dec 2011 03:43:36 -0800 (PST)
In-Reply-To: <C10D3FB0CD45994C8A51FEC1227CE22F37666D5EA5@shsmsx502.ccr.corp.intel.com>
References: <C10D3FB0CD45994C8A51FEC1227CE22F340768D793@shsmsx502.ccr.corp.intel.com>
	<CAFLBxZZ9nqeb7CVqTZCsEtJRjgGMTHF2Ak929kvauj2KUFSOyg@mail.gmail.com>
	<C10D3FB0CD45994C8A51FEC1227CE22F3428CB5EF9@shsmsx502.ccr.corp.intel.com>
	<1319789425.19320.12.camel@Abyss>
	<C10D3FB0CD45994C8A51FEC1227CE22F3428CB61F2@shsmsx502.ccr.corp.intel.com>
	<1319796584.19320.31.camel@Abyss>
	<1319818714.21033.414.camel@elijah>
	<C10D3FB0CD45994C8A51FEC1227CE22F34B3905D03@shsmsx502.ccr.corp.intel.com>
	<CAFLBxZa5v_YgnC1LTa4a5wis4h6eQPijCAfUDLDsR4ucMuBXWg@mail.gmail.com>
	<C10D3FB0CD45994C8A51FEC1227CE22F37499C2733@shsmsx502.ccr.corp.intel.com>
	<CAFLBxZZ-F2hNTNHtiBCuQ0tVqJDe6btPnvofHK4KaDDQz8Rxtw@mail.gmail.com>
	<C10D3FB0CD45994C8A51FEC1227CE22F37666D5EA5@shsmsx502.ccr.corp.intel.com>
Date: Mon, 12 Dec 2011 11:43:36 +0000
X-Google-Sender-Auth: ySo8ZBvf4rKbvBjHOWGbYq47Kz8
Message-ID: <CAFLBxZZtpwncpEXJ9Atv0=isT_5FNJi8sEhZbAZnsJFbwvZpjw@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: "Lv, Hui" <hui.lv@intel.com>
Cc: "Tian, Kevin" <kevin.tian@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, "Dong, Eddie" <eddie.dong@intel.com>,
	George Dunlap <george.dunlap@citrix.com>, "Duan,
	Jiangang" <jiangang.duan@intel.com>, Dario Faggioli <raistlin@linux.it>
Subject: Re: [Xen-devel] [PATCH] scheduler rate controller
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Sun, Dec 11, 2011 at 3:27 PM, Lv, Hui <hui.lv@intel.com> wrote:
> Hi George,
>
> Thank you very much for your feedbacks.
> I have finished the measurement work based on the delay method. From the comparable results, 1ms-delay can do as well as SRC patch to gain significant performance boost without obvious drawbacks.
> 1. Basically, the "delay method" can achieve nearly the same benefits as my previous SRC patch, 11% overall performance boost for SPECvirt than original credit scheduler.
> 2. I have tried 1ms delay and 10ms delay, there is no big difference between these two configurations. (1ms is enough to achieve a good performance)
> 3. I have compared different load level response time/latency (low, high, peak), "delay method" didn't bring very much Qos increase.

Thanks Hui, those are good results.  Just one question: What's QoS
supposed to measure?  Is this a metric that SPECVirt reports?  Is
higher or lower better?

The patch looks good, but there's one last nitpick: Several of your
lines have hard tab characters in them; tabs are officially verboten
in the Xen code.  Please replace them with spaces.  After that, I
think we're ready to check it in.

One more small request: would it be possible to get some short xen
traces of SPECVirt running, at least with the 1ms-delay patch, and if
possible without it?  I'd like to have a better understanding of what
kind of scheduling workload SPECVirt creates, and how the 1ms delay
affects it.  If you have other priorities, don't worry, I'll wait
until our performance team here gets it set up.  If you do have time,
the command to use is as follows:

xentrace -D -e 0x21000 -T 30 /path/to/file.trace

This will take *just* scheduling traces for 30 seconds.  If you could
run it when the benchmark is going full throttle, that should help me
get an idea what the scheduling looks like.

Thanks,
 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 11:44:59 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 11:44:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ra4J7-0008Uk-Ga; Mon, 12 Dec 2011 11:44:33 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1Ra4J5-0008Uf-SX
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 11:44:32 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1323690217!6995121!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22385 invoked from network); 12 Dec 2011 11:43:38 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Dec 2011 11:43:38 -0000
Received: by iaen33 with SMTP id n33so33495917iae.30
	for <xen-devel@lists.xensource.com>;
	Mon, 12 Dec 2011 03:43:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=Ith2MKAxmj9kpYEMJL+h/5IzhIJt85+SqWG2lqZDVJQ=;
	b=wTF9LCyRyk0Wq74/8D0JzOS2ZGaqxyTb082aUqBnoOHmaCWBAu6ja07um6nIZcfS2h
	1q3fs/ehppGEDRNNcSdRzxs9Xgt/5JVjVq8YK6r5GxhHrmS3EqJf+aqBcebCYMGT7LRA
	wJQwkJ6+qJNcHPtqvTqrCMpv1qMkRuWjX3qL0=
MIME-Version: 1.0
Received: by 10.50.242.1 with SMTP id wm1mr14946105igc.30.1323690217031; Mon,
	12 Dec 2011 03:43:37 -0800 (PST)
Received: by 10.231.146.21 with HTTP; Mon, 12 Dec 2011 03:43:36 -0800 (PST)
In-Reply-To: <C10D3FB0CD45994C8A51FEC1227CE22F37666D5EA5@shsmsx502.ccr.corp.intel.com>
References: <C10D3FB0CD45994C8A51FEC1227CE22F340768D793@shsmsx502.ccr.corp.intel.com>
	<CAFLBxZZ9nqeb7CVqTZCsEtJRjgGMTHF2Ak929kvauj2KUFSOyg@mail.gmail.com>
	<C10D3FB0CD45994C8A51FEC1227CE22F3428CB5EF9@shsmsx502.ccr.corp.intel.com>
	<1319789425.19320.12.camel@Abyss>
	<C10D3FB0CD45994C8A51FEC1227CE22F3428CB61F2@shsmsx502.ccr.corp.intel.com>
	<1319796584.19320.31.camel@Abyss>
	<1319818714.21033.414.camel@elijah>
	<C10D3FB0CD45994C8A51FEC1227CE22F34B3905D03@shsmsx502.ccr.corp.intel.com>
	<CAFLBxZa5v_YgnC1LTa4a5wis4h6eQPijCAfUDLDsR4ucMuBXWg@mail.gmail.com>
	<C10D3FB0CD45994C8A51FEC1227CE22F37499C2733@shsmsx502.ccr.corp.intel.com>
	<CAFLBxZZ-F2hNTNHtiBCuQ0tVqJDe6btPnvofHK4KaDDQz8Rxtw@mail.gmail.com>
	<C10D3FB0CD45994C8A51FEC1227CE22F37666D5EA5@shsmsx502.ccr.corp.intel.com>
Date: Mon, 12 Dec 2011 11:43:36 +0000
X-Google-Sender-Auth: ySo8ZBvf4rKbvBjHOWGbYq47Kz8
Message-ID: <CAFLBxZZtpwncpEXJ9Atv0=isT_5FNJi8sEhZbAZnsJFbwvZpjw@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: "Lv, Hui" <hui.lv@intel.com>
Cc: "Tian, Kevin" <kevin.tian@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, "Dong, Eddie" <eddie.dong@intel.com>,
	George Dunlap <george.dunlap@citrix.com>, "Duan,
	Jiangang" <jiangang.duan@intel.com>, Dario Faggioli <raistlin@linux.it>
Subject: Re: [Xen-devel] [PATCH] scheduler rate controller
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Sun, Dec 11, 2011 at 3:27 PM, Lv, Hui <hui.lv@intel.com> wrote:
> Hi George,
>
> Thank you very much for your feedbacks.
> I have finished the measurement work based on the delay method. From the comparable results, 1ms-delay can do as well as SRC patch to gain significant performance boost without obvious drawbacks.
> 1. Basically, the "delay method" can achieve nearly the same benefits as my previous SRC patch, 11% overall performance boost for SPECvirt than original credit scheduler.
> 2. I have tried 1ms delay and 10ms delay, there is no big difference between these two configurations. (1ms is enough to achieve a good performance)
> 3. I have compared different load level response time/latency (low, high, peak), "delay method" didn't bring very much Qos increase.

Thanks Hui, those are good results.  Just one question: What's QoS
supposed to measure?  Is this a metric that SPECVirt reports?  Is
higher or lower better?

The patch looks good, but there's one last nitpick: Several of your
lines have hard tab characters in them; tabs are officially verboten
in the Xen code.  Please replace them with spaces.  After that, I
think we're ready to check it in.

One more small request: would it be possible to get some short xen
traces of SPECVirt running, at least with the 1ms-delay patch, and if
possible without it?  I'd like to have a better understanding of what
kind of scheduling workload SPECVirt creates, and how the 1ms delay
affects it.  If you have other priorities, don't worry, I'll wait
until our performance team here gets it set up.  If you do have time,
the command to use is as follows:

xentrace -D -e 0x21000 -T 30 /path/to/file.trace

This will take *just* scheduling traces for 30 seconds.  If you could
run it when the benchmark is going full throttle, that should help me
get an idea what the scheduling looks like.

Thanks,
 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 11:52:09 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 11:52:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ra4Q6-0000GS-DZ; Mon, 12 Dec 2011 11:51:46 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Ra4Q5-0000GL-6T
	for Xen-devel@lists.xensource.com; Mon, 12 Dec 2011 11:51:45 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1323690652!7104984!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDc4NQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23042 invoked from network); 12 Dec 2011 11:50:52 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Dec 2011 11:50:52 -0000
X-IronPort-AV: E=Sophos;i="4.71,338,1320624000"; 
   d="scan'208";a="9414210"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Dec 2011 11:50:52 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 12 Dec 2011 11:50:52 +0000
Date: Mon, 12 Dec 2011 11:52:13 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1323687897.20077.153.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1112121147580.3517@kaball-desktop>
References: <20111209175149.1e50bae0@mantra.us.oracle.com>
	<1323687897.20077.153.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] HYBRID: SMP without HAP (PV MMU)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 12 Dec 2011, Ian Campbell wrote:
> My expectation (until you mentioned the above) was that the option to
> run without HAP would be only really used as a debug aid or to measure
> the specific impact of HAP so it wasn't really that important if it
> turned out to be hard.

I agree with Ian. Covering all the "PV spectrum" could be interesting
from a technical point of view but not that useful. Not worth the effort
if it turns out to be hard.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 11:52:09 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 11:52:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ra4Q6-0000GS-DZ; Mon, 12 Dec 2011 11:51:46 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Ra4Q5-0000GL-6T
	for Xen-devel@lists.xensource.com; Mon, 12 Dec 2011 11:51:45 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1323690652!7104984!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDc4NQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23042 invoked from network); 12 Dec 2011 11:50:52 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Dec 2011 11:50:52 -0000
X-IronPort-AV: E=Sophos;i="4.71,338,1320624000"; 
   d="scan'208";a="9414210"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Dec 2011 11:50:52 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 12 Dec 2011 11:50:52 +0000
Date: Mon, 12 Dec 2011 11:52:13 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1323687897.20077.153.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1112121147580.3517@kaball-desktop>
References: <20111209175149.1e50bae0@mantra.us.oracle.com>
	<1323687897.20077.153.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] HYBRID: SMP without HAP (PV MMU)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 12 Dec 2011, Ian Campbell wrote:
> My expectation (until you mentioned the above) was that the option to
> run without HAP would be only really used as a debug aid or to measure
> the specific impact of HAP so it wasn't really that important if it
> turned out to be hard.

I agree with Ian. Covering all the "PV spectrum" could be interesting
from a technical point of view but not that useful. Not worth the effort
if it turns out to be hard.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 11:55:02 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 11:55:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ra4Sx-0000MU-07; Mon, 12 Dec 2011 11:54:43 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Ra4Sv-0000MK-R8
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 11:54:42 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1323690827!6880535!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDc4NQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23515 invoked from network); 12 Dec 2011 11:53:48 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Dec 2011 11:53:48 -0000
X-IronPort-AV: E=Sophos;i="4.71,338,1320624000"; 
   d="scan'208";a="9414281"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Dec 2011 11:53:33 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 12 Dec 2011 11:53:33 +0000
Date: Mon, 12 Dec 2011 11:54:54 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Jan Beulich <JBeulich@suse.com>
In-Reply-To: <4EE5D20B0200007800066DB8@nat28.tlf.novell.com>
Message-ID: <alpine.DEB.2.00.1112121153550.3517@kaball-desktop>
References: <CAFQ2Z+fpR1UkxFEAYTD6irBUBeA3c7eJ3x1bXE0jzpdfQtH64w@mail.gmail.com>
	<alpine.DEB.2.00.1112021223190.31179@kaball-desktop>
	<4EDE367D0200007800065B6B@nat28.tlf.novell.com>
	<alpine.DEB.2.00.1112061906550.31179@kaball-desktop>
	<04F972F38B3C4E4E91C4697DA8BF9F52846C7517E8@shsmsx502.ccr.corp.intel.com>
	<4EE5D20B0200007800066DB8@nat28.tlf.novell.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Haitao Shan <haitao.shan@intel.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Haitao Shan <maillists.shan@gmail.com>
Subject: Re: [Xen-devel] [PATCH] Qemu MSI Cleaning Up
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 12 Dec 2011, Jan Beulich wrote:
> >>> On 09.12.11 at 07:01, "Shan, Haitao" <haitao.shan@intel.com> wrote:
> > Fine to me! Thanks, Jan!
> > 
> > Shan Haitao
> 
> Ian,
> 
> any chance to get this committed then?
> 
> Also, how are we going to deal with the "modern" qemu tree (is
> passthrough for Xen implemented at all in that tree)?

It is only a patch series at the moment, even though it is close to be
merged upstream I believe.

This is the link to the last version:

http://marc.info/?l=qemu-devel&m=132215676720458&w=2

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 11:55:02 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 11:55:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ra4Sx-0000MU-07; Mon, 12 Dec 2011 11:54:43 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Ra4Sv-0000MK-R8
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 11:54:42 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1323690827!6880535!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDc4NQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23515 invoked from network); 12 Dec 2011 11:53:48 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Dec 2011 11:53:48 -0000
X-IronPort-AV: E=Sophos;i="4.71,338,1320624000"; 
   d="scan'208";a="9414281"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Dec 2011 11:53:33 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 12 Dec 2011 11:53:33 +0000
Date: Mon, 12 Dec 2011 11:54:54 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Jan Beulich <JBeulich@suse.com>
In-Reply-To: <4EE5D20B0200007800066DB8@nat28.tlf.novell.com>
Message-ID: <alpine.DEB.2.00.1112121153550.3517@kaball-desktop>
References: <CAFQ2Z+fpR1UkxFEAYTD6irBUBeA3c7eJ3x1bXE0jzpdfQtH64w@mail.gmail.com>
	<alpine.DEB.2.00.1112021223190.31179@kaball-desktop>
	<4EDE367D0200007800065B6B@nat28.tlf.novell.com>
	<alpine.DEB.2.00.1112061906550.31179@kaball-desktop>
	<04F972F38B3C4E4E91C4697DA8BF9F52846C7517E8@shsmsx502.ccr.corp.intel.com>
	<4EE5D20B0200007800066DB8@nat28.tlf.novell.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Haitao Shan <haitao.shan@intel.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Haitao Shan <maillists.shan@gmail.com>
Subject: Re: [Xen-devel] [PATCH] Qemu MSI Cleaning Up
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 12 Dec 2011, Jan Beulich wrote:
> >>> On 09.12.11 at 07:01, "Shan, Haitao" <haitao.shan@intel.com> wrote:
> > Fine to me! Thanks, Jan!
> > 
> > Shan Haitao
> 
> Ian,
> 
> any chance to get this committed then?
> 
> Also, how are we going to deal with the "modern" qemu tree (is
> passthrough for Xen implemented at all in that tree)?

It is only a patch series at the moment, even though it is close to be
merged upstream I believe.

This is the link to the last version:

http://marc.info/?l=qemu-devel&m=132215676720458&w=2

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 12:09:54 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 12:09:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ra4hJ-0000oc-60; Mon, 12 Dec 2011 12:09:33 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Ra4hI-0000oX-9O
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 12:09:32 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1323691719!5194104!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDc4NQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16212 invoked from network); 12 Dec 2011 12:08:39 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Dec 2011 12:08:39 -0000
X-IronPort-AV: E=Sophos;i="4.71,338,1320624000"; 
   d="scan'208";a="9414650"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Dec 2011 12:08:12 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 12 Dec 2011 12:08:12 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Ra4g0-0006rF-1A; Mon, 12 Dec 2011 12:08:12 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Ra4g0-0005wc-0N;
	Mon, 12 Dec 2011 12:08:12 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20197.61100.1047.581173@mariner.uk.xensource.com>
Date: Mon, 12 Dec 2011 12:08:12 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1323463786.20936.19.camel@dagon.hellion.org.uk>
References: <1323456877-15315-1-git-send-email-ian.jackson@eu.citrix.com>
	<1323456877-15315-16-git-send-email-ian.jackson@eu.citrix.com>
	<1323463786.20936.19.camel@dagon.hellion.org.uk>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 15/18] xenstore: New function
 xs_path_is_subpath
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("Re: [Xen-devel] [PATCH 15/18] xenstore: New function xs_path_is_subpath"):
> On Fri, 2011-12-09 at 18:54 +0000, Ian Jackson wrote:
> > +	if (childlen > parentlen && child[parentlen] != '/')
> > +		return false;
> 
> It took me a second to figure that this last statement was preventing
> false positives from sibling directories where one is a substring of the
> other. Worth a comment?

Probably, yes.

> Doesn't the correctness of this depend on whether parent has a trailing
> slash or not though?

We don't allow trailing slashes.  They don't work in xenstore
operations.  However, there is one exception: "/".  If parent is "/"
the algorithm is wrong.

So docs/misc/xenstore.txt needs updating to clarify the former and my
new function needs the latter fixing.

These are the perils of taking code that was correct in situ and
making a general function out of it, I guess ...

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 12:09:54 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 12:09:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ra4hJ-0000oc-60; Mon, 12 Dec 2011 12:09:33 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Ra4hI-0000oX-9O
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 12:09:32 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1323691719!5194104!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDc4NQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16212 invoked from network); 12 Dec 2011 12:08:39 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Dec 2011 12:08:39 -0000
X-IronPort-AV: E=Sophos;i="4.71,338,1320624000"; 
   d="scan'208";a="9414650"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Dec 2011 12:08:12 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 12 Dec 2011 12:08:12 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Ra4g0-0006rF-1A; Mon, 12 Dec 2011 12:08:12 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Ra4g0-0005wc-0N;
	Mon, 12 Dec 2011 12:08:12 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20197.61100.1047.581173@mariner.uk.xensource.com>
Date: Mon, 12 Dec 2011 12:08:12 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1323463786.20936.19.camel@dagon.hellion.org.uk>
References: <1323456877-15315-1-git-send-email-ian.jackson@eu.citrix.com>
	<1323456877-15315-16-git-send-email-ian.jackson@eu.citrix.com>
	<1323463786.20936.19.camel@dagon.hellion.org.uk>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 15/18] xenstore: New function
 xs_path_is_subpath
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("Re: [Xen-devel] [PATCH 15/18] xenstore: New function xs_path_is_subpath"):
> On Fri, 2011-12-09 at 18:54 +0000, Ian Jackson wrote:
> > +	if (childlen > parentlen && child[parentlen] != '/')
> > +		return false;
> 
> It took me a second to figure that this last statement was preventing
> false positives from sibling directories where one is a substring of the
> other. Worth a comment?

Probably, yes.

> Doesn't the correctness of this depend on whether parent has a trailing
> slash or not though?

We don't allow trailing slashes.  They don't work in xenstore
operations.  However, there is one exception: "/".  If parent is "/"
the algorithm is wrong.

So docs/misc/xenstore.txt needs updating to clarify the former and my
new function needs the latter fixing.

These are the perils of taking code that was correct in situ and
making a general function out of it, I guess ...

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 12:18:10 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 12:18:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ra4pH-00012e-EU; Mon, 12 Dec 2011 12:17:47 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Ra4pG-00012Y-6w
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 12:17:46 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1323692080!6989789!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDc4NQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10145 invoked from network); 12 Dec 2011 12:14:40 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Dec 2011 12:14:40 -0000
X-IronPort-AV: E=Sophos;i="4.71,338,1320624000"; 
   d="scan'208";a="9414862"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Dec 2011 12:14:40 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 12 Dec 2011 12:14:40 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Ra4mG-0006tR-Cw; Mon, 12 Dec 2011 12:14:40 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Ra4mG-0005xr-BL;
	Mon, 12 Dec 2011 12:14:40 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20197.61488.97571.727445@mariner.uk.xensource.com>
Date: Mon, 12 Dec 2011 12:14:40 +0000
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
In-Reply-To: <e16f5d2643c910d9b8c1.1323472553@xdev.gridcentric.ca>
References: <patchbomb.1323472550@xdev.gridcentric.ca>
	<e16f5d2643c910d9b8c1.1323472553@xdev.gridcentric.ca>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "andres@gridcentric.ca" <andres@gridcentric.ca>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Tim
	\(Xen.org\)" <tim@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	"adin@gridcentric.ca" <adin@gridcentric.ca>
Subject: Re: [Xen-devel] [PATCH 3 of 8] Tools: Update memshr tool to use new
	sharing API
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Andres Lagar-Cavilla writes ("[PATCH 3 of 8] Tools: Update memshr tool to use new sharing API"):
>  #ifdef MEMSHR
> -       image->memshr_id = memshr_vbd_image_get(file);
> +       image->memshr_id = memshr_vbd_image_get((char *)file);

This case would be unnecessary if memshr_vbd_image_get was
const-correct, which I think would be better.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 12:18:10 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 12:18:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ra4pH-00012e-EU; Mon, 12 Dec 2011 12:17:47 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Ra4pG-00012Y-6w
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 12:17:46 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1323692080!6989789!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDc4NQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10145 invoked from network); 12 Dec 2011 12:14:40 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Dec 2011 12:14:40 -0000
X-IronPort-AV: E=Sophos;i="4.71,338,1320624000"; 
   d="scan'208";a="9414862"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Dec 2011 12:14:40 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 12 Dec 2011 12:14:40 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Ra4mG-0006tR-Cw; Mon, 12 Dec 2011 12:14:40 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Ra4mG-0005xr-BL;
	Mon, 12 Dec 2011 12:14:40 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20197.61488.97571.727445@mariner.uk.xensource.com>
Date: Mon, 12 Dec 2011 12:14:40 +0000
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
In-Reply-To: <e16f5d2643c910d9b8c1.1323472553@xdev.gridcentric.ca>
References: <patchbomb.1323472550@xdev.gridcentric.ca>
	<e16f5d2643c910d9b8c1.1323472553@xdev.gridcentric.ca>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "andres@gridcentric.ca" <andres@gridcentric.ca>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Tim
	\(Xen.org\)" <tim@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	"adin@gridcentric.ca" <adin@gridcentric.ca>
Subject: Re: [Xen-devel] [PATCH 3 of 8] Tools: Update memshr tool to use new
	sharing API
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Andres Lagar-Cavilla writes ("[PATCH 3 of 8] Tools: Update memshr tool to use new sharing API"):
>  #ifdef MEMSHR
> -       image->memshr_id = memshr_vbd_image_get(file);
> +       image->memshr_id = memshr_vbd_image_get((char *)file);

This case would be unnecessary if memshr_vbd_image_get was
const-correct, which I think would be better.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 12:18:17 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 12:18:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ra4pU-00013Q-Rs; Mon, 12 Dec 2011 12:18:00 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Ra4pS-00012z-UO
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 12:17:59 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1323692225!7602588!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDc4NQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27952 invoked from network); 12 Dec 2011 12:17:05 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Dec 2011 12:17:05 -0000
X-IronPort-AV: E=Sophos;i="4.71,338,1320624000"; 
   d="scan'208";a="9414975"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Dec 2011 12:17:05 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 12 Dec 2011 12:17:05 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Mon, 12 Dec 2011 12:17:05 +0000
In-Reply-To: <20197.59428.699013.507183@mariner.uk.xensource.com>
References: <1323108621-22654-1-git-send-email-ian.jackson@eu.citrix.com>
	<1323108621-22654-16-git-send-email-ian.jackson@eu.citrix.com>
	<alpine.DEB.2.00.1112091558300.3517@kaball-desktop>
	<20194.22539.574524.956955@mariner.uk.xensource.com>
	<1323463293.20936.11.camel@dagon.hellion.org.uk>
	<20197.59428.699013.507183@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323692225.20077.183.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 15/15] libxl: New event generation API
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2011-12-12 at 11:40 +0000, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [PATCH 15/15] libxl: New event generation API"):
> > Stepping back a bit: Since the lock is recursive do we really need the
> > unlocked version? All the callers of event_check_unlocked (apart from
> > libxl_event_check) could call libxl_event_check instead.
> 
> Well, we have to have an internal version because we don't want to
> call GC_INIT again, obviously.

In this case it would take a ctx not a gc and it's ok and expected for
libxl a function calling another libxl function to end up with another
gc in the inner function (it happens all the time).

> Since the callers all take the lock the internal version doesn't have to.
> 
> It would be possible to have these functions pointlessly reacquire the
> lock, I guess, and rename it to "beforepoll_internal" etc.

My point was that the "unlocked" version of the function makes naming
the function confusing (or at least has led to some degree of
bikeshedding) and that there is nothing wrong with pointlessly taking a
recursive lock twice so we could avoid the issue by just having the
external version and using it internally as well.

IOW if you make beforepoll_internal take the lock as you suggest then
you may as well inline it into libxl_osevent_beforepoll (removing the
second lock use) and use that internally too.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 12:18:17 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 12:18:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ra4pU-00013Q-Rs; Mon, 12 Dec 2011 12:18:00 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Ra4pS-00012z-UO
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 12:17:59 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1323692225!7602588!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDc4NQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27952 invoked from network); 12 Dec 2011 12:17:05 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Dec 2011 12:17:05 -0000
X-IronPort-AV: E=Sophos;i="4.71,338,1320624000"; 
   d="scan'208";a="9414975"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Dec 2011 12:17:05 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 12 Dec 2011 12:17:05 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Mon, 12 Dec 2011 12:17:05 +0000
In-Reply-To: <20197.59428.699013.507183@mariner.uk.xensource.com>
References: <1323108621-22654-1-git-send-email-ian.jackson@eu.citrix.com>
	<1323108621-22654-16-git-send-email-ian.jackson@eu.citrix.com>
	<alpine.DEB.2.00.1112091558300.3517@kaball-desktop>
	<20194.22539.574524.956955@mariner.uk.xensource.com>
	<1323463293.20936.11.camel@dagon.hellion.org.uk>
	<20197.59428.699013.507183@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323692225.20077.183.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 15/15] libxl: New event generation API
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2011-12-12 at 11:40 +0000, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [PATCH 15/15] libxl: New event generation API"):
> > Stepping back a bit: Since the lock is recursive do we really need the
> > unlocked version? All the callers of event_check_unlocked (apart from
> > libxl_event_check) could call libxl_event_check instead.
> 
> Well, we have to have an internal version because we don't want to
> call GC_INIT again, obviously.

In this case it would take a ctx not a gc and it's ok and expected for
libxl a function calling another libxl function to end up with another
gc in the inner function (it happens all the time).

> Since the callers all take the lock the internal version doesn't have to.
> 
> It would be possible to have these functions pointlessly reacquire the
> lock, I guess, and rename it to "beforepoll_internal" etc.

My point was that the "unlocked" version of the function makes naming
the function confusing (or at least has led to some degree of
bikeshedding) and that there is nothing wrong with pointlessly taking a
recursive lock twice so we could avoid the issue by just having the
external version and using it internally as well.

IOW if you make beforepoll_internal take the lock as you suggest then
you may as well inline it into libxl_osevent_beforepoll (removing the
second lock use) and use that internally too.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 12:32:12 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 12: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.xensource.com>)
	id 1Ra52r-0001Pu-9o; Mon, 12 Dec 2011 12:31:49 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Ra52q-0001Pp-2L
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 12:31:48 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1323693054!5183448!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDc4NQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15073 invoked from network); 12 Dec 2011 12:30:55 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Dec 2011 12:30:55 -0000
X-IronPort-AV: E=Sophos;i="4.71,338,1320624000"; 
   d="scan'208";a="9415354"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Dec 2011 12:30:54 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 12 Dec 2011 12:30:54 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Ra51y-0006zK-7H; Mon, 12 Dec 2011 12:30:54 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Ra51y-0005zE-6X;
	Mon, 12 Dec 2011 12:30:54 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20197.62462.189827.239656@mariner.uk.xensource.com>
Date: Mon, 12 Dec 2011 12:30:54 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1323692225.20077.183.camel@zakaz.uk.xensource.com>
References: <1323108621-22654-1-git-send-email-ian.jackson@eu.citrix.com>
	<1323108621-22654-16-git-send-email-ian.jackson@eu.citrix.com>
	<alpine.DEB.2.00.1112091558300.3517@kaball-desktop>
	<20194.22539.574524.956955@mariner.uk.xensource.com>
	<1323463293.20936.11.camel@dagon.hellion.org.uk>
	<20197.59428.699013.507183@mariner.uk.xensource.com>
	<1323692225.20077.183.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 15/15] libxl: New event generation API
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("Re: [Xen-devel] [PATCH 15/15] libxl: New event generation API"):
> On Mon, 2011-12-12 at 11:40 +0000, Ian Jackson wrote:
> > Well, we have to have an internal version because we don't want to
> > call GC_INIT again, obviously.
> 
> In this case it would take a ctx not a gc and it's ok and expected for
> libxl a function calling another libxl function to end up with another
> gc in the inner function (it happens all the time).

This is not allowed in functions which might generate events (ie,
which might call libxl__event_occurred), because the application's
event callback will be called at an unexpected point in libxl's
execution.  This has three problems:

 * There is a reentrancy hazard.  Exactly whether this is a problem in
   a specific case is difficult to analyse; hence the recording of
   pending callbacks in the gc, so that they can be delayed until the
   gc is freed.

 * The application's callbacks will be called with the libxl ctx
   locked.  This might result in deadlock.

 * The  application's callbacks  might be  called in  the  wrong order
   because the  inner gc (containing  later events) is  unwound before
   the outer gc (containing earlier events).

In general this means that functions which lock the ctx must not
allocate an inner gc.

> IOW if you make beforepoll_internal take the lock as you suggest then
> you may as well inline it into libxl_osevent_beforepoll (removing the
> second lock use) and use that internally too.

beforepoll_unlocked is called in two places: libxl_osevent_beforepoll,
and libxl_event_wait.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 12:32:12 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 12: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.xensource.com>)
	id 1Ra52r-0001Pu-9o; Mon, 12 Dec 2011 12:31:49 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Ra52q-0001Pp-2L
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 12:31:48 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1323693054!5183448!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDc4NQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15073 invoked from network); 12 Dec 2011 12:30:55 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Dec 2011 12:30:55 -0000
X-IronPort-AV: E=Sophos;i="4.71,338,1320624000"; 
   d="scan'208";a="9415354"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Dec 2011 12:30:54 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 12 Dec 2011 12:30:54 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Ra51y-0006zK-7H; Mon, 12 Dec 2011 12:30:54 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Ra51y-0005zE-6X;
	Mon, 12 Dec 2011 12:30:54 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20197.62462.189827.239656@mariner.uk.xensource.com>
Date: Mon, 12 Dec 2011 12:30:54 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1323692225.20077.183.camel@zakaz.uk.xensource.com>
References: <1323108621-22654-1-git-send-email-ian.jackson@eu.citrix.com>
	<1323108621-22654-16-git-send-email-ian.jackson@eu.citrix.com>
	<alpine.DEB.2.00.1112091558300.3517@kaball-desktop>
	<20194.22539.574524.956955@mariner.uk.xensource.com>
	<1323463293.20936.11.camel@dagon.hellion.org.uk>
	<20197.59428.699013.507183@mariner.uk.xensource.com>
	<1323692225.20077.183.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 15/15] libxl: New event generation API
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("Re: [Xen-devel] [PATCH 15/15] libxl: New event generation API"):
> On Mon, 2011-12-12 at 11:40 +0000, Ian Jackson wrote:
> > Well, we have to have an internal version because we don't want to
> > call GC_INIT again, obviously.
> 
> In this case it would take a ctx not a gc and it's ok and expected for
> libxl a function calling another libxl function to end up with another
> gc in the inner function (it happens all the time).

This is not allowed in functions which might generate events (ie,
which might call libxl__event_occurred), because the application's
event callback will be called at an unexpected point in libxl's
execution.  This has three problems:

 * There is a reentrancy hazard.  Exactly whether this is a problem in
   a specific case is difficult to analyse; hence the recording of
   pending callbacks in the gc, so that they can be delayed until the
   gc is freed.

 * The application's callbacks will be called with the libxl ctx
   locked.  This might result in deadlock.

 * The  application's callbacks  might be  called in  the  wrong order
   because the  inner gc (containing  later events) is  unwound before
   the outer gc (containing earlier events).

In general this means that functions which lock the ctx must not
allocate an inner gc.

> IOW if you make beforepoll_internal take the lock as you suggest then
> you may as well inline it into libxl_osevent_beforepoll (removing the
> second lock use) and use that internally too.

beforepoll_unlocked is called in two places: libxl_osevent_beforepoll,
and libxl_event_wait.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 12:53:12 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 12: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.xensource.com>)
	id 1Ra5NB-0001bd-BQ; Mon, 12 Dec 2011 12:52:49 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Ra5N9-0001bY-8x
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 12:52:47 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1323694314!7006279!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDc4NQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27940 invoked from network); 12 Dec 2011 12:51:54 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Dec 2011 12:51:54 -0000
X-IronPort-AV: E=Sophos;i="4.71,338,1320624000"; 
   d="scan'208";a="9415922"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Dec 2011 12:51:54 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 12 Dec 2011 12:51:54 +0000
Date: Mon, 12 Dec 2011 12:53:16 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Anthony PERARD <anthony.perard@citrix.com>
In-Reply-To: <1323467645-24271-3-git-send-email-anthony.perard@citrix.com>
Message-ID: <alpine.DEB.2.00.1112121241580.3517@kaball-desktop>
References: <1323467645-24271-1-git-send-email-anthony.perard@citrix.com>
	<1323467645-24271-3-git-send-email-anthony.perard@citrix.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Xen Devel <xen-devel@lists.xensource.com>,
	QEMU-devel <qemu-devel@nongnu.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH V2 2/5] xen mapcache: Check if a memory
 space has moved.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 9 Dec 2011, Anthony PERARD wrote:
> This patch change the xen_map_cache behavior. Before trying to map a guest
> addr, mapcache will look into the list of range of address that have been moved
> (physmap/set_memory). There is currently one memory space like this, the vram,
> "moved" from were it's allocated to were the guest will look into.
> 
> This help to have a succefull migration.
> 
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> ---
>  xen-all.c      |   18 +++++++++++++++++-
>  xen-mapcache.c |   22 +++++++++++++++++++---
>  xen-mapcache.h |    9 +++++++--
>  3 files changed, 43 insertions(+), 6 deletions(-)
> 
> diff --git a/xen-all.c b/xen-all.c
> index b5e28ab..b2e9853 100644
> --- a/xen-all.c
> +++ b/xen-all.c
> @@ -218,6 +218,22 @@ static XenPhysmap *get_physmapping(XenIOState *state,
>      return NULL;
>  }
>  
> +static target_phys_addr_t xen_phys_offset_to_gaddr(target_phys_addr_t start_addr,
> +                                                   ram_addr_t size, void *opaque)
> +{
> +    target_phys_addr_t addr = start_addr & TARGET_PAGE_MASK;
> +    XenIOState *xen_io_state = opaque;
> +    XenPhysmap *physmap = NULL;
> +    QLIST_FOREACH(physmap, &xen_io_state->physmap, list) {
> +        if (range_covers_byte(physmap->phys_offset, physmap->size, addr)) {
> +            return physmap->start_addr;
> +        }
> +    }
> +
> +    return start_addr;
> +}

Considering that xen_phys_offset_to_gaddr can be called with addresses
that are not page aligned, you should be able to return the translated
address with the right offset in the page, rather than just the
translated address, that is incorrect.
Otherwise if start_addr has to be page aligned, just add a BUG_ON at
the beginning of the function, to spot cases in which it is not.


>  #if CONFIG_XEN_CTRL_INTERFACE_VERSION >= 340
>  static int xen_add_to_physmap(XenIOState *state,
>                                target_phys_addr_t start_addr,
> @@ -938,7 +954,7 @@ int xen_hvm_init(void)
>      }
>  
>      /* Init RAM management */
> -    xen_map_cache_init();
> +    xen_map_cache_init(xen_phys_offset_to_gaddr, state);
>      xen_ram_init(ram_size);

This patch is better than the previous version but I think there is
still room for improvement.
For example, the only case in which xen_phys_offset_to_gaddr should
actually be used is for the videoram on restore, right?
In that case, why don't we set xen_phys_offset_to_gaddr only on restore
rather than all cases?
We could even unset xen_phys_offset_to_gaddr after the videoram address
has been translated correctly so that it is going to be called only once.



>      qemu_add_vm_change_state_handler(xen_hvm_change_state_handler, state);
> diff --git a/xen-mapcache.c b/xen-mapcache.c
> index 7bcb86e..d5f52b2 100644
> --- a/xen-mapcache.c
> +++ b/xen-mapcache.c
> @@ -76,6 +76,9 @@ typedef struct MapCache {
>      uint8_t *last_address_vaddr;
>      unsigned long max_mcache_size;
>      unsigned int mcache_bucket_shift;
> +
> +    phys_offset_to_gaddr_t phys_offset_to_gaddr;
> +    void *opaque;
>  } MapCache;
>  
>  static MapCache *mapcache;
> @@ -89,13 +92,16 @@ static inline int test_bits(int nr, int size, const unsigned long *addr)
>          return 0;
>  }
>  
> -void xen_map_cache_init(void)
> +void xen_map_cache_init(phys_offset_to_gaddr_t f, void *opaque)
>  {
>      unsigned long size;
>      struct rlimit rlimit_as;
>  
>      mapcache = g_malloc0(sizeof (MapCache));
>  
> +    mapcache->phys_offset_to_gaddr = f;
> +    mapcache->opaque = opaque;
> +
>      QTAILQ_INIT(&mapcache->locked_entries);
>      mapcache->last_address_index = -1;
>  
> @@ -191,9 +197,14 @@ uint8_t *xen_map_cache(target_phys_addr_t phys_addr, target_phys_addr_t size,
>                         uint8_t lock)
>  {
>      MapCacheEntry *entry, *pentry = NULL;
> -    target_phys_addr_t address_index  = phys_addr >> MCACHE_BUCKET_SHIFT;
> -    target_phys_addr_t address_offset = phys_addr & (MCACHE_BUCKET_SIZE - 1);
> +    target_phys_addr_t address_index;
> +    target_phys_addr_t address_offset;
>      target_phys_addr_t __size = size;
> +    bool translated = false;
> +
> +tryagain:
> +    address_index  = phys_addr >> MCACHE_BUCKET_SHIFT;
> +    address_offset = phys_addr & (MCACHE_BUCKET_SIZE - 1);
>  
>      trace_xen_map_cache(phys_addr);
>  
> @@ -235,6 +246,11 @@ uint8_t *xen_map_cache(target_phys_addr_t phys_addr, target_phys_addr_t size,
>      if(!test_bits(address_offset >> XC_PAGE_SHIFT, size >> XC_PAGE_SHIFT,
>                  entry->valid_mapping)) {
>          mapcache->last_address_index = -1;
> +        if (!translated && mapcache->phys_offset_to_gaddr) {
> +            phys_addr = mapcache->phys_offset_to_gaddr(phys_addr, size, mapcache->opaque);
> +            translated = true;
> +            goto tryagain;
> +        }
>          trace_xen_map_cache_return(NULL);
>          return NULL;
>      }

It would be interesting to check how many times we end up needlessly
calling phys_offset_to_gaddr during the normal life of a VM. It should
be very few, may only one, right?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 12:53:12 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 12: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.xensource.com>)
	id 1Ra5NB-0001bd-BQ; Mon, 12 Dec 2011 12:52:49 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Ra5N9-0001bY-8x
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 12:52:47 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1323694314!7006279!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDc4NQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27940 invoked from network); 12 Dec 2011 12:51:54 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Dec 2011 12:51:54 -0000
X-IronPort-AV: E=Sophos;i="4.71,338,1320624000"; 
   d="scan'208";a="9415922"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Dec 2011 12:51:54 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 12 Dec 2011 12:51:54 +0000
Date: Mon, 12 Dec 2011 12:53:16 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Anthony PERARD <anthony.perard@citrix.com>
In-Reply-To: <1323467645-24271-3-git-send-email-anthony.perard@citrix.com>
Message-ID: <alpine.DEB.2.00.1112121241580.3517@kaball-desktop>
References: <1323467645-24271-1-git-send-email-anthony.perard@citrix.com>
	<1323467645-24271-3-git-send-email-anthony.perard@citrix.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Xen Devel <xen-devel@lists.xensource.com>,
	QEMU-devel <qemu-devel@nongnu.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH V2 2/5] xen mapcache: Check if a memory
 space has moved.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 9 Dec 2011, Anthony PERARD wrote:
> This patch change the xen_map_cache behavior. Before trying to map a guest
> addr, mapcache will look into the list of range of address that have been moved
> (physmap/set_memory). There is currently one memory space like this, the vram,
> "moved" from were it's allocated to were the guest will look into.
> 
> This help to have a succefull migration.
> 
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> ---
>  xen-all.c      |   18 +++++++++++++++++-
>  xen-mapcache.c |   22 +++++++++++++++++++---
>  xen-mapcache.h |    9 +++++++--
>  3 files changed, 43 insertions(+), 6 deletions(-)
> 
> diff --git a/xen-all.c b/xen-all.c
> index b5e28ab..b2e9853 100644
> --- a/xen-all.c
> +++ b/xen-all.c
> @@ -218,6 +218,22 @@ static XenPhysmap *get_physmapping(XenIOState *state,
>      return NULL;
>  }
>  
> +static target_phys_addr_t xen_phys_offset_to_gaddr(target_phys_addr_t start_addr,
> +                                                   ram_addr_t size, void *opaque)
> +{
> +    target_phys_addr_t addr = start_addr & TARGET_PAGE_MASK;
> +    XenIOState *xen_io_state = opaque;
> +    XenPhysmap *physmap = NULL;
> +    QLIST_FOREACH(physmap, &xen_io_state->physmap, list) {
> +        if (range_covers_byte(physmap->phys_offset, physmap->size, addr)) {
> +            return physmap->start_addr;
> +        }
> +    }
> +
> +    return start_addr;
> +}

Considering that xen_phys_offset_to_gaddr can be called with addresses
that are not page aligned, you should be able to return the translated
address with the right offset in the page, rather than just the
translated address, that is incorrect.
Otherwise if start_addr has to be page aligned, just add a BUG_ON at
the beginning of the function, to spot cases in which it is not.


>  #if CONFIG_XEN_CTRL_INTERFACE_VERSION >= 340
>  static int xen_add_to_physmap(XenIOState *state,
>                                target_phys_addr_t start_addr,
> @@ -938,7 +954,7 @@ int xen_hvm_init(void)
>      }
>  
>      /* Init RAM management */
> -    xen_map_cache_init();
> +    xen_map_cache_init(xen_phys_offset_to_gaddr, state);
>      xen_ram_init(ram_size);

This patch is better than the previous version but I think there is
still room for improvement.
For example, the only case in which xen_phys_offset_to_gaddr should
actually be used is for the videoram on restore, right?
In that case, why don't we set xen_phys_offset_to_gaddr only on restore
rather than all cases?
We could even unset xen_phys_offset_to_gaddr after the videoram address
has been translated correctly so that it is going to be called only once.



>      qemu_add_vm_change_state_handler(xen_hvm_change_state_handler, state);
> diff --git a/xen-mapcache.c b/xen-mapcache.c
> index 7bcb86e..d5f52b2 100644
> --- a/xen-mapcache.c
> +++ b/xen-mapcache.c
> @@ -76,6 +76,9 @@ typedef struct MapCache {
>      uint8_t *last_address_vaddr;
>      unsigned long max_mcache_size;
>      unsigned int mcache_bucket_shift;
> +
> +    phys_offset_to_gaddr_t phys_offset_to_gaddr;
> +    void *opaque;
>  } MapCache;
>  
>  static MapCache *mapcache;
> @@ -89,13 +92,16 @@ static inline int test_bits(int nr, int size, const unsigned long *addr)
>          return 0;
>  }
>  
> -void xen_map_cache_init(void)
> +void xen_map_cache_init(phys_offset_to_gaddr_t f, void *opaque)
>  {
>      unsigned long size;
>      struct rlimit rlimit_as;
>  
>      mapcache = g_malloc0(sizeof (MapCache));
>  
> +    mapcache->phys_offset_to_gaddr = f;
> +    mapcache->opaque = opaque;
> +
>      QTAILQ_INIT(&mapcache->locked_entries);
>      mapcache->last_address_index = -1;
>  
> @@ -191,9 +197,14 @@ uint8_t *xen_map_cache(target_phys_addr_t phys_addr, target_phys_addr_t size,
>                         uint8_t lock)
>  {
>      MapCacheEntry *entry, *pentry = NULL;
> -    target_phys_addr_t address_index  = phys_addr >> MCACHE_BUCKET_SHIFT;
> -    target_phys_addr_t address_offset = phys_addr & (MCACHE_BUCKET_SIZE - 1);
> +    target_phys_addr_t address_index;
> +    target_phys_addr_t address_offset;
>      target_phys_addr_t __size = size;
> +    bool translated = false;
> +
> +tryagain:
> +    address_index  = phys_addr >> MCACHE_BUCKET_SHIFT;
> +    address_offset = phys_addr & (MCACHE_BUCKET_SIZE - 1);
>  
>      trace_xen_map_cache(phys_addr);
>  
> @@ -235,6 +246,11 @@ uint8_t *xen_map_cache(target_phys_addr_t phys_addr, target_phys_addr_t size,
>      if(!test_bits(address_offset >> XC_PAGE_SHIFT, size >> XC_PAGE_SHIFT,
>                  entry->valid_mapping)) {
>          mapcache->last_address_index = -1;
> +        if (!translated && mapcache->phys_offset_to_gaddr) {
> +            phys_addr = mapcache->phys_offset_to_gaddr(phys_addr, size, mapcache->opaque);
> +            translated = true;
> +            goto tryagain;
> +        }
>          trace_xen_map_cache_return(NULL);
>          return NULL;
>      }

It would be interesting to check how many times we end up needlessly
calling phys_offset_to_gaddr during the normal life of a VM. It should
be very few, may only one, right?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 12:55:25 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 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.xensource.com>)
	id 1Ra5PG-0001gd-TZ; Mon, 12 Dec 2011 12:54:58 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Ra5PF-0001gF-Pg
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 12:54:57 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1323694444!7125741!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDc4NQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20168 invoked from network); 12 Dec 2011 12:54:05 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Dec 2011 12:54:05 -0000
X-IronPort-AV: E=Sophos;i="4.71,338,1320624000"; 
   d="scan'208";a="9415983"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Dec 2011 12:54:04 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 12 Dec 2011 12:54:04 +0000
Date: Mon, 12 Dec 2011 12:55:26 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Anthony PERARD <anthony.perard@citrix.com>
In-Reply-To: <1323467645-24271-5-git-send-email-anthony.perard@citrix.com>
Message-ID: <alpine.DEB.2.00.1112121254180.3517@kaball-desktop>
References: <1323467645-24271-1-git-send-email-anthony.perard@citrix.com>
	<1323467645-24271-5-git-send-email-anthony.perard@citrix.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Xen Devel <xen-devel@lists.xensource.com>,
	QEMU-devel <qemu-devel@nongnu.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH V2 4/5] xen: Change memory access behavior
 during migration.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 9 Dec 2011, Anthony PERARD wrote:
> Do not allocate RAM during pre-migration runstate.
> Do not actually "do" set_memory during migration.
> 
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> ---
>  xen-all.c |   13 +++++++++++++
>  1 files changed, 13 insertions(+), 0 deletions(-)
> 
> diff --git a/xen-all.c b/xen-all.c
> index b2e9853..c1fed87 100644
> --- a/xen-all.c
> +++ b/xen-all.c
> @@ -189,6 +189,11 @@ void xen_ram_alloc(ram_addr_t ram_addr, ram_addr_t size)
>  
>      trace_xen_ram_alloc(ram_addr, size);
>  
> +    if (runstate_check(RUN_STATE_PREMIGRATE)) {
> +        /* RAM already populated in Xen */
> +        return;
> +    }

It is probably worth printing out a message about the address and size
qemu wanted to allocated


>      nr_pfn = size >> TARGET_PAGE_BITS;
>      pfn_list = g_malloc(sizeof (*pfn_list) * nr_pfn);
>  
> @@ -269,6 +274,13 @@ go_physmap:
>      DPRINTF("mapping vram to %llx - %llx, from %llx\n",
>              start_addr, start_addr + size, phys_offset);
>  
> +    if (runstate_check(RUN_STATE_INMIGRATE)) {
> +        /* The mapping should already be done and can not be done a second
> +         * time. So we just add to the physmap list instead.
> +         */
> +        goto done;
> +    }

same here, printing a message would be useful

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 12:55:25 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 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.xensource.com>)
	id 1Ra5PG-0001gd-TZ; Mon, 12 Dec 2011 12:54:58 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Ra5PF-0001gF-Pg
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 12:54:57 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1323694444!7125741!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDc4NQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20168 invoked from network); 12 Dec 2011 12:54:05 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Dec 2011 12:54:05 -0000
X-IronPort-AV: E=Sophos;i="4.71,338,1320624000"; 
   d="scan'208";a="9415983"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Dec 2011 12:54:04 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 12 Dec 2011 12:54:04 +0000
Date: Mon, 12 Dec 2011 12:55:26 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Anthony PERARD <anthony.perard@citrix.com>
In-Reply-To: <1323467645-24271-5-git-send-email-anthony.perard@citrix.com>
Message-ID: <alpine.DEB.2.00.1112121254180.3517@kaball-desktop>
References: <1323467645-24271-1-git-send-email-anthony.perard@citrix.com>
	<1323467645-24271-5-git-send-email-anthony.perard@citrix.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Xen Devel <xen-devel@lists.xensource.com>,
	QEMU-devel <qemu-devel@nongnu.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH V2 4/5] xen: Change memory access behavior
 during migration.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 9 Dec 2011, Anthony PERARD wrote:
> Do not allocate RAM during pre-migration runstate.
> Do not actually "do" set_memory during migration.
> 
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> ---
>  xen-all.c |   13 +++++++++++++
>  1 files changed, 13 insertions(+), 0 deletions(-)
> 
> diff --git a/xen-all.c b/xen-all.c
> index b2e9853..c1fed87 100644
> --- a/xen-all.c
> +++ b/xen-all.c
> @@ -189,6 +189,11 @@ void xen_ram_alloc(ram_addr_t ram_addr, ram_addr_t size)
>  
>      trace_xen_ram_alloc(ram_addr, size);
>  
> +    if (runstate_check(RUN_STATE_PREMIGRATE)) {
> +        /* RAM already populated in Xen */
> +        return;
> +    }

It is probably worth printing out a message about the address and size
qemu wanted to allocated


>      nr_pfn = size >> TARGET_PAGE_BITS;
>      pfn_list = g_malloc(sizeof (*pfn_list) * nr_pfn);
>  
> @@ -269,6 +274,13 @@ go_physmap:
>      DPRINTF("mapping vram to %llx - %llx, from %llx\n",
>              start_addr, start_addr + size, phys_offset);
>  
> +    if (runstate_check(RUN_STATE_INMIGRATE)) {
> +        /* The mapping should already be done and can not be done a second
> +         * time. So we just add to the physmap list instead.
> +         */
> +        goto done;
> +    }

same here, printing a message would be useful

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 12:58:42 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 12: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.xensource.com>)
	id 1Ra5SW-0001qL-Kn; Mon, 12 Dec 2011 12:58:20 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Ra5SV-0001qG-2s
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 12:58:19 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1323694608!48628766!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDc4NQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19815 invoked from network); 12 Dec 2011 12:56:48 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Dec 2011 12:56:48 -0000
X-IronPort-AV: E=Sophos;i="4.71,338,1320624000"; 
   d="scan'208";a="9416064"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Dec 2011 12:57:31 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 12 Dec 2011 12:57:31 +0000
Date: Mon, 12 Dec 2011 12:58:53 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Anthony PERARD <anthony.perard@citrix.com>
In-Reply-To: <1323467645-24271-6-git-send-email-anthony.perard@citrix.com>
Message-ID: <alpine.DEB.2.00.1112121256590.3517@kaball-desktop>
References: <1323467645-24271-1-git-send-email-anthony.perard@citrix.com>
	<1323467645-24271-6-git-send-email-anthony.perard@citrix.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Xen Devel <xen-devel@lists.xensource.com>,
	QEMU-devel <qemu-devel@nongnu.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH V2 5/5] vga-cirrus: Workaround during
 restore when using Xen.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 9 Dec 2011, Anthony PERARD wrote:
> During the initialisation of the machine at restore time, the access to the
> VRAM will fail because QEMU does not know yet the right guest address to map,
> so the vram_ptr is NULL.
> 
> So this patch avoid using a NULL pointer during initialisation, and try to get
> another vram_ptr if the call failed the first time.

I think it would be a good idea to split this patch into two patches:
one that avoids doing the memset on restore, because it is actually
futile in all cases; and another patch that tries to set the
vga.vram_ptr again in case it is still NULL.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 12:58:42 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 12: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.xensource.com>)
	id 1Ra5SW-0001qL-Kn; Mon, 12 Dec 2011 12:58:20 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Ra5SV-0001qG-2s
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 12:58:19 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1323694608!48628766!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDc4NQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19815 invoked from network); 12 Dec 2011 12:56:48 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Dec 2011 12:56:48 -0000
X-IronPort-AV: E=Sophos;i="4.71,338,1320624000"; 
   d="scan'208";a="9416064"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Dec 2011 12:57:31 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 12 Dec 2011 12:57:31 +0000
Date: Mon, 12 Dec 2011 12:58:53 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Anthony PERARD <anthony.perard@citrix.com>
In-Reply-To: <1323467645-24271-6-git-send-email-anthony.perard@citrix.com>
Message-ID: <alpine.DEB.2.00.1112121256590.3517@kaball-desktop>
References: <1323467645-24271-1-git-send-email-anthony.perard@citrix.com>
	<1323467645-24271-6-git-send-email-anthony.perard@citrix.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Xen Devel <xen-devel@lists.xensource.com>,
	QEMU-devel <qemu-devel@nongnu.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH V2 5/5] vga-cirrus: Workaround during
 restore when using Xen.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 9 Dec 2011, Anthony PERARD wrote:
> During the initialisation of the machine at restore time, the access to the
> VRAM will fail because QEMU does not know yet the right guest address to map,
> so the vram_ptr is NULL.
> 
> So this patch avoid using a NULL pointer during initialisation, and try to get
> another vram_ptr if the call failed the first time.

I think it would be a good idea to split this patch into two patches:
one that avoids doing the memset on restore, because it is actually
futile in all cases; and another patch that tries to set the
vga.vram_ptr again in case it is still NULL.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 13:03:07 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 13: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.xensource.com>)
	id 1Ra5Wj-00029z-HV; Mon, 12 Dec 2011 13:02:41 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1Ra5Wi-00029q-Bp
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 13:02:40 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-13.tower-27.messagelabs.com!1323694884!51808510!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32486 invoked from network); 12 Dec 2011 13:01:24 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-13.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 12 Dec 2011 13:01:24 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1Ra5Vn-0004oW-Ei; Mon, 12 Dec 2011 13:01:43 +0000
Date: Mon, 12 Dec 2011 13:01:43 +0000
From: Tim Deegan <tim@xen.org>
To: jack nemati <hn_nemati1985@yahoo.com>
Message-ID: <20111212130143.GA15468@ocelot.phlegethon.org>
References: <1323687759.14650.YahooMailClassic@web160906.mail.bf1.yahoo.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1323687759.14650.YahooMailClassic@web160906.mail.bf1.yahoo.com>
User-Agent: Mutt/1.4.2.1i
Cc: George Dunlap <dunlapg@umich.edu>, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Xen shadow page table
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hello,

(Please don't top-post)

At 03:02 -0800 on 12 Dec (1323658959), jack nemati wrote:
> I just need to enable the Xen shadow page table (if HAP is not
> possible) in that I need to take the control of dom0's pages in order
> to modify their control flags. is there any solution for this problem.

The way to enable shadow pagetables for dom0 is the "dom0_shadow"
command-line option to xen.

> it's noticeable that, I have enabled this feature by directly setting
> of the opt_dom0_shadow init variable but I cause some CPU stall.

It works fine for me (with a 64-bit dom0 on 64-bit xen from xen-unstable
tip, on an Intel Xeon E5520).  There must be something different about
your setup that causes it to fail. 

(Please read http://wiki.xen.org/wiki/Reporting_Bugs_against_Xen about
how to report errors in Xen.)

Cheers,


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 13:03:07 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 13: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.xensource.com>)
	id 1Ra5Wj-00029z-HV; Mon, 12 Dec 2011 13:02:41 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1Ra5Wi-00029q-Bp
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 13:02:40 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-13.tower-27.messagelabs.com!1323694884!51808510!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32486 invoked from network); 12 Dec 2011 13:01:24 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-13.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 12 Dec 2011 13:01:24 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1Ra5Vn-0004oW-Ei; Mon, 12 Dec 2011 13:01:43 +0000
Date: Mon, 12 Dec 2011 13:01:43 +0000
From: Tim Deegan <tim@xen.org>
To: jack nemati <hn_nemati1985@yahoo.com>
Message-ID: <20111212130143.GA15468@ocelot.phlegethon.org>
References: <1323687759.14650.YahooMailClassic@web160906.mail.bf1.yahoo.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1323687759.14650.YahooMailClassic@web160906.mail.bf1.yahoo.com>
User-Agent: Mutt/1.4.2.1i
Cc: George Dunlap <dunlapg@umich.edu>, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Xen shadow page table
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hello,

(Please don't top-post)

At 03:02 -0800 on 12 Dec (1323658959), jack nemati wrote:
> I just need to enable the Xen shadow page table (if HAP is not
> possible) in that I need to take the control of dom0's pages in order
> to modify their control flags. is there any solution for this problem.

The way to enable shadow pagetables for dom0 is the "dom0_shadow"
command-line option to xen.

> it's noticeable that, I have enabled this feature by directly setting
> of the opt_dom0_shadow init variable but I cause some CPU stall.

It works fine for me (with a 64-bit dom0 on 64-bit xen from xen-unstable
tip, on an Intel Xeon E5520).  There must be something different about
your setup that causes it to fail. 

(Please read http://wiki.xen.org/wiki/Reporting_Bugs_against_Xen about
how to report errors in Xen.)

Cheers,


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 13:19:06 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 13: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.xensource.com>)
	id 1Ra5mC-0002Mg-3y; Mon, 12 Dec 2011 13:18:40 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Ra5mA-0002MY-SS
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 13:18:39 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1323695827!50416234!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDc4NQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10041 invoked from network); 12 Dec 2011 13:17:07 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Dec 2011 13:17:07 -0000
X-IronPort-AV: E=Sophos;i="4.71,339,1320624000"; 
   d="scan'208";a="9416575"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Dec 2011 13:16:43 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 12 Dec 2011 13:16:42 +0000
Date: Mon, 12 Dec 2011 13:18:05 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Jan Kiszka <jan.kiszka@web.de>
In-Reply-To: <4EE3382D.80903@web.de>
Message-ID: <alpine.DEB.2.00.1112121259180.3517@kaball-desktop>
References: <1323467645-24271-1-git-send-email-anthony.perard@citrix.com>
	<1323467645-24271-6-git-send-email-anthony.perard@citrix.com>
	<4EE3382D.80903@web.de>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Anthony Perard <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	QEMU-devel <qemu-devel@nongnu.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH V2 5/5] vga-cirrus: Workaround during
 restore when using Xen.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Sat, 10 Dec 2011, Jan Kiszka wrote:
> On 2011-12-09 22:54, Anthony PERARD wrote:
> > During the initialisation of the machine at restore time, the access to the
> > VRAM will fail because QEMU does not know yet the right guest address to map,
> > so the vram_ptr is NULL.
> > 
> > So this patch avoid using a NULL pointer during initialisation, and try to get
> > another vram_ptr if the call failed the first time.
> > 
> > Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> > ---
> >  hw/cirrus_vga.c |   16 +++++++++++++---
> >  1 files changed, 13 insertions(+), 3 deletions(-)
> > 
> > diff --git a/hw/cirrus_vga.c b/hw/cirrus_vga.c
> > index c7e365b..2e049c9 100644
> > --- a/hw/cirrus_vga.c
> > +++ b/hw/cirrus_vga.c
> > @@ -32,6 +32,7 @@
> >  #include "console.h"
> >  #include "vga_int.h"
> >  #include "loader.h"
> > +#include "sysemu.h"
> >  
> >  /*
> >   * TODO:
> > @@ -2696,6 +2697,13 @@ static int cirrus_post_load(void *opaque, int version_id)
> >      s->vga.gr[0x01] = s->cirrus_shadow_gr1 & 0x0f;
> >  
> >      cirrus_update_memory_access(s);
> > +    if (!s->vga.vram_ptr) {
> > +        /* At this point vga.vram_ptr can be invalid on Xen because we need to
> > +         * know the position of the videoram in the guest physical address space in
> > +         * order to be able to map it. After cirrus_update_memory_access we do know
> > +         * where the videoram is, so let's map it now. */
> > +        s->vga.vram_ptr = memory_region_get_ram_ptr(&s->vga.vram);
> > +    }
> >      /* force refresh */
> >      s->vga.graphic_mode = -1;
> >      cirrus_update_bank_ptr(s, 0);
> > @@ -2784,9 +2792,11 @@ static void cirrus_reset(void *opaque)
> >      }
> >      s->vga.cr[0x27] = s->device_id;
> >  
> > -    /* Win2K seems to assume that the pattern buffer is at 0xff
> > -       initially ! */
> > -    memset(s->vga.vram_ptr, 0xff, s->real_vram_size);
> > +    if (!runstate_check(RUN_STATE_PREMIGRATE)) {
> > +        /* Win2K seems to assume that the pattern buffer is at 0xff
> > +           initially ! */
> > +        memset(s->vga.vram_ptr, 0xff, s->real_vram_size);
> > +    }
> >  
> >      s->cirrus_hidden_dac_lockindex = 5;
> >      s->cirrus_hidden_dac_data = 0;
> 
> Is there really no way to fix this properly in the Xen layer?

We thought about this issue for some time but we couldn't come up with
anything better.
To summarize the problem:

- on restore the videoram has already been loaded in the guest physical
  address space by Xen;

- we don't know exactly where it is yet, because it has been loaded at
  the *last* address it was mapped to (see map_linear_vram_bank that
  moves the videoram);

- we want to avoid allocating the videoram twice (actually the second
  allocation would fail because of memory constraints);



So the solution (I acknowledge that it looks more like an hack than a
solution) is:

- wait for cirrus to load its state so that we know where the videoram
  is;

- map the videoram into qemu's address space at that point.



Anything else we came up with was even worse, for example:

- independently save the position of the videoram and then when
  vga_common_init tries to allocate it for a second time give back the
  old videoram instead;

- move back the videoram to the original position and then move it again
  to the new position.



> This looks
> highly fragile as specifically the second hunk appears unrelated to Xen.

I think that the second chuck should be in a separate patch because it
is unrelated to Xen. On restore it is useless to memset the videoram, so
for performance reasons it would be a good idea to avoid it on all
platforms. Also it happens to crash Qemu on Xen but that is another
story  ;-)

I think we should also add a comment:

"useles to memset the videoram on restore, the old videoram is going to
be copied over soon anyway"


> Also, is this the only device affected by the shortcoming? What about
> other VGA adapters e.g.?

To my knowledge (in the PC emulator) it is the only device that
allocates memory using memory_region_init_ram/memory_region_get_ram_ptr
and then moves it around. But maybe QXL does it as well?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 13:19:06 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 13: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.xensource.com>)
	id 1Ra5mC-0002Mg-3y; Mon, 12 Dec 2011 13:18:40 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Ra5mA-0002MY-SS
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 13:18:39 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1323695827!50416234!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDc4NQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10041 invoked from network); 12 Dec 2011 13:17:07 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Dec 2011 13:17:07 -0000
X-IronPort-AV: E=Sophos;i="4.71,339,1320624000"; 
   d="scan'208";a="9416575"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Dec 2011 13:16:43 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 12 Dec 2011 13:16:42 +0000
Date: Mon, 12 Dec 2011 13:18:05 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Jan Kiszka <jan.kiszka@web.de>
In-Reply-To: <4EE3382D.80903@web.de>
Message-ID: <alpine.DEB.2.00.1112121259180.3517@kaball-desktop>
References: <1323467645-24271-1-git-send-email-anthony.perard@citrix.com>
	<1323467645-24271-6-git-send-email-anthony.perard@citrix.com>
	<4EE3382D.80903@web.de>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Anthony Perard <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	QEMU-devel <qemu-devel@nongnu.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH V2 5/5] vga-cirrus: Workaround during
 restore when using Xen.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Sat, 10 Dec 2011, Jan Kiszka wrote:
> On 2011-12-09 22:54, Anthony PERARD wrote:
> > During the initialisation of the machine at restore time, the access to the
> > VRAM will fail because QEMU does not know yet the right guest address to map,
> > so the vram_ptr is NULL.
> > 
> > So this patch avoid using a NULL pointer during initialisation, and try to get
> > another vram_ptr if the call failed the first time.
> > 
> > Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> > ---
> >  hw/cirrus_vga.c |   16 +++++++++++++---
> >  1 files changed, 13 insertions(+), 3 deletions(-)
> > 
> > diff --git a/hw/cirrus_vga.c b/hw/cirrus_vga.c
> > index c7e365b..2e049c9 100644
> > --- a/hw/cirrus_vga.c
> > +++ b/hw/cirrus_vga.c
> > @@ -32,6 +32,7 @@
> >  #include "console.h"
> >  #include "vga_int.h"
> >  #include "loader.h"
> > +#include "sysemu.h"
> >  
> >  /*
> >   * TODO:
> > @@ -2696,6 +2697,13 @@ static int cirrus_post_load(void *opaque, int version_id)
> >      s->vga.gr[0x01] = s->cirrus_shadow_gr1 & 0x0f;
> >  
> >      cirrus_update_memory_access(s);
> > +    if (!s->vga.vram_ptr) {
> > +        /* At this point vga.vram_ptr can be invalid on Xen because we need to
> > +         * know the position of the videoram in the guest physical address space in
> > +         * order to be able to map it. After cirrus_update_memory_access we do know
> > +         * where the videoram is, so let's map it now. */
> > +        s->vga.vram_ptr = memory_region_get_ram_ptr(&s->vga.vram);
> > +    }
> >      /* force refresh */
> >      s->vga.graphic_mode = -1;
> >      cirrus_update_bank_ptr(s, 0);
> > @@ -2784,9 +2792,11 @@ static void cirrus_reset(void *opaque)
> >      }
> >      s->vga.cr[0x27] = s->device_id;
> >  
> > -    /* Win2K seems to assume that the pattern buffer is at 0xff
> > -       initially ! */
> > -    memset(s->vga.vram_ptr, 0xff, s->real_vram_size);
> > +    if (!runstate_check(RUN_STATE_PREMIGRATE)) {
> > +        /* Win2K seems to assume that the pattern buffer is at 0xff
> > +           initially ! */
> > +        memset(s->vga.vram_ptr, 0xff, s->real_vram_size);
> > +    }
> >  
> >      s->cirrus_hidden_dac_lockindex = 5;
> >      s->cirrus_hidden_dac_data = 0;
> 
> Is there really no way to fix this properly in the Xen layer?

We thought about this issue for some time but we couldn't come up with
anything better.
To summarize the problem:

- on restore the videoram has already been loaded in the guest physical
  address space by Xen;

- we don't know exactly where it is yet, because it has been loaded at
  the *last* address it was mapped to (see map_linear_vram_bank that
  moves the videoram);

- we want to avoid allocating the videoram twice (actually the second
  allocation would fail because of memory constraints);



So the solution (I acknowledge that it looks more like an hack than a
solution) is:

- wait for cirrus to load its state so that we know where the videoram
  is;

- map the videoram into qemu's address space at that point.



Anything else we came up with was even worse, for example:

- independently save the position of the videoram and then when
  vga_common_init tries to allocate it for a second time give back the
  old videoram instead;

- move back the videoram to the original position and then move it again
  to the new position.



> This looks
> highly fragile as specifically the second hunk appears unrelated to Xen.

I think that the second chuck should be in a separate patch because it
is unrelated to Xen. On restore it is useless to memset the videoram, so
for performance reasons it would be a good idea to avoid it on all
platforms. Also it happens to crash Qemu on Xen but that is another
story  ;-)

I think we should also add a comment:

"useles to memset the videoram on restore, the old videoram is going to
be copied over soon anyway"


> Also, is this the only device affected by the shortcoming? What about
> other VGA adapters e.g.?

To my knowledge (in the PC emulator) it is the only device that
allocates memory using memory_region_init_ram/memory_region_get_ram_ptr
and then moves it around. But maybe QXL does it as well?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 13:48:15 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 13: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.xensource.com>)
	id 1Ra6EO-0002dl-Tj; Mon, 12 Dec 2011 13:47:48 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>)
	id 1Ra6EO-0002dY-4Z; Mon, 12 Dec 2011 13:47:48 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1323697615!7116745!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDc4NQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7718 invoked from network); 12 Dec 2011 13:46:55 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Dec 2011 13:46:55 -0000
X-IronPort-AV: E=Sophos;i="4.71,339,1320624000"; 
   d="scan'208";a="9417413"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Dec 2011 13:46:54 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 12 Dec 2011 13:46:54 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: George Shuklin <george.shuklin@gmail.com>
Date: Mon, 12 Dec 2011 13:46:53 +0000
In-Reply-To: <4EE5EF22.6050704@gmail.com>
References: <4EE2665C.8090602@gmail.com>
	<1323689477.20077.173.camel@zakaz.uk.xensource.com>
	<4EE5EF22.6050704@gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323697614.20077.211.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>,
	"xen-api@lists.xensource.com" <xen-api@lists.xensource.com>
Subject: Re: [Xen-devel] bug in xenstored? No notification to subscription
 on @introduceDomain
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Please don't top post and don't drop people/lists from the CC. I have
reinstated xen-devel and refrained from trimming the quotes as heavily
as I normally would.

Counter to my own advice I have also dropped xen-hosts@googlegroups.com
because last time I got a bounce in Russian to the effect that the group
does not exist (according to google translate).

On Mon, 2011-12-12 at 12:10 +0000, George Shuklin wrote:
> Thanks for reply.
> 
> The problem is we tried at least two different libraries - xs (+python 
> xen.lowlevel.xs) and our own library (pyxs), created from scratches on 
> pure python - both shows exactly same behavior. We loosing same time 
> @introduce and @release, but only for new domains. Older domains (which 
> starts before error appear) during shutdown/migration sends  @release 
> normally.
> 
> I done strace, nothig is sending by xenstored to application socket when 
> 'new' domains appears and disappears (I'm not sure 100% due not very 
> good strace skills).
> 
> Application performs write/read operations to/from xenstore (and do many 
> subscriptions, but only after @introduce) and older subscription works fine.
> 
> PS We got other strange bug with memory leak in xenstored (happens only 
> with big amount of transactions, and ONLY with socket) - but this case 
> is still under research, so I decide not to post this (but may be it 
> related somehow?).

Are the two event correlated? i.e. is the oxenstored process huge when
these failures occur? Inability to allocate memory could explain some of
your symptoms although I'd expect it to be more fatal more quickly and
obviously than what you describe or to have wider impact.

> Sorry for question - how I can gather debug information for oxenstored?

What sort of debug information are you after?

There are various logging options which you could turn up to 11
in /etc/xensource/xenstored.conf but I do not have a complete list of
what they are, similarly for command line options -- perhaps someone on
xen-api@ could chime in? Otherwise looking in the source might be the
best way to find out what they are, try xenstore.ml, parse_args.ml
logging.ml would be good places to start. (if having done so you feel
motivated to write a patch to add docs/man/oxenstored.1.pod we would be
much obliged...)

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 13:48:15 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 13: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.xensource.com>)
	id 1Ra6EO-0002dl-Tj; Mon, 12 Dec 2011 13:47:48 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>)
	id 1Ra6EO-0002dY-4Z; Mon, 12 Dec 2011 13:47:48 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1323697615!7116745!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDc4NQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7718 invoked from network); 12 Dec 2011 13:46:55 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Dec 2011 13:46:55 -0000
X-IronPort-AV: E=Sophos;i="4.71,339,1320624000"; 
   d="scan'208";a="9417413"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Dec 2011 13:46:54 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 12 Dec 2011 13:46:54 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: George Shuklin <george.shuklin@gmail.com>
Date: Mon, 12 Dec 2011 13:46:53 +0000
In-Reply-To: <4EE5EF22.6050704@gmail.com>
References: <4EE2665C.8090602@gmail.com>
	<1323689477.20077.173.camel@zakaz.uk.xensource.com>
	<4EE5EF22.6050704@gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323697614.20077.211.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>,
	"xen-api@lists.xensource.com" <xen-api@lists.xensource.com>
Subject: Re: [Xen-devel] bug in xenstored? No notification to subscription
 on @introduceDomain
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Please don't top post and don't drop people/lists from the CC. I have
reinstated xen-devel and refrained from trimming the quotes as heavily
as I normally would.

Counter to my own advice I have also dropped xen-hosts@googlegroups.com
because last time I got a bounce in Russian to the effect that the group
does not exist (according to google translate).

On Mon, 2011-12-12 at 12:10 +0000, George Shuklin wrote:
> Thanks for reply.
> 
> The problem is we tried at least two different libraries - xs (+python 
> xen.lowlevel.xs) and our own library (pyxs), created from scratches on 
> pure python - both shows exactly same behavior. We loosing same time 
> @introduce and @release, but only for new domains. Older domains (which 
> starts before error appear) during shutdown/migration sends  @release 
> normally.
> 
> I done strace, nothig is sending by xenstored to application socket when 
> 'new' domains appears and disappears (I'm not sure 100% due not very 
> good strace skills).
> 
> Application performs write/read operations to/from xenstore (and do many 
> subscriptions, but only after @introduce) and older subscription works fine.
> 
> PS We got other strange bug with memory leak in xenstored (happens only 
> with big amount of transactions, and ONLY with socket) - but this case 
> is still under research, so I decide not to post this (but may be it 
> related somehow?).

Are the two event correlated? i.e. is the oxenstored process huge when
these failures occur? Inability to allocate memory could explain some of
your symptoms although I'd expect it to be more fatal more quickly and
obviously than what you describe or to have wider impact.

> Sorry for question - how I can gather debug information for oxenstored?

What sort of debug information are you after?

There are various logging options which you could turn up to 11
in /etc/xensource/xenstored.conf but I do not have a complete list of
what they are, similarly for command line options -- perhaps someone on
xen-api@ could chime in? Otherwise looking in the source might be the
best way to find out what they are, try xenstore.ml, parse_args.ml
logging.ml would be good places to start. (if having done so you feel
motivated to write a patch to add docs/man/oxenstored.1.pod we would be
much obliged...)

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 13:50:13 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 13:50:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ra6GJ-0002ko-EI; Mon, 12 Dec 2011 13:49:47 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Ra6GI-0002kQ-5B
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 13:49:46 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1323697731!5220045!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDc4NQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11482 invoked from network); 12 Dec 2011 13:48:52 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Dec 2011 13:48:52 -0000
X-IronPort-AV: E=Sophos;i="4.71,339,1320624000"; 
   d="scan'208";a="9417470"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Dec 2011 13:48:43 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 12 Dec 2011 13:48:43 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Mon, 12 Dec 2011 13:48:43 +0000
In-Reply-To: <20197.62462.189827.239656@mariner.uk.xensource.com>
References: <1323108621-22654-1-git-send-email-ian.jackson@eu.citrix.com>
	<1323108621-22654-16-git-send-email-ian.jackson@eu.citrix.com>
	<alpine.DEB.2.00.1112091558300.3517@kaball-desktop>
	<20194.22539.574524.956955@mariner.uk.xensource.com>
	<1323463293.20936.11.camel@dagon.hellion.org.uk>
	<20197.59428.699013.507183@mariner.uk.xensource.com>
	<1323692225.20077.183.camel@zakaz.uk.xensource.com>
	<20197.62462.189827.239656@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323697723.20077.212.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 15/15] libxl: New event generation API
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2011-12-12 at 12:30 +0000, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [PATCH 15/15] libxl: New event generation API"):
> > On Mon, 2011-12-12 at 11:40 +0000, Ian Jackson wrote:
> > > Well, we have to have an internal version because we don't want to
> > > call GC_INIT again, obviously.
> > 
> > In this case it would take a ctx not a gc and it's ok and expected for
> > libxl a function calling another libxl function to end up with another
> > gc in the inner function (it happens all the time).
> 
> This is not allowed in functions which might generate events (ie,
> which might call libxl__event_occurred), because the application's
> event callback will be called at an unexpected point in libxl's
> execution.  This has three problems:
> 
>  * There is a reentrancy hazard.  Exactly whether this is a problem in
>    a specific case is difficult to analyse; hence the recording of
>    pending callbacks in the gc, so that they can be delayed until the
>    gc is freed.
> 
>  * The application's callbacks will be called with the libxl ctx
>    locked.  This might result in deadlock.
> 
>  * The  application's callbacks  might be  called in  the  wrong order
>    because the  inner gc (containing  later events) is  unwound before
>    the outer gc (containing earlier events).
> 
> In general this means that functions which lock the ctx must not
> allocate an inner gc.

Hmm, yes that all makes sense :-/

I was a little surprised when I looked when writing my previous reply
that LIBXL_INITGC doesn't actually take nesting into account. I had
expected that LIBXL_INITGC would return (or somehow chain) the existing
GC when libxl is calling itself such that all the freeing work (and now
callbacks) would only happen when exiting the final frame.

It's probably not so important for memory allocation cleanup but it
would be a semantically useful change for the callbacks if we could
arrange for them to happen only on final exit of the library -- exactly
because of the difficulty of reasoning about things otherwise. Alas I
can't think of a good way to do this since the ctx can be shared, thread
local storage would be one or libxl__gc_owner could return a special
"nested ctx" instead of the real outer ctx, but, ick.

If we can't figure a way round this then the restriction about libxl not
calling into itself via its own public interfaces should be documented
(apologies if I've simply missed that bit, I did go and look because I
thought I recalled seeing it, but I didn't find it, I think I was
thinking about the comment associated with the CTX lock). In particular
if the restriction is that you cannot call public API functions which
might generate events from within libxl then those functions need to be
clearly annotated as potentially generating events.

> > IOW if you make beforepoll_internal take the lock as you suggest then
> > you may as well inline it into libxl_osevent_beforepoll (removing the
> > second lock use) and use that internally too.
> 
> beforepoll_unlocked is called in two places: libxl_osevent_beforepoll,
> and libxl_event_wait.

My suggestion was to call libxl_osevent_beforepoll from
libxl_event_wait. The documentation for libxl_event_wait even says this
is how libxl_event_wait is implemented (I know I'm not a liberty to take
that as literally as that).

Of course your explanation above put paid to that idea, unless we can
work around it.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 13:50:13 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 13:50:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ra6GJ-0002ko-EI; Mon, 12 Dec 2011 13:49:47 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Ra6GI-0002kQ-5B
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 13:49:46 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1323697731!5220045!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDc4NQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11482 invoked from network); 12 Dec 2011 13:48:52 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Dec 2011 13:48:52 -0000
X-IronPort-AV: E=Sophos;i="4.71,339,1320624000"; 
   d="scan'208";a="9417470"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Dec 2011 13:48:43 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 12 Dec 2011 13:48:43 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Mon, 12 Dec 2011 13:48:43 +0000
In-Reply-To: <20197.62462.189827.239656@mariner.uk.xensource.com>
References: <1323108621-22654-1-git-send-email-ian.jackson@eu.citrix.com>
	<1323108621-22654-16-git-send-email-ian.jackson@eu.citrix.com>
	<alpine.DEB.2.00.1112091558300.3517@kaball-desktop>
	<20194.22539.574524.956955@mariner.uk.xensource.com>
	<1323463293.20936.11.camel@dagon.hellion.org.uk>
	<20197.59428.699013.507183@mariner.uk.xensource.com>
	<1323692225.20077.183.camel@zakaz.uk.xensource.com>
	<20197.62462.189827.239656@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323697723.20077.212.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 15/15] libxl: New event generation API
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2011-12-12 at 12:30 +0000, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [PATCH 15/15] libxl: New event generation API"):
> > On Mon, 2011-12-12 at 11:40 +0000, Ian Jackson wrote:
> > > Well, we have to have an internal version because we don't want to
> > > call GC_INIT again, obviously.
> > 
> > In this case it would take a ctx not a gc and it's ok and expected for
> > libxl a function calling another libxl function to end up with another
> > gc in the inner function (it happens all the time).
> 
> This is not allowed in functions which might generate events (ie,
> which might call libxl__event_occurred), because the application's
> event callback will be called at an unexpected point in libxl's
> execution.  This has three problems:
> 
>  * There is a reentrancy hazard.  Exactly whether this is a problem in
>    a specific case is difficult to analyse; hence the recording of
>    pending callbacks in the gc, so that they can be delayed until the
>    gc is freed.
> 
>  * The application's callbacks will be called with the libxl ctx
>    locked.  This might result in deadlock.
> 
>  * The  application's callbacks  might be  called in  the  wrong order
>    because the  inner gc (containing  later events) is  unwound before
>    the outer gc (containing earlier events).
> 
> In general this means that functions which lock the ctx must not
> allocate an inner gc.

Hmm, yes that all makes sense :-/

I was a little surprised when I looked when writing my previous reply
that LIBXL_INITGC doesn't actually take nesting into account. I had
expected that LIBXL_INITGC would return (or somehow chain) the existing
GC when libxl is calling itself such that all the freeing work (and now
callbacks) would only happen when exiting the final frame.

It's probably not so important for memory allocation cleanup but it
would be a semantically useful change for the callbacks if we could
arrange for them to happen only on final exit of the library -- exactly
because of the difficulty of reasoning about things otherwise. Alas I
can't think of a good way to do this since the ctx can be shared, thread
local storage would be one or libxl__gc_owner could return a special
"nested ctx" instead of the real outer ctx, but, ick.

If we can't figure a way round this then the restriction about libxl not
calling into itself via its own public interfaces should be documented
(apologies if I've simply missed that bit, I did go and look because I
thought I recalled seeing it, but I didn't find it, I think I was
thinking about the comment associated with the CTX lock). In particular
if the restriction is that you cannot call public API functions which
might generate events from within libxl then those functions need to be
clearly annotated as potentially generating events.

> > IOW if you make beforepoll_internal take the lock as you suggest then
> > you may as well inline it into libxl_osevent_beforepoll (removing the
> > second lock use) and use that internally too.
> 
> beforepoll_unlocked is called in two places: libxl_osevent_beforepoll,
> and libxl_event_wait.

My suggestion was to call libxl_osevent_beforepoll from
libxl_event_wait. The documentation for libxl_event_wait even says this
is how libxl_event_wait is implemented (I know I'm not a liberty to take
that as literally as that).

Of course your explanation above put paid to that idea, unless we can
work around it.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 13:56:21 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 13:56:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ra6MJ-0002zx-D4; Mon, 12 Dec 2011 13:55:59 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>)
	id 1Ra6MH-0002zf-45; Mon, 12 Dec 2011 13:55:57 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1323698103!6882488!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDc4NQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11528 invoked from network); 12 Dec 2011 13:55:03 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Dec 2011 13:55:03 -0000
X-IronPort-AV: E=Sophos;i="4.71,339,1320624000"; 
   d="scan'208";a="9417629"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Dec 2011 13:55:03 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 12 Dec 2011 13:55:03 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: George Shuklin <george.shuklin@gmail.com>
Date: Mon, 12 Dec 2011 13:55:03 +0000
In-Reply-To: <1323689477.20077.173.camel@zakaz.uk.xensource.com>
References: <4EE2665C.8090602@gmail.com>
	<1323689477.20077.173.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323698103.20077.216.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"xen-api@lists.xensource.com" <xen-api@lists.xensource.com>
Subject: Re: [Xen-devel] bug in xenstored? No notification to subscription
 on @introduceDomain
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2011-12-12 at 11:31 +0000, Ian Campbell wrote:
> Does the app do any other XS stuff, e.g. other watches or read/write? Do
> these stop working also?

One other question -- does your app use threading anywhere apart from
the one it gets from libxenstore?

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 13:56:21 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 13:56:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ra6MJ-0002zx-D4; Mon, 12 Dec 2011 13:55:59 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>)
	id 1Ra6MH-0002zf-45; Mon, 12 Dec 2011 13:55:57 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1323698103!6882488!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDc4NQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11528 invoked from network); 12 Dec 2011 13:55:03 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Dec 2011 13:55:03 -0000
X-IronPort-AV: E=Sophos;i="4.71,339,1320624000"; 
   d="scan'208";a="9417629"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Dec 2011 13:55:03 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 12 Dec 2011 13:55:03 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: George Shuklin <george.shuklin@gmail.com>
Date: Mon, 12 Dec 2011 13:55:03 +0000
In-Reply-To: <1323689477.20077.173.camel@zakaz.uk.xensource.com>
References: <4EE2665C.8090602@gmail.com>
	<1323689477.20077.173.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323698103.20077.216.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"xen-api@lists.xensource.com" <xen-api@lists.xensource.com>
Subject: Re: [Xen-devel] bug in xenstored? No notification to subscription
 on @introduceDomain
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2011-12-12 at 11:31 +0000, Ian Campbell wrote:
> Does the app do any other XS stuff, e.g. other watches or read/write? Do
> these stop working also?

One other question -- does your app use threading anywhere apart from
the one it gets from libxenstore?

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 14:03:28 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 14:03:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ra6T9-0003M6-Gr; Mon, 12 Dec 2011 14:03:03 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Christoph.Egger@amd.com>) id 1Ra6T7-0003Lr-5M
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 14:03:01 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1323698526!5215427!1
X-Originating-IP: [216.32.180.16]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23046 invoked from network); 12 Dec 2011 14:02:07 -0000
Received: from va3ehsobe006.messaging.microsoft.com (HELO
	VA3EHSOBE007.bigfish.com) (216.32.180.16)
	by server-6.tower-174.messagelabs.com with AES128-SHA encrypted SMTP;
	12 Dec 2011 14:02:07 -0000
Received: from mail68-va3-R.bigfish.com (10.7.14.236) by
	VA3EHSOBE007.bigfish.com (10.7.40.11) with Microsoft SMTP Server id
	14.1.225.23; Mon, 12 Dec 2011 14:02:04 +0000
Received: from mail68-va3 (localhost [127.0.0.1])	by mail68-va3-R.bigfish.com
	(Postfix) with ESMTP id 36B06100338	for
	<xen-devel@lists.xensource.com>; Mon,
	12 Dec 2011 14:02:04 +0000 (UTC)
X-SpamScore: -5
X-BigFish: VPS-5(zz1803Mc85dhzz1202hzz8275bhz2dh668h839h34h62h)
X-Spam-TCS-SCL: 1:0
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
Received: from mail68-va3 (localhost.localdomain [127.0.0.1]) by mail68-va3
	(MessageSwitch) id 1323698523901252_18046;
	Mon, 12 Dec 2011 14:02:03 +0000 (UTC)
Received: from VA3EHSMHS018.bigfish.com (unknown [10.7.14.238])	by
	mail68-va3.bigfish.com (Postfix) with ESMTP id D4DEC4C0048	for
	<xen-devel@lists.xensource.com>; Mon, 12 Dec 2011 14:02:03 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	VA3EHSMHS018.bigfish.com (10.7.99.28) with Microsoft SMTP Server id
	14.1.225.22; Mon, 12 Dec 2011 14:02:02 +0000
X-WSS-ID: 0LW3GBD-01-GG0-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2CD7A102804A	for <xen-devel@lists.xensource.com>;
	Mon, 12 Dec 2011 08:02:01 -0600 (CST)
Received: from SAUSEXDAG02.amd.com (163.181.55.2) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Mon, 12 Dec 2011 08:02:07 -0600
Received: from storexhtp01.amd.com (172.24.4.3) by sausexdag02.amd.com
	(163.181.55.2) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Mon, 12 Dec 2011 08:02:02 -0600
Received: from rhodium.osrc.amd.com (165.204.15.173) by storexhtp01.amd.com
	(172.24.4.3) with Microsoft SMTP Server id 8.3.213.0; Mon, 12 Dec 2011
	09:02:01 -0500
Message-ID: <4EE60958.70403@amd.com>
Date: Mon, 12 Dec 2011 15:02:00 +0100
From: Christoph Egger <Christoph.Egger@amd.com>
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:8.0) Gecko/20111114 Thunderbird/8.0
MIME-Version: 1.0
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Content-Type: multipart/mixed; boundary="------------070607060102090401020508"
X-OriginatorOrg: amd.com
Subject: [Xen-devel] [PATCH] microcode fix
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--------------070607060102090401020508
Content-Type: text/plain; charset="ISO-8859-15"; format=flowed
Content-Transfer-Encoding: 7bit


Remove hardcoded maximum size a microcode patch can have.
This is dynamic now.

The microcode patch for family15h can be larger than 2048 bytes
and gets silently truncated.

Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>

P.S. Please apply this to Xen 4.1, 4.0, 3.4 and 3.3, too.

-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo, Andrew Bowd
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632

--------------070607060102090401020508
Content-Type: text/plain; name="xen_microcode_fam15.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="xen_microcode_fam15.diff"
Content-Description: xen_microcode_fam15.diff

diff -r 848049b14ec7 xen/arch/x86/microcode_amd.c
--- a/xen/arch/x86/microcode_amd.c	Mon Nov 14 20:15:35 2011 +0000
+++ b/xen/arch/x86/microcode_amd.c	Mon Dec 12 14:36:07 2011 +0100
@@ -27,18 +27,10 @@
 #include <asm/processor.h>
 #include <asm/microcode.h>
 
-#define pr_debug(x...) ((void)0)
-
 #define UCODE_MAGIC                0x00414d44
 #define UCODE_EQUIV_CPU_TABLE_TYPE 0x00000000
 #define UCODE_UCODE_TYPE           0x00000001
 
-#define UCODE_MAX_SIZE          (2048)
-#define DEFAULT_UCODE_DATASIZE  (896)
-#define MC_HEADER_SIZE          (sizeof(struct microcode_header_amd))
-#define DEFAULT_UCODE_TOTALSIZE (DEFAULT_UCODE_DATASIZE + MC_HEADER_SIZE)
-#define DWSIZE                  (sizeof(uint32_t))
-
 /* serialize access to the physical write */
 static DEFINE_SPINLOCK(microcode_update_lock);
 
@@ -99,7 +91,7 @@ static int microcode_fits(void *mc, int 
     }
 
     if ( mc_header->patch_id <= uci->cpu_sig.rev )
-        return -EINVAL;
+        return 1;
 
     printk(KERN_DEBUG "microcode: CPU%d found a matching microcode "
            "update with version 0x%x (current=0x%x)\n",
@@ -147,8 +139,8 @@ static int apply_microcode(int cpu)
     return 0;
 }
 
-static int get_next_ucode_from_buffer_amd(void *mc, const void *buf,
-                                         size_t size, unsigned long *offset)
+static int get_next_ucode_from_buffer_amd(void *mc, size_t *mc_size,
+    const void *buf, size_t size, unsigned long *offset)
 {
     size_t total_size;
     const uint8_t *bufp = buf;
@@ -178,7 +170,12 @@ static int get_next_ucode_from_buffer_am
         return -EINVAL;
     }
 
-    memset(mc, 0, UCODE_MAX_SIZE);
+    if (*mc_size < total_size) {
+        xfree(mc);
+        mc = xmalloc_bytes(total_size);
+        *mc_size = total_size;
+    }
+    memset(mc, 0, *mc_size);
     memcpy(mc, (const void *)(&bufp[off + 8]), total_size);
 
     *offset = off + total_size + 8;
@@ -231,11 +228,12 @@ static int install_equiv_cpu_table(const
 static int cpu_request_microcode(int cpu, const void *buf, size_t size)
 {
     const uint32_t *buf_pos;
-    unsigned long offset = 0;
+    size_t offset = 0;
     int error = 0;
     int ret;
     struct ucode_cpu_info *uci = &per_cpu(ucode_cpu_info, cpu);
     void *mc;
+    size_t mc_size;
 
     /* We should bind the task to the CPU */
     BUG_ON(cpu != raw_smp_processor_id());
@@ -245,7 +243,7 @@ static int cpu_request_microcode(int cpu
     if ( buf_pos[0] != UCODE_MAGIC )
     {
         printk(KERN_ERR "microcode: error! Wrong "
-               "microcode patch file magic\n");
+            "microcode patch file magic\n");
         return -EINVAL;
     }
 
@@ -256,7 +254,8 @@ static int cpu_request_microcode(int cpu
         return -EINVAL;
     }
 
-    mc = xmalloc_bytes(UCODE_MAX_SIZE);
+    mc_size = buf_pos[offset + 1]; /* Size of 1st microcode patch in bytes */
+    mc = xmalloc_bytes(size);
     if ( mc == NULL )
     {
         printk(KERN_ERR "microcode: error! "
@@ -272,7 +271,8 @@ static int cpu_request_microcode(int cpu
      * It's possible the data file has multiple matching ucode,
      * lets keep searching till the latest version
      */
-    while ( (ret = get_next_ucode_from_buffer_amd(mc, buf, size, &offset)) == 0)
+    while ( (ret = get_next_ucode_from_buffer_amd(mc, &mc_size,
+        buf, size, &offset)) == 0)
     {
         error = microcode_fits(mc, cpu);
         if (error <= 0)

--------------070607060102090401020508
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--------------070607060102090401020508--


From xen-devel-bounces@lists.xensource.com Mon Dec 12 14:03:28 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 14:03:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ra6T9-0003M6-Gr; Mon, 12 Dec 2011 14:03:03 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Christoph.Egger@amd.com>) id 1Ra6T7-0003Lr-5M
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 14:03:01 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1323698526!5215427!1
X-Originating-IP: [216.32.180.16]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23046 invoked from network); 12 Dec 2011 14:02:07 -0000
Received: from va3ehsobe006.messaging.microsoft.com (HELO
	VA3EHSOBE007.bigfish.com) (216.32.180.16)
	by server-6.tower-174.messagelabs.com with AES128-SHA encrypted SMTP;
	12 Dec 2011 14:02:07 -0000
Received: from mail68-va3-R.bigfish.com (10.7.14.236) by
	VA3EHSOBE007.bigfish.com (10.7.40.11) with Microsoft SMTP Server id
	14.1.225.23; Mon, 12 Dec 2011 14:02:04 +0000
Received: from mail68-va3 (localhost [127.0.0.1])	by mail68-va3-R.bigfish.com
	(Postfix) with ESMTP id 36B06100338	for
	<xen-devel@lists.xensource.com>; Mon,
	12 Dec 2011 14:02:04 +0000 (UTC)
X-SpamScore: -5
X-BigFish: VPS-5(zz1803Mc85dhzz1202hzz8275bhz2dh668h839h34h62h)
X-Spam-TCS-SCL: 1:0
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
Received: from mail68-va3 (localhost.localdomain [127.0.0.1]) by mail68-va3
	(MessageSwitch) id 1323698523901252_18046;
	Mon, 12 Dec 2011 14:02:03 +0000 (UTC)
Received: from VA3EHSMHS018.bigfish.com (unknown [10.7.14.238])	by
	mail68-va3.bigfish.com (Postfix) with ESMTP id D4DEC4C0048	for
	<xen-devel@lists.xensource.com>; Mon, 12 Dec 2011 14:02:03 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	VA3EHSMHS018.bigfish.com (10.7.99.28) with Microsoft SMTP Server id
	14.1.225.22; Mon, 12 Dec 2011 14:02:02 +0000
X-WSS-ID: 0LW3GBD-01-GG0-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2CD7A102804A	for <xen-devel@lists.xensource.com>;
	Mon, 12 Dec 2011 08:02:01 -0600 (CST)
Received: from SAUSEXDAG02.amd.com (163.181.55.2) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Mon, 12 Dec 2011 08:02:07 -0600
Received: from storexhtp01.amd.com (172.24.4.3) by sausexdag02.amd.com
	(163.181.55.2) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Mon, 12 Dec 2011 08:02:02 -0600
Received: from rhodium.osrc.amd.com (165.204.15.173) by storexhtp01.amd.com
	(172.24.4.3) with Microsoft SMTP Server id 8.3.213.0; Mon, 12 Dec 2011
	09:02:01 -0500
Message-ID: <4EE60958.70403@amd.com>
Date: Mon, 12 Dec 2011 15:02:00 +0100
From: Christoph Egger <Christoph.Egger@amd.com>
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:8.0) Gecko/20111114 Thunderbird/8.0
MIME-Version: 1.0
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Content-Type: multipart/mixed; boundary="------------070607060102090401020508"
X-OriginatorOrg: amd.com
Subject: [Xen-devel] [PATCH] microcode fix
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--------------070607060102090401020508
Content-Type: text/plain; charset="ISO-8859-15"; format=flowed
Content-Transfer-Encoding: 7bit


Remove hardcoded maximum size a microcode patch can have.
This is dynamic now.

The microcode patch for family15h can be larger than 2048 bytes
and gets silently truncated.

Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>

P.S. Please apply this to Xen 4.1, 4.0, 3.4 and 3.3, too.

-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo, Andrew Bowd
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632

--------------070607060102090401020508
Content-Type: text/plain; name="xen_microcode_fam15.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="xen_microcode_fam15.diff"
Content-Description: xen_microcode_fam15.diff

diff -r 848049b14ec7 xen/arch/x86/microcode_amd.c
--- a/xen/arch/x86/microcode_amd.c	Mon Nov 14 20:15:35 2011 +0000
+++ b/xen/arch/x86/microcode_amd.c	Mon Dec 12 14:36:07 2011 +0100
@@ -27,18 +27,10 @@
 #include <asm/processor.h>
 #include <asm/microcode.h>
 
-#define pr_debug(x...) ((void)0)
-
 #define UCODE_MAGIC                0x00414d44
 #define UCODE_EQUIV_CPU_TABLE_TYPE 0x00000000
 #define UCODE_UCODE_TYPE           0x00000001
 
-#define UCODE_MAX_SIZE          (2048)
-#define DEFAULT_UCODE_DATASIZE  (896)
-#define MC_HEADER_SIZE          (sizeof(struct microcode_header_amd))
-#define DEFAULT_UCODE_TOTALSIZE (DEFAULT_UCODE_DATASIZE + MC_HEADER_SIZE)
-#define DWSIZE                  (sizeof(uint32_t))
-
 /* serialize access to the physical write */
 static DEFINE_SPINLOCK(microcode_update_lock);
 
@@ -99,7 +91,7 @@ static int microcode_fits(void *mc, int 
     }
 
     if ( mc_header->patch_id <= uci->cpu_sig.rev )
-        return -EINVAL;
+        return 1;
 
     printk(KERN_DEBUG "microcode: CPU%d found a matching microcode "
            "update with version 0x%x (current=0x%x)\n",
@@ -147,8 +139,8 @@ static int apply_microcode(int cpu)
     return 0;
 }
 
-static int get_next_ucode_from_buffer_amd(void *mc, const void *buf,
-                                         size_t size, unsigned long *offset)
+static int get_next_ucode_from_buffer_amd(void *mc, size_t *mc_size,
+    const void *buf, size_t size, unsigned long *offset)
 {
     size_t total_size;
     const uint8_t *bufp = buf;
@@ -178,7 +170,12 @@ static int get_next_ucode_from_buffer_am
         return -EINVAL;
     }
 
-    memset(mc, 0, UCODE_MAX_SIZE);
+    if (*mc_size < total_size) {
+        xfree(mc);
+        mc = xmalloc_bytes(total_size);
+        *mc_size = total_size;
+    }
+    memset(mc, 0, *mc_size);
     memcpy(mc, (const void *)(&bufp[off + 8]), total_size);
 
     *offset = off + total_size + 8;
@@ -231,11 +228,12 @@ static int install_equiv_cpu_table(const
 static int cpu_request_microcode(int cpu, const void *buf, size_t size)
 {
     const uint32_t *buf_pos;
-    unsigned long offset = 0;
+    size_t offset = 0;
     int error = 0;
     int ret;
     struct ucode_cpu_info *uci = &per_cpu(ucode_cpu_info, cpu);
     void *mc;
+    size_t mc_size;
 
     /* We should bind the task to the CPU */
     BUG_ON(cpu != raw_smp_processor_id());
@@ -245,7 +243,7 @@ static int cpu_request_microcode(int cpu
     if ( buf_pos[0] != UCODE_MAGIC )
     {
         printk(KERN_ERR "microcode: error! Wrong "
-               "microcode patch file magic\n");
+            "microcode patch file magic\n");
         return -EINVAL;
     }
 
@@ -256,7 +254,8 @@ static int cpu_request_microcode(int cpu
         return -EINVAL;
     }
 
-    mc = xmalloc_bytes(UCODE_MAX_SIZE);
+    mc_size = buf_pos[offset + 1]; /* Size of 1st microcode patch in bytes */
+    mc = xmalloc_bytes(size);
     if ( mc == NULL )
     {
         printk(KERN_ERR "microcode: error! "
@@ -272,7 +271,8 @@ static int cpu_request_microcode(int cpu
      * It's possible the data file has multiple matching ucode,
      * lets keep searching till the latest version
      */
-    while ( (ret = get_next_ucode_from_buffer_amd(mc, buf, size, &offset)) == 0)
+    while ( (ret = get_next_ucode_from_buffer_amd(mc, &mc_size,
+        buf, size, &offset)) == 0)
     {
         error = microcode_fits(mc, cpu);
         if (error <= 0)

--------------070607060102090401020508
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--------------070607060102090401020508--


From xen-devel-bounces@lists.xensource.com Mon Dec 12 14:05:01 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 14: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.xensource.com>)
	id 1Ra6Uk-0003Rg-6b; Mon, 12 Dec 2011 14:04:42 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jan.kiszka@siemens.com>) id 1Ra6Uj-0003RZ-7s
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 14:04:41 +0000
X-Env-Sender: jan.kiszka@siemens.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1323698593!47510865!1
X-Originating-IP: [192.35.17.2]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjM1LjE3LjIgPT4gMzAxNzcz\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19050 invoked from network); 12 Dec 2011 14:03:13 -0000
Received: from thoth.sbs.de (HELO thoth.sbs.de) (192.35.17.2)
	by server-10.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Dec 2011 14:03:13 -0000
Received: from mail1.siemens.de (localhost [127.0.0.1])
	by thoth.sbs.de (8.13.6/8.13.6) with ESMTP id pBCE3jdu015029;
	Mon, 12 Dec 2011 15:03:46 +0100
Received: from mchn199C.mchp.siemens.de ([139.25.109.49])
	by mail1.siemens.de (8.13.6/8.13.6) with ESMTP id pBCE3hjN017697;
	Mon, 12 Dec 2011 15:03:44 +0100
Message-ID: <4EE609BF.1070307@siemens.com>
Date: Mon, 12 Dec 2011 15:03:43 +0100
From: Jan Kiszka <jan.kiszka@siemens.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de;
	rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12
	Mnenhy/0.7.5.666
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <1323467645-24271-1-git-send-email-anthony.perard@citrix.com>
	<1323467645-24271-6-git-send-email-anthony.perard@citrix.com>
	<4EE3382D.80903@web.de>
	<alpine.DEB.2.00.1112121259180.3517@kaball-desktop>
In-Reply-To: <alpine.DEB.2.00.1112121259180.3517@kaball-desktop>
Cc: Anthony Perard <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	QEMU-devel <qemu-devel@nongnu.org>
Subject: Re: [Xen-devel] [PATCH V2 5/5] vga-cirrus: Workaround during
 restore when using Xen.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 2011-12-12 14:18, Stefano Stabellini wrote:
> On Sat, 10 Dec 2011, Jan Kiszka wrote:
>> On 2011-12-09 22:54, Anthony PERARD wrote:
>>> During the initialisation of the machine at restore time, the access to the
>>> VRAM will fail because QEMU does not know yet the right guest address to map,
>>> so the vram_ptr is NULL.
>>>
>>> So this patch avoid using a NULL pointer during initialisation, and try to get
>>> another vram_ptr if the call failed the first time.
>>>
>>> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
>>> ---
>>>  hw/cirrus_vga.c |   16 +++++++++++++---
>>>  1 files changed, 13 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/hw/cirrus_vga.c b/hw/cirrus_vga.c
>>> index c7e365b..2e049c9 100644
>>> --- a/hw/cirrus_vga.c
>>> +++ b/hw/cirrus_vga.c
>>> @@ -32,6 +32,7 @@
>>>  #include "console.h"
>>>  #include "vga_int.h"
>>>  #include "loader.h"
>>> +#include "sysemu.h"
>>>  
>>>  /*
>>>   * TODO:
>>> @@ -2696,6 +2697,13 @@ static int cirrus_post_load(void *opaque, int version_id)
>>>      s->vga.gr[0x01] = s->cirrus_shadow_gr1 & 0x0f;
>>>  
>>>      cirrus_update_memory_access(s);
>>> +    if (!s->vga.vram_ptr) {
>>> +        /* At this point vga.vram_ptr can be invalid on Xen because we need to
>>> +         * know the position of the videoram in the guest physical address space in
>>> +         * order to be able to map it. After cirrus_update_memory_access we do know
>>> +         * where the videoram is, so let's map it now. */
>>> +        s->vga.vram_ptr = memory_region_get_ram_ptr(&s->vga.vram);
>>> +    }
>>>      /* force refresh */
>>>      s->vga.graphic_mode = -1;
>>>      cirrus_update_bank_ptr(s, 0);
>>> @@ -2784,9 +2792,11 @@ static void cirrus_reset(void *opaque)
>>>      }
>>>      s->vga.cr[0x27] = s->device_id;
>>>  
>>> -    /* Win2K seems to assume that the pattern buffer is at 0xff
>>> -       initially ! */
>>> -    memset(s->vga.vram_ptr, 0xff, s->real_vram_size);
>>> +    if (!runstate_check(RUN_STATE_PREMIGRATE)) {
>>> +        /* Win2K seems to assume that the pattern buffer is at 0xff
>>> +           initially ! */
>>> +        memset(s->vga.vram_ptr, 0xff, s->real_vram_size);
>>> +    }
>>>  
>>>      s->cirrus_hidden_dac_lockindex = 5;
>>>      s->cirrus_hidden_dac_data = 0;
>>
>> Is there really no way to fix this properly in the Xen layer?
> 
> We thought about this issue for some time but we couldn't come up with
> anything better.
> To summarize the problem:
> 
> - on restore the videoram has already been loaded in the guest physical
>   address space by Xen;
> 
> - we don't know exactly where it is yet, because it has been loaded at
>   the *last* address it was mapped to (see map_linear_vram_bank that
>   moves the videoram);
> 
> - we want to avoid allocating the videoram twice (actually the second
>   allocation would fail because of memory constraints);
> 
> 
> 
> So the solution (I acknowledge that it looks more like an hack than a
> solution) is:
> 
> - wait for cirrus to load its state so that we know where the videoram
>   is;

Why can't you store this information in some additional Xen-specific
vmstate? The fact that memory_region_get_ram_ptr has to return NULL
looks bogus to me. It's against the QEMU semantics. Other devices may
only be fine as they are not (yet) used with Xen.

> 
> - map the videoram into qemu's address space at that point.
> 
> 
> 
> Anything else we came up with was even worse, for example:
> 
> - independently save the position of the videoram and then when
>   vga_common_init tries to allocate it for a second time give back the
>   old videoram instead;
> 
> - move back the videoram to the original position and then move it again
>   to the new position.
> 
> 
> 
>> This looks
>> highly fragile as specifically the second hunk appears unrelated to Xen.
> 
> I think that the second chuck should be in a separate patch because it
> is unrelated to Xen. On restore it is useless to memset the videoram, so
> for performance reasons it would be a good idea to avoid it on all
> platforms. Also it happens to crash Qemu on Xen but that is another
> story  ;-)
> 
> I think we should also add a comment:
> 
> "useles to memset the videoram on restore, the old videoram is going to
> be copied over soon anyway"

That's in fact a different story and maybe worth optimizing due to the
size of that buffer. But please do not call the state "PREMIGRATE". It's
rather "INCOMING[_MIGRATION]".

Thanks,
Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 14:05:01 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 14: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.xensource.com>)
	id 1Ra6Uk-0003Rg-6b; Mon, 12 Dec 2011 14:04:42 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jan.kiszka@siemens.com>) id 1Ra6Uj-0003RZ-7s
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 14:04:41 +0000
X-Env-Sender: jan.kiszka@siemens.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1323698593!47510865!1
X-Originating-IP: [192.35.17.2]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjM1LjE3LjIgPT4gMzAxNzcz\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19050 invoked from network); 12 Dec 2011 14:03:13 -0000
Received: from thoth.sbs.de (HELO thoth.sbs.de) (192.35.17.2)
	by server-10.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Dec 2011 14:03:13 -0000
Received: from mail1.siemens.de (localhost [127.0.0.1])
	by thoth.sbs.de (8.13.6/8.13.6) with ESMTP id pBCE3jdu015029;
	Mon, 12 Dec 2011 15:03:46 +0100
Received: from mchn199C.mchp.siemens.de ([139.25.109.49])
	by mail1.siemens.de (8.13.6/8.13.6) with ESMTP id pBCE3hjN017697;
	Mon, 12 Dec 2011 15:03:44 +0100
Message-ID: <4EE609BF.1070307@siemens.com>
Date: Mon, 12 Dec 2011 15:03:43 +0100
From: Jan Kiszka <jan.kiszka@siemens.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de;
	rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12
	Mnenhy/0.7.5.666
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <1323467645-24271-1-git-send-email-anthony.perard@citrix.com>
	<1323467645-24271-6-git-send-email-anthony.perard@citrix.com>
	<4EE3382D.80903@web.de>
	<alpine.DEB.2.00.1112121259180.3517@kaball-desktop>
In-Reply-To: <alpine.DEB.2.00.1112121259180.3517@kaball-desktop>
Cc: Anthony Perard <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	QEMU-devel <qemu-devel@nongnu.org>
Subject: Re: [Xen-devel] [PATCH V2 5/5] vga-cirrus: Workaround during
 restore when using Xen.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 2011-12-12 14:18, Stefano Stabellini wrote:
> On Sat, 10 Dec 2011, Jan Kiszka wrote:
>> On 2011-12-09 22:54, Anthony PERARD wrote:
>>> During the initialisation of the machine at restore time, the access to the
>>> VRAM will fail because QEMU does not know yet the right guest address to map,
>>> so the vram_ptr is NULL.
>>>
>>> So this patch avoid using a NULL pointer during initialisation, and try to get
>>> another vram_ptr if the call failed the first time.
>>>
>>> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
>>> ---
>>>  hw/cirrus_vga.c |   16 +++++++++++++---
>>>  1 files changed, 13 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/hw/cirrus_vga.c b/hw/cirrus_vga.c
>>> index c7e365b..2e049c9 100644
>>> --- a/hw/cirrus_vga.c
>>> +++ b/hw/cirrus_vga.c
>>> @@ -32,6 +32,7 @@
>>>  #include "console.h"
>>>  #include "vga_int.h"
>>>  #include "loader.h"
>>> +#include "sysemu.h"
>>>  
>>>  /*
>>>   * TODO:
>>> @@ -2696,6 +2697,13 @@ static int cirrus_post_load(void *opaque, int version_id)
>>>      s->vga.gr[0x01] = s->cirrus_shadow_gr1 & 0x0f;
>>>  
>>>      cirrus_update_memory_access(s);
>>> +    if (!s->vga.vram_ptr) {
>>> +        /* At this point vga.vram_ptr can be invalid on Xen because we need to
>>> +         * know the position of the videoram in the guest physical address space in
>>> +         * order to be able to map it. After cirrus_update_memory_access we do know
>>> +         * where the videoram is, so let's map it now. */
>>> +        s->vga.vram_ptr = memory_region_get_ram_ptr(&s->vga.vram);
>>> +    }
>>>      /* force refresh */
>>>      s->vga.graphic_mode = -1;
>>>      cirrus_update_bank_ptr(s, 0);
>>> @@ -2784,9 +2792,11 @@ static void cirrus_reset(void *opaque)
>>>      }
>>>      s->vga.cr[0x27] = s->device_id;
>>>  
>>> -    /* Win2K seems to assume that the pattern buffer is at 0xff
>>> -       initially ! */
>>> -    memset(s->vga.vram_ptr, 0xff, s->real_vram_size);
>>> +    if (!runstate_check(RUN_STATE_PREMIGRATE)) {
>>> +        /* Win2K seems to assume that the pattern buffer is at 0xff
>>> +           initially ! */
>>> +        memset(s->vga.vram_ptr, 0xff, s->real_vram_size);
>>> +    }
>>>  
>>>      s->cirrus_hidden_dac_lockindex = 5;
>>>      s->cirrus_hidden_dac_data = 0;
>>
>> Is there really no way to fix this properly in the Xen layer?
> 
> We thought about this issue for some time but we couldn't come up with
> anything better.
> To summarize the problem:
> 
> - on restore the videoram has already been loaded in the guest physical
>   address space by Xen;
> 
> - we don't know exactly where it is yet, because it has been loaded at
>   the *last* address it was mapped to (see map_linear_vram_bank that
>   moves the videoram);
> 
> - we want to avoid allocating the videoram twice (actually the second
>   allocation would fail because of memory constraints);
> 
> 
> 
> So the solution (I acknowledge that it looks more like an hack than a
> solution) is:
> 
> - wait for cirrus to load its state so that we know where the videoram
>   is;

Why can't you store this information in some additional Xen-specific
vmstate? The fact that memory_region_get_ram_ptr has to return NULL
looks bogus to me. It's against the QEMU semantics. Other devices may
only be fine as they are not (yet) used with Xen.

> 
> - map the videoram into qemu's address space at that point.
> 
> 
> 
> Anything else we came up with was even worse, for example:
> 
> - independently save the position of the videoram and then when
>   vga_common_init tries to allocate it for a second time give back the
>   old videoram instead;
> 
> - move back the videoram to the original position and then move it again
>   to the new position.
> 
> 
> 
>> This looks
>> highly fragile as specifically the second hunk appears unrelated to Xen.
> 
> I think that the second chuck should be in a separate patch because it
> is unrelated to Xen. On restore it is useless to memset the videoram, so
> for performance reasons it would be a good idea to avoid it on all
> platforms. Also it happens to crash Qemu on Xen but that is another
> story  ;-)
> 
> I think we should also add a comment:
> 
> "useles to memset the videoram on restore, the old videoram is going to
> be copied over soon anyway"

That's in fact a different story and maybe worth optimizing due to the
size of that buffer. But please do not call the state "PREMIGRATE". It's
rather "INCOMING[_MIGRATION]".

Thanks,
Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 14:18:52 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 14: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.xensource.com>)
	id 1Ra6i9-0003ir-MK; Mon, 12 Dec 2011 14:18:33 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Ra6i8-0003im-5H
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 14:18:32 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1323699459!6834612!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDc4NQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17768 invoked from network); 12 Dec 2011 14:17:39 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Dec 2011 14:17:39 -0000
X-IronPort-AV: E=Sophos;i="4.71,339,1320624000"; 
   d="scan'208";a="9418437"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Dec 2011 14:17:38 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 12 Dec 2011 14:17:38 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Mon, 12 Dec 2011 14:17:38 +0000
In-Reply-To: <20194.17095.512495.93972@mariner.uk.xensource.com>
References: <1323108621-22654-1-git-send-email-ian.jackson@eu.citrix.com>
	<1323108621-22654-15-git-send-email-ian.jackson@eu.citrix.com>
	<alpine.DEB.2.00.1112091504060.3517@kaball-desktop>
	<20194.13560.873396.700831@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1112091629340.3517@kaball-desktop>
	<20194.17095.512495.93972@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323699458.20077.227.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 14/15] libxl: New API for providing OS
 events to libxl
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2011-12-09 at 17:17 +0000, Ian Jackson wrote:
> I definitely don't want to add a sentence next to "timeout_register"
> saying "this is for libxl to register a timeout" and another sentence
> saying that the "struct timeval abs" is the absolute time at which the
> timeout should fire and another sentence saying that "int fd" is the
> file descriptor and on on.

I agree that we don't want/need this style of documentation.

WRT comment placement I don't feel especially strongly (so I'm no doubt
going to regret getting involved) but the comment-after-prototype form
does look odd to me.

Putting the comment first is the norm (at least in the projects I
follow), even those that don't fall into the poor/boilerplate style
documentation traps you describe (which we do have some of :-(). I think
people are just used to reading the prototype and then looking for the
comment above it, no matter how unnatural/inefficient/illogical that
might seem.

One specific pitfall which trips me up is that when one has multiple
commented function prototypes in a block, thus:

	a_function(...)
	/* describe function a...
	 * ...
	 * at length
	 */
	b_function(...)
	/* describe function b...
	 * ...
	 * at length
	 */
then figuring out which comment goes with which prototype is non-obvious
and since I naturally look above the prototype for the comment I
inevitably get the wrong one. This is compounded somewhat because we
tend to document other types of object above rather than below and
function prototypes are therefore something of a special case.
(admittedly the correct solution here is more line breaks whatever the
style of commenting used)

We seem to have a mixture of both styles in libxl headers which is
obviously much worse than either option. If an opinion is needed to tip
the scales then I lean slightly towards commenting above but not
noticeably changing the style of commentary.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 14:18:52 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 14: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.xensource.com>)
	id 1Ra6i9-0003ir-MK; Mon, 12 Dec 2011 14:18:33 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Ra6i8-0003im-5H
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 14:18:32 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1323699459!6834612!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDc4NQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17768 invoked from network); 12 Dec 2011 14:17:39 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Dec 2011 14:17:39 -0000
X-IronPort-AV: E=Sophos;i="4.71,339,1320624000"; 
   d="scan'208";a="9418437"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Dec 2011 14:17:38 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 12 Dec 2011 14:17:38 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Mon, 12 Dec 2011 14:17:38 +0000
In-Reply-To: <20194.17095.512495.93972@mariner.uk.xensource.com>
References: <1323108621-22654-1-git-send-email-ian.jackson@eu.citrix.com>
	<1323108621-22654-15-git-send-email-ian.jackson@eu.citrix.com>
	<alpine.DEB.2.00.1112091504060.3517@kaball-desktop>
	<20194.13560.873396.700831@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1112091629340.3517@kaball-desktop>
	<20194.17095.512495.93972@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323699458.20077.227.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 14/15] libxl: New API for providing OS
 events to libxl
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2011-12-09 at 17:17 +0000, Ian Jackson wrote:
> I definitely don't want to add a sentence next to "timeout_register"
> saying "this is for libxl to register a timeout" and another sentence
> saying that the "struct timeval abs" is the absolute time at which the
> timeout should fire and another sentence saying that "int fd" is the
> file descriptor and on on.

I agree that we don't want/need this style of documentation.

WRT comment placement I don't feel especially strongly (so I'm no doubt
going to regret getting involved) but the comment-after-prototype form
does look odd to me.

Putting the comment first is the norm (at least in the projects I
follow), even those that don't fall into the poor/boilerplate style
documentation traps you describe (which we do have some of :-(). I think
people are just used to reading the prototype and then looking for the
comment above it, no matter how unnatural/inefficient/illogical that
might seem.

One specific pitfall which trips me up is that when one has multiple
commented function prototypes in a block, thus:

	a_function(...)
	/* describe function a...
	 * ...
	 * at length
	 */
	b_function(...)
	/* describe function b...
	 * ...
	 * at length
	 */
then figuring out which comment goes with which prototype is non-obvious
and since I naturally look above the prototype for the comment I
inevitably get the wrong one. This is compounded somewhat because we
tend to document other types of object above rather than below and
function prototypes are therefore something of a special case.
(admittedly the correct solution here is more line breaks whatever the
style of commenting used)

We seem to have a mixture of both styles in libxl headers which is
obviously much worse than either option. If an opinion is needed to tip
the scales then I lean slightly towards commenting above but not
noticeably changing the style of commentary.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 14:27:34 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 14:27:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ra6qc-0003tg-ML; Mon, 12 Dec 2011 14:27:18 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Ra6qa-0003tb-IH
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 14:27:16 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1323699958!44513528!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDc4NQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16043 invoked from network); 12 Dec 2011 14:25:59 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Dec 2011 14:25:59 -0000
X-IronPort-AV: E=Sophos;i="4.71,339,1320624000"; 
   d="scan'208";a="9418714"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Dec 2011 14:26:28 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 12 Dec 2011 14:26:28 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Ra6pn-0007cp-Rq; Mon, 12 Dec 2011 14:26:27 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Ra6pn-00065a-RB;
	Mon, 12 Dec 2011 14:26:27 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20198.3859.619446.718758@mariner.uk.xensource.com>
Date: Mon, 12 Dec 2011 14:26:27 +0000
To: xen-devel.GarveyPatrickD@OrdinaryAmerican.net
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <CACm5R6Sv2isGevS-gzprj6w0qnbKehpbC5=ai16zh29oty7jLg@mail.gmail.com>
References: <CACm5R6Sv2isGevS-gzprj6w0qnbKehpbC5=ai16zh29oty7jLg@mail.gmail.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Xen Wiki Spaceflight page
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

xen-devel.GarveyPatrickD@OrdinaryAmerican.net writes ("[Xen-devel] Xen Wiki Spaceflight page"):
> According to http://wiki.xen.org/wiki/Special:AllPages
> there is a page http://wiki.xen.org/wiki/Spaceflight
> When I use the link there is a redirection to
> https://en.wikipedia.org/wiki/Spaceflight?rdfrom=http%3A%2F%2Fwiki.xen.org%2Fwiki%3Ftitle%3DSpaceflight%26redirect%3Dno
> 
> Was http://wiki.xen.org/wiki/Spaceflight purposely created?
> Is it needed in http://wiki.xen.org/wiki/
> Can it be removed?

I think it was a mistake (probably, an example which comes with the
mediawiki installation) and have removed it.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 14:27:34 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 14:27:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ra6qc-0003tg-ML; Mon, 12 Dec 2011 14:27:18 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Ra6qa-0003tb-IH
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 14:27:16 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1323699958!44513528!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDc4NQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16043 invoked from network); 12 Dec 2011 14:25:59 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Dec 2011 14:25:59 -0000
X-IronPort-AV: E=Sophos;i="4.71,339,1320624000"; 
   d="scan'208";a="9418714"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Dec 2011 14:26:28 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 12 Dec 2011 14:26:28 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Ra6pn-0007cp-Rq; Mon, 12 Dec 2011 14:26:27 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Ra6pn-00065a-RB;
	Mon, 12 Dec 2011 14:26:27 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20198.3859.619446.718758@mariner.uk.xensource.com>
Date: Mon, 12 Dec 2011 14:26:27 +0000
To: xen-devel.GarveyPatrickD@OrdinaryAmerican.net
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <CACm5R6Sv2isGevS-gzprj6w0qnbKehpbC5=ai16zh29oty7jLg@mail.gmail.com>
References: <CACm5R6Sv2isGevS-gzprj6w0qnbKehpbC5=ai16zh29oty7jLg@mail.gmail.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Xen Wiki Spaceflight page
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

xen-devel.GarveyPatrickD@OrdinaryAmerican.net writes ("[Xen-devel] Xen Wiki Spaceflight page"):
> According to http://wiki.xen.org/wiki/Special:AllPages
> there is a page http://wiki.xen.org/wiki/Spaceflight
> When I use the link there is a redirection to
> https://en.wikipedia.org/wiki/Spaceflight?rdfrom=http%3A%2F%2Fwiki.xen.org%2Fwiki%3Ftitle%3DSpaceflight%26redirect%3Dno
> 
> Was http://wiki.xen.org/wiki/Spaceflight purposely created?
> Is it needed in http://wiki.xen.org/wiki/
> Can it be removed?

I think it was a mistake (probably, an example which comes with the
mediawiki installation) and have removed it.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 14:34:59 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 14:34:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ra6xi-0004Ll-8G; Mon, 12 Dec 2011 14:34:38 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1Ra6xg-0004LN-2i
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 14:34:36 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1323700422!5934536!1
X-Originating-IP: [209.85.214.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13608 invoked from network); 12 Dec 2011 14:33:42 -0000
Received: from mail-bw0-f43.google.com (HELO mail-bw0-f43.google.com)
	(209.85.214.43)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Dec 2011 14:33:42 -0000
Received: by bkbzs2 with SMTP id zs2so18184859bkb.30
	for <xen-devel@lists.xensource.com>;
	Mon, 12 Dec 2011 06:33:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=LGJ7yeM0Nb14tZdjlILn5iPwDnrm4SUJLCOEqNPBk9E=;
	b=o/qfQCT+koeVngJTaov//4sytYdb2PS5AsdHbGMgnPR601o2oCi2KX6COdMVGwE/qe
	ThTxDKi3Nh4wwrDunudcXt3WB1pjPrzN3SKLc2WNisoJHAdRBdbQvJDpnW5vyY3OjGEA
	QpGyIkxKK4c77Cvj4NJ9A1QsbhIX/oDSRCLzo=
Received: by 10.205.128.132 with SMTP id he4mr10188482bkc.123.1323700421507;
	Mon, 12 Dec 2011 06:33:41 -0800 (PST)
Received: from [192.168.1.3] (host81-152-17-11.range81-152.btcentralplus.com.
	[81.152.17.11])
	by mx.google.com with ESMTPS id e8sm32183537bkd.7.2011.12.12.06.33.38
	(version=SSLv3 cipher=OTHER); Mon, 12 Dec 2011 06:33:40 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Mon, 12 Dec 2011 14:33:39 +0000
From: Keir Fraser <keir@xen.org>
To: Christoph Egger <Christoph.Egger@amd.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Message-ID: <CB0BC143.35A76%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH] microcode fix
Thread-Index: Acy42wnhAGCrGVJTJ0+sOy9gGxJ5Ww==
In-Reply-To: <4EE60958.70403@amd.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH] microcode fix
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 12/12/2011 14:02, "Christoph Egger" <Christoph.Egger@amd.com> wrote:

> 
> Remove hardcoded maximum size a microcode patch can have.
> This is dynamic now.

The patch doesn't apply to xen-unstable tip.

 -- Keir

> The microcode patch for family15h can be larger than 2048 bytes
> and gets silently truncated.
> 
> Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>
> 
> P.S. Please apply this to Xen 4.1, 4.0, 3.4 and 3.3, too.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 14:34:59 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 14:34:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ra6xi-0004Ll-8G; Mon, 12 Dec 2011 14:34:38 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1Ra6xg-0004LN-2i
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 14:34:36 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1323700422!5934536!1
X-Originating-IP: [209.85.214.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13608 invoked from network); 12 Dec 2011 14:33:42 -0000
Received: from mail-bw0-f43.google.com (HELO mail-bw0-f43.google.com)
	(209.85.214.43)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Dec 2011 14:33:42 -0000
Received: by bkbzs2 with SMTP id zs2so18184859bkb.30
	for <xen-devel@lists.xensource.com>;
	Mon, 12 Dec 2011 06:33:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=LGJ7yeM0Nb14tZdjlILn5iPwDnrm4SUJLCOEqNPBk9E=;
	b=o/qfQCT+koeVngJTaov//4sytYdb2PS5AsdHbGMgnPR601o2oCi2KX6COdMVGwE/qe
	ThTxDKi3Nh4wwrDunudcXt3WB1pjPrzN3SKLc2WNisoJHAdRBdbQvJDpnW5vyY3OjGEA
	QpGyIkxKK4c77Cvj4NJ9A1QsbhIX/oDSRCLzo=
Received: by 10.205.128.132 with SMTP id he4mr10188482bkc.123.1323700421507;
	Mon, 12 Dec 2011 06:33:41 -0800 (PST)
Received: from [192.168.1.3] (host81-152-17-11.range81-152.btcentralplus.com.
	[81.152.17.11])
	by mx.google.com with ESMTPS id e8sm32183537bkd.7.2011.12.12.06.33.38
	(version=SSLv3 cipher=OTHER); Mon, 12 Dec 2011 06:33:40 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Mon, 12 Dec 2011 14:33:39 +0000
From: Keir Fraser <keir@xen.org>
To: Christoph Egger <Christoph.Egger@amd.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Message-ID: <CB0BC143.35A76%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH] microcode fix
Thread-Index: Acy42wnhAGCrGVJTJ0+sOy9gGxJ5Ww==
In-Reply-To: <4EE60958.70403@amd.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH] microcode fix
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 12/12/2011 14:02, "Christoph Egger" <Christoph.Egger@amd.com> wrote:

> 
> Remove hardcoded maximum size a microcode patch can have.
> This is dynamic now.

The patch doesn't apply to xen-unstable tip.

 -- Keir

> The microcode patch for family15h can be larger than 2048 bytes
> and gets silently truncated.
> 
> Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>
> 
> P.S. Please apply this to Xen 4.1, 4.0, 3.4 and 3.3, too.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 14:39:49 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 14: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.xensource.com>)
	id 1Ra72Z-0004Zg-Rk; Mon, 12 Dec 2011 14:39:39 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <brace@beardog.cce.hp.com>) id 1RYP2y-0000cd-Jy
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 21:29:00 +0000
X-Env-Sender: brace@beardog.cce.hp.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1323293174!47405406!1
X-Originating-IP: [15.216.28.36]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTUuMjE2LjI4LjM2ID0+IDc4MTc2MA==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3880 invoked from network); 7 Dec 2011 21:26:15 -0000
Received: from g1t0029.austin.hp.com (HELO g1t0029.austin.hp.com)
	(15.216.28.36)
	by server-14.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 7 Dec 2011 21:26:15 -0000
Received: from g1t0038.austin.hp.com (g1t0038.austin.hp.com [16.236.32.44])
	by g1t0029.austin.hp.com (Postfix) with ESMTP id B244B3812A
	for <xen-devel@lists.xensource.com>;
	Wed,  7 Dec 2011 21:28:16 +0000 (UTC)
Received: from beardog.cce.hp.com (beardog.cce.hp.com [16.84.84.24])
	by g1t0038.austin.hp.com (Postfix) with ESMTP id 92DD330042
	for <xen-devel@lists.xensource.com>;
	Wed,  7 Dec 2011 21:28:16 +0000 (UTC)
Received: from beardog.cce.hp.com (beardog.cce.hp.com [127.0.0.1])
	by beardog.cce.hp.com (8.13.8/8.13.8) with ESMTP id pB7LSEF9014722
	for <xen-devel@lists.xensource.com>; Wed, 7 Dec 2011 15:28:14 -0600
Received: (from brace@localhost)
	by beardog.cce.hp.com (8.13.8/8.13.8/Submit) id pB7LSEDf014721
	for xen-devel@lists.xensource.com; Wed, 7 Dec 2011 15:28:14 -0600
Date: Wed, 7 Dec 2011 15:28:14 -0600
From: brace@beardog.cce.hp.com
Message-Id: <201112072128.pB7LSEDf014721@beardog.cce.hp.com>
To: xen-devel@lists.xensource.com
X-Mailman-Approved-At: Mon, 12 Dec 2011 14:39:35 +0000
Subject: [Xen-devel] kmap_atomic issue with SLES11SP1 32bit XEN
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 14:39:49 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 14: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.xensource.com>)
	id 1Ra72c-0004cB-AX; Mon, 12 Dec 2011 14:39:42 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raghukt@linux.vnet.ibm.com>) id 1RYyBc-0007H0-Ka
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 11:00:16 +0000
X-Env-Sender: raghukt@linux.vnet.ibm.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1323428242!47620017!1
X-Originating-IP: [202.81.31.141]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjAyLjgxLjMxLjE0MSA9PiA2Mjg4Mg==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31363 invoked from network); 9 Dec 2011 10:57:25 -0000
Received: from e23smtp08.au.ibm.com (HELO e23smtp08.au.ibm.com) (202.81.31.141)
	by server-14.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 9 Dec 2011 10:57:25 -0000
Received: from /spool/local
	by e23smtp08.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use
	Only! Violators will be prosecuted
	for <xen-devel@lists.xensource.com> from <raghukt@linux.vnet.ibm.com>; 
	Fri, 9 Dec 2011 10:57:39 +1000
Received: from d23relay05.au.ibm.com ([202.81.31.247])
	by e23smtp08.au.ibm.com ([202.81.31.205]) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Fri, 9 Dec 2011 10:57:37 +1000
Received: from d23av04.au.ibm.com (d23av04.au.ibm.com [9.190.235.139])
	by d23relay05.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	pB9AtYbU2789612
	for <xen-devel@lists.xensource.com>; Fri, 9 Dec 2011 21:55:35 +1100
Received: from d23av04.au.ibm.com (loopback [127.0.0.1])
	by d23av04.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id
	pB9AxDjW023483
	for <xen-devel@lists.xensource.com>; Fri, 9 Dec 2011 21:59:15 +1100
Received: from oc5400248562.ibm.com (oc5400248562.in.ibm.com [9.124.35.237])
	by d23av04.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	pB9Ax8mR023408; Fri, 9 Dec 2011 21:59:09 +1100
Message-ID: <4EE1E9FA.5030307@linux.vnet.ibm.com>
Date: Fri, 09 Dec 2011 16:29:06 +0530
From: Raghavendra K T <raghukt@linux.vnet.ibm.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
	rv:1.9.2.24) Gecko/20111108 Fedora/3.1.16-1.fc14 Thunderbird/3.1.16
MIME-Version: 1.0
To: Avi Kivity <avi@redhat.com>
References: <20111130085921.23386.89708.sendpatchset@oc5400248562.ibm.com>
	<20111130085959.23386.69166.sendpatchset@oc5400248562.ibm.com>
	<20111207104849.GA24849@amt.cnet>
	<4EDF5413.1030107@linux.vnet.ibm.com>
	<20111207123330.GA32212@amt.cnet> <4EDF6049.2030204@redhat.com>
	<20111207133947.GA1708@amt.cnet> <4EDF7DC5.5010504@redhat.com>
	<4EDF987B.8040900@linux.vnet.ibm.com> <4EE08606.2060508@redhat.com>
In-Reply-To: <4EE08606.2060508@redhat.com>
x-cbid: 11120900-5140-0000-0000-00000065E133
X-Mailman-Approved-At: Mon, 12 Dec 2011 14:39:35 +0000
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, x86@kernel.org,
	Gleb Natapov <gleb@redhat.com>, Peter Zijlstra <peterz@infradead.org>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Xen <xen-devel@lists.xensource.com>,
	Dave Jiang <dave.jiang@intel.com>, KVM <kvm@vger.kernel.org>,
	Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	Ingo Molnar <mingo@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>,
	Sasha Levin <levinsasha928@gmail.com>, Sedat Dilek <sedat.dilek@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>, Yinghai Lu <yinghai@kernel.org>,
	Greg Kroah-Hartman <gregkh@suse.de>, Marcelo Tosatti <mtosatti@redhat.com>,
	LKML <linux-kernel@vger.kernel.org>, Dave Hansen <dave@linux.vnet.ibm.com>,
	Suzuki Poulose <suzuki@linux.vnet.ibm.com>
Subject: Re: [Xen-devel] [PATCH RFC V3 2/4] kvm hypervisor : Add a hypercall
 to KVM hypervisor to support pv-ticketlocks
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 12/08/2011 03:10 PM, Avi Kivity wrote:
> On 12/07/2011 06:46 PM, Raghavendra K T wrote:
>> On 12/07/2011 08:22 PM, Avi Kivity wrote:
>>> On 12/07/2011 03:39 PM, Marcelo Tosatti wrote:
>>>>> Also I think we can keep the kicked flag in vcpu->requests, no need
>>>>> for
>>>>> new storage.
>>>>
>>>> Was going to suggest it but it violates the currently organized
>>>> processing of entries at the beginning of vcpu_enter_guest.
>>>>
>>>> That is, this "kicked" flag is different enough from vcpu->requests
>>>> processing that a separate variable seems worthwhile (even more
>>>> different with convertion to MP_STATE at KVM_GET_MP_STATE).
>>>
>>> IMO, it's similar to KVM_REQ_EVENT (which can also cause mpstate to
>>> change due to apic re-evaluation).
>>>
>>
>> Ok, So what I understand is we have to either :
>> 1. retain current kick flag AS-IS but would have to make it migration
>> friendly. [I still have to get more familiar with migration side]
>> or
>> 2. introduce notion similar to KVM_REQ_PVLOCK_KICK(??) to be part of
>> vcpu->requests.
>>
>> So what would be better? Please let me know.
>>
>
> IMO, KVM_REQ.
>

Ok, 'll continue in this direction. Hmm I think now the race condition 
should be kept in mind, pointed by Marcello.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 14:39:49 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 14: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.xensource.com>)
	id 1Ra72b-0004ax-1E; Mon, 12 Dec 2011 14:39:41 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <dab@hp.com>)
	id 1RYPTF-0001an-5q
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 21:56:09 +0000
X-Env-Sender: dab@hp.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1323294888!51541055!1
X-Originating-IP: [15.216.28.33]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTUuMjE2LjI4LjMzID0+IDc1NTQ2OQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16281 invoked from network); 7 Dec 2011 21:54:49 -0000
Received: from g1t0026.austin.hp.com (HELO g1t0026.austin.hp.com)
	(15.216.28.33)
	by server-4.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 7 Dec 2011 21:54:49 -0000
Received: from g1t0039.austin.hp.com (g1t0039.austin.hp.com [16.236.32.45])
	by g1t0026.austin.hp.com (Postfix) with ESMTP id 69AE1C0B8
	for <xen-devel@lists.xensource.com>;
	Wed,  7 Dec 2011 21:55:20 +0000 (UTC)
Received: from [10.10.13.84] (data.cce.hp.com [16.84.84.25])
	by g1t0039.austin.hp.com (Postfix) with ESMTP id 540E034068;
	Wed,  7 Dec 2011 21:55:20 +0000 (UTC)
Message-ID: <4EDFE140.7040600@hp.com>
Date: Wed, 07 Dec 2011 15:57:20 -0600
From: dbrace <dab@hp.com>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: scameron@beardog.cce.hp.com
References: <4EDFDF0D.2020104@hp.com>
	<20111207215219.GH6635@beardog.cce.hp.com>
In-Reply-To: <20111207215219.GH6635@beardog.cce.hp.com>
X-Mailman-Approved-At: Mon, 12 Dec 2011 14:39:35 +0000
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] kmap_atomic issue with SLES11SP1 32bit XEN driver
	code
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Yes

On 12/07/2011 03:52 PM, scameron@beardog.cce.hp.com wrote:
> On Wed, Dec 07, 2011 at 03:47:57PM -0600, dbrace wrote:
>> kernel: Linux 360 2.6.32.12-0.7-xen #1 SMP 2010-05-20 11:14:20 +0200
>> i686 i686 i386 GNU/Linux
>>
>> I am having issues with some code that uses kmap_atomic(). I am getting:
>>
>> BUG: unable to handle kernel paging request at 23a1a000 (which is the
>> address returned from kmap_atomic().)
>>
>> The same code works when running on non-XEN 32bit kernels so I am
>> wondering why this does not work under
>> XEN kernels. Is there a different approach that I need to take for 32bit
>> XEN kernels?
>>
>> I really only need to do this code segment if the memory address is a
>> high memory address. Is there a MACRO or function
>> that can help me determine this?
>>
>> Here is a code snippet:
>>
>>                  void *linux_vaddr = NULL;       /* kmapped temporary
>> virtual address */
>>                  int linux_page_offset = 0;      /* offset in page */
>>                  int count = 0;                  /* bytes left to
>> transfer */
>>                  int left = byte_count;          /* number of bytes left
>> to transfer */
>>                  int memcpysize = 0;             /* current size to
>> transfer */
>>                  struct page *linux_page = NULL; /* calculated page */
>>                  int kmap_flags = 0;
>>
>>                  linux_page = __pfn_to_page(physical_address>>  PAGE_SHIFT);
>>                  linux_page_offset = (physical_address&
>> 0x0000000000000FFFULL);
>>                  memcpysize =  min((PAGE_SIZE - linux_page_offset), left);
>>
>>                  kmap_flags = KM_USER0;
>>
>>                  linux_vaddr = kmap_atomic(linux_page, kmap_flags) +
>> linux_page_offset;
>>
>>                  printk("%s: called kmap_atomic, "
>>                          "calling memcpy linux_vaddr = 0x%x virt_address
>> = 0x%x count = 0x%x\n",
>>                          __func__, linux_vaddr, virt_address, count);
>>                  /*
>>                   * Either need to copy to a kmapped destination
>>                   * or a kmapped source.
>>                   */
>>                  if (type == 0) // Write to s/g element, dest virtual
>> addr was known.
>>                          memcpy((void *)virt_address+count, (void
>> *)linux_vaddr, memcpysize);
>>                  else // Source virt. address was known.
>>                          memcpy((void *)linux_vaddr, (void
>> *)virt_address+count, memcpysize);
> Just to be clear, it's these memcpy's that get the BUG, correct?
>
> -- steve
>
>
>>                  printk("OS_Linux32_Xfer_SG_Page: calling kunmap_atomic, "
>>                          "calling memcpy linux_vaddr = 0x%lx\n",
>> linux_vaddr);
>>
>>                  kunmap_atomic(linux_vaddr, kmap_flags);
>>
>>
>> -- 
>> Don Brace
>> SPSN Linux Development
>> Hewlett-Packard Company

-- 
Don Brace
SPSN Linux Development
Hewlett-Packard Company

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 14:39:49 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 14: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.xensource.com>)
	id 1Ra72Z-0004Z0-0M; Mon, 12 Dec 2011 14:39:39 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raghukt@linux.vnet.ibm.com>) id 1RYKez-0001Bt-4Z
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 16:47:57 +0000
X-Env-Sender: raghukt@linux.vnet.ibm.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1323276403!51272636!1
X-Originating-IP: [122.248.162.3]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTIyLjI0OC4xNjIuMyA9PiAxOTAxNjA=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31508 invoked from network); 7 Dec 2011 16:46:47 -0000
Received: from e28smtp03.in.ibm.com (HELO e28smtp03.in.ibm.com) (122.248.162.3)
	by server-13.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 7 Dec 2011 16:46:47 -0000
Received: from /spool/local
	by e28smtp03.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use
	Only! Violators will be prosecuted
	for <xen-devel@lists.xensource.com> from <raghukt@linux.vnet.ibm.com>; 
	Wed, 7 Dec 2011 22:17:04 +0530
Received: from d28relay04.in.ibm.com (9.184.220.61)
	by e28smtp03.in.ibm.com (192.168.1.133) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Wed, 7 Dec 2011 22:16:59 +0530
Received: from d28av02.in.ibm.com (d28av02.in.ibm.com [9.184.220.64])
	by d28relay04.in.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	pB7GkwnX2867368
	for <xen-devel@lists.xensource.com>; Wed, 7 Dec 2011 22:16:58 +0530
Received: from d28av02.in.ibm.com (loopback [127.0.0.1])
	by d28av02.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id
	pB7Gkvx5012332
	for <xen-devel@lists.xensource.com>; Thu, 8 Dec 2011 03:46:58 +1100
Received: from oc5400248562.ibm.com ([9.77.196.131])
	by d28av02.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	pB7Gks5c012278; Thu, 8 Dec 2011 03:46:54 +1100
Message-ID: <4EDF987B.8040900@linux.vnet.ibm.com>
Date: Wed, 07 Dec 2011 22:16:51 +0530
From: Raghavendra K T <raghukt@linux.vnet.ibm.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
	rv:1.9.2.24) Gecko/20111108 Fedora/3.1.16-1.fc14 Thunderbird/3.1.16
MIME-Version: 1.0
To: Avi Kivity <avi@redhat.com>
References: <20111130085921.23386.89708.sendpatchset@oc5400248562.ibm.com>
	<20111130085959.23386.69166.sendpatchset@oc5400248562.ibm.com>
	<20111207104849.GA24849@amt.cnet>
	<4EDF5413.1030107@linux.vnet.ibm.com>
	<20111207123330.GA32212@amt.cnet> <4EDF6049.2030204@redhat.com>
	<20111207133947.GA1708@amt.cnet> <4EDF7DC5.5010504@redhat.com>
In-Reply-To: <4EDF7DC5.5010504@redhat.com>
x-cbid: 11120716-3864-0000-0000-00000069025E
X-Mailman-Approved-At: Mon, 12 Dec 2011 14:39:35 +0000
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, x86@kernel.org,
	Gleb Natapov <gleb@redhat.com>, Peter Zijlstra <peterz@infradead.org>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Xen <xen-devel@lists.xensource.com>,
	Dave Jiang <dave.jiang@intel.com>, KVM <kvm@vger.kernel.org>,
	Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	Ingo Molnar <mingo@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>,
	Sasha Levin <levinsasha928@gmail.com>, Sedat Dilek <sedat.dilek@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>, Yinghai Lu <yinghai@kernel.org>,
	Greg Kroah-Hartman <gregkh@suse.de>, Marcelo Tosatti <mtosatti@redhat.com>,
	LKML <linux-kernel@vger.kernel.org>, Dave Hansen <dave@linux.vnet.ibm.com>,
	Suzuki Poulose <suzuki@linux.vnet.ibm.com>
Subject: Re: [Xen-devel] [PATCH RFC V3 2/4] kvm hypervisor : Add a hypercall
 to KVM hypervisor to support pv-ticketlocks
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 12/07/2011 08:22 PM, Avi Kivity wrote:
> On 12/07/2011 03:39 PM, Marcelo Tosatti wrote:
>>> Also I think we can keep the kicked flag in vcpu->requests, no need for
>>> new storage.
>>
>> Was going to suggest it but it violates the currently organized
>> processing of entries at the beginning of vcpu_enter_guest.
>>
>> That is, this "kicked" flag is different enough from vcpu->requests
>> processing that a separate variable seems worthwhile (even more
>> different with convertion to MP_STATE at KVM_GET_MP_STATE).
>
> IMO, it's similar to KVM_REQ_EVENT (which can also cause mpstate to
> change due to apic re-evaluation).
>

Ok, So what I understand is we have to either :
1. retain current kick flag AS-IS but would have to make it migration 
friendly. [I still have to get more familiar with migration side]
or
2. introduce notion similar to KVM_REQ_PVLOCK_KICK(??) to be part of
vcpu->requests.

So what would be better? Please let me know.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 14:39:49 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 14: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.xensource.com>)
	id 1Ra72a-0004a7-88; Mon, 12 Dec 2011 14:39:40 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <dab@hp.com>)
	id 1RYPKB-0001Z9-FI
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 21:46:47 +0000
X-Env-Sender: dab@hp.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1323294358!4487689!1
X-Originating-IP: [15.192.0.46]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTUuMTkyLjAuNDYgPT4gNjQzMDEz\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20904 invoked from network); 7 Dec 2011 21:46:00 -0000
Received: from g5t0009.atlanta.hp.com (HELO g5t0009.atlanta.hp.com)
	(15.192.0.46)
	by server-15.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 7 Dec 2011 21:46:00 -0000
Received: from g5t0029.atlanta.hp.com (g5t0029.atlanta.hp.com [16.228.8.141])
	by g5t0009.atlanta.hp.com (Postfix) with ESMTP id 662DB30189
	for <xen-devel@lists.xensource.com>;
	Wed,  7 Dec 2011 21:45:58 +0000 (UTC)
Received: from [10.10.13.84] (data.cce.hp.com [16.84.84.25])
	by g5t0029.atlanta.hp.com (Postfix) with ESMTP id BE29320240;
	Wed,  7 Dec 2011 21:45:57 +0000 (UTC)
Message-ID: <4EDFDF0D.2020104@hp.com>
Date: Wed, 07 Dec 2011 15:47:57 -0600
From: dbrace <dab@hp.com>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: xen-devel@lists.xensource.com
X-Mailman-Approved-At: Mon, 12 Dec 2011 14:39:35 +0000
Subject: [Xen-devel] kmap_atomic issue with SLES11SP1 32bit XEN driver code
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

kernel: Linux 360 2.6.32.12-0.7-xen #1 SMP 2010-05-20 11:14:20 +0200 
i686 i686 i386 GNU/Linux

I am having issues with some code that uses kmap_atomic(). I am getting:

BUG: unable to handle kernel paging request at 23a1a000 (which is the 
address returned from kmap_atomic().)

The same code works when running on non-XEN 32bit kernels so I am  
wondering why this does not work under
XEN kernels. Is there a different approach that I need to take for 32bit 
XEN kernels?

I really only need to do this code segment if the memory address is a 
high memory address. Is there a MACRO or function
that can help me determine this?

Here is a code snippet:

                 void *linux_vaddr = NULL;       /* kmapped temporary 
virtual address */
                 int linux_page_offset = 0;      /* offset in page */
                 int count = 0;                  /* bytes left to 
transfer */
                 int left = byte_count;          /* number of bytes left 
to transfer */
                 int memcpysize = 0;             /* current size to 
transfer */
                 struct page *linux_page = NULL; /* calculated page */
                 int kmap_flags = 0;

                 linux_page = __pfn_to_page(physical_address >> PAGE_SHIFT);
                 linux_page_offset = (physical_address & 
0x0000000000000FFFULL);
                 memcpysize =  min((PAGE_SIZE - linux_page_offset), left);

                 kmap_flags = KM_USER0;

                 linux_vaddr = kmap_atomic(linux_page, kmap_flags) + 
linux_page_offset;

                 printk("%s: called kmap_atomic, "
                         "calling memcpy linux_vaddr = 0x%x virt_address 
= 0x%x count = 0x%x\n",
                         __func__, linux_vaddr, virt_address, count);
                 /*
                  * Either need to copy to a kmapped destination
                  * or a kmapped source.
                  */
                 if (type == 0) // Write to s/g element, dest virtual 
addr was known.
                         memcpy((void *)virt_address+count, (void 
*)linux_vaddr, memcpysize);
                 else // Source virt. address was known.
                         memcpy((void *)linux_vaddr, (void 
*)virt_address+count, memcpysize);

                 printk("OS_Linux32_Xfer_SG_Page: calling kunmap_atomic, "
                         "calling memcpy linux_vaddr = 0x%lx\n", 
linux_vaddr);

                 kunmap_atomic(linux_vaddr, kmap_flags);


-- 
Don Brace
SPSN Linux Development
Hewlett-Packard Company

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 14:39:48 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 14:39:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ra72W-0004Y7-Ph; Mon, 12 Dec 2011 14:39:36 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <mtosatti@redhat.com>) id 1RYGih-0002MO-6q
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 12:35:31 +0000
X-Env-Sender: mtosatti@redhat.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1323261261!51225604!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDYzMzc=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21545 invoked from network); 7 Dec 2011 12:34:22 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-13.tower-27.messagelabs.com with SMTP;
	7 Dec 2011 12:34:22 -0000
Received: from int-mx10.intmail.prod.int.phx2.redhat.com
	(int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id pB7CXwll022301
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 7 Dec 2011 07:33:58 -0500
Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199])
	by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id pB7CXvDK004147; Wed, 7 Dec 2011 07:33:57 -0500
Received: from amt.cnet (vpn-11-217.rdu.redhat.com [10.11.11.217])
	by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id pB7CXtdM022078;
	Wed, 7 Dec 2011 07:33:55 -0500
Received: from amt.cnet (amt.cnet [127.0.0.1])
	by amt.cnet (Postfix) with ESMTP id 7A9A6652179;
	Wed,  7 Dec 2011 10:33:36 -0200 (BRST)
Received: (from marcelo@localhost)
	by amt.cnet (8.14.5/8.14.5/Submit) id pB7CXUCl000393;
	Wed, 7 Dec 2011 10:33:30 -0200
Date: Wed, 7 Dec 2011 10:33:30 -0200
From: Marcelo Tosatti <mtosatti@redhat.com>
To: Raghavendra K T <raghukt@linux.vnet.ibm.com>
Message-ID: <20111207123330.GA32212@amt.cnet>
References: <20111130085921.23386.89708.sendpatchset@oc5400248562.ibm.com>
	<20111130085959.23386.69166.sendpatchset@oc5400248562.ibm.com>
	<20111207104849.GA24849@amt.cnet>
	<4EDF5413.1030107@linux.vnet.ibm.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4EDF5413.1030107@linux.vnet.ibm.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
X-Mailman-Approved-At: Mon, 12 Dec 2011 14:39:35 +0000
Cc: x86@kernel.org, Gleb Natapov <gleb@redhat.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Xen <xen-devel@lists.xensource.com>,
	Dave Jiang <dave.jiang@intel.com>, KVM <kvm@vger.kernel.org>,
	Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	Ingo Molnar <mingo@redhat.com>, Avi Kivity <avi@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>,
	Sasha Levin <levinsasha928@gmail.com>, Sedat Dilek <sedat.dilek@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>, Yinghai Lu <yinghai@kernel.org>,
	Greg Kroah-Hartman <gregkh@suse.de>, LKML <linux-kernel@vger.kernel.org>,
	Dave Hansen <dave@linux.vnet.ibm.com>,
	Suzuki Poulose <suzuki@linux.vnet.ibm.com>
Subject: Re: [Xen-devel] [PATCH RFC V3 2/4] kvm hypervisor : Add a hypercall
 to KVM hypervisor to support pv-ticketlocks
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Dec 07, 2011 at 05:24:59PM +0530, Raghavendra K T wrote:
> On 12/07/2011 04:18 PM, Marcelo Tosatti wrote:
> >On Wed, Nov 30, 2011 at 02:29:59PM +0530, Raghavendra K T wrote:
> >>
> >>+/*
> >>+ * kvm_pv_kick_cpu_op:  Kick a vcpu.
> >>+ *
> >>+ * @cpu - vcpu to be kicked.
> >>+ */
> >>+static void kvm_pv_kick_cpu_op(struct kvm *kvm, int cpu)
> >>+{
> >>+	struct kvm_vcpu *vcpu = kvm_get_vcpu(kvm, cpu);
> >>+	struct kvm_mp_state mp_state;
> >>+
> >>+	mp_state.mp_state = KVM_MP_STATE_RUNNABLE;
> >
> >Since vcpu->mp_state is not protected by a lock, this is potentially racy. For example:
> >
> >CPU0						CPU1
> >kvm_pv_kick_cpu_op				running vcpuN
> >vcpuN->mp_state = KVM_MP_STATE_RUNNABLE;
> >						kvm_emulate_halt
> >						vcpuN->mp_state = KVM_MP_STATE_HALTED
> >
> >Is it harmless to lose a kick?
> >
> 
> Yes you are right. It was potentially racy and it was harmful too!.
> I had observed that it was stalling the CPU before I introduced
> kicked flag.
> 
> But now,
> 
> vcpu->kicked = 1  ==> kvm_make_request(KVM_REQ_UNHALT, vcpu); ==>

Ok, please use a more descriptive name, such as "pvlock_kicked" or
something.

> 
> __vcpu_run() ==> kvm_check_request(KVM_REQ_UNHALT, vcpu) ==>
> 
> vcpuN->mp_state = KVM_MP_STATE_RUNNABLE; so eventually we will end up
> in RUNNABLE.
> 
> Also Avi pointed that, logically kvm_arch_vcpu_ioctl_set_mpstate should
> be called only in vcpu thread, so after further debugging, I noticed
> that,  setting vcpuN->mp_state = KVM_MP_STATE_RUNNABLE; is not
> necessary.
> I 'll remove that in the next patch. Thanks for pointing.

In fact you don't need kvm_arch_vcpu_ioctl_set_mpstate either, only the
new "kicked" flag.

> 
> 
> 			

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 14:39:49 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 14: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.xensource.com>)
	id 1Ra72X-0004YE-7w; Mon, 12 Dec 2011 14:39:37 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <avi@redhat.com>) id 1RYGv4-0002Vj-S5
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 12:48:19 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1323262051!6453519!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDYzMzc=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12578 invoked from network); 7 Dec 2011 12:47:31 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-11.tower-216.messagelabs.com with SMTP;
	7 Dec 2011 12:47:31 -0000
Received: from int-mx12.intmail.prod.int.phx2.redhat.com
	(int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id pB7ClCjW032375
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 7 Dec 2011 07:47:13 -0500
Received: from balrog.usersys.redhat.com (dhcp-4-24.tlv.redhat.com
	[10.35.4.24])
	by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id pB7Cl6rs022269; Wed, 7 Dec 2011 07:47:06 -0500
Message-ID: <4EDF6049.2030204@redhat.com>
Date: Wed, 07 Dec 2011 14:47:05 +0200
From: Avi Kivity <avi@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:8.0) Gecko/20111115 Thunderbird/8.0
MIME-Version: 1.0
To: Marcelo Tosatti <mtosatti@redhat.com>
References: <20111130085921.23386.89708.sendpatchset@oc5400248562.ibm.com>
	<20111130085959.23386.69166.sendpatchset@oc5400248562.ibm.com>
	<20111207104849.GA24849@amt.cnet>
	<4EDF5413.1030107@linux.vnet.ibm.com>
	<20111207123330.GA32212@amt.cnet>
In-Reply-To: <20111207123330.GA32212@amt.cnet>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.25
X-Mailman-Approved-At: Mon, 12 Dec 2011 14:39:35 +0000
Cc: Raghavendra K T <raghukt@linux.vnet.ibm.com>, x86@kernel.org,
	Gleb Natapov <gleb@redhat.com>, Peter Zijlstra <peterz@infradead.org>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Xen <xen-devel@lists.xensource.com>,
	Dave Jiang <dave.jiang@intel.com>, KVM <kvm@vger.kernel.org>,
	Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	Ingo Molnar <mingo@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>,
	Sasha Levin <levinsasha928@gmail.com>, Sedat Dilek <sedat.dilek@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>, Yinghai Lu <yinghai@kernel.org>,
	Greg Kroah-Hartman <gregkh@suse.de>, LKML <linux-kernel@vger.kernel.org>,
	Dave Hansen <dave@linux.vnet.ibm.com>,
	Suzuki Poulose <suzuki@linux.vnet.ibm.com>
Subject: Re: [Xen-devel] [PATCH RFC V3 2/4] kvm hypervisor : Add a hypercall
 to KVM hypervisor to support pv-ticketlocks
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 12/07/2011 02:33 PM, Marcelo Tosatti wrote:
> > 
> > Also Avi pointed that, logically kvm_arch_vcpu_ioctl_set_mpstate should
> > be called only in vcpu thread, so after further debugging, I noticed
> > that,  setting vcpuN->mp_state = KVM_MP_STATE_RUNNABLE; is not
> > necessary.
> > I 'll remove that in the next patch. Thanks for pointing.
>
> In fact you don't need kvm_arch_vcpu_ioctl_set_mpstate either, only the
> new "kicked" flag.

If we have a kicked flag, it becomes necessary to live migrate it.

Maybe we can change KVM_GET_MP_STATE to fold the kicked flag into the mp
state (converting HALTED into RUNNABLE).

Also I think we can keep the kicked flag in vcpu->requests, no need for
new storage.

-- 
error compiling committee.c: too many arguments to function


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 14:39:49 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 14: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.xensource.com>)
	id 1Ra72Z-0004ZI-Ec; Mon, 12 Dec 2011 14:39:39 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dcmichael1256@gmail.com>) id 1RYMIm-0005QH-MQ
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 18:33:08 +0000
X-Env-Sender: dcmichael1256@gmail.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1323282695!59851008!1
X-Originating-IP: [209.85.161.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11227 invoked from network); 7 Dec 2011 18:31:36 -0000
Received: from mail-gx0-f171.google.com (HELO mail-gx0-f171.google.com)
	(209.85.161.171)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Dec 2011 18:31:36 -0000
Received: by ggnr4 with SMTP id r4so5266627ggn.30
	for <xen-devel@lists.xensource.com>;
	Wed, 07 Dec 2011 10:32:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=subject:from:to:content-type:date:message-id:mime-version:x-mailer
	:content-transfer-encoding;
	bh=rgj64MNDLhP1sAQ4OHYbFfBYaX0u2v4INxzP8cC1zmo=;
	b=WFxWrG9JtwRiNxAGy1hbg52vY2I/W5UQImLgKPNl1Zc8okIjCcIcVOMstlx9W8O6Pj
	GVXBYw+enQtC4a/r6d1fI65v66grbDpPmEzRdIe0KEOY1VGjP2Vzk7c5cd4sOD2ZTxqx
	EHkzDAZC+YMeCuCkPccqVOoXmJj6TwbjcM5zM=
Received: by 10.182.5.198 with SMTP id u6mr2074959obu.14.1323282745162;
	Wed, 07 Dec 2011 10:32:25 -0800 (PST)
Received: from [10.20.14.69] ([114.70.9.204])
	by mx.google.com with ESMTPS id ed2sm3559987obc.6.2011.12.07.10.32.19
	(version=SSLv3 cipher=OTHER); Wed, 07 Dec 2011 10:32:21 -0800 (PST)
From: DcMichael <dcmichael1256@gmail.com>
To: xen-devel@lists.xensource.com
Date: Thu, 08 Dec 2011 03:32:12 +0900
Message-ID: <1323282732.2750.6.camel@dcmichael-pc>
Mime-Version: 1.0
X-Mailer: Evolution 2.30.3 
X-Mailman-Approved-At: Mon, 12 Dec 2011 14:39:35 +0000
Subject: [Xen-devel] How to share memory with kernel and hypervisor?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi!
I'm first in here.
anyway I want to make kernel and hypervisor share there memory.
which the kernal write memory, then hypervisor can read it.
without any function like copy_from_user.

I'll use this memory very many time, so I want share memory like shmget.
but using ring use push function every time.

can I share memory like this way?


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 14:39:49 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 14: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.xensource.com>)
	id 1Ra72X-0004YL-Ly; Mon, 12 Dec 2011 14:39:37 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <mtosatti@redhat.com>) id 1RYHkX-0005jj-Vn
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 13:41:30 +0000
X-Env-Sender: mtosatti@redhat.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1323265242!6249142!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDYzMzc=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30061 invoked from network); 7 Dec 2011 13:40:42 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-11.tower-182.messagelabs.com with SMTP;
	7 Dec 2011 13:40:42 -0000
Received: from int-mx12.intmail.prod.int.phx2.redhat.com
	(int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id pB7DeMQj025141
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 7 Dec 2011 08:40:22 -0500
Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199])
	by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id pB7DeLoJ012344; Wed, 7 Dec 2011 08:40:21 -0500
Received: from amt.cnet (vpn-8-4.rdu.redhat.com [10.11.8.4])
	by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id pB7DeILa005286;
	Wed, 7 Dec 2011 08:40:19 -0500
Received: from amt.cnet (amt.cnet [127.0.0.1])
	by amt.cnet (Postfix) with ESMTP id E1603652179;
	Wed,  7 Dec 2011 11:39:58 -0200 (BRST)
Received: (from marcelo@localhost)
	by amt.cnet (8.14.5/8.14.5/Submit) id pB7DdlLu001814;
	Wed, 7 Dec 2011 11:39:47 -0200
Date: Wed, 7 Dec 2011 11:39:47 -0200
From: Marcelo Tosatti <mtosatti@redhat.com>
To: Avi Kivity <avi@redhat.com>
Message-ID: <20111207133947.GA1708@amt.cnet>
References: <20111130085921.23386.89708.sendpatchset@oc5400248562.ibm.com>
	<20111130085959.23386.69166.sendpatchset@oc5400248562.ibm.com>
	<20111207104849.GA24849@amt.cnet>
	<4EDF5413.1030107@linux.vnet.ibm.com>
	<20111207123330.GA32212@amt.cnet> <4EDF6049.2030204@redhat.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4EDF6049.2030204@redhat.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.25
X-Mailman-Approved-At: Mon, 12 Dec 2011 14:39:35 +0000
Cc: Raghavendra K T <raghukt@linux.vnet.ibm.com>, x86@kernel.org,
	Gleb Natapov <gleb@redhat.com>, Peter Zijlstra <peterz@infradead.org>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Xen <xen-devel@lists.xensource.com>,
	Dave Jiang <dave.jiang@intel.com>, KVM <kvm@vger.kernel.org>,
	Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	Ingo Molnar <mingo@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>,
	Sasha Levin <levinsasha928@gmail.com>, Sedat Dilek <sedat.dilek@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>, Yinghai Lu <yinghai@kernel.org>,
	Greg Kroah-Hartman <gregkh@suse.de>, LKML <linux-kernel@vger.kernel.org>,
	Dave Hansen <dave@linux.vnet.ibm.com>,
	Suzuki Poulose <suzuki@linux.vnet.ibm.com>
Subject: Re: [Xen-devel] [PATCH RFC V3 2/4] kvm hypervisor : Add a hypercall
 to KVM hypervisor to support pv-ticketlocks
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Dec 07, 2011 at 02:47:05PM +0200, Avi Kivity wrote:
> On 12/07/2011 02:33 PM, Marcelo Tosatti wrote:
> > > 
> > > Also Avi pointed that, logically kvm_arch_vcpu_ioctl_set_mpstate should
> > > be called only in vcpu thread, so after further debugging, I noticed
> > > that,  setting vcpuN->mp_state = KVM_MP_STATE_RUNNABLE; is not
> > > necessary.
> > > I 'll remove that in the next patch. Thanks for pointing.
> >
> > In fact you don't need kvm_arch_vcpu_ioctl_set_mpstate either, only the
> > new "kicked" flag.
> 
> If we have a kicked flag, it becomes necessary to live migrate it.
> 
> Maybe we can change KVM_GET_MP_STATE to fold the kicked flag into the mp
> state (converting HALTED into RUNNABLE).

Yep, that works.

> Also I think we can keep the kicked flag in vcpu->requests, no need for
> new storage.

Was going to suggest it but it violates the currently organized
processing of entries at the beginning of vcpu_enter_guest.

That is, this "kicked" flag is different enough from vcpu->requests
processing that a separate variable seems worthwhile (even more
different with convertion to MP_STATE at KVM_GET_MP_STATE).


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 14:39:50 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 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.xensource.com>)
	id 1Ra72Y-0004Yj-H7; Mon, 12 Dec 2011 14:39:38 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raghukt@linux.vnet.ibm.com>) id 1RYKQM-0000mJ-Ln
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 16:32:50 +0000
X-Env-Sender: raghukt@linux.vnet.ibm.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1323275519!7198072!1
X-Originating-IP: [122.248.162.9]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTIyLjI0OC4xNjIuOSA9PiA5NDQ1OA==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5674 invoked from network); 7 Dec 2011 16:32:03 -0000
Received: from e28smtp09.in.ibm.com (HELO e28smtp09.in.ibm.com) (122.248.162.9)
	by server-12.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 7 Dec 2011 16:32:03 -0000
Received: from /spool/local
	by e28smtp09.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use
	Only! Violators will be prosecuted
	for <xen-devel@lists.xensource.com> from <raghukt@linux.vnet.ibm.com>; 
	Wed, 7 Dec 2011 22:01:58 +0530
Received: from d28relay03.in.ibm.com (9.184.220.60)
	by e28smtp09.in.ibm.com (192.168.1.139) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Wed, 7 Dec 2011 22:01:53 +0530
Received: from d28av04.in.ibm.com (d28av04.in.ibm.com [9.184.220.66])
	by d28relay03.in.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	pB7GVpGM2109590
	for <xen-devel@lists.xensource.com>; Wed, 7 Dec 2011 22:01:52 +0530
Received: from d28av04.in.ibm.com (loopback [127.0.0.1])
	by d28av04.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id
	pB7GVnCl023412
	for <xen-devel@lists.xensource.com>; Thu, 8 Dec 2011 03:31:51 +1100
Received: from oc5400248562.ibm.com ([9.77.196.131])
	by d28av04.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	pB7GVk0s023266; Thu, 8 Dec 2011 03:31:46 +1100
Message-ID: <4EDF94F0.2080201@linux.vnet.ibm.com>
Date: Wed, 07 Dec 2011 22:01:44 +0530
From: Raghavendra K T <raghukt@linux.vnet.ibm.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
	rv:1.9.2.24) Gecko/20111108 Fedora/3.1.16-1.fc14 Thunderbird/3.1.16
MIME-Version: 1.0
To: Marcelo Tosatti <mtosatti@redhat.com>
References: <20111130085921.23386.89708.sendpatchset@oc5400248562.ibm.com>
	<20111130085959.23386.69166.sendpatchset@oc5400248562.ibm.com>
	<20111207104849.GA24849@amt.cnet>
	<4EDF5413.1030107@linux.vnet.ibm.com>
	<20111207123330.GA32212@amt.cnet>
In-Reply-To: <20111207123330.GA32212@amt.cnet>
x-cbid: 11120716-2674-0000-0000-0000028EE6A9
X-Mailman-Approved-At: Mon, 12 Dec 2011 14:39:35 +0000
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, x86@kernel.org,
	Gleb Natapov <gleb@redhat.com>, Peter Zijlstra <peterz@infradead.org>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Xen <xen-devel@lists.xensource.com>,
	Dave Jiang <dave.jiang@intel.com>, KVM <kvm@vger.kernel.org>,
	Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	Ingo Molnar <mingo@redhat.com>, Avi Kivity <avi@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>,
	Sasha Levin <levinsasha928@gmail.com>, Sedat Dilek <sedat.dilek@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>, Yinghai Lu <yinghai@kernel.org>,
	Greg Kroah-Hartman <gregkh@suse.de>, LKML <linux-kernel@vger.kernel.org>,
	Dave Hansen <dave@linux.vnet.ibm.com>,
	Suzuki Poulose <suzuki@linux.vnet.ibm.com>
Subject: Re: [Xen-devel] [PATCH RFC V3 2/4] kvm hypervisor : Add a hypercall
 to KVM hypervisor to support pv-ticketlocks
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 12/07/2011 06:03 PM, Marcelo Tosatti wrote:
> On Wed, Dec 07, 2011 at 05:24:59PM +0530, Raghavendra K T wrote:
>> On 12/07/2011 04:18 PM, Marcelo Tosatti wrote:
>> Yes you are right. It was potentially racy and it was harmful too!.
>> I had observed that it was stalling the CPU before I introduced
>> kicked flag.
>>
>> But now,
>>
>> vcpu->kicked = 1  ==>  kvm_make_request(KVM_REQ_UNHALT, vcpu); ==>
>
> Ok, please use a more descriptive name, such as "pvlock_kicked" or
> something.
>

Yes, pvlock_kicked seems good. 'll use same unless something else
flashes.

>>
>> __vcpu_run() ==>  kvm_check_request(KVM_REQ_UNHALT, vcpu) ==>
>>
>> vcpuN->mp_state = KVM_MP_STATE_RUNNABLE; so eventually we will end up
>> in RUNNABLE.
>>
>> Also Avi pointed that, logically kvm_arch_vcpu_ioctl_set_mpstate should
>> be called only in vcpu thread, so after further debugging, I noticed
>> that,  setting vcpuN->mp_state = KVM_MP_STATE_RUNNABLE; is not
>> necessary.
>> I 'll remove that in the next patch. Thanks for pointing.
>
> In fact you don't need kvm_arch_vcpu_ioctl_set_mpstate either, only the
> new "kicked" flag.
>

True indeed, I meant the same.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 14:39:48 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 14:39:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ra72W-0004Y7-Ph; Mon, 12 Dec 2011 14:39:36 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <mtosatti@redhat.com>) id 1RYGih-0002MO-6q
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 12:35:31 +0000
X-Env-Sender: mtosatti@redhat.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1323261261!51225604!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDYzMzc=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21545 invoked from network); 7 Dec 2011 12:34:22 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-13.tower-27.messagelabs.com with SMTP;
	7 Dec 2011 12:34:22 -0000
Received: from int-mx10.intmail.prod.int.phx2.redhat.com
	(int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id pB7CXwll022301
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 7 Dec 2011 07:33:58 -0500
Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199])
	by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id pB7CXvDK004147; Wed, 7 Dec 2011 07:33:57 -0500
Received: from amt.cnet (vpn-11-217.rdu.redhat.com [10.11.11.217])
	by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id pB7CXtdM022078;
	Wed, 7 Dec 2011 07:33:55 -0500
Received: from amt.cnet (amt.cnet [127.0.0.1])
	by amt.cnet (Postfix) with ESMTP id 7A9A6652179;
	Wed,  7 Dec 2011 10:33:36 -0200 (BRST)
Received: (from marcelo@localhost)
	by amt.cnet (8.14.5/8.14.5/Submit) id pB7CXUCl000393;
	Wed, 7 Dec 2011 10:33:30 -0200
Date: Wed, 7 Dec 2011 10:33:30 -0200
From: Marcelo Tosatti <mtosatti@redhat.com>
To: Raghavendra K T <raghukt@linux.vnet.ibm.com>
Message-ID: <20111207123330.GA32212@amt.cnet>
References: <20111130085921.23386.89708.sendpatchset@oc5400248562.ibm.com>
	<20111130085959.23386.69166.sendpatchset@oc5400248562.ibm.com>
	<20111207104849.GA24849@amt.cnet>
	<4EDF5413.1030107@linux.vnet.ibm.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4EDF5413.1030107@linux.vnet.ibm.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
X-Mailman-Approved-At: Mon, 12 Dec 2011 14:39:35 +0000
Cc: x86@kernel.org, Gleb Natapov <gleb@redhat.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Xen <xen-devel@lists.xensource.com>,
	Dave Jiang <dave.jiang@intel.com>, KVM <kvm@vger.kernel.org>,
	Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	Ingo Molnar <mingo@redhat.com>, Avi Kivity <avi@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>,
	Sasha Levin <levinsasha928@gmail.com>, Sedat Dilek <sedat.dilek@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>, Yinghai Lu <yinghai@kernel.org>,
	Greg Kroah-Hartman <gregkh@suse.de>, LKML <linux-kernel@vger.kernel.org>,
	Dave Hansen <dave@linux.vnet.ibm.com>,
	Suzuki Poulose <suzuki@linux.vnet.ibm.com>
Subject: Re: [Xen-devel] [PATCH RFC V3 2/4] kvm hypervisor : Add a hypercall
 to KVM hypervisor to support pv-ticketlocks
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Dec 07, 2011 at 05:24:59PM +0530, Raghavendra K T wrote:
> On 12/07/2011 04:18 PM, Marcelo Tosatti wrote:
> >On Wed, Nov 30, 2011 at 02:29:59PM +0530, Raghavendra K T wrote:
> >>
> >>+/*
> >>+ * kvm_pv_kick_cpu_op:  Kick a vcpu.
> >>+ *
> >>+ * @cpu - vcpu to be kicked.
> >>+ */
> >>+static void kvm_pv_kick_cpu_op(struct kvm *kvm, int cpu)
> >>+{
> >>+	struct kvm_vcpu *vcpu = kvm_get_vcpu(kvm, cpu);
> >>+	struct kvm_mp_state mp_state;
> >>+
> >>+	mp_state.mp_state = KVM_MP_STATE_RUNNABLE;
> >
> >Since vcpu->mp_state is not protected by a lock, this is potentially racy. For example:
> >
> >CPU0						CPU1
> >kvm_pv_kick_cpu_op				running vcpuN
> >vcpuN->mp_state = KVM_MP_STATE_RUNNABLE;
> >						kvm_emulate_halt
> >						vcpuN->mp_state = KVM_MP_STATE_HALTED
> >
> >Is it harmless to lose a kick?
> >
> 
> Yes you are right. It was potentially racy and it was harmful too!.
> I had observed that it was stalling the CPU before I introduced
> kicked flag.
> 
> But now,
> 
> vcpu->kicked = 1  ==> kvm_make_request(KVM_REQ_UNHALT, vcpu); ==>

Ok, please use a more descriptive name, such as "pvlock_kicked" or
something.

> 
> __vcpu_run() ==> kvm_check_request(KVM_REQ_UNHALT, vcpu) ==>
> 
> vcpuN->mp_state = KVM_MP_STATE_RUNNABLE; so eventually we will end up
> in RUNNABLE.
> 
> Also Avi pointed that, logically kvm_arch_vcpu_ioctl_set_mpstate should
> be called only in vcpu thread, so after further debugging, I noticed
> that,  setting vcpuN->mp_state = KVM_MP_STATE_RUNNABLE; is not
> necessary.
> I 'll remove that in the next patch. Thanks for pointing.

In fact you don't need kvm_arch_vcpu_ioctl_set_mpstate either, only the
new "kicked" flag.

> 
> 
> 			

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 14:39:49 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 14: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.xensource.com>)
	id 1Ra72a-0004a7-88; Mon, 12 Dec 2011 14:39:40 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <dab@hp.com>)
	id 1RYPKB-0001Z9-FI
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 21:46:47 +0000
X-Env-Sender: dab@hp.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1323294358!4487689!1
X-Originating-IP: [15.192.0.46]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTUuMTkyLjAuNDYgPT4gNjQzMDEz\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20904 invoked from network); 7 Dec 2011 21:46:00 -0000
Received: from g5t0009.atlanta.hp.com (HELO g5t0009.atlanta.hp.com)
	(15.192.0.46)
	by server-15.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 7 Dec 2011 21:46:00 -0000
Received: from g5t0029.atlanta.hp.com (g5t0029.atlanta.hp.com [16.228.8.141])
	by g5t0009.atlanta.hp.com (Postfix) with ESMTP id 662DB30189
	for <xen-devel@lists.xensource.com>;
	Wed,  7 Dec 2011 21:45:58 +0000 (UTC)
Received: from [10.10.13.84] (data.cce.hp.com [16.84.84.25])
	by g5t0029.atlanta.hp.com (Postfix) with ESMTP id BE29320240;
	Wed,  7 Dec 2011 21:45:57 +0000 (UTC)
Message-ID: <4EDFDF0D.2020104@hp.com>
Date: Wed, 07 Dec 2011 15:47:57 -0600
From: dbrace <dab@hp.com>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: xen-devel@lists.xensource.com
X-Mailman-Approved-At: Mon, 12 Dec 2011 14:39:35 +0000
Subject: [Xen-devel] kmap_atomic issue with SLES11SP1 32bit XEN driver code
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

kernel: Linux 360 2.6.32.12-0.7-xen #1 SMP 2010-05-20 11:14:20 +0200 
i686 i686 i386 GNU/Linux

I am having issues with some code that uses kmap_atomic(). I am getting:

BUG: unable to handle kernel paging request at 23a1a000 (which is the 
address returned from kmap_atomic().)

The same code works when running on non-XEN 32bit kernels so I am  
wondering why this does not work under
XEN kernels. Is there a different approach that I need to take for 32bit 
XEN kernels?

I really only need to do this code segment if the memory address is a 
high memory address. Is there a MACRO or function
that can help me determine this?

Here is a code snippet:

                 void *linux_vaddr = NULL;       /* kmapped temporary 
virtual address */
                 int linux_page_offset = 0;      /* offset in page */
                 int count = 0;                  /* bytes left to 
transfer */
                 int left = byte_count;          /* number of bytes left 
to transfer */
                 int memcpysize = 0;             /* current size to 
transfer */
                 struct page *linux_page = NULL; /* calculated page */
                 int kmap_flags = 0;

                 linux_page = __pfn_to_page(physical_address >> PAGE_SHIFT);
                 linux_page_offset = (physical_address & 
0x0000000000000FFFULL);
                 memcpysize =  min((PAGE_SIZE - linux_page_offset), left);

                 kmap_flags = KM_USER0;

                 linux_vaddr = kmap_atomic(linux_page, kmap_flags) + 
linux_page_offset;

                 printk("%s: called kmap_atomic, "
                         "calling memcpy linux_vaddr = 0x%x virt_address 
= 0x%x count = 0x%x\n",
                         __func__, linux_vaddr, virt_address, count);
                 /*
                  * Either need to copy to a kmapped destination
                  * or a kmapped source.
                  */
                 if (type == 0) // Write to s/g element, dest virtual 
addr was known.
                         memcpy((void *)virt_address+count, (void 
*)linux_vaddr, memcpysize);
                 else // Source virt. address was known.
                         memcpy((void *)linux_vaddr, (void 
*)virt_address+count, memcpysize);

                 printk("OS_Linux32_Xfer_SG_Page: calling kunmap_atomic, "
                         "calling memcpy linux_vaddr = 0x%lx\n", 
linux_vaddr);

                 kunmap_atomic(linux_vaddr, kmap_flags);


-- 
Don Brace
SPSN Linux Development
Hewlett-Packard Company

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 14:39:49 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 14: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.xensource.com>)
	id 1Ra72Z-0004Zg-Rk; Mon, 12 Dec 2011 14:39:39 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <brace@beardog.cce.hp.com>) id 1RYP2y-0000cd-Jy
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 21:29:00 +0000
X-Env-Sender: brace@beardog.cce.hp.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1323293174!47405406!1
X-Originating-IP: [15.216.28.36]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTUuMjE2LjI4LjM2ID0+IDc4MTc2MA==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3880 invoked from network); 7 Dec 2011 21:26:15 -0000
Received: from g1t0029.austin.hp.com (HELO g1t0029.austin.hp.com)
	(15.216.28.36)
	by server-14.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 7 Dec 2011 21:26:15 -0000
Received: from g1t0038.austin.hp.com (g1t0038.austin.hp.com [16.236.32.44])
	by g1t0029.austin.hp.com (Postfix) with ESMTP id B244B3812A
	for <xen-devel@lists.xensource.com>;
	Wed,  7 Dec 2011 21:28:16 +0000 (UTC)
Received: from beardog.cce.hp.com (beardog.cce.hp.com [16.84.84.24])
	by g1t0038.austin.hp.com (Postfix) with ESMTP id 92DD330042
	for <xen-devel@lists.xensource.com>;
	Wed,  7 Dec 2011 21:28:16 +0000 (UTC)
Received: from beardog.cce.hp.com (beardog.cce.hp.com [127.0.0.1])
	by beardog.cce.hp.com (8.13.8/8.13.8) with ESMTP id pB7LSEF9014722
	for <xen-devel@lists.xensource.com>; Wed, 7 Dec 2011 15:28:14 -0600
Received: (from brace@localhost)
	by beardog.cce.hp.com (8.13.8/8.13.8/Submit) id pB7LSEDf014721
	for xen-devel@lists.xensource.com; Wed, 7 Dec 2011 15:28:14 -0600
Date: Wed, 7 Dec 2011 15:28:14 -0600
From: brace@beardog.cce.hp.com
Message-Id: <201112072128.pB7LSEDf014721@beardog.cce.hp.com>
To: xen-devel@lists.xensource.com
X-Mailman-Approved-At: Mon, 12 Dec 2011 14:39:35 +0000
Subject: [Xen-devel] kmap_atomic issue with SLES11SP1 32bit XEN
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 14:39:49 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 14: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.xensource.com>)
	id 1Ra72X-0004YE-7w; Mon, 12 Dec 2011 14:39:37 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <avi@redhat.com>) id 1RYGv4-0002Vj-S5
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 12:48:19 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1323262051!6453519!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDYzMzc=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12578 invoked from network); 7 Dec 2011 12:47:31 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-11.tower-216.messagelabs.com with SMTP;
	7 Dec 2011 12:47:31 -0000
Received: from int-mx12.intmail.prod.int.phx2.redhat.com
	(int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id pB7ClCjW032375
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 7 Dec 2011 07:47:13 -0500
Received: from balrog.usersys.redhat.com (dhcp-4-24.tlv.redhat.com
	[10.35.4.24])
	by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id pB7Cl6rs022269; Wed, 7 Dec 2011 07:47:06 -0500
Message-ID: <4EDF6049.2030204@redhat.com>
Date: Wed, 07 Dec 2011 14:47:05 +0200
From: Avi Kivity <avi@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:8.0) Gecko/20111115 Thunderbird/8.0
MIME-Version: 1.0
To: Marcelo Tosatti <mtosatti@redhat.com>
References: <20111130085921.23386.89708.sendpatchset@oc5400248562.ibm.com>
	<20111130085959.23386.69166.sendpatchset@oc5400248562.ibm.com>
	<20111207104849.GA24849@amt.cnet>
	<4EDF5413.1030107@linux.vnet.ibm.com>
	<20111207123330.GA32212@amt.cnet>
In-Reply-To: <20111207123330.GA32212@amt.cnet>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.25
X-Mailman-Approved-At: Mon, 12 Dec 2011 14:39:35 +0000
Cc: Raghavendra K T <raghukt@linux.vnet.ibm.com>, x86@kernel.org,
	Gleb Natapov <gleb@redhat.com>, Peter Zijlstra <peterz@infradead.org>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Xen <xen-devel@lists.xensource.com>,
	Dave Jiang <dave.jiang@intel.com>, KVM <kvm@vger.kernel.org>,
	Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	Ingo Molnar <mingo@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>,
	Sasha Levin <levinsasha928@gmail.com>, Sedat Dilek <sedat.dilek@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>, Yinghai Lu <yinghai@kernel.org>,
	Greg Kroah-Hartman <gregkh@suse.de>, LKML <linux-kernel@vger.kernel.org>,
	Dave Hansen <dave@linux.vnet.ibm.com>,
	Suzuki Poulose <suzuki@linux.vnet.ibm.com>
Subject: Re: [Xen-devel] [PATCH RFC V3 2/4] kvm hypervisor : Add a hypercall
 to KVM hypervisor to support pv-ticketlocks
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 12/07/2011 02:33 PM, Marcelo Tosatti wrote:
> > 
> > Also Avi pointed that, logically kvm_arch_vcpu_ioctl_set_mpstate should
> > be called only in vcpu thread, so after further debugging, I noticed
> > that,  setting vcpuN->mp_state = KVM_MP_STATE_RUNNABLE; is not
> > necessary.
> > I 'll remove that in the next patch. Thanks for pointing.
>
> In fact you don't need kvm_arch_vcpu_ioctl_set_mpstate either, only the
> new "kicked" flag.

If we have a kicked flag, it becomes necessary to live migrate it.

Maybe we can change KVM_GET_MP_STATE to fold the kicked flag into the mp
state (converting HALTED into RUNNABLE).

Also I think we can keep the kicked flag in vcpu->requests, no need for
new storage.

-- 
error compiling committee.c: too many arguments to function


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 14:39:50 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 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.xensource.com>)
	id 1Ra72V-0004Xt-VM; Mon, 12 Dec 2011 14:39:35 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <avi@redhat.com>) id 1RYFOy-0007T7-CP
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 11:11:04 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1323256216!4534466!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDYzMzc=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22951 invoked from network); 7 Dec 2011 11:10:16 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-3.tower-174.messagelabs.com with SMTP;
	7 Dec 2011 11:10:16 -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 pB7As1u3001160
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 7 Dec 2011 05:54:01 -0500
Received: from balrog.usersys.redhat.com (dhcp-4-24.tlv.redhat.com
	[10.35.4.24])
	by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id pB7Arsx0028225; Wed, 7 Dec 2011 05:53:55 -0500
Message-ID: <4EDF45C2.9060108@redhat.com>
Date: Wed, 07 Dec 2011 12:53:54 +0200
From: Avi Kivity <avi@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:8.0) Gecko/20111115 Thunderbird/8.0
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
References: <20111130085921.23386.89708.sendpatchset@oc5400248562.ibm.com>
	<20111130085959.23386.69166.sendpatchset@oc5400248562.ibm.com>
	<4ED760F1.6080804@redhat.com> <4ED7DA85.5080504@linux.vnet.ibm.com>
	<4EDBB6C2.9050303@linux.vnet.ibm.com>
	<20111206164947.GA13184@andromeda.dapyr.net>
In-Reply-To: <20111206164947.GA13184@andromeda.dapyr.net>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
X-Mailman-Approved-At: Mon, 12 Dec 2011 14:39:35 +0000
Cc: Raghavendra K T <raghukt@linux.vnet.ibm.com>,
	Marcelo Tosatti <mtosatti@redhat.com>, KVM <kvm@vger.kernel.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Jeremy Fitzhardinge <jeremy@goop.org>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	"H. Peter Anvin" <hpa@zytor.com>, Dave Hansen <dave@linux.vnet.ibm.com>,
	Xen <xen-devel@lists.xensource.com>, Dave Jiang <dave.jiang@intel.com>,
	Gleb Natapov <gleb@redhat.com>, x86@kernel.org,
	Ingo Molnar <mingo@redhat.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>,
	Sasha Levin <levinsasha928@gmail.com>, Sedat Dilek <sedat.dilek@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>, Yinghai Lu <yinghai@kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Greg Kroah-Hartman <gregkh@suse.de>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	LKML <linux-kernel@vger.kernel.org>,
	Suzuki Poulose <suzuki@linux.vnet.ibm.com>
Subject: Re: [Xen-devel] [PATCH RFC V3 2/4] kvm hypervisor : Add a hypercall
 to KVM hypervisor to support pv-ticketlocks
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 12/06/2011 06:49 PM, Konrad Rzeszutek Wilk wrote:
> On Sun, Dec 04, 2011 at 11:36:58PM +0530, Raghavendra K T wrote:
> > On 12/02/2011 01:20 AM, Raghavendra K T wrote:
> > >>Have you tested it on AMD machines? There are some differences in the
> > >>hypercall infrastructure there.
> > >
> > >Yes. 'll test on AMD machine and update on that.
> > >
> > 
> > I tested the code on 64 bit Dual-Core AMD Opteron machine, and it is 
> > working.
>
> I am not that familiar with how KVM does migration, but do you need any
> special flags in QEMU to when migrating a KVM-pv-spinlock enabled guest
> to another machine?

I don't think so.  Sleeping is an ordinary HLT state which we already
migrate.  There are no further states.

-- 
error compiling committee.c: too many arguments to function


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 14:39:50 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 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.xensource.com>)
	id 1Ra72b-0004bU-G6; Mon, 12 Dec 2011 14:39:41 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <avi@redhat.com>) id 1RYaUN-0000kL-Fu
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 09:42:03 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1323337274!4549178!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDYzNjI=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31624 invoked from network); 8 Dec 2011 09:41:15 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-16.tower-174.messagelabs.com with SMTP;
	8 Dec 2011 09:41:15 -0000
Received: from int-mx02.intmail.prod.int.phx2.redhat.com
	(int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id pB89eVP0028644
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 8 Dec 2011 04:40:31 -0500
Received: from balrog.usersys.redhat.com (dhcp-4-24.tlv.redhat.com
	[10.35.4.24])
	by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP
	id pB89eMj7023187; Thu, 8 Dec 2011 04:40:23 -0500
Message-ID: <4EE08606.2060508@redhat.com>
Date: Thu, 08 Dec 2011 11:40:22 +0200
From: Avi Kivity <avi@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:8.0) Gecko/20111115 Thunderbird/8.0
MIME-Version: 1.0
To: Raghavendra K T <raghukt@linux.vnet.ibm.com>
References: <20111130085921.23386.89708.sendpatchset@oc5400248562.ibm.com>
	<20111130085959.23386.69166.sendpatchset@oc5400248562.ibm.com>
	<20111207104849.GA24849@amt.cnet>
	<4EDF5413.1030107@linux.vnet.ibm.com>
	<20111207123330.GA32212@amt.cnet> <4EDF6049.2030204@redhat.com>
	<20111207133947.GA1708@amt.cnet> <4EDF7DC5.5010504@redhat.com>
	<4EDF987B.8040900@linux.vnet.ibm.com>
In-Reply-To: <4EDF987B.8040900@linux.vnet.ibm.com>
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.12
X-Mailman-Approved-At: Mon, 12 Dec 2011 14:39:35 +0000
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, x86@kernel.org,
	Gleb Natapov <gleb@redhat.com>, Peter Zijlstra <peterz@infradead.org>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Xen <xen-devel@lists.xensource.com>,
	Dave Jiang <dave.jiang@intel.com>, KVM <kvm@vger.kernel.org>,
	Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	Ingo Molnar <mingo@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>,
	Sasha Levin <levinsasha928@gmail.com>, Sedat Dilek <sedat.dilek@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>, Yinghai Lu <yinghai@kernel.org>,
	Greg Kroah-Hartman <gregkh@suse.de>, Marcelo Tosatti <mtosatti@redhat.com>,
	LKML <linux-kernel@vger.kernel.org>, Dave Hansen <dave@linux.vnet.ibm.com>,
	Suzuki Poulose <suzuki@linux.vnet.ibm.com>
Subject: Re: [Xen-devel] [PATCH RFC V3 2/4] kvm hypervisor : Add a hypercall
 to KVM hypervisor to support pv-ticketlocks
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 12/07/2011 06:46 PM, Raghavendra K T wrote:
> On 12/07/2011 08:22 PM, Avi Kivity wrote:
>> On 12/07/2011 03:39 PM, Marcelo Tosatti wrote:
>>>> Also I think we can keep the kicked flag in vcpu->requests, no need
>>>> for
>>>> new storage.
>>>
>>> Was going to suggest it but it violates the currently organized
>>> processing of entries at the beginning of vcpu_enter_guest.
>>>
>>> That is, this "kicked" flag is different enough from vcpu->requests
>>> processing that a separate variable seems worthwhile (even more
>>> different with convertion to MP_STATE at KVM_GET_MP_STATE).
>>
>> IMO, it's similar to KVM_REQ_EVENT (which can also cause mpstate to
>> change due to apic re-evaluation).
>>
>
> Ok, So what I understand is we have to either :
> 1. retain current kick flag AS-IS but would have to make it migration
> friendly. [I still have to get more familiar with migration side]
> or
> 2. introduce notion similar to KVM_REQ_PVLOCK_KICK(??) to be part of
> vcpu->requests.
>
> So what would be better? Please let me know.
>

IMO, KVM_REQ.

-- 
error compiling committee.c: too many arguments to function


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 14:39:50 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 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.xensource.com>)
	id 1Ra72Y-0004Yj-H7; Mon, 12 Dec 2011 14:39:38 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raghukt@linux.vnet.ibm.com>) id 1RYKQM-0000mJ-Ln
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 16:32:50 +0000
X-Env-Sender: raghukt@linux.vnet.ibm.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1323275519!7198072!1
X-Originating-IP: [122.248.162.9]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTIyLjI0OC4xNjIuOSA9PiA5NDQ1OA==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5674 invoked from network); 7 Dec 2011 16:32:03 -0000
Received: from e28smtp09.in.ibm.com (HELO e28smtp09.in.ibm.com) (122.248.162.9)
	by server-12.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 7 Dec 2011 16:32:03 -0000
Received: from /spool/local
	by e28smtp09.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use
	Only! Violators will be prosecuted
	for <xen-devel@lists.xensource.com> from <raghukt@linux.vnet.ibm.com>; 
	Wed, 7 Dec 2011 22:01:58 +0530
Received: from d28relay03.in.ibm.com (9.184.220.60)
	by e28smtp09.in.ibm.com (192.168.1.139) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Wed, 7 Dec 2011 22:01:53 +0530
Received: from d28av04.in.ibm.com (d28av04.in.ibm.com [9.184.220.66])
	by d28relay03.in.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	pB7GVpGM2109590
	for <xen-devel@lists.xensource.com>; Wed, 7 Dec 2011 22:01:52 +0530
Received: from d28av04.in.ibm.com (loopback [127.0.0.1])
	by d28av04.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id
	pB7GVnCl023412
	for <xen-devel@lists.xensource.com>; Thu, 8 Dec 2011 03:31:51 +1100
Received: from oc5400248562.ibm.com ([9.77.196.131])
	by d28av04.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	pB7GVk0s023266; Thu, 8 Dec 2011 03:31:46 +1100
Message-ID: <4EDF94F0.2080201@linux.vnet.ibm.com>
Date: Wed, 07 Dec 2011 22:01:44 +0530
From: Raghavendra K T <raghukt@linux.vnet.ibm.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
	rv:1.9.2.24) Gecko/20111108 Fedora/3.1.16-1.fc14 Thunderbird/3.1.16
MIME-Version: 1.0
To: Marcelo Tosatti <mtosatti@redhat.com>
References: <20111130085921.23386.89708.sendpatchset@oc5400248562.ibm.com>
	<20111130085959.23386.69166.sendpatchset@oc5400248562.ibm.com>
	<20111207104849.GA24849@amt.cnet>
	<4EDF5413.1030107@linux.vnet.ibm.com>
	<20111207123330.GA32212@amt.cnet>
In-Reply-To: <20111207123330.GA32212@amt.cnet>
x-cbid: 11120716-2674-0000-0000-0000028EE6A9
X-Mailman-Approved-At: Mon, 12 Dec 2011 14:39:35 +0000
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, x86@kernel.org,
	Gleb Natapov <gleb@redhat.com>, Peter Zijlstra <peterz@infradead.org>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Xen <xen-devel@lists.xensource.com>,
	Dave Jiang <dave.jiang@intel.com>, KVM <kvm@vger.kernel.org>,
	Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	Ingo Molnar <mingo@redhat.com>, Avi Kivity <avi@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>,
	Sasha Levin <levinsasha928@gmail.com>, Sedat Dilek <sedat.dilek@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>, Yinghai Lu <yinghai@kernel.org>,
	Greg Kroah-Hartman <gregkh@suse.de>, LKML <linux-kernel@vger.kernel.org>,
	Dave Hansen <dave@linux.vnet.ibm.com>,
	Suzuki Poulose <suzuki@linux.vnet.ibm.com>
Subject: Re: [Xen-devel] [PATCH RFC V3 2/4] kvm hypervisor : Add a hypercall
 to KVM hypervisor to support pv-ticketlocks
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 12/07/2011 06:03 PM, Marcelo Tosatti wrote:
> On Wed, Dec 07, 2011 at 05:24:59PM +0530, Raghavendra K T wrote:
>> On 12/07/2011 04:18 PM, Marcelo Tosatti wrote:
>> Yes you are right. It was potentially racy and it was harmful too!.
>> I had observed that it was stalling the CPU before I introduced
>> kicked flag.
>>
>> But now,
>>
>> vcpu->kicked = 1  ==>  kvm_make_request(KVM_REQ_UNHALT, vcpu); ==>
>
> Ok, please use a more descriptive name, such as "pvlock_kicked" or
> something.
>

Yes, pvlock_kicked seems good. 'll use same unless something else
flashes.

>>
>> __vcpu_run() ==>  kvm_check_request(KVM_REQ_UNHALT, vcpu) ==>
>>
>> vcpuN->mp_state = KVM_MP_STATE_RUNNABLE; so eventually we will end up
>> in RUNNABLE.
>>
>> Also Avi pointed that, logically kvm_arch_vcpu_ioctl_set_mpstate should
>> be called only in vcpu thread, so after further debugging, I noticed
>> that,  setting vcpuN->mp_state = KVM_MP_STATE_RUNNABLE; is not
>> necessary.
>> I 'll remove that in the next patch. Thanks for pointing.
>
> In fact you don't need kvm_arch_vcpu_ioctl_set_mpstate either, only the
> new "kicked" flag.
>

True indeed, I meant the same.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 14:39:50 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 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.xensource.com>)
	id 1Ra72b-0004bs-U5; Mon, 12 Dec 2011 14:39:41 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raghukt@linux.vnet.ibm.com>) id 1RYhtM-00035H-Bb
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 17:36:20 +0000
X-Env-Sender: raghukt@linux.vnet.ibm.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1323365715!48776151!1
X-Originating-IP: [202.81.31.148]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjAyLjgxLjMxLjE0OCA9PiAyMTAyMDc=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23523 invoked from network); 8 Dec 2011 17:35:18 -0000
Received: from e23smtp06.au.ibm.com (HELO e23smtp06.au.ibm.com) (202.81.31.148)
	by server-11.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 8 Dec 2011 17:35:18 -0000
Received: from /spool/local
	by e23smtp06.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use
	Only! Violators will be prosecuted
	for <xen-devel@lists.xensource.com> from <raghukt@linux.vnet.ibm.com>; 
	Thu, 8 Dec 2011 17:33:11 +1000
Received: from d23relay04.au.ibm.com ([202.81.31.246])
	by e23smtp06.au.ibm.com ([202.81.31.212]) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Thu, 8 Dec 2011 17:33:10 +1000
Received: from d23av02.au.ibm.com (d23av02.au.ibm.com [9.190.235.138])
	by d23relay04.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	pB8HVfMl3465430
	for <xen-devel@lists.xensource.com>; Fri, 9 Dec 2011 04:31:44 +1100
Received: from d23av02.au.ibm.com (loopback [127.0.0.1])
	by d23av02.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id
	pB8HZHv9019302
	for <xen-devel@lists.xensource.com>; Fri, 9 Dec 2011 04:35:18 +1100
Received: from oc5400248562.ibm.com ([9.79.214.252])
	by d23av02.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	pB8HZ65E019178; Fri, 9 Dec 2011 04:35:07 +1100
Message-ID: <4EE0F548.8050006@linux.vnet.ibm.com>
Date: Thu, 08 Dec 2011 23:05:04 +0530
From: Raghavendra K T <raghukt@linux.vnet.ibm.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
	rv:1.9.2.24) Gecko/20111108 Fedora/3.1.16-1.fc14 Thunderbird/3.1.16
MIME-Version: 1.0
To: Raghavendra K T <raghukt@linux.vnet.ibm.com>
References: <20111130085921.23386.89708.sendpatchset@oc5400248562.ibm.com>
	<20111130085959.23386.69166.sendpatchset@oc5400248562.ibm.com>
	<4ED760F1.6080804@redhat.com> <4ED7DA85.5080504@linux.vnet.ibm.com>
In-Reply-To: <4ED7DA85.5080504@linux.vnet.ibm.com>
x-cbid: 11120807-7014-0000-0000-0000003B2CC7
X-Mailman-Approved-At: Mon, 12 Dec 2011 14:39:35 +0000
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, x86@kernel.org,
	Gleb Natapov <gleb@redhat.com>, Peter Zijlstra <peterz@infradead.org>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Xen <xen-devel@lists.xensource.com>,
	Dave Jiang <dave.jiang@intel.com>, KVM <kvm@vger.kernel.org>,
	Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	Ingo Molnar <mingo@redhat.com>, Avi Kivity <avi@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Marcelo Tosatti <mtosatti@redhat.com>,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>,
	Sasha Levin <levinsasha928@gmail.com>, Sedat Dilek <sedat.dilek@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>, Yinghai Lu <yinghai@kernel.org>,
	Greg Kroah-Hartman <gregkh@suse.de>, LKML <linux-kernel@vger.kernel.org>,
	Dave Hansen <dave@linux.vnet.ibm.com>,
	Suzuki Poulose <suzuki@linux.vnet.ibm.com>
Subject: Re: [Xen-devel] [PATCH RFC V3 2/4] kvm hypervisor : Add a hypercall
 to KVM hypervisor to support pv-ticketlocks
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 12/02/2011 01:20 AM, Raghavendra K T wrote:
>>>
>>> +/*
>>> + * kvm_pv_kick_cpu_op: Kick a vcpu.
>>> + *
>>> + * @cpu - vcpu to be kicked.
>>> + */
>>> +static void kvm_pv_kick_cpu_op(struct kvm *kvm, int cpu)
>>> +{
>>> + struct kvm_vcpu *vcpu = kvm_get_vcpu(kvm, cpu);
>>
>> There is no guarantee that guest cpu numbers match host vcpu numbers.
>> Use APIC IDs, and kvm_apic_match_dest().
>
> Okay. I have to dig more on this.
>
Sorry for late reply on this, was experimenting with the changes needed.

Wanted to confirm if it is according to your expectation.

  Host side change should look like this to get vcpu,

	int i;
	struct kvm_vcpu *vcpu = NULL;

	kvm_for_each_vcpu(i, vcpu, kvm) {
		if (!kvm_apic_present(vcpu))
		continue;

		if (kvm_apic_match_dest(vcpu, 0, 0, cpu, 0)) {
		break;
		}
	}


In guest side, convert the cpu to apicid using,

apicid = apic->cpu_present_to_apicid(cpu);
OR
apicid =  per_cpu(x86_cpu_to_apicid, cpu);

But I have a question, as you know, we are storing the waiting cpus in
cpumask, to track the cpu to be kicked.

You want to change the logic to store the apicid directly instead of
cpu during contention or is it OK to convert before kick hypercall?.

Probably it would be more good if I can get to know the scenario,
where guest cpu numbers does not match host vcpu numbers. It may answer 
the whole question and help me in testing/validating the code.

Thanks
- Raghu








_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 14:39:49 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 14: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.xensource.com>)
	id 1Ra72b-0004ax-1E; Mon, 12 Dec 2011 14:39:41 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <dab@hp.com>)
	id 1RYPTF-0001an-5q
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 21:56:09 +0000
X-Env-Sender: dab@hp.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1323294888!51541055!1
X-Originating-IP: [15.216.28.33]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTUuMjE2LjI4LjMzID0+IDc1NTQ2OQ==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16281 invoked from network); 7 Dec 2011 21:54:49 -0000
Received: from g1t0026.austin.hp.com (HELO g1t0026.austin.hp.com)
	(15.216.28.33)
	by server-4.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 7 Dec 2011 21:54:49 -0000
Received: from g1t0039.austin.hp.com (g1t0039.austin.hp.com [16.236.32.45])
	by g1t0026.austin.hp.com (Postfix) with ESMTP id 69AE1C0B8
	for <xen-devel@lists.xensource.com>;
	Wed,  7 Dec 2011 21:55:20 +0000 (UTC)
Received: from [10.10.13.84] (data.cce.hp.com [16.84.84.25])
	by g1t0039.austin.hp.com (Postfix) with ESMTP id 540E034068;
	Wed,  7 Dec 2011 21:55:20 +0000 (UTC)
Message-ID: <4EDFE140.7040600@hp.com>
Date: Wed, 07 Dec 2011 15:57:20 -0600
From: dbrace <dab@hp.com>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: scameron@beardog.cce.hp.com
References: <4EDFDF0D.2020104@hp.com>
	<20111207215219.GH6635@beardog.cce.hp.com>
In-Reply-To: <20111207215219.GH6635@beardog.cce.hp.com>
X-Mailman-Approved-At: Mon, 12 Dec 2011 14:39:35 +0000
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] kmap_atomic issue with SLES11SP1 32bit XEN driver
	code
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Yes

On 12/07/2011 03:52 PM, scameron@beardog.cce.hp.com wrote:
> On Wed, Dec 07, 2011 at 03:47:57PM -0600, dbrace wrote:
>> kernel: Linux 360 2.6.32.12-0.7-xen #1 SMP 2010-05-20 11:14:20 +0200
>> i686 i686 i386 GNU/Linux
>>
>> I am having issues with some code that uses kmap_atomic(). I am getting:
>>
>> BUG: unable to handle kernel paging request at 23a1a000 (which is the
>> address returned from kmap_atomic().)
>>
>> The same code works when running on non-XEN 32bit kernels so I am
>> wondering why this does not work under
>> XEN kernels. Is there a different approach that I need to take for 32bit
>> XEN kernels?
>>
>> I really only need to do this code segment if the memory address is a
>> high memory address. Is there a MACRO or function
>> that can help me determine this?
>>
>> Here is a code snippet:
>>
>>                  void *linux_vaddr = NULL;       /* kmapped temporary
>> virtual address */
>>                  int linux_page_offset = 0;      /* offset in page */
>>                  int count = 0;                  /* bytes left to
>> transfer */
>>                  int left = byte_count;          /* number of bytes left
>> to transfer */
>>                  int memcpysize = 0;             /* current size to
>> transfer */
>>                  struct page *linux_page = NULL; /* calculated page */
>>                  int kmap_flags = 0;
>>
>>                  linux_page = __pfn_to_page(physical_address>>  PAGE_SHIFT);
>>                  linux_page_offset = (physical_address&
>> 0x0000000000000FFFULL);
>>                  memcpysize =  min((PAGE_SIZE - linux_page_offset), left);
>>
>>                  kmap_flags = KM_USER0;
>>
>>                  linux_vaddr = kmap_atomic(linux_page, kmap_flags) +
>> linux_page_offset;
>>
>>                  printk("%s: called kmap_atomic, "
>>                          "calling memcpy linux_vaddr = 0x%x virt_address
>> = 0x%x count = 0x%x\n",
>>                          __func__, linux_vaddr, virt_address, count);
>>                  /*
>>                   * Either need to copy to a kmapped destination
>>                   * or a kmapped source.
>>                   */
>>                  if (type == 0) // Write to s/g element, dest virtual
>> addr was known.
>>                          memcpy((void *)virt_address+count, (void
>> *)linux_vaddr, memcpysize);
>>                  else // Source virt. address was known.
>>                          memcpy((void *)linux_vaddr, (void
>> *)virt_address+count, memcpysize);
> Just to be clear, it's these memcpy's that get the BUG, correct?
>
> -- steve
>
>
>>                  printk("OS_Linux32_Xfer_SG_Page: calling kunmap_atomic, "
>>                          "calling memcpy linux_vaddr = 0x%lx\n",
>> linux_vaddr);
>>
>>                  kunmap_atomic(linux_vaddr, kmap_flags);
>>
>>
>> -- 
>> Don Brace
>> SPSN Linux Development
>> Hewlett-Packard Company

-- 
Don Brace
SPSN Linux Development
Hewlett-Packard Company

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 14:39:49 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 14: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.xensource.com>)
	id 1Ra72c-0004cB-AX; Mon, 12 Dec 2011 14:39:42 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raghukt@linux.vnet.ibm.com>) id 1RYyBc-0007H0-Ka
	for xen-devel@lists.xensource.com; Fri, 09 Dec 2011 11:00:16 +0000
X-Env-Sender: raghukt@linux.vnet.ibm.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1323428242!47620017!1
X-Originating-IP: [202.81.31.141]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjAyLjgxLjMxLjE0MSA9PiA2Mjg4Mg==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31363 invoked from network); 9 Dec 2011 10:57:25 -0000
Received: from e23smtp08.au.ibm.com (HELO e23smtp08.au.ibm.com) (202.81.31.141)
	by server-14.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 9 Dec 2011 10:57:25 -0000
Received: from /spool/local
	by e23smtp08.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use
	Only! Violators will be prosecuted
	for <xen-devel@lists.xensource.com> from <raghukt@linux.vnet.ibm.com>; 
	Fri, 9 Dec 2011 10:57:39 +1000
Received: from d23relay05.au.ibm.com ([202.81.31.247])
	by e23smtp08.au.ibm.com ([202.81.31.205]) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Fri, 9 Dec 2011 10:57:37 +1000
Received: from d23av04.au.ibm.com (d23av04.au.ibm.com [9.190.235.139])
	by d23relay05.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	pB9AtYbU2789612
	for <xen-devel@lists.xensource.com>; Fri, 9 Dec 2011 21:55:35 +1100
Received: from d23av04.au.ibm.com (loopback [127.0.0.1])
	by d23av04.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id
	pB9AxDjW023483
	for <xen-devel@lists.xensource.com>; Fri, 9 Dec 2011 21:59:15 +1100
Received: from oc5400248562.ibm.com (oc5400248562.in.ibm.com [9.124.35.237])
	by d23av04.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	pB9Ax8mR023408; Fri, 9 Dec 2011 21:59:09 +1100
Message-ID: <4EE1E9FA.5030307@linux.vnet.ibm.com>
Date: Fri, 09 Dec 2011 16:29:06 +0530
From: Raghavendra K T <raghukt@linux.vnet.ibm.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
	rv:1.9.2.24) Gecko/20111108 Fedora/3.1.16-1.fc14 Thunderbird/3.1.16
MIME-Version: 1.0
To: Avi Kivity <avi@redhat.com>
References: <20111130085921.23386.89708.sendpatchset@oc5400248562.ibm.com>
	<20111130085959.23386.69166.sendpatchset@oc5400248562.ibm.com>
	<20111207104849.GA24849@amt.cnet>
	<4EDF5413.1030107@linux.vnet.ibm.com>
	<20111207123330.GA32212@amt.cnet> <4EDF6049.2030204@redhat.com>
	<20111207133947.GA1708@amt.cnet> <4EDF7DC5.5010504@redhat.com>
	<4EDF987B.8040900@linux.vnet.ibm.com> <4EE08606.2060508@redhat.com>
In-Reply-To: <4EE08606.2060508@redhat.com>
x-cbid: 11120900-5140-0000-0000-00000065E133
X-Mailman-Approved-At: Mon, 12 Dec 2011 14:39:35 +0000
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, x86@kernel.org,
	Gleb Natapov <gleb@redhat.com>, Peter Zijlstra <peterz@infradead.org>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Xen <xen-devel@lists.xensource.com>,
	Dave Jiang <dave.jiang@intel.com>, KVM <kvm@vger.kernel.org>,
	Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	Ingo Molnar <mingo@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>,
	Sasha Levin <levinsasha928@gmail.com>, Sedat Dilek <sedat.dilek@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>, Yinghai Lu <yinghai@kernel.org>,
	Greg Kroah-Hartman <gregkh@suse.de>, Marcelo Tosatti <mtosatti@redhat.com>,
	LKML <linux-kernel@vger.kernel.org>, Dave Hansen <dave@linux.vnet.ibm.com>,
	Suzuki Poulose <suzuki@linux.vnet.ibm.com>
Subject: Re: [Xen-devel] [PATCH RFC V3 2/4] kvm hypervisor : Add a hypercall
 to KVM hypervisor to support pv-ticketlocks
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 12/08/2011 03:10 PM, Avi Kivity wrote:
> On 12/07/2011 06:46 PM, Raghavendra K T wrote:
>> On 12/07/2011 08:22 PM, Avi Kivity wrote:
>>> On 12/07/2011 03:39 PM, Marcelo Tosatti wrote:
>>>>> Also I think we can keep the kicked flag in vcpu->requests, no need
>>>>> for
>>>>> new storage.
>>>>
>>>> Was going to suggest it but it violates the currently organized
>>>> processing of entries at the beginning of vcpu_enter_guest.
>>>>
>>>> That is, this "kicked" flag is different enough from vcpu->requests
>>>> processing that a separate variable seems worthwhile (even more
>>>> different with convertion to MP_STATE at KVM_GET_MP_STATE).
>>>
>>> IMO, it's similar to KVM_REQ_EVENT (which can also cause mpstate to
>>> change due to apic re-evaluation).
>>>
>>
>> Ok, So what I understand is we have to either :
>> 1. retain current kick flag AS-IS but would have to make it migration
>> friendly. [I still have to get more familiar with migration side]
>> or
>> 2. introduce notion similar to KVM_REQ_PVLOCK_KICK(??) to be part of
>> vcpu->requests.
>>
>> So what would be better? Please let me know.
>>
>
> IMO, KVM_REQ.
>

Ok, 'll continue in this direction. Hmm I think now the race condition 
should be kept in mind, pointed by Marcello.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 14:39:50 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 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.xensource.com>)
	id 1Ra72V-0004Xt-VM; Mon, 12 Dec 2011 14:39:35 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <avi@redhat.com>) id 1RYFOy-0007T7-CP
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 11:11:04 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1323256216!4534466!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDYzMzc=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22951 invoked from network); 7 Dec 2011 11:10:16 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-3.tower-174.messagelabs.com with SMTP;
	7 Dec 2011 11:10:16 -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 pB7As1u3001160
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 7 Dec 2011 05:54:01 -0500
Received: from balrog.usersys.redhat.com (dhcp-4-24.tlv.redhat.com
	[10.35.4.24])
	by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id pB7Arsx0028225; Wed, 7 Dec 2011 05:53:55 -0500
Message-ID: <4EDF45C2.9060108@redhat.com>
Date: Wed, 07 Dec 2011 12:53:54 +0200
From: Avi Kivity <avi@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:8.0) Gecko/20111115 Thunderbird/8.0
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
References: <20111130085921.23386.89708.sendpatchset@oc5400248562.ibm.com>
	<20111130085959.23386.69166.sendpatchset@oc5400248562.ibm.com>
	<4ED760F1.6080804@redhat.com> <4ED7DA85.5080504@linux.vnet.ibm.com>
	<4EDBB6C2.9050303@linux.vnet.ibm.com>
	<20111206164947.GA13184@andromeda.dapyr.net>
In-Reply-To: <20111206164947.GA13184@andromeda.dapyr.net>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
X-Mailman-Approved-At: Mon, 12 Dec 2011 14:39:35 +0000
Cc: Raghavendra K T <raghukt@linux.vnet.ibm.com>,
	Marcelo Tosatti <mtosatti@redhat.com>, KVM <kvm@vger.kernel.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Jeremy Fitzhardinge <jeremy@goop.org>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	"H. Peter Anvin" <hpa@zytor.com>, Dave Hansen <dave@linux.vnet.ibm.com>,
	Xen <xen-devel@lists.xensource.com>, Dave Jiang <dave.jiang@intel.com>,
	Gleb Natapov <gleb@redhat.com>, x86@kernel.org,
	Ingo Molnar <mingo@redhat.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>,
	Sasha Levin <levinsasha928@gmail.com>, Sedat Dilek <sedat.dilek@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>, Yinghai Lu <yinghai@kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Greg Kroah-Hartman <gregkh@suse.de>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	LKML <linux-kernel@vger.kernel.org>,
	Suzuki Poulose <suzuki@linux.vnet.ibm.com>
Subject: Re: [Xen-devel] [PATCH RFC V3 2/4] kvm hypervisor : Add a hypercall
 to KVM hypervisor to support pv-ticketlocks
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 12/06/2011 06:49 PM, Konrad Rzeszutek Wilk wrote:
> On Sun, Dec 04, 2011 at 11:36:58PM +0530, Raghavendra K T wrote:
> > On 12/02/2011 01:20 AM, Raghavendra K T wrote:
> > >>Have you tested it on AMD machines? There are some differences in the
> > >>hypercall infrastructure there.
> > >
> > >Yes. 'll test on AMD machine and update on that.
> > >
> > 
> > I tested the code on 64 bit Dual-Core AMD Opteron machine, and it is 
> > working.
>
> I am not that familiar with how KVM does migration, but do you need any
> special flags in QEMU to when migrating a KVM-pv-spinlock enabled guest
> to another machine?

I don't think so.  Sleeping is an ordinary HLT state which we already
migrate.  There are no further states.

-- 
error compiling committee.c: too many arguments to function


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 14:39:50 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 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.xensource.com>)
	id 1Ra72b-0004bU-G6; Mon, 12 Dec 2011 14:39:41 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <avi@redhat.com>) id 1RYaUN-0000kL-Fu
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 09:42:03 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1323337274!4549178!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDYzNjI=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31624 invoked from network); 8 Dec 2011 09:41:15 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-16.tower-174.messagelabs.com with SMTP;
	8 Dec 2011 09:41:15 -0000
Received: from int-mx02.intmail.prod.int.phx2.redhat.com
	(int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id pB89eVP0028644
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 8 Dec 2011 04:40:31 -0500
Received: from balrog.usersys.redhat.com (dhcp-4-24.tlv.redhat.com
	[10.35.4.24])
	by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP
	id pB89eMj7023187; Thu, 8 Dec 2011 04:40:23 -0500
Message-ID: <4EE08606.2060508@redhat.com>
Date: Thu, 08 Dec 2011 11:40:22 +0200
From: Avi Kivity <avi@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:8.0) Gecko/20111115 Thunderbird/8.0
MIME-Version: 1.0
To: Raghavendra K T <raghukt@linux.vnet.ibm.com>
References: <20111130085921.23386.89708.sendpatchset@oc5400248562.ibm.com>
	<20111130085959.23386.69166.sendpatchset@oc5400248562.ibm.com>
	<20111207104849.GA24849@amt.cnet>
	<4EDF5413.1030107@linux.vnet.ibm.com>
	<20111207123330.GA32212@amt.cnet> <4EDF6049.2030204@redhat.com>
	<20111207133947.GA1708@amt.cnet> <4EDF7DC5.5010504@redhat.com>
	<4EDF987B.8040900@linux.vnet.ibm.com>
In-Reply-To: <4EDF987B.8040900@linux.vnet.ibm.com>
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.12
X-Mailman-Approved-At: Mon, 12 Dec 2011 14:39:35 +0000
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, x86@kernel.org,
	Gleb Natapov <gleb@redhat.com>, Peter Zijlstra <peterz@infradead.org>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Xen <xen-devel@lists.xensource.com>,
	Dave Jiang <dave.jiang@intel.com>, KVM <kvm@vger.kernel.org>,
	Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	Ingo Molnar <mingo@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>,
	Sasha Levin <levinsasha928@gmail.com>, Sedat Dilek <sedat.dilek@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>, Yinghai Lu <yinghai@kernel.org>,
	Greg Kroah-Hartman <gregkh@suse.de>, Marcelo Tosatti <mtosatti@redhat.com>,
	LKML <linux-kernel@vger.kernel.org>, Dave Hansen <dave@linux.vnet.ibm.com>,
	Suzuki Poulose <suzuki@linux.vnet.ibm.com>
Subject: Re: [Xen-devel] [PATCH RFC V3 2/4] kvm hypervisor : Add a hypercall
 to KVM hypervisor to support pv-ticketlocks
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 12/07/2011 06:46 PM, Raghavendra K T wrote:
> On 12/07/2011 08:22 PM, Avi Kivity wrote:
>> On 12/07/2011 03:39 PM, Marcelo Tosatti wrote:
>>>> Also I think we can keep the kicked flag in vcpu->requests, no need
>>>> for
>>>> new storage.
>>>
>>> Was going to suggest it but it violates the currently organized
>>> processing of entries at the beginning of vcpu_enter_guest.
>>>
>>> That is, this "kicked" flag is different enough from vcpu->requests
>>> processing that a separate variable seems worthwhile (even more
>>> different with convertion to MP_STATE at KVM_GET_MP_STATE).
>>
>> IMO, it's similar to KVM_REQ_EVENT (which can also cause mpstate to
>> change due to apic re-evaluation).
>>
>
> Ok, So what I understand is we have to either :
> 1. retain current kick flag AS-IS but would have to make it migration
> friendly. [I still have to get more familiar with migration side]
> or
> 2. introduce notion similar to KVM_REQ_PVLOCK_KICK(??) to be part of
> vcpu->requests.
>
> So what would be better? Please let me know.
>

IMO, KVM_REQ.

-- 
error compiling committee.c: too many arguments to function


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 14:39:50 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 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.xensource.com>)
	id 1Ra72Y-0004YZ-2l; Mon, 12 Dec 2011 14:39:38 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <avi@redhat.com>) id 1RYIsr-0006xA-K4
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 14:54:09 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1323269601!4635479!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDYzMzc=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 654 invoked from network); 7 Dec 2011 14:53:22 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-5.tower-174.messagelabs.com with SMTP;
	7 Dec 2011 14:53: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 pB7Er1Fk014271
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 7 Dec 2011 09:53:01 -0500
Received: from balrog.usersys.redhat.com (dhcp-4-24.tlv.redhat.com
	[10.35.4.24])
	by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id pB7EqsYZ015445; Wed, 7 Dec 2011 09:52:54 -0500
Message-ID: <4EDF7DC5.5010504@redhat.com>
Date: Wed, 07 Dec 2011 16:52:53 +0200
From: Avi Kivity <avi@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:8.0) Gecko/20111115 Thunderbird/8.0
MIME-Version: 1.0
To: Marcelo Tosatti <mtosatti@redhat.com>
References: <20111130085921.23386.89708.sendpatchset@oc5400248562.ibm.com>
	<20111130085959.23386.69166.sendpatchset@oc5400248562.ibm.com>
	<20111207104849.GA24849@amt.cnet>
	<4EDF5413.1030107@linux.vnet.ibm.com>
	<20111207123330.GA32212@amt.cnet> <4EDF6049.2030204@redhat.com>
	<20111207133947.GA1708@amt.cnet>
In-Reply-To: <20111207133947.GA1708@amt.cnet>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
X-Mailman-Approved-At: Mon, 12 Dec 2011 14:39:35 +0000
Cc: Raghavendra K T <raghukt@linux.vnet.ibm.com>, x86@kernel.org,
	Gleb Natapov <gleb@redhat.com>, Peter Zijlstra <peterz@infradead.org>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Xen <xen-devel@lists.xensource.com>,
	Dave Jiang <dave.jiang@intel.com>, KVM <kvm@vger.kernel.org>,
	Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	Ingo Molnar <mingo@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>,
	Sasha Levin <levinsasha928@gmail.com>, Sedat Dilek <sedat.dilek@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>, Yinghai Lu <yinghai@kernel.org>,
	Greg Kroah-Hartman <gregkh@suse.de>, LKML <linux-kernel@vger.kernel.org>,
	Dave Hansen <dave@linux.vnet.ibm.com>,
	Suzuki Poulose <suzuki@linux.vnet.ibm.com>
Subject: Re: [Xen-devel] [PATCH RFC V3 2/4] kvm hypervisor : Add a hypercall
 to KVM hypervisor to support pv-ticketlocks
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 12/07/2011 03:39 PM, Marcelo Tosatti wrote:
> > Also I think we can keep the kicked flag in vcpu->requests, no need for
> > new storage.
>
> Was going to suggest it but it violates the currently organized
> processing of entries at the beginning of vcpu_enter_guest.
>
> That is, this "kicked" flag is different enough from vcpu->requests
> processing that a separate variable seems worthwhile (even more
> different with convertion to MP_STATE at KVM_GET_MP_STATE).

IMO, it's similar to KVM_REQ_EVENT (which can also cause mpstate to
change due to apic re-evaluation).

-- 
error compiling committee.c: too many arguments to function


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 14:39:50 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 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.xensource.com>)
	id 1Ra72W-0004Y0-Cq; Mon, 12 Dec 2011 14:39:36 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raghukt@linux.vnet.ibm.com>) id 1RYG7B-0001v9-7A
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 11:56:45 +0000
X-Env-Sender: raghukt@linux.vnet.ibm.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1323258939!57979011!1
X-Originating-IP: [202.81.31.145]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjAyLjgxLjMxLjE0NSA9PiAxOTYwNjU=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32595 invoked from network); 7 Dec 2011 11:55:43 -0000
Received: from e23smtp03.au.ibm.com (HELO e23smtp03.au.ibm.com) (202.81.31.145)
	by server-15.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 7 Dec 2011 11:55:43 -0000
Received: from /spool/local
	by e23smtp03.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use
	Only! Violators will be prosecuted
	for <xen-devel@lists.xensource.com> from <raghukt@linux.vnet.ibm.com>; 
	Wed, 7 Dec 2011 11:50:19 +1000
Received: from d23relay03.au.ibm.com ([202.81.31.245])
	by e23smtp03.au.ibm.com ([202.81.31.209]) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Wed, 7 Dec 2011 11:49:38 +1000
Received: from d23av01.au.ibm.com (d23av01.au.ibm.com [9.190.234.96])
	by d23relay03.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	pB7Bt89g4993262
	for <xen-devel@lists.xensource.com>; Wed, 7 Dec 2011 22:55:08 +1100
Received: from d23av01.au.ibm.com (loopback [127.0.0.1])
	by d23av01.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id
	pB7Bt6wF030864
	for <xen-devel@lists.xensource.com>; Wed, 7 Dec 2011 22:55:07 +1100
Received: from oc5400248562.ibm.com (oc5400248562.in.ibm.com [9.124.158.57])
	by d23av01.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	pB7Bt2DL030769; Wed, 7 Dec 2011 22:55:02 +1100
Message-ID: <4EDF5413.1030107@linux.vnet.ibm.com>
Date: Wed, 07 Dec 2011 17:24:59 +0530
From: Raghavendra K T <raghukt@linux.vnet.ibm.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
	rv:1.9.2.24) Gecko/20111108 Fedora/3.1.16-1.fc14 Thunderbird/3.1.16
MIME-Version: 1.0
To: Marcelo Tosatti <mtosatti@redhat.com>
References: <20111130085921.23386.89708.sendpatchset@oc5400248562.ibm.com>
	<20111130085959.23386.69166.sendpatchset@oc5400248562.ibm.com>
	<20111207104849.GA24849@amt.cnet>
In-Reply-To: <20111207104849.GA24849@amt.cnet>
x-cbid: 11120701-6102-0000-0000-0000005A078F
X-Mailman-Approved-At: Mon, 12 Dec 2011 14:39:35 +0000
Cc: x86@kernel.org, Gleb Natapov <gleb@redhat.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Xen <xen-devel@lists.xensource.com>,
	Dave Jiang <dave.jiang@intel.com>, KVM <kvm@vger.kernel.org>,
	Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	Ingo Molnar <mingo@redhat.com>, Avi Kivity <avi@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>,
	Sasha Levin <levinsasha928@gmail.com>, Sedat Dilek <sedat.dilek@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>, Yinghai Lu <yinghai@kernel.org>,
	Greg Kroah-Hartman <gregkh@suse.de>, LKML <linux-kernel@vger.kernel.org>,
	Dave Hansen <dave@linux.vnet.ibm.com>,
	Suzuki Poulose <suzuki@linux.vnet.ibm.com>
Subject: Re: [Xen-devel] [PATCH RFC V3 2/4] kvm hypervisor : Add a hypercall
 to KVM hypervisor to support pv-ticketlocks
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 12/07/2011 04:18 PM, Marcelo Tosatti wrote:
> On Wed, Nov 30, 2011 at 02:29:59PM +0530, Raghavendra K T wrote:
>>
>> +/*
>> + * kvm_pv_kick_cpu_op:  Kick a vcpu.
>> + *
>> + * @cpu - vcpu to be kicked.
>> + */
>> +static void kvm_pv_kick_cpu_op(struct kvm *kvm, int cpu)
>> +{
>> +	struct kvm_vcpu *vcpu = kvm_get_vcpu(kvm, cpu);
>> +	struct kvm_mp_state mp_state;
>> +
>> +	mp_state.mp_state = KVM_MP_STATE_RUNNABLE;
>
> Since vcpu->mp_state is not protected by a lock, this is potentially racy. For example:
>
> CPU0						CPU1
> kvm_pv_kick_cpu_op				running vcpuN
> vcpuN->mp_state = KVM_MP_STATE_RUNNABLE;
> 						kvm_emulate_halt
> 						vcpuN->mp_state = KVM_MP_STATE_HALTED
>
> Is it harmless to lose a kick?
>

Yes you are right. It was potentially racy and it was harmful too!. I 
had observed that it was stalling the CPU before I introduced kicked flag.

But now,

vcpu->kicked = 1  ==> kvm_make_request(KVM_REQ_UNHALT, vcpu); ==>

__vcpu_run() ==> kvm_check_request(KVM_REQ_UNHALT, vcpu) ==>

vcpuN->mp_state = KVM_MP_STATE_RUNNABLE; so eventually we will end up
in RUNNABLE.

Also Avi pointed that, logically kvm_arch_vcpu_ioctl_set_mpstate should
be called only in vcpu thread, so after further debugging, I noticed
that,  setting vcpuN->mp_state = KVM_MP_STATE_RUNNABLE; is not
necessary.
I 'll remove that in the next patch. Thanks for pointing.


			


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 14:39:50 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 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.xensource.com>)
	id 1Ra72W-0004Y0-Cq; Mon, 12 Dec 2011 14:39:36 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raghukt@linux.vnet.ibm.com>) id 1RYG7B-0001v9-7A
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 11:56:45 +0000
X-Env-Sender: raghukt@linux.vnet.ibm.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1323258939!57979011!1
X-Originating-IP: [202.81.31.145]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjAyLjgxLjMxLjE0NSA9PiAxOTYwNjU=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32595 invoked from network); 7 Dec 2011 11:55:43 -0000
Received: from e23smtp03.au.ibm.com (HELO e23smtp03.au.ibm.com) (202.81.31.145)
	by server-15.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 7 Dec 2011 11:55:43 -0000
Received: from /spool/local
	by e23smtp03.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use
	Only! Violators will be prosecuted
	for <xen-devel@lists.xensource.com> from <raghukt@linux.vnet.ibm.com>; 
	Wed, 7 Dec 2011 11:50:19 +1000
Received: from d23relay03.au.ibm.com ([202.81.31.245])
	by e23smtp03.au.ibm.com ([202.81.31.209]) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Wed, 7 Dec 2011 11:49:38 +1000
Received: from d23av01.au.ibm.com (d23av01.au.ibm.com [9.190.234.96])
	by d23relay03.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	pB7Bt89g4993262
	for <xen-devel@lists.xensource.com>; Wed, 7 Dec 2011 22:55:08 +1100
Received: from d23av01.au.ibm.com (loopback [127.0.0.1])
	by d23av01.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id
	pB7Bt6wF030864
	for <xen-devel@lists.xensource.com>; Wed, 7 Dec 2011 22:55:07 +1100
Received: from oc5400248562.ibm.com (oc5400248562.in.ibm.com [9.124.158.57])
	by d23av01.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	pB7Bt2DL030769; Wed, 7 Dec 2011 22:55:02 +1100
Message-ID: <4EDF5413.1030107@linux.vnet.ibm.com>
Date: Wed, 07 Dec 2011 17:24:59 +0530
From: Raghavendra K T <raghukt@linux.vnet.ibm.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
	rv:1.9.2.24) Gecko/20111108 Fedora/3.1.16-1.fc14 Thunderbird/3.1.16
MIME-Version: 1.0
To: Marcelo Tosatti <mtosatti@redhat.com>
References: <20111130085921.23386.89708.sendpatchset@oc5400248562.ibm.com>
	<20111130085959.23386.69166.sendpatchset@oc5400248562.ibm.com>
	<20111207104849.GA24849@amt.cnet>
In-Reply-To: <20111207104849.GA24849@amt.cnet>
x-cbid: 11120701-6102-0000-0000-0000005A078F
X-Mailman-Approved-At: Mon, 12 Dec 2011 14:39:35 +0000
Cc: x86@kernel.org, Gleb Natapov <gleb@redhat.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Xen <xen-devel@lists.xensource.com>,
	Dave Jiang <dave.jiang@intel.com>, KVM <kvm@vger.kernel.org>,
	Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	Ingo Molnar <mingo@redhat.com>, Avi Kivity <avi@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>,
	Sasha Levin <levinsasha928@gmail.com>, Sedat Dilek <sedat.dilek@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>, Yinghai Lu <yinghai@kernel.org>,
	Greg Kroah-Hartman <gregkh@suse.de>, LKML <linux-kernel@vger.kernel.org>,
	Dave Hansen <dave@linux.vnet.ibm.com>,
	Suzuki Poulose <suzuki@linux.vnet.ibm.com>
Subject: Re: [Xen-devel] [PATCH RFC V3 2/4] kvm hypervisor : Add a hypercall
 to KVM hypervisor to support pv-ticketlocks
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 12/07/2011 04:18 PM, Marcelo Tosatti wrote:
> On Wed, Nov 30, 2011 at 02:29:59PM +0530, Raghavendra K T wrote:
>>
>> +/*
>> + * kvm_pv_kick_cpu_op:  Kick a vcpu.
>> + *
>> + * @cpu - vcpu to be kicked.
>> + */
>> +static void kvm_pv_kick_cpu_op(struct kvm *kvm, int cpu)
>> +{
>> +	struct kvm_vcpu *vcpu = kvm_get_vcpu(kvm, cpu);
>> +	struct kvm_mp_state mp_state;
>> +
>> +	mp_state.mp_state = KVM_MP_STATE_RUNNABLE;
>
> Since vcpu->mp_state is not protected by a lock, this is potentially racy. For example:
>
> CPU0						CPU1
> kvm_pv_kick_cpu_op				running vcpuN
> vcpuN->mp_state = KVM_MP_STATE_RUNNABLE;
> 						kvm_emulate_halt
> 						vcpuN->mp_state = KVM_MP_STATE_HALTED
>
> Is it harmless to lose a kick?
>

Yes you are right. It was potentially racy and it was harmful too!. I 
had observed that it was stalling the CPU before I introduced kicked flag.

But now,

vcpu->kicked = 1  ==> kvm_make_request(KVM_REQ_UNHALT, vcpu); ==>

__vcpu_run() ==> kvm_check_request(KVM_REQ_UNHALT, vcpu) ==>

vcpuN->mp_state = KVM_MP_STATE_RUNNABLE; so eventually we will end up
in RUNNABLE.

Also Avi pointed that, logically kvm_arch_vcpu_ioctl_set_mpstate should
be called only in vcpu thread, so after further debugging, I noticed
that,  setting vcpuN->mp_state = KVM_MP_STATE_RUNNABLE; is not
necessary.
I 'll remove that in the next patch. Thanks for pointing.


			


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 14:39:50 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 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.xensource.com>)
	id 1Ra72b-0004bs-U5; Mon, 12 Dec 2011 14:39:41 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raghukt@linux.vnet.ibm.com>) id 1RYhtM-00035H-Bb
	for xen-devel@lists.xensource.com; Thu, 08 Dec 2011 17:36:20 +0000
X-Env-Sender: raghukt@linux.vnet.ibm.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1323365715!48776151!1
X-Originating-IP: [202.81.31.148]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjAyLjgxLjMxLjE0OCA9PiAyMTAyMDc=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23523 invoked from network); 8 Dec 2011 17:35:18 -0000
Received: from e23smtp06.au.ibm.com (HELO e23smtp06.au.ibm.com) (202.81.31.148)
	by server-11.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 8 Dec 2011 17:35:18 -0000
Received: from /spool/local
	by e23smtp06.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use
	Only! Violators will be prosecuted
	for <xen-devel@lists.xensource.com> from <raghukt@linux.vnet.ibm.com>; 
	Thu, 8 Dec 2011 17:33:11 +1000
Received: from d23relay04.au.ibm.com ([202.81.31.246])
	by e23smtp06.au.ibm.com ([202.81.31.212]) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Thu, 8 Dec 2011 17:33:10 +1000
Received: from d23av02.au.ibm.com (d23av02.au.ibm.com [9.190.235.138])
	by d23relay04.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	pB8HVfMl3465430
	for <xen-devel@lists.xensource.com>; Fri, 9 Dec 2011 04:31:44 +1100
Received: from d23av02.au.ibm.com (loopback [127.0.0.1])
	by d23av02.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id
	pB8HZHv9019302
	for <xen-devel@lists.xensource.com>; Fri, 9 Dec 2011 04:35:18 +1100
Received: from oc5400248562.ibm.com ([9.79.214.252])
	by d23av02.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	pB8HZ65E019178; Fri, 9 Dec 2011 04:35:07 +1100
Message-ID: <4EE0F548.8050006@linux.vnet.ibm.com>
Date: Thu, 08 Dec 2011 23:05:04 +0530
From: Raghavendra K T <raghukt@linux.vnet.ibm.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
	rv:1.9.2.24) Gecko/20111108 Fedora/3.1.16-1.fc14 Thunderbird/3.1.16
MIME-Version: 1.0
To: Raghavendra K T <raghukt@linux.vnet.ibm.com>
References: <20111130085921.23386.89708.sendpatchset@oc5400248562.ibm.com>
	<20111130085959.23386.69166.sendpatchset@oc5400248562.ibm.com>
	<4ED760F1.6080804@redhat.com> <4ED7DA85.5080504@linux.vnet.ibm.com>
In-Reply-To: <4ED7DA85.5080504@linux.vnet.ibm.com>
x-cbid: 11120807-7014-0000-0000-0000003B2CC7
X-Mailman-Approved-At: Mon, 12 Dec 2011 14:39:35 +0000
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, x86@kernel.org,
	Gleb Natapov <gleb@redhat.com>, Peter Zijlstra <peterz@infradead.org>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Xen <xen-devel@lists.xensource.com>,
	Dave Jiang <dave.jiang@intel.com>, KVM <kvm@vger.kernel.org>,
	Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	Ingo Molnar <mingo@redhat.com>, Avi Kivity <avi@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Marcelo Tosatti <mtosatti@redhat.com>,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>,
	Sasha Levin <levinsasha928@gmail.com>, Sedat Dilek <sedat.dilek@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>, Yinghai Lu <yinghai@kernel.org>,
	Greg Kroah-Hartman <gregkh@suse.de>, LKML <linux-kernel@vger.kernel.org>,
	Dave Hansen <dave@linux.vnet.ibm.com>,
	Suzuki Poulose <suzuki@linux.vnet.ibm.com>
Subject: Re: [Xen-devel] [PATCH RFC V3 2/4] kvm hypervisor : Add a hypercall
 to KVM hypervisor to support pv-ticketlocks
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 12/02/2011 01:20 AM, Raghavendra K T wrote:
>>>
>>> +/*
>>> + * kvm_pv_kick_cpu_op: Kick a vcpu.
>>> + *
>>> + * @cpu - vcpu to be kicked.
>>> + */
>>> +static void kvm_pv_kick_cpu_op(struct kvm *kvm, int cpu)
>>> +{
>>> + struct kvm_vcpu *vcpu = kvm_get_vcpu(kvm, cpu);
>>
>> There is no guarantee that guest cpu numbers match host vcpu numbers.
>> Use APIC IDs, and kvm_apic_match_dest().
>
> Okay. I have to dig more on this.
>
Sorry for late reply on this, was experimenting with the changes needed.

Wanted to confirm if it is according to your expectation.

  Host side change should look like this to get vcpu,

	int i;
	struct kvm_vcpu *vcpu = NULL;

	kvm_for_each_vcpu(i, vcpu, kvm) {
		if (!kvm_apic_present(vcpu))
		continue;

		if (kvm_apic_match_dest(vcpu, 0, 0, cpu, 0)) {
		break;
		}
	}


In guest side, convert the cpu to apicid using,

apicid = apic->cpu_present_to_apicid(cpu);
OR
apicid =  per_cpu(x86_cpu_to_apicid, cpu);

But I have a question, as you know, we are storing the waiting cpus in
cpumask, to track the cpu to be kicked.

You want to change the logic to store the apicid directly instead of
cpu during contention or is it OK to convert before kick hypercall?.

Probably it would be more good if I can get to know the scenario,
where guest cpu numbers does not match host vcpu numbers. It may answer 
the whole question and help me in testing/validating the code.

Thanks
- Raghu








_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 14:39:50 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 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.xensource.com>)
	id 1Ra72a-0004aW-Ko; Mon, 12 Dec 2011 14:39:40 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <scameron@beardog.cce.hp.com>) id 1RYPQP-0001a7-42
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 21:53:13 +0000
X-Env-Sender: scameron@beardog.cce.hp.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1323294740!6483161!1
X-Originating-IP: [15.216.28.34]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTUuMjE2LjI4LjM0ID0+IDcyMTM0Mg==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15145 invoked from network); 7 Dec 2011 21:52:25 -0000
Received: from g1t0027.austin.hp.com (HELO g1t0027.austin.hp.com)
	(15.216.28.34)
	by server-10.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 7 Dec 2011 21:52:25 -0000
Received: from g1t0038.austin.hp.com (g1t0038.austin.hp.com [16.236.32.44])
	by g1t0027.austin.hp.com (Postfix) with ESMTP id 80FEA381F5
	for <xen-devel@lists.xensource.com>;
	Wed,  7 Dec 2011 21:52:20 +0000 (UTC)
Received: from beardog.cce.hp.com (beardog.cce.hp.com [16.84.84.24])
	by g1t0038.austin.hp.com (Postfix) with ESMTP id 5C52030056;
	Wed,  7 Dec 2011 21:52:20 +0000 (UTC)
Received: from beardog.cce.hp.com (beardog.cce.hp.com [127.0.0.1])
	by beardog.cce.hp.com (8.13.8/8.13.8) with ESMTP id pB7LqKKZ014814;
	Wed, 7 Dec 2011 15:52:20 -0600
Received: (from scameron@localhost)
	by beardog.cce.hp.com (8.13.8/8.13.8/Submit) id pB7LqJud014813;
	Wed, 7 Dec 2011 15:52:19 -0600
Date: Wed, 7 Dec 2011 15:52:19 -0600
From: scameron@beardog.cce.hp.com
To: dbrace <dab@hp.com>
Message-ID: <20111207215219.GH6635@beardog.cce.hp.com>
References: <4EDFDF0D.2020104@hp.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4EDFDF0D.2020104@hp.com>
User-Agent: Mutt/1.4.2.2i
X-Mailman-Approved-At: Mon, 12 Dec 2011 14:39:35 +0000
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] kmap_atomic issue with SLES11SP1 32bit XEN driver
	code
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Dec 07, 2011 at 03:47:57PM -0600, dbrace wrote:
> kernel: Linux 360 2.6.32.12-0.7-xen #1 SMP 2010-05-20 11:14:20 +0200 
> i686 i686 i386 GNU/Linux
> 
> I am having issues with some code that uses kmap_atomic(). I am getting:
> 
> BUG: unable to handle kernel paging request at 23a1a000 (which is the 
> address returned from kmap_atomic().)
> 
> The same code works when running on non-XEN 32bit kernels so I am  
> wondering why this does not work under
> XEN kernels. Is there a different approach that I need to take for 32bit 
> XEN kernels?
> 
> I really only need to do this code segment if the memory address is a 
> high memory address. Is there a MACRO or function
> that can help me determine this?
> 
> Here is a code snippet:
> 
>                 void *linux_vaddr = NULL;       /* kmapped temporary 
> virtual address */
>                 int linux_page_offset = 0;      /* offset in page */
>                 int count = 0;                  /* bytes left to 
> transfer */
>                 int left = byte_count;          /* number of bytes left 
> to transfer */
>                 int memcpysize = 0;             /* current size to 
> transfer */
>                 struct page *linux_page = NULL; /* calculated page */
>                 int kmap_flags = 0;
> 
>                 linux_page = __pfn_to_page(physical_address >> PAGE_SHIFT);
>                 linux_page_offset = (physical_address & 
> 0x0000000000000FFFULL);
>                 memcpysize =  min((PAGE_SIZE - linux_page_offset), left);
> 
>                 kmap_flags = KM_USER0;
> 
>                 linux_vaddr = kmap_atomic(linux_page, kmap_flags) + 
> linux_page_offset;
> 
>                 printk("%s: called kmap_atomic, "
>                         "calling memcpy linux_vaddr = 0x%x virt_address 
> = 0x%x count = 0x%x\n",
>                         __func__, linux_vaddr, virt_address, count);
>                 /*
>                  * Either need to copy to a kmapped destination
>                  * or a kmapped source.
>                  */
>                 if (type == 0) // Write to s/g element, dest virtual 
> addr was known.
>                         memcpy((void *)virt_address+count, (void 
> *)linux_vaddr, memcpysize);
>                 else // Source virt. address was known.
>                         memcpy((void *)linux_vaddr, (void 
> *)virt_address+count, memcpysize);

Just to be clear, it's these memcpy's that get the BUG, correct?

-- steve


> 
>                 printk("OS_Linux32_Xfer_SG_Page: calling kunmap_atomic, "
>                         "calling memcpy linux_vaddr = 0x%lx\n", 
> linux_vaddr);
> 
>                 kunmap_atomic(linux_vaddr, kmap_flags);
> 
> 
> -- 
> Don Brace
> SPSN Linux Development
> Hewlett-Packard Company

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 14:39:49 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 14: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.xensource.com>)
	id 1Ra72Z-0004Z0-0M; Mon, 12 Dec 2011 14:39:39 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raghukt@linux.vnet.ibm.com>) id 1RYKez-0001Bt-4Z
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 16:47:57 +0000
X-Env-Sender: raghukt@linux.vnet.ibm.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1323276403!51272636!1
X-Originating-IP: [122.248.162.3]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTIyLjI0OC4xNjIuMyA9PiAxOTAxNjA=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31508 invoked from network); 7 Dec 2011 16:46:47 -0000
Received: from e28smtp03.in.ibm.com (HELO e28smtp03.in.ibm.com) (122.248.162.3)
	by server-13.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 7 Dec 2011 16:46:47 -0000
Received: from /spool/local
	by e28smtp03.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use
	Only! Violators will be prosecuted
	for <xen-devel@lists.xensource.com> from <raghukt@linux.vnet.ibm.com>; 
	Wed, 7 Dec 2011 22:17:04 +0530
Received: from d28relay04.in.ibm.com (9.184.220.61)
	by e28smtp03.in.ibm.com (192.168.1.133) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Wed, 7 Dec 2011 22:16:59 +0530
Received: from d28av02.in.ibm.com (d28av02.in.ibm.com [9.184.220.64])
	by d28relay04.in.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	pB7GkwnX2867368
	for <xen-devel@lists.xensource.com>; Wed, 7 Dec 2011 22:16:58 +0530
Received: from d28av02.in.ibm.com (loopback [127.0.0.1])
	by d28av02.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id
	pB7Gkvx5012332
	for <xen-devel@lists.xensource.com>; Thu, 8 Dec 2011 03:46:58 +1100
Received: from oc5400248562.ibm.com ([9.77.196.131])
	by d28av02.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	pB7Gks5c012278; Thu, 8 Dec 2011 03:46:54 +1100
Message-ID: <4EDF987B.8040900@linux.vnet.ibm.com>
Date: Wed, 07 Dec 2011 22:16:51 +0530
From: Raghavendra K T <raghukt@linux.vnet.ibm.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
	rv:1.9.2.24) Gecko/20111108 Fedora/3.1.16-1.fc14 Thunderbird/3.1.16
MIME-Version: 1.0
To: Avi Kivity <avi@redhat.com>
References: <20111130085921.23386.89708.sendpatchset@oc5400248562.ibm.com>
	<20111130085959.23386.69166.sendpatchset@oc5400248562.ibm.com>
	<20111207104849.GA24849@amt.cnet>
	<4EDF5413.1030107@linux.vnet.ibm.com>
	<20111207123330.GA32212@amt.cnet> <4EDF6049.2030204@redhat.com>
	<20111207133947.GA1708@amt.cnet> <4EDF7DC5.5010504@redhat.com>
In-Reply-To: <4EDF7DC5.5010504@redhat.com>
x-cbid: 11120716-3864-0000-0000-00000069025E
X-Mailman-Approved-At: Mon, 12 Dec 2011 14:39:35 +0000
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, x86@kernel.org,
	Gleb Natapov <gleb@redhat.com>, Peter Zijlstra <peterz@infradead.org>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Xen <xen-devel@lists.xensource.com>,
	Dave Jiang <dave.jiang@intel.com>, KVM <kvm@vger.kernel.org>,
	Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	Ingo Molnar <mingo@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>,
	Sasha Levin <levinsasha928@gmail.com>, Sedat Dilek <sedat.dilek@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>, Yinghai Lu <yinghai@kernel.org>,
	Greg Kroah-Hartman <gregkh@suse.de>, Marcelo Tosatti <mtosatti@redhat.com>,
	LKML <linux-kernel@vger.kernel.org>, Dave Hansen <dave@linux.vnet.ibm.com>,
	Suzuki Poulose <suzuki@linux.vnet.ibm.com>
Subject: Re: [Xen-devel] [PATCH RFC V3 2/4] kvm hypervisor : Add a hypercall
 to KVM hypervisor to support pv-ticketlocks
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 12/07/2011 08:22 PM, Avi Kivity wrote:
> On 12/07/2011 03:39 PM, Marcelo Tosatti wrote:
>>> Also I think we can keep the kicked flag in vcpu->requests, no need for
>>> new storage.
>>
>> Was going to suggest it but it violates the currently organized
>> processing of entries at the beginning of vcpu_enter_guest.
>>
>> That is, this "kicked" flag is different enough from vcpu->requests
>> processing that a separate variable seems worthwhile (even more
>> different with convertion to MP_STATE at KVM_GET_MP_STATE).
>
> IMO, it's similar to KVM_REQ_EVENT (which can also cause mpstate to
> change due to apic re-evaluation).
>

Ok, So what I understand is we have to either :
1. retain current kick flag AS-IS but would have to make it migration 
friendly. [I still have to get more familiar with migration side]
or
2. introduce notion similar to KVM_REQ_PVLOCK_KICK(??) to be part of
vcpu->requests.

So what would be better? Please let me know.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 14:39:49 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 14: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.xensource.com>)
	id 1Ra72X-0004YL-Ly; Mon, 12 Dec 2011 14:39:37 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <mtosatti@redhat.com>) id 1RYHkX-0005jj-Vn
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 13:41:30 +0000
X-Env-Sender: mtosatti@redhat.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1323265242!6249142!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDYzMzc=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30061 invoked from network); 7 Dec 2011 13:40:42 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-11.tower-182.messagelabs.com with SMTP;
	7 Dec 2011 13:40:42 -0000
Received: from int-mx12.intmail.prod.int.phx2.redhat.com
	(int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id pB7DeMQj025141
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 7 Dec 2011 08:40:22 -0500
Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199])
	by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id pB7DeLoJ012344; Wed, 7 Dec 2011 08:40:21 -0500
Received: from amt.cnet (vpn-8-4.rdu.redhat.com [10.11.8.4])
	by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id pB7DeILa005286;
	Wed, 7 Dec 2011 08:40:19 -0500
Received: from amt.cnet (amt.cnet [127.0.0.1])
	by amt.cnet (Postfix) with ESMTP id E1603652179;
	Wed,  7 Dec 2011 11:39:58 -0200 (BRST)
Received: (from marcelo@localhost)
	by amt.cnet (8.14.5/8.14.5/Submit) id pB7DdlLu001814;
	Wed, 7 Dec 2011 11:39:47 -0200
Date: Wed, 7 Dec 2011 11:39:47 -0200
From: Marcelo Tosatti <mtosatti@redhat.com>
To: Avi Kivity <avi@redhat.com>
Message-ID: <20111207133947.GA1708@amt.cnet>
References: <20111130085921.23386.89708.sendpatchset@oc5400248562.ibm.com>
	<20111130085959.23386.69166.sendpatchset@oc5400248562.ibm.com>
	<20111207104849.GA24849@amt.cnet>
	<4EDF5413.1030107@linux.vnet.ibm.com>
	<20111207123330.GA32212@amt.cnet> <4EDF6049.2030204@redhat.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4EDF6049.2030204@redhat.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.25
X-Mailman-Approved-At: Mon, 12 Dec 2011 14:39:35 +0000
Cc: Raghavendra K T <raghukt@linux.vnet.ibm.com>, x86@kernel.org,
	Gleb Natapov <gleb@redhat.com>, Peter Zijlstra <peterz@infradead.org>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Xen <xen-devel@lists.xensource.com>,
	Dave Jiang <dave.jiang@intel.com>, KVM <kvm@vger.kernel.org>,
	Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	Ingo Molnar <mingo@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>,
	Sasha Levin <levinsasha928@gmail.com>, Sedat Dilek <sedat.dilek@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>, Yinghai Lu <yinghai@kernel.org>,
	Greg Kroah-Hartman <gregkh@suse.de>, LKML <linux-kernel@vger.kernel.org>,
	Dave Hansen <dave@linux.vnet.ibm.com>,
	Suzuki Poulose <suzuki@linux.vnet.ibm.com>
Subject: Re: [Xen-devel] [PATCH RFC V3 2/4] kvm hypervisor : Add a hypercall
 to KVM hypervisor to support pv-ticketlocks
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Dec 07, 2011 at 02:47:05PM +0200, Avi Kivity wrote:
> On 12/07/2011 02:33 PM, Marcelo Tosatti wrote:
> > > 
> > > Also Avi pointed that, logically kvm_arch_vcpu_ioctl_set_mpstate should
> > > be called only in vcpu thread, so after further debugging, I noticed
> > > that,  setting vcpuN->mp_state = KVM_MP_STATE_RUNNABLE; is not
> > > necessary.
> > > I 'll remove that in the next patch. Thanks for pointing.
> >
> > In fact you don't need kvm_arch_vcpu_ioctl_set_mpstate either, only the
> > new "kicked" flag.
> 
> If we have a kicked flag, it becomes necessary to live migrate it.
> 
> Maybe we can change KVM_GET_MP_STATE to fold the kicked flag into the mp
> state (converting HALTED into RUNNABLE).

Yep, that works.

> Also I think we can keep the kicked flag in vcpu->requests, no need for
> new storage.

Was going to suggest it but it violates the currently organized
processing of entries at the beginning of vcpu_enter_guest.

That is, this "kicked" flag is different enough from vcpu->requests
processing that a separate variable seems worthwhile (even more
different with convertion to MP_STATE at KVM_GET_MP_STATE).


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 14:39:49 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 14: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.xensource.com>)
	id 1Ra72Z-0004ZI-Ec; Mon, 12 Dec 2011 14:39:39 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dcmichael1256@gmail.com>) id 1RYMIm-0005QH-MQ
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 18:33:08 +0000
X-Env-Sender: dcmichael1256@gmail.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1323282695!59851008!1
X-Originating-IP: [209.85.161.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11227 invoked from network); 7 Dec 2011 18:31:36 -0000
Received: from mail-gx0-f171.google.com (HELO mail-gx0-f171.google.com)
	(209.85.161.171)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Dec 2011 18:31:36 -0000
Received: by ggnr4 with SMTP id r4so5266627ggn.30
	for <xen-devel@lists.xensource.com>;
	Wed, 07 Dec 2011 10:32:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=subject:from:to:content-type:date:message-id:mime-version:x-mailer
	:content-transfer-encoding;
	bh=rgj64MNDLhP1sAQ4OHYbFfBYaX0u2v4INxzP8cC1zmo=;
	b=WFxWrG9JtwRiNxAGy1hbg52vY2I/W5UQImLgKPNl1Zc8okIjCcIcVOMstlx9W8O6Pj
	GVXBYw+enQtC4a/r6d1fI65v66grbDpPmEzRdIe0KEOY1VGjP2Vzk7c5cd4sOD2ZTxqx
	EHkzDAZC+YMeCuCkPccqVOoXmJj6TwbjcM5zM=
Received: by 10.182.5.198 with SMTP id u6mr2074959obu.14.1323282745162;
	Wed, 07 Dec 2011 10:32:25 -0800 (PST)
Received: from [10.20.14.69] ([114.70.9.204])
	by mx.google.com with ESMTPS id ed2sm3559987obc.6.2011.12.07.10.32.19
	(version=SSLv3 cipher=OTHER); Wed, 07 Dec 2011 10:32:21 -0800 (PST)
From: DcMichael <dcmichael1256@gmail.com>
To: xen-devel@lists.xensource.com
Date: Thu, 08 Dec 2011 03:32:12 +0900
Message-ID: <1323282732.2750.6.camel@dcmichael-pc>
Mime-Version: 1.0
X-Mailer: Evolution 2.30.3 
X-Mailman-Approved-At: Mon, 12 Dec 2011 14:39:35 +0000
Subject: [Xen-devel] How to share memory with kernel and hypervisor?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi!
I'm first in here.
anyway I want to make kernel and hypervisor share there memory.
which the kernal write memory, then hypervisor can read it.
without any function like copy_from_user.

I'll use this memory very many time, so I want share memory like shmget.
but using ring use push function every time.

can I share memory like this way?


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 14:39:50 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 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.xensource.com>)
	id 1Ra72Y-0004YZ-2l; Mon, 12 Dec 2011 14:39:38 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <avi@redhat.com>) id 1RYIsr-0006xA-K4
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 14:54:09 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1323269601!4635479!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDYzMzc=\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 654 invoked from network); 7 Dec 2011 14:53:22 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-5.tower-174.messagelabs.com with SMTP;
	7 Dec 2011 14:53: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 pB7Er1Fk014271
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 7 Dec 2011 09:53:01 -0500
Received: from balrog.usersys.redhat.com (dhcp-4-24.tlv.redhat.com
	[10.35.4.24])
	by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id pB7EqsYZ015445; Wed, 7 Dec 2011 09:52:54 -0500
Message-ID: <4EDF7DC5.5010504@redhat.com>
Date: Wed, 07 Dec 2011 16:52:53 +0200
From: Avi Kivity <avi@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:8.0) Gecko/20111115 Thunderbird/8.0
MIME-Version: 1.0
To: Marcelo Tosatti <mtosatti@redhat.com>
References: <20111130085921.23386.89708.sendpatchset@oc5400248562.ibm.com>
	<20111130085959.23386.69166.sendpatchset@oc5400248562.ibm.com>
	<20111207104849.GA24849@amt.cnet>
	<4EDF5413.1030107@linux.vnet.ibm.com>
	<20111207123330.GA32212@amt.cnet> <4EDF6049.2030204@redhat.com>
	<20111207133947.GA1708@amt.cnet>
In-Reply-To: <20111207133947.GA1708@amt.cnet>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
X-Mailman-Approved-At: Mon, 12 Dec 2011 14:39:35 +0000
Cc: Raghavendra K T <raghukt@linux.vnet.ibm.com>, x86@kernel.org,
	Gleb Natapov <gleb@redhat.com>, Peter Zijlstra <peterz@infradead.org>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Xen <xen-devel@lists.xensource.com>,
	Dave Jiang <dave.jiang@intel.com>, KVM <kvm@vger.kernel.org>,
	Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	Ingo Molnar <mingo@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>,
	Sasha Levin <levinsasha928@gmail.com>, Sedat Dilek <sedat.dilek@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>, Yinghai Lu <yinghai@kernel.org>,
	Greg Kroah-Hartman <gregkh@suse.de>, LKML <linux-kernel@vger.kernel.org>,
	Dave Hansen <dave@linux.vnet.ibm.com>,
	Suzuki Poulose <suzuki@linux.vnet.ibm.com>
Subject: Re: [Xen-devel] [PATCH RFC V3 2/4] kvm hypervisor : Add a hypercall
 to KVM hypervisor to support pv-ticketlocks
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 12/07/2011 03:39 PM, Marcelo Tosatti wrote:
> > Also I think we can keep the kicked flag in vcpu->requests, no need for
> > new storage.
>
> Was going to suggest it but it violates the currently organized
> processing of entries at the beginning of vcpu_enter_guest.
>
> That is, this "kicked" flag is different enough from vcpu->requests
> processing that a separate variable seems worthwhile (even more
> different with convertion to MP_STATE at KVM_GET_MP_STATE).

IMO, it's similar to KVM_REQ_EVENT (which can also cause mpstate to
change due to apic re-evaluation).

-- 
error compiling committee.c: too many arguments to function


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 14:39:50 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 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.xensource.com>)
	id 1Ra72a-0004aW-Ko; Mon, 12 Dec 2011 14:39:40 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <scameron@beardog.cce.hp.com>) id 1RYPQP-0001a7-42
	for xen-devel@lists.xensource.com; Wed, 07 Dec 2011 21:53:13 +0000
X-Env-Sender: scameron@beardog.cce.hp.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1323294740!6483161!1
X-Originating-IP: [15.216.28.34]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTUuMjE2LjI4LjM0ID0+IDcyMTM0Mg==\n
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15145 invoked from network); 7 Dec 2011 21:52:25 -0000
Received: from g1t0027.austin.hp.com (HELO g1t0027.austin.hp.com)
	(15.216.28.34)
	by server-10.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 7 Dec 2011 21:52:25 -0000
Received: from g1t0038.austin.hp.com (g1t0038.austin.hp.com [16.236.32.44])
	by g1t0027.austin.hp.com (Postfix) with ESMTP id 80FEA381F5
	for <xen-devel@lists.xensource.com>;
	Wed,  7 Dec 2011 21:52:20 +0000 (UTC)
Received: from beardog.cce.hp.com (beardog.cce.hp.com [16.84.84.24])
	by g1t0038.austin.hp.com (Postfix) with ESMTP id 5C52030056;
	Wed,  7 Dec 2011 21:52:20 +0000 (UTC)
Received: from beardog.cce.hp.com (beardog.cce.hp.com [127.0.0.1])
	by beardog.cce.hp.com (8.13.8/8.13.8) with ESMTP id pB7LqKKZ014814;
	Wed, 7 Dec 2011 15:52:20 -0600
Received: (from scameron@localhost)
	by beardog.cce.hp.com (8.13.8/8.13.8/Submit) id pB7LqJud014813;
	Wed, 7 Dec 2011 15:52:19 -0600
Date: Wed, 7 Dec 2011 15:52:19 -0600
From: scameron@beardog.cce.hp.com
To: dbrace <dab@hp.com>
Message-ID: <20111207215219.GH6635@beardog.cce.hp.com>
References: <4EDFDF0D.2020104@hp.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4EDFDF0D.2020104@hp.com>
User-Agent: Mutt/1.4.2.2i
X-Mailman-Approved-At: Mon, 12 Dec 2011 14:39:35 +0000
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] kmap_atomic issue with SLES11SP1 32bit XEN driver
	code
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Dec 07, 2011 at 03:47:57PM -0600, dbrace wrote:
> kernel: Linux 360 2.6.32.12-0.7-xen #1 SMP 2010-05-20 11:14:20 +0200 
> i686 i686 i386 GNU/Linux
> 
> I am having issues with some code that uses kmap_atomic(). I am getting:
> 
> BUG: unable to handle kernel paging request at 23a1a000 (which is the 
> address returned from kmap_atomic().)
> 
> The same code works when running on non-XEN 32bit kernels so I am  
> wondering why this does not work under
> XEN kernels. Is there a different approach that I need to take for 32bit 
> XEN kernels?
> 
> I really only need to do this code segment if the memory address is a 
> high memory address. Is there a MACRO or function
> that can help me determine this?
> 
> Here is a code snippet:
> 
>                 void *linux_vaddr = NULL;       /* kmapped temporary 
> virtual address */
>                 int linux_page_offset = 0;      /* offset in page */
>                 int count = 0;                  /* bytes left to 
> transfer */
>                 int left = byte_count;          /* number of bytes left 
> to transfer */
>                 int memcpysize = 0;             /* current size to 
> transfer */
>                 struct page *linux_page = NULL; /* calculated page */
>                 int kmap_flags = 0;
> 
>                 linux_page = __pfn_to_page(physical_address >> PAGE_SHIFT);
>                 linux_page_offset = (physical_address & 
> 0x0000000000000FFFULL);
>                 memcpysize =  min((PAGE_SIZE - linux_page_offset), left);
> 
>                 kmap_flags = KM_USER0;
> 
>                 linux_vaddr = kmap_atomic(linux_page, kmap_flags) + 
> linux_page_offset;
> 
>                 printk("%s: called kmap_atomic, "
>                         "calling memcpy linux_vaddr = 0x%x virt_address 
> = 0x%x count = 0x%x\n",
>                         __func__, linux_vaddr, virt_address, count);
>                 /*
>                  * Either need to copy to a kmapped destination
>                  * or a kmapped source.
>                  */
>                 if (type == 0) // Write to s/g element, dest virtual 
> addr was known.
>                         memcpy((void *)virt_address+count, (void 
> *)linux_vaddr, memcpysize);
>                 else // Source virt. address was known.
>                         memcpy((void *)linux_vaddr, (void 
> *)virt_address+count, memcpysize);

Just to be clear, it's these memcpy's that get the BUG, correct?

-- steve


> 
>                 printk("OS_Linux32_Xfer_SG_Page: calling kunmap_atomic, "
>                         "calling memcpy linux_vaddr = 0x%lx\n", 
> linux_vaddr);
> 
>                 kunmap_atomic(linux_vaddr, kmap_flags);
> 
> 
> -- 
> Don Brace
> SPSN Linux Development
> Hewlett-Packard Company

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 14:40:55 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 14:40:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ra73k-0005Nu-0X; Mon, 12 Dec 2011 14:40:52 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Ra73i-0005Lg-8j
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 14:40:50 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1323700797!6886208!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDc4NQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13421 invoked from network); 12 Dec 2011 14:39:57 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Dec 2011 14:39:57 -0000
X-IronPort-AV: E=Sophos;i="4.71,339,1320624000"; 
   d="scan'208";a="9419116"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Dec 2011 14:39:57 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 12 Dec 2011 14:39:57 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Ra72q-0007hM-Pl; Mon, 12 Dec 2011 14:39:56 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Ra72q-00066e-P3;
	Mon, 12 Dec 2011 14:39:56 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20198.4668.762538.72762@mariner.uk.xensource.com>
Date: Mon, 12 Dec 2011 14:39:56 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1323699458.20077.227.camel@zakaz.uk.xensource.com>
References: <1323108621-22654-1-git-send-email-ian.jackson@eu.citrix.com>
	<1323108621-22654-15-git-send-email-ian.jackson@eu.citrix.com>
	<alpine.DEB.2.00.1112091504060.3517@kaball-desktop>
	<20194.13560.873396.700831@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1112091629340.3517@kaball-desktop>
	<20194.17095.512495.93972@mariner.uk.xensource.com>
	<1323699458.20077.227.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 14/15] libxl: New API for providing OS
 events to libxl
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("Re: [Xen-devel] [PATCH 14/15] libxl: New API for providing OS events to libxl"):
> One specific pitfall which trips me up is that when one has multiple
> commented function prototypes in a block, thus:
> 
> 	a_function(...)
> 	/* describe function a...
> 	 * ...
> 	 * at length
> 	 */
> 	b_function(...)
> 	/* describe function b...
> 	 * ...
> 	 * at length
> 	 */
> then figuring out which comment goes with which prototype is non-obvious

I find these very confusing.  There should be blank lines,
like this:

 	a_function(...)
 	/* describe function a...
 	 * ...
 	 * at length
 	 */

 	b_function(...)
 	/* describe function b...
 	 * ...
 	 * at length
 	 */

> and since I naturally look above the prototype for the comment I
> inevitably get the wrong one. This is compounded somewhat because we
> tend to document other types of object above rather than below and
> function prototypes are therefore something of a special case.
> (admittedly the correct solution here is more line breaks whatever the
> style of commenting used)

Yes :-).

> We seem to have a mixture of both styles in libxl headers which is
> obviously much worse than either option. If an opinion is needed to tip
> the scales then I lean slightly towards commenting above but not
> noticeably changing the style of commentary.

OK, I will move them.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 14:40:55 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 14:40:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ra73k-0005Nu-0X; Mon, 12 Dec 2011 14:40:52 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Ra73i-0005Lg-8j
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 14:40:50 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1323700797!6886208!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDc4NQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13421 invoked from network); 12 Dec 2011 14:39:57 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Dec 2011 14:39:57 -0000
X-IronPort-AV: E=Sophos;i="4.71,339,1320624000"; 
   d="scan'208";a="9419116"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Dec 2011 14:39:57 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 12 Dec 2011 14:39:57 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Ra72q-0007hM-Pl; Mon, 12 Dec 2011 14:39:56 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Ra72q-00066e-P3;
	Mon, 12 Dec 2011 14:39:56 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20198.4668.762538.72762@mariner.uk.xensource.com>
Date: Mon, 12 Dec 2011 14:39:56 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1323699458.20077.227.camel@zakaz.uk.xensource.com>
References: <1323108621-22654-1-git-send-email-ian.jackson@eu.citrix.com>
	<1323108621-22654-15-git-send-email-ian.jackson@eu.citrix.com>
	<alpine.DEB.2.00.1112091504060.3517@kaball-desktop>
	<20194.13560.873396.700831@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1112091629340.3517@kaball-desktop>
	<20194.17095.512495.93972@mariner.uk.xensource.com>
	<1323699458.20077.227.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 14/15] libxl: New API for providing OS
 events to libxl
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("Re: [Xen-devel] [PATCH 14/15] libxl: New API for providing OS events to libxl"):
> One specific pitfall which trips me up is that when one has multiple
> commented function prototypes in a block, thus:
> 
> 	a_function(...)
> 	/* describe function a...
> 	 * ...
> 	 * at length
> 	 */
> 	b_function(...)
> 	/* describe function b...
> 	 * ...
> 	 * at length
> 	 */
> then figuring out which comment goes with which prototype is non-obvious

I find these very confusing.  There should be blank lines,
like this:

 	a_function(...)
 	/* describe function a...
 	 * ...
 	 * at length
 	 */

 	b_function(...)
 	/* describe function b...
 	 * ...
 	 * at length
 	 */

> and since I naturally look above the prototype for the comment I
> inevitably get the wrong one. This is compounded somewhat because we
> tend to document other types of object above rather than below and
> function prototypes are therefore something of a special case.
> (admittedly the correct solution here is more line breaks whatever the
> style of commenting used)

Yes :-).

> We seem to have a mixture of both styles in libxl headers which is
> obviously much worse than either option. If an opinion is needed to tip
> the scales then I lean slightly towards commenting above but not
> noticeably changing the style of commentary.

OK, I will move them.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 14:41:11 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 14: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.xensource.com>)
	id 1Ra73z-0005Zx-NV; Mon, 12 Dec 2011 14:41:07 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Ra73y-0005VD-6j
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 14:41:06 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1323700812!7115857!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDc4NQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1520 invoked from network); 12 Dec 2011 14:40:12 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Dec 2011 14:40:12 -0000
X-IronPort-AV: E=Sophos;i="4.71,339,1320624000"; 
   d="scan'208";a="9419123"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Dec 2011 14:40:12 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 12 Dec 2011 14:40:12 +0000
Date: Mon, 12 Dec 2011 14:41:36 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Jan Kiszka <jan.kiszka@siemens.com>
In-Reply-To: <4EE609BF.1070307@siemens.com>
Message-ID: <alpine.DEB.2.00.1112121438410.3517@kaball-desktop>
References: <1323467645-24271-1-git-send-email-anthony.perard@citrix.com>
	<1323467645-24271-6-git-send-email-anthony.perard@citrix.com>
	<4EE3382D.80903@web.de>
	<alpine.DEB.2.00.1112121259180.3517@kaball-desktop>
	<4EE609BF.1070307@siemens.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Anthony Perard <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	QEMU-devel <qemu-devel@nongnu.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH V2 5/5] vga-cirrus: Workaround during
 restore when using Xen.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 12 Dec 2011, Jan Kiszka wrote:
> On 2011-12-12 14:18, Stefano Stabellini wrote:
> > On Sat, 10 Dec 2011, Jan Kiszka wrote:
> >> On 2011-12-09 22:54, Anthony PERARD wrote:
> >>> During the initialisation of the machine at restore time, the access to the
> >>> VRAM will fail because QEMU does not know yet the right guest address to map,
> >>> so the vram_ptr is NULL.
> >>>
> >>> So this patch avoid using a NULL pointer during initialisation, and try to get
> >>> another vram_ptr if the call failed the first time.
> >>>
> >>> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> >>> ---
> >>>  hw/cirrus_vga.c |   16 +++++++++++++---
> >>>  1 files changed, 13 insertions(+), 3 deletions(-)
> >>>
> >>> diff --git a/hw/cirrus_vga.c b/hw/cirrus_vga.c
> >>> index c7e365b..2e049c9 100644
> >>> --- a/hw/cirrus_vga.c
> >>> +++ b/hw/cirrus_vga.c
> >>> @@ -32,6 +32,7 @@
> >>>  #include "console.h"
> >>>  #include "vga_int.h"
> >>>  #include "loader.h"
> >>> +#include "sysemu.h"
> >>>  
> >>>  /*
> >>>   * TODO:
> >>> @@ -2696,6 +2697,13 @@ static int cirrus_post_load(void *opaque, int version_id)
> >>>      s->vga.gr[0x01] = s->cirrus_shadow_gr1 & 0x0f;
> >>>  
> >>>      cirrus_update_memory_access(s);
> >>> +    if (!s->vga.vram_ptr) {
> >>> +        /* At this point vga.vram_ptr can be invalid on Xen because we need to
> >>> +         * know the position of the videoram in the guest physical address space in
> >>> +         * order to be able to map it. After cirrus_update_memory_access we do know
> >>> +         * where the videoram is, so let's map it now. */
> >>> +        s->vga.vram_ptr = memory_region_get_ram_ptr(&s->vga.vram);
> >>> +    }
> >>>      /* force refresh */
> >>>      s->vga.graphic_mode = -1;
> >>>      cirrus_update_bank_ptr(s, 0);
> >>> @@ -2784,9 +2792,11 @@ static void cirrus_reset(void *opaque)
> >>>      }
> >>>      s->vga.cr[0x27] = s->device_id;
> >>>  
> >>> -    /* Win2K seems to assume that the pattern buffer is at 0xff
> >>> -       initially ! */
> >>> -    memset(s->vga.vram_ptr, 0xff, s->real_vram_size);
> >>> +    if (!runstate_check(RUN_STATE_PREMIGRATE)) {
> >>> +        /* Win2K seems to assume that the pattern buffer is at 0xff
> >>> +           initially ! */
> >>> +        memset(s->vga.vram_ptr, 0xff, s->real_vram_size);
> >>> +    }
> >>>  
> >>>      s->cirrus_hidden_dac_lockindex = 5;
> >>>      s->cirrus_hidden_dac_data = 0;
> >>
> >> Is there really no way to fix this properly in the Xen layer?
> > 
> > We thought about this issue for some time but we couldn't come up with
> > anything better.
> > To summarize the problem:
> > 
> > - on restore the videoram has already been loaded in the guest physical
> >   address space by Xen;
> > 
> > - we don't know exactly where it is yet, because it has been loaded at
> >   the *last* address it was mapped to (see map_linear_vram_bank that
> >   moves the videoram);
> > 
> > - we want to avoid allocating the videoram twice (actually the second
> >   allocation would fail because of memory constraints);
> > 
> > 
> > 
> > So the solution (I acknowledge that it looks more like an hack than a
> > solution) is:
> > 
> > - wait for cirrus to load its state so that we know where the videoram
> >   is;
> 
> Why can't you store this information in some additional Xen-specific
> vmstate? The fact that memory_region_get_ram_ptr has to return NULL
> looks bogus to me. It's against the QEMU semantics. Other devices may
> only be fine as they are not (yet) used with Xen.

Unfortunately that cannot work because the allocation is done by
vga_common_init before any state has been loaded.
So even if we saved the physmap QLIST in a vmstate record, it wouldn't
be available yet when vga_common_init tries to allocate the memory.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 14:41:11 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 14: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.xensource.com>)
	id 1Ra73z-0005Zx-NV; Mon, 12 Dec 2011 14:41:07 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Ra73y-0005VD-6j
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 14:41:06 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1323700812!7115857!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDc4NQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1520 invoked from network); 12 Dec 2011 14:40:12 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Dec 2011 14:40:12 -0000
X-IronPort-AV: E=Sophos;i="4.71,339,1320624000"; 
   d="scan'208";a="9419123"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Dec 2011 14:40:12 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 12 Dec 2011 14:40:12 +0000
Date: Mon, 12 Dec 2011 14:41:36 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Jan Kiszka <jan.kiszka@siemens.com>
In-Reply-To: <4EE609BF.1070307@siemens.com>
Message-ID: <alpine.DEB.2.00.1112121438410.3517@kaball-desktop>
References: <1323467645-24271-1-git-send-email-anthony.perard@citrix.com>
	<1323467645-24271-6-git-send-email-anthony.perard@citrix.com>
	<4EE3382D.80903@web.de>
	<alpine.DEB.2.00.1112121259180.3517@kaball-desktop>
	<4EE609BF.1070307@siemens.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Anthony Perard <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	QEMU-devel <qemu-devel@nongnu.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH V2 5/5] vga-cirrus: Workaround during
 restore when using Xen.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 12 Dec 2011, Jan Kiszka wrote:
> On 2011-12-12 14:18, Stefano Stabellini wrote:
> > On Sat, 10 Dec 2011, Jan Kiszka wrote:
> >> On 2011-12-09 22:54, Anthony PERARD wrote:
> >>> During the initialisation of the machine at restore time, the access to the
> >>> VRAM will fail because QEMU does not know yet the right guest address to map,
> >>> so the vram_ptr is NULL.
> >>>
> >>> So this patch avoid using a NULL pointer during initialisation, and try to get
> >>> another vram_ptr if the call failed the first time.
> >>>
> >>> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> >>> ---
> >>>  hw/cirrus_vga.c |   16 +++++++++++++---
> >>>  1 files changed, 13 insertions(+), 3 deletions(-)
> >>>
> >>> diff --git a/hw/cirrus_vga.c b/hw/cirrus_vga.c
> >>> index c7e365b..2e049c9 100644
> >>> --- a/hw/cirrus_vga.c
> >>> +++ b/hw/cirrus_vga.c
> >>> @@ -32,6 +32,7 @@
> >>>  #include "console.h"
> >>>  #include "vga_int.h"
> >>>  #include "loader.h"
> >>> +#include "sysemu.h"
> >>>  
> >>>  /*
> >>>   * TODO:
> >>> @@ -2696,6 +2697,13 @@ static int cirrus_post_load(void *opaque, int version_id)
> >>>      s->vga.gr[0x01] = s->cirrus_shadow_gr1 & 0x0f;
> >>>  
> >>>      cirrus_update_memory_access(s);
> >>> +    if (!s->vga.vram_ptr) {
> >>> +        /* At this point vga.vram_ptr can be invalid on Xen because we need to
> >>> +         * know the position of the videoram in the guest physical address space in
> >>> +         * order to be able to map it. After cirrus_update_memory_access we do know
> >>> +         * where the videoram is, so let's map it now. */
> >>> +        s->vga.vram_ptr = memory_region_get_ram_ptr(&s->vga.vram);
> >>> +    }
> >>>      /* force refresh */
> >>>      s->vga.graphic_mode = -1;
> >>>      cirrus_update_bank_ptr(s, 0);
> >>> @@ -2784,9 +2792,11 @@ static void cirrus_reset(void *opaque)
> >>>      }
> >>>      s->vga.cr[0x27] = s->device_id;
> >>>  
> >>> -    /* Win2K seems to assume that the pattern buffer is at 0xff
> >>> -       initially ! */
> >>> -    memset(s->vga.vram_ptr, 0xff, s->real_vram_size);
> >>> +    if (!runstate_check(RUN_STATE_PREMIGRATE)) {
> >>> +        /* Win2K seems to assume that the pattern buffer is at 0xff
> >>> +           initially ! */
> >>> +        memset(s->vga.vram_ptr, 0xff, s->real_vram_size);
> >>> +    }
> >>>  
> >>>      s->cirrus_hidden_dac_lockindex = 5;
> >>>      s->cirrus_hidden_dac_data = 0;
> >>
> >> Is there really no way to fix this properly in the Xen layer?
> > 
> > We thought about this issue for some time but we couldn't come up with
> > anything better.
> > To summarize the problem:
> > 
> > - on restore the videoram has already been loaded in the guest physical
> >   address space by Xen;
> > 
> > - we don't know exactly where it is yet, because it has been loaded at
> >   the *last* address it was mapped to (see map_linear_vram_bank that
> >   moves the videoram);
> > 
> > - we want to avoid allocating the videoram twice (actually the second
> >   allocation would fail because of memory constraints);
> > 
> > 
> > 
> > So the solution (I acknowledge that it looks more like an hack than a
> > solution) is:
> > 
> > - wait for cirrus to load its state so that we know where the videoram
> >   is;
> 
> Why can't you store this information in some additional Xen-specific
> vmstate? The fact that memory_region_get_ram_ptr has to return NULL
> looks bogus to me. It's against the QEMU semantics. Other devices may
> only be fine as they are not (yet) used with Xen.

Unfortunately that cannot work because the allocation is done by
vga_common_init before any state has been loaded.
So even if we saved the physmap QLIST in a vmstate record, it wouldn't
be available yet when vga_common_init tries to allocate the memory.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 14:41:43 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 14:41:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ra74V-0005xK-7j; Mon, 12 Dec 2011 14:41:39 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Ra74U-0005re-B9
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 14:41:38 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1323700844!5221957!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17774 invoked from network); 12 Dec 2011 14:40:44 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-6.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 12 Dec 2011 14:40:44 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 12 Dec 2011 14:40:44 +0000
Message-Id: <4EE620B40200007800066F23@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 12 Dec 2011 14:41:40 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Christoph Egger" <Christoph.Egger@amd.com>
References: <4EE60958.70403@amd.com>
In-Reply-To: <4EE60958.70403@amd.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] microcode fix
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 12.12.11 at 15:02, Christoph Egger <Christoph.Egger@amd.com> wrote:
> Remove hardcoded maximum size a microcode patch can have.
> This is dynamic now.
> 
> The microcode patch for family15h can be larger than 2048 bytes
> and gets silently truncated.
> 
> Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>
> 
> P.S. Please apply this to Xen 4.1, 4.0, 3.4 and 3.3, too.

Please sync up with latest -unstable. At least this hunk (which also
is completely unrelated to anything mentioned in the description)

>@@ -99,7 +91,7 @@ static int microcode_fits(void *mc, int 
>     }
> 
>     if ( mc_header->patch_id <= uci->cpu_sig.rev )
>-        return -EINVAL;
>+        return 1;
> 
>     printk(KERN_DEBUG "microcode: CPU%d found a matching microcode "
>            "update with version 0x%x (current=0x%x)\n",

would not apply anymore (and is wrong - zero is being and should be
returned in this case).

There's also a stray hunk (mis?)adjusting only formatting, which should
be removed.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 14:41:43 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 14:41:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ra74V-0005xK-7j; Mon, 12 Dec 2011 14:41:39 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Ra74U-0005re-B9
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 14:41:38 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1323700844!5221957!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17774 invoked from network); 12 Dec 2011 14:40:44 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-6.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 12 Dec 2011 14:40:44 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 12 Dec 2011 14:40:44 +0000
Message-Id: <4EE620B40200007800066F23@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 12 Dec 2011 14:41:40 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Christoph Egger" <Christoph.Egger@amd.com>
References: <4EE60958.70403@amd.com>
In-Reply-To: <4EE60958.70403@amd.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] microcode fix
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 12.12.11 at 15:02, Christoph Egger <Christoph.Egger@amd.com> wrote:
> Remove hardcoded maximum size a microcode patch can have.
> This is dynamic now.
> 
> The microcode patch for family15h can be larger than 2048 bytes
> and gets silently truncated.
> 
> Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>
> 
> P.S. Please apply this to Xen 4.1, 4.0, 3.4 and 3.3, too.

Please sync up with latest -unstable. At least this hunk (which also
is completely unrelated to anything mentioned in the description)

>@@ -99,7 +91,7 @@ static int microcode_fits(void *mc, int 
>     }
> 
>     if ( mc_header->patch_id <= uci->cpu_sig.rev )
>-        return -EINVAL;
>+        return 1;
> 
>     printk(KERN_DEBUG "microcode: CPU%d found a matching microcode "
>            "update with version 0x%x (current=0x%x)\n",

would not apply anymore (and is wrong - zero is being and should be
returned in this case).

There's also a stray hunk (mis?)adjusting only formatting, which should
be removed.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 14:48:20 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 14:48:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ra7An-0007nM-AC; Mon, 12 Dec 2011 14:48:09 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Ra7Al-0007n6-TI
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 14:48:08 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1323701234!5206710!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDc4NQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21051 invoked from network); 12 Dec 2011 14:47:14 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Dec 2011 14:47:14 -0000
X-IronPort-AV: E=Sophos;i="4.71,339,1320624000"; 
   d="scan'208";a="9419486"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Dec 2011 14:47:14 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 12 Dec 2011 14:47:14 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1Ra79u-0007jg-22;
	Mon, 12 Dec 2011 14:47:14 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Ra79t-0008AM-Uf;
	Mon, 12 Dec 2011 14:47:13 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10475-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 12 Dec 2011 14:47:13 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10475: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10475 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10475/

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-amd64-xl-sedf-pin 14 guest-localmigrate/x10    fail REGR. vs. 10474

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-i386-i386-xl-winxpsp3    7 windows-install              fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install          fail never pass
 test-amd64-i386-xl-win7-amd64  7 windows-install              fail  never pass
 test-amd64-i386-xend-winxpsp3  7 windows-install              fail  never pass
 test-amd64-amd64-xl-win7-amd64  7 windows-install              fail never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-amd64-xl-sedf     14 guest-localmigrate/x10       fail   like 10474
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  f1ab2c2138d8
baseline version:
 xen                  1c58bb664d8d

------------------------------------------------------------
People who touched revisions under test:
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   24373:f1ab2c2138d8
tag:         tip
user:        Jan Beulich <jbeulich@suse.com>
date:        Mon Dec 12 10:47:26 2011 +0100
    
    x86/Intel: quiesce revised CPUID level message
    
    Print this only once, for the boot CPU, unless "cpuinfo" was specified.
    I found this particularly annoying on a machine which also didn't have
    it MTRRs consistently set up across cores, resulting in the printing of
    those messages being awfully slow (and with a second per-CPU message
    added for debugging purposes this even lead to timeouts during AP
    bringup).
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    
    
changeset:   24372:1c58bb664d8d
user:        Philipp Hahn <hahn@univention.de>
date:        Thu Dec 08 17:15:16 2011 +0000
    
    xend: fix insufficient quoting in tapdisk
    
    Fix insufficient quoting between "tap-ctl list" and
    xend/server/BlktapController.py
    
    The "line.split(None, 4)" needs to be a "3", because 3 splits needs to
    be done to get the 4 parts.  Sorry for the mixup.
    
    [ fix to 24335:3915bd95ade5. -iwj ]
    
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
========================================
commit 54e24021005458ad0a361c1d83011b751726a94b
Author: Ian Jackson <ian.jackson@eu.citrix.com>
Date:   Thu Dec 8 16:38:06 2011 +0000

    qemu_get_timer: Provide a comment about the behaviour on ts==NULL
    
    Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 14:48:20 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 14:48:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ra7An-0007nM-AC; Mon, 12 Dec 2011 14:48:09 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Ra7Al-0007n6-TI
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 14:48:08 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1323701234!5206710!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDc4NQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21051 invoked from network); 12 Dec 2011 14:47:14 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Dec 2011 14:47:14 -0000
X-IronPort-AV: E=Sophos;i="4.71,339,1320624000"; 
   d="scan'208";a="9419486"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Dec 2011 14:47:14 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 12 Dec 2011 14:47:14 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1Ra79u-0007jg-22;
	Mon, 12 Dec 2011 14:47:14 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Ra79t-0008AM-Uf;
	Mon, 12 Dec 2011 14:47:13 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10475-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 12 Dec 2011 14:47:13 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10475: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10475 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10475/

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-amd64-xl-sedf-pin 14 guest-localmigrate/x10    fail REGR. vs. 10474

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-i386-i386-xl-winxpsp3    7 windows-install              fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install          fail never pass
 test-amd64-i386-xl-win7-amd64  7 windows-install              fail  never pass
 test-amd64-i386-xend-winxpsp3  7 windows-install              fail  never pass
 test-amd64-amd64-xl-win7-amd64  7 windows-install              fail never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-amd64-xl-sedf     14 guest-localmigrate/x10       fail   like 10474
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  f1ab2c2138d8
baseline version:
 xen                  1c58bb664d8d

------------------------------------------------------------
People who touched revisions under test:
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   24373:f1ab2c2138d8
tag:         tip
user:        Jan Beulich <jbeulich@suse.com>
date:        Mon Dec 12 10:47:26 2011 +0100
    
    x86/Intel: quiesce revised CPUID level message
    
    Print this only once, for the boot CPU, unless "cpuinfo" was specified.
    I found this particularly annoying on a machine which also didn't have
    it MTRRs consistently set up across cores, resulting in the printing of
    those messages being awfully slow (and with a second per-CPU message
    added for debugging purposes this even lead to timeouts during AP
    bringup).
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    
    
changeset:   24372:1c58bb664d8d
user:        Philipp Hahn <hahn@univention.de>
date:        Thu Dec 08 17:15:16 2011 +0000
    
    xend: fix insufficient quoting in tapdisk
    
    Fix insufficient quoting between "tap-ctl list" and
    xend/server/BlktapController.py
    
    The "line.split(None, 4)" needs to be a "3", because 3 splits needs to
    be done to get the 4 parts.  Sorry for the mixup.
    
    [ fix to 24335:3915bd95ade5. -iwj ]
    
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
========================================
commit 54e24021005458ad0a361c1d83011b751726a94b
Author: Ian Jackson <ian.jackson@eu.citrix.com>
Date:   Thu Dec 8 16:38:06 2011 +0000

    qemu_get_timer: Provide a comment about the behaviour on ts==NULL
    
    Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 14:53:44 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 14:53:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ra7Fz-00080a-5m; Mon, 12 Dec 2011 14:53:31 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Ra7Fx-00080N-7q
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 14:53:29 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1323701555!7887363!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDc4NQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22169 invoked from network); 12 Dec 2011 14:52:36 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Dec 2011 14:52:36 -0000
X-IronPort-AV: E=Sophos;i="4.71,339,1320624000"; 
   d="scan'208";a="9419704"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Dec 2011 14:52:35 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 12 Dec 2011 14:52:35 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Ra7F5-0007lY-55; Mon, 12 Dec 2011 14:52:35 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Ra7F5-00069G-4V;
	Mon, 12 Dec 2011 14:52:35 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20198.5427.127204.527798@mariner.uk.xensource.com>
Date: Mon, 12 Dec 2011 14:52:35 +0000
To: Christoph Egger <Christoph.Egger@amd.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <4EDDE199.2090801@amd.com>
References: <4EDDE199.2090801@amd.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH] libxc: switch to XC_PAGE_*
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Christoph Egger writes ("[Xen-devel] [PATCH] libxc: switch to XC_PAGE_*"):
> Switch to a consistent set of XC_PAGE_* constants.

This looks reasonable to me but: can you confirm what tests you've
done to check that this doesn't have any actual change to the code ?

Eg it would be good to run it through the preprocessor and see if the
output is identical to before.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 14:53:44 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 14:53:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ra7Fz-00080a-5m; Mon, 12 Dec 2011 14:53:31 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Ra7Fx-00080N-7q
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 14:53:29 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1323701555!7887363!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDc4NQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22169 invoked from network); 12 Dec 2011 14:52:36 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Dec 2011 14:52:36 -0000
X-IronPort-AV: E=Sophos;i="4.71,339,1320624000"; 
   d="scan'208";a="9419704"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Dec 2011 14:52:35 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 12 Dec 2011 14:52:35 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Ra7F5-0007lY-55; Mon, 12 Dec 2011 14:52:35 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Ra7F5-00069G-4V;
	Mon, 12 Dec 2011 14:52:35 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20198.5427.127204.527798@mariner.uk.xensource.com>
Date: Mon, 12 Dec 2011 14:52:35 +0000
To: Christoph Egger <Christoph.Egger@amd.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <4EDDE199.2090801@amd.com>
References: <4EDDE199.2090801@amd.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH] libxc: switch to XC_PAGE_*
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Christoph Egger writes ("[Xen-devel] [PATCH] libxc: switch to XC_PAGE_*"):
> Switch to a consistent set of XC_PAGE_* constants.

This looks reasonable to me but: can you confirm what tests you've
done to check that this doesn't have any actual change to the code ?

Eg it would be good to run it through the preprocessor and see if the
output is identical to before.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 15:04:38 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 15:04:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ra7QW-0008F3-Cz; Mon, 12 Dec 2011 15:04:24 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jan.kiszka@siemens.com>) id 1Ra7QV-0008Ey-C2
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 15:04:23 +0000
X-Env-Sender: jan.kiszka@siemens.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1323702171!50435311!1
X-Originating-IP: [192.35.17.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjM1LjE3LjI4ID0+IDI5NDM2MA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9124 invoked from network); 12 Dec 2011 15:02:52 -0000
Received: from goliath.siemens.de (HELO goliath.siemens.de) (192.35.17.28)
	by server-6.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Dec 2011 15:02:52 -0000
Received: from mail1.siemens.de (localhost [127.0.0.1])
	by goliath.siemens.de (8.13.6/8.13.6) with ESMTP id pBCF3N1x018739;
	Mon, 12 Dec 2011 16:03:24 +0100
Received: from mchn199C.mchp.siemens.de ([139.25.109.49])
	by mail1.siemens.de (8.13.6/8.13.6) with ESMTP id pBCF3Mmj008607;
	Mon, 12 Dec 2011 16:03:22 +0100
Message-ID: <4EE617BA.4030102@siemens.com>
Date: Mon, 12 Dec 2011 16:03:22 +0100
From: Jan Kiszka <jan.kiszka@siemens.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de;
	rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12
	Mnenhy/0.7.5.666
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <1323467645-24271-1-git-send-email-anthony.perard@citrix.com>
	<1323467645-24271-6-git-send-email-anthony.perard@citrix.com>
	<4EE3382D.80903@web.de>
	<alpine.DEB.2.00.1112121259180.3517@kaball-desktop>
	<4EE609BF.1070307@siemens.com>
	<alpine.DEB.2.00.1112121438410.3517@kaball-desktop>
In-Reply-To: <alpine.DEB.2.00.1112121438410.3517@kaball-desktop>
Cc: Anthony Perard <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	QEMU-devel <qemu-devel@nongnu.org>
Subject: Re: [Xen-devel] [PATCH V2 5/5] vga-cirrus: Workaround during
 restore when using Xen.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 2011-12-12 15:41, Stefano Stabellini wrote:
> On Mon, 12 Dec 2011, Jan Kiszka wrote:
>> On 2011-12-12 14:18, Stefano Stabellini wrote:
>>> On Sat, 10 Dec 2011, Jan Kiszka wrote:
>>>> On 2011-12-09 22:54, Anthony PERARD wrote:
>>>>> During the initialisation of the machine at restore time, the access to the
>>>>> VRAM will fail because QEMU does not know yet the right guest address to map,
>>>>> so the vram_ptr is NULL.
>>>>>
>>>>> So this patch avoid using a NULL pointer during initialisation, and try to get
>>>>> another vram_ptr if the call failed the first time.
>>>>>
>>>>> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
>>>>> ---
>>>>>  hw/cirrus_vga.c |   16 +++++++++++++---
>>>>>  1 files changed, 13 insertions(+), 3 deletions(-)
>>>>>
>>>>> diff --git a/hw/cirrus_vga.c b/hw/cirrus_vga.c
>>>>> index c7e365b..2e049c9 100644
>>>>> --- a/hw/cirrus_vga.c
>>>>> +++ b/hw/cirrus_vga.c
>>>>> @@ -32,6 +32,7 @@
>>>>>  #include "console.h"
>>>>>  #include "vga_int.h"
>>>>>  #include "loader.h"
>>>>> +#include "sysemu.h"
>>>>>  
>>>>>  /*
>>>>>   * TODO:
>>>>> @@ -2696,6 +2697,13 @@ static int cirrus_post_load(void *opaque, int version_id)
>>>>>      s->vga.gr[0x01] = s->cirrus_shadow_gr1 & 0x0f;
>>>>>  
>>>>>      cirrus_update_memory_access(s);
>>>>> +    if (!s->vga.vram_ptr) {
>>>>> +        /* At this point vga.vram_ptr can be invalid on Xen because we need to
>>>>> +         * know the position of the videoram in the guest physical address space in
>>>>> +         * order to be able to map it. After cirrus_update_memory_access we do know
>>>>> +         * where the videoram is, so let's map it now. */
>>>>> +        s->vga.vram_ptr = memory_region_get_ram_ptr(&s->vga.vram);
>>>>> +    }
>>>>>      /* force refresh */
>>>>>      s->vga.graphic_mode = -1;
>>>>>      cirrus_update_bank_ptr(s, 0);
>>>>> @@ -2784,9 +2792,11 @@ static void cirrus_reset(void *opaque)
>>>>>      }
>>>>>      s->vga.cr[0x27] = s->device_id;
>>>>>  
>>>>> -    /* Win2K seems to assume that the pattern buffer is at 0xff
>>>>> -       initially ! */
>>>>> -    memset(s->vga.vram_ptr, 0xff, s->real_vram_size);
>>>>> +    if (!runstate_check(RUN_STATE_PREMIGRATE)) {
>>>>> +        /* Win2K seems to assume that the pattern buffer is at 0xff
>>>>> +           initially ! */
>>>>> +        memset(s->vga.vram_ptr, 0xff, s->real_vram_size);
>>>>> +    }
>>>>>  
>>>>>      s->cirrus_hidden_dac_lockindex = 5;
>>>>>      s->cirrus_hidden_dac_data = 0;
>>>>
>>>> Is there really no way to fix this properly in the Xen layer?
>>>
>>> We thought about this issue for some time but we couldn't come up with
>>> anything better.
>>> To summarize the problem:
>>>
>>> - on restore the videoram has already been loaded in the guest physical
>>>   address space by Xen;
>>>
>>> - we don't know exactly where it is yet, because it has been loaded at
>>>   the *last* address it was mapped to (see map_linear_vram_bank that
>>>   moves the videoram);
>>>
>>> - we want to avoid allocating the videoram twice (actually the second
>>>   allocation would fail because of memory constraints);
>>>
>>>
>>>
>>> So the solution (I acknowledge that it looks more like an hack than a
>>> solution) is:
>>>
>>> - wait for cirrus to load its state so that we know where the videoram
>>>   is;
>>
>> Why can't you store this information in some additional Xen-specific
>> vmstate? The fact that memory_region_get_ram_ptr has to return NULL
>> looks bogus to me. It's against the QEMU semantics. Other devices may
>> only be fine as they are not (yet) used with Xen.
> 
> Unfortunately that cannot work because the allocation is done by
> vga_common_init before any state has been loaded.
> So even if we saved the physmap QLIST in a vmstate record, it wouldn't
> be available yet when vga_common_init tries to allocate the memory.

If you run two VMs with identical setup, one from cold start to
operational mode, the other into an incoming migration, the guest
physical memory layout the host sees is different? Hmm, maybe if you
reorder devices in the command line.

Really, I think this is something inherently incompatible with the
current memory API. If Xen has this unfixable special "requirement"
(it's rather a design issue IMHO), adjust the API and adapt all devices.
Hot-fixing only a single one this way is no good idea long term.

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 15:04:38 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 15:04:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ra7QW-0008F3-Cz; Mon, 12 Dec 2011 15:04:24 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jan.kiszka@siemens.com>) id 1Ra7QV-0008Ey-C2
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 15:04:23 +0000
X-Env-Sender: jan.kiszka@siemens.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1323702171!50435311!1
X-Originating-IP: [192.35.17.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjM1LjE3LjI4ID0+IDI5NDM2MA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9124 invoked from network); 12 Dec 2011 15:02:52 -0000
Received: from goliath.siemens.de (HELO goliath.siemens.de) (192.35.17.28)
	by server-6.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Dec 2011 15:02:52 -0000
Received: from mail1.siemens.de (localhost [127.0.0.1])
	by goliath.siemens.de (8.13.6/8.13.6) with ESMTP id pBCF3N1x018739;
	Mon, 12 Dec 2011 16:03:24 +0100
Received: from mchn199C.mchp.siemens.de ([139.25.109.49])
	by mail1.siemens.de (8.13.6/8.13.6) with ESMTP id pBCF3Mmj008607;
	Mon, 12 Dec 2011 16:03:22 +0100
Message-ID: <4EE617BA.4030102@siemens.com>
Date: Mon, 12 Dec 2011 16:03:22 +0100
From: Jan Kiszka <jan.kiszka@siemens.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de;
	rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12
	Mnenhy/0.7.5.666
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <1323467645-24271-1-git-send-email-anthony.perard@citrix.com>
	<1323467645-24271-6-git-send-email-anthony.perard@citrix.com>
	<4EE3382D.80903@web.de>
	<alpine.DEB.2.00.1112121259180.3517@kaball-desktop>
	<4EE609BF.1070307@siemens.com>
	<alpine.DEB.2.00.1112121438410.3517@kaball-desktop>
In-Reply-To: <alpine.DEB.2.00.1112121438410.3517@kaball-desktop>
Cc: Anthony Perard <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	QEMU-devel <qemu-devel@nongnu.org>
Subject: Re: [Xen-devel] [PATCH V2 5/5] vga-cirrus: Workaround during
 restore when using Xen.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 2011-12-12 15:41, Stefano Stabellini wrote:
> On Mon, 12 Dec 2011, Jan Kiszka wrote:
>> On 2011-12-12 14:18, Stefano Stabellini wrote:
>>> On Sat, 10 Dec 2011, Jan Kiszka wrote:
>>>> On 2011-12-09 22:54, Anthony PERARD wrote:
>>>>> During the initialisation of the machine at restore time, the access to the
>>>>> VRAM will fail because QEMU does not know yet the right guest address to map,
>>>>> so the vram_ptr is NULL.
>>>>>
>>>>> So this patch avoid using a NULL pointer during initialisation, and try to get
>>>>> another vram_ptr if the call failed the first time.
>>>>>
>>>>> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
>>>>> ---
>>>>>  hw/cirrus_vga.c |   16 +++++++++++++---
>>>>>  1 files changed, 13 insertions(+), 3 deletions(-)
>>>>>
>>>>> diff --git a/hw/cirrus_vga.c b/hw/cirrus_vga.c
>>>>> index c7e365b..2e049c9 100644
>>>>> --- a/hw/cirrus_vga.c
>>>>> +++ b/hw/cirrus_vga.c
>>>>> @@ -32,6 +32,7 @@
>>>>>  #include "console.h"
>>>>>  #include "vga_int.h"
>>>>>  #include "loader.h"
>>>>> +#include "sysemu.h"
>>>>>  
>>>>>  /*
>>>>>   * TODO:
>>>>> @@ -2696,6 +2697,13 @@ static int cirrus_post_load(void *opaque, int version_id)
>>>>>      s->vga.gr[0x01] = s->cirrus_shadow_gr1 & 0x0f;
>>>>>  
>>>>>      cirrus_update_memory_access(s);
>>>>> +    if (!s->vga.vram_ptr) {
>>>>> +        /* At this point vga.vram_ptr can be invalid on Xen because we need to
>>>>> +         * know the position of the videoram in the guest physical address space in
>>>>> +         * order to be able to map it. After cirrus_update_memory_access we do know
>>>>> +         * where the videoram is, so let's map it now. */
>>>>> +        s->vga.vram_ptr = memory_region_get_ram_ptr(&s->vga.vram);
>>>>> +    }
>>>>>      /* force refresh */
>>>>>      s->vga.graphic_mode = -1;
>>>>>      cirrus_update_bank_ptr(s, 0);
>>>>> @@ -2784,9 +2792,11 @@ static void cirrus_reset(void *opaque)
>>>>>      }
>>>>>      s->vga.cr[0x27] = s->device_id;
>>>>>  
>>>>> -    /* Win2K seems to assume that the pattern buffer is at 0xff
>>>>> -       initially ! */
>>>>> -    memset(s->vga.vram_ptr, 0xff, s->real_vram_size);
>>>>> +    if (!runstate_check(RUN_STATE_PREMIGRATE)) {
>>>>> +        /* Win2K seems to assume that the pattern buffer is at 0xff
>>>>> +           initially ! */
>>>>> +        memset(s->vga.vram_ptr, 0xff, s->real_vram_size);
>>>>> +    }
>>>>>  
>>>>>      s->cirrus_hidden_dac_lockindex = 5;
>>>>>      s->cirrus_hidden_dac_data = 0;
>>>>
>>>> Is there really no way to fix this properly in the Xen layer?
>>>
>>> We thought about this issue for some time but we couldn't come up with
>>> anything better.
>>> To summarize the problem:
>>>
>>> - on restore the videoram has already been loaded in the guest physical
>>>   address space by Xen;
>>>
>>> - we don't know exactly where it is yet, because it has been loaded at
>>>   the *last* address it was mapped to (see map_linear_vram_bank that
>>>   moves the videoram);
>>>
>>> - we want to avoid allocating the videoram twice (actually the second
>>>   allocation would fail because of memory constraints);
>>>
>>>
>>>
>>> So the solution (I acknowledge that it looks more like an hack than a
>>> solution) is:
>>>
>>> - wait for cirrus to load its state so that we know where the videoram
>>>   is;
>>
>> Why can't you store this information in some additional Xen-specific
>> vmstate? The fact that memory_region_get_ram_ptr has to return NULL
>> looks bogus to me. It's against the QEMU semantics. Other devices may
>> only be fine as they are not (yet) used with Xen.
> 
> Unfortunately that cannot work because the allocation is done by
> vga_common_init before any state has been loaded.
> So even if we saved the physmap QLIST in a vmstate record, it wouldn't
> be available yet when vga_common_init tries to allocate the memory.

If you run two VMs with identical setup, one from cold start to
operational mode, the other into an incoming migration, the guest
physical memory layout the host sees is different? Hmm, maybe if you
reorder devices in the command line.

Really, I think this is something inherently incompatible with the
current memory API. If Xen has this unfixable special "requirement"
(it's rather a design issue IMHO), adjust the API and adapt all devices.
Hot-fixing only a single one this way is no good idea long term.

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 15:16:39 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 15: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.xensource.com>)
	id 1Ra7c6-0000AN-KU; Mon, 12 Dec 2011 15:16:22 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Ra7c5-0000AI-CP
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 15:16:21 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1323702906!51834046!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12639 invoked from network); 12 Dec 2011 15:15:07 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-13.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 12 Dec 2011 15:15:07 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 12 Dec 2011 15:15:29 +0000
Message-Id: <4EE628D80200007800066F9E@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 12 Dec 2011 15:16:24 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "dbrace" <dab@hp.com>
References: <4EDFDF0D.2020104@hp.com>
In-Reply-To: <4EDFDF0D.2020104@hp.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] kmap_atomic issue with SLES11SP1 32bit XEN driver
 code
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 07.12.11 at 22:47, dbrace <dab@hp.com> wrote:
> kernel: Linux 360 2.6.32.12-0.7-xen #1 SMP 2010-05-20 11:14:20 +0200 
> i686 i686 i386 GNU/Linux

Pretty outdated.

> I am having issues with some code that uses kmap_atomic(). I am getting:
> 
> BUG: unable to handle kernel paging request at 23a1a000 (which is the 
> address returned from kmap_atomic().)

For a valid high memory page this is surely not being returned by
kmap_atomic(), so we have to assume that what you started with is
the address of a low memory one.

> The same code works when running on non-XEN 32bit kernels so I am  
> wondering why this does not work under
> XEN kernels. Is there a different approach that I need to take for 32bit 
> XEN kernels?

No, but ...

> I really only need to do this code segment if the memory address is a 
> high memory address. Is there a MACRO or function
> that can help me determine this?

PageHighMem().

> Here is a code snippet:
> 
>                  void *linux_vaddr = NULL;       /* kmapped temporary 
> virtual address */
>                  int linux_page_offset = 0;      /* offset in page */
>                  int count = 0;                  /* bytes left to 
> transfer */
>                  int left = byte_count;          /* number of bytes left 
> to transfer */
>                  int memcpysize = 0;             /* current size to 
> transfer */
>                  struct page *linux_page = NULL; /* calculated page */
>                  int kmap_flags = 0;
> 
>                  linux_page = __pfn_to_page(physical_address >> PAGE_SHIFT);

... without knowing where you got physical_address from it's impossible
to tell whether your problem is that under Xen physical and machine
(sometimes called "bus") addresses being distinct (end hence you're
possibly lacking a translation between the two).

Jan

>                  linux_page_offset = (physical_address & 
> 0x0000000000000FFFULL);
>                  memcpysize =  min((PAGE_SIZE - linux_page_offset), left);
> 
>                  kmap_flags = KM_USER0;
> 
>                  linux_vaddr = kmap_atomic(linux_page, kmap_flags) + 
> linux_page_offset;
> 
>                  printk("%s: called kmap_atomic, "
>                          "calling memcpy linux_vaddr = 0x%x virt_address 
> = 0x%x count = 0x%x\n",
>                          __func__, linux_vaddr, virt_address, count);
>                  /*
>                   * Either need to copy to a kmapped destination
>                   * or a kmapped source.
>                   */
>                  if (type == 0) // Write to s/g element, dest virtual 
> addr was known.
>                          memcpy((void *)virt_address+count, (void 
> *)linux_vaddr, memcpysize);
>                  else // Source virt. address was known.
>                          memcpy((void *)linux_vaddr, (void 
> *)virt_address+count, memcpysize);
> 
>                  printk("OS_Linux32_Xfer_SG_Page: calling kunmap_atomic, "
>                          "calling memcpy linux_vaddr = 0x%lx\n", 
> linux_vaddr);
> 
>                  kunmap_atomic(linux_vaddr, kmap_flags);
> 
> 
> -- 
> Don Brace
> SPSN Linux Development
> Hewlett-Packard Company
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com 
> http://lists.xensource.com/xen-devel 




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 15:16:39 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 15: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.xensource.com>)
	id 1Ra7c6-0000AN-KU; Mon, 12 Dec 2011 15:16:22 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Ra7c5-0000AI-CP
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 15:16:21 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1323702906!51834046!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12639 invoked from network); 12 Dec 2011 15:15:07 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-13.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 12 Dec 2011 15:15:07 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 12 Dec 2011 15:15:29 +0000
Message-Id: <4EE628D80200007800066F9E@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 12 Dec 2011 15:16:24 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "dbrace" <dab@hp.com>
References: <4EDFDF0D.2020104@hp.com>
In-Reply-To: <4EDFDF0D.2020104@hp.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] kmap_atomic issue with SLES11SP1 32bit XEN driver
 code
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 07.12.11 at 22:47, dbrace <dab@hp.com> wrote:
> kernel: Linux 360 2.6.32.12-0.7-xen #1 SMP 2010-05-20 11:14:20 +0200 
> i686 i686 i386 GNU/Linux

Pretty outdated.

> I am having issues with some code that uses kmap_atomic(). I am getting:
> 
> BUG: unable to handle kernel paging request at 23a1a000 (which is the 
> address returned from kmap_atomic().)

For a valid high memory page this is surely not being returned by
kmap_atomic(), so we have to assume that what you started with is
the address of a low memory one.

> The same code works when running on non-XEN 32bit kernels so I am  
> wondering why this does not work under
> XEN kernels. Is there a different approach that I need to take for 32bit 
> XEN kernels?

No, but ...

> I really only need to do this code segment if the memory address is a 
> high memory address. Is there a MACRO or function
> that can help me determine this?

PageHighMem().

> Here is a code snippet:
> 
>                  void *linux_vaddr = NULL;       /* kmapped temporary 
> virtual address */
>                  int linux_page_offset = 0;      /* offset in page */
>                  int count = 0;                  /* bytes left to 
> transfer */
>                  int left = byte_count;          /* number of bytes left 
> to transfer */
>                  int memcpysize = 0;             /* current size to 
> transfer */
>                  struct page *linux_page = NULL; /* calculated page */
>                  int kmap_flags = 0;
> 
>                  linux_page = __pfn_to_page(physical_address >> PAGE_SHIFT);

... without knowing where you got physical_address from it's impossible
to tell whether your problem is that under Xen physical and machine
(sometimes called "bus") addresses being distinct (end hence you're
possibly lacking a translation between the two).

Jan

>                  linux_page_offset = (physical_address & 
> 0x0000000000000FFFULL);
>                  memcpysize =  min((PAGE_SIZE - linux_page_offset), left);
> 
>                  kmap_flags = KM_USER0;
> 
>                  linux_vaddr = kmap_atomic(linux_page, kmap_flags) + 
> linux_page_offset;
> 
>                  printk("%s: called kmap_atomic, "
>                          "calling memcpy linux_vaddr = 0x%x virt_address 
> = 0x%x count = 0x%x\n",
>                          __func__, linux_vaddr, virt_address, count);
>                  /*
>                   * Either need to copy to a kmapped destination
>                   * or a kmapped source.
>                   */
>                  if (type == 0) // Write to s/g element, dest virtual 
> addr was known.
>                          memcpy((void *)virt_address+count, (void 
> *)linux_vaddr, memcpysize);
>                  else // Source virt. address was known.
>                          memcpy((void *)linux_vaddr, (void 
> *)virt_address+count, memcpysize);
> 
>                  printk("OS_Linux32_Xfer_SG_Page: calling kunmap_atomic, "
>                          "calling memcpy linux_vaddr = 0x%lx\n", 
> linux_vaddr);
> 
>                  kunmap_atomic(linux_vaddr, kmap_flags);
> 
> 
> -- 
> Don Brace
> SPSN Linux Development
> Hewlett-Packard Company
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com 
> http://lists.xensource.com/xen-devel 




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 15:16:50 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 15:16:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ra7cI-0000BZ-7e; Mon, 12 Dec 2011 15:16:34 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Ra7cG-0000Ax-6N
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 15:16:32 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1323702935!7148193!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDc4NQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11305 invoked from network); 12 Dec 2011 15:15:39 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Dec 2011 15:15:39 -0000
X-IronPort-AV: E=Sophos;i="4.71,339,1320624000"; 
   d="scan'208";a="9420375"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Dec 2011 15:15:35 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 12 Dec 2011 15:15:35 +0000
Date: Mon, 12 Dec 2011 15:17:09 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1323697723.20077.212.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1112121453050.3517@kaball-desktop>
References: <1323108621-22654-1-git-send-email-ian.jackson@eu.citrix.com>
	<1323108621-22654-16-git-send-email-ian.jackson@eu.citrix.com>
	<alpine.DEB.2.00.1112091558300.3517@kaball-desktop>
	<20194.22539.574524.956955@mariner.uk.xensource.com> 
	<1323463293.20936.11.camel@dagon.hellion.org.uk>
	<20197.59428.699013.507183@mariner.uk.xensource.com>
	<1323692225.20077.183.camel@zakaz.uk.xensource.com>
	<20197.62462.189827.239656@mariner.uk.xensource.com>
	<1323697723.20077.212.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 15/15] libxl: New event generation API
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 12 Dec 2011, Ian Campbell wrote:
> On Mon, 2011-12-12 at 12:30 +0000, Ian Jackson wrote:
> > Ian Campbell writes ("Re: [Xen-devel] [PATCH 15/15] libxl: New event generation API"):
> > > On Mon, 2011-12-12 at 11:40 +0000, Ian Jackson wrote:
> > > > Well, we have to have an internal version because we don't want to
> > > > call GC_INIT again, obviously.
> > > 
> > > In this case it would take a ctx not a gc and it's ok and expected for
> > > libxl a function calling another libxl function to end up with another
> > > gc in the inner function (it happens all the time).
> > 
> > This is not allowed in functions which might generate events (ie,
> > which might call libxl__event_occurred), because the application's
> > event callback will be called at an unexpected point in libxl's
> > execution.  This has three problems:
> > 
> >  * There is a reentrancy hazard.  Exactly whether this is a problem in
> >    a specific case is difficult to analyse; hence the recording of
> >    pending callbacks in the gc, so that they can be delayed until the
> >    gc is freed.
> > 
> >  * The application's callbacks will be called with the libxl ctx
> >    locked.  This might result in deadlock.
> > 
> >  * The  application's callbacks  might be  called in  the  wrong order
> >    because the  inner gc (containing  later events) is  unwound before
> >    the outer gc (containing earlier events).
> > 
> > In general this means that functions which lock the ctx must not
> > allocate an inner gc.

this is quite an important limitation and change in behaviour!


> I was a little surprised when I looked when writing my previous reply
> that LIBXL_INITGC doesn't actually take nesting into account. I had
> expected that LIBXL_INITGC would return (or somehow chain) the existing
> GC when libxl is calling itself such that all the freeing work (and now
> callbacks) would only happen when exiting the final frame.
> 
> It's probably not so important for memory allocation cleanup but it
> would be a semantically useful change for the callbacks if we could
> arrange for them to happen only on final exit of the library -- exactly
> because of the difficulty of reasoning about things otherwise. Alas I
> can't think of a good way to do this since the ctx can be shared, thread
> local storage would be one or libxl__gc_owner could return a special
> "nested ctx" instead of the real outer ctx, but, ick.

I think that using TLS to increase/decrease a nesting counter would OK
in this case. We could have a libxl__enter and a libxl__exit function
that take care it this.

Modifying libxl__gc_owner could lead to errors because it doesn't handle
the case in which an externally visible function calls another
externally visible function: libxl__gc_owner wouldn't even be called in
this case.



> If we can't figure a way round this then the restriction about libxl not
> calling into itself via its own public interfaces should be documented
> (apologies if I've simply missed that bit, I did go and look because I
> thought I recalled seeing it, but I didn't find it, I think I was
> thinking about the comment associated with the CTX lock). In particular
> if the restriction is that you cannot call public API functions which
> might generate events from within libxl then those functions need to be
> clearly annotated as potentially generating events.

Right.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 15:16:50 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 15:16:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ra7cI-0000BZ-7e; Mon, 12 Dec 2011 15:16:34 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Ra7cG-0000Ax-6N
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 15:16:32 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1323702935!7148193!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDc4NQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11305 invoked from network); 12 Dec 2011 15:15:39 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Dec 2011 15:15:39 -0000
X-IronPort-AV: E=Sophos;i="4.71,339,1320624000"; 
   d="scan'208";a="9420375"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Dec 2011 15:15:35 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 12 Dec 2011 15:15:35 +0000
Date: Mon, 12 Dec 2011 15:17:09 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1323697723.20077.212.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1112121453050.3517@kaball-desktop>
References: <1323108621-22654-1-git-send-email-ian.jackson@eu.citrix.com>
	<1323108621-22654-16-git-send-email-ian.jackson@eu.citrix.com>
	<alpine.DEB.2.00.1112091558300.3517@kaball-desktop>
	<20194.22539.574524.956955@mariner.uk.xensource.com> 
	<1323463293.20936.11.camel@dagon.hellion.org.uk>
	<20197.59428.699013.507183@mariner.uk.xensource.com>
	<1323692225.20077.183.camel@zakaz.uk.xensource.com>
	<20197.62462.189827.239656@mariner.uk.xensource.com>
	<1323697723.20077.212.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 15/15] libxl: New event generation API
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 12 Dec 2011, Ian Campbell wrote:
> On Mon, 2011-12-12 at 12:30 +0000, Ian Jackson wrote:
> > Ian Campbell writes ("Re: [Xen-devel] [PATCH 15/15] libxl: New event generation API"):
> > > On Mon, 2011-12-12 at 11:40 +0000, Ian Jackson wrote:
> > > > Well, we have to have an internal version because we don't want to
> > > > call GC_INIT again, obviously.
> > > 
> > > In this case it would take a ctx not a gc and it's ok and expected for
> > > libxl a function calling another libxl function to end up with another
> > > gc in the inner function (it happens all the time).
> > 
> > This is not allowed in functions which might generate events (ie,
> > which might call libxl__event_occurred), because the application's
> > event callback will be called at an unexpected point in libxl's
> > execution.  This has three problems:
> > 
> >  * There is a reentrancy hazard.  Exactly whether this is a problem in
> >    a specific case is difficult to analyse; hence the recording of
> >    pending callbacks in the gc, so that they can be delayed until the
> >    gc is freed.
> > 
> >  * The application's callbacks will be called with the libxl ctx
> >    locked.  This might result in deadlock.
> > 
> >  * The  application's callbacks  might be  called in  the  wrong order
> >    because the  inner gc (containing  later events) is  unwound before
> >    the outer gc (containing earlier events).
> > 
> > In general this means that functions which lock the ctx must not
> > allocate an inner gc.

this is quite an important limitation and change in behaviour!


> I was a little surprised when I looked when writing my previous reply
> that LIBXL_INITGC doesn't actually take nesting into account. I had
> expected that LIBXL_INITGC would return (or somehow chain) the existing
> GC when libxl is calling itself such that all the freeing work (and now
> callbacks) would only happen when exiting the final frame.
> 
> It's probably not so important for memory allocation cleanup but it
> would be a semantically useful change for the callbacks if we could
> arrange for them to happen only on final exit of the library -- exactly
> because of the difficulty of reasoning about things otherwise. Alas I
> can't think of a good way to do this since the ctx can be shared, thread
> local storage would be one or libxl__gc_owner could return a special
> "nested ctx" instead of the real outer ctx, but, ick.

I think that using TLS to increase/decrease a nesting counter would OK
in this case. We could have a libxl__enter and a libxl__exit function
that take care it this.

Modifying libxl__gc_owner could lead to errors because it doesn't handle
the case in which an externally visible function calls another
externally visible function: libxl__gc_owner wouldn't even be called in
this case.



> If we can't figure a way round this then the restriction about libxl not
> calling into itself via its own public interfaces should be documented
> (apologies if I've simply missed that bit, I did go and look because I
> thought I recalled seeing it, but I didn't find it, I think I was
> thinking about the comment associated with the CTX lock). In particular
> if the restriction is that you cannot call public API functions which
> might generate events from within libxl then those functions need to be
> clearly annotated as potentially generating events.

Right.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 15:25:52 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 15:25:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ra7l3-0000Zs-9y; Mon, 12 Dec 2011 15:25:37 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Ra7l1-0000Zm-NE
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 15:25:36 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1323703438!56955922!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29057 invoked from network); 12 Dec 2011 15:23:58 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-2.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 12 Dec 2011 15:23:58 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 12 Dec 2011 15:24:46 +0000
Message-Id: <4EE62B040200007800066FB6@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 12 Dec 2011 15:25:40 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part38179DE4.1__="
Cc: Joerg Roedel <joerg.roedel@amd.com>
Subject: [Xen-devel] [PATCH] x86,
	amd: Disable GartTlbWlkErr when BIOS forgets it
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__Part38179DE4.1__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

This patch disables GartTlbWlk errors on AMD Fam10h CPUs if the BIOS
forgets to do is (or is just too old). Letting these errors enabled
can cause a sync-flood on the CPU causing a reboot.

The AMD BKDG recommends disabling GART TLB Wlk Error completely.

Based on a Linux patch from Joerg Roedel <joerg.roedel@amd.com>; see e.g.
https://git.kernel.org/?p=3Dlinux/kernel/git/torvalds/linux.git;a=3Dpatch;h=
=3D5bbc097d890409d8eff4e3f1d26f11a9d6b7c07e=20

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- 2011-11-23.orig/xen/arch/x86/cpu/mcheck/amd_f10.c	2011-12-05 =
11:38:34.000000000 +0100
+++ 2011-11-23/xen/arch/x86/cpu/mcheck/amd_f10.c	2011-12-05 =
11:17:03.000000000 +0100
@@ -46,6 +46,7 @@
 #include <asm/msr.h>
=20
 #include "mce.h"
+#include "mce_quirks.h"
 #include "x86_mca.h"
=20
=20
@@ -91,9 +92,14 @@ amd_f10_handler(struct mc_info *mi, uint
 /* AMD Family10 machine check */
 enum mcheck_type amd_f10_mcheck_init(struct cpuinfo_x86 *c)
 {=20
+	enum mcequirk_amd_flags quirkflag =3D mcequirk_lookup_amd_quirkdata=
(c);
+
 	if (amd_k8_mcheck_init(c) =3D=3D mcheck_none)
 		return mcheck_none;
=20
+	if (quirkflag =3D=3D MCEQUIRK_F10_GART)
+		mcequirk_amd_apply(quirkflag);
+
 	x86_mce_callback_register(amd_f10_handler);
=20
 	return mcheck_amd_famXX;
--- 2011-11-23.orig/xen/arch/x86/cpu/mcheck/mce_amd_quirks.c	2011-12-05 =
11:38:34.000000000 +0100
+++ 2011-11-23/xen/arch/x86/cpu/mcheck/mce_amd_quirks.c	2011-12-05 =
11:41:00.000000000 +0100
@@ -29,6 +29,8 @@ static const struct mce_quirkdata mce_am
 	  MCEQUIRK_K7_BANK0 },
 	{ 0xf /* cpu family */, ANY /* all models */, ANY /* all steppings =
*/,
 	  MCEQUIRK_K8_GART },
+	{ 0x10 /* cpu family */, ANY /* all models */, ANY /* all =
steppings */,
+	  MCEQUIRK_F10_GART },
 };
=20
 enum mcequirk_amd_flags
@@ -54,6 +56,8 @@ mcequirk_lookup_amd_quirkdata(struct cpu
=20
 int mcequirk_amd_apply(enum mcequirk_amd_flags flags)
 {
+	u64 val;
+
 	switch (flags) {
 	case MCEQUIRK_K7_BANK0:
 		return 1; /* first bank */
@@ -67,6 +71,10 @@ int mcequirk_amd_apply(enum mcequirk_amd
 		wrmsrl(MSR_IA32_MC4_CTL, ~(1ULL << 10));
 		wrmsrl(MSR_IA32_MC4_STATUS, 0ULL);
 		break;
+	case MCEQUIRK_F10_GART:
+		if (rdmsr_safe(MSR_AMD64_MCx_MASK(4), val) =3D=3D 0)
+			wrmsr_safe(MSR_AMD64_MCx_MASK(4), val | (1 << =
10));
+		break;
 	}
=20
 	return 0;
--- 2011-11-23.orig/xen/arch/x86/cpu/mcheck/mce_quirks.h	2011-12-05 =
11:38:34.000000000 +0100
+++ 2011-11-23/xen/arch/x86/cpu/mcheck/mce_quirks.h	2011-12-05 =
11:11:45.000000000 +0100
@@ -33,8 +33,9 @@ struct mce_quirkdata {
  */
=20
 enum mcequirk_amd_flags {
-	MCEQUIRK_K7_BANK0 =3D 0x1,
-	MCEQUIRK_K8_GART =3D 0x2,
+	MCEQUIRK_K7_BANK0 =3D 1,
+	MCEQUIRK_K8_GART,
+	MCEQUIRK_F10_GART
 };
=20
 enum mcequirk_intel_flags {
--- 2011-11-23.orig/xen/include/asm-x86/msr-index.h	2011-12-05 =
11:38:34.000000000 +0100
+++ 2011-11-23/xen/include/asm-x86/msr-index.h	2011-12-05 11:06:39.0000000=
00 +0100
@@ -98,6 +98,8 @@
 #define CMCI_EN 			(1UL<<30)
 #define CMCI_THRESHOLD_MASK		0x7FFF
=20
+#define MSR_AMD64_MC0_MASK		0xc0010044
+
 #define MSR_IA32_MC1_CTL		0x00000404
 #define MSR_IA32_MC1_CTL2		0x00000281
 #define MSR_IA32_MC1_STATUS		0x00000405
@@ -151,6 +153,8 @@
 #define MSR_IA32_MCx_ADDR(x)		(MSR_IA32_MC0_ADDR + 4*(x))
 #define MSR_IA32_MCx_MISC(x)		(MSR_IA32_MC0_MISC + 4*(x))=20
=20
+#define MSR_AMD64_MCx_MASK(x)		(MSR_AMD64_MC0_MASK + (x))
+
 #define MSR_P6_PERFCTR0			0x000000c1
 #define MSR_P6_PERFCTR1			0x000000c2
 #define MSR_P6_EVNTSEL0			0x00000186




--=__Part38179DE4.1__=
Content-Type: text/plain; name="amd-fam10-gart-tlb-walk-err.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="amd-fam10-gart-tlb-walk-err.patch"

x86, amd: Disable GartTlbWlkErr when BIOS forgets it=0A=0AThis patch =
disables GartTlbWlk errors on AMD Fam10h CPUs if the BIOS=0Aforgets to do =
is (or is just too old). Letting these errors enabled=0Acan cause a =
sync-flood on the CPU causing a reboot.=0A=0AThe AMD BKDG recommends =
disabling GART TLB Wlk Error completely.=0A=0ABased on a Linux patch from =
Joerg Roedel <joerg.roedel@amd.com>; see e.g.=0Ahttps://git.kernel.org/?p=
=3Dlinux/kernel/git/torvalds/linux.git;a=3Dpatch;h=3D5bbc097d890409d8eff4e3=
f1d26f11a9d6b7c07e=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=0A=
=0A--- 2011-11-23.orig/xen/arch/x86/cpu/mcheck/amd_f10.c	2011-12-05 =
11:38:34.000000000 +0100=0A+++ 2011-11-23/xen/arch/x86/cpu/mcheck/amd_f10.c=
	2011-12-05 11:17:03.000000000 +0100=0A@@ -46,6 +46,7 @@=0A =
#include <asm/msr.h>=0A =0A #include "mce.h"=0A+#include "mce_quirks.h"=0A =
#include "x86_mca.h"=0A =0A =0A@@ -91,9 +92,14 @@ amd_f10_handler(struct =
mc_info *mi, uint=0A /* AMD Family10 machine check */=0A enum mcheck_type =
amd_f10_mcheck_init(struct cpuinfo_x86 *c)=0A { =0A+	enum mcequirk_amd_f=
lags quirkflag =3D mcequirk_lookup_amd_quirkdata(c);=0A+=0A 	if =
(amd_k8_mcheck_init(c) =3D=3D mcheck_none)=0A 		return mcheck_none;=
=0A =0A+	if (quirkflag =3D=3D MCEQUIRK_F10_GART)=0A+		=
mcequirk_amd_apply(quirkflag);=0A+=0A 	x86_mce_callback_register(amd_f10_h=
andler);=0A =0A 	return mcheck_amd_famXX;=0A--- 2011-11-23.orig/xen/=
arch/x86/cpu/mcheck/mce_amd_quirks.c	2011-12-05 11:38:34.000000000 =
+0100=0A+++ 2011-11-23/xen/arch/x86/cpu/mcheck/mce_amd_quirks.c	2011-12-05 =
11:41:00.000000000 +0100=0A@@ -29,6 +29,8 @@ static const struct mce_quirkd=
ata mce_am=0A 	  MCEQUIRK_K7_BANK0 },=0A 	{ 0xf /* cpu family */, =
ANY /* all models */, ANY /* all steppings */,=0A 	  MCEQUIRK_K8_GART =
},=0A+	{ 0x10 /* cpu family */, ANY /* all models */, ANY /* all =
steppings */,=0A+	  MCEQUIRK_F10_GART },=0A };=0A =0A enum mcequirk_a=
md_flags=0A@@ -54,6 +56,8 @@ mcequirk_lookup_amd_quirkdata(struct cpu=0A =
=0A int mcequirk_amd_apply(enum mcequirk_amd_flags flags)=0A {=0A+	=
u64 val;=0A+=0A 	switch (flags) {=0A 	case MCEQUIRK_K7_BANK0:=0A =
		return 1; /* first bank */=0A@@ -67,6 +71,10 @@ int =
mcequirk_amd_apply(enum mcequirk_amd=0A 		wrmsrl(MSR_IA32_MC4=
_CTL, ~(1ULL << 10));=0A 		wrmsrl(MSR_IA32_MC4_STATUS, =
0ULL);=0A 		break;=0A+	case MCEQUIRK_F10_GART:=0A+		=
if (rdmsr_safe(MSR_AMD64_MCx_MASK(4), val) =3D=3D 0)=0A+			=
wrmsr_safe(MSR_AMD64_MCx_MASK(4), val | (1 << 10));=0A+		break;=0A 	=
}=0A =0A 	return 0;=0A--- 2011-11-23.orig/xen/arch/x86/cpu/mcheck/mce=
_quirks.h	2011-12-05 11:38:34.000000000 +0100=0A+++ 2011-11-23/xen/ar=
ch/x86/cpu/mcheck/mce_quirks.h	2011-12-05 11:11:45.000000000 +0100=0A@@ =
-33,8 +33,9 @@ struct mce_quirkdata {=0A  */=0A =0A enum mcequirk_amd_flags=
 {=0A-	MCEQUIRK_K7_BANK0 =3D 0x1,=0A-	MCEQUIRK_K8_GART =3D 0x2,=0A+	=
MCEQUIRK_K7_BANK0 =3D 1,=0A+	MCEQUIRK_K8_GART,=0A+	MCEQUIRK_F10_GART=
=0A };=0A =0A enum mcequirk_intel_flags {=0A--- 2011-11-23.orig/xen/include=
/asm-x86/msr-index.h	2011-12-05 11:38:34.000000000 +0100=0A+++ =
2011-11-23/xen/include/asm-x86/msr-index.h	2011-12-05 11:06:39.0000000=
00 +0100=0A@@ -98,6 +98,8 @@=0A #define CMCI_EN 			=
(1UL<<30)=0A #define CMCI_THRESHOLD_MASK		0x7FFF=0A =
=0A+#define MSR_AMD64_MC0_MASK		0xc0010044=0A+=0A #define =
MSR_IA32_MC1_CTL		0x00000404=0A #define MSR_IA32_MC1_CTL2		=
0x00000281=0A #define MSR_IA32_MC1_STATUS		0x00000405=0A@@ =
-151,6 +153,8 @@=0A #define MSR_IA32_MCx_ADDR(x)		(MSR_IA32_M=
C0_ADDR + 4*(x))=0A #define MSR_IA32_MCx_MISC(x)		(MSR_IA32_M=
C0_MISC + 4*(x)) =0A =0A+#define MSR_AMD64_MCx_MASK(x)		(MSR_AMD64_=
MC0_MASK + (x))=0A+=0A #define MSR_P6_PERFCTR0			0x000000c1=
=0A #define MSR_P6_PERFCTR1			0x000000c2=0A #define =
MSR_P6_EVNTSEL0			0x00000186=0A
--=__Part38179DE4.1__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--=__Part38179DE4.1__=--


From xen-devel-bounces@lists.xensource.com Mon Dec 12 15:25:52 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 15:25:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ra7l3-0000Zs-9y; Mon, 12 Dec 2011 15:25:37 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Ra7l1-0000Zm-NE
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 15:25:36 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1323703438!56955922!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29057 invoked from network); 12 Dec 2011 15:23:58 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-2.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 12 Dec 2011 15:23:58 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 12 Dec 2011 15:24:46 +0000
Message-Id: <4EE62B040200007800066FB6@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 12 Dec 2011 15:25:40 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part38179DE4.1__="
Cc: Joerg Roedel <joerg.roedel@amd.com>
Subject: [Xen-devel] [PATCH] x86,
	amd: Disable GartTlbWlkErr when BIOS forgets it
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__Part38179DE4.1__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

This patch disables GartTlbWlk errors on AMD Fam10h CPUs if the BIOS
forgets to do is (or is just too old). Letting these errors enabled
can cause a sync-flood on the CPU causing a reboot.

The AMD BKDG recommends disabling GART TLB Wlk Error completely.

Based on a Linux patch from Joerg Roedel <joerg.roedel@amd.com>; see e.g.
https://git.kernel.org/?p=3Dlinux/kernel/git/torvalds/linux.git;a=3Dpatch;h=
=3D5bbc097d890409d8eff4e3f1d26f11a9d6b7c07e=20

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- 2011-11-23.orig/xen/arch/x86/cpu/mcheck/amd_f10.c	2011-12-05 =
11:38:34.000000000 +0100
+++ 2011-11-23/xen/arch/x86/cpu/mcheck/amd_f10.c	2011-12-05 =
11:17:03.000000000 +0100
@@ -46,6 +46,7 @@
 #include <asm/msr.h>
=20
 #include "mce.h"
+#include "mce_quirks.h"
 #include "x86_mca.h"
=20
=20
@@ -91,9 +92,14 @@ amd_f10_handler(struct mc_info *mi, uint
 /* AMD Family10 machine check */
 enum mcheck_type amd_f10_mcheck_init(struct cpuinfo_x86 *c)
 {=20
+	enum mcequirk_amd_flags quirkflag =3D mcequirk_lookup_amd_quirkdata=
(c);
+
 	if (amd_k8_mcheck_init(c) =3D=3D mcheck_none)
 		return mcheck_none;
=20
+	if (quirkflag =3D=3D MCEQUIRK_F10_GART)
+		mcequirk_amd_apply(quirkflag);
+
 	x86_mce_callback_register(amd_f10_handler);
=20
 	return mcheck_amd_famXX;
--- 2011-11-23.orig/xen/arch/x86/cpu/mcheck/mce_amd_quirks.c	2011-12-05 =
11:38:34.000000000 +0100
+++ 2011-11-23/xen/arch/x86/cpu/mcheck/mce_amd_quirks.c	2011-12-05 =
11:41:00.000000000 +0100
@@ -29,6 +29,8 @@ static const struct mce_quirkdata mce_am
 	  MCEQUIRK_K7_BANK0 },
 	{ 0xf /* cpu family */, ANY /* all models */, ANY /* all steppings =
*/,
 	  MCEQUIRK_K8_GART },
+	{ 0x10 /* cpu family */, ANY /* all models */, ANY /* all =
steppings */,
+	  MCEQUIRK_F10_GART },
 };
=20
 enum mcequirk_amd_flags
@@ -54,6 +56,8 @@ mcequirk_lookup_amd_quirkdata(struct cpu
=20
 int mcequirk_amd_apply(enum mcequirk_amd_flags flags)
 {
+	u64 val;
+
 	switch (flags) {
 	case MCEQUIRK_K7_BANK0:
 		return 1; /* first bank */
@@ -67,6 +71,10 @@ int mcequirk_amd_apply(enum mcequirk_amd
 		wrmsrl(MSR_IA32_MC4_CTL, ~(1ULL << 10));
 		wrmsrl(MSR_IA32_MC4_STATUS, 0ULL);
 		break;
+	case MCEQUIRK_F10_GART:
+		if (rdmsr_safe(MSR_AMD64_MCx_MASK(4), val) =3D=3D 0)
+			wrmsr_safe(MSR_AMD64_MCx_MASK(4), val | (1 << =
10));
+		break;
 	}
=20
 	return 0;
--- 2011-11-23.orig/xen/arch/x86/cpu/mcheck/mce_quirks.h	2011-12-05 =
11:38:34.000000000 +0100
+++ 2011-11-23/xen/arch/x86/cpu/mcheck/mce_quirks.h	2011-12-05 =
11:11:45.000000000 +0100
@@ -33,8 +33,9 @@ struct mce_quirkdata {
  */
=20
 enum mcequirk_amd_flags {
-	MCEQUIRK_K7_BANK0 =3D 0x1,
-	MCEQUIRK_K8_GART =3D 0x2,
+	MCEQUIRK_K7_BANK0 =3D 1,
+	MCEQUIRK_K8_GART,
+	MCEQUIRK_F10_GART
 };
=20
 enum mcequirk_intel_flags {
--- 2011-11-23.orig/xen/include/asm-x86/msr-index.h	2011-12-05 =
11:38:34.000000000 +0100
+++ 2011-11-23/xen/include/asm-x86/msr-index.h	2011-12-05 11:06:39.0000000=
00 +0100
@@ -98,6 +98,8 @@
 #define CMCI_EN 			(1UL<<30)
 #define CMCI_THRESHOLD_MASK		0x7FFF
=20
+#define MSR_AMD64_MC0_MASK		0xc0010044
+
 #define MSR_IA32_MC1_CTL		0x00000404
 #define MSR_IA32_MC1_CTL2		0x00000281
 #define MSR_IA32_MC1_STATUS		0x00000405
@@ -151,6 +153,8 @@
 #define MSR_IA32_MCx_ADDR(x)		(MSR_IA32_MC0_ADDR + 4*(x))
 #define MSR_IA32_MCx_MISC(x)		(MSR_IA32_MC0_MISC + 4*(x))=20
=20
+#define MSR_AMD64_MCx_MASK(x)		(MSR_AMD64_MC0_MASK + (x))
+
 #define MSR_P6_PERFCTR0			0x000000c1
 #define MSR_P6_PERFCTR1			0x000000c2
 #define MSR_P6_EVNTSEL0			0x00000186




--=__Part38179DE4.1__=
Content-Type: text/plain; name="amd-fam10-gart-tlb-walk-err.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="amd-fam10-gart-tlb-walk-err.patch"

x86, amd: Disable GartTlbWlkErr when BIOS forgets it=0A=0AThis patch =
disables GartTlbWlk errors on AMD Fam10h CPUs if the BIOS=0Aforgets to do =
is (or is just too old). Letting these errors enabled=0Acan cause a =
sync-flood on the CPU causing a reboot.=0A=0AThe AMD BKDG recommends =
disabling GART TLB Wlk Error completely.=0A=0ABased on a Linux patch from =
Joerg Roedel <joerg.roedel@amd.com>; see e.g.=0Ahttps://git.kernel.org/?p=
=3Dlinux/kernel/git/torvalds/linux.git;a=3Dpatch;h=3D5bbc097d890409d8eff4e3=
f1d26f11a9d6b7c07e=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=0A=
=0A--- 2011-11-23.orig/xen/arch/x86/cpu/mcheck/amd_f10.c	2011-12-05 =
11:38:34.000000000 +0100=0A+++ 2011-11-23/xen/arch/x86/cpu/mcheck/amd_f10.c=
	2011-12-05 11:17:03.000000000 +0100=0A@@ -46,6 +46,7 @@=0A =
#include <asm/msr.h>=0A =0A #include "mce.h"=0A+#include "mce_quirks.h"=0A =
#include "x86_mca.h"=0A =0A =0A@@ -91,9 +92,14 @@ amd_f10_handler(struct =
mc_info *mi, uint=0A /* AMD Family10 machine check */=0A enum mcheck_type =
amd_f10_mcheck_init(struct cpuinfo_x86 *c)=0A { =0A+	enum mcequirk_amd_f=
lags quirkflag =3D mcequirk_lookup_amd_quirkdata(c);=0A+=0A 	if =
(amd_k8_mcheck_init(c) =3D=3D mcheck_none)=0A 		return mcheck_none;=
=0A =0A+	if (quirkflag =3D=3D MCEQUIRK_F10_GART)=0A+		=
mcequirk_amd_apply(quirkflag);=0A+=0A 	x86_mce_callback_register(amd_f10_h=
andler);=0A =0A 	return mcheck_amd_famXX;=0A--- 2011-11-23.orig/xen/=
arch/x86/cpu/mcheck/mce_amd_quirks.c	2011-12-05 11:38:34.000000000 =
+0100=0A+++ 2011-11-23/xen/arch/x86/cpu/mcheck/mce_amd_quirks.c	2011-12-05 =
11:41:00.000000000 +0100=0A@@ -29,6 +29,8 @@ static const struct mce_quirkd=
ata mce_am=0A 	  MCEQUIRK_K7_BANK0 },=0A 	{ 0xf /* cpu family */, =
ANY /* all models */, ANY /* all steppings */,=0A 	  MCEQUIRK_K8_GART =
},=0A+	{ 0x10 /* cpu family */, ANY /* all models */, ANY /* all =
steppings */,=0A+	  MCEQUIRK_F10_GART },=0A };=0A =0A enum mcequirk_a=
md_flags=0A@@ -54,6 +56,8 @@ mcequirk_lookup_amd_quirkdata(struct cpu=0A =
=0A int mcequirk_amd_apply(enum mcequirk_amd_flags flags)=0A {=0A+	=
u64 val;=0A+=0A 	switch (flags) {=0A 	case MCEQUIRK_K7_BANK0:=0A =
		return 1; /* first bank */=0A@@ -67,6 +71,10 @@ int =
mcequirk_amd_apply(enum mcequirk_amd=0A 		wrmsrl(MSR_IA32_MC4=
_CTL, ~(1ULL << 10));=0A 		wrmsrl(MSR_IA32_MC4_STATUS, =
0ULL);=0A 		break;=0A+	case MCEQUIRK_F10_GART:=0A+		=
if (rdmsr_safe(MSR_AMD64_MCx_MASK(4), val) =3D=3D 0)=0A+			=
wrmsr_safe(MSR_AMD64_MCx_MASK(4), val | (1 << 10));=0A+		break;=0A 	=
}=0A =0A 	return 0;=0A--- 2011-11-23.orig/xen/arch/x86/cpu/mcheck/mce=
_quirks.h	2011-12-05 11:38:34.000000000 +0100=0A+++ 2011-11-23/xen/ar=
ch/x86/cpu/mcheck/mce_quirks.h	2011-12-05 11:11:45.000000000 +0100=0A@@ =
-33,8 +33,9 @@ struct mce_quirkdata {=0A  */=0A =0A enum mcequirk_amd_flags=
 {=0A-	MCEQUIRK_K7_BANK0 =3D 0x1,=0A-	MCEQUIRK_K8_GART =3D 0x2,=0A+	=
MCEQUIRK_K7_BANK0 =3D 1,=0A+	MCEQUIRK_K8_GART,=0A+	MCEQUIRK_F10_GART=
=0A };=0A =0A enum mcequirk_intel_flags {=0A--- 2011-11-23.orig/xen/include=
/asm-x86/msr-index.h	2011-12-05 11:38:34.000000000 +0100=0A+++ =
2011-11-23/xen/include/asm-x86/msr-index.h	2011-12-05 11:06:39.0000000=
00 +0100=0A@@ -98,6 +98,8 @@=0A #define CMCI_EN 			=
(1UL<<30)=0A #define CMCI_THRESHOLD_MASK		0x7FFF=0A =
=0A+#define MSR_AMD64_MC0_MASK		0xc0010044=0A+=0A #define =
MSR_IA32_MC1_CTL		0x00000404=0A #define MSR_IA32_MC1_CTL2		=
0x00000281=0A #define MSR_IA32_MC1_STATUS		0x00000405=0A@@ =
-151,6 +153,8 @@=0A #define MSR_IA32_MCx_ADDR(x)		(MSR_IA32_M=
C0_ADDR + 4*(x))=0A #define MSR_IA32_MCx_MISC(x)		(MSR_IA32_M=
C0_MISC + 4*(x)) =0A =0A+#define MSR_AMD64_MCx_MASK(x)		(MSR_AMD64_=
MC0_MASK + (x))=0A+=0A #define MSR_P6_PERFCTR0			0x000000c1=
=0A #define MSR_P6_PERFCTR1			0x000000c2=0A #define =
MSR_P6_EVNTSEL0			0x00000186=0A
--=__Part38179DE4.1__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--=__Part38179DE4.1__=--


From xen-devel-bounces@lists.xensource.com Mon Dec 12 15:27:40 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 15:27:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ra7mm-0000eL-Qr; Mon, 12 Dec 2011 15:27:24 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Ra7ml-0000e2-7q
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 15:27:23 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1323703589!7879815!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19223 invoked from network); 12 Dec 2011 15:26:29 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-8.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 12 Dec 2011 15:26:29 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 12 Dec 2011 15:26:29 +0000
Message-Id: <4EE62B6C0200007800066FBA@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 12 Dec 2011 15:27:24 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part91BE344C.0__="
Subject: [Xen-devel] [PATCH] x86/microcode: Allow "ucode=" argument to be
	negative
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__Part91BE344C.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

... to indicate counting from the end of the modules list.

Suggested by Tim Deegan.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- 2011-11-23.orig/xen/arch/x86/microcode.c	2011-11-30 16:52:28.0000000=
00 +0100
+++ 2011-11-23/xen/arch/x86/microcode.c	2011-12-06 08:41:13.000000000 =
+0100
@@ -41,7 +41,7 @@
=20
 static module_t __initdata ucode_mod;
 static void *(*__initdata ucode_mod_map)(const module_t *);
-static unsigned int __initdata ucode_mod_idx;
+static signed int __initdata ucode_mod_idx;
 static bool_t __initdata ucode_mod_forced;
 static cpumask_t __initdata init_mask;
=20
@@ -54,7 +54,7 @@ void __init microcode_set_module(unsigne
 static void __init parse_ucode(char *s)
 {
     if ( !ucode_mod_forced )
-        ucode_mod_idx =3D simple_strtoul(s, NULL, 0);
+        ucode_mod_idx =3D simple_strtol(s, NULL, 0);
 }
 custom_param("ucode", parse_ucode);
=20
@@ -65,7 +65,9 @@ void __init microcode_grab_module(
 {
     module_t *mod =3D (module_t *)__va(mbi->mods_addr);
=20
-    if ( !ucode_mod_idx || ucode_mod_idx >=3D mbi->mods_count ||
+    if ( ucode_mod_idx < 0 )
+        ucode_mod_idx +=3D mbi->mods_count;
+    if ( ucode_mod_idx <=3D 0 || ucode_mod_idx >=3D mbi->mods_count ||
          !__test_and_clear_bit(ucode_mod_idx, module_map) )
         return;
     ucode_mod =3D mod[ucode_mod_idx];




--=__Part91BE344C.0__=
Content-Type: text/plain; name="x86-ucode-neg-modidx.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-ucode-neg-modidx.patch"

x86/microcode: Allow "ucode=3D" argument to be negative=0A=0A... to =
indicate counting from the end of the modules list.=0A=0ASuggested by Tim =
Deegan.=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=0A=0A--- =
2011-11-23.orig/xen/arch/x86/microcode.c	2011-11-30 16:52:28.0000000=
00 +0100=0A+++ 2011-11-23/xen/arch/x86/microcode.c	2011-12-06 =
08:41:13.000000000 +0100=0A@@ -41,7 +41,7 @@=0A =0A static module_t =
__initdata ucode_mod;=0A static void *(*__initdata ucode_mod_map)(const =
module_t *);=0A-static unsigned int __initdata ucode_mod_idx;=0A+static =
signed int __initdata ucode_mod_idx;=0A static bool_t __initdata ucode_mod_=
forced;=0A static cpumask_t __initdata init_mask;=0A =0A@@ -54,7 +54,7 @@ =
void __init microcode_set_module(unsigne=0A static void __init parse_ucode(=
char *s)=0A {=0A     if ( !ucode_mod_forced )=0A-        ucode_mod_idx =3D =
simple_strtoul(s, NULL, 0);=0A+        ucode_mod_idx =3D simple_strtol(s, =
NULL, 0);=0A }=0A custom_param("ucode", parse_ucode);=0A =0A@@ -65,7 +65,9 =
@@ void __init microcode_grab_module(=0A {=0A     module_t *mod =3D =
(module_t *)__va(mbi->mods_addr);=0A =0A-    if ( !ucode_mod_idx || =
ucode_mod_idx >=3D mbi->mods_count ||=0A+    if ( ucode_mod_idx < 0 )=0A+  =
      ucode_mod_idx +=3D mbi->mods_count;=0A+    if ( ucode_mod_idx <=3D 0 =
|| ucode_mod_idx >=3D mbi->mods_count ||=0A          !__test_and_clear_bit(=
ucode_mod_idx, module_map) )=0A         return;=0A     ucode_mod =3D =
mod[ucode_mod_idx];=0A
--=__Part91BE344C.0__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--=__Part91BE344C.0__=--


From xen-devel-bounces@lists.xensource.com Mon Dec 12 15:27:40 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 15:27:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ra7mm-0000eL-Qr; Mon, 12 Dec 2011 15:27:24 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Ra7ml-0000e2-7q
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 15:27:23 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1323703589!7879815!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19223 invoked from network); 12 Dec 2011 15:26:29 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-8.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 12 Dec 2011 15:26:29 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 12 Dec 2011 15:26:29 +0000
Message-Id: <4EE62B6C0200007800066FBA@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 12 Dec 2011 15:27:24 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part91BE344C.0__="
Subject: [Xen-devel] [PATCH] x86/microcode: Allow "ucode=" argument to be
	negative
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__Part91BE344C.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

... to indicate counting from the end of the modules list.

Suggested by Tim Deegan.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- 2011-11-23.orig/xen/arch/x86/microcode.c	2011-11-30 16:52:28.0000000=
00 +0100
+++ 2011-11-23/xen/arch/x86/microcode.c	2011-12-06 08:41:13.000000000 =
+0100
@@ -41,7 +41,7 @@
=20
 static module_t __initdata ucode_mod;
 static void *(*__initdata ucode_mod_map)(const module_t *);
-static unsigned int __initdata ucode_mod_idx;
+static signed int __initdata ucode_mod_idx;
 static bool_t __initdata ucode_mod_forced;
 static cpumask_t __initdata init_mask;
=20
@@ -54,7 +54,7 @@ void __init microcode_set_module(unsigne
 static void __init parse_ucode(char *s)
 {
     if ( !ucode_mod_forced )
-        ucode_mod_idx =3D simple_strtoul(s, NULL, 0);
+        ucode_mod_idx =3D simple_strtol(s, NULL, 0);
 }
 custom_param("ucode", parse_ucode);
=20
@@ -65,7 +65,9 @@ void __init microcode_grab_module(
 {
     module_t *mod =3D (module_t *)__va(mbi->mods_addr);
=20
-    if ( !ucode_mod_idx || ucode_mod_idx >=3D mbi->mods_count ||
+    if ( ucode_mod_idx < 0 )
+        ucode_mod_idx +=3D mbi->mods_count;
+    if ( ucode_mod_idx <=3D 0 || ucode_mod_idx >=3D mbi->mods_count ||
          !__test_and_clear_bit(ucode_mod_idx, module_map) )
         return;
     ucode_mod =3D mod[ucode_mod_idx];




--=__Part91BE344C.0__=
Content-Type: text/plain; name="x86-ucode-neg-modidx.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-ucode-neg-modidx.patch"

x86/microcode: Allow "ucode=3D" argument to be negative=0A=0A... to =
indicate counting from the end of the modules list.=0A=0ASuggested by Tim =
Deegan.=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=0A=0A--- =
2011-11-23.orig/xen/arch/x86/microcode.c	2011-11-30 16:52:28.0000000=
00 +0100=0A+++ 2011-11-23/xen/arch/x86/microcode.c	2011-12-06 =
08:41:13.000000000 +0100=0A@@ -41,7 +41,7 @@=0A =0A static module_t =
__initdata ucode_mod;=0A static void *(*__initdata ucode_mod_map)(const =
module_t *);=0A-static unsigned int __initdata ucode_mod_idx;=0A+static =
signed int __initdata ucode_mod_idx;=0A static bool_t __initdata ucode_mod_=
forced;=0A static cpumask_t __initdata init_mask;=0A =0A@@ -54,7 +54,7 @@ =
void __init microcode_set_module(unsigne=0A static void __init parse_ucode(=
char *s)=0A {=0A     if ( !ucode_mod_forced )=0A-        ucode_mod_idx =3D =
simple_strtoul(s, NULL, 0);=0A+        ucode_mod_idx =3D simple_strtol(s, =
NULL, 0);=0A }=0A custom_param("ucode", parse_ucode);=0A =0A@@ -65,7 +65,9 =
@@ void __init microcode_grab_module(=0A {=0A     module_t *mod =3D =
(module_t *)__va(mbi->mods_addr);=0A =0A-    if ( !ucode_mod_idx || =
ucode_mod_idx >=3D mbi->mods_count ||=0A+    if ( ucode_mod_idx < 0 )=0A+  =
      ucode_mod_idx +=3D mbi->mods_count;=0A+    if ( ucode_mod_idx <=3D 0 =
|| ucode_mod_idx >=3D mbi->mods_count ||=0A          !__test_and_clear_bit(=
ucode_mod_idx, module_map) )=0A         return;=0A     ucode_mod =3D =
mod[ucode_mod_idx];=0A
--=__Part91BE344C.0__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--=__Part91BE344C.0__=--


From xen-devel-bounces@lists.xensource.com Mon Dec 12 15:32:27 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 15:32:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ra7rR-0000wz-L2; Mon, 12 Dec 2011 15:32:13 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Ra7rP-0000wf-Vu
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 15:32:12 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1323703877!7732516!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22919 invoked from network); 12 Dec 2011 15:31:18 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-6.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 12 Dec 2011 15:31:18 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 12 Dec 2011 15:31:17 +0000
Message-Id: <4EE62C8D0200007800066FCF@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 12 Dec 2011 15:32:13 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartB39C166D.0__="
Subject: [Xen-devel] [PATCH] x86: add platform hypercall to retrieve pCPU-s'
 family, model, and stepping
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__PartB39C166D.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

With the recent hotplug changes to the Xen part of the microcode
loading, this allows the kernel driver to avoid unnecessary calls into
the hypervisor during pCPU hot-enabling: Knowing that the hypervisor
retains the data for already booted CPUs, only data for CPUs with a
different signature needs to be passed down. Since the microcode
loading code can be pretty verbose, avoiding to invoke it can make the
log much easier to look at in case of problems.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- 2011-11-23.orig/xen/arch/x86/platform_hypercall.c	2011-12-01 =
12:06:55.000000000 +0100
+++ 2011-11-23/xen/arch/x86/platform_hypercall.c	2011-12-09 =
17:39:04.000000000 +0100
@@ -469,6 +469,42 @@ ret_t do_platform_op(XEN_GUEST_HANDLE(xe
     }
     break;
=20
+    case XENPF_get_cpu_version:
+    {
+        struct xenpf_pcpu_version *ver =3D &op->u.pcpu_version;
+
+        if ( !get_cpu_maps() )
+        {
+            ret =3D -EBUSY;
+            break;
+        }
+
+        if ( (ver->xen_cpuid >=3D nr_cpu_ids) || !cpu_online(ver->xen_cpui=
d) )
+        {
+            memset(ver->vendor_id, 0, sizeof(ver->vendor_id));
+            ver->family =3D 0;
+            ver->model =3D 0;
+            ver->stepping =3D 0;
+        }
+        else
+        {
+            const struct cpuinfo_x86 *c =3D &cpu_data[ver->xen_cpuid];
+
+            memcpy(ver->vendor_id, c->x86_vendor_id, sizeof(ver->vendor_id=
));
+            ver->family =3D c->x86;
+            ver->model =3D c->x86_model;
+            ver->stepping =3D c->x86_mask;
+        }
+
+        ver->max_present =3D cpumask_last(&cpu_present_map);
+
+        put_cpu_maps();
+
+        if ( copy_field_to_guest(u_xenpf_op, op, u.pcpu_version) )
+            ret =3D -EFAULT;
+    }
+    break;
+
     case XENPF_cpu_online:
     {
         int cpu =3D op->u.cpu_ol.cpuid;
--- 2011-11-23.orig/xen/arch/x86/x86_64/platform_hypercall.c	2011-12-09 =
17:40:49.000000000 +0100
+++ 2011-11-23/xen/arch/x86/x86_64/platform_hypercall.c	2011-12-01 =
16:04:28.000000000 +0100
@@ -3,7 +3,7 @@
  */
=20
 #include <xen/config.h>
-#include <xen/types.h>
+#include <xen/lib.h>
 #include <compat/platform.h>
=20
 DEFINE_XEN_GUEST_HANDLE(compat_platform_op_t);
@@ -26,8 +26,13 @@ DEFINE_XEN_GUEST_HANDLE(compat_platform_
 #define xen_processor_power_t   compat_processor_power_t
 #define set_cx_pminfo           compat_set_cx_pminfo
=20
-#define xenpf_pcpuinfo compat_pf_pcpuinfo
-#define xenpf_pcpuinfo_t compat_pf_pcpuinfo_t
+#define xen_pf_pcpuinfo xenpf_pcpuinfo
+CHECK_pf_pcpuinfo;
+#undef xen_pf_pcpuinfo
+
+#define xen_pf_pcpu_version xenpf_pcpu_version
+CHECK_pf_pcpu_version;
+#undef xen_pf_pcpu_version
=20
 #define xenpf_enter_acpi_sleep compat_pf_enter_acpi_sleep
=20
--- 2011-11-23.orig/xen/include/public/platform.h	2011-12-09 =
17:40:49.000000000 +0100
+++ 2011-11-23/xen/include/public/platform.h	2011-12-09 17:39:17.0000000=
00 +0100
@@ -449,6 +449,21 @@ struct xenpf_pcpuinfo {
 typedef struct xenpf_pcpuinfo xenpf_pcpuinfo_t;
 DEFINE_XEN_GUEST_HANDLE(xenpf_pcpuinfo_t);
=20
+#define XENPF_get_cpu_version 48
+struct xenpf_pcpu_version {
+    /* IN */
+    uint32_t xen_cpuid;
+    /* OUT */
+    /* The maxium cpu_id that is present */
+    uint32_t max_present;
+    char vendor_id[12];
+    uint32_t family;
+    uint32_t model;
+    uint32_t stepping;
+};
+typedef struct xenpf_pcpu_version xenpf_pcpu_version_t;
+DEFINE_XEN_GUEST_HANDLE(xenpf_pcpu_version_t);
+
 #define XENPF_cpu_online    56
 #define XENPF_cpu_offline   57
 struct xenpf_cpu_ol
@@ -492,6 +507,7 @@ struct xen_platform_op {
         struct xenpf_getidletime       getidletime;
         struct xenpf_set_processor_pminfo set_pminfo;
         struct xenpf_pcpuinfo          pcpu_info;
+        struct xenpf_pcpu_version      pcpu_version;
         struct xenpf_cpu_ol            cpu_ol;
         struct xenpf_cpu_hotadd        cpu_add;
         struct xenpf_mem_hotadd        mem_add;
--- 2011-11-23.orig/xen/include/xlat.lst	2011-12-09 17:40:49.0000000=
00 +0100
+++ 2011-11-23/xen/include/xlat.lst	2011-12-01 15:46:31.000000000 =
+0100
@@ -72,6 +72,17 @@
 ?	physdev_restore_msi		physdev.h
 ?	physdev_set_iopl		physdev.h
 ?	physdev_setup_gsi		physdev.h
+!	pct_register			platform.h
+!	power_register			platform.h
+?	processor_csd			platform.h
+!	processor_cx			platform.h
+!	processor_flags			platform.h
+!	processor_performance		platform.h
+!	processor_power			platform.h
+?	processor_px			platform.h
+!	psd_package			platform.h
+?	xenpf_pcpuinfo			platform.h
+?	xenpf_pcpu_version		platform.h
 !	sched_poll			sched.h
 ?	sched_remote_shutdown		sched.h
 ?	sched_shutdown			sched.h
@@ -84,12 +95,3 @@
 !	vcpu_set_singleshot_timer	vcpu.h
 ?	xenoprof_init			xenoprof.h
 ?	xenoprof_passive		xenoprof.h
-!	power_register			platform.h
-?	processor_csd			platform.h
-!	processor_cx			platform.h
-!	processor_flags			platform.h
-!	processor_power			platform.h
-!	pct_register			platform.h
-?	processor_px			platform.h
-!	psd_package			platform.h
-!	processor_performance		platform.h



--=__PartB39C166D.0__=
Content-Type: text/plain; name="x86-pcpu-version.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-pcpu-version.patch"

x86: add platform hypercall to retrieve pCPU-s' family, model, and =
stepping=0A=0AWith the recent hotplug changes to the Xen part of the =
microcode=0Aloading, this allows the kernel driver to avoid unnecessary =
calls into=0Athe hypervisor during pCPU hot-enabling: Knowing that the =
hypervisor=0Aretains the data for already booted CPUs, only data for CPUs =
with a=0Adifferent signature needs to be passed down. Since the =
microcode=0Aloading code can be pretty verbose, avoiding to invoke it can =
make the=0Alog much easier to look at in case of problems.=0A=0ASigned-off-=
by: Jan Beulich <jbeulich@suse.com>=0A=0A--- 2011-11-23.orig/xen/arch/x86/p=
latform_hypercall.c	2011-12-01 12:06:55.000000000 +0100=0A+++ =
2011-11-23/xen/arch/x86/platform_hypercall.c	2011-12-09 17:39:04.0000000=
00 +0100=0A@@ -469,6 +469,42 @@ ret_t do_platform_op(XEN_GUEST_HANDLE(xe=0A=
     }=0A     break;=0A =0A+    case XENPF_get_cpu_version:=0A+    {=0A+   =
     struct xenpf_pcpu_version *ver =3D &op->u.pcpu_version;=0A+=0A+       =
 if ( !get_cpu_maps() )=0A+        {=0A+            ret =3D -EBUSY;=0A+    =
        break;=0A+        }=0A+=0A+        if ( (ver->xen_cpuid >=3D =
nr_cpu_ids) || !cpu_online(ver->xen_cpuid) )=0A+        {=0A+            =
memset(ver->vendor_id, 0, sizeof(ver->vendor_id));=0A+            =
ver->family =3D 0;=0A+            ver->model =3D 0;=0A+            =
ver->stepping =3D 0;=0A+        }=0A+        else=0A+        {=0A+         =
   const struct cpuinfo_x86 *c =3D &cpu_data[ver->xen_cpuid];=0A+=0A+      =
      memcpy(ver->vendor_id, c->x86_vendor_id, sizeof(ver->vendor_id));=0A+=
            ver->family =3D c->x86;=0A+            ver->model =3D =
c->x86_model;=0A+            ver->stepping =3D c->x86_mask;=0A+        =
}=0A+=0A+        ver->max_present =3D cpumask_last(&cpu_present_map);=0A+=
=0A+        put_cpu_maps();=0A+=0A+        if ( copy_field_to_guest(u_xenpf=
_op, op, u.pcpu_version) )=0A+            ret =3D -EFAULT;=0A+    }=0A+    =
break;=0A+=0A     case XENPF_cpu_online:=0A     {=0A         int cpu =3D =
op->u.cpu_ol.cpuid;=0A--- 2011-11-23.orig/xen/arch/x86/x86_64/platform_hype=
rcall.c	2011-12-09 17:40:49.000000000 +0100=0A+++ 2011-11-23/xen/arch/x86/x=
86_64/platform_hypercall.c	2011-12-01 16:04:28.000000000 +0100=0A@@ =
-3,7 +3,7 @@=0A  */=0A =0A #include <xen/config.h>=0A-#include <xen/types.h=
>=0A+#include <xen/lib.h>=0A #include <compat/platform.h>=0A =0A DEFINE_XEN=
_GUEST_HANDLE(compat_platform_op_t);=0A@@ -26,8 +26,13 @@ DEFINE_XEN_GUEST_=
HANDLE(compat_platform_=0A #define xen_processor_power_t   compat_processor=
_power_t=0A #define set_cx_pminfo           compat_set_cx_pminfo=0A =
=0A-#define xenpf_pcpuinfo compat_pf_pcpuinfo=0A-#define xenpf_pcpuinfo_t =
compat_pf_pcpuinfo_t=0A+#define xen_pf_pcpuinfo xenpf_pcpuinfo=0A+CHECK_pf_=
pcpuinfo;=0A+#undef xen_pf_pcpuinfo=0A+=0A+#define xen_pf_pcpu_version =
xenpf_pcpu_version=0A+CHECK_pf_pcpu_version;=0A+#undef xen_pf_pcpu_version=
=0A =0A #define xenpf_enter_acpi_sleep compat_pf_enter_acpi_sleep=0A =
=0A--- 2011-11-23.orig/xen/include/public/platform.h	2011-12-09 =
17:40:49.000000000 +0100=0A+++ 2011-11-23/xen/include/public/platform.h	=
2011-12-09 17:39:17.000000000 +0100=0A@@ -449,6 +449,21 @@ struct =
xenpf_pcpuinfo {=0A typedef struct xenpf_pcpuinfo xenpf_pcpuinfo_t;=0A =
DEFINE_XEN_GUEST_HANDLE(xenpf_pcpuinfo_t);=0A =0A+#define XENPF_get_cpu_ver=
sion 48=0A+struct xenpf_pcpu_version {=0A+    /* IN */=0A+    uint32_t =
xen_cpuid;=0A+    /* OUT */=0A+    /* The maxium cpu_id that is present =
*/=0A+    uint32_t max_present;=0A+    char vendor_id[12];=0A+    uint32_t =
family;=0A+    uint32_t model;=0A+    uint32_t stepping;=0A+};=0A+typedef =
struct xenpf_pcpu_version xenpf_pcpu_version_t;=0A+DEFINE_XEN_GUEST_HANDLE(=
xenpf_pcpu_version_t);=0A+=0A #define XENPF_cpu_online    56=0A #define =
XENPF_cpu_offline   57=0A struct xenpf_cpu_ol=0A@@ -492,6 +507,7 @@ struct =
xen_platform_op {=0A         struct xenpf_getidletime       getidletime;=0A=
         struct xenpf_set_processor_pminfo set_pminfo;=0A         struct =
xenpf_pcpuinfo          pcpu_info;=0A+        struct xenpf_pcpu_version    =
  pcpu_version;=0A         struct xenpf_cpu_ol            cpu_ol;=0A       =
  struct xenpf_cpu_hotadd        cpu_add;=0A         struct xenpf_mem_hotad=
d        mem_add;=0A--- 2011-11-23.orig/xen/include/xlat.lst	2011-12-09 =
17:40:49.000000000 +0100=0A+++ 2011-11-23/xen/include/xlat.lst	2011-12-01 =
15:46:31.000000000 +0100=0A@@ -72,6 +72,17 @@=0A ?	physdev_restore_msi=
		physdev.h=0A ?	physdev_set_iopl		=
physdev.h=0A ?	physdev_setup_gsi		physdev.h=0A+!	pct_registe=
r			platform.h=0A+!	power_register			=
platform.h=0A+?	processor_csd			platform.h=0A+!	processor_c=
x			platform.h=0A+!	processor_flags			=
platform.h=0A+!	processor_performance		platform.h=0A+!	processor_p=
ower			platform.h=0A+?	processor_px			=
platform.h=0A+!	psd_package			platform.h=0A+?	xenpf_pcpui=
nfo			platform.h=0A+?	xenpf_pcpu_version		=
platform.h=0A !	sched_poll			sched.h=0A ?	sched_remot=
e_shutdown		sched.h=0A ?	sched_shutdown			=
sched.h=0A@@ -84,12 +95,3 @@=0A !	vcpu_set_singleshot_timer	=
vcpu.h=0A ?	xenoprof_init			xenoprof.h=0A ?	xenoprof_pa=
ssive		xenoprof.h=0A-!	power_register			platform.h=
=0A-?	processor_csd			platform.h=0A-!	processor_cx		=
	platform.h=0A-!	processor_flags			platform.h=0A-!	=
processor_power			platform.h=0A-!	pct_register			=
platform.h=0A-?	processor_px			platform.h=0A-!	psd_package=
			platform.h=0A-!	processor_performance		=
platform.h=0A
--=__PartB39C166D.0__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--=__PartB39C166D.0__=--


From xen-devel-bounces@lists.xensource.com Mon Dec 12 15:32:27 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 15:32:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ra7rR-0000wz-L2; Mon, 12 Dec 2011 15:32:13 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Ra7rP-0000wf-Vu
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 15:32:12 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1323703877!7732516!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22919 invoked from network); 12 Dec 2011 15:31:18 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-6.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 12 Dec 2011 15:31:18 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 12 Dec 2011 15:31:17 +0000
Message-Id: <4EE62C8D0200007800066FCF@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 12 Dec 2011 15:32:13 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartB39C166D.0__="
Subject: [Xen-devel] [PATCH] x86: add platform hypercall to retrieve pCPU-s'
 family, model, and stepping
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__PartB39C166D.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

With the recent hotplug changes to the Xen part of the microcode
loading, this allows the kernel driver to avoid unnecessary calls into
the hypervisor during pCPU hot-enabling: Knowing that the hypervisor
retains the data for already booted CPUs, only data for CPUs with a
different signature needs to be passed down. Since the microcode
loading code can be pretty verbose, avoiding to invoke it can make the
log much easier to look at in case of problems.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- 2011-11-23.orig/xen/arch/x86/platform_hypercall.c	2011-12-01 =
12:06:55.000000000 +0100
+++ 2011-11-23/xen/arch/x86/platform_hypercall.c	2011-12-09 =
17:39:04.000000000 +0100
@@ -469,6 +469,42 @@ ret_t do_platform_op(XEN_GUEST_HANDLE(xe
     }
     break;
=20
+    case XENPF_get_cpu_version:
+    {
+        struct xenpf_pcpu_version *ver =3D &op->u.pcpu_version;
+
+        if ( !get_cpu_maps() )
+        {
+            ret =3D -EBUSY;
+            break;
+        }
+
+        if ( (ver->xen_cpuid >=3D nr_cpu_ids) || !cpu_online(ver->xen_cpui=
d) )
+        {
+            memset(ver->vendor_id, 0, sizeof(ver->vendor_id));
+            ver->family =3D 0;
+            ver->model =3D 0;
+            ver->stepping =3D 0;
+        }
+        else
+        {
+            const struct cpuinfo_x86 *c =3D &cpu_data[ver->xen_cpuid];
+
+            memcpy(ver->vendor_id, c->x86_vendor_id, sizeof(ver->vendor_id=
));
+            ver->family =3D c->x86;
+            ver->model =3D c->x86_model;
+            ver->stepping =3D c->x86_mask;
+        }
+
+        ver->max_present =3D cpumask_last(&cpu_present_map);
+
+        put_cpu_maps();
+
+        if ( copy_field_to_guest(u_xenpf_op, op, u.pcpu_version) )
+            ret =3D -EFAULT;
+    }
+    break;
+
     case XENPF_cpu_online:
     {
         int cpu =3D op->u.cpu_ol.cpuid;
--- 2011-11-23.orig/xen/arch/x86/x86_64/platform_hypercall.c	2011-12-09 =
17:40:49.000000000 +0100
+++ 2011-11-23/xen/arch/x86/x86_64/platform_hypercall.c	2011-12-01 =
16:04:28.000000000 +0100
@@ -3,7 +3,7 @@
  */
=20
 #include <xen/config.h>
-#include <xen/types.h>
+#include <xen/lib.h>
 #include <compat/platform.h>
=20
 DEFINE_XEN_GUEST_HANDLE(compat_platform_op_t);
@@ -26,8 +26,13 @@ DEFINE_XEN_GUEST_HANDLE(compat_platform_
 #define xen_processor_power_t   compat_processor_power_t
 #define set_cx_pminfo           compat_set_cx_pminfo
=20
-#define xenpf_pcpuinfo compat_pf_pcpuinfo
-#define xenpf_pcpuinfo_t compat_pf_pcpuinfo_t
+#define xen_pf_pcpuinfo xenpf_pcpuinfo
+CHECK_pf_pcpuinfo;
+#undef xen_pf_pcpuinfo
+
+#define xen_pf_pcpu_version xenpf_pcpu_version
+CHECK_pf_pcpu_version;
+#undef xen_pf_pcpu_version
=20
 #define xenpf_enter_acpi_sleep compat_pf_enter_acpi_sleep
=20
--- 2011-11-23.orig/xen/include/public/platform.h	2011-12-09 =
17:40:49.000000000 +0100
+++ 2011-11-23/xen/include/public/platform.h	2011-12-09 17:39:17.0000000=
00 +0100
@@ -449,6 +449,21 @@ struct xenpf_pcpuinfo {
 typedef struct xenpf_pcpuinfo xenpf_pcpuinfo_t;
 DEFINE_XEN_GUEST_HANDLE(xenpf_pcpuinfo_t);
=20
+#define XENPF_get_cpu_version 48
+struct xenpf_pcpu_version {
+    /* IN */
+    uint32_t xen_cpuid;
+    /* OUT */
+    /* The maxium cpu_id that is present */
+    uint32_t max_present;
+    char vendor_id[12];
+    uint32_t family;
+    uint32_t model;
+    uint32_t stepping;
+};
+typedef struct xenpf_pcpu_version xenpf_pcpu_version_t;
+DEFINE_XEN_GUEST_HANDLE(xenpf_pcpu_version_t);
+
 #define XENPF_cpu_online    56
 #define XENPF_cpu_offline   57
 struct xenpf_cpu_ol
@@ -492,6 +507,7 @@ struct xen_platform_op {
         struct xenpf_getidletime       getidletime;
         struct xenpf_set_processor_pminfo set_pminfo;
         struct xenpf_pcpuinfo          pcpu_info;
+        struct xenpf_pcpu_version      pcpu_version;
         struct xenpf_cpu_ol            cpu_ol;
         struct xenpf_cpu_hotadd        cpu_add;
         struct xenpf_mem_hotadd        mem_add;
--- 2011-11-23.orig/xen/include/xlat.lst	2011-12-09 17:40:49.0000000=
00 +0100
+++ 2011-11-23/xen/include/xlat.lst	2011-12-01 15:46:31.000000000 =
+0100
@@ -72,6 +72,17 @@
 ?	physdev_restore_msi		physdev.h
 ?	physdev_set_iopl		physdev.h
 ?	physdev_setup_gsi		physdev.h
+!	pct_register			platform.h
+!	power_register			platform.h
+?	processor_csd			platform.h
+!	processor_cx			platform.h
+!	processor_flags			platform.h
+!	processor_performance		platform.h
+!	processor_power			platform.h
+?	processor_px			platform.h
+!	psd_package			platform.h
+?	xenpf_pcpuinfo			platform.h
+?	xenpf_pcpu_version		platform.h
 !	sched_poll			sched.h
 ?	sched_remote_shutdown		sched.h
 ?	sched_shutdown			sched.h
@@ -84,12 +95,3 @@
 !	vcpu_set_singleshot_timer	vcpu.h
 ?	xenoprof_init			xenoprof.h
 ?	xenoprof_passive		xenoprof.h
-!	power_register			platform.h
-?	processor_csd			platform.h
-!	processor_cx			platform.h
-!	processor_flags			platform.h
-!	processor_power			platform.h
-!	pct_register			platform.h
-?	processor_px			platform.h
-!	psd_package			platform.h
-!	processor_performance		platform.h



--=__PartB39C166D.0__=
Content-Type: text/plain; name="x86-pcpu-version.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-pcpu-version.patch"

x86: add platform hypercall to retrieve pCPU-s' family, model, and =
stepping=0A=0AWith the recent hotplug changes to the Xen part of the =
microcode=0Aloading, this allows the kernel driver to avoid unnecessary =
calls into=0Athe hypervisor during pCPU hot-enabling: Knowing that the =
hypervisor=0Aretains the data for already booted CPUs, only data for CPUs =
with a=0Adifferent signature needs to be passed down. Since the =
microcode=0Aloading code can be pretty verbose, avoiding to invoke it can =
make the=0Alog much easier to look at in case of problems.=0A=0ASigned-off-=
by: Jan Beulich <jbeulich@suse.com>=0A=0A--- 2011-11-23.orig/xen/arch/x86/p=
latform_hypercall.c	2011-12-01 12:06:55.000000000 +0100=0A+++ =
2011-11-23/xen/arch/x86/platform_hypercall.c	2011-12-09 17:39:04.0000000=
00 +0100=0A@@ -469,6 +469,42 @@ ret_t do_platform_op(XEN_GUEST_HANDLE(xe=0A=
     }=0A     break;=0A =0A+    case XENPF_get_cpu_version:=0A+    {=0A+   =
     struct xenpf_pcpu_version *ver =3D &op->u.pcpu_version;=0A+=0A+       =
 if ( !get_cpu_maps() )=0A+        {=0A+            ret =3D -EBUSY;=0A+    =
        break;=0A+        }=0A+=0A+        if ( (ver->xen_cpuid >=3D =
nr_cpu_ids) || !cpu_online(ver->xen_cpuid) )=0A+        {=0A+            =
memset(ver->vendor_id, 0, sizeof(ver->vendor_id));=0A+            =
ver->family =3D 0;=0A+            ver->model =3D 0;=0A+            =
ver->stepping =3D 0;=0A+        }=0A+        else=0A+        {=0A+         =
   const struct cpuinfo_x86 *c =3D &cpu_data[ver->xen_cpuid];=0A+=0A+      =
      memcpy(ver->vendor_id, c->x86_vendor_id, sizeof(ver->vendor_id));=0A+=
            ver->family =3D c->x86;=0A+            ver->model =3D =
c->x86_model;=0A+            ver->stepping =3D c->x86_mask;=0A+        =
}=0A+=0A+        ver->max_present =3D cpumask_last(&cpu_present_map);=0A+=
=0A+        put_cpu_maps();=0A+=0A+        if ( copy_field_to_guest(u_xenpf=
_op, op, u.pcpu_version) )=0A+            ret =3D -EFAULT;=0A+    }=0A+    =
break;=0A+=0A     case XENPF_cpu_online:=0A     {=0A         int cpu =3D =
op->u.cpu_ol.cpuid;=0A--- 2011-11-23.orig/xen/arch/x86/x86_64/platform_hype=
rcall.c	2011-12-09 17:40:49.000000000 +0100=0A+++ 2011-11-23/xen/arch/x86/x=
86_64/platform_hypercall.c	2011-12-01 16:04:28.000000000 +0100=0A@@ =
-3,7 +3,7 @@=0A  */=0A =0A #include <xen/config.h>=0A-#include <xen/types.h=
>=0A+#include <xen/lib.h>=0A #include <compat/platform.h>=0A =0A DEFINE_XEN=
_GUEST_HANDLE(compat_platform_op_t);=0A@@ -26,8 +26,13 @@ DEFINE_XEN_GUEST_=
HANDLE(compat_platform_=0A #define xen_processor_power_t   compat_processor=
_power_t=0A #define set_cx_pminfo           compat_set_cx_pminfo=0A =
=0A-#define xenpf_pcpuinfo compat_pf_pcpuinfo=0A-#define xenpf_pcpuinfo_t =
compat_pf_pcpuinfo_t=0A+#define xen_pf_pcpuinfo xenpf_pcpuinfo=0A+CHECK_pf_=
pcpuinfo;=0A+#undef xen_pf_pcpuinfo=0A+=0A+#define xen_pf_pcpu_version =
xenpf_pcpu_version=0A+CHECK_pf_pcpu_version;=0A+#undef xen_pf_pcpu_version=
=0A =0A #define xenpf_enter_acpi_sleep compat_pf_enter_acpi_sleep=0A =
=0A--- 2011-11-23.orig/xen/include/public/platform.h	2011-12-09 =
17:40:49.000000000 +0100=0A+++ 2011-11-23/xen/include/public/platform.h	=
2011-12-09 17:39:17.000000000 +0100=0A@@ -449,6 +449,21 @@ struct =
xenpf_pcpuinfo {=0A typedef struct xenpf_pcpuinfo xenpf_pcpuinfo_t;=0A =
DEFINE_XEN_GUEST_HANDLE(xenpf_pcpuinfo_t);=0A =0A+#define XENPF_get_cpu_ver=
sion 48=0A+struct xenpf_pcpu_version {=0A+    /* IN */=0A+    uint32_t =
xen_cpuid;=0A+    /* OUT */=0A+    /* The maxium cpu_id that is present =
*/=0A+    uint32_t max_present;=0A+    char vendor_id[12];=0A+    uint32_t =
family;=0A+    uint32_t model;=0A+    uint32_t stepping;=0A+};=0A+typedef =
struct xenpf_pcpu_version xenpf_pcpu_version_t;=0A+DEFINE_XEN_GUEST_HANDLE(=
xenpf_pcpu_version_t);=0A+=0A #define XENPF_cpu_online    56=0A #define =
XENPF_cpu_offline   57=0A struct xenpf_cpu_ol=0A@@ -492,6 +507,7 @@ struct =
xen_platform_op {=0A         struct xenpf_getidletime       getidletime;=0A=
         struct xenpf_set_processor_pminfo set_pminfo;=0A         struct =
xenpf_pcpuinfo          pcpu_info;=0A+        struct xenpf_pcpu_version    =
  pcpu_version;=0A         struct xenpf_cpu_ol            cpu_ol;=0A       =
  struct xenpf_cpu_hotadd        cpu_add;=0A         struct xenpf_mem_hotad=
d        mem_add;=0A--- 2011-11-23.orig/xen/include/xlat.lst	2011-12-09 =
17:40:49.000000000 +0100=0A+++ 2011-11-23/xen/include/xlat.lst	2011-12-01 =
15:46:31.000000000 +0100=0A@@ -72,6 +72,17 @@=0A ?	physdev_restore_msi=
		physdev.h=0A ?	physdev_set_iopl		=
physdev.h=0A ?	physdev_setup_gsi		physdev.h=0A+!	pct_registe=
r			platform.h=0A+!	power_register			=
platform.h=0A+?	processor_csd			platform.h=0A+!	processor_c=
x			platform.h=0A+!	processor_flags			=
platform.h=0A+!	processor_performance		platform.h=0A+!	processor_p=
ower			platform.h=0A+?	processor_px			=
platform.h=0A+!	psd_package			platform.h=0A+?	xenpf_pcpui=
nfo			platform.h=0A+?	xenpf_pcpu_version		=
platform.h=0A !	sched_poll			sched.h=0A ?	sched_remot=
e_shutdown		sched.h=0A ?	sched_shutdown			=
sched.h=0A@@ -84,12 +95,3 @@=0A !	vcpu_set_singleshot_timer	=
vcpu.h=0A ?	xenoprof_init			xenoprof.h=0A ?	xenoprof_pa=
ssive		xenoprof.h=0A-!	power_register			platform.h=
=0A-?	processor_csd			platform.h=0A-!	processor_cx		=
	platform.h=0A-!	processor_flags			platform.h=0A-!	=
processor_power			platform.h=0A-!	pct_register			=
platform.h=0A-?	processor_px			platform.h=0A-!	psd_package=
			platform.h=0A-!	processor_performance		=
platform.h=0A
--=__PartB39C166D.0__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--=__PartB39C166D.0__=--


From xen-devel-bounces@lists.xensource.com Mon Dec 12 15:32:43 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 15: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.xensource.com>)
	id 1Ra7rf-0000yf-7o; Mon, 12 Dec 2011 15:32:27 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Ra7re-0000yD-3N
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 15:32:26 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1323703892!5228701!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDc4NQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3587 invoked from network); 12 Dec 2011 15:31:32 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Dec 2011 15:31:32 -0000
X-IronPort-AV: E=Sophos;i="4.71,339,1320624000"; 
   d="scan'208";a="9420804"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Dec 2011 15:31:32 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 12 Dec 2011 15:31:32 +0000
Date: Mon, 12 Dec 2011 15:32:56 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Jan Kiszka <jan.kiszka@siemens.com>
In-Reply-To: <4EE617BA.4030102@siemens.com>
Message-ID: <alpine.DEB.2.00.1112121527130.3517@kaball-desktop>
References: <1323467645-24271-1-git-send-email-anthony.perard@citrix.com>
	<1323467645-24271-6-git-send-email-anthony.perard@citrix.com>
	<4EE3382D.80903@web.de>
	<alpine.DEB.2.00.1112121259180.3517@kaball-desktop>
	<4EE609BF.1070307@siemens.com>
	<alpine.DEB.2.00.1112121438410.3517@kaball-desktop>
	<4EE617BA.4030102@siemens.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Anthony Perard <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	QEMU-devel <qemu-devel@nongnu.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH V2 5/5] vga-cirrus: Workaround during
 restore when using Xen.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 12 Dec 2011, Jan Kiszka wrote:
> >>>> Is there really no way to fix this properly in the Xen layer?
> >>>
> >>> We thought about this issue for some time but we couldn't come up with
> >>> anything better.
> >>> To summarize the problem:
> >>>
> >>> - on restore the videoram has already been loaded in the guest physical
> >>>   address space by Xen;
> >>>
> >>> - we don't know exactly where it is yet, because it has been loaded at
> >>>   the *last* address it was mapped to (see map_linear_vram_bank that
> >>>   moves the videoram);
> >>>
> >>> - we want to avoid allocating the videoram twice (actually the second
> >>>   allocation would fail because of memory constraints);
> >>>
> >>>
> >>>
> >>> So the solution (I acknowledge that it looks more like an hack than a
> >>> solution) is:
> >>>
> >>> - wait for cirrus to load its state so that we know where the videoram
> >>>   is;
> >>
> >> Why can't you store this information in some additional Xen-specific
> >> vmstate? The fact that memory_region_get_ram_ptr has to return NULL
> >> looks bogus to me. It's against the QEMU semantics. Other devices may
> >> only be fine as they are not (yet) used with Xen.
> > 
> > Unfortunately that cannot work because the allocation is done by
> > vga_common_init before any state has been loaded.
> > So even if we saved the physmap QLIST in a vmstate record, it wouldn't
> > be available yet when vga_common_init tries to allocate the memory.
> 
> If you run two VMs with identical setup, one from cold start to
> operational mode, the other into an incoming migration, the guest
> physical memory layout the host sees is different? Hmm, maybe if you
> reorder devices in the command line.

Yes, it is different because the memory allocated for a specific device
(Cirrus) has been moved (map_linear_vram_bank).


> Really, I think this is something inherently incompatible with the
> current memory API. If Xen has this unfixable special "requirement"
> (it's rather a design issue IMHO), adjust the API and adapt all devices.
> Hot-fixing only a single one this way is no good idea long term.

Fair enough.
What about introducing a type of savevm state that is going to be
restored before machine->init?
This way we could save and restore our physmap and we could handle
memory maps and allocations transparently.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 15:32:43 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 15: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.xensource.com>)
	id 1Ra7rf-0000yf-7o; Mon, 12 Dec 2011 15:32:27 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Ra7re-0000yD-3N
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 15:32:26 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1323703892!5228701!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDc4NQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3587 invoked from network); 12 Dec 2011 15:31:32 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Dec 2011 15:31:32 -0000
X-IronPort-AV: E=Sophos;i="4.71,339,1320624000"; 
   d="scan'208";a="9420804"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Dec 2011 15:31:32 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 12 Dec 2011 15:31:32 +0000
Date: Mon, 12 Dec 2011 15:32:56 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Jan Kiszka <jan.kiszka@siemens.com>
In-Reply-To: <4EE617BA.4030102@siemens.com>
Message-ID: <alpine.DEB.2.00.1112121527130.3517@kaball-desktop>
References: <1323467645-24271-1-git-send-email-anthony.perard@citrix.com>
	<1323467645-24271-6-git-send-email-anthony.perard@citrix.com>
	<4EE3382D.80903@web.de>
	<alpine.DEB.2.00.1112121259180.3517@kaball-desktop>
	<4EE609BF.1070307@siemens.com>
	<alpine.DEB.2.00.1112121438410.3517@kaball-desktop>
	<4EE617BA.4030102@siemens.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Anthony Perard <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	QEMU-devel <qemu-devel@nongnu.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH V2 5/5] vga-cirrus: Workaround during
 restore when using Xen.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 12 Dec 2011, Jan Kiszka wrote:
> >>>> Is there really no way to fix this properly in the Xen layer?
> >>>
> >>> We thought about this issue for some time but we couldn't come up with
> >>> anything better.
> >>> To summarize the problem:
> >>>
> >>> - on restore the videoram has already been loaded in the guest physical
> >>>   address space by Xen;
> >>>
> >>> - we don't know exactly where it is yet, because it has been loaded at
> >>>   the *last* address it was mapped to (see map_linear_vram_bank that
> >>>   moves the videoram);
> >>>
> >>> - we want to avoid allocating the videoram twice (actually the second
> >>>   allocation would fail because of memory constraints);
> >>>
> >>>
> >>>
> >>> So the solution (I acknowledge that it looks more like an hack than a
> >>> solution) is:
> >>>
> >>> - wait for cirrus to load its state so that we know where the videoram
> >>>   is;
> >>
> >> Why can't you store this information in some additional Xen-specific
> >> vmstate? The fact that memory_region_get_ram_ptr has to return NULL
> >> looks bogus to me. It's against the QEMU semantics. Other devices may
> >> only be fine as they are not (yet) used with Xen.
> > 
> > Unfortunately that cannot work because the allocation is done by
> > vga_common_init before any state has been loaded.
> > So even if we saved the physmap QLIST in a vmstate record, it wouldn't
> > be available yet when vga_common_init tries to allocate the memory.
> 
> If you run two VMs with identical setup, one from cold start to
> operational mode, the other into an incoming migration, the guest
> physical memory layout the host sees is different? Hmm, maybe if you
> reorder devices in the command line.

Yes, it is different because the memory allocated for a specific device
(Cirrus) has been moved (map_linear_vram_bank).


> Really, I think this is something inherently incompatible with the
> current memory API. If Xen has this unfixable special "requirement"
> (it's rather a design issue IMHO), adjust the API and adapt all devices.
> Hot-fixing only a single one this way is no good idea long term.

Fair enough.
What about introducing a type of savevm state that is going to be
restored before machine->init?
This way we could save and restore our physmap and we could handle
memory maps and allocations transparently.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 15:35:15 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 15:35:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ra7u8-0001Bn-VP; Mon, 12 Dec 2011 15:35:00 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <george.shuklin@gmail.com>)
	id 1Ra7u7-0001BO-43; Mon, 12 Dec 2011 15:34:59 +0000
X-Env-Sender: george.shuklin@gmail.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1323704045!7133913!1
X-Originating-IP: [209.85.214.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6797 invoked from network); 12 Dec 2011 15:34:05 -0000
Received: from mail-bw0-f43.google.com (HELO mail-bw0-f43.google.com)
	(209.85.214.43)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Dec 2011 15:34:05 -0000
Received: by bkbzs2 with SMTP id zs2so18338912bkb.30
	for <multiple recipients>; Mon, 12 Dec 2011 07:34:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=message-id:date:from:user-agent:mime-version:to:cc:subject
	:references:in-reply-to:content-type:content-transfer-encoding;
	bh=c6yO6Ju5OjywTr6zw4cOgitPCKS3fvoGdn8pjADxeAA=;
	b=i4wCl4TX5u3s2YGH0qQbYND/mlxRYTUSf6WCG/MWsHSG4aAhUg2h4cpLEkVq5CSvVO
	ESDAiE28QjkjVvewJzATrYMRiX3ElJVtlf6J0CtBVkWFj3oPknTDC/2+x6vumWm6HQh+
	I6UaQowhz8J+xv5LT2cAKE7PdfEvBX32a/PMA=
Received: by 10.204.145.86 with SMTP id c22mr9844883bkv.61.1323704045157;
	Mon, 12 Dec 2011 07:34:05 -0800 (PST)
Received: from [192.168.40.44] (officecvt.selectel.ru. [188.93.16.50])
	by mx.google.com with ESMTPS id n14sm32600360bkn.13.2011.12.12.07.34.03
	(version=SSLv3 cipher=OTHER); Mon, 12 Dec 2011 07:34:04 -0800 (PST)
Message-ID: <4EE61EEA.9040607@gmail.com>
Date: Mon, 12 Dec 2011 19:34:02 +0400
From: George Shuklin <george.shuklin@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:9.0) Gecko/20111209 Thunderbird/9.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <4EE2665C.8090602@gmail.com>
	<1323689477.20077.173.camel@zakaz.uk.xensource.com>
	<4EE5EF22.6050704@gmail.com>
	<1323697614.20077.211.camel@zakaz.uk.xensource.com>
In-Reply-To: <1323697614.20077.211.camel@zakaz.uk.xensource.com>
Cc: xen-devel <xen-devel@lists.xensource.com>,
	"xen-api@lists.xensource.com" <xen-api@lists.xensource.com>
Subject: Re: [Xen-devel] bug in xenstored? No notification to subscription
 on @introduceDomain
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 12.12.2011 17:46, Ian Campbell wrote:
> Please don't top post and don't drop people/lists from the CC. I have
> reinstated xen-devel and refrained from trimming the quotes as heavily
> as I normally would.
>
> Counter to my own advice I have also dropped xen-hosts@googlegroups.com
> because last time I got a bounce in Russian to the effect that the group
> does not exist (according to google translate).
>
> On Mon, 2011-12-12 at 12:10 +0000, George Shuklin wrote:
>> Thanks for reply.
>>
>> The problem is we tried at least two different libraries - xs (+python
>> xen.lowlevel.xs) and our own library (pyxs), created from scratches on
>> pure python - both shows exactly same behavior. We loosing same time
>> @introduce and @release, but only for new domains. Older domains (which
>> starts before error appear) during shutdown/migration sends  @release
>> normally.
>>
>> I done strace, nothig is sending by xenstored to application socket when
>> 'new' domains appears and disappears (I'm not sure 100% due not very
>> good strace skills).
>>
>> Application performs write/read operations to/from xenstore (and do many
>> subscriptions, but only after @introduce) and older subscription works fine.
>>
>> PS We got other strange bug with memory leak in xenstored (happens only
>> with big amount of transactions, and ONLY with socket) - but this case
>> is still under research, so I decide not to post this (but may be it
>> related somehow?).
> Are the two event correlated? i.e. is the oxenstored process huge when
> these failures occur? Inability to allocate memory could explain some of
> your symptoms although I'd expect it to be more fatal more quickly and
> obviously than what you describe or to have wider impact.
Nope, memory leak occur only if transaction happens with subscription, 
but 'no notification' problem continues after we stops to use 
transaction (this cure memory leak completely, so I think this is 
separate issue, but I don't sure).

I still can't catch condition for lack of notifications for @introduce, 
sorry (I got one more this morning in test pool).

>> Sorry for question - how I can gather debug information for oxenstored?
> What sort of debug information are you after?
>
> There are various logging options which you could turn up to 11
> in /etc/xensource/xenstored.conf but I do not have a complete list of
> what they are, similarly for command line options -- perhaps someone on
> xen-api@ could chime in? Otherwise looking in the source might be the
> best way to find out what they are, try xenstore.ml, parse_args.ml
> logging.ml would be good places to start. (if having done so you feel
> motivated to write a patch to add docs/man/oxenstored.1.pod we would be
> much obliged...)
>
Ok, thanks, I'll dig to sources to set up them all. We heavily using 
xenstore for dynamic memory regulation (about five operations for every 
domain per second).

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 15:35:15 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 15:35:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ra7u8-0001Bn-VP; Mon, 12 Dec 2011 15:35:00 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <george.shuklin@gmail.com>)
	id 1Ra7u7-0001BO-43; Mon, 12 Dec 2011 15:34:59 +0000
X-Env-Sender: george.shuklin@gmail.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1323704045!7133913!1
X-Originating-IP: [209.85.214.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6797 invoked from network); 12 Dec 2011 15:34:05 -0000
Received: from mail-bw0-f43.google.com (HELO mail-bw0-f43.google.com)
	(209.85.214.43)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Dec 2011 15:34:05 -0000
Received: by bkbzs2 with SMTP id zs2so18338912bkb.30
	for <multiple recipients>; Mon, 12 Dec 2011 07:34:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=message-id:date:from:user-agent:mime-version:to:cc:subject
	:references:in-reply-to:content-type:content-transfer-encoding;
	bh=c6yO6Ju5OjywTr6zw4cOgitPCKS3fvoGdn8pjADxeAA=;
	b=i4wCl4TX5u3s2YGH0qQbYND/mlxRYTUSf6WCG/MWsHSG4aAhUg2h4cpLEkVq5CSvVO
	ESDAiE28QjkjVvewJzATrYMRiX3ElJVtlf6J0CtBVkWFj3oPknTDC/2+x6vumWm6HQh+
	I6UaQowhz8J+xv5LT2cAKE7PdfEvBX32a/PMA=
Received: by 10.204.145.86 with SMTP id c22mr9844883bkv.61.1323704045157;
	Mon, 12 Dec 2011 07:34:05 -0800 (PST)
Received: from [192.168.40.44] (officecvt.selectel.ru. [188.93.16.50])
	by mx.google.com with ESMTPS id n14sm32600360bkn.13.2011.12.12.07.34.03
	(version=SSLv3 cipher=OTHER); Mon, 12 Dec 2011 07:34:04 -0800 (PST)
Message-ID: <4EE61EEA.9040607@gmail.com>
Date: Mon, 12 Dec 2011 19:34:02 +0400
From: George Shuklin <george.shuklin@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:9.0) Gecko/20111209 Thunderbird/9.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <4EE2665C.8090602@gmail.com>
	<1323689477.20077.173.camel@zakaz.uk.xensource.com>
	<4EE5EF22.6050704@gmail.com>
	<1323697614.20077.211.camel@zakaz.uk.xensource.com>
In-Reply-To: <1323697614.20077.211.camel@zakaz.uk.xensource.com>
Cc: xen-devel <xen-devel@lists.xensource.com>,
	"xen-api@lists.xensource.com" <xen-api@lists.xensource.com>
Subject: Re: [Xen-devel] bug in xenstored? No notification to subscription
 on @introduceDomain
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 12.12.2011 17:46, Ian Campbell wrote:
> Please don't top post and don't drop people/lists from the CC. I have
> reinstated xen-devel and refrained from trimming the quotes as heavily
> as I normally would.
>
> Counter to my own advice I have also dropped xen-hosts@googlegroups.com
> because last time I got a bounce in Russian to the effect that the group
> does not exist (according to google translate).
>
> On Mon, 2011-12-12 at 12:10 +0000, George Shuklin wrote:
>> Thanks for reply.
>>
>> The problem is we tried at least two different libraries - xs (+python
>> xen.lowlevel.xs) and our own library (pyxs), created from scratches on
>> pure python - both shows exactly same behavior. We loosing same time
>> @introduce and @release, but only for new domains. Older domains (which
>> starts before error appear) during shutdown/migration sends  @release
>> normally.
>>
>> I done strace, nothig is sending by xenstored to application socket when
>> 'new' domains appears and disappears (I'm not sure 100% due not very
>> good strace skills).
>>
>> Application performs write/read operations to/from xenstore (and do many
>> subscriptions, but only after @introduce) and older subscription works fine.
>>
>> PS We got other strange bug with memory leak in xenstored (happens only
>> with big amount of transactions, and ONLY with socket) - but this case
>> is still under research, so I decide not to post this (but may be it
>> related somehow?).
> Are the two event correlated? i.e. is the oxenstored process huge when
> these failures occur? Inability to allocate memory could explain some of
> your symptoms although I'd expect it to be more fatal more quickly and
> obviously than what you describe or to have wider impact.
Nope, memory leak occur only if transaction happens with subscription, 
but 'no notification' problem continues after we stops to use 
transaction (this cure memory leak completely, so I think this is 
separate issue, but I don't sure).

I still can't catch condition for lack of notifications for @introduce, 
sorry (I got one more this morning in test pool).

>> Sorry for question - how I can gather debug information for oxenstored?
> What sort of debug information are you after?
>
> There are various logging options which you could turn up to 11
> in /etc/xensource/xenstored.conf but I do not have a complete list of
> what they are, similarly for command line options -- perhaps someone on
> xen-api@ could chime in? Otherwise looking in the source might be the
> best way to find out what they are, try xenstore.ml, parse_args.ml
> logging.ml would be good places to start. (if having done so you feel
> motivated to write a patch to add docs/man/oxenstored.1.pod we would be
> much obliged...)
>
Ok, thanks, I'll dig to sources to set up them all. We heavily using 
xenstore for dynamic memory regulation (about five operations for every 
domain per second).

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 15:35:34 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 15: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.xensource.com>)
	id 1Ra7uU-0001EO-D1; Mon, 12 Dec 2011 15:35:22 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Ra7uS-0001DS-GS
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 15:35:20 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1323704066!7921228!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27605 invoked from network); 12 Dec 2011 15:34:26 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-3.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 12 Dec 2011 15:34:26 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 12 Dec 2011 15:34:26 +0000
Message-Id: <4EE62D480200007800066FE7@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 12 Dec 2011 15:35:20 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartF7D85228.0__="
Subject: [Xen-devel] [PATCH] x86: remove redundant MCE related MSR
	definitions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__PartF7D85228.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Two definitions (the first register and a macro to calculate the
register for a given bank) are sufficient per kind of register.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- 2011-11-23.orig/xen/arch/x86/cpu/mcheck/amd_nonfatal.c	2011-12-05 =
11:38:33.000000000 +0100
+++ 2011-11-23/xen/arch/x86/cpu/mcheck/amd_nonfatal.c	2011-12-05 =
11:24:15.000000000 +0100
@@ -144,7 +144,7 @@ static void mce_amd_work_fn(void *data)
 		uint64_t value;
 		uint32_t counter;
=20
-		value =3D mca_rdmsr(MSR_IA32_MC4_MISC);
+		value =3D mca_rdmsr(MSR_IA32_MCx_MISC(4));
 		/* Only the error counter field is of interest
 		 * Bit field is described in AMD K8 BKDG chapter 6.4.5.5
 		 */
@@ -174,7 +174,7 @@ static void mce_amd_work_fn(void *data)
 			value &=3D ~(0x60FFF00000000ULL);
 			/* Counter enable */
 			value |=3D (1ULL << 51);
-			mca_wrmsr(MSR_IA32_MC4_MISC, value);
+			mca_wrmsr(MSR_IA32_MCx_MISC(4), value);
 			wmb();
 		}
 	}
@@ -217,7 +217,7 @@ void amd_nonfatal_mcheck_init(struct cpu
=20
 		/* hw threshold registers present */
 		hw_threshold =3D 1;
-		rdmsrl(MSR_IA32_MC4_MISC, value);
+		rdmsrl(MSR_IA32_MCx_MISC(4), value);
=20
 		if (value & (1ULL << 61)) { /* Locked bit */
 			/* Locked by BIOS. Not available for use */
@@ -238,7 +238,7 @@ void amd_nonfatal_mcheck_init(struct cpu
 			value &=3D ~(0x60FFF00000000ULL);
 			/* Counter enable */
 			value |=3D (1ULL << 51);
-			wrmsrl(MSR_IA32_MC4_MISC, value);
+			wrmsrl(MSR_IA32_MCx_MISC(4), value);
 			/* serialize */
 			wmb();
 			printk(XENLOG_INFO "MCA: Use hw thresholding to =
adjust polling frequency\n");
--- 2011-11-23.orig/xen/arch/x86/cpu/mcheck/mce_amd_quirks.c	2011-12-05 =
11:41:00.000000000 +0100
+++ 2011-11-23/xen/arch/x86/cpu/mcheck/mce_amd_quirks.c	2011-12-05 =
11:42:03.000000000 +0100
@@ -68,8 +68,8 @@ int mcequirk_amd_apply(enum mcequirk_amd
 		 * TBL walk error reporting, which trips off incorrectly
 		 * with AGP GART & 3ware & Cerberus.
 		 */
-		wrmsrl(MSR_IA32_MC4_CTL, ~(1ULL << 10));
-		wrmsrl(MSR_IA32_MC4_STATUS, 0ULL);
+		wrmsrl(MSR_IA32_MCx_CTL(4), ~(1ULL << 10));
+		wrmsrl(MSR_IA32_MCx_STATUS(4), 0ULL);
 		break;
 	case MCEQUIRK_F10_GART:
 		if (rdmsr_safe(MSR_AMD64_MCx_MASK(4), val) =3D=3D 0)
--- 2011-11-23.orig/xen/arch/x86/cpu/mcheck/mce_intel.c	2011-12-05 =
11:38:33.000000000 +0100
+++ 2011-11-23/xen/arch/x86/cpu/mcheck/mce_intel.c	2011-12-05 =
11:27:53.000000000 +0100
@@ -986,7 +986,7 @@ static DEFINE_SPINLOCK(cmci_discover_loc
  */
 static int do_cmci_discover(int i)
 {
-    unsigned msr =3D MSR_IA32_MC0_CTL2 + i;
+    unsigned msr =3D MSR_IA32_MCx_CTL2(i);
     u64 val;
=20
     rdmsrl(msr, val);
@@ -1095,7 +1095,7 @@ static void clear_cmci(void)
             smp_processor_id());
=20
     for (i =3D 0; i < nr_mce_banks; i++) {
-        unsigned msr =3D MSR_IA32_MC0_CTL2 + i;
+        unsigned msr =3D MSR_IA32_MCx_CTL2(i);
         u64 val;
         if (!mcabanks_test(i, __get_cpu_var(mce_banks_owned)))
             continue;
--- 2011-11-23.orig/xen/arch/x86/hvm/svm/svm.c	2011-12-05 11:38:33.0000000=
00 +0100
+++ 2011-11-23/xen/arch/x86/hvm/svm/svm.c	2011-12-05 11:25:55.0000000=
00 +0100
@@ -1318,7 +1318,7 @@ static int svm_msr_read_intercept(unsign
         *msr_content =3D v->arch.hvm_svm.guest_sysenter_eip;
         break;
=20
-    case MSR_IA32_MC4_MISC: /* Threshold register */
+    case MSR_IA32_MCx_MISC(4): /* Threshold register */
     case MSR_F10_MC4_MISC1 ... MSR_F10_MC4_MISC3:
         /*
          * MCA/MCE: We report that the threshold register is unavailable
@@ -1498,7 +1498,7 @@ static int svm_msr_write_intercept(unsig
         vpmu_do_wrmsr(msr, msr_content);
         break;
=20
-    case MSR_IA32_MC4_MISC: /* Threshold register */
+    case MSR_IA32_MCx_MISC(4): /* Threshold register */
     case MSR_F10_MC4_MISC1 ... MSR_F10_MC4_MISC3:
         /*
          * MCA/MCE: Threshold register is reported to be locked, so we =
ignore
--- 2011-11-23.orig/xen/include/asm-x86/msr-index.h	2011-12-05 =
11:06:39.000000000 +0100
+++ 2011-11-23/xen/include/asm-x86/msr-index.h	2011-12-05 11:21:46.0000000=
00 +0100
@@ -100,58 +100,11 @@
=20
 #define MSR_AMD64_MC0_MASK		0xc0010044
=20
-#define MSR_IA32_MC1_CTL		0x00000404
-#define MSR_IA32_MC1_CTL2		0x00000281
-#define MSR_IA32_MC1_STATUS		0x00000405
-#define MSR_IA32_MC1_ADDR		0x00000406
-#define MSR_IA32_MC1_MISC		0x00000407
-
-#define MSR_IA32_MC2_CTL		0x00000408
-#define MSR_IA32_MC2_CTL2		0x00000282
-#define MSR_IA32_MC2_STATUS		0x00000409
-#define MSR_IA32_MC2_ADDR		0x0000040A
-#define MSR_IA32_MC2_MISC		0x0000040B
-
-#define MSR_IA32_MC3_CTL2		0x00000283
-#define MSR_IA32_MC3_CTL		0x0000040C
-#define MSR_IA32_MC3_STATUS		0x0000040D
-#define MSR_IA32_MC3_ADDR		0x0000040E
-#define MSR_IA32_MC3_MISC		0x0000040F
-
-#define MSR_IA32_MC4_CTL2		0x00000284
-#define MSR_IA32_MC4_CTL		0x00000410
-#define MSR_IA32_MC4_STATUS		0x00000411
-#define MSR_IA32_MC4_ADDR		0x00000412
-#define MSR_IA32_MC4_MISC		0x00000413
-
-#define MSR_IA32_MC5_CTL2		0x00000285
-#define MSR_IA32_MC5_CTL		0x00000414
-#define MSR_IA32_MC5_STATUS		0x00000415
-#define MSR_IA32_MC5_ADDR		0x00000416
-#define MSR_IA32_MC5_MISC		0x00000417
-
-#define MSR_IA32_MC6_CTL2		0x00000286
-#define MSR_IA32_MC6_CTL		0x00000418
-#define MSR_IA32_MC6_STATUS		0x00000419
-#define MSR_IA32_MC6_ADDR		0x0000041A
-#define MSR_IA32_MC6_MISC		0x0000041B
-
-#define MSR_IA32_MC7_CTL2		0x00000287
-#define MSR_IA32_MC7_CTL		0x0000041C
-#define MSR_IA32_MC7_STATUS		0x0000041D
-#define MSR_IA32_MC7_ADDR		0x0000041E
-#define MSR_IA32_MC7_MISC		0x0000041F
-
-#define MSR_IA32_MC8_CTL2		0x00000288
-#define MSR_IA32_MC8_CTL		0x00000420
-#define MSR_IA32_MC8_STATUS		0x00000421
-#define MSR_IA32_MC8_ADDR		0x00000422
-#define MSR_IA32_MC8_MISC		0x00000423
-
 #define MSR_IA32_MCx_CTL(x)		(MSR_IA32_MC0_CTL + 4*(x))
 #define MSR_IA32_MCx_STATUS(x)		(MSR_IA32_MC0_STATUS + 4*(x))
 #define MSR_IA32_MCx_ADDR(x)		(MSR_IA32_MC0_ADDR + 4*(x))
 #define MSR_IA32_MCx_MISC(x)		(MSR_IA32_MC0_MISC + 4*(x))=20
+#define MSR_IA32_MCx_CTL2(x)		(MSR_IA32_MC0_CTL2 + (x))
=20
 #define MSR_AMD64_MCx_MASK(x)		(MSR_AMD64_MC0_MASK + (x))
=20



--=__PartF7D85228.0__=
Content-Type: text/plain; name="x86-mce-msr-names.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-mce-msr-names.patch"

x86: remove redundant MCE related MSR definitions=0A=0ATwo definitions =
(the first register and a macro to calculate the=0Aregister for a given =
bank) are sufficient per kind of register.=0A=0ASigned-off-by: Jan Beulich =
<jbeulich@suse.com>=0A=0A--- 2011-11-23.orig/xen/arch/x86/cpu/mcheck/amd_no=
nfatal.c	2011-12-05 11:38:33.000000000 +0100=0A+++ 2011-11-23/xen/ar=
ch/x86/cpu/mcheck/amd_nonfatal.c	2011-12-05 11:24:15.000000000 =
+0100=0A@@ -144,7 +144,7 @@ static void mce_amd_work_fn(void *data)=0A 		=
uint64_t value;=0A 		uint32_t counter;=0A =0A-		=
value =3D mca_rdmsr(MSR_IA32_MC4_MISC);=0A+		value =3D =
mca_rdmsr(MSR_IA32_MCx_MISC(4));=0A 		/* Only the error counter =
field is of interest=0A 		 * Bit field is described in AMD =
K8 BKDG chapter 6.4.5.5=0A 		 */=0A@@ -174,7 +174,7 @@ static =
void mce_amd_work_fn(void *data)=0A 			value &=3D =
~(0x60FFF00000000ULL);=0A 			/* Counter enable */=0A 	=
		value |=3D (1ULL << 51);=0A-			mca_wrmsr(M=
SR_IA32_MC4_MISC, value);=0A+			mca_wrmsr(MSR_IA32_MCx_MISC=
(4), value);=0A 			wmb();=0A 		}=0A 	=
}=0A@@ -217,7 +217,7 @@ void amd_nonfatal_mcheck_init(struct cpu=0A =0A 	=
	/* hw threshold registers present */=0A 		hw_threshol=
d =3D 1;=0A-		rdmsrl(MSR_IA32_MC4_MISC, value);=0A+		=
rdmsrl(MSR_IA32_MCx_MISC(4), value);=0A =0A 		if (value & (1ULL =
<< 61)) { /* Locked bit */=0A 			/* Locked by BIOS. Not =
available for use */=0A@@ -238,7 +238,7 @@ void amd_nonfatal_mcheck_init(st=
ruct cpu=0A 			value &=3D ~(0x60FFF00000000ULL);=0A 		=
	/* Counter enable */=0A 			value |=3D (1ULL =
<< 51);=0A-			wrmsrl(MSR_IA32_MC4_MISC, value);=0A+		=
	wrmsrl(MSR_IA32_MCx_MISC(4), value);=0A 			/* =
serialize */=0A 			wmb();=0A 			=
printk(XENLOG_INFO "MCA: Use hw thresholding to adjust polling frequency\n"=
);=0A--- 2011-11-23.orig/xen/arch/x86/cpu/mcheck/mce_amd_quirks.c	=
2011-12-05 11:41:00.000000000 +0100=0A+++ 2011-11-23/xen/arch/x86/cpu/mchec=
k/mce_amd_quirks.c	2011-12-05 11:42:03.000000000 +0100=0A@@ -68,8 =
+68,8 @@ int mcequirk_amd_apply(enum mcequirk_amd=0A 		 * TBL =
walk error reporting, which trips off incorrectly=0A 		 * with =
AGP GART & 3ware & Cerberus.=0A 		 */=0A-		wrmsrl(MSR_=
IA32_MC4_CTL, ~(1ULL << 10));=0A-		wrmsrl(MSR_IA32_MC4_STATUS,=
 0ULL);=0A+		wrmsrl(MSR_IA32_MCx_CTL(4), ~(1ULL << 10));=0A+		=
wrmsrl(MSR_IA32_MCx_STATUS(4), 0ULL);=0A 		break;=0A 	=
case MCEQUIRK_F10_GART:=0A 		if (rdmsr_safe(MSR_AMD64_MCx_MASK(4=
), val) =3D=3D 0)=0A--- 2011-11-23.orig/xen/arch/x86/cpu/mcheck/mce_intel.c=
	2011-12-05 11:38:33.000000000 +0100=0A+++ 2011-11-23/xen/arch/x86/c=
pu/mcheck/mce_intel.c	2011-12-05 11:27:53.000000000 +0100=0A@@ -986,7 =
+986,7 @@ static DEFINE_SPINLOCK(cmci_discover_loc=0A  */=0A static int =
do_cmci_discover(int i)=0A {=0A-    unsigned msr =3D MSR_IA32_MC0_CTL2 + =
i;=0A+    unsigned msr =3D MSR_IA32_MCx_CTL2(i);=0A     u64 val;=0A =0A    =
 rdmsrl(msr, val);=0A@@ -1095,7 +1095,7 @@ static void clear_cmci(void)=0A =
            smp_processor_id());=0A =0A     for (i =3D 0; i < nr_mce_banks;=
 i++) {=0A-        unsigned msr =3D MSR_IA32_MC0_CTL2 + i;=0A+        =
unsigned msr =3D MSR_IA32_MCx_CTL2(i);=0A         u64 val;=0A         if =
(!mcabanks_test(i, __get_cpu_var(mce_banks_owned)))=0A             =
continue;=0A--- 2011-11-23.orig/xen/arch/x86/hvm/svm/svm.c	2011-12-05 =
11:38:33.000000000 +0100=0A+++ 2011-11-23/xen/arch/x86/hvm/svm/svm.c	=
2011-12-05 11:25:55.000000000 +0100=0A@@ -1318,7 +1318,7 @@ static int =
svm_msr_read_intercept(unsign=0A         *msr_content =3D v->arch.hvm_svm.g=
uest_sysenter_eip;=0A         break;=0A =0A-    case MSR_IA32_MC4_MISC: /* =
Threshold register */=0A+    case MSR_IA32_MCx_MISC(4): /* Threshold =
register */=0A     case MSR_F10_MC4_MISC1 ... MSR_F10_MC4_MISC3:=0A        =
 /*=0A          * MCA/MCE: We report that the threshold register is =
unavailable=0A@@ -1498,7 +1498,7 @@ static int svm_msr_write_intercept(unsi=
g=0A         vpmu_do_wrmsr(msr, msr_content);=0A         break;=0A =0A-    =
case MSR_IA32_MC4_MISC: /* Threshold register */=0A+    case MSR_IA32_MCx_M=
ISC(4): /* Threshold register */=0A     case MSR_F10_MC4_MISC1 ... =
MSR_F10_MC4_MISC3:=0A         /*=0A          * MCA/MCE: Threshold register =
is reported to be locked, so we ignore=0A--- 2011-11-23.orig/xen/include/as=
m-x86/msr-index.h	2011-12-05 11:06:39.000000000 +0100=0A+++ =
2011-11-23/xen/include/asm-x86/msr-index.h	2011-12-05 11:21:46.0000000=
00 +0100=0A@@ -100,58 +100,11 @@=0A =0A #define MSR_AMD64_MC0_MASK		=
0xc0010044=0A =0A-#define MSR_IA32_MC1_CTL		0x00000404=0A-#defi=
ne MSR_IA32_MC1_CTL2		0x00000281=0A-#define MSR_IA32_MC1_STATUS	=
	0x00000405=0A-#define MSR_IA32_MC1_ADDR		0x00000406=0A-#defi=
ne MSR_IA32_MC1_MISC		0x00000407=0A-=0A-#define MSR_IA32_MC2_CTL	=
	0x00000408=0A-#define MSR_IA32_MC2_CTL2		0x00000282=0A-#defi=
ne MSR_IA32_MC2_STATUS		0x00000409=0A-#define MSR_IA32_MC2_ADDR		=
0x0000040A=0A-#define MSR_IA32_MC2_MISC		0x0000040B=0A-=0A-#define =
MSR_IA32_MC3_CTL2		0x00000283=0A-#define MSR_IA32_MC3_CTL		=
0x0000040C=0A-#define MSR_IA32_MC3_STATUS		0x0000040D=0A-#defi=
ne MSR_IA32_MC3_ADDR		0x0000040E=0A-#define MSR_IA32_MC3_MISC		=
0x0000040F=0A-=0A-#define MSR_IA32_MC4_CTL2		0x00000284=0A-#defi=
ne MSR_IA32_MC4_CTL		0x00000410=0A-#define MSR_IA32_MC4_STATUS	=
	0x00000411=0A-#define MSR_IA32_MC4_ADDR		0x00000412=0A-#defi=
ne MSR_IA32_MC4_MISC		0x00000413=0A-=0A-#define MSR_IA32_MC5_CTL2=
		0x00000285=0A-#define MSR_IA32_MC5_CTL		0x00000414=
=0A-#define MSR_IA32_MC5_STATUS		0x00000415=0A-#define MSR_IA32_MC5_=
ADDR		0x00000416=0A-#define MSR_IA32_MC5_MISC		0x00000417=
=0A-=0A-#define MSR_IA32_MC6_CTL2		0x00000286=0A-#define =
MSR_IA32_MC6_CTL		0x00000418=0A-#define MSR_IA32_MC6_STATUS	=
	0x00000419=0A-#define MSR_IA32_MC6_ADDR		0x0000041A=0A-#defi=
ne MSR_IA32_MC6_MISC		0x0000041B=0A-=0A-#define MSR_IA32_MC7_CTL2=
		0x00000287=0A-#define MSR_IA32_MC7_CTL		0x0000041C=
=0A-#define MSR_IA32_MC7_STATUS		0x0000041D=0A-#define MSR_IA32_MC7_=
ADDR		0x0000041E=0A-#define MSR_IA32_MC7_MISC		0x0000041F=
=0A-=0A-#define MSR_IA32_MC8_CTL2		0x00000288=0A-#define =
MSR_IA32_MC8_CTL		0x00000420=0A-#define MSR_IA32_MC8_STATUS	=
	0x00000421=0A-#define MSR_IA32_MC8_ADDR		0x00000422=0A-#defi=
ne MSR_IA32_MC8_MISC		0x00000423=0A-=0A #define MSR_IA32_MCx_CTL(=
x)		(MSR_IA32_MC0_CTL + 4*(x))=0A #define MSR_IA32_MCx_STATUS(x=
)		(MSR_IA32_MC0_STATUS + 4*(x))=0A #define MSR_IA32_MCx_ADDR(=
x)		(MSR_IA32_MC0_ADDR + 4*(x))=0A #define MSR_IA32_MCx_MISC(x)=
		(MSR_IA32_MC0_MISC + 4*(x)) =0A+#define MSR_IA32_MCx_CTL2(x=
)		(MSR_IA32_MC0_CTL2 + (x))=0A =0A #define MSR_AMD64_MCx_MASK=
(x)		(MSR_AMD64_MC0_MASK + (x))=0A =0A
--=__PartF7D85228.0__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--=__PartF7D85228.0__=--


From xen-devel-bounces@lists.xensource.com Mon Dec 12 15:35:34 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 15: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.xensource.com>)
	id 1Ra7uU-0001EO-D1; Mon, 12 Dec 2011 15:35:22 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Ra7uS-0001DS-GS
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 15:35:20 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1323704066!7921228!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27605 invoked from network); 12 Dec 2011 15:34:26 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-3.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 12 Dec 2011 15:34:26 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 12 Dec 2011 15:34:26 +0000
Message-Id: <4EE62D480200007800066FE7@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 12 Dec 2011 15:35:20 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartF7D85228.0__="
Subject: [Xen-devel] [PATCH] x86: remove redundant MCE related MSR
	definitions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__PartF7D85228.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Two definitions (the first register and a macro to calculate the
register for a given bank) are sufficient per kind of register.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- 2011-11-23.orig/xen/arch/x86/cpu/mcheck/amd_nonfatal.c	2011-12-05 =
11:38:33.000000000 +0100
+++ 2011-11-23/xen/arch/x86/cpu/mcheck/amd_nonfatal.c	2011-12-05 =
11:24:15.000000000 +0100
@@ -144,7 +144,7 @@ static void mce_amd_work_fn(void *data)
 		uint64_t value;
 		uint32_t counter;
=20
-		value =3D mca_rdmsr(MSR_IA32_MC4_MISC);
+		value =3D mca_rdmsr(MSR_IA32_MCx_MISC(4));
 		/* Only the error counter field is of interest
 		 * Bit field is described in AMD K8 BKDG chapter 6.4.5.5
 		 */
@@ -174,7 +174,7 @@ static void mce_amd_work_fn(void *data)
 			value &=3D ~(0x60FFF00000000ULL);
 			/* Counter enable */
 			value |=3D (1ULL << 51);
-			mca_wrmsr(MSR_IA32_MC4_MISC, value);
+			mca_wrmsr(MSR_IA32_MCx_MISC(4), value);
 			wmb();
 		}
 	}
@@ -217,7 +217,7 @@ void amd_nonfatal_mcheck_init(struct cpu
=20
 		/* hw threshold registers present */
 		hw_threshold =3D 1;
-		rdmsrl(MSR_IA32_MC4_MISC, value);
+		rdmsrl(MSR_IA32_MCx_MISC(4), value);
=20
 		if (value & (1ULL << 61)) { /* Locked bit */
 			/* Locked by BIOS. Not available for use */
@@ -238,7 +238,7 @@ void amd_nonfatal_mcheck_init(struct cpu
 			value &=3D ~(0x60FFF00000000ULL);
 			/* Counter enable */
 			value |=3D (1ULL << 51);
-			wrmsrl(MSR_IA32_MC4_MISC, value);
+			wrmsrl(MSR_IA32_MCx_MISC(4), value);
 			/* serialize */
 			wmb();
 			printk(XENLOG_INFO "MCA: Use hw thresholding to =
adjust polling frequency\n");
--- 2011-11-23.orig/xen/arch/x86/cpu/mcheck/mce_amd_quirks.c	2011-12-05 =
11:41:00.000000000 +0100
+++ 2011-11-23/xen/arch/x86/cpu/mcheck/mce_amd_quirks.c	2011-12-05 =
11:42:03.000000000 +0100
@@ -68,8 +68,8 @@ int mcequirk_amd_apply(enum mcequirk_amd
 		 * TBL walk error reporting, which trips off incorrectly
 		 * with AGP GART & 3ware & Cerberus.
 		 */
-		wrmsrl(MSR_IA32_MC4_CTL, ~(1ULL << 10));
-		wrmsrl(MSR_IA32_MC4_STATUS, 0ULL);
+		wrmsrl(MSR_IA32_MCx_CTL(4), ~(1ULL << 10));
+		wrmsrl(MSR_IA32_MCx_STATUS(4), 0ULL);
 		break;
 	case MCEQUIRK_F10_GART:
 		if (rdmsr_safe(MSR_AMD64_MCx_MASK(4), val) =3D=3D 0)
--- 2011-11-23.orig/xen/arch/x86/cpu/mcheck/mce_intel.c	2011-12-05 =
11:38:33.000000000 +0100
+++ 2011-11-23/xen/arch/x86/cpu/mcheck/mce_intel.c	2011-12-05 =
11:27:53.000000000 +0100
@@ -986,7 +986,7 @@ static DEFINE_SPINLOCK(cmci_discover_loc
  */
 static int do_cmci_discover(int i)
 {
-    unsigned msr =3D MSR_IA32_MC0_CTL2 + i;
+    unsigned msr =3D MSR_IA32_MCx_CTL2(i);
     u64 val;
=20
     rdmsrl(msr, val);
@@ -1095,7 +1095,7 @@ static void clear_cmci(void)
             smp_processor_id());
=20
     for (i =3D 0; i < nr_mce_banks; i++) {
-        unsigned msr =3D MSR_IA32_MC0_CTL2 + i;
+        unsigned msr =3D MSR_IA32_MCx_CTL2(i);
         u64 val;
         if (!mcabanks_test(i, __get_cpu_var(mce_banks_owned)))
             continue;
--- 2011-11-23.orig/xen/arch/x86/hvm/svm/svm.c	2011-12-05 11:38:33.0000000=
00 +0100
+++ 2011-11-23/xen/arch/x86/hvm/svm/svm.c	2011-12-05 11:25:55.0000000=
00 +0100
@@ -1318,7 +1318,7 @@ static int svm_msr_read_intercept(unsign
         *msr_content =3D v->arch.hvm_svm.guest_sysenter_eip;
         break;
=20
-    case MSR_IA32_MC4_MISC: /* Threshold register */
+    case MSR_IA32_MCx_MISC(4): /* Threshold register */
     case MSR_F10_MC4_MISC1 ... MSR_F10_MC4_MISC3:
         /*
          * MCA/MCE: We report that the threshold register is unavailable
@@ -1498,7 +1498,7 @@ static int svm_msr_write_intercept(unsig
         vpmu_do_wrmsr(msr, msr_content);
         break;
=20
-    case MSR_IA32_MC4_MISC: /* Threshold register */
+    case MSR_IA32_MCx_MISC(4): /* Threshold register */
     case MSR_F10_MC4_MISC1 ... MSR_F10_MC4_MISC3:
         /*
          * MCA/MCE: Threshold register is reported to be locked, so we =
ignore
--- 2011-11-23.orig/xen/include/asm-x86/msr-index.h	2011-12-05 =
11:06:39.000000000 +0100
+++ 2011-11-23/xen/include/asm-x86/msr-index.h	2011-12-05 11:21:46.0000000=
00 +0100
@@ -100,58 +100,11 @@
=20
 #define MSR_AMD64_MC0_MASK		0xc0010044
=20
-#define MSR_IA32_MC1_CTL		0x00000404
-#define MSR_IA32_MC1_CTL2		0x00000281
-#define MSR_IA32_MC1_STATUS		0x00000405
-#define MSR_IA32_MC1_ADDR		0x00000406
-#define MSR_IA32_MC1_MISC		0x00000407
-
-#define MSR_IA32_MC2_CTL		0x00000408
-#define MSR_IA32_MC2_CTL2		0x00000282
-#define MSR_IA32_MC2_STATUS		0x00000409
-#define MSR_IA32_MC2_ADDR		0x0000040A
-#define MSR_IA32_MC2_MISC		0x0000040B
-
-#define MSR_IA32_MC3_CTL2		0x00000283
-#define MSR_IA32_MC3_CTL		0x0000040C
-#define MSR_IA32_MC3_STATUS		0x0000040D
-#define MSR_IA32_MC3_ADDR		0x0000040E
-#define MSR_IA32_MC3_MISC		0x0000040F
-
-#define MSR_IA32_MC4_CTL2		0x00000284
-#define MSR_IA32_MC4_CTL		0x00000410
-#define MSR_IA32_MC4_STATUS		0x00000411
-#define MSR_IA32_MC4_ADDR		0x00000412
-#define MSR_IA32_MC4_MISC		0x00000413
-
-#define MSR_IA32_MC5_CTL2		0x00000285
-#define MSR_IA32_MC5_CTL		0x00000414
-#define MSR_IA32_MC5_STATUS		0x00000415
-#define MSR_IA32_MC5_ADDR		0x00000416
-#define MSR_IA32_MC5_MISC		0x00000417
-
-#define MSR_IA32_MC6_CTL2		0x00000286
-#define MSR_IA32_MC6_CTL		0x00000418
-#define MSR_IA32_MC6_STATUS		0x00000419
-#define MSR_IA32_MC6_ADDR		0x0000041A
-#define MSR_IA32_MC6_MISC		0x0000041B
-
-#define MSR_IA32_MC7_CTL2		0x00000287
-#define MSR_IA32_MC7_CTL		0x0000041C
-#define MSR_IA32_MC7_STATUS		0x0000041D
-#define MSR_IA32_MC7_ADDR		0x0000041E
-#define MSR_IA32_MC7_MISC		0x0000041F
-
-#define MSR_IA32_MC8_CTL2		0x00000288
-#define MSR_IA32_MC8_CTL		0x00000420
-#define MSR_IA32_MC8_STATUS		0x00000421
-#define MSR_IA32_MC8_ADDR		0x00000422
-#define MSR_IA32_MC8_MISC		0x00000423
-
 #define MSR_IA32_MCx_CTL(x)		(MSR_IA32_MC0_CTL + 4*(x))
 #define MSR_IA32_MCx_STATUS(x)		(MSR_IA32_MC0_STATUS + 4*(x))
 #define MSR_IA32_MCx_ADDR(x)		(MSR_IA32_MC0_ADDR + 4*(x))
 #define MSR_IA32_MCx_MISC(x)		(MSR_IA32_MC0_MISC + 4*(x))=20
+#define MSR_IA32_MCx_CTL2(x)		(MSR_IA32_MC0_CTL2 + (x))
=20
 #define MSR_AMD64_MCx_MASK(x)		(MSR_AMD64_MC0_MASK + (x))
=20



--=__PartF7D85228.0__=
Content-Type: text/plain; name="x86-mce-msr-names.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-mce-msr-names.patch"

x86: remove redundant MCE related MSR definitions=0A=0ATwo definitions =
(the first register and a macro to calculate the=0Aregister for a given =
bank) are sufficient per kind of register.=0A=0ASigned-off-by: Jan Beulich =
<jbeulich@suse.com>=0A=0A--- 2011-11-23.orig/xen/arch/x86/cpu/mcheck/amd_no=
nfatal.c	2011-12-05 11:38:33.000000000 +0100=0A+++ 2011-11-23/xen/ar=
ch/x86/cpu/mcheck/amd_nonfatal.c	2011-12-05 11:24:15.000000000 =
+0100=0A@@ -144,7 +144,7 @@ static void mce_amd_work_fn(void *data)=0A 		=
uint64_t value;=0A 		uint32_t counter;=0A =0A-		=
value =3D mca_rdmsr(MSR_IA32_MC4_MISC);=0A+		value =3D =
mca_rdmsr(MSR_IA32_MCx_MISC(4));=0A 		/* Only the error counter =
field is of interest=0A 		 * Bit field is described in AMD =
K8 BKDG chapter 6.4.5.5=0A 		 */=0A@@ -174,7 +174,7 @@ static =
void mce_amd_work_fn(void *data)=0A 			value &=3D =
~(0x60FFF00000000ULL);=0A 			/* Counter enable */=0A 	=
		value |=3D (1ULL << 51);=0A-			mca_wrmsr(M=
SR_IA32_MC4_MISC, value);=0A+			mca_wrmsr(MSR_IA32_MCx_MISC=
(4), value);=0A 			wmb();=0A 		}=0A 	=
}=0A@@ -217,7 +217,7 @@ void amd_nonfatal_mcheck_init(struct cpu=0A =0A 	=
	/* hw threshold registers present */=0A 		hw_threshol=
d =3D 1;=0A-		rdmsrl(MSR_IA32_MC4_MISC, value);=0A+		=
rdmsrl(MSR_IA32_MCx_MISC(4), value);=0A =0A 		if (value & (1ULL =
<< 61)) { /* Locked bit */=0A 			/* Locked by BIOS. Not =
available for use */=0A@@ -238,7 +238,7 @@ void amd_nonfatal_mcheck_init(st=
ruct cpu=0A 			value &=3D ~(0x60FFF00000000ULL);=0A 		=
	/* Counter enable */=0A 			value |=3D (1ULL =
<< 51);=0A-			wrmsrl(MSR_IA32_MC4_MISC, value);=0A+		=
	wrmsrl(MSR_IA32_MCx_MISC(4), value);=0A 			/* =
serialize */=0A 			wmb();=0A 			=
printk(XENLOG_INFO "MCA: Use hw thresholding to adjust polling frequency\n"=
);=0A--- 2011-11-23.orig/xen/arch/x86/cpu/mcheck/mce_amd_quirks.c	=
2011-12-05 11:41:00.000000000 +0100=0A+++ 2011-11-23/xen/arch/x86/cpu/mchec=
k/mce_amd_quirks.c	2011-12-05 11:42:03.000000000 +0100=0A@@ -68,8 =
+68,8 @@ int mcequirk_amd_apply(enum mcequirk_amd=0A 		 * TBL =
walk error reporting, which trips off incorrectly=0A 		 * with =
AGP GART & 3ware & Cerberus.=0A 		 */=0A-		wrmsrl(MSR_=
IA32_MC4_CTL, ~(1ULL << 10));=0A-		wrmsrl(MSR_IA32_MC4_STATUS,=
 0ULL);=0A+		wrmsrl(MSR_IA32_MCx_CTL(4), ~(1ULL << 10));=0A+		=
wrmsrl(MSR_IA32_MCx_STATUS(4), 0ULL);=0A 		break;=0A 	=
case MCEQUIRK_F10_GART:=0A 		if (rdmsr_safe(MSR_AMD64_MCx_MASK(4=
), val) =3D=3D 0)=0A--- 2011-11-23.orig/xen/arch/x86/cpu/mcheck/mce_intel.c=
	2011-12-05 11:38:33.000000000 +0100=0A+++ 2011-11-23/xen/arch/x86/c=
pu/mcheck/mce_intel.c	2011-12-05 11:27:53.000000000 +0100=0A@@ -986,7 =
+986,7 @@ static DEFINE_SPINLOCK(cmci_discover_loc=0A  */=0A static int =
do_cmci_discover(int i)=0A {=0A-    unsigned msr =3D MSR_IA32_MC0_CTL2 + =
i;=0A+    unsigned msr =3D MSR_IA32_MCx_CTL2(i);=0A     u64 val;=0A =0A    =
 rdmsrl(msr, val);=0A@@ -1095,7 +1095,7 @@ static void clear_cmci(void)=0A =
            smp_processor_id());=0A =0A     for (i =3D 0; i < nr_mce_banks;=
 i++) {=0A-        unsigned msr =3D MSR_IA32_MC0_CTL2 + i;=0A+        =
unsigned msr =3D MSR_IA32_MCx_CTL2(i);=0A         u64 val;=0A         if =
(!mcabanks_test(i, __get_cpu_var(mce_banks_owned)))=0A             =
continue;=0A--- 2011-11-23.orig/xen/arch/x86/hvm/svm/svm.c	2011-12-05 =
11:38:33.000000000 +0100=0A+++ 2011-11-23/xen/arch/x86/hvm/svm/svm.c	=
2011-12-05 11:25:55.000000000 +0100=0A@@ -1318,7 +1318,7 @@ static int =
svm_msr_read_intercept(unsign=0A         *msr_content =3D v->arch.hvm_svm.g=
uest_sysenter_eip;=0A         break;=0A =0A-    case MSR_IA32_MC4_MISC: /* =
Threshold register */=0A+    case MSR_IA32_MCx_MISC(4): /* Threshold =
register */=0A     case MSR_F10_MC4_MISC1 ... MSR_F10_MC4_MISC3:=0A        =
 /*=0A          * MCA/MCE: We report that the threshold register is =
unavailable=0A@@ -1498,7 +1498,7 @@ static int svm_msr_write_intercept(unsi=
g=0A         vpmu_do_wrmsr(msr, msr_content);=0A         break;=0A =0A-    =
case MSR_IA32_MC4_MISC: /* Threshold register */=0A+    case MSR_IA32_MCx_M=
ISC(4): /* Threshold register */=0A     case MSR_F10_MC4_MISC1 ... =
MSR_F10_MC4_MISC3:=0A         /*=0A          * MCA/MCE: Threshold register =
is reported to be locked, so we ignore=0A--- 2011-11-23.orig/xen/include/as=
m-x86/msr-index.h	2011-12-05 11:06:39.000000000 +0100=0A+++ =
2011-11-23/xen/include/asm-x86/msr-index.h	2011-12-05 11:21:46.0000000=
00 +0100=0A@@ -100,58 +100,11 @@=0A =0A #define MSR_AMD64_MC0_MASK		=
0xc0010044=0A =0A-#define MSR_IA32_MC1_CTL		0x00000404=0A-#defi=
ne MSR_IA32_MC1_CTL2		0x00000281=0A-#define MSR_IA32_MC1_STATUS	=
	0x00000405=0A-#define MSR_IA32_MC1_ADDR		0x00000406=0A-#defi=
ne MSR_IA32_MC1_MISC		0x00000407=0A-=0A-#define MSR_IA32_MC2_CTL	=
	0x00000408=0A-#define MSR_IA32_MC2_CTL2		0x00000282=0A-#defi=
ne MSR_IA32_MC2_STATUS		0x00000409=0A-#define MSR_IA32_MC2_ADDR		=
0x0000040A=0A-#define MSR_IA32_MC2_MISC		0x0000040B=0A-=0A-#define =
MSR_IA32_MC3_CTL2		0x00000283=0A-#define MSR_IA32_MC3_CTL		=
0x0000040C=0A-#define MSR_IA32_MC3_STATUS		0x0000040D=0A-#defi=
ne MSR_IA32_MC3_ADDR		0x0000040E=0A-#define MSR_IA32_MC3_MISC		=
0x0000040F=0A-=0A-#define MSR_IA32_MC4_CTL2		0x00000284=0A-#defi=
ne MSR_IA32_MC4_CTL		0x00000410=0A-#define MSR_IA32_MC4_STATUS	=
	0x00000411=0A-#define MSR_IA32_MC4_ADDR		0x00000412=0A-#defi=
ne MSR_IA32_MC4_MISC		0x00000413=0A-=0A-#define MSR_IA32_MC5_CTL2=
		0x00000285=0A-#define MSR_IA32_MC5_CTL		0x00000414=
=0A-#define MSR_IA32_MC5_STATUS		0x00000415=0A-#define MSR_IA32_MC5_=
ADDR		0x00000416=0A-#define MSR_IA32_MC5_MISC		0x00000417=
=0A-=0A-#define MSR_IA32_MC6_CTL2		0x00000286=0A-#define =
MSR_IA32_MC6_CTL		0x00000418=0A-#define MSR_IA32_MC6_STATUS	=
	0x00000419=0A-#define MSR_IA32_MC6_ADDR		0x0000041A=0A-#defi=
ne MSR_IA32_MC6_MISC		0x0000041B=0A-=0A-#define MSR_IA32_MC7_CTL2=
		0x00000287=0A-#define MSR_IA32_MC7_CTL		0x0000041C=
=0A-#define MSR_IA32_MC7_STATUS		0x0000041D=0A-#define MSR_IA32_MC7_=
ADDR		0x0000041E=0A-#define MSR_IA32_MC7_MISC		0x0000041F=
=0A-=0A-#define MSR_IA32_MC8_CTL2		0x00000288=0A-#define =
MSR_IA32_MC8_CTL		0x00000420=0A-#define MSR_IA32_MC8_STATUS	=
	0x00000421=0A-#define MSR_IA32_MC8_ADDR		0x00000422=0A-#defi=
ne MSR_IA32_MC8_MISC		0x00000423=0A-=0A #define MSR_IA32_MCx_CTL(=
x)		(MSR_IA32_MC0_CTL + 4*(x))=0A #define MSR_IA32_MCx_STATUS(x=
)		(MSR_IA32_MC0_STATUS + 4*(x))=0A #define MSR_IA32_MCx_ADDR(=
x)		(MSR_IA32_MC0_ADDR + 4*(x))=0A #define MSR_IA32_MCx_MISC(x)=
		(MSR_IA32_MC0_MISC + 4*(x)) =0A+#define MSR_IA32_MCx_CTL2(x=
)		(MSR_IA32_MC0_CTL2 + (x))=0A =0A #define MSR_AMD64_MCx_MASK=
(x)		(MSR_AMD64_MC0_MASK + (x))=0A =0A
--=__PartF7D85228.0__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--=__PartF7D85228.0__=--


From xen-devel-bounces@lists.xensource.com Mon Dec 12 15:37:18 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 15:37:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ra7wB-0001XT-4I; Mon, 12 Dec 2011 15:37:07 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <george.shuklin@gmail.com>)
	id 1Ra7wA-0001WT-0d; Mon, 12 Dec 2011 15:37:06 +0000
X-Env-Sender: george.shuklin@gmail.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1323704172!6917635!1
X-Originating-IP: [209.85.214.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29503 invoked from network); 12 Dec 2011 15:36:12 -0000
Received: from mail-bw0-f43.google.com (HELO mail-bw0-f43.google.com)
	(209.85.214.43)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Dec 2011 15:36:12 -0000
Received: by bkbzs2 with SMTP id zs2so18344590bkb.30
	for <multiple recipients>; Mon, 12 Dec 2011 07:36:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=message-id:date:from:user-agent:mime-version:to:cc:subject
	:references:in-reply-to:content-type:content-transfer-encoding;
	bh=D5r7Bjzwx87Kd7GIFJY05EKg9OEstog15llIgUcTRAU=;
	b=Pv7QqdjDxeZy+eihafQO0zfLcWUxi8VikQpmOBIFvwKNkP6XAwiTsVM1EdJSxOMGie
	bXOFCqKTUOw+VYg0O0bqsrVa/5YCwG0Ax6QmSWxIPllP6Ro6xtPA6AFw0mpa7M++KXKH
	e+MbNlM7I3UD/W6jHsMRN0sdPHzSlWABIdnuY=
Received: by 10.205.127.2 with SMTP id gy2mr8887022bkc.87.1323704172244;
	Mon, 12 Dec 2011 07:36:12 -0800 (PST)
Received: from [192.168.40.44] (officecvt.selectel.ru. [188.93.16.50])
	by mx.google.com with ESMTPS id d2sm32625525bky.11.2011.12.12.07.36.10
	(version=SSLv3 cipher=OTHER); Mon, 12 Dec 2011 07:36:11 -0800 (PST)
Message-ID: <4EE61F69.6020407@gmail.com>
Date: Mon, 12 Dec 2011 19:36:09 +0400
From: George Shuklin <george.shuklin@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:9.0) Gecko/20111209 Thunderbird/9.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <4EE2665C.8090602@gmail.com>
	<1323689477.20077.173.camel@zakaz.uk.xensource.com>
	<1323698103.20077.216.camel@zakaz.uk.xensource.com>
In-Reply-To: <1323698103.20077.216.camel@zakaz.uk.xensource.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"xen-api@lists.xensource.com" <xen-api@lists.xensource.com>
Subject: Re: [Xen-devel] bug in xenstored? No notification to subscription
 on @introduceDomain
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


On 12.12.2011 17:55, Ian Campbell wrote:
> On Mon, 2011-12-12 at 11:31 +0000, Ian Campbell wrote:
>> Does the app do any other XS stuff, e.g. other watches or read/write? Do
>> these stop working also?
> One other question -- does your app use threading anywhere apart from
> the one it gets from libxenstore?
>
Yes, it is!

We using multithread model (that why we wrote an alternative library to 
access xenstore - to get normal multithread subscription). But this 
problem happens before we start multithread, with single-thread application.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 15:37:18 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 15:37:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ra7wB-0001XT-4I; Mon, 12 Dec 2011 15:37:07 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <george.shuklin@gmail.com>)
	id 1Ra7wA-0001WT-0d; Mon, 12 Dec 2011 15:37:06 +0000
X-Env-Sender: george.shuklin@gmail.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1323704172!6917635!1
X-Originating-IP: [209.85.214.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29503 invoked from network); 12 Dec 2011 15:36:12 -0000
Received: from mail-bw0-f43.google.com (HELO mail-bw0-f43.google.com)
	(209.85.214.43)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Dec 2011 15:36:12 -0000
Received: by bkbzs2 with SMTP id zs2so18344590bkb.30
	for <multiple recipients>; Mon, 12 Dec 2011 07:36:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=message-id:date:from:user-agent:mime-version:to:cc:subject
	:references:in-reply-to:content-type:content-transfer-encoding;
	bh=D5r7Bjzwx87Kd7GIFJY05EKg9OEstog15llIgUcTRAU=;
	b=Pv7QqdjDxeZy+eihafQO0zfLcWUxi8VikQpmOBIFvwKNkP6XAwiTsVM1EdJSxOMGie
	bXOFCqKTUOw+VYg0O0bqsrVa/5YCwG0Ax6QmSWxIPllP6Ro6xtPA6AFw0mpa7M++KXKH
	e+MbNlM7I3UD/W6jHsMRN0sdPHzSlWABIdnuY=
Received: by 10.205.127.2 with SMTP id gy2mr8887022bkc.87.1323704172244;
	Mon, 12 Dec 2011 07:36:12 -0800 (PST)
Received: from [192.168.40.44] (officecvt.selectel.ru. [188.93.16.50])
	by mx.google.com with ESMTPS id d2sm32625525bky.11.2011.12.12.07.36.10
	(version=SSLv3 cipher=OTHER); Mon, 12 Dec 2011 07:36:11 -0800 (PST)
Message-ID: <4EE61F69.6020407@gmail.com>
Date: Mon, 12 Dec 2011 19:36:09 +0400
From: George Shuklin <george.shuklin@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:9.0) Gecko/20111209 Thunderbird/9.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <4EE2665C.8090602@gmail.com>
	<1323689477.20077.173.camel@zakaz.uk.xensource.com>
	<1323698103.20077.216.camel@zakaz.uk.xensource.com>
In-Reply-To: <1323698103.20077.216.camel@zakaz.uk.xensource.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"xen-api@lists.xensource.com" <xen-api@lists.xensource.com>
Subject: Re: [Xen-devel] bug in xenstored? No notification to subscription
 on @introduceDomain
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


On 12.12.2011 17:55, Ian Campbell wrote:
> On Mon, 2011-12-12 at 11:31 +0000, Ian Campbell wrote:
>> Does the app do any other XS stuff, e.g. other watches or read/write? Do
>> these stop working also?
> One other question -- does your app use threading anywhere apart from
> the one it gets from libxenstore?
>
Yes, it is!

We using multithread model (that why we wrote an alternative library to 
access xenstore - to get normal multithread subscription). But this 
problem happens before we start multithread, with single-thread application.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 15:43:20 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 15: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.xensource.com>)
	id 1Ra81u-0001vp-VX; Mon, 12 Dec 2011 15:43:02 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Ra81t-0001vk-1L
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 15:43:01 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1323704526!5239099!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21809 invoked from network); 12 Dec 2011 15:42:07 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-9.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 12 Dec 2011 15:42:07 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 12 Dec 2011 15:42:06 +0000
Message-Id: <4EE62F140200007800067003@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 12 Dec 2011 15:43:00 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartF5DA5014.0__="
Subject: [Xen-devel] [PATCH] remove the use of -Wno-unused-value
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__PartF5DA5014.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

It has been hiding actual mistakes, and there are not too many changes
necessary to make things build without suppressing this warning.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- 2011-12-12.orig/Config.mk	2011-12-12 15:46:14.000000000 +0100
+++ 2011-12-12/Config.mk	2011-11-30 17:49:42.000000000 +0100
@@ -157,10 +157,6 @@ CFLAGS +=3D -std=3Dgnu99
=20
 CFLAGS +=3D -Wall -Wstrict-prototypes
=20
-# -Wunused-value makes GCC 4.x too aggressive for my taste: ignoring the
-# result of any casted expression causes a warning.
-CFLAGS +=3D -Wno-unused-value
-
 # Clang complains about macros that expand to 'if ( ( foo =3D=3D bar ) ) =
...'
 # and is over-zealous with the printf format lint
 CFLAGS-$(clang) +=3D -Wno-parentheses -Wno-format
--- 2011-12-12.orig/tools/libfsimage/common/fsimage_grub.h	2010-04-19 =
09:12:58.000000000 +0200
+++ 2011-12-12/tools/libfsimage/common/fsimage_grub.h	2011-12-12 =
15:47:35.000000000 +0100
@@ -57,7 +57,7 @@ typedef struct fsig_plugin_ops {
 #define	disk_read_func (*fsig_disk_read_junk())
 #define	disk_read_hook (*fsig_disk_read_junk())
 #define	print_possibilities 0
-#define	noisy_printf
+#define	noisy_printf(fmt...)
=20
 #define	grub_memset memset
 #define	grub_memmove memmove
--- 2011-12-12.orig/xen/arch/x86/debug.c	2011-12-12 15:46:14.0000000=
00 +0100
+++ 2011-12-12/xen/arch/x86/debug.c	2011-11-30 17:50:55.000000000 =
+0100
@@ -37,8 +37,8 @@
 #define DBGP1(...) {(kdbdbg>1) ? kdbp(__VA_ARGS__):0;}
 #define DBGP2(...) {(kdbdbg>2) ? kdbp(__VA_ARGS__):0;}
 #else
-#define DBGP1(...) {0;}
-#define DBGP2(...) {0;}
+#define DBGP1(...) ((void)0)
+#define DBGP2(...) ((void)0)
 #endif
=20
 /* Returns: mfn for the given (hvm guest) vaddr */
--- 2011-12-12.orig/xen/arch/x86/hvm/svm/vpmu.c	2011-12-12 15:46:14.0000000=
00 +0100
+++ 2011-12-12/xen/arch/x86/hvm/svm/vpmu.c	2011-12-01 11:35:58.0000000=
00 +0100
@@ -154,7 +154,7 @@ static int amd_vpmu_do_interrupt(struct=20
     if ( GET_APIC_DELIVERY_MODE(vlapic_lvtpc) =3D=3D APIC_MODE_FIXED )
         vlapic_set_irq(vcpu_vlapic(v), int_vec, 0);
     else
-        test_and_set_bool(v->nmi_pending);
+        v->nmi_pending =3D 1;
=20
     return 1;
 }
--- 2011-12-12.orig/xen/arch/x86/hvm/vmx/vpmu_core2.c	2011-12-12 =
15:46:14.000000000 +0100
+++ 2011-12-12/xen/arch/x86/hvm/vmx/vpmu_core2.c	2011-12-01 =
11:36:37.000000000 +0100
@@ -574,7 +574,7 @@ static int core2_vpmu_do_interrupt(struc
     if ( GET_APIC_DELIVERY_MODE(vlapic_lvtpc) =3D=3D APIC_MODE_FIXED )
         vlapic_set_irq(vcpu_vlapic(v), int_vec, 0);
     else
-        test_and_set_bool(v->nmi_pending);
+        v->nmi_pending =3D 1;
     return 1;
 }
=20
--- 2011-12-12.orig/xen/arch/x86/oprofile/nmi_int.c	2011-12-12 =
15:46:14.000000000 +0100
+++ 2011-12-12/xen/arch/x86/oprofile/nmi_int.c	2011-11-30 18:01:11.0000000=
00 +0100
@@ -92,7 +92,7 @@ static int nmi_callback(struct cpu_user_
 		send_guest_vcpu_virq(current, VIRQ_XENOPROF);
=20
 	if ( ovf =3D=3D 2 )=20
-                test_and_set_bool(current->nmi_pending);
+                current->nmi_pending =3D 1;
 	return 1;
 }
 =20
--- 2011-12-12.orig/xen/include/asm-x86/debugger.h	2011-12-12 =
15:46:14.000000000 +0100
+++ 2011-12-12/xen/include/asm-x86/debugger.h	2011-11-30 17:58:20.0000000=
00 +0100
@@ -55,7 +55,12 @@ static inline int debugger_trap_fatal(
=20
 #else
=20
-#define debugger_trap_fatal(v, r) (0)
+static inline int debugger_trap_fatal(
+    unsigned int vector, struct cpu_user_regs *regs)
+{
+    return 0;
+}
+
 #define debugger_trap_immediate() ((void)0)
=20
 #endif
--- 2011-12-12.orig/xen/include/asm-x86/hvm/hvm.h	2011-12-12 =
15:46:14.000000000 +0100
+++ 2011-12-12/xen/include/asm-x86/hvm/hvm.h	2011-12-01 12:15:02.0000000=
00 +0100
@@ -235,7 +235,7 @@ int hvm_girq_dest_2_vcpu_id(struct domai
 #define hvm_long_mode_enabled(v) \
     ((v)->arch.hvm_vcpu.guest_efer & EFER_LMA)
 #else
-#define hvm_long_mode_enabled(v) (v,0)
+#define hvm_long_mode_enabled(v) ((void)(v),0)
 #endif
=20
 enum hvm_intblk
--- 2011-12-12.orig/xen/include/xen/tmem_xen.h	2011-12-12 15:46:14.0000000=
00 +0100
+++ 2011-12-12/xen/include/xen/tmem_xen.h	2011-11-30 17:55:22.0000000=
00 +0100
@@ -365,7 +365,7 @@ static inline int tmh_page_cmp(pfp_t *pf
     // FIXME: code in assembly?
 ASSERT(p1 !=3D NULL);
 ASSERT(p2 !=3D NULL);
-    for ( i =3D PAGE_SIZE/sizeof(uint64_t); i && *p1 =3D=3D *p2; i--, =
*p1++, *p2++ );
+    for ( i =3D PAGE_SIZE/sizeof(uint64_t); i && *p1 =3D=3D *p2; i--, =
p1++, p2++ );
     if ( !i )
         return 0;
     if ( *p1 < *p2 )
@@ -386,7 +386,7 @@ static inline int tmh_pcd_cmp(void *va1,
     if ( len1 > len2 )
         return 1;
     ASSERT(len1 =3D=3D len2);
-    for ( i =3D len2; i && *p1 =3D=3D *p2; i--, *p1++, *p2++ );
+    for ( i =3D len2; i && *p1 =3D=3D *p2; i--, p1++, p2++ );
     if ( !i )
         return 0;
     if ( *p1 < *p2 )
@@ -413,7 +413,7 @@ static inline int tmh_tze_pfp_cmp(pfp_t=20
     if ( pfp_len > tze_len )
         return 1;
     ASSERT(pfp_len =3D=3D tze_len);
-    for ( i =3D tze_len/sizeof(uint64_t); i && *p1 =3D=3D *p2; i--, =
*p1++, *p2++ );
+    for ( i =3D tze_len/sizeof(uint64_t); i && *p1 =3D=3D *p2; i--, p1++, =
p2++ );
     if ( !i )
         return 0;
     if ( *p1 < *p2 )
--- 2011-12-12.orig/xen/include/xsm/xsm.h	2011-12-12 15:46:14.0000000=
00 +0100
+++ 2011-12-12/xen/include/xsm/xsm.h	2011-12-12 15:23:49.000000000 =
+0100
@@ -163,7 +163,7 @@ extern struct xsm_operations *xsm_ops;
 static inline void xsm_security_domaininfo (struct domain *d,
                                         struct xen_domctl_getdomaininfo =
*info)
 {
-    xsm_call(security_domaininfo(d, info));
+    (void)xsm_call(security_domaininfo(d, info));
 }
=20
 static inline int xsm_setvcpucontext(struct domain *d)
@@ -310,7 +310,7 @@ static inline int xsm_evtchn_interdomain
=20
 static inline void xsm_evtchn_close_post (struct evtchn *chn)
 {
-    xsm_call(evtchn_close_post(chn));
+    (void)xsm_call(evtchn_close_post(chn));
 }
=20
 static inline int xsm_evtchn_send (struct domain *d, struct evtchn *chn)
@@ -366,7 +366,7 @@ static inline int xsm_alloc_security_dom
=20
 static inline void xsm_free_security_domain (struct domain *d)
 {
-    xsm_call(free_security_domain(d));
+    (void)xsm_call(free_security_domain(d));
 }
=20
 static inline int xsm_alloc_security_evtchn (struct evtchn *chn)
@@ -376,7 +376,7 @@ static inline int xsm_alloc_security_evt
=20
 static inline void xsm_free_security_evtchn (struct evtchn *chn)
 {
-    xsm_call(free_security_evtchn(chn));
+    (void)xsm_call(free_security_evtchn(chn));
 }
=20
 static inline int xsm_memory_adjust_reservation (struct domain *d1, =
struct



--=__PartF5DA5014.0__=
Content-Type: text/plain; name="no-Wno-unused-value.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="no-Wno-unused-value.patch"

remove the use of -Wno-unused-value=0A=0AIt has been hiding actual =
mistakes, and there are not too many changes=0Anecessary to make things =
build without suppressing this warning.=0A=0ASigned-off-by: Jan Beulich =
<jbeulich@suse.com>=0A=0A--- 2011-12-12.orig/Config.mk	2011-12-12 =
15:46:14.000000000 +0100=0A+++ 2011-12-12/Config.mk	2011-11-30 =
17:49:42.000000000 +0100=0A@@ -157,10 +157,6 @@ CFLAGS +=3D -std=3Dgnu99=0A=
 =0A CFLAGS +=3D -Wall -Wstrict-prototypes=0A =0A-# -Wunused-value makes =
GCC 4.x too aggressive for my taste: ignoring the=0A-# result of any =
casted expression causes a warning.=0A-CFLAGS +=3D -Wno-unused-value=0A-=0A=
 # Clang complains about macros that expand to 'if ( ( foo =3D=3D bar ) ) =
...'=0A # and is over-zealous with the printf format lint=0A CFLAGS-$(clang=
) +=3D -Wno-parentheses -Wno-format=0A--- 2011-12-12.orig/tools/libfsimage/=
common/fsimage_grub.h	2010-04-19 09:12:58.000000000 +0200=0A+++ =
2011-12-12/tools/libfsimage/common/fsimage_grub.h	2011-12-12 =
15:47:35.000000000 +0100=0A@@ -57,7 +57,7 @@ typedef struct fsig_plugin_ops=
 {=0A #define	disk_read_func (*fsig_disk_read_junk())=0A #define	=
disk_read_hook (*fsig_disk_read_junk())=0A #define	print_possibilities=
 0=0A-#define	noisy_printf=0A+#define	noisy_printf(fmt...)=0A =0A =
#define	grub_memset memset=0A #define	grub_memmove memmove=0A--- =
2011-12-12.orig/xen/arch/x86/debug.c	2011-12-12 15:46:14.000000000 =
+0100=0A+++ 2011-12-12/xen/arch/x86/debug.c	2011-11-30 17:50:55.0000000=
00 +0100=0A@@ -37,8 +37,8 @@=0A #define DBGP1(...) {(kdbdbg>1) ? kdbp(__VA_=
ARGS__):0;}=0A #define DBGP2(...) {(kdbdbg>2) ? kdbp(__VA_ARGS__):0;}=0A =
#else=0A-#define DBGP1(...) {0;}=0A-#define DBGP2(...) {0;}=0A+#define =
DBGP1(...) ((void)0)=0A+#define DBGP2(...) ((void)0)=0A #endif=0A =0A /* =
Returns: mfn for the given (hvm guest) vaddr */=0A--- 2011-12-12.orig/xen/a=
rch/x86/hvm/svm/vpmu.c	2011-12-12 15:46:14.000000000 +0100=0A+++ =
2011-12-12/xen/arch/x86/hvm/svm/vpmu.c	2011-12-01 11:35:58.000000000 =
+0100=0A@@ -154,7 +154,7 @@ static int amd_vpmu_do_interrupt(struct =0A    =
 if ( GET_APIC_DELIVERY_MODE(vlapic_lvtpc) =3D=3D APIC_MODE_FIXED )=0A     =
    vlapic_set_irq(vcpu_vlapic(v), int_vec, 0);=0A     else=0A-        =
test_and_set_bool(v->nmi_pending);=0A+        v->nmi_pending =3D 1;=0A =0A =
    return 1;=0A }=0A--- 2011-12-12.orig/xen/arch/x86/hvm/vmx/vpmu_core2.c	=
2011-12-12 15:46:14.000000000 +0100=0A+++ 2011-12-12/xen/arch/x86/hvm/vmx/v=
pmu_core2.c	2011-12-01 11:36:37.000000000 +0100=0A@@ -574,7 +574,7 @@ =
static int core2_vpmu_do_interrupt(struc=0A     if ( GET_APIC_DELIVERY_MODE=
(vlapic_lvtpc) =3D=3D APIC_MODE_FIXED )=0A         vlapic_set_irq(vcpu_vlap=
ic(v), int_vec, 0);=0A     else=0A-        test_and_set_bool(v->nmi_pending=
);=0A+        v->nmi_pending =3D 1;=0A     return 1;=0A }=0A =0A--- =
2011-12-12.orig/xen/arch/x86/oprofile/nmi_int.c	2011-12-12 15:46:14.0000000=
00 +0100=0A+++ 2011-12-12/xen/arch/x86/oprofile/nmi_int.c	2011-11-30 =
18:01:11.000000000 +0100=0A@@ -92,7 +92,7 @@ static int nmi_callback(struct=
 cpu_user_=0A 		send_guest_vcpu_virq(current, VIRQ_XENOPROF);=0A =
=0A 	if ( ovf =3D=3D 2 ) =0A-                test_and_set_bool(current->=
nmi_pending);=0A+                current->nmi_pending =3D 1;=0A 	=
return 1;=0A }=0A  =0A--- 2011-12-12.orig/xen/include/asm-x86/debugger.h	=
2011-12-12 15:46:14.000000000 +0100=0A+++ 2011-12-12/xen/include/asm-x86/de=
bugger.h	2011-11-30 17:58:20.000000000 +0100=0A@@ -55,7 +55,12 @@ =
static inline int debugger_trap_fatal(=0A =0A #else=0A =0A-#define =
debugger_trap_fatal(v, r) (0)=0A+static inline int debugger_trap_fatal(=0A+=
    unsigned int vector, struct cpu_user_regs *regs)=0A+{=0A+    return =
0;=0A+}=0A+=0A #define debugger_trap_immediate() ((void)0)=0A =0A =
#endif=0A--- 2011-12-12.orig/xen/include/asm-x86/hvm/hvm.h	2011-12-12 =
15:46:14.000000000 +0100=0A+++ 2011-12-12/xen/include/asm-x86/hvm/hvm.h	=
2011-12-01 12:15:02.000000000 +0100=0A@@ -235,7 +235,7 @@ int hvm_girq_dest=
_2_vcpu_id(struct domai=0A #define hvm_long_mode_enabled(v) \=0A     =
((v)->arch.hvm_vcpu.guest_efer & EFER_LMA)=0A #else=0A-#define hvm_long_mod=
e_enabled(v) (v,0)=0A+#define hvm_long_mode_enabled(v) ((void)(v),0)=0A =
#endif=0A =0A enum hvm_intblk=0A--- 2011-12-12.orig/xen/include/xen/tmem_xe=
n.h	2011-12-12 15:46:14.000000000 +0100=0A+++ 2011-12-12/xen/include/xe=
n/tmem_xen.h	2011-11-30 17:55:22.000000000 +0100=0A@@ -365,7 +365,7 @@ =
static inline int tmh_page_cmp(pfp_t *pf=0A     // FIXME: code in =
assembly?=0A ASSERT(p1 !=3D NULL);=0A ASSERT(p2 !=3D NULL);=0A-    for ( i =
=3D PAGE_SIZE/sizeof(uint64_t); i && *p1 =3D=3D *p2; i--, *p1++, *p2++ =
);=0A+    for ( i =3D PAGE_SIZE/sizeof(uint64_t); i && *p1 =3D=3D *p2; =
i--, p1++, p2++ );=0A     if ( !i )=0A         return 0;=0A     if ( *p1 < =
*p2 )=0A@@ -386,7 +386,7 @@ static inline int tmh_pcd_cmp(void *va1,=0A    =
 if ( len1 > len2 )=0A         return 1;=0A     ASSERT(len1 =3D=3D =
len2);=0A-    for ( i =3D len2; i && *p1 =3D=3D *p2; i--, *p1++, *p2++ =
);=0A+    for ( i =3D len2; i && *p1 =3D=3D *p2; i--, p1++, p2++ );=0A     =
if ( !i )=0A         return 0;=0A     if ( *p1 < *p2 )=0A@@ -413,7 +413,7 =
@@ static inline int tmh_tze_pfp_cmp(pfp_t =0A     if ( pfp_len > tze_len =
)=0A         return 1;=0A     ASSERT(pfp_len =3D=3D tze_len);=0A-    for ( =
i =3D tze_len/sizeof(uint64_t); i && *p1 =3D=3D *p2; i--, *p1++, *p2++ =
);=0A+    for ( i =3D tze_len/sizeof(uint64_t); i && *p1 =3D=3D *p2; i--, =
p1++, p2++ );=0A     if ( !i )=0A         return 0;=0A     if ( *p1 < *p2 =
)=0A--- 2011-12-12.orig/xen/include/xsm/xsm.h	2011-12-12 15:46:14.0000000=
00 +0100=0A+++ 2011-12-12/xen/include/xsm/xsm.h	2011-12-12 15:23:49.0000000=
00 +0100=0A@@ -163,7 +163,7 @@ extern struct xsm_operations *xsm_ops;=0A =
static inline void xsm_security_domaininfo (struct domain *d,=0A           =
                              struct xen_domctl_getdomaininfo *info)=0A =
{=0A-    xsm_call(security_domaininfo(d, info));=0A+    (void)xsm_call(secu=
rity_domaininfo(d, info));=0A }=0A =0A static inline int xsm_setvcpucontext=
(struct domain *d)=0A@@ -310,7 +310,7 @@ static inline int xsm_evtchn_inter=
domain=0A =0A static inline void xsm_evtchn_close_post (struct evtchn =
*chn)=0A {=0A-    xsm_call(evtchn_close_post(chn));=0A+    (void)xsm_call(e=
vtchn_close_post(chn));=0A }=0A =0A static inline int xsm_evtchn_send =
(struct domain *d, struct evtchn *chn)=0A@@ -366,7 +366,7 @@ static inline =
int xsm_alloc_security_dom=0A =0A static inline void xsm_free_security_doma=
in (struct domain *d)=0A {=0A-    xsm_call(free_security_domain(d));=0A+   =
 (void)xsm_call(free_security_domain(d));=0A }=0A =0A static inline int =
xsm_alloc_security_evtchn (struct evtchn *chn)=0A@@ -376,7 +376,7 @@ =
static inline int xsm_alloc_security_evt=0A =0A static inline void =
xsm_free_security_evtchn (struct evtchn *chn)=0A {=0A-    xsm_call(free_sec=
urity_evtchn(chn));=0A+    (void)xsm_call(free_security_evtchn(chn));=0A =
}=0A =0A static inline int xsm_memory_adjust_reservation (struct domain =
*d1, struct=0A
--=__PartF5DA5014.0__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--=__PartF5DA5014.0__=--


From xen-devel-bounces@lists.xensource.com Mon Dec 12 15:43:20 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 15: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.xensource.com>)
	id 1Ra81u-0001vp-VX; Mon, 12 Dec 2011 15:43:02 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Ra81t-0001vk-1L
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 15:43:01 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1323704526!5239099!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21809 invoked from network); 12 Dec 2011 15:42:07 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-9.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 12 Dec 2011 15:42:07 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 12 Dec 2011 15:42:06 +0000
Message-Id: <4EE62F140200007800067003@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 12 Dec 2011 15:43:00 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartF5DA5014.0__="
Subject: [Xen-devel] [PATCH] remove the use of -Wno-unused-value
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__PartF5DA5014.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

It has been hiding actual mistakes, and there are not too many changes
necessary to make things build without suppressing this warning.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- 2011-12-12.orig/Config.mk	2011-12-12 15:46:14.000000000 +0100
+++ 2011-12-12/Config.mk	2011-11-30 17:49:42.000000000 +0100
@@ -157,10 +157,6 @@ CFLAGS +=3D -std=3Dgnu99
=20
 CFLAGS +=3D -Wall -Wstrict-prototypes
=20
-# -Wunused-value makes GCC 4.x too aggressive for my taste: ignoring the
-# result of any casted expression causes a warning.
-CFLAGS +=3D -Wno-unused-value
-
 # Clang complains about macros that expand to 'if ( ( foo =3D=3D bar ) ) =
...'
 # and is over-zealous with the printf format lint
 CFLAGS-$(clang) +=3D -Wno-parentheses -Wno-format
--- 2011-12-12.orig/tools/libfsimage/common/fsimage_grub.h	2010-04-19 =
09:12:58.000000000 +0200
+++ 2011-12-12/tools/libfsimage/common/fsimage_grub.h	2011-12-12 =
15:47:35.000000000 +0100
@@ -57,7 +57,7 @@ typedef struct fsig_plugin_ops {
 #define	disk_read_func (*fsig_disk_read_junk())
 #define	disk_read_hook (*fsig_disk_read_junk())
 #define	print_possibilities 0
-#define	noisy_printf
+#define	noisy_printf(fmt...)
=20
 #define	grub_memset memset
 #define	grub_memmove memmove
--- 2011-12-12.orig/xen/arch/x86/debug.c	2011-12-12 15:46:14.0000000=
00 +0100
+++ 2011-12-12/xen/arch/x86/debug.c	2011-11-30 17:50:55.000000000 =
+0100
@@ -37,8 +37,8 @@
 #define DBGP1(...) {(kdbdbg>1) ? kdbp(__VA_ARGS__):0;}
 #define DBGP2(...) {(kdbdbg>2) ? kdbp(__VA_ARGS__):0;}
 #else
-#define DBGP1(...) {0;}
-#define DBGP2(...) {0;}
+#define DBGP1(...) ((void)0)
+#define DBGP2(...) ((void)0)
 #endif
=20
 /* Returns: mfn for the given (hvm guest) vaddr */
--- 2011-12-12.orig/xen/arch/x86/hvm/svm/vpmu.c	2011-12-12 15:46:14.0000000=
00 +0100
+++ 2011-12-12/xen/arch/x86/hvm/svm/vpmu.c	2011-12-01 11:35:58.0000000=
00 +0100
@@ -154,7 +154,7 @@ static int amd_vpmu_do_interrupt(struct=20
     if ( GET_APIC_DELIVERY_MODE(vlapic_lvtpc) =3D=3D APIC_MODE_FIXED )
         vlapic_set_irq(vcpu_vlapic(v), int_vec, 0);
     else
-        test_and_set_bool(v->nmi_pending);
+        v->nmi_pending =3D 1;
=20
     return 1;
 }
--- 2011-12-12.orig/xen/arch/x86/hvm/vmx/vpmu_core2.c	2011-12-12 =
15:46:14.000000000 +0100
+++ 2011-12-12/xen/arch/x86/hvm/vmx/vpmu_core2.c	2011-12-01 =
11:36:37.000000000 +0100
@@ -574,7 +574,7 @@ static int core2_vpmu_do_interrupt(struc
     if ( GET_APIC_DELIVERY_MODE(vlapic_lvtpc) =3D=3D APIC_MODE_FIXED )
         vlapic_set_irq(vcpu_vlapic(v), int_vec, 0);
     else
-        test_and_set_bool(v->nmi_pending);
+        v->nmi_pending =3D 1;
     return 1;
 }
=20
--- 2011-12-12.orig/xen/arch/x86/oprofile/nmi_int.c	2011-12-12 =
15:46:14.000000000 +0100
+++ 2011-12-12/xen/arch/x86/oprofile/nmi_int.c	2011-11-30 18:01:11.0000000=
00 +0100
@@ -92,7 +92,7 @@ static int nmi_callback(struct cpu_user_
 		send_guest_vcpu_virq(current, VIRQ_XENOPROF);
=20
 	if ( ovf =3D=3D 2 )=20
-                test_and_set_bool(current->nmi_pending);
+                current->nmi_pending =3D 1;
 	return 1;
 }
 =20
--- 2011-12-12.orig/xen/include/asm-x86/debugger.h	2011-12-12 =
15:46:14.000000000 +0100
+++ 2011-12-12/xen/include/asm-x86/debugger.h	2011-11-30 17:58:20.0000000=
00 +0100
@@ -55,7 +55,12 @@ static inline int debugger_trap_fatal(
=20
 #else
=20
-#define debugger_trap_fatal(v, r) (0)
+static inline int debugger_trap_fatal(
+    unsigned int vector, struct cpu_user_regs *regs)
+{
+    return 0;
+}
+
 #define debugger_trap_immediate() ((void)0)
=20
 #endif
--- 2011-12-12.orig/xen/include/asm-x86/hvm/hvm.h	2011-12-12 =
15:46:14.000000000 +0100
+++ 2011-12-12/xen/include/asm-x86/hvm/hvm.h	2011-12-01 12:15:02.0000000=
00 +0100
@@ -235,7 +235,7 @@ int hvm_girq_dest_2_vcpu_id(struct domai
 #define hvm_long_mode_enabled(v) \
     ((v)->arch.hvm_vcpu.guest_efer & EFER_LMA)
 #else
-#define hvm_long_mode_enabled(v) (v,0)
+#define hvm_long_mode_enabled(v) ((void)(v),0)
 #endif
=20
 enum hvm_intblk
--- 2011-12-12.orig/xen/include/xen/tmem_xen.h	2011-12-12 15:46:14.0000000=
00 +0100
+++ 2011-12-12/xen/include/xen/tmem_xen.h	2011-11-30 17:55:22.0000000=
00 +0100
@@ -365,7 +365,7 @@ static inline int tmh_page_cmp(pfp_t *pf
     // FIXME: code in assembly?
 ASSERT(p1 !=3D NULL);
 ASSERT(p2 !=3D NULL);
-    for ( i =3D PAGE_SIZE/sizeof(uint64_t); i && *p1 =3D=3D *p2; i--, =
*p1++, *p2++ );
+    for ( i =3D PAGE_SIZE/sizeof(uint64_t); i && *p1 =3D=3D *p2; i--, =
p1++, p2++ );
     if ( !i )
         return 0;
     if ( *p1 < *p2 )
@@ -386,7 +386,7 @@ static inline int tmh_pcd_cmp(void *va1,
     if ( len1 > len2 )
         return 1;
     ASSERT(len1 =3D=3D len2);
-    for ( i =3D len2; i && *p1 =3D=3D *p2; i--, *p1++, *p2++ );
+    for ( i =3D len2; i && *p1 =3D=3D *p2; i--, p1++, p2++ );
     if ( !i )
         return 0;
     if ( *p1 < *p2 )
@@ -413,7 +413,7 @@ static inline int tmh_tze_pfp_cmp(pfp_t=20
     if ( pfp_len > tze_len )
         return 1;
     ASSERT(pfp_len =3D=3D tze_len);
-    for ( i =3D tze_len/sizeof(uint64_t); i && *p1 =3D=3D *p2; i--, =
*p1++, *p2++ );
+    for ( i =3D tze_len/sizeof(uint64_t); i && *p1 =3D=3D *p2; i--, p1++, =
p2++ );
     if ( !i )
         return 0;
     if ( *p1 < *p2 )
--- 2011-12-12.orig/xen/include/xsm/xsm.h	2011-12-12 15:46:14.0000000=
00 +0100
+++ 2011-12-12/xen/include/xsm/xsm.h	2011-12-12 15:23:49.000000000 =
+0100
@@ -163,7 +163,7 @@ extern struct xsm_operations *xsm_ops;
 static inline void xsm_security_domaininfo (struct domain *d,
                                         struct xen_domctl_getdomaininfo =
*info)
 {
-    xsm_call(security_domaininfo(d, info));
+    (void)xsm_call(security_domaininfo(d, info));
 }
=20
 static inline int xsm_setvcpucontext(struct domain *d)
@@ -310,7 +310,7 @@ static inline int xsm_evtchn_interdomain
=20
 static inline void xsm_evtchn_close_post (struct evtchn *chn)
 {
-    xsm_call(evtchn_close_post(chn));
+    (void)xsm_call(evtchn_close_post(chn));
 }
=20
 static inline int xsm_evtchn_send (struct domain *d, struct evtchn *chn)
@@ -366,7 +366,7 @@ static inline int xsm_alloc_security_dom
=20
 static inline void xsm_free_security_domain (struct domain *d)
 {
-    xsm_call(free_security_domain(d));
+    (void)xsm_call(free_security_domain(d));
 }
=20
 static inline int xsm_alloc_security_evtchn (struct evtchn *chn)
@@ -376,7 +376,7 @@ static inline int xsm_alloc_security_evt
=20
 static inline void xsm_free_security_evtchn (struct evtchn *chn)
 {
-    xsm_call(free_security_evtchn(chn));
+    (void)xsm_call(free_security_evtchn(chn));
 }
=20
 static inline int xsm_memory_adjust_reservation (struct domain *d1, =
struct



--=__PartF5DA5014.0__=
Content-Type: text/plain; name="no-Wno-unused-value.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="no-Wno-unused-value.patch"

remove the use of -Wno-unused-value=0A=0AIt has been hiding actual =
mistakes, and there are not too many changes=0Anecessary to make things =
build without suppressing this warning.=0A=0ASigned-off-by: Jan Beulich =
<jbeulich@suse.com>=0A=0A--- 2011-12-12.orig/Config.mk	2011-12-12 =
15:46:14.000000000 +0100=0A+++ 2011-12-12/Config.mk	2011-11-30 =
17:49:42.000000000 +0100=0A@@ -157,10 +157,6 @@ CFLAGS +=3D -std=3Dgnu99=0A=
 =0A CFLAGS +=3D -Wall -Wstrict-prototypes=0A =0A-# -Wunused-value makes =
GCC 4.x too aggressive for my taste: ignoring the=0A-# result of any =
casted expression causes a warning.=0A-CFLAGS +=3D -Wno-unused-value=0A-=0A=
 # Clang complains about macros that expand to 'if ( ( foo =3D=3D bar ) ) =
...'=0A # and is over-zealous with the printf format lint=0A CFLAGS-$(clang=
) +=3D -Wno-parentheses -Wno-format=0A--- 2011-12-12.orig/tools/libfsimage/=
common/fsimage_grub.h	2010-04-19 09:12:58.000000000 +0200=0A+++ =
2011-12-12/tools/libfsimage/common/fsimage_grub.h	2011-12-12 =
15:47:35.000000000 +0100=0A@@ -57,7 +57,7 @@ typedef struct fsig_plugin_ops=
 {=0A #define	disk_read_func (*fsig_disk_read_junk())=0A #define	=
disk_read_hook (*fsig_disk_read_junk())=0A #define	print_possibilities=
 0=0A-#define	noisy_printf=0A+#define	noisy_printf(fmt...)=0A =0A =
#define	grub_memset memset=0A #define	grub_memmove memmove=0A--- =
2011-12-12.orig/xen/arch/x86/debug.c	2011-12-12 15:46:14.000000000 =
+0100=0A+++ 2011-12-12/xen/arch/x86/debug.c	2011-11-30 17:50:55.0000000=
00 +0100=0A@@ -37,8 +37,8 @@=0A #define DBGP1(...) {(kdbdbg>1) ? kdbp(__VA_=
ARGS__):0;}=0A #define DBGP2(...) {(kdbdbg>2) ? kdbp(__VA_ARGS__):0;}=0A =
#else=0A-#define DBGP1(...) {0;}=0A-#define DBGP2(...) {0;}=0A+#define =
DBGP1(...) ((void)0)=0A+#define DBGP2(...) ((void)0)=0A #endif=0A =0A /* =
Returns: mfn for the given (hvm guest) vaddr */=0A--- 2011-12-12.orig/xen/a=
rch/x86/hvm/svm/vpmu.c	2011-12-12 15:46:14.000000000 +0100=0A+++ =
2011-12-12/xen/arch/x86/hvm/svm/vpmu.c	2011-12-01 11:35:58.000000000 =
+0100=0A@@ -154,7 +154,7 @@ static int amd_vpmu_do_interrupt(struct =0A    =
 if ( GET_APIC_DELIVERY_MODE(vlapic_lvtpc) =3D=3D APIC_MODE_FIXED )=0A     =
    vlapic_set_irq(vcpu_vlapic(v), int_vec, 0);=0A     else=0A-        =
test_and_set_bool(v->nmi_pending);=0A+        v->nmi_pending =3D 1;=0A =0A =
    return 1;=0A }=0A--- 2011-12-12.orig/xen/arch/x86/hvm/vmx/vpmu_core2.c	=
2011-12-12 15:46:14.000000000 +0100=0A+++ 2011-12-12/xen/arch/x86/hvm/vmx/v=
pmu_core2.c	2011-12-01 11:36:37.000000000 +0100=0A@@ -574,7 +574,7 @@ =
static int core2_vpmu_do_interrupt(struc=0A     if ( GET_APIC_DELIVERY_MODE=
(vlapic_lvtpc) =3D=3D APIC_MODE_FIXED )=0A         vlapic_set_irq(vcpu_vlap=
ic(v), int_vec, 0);=0A     else=0A-        test_and_set_bool(v->nmi_pending=
);=0A+        v->nmi_pending =3D 1;=0A     return 1;=0A }=0A =0A--- =
2011-12-12.orig/xen/arch/x86/oprofile/nmi_int.c	2011-12-12 15:46:14.0000000=
00 +0100=0A+++ 2011-12-12/xen/arch/x86/oprofile/nmi_int.c	2011-11-30 =
18:01:11.000000000 +0100=0A@@ -92,7 +92,7 @@ static int nmi_callback(struct=
 cpu_user_=0A 		send_guest_vcpu_virq(current, VIRQ_XENOPROF);=0A =
=0A 	if ( ovf =3D=3D 2 ) =0A-                test_and_set_bool(current->=
nmi_pending);=0A+                current->nmi_pending =3D 1;=0A 	=
return 1;=0A }=0A  =0A--- 2011-12-12.orig/xen/include/asm-x86/debugger.h	=
2011-12-12 15:46:14.000000000 +0100=0A+++ 2011-12-12/xen/include/asm-x86/de=
bugger.h	2011-11-30 17:58:20.000000000 +0100=0A@@ -55,7 +55,12 @@ =
static inline int debugger_trap_fatal(=0A =0A #else=0A =0A-#define =
debugger_trap_fatal(v, r) (0)=0A+static inline int debugger_trap_fatal(=0A+=
    unsigned int vector, struct cpu_user_regs *regs)=0A+{=0A+    return =
0;=0A+}=0A+=0A #define debugger_trap_immediate() ((void)0)=0A =0A =
#endif=0A--- 2011-12-12.orig/xen/include/asm-x86/hvm/hvm.h	2011-12-12 =
15:46:14.000000000 +0100=0A+++ 2011-12-12/xen/include/asm-x86/hvm/hvm.h	=
2011-12-01 12:15:02.000000000 +0100=0A@@ -235,7 +235,7 @@ int hvm_girq_dest=
_2_vcpu_id(struct domai=0A #define hvm_long_mode_enabled(v) \=0A     =
((v)->arch.hvm_vcpu.guest_efer & EFER_LMA)=0A #else=0A-#define hvm_long_mod=
e_enabled(v) (v,0)=0A+#define hvm_long_mode_enabled(v) ((void)(v),0)=0A =
#endif=0A =0A enum hvm_intblk=0A--- 2011-12-12.orig/xen/include/xen/tmem_xe=
n.h	2011-12-12 15:46:14.000000000 +0100=0A+++ 2011-12-12/xen/include/xe=
n/tmem_xen.h	2011-11-30 17:55:22.000000000 +0100=0A@@ -365,7 +365,7 @@ =
static inline int tmh_page_cmp(pfp_t *pf=0A     // FIXME: code in =
assembly?=0A ASSERT(p1 !=3D NULL);=0A ASSERT(p2 !=3D NULL);=0A-    for ( i =
=3D PAGE_SIZE/sizeof(uint64_t); i && *p1 =3D=3D *p2; i--, *p1++, *p2++ =
);=0A+    for ( i =3D PAGE_SIZE/sizeof(uint64_t); i && *p1 =3D=3D *p2; =
i--, p1++, p2++ );=0A     if ( !i )=0A         return 0;=0A     if ( *p1 < =
*p2 )=0A@@ -386,7 +386,7 @@ static inline int tmh_pcd_cmp(void *va1,=0A    =
 if ( len1 > len2 )=0A         return 1;=0A     ASSERT(len1 =3D=3D =
len2);=0A-    for ( i =3D len2; i && *p1 =3D=3D *p2; i--, *p1++, *p2++ =
);=0A+    for ( i =3D len2; i && *p1 =3D=3D *p2; i--, p1++, p2++ );=0A     =
if ( !i )=0A         return 0;=0A     if ( *p1 < *p2 )=0A@@ -413,7 +413,7 =
@@ static inline int tmh_tze_pfp_cmp(pfp_t =0A     if ( pfp_len > tze_len =
)=0A         return 1;=0A     ASSERT(pfp_len =3D=3D tze_len);=0A-    for ( =
i =3D tze_len/sizeof(uint64_t); i && *p1 =3D=3D *p2; i--, *p1++, *p2++ =
);=0A+    for ( i =3D tze_len/sizeof(uint64_t); i && *p1 =3D=3D *p2; i--, =
p1++, p2++ );=0A     if ( !i )=0A         return 0;=0A     if ( *p1 < *p2 =
)=0A--- 2011-12-12.orig/xen/include/xsm/xsm.h	2011-12-12 15:46:14.0000000=
00 +0100=0A+++ 2011-12-12/xen/include/xsm/xsm.h	2011-12-12 15:23:49.0000000=
00 +0100=0A@@ -163,7 +163,7 @@ extern struct xsm_operations *xsm_ops;=0A =
static inline void xsm_security_domaininfo (struct domain *d,=0A           =
                              struct xen_domctl_getdomaininfo *info)=0A =
{=0A-    xsm_call(security_domaininfo(d, info));=0A+    (void)xsm_call(secu=
rity_domaininfo(d, info));=0A }=0A =0A static inline int xsm_setvcpucontext=
(struct domain *d)=0A@@ -310,7 +310,7 @@ static inline int xsm_evtchn_inter=
domain=0A =0A static inline void xsm_evtchn_close_post (struct evtchn =
*chn)=0A {=0A-    xsm_call(evtchn_close_post(chn));=0A+    (void)xsm_call(e=
vtchn_close_post(chn));=0A }=0A =0A static inline int xsm_evtchn_send =
(struct domain *d, struct evtchn *chn)=0A@@ -366,7 +366,7 @@ static inline =
int xsm_alloc_security_dom=0A =0A static inline void xsm_free_security_doma=
in (struct domain *d)=0A {=0A-    xsm_call(free_security_domain(d));=0A+   =
 (void)xsm_call(free_security_domain(d));=0A }=0A =0A static inline int =
xsm_alloc_security_evtchn (struct evtchn *chn)=0A@@ -376,7 +376,7 @@ =
static inline int xsm_alloc_security_evt=0A =0A static inline void =
xsm_free_security_evtchn (struct evtchn *chn)=0A {=0A-    xsm_call(free_sec=
urity_evtchn(chn));=0A+    (void)xsm_call(free_security_evtchn(chn));=0A =
}=0A =0A static inline int xsm_memory_adjust_reservation (struct domain =
*d1, struct=0A
--=__PartF5DA5014.0__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--=__PartF5DA5014.0__=--


From xen-devel-bounces@lists.xensource.com Mon Dec 12 15:44:38 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 15:44:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ra83A-00020Y-Ll; Mon, 12 Dec 2011 15:44:20 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Ra839-00020M-73
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 15:44:19 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1323704557!60396713!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQyODgzMQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12693 invoked from network); 12 Dec 2011 15:42:39 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-7.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Dec 2011 15:42:39 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pBCFhKUV031808
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 12 Dec 2011 15:43:21 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pBCFhJrS008836
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 12 Dec 2011 15:43:20 GMT
Received: from abhmt104.oracle.com (abhmt104.oracle.com [141.146.116.56])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pBCFhEN8030983; Mon, 12 Dec 2011 09:43:14 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 12 Dec 2011 07:43:14 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id A17664175F; Mon, 12 Dec 2011 10:42:27 -0500 (EST)
Date: Mon, 12 Dec 2011 10:42:27 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Bastian Blank <waldi@debian.org>
Message-ID: <20111212154227.GB21558@phenom.dumpdata.com>
References: <1323541791-18006-1-git-send-email-waldi@debian.org>
	<1323541791-18006-7-git-send-email-waldi@debian.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1323541791-18006-7-git-send-email-waldi@debian.org>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090209.4EE6211A.005E,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH 6/6] xen/xenbus-backend: Only register
 device if communication ring is local
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Sat, Dec 10, 2011 at 07:29:51PM +0100, Bastian Blank wrote:
> Signed-off-by: Bastian Blank <waldi@debian.org>
> ---
>  drivers/xen/xenbus/Makefile             |    2 +-
>  drivers/xen/xenbus/xenbus_dev_backend.c |   13 ++-----------
>  drivers/xen/xenbus/xenbus_dev_backend.h |    2 ++
>  drivers/xen/xenbus/xenbus_probe.c       |   18 ++++++++++++++++++
>  4 files changed, 23 insertions(+), 12 deletions(-)
>  create mode 100644 drivers/xen/xenbus/xenbus_dev_backend.h
> 
> diff --git a/drivers/xen/xenbus/Makefile b/drivers/xen/xenbus/Makefile
> index 31e2e90..d751f45 100644
> --- a/drivers/xen/xenbus/Makefile
> +++ b/drivers/xen/xenbus/Makefile
> @@ -7,8 +7,8 @@ xenbus-objs += xenbus_comms.o
>  xenbus-objs += xenbus_xs.o
>  xenbus-objs += xenbus_probe.o
>  
> +xenbus-be-objs-$(CONFIG_XEN_BACKEND) += xenbus_dev_backend.o
>  xenbus-be-objs-$(CONFIG_XEN_BACKEND) += xenbus_probe_backend.o
>  xenbus-objs += $(xenbus-be-objs-y)
>  
> -obj-$(CONFIG_XEN_BACKEND) += xenbus_dev_backend.o
>  obj-$(CONFIG_XEN_XENBUS_FRONTEND) += xenbus_probe_frontend.o
> diff --git a/drivers/xen/xenbus/xenbus_dev_backend.c b/drivers/xen/xenbus/xenbus_dev_backend.c
> index a2092bd..fb87f1b 100644
> --- a/drivers/xen/xenbus/xenbus_dev_backend.c
> +++ b/drivers/xen/xenbus/xenbus_dev_backend.c
> @@ -3,7 +3,6 @@
>  #include <linux/mm.h>
>  #include <linux/fs.h>
>  #include <linux/miscdevice.h>
> -#include <linux/module.h>
>  #include <linux/capability.h>
>  
>  #include <xen/page.h>
> @@ -11,8 +10,6 @@
>  
>  #include "xenbus_comms.h"
>  
> -MODULE_LICENSE("GPL");
> -
>  static int xenbus_backend_open(struct inode *inode, struct file *filp)
>  {
>  	if (!capable(CAP_SYS_ADMIN))
> @@ -67,23 +64,17 @@ static struct miscdevice xenbus_backend_dev = {
>  	.fops = &xenbus_backend_fops,
>  };
>  
> -static int __init xenbus_backend_init(void)
> +int __init xenbus_backend_init(void)
>  {
>  	int err;
>  
> -	if (!xen_initial_domain())
> -		return -ENODEV;
> -
>  	err = misc_register(&xenbus_backend_dev);
>  	if (err)
>  		printk(KERN_ERR "Could not register xenbus backend device\n");
>  	return err;
>  }
>  
> -static void __exit xenbus_backend_exit(void)
> +void __exit xenbus_backend_exit(void)
>  {
>  	misc_deregister(&xenbus_backend_dev);
>  }
> -
> -module_init(xenbus_backend_init);
> -module_exit(xenbus_backend_exit);

Why are we removing the module functionality?
Can't this [the purpose of this patch] be done while still maintaining the module functionality?

> diff --git a/drivers/xen/xenbus/xenbus_dev_backend.h b/drivers/xen/xenbus/xenbus_dev_backend.h
> new file mode 100644
> index 0000000..d986853
> --- /dev/null
> +++ b/drivers/xen/xenbus/xenbus_dev_backend.h
> @@ -0,0 +1,2 @@
> +int xenbus_backend_init(void);
> +void xenbus_backend_exit(void);
> diff --git a/drivers/xen/xenbus/xenbus_probe.c b/drivers/xen/xenbus/xenbus_probe.c
> index 1b178c6..4eff095 100644
> --- a/drivers/xen/xenbus/xenbus_probe.c
> +++ b/drivers/xen/xenbus/xenbus_probe.c
> @@ -60,6 +60,7 @@
>  #include <xen/hvm.h>
>  
>  #include "xenbus_comms.h"
> +#include "xenbus_dev_backend.h"
>  #include "xenbus_probe.h"
>  
>  
> @@ -641,6 +642,10 @@ EXPORT_SYMBOL_GPL(xenbus_dev_cancel);
>  /* A flag to determine if xenstored is 'ready' (i.e. has started) */
>  int xenstored_ready;
>  
> +/* A flag to determine if xenstored is 'local' */
> +#ifdef CONFIG_XEN_BACKEND
> +static int xenstored_local;

bool?

> +#endif
>  
>  int register_xenstore_notifier(struct notifier_block *nb)
>  {
> @@ -675,6 +680,14 @@ static int __init xenbus_probe_initcall(void)
>  	if (!xen_domain())
>  		return -ENODEV;
>  
> +#ifdef CONFIG_XEN_BACKEND
> +	if (xenstored_local) {
> +		int ret = xenbus_backend_init();
> +		if (ret)
> +			return ret;
> +	}
> +#endif
> +
>  	if (xen_initial_domain() || xen_hvm_domain())
>  		return 0;
>  
> @@ -747,9 +760,14 @@ static int __init xenbus_init(void)
>  		if (xen_store_evtchn)
>  			xenstored_ready = 1;
>  		else {
> +#ifdef CONFIG_XEN_BACKEND
> +			xenstored_local = 1;
>  			err = xenstored_local_init();
>  			if (err)
>  				goto out_error;
> +#else
> +			BUG();

No way. A WARN, sure - but BUG() is way too intense for this.

> +#endif
>  		}
>  		xen_store_interface = mfn_to_virt(xen_store_mfn);
>  	}
> -- 
> 1.7.7.3
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 15:44:38 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 15:44:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ra83A-00020Y-Ll; Mon, 12 Dec 2011 15:44:20 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Ra839-00020M-73
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 15:44:19 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1323704557!60396713!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQyODgzMQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12693 invoked from network); 12 Dec 2011 15:42:39 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-7.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Dec 2011 15:42:39 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pBCFhKUV031808
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 12 Dec 2011 15:43:21 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pBCFhJrS008836
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 12 Dec 2011 15:43:20 GMT
Received: from abhmt104.oracle.com (abhmt104.oracle.com [141.146.116.56])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pBCFhEN8030983; Mon, 12 Dec 2011 09:43:14 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 12 Dec 2011 07:43:14 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id A17664175F; Mon, 12 Dec 2011 10:42:27 -0500 (EST)
Date: Mon, 12 Dec 2011 10:42:27 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Bastian Blank <waldi@debian.org>
Message-ID: <20111212154227.GB21558@phenom.dumpdata.com>
References: <1323541791-18006-1-git-send-email-waldi@debian.org>
	<1323541791-18006-7-git-send-email-waldi@debian.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1323541791-18006-7-git-send-email-waldi@debian.org>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090209.4EE6211A.005E,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH 6/6] xen/xenbus-backend: Only register
 device if communication ring is local
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Sat, Dec 10, 2011 at 07:29:51PM +0100, Bastian Blank wrote:
> Signed-off-by: Bastian Blank <waldi@debian.org>
> ---
>  drivers/xen/xenbus/Makefile             |    2 +-
>  drivers/xen/xenbus/xenbus_dev_backend.c |   13 ++-----------
>  drivers/xen/xenbus/xenbus_dev_backend.h |    2 ++
>  drivers/xen/xenbus/xenbus_probe.c       |   18 ++++++++++++++++++
>  4 files changed, 23 insertions(+), 12 deletions(-)
>  create mode 100644 drivers/xen/xenbus/xenbus_dev_backend.h
> 
> diff --git a/drivers/xen/xenbus/Makefile b/drivers/xen/xenbus/Makefile
> index 31e2e90..d751f45 100644
> --- a/drivers/xen/xenbus/Makefile
> +++ b/drivers/xen/xenbus/Makefile
> @@ -7,8 +7,8 @@ xenbus-objs += xenbus_comms.o
>  xenbus-objs += xenbus_xs.o
>  xenbus-objs += xenbus_probe.o
>  
> +xenbus-be-objs-$(CONFIG_XEN_BACKEND) += xenbus_dev_backend.o
>  xenbus-be-objs-$(CONFIG_XEN_BACKEND) += xenbus_probe_backend.o
>  xenbus-objs += $(xenbus-be-objs-y)
>  
> -obj-$(CONFIG_XEN_BACKEND) += xenbus_dev_backend.o
>  obj-$(CONFIG_XEN_XENBUS_FRONTEND) += xenbus_probe_frontend.o
> diff --git a/drivers/xen/xenbus/xenbus_dev_backend.c b/drivers/xen/xenbus/xenbus_dev_backend.c
> index a2092bd..fb87f1b 100644
> --- a/drivers/xen/xenbus/xenbus_dev_backend.c
> +++ b/drivers/xen/xenbus/xenbus_dev_backend.c
> @@ -3,7 +3,6 @@
>  #include <linux/mm.h>
>  #include <linux/fs.h>
>  #include <linux/miscdevice.h>
> -#include <linux/module.h>
>  #include <linux/capability.h>
>  
>  #include <xen/page.h>
> @@ -11,8 +10,6 @@
>  
>  #include "xenbus_comms.h"
>  
> -MODULE_LICENSE("GPL");
> -
>  static int xenbus_backend_open(struct inode *inode, struct file *filp)
>  {
>  	if (!capable(CAP_SYS_ADMIN))
> @@ -67,23 +64,17 @@ static struct miscdevice xenbus_backend_dev = {
>  	.fops = &xenbus_backend_fops,
>  };
>  
> -static int __init xenbus_backend_init(void)
> +int __init xenbus_backend_init(void)
>  {
>  	int err;
>  
> -	if (!xen_initial_domain())
> -		return -ENODEV;
> -
>  	err = misc_register(&xenbus_backend_dev);
>  	if (err)
>  		printk(KERN_ERR "Could not register xenbus backend device\n");
>  	return err;
>  }
>  
> -static void __exit xenbus_backend_exit(void)
> +void __exit xenbus_backend_exit(void)
>  {
>  	misc_deregister(&xenbus_backend_dev);
>  }
> -
> -module_init(xenbus_backend_init);
> -module_exit(xenbus_backend_exit);

Why are we removing the module functionality?
Can't this [the purpose of this patch] be done while still maintaining the module functionality?

> diff --git a/drivers/xen/xenbus/xenbus_dev_backend.h b/drivers/xen/xenbus/xenbus_dev_backend.h
> new file mode 100644
> index 0000000..d986853
> --- /dev/null
> +++ b/drivers/xen/xenbus/xenbus_dev_backend.h
> @@ -0,0 +1,2 @@
> +int xenbus_backend_init(void);
> +void xenbus_backend_exit(void);
> diff --git a/drivers/xen/xenbus/xenbus_probe.c b/drivers/xen/xenbus/xenbus_probe.c
> index 1b178c6..4eff095 100644
> --- a/drivers/xen/xenbus/xenbus_probe.c
> +++ b/drivers/xen/xenbus/xenbus_probe.c
> @@ -60,6 +60,7 @@
>  #include <xen/hvm.h>
>  
>  #include "xenbus_comms.h"
> +#include "xenbus_dev_backend.h"
>  #include "xenbus_probe.h"
>  
>  
> @@ -641,6 +642,10 @@ EXPORT_SYMBOL_GPL(xenbus_dev_cancel);
>  /* A flag to determine if xenstored is 'ready' (i.e. has started) */
>  int xenstored_ready;
>  
> +/* A flag to determine if xenstored is 'local' */
> +#ifdef CONFIG_XEN_BACKEND
> +static int xenstored_local;

bool?

> +#endif
>  
>  int register_xenstore_notifier(struct notifier_block *nb)
>  {
> @@ -675,6 +680,14 @@ static int __init xenbus_probe_initcall(void)
>  	if (!xen_domain())
>  		return -ENODEV;
>  
> +#ifdef CONFIG_XEN_BACKEND
> +	if (xenstored_local) {
> +		int ret = xenbus_backend_init();
> +		if (ret)
> +			return ret;
> +	}
> +#endif
> +
>  	if (xen_initial_domain() || xen_hvm_domain())
>  		return 0;
>  
> @@ -747,9 +760,14 @@ static int __init xenbus_init(void)
>  		if (xen_store_evtchn)
>  			xenstored_ready = 1;
>  		else {
> +#ifdef CONFIG_XEN_BACKEND
> +			xenstored_local = 1;
>  			err = xenstored_local_init();
>  			if (err)
>  				goto out_error;
> +#else
> +			BUG();

No way. A WARN, sure - but BUG() is way too intense for this.

> +#endif
>  		}
>  		xen_store_interface = mfn_to_virt(xen_store_mfn);
>  	}
> -- 
> 1.7.7.3
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 15:48:18 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 15:48:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ra86o-0002ES-EH; Mon, 12 Dec 2011 15:48:06 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <mrezanin@redhat.com>) id 1Ra86n-0002EI-4X
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 15:48:05 +0000
X-Env-Sender: mrezanin@redhat.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1323704813!51839726!1
X-Originating-IP: [209.132.183.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjQgPT4gNjg3ODk=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8382 invoked from network); 12 Dec 2011 15:46:53 -0000
Received: from mx3-phx2.redhat.com (HELO mx3-phx2.redhat.com) (209.132.183.24)
	by server-13.tower-27.messagelabs.com with SMTP;
	12 Dec 2011 15:46:53 -0000
Received: from zmail13.collab.prod.int.phx2.redhat.com
	(zmail13.collab.prod.int.phx2.redhat.com [10.5.83.15])
	by mx3-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id pBCFlFhl007727
	for <xen-devel@lists.xensource.com>; Mon, 12 Dec 2011 10:47:15 -0500
Date: Mon, 12 Dec 2011 10:47:15 -0500 (EST)
From: Miroslav Rezanina <mrezanin@redhat.com>
To: xen-devel <xen-devel@lists.xensource.com>
Message-ID: <83000c07-d9cc-48fe-ab0a-e07aaf2f1b3b@zmail13.collab.prod.int.phx2.redhat.com>
In-Reply-To: <54c8f8bc-2f0d-439e-8106-937b433b73a8@zmail13.collab.prod.int.phx2.redhat.com>
MIME-Version: 1.0
X-Originating-IP: [10.34.26.132]
X-Mailer: Zimbra 7.1.2_GA_3268 (ZimbraWebClient - FF3.0 (Linux)/7.1.2_GA_3268)
Subject: [Xen-devel] pygrub: Fix entry editing in grub2
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

When user wants to change entry in grub2 menu in pygrub, there's no
response in case of appending command line arguments ('a' key) and
may be crash of pygrub in case of editing item ('e' key).

Append malfunction is caused by change of keyword used for kernel
record. Grub uses 'kernel' for line with linux kernel but grub2 uses
'linux' instead. This patch adds checking for both grub 1 and 2 keywords.

Crash on editing is caused longer entry list in case of grub2. As entry
window is 10 lines high, it can hold only 8 entries (2 lines for border).
Adding line outside of windows high causes crash. Patch add handling
for longer lists and scrolling through them.

Signed-off-by: Miroslav Rezanina <mrezanin@redhat.com>

Patch:
---
diff -r 1c58bb664d8d tools/pygrub/src/pygrub
--- a/tools/pygrub/src/pygrub	Thu Dec 08 17:15:16 2011 +0000
+++ b/tools/pygrub/src/pygrub	Mon Dec 12 16:35:43 2011 +0100
@@ -221,6 +221,7 @@
         
 
 class Grub:
+    ENTRY_WIN_LINES = 8
     def __init__(self, file, fs = None):
         self.screen = None
         self.entry_win = None
@@ -238,7 +239,7 @@
                 except:
                     pass # Not important if we can't use colour
             enable_cursor(False)
-            self.entry_win = curses.newwin(10, 74, 2, 1)
+            self.entry_win = curses.newwin(Grub.ENTRY_WIN_LINES + 2, 74, 2, 1)
             self.text_win = curses.newwin(10, 70, 12, 5)
             curses.def_prog_mode()
         
@@ -287,12 +288,20 @@
             self.text_win.noutrefresh()
 
         curline = 0
+        pos = 0
         img = copy.deepcopy(origimg)
         while 1:
             draw()
             self.entry_win.erase()
-            self.entry_win.box()
-            for idx in range(0, len(img.lines)):
+
+            rs = 0
+            re = len(img.lines)
+            idp = 1
+            if re > Grub.ENTRY_WIN_LINES:
+                rs = curline - pos
+                re = rs + Grub.ENTRY_WIN_LINES
+
+            for idx in range(rs, re):
                 # current line should be highlighted
                 if idx == curline:
                     self.entry_win.attron(curses.A_REVERSE)
@@ -302,9 +311,11 @@
                 if len(l) > 70:
                     l = l[:69] + ">"
                     
-                self.entry_win.addstr(idx + 1, 2, l)
+                self.entry_win.addstr(idp, 2, l)
                 if idx == curline:
                     self.entry_win.attroff(curses.A_REVERSE)
+                idp += 1
+            self.entry_win.box()
             self.entry_win.noutrefresh()
             curses.doupdate()
 
@@ -313,8 +324,12 @@
                 break
             elif c == curses.KEY_UP:
                 curline -= 1
+                if pos > 0:
+                    pos -= 1
             elif c == curses.KEY_DOWN:
                 curline += 1
+                if pos < Grub.ENTRY_WIN_LINES - 1:
+                    pos += 1
             elif c == ord('b'):
                 self.isdone = True
                 break
@@ -507,7 +522,7 @@
                 # find the kernel line, edit it and then boot
                 img = self.cf.images[self.selected_image]
                 for line in img.lines:
-                    if line.startswith("kernel"):
+                    if line.startswith("kernel") or line.startswith("linux"):
                         l = self.edit_line(line)
                         if l is not None:
                             img.set_from_line(l, replace = True)
---
Miroslav Rezanina
Software Engineer - Virtualization Team - XEN kernel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 15:48:18 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 15:48:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ra86o-0002ES-EH; Mon, 12 Dec 2011 15:48:06 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <mrezanin@redhat.com>) id 1Ra86n-0002EI-4X
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 15:48:05 +0000
X-Env-Sender: mrezanin@redhat.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1323704813!51839726!1
X-Originating-IP: [209.132.183.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjQgPT4gNjg3ODk=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8382 invoked from network); 12 Dec 2011 15:46:53 -0000
Received: from mx3-phx2.redhat.com (HELO mx3-phx2.redhat.com) (209.132.183.24)
	by server-13.tower-27.messagelabs.com with SMTP;
	12 Dec 2011 15:46:53 -0000
Received: from zmail13.collab.prod.int.phx2.redhat.com
	(zmail13.collab.prod.int.phx2.redhat.com [10.5.83.15])
	by mx3-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id pBCFlFhl007727
	for <xen-devel@lists.xensource.com>; Mon, 12 Dec 2011 10:47:15 -0500
Date: Mon, 12 Dec 2011 10:47:15 -0500 (EST)
From: Miroslav Rezanina <mrezanin@redhat.com>
To: xen-devel <xen-devel@lists.xensource.com>
Message-ID: <83000c07-d9cc-48fe-ab0a-e07aaf2f1b3b@zmail13.collab.prod.int.phx2.redhat.com>
In-Reply-To: <54c8f8bc-2f0d-439e-8106-937b433b73a8@zmail13.collab.prod.int.phx2.redhat.com>
MIME-Version: 1.0
X-Originating-IP: [10.34.26.132]
X-Mailer: Zimbra 7.1.2_GA_3268 (ZimbraWebClient - FF3.0 (Linux)/7.1.2_GA_3268)
Subject: [Xen-devel] pygrub: Fix entry editing in grub2
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

When user wants to change entry in grub2 menu in pygrub, there's no
response in case of appending command line arguments ('a' key) and
may be crash of pygrub in case of editing item ('e' key).

Append malfunction is caused by change of keyword used for kernel
record. Grub uses 'kernel' for line with linux kernel but grub2 uses
'linux' instead. This patch adds checking for both grub 1 and 2 keywords.

Crash on editing is caused longer entry list in case of grub2. As entry
window is 10 lines high, it can hold only 8 entries (2 lines for border).
Adding line outside of windows high causes crash. Patch add handling
for longer lists and scrolling through them.

Signed-off-by: Miroslav Rezanina <mrezanin@redhat.com>

Patch:
---
diff -r 1c58bb664d8d tools/pygrub/src/pygrub
--- a/tools/pygrub/src/pygrub	Thu Dec 08 17:15:16 2011 +0000
+++ b/tools/pygrub/src/pygrub	Mon Dec 12 16:35:43 2011 +0100
@@ -221,6 +221,7 @@
         
 
 class Grub:
+    ENTRY_WIN_LINES = 8
     def __init__(self, file, fs = None):
         self.screen = None
         self.entry_win = None
@@ -238,7 +239,7 @@
                 except:
                     pass # Not important if we can't use colour
             enable_cursor(False)
-            self.entry_win = curses.newwin(10, 74, 2, 1)
+            self.entry_win = curses.newwin(Grub.ENTRY_WIN_LINES + 2, 74, 2, 1)
             self.text_win = curses.newwin(10, 70, 12, 5)
             curses.def_prog_mode()
         
@@ -287,12 +288,20 @@
             self.text_win.noutrefresh()
 
         curline = 0
+        pos = 0
         img = copy.deepcopy(origimg)
         while 1:
             draw()
             self.entry_win.erase()
-            self.entry_win.box()
-            for idx in range(0, len(img.lines)):
+
+            rs = 0
+            re = len(img.lines)
+            idp = 1
+            if re > Grub.ENTRY_WIN_LINES:
+                rs = curline - pos
+                re = rs + Grub.ENTRY_WIN_LINES
+
+            for idx in range(rs, re):
                 # current line should be highlighted
                 if idx == curline:
                     self.entry_win.attron(curses.A_REVERSE)
@@ -302,9 +311,11 @@
                 if len(l) > 70:
                     l = l[:69] + ">"
                     
-                self.entry_win.addstr(idx + 1, 2, l)
+                self.entry_win.addstr(idp, 2, l)
                 if idx == curline:
                     self.entry_win.attroff(curses.A_REVERSE)
+                idp += 1
+            self.entry_win.box()
             self.entry_win.noutrefresh()
             curses.doupdate()
 
@@ -313,8 +324,12 @@
                 break
             elif c == curses.KEY_UP:
                 curline -= 1
+                if pos > 0:
+                    pos -= 1
             elif c == curses.KEY_DOWN:
                 curline += 1
+                if pos < Grub.ENTRY_WIN_LINES - 1:
+                    pos += 1
             elif c == ord('b'):
                 self.isdone = True
                 break
@@ -507,7 +522,7 @@
                 # find the kernel line, edit it and then boot
                 img = self.cf.images[self.selected_image]
                 for line in img.lines:
-                    if line.startswith("kernel"):
+                    if line.startswith("kernel") or line.startswith("linux"):
                         l = self.edit_line(line)
                         if l is not None:
                             img.set_from_line(l, replace = True)
---
Miroslav Rezanina
Software Engineer - Virtualization Team - XEN kernel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 15:54:13 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 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.xensource.com>)
	id 1Ra8CT-0002Qd-7b; Mon, 12 Dec 2011 15:53:57 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Ra8CR-0002QS-F5
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 15:53:55 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1323705180!7640798!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=2.0 required=7.0 tests=SUBJECT_RANDOMQ
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11458 invoked from network); 12 Dec 2011 15:53:00 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-11.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 12 Dec 2011 15:53:00 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 12 Dec 2011 15:53:00 +0000
Message-Id: <4EE631A2020000780006701F@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 12 Dec 2011 15:53:54 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part614EC482.1__="
Cc: Allen M Kay <allen.m.kay@intel.com>
Subject: [Xen-devel] [PATCH] VT-d: bind IRQs to CPUs local to the node the
 IOMMU is on
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__Part614EC482.1__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

This extends create_irq() to take a node parameter, allowing the
resulting IRQ to have its destination set to a CPU on that node right
away, which is more natural than having to post-adjust this (and
get e.g. a new IRQ vector assigned despite a fresh one was just
obtained).

All other callers of create_irq() pass NUMA_NO_NODE for the time being.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- 2011-12-12.orig/xen/arch/x86/hpet.c	2011-11-11 09:40:55.000000000 =
+0100
+++ 2011-12-12/xen/arch/x86/hpet.c	2011-12-06 16:36:24.000000000 =
+0100
@@ -11,6 +11,7 @@
 #include <xen/smp.h>
 #include <xen/softirq.h>
 #include <xen/irq.h>
+#include <xen/numa.h>
 #include <asm/fixmap.h>
 #include <asm/div64.h>
 #include <asm/hpet.h>
@@ -334,7 +335,7 @@ static int __init hpet_assign_irq(unsign
 {
     int irq;
=20
-    if ( (irq =3D create_irq()) < 0 )
+    if ( (irq =3D create_irq(NUMA_NO_NODE)) < 0 )
         return irq;
=20
     if ( hpet_setup_msi_irq(irq, hpet_events + idx) )
--- 2011-12-12.orig/xen/arch/x86/io_apic.c	2011-11-22 10:57:09.0000000=
00 +0100
+++ 2011-12-12/xen/arch/x86/io_apic.c	2011-12-12 15:24:10.000000000 =
+0100
@@ -995,7 +995,7 @@ static void __init setup_IO_APIC_irqs(vo
                 continue;
=20
             if (IO_APIC_IRQ(irq)) {
-                vector =3D assign_irq_vector(irq);
+                vector =3D assign_irq_vector(irq, NULL);
                 BUG_ON(vector < 0);
                 entry.vector =3D vector;
                 ioapic_register_intr(irq, IOAPIC_AUTO);
@@ -2188,7 +2188,7 @@ int io_apic_set_pci_routing (int ioapic,
     if (!platform_legacy_irq(irq))
         add_pin_to_irq(irq, ioapic, pin);
=20
-    vector =3D assign_irq_vector(irq);
+    vector =3D assign_irq_vector(irq, NULL);
     if (vector < 0)
         return vector;
     entry.vector =3D vector;
@@ -2340,7 +2340,7 @@ int ioapic_guest_write(unsigned long phy
=20
     if ( desc->arch.vector <=3D 0 || desc->arch.vector > LAST_DYNAMIC_VECT=
OR ) {
         add_pin_to_irq(irq, apic, pin);
-        vector =3D assign_irq_vector(irq);
+        vector =3D assign_irq_vector(irq, NULL);
         if ( vector < 0 )
             return vector;
=20
--- 2011-12-12.orig/xen/arch/x86/irq.c	2011-12-12 09:01:34.000000000 =
+0100
+++ 2011-12-12/xen/arch/x86/irq.c	2011-12-12 15:24:15.000000000 =
+0100
@@ -151,7 +151,7 @@ int __init bind_irq_vector(int irq, int=20
 /*
  * Dynamic irq allocate and deallocation for MSI
  */
-int create_irq(void)
+int create_irq(int node)
 {
     int irq, ret;
     struct irq_desc *desc;
@@ -168,7 +168,17 @@ int create_irq(void)
=20
     ret =3D init_one_irq_desc(desc);
     if (!ret)
-        ret =3D assign_irq_vector(irq);
+    {
+        cpumask_t *mask =3D NULL;
+
+        if (node !=3D NUMA_NO_NODE && node >=3D 0)
+        {
+            mask =3D &node_to_cpumask(node);
+            if (cpumask_empty(mask))
+                mask =3D NULL;
+        }
+        ret =3D assign_irq_vector(irq, mask);
+    }
     if (ret < 0)
     {
         desc->arch.used =3D IRQ_UNUSED;
@@ -514,7 +524,7 @@ next:
     return err;
 }
=20
-int assign_irq_vector(int irq)
+int assign_irq_vector(int irq, const cpumask_t *mask)
 {
     int ret;
     unsigned long flags;
@@ -523,7 +533,7 @@ int assign_irq_vector(int irq)
     BUG_ON(irq >=3D nr_irqs || irq <0);
=20
     spin_lock_irqsave(&vector_lock, flags);
-    ret =3D __assign_irq_vector(irq, desc, TARGET_CPUS);
+    ret =3D __assign_irq_vector(irq, desc, mask ?: TARGET_CPUS);
     if (!ret) {
         ret =3D desc->arch.vector;
         cpumask_copy(desc->affinity, desc->arch.cpu_mask);
--- 2011-12-12.orig/xen/arch/x86/physdev.c	2011-12-12 09:01:34.0000000=
00 +0100
+++ 2011-12-12/xen/arch/x86/physdev.c	2011-12-06 16:28:10.000000000 =
+0100
@@ -132,7 +132,7 @@ int physdev_map_pirq(domid_t domid, int=20
     case MAP_PIRQ_TYPE_MSI:
         irq =3D *index;
         if ( irq =3D=3D -1 )
-            irq =3D create_irq();
+            irq =3D create_irq(NUMA_NO_NODE);
=20
         if ( irq < 0 || irq >=3D nr_irqs )
         {
--- 2011-12-12.orig/xen/drivers/passthrough/amd/iommu_init.c	2011-11-29 =
09:19:05.000000000 +0100
+++ 2011-12-12/xen/drivers/passthrough/amd/iommu_init.c	2011-12-06 =
16:27:49.000000000 +0100
@@ -551,7 +551,7 @@ static int __init set_iommu_interrupt_ha
 {
     int irq, ret;
=20
-    irq =3D create_irq();
+    irq =3D create_irq(NUMA_NO_NODE);
     if ( irq <=3D 0 )
     {
         dprintk(XENLOG_ERR, "IOMMU: no irqs\n");
--- 2011-12-12.orig/xen/drivers/passthrough/vtd/iommu.c	2011-11-22 =
10:57:10.000000000 +0100
+++ 2011-12-12/xen/drivers/passthrough/vtd/iommu.c	2011-12-06 =
16:35:42.000000000 +0100
@@ -1096,11 +1096,13 @@ static hw_irq_controller dma_msi_type =3D=20
     .set_affinity =3D dma_msi_set_affinity,
 };
=20
-static int __init iommu_set_interrupt(struct iommu *iommu)
+static int __init iommu_set_interrupt(struct acpi_drhd_unit *drhd)
 {
     int irq, ret;
+    struct acpi_rhsa_unit *rhsa =3D drhd_to_rhsa(drhd);
=20
-    irq =3D create_irq();
+    irq =3D create_irq(rhsa ? pxm_to_node(rhsa->proximity_domain)
+                          : NUMA_NO_NODE);
     if ( irq <=3D 0 )
     {
         dprintk(XENLOG_ERR VTDPREFIX, "IOMMU: no irq available!\n");
@@ -1109,9 +1111,9 @@ static int __init iommu_set_interrupt(st
=20
     irq_desc[irq].handler =3D &dma_msi_type;
 #ifdef CONFIG_X86
-    ret =3D request_irq(irq, iommu_page_fault, 0, "dmar", iommu);
+    ret =3D request_irq(irq, iommu_page_fault, 0, "dmar", drhd->iommu);
 #else
-    ret =3D request_irq_vector(irq, iommu_page_fault, 0, "dmar", iommu);
+    ret =3D request_irq_vector(irq, iommu_page_fault, 0, "dmar", =
drhd->iommu);
 #endif
     if ( ret )
     {
@@ -2133,7 +2135,7 @@ int __init intel_vtd_setup(void)
         if ( !vtd_ept_page_compatible(iommu) )
             iommu_hap_pt_share =3D 0;
=20
-        ret =3D iommu_set_interrupt(iommu);
+        ret =3D iommu_set_interrupt(drhd);
         if ( ret < 0 )
         {
             dprintk(XENLOG_ERR VTDPREFIX, "IOMMU: interrupt setup =
failed\n");
--- 2011-12-12.orig/xen/include/asm-x86/io_apic.h	2011-10-04 =
08:22:17.000000000 +0200
+++ 2011-12-12/xen/include/asm-x86/io_apic.h	2011-12-06 16:24:22.0000000=
00 +0100
@@ -213,9 +213,6 @@ static inline void ioapic_suspend(void)=20
 static inline void ioapic_resume(void) {}
 #endif
=20
-extern int assign_irq_vector(int irq);
-extern int free_irq_vector(int vector);
-
 unsigned highest_gsi(void);
=20
 int ioapic_guest_read( unsigned long physbase, unsigned int reg, u32 =
*pval);
--- 2011-12-12.orig/xen/include/asm-x86/irq.h	2011-11-22 10:57:10.0000000=
00 +0100
+++ 2011-12-12/xen/include/asm-x86/irq.h	2011-12-06 16:25:22.0000000=
00 +0100
@@ -155,8 +155,9 @@ int  init_irq_data(void);
 void clear_irq_vector(int irq);
=20
 int irq_to_vector(int irq);
-int create_irq(void);
+int create_irq(int node);
 void destroy_irq(unsigned int irq);
+int assign_irq_vector(int irq, const cpumask_t *);
=20
 extern void irq_complete_move(struct irq_desc *);
=20



--=__Part614EC482.1__=
Content-Type: text/plain; name="vtd-irq-affinity.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="vtd-irq-affinity.patch"

VT-d: bind IRQs to CPUs local to the node the IOMMU is on=0A=0AThis =
extends create_irq() to take a node parameter, allowing the=0Aresulting =
IRQ to have its destination set to a CPU on that node right=0Aaway, which =
is more natural than having to post-adjust this (and=0Aget e.g. a new IRQ =
vector assigned despite a fresh one was just=0Aobtained).=0A=0AAll other =
callers of create_irq() pass NUMA_NO_NODE for the time being.=0A=0ASigned-o=
ff-by: Jan Beulich <jbeulich@suse.com>=0A=0A--- 2011-12-12.orig/xen/arch/x8=
6/hpet.c	2011-11-11 09:40:55.000000000 +0100=0A+++ 2011-12-12/xen/ar=
ch/x86/hpet.c	2011-12-06 16:36:24.000000000 +0100=0A@@ -11,6 +11,7 @@=0A =
#include <xen/smp.h>=0A #include <xen/softirq.h>=0A #include <xen/irq.h>=0A=
+#include <xen/numa.h>=0A #include <asm/fixmap.h>=0A #include <asm/div64.h>=
=0A #include <asm/hpet.h>=0A@@ -334,7 +335,7 @@ static int __init =
hpet_assign_irq(unsign=0A {=0A     int irq;=0A =0A-    if ( (irq =3D =
create_irq()) < 0 )=0A+    if ( (irq =3D create_irq(NUMA_NO_NODE)) < 0 =
)=0A         return irq;=0A =0A     if ( hpet_setup_msi_irq(irq, hpet_event=
s + idx) )=0A--- 2011-12-12.orig/xen/arch/x86/io_apic.c	2011-11-22 =
10:57:09.000000000 +0100=0A+++ 2011-12-12/xen/arch/x86/io_apic.c	=
2011-12-12 15:24:10.000000000 +0100=0A@@ -995,7 +995,7 @@ static void =
__init setup_IO_APIC_irqs(vo=0A                 continue;=0A =0A           =
  if (IO_APIC_IRQ(irq)) {=0A-                vector =3D assign_irq_vector(i=
rq);=0A+                vector =3D assign_irq_vector(irq, NULL);=0A        =
         BUG_ON(vector < 0);=0A                 entry.vector =3D vector;=0A=
                 ioapic_register_intr(irq, IOAPIC_AUTO);=0A@@ -2188,7 =
+2188,7 @@ int io_apic_set_pci_routing (int ioapic,=0A     if (!platform_le=
gacy_irq(irq))=0A         add_pin_to_irq(irq, ioapic, pin);=0A =0A-    =
vector =3D assign_irq_vector(irq);=0A+    vector =3D assign_irq_vector(irq,=
 NULL);=0A     if (vector < 0)=0A         return vector;=0A     entry.vecto=
r =3D vector;=0A@@ -2340,7 +2340,7 @@ int ioapic_guest_write(unsigned long =
phy=0A =0A     if ( desc->arch.vector <=3D 0 || desc->arch.vector > =
LAST_DYNAMIC_VECTOR ) {=0A         add_pin_to_irq(irq, apic, pin);=0A-     =
   vector =3D assign_irq_vector(irq);=0A+        vector =3D assign_irq_vect=
or(irq, NULL);=0A         if ( vector < 0 )=0A             return =
vector;=0A =0A--- 2011-12-12.orig/xen/arch/x86/irq.c	2011-12-12 =
09:01:34.000000000 +0100=0A+++ 2011-12-12/xen/arch/x86/irq.c	2011-12-12 =
15:24:15.000000000 +0100=0A@@ -151,7 +151,7 @@ int __init bind_irq_vector(i=
nt irq, int =0A /*=0A  * Dynamic irq allocate and deallocation for MSI=0A  =
*/=0A-int create_irq(void)=0A+int create_irq(int node)=0A {=0A     int =
irq, ret;=0A     struct irq_desc *desc;=0A@@ -168,7 +168,17 @@ int =
create_irq(void)=0A =0A     ret =3D init_one_irq_desc(desc);=0A     if =
(!ret)=0A-        ret =3D assign_irq_vector(irq);=0A+    {=0A+        =
cpumask_t *mask =3D NULL;=0A+=0A+        if (node !=3D NUMA_NO_NODE && =
node >=3D 0)=0A+        {=0A+            mask =3D &node_to_cpumask(node);=
=0A+            if (cpumask_empty(mask))=0A+                mask =3D =
NULL;=0A+        }=0A+        ret =3D assign_irq_vector(irq, mask);=0A+    =
}=0A     if (ret < 0)=0A     {=0A         desc->arch.used =3D IRQ_UNUSED;=
=0A@@ -514,7 +524,7 @@ next:=0A     return err;=0A }=0A =0A-int assign_irq_=
vector(int irq)=0A+int assign_irq_vector(int irq, const cpumask_t =
*mask)=0A {=0A     int ret;=0A     unsigned long flags;=0A@@ -523,7 +533,7 =
@@ int assign_irq_vector(int irq)=0A     BUG_ON(irq >=3D nr_irqs || irq =
<0);=0A =0A     spin_lock_irqsave(&vector_lock, flags);=0A-    ret =3D =
__assign_irq_vector(irq, desc, TARGET_CPUS);=0A+    ret =3D __assign_irq_ve=
ctor(irq, desc, mask ?: TARGET_CPUS);=0A     if (!ret) {=0A         ret =
=3D desc->arch.vector;=0A         cpumask_copy(desc->affinity, desc->arch.c=
pu_mask);=0A--- 2011-12-12.orig/xen/arch/x86/physdev.c	2011-12-12 =
09:01:34.000000000 +0100=0A+++ 2011-12-12/xen/arch/x86/physdev.c	=
2011-12-06 16:28:10.000000000 +0100=0A@@ -132,7 +132,7 @@ int physdev_map_p=
irq(domid_t domid, int =0A     case MAP_PIRQ_TYPE_MSI:=0A         irq =3D =
*index;=0A         if ( irq =3D=3D -1 )=0A-            irq =3D create_irq()=
;=0A+            irq =3D create_irq(NUMA_NO_NODE);=0A =0A         if ( irq =
< 0 || irq >=3D nr_irqs )=0A         {=0A--- 2011-12-12.orig/xen/drivers/pa=
ssthrough/amd/iommu_init.c	2011-11-29 09:19:05.000000000 +0100=0A+++ =
2011-12-12/xen/drivers/passthrough/amd/iommu_init.c	2011-12-06 =
16:27:49.000000000 +0100=0A@@ -551,7 +551,7 @@ static int __init set_iommu_=
interrupt_ha=0A {=0A     int irq, ret;=0A =0A-    irq =3D create_irq();=0A+=
    irq =3D create_irq(NUMA_NO_NODE);=0A     if ( irq <=3D 0 )=0A     {=0A =
        dprintk(XENLOG_ERR, "IOMMU: no irqs\n");=0A--- 2011-12-12.orig/xen/=
drivers/passthrough/vtd/iommu.c	2011-11-22 10:57:10.000000000 +0100=0A+++ =
2011-12-12/xen/drivers/passthrough/vtd/iommu.c	2011-12-06 16:35:42.0000000=
00 +0100=0A@@ -1096,11 +1096,13 @@ static hw_irq_controller dma_msi_type =
=3D =0A     .set_affinity =3D dma_msi_set_affinity,=0A };=0A =0A-static =
int __init iommu_set_interrupt(struct iommu *iommu)=0A+static int __init =
iommu_set_interrupt(struct acpi_drhd_unit *drhd)=0A {=0A     int irq, =
ret;=0A+    struct acpi_rhsa_unit *rhsa =3D drhd_to_rhsa(drhd);=0A =0A-    =
irq =3D create_irq();=0A+    irq =3D create_irq(rhsa ? pxm_to_node(rhsa->pr=
oximity_domain)=0A+                          : NUMA_NO_NODE);=0A     if ( =
irq <=3D 0 )=0A     {=0A         dprintk(XENLOG_ERR VTDPREFIX, "IOMMU: no =
irq available!\n");=0A@@ -1109,9 +1111,9 @@ static int __init iommu_set_int=
errupt(st=0A =0A     irq_desc[irq].handler =3D &dma_msi_type;=0A #ifdef =
CONFIG_X86=0A-    ret =3D request_irq(irq, iommu_page_fault, 0, "dmar", =
iommu);=0A+    ret =3D request_irq(irq, iommu_page_fault, 0, "dmar", =
drhd->iommu);=0A #else=0A-    ret =3D request_irq_vector(irq, iommu_page_fa=
ult, 0, "dmar", iommu);=0A+    ret =3D request_irq_vector(irq, iommu_page_f=
ault, 0, "dmar", drhd->iommu);=0A #endif=0A     if ( ret )=0A     {=0A@@ =
-2133,7 +2135,7 @@ int __init intel_vtd_setup(void)=0A         if ( =
!vtd_ept_page_compatible(iommu) )=0A             iommu_hap_pt_share =3D =
0;=0A =0A-        ret =3D iommu_set_interrupt(iommu);=0A+        ret =3D =
iommu_set_interrupt(drhd);=0A         if ( ret < 0 )=0A         {=0A       =
      dprintk(XENLOG_ERR VTDPREFIX, "IOMMU: interrupt setup failed\n");=0A-=
-- 2011-12-12.orig/xen/include/asm-x86/io_apic.h	2011-10-04 =
08:22:17.000000000 +0200=0A+++ 2011-12-12/xen/include/asm-x86/io_apic.h	=
2011-12-06 16:24:22.000000000 +0100=0A@@ -213,9 +213,6 @@ static inline =
void ioapic_suspend(void) =0A static inline void ioapic_resume(void) {}=0A =
#endif=0A =0A-extern int assign_irq_vector(int irq);=0A-extern int =
free_irq_vector(int vector);=0A-=0A unsigned highest_gsi(void);=0A =0A int =
ioapic_guest_read( unsigned long physbase, unsigned int reg, u32 *pval);=0A=
--- 2011-12-12.orig/xen/include/asm-x86/irq.h	2011-11-22 10:57:10.0000000=
00 +0100=0A+++ 2011-12-12/xen/include/asm-x86/irq.h	2011-12-06 =
16:25:22.000000000 +0100=0A@@ -155,8 +155,9 @@ int  init_irq_data(void);=0A=
 void clear_irq_vector(int irq);=0A =0A int irq_to_vector(int irq);=0A-int =
create_irq(void);=0A+int create_irq(int node);=0A void destroy_irq(unsigned=
 int irq);=0A+int assign_irq_vector(int irq, const cpumask_t *);=0A =0A =
extern void irq_complete_move(struct irq_desc *);=0A =0A
--=__Part614EC482.1__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--=__Part614EC482.1__=--


From xen-devel-bounces@lists.xensource.com Mon Dec 12 15:54:13 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 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.xensource.com>)
	id 1Ra8CT-0002Qd-7b; Mon, 12 Dec 2011 15:53:57 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Ra8CR-0002QS-F5
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 15:53:55 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1323705180!7640798!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=2.0 required=7.0 tests=SUBJECT_RANDOMQ
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11458 invoked from network); 12 Dec 2011 15:53:00 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-11.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 12 Dec 2011 15:53:00 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 12 Dec 2011 15:53:00 +0000
Message-Id: <4EE631A2020000780006701F@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 12 Dec 2011 15:53:54 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part614EC482.1__="
Cc: Allen M Kay <allen.m.kay@intel.com>
Subject: [Xen-devel] [PATCH] VT-d: bind IRQs to CPUs local to the node the
 IOMMU is on
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__Part614EC482.1__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

This extends create_irq() to take a node parameter, allowing the
resulting IRQ to have its destination set to a CPU on that node right
away, which is more natural than having to post-adjust this (and
get e.g. a new IRQ vector assigned despite a fresh one was just
obtained).

All other callers of create_irq() pass NUMA_NO_NODE for the time being.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- 2011-12-12.orig/xen/arch/x86/hpet.c	2011-11-11 09:40:55.000000000 =
+0100
+++ 2011-12-12/xen/arch/x86/hpet.c	2011-12-06 16:36:24.000000000 =
+0100
@@ -11,6 +11,7 @@
 #include <xen/smp.h>
 #include <xen/softirq.h>
 #include <xen/irq.h>
+#include <xen/numa.h>
 #include <asm/fixmap.h>
 #include <asm/div64.h>
 #include <asm/hpet.h>
@@ -334,7 +335,7 @@ static int __init hpet_assign_irq(unsign
 {
     int irq;
=20
-    if ( (irq =3D create_irq()) < 0 )
+    if ( (irq =3D create_irq(NUMA_NO_NODE)) < 0 )
         return irq;
=20
     if ( hpet_setup_msi_irq(irq, hpet_events + idx) )
--- 2011-12-12.orig/xen/arch/x86/io_apic.c	2011-11-22 10:57:09.0000000=
00 +0100
+++ 2011-12-12/xen/arch/x86/io_apic.c	2011-12-12 15:24:10.000000000 =
+0100
@@ -995,7 +995,7 @@ static void __init setup_IO_APIC_irqs(vo
                 continue;
=20
             if (IO_APIC_IRQ(irq)) {
-                vector =3D assign_irq_vector(irq);
+                vector =3D assign_irq_vector(irq, NULL);
                 BUG_ON(vector < 0);
                 entry.vector =3D vector;
                 ioapic_register_intr(irq, IOAPIC_AUTO);
@@ -2188,7 +2188,7 @@ int io_apic_set_pci_routing (int ioapic,
     if (!platform_legacy_irq(irq))
         add_pin_to_irq(irq, ioapic, pin);
=20
-    vector =3D assign_irq_vector(irq);
+    vector =3D assign_irq_vector(irq, NULL);
     if (vector < 0)
         return vector;
     entry.vector =3D vector;
@@ -2340,7 +2340,7 @@ int ioapic_guest_write(unsigned long phy
=20
     if ( desc->arch.vector <=3D 0 || desc->arch.vector > LAST_DYNAMIC_VECT=
OR ) {
         add_pin_to_irq(irq, apic, pin);
-        vector =3D assign_irq_vector(irq);
+        vector =3D assign_irq_vector(irq, NULL);
         if ( vector < 0 )
             return vector;
=20
--- 2011-12-12.orig/xen/arch/x86/irq.c	2011-12-12 09:01:34.000000000 =
+0100
+++ 2011-12-12/xen/arch/x86/irq.c	2011-12-12 15:24:15.000000000 =
+0100
@@ -151,7 +151,7 @@ int __init bind_irq_vector(int irq, int=20
 /*
  * Dynamic irq allocate and deallocation for MSI
  */
-int create_irq(void)
+int create_irq(int node)
 {
     int irq, ret;
     struct irq_desc *desc;
@@ -168,7 +168,17 @@ int create_irq(void)
=20
     ret =3D init_one_irq_desc(desc);
     if (!ret)
-        ret =3D assign_irq_vector(irq);
+    {
+        cpumask_t *mask =3D NULL;
+
+        if (node !=3D NUMA_NO_NODE && node >=3D 0)
+        {
+            mask =3D &node_to_cpumask(node);
+            if (cpumask_empty(mask))
+                mask =3D NULL;
+        }
+        ret =3D assign_irq_vector(irq, mask);
+    }
     if (ret < 0)
     {
         desc->arch.used =3D IRQ_UNUSED;
@@ -514,7 +524,7 @@ next:
     return err;
 }
=20
-int assign_irq_vector(int irq)
+int assign_irq_vector(int irq, const cpumask_t *mask)
 {
     int ret;
     unsigned long flags;
@@ -523,7 +533,7 @@ int assign_irq_vector(int irq)
     BUG_ON(irq >=3D nr_irqs || irq <0);
=20
     spin_lock_irqsave(&vector_lock, flags);
-    ret =3D __assign_irq_vector(irq, desc, TARGET_CPUS);
+    ret =3D __assign_irq_vector(irq, desc, mask ?: TARGET_CPUS);
     if (!ret) {
         ret =3D desc->arch.vector;
         cpumask_copy(desc->affinity, desc->arch.cpu_mask);
--- 2011-12-12.orig/xen/arch/x86/physdev.c	2011-12-12 09:01:34.0000000=
00 +0100
+++ 2011-12-12/xen/arch/x86/physdev.c	2011-12-06 16:28:10.000000000 =
+0100
@@ -132,7 +132,7 @@ int physdev_map_pirq(domid_t domid, int=20
     case MAP_PIRQ_TYPE_MSI:
         irq =3D *index;
         if ( irq =3D=3D -1 )
-            irq =3D create_irq();
+            irq =3D create_irq(NUMA_NO_NODE);
=20
         if ( irq < 0 || irq >=3D nr_irqs )
         {
--- 2011-12-12.orig/xen/drivers/passthrough/amd/iommu_init.c	2011-11-29 =
09:19:05.000000000 +0100
+++ 2011-12-12/xen/drivers/passthrough/amd/iommu_init.c	2011-12-06 =
16:27:49.000000000 +0100
@@ -551,7 +551,7 @@ static int __init set_iommu_interrupt_ha
 {
     int irq, ret;
=20
-    irq =3D create_irq();
+    irq =3D create_irq(NUMA_NO_NODE);
     if ( irq <=3D 0 )
     {
         dprintk(XENLOG_ERR, "IOMMU: no irqs\n");
--- 2011-12-12.orig/xen/drivers/passthrough/vtd/iommu.c	2011-11-22 =
10:57:10.000000000 +0100
+++ 2011-12-12/xen/drivers/passthrough/vtd/iommu.c	2011-12-06 =
16:35:42.000000000 +0100
@@ -1096,11 +1096,13 @@ static hw_irq_controller dma_msi_type =3D=20
     .set_affinity =3D dma_msi_set_affinity,
 };
=20
-static int __init iommu_set_interrupt(struct iommu *iommu)
+static int __init iommu_set_interrupt(struct acpi_drhd_unit *drhd)
 {
     int irq, ret;
+    struct acpi_rhsa_unit *rhsa =3D drhd_to_rhsa(drhd);
=20
-    irq =3D create_irq();
+    irq =3D create_irq(rhsa ? pxm_to_node(rhsa->proximity_domain)
+                          : NUMA_NO_NODE);
     if ( irq <=3D 0 )
     {
         dprintk(XENLOG_ERR VTDPREFIX, "IOMMU: no irq available!\n");
@@ -1109,9 +1111,9 @@ static int __init iommu_set_interrupt(st
=20
     irq_desc[irq].handler =3D &dma_msi_type;
 #ifdef CONFIG_X86
-    ret =3D request_irq(irq, iommu_page_fault, 0, "dmar", iommu);
+    ret =3D request_irq(irq, iommu_page_fault, 0, "dmar", drhd->iommu);
 #else
-    ret =3D request_irq_vector(irq, iommu_page_fault, 0, "dmar", iommu);
+    ret =3D request_irq_vector(irq, iommu_page_fault, 0, "dmar", =
drhd->iommu);
 #endif
     if ( ret )
     {
@@ -2133,7 +2135,7 @@ int __init intel_vtd_setup(void)
         if ( !vtd_ept_page_compatible(iommu) )
             iommu_hap_pt_share =3D 0;
=20
-        ret =3D iommu_set_interrupt(iommu);
+        ret =3D iommu_set_interrupt(drhd);
         if ( ret < 0 )
         {
             dprintk(XENLOG_ERR VTDPREFIX, "IOMMU: interrupt setup =
failed\n");
--- 2011-12-12.orig/xen/include/asm-x86/io_apic.h	2011-10-04 =
08:22:17.000000000 +0200
+++ 2011-12-12/xen/include/asm-x86/io_apic.h	2011-12-06 16:24:22.0000000=
00 +0100
@@ -213,9 +213,6 @@ static inline void ioapic_suspend(void)=20
 static inline void ioapic_resume(void) {}
 #endif
=20
-extern int assign_irq_vector(int irq);
-extern int free_irq_vector(int vector);
-
 unsigned highest_gsi(void);
=20
 int ioapic_guest_read( unsigned long physbase, unsigned int reg, u32 =
*pval);
--- 2011-12-12.orig/xen/include/asm-x86/irq.h	2011-11-22 10:57:10.0000000=
00 +0100
+++ 2011-12-12/xen/include/asm-x86/irq.h	2011-12-06 16:25:22.0000000=
00 +0100
@@ -155,8 +155,9 @@ int  init_irq_data(void);
 void clear_irq_vector(int irq);
=20
 int irq_to_vector(int irq);
-int create_irq(void);
+int create_irq(int node);
 void destroy_irq(unsigned int irq);
+int assign_irq_vector(int irq, const cpumask_t *);
=20
 extern void irq_complete_move(struct irq_desc *);
=20



--=__Part614EC482.1__=
Content-Type: text/plain; name="vtd-irq-affinity.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="vtd-irq-affinity.patch"

VT-d: bind IRQs to CPUs local to the node the IOMMU is on=0A=0AThis =
extends create_irq() to take a node parameter, allowing the=0Aresulting =
IRQ to have its destination set to a CPU on that node right=0Aaway, which =
is more natural than having to post-adjust this (and=0Aget e.g. a new IRQ =
vector assigned despite a fresh one was just=0Aobtained).=0A=0AAll other =
callers of create_irq() pass NUMA_NO_NODE for the time being.=0A=0ASigned-o=
ff-by: Jan Beulich <jbeulich@suse.com>=0A=0A--- 2011-12-12.orig/xen/arch/x8=
6/hpet.c	2011-11-11 09:40:55.000000000 +0100=0A+++ 2011-12-12/xen/ar=
ch/x86/hpet.c	2011-12-06 16:36:24.000000000 +0100=0A@@ -11,6 +11,7 @@=0A =
#include <xen/smp.h>=0A #include <xen/softirq.h>=0A #include <xen/irq.h>=0A=
+#include <xen/numa.h>=0A #include <asm/fixmap.h>=0A #include <asm/div64.h>=
=0A #include <asm/hpet.h>=0A@@ -334,7 +335,7 @@ static int __init =
hpet_assign_irq(unsign=0A {=0A     int irq;=0A =0A-    if ( (irq =3D =
create_irq()) < 0 )=0A+    if ( (irq =3D create_irq(NUMA_NO_NODE)) < 0 =
)=0A         return irq;=0A =0A     if ( hpet_setup_msi_irq(irq, hpet_event=
s + idx) )=0A--- 2011-12-12.orig/xen/arch/x86/io_apic.c	2011-11-22 =
10:57:09.000000000 +0100=0A+++ 2011-12-12/xen/arch/x86/io_apic.c	=
2011-12-12 15:24:10.000000000 +0100=0A@@ -995,7 +995,7 @@ static void =
__init setup_IO_APIC_irqs(vo=0A                 continue;=0A =0A           =
  if (IO_APIC_IRQ(irq)) {=0A-                vector =3D assign_irq_vector(i=
rq);=0A+                vector =3D assign_irq_vector(irq, NULL);=0A        =
         BUG_ON(vector < 0);=0A                 entry.vector =3D vector;=0A=
                 ioapic_register_intr(irq, IOAPIC_AUTO);=0A@@ -2188,7 =
+2188,7 @@ int io_apic_set_pci_routing (int ioapic,=0A     if (!platform_le=
gacy_irq(irq))=0A         add_pin_to_irq(irq, ioapic, pin);=0A =0A-    =
vector =3D assign_irq_vector(irq);=0A+    vector =3D assign_irq_vector(irq,=
 NULL);=0A     if (vector < 0)=0A         return vector;=0A     entry.vecto=
r =3D vector;=0A@@ -2340,7 +2340,7 @@ int ioapic_guest_write(unsigned long =
phy=0A =0A     if ( desc->arch.vector <=3D 0 || desc->arch.vector > =
LAST_DYNAMIC_VECTOR ) {=0A         add_pin_to_irq(irq, apic, pin);=0A-     =
   vector =3D assign_irq_vector(irq);=0A+        vector =3D assign_irq_vect=
or(irq, NULL);=0A         if ( vector < 0 )=0A             return =
vector;=0A =0A--- 2011-12-12.orig/xen/arch/x86/irq.c	2011-12-12 =
09:01:34.000000000 +0100=0A+++ 2011-12-12/xen/arch/x86/irq.c	2011-12-12 =
15:24:15.000000000 +0100=0A@@ -151,7 +151,7 @@ int __init bind_irq_vector(i=
nt irq, int =0A /*=0A  * Dynamic irq allocate and deallocation for MSI=0A  =
*/=0A-int create_irq(void)=0A+int create_irq(int node)=0A {=0A     int =
irq, ret;=0A     struct irq_desc *desc;=0A@@ -168,7 +168,17 @@ int =
create_irq(void)=0A =0A     ret =3D init_one_irq_desc(desc);=0A     if =
(!ret)=0A-        ret =3D assign_irq_vector(irq);=0A+    {=0A+        =
cpumask_t *mask =3D NULL;=0A+=0A+        if (node !=3D NUMA_NO_NODE && =
node >=3D 0)=0A+        {=0A+            mask =3D &node_to_cpumask(node);=
=0A+            if (cpumask_empty(mask))=0A+                mask =3D =
NULL;=0A+        }=0A+        ret =3D assign_irq_vector(irq, mask);=0A+    =
}=0A     if (ret < 0)=0A     {=0A         desc->arch.used =3D IRQ_UNUSED;=
=0A@@ -514,7 +524,7 @@ next:=0A     return err;=0A }=0A =0A-int assign_irq_=
vector(int irq)=0A+int assign_irq_vector(int irq, const cpumask_t =
*mask)=0A {=0A     int ret;=0A     unsigned long flags;=0A@@ -523,7 +533,7 =
@@ int assign_irq_vector(int irq)=0A     BUG_ON(irq >=3D nr_irqs || irq =
<0);=0A =0A     spin_lock_irqsave(&vector_lock, flags);=0A-    ret =3D =
__assign_irq_vector(irq, desc, TARGET_CPUS);=0A+    ret =3D __assign_irq_ve=
ctor(irq, desc, mask ?: TARGET_CPUS);=0A     if (!ret) {=0A         ret =
=3D desc->arch.vector;=0A         cpumask_copy(desc->affinity, desc->arch.c=
pu_mask);=0A--- 2011-12-12.orig/xen/arch/x86/physdev.c	2011-12-12 =
09:01:34.000000000 +0100=0A+++ 2011-12-12/xen/arch/x86/physdev.c	=
2011-12-06 16:28:10.000000000 +0100=0A@@ -132,7 +132,7 @@ int physdev_map_p=
irq(domid_t domid, int =0A     case MAP_PIRQ_TYPE_MSI:=0A         irq =3D =
*index;=0A         if ( irq =3D=3D -1 )=0A-            irq =3D create_irq()=
;=0A+            irq =3D create_irq(NUMA_NO_NODE);=0A =0A         if ( irq =
< 0 || irq >=3D nr_irqs )=0A         {=0A--- 2011-12-12.orig/xen/drivers/pa=
ssthrough/amd/iommu_init.c	2011-11-29 09:19:05.000000000 +0100=0A+++ =
2011-12-12/xen/drivers/passthrough/amd/iommu_init.c	2011-12-06 =
16:27:49.000000000 +0100=0A@@ -551,7 +551,7 @@ static int __init set_iommu_=
interrupt_ha=0A {=0A     int irq, ret;=0A =0A-    irq =3D create_irq();=0A+=
    irq =3D create_irq(NUMA_NO_NODE);=0A     if ( irq <=3D 0 )=0A     {=0A =
        dprintk(XENLOG_ERR, "IOMMU: no irqs\n");=0A--- 2011-12-12.orig/xen/=
drivers/passthrough/vtd/iommu.c	2011-11-22 10:57:10.000000000 +0100=0A+++ =
2011-12-12/xen/drivers/passthrough/vtd/iommu.c	2011-12-06 16:35:42.0000000=
00 +0100=0A@@ -1096,11 +1096,13 @@ static hw_irq_controller dma_msi_type =
=3D =0A     .set_affinity =3D dma_msi_set_affinity,=0A };=0A =0A-static =
int __init iommu_set_interrupt(struct iommu *iommu)=0A+static int __init =
iommu_set_interrupt(struct acpi_drhd_unit *drhd)=0A {=0A     int irq, =
ret;=0A+    struct acpi_rhsa_unit *rhsa =3D drhd_to_rhsa(drhd);=0A =0A-    =
irq =3D create_irq();=0A+    irq =3D create_irq(rhsa ? pxm_to_node(rhsa->pr=
oximity_domain)=0A+                          : NUMA_NO_NODE);=0A     if ( =
irq <=3D 0 )=0A     {=0A         dprintk(XENLOG_ERR VTDPREFIX, "IOMMU: no =
irq available!\n");=0A@@ -1109,9 +1111,9 @@ static int __init iommu_set_int=
errupt(st=0A =0A     irq_desc[irq].handler =3D &dma_msi_type;=0A #ifdef =
CONFIG_X86=0A-    ret =3D request_irq(irq, iommu_page_fault, 0, "dmar", =
iommu);=0A+    ret =3D request_irq(irq, iommu_page_fault, 0, "dmar", =
drhd->iommu);=0A #else=0A-    ret =3D request_irq_vector(irq, iommu_page_fa=
ult, 0, "dmar", iommu);=0A+    ret =3D request_irq_vector(irq, iommu_page_f=
ault, 0, "dmar", drhd->iommu);=0A #endif=0A     if ( ret )=0A     {=0A@@ =
-2133,7 +2135,7 @@ int __init intel_vtd_setup(void)=0A         if ( =
!vtd_ept_page_compatible(iommu) )=0A             iommu_hap_pt_share =3D =
0;=0A =0A-        ret =3D iommu_set_interrupt(iommu);=0A+        ret =3D =
iommu_set_interrupt(drhd);=0A         if ( ret < 0 )=0A         {=0A       =
      dprintk(XENLOG_ERR VTDPREFIX, "IOMMU: interrupt setup failed\n");=0A-=
-- 2011-12-12.orig/xen/include/asm-x86/io_apic.h	2011-10-04 =
08:22:17.000000000 +0200=0A+++ 2011-12-12/xen/include/asm-x86/io_apic.h	=
2011-12-06 16:24:22.000000000 +0100=0A@@ -213,9 +213,6 @@ static inline =
void ioapic_suspend(void) =0A static inline void ioapic_resume(void) {}=0A =
#endif=0A =0A-extern int assign_irq_vector(int irq);=0A-extern int =
free_irq_vector(int vector);=0A-=0A unsigned highest_gsi(void);=0A =0A int =
ioapic_guest_read( unsigned long physbase, unsigned int reg, u32 *pval);=0A=
--- 2011-12-12.orig/xen/include/asm-x86/irq.h	2011-11-22 10:57:10.0000000=
00 +0100=0A+++ 2011-12-12/xen/include/asm-x86/irq.h	2011-12-06 =
16:25:22.000000000 +0100=0A@@ -155,8 +155,9 @@ int  init_irq_data(void);=0A=
 void clear_irq_vector(int irq);=0A =0A int irq_to_vector(int irq);=0A-int =
create_irq(void);=0A+int create_irq(int node);=0A void destroy_irq(unsigned=
 int irq);=0A+int assign_irq_vector(int irq, const cpumask_t *);=0A =0A =
extern void irq_complete_move(struct irq_desc *);=0A =0A
--=__Part614EC482.1__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--=__Part614EC482.1__=--


From xen-devel-bounces@lists.xensource.com Mon Dec 12 16:05:37 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 16:05:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ra8NV-00037k-Kf; Mon, 12 Dec 2011 16:05:21 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Ra8NT-00037f-Aa
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 16:05:19 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1323705866!6575781!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDc4NQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30625 invoked from network); 12 Dec 2011 16:04:26 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Dec 2011 16:04:26 -0000
X-IronPort-AV: E=Sophos;i="4.71,339,1320624000"; 
   d="scan'208";a="9422199"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Dec 2011 16:04:26 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 12 Dec 2011 16:04:26 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Ra8Mb-00089X-NV; Mon, 12 Dec 2011 16:04:25 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Ra8Mb-0006Ed-MO;
	Mon, 12 Dec 2011 16:04:25 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20198.9737.680162.103418@mariner.uk.xensource.com>
Date: Mon, 12 Dec 2011 16:04:25 +0000
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
In-Reply-To: <alpine.DEB.2.00.1112121453050.3517@kaball-desktop>
References: <1323108621-22654-1-git-send-email-ian.jackson@eu.citrix.com>
	<1323108621-22654-16-git-send-email-ian.jackson@eu.citrix.com>
	<alpine.DEB.2.00.1112091558300.3517@kaball-desktop>
	<20194.22539.574524.956955@mariner.uk.xensource.com>
	<1323463293.20936.11.camel@dagon.hellion.org.uk>
	<20197.59428.699013.507183@mariner.uk.xensource.com>
	<1323692225.20077.183.camel@zakaz.uk.xensource.com>
	<20197.62462.189827.239656@mariner.uk.xensource.com>
	<1323697723.20077.212.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1112121453050.3517@kaball-desktop>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH 15/15] libxl: New event generation API
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Stefano Stabellini writes ("Re: [Xen-devel] [PATCH 15/15] libxl: New event generation API"):
> On Mon, 12 Dec 2011, Ian Campbell wrote:
> > On Mon, 2011-12-12 at 12:30 +0000, Ian Jackson wrote:
> > > In general this means that functions which lock the ctx must not
> > > allocate an inner gc.
> 
> this is quite an important limitation and change in behaviour!

Luckily I have only introduced the ctx lock in this series so there is
no existing code which violates this rule.

> > It's probably not so important for memory allocation cleanup but it
> > would be a semantically useful change for the callbacks if we could
> > arrange for them to happen only on final exit of the library -- exactly
> > because of the difficulty of reasoning about things otherwise. Alas I
> > can't think of a good way to do this since the ctx can be shared, thread
> > local storage would be one or libxl__gc_owner could return a special
> > "nested ctx" instead of the real outer ctx, but, ick.
> 
> I think that using TLS to increase/decrease a nesting counter would OK
> in this case. We could have a libxl__enter and a libxl__exit function
> that take care it this.
> 
> Modifying libxl__gc_owner could lead to errors because it doesn't handle
> the case in which an externally visible function calls another
> externally visible function: libxl__gc_owner wouldn't even be called in
> this case.

I suggested to Ian the moral equivalent of:

#define CTX_LOCK \
     <previous implementation> \
     ctx->recursive_lock_counter++

#define GC_INIT \
     CTX_LOCK; \
     assert(ctx->recursive_lock_counter==1); \
     CTX_UNLOCK

but I don't think this is really very nice.


I think the answer is to write a comment saying that it is forbidden
to allocate a new gc with the ctx locked.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 16:05:37 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 16:05:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ra8NV-00037k-Kf; Mon, 12 Dec 2011 16:05:21 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Ra8NT-00037f-Aa
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 16:05:19 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1323705866!6575781!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDc4NQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30625 invoked from network); 12 Dec 2011 16:04:26 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Dec 2011 16:04:26 -0000
X-IronPort-AV: E=Sophos;i="4.71,339,1320624000"; 
   d="scan'208";a="9422199"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Dec 2011 16:04:26 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 12 Dec 2011 16:04:26 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Ra8Mb-00089X-NV; Mon, 12 Dec 2011 16:04:25 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Ra8Mb-0006Ed-MO;
	Mon, 12 Dec 2011 16:04:25 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20198.9737.680162.103418@mariner.uk.xensource.com>
Date: Mon, 12 Dec 2011 16:04:25 +0000
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
In-Reply-To: <alpine.DEB.2.00.1112121453050.3517@kaball-desktop>
References: <1323108621-22654-1-git-send-email-ian.jackson@eu.citrix.com>
	<1323108621-22654-16-git-send-email-ian.jackson@eu.citrix.com>
	<alpine.DEB.2.00.1112091558300.3517@kaball-desktop>
	<20194.22539.574524.956955@mariner.uk.xensource.com>
	<1323463293.20936.11.camel@dagon.hellion.org.uk>
	<20197.59428.699013.507183@mariner.uk.xensource.com>
	<1323692225.20077.183.camel@zakaz.uk.xensource.com>
	<20197.62462.189827.239656@mariner.uk.xensource.com>
	<1323697723.20077.212.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1112121453050.3517@kaball-desktop>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH 15/15] libxl: New event generation API
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Stefano Stabellini writes ("Re: [Xen-devel] [PATCH 15/15] libxl: New event generation API"):
> On Mon, 12 Dec 2011, Ian Campbell wrote:
> > On Mon, 2011-12-12 at 12:30 +0000, Ian Jackson wrote:
> > > In general this means that functions which lock the ctx must not
> > > allocate an inner gc.
> 
> this is quite an important limitation and change in behaviour!

Luckily I have only introduced the ctx lock in this series so there is
no existing code which violates this rule.

> > It's probably not so important for memory allocation cleanup but it
> > would be a semantically useful change for the callbacks if we could
> > arrange for them to happen only on final exit of the library -- exactly
> > because of the difficulty of reasoning about things otherwise. Alas I
> > can't think of a good way to do this since the ctx can be shared, thread
> > local storage would be one or libxl__gc_owner could return a special
> > "nested ctx" instead of the real outer ctx, but, ick.
> 
> I think that using TLS to increase/decrease a nesting counter would OK
> in this case. We could have a libxl__enter and a libxl__exit function
> that take care it this.
> 
> Modifying libxl__gc_owner could lead to errors because it doesn't handle
> the case in which an externally visible function calls another
> externally visible function: libxl__gc_owner wouldn't even be called in
> this case.

I suggested to Ian the moral equivalent of:

#define CTX_LOCK \
     <previous implementation> \
     ctx->recursive_lock_counter++

#define GC_INIT \
     CTX_LOCK; \
     assert(ctx->recursive_lock_counter==1); \
     CTX_UNLOCK

but I don't think this is really very nice.


I think the answer is to write a comment saying that it is forbidden
to allocate a new gc with the ctx locked.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 16:09:04 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 16: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.xensource.com>)
	id 1Ra8Qs-0003HW-L6; Mon, 12 Dec 2011 16:08:50 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Ra8Qq-0003HJ-Vl
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 16:08:49 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1323706075!5047955!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12326 invoked from network); 12 Dec 2011 16:07:56 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-15.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 12 Dec 2011 16:07:56 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 12 Dec 2011 16:07:55 +0000
Message-Id: <4EE635220200007800067047@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 12 Dec 2011 16:08:50 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Subject: [Xen-devel] [PATCH 0/4] ACPI: update firmware interface headers
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This set of patches eliminates bogus duplicate structure definitions,
which accumulated in a couple of places where they don't belong. To
facilitate this, the interface headers get updated to what is being used
on Linux 3.1 (also 3.2-rc), with two or three minor adjustments.

1: eliminate duplicate MADT parsing and unused SBF definitions
2: update table interface headers
3: eliminate duplicate DMAR definitions
4: eliminate duplicate IVRS definitions

Original and new code were verified to produce identical code, with
the sole exception of places where e.g. bitfield were used in the
stray structure definitions, and full width fields with manifest constant
masks get used now.

Signed-off-by: Jan Beulich <jbeulich@suse.com>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 16:09:04 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 16: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.xensource.com>)
	id 1Ra8Qs-0003HW-L6; Mon, 12 Dec 2011 16:08:50 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Ra8Qq-0003HJ-Vl
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 16:08:49 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1323706075!5047955!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12326 invoked from network); 12 Dec 2011 16:07:56 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-15.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 12 Dec 2011 16:07:56 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 12 Dec 2011 16:07:55 +0000
Message-Id: <4EE635220200007800067047@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 12 Dec 2011 16:08:50 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Subject: [Xen-devel] [PATCH 0/4] ACPI: update firmware interface headers
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This set of patches eliminates bogus duplicate structure definitions,
which accumulated in a couple of places where they don't belong. To
facilitate this, the interface headers get updated to what is being used
on Linux 3.1 (also 3.2-rc), with two or three minor adjustments.

1: eliminate duplicate MADT parsing and unused SBF definitions
2: update table interface headers
3: eliminate duplicate DMAR definitions
4: eliminate duplicate IVRS definitions

Original and new code were verified to produce identical code, with
the sole exception of places where e.g. bitfield were used in the
stray structure definitions, and full width fields with manifest constant
masks get used now.

Signed-off-by: Jan Beulich <jbeulich@suse.com>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 16:09:55 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 16: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.xensource.com>)
	id 1Ra8Rj-0003Lr-3e; Mon, 12 Dec 2011 16:09:43 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Ra8Rg-0003LL-UO
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 16:09:41 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1323706126!7073766!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23752 invoked from network); 12 Dec 2011 16:08:46 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-14.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 12 Dec 2011 16:08:46 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 12 Dec 2011 16:08:45 +0000
Message-Id: <4EE63551020000780006705C@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 12 Dec 2011 16:09:37 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartB6991351.0__="
Subject: [Xen-devel] [PATCH 1/4] ACPI: eliminate duplicate MADT parsing and
 unused SBF definitions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__PartB6991351.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Use their proper counterparts in include/acpi/actbl*.h instead.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/ia64/xen/dom_fw_common.c
+++ b/xen/arch/ia64/xen/dom_fw_common.c
@@ -347,7 +347,7 @@ struct fake_acpi_tables {
 	struct acpi_table_header dsdt;
 	uint8_t aml[8 + 11 * MAX_VIRT_CPUS];
 	struct acpi_table_madt madt;
-	struct acpi_table_lsapic lsapic[MAX_VIRT_CPUS];
+	struct acpi_madt_local_sapic lsapic[MAX_VIRT_CPUS];
 	uint8_t pm1a_event_block[4];
 	uint8_t pm1a_control_block[1];
 	uint8_t pm_timer_block[4];
@@ -365,7 +365,7 @@ dom_fw_fake_acpi(domain_t *d, struct fak
 	struct acpi_table_facs *facs =3D &tables->facs;
 	struct acpi_table_header *dsdt =3D &tables->dsdt;
 	struct acpi_table_madt *madt =3D &tables->madt;
-	struct acpi_table_lsapic *lsapic =3D tables->lsapic;
+	struct acpi_madt_local_sapic *lsapic =3D tables->lsapic;
 	int i;
 	int aml_len;
 	int nbr_cpus;
@@ -492,18 +492,18 @@ dom_fw_fake_acpi(domain_t *d, struct fak
 	/* An LSAPIC entry describes a CPU.  */
 	nbr_cpus =3D 0;
 	for (i =3D 0; i < MAX_VIRT_CPUS; i++) {
-		lsapic[i].header.type =3D ACPI_MADT_LSAPIC;
-		lsapic[i].header.length =3D sizeof(struct acpi_table_lsapic=
);
-		lsapic[i].acpi_id =3D i;
+		lsapic[i].header.type =3D ACPI_MADT_TYPE_LOCAL_SAPIC;
+		lsapic[i].header.length =3D sizeof(lsapic[i]);
+		lsapic[i].processor_id =3D i;
 		lsapic[i].id =3D i;
 		lsapic[i].eid =3D 0;
 		if (xen_ia64_is_vcpu_allocated(d, i)) {
-			lsapic[i].flags.enabled =3D 1;
+			lsapic[i].lapic_flags =3D ACPI_MADT_ENABLED;
 			nbr_cpus++;
 		}
 	}
 	madt->header.length =3D sizeof(struct acpi_table_madt) +
-	                      nbr_cpus * sizeof(struct acpi_table_lsapic);
+	                      nbr_cpus * sizeof(*lsapic);
 	madt->header.checksum =3D -acpi_tb_checksum((u8*)madt,
 						  madt->header.length);
 	return;
--- a/xen/arch/ia64/xen/dom_fw_dom0.c
+++ b/xen/arch/ia64/xen/dom_fw_dom0.c
@@ -53,11 +53,11 @@ static u32 lsapic_nbr;
 static int __init
 acpi_update_lsapic(struct acpi_subtable_header * header, const unsigned =
long end)
 {
-	struct acpi_table_lsapic *lsapic;
+	struct acpi_madt_local_sapic *lsapic =3D
+		container_of(header, struct acpi_madt_local_sapic, =
header);
 	int enable;
=20
-	lsapic =3D (struct acpi_table_lsapic *)header;
-	if (!lsapic)
+	if (!header)
 		return -EINVAL;
=20
 	if (lsapic_nbr < dom0->max_vcpus && dom0->vcpu[lsapic_nbr] !=3D =
NULL)
@@ -65,14 +65,14 @@ acpi_update_lsapic(struct acpi_subtable_
 	else
 		enable =3D 0;
=20
-	if (lsapic->flags.enabled && enable) {
+	if ((lsapic->lapic_flags & ACPI_MADT_ENABLED) && enable) {
 		printk("enable lsapic entry: 0x%lx\n", (u64) lsapic);
 		lsapic->id =3D lsapic_nbr;
 		lsapic->eid =3D 0;
 		lsapic_nbr++;
-	} else if (lsapic->flags.enabled) {
+	} else if (lsapic->lapic_flags & ACPI_MADT_ENABLED) {
 		printk("DISABLE lsapic entry: 0x%lx\n", (u64) lsapic);
-		lsapic->flags.enabled =3D 0;
+		lsapic->lapic_flags &=3D ~ACPI_MADT_ENABLED;
 		lsapic->id =3D 0;
 		lsapic->eid =3D 0;
 	}
@@ -83,10 +83,11 @@ static int __init
 acpi_patch_plat_int_src(struct acpi_subtable_header * header,
 			const unsigned long end)
 {
-	struct acpi_table_plat_int_src *plintsrc;
+	struct acpi_madt_interrupt_source *plintsrc =3D
+		container_of(header, struct acpi_madt_interrupt_source,
+			     header);
=20
-	plintsrc =3D (struct acpi_table_plat_int_src *)header;
-	if (!plintsrc)
+	if (!header)
 		return -EINVAL;
=20
 	if (plintsrc->type =3D=3D ACPI_INTERRUPT_CPEI) {
@@ -193,12 +194,13 @@ static void __init touch_acpi_table(void
 	 */
 	acpi_table_parse(ACPI_SIG_MADT, acpi_backup_table);
=20
-	if (acpi_table_parse_madt(ACPI_MADT_LSAPIC, acpi_update_lsapic, 0) =
< 0)
+	if (acpi_table_parse_madt(ACPI_MADT_TYPE_LOCAL_SAPIC,
+				  acpi_update_lsapic, 0) < 0)
 		printk("Error parsing MADT - no LAPIC entries\n");
=20
 	acpi_update_madt_checksum(madt);
=20
-	if (acpi_table_parse_madt(ACPI_MADT_PLAT_INT_SRC,
+	if (acpi_table_parse_madt(ACPI_MADT_TYPE_INTERRUPT_SOURCE,
 				  acpi_patch_plat_int_src, 0) < 0)
 		printk("Error parsing MADT - no PLAT_INT_SRC entries\n");
=20
--- a/xen/arch/x86/acpi/boot.c
+++ b/xen/arch/x86/acpi/boot.c
@@ -87,9 +87,9 @@ static int __init acpi_parse_madt(struct
 static int __init
 acpi_parse_x2apic(struct acpi_subtable_header *header, const unsigned =
long end)
 {
-	struct acpi_table_x2apic *processor =3D NULL;
-
-	processor =3D (struct acpi_table_x2apic *)header;
+	struct acpi_madt_local_x2apic *processor =3D
+		container_of(header, struct acpi_madt_local_x2apic, =
header);
+	bool_t enabled =3D 0;
=20
 	if (BAD_MADT_ENTRY(processor, end))
 		return -EINVAL;
@@ -97,8 +97,11 @@ acpi_parse_x2apic(struct acpi_subtable_h
 	acpi_table_print_madt_entry(header);
=20
 	/* Record local apic id only when enabled */
-	if (processor->flags.enabled)
-		x86_acpiid_to_apicid[processor->acpi_uid] =3D processor->id=
;
+	if (processor->lapic_flags & ACPI_MADT_ENABLED) {
+		x86_acpiid_to_apicid[processor->uid] =3D
+			processor->local_apic_id;
+		enabled =3D 1;
+	}
=20
 	/*
 	 * We need to register disabled CPU as well to permit
@@ -107,9 +110,7 @@ acpi_parse_x2apic(struct acpi_subtable_h
 	 * to not preallocating memory for all NR_CPUS
 	 * when we use CPU hotplug.
 	 */
-	mp_register_lapic(processor->id,	/* X2APIC ID */
-			  processor->flags.enabled,	/* Enabled? */
-			  0);
+	mp_register_lapic(processor->local_apic_id, enabled, 0);
=20
 	return 0;
 }
@@ -117,9 +118,9 @@ acpi_parse_x2apic(struct acpi_subtable_h
 static int __init
 acpi_parse_lapic(struct acpi_subtable_header * header, const unsigned =
long end)
 {
-	struct acpi_table_lapic *processor =3D NULL;
-
-	processor =3D (struct acpi_table_lapic *)header;
+	struct acpi_madt_local_apic *processor =3D
+		container_of(header, struct acpi_madt_local_apic, header);
+	bool_t enabled =3D 0;
=20
 	if (BAD_MADT_ENTRY(processor, end))
 		return -EINVAL;
@@ -127,8 +128,10 @@ acpi_parse_lapic(struct acpi_subtable_he
 	acpi_table_print_madt_entry(header);
=20
 	/* Record local apic id only when enabled */
-	if (processor->flags.enabled)
-		x86_acpiid_to_apicid[processor->acpi_id] =3D processor->id;=

+	if (processor->lapic_flags & ACPI_MADT_ENABLED) {
+		x86_acpiid_to_apicid[processor->processor_id] =3D =
processor->id;
+		enabled =3D 1;
+	}
=20
 	/*
 	 * We need to register disabled CPU as well to permit
@@ -137,9 +140,7 @@ acpi_parse_lapic(struct acpi_subtable_he
 	 * to not preallocating memory for all NR_CPUS
 	 * when we use CPU hotplug.
 	 */
-	mp_register_lapic(processor->id,	/* APIC ID */
-			  processor->flags.enabled,	/* Enabled? */
-			  0);
+	mp_register_lapic(processor->id, enabled, 0);
=20
 	return 0;
 }
@@ -148,9 +149,9 @@ static int __init
 acpi_parse_lapic_addr_ovr(struct acpi_subtable_header * header,
 			  const unsigned long end)
 {
-	struct acpi_table_lapic_addr_ovr *lapic_addr_ovr =3D NULL;
-
-	lapic_addr_ovr =3D (struct acpi_table_lapic_addr_ovr *)header;
+	struct acpi_madt_local_apic_override *lapic_addr_ovr =3D
+		container_of(header, struct acpi_madt_local_apic_override,
+			     header);
=20
 	if (BAD_MADT_ENTRY(lapic_addr_ovr, end))
 		return -EINVAL;
@@ -164,9 +165,9 @@ static int __init
 acpi_parse_x2apic_nmi(struct acpi_subtable_header *header,
 		      const unsigned long end)
 {
-	struct acpi_table_x2apic_nmi *x2apic_nmi =3D NULL;
-
-	x2apic_nmi =3D (struct acpi_table_x2apic_nmi *)header;
+	struct acpi_madt_local_x2apic_nmi *x2apic_nmi =3D
+		container_of(header, struct acpi_madt_local_x2apic_nmi,
+			     header);
=20
 	if (BAD_MADT_ENTRY(x2apic_nmi, end))
 		return -EINVAL;
@@ -182,9 +183,8 @@ acpi_parse_x2apic_nmi(struct acpi_subtab
 static int __init
 acpi_parse_lapic_nmi(struct acpi_subtable_header * header, const unsigned =
long end)
 {
-	struct acpi_table_lapic_nmi *lapic_nmi =3D NULL;
-
-	lapic_nmi =3D (struct acpi_table_lapic_nmi *)header;
+	struct acpi_madt_local_apic_nmi *lapic_nmi =3D
+		container_of(header, struct acpi_madt_local_apic_nmi, =
header);
=20
 	if (BAD_MADT_ENTRY(lapic_nmi, end))
 		return -EINVAL;
@@ -204,9 +204,8 @@ acpi_parse_lapic_nmi(struct acpi_subtabl
 static int __init
 acpi_parse_ioapic(struct acpi_subtable_header * header, const unsigned =
long end)
 {
-	struct acpi_table_ioapic *ioapic =3D NULL;
-
-	ioapic =3D (struct acpi_table_ioapic *)header;
+	struct acpi_madt_io_apic *ioapic =3D
+		container_of(header, struct acpi_madt_io_apic, header);
=20
 	if (BAD_MADT_ENTRY(ioapic, end))
 		return -EINVAL;
@@ -223,9 +222,9 @@ static int __init
 acpi_parse_int_src_ovr(struct acpi_subtable_header * header,
 		       const unsigned long end)
 {
-	struct acpi_table_int_src_ovr *intsrc =3D NULL;
-
-	intsrc =3D (struct acpi_table_int_src_ovr *)header;
+	struct acpi_madt_interrupt_override *intsrc =3D
+		container_of(header, struct acpi_madt_interrupt_override,
+			     header);
=20
 	if (BAD_MADT_ENTRY(intsrc, end))
 		return -EINVAL;
@@ -233,14 +232,15 @@ acpi_parse_int_src_ovr(struct acpi_subta
 	acpi_table_print_madt_entry(header);
=20
 	if (acpi_skip_timer_override &&
-		intsrc->bus_irq =3D=3D 0 && intsrc->global_irq =3D=3D 2) {
+	    intsrc->source_irq =3D=3D 0 && intsrc->global_irq =3D=3D 2) {
 			printk(PREFIX "BIOS IRQ0 pin2 override ignored.\n")=
;
 			return 0;
 	}
=20
-	mp_override_legacy_irq(intsrc->bus_irq,
-			       intsrc->flags.polarity,
-			       intsrc->flags.trigger, intsrc->global_irq);
+	mp_override_legacy_irq(intsrc->source_irq,
+			       ACPI_MADT_GET_POLARITY(intsrc->inti_flags),
+			       ACPI_MADT_GET_TRIGGER(intsrc->inti_flags),
+			       intsrc->global_irq);
=20
 	return 0;
 }
@@ -248,9 +248,8 @@ acpi_parse_int_src_ovr(struct acpi_subta
 static int __init
 acpi_parse_nmi_src(struct acpi_subtable_header * header, const unsigned =
long end)
 {
-	struct acpi_table_nmi_src *nmi_src =3D NULL;
-
-	nmi_src =3D (struct acpi_table_nmi_src *)header;
+	struct acpi_madt_nmi_source *nmi_src =3D
+		container_of(header, struct acpi_madt_nmi_source, header);
=20
 	if (BAD_MADT_ENTRY(nmi_src, end))
 		return -EINVAL;
@@ -270,7 +269,7 @@ static int __init acpi_parse_hpet(struct
 {
 	struct acpi_table_hpet *hpet_tbl =3D (struct acpi_table_hpet =
*)table;
=20
-	if (hpet_tbl->address.space_id !=3D ACPI_SPACE_MEM) {
+	if (hpet_tbl->address.space_id !=3D ACPI_ADR_SPACE_SYSTEM_MEMORY) =
{
 		printk(KERN_WARNING PREFIX "HPET timers must be located in =
"
 		       "memory.\n");
 		return -1;
--- a/xen/arch/x86/srat.c
+++ b/xen/arch/x86/srat.c
@@ -396,7 +396,8 @@ void __init srat_parse_regions(u64 addr)
 		return;
=20
 	srat_region_mask =3D fill_mask(addr - 1);
-	acpi_table_parse_srat(ACPI_SRAT_MEMORY_AFFINITY, srat_parse_region,=
 0);
+	acpi_table_parse_srat(ACPI_SRAT_TYPE_MEMORY_AFFINITY,
+			      srat_parse_region, 0);
=20
 	for (mask =3D srat_region_mask, i =3D 0; mask && i < e820.nr_map; =
i++) {
 		if (e820.map[i].type !=3D E820_RAM)
--- a/xen/drivers/acpi/numa.c
+++ b/xen/drivers/acpi/numa.c
@@ -46,7 +46,7 @@ void __init acpi_table_print_srat_entry(
=20
 	switch (header->type) {
=20
-	case ACPI_SRAT_PROCESSOR_AFFINITY:
+	case ACPI_SRAT_TYPE_CPU_AFFINITY:
 #ifdef ACPI_DEBUG_OUTPUT
 		{
 			struct acpi_srat_cpu_affinity *p =3D
@@ -68,7 +68,7 @@ void __init acpi_table_print_srat_entry(
 #endif				/* ACPI_DEBUG_OUTPUT */
 		break;
=20
-	case ACPI_SRAT_MEMORY_AFFINITY:
+	case ACPI_SRAT_TYPE_MEMORY_AFFINITY:
 #ifdef ACPI_DEBUG_OUTPUT
 		{
 			struct acpi_srat_mem_affinity *p =3D
@@ -194,8 +194,8 @@ int __init acpi_parse_srat(struct acpi_t
 }
=20
 int __init
-acpi_table_parse_srat(enum acpi_srat_entry_id id,
-		      acpi_madt_entry_handler handler, unsigned int =
max_entries)
+acpi_table_parse_srat(int id, acpi_madt_entry_handler handler,
+		      unsigned int max_entries)
 {
 	return acpi_table_parse_entries(ACPI_SIG_SRAT,
 					sizeof(struct acpi_table_srat), =
id,
@@ -206,12 +206,13 @@ int __init acpi_numa_init(void)
 {
 	/* SRAT: Static Resource Affinity Table */
 	if (!acpi_table_parse(ACPI_SIG_SRAT, acpi_parse_srat)) {
-		acpi_table_parse_srat(ACPI_SRAT_X2APIC_AFFINITY,
-				           acpi_parse_x2apic_affinity, =
NR_CPUS);
-		acpi_table_parse_srat(ACPI_SRAT_PROCESSOR_AFFINITY,
-					       acpi_parse_processor_affinit=
y,
-					       NR_CPUS);
-		acpi_table_parse_srat(ACPI_SRAT_MEMORY_AFFINITY, acpi_parse=
_memory_affinity, NR_NODE_MEMBLKS);	// IA64 specific
+		acpi_table_parse_srat(ACPI_SRAT_TYPE_X2APIC_CPU_AFFINITY,
+				      acpi_parse_x2apic_affinity, =
NR_CPUS);
+		acpi_table_parse_srat(ACPI_SRAT_TYPE_CPU_AFFINITY,
+				      acpi_parse_processor_affinity, =
NR_CPUS);
+		acpi_table_parse_srat(ACPI_SRAT_TYPE_MEMORY_AFFINITY,
+				      acpi_parse_memory_affinity,
+				      NR_NODE_MEMBLKS);
 	}
=20
 	/* SLIT: System Locality Information Table */
--- a/xen/include/xen/acpi.h
+++ b/xen/include/xen/acpi.h
@@ -34,123 +34,13 @@
 #include <acpi/acpi.h>
 #include <asm/acpi.h>
=20
-#ifdef CONFIG_ACPI_BOOT
-
-enum acpi_madt_entry_id {
-	ACPI_MADT_LAPIC =3D 0,
-	ACPI_MADT_IOAPIC,
-	ACPI_MADT_INT_SRC_OVR,
-	ACPI_MADT_NMI_SRC,
-	ACPI_MADT_LAPIC_NMI,
-	ACPI_MADT_LAPIC_ADDR_OVR,
-	ACPI_MADT_IOSAPIC,
-	ACPI_MADT_LSAPIC,
-	ACPI_MADT_PLAT_INT_SRC,
-	ACPI_MADT_X2APIC,
-	ACPI_MADT_X2APIC_NMI,
-	ACPI_MADT_ENTRY_COUNT
-};
-
-typedef struct {
-	u16			polarity:2;
-	u16			trigger:2;
-	u16			reserved:12;
-} __attribute__ ((packed)) acpi_interrupt_flags;
-
-struct acpi_table_lapic {
-	struct acpi_subtable_header	header;
-	u8			acpi_id;
-	u8			id;
-	struct {
-		u32			enabled:1;
-		u32			reserved:31;
-	}			flags;
-} __attribute__ ((packed));
-
-struct acpi_table_x2apic {
-	struct acpi_subtable_header header;
-	u16			reserved;
-	u32			id;
-	struct {
-		u32			enabled:1;
-		u32			reserved:31;
-	}			flags;
-	u32         acpi_uid;
-} __attribute__ ((packed));
-
-struct acpi_table_ioapic {
-	struct acpi_subtable_header	header;
-	u8			id;
-	u8			reserved;
-	u32			address;
-	u32			global_irq_base;
-} __attribute__ ((packed));
-
-struct acpi_table_int_src_ovr {
-	struct acpi_subtable_header	header;
-	u8			bus;
-	u8			bus_irq;
-	u32			global_irq;
-	acpi_interrupt_flags	flags;
-} __attribute__ ((packed));
-
-struct acpi_table_nmi_src {
-	struct acpi_subtable_header	header;
-	acpi_interrupt_flags	flags;
-	u32			global_irq;
-} __attribute__ ((packed));
-
-struct acpi_table_lapic_nmi {
-	struct acpi_subtable_header	header;
-	u8			acpi_id;
-	acpi_interrupt_flags	flags;
-	u8			lint;
-} __attribute__ ((packed));
-
-struct acpi_table_x2apic_nmi {
-	struct acpi_subtable_header header;
-	acpi_interrupt_flags	flags;
-	u32			acpi_uid;
-	u8			lint;
-	u8			reserved[3];
-} __attribute__ ((packed));
+#define ACPI_MADT_GET_(fld, x) (((x) & ACPI_MADT_##fld##_MASK) / \
+	(ACPI_MADT_##fld##_MASK & -ACPI_MADT_##fld##_MASK))
=20
-struct acpi_table_lapic_addr_ovr {
-	struct acpi_subtable_header	header;
-	u8			reserved[2];
-	u64			address;
-} __attribute__ ((packed));
-
-struct acpi_table_iosapic {
-	struct acpi_subtable_header	header;
-	u8			id;
-	u8			reserved;
-	u32			global_irq_base;
-	u64			address;
-} __attribute__ ((packed));
-
-struct acpi_table_lsapic {
-	struct acpi_subtable_header	header;
-	u8			acpi_id;
-	u8			id;
-	u8			eid;
-	u8			reserved[3];
-	struct {
-		u32			enabled:1;
-		u32			reserved:31;
-	}			flags;
-} __attribute__ ((packed));
+#define ACPI_MADT_GET_POLARITY(inti)	ACPI_MADT_GET_(POLARITY, inti)
+#define ACPI_MADT_GET_TRIGGER(inti)	ACPI_MADT_GET_(TRIGGER, inti)
=20
-struct acpi_table_plat_int_src {
-	struct acpi_subtable_header	header;
-	acpi_interrupt_flags	flags;
-	u8			type;	/* See acpi_interrupt_type */
-	u8			id;
-	u8			eid;
-	u8			iosapic_vector;
-	u32			global_irq;
-	u32			reserved;
-} __attribute__ ((packed));
+#ifdef CONFIG_ACPI_BOOT
=20
 enum acpi_interrupt_id {
 	ACPI_INTERRUPT_PMI	=3D 1,
@@ -159,42 +49,6 @@ enum acpi_interrupt_id {
 	ACPI_INTERRUPT_COUNT
 };
=20
-#define	ACPI_SPACE_MEM		0
-
-/*
- * Simple Boot Flags
- * http://www.microsoft.com/whdc/hwdev/resources/specs/simp_bios.mspx=20
- */
-struct acpi_table_sbf
-{
-	u8 sbf_signature[4];
-	u32 sbf_len;
-	u8 sbf_revision;
-	u8 sbf_csum;
-	u8 sbf_oemid[6];
-	u8 sbf_oemtable[8];
-	u8 sbf_revdata[4];
-	u8 sbf_creator[4];
-	u8 sbf_crearev[4];
-	u8 sbf_cmos;
-	u8 sbf_spare[3];
-} __attribute__ ((packed));
-
-enum acpi_srat_entry_id {
-	ACPI_SRAT_PROCESSOR_AFFINITY =3D 0,
-	ACPI_SRAT_MEMORY_AFFINITY,
-	ACPI_SRAT_X2APIC_AFFINITY,
-	ACPI_SRAT_ENTRY_COUNT
-};
-
-enum acpi_address_range_id {
-	ACPI_ADDRESS_RANGE_MEMORY =3D 1,
-	ACPI_ADDRESS_RANGE_RESERVED =3D 2,
-	ACPI_ADDRESS_RANGE_ACPI =3D 3,
-	ACPI_ADDRESS_RANGE_NVS	=3D 4,
-	ACPI_ADDRESS_RANGE_COUNT
-};
-
 /* DMA Remapping Reporting Table (DMAR) */
=20
 #define DMAR_FLAGS_INTR_REMAP 0x1       /* intr remap supported */
@@ -282,8 +136,8 @@ int acpi_table_parse(char *id, acpi_tabl
 int acpi_table_parse_entries(char *id, unsigned long table_size,
 	int entry_id, acpi_table_entry_handler handler, unsigned int =
max_entries);
 int acpi_table_parse_madt(enum acpi_madt_type id, acpi_table_entry_handler=
 handler, unsigned int max_entries);
-int acpi_table_parse_srat(enum acpi_srat_entry_id id,
-	acpi_madt_entry_handler handler, unsigned int max_entries);
+int acpi_table_parse_srat(int id, acpi_madt_entry_handler handler,
+	unsigned int max_entries);
 int acpi_parse_srat(struct acpi_table_header *);
 void acpi_table_print (struct acpi_table_header *header, unsigned long =
phys_addr);
 void acpi_table_print_madt_entry (struct acpi_subtable_header *madt);



--=__PartB6991351.0__=
Content-Type: text/plain; name="acpi-duplicate-structs.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="acpi-duplicate-structs.patch"

ACPI: eliminate duplicate MADT parsing and unused SBF definitions=0A=0AUse =
their proper counterparts in include/acpi/actbl*.h instead.=0A=0ASigned-off=
-by: Jan Beulich <jbeulich@suse.com>=0A=0A--- a/xen/arch/ia64/xen/dom_fw_co=
mmon.c=0A+++ b/xen/arch/ia64/xen/dom_fw_common.c=0A@@ -347,7 +347,7 @@ =
struct fake_acpi_tables {=0A 	struct acpi_table_header dsdt;=0A 	=
uint8_t aml[8 + 11 * MAX_VIRT_CPUS];=0A 	struct acpi_table_madt =
madt;=0A-	struct acpi_table_lsapic lsapic[MAX_VIRT_CPUS];=0A+	=
struct acpi_madt_local_sapic lsapic[MAX_VIRT_CPUS];=0A 	uint8_t pm1a_event_=
block[4];=0A 	uint8_t pm1a_control_block[1];=0A 	uint8_t pm_timer_bl=
ock[4];=0A@@ -365,7 +365,7 @@ dom_fw_fake_acpi(domain_t *d, struct fak=0A 	=
struct acpi_table_facs *facs =3D &tables->facs;=0A 	struct acpi_table_h=
eader *dsdt =3D &tables->dsdt;=0A 	struct acpi_table_madt *madt =3D =
&tables->madt;=0A-	struct acpi_table_lsapic *lsapic =3D tables->lsapic=
;=0A+	struct acpi_madt_local_sapic *lsapic =3D tables->lsapic;=0A 	=
int i;=0A 	int aml_len;=0A 	int nbr_cpus;=0A@@ -492,18 +492,18 =
@@ dom_fw_fake_acpi(domain_t *d, struct fak=0A 	/* An LSAPIC entry =
describes a CPU.  */=0A 	nbr_cpus =3D 0;=0A 	for (i =3D 0; i < =
MAX_VIRT_CPUS; i++) {=0A-		lsapic[i].header.type =3D =
ACPI_MADT_LSAPIC;=0A-		lsapic[i].header.length =3D sizeof(struct =
acpi_table_lsapic);=0A-		lsapic[i].acpi_id =3D i;=0A+		=
lsapic[i].header.type =3D ACPI_MADT_TYPE_LOCAL_SAPIC;=0A+		=
lsapic[i].header.length =3D sizeof(lsapic[i]);=0A+		lsapic[i].p=
rocessor_id =3D i;=0A 		lsapic[i].id =3D i;=0A 		lsapic[i].e=
id =3D 0;=0A 		if (xen_ia64_is_vcpu_allocated(d, i)) {=0A-		=
	lsapic[i].flags.enabled =3D 1;=0A+			lsapic[i].l=
apic_flags =3D ACPI_MADT_ENABLED;=0A 			nbr_cpus++;=0A 		=
}=0A 	}=0A 	madt->header.length =3D sizeof(struct acpi_table_madt) =
+=0A-	                      nbr_cpus * sizeof(struct acpi_table_lsapic);=
=0A+	                      nbr_cpus * sizeof(*lsapic);=0A 	madt->heade=
r.checksum =3D -acpi_tb_checksum((u8*)madt,=0A 					=
	  madt->header.length);=0A 	return;=0A--- a/xen/arch/ia64/xen/d=
om_fw_dom0.c=0A+++ b/xen/arch/ia64/xen/dom_fw_dom0.c=0A@@ -53,11 +53,11 @@ =
static u32 lsapic_nbr;=0A static int __init=0A acpi_update_lsapic(struct =
acpi_subtable_header * header, const unsigned long end)=0A {=0A-	=
struct acpi_table_lsapic *lsapic;=0A+	struct acpi_madt_local_sapic =
*lsapic =3D=0A+		container_of(header, struct acpi_madt_local_sapic, =
header);=0A 	int enable;=0A =0A-	lsapic =3D (struct acpi_table_lsapi=
c *)header;=0A-	if (!lsapic)=0A+	if (!header)=0A 		=
return -EINVAL;=0A =0A 	if (lsapic_nbr < dom0->max_vcpus && dom0->vcpu[lsap=
ic_nbr] !=3D NULL)=0A@@ -65,14 +65,14 @@ acpi_update_lsapic(struct =
acpi_subtable_=0A 	else=0A 		enable =3D 0;=0A =0A-	if =
(lsapic->flags.enabled && enable) {=0A+	if ((lsapic->lapic_flags & =
ACPI_MADT_ENABLED) && enable) {=0A 		printk("enable lsapic =
entry: 0x%lx\n", (u64) lsapic);=0A 		lsapic->id =3D lsapic_nbr;=
=0A 		lsapic->eid =3D 0;=0A 		lsapic_nbr++;=0A-	} =
else if (lsapic->flags.enabled) {=0A+	} else if (lsapic->lapic_flags & =
ACPI_MADT_ENABLED) {=0A 		printk("DISABLE lsapic entry: =
0x%lx\n", (u64) lsapic);=0A-		lsapic->flags.enabled =3D 0;=0A+	=
	lsapic->lapic_flags &=3D ~ACPI_MADT_ENABLED;=0A 		=
lsapic->id =3D 0;=0A 		lsapic->eid =3D 0;=0A 	}=0A@@ -83,10 =
+83,11 @@ static int __init=0A acpi_patch_plat_int_src(struct acpi_subtable=
_header * header,=0A 			const unsigned long end)=0A {=0A-	=
struct acpi_table_plat_int_src *plintsrc;=0A+	struct acpi_madt_interrupt_=
source *plintsrc =3D=0A+		container_of(header, struct =
acpi_madt_interrupt_source,=0A+			     header);=0A =0A-	=
plintsrc =3D (struct acpi_table_plat_int_src *)header;=0A-	if =
(!plintsrc)=0A+	if (!header)=0A 		return -EINVAL;=0A =0A 	if =
(plintsrc->type =3D=3D ACPI_INTERRUPT_CPEI) {=0A@@ -193,12 +194,13 @@ =
static void __init touch_acpi_table(void=0A 	 */=0A 	acpi_table_parse(AC=
PI_SIG_MADT, acpi_backup_table);=0A =0A-	if (acpi_table_parse_madt(A=
CPI_MADT_LSAPIC, acpi_update_lsapic, 0) < 0)=0A+	if (acpi_table_pars=
e_madt(ACPI_MADT_TYPE_LOCAL_SAPIC,=0A+				  =
acpi_update_lsapic, 0) < 0)=0A 		printk("Error parsing MADT - no =
LAPIC entries\n");=0A =0A 	acpi_update_madt_checksum(madt);=0A =0A-	=
if (acpi_table_parse_madt(ACPI_MADT_PLAT_INT_SRC,=0A+	if (acpi_table_pars=
e_madt(ACPI_MADT_TYPE_INTERRUPT_SOURCE,=0A 				  =
acpi_patch_plat_int_src, 0) < 0)=0A 		printk("Error parsing MADT =
- no PLAT_INT_SRC entries\n");=0A =0A--- a/xen/arch/x86/acpi/boot.c=0A+++ =
b/xen/arch/x86/acpi/boot.c=0A@@ -87,9 +87,9 @@ static int __init acpi_parse=
_madt(struct=0A static int __init=0A acpi_parse_x2apic(struct acpi_subtable=
_header *header, const unsigned long end)=0A {=0A-	struct acpi_table_x=
2apic *processor =3D NULL;=0A-=0A-	processor =3D (struct acpi_table_x2=
apic *)header;=0A+	struct acpi_madt_local_x2apic *processor =3D=0A+	=
	container_of(header, struct acpi_madt_local_x2apic, header);=0A+	=
bool_t enabled =3D 0;=0A =0A 	if (BAD_MADT_ENTRY(processor, end))=0A 		=
return -EINVAL;=0A@@ -97,8 +97,11 @@ acpi_parse_x2apic(struct acpi_subtable=
_h=0A 	acpi_table_print_madt_entry(header);=0A =0A 	/* Record local =
apic id only when enabled */=0A-	if (processor->flags.enabled)=0A-	=
	x86_acpiid_to_apicid[processor->acpi_uid] =3D processor->id;=0A+	=
if (processor->lapic_flags & ACPI_MADT_ENABLED) {=0A+		x86_acpiid_=
to_apicid[processor->uid] =3D=0A+			processor->local_ap=
ic_id;=0A+		enabled =3D 1;=0A+	}=0A =0A 	/*=0A 	 * =
We need to register disabled CPU as well to permit=0A@@ -107,9 +110,7 @@ =
acpi_parse_x2apic(struct acpi_subtable_h=0A 	 * to not preallocating =
memory for all NR_CPUS=0A 	 * when we use CPU hotplug.=0A 	 */=0A-	=
mp_register_lapic(processor->id,	/* X2APIC ID */=0A-			=
  processor->flags.enabled,	/* Enabled? */=0A-			  =
0);=0A+	mp_register_lapic(processor->local_apic_id, enabled, 0);=0A =0A 	=
return 0;=0A }=0A@@ -117,9 +118,9 @@ acpi_parse_x2apic(struct acpi_subtable=
_h=0A static int __init=0A acpi_parse_lapic(struct acpi_subtable_header * =
header, const unsigned long end)=0A {=0A-	struct acpi_table_lapic =
*processor =3D NULL;=0A-=0A-	processor =3D (struct acpi_table_lapic =
*)header;=0A+	struct acpi_madt_local_apic *processor =3D=0A+		=
container_of(header, struct acpi_madt_local_apic, header);=0A+	bool_t =
enabled =3D 0;=0A =0A 	if (BAD_MADT_ENTRY(processor, end))=0A 		=
return -EINVAL;=0A@@ -127,8 +128,10 @@ acpi_parse_lapic(struct acpi_subtabl=
e_he=0A 	acpi_table_print_madt_entry(header);=0A =0A 	/* Record =
local apic id only when enabled */=0A-	if (processor->flags.enabled)=0A-	=
	x86_acpiid_to_apicid[processor->acpi_id] =3D processor->id;=0A+	if =
(processor->lapic_flags & ACPI_MADT_ENABLED) {=0A+		x86_acpiid_=
to_apicid[processor->processor_id] =3D processor->id;=0A+		=
enabled =3D 1;=0A+	}=0A =0A 	/*=0A 	 * We need to register =
disabled CPU as well to permit=0A@@ -137,9 +140,7 @@ acpi_parse_lapic(struc=
t acpi_subtable_he=0A 	 * to not preallocating memory for all NR_CPUS=0A 	=
 * when we use CPU hotplug.=0A 	 */=0A-	mp_register_lapic(processor->id,	=
/* APIC ID */=0A-			  processor->flags.enabled,	/* =
Enabled? */=0A-			  0);=0A+	mp_register_lapic(processor=
->id, enabled, 0);=0A =0A 	return 0;=0A }=0A@@ -148,9 +149,9 @@ =
static int __init=0A acpi_parse_lapic_addr_ovr(struct acpi_subtable_header =
* header,=0A 			  const unsigned long end)=0A {=0A-	=
struct acpi_table_lapic_addr_ovr *lapic_addr_ovr =3D NULL;=0A-=0A-	=
lapic_addr_ovr =3D (struct acpi_table_lapic_addr_ovr *)header;=0A+	=
struct acpi_madt_local_apic_override *lapic_addr_ovr =3D=0A+		=
container_of(header, struct acpi_madt_local_apic_override,=0A+			=
     header);=0A =0A 	if (BAD_MADT_ENTRY(lapic_addr_ovr, end))=0A 		=
return -EINVAL;=0A@@ -164,9 +165,9 @@ static int __init=0A acpi_parse_x2api=
c_nmi(struct acpi_subtable_header *header,=0A 		      const =
unsigned long end)=0A {=0A-	struct acpi_table_x2apic_nmi *x2apic_nmi =
=3D NULL;=0A-=0A-	x2apic_nmi =3D (struct acpi_table_x2apic_nmi =
*)header;=0A+	struct acpi_madt_local_x2apic_nmi *x2apic_nmi =3D=0A+		=
container_of(header, struct acpi_madt_local_x2apic_nmi,=0A+			=
     header);=0A =0A 	if (BAD_MADT_ENTRY(x2apic_nmi, end))=0A 		=
return -EINVAL;=0A@@ -182,9 +183,8 @@ acpi_parse_x2apic_nmi(struct =
acpi_subtab=0A static int __init=0A acpi_parse_lapic_nmi(struct acpi_subtab=
le_header * header, const unsigned long end)=0A {=0A-	struct acpi_table_l=
apic_nmi *lapic_nmi =3D NULL;=0A-=0A-	lapic_nmi =3D (struct acpi_table_la=
pic_nmi *)header;=0A+	struct acpi_madt_local_apic_nmi *lapic_nmi =3D=0A+	=
	container_of(header, struct acpi_madt_local_apic_nmi, header);=0A =
=0A 	if (BAD_MADT_ENTRY(lapic_nmi, end))=0A 		return -EINVAL;=0A@=
@ -204,9 +204,8 @@ acpi_parse_lapic_nmi(struct acpi_subtabl=0A static int =
__init=0A acpi_parse_ioapic(struct acpi_subtable_header * header, const =
unsigned long end)=0A {=0A-	struct acpi_table_ioapic *ioapic =3D =
NULL;=0A-=0A-	ioapic =3D (struct acpi_table_ioapic *)header;=0A+	=
struct acpi_madt_io_apic *ioapic =3D=0A+		container_of(header=
, struct acpi_madt_io_apic, header);=0A =0A 	if (BAD_MADT_ENTRY(ioapic, =
end))=0A 		return -EINVAL;=0A@@ -223,9 +222,9 @@ static int =
__init=0A acpi_parse_int_src_ovr(struct acpi_subtable_header * header,=0A 	=
	       const unsigned long end)=0A {=0A-	struct acpi_table_i=
nt_src_ovr *intsrc =3D NULL;=0A-=0A-	intsrc =3D (struct acpi_table_int_s=
rc_ovr *)header;=0A+	struct acpi_madt_interrupt_override *intsrc =
=3D=0A+		container_of(header, struct acpi_madt_interrupt_override,=
=0A+			     header);=0A =0A 	if (BAD_MADT_ENTRY(intsrc, =
end))=0A 		return -EINVAL;=0A@@ -233,14 +232,15 @@ acpi_parse_=
int_src_ovr(struct acpi_subta=0A 	acpi_table_print_madt_entry(header)=
;=0A =0A 	if (acpi_skip_timer_override &&=0A-		intsrc->bus=
_irq =3D=3D 0 && intsrc->global_irq =3D=3D 2) {=0A+	    intsrc->source_=
irq =3D=3D 0 && intsrc->global_irq =3D=3D 2) {=0A 			=
printk(PREFIX "BIOS IRQ0 pin2 override ignored.\n");=0A 			=
return 0;=0A 	}=0A =0A-	mp_override_legacy_irq(intsrc->bus_irq,=0A-=
			       intsrc->flags.polarity,=0A-			=
       intsrc->flags.trigger, intsrc->global_irq);=0A+	mp_override_legacy_=
irq(intsrc->source_irq,=0A+			       ACPI_MADT_GET_POLARI=
TY(intsrc->inti_flags),=0A+			       ACPI_MADT_GET_TRIGGE=
R(intsrc->inti_flags),=0A+			       intsrc->global_irq);=
=0A =0A 	return 0;=0A }=0A@@ -248,9 +248,8 @@ acpi_parse_int_src_ovr=
(struct acpi_subta=0A static int __init=0A acpi_parse_nmi_src(struct =
acpi_subtable_header * header, const unsigned long end)=0A {=0A-	=
struct acpi_table_nmi_src *nmi_src =3D NULL;=0A-=0A-	nmi_src =3D =
(struct acpi_table_nmi_src *)header;=0A+	struct acpi_madt_nmi_source=
 *nmi_src =3D=0A+		container_of(header, struct acpi_madt_nmi_s=
ource, header);=0A =0A 	if (BAD_MADT_ENTRY(nmi_src, end))=0A 		=
return -EINVAL;=0A@@ -270,7 +269,7 @@ static int __init acpi_parse_hpet(str=
uct=0A {=0A 	struct acpi_table_hpet *hpet_tbl =3D (struct acpi_table_hpe=
t *)table;=0A =0A-	if (hpet_tbl->address.space_id !=3D ACPI_SPACE_MEM)=
 {=0A+	if (hpet_tbl->address.space_id !=3D ACPI_ADR_SPACE_SYSTEM_MEMORY) =
{=0A 		printk(KERN_WARNING PREFIX "HPET timers must be located in =
"=0A 		       "memory.\n");=0A 		return -1;=0A--- =
a/xen/arch/x86/srat.c=0A+++ b/xen/arch/x86/srat.c=0A@@ -396,7 +396,8 @@ =
void __init srat_parse_regions(u64 addr)=0A 		return;=0A =0A 	=
srat_region_mask =3D fill_mask(addr - 1);=0A-	acpi_table_parse_srat(ACPI_=
SRAT_MEMORY_AFFINITY, srat_parse_region, 0);=0A+	acpi_table_parse_sr=
at(ACPI_SRAT_TYPE_MEMORY_AFFINITY,=0A+			      srat_parse_re=
gion, 0);=0A =0A 	for (mask =3D srat_region_mask, i =3D 0; mask && i =
< e820.nr_map; i++) {=0A 		if (e820.map[i].type !=3D =
E820_RAM)=0A--- a/xen/drivers/acpi/numa.c=0A+++ b/xen/drivers/acpi/numa.c=
=0A@@ -46,7 +46,7 @@ void __init acpi_table_print_srat_entry(=0A =0A 	=
switch (header->type) {=0A =0A-	case ACPI_SRAT_PROCESSOR_AFFINITY:=0A+	=
case ACPI_SRAT_TYPE_CPU_AFFINITY:=0A #ifdef ACPI_DEBUG_OUTPUT=0A 		=
{=0A 			struct acpi_srat_cpu_affinity *p =3D=0A@@ -68,7 =
+68,7 @@ void __init acpi_table_print_srat_entry(=0A #endif			=
	/* ACPI_DEBUG_OUTPUT */=0A 		break;=0A =0A-	case =
ACPI_SRAT_MEMORY_AFFINITY:=0A+	case ACPI_SRAT_TYPE_MEMORY_AFFINITY:=0A =
#ifdef ACPI_DEBUG_OUTPUT=0A 		{=0A 			struct =
acpi_srat_mem_affinity *p =3D=0A@@ -194,8 +194,8 @@ int __init acpi_parse_s=
rat(struct acpi_t=0A }=0A =0A int __init=0A-acpi_table_parse_srat(enum =
acpi_srat_entry_id id,=0A-		      acpi_madt_entry_handler =
handler, unsigned int max_entries)=0A+acpi_table_parse_srat(int id, =
acpi_madt_entry_handler handler,=0A+		      unsigned int =
max_entries)=0A {=0A 	return acpi_table_parse_entries(ACPI_SIG_SRAT,=0A 	=
				sizeof(struct acpi_table_srat), id,=0A@@ =
-206,12 +206,13 @@ int __init acpi_numa_init(void)=0A {=0A 	/* SRAT: =
Static Resource Affinity Table */=0A 	if (!acpi_table_parse(ACPI_SIG_SRAT=
, acpi_parse_srat)) {=0A-		acpi_table_parse_srat(ACPI_SRAT_X2A=
PIC_AFFINITY,=0A-				           acpi_parse_x2api=
c_affinity, NR_CPUS);=0A-		acpi_table_parse_srat(ACPI_SRAT_PRO=
CESSOR_AFFINITY,=0A-					       acpi_parse_p=
rocessor_affinity,=0A-					       NR_CPUS);=0A=
-		acpi_table_parse_srat(ACPI_SRAT_MEMORY_AFFINITY, acpi_parse=
_memory_affinity, NR_NODE_MEMBLKS);	// IA64 specific=0A+		=
acpi_table_parse_srat(ACPI_SRAT_TYPE_X2APIC_CPU_AFFINITY,=0A+			=
	      acpi_parse_x2apic_affinity, NR_CPUS);=0A+		acpi_table_=
parse_srat(ACPI_SRAT_TYPE_CPU_AFFINITY,=0A+				   =
   acpi_parse_processor_affinity, NR_CPUS);=0A+		acpi_table_parse_sr=
at(ACPI_SRAT_TYPE_MEMORY_AFFINITY,=0A+				      =
acpi_parse_memory_affinity,=0A+				      NR_NODE_MEMBL=
KS);=0A 	}=0A =0A 	/* SLIT: System Locality Information Table =
*/=0A--- a/xen/include/xen/acpi.h=0A+++ b/xen/include/xen/acpi.h=0A@@ =
-34,123 +34,13 @@=0A #include <acpi/acpi.h>=0A #include <asm/acpi.h>=0A =
=0A-#ifdef CONFIG_ACPI_BOOT=0A-=0A-enum acpi_madt_entry_id {=0A-	=
ACPI_MADT_LAPIC =3D 0,=0A-	ACPI_MADT_IOAPIC,=0A-	ACPI_MADT_INT_SRC_O=
VR,=0A-	ACPI_MADT_NMI_SRC,=0A-	ACPI_MADT_LAPIC_NMI,=0A-	ACPI_MADT_L=
APIC_ADDR_OVR,=0A-	ACPI_MADT_IOSAPIC,=0A-	ACPI_MADT_LSAPIC,=0A-	=
ACPI_MADT_PLAT_INT_SRC,=0A-	ACPI_MADT_X2APIC,=0A-	ACPI_MADT_X2APIC_NM=
I,=0A-	ACPI_MADT_ENTRY_COUNT=0A-};=0A-=0A-typedef struct {=0A-	u16		=
	polarity:2;=0A-	u16			trigger:2;=0A-	u16		=
	reserved:12;=0A-} __attribute__ ((packed)) acpi_interrupt_flags;=0A=
-=0A-struct acpi_table_lapic {=0A-	struct acpi_subtable_header	=
header;=0A-	u8			acpi_id;=0A-	u8			=
id;=0A-	struct {=0A-		u32			enabled:1;=0A-		=
u32			reserved:31;=0A-	}			=
flags;=0A-} __attribute__ ((packed));=0A-=0A-struct acpi_table_x2apic =
{=0A-	struct acpi_subtable_header header;=0A-	u16			=
reserved;=0A-	u32			id;=0A-	struct {=0A-		=
u32			enabled:1;=0A-		u32			=
reserved:31;=0A-	}			flags;=0A-	u32        =
 acpi_uid;=0A-} __attribute__ ((packed));=0A-=0A-struct acpi_table_ioapic =
{=0A-	struct acpi_subtable_header	header;=0A-	u8			=
id;=0A-	u8			reserved;=0A-	u32			=
address;=0A-	u32			global_irq_base;=0A-} __attribute__=
 ((packed));=0A-=0A-struct acpi_table_int_src_ovr {=0A-	struct acpi_subtabl=
e_header	header;=0A-	u8			bus;=0A-	u8	=
		bus_irq;=0A-	u32			global_irq;=0A-	=
acpi_interrupt_flags	flags;=0A-} __attribute__ ((packed));=0A-=0A-struct=
 acpi_table_nmi_src {=0A-	struct acpi_subtable_header	header;=0A-=
	acpi_interrupt_flags	flags;=0A-	u32			=
global_irq;=0A-} __attribute__ ((packed));=0A-=0A-struct acpi_table_lapic_n=
mi {=0A-	struct acpi_subtable_header	header;=0A-	u8		=
	acpi_id;=0A-	acpi_interrupt_flags	flags;=0A-	u8		=
	lint;=0A-} __attribute__ ((packed));=0A-=0A-struct acpi_table_x2api=
c_nmi {=0A-	struct acpi_subtable_header header;=0A-	acpi_interrupt_flag=
s	flags;=0A-	u32			acpi_uid;=0A-	u8		=
	lint;=0A-	u8			reserved[3];=0A-} =
__attribute__ ((packed));=0A+#define ACPI_MADT_GET_(fld, x) (((x) & =
ACPI_MADT_##fld##_MASK) / \=0A+	(ACPI_MADT_##fld##_MASK & -ACPI_MADT_##fld#=
#_MASK))=0A =0A-struct acpi_table_lapic_addr_ovr {=0A-	struct acpi_subtabl=
e_header	header;=0A-	u8			reserved[2];=0A-	=
u64			address;=0A-} __attribute__ ((packed));=0A-=0A-stru=
ct acpi_table_iosapic {=0A-	struct acpi_subtable_header	header;=0A-=
	u8			id;=0A-	u8			=
reserved;=0A-	u32			global_irq_base;=0A-	u64		=
	address;=0A-} __attribute__ ((packed));=0A-=0A-struct acpi_table_ls=
apic {=0A-	struct acpi_subtable_header	header;=0A-	u8		=
	acpi_id;=0A-	u8			id;=0A-	u8			=
eid;=0A-	u8			reserved[3];=0A-	struct =
{=0A-		u32			enabled:1;=0A-		u32		=
	reserved:31;=0A-	}			flags;=0A-} =
__attribute__ ((packed));=0A+#define ACPI_MADT_GET_POLARITY(inti)	=
ACPI_MADT_GET_(POLARITY, inti)=0A+#define ACPI_MADT_GET_TRIGGER(inti)	=
ACPI_MADT_GET_(TRIGGER, inti)=0A =0A-struct acpi_table_plat_int_src {=0A-	=
struct acpi_subtable_header	header;=0A-	acpi_interrupt_flags	=
flags;=0A-	u8			type;	/* See acpi_interrupt_type =
*/=0A-	u8			id;=0A-	u8			eid;=0A-	=
u8			iosapic_vector;=0A-	u32			=
global_irq;=0A-	u32			reserved;=0A-} __attribute__ =
((packed));=0A+#ifdef CONFIG_ACPI_BOOT=0A =0A enum acpi_interrupt_id {=0A 	=
ACPI_INTERRUPT_PMI	=3D 1,=0A@@ -159,42 +49,6 @@ enum acpi_interrupt_id=
 {=0A 	ACPI_INTERRUPT_COUNT=0A };=0A =0A-#define	ACPI_SPACE_MEM		=
0=0A-=0A-/*=0A- * Simple Boot Flags=0A- * http://www.microsoft.com/whdc/hwd=
ev/resources/specs/simp_bios.mspx=0A- */=0A-struct acpi_table_sbf=0A-{=0A-	=
u8 sbf_signature[4];=0A-	u32 sbf_len;=0A-	u8 sbf_revision;=0A=
-	u8 sbf_csum;=0A-	u8 sbf_oemid[6];=0A-	u8 sbf_oemtable[8];=
=0A-	u8 sbf_revdata[4];=0A-	u8 sbf_creator[4];=0A-	u8 sbf_crearev[4];=
=0A-	u8 sbf_cmos;=0A-	u8 sbf_spare[3];=0A-} __attribute__ =
((packed));=0A-=0A-enum acpi_srat_entry_id {=0A-	ACPI_SRAT_PROCESSOR=
_AFFINITY =3D 0,=0A-	ACPI_SRAT_MEMORY_AFFINITY,=0A-	ACPI_SRAT_X2APIC_AF=
FINITY,=0A-	ACPI_SRAT_ENTRY_COUNT=0A-};=0A-=0A-enum acpi_address_range_=
id {=0A-	ACPI_ADDRESS_RANGE_MEMORY =3D 1,=0A-	ACPI_ADDRESS_RANGE_=
RESERVED =3D 2,=0A-	ACPI_ADDRESS_RANGE_ACPI =3D 3,=0A-	ACPI_ADDRES=
S_RANGE_NVS	=3D 4,=0A-	ACPI_ADDRESS_RANGE_COUNT=0A-};=0A-=0A /* =
DMA Remapping Reporting Table (DMAR) */=0A =0A #define DMAR_FLAGS_INTR_REMA=
P 0x1       /* intr remap supported */=0A@@ -282,8 +136,8 @@ int acpi_table=
_parse(char *id, acpi_tabl=0A int acpi_table_parse_entries(char *id, =
unsigned long table_size,=0A 	int entry_id, acpi_table_entry_handler =
handler, unsigned int max_entries);=0A int acpi_table_parse_madt(enum =
acpi_madt_type id, acpi_table_entry_handler handler, unsigned int =
max_entries);=0A-int acpi_table_parse_srat(enum acpi_srat_entry_id id,=0A-	=
acpi_madt_entry_handler handler, unsigned int max_entries);=0A+int =
acpi_table_parse_srat(int id, acpi_madt_entry_handler handler,=0A+	=
unsigned int max_entries);=0A int acpi_parse_srat(struct acpi_table_header =
*);=0A void acpi_table_print (struct acpi_table_header *header, unsigned =
long phys_addr);=0A void acpi_table_print_madt_entry (struct acpi_subtable_=
header *madt);=0A
--=__PartB6991351.0__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--=__PartB6991351.0__=--


From xen-devel-bounces@lists.xensource.com Mon Dec 12 16:09:55 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 16: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.xensource.com>)
	id 1Ra8Rj-0003Lr-3e; Mon, 12 Dec 2011 16:09:43 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Ra8Rg-0003LL-UO
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 16:09:41 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1323706126!7073766!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23752 invoked from network); 12 Dec 2011 16:08:46 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-14.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 12 Dec 2011 16:08:46 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 12 Dec 2011 16:08:45 +0000
Message-Id: <4EE63551020000780006705C@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 12 Dec 2011 16:09:37 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartB6991351.0__="
Subject: [Xen-devel] [PATCH 1/4] ACPI: eliminate duplicate MADT parsing and
 unused SBF definitions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__PartB6991351.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Use their proper counterparts in include/acpi/actbl*.h instead.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/ia64/xen/dom_fw_common.c
+++ b/xen/arch/ia64/xen/dom_fw_common.c
@@ -347,7 +347,7 @@ struct fake_acpi_tables {
 	struct acpi_table_header dsdt;
 	uint8_t aml[8 + 11 * MAX_VIRT_CPUS];
 	struct acpi_table_madt madt;
-	struct acpi_table_lsapic lsapic[MAX_VIRT_CPUS];
+	struct acpi_madt_local_sapic lsapic[MAX_VIRT_CPUS];
 	uint8_t pm1a_event_block[4];
 	uint8_t pm1a_control_block[1];
 	uint8_t pm_timer_block[4];
@@ -365,7 +365,7 @@ dom_fw_fake_acpi(domain_t *d, struct fak
 	struct acpi_table_facs *facs =3D &tables->facs;
 	struct acpi_table_header *dsdt =3D &tables->dsdt;
 	struct acpi_table_madt *madt =3D &tables->madt;
-	struct acpi_table_lsapic *lsapic =3D tables->lsapic;
+	struct acpi_madt_local_sapic *lsapic =3D tables->lsapic;
 	int i;
 	int aml_len;
 	int nbr_cpus;
@@ -492,18 +492,18 @@ dom_fw_fake_acpi(domain_t *d, struct fak
 	/* An LSAPIC entry describes a CPU.  */
 	nbr_cpus =3D 0;
 	for (i =3D 0; i < MAX_VIRT_CPUS; i++) {
-		lsapic[i].header.type =3D ACPI_MADT_LSAPIC;
-		lsapic[i].header.length =3D sizeof(struct acpi_table_lsapic=
);
-		lsapic[i].acpi_id =3D i;
+		lsapic[i].header.type =3D ACPI_MADT_TYPE_LOCAL_SAPIC;
+		lsapic[i].header.length =3D sizeof(lsapic[i]);
+		lsapic[i].processor_id =3D i;
 		lsapic[i].id =3D i;
 		lsapic[i].eid =3D 0;
 		if (xen_ia64_is_vcpu_allocated(d, i)) {
-			lsapic[i].flags.enabled =3D 1;
+			lsapic[i].lapic_flags =3D ACPI_MADT_ENABLED;
 			nbr_cpus++;
 		}
 	}
 	madt->header.length =3D sizeof(struct acpi_table_madt) +
-	                      nbr_cpus * sizeof(struct acpi_table_lsapic);
+	                      nbr_cpus * sizeof(*lsapic);
 	madt->header.checksum =3D -acpi_tb_checksum((u8*)madt,
 						  madt->header.length);
 	return;
--- a/xen/arch/ia64/xen/dom_fw_dom0.c
+++ b/xen/arch/ia64/xen/dom_fw_dom0.c
@@ -53,11 +53,11 @@ static u32 lsapic_nbr;
 static int __init
 acpi_update_lsapic(struct acpi_subtable_header * header, const unsigned =
long end)
 {
-	struct acpi_table_lsapic *lsapic;
+	struct acpi_madt_local_sapic *lsapic =3D
+		container_of(header, struct acpi_madt_local_sapic, =
header);
 	int enable;
=20
-	lsapic =3D (struct acpi_table_lsapic *)header;
-	if (!lsapic)
+	if (!header)
 		return -EINVAL;
=20
 	if (lsapic_nbr < dom0->max_vcpus && dom0->vcpu[lsapic_nbr] !=3D =
NULL)
@@ -65,14 +65,14 @@ acpi_update_lsapic(struct acpi_subtable_
 	else
 		enable =3D 0;
=20
-	if (lsapic->flags.enabled && enable) {
+	if ((lsapic->lapic_flags & ACPI_MADT_ENABLED) && enable) {
 		printk("enable lsapic entry: 0x%lx\n", (u64) lsapic);
 		lsapic->id =3D lsapic_nbr;
 		lsapic->eid =3D 0;
 		lsapic_nbr++;
-	} else if (lsapic->flags.enabled) {
+	} else if (lsapic->lapic_flags & ACPI_MADT_ENABLED) {
 		printk("DISABLE lsapic entry: 0x%lx\n", (u64) lsapic);
-		lsapic->flags.enabled =3D 0;
+		lsapic->lapic_flags &=3D ~ACPI_MADT_ENABLED;
 		lsapic->id =3D 0;
 		lsapic->eid =3D 0;
 	}
@@ -83,10 +83,11 @@ static int __init
 acpi_patch_plat_int_src(struct acpi_subtable_header * header,
 			const unsigned long end)
 {
-	struct acpi_table_plat_int_src *plintsrc;
+	struct acpi_madt_interrupt_source *plintsrc =3D
+		container_of(header, struct acpi_madt_interrupt_source,
+			     header);
=20
-	plintsrc =3D (struct acpi_table_plat_int_src *)header;
-	if (!plintsrc)
+	if (!header)
 		return -EINVAL;
=20
 	if (plintsrc->type =3D=3D ACPI_INTERRUPT_CPEI) {
@@ -193,12 +194,13 @@ static void __init touch_acpi_table(void
 	 */
 	acpi_table_parse(ACPI_SIG_MADT, acpi_backup_table);
=20
-	if (acpi_table_parse_madt(ACPI_MADT_LSAPIC, acpi_update_lsapic, 0) =
< 0)
+	if (acpi_table_parse_madt(ACPI_MADT_TYPE_LOCAL_SAPIC,
+				  acpi_update_lsapic, 0) < 0)
 		printk("Error parsing MADT - no LAPIC entries\n");
=20
 	acpi_update_madt_checksum(madt);
=20
-	if (acpi_table_parse_madt(ACPI_MADT_PLAT_INT_SRC,
+	if (acpi_table_parse_madt(ACPI_MADT_TYPE_INTERRUPT_SOURCE,
 				  acpi_patch_plat_int_src, 0) < 0)
 		printk("Error parsing MADT - no PLAT_INT_SRC entries\n");
=20
--- a/xen/arch/x86/acpi/boot.c
+++ b/xen/arch/x86/acpi/boot.c
@@ -87,9 +87,9 @@ static int __init acpi_parse_madt(struct
 static int __init
 acpi_parse_x2apic(struct acpi_subtable_header *header, const unsigned =
long end)
 {
-	struct acpi_table_x2apic *processor =3D NULL;
-
-	processor =3D (struct acpi_table_x2apic *)header;
+	struct acpi_madt_local_x2apic *processor =3D
+		container_of(header, struct acpi_madt_local_x2apic, =
header);
+	bool_t enabled =3D 0;
=20
 	if (BAD_MADT_ENTRY(processor, end))
 		return -EINVAL;
@@ -97,8 +97,11 @@ acpi_parse_x2apic(struct acpi_subtable_h
 	acpi_table_print_madt_entry(header);
=20
 	/* Record local apic id only when enabled */
-	if (processor->flags.enabled)
-		x86_acpiid_to_apicid[processor->acpi_uid] =3D processor->id=
;
+	if (processor->lapic_flags & ACPI_MADT_ENABLED) {
+		x86_acpiid_to_apicid[processor->uid] =3D
+			processor->local_apic_id;
+		enabled =3D 1;
+	}
=20
 	/*
 	 * We need to register disabled CPU as well to permit
@@ -107,9 +110,7 @@ acpi_parse_x2apic(struct acpi_subtable_h
 	 * to not preallocating memory for all NR_CPUS
 	 * when we use CPU hotplug.
 	 */
-	mp_register_lapic(processor->id,	/* X2APIC ID */
-			  processor->flags.enabled,	/* Enabled? */
-			  0);
+	mp_register_lapic(processor->local_apic_id, enabled, 0);
=20
 	return 0;
 }
@@ -117,9 +118,9 @@ acpi_parse_x2apic(struct acpi_subtable_h
 static int __init
 acpi_parse_lapic(struct acpi_subtable_header * header, const unsigned =
long end)
 {
-	struct acpi_table_lapic *processor =3D NULL;
-
-	processor =3D (struct acpi_table_lapic *)header;
+	struct acpi_madt_local_apic *processor =3D
+		container_of(header, struct acpi_madt_local_apic, header);
+	bool_t enabled =3D 0;
=20
 	if (BAD_MADT_ENTRY(processor, end))
 		return -EINVAL;
@@ -127,8 +128,10 @@ acpi_parse_lapic(struct acpi_subtable_he
 	acpi_table_print_madt_entry(header);
=20
 	/* Record local apic id only when enabled */
-	if (processor->flags.enabled)
-		x86_acpiid_to_apicid[processor->acpi_id] =3D processor->id;=

+	if (processor->lapic_flags & ACPI_MADT_ENABLED) {
+		x86_acpiid_to_apicid[processor->processor_id] =3D =
processor->id;
+		enabled =3D 1;
+	}
=20
 	/*
 	 * We need to register disabled CPU as well to permit
@@ -137,9 +140,7 @@ acpi_parse_lapic(struct acpi_subtable_he
 	 * to not preallocating memory for all NR_CPUS
 	 * when we use CPU hotplug.
 	 */
-	mp_register_lapic(processor->id,	/* APIC ID */
-			  processor->flags.enabled,	/* Enabled? */
-			  0);
+	mp_register_lapic(processor->id, enabled, 0);
=20
 	return 0;
 }
@@ -148,9 +149,9 @@ static int __init
 acpi_parse_lapic_addr_ovr(struct acpi_subtable_header * header,
 			  const unsigned long end)
 {
-	struct acpi_table_lapic_addr_ovr *lapic_addr_ovr =3D NULL;
-
-	lapic_addr_ovr =3D (struct acpi_table_lapic_addr_ovr *)header;
+	struct acpi_madt_local_apic_override *lapic_addr_ovr =3D
+		container_of(header, struct acpi_madt_local_apic_override,
+			     header);
=20
 	if (BAD_MADT_ENTRY(lapic_addr_ovr, end))
 		return -EINVAL;
@@ -164,9 +165,9 @@ static int __init
 acpi_parse_x2apic_nmi(struct acpi_subtable_header *header,
 		      const unsigned long end)
 {
-	struct acpi_table_x2apic_nmi *x2apic_nmi =3D NULL;
-
-	x2apic_nmi =3D (struct acpi_table_x2apic_nmi *)header;
+	struct acpi_madt_local_x2apic_nmi *x2apic_nmi =3D
+		container_of(header, struct acpi_madt_local_x2apic_nmi,
+			     header);
=20
 	if (BAD_MADT_ENTRY(x2apic_nmi, end))
 		return -EINVAL;
@@ -182,9 +183,8 @@ acpi_parse_x2apic_nmi(struct acpi_subtab
 static int __init
 acpi_parse_lapic_nmi(struct acpi_subtable_header * header, const unsigned =
long end)
 {
-	struct acpi_table_lapic_nmi *lapic_nmi =3D NULL;
-
-	lapic_nmi =3D (struct acpi_table_lapic_nmi *)header;
+	struct acpi_madt_local_apic_nmi *lapic_nmi =3D
+		container_of(header, struct acpi_madt_local_apic_nmi, =
header);
=20
 	if (BAD_MADT_ENTRY(lapic_nmi, end))
 		return -EINVAL;
@@ -204,9 +204,8 @@ acpi_parse_lapic_nmi(struct acpi_subtabl
 static int __init
 acpi_parse_ioapic(struct acpi_subtable_header * header, const unsigned =
long end)
 {
-	struct acpi_table_ioapic *ioapic =3D NULL;
-
-	ioapic =3D (struct acpi_table_ioapic *)header;
+	struct acpi_madt_io_apic *ioapic =3D
+		container_of(header, struct acpi_madt_io_apic, header);
=20
 	if (BAD_MADT_ENTRY(ioapic, end))
 		return -EINVAL;
@@ -223,9 +222,9 @@ static int __init
 acpi_parse_int_src_ovr(struct acpi_subtable_header * header,
 		       const unsigned long end)
 {
-	struct acpi_table_int_src_ovr *intsrc =3D NULL;
-
-	intsrc =3D (struct acpi_table_int_src_ovr *)header;
+	struct acpi_madt_interrupt_override *intsrc =3D
+		container_of(header, struct acpi_madt_interrupt_override,
+			     header);
=20
 	if (BAD_MADT_ENTRY(intsrc, end))
 		return -EINVAL;
@@ -233,14 +232,15 @@ acpi_parse_int_src_ovr(struct acpi_subta
 	acpi_table_print_madt_entry(header);
=20
 	if (acpi_skip_timer_override &&
-		intsrc->bus_irq =3D=3D 0 && intsrc->global_irq =3D=3D 2) {
+	    intsrc->source_irq =3D=3D 0 && intsrc->global_irq =3D=3D 2) {
 			printk(PREFIX "BIOS IRQ0 pin2 override ignored.\n")=
;
 			return 0;
 	}
=20
-	mp_override_legacy_irq(intsrc->bus_irq,
-			       intsrc->flags.polarity,
-			       intsrc->flags.trigger, intsrc->global_irq);
+	mp_override_legacy_irq(intsrc->source_irq,
+			       ACPI_MADT_GET_POLARITY(intsrc->inti_flags),
+			       ACPI_MADT_GET_TRIGGER(intsrc->inti_flags),
+			       intsrc->global_irq);
=20
 	return 0;
 }
@@ -248,9 +248,8 @@ acpi_parse_int_src_ovr(struct acpi_subta
 static int __init
 acpi_parse_nmi_src(struct acpi_subtable_header * header, const unsigned =
long end)
 {
-	struct acpi_table_nmi_src *nmi_src =3D NULL;
-
-	nmi_src =3D (struct acpi_table_nmi_src *)header;
+	struct acpi_madt_nmi_source *nmi_src =3D
+		container_of(header, struct acpi_madt_nmi_source, header);
=20
 	if (BAD_MADT_ENTRY(nmi_src, end))
 		return -EINVAL;
@@ -270,7 +269,7 @@ static int __init acpi_parse_hpet(struct
 {
 	struct acpi_table_hpet *hpet_tbl =3D (struct acpi_table_hpet =
*)table;
=20
-	if (hpet_tbl->address.space_id !=3D ACPI_SPACE_MEM) {
+	if (hpet_tbl->address.space_id !=3D ACPI_ADR_SPACE_SYSTEM_MEMORY) =
{
 		printk(KERN_WARNING PREFIX "HPET timers must be located in =
"
 		       "memory.\n");
 		return -1;
--- a/xen/arch/x86/srat.c
+++ b/xen/arch/x86/srat.c
@@ -396,7 +396,8 @@ void __init srat_parse_regions(u64 addr)
 		return;
=20
 	srat_region_mask =3D fill_mask(addr - 1);
-	acpi_table_parse_srat(ACPI_SRAT_MEMORY_AFFINITY, srat_parse_region,=
 0);
+	acpi_table_parse_srat(ACPI_SRAT_TYPE_MEMORY_AFFINITY,
+			      srat_parse_region, 0);
=20
 	for (mask =3D srat_region_mask, i =3D 0; mask && i < e820.nr_map; =
i++) {
 		if (e820.map[i].type !=3D E820_RAM)
--- a/xen/drivers/acpi/numa.c
+++ b/xen/drivers/acpi/numa.c
@@ -46,7 +46,7 @@ void __init acpi_table_print_srat_entry(
=20
 	switch (header->type) {
=20
-	case ACPI_SRAT_PROCESSOR_AFFINITY:
+	case ACPI_SRAT_TYPE_CPU_AFFINITY:
 #ifdef ACPI_DEBUG_OUTPUT
 		{
 			struct acpi_srat_cpu_affinity *p =3D
@@ -68,7 +68,7 @@ void __init acpi_table_print_srat_entry(
 #endif				/* ACPI_DEBUG_OUTPUT */
 		break;
=20
-	case ACPI_SRAT_MEMORY_AFFINITY:
+	case ACPI_SRAT_TYPE_MEMORY_AFFINITY:
 #ifdef ACPI_DEBUG_OUTPUT
 		{
 			struct acpi_srat_mem_affinity *p =3D
@@ -194,8 +194,8 @@ int __init acpi_parse_srat(struct acpi_t
 }
=20
 int __init
-acpi_table_parse_srat(enum acpi_srat_entry_id id,
-		      acpi_madt_entry_handler handler, unsigned int =
max_entries)
+acpi_table_parse_srat(int id, acpi_madt_entry_handler handler,
+		      unsigned int max_entries)
 {
 	return acpi_table_parse_entries(ACPI_SIG_SRAT,
 					sizeof(struct acpi_table_srat), =
id,
@@ -206,12 +206,13 @@ int __init acpi_numa_init(void)
 {
 	/* SRAT: Static Resource Affinity Table */
 	if (!acpi_table_parse(ACPI_SIG_SRAT, acpi_parse_srat)) {
-		acpi_table_parse_srat(ACPI_SRAT_X2APIC_AFFINITY,
-				           acpi_parse_x2apic_affinity, =
NR_CPUS);
-		acpi_table_parse_srat(ACPI_SRAT_PROCESSOR_AFFINITY,
-					       acpi_parse_processor_affinit=
y,
-					       NR_CPUS);
-		acpi_table_parse_srat(ACPI_SRAT_MEMORY_AFFINITY, acpi_parse=
_memory_affinity, NR_NODE_MEMBLKS);	// IA64 specific
+		acpi_table_parse_srat(ACPI_SRAT_TYPE_X2APIC_CPU_AFFINITY,
+				      acpi_parse_x2apic_affinity, =
NR_CPUS);
+		acpi_table_parse_srat(ACPI_SRAT_TYPE_CPU_AFFINITY,
+				      acpi_parse_processor_affinity, =
NR_CPUS);
+		acpi_table_parse_srat(ACPI_SRAT_TYPE_MEMORY_AFFINITY,
+				      acpi_parse_memory_affinity,
+				      NR_NODE_MEMBLKS);
 	}
=20
 	/* SLIT: System Locality Information Table */
--- a/xen/include/xen/acpi.h
+++ b/xen/include/xen/acpi.h
@@ -34,123 +34,13 @@
 #include <acpi/acpi.h>
 #include <asm/acpi.h>
=20
-#ifdef CONFIG_ACPI_BOOT
-
-enum acpi_madt_entry_id {
-	ACPI_MADT_LAPIC =3D 0,
-	ACPI_MADT_IOAPIC,
-	ACPI_MADT_INT_SRC_OVR,
-	ACPI_MADT_NMI_SRC,
-	ACPI_MADT_LAPIC_NMI,
-	ACPI_MADT_LAPIC_ADDR_OVR,
-	ACPI_MADT_IOSAPIC,
-	ACPI_MADT_LSAPIC,
-	ACPI_MADT_PLAT_INT_SRC,
-	ACPI_MADT_X2APIC,
-	ACPI_MADT_X2APIC_NMI,
-	ACPI_MADT_ENTRY_COUNT
-};
-
-typedef struct {
-	u16			polarity:2;
-	u16			trigger:2;
-	u16			reserved:12;
-} __attribute__ ((packed)) acpi_interrupt_flags;
-
-struct acpi_table_lapic {
-	struct acpi_subtable_header	header;
-	u8			acpi_id;
-	u8			id;
-	struct {
-		u32			enabled:1;
-		u32			reserved:31;
-	}			flags;
-} __attribute__ ((packed));
-
-struct acpi_table_x2apic {
-	struct acpi_subtable_header header;
-	u16			reserved;
-	u32			id;
-	struct {
-		u32			enabled:1;
-		u32			reserved:31;
-	}			flags;
-	u32         acpi_uid;
-} __attribute__ ((packed));
-
-struct acpi_table_ioapic {
-	struct acpi_subtable_header	header;
-	u8			id;
-	u8			reserved;
-	u32			address;
-	u32			global_irq_base;
-} __attribute__ ((packed));
-
-struct acpi_table_int_src_ovr {
-	struct acpi_subtable_header	header;
-	u8			bus;
-	u8			bus_irq;
-	u32			global_irq;
-	acpi_interrupt_flags	flags;
-} __attribute__ ((packed));
-
-struct acpi_table_nmi_src {
-	struct acpi_subtable_header	header;
-	acpi_interrupt_flags	flags;
-	u32			global_irq;
-} __attribute__ ((packed));
-
-struct acpi_table_lapic_nmi {
-	struct acpi_subtable_header	header;
-	u8			acpi_id;
-	acpi_interrupt_flags	flags;
-	u8			lint;
-} __attribute__ ((packed));
-
-struct acpi_table_x2apic_nmi {
-	struct acpi_subtable_header header;
-	acpi_interrupt_flags	flags;
-	u32			acpi_uid;
-	u8			lint;
-	u8			reserved[3];
-} __attribute__ ((packed));
+#define ACPI_MADT_GET_(fld, x) (((x) & ACPI_MADT_##fld##_MASK) / \
+	(ACPI_MADT_##fld##_MASK & -ACPI_MADT_##fld##_MASK))
=20
-struct acpi_table_lapic_addr_ovr {
-	struct acpi_subtable_header	header;
-	u8			reserved[2];
-	u64			address;
-} __attribute__ ((packed));
-
-struct acpi_table_iosapic {
-	struct acpi_subtable_header	header;
-	u8			id;
-	u8			reserved;
-	u32			global_irq_base;
-	u64			address;
-} __attribute__ ((packed));
-
-struct acpi_table_lsapic {
-	struct acpi_subtable_header	header;
-	u8			acpi_id;
-	u8			id;
-	u8			eid;
-	u8			reserved[3];
-	struct {
-		u32			enabled:1;
-		u32			reserved:31;
-	}			flags;
-} __attribute__ ((packed));
+#define ACPI_MADT_GET_POLARITY(inti)	ACPI_MADT_GET_(POLARITY, inti)
+#define ACPI_MADT_GET_TRIGGER(inti)	ACPI_MADT_GET_(TRIGGER, inti)
=20
-struct acpi_table_plat_int_src {
-	struct acpi_subtable_header	header;
-	acpi_interrupt_flags	flags;
-	u8			type;	/* See acpi_interrupt_type */
-	u8			id;
-	u8			eid;
-	u8			iosapic_vector;
-	u32			global_irq;
-	u32			reserved;
-} __attribute__ ((packed));
+#ifdef CONFIG_ACPI_BOOT
=20
 enum acpi_interrupt_id {
 	ACPI_INTERRUPT_PMI	=3D 1,
@@ -159,42 +49,6 @@ enum acpi_interrupt_id {
 	ACPI_INTERRUPT_COUNT
 };
=20
-#define	ACPI_SPACE_MEM		0
-
-/*
- * Simple Boot Flags
- * http://www.microsoft.com/whdc/hwdev/resources/specs/simp_bios.mspx=20
- */
-struct acpi_table_sbf
-{
-	u8 sbf_signature[4];
-	u32 sbf_len;
-	u8 sbf_revision;
-	u8 sbf_csum;
-	u8 sbf_oemid[6];
-	u8 sbf_oemtable[8];
-	u8 sbf_revdata[4];
-	u8 sbf_creator[4];
-	u8 sbf_crearev[4];
-	u8 sbf_cmos;
-	u8 sbf_spare[3];
-} __attribute__ ((packed));
-
-enum acpi_srat_entry_id {
-	ACPI_SRAT_PROCESSOR_AFFINITY =3D 0,
-	ACPI_SRAT_MEMORY_AFFINITY,
-	ACPI_SRAT_X2APIC_AFFINITY,
-	ACPI_SRAT_ENTRY_COUNT
-};
-
-enum acpi_address_range_id {
-	ACPI_ADDRESS_RANGE_MEMORY =3D 1,
-	ACPI_ADDRESS_RANGE_RESERVED =3D 2,
-	ACPI_ADDRESS_RANGE_ACPI =3D 3,
-	ACPI_ADDRESS_RANGE_NVS	=3D 4,
-	ACPI_ADDRESS_RANGE_COUNT
-};
-
 /* DMA Remapping Reporting Table (DMAR) */
=20
 #define DMAR_FLAGS_INTR_REMAP 0x1       /* intr remap supported */
@@ -282,8 +136,8 @@ int acpi_table_parse(char *id, acpi_tabl
 int acpi_table_parse_entries(char *id, unsigned long table_size,
 	int entry_id, acpi_table_entry_handler handler, unsigned int =
max_entries);
 int acpi_table_parse_madt(enum acpi_madt_type id, acpi_table_entry_handler=
 handler, unsigned int max_entries);
-int acpi_table_parse_srat(enum acpi_srat_entry_id id,
-	acpi_madt_entry_handler handler, unsigned int max_entries);
+int acpi_table_parse_srat(int id, acpi_madt_entry_handler handler,
+	unsigned int max_entries);
 int acpi_parse_srat(struct acpi_table_header *);
 void acpi_table_print (struct acpi_table_header *header, unsigned long =
phys_addr);
 void acpi_table_print_madt_entry (struct acpi_subtable_header *madt);



--=__PartB6991351.0__=
Content-Type: text/plain; name="acpi-duplicate-structs.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="acpi-duplicate-structs.patch"

ACPI: eliminate duplicate MADT parsing and unused SBF definitions=0A=0AUse =
their proper counterparts in include/acpi/actbl*.h instead.=0A=0ASigned-off=
-by: Jan Beulich <jbeulich@suse.com>=0A=0A--- a/xen/arch/ia64/xen/dom_fw_co=
mmon.c=0A+++ b/xen/arch/ia64/xen/dom_fw_common.c=0A@@ -347,7 +347,7 @@ =
struct fake_acpi_tables {=0A 	struct acpi_table_header dsdt;=0A 	=
uint8_t aml[8 + 11 * MAX_VIRT_CPUS];=0A 	struct acpi_table_madt =
madt;=0A-	struct acpi_table_lsapic lsapic[MAX_VIRT_CPUS];=0A+	=
struct acpi_madt_local_sapic lsapic[MAX_VIRT_CPUS];=0A 	uint8_t pm1a_event_=
block[4];=0A 	uint8_t pm1a_control_block[1];=0A 	uint8_t pm_timer_bl=
ock[4];=0A@@ -365,7 +365,7 @@ dom_fw_fake_acpi(domain_t *d, struct fak=0A 	=
struct acpi_table_facs *facs =3D &tables->facs;=0A 	struct acpi_table_h=
eader *dsdt =3D &tables->dsdt;=0A 	struct acpi_table_madt *madt =3D =
&tables->madt;=0A-	struct acpi_table_lsapic *lsapic =3D tables->lsapic=
;=0A+	struct acpi_madt_local_sapic *lsapic =3D tables->lsapic;=0A 	=
int i;=0A 	int aml_len;=0A 	int nbr_cpus;=0A@@ -492,18 +492,18 =
@@ dom_fw_fake_acpi(domain_t *d, struct fak=0A 	/* An LSAPIC entry =
describes a CPU.  */=0A 	nbr_cpus =3D 0;=0A 	for (i =3D 0; i < =
MAX_VIRT_CPUS; i++) {=0A-		lsapic[i].header.type =3D =
ACPI_MADT_LSAPIC;=0A-		lsapic[i].header.length =3D sizeof(struct =
acpi_table_lsapic);=0A-		lsapic[i].acpi_id =3D i;=0A+		=
lsapic[i].header.type =3D ACPI_MADT_TYPE_LOCAL_SAPIC;=0A+		=
lsapic[i].header.length =3D sizeof(lsapic[i]);=0A+		lsapic[i].p=
rocessor_id =3D i;=0A 		lsapic[i].id =3D i;=0A 		lsapic[i].e=
id =3D 0;=0A 		if (xen_ia64_is_vcpu_allocated(d, i)) {=0A-		=
	lsapic[i].flags.enabled =3D 1;=0A+			lsapic[i].l=
apic_flags =3D ACPI_MADT_ENABLED;=0A 			nbr_cpus++;=0A 		=
}=0A 	}=0A 	madt->header.length =3D sizeof(struct acpi_table_madt) =
+=0A-	                      nbr_cpus * sizeof(struct acpi_table_lsapic);=
=0A+	                      nbr_cpus * sizeof(*lsapic);=0A 	madt->heade=
r.checksum =3D -acpi_tb_checksum((u8*)madt,=0A 					=
	  madt->header.length);=0A 	return;=0A--- a/xen/arch/ia64/xen/d=
om_fw_dom0.c=0A+++ b/xen/arch/ia64/xen/dom_fw_dom0.c=0A@@ -53,11 +53,11 @@ =
static u32 lsapic_nbr;=0A static int __init=0A acpi_update_lsapic(struct =
acpi_subtable_header * header, const unsigned long end)=0A {=0A-	=
struct acpi_table_lsapic *lsapic;=0A+	struct acpi_madt_local_sapic =
*lsapic =3D=0A+		container_of(header, struct acpi_madt_local_sapic, =
header);=0A 	int enable;=0A =0A-	lsapic =3D (struct acpi_table_lsapi=
c *)header;=0A-	if (!lsapic)=0A+	if (!header)=0A 		=
return -EINVAL;=0A =0A 	if (lsapic_nbr < dom0->max_vcpus && dom0->vcpu[lsap=
ic_nbr] !=3D NULL)=0A@@ -65,14 +65,14 @@ acpi_update_lsapic(struct =
acpi_subtable_=0A 	else=0A 		enable =3D 0;=0A =0A-	if =
(lsapic->flags.enabled && enable) {=0A+	if ((lsapic->lapic_flags & =
ACPI_MADT_ENABLED) && enable) {=0A 		printk("enable lsapic =
entry: 0x%lx\n", (u64) lsapic);=0A 		lsapic->id =3D lsapic_nbr;=
=0A 		lsapic->eid =3D 0;=0A 		lsapic_nbr++;=0A-	} =
else if (lsapic->flags.enabled) {=0A+	} else if (lsapic->lapic_flags & =
ACPI_MADT_ENABLED) {=0A 		printk("DISABLE lsapic entry: =
0x%lx\n", (u64) lsapic);=0A-		lsapic->flags.enabled =3D 0;=0A+	=
	lsapic->lapic_flags &=3D ~ACPI_MADT_ENABLED;=0A 		=
lsapic->id =3D 0;=0A 		lsapic->eid =3D 0;=0A 	}=0A@@ -83,10 =
+83,11 @@ static int __init=0A acpi_patch_plat_int_src(struct acpi_subtable=
_header * header,=0A 			const unsigned long end)=0A {=0A-	=
struct acpi_table_plat_int_src *plintsrc;=0A+	struct acpi_madt_interrupt_=
source *plintsrc =3D=0A+		container_of(header, struct =
acpi_madt_interrupt_source,=0A+			     header);=0A =0A-	=
plintsrc =3D (struct acpi_table_plat_int_src *)header;=0A-	if =
(!plintsrc)=0A+	if (!header)=0A 		return -EINVAL;=0A =0A 	if =
(plintsrc->type =3D=3D ACPI_INTERRUPT_CPEI) {=0A@@ -193,12 +194,13 @@ =
static void __init touch_acpi_table(void=0A 	 */=0A 	acpi_table_parse(AC=
PI_SIG_MADT, acpi_backup_table);=0A =0A-	if (acpi_table_parse_madt(A=
CPI_MADT_LSAPIC, acpi_update_lsapic, 0) < 0)=0A+	if (acpi_table_pars=
e_madt(ACPI_MADT_TYPE_LOCAL_SAPIC,=0A+				  =
acpi_update_lsapic, 0) < 0)=0A 		printk("Error parsing MADT - no =
LAPIC entries\n");=0A =0A 	acpi_update_madt_checksum(madt);=0A =0A-	=
if (acpi_table_parse_madt(ACPI_MADT_PLAT_INT_SRC,=0A+	if (acpi_table_pars=
e_madt(ACPI_MADT_TYPE_INTERRUPT_SOURCE,=0A 				  =
acpi_patch_plat_int_src, 0) < 0)=0A 		printk("Error parsing MADT =
- no PLAT_INT_SRC entries\n");=0A =0A--- a/xen/arch/x86/acpi/boot.c=0A+++ =
b/xen/arch/x86/acpi/boot.c=0A@@ -87,9 +87,9 @@ static int __init acpi_parse=
_madt(struct=0A static int __init=0A acpi_parse_x2apic(struct acpi_subtable=
_header *header, const unsigned long end)=0A {=0A-	struct acpi_table_x=
2apic *processor =3D NULL;=0A-=0A-	processor =3D (struct acpi_table_x2=
apic *)header;=0A+	struct acpi_madt_local_x2apic *processor =3D=0A+	=
	container_of(header, struct acpi_madt_local_x2apic, header);=0A+	=
bool_t enabled =3D 0;=0A =0A 	if (BAD_MADT_ENTRY(processor, end))=0A 		=
return -EINVAL;=0A@@ -97,8 +97,11 @@ acpi_parse_x2apic(struct acpi_subtable=
_h=0A 	acpi_table_print_madt_entry(header);=0A =0A 	/* Record local =
apic id only when enabled */=0A-	if (processor->flags.enabled)=0A-	=
	x86_acpiid_to_apicid[processor->acpi_uid] =3D processor->id;=0A+	=
if (processor->lapic_flags & ACPI_MADT_ENABLED) {=0A+		x86_acpiid_=
to_apicid[processor->uid] =3D=0A+			processor->local_ap=
ic_id;=0A+		enabled =3D 1;=0A+	}=0A =0A 	/*=0A 	 * =
We need to register disabled CPU as well to permit=0A@@ -107,9 +110,7 @@ =
acpi_parse_x2apic(struct acpi_subtable_h=0A 	 * to not preallocating =
memory for all NR_CPUS=0A 	 * when we use CPU hotplug.=0A 	 */=0A-	=
mp_register_lapic(processor->id,	/* X2APIC ID */=0A-			=
  processor->flags.enabled,	/* Enabled? */=0A-			  =
0);=0A+	mp_register_lapic(processor->local_apic_id, enabled, 0);=0A =0A 	=
return 0;=0A }=0A@@ -117,9 +118,9 @@ acpi_parse_x2apic(struct acpi_subtable=
_h=0A static int __init=0A acpi_parse_lapic(struct acpi_subtable_header * =
header, const unsigned long end)=0A {=0A-	struct acpi_table_lapic =
*processor =3D NULL;=0A-=0A-	processor =3D (struct acpi_table_lapic =
*)header;=0A+	struct acpi_madt_local_apic *processor =3D=0A+		=
container_of(header, struct acpi_madt_local_apic, header);=0A+	bool_t =
enabled =3D 0;=0A =0A 	if (BAD_MADT_ENTRY(processor, end))=0A 		=
return -EINVAL;=0A@@ -127,8 +128,10 @@ acpi_parse_lapic(struct acpi_subtabl=
e_he=0A 	acpi_table_print_madt_entry(header);=0A =0A 	/* Record =
local apic id only when enabled */=0A-	if (processor->flags.enabled)=0A-	=
	x86_acpiid_to_apicid[processor->acpi_id] =3D processor->id;=0A+	if =
(processor->lapic_flags & ACPI_MADT_ENABLED) {=0A+		x86_acpiid_=
to_apicid[processor->processor_id] =3D processor->id;=0A+		=
enabled =3D 1;=0A+	}=0A =0A 	/*=0A 	 * We need to register =
disabled CPU as well to permit=0A@@ -137,9 +140,7 @@ acpi_parse_lapic(struc=
t acpi_subtable_he=0A 	 * to not preallocating memory for all NR_CPUS=0A 	=
 * when we use CPU hotplug.=0A 	 */=0A-	mp_register_lapic(processor->id,	=
/* APIC ID */=0A-			  processor->flags.enabled,	/* =
Enabled? */=0A-			  0);=0A+	mp_register_lapic(processor=
->id, enabled, 0);=0A =0A 	return 0;=0A }=0A@@ -148,9 +149,9 @@ =
static int __init=0A acpi_parse_lapic_addr_ovr(struct acpi_subtable_header =
* header,=0A 			  const unsigned long end)=0A {=0A-	=
struct acpi_table_lapic_addr_ovr *lapic_addr_ovr =3D NULL;=0A-=0A-	=
lapic_addr_ovr =3D (struct acpi_table_lapic_addr_ovr *)header;=0A+	=
struct acpi_madt_local_apic_override *lapic_addr_ovr =3D=0A+		=
container_of(header, struct acpi_madt_local_apic_override,=0A+			=
     header);=0A =0A 	if (BAD_MADT_ENTRY(lapic_addr_ovr, end))=0A 		=
return -EINVAL;=0A@@ -164,9 +165,9 @@ static int __init=0A acpi_parse_x2api=
c_nmi(struct acpi_subtable_header *header,=0A 		      const =
unsigned long end)=0A {=0A-	struct acpi_table_x2apic_nmi *x2apic_nmi =
=3D NULL;=0A-=0A-	x2apic_nmi =3D (struct acpi_table_x2apic_nmi =
*)header;=0A+	struct acpi_madt_local_x2apic_nmi *x2apic_nmi =3D=0A+		=
container_of(header, struct acpi_madt_local_x2apic_nmi,=0A+			=
     header);=0A =0A 	if (BAD_MADT_ENTRY(x2apic_nmi, end))=0A 		=
return -EINVAL;=0A@@ -182,9 +183,8 @@ acpi_parse_x2apic_nmi(struct =
acpi_subtab=0A static int __init=0A acpi_parse_lapic_nmi(struct acpi_subtab=
le_header * header, const unsigned long end)=0A {=0A-	struct acpi_table_l=
apic_nmi *lapic_nmi =3D NULL;=0A-=0A-	lapic_nmi =3D (struct acpi_table_la=
pic_nmi *)header;=0A+	struct acpi_madt_local_apic_nmi *lapic_nmi =3D=0A+	=
	container_of(header, struct acpi_madt_local_apic_nmi, header);=0A =
=0A 	if (BAD_MADT_ENTRY(lapic_nmi, end))=0A 		return -EINVAL;=0A@=
@ -204,9 +204,8 @@ acpi_parse_lapic_nmi(struct acpi_subtabl=0A static int =
__init=0A acpi_parse_ioapic(struct acpi_subtable_header * header, const =
unsigned long end)=0A {=0A-	struct acpi_table_ioapic *ioapic =3D =
NULL;=0A-=0A-	ioapic =3D (struct acpi_table_ioapic *)header;=0A+	=
struct acpi_madt_io_apic *ioapic =3D=0A+		container_of(header=
, struct acpi_madt_io_apic, header);=0A =0A 	if (BAD_MADT_ENTRY(ioapic, =
end))=0A 		return -EINVAL;=0A@@ -223,9 +222,9 @@ static int =
__init=0A acpi_parse_int_src_ovr(struct acpi_subtable_header * header,=0A 	=
	       const unsigned long end)=0A {=0A-	struct acpi_table_i=
nt_src_ovr *intsrc =3D NULL;=0A-=0A-	intsrc =3D (struct acpi_table_int_s=
rc_ovr *)header;=0A+	struct acpi_madt_interrupt_override *intsrc =
=3D=0A+		container_of(header, struct acpi_madt_interrupt_override,=
=0A+			     header);=0A =0A 	if (BAD_MADT_ENTRY(intsrc, =
end))=0A 		return -EINVAL;=0A@@ -233,14 +232,15 @@ acpi_parse_=
int_src_ovr(struct acpi_subta=0A 	acpi_table_print_madt_entry(header)=
;=0A =0A 	if (acpi_skip_timer_override &&=0A-		intsrc->bus=
_irq =3D=3D 0 && intsrc->global_irq =3D=3D 2) {=0A+	    intsrc->source_=
irq =3D=3D 0 && intsrc->global_irq =3D=3D 2) {=0A 			=
printk(PREFIX "BIOS IRQ0 pin2 override ignored.\n");=0A 			=
return 0;=0A 	}=0A =0A-	mp_override_legacy_irq(intsrc->bus_irq,=0A-=
			       intsrc->flags.polarity,=0A-			=
       intsrc->flags.trigger, intsrc->global_irq);=0A+	mp_override_legacy_=
irq(intsrc->source_irq,=0A+			       ACPI_MADT_GET_POLARI=
TY(intsrc->inti_flags),=0A+			       ACPI_MADT_GET_TRIGGE=
R(intsrc->inti_flags),=0A+			       intsrc->global_irq);=
=0A =0A 	return 0;=0A }=0A@@ -248,9 +248,8 @@ acpi_parse_int_src_ovr=
(struct acpi_subta=0A static int __init=0A acpi_parse_nmi_src(struct =
acpi_subtable_header * header, const unsigned long end)=0A {=0A-	=
struct acpi_table_nmi_src *nmi_src =3D NULL;=0A-=0A-	nmi_src =3D =
(struct acpi_table_nmi_src *)header;=0A+	struct acpi_madt_nmi_source=
 *nmi_src =3D=0A+		container_of(header, struct acpi_madt_nmi_s=
ource, header);=0A =0A 	if (BAD_MADT_ENTRY(nmi_src, end))=0A 		=
return -EINVAL;=0A@@ -270,7 +269,7 @@ static int __init acpi_parse_hpet(str=
uct=0A {=0A 	struct acpi_table_hpet *hpet_tbl =3D (struct acpi_table_hpe=
t *)table;=0A =0A-	if (hpet_tbl->address.space_id !=3D ACPI_SPACE_MEM)=
 {=0A+	if (hpet_tbl->address.space_id !=3D ACPI_ADR_SPACE_SYSTEM_MEMORY) =
{=0A 		printk(KERN_WARNING PREFIX "HPET timers must be located in =
"=0A 		       "memory.\n");=0A 		return -1;=0A--- =
a/xen/arch/x86/srat.c=0A+++ b/xen/arch/x86/srat.c=0A@@ -396,7 +396,8 @@ =
void __init srat_parse_regions(u64 addr)=0A 		return;=0A =0A 	=
srat_region_mask =3D fill_mask(addr - 1);=0A-	acpi_table_parse_srat(ACPI_=
SRAT_MEMORY_AFFINITY, srat_parse_region, 0);=0A+	acpi_table_parse_sr=
at(ACPI_SRAT_TYPE_MEMORY_AFFINITY,=0A+			      srat_parse_re=
gion, 0);=0A =0A 	for (mask =3D srat_region_mask, i =3D 0; mask && i =
< e820.nr_map; i++) {=0A 		if (e820.map[i].type !=3D =
E820_RAM)=0A--- a/xen/drivers/acpi/numa.c=0A+++ b/xen/drivers/acpi/numa.c=
=0A@@ -46,7 +46,7 @@ void __init acpi_table_print_srat_entry(=0A =0A 	=
switch (header->type) {=0A =0A-	case ACPI_SRAT_PROCESSOR_AFFINITY:=0A+	=
case ACPI_SRAT_TYPE_CPU_AFFINITY:=0A #ifdef ACPI_DEBUG_OUTPUT=0A 		=
{=0A 			struct acpi_srat_cpu_affinity *p =3D=0A@@ -68,7 =
+68,7 @@ void __init acpi_table_print_srat_entry(=0A #endif			=
	/* ACPI_DEBUG_OUTPUT */=0A 		break;=0A =0A-	case =
ACPI_SRAT_MEMORY_AFFINITY:=0A+	case ACPI_SRAT_TYPE_MEMORY_AFFINITY:=0A =
#ifdef ACPI_DEBUG_OUTPUT=0A 		{=0A 			struct =
acpi_srat_mem_affinity *p =3D=0A@@ -194,8 +194,8 @@ int __init acpi_parse_s=
rat(struct acpi_t=0A }=0A =0A int __init=0A-acpi_table_parse_srat(enum =
acpi_srat_entry_id id,=0A-		      acpi_madt_entry_handler =
handler, unsigned int max_entries)=0A+acpi_table_parse_srat(int id, =
acpi_madt_entry_handler handler,=0A+		      unsigned int =
max_entries)=0A {=0A 	return acpi_table_parse_entries(ACPI_SIG_SRAT,=0A 	=
				sizeof(struct acpi_table_srat), id,=0A@@ =
-206,12 +206,13 @@ int __init acpi_numa_init(void)=0A {=0A 	/* SRAT: =
Static Resource Affinity Table */=0A 	if (!acpi_table_parse(ACPI_SIG_SRAT=
, acpi_parse_srat)) {=0A-		acpi_table_parse_srat(ACPI_SRAT_X2A=
PIC_AFFINITY,=0A-				           acpi_parse_x2api=
c_affinity, NR_CPUS);=0A-		acpi_table_parse_srat(ACPI_SRAT_PRO=
CESSOR_AFFINITY,=0A-					       acpi_parse_p=
rocessor_affinity,=0A-					       NR_CPUS);=0A=
-		acpi_table_parse_srat(ACPI_SRAT_MEMORY_AFFINITY, acpi_parse=
_memory_affinity, NR_NODE_MEMBLKS);	// IA64 specific=0A+		=
acpi_table_parse_srat(ACPI_SRAT_TYPE_X2APIC_CPU_AFFINITY,=0A+			=
	      acpi_parse_x2apic_affinity, NR_CPUS);=0A+		acpi_table_=
parse_srat(ACPI_SRAT_TYPE_CPU_AFFINITY,=0A+				   =
   acpi_parse_processor_affinity, NR_CPUS);=0A+		acpi_table_parse_sr=
at(ACPI_SRAT_TYPE_MEMORY_AFFINITY,=0A+				      =
acpi_parse_memory_affinity,=0A+				      NR_NODE_MEMBL=
KS);=0A 	}=0A =0A 	/* SLIT: System Locality Information Table =
*/=0A--- a/xen/include/xen/acpi.h=0A+++ b/xen/include/xen/acpi.h=0A@@ =
-34,123 +34,13 @@=0A #include <acpi/acpi.h>=0A #include <asm/acpi.h>=0A =
=0A-#ifdef CONFIG_ACPI_BOOT=0A-=0A-enum acpi_madt_entry_id {=0A-	=
ACPI_MADT_LAPIC =3D 0,=0A-	ACPI_MADT_IOAPIC,=0A-	ACPI_MADT_INT_SRC_O=
VR,=0A-	ACPI_MADT_NMI_SRC,=0A-	ACPI_MADT_LAPIC_NMI,=0A-	ACPI_MADT_L=
APIC_ADDR_OVR,=0A-	ACPI_MADT_IOSAPIC,=0A-	ACPI_MADT_LSAPIC,=0A-	=
ACPI_MADT_PLAT_INT_SRC,=0A-	ACPI_MADT_X2APIC,=0A-	ACPI_MADT_X2APIC_NM=
I,=0A-	ACPI_MADT_ENTRY_COUNT=0A-};=0A-=0A-typedef struct {=0A-	u16		=
	polarity:2;=0A-	u16			trigger:2;=0A-	u16		=
	reserved:12;=0A-} __attribute__ ((packed)) acpi_interrupt_flags;=0A=
-=0A-struct acpi_table_lapic {=0A-	struct acpi_subtable_header	=
header;=0A-	u8			acpi_id;=0A-	u8			=
id;=0A-	struct {=0A-		u32			enabled:1;=0A-		=
u32			reserved:31;=0A-	}			=
flags;=0A-} __attribute__ ((packed));=0A-=0A-struct acpi_table_x2apic =
{=0A-	struct acpi_subtable_header header;=0A-	u16			=
reserved;=0A-	u32			id;=0A-	struct {=0A-		=
u32			enabled:1;=0A-		u32			=
reserved:31;=0A-	}			flags;=0A-	u32        =
 acpi_uid;=0A-} __attribute__ ((packed));=0A-=0A-struct acpi_table_ioapic =
{=0A-	struct acpi_subtable_header	header;=0A-	u8			=
id;=0A-	u8			reserved;=0A-	u32			=
address;=0A-	u32			global_irq_base;=0A-} __attribute__=
 ((packed));=0A-=0A-struct acpi_table_int_src_ovr {=0A-	struct acpi_subtabl=
e_header	header;=0A-	u8			bus;=0A-	u8	=
		bus_irq;=0A-	u32			global_irq;=0A-	=
acpi_interrupt_flags	flags;=0A-} __attribute__ ((packed));=0A-=0A-struct=
 acpi_table_nmi_src {=0A-	struct acpi_subtable_header	header;=0A-=
	acpi_interrupt_flags	flags;=0A-	u32			=
global_irq;=0A-} __attribute__ ((packed));=0A-=0A-struct acpi_table_lapic_n=
mi {=0A-	struct acpi_subtable_header	header;=0A-	u8		=
	acpi_id;=0A-	acpi_interrupt_flags	flags;=0A-	u8		=
	lint;=0A-} __attribute__ ((packed));=0A-=0A-struct acpi_table_x2api=
c_nmi {=0A-	struct acpi_subtable_header header;=0A-	acpi_interrupt_flag=
s	flags;=0A-	u32			acpi_uid;=0A-	u8		=
	lint;=0A-	u8			reserved[3];=0A-} =
__attribute__ ((packed));=0A+#define ACPI_MADT_GET_(fld, x) (((x) & =
ACPI_MADT_##fld##_MASK) / \=0A+	(ACPI_MADT_##fld##_MASK & -ACPI_MADT_##fld#=
#_MASK))=0A =0A-struct acpi_table_lapic_addr_ovr {=0A-	struct acpi_subtabl=
e_header	header;=0A-	u8			reserved[2];=0A-	=
u64			address;=0A-} __attribute__ ((packed));=0A-=0A-stru=
ct acpi_table_iosapic {=0A-	struct acpi_subtable_header	header;=0A-=
	u8			id;=0A-	u8			=
reserved;=0A-	u32			global_irq_base;=0A-	u64		=
	address;=0A-} __attribute__ ((packed));=0A-=0A-struct acpi_table_ls=
apic {=0A-	struct acpi_subtable_header	header;=0A-	u8		=
	acpi_id;=0A-	u8			id;=0A-	u8			=
eid;=0A-	u8			reserved[3];=0A-	struct =
{=0A-		u32			enabled:1;=0A-		u32		=
	reserved:31;=0A-	}			flags;=0A-} =
__attribute__ ((packed));=0A+#define ACPI_MADT_GET_POLARITY(inti)	=
ACPI_MADT_GET_(POLARITY, inti)=0A+#define ACPI_MADT_GET_TRIGGER(inti)	=
ACPI_MADT_GET_(TRIGGER, inti)=0A =0A-struct acpi_table_plat_int_src {=0A-	=
struct acpi_subtable_header	header;=0A-	acpi_interrupt_flags	=
flags;=0A-	u8			type;	/* See acpi_interrupt_type =
*/=0A-	u8			id;=0A-	u8			eid;=0A-	=
u8			iosapic_vector;=0A-	u32			=
global_irq;=0A-	u32			reserved;=0A-} __attribute__ =
((packed));=0A+#ifdef CONFIG_ACPI_BOOT=0A =0A enum acpi_interrupt_id {=0A 	=
ACPI_INTERRUPT_PMI	=3D 1,=0A@@ -159,42 +49,6 @@ enum acpi_interrupt_id=
 {=0A 	ACPI_INTERRUPT_COUNT=0A };=0A =0A-#define	ACPI_SPACE_MEM		=
0=0A-=0A-/*=0A- * Simple Boot Flags=0A- * http://www.microsoft.com/whdc/hwd=
ev/resources/specs/simp_bios.mspx=0A- */=0A-struct acpi_table_sbf=0A-{=0A-	=
u8 sbf_signature[4];=0A-	u32 sbf_len;=0A-	u8 sbf_revision;=0A=
-	u8 sbf_csum;=0A-	u8 sbf_oemid[6];=0A-	u8 sbf_oemtable[8];=
=0A-	u8 sbf_revdata[4];=0A-	u8 sbf_creator[4];=0A-	u8 sbf_crearev[4];=
=0A-	u8 sbf_cmos;=0A-	u8 sbf_spare[3];=0A-} __attribute__ =
((packed));=0A-=0A-enum acpi_srat_entry_id {=0A-	ACPI_SRAT_PROCESSOR=
_AFFINITY =3D 0,=0A-	ACPI_SRAT_MEMORY_AFFINITY,=0A-	ACPI_SRAT_X2APIC_AF=
FINITY,=0A-	ACPI_SRAT_ENTRY_COUNT=0A-};=0A-=0A-enum acpi_address_range_=
id {=0A-	ACPI_ADDRESS_RANGE_MEMORY =3D 1,=0A-	ACPI_ADDRESS_RANGE_=
RESERVED =3D 2,=0A-	ACPI_ADDRESS_RANGE_ACPI =3D 3,=0A-	ACPI_ADDRES=
S_RANGE_NVS	=3D 4,=0A-	ACPI_ADDRESS_RANGE_COUNT=0A-};=0A-=0A /* =
DMA Remapping Reporting Table (DMAR) */=0A =0A #define DMAR_FLAGS_INTR_REMA=
P 0x1       /* intr remap supported */=0A@@ -282,8 +136,8 @@ int acpi_table=
_parse(char *id, acpi_tabl=0A int acpi_table_parse_entries(char *id, =
unsigned long table_size,=0A 	int entry_id, acpi_table_entry_handler =
handler, unsigned int max_entries);=0A int acpi_table_parse_madt(enum =
acpi_madt_type id, acpi_table_entry_handler handler, unsigned int =
max_entries);=0A-int acpi_table_parse_srat(enum acpi_srat_entry_id id,=0A-	=
acpi_madt_entry_handler handler, unsigned int max_entries);=0A+int =
acpi_table_parse_srat(int id, acpi_madt_entry_handler handler,=0A+	=
unsigned int max_entries);=0A int acpi_parse_srat(struct acpi_table_header =
*);=0A void acpi_table_print (struct acpi_table_header *header, unsigned =
long phys_addr);=0A void acpi_table_print_madt_entry (struct acpi_subtable_=
header *madt);=0A
--=__PartB6991351.0__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--=__PartB6991351.0__=--


From xen-devel-bounces@lists.xensource.com Mon Dec 12 16:10:26 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 16:10:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ra8SG-0003St-O4; Mon, 12 Dec 2011 16:10:16 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Ra8SE-0003S1-HH
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 16:10:15 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1323706156!7886778!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25105 invoked from network); 12 Dec 2011 16:09:16 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-8.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 12 Dec 2011 16:09:16 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 12 Dec 2011 16:09:16 +0000
Message-Id: <4EE635710200007800067060@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 12 Dec 2011 16:10:09 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part96B93371.0__="
Subject: [Xen-devel] [PATCH 2/4] ACPI: update table interface headers
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__Part96B93371.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

... to what is being used on Linux 3.1 (and 3.2-rc).

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/drivers/acpi/numa.c
+++ b/xen/drivers/acpi/numa.c
@@ -78,9 +78,11 @@ void __init acpi_table_print_srat_entry(
 			if (srat_rev < 2)
 				proximity_domain &=3D 0xff;
 			ACPI_DEBUG_PRINT((ACPI_DB_INFO,
-					  "SRAT Memory (0x%016"PRIx64" =
length 0x%016"PRIx64" type 0x%x) in proximity domain %d %s%s\n",
+					  "SRAT Memory (%#016"PRIx64
+					  " length %#016"PRIx64")"
+					  " in proximity domain %d =
%s%s\n",
 					  p->base_address, p->length,
-					  p->memory_type, proximity_domain,=

+					  proximity_domain,
 					  p->flags & ACPI_SRAT_MEM_ENABLED
 					  ? "enabled" : "disabled",
 					  p->flags & ACPI_SRAT_MEM_HOT_PLUG=
GABLE
--- a/xen/include/acpi/actbl.h
+++ b/xen/include/acpi/actbl.h
@@ -5,7 +5,7 @@
  *************************************************************************=
****/
=20
 /*
- * Copyright (C) 2000 - 2007, R. Byron Moore
+ * Copyright (C) 2000 - 2011, Intel Corp.
  * All rights reserved.
  *
  * Redistribution and use in source and binary forms, with or without
@@ -44,9 +44,23 @@
 #ifndef __ACTBL_H__
 #define __ACTBL_H__
=20
+/*************************************************************************=
******
+ *
+ * Fundamental ACPI tables
+ *
+ * This file contains definitions for the ACPI tables that are directly =
consumed
+ * by ACPICA. All other tables are consumed by the OS-dependent ACPI-relat=
ed
+ * device drivers and other OS support code.
+ *
+ * The RSDP and FACS do not use the common ACPI table header. All other =
ACPI
+ * tables use the header.
+ *
+ *************************************************************************=
*****/
+
 /*
- * Values for description table header signatures. Useful because they =
make
- * it more difficult to inadvertently type in the wrong signature.
+ * Values for description table header signatures for tables defined in =
this
+ * file. Useful because they make it more difficult to inadvertently type =
in
+ * the wrong signature.
  */
 #define ACPI_SIG_DSDT           "DSDT"	/* Differentiated System Descriptio=
n Table */
 #define ACPI_SIG_FADT           "FACP"	/* Fixed ACPI Description Table */
@@ -65,11 +79,6 @@
 #pragma pack(1)
=20
 /*
- * These are the ACPI tables that are directly consumed by the subsystem.
- *
- * The RSDP and FACS do not use the common ACPI table header. All other =
ACPI
- * tables use the header.
- *
  * Note about bitfields: The u8 type is used for bitfields in ACPI =
tables.
  * This is the only type that is even remotely portable. Anything else is =
not
  * portable, so do not use any other bitfield types.
@@ -77,9 +86,8 @@
=20
 /*************************************************************************=
******
  *
- * ACPI Table Header. This common header is used by all tables except the
- * RSDP and FACS. The define is used for direct inclusion of header into
- * other ACPI tables
+ * Master ACPI Table Header. This common header is used by all ACPI =
tables
+ * except the RSDP and FACS.
  *
  *************************************************************************=
*****/
=20
@@ -95,13 +103,16 @@ struct acpi_table_header {
 	u32 asl_compiler_revision;	/* ASL compiler version */
 };
=20
-/*
+/*************************************************************************=
******
+ *
  * GAS - Generic Address Structure (ACPI 2.0+)
  *
  * Note: Since this structure is used in the ACPI tables, it is byte =
aligned.
- * If misalignment is not supported, access to the Address field must be
- * performed with care.
- */
+ * If misaliged access is not supported by the hardware, accesses to the
+ * 64-bit Address field must be performed with care.
+ *
+ *************************************************************************=
*****/
+
 struct acpi_generic_address {
 	u8 space_id;		/* Address space where struct or register =
exists */
 	u8 bit_width;		/* Size in bits of given register */
@@ -113,6 +124,7 @@ struct acpi_generic_address {
 /*************************************************************************=
******
  *
  * RSDP - Root System Description Pointer (Signature is "RSD PTR ")
+ *        Version 2
  *
  *************************************************************************=
*****/
=20
@@ -133,6 +145,7 @@ struct acpi_table_rsdp {
 /*************************************************************************=
******
  *
  * RSDT/XSDT - Root System Description Tables
+ *             Version 1 (both)
  *
  *************************************************************************=
*****/
=20
@@ -161,21 +174,29 @@ struct acpi_table_facs {
 	u32 flags;
 	u64 xfirmware_waking_vector;	/* 64-bit version of the Firmware =
Waking Vector (ACPI 2.0+) */
 	u8 version;		/* Version of this table (ACPI 2.0+) */
-	u8 reserved[31];	/* Reserved, must be zero */
+	u8 reserved[3];		/* Reserved, must be zero */
+	u32 ospm_flags;		/* Flags to be set by OSPM (ACPI 4.0) */
+	u8 reserved1[24];	/* Reserved, must be zero */
 };
=20
-/* Flag macros */
+/* Masks for global_lock flag field above */
+
+#define ACPI_GLOCK_PENDING          (1)	/* 00: Pending global lock =
ownership */
+#define ACPI_GLOCK_OWNED            (1<<1)	/* 01: Global lock is =
owned */
=20
-#define ACPI_FACS_S4_BIOS_PRESENT (1)	/* 00: S4BIOS support is present =
*/
+/* Masks for Flags field above  */
=20
-/* Global lock flags */
+#define ACPI_FACS_S4_BIOS_PRESENT   (1)	/* 00: S4BIOS support is =
present */
+#define ACPI_FACS_64BIT_WAKE        (1<<1)	/* 01: 64-bit wake vector =
supported (ACPI 4.0) */
=20
-#define ACPI_GLOCK_PENDING      0x01	/* 00: Pending global lock =
ownership */
-#define ACPI_GLOCK_OWNED        0x02	/* 01: Global lock is owned */
+/* Masks for ospm_flags field above */
+
+#define ACPI_FACS_64BIT_ENVIRONMENT (1)	/* 00: 64-bit wake =
environment is required (ACPI 4.0) */
=20
 /*************************************************************************=
******
  *
  * FADT - Fixed ACPI Description Table (Signature "FACP")
+ *        Version 4
  *
  *************************************************************************=
*****/
=20
@@ -214,11 +235,11 @@ struct acpi_table_fadt {
 	u16 flush_size;		/* Processor's memory cache line width, in =
bytes */
 	u16 flush_stride;	/* Number of flush strides that need to be =
read */
 	u8 duty_offset;		/* Processor duty cycle index in processor'=
s P_CNT reg */
-	u8 duty_width;		/* Processor duty cycle value bit width in =
P_CNT register. */
+	u8 duty_width;		/* Processor duty cycle value bit width in =
P_CNT register */
 	u8 day_alarm;		/* Index to day-of-month alarm in RTC CMOS =
RAM */
 	u8 month_alarm;		/* Index to month-of-year alarm in RTC =
CMOS RAM */
 	u8 century;		/* Index to century in RTC CMOS RAM */
-	u16 boot_flags;		/* IA-PC Boot Architecture Flags. See =
Table 5-10 for description */
+	u16 boot_flags;		/* IA-PC Boot Architecture Flags (see =
below for individual flags) */
 	u8 reserved;		/* Reserved, must be zero */
 	u32 flags;		/* Miscellaneous flag bits (see below for =
individual flags) */
 	struct acpi_generic_address reset_register;	/* 64-bit address =
of the Reset register */
@@ -236,32 +257,41 @@ struct acpi_table_fadt {
 	struct acpi_generic_address xgpe1_block;	/* 64-bit Extended =
General Purpose Event 1 Reg Blk address */
 };
=20
-/* FADT flags */
+/* Masks for FADT Boot Architecture Flags (boot_flags) */
=20
-#define ACPI_FADT_WBINVD            (1)	/* 00: The wbinvd =
instruction works properly */
-#define ACPI_FADT_WBINVD_FLUSH      (1<<1)	/* 01: The wbinvd flushes =
but does not invalidate */
-#define ACPI_FADT_C1_SUPPORTED      (1<<2)	/* 02: All processors =
support C1 state */
-#define ACPI_FADT_C2_MP_SUPPORTED   (1<<3)	/* 03: C2 state works on =
MP system */
-#define ACPI_FADT_POWER_BUTTON      (1<<4)	/* 04: Power button is =
handled as a generic feature */
-#define ACPI_FADT_SLEEP_BUTTON      (1<<5)	/* 05: Sleep button is =
handled as a generic feature, or  not present */
-#define ACPI_FADT_FIXED_RTC         (1<<6)	/* 06: RTC wakeup stat not =
in fixed register space */
-#define ACPI_FADT_S4_RTC_WAKE       (1<<7)	/* 07: RTC wakeup stat not =
possible from S4 */
-#define ACPI_FADT_32BIT_TIMER       (1<<8)	/* 08: tmr_val is 32 bits =
0=3D24-bits */
-#define ACPI_FADT_DOCKING_SUPPORTED (1<<9)	/* 09: Docking supported =
*/
-#define ACPI_FADT_RESET_REGISTER    (1<<10)	/* 10: System reset via =
the FADT RESET_REG supported */
-#define ACPI_FADT_SEALED_CASE       (1<<11)	/* 11: No internal =
expansion capabilities and case is sealed */
-#define ACPI_FADT_HEADLESS          (1<<12)	/* 12: No local video =
capabilities or local input devices */
-#define ACPI_FADT_SLEEP_TYPE        (1<<13)	/* 13: Must execute native =
instruction after writing  SLP_TYPx register */
-#define ACPI_FADT_PCI_EXPRESS_WAKE  (1<<14)	/* 14: System supports =
PCIEXP_WAKE (STS/EN) bits (ACPI 3.0) */
-#define ACPI_FADT_PLATFORM_CLOCK    (1<<15)	/* 15: OSPM should use =
platform-provided timer (ACPI 3.0) */
-#define ACPI_FADT_S4_RTC_VALID      (1<<16)	/* 16: Contents of RTC_STS =
valid after S4 wake (ACPI 3.0) */
-#define ACPI_FADT_REMOTE_POWER_ON   (1<<17)	/* 17: System is compatible=
 with remote power on (ACPI 3.0) */
-#define ACPI_FADT_APIC_CLUSTER      (1<<18)	/* 18: All local APICs =
must use cluster model (ACPI 3.0) */
-#define ACPI_FADT_APIC_PHYSICAL     (1<<19)	/* 19: All local x_aPICs =
must use physical dest mode (ACPI 3.0) */
+#define ACPI_FADT_LEGACY_DEVICES    (1)  	/* 00: [V2] System has LPC =
or ISA bus devices */
+#define ACPI_FADT_8042              (1<<1)	/* 01: [V3] System has an =
8042 controller on port 60/64 */
+#define ACPI_FADT_NO_VGA            (1<<2)	/* 02: [V4] It is not safe =
to probe for VGA hardware */
+#define ACPI_FADT_NO_MSI            (1<<3)	/* 03: [V4] Message =
Signaled Interrupts (MSI) must not be enabled */
+#define ACPI_FADT_NO_ASPM           (1<<4)	/* 04: [V4] PCIe ASPM =
control must not be enabled */
+
+#define FADT2_REVISION_ID               3
+
+/* Masks for FADT flags */
+
+#define ACPI_FADT_WBINVD            (1)	/* 00: [V1] The wbinvd =
instruction works properly */
+#define ACPI_FADT_WBINVD_FLUSH      (1<<1)	/* 01: [V1] wbinvd flushes =
but does not invalidate caches */
+#define ACPI_FADT_C1_SUPPORTED      (1<<2)	/* 02: [V1] All processors =
support C1 state */
+#define ACPI_FADT_C2_MP_SUPPORTED   (1<<3)	/* 03: [V1] C2 state works =
on MP system */
+#define ACPI_FADT_POWER_BUTTON      (1<<4)	/* 04: [V1] Power button =
is handled as a control method device */
+#define ACPI_FADT_SLEEP_BUTTON      (1<<5)	/* 05: [V1] Sleep button =
is handled as a control method device */
+#define ACPI_FADT_FIXED_RTC         (1<<6)	/* 06: [V1] RTC wakeup =
status not in fixed register space */
+#define ACPI_FADT_S4_RTC_WAKE       (1<<7)	/* 07: [V1] RTC alarm can =
wake system from S4 */
+#define ACPI_FADT_32BIT_TIMER       (1<<8)	/* 08: [V1] ACPI timer =
width is 32-bit (0=3D24-bit) */
+#define ACPI_FADT_DOCKING_SUPPORTED (1<<9)	/* 09: [V1] Docking =
supported */
+#define ACPI_FADT_RESET_REGISTER    (1<<10)	/* 10: [V2] System reset =
via the FADT RESET_REG supported */
+#define ACPI_FADT_SEALED_CASE       (1<<11)	/* 11: [V3] No internal =
expansion capabilities and case is sealed */
+#define ACPI_FADT_HEADLESS          (1<<12)	/* 12: [V3] No local video =
capabilities or local input devices */
+#define ACPI_FADT_SLEEP_TYPE        (1<<13)	/* 13: [V3] Must execute =
native instruction after writing  SLP_TYPx register */
+#define ACPI_FADT_PCI_EXPRESS_WAKE  (1<<14)	/* 14: [V4] System =
supports PCIEXP_WAKE (STS/EN) bits (ACPI 3.0) */
+#define ACPI_FADT_PLATFORM_CLOCK    (1<<15)	/* 15: [V4] OSPM should =
use platform-provided timer (ACPI 3.0) */
+#define ACPI_FADT_S4_RTC_VALID      (1<<16)	/* 16: [V4] Contents of =
RTC_STS valid after S4 wake (ACPI 3.0) */
+#define ACPI_FADT_REMOTE_POWER_ON   (1<<17)	/* 17: [V4] System is =
compatible with remote power on (ACPI 3.0) */
+#define ACPI_FADT_APIC_CLUSTER      (1<<18)	/* 18: [V4] All local =
APICs must use cluster model (ACPI 3.0) */
+#define ACPI_FADT_APIC_PHYSICAL     (1<<19)	/* 19: [V4] All local =
x_aPICs must use physical dest mode (ACPI 3.0) */
+
+/* Values for preferred_profile (Preferred Power Management Profiles) */
=20
-/*
- * FADT Prefered Power Management Profiles
- */
 enum acpi_prefered_pm_profiles {
 	PM_UNSPECIFIED =3D 0,
 	PM_DESKTOP =3D 1,
@@ -272,15 +302,6 @@ enum acpi_prefered_pm_profiles {
 	PM_APPLIANCE_PC =3D 6
 };
=20
-/* FADT Boot Arch Flags */
-
-#define BAF_LEGACY_DEVICES              0x0001
-#define BAF_8042_KEYBOARD_CONTROLLER    0x0002
-#define BAF_MSI_NOT_SUPPORTED           0x0008
-
-#define FADT2_REVISION_ID               3
-#define FADT2_MINUS_REVISION_ID         2
-
 /* Reset to default packing */
=20
 #pragma pack()
@@ -292,5 +313,22 @@ enum acpi_prefered_pm_profiles {
  */
=20
 #include <acpi/actbl1.h>
+#include <acpi/actbl2.h>
+
+/*
+ * Sizes of the various flavors of FADT. We need to look closely
+ * at the FADT length because the version number essentially tells
+ * us nothing because of many BIOS bugs where the version does not
+ * match the expected length. In other words, the length of the
+ * FADT is the bottom line as to what the version really is.
+ *
+ * For reference, the values below are as follows:
+ *     FADT V1  size: 0x74
+ *     FADT V2  size: 0x84
+ *     FADT V3+ size: 0xF4
+ */
+#define ACPI_FADT_V1_SIZE       (u32) (ACPI_FADT_OFFSET (flags) + 4)
+#define ACPI_FADT_V2_SIZE       (u32) (ACPI_FADT_OFFSET (reserved4[0]) + =
3)
+#define ACPI_FADT_V3_SIZE       (u32) (sizeof (struct acpi_table_fadt))
=20
 #endif				/* __ACTBL_H__ */
--- a/xen/include/acpi/actbl1.h
+++ b/xen/include/acpi/actbl1.h
@@ -5,7 +5,7 @@
  *************************************************************************=
****/
=20
 /*
- * Copyright (C) 2000 - 2007, R. Byron Moore
+ * Copyright (C) 2000 - 2011, Intel Corp.
  * All rights reserved.
  *
  * Redistribution and use in source and binary forms, with or without
@@ -46,34 +46,31 @@
=20
 /*************************************************************************=
******
  *
- * Additional ACPI Tables
+ * Additional ACPI Tables (1)
  *
  * These tables are not consumed directly by the ACPICA subsystem, but =
are
  * included here to support device drivers and the AML disassembler.
  *
+ * The tables in this file are fully defined within the ACPI specification=
.
+ *
  *************************************************************************=
*****/
=20
 /*
- * Values for description table header signatures. Useful because they =
make
- * it more difficult to inadvertently type in the wrong signature.
+ * Values for description table header signatures for tables defined in =
this
+ * file. Useful because they make it more difficult to inadvertently type =
in
+ * the wrong signature.
  */
-#define ACPI_SIG_ASF            "ASF!"	/* Alert Standard Format table */
-#define ACPI_SIG_BOOT           "BOOT"	/* Simple Boot Flag Table */
+#define ACPI_SIG_BERT           "BERT"	/* Boot Error Record Table */
 #define ACPI_SIG_CPEP           "CPEP"	/* Corrected Platform Error =
Polling table */
-#define ACPI_SIG_ERST           "ERST"  /* Error Record Serialization =
Table */
-#define ACPI_SIG_DBGP           "DBGP"	/* Debug Port table */
-#define ACPI_SIG_DMAR           "DMAR"	/* DMA Remapping table */
 #define ACPI_SIG_ECDT           "ECDT"	/* Embedded Controller Boot =
Resources Table */
-#define ACPI_SIG_HPET           "HPET"	/* High Precision Event Timer =
table */
+#define ACPI_SIG_EINJ           "EINJ"	/* Error Injection table */
+#define ACPI_SIG_ERST           "ERST"	/* Error Record Serialization =
Table */
+#define ACPI_SIG_HEST           "HEST"	/* Hardware Error Source Table */
 #define ACPI_SIG_MADT           "APIC"	/* Multiple APIC Description Table =
*/
-#define ACPI_SIG_MCFG           "MCFG"	/* PCI Memory Mapped Configuration =
table */
+#define ACPI_SIG_MSCT           "MSCT"	/* Maximum System Characteristics =
Table */
 #define ACPI_SIG_SBST           "SBST"	/* Smart Battery Specification =
Table */
 #define ACPI_SIG_SLIT           "SLIT"	/* System Locality Distance =
Information Table */
-#define ACPI_SIG_SPCR           "SPCR"	/* Serial Port Console Redirection =
table */
-#define ACPI_SIG_SPMI           "SPMI"	/* Server Platform Management =
Interface table */
 #define ACPI_SIG_SRAT           "SRAT"	/* System Resource Affinity Table =
*/
-#define ACPI_SIG_TCPA           "TCPA"	/* Trusted Computing Platform =
Alliance table */
-#define ACPI_SIG_WDRT           "WDRT"	/* Watchdog Resource Table */
=20
 /*
  * All tables must be byte-packed to match the ACPI specification, since
@@ -87,7 +84,13 @@
  * portable, so do not use any other bitfield types.
  */
=20
-/* Common Sub-table header (used in MADT, SRAT, etc.) */
+/*************************************************************************=
******
+ *
+ * Common subtable headers
+ *
+ *************************************************************************=
*****/
+
+/* Generic subtable header (used in MADT, SRAT, etc.) */
=20
 struct acpi_subtable_header {
 	u8 type;
@@ -108,128 +111,54 @@ struct acpi_whea_header {
=20
 /*************************************************************************=
******
  *
- * ASF - Alert Standard Format table (Signature "ASF!")
- *
- * Conforms to the Alert Standard Format Specification V2.0, 23 April =
2003
+ * BERT - Boot Error Record Table (ACPI 4.0)
+ *        Version 1
  *
  *************************************************************************=
*****/
=20
-struct acpi_table_asf {
+struct acpi_table_bert {
 	struct acpi_table_header header;	/* Common ACPI table =
header */
+	u32 region_length;	/* Length of the boot error region */
+	u64 address;		/* Physical address of the error region */
 };
=20
-/* ASF subtable header */
-
-struct acpi_asf_header {
-	u8 type;
-	u8 reserved;
-	u16 length;
-};
-
-/* Values for Type field above */
+/* Boot Error Region (not a subtable, pointed to by Address field above) =
*/
=20
-enum acpi_asf_type {
-	ACPI_ASF_TYPE_INFO =3D 0,
-	ACPI_ASF_TYPE_ALERT =3D 1,
-	ACPI_ASF_TYPE_CONTROL =3D 2,
-	ACPI_ASF_TYPE_BOOT =3D 3,
-	ACPI_ASF_TYPE_ADDRESS =3D 4,
-	ACPI_ASF_TYPE_RESERVED =3D 5
+struct acpi_bert_region {
+	u32 block_status;	/* Type of error information */
+	u32 raw_data_offset;	/* Offset to raw error data */
+	u32 raw_data_length;	/* Length of raw error data */
+	u32 data_length;	/* Length of generic error data */
+	u32 error_severity;	/* Severity code */
 };
=20
-/*
- * ASF subtables
- */
+/* Values for block_status flags above */
=20
-/* 0: ASF Information */
+#define ACPI_BERT_UNCORRECTABLE             (1)
+#define ACPI_BERT_CORRECTABLE               (1<<1)
+#define ACPI_BERT_MULTIPLE_UNCORRECTABLE    (1<<2)
+#define ACPI_BERT_MULTIPLE_CORRECTABLE      (1<<3)
+#define ACPI_BERT_ERROR_ENTRY_COUNT         (0xFF<<4)	/* 8 bits, error =
count */
=20
-struct acpi_asf_info {
-	struct acpi_asf_header header;
-	u8 min_reset_value;
-	u8 min_poll_interval;
-	u16 system_id;
-	u32 mfg_id;
-	u8 flags;
-	u8 reserved2[3];
-};
-
-/* 1: ASF Alerts */
+/* Values for error_severity above */
=20
-struct acpi_asf_alert {
-	struct acpi_asf_header header;
-	u8 assert_mask;
-	u8 deassert_mask;
-	u8 alerts;
-	u8 data_length;
-};
-
-struct acpi_asf_alert_data {
-	u8 address;
-	u8 command;
-	u8 mask;
-	u8 value;
-	u8 sensor_type;
-	u8 type;
-	u8 offset;
-	u8 source_type;
-	u8 severity;
-	u8 sensor_number;
-	u8 entity;
-	u8 instance;
+enum acpi_bert_error_severity {
+	ACPI_BERT_ERROR_CORRECTABLE =3D 0,
+	ACPI_BERT_ERROR_FATAL =3D 1,
+	ACPI_BERT_ERROR_CORRECTED =3D 2,
+	ACPI_BERT_ERROR_NONE =3D 3,
+	ACPI_BERT_ERROR_RESERVED =3D 4	/* 4 and greater are reserved */
 };
=20
-/* 2: ASF Remote Control */
-
-struct acpi_asf_remote {
-	struct acpi_asf_header header;
-	u8 controls;
-	u8 data_length;
-	u16 reserved2;
-};
-
-struct acpi_asf_control_data {
-	u8 function;
-	u8 address;
-	u8 command;
-	u8 value;
-};
-
-/* 3: ASF RMCP Boot Options */
-
-struct acpi_asf_rmcp {
-	struct acpi_asf_header header;
-	u8 capabilities[7];
-	u8 completion_code;
-	u32 enterprise_id;
-	u8 command;
-	u16 parameter;
-	u16 boot_options;
-	u16 oem_parameters;
-};
-
-/* 4: ASF Address */
-
-struct acpi_asf_address {
-	struct acpi_asf_header header;
-	u8 eprom_address;
-	u8 devices;
-};
-
-/*************************************************************************=
******
- *
- * BOOT - Simple Boot Flag Table
- *
- *************************************************************************=
*****/
-
-struct acpi_table_boot {
-	struct acpi_table_header header;	/* Common ACPI table =
header */
-	u8 cmos_index;		/* Index in CMOS RAM for the boot register =
*/
-	u8 reserved[3];
-};
+/*
+ * Note: The generic error data that follows the error_severity field =
above
+ * uses the struct acpi_hest_generic_data defined under the HEST table =
below
+ */
=20
 /*************************************************************************=
******
  *
- * CPEP - Corrected Platform Error Polling table
+ * CPEP - Corrected Platform Error Polling table (ACPI 4.0)
+ *        Version 1
  *
  *************************************************************************=
*****/
=20
@@ -241,8 +170,7 @@ struct acpi_table_cpep {
 /* Subtable */
=20
 struct acpi_cpep_polling {
-	u8 type;
-	u8 length;
+	struct acpi_subtable_header header;
 	u8 id;			/* Processor ID */
 	u8 eid;			/* Processor EID */
 	u32 interval;		/* Polling interval (msec) */
@@ -250,116 +178,103 @@ struct acpi_cpep_polling {
=20
 /*************************************************************************=
******
  *
- * DBGP - Debug Port table
+ * ECDT - Embedded Controller Boot Resources Table
+ *        Version 1
  *
  *************************************************************************=
*****/
=20
-struct acpi_table_dbgp {
+struct acpi_table_ecdt {
 	struct acpi_table_header header;	/* Common ACPI table =
header */
-	u8 type;		/* 0=3Dfull 16550, 1=3Dsubset of 16550 */
-	u8 reserved[3];
-	struct acpi_generic_address debug_port;
+	struct acpi_generic_address control;	/* Address of EC command/st=
atus register */
+	struct acpi_generic_address data;	/* Address of EC data =
register */
+	u32 uid;		/* Unique ID - must be same as the EC _UID =
method */
+	u8 gpe;			/* The GPE for the EC */
+	u8 id[1];		/* Full namepath of the EC in the ACPI =
namespace */
 };
=20
 /*************************************************************************=
******
  *
- * DMAR - DMA Remapping table
+ * EINJ - Error Injection Table (ACPI 4.0)
+ *        Version 1
  *
  *************************************************************************=
*****/
=20
-struct acpi_table_dmar {
+struct acpi_table_einj {
 	struct acpi_table_header header;	/* Common ACPI table =
header */
-	u8 width;		/* Host Address Width */
+	u32 header_length;
 	u8 flags;
-	u8 reserved[10];
-};
-
-/* DMAR subtable header */
-
-struct acpi_dmar_header {
-	u16 type;
-	u16 length;
-};
-
-/* Values for subtable type in struct acpi_dmar_header */
-
-enum acpi_dmar_type {
-	ACPI_DMAR_TYPE_HARDWARE_UNIT =3D 0,
-	ACPI_DMAR_TYPE_RESERVED_MEMORY =3D 1,
-	ACPI_DMAR_TYPE_ATSR =3D 2,
-	ACPI_DMAR_TYPE_RESERVED =3D 3	/* 3 and greater are reserved */
-};
-
-struct acpi_dmar_device_scope {
-	u8 entry_type;
-	u8 length;
-	u16 reserved;
-	u8 enumeration_id;
-	u8 bus;
+	u8 reserved[3];
+	u32 entries;
 };
=20
-/* Values for entry_type in struct acpi_dmar_device_scope */
+/* EINJ Injection Instruction Entries (actions) */
=20
-enum acpi_dmar_scope_type {
-	ACPI_DMAR_SCOPE_TYPE_NOT_USED =3D 0,
-	ACPI_DMAR_SCOPE_TYPE_ENDPOINT =3D 1,
-	ACPI_DMAR_SCOPE_TYPE_BRIDGE =3D 2,
-	ACPI_DMAR_SCOPE_TYPE_IOAPIC =3D 3,
-	ACPI_DMAR_SCOPE_TYPE_HPET =3D 4,
-	ACPI_DMAR_SCOPE_TYPE_RESERVED =3D 5	/* 5 and greater are =
reserved */
+struct acpi_einj_entry {
+	struct acpi_whea_header whea_header;	/* Common header for WHEA =
tables */
 };
=20
-struct acpi_dmar_pci_path {
-	u8 dev;
-	u8 fn;
-};
+/* Masks for Flags field above */
=20
-/*
- * DMAR Sub-tables, correspond to Type in struct acpi_dmar_header
- */
+#define ACPI_EINJ_PRESERVE          (1)
=20
-/* 0: Hardware Unit Definition */
+/* Values for Action field above */
=20
-struct acpi_dmar_hardware_unit {
-	struct acpi_dmar_header header;
-	u8 flags;
-	u8 reserved;
-	u16 segment;
-	u64 address;		/* Register Base Address */
+enum acpi_einj_actions {
+	ACPI_EINJ_BEGIN_OPERATION =3D 0,
+	ACPI_EINJ_GET_TRIGGER_TABLE =3D 1,
+	ACPI_EINJ_SET_ERROR_TYPE =3D 2,
+	ACPI_EINJ_GET_ERROR_TYPE =3D 3,
+	ACPI_EINJ_END_OPERATION =3D 4,
+	ACPI_EINJ_EXECUTE_OPERATION =3D 5,
+	ACPI_EINJ_CHECK_BUSY_STATUS =3D 6,
+	ACPI_EINJ_GET_COMMAND_STATUS =3D 7,
+	ACPI_EINJ_ACTION_RESERVED =3D 8,	/* 8 and greater are =
reserved */
+	ACPI_EINJ_TRIGGER_ERROR =3D 0xFF	/* Except for this value =
*/
 };
=20
-/* Flags */
-
-#define ACPI_DMAR_INCLUDE_ALL       (1)
-
-/* 1: Reserved Memory Defininition */
+/* Values for Instruction field above */
=20
-struct acpi_dmar_reserved_memory {
-	struct acpi_dmar_header header;
-	u16 reserved;
-	u16 segment;
-	u64 base_address;		/* 4_k aligned base address */
-	u64 end_address;	/* 4_k aligned limit address */
+enum acpi_einj_instructions {
+	ACPI_EINJ_READ_REGISTER =3D 0,
+	ACPI_EINJ_READ_REGISTER_VALUE =3D 1,
+	ACPI_EINJ_WRITE_REGISTER =3D 2,
+	ACPI_EINJ_WRITE_REGISTER_VALUE =3D 3,
+	ACPI_EINJ_NOOP =3D 4,
+	ACPI_EINJ_INSTRUCTION_RESERVED =3D 5	/* 5 and greater are =
reserved */
+};
+
+/* EINJ Trigger Error Action Table */
+
+struct acpi_einj_trigger {
+	u32 header_size;
+	u32 revision;
+	u32 table_size;
+	u32 entry_count;
 };
=20
-/* Flags */
+/* Command status return values */
=20
-#define ACPI_DMAR_ALLOW_ALL         (1)
-
-/*************************************************************************=
******
- *
- * ECDT - Embedded Controller Boot Resources Table
- *
- *************************************************************************=
*****/
-
-struct acpi_table_ecdt {
-	struct acpi_table_header header;	/* Common ACPI table =
header */
-	struct acpi_generic_address control;	/* Address of EC command/st=
atus register */
-	struct acpi_generic_address data;	/* Address of EC data =
register */
-	u32 uid;		/* Unique ID - must be same as the EC _UID =
method */
-	u8 gpe;			/* The GPE for the EC */
-	u8 id[1];		/* Full namepath of the EC in the ACPI =
namespace */
-};
+enum acpi_einj_command_status {
+	ACPI_EINJ_SUCCESS =3D 0,
+	ACPI_EINJ_FAILURE =3D 1,
+	ACPI_EINJ_INVALID_ACCESS =3D 2,
+	ACPI_EINJ_STATUS_RESERVED =3D 3	/* 3 and greater are reserved */
+};
+
+/* Error types returned from ACPI_EINJ_GET_ERROR_TYPE (bitfield) */
+
+#define ACPI_EINJ_PROCESSOR_CORRECTABLE     (1)
+#define ACPI_EINJ_PROCESSOR_UNCORRECTABLE   (1<<1)
+#define ACPI_EINJ_PROCESSOR_FATAL           (1<<2)
+#define ACPI_EINJ_MEMORY_CORRECTABLE        (1<<3)
+#define ACPI_EINJ_MEMORY_UNCORRECTABLE      (1<<4)
+#define ACPI_EINJ_MEMORY_FATAL              (1<<5)
+#define ACPI_EINJ_PCIX_CORRECTABLE          (1<<6)
+#define ACPI_EINJ_PCIX_UNCORRECTABLE        (1<<7)
+#define ACPI_EINJ_PCIX_FATAL                (1<<8)
+#define ACPI_EINJ_PLATFORM_CORRECTABLE      (1<<9)
+#define ACPI_EINJ_PLATFORM_UNCORRECTABLE    (1<<10)
+#define ACPI_EINJ_PLATFORM_FATAL            (1<<11)
=20
 /*************************************************************************=
******
  *
@@ -453,30 +368,237 @@ struct acpi_erst_info {
=20
 /*************************************************************************=
******
  *
- * HPET - High Precision Event Timer table
+ * HEST - Hardware Error Source Table (ACPI 4.0)
+ *        Version 1
  *
  *************************************************************************=
*****/
=20
-struct acpi_table_hpet {
+struct acpi_table_hest {
 	struct acpi_table_header header;	/* Common ACPI table =
header */
-	u32 id;			/* Hardware ID of event timer block */
-	struct acpi_generic_address address;	/* Address of event timer =
block */
-	u8 sequence;		/* HPET sequence number */
-	u16 minimum_tick;	/* Main counter min tick, periodic mode */
+	u32 error_source_count;
+};
+
+/* HEST subtable header */
+
+struct acpi_hest_header {
+	u16 type;
+	u16 source_id;
+};
+
+/* Values for Type field above for subtables */
+
+enum acpi_hest_types {
+	ACPI_HEST_TYPE_IA32_CHECK =3D 0,
+	ACPI_HEST_TYPE_IA32_CORRECTED_CHECK =3D 1,
+	ACPI_HEST_TYPE_IA32_NMI =3D 2,
+	ACPI_HEST_TYPE_NOT_USED3 =3D 3,
+	ACPI_HEST_TYPE_NOT_USED4 =3D 4,
+	ACPI_HEST_TYPE_NOT_USED5 =3D 5,
+	ACPI_HEST_TYPE_AER_ROOT_PORT =3D 6,
+	ACPI_HEST_TYPE_AER_ENDPOINT =3D 7,
+	ACPI_HEST_TYPE_AER_BRIDGE =3D 8,
+	ACPI_HEST_TYPE_GENERIC_ERROR =3D 9,
+	ACPI_HEST_TYPE_RESERVED =3D 10	/* 10 and greater are reserved */
+};
+
+/*
+ * HEST substructures contained in subtables
+ */
+
+/*
+ * IA32 Error Bank(s) - Follows the struct acpi_hest_ia_machine_check and
+ * struct acpi_hest_ia_corrected structures.
+ */
+struct acpi_hest_ia_error_bank {
+	u8 bank_number;
+	u8 clear_status_on_init;
+	u8 status_format;
+	u8 reserved;
+	u32 control_register;
+	u64 control_data;
+	u32 status_register;
+	u32 address_register;
+	u32 misc_register;
+};
+
+/* Common HEST sub-structure for PCI/AER structures below (6,7,8) */
+
+struct acpi_hest_aer_common {
+	u16 reserved1;
 	u8 flags;
+	u8 enabled;
+	u32 records_to_preallocate;
+	u32 max_sections_per_record;
+	u32 bus;
+	u16 device;
+	u16 function;
+	u16 device_control;
+	u16 reserved2;
+	u32 uncorrectable_mask;
+	u32 uncorrectable_severity;
+	u32 correctable_mask;
+	u32 advanced_capabilities;
 };
=20
-/*! Flags */
+/* Masks for HEST Flags fields */
+
+#define ACPI_HEST_FIRMWARE_FIRST        (1)
+#define ACPI_HEST_GLOBAL                (1<<1)
=20
-#define ACPI_HPET_PAGE_PROTECT      (1)	/* 00: No page protection =
*/
-#define ACPI_HPET_PAGE_PROTECT_4    (1<<1)	/* 01: 4KB page protected =
*/
-#define ACPI_HPET_PAGE_PROTECT_64   (1<<2)	/* 02: 64KB page protected =
*/
+/* Hardware Error Notification */
=20
-/*! [End] no source code translation !*/
+struct acpi_hest_notify {
+	u8 type;
+	u8 length;
+	u16 config_write_enable;
+	u32 poll_interval;
+	u32 vector;
+	u32 polling_threshold_value;
+	u32 polling_threshold_window;
+	u32 error_threshold_value;
+	u32 error_threshold_window;
+};
+
+/* Values for Notify Type field above */
+
+enum acpi_hest_notify_types {
+	ACPI_HEST_NOTIFY_POLLED =3D 0,
+	ACPI_HEST_NOTIFY_EXTERNAL =3D 1,
+	ACPI_HEST_NOTIFY_LOCAL =3D 2,
+	ACPI_HEST_NOTIFY_SCI =3D 3,
+	ACPI_HEST_NOTIFY_NMI =3D 4,
+	ACPI_HEST_NOTIFY_RESERVED =3D 5	/* 5 and greater are reserved */
+};
+
+/* Values for config_write_enable bitfield above */
+
+#define ACPI_HEST_TYPE                  (1)
+#define ACPI_HEST_POLL_INTERVAL         (1<<1)
+#define ACPI_HEST_POLL_THRESHOLD_VALUE  (1<<2)
+#define ACPI_HEST_POLL_THRESHOLD_WINDOW (1<<3)
+#define ACPI_HEST_ERR_THRESHOLD_VALUE   (1<<4)
+#define ACPI_HEST_ERR_THRESHOLD_WINDOW  (1<<5)
+
+/*
+ * HEST subtables
+ */
+
+/* 0: IA32 Machine Check Exception */
+
+struct acpi_hest_ia_machine_check {
+	struct acpi_hest_header header;
+	u16 reserved1;
+	u8 flags;
+	u8 enabled;
+	u32 records_to_preallocate;
+	u32 max_sections_per_record;
+	u64 global_capability_data;
+	u64 global_control_data;
+	u8 num_hardware_banks;
+	u8 reserved3[7];
+};
+
+/* 1: IA32 Corrected Machine Check */
+
+struct acpi_hest_ia_corrected {
+	struct acpi_hest_header header;
+	u16 reserved1;
+	u8 flags;
+	u8 enabled;
+	u32 records_to_preallocate;
+	u32 max_sections_per_record;
+	struct acpi_hest_notify notify;
+	u8 num_hardware_banks;
+	u8 reserved2[3];
+};
+
+/* 2: IA32 Non-Maskable Interrupt */
+
+struct acpi_hest_ia_nmi {
+	struct acpi_hest_header header;
+	u32 reserved;
+	u32 records_to_preallocate;
+	u32 max_sections_per_record;
+	u32 max_raw_data_length;
+};
+
+/* 3,4,5: Not used */
+
+/* 6: PCI Express Root Port AER */
+
+struct acpi_hest_aer_root {
+	struct acpi_hest_header header;
+	struct acpi_hest_aer_common aer;
+	u32 root_error_command;
+};
+
+/* 7: PCI Express AER (AER Endpoint) */
+
+struct acpi_hest_aer {
+	struct acpi_hest_header header;
+	struct acpi_hest_aer_common aer;
+};
+
+/* 8: PCI Express/PCI-X Bridge AER */
+
+struct acpi_hest_aer_bridge {
+	struct acpi_hest_header header;
+	struct acpi_hest_aer_common aer;
+	u32 uncorrectable_mask2;
+	u32 uncorrectable_severity2;
+	u32 advanced_capabilities2;
+};
+
+/* 9: Generic Hardware Error Source */
+
+struct acpi_hest_generic {
+	struct acpi_hest_header header;
+	u16 related_source_id;
+	u8 reserved;
+	u8 enabled;
+	u32 records_to_preallocate;
+	u32 max_sections_per_record;
+	u32 max_raw_data_length;
+	struct acpi_generic_address error_status_address;
+	struct acpi_hest_notify notify;
+	u32 error_block_length;
+};
+
+/* Generic Error Status block */
+
+struct acpi_hest_generic_status {
+	u32 block_status;
+	u32 raw_data_offset;
+	u32 raw_data_length;
+	u32 data_length;
+	u32 error_severity;
+};
+
+/* Values for block_status flags above */
+
+#define ACPI_HEST_UNCORRECTABLE             (1)
+#define ACPI_HEST_CORRECTABLE               (1<<1)
+#define ACPI_HEST_MULTIPLE_UNCORRECTABLE    (1<<2)
+#define ACPI_HEST_MULTIPLE_CORRECTABLE      (1<<3)
+#define ACPI_HEST_ERROR_ENTRY_COUNT         (0xFF<<4)	/* 8 bits, error =
count */
+
+/* Generic Error Data entry */
+
+struct acpi_hest_generic_data {
+	u8 section_type[16];
+	u32 error_severity;
+	u16 revision;
+	u8 validation_bits;
+	u8 flags;
+	u32 error_data_length;
+	u8 fru_id[16];
+	u8 fru_text[20];
+};
=20
 /*************************************************************************=
******
  *
  * MADT - Multiple APIC Description Table
+ *        Version 3
  *
  *************************************************************************=
*****/
=20
@@ -486,7 +608,7 @@ struct acpi_table_madt {
 	u32 flags;
 };
=20
-/* Flags */
+/* Masks for Flags field above */
=20
 #define ACPI_MADT_PCAT_COMPAT       (1)	/* 00:    System also has =
dual 8259s */
=20
@@ -495,7 +617,7 @@ struct acpi_table_madt {
 #define ACPI_MADT_DUAL_PIC          0
 #define ACPI_MADT_MULTIPLE_APIC     1
=20
-/* Values for subtable type in struct acpi_subtable_header */
+/* Values for MADT subtable type in struct acpi_subtable_header */
=20
 enum acpi_madt_type {
 	ACPI_MADT_TYPE_LOCAL_APIC =3D 0,
@@ -606,7 +728,7 @@ struct acpi_madt_interrupt_source {
 	u32 flags;		/* Interrupt Source Flags */
 };
=20
-/* Flags field above */
+/* Masks for Flags field above */
=20
 #define ACPI_MADT_CPEI_OVERRIDE     (1)
=20
@@ -615,9 +737,9 @@ struct acpi_madt_interrupt_source {
 struct acpi_madt_local_x2apic {
 	struct acpi_subtable_header header;
 	u16 reserved;		/* Reserved - must be zero */
-	u32 local_apic_id;	/* Processor X2_APIC ID  */
+	u32 local_apic_id;	/* Processor x2APIC ID  */
 	u32 lapic_flags;
-	u32 uid;		/* Extended X2_APIC processor ID */
+	u32 uid;		/* ACPI processor UID */
 };
=20
 /* 10: Local X2APIC NMI (ACPI 4.0) */
@@ -625,7 +747,7 @@ struct acpi_madt_local_x2apic {
 struct acpi_madt_local_x2apic_nmi {
 	struct acpi_subtable_header header;
 	u16 inti_flags;
-	u32 uid;		/* Processor X2_APIC ID */
+	u32 uid;		/* ACPI processor UID */
 	u8 lint;		/* LINTn to which NMI is connected */
 	u8 reserved[3];
 };
@@ -657,28 +779,34 @@ struct acpi_madt_local_x2apic_nmi {
=20
 /*************************************************************************=
******
  *
- * MCFG - PCI Memory Mapped Configuration table and sub-table
+ * MSCT - Maximum System Characteristics Table (ACPI 4.0)
+ *        Version 1
  *
  *************************************************************************=
*****/
=20
-struct acpi_table_mcfg {
+struct acpi_table_msct {
 	struct acpi_table_header header;	/* Common ACPI table =
header */
-	u8 reserved[8];
+	u32 proximity_offset;	/* Location of proximity info struct(s) */
+	u32 max_proximity_domains;	/* Max number of proximity domains =
*/
+	u32 max_clock_domains;	/* Max number of clock domains */
+	u64 max_address;	/* Max physical address in system */
 };
=20
-/* Subtable */
+/* Subtable - Maximum Proximity Domain Information. Version 1 */
=20
-struct acpi_mcfg_allocation {
-	u64 address;		/* Base address, processor-relative */
-	u16 pci_segment;	/* PCI segment group number */
-	u8 start_bus_number;	/* Starting PCI Bus number */
-	u8 end_bus_number;	/* Final PCI Bus number */
-	u32 reserved;
+struct acpi_msct_proximity {
+	u8 revision;
+	u8 length;
+	u32 range_start;	/* Start of domain range */
+	u32 range_end;		/* End of domain range */
+	u32 processor_capacity;
+	u64 memory_capacity;	/* In bytes */
 };
=20
 /*************************************************************************=
******
  *
  * SBST - Smart Battery Specification Table
+ *        Version 1
  *
  *************************************************************************=
*****/
=20
@@ -692,6 +820,7 @@ struct acpi_table_sbst {
 /*************************************************************************=
******
  *
  * SLIT - System Locality Distance Information Table
+ *        Version 1
  *
  *************************************************************************=
*****/
=20
@@ -703,60 +832,8 @@ struct acpi_table_slit {
=20
 /*************************************************************************=
******
  *
- * SPCR - Serial Port Console Redirection table
- *
- *************************************************************************=
*****/
-
-struct acpi_table_spcr {
-	struct acpi_table_header header;	/* Common ACPI table =
header */
-	u8 interface_type;	/* 0=3Dfull 16550, 1=3Dsubset of 16550 */
-	u8 reserved[3];
-	struct acpi_generic_address serial_port;
-	u8 interrupt_type;
-	u8 pc_interrupt;
-	u32 interrupt;
-	u8 baud_rate;
-	u8 parity;
-	u8 stop_bits;
-	u8 flow_control;
-	u8 terminal_type;
-	u8 reserved1;
-	u16 pci_device_id;
-	u16 pci_vendor_id;
-	u8 pci_bus;
-	u8 pci_device;
-	u8 pci_function;
-	u32 pci_flags;
-	u8 pci_segment;
-	u32 reserved2;
-};
-
-/*************************************************************************=
******
- *
- * SPMI - Server Platform Management Interface table
- *
- *************************************************************************=
*****/
-
-struct acpi_table_spmi {
-	struct acpi_table_header header;	/* Common ACPI table =
header */
-	u8 reserved;
-	u8 interface_type;
-	u16 spec_revision;	/* Version of IPMI */
-	u8 interrupt_type;
-	u8 gpe_number;		/* GPE assigned */
-	u8 reserved1;
-	u8 pci_device_flag;
-	u32 interrupt;
-	struct acpi_generic_address ipmi_register;
-	u8 pci_segment;
-	u8 pci_bus;
-	u8 pci_device;
-	u8 pci_function;
-};
-
-/*************************************************************************=
******
- *
  * SRAT - System Resource Affinity Table
+ *        Version 3
  *
  *************************************************************************=
*****/
=20
@@ -775,7 +852,9 @@ enum acpi_srat_type {
 	ACPI_SRAT_TYPE_RESERVED =3D 3	/* 3 and greater are reserved */
 };
=20
-/* SRAT sub-tables */
+/*
+ * SRAT Sub-tables, correspond to Type in struct acpi_subtable_header
+ */
=20
 /* 0: Processor Local APIC/SAPIC Affinity */
=20
@@ -789,6 +868,10 @@ struct acpi_srat_cpu_affinity {
 	u32 reserved;		/* Reserved, must be zero */
 };
=20
+/* Flags */
+
+#define ACPI_SRAT_CPU_USE_AFFINITY  (1)	/* 00: Use affinity =
structure */
+
 /* 1: Memory Affinity */
=20
 struct acpi_srat_mem_affinity {
@@ -797,9 +880,9 @@ struct acpi_srat_mem_affinity {
 	u16 reserved;		/* Reserved, must be zero */
 	u64 base_address;
 	u64 length;
-	u32 memory_type;	/* See acpi_address_range_id */
+	u32 reserved1;
 	u32 flags;
-	u64 reserved1;		/* Reserved, must be zero */
+	u64 reserved2;		/* Reserved, must be zero */
 };
=20
 /* Flags */
@@ -824,44 +907,6 @@ struct acpi_srat_x2apic_cpu_affinity {
=20
 #define ACPI_SRAT_CPU_ENABLED       (1)	/* 00: Use affinity =
structure */
=20
-/*************************************************************************=
******
- *
- * TCPA - Trusted Computing Platform Alliance table
- *
- *************************************************************************=
*****/
-
-struct acpi_table_tcpa {
-	struct acpi_table_header header;	/* Common ACPI table =
header */
-	u16 reserved;
-	u32 max_log_length;	/* Maximum length for the event log area =
*/
-	u64 log_address;	/* Address of the event log area */
-};
-
-/*************************************************************************=
******
- *
- * WDRT - Watchdog Resource Table
- *
- *************************************************************************=
*****/
-
-struct acpi_table_wdrt {
-	struct acpi_table_header header;	/* Common ACPI table =
header */
-	u32 header_length;	/* Watchdog Header Length */
-	u8 pci_segment;		/* PCI Segment number */
-	u8 pci_bus;		/* PCI Bus number */
-	u8 pci_device;		/* PCI Device number */
-	u8 pci_function;	/* PCI Function number */
-	u32 timer_period;	/* Period of one timer count (msec) */
-	u32 max_count;		/* Maximum counter value supported */
-	u32 min_count;		/* Minimum counter value */
-	u8 flags;
-	u8 reserved[3];
-	u32 entries;		/* Number of watchdog entries that follow =
*/
-};
-
-/* Flags */
-
-#define ACPI_WDRT_TIMER_ENABLED     (1)	/* 00: Timer enabled */
-
 /* Reset to default packing */
=20
 #pragma pack()
--- /dev/null
+++ a/xen/include/acpi/actbl2.h
@@ -0,0 +1,1050 @@
+/*************************************************************************=
*****
+ *
+ * Name: actbl2.h - ACPI Table Definitions (tables not in ACPI spec)
+ *
+ *************************************************************************=
****/
+
+/*
+ * Copyright (C) 2000 - 2011, 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:
+ * 1. Redistributions of source code must retain the above copyright
+ *    notice, this list of conditions, and the following disclaimer,
+ *    without modification.
+ * 2. Redistributions in binary form must reproduce at minimum a =
disclaimer
+ *    substantially similar to the "NO WARRANTY" disclaimer below
+ *    ("Disclaimer") and any redistribution must be conditioned upon
+ *    including a substantially similar Disclaimer requirement for =
further
+ *    binary redistribution.
+ * 3. Neither the names of the above-listed copyright holders nor the =
names
+ *    of any contributors may be used to endorse or promote products =
derived
+ *    from this software without specific prior written permission.
+ *
+ * Alternatively, this software may be distributed under the terms of the
+ * GNU General Public License ("GPL") version 2 as published by the Free
+ * Software Foundation.
+ *
+ * NO WARRANTY
+ * 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 MERCHANTIBILITY AND FITNESS FOR
+ * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ * HOLDERS OR CONTRIBUTORS BE LIABLE FOR SPECIAL, EXEMPLARY, OR CONSEQUENT=
IAL
+ * 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 DAMAGES.
+ */
+
+#ifndef __ACTBL2_H__
+#define __ACTBL2_H__
+
+/*************************************************************************=
******
+ *
+ * Additional ACPI Tables (2)
+ *
+ * These tables are not consumed directly by the ACPICA subsystem, but =
are
+ * included here to support device drivers and the AML disassembler.
+ *
+ * The tables in this file are defined by third-party specifications, and =
are
+ * not defined directly by the ACPI specification itself.
+ *
+ *************************************************************************=
*****/
+
+/*
+ * Values for description table header signatures for tables defined in =
this
+ * file. Useful because they make it more difficult to inadvertently type =
in
+ * the wrong signature.
+ */
+#define ACPI_SIG_ASF            "ASF!"	/* Alert Standard Format table */
+#define ACPI_SIG_BOOT           "BOOT"	/* Simple Boot Flag Table */
+#define ACPI_SIG_DBGP           "DBGP"	/* Debug Port table */
+#define ACPI_SIG_DMAR           "DMAR"	/* DMA Remapping table */
+#define ACPI_SIG_HPET           "HPET"	/* High Precision Event Timer =
table */
+#define ACPI_SIG_IBFT           "IBFT"	/* i_sCSI Boot Firmware Table */
+#define ACPI_SIG_IVRS           "IVRS"	/* I/O Virtualization Reporting =
Structure */
+#define ACPI_SIG_MCFG           "MCFG"	/* PCI Memory Mapped Configuration =
table */
+#define ACPI_SIG_MCHI           "MCHI"	/* Management Controller Host =
Interface table */
+#define ACPI_SIG_SLIC           "SLIC"	/* Software Licensing Description =
Table */
+#define ACPI_SIG_SPCR           "SPCR"	/* Serial Port Console Redirection =
table */
+#define ACPI_SIG_SPMI           "SPMI"	/* Server Platform Management =
Interface table */
+#define ACPI_SIG_TCPA           "TCPA"	/* Trusted Computing Platform =
Alliance table */
+#define ACPI_SIG_UEFI           "UEFI"	/* Uefi Boot Optimization Table */
+#define ACPI_SIG_WAET           "WAET"	/* Windows ACPI Emulated devices =
Table */
+#define ACPI_SIG_WDAT           "WDAT"	/* Watchdog Action Table */
+#define ACPI_SIG_WDDT           "WDDT"	/* Watchdog Timer Description =
Table */
+#define ACPI_SIG_WDRT           "WDRT"	/* Watchdog Resource Table */
+
+#ifdef ACPI_UNDEFINED_TABLES
+/*
+ * These tables have been seen in the field, but no definition has been =
found
+ */
+#define ACPI_SIG_ATKG           "ATKG"
+#define ACPI_SIG_GSCI           "GSCI"	/* GMCH SCI table */
+#define ACPI_SIG_IEIT           "IEIT"
+#endif
+
+/*
+ * All tables must be byte-packed to match the ACPI specification, since
+ * the tables are provided by the system BIOS.
+ */
+#pragma pack(1)
+
+/*
+ * Note about bitfields: The u8 type is used for bitfields in ACPI =
tables.
+ * This is the only type that is even remotely portable. Anything else is =
not
+ * portable, so do not use any other bitfield types.
+ */
+
+/*************************************************************************=
******
+ *
+ * ASF - Alert Standard Format table (Signature "ASF!")
+ *       Revision 0x10
+ *
+ * Conforms to the Alert Standard Format Specification V2.0, 23 April =
2003
+ *
+ *************************************************************************=
*****/
+
+struct acpi_table_asf {
+	struct acpi_table_header header;	/* Common ACPI table =
header */
+};
+
+/* ASF subtable header */
+
+struct acpi_asf_header {
+	u8 type;
+	u8 reserved;
+	u16 length;
+};
+
+/* Values for Type field above */
+
+enum acpi_asf_type {
+	ACPI_ASF_TYPE_INFO =3D 0,
+	ACPI_ASF_TYPE_ALERT =3D 1,
+	ACPI_ASF_TYPE_CONTROL =3D 2,
+	ACPI_ASF_TYPE_BOOT =3D 3,
+	ACPI_ASF_TYPE_ADDRESS =3D 4,
+	ACPI_ASF_TYPE_RESERVED =3D 5
+};
+
+/*
+ * ASF subtables
+ */
+
+/* 0: ASF Information */
+
+struct acpi_asf_info {
+	struct acpi_asf_header header;
+	u8 min_reset_value;
+	u8 min_poll_interval;
+	u16 system_id;
+	u32 mfg_id;
+	u8 flags;
+	u8 reserved2[3];
+};
+
+/* Masks for Flags field above */
+
+#define ACPI_ASF_SMBUS_PROTOCOLS    (1)
+
+/* 1: ASF Alerts */
+
+struct acpi_asf_alert {
+	struct acpi_asf_header header;
+	u8 assert_mask;
+	u8 deassert_mask;
+	u8 alerts;
+	u8 data_length;
+};
+
+struct acpi_asf_alert_data {
+	u8 address;
+	u8 command;
+	u8 mask;
+	u8 value;
+	u8 sensor_type;
+	u8 type;
+	u8 offset;
+	u8 source_type;
+	u8 severity;
+	u8 sensor_number;
+	u8 entity;
+	u8 instance;
+};
+
+/* 2: ASF Remote Control */
+
+struct acpi_asf_remote {
+	struct acpi_asf_header header;
+	u8 controls;
+	u8 data_length;
+	u16 reserved2;
+};
+
+struct acpi_asf_control_data {
+	u8 function;
+	u8 address;
+	u8 command;
+	u8 value;
+};
+
+/* 3: ASF RMCP Boot Options */
+
+struct acpi_asf_rmcp {
+	struct acpi_asf_header header;
+	u8 capabilities[7];
+	u8 completion_code;
+	u32 enterprise_id;
+	u8 command;
+	u16 parameter;
+	u16 boot_options;
+	u16 oem_parameters;
+};
+
+/* 4: ASF Address */
+
+struct acpi_asf_address {
+	struct acpi_asf_header header;
+	u8 eprom_address;
+	u8 devices;
+};
+
+/*************************************************************************=
******
+ *
+ * BOOT - Simple Boot Flag Table
+ *        Version 1
+ *
+ * Conforms to the "Simple Boot Flag Specification", Version 2.1
+ *
+ *************************************************************************=
*****/
+
+struct acpi_table_boot {
+	struct acpi_table_header header;	/* Common ACPI table =
header */
+	u8 cmos_index;		/* Index in CMOS RAM for the boot register =
*/
+	u8 reserved[3];
+};
+
+/*************************************************************************=
******
+ *
+ * DBGP - Debug Port table
+ *        Version 1
+ *
+ * Conforms to the "Debug Port Specification", Version 1.00, 2/9/2000
+ *
+ *************************************************************************=
*****/
+
+struct acpi_table_dbgp {
+	struct acpi_table_header header;	/* Common ACPI table =
header */
+	u8 type;		/* 0=3Dfull 16550, 1=3Dsubset of 16550 */
+	u8 reserved[3];
+	struct acpi_generic_address debug_port;
+};
+
+/*************************************************************************=
******
+ *
+ * DMAR - DMA Remapping table
+ *        Version 1
+ *
+ * Conforms to "Intel Virtualization Technology for Directed I/O",
+ * Version 1.2, Sept. 2008
+ *
+ *************************************************************************=
*****/
+
+struct acpi_table_dmar {
+	struct acpi_table_header header;	/* Common ACPI table =
header */
+	u8 width;		/* Host Address Width */
+	u8 flags;
+	u8 reserved[10];
+};
+
+/* Masks for Flags field above */
+
+#define ACPI_DMAR_INTR_REMAP        (1)
+#define ACPI_DMAR_X2APIC_OPT_OUT    (1<<1)
+
+/* DMAR subtable header */
+
+struct acpi_dmar_header {
+	u16 type;
+	u16 length;
+};
+
+/* Values for subtable type in struct acpi_dmar_header */
+
+enum acpi_dmar_type {
+	ACPI_DMAR_TYPE_HARDWARE_UNIT =3D 0,
+	ACPI_DMAR_TYPE_RESERVED_MEMORY =3D 1,
+	ACPI_DMAR_TYPE_ATSR =3D 2,
+	ACPI_DMAR_HARDWARE_AFFINITY =3D 3,
+	ACPI_DMAR_TYPE_RESERVED =3D 4	/* 4 and greater are reserved */
+};
+
+/* DMAR Device Scope structure */
+
+struct acpi_dmar_device_scope {
+	u8 entry_type;
+	u8 length;
+	u16 reserved;
+	u8 enumeration_id;
+	u8 bus;
+};
+
+/* Values for entry_type in struct acpi_dmar_device_scope */
+
+enum acpi_dmar_scope_type {
+	ACPI_DMAR_SCOPE_TYPE_NOT_USED =3D 0,
+	ACPI_DMAR_SCOPE_TYPE_ENDPOINT =3D 1,
+	ACPI_DMAR_SCOPE_TYPE_BRIDGE =3D 2,
+	ACPI_DMAR_SCOPE_TYPE_IOAPIC =3D 3,
+	ACPI_DMAR_SCOPE_TYPE_HPET =3D 4,
+	ACPI_DMAR_SCOPE_TYPE_RESERVED =3D 5	/* 5 and greater are =
reserved */
+};
+
+struct acpi_dmar_pci_path {
+	u8 dev;
+	u8 fn;
+};
+
+/*
+ * DMAR Sub-tables, correspond to Type in struct acpi_dmar_header
+ */
+
+/* 0: Hardware Unit Definition */
+
+struct acpi_dmar_hardware_unit {
+	struct acpi_dmar_header header;
+	u8 flags;
+	u8 reserved;
+	u16 segment;
+	u64 address;		/* Register Base Address */
+};
+
+/* Masks for Flags field above */
+
+#define ACPI_DMAR_INCLUDE_ALL       (1)
+
+/* 1: Reserved Memory Defininition */
+
+struct acpi_dmar_reserved_memory {
+	struct acpi_dmar_header header;
+	u16 reserved;
+	u16 segment;
+	u64 base_address;	/* 4_k aligned base address */
+	u64 end_address;	/* 4_k aligned limit address */
+};
+
+/* Masks for Flags field above */
+
+#define ACPI_DMAR_ALLOW_ALL         (1)
+
+/* 2: Root Port ATS Capability Reporting Structure */
+
+struct acpi_dmar_atsr {
+	struct acpi_dmar_header header;
+	u8 flags;
+	u8 reserved;
+	u16 segment;
+};
+
+/* Masks for Flags field above */
+
+#define ACPI_DMAR_ALL_PORTS         (1)
+
+/* 3: Remapping Hardware Static Affinity Structure */
+
+struct acpi_dmar_rhsa {
+	struct acpi_dmar_header header;
+	u32 reserved;
+	u64 base_address;
+	u32 proximity_domain;
+};
+
+/*************************************************************************=
******
+ *
+ * HPET - High Precision Event Timer table
+ *        Version 1
+ *
+ * Conforms to "IA-PC HPET (High Precision Event Timers) Specification",
+ * Version 1.0a, October 2004
+ *
+ *************************************************************************=
*****/
+
+struct acpi_table_hpet {
+	struct acpi_table_header header;	/* Common ACPI table =
header */
+	u32 id;			/* Hardware ID of event timer block */
+	struct acpi_generic_address address;	/* Address of event timer =
block */
+	u8 sequence;		/* HPET sequence number */
+	u16 minimum_tick;	/* Main counter min tick, periodic mode */
+	u8 flags;
+};
+
+/* Masks for Flags field above */
+
+#define ACPI_HPET_PAGE_PROTECT_MASK (3)
+
+/* Values for Page Protect flags */
+
+enum acpi_hpet_page_protect {
+	ACPI_HPET_NO_PAGE_PROTECT =3D 0,
+	ACPI_HPET_PAGE_PROTECT4 =3D 1,
+	ACPI_HPET_PAGE_PROTECT64 =3D 2
+};
+
+/*************************************************************************=
******
+ *
+ * IBFT - Boot Firmware Table
+ *        Version 1
+ *
+ * Conforms to "iSCSI Boot Firmware Table (iBFT) as Defined in ACPI 3.0b
+ * Specification", Version 1.01, March 1, 2007
+ *
+ * Note: It appears that this table is not intended to appear in the =
RSDT/XSDT.
+ * Therefore, it is not currently supported by the disassembler.
+ *
+ *************************************************************************=
*****/
+
+struct acpi_table_ibft {
+	struct acpi_table_header header;	/* Common ACPI table =
header */
+	u8 reserved[12];
+};
+
+/* IBFT common subtable header */
+
+struct acpi_ibft_header {
+	u8 type;
+	u8 version;
+	u16 length;
+	u8 index;
+	u8 flags;
+};
+
+/* Values for Type field above */
+
+enum acpi_ibft_type {
+	ACPI_IBFT_TYPE_NOT_USED =3D 0,
+	ACPI_IBFT_TYPE_CONTROL =3D 1,
+	ACPI_IBFT_TYPE_INITIATOR =3D 2,
+	ACPI_IBFT_TYPE_NIC =3D 3,
+	ACPI_IBFT_TYPE_TARGET =3D 4,
+	ACPI_IBFT_TYPE_EXTENSIONS =3D 5,
+	ACPI_IBFT_TYPE_RESERVED =3D 6	/* 6 and greater are reserved */
+};
+
+/* IBFT subtables */
+
+struct acpi_ibft_control {
+	struct acpi_ibft_header header;
+	u16 extensions;
+	u16 initiator_offset;
+	u16 nic0_offset;
+	u16 target0_offset;
+	u16 nic1_offset;
+	u16 target1_offset;
+};
+
+struct acpi_ibft_initiator {
+	struct acpi_ibft_header header;
+	u8 sns_server[16];
+	u8 slp_server[16];
+	u8 primary_server[16];
+	u8 secondary_server[16];
+	u16 name_length;
+	u16 name_offset;
+};
+
+struct acpi_ibft_nic {
+	struct acpi_ibft_header header;
+	u8 ip_address[16];
+	u8 subnet_mask_prefix;
+	u8 origin;
+	u8 gateway[16];
+	u8 primary_dns[16];
+	u8 secondary_dns[16];
+	u8 dhcp[16];
+	u16 vlan;
+	u8 mac_address[6];
+	u16 pci_address;
+	u16 name_length;
+	u16 name_offset;
+};
+
+struct acpi_ibft_target {
+	struct acpi_ibft_header header;
+	u8 target_ip_address[16];
+	u16 target_ip_socket;
+	u8 target_boot_lun[8];
+	u8 chap_type;
+	u8 nic_association;
+	u16 target_name_length;
+	u16 target_name_offset;
+	u16 chap_name_length;
+	u16 chap_name_offset;
+	u16 chap_secret_length;
+	u16 chap_secret_offset;
+	u16 reverse_chap_name_length;
+	u16 reverse_chap_name_offset;
+	u16 reverse_chap_secret_length;
+	u16 reverse_chap_secret_offset;
+};
+
+/*************************************************************************=
******
+ *
+ * IVRS - I/O Virtualization Reporting Structure
+ *        Version 1
+ *
+ * Conforms to "AMD I/O Virtualization Technology (IOMMU) Specification",
+ * Revision 1.26, February 2009.
+ *
+ *************************************************************************=
*****/
+
+struct acpi_table_ivrs {
+	struct acpi_table_header header;	/* Common ACPI table =
header */
+	u32 info;		/* Common virtualization info */
+	u64 reserved;
+};
+
+/* Values for Info field above */
+
+#define ACPI_IVRS_PHYSICAL_SIZE     0x00007F00	/* 7 bits, physical =
address size */
+#define ACPI_IVRS_VIRTUAL_SIZE      0x003F8000	/* 7 bits, virtual address =
size */
+#define ACPI_IVRS_ATS_RESERVED      0x00400000	/* ATS address translation =
range reserved */
+
+/* IVRS subtable header */
+
+struct acpi_ivrs_header {
+	u8 type;		/* Subtable type */
+	u8 flags;
+	u16 length;		/* Subtable length */
+	u16 device_id;		/* ID of IOMMU */
+};
+
+/* Values for subtable Type above */
+
+enum acpi_ivrs_type {
+	ACPI_IVRS_TYPE_HARDWARE =3D 0x10,
+	ACPI_IVRS_TYPE_MEMORY_ALL /* _MEMORY1 */ =3D 0x20,
+	ACPI_IVRS_TYPE_MEMORY_ONE /* _MEMORY2 */ =3D 0x21,
+	ACPI_IVRS_TYPE_MEMORY_RANGE /* _MEMORY3 */ =3D 0x22,
+	ACPI_IVRS_TYPE_MEMORY_IOMMU =3D 0x23
+};
+
+/* Masks for Flags field above for IVHD subtable */
+
+#define ACPI_IVHD_TT_ENABLE         (1)
+#define ACPI_IVHD_PASS_PW           (1<<1)
+#define ACPI_IVHD_RES_PASS_PW       (1<<2)
+#define ACPI_IVHD_ISOC              (1<<3)
+#define ACPI_IVHD_IOTLB             (1<<4)
+
+/* Masks for Flags field above for IVMD subtable */
+
+#define ACPI_IVMD_UNITY             (1)
+#define ACPI_IVMD_READ              (1<<1)
+#define ACPI_IVMD_WRITE             (1<<2)
+#define ACPI_IVMD_EXCLUSION_RANGE   (1<<3)
+
+/*
+ * IVRS subtables, correspond to Type in struct acpi_ivrs_header
+ */
+
+/* 0x10: I/O Virtualization Hardware Definition Block (IVHD) */
+
+struct acpi_ivrs_hardware {
+	struct acpi_ivrs_header header;
+	u16 capability_offset;	/* Offset for IOMMU control fields */
+	u64 base_address;	/* IOMMU control registers */
+	u16 pci_segment_group;
+	u16 info;		/* MSI number and unit ID */
+	u32 reserved;
+};
+
+/* Masks for Info field above */
+
+#define ACPI_IVHD_MSI_NUMBER_MASK   0x001F	/* 5 bits, MSI message =
number */
+#define ACPI_IVHD_UNIT_ID_MASK      0x1F00	/* 5 bits, unit_iD */
+
+/*
+ * Device Entries for IVHD subtable, appear after struct acpi_ivrs_hardwar=
e structure.
+ * Upper two bits of the Type field are the (encoded) length of the =
structure.
+ * Currently, only 4 and 8 byte entries are defined. 16 and 32 byte =
entries
+ * are reserved for future use but not defined.
+ */
+struct acpi_ivrs_de_header {
+	u8 type;
+	u16 id;
+	u8 data_setting;
+};
+
+/* Length of device entry is in the top two bits of Type field above */
+
+#define ACPI_IVHD_ENTRY_LENGTH      0xC0
+
+/* Values for device entry Type field above */
+
+enum acpi_ivrs_device_entry_type {
+	/* 4-byte device entries, all use struct acpi_ivrs_device4 */
+
+	ACPI_IVRS_TYPE_PAD4 =3D 0,
+	ACPI_IVRS_TYPE_ALL =3D 1,
+	ACPI_IVRS_TYPE_SELECT =3D 2,
+	ACPI_IVRS_TYPE_START =3D 3,
+	ACPI_IVRS_TYPE_END =3D 4,
+
+	/* 8-byte device entries */
+
+	ACPI_IVRS_TYPE_PAD8 =3D 64,
+	ACPI_IVRS_TYPE_NOT_USED =3D 65,
+	ACPI_IVRS_TYPE_ALIAS_SELECT =3D 66,	/* Uses struct acpi_ivrs_de=
vice8a */
+	ACPI_IVRS_TYPE_ALIAS_START =3D 67,	/* Uses struct acpi_ivrs_de=
vice8a */
+	ACPI_IVRS_TYPE_EXT_SELECT =3D 70,	/* Uses struct acpi_ivrs_de=
vice8b */
+	ACPI_IVRS_TYPE_EXT_START =3D 71,	/* Uses struct acpi_ivrs_de=
vice8b */
+	ACPI_IVRS_TYPE_SPECIAL =3D 72	/* Uses struct acpi_ivrs_device8c =
*/
+};
+
+/* Values for Data field above */
+
+#define ACPI_IVHD_INIT_PASS         (1)
+#define ACPI_IVHD_EINT_PASS         (1<<1)
+#define ACPI_IVHD_NMI_PASS          (1<<2)
+#define ACPI_IVHD_SYSTEM_MGMT       (3<<4)
+#define ACPI_IVHD_LINT0_PASS        (1<<6)
+#define ACPI_IVHD_LINT1_PASS        (1<<7)
+
+/* Types 0-4: 4-byte device entry */
+
+struct acpi_ivrs_device4 {
+	struct acpi_ivrs_de_header header;
+};
+
+/* Types 66-67: 8-byte device entry */
+
+struct acpi_ivrs_device8a {
+	struct acpi_ivrs_de_header header;
+	u8 reserved1;
+	u16 used_id;
+	u8 reserved2;
+};
+
+/* Types 70-71: 8-byte device entry */
+
+struct acpi_ivrs_device8b {
+	struct acpi_ivrs_de_header header;
+	u32 extended_data;
+};
+
+/* Values for extended_data above */
+
+#define ACPI_IVHD_ATS_DISABLED      (1<<31)
+
+/* Type 72: 8-byte device entry */
+
+struct acpi_ivrs_device8c {
+	struct acpi_ivrs_de_header header;
+	u8 handle;
+	u16 used_id;
+	u8 variety;
+};
+
+/* Values for Variety field above */
+
+#define ACPI_IVHD_IOAPIC            1
+#define ACPI_IVHD_HPET              2
+
+/* 0x20, 0x21, 0x22: I/O Virtualization Memory Definition Block (IVMD) */
+
+struct acpi_ivrs_memory {
+	struct acpi_ivrs_header header;
+	u16 aux_data;
+	u64 reserved;
+	u64 start_address;
+	u64 memory_length;
+};
+
+/*************************************************************************=
******
+ *
+ * MCFG - PCI Memory Mapped Configuration table and sub-table
+ *        Version 1
+ *
+ * Conforms to "PCI Firmware Specification", Revision 3.0, June 20, 2005
+ *
+ *************************************************************************=
*****/
+
+struct acpi_table_mcfg {
+	struct acpi_table_header header;	/* Common ACPI table =
header */
+	u8 reserved[8];
+};
+
+/* Subtable */
+
+struct acpi_mcfg_allocation {
+	u64 address;		/* Base address, processor-relative */
+	u16 pci_segment;	/* PCI segment group number */
+	u8 start_bus_number;	/* Starting PCI Bus number */
+	u8 end_bus_number;	/* Final PCI Bus number */
+	u32 reserved;
+};
+
+/*************************************************************************=
******
+ *
+ * MCHI - Management Controller Host Interface Table
+ *        Version 1
+ *
+ * Conforms to "Management Component Transport Protocol (MCTP) Host
+ * Interface Specification", Revision 1.0.0a, October 13, 2009
+ *
+ *************************************************************************=
*****/
+
+struct acpi_table_mchi {
+	struct acpi_table_header header;	/* Common ACPI table =
header */
+	u8 interface_type;
+	u8 protocol;
+	u64 protocol_data;
+	u8 interrupt_type;
+	u8 gpe;
+	u8 pci_device_flag;
+	u32 global_interrupt;
+	struct acpi_generic_address control_register;
+	u8 pci_segment;
+	u8 pci_bus;
+	u8 pci_device;
+	u8 pci_function;
+};
+
+/*************************************************************************=
******
+ *
+ * SLIC - Software Licensing Description Table
+ *        Version 1
+ *
+ * Conforms to "OEM Activation 2.0 for Windows Vista Operating Systems",
+ * Copyright 2006
+ *
+ *************************************************************************=
*****/
+
+/* Basic SLIC table is only the common ACPI header */
+
+struct acpi_table_slic {
+	struct acpi_table_header header;	/* Common ACPI table =
header */
+};
+
+/* Common SLIC subtable header */
+
+struct acpi_slic_header {
+	u32 type;
+	u32 length;
+};
+
+/* Values for Type field above */
+
+enum acpi_slic_type {
+	ACPI_SLIC_TYPE_PUBLIC_KEY =3D 0,
+	ACPI_SLIC_TYPE_WINDOWS_MARKER =3D 1,
+	ACPI_SLIC_TYPE_RESERVED =3D 2	/* 2 and greater are reserved */
+};
+
+/*
+ * SLIC Sub-tables, correspond to Type in struct acpi_slic_header
+ */
+
+/* 0: Public Key Structure */
+
+struct acpi_slic_key {
+	struct acpi_slic_header header;
+	u8 key_type;
+	u8 version;
+	u16 reserved;
+	u32 algorithm;
+	char magic[4];
+	u32 bit_length;
+	u32 exponent;
+	u8 modulus[128];
+};
+
+/* 1: Windows Marker Structure */
+
+struct acpi_slic_marker {
+	struct acpi_slic_header header;
+	u32 version;
+	char oem_id[ACPI_OEM_ID_SIZE];	/* ASCII OEM identification */
+	char oem_table_id[ACPI_OEM_TABLE_ID_SIZE];	/* ASCII OEM table =
identification */
+	char windows_flag[8];
+	u32 slic_version;
+	u8 reserved[16];
+	u8 signature[128];
+};
+
+/*************************************************************************=
******
+ *
+ * SPCR - Serial Port Console Redirection table
+ *        Version 1
+ *
+ * Conforms to "Serial Port Console Redirection Table",
+ * Version 1.00, January 11, 2002
+ *
+ *************************************************************************=
*****/
+
+struct acpi_table_spcr {
+	struct acpi_table_header header;	/* Common ACPI table =
header */
+	u8 interface_type;	/* 0=3Dfull 16550, 1=3Dsubset of 16550 */
+	u8 reserved[3];
+	struct acpi_generic_address serial_port;
+	u8 interrupt_type;
+	u8 pc_interrupt;
+	u32 interrupt;
+	u8 baud_rate;
+	u8 parity;
+	u8 stop_bits;
+	u8 flow_control;
+	u8 terminal_type;
+	u8 reserved1;
+	u16 pci_device_id;
+	u16 pci_vendor_id;
+	u8 pci_bus;
+	u8 pci_device;
+	u8 pci_function;
+	u32 pci_flags;
+	u8 pci_segment;
+	u32 reserved2;
+};
+
+/* Masks for pci_flags field above */
+
+#define ACPI_SPCR_DO_NOT_DISABLE    (1)
+
+/*************************************************************************=
******
+ *
+ * SPMI - Server Platform Management Interface table
+ *        Version 5
+ *
+ * Conforms to "Intelligent Platform Management Interface Specification
+ * Second Generation v2.0", Document Revision 1.0, February 12, 2004 with
+ * June 12, 2009 markup.
+ *
+ *************************************************************************=
*****/
+
+struct acpi_table_spmi {
+	struct acpi_table_header header;	/* Common ACPI table =
header */
+	u8 interface_type;
+	u8 reserved;		/* Must be 1 */
+	u16 spec_revision;	/* Version of IPMI */
+	u8 interrupt_type;
+	u8 gpe_number;		/* GPE assigned */
+	u8 reserved1;
+	u8 pci_device_flag;
+	u32 interrupt;
+	struct acpi_generic_address ipmi_register;
+	u8 pci_segment;
+	u8 pci_bus;
+	u8 pci_device;
+	u8 pci_function;
+	u8 reserved2;
+};
+
+/* Values for interface_type above */
+
+enum acpi_spmi_interface_types {
+	ACPI_SPMI_NOT_USED =3D 0,
+	ACPI_SPMI_KEYBOARD =3D 1,
+	ACPI_SPMI_SMI =3D 2,
+	ACPI_SPMI_BLOCK_TRANSFER =3D 3,
+	ACPI_SPMI_SMBUS =3D 4,
+	ACPI_SPMI_RESERVED =3D 5	/* 5 and above are reserved */
+};
+
+/*************************************************************************=
******
+ *
+ * TCPA - Trusted Computing Platform Alliance table
+ *        Version 1
+ *
+ * Conforms to "TCG PC Specific Implementation Specification",
+ * Version 1.1, August 18, 2003
+ *
+ *************************************************************************=
*****/
+
+struct acpi_table_tcpa {
+	struct acpi_table_header header;	/* Common ACPI table =
header */
+	u16 reserved;
+	u32 max_log_length;	/* Maximum length for the event log area =
*/
+	u64 log_address;	/* Address of the event log area */
+};
+
+/*************************************************************************=
******
+ *
+ * UEFI - UEFI Boot optimization Table
+ *        Version 1
+ *
+ * Conforms to "Unified Extensible Firmware Interface Specification",
+ * Version 2.3, May 8, 2009
+ *
+ *************************************************************************=
*****/
+
+struct acpi_table_uefi {
+	struct acpi_table_header header;	/* Common ACPI table =
header */
+	u8 identifier[16];	/* UUID identifier */
+	u16 data_offset;	/* Offset of remaining data in table */
+};
+
+/*************************************************************************=
******
+ *
+ * WAET - Windows ACPI Emulated devices Table
+ *        Version 1
+ *
+ * Conforms to "Windows ACPI Emulated Devices Table", version 1.0, April =
6, 2009
+ *
+ *************************************************************************=
*****/
+
+struct acpi_table_waet {
+	struct acpi_table_header header;	/* Common ACPI table =
header */
+	u32 flags;
+};
+
+/* Masks for Flags field above */
+
+#define ACPI_WAET_RTC_NO_ACK        (1)	/* RTC requires no int =
acknowledge */
+#define ACPI_WAET_TIMER_ONE_READ    (1<<1)	/* PM timer requires only =
one read */
+
+/*************************************************************************=
******
+ *
+ * WDAT - Watchdog Action Table
+ *        Version 1
+ *
+ * Conforms to "Hardware Watchdog Timers Design Specification",
+ * Copyright 2006 Microsoft Corporation.
+ *
+ *************************************************************************=
*****/
+
+struct acpi_table_wdat {
+	struct acpi_table_header header;	/* Common ACPI table =
header */
+	u32 header_length;	/* Watchdog Header Length */
+	u16 pci_segment;	/* PCI Segment number */
+	u8 pci_bus;		/* PCI Bus number */
+	u8 pci_device;		/* PCI Device number */
+	u8 pci_function;	/* PCI Function number */
+	u8 reserved[3];
+	u32 timer_period;	/* Period of one timer count (msec) */
+	u32 max_count;		/* Maximum counter value supported */
+	u32 min_count;		/* Minimum counter value */
+	u8 flags;
+	u8 reserved2[3];
+	u32 entries;		/* Number of watchdog entries that follow =
*/
+};
+
+/* Masks for Flags field above */
+
+#define ACPI_WDAT_ENABLED           (1)
+#define ACPI_WDAT_STOPPED           0x80
+
+/* WDAT Instruction Entries (actions) */
+
+struct acpi_wdat_entry {
+	u8 action;
+	u8 instruction;
+	u16 reserved;
+	struct acpi_generic_address register_region;
+	u32 value;		/* Value used with Read/Write register */
+	u32 mask;		/* Bitmask required for this register =
instruction */
+};
+
+/* Values for Action field above */
+
+enum acpi_wdat_actions {
+	ACPI_WDAT_RESET =3D 1,
+	ACPI_WDAT_GET_CURRENT_COUNTDOWN =3D 4,
+	ACPI_WDAT_GET_COUNTDOWN =3D 5,
+	ACPI_WDAT_SET_COUNTDOWN =3D 6,
+	ACPI_WDAT_GET_RUNNING_STATE =3D 8,
+	ACPI_WDAT_SET_RUNNING_STATE =3D 9,
+	ACPI_WDAT_GET_STOPPED_STATE =3D 10,
+	ACPI_WDAT_SET_STOPPED_STATE =3D 11,
+	ACPI_WDAT_GET_REBOOT =3D 16,
+	ACPI_WDAT_SET_REBOOT =3D 17,
+	ACPI_WDAT_GET_SHUTDOWN =3D 18,
+	ACPI_WDAT_SET_SHUTDOWN =3D 19,
+	ACPI_WDAT_GET_STATUS =3D 32,
+	ACPI_WDAT_SET_STATUS =3D 33,
+	ACPI_WDAT_ACTION_RESERVED =3D 34	/* 34 and greater are =
reserved */
+};
+
+/* Values for Instruction field above */
+
+enum acpi_wdat_instructions {
+	ACPI_WDAT_READ_VALUE =3D 0,
+	ACPI_WDAT_READ_COUNTDOWN =3D 1,
+	ACPI_WDAT_WRITE_VALUE =3D 2,
+	ACPI_WDAT_WRITE_COUNTDOWN =3D 3,
+	ACPI_WDAT_INSTRUCTION_RESERVED =3D 4,	/* 4 and greater are =
reserved */
+	ACPI_WDAT_PRESERVE_REGISTER =3D 0x80	/* Except for this value =
*/
+};
+
+/*************************************************************************=
******
+ *
+ * WDDT - Watchdog Descriptor Table
+ *        Version 1
+ *
+ * Conforms to "Using the Intel ICH Family Watchdog Timer (WDT)",
+ * Version 001, September 2002
+ *
+ *************************************************************************=
*****/
+
+struct acpi_table_wddt {
+	struct acpi_table_header header;	/* Common ACPI table =
header */
+	u16 spec_version;
+	u16 table_version;
+	u16 pci_vendor_id;
+	struct acpi_generic_address address;
+	u16 max_count;		/* Maximum counter value supported */
+	u16 min_count;		/* Minimum counter value supported */
+	u16 period;
+	u16 status;
+	u16 capability;
+};
+
+/* Flags for Status field above */
+
+#define ACPI_WDDT_AVAILABLE     (1)
+#define ACPI_WDDT_ACTIVE        (1<<1)
+#define ACPI_WDDT_TCO_OS_OWNED  (1<<2)
+#define ACPI_WDDT_USER_RESET    (1<<11)
+#define ACPI_WDDT_WDT_RESET     (1<<12)
+#define ACPI_WDDT_POWER_FAIL    (1<<13)
+#define ACPI_WDDT_UNKNOWN_RESET (1<<14)
+
+/* Flags for Capability field above */
+
+#define ACPI_WDDT_AUTO_RESET    (1)
+#define ACPI_WDDT_ALERT_SUPPORT (1<<1)
+
+/*************************************************************************=
******
+ *
+ * WDRT - Watchdog Resource Table
+ *        Version 1
+ *
+ * Conforms to "Watchdog Timer Hardware Requirements for Windows Server =
2003",
+ * Version 1.01, August 28, 2006
+ *
+ *************************************************************************=
*****/
+
+struct acpi_table_wdrt {
+	struct acpi_table_header header;	/* Common ACPI table =
header */
+	struct acpi_generic_address control_register;
+	struct acpi_generic_address count_register;
+	u16 pci_device_id;
+	u16 pci_vendor_id;
+	u8 pci_bus;		/* PCI Bus number */
+	u8 pci_device;		/* PCI Device number */
+	u8 pci_function;	/* PCI Function number */
+	u8 pci_segment;		/* PCI Segment number */
+	u16 max_count;		/* Maximum counter value supported */
+	u8 units;
+};
+
+/* Reset to default packing */
+
+#pragma pack()
+
+#endif				/* __ACTBL2_H__ */



--=__Part96B93371.0__=
Content-Type: text/plain; name="acpi-update-structs.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="acpi-update-structs.patch"

ACPI: update table interface headers=0A=0A... to what is being used on =
Linux 3.1 (and 3.2-rc).=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=
=0A=0A--- a/xen/drivers/acpi/numa.c=0A+++ b/xen/drivers/acpi/numa.c=0A@@ =
-78,9 +78,11 @@ void __init acpi_table_print_srat_entry(=0A 			=
if (srat_rev < 2)=0A 				proximity_domain &=3D =
0xff;=0A 			ACPI_DEBUG_PRINT((ACPI_DB_INFO,=0A-		=
			  "SRAT Memory (0x%016"PRIx64" length 0x%016"PRIx64=
" type 0x%x) in proximity domain %d %s%s\n",=0A+				=
	  "SRAT Memory (%#016"PRIx64=0A+					=
  " length %#016"PRIx64")"=0A+					  " in =
proximity domain %d %s%s\n",=0A 					  =
p->base_address, p->length,=0A-					  =
p->memory_type, proximity_domain,=0A+					  =
proximity_domain,=0A 					  p->flags & =
ACPI_SRAT_MEM_ENABLED=0A 					  ? =
"enabled" : "disabled",=0A 					  p->flags =
& ACPI_SRAT_MEM_HOT_PLUGGABLE=0A--- a/xen/include/acpi/actbl.h=0A+++ =
b/xen/include/acpi/actbl.h=0A@@ -5,7 +5,7 @@=0A  **************************=
***************************************************/=0A =0A /*=0A- * =
Copyright (C) 2000 - 2007, R. Byron Moore=0A+ * Copyright (C) 2000 - 2011, =
Intel Corp.=0A  * All rights reserved.=0A  *=0A  * Redistribution and use =
in source and binary forms, with or without=0A@@ -44,9 +44,23 @@=0A =
#ifndef __ACTBL_H__=0A #define __ACTBL_H__=0A =0A+/************************=
*******************************************************=0A+ *=0A+ * =
Fundamental ACPI tables=0A+ *=0A+ * This file contains definitions for the =
ACPI tables that are directly consumed=0A+ * by ACPICA. All other tables =
are consumed by the OS-dependent ACPI-related=0A+ * device drivers and =
other OS support code.=0A+ *=0A+ * The RSDP and FACS do not use the common =
ACPI table header. All other ACPI=0A+ * tables use the header.=0A+ *=0A+ =
***************************************************************************=
***/=0A+=0A /*=0A- * Values for description table header signatures. =
Useful because they make=0A- * it more difficult to inadvertently type in =
the wrong signature.=0A+ * Values for description table header signatures =
for tables defined in this=0A+ * file. Useful because they make it more =
difficult to inadvertently type in=0A+ * the wrong signature.=0A  */=0A =
#define ACPI_SIG_DSDT           "DSDT"	/* Differentiated System Descriptio=
n Table */=0A #define ACPI_SIG_FADT           "FACP"	/* Fixed ACPI =
Description Table */=0A@@ -65,11 +79,6 @@=0A #pragma pack(1)=0A =0A /*=0A- =
* These are the ACPI tables that are directly consumed by the subsystem.=0A=
- *=0A- * The RSDP and FACS do not use the common ACPI table header. All =
other ACPI=0A- * tables use the header.=0A- *=0A  * Note about bitfields: =
The u8 type is used for bitfields in ACPI tables.=0A  * This is the only =
type that is even remotely portable. Anything else is not=0A  * portable, =
so do not use any other bitfield types.=0A@@ -77,9 +86,8 @@=0A =0A =
/**************************************************************************=
*****=0A  *=0A- * ACPI Table Header. This common header is used by all =
tables except the=0A- * RSDP and FACS. The define is used for direct =
inclusion of header into=0A- * other ACPI tables=0A+ * Master ACPI Table =
Header. This common header is used by all ACPI tables=0A+ * except the =
RSDP and FACS.=0A  *=0A  **************************************************=
****************************/=0A =0A@@ -95,13 +103,16 @@ struct acpi_table_=
header {=0A 	u32 asl_compiler_revision;	/* ASL compiler version =
*/=0A };=0A =0A-/*=0A+/****************************************************=
***************************=0A+ *=0A  * GAS - Generic Address Structure =
(ACPI 2.0+)=0A  *=0A  * Note: Since this structure is used in the ACPI =
tables, it is byte aligned.=0A- * If misalignment is not supported, access =
to the Address field must be=0A- * performed with care.=0A- */=0A+ * If =
misaliged access is not supported by the hardware, accesses to the=0A+ * =
64-bit Address field must be performed with care.=0A+ *=0A+ ***************=
***************************************************************/=0A+=0A =
struct acpi_generic_address {=0A 	u8 space_id;		/* Address =
space where struct or register exists */=0A 	u8 bit_width;		/* =
Size in bits of given register */=0A@@ -113,6 +124,7 @@ struct acpi_generic=
_address {=0A /************************************************************=
*******************=0A  *=0A  * RSDP - Root System Description Pointer =
(Signature is "RSD PTR ")=0A+ *        Version 2=0A  *=0A  ****************=
**************************************************************/=0A =0A@@ =
-133,6 +145,7 @@ struct acpi_table_rsdp {=0A /*****************************=
**************************************************=0A  *=0A  * RSDT/XSDT - =
Root System Description Tables=0A+ *             Version 1 (both)=0A  *=0A =
 **************************************************************************=
****/=0A =0A@@ -161,21 +174,29 @@ struct acpi_table_facs {=0A 	u32 =
flags;=0A 	u64 xfirmware_waking_vector;	/* 64-bit version of the =
Firmware Waking Vector (ACPI 2.0+) */=0A 	u8 version;		/* =
Version of this table (ACPI 2.0+) */=0A-	u8 reserved[31];	/* =
Reserved, must be zero */=0A+	u8 reserved[3];		/* Reserved, must =
be zero */=0A+	u32 ospm_flags;		/* Flags to be set by OSPM (ACPI =
4.0) */=0A+	u8 reserved1[24];	/* Reserved, must be zero */=0A =
};=0A =0A-/* Flag macros */=0A+/* Masks for global_lock flag field above =
*/=0A+=0A+#define ACPI_GLOCK_PENDING          (1)	/* 00: Pending =
global lock ownership */=0A+#define ACPI_GLOCK_OWNED            (1<<1)	/* =
01: Global lock is owned */=0A =0A-#define ACPI_FACS_S4_BIOS_PRESENT (1)	=
/* 00: S4BIOS support is present */=0A+/* Masks for Flags field above  =
*/=0A =0A-/* Global lock flags */=0A+#define ACPI_FACS_S4_BIOS_PRESENT   =
(1)	/* 00: S4BIOS support is present */=0A+#define ACPI_FACS_64BIT_WAKE=
        (1<<1)	/* 01: 64-bit wake vector supported (ACPI 4.0) */=0A =
=0A-#define ACPI_GLOCK_PENDING      0x01	/* 00: Pending global lock =
ownership */=0A-#define ACPI_GLOCK_OWNED        0x02	/* 01: Global lock =
is owned */=0A+/* Masks for ospm_flags field above */=0A+=0A+#define =
ACPI_FACS_64BIT_ENVIRONMENT (1)	/* 00: 64-bit wake environment is required =
(ACPI 4.0) */=0A =0A /*****************************************************=
**************************=0A  *=0A  * FADT - Fixed ACPI Description Table =
(Signature "FACP")=0A+ *        Version 4=0A  *=0A  ***********************=
*******************************************************/=0A =0A@@ -214,11 =
+235,11 @@ struct acpi_table_fadt {=0A 	u16 flush_size;		/* =
Processor's memory cache line width, in bytes */=0A 	u16 flush_stride;	=
/* Number of flush strides that need to be read */=0A 	u8 duty_offset;		=
/* Processor duty cycle index in processor's P_CNT reg */=0A-	u8 =
duty_width;		/* Processor duty cycle value bit width in P_CNT =
register. */=0A+	u8 duty_width;		/* Processor duty cycle =
value bit width in P_CNT register */=0A 	u8 day_alarm;		/* =
Index to day-of-month alarm in RTC CMOS RAM */=0A 	u8 month_alarm;		=
/* Index to month-of-year alarm in RTC CMOS RAM */=0A 	u8 century;		=
/* Index to century in RTC CMOS RAM */=0A-	u16 boot_flags;		/* =
IA-PC Boot Architecture Flags. See Table 5-10 for description */=0A+	=
u16 boot_flags;		/* IA-PC Boot Architecture Flags (see below for =
individual flags) */=0A 	u8 reserved;		/* Reserved, must =
be zero */=0A 	u32 flags;		/* Miscellaneous flag bits (see =
below for individual flags) */=0A 	struct acpi_generic_address =
reset_register;	/* 64-bit address of the Reset register */=0A@@ -236,32 =
+257,41 @@ struct acpi_table_fadt {=0A 	struct acpi_generic_address =
xgpe1_block;	/* 64-bit Extended General Purpose Event 1 Reg Blk address =
*/=0A };=0A =0A-/* FADT flags */=0A+/* Masks for FADT Boot Architecture =
Flags (boot_flags) */=0A =0A-#define ACPI_FADT_WBINVD            (1)	/* =
00: The wbinvd instruction works properly */=0A-#define ACPI_FADT_WBINVD_FL=
USH      (1<<1)	/* 01: The wbinvd flushes but does not invalidate =
*/=0A-#define ACPI_FADT_C1_SUPPORTED      (1<<2)	/* 02: All =
processors support C1 state */=0A-#define ACPI_FADT_C2_MP_SUPPORTED   =
(1<<3)	/* 03: C2 state works on MP system */=0A-#define ACPI_FADT_POWER_BU=
TTON      (1<<4)	/* 04: Power button is handled as a generic =
feature */=0A-#define ACPI_FADT_SLEEP_BUTTON      (1<<5)	/* 05: =
Sleep button is handled as a generic feature, or  not present */=0A-#define=
 ACPI_FADT_FIXED_RTC         (1<<6)	/* 06: RTC wakeup stat not in =
fixed register space */=0A-#define ACPI_FADT_S4_RTC_WAKE       (1<<7)	/* =
07: RTC wakeup stat not possible from S4 */=0A-#define ACPI_FADT_32BIT_TIME=
R       (1<<8)	/* 08: tmr_val is 32 bits 0=3D24-bits */=0A-#define =
ACPI_FADT_DOCKING_SUPPORTED (1<<9)	/* 09: Docking supported */=0A-#def=
ine ACPI_FADT_RESET_REGISTER    (1<<10)	/* 10: System reset via the FADT =
RESET_REG supported */=0A-#define ACPI_FADT_SEALED_CASE       (1<<11)	/* =
11: No internal expansion capabilities and case is sealed */=0A-#define =
ACPI_FADT_HEADLESS          (1<<12)	/* 12: No local video capabilities =
or local input devices */=0A-#define ACPI_FADT_SLEEP_TYPE        (1<<13)	=
/* 13: Must execute native instruction after writing  SLP_TYPx register =
*/=0A-#define ACPI_FADT_PCI_EXPRESS_WAKE  (1<<14)	/* 14: System =
supports PCIEXP_WAKE (STS/EN) bits (ACPI 3.0) */=0A-#define ACPI_FADT_PLATF=
ORM_CLOCK    (1<<15)	/* 15: OSPM should use platform-provided timer =
(ACPI 3.0) */=0A-#define ACPI_FADT_S4_RTC_VALID      (1<<16)	/* 16: =
Contents of RTC_STS valid after S4 wake (ACPI 3.0) */=0A-#define ACPI_FADT_=
REMOTE_POWER_ON   (1<<17)	/* 17: System is compatible with remote =
power on (ACPI 3.0) */=0A-#define ACPI_FADT_APIC_CLUSTER      (1<<18)	/* =
18: All local APICs must use cluster model (ACPI 3.0) */=0A-#define =
ACPI_FADT_APIC_PHYSICAL     (1<<19)	/* 19: All local x_aPICs must use =
physical dest mode (ACPI 3.0) */=0A+#define ACPI_FADT_LEGACY_DEVICES    =
(1)  	/* 00: [V2] System has LPC or ISA bus devices */=0A+#define =
ACPI_FADT_8042              (1<<1)	/* 01: [V3] System has an 8042 =
controller on port 60/64 */=0A+#define ACPI_FADT_NO_VGA            (1<<2)	=
/* 02: [V4] It is not safe to probe for VGA hardware */=0A+#define =
ACPI_FADT_NO_MSI            (1<<3)	/* 03: [V4] Message Signaled =
Interrupts (MSI) must not be enabled */=0A+#define ACPI_FADT_NO_ASPM       =
    (1<<4)	/* 04: [V4] PCIe ASPM control must not be enabled =
*/=0A+=0A+#define FADT2_REVISION_ID               3=0A+=0A+/* Masks for =
FADT flags */=0A+=0A+#define ACPI_FADT_WBINVD            (1)	/* 00: =
[V1] The wbinvd instruction works properly */=0A+#define ACPI_FADT_WBINVD_F=
LUSH      (1<<1)	/* 01: [V1] wbinvd flushes but does not invalidate =
caches */=0A+#define ACPI_FADT_C1_SUPPORTED      (1<<2)	/* 02: [V1] All =
processors support C1 state */=0A+#define ACPI_FADT_C2_MP_SUPPORTED   =
(1<<3)	/* 03: [V1] C2 state works on MP system */=0A+#define ACPI_FADT_POW=
ER_BUTTON      (1<<4)	/* 04: [V1] Power button is handled as a control =
method device */=0A+#define ACPI_FADT_SLEEP_BUTTON      (1<<5)	/* 05: =
[V1] Sleep button is handled as a control method device */=0A+#define =
ACPI_FADT_FIXED_RTC         (1<<6)	/* 06: [V1] RTC wakeup status not =
in fixed register space */=0A+#define ACPI_FADT_S4_RTC_WAKE       (1<<7)	=
/* 07: [V1] RTC alarm can wake system from S4 */=0A+#define ACPI_FADT_32BIT=
_TIMER       (1<<8)	/* 08: [V1] ACPI timer width is 32-bit (0=3D24-bit)=
 */=0A+#define ACPI_FADT_DOCKING_SUPPORTED (1<<9)	/* 09: [V1] =
Docking supported */=0A+#define ACPI_FADT_RESET_REGISTER    (1<<10)	/* =
10: [V2] System reset via the FADT RESET_REG supported */=0A+#define =
ACPI_FADT_SEALED_CASE       (1<<11)	/* 11: [V3] No internal expansion =
capabilities and case is sealed */=0A+#define ACPI_FADT_HEADLESS          =
(1<<12)	/* 12: [V3] No local video capabilities or local input devices =
*/=0A+#define ACPI_FADT_SLEEP_TYPE        (1<<13)	/* 13: [V3] Must =
execute native instruction after writing  SLP_TYPx register */=0A+#define =
ACPI_FADT_PCI_EXPRESS_WAKE  (1<<14)	/* 14: [V4] System supports =
PCIEXP_WAKE (STS/EN) bits (ACPI 3.0) */=0A+#define ACPI_FADT_PLATFORM_CLOCK=
    (1<<15)	/* 15: [V4] OSPM should use platform-provided timer (ACPI =
3.0) */=0A+#define ACPI_FADT_S4_RTC_VALID      (1<<16)	/* 16: [V4] =
Contents of RTC_STS valid after S4 wake (ACPI 3.0) */=0A+#define ACPI_FADT_=
REMOTE_POWER_ON   (1<<17)	/* 17: [V4] System is compatible with =
remote power on (ACPI 3.0) */=0A+#define ACPI_FADT_APIC_CLUSTER      =
(1<<18)	/* 18: [V4] All local APICs must use cluster model (ACPI 3.0) =
*/=0A+#define ACPI_FADT_APIC_PHYSICAL     (1<<19)	/* 19: [V4] All =
local x_aPICs must use physical dest mode (ACPI 3.0) */=0A+=0A+/* Values =
for preferred_profile (Preferred Power Management Profiles) */=0A =
=0A-/*=0A- * FADT Prefered Power Management Profiles=0A- */=0A enum =
acpi_prefered_pm_profiles {=0A 	PM_UNSPECIFIED =3D 0,=0A 	PM_DESKTOP =
=3D 1,=0A@@ -272,15 +302,6 @@ enum acpi_prefered_pm_profiles {=0A 	=
PM_APPLIANCE_PC =3D 6=0A };=0A =0A-/* FADT Boot Arch Flags */=0A-=0A-#defin=
e BAF_LEGACY_DEVICES              0x0001=0A-#define BAF_8042_KEYBOARD_CONTR=
OLLER    0x0002=0A-#define BAF_MSI_NOT_SUPPORTED           0x0008=0A-=0A-#d=
efine FADT2_REVISION_ID               3=0A-#define FADT2_MINUS_REVISION_ID =
        2=0A-=0A /* Reset to default packing */=0A =0A #pragma pack()=0A@@ =
-292,5 +313,22 @@ enum acpi_prefered_pm_profiles {=0A  */=0A =0A #include =
<acpi/actbl1.h>=0A+#include <acpi/actbl2.h>=0A+=0A+/*=0A+ * Sizes of the =
various flavors of FADT. We need to look closely=0A+ * at the FADT length =
because the version number essentially tells=0A+ * us nothing because of =
many BIOS bugs where the version does not=0A+ * match the expected length. =
In other words, the length of the=0A+ * FADT is the bottom line as to what =
the version really is.=0A+ *=0A+ * For reference, the values below are as =
follows:=0A+ *     FADT V1  size: 0x74=0A+ *     FADT V2  size: 0x84=0A+ * =
    FADT V3+ size: 0xF4=0A+ */=0A+#define ACPI_FADT_V1_SIZE       (u32) =
(ACPI_FADT_OFFSET (flags) + 4)=0A+#define ACPI_FADT_V2_SIZE       (u32) =
(ACPI_FADT_OFFSET (reserved4[0]) + 3)=0A+#define ACPI_FADT_V3_SIZE       =
(u32) (sizeof (struct acpi_table_fadt))=0A =0A #endif				=
/* __ACTBL_H__ */=0A--- a/xen/include/acpi/actbl1.h=0A+++ b/xen/include/acp=
i/actbl1.h=0A@@ -5,7 +5,7 @@=0A  ******************************************=
***********************************/=0A =0A /*=0A- * Copyright (C) 2000 - =
2007, R. Byron Moore=0A+ * Copyright (C) 2000 - 2011, Intel Corp.=0A  * =
All rights reserved.=0A  *=0A  * Redistribution and use in source and =
binary forms, with or without=0A@@ -46,34 +46,31 @@=0A =0A /***************=
****************************************************************=0A  *=0A- =
* Additional ACPI Tables=0A+ * Additional ACPI Tables (1)=0A  *=0A  * =
These tables are not consumed directly by the ACPICA subsystem, but are=0A =
 * included here to support device drivers and the AML disassembler.=0A  =
*=0A+ * The tables in this file are fully defined within the ACPI =
specification.=0A+ *=0A  **************************************************=
****************************/=0A =0A /*=0A- * Values for description table =
header signatures. Useful because they make=0A- * it more difficult to =
inadvertently type in the wrong signature.=0A+ * Values for description =
table header signatures for tables defined in this=0A+ * file. Useful =
because they make it more difficult to inadvertently type in=0A+ * the =
wrong signature.=0A  */=0A-#define ACPI_SIG_ASF            "ASF!"	/* =
Alert Standard Format table */=0A-#define ACPI_SIG_BOOT           "BOOT"	=
/* Simple Boot Flag Table */=0A+#define ACPI_SIG_BERT           "BERT"	/* =
Boot Error Record Table */=0A #define ACPI_SIG_CPEP           "CPEP"	/* =
Corrected Platform Error Polling table */=0A-#define ACPI_SIG_ERST         =
  "ERST"  /* Error Record Serialization Table */=0A-#define ACPI_SIG_DBGP  =
         "DBGP"	/* Debug Port table */=0A-#define ACPI_SIG_DMAR           =
"DMAR"	/* DMA Remapping table */=0A #define ACPI_SIG_ECDT           =
"ECDT"	/* Embedded Controller Boot Resources Table */=0A-#define =
ACPI_SIG_HPET           "HPET"	/* High Precision Event Timer table =
*/=0A+#define ACPI_SIG_EINJ           "EINJ"	/* Error Injection table =
*/=0A+#define ACPI_SIG_ERST           "ERST"	/* Error Record Serializati=
on Table */=0A+#define ACPI_SIG_HEST           "HEST"	/* Hardware Error =
Source Table */=0A #define ACPI_SIG_MADT           "APIC"	/* =
Multiple APIC Description Table */=0A-#define ACPI_SIG_MCFG           =
"MCFG"	/* PCI Memory Mapped Configuration table */=0A+#define ACPI_SIG_MSC=
T           "MSCT"	/* Maximum System Characteristics Table */=0A =
#define ACPI_SIG_SBST           "SBST"	/* Smart Battery Specification =
Table */=0A #define ACPI_SIG_SLIT           "SLIT"	/* System Locality =
Distance Information Table */=0A-#define ACPI_SIG_SPCR           "SPCR"	/* =
Serial Port Console Redirection table */=0A-#define ACPI_SIG_SPMI          =
 "SPMI"	/* Server Platform Management Interface table */=0A #define =
ACPI_SIG_SRAT           "SRAT"	/* System Resource Affinity Table =
*/=0A-#define ACPI_SIG_TCPA           "TCPA"	/* Trusted Computing =
Platform Alliance table */=0A-#define ACPI_SIG_WDRT           "WDRT"	/* =
Watchdog Resource Table */=0A =0A /*=0A  * All tables must be byte-packed =
to match the ACPI specification, since=0A@@ -87,7 +84,13 @@=0A  * =
portable, so do not use any other bitfield types.=0A  */=0A =0A-/* Common =
Sub-table header (used in MADT, SRAT, etc.) */=0A+/************************=
*******************************************************=0A+ *=0A+ * Common =
subtable headers=0A+ *=0A+ ************************************************=
******************************/=0A+=0A+/* Generic subtable header (used in =
MADT, SRAT, etc.) */=0A =0A struct acpi_subtable_header {=0A 	u8 =
type;=0A@@ -108,128 +111,54 @@ struct acpi_whea_header {=0A =0A /**********=
*********************************************************************=0A  =
*=0A- * ASF - Alert Standard Format table (Signature "ASF!")=0A- *=0A- * =
Conforms to the Alert Standard Format Specification V2.0, 23 April =
2003=0A+ * BERT - Boot Error Record Table (ACPI 4.0)=0A+ *        Version =
1=0A  *=0A  ***************************************************************=
***************/=0A =0A-struct acpi_table_asf {=0A+struct acpi_table_bert =
{=0A 	struct acpi_table_header header;	/* Common ACPI table =
header */=0A+	u32 region_length;	/* Length of the boot error region =
*/=0A+	u64 address;		/* Physical address of the error region =
*/=0A };=0A =0A-/* ASF subtable header */=0A-=0A-struct acpi_asf_header =
{=0A-	u8 type;=0A-	u8 reserved;=0A-	u16 length;=0A-};=0A-=0A-/*=
 Values for Type field above */=0A+/* Boot Error Region (not a subtable, =
pointed to by Address field above) */=0A =0A-enum acpi_asf_type {=0A-	=
ACPI_ASF_TYPE_INFO =3D 0,=0A-	ACPI_ASF_TYPE_ALERT =3D 1,=0A-	ACPI_ASF_TY=
PE_CONTROL =3D 2,=0A-	ACPI_ASF_TYPE_BOOT =3D 3,=0A-	ACPI_ASF_TYPE_ADDRE=
SS =3D 4,=0A-	ACPI_ASF_TYPE_RESERVED =3D 5=0A+struct acpi_bert_region =
{=0A+	u32 block_status;	/* Type of error information */=0A+	=
u32 raw_data_offset;	/* Offset to raw error data */=0A+	u32 =
raw_data_length;	/* Length of raw error data */=0A+	u32 =
data_length;	/* Length of generic error data */=0A+	u32 error_severity;=
	/* Severity code */=0A };=0A =0A-/*=0A- * ASF subtables=0A- =
*/=0A+/* Values for block_status flags above */=0A =0A-/* 0: ASF Informatio=
n */=0A+#define ACPI_BERT_UNCORRECTABLE             (1)=0A+#define =
ACPI_BERT_CORRECTABLE               (1<<1)=0A+#define ACPI_BERT_MULTIPLE_UN=
CORRECTABLE    (1<<2)=0A+#define ACPI_BERT_MULTIPLE_CORRECTABLE      =
(1<<3)=0A+#define ACPI_BERT_ERROR_ENTRY_COUNT         (0xFF<<4)	/* 8 bits, =
error count */=0A =0A-struct acpi_asf_info {=0A-	struct acpi_asf_hea=
der header;=0A-	u8 min_reset_value;=0A-	u8 min_poll_interval;=0A-	=
u16 system_id;=0A-	u32 mfg_id;=0A-	u8 flags;=0A-	u8 reserved2[3];=0A=
-};=0A-=0A-/* 1: ASF Alerts */=0A+/* Values for error_severity above */=0A =
=0A-struct acpi_asf_alert {=0A-	struct acpi_asf_header header;=0A-	u8 =
assert_mask;=0A-	u8 deassert_mask;=0A-	u8 alerts;=0A-	u8 =
data_length;=0A-};=0A-=0A-struct acpi_asf_alert_data {=0A-	u8 =
address;=0A-	u8 command;=0A-	u8 mask;=0A-	u8 value;=0A-	u8 =
sensor_type;=0A-	u8 type;=0A-	u8 offset;=0A-	u8 source_type;=0A-=
	u8 severity;=0A-	u8 sensor_number;=0A-	u8 entity;=0A-	u8 =
instance;=0A+enum acpi_bert_error_severity {=0A+	ACPI_BERT_ERROR_COR=
RECTABLE =3D 0,=0A+	ACPI_BERT_ERROR_FATAL =3D 1,=0A+	ACPI_BERT_E=
RROR_CORRECTED =3D 2,=0A+	ACPI_BERT_ERROR_NONE =3D 3,=0A+	ACPI_BERT_E=
RROR_RESERVED =3D 4	/* 4 and greater are reserved */=0A };=0A =0A-/* =
2: ASF Remote Control */=0A-=0A-struct acpi_asf_remote {=0A-	struct =
acpi_asf_header header;=0A-	u8 controls;=0A-	u8 data_length;=0A-=
	u16 reserved2;=0A-};=0A-=0A-struct acpi_asf_control_data {=0A-	u8 =
function;=0A-	u8 address;=0A-	u8 command;=0A-	u8 value;=0A-};=0A-=0A-/* =
3: ASF RMCP Boot Options */=0A-=0A-struct acpi_asf_rmcp {=0A-	struct =
acpi_asf_header header;=0A-	u8 capabilities[7];=0A-	u8 completion_code;=
=0A-	u32 enterprise_id;=0A-	u8 command;=0A-	u16 parameter;=0A-	=
u16 boot_options;=0A-	u16 oem_parameters;=0A-};=0A-=0A-/* 4: ASF Address =
*/=0A-=0A-struct acpi_asf_address {=0A-	struct acpi_asf_header header;=0A-	=
u8 eprom_address;=0A-	u8 devices;=0A-};=0A-=0A-/*************************=
******************************************************=0A- *=0A- * BOOT - =
Simple Boot Flag Table=0A- *=0A- ******************************************=
************************************/=0A-=0A-struct acpi_table_boot {=0A-	=
struct acpi_table_header header;	/* Common ACPI table header */=0A-	=
u8 cmos_index;		/* Index in CMOS RAM for the boot register */=0A-	=
u8 reserved[3];=0A-};=0A+/*=0A+ * Note: The generic error data that =
follows the error_severity field above=0A+ * uses the struct acpi_hest_gene=
ric_data defined under the HEST table below=0A+ */=0A =0A /****************=
***************************************************************=0A  *=0A- =
* CPEP - Corrected Platform Error Polling table=0A+ * CPEP - Corrected =
Platform Error Polling table (ACPI 4.0)=0A+ *        Version 1=0A  *=0A  =
***************************************************************************=
***/=0A =0A@@ -241,8 +170,7 @@ struct acpi_table_cpep {=0A /* Subtable =
*/=0A =0A struct acpi_cpep_polling {=0A-	u8 type;=0A-	u8 =
length;=0A+	struct acpi_subtable_header header;=0A 	u8 id;			=
/* Processor ID */=0A 	u8 eid;			/* Processor EID */=0A 	=
u32 interval;		/* Polling interval (msec) */=0A@@ -250,116 =
+178,103 @@ struct acpi_cpep_polling {=0A =0A /****************************=
***************************************************=0A  *=0A- * DBGP - =
Debug Port table=0A+ * ECDT - Embedded Controller Boot Resources Table=0A+ =
*        Version 1=0A  *=0A  **********************************************=
********************************/=0A =0A-struct acpi_table_dbgp {=0A+struct=
 acpi_table_ecdt {=0A 	struct acpi_table_header header;	/* Common =
ACPI table header */=0A-	u8 type;		/* 0=3Dfull 16550, =
1=3Dsubset of 16550 */=0A-	u8 reserved[3];=0A-	struct acpi_generic=
_address debug_port;=0A+	struct acpi_generic_address control;	/* =
Address of EC command/status register */=0A+	struct acpi_generic_address=
 data;	/* Address of EC data register */=0A+	u32 uid;		/* =
Unique ID - must be same as the EC _UID method */=0A+	u8 gpe;			=
/* The GPE for the EC */=0A+	u8 id[1];		/* Full namepath =
of the EC in the ACPI namespace */=0A };=0A =0A /**************************=
*****************************************************=0A  *=0A- * DMAR - =
DMA Remapping table=0A+ * EINJ - Error Injection Table (ACPI 4.0)=0A+ *    =
    Version 1=0A  *=0A  ***************************************************=
***************************/=0A =0A-struct acpi_table_dmar {=0A+struct =
acpi_table_einj {=0A 	struct acpi_table_header header;	/* Common =
ACPI table header */=0A-	u8 width;		/* Host Address =
Width */=0A+	u32 header_length;=0A 	u8 flags;=0A-	u8 reserved[10];=0A=
-};=0A-=0A-/* DMAR subtable header */=0A-=0A-struct acpi_dmar_header {=0A-	=
u16 type;=0A-	u16 length;=0A-};=0A-=0A-/* Values for subtable type in =
struct acpi_dmar_header */=0A-=0A-enum acpi_dmar_type {=0A-	ACPI_DMAR_T=
YPE_HARDWARE_UNIT =3D 0,=0A-	ACPI_DMAR_TYPE_RESERVED_MEMORY =3D 1,=0A-	=
ACPI_DMAR_TYPE_ATSR =3D 2,=0A-	ACPI_DMAR_TYPE_RESERVED =3D 3	/* 3 and =
greater are reserved */=0A-};=0A-=0A-struct acpi_dmar_device_scope {=0A-	=
u8 entry_type;=0A-	u8 length;=0A-	u16 reserved;=0A-	u8 =
enumeration_id;=0A-	u8 bus;=0A+	u8 reserved[3];=0A+	u32 =
entries;=0A };=0A =0A-/* Values for entry_type in struct acpi_dmar_device_s=
cope */=0A+/* EINJ Injection Instruction Entries (actions) */=0A =0A-enum =
acpi_dmar_scope_type {=0A-	ACPI_DMAR_SCOPE_TYPE_NOT_USED =3D 0,=0A-	=
ACPI_DMAR_SCOPE_TYPE_ENDPOINT =3D 1,=0A-	ACPI_DMAR_SCOPE_TYPE_BRIDGE=
 =3D 2,=0A-	ACPI_DMAR_SCOPE_TYPE_IOAPIC =3D 3,=0A-	ACPI_DMAR_SCOPE_TYP=
E_HPET =3D 4,=0A-	ACPI_DMAR_SCOPE_TYPE_RESERVED =3D 5	/* 5 and =
greater are reserved */=0A+struct acpi_einj_entry {=0A+	struct acpi_whea_he=
ader whea_header;	/* Common header for WHEA tables */=0A };=0A =
=0A-struct acpi_dmar_pci_path {=0A-	u8 dev;=0A-	u8 fn;=0A-};=0A+/* =
Masks for Flags field above */=0A =0A-/*=0A- * DMAR Sub-tables, correspond =
to Type in struct acpi_dmar_header=0A- */=0A+#define ACPI_EINJ_PRESERVE    =
      (1)=0A =0A-/* 0: Hardware Unit Definition */=0A+/* Values for Action =
field above */=0A =0A-struct acpi_dmar_hardware_unit {=0A-	struct =
acpi_dmar_header header;=0A-	u8 flags;=0A-	u8 reserved;=0A-	=
u16 segment;=0A-	u64 address;		/* Register Base Address =
*/=0A+enum acpi_einj_actions {=0A+	ACPI_EINJ_BEGIN_OPERATION =3D =
0,=0A+	ACPI_EINJ_GET_TRIGGER_TABLE =3D 1,=0A+	ACPI_EINJ_SET_ERROR_TYPE =
=3D 2,=0A+	ACPI_EINJ_GET_ERROR_TYPE =3D 3,=0A+	ACPI_EINJ_END_OPERA=
TION =3D 4,=0A+	ACPI_EINJ_EXECUTE_OPERATION =3D 5,=0A+	ACPI_EINJ_CHECK_BUS=
Y_STATUS =3D 6,=0A+	ACPI_EINJ_GET_COMMAND_STATUS =3D 7,=0A+	ACPI_EINJ_A=
CTION_RESERVED =3D 8,	/* 8 and greater are reserved */=0A+	ACPI_EINJ_T=
RIGGER_ERROR =3D 0xFF	/* Except for this value */=0A };=0A =0A-/* Flags =
*/=0A-=0A-#define ACPI_DMAR_INCLUDE_ALL       (1)=0A-=0A-/* 1: Reserved =
Memory Defininition */=0A+/* Values for Instruction field above */=0A =
=0A-struct acpi_dmar_reserved_memory {=0A-	struct acpi_dmar_header =
header;=0A-	u16 reserved;=0A-	u16 segment;=0A-	u64 =
base_address;		/* 4_k aligned base address */=0A-	u64 =
end_address;	/* 4_k aligned limit address */=0A+enum acpi_einj_instructi=
ons {=0A+	ACPI_EINJ_READ_REGISTER =3D 0,=0A+	ACPI_EINJ_READ_REGI=
STER_VALUE =3D 1,=0A+	ACPI_EINJ_WRITE_REGISTER =3D 2,=0A+	ACPI_EINJ_W=
RITE_REGISTER_VALUE =3D 3,=0A+	ACPI_EINJ_NOOP =3D 4,=0A+	ACPI_EINJ_I=
NSTRUCTION_RESERVED =3D 5	/* 5 and greater are reserved */=0A+};=0A+=
=0A+/* EINJ Trigger Error Action Table */=0A+=0A+struct acpi_einj_trigger =
{=0A+	u32 header_size;=0A+	u32 revision;=0A+	u32 table_size;=0A+=
	u32 entry_count;=0A };=0A =0A-/* Flags */=0A+/* Command status =
return values */=0A =0A-#define ACPI_DMAR_ALLOW_ALL         (1)=0A-=0A-/***=
***************************************************************************=
*=0A- *=0A- * ECDT - Embedded Controller Boot Resources Table=0A- *=0A- =
***************************************************************************=
***/=0A-=0A-struct acpi_table_ecdt {=0A-	struct acpi_table_header =
header;	/* Common ACPI table header */=0A-	struct acpi_generic_address=
 control;	/* Address of EC command/status register */=0A-	struct =
acpi_generic_address data;	/* Address of EC data register */=0A-	=
u32 uid;		/* Unique ID - must be same as the EC _UID method =
*/=0A-	u8 gpe;			/* The GPE for the EC */=0A-	u8 id[1];	=
	/* Full namepath of the EC in the ACPI namespace */=0A-};=0A+enum =
acpi_einj_command_status {=0A+	ACPI_EINJ_SUCCESS =3D 0,=0A+	ACPI_EINJ_F=
AILURE =3D 1,=0A+	ACPI_EINJ_INVALID_ACCESS =3D 2,=0A+	ACPI_EINJ_S=
TATUS_RESERVED =3D 3	/* 3 and greater are reserved */=0A+};=0A+=0A+/* =
Error types returned from ACPI_EINJ_GET_ERROR_TYPE (bitfield) */=0A+=0A+#de=
fine ACPI_EINJ_PROCESSOR_CORRECTABLE     (1)=0A+#define ACPI_EINJ_PROCESSOR=
_UNCORRECTABLE   (1<<1)=0A+#define ACPI_EINJ_PROCESSOR_FATAL           =
(1<<2)=0A+#define ACPI_EINJ_MEMORY_CORRECTABLE        (1<<3)=0A+#define =
ACPI_EINJ_MEMORY_UNCORRECTABLE      (1<<4)=0A+#define ACPI_EINJ_MEMORY_FATA=
L              (1<<5)=0A+#define ACPI_EINJ_PCIX_CORRECTABLE          =
(1<<6)=0A+#define ACPI_EINJ_PCIX_UNCORRECTABLE        (1<<7)=0A+#define =
ACPI_EINJ_PCIX_FATAL                (1<<8)=0A+#define ACPI_EINJ_PLATFORM_CO=
RRECTABLE      (1<<9)=0A+#define ACPI_EINJ_PLATFORM_UNCORRECTABLE    =
(1<<10)=0A+#define ACPI_EINJ_PLATFORM_FATAL            (1<<11)=0A =0A =
/**************************************************************************=
*****=0A  *=0A@@ -453,30 +368,237 @@ struct acpi_erst_info {=0A =0A =
/**************************************************************************=
*****=0A  *=0A- * HPET - High Precision Event Timer table=0A+ * HEST - =
Hardware Error Source Table (ACPI 4.0)=0A+ *        Version 1=0A  *=0A  =
***************************************************************************=
***/=0A =0A-struct acpi_table_hpet {=0A+struct acpi_table_hest {=0A 	=
struct acpi_table_header header;	/* Common ACPI table header */=0A-	=
u32 id;			/* Hardware ID of event timer block */=0A-	=
struct acpi_generic_address address;	/* Address of event timer block =
*/=0A-	u8 sequence;		/* HPET sequence number */=0A-	u16 =
minimum_tick;	/* Main counter min tick, periodic mode */=0A+	u32 =
error_source_count;=0A+};=0A+=0A+/* HEST subtable header */=0A+=0A+struct =
acpi_hest_header {=0A+	u16 type;=0A+	u16 source_id;=0A+};=0A+=0A+/* =
Values for Type field above for subtables */=0A+=0A+enum acpi_hest_types =
{=0A+	ACPI_HEST_TYPE_IA32_CHECK =3D 0,=0A+	ACPI_HEST_TYPE_IA32_CORRECT=
ED_CHECK =3D 1,=0A+	ACPI_HEST_TYPE_IA32_NMI =3D 2,=0A+	ACPI_HEST_T=
YPE_NOT_USED3 =3D 3,=0A+	ACPI_HEST_TYPE_NOT_USED4 =3D 4,=0A+	=
ACPI_HEST_TYPE_NOT_USED5 =3D 5,=0A+	ACPI_HEST_TYPE_AER_ROOT_PORT =3D =
6,=0A+	ACPI_HEST_TYPE_AER_ENDPOINT =3D 7,=0A+	ACPI_HEST_TYPE_AER_BRIDGE =
=3D 8,=0A+	ACPI_HEST_TYPE_GENERIC_ERROR =3D 9,=0A+	ACPI_HEST_TYPE_RESE=
RVED =3D 10	/* 10 and greater are reserved */=0A+};=0A+=0A+/*=0A+ * =
HEST substructures contained in subtables=0A+ */=0A+=0A+/*=0A+ * IA32 =
Error Bank(s) - Follows the struct acpi_hest_ia_machine_check and=0A+ * =
struct acpi_hest_ia_corrected structures.=0A+ */=0A+struct acpi_hest_ia_err=
or_bank {=0A+	u8 bank_number;=0A+	u8 clear_status_on_init;=0A+	u8 =
status_format;=0A+	u8 reserved;=0A+	u32 control_register;=0A+	=
u64 control_data;=0A+	u32 status_register;=0A+	u32 address_registe=
r;=0A+	u32 misc_register;=0A+};=0A+=0A+/* Common HEST sub-structure for =
PCI/AER structures below (6,7,8) */=0A+=0A+struct acpi_hest_aer_common =
{=0A+	u16 reserved1;=0A 	u8 flags;=0A+	u8 enabled;=0A+	u32 =
records_to_preallocate;=0A+	u32 max_sections_per_record;=0A+	=
u32 bus;=0A+	u16 device;=0A+	u16 function;=0A+	u16 device_control;=
=0A+	u16 reserved2;=0A+	u32 uncorrectable_mask;=0A+	u32 =
uncorrectable_severity;=0A+	u32 correctable_mask;=0A+	u32 =
advanced_capabilities;=0A };=0A =0A-/*! Flags */=0A+/* Masks for HEST =
Flags fields */=0A+=0A+#define ACPI_HEST_FIRMWARE_FIRST        (1)=0A+#defi=
ne ACPI_HEST_GLOBAL                (1<<1)=0A =0A-#define ACPI_HPET_PAGE_PRO=
TECT      (1)	/* 00: No page protection */=0A-#define ACPI_HPET_PAGE_PROT=
ECT_4    (1<<1)	/* 01: 4KB page protected */=0A-#define ACPI_HPET_PAGE_PROT=
ECT_64   (1<<2)	/* 02: 64KB page protected */=0A+/* Hardware Error =
Notification */=0A =0A-/*! [End] no source code translation !*/=0A+struct =
acpi_hest_notify {=0A+	u8 type;=0A+	u8 length;=0A+	u16 config_write_en=
able;=0A+	u32 poll_interval;=0A+	u32 vector;=0A+	u32 polling_thresho=
ld_value;=0A+	u32 polling_threshold_window;=0A+	u32 error_threshold=
_value;=0A+	u32 error_threshold_window;=0A+};=0A+=0A+/* Values for =
Notify Type field above */=0A+=0A+enum acpi_hest_notify_types {=0A+	=
ACPI_HEST_NOTIFY_POLLED =3D 0,=0A+	ACPI_HEST_NOTIFY_EXTERNAL =3D =
1,=0A+	ACPI_HEST_NOTIFY_LOCAL =3D 2,=0A+	ACPI_HEST_NOTIFY_SCI =3D =
3,=0A+	ACPI_HEST_NOTIFY_NMI =3D 4,=0A+	ACPI_HEST_NOTIFY_RESERVED =3D 5	/* =
5 and greater are reserved */=0A+};=0A+=0A+/* Values for config_write_enabl=
e bitfield above */=0A+=0A+#define ACPI_HEST_TYPE                  =
(1)=0A+#define ACPI_HEST_POLL_INTERVAL         (1<<1)=0A+#define ACPI_HEST_=
POLL_THRESHOLD_VALUE  (1<<2)=0A+#define ACPI_HEST_POLL_THRESHOLD_WINDOW =
(1<<3)=0A+#define ACPI_HEST_ERR_THRESHOLD_VALUE   (1<<4)=0A+#define =
ACPI_HEST_ERR_THRESHOLD_WINDOW  (1<<5)=0A+=0A+/*=0A+ * HEST subtables=0A+ =
*/=0A+=0A+/* 0: IA32 Machine Check Exception */=0A+=0A+struct acpi_hest_ia_=
machine_check {=0A+	struct acpi_hest_header header;=0A+	u16 =
reserved1;=0A+	u8 flags;=0A+	u8 enabled;=0A+	u32 records_to_preallocate;=
=0A+	u32 max_sections_per_record;=0A+	u64 global_capability_data;=
=0A+	u64 global_control_data;=0A+	u8 num_hardware_banks;=0A+	u8 =
reserved3[7];=0A+};=0A+=0A+/* 1: IA32 Corrected Machine Check */=0A+=0A+str=
uct acpi_hest_ia_corrected {=0A+	struct acpi_hest_header header;=0A+=
	u16 reserved1;=0A+	u8 flags;=0A+	u8 enabled;=0A+	u32 =
records_to_preallocate;=0A+	u32 max_sections_per_record;=0A+	=
struct acpi_hest_notify notify;=0A+	u8 num_hardware_banks;=0A+	u8 =
reserved2[3];=0A+};=0A+=0A+/* 2: IA32 Non-Maskable Interrupt */=0A+=0A+stru=
ct acpi_hest_ia_nmi {=0A+	struct acpi_hest_header header;=0A+	=
u32 reserved;=0A+	u32 records_to_preallocate;=0A+	u32 max_sections_pe=
r_record;=0A+	u32 max_raw_data_length;=0A+};=0A+=0A+/* 3,4,5: Not used =
*/=0A+=0A+/* 6: PCI Express Root Port AER */=0A+=0A+struct acpi_hest_aer_ro=
ot {=0A+	struct acpi_hest_header header;=0A+	struct acpi_hest_ae=
r_common aer;=0A+	u32 root_error_command;=0A+};=0A+=0A+/* 7: PCI =
Express AER (AER Endpoint) */=0A+=0A+struct acpi_hest_aer {=0A+	struct =
acpi_hest_header header;=0A+	struct acpi_hest_aer_common aer;=0A+};=0A+=
=0A+/* 8: PCI Express/PCI-X Bridge AER */=0A+=0A+struct acpi_hest_aer_bridg=
e {=0A+	struct acpi_hest_header header;=0A+	struct acpi_hest_aer_common=
 aer;=0A+	u32 uncorrectable_mask2;=0A+	u32 uncorrectable_severity2=
;=0A+	u32 advanced_capabilities2;=0A+};=0A+=0A+/* 9: Generic Hardware =
Error Source */=0A+=0A+struct acpi_hest_generic {=0A+	struct acpi_hest_he=
ader header;=0A+	u16 related_source_id;=0A+	u8 reserved;=0A+	=
u8 enabled;=0A+	u32 records_to_preallocate;=0A+	u32 max_sections_per_record=
;=0A+	u32 max_raw_data_length;=0A+	struct acpi_generic_address =
error_status_address;=0A+	struct acpi_hest_notify notify;=0A+	=
u32 error_block_length;=0A+};=0A+=0A+/* Generic Error Status block =
*/=0A+=0A+struct acpi_hest_generic_status {=0A+	u32 block_status;=0A+	=
u32 raw_data_offset;=0A+	u32 raw_data_length;=0A+	u32 =
data_length;=0A+	u32 error_severity;=0A+};=0A+=0A+/* Values for =
block_status flags above */=0A+=0A+#define ACPI_HEST_UNCORRECTABLE         =
    (1)=0A+#define ACPI_HEST_CORRECTABLE               (1<<1)=0A+#define =
ACPI_HEST_MULTIPLE_UNCORRECTABLE    (1<<2)=0A+#define ACPI_HEST_MULTIPLE_CO=
RRECTABLE      (1<<3)=0A+#define ACPI_HEST_ERROR_ENTRY_COUNT         =
(0xFF<<4)	/* 8 bits, error count */=0A+=0A+/* Generic Error Data =
entry */=0A+=0A+struct acpi_hest_generic_data {=0A+	u8 section_type[16]=
;=0A+	u32 error_severity;=0A+	u16 revision;=0A+	u8 validation_bits;=
=0A+	u8 flags;=0A+	u32 error_data_length;=0A+	u8 fru_id[16];=0A+	=
u8 fru_text[20];=0A+};=0A =0A /********************************************=
***********************************=0A  *=0A  * MADT - Multiple APIC =
Description Table=0A+ *        Version 3=0A  *=0A  ************************=
******************************************************/=0A =0A@@ -486,7 =
+608,7 @@ struct acpi_table_madt {=0A 	u32 flags;=0A };=0A =0A-/* Flags =
*/=0A+/* Masks for Flags field above */=0A =0A #define ACPI_MADT_PCAT_COMPA=
T       (1)	/* 00:    System also has dual 8259s */=0A =0A@@ -495,7 =
+617,7 @@ struct acpi_table_madt {=0A #define ACPI_MADT_DUAL_PIC          =
0=0A #define ACPI_MADT_MULTIPLE_APIC     1=0A =0A-/* Values for subtable =
type in struct acpi_subtable_header */=0A+/* Values for MADT subtable type =
in struct acpi_subtable_header */=0A =0A enum acpi_madt_type {=0A 	=
ACPI_MADT_TYPE_LOCAL_APIC =3D 0,=0A@@ -606,7 +728,7 @@ struct acpi_madt_int=
errupt_source {=0A 	u32 flags;		/* Interrupt Source Flags =
*/=0A };=0A =0A-/* Flags field above */=0A+/* Masks for Flags field above =
*/=0A =0A #define ACPI_MADT_CPEI_OVERRIDE     (1)=0A =0A@@ -615,9 +737,9 =
@@ struct acpi_madt_interrupt_source {=0A struct acpi_madt_local_x2apic =
{=0A 	struct acpi_subtable_header header;=0A 	u16 reserved;		/* =
Reserved - must be zero */=0A-	u32 local_apic_id;	/* Processor =
X2_APIC ID  */=0A+	u32 local_apic_id;	/* Processor x2APIC ID  =
*/=0A 	u32 lapic_flags;=0A-	u32 uid;		/* Extended =
X2_APIC processor ID */=0A+	u32 uid;		/* ACPI processor =
UID */=0A };=0A =0A /* 10: Local X2APIC NMI (ACPI 4.0) */=0A@@ -625,7 =
+747,7 @@ struct acpi_madt_local_x2apic {=0A struct acpi_madt_local_x2apic_=
nmi {=0A 	struct acpi_subtable_header header;=0A 	u16 inti_flags;=0A-=
	u32 uid;		/* Processor X2_APIC ID */=0A+	u32 uid;	=
	/* ACPI processor UID */=0A 	u8 lint;		/* LINTn =
to which NMI is connected */=0A 	u8 reserved[3];=0A };=0A@@ -657,28 =
+779,34 @@ struct acpi_madt_local_x2apic_nmi {=0A =0A /********************=
***********************************************************=0A  *=0A- * =
MCFG - PCI Memory Mapped Configuration table and sub-table=0A+ * MSCT - =
Maximum System Characteristics Table (ACPI 4.0)=0A+ *        Version 1=0A  =
*=0A  *********************************************************************=
*********/=0A =0A-struct acpi_table_mcfg {=0A+struct acpi_table_msct {=0A 	=
struct acpi_table_header header;	/* Common ACPI table header */=0A-	=
u8 reserved[8];=0A+	u32 proximity_offset;	/* Location of proximity =
info struct(s) */=0A+	u32 max_proximity_domains;	/* Max number of =
proximity domains */=0A+	u32 max_clock_domains;	/* Max number of =
clock domains */=0A+	u64 max_address;	/* Max physical address in =
system */=0A };=0A =0A-/* Subtable */=0A+/* Subtable - Maximum Proximity =
Domain Information. Version 1 */=0A =0A-struct acpi_mcfg_allocation {=0A-	=
u64 address;		/* Base address, processor-relative */=0A-	=
u16 pci_segment;	/* PCI segment group number */=0A-	u8 =
start_bus_number;	/* Starting PCI Bus number */=0A-	u8 =
end_bus_number;	/* Final PCI Bus number */=0A-	u32 reserved;=0A+struct =
acpi_msct_proximity {=0A+	u8 revision;=0A+	u8 length;=0A+	=
u32 range_start;	/* Start of domain range */=0A+	u32 range_end;		=
/* End of domain range */=0A+	u32 processor_capacity;=0A+	u64 =
memory_capacity;	/* In bytes */=0A };=0A =0A /**********************=
*********************************************************=0A  *=0A  * SBST =
- Smart Battery Specification Table=0A+ *        Version 1=0A  *=0A  =
***************************************************************************=
***/=0A =0A@@ -692,6 +820,7 @@ struct acpi_table_sbst {=0A /***************=
****************************************************************=0A  *=0A  =
* SLIT - System Locality Distance Information Table=0A+ *        Version =
1=0A  *=0A  ***************************************************************=
***************/=0A =0A@@ -703,60 +832,8 @@ struct acpi_table_slit {=0A =
=0A /**********************************************************************=
*********=0A  *=0A- * SPCR - Serial Port Console Redirection table=0A- =
*=0A- *********************************************************************=
*********/=0A-=0A-struct acpi_table_spcr {=0A-	struct acpi_table_header =
header;	/* Common ACPI table header */=0A-	u8 interface_type;	/* =
0=3Dfull 16550, 1=3Dsubset of 16550 */=0A-	u8 reserved[3];=0A-	=
struct acpi_generic_address serial_port;=0A-	u8 interrupt_type;=0A-	u8 =
pc_interrupt;=0A-	u32 interrupt;=0A-	u8 baud_rate;=0A-	u8 =
parity;=0A-	u8 stop_bits;=0A-	u8 flow_control;=0A-	u8 =
terminal_type;=0A-	u8 reserved1;=0A-	u16 pci_device_id;=0A-	=
u16 pci_vendor_id;=0A-	u8 pci_bus;=0A-	u8 pci_device;=0A-	u8 =
pci_function;=0A-	u32 pci_flags;=0A-	u8 pci_segment;=0A-	=
u32 reserved2;=0A-};=0A-=0A-/**********************************************=
*********************************=0A- *=0A- * SPMI - Server Platform =
Management Interface table=0A- *=0A- **************************************=
****************************************/=0A-=0A-struct acpi_table_spmi =
{=0A-	struct acpi_table_header header;	/* Common ACPI table =
header */=0A-	u8 reserved;=0A-	u8 interface_type;=0A-	u16 =
spec_revision;	/* Version of IPMI */=0A-	u8 interrupt_type;=0A-	u8 =
gpe_number;		/* GPE assigned */=0A-	u8 reserved1;=0A-	u8 =
pci_device_flag;=0A-	u32 interrupt;=0A-	struct acpi_generic_address=
 ipmi_register;=0A-	u8 pci_segment;=0A-	u8 pci_bus;=0A-	u8 =
pci_device;=0A-	u8 pci_function;=0A-};=0A-=0A-/****************************=
***************************************************=0A- *=0A  * SRAT - =
System Resource Affinity Table=0A+ *        Version 3=0A  *=0A  ***********=
*******************************************************************/=0A =
=0A@@ -775,7 +852,9 @@ enum acpi_srat_type {=0A 	ACPI_SRAT_TYPE_RESE=
RVED =3D 3	/* 3 and greater are reserved */=0A };=0A =0A-/* SRAT =
sub-tables */=0A+/*=0A+ * SRAT Sub-tables, correspond to Type in struct =
acpi_subtable_header=0A+ */=0A =0A /* 0: Processor Local APIC/SAPIC =
Affinity */=0A =0A@@ -789,6 +868,10 @@ struct acpi_srat_cpu_affinity {=0A 	=
u32 reserved;		/* Reserved, must be zero */=0A };=0A =0A+/* Flags =
*/=0A+=0A+#define ACPI_SRAT_CPU_USE_AFFINITY  (1)	/* 00: Use =
affinity structure */=0A+=0A /* 1: Memory Affinity */=0A =0A struct =
acpi_srat_mem_affinity {=0A@@ -797,9 +880,9 @@ struct acpi_srat_mem_affinit=
y {=0A 	u16 reserved;		/* Reserved, must be zero */=0A 	=
u64 base_address;=0A 	u64 length;=0A-	u32 memory_type;	/* See =
acpi_address_range_id */=0A+	u32 reserved1;=0A 	u32 flags;=0A-	=
u64 reserved1;		/* Reserved, must be zero */=0A+	u64 =
reserved2;		/* Reserved, must be zero */=0A };=0A =0A /* Flags =
*/=0A@@ -824,44 +907,6 @@ struct acpi_srat_x2apic_cpu_affinity {=0A =0A =
#define ACPI_SRAT_CPU_ENABLED       (1)	/* 00: Use affinity structure =
*/=0A =0A-/****************************************************************=
***************=0A- *=0A- * TCPA - Trusted Computing Platform Alliance =
table=0A- *=0A- ***********************************************************=
*******************/=0A-=0A-struct acpi_table_tcpa {=0A-	struct =
acpi_table_header header;	/* Common ACPI table header */=0A-	=
u16 reserved;=0A-	u32 max_log_length;	/* Maximum length for the =
event log area */=0A-	u64 log_address;	/* Address of the event =
log area */=0A-};=0A-=0A-/*************************************************=
******************************=0A- *=0A- * WDRT - Watchdog Resource =
Table=0A- *=0A- ***********************************************************=
*******************/=0A-=0A-struct acpi_table_wdrt {=0A-	struct =
acpi_table_header header;	/* Common ACPI table header */=0A-	=
u32 header_length;	/* Watchdog Header Length */=0A-	u8 =
pci_segment;		/* PCI Segment number */=0A-	u8 pci_bus;		=
/* PCI Bus number */=0A-	u8 pci_device;		/* PCI Device =
number */=0A-	u8 pci_function;	/* PCI Function number */=0A-	=
u32 timer_period;	/* Period of one timer count (msec) */=0A-	=
u32 max_count;		/* Maximum counter value supported */=0A-	=
u32 min_count;		/* Minimum counter value */=0A-	u8 flags;=0A-	u8 =
reserved[3];=0A-	u32 entries;		/* Number of watchdog =
entries that follow */=0A-};=0A-=0A-/* Flags */=0A-=0A-#define ACPI_WDRT_TI=
MER_ENABLED     (1)	/* 00: Timer enabled */=0A-=0A /* Reset to default =
packing */=0A =0A #pragma pack()=0A--- /dev/null=0A+++ a/xen/include/acpi/a=
ctbl2.h=0A@@ -0,0 +1,1050 @@=0A+/******************************************=
************************************=0A+ *=0A+ * Name: actbl2.h - ACPI =
Table Definitions (tables not in ACPI spec)=0A+ *=0A+ *********************=
********************************************************/=0A+=0A+/*=0A+ * =
Copyright (C) 2000 - 2011, Intel Corp.=0A+ * All rights reserved.=0A+ =
*=0A+ * Redistribution and use in source and binary forms, with or =
without=0A+ * modification, are permitted provided that the following =
conditions=0A+ * are met:=0A+ * 1. Redistributions of source code must =
retain the above copyright=0A+ *    notice, this list of conditions, and =
the following disclaimer,=0A+ *    without modification.=0A+ * 2. =
Redistributions in binary form must reproduce at minimum a disclaimer=0A+ =
*    substantially similar to the "NO WARRANTY" disclaimer below=0A+ *    =
("Disclaimer") and any redistribution must be conditioned upon=0A+ *    =
including a substantially similar Disclaimer requirement for further=0A+ * =
   binary redistribution.=0A+ * 3. Neither the names of the above-listed =
copyright holders nor the names=0A+ *    of any contributors may be used =
to endorse or promote products derived=0A+ *    from this software without =
specific prior written permission.=0A+ *=0A+ * Alternatively, this =
software may be distributed under the terms of the=0A+ * GNU General =
Public License ("GPL") version 2 as published by the Free=0A+ * Software =
Foundation.=0A+ *=0A+ * NO WARRANTY=0A+ * THIS SOFTWARE IS PROVIDED BY THE =
COPYRIGHT HOLDERS AND CONTRIBUTORS=0A+ * "AS IS" AND ANY EXPRESS OR =
IMPLIED WARRANTIES, INCLUDING, BUT NOT=0A+ * LIMITED TO, THE IMPLIED =
WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR=0A+ * A PARTICULAR PURPOSE =
ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT=0A+ * HOLDERS OR CONTRIBUTO=
RS BE LIABLE FOR SPECIAL, EXEMPLARY, OR CONSEQUENTIAL=0A+ * DAMAGES =
(INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS=0A+ * OR =
SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)=0A+ * =
HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,=0A+ * =
STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING=0A+ =
* IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE=0A+ * =
POSSIBILITY OF SUCH DAMAGES.=0A+ */=0A+=0A+#ifndef __ACTBL2_H__=0A+#define =
__ACTBL2_H__=0A+=0A+/******************************************************=
*************************=0A+ *=0A+ * Additional ACPI Tables (2)=0A+ *=0A+ =
* These tables are not consumed directly by the ACPICA subsystem, but =
are=0A+ * included here to support device drivers and the AML disassembler.=
=0A+ *=0A+ * The tables in this file are defined by third-party specificati=
ons, and are=0A+ * not defined directly by the ACPI specification =
itself.=0A+ *=0A+ *********************************************************=
*********************/=0A+=0A+/*=0A+ * Values for description table header =
signatures for tables defined in this=0A+ * file. Useful because they make =
it more difficult to inadvertently type in=0A+ * the wrong signature.=0A+ =
*/=0A+#define ACPI_SIG_ASF            "ASF!"	/* Alert Standard Format =
table */=0A+#define ACPI_SIG_BOOT           "BOOT"	/* Simple Boot =
Flag Table */=0A+#define ACPI_SIG_DBGP           "DBGP"	/* Debug Port =
table */=0A+#define ACPI_SIG_DMAR           "DMAR"	/* DMA Remapping =
table */=0A+#define ACPI_SIG_HPET           "HPET"	/* High Precision =
Event Timer table */=0A+#define ACPI_SIG_IBFT           "IBFT"	/* i_sCSI =
Boot Firmware Table */=0A+#define ACPI_SIG_IVRS           "IVRS"	/* =
I/O Virtualization Reporting Structure */=0A+#define ACPI_SIG_MCFG         =
  "MCFG"	/* PCI Memory Mapped Configuration table */=0A+#define =
ACPI_SIG_MCHI           "MCHI"	/* Management Controller Host Interface =
table */=0A+#define ACPI_SIG_SLIC           "SLIC"	/* Software =
Licensing Description Table */=0A+#define ACPI_SIG_SPCR           "SPCR"	=
/* Serial Port Console Redirection table */=0A+#define ACPI_SIG_SPMI       =
    "SPMI"	/* Server Platform Management Interface table */=0A+#define=
 ACPI_SIG_TCPA           "TCPA"	/* Trusted Computing Platform Alliance =
table */=0A+#define ACPI_SIG_UEFI           "UEFI"	/* Uefi Boot =
Optimization Table */=0A+#define ACPI_SIG_WAET           "WAET"	/* Windows =
ACPI Emulated devices Table */=0A+#define ACPI_SIG_WDAT           "WDAT"	=
/* Watchdog Action Table */=0A+#define ACPI_SIG_WDDT           "WDDT"	/* =
Watchdog Timer Description Table */=0A+#define ACPI_SIG_WDRT           =
"WDRT"	/* Watchdog Resource Table */=0A+=0A+#ifdef ACPI_UNDEFINED_TABLES=
=0A+/*=0A+ * These tables have been seen in the field, but no definition =
has been found=0A+ */=0A+#define ACPI_SIG_ATKG           "ATKG"=0A+#define =
ACPI_SIG_GSCI           "GSCI"	/* GMCH SCI table */=0A+#define ACPI_SIG_IE=
IT           "IEIT"=0A+#endif=0A+=0A+/*=0A+ * All tables must be byte-packe=
d to match the ACPI specification, since=0A+ * the tables are provided by =
the system BIOS.=0A+ */=0A+#pragma pack(1)=0A+=0A+/*=0A+ * Note about =
bitfields: The u8 type is used for bitfields in ACPI tables.=0A+ * This is =
the only type that is even remotely portable. Anything else is not=0A+ * =
portable, so do not use any other bitfield types.=0A+ */=0A+=0A+/**********=
*********************************************************************=0A+ =
*=0A+ * ASF - Alert Standard Format table (Signature "ASF!")=0A+ *       =
Revision 0x10=0A+ *=0A+ * Conforms to the Alert Standard Format Specificati=
on V2.0, 23 April 2003=0A+ *=0A+ ******************************************=
************************************/=0A+=0A+struct acpi_table_asf {=0A+	=
struct acpi_table_header header;	/* Common ACPI table header =
*/=0A+};=0A+=0A+/* ASF subtable header */=0A+=0A+struct acpi_asf_header =
{=0A+	u8 type;=0A+	u8 reserved;=0A+	u16 length;=0A+};=0A+=0A+/*=
 Values for Type field above */=0A+=0A+enum acpi_asf_type {=0A+	ACPI_ASF_TY=
PE_INFO =3D 0,=0A+	ACPI_ASF_TYPE_ALERT =3D 1,=0A+	ACPI_ASF_TYPE_CONTR=
OL =3D 2,=0A+	ACPI_ASF_TYPE_BOOT =3D 3,=0A+	ACPI_ASF_TYPE_ADDRESS =3D =
4,=0A+	ACPI_ASF_TYPE_RESERVED =3D 5=0A+};=0A+=0A+/*=0A+ * ASF subtables=0A=
+ */=0A+=0A+/* 0: ASF Information */=0A+=0A+struct acpi_asf_info {=0A+	=
struct acpi_asf_header header;=0A+	u8 min_reset_value;=0A+	u8 =
min_poll_interval;=0A+	u16 system_id;=0A+	u32 mfg_id;=0A+	u8 =
flags;=0A+	u8 reserved2[3];=0A+};=0A+=0A+/* Masks for Flags field =
above */=0A+=0A+#define ACPI_ASF_SMBUS_PROTOCOLS    (1)=0A+=0A+/* 1: ASF =
Alerts */=0A+=0A+struct acpi_asf_alert {=0A+	struct acpi_asf_header =
header;=0A+	u8 assert_mask;=0A+	u8 deassert_mask;=0A+	u8 =
alerts;=0A+	u8 data_length;=0A+};=0A+=0A+struct acpi_asf_alert_data =
{=0A+	u8 address;=0A+	u8 command;=0A+	u8 mask;=0A+	u8 value;=0A+	u8 =
sensor_type;=0A+	u8 type;=0A+	u8 offset;=0A+	u8 source_type;=0A+=
	u8 severity;=0A+	u8 sensor_number;=0A+	u8 entity;=0A+	u8 =
instance;=0A+};=0A+=0A+/* 2: ASF Remote Control */=0A+=0A+struct acpi_asf_r=
emote {=0A+	struct acpi_asf_header header;=0A+	u8 controls;=0A+	=
u8 data_length;=0A+	u16 reserved2;=0A+};=0A+=0A+struct acpi_asf_control=
_data {=0A+	u8 function;=0A+	u8 address;=0A+	u8 command;=0A+	u8 =
value;=0A+};=0A+=0A+/* 3: ASF RMCP Boot Options */=0A+=0A+struct acpi_asf_r=
mcp {=0A+	struct acpi_asf_header header;=0A+	u8 capabilities[7];=
=0A+	u8 completion_code;=0A+	u32 enterprise_id;=0A+	u8 command;=0A+	=
u16 parameter;=0A+	u16 boot_options;=0A+	u16 oem_parameters;=0A+};=
=0A+=0A+/* 4: ASF Address */=0A+=0A+struct acpi_asf_address {=0A+	=
struct acpi_asf_header header;=0A+	u8 eprom_address;=0A+	u8 =
devices;=0A+};=0A+=0A+/****************************************************=
***************************=0A+ *=0A+ * BOOT - Simple Boot Flag Table=0A+ =
*        Version 1=0A+ *=0A+ * Conforms to the "Simple Boot Flag Specificat=
ion", Version 2.1=0A+ *=0A+ ***********************************************=
*******************************/=0A+=0A+struct acpi_table_boot {=0A+	=
struct acpi_table_header header;	/* Common ACPI table header */=0A+	=
u8 cmos_index;		/* Index in CMOS RAM for the boot register */=0A+	=
u8 reserved[3];=0A+};=0A+=0A+/*********************************************=
**********************************=0A+ *=0A+ * DBGP - Debug Port table=0A+ =
*        Version 1=0A+ *=0A+ * Conforms to the "Debug Port Specification", =
Version 1.00, 2/9/2000=0A+ *=0A+ ******************************************=
************************************/=0A+=0A+struct acpi_table_dbgp {=0A+	=
struct acpi_table_header header;	/* Common ACPI table header */=0A+	=
u8 type;		/* 0=3Dfull 16550, 1=3Dsubset of 16550 */=0A+	u8 =
reserved[3];=0A+	struct acpi_generic_address debug_port;=0A+};=0A+=
=0A+/**********************************************************************=
*********=0A+ *=0A+ * DMAR - DMA Remapping table=0A+ *        Version =
1=0A+ *=0A+ * Conforms to "Intel Virtualization Technology for Directed =
I/O",=0A+ * Version 1.2, Sept. 2008=0A+ *=0A+ *****************************=
*************************************************/=0A+=0A+struct acpi_table=
_dmar {=0A+	struct acpi_table_header header;	/* Common ACPI =
table header */=0A+	u8 width;		/* Host Address Width =
*/=0A+	u8 flags;=0A+	u8 reserved[10];=0A+};=0A+=0A+/* Masks for Flags =
field above */=0A+=0A+#define ACPI_DMAR_INTR_REMAP        (1)=0A+#define =
ACPI_DMAR_X2APIC_OPT_OUT    (1<<1)=0A+=0A+/* DMAR subtable header =
*/=0A+=0A+struct acpi_dmar_header {=0A+	u16 type;=0A+	u16 length;=0A+};=
=0A+=0A+/* Values for subtable type in struct acpi_dmar_header */=0A+=0A+en=
um acpi_dmar_type {=0A+	ACPI_DMAR_TYPE_HARDWARE_UNIT =3D 0,=0A+	ACPI_DMAR_T=
YPE_RESERVED_MEMORY =3D 1,=0A+	ACPI_DMAR_TYPE_ATSR =3D 2,=0A+	ACPI_DMAR_H=
ARDWARE_AFFINITY =3D 3,=0A+	ACPI_DMAR_TYPE_RESERVED =3D 4	/* 4 and =
greater are reserved */=0A+};=0A+=0A+/* DMAR Device Scope structure =
*/=0A+=0A+struct acpi_dmar_device_scope {=0A+	u8 entry_type;=0A+	u8 =
length;=0A+	u16 reserved;=0A+	u8 enumeration_id;=0A+	u8 =
bus;=0A+};=0A+=0A+/* Values for entry_type in struct acpi_dmar_device_scope=
 */=0A+=0A+enum acpi_dmar_scope_type {=0A+	ACPI_DMAR_SCOPE_TYPE_NOT_US=
ED =3D 0,=0A+	ACPI_DMAR_SCOPE_TYPE_ENDPOINT =3D 1,=0A+	ACPI_DMAR_S=
COPE_TYPE_BRIDGE =3D 2,=0A+	ACPI_DMAR_SCOPE_TYPE_IOAPIC =3D 3,=0A+	=
ACPI_DMAR_SCOPE_TYPE_HPET =3D 4,=0A+	ACPI_DMAR_SCOPE_TYPE_RESERVED =3D =
5	/* 5 and greater are reserved */=0A+};=0A+=0A+struct acpi_dmar_pci_=
path {=0A+	u8 dev;=0A+	u8 fn;=0A+};=0A+=0A+/*=0A+ * DMAR =
Sub-tables, correspond to Type in struct acpi_dmar_header=0A+ */=0A+=0A+/* =
0: Hardware Unit Definition */=0A+=0A+struct acpi_dmar_hardware_unit {=0A+	=
struct acpi_dmar_header header;=0A+	u8 flags;=0A+	u8 reserved;=0A+	=
u16 segment;=0A+	u64 address;		/* Register Base Address =
*/=0A+};=0A+=0A+/* Masks for Flags field above */=0A+=0A+#define ACPI_DMAR_=
INCLUDE_ALL       (1)=0A+=0A+/* 1: Reserved Memory Defininition */=0A+=0A+s=
truct acpi_dmar_reserved_memory {=0A+	struct acpi_dmar_header header;=0A+=
	u16 reserved;=0A+	u16 segment;=0A+	u64 base_address;	=
/* 4_k aligned base address */=0A+	u64 end_address;	/* 4_k =
aligned limit address */=0A+};=0A+=0A+/* Masks for Flags field above =
*/=0A+=0A+#define ACPI_DMAR_ALLOW_ALL         (1)=0A+=0A+/* 2: Root Port =
ATS Capability Reporting Structure */=0A+=0A+struct acpi_dmar_atsr {=0A+	=
struct acpi_dmar_header header;=0A+	u8 flags;=0A+	u8 reserved;=0A+	=
u16 segment;=0A+};=0A+=0A+/* Masks for Flags field above */=0A+=0A+#define =
ACPI_DMAR_ALL_PORTS         (1)=0A+=0A+/* 3: Remapping Hardware Static =
Affinity Structure */=0A+=0A+struct acpi_dmar_rhsa {=0A+	struct =
acpi_dmar_header header;=0A+	u32 reserved;=0A+	u64 base_address;=
=0A+	u32 proximity_domain;=0A+};=0A+=0A+/*******************************=
************************************************=0A+ *=0A+ * HPET - High =
Precision Event Timer table=0A+ *        Version 1=0A+ *=0A+ * Conforms to =
"IA-PC HPET (High Precision Event Timers) Specification",=0A+ * Version =
1.0a, October 2004=0A+ *=0A+ **********************************************=
********************************/=0A+=0A+struct acpi_table_hpet {=0A+	=
struct acpi_table_header header;	/* Common ACPI table header */=0A+	=
u32 id;			/* Hardware ID of event timer block */=0A+	=
struct acpi_generic_address address;	/* Address of event timer block =
*/=0A+	u8 sequence;		/* HPET sequence number */=0A+	u16 =
minimum_tick;	/* Main counter min tick, periodic mode */=0A+	u8 =
flags;=0A+};=0A+=0A+/* Masks for Flags field above */=0A+=0A+#define =
ACPI_HPET_PAGE_PROTECT_MASK (3)=0A+=0A+/* Values for Page Protect flags =
*/=0A+=0A+enum acpi_hpet_page_protect {=0A+	ACPI_HPET_NO_PAGE_PROTECT =
=3D 0,=0A+	ACPI_HPET_PAGE_PROTECT4 =3D 1,=0A+	ACPI_HPET_PAGE_PROT=
ECT64 =3D 2=0A+};=0A+=0A+/*************************************************=
******************************=0A+ *=0A+ * IBFT - Boot Firmware Table=0A+ =
*        Version 1=0A+ *=0A+ * Conforms to "iSCSI Boot Firmware Table =
(iBFT) as Defined in ACPI 3.0b=0A+ * Specification", Version 1.01, March =
1, 2007=0A+ *=0A+ * Note: It appears that this table is not intended to =
appear in the RSDT/XSDT.=0A+ * Therefore, it is not currently supported by =
the disassembler.=0A+ *=0A+ ***********************************************=
*******************************/=0A+=0A+struct acpi_table_ibft {=0A+	=
struct acpi_table_header header;	/* Common ACPI table header */=0A+	=
u8 reserved[12];=0A+};=0A+=0A+/* IBFT common subtable header */=0A+=0A+stru=
ct acpi_ibft_header {=0A+	u8 type;=0A+	u8 version;=0A+	u16 =
length;=0A+	u8 index;=0A+	u8 flags;=0A+};=0A+=0A+/* Values for Type =
field above */=0A+=0A+enum acpi_ibft_type {=0A+	ACPI_IBFT_TYPE_NOT_USED =
=3D 0,=0A+	ACPI_IBFT_TYPE_CONTROL =3D 1,=0A+	ACPI_IBFT_TYPE_INIT=
IATOR =3D 2,=0A+	ACPI_IBFT_TYPE_NIC =3D 3,=0A+	ACPI_IBFT_TYPE_TARG=
ET =3D 4,=0A+	ACPI_IBFT_TYPE_EXTENSIONS =3D 5,=0A+	ACPI_IBFT_TYPE_RESE=
RVED =3D 6	/* 6 and greater are reserved */=0A+};=0A+=0A+/* IBFT =
subtables */=0A+=0A+struct acpi_ibft_control {=0A+	struct acpi_ibft_he=
ader header;=0A+	u16 extensions;=0A+	u16 initiator_offset;=0A+	=
u16 nic0_offset;=0A+	u16 target0_offset;=0A+	u16 nic1_offset;=0A+	=
u16 target1_offset;=0A+};=0A+=0A+struct acpi_ibft_initiator {=0A+	=
struct acpi_ibft_header header;=0A+	u8 sns_server[16];=0A+	u8 =
slp_server[16];=0A+	u8 primary_server[16];=0A+	u8 secondary_server=
[16];=0A+	u16 name_length;=0A+	u16 name_offset;=0A+};=0A+=0A+struc=
t acpi_ibft_nic {=0A+	struct acpi_ibft_header header;=0A+	u8 =
ip_address[16];=0A+	u8 subnet_mask_prefix;=0A+	u8 origin;=0A+	u8 =
gateway[16];=0A+	u8 primary_dns[16];=0A+	u8 secondary_dns[16];=0A+	=
u8 dhcp[16];=0A+	u16 vlan;=0A+	u8 mac_address[6];=0A+	u16 =
pci_address;=0A+	u16 name_length;=0A+	u16 name_offset;=0A+};=0A+=
=0A+struct acpi_ibft_target {=0A+	struct acpi_ibft_header header;=0A+=
	u8 target_ip_address[16];=0A+	u16 target_ip_socket;=0A+	u8 =
target_boot_lun[8];=0A+	u8 chap_type;=0A+	u8 nic_association;=0A+	=
u16 target_name_length;=0A+	u16 target_name_offset;=0A+	u16 =
chap_name_length;=0A+	u16 chap_name_offset;=0A+	u16 chap_secret_len=
gth;=0A+	u16 chap_secret_offset;=0A+	u16 reverse_chap_name_lengt=
h;=0A+	u16 reverse_chap_name_offset;=0A+	u16 reverse_chap_secret_len=
gth;=0A+	u16 reverse_chap_secret_offset;=0A+};=0A+=0A+/*************=
******************************************************************=0A+ =
*=0A+ * IVRS - I/O Virtualization Reporting Structure=0A+ *        Version =
1=0A+ *=0A+ * Conforms to "AMD I/O Virtualization Technology (IOMMU) =
Specification",=0A+ * Revision 1.26, February 2009.=0A+ *=0A+ *************=
*****************************************************************/=0A+=0A+s=
truct acpi_table_ivrs {=0A+	struct acpi_table_header header;	/* =
Common ACPI table header */=0A+	u32 info;		/* Common =
virtualization info */=0A+	u64 reserved;=0A+};=0A+=0A+/* Values for =
Info field above */=0A+=0A+#define ACPI_IVRS_PHYSICAL_SIZE     0x00007F00	=
/* 7 bits, physical address size */=0A+#define ACPI_IVRS_VIRTUAL_SIZE      =
0x003F8000	/* 7 bits, virtual address size */=0A+#define ACPI_IVRS_ATS=
_RESERVED      0x00400000	/* ATS address translation range reserved =
*/=0A+=0A+/* IVRS subtable header */=0A+=0A+struct acpi_ivrs_header {=0A+	=
u8 type;		/* Subtable type */=0A+	u8 flags;=0A+	u16 =
length;		/* Subtable length */=0A+	u16 device_id;		/* =
ID of IOMMU */=0A+};=0A+=0A+/* Values for subtable Type above */=0A+=0A+enu=
m acpi_ivrs_type {=0A+	ACPI_IVRS_TYPE_HARDWARE =3D 0x10,=0A+	ACPI_IVRS_T=
YPE_MEMORY_ALL /* _MEMORY1 */ =3D 0x20,=0A+	ACPI_IVRS_TYPE_MEMORY_ONE =
/* _MEMORY2 */ =3D 0x21,=0A+	ACPI_IVRS_TYPE_MEMORY_RANGE /* _MEMORY3 */ =
=3D 0x22,=0A+	ACPI_IVRS_TYPE_MEMORY_IOMMU =3D 0x23=0A+};=0A+=0A+/* Masks =
for Flags field above for IVHD subtable */=0A+=0A+#define ACPI_IVHD_TT_ENAB=
LE         (1)=0A+#define ACPI_IVHD_PASS_PW           (1<<1)=0A+#define =
ACPI_IVHD_RES_PASS_PW       (1<<2)=0A+#define ACPI_IVHD_ISOC              =
(1<<3)=0A+#define ACPI_IVHD_IOTLB             (1<<4)=0A+=0A+/* Masks for =
Flags field above for IVMD subtable */=0A+=0A+#define ACPI_IVMD_UNITY      =
       (1)=0A+#define ACPI_IVMD_READ              (1<<1)=0A+#define =
ACPI_IVMD_WRITE             (1<<2)=0A+#define ACPI_IVMD_EXCLUSION_RANGE   =
(1<<3)=0A+=0A+/*=0A+ * IVRS subtables, correspond to Type in struct =
acpi_ivrs_header=0A+ */=0A+=0A+/* 0x10: I/O Virtualization Hardware =
Definition Block (IVHD) */=0A+=0A+struct acpi_ivrs_hardware {=0A+	=
struct acpi_ivrs_header header;=0A+	u16 capability_offset;	/* Offset =
for IOMMU control fields */=0A+	u64 base_address;	/* IOMMU control =
registers */=0A+	u16 pci_segment_group;=0A+	u16 info;		=
/* MSI number and unit ID */=0A+	u32 reserved;=0A+};=0A+=0A+/* =
Masks for Info field above */=0A+=0A+#define ACPI_IVHD_MSI_NUMBER_MASK   =
0x001F	/* 5 bits, MSI message number */=0A+#define ACPI_IVHD_UNIT_ID_MASK =
     0x1F00	/* 5 bits, unit_iD */=0A+=0A+/*=0A+ * Device Entries for =
IVHD subtable, appear after struct acpi_ivrs_hardware structure.=0A+ * =
Upper two bits of the Type field are the (encoded) length of the structure.=
=0A+ * Currently, only 4 and 8 byte entries are defined. 16 and 32 byte =
entries=0A+ * are reserved for future use but not defined.=0A+ */=0A+struct=
 acpi_ivrs_de_header {=0A+	u8 type;=0A+	u16 id;=0A+	u8 =
data_setting;=0A+};=0A+=0A+/* Length of device entry is in the top two =
bits of Type field above */=0A+=0A+#define ACPI_IVHD_ENTRY_LENGTH      =
0xC0=0A+=0A+/* Values for device entry Type field above */=0A+=0A+enum =
acpi_ivrs_device_entry_type {=0A+	/* 4-byte device entries, all use =
struct acpi_ivrs_device4 */=0A+=0A+	ACPI_IVRS_TYPE_PAD4 =3D 0,=0A+	=
ACPI_IVRS_TYPE_ALL =3D 1,=0A+	ACPI_IVRS_TYPE_SELECT =3D 2,=0A+	=
ACPI_IVRS_TYPE_START =3D 3,=0A+	ACPI_IVRS_TYPE_END =3D 4,=0A+=0A+	/* =
8-byte device entries */=0A+=0A+	ACPI_IVRS_TYPE_PAD8 =3D 64,=0A+	=
ACPI_IVRS_TYPE_NOT_USED =3D 65,=0A+	ACPI_IVRS_TYPE_ALIAS_SELECT =3D =
66,	/* Uses struct acpi_ivrs_device8a */=0A+	ACPI_IVRS_TYPE_ALIA=
S_START =3D 67,	/* Uses struct acpi_ivrs_device8a */=0A+	ACPI_IVRS_T=
YPE_EXT_SELECT =3D 70,	/* Uses struct acpi_ivrs_device8b */=0A+	=
ACPI_IVRS_TYPE_EXT_START =3D 71,	/* Uses struct acpi_ivrs_device8b =
*/=0A+	ACPI_IVRS_TYPE_SPECIAL =3D 72	/* Uses struct acpi_ivrs_device8c =
*/=0A+};=0A+=0A+/* Values for Data field above */=0A+=0A+#define ACPI_IVHD_=
INIT_PASS         (1)=0A+#define ACPI_IVHD_EINT_PASS         (1<<1)=0A+#def=
ine ACPI_IVHD_NMI_PASS          (1<<2)=0A+#define ACPI_IVHD_SYSTEM_MGMT    =
   (3<<4)=0A+#define ACPI_IVHD_LINT0_PASS        (1<<6)=0A+#define =
ACPI_IVHD_LINT1_PASS        (1<<7)=0A+=0A+/* Types 0-4: 4-byte device =
entry */=0A+=0A+struct acpi_ivrs_device4 {=0A+	struct acpi_ivrs_de_header =
header;=0A+};=0A+=0A+/* Types 66-67: 8-byte device entry */=0A+=0A+struct =
acpi_ivrs_device8a {=0A+	struct acpi_ivrs_de_header header;=0A+	u8 =
reserved1;=0A+	u16 used_id;=0A+	u8 reserved2;=0A+};=0A+=0A+/* =
Types 70-71: 8-byte device entry */=0A+=0A+struct acpi_ivrs_device8b {=0A+	=
struct acpi_ivrs_de_header header;=0A+	u32 extended_data;=0A+};=0A+=0A+/* =
Values for extended_data above */=0A+=0A+#define ACPI_IVHD_ATS_DISABLED    =
  (1<<31)=0A+=0A+/* Type 72: 8-byte device entry */=0A+=0A+struct =
acpi_ivrs_device8c {=0A+	struct acpi_ivrs_de_header header;=0A+	u8 =
handle;=0A+	u16 used_id;=0A+	u8 variety;=0A+};=0A+=0A+/* Values =
for Variety field above */=0A+=0A+#define ACPI_IVHD_IOAPIC            =
1=0A+#define ACPI_IVHD_HPET              2=0A+=0A+/* 0x20, 0x21, 0x22: I/O =
Virtualization Memory Definition Block (IVMD) */=0A+=0A+struct acpi_ivrs_me=
mory {=0A+	struct acpi_ivrs_header header;=0A+	u16 aux_data;=0A+	=
u64 reserved;=0A+	u64 start_address;=0A+	u64 memory_length;=0A+};=0A=
+=0A+/*********************************************************************=
**********=0A+ *=0A+ * MCFG - PCI Memory Mapped Configuration table and =
sub-table=0A+ *        Version 1=0A+ *=0A+ * Conforms to "PCI Firmware =
Specification", Revision 3.0, June 20, 2005=0A+ *=0A+ *********************=
*********************************************************/=0A+=0A+struct =
acpi_table_mcfg {=0A+	struct acpi_table_header header;	/* Common =
ACPI table header */=0A+	u8 reserved[8];=0A+};=0A+=0A+/* Subtable =
*/=0A+=0A+struct acpi_mcfg_allocation {=0A+	u64 address;		/* =
Base address, processor-relative */=0A+	u16 pci_segment;	/* PCI =
segment group number */=0A+	u8 start_bus_number;	/* Starting PCI =
Bus number */=0A+	u8 end_bus_number;	/* Final PCI Bus number =
*/=0A+	u32 reserved;=0A+};=0A+=0A+/***************************************=
****************************************=0A+ *=0A+ * MCHI - Management =
Controller Host Interface Table=0A+ *        Version 1=0A+ *=0A+ * =
Conforms to "Management Component Transport Protocol (MCTP) Host=0A+ * =
Interface Specification", Revision 1.0.0a, October 13, 2009=0A+ *=0A+ =
***************************************************************************=
***/=0A+=0A+struct acpi_table_mchi {=0A+	struct acpi_table_header =
header;	/* Common ACPI table header */=0A+	u8 interface_type;=0A+	u8 =
protocol;=0A+	u64 protocol_data;=0A+	u8 interrupt_type;=0A+	u8 =
gpe;=0A+	u8 pci_device_flag;=0A+	u32 global_interrupt;=0A+	=
struct acpi_generic_address control_register;=0A+	u8 pci_segment;=0A+=
	u8 pci_bus;=0A+	u8 pci_device;=0A+	u8 pci_function;=0A+};=0A+=
=0A+/**********************************************************************=
*********=0A+ *=0A+ * SLIC - Software Licensing Description Table=0A+ *    =
    Version 1=0A+ *=0A+ * Conforms to "OEM Activation 2.0 for Windows =
Vista Operating Systems",=0A+ * Copyright 2006=0A+ *=0A+ ******************=
************************************************************/=0A+=0A+/* =
Basic SLIC table is only the common ACPI header */=0A+=0A+struct acpi_table=
_slic {=0A+	struct acpi_table_header header;	/* Common ACPI =
table header */=0A+};=0A+=0A+/* Common SLIC subtable header */=0A+=0A+struc=
t acpi_slic_header {=0A+	u32 type;=0A+	u32 length;=0A+};=0A+=0A+/*=
 Values for Type field above */=0A+=0A+enum acpi_slic_type {=0A+	=
ACPI_SLIC_TYPE_PUBLIC_KEY =3D 0,=0A+	ACPI_SLIC_TYPE_WINDOWS_MARKER =3D =
1,=0A+	ACPI_SLIC_TYPE_RESERVED =3D 2	/* 2 and greater are reserved =
*/=0A+};=0A+=0A+/*=0A+ * SLIC Sub-tables, correspond to Type in struct =
acpi_slic_header=0A+ */=0A+=0A+/* 0: Public Key Structure */=0A+=0A+struct =
acpi_slic_key {=0A+	struct acpi_slic_header header;=0A+	u8 =
key_type;=0A+	u8 version;=0A+	u16 reserved;=0A+	u32 algorithm;=0A+	=
char magic[4];=0A+	u32 bit_length;=0A+	u32 exponent;=0A+	u8 =
modulus[128];=0A+};=0A+=0A+/* 1: Windows Marker Structure */=0A+=0A+struct =
acpi_slic_marker {=0A+	struct acpi_slic_header header;=0A+	u32 =
version;=0A+	char oem_id[ACPI_OEM_ID_SIZE];	/* ASCII OEM identification=
 */=0A+	char oem_table_id[ACPI_OEM_TABLE_ID_SIZE];	/* ASCII OEM table =
identification */=0A+	char windows_flag[8];=0A+	u32 slic_version;=
=0A+	u8 reserved[16];=0A+	u8 signature[128];=0A+};=0A+=0A+/**********=
*********************************************************************=0A+ =
*=0A+ * SPCR - Serial Port Console Redirection table=0A+ *        Version =
1=0A+ *=0A+ * Conforms to "Serial Port Console Redirection Table",=0A+ * =
Version 1.00, January 11, 2002=0A+ *=0A+ **********************************=
********************************************/=0A+=0A+struct acpi_table_spcr=
 {=0A+	struct acpi_table_header header;	/* Common ACPI table =
header */=0A+	u8 interface_type;	/* 0=3Dfull 16550, 1=3Dsubset of =
16550 */=0A+	u8 reserved[3];=0A+	struct acpi_generic_address =
serial_port;=0A+	u8 interrupt_type;=0A+	u8 pc_interrupt;=0A+	=
u32 interrupt;=0A+	u8 baud_rate;=0A+	u8 parity;=0A+	u8 =
stop_bits;=0A+	u8 flow_control;=0A+	u8 terminal_type;=0A+	u8 =
reserved1;=0A+	u16 pci_device_id;=0A+	u16 pci_vendor_id;=0A+	u8 =
pci_bus;=0A+	u8 pci_device;=0A+	u8 pci_function;=0A+	u32 =
pci_flags;=0A+	u8 pci_segment;=0A+	u32 reserved2;=0A+};=0A+=0A+/* =
Masks for pci_flags field above */=0A+=0A+#define ACPI_SPCR_DO_NOT_DISABLE =
   (1)=0A+=0A+/************************************************************=
*******************=0A+ *=0A+ * SPMI - Server Platform Management =
Interface table=0A+ *        Version 5=0A+ *=0A+ * Conforms to "Intelligent=
 Platform Management Interface Specification=0A+ * Second Generation =
v2.0", Document Revision 1.0, February 12, 2004 with=0A+ * June 12, 2009 =
markup.=0A+ *=0A+ *********************************************************=
*********************/=0A+=0A+struct acpi_table_spmi {=0A+	struct =
acpi_table_header header;	/* Common ACPI table header */=0A+	u8 =
interface_type;=0A+	u8 reserved;		/* Must be 1 */=0A+	=
u16 spec_revision;	/* Version of IPMI */=0A+	u8 interrupt_type;=
=0A+	u8 gpe_number;		/* GPE assigned */=0A+	u8 reserved1;=0A+	=
u8 pci_device_flag;=0A+	u32 interrupt;=0A+	struct acpi_generic_address=
 ipmi_register;=0A+	u8 pci_segment;=0A+	u8 pci_bus;=0A+	u8 =
pci_device;=0A+	u8 pci_function;=0A+	u8 reserved2;=0A+};=0A+=0A+/* =
Values for interface_type above */=0A+=0A+enum acpi_spmi_interface_types =
{=0A+	ACPI_SPMI_NOT_USED =3D 0,=0A+	ACPI_SPMI_KEYBOARD =3D 1,=0A+	=
ACPI_SPMI_SMI =3D 2,=0A+	ACPI_SPMI_BLOCK_TRANSFER =3D 3,=0A+	=
ACPI_SPMI_SMBUS =3D 4,=0A+	ACPI_SPMI_RESERVED =3D 5	/* 5 and =
above are reserved */=0A+};=0A+=0A+/***************************************=
****************************************=0A+ *=0A+ * TCPA - Trusted =
Computing Platform Alliance table=0A+ *        Version 1=0A+ *=0A+ * =
Conforms to "TCG PC Specific Implementation Specification",=0A+ * Version =
1.1, August 18, 2003=0A+ *=0A+ ********************************************=
**********************************/=0A+=0A+struct acpi_table_tcpa {=0A+	=
struct acpi_table_header header;	/* Common ACPI table header */=0A+	=
u16 reserved;=0A+	u32 max_log_length;	/* Maximum length for the =
event log area */=0A+	u64 log_address;	/* Address of the event =
log area */=0A+};=0A+=0A+/*************************************************=
******************************=0A+ *=0A+ * UEFI - UEFI Boot optimization =
Table=0A+ *        Version 1=0A+ *=0A+ * Conforms to "Unified Extensible =
Firmware Interface Specification",=0A+ * Version 2.3, May 8, 2009=0A+ =
*=0A+ *********************************************************************=
*********/=0A+=0A+struct acpi_table_uefi {=0A+	struct acpi_table_header =
header;	/* Common ACPI table header */=0A+	u8 identifier[16];	/* =
UUID identifier */=0A+	u16 data_offset;	/* Offset of remaining =
data in table */=0A+};=0A+=0A+/********************************************=
***********************************=0A+ *=0A+ * WAET - Windows ACPI =
Emulated devices Table=0A+ *        Version 1=0A+ *=0A+ * Conforms to =
"Windows ACPI Emulated Devices Table", version 1.0, April 6, 2009=0A+ =
*=0A+ *********************************************************************=
*********/=0A+=0A+struct acpi_table_waet {=0A+	struct acpi_table_header =
header;	/* Common ACPI table header */=0A+	u32 flags;=0A+};=0A+=0A+/* =
Masks for Flags field above */=0A+=0A+#define ACPI_WAET_RTC_NO_ACK        =
(1)	/* RTC requires no int acknowledge */=0A+#define ACPI_WAET_TIMER_ON=
E_READ    (1<<1)	/* PM timer requires only one read */=0A+=0A+/*****=
**************************************************************************=
=0A+ *=0A+ * WDAT - Watchdog Action Table=0A+ *        Version 1=0A+ *=0A+ =
* Conforms to "Hardware Watchdog Timers Design Specification",=0A+ * =
Copyright 2006 Microsoft Corporation.=0A+ *=0A+ ***************************=
***************************************************/=0A+=0A+struct =
acpi_table_wdat {=0A+	struct acpi_table_header header;	/* Common =
ACPI table header */=0A+	u32 header_length;	/* Watchdog Header =
Length */=0A+	u16 pci_segment;	/* PCI Segment number */=0A+	u8 =
pci_bus;		/* PCI Bus number */=0A+	u8 pci_device;		=
/* PCI Device number */=0A+	u8 pci_function;	/* PCI Function =
number */=0A+	u8 reserved[3];=0A+	u32 timer_period;	/* Period =
of one timer count (msec) */=0A+	u32 max_count;		/* Maximum =
counter value supported */=0A+	u32 min_count;		/* Minimum counter =
value */=0A+	u8 flags;=0A+	u8 reserved2[3];=0A+	u32 entries;		=
/* Number of watchdog entries that follow */=0A+};=0A+=0A+/* Masks for =
Flags field above */=0A+=0A+#define ACPI_WDAT_ENABLED           (1)=0A+#def=
ine ACPI_WDAT_STOPPED           0x80=0A+=0A+/* WDAT Instruction Entries =
(actions) */=0A+=0A+struct acpi_wdat_entry {=0A+	u8 action;=0A+	u8 =
instruction;=0A+	u16 reserved;=0A+	struct acpi_generic_address=
 register_region;=0A+	u32 value;		/* Value used with =
Read/Write register */=0A+	u32 mask;		/* Bitmask =
required for this register instruction */=0A+};=0A+=0A+/* Values for =
Action field above */=0A+=0A+enum acpi_wdat_actions {=0A+	ACPI_WDAT_R=
ESET =3D 1,=0A+	ACPI_WDAT_GET_CURRENT_COUNTDOWN =3D 4,=0A+	ACPI_WDAT_G=
ET_COUNTDOWN =3D 5,=0A+	ACPI_WDAT_SET_COUNTDOWN =3D 6,=0A+	ACPI_WDAT_G=
ET_RUNNING_STATE =3D 8,=0A+	ACPI_WDAT_SET_RUNNING_STATE =3D 9,=0A+	=
ACPI_WDAT_GET_STOPPED_STATE =3D 10,=0A+	ACPI_WDAT_SET_STOPPED_STATE =3D =
11,=0A+	ACPI_WDAT_GET_REBOOT =3D 16,=0A+	ACPI_WDAT_SET_REBOOT =3D =
17,=0A+	ACPI_WDAT_GET_SHUTDOWN =3D 18,=0A+	ACPI_WDAT_SET_SHUTDOWN =3D =
19,=0A+	ACPI_WDAT_GET_STATUS =3D 32,=0A+	ACPI_WDAT_SET_STATUS =3D =
33,=0A+	ACPI_WDAT_ACTION_RESERVED =3D 34	/* 34 and greater are =
reserved */=0A+};=0A+=0A+/* Values for Instruction field above */=0A+=0A+en=
um acpi_wdat_instructions {=0A+	ACPI_WDAT_READ_VALUE =3D 0,=0A+	ACPI_WDAT_R=
EAD_COUNTDOWN =3D 1,=0A+	ACPI_WDAT_WRITE_VALUE =3D 2,=0A+	=
ACPI_WDAT_WRITE_COUNTDOWN =3D 3,=0A+	ACPI_WDAT_INSTRUCTION_RESERVED =3D =
4,	/* 4 and greater are reserved */=0A+	ACPI_WDAT_PRESERVE_REGISTER=
 =3D 0x80	/* Except for this value */=0A+};=0A+=0A+/*****************=
**************************************************************=0A+ *=0A+ * =
WDDT - Watchdog Descriptor Table=0A+ *        Version 1=0A+ *=0A+ * =
Conforms to "Using the Intel ICH Family Watchdog Timer (WDT)",=0A+ * =
Version 001, September 2002=0A+ *=0A+ *************************************=
*****************************************/=0A+=0A+struct acpi_table_wddt =
{=0A+	struct acpi_table_header header;	/* Common ACPI table =
header */=0A+	u16 spec_version;=0A+	u16 table_version;=0A+	u16 =
pci_vendor_id;=0A+	struct acpi_generic_address address;=0A+	=
u16 max_count;		/* Maximum counter value supported */=0A+	=
u16 min_count;		/* Minimum counter value supported */=0A+	=
u16 period;=0A+	u16 status;=0A+	u16 capability;=0A+};=0A+=0A+/* Flags for =
Status field above */=0A+=0A+#define ACPI_WDDT_AVAILABLE     (1)=0A+#define=
 ACPI_WDDT_ACTIVE        (1<<1)=0A+#define ACPI_WDDT_TCO_OS_OWNED  =
(1<<2)=0A+#define ACPI_WDDT_USER_RESET    (1<<11)=0A+#define ACPI_WDDT_WDT_=
RESET     (1<<12)=0A+#define ACPI_WDDT_POWER_FAIL    (1<<13)=0A+#define =
ACPI_WDDT_UNKNOWN_RESET (1<<14)=0A+=0A+/* Flags for Capability field above =
*/=0A+=0A+#define ACPI_WDDT_AUTO_RESET    (1)=0A+#define ACPI_WDDT_ALERT_SU=
PPORT (1<<1)=0A+=0A+/******************************************************=
*************************=0A+ *=0A+ * WDRT - Watchdog Resource Table=0A+ * =
       Version 1=0A+ *=0A+ * Conforms to "Watchdog Timer Hardware =
Requirements for Windows Server 2003",=0A+ * Version 1.01, August 28, =
2006=0A+ *=0A+ ************************************************************=
******************/=0A+=0A+struct acpi_table_wdrt {=0A+	struct acpi_table_h=
eader header;	/* Common ACPI table header */=0A+	struct acpi_generic=
_address control_register;=0A+	struct acpi_generic_address count_register;=
=0A+	u16 pci_device_id;=0A+	u16 pci_vendor_id;=0A+	u8 pci_bus;		=
/* PCI Bus number */=0A+	u8 pci_device;		/* PCI Device =
number */=0A+	u8 pci_function;	/* PCI Function number */=0A+	u8 =
pci_segment;		/* PCI Segment number */=0A+	u16 max_count;		=
/* Maximum counter value supported */=0A+	u8 units;=0A+};=0A+=0A+/* =
Reset to default packing */=0A+=0A+#pragma pack()=0A+=0A+#endif			=
	/* __ACTBL2_H__ */=0A
--=__Part96B93371.0__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--=__Part96B93371.0__=--


From xen-devel-bounces@lists.xensource.com Mon Dec 12 16:10:26 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 16:10:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ra8SG-0003St-O4; Mon, 12 Dec 2011 16:10:16 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Ra8SE-0003S1-HH
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 16:10:15 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1323706156!7886778!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25105 invoked from network); 12 Dec 2011 16:09:16 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-8.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 12 Dec 2011 16:09:16 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 12 Dec 2011 16:09:16 +0000
Message-Id: <4EE635710200007800067060@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 12 Dec 2011 16:10:09 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part96B93371.0__="
Subject: [Xen-devel] [PATCH 2/4] ACPI: update table interface headers
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__Part96B93371.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

... to what is being used on Linux 3.1 (and 3.2-rc).

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/drivers/acpi/numa.c
+++ b/xen/drivers/acpi/numa.c
@@ -78,9 +78,11 @@ void __init acpi_table_print_srat_entry(
 			if (srat_rev < 2)
 				proximity_domain &=3D 0xff;
 			ACPI_DEBUG_PRINT((ACPI_DB_INFO,
-					  "SRAT Memory (0x%016"PRIx64" =
length 0x%016"PRIx64" type 0x%x) in proximity domain %d %s%s\n",
+					  "SRAT Memory (%#016"PRIx64
+					  " length %#016"PRIx64")"
+					  " in proximity domain %d =
%s%s\n",
 					  p->base_address, p->length,
-					  p->memory_type, proximity_domain,=

+					  proximity_domain,
 					  p->flags & ACPI_SRAT_MEM_ENABLED
 					  ? "enabled" : "disabled",
 					  p->flags & ACPI_SRAT_MEM_HOT_PLUG=
GABLE
--- a/xen/include/acpi/actbl.h
+++ b/xen/include/acpi/actbl.h
@@ -5,7 +5,7 @@
  *************************************************************************=
****/
=20
 /*
- * Copyright (C) 2000 - 2007, R. Byron Moore
+ * Copyright (C) 2000 - 2011, Intel Corp.
  * All rights reserved.
  *
  * Redistribution and use in source and binary forms, with or without
@@ -44,9 +44,23 @@
 #ifndef __ACTBL_H__
 #define __ACTBL_H__
=20
+/*************************************************************************=
******
+ *
+ * Fundamental ACPI tables
+ *
+ * This file contains definitions for the ACPI tables that are directly =
consumed
+ * by ACPICA. All other tables are consumed by the OS-dependent ACPI-relat=
ed
+ * device drivers and other OS support code.
+ *
+ * The RSDP and FACS do not use the common ACPI table header. All other =
ACPI
+ * tables use the header.
+ *
+ *************************************************************************=
*****/
+
 /*
- * Values for description table header signatures. Useful because they =
make
- * it more difficult to inadvertently type in the wrong signature.
+ * Values for description table header signatures for tables defined in =
this
+ * file. Useful because they make it more difficult to inadvertently type =
in
+ * the wrong signature.
  */
 #define ACPI_SIG_DSDT           "DSDT"	/* Differentiated System Descriptio=
n Table */
 #define ACPI_SIG_FADT           "FACP"	/* Fixed ACPI Description Table */
@@ -65,11 +79,6 @@
 #pragma pack(1)
=20
 /*
- * These are the ACPI tables that are directly consumed by the subsystem.
- *
- * The RSDP and FACS do not use the common ACPI table header. All other =
ACPI
- * tables use the header.
- *
  * Note about bitfields: The u8 type is used for bitfields in ACPI =
tables.
  * This is the only type that is even remotely portable. Anything else is =
not
  * portable, so do not use any other bitfield types.
@@ -77,9 +86,8 @@
=20
 /*************************************************************************=
******
  *
- * ACPI Table Header. This common header is used by all tables except the
- * RSDP and FACS. The define is used for direct inclusion of header into
- * other ACPI tables
+ * Master ACPI Table Header. This common header is used by all ACPI =
tables
+ * except the RSDP and FACS.
  *
  *************************************************************************=
*****/
=20
@@ -95,13 +103,16 @@ struct acpi_table_header {
 	u32 asl_compiler_revision;	/* ASL compiler version */
 };
=20
-/*
+/*************************************************************************=
******
+ *
  * GAS - Generic Address Structure (ACPI 2.0+)
  *
  * Note: Since this structure is used in the ACPI tables, it is byte =
aligned.
- * If misalignment is not supported, access to the Address field must be
- * performed with care.
- */
+ * If misaliged access is not supported by the hardware, accesses to the
+ * 64-bit Address field must be performed with care.
+ *
+ *************************************************************************=
*****/
+
 struct acpi_generic_address {
 	u8 space_id;		/* Address space where struct or register =
exists */
 	u8 bit_width;		/* Size in bits of given register */
@@ -113,6 +124,7 @@ struct acpi_generic_address {
 /*************************************************************************=
******
  *
  * RSDP - Root System Description Pointer (Signature is "RSD PTR ")
+ *        Version 2
  *
  *************************************************************************=
*****/
=20
@@ -133,6 +145,7 @@ struct acpi_table_rsdp {
 /*************************************************************************=
******
  *
  * RSDT/XSDT - Root System Description Tables
+ *             Version 1 (both)
  *
  *************************************************************************=
*****/
=20
@@ -161,21 +174,29 @@ struct acpi_table_facs {
 	u32 flags;
 	u64 xfirmware_waking_vector;	/* 64-bit version of the Firmware =
Waking Vector (ACPI 2.0+) */
 	u8 version;		/* Version of this table (ACPI 2.0+) */
-	u8 reserved[31];	/* Reserved, must be zero */
+	u8 reserved[3];		/* Reserved, must be zero */
+	u32 ospm_flags;		/* Flags to be set by OSPM (ACPI 4.0) */
+	u8 reserved1[24];	/* Reserved, must be zero */
 };
=20
-/* Flag macros */
+/* Masks for global_lock flag field above */
+
+#define ACPI_GLOCK_PENDING          (1)	/* 00: Pending global lock =
ownership */
+#define ACPI_GLOCK_OWNED            (1<<1)	/* 01: Global lock is =
owned */
=20
-#define ACPI_FACS_S4_BIOS_PRESENT (1)	/* 00: S4BIOS support is present =
*/
+/* Masks for Flags field above  */
=20
-/* Global lock flags */
+#define ACPI_FACS_S4_BIOS_PRESENT   (1)	/* 00: S4BIOS support is =
present */
+#define ACPI_FACS_64BIT_WAKE        (1<<1)	/* 01: 64-bit wake vector =
supported (ACPI 4.0) */
=20
-#define ACPI_GLOCK_PENDING      0x01	/* 00: Pending global lock =
ownership */
-#define ACPI_GLOCK_OWNED        0x02	/* 01: Global lock is owned */
+/* Masks for ospm_flags field above */
+
+#define ACPI_FACS_64BIT_ENVIRONMENT (1)	/* 00: 64-bit wake =
environment is required (ACPI 4.0) */
=20
 /*************************************************************************=
******
  *
  * FADT - Fixed ACPI Description Table (Signature "FACP")
+ *        Version 4
  *
  *************************************************************************=
*****/
=20
@@ -214,11 +235,11 @@ struct acpi_table_fadt {
 	u16 flush_size;		/* Processor's memory cache line width, in =
bytes */
 	u16 flush_stride;	/* Number of flush strides that need to be =
read */
 	u8 duty_offset;		/* Processor duty cycle index in processor'=
s P_CNT reg */
-	u8 duty_width;		/* Processor duty cycle value bit width in =
P_CNT register. */
+	u8 duty_width;		/* Processor duty cycle value bit width in =
P_CNT register */
 	u8 day_alarm;		/* Index to day-of-month alarm in RTC CMOS =
RAM */
 	u8 month_alarm;		/* Index to month-of-year alarm in RTC =
CMOS RAM */
 	u8 century;		/* Index to century in RTC CMOS RAM */
-	u16 boot_flags;		/* IA-PC Boot Architecture Flags. See =
Table 5-10 for description */
+	u16 boot_flags;		/* IA-PC Boot Architecture Flags (see =
below for individual flags) */
 	u8 reserved;		/* Reserved, must be zero */
 	u32 flags;		/* Miscellaneous flag bits (see below for =
individual flags) */
 	struct acpi_generic_address reset_register;	/* 64-bit address =
of the Reset register */
@@ -236,32 +257,41 @@ struct acpi_table_fadt {
 	struct acpi_generic_address xgpe1_block;	/* 64-bit Extended =
General Purpose Event 1 Reg Blk address */
 };
=20
-/* FADT flags */
+/* Masks for FADT Boot Architecture Flags (boot_flags) */
=20
-#define ACPI_FADT_WBINVD            (1)	/* 00: The wbinvd =
instruction works properly */
-#define ACPI_FADT_WBINVD_FLUSH      (1<<1)	/* 01: The wbinvd flushes =
but does not invalidate */
-#define ACPI_FADT_C1_SUPPORTED      (1<<2)	/* 02: All processors =
support C1 state */
-#define ACPI_FADT_C2_MP_SUPPORTED   (1<<3)	/* 03: C2 state works on =
MP system */
-#define ACPI_FADT_POWER_BUTTON      (1<<4)	/* 04: Power button is =
handled as a generic feature */
-#define ACPI_FADT_SLEEP_BUTTON      (1<<5)	/* 05: Sleep button is =
handled as a generic feature, or  not present */
-#define ACPI_FADT_FIXED_RTC         (1<<6)	/* 06: RTC wakeup stat not =
in fixed register space */
-#define ACPI_FADT_S4_RTC_WAKE       (1<<7)	/* 07: RTC wakeup stat not =
possible from S4 */
-#define ACPI_FADT_32BIT_TIMER       (1<<8)	/* 08: tmr_val is 32 bits =
0=3D24-bits */
-#define ACPI_FADT_DOCKING_SUPPORTED (1<<9)	/* 09: Docking supported =
*/
-#define ACPI_FADT_RESET_REGISTER    (1<<10)	/* 10: System reset via =
the FADT RESET_REG supported */
-#define ACPI_FADT_SEALED_CASE       (1<<11)	/* 11: No internal =
expansion capabilities and case is sealed */
-#define ACPI_FADT_HEADLESS          (1<<12)	/* 12: No local video =
capabilities or local input devices */
-#define ACPI_FADT_SLEEP_TYPE        (1<<13)	/* 13: Must execute native =
instruction after writing  SLP_TYPx register */
-#define ACPI_FADT_PCI_EXPRESS_WAKE  (1<<14)	/* 14: System supports =
PCIEXP_WAKE (STS/EN) bits (ACPI 3.0) */
-#define ACPI_FADT_PLATFORM_CLOCK    (1<<15)	/* 15: OSPM should use =
platform-provided timer (ACPI 3.0) */
-#define ACPI_FADT_S4_RTC_VALID      (1<<16)	/* 16: Contents of RTC_STS =
valid after S4 wake (ACPI 3.0) */
-#define ACPI_FADT_REMOTE_POWER_ON   (1<<17)	/* 17: System is compatible=
 with remote power on (ACPI 3.0) */
-#define ACPI_FADT_APIC_CLUSTER      (1<<18)	/* 18: All local APICs =
must use cluster model (ACPI 3.0) */
-#define ACPI_FADT_APIC_PHYSICAL     (1<<19)	/* 19: All local x_aPICs =
must use physical dest mode (ACPI 3.0) */
+#define ACPI_FADT_LEGACY_DEVICES    (1)  	/* 00: [V2] System has LPC =
or ISA bus devices */
+#define ACPI_FADT_8042              (1<<1)	/* 01: [V3] System has an =
8042 controller on port 60/64 */
+#define ACPI_FADT_NO_VGA            (1<<2)	/* 02: [V4] It is not safe =
to probe for VGA hardware */
+#define ACPI_FADT_NO_MSI            (1<<3)	/* 03: [V4] Message =
Signaled Interrupts (MSI) must not be enabled */
+#define ACPI_FADT_NO_ASPM           (1<<4)	/* 04: [V4] PCIe ASPM =
control must not be enabled */
+
+#define FADT2_REVISION_ID               3
+
+/* Masks for FADT flags */
+
+#define ACPI_FADT_WBINVD            (1)	/* 00: [V1] The wbinvd =
instruction works properly */
+#define ACPI_FADT_WBINVD_FLUSH      (1<<1)	/* 01: [V1] wbinvd flushes =
but does not invalidate caches */
+#define ACPI_FADT_C1_SUPPORTED      (1<<2)	/* 02: [V1] All processors =
support C1 state */
+#define ACPI_FADT_C2_MP_SUPPORTED   (1<<3)	/* 03: [V1] C2 state works =
on MP system */
+#define ACPI_FADT_POWER_BUTTON      (1<<4)	/* 04: [V1] Power button =
is handled as a control method device */
+#define ACPI_FADT_SLEEP_BUTTON      (1<<5)	/* 05: [V1] Sleep button =
is handled as a control method device */
+#define ACPI_FADT_FIXED_RTC         (1<<6)	/* 06: [V1] RTC wakeup =
status not in fixed register space */
+#define ACPI_FADT_S4_RTC_WAKE       (1<<7)	/* 07: [V1] RTC alarm can =
wake system from S4 */
+#define ACPI_FADT_32BIT_TIMER       (1<<8)	/* 08: [V1] ACPI timer =
width is 32-bit (0=3D24-bit) */
+#define ACPI_FADT_DOCKING_SUPPORTED (1<<9)	/* 09: [V1] Docking =
supported */
+#define ACPI_FADT_RESET_REGISTER    (1<<10)	/* 10: [V2] System reset =
via the FADT RESET_REG supported */
+#define ACPI_FADT_SEALED_CASE       (1<<11)	/* 11: [V3] No internal =
expansion capabilities and case is sealed */
+#define ACPI_FADT_HEADLESS          (1<<12)	/* 12: [V3] No local video =
capabilities or local input devices */
+#define ACPI_FADT_SLEEP_TYPE        (1<<13)	/* 13: [V3] Must execute =
native instruction after writing  SLP_TYPx register */
+#define ACPI_FADT_PCI_EXPRESS_WAKE  (1<<14)	/* 14: [V4] System =
supports PCIEXP_WAKE (STS/EN) bits (ACPI 3.0) */
+#define ACPI_FADT_PLATFORM_CLOCK    (1<<15)	/* 15: [V4] OSPM should =
use platform-provided timer (ACPI 3.0) */
+#define ACPI_FADT_S4_RTC_VALID      (1<<16)	/* 16: [V4] Contents of =
RTC_STS valid after S4 wake (ACPI 3.0) */
+#define ACPI_FADT_REMOTE_POWER_ON   (1<<17)	/* 17: [V4] System is =
compatible with remote power on (ACPI 3.0) */
+#define ACPI_FADT_APIC_CLUSTER      (1<<18)	/* 18: [V4] All local =
APICs must use cluster model (ACPI 3.0) */
+#define ACPI_FADT_APIC_PHYSICAL     (1<<19)	/* 19: [V4] All local =
x_aPICs must use physical dest mode (ACPI 3.0) */
+
+/* Values for preferred_profile (Preferred Power Management Profiles) */
=20
-/*
- * FADT Prefered Power Management Profiles
- */
 enum acpi_prefered_pm_profiles {
 	PM_UNSPECIFIED =3D 0,
 	PM_DESKTOP =3D 1,
@@ -272,15 +302,6 @@ enum acpi_prefered_pm_profiles {
 	PM_APPLIANCE_PC =3D 6
 };
=20
-/* FADT Boot Arch Flags */
-
-#define BAF_LEGACY_DEVICES              0x0001
-#define BAF_8042_KEYBOARD_CONTROLLER    0x0002
-#define BAF_MSI_NOT_SUPPORTED           0x0008
-
-#define FADT2_REVISION_ID               3
-#define FADT2_MINUS_REVISION_ID         2
-
 /* Reset to default packing */
=20
 #pragma pack()
@@ -292,5 +313,22 @@ enum acpi_prefered_pm_profiles {
  */
=20
 #include <acpi/actbl1.h>
+#include <acpi/actbl2.h>
+
+/*
+ * Sizes of the various flavors of FADT. We need to look closely
+ * at the FADT length because the version number essentially tells
+ * us nothing because of many BIOS bugs where the version does not
+ * match the expected length. In other words, the length of the
+ * FADT is the bottom line as to what the version really is.
+ *
+ * For reference, the values below are as follows:
+ *     FADT V1  size: 0x74
+ *     FADT V2  size: 0x84
+ *     FADT V3+ size: 0xF4
+ */
+#define ACPI_FADT_V1_SIZE       (u32) (ACPI_FADT_OFFSET (flags) + 4)
+#define ACPI_FADT_V2_SIZE       (u32) (ACPI_FADT_OFFSET (reserved4[0]) + =
3)
+#define ACPI_FADT_V3_SIZE       (u32) (sizeof (struct acpi_table_fadt))
=20
 #endif				/* __ACTBL_H__ */
--- a/xen/include/acpi/actbl1.h
+++ b/xen/include/acpi/actbl1.h
@@ -5,7 +5,7 @@
  *************************************************************************=
****/
=20
 /*
- * Copyright (C) 2000 - 2007, R. Byron Moore
+ * Copyright (C) 2000 - 2011, Intel Corp.
  * All rights reserved.
  *
  * Redistribution and use in source and binary forms, with or without
@@ -46,34 +46,31 @@
=20
 /*************************************************************************=
******
  *
- * Additional ACPI Tables
+ * Additional ACPI Tables (1)
  *
  * These tables are not consumed directly by the ACPICA subsystem, but =
are
  * included here to support device drivers and the AML disassembler.
  *
+ * The tables in this file are fully defined within the ACPI specification=
.
+ *
  *************************************************************************=
*****/
=20
 /*
- * Values for description table header signatures. Useful because they =
make
- * it more difficult to inadvertently type in the wrong signature.
+ * Values for description table header signatures for tables defined in =
this
+ * file. Useful because they make it more difficult to inadvertently type =
in
+ * the wrong signature.
  */
-#define ACPI_SIG_ASF            "ASF!"	/* Alert Standard Format table */
-#define ACPI_SIG_BOOT           "BOOT"	/* Simple Boot Flag Table */
+#define ACPI_SIG_BERT           "BERT"	/* Boot Error Record Table */
 #define ACPI_SIG_CPEP           "CPEP"	/* Corrected Platform Error =
Polling table */
-#define ACPI_SIG_ERST           "ERST"  /* Error Record Serialization =
Table */
-#define ACPI_SIG_DBGP           "DBGP"	/* Debug Port table */
-#define ACPI_SIG_DMAR           "DMAR"	/* DMA Remapping table */
 #define ACPI_SIG_ECDT           "ECDT"	/* Embedded Controller Boot =
Resources Table */
-#define ACPI_SIG_HPET           "HPET"	/* High Precision Event Timer =
table */
+#define ACPI_SIG_EINJ           "EINJ"	/* Error Injection table */
+#define ACPI_SIG_ERST           "ERST"	/* Error Record Serialization =
Table */
+#define ACPI_SIG_HEST           "HEST"	/* Hardware Error Source Table */
 #define ACPI_SIG_MADT           "APIC"	/* Multiple APIC Description Table =
*/
-#define ACPI_SIG_MCFG           "MCFG"	/* PCI Memory Mapped Configuration =
table */
+#define ACPI_SIG_MSCT           "MSCT"	/* Maximum System Characteristics =
Table */
 #define ACPI_SIG_SBST           "SBST"	/* Smart Battery Specification =
Table */
 #define ACPI_SIG_SLIT           "SLIT"	/* System Locality Distance =
Information Table */
-#define ACPI_SIG_SPCR           "SPCR"	/* Serial Port Console Redirection =
table */
-#define ACPI_SIG_SPMI           "SPMI"	/* Server Platform Management =
Interface table */
 #define ACPI_SIG_SRAT           "SRAT"	/* System Resource Affinity Table =
*/
-#define ACPI_SIG_TCPA           "TCPA"	/* Trusted Computing Platform =
Alliance table */
-#define ACPI_SIG_WDRT           "WDRT"	/* Watchdog Resource Table */
=20
 /*
  * All tables must be byte-packed to match the ACPI specification, since
@@ -87,7 +84,13 @@
  * portable, so do not use any other bitfield types.
  */
=20
-/* Common Sub-table header (used in MADT, SRAT, etc.) */
+/*************************************************************************=
******
+ *
+ * Common subtable headers
+ *
+ *************************************************************************=
*****/
+
+/* Generic subtable header (used in MADT, SRAT, etc.) */
=20
 struct acpi_subtable_header {
 	u8 type;
@@ -108,128 +111,54 @@ struct acpi_whea_header {
=20
 /*************************************************************************=
******
  *
- * ASF - Alert Standard Format table (Signature "ASF!")
- *
- * Conforms to the Alert Standard Format Specification V2.0, 23 April =
2003
+ * BERT - Boot Error Record Table (ACPI 4.0)
+ *        Version 1
  *
  *************************************************************************=
*****/
=20
-struct acpi_table_asf {
+struct acpi_table_bert {
 	struct acpi_table_header header;	/* Common ACPI table =
header */
+	u32 region_length;	/* Length of the boot error region */
+	u64 address;		/* Physical address of the error region */
 };
=20
-/* ASF subtable header */
-
-struct acpi_asf_header {
-	u8 type;
-	u8 reserved;
-	u16 length;
-};
-
-/* Values for Type field above */
+/* Boot Error Region (not a subtable, pointed to by Address field above) =
*/
=20
-enum acpi_asf_type {
-	ACPI_ASF_TYPE_INFO =3D 0,
-	ACPI_ASF_TYPE_ALERT =3D 1,
-	ACPI_ASF_TYPE_CONTROL =3D 2,
-	ACPI_ASF_TYPE_BOOT =3D 3,
-	ACPI_ASF_TYPE_ADDRESS =3D 4,
-	ACPI_ASF_TYPE_RESERVED =3D 5
+struct acpi_bert_region {
+	u32 block_status;	/* Type of error information */
+	u32 raw_data_offset;	/* Offset to raw error data */
+	u32 raw_data_length;	/* Length of raw error data */
+	u32 data_length;	/* Length of generic error data */
+	u32 error_severity;	/* Severity code */
 };
=20
-/*
- * ASF subtables
- */
+/* Values for block_status flags above */
=20
-/* 0: ASF Information */
+#define ACPI_BERT_UNCORRECTABLE             (1)
+#define ACPI_BERT_CORRECTABLE               (1<<1)
+#define ACPI_BERT_MULTIPLE_UNCORRECTABLE    (1<<2)
+#define ACPI_BERT_MULTIPLE_CORRECTABLE      (1<<3)
+#define ACPI_BERT_ERROR_ENTRY_COUNT         (0xFF<<4)	/* 8 bits, error =
count */
=20
-struct acpi_asf_info {
-	struct acpi_asf_header header;
-	u8 min_reset_value;
-	u8 min_poll_interval;
-	u16 system_id;
-	u32 mfg_id;
-	u8 flags;
-	u8 reserved2[3];
-};
-
-/* 1: ASF Alerts */
+/* Values for error_severity above */
=20
-struct acpi_asf_alert {
-	struct acpi_asf_header header;
-	u8 assert_mask;
-	u8 deassert_mask;
-	u8 alerts;
-	u8 data_length;
-};
-
-struct acpi_asf_alert_data {
-	u8 address;
-	u8 command;
-	u8 mask;
-	u8 value;
-	u8 sensor_type;
-	u8 type;
-	u8 offset;
-	u8 source_type;
-	u8 severity;
-	u8 sensor_number;
-	u8 entity;
-	u8 instance;
+enum acpi_bert_error_severity {
+	ACPI_BERT_ERROR_CORRECTABLE =3D 0,
+	ACPI_BERT_ERROR_FATAL =3D 1,
+	ACPI_BERT_ERROR_CORRECTED =3D 2,
+	ACPI_BERT_ERROR_NONE =3D 3,
+	ACPI_BERT_ERROR_RESERVED =3D 4	/* 4 and greater are reserved */
 };
=20
-/* 2: ASF Remote Control */
-
-struct acpi_asf_remote {
-	struct acpi_asf_header header;
-	u8 controls;
-	u8 data_length;
-	u16 reserved2;
-};
-
-struct acpi_asf_control_data {
-	u8 function;
-	u8 address;
-	u8 command;
-	u8 value;
-};
-
-/* 3: ASF RMCP Boot Options */
-
-struct acpi_asf_rmcp {
-	struct acpi_asf_header header;
-	u8 capabilities[7];
-	u8 completion_code;
-	u32 enterprise_id;
-	u8 command;
-	u16 parameter;
-	u16 boot_options;
-	u16 oem_parameters;
-};
-
-/* 4: ASF Address */
-
-struct acpi_asf_address {
-	struct acpi_asf_header header;
-	u8 eprom_address;
-	u8 devices;
-};
-
-/*************************************************************************=
******
- *
- * BOOT - Simple Boot Flag Table
- *
- *************************************************************************=
*****/
-
-struct acpi_table_boot {
-	struct acpi_table_header header;	/* Common ACPI table =
header */
-	u8 cmos_index;		/* Index in CMOS RAM for the boot register =
*/
-	u8 reserved[3];
-};
+/*
+ * Note: The generic error data that follows the error_severity field =
above
+ * uses the struct acpi_hest_generic_data defined under the HEST table =
below
+ */
=20
 /*************************************************************************=
******
  *
- * CPEP - Corrected Platform Error Polling table
+ * CPEP - Corrected Platform Error Polling table (ACPI 4.0)
+ *        Version 1
  *
  *************************************************************************=
*****/
=20
@@ -241,8 +170,7 @@ struct acpi_table_cpep {
 /* Subtable */
=20
 struct acpi_cpep_polling {
-	u8 type;
-	u8 length;
+	struct acpi_subtable_header header;
 	u8 id;			/* Processor ID */
 	u8 eid;			/* Processor EID */
 	u32 interval;		/* Polling interval (msec) */
@@ -250,116 +178,103 @@ struct acpi_cpep_polling {
=20
 /*************************************************************************=
******
  *
- * DBGP - Debug Port table
+ * ECDT - Embedded Controller Boot Resources Table
+ *        Version 1
  *
  *************************************************************************=
*****/
=20
-struct acpi_table_dbgp {
+struct acpi_table_ecdt {
 	struct acpi_table_header header;	/* Common ACPI table =
header */
-	u8 type;		/* 0=3Dfull 16550, 1=3Dsubset of 16550 */
-	u8 reserved[3];
-	struct acpi_generic_address debug_port;
+	struct acpi_generic_address control;	/* Address of EC command/st=
atus register */
+	struct acpi_generic_address data;	/* Address of EC data =
register */
+	u32 uid;		/* Unique ID - must be same as the EC _UID =
method */
+	u8 gpe;			/* The GPE for the EC */
+	u8 id[1];		/* Full namepath of the EC in the ACPI =
namespace */
 };
=20
 /*************************************************************************=
******
  *
- * DMAR - DMA Remapping table
+ * EINJ - Error Injection Table (ACPI 4.0)
+ *        Version 1
  *
  *************************************************************************=
*****/
=20
-struct acpi_table_dmar {
+struct acpi_table_einj {
 	struct acpi_table_header header;	/* Common ACPI table =
header */
-	u8 width;		/* Host Address Width */
+	u32 header_length;
 	u8 flags;
-	u8 reserved[10];
-};
-
-/* DMAR subtable header */
-
-struct acpi_dmar_header {
-	u16 type;
-	u16 length;
-};
-
-/* Values for subtable type in struct acpi_dmar_header */
-
-enum acpi_dmar_type {
-	ACPI_DMAR_TYPE_HARDWARE_UNIT =3D 0,
-	ACPI_DMAR_TYPE_RESERVED_MEMORY =3D 1,
-	ACPI_DMAR_TYPE_ATSR =3D 2,
-	ACPI_DMAR_TYPE_RESERVED =3D 3	/* 3 and greater are reserved */
-};
-
-struct acpi_dmar_device_scope {
-	u8 entry_type;
-	u8 length;
-	u16 reserved;
-	u8 enumeration_id;
-	u8 bus;
+	u8 reserved[3];
+	u32 entries;
 };
=20
-/* Values for entry_type in struct acpi_dmar_device_scope */
+/* EINJ Injection Instruction Entries (actions) */
=20
-enum acpi_dmar_scope_type {
-	ACPI_DMAR_SCOPE_TYPE_NOT_USED =3D 0,
-	ACPI_DMAR_SCOPE_TYPE_ENDPOINT =3D 1,
-	ACPI_DMAR_SCOPE_TYPE_BRIDGE =3D 2,
-	ACPI_DMAR_SCOPE_TYPE_IOAPIC =3D 3,
-	ACPI_DMAR_SCOPE_TYPE_HPET =3D 4,
-	ACPI_DMAR_SCOPE_TYPE_RESERVED =3D 5	/* 5 and greater are =
reserved */
+struct acpi_einj_entry {
+	struct acpi_whea_header whea_header;	/* Common header for WHEA =
tables */
 };
=20
-struct acpi_dmar_pci_path {
-	u8 dev;
-	u8 fn;
-};
+/* Masks for Flags field above */
=20
-/*
- * DMAR Sub-tables, correspond to Type in struct acpi_dmar_header
- */
+#define ACPI_EINJ_PRESERVE          (1)
=20
-/* 0: Hardware Unit Definition */
+/* Values for Action field above */
=20
-struct acpi_dmar_hardware_unit {
-	struct acpi_dmar_header header;
-	u8 flags;
-	u8 reserved;
-	u16 segment;
-	u64 address;		/* Register Base Address */
+enum acpi_einj_actions {
+	ACPI_EINJ_BEGIN_OPERATION =3D 0,
+	ACPI_EINJ_GET_TRIGGER_TABLE =3D 1,
+	ACPI_EINJ_SET_ERROR_TYPE =3D 2,
+	ACPI_EINJ_GET_ERROR_TYPE =3D 3,
+	ACPI_EINJ_END_OPERATION =3D 4,
+	ACPI_EINJ_EXECUTE_OPERATION =3D 5,
+	ACPI_EINJ_CHECK_BUSY_STATUS =3D 6,
+	ACPI_EINJ_GET_COMMAND_STATUS =3D 7,
+	ACPI_EINJ_ACTION_RESERVED =3D 8,	/* 8 and greater are =
reserved */
+	ACPI_EINJ_TRIGGER_ERROR =3D 0xFF	/* Except for this value =
*/
 };
=20
-/* Flags */
-
-#define ACPI_DMAR_INCLUDE_ALL       (1)
-
-/* 1: Reserved Memory Defininition */
+/* Values for Instruction field above */
=20
-struct acpi_dmar_reserved_memory {
-	struct acpi_dmar_header header;
-	u16 reserved;
-	u16 segment;
-	u64 base_address;		/* 4_k aligned base address */
-	u64 end_address;	/* 4_k aligned limit address */
+enum acpi_einj_instructions {
+	ACPI_EINJ_READ_REGISTER =3D 0,
+	ACPI_EINJ_READ_REGISTER_VALUE =3D 1,
+	ACPI_EINJ_WRITE_REGISTER =3D 2,
+	ACPI_EINJ_WRITE_REGISTER_VALUE =3D 3,
+	ACPI_EINJ_NOOP =3D 4,
+	ACPI_EINJ_INSTRUCTION_RESERVED =3D 5	/* 5 and greater are =
reserved */
+};
+
+/* EINJ Trigger Error Action Table */
+
+struct acpi_einj_trigger {
+	u32 header_size;
+	u32 revision;
+	u32 table_size;
+	u32 entry_count;
 };
=20
-/* Flags */
+/* Command status return values */
=20
-#define ACPI_DMAR_ALLOW_ALL         (1)
-
-/*************************************************************************=
******
- *
- * ECDT - Embedded Controller Boot Resources Table
- *
- *************************************************************************=
*****/
-
-struct acpi_table_ecdt {
-	struct acpi_table_header header;	/* Common ACPI table =
header */
-	struct acpi_generic_address control;	/* Address of EC command/st=
atus register */
-	struct acpi_generic_address data;	/* Address of EC data =
register */
-	u32 uid;		/* Unique ID - must be same as the EC _UID =
method */
-	u8 gpe;			/* The GPE for the EC */
-	u8 id[1];		/* Full namepath of the EC in the ACPI =
namespace */
-};
+enum acpi_einj_command_status {
+	ACPI_EINJ_SUCCESS =3D 0,
+	ACPI_EINJ_FAILURE =3D 1,
+	ACPI_EINJ_INVALID_ACCESS =3D 2,
+	ACPI_EINJ_STATUS_RESERVED =3D 3	/* 3 and greater are reserved */
+};
+
+/* Error types returned from ACPI_EINJ_GET_ERROR_TYPE (bitfield) */
+
+#define ACPI_EINJ_PROCESSOR_CORRECTABLE     (1)
+#define ACPI_EINJ_PROCESSOR_UNCORRECTABLE   (1<<1)
+#define ACPI_EINJ_PROCESSOR_FATAL           (1<<2)
+#define ACPI_EINJ_MEMORY_CORRECTABLE        (1<<3)
+#define ACPI_EINJ_MEMORY_UNCORRECTABLE      (1<<4)
+#define ACPI_EINJ_MEMORY_FATAL              (1<<5)
+#define ACPI_EINJ_PCIX_CORRECTABLE          (1<<6)
+#define ACPI_EINJ_PCIX_UNCORRECTABLE        (1<<7)
+#define ACPI_EINJ_PCIX_FATAL                (1<<8)
+#define ACPI_EINJ_PLATFORM_CORRECTABLE      (1<<9)
+#define ACPI_EINJ_PLATFORM_UNCORRECTABLE    (1<<10)
+#define ACPI_EINJ_PLATFORM_FATAL            (1<<11)
=20
 /*************************************************************************=
******
  *
@@ -453,30 +368,237 @@ struct acpi_erst_info {
=20
 /*************************************************************************=
******
  *
- * HPET - High Precision Event Timer table
+ * HEST - Hardware Error Source Table (ACPI 4.0)
+ *        Version 1
  *
  *************************************************************************=
*****/
=20
-struct acpi_table_hpet {
+struct acpi_table_hest {
 	struct acpi_table_header header;	/* Common ACPI table =
header */
-	u32 id;			/* Hardware ID of event timer block */
-	struct acpi_generic_address address;	/* Address of event timer =
block */
-	u8 sequence;		/* HPET sequence number */
-	u16 minimum_tick;	/* Main counter min tick, periodic mode */
+	u32 error_source_count;
+};
+
+/* HEST subtable header */
+
+struct acpi_hest_header {
+	u16 type;
+	u16 source_id;
+};
+
+/* Values for Type field above for subtables */
+
+enum acpi_hest_types {
+	ACPI_HEST_TYPE_IA32_CHECK =3D 0,
+	ACPI_HEST_TYPE_IA32_CORRECTED_CHECK =3D 1,
+	ACPI_HEST_TYPE_IA32_NMI =3D 2,
+	ACPI_HEST_TYPE_NOT_USED3 =3D 3,
+	ACPI_HEST_TYPE_NOT_USED4 =3D 4,
+	ACPI_HEST_TYPE_NOT_USED5 =3D 5,
+	ACPI_HEST_TYPE_AER_ROOT_PORT =3D 6,
+	ACPI_HEST_TYPE_AER_ENDPOINT =3D 7,
+	ACPI_HEST_TYPE_AER_BRIDGE =3D 8,
+	ACPI_HEST_TYPE_GENERIC_ERROR =3D 9,
+	ACPI_HEST_TYPE_RESERVED =3D 10	/* 10 and greater are reserved */
+};
+
+/*
+ * HEST substructures contained in subtables
+ */
+
+/*
+ * IA32 Error Bank(s) - Follows the struct acpi_hest_ia_machine_check and
+ * struct acpi_hest_ia_corrected structures.
+ */
+struct acpi_hest_ia_error_bank {
+	u8 bank_number;
+	u8 clear_status_on_init;
+	u8 status_format;
+	u8 reserved;
+	u32 control_register;
+	u64 control_data;
+	u32 status_register;
+	u32 address_register;
+	u32 misc_register;
+};
+
+/* Common HEST sub-structure for PCI/AER structures below (6,7,8) */
+
+struct acpi_hest_aer_common {
+	u16 reserved1;
 	u8 flags;
+	u8 enabled;
+	u32 records_to_preallocate;
+	u32 max_sections_per_record;
+	u32 bus;
+	u16 device;
+	u16 function;
+	u16 device_control;
+	u16 reserved2;
+	u32 uncorrectable_mask;
+	u32 uncorrectable_severity;
+	u32 correctable_mask;
+	u32 advanced_capabilities;
 };
=20
-/*! Flags */
+/* Masks for HEST Flags fields */
+
+#define ACPI_HEST_FIRMWARE_FIRST        (1)
+#define ACPI_HEST_GLOBAL                (1<<1)
=20
-#define ACPI_HPET_PAGE_PROTECT      (1)	/* 00: No page protection =
*/
-#define ACPI_HPET_PAGE_PROTECT_4    (1<<1)	/* 01: 4KB page protected =
*/
-#define ACPI_HPET_PAGE_PROTECT_64   (1<<2)	/* 02: 64KB page protected =
*/
+/* Hardware Error Notification */
=20
-/*! [End] no source code translation !*/
+struct acpi_hest_notify {
+	u8 type;
+	u8 length;
+	u16 config_write_enable;
+	u32 poll_interval;
+	u32 vector;
+	u32 polling_threshold_value;
+	u32 polling_threshold_window;
+	u32 error_threshold_value;
+	u32 error_threshold_window;
+};
+
+/* Values for Notify Type field above */
+
+enum acpi_hest_notify_types {
+	ACPI_HEST_NOTIFY_POLLED =3D 0,
+	ACPI_HEST_NOTIFY_EXTERNAL =3D 1,
+	ACPI_HEST_NOTIFY_LOCAL =3D 2,
+	ACPI_HEST_NOTIFY_SCI =3D 3,
+	ACPI_HEST_NOTIFY_NMI =3D 4,
+	ACPI_HEST_NOTIFY_RESERVED =3D 5	/* 5 and greater are reserved */
+};
+
+/* Values for config_write_enable bitfield above */
+
+#define ACPI_HEST_TYPE                  (1)
+#define ACPI_HEST_POLL_INTERVAL         (1<<1)
+#define ACPI_HEST_POLL_THRESHOLD_VALUE  (1<<2)
+#define ACPI_HEST_POLL_THRESHOLD_WINDOW (1<<3)
+#define ACPI_HEST_ERR_THRESHOLD_VALUE   (1<<4)
+#define ACPI_HEST_ERR_THRESHOLD_WINDOW  (1<<5)
+
+/*
+ * HEST subtables
+ */
+
+/* 0: IA32 Machine Check Exception */
+
+struct acpi_hest_ia_machine_check {
+	struct acpi_hest_header header;
+	u16 reserved1;
+	u8 flags;
+	u8 enabled;
+	u32 records_to_preallocate;
+	u32 max_sections_per_record;
+	u64 global_capability_data;
+	u64 global_control_data;
+	u8 num_hardware_banks;
+	u8 reserved3[7];
+};
+
+/* 1: IA32 Corrected Machine Check */
+
+struct acpi_hest_ia_corrected {
+	struct acpi_hest_header header;
+	u16 reserved1;
+	u8 flags;
+	u8 enabled;
+	u32 records_to_preallocate;
+	u32 max_sections_per_record;
+	struct acpi_hest_notify notify;
+	u8 num_hardware_banks;
+	u8 reserved2[3];
+};
+
+/* 2: IA32 Non-Maskable Interrupt */
+
+struct acpi_hest_ia_nmi {
+	struct acpi_hest_header header;
+	u32 reserved;
+	u32 records_to_preallocate;
+	u32 max_sections_per_record;
+	u32 max_raw_data_length;
+};
+
+/* 3,4,5: Not used */
+
+/* 6: PCI Express Root Port AER */
+
+struct acpi_hest_aer_root {
+	struct acpi_hest_header header;
+	struct acpi_hest_aer_common aer;
+	u32 root_error_command;
+};
+
+/* 7: PCI Express AER (AER Endpoint) */
+
+struct acpi_hest_aer {
+	struct acpi_hest_header header;
+	struct acpi_hest_aer_common aer;
+};
+
+/* 8: PCI Express/PCI-X Bridge AER */
+
+struct acpi_hest_aer_bridge {
+	struct acpi_hest_header header;
+	struct acpi_hest_aer_common aer;
+	u32 uncorrectable_mask2;
+	u32 uncorrectable_severity2;
+	u32 advanced_capabilities2;
+};
+
+/* 9: Generic Hardware Error Source */
+
+struct acpi_hest_generic {
+	struct acpi_hest_header header;
+	u16 related_source_id;
+	u8 reserved;
+	u8 enabled;
+	u32 records_to_preallocate;
+	u32 max_sections_per_record;
+	u32 max_raw_data_length;
+	struct acpi_generic_address error_status_address;
+	struct acpi_hest_notify notify;
+	u32 error_block_length;
+};
+
+/* Generic Error Status block */
+
+struct acpi_hest_generic_status {
+	u32 block_status;
+	u32 raw_data_offset;
+	u32 raw_data_length;
+	u32 data_length;
+	u32 error_severity;
+};
+
+/* Values for block_status flags above */
+
+#define ACPI_HEST_UNCORRECTABLE             (1)
+#define ACPI_HEST_CORRECTABLE               (1<<1)
+#define ACPI_HEST_MULTIPLE_UNCORRECTABLE    (1<<2)
+#define ACPI_HEST_MULTIPLE_CORRECTABLE      (1<<3)
+#define ACPI_HEST_ERROR_ENTRY_COUNT         (0xFF<<4)	/* 8 bits, error =
count */
+
+/* Generic Error Data entry */
+
+struct acpi_hest_generic_data {
+	u8 section_type[16];
+	u32 error_severity;
+	u16 revision;
+	u8 validation_bits;
+	u8 flags;
+	u32 error_data_length;
+	u8 fru_id[16];
+	u8 fru_text[20];
+};
=20
 /*************************************************************************=
******
  *
  * MADT - Multiple APIC Description Table
+ *        Version 3
  *
  *************************************************************************=
*****/
=20
@@ -486,7 +608,7 @@ struct acpi_table_madt {
 	u32 flags;
 };
=20
-/* Flags */
+/* Masks for Flags field above */
=20
 #define ACPI_MADT_PCAT_COMPAT       (1)	/* 00:    System also has =
dual 8259s */
=20
@@ -495,7 +617,7 @@ struct acpi_table_madt {
 #define ACPI_MADT_DUAL_PIC          0
 #define ACPI_MADT_MULTIPLE_APIC     1
=20
-/* Values for subtable type in struct acpi_subtable_header */
+/* Values for MADT subtable type in struct acpi_subtable_header */
=20
 enum acpi_madt_type {
 	ACPI_MADT_TYPE_LOCAL_APIC =3D 0,
@@ -606,7 +728,7 @@ struct acpi_madt_interrupt_source {
 	u32 flags;		/* Interrupt Source Flags */
 };
=20
-/* Flags field above */
+/* Masks for Flags field above */
=20
 #define ACPI_MADT_CPEI_OVERRIDE     (1)
=20
@@ -615,9 +737,9 @@ struct acpi_madt_interrupt_source {
 struct acpi_madt_local_x2apic {
 	struct acpi_subtable_header header;
 	u16 reserved;		/* Reserved - must be zero */
-	u32 local_apic_id;	/* Processor X2_APIC ID  */
+	u32 local_apic_id;	/* Processor x2APIC ID  */
 	u32 lapic_flags;
-	u32 uid;		/* Extended X2_APIC processor ID */
+	u32 uid;		/* ACPI processor UID */
 };
=20
 /* 10: Local X2APIC NMI (ACPI 4.0) */
@@ -625,7 +747,7 @@ struct acpi_madt_local_x2apic {
 struct acpi_madt_local_x2apic_nmi {
 	struct acpi_subtable_header header;
 	u16 inti_flags;
-	u32 uid;		/* Processor X2_APIC ID */
+	u32 uid;		/* ACPI processor UID */
 	u8 lint;		/* LINTn to which NMI is connected */
 	u8 reserved[3];
 };
@@ -657,28 +779,34 @@ struct acpi_madt_local_x2apic_nmi {
=20
 /*************************************************************************=
******
  *
- * MCFG - PCI Memory Mapped Configuration table and sub-table
+ * MSCT - Maximum System Characteristics Table (ACPI 4.0)
+ *        Version 1
  *
  *************************************************************************=
*****/
=20
-struct acpi_table_mcfg {
+struct acpi_table_msct {
 	struct acpi_table_header header;	/* Common ACPI table =
header */
-	u8 reserved[8];
+	u32 proximity_offset;	/* Location of proximity info struct(s) */
+	u32 max_proximity_domains;	/* Max number of proximity domains =
*/
+	u32 max_clock_domains;	/* Max number of clock domains */
+	u64 max_address;	/* Max physical address in system */
 };
=20
-/* Subtable */
+/* Subtable - Maximum Proximity Domain Information. Version 1 */
=20
-struct acpi_mcfg_allocation {
-	u64 address;		/* Base address, processor-relative */
-	u16 pci_segment;	/* PCI segment group number */
-	u8 start_bus_number;	/* Starting PCI Bus number */
-	u8 end_bus_number;	/* Final PCI Bus number */
-	u32 reserved;
+struct acpi_msct_proximity {
+	u8 revision;
+	u8 length;
+	u32 range_start;	/* Start of domain range */
+	u32 range_end;		/* End of domain range */
+	u32 processor_capacity;
+	u64 memory_capacity;	/* In bytes */
 };
=20
 /*************************************************************************=
******
  *
  * SBST - Smart Battery Specification Table
+ *        Version 1
  *
  *************************************************************************=
*****/
=20
@@ -692,6 +820,7 @@ struct acpi_table_sbst {
 /*************************************************************************=
******
  *
  * SLIT - System Locality Distance Information Table
+ *        Version 1
  *
  *************************************************************************=
*****/
=20
@@ -703,60 +832,8 @@ struct acpi_table_slit {
=20
 /*************************************************************************=
******
  *
- * SPCR - Serial Port Console Redirection table
- *
- *************************************************************************=
*****/
-
-struct acpi_table_spcr {
-	struct acpi_table_header header;	/* Common ACPI table =
header */
-	u8 interface_type;	/* 0=3Dfull 16550, 1=3Dsubset of 16550 */
-	u8 reserved[3];
-	struct acpi_generic_address serial_port;
-	u8 interrupt_type;
-	u8 pc_interrupt;
-	u32 interrupt;
-	u8 baud_rate;
-	u8 parity;
-	u8 stop_bits;
-	u8 flow_control;
-	u8 terminal_type;
-	u8 reserved1;
-	u16 pci_device_id;
-	u16 pci_vendor_id;
-	u8 pci_bus;
-	u8 pci_device;
-	u8 pci_function;
-	u32 pci_flags;
-	u8 pci_segment;
-	u32 reserved2;
-};
-
-/*************************************************************************=
******
- *
- * SPMI - Server Platform Management Interface table
- *
- *************************************************************************=
*****/
-
-struct acpi_table_spmi {
-	struct acpi_table_header header;	/* Common ACPI table =
header */
-	u8 reserved;
-	u8 interface_type;
-	u16 spec_revision;	/* Version of IPMI */
-	u8 interrupt_type;
-	u8 gpe_number;		/* GPE assigned */
-	u8 reserved1;
-	u8 pci_device_flag;
-	u32 interrupt;
-	struct acpi_generic_address ipmi_register;
-	u8 pci_segment;
-	u8 pci_bus;
-	u8 pci_device;
-	u8 pci_function;
-};
-
-/*************************************************************************=
******
- *
  * SRAT - System Resource Affinity Table
+ *        Version 3
  *
  *************************************************************************=
*****/
=20
@@ -775,7 +852,9 @@ enum acpi_srat_type {
 	ACPI_SRAT_TYPE_RESERVED =3D 3	/* 3 and greater are reserved */
 };
=20
-/* SRAT sub-tables */
+/*
+ * SRAT Sub-tables, correspond to Type in struct acpi_subtable_header
+ */
=20
 /* 0: Processor Local APIC/SAPIC Affinity */
=20
@@ -789,6 +868,10 @@ struct acpi_srat_cpu_affinity {
 	u32 reserved;		/* Reserved, must be zero */
 };
=20
+/* Flags */
+
+#define ACPI_SRAT_CPU_USE_AFFINITY  (1)	/* 00: Use affinity =
structure */
+
 /* 1: Memory Affinity */
=20
 struct acpi_srat_mem_affinity {
@@ -797,9 +880,9 @@ struct acpi_srat_mem_affinity {
 	u16 reserved;		/* Reserved, must be zero */
 	u64 base_address;
 	u64 length;
-	u32 memory_type;	/* See acpi_address_range_id */
+	u32 reserved1;
 	u32 flags;
-	u64 reserved1;		/* Reserved, must be zero */
+	u64 reserved2;		/* Reserved, must be zero */
 };
=20
 /* Flags */
@@ -824,44 +907,6 @@ struct acpi_srat_x2apic_cpu_affinity {
=20
 #define ACPI_SRAT_CPU_ENABLED       (1)	/* 00: Use affinity =
structure */
=20
-/*************************************************************************=
******
- *
- * TCPA - Trusted Computing Platform Alliance table
- *
- *************************************************************************=
*****/
-
-struct acpi_table_tcpa {
-	struct acpi_table_header header;	/* Common ACPI table =
header */
-	u16 reserved;
-	u32 max_log_length;	/* Maximum length for the event log area =
*/
-	u64 log_address;	/* Address of the event log area */
-};
-
-/*************************************************************************=
******
- *
- * WDRT - Watchdog Resource Table
- *
- *************************************************************************=
*****/
-
-struct acpi_table_wdrt {
-	struct acpi_table_header header;	/* Common ACPI table =
header */
-	u32 header_length;	/* Watchdog Header Length */
-	u8 pci_segment;		/* PCI Segment number */
-	u8 pci_bus;		/* PCI Bus number */
-	u8 pci_device;		/* PCI Device number */
-	u8 pci_function;	/* PCI Function number */
-	u32 timer_period;	/* Period of one timer count (msec) */
-	u32 max_count;		/* Maximum counter value supported */
-	u32 min_count;		/* Minimum counter value */
-	u8 flags;
-	u8 reserved[3];
-	u32 entries;		/* Number of watchdog entries that follow =
*/
-};
-
-/* Flags */
-
-#define ACPI_WDRT_TIMER_ENABLED     (1)	/* 00: Timer enabled */
-
 /* Reset to default packing */
=20
 #pragma pack()
--- /dev/null
+++ a/xen/include/acpi/actbl2.h
@@ -0,0 +1,1050 @@
+/*************************************************************************=
*****
+ *
+ * Name: actbl2.h - ACPI Table Definitions (tables not in ACPI spec)
+ *
+ *************************************************************************=
****/
+
+/*
+ * Copyright (C) 2000 - 2011, 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:
+ * 1. Redistributions of source code must retain the above copyright
+ *    notice, this list of conditions, and the following disclaimer,
+ *    without modification.
+ * 2. Redistributions in binary form must reproduce at minimum a =
disclaimer
+ *    substantially similar to the "NO WARRANTY" disclaimer below
+ *    ("Disclaimer") and any redistribution must be conditioned upon
+ *    including a substantially similar Disclaimer requirement for =
further
+ *    binary redistribution.
+ * 3. Neither the names of the above-listed copyright holders nor the =
names
+ *    of any contributors may be used to endorse or promote products =
derived
+ *    from this software without specific prior written permission.
+ *
+ * Alternatively, this software may be distributed under the terms of the
+ * GNU General Public License ("GPL") version 2 as published by the Free
+ * Software Foundation.
+ *
+ * NO WARRANTY
+ * 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 MERCHANTIBILITY AND FITNESS FOR
+ * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ * HOLDERS OR CONTRIBUTORS BE LIABLE FOR SPECIAL, EXEMPLARY, OR CONSEQUENT=
IAL
+ * 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 DAMAGES.
+ */
+
+#ifndef __ACTBL2_H__
+#define __ACTBL2_H__
+
+/*************************************************************************=
******
+ *
+ * Additional ACPI Tables (2)
+ *
+ * These tables are not consumed directly by the ACPICA subsystem, but =
are
+ * included here to support device drivers and the AML disassembler.
+ *
+ * The tables in this file are defined by third-party specifications, and =
are
+ * not defined directly by the ACPI specification itself.
+ *
+ *************************************************************************=
*****/
+
+/*
+ * Values for description table header signatures for tables defined in =
this
+ * file. Useful because they make it more difficult to inadvertently type =
in
+ * the wrong signature.
+ */
+#define ACPI_SIG_ASF            "ASF!"	/* Alert Standard Format table */
+#define ACPI_SIG_BOOT           "BOOT"	/* Simple Boot Flag Table */
+#define ACPI_SIG_DBGP           "DBGP"	/* Debug Port table */
+#define ACPI_SIG_DMAR           "DMAR"	/* DMA Remapping table */
+#define ACPI_SIG_HPET           "HPET"	/* High Precision Event Timer =
table */
+#define ACPI_SIG_IBFT           "IBFT"	/* i_sCSI Boot Firmware Table */
+#define ACPI_SIG_IVRS           "IVRS"	/* I/O Virtualization Reporting =
Structure */
+#define ACPI_SIG_MCFG           "MCFG"	/* PCI Memory Mapped Configuration =
table */
+#define ACPI_SIG_MCHI           "MCHI"	/* Management Controller Host =
Interface table */
+#define ACPI_SIG_SLIC           "SLIC"	/* Software Licensing Description =
Table */
+#define ACPI_SIG_SPCR           "SPCR"	/* Serial Port Console Redirection =
table */
+#define ACPI_SIG_SPMI           "SPMI"	/* Server Platform Management =
Interface table */
+#define ACPI_SIG_TCPA           "TCPA"	/* Trusted Computing Platform =
Alliance table */
+#define ACPI_SIG_UEFI           "UEFI"	/* Uefi Boot Optimization Table */
+#define ACPI_SIG_WAET           "WAET"	/* Windows ACPI Emulated devices =
Table */
+#define ACPI_SIG_WDAT           "WDAT"	/* Watchdog Action Table */
+#define ACPI_SIG_WDDT           "WDDT"	/* Watchdog Timer Description =
Table */
+#define ACPI_SIG_WDRT           "WDRT"	/* Watchdog Resource Table */
+
+#ifdef ACPI_UNDEFINED_TABLES
+/*
+ * These tables have been seen in the field, but no definition has been =
found
+ */
+#define ACPI_SIG_ATKG           "ATKG"
+#define ACPI_SIG_GSCI           "GSCI"	/* GMCH SCI table */
+#define ACPI_SIG_IEIT           "IEIT"
+#endif
+
+/*
+ * All tables must be byte-packed to match the ACPI specification, since
+ * the tables are provided by the system BIOS.
+ */
+#pragma pack(1)
+
+/*
+ * Note about bitfields: The u8 type is used for bitfields in ACPI =
tables.
+ * This is the only type that is even remotely portable. Anything else is =
not
+ * portable, so do not use any other bitfield types.
+ */
+
+/*************************************************************************=
******
+ *
+ * ASF - Alert Standard Format table (Signature "ASF!")
+ *       Revision 0x10
+ *
+ * Conforms to the Alert Standard Format Specification V2.0, 23 April =
2003
+ *
+ *************************************************************************=
*****/
+
+struct acpi_table_asf {
+	struct acpi_table_header header;	/* Common ACPI table =
header */
+};
+
+/* ASF subtable header */
+
+struct acpi_asf_header {
+	u8 type;
+	u8 reserved;
+	u16 length;
+};
+
+/* Values for Type field above */
+
+enum acpi_asf_type {
+	ACPI_ASF_TYPE_INFO =3D 0,
+	ACPI_ASF_TYPE_ALERT =3D 1,
+	ACPI_ASF_TYPE_CONTROL =3D 2,
+	ACPI_ASF_TYPE_BOOT =3D 3,
+	ACPI_ASF_TYPE_ADDRESS =3D 4,
+	ACPI_ASF_TYPE_RESERVED =3D 5
+};
+
+/*
+ * ASF subtables
+ */
+
+/* 0: ASF Information */
+
+struct acpi_asf_info {
+	struct acpi_asf_header header;
+	u8 min_reset_value;
+	u8 min_poll_interval;
+	u16 system_id;
+	u32 mfg_id;
+	u8 flags;
+	u8 reserved2[3];
+};
+
+/* Masks for Flags field above */
+
+#define ACPI_ASF_SMBUS_PROTOCOLS    (1)
+
+/* 1: ASF Alerts */
+
+struct acpi_asf_alert {
+	struct acpi_asf_header header;
+	u8 assert_mask;
+	u8 deassert_mask;
+	u8 alerts;
+	u8 data_length;
+};
+
+struct acpi_asf_alert_data {
+	u8 address;
+	u8 command;
+	u8 mask;
+	u8 value;
+	u8 sensor_type;
+	u8 type;
+	u8 offset;
+	u8 source_type;
+	u8 severity;
+	u8 sensor_number;
+	u8 entity;
+	u8 instance;
+};
+
+/* 2: ASF Remote Control */
+
+struct acpi_asf_remote {
+	struct acpi_asf_header header;
+	u8 controls;
+	u8 data_length;
+	u16 reserved2;
+};
+
+struct acpi_asf_control_data {
+	u8 function;
+	u8 address;
+	u8 command;
+	u8 value;
+};
+
+/* 3: ASF RMCP Boot Options */
+
+struct acpi_asf_rmcp {
+	struct acpi_asf_header header;
+	u8 capabilities[7];
+	u8 completion_code;
+	u32 enterprise_id;
+	u8 command;
+	u16 parameter;
+	u16 boot_options;
+	u16 oem_parameters;
+};
+
+/* 4: ASF Address */
+
+struct acpi_asf_address {
+	struct acpi_asf_header header;
+	u8 eprom_address;
+	u8 devices;
+};
+
+/*************************************************************************=
******
+ *
+ * BOOT - Simple Boot Flag Table
+ *        Version 1
+ *
+ * Conforms to the "Simple Boot Flag Specification", Version 2.1
+ *
+ *************************************************************************=
*****/
+
+struct acpi_table_boot {
+	struct acpi_table_header header;	/* Common ACPI table =
header */
+	u8 cmos_index;		/* Index in CMOS RAM for the boot register =
*/
+	u8 reserved[3];
+};
+
+/*************************************************************************=
******
+ *
+ * DBGP - Debug Port table
+ *        Version 1
+ *
+ * Conforms to the "Debug Port Specification", Version 1.00, 2/9/2000
+ *
+ *************************************************************************=
*****/
+
+struct acpi_table_dbgp {
+	struct acpi_table_header header;	/* Common ACPI table =
header */
+	u8 type;		/* 0=3Dfull 16550, 1=3Dsubset of 16550 */
+	u8 reserved[3];
+	struct acpi_generic_address debug_port;
+};
+
+/*************************************************************************=
******
+ *
+ * DMAR - DMA Remapping table
+ *        Version 1
+ *
+ * Conforms to "Intel Virtualization Technology for Directed I/O",
+ * Version 1.2, Sept. 2008
+ *
+ *************************************************************************=
*****/
+
+struct acpi_table_dmar {
+	struct acpi_table_header header;	/* Common ACPI table =
header */
+	u8 width;		/* Host Address Width */
+	u8 flags;
+	u8 reserved[10];
+};
+
+/* Masks for Flags field above */
+
+#define ACPI_DMAR_INTR_REMAP        (1)
+#define ACPI_DMAR_X2APIC_OPT_OUT    (1<<1)
+
+/* DMAR subtable header */
+
+struct acpi_dmar_header {
+	u16 type;
+	u16 length;
+};
+
+/* Values for subtable type in struct acpi_dmar_header */
+
+enum acpi_dmar_type {
+	ACPI_DMAR_TYPE_HARDWARE_UNIT =3D 0,
+	ACPI_DMAR_TYPE_RESERVED_MEMORY =3D 1,
+	ACPI_DMAR_TYPE_ATSR =3D 2,
+	ACPI_DMAR_HARDWARE_AFFINITY =3D 3,
+	ACPI_DMAR_TYPE_RESERVED =3D 4	/* 4 and greater are reserved */
+};
+
+/* DMAR Device Scope structure */
+
+struct acpi_dmar_device_scope {
+	u8 entry_type;
+	u8 length;
+	u16 reserved;
+	u8 enumeration_id;
+	u8 bus;
+};
+
+/* Values for entry_type in struct acpi_dmar_device_scope */
+
+enum acpi_dmar_scope_type {
+	ACPI_DMAR_SCOPE_TYPE_NOT_USED =3D 0,
+	ACPI_DMAR_SCOPE_TYPE_ENDPOINT =3D 1,
+	ACPI_DMAR_SCOPE_TYPE_BRIDGE =3D 2,
+	ACPI_DMAR_SCOPE_TYPE_IOAPIC =3D 3,
+	ACPI_DMAR_SCOPE_TYPE_HPET =3D 4,
+	ACPI_DMAR_SCOPE_TYPE_RESERVED =3D 5	/* 5 and greater are =
reserved */
+};
+
+struct acpi_dmar_pci_path {
+	u8 dev;
+	u8 fn;
+};
+
+/*
+ * DMAR Sub-tables, correspond to Type in struct acpi_dmar_header
+ */
+
+/* 0: Hardware Unit Definition */
+
+struct acpi_dmar_hardware_unit {
+	struct acpi_dmar_header header;
+	u8 flags;
+	u8 reserved;
+	u16 segment;
+	u64 address;		/* Register Base Address */
+};
+
+/* Masks for Flags field above */
+
+#define ACPI_DMAR_INCLUDE_ALL       (1)
+
+/* 1: Reserved Memory Defininition */
+
+struct acpi_dmar_reserved_memory {
+	struct acpi_dmar_header header;
+	u16 reserved;
+	u16 segment;
+	u64 base_address;	/* 4_k aligned base address */
+	u64 end_address;	/* 4_k aligned limit address */
+};
+
+/* Masks for Flags field above */
+
+#define ACPI_DMAR_ALLOW_ALL         (1)
+
+/* 2: Root Port ATS Capability Reporting Structure */
+
+struct acpi_dmar_atsr {
+	struct acpi_dmar_header header;
+	u8 flags;
+	u8 reserved;
+	u16 segment;
+};
+
+/* Masks for Flags field above */
+
+#define ACPI_DMAR_ALL_PORTS         (1)
+
+/* 3: Remapping Hardware Static Affinity Structure */
+
+struct acpi_dmar_rhsa {
+	struct acpi_dmar_header header;
+	u32 reserved;
+	u64 base_address;
+	u32 proximity_domain;
+};
+
+/*************************************************************************=
******
+ *
+ * HPET - High Precision Event Timer table
+ *        Version 1
+ *
+ * Conforms to "IA-PC HPET (High Precision Event Timers) Specification",
+ * Version 1.0a, October 2004
+ *
+ *************************************************************************=
*****/
+
+struct acpi_table_hpet {
+	struct acpi_table_header header;	/* Common ACPI table =
header */
+	u32 id;			/* Hardware ID of event timer block */
+	struct acpi_generic_address address;	/* Address of event timer =
block */
+	u8 sequence;		/* HPET sequence number */
+	u16 minimum_tick;	/* Main counter min tick, periodic mode */
+	u8 flags;
+};
+
+/* Masks for Flags field above */
+
+#define ACPI_HPET_PAGE_PROTECT_MASK (3)
+
+/* Values for Page Protect flags */
+
+enum acpi_hpet_page_protect {
+	ACPI_HPET_NO_PAGE_PROTECT =3D 0,
+	ACPI_HPET_PAGE_PROTECT4 =3D 1,
+	ACPI_HPET_PAGE_PROTECT64 =3D 2
+};
+
+/*************************************************************************=
******
+ *
+ * IBFT - Boot Firmware Table
+ *        Version 1
+ *
+ * Conforms to "iSCSI Boot Firmware Table (iBFT) as Defined in ACPI 3.0b
+ * Specification", Version 1.01, March 1, 2007
+ *
+ * Note: It appears that this table is not intended to appear in the =
RSDT/XSDT.
+ * Therefore, it is not currently supported by the disassembler.
+ *
+ *************************************************************************=
*****/
+
+struct acpi_table_ibft {
+	struct acpi_table_header header;	/* Common ACPI table =
header */
+	u8 reserved[12];
+};
+
+/* IBFT common subtable header */
+
+struct acpi_ibft_header {
+	u8 type;
+	u8 version;
+	u16 length;
+	u8 index;
+	u8 flags;
+};
+
+/* Values for Type field above */
+
+enum acpi_ibft_type {
+	ACPI_IBFT_TYPE_NOT_USED =3D 0,
+	ACPI_IBFT_TYPE_CONTROL =3D 1,
+	ACPI_IBFT_TYPE_INITIATOR =3D 2,
+	ACPI_IBFT_TYPE_NIC =3D 3,
+	ACPI_IBFT_TYPE_TARGET =3D 4,
+	ACPI_IBFT_TYPE_EXTENSIONS =3D 5,
+	ACPI_IBFT_TYPE_RESERVED =3D 6	/* 6 and greater are reserved */
+};
+
+/* IBFT subtables */
+
+struct acpi_ibft_control {
+	struct acpi_ibft_header header;
+	u16 extensions;
+	u16 initiator_offset;
+	u16 nic0_offset;
+	u16 target0_offset;
+	u16 nic1_offset;
+	u16 target1_offset;
+};
+
+struct acpi_ibft_initiator {
+	struct acpi_ibft_header header;
+	u8 sns_server[16];
+	u8 slp_server[16];
+	u8 primary_server[16];
+	u8 secondary_server[16];
+	u16 name_length;
+	u16 name_offset;
+};
+
+struct acpi_ibft_nic {
+	struct acpi_ibft_header header;
+	u8 ip_address[16];
+	u8 subnet_mask_prefix;
+	u8 origin;
+	u8 gateway[16];
+	u8 primary_dns[16];
+	u8 secondary_dns[16];
+	u8 dhcp[16];
+	u16 vlan;
+	u8 mac_address[6];
+	u16 pci_address;
+	u16 name_length;
+	u16 name_offset;
+};
+
+struct acpi_ibft_target {
+	struct acpi_ibft_header header;
+	u8 target_ip_address[16];
+	u16 target_ip_socket;
+	u8 target_boot_lun[8];
+	u8 chap_type;
+	u8 nic_association;
+	u16 target_name_length;
+	u16 target_name_offset;
+	u16 chap_name_length;
+	u16 chap_name_offset;
+	u16 chap_secret_length;
+	u16 chap_secret_offset;
+	u16 reverse_chap_name_length;
+	u16 reverse_chap_name_offset;
+	u16 reverse_chap_secret_length;
+	u16 reverse_chap_secret_offset;
+};
+
+/*************************************************************************=
******
+ *
+ * IVRS - I/O Virtualization Reporting Structure
+ *        Version 1
+ *
+ * Conforms to "AMD I/O Virtualization Technology (IOMMU) Specification",
+ * Revision 1.26, February 2009.
+ *
+ *************************************************************************=
*****/
+
+struct acpi_table_ivrs {
+	struct acpi_table_header header;	/* Common ACPI table =
header */
+	u32 info;		/* Common virtualization info */
+	u64 reserved;
+};
+
+/* Values for Info field above */
+
+#define ACPI_IVRS_PHYSICAL_SIZE     0x00007F00	/* 7 bits, physical =
address size */
+#define ACPI_IVRS_VIRTUAL_SIZE      0x003F8000	/* 7 bits, virtual address =
size */
+#define ACPI_IVRS_ATS_RESERVED      0x00400000	/* ATS address translation =
range reserved */
+
+/* IVRS subtable header */
+
+struct acpi_ivrs_header {
+	u8 type;		/* Subtable type */
+	u8 flags;
+	u16 length;		/* Subtable length */
+	u16 device_id;		/* ID of IOMMU */
+};
+
+/* Values for subtable Type above */
+
+enum acpi_ivrs_type {
+	ACPI_IVRS_TYPE_HARDWARE =3D 0x10,
+	ACPI_IVRS_TYPE_MEMORY_ALL /* _MEMORY1 */ =3D 0x20,
+	ACPI_IVRS_TYPE_MEMORY_ONE /* _MEMORY2 */ =3D 0x21,
+	ACPI_IVRS_TYPE_MEMORY_RANGE /* _MEMORY3 */ =3D 0x22,
+	ACPI_IVRS_TYPE_MEMORY_IOMMU =3D 0x23
+};
+
+/* Masks for Flags field above for IVHD subtable */
+
+#define ACPI_IVHD_TT_ENABLE         (1)
+#define ACPI_IVHD_PASS_PW           (1<<1)
+#define ACPI_IVHD_RES_PASS_PW       (1<<2)
+#define ACPI_IVHD_ISOC              (1<<3)
+#define ACPI_IVHD_IOTLB             (1<<4)
+
+/* Masks for Flags field above for IVMD subtable */
+
+#define ACPI_IVMD_UNITY             (1)
+#define ACPI_IVMD_READ              (1<<1)
+#define ACPI_IVMD_WRITE             (1<<2)
+#define ACPI_IVMD_EXCLUSION_RANGE   (1<<3)
+
+/*
+ * IVRS subtables, correspond to Type in struct acpi_ivrs_header
+ */
+
+/* 0x10: I/O Virtualization Hardware Definition Block (IVHD) */
+
+struct acpi_ivrs_hardware {
+	struct acpi_ivrs_header header;
+	u16 capability_offset;	/* Offset for IOMMU control fields */
+	u64 base_address;	/* IOMMU control registers */
+	u16 pci_segment_group;
+	u16 info;		/* MSI number and unit ID */
+	u32 reserved;
+};
+
+/* Masks for Info field above */
+
+#define ACPI_IVHD_MSI_NUMBER_MASK   0x001F	/* 5 bits, MSI message =
number */
+#define ACPI_IVHD_UNIT_ID_MASK      0x1F00	/* 5 bits, unit_iD */
+
+/*
+ * Device Entries for IVHD subtable, appear after struct acpi_ivrs_hardwar=
e structure.
+ * Upper two bits of the Type field are the (encoded) length of the =
structure.
+ * Currently, only 4 and 8 byte entries are defined. 16 and 32 byte =
entries
+ * are reserved for future use but not defined.
+ */
+struct acpi_ivrs_de_header {
+	u8 type;
+	u16 id;
+	u8 data_setting;
+};
+
+/* Length of device entry is in the top two bits of Type field above */
+
+#define ACPI_IVHD_ENTRY_LENGTH      0xC0
+
+/* Values for device entry Type field above */
+
+enum acpi_ivrs_device_entry_type {
+	/* 4-byte device entries, all use struct acpi_ivrs_device4 */
+
+	ACPI_IVRS_TYPE_PAD4 =3D 0,
+	ACPI_IVRS_TYPE_ALL =3D 1,
+	ACPI_IVRS_TYPE_SELECT =3D 2,
+	ACPI_IVRS_TYPE_START =3D 3,
+	ACPI_IVRS_TYPE_END =3D 4,
+
+	/* 8-byte device entries */
+
+	ACPI_IVRS_TYPE_PAD8 =3D 64,
+	ACPI_IVRS_TYPE_NOT_USED =3D 65,
+	ACPI_IVRS_TYPE_ALIAS_SELECT =3D 66,	/* Uses struct acpi_ivrs_de=
vice8a */
+	ACPI_IVRS_TYPE_ALIAS_START =3D 67,	/* Uses struct acpi_ivrs_de=
vice8a */
+	ACPI_IVRS_TYPE_EXT_SELECT =3D 70,	/* Uses struct acpi_ivrs_de=
vice8b */
+	ACPI_IVRS_TYPE_EXT_START =3D 71,	/* Uses struct acpi_ivrs_de=
vice8b */
+	ACPI_IVRS_TYPE_SPECIAL =3D 72	/* Uses struct acpi_ivrs_device8c =
*/
+};
+
+/* Values for Data field above */
+
+#define ACPI_IVHD_INIT_PASS         (1)
+#define ACPI_IVHD_EINT_PASS         (1<<1)
+#define ACPI_IVHD_NMI_PASS          (1<<2)
+#define ACPI_IVHD_SYSTEM_MGMT       (3<<4)
+#define ACPI_IVHD_LINT0_PASS        (1<<6)
+#define ACPI_IVHD_LINT1_PASS        (1<<7)
+
+/* Types 0-4: 4-byte device entry */
+
+struct acpi_ivrs_device4 {
+	struct acpi_ivrs_de_header header;
+};
+
+/* Types 66-67: 8-byte device entry */
+
+struct acpi_ivrs_device8a {
+	struct acpi_ivrs_de_header header;
+	u8 reserved1;
+	u16 used_id;
+	u8 reserved2;
+};
+
+/* Types 70-71: 8-byte device entry */
+
+struct acpi_ivrs_device8b {
+	struct acpi_ivrs_de_header header;
+	u32 extended_data;
+};
+
+/* Values for extended_data above */
+
+#define ACPI_IVHD_ATS_DISABLED      (1<<31)
+
+/* Type 72: 8-byte device entry */
+
+struct acpi_ivrs_device8c {
+	struct acpi_ivrs_de_header header;
+	u8 handle;
+	u16 used_id;
+	u8 variety;
+};
+
+/* Values for Variety field above */
+
+#define ACPI_IVHD_IOAPIC            1
+#define ACPI_IVHD_HPET              2
+
+/* 0x20, 0x21, 0x22: I/O Virtualization Memory Definition Block (IVMD) */
+
+struct acpi_ivrs_memory {
+	struct acpi_ivrs_header header;
+	u16 aux_data;
+	u64 reserved;
+	u64 start_address;
+	u64 memory_length;
+};
+
+/*************************************************************************=
******
+ *
+ * MCFG - PCI Memory Mapped Configuration table and sub-table
+ *        Version 1
+ *
+ * Conforms to "PCI Firmware Specification", Revision 3.0, June 20, 2005
+ *
+ *************************************************************************=
*****/
+
+struct acpi_table_mcfg {
+	struct acpi_table_header header;	/* Common ACPI table =
header */
+	u8 reserved[8];
+};
+
+/* Subtable */
+
+struct acpi_mcfg_allocation {
+	u64 address;		/* Base address, processor-relative */
+	u16 pci_segment;	/* PCI segment group number */
+	u8 start_bus_number;	/* Starting PCI Bus number */
+	u8 end_bus_number;	/* Final PCI Bus number */
+	u32 reserved;
+};
+
+/*************************************************************************=
******
+ *
+ * MCHI - Management Controller Host Interface Table
+ *        Version 1
+ *
+ * Conforms to "Management Component Transport Protocol (MCTP) Host
+ * Interface Specification", Revision 1.0.0a, October 13, 2009
+ *
+ *************************************************************************=
*****/
+
+struct acpi_table_mchi {
+	struct acpi_table_header header;	/* Common ACPI table =
header */
+	u8 interface_type;
+	u8 protocol;
+	u64 protocol_data;
+	u8 interrupt_type;
+	u8 gpe;
+	u8 pci_device_flag;
+	u32 global_interrupt;
+	struct acpi_generic_address control_register;
+	u8 pci_segment;
+	u8 pci_bus;
+	u8 pci_device;
+	u8 pci_function;
+};
+
+/*************************************************************************=
******
+ *
+ * SLIC - Software Licensing Description Table
+ *        Version 1
+ *
+ * Conforms to "OEM Activation 2.0 for Windows Vista Operating Systems",
+ * Copyright 2006
+ *
+ *************************************************************************=
*****/
+
+/* Basic SLIC table is only the common ACPI header */
+
+struct acpi_table_slic {
+	struct acpi_table_header header;	/* Common ACPI table =
header */
+};
+
+/* Common SLIC subtable header */
+
+struct acpi_slic_header {
+	u32 type;
+	u32 length;
+};
+
+/* Values for Type field above */
+
+enum acpi_slic_type {
+	ACPI_SLIC_TYPE_PUBLIC_KEY =3D 0,
+	ACPI_SLIC_TYPE_WINDOWS_MARKER =3D 1,
+	ACPI_SLIC_TYPE_RESERVED =3D 2	/* 2 and greater are reserved */
+};
+
+/*
+ * SLIC Sub-tables, correspond to Type in struct acpi_slic_header
+ */
+
+/* 0: Public Key Structure */
+
+struct acpi_slic_key {
+	struct acpi_slic_header header;
+	u8 key_type;
+	u8 version;
+	u16 reserved;
+	u32 algorithm;
+	char magic[4];
+	u32 bit_length;
+	u32 exponent;
+	u8 modulus[128];
+};
+
+/* 1: Windows Marker Structure */
+
+struct acpi_slic_marker {
+	struct acpi_slic_header header;
+	u32 version;
+	char oem_id[ACPI_OEM_ID_SIZE];	/* ASCII OEM identification */
+	char oem_table_id[ACPI_OEM_TABLE_ID_SIZE];	/* ASCII OEM table =
identification */
+	char windows_flag[8];
+	u32 slic_version;
+	u8 reserved[16];
+	u8 signature[128];
+};
+
+/*************************************************************************=
******
+ *
+ * SPCR - Serial Port Console Redirection table
+ *        Version 1
+ *
+ * Conforms to "Serial Port Console Redirection Table",
+ * Version 1.00, January 11, 2002
+ *
+ *************************************************************************=
*****/
+
+struct acpi_table_spcr {
+	struct acpi_table_header header;	/* Common ACPI table =
header */
+	u8 interface_type;	/* 0=3Dfull 16550, 1=3Dsubset of 16550 */
+	u8 reserved[3];
+	struct acpi_generic_address serial_port;
+	u8 interrupt_type;
+	u8 pc_interrupt;
+	u32 interrupt;
+	u8 baud_rate;
+	u8 parity;
+	u8 stop_bits;
+	u8 flow_control;
+	u8 terminal_type;
+	u8 reserved1;
+	u16 pci_device_id;
+	u16 pci_vendor_id;
+	u8 pci_bus;
+	u8 pci_device;
+	u8 pci_function;
+	u32 pci_flags;
+	u8 pci_segment;
+	u32 reserved2;
+};
+
+/* Masks for pci_flags field above */
+
+#define ACPI_SPCR_DO_NOT_DISABLE    (1)
+
+/*************************************************************************=
******
+ *
+ * SPMI - Server Platform Management Interface table
+ *        Version 5
+ *
+ * Conforms to "Intelligent Platform Management Interface Specification
+ * Second Generation v2.0", Document Revision 1.0, February 12, 2004 with
+ * June 12, 2009 markup.
+ *
+ *************************************************************************=
*****/
+
+struct acpi_table_spmi {
+	struct acpi_table_header header;	/* Common ACPI table =
header */
+	u8 interface_type;
+	u8 reserved;		/* Must be 1 */
+	u16 spec_revision;	/* Version of IPMI */
+	u8 interrupt_type;
+	u8 gpe_number;		/* GPE assigned */
+	u8 reserved1;
+	u8 pci_device_flag;
+	u32 interrupt;
+	struct acpi_generic_address ipmi_register;
+	u8 pci_segment;
+	u8 pci_bus;
+	u8 pci_device;
+	u8 pci_function;
+	u8 reserved2;
+};
+
+/* Values for interface_type above */
+
+enum acpi_spmi_interface_types {
+	ACPI_SPMI_NOT_USED =3D 0,
+	ACPI_SPMI_KEYBOARD =3D 1,
+	ACPI_SPMI_SMI =3D 2,
+	ACPI_SPMI_BLOCK_TRANSFER =3D 3,
+	ACPI_SPMI_SMBUS =3D 4,
+	ACPI_SPMI_RESERVED =3D 5	/* 5 and above are reserved */
+};
+
+/*************************************************************************=
******
+ *
+ * TCPA - Trusted Computing Platform Alliance table
+ *        Version 1
+ *
+ * Conforms to "TCG PC Specific Implementation Specification",
+ * Version 1.1, August 18, 2003
+ *
+ *************************************************************************=
*****/
+
+struct acpi_table_tcpa {
+	struct acpi_table_header header;	/* Common ACPI table =
header */
+	u16 reserved;
+	u32 max_log_length;	/* Maximum length for the event log area =
*/
+	u64 log_address;	/* Address of the event log area */
+};
+
+/*************************************************************************=
******
+ *
+ * UEFI - UEFI Boot optimization Table
+ *        Version 1
+ *
+ * Conforms to "Unified Extensible Firmware Interface Specification",
+ * Version 2.3, May 8, 2009
+ *
+ *************************************************************************=
*****/
+
+struct acpi_table_uefi {
+	struct acpi_table_header header;	/* Common ACPI table =
header */
+	u8 identifier[16];	/* UUID identifier */
+	u16 data_offset;	/* Offset of remaining data in table */
+};
+
+/*************************************************************************=
******
+ *
+ * WAET - Windows ACPI Emulated devices Table
+ *        Version 1
+ *
+ * Conforms to "Windows ACPI Emulated Devices Table", version 1.0, April =
6, 2009
+ *
+ *************************************************************************=
*****/
+
+struct acpi_table_waet {
+	struct acpi_table_header header;	/* Common ACPI table =
header */
+	u32 flags;
+};
+
+/* Masks for Flags field above */
+
+#define ACPI_WAET_RTC_NO_ACK        (1)	/* RTC requires no int =
acknowledge */
+#define ACPI_WAET_TIMER_ONE_READ    (1<<1)	/* PM timer requires only =
one read */
+
+/*************************************************************************=
******
+ *
+ * WDAT - Watchdog Action Table
+ *        Version 1
+ *
+ * Conforms to "Hardware Watchdog Timers Design Specification",
+ * Copyright 2006 Microsoft Corporation.
+ *
+ *************************************************************************=
*****/
+
+struct acpi_table_wdat {
+	struct acpi_table_header header;	/* Common ACPI table =
header */
+	u32 header_length;	/* Watchdog Header Length */
+	u16 pci_segment;	/* PCI Segment number */
+	u8 pci_bus;		/* PCI Bus number */
+	u8 pci_device;		/* PCI Device number */
+	u8 pci_function;	/* PCI Function number */
+	u8 reserved[3];
+	u32 timer_period;	/* Period of one timer count (msec) */
+	u32 max_count;		/* Maximum counter value supported */
+	u32 min_count;		/* Minimum counter value */
+	u8 flags;
+	u8 reserved2[3];
+	u32 entries;		/* Number of watchdog entries that follow =
*/
+};
+
+/* Masks for Flags field above */
+
+#define ACPI_WDAT_ENABLED           (1)
+#define ACPI_WDAT_STOPPED           0x80
+
+/* WDAT Instruction Entries (actions) */
+
+struct acpi_wdat_entry {
+	u8 action;
+	u8 instruction;
+	u16 reserved;
+	struct acpi_generic_address register_region;
+	u32 value;		/* Value used with Read/Write register */
+	u32 mask;		/* Bitmask required for this register =
instruction */
+};
+
+/* Values for Action field above */
+
+enum acpi_wdat_actions {
+	ACPI_WDAT_RESET =3D 1,
+	ACPI_WDAT_GET_CURRENT_COUNTDOWN =3D 4,
+	ACPI_WDAT_GET_COUNTDOWN =3D 5,
+	ACPI_WDAT_SET_COUNTDOWN =3D 6,
+	ACPI_WDAT_GET_RUNNING_STATE =3D 8,
+	ACPI_WDAT_SET_RUNNING_STATE =3D 9,
+	ACPI_WDAT_GET_STOPPED_STATE =3D 10,
+	ACPI_WDAT_SET_STOPPED_STATE =3D 11,
+	ACPI_WDAT_GET_REBOOT =3D 16,
+	ACPI_WDAT_SET_REBOOT =3D 17,
+	ACPI_WDAT_GET_SHUTDOWN =3D 18,
+	ACPI_WDAT_SET_SHUTDOWN =3D 19,
+	ACPI_WDAT_GET_STATUS =3D 32,
+	ACPI_WDAT_SET_STATUS =3D 33,
+	ACPI_WDAT_ACTION_RESERVED =3D 34	/* 34 and greater are =
reserved */
+};
+
+/* Values for Instruction field above */
+
+enum acpi_wdat_instructions {
+	ACPI_WDAT_READ_VALUE =3D 0,
+	ACPI_WDAT_READ_COUNTDOWN =3D 1,
+	ACPI_WDAT_WRITE_VALUE =3D 2,
+	ACPI_WDAT_WRITE_COUNTDOWN =3D 3,
+	ACPI_WDAT_INSTRUCTION_RESERVED =3D 4,	/* 4 and greater are =
reserved */
+	ACPI_WDAT_PRESERVE_REGISTER =3D 0x80	/* Except for this value =
*/
+};
+
+/*************************************************************************=
******
+ *
+ * WDDT - Watchdog Descriptor Table
+ *        Version 1
+ *
+ * Conforms to "Using the Intel ICH Family Watchdog Timer (WDT)",
+ * Version 001, September 2002
+ *
+ *************************************************************************=
*****/
+
+struct acpi_table_wddt {
+	struct acpi_table_header header;	/* Common ACPI table =
header */
+	u16 spec_version;
+	u16 table_version;
+	u16 pci_vendor_id;
+	struct acpi_generic_address address;
+	u16 max_count;		/* Maximum counter value supported */
+	u16 min_count;		/* Minimum counter value supported */
+	u16 period;
+	u16 status;
+	u16 capability;
+};
+
+/* Flags for Status field above */
+
+#define ACPI_WDDT_AVAILABLE     (1)
+#define ACPI_WDDT_ACTIVE        (1<<1)
+#define ACPI_WDDT_TCO_OS_OWNED  (1<<2)
+#define ACPI_WDDT_USER_RESET    (1<<11)
+#define ACPI_WDDT_WDT_RESET     (1<<12)
+#define ACPI_WDDT_POWER_FAIL    (1<<13)
+#define ACPI_WDDT_UNKNOWN_RESET (1<<14)
+
+/* Flags for Capability field above */
+
+#define ACPI_WDDT_AUTO_RESET    (1)
+#define ACPI_WDDT_ALERT_SUPPORT (1<<1)
+
+/*************************************************************************=
******
+ *
+ * WDRT - Watchdog Resource Table
+ *        Version 1
+ *
+ * Conforms to "Watchdog Timer Hardware Requirements for Windows Server =
2003",
+ * Version 1.01, August 28, 2006
+ *
+ *************************************************************************=
*****/
+
+struct acpi_table_wdrt {
+	struct acpi_table_header header;	/* Common ACPI table =
header */
+	struct acpi_generic_address control_register;
+	struct acpi_generic_address count_register;
+	u16 pci_device_id;
+	u16 pci_vendor_id;
+	u8 pci_bus;		/* PCI Bus number */
+	u8 pci_device;		/* PCI Device number */
+	u8 pci_function;	/* PCI Function number */
+	u8 pci_segment;		/* PCI Segment number */
+	u16 max_count;		/* Maximum counter value supported */
+	u8 units;
+};
+
+/* Reset to default packing */
+
+#pragma pack()
+
+#endif				/* __ACTBL2_H__ */



--=__Part96B93371.0__=
Content-Type: text/plain; name="acpi-update-structs.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="acpi-update-structs.patch"

ACPI: update table interface headers=0A=0A... to what is being used on =
Linux 3.1 (and 3.2-rc).=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=
=0A=0A--- a/xen/drivers/acpi/numa.c=0A+++ b/xen/drivers/acpi/numa.c=0A@@ =
-78,9 +78,11 @@ void __init acpi_table_print_srat_entry(=0A 			=
if (srat_rev < 2)=0A 				proximity_domain &=3D =
0xff;=0A 			ACPI_DEBUG_PRINT((ACPI_DB_INFO,=0A-		=
			  "SRAT Memory (0x%016"PRIx64" length 0x%016"PRIx64=
" type 0x%x) in proximity domain %d %s%s\n",=0A+				=
	  "SRAT Memory (%#016"PRIx64=0A+					=
  " length %#016"PRIx64")"=0A+					  " in =
proximity domain %d %s%s\n",=0A 					  =
p->base_address, p->length,=0A-					  =
p->memory_type, proximity_domain,=0A+					  =
proximity_domain,=0A 					  p->flags & =
ACPI_SRAT_MEM_ENABLED=0A 					  ? =
"enabled" : "disabled",=0A 					  p->flags =
& ACPI_SRAT_MEM_HOT_PLUGGABLE=0A--- a/xen/include/acpi/actbl.h=0A+++ =
b/xen/include/acpi/actbl.h=0A@@ -5,7 +5,7 @@=0A  **************************=
***************************************************/=0A =0A /*=0A- * =
Copyright (C) 2000 - 2007, R. Byron Moore=0A+ * Copyright (C) 2000 - 2011, =
Intel Corp.=0A  * All rights reserved.=0A  *=0A  * Redistribution and use =
in source and binary forms, with or without=0A@@ -44,9 +44,23 @@=0A =
#ifndef __ACTBL_H__=0A #define __ACTBL_H__=0A =0A+/************************=
*******************************************************=0A+ *=0A+ * =
Fundamental ACPI tables=0A+ *=0A+ * This file contains definitions for the =
ACPI tables that are directly consumed=0A+ * by ACPICA. All other tables =
are consumed by the OS-dependent ACPI-related=0A+ * device drivers and =
other OS support code.=0A+ *=0A+ * The RSDP and FACS do not use the common =
ACPI table header. All other ACPI=0A+ * tables use the header.=0A+ *=0A+ =
***************************************************************************=
***/=0A+=0A /*=0A- * Values for description table header signatures. =
Useful because they make=0A- * it more difficult to inadvertently type in =
the wrong signature.=0A+ * Values for description table header signatures =
for tables defined in this=0A+ * file. Useful because they make it more =
difficult to inadvertently type in=0A+ * the wrong signature.=0A  */=0A =
#define ACPI_SIG_DSDT           "DSDT"	/* Differentiated System Descriptio=
n Table */=0A #define ACPI_SIG_FADT           "FACP"	/* Fixed ACPI =
Description Table */=0A@@ -65,11 +79,6 @@=0A #pragma pack(1)=0A =0A /*=0A- =
* These are the ACPI tables that are directly consumed by the subsystem.=0A=
- *=0A- * The RSDP and FACS do not use the common ACPI table header. All =
other ACPI=0A- * tables use the header.=0A- *=0A  * Note about bitfields: =
The u8 type is used for bitfields in ACPI tables.=0A  * This is the only =
type that is even remotely portable. Anything else is not=0A  * portable, =
so do not use any other bitfield types.=0A@@ -77,9 +86,8 @@=0A =0A =
/**************************************************************************=
*****=0A  *=0A- * ACPI Table Header. This common header is used by all =
tables except the=0A- * RSDP and FACS. The define is used for direct =
inclusion of header into=0A- * other ACPI tables=0A+ * Master ACPI Table =
Header. This common header is used by all ACPI tables=0A+ * except the =
RSDP and FACS.=0A  *=0A  **************************************************=
****************************/=0A =0A@@ -95,13 +103,16 @@ struct acpi_table_=
header {=0A 	u32 asl_compiler_revision;	/* ASL compiler version =
*/=0A };=0A =0A-/*=0A+/****************************************************=
***************************=0A+ *=0A  * GAS - Generic Address Structure =
(ACPI 2.0+)=0A  *=0A  * Note: Since this structure is used in the ACPI =
tables, it is byte aligned.=0A- * If misalignment is not supported, access =
to the Address field must be=0A- * performed with care.=0A- */=0A+ * If =
misaliged access is not supported by the hardware, accesses to the=0A+ * =
64-bit Address field must be performed with care.=0A+ *=0A+ ***************=
***************************************************************/=0A+=0A =
struct acpi_generic_address {=0A 	u8 space_id;		/* Address =
space where struct or register exists */=0A 	u8 bit_width;		/* =
Size in bits of given register */=0A@@ -113,6 +124,7 @@ struct acpi_generic=
_address {=0A /************************************************************=
*******************=0A  *=0A  * RSDP - Root System Description Pointer =
(Signature is "RSD PTR ")=0A+ *        Version 2=0A  *=0A  ****************=
**************************************************************/=0A =0A@@ =
-133,6 +145,7 @@ struct acpi_table_rsdp {=0A /*****************************=
**************************************************=0A  *=0A  * RSDT/XSDT - =
Root System Description Tables=0A+ *             Version 1 (both)=0A  *=0A =
 **************************************************************************=
****/=0A =0A@@ -161,21 +174,29 @@ struct acpi_table_facs {=0A 	u32 =
flags;=0A 	u64 xfirmware_waking_vector;	/* 64-bit version of the =
Firmware Waking Vector (ACPI 2.0+) */=0A 	u8 version;		/* =
Version of this table (ACPI 2.0+) */=0A-	u8 reserved[31];	/* =
Reserved, must be zero */=0A+	u8 reserved[3];		/* Reserved, must =
be zero */=0A+	u32 ospm_flags;		/* Flags to be set by OSPM (ACPI =
4.0) */=0A+	u8 reserved1[24];	/* Reserved, must be zero */=0A =
};=0A =0A-/* Flag macros */=0A+/* Masks for global_lock flag field above =
*/=0A+=0A+#define ACPI_GLOCK_PENDING          (1)	/* 00: Pending =
global lock ownership */=0A+#define ACPI_GLOCK_OWNED            (1<<1)	/* =
01: Global lock is owned */=0A =0A-#define ACPI_FACS_S4_BIOS_PRESENT (1)	=
/* 00: S4BIOS support is present */=0A+/* Masks for Flags field above  =
*/=0A =0A-/* Global lock flags */=0A+#define ACPI_FACS_S4_BIOS_PRESENT   =
(1)	/* 00: S4BIOS support is present */=0A+#define ACPI_FACS_64BIT_WAKE=
        (1<<1)	/* 01: 64-bit wake vector supported (ACPI 4.0) */=0A =
=0A-#define ACPI_GLOCK_PENDING      0x01	/* 00: Pending global lock =
ownership */=0A-#define ACPI_GLOCK_OWNED        0x02	/* 01: Global lock =
is owned */=0A+/* Masks for ospm_flags field above */=0A+=0A+#define =
ACPI_FACS_64BIT_ENVIRONMENT (1)	/* 00: 64-bit wake environment is required =
(ACPI 4.0) */=0A =0A /*****************************************************=
**************************=0A  *=0A  * FADT - Fixed ACPI Description Table =
(Signature "FACP")=0A+ *        Version 4=0A  *=0A  ***********************=
*******************************************************/=0A =0A@@ -214,11 =
+235,11 @@ struct acpi_table_fadt {=0A 	u16 flush_size;		/* =
Processor's memory cache line width, in bytes */=0A 	u16 flush_stride;	=
/* Number of flush strides that need to be read */=0A 	u8 duty_offset;		=
/* Processor duty cycle index in processor's P_CNT reg */=0A-	u8 =
duty_width;		/* Processor duty cycle value bit width in P_CNT =
register. */=0A+	u8 duty_width;		/* Processor duty cycle =
value bit width in P_CNT register */=0A 	u8 day_alarm;		/* =
Index to day-of-month alarm in RTC CMOS RAM */=0A 	u8 month_alarm;		=
/* Index to month-of-year alarm in RTC CMOS RAM */=0A 	u8 century;		=
/* Index to century in RTC CMOS RAM */=0A-	u16 boot_flags;		/* =
IA-PC Boot Architecture Flags. See Table 5-10 for description */=0A+	=
u16 boot_flags;		/* IA-PC Boot Architecture Flags (see below for =
individual flags) */=0A 	u8 reserved;		/* Reserved, must =
be zero */=0A 	u32 flags;		/* Miscellaneous flag bits (see =
below for individual flags) */=0A 	struct acpi_generic_address =
reset_register;	/* 64-bit address of the Reset register */=0A@@ -236,32 =
+257,41 @@ struct acpi_table_fadt {=0A 	struct acpi_generic_address =
xgpe1_block;	/* 64-bit Extended General Purpose Event 1 Reg Blk address =
*/=0A };=0A =0A-/* FADT flags */=0A+/* Masks for FADT Boot Architecture =
Flags (boot_flags) */=0A =0A-#define ACPI_FADT_WBINVD            (1)	/* =
00: The wbinvd instruction works properly */=0A-#define ACPI_FADT_WBINVD_FL=
USH      (1<<1)	/* 01: The wbinvd flushes but does not invalidate =
*/=0A-#define ACPI_FADT_C1_SUPPORTED      (1<<2)	/* 02: All =
processors support C1 state */=0A-#define ACPI_FADT_C2_MP_SUPPORTED   =
(1<<3)	/* 03: C2 state works on MP system */=0A-#define ACPI_FADT_POWER_BU=
TTON      (1<<4)	/* 04: Power button is handled as a generic =
feature */=0A-#define ACPI_FADT_SLEEP_BUTTON      (1<<5)	/* 05: =
Sleep button is handled as a generic feature, or  not present */=0A-#define=
 ACPI_FADT_FIXED_RTC         (1<<6)	/* 06: RTC wakeup stat not in =
fixed register space */=0A-#define ACPI_FADT_S4_RTC_WAKE       (1<<7)	/* =
07: RTC wakeup stat not possible from S4 */=0A-#define ACPI_FADT_32BIT_TIME=
R       (1<<8)	/* 08: tmr_val is 32 bits 0=3D24-bits */=0A-#define =
ACPI_FADT_DOCKING_SUPPORTED (1<<9)	/* 09: Docking supported */=0A-#def=
ine ACPI_FADT_RESET_REGISTER    (1<<10)	/* 10: System reset via the FADT =
RESET_REG supported */=0A-#define ACPI_FADT_SEALED_CASE       (1<<11)	/* =
11: No internal expansion capabilities and case is sealed */=0A-#define =
ACPI_FADT_HEADLESS          (1<<12)	/* 12: No local video capabilities =
or local input devices */=0A-#define ACPI_FADT_SLEEP_TYPE        (1<<13)	=
/* 13: Must execute native instruction after writing  SLP_TYPx register =
*/=0A-#define ACPI_FADT_PCI_EXPRESS_WAKE  (1<<14)	/* 14: System =
supports PCIEXP_WAKE (STS/EN) bits (ACPI 3.0) */=0A-#define ACPI_FADT_PLATF=
ORM_CLOCK    (1<<15)	/* 15: OSPM should use platform-provided timer =
(ACPI 3.0) */=0A-#define ACPI_FADT_S4_RTC_VALID      (1<<16)	/* 16: =
Contents of RTC_STS valid after S4 wake (ACPI 3.0) */=0A-#define ACPI_FADT_=
REMOTE_POWER_ON   (1<<17)	/* 17: System is compatible with remote =
power on (ACPI 3.0) */=0A-#define ACPI_FADT_APIC_CLUSTER      (1<<18)	/* =
18: All local APICs must use cluster model (ACPI 3.0) */=0A-#define =
ACPI_FADT_APIC_PHYSICAL     (1<<19)	/* 19: All local x_aPICs must use =
physical dest mode (ACPI 3.0) */=0A+#define ACPI_FADT_LEGACY_DEVICES    =
(1)  	/* 00: [V2] System has LPC or ISA bus devices */=0A+#define =
ACPI_FADT_8042              (1<<1)	/* 01: [V3] System has an 8042 =
controller on port 60/64 */=0A+#define ACPI_FADT_NO_VGA            (1<<2)	=
/* 02: [V4] It is not safe to probe for VGA hardware */=0A+#define =
ACPI_FADT_NO_MSI            (1<<3)	/* 03: [V4] Message Signaled =
Interrupts (MSI) must not be enabled */=0A+#define ACPI_FADT_NO_ASPM       =
    (1<<4)	/* 04: [V4] PCIe ASPM control must not be enabled =
*/=0A+=0A+#define FADT2_REVISION_ID               3=0A+=0A+/* Masks for =
FADT flags */=0A+=0A+#define ACPI_FADT_WBINVD            (1)	/* 00: =
[V1] The wbinvd instruction works properly */=0A+#define ACPI_FADT_WBINVD_F=
LUSH      (1<<1)	/* 01: [V1] wbinvd flushes but does not invalidate =
caches */=0A+#define ACPI_FADT_C1_SUPPORTED      (1<<2)	/* 02: [V1] All =
processors support C1 state */=0A+#define ACPI_FADT_C2_MP_SUPPORTED   =
(1<<3)	/* 03: [V1] C2 state works on MP system */=0A+#define ACPI_FADT_POW=
ER_BUTTON      (1<<4)	/* 04: [V1] Power button is handled as a control =
method device */=0A+#define ACPI_FADT_SLEEP_BUTTON      (1<<5)	/* 05: =
[V1] Sleep button is handled as a control method device */=0A+#define =
ACPI_FADT_FIXED_RTC         (1<<6)	/* 06: [V1] RTC wakeup status not =
in fixed register space */=0A+#define ACPI_FADT_S4_RTC_WAKE       (1<<7)	=
/* 07: [V1] RTC alarm can wake system from S4 */=0A+#define ACPI_FADT_32BIT=
_TIMER       (1<<8)	/* 08: [V1] ACPI timer width is 32-bit (0=3D24-bit)=
 */=0A+#define ACPI_FADT_DOCKING_SUPPORTED (1<<9)	/* 09: [V1] =
Docking supported */=0A+#define ACPI_FADT_RESET_REGISTER    (1<<10)	/* =
10: [V2] System reset via the FADT RESET_REG supported */=0A+#define =
ACPI_FADT_SEALED_CASE       (1<<11)	/* 11: [V3] No internal expansion =
capabilities and case is sealed */=0A+#define ACPI_FADT_HEADLESS          =
(1<<12)	/* 12: [V3] No local video capabilities or local input devices =
*/=0A+#define ACPI_FADT_SLEEP_TYPE        (1<<13)	/* 13: [V3] Must =
execute native instruction after writing  SLP_TYPx register */=0A+#define =
ACPI_FADT_PCI_EXPRESS_WAKE  (1<<14)	/* 14: [V4] System supports =
PCIEXP_WAKE (STS/EN) bits (ACPI 3.0) */=0A+#define ACPI_FADT_PLATFORM_CLOCK=
    (1<<15)	/* 15: [V4] OSPM should use platform-provided timer (ACPI =
3.0) */=0A+#define ACPI_FADT_S4_RTC_VALID      (1<<16)	/* 16: [V4] =
Contents of RTC_STS valid after S4 wake (ACPI 3.0) */=0A+#define ACPI_FADT_=
REMOTE_POWER_ON   (1<<17)	/* 17: [V4] System is compatible with =
remote power on (ACPI 3.0) */=0A+#define ACPI_FADT_APIC_CLUSTER      =
(1<<18)	/* 18: [V4] All local APICs must use cluster model (ACPI 3.0) =
*/=0A+#define ACPI_FADT_APIC_PHYSICAL     (1<<19)	/* 19: [V4] All =
local x_aPICs must use physical dest mode (ACPI 3.0) */=0A+=0A+/* Values =
for preferred_profile (Preferred Power Management Profiles) */=0A =
=0A-/*=0A- * FADT Prefered Power Management Profiles=0A- */=0A enum =
acpi_prefered_pm_profiles {=0A 	PM_UNSPECIFIED =3D 0,=0A 	PM_DESKTOP =
=3D 1,=0A@@ -272,15 +302,6 @@ enum acpi_prefered_pm_profiles {=0A 	=
PM_APPLIANCE_PC =3D 6=0A };=0A =0A-/* FADT Boot Arch Flags */=0A-=0A-#defin=
e BAF_LEGACY_DEVICES              0x0001=0A-#define BAF_8042_KEYBOARD_CONTR=
OLLER    0x0002=0A-#define BAF_MSI_NOT_SUPPORTED           0x0008=0A-=0A-#d=
efine FADT2_REVISION_ID               3=0A-#define FADT2_MINUS_REVISION_ID =
        2=0A-=0A /* Reset to default packing */=0A =0A #pragma pack()=0A@@ =
-292,5 +313,22 @@ enum acpi_prefered_pm_profiles {=0A  */=0A =0A #include =
<acpi/actbl1.h>=0A+#include <acpi/actbl2.h>=0A+=0A+/*=0A+ * Sizes of the =
various flavors of FADT. We need to look closely=0A+ * at the FADT length =
because the version number essentially tells=0A+ * us nothing because of =
many BIOS bugs where the version does not=0A+ * match the expected length. =
In other words, the length of the=0A+ * FADT is the bottom line as to what =
the version really is.=0A+ *=0A+ * For reference, the values below are as =
follows:=0A+ *     FADT V1  size: 0x74=0A+ *     FADT V2  size: 0x84=0A+ * =
    FADT V3+ size: 0xF4=0A+ */=0A+#define ACPI_FADT_V1_SIZE       (u32) =
(ACPI_FADT_OFFSET (flags) + 4)=0A+#define ACPI_FADT_V2_SIZE       (u32) =
(ACPI_FADT_OFFSET (reserved4[0]) + 3)=0A+#define ACPI_FADT_V3_SIZE       =
(u32) (sizeof (struct acpi_table_fadt))=0A =0A #endif				=
/* __ACTBL_H__ */=0A--- a/xen/include/acpi/actbl1.h=0A+++ b/xen/include/acp=
i/actbl1.h=0A@@ -5,7 +5,7 @@=0A  ******************************************=
***********************************/=0A =0A /*=0A- * Copyright (C) 2000 - =
2007, R. Byron Moore=0A+ * Copyright (C) 2000 - 2011, Intel Corp.=0A  * =
All rights reserved.=0A  *=0A  * Redistribution and use in source and =
binary forms, with or without=0A@@ -46,34 +46,31 @@=0A =0A /***************=
****************************************************************=0A  *=0A- =
* Additional ACPI Tables=0A+ * Additional ACPI Tables (1)=0A  *=0A  * =
These tables are not consumed directly by the ACPICA subsystem, but are=0A =
 * included here to support device drivers and the AML disassembler.=0A  =
*=0A+ * The tables in this file are fully defined within the ACPI =
specification.=0A+ *=0A  **************************************************=
****************************/=0A =0A /*=0A- * Values for description table =
header signatures. Useful because they make=0A- * it more difficult to =
inadvertently type in the wrong signature.=0A+ * Values for description =
table header signatures for tables defined in this=0A+ * file. Useful =
because they make it more difficult to inadvertently type in=0A+ * the =
wrong signature.=0A  */=0A-#define ACPI_SIG_ASF            "ASF!"	/* =
Alert Standard Format table */=0A-#define ACPI_SIG_BOOT           "BOOT"	=
/* Simple Boot Flag Table */=0A+#define ACPI_SIG_BERT           "BERT"	/* =
Boot Error Record Table */=0A #define ACPI_SIG_CPEP           "CPEP"	/* =
Corrected Platform Error Polling table */=0A-#define ACPI_SIG_ERST         =
  "ERST"  /* Error Record Serialization Table */=0A-#define ACPI_SIG_DBGP  =
         "DBGP"	/* Debug Port table */=0A-#define ACPI_SIG_DMAR           =
"DMAR"	/* DMA Remapping table */=0A #define ACPI_SIG_ECDT           =
"ECDT"	/* Embedded Controller Boot Resources Table */=0A-#define =
ACPI_SIG_HPET           "HPET"	/* High Precision Event Timer table =
*/=0A+#define ACPI_SIG_EINJ           "EINJ"	/* Error Injection table =
*/=0A+#define ACPI_SIG_ERST           "ERST"	/* Error Record Serializati=
on Table */=0A+#define ACPI_SIG_HEST           "HEST"	/* Hardware Error =
Source Table */=0A #define ACPI_SIG_MADT           "APIC"	/* =
Multiple APIC Description Table */=0A-#define ACPI_SIG_MCFG           =
"MCFG"	/* PCI Memory Mapped Configuration table */=0A+#define ACPI_SIG_MSC=
T           "MSCT"	/* Maximum System Characteristics Table */=0A =
#define ACPI_SIG_SBST           "SBST"	/* Smart Battery Specification =
Table */=0A #define ACPI_SIG_SLIT           "SLIT"	/* System Locality =
Distance Information Table */=0A-#define ACPI_SIG_SPCR           "SPCR"	/* =
Serial Port Console Redirection table */=0A-#define ACPI_SIG_SPMI          =
 "SPMI"	/* Server Platform Management Interface table */=0A #define =
ACPI_SIG_SRAT           "SRAT"	/* System Resource Affinity Table =
*/=0A-#define ACPI_SIG_TCPA           "TCPA"	/* Trusted Computing =
Platform Alliance table */=0A-#define ACPI_SIG_WDRT           "WDRT"	/* =
Watchdog Resource Table */=0A =0A /*=0A  * All tables must be byte-packed =
to match the ACPI specification, since=0A@@ -87,7 +84,13 @@=0A  * =
portable, so do not use any other bitfield types.=0A  */=0A =0A-/* Common =
Sub-table header (used in MADT, SRAT, etc.) */=0A+/************************=
*******************************************************=0A+ *=0A+ * Common =
subtable headers=0A+ *=0A+ ************************************************=
******************************/=0A+=0A+/* Generic subtable header (used in =
MADT, SRAT, etc.) */=0A =0A struct acpi_subtable_header {=0A 	u8 =
type;=0A@@ -108,128 +111,54 @@ struct acpi_whea_header {=0A =0A /**********=
*********************************************************************=0A  =
*=0A- * ASF - Alert Standard Format table (Signature "ASF!")=0A- *=0A- * =
Conforms to the Alert Standard Format Specification V2.0, 23 April =
2003=0A+ * BERT - Boot Error Record Table (ACPI 4.0)=0A+ *        Version =
1=0A  *=0A  ***************************************************************=
***************/=0A =0A-struct acpi_table_asf {=0A+struct acpi_table_bert =
{=0A 	struct acpi_table_header header;	/* Common ACPI table =
header */=0A+	u32 region_length;	/* Length of the boot error region =
*/=0A+	u64 address;		/* Physical address of the error region =
*/=0A };=0A =0A-/* ASF subtable header */=0A-=0A-struct acpi_asf_header =
{=0A-	u8 type;=0A-	u8 reserved;=0A-	u16 length;=0A-};=0A-=0A-/*=
 Values for Type field above */=0A+/* Boot Error Region (not a subtable, =
pointed to by Address field above) */=0A =0A-enum acpi_asf_type {=0A-	=
ACPI_ASF_TYPE_INFO =3D 0,=0A-	ACPI_ASF_TYPE_ALERT =3D 1,=0A-	ACPI_ASF_TY=
PE_CONTROL =3D 2,=0A-	ACPI_ASF_TYPE_BOOT =3D 3,=0A-	ACPI_ASF_TYPE_ADDRE=
SS =3D 4,=0A-	ACPI_ASF_TYPE_RESERVED =3D 5=0A+struct acpi_bert_region =
{=0A+	u32 block_status;	/* Type of error information */=0A+	=
u32 raw_data_offset;	/* Offset to raw error data */=0A+	u32 =
raw_data_length;	/* Length of raw error data */=0A+	u32 =
data_length;	/* Length of generic error data */=0A+	u32 error_severity;=
	/* Severity code */=0A };=0A =0A-/*=0A- * ASF subtables=0A- =
*/=0A+/* Values for block_status flags above */=0A =0A-/* 0: ASF Informatio=
n */=0A+#define ACPI_BERT_UNCORRECTABLE             (1)=0A+#define =
ACPI_BERT_CORRECTABLE               (1<<1)=0A+#define ACPI_BERT_MULTIPLE_UN=
CORRECTABLE    (1<<2)=0A+#define ACPI_BERT_MULTIPLE_CORRECTABLE      =
(1<<3)=0A+#define ACPI_BERT_ERROR_ENTRY_COUNT         (0xFF<<4)	/* 8 bits, =
error count */=0A =0A-struct acpi_asf_info {=0A-	struct acpi_asf_hea=
der header;=0A-	u8 min_reset_value;=0A-	u8 min_poll_interval;=0A-	=
u16 system_id;=0A-	u32 mfg_id;=0A-	u8 flags;=0A-	u8 reserved2[3];=0A=
-};=0A-=0A-/* 1: ASF Alerts */=0A+/* Values for error_severity above */=0A =
=0A-struct acpi_asf_alert {=0A-	struct acpi_asf_header header;=0A-	u8 =
assert_mask;=0A-	u8 deassert_mask;=0A-	u8 alerts;=0A-	u8 =
data_length;=0A-};=0A-=0A-struct acpi_asf_alert_data {=0A-	u8 =
address;=0A-	u8 command;=0A-	u8 mask;=0A-	u8 value;=0A-	u8 =
sensor_type;=0A-	u8 type;=0A-	u8 offset;=0A-	u8 source_type;=0A-=
	u8 severity;=0A-	u8 sensor_number;=0A-	u8 entity;=0A-	u8 =
instance;=0A+enum acpi_bert_error_severity {=0A+	ACPI_BERT_ERROR_COR=
RECTABLE =3D 0,=0A+	ACPI_BERT_ERROR_FATAL =3D 1,=0A+	ACPI_BERT_E=
RROR_CORRECTED =3D 2,=0A+	ACPI_BERT_ERROR_NONE =3D 3,=0A+	ACPI_BERT_E=
RROR_RESERVED =3D 4	/* 4 and greater are reserved */=0A };=0A =0A-/* =
2: ASF Remote Control */=0A-=0A-struct acpi_asf_remote {=0A-	struct =
acpi_asf_header header;=0A-	u8 controls;=0A-	u8 data_length;=0A-=
	u16 reserved2;=0A-};=0A-=0A-struct acpi_asf_control_data {=0A-	u8 =
function;=0A-	u8 address;=0A-	u8 command;=0A-	u8 value;=0A-};=0A-=0A-/* =
3: ASF RMCP Boot Options */=0A-=0A-struct acpi_asf_rmcp {=0A-	struct =
acpi_asf_header header;=0A-	u8 capabilities[7];=0A-	u8 completion_code;=
=0A-	u32 enterprise_id;=0A-	u8 command;=0A-	u16 parameter;=0A-	=
u16 boot_options;=0A-	u16 oem_parameters;=0A-};=0A-=0A-/* 4: ASF Address =
*/=0A-=0A-struct acpi_asf_address {=0A-	struct acpi_asf_header header;=0A-	=
u8 eprom_address;=0A-	u8 devices;=0A-};=0A-=0A-/*************************=
******************************************************=0A- *=0A- * BOOT - =
Simple Boot Flag Table=0A- *=0A- ******************************************=
************************************/=0A-=0A-struct acpi_table_boot {=0A-	=
struct acpi_table_header header;	/* Common ACPI table header */=0A-	=
u8 cmos_index;		/* Index in CMOS RAM for the boot register */=0A-	=
u8 reserved[3];=0A-};=0A+/*=0A+ * Note: The generic error data that =
follows the error_severity field above=0A+ * uses the struct acpi_hest_gene=
ric_data defined under the HEST table below=0A+ */=0A =0A /****************=
***************************************************************=0A  *=0A- =
* CPEP - Corrected Platform Error Polling table=0A+ * CPEP - Corrected =
Platform Error Polling table (ACPI 4.0)=0A+ *        Version 1=0A  *=0A  =
***************************************************************************=
***/=0A =0A@@ -241,8 +170,7 @@ struct acpi_table_cpep {=0A /* Subtable =
*/=0A =0A struct acpi_cpep_polling {=0A-	u8 type;=0A-	u8 =
length;=0A+	struct acpi_subtable_header header;=0A 	u8 id;			=
/* Processor ID */=0A 	u8 eid;			/* Processor EID */=0A 	=
u32 interval;		/* Polling interval (msec) */=0A@@ -250,116 =
+178,103 @@ struct acpi_cpep_polling {=0A =0A /****************************=
***************************************************=0A  *=0A- * DBGP - =
Debug Port table=0A+ * ECDT - Embedded Controller Boot Resources Table=0A+ =
*        Version 1=0A  *=0A  **********************************************=
********************************/=0A =0A-struct acpi_table_dbgp {=0A+struct=
 acpi_table_ecdt {=0A 	struct acpi_table_header header;	/* Common =
ACPI table header */=0A-	u8 type;		/* 0=3Dfull 16550, =
1=3Dsubset of 16550 */=0A-	u8 reserved[3];=0A-	struct acpi_generic=
_address debug_port;=0A+	struct acpi_generic_address control;	/* =
Address of EC command/status register */=0A+	struct acpi_generic_address=
 data;	/* Address of EC data register */=0A+	u32 uid;		/* =
Unique ID - must be same as the EC _UID method */=0A+	u8 gpe;			=
/* The GPE for the EC */=0A+	u8 id[1];		/* Full namepath =
of the EC in the ACPI namespace */=0A };=0A =0A /**************************=
*****************************************************=0A  *=0A- * DMAR - =
DMA Remapping table=0A+ * EINJ - Error Injection Table (ACPI 4.0)=0A+ *    =
    Version 1=0A  *=0A  ***************************************************=
***************************/=0A =0A-struct acpi_table_dmar {=0A+struct =
acpi_table_einj {=0A 	struct acpi_table_header header;	/* Common =
ACPI table header */=0A-	u8 width;		/* Host Address =
Width */=0A+	u32 header_length;=0A 	u8 flags;=0A-	u8 reserved[10];=0A=
-};=0A-=0A-/* DMAR subtable header */=0A-=0A-struct acpi_dmar_header {=0A-	=
u16 type;=0A-	u16 length;=0A-};=0A-=0A-/* Values for subtable type in =
struct acpi_dmar_header */=0A-=0A-enum acpi_dmar_type {=0A-	ACPI_DMAR_T=
YPE_HARDWARE_UNIT =3D 0,=0A-	ACPI_DMAR_TYPE_RESERVED_MEMORY =3D 1,=0A-	=
ACPI_DMAR_TYPE_ATSR =3D 2,=0A-	ACPI_DMAR_TYPE_RESERVED =3D 3	/* 3 and =
greater are reserved */=0A-};=0A-=0A-struct acpi_dmar_device_scope {=0A-	=
u8 entry_type;=0A-	u8 length;=0A-	u16 reserved;=0A-	u8 =
enumeration_id;=0A-	u8 bus;=0A+	u8 reserved[3];=0A+	u32 =
entries;=0A };=0A =0A-/* Values for entry_type in struct acpi_dmar_device_s=
cope */=0A+/* EINJ Injection Instruction Entries (actions) */=0A =0A-enum =
acpi_dmar_scope_type {=0A-	ACPI_DMAR_SCOPE_TYPE_NOT_USED =3D 0,=0A-	=
ACPI_DMAR_SCOPE_TYPE_ENDPOINT =3D 1,=0A-	ACPI_DMAR_SCOPE_TYPE_BRIDGE=
 =3D 2,=0A-	ACPI_DMAR_SCOPE_TYPE_IOAPIC =3D 3,=0A-	ACPI_DMAR_SCOPE_TYP=
E_HPET =3D 4,=0A-	ACPI_DMAR_SCOPE_TYPE_RESERVED =3D 5	/* 5 and =
greater are reserved */=0A+struct acpi_einj_entry {=0A+	struct acpi_whea_he=
ader whea_header;	/* Common header for WHEA tables */=0A };=0A =
=0A-struct acpi_dmar_pci_path {=0A-	u8 dev;=0A-	u8 fn;=0A-};=0A+/* =
Masks for Flags field above */=0A =0A-/*=0A- * DMAR Sub-tables, correspond =
to Type in struct acpi_dmar_header=0A- */=0A+#define ACPI_EINJ_PRESERVE    =
      (1)=0A =0A-/* 0: Hardware Unit Definition */=0A+/* Values for Action =
field above */=0A =0A-struct acpi_dmar_hardware_unit {=0A-	struct =
acpi_dmar_header header;=0A-	u8 flags;=0A-	u8 reserved;=0A-	=
u16 segment;=0A-	u64 address;		/* Register Base Address =
*/=0A+enum acpi_einj_actions {=0A+	ACPI_EINJ_BEGIN_OPERATION =3D =
0,=0A+	ACPI_EINJ_GET_TRIGGER_TABLE =3D 1,=0A+	ACPI_EINJ_SET_ERROR_TYPE =
=3D 2,=0A+	ACPI_EINJ_GET_ERROR_TYPE =3D 3,=0A+	ACPI_EINJ_END_OPERA=
TION =3D 4,=0A+	ACPI_EINJ_EXECUTE_OPERATION =3D 5,=0A+	ACPI_EINJ_CHECK_BUS=
Y_STATUS =3D 6,=0A+	ACPI_EINJ_GET_COMMAND_STATUS =3D 7,=0A+	ACPI_EINJ_A=
CTION_RESERVED =3D 8,	/* 8 and greater are reserved */=0A+	ACPI_EINJ_T=
RIGGER_ERROR =3D 0xFF	/* Except for this value */=0A };=0A =0A-/* Flags =
*/=0A-=0A-#define ACPI_DMAR_INCLUDE_ALL       (1)=0A-=0A-/* 1: Reserved =
Memory Defininition */=0A+/* Values for Instruction field above */=0A =
=0A-struct acpi_dmar_reserved_memory {=0A-	struct acpi_dmar_header =
header;=0A-	u16 reserved;=0A-	u16 segment;=0A-	u64 =
base_address;		/* 4_k aligned base address */=0A-	u64 =
end_address;	/* 4_k aligned limit address */=0A+enum acpi_einj_instructi=
ons {=0A+	ACPI_EINJ_READ_REGISTER =3D 0,=0A+	ACPI_EINJ_READ_REGI=
STER_VALUE =3D 1,=0A+	ACPI_EINJ_WRITE_REGISTER =3D 2,=0A+	ACPI_EINJ_W=
RITE_REGISTER_VALUE =3D 3,=0A+	ACPI_EINJ_NOOP =3D 4,=0A+	ACPI_EINJ_I=
NSTRUCTION_RESERVED =3D 5	/* 5 and greater are reserved */=0A+};=0A+=
=0A+/* EINJ Trigger Error Action Table */=0A+=0A+struct acpi_einj_trigger =
{=0A+	u32 header_size;=0A+	u32 revision;=0A+	u32 table_size;=0A+=
	u32 entry_count;=0A };=0A =0A-/* Flags */=0A+/* Command status =
return values */=0A =0A-#define ACPI_DMAR_ALLOW_ALL         (1)=0A-=0A-/***=
***************************************************************************=
*=0A- *=0A- * ECDT - Embedded Controller Boot Resources Table=0A- *=0A- =
***************************************************************************=
***/=0A-=0A-struct acpi_table_ecdt {=0A-	struct acpi_table_header =
header;	/* Common ACPI table header */=0A-	struct acpi_generic_address=
 control;	/* Address of EC command/status register */=0A-	struct =
acpi_generic_address data;	/* Address of EC data register */=0A-	=
u32 uid;		/* Unique ID - must be same as the EC _UID method =
*/=0A-	u8 gpe;			/* The GPE for the EC */=0A-	u8 id[1];	=
	/* Full namepath of the EC in the ACPI namespace */=0A-};=0A+enum =
acpi_einj_command_status {=0A+	ACPI_EINJ_SUCCESS =3D 0,=0A+	ACPI_EINJ_F=
AILURE =3D 1,=0A+	ACPI_EINJ_INVALID_ACCESS =3D 2,=0A+	ACPI_EINJ_S=
TATUS_RESERVED =3D 3	/* 3 and greater are reserved */=0A+};=0A+=0A+/* =
Error types returned from ACPI_EINJ_GET_ERROR_TYPE (bitfield) */=0A+=0A+#de=
fine ACPI_EINJ_PROCESSOR_CORRECTABLE     (1)=0A+#define ACPI_EINJ_PROCESSOR=
_UNCORRECTABLE   (1<<1)=0A+#define ACPI_EINJ_PROCESSOR_FATAL           =
(1<<2)=0A+#define ACPI_EINJ_MEMORY_CORRECTABLE        (1<<3)=0A+#define =
ACPI_EINJ_MEMORY_UNCORRECTABLE      (1<<4)=0A+#define ACPI_EINJ_MEMORY_FATA=
L              (1<<5)=0A+#define ACPI_EINJ_PCIX_CORRECTABLE          =
(1<<6)=0A+#define ACPI_EINJ_PCIX_UNCORRECTABLE        (1<<7)=0A+#define =
ACPI_EINJ_PCIX_FATAL                (1<<8)=0A+#define ACPI_EINJ_PLATFORM_CO=
RRECTABLE      (1<<9)=0A+#define ACPI_EINJ_PLATFORM_UNCORRECTABLE    =
(1<<10)=0A+#define ACPI_EINJ_PLATFORM_FATAL            (1<<11)=0A =0A =
/**************************************************************************=
*****=0A  *=0A@@ -453,30 +368,237 @@ struct acpi_erst_info {=0A =0A =
/**************************************************************************=
*****=0A  *=0A- * HPET - High Precision Event Timer table=0A+ * HEST - =
Hardware Error Source Table (ACPI 4.0)=0A+ *        Version 1=0A  *=0A  =
***************************************************************************=
***/=0A =0A-struct acpi_table_hpet {=0A+struct acpi_table_hest {=0A 	=
struct acpi_table_header header;	/* Common ACPI table header */=0A-	=
u32 id;			/* Hardware ID of event timer block */=0A-	=
struct acpi_generic_address address;	/* Address of event timer block =
*/=0A-	u8 sequence;		/* HPET sequence number */=0A-	u16 =
minimum_tick;	/* Main counter min tick, periodic mode */=0A+	u32 =
error_source_count;=0A+};=0A+=0A+/* HEST subtable header */=0A+=0A+struct =
acpi_hest_header {=0A+	u16 type;=0A+	u16 source_id;=0A+};=0A+=0A+/* =
Values for Type field above for subtables */=0A+=0A+enum acpi_hest_types =
{=0A+	ACPI_HEST_TYPE_IA32_CHECK =3D 0,=0A+	ACPI_HEST_TYPE_IA32_CORRECT=
ED_CHECK =3D 1,=0A+	ACPI_HEST_TYPE_IA32_NMI =3D 2,=0A+	ACPI_HEST_T=
YPE_NOT_USED3 =3D 3,=0A+	ACPI_HEST_TYPE_NOT_USED4 =3D 4,=0A+	=
ACPI_HEST_TYPE_NOT_USED5 =3D 5,=0A+	ACPI_HEST_TYPE_AER_ROOT_PORT =3D =
6,=0A+	ACPI_HEST_TYPE_AER_ENDPOINT =3D 7,=0A+	ACPI_HEST_TYPE_AER_BRIDGE =
=3D 8,=0A+	ACPI_HEST_TYPE_GENERIC_ERROR =3D 9,=0A+	ACPI_HEST_TYPE_RESE=
RVED =3D 10	/* 10 and greater are reserved */=0A+};=0A+=0A+/*=0A+ * =
HEST substructures contained in subtables=0A+ */=0A+=0A+/*=0A+ * IA32 =
Error Bank(s) - Follows the struct acpi_hest_ia_machine_check and=0A+ * =
struct acpi_hest_ia_corrected structures.=0A+ */=0A+struct acpi_hest_ia_err=
or_bank {=0A+	u8 bank_number;=0A+	u8 clear_status_on_init;=0A+	u8 =
status_format;=0A+	u8 reserved;=0A+	u32 control_register;=0A+	=
u64 control_data;=0A+	u32 status_register;=0A+	u32 address_registe=
r;=0A+	u32 misc_register;=0A+};=0A+=0A+/* Common HEST sub-structure for =
PCI/AER structures below (6,7,8) */=0A+=0A+struct acpi_hest_aer_common =
{=0A+	u16 reserved1;=0A 	u8 flags;=0A+	u8 enabled;=0A+	u32 =
records_to_preallocate;=0A+	u32 max_sections_per_record;=0A+	=
u32 bus;=0A+	u16 device;=0A+	u16 function;=0A+	u16 device_control;=
=0A+	u16 reserved2;=0A+	u32 uncorrectable_mask;=0A+	u32 =
uncorrectable_severity;=0A+	u32 correctable_mask;=0A+	u32 =
advanced_capabilities;=0A };=0A =0A-/*! Flags */=0A+/* Masks for HEST =
Flags fields */=0A+=0A+#define ACPI_HEST_FIRMWARE_FIRST        (1)=0A+#defi=
ne ACPI_HEST_GLOBAL                (1<<1)=0A =0A-#define ACPI_HPET_PAGE_PRO=
TECT      (1)	/* 00: No page protection */=0A-#define ACPI_HPET_PAGE_PROT=
ECT_4    (1<<1)	/* 01: 4KB page protected */=0A-#define ACPI_HPET_PAGE_PROT=
ECT_64   (1<<2)	/* 02: 64KB page protected */=0A+/* Hardware Error =
Notification */=0A =0A-/*! [End] no source code translation !*/=0A+struct =
acpi_hest_notify {=0A+	u8 type;=0A+	u8 length;=0A+	u16 config_write_en=
able;=0A+	u32 poll_interval;=0A+	u32 vector;=0A+	u32 polling_thresho=
ld_value;=0A+	u32 polling_threshold_window;=0A+	u32 error_threshold=
_value;=0A+	u32 error_threshold_window;=0A+};=0A+=0A+/* Values for =
Notify Type field above */=0A+=0A+enum acpi_hest_notify_types {=0A+	=
ACPI_HEST_NOTIFY_POLLED =3D 0,=0A+	ACPI_HEST_NOTIFY_EXTERNAL =3D =
1,=0A+	ACPI_HEST_NOTIFY_LOCAL =3D 2,=0A+	ACPI_HEST_NOTIFY_SCI =3D =
3,=0A+	ACPI_HEST_NOTIFY_NMI =3D 4,=0A+	ACPI_HEST_NOTIFY_RESERVED =3D 5	/* =
5 and greater are reserved */=0A+};=0A+=0A+/* Values for config_write_enabl=
e bitfield above */=0A+=0A+#define ACPI_HEST_TYPE                  =
(1)=0A+#define ACPI_HEST_POLL_INTERVAL         (1<<1)=0A+#define ACPI_HEST_=
POLL_THRESHOLD_VALUE  (1<<2)=0A+#define ACPI_HEST_POLL_THRESHOLD_WINDOW =
(1<<3)=0A+#define ACPI_HEST_ERR_THRESHOLD_VALUE   (1<<4)=0A+#define =
ACPI_HEST_ERR_THRESHOLD_WINDOW  (1<<5)=0A+=0A+/*=0A+ * HEST subtables=0A+ =
*/=0A+=0A+/* 0: IA32 Machine Check Exception */=0A+=0A+struct acpi_hest_ia_=
machine_check {=0A+	struct acpi_hest_header header;=0A+	u16 =
reserved1;=0A+	u8 flags;=0A+	u8 enabled;=0A+	u32 records_to_preallocate;=
=0A+	u32 max_sections_per_record;=0A+	u64 global_capability_data;=
=0A+	u64 global_control_data;=0A+	u8 num_hardware_banks;=0A+	u8 =
reserved3[7];=0A+};=0A+=0A+/* 1: IA32 Corrected Machine Check */=0A+=0A+str=
uct acpi_hest_ia_corrected {=0A+	struct acpi_hest_header header;=0A+=
	u16 reserved1;=0A+	u8 flags;=0A+	u8 enabled;=0A+	u32 =
records_to_preallocate;=0A+	u32 max_sections_per_record;=0A+	=
struct acpi_hest_notify notify;=0A+	u8 num_hardware_banks;=0A+	u8 =
reserved2[3];=0A+};=0A+=0A+/* 2: IA32 Non-Maskable Interrupt */=0A+=0A+stru=
ct acpi_hest_ia_nmi {=0A+	struct acpi_hest_header header;=0A+	=
u32 reserved;=0A+	u32 records_to_preallocate;=0A+	u32 max_sections_pe=
r_record;=0A+	u32 max_raw_data_length;=0A+};=0A+=0A+/* 3,4,5: Not used =
*/=0A+=0A+/* 6: PCI Express Root Port AER */=0A+=0A+struct acpi_hest_aer_ro=
ot {=0A+	struct acpi_hest_header header;=0A+	struct acpi_hest_ae=
r_common aer;=0A+	u32 root_error_command;=0A+};=0A+=0A+/* 7: PCI =
Express AER (AER Endpoint) */=0A+=0A+struct acpi_hest_aer {=0A+	struct =
acpi_hest_header header;=0A+	struct acpi_hest_aer_common aer;=0A+};=0A+=
=0A+/* 8: PCI Express/PCI-X Bridge AER */=0A+=0A+struct acpi_hest_aer_bridg=
e {=0A+	struct acpi_hest_header header;=0A+	struct acpi_hest_aer_common=
 aer;=0A+	u32 uncorrectable_mask2;=0A+	u32 uncorrectable_severity2=
;=0A+	u32 advanced_capabilities2;=0A+};=0A+=0A+/* 9: Generic Hardware =
Error Source */=0A+=0A+struct acpi_hest_generic {=0A+	struct acpi_hest_he=
ader header;=0A+	u16 related_source_id;=0A+	u8 reserved;=0A+	=
u8 enabled;=0A+	u32 records_to_preallocate;=0A+	u32 max_sections_per_record=
;=0A+	u32 max_raw_data_length;=0A+	struct acpi_generic_address =
error_status_address;=0A+	struct acpi_hest_notify notify;=0A+	=
u32 error_block_length;=0A+};=0A+=0A+/* Generic Error Status block =
*/=0A+=0A+struct acpi_hest_generic_status {=0A+	u32 block_status;=0A+	=
u32 raw_data_offset;=0A+	u32 raw_data_length;=0A+	u32 =
data_length;=0A+	u32 error_severity;=0A+};=0A+=0A+/* Values for =
block_status flags above */=0A+=0A+#define ACPI_HEST_UNCORRECTABLE         =
    (1)=0A+#define ACPI_HEST_CORRECTABLE               (1<<1)=0A+#define =
ACPI_HEST_MULTIPLE_UNCORRECTABLE    (1<<2)=0A+#define ACPI_HEST_MULTIPLE_CO=
RRECTABLE      (1<<3)=0A+#define ACPI_HEST_ERROR_ENTRY_COUNT         =
(0xFF<<4)	/* 8 bits, error count */=0A+=0A+/* Generic Error Data =
entry */=0A+=0A+struct acpi_hest_generic_data {=0A+	u8 section_type[16]=
;=0A+	u32 error_severity;=0A+	u16 revision;=0A+	u8 validation_bits;=
=0A+	u8 flags;=0A+	u32 error_data_length;=0A+	u8 fru_id[16];=0A+	=
u8 fru_text[20];=0A+};=0A =0A /********************************************=
***********************************=0A  *=0A  * MADT - Multiple APIC =
Description Table=0A+ *        Version 3=0A  *=0A  ************************=
******************************************************/=0A =0A@@ -486,7 =
+608,7 @@ struct acpi_table_madt {=0A 	u32 flags;=0A };=0A =0A-/* Flags =
*/=0A+/* Masks for Flags field above */=0A =0A #define ACPI_MADT_PCAT_COMPA=
T       (1)	/* 00:    System also has dual 8259s */=0A =0A@@ -495,7 =
+617,7 @@ struct acpi_table_madt {=0A #define ACPI_MADT_DUAL_PIC          =
0=0A #define ACPI_MADT_MULTIPLE_APIC     1=0A =0A-/* Values for subtable =
type in struct acpi_subtable_header */=0A+/* Values for MADT subtable type =
in struct acpi_subtable_header */=0A =0A enum acpi_madt_type {=0A 	=
ACPI_MADT_TYPE_LOCAL_APIC =3D 0,=0A@@ -606,7 +728,7 @@ struct acpi_madt_int=
errupt_source {=0A 	u32 flags;		/* Interrupt Source Flags =
*/=0A };=0A =0A-/* Flags field above */=0A+/* Masks for Flags field above =
*/=0A =0A #define ACPI_MADT_CPEI_OVERRIDE     (1)=0A =0A@@ -615,9 +737,9 =
@@ struct acpi_madt_interrupt_source {=0A struct acpi_madt_local_x2apic =
{=0A 	struct acpi_subtable_header header;=0A 	u16 reserved;		/* =
Reserved - must be zero */=0A-	u32 local_apic_id;	/* Processor =
X2_APIC ID  */=0A+	u32 local_apic_id;	/* Processor x2APIC ID  =
*/=0A 	u32 lapic_flags;=0A-	u32 uid;		/* Extended =
X2_APIC processor ID */=0A+	u32 uid;		/* ACPI processor =
UID */=0A };=0A =0A /* 10: Local X2APIC NMI (ACPI 4.0) */=0A@@ -625,7 =
+747,7 @@ struct acpi_madt_local_x2apic {=0A struct acpi_madt_local_x2apic_=
nmi {=0A 	struct acpi_subtable_header header;=0A 	u16 inti_flags;=0A-=
	u32 uid;		/* Processor X2_APIC ID */=0A+	u32 uid;	=
	/* ACPI processor UID */=0A 	u8 lint;		/* LINTn =
to which NMI is connected */=0A 	u8 reserved[3];=0A };=0A@@ -657,28 =
+779,34 @@ struct acpi_madt_local_x2apic_nmi {=0A =0A /********************=
***********************************************************=0A  *=0A- * =
MCFG - PCI Memory Mapped Configuration table and sub-table=0A+ * MSCT - =
Maximum System Characteristics Table (ACPI 4.0)=0A+ *        Version 1=0A  =
*=0A  *********************************************************************=
*********/=0A =0A-struct acpi_table_mcfg {=0A+struct acpi_table_msct {=0A 	=
struct acpi_table_header header;	/* Common ACPI table header */=0A-	=
u8 reserved[8];=0A+	u32 proximity_offset;	/* Location of proximity =
info struct(s) */=0A+	u32 max_proximity_domains;	/* Max number of =
proximity domains */=0A+	u32 max_clock_domains;	/* Max number of =
clock domains */=0A+	u64 max_address;	/* Max physical address in =
system */=0A };=0A =0A-/* Subtable */=0A+/* Subtable - Maximum Proximity =
Domain Information. Version 1 */=0A =0A-struct acpi_mcfg_allocation {=0A-	=
u64 address;		/* Base address, processor-relative */=0A-	=
u16 pci_segment;	/* PCI segment group number */=0A-	u8 =
start_bus_number;	/* Starting PCI Bus number */=0A-	u8 =
end_bus_number;	/* Final PCI Bus number */=0A-	u32 reserved;=0A+struct =
acpi_msct_proximity {=0A+	u8 revision;=0A+	u8 length;=0A+	=
u32 range_start;	/* Start of domain range */=0A+	u32 range_end;		=
/* End of domain range */=0A+	u32 processor_capacity;=0A+	u64 =
memory_capacity;	/* In bytes */=0A };=0A =0A /**********************=
*********************************************************=0A  *=0A  * SBST =
- Smart Battery Specification Table=0A+ *        Version 1=0A  *=0A  =
***************************************************************************=
***/=0A =0A@@ -692,6 +820,7 @@ struct acpi_table_sbst {=0A /***************=
****************************************************************=0A  *=0A  =
* SLIT - System Locality Distance Information Table=0A+ *        Version =
1=0A  *=0A  ***************************************************************=
***************/=0A =0A@@ -703,60 +832,8 @@ struct acpi_table_slit {=0A =
=0A /**********************************************************************=
*********=0A  *=0A- * SPCR - Serial Port Console Redirection table=0A- =
*=0A- *********************************************************************=
*********/=0A-=0A-struct acpi_table_spcr {=0A-	struct acpi_table_header =
header;	/* Common ACPI table header */=0A-	u8 interface_type;	/* =
0=3Dfull 16550, 1=3Dsubset of 16550 */=0A-	u8 reserved[3];=0A-	=
struct acpi_generic_address serial_port;=0A-	u8 interrupt_type;=0A-	u8 =
pc_interrupt;=0A-	u32 interrupt;=0A-	u8 baud_rate;=0A-	u8 =
parity;=0A-	u8 stop_bits;=0A-	u8 flow_control;=0A-	u8 =
terminal_type;=0A-	u8 reserved1;=0A-	u16 pci_device_id;=0A-	=
u16 pci_vendor_id;=0A-	u8 pci_bus;=0A-	u8 pci_device;=0A-	u8 =
pci_function;=0A-	u32 pci_flags;=0A-	u8 pci_segment;=0A-	=
u32 reserved2;=0A-};=0A-=0A-/**********************************************=
*********************************=0A- *=0A- * SPMI - Server Platform =
Management Interface table=0A- *=0A- **************************************=
****************************************/=0A-=0A-struct acpi_table_spmi =
{=0A-	struct acpi_table_header header;	/* Common ACPI table =
header */=0A-	u8 reserved;=0A-	u8 interface_type;=0A-	u16 =
spec_revision;	/* Version of IPMI */=0A-	u8 interrupt_type;=0A-	u8 =
gpe_number;		/* GPE assigned */=0A-	u8 reserved1;=0A-	u8 =
pci_device_flag;=0A-	u32 interrupt;=0A-	struct acpi_generic_address=
 ipmi_register;=0A-	u8 pci_segment;=0A-	u8 pci_bus;=0A-	u8 =
pci_device;=0A-	u8 pci_function;=0A-};=0A-=0A-/****************************=
***************************************************=0A- *=0A  * SRAT - =
System Resource Affinity Table=0A+ *        Version 3=0A  *=0A  ***********=
*******************************************************************/=0A =
=0A@@ -775,7 +852,9 @@ enum acpi_srat_type {=0A 	ACPI_SRAT_TYPE_RESE=
RVED =3D 3	/* 3 and greater are reserved */=0A };=0A =0A-/* SRAT =
sub-tables */=0A+/*=0A+ * SRAT Sub-tables, correspond to Type in struct =
acpi_subtable_header=0A+ */=0A =0A /* 0: Processor Local APIC/SAPIC =
Affinity */=0A =0A@@ -789,6 +868,10 @@ struct acpi_srat_cpu_affinity {=0A 	=
u32 reserved;		/* Reserved, must be zero */=0A };=0A =0A+/* Flags =
*/=0A+=0A+#define ACPI_SRAT_CPU_USE_AFFINITY  (1)	/* 00: Use =
affinity structure */=0A+=0A /* 1: Memory Affinity */=0A =0A struct =
acpi_srat_mem_affinity {=0A@@ -797,9 +880,9 @@ struct acpi_srat_mem_affinit=
y {=0A 	u16 reserved;		/* Reserved, must be zero */=0A 	=
u64 base_address;=0A 	u64 length;=0A-	u32 memory_type;	/* See =
acpi_address_range_id */=0A+	u32 reserved1;=0A 	u32 flags;=0A-	=
u64 reserved1;		/* Reserved, must be zero */=0A+	u64 =
reserved2;		/* Reserved, must be zero */=0A };=0A =0A /* Flags =
*/=0A@@ -824,44 +907,6 @@ struct acpi_srat_x2apic_cpu_affinity {=0A =0A =
#define ACPI_SRAT_CPU_ENABLED       (1)	/* 00: Use affinity structure =
*/=0A =0A-/****************************************************************=
***************=0A- *=0A- * TCPA - Trusted Computing Platform Alliance =
table=0A- *=0A- ***********************************************************=
*******************/=0A-=0A-struct acpi_table_tcpa {=0A-	struct =
acpi_table_header header;	/* Common ACPI table header */=0A-	=
u16 reserved;=0A-	u32 max_log_length;	/* Maximum length for the =
event log area */=0A-	u64 log_address;	/* Address of the event =
log area */=0A-};=0A-=0A-/*************************************************=
******************************=0A- *=0A- * WDRT - Watchdog Resource =
Table=0A- *=0A- ***********************************************************=
*******************/=0A-=0A-struct acpi_table_wdrt {=0A-	struct =
acpi_table_header header;	/* Common ACPI table header */=0A-	=
u32 header_length;	/* Watchdog Header Length */=0A-	u8 =
pci_segment;		/* PCI Segment number */=0A-	u8 pci_bus;		=
/* PCI Bus number */=0A-	u8 pci_device;		/* PCI Device =
number */=0A-	u8 pci_function;	/* PCI Function number */=0A-	=
u32 timer_period;	/* Period of one timer count (msec) */=0A-	=
u32 max_count;		/* Maximum counter value supported */=0A-	=
u32 min_count;		/* Minimum counter value */=0A-	u8 flags;=0A-	u8 =
reserved[3];=0A-	u32 entries;		/* Number of watchdog =
entries that follow */=0A-};=0A-=0A-/* Flags */=0A-=0A-#define ACPI_WDRT_TI=
MER_ENABLED     (1)	/* 00: Timer enabled */=0A-=0A /* Reset to default =
packing */=0A =0A #pragma pack()=0A--- /dev/null=0A+++ a/xen/include/acpi/a=
ctbl2.h=0A@@ -0,0 +1,1050 @@=0A+/******************************************=
************************************=0A+ *=0A+ * Name: actbl2.h - ACPI =
Table Definitions (tables not in ACPI spec)=0A+ *=0A+ *********************=
********************************************************/=0A+=0A+/*=0A+ * =
Copyright (C) 2000 - 2011, Intel Corp.=0A+ * All rights reserved.=0A+ =
*=0A+ * Redistribution and use in source and binary forms, with or =
without=0A+ * modification, are permitted provided that the following =
conditions=0A+ * are met:=0A+ * 1. Redistributions of source code must =
retain the above copyright=0A+ *    notice, this list of conditions, and =
the following disclaimer,=0A+ *    without modification.=0A+ * 2. =
Redistributions in binary form must reproduce at minimum a disclaimer=0A+ =
*    substantially similar to the "NO WARRANTY" disclaimer below=0A+ *    =
("Disclaimer") and any redistribution must be conditioned upon=0A+ *    =
including a substantially similar Disclaimer requirement for further=0A+ * =
   binary redistribution.=0A+ * 3. Neither the names of the above-listed =
copyright holders nor the names=0A+ *    of any contributors may be used =
to endorse or promote products derived=0A+ *    from this software without =
specific prior written permission.=0A+ *=0A+ * Alternatively, this =
software may be distributed under the terms of the=0A+ * GNU General =
Public License ("GPL") version 2 as published by the Free=0A+ * Software =
Foundation.=0A+ *=0A+ * NO WARRANTY=0A+ * THIS SOFTWARE IS PROVIDED BY THE =
COPYRIGHT HOLDERS AND CONTRIBUTORS=0A+ * "AS IS" AND ANY EXPRESS OR =
IMPLIED WARRANTIES, INCLUDING, BUT NOT=0A+ * LIMITED TO, THE IMPLIED =
WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR=0A+ * A PARTICULAR PURPOSE =
ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT=0A+ * HOLDERS OR CONTRIBUTO=
RS BE LIABLE FOR SPECIAL, EXEMPLARY, OR CONSEQUENTIAL=0A+ * DAMAGES =
(INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS=0A+ * OR =
SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)=0A+ * =
HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,=0A+ * =
STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING=0A+ =
* IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE=0A+ * =
POSSIBILITY OF SUCH DAMAGES.=0A+ */=0A+=0A+#ifndef __ACTBL2_H__=0A+#define =
__ACTBL2_H__=0A+=0A+/******************************************************=
*************************=0A+ *=0A+ * Additional ACPI Tables (2)=0A+ *=0A+ =
* These tables are not consumed directly by the ACPICA subsystem, but =
are=0A+ * included here to support device drivers and the AML disassembler.=
=0A+ *=0A+ * The tables in this file are defined by third-party specificati=
ons, and are=0A+ * not defined directly by the ACPI specification =
itself.=0A+ *=0A+ *********************************************************=
*********************/=0A+=0A+/*=0A+ * Values for description table header =
signatures for tables defined in this=0A+ * file. Useful because they make =
it more difficult to inadvertently type in=0A+ * the wrong signature.=0A+ =
*/=0A+#define ACPI_SIG_ASF            "ASF!"	/* Alert Standard Format =
table */=0A+#define ACPI_SIG_BOOT           "BOOT"	/* Simple Boot =
Flag Table */=0A+#define ACPI_SIG_DBGP           "DBGP"	/* Debug Port =
table */=0A+#define ACPI_SIG_DMAR           "DMAR"	/* DMA Remapping =
table */=0A+#define ACPI_SIG_HPET           "HPET"	/* High Precision =
Event Timer table */=0A+#define ACPI_SIG_IBFT           "IBFT"	/* i_sCSI =
Boot Firmware Table */=0A+#define ACPI_SIG_IVRS           "IVRS"	/* =
I/O Virtualization Reporting Structure */=0A+#define ACPI_SIG_MCFG         =
  "MCFG"	/* PCI Memory Mapped Configuration table */=0A+#define =
ACPI_SIG_MCHI           "MCHI"	/* Management Controller Host Interface =
table */=0A+#define ACPI_SIG_SLIC           "SLIC"	/* Software =
Licensing Description Table */=0A+#define ACPI_SIG_SPCR           "SPCR"	=
/* Serial Port Console Redirection table */=0A+#define ACPI_SIG_SPMI       =
    "SPMI"	/* Server Platform Management Interface table */=0A+#define=
 ACPI_SIG_TCPA           "TCPA"	/* Trusted Computing Platform Alliance =
table */=0A+#define ACPI_SIG_UEFI           "UEFI"	/* Uefi Boot =
Optimization Table */=0A+#define ACPI_SIG_WAET           "WAET"	/* Windows =
ACPI Emulated devices Table */=0A+#define ACPI_SIG_WDAT           "WDAT"	=
/* Watchdog Action Table */=0A+#define ACPI_SIG_WDDT           "WDDT"	/* =
Watchdog Timer Description Table */=0A+#define ACPI_SIG_WDRT           =
"WDRT"	/* Watchdog Resource Table */=0A+=0A+#ifdef ACPI_UNDEFINED_TABLES=
=0A+/*=0A+ * These tables have been seen in the field, but no definition =
has been found=0A+ */=0A+#define ACPI_SIG_ATKG           "ATKG"=0A+#define =
ACPI_SIG_GSCI           "GSCI"	/* GMCH SCI table */=0A+#define ACPI_SIG_IE=
IT           "IEIT"=0A+#endif=0A+=0A+/*=0A+ * All tables must be byte-packe=
d to match the ACPI specification, since=0A+ * the tables are provided by =
the system BIOS.=0A+ */=0A+#pragma pack(1)=0A+=0A+/*=0A+ * Note about =
bitfields: The u8 type is used for bitfields in ACPI tables.=0A+ * This is =
the only type that is even remotely portable. Anything else is not=0A+ * =
portable, so do not use any other bitfield types.=0A+ */=0A+=0A+/**********=
*********************************************************************=0A+ =
*=0A+ * ASF - Alert Standard Format table (Signature "ASF!")=0A+ *       =
Revision 0x10=0A+ *=0A+ * Conforms to the Alert Standard Format Specificati=
on V2.0, 23 April 2003=0A+ *=0A+ ******************************************=
************************************/=0A+=0A+struct acpi_table_asf {=0A+	=
struct acpi_table_header header;	/* Common ACPI table header =
*/=0A+};=0A+=0A+/* ASF subtable header */=0A+=0A+struct acpi_asf_header =
{=0A+	u8 type;=0A+	u8 reserved;=0A+	u16 length;=0A+};=0A+=0A+/*=
 Values for Type field above */=0A+=0A+enum acpi_asf_type {=0A+	ACPI_ASF_TY=
PE_INFO =3D 0,=0A+	ACPI_ASF_TYPE_ALERT =3D 1,=0A+	ACPI_ASF_TYPE_CONTR=
OL =3D 2,=0A+	ACPI_ASF_TYPE_BOOT =3D 3,=0A+	ACPI_ASF_TYPE_ADDRESS =3D =
4,=0A+	ACPI_ASF_TYPE_RESERVED =3D 5=0A+};=0A+=0A+/*=0A+ * ASF subtables=0A=
+ */=0A+=0A+/* 0: ASF Information */=0A+=0A+struct acpi_asf_info {=0A+	=
struct acpi_asf_header header;=0A+	u8 min_reset_value;=0A+	u8 =
min_poll_interval;=0A+	u16 system_id;=0A+	u32 mfg_id;=0A+	u8 =
flags;=0A+	u8 reserved2[3];=0A+};=0A+=0A+/* Masks for Flags field =
above */=0A+=0A+#define ACPI_ASF_SMBUS_PROTOCOLS    (1)=0A+=0A+/* 1: ASF =
Alerts */=0A+=0A+struct acpi_asf_alert {=0A+	struct acpi_asf_header =
header;=0A+	u8 assert_mask;=0A+	u8 deassert_mask;=0A+	u8 =
alerts;=0A+	u8 data_length;=0A+};=0A+=0A+struct acpi_asf_alert_data =
{=0A+	u8 address;=0A+	u8 command;=0A+	u8 mask;=0A+	u8 value;=0A+	u8 =
sensor_type;=0A+	u8 type;=0A+	u8 offset;=0A+	u8 source_type;=0A+=
	u8 severity;=0A+	u8 sensor_number;=0A+	u8 entity;=0A+	u8 =
instance;=0A+};=0A+=0A+/* 2: ASF Remote Control */=0A+=0A+struct acpi_asf_r=
emote {=0A+	struct acpi_asf_header header;=0A+	u8 controls;=0A+	=
u8 data_length;=0A+	u16 reserved2;=0A+};=0A+=0A+struct acpi_asf_control=
_data {=0A+	u8 function;=0A+	u8 address;=0A+	u8 command;=0A+	u8 =
value;=0A+};=0A+=0A+/* 3: ASF RMCP Boot Options */=0A+=0A+struct acpi_asf_r=
mcp {=0A+	struct acpi_asf_header header;=0A+	u8 capabilities[7];=
=0A+	u8 completion_code;=0A+	u32 enterprise_id;=0A+	u8 command;=0A+	=
u16 parameter;=0A+	u16 boot_options;=0A+	u16 oem_parameters;=0A+};=
=0A+=0A+/* 4: ASF Address */=0A+=0A+struct acpi_asf_address {=0A+	=
struct acpi_asf_header header;=0A+	u8 eprom_address;=0A+	u8 =
devices;=0A+};=0A+=0A+/****************************************************=
***************************=0A+ *=0A+ * BOOT - Simple Boot Flag Table=0A+ =
*        Version 1=0A+ *=0A+ * Conforms to the "Simple Boot Flag Specificat=
ion", Version 2.1=0A+ *=0A+ ***********************************************=
*******************************/=0A+=0A+struct acpi_table_boot {=0A+	=
struct acpi_table_header header;	/* Common ACPI table header */=0A+	=
u8 cmos_index;		/* Index in CMOS RAM for the boot register */=0A+	=
u8 reserved[3];=0A+};=0A+=0A+/*********************************************=
**********************************=0A+ *=0A+ * DBGP - Debug Port table=0A+ =
*        Version 1=0A+ *=0A+ * Conforms to the "Debug Port Specification", =
Version 1.00, 2/9/2000=0A+ *=0A+ ******************************************=
************************************/=0A+=0A+struct acpi_table_dbgp {=0A+	=
struct acpi_table_header header;	/* Common ACPI table header */=0A+	=
u8 type;		/* 0=3Dfull 16550, 1=3Dsubset of 16550 */=0A+	u8 =
reserved[3];=0A+	struct acpi_generic_address debug_port;=0A+};=0A+=
=0A+/**********************************************************************=
*********=0A+ *=0A+ * DMAR - DMA Remapping table=0A+ *        Version =
1=0A+ *=0A+ * Conforms to "Intel Virtualization Technology for Directed =
I/O",=0A+ * Version 1.2, Sept. 2008=0A+ *=0A+ *****************************=
*************************************************/=0A+=0A+struct acpi_table=
_dmar {=0A+	struct acpi_table_header header;	/* Common ACPI =
table header */=0A+	u8 width;		/* Host Address Width =
*/=0A+	u8 flags;=0A+	u8 reserved[10];=0A+};=0A+=0A+/* Masks for Flags =
field above */=0A+=0A+#define ACPI_DMAR_INTR_REMAP        (1)=0A+#define =
ACPI_DMAR_X2APIC_OPT_OUT    (1<<1)=0A+=0A+/* DMAR subtable header =
*/=0A+=0A+struct acpi_dmar_header {=0A+	u16 type;=0A+	u16 length;=0A+};=
=0A+=0A+/* Values for subtable type in struct acpi_dmar_header */=0A+=0A+en=
um acpi_dmar_type {=0A+	ACPI_DMAR_TYPE_HARDWARE_UNIT =3D 0,=0A+	ACPI_DMAR_T=
YPE_RESERVED_MEMORY =3D 1,=0A+	ACPI_DMAR_TYPE_ATSR =3D 2,=0A+	ACPI_DMAR_H=
ARDWARE_AFFINITY =3D 3,=0A+	ACPI_DMAR_TYPE_RESERVED =3D 4	/* 4 and =
greater are reserved */=0A+};=0A+=0A+/* DMAR Device Scope structure =
*/=0A+=0A+struct acpi_dmar_device_scope {=0A+	u8 entry_type;=0A+	u8 =
length;=0A+	u16 reserved;=0A+	u8 enumeration_id;=0A+	u8 =
bus;=0A+};=0A+=0A+/* Values for entry_type in struct acpi_dmar_device_scope=
 */=0A+=0A+enum acpi_dmar_scope_type {=0A+	ACPI_DMAR_SCOPE_TYPE_NOT_US=
ED =3D 0,=0A+	ACPI_DMAR_SCOPE_TYPE_ENDPOINT =3D 1,=0A+	ACPI_DMAR_S=
COPE_TYPE_BRIDGE =3D 2,=0A+	ACPI_DMAR_SCOPE_TYPE_IOAPIC =3D 3,=0A+	=
ACPI_DMAR_SCOPE_TYPE_HPET =3D 4,=0A+	ACPI_DMAR_SCOPE_TYPE_RESERVED =3D =
5	/* 5 and greater are reserved */=0A+};=0A+=0A+struct acpi_dmar_pci_=
path {=0A+	u8 dev;=0A+	u8 fn;=0A+};=0A+=0A+/*=0A+ * DMAR =
Sub-tables, correspond to Type in struct acpi_dmar_header=0A+ */=0A+=0A+/* =
0: Hardware Unit Definition */=0A+=0A+struct acpi_dmar_hardware_unit {=0A+	=
struct acpi_dmar_header header;=0A+	u8 flags;=0A+	u8 reserved;=0A+	=
u16 segment;=0A+	u64 address;		/* Register Base Address =
*/=0A+};=0A+=0A+/* Masks for Flags field above */=0A+=0A+#define ACPI_DMAR_=
INCLUDE_ALL       (1)=0A+=0A+/* 1: Reserved Memory Defininition */=0A+=0A+s=
truct acpi_dmar_reserved_memory {=0A+	struct acpi_dmar_header header;=0A+=
	u16 reserved;=0A+	u16 segment;=0A+	u64 base_address;	=
/* 4_k aligned base address */=0A+	u64 end_address;	/* 4_k =
aligned limit address */=0A+};=0A+=0A+/* Masks for Flags field above =
*/=0A+=0A+#define ACPI_DMAR_ALLOW_ALL         (1)=0A+=0A+/* 2: Root Port =
ATS Capability Reporting Structure */=0A+=0A+struct acpi_dmar_atsr {=0A+	=
struct acpi_dmar_header header;=0A+	u8 flags;=0A+	u8 reserved;=0A+	=
u16 segment;=0A+};=0A+=0A+/* Masks for Flags field above */=0A+=0A+#define =
ACPI_DMAR_ALL_PORTS         (1)=0A+=0A+/* 3: Remapping Hardware Static =
Affinity Structure */=0A+=0A+struct acpi_dmar_rhsa {=0A+	struct =
acpi_dmar_header header;=0A+	u32 reserved;=0A+	u64 base_address;=
=0A+	u32 proximity_domain;=0A+};=0A+=0A+/*******************************=
************************************************=0A+ *=0A+ * HPET - High =
Precision Event Timer table=0A+ *        Version 1=0A+ *=0A+ * Conforms to =
"IA-PC HPET (High Precision Event Timers) Specification",=0A+ * Version =
1.0a, October 2004=0A+ *=0A+ **********************************************=
********************************/=0A+=0A+struct acpi_table_hpet {=0A+	=
struct acpi_table_header header;	/* Common ACPI table header */=0A+	=
u32 id;			/* Hardware ID of event timer block */=0A+	=
struct acpi_generic_address address;	/* Address of event timer block =
*/=0A+	u8 sequence;		/* HPET sequence number */=0A+	u16 =
minimum_tick;	/* Main counter min tick, periodic mode */=0A+	u8 =
flags;=0A+};=0A+=0A+/* Masks for Flags field above */=0A+=0A+#define =
ACPI_HPET_PAGE_PROTECT_MASK (3)=0A+=0A+/* Values for Page Protect flags =
*/=0A+=0A+enum acpi_hpet_page_protect {=0A+	ACPI_HPET_NO_PAGE_PROTECT =
=3D 0,=0A+	ACPI_HPET_PAGE_PROTECT4 =3D 1,=0A+	ACPI_HPET_PAGE_PROT=
ECT64 =3D 2=0A+};=0A+=0A+/*************************************************=
******************************=0A+ *=0A+ * IBFT - Boot Firmware Table=0A+ =
*        Version 1=0A+ *=0A+ * Conforms to "iSCSI Boot Firmware Table =
(iBFT) as Defined in ACPI 3.0b=0A+ * Specification", Version 1.01, March =
1, 2007=0A+ *=0A+ * Note: It appears that this table is not intended to =
appear in the RSDT/XSDT.=0A+ * Therefore, it is not currently supported by =
the disassembler.=0A+ *=0A+ ***********************************************=
*******************************/=0A+=0A+struct acpi_table_ibft {=0A+	=
struct acpi_table_header header;	/* Common ACPI table header */=0A+	=
u8 reserved[12];=0A+};=0A+=0A+/* IBFT common subtable header */=0A+=0A+stru=
ct acpi_ibft_header {=0A+	u8 type;=0A+	u8 version;=0A+	u16 =
length;=0A+	u8 index;=0A+	u8 flags;=0A+};=0A+=0A+/* Values for Type =
field above */=0A+=0A+enum acpi_ibft_type {=0A+	ACPI_IBFT_TYPE_NOT_USED =
=3D 0,=0A+	ACPI_IBFT_TYPE_CONTROL =3D 1,=0A+	ACPI_IBFT_TYPE_INIT=
IATOR =3D 2,=0A+	ACPI_IBFT_TYPE_NIC =3D 3,=0A+	ACPI_IBFT_TYPE_TARG=
ET =3D 4,=0A+	ACPI_IBFT_TYPE_EXTENSIONS =3D 5,=0A+	ACPI_IBFT_TYPE_RESE=
RVED =3D 6	/* 6 and greater are reserved */=0A+};=0A+=0A+/* IBFT =
subtables */=0A+=0A+struct acpi_ibft_control {=0A+	struct acpi_ibft_he=
ader header;=0A+	u16 extensions;=0A+	u16 initiator_offset;=0A+	=
u16 nic0_offset;=0A+	u16 target0_offset;=0A+	u16 nic1_offset;=0A+	=
u16 target1_offset;=0A+};=0A+=0A+struct acpi_ibft_initiator {=0A+	=
struct acpi_ibft_header header;=0A+	u8 sns_server[16];=0A+	u8 =
slp_server[16];=0A+	u8 primary_server[16];=0A+	u8 secondary_server=
[16];=0A+	u16 name_length;=0A+	u16 name_offset;=0A+};=0A+=0A+struc=
t acpi_ibft_nic {=0A+	struct acpi_ibft_header header;=0A+	u8 =
ip_address[16];=0A+	u8 subnet_mask_prefix;=0A+	u8 origin;=0A+	u8 =
gateway[16];=0A+	u8 primary_dns[16];=0A+	u8 secondary_dns[16];=0A+	=
u8 dhcp[16];=0A+	u16 vlan;=0A+	u8 mac_address[6];=0A+	u16 =
pci_address;=0A+	u16 name_length;=0A+	u16 name_offset;=0A+};=0A+=
=0A+struct acpi_ibft_target {=0A+	struct acpi_ibft_header header;=0A+=
	u8 target_ip_address[16];=0A+	u16 target_ip_socket;=0A+	u8 =
target_boot_lun[8];=0A+	u8 chap_type;=0A+	u8 nic_association;=0A+	=
u16 target_name_length;=0A+	u16 target_name_offset;=0A+	u16 =
chap_name_length;=0A+	u16 chap_name_offset;=0A+	u16 chap_secret_len=
gth;=0A+	u16 chap_secret_offset;=0A+	u16 reverse_chap_name_lengt=
h;=0A+	u16 reverse_chap_name_offset;=0A+	u16 reverse_chap_secret_len=
gth;=0A+	u16 reverse_chap_secret_offset;=0A+};=0A+=0A+/*************=
******************************************************************=0A+ =
*=0A+ * IVRS - I/O Virtualization Reporting Structure=0A+ *        Version =
1=0A+ *=0A+ * Conforms to "AMD I/O Virtualization Technology (IOMMU) =
Specification",=0A+ * Revision 1.26, February 2009.=0A+ *=0A+ *************=
*****************************************************************/=0A+=0A+s=
truct acpi_table_ivrs {=0A+	struct acpi_table_header header;	/* =
Common ACPI table header */=0A+	u32 info;		/* Common =
virtualization info */=0A+	u64 reserved;=0A+};=0A+=0A+/* Values for =
Info field above */=0A+=0A+#define ACPI_IVRS_PHYSICAL_SIZE     0x00007F00	=
/* 7 bits, physical address size */=0A+#define ACPI_IVRS_VIRTUAL_SIZE      =
0x003F8000	/* 7 bits, virtual address size */=0A+#define ACPI_IVRS_ATS=
_RESERVED      0x00400000	/* ATS address translation range reserved =
*/=0A+=0A+/* IVRS subtable header */=0A+=0A+struct acpi_ivrs_header {=0A+	=
u8 type;		/* Subtable type */=0A+	u8 flags;=0A+	u16 =
length;		/* Subtable length */=0A+	u16 device_id;		/* =
ID of IOMMU */=0A+};=0A+=0A+/* Values for subtable Type above */=0A+=0A+enu=
m acpi_ivrs_type {=0A+	ACPI_IVRS_TYPE_HARDWARE =3D 0x10,=0A+	ACPI_IVRS_T=
YPE_MEMORY_ALL /* _MEMORY1 */ =3D 0x20,=0A+	ACPI_IVRS_TYPE_MEMORY_ONE =
/* _MEMORY2 */ =3D 0x21,=0A+	ACPI_IVRS_TYPE_MEMORY_RANGE /* _MEMORY3 */ =
=3D 0x22,=0A+	ACPI_IVRS_TYPE_MEMORY_IOMMU =3D 0x23=0A+};=0A+=0A+/* Masks =
for Flags field above for IVHD subtable */=0A+=0A+#define ACPI_IVHD_TT_ENAB=
LE         (1)=0A+#define ACPI_IVHD_PASS_PW           (1<<1)=0A+#define =
ACPI_IVHD_RES_PASS_PW       (1<<2)=0A+#define ACPI_IVHD_ISOC              =
(1<<3)=0A+#define ACPI_IVHD_IOTLB             (1<<4)=0A+=0A+/* Masks for =
Flags field above for IVMD subtable */=0A+=0A+#define ACPI_IVMD_UNITY      =
       (1)=0A+#define ACPI_IVMD_READ              (1<<1)=0A+#define =
ACPI_IVMD_WRITE             (1<<2)=0A+#define ACPI_IVMD_EXCLUSION_RANGE   =
(1<<3)=0A+=0A+/*=0A+ * IVRS subtables, correspond to Type in struct =
acpi_ivrs_header=0A+ */=0A+=0A+/* 0x10: I/O Virtualization Hardware =
Definition Block (IVHD) */=0A+=0A+struct acpi_ivrs_hardware {=0A+	=
struct acpi_ivrs_header header;=0A+	u16 capability_offset;	/* Offset =
for IOMMU control fields */=0A+	u64 base_address;	/* IOMMU control =
registers */=0A+	u16 pci_segment_group;=0A+	u16 info;		=
/* MSI number and unit ID */=0A+	u32 reserved;=0A+};=0A+=0A+/* =
Masks for Info field above */=0A+=0A+#define ACPI_IVHD_MSI_NUMBER_MASK   =
0x001F	/* 5 bits, MSI message number */=0A+#define ACPI_IVHD_UNIT_ID_MASK =
     0x1F00	/* 5 bits, unit_iD */=0A+=0A+/*=0A+ * Device Entries for =
IVHD subtable, appear after struct acpi_ivrs_hardware structure.=0A+ * =
Upper two bits of the Type field are the (encoded) length of the structure.=
=0A+ * Currently, only 4 and 8 byte entries are defined. 16 and 32 byte =
entries=0A+ * are reserved for future use but not defined.=0A+ */=0A+struct=
 acpi_ivrs_de_header {=0A+	u8 type;=0A+	u16 id;=0A+	u8 =
data_setting;=0A+};=0A+=0A+/* Length of device entry is in the top two =
bits of Type field above */=0A+=0A+#define ACPI_IVHD_ENTRY_LENGTH      =
0xC0=0A+=0A+/* Values for device entry Type field above */=0A+=0A+enum =
acpi_ivrs_device_entry_type {=0A+	/* 4-byte device entries, all use =
struct acpi_ivrs_device4 */=0A+=0A+	ACPI_IVRS_TYPE_PAD4 =3D 0,=0A+	=
ACPI_IVRS_TYPE_ALL =3D 1,=0A+	ACPI_IVRS_TYPE_SELECT =3D 2,=0A+	=
ACPI_IVRS_TYPE_START =3D 3,=0A+	ACPI_IVRS_TYPE_END =3D 4,=0A+=0A+	/* =
8-byte device entries */=0A+=0A+	ACPI_IVRS_TYPE_PAD8 =3D 64,=0A+	=
ACPI_IVRS_TYPE_NOT_USED =3D 65,=0A+	ACPI_IVRS_TYPE_ALIAS_SELECT =3D =
66,	/* Uses struct acpi_ivrs_device8a */=0A+	ACPI_IVRS_TYPE_ALIA=
S_START =3D 67,	/* Uses struct acpi_ivrs_device8a */=0A+	ACPI_IVRS_T=
YPE_EXT_SELECT =3D 70,	/* Uses struct acpi_ivrs_device8b */=0A+	=
ACPI_IVRS_TYPE_EXT_START =3D 71,	/* Uses struct acpi_ivrs_device8b =
*/=0A+	ACPI_IVRS_TYPE_SPECIAL =3D 72	/* Uses struct acpi_ivrs_device8c =
*/=0A+};=0A+=0A+/* Values for Data field above */=0A+=0A+#define ACPI_IVHD_=
INIT_PASS         (1)=0A+#define ACPI_IVHD_EINT_PASS         (1<<1)=0A+#def=
ine ACPI_IVHD_NMI_PASS          (1<<2)=0A+#define ACPI_IVHD_SYSTEM_MGMT    =
   (3<<4)=0A+#define ACPI_IVHD_LINT0_PASS        (1<<6)=0A+#define =
ACPI_IVHD_LINT1_PASS        (1<<7)=0A+=0A+/* Types 0-4: 4-byte device =
entry */=0A+=0A+struct acpi_ivrs_device4 {=0A+	struct acpi_ivrs_de_header =
header;=0A+};=0A+=0A+/* Types 66-67: 8-byte device entry */=0A+=0A+struct =
acpi_ivrs_device8a {=0A+	struct acpi_ivrs_de_header header;=0A+	u8 =
reserved1;=0A+	u16 used_id;=0A+	u8 reserved2;=0A+};=0A+=0A+/* =
Types 70-71: 8-byte device entry */=0A+=0A+struct acpi_ivrs_device8b {=0A+	=
struct acpi_ivrs_de_header header;=0A+	u32 extended_data;=0A+};=0A+=0A+/* =
Values for extended_data above */=0A+=0A+#define ACPI_IVHD_ATS_DISABLED    =
  (1<<31)=0A+=0A+/* Type 72: 8-byte device entry */=0A+=0A+struct =
acpi_ivrs_device8c {=0A+	struct acpi_ivrs_de_header header;=0A+	u8 =
handle;=0A+	u16 used_id;=0A+	u8 variety;=0A+};=0A+=0A+/* Values =
for Variety field above */=0A+=0A+#define ACPI_IVHD_IOAPIC            =
1=0A+#define ACPI_IVHD_HPET              2=0A+=0A+/* 0x20, 0x21, 0x22: I/O =
Virtualization Memory Definition Block (IVMD) */=0A+=0A+struct acpi_ivrs_me=
mory {=0A+	struct acpi_ivrs_header header;=0A+	u16 aux_data;=0A+	=
u64 reserved;=0A+	u64 start_address;=0A+	u64 memory_length;=0A+};=0A=
+=0A+/*********************************************************************=
**********=0A+ *=0A+ * MCFG - PCI Memory Mapped Configuration table and =
sub-table=0A+ *        Version 1=0A+ *=0A+ * Conforms to "PCI Firmware =
Specification", Revision 3.0, June 20, 2005=0A+ *=0A+ *********************=
*********************************************************/=0A+=0A+struct =
acpi_table_mcfg {=0A+	struct acpi_table_header header;	/* Common =
ACPI table header */=0A+	u8 reserved[8];=0A+};=0A+=0A+/* Subtable =
*/=0A+=0A+struct acpi_mcfg_allocation {=0A+	u64 address;		/* =
Base address, processor-relative */=0A+	u16 pci_segment;	/* PCI =
segment group number */=0A+	u8 start_bus_number;	/* Starting PCI =
Bus number */=0A+	u8 end_bus_number;	/* Final PCI Bus number =
*/=0A+	u32 reserved;=0A+};=0A+=0A+/***************************************=
****************************************=0A+ *=0A+ * MCHI - Management =
Controller Host Interface Table=0A+ *        Version 1=0A+ *=0A+ * =
Conforms to "Management Component Transport Protocol (MCTP) Host=0A+ * =
Interface Specification", Revision 1.0.0a, October 13, 2009=0A+ *=0A+ =
***************************************************************************=
***/=0A+=0A+struct acpi_table_mchi {=0A+	struct acpi_table_header =
header;	/* Common ACPI table header */=0A+	u8 interface_type;=0A+	u8 =
protocol;=0A+	u64 protocol_data;=0A+	u8 interrupt_type;=0A+	u8 =
gpe;=0A+	u8 pci_device_flag;=0A+	u32 global_interrupt;=0A+	=
struct acpi_generic_address control_register;=0A+	u8 pci_segment;=0A+=
	u8 pci_bus;=0A+	u8 pci_device;=0A+	u8 pci_function;=0A+};=0A+=
=0A+/**********************************************************************=
*********=0A+ *=0A+ * SLIC - Software Licensing Description Table=0A+ *    =
    Version 1=0A+ *=0A+ * Conforms to "OEM Activation 2.0 for Windows =
Vista Operating Systems",=0A+ * Copyright 2006=0A+ *=0A+ ******************=
************************************************************/=0A+=0A+/* =
Basic SLIC table is only the common ACPI header */=0A+=0A+struct acpi_table=
_slic {=0A+	struct acpi_table_header header;	/* Common ACPI =
table header */=0A+};=0A+=0A+/* Common SLIC subtable header */=0A+=0A+struc=
t acpi_slic_header {=0A+	u32 type;=0A+	u32 length;=0A+};=0A+=0A+/*=
 Values for Type field above */=0A+=0A+enum acpi_slic_type {=0A+	=
ACPI_SLIC_TYPE_PUBLIC_KEY =3D 0,=0A+	ACPI_SLIC_TYPE_WINDOWS_MARKER =3D =
1,=0A+	ACPI_SLIC_TYPE_RESERVED =3D 2	/* 2 and greater are reserved =
*/=0A+};=0A+=0A+/*=0A+ * SLIC Sub-tables, correspond to Type in struct =
acpi_slic_header=0A+ */=0A+=0A+/* 0: Public Key Structure */=0A+=0A+struct =
acpi_slic_key {=0A+	struct acpi_slic_header header;=0A+	u8 =
key_type;=0A+	u8 version;=0A+	u16 reserved;=0A+	u32 algorithm;=0A+	=
char magic[4];=0A+	u32 bit_length;=0A+	u32 exponent;=0A+	u8 =
modulus[128];=0A+};=0A+=0A+/* 1: Windows Marker Structure */=0A+=0A+struct =
acpi_slic_marker {=0A+	struct acpi_slic_header header;=0A+	u32 =
version;=0A+	char oem_id[ACPI_OEM_ID_SIZE];	/* ASCII OEM identification=
 */=0A+	char oem_table_id[ACPI_OEM_TABLE_ID_SIZE];	/* ASCII OEM table =
identification */=0A+	char windows_flag[8];=0A+	u32 slic_version;=
=0A+	u8 reserved[16];=0A+	u8 signature[128];=0A+};=0A+=0A+/**********=
*********************************************************************=0A+ =
*=0A+ * SPCR - Serial Port Console Redirection table=0A+ *        Version =
1=0A+ *=0A+ * Conforms to "Serial Port Console Redirection Table",=0A+ * =
Version 1.00, January 11, 2002=0A+ *=0A+ **********************************=
********************************************/=0A+=0A+struct acpi_table_spcr=
 {=0A+	struct acpi_table_header header;	/* Common ACPI table =
header */=0A+	u8 interface_type;	/* 0=3Dfull 16550, 1=3Dsubset of =
16550 */=0A+	u8 reserved[3];=0A+	struct acpi_generic_address =
serial_port;=0A+	u8 interrupt_type;=0A+	u8 pc_interrupt;=0A+	=
u32 interrupt;=0A+	u8 baud_rate;=0A+	u8 parity;=0A+	u8 =
stop_bits;=0A+	u8 flow_control;=0A+	u8 terminal_type;=0A+	u8 =
reserved1;=0A+	u16 pci_device_id;=0A+	u16 pci_vendor_id;=0A+	u8 =
pci_bus;=0A+	u8 pci_device;=0A+	u8 pci_function;=0A+	u32 =
pci_flags;=0A+	u8 pci_segment;=0A+	u32 reserved2;=0A+};=0A+=0A+/* =
Masks for pci_flags field above */=0A+=0A+#define ACPI_SPCR_DO_NOT_DISABLE =
   (1)=0A+=0A+/************************************************************=
*******************=0A+ *=0A+ * SPMI - Server Platform Management =
Interface table=0A+ *        Version 5=0A+ *=0A+ * Conforms to "Intelligent=
 Platform Management Interface Specification=0A+ * Second Generation =
v2.0", Document Revision 1.0, February 12, 2004 with=0A+ * June 12, 2009 =
markup.=0A+ *=0A+ *********************************************************=
*********************/=0A+=0A+struct acpi_table_spmi {=0A+	struct =
acpi_table_header header;	/* Common ACPI table header */=0A+	u8 =
interface_type;=0A+	u8 reserved;		/* Must be 1 */=0A+	=
u16 spec_revision;	/* Version of IPMI */=0A+	u8 interrupt_type;=
=0A+	u8 gpe_number;		/* GPE assigned */=0A+	u8 reserved1;=0A+	=
u8 pci_device_flag;=0A+	u32 interrupt;=0A+	struct acpi_generic_address=
 ipmi_register;=0A+	u8 pci_segment;=0A+	u8 pci_bus;=0A+	u8 =
pci_device;=0A+	u8 pci_function;=0A+	u8 reserved2;=0A+};=0A+=0A+/* =
Values for interface_type above */=0A+=0A+enum acpi_spmi_interface_types =
{=0A+	ACPI_SPMI_NOT_USED =3D 0,=0A+	ACPI_SPMI_KEYBOARD =3D 1,=0A+	=
ACPI_SPMI_SMI =3D 2,=0A+	ACPI_SPMI_BLOCK_TRANSFER =3D 3,=0A+	=
ACPI_SPMI_SMBUS =3D 4,=0A+	ACPI_SPMI_RESERVED =3D 5	/* 5 and =
above are reserved */=0A+};=0A+=0A+/***************************************=
****************************************=0A+ *=0A+ * TCPA - Trusted =
Computing Platform Alliance table=0A+ *        Version 1=0A+ *=0A+ * =
Conforms to "TCG PC Specific Implementation Specification",=0A+ * Version =
1.1, August 18, 2003=0A+ *=0A+ ********************************************=
**********************************/=0A+=0A+struct acpi_table_tcpa {=0A+	=
struct acpi_table_header header;	/* Common ACPI table header */=0A+	=
u16 reserved;=0A+	u32 max_log_length;	/* Maximum length for the =
event log area */=0A+	u64 log_address;	/* Address of the event =
log area */=0A+};=0A+=0A+/*************************************************=
******************************=0A+ *=0A+ * UEFI - UEFI Boot optimization =
Table=0A+ *        Version 1=0A+ *=0A+ * Conforms to "Unified Extensible =
Firmware Interface Specification",=0A+ * Version 2.3, May 8, 2009=0A+ =
*=0A+ *********************************************************************=
*********/=0A+=0A+struct acpi_table_uefi {=0A+	struct acpi_table_header =
header;	/* Common ACPI table header */=0A+	u8 identifier[16];	/* =
UUID identifier */=0A+	u16 data_offset;	/* Offset of remaining =
data in table */=0A+};=0A+=0A+/********************************************=
***********************************=0A+ *=0A+ * WAET - Windows ACPI =
Emulated devices Table=0A+ *        Version 1=0A+ *=0A+ * Conforms to =
"Windows ACPI Emulated Devices Table", version 1.0, April 6, 2009=0A+ =
*=0A+ *********************************************************************=
*********/=0A+=0A+struct acpi_table_waet {=0A+	struct acpi_table_header =
header;	/* Common ACPI table header */=0A+	u32 flags;=0A+};=0A+=0A+/* =
Masks for Flags field above */=0A+=0A+#define ACPI_WAET_RTC_NO_ACK        =
(1)	/* RTC requires no int acknowledge */=0A+#define ACPI_WAET_TIMER_ON=
E_READ    (1<<1)	/* PM timer requires only one read */=0A+=0A+/*****=
**************************************************************************=
=0A+ *=0A+ * WDAT - Watchdog Action Table=0A+ *        Version 1=0A+ *=0A+ =
* Conforms to "Hardware Watchdog Timers Design Specification",=0A+ * =
Copyright 2006 Microsoft Corporation.=0A+ *=0A+ ***************************=
***************************************************/=0A+=0A+struct =
acpi_table_wdat {=0A+	struct acpi_table_header header;	/* Common =
ACPI table header */=0A+	u32 header_length;	/* Watchdog Header =
Length */=0A+	u16 pci_segment;	/* PCI Segment number */=0A+	u8 =
pci_bus;		/* PCI Bus number */=0A+	u8 pci_device;		=
/* PCI Device number */=0A+	u8 pci_function;	/* PCI Function =
number */=0A+	u8 reserved[3];=0A+	u32 timer_period;	/* Period =
of one timer count (msec) */=0A+	u32 max_count;		/* Maximum =
counter value supported */=0A+	u32 min_count;		/* Minimum counter =
value */=0A+	u8 flags;=0A+	u8 reserved2[3];=0A+	u32 entries;		=
/* Number of watchdog entries that follow */=0A+};=0A+=0A+/* Masks for =
Flags field above */=0A+=0A+#define ACPI_WDAT_ENABLED           (1)=0A+#def=
ine ACPI_WDAT_STOPPED           0x80=0A+=0A+/* WDAT Instruction Entries =
(actions) */=0A+=0A+struct acpi_wdat_entry {=0A+	u8 action;=0A+	u8 =
instruction;=0A+	u16 reserved;=0A+	struct acpi_generic_address=
 register_region;=0A+	u32 value;		/* Value used with =
Read/Write register */=0A+	u32 mask;		/* Bitmask =
required for this register instruction */=0A+};=0A+=0A+/* Values for =
Action field above */=0A+=0A+enum acpi_wdat_actions {=0A+	ACPI_WDAT_R=
ESET =3D 1,=0A+	ACPI_WDAT_GET_CURRENT_COUNTDOWN =3D 4,=0A+	ACPI_WDAT_G=
ET_COUNTDOWN =3D 5,=0A+	ACPI_WDAT_SET_COUNTDOWN =3D 6,=0A+	ACPI_WDAT_G=
ET_RUNNING_STATE =3D 8,=0A+	ACPI_WDAT_SET_RUNNING_STATE =3D 9,=0A+	=
ACPI_WDAT_GET_STOPPED_STATE =3D 10,=0A+	ACPI_WDAT_SET_STOPPED_STATE =3D =
11,=0A+	ACPI_WDAT_GET_REBOOT =3D 16,=0A+	ACPI_WDAT_SET_REBOOT =3D =
17,=0A+	ACPI_WDAT_GET_SHUTDOWN =3D 18,=0A+	ACPI_WDAT_SET_SHUTDOWN =3D =
19,=0A+	ACPI_WDAT_GET_STATUS =3D 32,=0A+	ACPI_WDAT_SET_STATUS =3D =
33,=0A+	ACPI_WDAT_ACTION_RESERVED =3D 34	/* 34 and greater are =
reserved */=0A+};=0A+=0A+/* Values for Instruction field above */=0A+=0A+en=
um acpi_wdat_instructions {=0A+	ACPI_WDAT_READ_VALUE =3D 0,=0A+	ACPI_WDAT_R=
EAD_COUNTDOWN =3D 1,=0A+	ACPI_WDAT_WRITE_VALUE =3D 2,=0A+	=
ACPI_WDAT_WRITE_COUNTDOWN =3D 3,=0A+	ACPI_WDAT_INSTRUCTION_RESERVED =3D =
4,	/* 4 and greater are reserved */=0A+	ACPI_WDAT_PRESERVE_REGISTER=
 =3D 0x80	/* Except for this value */=0A+};=0A+=0A+/*****************=
**************************************************************=0A+ *=0A+ * =
WDDT - Watchdog Descriptor Table=0A+ *        Version 1=0A+ *=0A+ * =
Conforms to "Using the Intel ICH Family Watchdog Timer (WDT)",=0A+ * =
Version 001, September 2002=0A+ *=0A+ *************************************=
*****************************************/=0A+=0A+struct acpi_table_wddt =
{=0A+	struct acpi_table_header header;	/* Common ACPI table =
header */=0A+	u16 spec_version;=0A+	u16 table_version;=0A+	u16 =
pci_vendor_id;=0A+	struct acpi_generic_address address;=0A+	=
u16 max_count;		/* Maximum counter value supported */=0A+	=
u16 min_count;		/* Minimum counter value supported */=0A+	=
u16 period;=0A+	u16 status;=0A+	u16 capability;=0A+};=0A+=0A+/* Flags for =
Status field above */=0A+=0A+#define ACPI_WDDT_AVAILABLE     (1)=0A+#define=
 ACPI_WDDT_ACTIVE        (1<<1)=0A+#define ACPI_WDDT_TCO_OS_OWNED  =
(1<<2)=0A+#define ACPI_WDDT_USER_RESET    (1<<11)=0A+#define ACPI_WDDT_WDT_=
RESET     (1<<12)=0A+#define ACPI_WDDT_POWER_FAIL    (1<<13)=0A+#define =
ACPI_WDDT_UNKNOWN_RESET (1<<14)=0A+=0A+/* Flags for Capability field above =
*/=0A+=0A+#define ACPI_WDDT_AUTO_RESET    (1)=0A+#define ACPI_WDDT_ALERT_SU=
PPORT (1<<1)=0A+=0A+/******************************************************=
*************************=0A+ *=0A+ * WDRT - Watchdog Resource Table=0A+ * =
       Version 1=0A+ *=0A+ * Conforms to "Watchdog Timer Hardware =
Requirements for Windows Server 2003",=0A+ * Version 1.01, August 28, =
2006=0A+ *=0A+ ************************************************************=
******************/=0A+=0A+struct acpi_table_wdrt {=0A+	struct acpi_table_h=
eader header;	/* Common ACPI table header */=0A+	struct acpi_generic=
_address control_register;=0A+	struct acpi_generic_address count_register;=
=0A+	u16 pci_device_id;=0A+	u16 pci_vendor_id;=0A+	u8 pci_bus;		=
/* PCI Bus number */=0A+	u8 pci_device;		/* PCI Device =
number */=0A+	u8 pci_function;	/* PCI Function number */=0A+	u8 =
pci_segment;		/* PCI Segment number */=0A+	u16 max_count;		=
/* Maximum counter value supported */=0A+	u8 units;=0A+};=0A+=0A+/* =
Reset to default packing */=0A+=0A+#pragma pack()=0A+=0A+#endif			=
	/* __ACTBL2_H__ */=0A
--=__Part96B93371.0__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--=__Part96B93371.0__=--


From xen-devel-bounces@lists.xensource.com Mon Dec 12 16:11:11 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 16:11:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ra8Sv-0003a8-IS; Mon, 12 Dec 2011 16:10:57 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Ra8St-0003Yo-75
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 16:10:55 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1323706200!1632406!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6165 invoked from network); 12 Dec 2011 16:10:00 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-5.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 12 Dec 2011 16:10:00 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 12 Dec 2011 16:10:00 +0000
Message-Id: <4EE6359F0200007800067064@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 12 Dec 2011 16:10:55 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part7857DD9F.1__="
Cc: Allen M Kay <allen.m.kay@intel.com>
Subject: [Xen-devel] [PATCH 3/4] ACPI: eliminate duplicate DMAR definitions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__Part7857DD9F.1__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Use their proper counterparts in include/acpi/actbl*.h instead.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/drivers/passthrough/vtd/dmar.c
+++ b/xen/drivers/passthrough/vtd/dmar.c
@@ -38,8 +38,8 @@
 #define PREFIX VTDPREFIX "ACPI DMAR:"
 #define DEBUG
=20
-#define MIN_SCOPE_LEN (sizeof(struct acpi_pci_path) + \
-                       sizeof(struct acpi_dev_scope))
+#define MIN_SCOPE_LEN (sizeof(struct acpi_dmar_device_scope) + \
+                       sizeof(struct acpi_dmar_pci_path))
=20
 LIST_HEAD_READ_MOSTLY(acpi_drhd_units);
 LIST_HEAD_READ_MOSTLY(acpi_rmrr_units);
@@ -247,25 +247,25 @@ int is_igd_drhd(struct acpi_drhd_unit *d
  * Count number of devices in device scope.  Do not include PCI sub
  * hierarchies.
  */
-static int scope_device_count(void *start, void *end)
+static int __init scope_device_count(const void *start, const void *end)
 {
-    struct acpi_dev_scope *scope;
+    const struct acpi_dmar_device_scope *scope;
     int count =3D 0;
=20
     while ( start < end )
     {
         scope =3D start;
         if ( (scope->length < MIN_SCOPE_LEN) ||
-             (scope->dev_type >=3D ACPI_DEV_ENTRY_COUNT) )
+             (scope->entry_type >=3D ACPI_DMAR_SCOPE_TYPE_RESERVED) )
         {
             dprintk(XENLOG_WARNING VTDPREFIX, "Invalid device scope.\n");
             return -EINVAL;
         }
=20
-        if ( scope->dev_type =3D=3D ACPI_DEV_P2PBRIDGE ||
-             scope->dev_type =3D=3D ACPI_DEV_ENDPOINT ||
-             scope->dev_type =3D=3D ACPI_DEV_IOAPIC ||
-             scope->dev_type =3D=3D ACPI_DEV_MSI_HPET )
+        if ( scope->entry_type =3D=3D ACPI_DMAR_SCOPE_TYPE_BRIDGE ||
+             scope->entry_type =3D=3D ACPI_DMAR_SCOPE_TYPE_ENDPOINT ||
+             scope->entry_type =3D=3D ACPI_DMAR_SCOPE_TYPE_IOAPIC ||
+             scope->entry_type =3D=3D ACPI_DMAR_SCOPE_TYPE_HPET )
             count++;
=20
         start +=3D scope->length;
@@ -276,13 +276,13 @@ static int scope_device_count(void *star
=20
=20
 static int __init acpi_parse_dev_scope(
-    void *start, void *end, void *acpi_entry, int type, u16 seg)
+    const void *start, const void *end, void *acpi_entry, int type, u16 =
seg)
 {
     struct dmar_scope *scope =3D acpi_entry;
     struct acpi_ioapic_unit *acpi_ioapic_unit;
-    struct acpi_dev_scope *acpi_scope;
+    const struct acpi_dmar_device_scope *acpi_scope;
     u16 bus, sub_bus, sec_bus;
-    struct acpi_pci_path *path;
+    const struct acpi_dmar_pci_path *path;
     int depth, cnt, didx =3D 0;
=20
     if ( (cnt =3D scope_device_count(start, end)) < 0 )
@@ -299,10 +299,9 @@ static int __init acpi_parse_dev_scope(
     while ( start < end )
     {
         acpi_scope =3D start;
-        path =3D (struct acpi_pci_path *)(acpi_scope + 1);
-        depth =3D (acpi_scope->length - sizeof(struct acpi_dev_scope))
-		    / sizeof(struct acpi_pci_path);
-        bus =3D acpi_scope->start_bus;
+        path =3D (const void *)(acpi_scope + 1);
+        depth =3D (acpi_scope->length - sizeof(*acpi_scope)) / sizeof(*pat=
h);
+        bus =3D acpi_scope->bus;
=20
         while ( --depth > 0 )
         {
@@ -311,9 +310,9 @@ static int __init acpi_parse_dev_scope(
             path++;
         }
=20
-        switch ( acpi_scope->dev_type )
+        switch ( acpi_scope->entry_type )
         {
-        case ACPI_DEV_P2PBRIDGE:
+        case ACPI_DMAR_SCOPE_TYPE_BRIDGE:
             sec_bus =3D pci_conf_read8(seg, bus, path->dev, path->fn,
                                      PCI_SECONDARY_BUS);
             sub_bus =3D pci_conf_read8(seg, bus, path->dev, path->fn,
@@ -322,18 +321,18 @@ static int __init acpi_parse_dev_scope(
                 dprintk(VTDPREFIX,
                         " bridge: %04x:%02x:%02x.%u start=3D%x sec=3D%x =
sub=3D%x\n",
                         seg, bus, path->dev, path->fn,
-                        acpi_scope->start_bus, sec_bus, sub_bus);
+                        acpi_scope->bus, sec_bus, sub_bus);
=20
             dmar_scope_add_buses(scope, sec_bus, sub_bus);
             break;
=20
-        case ACPI_DEV_MSI_HPET:
+        case ACPI_DMAR_SCOPE_TYPE_HPET:
             if ( iommu_verbose )
                 dprintk(VTDPREFIX, " MSI HPET: %04x:%02x:%02x.%u\n",
                         seg, bus, path->dev, path->fn);
             break;
=20
-        case ACPI_DEV_ENDPOINT:
+        case ACPI_DMAR_SCOPE_TYPE_ENDPOINT:
             if ( iommu_verbose )
                 dprintk(VTDPREFIX, " endpoint: %04x:%02x:%02x.%u\n",
                         seg, bus, path->dev, path->fn);
@@ -349,7 +348,7 @@ static int __init acpi_parse_dev_scope(
=20
             break;
=20
-        case ACPI_DEV_IOAPIC:
+        case ACPI_DMAR_SCOPE_TYPE_IOAPIC:
             if ( iommu_verbose )
                 dprintk(VTDPREFIX, " IOAPIC: %04x:%02x:%02x.%u\n",
                         seg, bus, path->dev, path->fn);
@@ -360,7 +359,7 @@ static int __init acpi_parse_dev_scope(
                 acpi_ioapic_unit =3D xmalloc(struct acpi_ioapic_unit);
                 if ( !acpi_ioapic_unit )
                     return -ENOMEM;
-                acpi_ioapic_unit->apic_id =3D acpi_scope->enum_id;
+                acpi_ioapic_unit->apic_id =3D acpi_scope->enumeration_id;
                 acpi_ioapic_unit->ioapic.bdf.bus =3D bus;
                 acpi_ioapic_unit->ioapic.bdf.dev =3D path->dev;
                 acpi_ioapic_unit->ioapic.bdf.func =3D path->fn;
@@ -377,7 +376,7 @@ static int __init acpi_parse_dev_scope(
 }
=20
 static int __init acpi_dmar_check_length(
-    struct acpi_dmar_entry_header *h, unsigned int min_len)
+    const struct acpi_dmar_header *h, unsigned int min_len)
 {
     if ( h->length >=3D min_len )
         return 0;
@@ -388,9 +387,10 @@ static int __init acpi_dmar_check_length
 }
=20
 static int __init
-acpi_parse_one_drhd(struct acpi_dmar_entry_header *header)
+acpi_parse_one_drhd(struct acpi_dmar_header *header)
 {
-    struct acpi_table_drhd * drhd =3D (struct acpi_table_drhd *)header;
+    struct acpi_dmar_hardware_unit *drhd =3D
+        container_of(header, struct acpi_dmar_hardware_unit, header);
     void *dev_scope_start, *dev_scope_end;
     struct acpi_drhd_unit *dmaru;
     int ret;
@@ -405,7 +405,7 @@ acpi_parse_one_drhd(struct acpi_dmar_ent
=20
     dmaru->address =3D drhd->address;
     dmaru->segment =3D drhd->segment;
-    dmaru->include_all =3D drhd->flags & 1; /* BIT0: INCLUDE_ALL */
+    dmaru->include_all =3D drhd->flags & ACPI_DMAR_INCLUDE_ALL;
     INIT_LIST_HEAD(&dmaru->ioapic_list);
     if ( iommu_verbose )
         dprintk(VTDPREFIX, "  dmaru->address =3D %"PRIx64"\n",
@@ -443,17 +443,20 @@ acpi_parse_one_drhd(struct acpi_dmar_ent
     {
         u8 b, d, f;
         unsigned int i =3D 0, invalid_cnt =3D 0;
-        void *p;
+        union {
+            const void *raw;
+            const struct acpi_dmar_device_scope *scope;
+        } p;
=20
         /* Skip checking if segment is not accessible yet. */
         if ( !pci_known_segment(drhd->segment) )
             i =3D UINT_MAX;
=20
-        for ( p =3D dev_scope_start; i < dmaru->scope.devices_cnt;
-              i++, p +=3D ((struct acpi_dev_scope *)p)->length )
+        for ( p.raw =3D dev_scope_start; i < dmaru->scope.devices_cnt;
+              i++, p.raw +=3D p.scope->length )
         {
-            if ( ((struct acpi_dev_scope *)p)->dev_type =3D=3D ACPI_DEV_IO=
APIC ||
-                 ((struct acpi_dev_scope *)p)->dev_type =3D=3D ACPI_DEV_MS=
I_HPET )
+            if ( p.scope->entry_type =3D=3D ACPI_DMAR_SCOPE_TYPE_IOAPIC =
||
+                 p.scope->entry_type =3D=3D ACPI_DMAR_SCOPE_TYPE_HPET )
                 continue;
=20
             b =3D PCI_BUS(dmaru->scope.devices[i]);
@@ -505,9 +508,10 @@ out:
 }
=20
 static int __init
-acpi_parse_one_rmrr(struct acpi_dmar_entry_header *header)
+acpi_parse_one_rmrr(struct acpi_dmar_header *header)
 {
-    struct acpi_table_rmrr *rmrr =3D (struct acpi_table_rmrr *)header;
+    struct acpi_dmar_reserved_memory *rmrr =3D
+        container_of(header, struct acpi_dmar_reserved_memory, header);
     struct acpi_rmrr_unit *rmrru;
     void *dev_scope_start, *dev_scope_end;
     u64 base_addr =3D rmrr->base_address, end_addr =3D rmrr->end_address;
@@ -610,9 +614,10 @@ acpi_parse_one_rmrr(struct acpi_dmar_ent
 }
=20
 static int __init
-acpi_parse_one_atsr(struct acpi_dmar_entry_header *header)
+acpi_parse_one_atsr(struct acpi_dmar_header *header)
 {
-    struct acpi_table_atsr *atsr =3D (struct acpi_table_atsr *)header;
+    struct acpi_dmar_atsr *atsr =3D
+        container_of(header, struct acpi_dmar_atsr, header);
     struct acpi_atsr_unit *atsru;
     int ret;
     static int all_ports;
@@ -626,7 +631,7 @@ acpi_parse_one_atsr(struct acpi_dmar_ent
         return -ENOMEM;
=20
     atsru->segment =3D atsr->segment;
-    atsru->all_ports =3D atsr->flags & 1; /* BIT0: ALL_PORTS */
+    atsru->all_ports =3D atsr->flags & ACPI_DMAR_ALL_PORTS;
     if ( iommu_verbose )
         dprintk(VTDPREFIX,
                 "  atsru->all_ports: %x\n", atsru->all_ports);
@@ -660,9 +665,10 @@ acpi_parse_one_atsr(struct acpi_dmar_ent
 }
=20
 static int __init
-acpi_parse_one_rhsa(struct acpi_dmar_entry_header *header)
+acpi_parse_one_rhsa(struct acpi_dmar_header *header)
 {
-    struct acpi_table_rhsa *rhsa =3D (struct acpi_table_rhsa *)header;
+    struct acpi_dmar_rhsa *rhsa =3D
+        container_of(header, struct acpi_dmar_rhsa, header);
     struct acpi_rhsa_unit *rhsau;
     int ret;
=20
@@ -673,7 +679,7 @@ acpi_parse_one_rhsa(struct acpi_dmar_ent
     if ( !rhsau )
         return -ENOMEM;
=20
-    rhsau->address =3D rhsa->address;
+    rhsau->address =3D rhsa->base_address;
     rhsau->proximity_domain =3D rhsa->proximity_domain;
     list_add_tail(&rhsau->list, &acpi_rhsa_units);
     if ( iommu_verbose )
@@ -688,7 +694,7 @@ acpi_parse_one_rhsa(struct acpi_dmar_ent
 static int __init acpi_parse_dmar(struct acpi_table_header *table)
 {
     struct acpi_table_dmar *dmar;
-    struct acpi_dmar_entry_header *entry_header;
+    struct acpi_dmar_header *entry_header;
     u8 dmar_host_address_width;
     int ret =3D 0;
=20
@@ -713,33 +719,32 @@ static int __init acpi_parse_dmar(struct
         dprintk(VTDPREFIX, "Host address width %d\n",
                 dmar_host_address_width);
=20
-    entry_header =3D (struct acpi_dmar_entry_header *)(dmar + 1);
+    entry_header =3D (void *)(dmar + 1);
     while ( ((unsigned long)entry_header) <
             (((unsigned long)dmar) + table->length) )
     {
-        ret =3D acpi_dmar_check_length(
-            entry_header, sizeof(struct acpi_dmar_entry_header));
+        ret =3D acpi_dmar_check_length(entry_header, sizeof(*entry_header)=
);
         if ( ret )
             break;
=20
         switch ( entry_header->type )
         {
-        case ACPI_DMAR_DRHD:
+        case ACPI_DMAR_TYPE_HARDWARE_UNIT:
             if ( iommu_verbose )
                 dprintk(VTDPREFIX, "found ACPI_DMAR_DRHD:\n");
             ret =3D acpi_parse_one_drhd(entry_header);
             break;
-        case ACPI_DMAR_RMRR:
+        case ACPI_DMAR_TYPE_RESERVED_MEMORY:
             if ( iommu_verbose )
                 dprintk(VTDPREFIX, "found ACPI_DMAR_RMRR:\n");
             ret =3D acpi_parse_one_rmrr(entry_header);
             break;
-        case ACPI_DMAR_ATSR:
+        case ACPI_DMAR_TYPE_ATSR:
             if ( iommu_verbose )
                 dprintk(VTDPREFIX, "found ACPI_DMAR_ATSR:\n");
             ret =3D acpi_parse_one_atsr(entry_header);
             break;
-        case ACPI_DMAR_RHSA:
+        case ACPI_DMAR_HARDWARE_AFFINITY:
             if ( iommu_verbose )
                 dprintk(VTDPREFIX, "found ACPI_DMAR_RHSA:\n");
             ret =3D acpi_parse_one_rhsa(entry_header);
@@ -803,21 +808,19 @@ void acpi_dmar_zap(void)
=20
 int platform_supports_intremap(void)
 {
-    unsigned int flags =3D 0;
+    unsigned int mask =3D ACPI_DMAR_INTR_REMAP;
=20
-    flags =3D DMAR_INTR_REMAP;
-    return ((dmar_flags & flags) =3D=3D DMAR_INTR_REMAP);
+    return (dmar_flags & mask) =3D=3D ACPI_DMAR_INTR_REMAP;
 }
=20
 #ifdef CONFIG_X86
 int platform_supports_x2apic(void)
 {
-    unsigned int flags =3D 0;
+    unsigned int mask =3D ACPI_DMAR_INTR_REMAP | ACPI_DMAR_X2APIC_OPT_OUT;=

=20
     if (!cpu_has_x2apic)
         return 0;
=20
-    flags =3D DMAR_INTR_REMAP | DMAR_X2APIC_OPT_OUT;
-    return ((dmar_flags & flags) =3D=3D DMAR_INTR_REMAP);
+    return (dmar_flags & mask) =3D=3D ACPI_DMAR_INTR_REMAP;
 }
 #endif
--- a/xen/drivers/passthrough/vtd/iommu.h
+++ b/xen/drivers/passthrough/vtd/iommu.h
@@ -22,10 +22,6 @@
=20
 #include <xen/types.h>
=20
-/* DMAR Flags bits */
-#define DMAR_INTR_REMAP 0x1
-#define DMAR_X2APIC_OPT_OUT 0x2
-
 /*
  * Intel IOMMU register specification per version 1.0 public spec.
  */
--- a/xen/include/xen/acpi.h
+++ b/xen/include/xen/acpi.h
@@ -49,75 +49,6 @@ enum acpi_interrupt_id {
 	ACPI_INTERRUPT_COUNT
 };
=20
-/* DMA Remapping Reporting Table (DMAR) */
-
-#define DMAR_FLAGS_INTR_REMAP 0x1       /* intr remap supported */
-
-struct acpi_dmar_entry_header {
-	u16	type;
-	u16	length;
-} __attribute__((packed));
-
-enum acpi_dmar_entry_type {
-	ACPI_DMAR_DRHD =3D 0,
-	ACPI_DMAR_RMRR,
-	ACPI_DMAR_ATSR,
-	ACPI_DMAR_RHSA,
-	ACPI_DMAR_ENTRY_COUNT
-};
-
-#define DRHD_FLAGS_INCLUDE_ALL	0x1       /* drhd remaps remaining devices =
*/
-struct acpi_table_drhd {
-	struct	acpi_dmar_entry_header header;
-	u8	flags;
-	u8	reserved;
-	u16	segment;
-	u64	address; /* register base address for this drhd */
-} __attribute__ ((packed));
-
-struct acpi_table_rmrr {
-	struct	acpi_dmar_entry_header header;
-	u16	reserved;
-	u16	segment;
-	u64	base_address;
-	u64	end_address;
-} __attribute__ ((packed));
-
-struct acpi_table_atsr {
-	struct	acpi_dmar_entry_header header;
-	u8	flags;
-	u8	reserved;
-	u16	segment;
-} __attribute__ ((packed));
-
-struct acpi_table_rhsa {
-	struct	acpi_dmar_entry_header header;
-	u32	reserved;
-	u64	address; /* register base address for this drhd */
-	u32	proximity_domain;
-} __attribute__ ((packed));
-
-enum acpi_dev_scope_type {
-	ACPI_DEV_ENDPOINT=3D0x01,	/* PCI Endpoing device */
-	ACPI_DEV_P2PBRIDGE,	/* PCI-PCI Bridge */
-	ACPI_DEV_IOAPIC,	/* IOAPIC device*/
-	ACPI_DEV_MSI_HPET,	/* MSI capable HPET*/
-	ACPI_DEV_ENTRY_COUNT
-};
-
-struct acpi_dev_scope {
-	u8	dev_type;
-	u8	length;
-	u8	reserved[2];
-	u8	enum_id;
-	u8	start_bus;
-} __attribute__((packed));
-
-struct acpi_pci_path {
-	u8	dev;
-	u8	fn;
-} __attribute__((packed));
-
 typedef int (*acpi_madt_entry_handler) (struct acpi_subtable_header =
*header, const unsigned long end);
=20
 typedef int (*acpi_table_handler) (struct acpi_table_header *table);



--=__Part7857DD9F.1__=
Content-Type: text/plain; name="acpi-duplicate-dmar-structs.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="acpi-duplicate-dmar-structs.patch"

ACPI: eliminate duplicate DMAR definitions=0A=0AUse their proper counterpar=
ts in include/acpi/actbl*.h instead.=0A=0ASigned-off-by: Jan Beulich =
<jbeulich@suse.com>=0A=0A--- a/xen/drivers/passthrough/vtd/dmar.c=0A+++ =
b/xen/drivers/passthrough/vtd/dmar.c=0A@@ -38,8 +38,8 @@=0A #define PREFIX =
VTDPREFIX "ACPI DMAR:"=0A #define DEBUG=0A =0A-#define MIN_SCOPE_LEN =
(sizeof(struct acpi_pci_path) + \=0A-                       sizeof(struct =
acpi_dev_scope))=0A+#define MIN_SCOPE_LEN (sizeof(struct acpi_dmar_device_s=
cope) + \=0A+                       sizeof(struct acpi_dmar_pci_path))=0A =
=0A LIST_HEAD_READ_MOSTLY(acpi_drhd_units);=0A LIST_HEAD_READ_MOSTLY(acpi_r=
mrr_units);=0A@@ -247,25 +247,25 @@ int is_igd_drhd(struct acpi_drhd_unit =
*d=0A  * Count number of devices in device scope.  Do not include PCI =
sub=0A  * hierarchies.=0A  */=0A-static int scope_device_count(void =
*start, void *end)=0A+static int __init scope_device_count(const void =
*start, const void *end)=0A {=0A-    struct acpi_dev_scope *scope;=0A+    =
const struct acpi_dmar_device_scope *scope;=0A     int count =3D 0;=0A =0A =
    while ( start < end )=0A     {=0A         scope =3D start;=0A         =
if ( (scope->length < MIN_SCOPE_LEN) ||=0A-             (scope->dev_type =
>=3D ACPI_DEV_ENTRY_COUNT) )=0A+             (scope->entry_type >=3D =
ACPI_DMAR_SCOPE_TYPE_RESERVED) )=0A         {=0A             dprintk(XENLOG=
_WARNING VTDPREFIX, "Invalid device scope.\n");=0A             return =
-EINVAL;=0A         }=0A =0A-        if ( scope->dev_type =3D=3D ACPI_DEV_P=
2PBRIDGE ||=0A-             scope->dev_type =3D=3D ACPI_DEV_ENDPOINT =
||=0A-             scope->dev_type =3D=3D ACPI_DEV_IOAPIC ||=0A-           =
  scope->dev_type =3D=3D ACPI_DEV_MSI_HPET )=0A+        if ( scope->entry_t=
ype =3D=3D ACPI_DMAR_SCOPE_TYPE_BRIDGE ||=0A+             scope->entry_type=
 =3D=3D ACPI_DMAR_SCOPE_TYPE_ENDPOINT ||=0A+             scope->entry_type =
=3D=3D ACPI_DMAR_SCOPE_TYPE_IOAPIC ||=0A+             scope->entry_type =
=3D=3D ACPI_DMAR_SCOPE_TYPE_HPET )=0A             count++;=0A =0A         =
start +=3D scope->length;=0A@@ -276,13 +276,13 @@ static int scope_device_c=
ount(void *star=0A =0A =0A static int __init acpi_parse_dev_scope(=0A-    =
void *start, void *end, void *acpi_entry, int type, u16 seg)=0A+    const =
void *start, const void *end, void *acpi_entry, int type, u16 seg)=0A {=0A =
    struct dmar_scope *scope =3D acpi_entry;=0A     struct acpi_ioapic_unit=
 *acpi_ioapic_unit;=0A-    struct acpi_dev_scope *acpi_scope;=0A+    const =
struct acpi_dmar_device_scope *acpi_scope;=0A     u16 bus, sub_bus, =
sec_bus;=0A-    struct acpi_pci_path *path;=0A+    const struct acpi_dmar_p=
ci_path *path;=0A     int depth, cnt, didx =3D 0;=0A =0A     if ( (cnt =3D =
scope_device_count(start, end)) < 0 )=0A@@ -299,10 +299,9 @@ static int =
__init acpi_parse_dev_scope(=0A     while ( start < end )=0A     {=0A      =
   acpi_scope =3D start;=0A-        path =3D (struct acpi_pci_path =
*)(acpi_scope + 1);=0A-        depth =3D (acpi_scope->length - sizeof(struc=
t acpi_dev_scope))=0A-		    / sizeof(struct acpi_pci_path);=0A-    =
    bus =3D acpi_scope->start_bus;=0A+        path =3D (const void =
*)(acpi_scope + 1);=0A+        depth =3D (acpi_scope->length - sizeof(*acpi=
_scope)) / sizeof(*path);=0A+        bus =3D acpi_scope->bus;=0A =0A       =
  while ( --depth > 0 )=0A         {=0A@@ -311,9 +310,9 @@ static int =
__init acpi_parse_dev_scope(=0A             path++;=0A         }=0A =0A-   =
     switch ( acpi_scope->dev_type )=0A+        switch ( acpi_scope->entry_=
type )=0A         {=0A-        case ACPI_DEV_P2PBRIDGE:=0A+        case =
ACPI_DMAR_SCOPE_TYPE_BRIDGE:=0A             sec_bus =3D pci_conf_read8(seg,=
 bus, path->dev, path->fn,=0A                                      =
PCI_SECONDARY_BUS);=0A             sub_bus =3D pci_conf_read8(seg, bus, =
path->dev, path->fn,=0A@@ -322,18 +321,18 @@ static int __init acpi_parse_d=
ev_scope(=0A                 dprintk(VTDPREFIX,=0A                         =
" bridge: %04x:%02x:%02x.%u start=3D%x sec=3D%x sub=3D%x\n",=0A            =
             seg, bus, path->dev, path->fn,=0A-                        =
acpi_scope->start_bus, sec_bus, sub_bus);=0A+                        =
acpi_scope->bus, sec_bus, sub_bus);=0A =0A             dmar_scope_add_buses=
(scope, sec_bus, sub_bus);=0A             break;=0A =0A-        case =
ACPI_DEV_MSI_HPET:=0A+        case ACPI_DMAR_SCOPE_TYPE_HPET:=0A           =
  if ( iommu_verbose )=0A                 dprintk(VTDPREFIX, " MSI HPET: =
%04x:%02x:%02x.%u\n",=0A                         seg, bus, path->dev, =
path->fn);=0A             break;=0A =0A-        case ACPI_DEV_ENDPOINT:=0A+=
        case ACPI_DMAR_SCOPE_TYPE_ENDPOINT:=0A             if ( iommu_verbo=
se )=0A                 dprintk(VTDPREFIX, " endpoint: %04x:%02x:%02x.%u\n"=
,=0A                         seg, bus, path->dev, path->fn);=0A@@ -349,7 =
+348,7 @@ static int __init acpi_parse_dev_scope(=0A =0A             =
break;=0A =0A-        case ACPI_DEV_IOAPIC:=0A+        case ACPI_DMAR_SCOPE=
_TYPE_IOAPIC:=0A             if ( iommu_verbose )=0A                 =
dprintk(VTDPREFIX, " IOAPIC: %04x:%02x:%02x.%u\n",=0A                      =
   seg, bus, path->dev, path->fn);=0A@@ -360,7 +359,7 @@ static int __init =
acpi_parse_dev_scope(=0A                 acpi_ioapic_unit =3D xmalloc(struc=
t acpi_ioapic_unit);=0A                 if ( !acpi_ioapic_unit )=0A        =
             return -ENOMEM;=0A-                acpi_ioapic_unit->apic_id =
=3D acpi_scope->enum_id;=0A+                acpi_ioapic_unit->apic_id =3D =
acpi_scope->enumeration_id;=0A                 acpi_ioapic_unit->ioapic.bdf=
.bus =3D bus;=0A                 acpi_ioapic_unit->ioapic.bdf.dev =3D =
path->dev;=0A                 acpi_ioapic_unit->ioapic.bdf.func =3D =
path->fn;=0A@@ -377,7 +376,7 @@ static int __init acpi_parse_dev_scope(=0A =
}=0A =0A static int __init acpi_dmar_check_length(=0A-    struct acpi_dmar_=
entry_header *h, unsigned int min_len)=0A+    const struct acpi_dmar_header=
 *h, unsigned int min_len)=0A {=0A     if ( h->length >=3D min_len )=0A    =
     return 0;=0A@@ -388,9 +387,10 @@ static int __init acpi_dmar_check_len=
gth=0A }=0A =0A static int __init=0A-acpi_parse_one_drhd(struct acpi_dmar_e=
ntry_header *header)=0A+acpi_parse_one_drhd(struct acpi_dmar_header =
*header)=0A {=0A-    struct acpi_table_drhd * drhd =3D (struct acpi_table_d=
rhd *)header;=0A+    struct acpi_dmar_hardware_unit *drhd =3D=0A+        =
container_of(header, struct acpi_dmar_hardware_unit, header);=0A     void =
*dev_scope_start, *dev_scope_end;=0A     struct acpi_drhd_unit *dmaru;=0A  =
   int ret;=0A@@ -405,7 +405,7 @@ acpi_parse_one_drhd(struct acpi_dmar_ent=
=0A =0A     dmaru->address =3D drhd->address;=0A     dmaru->segment =3D =
drhd->segment;=0A-    dmaru->include_all =3D drhd->flags & 1; /* BIT0: =
INCLUDE_ALL */=0A+    dmaru->include_all =3D drhd->flags & ACPI_DMAR_INCLUD=
E_ALL;=0A     INIT_LIST_HEAD(&dmaru->ioapic_list);=0A     if ( iommu_verbos=
e )=0A         dprintk(VTDPREFIX, "  dmaru->address =3D %"PRIx64"\n",=0A@@ =
-443,17 +443,20 @@ acpi_parse_one_drhd(struct acpi_dmar_ent=0A     {=0A    =
     u8 b, d, f;=0A         unsigned int i =3D 0, invalid_cnt =3D 0;=0A-   =
     void *p;=0A+        union {=0A+            const void *raw;=0A+       =
     const struct acpi_dmar_device_scope *scope;=0A+        } p;=0A =0A    =
     /* Skip checking if segment is not accessible yet. */=0A         if ( =
!pci_known_segment(drhd->segment) )=0A             i =3D UINT_MAX;=0A =0A- =
       for ( p =3D dev_scope_start; i < dmaru->scope.devices_cnt;=0A-      =
        i++, p +=3D ((struct acpi_dev_scope *)p)->length )=0A+        for =
( p.raw =3D dev_scope_start; i < dmaru->scope.devices_cnt;=0A+             =
 i++, p.raw +=3D p.scope->length )=0A         {=0A-            if ( =
((struct acpi_dev_scope *)p)->dev_type =3D=3D ACPI_DEV_IOAPIC ||=0A-       =
          ((struct acpi_dev_scope *)p)->dev_type =3D=3D ACPI_DEV_MSI_HPET =
)=0A+            if ( p.scope->entry_type =3D=3D ACPI_DMAR_SCOPE_TYPE_IOAPI=
C ||=0A+                 p.scope->entry_type =3D=3D ACPI_DMAR_SCOPE_TYPE_HP=
ET )=0A                 continue;=0A =0A             b =3D PCI_BUS(dmaru->s=
cope.devices[i]);=0A@@ -505,9 +508,10 @@ out:=0A }=0A =0A static int =
__init=0A-acpi_parse_one_rmrr(struct acpi_dmar_entry_header *header)=0A+acp=
i_parse_one_rmrr(struct acpi_dmar_header *header)=0A {=0A-    struct =
acpi_table_rmrr *rmrr =3D (struct acpi_table_rmrr *)header;=0A+    struct =
acpi_dmar_reserved_memory *rmrr =3D=0A+        container_of(header, struct =
acpi_dmar_reserved_memory, header);=0A     struct acpi_rmrr_unit *rmrru;=0A=
     void *dev_scope_start, *dev_scope_end;=0A     u64 base_addr =3D =
rmrr->base_address, end_addr =3D rmrr->end_address;=0A@@ -610,9 +614,10 @@ =
acpi_parse_one_rmrr(struct acpi_dmar_ent=0A }=0A =0A static int __init=0A-a=
cpi_parse_one_atsr(struct acpi_dmar_entry_header *header)=0A+acpi_parse_one=
_atsr(struct acpi_dmar_header *header)=0A {=0A-    struct acpi_table_atsr =
*atsr =3D (struct acpi_table_atsr *)header;=0A+    struct acpi_dmar_atsr =
*atsr =3D=0A+        container_of(header, struct acpi_dmar_atsr, =
header);=0A     struct acpi_atsr_unit *atsru;=0A     int ret;=0A     =
static int all_ports;=0A@@ -626,7 +631,7 @@ acpi_parse_one_atsr(struct =
acpi_dmar_ent=0A         return -ENOMEM;=0A =0A     atsru->segment =3D =
atsr->segment;=0A-    atsru->all_ports =3D atsr->flags & 1; /* BIT0: =
ALL_PORTS */=0A+    atsru->all_ports =3D atsr->flags & ACPI_DMAR_ALL_PORTS;=
=0A     if ( iommu_verbose )=0A         dprintk(VTDPREFIX,=0A              =
   "  atsru->all_ports: %x\n", atsru->all_ports);=0A@@ -660,9 +665,10 @@ =
acpi_parse_one_atsr(struct acpi_dmar_ent=0A }=0A =0A static int __init=0A-a=
cpi_parse_one_rhsa(struct acpi_dmar_entry_header *header)=0A+acpi_parse_one=
_rhsa(struct acpi_dmar_header *header)=0A {=0A-    struct acpi_table_rhsa =
*rhsa =3D (struct acpi_table_rhsa *)header;=0A+    struct acpi_dmar_rhsa =
*rhsa =3D=0A+        container_of(header, struct acpi_dmar_rhsa, =
header);=0A     struct acpi_rhsa_unit *rhsau;=0A     int ret;=0A =0A@@ =
-673,7 +679,7 @@ acpi_parse_one_rhsa(struct acpi_dmar_ent=0A     if ( =
!rhsau )=0A         return -ENOMEM;=0A =0A-    rhsau->address =3D =
rhsa->address;=0A+    rhsau->address =3D rhsa->base_address;=0A     =
rhsau->proximity_domain =3D rhsa->proximity_domain;=0A     list_add_tail(&r=
hsau->list, &acpi_rhsa_units);=0A     if ( iommu_verbose )=0A@@ -688,7 =
+694,7 @@ acpi_parse_one_rhsa(struct acpi_dmar_ent=0A static int __init =
acpi_parse_dmar(struct acpi_table_header *table)=0A {=0A     struct =
acpi_table_dmar *dmar;=0A-    struct acpi_dmar_entry_header *entry_header;=
=0A+    struct acpi_dmar_header *entry_header;=0A     u8 dmar_host_address_=
width;=0A     int ret =3D 0;=0A =0A@@ -713,33 +719,32 @@ static int __init =
acpi_parse_dmar(struct=0A         dprintk(VTDPREFIX, "Host address width =
%d\n",=0A                 dmar_host_address_width);=0A =0A-    entry_header=
 =3D (struct acpi_dmar_entry_header *)(dmar + 1);=0A+    entry_header =3D =
(void *)(dmar + 1);=0A     while ( ((unsigned long)entry_header) <=0A      =
       (((unsigned long)dmar) + table->length) )=0A     {=0A-        ret =
=3D acpi_dmar_check_length(=0A-            entry_header, sizeof(struct =
acpi_dmar_entry_header));=0A+        ret =3D acpi_dmar_check_length(entry_h=
eader, sizeof(*entry_header));=0A         if ( ret )=0A             =
break;=0A =0A         switch ( entry_header->type )=0A         {=0A-       =
 case ACPI_DMAR_DRHD:=0A+        case ACPI_DMAR_TYPE_HARDWARE_UNIT:=0A     =
        if ( iommu_verbose )=0A                 dprintk(VTDPREFIX, "found =
ACPI_DMAR_DRHD:\n");=0A             ret =3D acpi_parse_one_drhd(entry_heade=
r);=0A             break;=0A-        case ACPI_DMAR_RMRR:=0A+        case =
ACPI_DMAR_TYPE_RESERVED_MEMORY:=0A             if ( iommu_verbose )=0A     =
            dprintk(VTDPREFIX, "found ACPI_DMAR_RMRR:\n");=0A             =
ret =3D acpi_parse_one_rmrr(entry_header);=0A             break;=0A-       =
 case ACPI_DMAR_ATSR:=0A+        case ACPI_DMAR_TYPE_ATSR:=0A             =
if ( iommu_verbose )=0A                 dprintk(VTDPREFIX, "found =
ACPI_DMAR_ATSR:\n");=0A             ret =3D acpi_parse_one_atsr(entry_heade=
r);=0A             break;=0A-        case ACPI_DMAR_RHSA:=0A+        case =
ACPI_DMAR_HARDWARE_AFFINITY:=0A             if ( iommu_verbose )=0A        =
         dprintk(VTDPREFIX, "found ACPI_DMAR_RHSA:\n");=0A             ret =
=3D acpi_parse_one_rhsa(entry_header);=0A@@ -803,21 +808,19 @@ void =
acpi_dmar_zap(void)=0A =0A int platform_supports_intremap(void)=0A {=0A-   =
 unsigned int flags =3D 0;=0A+    unsigned int mask =3D ACPI_DMAR_INTR_REMA=
P;=0A =0A-    flags =3D DMAR_INTR_REMAP;=0A-    return ((dmar_flags & =
flags) =3D=3D DMAR_INTR_REMAP);=0A+    return (dmar_flags & mask) =3D=3D =
ACPI_DMAR_INTR_REMAP;=0A }=0A =0A #ifdef CONFIG_X86=0A int platform_support=
s_x2apic(void)=0A {=0A-    unsigned int flags =3D 0;=0A+    unsigned int =
mask =3D ACPI_DMAR_INTR_REMAP | ACPI_DMAR_X2APIC_OPT_OUT;=0A =0A     if =
(!cpu_has_x2apic)=0A         return 0;=0A =0A-    flags =3D DMAR_INTR_REMAP=
 | DMAR_X2APIC_OPT_OUT;=0A-    return ((dmar_flags & flags) =3D=3D =
DMAR_INTR_REMAP);=0A+    return (dmar_flags & mask) =3D=3D ACPI_DMAR_INTR_R=
EMAP;=0A }=0A #endif=0A--- a/xen/drivers/passthrough/vtd/iommu.h=0A+++ =
b/xen/drivers/passthrough/vtd/iommu.h=0A@@ -22,10 +22,6 @@=0A =0A #include =
<xen/types.h>=0A =0A-/* DMAR Flags bits */=0A-#define DMAR_INTR_REMAP =
0x1=0A-#define DMAR_X2APIC_OPT_OUT 0x2=0A-=0A /*=0A  * Intel IOMMU =
register specification per version 1.0 public spec.=0A  */=0A--- a/xen/incl=
ude/xen/acpi.h=0A+++ b/xen/include/xen/acpi.h=0A@@ -49,75 +49,6 @@ enum =
acpi_interrupt_id {=0A 	ACPI_INTERRUPT_COUNT=0A };=0A =0A-/* DMA Remapping =
Reporting Table (DMAR) */=0A-=0A-#define DMAR_FLAGS_INTR_REMAP 0x1       =
/* intr remap supported */=0A-=0A-struct acpi_dmar_entry_header {=0A-	=
u16	type;=0A-	u16	length;=0A-} __attribute__((packed));=0A-=
=0A-enum acpi_dmar_entry_type {=0A-	ACPI_DMAR_DRHD =3D 0,=0A-	=
ACPI_DMAR_RMRR,=0A-	ACPI_DMAR_ATSR,=0A-	ACPI_DMAR_RHSA,=0A-	=
ACPI_DMAR_ENTRY_COUNT=0A-};=0A-=0A-#define DRHD_FLAGS_INCLUDE_ALL	=
0x1       /* drhd remaps remaining devices */=0A-struct acpi_table_drhd =
{=0A-	struct	acpi_dmar_entry_header header;=0A-	u8	flags;=0A-	=
u8	reserved;=0A-	u16	segment;=0A-	u64	address; /* =
register base address for this drhd */=0A-} __attribute__ ((packed));=0A-=
=0A-struct acpi_table_rmrr {=0A-	struct	acpi_dmar_entry_header =
header;=0A-	u16	reserved;=0A-	u16	segment;=0A-	u64	=
base_address;=0A-	u64	end_address;=0A-} __attribute__ ((packed));=
=0A-=0A-struct acpi_table_atsr {=0A-	struct	acpi_dmar_entry_header =
header;=0A-	u8	flags;=0A-	u8	reserved;=0A-	u16	=
segment;=0A-} __attribute__ ((packed));=0A-=0A-struct acpi_table_rhsa =
{=0A-	struct	acpi_dmar_entry_header header;=0A-	u32	=
reserved;=0A-	u64	address; /* register base address for this drhd =
*/=0A-	u32	proximity_domain;=0A-} __attribute__ ((packed));=0A-=0A-enu=
m acpi_dev_scope_type {=0A-	ACPI_DEV_ENDPOINT=3D0x01,	/* PCI =
Endpoing device */=0A-	ACPI_DEV_P2PBRIDGE,	/* PCI-PCI Bridge */=0A-	=
ACPI_DEV_IOAPIC,	/* IOAPIC device*/=0A-	ACPI_DEV_MSI_HPET,	/* =
MSI capable HPET*/=0A-	ACPI_DEV_ENTRY_COUNT=0A-};=0A-=0A-struct acpi_dev_s=
cope {=0A-	u8	dev_type;=0A-	u8	length;=0A-	u8	=
reserved[2];=0A-	u8	enum_id;=0A-	u8	start_bus;=0A-} =
__attribute__((packed));=0A-=0A-struct acpi_pci_path {=0A-	u8	=
dev;=0A-	u8	fn;=0A-} __attribute__((packed));=0A-=0A typedef =
int (*acpi_madt_entry_handler) (struct acpi_subtable_header *header, const =
unsigned long end);=0A =0A typedef int (*acpi_table_handler) (struct =
acpi_table_header *table);=0A
--=__Part7857DD9F.1__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--=__Part7857DD9F.1__=--


From xen-devel-bounces@lists.xensource.com Mon Dec 12 16:11:11 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 16:11:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ra8Sv-0003a8-IS; Mon, 12 Dec 2011 16:10:57 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Ra8St-0003Yo-75
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 16:10:55 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1323706200!1632406!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6165 invoked from network); 12 Dec 2011 16:10:00 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-5.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 12 Dec 2011 16:10:00 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 12 Dec 2011 16:10:00 +0000
Message-Id: <4EE6359F0200007800067064@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 12 Dec 2011 16:10:55 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part7857DD9F.1__="
Cc: Allen M Kay <allen.m.kay@intel.com>
Subject: [Xen-devel] [PATCH 3/4] ACPI: eliminate duplicate DMAR definitions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__Part7857DD9F.1__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Use their proper counterparts in include/acpi/actbl*.h instead.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/drivers/passthrough/vtd/dmar.c
+++ b/xen/drivers/passthrough/vtd/dmar.c
@@ -38,8 +38,8 @@
 #define PREFIX VTDPREFIX "ACPI DMAR:"
 #define DEBUG
=20
-#define MIN_SCOPE_LEN (sizeof(struct acpi_pci_path) + \
-                       sizeof(struct acpi_dev_scope))
+#define MIN_SCOPE_LEN (sizeof(struct acpi_dmar_device_scope) + \
+                       sizeof(struct acpi_dmar_pci_path))
=20
 LIST_HEAD_READ_MOSTLY(acpi_drhd_units);
 LIST_HEAD_READ_MOSTLY(acpi_rmrr_units);
@@ -247,25 +247,25 @@ int is_igd_drhd(struct acpi_drhd_unit *d
  * Count number of devices in device scope.  Do not include PCI sub
  * hierarchies.
  */
-static int scope_device_count(void *start, void *end)
+static int __init scope_device_count(const void *start, const void *end)
 {
-    struct acpi_dev_scope *scope;
+    const struct acpi_dmar_device_scope *scope;
     int count =3D 0;
=20
     while ( start < end )
     {
         scope =3D start;
         if ( (scope->length < MIN_SCOPE_LEN) ||
-             (scope->dev_type >=3D ACPI_DEV_ENTRY_COUNT) )
+             (scope->entry_type >=3D ACPI_DMAR_SCOPE_TYPE_RESERVED) )
         {
             dprintk(XENLOG_WARNING VTDPREFIX, "Invalid device scope.\n");
             return -EINVAL;
         }
=20
-        if ( scope->dev_type =3D=3D ACPI_DEV_P2PBRIDGE ||
-             scope->dev_type =3D=3D ACPI_DEV_ENDPOINT ||
-             scope->dev_type =3D=3D ACPI_DEV_IOAPIC ||
-             scope->dev_type =3D=3D ACPI_DEV_MSI_HPET )
+        if ( scope->entry_type =3D=3D ACPI_DMAR_SCOPE_TYPE_BRIDGE ||
+             scope->entry_type =3D=3D ACPI_DMAR_SCOPE_TYPE_ENDPOINT ||
+             scope->entry_type =3D=3D ACPI_DMAR_SCOPE_TYPE_IOAPIC ||
+             scope->entry_type =3D=3D ACPI_DMAR_SCOPE_TYPE_HPET )
             count++;
=20
         start +=3D scope->length;
@@ -276,13 +276,13 @@ static int scope_device_count(void *star
=20
=20
 static int __init acpi_parse_dev_scope(
-    void *start, void *end, void *acpi_entry, int type, u16 seg)
+    const void *start, const void *end, void *acpi_entry, int type, u16 =
seg)
 {
     struct dmar_scope *scope =3D acpi_entry;
     struct acpi_ioapic_unit *acpi_ioapic_unit;
-    struct acpi_dev_scope *acpi_scope;
+    const struct acpi_dmar_device_scope *acpi_scope;
     u16 bus, sub_bus, sec_bus;
-    struct acpi_pci_path *path;
+    const struct acpi_dmar_pci_path *path;
     int depth, cnt, didx =3D 0;
=20
     if ( (cnt =3D scope_device_count(start, end)) < 0 )
@@ -299,10 +299,9 @@ static int __init acpi_parse_dev_scope(
     while ( start < end )
     {
         acpi_scope =3D start;
-        path =3D (struct acpi_pci_path *)(acpi_scope + 1);
-        depth =3D (acpi_scope->length - sizeof(struct acpi_dev_scope))
-		    / sizeof(struct acpi_pci_path);
-        bus =3D acpi_scope->start_bus;
+        path =3D (const void *)(acpi_scope + 1);
+        depth =3D (acpi_scope->length - sizeof(*acpi_scope)) / sizeof(*pat=
h);
+        bus =3D acpi_scope->bus;
=20
         while ( --depth > 0 )
         {
@@ -311,9 +310,9 @@ static int __init acpi_parse_dev_scope(
             path++;
         }
=20
-        switch ( acpi_scope->dev_type )
+        switch ( acpi_scope->entry_type )
         {
-        case ACPI_DEV_P2PBRIDGE:
+        case ACPI_DMAR_SCOPE_TYPE_BRIDGE:
             sec_bus =3D pci_conf_read8(seg, bus, path->dev, path->fn,
                                      PCI_SECONDARY_BUS);
             sub_bus =3D pci_conf_read8(seg, bus, path->dev, path->fn,
@@ -322,18 +321,18 @@ static int __init acpi_parse_dev_scope(
                 dprintk(VTDPREFIX,
                         " bridge: %04x:%02x:%02x.%u start=3D%x sec=3D%x =
sub=3D%x\n",
                         seg, bus, path->dev, path->fn,
-                        acpi_scope->start_bus, sec_bus, sub_bus);
+                        acpi_scope->bus, sec_bus, sub_bus);
=20
             dmar_scope_add_buses(scope, sec_bus, sub_bus);
             break;
=20
-        case ACPI_DEV_MSI_HPET:
+        case ACPI_DMAR_SCOPE_TYPE_HPET:
             if ( iommu_verbose )
                 dprintk(VTDPREFIX, " MSI HPET: %04x:%02x:%02x.%u\n",
                         seg, bus, path->dev, path->fn);
             break;
=20
-        case ACPI_DEV_ENDPOINT:
+        case ACPI_DMAR_SCOPE_TYPE_ENDPOINT:
             if ( iommu_verbose )
                 dprintk(VTDPREFIX, " endpoint: %04x:%02x:%02x.%u\n",
                         seg, bus, path->dev, path->fn);
@@ -349,7 +348,7 @@ static int __init acpi_parse_dev_scope(
=20
             break;
=20
-        case ACPI_DEV_IOAPIC:
+        case ACPI_DMAR_SCOPE_TYPE_IOAPIC:
             if ( iommu_verbose )
                 dprintk(VTDPREFIX, " IOAPIC: %04x:%02x:%02x.%u\n",
                         seg, bus, path->dev, path->fn);
@@ -360,7 +359,7 @@ static int __init acpi_parse_dev_scope(
                 acpi_ioapic_unit =3D xmalloc(struct acpi_ioapic_unit);
                 if ( !acpi_ioapic_unit )
                     return -ENOMEM;
-                acpi_ioapic_unit->apic_id =3D acpi_scope->enum_id;
+                acpi_ioapic_unit->apic_id =3D acpi_scope->enumeration_id;
                 acpi_ioapic_unit->ioapic.bdf.bus =3D bus;
                 acpi_ioapic_unit->ioapic.bdf.dev =3D path->dev;
                 acpi_ioapic_unit->ioapic.bdf.func =3D path->fn;
@@ -377,7 +376,7 @@ static int __init acpi_parse_dev_scope(
 }
=20
 static int __init acpi_dmar_check_length(
-    struct acpi_dmar_entry_header *h, unsigned int min_len)
+    const struct acpi_dmar_header *h, unsigned int min_len)
 {
     if ( h->length >=3D min_len )
         return 0;
@@ -388,9 +387,10 @@ static int __init acpi_dmar_check_length
 }
=20
 static int __init
-acpi_parse_one_drhd(struct acpi_dmar_entry_header *header)
+acpi_parse_one_drhd(struct acpi_dmar_header *header)
 {
-    struct acpi_table_drhd * drhd =3D (struct acpi_table_drhd *)header;
+    struct acpi_dmar_hardware_unit *drhd =3D
+        container_of(header, struct acpi_dmar_hardware_unit, header);
     void *dev_scope_start, *dev_scope_end;
     struct acpi_drhd_unit *dmaru;
     int ret;
@@ -405,7 +405,7 @@ acpi_parse_one_drhd(struct acpi_dmar_ent
=20
     dmaru->address =3D drhd->address;
     dmaru->segment =3D drhd->segment;
-    dmaru->include_all =3D drhd->flags & 1; /* BIT0: INCLUDE_ALL */
+    dmaru->include_all =3D drhd->flags & ACPI_DMAR_INCLUDE_ALL;
     INIT_LIST_HEAD(&dmaru->ioapic_list);
     if ( iommu_verbose )
         dprintk(VTDPREFIX, "  dmaru->address =3D %"PRIx64"\n",
@@ -443,17 +443,20 @@ acpi_parse_one_drhd(struct acpi_dmar_ent
     {
         u8 b, d, f;
         unsigned int i =3D 0, invalid_cnt =3D 0;
-        void *p;
+        union {
+            const void *raw;
+            const struct acpi_dmar_device_scope *scope;
+        } p;
=20
         /* Skip checking if segment is not accessible yet. */
         if ( !pci_known_segment(drhd->segment) )
             i =3D UINT_MAX;
=20
-        for ( p =3D dev_scope_start; i < dmaru->scope.devices_cnt;
-              i++, p +=3D ((struct acpi_dev_scope *)p)->length )
+        for ( p.raw =3D dev_scope_start; i < dmaru->scope.devices_cnt;
+              i++, p.raw +=3D p.scope->length )
         {
-            if ( ((struct acpi_dev_scope *)p)->dev_type =3D=3D ACPI_DEV_IO=
APIC ||
-                 ((struct acpi_dev_scope *)p)->dev_type =3D=3D ACPI_DEV_MS=
I_HPET )
+            if ( p.scope->entry_type =3D=3D ACPI_DMAR_SCOPE_TYPE_IOAPIC =
||
+                 p.scope->entry_type =3D=3D ACPI_DMAR_SCOPE_TYPE_HPET )
                 continue;
=20
             b =3D PCI_BUS(dmaru->scope.devices[i]);
@@ -505,9 +508,10 @@ out:
 }
=20
 static int __init
-acpi_parse_one_rmrr(struct acpi_dmar_entry_header *header)
+acpi_parse_one_rmrr(struct acpi_dmar_header *header)
 {
-    struct acpi_table_rmrr *rmrr =3D (struct acpi_table_rmrr *)header;
+    struct acpi_dmar_reserved_memory *rmrr =3D
+        container_of(header, struct acpi_dmar_reserved_memory, header);
     struct acpi_rmrr_unit *rmrru;
     void *dev_scope_start, *dev_scope_end;
     u64 base_addr =3D rmrr->base_address, end_addr =3D rmrr->end_address;
@@ -610,9 +614,10 @@ acpi_parse_one_rmrr(struct acpi_dmar_ent
 }
=20
 static int __init
-acpi_parse_one_atsr(struct acpi_dmar_entry_header *header)
+acpi_parse_one_atsr(struct acpi_dmar_header *header)
 {
-    struct acpi_table_atsr *atsr =3D (struct acpi_table_atsr *)header;
+    struct acpi_dmar_atsr *atsr =3D
+        container_of(header, struct acpi_dmar_atsr, header);
     struct acpi_atsr_unit *atsru;
     int ret;
     static int all_ports;
@@ -626,7 +631,7 @@ acpi_parse_one_atsr(struct acpi_dmar_ent
         return -ENOMEM;
=20
     atsru->segment =3D atsr->segment;
-    atsru->all_ports =3D atsr->flags & 1; /* BIT0: ALL_PORTS */
+    atsru->all_ports =3D atsr->flags & ACPI_DMAR_ALL_PORTS;
     if ( iommu_verbose )
         dprintk(VTDPREFIX,
                 "  atsru->all_ports: %x\n", atsru->all_ports);
@@ -660,9 +665,10 @@ acpi_parse_one_atsr(struct acpi_dmar_ent
 }
=20
 static int __init
-acpi_parse_one_rhsa(struct acpi_dmar_entry_header *header)
+acpi_parse_one_rhsa(struct acpi_dmar_header *header)
 {
-    struct acpi_table_rhsa *rhsa =3D (struct acpi_table_rhsa *)header;
+    struct acpi_dmar_rhsa *rhsa =3D
+        container_of(header, struct acpi_dmar_rhsa, header);
     struct acpi_rhsa_unit *rhsau;
     int ret;
=20
@@ -673,7 +679,7 @@ acpi_parse_one_rhsa(struct acpi_dmar_ent
     if ( !rhsau )
         return -ENOMEM;
=20
-    rhsau->address =3D rhsa->address;
+    rhsau->address =3D rhsa->base_address;
     rhsau->proximity_domain =3D rhsa->proximity_domain;
     list_add_tail(&rhsau->list, &acpi_rhsa_units);
     if ( iommu_verbose )
@@ -688,7 +694,7 @@ acpi_parse_one_rhsa(struct acpi_dmar_ent
 static int __init acpi_parse_dmar(struct acpi_table_header *table)
 {
     struct acpi_table_dmar *dmar;
-    struct acpi_dmar_entry_header *entry_header;
+    struct acpi_dmar_header *entry_header;
     u8 dmar_host_address_width;
     int ret =3D 0;
=20
@@ -713,33 +719,32 @@ static int __init acpi_parse_dmar(struct
         dprintk(VTDPREFIX, "Host address width %d\n",
                 dmar_host_address_width);
=20
-    entry_header =3D (struct acpi_dmar_entry_header *)(dmar + 1);
+    entry_header =3D (void *)(dmar + 1);
     while ( ((unsigned long)entry_header) <
             (((unsigned long)dmar) + table->length) )
     {
-        ret =3D acpi_dmar_check_length(
-            entry_header, sizeof(struct acpi_dmar_entry_header));
+        ret =3D acpi_dmar_check_length(entry_header, sizeof(*entry_header)=
);
         if ( ret )
             break;
=20
         switch ( entry_header->type )
         {
-        case ACPI_DMAR_DRHD:
+        case ACPI_DMAR_TYPE_HARDWARE_UNIT:
             if ( iommu_verbose )
                 dprintk(VTDPREFIX, "found ACPI_DMAR_DRHD:\n");
             ret =3D acpi_parse_one_drhd(entry_header);
             break;
-        case ACPI_DMAR_RMRR:
+        case ACPI_DMAR_TYPE_RESERVED_MEMORY:
             if ( iommu_verbose )
                 dprintk(VTDPREFIX, "found ACPI_DMAR_RMRR:\n");
             ret =3D acpi_parse_one_rmrr(entry_header);
             break;
-        case ACPI_DMAR_ATSR:
+        case ACPI_DMAR_TYPE_ATSR:
             if ( iommu_verbose )
                 dprintk(VTDPREFIX, "found ACPI_DMAR_ATSR:\n");
             ret =3D acpi_parse_one_atsr(entry_header);
             break;
-        case ACPI_DMAR_RHSA:
+        case ACPI_DMAR_HARDWARE_AFFINITY:
             if ( iommu_verbose )
                 dprintk(VTDPREFIX, "found ACPI_DMAR_RHSA:\n");
             ret =3D acpi_parse_one_rhsa(entry_header);
@@ -803,21 +808,19 @@ void acpi_dmar_zap(void)
=20
 int platform_supports_intremap(void)
 {
-    unsigned int flags =3D 0;
+    unsigned int mask =3D ACPI_DMAR_INTR_REMAP;
=20
-    flags =3D DMAR_INTR_REMAP;
-    return ((dmar_flags & flags) =3D=3D DMAR_INTR_REMAP);
+    return (dmar_flags & mask) =3D=3D ACPI_DMAR_INTR_REMAP;
 }
=20
 #ifdef CONFIG_X86
 int platform_supports_x2apic(void)
 {
-    unsigned int flags =3D 0;
+    unsigned int mask =3D ACPI_DMAR_INTR_REMAP | ACPI_DMAR_X2APIC_OPT_OUT;=

=20
     if (!cpu_has_x2apic)
         return 0;
=20
-    flags =3D DMAR_INTR_REMAP | DMAR_X2APIC_OPT_OUT;
-    return ((dmar_flags & flags) =3D=3D DMAR_INTR_REMAP);
+    return (dmar_flags & mask) =3D=3D ACPI_DMAR_INTR_REMAP;
 }
 #endif
--- a/xen/drivers/passthrough/vtd/iommu.h
+++ b/xen/drivers/passthrough/vtd/iommu.h
@@ -22,10 +22,6 @@
=20
 #include <xen/types.h>
=20
-/* DMAR Flags bits */
-#define DMAR_INTR_REMAP 0x1
-#define DMAR_X2APIC_OPT_OUT 0x2
-
 /*
  * Intel IOMMU register specification per version 1.0 public spec.
  */
--- a/xen/include/xen/acpi.h
+++ b/xen/include/xen/acpi.h
@@ -49,75 +49,6 @@ enum acpi_interrupt_id {
 	ACPI_INTERRUPT_COUNT
 };
=20
-/* DMA Remapping Reporting Table (DMAR) */
-
-#define DMAR_FLAGS_INTR_REMAP 0x1       /* intr remap supported */
-
-struct acpi_dmar_entry_header {
-	u16	type;
-	u16	length;
-} __attribute__((packed));
-
-enum acpi_dmar_entry_type {
-	ACPI_DMAR_DRHD =3D 0,
-	ACPI_DMAR_RMRR,
-	ACPI_DMAR_ATSR,
-	ACPI_DMAR_RHSA,
-	ACPI_DMAR_ENTRY_COUNT
-};
-
-#define DRHD_FLAGS_INCLUDE_ALL	0x1       /* drhd remaps remaining devices =
*/
-struct acpi_table_drhd {
-	struct	acpi_dmar_entry_header header;
-	u8	flags;
-	u8	reserved;
-	u16	segment;
-	u64	address; /* register base address for this drhd */
-} __attribute__ ((packed));
-
-struct acpi_table_rmrr {
-	struct	acpi_dmar_entry_header header;
-	u16	reserved;
-	u16	segment;
-	u64	base_address;
-	u64	end_address;
-} __attribute__ ((packed));
-
-struct acpi_table_atsr {
-	struct	acpi_dmar_entry_header header;
-	u8	flags;
-	u8	reserved;
-	u16	segment;
-} __attribute__ ((packed));
-
-struct acpi_table_rhsa {
-	struct	acpi_dmar_entry_header header;
-	u32	reserved;
-	u64	address; /* register base address for this drhd */
-	u32	proximity_domain;
-} __attribute__ ((packed));
-
-enum acpi_dev_scope_type {
-	ACPI_DEV_ENDPOINT=3D0x01,	/* PCI Endpoing device */
-	ACPI_DEV_P2PBRIDGE,	/* PCI-PCI Bridge */
-	ACPI_DEV_IOAPIC,	/* IOAPIC device*/
-	ACPI_DEV_MSI_HPET,	/* MSI capable HPET*/
-	ACPI_DEV_ENTRY_COUNT
-};
-
-struct acpi_dev_scope {
-	u8	dev_type;
-	u8	length;
-	u8	reserved[2];
-	u8	enum_id;
-	u8	start_bus;
-} __attribute__((packed));
-
-struct acpi_pci_path {
-	u8	dev;
-	u8	fn;
-} __attribute__((packed));
-
 typedef int (*acpi_madt_entry_handler) (struct acpi_subtable_header =
*header, const unsigned long end);
=20
 typedef int (*acpi_table_handler) (struct acpi_table_header *table);



--=__Part7857DD9F.1__=
Content-Type: text/plain; name="acpi-duplicate-dmar-structs.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="acpi-duplicate-dmar-structs.patch"

ACPI: eliminate duplicate DMAR definitions=0A=0AUse their proper counterpar=
ts in include/acpi/actbl*.h instead.=0A=0ASigned-off-by: Jan Beulich =
<jbeulich@suse.com>=0A=0A--- a/xen/drivers/passthrough/vtd/dmar.c=0A+++ =
b/xen/drivers/passthrough/vtd/dmar.c=0A@@ -38,8 +38,8 @@=0A #define PREFIX =
VTDPREFIX "ACPI DMAR:"=0A #define DEBUG=0A =0A-#define MIN_SCOPE_LEN =
(sizeof(struct acpi_pci_path) + \=0A-                       sizeof(struct =
acpi_dev_scope))=0A+#define MIN_SCOPE_LEN (sizeof(struct acpi_dmar_device_s=
cope) + \=0A+                       sizeof(struct acpi_dmar_pci_path))=0A =
=0A LIST_HEAD_READ_MOSTLY(acpi_drhd_units);=0A LIST_HEAD_READ_MOSTLY(acpi_r=
mrr_units);=0A@@ -247,25 +247,25 @@ int is_igd_drhd(struct acpi_drhd_unit =
*d=0A  * Count number of devices in device scope.  Do not include PCI =
sub=0A  * hierarchies.=0A  */=0A-static int scope_device_count(void =
*start, void *end)=0A+static int __init scope_device_count(const void =
*start, const void *end)=0A {=0A-    struct acpi_dev_scope *scope;=0A+    =
const struct acpi_dmar_device_scope *scope;=0A     int count =3D 0;=0A =0A =
    while ( start < end )=0A     {=0A         scope =3D start;=0A         =
if ( (scope->length < MIN_SCOPE_LEN) ||=0A-             (scope->dev_type =
>=3D ACPI_DEV_ENTRY_COUNT) )=0A+             (scope->entry_type >=3D =
ACPI_DMAR_SCOPE_TYPE_RESERVED) )=0A         {=0A             dprintk(XENLOG=
_WARNING VTDPREFIX, "Invalid device scope.\n");=0A             return =
-EINVAL;=0A         }=0A =0A-        if ( scope->dev_type =3D=3D ACPI_DEV_P=
2PBRIDGE ||=0A-             scope->dev_type =3D=3D ACPI_DEV_ENDPOINT =
||=0A-             scope->dev_type =3D=3D ACPI_DEV_IOAPIC ||=0A-           =
  scope->dev_type =3D=3D ACPI_DEV_MSI_HPET )=0A+        if ( scope->entry_t=
ype =3D=3D ACPI_DMAR_SCOPE_TYPE_BRIDGE ||=0A+             scope->entry_type=
 =3D=3D ACPI_DMAR_SCOPE_TYPE_ENDPOINT ||=0A+             scope->entry_type =
=3D=3D ACPI_DMAR_SCOPE_TYPE_IOAPIC ||=0A+             scope->entry_type =
=3D=3D ACPI_DMAR_SCOPE_TYPE_HPET )=0A             count++;=0A =0A         =
start +=3D scope->length;=0A@@ -276,13 +276,13 @@ static int scope_device_c=
ount(void *star=0A =0A =0A static int __init acpi_parse_dev_scope(=0A-    =
void *start, void *end, void *acpi_entry, int type, u16 seg)=0A+    const =
void *start, const void *end, void *acpi_entry, int type, u16 seg)=0A {=0A =
    struct dmar_scope *scope =3D acpi_entry;=0A     struct acpi_ioapic_unit=
 *acpi_ioapic_unit;=0A-    struct acpi_dev_scope *acpi_scope;=0A+    const =
struct acpi_dmar_device_scope *acpi_scope;=0A     u16 bus, sub_bus, =
sec_bus;=0A-    struct acpi_pci_path *path;=0A+    const struct acpi_dmar_p=
ci_path *path;=0A     int depth, cnt, didx =3D 0;=0A =0A     if ( (cnt =3D =
scope_device_count(start, end)) < 0 )=0A@@ -299,10 +299,9 @@ static int =
__init acpi_parse_dev_scope(=0A     while ( start < end )=0A     {=0A      =
   acpi_scope =3D start;=0A-        path =3D (struct acpi_pci_path =
*)(acpi_scope + 1);=0A-        depth =3D (acpi_scope->length - sizeof(struc=
t acpi_dev_scope))=0A-		    / sizeof(struct acpi_pci_path);=0A-    =
    bus =3D acpi_scope->start_bus;=0A+        path =3D (const void =
*)(acpi_scope + 1);=0A+        depth =3D (acpi_scope->length - sizeof(*acpi=
_scope)) / sizeof(*path);=0A+        bus =3D acpi_scope->bus;=0A =0A       =
  while ( --depth > 0 )=0A         {=0A@@ -311,9 +310,9 @@ static int =
__init acpi_parse_dev_scope(=0A             path++;=0A         }=0A =0A-   =
     switch ( acpi_scope->dev_type )=0A+        switch ( acpi_scope->entry_=
type )=0A         {=0A-        case ACPI_DEV_P2PBRIDGE:=0A+        case =
ACPI_DMAR_SCOPE_TYPE_BRIDGE:=0A             sec_bus =3D pci_conf_read8(seg,=
 bus, path->dev, path->fn,=0A                                      =
PCI_SECONDARY_BUS);=0A             sub_bus =3D pci_conf_read8(seg, bus, =
path->dev, path->fn,=0A@@ -322,18 +321,18 @@ static int __init acpi_parse_d=
ev_scope(=0A                 dprintk(VTDPREFIX,=0A                         =
" bridge: %04x:%02x:%02x.%u start=3D%x sec=3D%x sub=3D%x\n",=0A            =
             seg, bus, path->dev, path->fn,=0A-                        =
acpi_scope->start_bus, sec_bus, sub_bus);=0A+                        =
acpi_scope->bus, sec_bus, sub_bus);=0A =0A             dmar_scope_add_buses=
(scope, sec_bus, sub_bus);=0A             break;=0A =0A-        case =
ACPI_DEV_MSI_HPET:=0A+        case ACPI_DMAR_SCOPE_TYPE_HPET:=0A           =
  if ( iommu_verbose )=0A                 dprintk(VTDPREFIX, " MSI HPET: =
%04x:%02x:%02x.%u\n",=0A                         seg, bus, path->dev, =
path->fn);=0A             break;=0A =0A-        case ACPI_DEV_ENDPOINT:=0A+=
        case ACPI_DMAR_SCOPE_TYPE_ENDPOINT:=0A             if ( iommu_verbo=
se )=0A                 dprintk(VTDPREFIX, " endpoint: %04x:%02x:%02x.%u\n"=
,=0A                         seg, bus, path->dev, path->fn);=0A@@ -349,7 =
+348,7 @@ static int __init acpi_parse_dev_scope(=0A =0A             =
break;=0A =0A-        case ACPI_DEV_IOAPIC:=0A+        case ACPI_DMAR_SCOPE=
_TYPE_IOAPIC:=0A             if ( iommu_verbose )=0A                 =
dprintk(VTDPREFIX, " IOAPIC: %04x:%02x:%02x.%u\n",=0A                      =
   seg, bus, path->dev, path->fn);=0A@@ -360,7 +359,7 @@ static int __init =
acpi_parse_dev_scope(=0A                 acpi_ioapic_unit =3D xmalloc(struc=
t acpi_ioapic_unit);=0A                 if ( !acpi_ioapic_unit )=0A        =
             return -ENOMEM;=0A-                acpi_ioapic_unit->apic_id =
=3D acpi_scope->enum_id;=0A+                acpi_ioapic_unit->apic_id =3D =
acpi_scope->enumeration_id;=0A                 acpi_ioapic_unit->ioapic.bdf=
.bus =3D bus;=0A                 acpi_ioapic_unit->ioapic.bdf.dev =3D =
path->dev;=0A                 acpi_ioapic_unit->ioapic.bdf.func =3D =
path->fn;=0A@@ -377,7 +376,7 @@ static int __init acpi_parse_dev_scope(=0A =
}=0A =0A static int __init acpi_dmar_check_length(=0A-    struct acpi_dmar_=
entry_header *h, unsigned int min_len)=0A+    const struct acpi_dmar_header=
 *h, unsigned int min_len)=0A {=0A     if ( h->length >=3D min_len )=0A    =
     return 0;=0A@@ -388,9 +387,10 @@ static int __init acpi_dmar_check_len=
gth=0A }=0A =0A static int __init=0A-acpi_parse_one_drhd(struct acpi_dmar_e=
ntry_header *header)=0A+acpi_parse_one_drhd(struct acpi_dmar_header =
*header)=0A {=0A-    struct acpi_table_drhd * drhd =3D (struct acpi_table_d=
rhd *)header;=0A+    struct acpi_dmar_hardware_unit *drhd =3D=0A+        =
container_of(header, struct acpi_dmar_hardware_unit, header);=0A     void =
*dev_scope_start, *dev_scope_end;=0A     struct acpi_drhd_unit *dmaru;=0A  =
   int ret;=0A@@ -405,7 +405,7 @@ acpi_parse_one_drhd(struct acpi_dmar_ent=
=0A =0A     dmaru->address =3D drhd->address;=0A     dmaru->segment =3D =
drhd->segment;=0A-    dmaru->include_all =3D drhd->flags & 1; /* BIT0: =
INCLUDE_ALL */=0A+    dmaru->include_all =3D drhd->flags & ACPI_DMAR_INCLUD=
E_ALL;=0A     INIT_LIST_HEAD(&dmaru->ioapic_list);=0A     if ( iommu_verbos=
e )=0A         dprintk(VTDPREFIX, "  dmaru->address =3D %"PRIx64"\n",=0A@@ =
-443,17 +443,20 @@ acpi_parse_one_drhd(struct acpi_dmar_ent=0A     {=0A    =
     u8 b, d, f;=0A         unsigned int i =3D 0, invalid_cnt =3D 0;=0A-   =
     void *p;=0A+        union {=0A+            const void *raw;=0A+       =
     const struct acpi_dmar_device_scope *scope;=0A+        } p;=0A =0A    =
     /* Skip checking if segment is not accessible yet. */=0A         if ( =
!pci_known_segment(drhd->segment) )=0A             i =3D UINT_MAX;=0A =0A- =
       for ( p =3D dev_scope_start; i < dmaru->scope.devices_cnt;=0A-      =
        i++, p +=3D ((struct acpi_dev_scope *)p)->length )=0A+        for =
( p.raw =3D dev_scope_start; i < dmaru->scope.devices_cnt;=0A+             =
 i++, p.raw +=3D p.scope->length )=0A         {=0A-            if ( =
((struct acpi_dev_scope *)p)->dev_type =3D=3D ACPI_DEV_IOAPIC ||=0A-       =
          ((struct acpi_dev_scope *)p)->dev_type =3D=3D ACPI_DEV_MSI_HPET =
)=0A+            if ( p.scope->entry_type =3D=3D ACPI_DMAR_SCOPE_TYPE_IOAPI=
C ||=0A+                 p.scope->entry_type =3D=3D ACPI_DMAR_SCOPE_TYPE_HP=
ET )=0A                 continue;=0A =0A             b =3D PCI_BUS(dmaru->s=
cope.devices[i]);=0A@@ -505,9 +508,10 @@ out:=0A }=0A =0A static int =
__init=0A-acpi_parse_one_rmrr(struct acpi_dmar_entry_header *header)=0A+acp=
i_parse_one_rmrr(struct acpi_dmar_header *header)=0A {=0A-    struct =
acpi_table_rmrr *rmrr =3D (struct acpi_table_rmrr *)header;=0A+    struct =
acpi_dmar_reserved_memory *rmrr =3D=0A+        container_of(header, struct =
acpi_dmar_reserved_memory, header);=0A     struct acpi_rmrr_unit *rmrru;=0A=
     void *dev_scope_start, *dev_scope_end;=0A     u64 base_addr =3D =
rmrr->base_address, end_addr =3D rmrr->end_address;=0A@@ -610,9 +614,10 @@ =
acpi_parse_one_rmrr(struct acpi_dmar_ent=0A }=0A =0A static int __init=0A-a=
cpi_parse_one_atsr(struct acpi_dmar_entry_header *header)=0A+acpi_parse_one=
_atsr(struct acpi_dmar_header *header)=0A {=0A-    struct acpi_table_atsr =
*atsr =3D (struct acpi_table_atsr *)header;=0A+    struct acpi_dmar_atsr =
*atsr =3D=0A+        container_of(header, struct acpi_dmar_atsr, =
header);=0A     struct acpi_atsr_unit *atsru;=0A     int ret;=0A     =
static int all_ports;=0A@@ -626,7 +631,7 @@ acpi_parse_one_atsr(struct =
acpi_dmar_ent=0A         return -ENOMEM;=0A =0A     atsru->segment =3D =
atsr->segment;=0A-    atsru->all_ports =3D atsr->flags & 1; /* BIT0: =
ALL_PORTS */=0A+    atsru->all_ports =3D atsr->flags & ACPI_DMAR_ALL_PORTS;=
=0A     if ( iommu_verbose )=0A         dprintk(VTDPREFIX,=0A              =
   "  atsru->all_ports: %x\n", atsru->all_ports);=0A@@ -660,9 +665,10 @@ =
acpi_parse_one_atsr(struct acpi_dmar_ent=0A }=0A =0A static int __init=0A-a=
cpi_parse_one_rhsa(struct acpi_dmar_entry_header *header)=0A+acpi_parse_one=
_rhsa(struct acpi_dmar_header *header)=0A {=0A-    struct acpi_table_rhsa =
*rhsa =3D (struct acpi_table_rhsa *)header;=0A+    struct acpi_dmar_rhsa =
*rhsa =3D=0A+        container_of(header, struct acpi_dmar_rhsa, =
header);=0A     struct acpi_rhsa_unit *rhsau;=0A     int ret;=0A =0A@@ =
-673,7 +679,7 @@ acpi_parse_one_rhsa(struct acpi_dmar_ent=0A     if ( =
!rhsau )=0A         return -ENOMEM;=0A =0A-    rhsau->address =3D =
rhsa->address;=0A+    rhsau->address =3D rhsa->base_address;=0A     =
rhsau->proximity_domain =3D rhsa->proximity_domain;=0A     list_add_tail(&r=
hsau->list, &acpi_rhsa_units);=0A     if ( iommu_verbose )=0A@@ -688,7 =
+694,7 @@ acpi_parse_one_rhsa(struct acpi_dmar_ent=0A static int __init =
acpi_parse_dmar(struct acpi_table_header *table)=0A {=0A     struct =
acpi_table_dmar *dmar;=0A-    struct acpi_dmar_entry_header *entry_header;=
=0A+    struct acpi_dmar_header *entry_header;=0A     u8 dmar_host_address_=
width;=0A     int ret =3D 0;=0A =0A@@ -713,33 +719,32 @@ static int __init =
acpi_parse_dmar(struct=0A         dprintk(VTDPREFIX, "Host address width =
%d\n",=0A                 dmar_host_address_width);=0A =0A-    entry_header=
 =3D (struct acpi_dmar_entry_header *)(dmar + 1);=0A+    entry_header =3D =
(void *)(dmar + 1);=0A     while ( ((unsigned long)entry_header) <=0A      =
       (((unsigned long)dmar) + table->length) )=0A     {=0A-        ret =
=3D acpi_dmar_check_length(=0A-            entry_header, sizeof(struct =
acpi_dmar_entry_header));=0A+        ret =3D acpi_dmar_check_length(entry_h=
eader, sizeof(*entry_header));=0A         if ( ret )=0A             =
break;=0A =0A         switch ( entry_header->type )=0A         {=0A-       =
 case ACPI_DMAR_DRHD:=0A+        case ACPI_DMAR_TYPE_HARDWARE_UNIT:=0A     =
        if ( iommu_verbose )=0A                 dprintk(VTDPREFIX, "found =
ACPI_DMAR_DRHD:\n");=0A             ret =3D acpi_parse_one_drhd(entry_heade=
r);=0A             break;=0A-        case ACPI_DMAR_RMRR:=0A+        case =
ACPI_DMAR_TYPE_RESERVED_MEMORY:=0A             if ( iommu_verbose )=0A     =
            dprintk(VTDPREFIX, "found ACPI_DMAR_RMRR:\n");=0A             =
ret =3D acpi_parse_one_rmrr(entry_header);=0A             break;=0A-       =
 case ACPI_DMAR_ATSR:=0A+        case ACPI_DMAR_TYPE_ATSR:=0A             =
if ( iommu_verbose )=0A                 dprintk(VTDPREFIX, "found =
ACPI_DMAR_ATSR:\n");=0A             ret =3D acpi_parse_one_atsr(entry_heade=
r);=0A             break;=0A-        case ACPI_DMAR_RHSA:=0A+        case =
ACPI_DMAR_HARDWARE_AFFINITY:=0A             if ( iommu_verbose )=0A        =
         dprintk(VTDPREFIX, "found ACPI_DMAR_RHSA:\n");=0A             ret =
=3D acpi_parse_one_rhsa(entry_header);=0A@@ -803,21 +808,19 @@ void =
acpi_dmar_zap(void)=0A =0A int platform_supports_intremap(void)=0A {=0A-   =
 unsigned int flags =3D 0;=0A+    unsigned int mask =3D ACPI_DMAR_INTR_REMA=
P;=0A =0A-    flags =3D DMAR_INTR_REMAP;=0A-    return ((dmar_flags & =
flags) =3D=3D DMAR_INTR_REMAP);=0A+    return (dmar_flags & mask) =3D=3D =
ACPI_DMAR_INTR_REMAP;=0A }=0A =0A #ifdef CONFIG_X86=0A int platform_support=
s_x2apic(void)=0A {=0A-    unsigned int flags =3D 0;=0A+    unsigned int =
mask =3D ACPI_DMAR_INTR_REMAP | ACPI_DMAR_X2APIC_OPT_OUT;=0A =0A     if =
(!cpu_has_x2apic)=0A         return 0;=0A =0A-    flags =3D DMAR_INTR_REMAP=
 | DMAR_X2APIC_OPT_OUT;=0A-    return ((dmar_flags & flags) =3D=3D =
DMAR_INTR_REMAP);=0A+    return (dmar_flags & mask) =3D=3D ACPI_DMAR_INTR_R=
EMAP;=0A }=0A #endif=0A--- a/xen/drivers/passthrough/vtd/iommu.h=0A+++ =
b/xen/drivers/passthrough/vtd/iommu.h=0A@@ -22,10 +22,6 @@=0A =0A #include =
<xen/types.h>=0A =0A-/* DMAR Flags bits */=0A-#define DMAR_INTR_REMAP =
0x1=0A-#define DMAR_X2APIC_OPT_OUT 0x2=0A-=0A /*=0A  * Intel IOMMU =
register specification per version 1.0 public spec.=0A  */=0A--- a/xen/incl=
ude/xen/acpi.h=0A+++ b/xen/include/xen/acpi.h=0A@@ -49,75 +49,6 @@ enum =
acpi_interrupt_id {=0A 	ACPI_INTERRUPT_COUNT=0A };=0A =0A-/* DMA Remapping =
Reporting Table (DMAR) */=0A-=0A-#define DMAR_FLAGS_INTR_REMAP 0x1       =
/* intr remap supported */=0A-=0A-struct acpi_dmar_entry_header {=0A-	=
u16	type;=0A-	u16	length;=0A-} __attribute__((packed));=0A-=
=0A-enum acpi_dmar_entry_type {=0A-	ACPI_DMAR_DRHD =3D 0,=0A-	=
ACPI_DMAR_RMRR,=0A-	ACPI_DMAR_ATSR,=0A-	ACPI_DMAR_RHSA,=0A-	=
ACPI_DMAR_ENTRY_COUNT=0A-};=0A-=0A-#define DRHD_FLAGS_INCLUDE_ALL	=
0x1       /* drhd remaps remaining devices */=0A-struct acpi_table_drhd =
{=0A-	struct	acpi_dmar_entry_header header;=0A-	u8	flags;=0A-	=
u8	reserved;=0A-	u16	segment;=0A-	u64	address; /* =
register base address for this drhd */=0A-} __attribute__ ((packed));=0A-=
=0A-struct acpi_table_rmrr {=0A-	struct	acpi_dmar_entry_header =
header;=0A-	u16	reserved;=0A-	u16	segment;=0A-	u64	=
base_address;=0A-	u64	end_address;=0A-} __attribute__ ((packed));=
=0A-=0A-struct acpi_table_atsr {=0A-	struct	acpi_dmar_entry_header =
header;=0A-	u8	flags;=0A-	u8	reserved;=0A-	u16	=
segment;=0A-} __attribute__ ((packed));=0A-=0A-struct acpi_table_rhsa =
{=0A-	struct	acpi_dmar_entry_header header;=0A-	u32	=
reserved;=0A-	u64	address; /* register base address for this drhd =
*/=0A-	u32	proximity_domain;=0A-} __attribute__ ((packed));=0A-=0A-enu=
m acpi_dev_scope_type {=0A-	ACPI_DEV_ENDPOINT=3D0x01,	/* PCI =
Endpoing device */=0A-	ACPI_DEV_P2PBRIDGE,	/* PCI-PCI Bridge */=0A-	=
ACPI_DEV_IOAPIC,	/* IOAPIC device*/=0A-	ACPI_DEV_MSI_HPET,	/* =
MSI capable HPET*/=0A-	ACPI_DEV_ENTRY_COUNT=0A-};=0A-=0A-struct acpi_dev_s=
cope {=0A-	u8	dev_type;=0A-	u8	length;=0A-	u8	=
reserved[2];=0A-	u8	enum_id;=0A-	u8	start_bus;=0A-} =
__attribute__((packed));=0A-=0A-struct acpi_pci_path {=0A-	u8	=
dev;=0A-	u8	fn;=0A-} __attribute__((packed));=0A-=0A typedef =
int (*acpi_madt_entry_handler) (struct acpi_subtable_header *header, const =
unsigned long end);=0A =0A typedef int (*acpi_table_handler) (struct =
acpi_table_header *table);=0A
--=__Part7857DD9F.1__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--=__Part7857DD9F.1__=--


From xen-devel-bounces@lists.xensource.com Mon Dec 12 16:38:47 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 16:38:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ra8tW-0004Yj-9g; Mon, 12 Dec 2011 16:38:26 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1Ra8tV-0004Ya-Mn
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 16:38:25 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-13.tower-21.messagelabs.com!1323707850!5954825!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16510 invoked from network); 12 Dec 2011 16:37:32 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-13.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 12 Dec 2011 16:37:32 -0000
Received: from andromeda.dapyr.net (darnok@localhost [127.0.0.1])
	by andromeda.dapyr.net (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id
	pBCGbMwa024032
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Mon, 12 Dec 2011 11:37:22 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pBCGbMPL024030;
	Mon, 12 Dec 2011 11:37:22 -0500
Date: Mon, 12 Dec 2011 12:37:22 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Sergi Seira <s.seira@cdmon.com>
Message-ID: <20111212163722.GB23490@andromeda.dapyr.net>
References: <4ED5FFBC.3080605@cdmon.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4ED5FFBC.3080605@cdmon.com>
User-Agent: Mutt/1.5.9i
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] ext4_mb_generate_buddy remounting read-only on domU
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Nov 30, 2011 at 11:04:44AM +0100, Sergi Seira wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hi,
> 
> has anyone had ext4 filesystem remounting hours after a live-migration?
> 
> We've been having those 'read only remounts' always hours after a live-migration.
> The more load a domU has the faster we get 'read only remount'.
> We are suspecting something is getting corrupted after a live migration, and under load an error bumps:
> 
>  kernel: [3424760.190005] EXT4-fs error (device xvda3): ext4_mb_generate_buddy: EXT4-fs: group 55: 6102 blocks in bitmap, 6101 in gd
>  kernel: [3424760.190059] Aborting journal on device xvda3-8.
>  kernel: [3424760.191197] EXT4-fs (xvda3): Remounting filesystem read-only
>  kernel: [3424760.204396] EXT4-fs (xvda3): delayed block allocation failed for inode 374665 at logical offset 318 with max blocks 1 with error -30
>  kernel: [3424760.204447] This should not happen!!  Data will be lost
>  kernel: [3424760.204483] EXT4-fs (xvda3): ext4_da_writepages: jbd2_start: 1015 pages, ino 374665; err -30
> 
> We have to fsck the volume from dom0 before re-creating domU.
> 
> Our system runs on :
> 
>  dom0 debian6 2.6.32-5-xen-amd64

This looks familiar,
http://xen.1045712.n5.nabble.com/ext4-BUG-in-dom0-Kernel-2-6-32-36-td4773487.html

Ah no. There was some fix to blktap for this I think. What exactly is
the drivery you are using to drive the root/home/swap of the guest? Is
it blkback or blktap?


>  xen-hypervisor 4.0.1-2
> 
> DomU are:
> 
>  domU paravirtual debian6 2.6.32-5-xen-amd64
>  3 iscsi volumes act as vxda's, swap, root and home (400G)
>  7 vcpus
>  8 GB RAM
> 
> Regards,
> Sergi
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> 
> iQEcBAEBAgAGBQJO1f+8AAoJEN00VGSIizZ0zVIH/0KLyFgLAwJNmtXVbHo0VcsY
> IicYbcv5CJNkJZ/WDskPK/33HsWH98epWzsRbr33qAibZrKfJig/1HuHs8SwGwGe
> Xt1ii9+gnhy/oyNSnPbgmDpD6W81iEPkCTLm0fdHmndP9E5dbIWOzCMcIMvFB0RD
> +2bPKQ3CcKEqnbXcriYzKVdfU2Y4/UbgZJYCQBJizK20A9KbqwAyLve/zRxJ7WP8
> Q7+zWXkxefwcVq9rcBfkITvlrLQw9b9kK1KT7+7MrnxkG0ujIFYKVqkBxuIb4C3u
> kILnz8Gh6vuiKhHy+5DKqEpGmhSsq/VVymLQCNerveluer2TF9QOTisv2kXw58Y=
> =+hQj
> -----END PGP SIGNATURE-----
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 16:38:47 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 16:38:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ra8tW-0004Yj-9g; Mon, 12 Dec 2011 16:38:26 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1Ra8tV-0004Ya-Mn
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 16:38:25 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-13.tower-21.messagelabs.com!1323707850!5954825!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16510 invoked from network); 12 Dec 2011 16:37:32 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-13.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 12 Dec 2011 16:37:32 -0000
Received: from andromeda.dapyr.net (darnok@localhost [127.0.0.1])
	by andromeda.dapyr.net (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id
	pBCGbMwa024032
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Mon, 12 Dec 2011 11:37:22 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pBCGbMPL024030;
	Mon, 12 Dec 2011 11:37:22 -0500
Date: Mon, 12 Dec 2011 12:37:22 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Sergi Seira <s.seira@cdmon.com>
Message-ID: <20111212163722.GB23490@andromeda.dapyr.net>
References: <4ED5FFBC.3080605@cdmon.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4ED5FFBC.3080605@cdmon.com>
User-Agent: Mutt/1.5.9i
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] ext4_mb_generate_buddy remounting read-only on domU
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Nov 30, 2011 at 11:04:44AM +0100, Sergi Seira wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hi,
> 
> has anyone had ext4 filesystem remounting hours after a live-migration?
> 
> We've been having those 'read only remounts' always hours after a live-migration.
> The more load a domU has the faster we get 'read only remount'.
> We are suspecting something is getting corrupted after a live migration, and under load an error bumps:
> 
>  kernel: [3424760.190005] EXT4-fs error (device xvda3): ext4_mb_generate_buddy: EXT4-fs: group 55: 6102 blocks in bitmap, 6101 in gd
>  kernel: [3424760.190059] Aborting journal on device xvda3-8.
>  kernel: [3424760.191197] EXT4-fs (xvda3): Remounting filesystem read-only
>  kernel: [3424760.204396] EXT4-fs (xvda3): delayed block allocation failed for inode 374665 at logical offset 318 with max blocks 1 with error -30
>  kernel: [3424760.204447] This should not happen!!  Data will be lost
>  kernel: [3424760.204483] EXT4-fs (xvda3): ext4_da_writepages: jbd2_start: 1015 pages, ino 374665; err -30
> 
> We have to fsck the volume from dom0 before re-creating domU.
> 
> Our system runs on :
> 
>  dom0 debian6 2.6.32-5-xen-amd64

This looks familiar,
http://xen.1045712.n5.nabble.com/ext4-BUG-in-dom0-Kernel-2-6-32-36-td4773487.html

Ah no. There was some fix to blktap for this I think. What exactly is
the drivery you are using to drive the root/home/swap of the guest? Is
it blkback or blktap?


>  xen-hypervisor 4.0.1-2
> 
> DomU are:
> 
>  domU paravirtual debian6 2.6.32-5-xen-amd64
>  3 iscsi volumes act as vxda's, swap, root and home (400G)
>  7 vcpus
>  8 GB RAM
> 
> Regards,
> Sergi
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> 
> iQEcBAEBAgAGBQJO1f+8AAoJEN00VGSIizZ0zVIH/0KLyFgLAwJNmtXVbHo0VcsY
> IicYbcv5CJNkJZ/WDskPK/33HsWH98epWzsRbr33qAibZrKfJig/1HuHs8SwGwGe
> Xt1ii9+gnhy/oyNSnPbgmDpD6W81iEPkCTLm0fdHmndP9E5dbIWOzCMcIMvFB0RD
> +2bPKQ3CcKEqnbXcriYzKVdfU2Y4/UbgZJYCQBJizK20A9KbqwAyLve/zRxJ7WP8
> Q7+zWXkxefwcVq9rcBfkITvlrLQw9b9kK1KT7+7MrnxkG0ujIFYKVqkBxuIb4C3u
> kILnz8Gh6vuiKhHy+5DKqEpGmhSsq/VVymLQCNerveluer2TF9QOTisv2kXw58Y=
> =+hQj
> -----END PGP SIGNATURE-----
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 16:38:56 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 16: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.xensource.com>)
	id 1Ra8tk-0004Zt-3y; Mon, 12 Dec 2011 16:38:40 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1Ra8th-0004Z7-RJ
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 16:38:38 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-15.tower-21.messagelabs.com!1323707862!7905362!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25851 invoked from network); 12 Dec 2011 16:37:43 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-15.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 12 Dec 2011 16:37:43 -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
	pBCGWUYv023774
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Mon, 12 Dec 2011 11:32:30 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pBCGWTvB023772;
	Mon, 12 Dec 2011 11:32:29 -0500
Date: Mon, 12 Dec 2011 12:32:29 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Jean Guyader <jean.guyader@eu.citrix.com>
Message-ID: <20111212163229.GA23490@andromeda.dapyr.net>
References: <1322411006-12629-1-git-send-email-jean.guyader@eu.citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1322411006-12629-1-git-send-email-jean.guyader@eu.citrix.com>
User-Agent: Mutt/1.5.9i
Cc: allen.m.kay@intel.com, xen-devel@lists.xensource.com,
	Ian.Jackson@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH] qemu-xen: Intel GPU passthrough,
	fix OpRegion mapping.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Sun, Nov 27, 2011 at 04:23:26PM +0000, Jean Guyader wrote:
> 
> The OpRegion shouldn't be mapped 1:1 because the address in the host
> can't be used in the guest directly.
> 
> This patch traps read and write access to the opregion of the Intel
> GPU config space (offset 0xfc).


> 
> To work correctly this patch needs a change in hvmloader.
> 
> HVMloader will allocate 2 pages for the OpRegion and write this address
> on the config space of the Intel GPU. Qemu will trap and map the host
> OpRegion to the guest. Any write to this offset after that won't have
> any effect. Any read of this config space offset will return the address
> in the guest.
> 
> Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
> ---
>  hw/pass-through.c |    8 ++--
>  hw/pass-through.h |    4 ++
>  hw/pt-graphics.c  |   96 ++++++++++++++++++++++++++++++++++++++++++----------
>  3 files changed, 85 insertions(+), 23 deletions(-)
> 

> diff --git a/hw/pass-through.c b/hw/pass-through.c
> index 919937f..976d28f 100644
> --- a/hw/pass-through.c
> +++ b/hw/pass-through.c
> @@ -1455,8 +1455,7 @@ out:
>      return index;
>  }
>  
> -static void pt_pci_write_config(PCIDevice *d, uint32_t address, uint32_t val,
> -                                int len)
> +void pt_pci_write_config(PCIDevice *d, uint32_t address, uint32_t val, int len)
>  {
>      struct pt_dev *assigned_device = (struct pt_dev *)d;
>      struct pci_dev *pci_dev = assigned_device->pci_dev;
> @@ -1637,7 +1636,7 @@ exit:
>      return;
>  }
>  
> -static uint32_t pt_pci_read_config(PCIDevice *d, uint32_t address, int len)
> +uint32_t pt_pci_read_config(PCIDevice *d, uint32_t address, int len)
>  {
>      struct pt_dev *assigned_device = (struct pt_dev *)d;
>      struct pci_dev *pci_dev = assigned_device->pci_dev;
> @@ -4191,7 +4190,8 @@ static struct pt_dev * register_real_device(PCIBus *e_bus,
>      /* Register device */
>      assigned_device = (struct pt_dev *) pci_register_device(e_bus, e_dev_name,
>                                  sizeof(struct pt_dev), e_devfn,
> -                                pt_pci_read_config, pt_pci_write_config);
> +                                gfx_passthru ? vgapt_pci_read_config : pt_pci_read_config,
> +                                gfx_passthru ? vgapt_pci_write_config : pt_pci_write_config);
>      if ( assigned_device == NULL )
>      {
>          PT_LOG("Error: couldn't register real device\n");
> diff --git a/hw/pass-through.h b/hw/pass-through.h
> index 884139c..c898c7c 100644
> --- a/hw/pass-through.h
> +++ b/hw/pass-through.h
> @@ -422,6 +422,10 @@ PCIBus *intel_pci_bridge_init(PCIBus *bus, int devfn, uint16_t vid,
>             uint16_t did, const char *name, uint16_t revision);
>  void igd_pci_write(PCIDevice *pci_dev, uint32_t config_addr, uint32_t val, int len);
>  uint32_t igd_pci_read(PCIDevice *pci_dev, uint32_t config_addr, int len);
> +void vgapt_pci_write_config(PCIDevice *pci_dev, uint32_t config_addr, uint32_t val, int len);
> +uint32_t vgapt_pci_read_config(PCIDevice *pci_dev, uint32_t config_addr, int len);
> +uint32_t pt_pci_read_config(PCIDevice *d, uint32_t address, int len);
> +void pt_pci_write_config(PCIDevice *d, uint32_t address, uint32_t val, int len);
>  
>  #endif /* __PASSTHROUGH_H__ */
>  
> diff --git a/hw/pt-graphics.c b/hw/pt-graphics.c
> index fec7390..33cbff5 100644
> --- a/hw/pt-graphics.c
> +++ b/hw/pt-graphics.c
> @@ -13,6 +13,8 @@
>  extern int gfx_passthru;
>  extern int igd_passthru;
>  
> +static uint32_t igd_guest_opregion = 0;
> +
>  static int pch_map_irq(PCIDevice *pci_dev, int irq_num)
>  {
>      PT_LOG("pch_map_irq called\n");
> @@ -37,6 +39,77 @@ void intel_pch_init(PCIBus *bus)
>                          pch_map_irq, "intel_bridge_1f");
>  }
>  
> +static void igd_write_opregion(PCIDevice *pci_dev, uint32_t val, int len)
> +{
> +    struct pt_dev *real_dev = (struct pt_dev *)pci_dev;
> +    uint32_t host_opregion = 0;
> +    int ret;
> +
> +    if ( igd_guest_opregion || len != 4 )
> +        return;
> +
> +    host_opregion = pt_pci_host_read(real_dev->pci_dev,
> +            PCI_INTEL_OPREGION, len);

The tabs here are a bit weird.
> +    igd_guest_opregion = (val & ~0xfff) | (host_opregion & 0xfff);
> +    PT_LOG("Map OpRegion: %x -> %x\n", host_opregion, igd_guest_opregion);
> +
> +    ret = xc_domain_memory_mapping(xc_handle, domid,
> +            igd_guest_opregion >> XC_PAGE_SHIFT,
> +            host_opregion >> XC_PAGE_SHIFT,
> +            2,
> +            DPCI_ADD_MAPPING);
> +

Shouldn't you unmap the older region first?

> +    if ( ret != 0 )
> +    {
> +        PT_LOG("Error: Can't map opregion\n");
> +        igd_guest_opregion = 0;
> +    }
> +}
> +
> +void vgapt_pci_write_config(PCIDevice *pci_dev, uint32_t config_addr, uint32_t val, int len)
> +{
> +#ifdef PT_DEBUG_PCI_CONFIG_ACCESS
> +    PT_LOG("vgapt_pci_write_config: %x:%x.%x: addr=%x len=%x val=%x\n",
> +            pci_bus_num(pci_dev->bus), PCI_SLOT(pci_dev->devfn),
> +            PCI_FUNC(pci_dev->devfn), config_addr, len, val);
> +#endif
> +
> +    if ( igd_passthru )
> +    {
> +        switch ( config_addr )
> +        {
> +            case 0xfc : /* Opregion */
> +                igd_write_opregion(pci_dev, val, len);
> +                return;

No default case? I would think the compiler would throw a fit for that.

> +        }
> +    }
> +
> +    pt_pci_write_config(pci_dev, config_addr, val, len);
> +}
> +
> +uint32_t vgapt_pci_read_config(PCIDevice *pci_dev, uint32_t config_addr, int len)
> +{
> +    uint32_t val;
> +
> +    val = pt_pci_read_config(pci_dev, config_addr, len);
> +
> +    if ( igd_passthru )
> +    {
> +        switch ( config_addr )
> +        {
> +            case 0xfc: /* OpRegion */
> +                if ( igd_guest_opregion )
> +                    val = igd_guest_opregion;
> +                break;
> +        }
> +    }
> +#ifdef PT_DEBUG_PCI_CONFIG_ACCESS
> +    PT_LOG_DEV(pci_dev, "vgapt_pci_read_config: %x:%x.%x: addr=%x len=%x val=%x\n",
> +            config_addr, len, val);
> +#endif
> +    return val;
> +}
> +
>  void igd_pci_write(PCIDevice *pci_dev, uint32_t config_addr, uint32_t val, int len)
>  {
>      struct pci_dev *pci_dev_host_bridge = pt_pci_get_dev(0, 0, 0);
> @@ -99,7 +172,6 @@ uint32_t igd_pci_read(PCIDevice *pci_dev, uint32_t config_addr, int len)
>  int register_vga_regions(struct pt_dev *real_device)
>  {
>      u16 vendor_id;
> -    int igd_opregion;
>      int ret = 0;
>  
>      if ( !gfx_passthru || real_device->pci_dev->device_class != 0x0300 )
> @@ -117,19 +189,6 @@ int register_vga_regions(struct pt_dev *real_device)
>              0x20,
>              DPCI_ADD_MAPPING);
>  
> -    /* 1:1 map ASL Storage register value */
> -    vendor_id = pt_pci_host_read(real_device->pci_dev, 0, 2);
> -    igd_opregion = pt_pci_host_read(real_device->pci_dev, PCI_INTEL_OPREGION, 4);
> -    if ( (vendor_id == PCI_VENDOR_ID_INTEL ) && igd_opregion )
> -    {
> -        ret |= xc_domain_memory_mapping(xc_handle, domid,
> -                igd_opregion >> XC_PAGE_SHIFT,
> -                igd_opregion >> XC_PAGE_SHIFT,
> -                2,
> -                DPCI_ADD_MAPPING);
> -        PT_LOG("register_vga: igd_opregion = %x\n", igd_opregion);
> -    }
> -
>      if ( ret != 0 )
>          PT_LOG("VGA region mapping failed\n");
>  
> @@ -141,7 +200,7 @@ int register_vga_regions(struct pt_dev *real_device)
>   */
>  int unregister_vga_regions(struct pt_dev *real_device)
>  {
> -    u32 vendor_id, igd_opregion;
> +    u32 vendor_id;
>      int ret = 0;
>  
>      if ( !gfx_passthru || real_device->pci_dev->device_class != 0x0300 )
> @@ -160,12 +219,11 @@ int unregister_vga_regions(struct pt_dev *real_device)
>              DPCI_REMOVE_MAPPING);
>  
>      vendor_id = pt_pci_host_read(real_device->pci_dev, PCI_VENDOR_ID, 2);
> -    igd_opregion = pt_pci_host_read(real_device->pci_dev, PCI_INTEL_OPREGION, 4);
> -    if ( (vendor_id == PCI_VENDOR_ID_INTEL) && igd_opregion )
> +    if ( (vendor_id == PCI_VENDOR_ID_INTEL) && igd_guest_opregion )
>      {
>          ret |= xc_domain_memory_mapping(xc_handle, domid,
> -                igd_opregion >> XC_PAGE_SHIFT,
> -                igd_opregion >> XC_PAGE_SHIFT,
> +                igd_guest_opregion >> XC_PAGE_SHIFT,
> +                igd_guest_opregion >> XC_PAGE_SHIFT,
>                  2,
>                  DPCI_REMOVE_MAPPING);
>      }

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 16:38:56 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 16: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.xensource.com>)
	id 1Ra8tk-0004Zt-3y; Mon, 12 Dec 2011 16:38:40 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1Ra8th-0004Z7-RJ
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 16:38:38 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-15.tower-21.messagelabs.com!1323707862!7905362!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25851 invoked from network); 12 Dec 2011 16:37:43 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-15.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 12 Dec 2011 16:37:43 -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
	pBCGWUYv023774
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Mon, 12 Dec 2011 11:32:30 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pBCGWTvB023772;
	Mon, 12 Dec 2011 11:32:29 -0500
Date: Mon, 12 Dec 2011 12:32:29 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Jean Guyader <jean.guyader@eu.citrix.com>
Message-ID: <20111212163229.GA23490@andromeda.dapyr.net>
References: <1322411006-12629-1-git-send-email-jean.guyader@eu.citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1322411006-12629-1-git-send-email-jean.guyader@eu.citrix.com>
User-Agent: Mutt/1.5.9i
Cc: allen.m.kay@intel.com, xen-devel@lists.xensource.com,
	Ian.Jackson@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH] qemu-xen: Intel GPU passthrough,
	fix OpRegion mapping.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Sun, Nov 27, 2011 at 04:23:26PM +0000, Jean Guyader wrote:
> 
> The OpRegion shouldn't be mapped 1:1 because the address in the host
> can't be used in the guest directly.
> 
> This patch traps read and write access to the opregion of the Intel
> GPU config space (offset 0xfc).


> 
> To work correctly this patch needs a change in hvmloader.
> 
> HVMloader will allocate 2 pages for the OpRegion and write this address
> on the config space of the Intel GPU. Qemu will trap and map the host
> OpRegion to the guest. Any write to this offset after that won't have
> any effect. Any read of this config space offset will return the address
> in the guest.
> 
> Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
> ---
>  hw/pass-through.c |    8 ++--
>  hw/pass-through.h |    4 ++
>  hw/pt-graphics.c  |   96 ++++++++++++++++++++++++++++++++++++++++++----------
>  3 files changed, 85 insertions(+), 23 deletions(-)
> 

> diff --git a/hw/pass-through.c b/hw/pass-through.c
> index 919937f..976d28f 100644
> --- a/hw/pass-through.c
> +++ b/hw/pass-through.c
> @@ -1455,8 +1455,7 @@ out:
>      return index;
>  }
>  
> -static void pt_pci_write_config(PCIDevice *d, uint32_t address, uint32_t val,
> -                                int len)
> +void pt_pci_write_config(PCIDevice *d, uint32_t address, uint32_t val, int len)
>  {
>      struct pt_dev *assigned_device = (struct pt_dev *)d;
>      struct pci_dev *pci_dev = assigned_device->pci_dev;
> @@ -1637,7 +1636,7 @@ exit:
>      return;
>  }
>  
> -static uint32_t pt_pci_read_config(PCIDevice *d, uint32_t address, int len)
> +uint32_t pt_pci_read_config(PCIDevice *d, uint32_t address, int len)
>  {
>      struct pt_dev *assigned_device = (struct pt_dev *)d;
>      struct pci_dev *pci_dev = assigned_device->pci_dev;
> @@ -4191,7 +4190,8 @@ static struct pt_dev * register_real_device(PCIBus *e_bus,
>      /* Register device */
>      assigned_device = (struct pt_dev *) pci_register_device(e_bus, e_dev_name,
>                                  sizeof(struct pt_dev), e_devfn,
> -                                pt_pci_read_config, pt_pci_write_config);
> +                                gfx_passthru ? vgapt_pci_read_config : pt_pci_read_config,
> +                                gfx_passthru ? vgapt_pci_write_config : pt_pci_write_config);
>      if ( assigned_device == NULL )
>      {
>          PT_LOG("Error: couldn't register real device\n");
> diff --git a/hw/pass-through.h b/hw/pass-through.h
> index 884139c..c898c7c 100644
> --- a/hw/pass-through.h
> +++ b/hw/pass-through.h
> @@ -422,6 +422,10 @@ PCIBus *intel_pci_bridge_init(PCIBus *bus, int devfn, uint16_t vid,
>             uint16_t did, const char *name, uint16_t revision);
>  void igd_pci_write(PCIDevice *pci_dev, uint32_t config_addr, uint32_t val, int len);
>  uint32_t igd_pci_read(PCIDevice *pci_dev, uint32_t config_addr, int len);
> +void vgapt_pci_write_config(PCIDevice *pci_dev, uint32_t config_addr, uint32_t val, int len);
> +uint32_t vgapt_pci_read_config(PCIDevice *pci_dev, uint32_t config_addr, int len);
> +uint32_t pt_pci_read_config(PCIDevice *d, uint32_t address, int len);
> +void pt_pci_write_config(PCIDevice *d, uint32_t address, uint32_t val, int len);
>  
>  #endif /* __PASSTHROUGH_H__ */
>  
> diff --git a/hw/pt-graphics.c b/hw/pt-graphics.c
> index fec7390..33cbff5 100644
> --- a/hw/pt-graphics.c
> +++ b/hw/pt-graphics.c
> @@ -13,6 +13,8 @@
>  extern int gfx_passthru;
>  extern int igd_passthru;
>  
> +static uint32_t igd_guest_opregion = 0;
> +
>  static int pch_map_irq(PCIDevice *pci_dev, int irq_num)
>  {
>      PT_LOG("pch_map_irq called\n");
> @@ -37,6 +39,77 @@ void intel_pch_init(PCIBus *bus)
>                          pch_map_irq, "intel_bridge_1f");
>  }
>  
> +static void igd_write_opregion(PCIDevice *pci_dev, uint32_t val, int len)
> +{
> +    struct pt_dev *real_dev = (struct pt_dev *)pci_dev;
> +    uint32_t host_opregion = 0;
> +    int ret;
> +
> +    if ( igd_guest_opregion || len != 4 )
> +        return;
> +
> +    host_opregion = pt_pci_host_read(real_dev->pci_dev,
> +            PCI_INTEL_OPREGION, len);

The tabs here are a bit weird.
> +    igd_guest_opregion = (val & ~0xfff) | (host_opregion & 0xfff);
> +    PT_LOG("Map OpRegion: %x -> %x\n", host_opregion, igd_guest_opregion);
> +
> +    ret = xc_domain_memory_mapping(xc_handle, domid,
> +            igd_guest_opregion >> XC_PAGE_SHIFT,
> +            host_opregion >> XC_PAGE_SHIFT,
> +            2,
> +            DPCI_ADD_MAPPING);
> +

Shouldn't you unmap the older region first?

> +    if ( ret != 0 )
> +    {
> +        PT_LOG("Error: Can't map opregion\n");
> +        igd_guest_opregion = 0;
> +    }
> +}
> +
> +void vgapt_pci_write_config(PCIDevice *pci_dev, uint32_t config_addr, uint32_t val, int len)
> +{
> +#ifdef PT_DEBUG_PCI_CONFIG_ACCESS
> +    PT_LOG("vgapt_pci_write_config: %x:%x.%x: addr=%x len=%x val=%x\n",
> +            pci_bus_num(pci_dev->bus), PCI_SLOT(pci_dev->devfn),
> +            PCI_FUNC(pci_dev->devfn), config_addr, len, val);
> +#endif
> +
> +    if ( igd_passthru )
> +    {
> +        switch ( config_addr )
> +        {
> +            case 0xfc : /* Opregion */
> +                igd_write_opregion(pci_dev, val, len);
> +                return;

No default case? I would think the compiler would throw a fit for that.

> +        }
> +    }
> +
> +    pt_pci_write_config(pci_dev, config_addr, val, len);
> +}
> +
> +uint32_t vgapt_pci_read_config(PCIDevice *pci_dev, uint32_t config_addr, int len)
> +{
> +    uint32_t val;
> +
> +    val = pt_pci_read_config(pci_dev, config_addr, len);
> +
> +    if ( igd_passthru )
> +    {
> +        switch ( config_addr )
> +        {
> +            case 0xfc: /* OpRegion */
> +                if ( igd_guest_opregion )
> +                    val = igd_guest_opregion;
> +                break;
> +        }
> +    }
> +#ifdef PT_DEBUG_PCI_CONFIG_ACCESS
> +    PT_LOG_DEV(pci_dev, "vgapt_pci_read_config: %x:%x.%x: addr=%x len=%x val=%x\n",
> +            config_addr, len, val);
> +#endif
> +    return val;
> +}
> +
>  void igd_pci_write(PCIDevice *pci_dev, uint32_t config_addr, uint32_t val, int len)
>  {
>      struct pci_dev *pci_dev_host_bridge = pt_pci_get_dev(0, 0, 0);
> @@ -99,7 +172,6 @@ uint32_t igd_pci_read(PCIDevice *pci_dev, uint32_t config_addr, int len)
>  int register_vga_regions(struct pt_dev *real_device)
>  {
>      u16 vendor_id;
> -    int igd_opregion;
>      int ret = 0;
>  
>      if ( !gfx_passthru || real_device->pci_dev->device_class != 0x0300 )
> @@ -117,19 +189,6 @@ int register_vga_regions(struct pt_dev *real_device)
>              0x20,
>              DPCI_ADD_MAPPING);
>  
> -    /* 1:1 map ASL Storage register value */
> -    vendor_id = pt_pci_host_read(real_device->pci_dev, 0, 2);
> -    igd_opregion = pt_pci_host_read(real_device->pci_dev, PCI_INTEL_OPREGION, 4);
> -    if ( (vendor_id == PCI_VENDOR_ID_INTEL ) && igd_opregion )
> -    {
> -        ret |= xc_domain_memory_mapping(xc_handle, domid,
> -                igd_opregion >> XC_PAGE_SHIFT,
> -                igd_opregion >> XC_PAGE_SHIFT,
> -                2,
> -                DPCI_ADD_MAPPING);
> -        PT_LOG("register_vga: igd_opregion = %x\n", igd_opregion);
> -    }
> -
>      if ( ret != 0 )
>          PT_LOG("VGA region mapping failed\n");
>  
> @@ -141,7 +200,7 @@ int register_vga_regions(struct pt_dev *real_device)
>   */
>  int unregister_vga_regions(struct pt_dev *real_device)
>  {
> -    u32 vendor_id, igd_opregion;
> +    u32 vendor_id;
>      int ret = 0;
>  
>      if ( !gfx_passthru || real_device->pci_dev->device_class != 0x0300 )
> @@ -160,12 +219,11 @@ int unregister_vga_regions(struct pt_dev *real_device)
>              DPCI_REMOVE_MAPPING);
>  
>      vendor_id = pt_pci_host_read(real_device->pci_dev, PCI_VENDOR_ID, 2);
> -    igd_opregion = pt_pci_host_read(real_device->pci_dev, PCI_INTEL_OPREGION, 4);
> -    if ( (vendor_id == PCI_VENDOR_ID_INTEL) && igd_opregion )
> +    if ( (vendor_id == PCI_VENDOR_ID_INTEL) && igd_guest_opregion )
>      {
>          ret |= xc_domain_memory_mapping(xc_handle, domid,
> -                igd_opregion >> XC_PAGE_SHIFT,
> -                igd_opregion >> XC_PAGE_SHIFT,
> +                igd_guest_opregion >> XC_PAGE_SHIFT,
> +                igd_guest_opregion >> XC_PAGE_SHIFT,
>                  2,
>                  DPCI_REMOVE_MAPPING);
>      }

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 16:38:56 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 16: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.xensource.com>)
	id 1Ra8th-0004ZT-ML; Mon, 12 Dec 2011 16:38:37 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Ra8tg-0004ZI-5i
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 16:38:36 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1323707833!56355056!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDc4NQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1166 invoked from network); 12 Dec 2011 16:37:13 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Dec 2011 16:37:13 -0000
X-IronPort-AV: E=Sophos;i="4.71,339,1320624000"; 
   d="scan'208";a="9423422"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Dec 2011 16:37:47 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 12 Dec 2011 16:37:47 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Ra8ss-0008MD-T6; Mon, 12 Dec 2011 16:37:46 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Ra8ss-0006Gd-S8;
	Mon, 12 Dec 2011 16:37:46 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20198.11738.646611.204591@mariner.uk.xensource.com>
Date: Mon, 12 Dec 2011 16:37:46 +0000
To: xen-devel@lists.xensource.com
Cc: Lars Kurth <lars.kurth@citrix.com>
Subject: [Xen-devel] Security vulnerability process - confirmed
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

It's time we made this policy official.  There was only one change to
make during "last call" discussion, and with that I think we have
consensus.

Changes from the final draft:

  * Increase the standard embargo period from one week to two,
    as discussed in the last call.

The final version, below, will go on the xen.org website shortly.

Thanks,
Ian.

            xen.org security problem response process
            -----------------------------------------

Introduction
------------

Computer systems have bugs.  Currently recognised best practice for
bugs with security implications is to notify significant downstream
users in private; leave a reasonable interval for downstreams to
respond and prepare updated software packages; then make public
disclosure.

We want to encourage people to report bugs they find to us.  Therefore
we will treat with respect the requests of discoverers, or other
vendors, who report problems to us.


Specific process
----------------

1. We request that anyone who discovers a vulnerability in xen.org
   software reports this by email to security (at) xen (dot) org.

   (This also covers the situation where an existing published
   changeset is retrospectively found to be a security fix.)

2. Immediately, and in parallel:

   (a) Those of us on the xen.org team who are aware of the problem
       will notify security@xen if disclosure wasn't made there
       already.

   (b) If the vulnerability is not already public, security@xen will
       negotiate with discoverer regarding embargo date and disclosure
       schedule.  See below for detailed discussion.

3. Furthermore, also in parallel:

   (c) security@xen will check whether the discoverer, or other people
       already aware of the problem, have allocated a CVE number.  If
       not, we will acquire a CVE candidate number ourselves, and
       make sure that everyone who is aware of the problem is also
       aware of the CVE number.

   (d) If we think other software systems (for example, competing
       hypervisor systems) are likely to be affected by the same
       vulnerability, we will try to make those other projects aware
       of the problem and include them in the advisory preparation
       process.  (This may rely on the other project(s) having
       documented and responsive security contact points.)

   (e) We will prepare or check patch(es) which fix the vulnerability.
       This would ideally include all relevant backports.

   (f) We will determine which systems/configurations/versions are
       vulnerable, and what the impact of the vulnerability is.
       Depending on the nature of the vulnerability this may involve
       sharing information about the vulnerability (in confidence, if
       the issue is embargoed) with hardware vendors and/or other
       software projects.

   (g) We will write a Xen advisory including information from (b)-(f)

2. Advisory pre-release:

   This occurs only if the advisory is embargoed (ie, the problem is
   not already public):

   As soon as our advisory is available, we will send it,
   including patches, to members of the Xen security pre-disclosure
   list.  For more information about this list, see below.

   At this stage the advisory will be clearly marked with the embargo
   date.

3. Advisory public release:

   At the embargo date we will publish the advisory, and push
   bugfix changesets to public revision control trees.

   Public advisories will be posted to xen-devel.

   Copies will also be sent to the pre-disclosure list, unless
   the advisory was already sent there previously during the embargo
   period and has not been updated since.

4. Updates

   If new information or better patches become available, or we
   discover mistakes, we may issue an amended (revision 2 or later)
   public advisory.  This will also be sent to the pre-disclosure
   list.


Embargo and disclosure schedule
-------------------------------

If a vulnerability is not already public, we would like to notify
significant distributors and operators of Xen so that they can prepare
patched software in advance.  This will help minimise the degree to
which there are Xen users who are vulnerable but can't get patches.

As discussed, we will negotiate with discoverers about disclosure
schedule.  Our usual starting point for that negotiation, unless there
are reasons to diverge from this, would be:

  1. One working week between notification arriving at security@xen
     and the issue of our own advisory to our predisclosure list.  We
     will use this time to gather information and prepare our
     advisory, including required patches.

  2. Two working weeks between issue of our advisory to our
     predisclosure list and publication.

When a discoverer reports a problem to us and requests longer delays
than we would consider ideal, we will honour such a request if
reasonable.  If a discoverer wants an accelerated disclosure compared
to what we would prefer, we naturally do not have the power to insist
that a discoverer waits for us to be ready and will honour the date
specified by the discoverer.

Naturally, if a vulnerability is being exploited in the wild we will
make immediately public release of the advisory and patch(es) and
expect others to do likewise.


Pre-disclosure list
-------------------

Xen.org operates a pre-disclosure list.  This list contains the email
addresses (ideally, role addresses) of the security response teams for
significant Xen operators and distributors.

This includes:
  - Large-scale hosting providers;
  - Large-scale organisational users of Xen;
  - Vendors of widely-deployed Xen-based systems;
  - Distributors of widely-deployed operating systems with Xen support.
This includes both corporations and community institutions.

Here as a rule of thumb "large scale" and "widely deployed" means an
installed base of 300,000 or more Xen guests; other well-established
organisations with a mature security response process will be
considered on a case-by-case basis.

The list of entities on the pre-disclosure list is public.  (Just the
list of projects and organisations, not the actual email addresses.)

Pre-disclosure list members are expected to maintain the
confidentiality of the vulnerability up to the embargo date which
security@xen have agreed with the discoverer.

Specifically, prior to the embargo date, pre-disclosure list members
should not make available, even to their own customers and partners:
 - the Xen.org advisory
 - their own advisory
 - revision control commits which are a fix for the problem
 - patched software (even in binary form)
without prior consultation with security@xen and/or the discoverer.

Organisations who meet the criteria should contact security@xen if
they wish to receive pre-disclosure of advisories.

The pre-disclosure list will also receive copies of public advisories
when they are first issued or updated.

-- 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 16:38:56 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 16: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.xensource.com>)
	id 1Ra8th-0004ZT-ML; Mon, 12 Dec 2011 16:38:37 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Ra8tg-0004ZI-5i
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 16:38:36 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1323707833!56355056!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDc4NQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1166 invoked from network); 12 Dec 2011 16:37:13 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Dec 2011 16:37:13 -0000
X-IronPort-AV: E=Sophos;i="4.71,339,1320624000"; 
   d="scan'208";a="9423422"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Dec 2011 16:37:47 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 12 Dec 2011 16:37:47 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Ra8ss-0008MD-T6; Mon, 12 Dec 2011 16:37:46 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Ra8ss-0006Gd-S8;
	Mon, 12 Dec 2011 16:37:46 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20198.11738.646611.204591@mariner.uk.xensource.com>
Date: Mon, 12 Dec 2011 16:37:46 +0000
To: xen-devel@lists.xensource.com
Cc: Lars Kurth <lars.kurth@citrix.com>
Subject: [Xen-devel] Security vulnerability process - confirmed
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

It's time we made this policy official.  There was only one change to
make during "last call" discussion, and with that I think we have
consensus.

Changes from the final draft:

  * Increase the standard embargo period from one week to two,
    as discussed in the last call.

The final version, below, will go on the xen.org website shortly.

Thanks,
Ian.

            xen.org security problem response process
            -----------------------------------------

Introduction
------------

Computer systems have bugs.  Currently recognised best practice for
bugs with security implications is to notify significant downstream
users in private; leave a reasonable interval for downstreams to
respond and prepare updated software packages; then make public
disclosure.

We want to encourage people to report bugs they find to us.  Therefore
we will treat with respect the requests of discoverers, or other
vendors, who report problems to us.


Specific process
----------------

1. We request that anyone who discovers a vulnerability in xen.org
   software reports this by email to security (at) xen (dot) org.

   (This also covers the situation where an existing published
   changeset is retrospectively found to be a security fix.)

2. Immediately, and in parallel:

   (a) Those of us on the xen.org team who are aware of the problem
       will notify security@xen if disclosure wasn't made there
       already.

   (b) If the vulnerability is not already public, security@xen will
       negotiate with discoverer regarding embargo date and disclosure
       schedule.  See below for detailed discussion.

3. Furthermore, also in parallel:

   (c) security@xen will check whether the discoverer, or other people
       already aware of the problem, have allocated a CVE number.  If
       not, we will acquire a CVE candidate number ourselves, and
       make sure that everyone who is aware of the problem is also
       aware of the CVE number.

   (d) If we think other software systems (for example, competing
       hypervisor systems) are likely to be affected by the same
       vulnerability, we will try to make those other projects aware
       of the problem and include them in the advisory preparation
       process.  (This may rely on the other project(s) having
       documented and responsive security contact points.)

   (e) We will prepare or check patch(es) which fix the vulnerability.
       This would ideally include all relevant backports.

   (f) We will determine which systems/configurations/versions are
       vulnerable, and what the impact of the vulnerability is.
       Depending on the nature of the vulnerability this may involve
       sharing information about the vulnerability (in confidence, if
       the issue is embargoed) with hardware vendors and/or other
       software projects.

   (g) We will write a Xen advisory including information from (b)-(f)

2. Advisory pre-release:

   This occurs only if the advisory is embargoed (ie, the problem is
   not already public):

   As soon as our advisory is available, we will send it,
   including patches, to members of the Xen security pre-disclosure
   list.  For more information about this list, see below.

   At this stage the advisory will be clearly marked with the embargo
   date.

3. Advisory public release:

   At the embargo date we will publish the advisory, and push
   bugfix changesets to public revision control trees.

   Public advisories will be posted to xen-devel.

   Copies will also be sent to the pre-disclosure list, unless
   the advisory was already sent there previously during the embargo
   period and has not been updated since.

4. Updates

   If new information or better patches become available, or we
   discover mistakes, we may issue an amended (revision 2 or later)
   public advisory.  This will also be sent to the pre-disclosure
   list.


Embargo and disclosure schedule
-------------------------------

If a vulnerability is not already public, we would like to notify
significant distributors and operators of Xen so that they can prepare
patched software in advance.  This will help minimise the degree to
which there are Xen users who are vulnerable but can't get patches.

As discussed, we will negotiate with discoverers about disclosure
schedule.  Our usual starting point for that negotiation, unless there
are reasons to diverge from this, would be:

  1. One working week between notification arriving at security@xen
     and the issue of our own advisory to our predisclosure list.  We
     will use this time to gather information and prepare our
     advisory, including required patches.

  2. Two working weeks between issue of our advisory to our
     predisclosure list and publication.

When a discoverer reports a problem to us and requests longer delays
than we would consider ideal, we will honour such a request if
reasonable.  If a discoverer wants an accelerated disclosure compared
to what we would prefer, we naturally do not have the power to insist
that a discoverer waits for us to be ready and will honour the date
specified by the discoverer.

Naturally, if a vulnerability is being exploited in the wild we will
make immediately public release of the advisory and patch(es) and
expect others to do likewise.


Pre-disclosure list
-------------------

Xen.org operates a pre-disclosure list.  This list contains the email
addresses (ideally, role addresses) of the security response teams for
significant Xen operators and distributors.

This includes:
  - Large-scale hosting providers;
  - Large-scale organisational users of Xen;
  - Vendors of widely-deployed Xen-based systems;
  - Distributors of widely-deployed operating systems with Xen support.
This includes both corporations and community institutions.

Here as a rule of thumb "large scale" and "widely deployed" means an
installed base of 300,000 or more Xen guests; other well-established
organisations with a mature security response process will be
considered on a case-by-case basis.

The list of entities on the pre-disclosure list is public.  (Just the
list of projects and organisations, not the actual email addresses.)

Pre-disclosure list members are expected to maintain the
confidentiality of the vulnerability up to the embargo date which
security@xen have agreed with the discoverer.

Specifically, prior to the embargo date, pre-disclosure list members
should not make available, even to their own customers and partners:
 - the Xen.org advisory
 - their own advisory
 - revision control commits which are a fix for the problem
 - patched software (even in binary form)
without prior consultation with security@xen and/or the discoverer.

Organisations who meet the criteria should contact security@xen if
they wish to receive pre-disclosure of advisories.

The pre-disclosure list will also receive copies of public advisories
when they are first issued or updated.

-- 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 16:45:30 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 16:45:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ra8zu-00051t-0n; Mon, 12 Dec 2011 16:45:02 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <xen-devel.GarveyPatrickD@OrdinaryAmerican.net>)
	id 1Ra8zt-00051M-47
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 16:45:01 +0000
X-Env-Sender: xen-devel.GarveyPatrickD@OrdinaryAmerican.net
X-Msg-Ref: server-15.tower-216.messagelabs.com!1323708247!7126008!1
X-Originating-IP: [216.75.62.102]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27709 invoked from network); 12 Dec 2011 16:44:07 -0000
Received: from gourmet7.spamgourmet.com (HELO gourmet8.spamgourmet.com)
	(216.75.62.102) by server-15.tower-216.messagelabs.com with SMTP;
	12 Dec 2011 16:44:07 -0000
Received: from spamgourmet by gourmet7.spamgourmet.com with local (Exim 4.69)
	(envelope-from <xen-devel.GarveyPatrickD@OrdinaryAmerican.net>)
	id 1Ra8z0-00038H-Kg
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 16:44:06 +0000
Received: from mail-gx0-f176.google.com ([209.85.161.176])
	by gourmet7.spamgourmet.com with esmtp (Exim 4.69)
	(envelope-from <xen-devel.GarveyPatrickD@OrdinaryAmerican.net>)
	id 1Ra8z0-00037U-9V for
	+xen-devel+GarveyPatrickD+fbe7693c78.xen-devel#lists.xensource.com@spamgourmet.com;
	Mon, 12 Dec 2011 16:44:06 +0000
Received: by ggnr4 with SMTP id r4so3205286ggn.7 for
	<+xen-devel+GarveyPatrickD+fbe7693c78.xen-devel#lists.xensource.com@spamgourmet.com>;
	Mon, 12 Dec 2011 08:44:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:content-type; bh=/nLoYX21pZQ4+x8qncac/8hwzAfZs2wMPzeG6sXUVgw=;
	b=R/V0cu+odjJ4l4mBNminbFgZ9nzhmQBACXrza2WBhejTezFoagAHoAYmgGlGu4Dpa4
	ZyYunCkzWRZUNuJKKkxc2mPsO2Ax98pWnEPCm1wQEdCb0cLuXIk0K5gbFW92x3whSUxi
	SxIIyHKdWqBtwvfE0gGHM+zhH2pTXQzb8O+ko=
MIME-Version: 1.0
Received: by 10.182.49.1 with SMTP id q1mr3111378obn.48.1323708245717; Mon, 12
	Dec 2011 08:44:05 -0800 (PST)
Received: by 10.182.35.167 with HTTP; Mon, 12 Dec 2011 08:44:05 -0800 (PST)
In-Reply-To: <20198.3859.619446.718758@mariner.uk.xensource.com>
References: <CACm5R6Sv2isGevS-gzprj6w0qnbKehpbC5=ai16zh29oty7jLg@mail.gmail.com>
	<20198.3859.619446.718758@mariner.uk.xensource.com>
Date: Mon, 12 Dec 2011 08:44:05 -0800
Message-ID: <CACm5R6T_wT1jYc_eptfiAURXZ85QXTuLfyvP_867Rm4qPbtPZQ@mail.gmail.com>
From: xen-devel.GarveyPatrickD@OrdinaryAmerican.net
To: xen-devel@lists.xensource.com
X-Spamgourmet: 
Subject: Re: [Xen-devel] Xen Wiki Spaceflight page
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Dec 12, 2011 at 6:26 AM, Ian Jackson -
Ian.Jackson@eu.citrix.com
<+xen-devel+garveypatrickd+1e8028805c.Ian.Jackson#eu.citrix.com@spamgourmet.com>
wrote:
> xen-devel.GarveyPatrickD@OrdinaryAmerican.net writes ("[Xen-devel] Xen Wiki Spaceflight page"):
>> According to http://wiki.xen.org/wiki/Special:AllPages
>> there is a page http://wiki.xen.org/wiki/Spaceflight
>> When I use the link there is a redirection to
>> https://en.wikipedia.org/wiki/Spaceflight?rdfrom=http%3A%2F%2Fwiki.xen.org%2Fwiki%3Ftitle%3DSpaceflight%26redirect%3Dno
>>
>> Was http://wiki.xen.org/wiki/Spaceflight purposely created?
>> Is it needed in http://wiki.xen.org/wiki/
>> Can it be removed?
>
> I think it was a mistake (probably, an example which comes with the
> mediawiki installation) and have removed it.
>
> Ian.
>

Thank you.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 16:45:30 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 16:45:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ra8zu-00051t-0n; Mon, 12 Dec 2011 16:45:02 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <xen-devel.GarveyPatrickD@OrdinaryAmerican.net>)
	id 1Ra8zt-00051M-47
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 16:45:01 +0000
X-Env-Sender: xen-devel.GarveyPatrickD@OrdinaryAmerican.net
X-Msg-Ref: server-15.tower-216.messagelabs.com!1323708247!7126008!1
X-Originating-IP: [216.75.62.102]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27709 invoked from network); 12 Dec 2011 16:44:07 -0000
Received: from gourmet7.spamgourmet.com (HELO gourmet8.spamgourmet.com)
	(216.75.62.102) by server-15.tower-216.messagelabs.com with SMTP;
	12 Dec 2011 16:44:07 -0000
Received: from spamgourmet by gourmet7.spamgourmet.com with local (Exim 4.69)
	(envelope-from <xen-devel.GarveyPatrickD@OrdinaryAmerican.net>)
	id 1Ra8z0-00038H-Kg
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 16:44:06 +0000
Received: from mail-gx0-f176.google.com ([209.85.161.176])
	by gourmet7.spamgourmet.com with esmtp (Exim 4.69)
	(envelope-from <xen-devel.GarveyPatrickD@OrdinaryAmerican.net>)
	id 1Ra8z0-00037U-9V for
	+xen-devel+GarveyPatrickD+fbe7693c78.xen-devel#lists.xensource.com@spamgourmet.com;
	Mon, 12 Dec 2011 16:44:06 +0000
Received: by ggnr4 with SMTP id r4so3205286ggn.7 for
	<+xen-devel+GarveyPatrickD+fbe7693c78.xen-devel#lists.xensource.com@spamgourmet.com>;
	Mon, 12 Dec 2011 08:44:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:content-type; bh=/nLoYX21pZQ4+x8qncac/8hwzAfZs2wMPzeG6sXUVgw=;
	b=R/V0cu+odjJ4l4mBNminbFgZ9nzhmQBACXrza2WBhejTezFoagAHoAYmgGlGu4Dpa4
	ZyYunCkzWRZUNuJKKkxc2mPsO2Ax98pWnEPCm1wQEdCb0cLuXIk0K5gbFW92x3whSUxi
	SxIIyHKdWqBtwvfE0gGHM+zhH2pTXQzb8O+ko=
MIME-Version: 1.0
Received: by 10.182.49.1 with SMTP id q1mr3111378obn.48.1323708245717; Mon, 12
	Dec 2011 08:44:05 -0800 (PST)
Received: by 10.182.35.167 with HTTP; Mon, 12 Dec 2011 08:44:05 -0800 (PST)
In-Reply-To: <20198.3859.619446.718758@mariner.uk.xensource.com>
References: <CACm5R6Sv2isGevS-gzprj6w0qnbKehpbC5=ai16zh29oty7jLg@mail.gmail.com>
	<20198.3859.619446.718758@mariner.uk.xensource.com>
Date: Mon, 12 Dec 2011 08:44:05 -0800
Message-ID: <CACm5R6T_wT1jYc_eptfiAURXZ85QXTuLfyvP_867Rm4qPbtPZQ@mail.gmail.com>
From: xen-devel.GarveyPatrickD@OrdinaryAmerican.net
To: xen-devel@lists.xensource.com
X-Spamgourmet: 
Subject: Re: [Xen-devel] Xen Wiki Spaceflight page
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Dec 12, 2011 at 6:26 AM, Ian Jackson -
Ian.Jackson@eu.citrix.com
<+xen-devel+garveypatrickd+1e8028805c.Ian.Jackson#eu.citrix.com@spamgourmet.com>
wrote:
> xen-devel.GarveyPatrickD@OrdinaryAmerican.net writes ("[Xen-devel] Xen Wiki Spaceflight page"):
>> According to http://wiki.xen.org/wiki/Special:AllPages
>> there is a page http://wiki.xen.org/wiki/Spaceflight
>> When I use the link there is a redirection to
>> https://en.wikipedia.org/wiki/Spaceflight?rdfrom=http%3A%2F%2Fwiki.xen.org%2Fwiki%3Ftitle%3DSpaceflight%26redirect%3Dno
>>
>> Was http://wiki.xen.org/wiki/Spaceflight purposely created?
>> Is it needed in http://wiki.xen.org/wiki/
>> Can it be removed?
>
> I think it was a mistake (probably, an example which comes with the
> mediawiki installation) and have removed it.
>
> Ian.
>

Thank you.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 17:01:22 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 17:01:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ra9FP-0005KD-QE; Mon, 12 Dec 2011 17:01:03 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Ra9FO-0005K5-EX
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 17:01:03 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1323709203!1664651!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10935 invoked from network); 12 Dec 2011 17:00:03 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-9.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 12 Dec 2011 17:00:03 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 12 Dec 2011 17:00:03 +0000
Message-Id: <4EE6415A02000078000670E1@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 12 Dec 2011 17:00:58 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartA9860C5A.1__="
Cc: Wei Wang2 <wei.wang2@amd.com>
Subject: [Xen-devel] [PATCH 4/4] ACPI: eliminate duplicate IVRS definitions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__PartA9860C5A.1__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Use their proper counterparts in include/acpi/actbl*.h instead.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/drivers/passthrough/amd/iommu_acpi.c
+++ b/xen/drivers/passthrough/amd/iommu_acpi.c
@@ -20,10 +20,38 @@
=20
 #include <xen/config.h>
 #include <xen/errno.h>
+#include <xen/acpi.h>
 #include <asm/apicdef.h>
 #include <asm/amd-iommu.h>
 #include <asm/hvm/svm/amd-iommu-proto.h>
-#include <asm/hvm/svm/amd-iommu-acpi.h>
+
+/* Some helper structures, particularly to deal with ranges. */
+
+struct acpi_ivhd_device_range {
+   struct acpi_ivrs_device4 start;
+   struct acpi_ivrs_device4 end;
+};
+
+struct acpi_ivhd_device_alias_range {
+   struct acpi_ivrs_device8a alias;
+   struct acpi_ivrs_device4 end;
+};
+
+struct acpi_ivhd_device_extended_range {
+   struct acpi_ivrs_device8b extended;
+   struct acpi_ivrs_device4 end;
+};
+
+union acpi_ivhd_device {
+   struct acpi_ivrs_de_header header;
+   struct acpi_ivrs_device4 select;
+   struct acpi_ivhd_device_range range;
+   struct acpi_ivrs_device8a alias;
+   struct acpi_ivhd_device_alias_range alias_range;
+   struct acpi_ivrs_device8b extended;
+   struct acpi_ivhd_device_extended_range extended_range;
+   struct acpi_ivrs_device8c special;
+};
=20
 static unsigned short __initdata last_bdf;
=20
@@ -242,12 +270,12 @@ static int __init register_exclusion_ran
 }
=20
 static int __init parse_ivmd_device_select(
-    struct acpi_ivmd_block_header *ivmd_block,
+    const struct acpi_ivrs_memory *ivmd_block,
     unsigned long base, unsigned long limit, u8 iw, u8 ir)
 {
     u16 bdf;
=20
-    bdf =3D ivmd_block->header.dev_id;
+    bdf =3D ivmd_block->header.device_id;
     if ( bdf >=3D ivrs_bdf_entries )
     {
         AMD_IOMMU_DEBUG("IVMD Error: Invalid Dev_Id 0x%x\n", bdf);
@@ -258,13 +286,13 @@ static int __init parse_ivmd_device_sele
 }
=20
 static int __init parse_ivmd_device_range(
-    struct acpi_ivmd_block_header *ivmd_block,
+    const struct acpi_ivrs_memory *ivmd_block,
     unsigned long base, unsigned long limit, u8 iw, u8 ir)
 {
     u16 first_bdf, last_bdf, bdf;
     int error;
=20
-    first_bdf =3D ivmd_block->header.dev_id;
+    first_bdf =3D ivmd_block->header.device_id;
     if ( first_bdf >=3D ivrs_bdf_entries )
     {
         AMD_IOMMU_DEBUG("IVMD Error: "
@@ -272,7 +300,7 @@ static int __init parse_ivmd_device_rang
         return -ENODEV;
     }
=20
-    last_bdf =3D ivmd_block->last_dev_id;
+    last_bdf =3D ivmd_block->aux_data;
     if ( (last_bdf >=3D ivrs_bdf_entries) || (last_bdf <=3D first_bdf) )
     {
         AMD_IOMMU_DEBUG("IVMD Error: "
@@ -288,18 +316,18 @@ static int __init parse_ivmd_device_rang
 }
=20
 static int __init parse_ivmd_device_iommu(
-    struct acpi_ivmd_block_header *ivmd_block,
+    const struct acpi_ivrs_memory *ivmd_block,
     unsigned long base, unsigned long limit, u8 iw, u8 ir)
 {
     struct amd_iommu *iommu;
=20
     /* find target IOMMU */
-    iommu =3D find_iommu_from_bdf_cap(ivmd_block->header.dev_id,
-                                    ivmd_block->cap_offset);
+    iommu =3D find_iommu_from_bdf_cap(ivmd_block->header.device_id,
+                                    ivmd_block->aux_data);
     if ( !iommu )
     {
         AMD_IOMMU_DEBUG("IVMD Error: No IOMMU for Dev_Id 0x%x  Cap =
0x%x\n",
-                        ivmd_block->header.dev_id, ivmd_block->cap_offset)=
;
+                        ivmd_block->header.device_id, ivmd_block->aux_data=
);
         return -ENODEV;
     }
=20
@@ -307,20 +335,19 @@ static int __init parse_ivmd_device_iomm
         iommu, base, limit, iw, ir);
 }
=20
-static int __init parse_ivmd_block(struct acpi_ivmd_block_header =
*ivmd_block)
+static int __init parse_ivmd_block(const struct acpi_ivrs_memory =
*ivmd_block)
 {
     unsigned long start_addr, mem_length, base, limit;
     u8 iw, ir;
=20
-    if ( ivmd_block->header.length <
-         sizeof(struct acpi_ivmd_block_header) )
+    if ( ivmd_block->header.length < sizeof(*ivmd_block) )
     {
         AMD_IOMMU_DEBUG("IVMD Error: Invalid Block Length!\n");
         return -ENODEV;
     }
=20
-    start_addr =3D (unsigned long)ivmd_block->start_addr;
-    mem_length =3D (unsigned long)ivmd_block->mem_length;
+    start_addr =3D (unsigned long)ivmd_block->start_address;
+    mem_length =3D (unsigned long)ivmd_block->memory_length;
     base =3D start_addr & PAGE_MASK;
     limit =3D (start_addr + mem_length - 1) & PAGE_MASK;
=20
@@ -328,20 +355,14 @@ static int __init parse_ivmd_block(struc
     AMD_IOMMU_DEBUG(" Start_Addr_Phys 0x%lx\n", start_addr);
     AMD_IOMMU_DEBUG(" Mem_Length 0x%lx\n", mem_length);
=20
-    if ( get_field_from_byte(ivmd_block->header.flags,
-                             AMD_IOMMU_ACPI_EXCLUSION_RANGE_MASK,
-                             AMD_IOMMU_ACPI_EXCLUSION_RANGE_SHIFT) )
+    if ( ivmd_block->header.flags & ACPI_IVMD_EXCLUSION_RANGE )
         iw =3D ir =3D IOMMU_CONTROL_ENABLED;
-    else if ( get_field_from_byte(ivmd_block->header.flags,
-                                  AMD_IOMMU_ACPI_UNITY_MAPPING_MASK,
-                                  AMD_IOMMU_ACPI_UNITY_MAPPING_SHIFT) )
-    {
-        iw =3D get_field_from_byte(ivmd_block->header.flags,
-                                 AMD_IOMMU_ACPI_IW_PERMISSION_MASK,
-                                 AMD_IOMMU_ACPI_IW_PERMISSION_SHIFT);
-        ir =3D get_field_from_byte(ivmd_block->header.flags,
-                                 AMD_IOMMU_ACPI_IR_PERMISSION_MASK,
-                                 AMD_IOMMU_ACPI_IR_PERMISSION_SHIFT);
+    else if ( ivmd_block->header.flags & ACPI_IVMD_UNITY )
+    {
+        iw =3D ivmd_block->header.flags & ACPI_IVMD_READ ?
+            IOMMU_CONTROL_ENABLED : IOMMU_CONTROL_DISABLED;
+        ir =3D ivmd_block->header.flags & ACPI_IVMD_WRITE ?
+            IOMMU_CONTROL_ENABLED : IOMMU_CONTROL_DISABLED;
     }
     else
     {
@@ -351,19 +372,19 @@ static int __init parse_ivmd_block(struc
=20
     switch( ivmd_block->header.type )
     {
-    case AMD_IOMMU_ACPI_IVMD_ALL_TYPE:
+    case ACPI_IVRS_TYPE_MEMORY_ALL:
         return register_exclusion_range_for_all_devices(
             base, limit, iw, ir);
=20
-    case AMD_IOMMU_ACPI_IVMD_ONE_TYPE:
+    case ACPI_IVRS_TYPE_MEMORY_ONE:
         return parse_ivmd_device_select(ivmd_block,
                                         base, limit, iw, ir);
=20
-    case AMD_IOMMU_ACPI_IVMD_RANGE_TYPE:
+    case ACPI_IVRS_TYPE_MEMORY_RANGE:
         return parse_ivmd_device_range(ivmd_block,
                                        base, limit, iw, ir);
=20
-    case AMD_IOMMU_ACPI_IVMD_IOMMU_TYPE:
+    case ACPI_IVRS_TYPE_MEMORY_IOMMU:
         return parse_ivmd_device_iommu(ivmd_block,
                                        base, limit, iw, ir);
=20
@@ -386,45 +407,44 @@ static u16 __init parse_ivhd_device_padd
 }
=20
 static u16 __init parse_ivhd_device_select(
-    union acpi_ivhd_device *ivhd_device, struct amd_iommu *iommu)
+    const struct acpi_ivrs_device4 *select, struct amd_iommu *iommu)
 {
     u16 bdf;
=20
-    bdf =3D ivhd_device->header.dev_id;
+    bdf =3D select->header.id;
     if ( bdf >=3D ivrs_bdf_entries )
     {
         AMD_IOMMU_DEBUG("IVHD Error: Invalid Device_Entry Dev_Id 0x%x\n", =
bdf);
         return 0;
     }
=20
-    add_ivrs_mapping_entry(bdf, bdf, ivhd_device->header.flags, iommu);
+    add_ivrs_mapping_entry(bdf, bdf, select->header.data_setting, iommu);
=20
-    return sizeof(struct acpi_ivhd_device_header);
+    return sizeof(*select);
 }
=20
 static u16 __init parse_ivhd_device_range(
-    union acpi_ivhd_device *ivhd_device,
+    const struct acpi_ivhd_device_range *range,
     u16 header_length, u16 block_length, struct amd_iommu *iommu)
 {
     u16 dev_length, first_bdf, last_bdf, bdf;
=20
-    dev_length =3D sizeof(struct acpi_ivhd_device_range);
+    dev_length =3D sizeof(*range);
     if ( header_length < (block_length + dev_length) )
     {
         AMD_IOMMU_DEBUG("IVHD Error: Invalid Device_Entry Length!\n");
         return 0;
     }
=20
-    if ( ivhd_device->range.trailer.type !=3D
-         AMD_IOMMU_ACPI_IVHD_DEV_RANGE_END )
+    if ( range->end.header.type !=3D ACPI_IVRS_TYPE_END )
     {
         AMD_IOMMU_DEBUG("IVHD Error: "
                         "Invalid Range: End_Type 0x%x\n",
-                        ivhd_device->range.trailer.type);
+                        range->end.header.type);
         return 0;
     }
=20
-    first_bdf =3D ivhd_device->header.dev_id;
+    first_bdf =3D range->start.header.id;
     if ( first_bdf >=3D ivrs_bdf_entries )
     {
         AMD_IOMMU_DEBUG("IVHD Error: "
@@ -432,7 +452,7 @@ static u16 __init parse_ivhd_device_rang
         return 0;
     }
=20
-    last_bdf =3D ivhd_device->range.trailer.dev_id;
+    last_bdf =3D range->end.header.id;
     if ( (last_bdf >=3D ivrs_bdf_entries) || (last_bdf <=3D first_bdf) )
     {
         AMD_IOMMU_DEBUG("IVHD Error: "
@@ -443,32 +463,33 @@ static u16 __init parse_ivhd_device_rang
     AMD_IOMMU_DEBUG(" Dev_Id Range: 0x%x -> 0x%x\n", first_bdf, last_bdf);=

=20
     for ( bdf =3D first_bdf; bdf <=3D last_bdf; bdf++ )
-        add_ivrs_mapping_entry(bdf, bdf, ivhd_device->header.flags, =
iommu);
+        add_ivrs_mapping_entry(bdf, bdf, range->start.header.data_setting,=

+                               iommu);
=20
     return dev_length;
 }
=20
 static u16 __init parse_ivhd_device_alias(
-    union acpi_ivhd_device *ivhd_device,
+    const struct acpi_ivrs_device8a *alias,
     u16 header_length, u16 block_length, struct amd_iommu *iommu)
 {
     u16 dev_length, alias_id, bdf;
=20
-    dev_length =3D sizeof(struct acpi_ivhd_device_alias);
+    dev_length =3D sizeof(*alias);
     if ( header_length < (block_length + dev_length) )
     {
         AMD_IOMMU_DEBUG("IVHD Error: Invalid Device_Entry Length!\n");
         return 0;
     }
=20
-    bdf =3D ivhd_device->header.dev_id;
+    bdf =3D alias->header.id;
     if ( bdf >=3D ivrs_bdf_entries )
     {
         AMD_IOMMU_DEBUG("IVHD Error: Invalid Device_Entry Dev_Id 0x%x\n", =
bdf);
         return 0;
     }
=20
-    alias_id =3D ivhd_device->alias.dev_id;
+    alias_id =3D alias->used_id;
     if ( alias_id >=3D ivrs_bdf_entries )
     {
         AMD_IOMMU_DEBUG("IVHD Error: Invalid Alias Dev_Id 0x%x\n", =
alias_id);
@@ -477,35 +498,34 @@ static u16 __init parse_ivhd_device_alia
=20
     AMD_IOMMU_DEBUG(" Dev_Id Alias: 0x%x\n", alias_id);
=20
-    add_ivrs_mapping_entry(bdf, alias_id, ivhd_device->header.flags, =
iommu);
+    add_ivrs_mapping_entry(bdf, alias_id, alias->header.data_setting, =
iommu);
=20
     return dev_length;
 }
=20
 static u16 __init parse_ivhd_device_alias_range(
-    union acpi_ivhd_device *ivhd_device,
+    const struct acpi_ivhd_device_alias_range *range,
     u16 header_length, u16 block_length, struct amd_iommu *iommu)
 {
=20
     u16 dev_length, first_bdf, last_bdf, alias_id, bdf;
=20
-    dev_length =3D sizeof(struct acpi_ivhd_device_alias_range);
+    dev_length =3D sizeof(*range);
     if ( header_length < (block_length + dev_length) )
     {
         AMD_IOMMU_DEBUG("IVHD Error: Invalid Device_Entry Length!\n");
         return 0;
     }
=20
-    if ( ivhd_device->alias_range.trailer.type !=3D
-         AMD_IOMMU_ACPI_IVHD_DEV_RANGE_END )
+    if ( range->end.header.type !=3D ACPI_IVRS_TYPE_END )
     {
         AMD_IOMMU_DEBUG("IVHD Error: "
                         "Invalid Range: End_Type 0x%x\n",
-                        ivhd_device->alias_range.trailer.type);
+                        range->end.header.type);
         return 0;
     }
=20
-    first_bdf =3D ivhd_device->header.dev_id;
+    first_bdf =3D range->alias.header.id;
     if ( first_bdf >=3D ivrs_bdf_entries )
     {
         AMD_IOMMU_DEBUG("IVHD Error: "
@@ -513,7 +533,7 @@ static u16 __init parse_ivhd_device_alia
         return 0;
     }
=20
-    last_bdf =3D ivhd_device->alias_range.trailer.dev_id;
+    last_bdf =3D range->end.header.id;
     if ( last_bdf >=3D ivrs_bdf_entries || last_bdf <=3D first_bdf )
     {
         AMD_IOMMU_DEBUG(
@@ -521,7 +541,7 @@ static u16 __init parse_ivhd_device_alia
         return 0;
     }
=20
-    alias_id =3D ivhd_device->alias_range.alias.dev_id;
+    alias_id =3D range->alias.used_id;
     if ( alias_id >=3D ivrs_bdf_entries )
     {
         AMD_IOMMU_DEBUG("IVHD Error: Invalid Alias Dev_Id 0x%x\n", =
alias_id);
@@ -532,59 +552,59 @@ static u16 __init parse_ivhd_device_alia
     AMD_IOMMU_DEBUG(" Dev_Id Alias: 0x%x\n", alias_id);
=20
     for ( bdf =3D first_bdf; bdf <=3D last_bdf; bdf++ )
-        add_ivrs_mapping_entry(bdf, alias_id, ivhd_device->header.flags, =
iommu);
+        add_ivrs_mapping_entry(bdf, alias_id, range->alias.header.data_set=
ting,
+                               iommu);
=20
     return dev_length;
 }
=20
 static u16 __init parse_ivhd_device_extended(
-    union acpi_ivhd_device *ivhd_device,
+    const struct acpi_ivrs_device8b *ext,
     u16 header_length, u16 block_length, struct amd_iommu *iommu)
 {
     u16 dev_length, bdf;
=20
-    dev_length =3D sizeof(struct acpi_ivhd_device_extended);
+    dev_length =3D sizeof(*ext);
     if ( header_length < (block_length + dev_length) )
     {
         AMD_IOMMU_DEBUG("IVHD Error: Invalid Device_Entry Length!\n");
         return 0;
     }
=20
-    bdf =3D ivhd_device->header.dev_id;
+    bdf =3D ext->header.id;
     if ( bdf >=3D ivrs_bdf_entries )
     {
         AMD_IOMMU_DEBUG("IVHD Error: Invalid Device_Entry Dev_Id 0x%x\n", =
bdf);
         return 0;
     }
=20
-    add_ivrs_mapping_entry(bdf, bdf, ivhd_device->header.flags, iommu);
+    add_ivrs_mapping_entry(bdf, bdf, ext->header.data_setting, iommu);
=20
     return dev_length;
 }
=20
 static u16 __init parse_ivhd_device_extended_range(
-    union acpi_ivhd_device *ivhd_device,
+    const struct acpi_ivhd_device_extended_range *range,
     u16 header_length, u16 block_length, struct amd_iommu *iommu)
 {
     u16 dev_length, first_bdf, last_bdf, bdf;
=20
-    dev_length =3D sizeof(struct acpi_ivhd_device_extended_range);
+    dev_length =3D sizeof(*range);
     if ( header_length < (block_length + dev_length) )
     {
         AMD_IOMMU_DEBUG("IVHD Error: Invalid Device_Entry Length!\n");
         return 0;
     }
=20
-    if ( ivhd_device->extended_range.trailer.type !=3D
-         AMD_IOMMU_ACPI_IVHD_DEV_RANGE_END )
+    if ( range->end.header.type !=3D ACPI_IVRS_TYPE_END )
     {
         AMD_IOMMU_DEBUG("IVHD Error: "
                         "Invalid Range: End_Type 0x%x\n",
-                        ivhd_device->extended_range.trailer.type);
+                        range->end.header.type);
         return 0;
     }
=20
-    first_bdf =3D ivhd_device->header.dev_id;
+    first_bdf =3D range->extended.header.id;
     if ( first_bdf >=3D ivrs_bdf_entries )
     {
         AMD_IOMMU_DEBUG("IVHD Error: "
@@ -592,7 +612,7 @@ static u16 __init parse_ivhd_device_exte
         return 0;
     }
=20
-    last_bdf =3D ivhd_device->extended_range.trailer.dev_id;
+    last_bdf =3D range->end.header.id;
     if ( (last_bdf >=3D ivrs_bdf_entries) || (last_bdf <=3D first_bdf) )
     {
         AMD_IOMMU_DEBUG("IVHD Error: "
@@ -604,116 +624,116 @@ static u16 __init parse_ivhd_device_exte
                     first_bdf, last_bdf);
=20
     for ( bdf =3D first_bdf; bdf <=3D last_bdf; bdf++ )
-        add_ivrs_mapping_entry(bdf, bdf, ivhd_device->header.flags, =
iommu);
+        add_ivrs_mapping_entry(bdf, bdf, range->extended.header.data_setti=
ng,
+                               iommu);
=20
     return dev_length;
 }
=20
 static u16 __init parse_ivhd_device_special(
-    union acpi_ivhd_device *ivhd_device, u16 seg,
+    const struct acpi_ivrs_device8c *special, u16 seg,
     u16 header_length, u16 block_length, struct amd_iommu *iommu)
 {
     u16 dev_length, bdf;
=20
-    dev_length =3D sizeof(struct acpi_ivhd_device_special);
+    dev_length =3D sizeof(*special);
     if ( header_length < (block_length + dev_length) )
     {
         AMD_IOMMU_DEBUG("IVHD Error: Invalid Device_Entry Length!\n");
         return 0;
     }
=20
-    bdf =3D ivhd_device->special.dev_id;
+    bdf =3D special->used_id;
     if ( bdf >=3D ivrs_bdf_entries )
     {
         AMD_IOMMU_DEBUG("IVHD Error: Invalid Device_Entry Dev_Id 0x%x\n", =
bdf);
         return 0;
     }
=20
-    add_ivrs_mapping_entry(bdf, bdf, ivhd_device->header.flags, iommu);
+    add_ivrs_mapping_entry(bdf, bdf, special->header.data_setting, =
iommu);
     /* set device id of ioapic */
-    ioapic_sbdf[ivhd_device->special.handle].bdf =3D bdf;
-    ioapic_sbdf[ivhd_device->special.handle].seg =3D seg;
+    ioapic_sbdf[special->handle].bdf =3D bdf;
+    ioapic_sbdf[special->handle].seg =3D seg;
     return dev_length;
 }
=20
-static int __init parse_ivhd_block(struct acpi_ivhd_block_header =
*ivhd_block)
+static int __init parse_ivhd_block(const struct acpi_ivrs_hardware =
*ivhd_block)
 {
-    union acpi_ivhd_device *ivhd_device;
+    const union acpi_ivhd_device *ivhd_device;
     u16 block_length, dev_length;
     struct amd_iommu *iommu;
=20
-    if ( ivhd_block->header.length <
-         sizeof(struct acpi_ivhd_block_header) )
+    if ( ivhd_block->header.length < sizeof(*ivhd_block) )
     {
         AMD_IOMMU_DEBUG("IVHD Error: Invalid Block Length!\n");
         return -ENODEV;
     }
=20
-    iommu =3D find_iommu_from_bdf_cap(ivhd_block->header.dev_id,
-                                    ivhd_block->cap_offset);
+    iommu =3D find_iommu_from_bdf_cap(ivhd_block->header.device_id,
+                                    ivhd_block->capability_offset);
     if ( !iommu )
     {
         AMD_IOMMU_DEBUG("IVHD Error: No IOMMU for Dev_Id 0x%x  Cap =
0x%x\n",
-                        ivhd_block->header.dev_id, ivhd_block->cap_offset)=
;
+                        ivhd_block->header.device_id,
+                        ivhd_block->capability_offset);
         return -ENODEV;
     }
=20
     /* parse Device Entries */
-    block_length =3D sizeof(struct acpi_ivhd_block_header);
+    block_length =3D sizeof(*ivhd_block);
     while ( ivhd_block->header.length >=3D
-            (block_length + sizeof(struct acpi_ivhd_device_header)) )
+            (block_length + sizeof(struct acpi_ivrs_de_header)) )
     {
-        ivhd_device =3D (union acpi_ivhd_device *)
-            ((u8 *)ivhd_block + block_length);
+        ivhd_device =3D (const void *)((const u8 *)ivhd_block + block_leng=
th);
=20
         AMD_IOMMU_DEBUG( "IVHD Device Entry:\n");
         AMD_IOMMU_DEBUG( " Type 0x%x\n", ivhd_device->header.type);
-        AMD_IOMMU_DEBUG( " Dev_Id 0x%x\n", ivhd_device->header.dev_id);
-        AMD_IOMMU_DEBUG( " Flags 0x%x\n", ivhd_device->header.flags);
+        AMD_IOMMU_DEBUG( " Dev_Id 0x%x\n", ivhd_device->header.id);
+        AMD_IOMMU_DEBUG( " Flags 0x%x\n", ivhd_device->header.data_setting=
);
=20
         switch ( ivhd_device->header.type )
         {
-        case AMD_IOMMU_ACPI_IVHD_DEV_U32_PAD:
+        case ACPI_IVRS_TYPE_PAD4:
             dev_length =3D parse_ivhd_device_padding(
                 sizeof(u32),
                 ivhd_block->header.length, block_length);
             break;
-        case AMD_IOMMU_ACPI_IVHD_DEV_U64_PAD:
+        case ACPI_IVRS_TYPE_PAD8:
             dev_length =3D parse_ivhd_device_padding(
                 sizeof(u64),
                 ivhd_block->header.length, block_length);
             break;
-        case AMD_IOMMU_ACPI_IVHD_DEV_SELECT:
-            dev_length =3D parse_ivhd_device_select(ivhd_device, iommu);
+        case ACPI_IVRS_TYPE_SELECT:
+            dev_length =3D parse_ivhd_device_select(&ivhd_device->select, =
iommu);
             break;
-        case AMD_IOMMU_ACPI_IVHD_DEV_RANGE_START:
+        case ACPI_IVRS_TYPE_START:
             dev_length =3D parse_ivhd_device_range(
-                ivhd_device,
+                &ivhd_device->range,
                 ivhd_block->header.length, block_length, iommu);
             break;
-        case AMD_IOMMU_ACPI_IVHD_DEV_ALIAS_SELECT:
+        case ACPI_IVRS_TYPE_ALIAS_SELECT:
             dev_length =3D parse_ivhd_device_alias(
-                ivhd_device,
+                &ivhd_device->alias,
                 ivhd_block->header.length, block_length, iommu);
             break;
-        case AMD_IOMMU_ACPI_IVHD_DEV_ALIAS_RANGE:
+        case ACPI_IVRS_TYPE_ALIAS_START:
             dev_length =3D parse_ivhd_device_alias_range(
-                ivhd_device,
+                &ivhd_device->alias_range,
                 ivhd_block->header.length, block_length, iommu);
             break;
-        case AMD_IOMMU_ACPI_IVHD_DEV_EXT_SELECT:
+        case ACPI_IVRS_TYPE_EXT_SELECT:
             dev_length =3D parse_ivhd_device_extended(
-                ivhd_device,
+                &ivhd_device->extended,
                 ivhd_block->header.length, block_length, iommu);
             break;
-        case AMD_IOMMU_ACPI_IVHD_DEV_EXT_RANGE:
+        case ACPI_IVRS_TYPE_EXT_START:
             dev_length =3D parse_ivhd_device_extended_range(
-                ivhd_device,
+                &ivhd_device->extended_range,
                 ivhd_block->header.length, block_length, iommu);
             break;
-        case AMD_IOMMU_ACPI_IVHD_DEV_SPECIAL:
+        case ACPI_IVRS_TYPE_SPECIAL:
             dev_length =3D parse_ivhd_device_special(
-                ivhd_device, ivhd_block->pci_segment,
+                &ivhd_device->special, ivhd_block->pci_segment_group,
                 ivhd_block->header.length, block_length, iommu);
             break;
         default:
@@ -730,22 +750,24 @@ static int __init parse_ivhd_block(struc
     return 0;
 }
=20
-static int __init parse_ivrs_block(struct acpi_ivrs_block_header =
*ivrs_block)
+static int __init parse_ivrs_block(const struct acpi_ivrs_header =
*ivrs_block)
 {
-    struct acpi_ivhd_block_header *ivhd_block;
-    struct acpi_ivmd_block_header *ivmd_block;
+    const struct acpi_ivrs_hardware *ivhd_block;
+    const struct acpi_ivrs_memory *ivmd_block;
=20
     switch ( ivrs_block->type )
     {
-    case AMD_IOMMU_ACPI_IVHD_TYPE:
-        ivhd_block =3D (struct acpi_ivhd_block_header *)ivrs_block;
+    case ACPI_IVRS_TYPE_HARDWARE:
+        ivhd_block =3D container_of(ivrs_block, const struct acpi_ivrs_har=
dware,
+                                  header);
         return parse_ivhd_block(ivhd_block);
=20
-    case AMD_IOMMU_ACPI_IVMD_ALL_TYPE:
-    case AMD_IOMMU_ACPI_IVMD_ONE_TYPE:
-    case AMD_IOMMU_ACPI_IVMD_RANGE_TYPE:
-    case AMD_IOMMU_ACPI_IVMD_IOMMU_TYPE:
-        ivmd_block =3D (struct acpi_ivmd_block_header *)ivrs_block;
+    case ACPI_IVRS_TYPE_MEMORY_ALL:
+    case ACPI_IVRS_TYPE_MEMORY_ONE:
+    case ACPI_IVRS_TYPE_MEMORY_RANGE:
+    case ACPI_IVRS_TYPE_MEMORY_IOMMU:
+        ivmd_block =3D container_of(ivrs_block, const struct acpi_ivrs_mem=
ory,
+                                  header);
         return parse_ivmd_block(ivmd_block);
=20
     default:
@@ -792,12 +814,11 @@ static void __init dump_acpi_table_heade
=20
 }
=20
-static int __init parse_ivrs_table(struct acpi_table_header *_table)
+static int __init parse_ivrs_table(struct acpi_table_header *table)
 {
-    struct acpi_ivrs_block_header *ivrs_block;
+    const struct acpi_ivrs_header *ivrs_block;
     unsigned long length;
     int error =3D 0;
-    struct acpi_table_header *table =3D (struct acpi_table_header =
*)_table;
=20
     BUG_ON(!table);
=20
@@ -805,17 +826,16 @@ static int __init parse_ivrs_table(struc
         dump_acpi_table_header(table);
=20
     /* parse IVRS blocks */
-    length =3D sizeof(struct acpi_ivrs_table_header);
+    length =3D sizeof(struct acpi_table_ivrs);
     while ( (error =3D=3D 0) && (table->length > (length + sizeof(*ivrs_bl=
ock))) )
     {
-        ivrs_block =3D (struct acpi_ivrs_block_header *)
-            ((u8 *)table + length);
+        ivrs_block =3D (struct acpi_ivrs_header *)((u8 *)table + length);
=20
         AMD_IOMMU_DEBUG("IVRS Block:\n");
         AMD_IOMMU_DEBUG(" Type 0x%x\n", ivrs_block->type);
         AMD_IOMMU_DEBUG(" Flags 0x%x\n", ivrs_block->flags);
         AMD_IOMMU_DEBUG(" Length 0x%x\n", ivrs_block->length);
-        AMD_IOMMU_DEBUG(" Dev_Id 0x%x\n", ivrs_block->dev_id);
+        AMD_IOMMU_DEBUG(" Dev_Id 0x%x\n", ivrs_block->device_id);
=20
         if ( table->length < (length + ivrs_block->length) )
         {
@@ -833,12 +853,11 @@ static int __init parse_ivrs_table(struc
     return error;
 }
=20
-static int __init detect_iommu_acpi(struct acpi_table_header *_table)
+static int __init detect_iommu_acpi(struct acpi_table_header *table)
 {
-    struct acpi_ivrs_block_header *ivrs_block;
-    struct acpi_table_header *table =3D (struct acpi_table_header =
*)_table;
+    const struct acpi_ivrs_header *ivrs_block;
     unsigned long i;
-    unsigned long length =3D sizeof(struct acpi_ivrs_table_header);
+    unsigned long length =3D sizeof(struct acpi_table_ivrs);
     u8 checksum, *raw_table;
=20
     /* validate checksum: sum of entire table =3D=3D 0 */
@@ -854,12 +873,14 @@ static int __init detect_iommu_acpi(stru
=20
     while ( table->length > (length + sizeof(*ivrs_block)) )
     {
-        ivrs_block =3D (struct acpi_ivrs_block_header *) ((u8 *)table + =
length);
+        ivrs_block =3D (struct acpi_ivrs_header *)((u8 *)table + length);
         if ( table->length < (length + ivrs_block->length) )
             return -ENODEV;
-        if ( ivrs_block->type =3D=3D AMD_IOMMU_ACPI_IVHD_TYPE )
-            if ( amd_iommu_detect_one_acpi((void*)ivrs_block) !=3D 0 )
-                return -ENODEV;
+        if ( ivrs_block->type =3D=3D ACPI_IVRS_TYPE_HARDWARE &&
+             amd_iommu_detect_one_acpi(
+                 container_of(ivrs_block, const struct acpi_ivrs_hardware,=

+                              header)) !=3D 0 )
+            return -ENODEV;
         length +=3D ivrs_block->length;
     }
     return 0;
@@ -870,63 +891,59 @@ static int __init detect_iommu_acpi(stru
        last_bdf =3D (x); \
    } while(0);
=20
-static int __init get_last_bdf_ivhd(void *ivhd)
+static int __init get_last_bdf_ivhd(
+    const struct acpi_ivrs_hardware *ivhd_block)
 {
-    union acpi_ivhd_device *ivhd_device;
+    const union acpi_ivhd_device *ivhd_device;
     u16 block_length, dev_length;
-    struct acpi_ivhd_block_header *ivhd_block;
-
-    ivhd_block =3D (struct acpi_ivhd_block_header *)ivhd;
=20
-    if ( ivhd_block->header.length <
-         sizeof(struct acpi_ivhd_block_header) )
+    if ( ivhd_block->header.length < sizeof(*ivhd_block) )
     {
         AMD_IOMMU_DEBUG("IVHD Error: Invalid Block Length!\n");
         return -ENODEV;
     }
=20
-    block_length =3D sizeof(struct acpi_ivhd_block_header);
+    block_length =3D sizeof(*ivhd_block);
     while ( ivhd_block->header.length >=3D
-            (block_length + sizeof(struct acpi_ivhd_device_header)) )
+            (block_length + sizeof(struct acpi_ivrs_de_header)) )
     {
-        ivhd_device =3D (union acpi_ivhd_device *)
-            ((u8 *)ivhd_block + block_length);
+        ivhd_device =3D (const void *)((u8 *)ivhd_block + block_length);
=20
         switch ( ivhd_device->header.type )
         {
-        case AMD_IOMMU_ACPI_IVHD_DEV_U32_PAD:
+        case ACPI_IVRS_TYPE_PAD4:
             dev_length =3D sizeof(u32);
             break;
-        case AMD_IOMMU_ACPI_IVHD_DEV_U64_PAD:
+        case ACPI_IVRS_TYPE_PAD8:
             dev_length =3D sizeof(u64);
             break;
-        case AMD_IOMMU_ACPI_IVHD_DEV_SELECT:
-            UPDATE_LAST_BDF(ivhd_device->header.dev_id);
-            dev_length =3D sizeof(struct acpi_ivhd_device_header);
-            break;
-        case AMD_IOMMU_ACPI_IVHD_DEV_ALIAS_SELECT:
-            UPDATE_LAST_BDF(ivhd_device->header.dev_id);
-            dev_length =3D sizeof(struct acpi_ivhd_device_alias);
-            break;
-        case AMD_IOMMU_ACPI_IVHD_DEV_EXT_SELECT:
-            UPDATE_LAST_BDF(ivhd_device->header.dev_id);
-            dev_length =3D sizeof(struct acpi_ivhd_device_extended);
-            break;
-        case AMD_IOMMU_ACPI_IVHD_DEV_RANGE_START:
-            UPDATE_LAST_BDF(ivhd_device->range.trailer.dev_id);
-            dev_length =3D sizeof(struct acpi_ivhd_device_range);
-            break;
-        case AMD_IOMMU_ACPI_IVHD_DEV_ALIAS_RANGE:
-            UPDATE_LAST_BDF(ivhd_device->alias_range.trailer.dev_id)
-            dev_length =3D sizeof(struct acpi_ivhd_device_alias_range);
-            break;
-        case AMD_IOMMU_ACPI_IVHD_DEV_EXT_RANGE:
-            UPDATE_LAST_BDF(ivhd_device->extended_range.trailer.dev_id)
-            dev_length =3D sizeof(struct acpi_ivhd_device_extended_range);=

-            break;
-        case AMD_IOMMU_ACPI_IVHD_DEV_SPECIAL:
-            UPDATE_LAST_BDF(ivhd_device->special.dev_id)
-            dev_length =3D sizeof(struct acpi_ivhd_device_special);
+        case ACPI_IVRS_TYPE_SELECT:
+            UPDATE_LAST_BDF(ivhd_device->select.header.id);
+            dev_length =3D sizeof(ivhd_device->header);
+            break;
+        case ACPI_IVRS_TYPE_ALIAS_SELECT:
+            UPDATE_LAST_BDF(ivhd_device->alias.header.id);
+            dev_length =3D sizeof(ivhd_device->alias);
+            break;
+        case ACPI_IVRS_TYPE_EXT_SELECT:
+            UPDATE_LAST_BDF(ivhd_device->extended.header.id);
+            dev_length =3D sizeof(ivhd_device->extended);
+            break;
+        case ACPI_IVRS_TYPE_START:
+            UPDATE_LAST_BDF(ivhd_device->range.end.header.id);
+            dev_length =3D sizeof(ivhd_device->range);
+            break;
+        case ACPI_IVRS_TYPE_ALIAS_START:
+            UPDATE_LAST_BDF(ivhd_device->alias_range.end.header.id)
+            dev_length =3D sizeof(ivhd_device->alias_range);
+            break;
+        case ACPI_IVRS_TYPE_EXT_START:
+            UPDATE_LAST_BDF(ivhd_device->extended_range.end.header.id)
+            dev_length =3D sizeof(ivhd_device->extended_range);
+            break;
+        case ACPI_IVRS_TYPE_SPECIAL:
+            UPDATE_LAST_BDF(ivhd_device->special.used_id)
+            dev_length =3D sizeof(ivhd_device->special);
             break;
         default:
             AMD_IOMMU_DEBUG("IVHD Error: Invalid Device Type!\n");
@@ -942,20 +959,21 @@ static int __init get_last_bdf_ivhd(void
     return 0;
 }
=20
-static int __init get_last_bdf_acpi(struct acpi_table_header *_table)
+static int __init get_last_bdf_acpi(struct acpi_table_header *table)
 {
-    struct acpi_ivrs_block_header *ivrs_block;
-    struct acpi_table_header *table =3D (struct acpi_table_header =
*)_table;
-    unsigned long length =3D sizeof(struct acpi_ivrs_table_header);
+    const struct acpi_ivrs_header *ivrs_block;
+    unsigned long length =3D sizeof(struct acpi_table_ivrs);
=20
     while ( table->length > (length + sizeof(*ivrs_block)) )
     {
-        ivrs_block =3D (struct acpi_ivrs_block_header *) ((u8 *)table + =
length);
+        ivrs_block =3D (struct acpi_ivrs_header *)((u8 *)table + length);
         if ( table->length < (length + ivrs_block->length) )
             return -ENODEV;
-        if ( ivrs_block->type =3D=3D AMD_IOMMU_ACPI_IVHD_TYPE )
-            if ( get_last_bdf_ivhd((void*)ivrs_block) !=3D 0 )
-                return -ENODEV;
+        if ( ivrs_block->type =3D=3D ACPI_IVRS_TYPE_HARDWARE &&
+             get_last_bdf_ivhd(
+                 container_of(ivrs_block, const struct acpi_ivrs_hardware,=

+                              header)) !=3D 0 )
+            return -ENODEV;
         length +=3D ivrs_block->length;
     }
    return 0;
@@ -963,16 +981,16 @@ static int __init get_last_bdf_acpi(stru
=20
 int __init amd_iommu_detect_acpi(void)
 {
-    return acpi_table_parse(AMD_IOMMU_ACPI_IVRS_SIG, detect_iommu_acpi);
+    return acpi_table_parse(ACPI_SIG_IVRS, detect_iommu_acpi);
 }
=20
 int __init amd_iommu_get_ivrs_dev_entries(void)
 {
-    acpi_table_parse(AMD_IOMMU_ACPI_IVRS_SIG, get_last_bdf_acpi);
+    acpi_table_parse(ACPI_SIG_IVRS, get_last_bdf_acpi);
     return last_bdf + 1;
 }
=20
 int __init amd_iommu_update_ivrs_mapping_acpi(void)
 {
-    return acpi_table_parse(AMD_IOMMU_ACPI_IVRS_SIG, parse_ivrs_table);
+    return acpi_table_parse(ACPI_SIG_IVRS, parse_ivrs_table);
 }
--- a/xen/drivers/passthrough/amd/iommu_detect.c
+++ b/xen/drivers/passthrough/amd/iommu_detect.c
@@ -20,12 +20,12 @@
=20
 #include <xen/config.h>
 #include <xen/errno.h>
+#include <xen/acpi.h>
 #include <xen/iommu.h>
 #include <xen/pci.h>
 #include <xen/pci_regs.h>
 #include <asm/amd-iommu.h>
 #include <asm/hvm/svm/amd-iommu-proto.h>
-#include <asm/hvm/svm/amd-iommu-acpi.h>
=20
 static int __init get_iommu_msi_capabilities(
     u16 seg, u8 bus, u8 dev, u8 func, struct amd_iommu *iommu)
@@ -103,23 +103,21 @@ void __init get_iommu_features(struct am
     }
 }
=20
-int __init amd_iommu_detect_one_acpi(void *ivhd)
+int __init amd_iommu_detect_one_acpi(
+    const struct acpi_ivrs_hardware *ivhd_block)
 {
     struct amd_iommu *iommu;
     u8 bus, dev, func;
-    struct acpi_ivhd_block_header *ivhd_block;
     int rt =3D 0;
=20
-    ivhd_block =3D (struct acpi_ivhd_block_header *)ivhd;
-
-    if ( ivhd_block->header.length < sizeof(struct acpi_ivhd_block_header)=
 )
+    if ( ivhd_block->header.length < sizeof(*ivhd_block) )
     {
         AMD_IOMMU_DEBUG("Invalid IVHD Block Length!\n");
         return -ENODEV;
     }
=20
-    if ( !ivhd_block->header.dev_id ||
-        !ivhd_block->cap_offset || !ivhd_block->mmio_base)
+    if ( !ivhd_block->header.device_id ||
+        !ivhd_block->capability_offset || !ivhd_block->base_address)
     {
         AMD_IOMMU_DEBUG("Invalid IVHD Block!\n");
         return -ENODEV;
@@ -134,10 +132,10 @@ int __init amd_iommu_detect_one_acpi(voi
=20
     spin_lock_init(&iommu->lock);
=20
-    iommu->seg =3D ivhd_block->pci_segment;
-    iommu->bdf =3D ivhd_block->header.dev_id;
-    iommu->cap_offset =3D ivhd_block->cap_offset;
-    iommu->mmio_base_phys =3D ivhd_block->mmio_base;
+    iommu->seg =3D ivhd_block->pci_segment_group;
+    iommu->bdf =3D ivhd_block->header.device_id;
+    iommu->cap_offset =3D ivhd_block->capability_offset;
+    iommu->mmio_base_phys =3D ivhd_block->base_address;
=20
     /* override IOMMU HT flags */
     iommu->ht_flags =3D ivhd_block->header.flags;
--- a/xen/drivers/passthrough/amd/iommu_init.c
+++ b/xen/drivers/passthrough/amd/iommu_init.c
@@ -20,6 +20,7 @@
=20
 #include <xen/config.h>
 #include <xen/errno.h>
+#include <xen/acpi.h>
 #include <xen/pci.h>
 #include <xen/pci_regs.h>
 #include <xen/irq.h>
@@ -28,7 +29,6 @@
 #include <asm/hvm/svm/amd-iommu-proto.h>
 #include <asm-x86/fixmap.h>
 #include <mach_apic.h>
-#include <asm/hvm/svm/amd-iommu-acpi.h>
=20
 static int __initdata nr_amd_iommus;
=20
@@ -37,9 +37,8 @@ static struct radix_tree_root ivrs_maps;
 struct list_head amd_iommu_head;
 struct table_struct device_table;
=20
-static int iommu_has_ht_flag(struct amd_iommu *iommu, uint8_t bit)
+static int iommu_has_ht_flag(struct amd_iommu *iommu, u8 mask)
 {
-    u8 mask =3D 1U << bit;
     return iommu->ht_flags & mask;
 }
=20
@@ -80,19 +79,19 @@ static void set_iommu_ht_flags(struct am
=20
     /* Setup HT flags */
     if ( iommu_has_cap(iommu, PCI_CAP_HT_TUNNEL_SHIFT) )
-        iommu_has_ht_flag(iommu, AMD_IOMMU_ACPI_HT_TUN_ENB_SHIFT) ?
+        iommu_has_ht_flag(iommu, ACPI_IVHD_TT_ENABLE) ?
             iommu_set_bit(&entry, IOMMU_CONTROL_HT_TUNNEL_TRANSLATION_SHIF=
T) :
             iommu_clear_bit(&entry, IOMMU_CONTROL_HT_TUNNEL_TRANSLATION_SH=
IFT);
=20
-    iommu_has_ht_flag(iommu, AMD_IOMMU_ACPI_RES_PASS_PW_SHIFT) ?
+    iommu_has_ht_flag(iommu, ACPI_IVHD_RES_PASS_PW) ?
         iommu_set_bit(&entry, IOMMU_CONTROL_RESP_PASS_POSTED_WRITE_SHIFT):=

         iommu_clear_bit(&entry, IOMMU_CONTROL_RESP_PASS_POSTED_WRITE_SHIFT=
);
=20
-    iommu_has_ht_flag(iommu, AMD_IOMMU_ACPI_ISOC_SHIFT) ?
+    iommu_has_ht_flag(iommu, ACPI_IVHD_ISOC) ?
         iommu_set_bit(&entry, IOMMU_CONTROL_ISOCHRONOUS_SHIFT):
         iommu_clear_bit(&entry, IOMMU_CONTROL_ISOCHRONOUS_SHIFT);
=20
-    iommu_has_ht_flag(iommu, AMD_IOMMU_ACPI_PASS_PW_SHIFT) ?
+    iommu_has_ht_flag(iommu, ACPI_IVHD_PASS_PW) ?
         iommu_set_bit(&entry, IOMMU_CONTROL_PASS_POSTED_WRITE_SHIFT):
         iommu_clear_bit(&entry, IOMMU_CONTROL_PASS_POSTED_WRITE_SHIFT);
=20
--- a/xen/drivers/passthrough/amd/iommu_map.c
+++ b/xen/drivers/passthrough/amd/iommu_map.c
@@ -18,12 +18,13 @@
  * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307 =
USA
  */
=20
+#include <xen/config.h>
+#include <xen/acpi.h>
 #include <xen/sched.h>
 #include <asm/p2m.h>
 #include <xen/hvm/iommu.h>
 #include <asm/amd-iommu.h>
 #include <asm/hvm/svm/amd-iommu-proto.h>
-#include <asm/hvm/svm/amd-iommu-acpi.h>
 #include "../ats.h"
 #include <xen/pci.h>
=20
@@ -215,8 +216,7 @@ void __init iommu_dte_add_device_entry(u
     dte[7] =3D dte[6] =3D dte[4] =3D dte[2] =3D dte[1] =3D dte[0] =3D 0;
=20
     flags =3D ivrs_dev->device_flags;
-    sys_mgt =3D get_field_from_byte(flags, AMD_IOMMU_ACPI_SYS_MGT_MASK,
-                                  AMD_IOMMU_ACPI_SYS_MGT_SHIFT);
+    sys_mgt =3D get_field_from_byte(flags, ACPI_IVHD_SYSTEM_MGMT);
     dev_ex =3D ivrs_dev->dte_allow_exclusion;
=20
     flags &=3D mask;
--- a/xen/include/asm-x86/hvm/svm/amd-iommu-acpi.h
+++ /dev/null
@@ -1,185 +0,0 @@
-/*
- * Copyright (C) 2007 Advanced Micro Devices, Inc.
- * Author: Leo Duran <leo.duran@amd.com>
- * Author: Wei Wang <wei.wang2@amd.com> - adapted to xen
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307 =
USA
- */
-
-#ifndef _ASM_X86_64_AMD_IOMMU_ACPI_H
-#define _ASM_X86_64_AMD_IOMMU_ACPI_H
-
-#include <xen/acpi.h>
-
-/* I/O Virtualization Reporting Structure */
-#define AMD_IOMMU_ACPI_IVRS_SIG            "IVRS"
-#define AMD_IOMMU_ACPI_IVHD_TYPE       0x10
-#define AMD_IOMMU_ACPI_IVMD_ALL_TYPE       0x20
-#define AMD_IOMMU_ACPI_IVMD_ONE_TYPE       0x21
-#define AMD_IOMMU_ACPI_IVMD_RANGE_TYPE     0x22
-#define AMD_IOMMU_ACPI_IVMD_IOMMU_TYPE     0x23
-
-/* 4-byte Device Entries */
-#define AMD_IOMMU_ACPI_IVHD_DEV_U32_PAD        0
-#define AMD_IOMMU_ACPI_IVHD_DEV_SELECT     2
-#define AMD_IOMMU_ACPI_IVHD_DEV_RANGE_START    3
-#define AMD_IOMMU_ACPI_IVHD_DEV_RANGE_END  4
-
-/* 8-byte Device Entries */
-#define AMD_IOMMU_ACPI_IVHD_DEV_U64_PAD        64
-#define AMD_IOMMU_ACPI_IVHD_DEV_ALIAS_SELECT   66
-#define AMD_IOMMU_ACPI_IVHD_DEV_ALIAS_RANGE    67
-#define AMD_IOMMU_ACPI_IVHD_DEV_EXT_SELECT 70
-#define AMD_IOMMU_ACPI_IVHD_DEV_EXT_RANGE  71
-#define AMD_IOMMU_ACPI_IVHD_DEV_SPECIAL    72
-
-/* IVHD IOMMU Flags */
-#define AMD_IOMMU_ACPI_COHERENT_MASK       0x20
-#define AMD_IOMMU_ACPI_COHERENT_SHIFT      5
-#define AMD_IOMMU_ACPI_IOTLB_SUP_MASK      0x10
-#define AMD_IOMMU_ACPI_IOTLB_SUP_SHIFT     4
-#define AMD_IOMMU_ACPI_ISOC_MASK       0x08
-#define AMD_IOMMU_ACPI_ISOC_SHIFT      3
-#define AMD_IOMMU_ACPI_RES_PASS_PW_MASK        0x04
-#define AMD_IOMMU_ACPI_RES_PASS_PW_SHIFT   2
-#define AMD_IOMMU_ACPI_PASS_PW_MASK        0x02
-#define AMD_IOMMU_ACPI_PASS_PW_SHIFT       1
-#define AMD_IOMMU_ACPI_HT_TUN_ENB_MASK     0x01
-#define AMD_IOMMU_ACPI_HT_TUN_ENB_SHIFT        0
-
-/* IVHD Device Flags */
-#define AMD_IOMMU_ACPI_LINT1_PASS_MASK     0x80
-#define AMD_IOMMU_ACPI_LINT1_PASS_SHIFT        7
-#define AMD_IOMMU_ACPI_LINT0_PASS_MASK     0x40
-#define AMD_IOMMU_ACPI_LINT0_PASS_SHIFT        6
-#define AMD_IOMMU_ACPI_SYS_MGT_MASK        0x30
-#define AMD_IOMMU_ACPI_SYS_MGT_SHIFT       4
-#define AMD_IOMMU_ACPI_NMI_PASS_MASK       0x04
-#define AMD_IOMMU_ACPI_NMI_PASS_SHIFT      2
-#define AMD_IOMMU_ACPI_EINT_PASS_MASK      0x02
-#define AMD_IOMMU_ACPI_EINT_PASS_SHIFT     1
-#define AMD_IOMMU_ACPI_INIT_PASS_MASK      0x01
-#define AMD_IOMMU_ACPI_INIT_PASS_SHIFT     0
-
-/* IVHD Device Extended Flags */
-#define AMD_IOMMU_ACPI_ATS_DISABLED_MASK   0x80000000
-#define AMD_IOMMU_ACPI_ATS_DISABLED_SHIFT  31
-
-/* IVMD Device Flags */
-#define AMD_IOMMU_ACPI_EXCLUSION_RANGE_MASK    0x08
-#define AMD_IOMMU_ACPI_EXCLUSION_RANGE_SHIFT   3
-#define AMD_IOMMU_ACPI_IW_PERMISSION_MASK  0x04
-#define AMD_IOMMU_ACPI_IW_PERMISSION_SHIFT 2
-#define AMD_IOMMU_ACPI_IR_PERMISSION_MASK  0x02
-#define AMD_IOMMU_ACPI_IR_PERMISSION_SHIFT 1
-#define AMD_IOMMU_ACPI_UNITY_MAPPING_MASK  0x01
-#define AMD_IOMMU_ACPI_UNITY_MAPPING_SHIFT 0
-
-#define ACPI_OEM_ID_SIZE                6
-#define ACPI_OEM_TABLE_ID_SIZE          8
-
-#pragma pack(1)
-struct acpi_ivrs_table_header {
-   struct acpi_table_header acpi_header;
-   u32 io_info;
-   u8  reserved[8];
-};
-
-struct acpi_ivrs_block_header {
-   u8  type;
-   u8  flags;
-   u16 length;
-   u16 dev_id;
-};
-
-struct acpi_ivhd_block_header {
-   struct acpi_ivrs_block_header header;
-   u16 cap_offset;
-   u64 mmio_base;
-   u16 pci_segment;
-   u16 iommu_info;
-   u8 reserved[4];
-};
-
-struct acpi_ivhd_device_header {
-   u8  type;
-   u16 dev_id;
-   u8  flags;
-};
-
-struct acpi_ivhd_device_trailer {
-   u8  type;
-   u16 dev_id;
-   u8  reserved;
-};
-
-struct acpi_ivhd_device_range {
-   struct acpi_ivhd_device_header header;
-   struct acpi_ivhd_device_trailer trailer;
-};
-
-struct acpi_ivhd_device_alias {
-   struct acpi_ivhd_device_header header;
-   u8  reserved1;
-   u16 dev_id;
-   u8  reserved2;
-};
-
-struct acpi_ivhd_device_alias_range {
-   struct acpi_ivhd_device_alias alias;
-   struct acpi_ivhd_device_trailer trailer;
-};
-
-struct acpi_ivhd_device_extended {
-   struct acpi_ivhd_device_header header;
-   u32 ext_flags;
-};
-
-struct acpi_ivhd_device_extended_range {
-   struct acpi_ivhd_device_extended extended;
-   struct acpi_ivhd_device_trailer trailer;
-};
-
-struct acpi_ivhd_device_special {
-   struct acpi_ivhd_device_header header;
-   u8  handle;
-   u16 dev_id;
-   u8  variety;
-};
-
-union acpi_ivhd_device {
-   struct acpi_ivhd_device_header header;
-   struct acpi_ivhd_device_range range;
-   struct acpi_ivhd_device_alias alias;
-   struct acpi_ivhd_device_alias_range alias_range;
-   struct acpi_ivhd_device_extended extended;
-   struct acpi_ivhd_device_extended_range extended_range;
-   struct acpi_ivhd_device_special special;
-};
-
-struct acpi_ivmd_block_header {
-   struct acpi_ivrs_block_header header;
-   union {
-       u16 last_dev_id;
-       u16 cap_offset;
-       u16 reserved1;
-   };
-   u64 reserved2;
-   u64 start_addr;
-   u64 mem_length;
-};
-#pragma pack()
-
-#endif /* _ASM_X86_64_AMD_IOMMU_ACPI_H */
--- a/xen/include/asm-x86/hvm/svm/amd-iommu-proto.h
+++ b/xen/include/asm-x86/hvm/svm/amd-iommu-proto.h
@@ -26,6 +26,8 @@
 #include <asm/apicdef.h>
 #include <xen/domain_page.h>
=20
+struct acpi_ivrs_hardware;
+
 #define for_each_amd_iommu(amd_iommu) \
     list_for_each_entry(amd_iommu, \
         &amd_iommu_head, list)
@@ -41,7 +43,7 @@
=20
 /* amd-iommu-detect functions */
 int amd_iommu_get_ivrs_dev_entries(void);
-int amd_iommu_detect_one_acpi(void *ivhd);
+int amd_iommu_detect_one_acpi(const struct acpi_ivrs_hardware *);
 int amd_iommu_detect_acpi(void);
 void get_iommu_features(struct amd_iommu *iommu);
=20
@@ -121,11 +123,9 @@ static inline u32 set_field_in_reg_u32(u
     return reg_value;
 }
=20
-static inline u8 get_field_from_byte(u8 value, u8 mask, u8 shift)
+static inline u8 get_field_from_byte(u8 value, u8 mask)
 {
-    u8 field;
-    field =3D (value & mask) >> shift;
-    return field;
+    return (value & mask) / (mask & -mask);
 }
=20
 static inline unsigned long region_to_pages(unsigned long addr, unsigned =
long size)



--=__PartA9860C5A.1__=
Content-Type: text/plain; name="acpi-duplicate-ivrs-structs.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="acpi-duplicate-ivrs-structs.patch"

ACPI: eliminate duplicate IVRS definitions=0A=0AUse their proper counterpar=
ts in include/acpi/actbl*.h instead.=0A=0ASigned-off-by: Jan Beulich =
<jbeulich@suse.com>=0A=0A--- a/xen/drivers/passthrough/amd/iommu_acpi.c=0A+=
++ b/xen/drivers/passthrough/amd/iommu_acpi.c=0A@@ -20,10 +20,38 @@=0A =0A =
#include <xen/config.h>=0A #include <xen/errno.h>=0A+#include <xen/acpi.h>=
=0A #include <asm/apicdef.h>=0A #include <asm/amd-iommu.h>=0A #include =
<asm/hvm/svm/amd-iommu-proto.h>=0A-#include <asm/hvm/svm/amd-iommu-acpi.h>=
=0A+=0A+/* Some helper structures, particularly to deal with ranges. =
*/=0A+=0A+struct acpi_ivhd_device_range {=0A+   struct acpi_ivrs_device4 =
start;=0A+   struct acpi_ivrs_device4 end;=0A+};=0A+=0A+struct acpi_ivhd_de=
vice_alias_range {=0A+   struct acpi_ivrs_device8a alias;=0A+   struct =
acpi_ivrs_device4 end;=0A+};=0A+=0A+struct acpi_ivhd_device_extended_range =
{=0A+   struct acpi_ivrs_device8b extended;=0A+   struct acpi_ivrs_device4 =
end;=0A+};=0A+=0A+union acpi_ivhd_device {=0A+   struct acpi_ivrs_de_header=
 header;=0A+   struct acpi_ivrs_device4 select;=0A+   struct acpi_ivhd_devi=
ce_range range;=0A+   struct acpi_ivrs_device8a alias;=0A+   struct =
acpi_ivhd_device_alias_range alias_range;=0A+   struct acpi_ivrs_device8b =
extended;=0A+   struct acpi_ivhd_device_extended_range extended_range;=0A+ =
  struct acpi_ivrs_device8c special;=0A+};=0A =0A static unsigned short =
__initdata last_bdf;=0A =0A@@ -242,12 +270,12 @@ static int __init =
register_exclusion_ran=0A }=0A =0A static int __init parse_ivmd_device_sele=
ct(=0A-    struct acpi_ivmd_block_header *ivmd_block,=0A+    const struct =
acpi_ivrs_memory *ivmd_block,=0A     unsigned long base, unsigned long =
limit, u8 iw, u8 ir)=0A {=0A     u16 bdf;=0A =0A-    bdf =3D ivmd_block->he=
ader.dev_id;=0A+    bdf =3D ivmd_block->header.device_id;=0A     if ( bdf =
>=3D ivrs_bdf_entries )=0A     {=0A         AMD_IOMMU_DEBUG("IVMD Error: =
Invalid Dev_Id 0x%x\n", bdf);=0A@@ -258,13 +286,13 @@ static int __init =
parse_ivmd_device_sele=0A }=0A =0A static int __init parse_ivmd_device_rang=
e(=0A-    struct acpi_ivmd_block_header *ivmd_block,=0A+    const struct =
acpi_ivrs_memory *ivmd_block,=0A     unsigned long base, unsigned long =
limit, u8 iw, u8 ir)=0A {=0A     u16 first_bdf, last_bdf, bdf;=0A     int =
error;=0A =0A-    first_bdf =3D ivmd_block->header.dev_id;=0A+    =
first_bdf =3D ivmd_block->header.device_id;=0A     if ( first_bdf >=3D =
ivrs_bdf_entries )=0A     {=0A         AMD_IOMMU_DEBUG("IVMD Error: "=0A@@ =
-272,7 +300,7 @@ static int __init parse_ivmd_device_rang=0A         =
return -ENODEV;=0A     }=0A =0A-    last_bdf =3D ivmd_block->last_dev_id;=
=0A+    last_bdf =3D ivmd_block->aux_data;=0A     if ( (last_bdf >=3D =
ivrs_bdf_entries) || (last_bdf <=3D first_bdf) )=0A     {=0A         =
AMD_IOMMU_DEBUG("IVMD Error: "=0A@@ -288,18 +316,18 @@ static int __init =
parse_ivmd_device_rang=0A }=0A =0A static int __init parse_ivmd_device_iomm=
u(=0A-    struct acpi_ivmd_block_header *ivmd_block,=0A+    const struct =
acpi_ivrs_memory *ivmd_block,=0A     unsigned long base, unsigned long =
limit, u8 iw, u8 ir)=0A {=0A     struct amd_iommu *iommu;=0A =0A     /* =
find target IOMMU */=0A-    iommu =3D find_iommu_from_bdf_cap(ivmd_block->h=
eader.dev_id,=0A-                                    ivmd_block->cap_offset=
);=0A+    iommu =3D find_iommu_from_bdf_cap(ivmd_block->header.device_id,=
=0A+                                    ivmd_block->aux_data);=0A     if ( =
!iommu )=0A     {=0A         AMD_IOMMU_DEBUG("IVMD Error: No IOMMU for =
Dev_Id 0x%x  Cap 0x%x\n",=0A-                        ivmd_block->header.dev=
_id, ivmd_block->cap_offset);=0A+                        ivmd_block->header=
.device_id, ivmd_block->aux_data);=0A         return -ENODEV;=0A     }=0A =
=0A@@ -307,20 +335,19 @@ static int __init parse_ivmd_device_iomm=0A       =
  iommu, base, limit, iw, ir);=0A }=0A =0A-static int __init parse_ivmd_blo=
ck(struct acpi_ivmd_block_header *ivmd_block)=0A+static int __init =
parse_ivmd_block(const struct acpi_ivrs_memory *ivmd_block)=0A {=0A     =
unsigned long start_addr, mem_length, base, limit;=0A     u8 iw, ir;=0A =
=0A-    if ( ivmd_block->header.length <=0A-         sizeof(struct =
acpi_ivmd_block_header) )=0A+    if ( ivmd_block->header.length < =
sizeof(*ivmd_block) )=0A     {=0A         AMD_IOMMU_DEBUG("IVMD Error: =
Invalid Block Length!\n");=0A         return -ENODEV;=0A     }=0A =0A-    =
start_addr =3D (unsigned long)ivmd_block->start_addr;=0A-    mem_length =
=3D (unsigned long)ivmd_block->mem_length;=0A+    start_addr =3D (unsigned =
long)ivmd_block->start_address;=0A+    mem_length =3D (unsigned long)ivmd_b=
lock->memory_length;=0A     base =3D start_addr & PAGE_MASK;=0A     limit =
=3D (start_addr + mem_length - 1) & PAGE_MASK;=0A =0A@@ -328,20 +355,14 @@ =
static int __init parse_ivmd_block(struc=0A     AMD_IOMMU_DEBUG(" =
Start_Addr_Phys 0x%lx\n", start_addr);=0A     AMD_IOMMU_DEBUG(" Mem_Length =
0x%lx\n", mem_length);=0A =0A-    if ( get_field_from_byte(ivmd_block->head=
er.flags,=0A-                             AMD_IOMMU_ACPI_EXCLUSION_RANGE_MA=
SK,=0A-                             AMD_IOMMU_ACPI_EXCLUSION_RANGE_SHIFT) =
)=0A+    if ( ivmd_block->header.flags & ACPI_IVMD_EXCLUSION_RANGE )=0A    =
     iw =3D ir =3D IOMMU_CONTROL_ENABLED;=0A-    else if ( get_field_from_b=
yte(ivmd_block->header.flags,=0A-                                  =
AMD_IOMMU_ACPI_UNITY_MAPPING_MASK,=0A-                                  =
AMD_IOMMU_ACPI_UNITY_MAPPING_SHIFT) )=0A-    {=0A-        iw =3D get_field_=
from_byte(ivmd_block->header.flags,=0A-                                 =
AMD_IOMMU_ACPI_IW_PERMISSION_MASK,=0A-                                 =
AMD_IOMMU_ACPI_IW_PERMISSION_SHIFT);=0A-        ir =3D get_field_from_byte(=
ivmd_block->header.flags,=0A-                                 AMD_IOMMU_ACP=
I_IR_PERMISSION_MASK,=0A-                                 AMD_IOMMU_ACPI_IR=
_PERMISSION_SHIFT);=0A+    else if ( ivmd_block->header.flags & ACPI_IVMD_U=
NITY )=0A+    {=0A+        iw =3D ivmd_block->header.flags & ACPI_IVMD_READ=
 ?=0A+            IOMMU_CONTROL_ENABLED : IOMMU_CONTROL_DISABLED;=0A+      =
  ir =3D ivmd_block->header.flags & ACPI_IVMD_WRITE ?=0A+            =
IOMMU_CONTROL_ENABLED : IOMMU_CONTROL_DISABLED;=0A     }=0A     else=0A    =
 {=0A@@ -351,19 +372,19 @@ static int __init parse_ivmd_block(struc=0A =0A =
    switch( ivmd_block->header.type )=0A     {=0A-    case AMD_IOMMU_ACPI_I=
VMD_ALL_TYPE:=0A+    case ACPI_IVRS_TYPE_MEMORY_ALL:=0A         return =
register_exclusion_range_for_all_devices(=0A             base, limit, iw, =
ir);=0A =0A-    case AMD_IOMMU_ACPI_IVMD_ONE_TYPE:=0A+    case ACPI_IVRS_TY=
PE_MEMORY_ONE:=0A         return parse_ivmd_device_select(ivmd_block,=0A   =
                                      base, limit, iw, ir);=0A =0A-    =
case AMD_IOMMU_ACPI_IVMD_RANGE_TYPE:=0A+    case ACPI_IVRS_TYPE_MEMORY_RANG=
E:=0A         return parse_ivmd_device_range(ivmd_block,=0A                =
                        base, limit, iw, ir);=0A =0A-    case AMD_IOMMU_ACP=
I_IVMD_IOMMU_TYPE:=0A+    case ACPI_IVRS_TYPE_MEMORY_IOMMU:=0A         =
return parse_ivmd_device_iommu(ivmd_block,=0A                              =
          base, limit, iw, ir);=0A =0A@@ -386,45 +407,44 @@ static u16 =
__init parse_ivhd_device_padd=0A }=0A =0A static u16 __init parse_ivhd_devi=
ce_select(=0A-    union acpi_ivhd_device *ivhd_device, struct amd_iommu =
*iommu)=0A+    const struct acpi_ivrs_device4 *select, struct amd_iommu =
*iommu)=0A {=0A     u16 bdf;=0A =0A-    bdf =3D ivhd_device->header.dev_id;=
=0A+    bdf =3D select->header.id;=0A     if ( bdf >=3D ivrs_bdf_entries =
)=0A     {=0A         AMD_IOMMU_DEBUG("IVHD Error: Invalid Device_Entry =
Dev_Id 0x%x\n", bdf);=0A         return 0;=0A     }=0A =0A-    add_ivrs_map=
ping_entry(bdf, bdf, ivhd_device->header.flags, iommu);=0A+    add_ivrs_map=
ping_entry(bdf, bdf, select->header.data_setting, iommu);=0A =0A-    =
return sizeof(struct acpi_ivhd_device_header);=0A+    return sizeof(*select=
);=0A }=0A =0A static u16 __init parse_ivhd_device_range(=0A-    union =
acpi_ivhd_device *ivhd_device,=0A+    const struct acpi_ivhd_device_range =
*range,=0A     u16 header_length, u16 block_length, struct amd_iommu =
*iommu)=0A {=0A     u16 dev_length, first_bdf, last_bdf, bdf;=0A =0A-    =
dev_length =3D sizeof(struct acpi_ivhd_device_range);=0A+    dev_length =
=3D sizeof(*range);=0A     if ( header_length < (block_length + dev_length)=
 )=0A     {=0A         AMD_IOMMU_DEBUG("IVHD Error: Invalid Device_Entry =
Length!\n");=0A         return 0;=0A     }=0A =0A-    if ( ivhd_device->ran=
ge.trailer.type !=3D=0A-         AMD_IOMMU_ACPI_IVHD_DEV_RANGE_END )=0A+   =
 if ( range->end.header.type !=3D ACPI_IVRS_TYPE_END )=0A     {=0A         =
AMD_IOMMU_DEBUG("IVHD Error: "=0A                         "Invalid Range: =
End_Type 0x%x\n",=0A-                        ivhd_device->range.trailer.typ=
e);=0A+                        range->end.header.type);=0A         return =
0;=0A     }=0A =0A-    first_bdf =3D ivhd_device->header.dev_id;=0A+    =
first_bdf =3D range->start.header.id;=0A     if ( first_bdf >=3D ivrs_bdf_e=
ntries )=0A     {=0A         AMD_IOMMU_DEBUG("IVHD Error: "=0A@@ -432,7 =
+452,7 @@ static u16 __init parse_ivhd_device_rang=0A         return 0;=0A =
    }=0A =0A-    last_bdf =3D ivhd_device->range.trailer.dev_id;=0A+    =
last_bdf =3D range->end.header.id;=0A     if ( (last_bdf >=3D ivrs_bdf_entr=
ies) || (last_bdf <=3D first_bdf) )=0A     {=0A         AMD_IOMMU_DEBUG("IV=
HD Error: "=0A@@ -443,32 +463,33 @@ static u16 __init parse_ivhd_device_ran=
g=0A     AMD_IOMMU_DEBUG(" Dev_Id Range: 0x%x -> 0x%x\n", first_bdf, =
last_bdf);=0A =0A     for ( bdf =3D first_bdf; bdf <=3D last_bdf; bdf++ =
)=0A-        add_ivrs_mapping_entry(bdf, bdf, ivhd_device->header.flags, =
iommu);=0A+        add_ivrs_mapping_entry(bdf, bdf, range->start.header.dat=
a_setting,=0A+                               iommu);=0A =0A     return =
dev_length;=0A }=0A =0A static u16 __init parse_ivhd_device_alias(=0A-    =
union acpi_ivhd_device *ivhd_device,=0A+    const struct acpi_ivrs_device8a=
 *alias,=0A     u16 header_length, u16 block_length, struct amd_iommu =
*iommu)=0A {=0A     u16 dev_length, alias_id, bdf;=0A =0A-    dev_length =
=3D sizeof(struct acpi_ivhd_device_alias);=0A+    dev_length =3D sizeof(*al=
ias);=0A     if ( header_length < (block_length + dev_length) )=0A     =
{=0A         AMD_IOMMU_DEBUG("IVHD Error: Invalid Device_Entry Length!\n");=
=0A         return 0;=0A     }=0A =0A-    bdf =3D ivhd_device->header.dev_i=
d;=0A+    bdf =3D alias->header.id;=0A     if ( bdf >=3D ivrs_bdf_entries =
)=0A     {=0A         AMD_IOMMU_DEBUG("IVHD Error: Invalid Device_Entry =
Dev_Id 0x%x\n", bdf);=0A         return 0;=0A     }=0A =0A-    alias_id =
=3D ivhd_device->alias.dev_id;=0A+    alias_id =3D alias->used_id;=0A     =
if ( alias_id >=3D ivrs_bdf_entries )=0A     {=0A         AMD_IOMMU_DEBUG("=
IVHD Error: Invalid Alias Dev_Id 0x%x\n", alias_id);=0A@@ -477,35 +498,34 =
@@ static u16 __init parse_ivhd_device_alia=0A =0A     AMD_IOMMU_DEBUG(" =
Dev_Id Alias: 0x%x\n", alias_id);=0A =0A-    add_ivrs_mapping_entry(bdf, =
alias_id, ivhd_device->header.flags, iommu);=0A+    add_ivrs_mapping_entry(=
bdf, alias_id, alias->header.data_setting, iommu);=0A =0A     return =
dev_length;=0A }=0A =0A static u16 __init parse_ivhd_device_alias_range(=0A=
-    union acpi_ivhd_device *ivhd_device,=0A+    const struct acpi_ivhd_dev=
ice_alias_range *range,=0A     u16 header_length, u16 block_length, struct =
amd_iommu *iommu)=0A {=0A =0A     u16 dev_length, first_bdf, last_bdf, =
alias_id, bdf;=0A =0A-    dev_length =3D sizeof(struct acpi_ivhd_device_ali=
as_range);=0A+    dev_length =3D sizeof(*range);=0A     if ( header_length =
< (block_length + dev_length) )=0A     {=0A         AMD_IOMMU_DEBUG("IVHD =
Error: Invalid Device_Entry Length!\n");=0A         return 0;=0A     }=0A =
=0A-    if ( ivhd_device->alias_range.trailer.type !=3D=0A-         =
AMD_IOMMU_ACPI_IVHD_DEV_RANGE_END )=0A+    if ( range->end.header.type =
!=3D ACPI_IVRS_TYPE_END )=0A     {=0A         AMD_IOMMU_DEBUG("IVHD Error: =
"=0A                         "Invalid Range: End_Type 0x%x\n",=0A-         =
               ivhd_device->alias_range.trailer.type);=0A+                 =
       range->end.header.type);=0A         return 0;=0A     }=0A =0A-    =
first_bdf =3D ivhd_device->header.dev_id;=0A+    first_bdf =3D range->alias=
.header.id;=0A     if ( first_bdf >=3D ivrs_bdf_entries )=0A     {=0A      =
   AMD_IOMMU_DEBUG("IVHD Error: "=0A@@ -513,7 +533,7 @@ static u16 __init =
parse_ivhd_device_alia=0A         return 0;=0A     }=0A =0A-    last_bdf =
=3D ivhd_device->alias_range.trailer.dev_id;=0A+    last_bdf =3D range->end=
.header.id;=0A     if ( last_bdf >=3D ivrs_bdf_entries || last_bdf <=3D =
first_bdf )=0A     {=0A         AMD_IOMMU_DEBUG(=0A@@ -521,7 +541,7 @@ =
static u16 __init parse_ivhd_device_alia=0A         return 0;=0A     }=0A =
=0A-    alias_id =3D ivhd_device->alias_range.alias.dev_id;=0A+    =
alias_id =3D range->alias.used_id;=0A     if ( alias_id >=3D ivrs_bdf_entri=
es )=0A     {=0A         AMD_IOMMU_DEBUG("IVHD Error: Invalid Alias Dev_Id =
0x%x\n", alias_id);=0A@@ -532,59 +552,59 @@ static u16 __init parse_ivhd_de=
vice_alia=0A     AMD_IOMMU_DEBUG(" Dev_Id Alias: 0x%x\n", alias_id);=0A =
=0A     for ( bdf =3D first_bdf; bdf <=3D last_bdf; bdf++ )=0A-        =
add_ivrs_mapping_entry(bdf, alias_id, ivhd_device->header.flags, iommu);=0A=
+        add_ivrs_mapping_entry(bdf, alias_id, range->alias.header.data_set=
ting,=0A+                               iommu);=0A =0A     return =
dev_length;=0A }=0A =0A static u16 __init parse_ivhd_device_extended(=0A-  =
  union acpi_ivhd_device *ivhd_device,=0A+    const struct acpi_ivrs_device=
8b *ext,=0A     u16 header_length, u16 block_length, struct amd_iommu =
*iommu)=0A {=0A     u16 dev_length, bdf;=0A =0A-    dev_length =3D =
sizeof(struct acpi_ivhd_device_extended);=0A+    dev_length =3D sizeof(*ext=
);=0A     if ( header_length < (block_length + dev_length) )=0A     {=0A   =
      AMD_IOMMU_DEBUG("IVHD Error: Invalid Device_Entry Length!\n");=0A    =
     return 0;=0A     }=0A =0A-    bdf =3D ivhd_device->header.dev_id;=0A+ =
   bdf =3D ext->header.id;=0A     if ( bdf >=3D ivrs_bdf_entries )=0A     =
{=0A         AMD_IOMMU_DEBUG("IVHD Error: Invalid Device_Entry Dev_Id =
0x%x\n", bdf);=0A         return 0;=0A     }=0A =0A-    add_ivrs_mapping_en=
try(bdf, bdf, ivhd_device->header.flags, iommu);=0A+    add_ivrs_mapping_en=
try(bdf, bdf, ext->header.data_setting, iommu);=0A =0A     return =
dev_length;=0A }=0A =0A static u16 __init parse_ivhd_device_extended_range(=
=0A-    union acpi_ivhd_device *ivhd_device,=0A+    const struct acpi_ivhd_=
device_extended_range *range,=0A     u16 header_length, u16 block_length, =
struct amd_iommu *iommu)=0A {=0A     u16 dev_length, first_bdf, last_bdf, =
bdf;=0A =0A-    dev_length =3D sizeof(struct acpi_ivhd_device_extended_rang=
e);=0A+    dev_length =3D sizeof(*range);=0A     if ( header_length < =
(block_length + dev_length) )=0A     {=0A         AMD_IOMMU_DEBUG("IVHD =
Error: Invalid Device_Entry Length!\n");=0A         return 0;=0A     }=0A =
=0A-    if ( ivhd_device->extended_range.trailer.type !=3D=0A-         =
AMD_IOMMU_ACPI_IVHD_DEV_RANGE_END )=0A+    if ( range->end.header.type =
!=3D ACPI_IVRS_TYPE_END )=0A     {=0A         AMD_IOMMU_DEBUG("IVHD Error: =
"=0A                         "Invalid Range: End_Type 0x%x\n",=0A-         =
               ivhd_device->extended_range.trailer.type);=0A+              =
          range->end.header.type);=0A         return 0;=0A     }=0A =0A-   =
 first_bdf =3D ivhd_device->header.dev_id;=0A+    first_bdf =3D range->exte=
nded.header.id;=0A     if ( first_bdf >=3D ivrs_bdf_entries )=0A     {=0A  =
       AMD_IOMMU_DEBUG("IVHD Error: "=0A@@ -592,7 +612,7 @@ static u16 =
__init parse_ivhd_device_exte=0A         return 0;=0A     }=0A =0A-    =
last_bdf =3D ivhd_device->extended_range.trailer.dev_id;=0A+    last_bdf =
=3D range->end.header.id;=0A     if ( (last_bdf >=3D ivrs_bdf_entries) || =
(last_bdf <=3D first_bdf) )=0A     {=0A         AMD_IOMMU_DEBUG("IVHD =
Error: "=0A@@ -604,116 +624,116 @@ static u16 __init parse_ivhd_device_exte=
=0A                     first_bdf, last_bdf);=0A =0A     for ( bdf =3D =
first_bdf; bdf <=3D last_bdf; bdf++ )=0A-        add_ivrs_mapping_entry(bdf=
, bdf, ivhd_device->header.flags, iommu);=0A+        add_ivrs_mapping_entry=
(bdf, bdf, range->extended.header.data_setting,=0A+                        =
       iommu);=0A =0A     return dev_length;=0A }=0A =0A static u16 __init =
parse_ivhd_device_special(=0A-    union acpi_ivhd_device *ivhd_device, u16 =
seg,=0A+    const struct acpi_ivrs_device8c *special, u16 seg,=0A     u16 =
header_length, u16 block_length, struct amd_iommu *iommu)=0A {=0A     u16 =
dev_length, bdf;=0A =0A-    dev_length =3D sizeof(struct acpi_ivhd_device_s=
pecial);=0A+    dev_length =3D sizeof(*special);=0A     if ( header_length =
< (block_length + dev_length) )=0A     {=0A         AMD_IOMMU_DEBUG("IVHD =
Error: Invalid Device_Entry Length!\n");=0A         return 0;=0A     }=0A =
=0A-    bdf =3D ivhd_device->special.dev_id;=0A+    bdf =3D special->used_i=
d;=0A     if ( bdf >=3D ivrs_bdf_entries )=0A     {=0A         AMD_IOMMU_DE=
BUG("IVHD Error: Invalid Device_Entry Dev_Id 0x%x\n", bdf);=0A         =
return 0;=0A     }=0A =0A-    add_ivrs_mapping_entry(bdf, bdf, ivhd_device-=
>header.flags, iommu);=0A+    add_ivrs_mapping_entry(bdf, bdf, special->hea=
der.data_setting, iommu);=0A     /* set device id of ioapic */=0A-    =
ioapic_sbdf[ivhd_device->special.handle].bdf =3D bdf;=0A-    ioapic_sbdf[iv=
hd_device->special.handle].seg =3D seg;=0A+    ioapic_sbdf[special->handle]=
.bdf =3D bdf;=0A+    ioapic_sbdf[special->handle].seg =3D seg;=0A     =
return dev_length;=0A }=0A =0A-static int __init parse_ivhd_block(struct =
acpi_ivhd_block_header *ivhd_block)=0A+static int __init parse_ivhd_block(c=
onst struct acpi_ivrs_hardware *ivhd_block)=0A {=0A-    union acpi_ivhd_dev=
ice *ivhd_device;=0A+    const union acpi_ivhd_device *ivhd_device;=0A     =
u16 block_length, dev_length;=0A     struct amd_iommu *iommu;=0A =0A-    =
if ( ivhd_block->header.length <=0A-         sizeof(struct acpi_ivhd_block_=
header) )=0A+    if ( ivhd_block->header.length < sizeof(*ivhd_block) )=0A =
    {=0A         AMD_IOMMU_DEBUG("IVHD Error: Invalid Block Length!\n");=0A=
         return -ENODEV;=0A     }=0A =0A-    iommu =3D find_iommu_from_bdf_=
cap(ivhd_block->header.dev_id,=0A-                                    =
ivhd_block->cap_offset);=0A+    iommu =3D find_iommu_from_bdf_cap(ivhd_bloc=
k->header.device_id,=0A+                                    ivhd_block->cap=
ability_offset);=0A     if ( !iommu )=0A     {=0A         AMD_IOMMU_DEBUG("=
IVHD Error: No IOMMU for Dev_Id 0x%x  Cap 0x%x\n",=0A-                     =
   ivhd_block->header.dev_id, ivhd_block->cap_offset);=0A+                 =
       ivhd_block->header.device_id,=0A+                        ivhd_block-=
>capability_offset);=0A         return -ENODEV;=0A     }=0A =0A     /* =
parse Device Entries */=0A-    block_length =3D sizeof(struct acpi_ivhd_blo=
ck_header);=0A+    block_length =3D sizeof(*ivhd_block);=0A     while ( =
ivhd_block->header.length >=3D=0A-            (block_length + sizeof(struct=
 acpi_ivhd_device_header)) )=0A+            (block_length + sizeof(struct =
acpi_ivrs_de_header)) )=0A     {=0A-        ivhd_device =3D (union =
acpi_ivhd_device *)=0A-            ((u8 *)ivhd_block + block_length);=0A+  =
      ivhd_device =3D (const void *)((const u8 *)ivhd_block + block_length)=
;=0A =0A         AMD_IOMMU_DEBUG( "IVHD Device Entry:\n");=0A         =
AMD_IOMMU_DEBUG( " Type 0x%x\n", ivhd_device->header.type);=0A-        =
AMD_IOMMU_DEBUG( " Dev_Id 0x%x\n", ivhd_device->header.dev_id);=0A-        =
AMD_IOMMU_DEBUG( " Flags 0x%x\n", ivhd_device->header.flags);=0A+        =
AMD_IOMMU_DEBUG( " Dev_Id 0x%x\n", ivhd_device->header.id);=0A+        =
AMD_IOMMU_DEBUG( " Flags 0x%x\n", ivhd_device->header.data_setting);=0A =
=0A         switch ( ivhd_device->header.type )=0A         {=0A-        =
case AMD_IOMMU_ACPI_IVHD_DEV_U32_PAD:=0A+        case ACPI_IVRS_TYPE_PAD4:=
=0A             dev_length =3D parse_ivhd_device_padding(=0A               =
  sizeof(u32),=0A                 ivhd_block->header.length, block_length);=
=0A             break;=0A-        case AMD_IOMMU_ACPI_IVHD_DEV_U64_PAD:=0A+=
        case ACPI_IVRS_TYPE_PAD8:=0A             dev_length =3D parse_ivhd_=
device_padding(=0A                 sizeof(u64),=0A                 =
ivhd_block->header.length, block_length);=0A             break;=0A-        =
case AMD_IOMMU_ACPI_IVHD_DEV_SELECT:=0A-            dev_length =3D =
parse_ivhd_device_select(ivhd_device, iommu);=0A+        case ACPI_IVRS_TYP=
E_SELECT:=0A+            dev_length =3D parse_ivhd_device_select(&ivhd_devi=
ce->select, iommu);=0A             break;=0A-        case AMD_IOMMU_ACPI_IV=
HD_DEV_RANGE_START:=0A+        case ACPI_IVRS_TYPE_START:=0A             =
dev_length =3D parse_ivhd_device_range(=0A-                ivhd_device,=0A+=
                &ivhd_device->range,=0A                 ivhd_block->header.=
length, block_length, iommu);=0A             break;=0A-        case =
AMD_IOMMU_ACPI_IVHD_DEV_ALIAS_SELECT:=0A+        case ACPI_IVRS_TYPE_ALIAS_=
SELECT:=0A             dev_length =3D parse_ivhd_device_alias(=0A-         =
       ivhd_device,=0A+                &ivhd_device->alias,=0A             =
    ivhd_block->header.length, block_length, iommu);=0A             =
break;=0A-        case AMD_IOMMU_ACPI_IVHD_DEV_ALIAS_RANGE:=0A+        =
case ACPI_IVRS_TYPE_ALIAS_START:=0A             dev_length =3D parse_ivhd_d=
evice_alias_range(=0A-                ivhd_device,=0A+                =
&ivhd_device->alias_range,=0A                 ivhd_block->header.length, =
block_length, iommu);=0A             break;=0A-        case AMD_IOMMU_ACPI_=
IVHD_DEV_EXT_SELECT:=0A+        case ACPI_IVRS_TYPE_EXT_SELECT:=0A         =
    dev_length =3D parse_ivhd_device_extended(=0A-                =
ivhd_device,=0A+                &ivhd_device->extended,=0A                 =
ivhd_block->header.length, block_length, iommu);=0A             break;=0A- =
       case AMD_IOMMU_ACPI_IVHD_DEV_EXT_RANGE:=0A+        case ACPI_IVRS_TY=
PE_EXT_START:=0A             dev_length =3D parse_ivhd_device_extended_rang=
e(=0A-                ivhd_device,=0A+                &ivhd_device->extende=
d_range,=0A                 ivhd_block->header.length, block_length, =
iommu);=0A             break;=0A-        case AMD_IOMMU_ACPI_IVHD_DEV_SPECI=
AL:=0A+        case ACPI_IVRS_TYPE_SPECIAL:=0A             dev_length =3D =
parse_ivhd_device_special(=0A-                ivhd_device, ivhd_block->pci_=
segment,=0A+                &ivhd_device->special, ivhd_block->pci_segment_=
group,=0A                 ivhd_block->header.length, block_length, =
iommu);=0A             break;=0A         default:=0A@@ -730,22 +750,24 @@ =
static int __init parse_ivhd_block(struc=0A     return 0;=0A }=0A =
=0A-static int __init parse_ivrs_block(struct acpi_ivrs_block_header =
*ivrs_block)=0A+static int __init parse_ivrs_block(const struct acpi_ivrs_h=
eader *ivrs_block)=0A {=0A-    struct acpi_ivhd_block_header *ivhd_block;=
=0A-    struct acpi_ivmd_block_header *ivmd_block;=0A+    const struct =
acpi_ivrs_hardware *ivhd_block;=0A+    const struct acpi_ivrs_memory =
*ivmd_block;=0A =0A     switch ( ivrs_block->type )=0A     {=0A-    case =
AMD_IOMMU_ACPI_IVHD_TYPE:=0A-        ivhd_block =3D (struct acpi_ivhd_block=
_header *)ivrs_block;=0A+    case ACPI_IVRS_TYPE_HARDWARE:=0A+        =
ivhd_block =3D container_of(ivrs_block, const struct acpi_ivrs_hardware,=0A=
+                                  header);=0A         return parse_ivhd_bl=
ock(ivhd_block);=0A =0A-    case AMD_IOMMU_ACPI_IVMD_ALL_TYPE:=0A-    case =
AMD_IOMMU_ACPI_IVMD_ONE_TYPE:=0A-    case AMD_IOMMU_ACPI_IVMD_RANGE_TYPE:=
=0A-    case AMD_IOMMU_ACPI_IVMD_IOMMU_TYPE:=0A-        ivmd_block =3D =
(struct acpi_ivmd_block_header *)ivrs_block;=0A+    case ACPI_IVRS_TYPE_MEM=
ORY_ALL:=0A+    case ACPI_IVRS_TYPE_MEMORY_ONE:=0A+    case ACPI_IVRS_TYPE_=
MEMORY_RANGE:=0A+    case ACPI_IVRS_TYPE_MEMORY_IOMMU:=0A+        =
ivmd_block =3D container_of(ivrs_block, const struct acpi_ivrs_memory,=0A+ =
                                 header);=0A         return parse_ivmd_bloc=
k(ivmd_block);=0A =0A     default:=0A@@ -792,12 +814,11 @@ static void =
__init dump_acpi_table_heade=0A =0A }=0A =0A-static int __init parse_ivrs_t=
able(struct acpi_table_header *_table)=0A+static int __init parse_ivrs_tabl=
e(struct acpi_table_header *table)=0A {=0A-    struct acpi_ivrs_block_heade=
r *ivrs_block;=0A+    const struct acpi_ivrs_header *ivrs_block;=0A     =
unsigned long length;=0A     int error =3D 0;=0A-    struct acpi_table_head=
er *table =3D (struct acpi_table_header *)_table;=0A =0A     BUG_ON(!table)=
;=0A =0A@@ -805,17 +826,16 @@ static int __init parse_ivrs_table(struc=0A  =
       dump_acpi_table_header(table);=0A =0A     /* parse IVRS blocks =
*/=0A-    length =3D sizeof(struct acpi_ivrs_table_header);=0A+    length =
=3D sizeof(struct acpi_table_ivrs);=0A     while ( (error =3D=3D 0) && =
(table->length > (length + sizeof(*ivrs_block))) )=0A     {=0A-        =
ivrs_block =3D (struct acpi_ivrs_block_header *)=0A-            ((u8 =
*)table + length);=0A+        ivrs_block =3D (struct acpi_ivrs_header =
*)((u8 *)table + length);=0A =0A         AMD_IOMMU_DEBUG("IVRS Block:\n");=
=0A         AMD_IOMMU_DEBUG(" Type 0x%x\n", ivrs_block->type);=0A         =
AMD_IOMMU_DEBUG(" Flags 0x%x\n", ivrs_block->flags);=0A         AMD_IOMMU_D=
EBUG(" Length 0x%x\n", ivrs_block->length);=0A-        AMD_IOMMU_DEBUG(" =
Dev_Id 0x%x\n", ivrs_block->dev_id);=0A+        AMD_IOMMU_DEBUG(" Dev_Id =
0x%x\n", ivrs_block->device_id);=0A =0A         if ( table->length < =
(length + ivrs_block->length) )=0A         {=0A@@ -833,12 +853,11 @@ =
static int __init parse_ivrs_table(struc=0A     return error;=0A }=0A =
=0A-static int __init detect_iommu_acpi(struct acpi_table_header =
*_table)=0A+static int __init detect_iommu_acpi(struct acpi_table_header =
*table)=0A {=0A-    struct acpi_ivrs_block_header *ivrs_block;=0A-    =
struct acpi_table_header *table =3D (struct acpi_table_header *)_table;=0A+=
    const struct acpi_ivrs_header *ivrs_block;=0A     unsigned long i;=0A- =
   unsigned long length =3D sizeof(struct acpi_ivrs_table_header);=0A+    =
unsigned long length =3D sizeof(struct acpi_table_ivrs);=0A     u8 =
checksum, *raw_table;=0A =0A     /* validate checksum: sum of entire table =
=3D=3D 0 */=0A@@ -854,12 +873,14 @@ static int __init detect_iommu_acpi(str=
u=0A =0A     while ( table->length > (length + sizeof(*ivrs_block)) )=0A   =
  {=0A-        ivrs_block =3D (struct acpi_ivrs_block_header *) ((u8 =
*)table + length);=0A+        ivrs_block =3D (struct acpi_ivrs_header =
*)((u8 *)table + length);=0A         if ( table->length < (length + =
ivrs_block->length) )=0A             return -ENODEV;=0A-        if ( =
ivrs_block->type =3D=3D AMD_IOMMU_ACPI_IVHD_TYPE )=0A-            if ( =
amd_iommu_detect_one_acpi((void*)ivrs_block) !=3D 0 )=0A-                =
return -ENODEV;=0A+        if ( ivrs_block->type =3D=3D ACPI_IVRS_TYPE_HARD=
WARE &&=0A+             amd_iommu_detect_one_acpi(=0A+                 =
container_of(ivrs_block, const struct acpi_ivrs_hardware,=0A+              =
                header)) !=3D 0 )=0A+            return -ENODEV;=0A        =
 length +=3D ivrs_block->length;=0A     }=0A     return 0;=0A@@ -870,63 =
+891,59 @@ static int __init detect_iommu_acpi(stru=0A        last_bdf =3D =
(x); \=0A    } while(0);=0A =0A-static int __init get_last_bdf_ivhd(void =
*ivhd)=0A+static int __init get_last_bdf_ivhd(=0A+    const struct =
acpi_ivrs_hardware *ivhd_block)=0A {=0A-    union acpi_ivhd_device =
*ivhd_device;=0A+    const union acpi_ivhd_device *ivhd_device;=0A     u16 =
block_length, dev_length;=0A-    struct acpi_ivhd_block_header *ivhd_block;=
=0A-=0A-    ivhd_block =3D (struct acpi_ivhd_block_header *)ivhd;=0A =0A-  =
  if ( ivhd_block->header.length <=0A-         sizeof(struct acpi_ivhd_bloc=
k_header) )=0A+    if ( ivhd_block->header.length < sizeof(*ivhd_block) =
)=0A     {=0A         AMD_IOMMU_DEBUG("IVHD Error: Invalid Block Length!\n"=
);=0A         return -ENODEV;=0A     }=0A =0A-    block_length =3D =
sizeof(struct acpi_ivhd_block_header);=0A+    block_length =3D sizeof(*ivhd=
_block);=0A     while ( ivhd_block->header.length >=3D=0A-            =
(block_length + sizeof(struct acpi_ivhd_device_header)) )=0A+            =
(block_length + sizeof(struct acpi_ivrs_de_header)) )=0A     {=0A-        =
ivhd_device =3D (union acpi_ivhd_device *)=0A-            ((u8 *)ivhd_block=
 + block_length);=0A+        ivhd_device =3D (const void *)((u8 *)ivhd_bloc=
k + block_length);=0A =0A         switch ( ivhd_device->header.type )=0A   =
      {=0A-        case AMD_IOMMU_ACPI_IVHD_DEV_U32_PAD:=0A+        case =
ACPI_IVRS_TYPE_PAD4:=0A             dev_length =3D sizeof(u32);=0A         =
    break;=0A-        case AMD_IOMMU_ACPI_IVHD_DEV_U64_PAD:=0A+        =
case ACPI_IVRS_TYPE_PAD8:=0A             dev_length =3D sizeof(u64);=0A    =
         break;=0A-        case AMD_IOMMU_ACPI_IVHD_DEV_SELECT:=0A-        =
    UPDATE_LAST_BDF(ivhd_device->header.dev_id);=0A-            dev_length =
=3D sizeof(struct acpi_ivhd_device_header);=0A-            break;=0A-      =
  case AMD_IOMMU_ACPI_IVHD_DEV_ALIAS_SELECT:=0A-            UPDATE_LAST_BDF=
(ivhd_device->header.dev_id);=0A-            dev_length =3D sizeof(struct =
acpi_ivhd_device_alias);=0A-            break;=0A-        case AMD_IOMMU_AC=
PI_IVHD_DEV_EXT_SELECT:=0A-            UPDATE_LAST_BDF(ivhd_device->header.=
dev_id);=0A-            dev_length =3D sizeof(struct acpi_ivhd_device_exten=
ded);=0A-            break;=0A-        case AMD_IOMMU_ACPI_IVHD_DEV_RANGE_S=
TART:=0A-            UPDATE_LAST_BDF(ivhd_device->range.trailer.dev_id);=0A=
-            dev_length =3D sizeof(struct acpi_ivhd_device_range);=0A-     =
       break;=0A-        case AMD_IOMMU_ACPI_IVHD_DEV_ALIAS_RANGE:=0A-     =
       UPDATE_LAST_BDF(ivhd_device->alias_range.trailer.dev_id)=0A-        =
    dev_length =3D sizeof(struct acpi_ivhd_device_alias_range);=0A-        =
    break;=0A-        case AMD_IOMMU_ACPI_IVHD_DEV_EXT_RANGE:=0A-          =
  UPDATE_LAST_BDF(ivhd_device->extended_range.trailer.dev_id)=0A-          =
  dev_length =3D sizeof(struct acpi_ivhd_device_extended_range);=0A-       =
     break;=0A-        case AMD_IOMMU_ACPI_IVHD_DEV_SPECIAL:=0A-           =
 UPDATE_LAST_BDF(ivhd_device->special.dev_id)=0A-            dev_length =
=3D sizeof(struct acpi_ivhd_device_special);=0A+        case ACPI_IVRS_TYPE=
_SELECT:=0A+            UPDATE_LAST_BDF(ivhd_device->select.header.id);=0A+=
            dev_length =3D sizeof(ivhd_device->header);=0A+            =
break;=0A+        case ACPI_IVRS_TYPE_ALIAS_SELECT:=0A+            =
UPDATE_LAST_BDF(ivhd_device->alias.header.id);=0A+            dev_length =
=3D sizeof(ivhd_device->alias);=0A+            break;=0A+        case =
ACPI_IVRS_TYPE_EXT_SELECT:=0A+            UPDATE_LAST_BDF(ivhd_device->exte=
nded.header.id);=0A+            dev_length =3D sizeof(ivhd_device->extended=
);=0A+            break;=0A+        case ACPI_IVRS_TYPE_START:=0A+         =
   UPDATE_LAST_BDF(ivhd_device->range.end.header.id);=0A+            =
dev_length =3D sizeof(ivhd_device->range);=0A+            break;=0A+       =
 case ACPI_IVRS_TYPE_ALIAS_START:=0A+            UPDATE_LAST_BDF(ivhd_devic=
e->alias_range.end.header.id)=0A+            dev_length =3D sizeof(ivhd_dev=
ice->alias_range);=0A+            break;=0A+        case ACPI_IVRS_TYPE_EXT=
_START:=0A+            UPDATE_LAST_BDF(ivhd_device->extended_range.end.head=
er.id)=0A+            dev_length =3D sizeof(ivhd_device->extended_range);=
=0A+            break;=0A+        case ACPI_IVRS_TYPE_SPECIAL:=0A+         =
   UPDATE_LAST_BDF(ivhd_device->special.used_id)=0A+            dev_length =
=3D sizeof(ivhd_device->special);=0A             break;=0A         =
default:=0A             AMD_IOMMU_DEBUG("IVHD Error: Invalid Device =
Type!\n");=0A@@ -942,20 +959,21 @@ static int __init get_last_bdf_ivhd(void=
=0A     return 0;=0A }=0A =0A-static int __init get_last_bdf_acpi(struct =
acpi_table_header *_table)=0A+static int __init get_last_bdf_acpi(struct =
acpi_table_header *table)=0A {=0A-    struct acpi_ivrs_block_header =
*ivrs_block;=0A-    struct acpi_table_header *table =3D (struct acpi_table_=
header *)_table;=0A-    unsigned long length =3D sizeof(struct acpi_ivrs_ta=
ble_header);=0A+    const struct acpi_ivrs_header *ivrs_block;=0A+    =
unsigned long length =3D sizeof(struct acpi_table_ivrs);=0A =0A     while =
( table->length > (length + sizeof(*ivrs_block)) )=0A     {=0A-        =
ivrs_block =3D (struct acpi_ivrs_block_header *) ((u8 *)table + length);=0A=
+        ivrs_block =3D (struct acpi_ivrs_header *)((u8 *)table + =
length);=0A         if ( table->length < (length + ivrs_block->length) =
)=0A             return -ENODEV;=0A-        if ( ivrs_block->type =3D=3D =
AMD_IOMMU_ACPI_IVHD_TYPE )=0A-            if ( get_last_bdf_ivhd((void*)ivr=
s_block) !=3D 0 )=0A-                return -ENODEV;=0A+        if ( =
ivrs_block->type =3D=3D ACPI_IVRS_TYPE_HARDWARE &&=0A+             =
get_last_bdf_ivhd(=0A+                 container_of(ivrs_block, const =
struct acpi_ivrs_hardware,=0A+                              header)) !=3D =
0 )=0A+            return -ENODEV;=0A         length +=3D ivrs_block->lengt=
h;=0A     }=0A    return 0;=0A@@ -963,16 +981,16 @@ static int __init =
get_last_bdf_acpi(stru=0A =0A int __init amd_iommu_detect_acpi(void)=0A =
{=0A-    return acpi_table_parse(AMD_IOMMU_ACPI_IVRS_SIG, detect_iommu_acpi=
);=0A+    return acpi_table_parse(ACPI_SIG_IVRS, detect_iommu_acpi);=0A =
}=0A =0A int __init amd_iommu_get_ivrs_dev_entries(void)=0A {=0A-    =
acpi_table_parse(AMD_IOMMU_ACPI_IVRS_SIG, get_last_bdf_acpi);=0A+    =
acpi_table_parse(ACPI_SIG_IVRS, get_last_bdf_acpi);=0A     return last_bdf =
+ 1;=0A }=0A =0A int __init amd_iommu_update_ivrs_mapping_acpi(void)=0A =
{=0A-    return acpi_table_parse(AMD_IOMMU_ACPI_IVRS_SIG, parse_ivrs_table)=
;=0A+    return acpi_table_parse(ACPI_SIG_IVRS, parse_ivrs_table);=0A =
}=0A--- a/xen/drivers/passthrough/amd/iommu_detect.c=0A+++ b/xen/drivers/pa=
ssthrough/amd/iommu_detect.c=0A@@ -20,12 +20,12 @@=0A =0A #include =
<xen/config.h>=0A #include <xen/errno.h>=0A+#include <xen/acpi.h>=0A =
#include <xen/iommu.h>=0A #include <xen/pci.h>=0A #include <xen/pci_regs.h>=
=0A #include <asm/amd-iommu.h>=0A #include <asm/hvm/svm/amd-iommu-proto.h>=
=0A-#include <asm/hvm/svm/amd-iommu-acpi.h>=0A =0A static int __init =
get_iommu_msi_capabilities(=0A     u16 seg, u8 bus, u8 dev, u8 func, =
struct amd_iommu *iommu)=0A@@ -103,23 +103,21 @@ void __init get_iommu_feat=
ures(struct am=0A     }=0A }=0A =0A-int __init amd_iommu_detect_one_acpi(vo=
id *ivhd)=0A+int __init amd_iommu_detect_one_acpi(=0A+    const struct =
acpi_ivrs_hardware *ivhd_block)=0A {=0A     struct amd_iommu *iommu;=0A    =
 u8 bus, dev, func;=0A-    struct acpi_ivhd_block_header *ivhd_block;=0A   =
  int rt =3D 0;=0A =0A-    ivhd_block =3D (struct acpi_ivhd_block_header =
*)ivhd;=0A-=0A-    if ( ivhd_block->header.length < sizeof(struct =
acpi_ivhd_block_header) )=0A+    if ( ivhd_block->header.length < =
sizeof(*ivhd_block) )=0A     {=0A         AMD_IOMMU_DEBUG("Invalid IVHD =
Block Length!\n");=0A         return -ENODEV;=0A     }=0A =0A-    if ( =
!ivhd_block->header.dev_id ||=0A-        !ivhd_block->cap_offset || =
!ivhd_block->mmio_base)=0A+    if ( !ivhd_block->header.device_id ||=0A+   =
     !ivhd_block->capability_offset || !ivhd_block->base_address)=0A     =
{=0A         AMD_IOMMU_DEBUG("Invalid IVHD Block!\n");=0A         return =
-ENODEV;=0A@@ -134,10 +132,10 @@ int __init amd_iommu_detect_one_acpi(voi=
=0A =0A     spin_lock_init(&iommu->lock);=0A =0A-    iommu->seg =3D =
ivhd_block->pci_segment;=0A-    iommu->bdf =3D ivhd_block->header.dev_id;=
=0A-    iommu->cap_offset =3D ivhd_block->cap_offset;=0A-    iommu->mmio_ba=
se_phys =3D ivhd_block->mmio_base;=0A+    iommu->seg =3D ivhd_block->pci_se=
gment_group;=0A+    iommu->bdf =3D ivhd_block->header.device_id;=0A+    =
iommu->cap_offset =3D ivhd_block->capability_offset;=0A+    iommu->mmio_bas=
e_phys =3D ivhd_block->base_address;=0A =0A     /* override IOMMU HT flags =
*/=0A     iommu->ht_flags =3D ivhd_block->header.flags;=0A--- a/xen/drivers=
/passthrough/amd/iommu_init.c=0A+++ b/xen/drivers/passthrough/amd/iommu_ini=
t.c=0A@@ -20,6 +20,7 @@=0A =0A #include <xen/config.h>=0A #include =
<xen/errno.h>=0A+#include <xen/acpi.h>=0A #include <xen/pci.h>=0A #include =
<xen/pci_regs.h>=0A #include <xen/irq.h>=0A@@ -28,7 +29,6 @@=0A #include =
<asm/hvm/svm/amd-iommu-proto.h>=0A #include <asm-x86/fixmap.h>=0A #include =
<mach_apic.h>=0A-#include <asm/hvm/svm/amd-iommu-acpi.h>=0A =0A static int =
__initdata nr_amd_iommus;=0A =0A@@ -37,9 +37,8 @@ static struct radix_tree_=
root ivrs_maps;=0A struct list_head amd_iommu_head;=0A struct table_struct =
device_table;=0A =0A-static int iommu_has_ht_flag(struct amd_iommu *iommu, =
uint8_t bit)=0A+static int iommu_has_ht_flag(struct amd_iommu *iommu, u8 =
mask)=0A {=0A-    u8 mask =3D 1U << bit;=0A     return iommu->ht_flags & =
mask;=0A }=0A =0A@@ -80,19 +79,19 @@ static void set_iommu_ht_flags(struct =
am=0A =0A     /* Setup HT flags */=0A     if ( iommu_has_cap(iommu, =
PCI_CAP_HT_TUNNEL_SHIFT) )=0A-        iommu_has_ht_flag(iommu, AMD_IOMMU_AC=
PI_HT_TUN_ENB_SHIFT) ?=0A+        iommu_has_ht_flag(iommu, ACPI_IVHD_TT_ENA=
BLE) ?=0A             iommu_set_bit(&entry, IOMMU_CONTROL_HT_TUNNEL_TRANSLA=
TION_SHIFT) :=0A             iommu_clear_bit(&entry, IOMMU_CONTROL_HT_TUNNE=
L_TRANSLATION_SHIFT);=0A =0A-    iommu_has_ht_flag(iommu, AMD_IOMMU_ACPI_RE=
S_PASS_PW_SHIFT) ?=0A+    iommu_has_ht_flag(iommu, ACPI_IVHD_RES_PASS_PW) =
?=0A         iommu_set_bit(&entry, IOMMU_CONTROL_RESP_PASS_POSTED_WRITE_SHI=
FT):=0A         iommu_clear_bit(&entry, IOMMU_CONTROL_RESP_PASS_POSTED_WRIT=
E_SHIFT);=0A =0A-    iommu_has_ht_flag(iommu, AMD_IOMMU_ACPI_ISOC_SHIFT) =
?=0A+    iommu_has_ht_flag(iommu, ACPI_IVHD_ISOC) ?=0A         iommu_set_bi=
t(&entry, IOMMU_CONTROL_ISOCHRONOUS_SHIFT):=0A         iommu_clear_bit(&ent=
ry, IOMMU_CONTROL_ISOCHRONOUS_SHIFT);=0A =0A-    iommu_has_ht_flag(iommu, =
AMD_IOMMU_ACPI_PASS_PW_SHIFT) ?=0A+    iommu_has_ht_flag(iommu, ACPI_IVHD_P=
ASS_PW) ?=0A         iommu_set_bit(&entry, IOMMU_CONTROL_PASS_POSTED_WRITE_=
SHIFT):=0A         iommu_clear_bit(&entry, IOMMU_CONTROL_PASS_POSTED_WRITE_=
SHIFT);=0A =0A--- a/xen/drivers/passthrough/amd/iommu_map.c=0A+++ =
b/xen/drivers/passthrough/amd/iommu_map.c=0A@@ -18,12 +18,13 @@=0A  * =
Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307 =
USA=0A  */=0A =0A+#include <xen/config.h>=0A+#include <xen/acpi.h>=0A =
#include <xen/sched.h>=0A #include <asm/p2m.h>=0A #include <xen/hvm/iommu.h=
>=0A #include <asm/amd-iommu.h>=0A #include <asm/hvm/svm/amd-iommu-proto.h>=
=0A-#include <asm/hvm/svm/amd-iommu-acpi.h>=0A #include "../ats.h"=0A =
#include <xen/pci.h>=0A =0A@@ -215,8 +216,7 @@ void __init iommu_dte_add_de=
vice_entry(u=0A     dte[7] =3D dte[6] =3D dte[4] =3D dte[2] =3D dte[1] =3D =
dte[0] =3D 0;=0A =0A     flags =3D ivrs_dev->device_flags;=0A-    sys_mgt =
=3D get_field_from_byte(flags, AMD_IOMMU_ACPI_SYS_MGT_MASK,=0A-            =
                      AMD_IOMMU_ACPI_SYS_MGT_SHIFT);=0A+    sys_mgt =3D =
get_field_from_byte(flags, ACPI_IVHD_SYSTEM_MGMT);=0A     dev_ex =3D =
ivrs_dev->dte_allow_exclusion;=0A =0A     flags &=3D mask;=0A--- a/xen/incl=
ude/asm-x86/hvm/svm/amd-iommu-acpi.h=0A+++ /dev/null=0A@@ -1,185 +0,0 =
@@=0A-/*=0A- * Copyright (C) 2007 Advanced Micro Devices, Inc.=0A- * =
Author: Leo Duran <leo.duran@amd.com>=0A- * Author: Wei Wang <wei.wang2@amd=
.com> - adapted to xen=0A- *=0A- * This program is free software; you can =
redistribute it and/or modify=0A- * it under the terms of the GNU General =
Public License as published by=0A- * the Free Software Foundation; either =
version 2 of the License, or=0A- * (at your option) any later version.=0A- =
*=0A- * This program is distributed in the hope that it will be useful,=0A-=
 * but WITHOUT ANY WARRANTY; without even the implied warranty of=0A- * =
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the=0A- * GNU =
General Public License for more details.=0A- *=0A- * You should have =
received a copy of the GNU General Public License=0A- * along with this =
program; if not, write to the Free Software=0A- * Foundation, Inc., 59 =
Temple Place, Suite 330, Boston, MA  02111-1307 USA=0A- */=0A-=0A-#ifndef =
_ASM_X86_64_AMD_IOMMU_ACPI_H=0A-#define _ASM_X86_64_AMD_IOMMU_ACPI_H=0A-=0A=
-#include <xen/acpi.h>=0A-=0A-/* I/O Virtualization Reporting Structure =
*/=0A-#define AMD_IOMMU_ACPI_IVRS_SIG            "IVRS"=0A-#define =
AMD_IOMMU_ACPI_IVHD_TYPE       0x10=0A-#define AMD_IOMMU_ACPI_IVMD_ALL_TYPE=
       0x20=0A-#define AMD_IOMMU_ACPI_IVMD_ONE_TYPE       0x21=0A-#define =
AMD_IOMMU_ACPI_IVMD_RANGE_TYPE     0x22=0A-#define AMD_IOMMU_ACPI_IVMD_IOMM=
U_TYPE     0x23=0A-=0A-/* 4-byte Device Entries */=0A-#define AMD_IOMMU_ACP=
I_IVHD_DEV_U32_PAD        0=0A-#define AMD_IOMMU_ACPI_IVHD_DEV_SELECT     =
2=0A-#define AMD_IOMMU_ACPI_IVHD_DEV_RANGE_START    3=0A-#define AMD_IOMMU_=
ACPI_IVHD_DEV_RANGE_END  4=0A-=0A-/* 8-byte Device Entries */=0A-#define =
AMD_IOMMU_ACPI_IVHD_DEV_U64_PAD        64=0A-#define AMD_IOMMU_ACPI_IVHD_DE=
V_ALIAS_SELECT   66=0A-#define AMD_IOMMU_ACPI_IVHD_DEV_ALIAS_RANGE    =
67=0A-#define AMD_IOMMU_ACPI_IVHD_DEV_EXT_SELECT 70=0A-#define AMD_IOMMU_AC=
PI_IVHD_DEV_EXT_RANGE  71=0A-#define AMD_IOMMU_ACPI_IVHD_DEV_SPECIAL    =
72=0A-=0A-/* IVHD IOMMU Flags */=0A-#define AMD_IOMMU_ACPI_COHERENT_MASK   =
    0x20=0A-#define AMD_IOMMU_ACPI_COHERENT_SHIFT      5=0A-#define =
AMD_IOMMU_ACPI_IOTLB_SUP_MASK      0x10=0A-#define AMD_IOMMU_ACPI_IOTLB_SUP=
_SHIFT     4=0A-#define AMD_IOMMU_ACPI_ISOC_MASK       0x08=0A-#define =
AMD_IOMMU_ACPI_ISOC_SHIFT      3=0A-#define AMD_IOMMU_ACPI_RES_PASS_PW_MASK=
        0x04=0A-#define AMD_IOMMU_ACPI_RES_PASS_PW_SHIFT   2=0A-#define =
AMD_IOMMU_ACPI_PASS_PW_MASK        0x02=0A-#define AMD_IOMMU_ACPI_PASS_PW_S=
HIFT       1=0A-#define AMD_IOMMU_ACPI_HT_TUN_ENB_MASK     0x01=0A-#define =
AMD_IOMMU_ACPI_HT_TUN_ENB_SHIFT        0=0A-=0A-/* IVHD Device Flags =
*/=0A-#define AMD_IOMMU_ACPI_LINT1_PASS_MASK     0x80=0A-#define AMD_IOMMU_=
ACPI_LINT1_PASS_SHIFT        7=0A-#define AMD_IOMMU_ACPI_LINT0_PASS_MASK   =
  0x40=0A-#define AMD_IOMMU_ACPI_LINT0_PASS_SHIFT        6=0A-#define =
AMD_IOMMU_ACPI_SYS_MGT_MASK        0x30=0A-#define AMD_IOMMU_ACPI_SYS_MGT_S=
HIFT       4=0A-#define AMD_IOMMU_ACPI_NMI_PASS_MASK       0x04=0A-#define =
AMD_IOMMU_ACPI_NMI_PASS_SHIFT      2=0A-#define AMD_IOMMU_ACPI_EINT_PASS_MA=
SK      0x02=0A-#define AMD_IOMMU_ACPI_EINT_PASS_SHIFT     1=0A-#define =
AMD_IOMMU_ACPI_INIT_PASS_MASK      0x01=0A-#define AMD_IOMMU_ACPI_INIT_PASS=
_SHIFT     0=0A-=0A-/* IVHD Device Extended Flags */=0A-#define AMD_IOMMU_A=
CPI_ATS_DISABLED_MASK   0x80000000=0A-#define AMD_IOMMU_ACPI_ATS_DISABLED_S=
HIFT  31=0A-=0A-/* IVMD Device Flags */=0A-#define AMD_IOMMU_ACPI_EXCLUSION=
_RANGE_MASK    0x08=0A-#define AMD_IOMMU_ACPI_EXCLUSION_RANGE_SHIFT   =
3=0A-#define AMD_IOMMU_ACPI_IW_PERMISSION_MASK  0x04=0A-#define AMD_IOMMU_A=
CPI_IW_PERMISSION_SHIFT 2=0A-#define AMD_IOMMU_ACPI_IR_PERMISSION_MASK  =
0x02=0A-#define AMD_IOMMU_ACPI_IR_PERMISSION_SHIFT 1=0A-#define AMD_IOMMU_A=
CPI_UNITY_MAPPING_MASK  0x01=0A-#define AMD_IOMMU_ACPI_UNITY_MAPPING_SHIFT =
0=0A-=0A-#define ACPI_OEM_ID_SIZE                6=0A-#define ACPI_OEM_TABL=
E_ID_SIZE          8=0A-=0A-#pragma pack(1)=0A-struct acpi_ivrs_table_heade=
r {=0A-   struct acpi_table_header acpi_header;=0A-   u32 io_info;=0A-   =
u8  reserved[8];=0A-};=0A-=0A-struct acpi_ivrs_block_header {=0A-   u8  =
type;=0A-   u8  flags;=0A-   u16 length;=0A-   u16 dev_id;=0A-};=0A-=0A-str=
uct acpi_ivhd_block_header {=0A-   struct acpi_ivrs_block_header header;=0A=
-   u16 cap_offset;=0A-   u64 mmio_base;=0A-   u16 pci_segment;=0A-   u16 =
iommu_info;=0A-   u8 reserved[4];=0A-};=0A-=0A-struct acpi_ivhd_device_head=
er {=0A-   u8  type;=0A-   u16 dev_id;=0A-   u8  flags;=0A-};=0A-=0A-struct=
 acpi_ivhd_device_trailer {=0A-   u8  type;=0A-   u16 dev_id;=0A-   u8  =
reserved;=0A-};=0A-=0A-struct acpi_ivhd_device_range {=0A-   struct =
acpi_ivhd_device_header header;=0A-   struct acpi_ivhd_device_trailer =
trailer;=0A-};=0A-=0A-struct acpi_ivhd_device_alias {=0A-   struct =
acpi_ivhd_device_header header;=0A-   u8  reserved1;=0A-   u16 dev_id;=0A- =
  u8  reserved2;=0A-};=0A-=0A-struct acpi_ivhd_device_alias_range {=0A-   =
struct acpi_ivhd_device_alias alias;=0A-   struct acpi_ivhd_device_trailer =
trailer;=0A-};=0A-=0A-struct acpi_ivhd_device_extended {=0A-   struct =
acpi_ivhd_device_header header;=0A-   u32 ext_flags;=0A-};=0A-=0A-struct =
acpi_ivhd_device_extended_range {=0A-   struct acpi_ivhd_device_extended =
extended;=0A-   struct acpi_ivhd_device_trailer trailer;=0A-};=0A-=0A-struc=
t acpi_ivhd_device_special {=0A-   struct acpi_ivhd_device_header =
header;=0A-   u8  handle;=0A-   u16 dev_id;=0A-   u8  variety;=0A-};=0A-=0A=
-union acpi_ivhd_device {=0A-   struct acpi_ivhd_device_header header;=0A- =
  struct acpi_ivhd_device_range range;=0A-   struct acpi_ivhd_device_alias =
alias;=0A-   struct acpi_ivhd_device_alias_range alias_range;=0A-   struct =
acpi_ivhd_device_extended extended;=0A-   struct acpi_ivhd_device_extended_=
range extended_range;=0A-   struct acpi_ivhd_device_special special;=0A-};=
=0A-=0A-struct acpi_ivmd_block_header {=0A-   struct acpi_ivrs_block_header=
 header;=0A-   union {=0A-       u16 last_dev_id;=0A-       u16 cap_offset;=
=0A-       u16 reserved1;=0A-   };=0A-   u64 reserved2;=0A-   u64 =
start_addr;=0A-   u64 mem_length;=0A-};=0A-#pragma pack()=0A-=0A-#endif /* =
_ASM_X86_64_AMD_IOMMU_ACPI_H */=0A--- a/xen/include/asm-x86/hvm/svm/amd-iom=
mu-proto.h=0A+++ b/xen/include/asm-x86/hvm/svm/amd-iommu-proto.h=0A@@ =
-26,6 +26,8 @@=0A #include <asm/apicdef.h>=0A #include <xen/domain_page.h>=
=0A =0A+struct acpi_ivrs_hardware;=0A+=0A #define for_each_amd_iommu(amd_io=
mmu) \=0A     list_for_each_entry(amd_iommu, \=0A         &amd_iommu_head, =
list)=0A@@ -41,7 +43,7 @@=0A =0A /* amd-iommu-detect functions */=0A int =
amd_iommu_get_ivrs_dev_entries(void);=0A-int amd_iommu_detect_one_acpi(void=
 *ivhd);=0A+int amd_iommu_detect_one_acpi(const struct acpi_ivrs_hardware =
*);=0A int amd_iommu_detect_acpi(void);=0A void get_iommu_features(struct =
amd_iommu *iommu);=0A =0A@@ -121,11 +123,9 @@ static inline u32 set_field_i=
n_reg_u32(u=0A     return reg_value;=0A }=0A =0A-static inline u8 =
get_field_from_byte(u8 value, u8 mask, u8 shift)=0A+static inline u8 =
get_field_from_byte(u8 value, u8 mask)=0A {=0A-    u8 field;=0A-    field =
=3D (value & mask) >> shift;=0A-    return field;=0A+    return (value & =
mask) / (mask & -mask);=0A }=0A =0A static inline unsigned long region_to_p=
ages(unsigned long addr, unsigned long size)=0A
--=__PartA9860C5A.1__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--=__PartA9860C5A.1__=--


From xen-devel-bounces@lists.xensource.com Mon Dec 12 17:01:22 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 17:01:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ra9FP-0005KD-QE; Mon, 12 Dec 2011 17:01:03 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Ra9FO-0005K5-EX
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 17:01:03 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1323709203!1664651!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10935 invoked from network); 12 Dec 2011 17:00:03 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-9.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 12 Dec 2011 17:00:03 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 12 Dec 2011 17:00:03 +0000
Message-Id: <4EE6415A02000078000670E1@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 12 Dec 2011 17:00:58 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartA9860C5A.1__="
Cc: Wei Wang2 <wei.wang2@amd.com>
Subject: [Xen-devel] [PATCH 4/4] ACPI: eliminate duplicate IVRS definitions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__PartA9860C5A.1__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Use their proper counterparts in include/acpi/actbl*.h instead.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/drivers/passthrough/amd/iommu_acpi.c
+++ b/xen/drivers/passthrough/amd/iommu_acpi.c
@@ -20,10 +20,38 @@
=20
 #include <xen/config.h>
 #include <xen/errno.h>
+#include <xen/acpi.h>
 #include <asm/apicdef.h>
 #include <asm/amd-iommu.h>
 #include <asm/hvm/svm/amd-iommu-proto.h>
-#include <asm/hvm/svm/amd-iommu-acpi.h>
+
+/* Some helper structures, particularly to deal with ranges. */
+
+struct acpi_ivhd_device_range {
+   struct acpi_ivrs_device4 start;
+   struct acpi_ivrs_device4 end;
+};
+
+struct acpi_ivhd_device_alias_range {
+   struct acpi_ivrs_device8a alias;
+   struct acpi_ivrs_device4 end;
+};
+
+struct acpi_ivhd_device_extended_range {
+   struct acpi_ivrs_device8b extended;
+   struct acpi_ivrs_device4 end;
+};
+
+union acpi_ivhd_device {
+   struct acpi_ivrs_de_header header;
+   struct acpi_ivrs_device4 select;
+   struct acpi_ivhd_device_range range;
+   struct acpi_ivrs_device8a alias;
+   struct acpi_ivhd_device_alias_range alias_range;
+   struct acpi_ivrs_device8b extended;
+   struct acpi_ivhd_device_extended_range extended_range;
+   struct acpi_ivrs_device8c special;
+};
=20
 static unsigned short __initdata last_bdf;
=20
@@ -242,12 +270,12 @@ static int __init register_exclusion_ran
 }
=20
 static int __init parse_ivmd_device_select(
-    struct acpi_ivmd_block_header *ivmd_block,
+    const struct acpi_ivrs_memory *ivmd_block,
     unsigned long base, unsigned long limit, u8 iw, u8 ir)
 {
     u16 bdf;
=20
-    bdf =3D ivmd_block->header.dev_id;
+    bdf =3D ivmd_block->header.device_id;
     if ( bdf >=3D ivrs_bdf_entries )
     {
         AMD_IOMMU_DEBUG("IVMD Error: Invalid Dev_Id 0x%x\n", bdf);
@@ -258,13 +286,13 @@ static int __init parse_ivmd_device_sele
 }
=20
 static int __init parse_ivmd_device_range(
-    struct acpi_ivmd_block_header *ivmd_block,
+    const struct acpi_ivrs_memory *ivmd_block,
     unsigned long base, unsigned long limit, u8 iw, u8 ir)
 {
     u16 first_bdf, last_bdf, bdf;
     int error;
=20
-    first_bdf =3D ivmd_block->header.dev_id;
+    first_bdf =3D ivmd_block->header.device_id;
     if ( first_bdf >=3D ivrs_bdf_entries )
     {
         AMD_IOMMU_DEBUG("IVMD Error: "
@@ -272,7 +300,7 @@ static int __init parse_ivmd_device_rang
         return -ENODEV;
     }
=20
-    last_bdf =3D ivmd_block->last_dev_id;
+    last_bdf =3D ivmd_block->aux_data;
     if ( (last_bdf >=3D ivrs_bdf_entries) || (last_bdf <=3D first_bdf) )
     {
         AMD_IOMMU_DEBUG("IVMD Error: "
@@ -288,18 +316,18 @@ static int __init parse_ivmd_device_rang
 }
=20
 static int __init parse_ivmd_device_iommu(
-    struct acpi_ivmd_block_header *ivmd_block,
+    const struct acpi_ivrs_memory *ivmd_block,
     unsigned long base, unsigned long limit, u8 iw, u8 ir)
 {
     struct amd_iommu *iommu;
=20
     /* find target IOMMU */
-    iommu =3D find_iommu_from_bdf_cap(ivmd_block->header.dev_id,
-                                    ivmd_block->cap_offset);
+    iommu =3D find_iommu_from_bdf_cap(ivmd_block->header.device_id,
+                                    ivmd_block->aux_data);
     if ( !iommu )
     {
         AMD_IOMMU_DEBUG("IVMD Error: No IOMMU for Dev_Id 0x%x  Cap =
0x%x\n",
-                        ivmd_block->header.dev_id, ivmd_block->cap_offset)=
;
+                        ivmd_block->header.device_id, ivmd_block->aux_data=
);
         return -ENODEV;
     }
=20
@@ -307,20 +335,19 @@ static int __init parse_ivmd_device_iomm
         iommu, base, limit, iw, ir);
 }
=20
-static int __init parse_ivmd_block(struct acpi_ivmd_block_header =
*ivmd_block)
+static int __init parse_ivmd_block(const struct acpi_ivrs_memory =
*ivmd_block)
 {
     unsigned long start_addr, mem_length, base, limit;
     u8 iw, ir;
=20
-    if ( ivmd_block->header.length <
-         sizeof(struct acpi_ivmd_block_header) )
+    if ( ivmd_block->header.length < sizeof(*ivmd_block) )
     {
         AMD_IOMMU_DEBUG("IVMD Error: Invalid Block Length!\n");
         return -ENODEV;
     }
=20
-    start_addr =3D (unsigned long)ivmd_block->start_addr;
-    mem_length =3D (unsigned long)ivmd_block->mem_length;
+    start_addr =3D (unsigned long)ivmd_block->start_address;
+    mem_length =3D (unsigned long)ivmd_block->memory_length;
     base =3D start_addr & PAGE_MASK;
     limit =3D (start_addr + mem_length - 1) & PAGE_MASK;
=20
@@ -328,20 +355,14 @@ static int __init parse_ivmd_block(struc
     AMD_IOMMU_DEBUG(" Start_Addr_Phys 0x%lx\n", start_addr);
     AMD_IOMMU_DEBUG(" Mem_Length 0x%lx\n", mem_length);
=20
-    if ( get_field_from_byte(ivmd_block->header.flags,
-                             AMD_IOMMU_ACPI_EXCLUSION_RANGE_MASK,
-                             AMD_IOMMU_ACPI_EXCLUSION_RANGE_SHIFT) )
+    if ( ivmd_block->header.flags & ACPI_IVMD_EXCLUSION_RANGE )
         iw =3D ir =3D IOMMU_CONTROL_ENABLED;
-    else if ( get_field_from_byte(ivmd_block->header.flags,
-                                  AMD_IOMMU_ACPI_UNITY_MAPPING_MASK,
-                                  AMD_IOMMU_ACPI_UNITY_MAPPING_SHIFT) )
-    {
-        iw =3D get_field_from_byte(ivmd_block->header.flags,
-                                 AMD_IOMMU_ACPI_IW_PERMISSION_MASK,
-                                 AMD_IOMMU_ACPI_IW_PERMISSION_SHIFT);
-        ir =3D get_field_from_byte(ivmd_block->header.flags,
-                                 AMD_IOMMU_ACPI_IR_PERMISSION_MASK,
-                                 AMD_IOMMU_ACPI_IR_PERMISSION_SHIFT);
+    else if ( ivmd_block->header.flags & ACPI_IVMD_UNITY )
+    {
+        iw =3D ivmd_block->header.flags & ACPI_IVMD_READ ?
+            IOMMU_CONTROL_ENABLED : IOMMU_CONTROL_DISABLED;
+        ir =3D ivmd_block->header.flags & ACPI_IVMD_WRITE ?
+            IOMMU_CONTROL_ENABLED : IOMMU_CONTROL_DISABLED;
     }
     else
     {
@@ -351,19 +372,19 @@ static int __init parse_ivmd_block(struc
=20
     switch( ivmd_block->header.type )
     {
-    case AMD_IOMMU_ACPI_IVMD_ALL_TYPE:
+    case ACPI_IVRS_TYPE_MEMORY_ALL:
         return register_exclusion_range_for_all_devices(
             base, limit, iw, ir);
=20
-    case AMD_IOMMU_ACPI_IVMD_ONE_TYPE:
+    case ACPI_IVRS_TYPE_MEMORY_ONE:
         return parse_ivmd_device_select(ivmd_block,
                                         base, limit, iw, ir);
=20
-    case AMD_IOMMU_ACPI_IVMD_RANGE_TYPE:
+    case ACPI_IVRS_TYPE_MEMORY_RANGE:
         return parse_ivmd_device_range(ivmd_block,
                                        base, limit, iw, ir);
=20
-    case AMD_IOMMU_ACPI_IVMD_IOMMU_TYPE:
+    case ACPI_IVRS_TYPE_MEMORY_IOMMU:
         return parse_ivmd_device_iommu(ivmd_block,
                                        base, limit, iw, ir);
=20
@@ -386,45 +407,44 @@ static u16 __init parse_ivhd_device_padd
 }
=20
 static u16 __init parse_ivhd_device_select(
-    union acpi_ivhd_device *ivhd_device, struct amd_iommu *iommu)
+    const struct acpi_ivrs_device4 *select, struct amd_iommu *iommu)
 {
     u16 bdf;
=20
-    bdf =3D ivhd_device->header.dev_id;
+    bdf =3D select->header.id;
     if ( bdf >=3D ivrs_bdf_entries )
     {
         AMD_IOMMU_DEBUG("IVHD Error: Invalid Device_Entry Dev_Id 0x%x\n", =
bdf);
         return 0;
     }
=20
-    add_ivrs_mapping_entry(bdf, bdf, ivhd_device->header.flags, iommu);
+    add_ivrs_mapping_entry(bdf, bdf, select->header.data_setting, iommu);
=20
-    return sizeof(struct acpi_ivhd_device_header);
+    return sizeof(*select);
 }
=20
 static u16 __init parse_ivhd_device_range(
-    union acpi_ivhd_device *ivhd_device,
+    const struct acpi_ivhd_device_range *range,
     u16 header_length, u16 block_length, struct amd_iommu *iommu)
 {
     u16 dev_length, first_bdf, last_bdf, bdf;
=20
-    dev_length =3D sizeof(struct acpi_ivhd_device_range);
+    dev_length =3D sizeof(*range);
     if ( header_length < (block_length + dev_length) )
     {
         AMD_IOMMU_DEBUG("IVHD Error: Invalid Device_Entry Length!\n");
         return 0;
     }
=20
-    if ( ivhd_device->range.trailer.type !=3D
-         AMD_IOMMU_ACPI_IVHD_DEV_RANGE_END )
+    if ( range->end.header.type !=3D ACPI_IVRS_TYPE_END )
     {
         AMD_IOMMU_DEBUG("IVHD Error: "
                         "Invalid Range: End_Type 0x%x\n",
-                        ivhd_device->range.trailer.type);
+                        range->end.header.type);
         return 0;
     }
=20
-    first_bdf =3D ivhd_device->header.dev_id;
+    first_bdf =3D range->start.header.id;
     if ( first_bdf >=3D ivrs_bdf_entries )
     {
         AMD_IOMMU_DEBUG("IVHD Error: "
@@ -432,7 +452,7 @@ static u16 __init parse_ivhd_device_rang
         return 0;
     }
=20
-    last_bdf =3D ivhd_device->range.trailer.dev_id;
+    last_bdf =3D range->end.header.id;
     if ( (last_bdf >=3D ivrs_bdf_entries) || (last_bdf <=3D first_bdf) )
     {
         AMD_IOMMU_DEBUG("IVHD Error: "
@@ -443,32 +463,33 @@ static u16 __init parse_ivhd_device_rang
     AMD_IOMMU_DEBUG(" Dev_Id Range: 0x%x -> 0x%x\n", first_bdf, last_bdf);=

=20
     for ( bdf =3D first_bdf; bdf <=3D last_bdf; bdf++ )
-        add_ivrs_mapping_entry(bdf, bdf, ivhd_device->header.flags, =
iommu);
+        add_ivrs_mapping_entry(bdf, bdf, range->start.header.data_setting,=

+                               iommu);
=20
     return dev_length;
 }
=20
 static u16 __init parse_ivhd_device_alias(
-    union acpi_ivhd_device *ivhd_device,
+    const struct acpi_ivrs_device8a *alias,
     u16 header_length, u16 block_length, struct amd_iommu *iommu)
 {
     u16 dev_length, alias_id, bdf;
=20
-    dev_length =3D sizeof(struct acpi_ivhd_device_alias);
+    dev_length =3D sizeof(*alias);
     if ( header_length < (block_length + dev_length) )
     {
         AMD_IOMMU_DEBUG("IVHD Error: Invalid Device_Entry Length!\n");
         return 0;
     }
=20
-    bdf =3D ivhd_device->header.dev_id;
+    bdf =3D alias->header.id;
     if ( bdf >=3D ivrs_bdf_entries )
     {
         AMD_IOMMU_DEBUG("IVHD Error: Invalid Device_Entry Dev_Id 0x%x\n", =
bdf);
         return 0;
     }
=20
-    alias_id =3D ivhd_device->alias.dev_id;
+    alias_id =3D alias->used_id;
     if ( alias_id >=3D ivrs_bdf_entries )
     {
         AMD_IOMMU_DEBUG("IVHD Error: Invalid Alias Dev_Id 0x%x\n", =
alias_id);
@@ -477,35 +498,34 @@ static u16 __init parse_ivhd_device_alia
=20
     AMD_IOMMU_DEBUG(" Dev_Id Alias: 0x%x\n", alias_id);
=20
-    add_ivrs_mapping_entry(bdf, alias_id, ivhd_device->header.flags, =
iommu);
+    add_ivrs_mapping_entry(bdf, alias_id, alias->header.data_setting, =
iommu);
=20
     return dev_length;
 }
=20
 static u16 __init parse_ivhd_device_alias_range(
-    union acpi_ivhd_device *ivhd_device,
+    const struct acpi_ivhd_device_alias_range *range,
     u16 header_length, u16 block_length, struct amd_iommu *iommu)
 {
=20
     u16 dev_length, first_bdf, last_bdf, alias_id, bdf;
=20
-    dev_length =3D sizeof(struct acpi_ivhd_device_alias_range);
+    dev_length =3D sizeof(*range);
     if ( header_length < (block_length + dev_length) )
     {
         AMD_IOMMU_DEBUG("IVHD Error: Invalid Device_Entry Length!\n");
         return 0;
     }
=20
-    if ( ivhd_device->alias_range.trailer.type !=3D
-         AMD_IOMMU_ACPI_IVHD_DEV_RANGE_END )
+    if ( range->end.header.type !=3D ACPI_IVRS_TYPE_END )
     {
         AMD_IOMMU_DEBUG("IVHD Error: "
                         "Invalid Range: End_Type 0x%x\n",
-                        ivhd_device->alias_range.trailer.type);
+                        range->end.header.type);
         return 0;
     }
=20
-    first_bdf =3D ivhd_device->header.dev_id;
+    first_bdf =3D range->alias.header.id;
     if ( first_bdf >=3D ivrs_bdf_entries )
     {
         AMD_IOMMU_DEBUG("IVHD Error: "
@@ -513,7 +533,7 @@ static u16 __init parse_ivhd_device_alia
         return 0;
     }
=20
-    last_bdf =3D ivhd_device->alias_range.trailer.dev_id;
+    last_bdf =3D range->end.header.id;
     if ( last_bdf >=3D ivrs_bdf_entries || last_bdf <=3D first_bdf )
     {
         AMD_IOMMU_DEBUG(
@@ -521,7 +541,7 @@ static u16 __init parse_ivhd_device_alia
         return 0;
     }
=20
-    alias_id =3D ivhd_device->alias_range.alias.dev_id;
+    alias_id =3D range->alias.used_id;
     if ( alias_id >=3D ivrs_bdf_entries )
     {
         AMD_IOMMU_DEBUG("IVHD Error: Invalid Alias Dev_Id 0x%x\n", =
alias_id);
@@ -532,59 +552,59 @@ static u16 __init parse_ivhd_device_alia
     AMD_IOMMU_DEBUG(" Dev_Id Alias: 0x%x\n", alias_id);
=20
     for ( bdf =3D first_bdf; bdf <=3D last_bdf; bdf++ )
-        add_ivrs_mapping_entry(bdf, alias_id, ivhd_device->header.flags, =
iommu);
+        add_ivrs_mapping_entry(bdf, alias_id, range->alias.header.data_set=
ting,
+                               iommu);
=20
     return dev_length;
 }
=20
 static u16 __init parse_ivhd_device_extended(
-    union acpi_ivhd_device *ivhd_device,
+    const struct acpi_ivrs_device8b *ext,
     u16 header_length, u16 block_length, struct amd_iommu *iommu)
 {
     u16 dev_length, bdf;
=20
-    dev_length =3D sizeof(struct acpi_ivhd_device_extended);
+    dev_length =3D sizeof(*ext);
     if ( header_length < (block_length + dev_length) )
     {
         AMD_IOMMU_DEBUG("IVHD Error: Invalid Device_Entry Length!\n");
         return 0;
     }
=20
-    bdf =3D ivhd_device->header.dev_id;
+    bdf =3D ext->header.id;
     if ( bdf >=3D ivrs_bdf_entries )
     {
         AMD_IOMMU_DEBUG("IVHD Error: Invalid Device_Entry Dev_Id 0x%x\n", =
bdf);
         return 0;
     }
=20
-    add_ivrs_mapping_entry(bdf, bdf, ivhd_device->header.flags, iommu);
+    add_ivrs_mapping_entry(bdf, bdf, ext->header.data_setting, iommu);
=20
     return dev_length;
 }
=20
 static u16 __init parse_ivhd_device_extended_range(
-    union acpi_ivhd_device *ivhd_device,
+    const struct acpi_ivhd_device_extended_range *range,
     u16 header_length, u16 block_length, struct amd_iommu *iommu)
 {
     u16 dev_length, first_bdf, last_bdf, bdf;
=20
-    dev_length =3D sizeof(struct acpi_ivhd_device_extended_range);
+    dev_length =3D sizeof(*range);
     if ( header_length < (block_length + dev_length) )
     {
         AMD_IOMMU_DEBUG("IVHD Error: Invalid Device_Entry Length!\n");
         return 0;
     }
=20
-    if ( ivhd_device->extended_range.trailer.type !=3D
-         AMD_IOMMU_ACPI_IVHD_DEV_RANGE_END )
+    if ( range->end.header.type !=3D ACPI_IVRS_TYPE_END )
     {
         AMD_IOMMU_DEBUG("IVHD Error: "
                         "Invalid Range: End_Type 0x%x\n",
-                        ivhd_device->extended_range.trailer.type);
+                        range->end.header.type);
         return 0;
     }
=20
-    first_bdf =3D ivhd_device->header.dev_id;
+    first_bdf =3D range->extended.header.id;
     if ( first_bdf >=3D ivrs_bdf_entries )
     {
         AMD_IOMMU_DEBUG("IVHD Error: "
@@ -592,7 +612,7 @@ static u16 __init parse_ivhd_device_exte
         return 0;
     }
=20
-    last_bdf =3D ivhd_device->extended_range.trailer.dev_id;
+    last_bdf =3D range->end.header.id;
     if ( (last_bdf >=3D ivrs_bdf_entries) || (last_bdf <=3D first_bdf) )
     {
         AMD_IOMMU_DEBUG("IVHD Error: "
@@ -604,116 +624,116 @@ static u16 __init parse_ivhd_device_exte
                     first_bdf, last_bdf);
=20
     for ( bdf =3D first_bdf; bdf <=3D last_bdf; bdf++ )
-        add_ivrs_mapping_entry(bdf, bdf, ivhd_device->header.flags, =
iommu);
+        add_ivrs_mapping_entry(bdf, bdf, range->extended.header.data_setti=
ng,
+                               iommu);
=20
     return dev_length;
 }
=20
 static u16 __init parse_ivhd_device_special(
-    union acpi_ivhd_device *ivhd_device, u16 seg,
+    const struct acpi_ivrs_device8c *special, u16 seg,
     u16 header_length, u16 block_length, struct amd_iommu *iommu)
 {
     u16 dev_length, bdf;
=20
-    dev_length =3D sizeof(struct acpi_ivhd_device_special);
+    dev_length =3D sizeof(*special);
     if ( header_length < (block_length + dev_length) )
     {
         AMD_IOMMU_DEBUG("IVHD Error: Invalid Device_Entry Length!\n");
         return 0;
     }
=20
-    bdf =3D ivhd_device->special.dev_id;
+    bdf =3D special->used_id;
     if ( bdf >=3D ivrs_bdf_entries )
     {
         AMD_IOMMU_DEBUG("IVHD Error: Invalid Device_Entry Dev_Id 0x%x\n", =
bdf);
         return 0;
     }
=20
-    add_ivrs_mapping_entry(bdf, bdf, ivhd_device->header.flags, iommu);
+    add_ivrs_mapping_entry(bdf, bdf, special->header.data_setting, =
iommu);
     /* set device id of ioapic */
-    ioapic_sbdf[ivhd_device->special.handle].bdf =3D bdf;
-    ioapic_sbdf[ivhd_device->special.handle].seg =3D seg;
+    ioapic_sbdf[special->handle].bdf =3D bdf;
+    ioapic_sbdf[special->handle].seg =3D seg;
     return dev_length;
 }
=20
-static int __init parse_ivhd_block(struct acpi_ivhd_block_header =
*ivhd_block)
+static int __init parse_ivhd_block(const struct acpi_ivrs_hardware =
*ivhd_block)
 {
-    union acpi_ivhd_device *ivhd_device;
+    const union acpi_ivhd_device *ivhd_device;
     u16 block_length, dev_length;
     struct amd_iommu *iommu;
=20
-    if ( ivhd_block->header.length <
-         sizeof(struct acpi_ivhd_block_header) )
+    if ( ivhd_block->header.length < sizeof(*ivhd_block) )
     {
         AMD_IOMMU_DEBUG("IVHD Error: Invalid Block Length!\n");
         return -ENODEV;
     }
=20
-    iommu =3D find_iommu_from_bdf_cap(ivhd_block->header.dev_id,
-                                    ivhd_block->cap_offset);
+    iommu =3D find_iommu_from_bdf_cap(ivhd_block->header.device_id,
+                                    ivhd_block->capability_offset);
     if ( !iommu )
     {
         AMD_IOMMU_DEBUG("IVHD Error: No IOMMU for Dev_Id 0x%x  Cap =
0x%x\n",
-                        ivhd_block->header.dev_id, ivhd_block->cap_offset)=
;
+                        ivhd_block->header.device_id,
+                        ivhd_block->capability_offset);
         return -ENODEV;
     }
=20
     /* parse Device Entries */
-    block_length =3D sizeof(struct acpi_ivhd_block_header);
+    block_length =3D sizeof(*ivhd_block);
     while ( ivhd_block->header.length >=3D
-            (block_length + sizeof(struct acpi_ivhd_device_header)) )
+            (block_length + sizeof(struct acpi_ivrs_de_header)) )
     {
-        ivhd_device =3D (union acpi_ivhd_device *)
-            ((u8 *)ivhd_block + block_length);
+        ivhd_device =3D (const void *)((const u8 *)ivhd_block + block_leng=
th);
=20
         AMD_IOMMU_DEBUG( "IVHD Device Entry:\n");
         AMD_IOMMU_DEBUG( " Type 0x%x\n", ivhd_device->header.type);
-        AMD_IOMMU_DEBUG( " Dev_Id 0x%x\n", ivhd_device->header.dev_id);
-        AMD_IOMMU_DEBUG( " Flags 0x%x\n", ivhd_device->header.flags);
+        AMD_IOMMU_DEBUG( " Dev_Id 0x%x\n", ivhd_device->header.id);
+        AMD_IOMMU_DEBUG( " Flags 0x%x\n", ivhd_device->header.data_setting=
);
=20
         switch ( ivhd_device->header.type )
         {
-        case AMD_IOMMU_ACPI_IVHD_DEV_U32_PAD:
+        case ACPI_IVRS_TYPE_PAD4:
             dev_length =3D parse_ivhd_device_padding(
                 sizeof(u32),
                 ivhd_block->header.length, block_length);
             break;
-        case AMD_IOMMU_ACPI_IVHD_DEV_U64_PAD:
+        case ACPI_IVRS_TYPE_PAD8:
             dev_length =3D parse_ivhd_device_padding(
                 sizeof(u64),
                 ivhd_block->header.length, block_length);
             break;
-        case AMD_IOMMU_ACPI_IVHD_DEV_SELECT:
-            dev_length =3D parse_ivhd_device_select(ivhd_device, iommu);
+        case ACPI_IVRS_TYPE_SELECT:
+            dev_length =3D parse_ivhd_device_select(&ivhd_device->select, =
iommu);
             break;
-        case AMD_IOMMU_ACPI_IVHD_DEV_RANGE_START:
+        case ACPI_IVRS_TYPE_START:
             dev_length =3D parse_ivhd_device_range(
-                ivhd_device,
+                &ivhd_device->range,
                 ivhd_block->header.length, block_length, iommu);
             break;
-        case AMD_IOMMU_ACPI_IVHD_DEV_ALIAS_SELECT:
+        case ACPI_IVRS_TYPE_ALIAS_SELECT:
             dev_length =3D parse_ivhd_device_alias(
-                ivhd_device,
+                &ivhd_device->alias,
                 ivhd_block->header.length, block_length, iommu);
             break;
-        case AMD_IOMMU_ACPI_IVHD_DEV_ALIAS_RANGE:
+        case ACPI_IVRS_TYPE_ALIAS_START:
             dev_length =3D parse_ivhd_device_alias_range(
-                ivhd_device,
+                &ivhd_device->alias_range,
                 ivhd_block->header.length, block_length, iommu);
             break;
-        case AMD_IOMMU_ACPI_IVHD_DEV_EXT_SELECT:
+        case ACPI_IVRS_TYPE_EXT_SELECT:
             dev_length =3D parse_ivhd_device_extended(
-                ivhd_device,
+                &ivhd_device->extended,
                 ivhd_block->header.length, block_length, iommu);
             break;
-        case AMD_IOMMU_ACPI_IVHD_DEV_EXT_RANGE:
+        case ACPI_IVRS_TYPE_EXT_START:
             dev_length =3D parse_ivhd_device_extended_range(
-                ivhd_device,
+                &ivhd_device->extended_range,
                 ivhd_block->header.length, block_length, iommu);
             break;
-        case AMD_IOMMU_ACPI_IVHD_DEV_SPECIAL:
+        case ACPI_IVRS_TYPE_SPECIAL:
             dev_length =3D parse_ivhd_device_special(
-                ivhd_device, ivhd_block->pci_segment,
+                &ivhd_device->special, ivhd_block->pci_segment_group,
                 ivhd_block->header.length, block_length, iommu);
             break;
         default:
@@ -730,22 +750,24 @@ static int __init parse_ivhd_block(struc
     return 0;
 }
=20
-static int __init parse_ivrs_block(struct acpi_ivrs_block_header =
*ivrs_block)
+static int __init parse_ivrs_block(const struct acpi_ivrs_header =
*ivrs_block)
 {
-    struct acpi_ivhd_block_header *ivhd_block;
-    struct acpi_ivmd_block_header *ivmd_block;
+    const struct acpi_ivrs_hardware *ivhd_block;
+    const struct acpi_ivrs_memory *ivmd_block;
=20
     switch ( ivrs_block->type )
     {
-    case AMD_IOMMU_ACPI_IVHD_TYPE:
-        ivhd_block =3D (struct acpi_ivhd_block_header *)ivrs_block;
+    case ACPI_IVRS_TYPE_HARDWARE:
+        ivhd_block =3D container_of(ivrs_block, const struct acpi_ivrs_har=
dware,
+                                  header);
         return parse_ivhd_block(ivhd_block);
=20
-    case AMD_IOMMU_ACPI_IVMD_ALL_TYPE:
-    case AMD_IOMMU_ACPI_IVMD_ONE_TYPE:
-    case AMD_IOMMU_ACPI_IVMD_RANGE_TYPE:
-    case AMD_IOMMU_ACPI_IVMD_IOMMU_TYPE:
-        ivmd_block =3D (struct acpi_ivmd_block_header *)ivrs_block;
+    case ACPI_IVRS_TYPE_MEMORY_ALL:
+    case ACPI_IVRS_TYPE_MEMORY_ONE:
+    case ACPI_IVRS_TYPE_MEMORY_RANGE:
+    case ACPI_IVRS_TYPE_MEMORY_IOMMU:
+        ivmd_block =3D container_of(ivrs_block, const struct acpi_ivrs_mem=
ory,
+                                  header);
         return parse_ivmd_block(ivmd_block);
=20
     default:
@@ -792,12 +814,11 @@ static void __init dump_acpi_table_heade
=20
 }
=20
-static int __init parse_ivrs_table(struct acpi_table_header *_table)
+static int __init parse_ivrs_table(struct acpi_table_header *table)
 {
-    struct acpi_ivrs_block_header *ivrs_block;
+    const struct acpi_ivrs_header *ivrs_block;
     unsigned long length;
     int error =3D 0;
-    struct acpi_table_header *table =3D (struct acpi_table_header =
*)_table;
=20
     BUG_ON(!table);
=20
@@ -805,17 +826,16 @@ static int __init parse_ivrs_table(struc
         dump_acpi_table_header(table);
=20
     /* parse IVRS blocks */
-    length =3D sizeof(struct acpi_ivrs_table_header);
+    length =3D sizeof(struct acpi_table_ivrs);
     while ( (error =3D=3D 0) && (table->length > (length + sizeof(*ivrs_bl=
ock))) )
     {
-        ivrs_block =3D (struct acpi_ivrs_block_header *)
-            ((u8 *)table + length);
+        ivrs_block =3D (struct acpi_ivrs_header *)((u8 *)table + length);
=20
         AMD_IOMMU_DEBUG("IVRS Block:\n");
         AMD_IOMMU_DEBUG(" Type 0x%x\n", ivrs_block->type);
         AMD_IOMMU_DEBUG(" Flags 0x%x\n", ivrs_block->flags);
         AMD_IOMMU_DEBUG(" Length 0x%x\n", ivrs_block->length);
-        AMD_IOMMU_DEBUG(" Dev_Id 0x%x\n", ivrs_block->dev_id);
+        AMD_IOMMU_DEBUG(" Dev_Id 0x%x\n", ivrs_block->device_id);
=20
         if ( table->length < (length + ivrs_block->length) )
         {
@@ -833,12 +853,11 @@ static int __init parse_ivrs_table(struc
     return error;
 }
=20
-static int __init detect_iommu_acpi(struct acpi_table_header *_table)
+static int __init detect_iommu_acpi(struct acpi_table_header *table)
 {
-    struct acpi_ivrs_block_header *ivrs_block;
-    struct acpi_table_header *table =3D (struct acpi_table_header =
*)_table;
+    const struct acpi_ivrs_header *ivrs_block;
     unsigned long i;
-    unsigned long length =3D sizeof(struct acpi_ivrs_table_header);
+    unsigned long length =3D sizeof(struct acpi_table_ivrs);
     u8 checksum, *raw_table;
=20
     /* validate checksum: sum of entire table =3D=3D 0 */
@@ -854,12 +873,14 @@ static int __init detect_iommu_acpi(stru
=20
     while ( table->length > (length + sizeof(*ivrs_block)) )
     {
-        ivrs_block =3D (struct acpi_ivrs_block_header *) ((u8 *)table + =
length);
+        ivrs_block =3D (struct acpi_ivrs_header *)((u8 *)table + length);
         if ( table->length < (length + ivrs_block->length) )
             return -ENODEV;
-        if ( ivrs_block->type =3D=3D AMD_IOMMU_ACPI_IVHD_TYPE )
-            if ( amd_iommu_detect_one_acpi((void*)ivrs_block) !=3D 0 )
-                return -ENODEV;
+        if ( ivrs_block->type =3D=3D ACPI_IVRS_TYPE_HARDWARE &&
+             amd_iommu_detect_one_acpi(
+                 container_of(ivrs_block, const struct acpi_ivrs_hardware,=

+                              header)) !=3D 0 )
+            return -ENODEV;
         length +=3D ivrs_block->length;
     }
     return 0;
@@ -870,63 +891,59 @@ static int __init detect_iommu_acpi(stru
        last_bdf =3D (x); \
    } while(0);
=20
-static int __init get_last_bdf_ivhd(void *ivhd)
+static int __init get_last_bdf_ivhd(
+    const struct acpi_ivrs_hardware *ivhd_block)
 {
-    union acpi_ivhd_device *ivhd_device;
+    const union acpi_ivhd_device *ivhd_device;
     u16 block_length, dev_length;
-    struct acpi_ivhd_block_header *ivhd_block;
-
-    ivhd_block =3D (struct acpi_ivhd_block_header *)ivhd;
=20
-    if ( ivhd_block->header.length <
-         sizeof(struct acpi_ivhd_block_header) )
+    if ( ivhd_block->header.length < sizeof(*ivhd_block) )
     {
         AMD_IOMMU_DEBUG("IVHD Error: Invalid Block Length!\n");
         return -ENODEV;
     }
=20
-    block_length =3D sizeof(struct acpi_ivhd_block_header);
+    block_length =3D sizeof(*ivhd_block);
     while ( ivhd_block->header.length >=3D
-            (block_length + sizeof(struct acpi_ivhd_device_header)) )
+            (block_length + sizeof(struct acpi_ivrs_de_header)) )
     {
-        ivhd_device =3D (union acpi_ivhd_device *)
-            ((u8 *)ivhd_block + block_length);
+        ivhd_device =3D (const void *)((u8 *)ivhd_block + block_length);
=20
         switch ( ivhd_device->header.type )
         {
-        case AMD_IOMMU_ACPI_IVHD_DEV_U32_PAD:
+        case ACPI_IVRS_TYPE_PAD4:
             dev_length =3D sizeof(u32);
             break;
-        case AMD_IOMMU_ACPI_IVHD_DEV_U64_PAD:
+        case ACPI_IVRS_TYPE_PAD8:
             dev_length =3D sizeof(u64);
             break;
-        case AMD_IOMMU_ACPI_IVHD_DEV_SELECT:
-            UPDATE_LAST_BDF(ivhd_device->header.dev_id);
-            dev_length =3D sizeof(struct acpi_ivhd_device_header);
-            break;
-        case AMD_IOMMU_ACPI_IVHD_DEV_ALIAS_SELECT:
-            UPDATE_LAST_BDF(ivhd_device->header.dev_id);
-            dev_length =3D sizeof(struct acpi_ivhd_device_alias);
-            break;
-        case AMD_IOMMU_ACPI_IVHD_DEV_EXT_SELECT:
-            UPDATE_LAST_BDF(ivhd_device->header.dev_id);
-            dev_length =3D sizeof(struct acpi_ivhd_device_extended);
-            break;
-        case AMD_IOMMU_ACPI_IVHD_DEV_RANGE_START:
-            UPDATE_LAST_BDF(ivhd_device->range.trailer.dev_id);
-            dev_length =3D sizeof(struct acpi_ivhd_device_range);
-            break;
-        case AMD_IOMMU_ACPI_IVHD_DEV_ALIAS_RANGE:
-            UPDATE_LAST_BDF(ivhd_device->alias_range.trailer.dev_id)
-            dev_length =3D sizeof(struct acpi_ivhd_device_alias_range);
-            break;
-        case AMD_IOMMU_ACPI_IVHD_DEV_EXT_RANGE:
-            UPDATE_LAST_BDF(ivhd_device->extended_range.trailer.dev_id)
-            dev_length =3D sizeof(struct acpi_ivhd_device_extended_range);=

-            break;
-        case AMD_IOMMU_ACPI_IVHD_DEV_SPECIAL:
-            UPDATE_LAST_BDF(ivhd_device->special.dev_id)
-            dev_length =3D sizeof(struct acpi_ivhd_device_special);
+        case ACPI_IVRS_TYPE_SELECT:
+            UPDATE_LAST_BDF(ivhd_device->select.header.id);
+            dev_length =3D sizeof(ivhd_device->header);
+            break;
+        case ACPI_IVRS_TYPE_ALIAS_SELECT:
+            UPDATE_LAST_BDF(ivhd_device->alias.header.id);
+            dev_length =3D sizeof(ivhd_device->alias);
+            break;
+        case ACPI_IVRS_TYPE_EXT_SELECT:
+            UPDATE_LAST_BDF(ivhd_device->extended.header.id);
+            dev_length =3D sizeof(ivhd_device->extended);
+            break;
+        case ACPI_IVRS_TYPE_START:
+            UPDATE_LAST_BDF(ivhd_device->range.end.header.id);
+            dev_length =3D sizeof(ivhd_device->range);
+            break;
+        case ACPI_IVRS_TYPE_ALIAS_START:
+            UPDATE_LAST_BDF(ivhd_device->alias_range.end.header.id)
+            dev_length =3D sizeof(ivhd_device->alias_range);
+            break;
+        case ACPI_IVRS_TYPE_EXT_START:
+            UPDATE_LAST_BDF(ivhd_device->extended_range.end.header.id)
+            dev_length =3D sizeof(ivhd_device->extended_range);
+            break;
+        case ACPI_IVRS_TYPE_SPECIAL:
+            UPDATE_LAST_BDF(ivhd_device->special.used_id)
+            dev_length =3D sizeof(ivhd_device->special);
             break;
         default:
             AMD_IOMMU_DEBUG("IVHD Error: Invalid Device Type!\n");
@@ -942,20 +959,21 @@ static int __init get_last_bdf_ivhd(void
     return 0;
 }
=20
-static int __init get_last_bdf_acpi(struct acpi_table_header *_table)
+static int __init get_last_bdf_acpi(struct acpi_table_header *table)
 {
-    struct acpi_ivrs_block_header *ivrs_block;
-    struct acpi_table_header *table =3D (struct acpi_table_header =
*)_table;
-    unsigned long length =3D sizeof(struct acpi_ivrs_table_header);
+    const struct acpi_ivrs_header *ivrs_block;
+    unsigned long length =3D sizeof(struct acpi_table_ivrs);
=20
     while ( table->length > (length + sizeof(*ivrs_block)) )
     {
-        ivrs_block =3D (struct acpi_ivrs_block_header *) ((u8 *)table + =
length);
+        ivrs_block =3D (struct acpi_ivrs_header *)((u8 *)table + length);
         if ( table->length < (length + ivrs_block->length) )
             return -ENODEV;
-        if ( ivrs_block->type =3D=3D AMD_IOMMU_ACPI_IVHD_TYPE )
-            if ( get_last_bdf_ivhd((void*)ivrs_block) !=3D 0 )
-                return -ENODEV;
+        if ( ivrs_block->type =3D=3D ACPI_IVRS_TYPE_HARDWARE &&
+             get_last_bdf_ivhd(
+                 container_of(ivrs_block, const struct acpi_ivrs_hardware,=

+                              header)) !=3D 0 )
+            return -ENODEV;
         length +=3D ivrs_block->length;
     }
    return 0;
@@ -963,16 +981,16 @@ static int __init get_last_bdf_acpi(stru
=20
 int __init amd_iommu_detect_acpi(void)
 {
-    return acpi_table_parse(AMD_IOMMU_ACPI_IVRS_SIG, detect_iommu_acpi);
+    return acpi_table_parse(ACPI_SIG_IVRS, detect_iommu_acpi);
 }
=20
 int __init amd_iommu_get_ivrs_dev_entries(void)
 {
-    acpi_table_parse(AMD_IOMMU_ACPI_IVRS_SIG, get_last_bdf_acpi);
+    acpi_table_parse(ACPI_SIG_IVRS, get_last_bdf_acpi);
     return last_bdf + 1;
 }
=20
 int __init amd_iommu_update_ivrs_mapping_acpi(void)
 {
-    return acpi_table_parse(AMD_IOMMU_ACPI_IVRS_SIG, parse_ivrs_table);
+    return acpi_table_parse(ACPI_SIG_IVRS, parse_ivrs_table);
 }
--- a/xen/drivers/passthrough/amd/iommu_detect.c
+++ b/xen/drivers/passthrough/amd/iommu_detect.c
@@ -20,12 +20,12 @@
=20
 #include <xen/config.h>
 #include <xen/errno.h>
+#include <xen/acpi.h>
 #include <xen/iommu.h>
 #include <xen/pci.h>
 #include <xen/pci_regs.h>
 #include <asm/amd-iommu.h>
 #include <asm/hvm/svm/amd-iommu-proto.h>
-#include <asm/hvm/svm/amd-iommu-acpi.h>
=20
 static int __init get_iommu_msi_capabilities(
     u16 seg, u8 bus, u8 dev, u8 func, struct amd_iommu *iommu)
@@ -103,23 +103,21 @@ void __init get_iommu_features(struct am
     }
 }
=20
-int __init amd_iommu_detect_one_acpi(void *ivhd)
+int __init amd_iommu_detect_one_acpi(
+    const struct acpi_ivrs_hardware *ivhd_block)
 {
     struct amd_iommu *iommu;
     u8 bus, dev, func;
-    struct acpi_ivhd_block_header *ivhd_block;
     int rt =3D 0;
=20
-    ivhd_block =3D (struct acpi_ivhd_block_header *)ivhd;
-
-    if ( ivhd_block->header.length < sizeof(struct acpi_ivhd_block_header)=
 )
+    if ( ivhd_block->header.length < sizeof(*ivhd_block) )
     {
         AMD_IOMMU_DEBUG("Invalid IVHD Block Length!\n");
         return -ENODEV;
     }
=20
-    if ( !ivhd_block->header.dev_id ||
-        !ivhd_block->cap_offset || !ivhd_block->mmio_base)
+    if ( !ivhd_block->header.device_id ||
+        !ivhd_block->capability_offset || !ivhd_block->base_address)
     {
         AMD_IOMMU_DEBUG("Invalid IVHD Block!\n");
         return -ENODEV;
@@ -134,10 +132,10 @@ int __init amd_iommu_detect_one_acpi(voi
=20
     spin_lock_init(&iommu->lock);
=20
-    iommu->seg =3D ivhd_block->pci_segment;
-    iommu->bdf =3D ivhd_block->header.dev_id;
-    iommu->cap_offset =3D ivhd_block->cap_offset;
-    iommu->mmio_base_phys =3D ivhd_block->mmio_base;
+    iommu->seg =3D ivhd_block->pci_segment_group;
+    iommu->bdf =3D ivhd_block->header.device_id;
+    iommu->cap_offset =3D ivhd_block->capability_offset;
+    iommu->mmio_base_phys =3D ivhd_block->base_address;
=20
     /* override IOMMU HT flags */
     iommu->ht_flags =3D ivhd_block->header.flags;
--- a/xen/drivers/passthrough/amd/iommu_init.c
+++ b/xen/drivers/passthrough/amd/iommu_init.c
@@ -20,6 +20,7 @@
=20
 #include <xen/config.h>
 #include <xen/errno.h>
+#include <xen/acpi.h>
 #include <xen/pci.h>
 #include <xen/pci_regs.h>
 #include <xen/irq.h>
@@ -28,7 +29,6 @@
 #include <asm/hvm/svm/amd-iommu-proto.h>
 #include <asm-x86/fixmap.h>
 #include <mach_apic.h>
-#include <asm/hvm/svm/amd-iommu-acpi.h>
=20
 static int __initdata nr_amd_iommus;
=20
@@ -37,9 +37,8 @@ static struct radix_tree_root ivrs_maps;
 struct list_head amd_iommu_head;
 struct table_struct device_table;
=20
-static int iommu_has_ht_flag(struct amd_iommu *iommu, uint8_t bit)
+static int iommu_has_ht_flag(struct amd_iommu *iommu, u8 mask)
 {
-    u8 mask =3D 1U << bit;
     return iommu->ht_flags & mask;
 }
=20
@@ -80,19 +79,19 @@ static void set_iommu_ht_flags(struct am
=20
     /* Setup HT flags */
     if ( iommu_has_cap(iommu, PCI_CAP_HT_TUNNEL_SHIFT) )
-        iommu_has_ht_flag(iommu, AMD_IOMMU_ACPI_HT_TUN_ENB_SHIFT) ?
+        iommu_has_ht_flag(iommu, ACPI_IVHD_TT_ENABLE) ?
             iommu_set_bit(&entry, IOMMU_CONTROL_HT_TUNNEL_TRANSLATION_SHIF=
T) :
             iommu_clear_bit(&entry, IOMMU_CONTROL_HT_TUNNEL_TRANSLATION_SH=
IFT);
=20
-    iommu_has_ht_flag(iommu, AMD_IOMMU_ACPI_RES_PASS_PW_SHIFT) ?
+    iommu_has_ht_flag(iommu, ACPI_IVHD_RES_PASS_PW) ?
         iommu_set_bit(&entry, IOMMU_CONTROL_RESP_PASS_POSTED_WRITE_SHIFT):=

         iommu_clear_bit(&entry, IOMMU_CONTROL_RESP_PASS_POSTED_WRITE_SHIFT=
);
=20
-    iommu_has_ht_flag(iommu, AMD_IOMMU_ACPI_ISOC_SHIFT) ?
+    iommu_has_ht_flag(iommu, ACPI_IVHD_ISOC) ?
         iommu_set_bit(&entry, IOMMU_CONTROL_ISOCHRONOUS_SHIFT):
         iommu_clear_bit(&entry, IOMMU_CONTROL_ISOCHRONOUS_SHIFT);
=20
-    iommu_has_ht_flag(iommu, AMD_IOMMU_ACPI_PASS_PW_SHIFT) ?
+    iommu_has_ht_flag(iommu, ACPI_IVHD_PASS_PW) ?
         iommu_set_bit(&entry, IOMMU_CONTROL_PASS_POSTED_WRITE_SHIFT):
         iommu_clear_bit(&entry, IOMMU_CONTROL_PASS_POSTED_WRITE_SHIFT);
=20
--- a/xen/drivers/passthrough/amd/iommu_map.c
+++ b/xen/drivers/passthrough/amd/iommu_map.c
@@ -18,12 +18,13 @@
  * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307 =
USA
  */
=20
+#include <xen/config.h>
+#include <xen/acpi.h>
 #include <xen/sched.h>
 #include <asm/p2m.h>
 #include <xen/hvm/iommu.h>
 #include <asm/amd-iommu.h>
 #include <asm/hvm/svm/amd-iommu-proto.h>
-#include <asm/hvm/svm/amd-iommu-acpi.h>
 #include "../ats.h"
 #include <xen/pci.h>
=20
@@ -215,8 +216,7 @@ void __init iommu_dte_add_device_entry(u
     dte[7] =3D dte[6] =3D dte[4] =3D dte[2] =3D dte[1] =3D dte[0] =3D 0;
=20
     flags =3D ivrs_dev->device_flags;
-    sys_mgt =3D get_field_from_byte(flags, AMD_IOMMU_ACPI_SYS_MGT_MASK,
-                                  AMD_IOMMU_ACPI_SYS_MGT_SHIFT);
+    sys_mgt =3D get_field_from_byte(flags, ACPI_IVHD_SYSTEM_MGMT);
     dev_ex =3D ivrs_dev->dte_allow_exclusion;
=20
     flags &=3D mask;
--- a/xen/include/asm-x86/hvm/svm/amd-iommu-acpi.h
+++ /dev/null
@@ -1,185 +0,0 @@
-/*
- * Copyright (C) 2007 Advanced Micro Devices, Inc.
- * Author: Leo Duran <leo.duran@amd.com>
- * Author: Wei Wang <wei.wang2@amd.com> - adapted to xen
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307 =
USA
- */
-
-#ifndef _ASM_X86_64_AMD_IOMMU_ACPI_H
-#define _ASM_X86_64_AMD_IOMMU_ACPI_H
-
-#include <xen/acpi.h>
-
-/* I/O Virtualization Reporting Structure */
-#define AMD_IOMMU_ACPI_IVRS_SIG            "IVRS"
-#define AMD_IOMMU_ACPI_IVHD_TYPE       0x10
-#define AMD_IOMMU_ACPI_IVMD_ALL_TYPE       0x20
-#define AMD_IOMMU_ACPI_IVMD_ONE_TYPE       0x21
-#define AMD_IOMMU_ACPI_IVMD_RANGE_TYPE     0x22
-#define AMD_IOMMU_ACPI_IVMD_IOMMU_TYPE     0x23
-
-/* 4-byte Device Entries */
-#define AMD_IOMMU_ACPI_IVHD_DEV_U32_PAD        0
-#define AMD_IOMMU_ACPI_IVHD_DEV_SELECT     2
-#define AMD_IOMMU_ACPI_IVHD_DEV_RANGE_START    3
-#define AMD_IOMMU_ACPI_IVHD_DEV_RANGE_END  4
-
-/* 8-byte Device Entries */
-#define AMD_IOMMU_ACPI_IVHD_DEV_U64_PAD        64
-#define AMD_IOMMU_ACPI_IVHD_DEV_ALIAS_SELECT   66
-#define AMD_IOMMU_ACPI_IVHD_DEV_ALIAS_RANGE    67
-#define AMD_IOMMU_ACPI_IVHD_DEV_EXT_SELECT 70
-#define AMD_IOMMU_ACPI_IVHD_DEV_EXT_RANGE  71
-#define AMD_IOMMU_ACPI_IVHD_DEV_SPECIAL    72
-
-/* IVHD IOMMU Flags */
-#define AMD_IOMMU_ACPI_COHERENT_MASK       0x20
-#define AMD_IOMMU_ACPI_COHERENT_SHIFT      5
-#define AMD_IOMMU_ACPI_IOTLB_SUP_MASK      0x10
-#define AMD_IOMMU_ACPI_IOTLB_SUP_SHIFT     4
-#define AMD_IOMMU_ACPI_ISOC_MASK       0x08
-#define AMD_IOMMU_ACPI_ISOC_SHIFT      3
-#define AMD_IOMMU_ACPI_RES_PASS_PW_MASK        0x04
-#define AMD_IOMMU_ACPI_RES_PASS_PW_SHIFT   2
-#define AMD_IOMMU_ACPI_PASS_PW_MASK        0x02
-#define AMD_IOMMU_ACPI_PASS_PW_SHIFT       1
-#define AMD_IOMMU_ACPI_HT_TUN_ENB_MASK     0x01
-#define AMD_IOMMU_ACPI_HT_TUN_ENB_SHIFT        0
-
-/* IVHD Device Flags */
-#define AMD_IOMMU_ACPI_LINT1_PASS_MASK     0x80
-#define AMD_IOMMU_ACPI_LINT1_PASS_SHIFT        7
-#define AMD_IOMMU_ACPI_LINT0_PASS_MASK     0x40
-#define AMD_IOMMU_ACPI_LINT0_PASS_SHIFT        6
-#define AMD_IOMMU_ACPI_SYS_MGT_MASK        0x30
-#define AMD_IOMMU_ACPI_SYS_MGT_SHIFT       4
-#define AMD_IOMMU_ACPI_NMI_PASS_MASK       0x04
-#define AMD_IOMMU_ACPI_NMI_PASS_SHIFT      2
-#define AMD_IOMMU_ACPI_EINT_PASS_MASK      0x02
-#define AMD_IOMMU_ACPI_EINT_PASS_SHIFT     1
-#define AMD_IOMMU_ACPI_INIT_PASS_MASK      0x01
-#define AMD_IOMMU_ACPI_INIT_PASS_SHIFT     0
-
-/* IVHD Device Extended Flags */
-#define AMD_IOMMU_ACPI_ATS_DISABLED_MASK   0x80000000
-#define AMD_IOMMU_ACPI_ATS_DISABLED_SHIFT  31
-
-/* IVMD Device Flags */
-#define AMD_IOMMU_ACPI_EXCLUSION_RANGE_MASK    0x08
-#define AMD_IOMMU_ACPI_EXCLUSION_RANGE_SHIFT   3
-#define AMD_IOMMU_ACPI_IW_PERMISSION_MASK  0x04
-#define AMD_IOMMU_ACPI_IW_PERMISSION_SHIFT 2
-#define AMD_IOMMU_ACPI_IR_PERMISSION_MASK  0x02
-#define AMD_IOMMU_ACPI_IR_PERMISSION_SHIFT 1
-#define AMD_IOMMU_ACPI_UNITY_MAPPING_MASK  0x01
-#define AMD_IOMMU_ACPI_UNITY_MAPPING_SHIFT 0
-
-#define ACPI_OEM_ID_SIZE                6
-#define ACPI_OEM_TABLE_ID_SIZE          8
-
-#pragma pack(1)
-struct acpi_ivrs_table_header {
-   struct acpi_table_header acpi_header;
-   u32 io_info;
-   u8  reserved[8];
-};
-
-struct acpi_ivrs_block_header {
-   u8  type;
-   u8  flags;
-   u16 length;
-   u16 dev_id;
-};
-
-struct acpi_ivhd_block_header {
-   struct acpi_ivrs_block_header header;
-   u16 cap_offset;
-   u64 mmio_base;
-   u16 pci_segment;
-   u16 iommu_info;
-   u8 reserved[4];
-};
-
-struct acpi_ivhd_device_header {
-   u8  type;
-   u16 dev_id;
-   u8  flags;
-};
-
-struct acpi_ivhd_device_trailer {
-   u8  type;
-   u16 dev_id;
-   u8  reserved;
-};
-
-struct acpi_ivhd_device_range {
-   struct acpi_ivhd_device_header header;
-   struct acpi_ivhd_device_trailer trailer;
-};
-
-struct acpi_ivhd_device_alias {
-   struct acpi_ivhd_device_header header;
-   u8  reserved1;
-   u16 dev_id;
-   u8  reserved2;
-};
-
-struct acpi_ivhd_device_alias_range {
-   struct acpi_ivhd_device_alias alias;
-   struct acpi_ivhd_device_trailer trailer;
-};
-
-struct acpi_ivhd_device_extended {
-   struct acpi_ivhd_device_header header;
-   u32 ext_flags;
-};
-
-struct acpi_ivhd_device_extended_range {
-   struct acpi_ivhd_device_extended extended;
-   struct acpi_ivhd_device_trailer trailer;
-};
-
-struct acpi_ivhd_device_special {
-   struct acpi_ivhd_device_header header;
-   u8  handle;
-   u16 dev_id;
-   u8  variety;
-};
-
-union acpi_ivhd_device {
-   struct acpi_ivhd_device_header header;
-   struct acpi_ivhd_device_range range;
-   struct acpi_ivhd_device_alias alias;
-   struct acpi_ivhd_device_alias_range alias_range;
-   struct acpi_ivhd_device_extended extended;
-   struct acpi_ivhd_device_extended_range extended_range;
-   struct acpi_ivhd_device_special special;
-};
-
-struct acpi_ivmd_block_header {
-   struct acpi_ivrs_block_header header;
-   union {
-       u16 last_dev_id;
-       u16 cap_offset;
-       u16 reserved1;
-   };
-   u64 reserved2;
-   u64 start_addr;
-   u64 mem_length;
-};
-#pragma pack()
-
-#endif /* _ASM_X86_64_AMD_IOMMU_ACPI_H */
--- a/xen/include/asm-x86/hvm/svm/amd-iommu-proto.h
+++ b/xen/include/asm-x86/hvm/svm/amd-iommu-proto.h
@@ -26,6 +26,8 @@
 #include <asm/apicdef.h>
 #include <xen/domain_page.h>
=20
+struct acpi_ivrs_hardware;
+
 #define for_each_amd_iommu(amd_iommu) \
     list_for_each_entry(amd_iommu, \
         &amd_iommu_head, list)
@@ -41,7 +43,7 @@
=20
 /* amd-iommu-detect functions */
 int amd_iommu_get_ivrs_dev_entries(void);
-int amd_iommu_detect_one_acpi(void *ivhd);
+int amd_iommu_detect_one_acpi(const struct acpi_ivrs_hardware *);
 int amd_iommu_detect_acpi(void);
 void get_iommu_features(struct amd_iommu *iommu);
=20
@@ -121,11 +123,9 @@ static inline u32 set_field_in_reg_u32(u
     return reg_value;
 }
=20
-static inline u8 get_field_from_byte(u8 value, u8 mask, u8 shift)
+static inline u8 get_field_from_byte(u8 value, u8 mask)
 {
-    u8 field;
-    field =3D (value & mask) >> shift;
-    return field;
+    return (value & mask) / (mask & -mask);
 }
=20
 static inline unsigned long region_to_pages(unsigned long addr, unsigned =
long size)



--=__PartA9860C5A.1__=
Content-Type: text/plain; name="acpi-duplicate-ivrs-structs.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="acpi-duplicate-ivrs-structs.patch"

ACPI: eliminate duplicate IVRS definitions=0A=0AUse their proper counterpar=
ts in include/acpi/actbl*.h instead.=0A=0ASigned-off-by: Jan Beulich =
<jbeulich@suse.com>=0A=0A--- a/xen/drivers/passthrough/amd/iommu_acpi.c=0A+=
++ b/xen/drivers/passthrough/amd/iommu_acpi.c=0A@@ -20,10 +20,38 @@=0A =0A =
#include <xen/config.h>=0A #include <xen/errno.h>=0A+#include <xen/acpi.h>=
=0A #include <asm/apicdef.h>=0A #include <asm/amd-iommu.h>=0A #include =
<asm/hvm/svm/amd-iommu-proto.h>=0A-#include <asm/hvm/svm/amd-iommu-acpi.h>=
=0A+=0A+/* Some helper structures, particularly to deal with ranges. =
*/=0A+=0A+struct acpi_ivhd_device_range {=0A+   struct acpi_ivrs_device4 =
start;=0A+   struct acpi_ivrs_device4 end;=0A+};=0A+=0A+struct acpi_ivhd_de=
vice_alias_range {=0A+   struct acpi_ivrs_device8a alias;=0A+   struct =
acpi_ivrs_device4 end;=0A+};=0A+=0A+struct acpi_ivhd_device_extended_range =
{=0A+   struct acpi_ivrs_device8b extended;=0A+   struct acpi_ivrs_device4 =
end;=0A+};=0A+=0A+union acpi_ivhd_device {=0A+   struct acpi_ivrs_de_header=
 header;=0A+   struct acpi_ivrs_device4 select;=0A+   struct acpi_ivhd_devi=
ce_range range;=0A+   struct acpi_ivrs_device8a alias;=0A+   struct =
acpi_ivhd_device_alias_range alias_range;=0A+   struct acpi_ivrs_device8b =
extended;=0A+   struct acpi_ivhd_device_extended_range extended_range;=0A+ =
  struct acpi_ivrs_device8c special;=0A+};=0A =0A static unsigned short =
__initdata last_bdf;=0A =0A@@ -242,12 +270,12 @@ static int __init =
register_exclusion_ran=0A }=0A =0A static int __init parse_ivmd_device_sele=
ct(=0A-    struct acpi_ivmd_block_header *ivmd_block,=0A+    const struct =
acpi_ivrs_memory *ivmd_block,=0A     unsigned long base, unsigned long =
limit, u8 iw, u8 ir)=0A {=0A     u16 bdf;=0A =0A-    bdf =3D ivmd_block->he=
ader.dev_id;=0A+    bdf =3D ivmd_block->header.device_id;=0A     if ( bdf =
>=3D ivrs_bdf_entries )=0A     {=0A         AMD_IOMMU_DEBUG("IVMD Error: =
Invalid Dev_Id 0x%x\n", bdf);=0A@@ -258,13 +286,13 @@ static int __init =
parse_ivmd_device_sele=0A }=0A =0A static int __init parse_ivmd_device_rang=
e(=0A-    struct acpi_ivmd_block_header *ivmd_block,=0A+    const struct =
acpi_ivrs_memory *ivmd_block,=0A     unsigned long base, unsigned long =
limit, u8 iw, u8 ir)=0A {=0A     u16 first_bdf, last_bdf, bdf;=0A     int =
error;=0A =0A-    first_bdf =3D ivmd_block->header.dev_id;=0A+    =
first_bdf =3D ivmd_block->header.device_id;=0A     if ( first_bdf >=3D =
ivrs_bdf_entries )=0A     {=0A         AMD_IOMMU_DEBUG("IVMD Error: "=0A@@ =
-272,7 +300,7 @@ static int __init parse_ivmd_device_rang=0A         =
return -ENODEV;=0A     }=0A =0A-    last_bdf =3D ivmd_block->last_dev_id;=
=0A+    last_bdf =3D ivmd_block->aux_data;=0A     if ( (last_bdf >=3D =
ivrs_bdf_entries) || (last_bdf <=3D first_bdf) )=0A     {=0A         =
AMD_IOMMU_DEBUG("IVMD Error: "=0A@@ -288,18 +316,18 @@ static int __init =
parse_ivmd_device_rang=0A }=0A =0A static int __init parse_ivmd_device_iomm=
u(=0A-    struct acpi_ivmd_block_header *ivmd_block,=0A+    const struct =
acpi_ivrs_memory *ivmd_block,=0A     unsigned long base, unsigned long =
limit, u8 iw, u8 ir)=0A {=0A     struct amd_iommu *iommu;=0A =0A     /* =
find target IOMMU */=0A-    iommu =3D find_iommu_from_bdf_cap(ivmd_block->h=
eader.dev_id,=0A-                                    ivmd_block->cap_offset=
);=0A+    iommu =3D find_iommu_from_bdf_cap(ivmd_block->header.device_id,=
=0A+                                    ivmd_block->aux_data);=0A     if ( =
!iommu )=0A     {=0A         AMD_IOMMU_DEBUG("IVMD Error: No IOMMU for =
Dev_Id 0x%x  Cap 0x%x\n",=0A-                        ivmd_block->header.dev=
_id, ivmd_block->cap_offset);=0A+                        ivmd_block->header=
.device_id, ivmd_block->aux_data);=0A         return -ENODEV;=0A     }=0A =
=0A@@ -307,20 +335,19 @@ static int __init parse_ivmd_device_iomm=0A       =
  iommu, base, limit, iw, ir);=0A }=0A =0A-static int __init parse_ivmd_blo=
ck(struct acpi_ivmd_block_header *ivmd_block)=0A+static int __init =
parse_ivmd_block(const struct acpi_ivrs_memory *ivmd_block)=0A {=0A     =
unsigned long start_addr, mem_length, base, limit;=0A     u8 iw, ir;=0A =
=0A-    if ( ivmd_block->header.length <=0A-         sizeof(struct =
acpi_ivmd_block_header) )=0A+    if ( ivmd_block->header.length < =
sizeof(*ivmd_block) )=0A     {=0A         AMD_IOMMU_DEBUG("IVMD Error: =
Invalid Block Length!\n");=0A         return -ENODEV;=0A     }=0A =0A-    =
start_addr =3D (unsigned long)ivmd_block->start_addr;=0A-    mem_length =
=3D (unsigned long)ivmd_block->mem_length;=0A+    start_addr =3D (unsigned =
long)ivmd_block->start_address;=0A+    mem_length =3D (unsigned long)ivmd_b=
lock->memory_length;=0A     base =3D start_addr & PAGE_MASK;=0A     limit =
=3D (start_addr + mem_length - 1) & PAGE_MASK;=0A =0A@@ -328,20 +355,14 @@ =
static int __init parse_ivmd_block(struc=0A     AMD_IOMMU_DEBUG(" =
Start_Addr_Phys 0x%lx\n", start_addr);=0A     AMD_IOMMU_DEBUG(" Mem_Length =
0x%lx\n", mem_length);=0A =0A-    if ( get_field_from_byte(ivmd_block->head=
er.flags,=0A-                             AMD_IOMMU_ACPI_EXCLUSION_RANGE_MA=
SK,=0A-                             AMD_IOMMU_ACPI_EXCLUSION_RANGE_SHIFT) =
)=0A+    if ( ivmd_block->header.flags & ACPI_IVMD_EXCLUSION_RANGE )=0A    =
     iw =3D ir =3D IOMMU_CONTROL_ENABLED;=0A-    else if ( get_field_from_b=
yte(ivmd_block->header.flags,=0A-                                  =
AMD_IOMMU_ACPI_UNITY_MAPPING_MASK,=0A-                                  =
AMD_IOMMU_ACPI_UNITY_MAPPING_SHIFT) )=0A-    {=0A-        iw =3D get_field_=
from_byte(ivmd_block->header.flags,=0A-                                 =
AMD_IOMMU_ACPI_IW_PERMISSION_MASK,=0A-                                 =
AMD_IOMMU_ACPI_IW_PERMISSION_SHIFT);=0A-        ir =3D get_field_from_byte(=
ivmd_block->header.flags,=0A-                                 AMD_IOMMU_ACP=
I_IR_PERMISSION_MASK,=0A-                                 AMD_IOMMU_ACPI_IR=
_PERMISSION_SHIFT);=0A+    else if ( ivmd_block->header.flags & ACPI_IVMD_U=
NITY )=0A+    {=0A+        iw =3D ivmd_block->header.flags & ACPI_IVMD_READ=
 ?=0A+            IOMMU_CONTROL_ENABLED : IOMMU_CONTROL_DISABLED;=0A+      =
  ir =3D ivmd_block->header.flags & ACPI_IVMD_WRITE ?=0A+            =
IOMMU_CONTROL_ENABLED : IOMMU_CONTROL_DISABLED;=0A     }=0A     else=0A    =
 {=0A@@ -351,19 +372,19 @@ static int __init parse_ivmd_block(struc=0A =0A =
    switch( ivmd_block->header.type )=0A     {=0A-    case AMD_IOMMU_ACPI_I=
VMD_ALL_TYPE:=0A+    case ACPI_IVRS_TYPE_MEMORY_ALL:=0A         return =
register_exclusion_range_for_all_devices(=0A             base, limit, iw, =
ir);=0A =0A-    case AMD_IOMMU_ACPI_IVMD_ONE_TYPE:=0A+    case ACPI_IVRS_TY=
PE_MEMORY_ONE:=0A         return parse_ivmd_device_select(ivmd_block,=0A   =
                                      base, limit, iw, ir);=0A =0A-    =
case AMD_IOMMU_ACPI_IVMD_RANGE_TYPE:=0A+    case ACPI_IVRS_TYPE_MEMORY_RANG=
E:=0A         return parse_ivmd_device_range(ivmd_block,=0A                =
                        base, limit, iw, ir);=0A =0A-    case AMD_IOMMU_ACP=
I_IVMD_IOMMU_TYPE:=0A+    case ACPI_IVRS_TYPE_MEMORY_IOMMU:=0A         =
return parse_ivmd_device_iommu(ivmd_block,=0A                              =
          base, limit, iw, ir);=0A =0A@@ -386,45 +407,44 @@ static u16 =
__init parse_ivhd_device_padd=0A }=0A =0A static u16 __init parse_ivhd_devi=
ce_select(=0A-    union acpi_ivhd_device *ivhd_device, struct amd_iommu =
*iommu)=0A+    const struct acpi_ivrs_device4 *select, struct amd_iommu =
*iommu)=0A {=0A     u16 bdf;=0A =0A-    bdf =3D ivhd_device->header.dev_id;=
=0A+    bdf =3D select->header.id;=0A     if ( bdf >=3D ivrs_bdf_entries =
)=0A     {=0A         AMD_IOMMU_DEBUG("IVHD Error: Invalid Device_Entry =
Dev_Id 0x%x\n", bdf);=0A         return 0;=0A     }=0A =0A-    add_ivrs_map=
ping_entry(bdf, bdf, ivhd_device->header.flags, iommu);=0A+    add_ivrs_map=
ping_entry(bdf, bdf, select->header.data_setting, iommu);=0A =0A-    =
return sizeof(struct acpi_ivhd_device_header);=0A+    return sizeof(*select=
);=0A }=0A =0A static u16 __init parse_ivhd_device_range(=0A-    union =
acpi_ivhd_device *ivhd_device,=0A+    const struct acpi_ivhd_device_range =
*range,=0A     u16 header_length, u16 block_length, struct amd_iommu =
*iommu)=0A {=0A     u16 dev_length, first_bdf, last_bdf, bdf;=0A =0A-    =
dev_length =3D sizeof(struct acpi_ivhd_device_range);=0A+    dev_length =
=3D sizeof(*range);=0A     if ( header_length < (block_length + dev_length)=
 )=0A     {=0A         AMD_IOMMU_DEBUG("IVHD Error: Invalid Device_Entry =
Length!\n");=0A         return 0;=0A     }=0A =0A-    if ( ivhd_device->ran=
ge.trailer.type !=3D=0A-         AMD_IOMMU_ACPI_IVHD_DEV_RANGE_END )=0A+   =
 if ( range->end.header.type !=3D ACPI_IVRS_TYPE_END )=0A     {=0A         =
AMD_IOMMU_DEBUG("IVHD Error: "=0A                         "Invalid Range: =
End_Type 0x%x\n",=0A-                        ivhd_device->range.trailer.typ=
e);=0A+                        range->end.header.type);=0A         return =
0;=0A     }=0A =0A-    first_bdf =3D ivhd_device->header.dev_id;=0A+    =
first_bdf =3D range->start.header.id;=0A     if ( first_bdf >=3D ivrs_bdf_e=
ntries )=0A     {=0A         AMD_IOMMU_DEBUG("IVHD Error: "=0A@@ -432,7 =
+452,7 @@ static u16 __init parse_ivhd_device_rang=0A         return 0;=0A =
    }=0A =0A-    last_bdf =3D ivhd_device->range.trailer.dev_id;=0A+    =
last_bdf =3D range->end.header.id;=0A     if ( (last_bdf >=3D ivrs_bdf_entr=
ies) || (last_bdf <=3D first_bdf) )=0A     {=0A         AMD_IOMMU_DEBUG("IV=
HD Error: "=0A@@ -443,32 +463,33 @@ static u16 __init parse_ivhd_device_ran=
g=0A     AMD_IOMMU_DEBUG(" Dev_Id Range: 0x%x -> 0x%x\n", first_bdf, =
last_bdf);=0A =0A     for ( bdf =3D first_bdf; bdf <=3D last_bdf; bdf++ =
)=0A-        add_ivrs_mapping_entry(bdf, bdf, ivhd_device->header.flags, =
iommu);=0A+        add_ivrs_mapping_entry(bdf, bdf, range->start.header.dat=
a_setting,=0A+                               iommu);=0A =0A     return =
dev_length;=0A }=0A =0A static u16 __init parse_ivhd_device_alias(=0A-    =
union acpi_ivhd_device *ivhd_device,=0A+    const struct acpi_ivrs_device8a=
 *alias,=0A     u16 header_length, u16 block_length, struct amd_iommu =
*iommu)=0A {=0A     u16 dev_length, alias_id, bdf;=0A =0A-    dev_length =
=3D sizeof(struct acpi_ivhd_device_alias);=0A+    dev_length =3D sizeof(*al=
ias);=0A     if ( header_length < (block_length + dev_length) )=0A     =
{=0A         AMD_IOMMU_DEBUG("IVHD Error: Invalid Device_Entry Length!\n");=
=0A         return 0;=0A     }=0A =0A-    bdf =3D ivhd_device->header.dev_i=
d;=0A+    bdf =3D alias->header.id;=0A     if ( bdf >=3D ivrs_bdf_entries =
)=0A     {=0A         AMD_IOMMU_DEBUG("IVHD Error: Invalid Device_Entry =
Dev_Id 0x%x\n", bdf);=0A         return 0;=0A     }=0A =0A-    alias_id =
=3D ivhd_device->alias.dev_id;=0A+    alias_id =3D alias->used_id;=0A     =
if ( alias_id >=3D ivrs_bdf_entries )=0A     {=0A         AMD_IOMMU_DEBUG("=
IVHD Error: Invalid Alias Dev_Id 0x%x\n", alias_id);=0A@@ -477,35 +498,34 =
@@ static u16 __init parse_ivhd_device_alia=0A =0A     AMD_IOMMU_DEBUG(" =
Dev_Id Alias: 0x%x\n", alias_id);=0A =0A-    add_ivrs_mapping_entry(bdf, =
alias_id, ivhd_device->header.flags, iommu);=0A+    add_ivrs_mapping_entry(=
bdf, alias_id, alias->header.data_setting, iommu);=0A =0A     return =
dev_length;=0A }=0A =0A static u16 __init parse_ivhd_device_alias_range(=0A=
-    union acpi_ivhd_device *ivhd_device,=0A+    const struct acpi_ivhd_dev=
ice_alias_range *range,=0A     u16 header_length, u16 block_length, struct =
amd_iommu *iommu)=0A {=0A =0A     u16 dev_length, first_bdf, last_bdf, =
alias_id, bdf;=0A =0A-    dev_length =3D sizeof(struct acpi_ivhd_device_ali=
as_range);=0A+    dev_length =3D sizeof(*range);=0A     if ( header_length =
< (block_length + dev_length) )=0A     {=0A         AMD_IOMMU_DEBUG("IVHD =
Error: Invalid Device_Entry Length!\n");=0A         return 0;=0A     }=0A =
=0A-    if ( ivhd_device->alias_range.trailer.type !=3D=0A-         =
AMD_IOMMU_ACPI_IVHD_DEV_RANGE_END )=0A+    if ( range->end.header.type =
!=3D ACPI_IVRS_TYPE_END )=0A     {=0A         AMD_IOMMU_DEBUG("IVHD Error: =
"=0A                         "Invalid Range: End_Type 0x%x\n",=0A-         =
               ivhd_device->alias_range.trailer.type);=0A+                 =
       range->end.header.type);=0A         return 0;=0A     }=0A =0A-    =
first_bdf =3D ivhd_device->header.dev_id;=0A+    first_bdf =3D range->alias=
.header.id;=0A     if ( first_bdf >=3D ivrs_bdf_entries )=0A     {=0A      =
   AMD_IOMMU_DEBUG("IVHD Error: "=0A@@ -513,7 +533,7 @@ static u16 __init =
parse_ivhd_device_alia=0A         return 0;=0A     }=0A =0A-    last_bdf =
=3D ivhd_device->alias_range.trailer.dev_id;=0A+    last_bdf =3D range->end=
.header.id;=0A     if ( last_bdf >=3D ivrs_bdf_entries || last_bdf <=3D =
first_bdf )=0A     {=0A         AMD_IOMMU_DEBUG(=0A@@ -521,7 +541,7 @@ =
static u16 __init parse_ivhd_device_alia=0A         return 0;=0A     }=0A =
=0A-    alias_id =3D ivhd_device->alias_range.alias.dev_id;=0A+    =
alias_id =3D range->alias.used_id;=0A     if ( alias_id >=3D ivrs_bdf_entri=
es )=0A     {=0A         AMD_IOMMU_DEBUG("IVHD Error: Invalid Alias Dev_Id =
0x%x\n", alias_id);=0A@@ -532,59 +552,59 @@ static u16 __init parse_ivhd_de=
vice_alia=0A     AMD_IOMMU_DEBUG(" Dev_Id Alias: 0x%x\n", alias_id);=0A =
=0A     for ( bdf =3D first_bdf; bdf <=3D last_bdf; bdf++ )=0A-        =
add_ivrs_mapping_entry(bdf, alias_id, ivhd_device->header.flags, iommu);=0A=
+        add_ivrs_mapping_entry(bdf, alias_id, range->alias.header.data_set=
ting,=0A+                               iommu);=0A =0A     return =
dev_length;=0A }=0A =0A static u16 __init parse_ivhd_device_extended(=0A-  =
  union acpi_ivhd_device *ivhd_device,=0A+    const struct acpi_ivrs_device=
8b *ext,=0A     u16 header_length, u16 block_length, struct amd_iommu =
*iommu)=0A {=0A     u16 dev_length, bdf;=0A =0A-    dev_length =3D =
sizeof(struct acpi_ivhd_device_extended);=0A+    dev_length =3D sizeof(*ext=
);=0A     if ( header_length < (block_length + dev_length) )=0A     {=0A   =
      AMD_IOMMU_DEBUG("IVHD Error: Invalid Device_Entry Length!\n");=0A    =
     return 0;=0A     }=0A =0A-    bdf =3D ivhd_device->header.dev_id;=0A+ =
   bdf =3D ext->header.id;=0A     if ( bdf >=3D ivrs_bdf_entries )=0A     =
{=0A         AMD_IOMMU_DEBUG("IVHD Error: Invalid Device_Entry Dev_Id =
0x%x\n", bdf);=0A         return 0;=0A     }=0A =0A-    add_ivrs_mapping_en=
try(bdf, bdf, ivhd_device->header.flags, iommu);=0A+    add_ivrs_mapping_en=
try(bdf, bdf, ext->header.data_setting, iommu);=0A =0A     return =
dev_length;=0A }=0A =0A static u16 __init parse_ivhd_device_extended_range(=
=0A-    union acpi_ivhd_device *ivhd_device,=0A+    const struct acpi_ivhd_=
device_extended_range *range,=0A     u16 header_length, u16 block_length, =
struct amd_iommu *iommu)=0A {=0A     u16 dev_length, first_bdf, last_bdf, =
bdf;=0A =0A-    dev_length =3D sizeof(struct acpi_ivhd_device_extended_rang=
e);=0A+    dev_length =3D sizeof(*range);=0A     if ( header_length < =
(block_length + dev_length) )=0A     {=0A         AMD_IOMMU_DEBUG("IVHD =
Error: Invalid Device_Entry Length!\n");=0A         return 0;=0A     }=0A =
=0A-    if ( ivhd_device->extended_range.trailer.type !=3D=0A-         =
AMD_IOMMU_ACPI_IVHD_DEV_RANGE_END )=0A+    if ( range->end.header.type =
!=3D ACPI_IVRS_TYPE_END )=0A     {=0A         AMD_IOMMU_DEBUG("IVHD Error: =
"=0A                         "Invalid Range: End_Type 0x%x\n",=0A-         =
               ivhd_device->extended_range.trailer.type);=0A+              =
          range->end.header.type);=0A         return 0;=0A     }=0A =0A-   =
 first_bdf =3D ivhd_device->header.dev_id;=0A+    first_bdf =3D range->exte=
nded.header.id;=0A     if ( first_bdf >=3D ivrs_bdf_entries )=0A     {=0A  =
       AMD_IOMMU_DEBUG("IVHD Error: "=0A@@ -592,7 +612,7 @@ static u16 =
__init parse_ivhd_device_exte=0A         return 0;=0A     }=0A =0A-    =
last_bdf =3D ivhd_device->extended_range.trailer.dev_id;=0A+    last_bdf =
=3D range->end.header.id;=0A     if ( (last_bdf >=3D ivrs_bdf_entries) || =
(last_bdf <=3D first_bdf) )=0A     {=0A         AMD_IOMMU_DEBUG("IVHD =
Error: "=0A@@ -604,116 +624,116 @@ static u16 __init parse_ivhd_device_exte=
=0A                     first_bdf, last_bdf);=0A =0A     for ( bdf =3D =
first_bdf; bdf <=3D last_bdf; bdf++ )=0A-        add_ivrs_mapping_entry(bdf=
, bdf, ivhd_device->header.flags, iommu);=0A+        add_ivrs_mapping_entry=
(bdf, bdf, range->extended.header.data_setting,=0A+                        =
       iommu);=0A =0A     return dev_length;=0A }=0A =0A static u16 __init =
parse_ivhd_device_special(=0A-    union acpi_ivhd_device *ivhd_device, u16 =
seg,=0A+    const struct acpi_ivrs_device8c *special, u16 seg,=0A     u16 =
header_length, u16 block_length, struct amd_iommu *iommu)=0A {=0A     u16 =
dev_length, bdf;=0A =0A-    dev_length =3D sizeof(struct acpi_ivhd_device_s=
pecial);=0A+    dev_length =3D sizeof(*special);=0A     if ( header_length =
< (block_length + dev_length) )=0A     {=0A         AMD_IOMMU_DEBUG("IVHD =
Error: Invalid Device_Entry Length!\n");=0A         return 0;=0A     }=0A =
=0A-    bdf =3D ivhd_device->special.dev_id;=0A+    bdf =3D special->used_i=
d;=0A     if ( bdf >=3D ivrs_bdf_entries )=0A     {=0A         AMD_IOMMU_DE=
BUG("IVHD Error: Invalid Device_Entry Dev_Id 0x%x\n", bdf);=0A         =
return 0;=0A     }=0A =0A-    add_ivrs_mapping_entry(bdf, bdf, ivhd_device-=
>header.flags, iommu);=0A+    add_ivrs_mapping_entry(bdf, bdf, special->hea=
der.data_setting, iommu);=0A     /* set device id of ioapic */=0A-    =
ioapic_sbdf[ivhd_device->special.handle].bdf =3D bdf;=0A-    ioapic_sbdf[iv=
hd_device->special.handle].seg =3D seg;=0A+    ioapic_sbdf[special->handle]=
.bdf =3D bdf;=0A+    ioapic_sbdf[special->handle].seg =3D seg;=0A     =
return dev_length;=0A }=0A =0A-static int __init parse_ivhd_block(struct =
acpi_ivhd_block_header *ivhd_block)=0A+static int __init parse_ivhd_block(c=
onst struct acpi_ivrs_hardware *ivhd_block)=0A {=0A-    union acpi_ivhd_dev=
ice *ivhd_device;=0A+    const union acpi_ivhd_device *ivhd_device;=0A     =
u16 block_length, dev_length;=0A     struct amd_iommu *iommu;=0A =0A-    =
if ( ivhd_block->header.length <=0A-         sizeof(struct acpi_ivhd_block_=
header) )=0A+    if ( ivhd_block->header.length < sizeof(*ivhd_block) )=0A =
    {=0A         AMD_IOMMU_DEBUG("IVHD Error: Invalid Block Length!\n");=0A=
         return -ENODEV;=0A     }=0A =0A-    iommu =3D find_iommu_from_bdf_=
cap(ivhd_block->header.dev_id,=0A-                                    =
ivhd_block->cap_offset);=0A+    iommu =3D find_iommu_from_bdf_cap(ivhd_bloc=
k->header.device_id,=0A+                                    ivhd_block->cap=
ability_offset);=0A     if ( !iommu )=0A     {=0A         AMD_IOMMU_DEBUG("=
IVHD Error: No IOMMU for Dev_Id 0x%x  Cap 0x%x\n",=0A-                     =
   ivhd_block->header.dev_id, ivhd_block->cap_offset);=0A+                 =
       ivhd_block->header.device_id,=0A+                        ivhd_block-=
>capability_offset);=0A         return -ENODEV;=0A     }=0A =0A     /* =
parse Device Entries */=0A-    block_length =3D sizeof(struct acpi_ivhd_blo=
ck_header);=0A+    block_length =3D sizeof(*ivhd_block);=0A     while ( =
ivhd_block->header.length >=3D=0A-            (block_length + sizeof(struct=
 acpi_ivhd_device_header)) )=0A+            (block_length + sizeof(struct =
acpi_ivrs_de_header)) )=0A     {=0A-        ivhd_device =3D (union =
acpi_ivhd_device *)=0A-            ((u8 *)ivhd_block + block_length);=0A+  =
      ivhd_device =3D (const void *)((const u8 *)ivhd_block + block_length)=
;=0A =0A         AMD_IOMMU_DEBUG( "IVHD Device Entry:\n");=0A         =
AMD_IOMMU_DEBUG( " Type 0x%x\n", ivhd_device->header.type);=0A-        =
AMD_IOMMU_DEBUG( " Dev_Id 0x%x\n", ivhd_device->header.dev_id);=0A-        =
AMD_IOMMU_DEBUG( " Flags 0x%x\n", ivhd_device->header.flags);=0A+        =
AMD_IOMMU_DEBUG( " Dev_Id 0x%x\n", ivhd_device->header.id);=0A+        =
AMD_IOMMU_DEBUG( " Flags 0x%x\n", ivhd_device->header.data_setting);=0A =
=0A         switch ( ivhd_device->header.type )=0A         {=0A-        =
case AMD_IOMMU_ACPI_IVHD_DEV_U32_PAD:=0A+        case ACPI_IVRS_TYPE_PAD4:=
=0A             dev_length =3D parse_ivhd_device_padding(=0A               =
  sizeof(u32),=0A                 ivhd_block->header.length, block_length);=
=0A             break;=0A-        case AMD_IOMMU_ACPI_IVHD_DEV_U64_PAD:=0A+=
        case ACPI_IVRS_TYPE_PAD8:=0A             dev_length =3D parse_ivhd_=
device_padding(=0A                 sizeof(u64),=0A                 =
ivhd_block->header.length, block_length);=0A             break;=0A-        =
case AMD_IOMMU_ACPI_IVHD_DEV_SELECT:=0A-            dev_length =3D =
parse_ivhd_device_select(ivhd_device, iommu);=0A+        case ACPI_IVRS_TYP=
E_SELECT:=0A+            dev_length =3D parse_ivhd_device_select(&ivhd_devi=
ce->select, iommu);=0A             break;=0A-        case AMD_IOMMU_ACPI_IV=
HD_DEV_RANGE_START:=0A+        case ACPI_IVRS_TYPE_START:=0A             =
dev_length =3D parse_ivhd_device_range(=0A-                ivhd_device,=0A+=
                &ivhd_device->range,=0A                 ivhd_block->header.=
length, block_length, iommu);=0A             break;=0A-        case =
AMD_IOMMU_ACPI_IVHD_DEV_ALIAS_SELECT:=0A+        case ACPI_IVRS_TYPE_ALIAS_=
SELECT:=0A             dev_length =3D parse_ivhd_device_alias(=0A-         =
       ivhd_device,=0A+                &ivhd_device->alias,=0A             =
    ivhd_block->header.length, block_length, iommu);=0A             =
break;=0A-        case AMD_IOMMU_ACPI_IVHD_DEV_ALIAS_RANGE:=0A+        =
case ACPI_IVRS_TYPE_ALIAS_START:=0A             dev_length =3D parse_ivhd_d=
evice_alias_range(=0A-                ivhd_device,=0A+                =
&ivhd_device->alias_range,=0A                 ivhd_block->header.length, =
block_length, iommu);=0A             break;=0A-        case AMD_IOMMU_ACPI_=
IVHD_DEV_EXT_SELECT:=0A+        case ACPI_IVRS_TYPE_EXT_SELECT:=0A         =
    dev_length =3D parse_ivhd_device_extended(=0A-                =
ivhd_device,=0A+                &ivhd_device->extended,=0A                 =
ivhd_block->header.length, block_length, iommu);=0A             break;=0A- =
       case AMD_IOMMU_ACPI_IVHD_DEV_EXT_RANGE:=0A+        case ACPI_IVRS_TY=
PE_EXT_START:=0A             dev_length =3D parse_ivhd_device_extended_rang=
e(=0A-                ivhd_device,=0A+                &ivhd_device->extende=
d_range,=0A                 ivhd_block->header.length, block_length, =
iommu);=0A             break;=0A-        case AMD_IOMMU_ACPI_IVHD_DEV_SPECI=
AL:=0A+        case ACPI_IVRS_TYPE_SPECIAL:=0A             dev_length =3D =
parse_ivhd_device_special(=0A-                ivhd_device, ivhd_block->pci_=
segment,=0A+                &ivhd_device->special, ivhd_block->pci_segment_=
group,=0A                 ivhd_block->header.length, block_length, =
iommu);=0A             break;=0A         default:=0A@@ -730,22 +750,24 @@ =
static int __init parse_ivhd_block(struc=0A     return 0;=0A }=0A =
=0A-static int __init parse_ivrs_block(struct acpi_ivrs_block_header =
*ivrs_block)=0A+static int __init parse_ivrs_block(const struct acpi_ivrs_h=
eader *ivrs_block)=0A {=0A-    struct acpi_ivhd_block_header *ivhd_block;=
=0A-    struct acpi_ivmd_block_header *ivmd_block;=0A+    const struct =
acpi_ivrs_hardware *ivhd_block;=0A+    const struct acpi_ivrs_memory =
*ivmd_block;=0A =0A     switch ( ivrs_block->type )=0A     {=0A-    case =
AMD_IOMMU_ACPI_IVHD_TYPE:=0A-        ivhd_block =3D (struct acpi_ivhd_block=
_header *)ivrs_block;=0A+    case ACPI_IVRS_TYPE_HARDWARE:=0A+        =
ivhd_block =3D container_of(ivrs_block, const struct acpi_ivrs_hardware,=0A=
+                                  header);=0A         return parse_ivhd_bl=
ock(ivhd_block);=0A =0A-    case AMD_IOMMU_ACPI_IVMD_ALL_TYPE:=0A-    case =
AMD_IOMMU_ACPI_IVMD_ONE_TYPE:=0A-    case AMD_IOMMU_ACPI_IVMD_RANGE_TYPE:=
=0A-    case AMD_IOMMU_ACPI_IVMD_IOMMU_TYPE:=0A-        ivmd_block =3D =
(struct acpi_ivmd_block_header *)ivrs_block;=0A+    case ACPI_IVRS_TYPE_MEM=
ORY_ALL:=0A+    case ACPI_IVRS_TYPE_MEMORY_ONE:=0A+    case ACPI_IVRS_TYPE_=
MEMORY_RANGE:=0A+    case ACPI_IVRS_TYPE_MEMORY_IOMMU:=0A+        =
ivmd_block =3D container_of(ivrs_block, const struct acpi_ivrs_memory,=0A+ =
                                 header);=0A         return parse_ivmd_bloc=
k(ivmd_block);=0A =0A     default:=0A@@ -792,12 +814,11 @@ static void =
__init dump_acpi_table_heade=0A =0A }=0A =0A-static int __init parse_ivrs_t=
able(struct acpi_table_header *_table)=0A+static int __init parse_ivrs_tabl=
e(struct acpi_table_header *table)=0A {=0A-    struct acpi_ivrs_block_heade=
r *ivrs_block;=0A+    const struct acpi_ivrs_header *ivrs_block;=0A     =
unsigned long length;=0A     int error =3D 0;=0A-    struct acpi_table_head=
er *table =3D (struct acpi_table_header *)_table;=0A =0A     BUG_ON(!table)=
;=0A =0A@@ -805,17 +826,16 @@ static int __init parse_ivrs_table(struc=0A  =
       dump_acpi_table_header(table);=0A =0A     /* parse IVRS blocks =
*/=0A-    length =3D sizeof(struct acpi_ivrs_table_header);=0A+    length =
=3D sizeof(struct acpi_table_ivrs);=0A     while ( (error =3D=3D 0) && =
(table->length > (length + sizeof(*ivrs_block))) )=0A     {=0A-        =
ivrs_block =3D (struct acpi_ivrs_block_header *)=0A-            ((u8 =
*)table + length);=0A+        ivrs_block =3D (struct acpi_ivrs_header =
*)((u8 *)table + length);=0A =0A         AMD_IOMMU_DEBUG("IVRS Block:\n");=
=0A         AMD_IOMMU_DEBUG(" Type 0x%x\n", ivrs_block->type);=0A         =
AMD_IOMMU_DEBUG(" Flags 0x%x\n", ivrs_block->flags);=0A         AMD_IOMMU_D=
EBUG(" Length 0x%x\n", ivrs_block->length);=0A-        AMD_IOMMU_DEBUG(" =
Dev_Id 0x%x\n", ivrs_block->dev_id);=0A+        AMD_IOMMU_DEBUG(" Dev_Id =
0x%x\n", ivrs_block->device_id);=0A =0A         if ( table->length < =
(length + ivrs_block->length) )=0A         {=0A@@ -833,12 +853,11 @@ =
static int __init parse_ivrs_table(struc=0A     return error;=0A }=0A =
=0A-static int __init detect_iommu_acpi(struct acpi_table_header =
*_table)=0A+static int __init detect_iommu_acpi(struct acpi_table_header =
*table)=0A {=0A-    struct acpi_ivrs_block_header *ivrs_block;=0A-    =
struct acpi_table_header *table =3D (struct acpi_table_header *)_table;=0A+=
    const struct acpi_ivrs_header *ivrs_block;=0A     unsigned long i;=0A- =
   unsigned long length =3D sizeof(struct acpi_ivrs_table_header);=0A+    =
unsigned long length =3D sizeof(struct acpi_table_ivrs);=0A     u8 =
checksum, *raw_table;=0A =0A     /* validate checksum: sum of entire table =
=3D=3D 0 */=0A@@ -854,12 +873,14 @@ static int __init detect_iommu_acpi(str=
u=0A =0A     while ( table->length > (length + sizeof(*ivrs_block)) )=0A   =
  {=0A-        ivrs_block =3D (struct acpi_ivrs_block_header *) ((u8 =
*)table + length);=0A+        ivrs_block =3D (struct acpi_ivrs_header =
*)((u8 *)table + length);=0A         if ( table->length < (length + =
ivrs_block->length) )=0A             return -ENODEV;=0A-        if ( =
ivrs_block->type =3D=3D AMD_IOMMU_ACPI_IVHD_TYPE )=0A-            if ( =
amd_iommu_detect_one_acpi((void*)ivrs_block) !=3D 0 )=0A-                =
return -ENODEV;=0A+        if ( ivrs_block->type =3D=3D ACPI_IVRS_TYPE_HARD=
WARE &&=0A+             amd_iommu_detect_one_acpi(=0A+                 =
container_of(ivrs_block, const struct acpi_ivrs_hardware,=0A+              =
                header)) !=3D 0 )=0A+            return -ENODEV;=0A        =
 length +=3D ivrs_block->length;=0A     }=0A     return 0;=0A@@ -870,63 =
+891,59 @@ static int __init detect_iommu_acpi(stru=0A        last_bdf =3D =
(x); \=0A    } while(0);=0A =0A-static int __init get_last_bdf_ivhd(void =
*ivhd)=0A+static int __init get_last_bdf_ivhd(=0A+    const struct =
acpi_ivrs_hardware *ivhd_block)=0A {=0A-    union acpi_ivhd_device =
*ivhd_device;=0A+    const union acpi_ivhd_device *ivhd_device;=0A     u16 =
block_length, dev_length;=0A-    struct acpi_ivhd_block_header *ivhd_block;=
=0A-=0A-    ivhd_block =3D (struct acpi_ivhd_block_header *)ivhd;=0A =0A-  =
  if ( ivhd_block->header.length <=0A-         sizeof(struct acpi_ivhd_bloc=
k_header) )=0A+    if ( ivhd_block->header.length < sizeof(*ivhd_block) =
)=0A     {=0A         AMD_IOMMU_DEBUG("IVHD Error: Invalid Block Length!\n"=
);=0A         return -ENODEV;=0A     }=0A =0A-    block_length =3D =
sizeof(struct acpi_ivhd_block_header);=0A+    block_length =3D sizeof(*ivhd=
_block);=0A     while ( ivhd_block->header.length >=3D=0A-            =
(block_length + sizeof(struct acpi_ivhd_device_header)) )=0A+            =
(block_length + sizeof(struct acpi_ivrs_de_header)) )=0A     {=0A-        =
ivhd_device =3D (union acpi_ivhd_device *)=0A-            ((u8 *)ivhd_block=
 + block_length);=0A+        ivhd_device =3D (const void *)((u8 *)ivhd_bloc=
k + block_length);=0A =0A         switch ( ivhd_device->header.type )=0A   =
      {=0A-        case AMD_IOMMU_ACPI_IVHD_DEV_U32_PAD:=0A+        case =
ACPI_IVRS_TYPE_PAD4:=0A             dev_length =3D sizeof(u32);=0A         =
    break;=0A-        case AMD_IOMMU_ACPI_IVHD_DEV_U64_PAD:=0A+        =
case ACPI_IVRS_TYPE_PAD8:=0A             dev_length =3D sizeof(u64);=0A    =
         break;=0A-        case AMD_IOMMU_ACPI_IVHD_DEV_SELECT:=0A-        =
    UPDATE_LAST_BDF(ivhd_device->header.dev_id);=0A-            dev_length =
=3D sizeof(struct acpi_ivhd_device_header);=0A-            break;=0A-      =
  case AMD_IOMMU_ACPI_IVHD_DEV_ALIAS_SELECT:=0A-            UPDATE_LAST_BDF=
(ivhd_device->header.dev_id);=0A-            dev_length =3D sizeof(struct =
acpi_ivhd_device_alias);=0A-            break;=0A-        case AMD_IOMMU_AC=
PI_IVHD_DEV_EXT_SELECT:=0A-            UPDATE_LAST_BDF(ivhd_device->header.=
dev_id);=0A-            dev_length =3D sizeof(struct acpi_ivhd_device_exten=
ded);=0A-            break;=0A-        case AMD_IOMMU_ACPI_IVHD_DEV_RANGE_S=
TART:=0A-            UPDATE_LAST_BDF(ivhd_device->range.trailer.dev_id);=0A=
-            dev_length =3D sizeof(struct acpi_ivhd_device_range);=0A-     =
       break;=0A-        case AMD_IOMMU_ACPI_IVHD_DEV_ALIAS_RANGE:=0A-     =
       UPDATE_LAST_BDF(ivhd_device->alias_range.trailer.dev_id)=0A-        =
    dev_length =3D sizeof(struct acpi_ivhd_device_alias_range);=0A-        =
    break;=0A-        case AMD_IOMMU_ACPI_IVHD_DEV_EXT_RANGE:=0A-          =
  UPDATE_LAST_BDF(ivhd_device->extended_range.trailer.dev_id)=0A-          =
  dev_length =3D sizeof(struct acpi_ivhd_device_extended_range);=0A-       =
     break;=0A-        case AMD_IOMMU_ACPI_IVHD_DEV_SPECIAL:=0A-           =
 UPDATE_LAST_BDF(ivhd_device->special.dev_id)=0A-            dev_length =
=3D sizeof(struct acpi_ivhd_device_special);=0A+        case ACPI_IVRS_TYPE=
_SELECT:=0A+            UPDATE_LAST_BDF(ivhd_device->select.header.id);=0A+=
            dev_length =3D sizeof(ivhd_device->header);=0A+            =
break;=0A+        case ACPI_IVRS_TYPE_ALIAS_SELECT:=0A+            =
UPDATE_LAST_BDF(ivhd_device->alias.header.id);=0A+            dev_length =
=3D sizeof(ivhd_device->alias);=0A+            break;=0A+        case =
ACPI_IVRS_TYPE_EXT_SELECT:=0A+            UPDATE_LAST_BDF(ivhd_device->exte=
nded.header.id);=0A+            dev_length =3D sizeof(ivhd_device->extended=
);=0A+            break;=0A+        case ACPI_IVRS_TYPE_START:=0A+         =
   UPDATE_LAST_BDF(ivhd_device->range.end.header.id);=0A+            =
dev_length =3D sizeof(ivhd_device->range);=0A+            break;=0A+       =
 case ACPI_IVRS_TYPE_ALIAS_START:=0A+            UPDATE_LAST_BDF(ivhd_devic=
e->alias_range.end.header.id)=0A+            dev_length =3D sizeof(ivhd_dev=
ice->alias_range);=0A+            break;=0A+        case ACPI_IVRS_TYPE_EXT=
_START:=0A+            UPDATE_LAST_BDF(ivhd_device->extended_range.end.head=
er.id)=0A+            dev_length =3D sizeof(ivhd_device->extended_range);=
=0A+            break;=0A+        case ACPI_IVRS_TYPE_SPECIAL:=0A+         =
   UPDATE_LAST_BDF(ivhd_device->special.used_id)=0A+            dev_length =
=3D sizeof(ivhd_device->special);=0A             break;=0A         =
default:=0A             AMD_IOMMU_DEBUG("IVHD Error: Invalid Device =
Type!\n");=0A@@ -942,20 +959,21 @@ static int __init get_last_bdf_ivhd(void=
=0A     return 0;=0A }=0A =0A-static int __init get_last_bdf_acpi(struct =
acpi_table_header *_table)=0A+static int __init get_last_bdf_acpi(struct =
acpi_table_header *table)=0A {=0A-    struct acpi_ivrs_block_header =
*ivrs_block;=0A-    struct acpi_table_header *table =3D (struct acpi_table_=
header *)_table;=0A-    unsigned long length =3D sizeof(struct acpi_ivrs_ta=
ble_header);=0A+    const struct acpi_ivrs_header *ivrs_block;=0A+    =
unsigned long length =3D sizeof(struct acpi_table_ivrs);=0A =0A     while =
( table->length > (length + sizeof(*ivrs_block)) )=0A     {=0A-        =
ivrs_block =3D (struct acpi_ivrs_block_header *) ((u8 *)table + length);=0A=
+        ivrs_block =3D (struct acpi_ivrs_header *)((u8 *)table + =
length);=0A         if ( table->length < (length + ivrs_block->length) =
)=0A             return -ENODEV;=0A-        if ( ivrs_block->type =3D=3D =
AMD_IOMMU_ACPI_IVHD_TYPE )=0A-            if ( get_last_bdf_ivhd((void*)ivr=
s_block) !=3D 0 )=0A-                return -ENODEV;=0A+        if ( =
ivrs_block->type =3D=3D ACPI_IVRS_TYPE_HARDWARE &&=0A+             =
get_last_bdf_ivhd(=0A+                 container_of(ivrs_block, const =
struct acpi_ivrs_hardware,=0A+                              header)) !=3D =
0 )=0A+            return -ENODEV;=0A         length +=3D ivrs_block->lengt=
h;=0A     }=0A    return 0;=0A@@ -963,16 +981,16 @@ static int __init =
get_last_bdf_acpi(stru=0A =0A int __init amd_iommu_detect_acpi(void)=0A =
{=0A-    return acpi_table_parse(AMD_IOMMU_ACPI_IVRS_SIG, detect_iommu_acpi=
);=0A+    return acpi_table_parse(ACPI_SIG_IVRS, detect_iommu_acpi);=0A =
}=0A =0A int __init amd_iommu_get_ivrs_dev_entries(void)=0A {=0A-    =
acpi_table_parse(AMD_IOMMU_ACPI_IVRS_SIG, get_last_bdf_acpi);=0A+    =
acpi_table_parse(ACPI_SIG_IVRS, get_last_bdf_acpi);=0A     return last_bdf =
+ 1;=0A }=0A =0A int __init amd_iommu_update_ivrs_mapping_acpi(void)=0A =
{=0A-    return acpi_table_parse(AMD_IOMMU_ACPI_IVRS_SIG, parse_ivrs_table)=
;=0A+    return acpi_table_parse(ACPI_SIG_IVRS, parse_ivrs_table);=0A =
}=0A--- a/xen/drivers/passthrough/amd/iommu_detect.c=0A+++ b/xen/drivers/pa=
ssthrough/amd/iommu_detect.c=0A@@ -20,12 +20,12 @@=0A =0A #include =
<xen/config.h>=0A #include <xen/errno.h>=0A+#include <xen/acpi.h>=0A =
#include <xen/iommu.h>=0A #include <xen/pci.h>=0A #include <xen/pci_regs.h>=
=0A #include <asm/amd-iommu.h>=0A #include <asm/hvm/svm/amd-iommu-proto.h>=
=0A-#include <asm/hvm/svm/amd-iommu-acpi.h>=0A =0A static int __init =
get_iommu_msi_capabilities(=0A     u16 seg, u8 bus, u8 dev, u8 func, =
struct amd_iommu *iommu)=0A@@ -103,23 +103,21 @@ void __init get_iommu_feat=
ures(struct am=0A     }=0A }=0A =0A-int __init amd_iommu_detect_one_acpi(vo=
id *ivhd)=0A+int __init amd_iommu_detect_one_acpi(=0A+    const struct =
acpi_ivrs_hardware *ivhd_block)=0A {=0A     struct amd_iommu *iommu;=0A    =
 u8 bus, dev, func;=0A-    struct acpi_ivhd_block_header *ivhd_block;=0A   =
  int rt =3D 0;=0A =0A-    ivhd_block =3D (struct acpi_ivhd_block_header =
*)ivhd;=0A-=0A-    if ( ivhd_block->header.length < sizeof(struct =
acpi_ivhd_block_header) )=0A+    if ( ivhd_block->header.length < =
sizeof(*ivhd_block) )=0A     {=0A         AMD_IOMMU_DEBUG("Invalid IVHD =
Block Length!\n");=0A         return -ENODEV;=0A     }=0A =0A-    if ( =
!ivhd_block->header.dev_id ||=0A-        !ivhd_block->cap_offset || =
!ivhd_block->mmio_base)=0A+    if ( !ivhd_block->header.device_id ||=0A+   =
     !ivhd_block->capability_offset || !ivhd_block->base_address)=0A     =
{=0A         AMD_IOMMU_DEBUG("Invalid IVHD Block!\n");=0A         return =
-ENODEV;=0A@@ -134,10 +132,10 @@ int __init amd_iommu_detect_one_acpi(voi=
=0A =0A     spin_lock_init(&iommu->lock);=0A =0A-    iommu->seg =3D =
ivhd_block->pci_segment;=0A-    iommu->bdf =3D ivhd_block->header.dev_id;=
=0A-    iommu->cap_offset =3D ivhd_block->cap_offset;=0A-    iommu->mmio_ba=
se_phys =3D ivhd_block->mmio_base;=0A+    iommu->seg =3D ivhd_block->pci_se=
gment_group;=0A+    iommu->bdf =3D ivhd_block->header.device_id;=0A+    =
iommu->cap_offset =3D ivhd_block->capability_offset;=0A+    iommu->mmio_bas=
e_phys =3D ivhd_block->base_address;=0A =0A     /* override IOMMU HT flags =
*/=0A     iommu->ht_flags =3D ivhd_block->header.flags;=0A--- a/xen/drivers=
/passthrough/amd/iommu_init.c=0A+++ b/xen/drivers/passthrough/amd/iommu_ini=
t.c=0A@@ -20,6 +20,7 @@=0A =0A #include <xen/config.h>=0A #include =
<xen/errno.h>=0A+#include <xen/acpi.h>=0A #include <xen/pci.h>=0A #include =
<xen/pci_regs.h>=0A #include <xen/irq.h>=0A@@ -28,7 +29,6 @@=0A #include =
<asm/hvm/svm/amd-iommu-proto.h>=0A #include <asm-x86/fixmap.h>=0A #include =
<mach_apic.h>=0A-#include <asm/hvm/svm/amd-iommu-acpi.h>=0A =0A static int =
__initdata nr_amd_iommus;=0A =0A@@ -37,9 +37,8 @@ static struct radix_tree_=
root ivrs_maps;=0A struct list_head amd_iommu_head;=0A struct table_struct =
device_table;=0A =0A-static int iommu_has_ht_flag(struct amd_iommu *iommu, =
uint8_t bit)=0A+static int iommu_has_ht_flag(struct amd_iommu *iommu, u8 =
mask)=0A {=0A-    u8 mask =3D 1U << bit;=0A     return iommu->ht_flags & =
mask;=0A }=0A =0A@@ -80,19 +79,19 @@ static void set_iommu_ht_flags(struct =
am=0A =0A     /* Setup HT flags */=0A     if ( iommu_has_cap(iommu, =
PCI_CAP_HT_TUNNEL_SHIFT) )=0A-        iommu_has_ht_flag(iommu, AMD_IOMMU_AC=
PI_HT_TUN_ENB_SHIFT) ?=0A+        iommu_has_ht_flag(iommu, ACPI_IVHD_TT_ENA=
BLE) ?=0A             iommu_set_bit(&entry, IOMMU_CONTROL_HT_TUNNEL_TRANSLA=
TION_SHIFT) :=0A             iommu_clear_bit(&entry, IOMMU_CONTROL_HT_TUNNE=
L_TRANSLATION_SHIFT);=0A =0A-    iommu_has_ht_flag(iommu, AMD_IOMMU_ACPI_RE=
S_PASS_PW_SHIFT) ?=0A+    iommu_has_ht_flag(iommu, ACPI_IVHD_RES_PASS_PW) =
?=0A         iommu_set_bit(&entry, IOMMU_CONTROL_RESP_PASS_POSTED_WRITE_SHI=
FT):=0A         iommu_clear_bit(&entry, IOMMU_CONTROL_RESP_PASS_POSTED_WRIT=
E_SHIFT);=0A =0A-    iommu_has_ht_flag(iommu, AMD_IOMMU_ACPI_ISOC_SHIFT) =
?=0A+    iommu_has_ht_flag(iommu, ACPI_IVHD_ISOC) ?=0A         iommu_set_bi=
t(&entry, IOMMU_CONTROL_ISOCHRONOUS_SHIFT):=0A         iommu_clear_bit(&ent=
ry, IOMMU_CONTROL_ISOCHRONOUS_SHIFT);=0A =0A-    iommu_has_ht_flag(iommu, =
AMD_IOMMU_ACPI_PASS_PW_SHIFT) ?=0A+    iommu_has_ht_flag(iommu, ACPI_IVHD_P=
ASS_PW) ?=0A         iommu_set_bit(&entry, IOMMU_CONTROL_PASS_POSTED_WRITE_=
SHIFT):=0A         iommu_clear_bit(&entry, IOMMU_CONTROL_PASS_POSTED_WRITE_=
SHIFT);=0A =0A--- a/xen/drivers/passthrough/amd/iommu_map.c=0A+++ =
b/xen/drivers/passthrough/amd/iommu_map.c=0A@@ -18,12 +18,13 @@=0A  * =
Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307 =
USA=0A  */=0A =0A+#include <xen/config.h>=0A+#include <xen/acpi.h>=0A =
#include <xen/sched.h>=0A #include <asm/p2m.h>=0A #include <xen/hvm/iommu.h=
>=0A #include <asm/amd-iommu.h>=0A #include <asm/hvm/svm/amd-iommu-proto.h>=
=0A-#include <asm/hvm/svm/amd-iommu-acpi.h>=0A #include "../ats.h"=0A =
#include <xen/pci.h>=0A =0A@@ -215,8 +216,7 @@ void __init iommu_dte_add_de=
vice_entry(u=0A     dte[7] =3D dte[6] =3D dte[4] =3D dte[2] =3D dte[1] =3D =
dte[0] =3D 0;=0A =0A     flags =3D ivrs_dev->device_flags;=0A-    sys_mgt =
=3D get_field_from_byte(flags, AMD_IOMMU_ACPI_SYS_MGT_MASK,=0A-            =
                      AMD_IOMMU_ACPI_SYS_MGT_SHIFT);=0A+    sys_mgt =3D =
get_field_from_byte(flags, ACPI_IVHD_SYSTEM_MGMT);=0A     dev_ex =3D =
ivrs_dev->dte_allow_exclusion;=0A =0A     flags &=3D mask;=0A--- a/xen/incl=
ude/asm-x86/hvm/svm/amd-iommu-acpi.h=0A+++ /dev/null=0A@@ -1,185 +0,0 =
@@=0A-/*=0A- * Copyright (C) 2007 Advanced Micro Devices, Inc.=0A- * =
Author: Leo Duran <leo.duran@amd.com>=0A- * Author: Wei Wang <wei.wang2@amd=
.com> - adapted to xen=0A- *=0A- * This program is free software; you can =
redistribute it and/or modify=0A- * it under the terms of the GNU General =
Public License as published by=0A- * the Free Software Foundation; either =
version 2 of the License, or=0A- * (at your option) any later version.=0A- =
*=0A- * This program is distributed in the hope that it will be useful,=0A-=
 * but WITHOUT ANY WARRANTY; without even the implied warranty of=0A- * =
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the=0A- * GNU =
General Public License for more details.=0A- *=0A- * You should have =
received a copy of the GNU General Public License=0A- * along with this =
program; if not, write to the Free Software=0A- * Foundation, Inc., 59 =
Temple Place, Suite 330, Boston, MA  02111-1307 USA=0A- */=0A-=0A-#ifndef =
_ASM_X86_64_AMD_IOMMU_ACPI_H=0A-#define _ASM_X86_64_AMD_IOMMU_ACPI_H=0A-=0A=
-#include <xen/acpi.h>=0A-=0A-/* I/O Virtualization Reporting Structure =
*/=0A-#define AMD_IOMMU_ACPI_IVRS_SIG            "IVRS"=0A-#define =
AMD_IOMMU_ACPI_IVHD_TYPE       0x10=0A-#define AMD_IOMMU_ACPI_IVMD_ALL_TYPE=
       0x20=0A-#define AMD_IOMMU_ACPI_IVMD_ONE_TYPE       0x21=0A-#define =
AMD_IOMMU_ACPI_IVMD_RANGE_TYPE     0x22=0A-#define AMD_IOMMU_ACPI_IVMD_IOMM=
U_TYPE     0x23=0A-=0A-/* 4-byte Device Entries */=0A-#define AMD_IOMMU_ACP=
I_IVHD_DEV_U32_PAD        0=0A-#define AMD_IOMMU_ACPI_IVHD_DEV_SELECT     =
2=0A-#define AMD_IOMMU_ACPI_IVHD_DEV_RANGE_START    3=0A-#define AMD_IOMMU_=
ACPI_IVHD_DEV_RANGE_END  4=0A-=0A-/* 8-byte Device Entries */=0A-#define =
AMD_IOMMU_ACPI_IVHD_DEV_U64_PAD        64=0A-#define AMD_IOMMU_ACPI_IVHD_DE=
V_ALIAS_SELECT   66=0A-#define AMD_IOMMU_ACPI_IVHD_DEV_ALIAS_RANGE    =
67=0A-#define AMD_IOMMU_ACPI_IVHD_DEV_EXT_SELECT 70=0A-#define AMD_IOMMU_AC=
PI_IVHD_DEV_EXT_RANGE  71=0A-#define AMD_IOMMU_ACPI_IVHD_DEV_SPECIAL    =
72=0A-=0A-/* IVHD IOMMU Flags */=0A-#define AMD_IOMMU_ACPI_COHERENT_MASK   =
    0x20=0A-#define AMD_IOMMU_ACPI_COHERENT_SHIFT      5=0A-#define =
AMD_IOMMU_ACPI_IOTLB_SUP_MASK      0x10=0A-#define AMD_IOMMU_ACPI_IOTLB_SUP=
_SHIFT     4=0A-#define AMD_IOMMU_ACPI_ISOC_MASK       0x08=0A-#define =
AMD_IOMMU_ACPI_ISOC_SHIFT      3=0A-#define AMD_IOMMU_ACPI_RES_PASS_PW_MASK=
        0x04=0A-#define AMD_IOMMU_ACPI_RES_PASS_PW_SHIFT   2=0A-#define =
AMD_IOMMU_ACPI_PASS_PW_MASK        0x02=0A-#define AMD_IOMMU_ACPI_PASS_PW_S=
HIFT       1=0A-#define AMD_IOMMU_ACPI_HT_TUN_ENB_MASK     0x01=0A-#define =
AMD_IOMMU_ACPI_HT_TUN_ENB_SHIFT        0=0A-=0A-/* IVHD Device Flags =
*/=0A-#define AMD_IOMMU_ACPI_LINT1_PASS_MASK     0x80=0A-#define AMD_IOMMU_=
ACPI_LINT1_PASS_SHIFT        7=0A-#define AMD_IOMMU_ACPI_LINT0_PASS_MASK   =
  0x40=0A-#define AMD_IOMMU_ACPI_LINT0_PASS_SHIFT        6=0A-#define =
AMD_IOMMU_ACPI_SYS_MGT_MASK        0x30=0A-#define AMD_IOMMU_ACPI_SYS_MGT_S=
HIFT       4=0A-#define AMD_IOMMU_ACPI_NMI_PASS_MASK       0x04=0A-#define =
AMD_IOMMU_ACPI_NMI_PASS_SHIFT      2=0A-#define AMD_IOMMU_ACPI_EINT_PASS_MA=
SK      0x02=0A-#define AMD_IOMMU_ACPI_EINT_PASS_SHIFT     1=0A-#define =
AMD_IOMMU_ACPI_INIT_PASS_MASK      0x01=0A-#define AMD_IOMMU_ACPI_INIT_PASS=
_SHIFT     0=0A-=0A-/* IVHD Device Extended Flags */=0A-#define AMD_IOMMU_A=
CPI_ATS_DISABLED_MASK   0x80000000=0A-#define AMD_IOMMU_ACPI_ATS_DISABLED_S=
HIFT  31=0A-=0A-/* IVMD Device Flags */=0A-#define AMD_IOMMU_ACPI_EXCLUSION=
_RANGE_MASK    0x08=0A-#define AMD_IOMMU_ACPI_EXCLUSION_RANGE_SHIFT   =
3=0A-#define AMD_IOMMU_ACPI_IW_PERMISSION_MASK  0x04=0A-#define AMD_IOMMU_A=
CPI_IW_PERMISSION_SHIFT 2=0A-#define AMD_IOMMU_ACPI_IR_PERMISSION_MASK  =
0x02=0A-#define AMD_IOMMU_ACPI_IR_PERMISSION_SHIFT 1=0A-#define AMD_IOMMU_A=
CPI_UNITY_MAPPING_MASK  0x01=0A-#define AMD_IOMMU_ACPI_UNITY_MAPPING_SHIFT =
0=0A-=0A-#define ACPI_OEM_ID_SIZE                6=0A-#define ACPI_OEM_TABL=
E_ID_SIZE          8=0A-=0A-#pragma pack(1)=0A-struct acpi_ivrs_table_heade=
r {=0A-   struct acpi_table_header acpi_header;=0A-   u32 io_info;=0A-   =
u8  reserved[8];=0A-};=0A-=0A-struct acpi_ivrs_block_header {=0A-   u8  =
type;=0A-   u8  flags;=0A-   u16 length;=0A-   u16 dev_id;=0A-};=0A-=0A-str=
uct acpi_ivhd_block_header {=0A-   struct acpi_ivrs_block_header header;=0A=
-   u16 cap_offset;=0A-   u64 mmio_base;=0A-   u16 pci_segment;=0A-   u16 =
iommu_info;=0A-   u8 reserved[4];=0A-};=0A-=0A-struct acpi_ivhd_device_head=
er {=0A-   u8  type;=0A-   u16 dev_id;=0A-   u8  flags;=0A-};=0A-=0A-struct=
 acpi_ivhd_device_trailer {=0A-   u8  type;=0A-   u16 dev_id;=0A-   u8  =
reserved;=0A-};=0A-=0A-struct acpi_ivhd_device_range {=0A-   struct =
acpi_ivhd_device_header header;=0A-   struct acpi_ivhd_device_trailer =
trailer;=0A-};=0A-=0A-struct acpi_ivhd_device_alias {=0A-   struct =
acpi_ivhd_device_header header;=0A-   u8  reserved1;=0A-   u16 dev_id;=0A- =
  u8  reserved2;=0A-};=0A-=0A-struct acpi_ivhd_device_alias_range {=0A-   =
struct acpi_ivhd_device_alias alias;=0A-   struct acpi_ivhd_device_trailer =
trailer;=0A-};=0A-=0A-struct acpi_ivhd_device_extended {=0A-   struct =
acpi_ivhd_device_header header;=0A-   u32 ext_flags;=0A-};=0A-=0A-struct =
acpi_ivhd_device_extended_range {=0A-   struct acpi_ivhd_device_extended =
extended;=0A-   struct acpi_ivhd_device_trailer trailer;=0A-};=0A-=0A-struc=
t acpi_ivhd_device_special {=0A-   struct acpi_ivhd_device_header =
header;=0A-   u8  handle;=0A-   u16 dev_id;=0A-   u8  variety;=0A-};=0A-=0A=
-union acpi_ivhd_device {=0A-   struct acpi_ivhd_device_header header;=0A- =
  struct acpi_ivhd_device_range range;=0A-   struct acpi_ivhd_device_alias =
alias;=0A-   struct acpi_ivhd_device_alias_range alias_range;=0A-   struct =
acpi_ivhd_device_extended extended;=0A-   struct acpi_ivhd_device_extended_=
range extended_range;=0A-   struct acpi_ivhd_device_special special;=0A-};=
=0A-=0A-struct acpi_ivmd_block_header {=0A-   struct acpi_ivrs_block_header=
 header;=0A-   union {=0A-       u16 last_dev_id;=0A-       u16 cap_offset;=
=0A-       u16 reserved1;=0A-   };=0A-   u64 reserved2;=0A-   u64 =
start_addr;=0A-   u64 mem_length;=0A-};=0A-#pragma pack()=0A-=0A-#endif /* =
_ASM_X86_64_AMD_IOMMU_ACPI_H */=0A--- a/xen/include/asm-x86/hvm/svm/amd-iom=
mu-proto.h=0A+++ b/xen/include/asm-x86/hvm/svm/amd-iommu-proto.h=0A@@ =
-26,6 +26,8 @@=0A #include <asm/apicdef.h>=0A #include <xen/domain_page.h>=
=0A =0A+struct acpi_ivrs_hardware;=0A+=0A #define for_each_amd_iommu(amd_io=
mmu) \=0A     list_for_each_entry(amd_iommu, \=0A         &amd_iommu_head, =
list)=0A@@ -41,7 +43,7 @@=0A =0A /* amd-iommu-detect functions */=0A int =
amd_iommu_get_ivrs_dev_entries(void);=0A-int amd_iommu_detect_one_acpi(void=
 *ivhd);=0A+int amd_iommu_detect_one_acpi(const struct acpi_ivrs_hardware =
*);=0A int amd_iommu_detect_acpi(void);=0A void get_iommu_features(struct =
amd_iommu *iommu);=0A =0A@@ -121,11 +123,9 @@ static inline u32 set_field_i=
n_reg_u32(u=0A     return reg_value;=0A }=0A =0A-static inline u8 =
get_field_from_byte(u8 value, u8 mask, u8 shift)=0A+static inline u8 =
get_field_from_byte(u8 value, u8 mask)=0A {=0A-    u8 field;=0A-    field =
=3D (value & mask) >> shift;=0A-    return field;=0A+    return (value & =
mask) / (mask & -mask);=0A }=0A =0A static inline unsigned long region_to_p=
ages(unsigned long addr, unsigned long size)=0A
--=__PartA9860C5A.1__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--=__PartA9860C5A.1__=--


From xen-devel-bounces@lists.xensource.com Mon Dec 12 17:32:13 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 17: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.xensource.com>)
	id 1Ra9j7-0005p2-Qc; Mon, 12 Dec 2011 17:31:45 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Ra9j6-0005ov-8t
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 17:31:44 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1323711048!6867271!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQyODgzMQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14652 invoked from network); 12 Dec 2011 17:30:50 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-7.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Dec 2011 17:30:50 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pBCHUfqi021098
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 12 Dec 2011 17:30:42 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pBCHUaw7016521
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 12 Dec 2011 17:30:39 GMT
Received: from abhmt107.oracle.com (abhmt107.oracle.com [141.146.116.59])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pBCHUSjC020219; Mon, 12 Dec 2011 11:30:29 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 12 Dec 2011 09:30:28 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 3F4C34179A; Mon, 12 Dec 2011 12:29:41 -0500 (EST)
Date: Mon, 12 Dec 2011 12:29:41 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jan Beulich <JBeulich@suse.com>, liang tang <liang.tang@oracle.com>
Message-ID: <20111212172941.GA8619@phenom.dumpdata.com>
References: <1322673664-14642-1-git-send-email-konrad.wilk@oracle.com>
	<1322673664-14642-6-git-send-email-konrad.wilk@oracle.com>
	<4ED755D70200007800064987@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4ED755D70200007800064987@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A020209.4EE63A42.0180,ss=2,re=0.000,fgs=0
Cc: kevin.tian@intel.com, xen-devel@lists.xensource.com,
	Ian.Campbell@citrix.com, linux-acpi@vger.kernel.org,
	mike.mcclurg@citrix.com, jeremy@goop.org,
	stefan.bader@canonical.com, linux-kernel@vger.kernel.org,
	rjw@sisk.pl, konrad@kernel.org, liang.tang@oracle.com,
	ke.yu@intel.com, lenb@kernel.org
Subject: Re: [Xen-devel] [PATCH 5/8] ACPI: add processor driver for Xen
 virtual CPUs.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Dec 01, 2011 at 09:24:23AM +0000, Jan Beulich wrote:
> >>> On 30.11.11 at 18:21, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> > --- a/drivers/acpi/Makefile
> > +++ b/drivers/acpi/Makefile
> > @@ -66,6 +66,7 @@ obj-$(CONFIG_ACPI_CUSTOM_METHOD)+= custom_method.o
> >  # processor has its own "processor." module_param namespace
> >  processor-y			:= processor_driver.o processor_throttling.o
> >  processor-y			+= processor_idle.o processor_thermal.o
> > +processor-y			+= processor_xen.o
> 
> This should minimally be processor-$(CONFIG_XEN), with other things
> adjusted as necessary.

I was under the impression that this was required to get the processor_xen.ko
to be a module. Otherwise it would only compile as built-in.

Liang, can you chime in please?

> 
> >  processor-$(CONFIG_CPU_FREQ)	+= processor_perflib.o
> >  
> >  obj-$(CONFIG_ACPI_PROCESSOR_AGGREGATOR) += acpi_pad.o
> >...
> > --- a/drivers/xen/Kconfig
> > +++ b/drivers/xen/Kconfig
> > @@ -117,6 +117,11 @@ config XEN_SYS_HYPERVISOR
> >  	 virtual environment, /sys/hypervisor will still be present,
> >  	 but will have no xen contents.
> >  
> > +config ACPI_PROCESSOR_XEN
> > +	tristate
> > +	depends on XEN_DOM0 && ACPI_PROCESSOR && CPU_FREQ
> > +	default m
> 
> default ACPI_PROCESSOR
> 
> > +
> >  config XEN_XENBUS_FRONTEND
> >  	tristate
> >  
> > diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
> > index 974fffd..f67450c 100644
> > --- a/drivers/xen/Makefile
> > +++ b/drivers/xen/Makefile
> > @@ -19,6 +19,9 @@ obj-$(CONFIG_XEN_TMEM)			+= tmem.o
> >  obj-$(CONFIG_SWIOTLB_XEN)		+= swiotlb-xen.o
> >  obj-$(CONFIG_XEN_DOM0)			+= pci.o
> >  obj-$(CONFIG_XEN_PCIDEV_BACKEND)	+= xen-pciback/
> > +ifdef CONFIG_ACPI_PROCESSOR_XEN
> > +obj-$(CONFIG_ACPI_PROCESSOR)		+= acpi_processor.o
> > +endif
> 
> obj-$(CONFIG_ACPI_PPROCESSOR_XEN)
> 
> Jan
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 17:32:13 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 17: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.xensource.com>)
	id 1Ra9j7-0005p2-Qc; Mon, 12 Dec 2011 17:31:45 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Ra9j6-0005ov-8t
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 17:31:44 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1323711048!6867271!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQyODgzMQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14652 invoked from network); 12 Dec 2011 17:30:50 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-7.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Dec 2011 17:30:50 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pBCHUfqi021098
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 12 Dec 2011 17:30:42 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pBCHUaw7016521
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 12 Dec 2011 17:30:39 GMT
Received: from abhmt107.oracle.com (abhmt107.oracle.com [141.146.116.59])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pBCHUSjC020219; Mon, 12 Dec 2011 11:30:29 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 12 Dec 2011 09:30:28 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 3F4C34179A; Mon, 12 Dec 2011 12:29:41 -0500 (EST)
Date: Mon, 12 Dec 2011 12:29:41 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jan Beulich <JBeulich@suse.com>, liang tang <liang.tang@oracle.com>
Message-ID: <20111212172941.GA8619@phenom.dumpdata.com>
References: <1322673664-14642-1-git-send-email-konrad.wilk@oracle.com>
	<1322673664-14642-6-git-send-email-konrad.wilk@oracle.com>
	<4ED755D70200007800064987@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4ED755D70200007800064987@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A020209.4EE63A42.0180,ss=2,re=0.000,fgs=0
Cc: kevin.tian@intel.com, xen-devel@lists.xensource.com,
	Ian.Campbell@citrix.com, linux-acpi@vger.kernel.org,
	mike.mcclurg@citrix.com, jeremy@goop.org,
	stefan.bader@canonical.com, linux-kernel@vger.kernel.org,
	rjw@sisk.pl, konrad@kernel.org, liang.tang@oracle.com,
	ke.yu@intel.com, lenb@kernel.org
Subject: Re: [Xen-devel] [PATCH 5/8] ACPI: add processor driver for Xen
 virtual CPUs.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Dec 01, 2011 at 09:24:23AM +0000, Jan Beulich wrote:
> >>> On 30.11.11 at 18:21, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> > --- a/drivers/acpi/Makefile
> > +++ b/drivers/acpi/Makefile
> > @@ -66,6 +66,7 @@ obj-$(CONFIG_ACPI_CUSTOM_METHOD)+= custom_method.o
> >  # processor has its own "processor." module_param namespace
> >  processor-y			:= processor_driver.o processor_throttling.o
> >  processor-y			+= processor_idle.o processor_thermal.o
> > +processor-y			+= processor_xen.o
> 
> This should minimally be processor-$(CONFIG_XEN), with other things
> adjusted as necessary.

I was under the impression that this was required to get the processor_xen.ko
to be a module. Otherwise it would only compile as built-in.

Liang, can you chime in please?

> 
> >  processor-$(CONFIG_CPU_FREQ)	+= processor_perflib.o
> >  
> >  obj-$(CONFIG_ACPI_PROCESSOR_AGGREGATOR) += acpi_pad.o
> >...
> > --- a/drivers/xen/Kconfig
> > +++ b/drivers/xen/Kconfig
> > @@ -117,6 +117,11 @@ config XEN_SYS_HYPERVISOR
> >  	 virtual environment, /sys/hypervisor will still be present,
> >  	 but will have no xen contents.
> >  
> > +config ACPI_PROCESSOR_XEN
> > +	tristate
> > +	depends on XEN_DOM0 && ACPI_PROCESSOR && CPU_FREQ
> > +	default m
> 
> default ACPI_PROCESSOR
> 
> > +
> >  config XEN_XENBUS_FRONTEND
> >  	tristate
> >  
> > diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
> > index 974fffd..f67450c 100644
> > --- a/drivers/xen/Makefile
> > +++ b/drivers/xen/Makefile
> > @@ -19,6 +19,9 @@ obj-$(CONFIG_XEN_TMEM)			+= tmem.o
> >  obj-$(CONFIG_SWIOTLB_XEN)		+= swiotlb-xen.o
> >  obj-$(CONFIG_XEN_DOM0)			+= pci.o
> >  obj-$(CONFIG_XEN_PCIDEV_BACKEND)	+= xen-pciback/
> > +ifdef CONFIG_ACPI_PROCESSOR_XEN
> > +obj-$(CONFIG_ACPI_PROCESSOR)		+= acpi_processor.o
> > +endif
> 
> obj-$(CONFIG_ACPI_PPROCESSOR_XEN)
> 
> Jan
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 17:40:26 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 17: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.xensource.com>)
	id 1Ra9r4-0005yn-Q2; Mon, 12 Dec 2011 17:39:58 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Ra9r4-0005ye-47
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 17:39:58 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1323711498!56975911!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDc4NQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1268 invoked from network); 12 Dec 2011 17:38:18 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Dec 2011 17:38:18 -0000
X-IronPort-AV: E=Sophos;i="4.71,340,1320624000"; 
   d="scan'208";a="9424872"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Dec 2011 17:39:06 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 12 Dec 2011 17:39:06 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Ra9qE-0000G8-AQ; Mon, 12 Dec 2011 17:39:06 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Ra9qE-0003PT-1V;
	Mon, 12 Dec 2011 17:39:06 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20198.15417.932169.223332@mariner.uk.xensource.com>
Date: Mon, 12 Dec 2011 17:39:05 +0000
To: <stefano.stabellini@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1322056320-5826-5-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1111221551510.31179@kaball-desktop>
	<1322056320-5826-5-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com, keir@xen.org, Ian.Campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH v9 5/6] Clone and build Seabios by default
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

stefano.stabellini@eu.citrix.com writes ("[Xen-devel] [PATCH v9 5/6] Clone and build Seabios by default"):
>  QEMU_UPSTREAM_URL ?= http://xenbits.xensource.com/git-http/qemu-upstream-unstable.git
> +SEABIOS_UPSTREAM_URL ?= http://git.qemu.org/git/seabios.git

Do we wanted push-gated versions of these trees too ?

I see you have included a lockstep changeset number in xen-unstable
but are we really able to force these to update in lockstep ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 17:40:26 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 17: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.xensource.com>)
	id 1Ra9r4-0005yn-Q2; Mon, 12 Dec 2011 17:39:58 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Ra9r4-0005ye-47
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 17:39:58 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1323711498!56975911!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDc4NQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1268 invoked from network); 12 Dec 2011 17:38:18 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Dec 2011 17:38:18 -0000
X-IronPort-AV: E=Sophos;i="4.71,340,1320624000"; 
   d="scan'208";a="9424872"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Dec 2011 17:39:06 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 12 Dec 2011 17:39:06 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Ra9qE-0000G8-AQ; Mon, 12 Dec 2011 17:39:06 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Ra9qE-0003PT-1V;
	Mon, 12 Dec 2011 17:39:06 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20198.15417.932169.223332@mariner.uk.xensource.com>
Date: Mon, 12 Dec 2011 17:39:05 +0000
To: <stefano.stabellini@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1322056320-5826-5-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1111221551510.31179@kaball-desktop>
	<1322056320-5826-5-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com, keir@xen.org, Ian.Campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH v9 5/6] Clone and build Seabios by default
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

stefano.stabellini@eu.citrix.com writes ("[Xen-devel] [PATCH v9 5/6] Clone and build Seabios by default"):
>  QEMU_UPSTREAM_URL ?= http://xenbits.xensource.com/git-http/qemu-upstream-unstable.git
> +SEABIOS_UPSTREAM_URL ?= http://git.qemu.org/git/seabios.git

Do we wanted push-gated versions of these trees too ?

I see you have included a lockstep changeset number in xen-unstable
but are we really able to force these to update in lockstep ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 17:45:07 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 17:45:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ra9va-000674-HE; Mon, 12 Dec 2011 17:44:38 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Ra9vZ-00066w-5R
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 17:44:37 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1323711823!7091832!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDc4NQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4971 invoked from network); 12 Dec 2011 17:43:44 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Dec 2011 17:43:44 -0000
X-IronPort-AV: E=Sophos;i="4.71,340,1320624000"; 
   d="scan'208";a="9424924"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Dec 2011 17:43:25 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 12 Dec 2011 17:43:25 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Ra9uP-0000Ht-6d; Mon, 12 Dec 2011 17:43:25 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Ra9uP-0003RV-5U;
	Mon, 12 Dec 2011 17:43:25 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20198.15677.158929.219443@mariner.uk.xensource.com>
Date: Mon, 12 Dec 2011 17:43:25 +0000
To: Andre Przywara <andre.przywara@amd.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <4ED8E3BF.6050509@amd.com>
References: <4ED8E3BF.6050509@amd.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] xl: fix compiler warnings
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Andre Przywara writes ("[Xen-devel] [PATCH] xl: fix compiler warnings"):
> either GCC 4.6.1 or Ubuntu add -Werror=format-security to the -Wall set, 
> so libxl compilation breaks:
>    libxl_create.c: In function 'store_libxl_entry':
>    libxl_create.c:454:9: error: format not a string literal and no 
> format arguments [-Werror=format-security]
>    cc1: all warnings being treated as errors
> 
> attached patch fixes this and another occurrence.

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 17:45:07 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 17:45:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ra9va-000674-HE; Mon, 12 Dec 2011 17:44:38 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Ra9vZ-00066w-5R
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 17:44:37 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1323711823!7091832!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDc4NQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4971 invoked from network); 12 Dec 2011 17:43:44 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Dec 2011 17:43:44 -0000
X-IronPort-AV: E=Sophos;i="4.71,340,1320624000"; 
   d="scan'208";a="9424924"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Dec 2011 17:43:25 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 12 Dec 2011 17:43:25 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Ra9uP-0000Ht-6d; Mon, 12 Dec 2011 17:43:25 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Ra9uP-0003RV-5U;
	Mon, 12 Dec 2011 17:43:25 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20198.15677.158929.219443@mariner.uk.xensource.com>
Date: Mon, 12 Dec 2011 17:43:25 +0000
To: Andre Przywara <andre.przywara@amd.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <4ED8E3BF.6050509@amd.com>
References: <4ED8E3BF.6050509@amd.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] xl: fix compiler warnings
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Andre Przywara writes ("[Xen-devel] [PATCH] xl: fix compiler warnings"):
> either GCC 4.6.1 or Ubuntu add -Werror=format-security to the -Wall set, 
> so libxl compilation breaks:
>    libxl_create.c: In function 'store_libxl_entry':
>    libxl_create.c:454:9: error: format not a string literal and no 
> format arguments [-Werror=format-security]
>    cc1: all warnings being treated as errors
> 
> attached patch fixes this and another occurrence.

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 17:47:15 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 17:47:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ra9xl-0006DW-Ej; Mon, 12 Dec 2011 17:46:53 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1Ra9xf-0006DC-4I
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 17:46:47 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1323711953!7087134!1
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28964 invoked from network); 12 Dec 2011 17:45:53 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Dec 2011 17:45:53 -0000
Received: by wgbds11 with SMTP id ds11so10130214wgb.24
	for <xen-devel@lists.xensource.com>;
	Mon, 12 Dec 2011 09:45:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=cykG4k328J5SbWwqi7CZkyqXBOu3FxyhGhVVxRCI7ik=;
	b=UtEmS5koT3xcCqrsyqTA0jLbjdpO7V743NJxp90kgMWi32sOMH/9xe0FjRfc+0BrEG
	kz7ixowQWr61+ZW/rUPOJZS7FRPdImz234v81hNZb4UI8DECSK6qENaBFz5a+JTwaDLW
	YDWx8+PcmnZXME0IFheffdmxnrA+CJ//uEngA=
Received: by 10.216.137.86 with SMTP id x64mr2913428wei.2.1323711953157;
	Mon, 12 Dec 2011 09:45:53 -0800 (PST)
Received: from [192.168.1.3] (host81-152-17-11.range81-152.btcentralplus.com.
	[81.152.17.11]) by mx.google.com with ESMTPS id
	bl10sm26630578wib.15.2011.12.12.09.45.48
	(version=SSLv3 cipher=OTHER); Mon, 12 Dec 2011 09:45:52 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Mon, 12 Dec 2011 17:45:50 +0000
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Message-ID: <CB0BEE4E.35B0B%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH] x86/microcode: Allow "ucode=" argument to be
	negative
Thread-Index: Acy49eLkU0zeH8ASFEKel76NuG+Vxw==
In-Reply-To: <4EE62B6C0200007800066FBA@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH] x86/microcode: Allow "ucode=" argument to
 be negative
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 12/12/2011 15:27, "Jan Beulich" <JBeulich@suse.com> wrote:

> ... to indicate counting from the end of the modules list.
> 
> Suggested by Tim Deegan.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Keir Fraser <keir@xen.org>

> --- 2011-11-23.orig/xen/arch/x86/microcode.c 2011-11-30 16:52:28.000000000
> +0100
> +++ 2011-11-23/xen/arch/x86/microcode.c 2011-12-06 08:41:13.000000000 +0100
> @@ -41,7 +41,7 @@
>  
>  static module_t __initdata ucode_mod;
>  static void *(*__initdata ucode_mod_map)(const module_t *);
> -static unsigned int __initdata ucode_mod_idx;
> +static signed int __initdata ucode_mod_idx;
>  static bool_t __initdata ucode_mod_forced;
>  static cpumask_t __initdata init_mask;
>  
> @@ -54,7 +54,7 @@ void __init microcode_set_module(unsigne
>  static void __init parse_ucode(char *s)
>  {
>      if ( !ucode_mod_forced )
> -        ucode_mod_idx = simple_strtoul(s, NULL, 0);
> +        ucode_mod_idx = simple_strtol(s, NULL, 0);
>  }
>  custom_param("ucode", parse_ucode);
>  
> @@ -65,7 +65,9 @@ void __init microcode_grab_module(
>  {
>      module_t *mod = (module_t *)__va(mbi->mods_addr);
>  
> -    if ( !ucode_mod_idx || ucode_mod_idx >= mbi->mods_count ||
> +    if ( ucode_mod_idx < 0 )
> +        ucode_mod_idx += mbi->mods_count;
> +    if ( ucode_mod_idx <= 0 || ucode_mod_idx >= mbi->mods_count ||
>           !__test_and_clear_bit(ucode_mod_idx, module_map) )
>          return;
>      ucode_mod = mod[ucode_mod_idx];
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 17:47:15 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 17:47:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ra9xl-0006DW-Ej; Mon, 12 Dec 2011 17:46:53 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1Ra9xf-0006DC-4I
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 17:46:47 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1323711953!7087134!1
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28964 invoked from network); 12 Dec 2011 17:45:53 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Dec 2011 17:45:53 -0000
Received: by wgbds11 with SMTP id ds11so10130214wgb.24
	for <xen-devel@lists.xensource.com>;
	Mon, 12 Dec 2011 09:45:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=cykG4k328J5SbWwqi7CZkyqXBOu3FxyhGhVVxRCI7ik=;
	b=UtEmS5koT3xcCqrsyqTA0jLbjdpO7V743NJxp90kgMWi32sOMH/9xe0FjRfc+0BrEG
	kz7ixowQWr61+ZW/rUPOJZS7FRPdImz234v81hNZb4UI8DECSK6qENaBFz5a+JTwaDLW
	YDWx8+PcmnZXME0IFheffdmxnrA+CJ//uEngA=
Received: by 10.216.137.86 with SMTP id x64mr2913428wei.2.1323711953157;
	Mon, 12 Dec 2011 09:45:53 -0800 (PST)
Received: from [192.168.1.3] (host81-152-17-11.range81-152.btcentralplus.com.
	[81.152.17.11]) by mx.google.com with ESMTPS id
	bl10sm26630578wib.15.2011.12.12.09.45.48
	(version=SSLv3 cipher=OTHER); Mon, 12 Dec 2011 09:45:52 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Mon, 12 Dec 2011 17:45:50 +0000
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Message-ID: <CB0BEE4E.35B0B%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH] x86/microcode: Allow "ucode=" argument to be
	negative
Thread-Index: Acy49eLkU0zeH8ASFEKel76NuG+Vxw==
In-Reply-To: <4EE62B6C0200007800066FBA@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH] x86/microcode: Allow "ucode=" argument to
 be negative
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 12/12/2011 15:27, "Jan Beulich" <JBeulich@suse.com> wrote:

> ... to indicate counting from the end of the modules list.
> 
> Suggested by Tim Deegan.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Keir Fraser <keir@xen.org>

> --- 2011-11-23.orig/xen/arch/x86/microcode.c 2011-11-30 16:52:28.000000000
> +0100
> +++ 2011-11-23/xen/arch/x86/microcode.c 2011-12-06 08:41:13.000000000 +0100
> @@ -41,7 +41,7 @@
>  
>  static module_t __initdata ucode_mod;
>  static void *(*__initdata ucode_mod_map)(const module_t *);
> -static unsigned int __initdata ucode_mod_idx;
> +static signed int __initdata ucode_mod_idx;
>  static bool_t __initdata ucode_mod_forced;
>  static cpumask_t __initdata init_mask;
>  
> @@ -54,7 +54,7 @@ void __init microcode_set_module(unsigne
>  static void __init parse_ucode(char *s)
>  {
>      if ( !ucode_mod_forced )
> -        ucode_mod_idx = simple_strtoul(s, NULL, 0);
> +        ucode_mod_idx = simple_strtol(s, NULL, 0);
>  }
>  custom_param("ucode", parse_ucode);
>  
> @@ -65,7 +65,9 @@ void __init microcode_grab_module(
>  {
>      module_t *mod = (module_t *)__va(mbi->mods_addr);
>  
> -    if ( !ucode_mod_idx || ucode_mod_idx >= mbi->mods_count ||
> +    if ( ucode_mod_idx < 0 )
> +        ucode_mod_idx += mbi->mods_count;
> +    if ( ucode_mod_idx <= 0 || ucode_mod_idx >= mbi->mods_count ||
>           !__test_and_clear_bit(ucode_mod_idx, module_map) )
>          return;
>      ucode_mod = mod[ucode_mod_idx];
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 17:47:40 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 17:47:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ra9yD-0006Fl-Sk; Mon, 12 Dec 2011 17:47:21 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1Ra9yC-0006FF-As
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 17:47:20 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1323711984!6927003!1
X-Originating-IP: [209.85.215.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9504 invoked from network); 12 Dec 2011 17:46:24 -0000
Received: from mail-ey0-f171.google.com (HELO mail-ey0-f171.google.com)
	(209.85.215.171)
	by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Dec 2011 17:46:24 -0000
Received: by eaa1 with SMTP id 1so9011336eaa.30
	for <xen-devel@lists.xensource.com>;
	Mon, 12 Dec 2011 09:46:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=7h3g5brkZDyLuDhfl7WFVlmMid1KlZ5VbeUbi68ujGs=;
	b=rcf3UJZqQGkAWeuR8cUaOx2TMNnw6+7AoeCw7Smu5Ynrzn6qz7j0+usVH9FmPIsUZ+
	uTCFHsFbcUjOwzl/3WNWrR6BpQOyg5HRbKlWSf3VkvMDfILnztvjE1YJFfKo7GYVloBC
	ti+q95DMw2u7dKy8uhfDTBfyIWUOMaN8uuGI8=
Received: by 10.216.14.132 with SMTP id d4mr2487236wed.37.1323711984242;
	Mon, 12 Dec 2011 09:46:24 -0800 (PST)
Received: from [192.168.1.3] (host81-152-17-11.range81-152.btcentralplus.com.
	[81.152.17.11])
	by mx.google.com with ESMTPS id u3sm26643528wiu.10.2011.12.12.09.46.21
	(version=SSLv3 cipher=OTHER); Mon, 12 Dec 2011 09:46:23 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Mon, 12 Dec 2011 17:46:23 +0000
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Message-ID: <CB0BEE6F.35B0C%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH] x86: add platform hypercall to retrieve
	pCPU-s' family, model, and stepping
Thread-Index: Acy49faP7y6lkUxuWUqt4j56RR15Zg==
In-Reply-To: <4EE62C8D0200007800066FCF@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH] x86: add platform hypercall to retrieve
 pCPU-s' family, model, and stepping
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 12/12/2011 15:32, "Jan Beulich" <JBeulich@suse.com> wrote:

> With the recent hotplug changes to the Xen part of the microcode
> loading, this allows the kernel driver to avoid unnecessary calls into
> the hypervisor during pCPU hot-enabling: Knowing that the hypervisor
> retains the data for already booted CPUs, only data for CPUs with a
> different signature needs to be passed down. Since the microcode
> loading code can be pretty verbose, avoiding to invoke it can make the
> log much easier to look at in case of problems.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Keir Fraser <keir@xen.org>

> --- 2011-11-23.orig/xen/arch/x86/platform_hypercall.c 2011-12-01
> 12:06:55.000000000 +0100
> +++ 2011-11-23/xen/arch/x86/platform_hypercall.c 2011-12-09 17:39:04.000000000
> +0100
> @@ -469,6 +469,42 @@ ret_t do_platform_op(XEN_GUEST_HANDLE(xe
>      }
>      break;
>  
> +    case XENPF_get_cpu_version:
> +    {
> +        struct xenpf_pcpu_version *ver = &op->u.pcpu_version;
> +
> +        if ( !get_cpu_maps() )
> +        {
> +            ret = -EBUSY;
> +            break;
> +        }
> +
> +        if ( (ver->xen_cpuid >= nr_cpu_ids) || !cpu_online(ver->xen_cpuid) )
> +        {
> +            memset(ver->vendor_id, 0, sizeof(ver->vendor_id));
> +            ver->family = 0;
> +            ver->model = 0;
> +            ver->stepping = 0;
> +        }
> +        else
> +        {
> +            const struct cpuinfo_x86 *c = &cpu_data[ver->xen_cpuid];
> +
> +            memcpy(ver->vendor_id, c->x86_vendor_id, sizeof(ver->vendor_id));
> +            ver->family = c->x86;
> +            ver->model = c->x86_model;
> +            ver->stepping = c->x86_mask;
> +        }
> +
> +        ver->max_present = cpumask_last(&cpu_present_map);
> +
> +        put_cpu_maps();
> +
> +        if ( copy_field_to_guest(u_xenpf_op, op, u.pcpu_version) )
> +            ret = -EFAULT;
> +    }
> +    break;
> +
>      case XENPF_cpu_online:
>      {
>          int cpu = op->u.cpu_ol.cpuid;
> --- 2011-11-23.orig/xen/arch/x86/x86_64/platform_hypercall.c 2011-12-09
> 17:40:49.000000000 +0100
> +++ 2011-11-23/xen/arch/x86/x86_64/platform_hypercall.c 2011-12-01
> 16:04:28.000000000 +0100
> @@ -3,7 +3,7 @@
>   */
>  
>  #include <xen/config.h>
> -#include <xen/types.h>
> +#include <xen/lib.h>
>  #include <compat/platform.h>
>  
>  DEFINE_XEN_GUEST_HANDLE(compat_platform_op_t);
> @@ -26,8 +26,13 @@ DEFINE_XEN_GUEST_HANDLE(compat_platform_
>  #define xen_processor_power_t   compat_processor_power_t
>  #define set_cx_pminfo           compat_set_cx_pminfo
>  
> -#define xenpf_pcpuinfo compat_pf_pcpuinfo
> -#define xenpf_pcpuinfo_t compat_pf_pcpuinfo_t
> +#define xen_pf_pcpuinfo xenpf_pcpuinfo
> +CHECK_pf_pcpuinfo;
> +#undef xen_pf_pcpuinfo
> +
> +#define xen_pf_pcpu_version xenpf_pcpu_version
> +CHECK_pf_pcpu_version;
> +#undef xen_pf_pcpu_version
>  
>  #define xenpf_enter_acpi_sleep compat_pf_enter_acpi_sleep
>  
> --- 2011-11-23.orig/xen/include/public/platform.h 2011-12-09
> 17:40:49.000000000 +0100
> +++ 2011-11-23/xen/include/public/platform.h 2011-12-09 17:39:17.000000000
> +0100
> @@ -449,6 +449,21 @@ struct xenpf_pcpuinfo {
>  typedef struct xenpf_pcpuinfo xenpf_pcpuinfo_t;
>  DEFINE_XEN_GUEST_HANDLE(xenpf_pcpuinfo_t);
>  
> +#define XENPF_get_cpu_version 48
> +struct xenpf_pcpu_version {
> +    /* IN */
> +    uint32_t xen_cpuid;
> +    /* OUT */
> +    /* The maxium cpu_id that is present */
> +    uint32_t max_present;
> +    char vendor_id[12];
> +    uint32_t family;
> +    uint32_t model;
> +    uint32_t stepping;
> +};
> +typedef struct xenpf_pcpu_version xenpf_pcpu_version_t;
> +DEFINE_XEN_GUEST_HANDLE(xenpf_pcpu_version_t);
> +
>  #define XENPF_cpu_online    56
>  #define XENPF_cpu_offline   57
>  struct xenpf_cpu_ol
> @@ -492,6 +507,7 @@ struct xen_platform_op {
>          struct xenpf_getidletime       getidletime;
>          struct xenpf_set_processor_pminfo set_pminfo;
>          struct xenpf_pcpuinfo          pcpu_info;
> +        struct xenpf_pcpu_version      pcpu_version;
>          struct xenpf_cpu_ol            cpu_ol;
>          struct xenpf_cpu_hotadd        cpu_add;
>          struct xenpf_mem_hotadd        mem_add;
> --- 2011-11-23.orig/xen/include/xlat.lst 2011-12-09 17:40:49.000000000 +0100
> +++ 2011-11-23/xen/include/xlat.lst 2011-12-01 15:46:31.000000000 +0100
> @@ -72,6 +72,17 @@
>  ? physdev_restore_msi  physdev.h
>  ? physdev_set_iopl  physdev.h
>  ? physdev_setup_gsi  physdev.h
> +! pct_register   platform.h
> +! power_register   platform.h
> +? processor_csd   platform.h
> +! processor_cx   platform.h
> +! processor_flags   platform.h
> +! processor_performance  platform.h
> +! processor_power   platform.h
> +? processor_px   platform.h
> +! psd_package   platform.h
> +? xenpf_pcpuinfo   platform.h
> +? xenpf_pcpu_version  platform.h
>  ! sched_poll   sched.h
>  ? sched_remote_shutdown  sched.h
>  ? sched_shutdown   sched.h
> @@ -84,12 +95,3 @@
>  ! vcpu_set_singleshot_timer vcpu.h
>  ? xenoprof_init   xenoprof.h
>  ? xenoprof_passive  xenoprof.h
> -! power_register   platform.h
> -? processor_csd   platform.h
> -! processor_cx   platform.h
> -! processor_flags   platform.h
> -! processor_power   platform.h
> -! pct_register   platform.h
> -? processor_px   platform.h
> -! psd_package   platform.h
> -! processor_performance  platform.h
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 17:47:40 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 17:47:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ra9yD-0006Fl-Sk; Mon, 12 Dec 2011 17:47:21 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1Ra9yC-0006FF-As
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 17:47:20 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1323711984!6927003!1
X-Originating-IP: [209.85.215.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9504 invoked from network); 12 Dec 2011 17:46:24 -0000
Received: from mail-ey0-f171.google.com (HELO mail-ey0-f171.google.com)
	(209.85.215.171)
	by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Dec 2011 17:46:24 -0000
Received: by eaa1 with SMTP id 1so9011336eaa.30
	for <xen-devel@lists.xensource.com>;
	Mon, 12 Dec 2011 09:46:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=7h3g5brkZDyLuDhfl7WFVlmMid1KlZ5VbeUbi68ujGs=;
	b=rcf3UJZqQGkAWeuR8cUaOx2TMNnw6+7AoeCw7Smu5Ynrzn6qz7j0+usVH9FmPIsUZ+
	uTCFHsFbcUjOwzl/3WNWrR6BpQOyg5HRbKlWSf3VkvMDfILnztvjE1YJFfKo7GYVloBC
	ti+q95DMw2u7dKy8uhfDTBfyIWUOMaN8uuGI8=
Received: by 10.216.14.132 with SMTP id d4mr2487236wed.37.1323711984242;
	Mon, 12 Dec 2011 09:46:24 -0800 (PST)
Received: from [192.168.1.3] (host81-152-17-11.range81-152.btcentralplus.com.
	[81.152.17.11])
	by mx.google.com with ESMTPS id u3sm26643528wiu.10.2011.12.12.09.46.21
	(version=SSLv3 cipher=OTHER); Mon, 12 Dec 2011 09:46:23 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Mon, 12 Dec 2011 17:46:23 +0000
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Message-ID: <CB0BEE6F.35B0C%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH] x86: add platform hypercall to retrieve
	pCPU-s' family, model, and stepping
Thread-Index: Acy49faP7y6lkUxuWUqt4j56RR15Zg==
In-Reply-To: <4EE62C8D0200007800066FCF@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH] x86: add platform hypercall to retrieve
 pCPU-s' family, model, and stepping
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 12/12/2011 15:32, "Jan Beulich" <JBeulich@suse.com> wrote:

> With the recent hotplug changes to the Xen part of the microcode
> loading, this allows the kernel driver to avoid unnecessary calls into
> the hypervisor during pCPU hot-enabling: Knowing that the hypervisor
> retains the data for already booted CPUs, only data for CPUs with a
> different signature needs to be passed down. Since the microcode
> loading code can be pretty verbose, avoiding to invoke it can make the
> log much easier to look at in case of problems.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Keir Fraser <keir@xen.org>

> --- 2011-11-23.orig/xen/arch/x86/platform_hypercall.c 2011-12-01
> 12:06:55.000000000 +0100
> +++ 2011-11-23/xen/arch/x86/platform_hypercall.c 2011-12-09 17:39:04.000000000
> +0100
> @@ -469,6 +469,42 @@ ret_t do_platform_op(XEN_GUEST_HANDLE(xe
>      }
>      break;
>  
> +    case XENPF_get_cpu_version:
> +    {
> +        struct xenpf_pcpu_version *ver = &op->u.pcpu_version;
> +
> +        if ( !get_cpu_maps() )
> +        {
> +            ret = -EBUSY;
> +            break;
> +        }
> +
> +        if ( (ver->xen_cpuid >= nr_cpu_ids) || !cpu_online(ver->xen_cpuid) )
> +        {
> +            memset(ver->vendor_id, 0, sizeof(ver->vendor_id));
> +            ver->family = 0;
> +            ver->model = 0;
> +            ver->stepping = 0;
> +        }
> +        else
> +        {
> +            const struct cpuinfo_x86 *c = &cpu_data[ver->xen_cpuid];
> +
> +            memcpy(ver->vendor_id, c->x86_vendor_id, sizeof(ver->vendor_id));
> +            ver->family = c->x86;
> +            ver->model = c->x86_model;
> +            ver->stepping = c->x86_mask;
> +        }
> +
> +        ver->max_present = cpumask_last(&cpu_present_map);
> +
> +        put_cpu_maps();
> +
> +        if ( copy_field_to_guest(u_xenpf_op, op, u.pcpu_version) )
> +            ret = -EFAULT;
> +    }
> +    break;
> +
>      case XENPF_cpu_online:
>      {
>          int cpu = op->u.cpu_ol.cpuid;
> --- 2011-11-23.orig/xen/arch/x86/x86_64/platform_hypercall.c 2011-12-09
> 17:40:49.000000000 +0100
> +++ 2011-11-23/xen/arch/x86/x86_64/platform_hypercall.c 2011-12-01
> 16:04:28.000000000 +0100
> @@ -3,7 +3,7 @@
>   */
>  
>  #include <xen/config.h>
> -#include <xen/types.h>
> +#include <xen/lib.h>
>  #include <compat/platform.h>
>  
>  DEFINE_XEN_GUEST_HANDLE(compat_platform_op_t);
> @@ -26,8 +26,13 @@ DEFINE_XEN_GUEST_HANDLE(compat_platform_
>  #define xen_processor_power_t   compat_processor_power_t
>  #define set_cx_pminfo           compat_set_cx_pminfo
>  
> -#define xenpf_pcpuinfo compat_pf_pcpuinfo
> -#define xenpf_pcpuinfo_t compat_pf_pcpuinfo_t
> +#define xen_pf_pcpuinfo xenpf_pcpuinfo
> +CHECK_pf_pcpuinfo;
> +#undef xen_pf_pcpuinfo
> +
> +#define xen_pf_pcpu_version xenpf_pcpu_version
> +CHECK_pf_pcpu_version;
> +#undef xen_pf_pcpu_version
>  
>  #define xenpf_enter_acpi_sleep compat_pf_enter_acpi_sleep
>  
> --- 2011-11-23.orig/xen/include/public/platform.h 2011-12-09
> 17:40:49.000000000 +0100
> +++ 2011-11-23/xen/include/public/platform.h 2011-12-09 17:39:17.000000000
> +0100
> @@ -449,6 +449,21 @@ struct xenpf_pcpuinfo {
>  typedef struct xenpf_pcpuinfo xenpf_pcpuinfo_t;
>  DEFINE_XEN_GUEST_HANDLE(xenpf_pcpuinfo_t);
>  
> +#define XENPF_get_cpu_version 48
> +struct xenpf_pcpu_version {
> +    /* IN */
> +    uint32_t xen_cpuid;
> +    /* OUT */
> +    /* The maxium cpu_id that is present */
> +    uint32_t max_present;
> +    char vendor_id[12];
> +    uint32_t family;
> +    uint32_t model;
> +    uint32_t stepping;
> +};
> +typedef struct xenpf_pcpu_version xenpf_pcpu_version_t;
> +DEFINE_XEN_GUEST_HANDLE(xenpf_pcpu_version_t);
> +
>  #define XENPF_cpu_online    56
>  #define XENPF_cpu_offline   57
>  struct xenpf_cpu_ol
> @@ -492,6 +507,7 @@ struct xen_platform_op {
>          struct xenpf_getidletime       getidletime;
>          struct xenpf_set_processor_pminfo set_pminfo;
>          struct xenpf_pcpuinfo          pcpu_info;
> +        struct xenpf_pcpu_version      pcpu_version;
>          struct xenpf_cpu_ol            cpu_ol;
>          struct xenpf_cpu_hotadd        cpu_add;
>          struct xenpf_mem_hotadd        mem_add;
> --- 2011-11-23.orig/xen/include/xlat.lst 2011-12-09 17:40:49.000000000 +0100
> +++ 2011-11-23/xen/include/xlat.lst 2011-12-01 15:46:31.000000000 +0100
> @@ -72,6 +72,17 @@
>  ? physdev_restore_msi  physdev.h
>  ? physdev_set_iopl  physdev.h
>  ? physdev_setup_gsi  physdev.h
> +! pct_register   platform.h
> +! power_register   platform.h
> +? processor_csd   platform.h
> +! processor_cx   platform.h
> +! processor_flags   platform.h
> +! processor_performance  platform.h
> +! processor_power   platform.h
> +? processor_px   platform.h
> +! psd_package   platform.h
> +? xenpf_pcpuinfo   platform.h
> +? xenpf_pcpu_version  platform.h
>  ! sched_poll   sched.h
>  ? sched_remote_shutdown  sched.h
>  ? sched_shutdown   sched.h
> @@ -84,12 +95,3 @@
>  ! vcpu_set_singleshot_timer vcpu.h
>  ? xenoprof_init   xenoprof.h
>  ? xenoprof_passive  xenoprof.h
> -! power_register   platform.h
> -? processor_csd   platform.h
> -! processor_cx   platform.h
> -! processor_flags   platform.h
> -! processor_power   platform.h
> -! pct_register   platform.h
> -? processor_px   platform.h
> -! psd_package   platform.h
> -! processor_performance  platform.h
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 17:47:49 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 17:47:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ra9yS-0006HP-E0; Mon, 12 Dec 2011 17:47:36 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Ra9yQ-0006GV-QQ
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 17:47:35 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1323712001!6916478!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDc4NQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8843 invoked from network); 12 Dec 2011 17:46:41 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Dec 2011 17:46:41 -0000
X-IronPort-AV: E=Sophos;i="4.71,340,1320624000"; 
   d="scan'208";a="9424969"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Dec 2011 17:46:41 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 12 Dec 2011 17:46:41 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Mon, 12 Dec 2011 17:46:41 +0000
In-Reply-To: <20198.15417.932169.223332@mariner.uk.xensource.com>
References: <alpine.DEB.2.00.1111221551510.31179@kaball-desktop>
	<1322056320-5826-5-git-send-email-stefano.stabellini@eu.citrix.com>
	<20198.15417.932169.223332@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323712001.20077.234.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Keir
	\(Xen.org\)" <keir@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v9 5/6] Clone and build Seabios by default
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2011-12-12 at 17:39 +0000, Ian Jackson wrote:
> stefano.stabellini@eu.citrix.com writes ("[Xen-devel] [PATCH v9 5/6] Clone and build Seabios by default"):
> >  QEMU_UPSTREAM_URL ?= http://xenbits.xensource.com/git-http/qemu-upstream-unstable.git
> > +SEABIOS_UPSTREAM_URL ?= http://git.qemu.org/git/seabios.git
> 
> Do we wanted push-gated versions of these trees too ?
> 
> I see you have included a lockstep changeset number in xen-unstable
> but are we really able to force these to update in lockstep ?

We should have a mirror on xenbits, we generally avoid reliance on third
party resources in our builds. Not just source repositories but also for
things like tarball downloads.

Also the upstream for seabios is git://git.seabios.org/seabios.git I
don't think indirecting via qemu buys us anything.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 17:47:49 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 17:47:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ra9yS-0006HP-E0; Mon, 12 Dec 2011 17:47:36 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Ra9yQ-0006GV-QQ
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 17:47:35 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1323712001!6916478!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDc4NQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8843 invoked from network); 12 Dec 2011 17:46:41 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Dec 2011 17:46:41 -0000
X-IronPort-AV: E=Sophos;i="4.71,340,1320624000"; 
   d="scan'208";a="9424969"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Dec 2011 17:46:41 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 12 Dec 2011 17:46:41 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Mon, 12 Dec 2011 17:46:41 +0000
In-Reply-To: <20198.15417.932169.223332@mariner.uk.xensource.com>
References: <alpine.DEB.2.00.1111221551510.31179@kaball-desktop>
	<1322056320-5826-5-git-send-email-stefano.stabellini@eu.citrix.com>
	<20198.15417.932169.223332@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323712001.20077.234.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Keir
	\(Xen.org\)" <keir@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v9 5/6] Clone and build Seabios by default
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2011-12-12 at 17:39 +0000, Ian Jackson wrote:
> stefano.stabellini@eu.citrix.com writes ("[Xen-devel] [PATCH v9 5/6] Clone and build Seabios by default"):
> >  QEMU_UPSTREAM_URL ?= http://xenbits.xensource.com/git-http/qemu-upstream-unstable.git
> > +SEABIOS_UPSTREAM_URL ?= http://git.qemu.org/git/seabios.git
> 
> Do we wanted push-gated versions of these trees too ?
> 
> I see you have included a lockstep changeset number in xen-unstable
> but are we really able to force these to update in lockstep ?

We should have a mirror on xenbits, we generally avoid reliance on third
party resources in our builds. Not just source repositories but also for
things like tarball downloads.

Also the upstream for seabios is git://git.seabios.org/seabios.git I
don't think indirecting via qemu buys us anything.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 17:47:58 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 17: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.xensource.com>)
	id 1Ra9yX-0006Ia-RR; Mon, 12 Dec 2011 17:47:41 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1Ra9yW-0006H7-B5
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 17:47:40 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1323712006!1208850!1
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7067 invoked from network); 12 Dec 2011 17:46:46 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Dec 2011 17:46:46 -0000
Received: by wgbds11 with SMTP id ds11so10131380wgb.24
	for <xen-devel@lists.xensource.com>;
	Mon, 12 Dec 2011 09:46:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=QeEpkNMzYNfjj2+89a4CO+6oQlhtoN2pklt8RGrLfio=;
	b=hcxwOzsWSlDxaMPTDwZQjeoxKduVTweA6WePKqg3G2dpy6gMIh6g3PBeYx9N+pYmjQ
	rD+zRrD4T8OxbbIs8hyq0S6c43KLvHgW6J+HY04U4ic2AQYWsi8STocmJulvfB5QV+ll
	AxVm1EP0d+MH9AgIFomTIWWfKhzbGg/mSJrB0=
Received: by 10.227.208.134 with SMTP id gc6mr10496569wbb.3.1323712006622;
	Mon, 12 Dec 2011 09:46:46 -0800 (PST)
Received: from [192.168.1.3] (host81-152-17-11.range81-152.btcentralplus.com.
	[81.152.17.11])
	by mx.google.com with ESMTPS id ep13sm23891281wbb.8.2011.12.12.09.46.45
	(version=SSLv3 cipher=OTHER); Mon, 12 Dec 2011 09:46:46 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Mon, 12 Dec 2011 17:46:44 +0000
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Message-ID: <CB0BEE84.35B0D%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH] x86: remove redundant MCE related MSR
	definitions
Thread-Index: Acy49gMTDkngLfbrY02c0SROLgvi/g==
In-Reply-To: <4EE62D480200007800066FE7@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH] x86: remove redundant MCE related MSR
 definitions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 12/12/2011 15:35, "Jan Beulich" <JBeulich@suse.com> wrote:

> Two definitions (the first register and a macro to calculate the
> register for a given bank) are sufficient per kind of register.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Keir Fraser <keir@xen.org>

> --- 2011-11-23.orig/xen/arch/x86/cpu/mcheck/amd_nonfatal.c 2011-12-05
> 11:38:33.000000000 +0100
> +++ 2011-11-23/xen/arch/x86/cpu/mcheck/amd_nonfatal.c 2011-12-05
> 11:24:15.000000000 +0100
> @@ -144,7 +144,7 @@ static void mce_amd_work_fn(void *data)
> uint64_t value;
> uint32_t counter;
>  
> -  value = mca_rdmsr(MSR_IA32_MC4_MISC);
> +  value = mca_rdmsr(MSR_IA32_MCx_MISC(4));
> /* Only the error counter field is of interest
> * Bit field is described in AMD K8 BKDG chapter 6.4.5.5
> */
> @@ -174,7 +174,7 @@ static void mce_amd_work_fn(void *data)
> value &= ~(0x60FFF00000000ULL);
> /* Counter enable */
> value |= (1ULL << 51);
> -   mca_wrmsr(MSR_IA32_MC4_MISC, value);
> +   mca_wrmsr(MSR_IA32_MCx_MISC(4), value);
> wmb();
> }
> }
> @@ -217,7 +217,7 @@ void amd_nonfatal_mcheck_init(struct cpu
>  
> /* hw threshold registers present */
> hw_threshold = 1;
> -  rdmsrl(MSR_IA32_MC4_MISC, value);
> +  rdmsrl(MSR_IA32_MCx_MISC(4), value);
>  
> if (value & (1ULL << 61)) { /* Locked bit */
> /* Locked by BIOS. Not available for use */
> @@ -238,7 +238,7 @@ void amd_nonfatal_mcheck_init(struct cpu
> value &= ~(0x60FFF00000000ULL);
> /* Counter enable */
> value |= (1ULL << 51);
> -   wrmsrl(MSR_IA32_MC4_MISC, value);
> +   wrmsrl(MSR_IA32_MCx_MISC(4), value);
> /* serialize */
> wmb();
> printk(XENLOG_INFO "MCA: Use hw thresholding to adjust polling frequency\n");
> --- 2011-11-23.orig/xen/arch/x86/cpu/mcheck/mce_amd_quirks.c 2011-12-05
> 11:41:00.000000000 +0100
> +++ 2011-11-23/xen/arch/x86/cpu/mcheck/mce_amd_quirks.c 2011-12-05
> 11:42:03.000000000 +0100
> @@ -68,8 +68,8 @@ int mcequirk_amd_apply(enum mcequirk_amd
> * TBL walk error reporting, which trips off incorrectly
> * with AGP GART & 3ware & Cerberus.
> */
> -  wrmsrl(MSR_IA32_MC4_CTL, ~(1ULL << 10));
> -  wrmsrl(MSR_IA32_MC4_STATUS, 0ULL);
> +  wrmsrl(MSR_IA32_MCx_CTL(4), ~(1ULL << 10));
> +  wrmsrl(MSR_IA32_MCx_STATUS(4), 0ULL);
> break;
> case MCEQUIRK_F10_GART:
> if (rdmsr_safe(MSR_AMD64_MCx_MASK(4), val) == 0)
> --- 2011-11-23.orig/xen/arch/x86/cpu/mcheck/mce_intel.c 2011-12-05
> 11:38:33.000000000 +0100
> +++ 2011-11-23/xen/arch/x86/cpu/mcheck/mce_intel.c 2011-12-05
> 11:27:53.000000000 +0100
> @@ -986,7 +986,7 @@ static DEFINE_SPINLOCK(cmci_discover_loc
>   */
>  static int do_cmci_discover(int i)
>  {
> -    unsigned msr = MSR_IA32_MC0_CTL2 + i;
> +    unsigned msr = MSR_IA32_MCx_CTL2(i);
>      u64 val;
>  
>      rdmsrl(msr, val);
> @@ -1095,7 +1095,7 @@ static void clear_cmci(void)
>              smp_processor_id());
>  
>      for (i = 0; i < nr_mce_banks; i++) {
> -        unsigned msr = MSR_IA32_MC0_CTL2 + i;
> +        unsigned msr = MSR_IA32_MCx_CTL2(i);
>          u64 val;
>          if (!mcabanks_test(i, __get_cpu_var(mce_banks_owned)))
>              continue;
> --- 2011-11-23.orig/xen/arch/x86/hvm/svm/svm.c 2011-12-05 11:38:33.000000000
> +0100
> +++ 2011-11-23/xen/arch/x86/hvm/svm/svm.c 2011-12-05 11:25:55.000000000 +0100
> @@ -1318,7 +1318,7 @@ static int svm_msr_read_intercept(unsign
>          *msr_content = v->arch.hvm_svm.guest_sysenter_eip;
>          break;
>  
> -    case MSR_IA32_MC4_MISC: /* Threshold register */
> +    case MSR_IA32_MCx_MISC(4): /* Threshold register */
>      case MSR_F10_MC4_MISC1 ... MSR_F10_MC4_MISC3:
>          /*
>           * MCA/MCE: We report that the threshold register is unavailable
> @@ -1498,7 +1498,7 @@ static int svm_msr_write_intercept(unsig
>          vpmu_do_wrmsr(msr, msr_content);
>          break;
>  
> -    case MSR_IA32_MC4_MISC: /* Threshold register */
> +    case MSR_IA32_MCx_MISC(4): /* Threshold register */
>      case MSR_F10_MC4_MISC1 ... MSR_F10_MC4_MISC3:
>          /*
>           * MCA/MCE: Threshold register is reported to be locked, so we ignore
> --- 2011-11-23.orig/xen/include/asm-x86/msr-index.h 2011-12-05
> 11:06:39.000000000 +0100
> +++ 2011-11-23/xen/include/asm-x86/msr-index.h 2011-12-05 11:21:46.000000000
> +0100
> @@ -100,58 +100,11 @@
>  
>  #define MSR_AMD64_MC0_MASK  0xc0010044
>  
> -#define MSR_IA32_MC1_CTL  0x00000404
> -#define MSR_IA32_MC1_CTL2  0x00000281
> -#define MSR_IA32_MC1_STATUS  0x00000405
> -#define MSR_IA32_MC1_ADDR  0x00000406
> -#define MSR_IA32_MC1_MISC  0x00000407
> -
> -#define MSR_IA32_MC2_CTL  0x00000408
> -#define MSR_IA32_MC2_CTL2  0x00000282
> -#define MSR_IA32_MC2_STATUS  0x00000409
> -#define MSR_IA32_MC2_ADDR  0x0000040A
> -#define MSR_IA32_MC2_MISC  0x0000040B
> -
> -#define MSR_IA32_MC3_CTL2  0x00000283
> -#define MSR_IA32_MC3_CTL  0x0000040C
> -#define MSR_IA32_MC3_STATUS  0x0000040D
> -#define MSR_IA32_MC3_ADDR  0x0000040E
> -#define MSR_IA32_MC3_MISC  0x0000040F
> -
> -#define MSR_IA32_MC4_CTL2  0x00000284
> -#define MSR_IA32_MC4_CTL  0x00000410
> -#define MSR_IA32_MC4_STATUS  0x00000411
> -#define MSR_IA32_MC4_ADDR  0x00000412
> -#define MSR_IA32_MC4_MISC  0x00000413
> -
> -#define MSR_IA32_MC5_CTL2  0x00000285
> -#define MSR_IA32_MC5_CTL  0x00000414
> -#define MSR_IA32_MC5_STATUS  0x00000415
> -#define MSR_IA32_MC5_ADDR  0x00000416
> -#define MSR_IA32_MC5_MISC  0x00000417
> -
> -#define MSR_IA32_MC6_CTL2  0x00000286
> -#define MSR_IA32_MC6_CTL  0x00000418
> -#define MSR_IA32_MC6_STATUS  0x00000419
> -#define MSR_IA32_MC6_ADDR  0x0000041A
> -#define MSR_IA32_MC6_MISC  0x0000041B
> -
> -#define MSR_IA32_MC7_CTL2  0x00000287
> -#define MSR_IA32_MC7_CTL  0x0000041C
> -#define MSR_IA32_MC7_STATUS  0x0000041D
> -#define MSR_IA32_MC7_ADDR  0x0000041E
> -#define MSR_IA32_MC7_MISC  0x0000041F
> -
> -#define MSR_IA32_MC8_CTL2  0x00000288
> -#define MSR_IA32_MC8_CTL  0x00000420
> -#define MSR_IA32_MC8_STATUS  0x00000421
> -#define MSR_IA32_MC8_ADDR  0x00000422
> -#define MSR_IA32_MC8_MISC  0x00000423
> -
>  #define MSR_IA32_MCx_CTL(x)  (MSR_IA32_MC0_CTL + 4*(x))
>  #define MSR_IA32_MCx_STATUS(x)  (MSR_IA32_MC0_STATUS + 4*(x))
>  #define MSR_IA32_MCx_ADDR(x)  (MSR_IA32_MC0_ADDR + 4*(x))
>  #define MSR_IA32_MCx_MISC(x)  (MSR_IA32_MC0_MISC + 4*(x))
> +#define MSR_IA32_MCx_CTL2(x)  (MSR_IA32_MC0_CTL2 + (x))
>  
>  #define MSR_AMD64_MCx_MASK(x)  (MSR_AMD64_MC0_MASK + (x))
>  
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 17:47:58 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 17: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.xensource.com>)
	id 1Ra9yX-0006Ia-RR; Mon, 12 Dec 2011 17:47:41 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1Ra9yW-0006H7-B5
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 17:47:40 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1323712006!1208850!1
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7067 invoked from network); 12 Dec 2011 17:46:46 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Dec 2011 17:46:46 -0000
Received: by wgbds11 with SMTP id ds11so10131380wgb.24
	for <xen-devel@lists.xensource.com>;
	Mon, 12 Dec 2011 09:46:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=QeEpkNMzYNfjj2+89a4CO+6oQlhtoN2pklt8RGrLfio=;
	b=hcxwOzsWSlDxaMPTDwZQjeoxKduVTweA6WePKqg3G2dpy6gMIh6g3PBeYx9N+pYmjQ
	rD+zRrD4T8OxbbIs8hyq0S6c43KLvHgW6J+HY04U4ic2AQYWsi8STocmJulvfB5QV+ll
	AxVm1EP0d+MH9AgIFomTIWWfKhzbGg/mSJrB0=
Received: by 10.227.208.134 with SMTP id gc6mr10496569wbb.3.1323712006622;
	Mon, 12 Dec 2011 09:46:46 -0800 (PST)
Received: from [192.168.1.3] (host81-152-17-11.range81-152.btcentralplus.com.
	[81.152.17.11])
	by mx.google.com with ESMTPS id ep13sm23891281wbb.8.2011.12.12.09.46.45
	(version=SSLv3 cipher=OTHER); Mon, 12 Dec 2011 09:46:46 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Mon, 12 Dec 2011 17:46:44 +0000
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Message-ID: <CB0BEE84.35B0D%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH] x86: remove redundant MCE related MSR
	definitions
Thread-Index: Acy49gMTDkngLfbrY02c0SROLgvi/g==
In-Reply-To: <4EE62D480200007800066FE7@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH] x86: remove redundant MCE related MSR
 definitions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 12/12/2011 15:35, "Jan Beulich" <JBeulich@suse.com> wrote:

> Two definitions (the first register and a macro to calculate the
> register for a given bank) are sufficient per kind of register.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Keir Fraser <keir@xen.org>

> --- 2011-11-23.orig/xen/arch/x86/cpu/mcheck/amd_nonfatal.c 2011-12-05
> 11:38:33.000000000 +0100
> +++ 2011-11-23/xen/arch/x86/cpu/mcheck/amd_nonfatal.c 2011-12-05
> 11:24:15.000000000 +0100
> @@ -144,7 +144,7 @@ static void mce_amd_work_fn(void *data)
> uint64_t value;
> uint32_t counter;
>  
> -  value = mca_rdmsr(MSR_IA32_MC4_MISC);
> +  value = mca_rdmsr(MSR_IA32_MCx_MISC(4));
> /* Only the error counter field is of interest
> * Bit field is described in AMD K8 BKDG chapter 6.4.5.5
> */
> @@ -174,7 +174,7 @@ static void mce_amd_work_fn(void *data)
> value &= ~(0x60FFF00000000ULL);
> /* Counter enable */
> value |= (1ULL << 51);
> -   mca_wrmsr(MSR_IA32_MC4_MISC, value);
> +   mca_wrmsr(MSR_IA32_MCx_MISC(4), value);
> wmb();
> }
> }
> @@ -217,7 +217,7 @@ void amd_nonfatal_mcheck_init(struct cpu
>  
> /* hw threshold registers present */
> hw_threshold = 1;
> -  rdmsrl(MSR_IA32_MC4_MISC, value);
> +  rdmsrl(MSR_IA32_MCx_MISC(4), value);
>  
> if (value & (1ULL << 61)) { /* Locked bit */
> /* Locked by BIOS. Not available for use */
> @@ -238,7 +238,7 @@ void amd_nonfatal_mcheck_init(struct cpu
> value &= ~(0x60FFF00000000ULL);
> /* Counter enable */
> value |= (1ULL << 51);
> -   wrmsrl(MSR_IA32_MC4_MISC, value);
> +   wrmsrl(MSR_IA32_MCx_MISC(4), value);
> /* serialize */
> wmb();
> printk(XENLOG_INFO "MCA: Use hw thresholding to adjust polling frequency\n");
> --- 2011-11-23.orig/xen/arch/x86/cpu/mcheck/mce_amd_quirks.c 2011-12-05
> 11:41:00.000000000 +0100
> +++ 2011-11-23/xen/arch/x86/cpu/mcheck/mce_amd_quirks.c 2011-12-05
> 11:42:03.000000000 +0100
> @@ -68,8 +68,8 @@ int mcequirk_amd_apply(enum mcequirk_amd
> * TBL walk error reporting, which trips off incorrectly
> * with AGP GART & 3ware & Cerberus.
> */
> -  wrmsrl(MSR_IA32_MC4_CTL, ~(1ULL << 10));
> -  wrmsrl(MSR_IA32_MC4_STATUS, 0ULL);
> +  wrmsrl(MSR_IA32_MCx_CTL(4), ~(1ULL << 10));
> +  wrmsrl(MSR_IA32_MCx_STATUS(4), 0ULL);
> break;
> case MCEQUIRK_F10_GART:
> if (rdmsr_safe(MSR_AMD64_MCx_MASK(4), val) == 0)
> --- 2011-11-23.orig/xen/arch/x86/cpu/mcheck/mce_intel.c 2011-12-05
> 11:38:33.000000000 +0100
> +++ 2011-11-23/xen/arch/x86/cpu/mcheck/mce_intel.c 2011-12-05
> 11:27:53.000000000 +0100
> @@ -986,7 +986,7 @@ static DEFINE_SPINLOCK(cmci_discover_loc
>   */
>  static int do_cmci_discover(int i)
>  {
> -    unsigned msr = MSR_IA32_MC0_CTL2 + i;
> +    unsigned msr = MSR_IA32_MCx_CTL2(i);
>      u64 val;
>  
>      rdmsrl(msr, val);
> @@ -1095,7 +1095,7 @@ static void clear_cmci(void)
>              smp_processor_id());
>  
>      for (i = 0; i < nr_mce_banks; i++) {
> -        unsigned msr = MSR_IA32_MC0_CTL2 + i;
> +        unsigned msr = MSR_IA32_MCx_CTL2(i);
>          u64 val;
>          if (!mcabanks_test(i, __get_cpu_var(mce_banks_owned)))
>              continue;
> --- 2011-11-23.orig/xen/arch/x86/hvm/svm/svm.c 2011-12-05 11:38:33.000000000
> +0100
> +++ 2011-11-23/xen/arch/x86/hvm/svm/svm.c 2011-12-05 11:25:55.000000000 +0100
> @@ -1318,7 +1318,7 @@ static int svm_msr_read_intercept(unsign
>          *msr_content = v->arch.hvm_svm.guest_sysenter_eip;
>          break;
>  
> -    case MSR_IA32_MC4_MISC: /* Threshold register */
> +    case MSR_IA32_MCx_MISC(4): /* Threshold register */
>      case MSR_F10_MC4_MISC1 ... MSR_F10_MC4_MISC3:
>          /*
>           * MCA/MCE: We report that the threshold register is unavailable
> @@ -1498,7 +1498,7 @@ static int svm_msr_write_intercept(unsig
>          vpmu_do_wrmsr(msr, msr_content);
>          break;
>  
> -    case MSR_IA32_MC4_MISC: /* Threshold register */
> +    case MSR_IA32_MCx_MISC(4): /* Threshold register */
>      case MSR_F10_MC4_MISC1 ... MSR_F10_MC4_MISC3:
>          /*
>           * MCA/MCE: Threshold register is reported to be locked, so we ignore
> --- 2011-11-23.orig/xen/include/asm-x86/msr-index.h 2011-12-05
> 11:06:39.000000000 +0100
> +++ 2011-11-23/xen/include/asm-x86/msr-index.h 2011-12-05 11:21:46.000000000
> +0100
> @@ -100,58 +100,11 @@
>  
>  #define MSR_AMD64_MC0_MASK  0xc0010044
>  
> -#define MSR_IA32_MC1_CTL  0x00000404
> -#define MSR_IA32_MC1_CTL2  0x00000281
> -#define MSR_IA32_MC1_STATUS  0x00000405
> -#define MSR_IA32_MC1_ADDR  0x00000406
> -#define MSR_IA32_MC1_MISC  0x00000407
> -
> -#define MSR_IA32_MC2_CTL  0x00000408
> -#define MSR_IA32_MC2_CTL2  0x00000282
> -#define MSR_IA32_MC2_STATUS  0x00000409
> -#define MSR_IA32_MC2_ADDR  0x0000040A
> -#define MSR_IA32_MC2_MISC  0x0000040B
> -
> -#define MSR_IA32_MC3_CTL2  0x00000283
> -#define MSR_IA32_MC3_CTL  0x0000040C
> -#define MSR_IA32_MC3_STATUS  0x0000040D
> -#define MSR_IA32_MC3_ADDR  0x0000040E
> -#define MSR_IA32_MC3_MISC  0x0000040F
> -
> -#define MSR_IA32_MC4_CTL2  0x00000284
> -#define MSR_IA32_MC4_CTL  0x00000410
> -#define MSR_IA32_MC4_STATUS  0x00000411
> -#define MSR_IA32_MC4_ADDR  0x00000412
> -#define MSR_IA32_MC4_MISC  0x00000413
> -
> -#define MSR_IA32_MC5_CTL2  0x00000285
> -#define MSR_IA32_MC5_CTL  0x00000414
> -#define MSR_IA32_MC5_STATUS  0x00000415
> -#define MSR_IA32_MC5_ADDR  0x00000416
> -#define MSR_IA32_MC5_MISC  0x00000417
> -
> -#define MSR_IA32_MC6_CTL2  0x00000286
> -#define MSR_IA32_MC6_CTL  0x00000418
> -#define MSR_IA32_MC6_STATUS  0x00000419
> -#define MSR_IA32_MC6_ADDR  0x0000041A
> -#define MSR_IA32_MC6_MISC  0x0000041B
> -
> -#define MSR_IA32_MC7_CTL2  0x00000287
> -#define MSR_IA32_MC7_CTL  0x0000041C
> -#define MSR_IA32_MC7_STATUS  0x0000041D
> -#define MSR_IA32_MC7_ADDR  0x0000041E
> -#define MSR_IA32_MC7_MISC  0x0000041F
> -
> -#define MSR_IA32_MC8_CTL2  0x00000288
> -#define MSR_IA32_MC8_CTL  0x00000420
> -#define MSR_IA32_MC8_STATUS  0x00000421
> -#define MSR_IA32_MC8_ADDR  0x00000422
> -#define MSR_IA32_MC8_MISC  0x00000423
> -
>  #define MSR_IA32_MCx_CTL(x)  (MSR_IA32_MC0_CTL + 4*(x))
>  #define MSR_IA32_MCx_STATUS(x)  (MSR_IA32_MC0_STATUS + 4*(x))
>  #define MSR_IA32_MCx_ADDR(x)  (MSR_IA32_MC0_ADDR + 4*(x))
>  #define MSR_IA32_MCx_MISC(x)  (MSR_IA32_MC0_MISC + 4*(x))
> +#define MSR_IA32_MCx_CTL2(x)  (MSR_IA32_MC0_CTL2 + (x))
>  
>  #define MSR_AMD64_MCx_MASK(x)  (MSR_AMD64_MC0_MASK + (x))
>  
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 17:49:11 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 17:49:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ra9zi-0006Xp-IT; Mon, 12 Dec 2011 17:48:54 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1Ra9zg-0006Wd-V4
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 17:48:53 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1323712079!1208917!1
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7875 invoked from network); 12 Dec 2011 17:47:59 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Dec 2011 17:47:59 -0000
Received: by wgbds11 with SMTP id ds11so10133064wgb.24
	for <xen-devel@lists.xensource.com>;
	Mon, 12 Dec 2011 09:47:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=tw8GU4/kGNuLdTlD0liMsrm4joDyLswYoPTIwnMkZUI=;
	b=CtHIw9e5Ozdc5luCfCg2DMFavP6eSAXFg3IqAxwcTk5f/oyMxEnCdjUstoiqyATxuz
	RpTtkEQR5cNRiiTbK049ZnKE37RrwmjWg2V9gNj77I/IkPI9qwGkqu3UQuialje5VRvz
	wH2H79+4X1VcWvp4aoxnWzufFzDhC/qWgRBEw=
Received: by 10.227.209.82 with SMTP id gf18mr14697120wbb.8.1323712079303;
	Mon, 12 Dec 2011 09:47:59 -0800 (PST)
Received: from [192.168.1.3] (host81-152-17-11.range81-152.btcentralplus.com.
	[81.152.17.11])
	by mx.google.com with ESMTPS id ff1sm23902403wbb.5.2011.12.12.09.47.56
	(version=SSLv3 cipher=OTHER); Mon, 12 Dec 2011 09:47:58 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Mon, 12 Dec 2011 17:47:57 +0000
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Message-ID: <CB0BEECD.35B0E%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH] remove the use of -Wno-unused-value
Thread-Index: Acy49i6W0kdGDe1aIkWhnJzrb6m51Q==
In-Reply-To: <4EE62F140200007800067003@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH] remove the use of -Wno-unused-value
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 12/12/2011 15:43, "Jan Beulich" <JBeulich@suse.com> wrote:

> It has been hiding actual mistakes, and there are not too many changes
> necessary to make things build without suppressing this warning.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Keir Fraser <keir@xen.org>

> --- 2011-12-12.orig/Config.mk 2011-12-12 15:46:14.000000000 +0100
> +++ 2011-12-12/Config.mk 2011-11-30 17:49:42.000000000 +0100
> @@ -157,10 +157,6 @@ CFLAGS += -std=gnu99
>  
>  CFLAGS += -Wall -Wstrict-prototypes
>  
> -# -Wunused-value makes GCC 4.x too aggressive for my taste: ignoring the
> -# result of any casted expression causes a warning.
> -CFLAGS += -Wno-unused-value
> -
>  # Clang complains about macros that expand to 'if ( ( foo == bar ) ) ...'
>  # and is over-zealous with the printf format lint
>  CFLAGS-$(clang) += -Wno-parentheses -Wno-format
> --- 2011-12-12.orig/tools/libfsimage/common/fsimage_grub.h 2010-04-19
> 09:12:58.000000000 +0200
> +++ 2011-12-12/tools/libfsimage/common/fsimage_grub.h 2011-12-12
> 15:47:35.000000000 +0100
> @@ -57,7 +57,7 @@ typedef struct fsig_plugin_ops {
>  #define disk_read_func (*fsig_disk_read_junk())
>  #define disk_read_hook (*fsig_disk_read_junk())
>  #define print_possibilities 0
> -#define noisy_printf
> +#define noisy_printf(fmt...)
>  
>  #define grub_memset memset
>  #define grub_memmove memmove
> --- 2011-12-12.orig/xen/arch/x86/debug.c 2011-12-12 15:46:14.000000000 +0100
> +++ 2011-12-12/xen/arch/x86/debug.c 2011-11-30 17:50:55.000000000 +0100
> @@ -37,8 +37,8 @@
>  #define DBGP1(...) {(kdbdbg>1) ? kdbp(__VA_ARGS__):0;}
>  #define DBGP2(...) {(kdbdbg>2) ? kdbp(__VA_ARGS__):0;}
>  #else
> -#define DBGP1(...) {0;}
> -#define DBGP2(...) {0;}
> +#define DBGP1(...) ((void)0)
> +#define DBGP2(...) ((void)0)
>  #endif
>  
>  /* Returns: mfn for the given (hvm guest) vaddr */
> --- 2011-12-12.orig/xen/arch/x86/hvm/svm/vpmu.c 2011-12-12 15:46:14.000000000
> +0100
> +++ 2011-12-12/xen/arch/x86/hvm/svm/vpmu.c 2011-12-01 11:35:58.000000000 +0100
> @@ -154,7 +154,7 @@ static int amd_vpmu_do_interrupt(struct
>      if ( GET_APIC_DELIVERY_MODE(vlapic_lvtpc) == APIC_MODE_FIXED )
>          vlapic_set_irq(vcpu_vlapic(v), int_vec, 0);
>      else
> -        test_and_set_bool(v->nmi_pending);
> +        v->nmi_pending = 1;
>  
>      return 1;
>  }
> --- 2011-12-12.orig/xen/arch/x86/hvm/vmx/vpmu_core2.c 2011-12-12
> 15:46:14.000000000 +0100
> +++ 2011-12-12/xen/arch/x86/hvm/vmx/vpmu_core2.c 2011-12-01 11:36:37.000000000
> +0100
> @@ -574,7 +574,7 @@ static int core2_vpmu_do_interrupt(struc
>      if ( GET_APIC_DELIVERY_MODE(vlapic_lvtpc) == APIC_MODE_FIXED )
>          vlapic_set_irq(vcpu_vlapic(v), int_vec, 0);
>      else
> -        test_and_set_bool(v->nmi_pending);
> +        v->nmi_pending = 1;
>      return 1;
>  }
>  
> --- 2011-12-12.orig/xen/arch/x86/oprofile/nmi_int.c 2011-12-12
> 15:46:14.000000000 +0100
> +++ 2011-12-12/xen/arch/x86/oprofile/nmi_int.c 2011-11-30 18:01:11.000000000
> +0100
> @@ -92,7 +92,7 @@ static int nmi_callback(struct cpu_user_
> send_guest_vcpu_virq(current, VIRQ_XENOPROF);
>  
> if ( ovf == 2 ) 
> -                test_and_set_bool(current->nmi_pending);
> +                current->nmi_pending = 1;
> return 1;
>  }
>   
> --- 2011-12-12.orig/xen/include/asm-x86/debugger.h 2011-12-12
> 15:46:14.000000000 +0100
> +++ 2011-12-12/xen/include/asm-x86/debugger.h 2011-11-30 17:58:20.000000000
> +0100
> @@ -55,7 +55,12 @@ static inline int debugger_trap_fatal(
>  
>  #else
>  
> -#define debugger_trap_fatal(v, r) (0)
> +static inline int debugger_trap_fatal(
> +    unsigned int vector, struct cpu_user_regs *regs)
> +{
> +    return 0;
> +}
> +
>  #define debugger_trap_immediate() ((void)0)
>  
>  #endif
> --- 2011-12-12.orig/xen/include/asm-x86/hvm/hvm.h 2011-12-12
> 15:46:14.000000000 +0100
> +++ 2011-12-12/xen/include/asm-x86/hvm/hvm.h 2011-12-01 12:15:02.000000000
> +0100
> @@ -235,7 +235,7 @@ int hvm_girq_dest_2_vcpu_id(struct domai
>  #define hvm_long_mode_enabled(v) \
>      ((v)->arch.hvm_vcpu.guest_efer & EFER_LMA)
>  #else
> -#define hvm_long_mode_enabled(v) (v,0)
> +#define hvm_long_mode_enabled(v) ((void)(v),0)
>  #endif
>  
>  enum hvm_intblk
> --- 2011-12-12.orig/xen/include/xen/tmem_xen.h 2011-12-12 15:46:14.000000000
> +0100
> +++ 2011-12-12/xen/include/xen/tmem_xen.h 2011-11-30 17:55:22.000000000 +0100
> @@ -365,7 +365,7 @@ static inline int tmh_page_cmp(pfp_t *pf
>      // FIXME: code in assembly?
>  ASSERT(p1 != NULL);
>  ASSERT(p2 != NULL);
> -    for ( i = PAGE_SIZE/sizeof(uint64_t); i && *p1 == *p2; i--, *p1++, *p2++
> );
> +    for ( i = PAGE_SIZE/sizeof(uint64_t); i && *p1 == *p2; i--, p1++, p2++ );
>      if ( !i )
>          return 0;
>      if ( *p1 < *p2 )
> @@ -386,7 +386,7 @@ static inline int tmh_pcd_cmp(void *va1,
>      if ( len1 > len2 )
>          return 1;
>      ASSERT(len1 == len2);
> -    for ( i = len2; i && *p1 == *p2; i--, *p1++, *p2++ );
> +    for ( i = len2; i && *p1 == *p2; i--, p1++, p2++ );
>      if ( !i )
>          return 0;
>      if ( *p1 < *p2 )
> @@ -413,7 +413,7 @@ static inline int tmh_tze_pfp_cmp(pfp_t
>      if ( pfp_len > tze_len )
>          return 1;
>      ASSERT(pfp_len == tze_len);
> -    for ( i = tze_len/sizeof(uint64_t); i && *p1 == *p2; i--, *p1++, *p2++ );
> +    for ( i = tze_len/sizeof(uint64_t); i && *p1 == *p2; i--, p1++, p2++ );
>      if ( !i )
>          return 0;
>      if ( *p1 < *p2 )
> --- 2011-12-12.orig/xen/include/xsm/xsm.h 2011-12-12 15:46:14.000000000 +0100
> +++ 2011-12-12/xen/include/xsm/xsm.h 2011-12-12 15:23:49.000000000 +0100
> @@ -163,7 +163,7 @@ extern struct xsm_operations *xsm_ops;
>  static inline void xsm_security_domaininfo (struct domain *d,
>                                          struct xen_domctl_getdomaininfo
> *info)
>  {
> -    xsm_call(security_domaininfo(d, info));
> +    (void)xsm_call(security_domaininfo(d, info));
>  }
>  
>  static inline int xsm_setvcpucontext(struct domain *d)
> @@ -310,7 +310,7 @@ static inline int xsm_evtchn_interdomain
>  
>  static inline void xsm_evtchn_close_post (struct evtchn *chn)
>  {
> -    xsm_call(evtchn_close_post(chn));
> +    (void)xsm_call(evtchn_close_post(chn));
>  }
>  
>  static inline int xsm_evtchn_send (struct domain *d, struct evtchn *chn)
> @@ -366,7 +366,7 @@ static inline int xsm_alloc_security_dom
>  
>  static inline void xsm_free_security_domain (struct domain *d)
>  {
> -    xsm_call(free_security_domain(d));
> +    (void)xsm_call(free_security_domain(d));
>  }
>  
>  static inline int xsm_alloc_security_evtchn (struct evtchn *chn)
> @@ -376,7 +376,7 @@ static inline int xsm_alloc_security_evt
>  
>  static inline void xsm_free_security_evtchn (struct evtchn *chn)
>  {
> -    xsm_call(free_security_evtchn(chn));
> +    (void)xsm_call(free_security_evtchn(chn));
>  }
>  
>  static inline int xsm_memory_adjust_reservation (struct domain *d1, struct
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 17:49:11 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 17:49:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ra9zi-0006Xp-IT; Mon, 12 Dec 2011 17:48:54 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1Ra9zg-0006Wd-V4
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 17:48:53 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1323712079!1208917!1
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7875 invoked from network); 12 Dec 2011 17:47:59 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Dec 2011 17:47:59 -0000
Received: by wgbds11 with SMTP id ds11so10133064wgb.24
	for <xen-devel@lists.xensource.com>;
	Mon, 12 Dec 2011 09:47:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=tw8GU4/kGNuLdTlD0liMsrm4joDyLswYoPTIwnMkZUI=;
	b=CtHIw9e5Ozdc5luCfCg2DMFavP6eSAXFg3IqAxwcTk5f/oyMxEnCdjUstoiqyATxuz
	RpTtkEQR5cNRiiTbK049ZnKE37RrwmjWg2V9gNj77I/IkPI9qwGkqu3UQuialje5VRvz
	wH2H79+4X1VcWvp4aoxnWzufFzDhC/qWgRBEw=
Received: by 10.227.209.82 with SMTP id gf18mr14697120wbb.8.1323712079303;
	Mon, 12 Dec 2011 09:47:59 -0800 (PST)
Received: from [192.168.1.3] (host81-152-17-11.range81-152.btcentralplus.com.
	[81.152.17.11])
	by mx.google.com with ESMTPS id ff1sm23902403wbb.5.2011.12.12.09.47.56
	(version=SSLv3 cipher=OTHER); Mon, 12 Dec 2011 09:47:58 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Mon, 12 Dec 2011 17:47:57 +0000
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Message-ID: <CB0BEECD.35B0E%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH] remove the use of -Wno-unused-value
Thread-Index: Acy49i6W0kdGDe1aIkWhnJzrb6m51Q==
In-Reply-To: <4EE62F140200007800067003@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH] remove the use of -Wno-unused-value
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 12/12/2011 15:43, "Jan Beulich" <JBeulich@suse.com> wrote:

> It has been hiding actual mistakes, and there are not too many changes
> necessary to make things build without suppressing this warning.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Keir Fraser <keir@xen.org>

> --- 2011-12-12.orig/Config.mk 2011-12-12 15:46:14.000000000 +0100
> +++ 2011-12-12/Config.mk 2011-11-30 17:49:42.000000000 +0100
> @@ -157,10 +157,6 @@ CFLAGS += -std=gnu99
>  
>  CFLAGS += -Wall -Wstrict-prototypes
>  
> -# -Wunused-value makes GCC 4.x too aggressive for my taste: ignoring the
> -# result of any casted expression causes a warning.
> -CFLAGS += -Wno-unused-value
> -
>  # Clang complains about macros that expand to 'if ( ( foo == bar ) ) ...'
>  # and is over-zealous with the printf format lint
>  CFLAGS-$(clang) += -Wno-parentheses -Wno-format
> --- 2011-12-12.orig/tools/libfsimage/common/fsimage_grub.h 2010-04-19
> 09:12:58.000000000 +0200
> +++ 2011-12-12/tools/libfsimage/common/fsimage_grub.h 2011-12-12
> 15:47:35.000000000 +0100
> @@ -57,7 +57,7 @@ typedef struct fsig_plugin_ops {
>  #define disk_read_func (*fsig_disk_read_junk())
>  #define disk_read_hook (*fsig_disk_read_junk())
>  #define print_possibilities 0
> -#define noisy_printf
> +#define noisy_printf(fmt...)
>  
>  #define grub_memset memset
>  #define grub_memmove memmove
> --- 2011-12-12.orig/xen/arch/x86/debug.c 2011-12-12 15:46:14.000000000 +0100
> +++ 2011-12-12/xen/arch/x86/debug.c 2011-11-30 17:50:55.000000000 +0100
> @@ -37,8 +37,8 @@
>  #define DBGP1(...) {(kdbdbg>1) ? kdbp(__VA_ARGS__):0;}
>  #define DBGP2(...) {(kdbdbg>2) ? kdbp(__VA_ARGS__):0;}
>  #else
> -#define DBGP1(...) {0;}
> -#define DBGP2(...) {0;}
> +#define DBGP1(...) ((void)0)
> +#define DBGP2(...) ((void)0)
>  #endif
>  
>  /* Returns: mfn for the given (hvm guest) vaddr */
> --- 2011-12-12.orig/xen/arch/x86/hvm/svm/vpmu.c 2011-12-12 15:46:14.000000000
> +0100
> +++ 2011-12-12/xen/arch/x86/hvm/svm/vpmu.c 2011-12-01 11:35:58.000000000 +0100
> @@ -154,7 +154,7 @@ static int amd_vpmu_do_interrupt(struct
>      if ( GET_APIC_DELIVERY_MODE(vlapic_lvtpc) == APIC_MODE_FIXED )
>          vlapic_set_irq(vcpu_vlapic(v), int_vec, 0);
>      else
> -        test_and_set_bool(v->nmi_pending);
> +        v->nmi_pending = 1;
>  
>      return 1;
>  }
> --- 2011-12-12.orig/xen/arch/x86/hvm/vmx/vpmu_core2.c 2011-12-12
> 15:46:14.000000000 +0100
> +++ 2011-12-12/xen/arch/x86/hvm/vmx/vpmu_core2.c 2011-12-01 11:36:37.000000000
> +0100
> @@ -574,7 +574,7 @@ static int core2_vpmu_do_interrupt(struc
>      if ( GET_APIC_DELIVERY_MODE(vlapic_lvtpc) == APIC_MODE_FIXED )
>          vlapic_set_irq(vcpu_vlapic(v), int_vec, 0);
>      else
> -        test_and_set_bool(v->nmi_pending);
> +        v->nmi_pending = 1;
>      return 1;
>  }
>  
> --- 2011-12-12.orig/xen/arch/x86/oprofile/nmi_int.c 2011-12-12
> 15:46:14.000000000 +0100
> +++ 2011-12-12/xen/arch/x86/oprofile/nmi_int.c 2011-11-30 18:01:11.000000000
> +0100
> @@ -92,7 +92,7 @@ static int nmi_callback(struct cpu_user_
> send_guest_vcpu_virq(current, VIRQ_XENOPROF);
>  
> if ( ovf == 2 ) 
> -                test_and_set_bool(current->nmi_pending);
> +                current->nmi_pending = 1;
> return 1;
>  }
>   
> --- 2011-12-12.orig/xen/include/asm-x86/debugger.h 2011-12-12
> 15:46:14.000000000 +0100
> +++ 2011-12-12/xen/include/asm-x86/debugger.h 2011-11-30 17:58:20.000000000
> +0100
> @@ -55,7 +55,12 @@ static inline int debugger_trap_fatal(
>  
>  #else
>  
> -#define debugger_trap_fatal(v, r) (0)
> +static inline int debugger_trap_fatal(
> +    unsigned int vector, struct cpu_user_regs *regs)
> +{
> +    return 0;
> +}
> +
>  #define debugger_trap_immediate() ((void)0)
>  
>  #endif
> --- 2011-12-12.orig/xen/include/asm-x86/hvm/hvm.h 2011-12-12
> 15:46:14.000000000 +0100
> +++ 2011-12-12/xen/include/asm-x86/hvm/hvm.h 2011-12-01 12:15:02.000000000
> +0100
> @@ -235,7 +235,7 @@ int hvm_girq_dest_2_vcpu_id(struct domai
>  #define hvm_long_mode_enabled(v) \
>      ((v)->arch.hvm_vcpu.guest_efer & EFER_LMA)
>  #else
> -#define hvm_long_mode_enabled(v) (v,0)
> +#define hvm_long_mode_enabled(v) ((void)(v),0)
>  #endif
>  
>  enum hvm_intblk
> --- 2011-12-12.orig/xen/include/xen/tmem_xen.h 2011-12-12 15:46:14.000000000
> +0100
> +++ 2011-12-12/xen/include/xen/tmem_xen.h 2011-11-30 17:55:22.000000000 +0100
> @@ -365,7 +365,7 @@ static inline int tmh_page_cmp(pfp_t *pf
>      // FIXME: code in assembly?
>  ASSERT(p1 != NULL);
>  ASSERT(p2 != NULL);
> -    for ( i = PAGE_SIZE/sizeof(uint64_t); i && *p1 == *p2; i--, *p1++, *p2++
> );
> +    for ( i = PAGE_SIZE/sizeof(uint64_t); i && *p1 == *p2; i--, p1++, p2++ );
>      if ( !i )
>          return 0;
>      if ( *p1 < *p2 )
> @@ -386,7 +386,7 @@ static inline int tmh_pcd_cmp(void *va1,
>      if ( len1 > len2 )
>          return 1;
>      ASSERT(len1 == len2);
> -    for ( i = len2; i && *p1 == *p2; i--, *p1++, *p2++ );
> +    for ( i = len2; i && *p1 == *p2; i--, p1++, p2++ );
>      if ( !i )
>          return 0;
>      if ( *p1 < *p2 )
> @@ -413,7 +413,7 @@ static inline int tmh_tze_pfp_cmp(pfp_t
>      if ( pfp_len > tze_len )
>          return 1;
>      ASSERT(pfp_len == tze_len);
> -    for ( i = tze_len/sizeof(uint64_t); i && *p1 == *p2; i--, *p1++, *p2++ );
> +    for ( i = tze_len/sizeof(uint64_t); i && *p1 == *p2; i--, p1++, p2++ );
>      if ( !i )
>          return 0;
>      if ( *p1 < *p2 )
> --- 2011-12-12.orig/xen/include/xsm/xsm.h 2011-12-12 15:46:14.000000000 +0100
> +++ 2011-12-12/xen/include/xsm/xsm.h 2011-12-12 15:23:49.000000000 +0100
> @@ -163,7 +163,7 @@ extern struct xsm_operations *xsm_ops;
>  static inline void xsm_security_domaininfo (struct domain *d,
>                                          struct xen_domctl_getdomaininfo
> *info)
>  {
> -    xsm_call(security_domaininfo(d, info));
> +    (void)xsm_call(security_domaininfo(d, info));
>  }
>  
>  static inline int xsm_setvcpucontext(struct domain *d)
> @@ -310,7 +310,7 @@ static inline int xsm_evtchn_interdomain
>  
>  static inline void xsm_evtchn_close_post (struct evtchn *chn)
>  {
> -    xsm_call(evtchn_close_post(chn));
> +    (void)xsm_call(evtchn_close_post(chn));
>  }
>  
>  static inline int xsm_evtchn_send (struct domain *d, struct evtchn *chn)
> @@ -366,7 +366,7 @@ static inline int xsm_alloc_security_dom
>  
>  static inline void xsm_free_security_domain (struct domain *d)
>  {
> -    xsm_call(free_security_domain(d));
> +    (void)xsm_call(free_security_domain(d));
>  }
>  
>  static inline int xsm_alloc_security_evtchn (struct evtchn *chn)
> @@ -376,7 +376,7 @@ static inline int xsm_alloc_security_evt
>  
>  static inline void xsm_free_security_evtchn (struct evtchn *chn)
>  {
> -    xsm_call(free_security_evtchn(chn));
> +    (void)xsm_call(free_security_evtchn(chn));
>  }
>  
>  static inline int xsm_memory_adjust_reservation (struct domain *d1, struct
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 17:49:33 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 17:49:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaA06-0006d5-VS; Mon, 12 Dec 2011 17:49:18 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RaA06-0006bt-5x
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 17:49:18 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1323712104!7113450!1
X-Originating-IP: [74.125.82.41]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2997 invoked from network); 12 Dec 2011 17:48:25 -0000
Received: from mail-ww0-f41.google.com (HELO mail-ww0-f41.google.com)
	(74.125.82.41)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Dec 2011 17:48:25 -0000
Received: by wgbdt12 with SMTP id dt12so9739680wgb.0
	for <xen-devel@lists.xensource.com>;
	Mon, 12 Dec 2011 09:48:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=u1L4kkEvvDOU7Tc5oE74ZxwX5Tn/CoFoaoqUK+lFvSI=;
	b=j9jH8vUB4dpP79mp3qncC6LPljpiRIPUAtY4hEerJgBqpbxCZiVb+RLwVb89JvnAS6
	PWBSbpnOn0aoPZtnvONehBhShkVM4UaSUJmKroQxcq1GKqbK8Wr7B8eFhGI7oy+57Fo9
	NYYe+8aq4+R44AmiqzdbaimcTjv/5P8d9k8Xg=
Received: by 10.216.133.29 with SMTP id p29mr2491544wei.70.1323712104885;
	Mon, 12 Dec 2011 09:48:24 -0800 (PST)
Received: from [192.168.1.3] (host81-152-17-11.range81-152.btcentralplus.com.
	[81.152.17.11])
	by mx.google.com with ESMTPS id ei9sm19497763wid.0.2011.12.12.09.48.23
	(version=SSLv3 cipher=OTHER); Mon, 12 Dec 2011 09:48:24 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Mon, 12 Dec 2011 17:48:24 +0000
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Message-ID: <CB0BEEE8.35B0F%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH 0/4] ACPI: update firmware interface headers
Thread-Index: Acy49j6uFdAyvRC4kk2t4mgeb8C6Rw==
In-Reply-To: <4EE635220200007800067047@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH 0/4] ACPI: update firmware interface headers
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 12/12/2011 16:08, "Jan Beulich" <JBeulich@suse.com> wrote:

> This set of patches eliminates bogus duplicate structure definitions,
> which accumulated in a couple of places where they don't belong. To
> facilitate this, the interface headers get updated to what is being used
> on Linux 3.1 (also 3.2-rc), with two or three minor adjustments.
> 
> 1: eliminate duplicate MADT parsing and unused SBF definitions
> 2: update table interface headers
> 3: eliminate duplicate DMAR definitions
> 4: eliminate duplicate IVRS definitions
> 
> Original and new code were verified to produce identical code, with
> the sole exception of places where e.g. bitfield were used in the
> stray structure definitions, and full width fields with manifest constant
> masks get used now.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Keir Fraser <keir@xen.org>

> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 17:49:33 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 17:49:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaA06-0006d5-VS; Mon, 12 Dec 2011 17:49:18 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RaA06-0006bt-5x
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 17:49:18 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1323712104!7113450!1
X-Originating-IP: [74.125.82.41]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2997 invoked from network); 12 Dec 2011 17:48:25 -0000
Received: from mail-ww0-f41.google.com (HELO mail-ww0-f41.google.com)
	(74.125.82.41)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Dec 2011 17:48:25 -0000
Received: by wgbdt12 with SMTP id dt12so9739680wgb.0
	for <xen-devel@lists.xensource.com>;
	Mon, 12 Dec 2011 09:48:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=u1L4kkEvvDOU7Tc5oE74ZxwX5Tn/CoFoaoqUK+lFvSI=;
	b=j9jH8vUB4dpP79mp3qncC6LPljpiRIPUAtY4hEerJgBqpbxCZiVb+RLwVb89JvnAS6
	PWBSbpnOn0aoPZtnvONehBhShkVM4UaSUJmKroQxcq1GKqbK8Wr7B8eFhGI7oy+57Fo9
	NYYe+8aq4+R44AmiqzdbaimcTjv/5P8d9k8Xg=
Received: by 10.216.133.29 with SMTP id p29mr2491544wei.70.1323712104885;
	Mon, 12 Dec 2011 09:48:24 -0800 (PST)
Received: from [192.168.1.3] (host81-152-17-11.range81-152.btcentralplus.com.
	[81.152.17.11])
	by mx.google.com with ESMTPS id ei9sm19497763wid.0.2011.12.12.09.48.23
	(version=SSLv3 cipher=OTHER); Mon, 12 Dec 2011 09:48:24 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Mon, 12 Dec 2011 17:48:24 +0000
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Message-ID: <CB0BEEE8.35B0F%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH 0/4] ACPI: update firmware interface headers
Thread-Index: Acy49j6uFdAyvRC4kk2t4mgeb8C6Rw==
In-Reply-To: <4EE635220200007800067047@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH 0/4] ACPI: update firmware interface headers
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 12/12/2011 16:08, "Jan Beulich" <JBeulich@suse.com> wrote:

> This set of patches eliminates bogus duplicate structure definitions,
> which accumulated in a couple of places where they don't belong. To
> facilitate this, the interface headers get updated to what is being used
> on Linux 3.1 (also 3.2-rc), with two or three minor adjustments.
> 
> 1: eliminate duplicate MADT parsing and unused SBF definitions
> 2: update table interface headers
> 3: eliminate duplicate DMAR definitions
> 4: eliminate duplicate IVRS definitions
> 
> Original and new code were verified to produce identical code, with
> the sole exception of places where e.g. bitfield were used in the
> stray structure definitions, and full width fields with manifest constant
> masks get used now.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Keir Fraser <keir@xen.org>

> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 17:50:46 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 17:50:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaA1L-0006rp-FL; Mon, 12 Dec 2011 17:50:35 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RaA1J-0006rT-Qu
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 17:50:34 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1323712146!46397590!1
X-Originating-IP: [209.85.161.43]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28239 invoked from network); 12 Dec 2011 17:49:06 -0000
Received: from mail-fx0-f43.google.com (HELO mail-fx0-f43.google.com)
	(209.85.161.43)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Dec 2011 17:49:06 -0000
Received: by faap21 with SMTP id p21so636765faa.30
	for <xen-devel@lists.xensource.com>;
	Mon, 12 Dec 2011 09:49:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=/4Jfoqvh/al20g8guyizuXRbXfVdQG91CrVJlCUJKcs=;
	b=TjZbkWJe6aTM/Ovuipbii5MLYr/CaVlR+76H0vdJYf2yyQQGWyC3ndcqRpRAvKakvJ
	QRMH96KshRUcIliGWdO9plK1hW0ctO1utyGz8j/HlkJo6tykj8KbHMOw8F6faLK/c0NN
	GK0GXzy2X3gp0+2Du43hV3kj0+lpxVCfWHKL8=
Received: by 10.180.105.131 with SMTP id gm3mr23126301wib.50.1323712185094;
	Mon, 12 Dec 2011 09:49:45 -0800 (PST)
Received: from [192.168.1.3] (host81-152-17-11.range81-152.btcentralplus.com.
	[81.152.17.11])
	by mx.google.com with ESMTPS id er5sm19226114wbb.11.2011.12.12.09.49.43
	(version=SSLv3 cipher=OTHER); Mon, 12 Dec 2011 09:49:44 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Mon, 12 Dec 2011 17:49:44 +0000
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Message-ID: <CB0BEF38.35B10%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH] x86, amd: Disable GartTlbWlkErr when BIOS
	forgets it
Thread-Index: Acy49m5d6zgbwj+DrUWOamY8Woaj/Q==
In-Reply-To: <4EE62B040200007800066FB6@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: Joerg Roedel <joerg.roedel@amd.com>
Subject: Re: [Xen-devel] [PATCH] x86,
 amd: Disable GartTlbWlkErr when BIOS forgets it
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 12/12/2011 15:25, "Jan Beulich" <JBeulich@suse.com> wrote:

> This patch disables GartTlbWlk errors on AMD Fam10h CPUs if the BIOS
> forgets to do is (or is just too old). Letting these errors enabled
> can cause a sync-flood on the CPU causing a reboot.
> 
> The AMD BKDG recommends disabling GART TLB Wlk Error completely.
> 
> Based on a Linux patch from Joerg Roedel <joerg.roedel@amd.com>; see e.g.
> https://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=patch;h=5bbc09
> 7d890409d8eff4e3f1d26f11a9d6b7c07e
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Keir Fraser <keir@xen.org>

> --- 2011-11-23.orig/xen/arch/x86/cpu/mcheck/amd_f10.c 2011-12-05
> 11:38:34.000000000 +0100
> +++ 2011-11-23/xen/arch/x86/cpu/mcheck/amd_f10.c 2011-12-05 11:17:03.000000000
> +0100
> @@ -46,6 +46,7 @@
>  #include <asm/msr.h>
>  
>  #include "mce.h"
> +#include "mce_quirks.h"
>  #include "x86_mca.h"
>  
>  
> @@ -91,9 +92,14 @@ amd_f10_handler(struct mc_info *mi, uint
>  /* AMD Family10 machine check */
>  enum mcheck_type amd_f10_mcheck_init(struct cpuinfo_x86 *c)
>  { 
> + enum mcequirk_amd_flags quirkflag = mcequirk_lookup_amd_quirkdata(c);
> +
> if (amd_k8_mcheck_init(c) == mcheck_none)
> return mcheck_none;
>  
> + if (quirkflag == MCEQUIRK_F10_GART)
> +  mcequirk_amd_apply(quirkflag);
> +
> x86_mce_callback_register(amd_f10_handler);
>  
> return mcheck_amd_famXX;
> --- 2011-11-23.orig/xen/arch/x86/cpu/mcheck/mce_amd_quirks.c 2011-12-05
> 11:38:34.000000000 +0100
> +++ 2011-11-23/xen/arch/x86/cpu/mcheck/mce_amd_quirks.c 2011-12-05
> 11:41:00.000000000 +0100
> @@ -29,6 +29,8 @@ static const struct mce_quirkdata mce_am
>  MCEQUIRK_K7_BANK0 },
> { 0xf /* cpu family */, ANY /* all models */, ANY /* all steppings */,
>  MCEQUIRK_K8_GART },
> + { 0x10 /* cpu family */, ANY /* all models */, ANY /* all steppings */,
> +   MCEQUIRK_F10_GART },
>  };
>  
>  enum mcequirk_amd_flags
> @@ -54,6 +56,8 @@ mcequirk_lookup_amd_quirkdata(struct cpu
>  
>  int mcequirk_amd_apply(enum mcequirk_amd_flags flags)
>  {
> + u64 val;
> +
> switch (flags) {
> case MCEQUIRK_K7_BANK0:
> return 1; /* first bank */
> @@ -67,6 +71,10 @@ int mcequirk_amd_apply(enum mcequirk_amd
> wrmsrl(MSR_IA32_MC4_CTL, ~(1ULL << 10));
> wrmsrl(MSR_IA32_MC4_STATUS, 0ULL);
> break;
> + case MCEQUIRK_F10_GART:
> +  if (rdmsr_safe(MSR_AMD64_MCx_MASK(4), val) == 0)
> +   wrmsr_safe(MSR_AMD64_MCx_MASK(4), val | (1 << 10));
> +  break;
> }
>  
> return 0;
> --- 2011-11-23.orig/xen/arch/x86/cpu/mcheck/mce_quirks.h 2011-12-05
> 11:38:34.000000000 +0100
> +++ 2011-11-23/xen/arch/x86/cpu/mcheck/mce_quirks.h 2011-12-05
> 11:11:45.000000000 +0100
> @@ -33,8 +33,9 @@ struct mce_quirkdata {
>   */
>  
>  enum mcequirk_amd_flags {
> - MCEQUIRK_K7_BANK0 = 0x1,
> - MCEQUIRK_K8_GART = 0x2,
> + MCEQUIRK_K7_BANK0 = 1,
> + MCEQUIRK_K8_GART,
> + MCEQUIRK_F10_GART
>  };
>  
>  enum mcequirk_intel_flags {
> --- 2011-11-23.orig/xen/include/asm-x86/msr-index.h 2011-12-05
> 11:38:34.000000000 +0100
> +++ 2011-11-23/xen/include/asm-x86/msr-index.h 2011-12-05 11:06:39.000000000
> +0100
> @@ -98,6 +98,8 @@
>  #define CMCI_EN    (1UL<<30)
>  #define CMCI_THRESHOLD_MASK  0x7FFF
>  
> +#define MSR_AMD64_MC0_MASK  0xc0010044
> +
>  #define MSR_IA32_MC1_CTL  0x00000404
>  #define MSR_IA32_MC1_CTL2  0x00000281
>  #define MSR_IA32_MC1_STATUS  0x00000405
> @@ -151,6 +153,8 @@
>  #define MSR_IA32_MCx_ADDR(x)  (MSR_IA32_MC0_ADDR + 4*(x))
>  #define MSR_IA32_MCx_MISC(x)  (MSR_IA32_MC0_MISC + 4*(x))
>  
> +#define MSR_AMD64_MCx_MASK(x)  (MSR_AMD64_MC0_MASK + (x))
> +
>  #define MSR_P6_PERFCTR0   0x000000c1
>  #define MSR_P6_PERFCTR1   0x000000c2
>  #define MSR_P6_EVNTSEL0   0x00000186
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 17:50:46 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 17:50:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaA1L-0006rp-FL; Mon, 12 Dec 2011 17:50:35 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RaA1J-0006rT-Qu
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 17:50:34 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1323712146!46397590!1
X-Originating-IP: [209.85.161.43]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28239 invoked from network); 12 Dec 2011 17:49:06 -0000
Received: from mail-fx0-f43.google.com (HELO mail-fx0-f43.google.com)
	(209.85.161.43)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Dec 2011 17:49:06 -0000
Received: by faap21 with SMTP id p21so636765faa.30
	for <xen-devel@lists.xensource.com>;
	Mon, 12 Dec 2011 09:49:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=/4Jfoqvh/al20g8guyizuXRbXfVdQG91CrVJlCUJKcs=;
	b=TjZbkWJe6aTM/Ovuipbii5MLYr/CaVlR+76H0vdJYf2yyQQGWyC3ndcqRpRAvKakvJ
	QRMH96KshRUcIliGWdO9plK1hW0ctO1utyGz8j/HlkJo6tykj8KbHMOw8F6faLK/c0NN
	GK0GXzy2X3gp0+2Du43hV3kj0+lpxVCfWHKL8=
Received: by 10.180.105.131 with SMTP id gm3mr23126301wib.50.1323712185094;
	Mon, 12 Dec 2011 09:49:45 -0800 (PST)
Received: from [192.168.1.3] (host81-152-17-11.range81-152.btcentralplus.com.
	[81.152.17.11])
	by mx.google.com with ESMTPS id er5sm19226114wbb.11.2011.12.12.09.49.43
	(version=SSLv3 cipher=OTHER); Mon, 12 Dec 2011 09:49:44 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Mon, 12 Dec 2011 17:49:44 +0000
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Message-ID: <CB0BEF38.35B10%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH] x86, amd: Disable GartTlbWlkErr when BIOS
	forgets it
Thread-Index: Acy49m5d6zgbwj+DrUWOamY8Woaj/Q==
In-Reply-To: <4EE62B040200007800066FB6@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: Joerg Roedel <joerg.roedel@amd.com>
Subject: Re: [Xen-devel] [PATCH] x86,
 amd: Disable GartTlbWlkErr when BIOS forgets it
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 12/12/2011 15:25, "Jan Beulich" <JBeulich@suse.com> wrote:

> This patch disables GartTlbWlk errors on AMD Fam10h CPUs if the BIOS
> forgets to do is (or is just too old). Letting these errors enabled
> can cause a sync-flood on the CPU causing a reboot.
> 
> The AMD BKDG recommends disabling GART TLB Wlk Error completely.
> 
> Based on a Linux patch from Joerg Roedel <joerg.roedel@amd.com>; see e.g.
> https://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=patch;h=5bbc09
> 7d890409d8eff4e3f1d26f11a9d6b7c07e
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Keir Fraser <keir@xen.org>

> --- 2011-11-23.orig/xen/arch/x86/cpu/mcheck/amd_f10.c 2011-12-05
> 11:38:34.000000000 +0100
> +++ 2011-11-23/xen/arch/x86/cpu/mcheck/amd_f10.c 2011-12-05 11:17:03.000000000
> +0100
> @@ -46,6 +46,7 @@
>  #include <asm/msr.h>
>  
>  #include "mce.h"
> +#include "mce_quirks.h"
>  #include "x86_mca.h"
>  
>  
> @@ -91,9 +92,14 @@ amd_f10_handler(struct mc_info *mi, uint
>  /* AMD Family10 machine check */
>  enum mcheck_type amd_f10_mcheck_init(struct cpuinfo_x86 *c)
>  { 
> + enum mcequirk_amd_flags quirkflag = mcequirk_lookup_amd_quirkdata(c);
> +
> if (amd_k8_mcheck_init(c) == mcheck_none)
> return mcheck_none;
>  
> + if (quirkflag == MCEQUIRK_F10_GART)
> +  mcequirk_amd_apply(quirkflag);
> +
> x86_mce_callback_register(amd_f10_handler);
>  
> return mcheck_amd_famXX;
> --- 2011-11-23.orig/xen/arch/x86/cpu/mcheck/mce_amd_quirks.c 2011-12-05
> 11:38:34.000000000 +0100
> +++ 2011-11-23/xen/arch/x86/cpu/mcheck/mce_amd_quirks.c 2011-12-05
> 11:41:00.000000000 +0100
> @@ -29,6 +29,8 @@ static const struct mce_quirkdata mce_am
>  MCEQUIRK_K7_BANK0 },
> { 0xf /* cpu family */, ANY /* all models */, ANY /* all steppings */,
>  MCEQUIRK_K8_GART },
> + { 0x10 /* cpu family */, ANY /* all models */, ANY /* all steppings */,
> +   MCEQUIRK_F10_GART },
>  };
>  
>  enum mcequirk_amd_flags
> @@ -54,6 +56,8 @@ mcequirk_lookup_amd_quirkdata(struct cpu
>  
>  int mcequirk_amd_apply(enum mcequirk_amd_flags flags)
>  {
> + u64 val;
> +
> switch (flags) {
> case MCEQUIRK_K7_BANK0:
> return 1; /* first bank */
> @@ -67,6 +71,10 @@ int mcequirk_amd_apply(enum mcequirk_amd
> wrmsrl(MSR_IA32_MC4_CTL, ~(1ULL << 10));
> wrmsrl(MSR_IA32_MC4_STATUS, 0ULL);
> break;
> + case MCEQUIRK_F10_GART:
> +  if (rdmsr_safe(MSR_AMD64_MCx_MASK(4), val) == 0)
> +   wrmsr_safe(MSR_AMD64_MCx_MASK(4), val | (1 << 10));
> +  break;
> }
>  
> return 0;
> --- 2011-11-23.orig/xen/arch/x86/cpu/mcheck/mce_quirks.h 2011-12-05
> 11:38:34.000000000 +0100
> +++ 2011-11-23/xen/arch/x86/cpu/mcheck/mce_quirks.h 2011-12-05
> 11:11:45.000000000 +0100
> @@ -33,8 +33,9 @@ struct mce_quirkdata {
>   */
>  
>  enum mcequirk_amd_flags {
> - MCEQUIRK_K7_BANK0 = 0x1,
> - MCEQUIRK_K8_GART = 0x2,
> + MCEQUIRK_K7_BANK0 = 1,
> + MCEQUIRK_K8_GART,
> + MCEQUIRK_F10_GART
>  };
>  
>  enum mcequirk_intel_flags {
> --- 2011-11-23.orig/xen/include/asm-x86/msr-index.h 2011-12-05
> 11:38:34.000000000 +0100
> +++ 2011-11-23/xen/include/asm-x86/msr-index.h 2011-12-05 11:06:39.000000000
> +0100
> @@ -98,6 +98,8 @@
>  #define CMCI_EN    (1UL<<30)
>  #define CMCI_THRESHOLD_MASK  0x7FFF
>  
> +#define MSR_AMD64_MC0_MASK  0xc0010044
> +
>  #define MSR_IA32_MC1_CTL  0x00000404
>  #define MSR_IA32_MC1_CTL2  0x00000281
>  #define MSR_IA32_MC1_STATUS  0x00000405
> @@ -151,6 +153,8 @@
>  #define MSR_IA32_MCx_ADDR(x)  (MSR_IA32_MC0_ADDR + 4*(x))
>  #define MSR_IA32_MCx_MISC(x)  (MSR_IA32_MC0_MISC + 4*(x))
>  
> +#define MSR_AMD64_MCx_MASK(x)  (MSR_AMD64_MC0_MASK + (x))
> +
>  #define MSR_P6_PERFCTR0   0x000000c1
>  #define MSR_P6_PERFCTR1   0x000000c2
>  #define MSR_P6_EVNTSEL0   0x00000186
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 17:51:57 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 17: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.xensource.com>)
	id 1RaA2T-00075N-Uu; Mon, 12 Dec 2011 17:51:45 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RaA2S-00074U-Jx
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 17:51:44 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1323712251!6590515!1
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=2.3 required=7.0 tests=RCVD_BY_IP,SUBJECT_RANDOMQ
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13682 invoked from network); 12 Dec 2011 17:50:51 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Dec 2011 17:50:51 -0000
Received: by wgbds11 with SMTP id ds11so10136673wgb.24
	for <xen-devel@lists.xensource.com>;
	Mon, 12 Dec 2011 09:50:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=xHC4VGBlX7Ub4ff4A3eUAz1CqXWzaWmwVq4MiEi+pkw=;
	b=XSJm5ZVNnoV8CHreLWUU85mDpo+wqjWs/J+8AZoFJ2xuqEEbv/3YPFSfuMcp7M1w0k
	Qw6WvqqZn6TeYALXI6IpyfGG/2Ylj0iUd4KSlndBDX5hzN03EVXbrqR1ngLqZtSnaiOC
	nNTq53nb3kU1Yz0BiZS7bJogPz6Ii/Vp2O83E=
Received: by 10.216.171.144 with SMTP id r16mr985369wel.63.1323712249403;
	Mon, 12 Dec 2011 09:50:49 -0800 (PST)
Received: from [192.168.1.3] (host81-152-17-11.range81-152.btcentralplus.com.
	[81.152.17.11]) by mx.google.com with ESMTPS id
	hb10sm26642205wib.16.2011.12.12.09.50.48
	(version=SSLv3 cipher=OTHER); Mon, 12 Dec 2011 09:50:48 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Mon, 12 Dec 2011 17:50:48 +0000
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Message-ID: <CB0BEF78.35B12%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH] VT-d: bind IRQs to CPUs local to the node
	the IOMMU is on
Thread-Index: Acy49pSDxa2SNv4IJEKEgKgiXgGtCA==
In-Reply-To: <4EE631A2020000780006701F@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: Allen M Kay <allen.m.kay@intel.com>
Subject: Re: [Xen-devel] [PATCH] VT-d: bind IRQs to CPUs local to the node
 the IOMMU is on
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 12/12/2011 15:53, "Jan Beulich" <JBeulich@suse.com> wrote:

> This extends create_irq() to take a node parameter, allowing the
> resulting IRQ to have its destination set to a CPU on that node right
> away, which is more natural than having to post-adjust this (and
> get e.g. a new IRQ vector assigned despite a fresh one was just
> obtained).
> 
> All other callers of create_irq() pass NUMA_NO_NODE for the time being.

I don't know about this one. Does the current 'inefficient' way things work
really matter?

 -- Keir

> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> --- 2011-12-12.orig/xen/arch/x86/hpet.c 2011-11-11 09:40:55.000000000 +0100
> +++ 2011-12-12/xen/arch/x86/hpet.c 2011-12-06 16:36:24.000000000 +0100
> @@ -11,6 +11,7 @@
>  #include <xen/smp.h>
>  #include <xen/softirq.h>
>  #include <xen/irq.h>
> +#include <xen/numa.h>
>  #include <asm/fixmap.h>
>  #include <asm/div64.h>
>  #include <asm/hpet.h>
> @@ -334,7 +335,7 @@ static int __init hpet_assign_irq(unsign
>  {
>      int irq;
>  
> -    if ( (irq = create_irq()) < 0 )
> +    if ( (irq = create_irq(NUMA_NO_NODE)) < 0 )
>          return irq;
>  
>      if ( hpet_setup_msi_irq(irq, hpet_events + idx) )
> --- 2011-12-12.orig/xen/arch/x86/io_apic.c 2011-11-22 10:57:09.000000000 +0100
> +++ 2011-12-12/xen/arch/x86/io_apic.c 2011-12-12 15:24:10.000000000 +0100
> @@ -995,7 +995,7 @@ static void __init setup_IO_APIC_irqs(vo
>                  continue;
>  
>              if (IO_APIC_IRQ(irq)) {
> -                vector = assign_irq_vector(irq);
> +                vector = assign_irq_vector(irq, NULL);
>                  BUG_ON(vector < 0);
>                  entry.vector = vector;
>                  ioapic_register_intr(irq, IOAPIC_AUTO);
> @@ -2188,7 +2188,7 @@ int io_apic_set_pci_routing (int ioapic,
>      if (!platform_legacy_irq(irq))
>          add_pin_to_irq(irq, ioapic, pin);
>  
> -    vector = assign_irq_vector(irq);
> +    vector = assign_irq_vector(irq, NULL);
>      if (vector < 0)
>          return vector;
>      entry.vector = vector;
> @@ -2340,7 +2340,7 @@ int ioapic_guest_write(unsigned long phy
>  
>      if ( desc->arch.vector <= 0 || desc->arch.vector > LAST_DYNAMIC_VECTOR )
> {
>          add_pin_to_irq(irq, apic, pin);
> -        vector = assign_irq_vector(irq);
> +        vector = assign_irq_vector(irq, NULL);
>          if ( vector < 0 )
>              return vector;
>  
> --- 2011-12-12.orig/xen/arch/x86/irq.c 2011-12-12 09:01:34.000000000 +0100
> +++ 2011-12-12/xen/arch/x86/irq.c 2011-12-12 15:24:15.000000000 +0100
> @@ -151,7 +151,7 @@ int __init bind_irq_vector(int irq, int
>  /*
>   * Dynamic irq allocate and deallocation for MSI
>   */
> -int create_irq(void)
> +int create_irq(int node)
>  {
>      int irq, ret;
>      struct irq_desc *desc;
> @@ -168,7 +168,17 @@ int create_irq(void)
>  
>      ret = init_one_irq_desc(desc);
>      if (!ret)
> -        ret = assign_irq_vector(irq);
> +    {
> +        cpumask_t *mask = NULL;
> +
> +        if (node != NUMA_NO_NODE && node >= 0)
> +        {
> +            mask = &node_to_cpumask(node);
> +            if (cpumask_empty(mask))
> +                mask = NULL;
> +        }
> +        ret = assign_irq_vector(irq, mask);
> +    }
>      if (ret < 0)
>      {
>          desc->arch.used = IRQ_UNUSED;
> @@ -514,7 +524,7 @@ next:
>      return err;
>  }
>  
> -int assign_irq_vector(int irq)
> +int assign_irq_vector(int irq, const cpumask_t *mask)
>  {
>      int ret;
>      unsigned long flags;
> @@ -523,7 +533,7 @@ int assign_irq_vector(int irq)
>      BUG_ON(irq >= nr_irqs || irq <0);
>  
>      spin_lock_irqsave(&vector_lock, flags);
> -    ret = __assign_irq_vector(irq, desc, TARGET_CPUS);
> +    ret = __assign_irq_vector(irq, desc, mask ?: TARGET_CPUS);
>      if (!ret) {
>          ret = desc->arch.vector;
>          cpumask_copy(desc->affinity, desc->arch.cpu_mask);
> --- 2011-12-12.orig/xen/arch/x86/physdev.c 2011-12-12 09:01:34.000000000 +0100
> +++ 2011-12-12/xen/arch/x86/physdev.c 2011-12-06 16:28:10.000000000 +0100
> @@ -132,7 +132,7 @@ int physdev_map_pirq(domid_t domid, int
>      case MAP_PIRQ_TYPE_MSI:
>          irq = *index;
>          if ( irq == -1 )
> -            irq = create_irq();
> +            irq = create_irq(NUMA_NO_NODE);
>  
>          if ( irq < 0 || irq >= nr_irqs )
>          {
> --- 2011-12-12.orig/xen/drivers/passthrough/amd/iommu_init.c 2011-11-29
> 09:19:05.000000000 +0100
> +++ 2011-12-12/xen/drivers/passthrough/amd/iommu_init.c 2011-12-06
> 16:27:49.000000000 +0100
> @@ -551,7 +551,7 @@ static int __init set_iommu_interrupt_ha
>  {
>      int irq, ret;
>  
> -    irq = create_irq();
> +    irq = create_irq(NUMA_NO_NODE);
>      if ( irq <= 0 )
>      {
>          dprintk(XENLOG_ERR, "IOMMU: no irqs\n");
> --- 2011-12-12.orig/xen/drivers/passthrough/vtd/iommu.c 2011-11-22
> 10:57:10.000000000 +0100
> +++ 2011-12-12/xen/drivers/passthrough/vtd/iommu.c 2011-12-06
> 16:35:42.000000000 +0100
> @@ -1096,11 +1096,13 @@ static hw_irq_controller dma_msi_type =
>      .set_affinity = dma_msi_set_affinity,
>  };
>  
> -static int __init iommu_set_interrupt(struct iommu *iommu)
> +static int __init iommu_set_interrupt(struct acpi_drhd_unit *drhd)
>  {
>      int irq, ret;
> +    struct acpi_rhsa_unit *rhsa = drhd_to_rhsa(drhd);
>  
> -    irq = create_irq();
> +    irq = create_irq(rhsa ? pxm_to_node(rhsa->proximity_domain)
> +                          : NUMA_NO_NODE);
>      if ( irq <= 0 )
>      {
>          dprintk(XENLOG_ERR VTDPREFIX, "IOMMU: no irq available!\n");
> @@ -1109,9 +1111,9 @@ static int __init iommu_set_interrupt(st
>  
>      irq_desc[irq].handler = &dma_msi_type;
>  #ifdef CONFIG_X86
> -    ret = request_irq(irq, iommu_page_fault, 0, "dmar", iommu);
> +    ret = request_irq(irq, iommu_page_fault, 0, "dmar", drhd->iommu);
>  #else
> -    ret = request_irq_vector(irq, iommu_page_fault, 0, "dmar", iommu);
> +    ret = request_irq_vector(irq, iommu_page_fault, 0, "dmar", drhd->iommu);
>  #endif
>      if ( ret )
>      {
> @@ -2133,7 +2135,7 @@ int __init intel_vtd_setup(void)
>          if ( !vtd_ept_page_compatible(iommu) )
>              iommu_hap_pt_share = 0;
>  
> -        ret = iommu_set_interrupt(iommu);
> +        ret = iommu_set_interrupt(drhd);
>          if ( ret < 0 )
>          {
>              dprintk(XENLOG_ERR VTDPREFIX, "IOMMU: interrupt setup failed\n");
> --- 2011-12-12.orig/xen/include/asm-x86/io_apic.h 2011-10-04
> 08:22:17.000000000 +0200
> +++ 2011-12-12/xen/include/asm-x86/io_apic.h 2011-12-06 16:24:22.000000000
> +0100
> @@ -213,9 +213,6 @@ static inline void ioapic_suspend(void)
>  static inline void ioapic_resume(void) {}
>  #endif
>  
> -extern int assign_irq_vector(int irq);
> -extern int free_irq_vector(int vector);
> -
>  unsigned highest_gsi(void);
>  
>  int ioapic_guest_read( unsigned long physbase, unsigned int reg, u32 *pval);
> --- 2011-12-12.orig/xen/include/asm-x86/irq.h 2011-11-22 10:57:10.000000000
> +0100
> +++ 2011-12-12/xen/include/asm-x86/irq.h 2011-12-06 16:25:22.000000000 +0100
> @@ -155,8 +155,9 @@ int  init_irq_data(void);
>  void clear_irq_vector(int irq);
>  
>  int irq_to_vector(int irq);
> -int create_irq(void);
> +int create_irq(int node);
>  void destroy_irq(unsigned int irq);
> +int assign_irq_vector(int irq, const cpumask_t *);
>  
>  extern void irq_complete_move(struct irq_desc *);
>  
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 17:51:57 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 17: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.xensource.com>)
	id 1RaA2T-00075N-Uu; Mon, 12 Dec 2011 17:51:45 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RaA2S-00074U-Jx
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 17:51:44 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1323712251!6590515!1
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=2.3 required=7.0 tests=RCVD_BY_IP,SUBJECT_RANDOMQ
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13682 invoked from network); 12 Dec 2011 17:50:51 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Dec 2011 17:50:51 -0000
Received: by wgbds11 with SMTP id ds11so10136673wgb.24
	for <xen-devel@lists.xensource.com>;
	Mon, 12 Dec 2011 09:50:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=xHC4VGBlX7Ub4ff4A3eUAz1CqXWzaWmwVq4MiEi+pkw=;
	b=XSJm5ZVNnoV8CHreLWUU85mDpo+wqjWs/J+8AZoFJ2xuqEEbv/3YPFSfuMcp7M1w0k
	Qw6WvqqZn6TeYALXI6IpyfGG/2Ylj0iUd4KSlndBDX5hzN03EVXbrqR1ngLqZtSnaiOC
	nNTq53nb3kU1Yz0BiZS7bJogPz6Ii/Vp2O83E=
Received: by 10.216.171.144 with SMTP id r16mr985369wel.63.1323712249403;
	Mon, 12 Dec 2011 09:50:49 -0800 (PST)
Received: from [192.168.1.3] (host81-152-17-11.range81-152.btcentralplus.com.
	[81.152.17.11]) by mx.google.com with ESMTPS id
	hb10sm26642205wib.16.2011.12.12.09.50.48
	(version=SSLv3 cipher=OTHER); Mon, 12 Dec 2011 09:50:48 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Mon, 12 Dec 2011 17:50:48 +0000
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Message-ID: <CB0BEF78.35B12%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH] VT-d: bind IRQs to CPUs local to the node
	the IOMMU is on
Thread-Index: Acy49pSDxa2SNv4IJEKEgKgiXgGtCA==
In-Reply-To: <4EE631A2020000780006701F@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: Allen M Kay <allen.m.kay@intel.com>
Subject: Re: [Xen-devel] [PATCH] VT-d: bind IRQs to CPUs local to the node
 the IOMMU is on
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 12/12/2011 15:53, "Jan Beulich" <JBeulich@suse.com> wrote:

> This extends create_irq() to take a node parameter, allowing the
> resulting IRQ to have its destination set to a CPU on that node right
> away, which is more natural than having to post-adjust this (and
> get e.g. a new IRQ vector assigned despite a fresh one was just
> obtained).
> 
> All other callers of create_irq() pass NUMA_NO_NODE for the time being.

I don't know about this one. Does the current 'inefficient' way things work
really matter?

 -- Keir

> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> --- 2011-12-12.orig/xen/arch/x86/hpet.c 2011-11-11 09:40:55.000000000 +0100
> +++ 2011-12-12/xen/arch/x86/hpet.c 2011-12-06 16:36:24.000000000 +0100
> @@ -11,6 +11,7 @@
>  #include <xen/smp.h>
>  #include <xen/softirq.h>
>  #include <xen/irq.h>
> +#include <xen/numa.h>
>  #include <asm/fixmap.h>
>  #include <asm/div64.h>
>  #include <asm/hpet.h>
> @@ -334,7 +335,7 @@ static int __init hpet_assign_irq(unsign
>  {
>      int irq;
>  
> -    if ( (irq = create_irq()) < 0 )
> +    if ( (irq = create_irq(NUMA_NO_NODE)) < 0 )
>          return irq;
>  
>      if ( hpet_setup_msi_irq(irq, hpet_events + idx) )
> --- 2011-12-12.orig/xen/arch/x86/io_apic.c 2011-11-22 10:57:09.000000000 +0100
> +++ 2011-12-12/xen/arch/x86/io_apic.c 2011-12-12 15:24:10.000000000 +0100
> @@ -995,7 +995,7 @@ static void __init setup_IO_APIC_irqs(vo
>                  continue;
>  
>              if (IO_APIC_IRQ(irq)) {
> -                vector = assign_irq_vector(irq);
> +                vector = assign_irq_vector(irq, NULL);
>                  BUG_ON(vector < 0);
>                  entry.vector = vector;
>                  ioapic_register_intr(irq, IOAPIC_AUTO);
> @@ -2188,7 +2188,7 @@ int io_apic_set_pci_routing (int ioapic,
>      if (!platform_legacy_irq(irq))
>          add_pin_to_irq(irq, ioapic, pin);
>  
> -    vector = assign_irq_vector(irq);
> +    vector = assign_irq_vector(irq, NULL);
>      if (vector < 0)
>          return vector;
>      entry.vector = vector;
> @@ -2340,7 +2340,7 @@ int ioapic_guest_write(unsigned long phy
>  
>      if ( desc->arch.vector <= 0 || desc->arch.vector > LAST_DYNAMIC_VECTOR )
> {
>          add_pin_to_irq(irq, apic, pin);
> -        vector = assign_irq_vector(irq);
> +        vector = assign_irq_vector(irq, NULL);
>          if ( vector < 0 )
>              return vector;
>  
> --- 2011-12-12.orig/xen/arch/x86/irq.c 2011-12-12 09:01:34.000000000 +0100
> +++ 2011-12-12/xen/arch/x86/irq.c 2011-12-12 15:24:15.000000000 +0100
> @@ -151,7 +151,7 @@ int __init bind_irq_vector(int irq, int
>  /*
>   * Dynamic irq allocate and deallocation for MSI
>   */
> -int create_irq(void)
> +int create_irq(int node)
>  {
>      int irq, ret;
>      struct irq_desc *desc;
> @@ -168,7 +168,17 @@ int create_irq(void)
>  
>      ret = init_one_irq_desc(desc);
>      if (!ret)
> -        ret = assign_irq_vector(irq);
> +    {
> +        cpumask_t *mask = NULL;
> +
> +        if (node != NUMA_NO_NODE && node >= 0)
> +        {
> +            mask = &node_to_cpumask(node);
> +            if (cpumask_empty(mask))
> +                mask = NULL;
> +        }
> +        ret = assign_irq_vector(irq, mask);
> +    }
>      if (ret < 0)
>      {
>          desc->arch.used = IRQ_UNUSED;
> @@ -514,7 +524,7 @@ next:
>      return err;
>  }
>  
> -int assign_irq_vector(int irq)
> +int assign_irq_vector(int irq, const cpumask_t *mask)
>  {
>      int ret;
>      unsigned long flags;
> @@ -523,7 +533,7 @@ int assign_irq_vector(int irq)
>      BUG_ON(irq >= nr_irqs || irq <0);
>  
>      spin_lock_irqsave(&vector_lock, flags);
> -    ret = __assign_irq_vector(irq, desc, TARGET_CPUS);
> +    ret = __assign_irq_vector(irq, desc, mask ?: TARGET_CPUS);
>      if (!ret) {
>          ret = desc->arch.vector;
>          cpumask_copy(desc->affinity, desc->arch.cpu_mask);
> --- 2011-12-12.orig/xen/arch/x86/physdev.c 2011-12-12 09:01:34.000000000 +0100
> +++ 2011-12-12/xen/arch/x86/physdev.c 2011-12-06 16:28:10.000000000 +0100
> @@ -132,7 +132,7 @@ int physdev_map_pirq(domid_t domid, int
>      case MAP_PIRQ_TYPE_MSI:
>          irq = *index;
>          if ( irq == -1 )
> -            irq = create_irq();
> +            irq = create_irq(NUMA_NO_NODE);
>  
>          if ( irq < 0 || irq >= nr_irqs )
>          {
> --- 2011-12-12.orig/xen/drivers/passthrough/amd/iommu_init.c 2011-11-29
> 09:19:05.000000000 +0100
> +++ 2011-12-12/xen/drivers/passthrough/amd/iommu_init.c 2011-12-06
> 16:27:49.000000000 +0100
> @@ -551,7 +551,7 @@ static int __init set_iommu_interrupt_ha
>  {
>      int irq, ret;
>  
> -    irq = create_irq();
> +    irq = create_irq(NUMA_NO_NODE);
>      if ( irq <= 0 )
>      {
>          dprintk(XENLOG_ERR, "IOMMU: no irqs\n");
> --- 2011-12-12.orig/xen/drivers/passthrough/vtd/iommu.c 2011-11-22
> 10:57:10.000000000 +0100
> +++ 2011-12-12/xen/drivers/passthrough/vtd/iommu.c 2011-12-06
> 16:35:42.000000000 +0100
> @@ -1096,11 +1096,13 @@ static hw_irq_controller dma_msi_type =
>      .set_affinity = dma_msi_set_affinity,
>  };
>  
> -static int __init iommu_set_interrupt(struct iommu *iommu)
> +static int __init iommu_set_interrupt(struct acpi_drhd_unit *drhd)
>  {
>      int irq, ret;
> +    struct acpi_rhsa_unit *rhsa = drhd_to_rhsa(drhd);
>  
> -    irq = create_irq();
> +    irq = create_irq(rhsa ? pxm_to_node(rhsa->proximity_domain)
> +                          : NUMA_NO_NODE);
>      if ( irq <= 0 )
>      {
>          dprintk(XENLOG_ERR VTDPREFIX, "IOMMU: no irq available!\n");
> @@ -1109,9 +1111,9 @@ static int __init iommu_set_interrupt(st
>  
>      irq_desc[irq].handler = &dma_msi_type;
>  #ifdef CONFIG_X86
> -    ret = request_irq(irq, iommu_page_fault, 0, "dmar", iommu);
> +    ret = request_irq(irq, iommu_page_fault, 0, "dmar", drhd->iommu);
>  #else
> -    ret = request_irq_vector(irq, iommu_page_fault, 0, "dmar", iommu);
> +    ret = request_irq_vector(irq, iommu_page_fault, 0, "dmar", drhd->iommu);
>  #endif
>      if ( ret )
>      {
> @@ -2133,7 +2135,7 @@ int __init intel_vtd_setup(void)
>          if ( !vtd_ept_page_compatible(iommu) )
>              iommu_hap_pt_share = 0;
>  
> -        ret = iommu_set_interrupt(iommu);
> +        ret = iommu_set_interrupt(drhd);
>          if ( ret < 0 )
>          {
>              dprintk(XENLOG_ERR VTDPREFIX, "IOMMU: interrupt setup failed\n");
> --- 2011-12-12.orig/xen/include/asm-x86/io_apic.h 2011-10-04
> 08:22:17.000000000 +0200
> +++ 2011-12-12/xen/include/asm-x86/io_apic.h 2011-12-06 16:24:22.000000000
> +0100
> @@ -213,9 +213,6 @@ static inline void ioapic_suspend(void)
>  static inline void ioapic_resume(void) {}
>  #endif
>  
> -extern int assign_irq_vector(int irq);
> -extern int free_irq_vector(int vector);
> -
>  unsigned highest_gsi(void);
>  
>  int ioapic_guest_read( unsigned long physbase, unsigned int reg, u32 *pval);
> --- 2011-12-12.orig/xen/include/asm-x86/irq.h 2011-11-22 10:57:10.000000000
> +0100
> +++ 2011-12-12/xen/include/asm-x86/irq.h 2011-12-06 16:25:22.000000000 +0100
> @@ -155,8 +155,9 @@ int  init_irq_data(void);
>  void clear_irq_vector(int irq);
>  
>  int irq_to_vector(int irq);
> -int create_irq(void);
> +int create_irq(int node);
>  void destroy_irq(unsigned int irq);
> +int assign_irq_vector(int irq, const cpumask_t *);
>  
>  extern void irq_complete_move(struct irq_desc *);
>  
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 17:58:37 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 17:58:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaA8x-0007XY-0V; Mon, 12 Dec 2011 17:58:27 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RaA8v-0007XT-O7
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 17:58:25 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1323712652!7170782!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDc4NQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7006 invoked from network); 12 Dec 2011 17:57:32 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Dec 2011 17:57:32 -0000
X-IronPort-AV: E=Sophos;i="4.71,340,1320624000"; 
   d="scan'208";a="9425143"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Dec 2011 17:57:32 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 12 Dec 2011 17:57:32 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RaA84-0000Mh-7p	for xen-devel@lists.xensource.com;
	Mon, 12 Dec 2011 17:57:32 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RaA84-0001XI-69	for
	xen-devel@lists.xensource.com; Mon, 12 Dec 2011 17:57:32 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20198.16523.822596.527870@mariner.uk.xensource.com>
Date: Mon, 12 Dec 2011 17:57:31 +0000
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
In-Reply-To: <1323456877-15315-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1323456877-15315-1-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Subject: Re: [Xen-devel] [PATCH v5 00/18] New event API
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Jackson writes ("[PATCH v5 00/18] New event API"):
> Yet another version of my event handling API series I'm afraid.  This
> addresses all comments so far.
> 
> Many of the earlier parts of the series have been acked and are
> reposted for completeness.  Hopefully we will be able to apply these
> early parts 01-13 soon:
>     01/18 libxl: Make libxl__xs_* more const-correct
>     02/18 libxenstore: Provide xs_check_watch
>     03/18 libxl: Provide a version of bsd's queue.h as _libxl_list.h
>     04/18 libxl: idl: support new "private" type attribute
>     05/18 libxl: idl: Provide struct and union tags
>     06/18 libxl: permit declaration after statement
>     07/18 libxl: internal convenience macros
>     08/18 libxl: Rationalise #includes
>     09/18 libxl: introduce lock in libxl_ctx
>     10/18 libxl: make libxl__[v]log const-correct
>     11/18 libxl: make libxl__free_all idempotent
>   * 12/18 libxl: libxl_ctx_free should free the ctx
>     13/18 libxl: Use GC_INIT and GC_FREE everywhere
> Of these 12/18 is new but I think obviously correct.  After that's
> acked, and test passes and patch backlog permitting, I intend to apply
> those.

I have applied 01-13, the uncontroversial preamble, all of which had
been acked.  Hopefully this will reduce the overhang (and reduce the
patchbombs too...)

I'm aware there are other tools patches outstanding too.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 17:58:37 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 17:58:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaA8x-0007XY-0V; Mon, 12 Dec 2011 17:58:27 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RaA8v-0007XT-O7
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 17:58:25 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1323712652!7170782!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDc4NQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7006 invoked from network); 12 Dec 2011 17:57:32 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Dec 2011 17:57:32 -0000
X-IronPort-AV: E=Sophos;i="4.71,340,1320624000"; 
   d="scan'208";a="9425143"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Dec 2011 17:57:32 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 12 Dec 2011 17:57:32 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RaA84-0000Mh-7p	for xen-devel@lists.xensource.com;
	Mon, 12 Dec 2011 17:57:32 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RaA84-0001XI-69	for
	xen-devel@lists.xensource.com; Mon, 12 Dec 2011 17:57:32 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20198.16523.822596.527870@mariner.uk.xensource.com>
Date: Mon, 12 Dec 2011 17:57:31 +0000
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
In-Reply-To: <1323456877-15315-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1323456877-15315-1-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Subject: Re: [Xen-devel] [PATCH v5 00/18] New event API
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Jackson writes ("[PATCH v5 00/18] New event API"):
> Yet another version of my event handling API series I'm afraid.  This
> addresses all comments so far.
> 
> Many of the earlier parts of the series have been acked and are
> reposted for completeness.  Hopefully we will be able to apply these
> early parts 01-13 soon:
>     01/18 libxl: Make libxl__xs_* more const-correct
>     02/18 libxenstore: Provide xs_check_watch
>     03/18 libxl: Provide a version of bsd's queue.h as _libxl_list.h
>     04/18 libxl: idl: support new "private" type attribute
>     05/18 libxl: idl: Provide struct and union tags
>     06/18 libxl: permit declaration after statement
>     07/18 libxl: internal convenience macros
>     08/18 libxl: Rationalise #includes
>     09/18 libxl: introduce lock in libxl_ctx
>     10/18 libxl: make libxl__[v]log const-correct
>     11/18 libxl: make libxl__free_all idempotent
>   * 12/18 libxl: libxl_ctx_free should free the ctx
>     13/18 libxl: Use GC_INIT and GC_FREE everywhere
> Of these 12/18 is new but I think obviously correct.  After that's
> acked, and test passes and patch backlog permitting, I intend to apply
> those.

I have applied 01-13, the uncontroversial preamble, all of which had
been acked.  Hopefully this will reduce the overhang (and reduce the
patchbombs too...)

I'm aware there are other tools patches outstanding too.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 18:01:48 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 18:01:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaAC1-0007l5-53; Mon, 12 Dec 2011 18:01:37 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RaABz-0007ky-II
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 18:01:35 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1323712737!55839677!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDc4NQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5891 invoked from network); 12 Dec 2011 17:58:58 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Dec 2011 17:58:58 -0000
X-IronPort-AV: E=Sophos;i="4.71,340,1320624000"; 
   d="scan'208";a="9425176"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Dec 2011 18:00:47 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 12 Dec 2011 18:00:47 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RaABC-0000Nq-UV; Mon, 12 Dec 2011 18:00:46 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RaABC-0001YA-Rz;
	Mon, 12 Dec 2011 18:00:46 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20198.16718.834204.605028@mariner.uk.xensource.com>
Date: Mon, 12 Dec 2011 18:00:46 +0000
To: <xen-devel@lists.xensource.com>
X-Mailer: VM 7.19 under Emacs 21.4.1
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>, Keir Fraser <keir@xen.org>
Subject: [Xen-devel] [PATCH] flask: add tools/flask/utils/flask-label-pci to
	.hgignore
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

I have just committed the patch below.

Ian.

# HG changeset patch
# User Ian Jackson <Ian.Jackson@eu.citrix.com>
# Date 1323712783 0
# Node ID 7ca56cca09ade16645fb4806be2c5b2b0bc3332b
# Parent  7e90178b8bbfd2f78e8f4c6d593a2fb233350f41
flask: add tools/flask/utils/flask-label-pci to .hgignore

This was apparently forgotten in 24353:448c48326d6b

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

diff -r 7e90178b8bbf -r c995cdcc3700 .hgignore
--- a/.hgignore	Mon Dec 12 17:48:42 2011 +0000
+++ b/.hgignore	Mon Dec 12 17:58:25 2011 +0000
@@ -157,6 +157,7 @@
 ^tools/flask/utils/flask-getenforce$
 ^tools/flask/utils/flask-loadpolicy$
 ^tools/flask/utils/flask-setenforce$
+^tools/flask/utils/flask-label-pci$
 ^tools/fs-back/fs-backend$
 ^tools/hotplug/common/hotplugpath\.sh$
 ^tools/include/xen/.*$

diff -r 7e90178b8bbf -r 7ca56cca09ad .hgignore
--- a/.hgignore	Mon Dec 12 17:48:42 2011 +0000
+++ b/.hgignore	Mon Dec 12 17:59:43 2011 +0000
@@ -157,6 +157,7 @@
 ^tools/flask/utils/flask-getenforce$
 ^tools/flask/utils/flask-loadpolicy$
 ^tools/flask/utils/flask-setenforce$
+^tools/flask/utils/flask-label-pci$
 ^tools/fs-back/fs-backend$
 ^tools/hotplug/common/hotplugpath\.sh$
 ^tools/include/xen/.*$

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 18:01:48 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 18:01:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaAC1-0007l5-53; Mon, 12 Dec 2011 18:01:37 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RaABz-0007ky-II
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 18:01:35 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1323712737!55839677!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDc4NQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5891 invoked from network); 12 Dec 2011 17:58:58 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Dec 2011 17:58:58 -0000
X-IronPort-AV: E=Sophos;i="4.71,340,1320624000"; 
   d="scan'208";a="9425176"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Dec 2011 18:00:47 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 12 Dec 2011 18:00:47 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RaABC-0000Nq-UV; Mon, 12 Dec 2011 18:00:46 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RaABC-0001YA-Rz;
	Mon, 12 Dec 2011 18:00:46 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20198.16718.834204.605028@mariner.uk.xensource.com>
Date: Mon, 12 Dec 2011 18:00:46 +0000
To: <xen-devel@lists.xensource.com>
X-Mailer: VM 7.19 under Emacs 21.4.1
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>, Keir Fraser <keir@xen.org>
Subject: [Xen-devel] [PATCH] flask: add tools/flask/utils/flask-label-pci to
	.hgignore
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

I have just committed the patch below.

Ian.

# HG changeset patch
# User Ian Jackson <Ian.Jackson@eu.citrix.com>
# Date 1323712783 0
# Node ID 7ca56cca09ade16645fb4806be2c5b2b0bc3332b
# Parent  7e90178b8bbfd2f78e8f4c6d593a2fb233350f41
flask: add tools/flask/utils/flask-label-pci to .hgignore

This was apparently forgotten in 24353:448c48326d6b

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

diff -r 7e90178b8bbf -r c995cdcc3700 .hgignore
--- a/.hgignore	Mon Dec 12 17:48:42 2011 +0000
+++ b/.hgignore	Mon Dec 12 17:58:25 2011 +0000
@@ -157,6 +157,7 @@
 ^tools/flask/utils/flask-getenforce$
 ^tools/flask/utils/flask-loadpolicy$
 ^tools/flask/utils/flask-setenforce$
+^tools/flask/utils/flask-label-pci$
 ^tools/fs-back/fs-backend$
 ^tools/hotplug/common/hotplugpath\.sh$
 ^tools/include/xen/.*$

diff -r 7e90178b8bbf -r 7ca56cca09ad .hgignore
--- a/.hgignore	Mon Dec 12 17:48:42 2011 +0000
+++ b/.hgignore	Mon Dec 12 17:59:43 2011 +0000
@@ -157,6 +157,7 @@
 ^tools/flask/utils/flask-getenforce$
 ^tools/flask/utils/flask-loadpolicy$
 ^tools/flask/utils/flask-setenforce$
+^tools/flask/utils/flask-label-pci$
 ^tools/fs-back/fs-backend$
 ^tools/hotplug/common/hotplugpath\.sh$
 ^tools/include/xen/.*$

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 18:04:55 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 18:04:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaAF0-0007xU-Oe; Mon, 12 Dec 2011 18:04:42 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RaAEy-0007x7-Or
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 18:04:40 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1323713027!6941837!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDc4NQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16698 invoked from network); 12 Dec 2011 18:03:47 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Dec 2011 18:03:47 -0000
X-IronPort-AV: E=Sophos;i="4.71,340,1320624000"; 
   d="scan'208";a="9425221"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Dec 2011 18:03:47 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 12 Dec 2011 18:03:47 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RaAE6-0000Ol-Re; Mon, 12 Dec 2011 18:03:46 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RaAE6-0001Ya-Qd;
	Mon, 12 Dec 2011 18:03:46 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20198.16898.814613.705263@mariner.uk.xensource.com>
Date: Mon, 12 Dec 2011 18:03:46 +0000
To: Roger Pau Monne <roger.pau@entel.upc.edu>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <patchbomb.1322752087@loki.upc.es>
References: <patchbomb.1322752087@loki.upc.es>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 00 of 11 v3] libxl: add support for hotplug
 script calling from libxl
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Roger Pau Monne writes ("[Xen-devel] [PATCH 00 of 11 v3] libxl: add support for hotplug script calling from libxl"):
> This patch series adds support for hotplug script calling directly
> from libxl, instead of relying on xenbackendd. Also some patches
> contain general bug fixes.

FYI this has now got to the top of my list.  I hope to give it some
serious review time tomorrow.  In the meantime, if you have any final
tweaks, feel free to send an updated version.

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 18:04:55 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 18:04:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaAF0-0007xU-Oe; Mon, 12 Dec 2011 18:04:42 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RaAEy-0007x7-Or
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 18:04:40 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1323713027!6941837!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDc4NQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16698 invoked from network); 12 Dec 2011 18:03:47 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Dec 2011 18:03:47 -0000
X-IronPort-AV: E=Sophos;i="4.71,340,1320624000"; 
   d="scan'208";a="9425221"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Dec 2011 18:03:47 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 12 Dec 2011 18:03:47 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RaAE6-0000Ol-Re; Mon, 12 Dec 2011 18:03:46 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RaAE6-0001Ya-Qd;
	Mon, 12 Dec 2011 18:03:46 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20198.16898.814613.705263@mariner.uk.xensource.com>
Date: Mon, 12 Dec 2011 18:03:46 +0000
To: Roger Pau Monne <roger.pau@entel.upc.edu>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <patchbomb.1322752087@loki.upc.es>
References: <patchbomb.1322752087@loki.upc.es>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 00 of 11 v3] libxl: add support for hotplug
 script calling from libxl
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Roger Pau Monne writes ("[Xen-devel] [PATCH 00 of 11 v3] libxl: add support for hotplug script calling from libxl"):
> This patch series adds support for hotplug script calling directly
> from libxl, instead of relying on xenbackendd. Also some patches
> contain general bug fixes.

FYI this has now got to the top of my list.  I hope to give it some
serious review time tomorrow.  In the meantime, if you have any final
tweaks, feel free to send an updated version.

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 18:08:14 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 18:08:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaAIC-0008Dn-F1; Mon, 12 Dec 2011 18:08:00 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RaAIA-0008Dc-Tn
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 18:07:59 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1323713209!58621706!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDc4NQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26718 invoked from network); 12 Dec 2011 18:06:49 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Dec 2011 18:06:49 -0000
X-IronPort-AV: E=Sophos;i="4.71,340,1320624000"; 
   d="scan'208";a="9425267"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Dec 2011 18:07:07 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 12 Dec 2011 18:07:07 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RaAHL-0000Q1-5m;
	Mon, 12 Dec 2011 18:07:07 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RaAHI-0003sZ-Pk;
	Mon, 12 Dec 2011 18:07:07 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10476-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 12 Dec 2011 18:07:04 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10476: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10476 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10476/

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-amd64-xl-sedf-pin 14 guest-localmigrate/x10    fail REGR. vs. 10474

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-credit2   12 guest-saverestore.2         fail pass in 10475
 test-amd64-amd64-xl-sedf      5 xen-boot                    fail pass in 10475

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-i386-i386-xl-winxpsp3    7 windows-install              fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install          fail never pass
 test-amd64-i386-xl-win7-amd64  7 windows-install              fail  never pass
 test-amd64-i386-xend-winxpsp3  7 windows-install              fail  never pass
 test-amd64-amd64-xl-win7-amd64  7 windows-install              fail never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-sedf    14 guest-localmigrate/x10 fail in 10475 like 10474

version targeted for testing:
 xen                  f1ab2c2138d8
baseline version:
 xen                  1c58bb664d8d

------------------------------------------------------------
People who touched revisions under test:
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   24373:f1ab2c2138d8
tag:         tip
user:        Jan Beulich <jbeulich@suse.com>
date:        Mon Dec 12 10:47:26 2011 +0100
    
    x86/Intel: quiesce revised CPUID level message
    
    Print this only once, for the boot CPU, unless "cpuinfo" was specified.
    I found this particularly annoying on a machine which also didn't have
    it MTRRs consistently set up across cores, resulting in the printing of
    those messages being awfully slow (and with a second per-CPU message
    added for debugging purposes this even lead to timeouts during AP
    bringup).
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    
    
changeset:   24372:1c58bb664d8d
user:        Philipp Hahn <hahn@univention.de>
date:        Thu Dec 08 17:15:16 2011 +0000
    
    xend: fix insufficient quoting in tapdisk
    
    Fix insufficient quoting between "tap-ctl list" and
    xend/server/BlktapController.py
    
    The "line.split(None, 4)" needs to be a "3", because 3 splits needs to
    be done to get the 4 parts.  Sorry for the mixup.
    
    [ fix to 24335:3915bd95ade5. -iwj ]
    
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
========================================
commit 54e24021005458ad0a361c1d83011b751726a94b
Author: Ian Jackson <ian.jackson@eu.citrix.com>
Date:   Thu Dec 8 16:38:06 2011 +0000

    qemu_get_timer: Provide a comment about the behaviour on ts==NULL
    
    Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 18:08:14 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 18:08:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaAIC-0008Dn-F1; Mon, 12 Dec 2011 18:08:00 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RaAIA-0008Dc-Tn
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 18:07:59 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1323713209!58621706!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDc4NQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26718 invoked from network); 12 Dec 2011 18:06:49 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Dec 2011 18:06:49 -0000
X-IronPort-AV: E=Sophos;i="4.71,340,1320624000"; 
   d="scan'208";a="9425267"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Dec 2011 18:07:07 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 12 Dec 2011 18:07:07 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RaAHL-0000Q1-5m;
	Mon, 12 Dec 2011 18:07:07 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RaAHI-0003sZ-Pk;
	Mon, 12 Dec 2011 18:07:07 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10476-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 12 Dec 2011 18:07:04 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10476: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10476 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10476/

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-amd64-xl-sedf-pin 14 guest-localmigrate/x10    fail REGR. vs. 10474

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-credit2   12 guest-saverestore.2         fail pass in 10475
 test-amd64-amd64-xl-sedf      5 xen-boot                    fail pass in 10475

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-i386-i386-xl-winxpsp3    7 windows-install              fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install          fail never pass
 test-amd64-i386-xl-win7-amd64  7 windows-install              fail  never pass
 test-amd64-i386-xend-winxpsp3  7 windows-install              fail  never pass
 test-amd64-amd64-xl-win7-amd64  7 windows-install              fail never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-sedf    14 guest-localmigrate/x10 fail in 10475 like 10474

version targeted for testing:
 xen                  f1ab2c2138d8
baseline version:
 xen                  1c58bb664d8d

------------------------------------------------------------
People who touched revisions under test:
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   24373:f1ab2c2138d8
tag:         tip
user:        Jan Beulich <jbeulich@suse.com>
date:        Mon Dec 12 10:47:26 2011 +0100
    
    x86/Intel: quiesce revised CPUID level message
    
    Print this only once, for the boot CPU, unless "cpuinfo" was specified.
    I found this particularly annoying on a machine which also didn't have
    it MTRRs consistently set up across cores, resulting in the printing of
    those messages being awfully slow (and with a second per-CPU message
    added for debugging purposes this even lead to timeouts during AP
    bringup).
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    
    
changeset:   24372:1c58bb664d8d
user:        Philipp Hahn <hahn@univention.de>
date:        Thu Dec 08 17:15:16 2011 +0000
    
    xend: fix insufficient quoting in tapdisk
    
    Fix insufficient quoting between "tap-ctl list" and
    xend/server/BlktapController.py
    
    The "line.split(None, 4)" needs to be a "3", because 3 splits needs to
    be done to get the 4 parts.  Sorry for the mixup.
    
    [ fix to 24335:3915bd95ade5. -iwj ]
    
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
========================================
commit 54e24021005458ad0a361c1d83011b751726a94b
Author: Ian Jackson <ian.jackson@eu.citrix.com>
Date:   Thu Dec 8 16:38:06 2011 +0000

    qemu_get_timer: Provide a comment about the behaviour on ts==NULL
    
    Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 18:29:20 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 18:29:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaAcb-0008Up-4H; Mon, 12 Dec 2011 18:29:05 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <bastian@waldi.eu.org>) id 1RaAcZ-0008UZ-Os
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 18:29:03 +0000
X-Env-Sender: bastian@waldi.eu.org
X-Msg-Ref: server-11.tower-174.messagelabs.com!1323714489!5252660!1
X-Originating-IP: [82.139.201.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15985 invoked from network); 12 Dec 2011 18:28:10 -0000
Received: from wavehammer.waldi.eu.org (HELO wavehammer.waldi.eu.org)
	(82.139.201.20)
	by server-11.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 12 Dec 2011 18:28:10 -0000
Received: by wavehammer.waldi.eu.org (Postfix, from userid 1000)
	id 1C5935415D; Mon, 12 Dec 2011 19:28:07 +0100 (CET)
Date: Mon, 12 Dec 2011 19:28:07 +0100
From: Bastian Blank <bastian@waldi.eu.org>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <20111212182807.GB14966@wavehammer.waldi.eu.org>
Mail-Followup-To: Bastian Blank <bastian@waldi.eu.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org
References: <1323541791-18006-1-git-send-email-waldi@debian.org>
	<1323541791-18006-7-git-send-email-waldi@debian.org>
	<20111212154227.GB21558@phenom.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20111212154227.GB21558@phenom.dumpdata.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH 6/6] xen/xenbus-backend: Only register
 device if communication ring is local
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Dec 12, 2011 at 10:42:27AM -0500, Konrad Rzeszutek Wilk wrote:
> On Sat, Dec 10, 2011 at 07:29:51PM +0100, Bastian Blank wrote:
> > -module_init(xenbus_backend_init);
> > -module_exit(xenbus_backend_exit);
> 
> Why are we removing the module functionality?
> Can't this [the purpose of this patch] be done while still maintaining the module functionality?

Not really. The purpose is to register the device only if the ring is
local. This information is not available to modules.

However we could just move the whole xenbus ring setup into a "module".
Or is there any reason for this to be in a postcore_initcall, even if it
is only operational after a userspace process works?

> >  int xenstored_ready;
> >  
> > +/* A flag to determine if xenstored is 'local' */
> > +#ifdef CONFIG_XEN_BACKEND
> > +static int xenstored_local;
> 
> bool?

Well. The other flags are int also.

> > +			BUG();
> No way. A WARN, sure - but BUG() is way too intense for this.

Okay.

Bastian

-- 
The sight of death frightens them [Earthers].
		-- Kras the Klingon, "Friday's Child", stardate 3497.2

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 18:29:20 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 18:29:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaAcb-0008Up-4H; Mon, 12 Dec 2011 18:29:05 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <bastian@waldi.eu.org>) id 1RaAcZ-0008UZ-Os
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 18:29:03 +0000
X-Env-Sender: bastian@waldi.eu.org
X-Msg-Ref: server-11.tower-174.messagelabs.com!1323714489!5252660!1
X-Originating-IP: [82.139.201.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15985 invoked from network); 12 Dec 2011 18:28:10 -0000
Received: from wavehammer.waldi.eu.org (HELO wavehammer.waldi.eu.org)
	(82.139.201.20)
	by server-11.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 12 Dec 2011 18:28:10 -0000
Received: by wavehammer.waldi.eu.org (Postfix, from userid 1000)
	id 1C5935415D; Mon, 12 Dec 2011 19:28:07 +0100 (CET)
Date: Mon, 12 Dec 2011 19:28:07 +0100
From: Bastian Blank <bastian@waldi.eu.org>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <20111212182807.GB14966@wavehammer.waldi.eu.org>
Mail-Followup-To: Bastian Blank <bastian@waldi.eu.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org
References: <1323541791-18006-1-git-send-email-waldi@debian.org>
	<1323541791-18006-7-git-send-email-waldi@debian.org>
	<20111212154227.GB21558@phenom.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20111212154227.GB21558@phenom.dumpdata.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH 6/6] xen/xenbus-backend: Only register
 device if communication ring is local
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Dec 12, 2011 at 10:42:27AM -0500, Konrad Rzeszutek Wilk wrote:
> On Sat, Dec 10, 2011 at 07:29:51PM +0100, Bastian Blank wrote:
> > -module_init(xenbus_backend_init);
> > -module_exit(xenbus_backend_exit);
> 
> Why are we removing the module functionality?
> Can't this [the purpose of this patch] be done while still maintaining the module functionality?

Not really. The purpose is to register the device only if the ring is
local. This information is not available to modules.

However we could just move the whole xenbus ring setup into a "module".
Or is there any reason for this to be in a postcore_initcall, even if it
is only operational after a userspace process works?

> >  int xenstored_ready;
> >  
> > +/* A flag to determine if xenstored is 'local' */
> > +#ifdef CONFIG_XEN_BACKEND
> > +static int xenstored_local;
> 
> bool?

Well. The other flags are int also.

> > +			BUG();
> No way. A WARN, sure - but BUG() is way too intense for this.

Okay.

Bastian

-- 
The sight of death frightens them [Earthers].
		-- Kras the Klingon, "Friday's Child", stardate 3497.2

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 18:37:55 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 18:37:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaAkr-0000dO-Fy; Mon, 12 Dec 2011 18:37:37 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <nupurghatnekar@gmail.com>) id 1RaAkq-0000dF-Be
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 18:37:36 +0000
X-Env-Sender: nupurghatnekar@gmail.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1323715002!7138422!1
X-Originating-IP: [209.85.161.43]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17633 invoked from network); 12 Dec 2011 18:36:42 -0000
Received: from mail-fx0-f43.google.com (HELO mail-fx0-f43.google.com)
	(209.85.161.43)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Dec 2011 18:36:42 -0000
Received: by faap21 with SMTP id p21so713135faa.30
	for <xen-devel@lists.xensource.com>;
	Mon, 12 Dec 2011 10:36:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=ZzOjA8/+brLZHoa1vTlD51in52ULN9dizdJOgmJduwU=;
	b=YDH+9dDgvvE2BRvwQdrKF6xx6aF25GRzFllylLjBkFV7eeJ4e1lKb6oivUTMOZTjED
	Tb5RutREejVD6o5XjATf2an/vi+oYWRmMdHbQ2cZA7gC8bFPxB3vYXABhJMQl2KoCmlH
	gn4Q9qawzXgR3/3qqSCq9+WBW3eD6keh9mIDQ=
MIME-Version: 1.0
Received: by 10.180.100.33 with SMTP id ev1mr5372463wib.2.1323715001292; Mon,
	12 Dec 2011 10:36:41 -0800 (PST)
Received: by 10.180.106.195 with HTTP; Mon, 12 Dec 2011 10:36:41 -0800 (PST)
Date: Tue, 13 Dec 2011 00:06:41 +0530
Message-ID: <CAO8_4VrOwdsWDjRvHM9-zytJ1qefhR=5FJ94Pvr9nA9LVDdH5Q@mail.gmail.com>
From: Nupur Ghatnekar <nupurghatnekar@gmail.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] Drivers (backend/frontend drivers) for "Hello World "
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============5664793100694402709=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============5664793100694402709==
Content-Type: multipart/alternative; boundary=f46d044402666f995404b3e96a04

--f46d044402666f995404b3e96a04
Content-Type: text/plain; charset=UTF-8

Hello,

I want to write a small module which can help me transfer a string between
dom0 and domU.
A small "hello world" program. wherein, whatever the Dom0 writes is printed
in DomU.

can you suggest me a way to tackle this. I am new to the environment.
Perhaps an example can help me understand the flow of events.

Regards,
Nupur
-- 

Nupur Ghatnekar

--f46d044402666f995404b3e96a04
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div>Hello,</div><div><br></div><div>I want to write a small module which c=
an help me transfer a string between dom0 and domU.=C2=A0</div><div>A small=
 &quot;hello world&quot; program. wherein, whatever the Dom0 writes is prin=
ted in DomU.</div>
<div><br></div><div>can you suggest me a way to tackle this. I am new to th=
e environment. Perhaps an example can help me understand the flow of events=
.</div><div><br></div><div>Regards,</div><div>Nupur=C2=A0</div>-- <br><br>N=
upur Ghatnekar<br>


--f46d044402666f995404b3e96a04--


--===============5664793100694402709==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============5664793100694402709==--


From xen-devel-bounces@lists.xensource.com Mon Dec 12 18:37:55 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 18:37:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaAkr-0000dO-Fy; Mon, 12 Dec 2011 18:37:37 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <nupurghatnekar@gmail.com>) id 1RaAkq-0000dF-Be
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 18:37:36 +0000
X-Env-Sender: nupurghatnekar@gmail.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1323715002!7138422!1
X-Originating-IP: [209.85.161.43]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17633 invoked from network); 12 Dec 2011 18:36:42 -0000
Received: from mail-fx0-f43.google.com (HELO mail-fx0-f43.google.com)
	(209.85.161.43)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Dec 2011 18:36:42 -0000
Received: by faap21 with SMTP id p21so713135faa.30
	for <xen-devel@lists.xensource.com>;
	Mon, 12 Dec 2011 10:36:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=ZzOjA8/+brLZHoa1vTlD51in52ULN9dizdJOgmJduwU=;
	b=YDH+9dDgvvE2BRvwQdrKF6xx6aF25GRzFllylLjBkFV7eeJ4e1lKb6oivUTMOZTjED
	Tb5RutREejVD6o5XjATf2an/vi+oYWRmMdHbQ2cZA7gC8bFPxB3vYXABhJMQl2KoCmlH
	gn4Q9qawzXgR3/3qqSCq9+WBW3eD6keh9mIDQ=
MIME-Version: 1.0
Received: by 10.180.100.33 with SMTP id ev1mr5372463wib.2.1323715001292; Mon,
	12 Dec 2011 10:36:41 -0800 (PST)
Received: by 10.180.106.195 with HTTP; Mon, 12 Dec 2011 10:36:41 -0800 (PST)
Date: Tue, 13 Dec 2011 00:06:41 +0530
Message-ID: <CAO8_4VrOwdsWDjRvHM9-zytJ1qefhR=5FJ94Pvr9nA9LVDdH5Q@mail.gmail.com>
From: Nupur Ghatnekar <nupurghatnekar@gmail.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] Drivers (backend/frontend drivers) for "Hello World "
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============5664793100694402709=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============5664793100694402709==
Content-Type: multipart/alternative; boundary=f46d044402666f995404b3e96a04

--f46d044402666f995404b3e96a04
Content-Type: text/plain; charset=UTF-8

Hello,

I want to write a small module which can help me transfer a string between
dom0 and domU.
A small "hello world" program. wherein, whatever the Dom0 writes is printed
in DomU.

can you suggest me a way to tackle this. I am new to the environment.
Perhaps an example can help me understand the flow of events.

Regards,
Nupur
-- 

Nupur Ghatnekar

--f46d044402666f995404b3e96a04
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div>Hello,</div><div><br></div><div>I want to write a small module which c=
an help me transfer a string between dom0 and domU.=C2=A0</div><div>A small=
 &quot;hello world&quot; program. wherein, whatever the Dom0 writes is prin=
ted in DomU.</div>
<div><br></div><div>can you suggest me a way to tackle this. I am new to th=
e environment. Perhaps an example can help me understand the flow of events=
.</div><div><br></div><div>Regards,</div><div>Nupur=C2=A0</div>-- <br><br>N=
upur Ghatnekar<br>


--f46d044402666f995404b3e96a04--


--===============5664793100694402709==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============5664793100694402709==--


From xen-devel-bounces@lists.xensource.com Mon Dec 12 18:46:35 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 18:46:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaAtF-0000rm-MD; Mon, 12 Dec 2011 18:46:17 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1RaAtE-0000rh-Ak
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 18:46:16 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-14.tower-27.messagelabs.com!1323715403!47971098!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6197 invoked from network); 12 Dec 2011 18:43:23 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-14.tower-27.messagelabs.com with AES256-SHA encrypted SMTP;
	12 Dec 2011 18:43:23 -0000
Received: from 87-74-ftth.onsneteindhoven.nl ([88.159.74.87]:49822
	helo=[172.16.1.229])
	by smtp.eikelenboom.it with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32)
	(Exim 4.72) (envelope-from <linux@eikelenboom.it>)
	id 1RaAps-00069L-3Y; Mon, 12 Dec 2011 19:42:48 +0100
Date: Mon, 12 Dec 2011 19:45:25 +0100
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <707238508.20111212194525@eikelenboom.it>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
In-Reply-To: <20198.11738.646611.204591@mariner.uk.xensource.com>
References: <20198.11738.646611.204591@mariner.uk.xensource.com>
MIME-Version: 1.0
Cc: Lars Kurth <lars.kurth@citrix.com>, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Security vulnerability process - confirmed
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hello Ian,

Monday, December 12, 2011, 5:37:46 PM, you wrote:

> It's time we made this policy official.  There was only one change to
> make during "last call" discussion, and with that I think we have
> consensus.

> Changes from the final draft:

>   * Increase the standard embargo period from one week to two,
>     as discussed in the last call.

> The final version, below, will go on the xen.org website shortly.

> Thanks,
> Ian.

>             xen.org security problem response process
>             -----------------------------------------

<big snip>

> 3. Advisory public release:

>    At the embargo date we will publish the advisory, and push
>    bugfix changesets to public revision control trees.

>    Public advisories will be posted to xen-devel.

>    Copies will also be sent to the pre-disclosure list, unless
>    the advisory was already sent there previously during the embargo
>    period and has not been updated since.


shouldn't this include at least xen-users and xen-announce, and perhaps a special read only list for security advisories ?

<big snip>


--
Sander


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 18:46:35 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 18:46:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaAtF-0000rm-MD; Mon, 12 Dec 2011 18:46:17 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1RaAtE-0000rh-Ak
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 18:46:16 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-14.tower-27.messagelabs.com!1323715403!47971098!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6197 invoked from network); 12 Dec 2011 18:43:23 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-14.tower-27.messagelabs.com with AES256-SHA encrypted SMTP;
	12 Dec 2011 18:43:23 -0000
Received: from 87-74-ftth.onsneteindhoven.nl ([88.159.74.87]:49822
	helo=[172.16.1.229])
	by smtp.eikelenboom.it with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32)
	(Exim 4.72) (envelope-from <linux@eikelenboom.it>)
	id 1RaAps-00069L-3Y; Mon, 12 Dec 2011 19:42:48 +0100
Date: Mon, 12 Dec 2011 19:45:25 +0100
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <707238508.20111212194525@eikelenboom.it>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
In-Reply-To: <20198.11738.646611.204591@mariner.uk.xensource.com>
References: <20198.11738.646611.204591@mariner.uk.xensource.com>
MIME-Version: 1.0
Cc: Lars Kurth <lars.kurth@citrix.com>, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Security vulnerability process - confirmed
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hello Ian,

Monday, December 12, 2011, 5:37:46 PM, you wrote:

> It's time we made this policy official.  There was only one change to
> make during "last call" discussion, and with that I think we have
> consensus.

> Changes from the final draft:

>   * Increase the standard embargo period from one week to two,
>     as discussed in the last call.

> The final version, below, will go on the xen.org website shortly.

> Thanks,
> Ian.

>             xen.org security problem response process
>             -----------------------------------------

<big snip>

> 3. Advisory public release:

>    At the embargo date we will publish the advisory, and push
>    bugfix changesets to public revision control trees.

>    Public advisories will be posted to xen-devel.

>    Copies will also be sent to the pre-disclosure list, unless
>    the advisory was already sent there previously during the embargo
>    period and has not been updated since.


shouldn't this include at least xen-users and xen-announce, and perhaps a special read only list for security advisories ?

<big snip>


--
Sander


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 19:13:26 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 19:13:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaBIy-0001Gx-8o; Mon, 12 Dec 2011 19:12:52 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <miche@google.com>) id 1RaBIw-0001Gs-Lt
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 19:12:50 +0000
X-Env-Sender: miche@google.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1323717116!7909529!1
X-Originating-IP: [209.85.216.50]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4213 invoked from network); 12 Dec 2011 19:11:57 -0000
Received: from mail-qw0-f50.google.com (HELO mail-qw0-f50.google.com)
	(209.85.216.50)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Dec 2011 19:11:57 -0000
Received: by qaea17 with SMTP id a17so30343344qae.9
	for <xen-devel@lists.xensource.com>;
	Mon, 12 Dec 2011 11:11:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding:x-system-of-record;
	bh=dMmeci4jGeWX0zaD4F7y2rK/+GkROzvi29qSy/dVFQ8=;
	b=KH87OBiOmR7pfQtk+ER3gjAkgysN5nIesGabTzISkSBf8eFUkTmEfb5tQelB1p4lST
	isg7JRM4NLCfcjKTvkDQ==
Received: by 10.224.77.13 with SMTP id e13mr18627167qak.51.1323717116221;
	Mon, 12 Dec 2011 11:11:56 -0800 (PST)
MIME-Version: 1.0
Received: by 10.224.77.13 with SMTP id e13mr18627147qak.51.1323717116107; Mon,
	12 Dec 2011 11:11:56 -0800 (PST)
Received: by 10.229.210.155 with HTTP; Mon, 12 Dec 2011 11:11:55 -0800 (PST)
In-Reply-To: <20111208120804.GF23531@amit-x200.redhat.com>
References: <20111108214504.28884.61814.stgit@miche.sea.corp.google.com>
	<874nybqo0o.fsf@rustcorp.com.au>
	<CAB8RdapbaueyWLJuJDE_ZdvLkRNM4sQHTxgmgO=jrnXZ6YPSmA@mail.gmail.com>
	<20111123103852.GG16665@amit-x200.redhat.com>
	<CAB8RdaoDxMCgTjuGP70bGrsrtgh=USYtU3Spo5OPtVMYAM5EzQ@mail.gmail.com>
	<20111129142149.GE2822@amit-x200.redhat.com>
	<CAB8RdapuPRym2dH_9mgmGdzpCxnP1KpS+hS8JJ-geVkga5fMcw@mail.gmail.com>
	<CAB8Rdapfuf5XH+X9gsUL+CJ9gTQcSNfq4Dj9DoYWQeFgD04ODQ@mail.gmail.com>
	<20111205105452.GB27683@amit-x200.redhat.com>
	<CAB8Rdar=qOokxZkjQVRmo=zN_f75jPwzU+6=WBRo0g+P7w+pAw@mail.gmail.com>
	<20111208120804.GF23531@amit-x200.redhat.com>
Date: Mon, 12 Dec 2011 11:11:55 -0800
Message-ID: <CAB8RdapDDV0kYW_uASpBoJ3hbx6zScKnG+LWWcjYtqMnqXN4Xw@mail.gmail.com>
From: Miche Baker-Harvey <miche@google.com>
To: Amit Shah <amit.shah@redhat.com>
X-System-Of-Record: true
Cc: Stephen Rothwell <sfr@canb.auug.org.au>, xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Rusty Russell <rusty@rustcorp.com.au>, linux-kernel@vger.kernel.org,
	virtualization@lists.linux-foundation.org,
	Anton Blanchard <anton@samba.org>, Mike Waychison <mikew@google.com>,
	ppc-dev <linuxppc-dev@lists.ozlabs.org>,
	Greg Kroah-Hartman <gregkh@suse.de>, Eric Northrup <digitaleric@google.com>
Subject: Re: [Xen-devel] [PATCH v3 2/3] hvc_init(): Enforce one-time
	initialization.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

So on a CONSOLE_PORT_ADD message, we would take the
(existing)ports_device::ports_lock, and for other control messages we
would justtake the (new) port::port_lock? =A0You are concerned that just
takingthe ports_lock for all control messages could be too
restrictive? =A0Iwouldn't have expected these messages to be frequent
occurrences, butI'll defer to your experience here.
The CONSOLE_CONSOLE_PORT message calls hvc_alloc, which also
needsserialization. =A0That's in another one of these three patches; are
youthinking we could leave that patch be, or that we would we use
theport_lock for CONSOLE_CONSOLE_PORT? =A0Using the port_lock
wouldprovide the HVC serialization "for free" but it would be cleaner
if weput HVC related synchronization in hvc_console.c.
On Thu, Dec 8, 2011 at 4:08 AM, Amit Shah <amit.shah@redhat.com> wrote:
> On (Tue) 06 Dec 2011 [09:05:38], Miche Baker-Harvey wrote:
>> Amit,
>>
>> Ah, indeed. =A0I am not using MSI-X, so virtio_pci::vp_try_to_find_vqs()
>> calls vp_request_intx() and sets up an interrupt callback. =A0From
>> there, when an interrupt occurs, the stack looks something like this:
>>
>> virtio_pci::vp_interrupt()
>> =A0 virtio_pci::vp_vring_interrupt()
>> =A0 =A0 virtio_ring::vring_interrupt()
>> =A0 =A0 =A0 vq->vq.callback() =A0<-- in this case, that's virtio_console=
::control_intr()
>> =A0 =A0 =A0 =A0 workqueue::schedule_work()
>> =A0 =A0 =A0 =A0 =A0 workqueue::queue_work()
>> =A0 =A0 =A0 =A0 =A0 =A0 queue_work_on(get_cpu()) =A0<-- queues the work =
on the current CPU.
>>
>> I'm not doing anything to keep multiple control message from being
>> sent concurrently to the guest, and we will take those interrupts on
>> any CPU. I've confirmed that the two instances of
>> handle_control_message() are occurring on different CPUs.
>
> So let's have a new helper, port_lock() that takes the port-specific
> spinlock. =A0There has to be a new helper, since the port lock should
> depend on the portdev lock being taken too. =A0For the port addition
> case, just the portdev lock should be taken. =A0For any other
> operations, the port lock should be taken.
>
> My assumption was that we would be able to serialise the work items,
> but that will be too restrictive. =A0Taking port locks sounds like a
> better idea.
>
> We'd definitely need the port lock in the control work handler. =A0We
> might need it in a few more places (like module removal), but we'll
> worry about that later.
>
> Does this sound fine?
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Amit

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 19:13:26 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 19:13:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaBIy-0001Gx-8o; Mon, 12 Dec 2011 19:12:52 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <miche@google.com>) id 1RaBIw-0001Gs-Lt
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 19:12:50 +0000
X-Env-Sender: miche@google.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1323717116!7909529!1
X-Originating-IP: [209.85.216.50]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4213 invoked from network); 12 Dec 2011 19:11:57 -0000
Received: from mail-qw0-f50.google.com (HELO mail-qw0-f50.google.com)
	(209.85.216.50)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Dec 2011 19:11:57 -0000
Received: by qaea17 with SMTP id a17so30343344qae.9
	for <xen-devel@lists.xensource.com>;
	Mon, 12 Dec 2011 11:11:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding:x-system-of-record;
	bh=dMmeci4jGeWX0zaD4F7y2rK/+GkROzvi29qSy/dVFQ8=;
	b=KH87OBiOmR7pfQtk+ER3gjAkgysN5nIesGabTzISkSBf8eFUkTmEfb5tQelB1p4lST
	isg7JRM4NLCfcjKTvkDQ==
Received: by 10.224.77.13 with SMTP id e13mr18627167qak.51.1323717116221;
	Mon, 12 Dec 2011 11:11:56 -0800 (PST)
MIME-Version: 1.0
Received: by 10.224.77.13 with SMTP id e13mr18627147qak.51.1323717116107; Mon,
	12 Dec 2011 11:11:56 -0800 (PST)
Received: by 10.229.210.155 with HTTP; Mon, 12 Dec 2011 11:11:55 -0800 (PST)
In-Reply-To: <20111208120804.GF23531@amit-x200.redhat.com>
References: <20111108214504.28884.61814.stgit@miche.sea.corp.google.com>
	<874nybqo0o.fsf@rustcorp.com.au>
	<CAB8RdapbaueyWLJuJDE_ZdvLkRNM4sQHTxgmgO=jrnXZ6YPSmA@mail.gmail.com>
	<20111123103852.GG16665@amit-x200.redhat.com>
	<CAB8RdaoDxMCgTjuGP70bGrsrtgh=USYtU3Spo5OPtVMYAM5EzQ@mail.gmail.com>
	<20111129142149.GE2822@amit-x200.redhat.com>
	<CAB8RdapuPRym2dH_9mgmGdzpCxnP1KpS+hS8JJ-geVkga5fMcw@mail.gmail.com>
	<CAB8Rdapfuf5XH+X9gsUL+CJ9gTQcSNfq4Dj9DoYWQeFgD04ODQ@mail.gmail.com>
	<20111205105452.GB27683@amit-x200.redhat.com>
	<CAB8Rdar=qOokxZkjQVRmo=zN_f75jPwzU+6=WBRo0g+P7w+pAw@mail.gmail.com>
	<20111208120804.GF23531@amit-x200.redhat.com>
Date: Mon, 12 Dec 2011 11:11:55 -0800
Message-ID: <CAB8RdapDDV0kYW_uASpBoJ3hbx6zScKnG+LWWcjYtqMnqXN4Xw@mail.gmail.com>
From: Miche Baker-Harvey <miche@google.com>
To: Amit Shah <amit.shah@redhat.com>
X-System-Of-Record: true
Cc: Stephen Rothwell <sfr@canb.auug.org.au>, xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Rusty Russell <rusty@rustcorp.com.au>, linux-kernel@vger.kernel.org,
	virtualization@lists.linux-foundation.org,
	Anton Blanchard <anton@samba.org>, Mike Waychison <mikew@google.com>,
	ppc-dev <linuxppc-dev@lists.ozlabs.org>,
	Greg Kroah-Hartman <gregkh@suse.de>, Eric Northrup <digitaleric@google.com>
Subject: Re: [Xen-devel] [PATCH v3 2/3] hvc_init(): Enforce one-time
	initialization.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

So on a CONSOLE_PORT_ADD message, we would take the
(existing)ports_device::ports_lock, and for other control messages we
would justtake the (new) port::port_lock? =A0You are concerned that just
takingthe ports_lock for all control messages could be too
restrictive? =A0Iwouldn't have expected these messages to be frequent
occurrences, butI'll defer to your experience here.
The CONSOLE_CONSOLE_PORT message calls hvc_alloc, which also
needsserialization. =A0That's in another one of these three patches; are
youthinking we could leave that patch be, or that we would we use
theport_lock for CONSOLE_CONSOLE_PORT? =A0Using the port_lock
wouldprovide the HVC serialization "for free" but it would be cleaner
if weput HVC related synchronization in hvc_console.c.
On Thu, Dec 8, 2011 at 4:08 AM, Amit Shah <amit.shah@redhat.com> wrote:
> On (Tue) 06 Dec 2011 [09:05:38], Miche Baker-Harvey wrote:
>> Amit,
>>
>> Ah, indeed. =A0I am not using MSI-X, so virtio_pci::vp_try_to_find_vqs()
>> calls vp_request_intx() and sets up an interrupt callback. =A0From
>> there, when an interrupt occurs, the stack looks something like this:
>>
>> virtio_pci::vp_interrupt()
>> =A0 virtio_pci::vp_vring_interrupt()
>> =A0 =A0 virtio_ring::vring_interrupt()
>> =A0 =A0 =A0 vq->vq.callback() =A0<-- in this case, that's virtio_console=
::control_intr()
>> =A0 =A0 =A0 =A0 workqueue::schedule_work()
>> =A0 =A0 =A0 =A0 =A0 workqueue::queue_work()
>> =A0 =A0 =A0 =A0 =A0 =A0 queue_work_on(get_cpu()) =A0<-- queues the work =
on the current CPU.
>>
>> I'm not doing anything to keep multiple control message from being
>> sent concurrently to the guest, and we will take those interrupts on
>> any CPU. I've confirmed that the two instances of
>> handle_control_message() are occurring on different CPUs.
>
> So let's have a new helper, port_lock() that takes the port-specific
> spinlock. =A0There has to be a new helper, since the port lock should
> depend on the portdev lock being taken too. =A0For the port addition
> case, just the portdev lock should be taken. =A0For any other
> operations, the port lock should be taken.
>
> My assumption was that we would be able to serialise the work items,
> but that will be too restrictive. =A0Taking port locks sounds like a
> better idea.
>
> We'd definitely need the port lock in the control work handler. =A0We
> might need it in a few more places (like module removal), but we'll
> worry about that later.
>
> Does this sound fine?
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Amit

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 19:24:09 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 19:24:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaBTO-0001SQ-Dz; Mon, 12 Dec 2011 19:23:38 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RaBTM-0001SJ-QS
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 19:23:37 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1323717762!5262468!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDc4NQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10370 invoked from network); 12 Dec 2011 19:22:43 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Dec 2011 19:22:43 -0000
X-IronPort-AV: E=Sophos;i="4.71,340,1320624000"; 
   d="scan'208";a="9425977"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Dec 2011 19:22:42 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 12 Dec 2011 19:22:42 +0000
Date: Mon, 12 Dec 2011 19:24:20 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
In-Reply-To: <20198.9737.680162.103418@mariner.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1112121613330.3517@kaball-desktop>
References: <1323108621-22654-1-git-send-email-ian.jackson@eu.citrix.com>
	<1323108621-22654-16-git-send-email-ian.jackson@eu.citrix.com>
	<alpine.DEB.2.00.1112091558300.3517@kaball-desktop>
	<20194.22539.574524.956955@mariner.uk.xensource.com>
	<1323463293.20936.11.camel@dagon.hellion.org.uk>
	<20197.59428.699013.507183@mariner.uk.xensource.com>
	<1323692225.20077.183.camel@zakaz.uk.xensource.com>
	<20197.62462.189827.239656@mariner.uk.xensource.com>
	<1323697723.20077.212.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1112121453050.3517@kaball-desktop>
	<20198.9737.680162.103418@mariner.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-287492656-1323717865=:3517"
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 15/15] libxl: New event generation API
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--8323329-287492656-1323717865=:3517
Content-Type: text/plain; charset="US-ASCII"

On Mon, 12 Dec 2011, Ian Jackson wrote:
> > > It's probably not so important for memory allocation cleanup but it
> > > would be a semantically useful change for the callbacks if we could
> > > arrange for them to happen only on final exit of the library -- exactly
> > > because of the difficulty of reasoning about things otherwise. Alas I
> > > can't think of a good way to do this since the ctx can be shared, thread
> > > local storage would be one or libxl__gc_owner could return a special
> > > "nested ctx" instead of the real outer ctx, but, ick.
> > 
> > I think that using TLS to increase/decrease a nesting counter would OK
> > in this case. We could have a libxl__enter and a libxl__exit function
> > that take care it this.
> > 
> > Modifying libxl__gc_owner could lead to errors because it doesn't handle
> > the case in which an externally visible function calls another
> > externally visible function: libxl__gc_owner wouldn't even be called in
> > this case.
> 
> I suggested to Ian the moral equivalent of:
> 
> #define CTX_LOCK \
>      <previous implementation> \
>      ctx->recursive_lock_counter++
> 
> #define GC_INIT \
>      CTX_LOCK; \
>      assert(ctx->recursive_lock_counter==1); \
>      CTX_UNLOCK
> 
> but I don't think this is really very nice.
> 
> 
> I think the answer is to write a comment saying that it is forbidden
> to allocate a new gc with the ctx locked.
 
Why not handle the case correctly in the first place?
It is certainly better than an assert or a comment, don't you think?
Ideally the code should be easy enough to understand without a comment.
This is what I have in mind:


diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index cd613f7..94bdbba 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -63,6 +63,12 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
      * only as an initialiser, not as an expression. */
     memcpy(&ctx->lock, &mutex_value, sizeof(ctx->lock));
 
+    if(pthread_key_create(&ctx->tls_key, NULL) < 0) {
+        LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, errno,
+            "cannot create tls key");
+        return ERROR_FAIL;
+    }
+
     if ( stat(XENSTORE_PID_FILE, &stat_buf) != 0 ) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "Is xenstore daemon running?\n"
                      "failed to stat %s", XENSTORE_PID_FILE);
diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c
index 34edaf3..eef3815 100644
--- a/tools/libxl/libxl_internal.c
+++ b/tools/libxl/libxl_internal.c
@@ -19,6 +19,7 @@
 #include <stdarg.h>
 #include <string.h>
 
+#include <pthread.h>
 #include <sys/types.h>
 #include <sys/stat.h>
 #include <fcntl.h>
@@ -65,17 +66,41 @@ int libxl__ptr_add(libxl__gc *gc, void *ptr)
     return 0;
 }
 
+libxl__gc *libxl__init_gc(libxl_ctx *ctx)
+{
+    libxl__gc *gc = (libxl__gc *) pthread_getspecific(ctx->tls_key);
+    if (gc == NULL) {
+        gc = (libxl__gc *) malloc(sizeof(libxl__gc));
+        if (gc == NULL)
+            return NULL;
+        gc->alloc_maxsize = 0;
+        gc->alloc_ptrs = 0;
+        gc->owner = ctx;
+        gc->nested = 1;
+        pthread_setspecific(ctx->tls_key, gc);
+    } else {
+        gc->nested++;
+    }
+    return gc;
+}
+
 void libxl__free_all(libxl__gc *gc)
 {
     void *ptr;
     int i;
 
+    gc->nested--;
+    if (gc->nested > 0)
+        return;
+
     for (i = 0; i < gc->alloc_maxsize; i++) {
         ptr = gc->alloc_ptrs[i];
         gc->alloc_ptrs[i] = NULL;
         free(ptr);
     }
     free(gc->alloc_ptrs);
+    pthread_setspecific(CTX->tls_key, NULL);
+    free(gc);
 }
 
 void *libxl__zalloc(libxl__gc *gc, int bytes)
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index b479c49..50e6b33 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -91,6 +91,8 @@ struct libxl__ctx {
     xc_interface *xch;
     struct xs_handle *xsh;
 
+    pthread_key_t tls_key;
+
     pthread_mutex_t lock; /* protects data structures hanging off the ctx */
       /* Always use CTX_LOCK and CTX_UNLOCK to manipulate this.
        *
@@ -138,9 +140,9 @@ typedef struct {
     int alloc_maxsize;
     void **alloc_ptrs;
     libxl_ctx *owner;
+    int nested;
 } libxl__gc;
 
-#define LIBXL_INIT_GC(ctx) (libxl__gc){ .alloc_maxsize = 0, .alloc_ptrs = 0, .owner = ctx }
 static inline libxl_ctx *libxl__gc_owner(libxl__gc *gc)
 {
     return gc->owner;
@@ -670,7 +672,8 @@ libxl__device_model_version_running(libxl__gc *gc, uint32_t domid);
  * as a local variable.
  */
 
-#define GC_INIT(ctx)  libxl__gc gc[1] = { LIBXL_INIT_GC(ctx) }
+_hidden libxl__gc *libxl__init_gc(struct libxl__ctx *ctx);
+#define GC_INIT(ctx)  libxl__gc *gc = libxl__init_gc(ctx); if (gc == NULL) return ERROR_NOMEM;
 #define GC_FREE       libxl__free_all(gc)
 #define CTX           libxl__gc_owner(gc)
 
---

I like this approach because it uses malloc for gc allocation so it can
be reused for your following patches that need a gc that lives out of
the function. This way we don't have two special cases but a single
approach that works everywhere and another comment that probably doesn't
need to be read anymore.
I also think that it makes the code easier to read and understand.

However in case you would like to see how would this patch look, keeping
the gc allocation on the stack, I have appended a version of it that
uses alloca instead of malloc.



P.S.
please note that the inline patch as it is doesn't compile because some libxl
function don't return an error but they return a pointer, something that
should be changed anyway.
--8323329-287492656-1323717865=:3517
Content-Type: text/plain; charset="US-ASCII"; name="2"
Content-Transfer-Encoding: BASE64
Content-ID: <alpine.DEB.2.00.1112121924200.3517@kaball-desktop>
Content-Description: 
Content-Disposition: attachment; filename="2"

ZGlmZiAtLWdpdCBhL3Rvb2xzL2xpYnhsL2xpYnhsLmMgYi90b29scy9saWJ4
bC9saWJ4bC5jDQppbmRleCBjZDYxM2Y3Li45NGJkYmJhIDEwMDY0NA0KLS0t
IGEvdG9vbHMvbGlieGwvbGlieGwuYw0KKysrIGIvdG9vbHMvbGlieGwvbGli
eGwuYw0KQEAgLTYzLDYgKzYzLDEyIEBAIGludCBsaWJ4bF9jdHhfYWxsb2Mo
bGlieGxfY3R4ICoqcGN0eCwgaW50IHZlcnNpb24sDQogICAgICAqIG9ubHkg
YXMgYW4gaW5pdGlhbGlzZXIsIG5vdCBhcyBhbiBleHByZXNzaW9uLiAqLw0K
ICAgICBtZW1jcHkoJmN0eC0+bG9jaywgJm11dGV4X3ZhbHVlLCBzaXplb2Yo
Y3R4LT5sb2NrKSk7DQogDQorICAgIGlmKHB0aHJlYWRfa2V5X2NyZWF0ZSgm
Y3R4LT50bHNfa2V5LCBOVUxMKSA8IDApIHsNCisgICAgICAgIExJQlhMX19M
T0dfRVJSTk9WQUwoY3R4LCBMSUJYTF9fTE9HX0VSUk9SLCBlcnJubywNCisg
ICAgICAgICAgICAiY2Fubm90IGNyZWF0ZSB0bHMga2V5Iik7DQorICAgICAg
ICByZXR1cm4gRVJST1JfRkFJTDsNCisgICAgfQ0KKw0KICAgICBpZiAoIHN0
YXQoWEVOU1RPUkVfUElEX0ZJTEUsICZzdGF0X2J1ZikgIT0gMCApIHsNCiAg
ICAgICAgIExJQlhMX19MT0dfRVJSTk8oY3R4LCBMSUJYTF9fTE9HX0VSUk9S
LCAiSXMgeGVuc3RvcmUgZGFlbW9uIHJ1bm5pbmc/XG4iDQogICAgICAgICAg
ICAgICAgICAgICAgImZhaWxlZCB0byBzdGF0ICVzIiwgWEVOU1RPUkVfUElE
X0ZJTEUpOw0KZGlmZiAtLWdpdCBhL3Rvb2xzL2xpYnhsL2xpYnhsX2ludGVy
bmFsLmMgYi90b29scy9saWJ4bC9saWJ4bF9pbnRlcm5hbC5jDQppbmRleCAz
NGVkYWYzLi44MTUwMjFkIDEwMDY0NA0KLS0tIGEvdG9vbHMvbGlieGwvbGli
eGxfaW50ZXJuYWwuYw0KKysrIGIvdG9vbHMvbGlieGwvbGlieGxfaW50ZXJu
YWwuYw0KQEAgLTE5LDYgKzE5LDcgQEANCiAjaW5jbHVkZSA8c3RkYXJnLmg+
DQogI2luY2x1ZGUgPHN0cmluZy5oPg0KIA0KKyNpbmNsdWRlIDxwdGhyZWFk
Lmg+DQogI2luY2x1ZGUgPHN5cy90eXBlcy5oPg0KICNpbmNsdWRlIDxzeXMv
c3RhdC5oPg0KICNpbmNsdWRlIDxmY250bC5oPg0KQEAgLTcwLDEyICs3MSwx
NyBAQCB2b2lkIGxpYnhsX19mcmVlX2FsbChsaWJ4bF9fZ2MgKmdjKQ0KICAg
ICB2b2lkICpwdHI7DQogICAgIGludCBpOw0KIA0KKyAgICBnYy0+bmVzdGVk
LS07DQorICAgIGlmIChnYy0+bmVzdGVkID4gMCkNCisgICAgICAgIHJldHVy
bjsNCisNCiAgICAgZm9yIChpID0gMDsgaSA8IGdjLT5hbGxvY19tYXhzaXpl
OyBpKyspIHsNCiAgICAgICAgIHB0ciA9IGdjLT5hbGxvY19wdHJzW2ldOw0K
ICAgICAgICAgZ2MtPmFsbG9jX3B0cnNbaV0gPSBOVUxMOw0KICAgICAgICAg
ZnJlZShwdHIpOw0KICAgICB9DQogICAgIGZyZWUoZ2MtPmFsbG9jX3B0cnMp
Ow0KKyAgICBwdGhyZWFkX3NldHNwZWNpZmljKENUWC0+dGxzX2tleSwgTlVM
TCk7DQogfQ0KIA0KIHZvaWQgKmxpYnhsX196YWxsb2MobGlieGxfX2djICpn
YywgaW50IGJ5dGVzKQ0KZGlmZiAtLWdpdCBhL3Rvb2xzL2xpYnhsL2xpYnhs
X2ludGVybmFsLmggYi90b29scy9saWJ4bC9saWJ4bF9pbnRlcm5hbC5oDQpp
bmRleCBiNDc5YzQ5Li42ZGFhNTExIDEwMDY0NA0KLS0tIGEvdG9vbHMvbGli
eGwvbGlieGxfaW50ZXJuYWwuaA0KKysrIGIvdG9vbHMvbGlieGwvbGlieGxf
aW50ZXJuYWwuaA0KQEAgLTkxLDYgKzkxLDggQEAgc3RydWN0IGxpYnhsX19j
dHggew0KICAgICB4Y19pbnRlcmZhY2UgKnhjaDsNCiAgICAgc3RydWN0IHhz
X2hhbmRsZSAqeHNoOw0KIA0KKyAgICBwdGhyZWFkX2tleV90IHRsc19rZXk7
DQorDQogICAgIHB0aHJlYWRfbXV0ZXhfdCBsb2NrOyAvKiBwcm90ZWN0cyBk
YXRhIHN0cnVjdHVyZXMgaGFuZ2luZyBvZmYgdGhlIGN0eCAqLw0KICAgICAg
IC8qIEFsd2F5cyB1c2UgQ1RYX0xPQ0sgYW5kIENUWF9VTkxPQ0sgdG8gbWFu
aXB1bGF0ZSB0aGlzLg0KICAgICAgICAqDQpAQCAtMTM4LDkgKzE0MCw5IEBA
IHR5cGVkZWYgc3RydWN0IHsNCiAgICAgaW50IGFsbG9jX21heHNpemU7DQog
ICAgIHZvaWQgKiphbGxvY19wdHJzOw0KICAgICBsaWJ4bF9jdHggKm93bmVy
Ow0KKyAgICBpbnQgbmVzdGVkOw0KIH0gbGlieGxfX2djOw0KIA0KLSNkZWZp
bmUgTElCWExfSU5JVF9HQyhjdHgpIChsaWJ4bF9fZ2MpeyAuYWxsb2NfbWF4
c2l6ZSA9IDAsIC5hbGxvY19wdHJzID0gMCwgLm93bmVyID0gY3R4IH0NCiBz
dGF0aWMgaW5saW5lIGxpYnhsX2N0eCAqbGlieGxfX2djX293bmVyKGxpYnhs
X19nYyAqZ2MpDQogew0KICAgICByZXR1cm4gZ2MtPm93bmVyOw0KQEAgLTY3
MCw3ICs2NzIsMTggQEAgbGlieGxfX2RldmljZV9tb2RlbF92ZXJzaW9uX3J1
bm5pbmcobGlieGxfX2djICpnYywgdWludDMyX3QgZG9taWQpOw0KICAqIGFz
IGEgbG9jYWwgdmFyaWFibGUuDQogICovDQogDQotI2RlZmluZSBHQ19JTklU
KGN0eCkgIGxpYnhsX19nYyBnY1sxXSA9IHsgTElCWExfSU5JVF9HQyhjdHgp
IH0NCisjZGVmaW5lIEdDX0lOSVQoY3R4KSBcDQorICAgIGxpYnhsX19nYyAq
Z2MgPSAobGlieGxfX2djICopIHB0aHJlYWRfZ2V0c3BlY2lmaWMoY3R4LT50
bHNfa2V5KTsgXA0KKyAgICBpZiAoZ2MgPT0gTlVMTCkgeyBcDQorICAgICAg
ICBnYyA9IChsaWJ4bF9fZ2MgKikgYWxsb2NhKHNpemVvZihsaWJ4bF9fZ2Mp
KTsgXA0KKyAgICAgICAgZ2MtPmFsbG9jX21heHNpemUgPSAwOyBcDQorICAg
ICAgICBnYy0+YWxsb2NfcHRycyA9IDA7IFwNCisgICAgICAgIGdjLT5vd25l
ciA9IGN0eDsgXA0KKyAgICAgICAgZ2MtPm5lc3RlZCA9IDE7IFwNCisgICAg
ICAgIHB0aHJlYWRfc2V0c3BlY2lmaWMoY3R4LT50bHNfa2V5LCBnYyk7IFwN
CisgICAgfSBlbHNlIHsgXA0KKyAgICAgICAgZ2MtPm5lc3RlZCsrOyBcDQor
ICAgIH0NCiAjZGVmaW5lIEdDX0ZSRUUgICAgICAgbGlieGxfX2ZyZWVfYWxs
KGdjKQ0KICNkZWZpbmUgQ1RYICAgICAgICAgICBsaWJ4bF9fZ2Nfb3duZXIo
Z2MpDQogDQo=

--8323329-287492656-1323717865=:3517
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--8323329-287492656-1323717865=:3517--


From xen-devel-bounces@lists.xensource.com Mon Dec 12 19:24:09 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 19:24:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaBTO-0001SQ-Dz; Mon, 12 Dec 2011 19:23:38 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RaBTM-0001SJ-QS
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 19:23:37 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1323717762!5262468!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDc4NQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10370 invoked from network); 12 Dec 2011 19:22:43 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Dec 2011 19:22:43 -0000
X-IronPort-AV: E=Sophos;i="4.71,340,1320624000"; 
   d="scan'208";a="9425977"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Dec 2011 19:22:42 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 12 Dec 2011 19:22:42 +0000
Date: Mon, 12 Dec 2011 19:24:20 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
In-Reply-To: <20198.9737.680162.103418@mariner.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1112121613330.3517@kaball-desktop>
References: <1323108621-22654-1-git-send-email-ian.jackson@eu.citrix.com>
	<1323108621-22654-16-git-send-email-ian.jackson@eu.citrix.com>
	<alpine.DEB.2.00.1112091558300.3517@kaball-desktop>
	<20194.22539.574524.956955@mariner.uk.xensource.com>
	<1323463293.20936.11.camel@dagon.hellion.org.uk>
	<20197.59428.699013.507183@mariner.uk.xensource.com>
	<1323692225.20077.183.camel@zakaz.uk.xensource.com>
	<20197.62462.189827.239656@mariner.uk.xensource.com>
	<1323697723.20077.212.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1112121453050.3517@kaball-desktop>
	<20198.9737.680162.103418@mariner.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-287492656-1323717865=:3517"
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 15/15] libxl: New event generation API
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--8323329-287492656-1323717865=:3517
Content-Type: text/plain; charset="US-ASCII"

On Mon, 12 Dec 2011, Ian Jackson wrote:
> > > It's probably not so important for memory allocation cleanup but it
> > > would be a semantically useful change for the callbacks if we could
> > > arrange for them to happen only on final exit of the library -- exactly
> > > because of the difficulty of reasoning about things otherwise. Alas I
> > > can't think of a good way to do this since the ctx can be shared, thread
> > > local storage would be one or libxl__gc_owner could return a special
> > > "nested ctx" instead of the real outer ctx, but, ick.
> > 
> > I think that using TLS to increase/decrease a nesting counter would OK
> > in this case. We could have a libxl__enter and a libxl__exit function
> > that take care it this.
> > 
> > Modifying libxl__gc_owner could lead to errors because it doesn't handle
> > the case in which an externally visible function calls another
> > externally visible function: libxl__gc_owner wouldn't even be called in
> > this case.
> 
> I suggested to Ian the moral equivalent of:
> 
> #define CTX_LOCK \
>      <previous implementation> \
>      ctx->recursive_lock_counter++
> 
> #define GC_INIT \
>      CTX_LOCK; \
>      assert(ctx->recursive_lock_counter==1); \
>      CTX_UNLOCK
> 
> but I don't think this is really very nice.
> 
> 
> I think the answer is to write a comment saying that it is forbidden
> to allocate a new gc with the ctx locked.
 
Why not handle the case correctly in the first place?
It is certainly better than an assert or a comment, don't you think?
Ideally the code should be easy enough to understand without a comment.
This is what I have in mind:


diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index cd613f7..94bdbba 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -63,6 +63,12 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
      * only as an initialiser, not as an expression. */
     memcpy(&ctx->lock, &mutex_value, sizeof(ctx->lock));
 
+    if(pthread_key_create(&ctx->tls_key, NULL) < 0) {
+        LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, errno,
+            "cannot create tls key");
+        return ERROR_FAIL;
+    }
+
     if ( stat(XENSTORE_PID_FILE, &stat_buf) != 0 ) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "Is xenstore daemon running?\n"
                      "failed to stat %s", XENSTORE_PID_FILE);
diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c
index 34edaf3..eef3815 100644
--- a/tools/libxl/libxl_internal.c
+++ b/tools/libxl/libxl_internal.c
@@ -19,6 +19,7 @@
 #include <stdarg.h>
 #include <string.h>
 
+#include <pthread.h>
 #include <sys/types.h>
 #include <sys/stat.h>
 #include <fcntl.h>
@@ -65,17 +66,41 @@ int libxl__ptr_add(libxl__gc *gc, void *ptr)
     return 0;
 }
 
+libxl__gc *libxl__init_gc(libxl_ctx *ctx)
+{
+    libxl__gc *gc = (libxl__gc *) pthread_getspecific(ctx->tls_key);
+    if (gc == NULL) {
+        gc = (libxl__gc *) malloc(sizeof(libxl__gc));
+        if (gc == NULL)
+            return NULL;
+        gc->alloc_maxsize = 0;
+        gc->alloc_ptrs = 0;
+        gc->owner = ctx;
+        gc->nested = 1;
+        pthread_setspecific(ctx->tls_key, gc);
+    } else {
+        gc->nested++;
+    }
+    return gc;
+}
+
 void libxl__free_all(libxl__gc *gc)
 {
     void *ptr;
     int i;
 
+    gc->nested--;
+    if (gc->nested > 0)
+        return;
+
     for (i = 0; i < gc->alloc_maxsize; i++) {
         ptr = gc->alloc_ptrs[i];
         gc->alloc_ptrs[i] = NULL;
         free(ptr);
     }
     free(gc->alloc_ptrs);
+    pthread_setspecific(CTX->tls_key, NULL);
+    free(gc);
 }
 
 void *libxl__zalloc(libxl__gc *gc, int bytes)
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index b479c49..50e6b33 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -91,6 +91,8 @@ struct libxl__ctx {
     xc_interface *xch;
     struct xs_handle *xsh;
 
+    pthread_key_t tls_key;
+
     pthread_mutex_t lock; /* protects data structures hanging off the ctx */
       /* Always use CTX_LOCK and CTX_UNLOCK to manipulate this.
        *
@@ -138,9 +140,9 @@ typedef struct {
     int alloc_maxsize;
     void **alloc_ptrs;
     libxl_ctx *owner;
+    int nested;
 } libxl__gc;
 
-#define LIBXL_INIT_GC(ctx) (libxl__gc){ .alloc_maxsize = 0, .alloc_ptrs = 0, .owner = ctx }
 static inline libxl_ctx *libxl__gc_owner(libxl__gc *gc)
 {
     return gc->owner;
@@ -670,7 +672,8 @@ libxl__device_model_version_running(libxl__gc *gc, uint32_t domid);
  * as a local variable.
  */
 
-#define GC_INIT(ctx)  libxl__gc gc[1] = { LIBXL_INIT_GC(ctx) }
+_hidden libxl__gc *libxl__init_gc(struct libxl__ctx *ctx);
+#define GC_INIT(ctx)  libxl__gc *gc = libxl__init_gc(ctx); if (gc == NULL) return ERROR_NOMEM;
 #define GC_FREE       libxl__free_all(gc)
 #define CTX           libxl__gc_owner(gc)
 
---

I like this approach because it uses malloc for gc allocation so it can
be reused for your following patches that need a gc that lives out of
the function. This way we don't have two special cases but a single
approach that works everywhere and another comment that probably doesn't
need to be read anymore.
I also think that it makes the code easier to read and understand.

However in case you would like to see how would this patch look, keeping
the gc allocation on the stack, I have appended a version of it that
uses alloca instead of malloc.



P.S.
please note that the inline patch as it is doesn't compile because some libxl
function don't return an error but they return a pointer, something that
should be changed anyway.
--8323329-287492656-1323717865=:3517
Content-Type: text/plain; charset="US-ASCII"; name="2"
Content-Transfer-Encoding: BASE64
Content-ID: <alpine.DEB.2.00.1112121924200.3517@kaball-desktop>
Content-Description: 
Content-Disposition: attachment; filename="2"

ZGlmZiAtLWdpdCBhL3Rvb2xzL2xpYnhsL2xpYnhsLmMgYi90b29scy9saWJ4
bC9saWJ4bC5jDQppbmRleCBjZDYxM2Y3Li45NGJkYmJhIDEwMDY0NA0KLS0t
IGEvdG9vbHMvbGlieGwvbGlieGwuYw0KKysrIGIvdG9vbHMvbGlieGwvbGli
eGwuYw0KQEAgLTYzLDYgKzYzLDEyIEBAIGludCBsaWJ4bF9jdHhfYWxsb2Mo
bGlieGxfY3R4ICoqcGN0eCwgaW50IHZlcnNpb24sDQogICAgICAqIG9ubHkg
YXMgYW4gaW5pdGlhbGlzZXIsIG5vdCBhcyBhbiBleHByZXNzaW9uLiAqLw0K
ICAgICBtZW1jcHkoJmN0eC0+bG9jaywgJm11dGV4X3ZhbHVlLCBzaXplb2Yo
Y3R4LT5sb2NrKSk7DQogDQorICAgIGlmKHB0aHJlYWRfa2V5X2NyZWF0ZSgm
Y3R4LT50bHNfa2V5LCBOVUxMKSA8IDApIHsNCisgICAgICAgIExJQlhMX19M
T0dfRVJSTk9WQUwoY3R4LCBMSUJYTF9fTE9HX0VSUk9SLCBlcnJubywNCisg
ICAgICAgICAgICAiY2Fubm90IGNyZWF0ZSB0bHMga2V5Iik7DQorICAgICAg
ICByZXR1cm4gRVJST1JfRkFJTDsNCisgICAgfQ0KKw0KICAgICBpZiAoIHN0
YXQoWEVOU1RPUkVfUElEX0ZJTEUsICZzdGF0X2J1ZikgIT0gMCApIHsNCiAg
ICAgICAgIExJQlhMX19MT0dfRVJSTk8oY3R4LCBMSUJYTF9fTE9HX0VSUk9S
LCAiSXMgeGVuc3RvcmUgZGFlbW9uIHJ1bm5pbmc/XG4iDQogICAgICAgICAg
ICAgICAgICAgICAgImZhaWxlZCB0byBzdGF0ICVzIiwgWEVOU1RPUkVfUElE
X0ZJTEUpOw0KZGlmZiAtLWdpdCBhL3Rvb2xzL2xpYnhsL2xpYnhsX2ludGVy
bmFsLmMgYi90b29scy9saWJ4bC9saWJ4bF9pbnRlcm5hbC5jDQppbmRleCAz
NGVkYWYzLi44MTUwMjFkIDEwMDY0NA0KLS0tIGEvdG9vbHMvbGlieGwvbGli
eGxfaW50ZXJuYWwuYw0KKysrIGIvdG9vbHMvbGlieGwvbGlieGxfaW50ZXJu
YWwuYw0KQEAgLTE5LDYgKzE5LDcgQEANCiAjaW5jbHVkZSA8c3RkYXJnLmg+
DQogI2luY2x1ZGUgPHN0cmluZy5oPg0KIA0KKyNpbmNsdWRlIDxwdGhyZWFk
Lmg+DQogI2luY2x1ZGUgPHN5cy90eXBlcy5oPg0KICNpbmNsdWRlIDxzeXMv
c3RhdC5oPg0KICNpbmNsdWRlIDxmY250bC5oPg0KQEAgLTcwLDEyICs3MSwx
NyBAQCB2b2lkIGxpYnhsX19mcmVlX2FsbChsaWJ4bF9fZ2MgKmdjKQ0KICAg
ICB2b2lkICpwdHI7DQogICAgIGludCBpOw0KIA0KKyAgICBnYy0+bmVzdGVk
LS07DQorICAgIGlmIChnYy0+bmVzdGVkID4gMCkNCisgICAgICAgIHJldHVy
bjsNCisNCiAgICAgZm9yIChpID0gMDsgaSA8IGdjLT5hbGxvY19tYXhzaXpl
OyBpKyspIHsNCiAgICAgICAgIHB0ciA9IGdjLT5hbGxvY19wdHJzW2ldOw0K
ICAgICAgICAgZ2MtPmFsbG9jX3B0cnNbaV0gPSBOVUxMOw0KICAgICAgICAg
ZnJlZShwdHIpOw0KICAgICB9DQogICAgIGZyZWUoZ2MtPmFsbG9jX3B0cnMp
Ow0KKyAgICBwdGhyZWFkX3NldHNwZWNpZmljKENUWC0+dGxzX2tleSwgTlVM
TCk7DQogfQ0KIA0KIHZvaWQgKmxpYnhsX196YWxsb2MobGlieGxfX2djICpn
YywgaW50IGJ5dGVzKQ0KZGlmZiAtLWdpdCBhL3Rvb2xzL2xpYnhsL2xpYnhs
X2ludGVybmFsLmggYi90b29scy9saWJ4bC9saWJ4bF9pbnRlcm5hbC5oDQpp
bmRleCBiNDc5YzQ5Li42ZGFhNTExIDEwMDY0NA0KLS0tIGEvdG9vbHMvbGli
eGwvbGlieGxfaW50ZXJuYWwuaA0KKysrIGIvdG9vbHMvbGlieGwvbGlieGxf
aW50ZXJuYWwuaA0KQEAgLTkxLDYgKzkxLDggQEAgc3RydWN0IGxpYnhsX19j
dHggew0KICAgICB4Y19pbnRlcmZhY2UgKnhjaDsNCiAgICAgc3RydWN0IHhz
X2hhbmRsZSAqeHNoOw0KIA0KKyAgICBwdGhyZWFkX2tleV90IHRsc19rZXk7
DQorDQogICAgIHB0aHJlYWRfbXV0ZXhfdCBsb2NrOyAvKiBwcm90ZWN0cyBk
YXRhIHN0cnVjdHVyZXMgaGFuZ2luZyBvZmYgdGhlIGN0eCAqLw0KICAgICAg
IC8qIEFsd2F5cyB1c2UgQ1RYX0xPQ0sgYW5kIENUWF9VTkxPQ0sgdG8gbWFu
aXB1bGF0ZSB0aGlzLg0KICAgICAgICAqDQpAQCAtMTM4LDkgKzE0MCw5IEBA
IHR5cGVkZWYgc3RydWN0IHsNCiAgICAgaW50IGFsbG9jX21heHNpemU7DQog
ICAgIHZvaWQgKiphbGxvY19wdHJzOw0KICAgICBsaWJ4bF9jdHggKm93bmVy
Ow0KKyAgICBpbnQgbmVzdGVkOw0KIH0gbGlieGxfX2djOw0KIA0KLSNkZWZp
bmUgTElCWExfSU5JVF9HQyhjdHgpIChsaWJ4bF9fZ2MpeyAuYWxsb2NfbWF4
c2l6ZSA9IDAsIC5hbGxvY19wdHJzID0gMCwgLm93bmVyID0gY3R4IH0NCiBz
dGF0aWMgaW5saW5lIGxpYnhsX2N0eCAqbGlieGxfX2djX293bmVyKGxpYnhs
X19nYyAqZ2MpDQogew0KICAgICByZXR1cm4gZ2MtPm93bmVyOw0KQEAgLTY3
MCw3ICs2NzIsMTggQEAgbGlieGxfX2RldmljZV9tb2RlbF92ZXJzaW9uX3J1
bm5pbmcobGlieGxfX2djICpnYywgdWludDMyX3QgZG9taWQpOw0KICAqIGFz
IGEgbG9jYWwgdmFyaWFibGUuDQogICovDQogDQotI2RlZmluZSBHQ19JTklU
KGN0eCkgIGxpYnhsX19nYyBnY1sxXSA9IHsgTElCWExfSU5JVF9HQyhjdHgp
IH0NCisjZGVmaW5lIEdDX0lOSVQoY3R4KSBcDQorICAgIGxpYnhsX19nYyAq
Z2MgPSAobGlieGxfX2djICopIHB0aHJlYWRfZ2V0c3BlY2lmaWMoY3R4LT50
bHNfa2V5KTsgXA0KKyAgICBpZiAoZ2MgPT0gTlVMTCkgeyBcDQorICAgICAg
ICBnYyA9IChsaWJ4bF9fZ2MgKikgYWxsb2NhKHNpemVvZihsaWJ4bF9fZ2Mp
KTsgXA0KKyAgICAgICAgZ2MtPmFsbG9jX21heHNpemUgPSAwOyBcDQorICAg
ICAgICBnYy0+YWxsb2NfcHRycyA9IDA7IFwNCisgICAgICAgIGdjLT5vd25l
ciA9IGN0eDsgXA0KKyAgICAgICAgZ2MtPm5lc3RlZCA9IDE7IFwNCisgICAg
ICAgIHB0aHJlYWRfc2V0c3BlY2lmaWMoY3R4LT50bHNfa2V5LCBnYyk7IFwN
CisgICAgfSBlbHNlIHsgXA0KKyAgICAgICAgZ2MtPm5lc3RlZCsrOyBcDQor
ICAgIH0NCiAjZGVmaW5lIEdDX0ZSRUUgICAgICAgbGlieGxfX2ZyZWVfYWxs
KGdjKQ0KICNkZWZpbmUgQ1RYICAgICAgICAgICBsaWJ4bF9fZ2Nfb3duZXIo
Z2MpDQogDQo=

--8323329-287492656-1323717865=:3517
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--8323329-287492656-1323717865=:3517--


From xen-devel-bounces@lists.xensource.com Mon Dec 12 19:26:40 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 19: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.xensource.com>)
	id 1RaBVz-0001Xr-0t; Mon, 12 Dec 2011 19:26:19 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <amit.shah@redhat.com>) id 1RaBVy-0001Xi-2L
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 19:26:18 +0000
X-Env-Sender: amit.shah@redhat.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1323717923!8502545!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDYzMzI=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20583 invoked from network); 12 Dec 2011 19:25:24 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-2.tower-216.messagelabs.com with SMTP;
	12 Dec 2011 19:25:24 -0000
Received: from int-mx02.intmail.prod.int.phx2.redhat.com
	(int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id pBCJPBWp016349
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 12 Dec 2011 14:25:11 -0500
Received: from localhost (ovpn-113-167.phx2.redhat.com [10.3.113.167])
	by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP
	id pBCJP6Ga000349; Mon, 12 Dec 2011 14:25:07 -0500
Date: Tue, 13 Dec 2011 00:55:04 +0530
From: Amit Shah <amit.shah@redhat.com>
To: Miche Baker-Harvey <miche@google.com>
Message-ID: <20111212192504.GC6316@amit-x200.redhat.com>
References: <CAB8RdapbaueyWLJuJDE_ZdvLkRNM4sQHTxgmgO=jrnXZ6YPSmA@mail.gmail.com>
	<20111123103852.GG16665@amit-x200.redhat.com>
	<CAB8RdaoDxMCgTjuGP70bGrsrtgh=USYtU3Spo5OPtVMYAM5EzQ@mail.gmail.com>
	<20111129142149.GE2822@amit-x200.redhat.com>
	<CAB8RdapuPRym2dH_9mgmGdzpCxnP1KpS+hS8JJ-geVkga5fMcw@mail.gmail.com>
	<CAB8Rdapfuf5XH+X9gsUL+CJ9gTQcSNfq4Dj9DoYWQeFgD04ODQ@mail.gmail.com>
	<20111205105452.GB27683@amit-x200.redhat.com>
	<CAB8Rdar=qOokxZkjQVRmo=zN_f75jPwzU+6=WBRo0g+P7w+pAw@mail.gmail.com>
	<20111208120804.GF23531@amit-x200.redhat.com>
	<CAB8RdapDDV0kYW_uASpBoJ3hbx6zScKnG+LWWcjYtqMnqXN4Xw@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAB8RdapDDV0kYW_uASpBoJ3hbx6zScKnG+LWWcjYtqMnqXN4Xw@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.12
Cc: Stephen Rothwell <sfr@canb.auug.org.au>, xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Rusty Russell <rusty@rustcorp.com.au>, linux-kernel@vger.kernel.org,
	virtualization@lists.linux-foundation.org,
	Anton Blanchard <anton@samba.org>, Mike Waychison <mikew@google.com>,
	ppc-dev <linuxppc-dev@lists.ozlabs.org>,
	Greg Kroah-Hartman <gregkh@suse.de>, Eric Northrup <digitaleric@google.com>
Subject: Re: [Xen-devel] [PATCH v3 2/3] hvc_init(): Enforce one-time
	initialization.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On (Mon) 12 Dec 2011 [11:11:55], Miche Baker-Harvey wrote:
> So on a CONSOLE_PORT_ADD message, we would take the
> (existing)ports_device::ports_lock, and for other control messages we
> would justtake the (new) port::port_lock? =A0You are concerned that just
> takingthe ports_lock for all control messages could be too
> restrictive? =A0Iwouldn't have expected these messages to be frequent
> occurrences, butI'll defer to your experience here.

No, I mean we'll have to take the new port_lock() everywhere we
currently take the port lock, plus in a few more places.  I only
suggest using port_lock() helper since we'll need a dependency on the
portdev lock as well.

> The CONSOLE_CONSOLE_PORT message calls hvc_alloc, which also
> needsserialization. =A0That's in another one of these three patches; are
> youthinking we could leave that patch be, or that we would we use
> theport_lock for CONSOLE_CONSOLE_PORT? =A0Using the port_lock
> wouldprovide the HVC serialization "for free" but it would be cleaner
> if weput HVC related synchronization in hvc_console.c.

Yes, definitely, since other users of hvc_console may get bitten in
similar ways.  However, I'm not too familiar with the hvc code, the
people at linux-ppc can be of help.

> On Thu, Dec 8, 2011 at 4:08 AM, Amit Shah <amit.shah@redhat.com> wrote:
> > On (Tue) 06 Dec 2011 [09:05:38], Miche Baker-Harvey wrote:
> >> Amit,
> >>
> >> Ah, indeed. =A0I am not using MSI-X, so virtio_pci::vp_try_to_find_vqs=
()
> >> calls vp_request_intx() and sets up an interrupt callback. =A0From
> >> there, when an interrupt occurs, the stack looks something like this:
> >>
> >> virtio_pci::vp_interrupt()
> >> =A0 virtio_pci::vp_vring_interrupt()
> >> =A0 =A0 virtio_ring::vring_interrupt()
> >> =A0 =A0 =A0 vq->vq.callback() =A0<-- in this case, that's virtio_conso=
le::control_intr()
> >> =A0 =A0 =A0 =A0 workqueue::schedule_work()
> >> =A0 =A0 =A0 =A0 =A0 workqueue::queue_work()
> >> =A0 =A0 =A0 =A0 =A0 =A0 queue_work_on(get_cpu()) =A0<-- queues the wor=
k on the current CPU.
> >>
> >> I'm not doing anything to keep multiple control message from being
> >> sent concurrently to the guest, and we will take those interrupts on
> >> any CPU. I've confirmed that the two instances of
> >> handle_control_message() are occurring on different CPUs.
> >
> > So let's have a new helper, port_lock() that takes the port-specific
> > spinlock. =A0There has to be a new helper, since the port lock should
> > depend on the portdev lock being taken too. =A0For the port addition
> > case, just the portdev lock should be taken. =A0For any other
> > operations, the port lock should be taken.
> >
> > My assumption was that we would be able to serialise the work items,
> > but that will be too restrictive. =A0Taking port locks sounds like a
> > better idea.
> >
> > We'd definitely need the port lock in the control work handler. =A0We
> > might need it in a few more places (like module removal), but we'll
> > worry about that later.
> >
> > Does this sound fine?
> >
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Amit

		Amit

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 19:26:40 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 19: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.xensource.com>)
	id 1RaBVz-0001Xr-0t; Mon, 12 Dec 2011 19:26:19 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <amit.shah@redhat.com>) id 1RaBVy-0001Xi-2L
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 19:26:18 +0000
X-Env-Sender: amit.shah@redhat.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1323717923!8502545!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDYzMzI=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20583 invoked from network); 12 Dec 2011 19:25:24 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-2.tower-216.messagelabs.com with SMTP;
	12 Dec 2011 19:25:24 -0000
Received: from int-mx02.intmail.prod.int.phx2.redhat.com
	(int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id pBCJPBWp016349
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 12 Dec 2011 14:25:11 -0500
Received: from localhost (ovpn-113-167.phx2.redhat.com [10.3.113.167])
	by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP
	id pBCJP6Ga000349; Mon, 12 Dec 2011 14:25:07 -0500
Date: Tue, 13 Dec 2011 00:55:04 +0530
From: Amit Shah <amit.shah@redhat.com>
To: Miche Baker-Harvey <miche@google.com>
Message-ID: <20111212192504.GC6316@amit-x200.redhat.com>
References: <CAB8RdapbaueyWLJuJDE_ZdvLkRNM4sQHTxgmgO=jrnXZ6YPSmA@mail.gmail.com>
	<20111123103852.GG16665@amit-x200.redhat.com>
	<CAB8RdaoDxMCgTjuGP70bGrsrtgh=USYtU3Spo5OPtVMYAM5EzQ@mail.gmail.com>
	<20111129142149.GE2822@amit-x200.redhat.com>
	<CAB8RdapuPRym2dH_9mgmGdzpCxnP1KpS+hS8JJ-geVkga5fMcw@mail.gmail.com>
	<CAB8Rdapfuf5XH+X9gsUL+CJ9gTQcSNfq4Dj9DoYWQeFgD04ODQ@mail.gmail.com>
	<20111205105452.GB27683@amit-x200.redhat.com>
	<CAB8Rdar=qOokxZkjQVRmo=zN_f75jPwzU+6=WBRo0g+P7w+pAw@mail.gmail.com>
	<20111208120804.GF23531@amit-x200.redhat.com>
	<CAB8RdapDDV0kYW_uASpBoJ3hbx6zScKnG+LWWcjYtqMnqXN4Xw@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAB8RdapDDV0kYW_uASpBoJ3hbx6zScKnG+LWWcjYtqMnqXN4Xw@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.12
Cc: Stephen Rothwell <sfr@canb.auug.org.au>, xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Rusty Russell <rusty@rustcorp.com.au>, linux-kernel@vger.kernel.org,
	virtualization@lists.linux-foundation.org,
	Anton Blanchard <anton@samba.org>, Mike Waychison <mikew@google.com>,
	ppc-dev <linuxppc-dev@lists.ozlabs.org>,
	Greg Kroah-Hartman <gregkh@suse.de>, Eric Northrup <digitaleric@google.com>
Subject: Re: [Xen-devel] [PATCH v3 2/3] hvc_init(): Enforce one-time
	initialization.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On (Mon) 12 Dec 2011 [11:11:55], Miche Baker-Harvey wrote:
> So on a CONSOLE_PORT_ADD message, we would take the
> (existing)ports_device::ports_lock, and for other control messages we
> would justtake the (new) port::port_lock? =A0You are concerned that just
> takingthe ports_lock for all control messages could be too
> restrictive? =A0Iwouldn't have expected these messages to be frequent
> occurrences, butI'll defer to your experience here.

No, I mean we'll have to take the new port_lock() everywhere we
currently take the port lock, plus in a few more places.  I only
suggest using port_lock() helper since we'll need a dependency on the
portdev lock as well.

> The CONSOLE_CONSOLE_PORT message calls hvc_alloc, which also
> needsserialization. =A0That's in another one of these three patches; are
> youthinking we could leave that patch be, or that we would we use
> theport_lock for CONSOLE_CONSOLE_PORT? =A0Using the port_lock
> wouldprovide the HVC serialization "for free" but it would be cleaner
> if weput HVC related synchronization in hvc_console.c.

Yes, definitely, since other users of hvc_console may get bitten in
similar ways.  However, I'm not too familiar with the hvc code, the
people at linux-ppc can be of help.

> On Thu, Dec 8, 2011 at 4:08 AM, Amit Shah <amit.shah@redhat.com> wrote:
> > On (Tue) 06 Dec 2011 [09:05:38], Miche Baker-Harvey wrote:
> >> Amit,
> >>
> >> Ah, indeed. =A0I am not using MSI-X, so virtio_pci::vp_try_to_find_vqs=
()
> >> calls vp_request_intx() and sets up an interrupt callback. =A0From
> >> there, when an interrupt occurs, the stack looks something like this:
> >>
> >> virtio_pci::vp_interrupt()
> >> =A0 virtio_pci::vp_vring_interrupt()
> >> =A0 =A0 virtio_ring::vring_interrupt()
> >> =A0 =A0 =A0 vq->vq.callback() =A0<-- in this case, that's virtio_conso=
le::control_intr()
> >> =A0 =A0 =A0 =A0 workqueue::schedule_work()
> >> =A0 =A0 =A0 =A0 =A0 workqueue::queue_work()
> >> =A0 =A0 =A0 =A0 =A0 =A0 queue_work_on(get_cpu()) =A0<-- queues the wor=
k on the current CPU.
> >>
> >> I'm not doing anything to keep multiple control message from being
> >> sent concurrently to the guest, and we will take those interrupts on
> >> any CPU. I've confirmed that the two instances of
> >> handle_control_message() are occurring on different CPUs.
> >
> > So let's have a new helper, port_lock() that takes the port-specific
> > spinlock. =A0There has to be a new helper, since the port lock should
> > depend on the portdev lock being taken too. =A0For the port addition
> > case, just the portdev lock should be taken. =A0For any other
> > operations, the port lock should be taken.
> >
> > My assumption was that we would be able to serialise the work items,
> > but that will be too restrictive. =A0Taking port locks sounds like a
> > better idea.
> >
> > We'd definitely need the port lock in the control work handler. =A0We
> > might need it in a few more places (like module removal), but we'll
> > worry about that later.
> >
> > Does this sound fine?
> >
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Amit

		Amit

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 19:26:59 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 19: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.xensource.com>)
	id 1RaBWH-0001Z5-Eb; Mon, 12 Dec 2011 19:26:37 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RaBWF-0001Ym-SN
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 19:26:36 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1323717925!49214008!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDc4NQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28677 invoked from network); 12 Dec 2011 19:25:25 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Dec 2011 19:25:25 -0000
X-IronPort-AV: E=Sophos;i="4.71,340,1320624000"; 
   d="scan'208";a="9425995"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Dec 2011 19:24:42 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 12 Dec 2011 19:24:42 +0000
Date: Mon, 12 Dec 2011 19:26:09 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1323712001.20077.234.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1112121924520.3517@kaball-desktop>
References: <alpine.DEB.2.00.1111221551510.31179@kaball-desktop>
	<1322056320-5826-5-git-send-email-stefano.stabellini@eu.citrix.com>
	<20198.15417.932169.223332@mariner.uk.xensource.com>
	<1323712001.20077.234.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "Keir \(Xen.org\)" <keir@xen.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v9 5/6] Clone and build Seabios by default
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 12 Dec 2011, Ian Campbell wrote:
> On Mon, 2011-12-12 at 17:39 +0000, Ian Jackson wrote:
> > stefano.stabellini@eu.citrix.com writes ("[Xen-devel] [PATCH v9 5/6] Clone and build Seabios by default"):
> > >  QEMU_UPSTREAM_URL ?= http://xenbits.xensource.com/git-http/qemu-upstream-unstable.git
> > > +SEABIOS_UPSTREAM_URL ?= http://git.qemu.org/git/seabios.git
> > 
> > Do we wanted push-gated versions of these trees too ?
> > 
> > I see you have included a lockstep changeset number in xen-unstable
> > but are we really able to force these to update in lockstep ?
> 
> We should have a mirror on xenbits, we generally avoid reliance on third
> party resources in our builds. Not just source repositories but also for
> things like tarball downloads.
> 
> Also the upstream for seabios is git://git.seabios.org/seabios.git I
> don't think indirecting via qemu buys us anything.
 
I don't have a strong opinion on this, so if you'd like to change the
url to a xenbits tree, I am OK with that.
I guess you don't need me to send a patch for that, but let me know if
you want me to change something.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 19:26:59 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 19: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.xensource.com>)
	id 1RaBWH-0001Z5-Eb; Mon, 12 Dec 2011 19:26:37 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RaBWF-0001Ym-SN
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 19:26:36 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1323717925!49214008!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDc4NQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28677 invoked from network); 12 Dec 2011 19:25:25 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Dec 2011 19:25:25 -0000
X-IronPort-AV: E=Sophos;i="4.71,340,1320624000"; 
   d="scan'208";a="9425995"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Dec 2011 19:24:42 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 12 Dec 2011 19:24:42 +0000
Date: Mon, 12 Dec 2011 19:26:09 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1323712001.20077.234.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1112121924520.3517@kaball-desktop>
References: <alpine.DEB.2.00.1111221551510.31179@kaball-desktop>
	<1322056320-5826-5-git-send-email-stefano.stabellini@eu.citrix.com>
	<20198.15417.932169.223332@mariner.uk.xensource.com>
	<1323712001.20077.234.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "Keir \(Xen.org\)" <keir@xen.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v9 5/6] Clone and build Seabios by default
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 12 Dec 2011, Ian Campbell wrote:
> On Mon, 2011-12-12 at 17:39 +0000, Ian Jackson wrote:
> > stefano.stabellini@eu.citrix.com writes ("[Xen-devel] [PATCH v9 5/6] Clone and build Seabios by default"):
> > >  QEMU_UPSTREAM_URL ?= http://xenbits.xensource.com/git-http/qemu-upstream-unstable.git
> > > +SEABIOS_UPSTREAM_URL ?= http://git.qemu.org/git/seabios.git
> > 
> > Do we wanted push-gated versions of these trees too ?
> > 
> > I see you have included a lockstep changeset number in xen-unstable
> > but are we really able to force these to update in lockstep ?
> 
> We should have a mirror on xenbits, we generally avoid reliance on third
> party resources in our builds. Not just source repositories but also for
> things like tarball downloads.
> 
> Also the upstream for seabios is git://git.seabios.org/seabios.git I
> don't think indirecting via qemu buys us anything.
 
I don't have a strong opinion on this, so if you'd like to change the
url to a xenbits tree, I am OK with that.
I guess you don't need me to send a patch for that, but let me know if
you want me to change something.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 19:32:43 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 19: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.xensource.com>)
	id 1RaBbr-00022W-89; Mon, 12 Dec 2011 19:32:23 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RaBbp-00022F-HJ
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 19:32:21 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1323718286!7180072!1
X-Originating-IP: [209.85.210.43]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19280 invoked from network); 12 Dec 2011 19:31:28 -0000
Received: from mail-pz0-f43.google.com (HELO mail-pz0-f43.google.com)
	(209.85.210.43)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Dec 2011 19:31:28 -0000
Received: by daec6 with SMTP id c6so9778126dae.30
	for <xen-devel@lists.xensource.com>;
	Mon, 12 Dec 2011 11:31:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=N9CAtN4GLPnhry+gcfGmKqnOjYsAteI1JJZKTisIWjo=;
	b=vZ3R6PxgaS6RMhf8qDrRn3TEGAOeLxaDGZJhrzKdiuEC4b8qsGo8yAnF1a5PbU3Szq
	BV61YFj9lVuefiDSVrGirh/0S2ou2xsyemFEOYhZpMeSNUQth1ANnlrHFuUTTDC6oyuq
	DJ++TC+hatbZwwipOHxn/BEvidgyjwoV2PP1M=
MIME-Version: 1.0
Received: by 10.68.199.3 with SMTP id jg3mr36790907pbc.81.1323718285837; Mon,
	12 Dec 2011 11:31:25 -0800 (PST)
Received: by 10.142.47.17 with HTTP; Mon, 12 Dec 2011 11:31:25 -0800 (PST)
In-Reply-To: <20198.16898.814613.705263@mariner.uk.xensource.com>
References: <patchbomb.1322752087@loki.upc.es>
	<20198.16898.814613.705263@mariner.uk.xensource.com>
Date: Mon, 12 Dec 2011 20:31:25 +0100
X-Google-Sender-Auth: B0_lU9RsqiKGXKpCQP1gAC0GSPM
Message-ID: <CAPLaKK4qK1sZJ_d-ivjmfG8biABvgrxP9JdjCMfJex4iXoP7Xw@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 00 of 11 v3] libxl: add support for hotplug
 script calling from libxl
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

MjAxMS8xMi8xMiBJYW4gSmFja3NvbiA8SWFuLkphY2tzb25AZXUuY2l0cml4LmNvbT46Cj4gRllJ
IHRoaXMgaGFzIG5vdyBnb3QgdG8gdGhlIHRvcCBvZiBteSBsaXN0LiDCoEkgaG9wZSB0byBnaXZl
IGl0IHNvbWUKPiBzZXJpb3VzIHJldmlldyB0aW1lIHRvbW9ycm93LiDCoEluIHRoZSBtZWFudGlt
ZSwgaWYgeW91IGhhdmUgYW55IGZpbmFsCj4gdHdlYWtzLCBmZWVsIGZyZWUgdG8gc2VuZCBhbiB1
cGRhdGVkIHZlcnNpb24uCgpJIHdpbGwgdHJ5IHRvIHBvc3QgYW4gdXBkYXRlZCB2ZXJzaW9uIHRv
bW9ycm93IG1vcm5pbmcsIHRoYXQgYXBwbGllcwp0byB0aXAgd2l0aG91dCByZWplY3Rpb25zLiBJ
IGFsc28gaGF2ZSBhbm90aGVyIHNtYWxsZXIgc2VyaWVzIHBlbmRpbmcsCnRoZSBvbmUgYWJvdXQg
bGlieGwgbm90IGJlaW5nIGFibGUgdG8gZGVzdHJveSBhIGRvbWFpbiBjb3JyZWN0bHkgdW5kZXIK
TmV0QlNELiBJIHRoaW5rIGl0IHdpbGwgYmUgZ29vZCB0byBtZXJnZSB0aGUgdHdvIHNlcmllcywg
c2luY2UgdGhleQphcmUgcXVpdGUgcmVsYXRlZCAodGhlIGRlc3Ryb3kgaXNzdWUgaXMgcmVsYXRl
ZCB0byBsaWJ4bCBub3QgcmVtb3ZpbmcKZnJvbnRlbmQgZW50cmllcyBiZWZvcmUgYXR0ZW1wdGlu
ZyB0byBkZXN0cm95IHRoZSBkZXZpY2VzKS4KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3Rz
LnhlbnNvdXJjZS5jb20KaHR0cDovL2xpc3RzLnhlbnNvdXJjZS5jb20veGVuLWRldmVsCg==

From xen-devel-bounces@lists.xensource.com Mon Dec 12 19:32:43 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 19: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.xensource.com>)
	id 1RaBbr-00022W-89; Mon, 12 Dec 2011 19:32:23 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RaBbp-00022F-HJ
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 19:32:21 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1323718286!7180072!1
X-Originating-IP: [209.85.210.43]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19280 invoked from network); 12 Dec 2011 19:31:28 -0000
Received: from mail-pz0-f43.google.com (HELO mail-pz0-f43.google.com)
	(209.85.210.43)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Dec 2011 19:31:28 -0000
Received: by daec6 with SMTP id c6so9778126dae.30
	for <xen-devel@lists.xensource.com>;
	Mon, 12 Dec 2011 11:31:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=N9CAtN4GLPnhry+gcfGmKqnOjYsAteI1JJZKTisIWjo=;
	b=vZ3R6PxgaS6RMhf8qDrRn3TEGAOeLxaDGZJhrzKdiuEC4b8qsGo8yAnF1a5PbU3Szq
	BV61YFj9lVuefiDSVrGirh/0S2ou2xsyemFEOYhZpMeSNUQth1ANnlrHFuUTTDC6oyuq
	DJ++TC+hatbZwwipOHxn/BEvidgyjwoV2PP1M=
MIME-Version: 1.0
Received: by 10.68.199.3 with SMTP id jg3mr36790907pbc.81.1323718285837; Mon,
	12 Dec 2011 11:31:25 -0800 (PST)
Received: by 10.142.47.17 with HTTP; Mon, 12 Dec 2011 11:31:25 -0800 (PST)
In-Reply-To: <20198.16898.814613.705263@mariner.uk.xensource.com>
References: <patchbomb.1322752087@loki.upc.es>
	<20198.16898.814613.705263@mariner.uk.xensource.com>
Date: Mon, 12 Dec 2011 20:31:25 +0100
X-Google-Sender-Auth: B0_lU9RsqiKGXKpCQP1gAC0GSPM
Message-ID: <CAPLaKK4qK1sZJ_d-ivjmfG8biABvgrxP9JdjCMfJex4iXoP7Xw@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 00 of 11 v3] libxl: add support for hotplug
 script calling from libxl
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

MjAxMS8xMi8xMiBJYW4gSmFja3NvbiA8SWFuLkphY2tzb25AZXUuY2l0cml4LmNvbT46Cj4gRllJ
IHRoaXMgaGFzIG5vdyBnb3QgdG8gdGhlIHRvcCBvZiBteSBsaXN0LiDCoEkgaG9wZSB0byBnaXZl
IGl0IHNvbWUKPiBzZXJpb3VzIHJldmlldyB0aW1lIHRvbW9ycm93LiDCoEluIHRoZSBtZWFudGlt
ZSwgaWYgeW91IGhhdmUgYW55IGZpbmFsCj4gdHdlYWtzLCBmZWVsIGZyZWUgdG8gc2VuZCBhbiB1
cGRhdGVkIHZlcnNpb24uCgpJIHdpbGwgdHJ5IHRvIHBvc3QgYW4gdXBkYXRlZCB2ZXJzaW9uIHRv
bW9ycm93IG1vcm5pbmcsIHRoYXQgYXBwbGllcwp0byB0aXAgd2l0aG91dCByZWplY3Rpb25zLiBJ
IGFsc28gaGF2ZSBhbm90aGVyIHNtYWxsZXIgc2VyaWVzIHBlbmRpbmcsCnRoZSBvbmUgYWJvdXQg
bGlieGwgbm90IGJlaW5nIGFibGUgdG8gZGVzdHJveSBhIGRvbWFpbiBjb3JyZWN0bHkgdW5kZXIK
TmV0QlNELiBJIHRoaW5rIGl0IHdpbGwgYmUgZ29vZCB0byBtZXJnZSB0aGUgdHdvIHNlcmllcywg
c2luY2UgdGhleQphcmUgcXVpdGUgcmVsYXRlZCAodGhlIGRlc3Ryb3kgaXNzdWUgaXMgcmVsYXRl
ZCB0byBsaWJ4bCBub3QgcmVtb3ZpbmcKZnJvbnRlbmQgZW50cmllcyBiZWZvcmUgYXR0ZW1wdGlu
ZyB0byBkZXN0cm95IHRoZSBkZXZpY2VzKS4KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3Rz
LnhlbnNvdXJjZS5jb20KaHR0cDovL2xpc3RzLnhlbnNvdXJjZS5jb20veGVuLWRldmVsCg==

From xen-devel-bounces@lists.xensource.com Mon Dec 12 21:45:47 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 21:45:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaDgH-0003Qd-5c; Mon, 12 Dec 2011 21:45:05 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <it@niemail.de>) id 1RaDgF-0003QV-Bt
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 21:45:03 +0000
X-Env-Sender: it@niemail.de
X-Msg-Ref: server-5.tower-174.messagelabs.com!1323726249!5275732!1
X-Originating-IP: [80.252.97.80]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuMjUyLjk3LjgwID0+IDIyMjUw\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 726 invoked from network); 12 Dec 2011 21:44:10 -0000
Received: from mailout.artfiles.de (HELO mailout.artfiles.de) (80.252.97.80)
	by server-5.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Dec 2011 21:44:10 -0000
Received: from [80.252.98.156] (helo=tim-everss-macbook-pro.local)
	auth=te@artfiles.de by mailout.artfiles.de with esmtpa (Exim 4.72)
	id 1RaDfM-0000wl-PG
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 22:44:08 +0100
Message-ID: <4EE675A8.3030609@niemail.de>
Date: Mon, 12 Dec 2011 22:44:08 +0100
From: Tim Evers <it@niemail.de>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6;
	rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] a ton of kernel issues
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi folks,

please forgive me if I'm not 100% right on this list but I'm going mad
about the current xen development as far as the pv_ops kernel are
involved. I've been using Xen since 3.0 in various productive setups
without any serious problems for years now.

And now, since the support for the "patched" distro-kernel like debian 5
run out I'm trying to setup a working xen+pv_ops kernel with regard to
cpu and ram hotplug and live migration. Nothing special I thought but
hell I'm totally lost: After testing two month now dozens of
combinations I was not able to find a single kernel / xen combination
which supports the abovementioned features. Some crash after hotplug on
a migrated domu, some crash right at the migration and some crash right
at the start if vcpu_avail > vcpus.

I've tested

xen-4.0
xen-4.1

debian 6 32 and 64 bit (2.6.32-x kernel)
ubuntu lucid 32 and 64 bit kernels including karmic, natty and even
oneric backports

I've put some questions on the users mailinglist, wrote bug reports but
today after two month work on this I'm as stuck as one can get.

Is it possible that there is not a single working xen+pv_ops setup out
there which matches my needs? I can't believe it.

I appreciate _any_ hint!

Regards

Tim

http://lists.xen.org/archives/html/xen-users/2011-11/msg00553.html
http://lists.xen.org/archives/html/xen-users/2011-11/msg00523.html
http://lists.xen.org/archives/html/xen-users/2011-11/msg00295.html
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/893177

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 21:45:47 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 21:45:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaDgH-0003Qd-5c; Mon, 12 Dec 2011 21:45:05 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <it@niemail.de>) id 1RaDgF-0003QV-Bt
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 21:45:03 +0000
X-Env-Sender: it@niemail.de
X-Msg-Ref: server-5.tower-174.messagelabs.com!1323726249!5275732!1
X-Originating-IP: [80.252.97.80]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuMjUyLjk3LjgwID0+IDIyMjUw\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 726 invoked from network); 12 Dec 2011 21:44:10 -0000
Received: from mailout.artfiles.de (HELO mailout.artfiles.de) (80.252.97.80)
	by server-5.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Dec 2011 21:44:10 -0000
Received: from [80.252.98.156] (helo=tim-everss-macbook-pro.local)
	auth=te@artfiles.de by mailout.artfiles.de with esmtpa (Exim 4.72)
	id 1RaDfM-0000wl-PG
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 22:44:08 +0100
Message-ID: <4EE675A8.3030609@niemail.de>
Date: Mon, 12 Dec 2011 22:44:08 +0100
From: Tim Evers <it@niemail.de>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6;
	rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] a ton of kernel issues
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi folks,

please forgive me if I'm not 100% right on this list but I'm going mad
about the current xen development as far as the pv_ops kernel are
involved. I've been using Xen since 3.0 in various productive setups
without any serious problems for years now.

And now, since the support for the "patched" distro-kernel like debian 5
run out I'm trying to setup a working xen+pv_ops kernel with regard to
cpu and ram hotplug and live migration. Nothing special I thought but
hell I'm totally lost: After testing two month now dozens of
combinations I was not able to find a single kernel / xen combination
which supports the abovementioned features. Some crash after hotplug on
a migrated domu, some crash right at the migration and some crash right
at the start if vcpu_avail > vcpus.

I've tested

xen-4.0
xen-4.1

debian 6 32 and 64 bit (2.6.32-x kernel)
ubuntu lucid 32 and 64 bit kernels including karmic, natty and even
oneric backports

I've put some questions on the users mailinglist, wrote bug reports but
today after two month work on this I'm as stuck as one can get.

Is it possible that there is not a single working xen+pv_ops setup out
there which matches my needs? I can't believe it.

I appreciate _any_ hint!

Regards

Tim

http://lists.xen.org/archives/html/xen-users/2011-11/msg00553.html
http://lists.xen.org/archives/html/xen-users/2011-11/msg00523.html
http://lists.xen.org/archives/html/xen-users/2011-11/msg00295.html
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/893177

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 21:58:30 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 21: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.xensource.com>)
	id 1RaDse-0003bK-I8; Mon, 12 Dec 2011 21:57:52 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1RaDsc-0003bF-Iv
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 21:57:50 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-3.tower-174.messagelabs.com!1323727014!5211727!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.1 required=7.0 tests=BODY_VIRGIN
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7388 invoked from network); 12 Dec 2011 21:56:55 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-3.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 12 Dec 2011 21:56:55 -0000
Received: from andromeda.dapyr.net (darnok@localhost [127.0.0.1])
	by andromeda.dapyr.net (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id
	pBCLurnQ012760
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Mon, 12 Dec 2011 16:56:53 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pBCLuqix012758;
	Mon, 12 Dec 2011 16:56:52 -0500
Date: Mon, 12 Dec 2011 17:56:52 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Tim Evers <it@niemail.de>
Message-ID: <20111212215652.GA12106@andromeda.dapyr.net>
References: <4EE675A8.3030609@niemail.de>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4EE675A8.3030609@niemail.de>
User-Agent: Mutt/1.5.9i
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] a ton of kernel issues
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Dec 12, 2011 at 10:44:08PM +0100, Tim Evers wrote:
> Hi folks,
> 
> please forgive me if I'm not 100% right on this list but I'm going mad
> about the current xen development as far as the pv_ops kernel are
> involved. I've been using Xen since 3.0 in various productive setups
> without any serious problems for years now.
> 
> And now, since the support for the "patched" distro-kernel like debian 5
> run out I'm trying to setup a working xen+pv_ops kernel with regard to
> cpu and ram hotplug and live migration. Nothing special I thought but
> hell I'm totally lost: After testing two month now dozens of
> combinations I was not able to find a single kernel / xen combination
> which supports the abovementioned features. Some crash after hotplug on

Did you try the latest and greatest? Meaning anything that is based on a
3.0 (or higher) kernel?

> a migrated domu, some crash right at the migration and some crash right
> at the start if vcpu_avail > vcpus.

Is this with more than 32 CPUs?

> 
> I've tested
> 
> xen-4.0
> xen-4.1
> 
> debian 6 32 and 64 bit (2.6.32-x kernel)
> ubuntu lucid 32 and 64 bit kernels including karmic, natty and even
> oneric backports

backports? Why not just .

Looking at your BUG, did you look in the .config to see if you
had MAXSMP or NR_CPUS defined? If you had MAXSMP, there was a bug
for that fixed in 2.6.39 time-frame (I think). And if you look
at the NR_CPUS, do you see the NR_CPUs > 0 virtual_cpus?


Otherwise, does the virgin kernel boot if you specify maxvcpus=vcpus
and then later on use xm to take CPUs away?


> 
> I've put some questions on the users mailinglist, wrote bug reports but
> today after two month work on this I'm as stuck as one can get.

Uh? Hm somehow we [kernel engineers] never got copied on it.
> 
> Is it possible that there is not a single working xen+pv_ops setup out
> there which matches my needs? I can't believe it.
> I appreciate _any_ hint!
> 
> Regards
> 
> Tim
> 
> http://lists.xen.org/archives/html/xen-users/2011-11/msg00553.html
> http://lists.xen.org/archives/html/xen-users/2011-11/msg00523.html
> http://lists.xen.org/archives/html/xen-users/2011-11/msg00295.html
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/893177

OK, so it says it brought 8 CPUs on .. and then it crashes afterwards.
So is that kernel compiled with CONFIG_NR_CPUS=8 or some higher value?

> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 21:58:30 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 21: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.xensource.com>)
	id 1RaDse-0003bK-I8; Mon, 12 Dec 2011 21:57:52 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1RaDsc-0003bF-Iv
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 21:57:50 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-3.tower-174.messagelabs.com!1323727014!5211727!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.1 required=7.0 tests=BODY_VIRGIN
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7388 invoked from network); 12 Dec 2011 21:56:55 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-3.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 12 Dec 2011 21:56:55 -0000
Received: from andromeda.dapyr.net (darnok@localhost [127.0.0.1])
	by andromeda.dapyr.net (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id
	pBCLurnQ012760
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Mon, 12 Dec 2011 16:56:53 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pBCLuqix012758;
	Mon, 12 Dec 2011 16:56:52 -0500
Date: Mon, 12 Dec 2011 17:56:52 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Tim Evers <it@niemail.de>
Message-ID: <20111212215652.GA12106@andromeda.dapyr.net>
References: <4EE675A8.3030609@niemail.de>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4EE675A8.3030609@niemail.de>
User-Agent: Mutt/1.5.9i
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] a ton of kernel issues
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Dec 12, 2011 at 10:44:08PM +0100, Tim Evers wrote:
> Hi folks,
> 
> please forgive me if I'm not 100% right on this list but I'm going mad
> about the current xen development as far as the pv_ops kernel are
> involved. I've been using Xen since 3.0 in various productive setups
> without any serious problems for years now.
> 
> And now, since the support for the "patched" distro-kernel like debian 5
> run out I'm trying to setup a working xen+pv_ops kernel with regard to
> cpu and ram hotplug and live migration. Nothing special I thought but
> hell I'm totally lost: After testing two month now dozens of
> combinations I was not able to find a single kernel / xen combination
> which supports the abovementioned features. Some crash after hotplug on

Did you try the latest and greatest? Meaning anything that is based on a
3.0 (or higher) kernel?

> a migrated domu, some crash right at the migration and some crash right
> at the start if vcpu_avail > vcpus.

Is this with more than 32 CPUs?

> 
> I've tested
> 
> xen-4.0
> xen-4.1
> 
> debian 6 32 and 64 bit (2.6.32-x kernel)
> ubuntu lucid 32 and 64 bit kernels including karmic, natty and even
> oneric backports

backports? Why not just .

Looking at your BUG, did you look in the .config to see if you
had MAXSMP or NR_CPUS defined? If you had MAXSMP, there was a bug
for that fixed in 2.6.39 time-frame (I think). And if you look
at the NR_CPUS, do you see the NR_CPUs > 0 virtual_cpus?


Otherwise, does the virgin kernel boot if you specify maxvcpus=vcpus
and then later on use xm to take CPUs away?


> 
> I've put some questions on the users mailinglist, wrote bug reports but
> today after two month work on this I'm as stuck as one can get.

Uh? Hm somehow we [kernel engineers] never got copied on it.
> 
> Is it possible that there is not a single working xen+pv_ops setup out
> there which matches my needs? I can't believe it.
> I appreciate _any_ hint!
> 
> Regards
> 
> Tim
> 
> http://lists.xen.org/archives/html/xen-users/2011-11/msg00553.html
> http://lists.xen.org/archives/html/xen-users/2011-11/msg00523.html
> http://lists.xen.org/archives/html/xen-users/2011-11/msg00295.html
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/893177

OK, so it says it brought 8 CPUs on .. and then it crashes afterwards.
So is that kernel compiled with CONFIG_NR_CPUS=8 or some higher value?

> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 21:59:03 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 21:59:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaDtL-0003cz-07; Mon, 12 Dec 2011 21:58:35 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1RaDtK-0003cU-67
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 21:58:34 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-14.tower-182.messagelabs.com!1323727059!6944433!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 821 invoked from network); 12 Dec 2011 21:57:40 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-14.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 12 Dec 2011 21:57:40 -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
	pBCLvbab012790
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Mon, 12 Dec 2011 16:57:37 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pBCLvbGb012788;
	Mon, 12 Dec 2011 16:57:37 -0500
Date: Mon, 12 Dec 2011 17:57:37 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Nupur Ghatnekar <nupurghatnekar@gmail.com>
Message-ID: <20111212215737.GB12106@andromeda.dapyr.net>
References: <CAO8_4VrOwdsWDjRvHM9-zytJ1qefhR=5FJ94Pvr9nA9LVDdH5Q@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAO8_4VrOwdsWDjRvHM9-zytJ1qefhR=5FJ94Pvr9nA9LVDdH5Q@mail.gmail.com>
User-Agent: Mutt/1.5.9i
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Drivers (backend/frontend drivers) for "Hello World
	"
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Dec 13, 2011 at 12:06:41AM +0530, Nupur Ghatnekar wrote:
> Hello,
> 
> I want to write a small module which can help me transfer a string between
> dom0 and domU.
> A small "hello world" program. wherein, whatever the Dom0 writes is printed
> in DomU.
> 
> can you suggest me a way to tackle this. I am new to the environment.
> Perhaps an example can help me understand the flow of events.

I would recommend you use the libvchan library and use that as mechanism
for transferring said string.
> 
> Regards,
> Nupur
> -- 
> 
> Nupur Ghatnekar

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 21:59:03 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 21:59:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaDtL-0003cz-07; Mon, 12 Dec 2011 21:58:35 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1RaDtK-0003cU-67
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 21:58:34 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-14.tower-182.messagelabs.com!1323727059!6944433!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 821 invoked from network); 12 Dec 2011 21:57:40 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-14.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 12 Dec 2011 21:57:40 -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
	pBCLvbab012790
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Mon, 12 Dec 2011 16:57:37 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pBCLvbGb012788;
	Mon, 12 Dec 2011 16:57:37 -0500
Date: Mon, 12 Dec 2011 17:57:37 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Nupur Ghatnekar <nupurghatnekar@gmail.com>
Message-ID: <20111212215737.GB12106@andromeda.dapyr.net>
References: <CAO8_4VrOwdsWDjRvHM9-zytJ1qefhR=5FJ94Pvr9nA9LVDdH5Q@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAO8_4VrOwdsWDjRvHM9-zytJ1qefhR=5FJ94Pvr9nA9LVDdH5Q@mail.gmail.com>
User-Agent: Mutt/1.5.9i
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Drivers (backend/frontend drivers) for "Hello World
	"
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Dec 13, 2011 at 12:06:41AM +0530, Nupur Ghatnekar wrote:
> Hello,
> 
> I want to write a small module which can help me transfer a string between
> dom0 and domU.
> A small "hello world" program. wherein, whatever the Dom0 writes is printed
> in DomU.
> 
> can you suggest me a way to tackle this. I am new to the environment.
> Perhaps an example can help me understand the flow of events.

I would recommend you use the libvchan library and use that as mechanism
for transferring said string.
> 
> Regards,
> Nupur
> -- 
> 
> Nupur Ghatnekar

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 22:01:40 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 22:01:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaDvr-0003r8-In; Mon, 12 Dec 2011 22:01:11 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1RaDvq-0003qs-KK
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 22:01:10 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-11.tower-21.messagelabs.com!1323727215!7576336!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3222 invoked from network); 12 Dec 2011 22:00:16 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-11.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 12 Dec 2011 22:00:16 -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
	pBCM0EP6013065
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Mon, 12 Dec 2011 17:00:14 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pBCM0EnU013063;
	Mon, 12 Dec 2011 17:00:14 -0500
Date: Mon, 12 Dec 2011 18:00:14 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: svenvan svenvan <svenvan.van@gmail.com>
Message-ID: <20111212220013.GC12106@andromeda.dapyr.net>
References: <CAJmQyTik==F8PuR+j3SVRjxQQ_aVLjHeBZdboekD3iOVRR9Y0A@mail.gmail.com>
	<CAJmQyThnnRjvuHBzB-2P43FvHOu8=C8dkD_0yYGLFew3HnoAXg@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAJmQyThnnRjvuHBzB-2P43FvHOu8=C8dkD_0yYGLFew3HnoAXg@mail.gmail.com>
User-Agent: Mutt/1.5.9i
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] xen 4.0.1/w 2.6.32 swapper: page allocation failure
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Sun, Dec 11, 2011 at 06:21:52PM +0100, svenvan svenvan wrote:
> 2011/12/5 svenvan svenvan <svenvan.van@gmail.com>
> 
> > hi
> > xen 4.0.1 w/2.6.32.41
> >
> > Last week dom0 experienced an hard crash and box need to be restarted
> > manually (despite kernel.panic=20).
> > Serial console was not setup, only netconsole.  No relevant entries
> > through netconsole, but analyzing logs I see some crashes twenty minutes
> > before fatal hang.
> >
> >
> Browsing archive I found a reply from  Konrad Rzeszutek about something
> similar:
> http://old-list-archives.xen.org/archives/html/xen-devel/2011-09/msg00600.html
> 
> Someone can confirm if it's the same issue or not?  Konrad maybe?

You would get much more traction if you CC-ed me.

Anyhow, no idea - 2.6.32-41 is a bit ancient and this thread does not
seem to have relevant data (such as serial console for examples, or the
"some crashes").

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 22:01:40 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 22:01:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaDvr-0003r8-In; Mon, 12 Dec 2011 22:01:11 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1RaDvq-0003qs-KK
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 22:01:10 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-11.tower-21.messagelabs.com!1323727215!7576336!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3222 invoked from network); 12 Dec 2011 22:00:16 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-11.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 12 Dec 2011 22:00:16 -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
	pBCM0EP6013065
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Mon, 12 Dec 2011 17:00:14 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pBCM0EnU013063;
	Mon, 12 Dec 2011 17:00:14 -0500
Date: Mon, 12 Dec 2011 18:00:14 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: svenvan svenvan <svenvan.van@gmail.com>
Message-ID: <20111212220013.GC12106@andromeda.dapyr.net>
References: <CAJmQyTik==F8PuR+j3SVRjxQQ_aVLjHeBZdboekD3iOVRR9Y0A@mail.gmail.com>
	<CAJmQyThnnRjvuHBzB-2P43FvHOu8=C8dkD_0yYGLFew3HnoAXg@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAJmQyThnnRjvuHBzB-2P43FvHOu8=C8dkD_0yYGLFew3HnoAXg@mail.gmail.com>
User-Agent: Mutt/1.5.9i
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] xen 4.0.1/w 2.6.32 swapper: page allocation failure
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Sun, Dec 11, 2011 at 06:21:52PM +0100, svenvan svenvan wrote:
> 2011/12/5 svenvan svenvan <svenvan.van@gmail.com>
> 
> > hi
> > xen 4.0.1 w/2.6.32.41
> >
> > Last week dom0 experienced an hard crash and box need to be restarted
> > manually (despite kernel.panic=20).
> > Serial console was not setup, only netconsole.  No relevant entries
> > through netconsole, but analyzing logs I see some crashes twenty minutes
> > before fatal hang.
> >
> >
> Browsing archive I found a reply from  Konrad Rzeszutek about something
> similar:
> http://old-list-archives.xen.org/archives/html/xen-devel/2011-09/msg00600.html
> 
> Someone can confirm if it's the same issue or not?  Konrad maybe?

You would get much more traction if you CC-ed me.

Anyhow, no idea - 2.6.32-41 is a bit ancient and this thread does not
seem to have relevant data (such as serial console for examples, or the
"some crashes").

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 22:12:45 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 22:12:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaE6g-0004Ej-Od; Mon, 12 Dec 2011 22:12:22 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Neal.Taylor@ca.com>) id 1RaE6e-0004EY-Dm
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 22:12:21 +0000
X-Env-Sender: Neal.Taylor@ca.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1323727882!5070800!1
X-Originating-IP: [74.125.149.76]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10826 invoked from network); 12 Dec 2011 22:11:25 -0000
Received: from na3sys009aob106.obsmtp.com (HELO na3sys009aog106.obsmtp.com)
	(74.125.149.76)
	by server-14.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 12 Dec 2011 22:11:25 -0000
Received: from USILMS190.ca.com ([141.202.246.44]) (using TLSv1) by
	na3sys009aob106.postini.com ([74.125.148.12]) with SMTP
	ID DSNKTuZ8CvFuwF/UlYpfg9Qmk1XIS569J1RG@postini.com;
	Mon, 12 Dec 2011 14:11:24 PST
Received: from USILMS173.ca.com (141.202.6.23) by USILMS190.ca.com
	(141.202.246.44) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Mon, 12 Dec 2011 17:11:21 -0500
Received: from USILMS110A.ca.com ([169.254.1.109]) by usilms173.ca.com
	([141.202.6.23]) with mapi id 14.01.0289.001;
	Mon, 12 Dec 2011 17:11:21 -0500
From: "Taylor, Neal E" <Neal.Taylor@ca.com>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
Thread-Topic: [Xen-devel] Buffers not reachable by PCI
Thread-Index: Acy2r+Ulg1PsfbmtTl6QVj0jZAx7mwAK1xcAAIXl/sA=
Date: Mon, 12 Dec 2011 22:11:20 +0000
Message-ID: <3E243B26F475504B9BB0BCC9728B0DA629E17AEA@USILMS110A.ca.com>
References: <3E243B26F475504B9BB0BCC9728B0DA629E16E01@USILMS110A.ca.com>
	<20111209203010.GA14412@andromeda.dapyr.net>
In-Reply-To: <20111209203010.GA14412@andromeda.dapyr.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [138.42.46.105]
Content-Type: multipart/mixed;
	boundary="_002_3E243B26F475504B9BB0BCC9728B0DA629E17AEAUSILMS110Acacom_"
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>, "Kalev,
	Leonid" <Leonid.Kalev@ca.com>, "Dave, Tushar N" <tushar.n.dave@intel.com>
Subject: Re: [Xen-devel] Buffers not reachable by PCI
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--_002_3E243B26F475504B9BB0BCC9728B0DA629E17AEAUSILMS110Acacom_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

We're having trouble getting a serial log. Are there other ways to capture =
the information you need?

Attached is a dmesg with 'debug loglevel 8' set on the kernel line... actua=
lly, with =20

   #define DEFAULT_MESSAGE_LOGLEVEL 8

set near the top of printk.c as well, since I wasn't seeing any difference =
in the log files with loglevel set to 8.

Neal

-----Original Message-----
From: Konrad Rzeszutek Wilk [mailto:konrad@darnok.org]=20
Sent: Friday, December 09, 2011 12:30 PM
To: Taylor, Neal E
Cc: xen-devel; Kalev, Leonid; Dave, Tushar N
Subject: Re: [Xen-devel] Buffers not reachable by PCI

On Fri, Dec 09, 2011 at 08:19:47PM +0000, Taylor, Neal E wrote:
> We're running 64-bit Xex 4.1.1 and 32-bit Linux 3.0.4 Dom0 (Linux 3.1 sho=
ws the same symptom.)

Hm, 32-bit. Did it work if the Dom0 was 64-bit?
>=20
> Several PCI drivers are unable to use DMA. Most fallback to using PIO but=
 in two instances the network drivers (e1000 and pcinet32) abort. The same =
kernel running on the same hardware without Xen works fine.
>=20
> Digging through the code, in swiotlb-xen.c I find "DMA_BIT_MASK(32)" (0x0=
0000000ffffffff) compared to "xen_virt_to_bus(xen_io_tlb_end - 1)" which re=
solves to 0x1,20fd,feff. Since the address is larger than the mask, DMA is =
declared as unsupportable.

<blinks>

xen_io_tlb_end resolved to 120fdfeff? That is a definite bug. Can you
attach you full bootup serial log with 'debug loglevel=3D8' parameters on
the Linux line please?



> In talking with others I hear Linux handles this situation with bounce bu=
ffers. Is there a config setting I've missed to enable that for Xen? (Confi=
g file attached)

The Xen SWIOTLB is by default enabled, so it is on, but the
xen_virt_to_bus(xen_io_tlb_end - 1) _MUST_ never be above 4GB. In your
case it is, which is bad. It is rather surprising as I had not seen this
ever happen.

--_002_3E243B26F475504B9BB0BCC9728B0DA629E17AEAUSILMS110Acacom_
Content-Type: application/octet-stream; name="dmesg-log8.3"
Content-Description: dmesg-log8.3
Content-Disposition: attachment; filename="dmesg-log8.3"; size=45419;
	creation-date="Mon, 12 Dec 2011 22:10:04 GMT";
	modification-date="Mon, 12 Dec 2011 20:34:19 GMT"
Content-Transfer-Encoding: base64

WyAgICAwLjAwMDAwMF0gUmVzZXJ2aW5nIHZpcnR1YWwgYWRkcmVzcyBzcGFjZSBhYm92ZSAweGZm
ODAwMDAwClsgICAgMC4wMDAwMDBdIExpbnV4IHZlcnNpb24gMy4wLjQtMzYueGVuMCAocm9vdEBu
dC1kZXYtQ2VudDU1LTMyKSAoZ2NjIHZlcnNpb24gNC4xLjIgMjAwODA3MDQgKFJlZCBIYXQgNC4x
LjItNDgpKSAjMSBTTVAgTW9uIERlYyAxMiAxNDo1NDozOSBFU1QgMjAxMQpbICAgIDAuMDAwMDAw
XSByZWxlYXNlZCAwIHBhZ2VzIG9mIHVudXNlZCBtZW1vcnkKWyAgICAwLjAwMDAwMF0gMS0xIG1h
cHBpbmcgb24gYTAtPjEwMApbICAgIDAuMDAwMDAwXSAxLTEgbWFwcGluZyBvbiBiZmZjMC0+MTAw
MDAwClsgICAgMC4wMDAwMDBdIFNldCAyNjIzMDQgcGFnZShzKSB0byAxLTEgbWFwcGluZy4KWyAg
ICAwLjAwMDAwMF0gQklPUy1wcm92aWRlZCBwaHlzaWNhbCBSQU0gbWFwOgpbICAgIDAuMDAwMDAw
XSAgWGVuOiAwMDAwMDAwMDAwMDAwMDAwIC0gMDAwMDAwMDAwMDBhMDAwMCAodXNhYmxlKQpbICAg
IDAuMDAwMDAwXSAgWGVuOiAwMDAwMDAwMDAwMGEwMDAwIC0gMDAwMDAwMDAwMDEwMDAwMCAocmVz
ZXJ2ZWQpClsgICAgMC4wMDAwMDBdICBYZW46IDAwMDAwMDAwMDAxMDAwMDAgLSAwMDAwMDAwMDIw
MDAwMDAwICh1c2FibGUpClsgICAgMC4wMDAwMDBdICBYZW46IDAwMDAwMDAwMjAwMDAwMDAgLSAw
MDAwMDAwMGJmZmMwMDAwICh1bnVzYWJsZSkKWyAgICAwLjAwMDAwMF0gIFhlbjogMDAwMDAwMDBi
ZmZjMDAwMCAtIDAwMDAwMDAwYmZmY2ZjMDAgKEFDUEkgZGF0YSkKWyAgICAwLjAwMDAwMF0gIFhl
bjogMDAwMDAwMDBiZmZjZmMwMCAtIDAwMDAwMDAwYmZmZmYwMDAgKHJlc2VydmVkKQpbICAgIDAu
MDAwMDAwXSAgWGVuOiAwMDAwMDAwMGUwMDAwMDAwIC0gMDAwMDAwMDBmZWM5MDAwMCAocmVzZXJ2
ZWQpClsgICAgMC4wMDAwMDBdICBYZW46IDAwMDAwMDAwZmVkMDAwMDAgLSAwMDAwMDAwMGZlZDAw
NDAwIChyZXNlcnZlZCkKWyAgICAwLjAwMDAwMF0gIFhlbjogMDAwMDAwMDBmZWUwMDAwMCAtIDAw
MDAwMDAwZmVlMTAwMDAgKHJlc2VydmVkKQpbICAgIDAuMDAwMDAwXSAgWGVuOiAwMDAwMDAwMGZm
YjAwMDAwIC0gMDAwMDAwMDEwMDAwMDAwMCAocmVzZXJ2ZWQpClsgICAgMC4wMDAwMDBdICBYZW46
IDAwMDAwMDAxMDAwMDAwMDAgLSAwMDAwMDAwMWRmZmMwMDAwICh1c2FibGUpClsgICAgMC4wMDAw
MDBdIE5YIChFeGVjdXRlIERpc2FibGUpIHByb3RlY3Rpb246IGFjdGl2ZQpbICAgIDAuMDAwMDAw
XSBETUkgMi4zIHByZXNlbnQuClsgICAgMC4wMDAwMDBdIERNSTogRGVsbCBDb21wdXRlciBDb3Jw
b3JhdGlvbiBQb3dlckVkZ2UgMTg1MC8wUkMxMzAsIEJJT1MgQTA1IDAxLzA5LzIwMDYKWyAgICAw
LjAwMDAwMF0gZTgyMCB1cGRhdGUgcmFuZ2U6IDAwMDAwMDAwMDAwMDAwMDAgLSAwMDAwMDAwMDAw
MDEwMDAwICh1c2FibGUpID09PiAocmVzZXJ2ZWQpClsgICAgMC4wMDAwMDBdIGU4MjAgcmVtb3Zl
IHJhbmdlOiAwMDAwMDAwMDAwMGEwMDAwIC0gMDAwMDAwMDAwMDEwMDAwMCAodXNhYmxlKQpbICAg
IDAuMDAwMDAwXSBsYXN0X3BmbiA9IDB4MWRmZmMwIG1heF9hcmNoX3BmbiA9IDB4MTAwMDAwMApb
ICAgIDAuMDAwMDAwXSBmb3VuZCBTTVAgTVAtdGFibGUgYXQgW2MwMGZlNzEwXSBmZTcxMApbICAg
IDAuMDAwMDAwXSBpbml0aWFsIG1lbW9yeSBtYXBwZWQgOiAwIC0gMDIzZmYwMDAKWyAgICAwLjAw
MDAwMF0gQmFzZSBtZW1vcnkgdHJhbXBvbGluZSBhdCBbYzAwOWYwMDBdIDlmMDAwIHNpemUgNDA5
NgpbICAgIDAuMDAwMDAwXSBpbml0X21lbW9yeV9tYXBwaW5nOiAwMDAwMDAwMDAwMDAwMDAwLTAw
MDAwMDAwMzczZmUwMDAKWyAgICAwLjAwMDAwMF0gIDAwMDAwMDAwMDAgLSAwMDM3M2ZlMDAwIHBh
Z2UgNGsKWyAgICAwLjAwMDAwMF0ga2VybmVsIGRpcmVjdCBtYXBwaW5nIHRhYmxlcyB1cCB0byAz
NzNmZTAwMCBAIDIyNDIwMDAtMjNmZjAwMApbICAgIDAuMDAwMDAwXSB4ZW46IHNldHRpbmcgUlcg
dGhlIHJhbmdlIDIzZWEwMDAgLSAyM2ZmMDAwClsgICAgMC4wMDAwMDBdIFJBTURJU0s6IDAxNmZi
MDAwIC0gMDFhYjIwMDAKWyAgICAwLjAwMDAwMF0gQUNQSTogUlNEUCAwMDBmZDViMCAwMDAxNCAo
djAwIERFTEwgICkKWyAgICAwLjAwMDAwMF0gQUNQSTogUlNEVCAwMDBmZDVjNCAwMDAzOCAodjAx
IERFTEwgICBQRSBCS0MgICAwMDAwMDAwMSBNU0ZUIDAxMDAwMDBBKQpbICAgIDAuMDAwMDAwXSBB
Q1BJOiBGQUNQIDAwMGZkNjIwIDAwMDc0ICh2MDEgREVMTCAgIFBFIEJLQyAgIDAwMDAwMDAxIE1T
RlQgMDEwMDAwMEEpClsgICAgMC4wMDAwMDBdIEFDUEk6IERTRFQgYmZmYzAwMDAgMDNDQ0QgKHYw
MSBERUxMICAgUEUgQktDICAgMDAwMDAwMDEgTVNGVCAwMTAwMDAwRSkKWyAgICAwLjAwMDAwMF0g
QUNQSTogRkFDUyBiZmZjZmMwMCAwMDA0MApbICAgIDAuMDAwMDAwXSBBQ1BJOiBBUElDIDAwMGZk
Njk0IDAwMEQ0ICh2MDEgREVMTCAgIFBFIEJLQyAgIDAwMDAwMDAxIE1TRlQgMDEwMDAwMEEpClsg
ICAgMC4wMDAwMDBdIEFDUEk6IFNQQ1IgMDAwZmQ3NzQgMDAwNTAgKHYwMSBERUxMICAgUEUgQktD
ICAgMDAwMDAwMDEgTVNGVCAwMTAwMDAwQSkKWyAgICAwLjAwMDAwMF0gQUNQSTogSFBFVCAwMDBm
ZDdjNCAwMDAzOCAodjAxIERFTEwgICBQRSBCS0MgICAwMDAwMDAwMSBNU0ZUIDAxMDAwMDBBKQpb
ICAgIDAuMDAwMDAwXSBBQ1BJOiBNQ0ZHIDAwMGZkN2ZjIDAwMDNDICh2MDEgREVMTCAgIFBFIEJL
QyAgIDAwMDAwMDAxIE1TRlQgMDEwMDAwMEEpClsgICAgMC4wMDAwMDBdIEFDUEk6IExvY2FsIEFQ
SUMgYWRkcmVzcyAweGZlZTAwMDAwClsgICAgMC4wMDAwMDBdIDY3OTVNQiBISUdITUVNIGF2YWls
YWJsZS4KWyAgICAwLjAwMDAwMF0gODgzTUIgTE9XTUVNIGF2YWlsYWJsZS4KWyAgICAwLjAwMDAw
MF0gICBtYXBwZWQgbG93IHJhbTogMCAtIDM3M2ZlMDAwClsgICAgMC4wMDAwMDBdICAgbG93IHJh
bTogMCAtIDM3M2ZlMDAwClsgICAgMC4wMDAwMDBdIFpvbmUgUEZOIHJhbmdlczoKWyAgICAwLjAw
MDAwMF0gICBETUEgICAgICAweDAwMDAwMDEwIC0+IDB4MDAwMDEwMDAKWyAgICAwLjAwMDAwMF0g
ICBOb3JtYWwgICAweDAwMDAxMDAwIC0+IDB4MDAwMzczZmUKWyAgICAwLjAwMDAwMF0gICBIaWdo
TWVtICAweDAwMDM3M2ZlIC0+IDB4MDAxZGZmYzAKWyAgICAwLjAwMDAwMF0gTW92YWJsZSB6b25l
IHN0YXJ0IFBGTiBmb3IgZWFjaCBub2RlClsgICAgMC4wMDAwMDBdIGVhcmx5X25vZGVfbWFwWzNd
IGFjdGl2ZSBQRk4gcmFuZ2VzClsgICAgMC4wMDAwMDBdICAgICAwOiAweDAwMDAwMDEwIC0+IDB4
MDAwMDAwYTAKWyAgICAwLjAwMDAwMF0gICAgIDA6IDB4MDAwMDAxMDAgLT4gMHgwMDAyMDAwMApb
ICAgIDAuMDAwMDAwXSAgICAgMDogMHgwMDEwMDAwMCAtPiAweDAwMWRmZmMwClsgICAgMC4wMDAw
MDBdIE9uIG5vZGUgMCB0b3RhbHBhZ2VzOiAxMDQ4NDAwClsgICAgMC4wMDAwMDBdIGZyZWVfYXJl
YV9pbml0X25vZGU6IG5vZGUgMCwgcGdkYXQgYzEzNmViMDAsIG5vZGVfbWVtX21hcCBkYzNmZjIw
MApbICAgIDAuMDAwMDAwXSAgIERNQSB6b25lOiAzMiBwYWdlcyB1c2VkIGZvciBtZW1tYXAKWyAg
ICAwLjAwMDAwMF0gICBETUEgem9uZTogMCBwYWdlcyByZXNlcnZlZApbICAgIDAuMDAwMDAwXSAg
IERNQSB6b25lOiAzOTUyIHBhZ2VzLCBMSUZPIGJhdGNoOjAKWyAgICAwLjAwMDAwMF0gICBOb3Jt
YWwgem9uZTogMTczNiBwYWdlcyB1c2VkIGZvciBtZW1tYXAKWyAgICAwLjAwMDAwMF0gICBOb3Jt
YWwgem9uZTogMTI1MjQwIHBhZ2VzLCBMSUZPIGJhdGNoOjMxClsgICAgMC4wMDAwMDBdICAgSGln
aE1lbSB6b25lOiAxMzU5MiBwYWdlcyB1c2VkIGZvciBtZW1tYXAKWyAgICAwLjAwMDAwMF0gICBI
aWdoTWVtIHpvbmU6IDkwMzg0OCBwYWdlcywgTElGTyBiYXRjaDozMQpbICAgIDAuMDAwMDAwXSBV
c2luZyBBUElDIGRyaXZlciBkZWZhdWx0ClsgICAgMC4wMDAwMDBdIEFDUEk6IFBNLVRpbWVyIElP
IFBvcnQ6IDB4ODA4ClsgICAgMC4wMDAwMDBdIEFDUEk6IExvY2FsIEFQSUMgYWRkcmVzcyAweGZl
ZTAwMDAwClsgICAgMC4wMDAwMDBdIEFDUEk6IExBUElDIChhY3BpX2lkWzB4MDFdIGxhcGljX2lk
WzB4MDBdIGVuYWJsZWQpClsgICAgMC4wMDAwMDBdIEJJT1MgYnVnOiBBUElDIHZlcnNpb24gaXMg
MCBmb3IgQ1BVIDAvMHgwLCBmaXhpbmcgdXAgdG8gMHgxMApbICAgIDAuMDAwMDAwXSBBQ1BJOiBM
QVBJQyAoYWNwaV9pZFsweDAyXSBsYXBpY19pZFsweDA2XSBlbmFibGVkKQpbICAgIDAuMDAwMDAw
XSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDAzXSBsYXBpY19pZFsweDAxXSBlbmFibGVkKQpbICAg
IDAuMDAwMDAwXSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDA0XSBsYXBpY19pZFsweDA3XSBlbmFi
bGVkKQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDA1XSBsYXBpY19pZFsw
eDAyXSBkaXNhYmxlZCkKWyAgICAwLjAwMDAwMF0gQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwNl0g
bGFwaWNfaWRbMHgwNF0gZGlzYWJsZWQpClsgICAgMC4wMDAwMDBdIEFDUEk6IExBUElDIChhY3Bp
X2lkWzB4MDddIGxhcGljX2lkWzB4MDNdIGRpc2FibGVkKQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBM
QVBJQyAoYWNwaV9pZFsweDA4XSBsYXBpY19pZFsweDA1XSBkaXNhYmxlZCkKWyAgICAwLjAwMDAw
MF0gQUNQSTogTEFQSUNfTk1JIChhY3BpX2lkWzB4MDFdIGhpZ2ggZWRnZSBsaW50WzB4MV0pClsg
ICAgMC4wMDAwMDBdIEFDUEk6IExBUElDX05NSSAoYWNwaV9pZFsweDAyXSBoaWdoIGVkZ2UgbGlu
dFsweDFdKQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJQ19OTUkgKGFjcGlfaWRbMHgwM10gaGln
aCBlZGdlIGxpbnRbMHgxXSkKWyAgICAwLjAwMDAwMF0gQUNQSTogTEFQSUNfTk1JIChhY3BpX2lk
WzB4MDRdIGhpZ2ggZWRnZSBsaW50WzB4MV0pClsgICAgMC4wMDAwMDBdIEFDUEk6IExBUElDX05N
SSAoYWNwaV9pZFsweDA1XSBoaWdoIGVkZ2UgbGludFsweDFdKQpbICAgIDAuMDAwMDAwXSBBQ1BJ
OiBMQVBJQ19OTUkgKGFjcGlfaWRbMHgwNl0gaGlnaCBlZGdlIGxpbnRbMHgxXSkKWyAgICAwLjAw
MDAwMF0gQUNQSTogTEFQSUNfTk1JIChhY3BpX2lkWzB4MDddIGhpZ2ggZWRnZSBsaW50WzB4MV0p
ClsgICAgMC4wMDAwMDBdIEFDUEk6IExBUElDX05NSSAoYWNwaV9pZFsweDA4XSBoaWdoIGVkZ2Ug
bGludFsweDFdKQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBJT0FQSUMgKGlkWzB4MDhdIGFkZHJlc3Nb
MHhmZWMwMDAwMF0gZ3NpX2Jhc2VbMF0pClsgICAgMC4wMDAwMDBdIElPQVBJQ1swXTogYXBpY19p
ZCA4LCB2ZXJzaW9uIDI1NSwgYWRkcmVzcyAweGZlYzAwMDAwLCBHU0kgMC0yNTUKWyAgICAwLjAw
MDAwMF0gQUNQSTogSU9BUElDIChpZFsweDA5XSBhZGRyZXNzWzB4ZmVjODAwMDBdIGdzaV9iYXNl
WzMyXSkKWyAgICAwLjAwMDAwMF0gSU9BUElDWzFdOiBhcGljX2lkIDksIHZlcnNpb24gMjU1LCBh
ZGRyZXNzIDB4ZmVjODAwMDAsIEdTSSAzMi0yODcKWyAgICAwLjAwMDAwMF0gQUNQSTogSU9BUElD
IChpZFsweDBhXSBhZGRyZXNzWzB4ZmVjODMwMDBdIGdzaV9iYXNlWzY0XSkKWyAgICAwLjAwMDAw
MF0gSU9BUElDWzJdOiBhcGljX2lkIDEwLCB2ZXJzaW9uIDI1NSwgYWRkcmVzcyAweGZlYzgzMDAw
LCBHU0kgNjQtMzE5ClsgICAgMC4wMDAwMDBdIEFDUEk6IElOVF9TUkNfT1ZSIChidXMgMCBidXNf
aXJxIDAgZ2xvYmFsX2lycSAyIGRmbCBkZmwpClsgICAgMC4wMDAwMDBdIEFDUEk6IElOVF9TUkNf
T1ZSIChidXMgMCBidXNfaXJxIDkgZ2xvYmFsX2lycSA5IGhpZ2ggbGV2ZWwpClsgICAgMC4wMDAw
MDBdIEFDUEk6IElSUTAgdXNlZCBieSBvdmVycmlkZS4KWyAgICAwLjAwMDAwMF0gQUNQSTogSVJR
MiB1c2VkIGJ5IG92ZXJyaWRlLgpbICAgIDAuMDAwMDAwXSBBQ1BJOiBJUlE5IHVzZWQgYnkgb3Zl
cnJpZGUuClsgICAgMC4wMDAwMDBdIFVzaW5nIEFDUEkgKE1BRFQpIGZvciBTTVAgY29uZmlndXJh
dGlvbiBpbmZvcm1hdGlvbgpbICAgIDAuMDAwMDAwXSBTTVA6IEFsbG93aW5nIDggQ1BVcywgNCBo
b3RwbHVnIENQVXMKWyAgICAwLjAwMDAwMF0gbnJfaXJxc19nc2k6IDMzNgpbICAgIDAuMDAwMDAw
XSBBbGxvY2F0aW5nIFBDSSByZXNvdXJjZXMgc3RhcnRpbmcgYXQgYmZmZmYwMDAgKGdhcDogYmZm
ZmYwMDA6MjAwMDEwMDApClsgICAgMC4wMDAwMDBdIEJvb3RpbmcgcGFyYXZpcnR1YWxpemVkIGtl
cm5lbCBvbiBYZW4KWyAgICAwLjAwMDAwMF0gWGVuIHZlcnNpb246IDQuMS4xIChwcmVzZXJ2ZS1B
RCkKWyAgICAwLjAwMDAwMF0gc2V0dXBfcGVyY3B1OiBOUl9DUFVTOjggbnJfY3B1bWFza19iaXRz
OjggbnJfY3B1X2lkczo4IG5yX25vZGVfaWRzOjEKWyAgICAwLjAwMDAwMF0gUEVSQ1BVOiBFbWJl
ZGRlZCAxMiBwYWdlcy9jcHUgQGRjMzhkMDAwIHMyNzEzNiByMCBkMjIwMTYgdTQ5MTUyClsgICAg
MC4wMDAwMDBdIHBjcHUtYWxsb2M6IHMyNzEzNiByMCBkMjIwMTYgdTQ5MTUyIGFsbG9jPTEyKjQw
OTYKWyAgICAwLjAwMDAwMF0gcGNwdS1hbGxvYzogWzBdIDAgWzBdIDEgWzBdIDIgWzBdIDMgWzBd
IDQgWzBdIDUgWzBdIDYgWzBdIDcgClsgICAgMC4wMDAwMDBdIEJ1aWx0IDEgem9uZWxpc3RzIGlu
IFpvbmUgb3JkZXIsIG1vYmlsaXR5IGdyb3VwaW5nIG9uLiAgVG90YWwgcGFnZXM6IDEwMzMwNDAK
WyAgICAwLjAwMDAwMF0gS2VybmVsIGNvbW1hbmQgbGluZTogbm91c2IgIHJvb3Q9TEFCRUw9L21u
dC9hcGxib290MSBzZWxpbnV4PTAgIG1heF9sb29wPTI1NiBkZWJ1ZyBsb2dsZXZlbD04ClsgICAg
MC4wMDAwMDBdIFBJRCBoYXNoIHRhYmxlIGVudHJpZXM6IDIwNDggKG9yZGVyOiAxLCA4MTkyIGJ5
dGVzKQpbICAgIDAuMDAwMDAwXSBEZW50cnkgY2FjaGUgaGFzaCB0YWJsZSBlbnRyaWVzOiA2NTUz
NiAob3JkZXI6IDYsIDI2MjE0NCBieXRlcykKWyAgICAwLjAwMDAwMF0gSW5vZGUtY2FjaGUgaGFz
aCB0YWJsZSBlbnRyaWVzOiAzMjc2OCAob3JkZXI6IDUsIDEzMTA3MiBieXRlcykKWyAgICAwLjAw
MDAwMF0gSW5pdGlhbGl6aW5nIENQVSMwClsgICAgMC4wMDAwMDBdIFBsYWNpbmcgNjRNQiBzb2Z0
d2FyZSBJTyBUTEIgYmV0d2VlbiBkODMyY2YwMCAtIGRjMzJjZjAwClsgICAgMC4wMDAwMDBdIHNv
ZnR3YXJlIElPIFRMQiBhdCBwaHlzIDB4MTgzMmNmMDAgLSAweDFjMzJjZjAwClsgICAgMC4wMDAw
MDBdIEluaXRpYWxpemluZyBIaWdoTWVtIGZvciBub2RlIDAgKDAwMDM3M2ZlOjAwMWRmZmMwKQpb
ICAgIDAuMDAwMDAwXSBNZW1vcnk6IDM4NDgwNGsvNzg2NDA2NGsgYXZhaWxhYmxlICgyMzM4ayBr
ZXJuZWwgY29kZSwgMTM5MDM2ayByZXNlcnZlZCwgMTE5N2sgZGF0YSwgMzcyayBpbml0LCAwayBo
aWdobWVtKQpbICAgIDAuMDAwMDAwXSB2aXJ0dWFsIGtlcm5lbCBtZW1vcnkgbGF5b3V0OgpbICAg
IDAuMDAwMDAwXSAgICAgZml4bWFwICA6IDB4ZmY3MTYwMDAgLSAweGZmN2ZmMDAwICAgKCA5MzIg
a0IpClsgICAgMC4wMDAwMDBdICAgICBwa21hcCAgIDogMHhmZjQwMDAwMCAtIDB4ZmY2MDAwMDAg
ICAoMjA0OCBrQikKWyAgICAwLjAwMDAwMF0gICAgIHZtYWxsb2MgOiAweGY3YmZlMDAwIC0gMHhm
ZjNmZTAwMCAgICggMTIwIE1CKQpbICAgIDAuMDAwMDAwXSAgICAgbG93bWVtICA6IDB4YzAwMDAw
MDAgLSAweGY3M2ZlMDAwICAgKCA4ODMgTUIpClsgICAgMC4wMDAwMDBdICAgICAgIC5pbml0IDog
MHhjMTM3NDAwMCAtIDB4YzEzZDEwMDAgICAoIDM3MiBrQikKWyAgICAwLjAwMDAwMF0gICAgICAg
LmRhdGEgOiAweGMxMjQ4ODI1IC0gMHhjMTM3NDAwMCAgICgxMTk3IGtCKQpbICAgIDAuMDAwMDAw
XSAgICAgICAudGV4dCA6IDB4YzEwMDAwMDAgLSAweGMxMjQ4ODI1ICAgKDIzMzgga0IpClsgICAg
MC4wMDAwMDBdIEhpZXJhcmNoaWNhbCBSQ1UgaW1wbGVtZW50YXRpb24uClsgICAgMC4wMDAwMDBd
IE5SX0lSUVM6MjU2MApbICAgIDAuMDAwMDAwXSBDUFUgMCBpcnFzdGFja3MsIGhhcmQ9ZDdjMTAw
MDAgc29mdD1kN2MxMjAwMApbICAgIDAuMDAwMDAwXSB4ZW46IHNjaSBvdmVycmlkZTogZ2xvYmFs
X2lycT05IHRyaWdnZXI9MCBwb2xhcml0eT0wClsgICAgMC4wMDAwMDBdIHhlbjogcmVnaXN0ZXJp
bmcgZ3NpIDkgdHJpZ2dlcmluZyAwIHBvbGFyaXR5IDAKWyAgICAwLjAwMDAwMF0geGVuOiAtLT4g
cGlycT05IC0+IGlycT05IChnc2k9OSkKWyAgICAwLjAwMDAwMF0geGVuOiBhY3BpIHNjaSA5Clsg
ICAgMC4wMDAwMDBdIHhlbjogLS0+IHBpcnE9MSAtPiBpcnE9MSAoZ3NpPTEpClsgICAgMC4wMDAw
MDBdIHhlbjogLS0+IHBpcnE9MiAtPiBpcnE9MiAoZ3NpPTIpClsgICAgMC4wMDAwMDBdIHhlbjog
LS0+IHBpcnE9MyAtPiBpcnE9MyAoZ3NpPTMpClsgICAgMC4wMDAwMDBdIHhlbjogLS0+IHBpcnE9
NCAtPiBpcnE9NCAoZ3NpPTQpClsgICAgMC4wMDAwMDBdIHhlbjogLS0+IHBpcnE9NSAtPiBpcnE9
NSAoZ3NpPTUpClsgICAgMC4wMDAwMDBdIHhlbjogLS0+IHBpcnE9NiAtPiBpcnE9NiAoZ3NpPTYp
ClsgICAgMC4wMDAwMDBdIHhlbjogLS0+IHBpcnE9NyAtPiBpcnE9NyAoZ3NpPTcpClsgICAgMC4w
MDAwMDBdIHhlbjogLS0+IHBpcnE9OCAtPiBpcnE9OCAoZ3NpPTgpClsgICAgMC4wMDAwMDBdIHhl
bl9tYXBfcGlycV9nc2k6IHJldHVybmluZyBpcnEgOSBmb3IgZ3NpIDkKWyAgICAwLjAwMDAwMF0g
eGVuOiAtLT4gcGlycT05IC0+IGlycT05IChnc2k9OSkKWyAgICAwLjAwMDAwMF0geGVuOiAtLT4g
cGlycT0xMCAtPiBpcnE9MTAgKGdzaT0xMCkKWyAgICAwLjAwMDAwMF0geGVuOiAtLT4gcGlycT0x
MSAtPiBpcnE9MTEgKGdzaT0xMSkKWyAgICAwLjAwMDAwMF0geGVuOiAtLT4gcGlycT0xMiAtPiBp
cnE9MTIgKGdzaT0xMikKWyAgICAwLjAwMDAwMF0geGVuOiAtLT4gcGlycT0xMyAtPiBpcnE9MTMg
KGdzaT0xMykKWyAgICAwLjAwMDAwMF0geGVuOiAtLT4gcGlycT0xNCAtPiBpcnE9MTQgKGdzaT0x
NCkKWyAgICAwLjAwMDAwMF0geGVuOiAtLT4gcGlycT0xNSAtPiBpcnE9MTUgKGdzaT0xNSkKWyAg
ICAwLjAwMDAwMF0gQ29uc29sZTogY29sb3VyIFZHQSsgODB4MjUKWyAgICAwLjAwMDAwMF0gY29u
c29sZSBbdHR5MF0gZW5hYmxlZApbICAgIDAuMDAwMDAwXSBYZW46IHVzaW5nIHZjcHVvcCB0aW1l
ciBpbnRlcmZhY2UKWyAgICAwLjAwMDAwMF0gaW5zdGFsbGluZyBYZW4gdGltZXIgZm9yIENQVSAw
ClsgICAgMC4wMDAwMDBdIERldGVjdGVkIDI5OTIuODI4IE1IeiBwcm9jZXNzb3IuClsgICAgMC4w
MTAwMDBdIENhbGlicmF0aW5nIGRlbGF5IGxvb3AgKHNraXBwZWQpLCB2YWx1ZSBjYWxjdWxhdGVk
IHVzaW5nIHRpbWVyIGZyZXF1ZW5jeS4uIDU5ODUuNjUgQm9nb01JUFMgKGxwaj0yOTkyODI4MCkK
WyAgICAwLjAxMDAwMF0gcGlkX21heDogZGVmYXVsdDogMzI3NjggbWluaW11bTogMzAxClsgICAg
MC4wMTAwMDBdIE1vdW50LWNhY2hlIGhhc2ggdGFibGUgZW50cmllczogNTEyClsgICAgMC4wMTAw
MDBdIENQVTogUGh5c2ljYWwgUHJvY2Vzc29yIElEOiAwClsgICAgMC4wMTAwMDBdIENQVTogUHJv
Y2Vzc29yIENvcmUgSUQ6IDAKWyAgICAwLjAxMDAwMF0gQUNQSTogQ29yZSByZXZpc2lvbiAyMDEx
MDQxMwpbICAgIDAuMDE1MTQ3XSBQZXJmb3JtYW5jZSBFdmVudHM6IHVuc3VwcG9ydGVkIE5ldGJ1
cnN0IENQVSBtb2RlbCA0IG5vIFBNVSBkcml2ZXIsIHNvZnR3YXJlIGV2ZW50cyBvbmx5LgpbICAg
IDAuMDE1ODkyXSBDUFUgMSBpcnFzdGFja3MsIGhhcmQ9ZDdjODAwMDAgc29mdD1kN2M4MjAwMApb
ICAgIDAuMDE1OTg2XSBpbnN0YWxsaW5nIFhlbiB0aW1lciBmb3IgQ1BVIDEKWyAgICAwLjAxMDAw
MF0gSW5pdGlhbGl6aW5nIENQVSMxClsgICAgMC4wMTY1NDVdIENQVSAyIGlycXN0YWNrcywgaGFy
ZD1kN2M4YzAwMCBzb2Z0PWQ3YzhlMDAwClsgICAgMC4wMTY3MjJdIGluc3RhbGxpbmcgWGVuIHRp
bWVyIGZvciBDUFUgMgpbICAgIDAuMDEwMDAwXSBJbml0aWFsaXppbmcgQ1BVIzIKWyAgICAwLjAx
NzI4OF0gQ1BVIDMgaXJxc3RhY2tzLCBoYXJkPWQ3Y2JhMDAwIHNvZnQ9ZDdjYmMwMDAKWyAgICAw
LjAxNzQ2NV0gaW5zdGFsbGluZyBYZW4gdGltZXIgZm9yIENQVSAzClsgICAgMC4wMTAwMDBdIElu
aXRpYWxpemluZyBDUFUjMwpbICAgIDAuMDE3NzY2XSBCcm91Z2h0IHVwIDQgQ1BVcwpbICAgIDAu
MDE4MTU3XSBHcmFudCB0YWJsZSBpbml0aWFsaXplZApbICAgIDAuMDE4MTU3XSBORVQ6IFJlZ2lz
dGVyZWQgcHJvdG9jb2wgZmFtaWx5IDE2ClsgICAgMC4wMjAxODddIEFDUEk6IGJ1cyB0eXBlIHBj
aSByZWdpc3RlcmVkClsgICAgMC4wMjA1MzddIFBDSTogTU1DT05GSUcgZm9yIGRvbWFpbiAwMDAw
IFtidXMgMDAtZmZdIGF0IFttZW0gMHhlMDAwMDAwMC0weGVmZmZmZmZmXSAoYmFzZSAweGUwMDAw
MDAwKQpbICAgIDAuMDIwNjQ5XSBQQ0k6IEludGVsIENvcnBvcmF0aW9uIEU3NTIwIE1lbW9yeSBD
b250cm9sbGVyIEh1YiB3aXRoIE1NQ09ORklHIHN1cHBvcnQKWyAgICAwLjAyMDc3NF0gUENJOiBN
TUNPTkZJRyBhdCBbbWVtIDB4ZTAwMDAwMDAtMHhlZmZmZmZmZl0gcmVzZXJ2ZWQgaW4gRTgyMApb
ICAgIDAuMDIwODY4XSBQQ0k6IFVzaW5nIE1NQ09ORklHIGZvciBleHRlbmRlZCBjb25maWcgc3Bh
Y2UKWyAgICAwLjAyMDk2MF0gUENJOiBVc2luZyBjb25maWd1cmF0aW9uIHR5cGUgMSBmb3IgYmFz
ZSBhY2Nlc3MKWyAgICAwLjAyMjIyOV0gYmlvOiBjcmVhdGUgc2xhYiA8YmlvLTA+IGF0IDAKWyAg
ICAwLjAyNDMwOF0gQUNQSTogRUM6IExvb2sgdXAgRUMgaW4gRFNEVApbICAgIDAuMDQzMTU0XSBB
Q1BJOiBJbnRlcnByZXRlciBlbmFibGVkClsgICAgMC4wNDMyNDRdIEFDUEk6IChzdXBwb3J0cyBT
MCBTNSkKWyAgICAwLjA0MzQ5NV0gQUNQSTogVXNpbmcgSU9BUElDIGZvciBpbnRlcnJ1cHQgcm91
dGluZwpbICAgIDAuMDYwMzUwXSBQQ0k6IElnbm9yaW5nIGhvc3QgYnJpZGdlIHdpbmRvd3MgZnJv
bSBBQ1BJOyBpZiBuZWNlc3NhcnksIHVzZSAicGNpPXVzZV9jcnMiIGFuZCByZXBvcnQgYSBidWcK
WyAgICAwLjA2MTYyNl0gQUNQSTogUENJIFJvb3QgQnJpZGdlIFtQQ0kwXSAoZG9tYWluIDAwMDAg
W2J1cyAwMC1mZl0pClsgICAgMC4wNjQwMjNdIHBjaV9yb290IFBOUDBBMDM6MDA6IGhvc3QgYnJp
ZGdlIHdpbmRvdyBbaW8gIDB4MDAwMC0weDBjZjddIChpZ25vcmVkKQpbICAgIDAuMDY0MTM1XSBw
Y2lfcm9vdCBQTlAwQTAzOjAwOiBob3N0IGJyaWRnZSB3aW5kb3cgW2lvICAweDBkMDAtMHhmZmZm
XSAoaWdub3JlZCkKWyAgICAwLjA2NDI0Nl0gcGNpX3Jvb3QgUE5QMEEwMzowMDogaG9zdCBicmlk
Z2Ugd2luZG93IFttZW0gMHgwMDBhMDAwMC0weDAwMGJmZmZmXSAoaWdub3JlZCkKWyAgICAwLjA2
NDM1OF0gcGNpX3Jvb3QgUE5QMEEwMzowMDogaG9zdCBicmlkZ2Ugd2luZG93IFttZW0gMHhjMDAw
MDAwMC0weGZlYmZmZmZmXSAoaWdub3JlZCkKWyAgICAwLjA2NDUwNl0gcGNpIDAwMDA6MDA6MDAu
MDogWzgwODY6MzU5MF0gdHlwZSAwIGNsYXNzIDB4MDAwNjAwClsgICAgMC4wNjQ4NDBdIHBjaSAw
MDAwOjAwOjAyLjA6IFs4MDg2OjM1OTVdIHR5cGUgMSBjbGFzcyAweDAwMDYwNApbICAgIDAuMDY1
MTEyXSBwY2kgMDAwMDowMDowMi4wOiBQTUUjIHN1cHBvcnRlZCBmcm9tIEQwIEQzaG90IEQzY29s
ZApbICAgIDAuMDY1MjEzXSBwY2kgMDAwMDowMDowMi4wOiBQTUUjIGRpc2FibGVkClsgICAgMC4w
NjUzODBdIHBjaSAwMDAwOjAwOjA0LjA6IFs4MDg2OjM1OTddIHR5cGUgMSBjbGFzcyAweDAwMDYw
NApbICAgIDAuMDY1NjUwXSBwY2kgMDAwMDowMDowNC4wOiBQTUUjIHN1cHBvcnRlZCBmcm9tIEQw
IEQzaG90IEQzY29sZApbICAgIDAuMDY1NzUyXSBwY2kgMDAwMDowMDowNC4wOiBQTUUjIGRpc2Fi
bGVkClsgICAgMC4wNjU5MTJdIHBjaSAwMDAwOjAwOjA1LjA6IFs4MDg2OjM1OThdIHR5cGUgMSBj
bGFzcyAweDAwMDYwNApbICAgIDAuMDY2MTgyXSBwY2kgMDAwMDowMDowNS4wOiBQTUUjIHN1cHBv
cnRlZCBmcm9tIEQwIEQzaG90IEQzY29sZApbICAgIDAuMDY2Mjk0XSBwY2kgMDAwMDowMDowNS4w
OiBQTUUjIGRpc2FibGVkClsgICAgMC4wNjY0NThdIHBjaSAwMDAwOjAwOjA2LjA6IFs4MDg2OjM1
OTldIHR5cGUgMSBjbGFzcyAweDAwMDYwNApbICAgIDAuMDY2NzI4XSBwY2kgMDAwMDowMDowNi4w
OiBQTUUjIHN1cHBvcnRlZCBmcm9tIEQwIEQzaG90IEQzY29sZApbICAgIDAuMDY2ODI5XSBwY2kg
MDAwMDowMDowNi4wOiBQTUUjIGRpc2FibGVkClsgICAgMC4wNjcwNDRdIHBjaSAwMDAwOjAwOjFk
LjA6IFs4MDg2OjI0ZDJdIHR5cGUgMCBjbGFzcyAweDAwMGMwMwpbICAgIDAuMDY3MjcyXSBwY2kg
MDAwMDowMDoxZC4wOiByZWcgMjA6IFtpbyAgMHhhY2UwLTB4YWNmZl0KWyAgICAwLjA2NzQ2MF0g
cGNpIDAwMDA6MDA6MWQuMTogWzgwODY6MjRkNF0gdHlwZSAwIGNsYXNzIDB4MDAwYzAzClsgICAg
MC4wNjc2ODhdIHBjaSAwMDAwOjAwOjFkLjE6IHJlZyAyMDogW2lvICAweGFjYzAtMHhhY2RmXQpb
ICAgIDAuMDY3ODczXSBwY2kgMDAwMDowMDoxZC4yOiBbODA4NjoyNGQ3XSB0eXBlIDAgY2xhc3Mg
MHgwMDBjMDMKWyAgICAwLjA2ODA5OV0gcGNpIDAwMDA6MDA6MWQuMjogcmVnIDIwOiBbaW8gIDB4
YWNhMC0weGFjYmZdClsgICAgMC4wNjgzMTldIHBjaSAwMDAwOjAwOjFkLjc6IFs4MDg2OjI0ZGRd
IHR5cGUgMCBjbGFzcyAweDAwMGMwMwpbICAgIDAuMDcwMDAwXSBwY2kgMDAwMDowMDoxZC43OiBy
ZWcgMTA6IFttZW0gMHhkZmYwMDAwMC0weGRmZjAwM2ZmXQpbICAgIDAuMDcwMDAwXSBwY2kgMDAw
MDowMDoxZC43OiBQTUUjIHN1cHBvcnRlZCBmcm9tIEQwIEQzaG90IEQzY29sZApbICAgIDAuMDcw
MDAwXSBwY2kgMDAwMDowMDoxZC43OiBQTUUjIGRpc2FibGVkClsgICAgMC4wNzAwMDBdIHBjaSAw
MDAwOjAwOjFlLjA6IFs4MDg2OjI0NGVdIHR5cGUgMSBjbGFzcyAweDAwMDYwNApbICAgIDAuMDcw
MDM0XSBwY2kgMDAwMDowMDoxZi4wOiBbODA4NjoyNGQwXSB0eXBlIDAgY2xhc3MgMHgwMDA2MDEK
WyAgICAwLjA3MDM2Ml0gcGNpIDAwMDA6MDA6MWYuMTogWzgwODY6MjRkYl0gdHlwZSAwIGNsYXNz
IDB4MDAwMTAxClsgICAgMC4wNzA0OTNdIHBjaSAwMDAwOjAwOjFmLjE6IHJlZyAxMDogW2lvICAw
eDAwMDAtMHgwMDA3XQpbICAgIDAuMDcwNjEyXSBwY2kgMDAwMDowMDoxZi4xOiByZWcgMTQ6IFtp
byAgMHgwMDAwLTB4MDAwM10KWyAgICAwLjA3MDczMV0gcGNpIDAwMDA6MDA6MWYuMTogcmVnIDE4
OiBbaW8gIDB4MDAwMC0weDAwMDddClsgICAgMC4wNzA4NTBdIHBjaSAwMDAwOjAwOjFmLjE6IHJl
ZyAxYzogW2lvICAweDAwMDAtMHgwMDAzXQpbICAgIDAuMDcwOTcwXSBwY2kgMDAwMDowMDoxZi4x
OiByZWcgMjA6IFtpbyAgMHhmYzAwLTB4ZmMwZl0KWyAgICAwLjA3MTA4OV0gcGNpIDAwMDA6MDA6
MWYuMTogcmVnIDI0OiBbbWVtIDB4MDAwMDAwMDAtMHgwMDAwMDNmZl0KWyAgICAwLjA3MTQwN10g
cGNpIDAwMDA6MDE6MDAuMDogWzgwODY6MDMzMF0gdHlwZSAxIGNsYXNzIDB4MDAwNjA0ClsgICAg
MC4wNzE2ODNdIHBjaSAwMDAwOjAxOjAwLjA6IFBNRSMgc3VwcG9ydGVkIGZyb20gRDAgRDNob3Qg
RDNjb2xkClsgICAgMC4wNzE3ODVdIHBjaSAwMDAwOjAxOjAwLjA6IFBNRSMgZGlzYWJsZWQKWyAg
ICAwLjA3MTk0Nl0gcGNpIDAwMDA6MDE6MDAuMjogWzgwODY6MDMzMl0gdHlwZSAxIGNsYXNzIDB4
MDAwNjA0ClsgICAgMC4wNzIyMjJdIHBjaSAwMDAwOjAxOjAwLjI6IFBNRSMgc3VwcG9ydGVkIGZy
b20gRDAgRDNob3QgRDNjb2xkClsgICAgMC4wNzIzMjNdIHBjaSAwMDAwOjAxOjAwLjI6IFBNRSMg
ZGlzYWJsZWQKWyAgICAwLjA3MjQ3MF0gcGNpIDAwMDA6MDE6MDAuMDogZGlzYWJsaW5nIEFTUE0g
b24gcHJlLTEuMSBQQ0llIGRldmljZS4gIFlvdSBjYW4gZW5hYmxlIGl0IHdpdGggJ3BjaWVfYXNw
bT1mb3JjZScKWyAgICAwLjA3MjYxMl0gcGNpIDAwMDA6MDA6MDIuMDogUENJIGJyaWRnZSB0byBb
YnVzIDAxLTAzXQpbICAgIDAuMDcyNzEzXSBwY2kgMDAwMDowMDowMi4wOiAgIGJyaWRnZSB3aW5k
b3cgW2lvICAweGUwMDAtMHhlZmZmXQpbICAgIDAuMDcyODE1XSBwY2kgMDAwMDowMDowMi4wOiAg
IGJyaWRnZSB3aW5kb3cgW21lbSAweGRmYzAwMDAwLTB4ZGZlZmZmZmZdClsgICAgMC4wNzI5MjVd
IHBjaSAwMDAwOjAwOjAyLjA6ICAgYnJpZGdlIHdpbmRvdyBbbWVtIDB4ZDgwMDAwMDAtMHhkOGZm
ZmZmZiA2NGJpdCBwcmVmXQpbICAgIDAuMDczMjA1XSBwY2kgMDAwMDowMjowNS4wOiBbMTAwMDow
MDMwXSB0eXBlIDAgY2xhc3MgMHgwMDAxMDAKWyAgICAwLjA3MzM1OV0gcGNpIDAwMDA6MDI6MDUu
MDogcmVnIDEwOiBbaW8gIDB4ZWMwMC0weGVjZmZdClsgICAgMC4wNzM0OTFdIHBjaSAwMDAwOjAy
OjA1LjA6IHJlZyAxNDogW21lbSAweGRmZGYwMDAwLTB4ZGZkZmZmZmYgNjRiaXRdClsgICAgMC4w
NzM2MjVdIHBjaSAwMDAwOjAyOjA1LjA6IHJlZyAxYzogW21lbSAweGRmZGUwMDAwLTB4ZGZkZWZm
ZmYgNjRiaXRdClsgICAgMC4wNzM3NzBdIHBjaSAwMDAwOjAyOjA1LjA6IHJlZyAzMDogW21lbSAw
eGRmZTAwMDAwLTB4ZGZlZmZmZmYgcHJlZl0KWyAgICAwLjA3MzkzOF0gcGNpIDAwMDA6MDI6MDUu
MDogc3VwcG9ydHMgRDEgRDIKWyAgICAwLjA3NDE0N10gcGNpIDAwMDA6MDE6MDAuMDogUENJIGJy
aWRnZSB0byBbYnVzIDAyLTAyXQpbICAgIDAuMDc0MjQ3XSBwY2kgMDAwMDowMTowMC4wOiAgIGJy
aWRnZSB3aW5kb3cgW2lvICAweGUwMDAtMHhlZmZmXQpbICAgIDAuMDc0MzQ5XSBwY2kgMDAwMDow
MTowMC4wOiAgIGJyaWRnZSB3aW5kb3cgW21lbSAweGRmZDAwMDAwLTB4ZGZlZmZmZmZdClsgICAg
MC4wNzQ0NTldIHBjaSAwMDAwOjAxOjAwLjA6ICAgYnJpZGdlIHdpbmRvdyBbbWVtIDB4ZDgwMDAw
MDAtMHhkOGZmZmZmZiA2NGJpdCBwcmVmXQpbICAgIDAuMDc0Nzg5XSBwY2kgMDAwMDowMTowMC4y
OiBQQ0kgYnJpZGdlIHRvIFtidXMgMDMtMDNdClsgICAgMC4wNzQ4OTBdIHBjaSAwMDAwOjAxOjAw
LjI6ICAgYnJpZGdlIHdpbmRvdyBbaW8gIDB4ZjAwMC0weDAwMDBdIChkaXNhYmxlZCkKWyAgICAw
LjA3NDk5NF0gcGNpIDAwMDA6MDE6MDAuMjogICBicmlkZ2Ugd2luZG93IFttZW0gMHhmZmYwMDAw
MC0weDAwMGZmZmZmXSAoZGlzYWJsZWQpClsgICAgMC4wNzUxMTldIHBjaSAwMDAwOjAxOjAwLjI6
ICAgYnJpZGdlIHdpbmRvdyBbbWVtIDB4ZmZmMDAwMDAtMHgwMDBmZmZmZiBwcmVmXSAoZGlzYWJs
ZWQpClsgICAgMC4wNzUzOTVdIHBjaSAwMDAwOjAwOjA0LjA6IFBDSSBicmlkZ2UgdG8gW2J1cyAw
NC0wNF0KWyAgICAwLjA3NTQ5NV0gcGNpIDAwMDA6MDA6MDQuMDogICBicmlkZ2Ugd2luZG93IFtp
byAgMHhmMDAwLTB4MDAwMF0gKGRpc2FibGVkKQpbICAgIDAuMDc1NTk5XSBwY2kgMDAwMDowMDow
NC4wOiAgIGJyaWRnZSB3aW5kb3cgW21lbSAweGZmZjAwMDAwLTB4MDAwZmZmZmZdIChkaXNhYmxl
ZCkKWyAgICAwLjA3NTcyNF0gcGNpIDAwMDA6MDA6MDQuMDogICBicmlkZ2Ugd2luZG93IFttZW0g
MHhmZmYwMDAwMC0weDAwMGZmZmZmIHByZWZdIChkaXNhYmxlZCkKWyAgICAwLjA3NTk4N10gcGNp
IDAwMDA6MDU6MDAuMDogWzgwODY6MDMyOV0gdHlwZSAxIGNsYXNzIDB4MDAwNjA0ClsgICAgMC4w
NzYxNDZdIHBjaSAwMDAwOjA1OjAwLjA6IFBYSCBxdWlyayBkZXRlY3RlZDsgU0hQQyBkZXZpY2Ug
TVNJIGRpc2FibGVkClsgICAgMC4wNzY0MTddIHBjaSAwMDAwOjA1OjAwLjA6IFBNRSMgc3VwcG9y
dGVkIGZyb20gRDAgRDNob3QgRDNjb2xkClsgICAgMC4wNzY1MjFdIHBjaSAwMDAwOjA1OjAwLjA6
IFBNRSMgZGlzYWJsZWQKWyAgICAwLjA3NjY4Nl0gcGNpIDAwMDA6MDU6MDAuMjogWzgwODY6MDMy
YV0gdHlwZSAxIGNsYXNzIDB4MDAwNjA0ClsgICAgMC4wNzY4NDRdIHBjaSAwMDAwOjA1OjAwLjI6
IFBYSCBxdWlyayBkZXRlY3RlZDsgU0hQQyBkZXZpY2UgTVNJIGRpc2FibGVkClsgICAgMC4wNzcx
MTVdIHBjaSAwMDAwOjA1OjAwLjI6IFBNRSMgc3VwcG9ydGVkIGZyb20gRDAgRDNob3QgRDNjb2xk
ClsgICAgMC4wNzcyMTZdIHBjaSAwMDAwOjA1OjAwLjI6IFBNRSMgZGlzYWJsZWQKWyAgICAwLjA3
NzM2Ml0gcGNpIDAwMDA6MDU6MDAuMDogZGlzYWJsaW5nIEFTUE0gb24gcHJlLTEuMSBQQ0llIGRl
dmljZS4gIFlvdSBjYW4gZW5hYmxlIGl0IHdpdGggJ3BjaWVfYXNwbT1mb3JjZScKWyAgICAwLjA3
NzUwNl0gcGNpIDAwMDA6MDA6MDUuMDogUENJIGJyaWRnZSB0byBbYnVzIDA1LTA3XQpbICAgIDAu
MDc3NjA4XSBwY2kgMDAwMDowMDowNS4wOiAgIGJyaWRnZSB3aW5kb3cgW2lvICAweGMwMDAtMHhk
ZmZmXQpbICAgIDAuMDc3NzEwXSBwY2kgMDAwMDowMDowNS4wOiAgIGJyaWRnZSB3aW5kb3cgW21l
bSAweGRmNzAwMDAwLTB4ZGZiZmZmZmZdClsgICAgMC4wNzc4MjBdIHBjaSAwMDAwOjAwOjA1LjA6
ICAgYnJpZGdlIHdpbmRvdyBbbWVtIDB4ZmZmMDAwMDAtMHgwMDBmZmZmZiBwcmVmXSAoZGlzYWJs
ZWQpClsgICAgMC4wNzgxMDFdIHBjaSAwMDAwOjA2OjA3LjA6IFs4MDg2OjEwNzZdIHR5cGUgMCBj
bGFzcyAweDAwMDIwMApbICAgIDAuMDc4MjQ5XSBwY2kgMDAwMDowNjowNy4wOiByZWcgMTA6IFtt
ZW0gMHhkZmFlMDAwMC0weGRmYWZmZmZmXQpbICAgIDAuMDc4MzkzXSBwY2kgMDAwMDowNjowNy4w
OiByZWcgMTg6IFtpbyAgMHhkY2MwLTB4ZGNmZl0KWyAgICAwLjA3ODY0NF0gcGNpIDAwMDA6MDY6
MDcuMDogUE1FIyBzdXBwb3J0ZWQgZnJvbSBEMCBEM2hvdCBEM2NvbGQKWyAgICAwLjA3ODc0NV0g
cGNpIDAwMDA6MDY6MDcuMDogUE1FIyBkaXNhYmxlZApbICAgIDAuMDc4OTQxXSBwY2kgMDAwMDow
NTowMC4wOiBQQ0kgYnJpZGdlIHRvIFtidXMgMDYtMDZdClsgICAgMC4wNzkwNDFdIHBjaSAwMDAw
OjA1OjAwLjA6ICAgYnJpZGdlIHdpbmRvdyBbaW8gIDB4ZDAwMC0weGRmZmZdClsgICAgMC4wNzkx
NDNdIHBjaSAwMDAwOjA1OjAwLjA6ICAgYnJpZGdlIHdpbmRvdyBbbWVtIDB4ZGZhMDAwMDAtMHhk
ZmJmZmZmZl0KWyAgICAwLjA3OTI1M10gcGNpIDAwMDA6MDU6MDAuMDogICBicmlkZ2Ugd2luZG93
IFttZW0gMHhmZmYwMDAwMC0weDAwMGZmZmZmIHByZWZdIChkaXNhYmxlZCkKWyAgICAwLjA3OTU0
NF0gcGNpIDAwMDA6MDc6MDguMDogWzgwODY6MTA3Nl0gdHlwZSAwIGNsYXNzIDB4MDAwMjAwClsg
ICAgMC4wNzk2OTJdIHBjaSAwMDAwOjA3OjA4LjA6IHJlZyAxMDogW21lbSAweGRmOGUwMDAwLTB4
ZGY4ZmZmZmZdClsgICAgMC4wNzk4MzZdIHBjaSAwMDAwOjA3OjA4LjA6IHJlZyAxODogW2lvICAw
eGNjYzAtMHhjY2ZmXQpbICAgIDAuMDgwMDAwXSBwY2kgMDAwMDowNzowOC4wOiBQTUUjIHN1cHBv
cnRlZCBmcm9tIEQwIEQzaG90IEQzY29sZApbICAgIDAuMDgwMDAwXSBwY2kgMDAwMDowNzowOC4w
OiBQTUUjIGRpc2FibGVkClsgICAgMC4wODAwMDBdIHBjaSAwMDAwOjA1OjAwLjI6IFBDSSBicmlk
Z2UgdG8gW2J1cyAwNy0wN10KWyAgICAwLjA4MDAwMF0gcGNpIDAwMDA6MDU6MDAuMjogICBicmlk
Z2Ugd2luZG93IFtpbyAgMHhjMDAwLTB4Y2ZmZl0KWyAgICAwLjA4MDAwMF0gcGNpIDAwMDA6MDU6
MDAuMjogICBicmlkZ2Ugd2luZG93IFttZW0gMHhkZjgwMDAwMC0weGRmOWZmZmZmXQpbICAgIDAu
MDgwMDAwXSBwY2kgMDAwMDowNTowMC4yOiAgIGJyaWRnZSB3aW5kb3cgW21lbSAweGZmZjAwMDAw
LTB4MDAwZmZmZmYgcHJlZl0gKGRpc2FibGVkKQpbICAgIDAuMDgwMDAwXSBwY2kgMDAwMDowMDow
Ni4wOiBQQ0kgYnJpZGdlIHRvIFtidXMgMDgtMDhdClsgICAgMC4wODAwMDBdIHBjaSAwMDAwOjAw
OjA2LjA6ICAgYnJpZGdlIHdpbmRvdyBbaW8gIDB4ZjAwMC0weDAwMDBdIChkaXNhYmxlZCkKWyAg
ICAwLjA4MDAwMF0gcGNpIDAwMDA6MDA6MDYuMDogICBicmlkZ2Ugd2luZG93IFttZW0gMHhmZmYw
MDAwMC0weDAwMGZmZmZmXSAoZGlzYWJsZWQpClsgICAgMC4wODAwMDBdIHBjaSAwMDAwOjAwOjA2
LjA6ICAgYnJpZGdlIHdpbmRvdyBbbWVtIDB4ZmZmMDAwMDAtMHgwMDBmZmZmZiBwcmVmXSAoZGlz
YWJsZWQpClsgICAgMC4wODAwNzddIHBjaSAwMDAwOjA5OjA1LjA6IFsxMDI4OjAwMTFdIHR5cGUg
MCBjbGFzcyAweDAwZmYwMApbICAgIDAuMDgwMjE5XSBwY2kgMDAwMDowOTowNS4wOiByZWcgMTA6
IFttZW0gMHhkN2ZmZjAwMC0weGQ3ZmZmZmZmIHByZWZdClsgICAgMC4wODAzNDFdIHBjaSAwMDAw
OjA5OjA1LjA6IHJlZyAxNDogW2lvICAweGJjZjgtMHhiY2ZmXQpbICAgIDAuMDgwNDYwXSBwY2kg
MDAwMDowOTowNS4wOiByZWcgMTg6IFtpbyAgMHhiY2U4LTB4YmNlZl0KWyAgICAwLjA4MDY1NV0g
cGNpIDAwMDA6MDk6MDUuMDogcmVnIDMwOiBbbWVtIDB4ZGY2MDAwMDAtMHhkZjYwZmZmZiBwcmVm
XQpbICAgIDAuMDgwODQ4XSBwY2kgMDAwMDowOTowNS4xOiBbMTAyODowMDEyXSB0eXBlIDAgY2xh
c3MgMHgwMGZmMDAKWyAgICAwLjA4MDk5MF0gcGNpIDAwMDA6MDk6MDUuMTogcmVnIDEwOiBbbWVt
IDB4ZGY1ZmYwMDAtMHhkZjVmZmZmZl0KWyAgICAwLjA4MTExMF0gcGNpIDAwMDA6MDk6MDUuMTog
cmVnIDE0OiBbaW8gIDB4YmM4MC0weGJjYmZdClsgICAgMC4wODEyMzBdIHBjaSAwMDAwOjA5OjA1
LjE6IHJlZyAxODogW21lbSAweGQ3ZjAwMDAwLTB4ZDdmN2ZmZmYgcHJlZl0KWyAgICAwLjA4MTUx
OF0gcGNpIDAwMDA6MDk6MDUuMjogWzEwMjg6MDAxNF0gdHlwZSAwIGNsYXNzIDB4MDBmZjAwClsg
ICAgMC4wODE5MTNdIHBjaSAwMDAwOjA5OjA2LjA6IFsxMDk1OjA2ODBdIHR5cGUgMCBjbGFzcyAw
eDAwMDEwMQpbICAgIDAuMDgyMDUzXSBwY2kgMDAwMDowOTowNi4wOiByZWcgMTA6IFtpbyAgMHhi
Y2YwLTB4YmNmN10KWyAgICAwLjA4MjE3Ml0gcGNpIDAwMDA6MDk6MDYuMDogcmVnIDE0OiBbaW8g
IDB4YmNlNC0weGJjZTddClsgICAgMC4wODIyOTFdIHBjaSAwMDAwOjA5OjA2LjA6IHJlZyAxODog
W2lvICAweGJjZDgtMHhiY2RmXQpbICAgIDAuMDgyNDA5XSBwY2kgMDAwMDowOTowNi4wOiByZWcg
MWM6IFtpbyAgMHhiY2QwLTB4YmNkM10KWyAgICAwLjA4MjUyOF0gcGNpIDAwMDA6MDk6MDYuMDog
cmVnIDIwOiBbaW8gIDB4YmM3MC0weGJjN2ZdClsgICAgMC4wODI2NDddIHBjaSAwMDAwOjA5OjA2
LjA6IHJlZyAyNDogW21lbSAweGRmNWZlYzAwLTB4ZGY1ZmVjZmZdClsgICAgMC4wODI3NjZdIHBj
aSAwMDAwOjA5OjA2LjA6IHJlZyAzMDogW21lbSAweGRmNjAwMDAwLTB4ZGY2N2ZmZmYgcHJlZl0K
WyAgICAwLjA4MjkxNV0gcGNpIDAwMDA6MDk6MDYuMDogc3VwcG9ydHMgRDEgRDIKWyAgICAwLjA4
MzA3MV0gcGNpIDAwMDA6MDk6MGQuMDogWzEwMDI6NTE1OV0gdHlwZSAwIGNsYXNzIDB4MDAwMzAw
ClsgICAgMC4wODMyMTFdIHBjaSAwMDAwOjA5OjBkLjA6IHJlZyAxMDogW21lbSAweGM4MDAwMDAw
LTB4Y2ZmZmZmZmYgcHJlZl0KWyAgICAwLjA4MzMzMl0gcGNpIDAwMDA6MDk6MGQuMDogcmVnIDE0
OiBbaW8gIDB4YjgwMC0weGI4ZmZdClsgICAgMC4wODM0NTFdIHBjaSAwMDAwOjA5OjBkLjA6IHJl
ZyAxODogW21lbSAweGRmNWUwMDAwLTB4ZGY1ZWZmZmZdClsgICAgMC4wODM2NDNdIHBjaSAwMDAw
OjA5OjBkLjA6IHJlZyAzMDogW21lbSAweDAwMDAwMDAwLTB4MDAwMWZmZmYgcHJlZl0KWyAgICAw
LjA4Mzc4OF0gcGNpIDAwMDA6MDk6MGQuMDogc3VwcG9ydHMgRDEgRDIKWyAgICAwLjA4Mzk1OF0g
cGNpIDAwMDA6MDA6MWUuMDogUENJIGJyaWRnZSB0byBbYnVzIDA5LTA5XSAoc3VidHJhY3RpdmUg
ZGVjb2RlKQpbICAgIDAuMDg0MDcwXSBwY2kgMDAwMDowMDoxZS4wOiAgIGJyaWRnZSB3aW5kb3cg
W2lvICAweGIwMDAtMHhiZmZmXQpbICAgIDAuMDg0MTczXSBwY2kgMDAwMDowMDoxZS4wOiAgIGJy
aWRnZSB3aW5kb3cgW21lbSAweGRmNTAwMDAwLTB4ZGY2ZmZmZmZdClsgICAgMC4wODQyNzZdIHBj
aSAwMDAwOjAwOjFlLjA6ICAgYnJpZGdlIHdpbmRvdyBbbWVtIDB4YzgwMDAwMDAtMHhkN2ZmZmZm
ZiBwcmVmXQpbICAgIDAuMDg0Mzg3XSBwY2kgMDAwMDowMDoxZS4wOiAgIGJyaWRnZSB3aW5kb3cg
W2lvICAweDAwMDAtMHhmZmZmXSAoc3VidHJhY3RpdmUgZGVjb2RlKQpbICAgIDAuMDg0NDk5XSBw
Y2kgMDAwMDowMDoxZS4wOiAgIGJyaWRnZSB3aW5kb3cgW21lbSAweDAwMDAwMDAwLTB4ZmZmZmZm
ZmZmXSAoc3VidHJhY3RpdmUgZGVjb2RlKQpbICAgIDAuMDg0Njg0XSBwY2lfYnVzIDAwMDA6MDA6
IG9uIE5VTUEgbm9kZSAwClsgICAgMC4wODQ3NzldIEFDUEk6IFBDSSBJbnRlcnJ1cHQgUm91dGlu
ZyBUYWJsZSBbXF9TQl8uUENJMC5fUFJUXQpbICAgIDAuMDg1NTUxXSBBQ1BJOiBQQ0kgSW50ZXJy
dXB0IFJvdXRpbmcgVGFibGUgW1xfU0JfLlBDSTAuUEFMTy5fUFJUXQpbICAgIDAuMDg1OTkyXSBB
Q1BJOiBQQ0kgSW50ZXJydXB0IFJvdXRpbmcgVGFibGUgW1xfU0JfLlBDSTAuUEFMTy5ET0JBLl9Q
UlRdClsgICAgMC4wODY2MzBdIEFDUEk6IFBDSSBJbnRlcnJ1cHQgUm91dGluZyBUYWJsZSBbXF9T
Ql8uUENJMC5QQUxPLkRPQkIuX1BSVF0KWyAgICAwLjA4NzE0MV0gQUNQSTogUENJIEludGVycnVw
dCBSb3V0aW5nIFRhYmxlIFtcX1NCXy5QQ0kwLlBCTE8uX1BSVF0KWyAgICAwLjA4NzU0OV0gQUNQ
STogUENJIEludGVycnVwdCBSb3V0aW5nIFRhYmxlIFtcX1NCXy5QQ0kwLlZQUjAuX1BSVF0KWyAg
ICAwLjA4Nzk1Nl0gQUNQSTogUENJIEludGVycnVwdCBSb3V0aW5nIFRhYmxlIFtcX1NCXy5QQ0kw
LlBCSEkuX1BSVF0KWyAgICAwLjA4ODM5NV0gQUNQSTogUENJIEludGVycnVwdCBSb3V0aW5nIFRh
YmxlIFtcX1NCXy5QQ0kwLlBCSEkuUFhCMS5fUFJUXQpbICAgIDAuMDg4Njk5XSBBQ1BJOiBQQ0kg
SW50ZXJydXB0IFJvdXRpbmcgVGFibGUgW1xfU0JfLlBDSTAuUEJISS5QWEIyLl9QUlRdClsgICAg
MC4wODg5NzFdIEFDUEk6IFBDSSBJbnRlcnJ1cHQgUm91dGluZyBUYWJsZSBbXF9TQl8uUENJMC5Q
SUNILl9QUlRdClsgICAgMC4wODk4NDVdICBwY2kwMDAwOjAwOiBSZXF1ZXN0aW5nIEFDUEkgX09T
QyBjb250cm9sICgweDFkKQpbICAgIDAuMDg5OTQyXSAgcGNpMDAwMDowMDogQUNQSSBfT1NDIHJl
cXVlc3QgZmFpbGVkIChBRV9OT1RfRk9VTkQpLCByZXR1cm5lZCBjb250cm9sIG1hc2s6IDB4MWQK
WyAgICAwLjA5MDAxMF0gQUNQSSBfT1NDIGNvbnRyb2wgZm9yIFBDSWUgbm90IGdyYW50ZWQsIGRp
c2FibGluZyBBU1BNClsgICAgMC4wOTkxMDFdIEFDUEk6IFBDSSBJbnRlcnJ1cHQgTGluayBbTE5L
QV0gKElSUXMgMyA0IDUgNiA3IDEwICoxMSAxMikKWyAgICAwLjEwMDA0OF0gQUNQSTogUENJIElu
dGVycnVwdCBMaW5rIFtMTktCXSAoSVJRcyAqMyA0IDUgNiA3IDEwIDExIDEyKQpbICAgIDAuMTAx
MDMyXSBBQ1BJOiBQQ0kgSW50ZXJydXB0IExpbmsgW0xOS0NdIChJUlFzIDMgNCA1IDYgKjcgMTAg
MTEgMTIpClsgICAgMC4xMDIwMTRdIEFDUEk6IFBDSSBJbnRlcnJ1cHQgTGluayBbTE5LRF0gKElS
UXMgMyA0IDUgNiA3ICoxMCAxMSAxMikKWyAgICAwLjEwMjk5Nl0gQUNQSTogUENJIEludGVycnVw
dCBMaW5rIFtMTktFXSAoSVJRcyAzIDQgNSA2IDcgMTAgKjExIDEyKQpbICAgIDAuMTAzOTc4XSBB
Q1BJOiBQQ0kgSW50ZXJydXB0IExpbmsgW0xOS0ZdIChJUlFzIDMgNCA1IDYgNyAqMTAgMTEgMTIp
ClsgICAgMC4xMDQ5NzFdIEFDUEk6IFBDSSBJbnRlcnJ1cHQgTGluayBbTE5LR10gKElSUXMgMyA0
IDUgNiA3IDEwIDExIDEyKSAqMCwgZGlzYWJsZWQuClsgICAgMC4xMDYxMDhdIEFDUEk6IFBDSSBJ
bnRlcnJ1cHQgTGluayBbTE5LSF0gKElSUXMgMyA0ICo1IDYgNyAxMCAxMSAxMikKWyAgICAwLjEw
Njk3Nl0geGVuL2JhbGxvb246IEluaXRpYWxpc2luZyBiYWxsb29uIGRyaXZlci4KWyAgICAwLjEw
NzA3MV0gbGFzdF9wZm4gPSAweDFkZmZjMCBtYXhfYXJjaF9wZm4gPSAweDEwMDAwMDAKWyAgICAw
LjEyNjU3MF0geGVuLWJhbGxvb246IEluaXRpYWxpc2luZyBiYWxsb29uIGRyaXZlci4KWyAgICAw
LjEyNjgzOV0gdmdhYXJiOiBkZXZpY2UgYWRkZWQ6IFBDSTowMDAwOjA5OjBkLjAsZGVjb2Rlcz1p
byttZW0sb3ducz1pbyttZW0sbG9ja3M9bm9uZQpbICAgIDAuMTI2OTUxXSB2Z2FhcmI6IGxvYWRl
ZApbICAgIDAuMTI3MDM5XSB2Z2FhcmI6IGJyaWRnZSBjb250cm9sIHBvc3NpYmxlIDAwMDA6MDk6
MGQuMApbICAgIDAuMTI3MTMxXSB1c2Jjb3JlOiBVU0Igc3VwcG9ydCBkaXNhYmxlZApbICAgIDAu
MTI3MzUzXSBQQ0k6IFVzaW5nIEFDUEkgZm9yIElSUSByb3V0aW5nClsgICAgMC4xMzAwMDBdIFBD
STogcGNpX2NhY2hlX2xpbmVfc2l6ZSBzZXQgdG8gNjQgYnl0ZXMKWyAgICAwLjEzMDAwMF0gcmVz
ZXJ2ZSBSQU0gYnVmZmVyOiAwMDAwMDAwMWRmZmMwMDAwIC0gMDAwMDAwMDFkZmZmZmZmZiAKWyAg
ICAwLjEzMDI5M10gU3dpdGNoaW5nIHRvIGNsb2Nrc291cmNlIHhlbgpbICAgIDAuMTMwNzM4XSBw
bnA6IFBuUCBBQ1BJIGluaXQKWyAgICAwLjEzMDgzOV0gQUNQSTogYnVzIHR5cGUgcG5wIHJlZ2lz
dGVyZWQKWyAgICAwLjEzMjE0NV0gcG5wIDAwOjAwOiBbYnVzIDAwLWZmXQpbICAgIDAuMTMyMjM4
XSBwbnAgMDA6MDA6IFtpbyAgMHgwMDAwLTB4MGNmNyB3aW5kb3ddClsgICAgMC4xMzIzMzFdIHBu
cCAwMDowMDogW2lvICAweDBjZjgtMHgwY2ZmXQpbICAgIDAuMTMyNDIzXSBwbnAgMDA6MDA6IFtp
byAgMHgwZDAwLTB4ZmZmZiB3aW5kb3ddClsgICAgMC4xMzI1MTZdIHBucCAwMDowMDogW21lbSAw
eDAwMGEwMDAwLTB4MDAwYmZmZmYgd2luZG93XQpbICAgIDAuMTMyNjEwXSBwbnAgMDA6MDA6IFtt
ZW0gMHhjMDAwMDAwMC0weGZlYmZmZmZmIHdpbmRvd10KWyAgICAwLjEzMjcwNF0gcG5wIDAwOjAw
OiBbbWVtIDB4MTAwMDAwMDAwLTB4ZmZmZmZmZmZmIHdpbmRvd10KWyAgICAwLjEzMjkwNF0gcG5w
IDAwOjAwOiBQbHVnIGFuZCBQbGF5IEFDUEkgZGV2aWNlLCBJRHMgUE5QMGEwMyAoYWN0aXZlKQpb
ICAgIDAuMTMzMDgzXSBwbnAgMDA6MDE6IFtpbyAgMHgwMDgwLTB4MDA5Zl0KWyAgICAwLjEzMzE3
NV0gcG5wIDAwOjAxOiBbaW8gIDB4MDAwMC0weDAwMWZdClsgICAgMC4xMzMyNjddIHBucCAwMDow
MTogW2lvICAweDAwYzAtMHgwMGRmXQpbICAgIDAuMTMzMzU5XSBwbnAgMDA6MDE6IFtkbWEgNF0K
WyAgICAwLjEzMzUwMV0gcG5wIDAwOjAxOiBQbHVnIGFuZCBQbGF5IEFDUEkgZGV2aWNlLCBJRHMg
UE5QMDIwMCAoYWN0aXZlKQpbICAgIDAuMTMzNjY4XSBwbnAgMDA6MDI6IFtpbyAgMHgwMGYwLTB4
MDBmZl0KWyAgICAwLjEzMzc2NF0geGVuOiByZWdpc3RlcmluZyBnc2kgMTMgdHJpZ2dlcmluZyAx
IHBvbGFyaXR5IDAKWyAgICAwLjEzMzg1OF0geGVuX21hcF9waXJxX2dzaTogcmV0dXJuaW5nIGly
cSAxMyBmb3IgZ3NpIDEzClsgICAgMC4xMzM5NTBdIHhlbjogLS0+IHBpcnE9MTMgLT4gaXJxPTEz
IChnc2k9MTMpClsgICAgMC4xMzQwNTVdIHBucCAwMDowMjogW2lycSAxM10KWyAgICAwLjEzNDIw
MV0gcG5wIDAwOjAyOiBQbHVnIGFuZCBQbGF5IEFDUEkgZGV2aWNlLCBJRHMgUE5QMGMwNCAoYWN0
aXZlKQpbICAgIDAuMTM1NDM3XSBTd2l0Y2hlZCB0byBOT0h6IG1vZGUgb24gQ1BVICMxClsgICAg
MC4xMzYyNzhdIHBucCAwMDowMzogW2lvICAweDAwNjFdClsgICAgMC4xMzY0MjldIHBucCAwMDow
MzogUGx1ZyBhbmQgUGxheSBBQ1BJIGRldmljZSwgSURzIFBOUDA4MDAgKGFjdGl2ZSkKWyAgICAw
LjEzNjU5Nl0gcG5wIDAwOjA0OiBbaW8gIDB4MDA3MC0weDAwN2ZdClsgICAgMC4xMzY2ODhdIHhl
bjogcmVnaXN0ZXJpbmcgZ3NpIDggdHJpZ2dlcmluZyAxIHBvbGFyaXR5IDAKWyAgICAwLjEzNjIz
N10gU3dpdGNoZWQgdG8gTk9IeiBtb2RlIG9uIENQVSAjMgpbICAgIDAuMTM2ODY2XSB4ZW5fbWFw
X3BpcnFfZ3NpOiByZXR1cm5pbmcgaXJxIDggZm9yIGdzaSA4ClsgICAgMC4xMzY5NThdIHhlbjog
LS0+IHBpcnE9OCAtPiBpcnE9OCAoZ3NpPTgpClsgICAgMC4xMzcwNTVdIHBucCAwMDowNDogW2ly
cSA4XQpbICAgIDAuMTM3MjAxXSBwbnAgMDA6MDQ6IFBsdWcgYW5kIFBsYXkgQUNQSSBkZXZpY2Us
IElEcyBQTlAwYjAwIChhY3RpdmUpClsgICAgMC4xMzY5NzJdIFN3aXRjaGVkIHRvIE5PSHogbW9k
ZSBvbiBDUFUgIzMKWyAgICAwLjEzODEzMl0gcG5wIDAwOjA1OiBbaW8gIDB4MDNmMC0weDAzZjVd
ClsgICAgMC4xMzgyMjVdIHBucCAwMDowNTogW2lvICAweDAzZjddClsgICAgMC4xMzgzMTVdIHhl
bjogcmVnaXN0ZXJpbmcgZ3NpIDYgdHJpZ2dlcmluZyAxIHBvbGFyaXR5IDAKWyAgICAwLjEzODQw
OF0geGVuX21hcF9waXJxX2dzaTogcmV0dXJuaW5nIGlycSA2IGZvciBnc2kgNgpbICAgIDAuMTM4
NTAwXSB4ZW46IC0tPiBwaXJxPTYgLT4gaXJxPTYgKGdzaT02KQpbICAgIDAuMTM4NTk2XSBwbnAg
MDA6MDU6IFtpcnEgNl0KWyAgICAwLjEzODY4Nl0gcG5wIDAwOjA1OiBbZG1hIDJdClsgICAgMC4x
Mzg5MzRdIHBucCAwMDowNTogUGx1ZyBhbmQgUGxheSBBQ1BJIGRldmljZSwgSURzIFBOUDA3MDAg
KGFjdGl2ZSkKWyAgICAwLjEzOTgxMl0gcG5wIDAwOjA2OiBbaW8gIDB4MDA2MF0KWyAgICAwLjEz
OTkwNV0gcG5wIDAwOjA2OiBbaW8gIDB4MDA2NF0KWyAgICAwLjEzOTk5NV0geGVuOiByZWdpc3Rl
cmluZyBnc2kgMSB0cmlnZ2VyaW5nIDEgcG9sYXJpdHkgMApbICAgIDAuMTQwMDAwXSB4ZW5fbWFw
X3BpcnFfZ3NpOiByZXR1cm5pbmcgaXJxIDEgZm9yIGdzaSAxClsgICAgMC4xNDAwMDBdIHhlbjog
LS0+IHBpcnE9MSAtPiBpcnE9MSAoZ3NpPTEpClsgICAgMC4xNDAwMDBdIFN3aXRjaGVkIHRvIE5P
SHogbW9kZSBvbiBDUFUgIzAKWyAgICAwLjE0MDAwMF0gcG5wIDAwOjA2OiBbaXJxIDFdClsgICAg
MC4xNDAwMjldIHBucCAwMDowNjogUGx1ZyBhbmQgUGxheSBBQ1BJIGRldmljZSwgSURzIFBOUDAz
MDMgKGFjdGl2ZSkKWyAgICAwLjE0MTUzNV0geGVuOiByZWdpc3RlcmluZyBnc2kgMTIgdHJpZ2dl
cmluZyAxIHBvbGFyaXR5IDAKWyAgICAwLjE0MTYyOV0geGVuX21hcF9waXJxX2dzaTogcmV0dXJu
aW5nIGlycSAxMiBmb3IgZ3NpIDEyClsgICAgMC4xNDE3MjFdIHhlbjogLS0+IHBpcnE9MTIgLT4g
aXJxPTEyIChnc2k9MTIpClsgICAgMC4xNDE4MThdIHBucCAwMDowNzogW2lycSAxMl0KWyAgICAw
LjE0MTk3MV0gcG5wIDAwOjA3OiBQbHVnIGFuZCBQbGF5IEFDUEkgZGV2aWNlLCBJRHMgUE5QMGYx
MyAoYWN0aXZlKQpbICAgIDAuMTQyNjA0XSBwbnAgMDA6MDg6IFtpbyAgMHgwM2Y4LTB4MDNmZl0K
WyAgICAwLjE0MjY5N10geGVuOiByZWdpc3RlcmluZyBnc2kgNCB0cmlnZ2VyaW5nIDEgcG9sYXJp
dHkgMApbICAgIDAuMTQyNzkwXSB4ZW5fbWFwX3BpcnFfZ3NpOiByZXR1cm5pbmcgaXJxIDQgZm9y
IGdzaSA0ClsgICAgMC4xNDI4ODJdIHhlbjogLS0+IHBpcnE9NCAtPiBpcnE9NCAoZ3NpPTQpClsg
ICAgMC4xNDI5NzhdIHBucCAwMDowODogW2lycSA0XQpbICAgIDAuMTQzMjA5XSBwbnAgMDA6MDg6
IFBsdWcgYW5kIFBsYXkgQUNQSSBkZXZpY2UsIElEcyBQTlAwNTAxIChhY3RpdmUpClsgICAgMC4x
NDQ5MTVdIHBucCAwMDowOTogW2lvICAweDA4MDAtMHgwODdmXQpbICAgIDAuMTQ1MDA3XSBwbnAg
MDA6MDk6IFtpbyAgMHgwODgwLTB4MDhiZl0KWyAgICAwLjE0NTA5OV0gcG5wIDAwOjA5OiBbaW8g
IDB4MDhjMC0weDA4ZGZdClsgICAgMC4xNDUxOTBdIHBucCAwMDowOTogW2lvICAweDA4ZTAtMHgw
OGUzXQpbICAgIDAuMTQ1MjgyXSBwbnAgMDA6MDk6IFtpbyAgMHgwYzAwLTB4MGMwZl0KWyAgICAw
LjE0NTM3M10gcG5wIDAwOjA5OiBbaW8gIDB4MGMxMC0weDBjMWZdClsgICAgMC4xNDU0NjVdIHBu
cCAwMDowOTogW2lvICAweDBjYTAtMHgwY2E3XQpbICAgIDAuMTQ1NTU5XSBwbnAgMDA6MDk6IFtp
byAgMHgwY2E5LTB4MGNhYl0KWyAgICAwLjE0NTY1MF0gcG5wIDAwOjA5OiBbaW8gIDB4MGNhZC0w
eDBjYWZdClsgICAgMC4xNDU3NDJdIHBucCAwMDowOTogW2lvICAweDBjMjAtMHgwYzNmXQpbICAg
IDAuMTQ1ODMzXSBwbnAgMDA6MDk6IFtpbyAgMHgwMGUwLTB4MDBlN10KWyAgICAwLjE0NTkyNV0g
cG5wIDAwOjA5OiBbaW8gIDB4MDA2MC0weDAwNWYgZGlzYWJsZWRdClsgICAgMC4xNDYwMThdIHBu
cCAwMDowOTogW2lvICAweDAwNjQtMHgwMDYzIGRpc2FibGVkXQpbICAgIDAuMTQ2MjU1XSBzeXN0
ZW0gMDA6MDk6IFtpbyAgMHgwODAwLTB4MDg3Zl0gaGFzIGJlZW4gcmVzZXJ2ZWQKWyAgICAwLjE0
NjM1MV0gc3lzdGVtIDAwOjA5OiBbaW8gIDB4MDg4MC0weDA4YmZdIGhhcyBiZWVuIHJlc2VydmVk
ClsgICAgMC4xNDY0NDldIHN5c3RlbSAwMDowOTogW2lvICAweDA4YzAtMHgwOGRmXSBoYXMgYmVl
biByZXNlcnZlZApbICAgIDAuMTQ2NTQ1XSBzeXN0ZW0gMDA6MDk6IFtpbyAgMHgwOGUwLTB4MDhl
M10gaGFzIGJlZW4gcmVzZXJ2ZWQKWyAgICAwLjE0NjY0MF0gc3lzdGVtIDAwOjA5OiBbaW8gIDB4
MGMwMC0weDBjMGZdIGhhcyBiZWVuIHJlc2VydmVkClsgICAgMC4xNDY3MzZdIHN5c3RlbSAwMDow
OTogW2lvICAweDBjMTAtMHgwYzFmXSBoYXMgYmVlbiByZXNlcnZlZApbICAgIDAuMTQ2ODMxXSBz
eXN0ZW0gMDA6MDk6IFtpbyAgMHgwY2EwLTB4MGNhN10gaGFzIGJlZW4gcmVzZXJ2ZWQKWyAgICAw
LjE0NjkyN10gc3lzdGVtIDAwOjA5OiBbaW8gIDB4MGNhOS0weDBjYWJdIGhhcyBiZWVuIHJlc2Vy
dmVkClsgICAgMC4xNDcwMjJdIHN5c3RlbSAwMDowOTogW2lvICAweDBjYWQtMHgwY2FmXSBoYXMg
YmVlbiByZXNlcnZlZApbICAgIDAuMTQ3MTE4XSBzeXN0ZW0gMDA6MDk6IFtpbyAgMHgwYzIwLTB4
MGMzZl0gaGFzIGJlZW4gcmVzZXJ2ZWQKWyAgICAwLjE0NzIxNF0gc3lzdGVtIDAwOjA5OiBQbHVn
IGFuZCBQbGF5IEFDUEkgZGV2aWNlLCBJRHMgUE5QMGMwMSAoYWN0aXZlKQpbICAgIDAuMTQ3NDk4
XSBwbnAgMDA6MGE6IFtpbyAgMHgwY2E4XQpbICAgIDAuMTQ3NTg5XSBwbnAgMDA6MGE6IFtpbyAg
MHgwY2FjXQpbICAgIDAuMTQ3NzQ4XSBwbnAgMDA6MGE6IFBsdWcgYW5kIFBsYXkgQUNQSSBkZXZp
Y2UsIElEcyBJUEkwMDAxIChhY3RpdmUpClsgICAgMC4xNDkzMzFdIHBucCAwMDowYjogW21lbSAw
eGUwMDAwMDAwLTB4ZWZmZmZmZmZdClsgICAgMC4xNDk1NTldIHN5c3RlbSAwMDowYjogW21lbSAw
eGUwMDAwMDAwLTB4ZWZmZmZmZmZdIGhhcyBiZWVuIHJlc2VydmVkClsgICAgMC4xNDk2NTZdIHN5
c3RlbSAwMDowYjogUGx1ZyBhbmQgUGxheSBBQ1BJIGRldmljZSwgSURzIFBOUDBjMDIgKGFjdGl2
ZSkKWyAgICAwLjE0OTc4N10gcG5wIDAwOjBjOiBbbWVtIDB4ZmVkMDAwMDAtMHhmZWQwMDNmZl0K
WyAgICAwLjE0OTk2MV0gcG5wIDAwOjBjOiBQbHVnIGFuZCBQbGF5IEFDUEkgZGV2aWNlLCBJRHMg
UE5QMDEwMyAoYWN0aXZlKQpbICAgIDAuMTUwMjExXSBwbnA6IFBuUCBBQ1BJOiBmb3VuZCAxMyBk
ZXZpY2VzClsgICAgMC4xNTAyMTFdIEFDUEk6IEFDUEkgYnVzIHR5cGUgcG5wIHVucmVnaXN0ZXJl
ZApbICAgIDAuMTYwMTQwXSBQTS1UaW1lciBmYWlsZWQgY29uc2lzdGVuY3kgY2hlY2sgICgweDB4
ZmZmZmZmKSAtIGFib3J0aW5nLgpbICAgIDAuMTYwMjc2XSBwY2kgMDAwMDowOTowNi4wOiBhZGRy
ZXNzIHNwYWNlIGNvbGxpc2lvbjogW21lbSAweGRmNjAwMDAwLTB4ZGY2N2ZmZmYgcHJlZl0gY29u
ZmxpY3RzIHdpdGggMDAwMDowOTowNS4wIFttZW0gMHhkZjYwMDAwMC0weGRmNjBmZmZmIHByZWZd
ClsgICAgMC4xNjA0MDBdIFBDSTogbWF4IGJ1cyBkZXB0aDogMiBwY2lfdHJ5X251bTogMwpbICAg
IDAuMTYwNjcyXSBwY2kgMDAwMDowMDoxZi4xOiBCQVIgNTogYXNzaWduZWQgW21lbSAweGJmZmZm
MDAwLTB4YmZmZmYzZmZdClsgICAgMC4xNjA3NzddIHBjaSAwMDAwOjAwOjFmLjE6IEJBUiA1OiBz
ZXQgdG8gW21lbSAweGJmZmZmMDAwLTB4YmZmZmYzZmZdIChQQ0kgYWRkcmVzcyBbMHhiZmZmZjAw
MC0weGJmZmZmM2ZmXSkKWyAgICAwLjE2MDg5M10gcGNpIDAwMDA6MDE6MDAuMDogUENJIGJyaWRn
ZSB0byBbYnVzIDAyLTAyXQpbICAgIDAuMTYwOTg5XSBwY2kgMDAwMDowMTowMC4wOiAgIGJyaWRn
ZSB3aW5kb3cgW2lvICAweGUwMDAtMHhlZmZmXQpbICAgIDAuMTYxMDk0XSBwY2kgMDAwMDowMTow
MC4wOiAgIGJyaWRnZSB3aW5kb3cgW21lbSAweGRmZDAwMDAwLTB4ZGZlZmZmZmZdClsgICAgMC4x
NjExOTZdIHBjaSAwMDAwOjAxOjAwLjA6ICAgYnJpZGdlIHdpbmRvdyBbbWVtIDB4ZDgwMDAwMDAt
MHhkOGZmZmZmZiA2NGJpdCBwcmVmXQpbICAgIDAuMTYxMzIwXSBwY2kgMDAwMDowMTowMC4yOiBQ
Q0kgYnJpZGdlIHRvIFtidXMgMDMtMDNdClsgICAgMC4xNjE0MTJdIHBjaSAwMDAwOjAxOjAwLjI6
ICAgYnJpZGdlIHdpbmRvdyBbaW8gIGRpc2FibGVkXQpbICAgIDAuMTYxNTE0XSBwY2kgMDAwMDow
MTowMC4yOiAgIGJyaWRnZSB3aW5kb3cgW21lbSBkaXNhYmxlZF0KWyAgICAwLjE2MTYxM10gcGNp
IDAwMDA6MDE6MDAuMjogICBicmlkZ2Ugd2luZG93IFttZW0gcHJlZiBkaXNhYmxlZF0KWyAgICAw
LjE2MTcyMV0gcGNpIDAwMDA6MDA6MDIuMDogUENJIGJyaWRnZSB0byBbYnVzIDAxLTAzXQpbICAg
IDAuMTYxODE3XSBwY2kgMDAwMDowMDowMi4wOiAgIGJyaWRnZSB3aW5kb3cgW2lvICAweGUwMDAt
MHhlZmZmXQpbICAgIDAuMTYxOTIyXSBwY2kgMDAwMDowMDowMi4wOiAgIGJyaWRnZSB3aW5kb3cg
W21lbSAweGRmYzAwMDAwLTB4ZGZlZmZmZmZdClsgICAgMC4xNjIwMjRdIHBjaSAwMDAwOjAwOjAy
LjA6ICAgYnJpZGdlIHdpbmRvdyBbbWVtIDB4ZDgwMDAwMDAtMHhkOGZmZmZmZiA2NGJpdCBwcmVm
XQpbICAgIDAuMTYyMTQ4XSBwY2kgMDAwMDowMDowNC4wOiBQQ0kgYnJpZGdlIHRvIFtidXMgMDQt
MDRdClsgICAgMC4xNjIyNDBdIHBjaSAwMDAwOjAwOjA0LjA6ICAgYnJpZGdlIHdpbmRvdyBbaW8g
IGRpc2FibGVkXQpbICAgIDAuMTYyMzQzXSBwY2kgMDAwMDowMDowNC4wOiAgIGJyaWRnZSB3aW5k
b3cgW21lbSBkaXNhYmxlZF0KWyAgICAwLjE2MjQ0Ml0gcGNpIDAwMDA6MDA6MDQuMDogICBicmlk
Z2Ugd2luZG93IFttZW0gcHJlZiBkaXNhYmxlZF0KWyAgICAwLjE2MjU1MV0gcGNpIDAwMDA6MDU6
MDAuMDogUENJIGJyaWRnZSB0byBbYnVzIDA2LTA2XQpbICAgIDAuMTYyNjQ3XSBwY2kgMDAwMDow
NTowMC4wOiAgIGJyaWRnZSB3aW5kb3cgW2lvICAweGQwMDAtMHhkZmZmXQpbICAgIDAuMTYyNzUx
XSBwY2kgMDAwMDowNTowMC4wOiAgIGJyaWRnZSB3aW5kb3cgW21lbSAweGRmYTAwMDAwLTB4ZGZi
ZmZmZmZdClsgICAgMC4xNjI4NTJdIHBjaSAwMDAwOjA1OjAwLjA6ICAgYnJpZGdlIHdpbmRvdyBb
bWVtIHByZWYgZGlzYWJsZWRdClsgICAgMC4xNjI5NjBdIHBjaSAwMDAwOjA1OjAwLjI6IFBDSSBi
cmlkZ2UgdG8gW2J1cyAwNy0wN10KWyAgICAwLjE2MzA1Nl0gcGNpIDAwMDA6MDU6MDAuMjogICBi
cmlkZ2Ugd2luZG93IFtpbyAgMHhjMDAwLTB4Y2ZmZl0KWyAgICAwLjE2MzE2MV0gcGNpIDAwMDA6
MDU6MDAuMjogICBicmlkZ2Ugd2luZG93IFttZW0gMHhkZjgwMDAwMC0weGRmOWZmZmZmXQpbICAg
IDAuMTYzMjYyXSBwY2kgMDAwMDowNTowMC4yOiAgIGJyaWRnZSB3aW5kb3cgW21lbSBwcmVmIGRp
c2FibGVkXQpbICAgIDAuMTYzMzY5XSBwY2kgMDAwMDowMDowNS4wOiBQQ0kgYnJpZGdlIHRvIFti
dXMgMDUtMDddClsgICAgMC4xNjM0NjVdIHBjaSAwMDAwOjAwOjA1LjA6ICAgYnJpZGdlIHdpbmRv
dyBbaW8gIDB4YzAwMC0weGRmZmZdClsgICAgMC4xNjM1NjldIHBjaSAwMDAwOjAwOjA1LjA6ICAg
YnJpZGdlIHdpbmRvdyBbbWVtIDB4ZGY3MDAwMDAtMHhkZmJmZmZmZl0KWyAgICAwLjE2MzY3MF0g
cGNpIDAwMDA6MDA6MDUuMDogICBicmlkZ2Ugd2luZG93IFttZW0gcHJlZiBkaXNhYmxlZF0KWyAg
ICAwLjE2Mzc3OF0gcGNpIDAwMDA6MDA6MDYuMDogUENJIGJyaWRnZSB0byBbYnVzIDA4LTA4XQpb
ICAgIDAuMTYzODcwXSBwY2kgMDAwMDowMDowNi4wOiAgIGJyaWRnZSB3aW5kb3cgW2lvICBkaXNh
YmxlZF0KWyAgICAwLjE2Mzk3Ml0gcGNpIDAwMDA6MDA6MDYuMDogICBicmlkZ2Ugd2luZG93IFtt
ZW0gZGlzYWJsZWRdClsgICAgMC4xNjQwNzJdIHBjaSAwMDAwOjAwOjA2LjA6ICAgYnJpZGdlIHdp
bmRvdyBbbWVtIHByZWYgZGlzYWJsZWRdClsgICAgMC4xNjQxODNdIHBjaSAwMDAwOjA5OjA2LjA6
IEJBUiA2OiBhc3NpZ25lZCBbbWVtIDB4ZDAwMDAwMDAtMHhkMDA3ZmZmZiBwcmVmXQpbICAgIDAu
MTY0Mjk1XSBwY2kgMDAwMDowOTowZC4wOiBCQVIgNjogYXNzaWduZWQgW21lbSAweGQwMDgwMDAw
LTB4ZDAwOWZmZmYgcHJlZl0KWyAgICAwLjE2NDQwN10gcGNpIDAwMDA6MDA6MWUuMDogUENJIGJy
aWRnZSB0byBbYnVzIDA5LTA5XQpbICAgIDAuMTY0NTAzXSBwY2kgMDAwMDowMDoxZS4wOiAgIGJy
aWRnZSB3aW5kb3cgW2lvICAweGIwMDAtMHhiZmZmXQpbICAgIDAuMTY0NjA4XSBwY2kgMDAwMDow
MDoxZS4wOiAgIGJyaWRnZSB3aW5kb3cgW21lbSAweGRmNTAwMDAwLTB4ZGY2ZmZmZmZdClsgICAg
MC4xNjQ3MTBdIHBjaSAwMDAwOjAwOjFlLjA6ICAgYnJpZGdlIHdpbmRvdyBbbWVtIDB4YzgwMDAw
MDAtMHhkN2ZmZmZmZiBwcmVmXQpbICAgIDAuMTY0ODQ4XSB4ZW46IHJlZ2lzdGVyaW5nIGdzaSAx
NiB0cmlnZ2VyaW5nIDAgcG9sYXJpdHkgMQpbICAgIDAuMTY0OTUwXSB4ZW46IC0tPiBwaXJxPTE2
IC0+IGlycT0xNiAoZ3NpPTE2KQpbICAgIDAuMTY1MDQ4XSBwY2kgMDAwMDowMDowMi4wOiBQQ0kg
SU5UIEEgLT4gR1NJIDE2IChsZXZlbCwgbG93KSAtPiBJUlEgMTYKWyAgICAwLjE2NTE1M10gcGNp
IDAwMDA6MDA6MDIuMDogc2V0dGluZyBsYXRlbmN5IHRpbWVyIHRvIDY0ClsgICAgMC4xNjUyNjhd
IHBjaSAwMDAwOjAxOjAwLjA6IHNldHRpbmcgbGF0ZW5jeSB0aW1lciB0byA2NApbICAgIDAuMTY1
MzgyXSBwY2kgMDAwMDowMTowMC4yOiBzZXR0aW5nIGxhdGVuY3kgdGltZXIgdG8gNjQKWyAgICAw
LjE2NTQ4OV0geGVuOiByZWdpc3RlcmluZyBnc2kgMTYgdHJpZ2dlcmluZyAwIHBvbGFyaXR5IDEK
WyAgICAwLjE2NTU4Ml0geGVuX21hcF9waXJxX2dzaTogcmV0dXJuaW5nIGlycSAxNiBmb3IgZ3Np
IDE2ClsgICAgMC4xNjU2NzRdIHhlbjogLS0+IHBpcnE9MTYgLT4gaXJxPTE2IChnc2k9MTYpClsg
ICAgMC4xNjU3NjddIEFscmVhZHkgc2V0dXAgdGhlIEdTSSA6MTYKWyAgICAwLjE2NTg1OF0gcGNp
IDAwMDA6MDA6MDQuMDogUENJIElOVCBBIC0+IEdTSSAxNiAobGV2ZWwsIGxvdykgLT4gSVJRIDE2
ClsgICAgMC4xNjU5NjFdIHBjaSAwMDAwOjAwOjA0LjA6IHNldHRpbmcgbGF0ZW5jeSB0aW1lciB0
byA2NApbICAgIDAuMTY2MDY4XSB4ZW46IHJlZ2lzdGVyaW5nIGdzaSAxNiB0cmlnZ2VyaW5nIDAg
cG9sYXJpdHkgMQpbICAgIDAuMTY2MTYxXSB4ZW5fbWFwX3BpcnFfZ3NpOiByZXR1cm5pbmcgaXJx
IDE2IGZvciBnc2kgMTYKWyAgICAwLjE2NjI1M10geGVuOiAtLT4gcGlycT0xNiAtPiBpcnE9MTYg
KGdzaT0xNikKWyAgICAwLjE2NjM0Nl0gQWxyZWFkeSBzZXR1cCB0aGUgR1NJIDoxNgpbICAgIDAu
MTY2NDM3XSBwY2kgMDAwMDowMDowNS4wOiBQQ0kgSU5UIEEgLT4gR1NJIDE2IChsZXZlbCwgbG93
KSAtPiBJUlEgMTYKWyAgICAwLjE2NjU0MF0gcGNpIDAwMDA6MDA6MDUuMDogc2V0dGluZyBsYXRl
bmN5IHRpbWVyIHRvIDY0ClsgICAgMC4xNjY2NTRdIHBjaSAwMDAwOjA1OjAwLjA6IHNldHRpbmcg
bGF0ZW5jeSB0aW1lciB0byA2NApbICAgIDAuMTY2NzY5XSBwY2kgMDAwMDowNTowMC4yOiBzZXR0
aW5nIGxhdGVuY3kgdGltZXIgdG8gNjQKWyAgICAwLjE2Njg3Nl0geGVuOiByZWdpc3RlcmluZyBn
c2kgMTYgdHJpZ2dlcmluZyAwIHBvbGFyaXR5IDEKWyAgICAwLjE2Njk2OF0geGVuX21hcF9waXJx
X2dzaTogcmV0dXJuaW5nIGlycSAxNiBmb3IgZ3NpIDE2ClsgICAgMC4xNjcwNjFdIHhlbjogLS0+
IHBpcnE9MTYgLT4gaXJxPTE2IChnc2k9MTYpClsgICAgMC4xNjcxNTNdIEFscmVhZHkgc2V0dXAg
dGhlIEdTSSA6MTYKWyAgICAwLjE2NzI0NF0gcGNpIDAwMDA6MDA6MDYuMDogUENJIElOVCBBIC0+
IEdTSSAxNiAobGV2ZWwsIGxvdykgLT4gSVJRIDE2ClsgICAgMC4xNjczNDddIHBjaSAwMDAwOjAw
OjA2LjA6IHNldHRpbmcgbGF0ZW5jeSB0aW1lciB0byA2NApbICAgIDAuMTY3NDU5XSBwY2kgMDAw
MDowMDoxZS4wOiBzZXR0aW5nIGxhdGVuY3kgdGltZXIgdG8gNjQKWyAgICAwLjE2NzU2MF0gcGNp
X2J1cyAwMDAwOjAwOiByZXNvdXJjZSAwIFtpbyAgMHgwMDAwLTB4ZmZmZl0KWyAgICAwLjE2NzY1
Nl0gcGNpX2J1cyAwMDAwOjAwOiByZXNvdXJjZSAxIFttZW0gMHgwMDAwMDAwMC0weGZmZmZmZmZm
Zl0KWyAgICAwLjE2Nzc1MV0gcGNpX2J1cyAwMDAwOjAxOiByZXNvdXJjZSAwIFtpbyAgMHhlMDAw
LTB4ZWZmZl0KWyAgICAwLjE2Nzg0NF0gcGNpX2J1cyAwMDAwOjAxOiByZXNvdXJjZSAxIFttZW0g
MHhkZmMwMDAwMC0weGRmZWZmZmZmXQpbICAgIDAuMTY3OTM5XSBwY2lfYnVzIDAwMDA6MDE6IHJl
c291cmNlIDIgW21lbSAweGQ4MDAwMDAwLTB4ZDhmZmZmZmYgNjRiaXQgcHJlZl0KWyAgICAwLjE2
ODA0OV0gcGNpX2J1cyAwMDAwOjAyOiByZXNvdXJjZSAwIFtpbyAgMHhlMDAwLTB4ZWZmZl0KWyAg
ICAwLjE2ODE0M10gcGNpX2J1cyAwMDAwOjAyOiByZXNvdXJjZSAxIFttZW0gMHhkZmQwMDAwMC0w
eGRmZWZmZmZmXQpbICAgIDAuMTY4MjM3XSBwY2lfYnVzIDAwMDA6MDI6IHJlc291cmNlIDIgW21l
bSAweGQ4MDAwMDAwLTB4ZDhmZmZmZmYgNjRiaXQgcHJlZl0KWyAgICAwLjE2ODM0OF0gcGNpX2J1
cyAwMDAwOjA1OiByZXNvdXJjZSAwIFtpbyAgMHhjMDAwLTB4ZGZmZl0KWyAgICAwLjE2ODQ0MV0g
cGNpX2J1cyAwMDAwOjA1OiByZXNvdXJjZSAxIFttZW0gMHhkZjcwMDAwMC0weGRmYmZmZmZmXQpb
ICAgIDAuMTY4NTM2XSBwY2lfYnVzIDAwMDA6MDY6IHJlc291cmNlIDAgW2lvICAweGQwMDAtMHhk
ZmZmXQpbICAgIDAuMTY4NjI5XSBwY2lfYnVzIDAwMDA6MDY6IHJlc291cmNlIDEgW21lbSAweGRm
YTAwMDAwLTB4ZGZiZmZmZmZdClsgICAgMC4xNjg3MjddIHBjaV9idXMgMDAwMDowNzogcmVzb3Vy
Y2UgMCBbaW8gIDB4YzAwMC0weGNmZmZdClsgICAgMC4xNjg4MjBdIHBjaV9idXMgMDAwMDowNzog
cmVzb3VyY2UgMSBbbWVtIDB4ZGY4MDAwMDAtMHhkZjlmZmZmZl0KWyAgICAwLjE2ODkxNV0gcGNp
X2J1cyAwMDAwOjA5OiByZXNvdXJjZSAwIFtpbyAgMHhiMDAwLTB4YmZmZl0KWyAgICAwLjE2OTAw
OV0gcGNpX2J1cyAwMDAwOjA5OiByZXNvdXJjZSAxIFttZW0gMHhkZjUwMDAwMC0weGRmNmZmZmZm
XQpbICAgIDAuMTY5MTAzXSBwY2lfYnVzIDAwMDA6MDk6IHJlc291cmNlIDIgW21lbSAweGM4MDAw
MDAwLTB4ZDdmZmZmZmYgcHJlZl0KWyAgICAwLjE2OTE5OV0gcGNpX2J1cyAwMDAwOjA5OiByZXNv
dXJjZSA0IFtpbyAgMHgwMDAwLTB4ZmZmZl0KWyAgICAwLjE2OTI5Ml0gcGNpX2J1cyAwMDAwOjA5
OiByZXNvdXJjZSA1IFttZW0gMHgwMDAwMDAwMC0weGZmZmZmZmZmZl0KWyAgICAwLjE2OTU5M10g
TkVUOiBSZWdpc3RlcmVkIHByb3RvY29sIGZhbWlseSAyClsgICAgMC4xNjk4NjNdIElQIHJvdXRl
IGNhY2hlIGhhc2ggdGFibGUgZW50cmllczogNDA5NiAob3JkZXI6IDIsIDE2Mzg0IGJ5dGVzKQpb
ICAgIDAuMTcwMzMxXSBUQ1AgZXN0YWJsaXNoZWQgaGFzaCB0YWJsZSBlbnRyaWVzOiAxNjM4NCAo
b3JkZXI6IDUsIDEzMTA3MiBieXRlcykKWyAgICAwLjE3MDUyOV0gVENQIGJpbmQgaGFzaCB0YWJs
ZSBlbnRyaWVzOiAxNjM4NCAob3JkZXI6IDUsIDEzMTA3MiBieXRlcykKWyAgICAwLjE3MDcwMl0g
VENQOiBIYXNoIHRhYmxlcyBjb25maWd1cmVkIChlc3RhYmxpc2hlZCAxNjM4NCBiaW5kIDE2Mzg0
KQpbICAgIDAuMTcwNzk2XSBUQ1AgcmVubyByZWdpc3RlcmVkClsgICAgMC4xNzA4ODhdIFVEUCBo
YXNoIHRhYmxlIGVudHJpZXM6IDI1NiAob3JkZXI6IDEsIDgxOTIgYnl0ZXMpClsgICAgMC4xNzA5
ODhdIFVEUC1MaXRlIGhhc2ggdGFibGUgZW50cmllczogMjU2IChvcmRlcjogMSwgODE5MiBieXRl
cykKWyAgICAwLjE3MTUxMV0gTkVUOiBSZWdpc3RlcmVkIHByb3RvY29sIGZhbWlseSAxClsgICAg
MC4xNzM3NjZdIFBDSTogQ0xTIG1pc21hdGNoICg2NCAhPSA0KSwgdXNpbmcgNjQgYnl0ZXMKWyAg
ICAwLjE3Mzg3MF0gcGNpIDAwMDA6MDk6MGQuMDogQm9vdCB2aWRlbyBkZXZpY2UKWyAgICAwLjE3
NDA1Ml0gVW5wYWNraW5nIGluaXRyYW1mcy4uLgpbICAgIDAuMTgxNjMxXSBGcmVlaW5nIGluaXRy
ZCBtZW1vcnk6IDM4MDRrIGZyZWVkClsgICAgMC4xODQ3NTZdIG1pY3JvY29kZTogQ1BVMCBzaWc9
MHhmNDMsIHBmPTB4MSwgcmV2aXNpb249MHg1ClsgICAgMC4xODQ4NzddIG1pY3JvY29kZTogQ1BV
MSBzaWc9MHhmNDMsIHBmPTB4MSwgcmV2aXNpb249MHg1ClsgICAgMC4xODUwMjBdIG1pY3JvY29k
ZTogQ1BVMiBzaWc9MHhmNDMsIHBmPTB4MSwgcmV2aXNpb249MHg1ClsgICAgMC4xODUxNTNdIG1p
Y3JvY29kZTogQ1BVMyBzaWc9MHhmNDMsIHBmPTB4MSwgcmV2aXNpb249MHg1ClsgICAgMC4xODUy
OTBdIG1pY3JvY29kZTogTWljcm9jb2RlIFVwZGF0ZSBEcml2ZXI6IHYyLjAwIDx0aWdyYW5AYWl2
YXppYW4uZnNuZXQuY28udWs+LCBQZXRlciBPcnViYQpbICAgIDAuMTg4MTUyXSBtc2dtbmkgaGFz
IGJlZW4gc2V0IHRvIDc1OQpbICAgIDAuMTg4ODcwXSBCbG9jayBsYXllciBTQ1NJIGdlbmVyaWMg
KGJzZykgZHJpdmVyIHZlcnNpb24gMC40IGxvYWRlZCAobWFqb3IgMjU0KQpbICAgIDAuMTg4OTg4
XSBpbyBzY2hlZHVsZXIgbm9vcCByZWdpc3RlcmVkClsgICAgMC4xODkwNzldIGlvIHNjaGVkdWxl
ciBkZWFkbGluZSByZWdpc3RlcmVkClsgICAgMC4xODkyMzBdIGlvIHNjaGVkdWxlciBjZnEgcmVn
aXN0ZXJlZCAoZGVmYXVsdCkKWyAgICAwLjE5MDE2MF0gQUNQSTogYWNwaV9pZGxlIHJlZ2lzdGVy
ZWQgd2l0aCBjcHVpZGxlClsgICAgMC4xOTc4NDBdIEV2ZW50LWNoYW5uZWwgZGV2aWNlIGluc3Rh
bGxlZC4KWyAgICAwLjE5ODM4NV0gU2VyaWFsOiA4MjUwLzE2NTUwIGRyaXZlciwgNCBwb3J0cywg
SVJRIHNoYXJpbmcgZW5hYmxlZApbICAgIDAuNTAwNTQwXSBzZXJpYWw4MjUwOiB0dHlTMCBhdCBJ
L08gMHgzZjggKGlycSA9IDQpIGlzIGEgMTY1NTBBClsgICAgMS4wODAwNTldIDAwOjA4OiB0dHlT
MCBhdCBJL08gMHgzZjggKGlycSA9IDQpIGlzIGEgMTY1NTBBClsgICAgMS4yMzAyMjVdIHhlbjog
cmVnaXN0ZXJpbmcgZ3NpIDIxIHRyaWdnZXJpbmcgMCBwb2xhcml0eSAxClsgICAgMS4yMzAzMjVd
IHhlbjogLS0+IHBpcnE9MjEgLT4gaXJxPTIxIChnc2k9MjEpClsgICAgMS4yMzA0MjZdIHNlcmlh
bCAwMDAwOjA5OjA1LjE6IFBDSSBJTlQgQiAtPiBHU0kgMjEgKGxldmVsLCBsb3cpIC0+IElSUSAy
MQpbICAgIDEuMjQwMDU5XSAwMDAwOjA5OjA1LjE6IHR0eVMxIGF0IEkvTyAweGJjODAgKGlycSA9
IDIxKSBpcyBhIDE2NTUwQQpbICAgIDEuMzkwMjEyXSBSZWFsIFRpbWUgQ2xvY2sgRHJpdmVyIHYx
LjEyYgpbICAgIDEuMzkwNDUxXSBpbnRlbF9ybmc6IEZXSCBub3QgZGV0ZWN0ZWQKWyAgICAxLjM5
MTk3MF0gaTgwNDI6IFBOUDogUFMvMiBDb250cm9sbGVyIFtQTlAwMzAzOktCRCxQTlAwZjEzOk1P
VV0gYXQgMHg2MCwweDY0IGlycSAxLDEyClsgICAgMS4zOTQ3ODVdIHNlcmlvOiBpODA0MiBLQkQg
cG9ydCBhdCAweDYwLDB4NjQgaXJxIDEKWyAgICAxLjM5NDg4N10gc2VyaW86IGk4MDQyIEFVWCBw
b3J0IGF0IDB4NjAsMHg2NCBpcnEgMTIKWyAgICAxLjM5NTA3M10gbW91c2VkZXY6IFBTLzIgbW91
c2UgZGV2aWNlIGNvbW1vbiBmb3IgYWxsIG1pY2UKWyAgICAxLjM5NTIwN10gY3B1aWRsZTogdXNp
bmcgZ292ZXJub3IgbGFkZGVyClsgICAgMS4zOTUyOThdIGNwdWlkbGU6IHVzaW5nIGdvdmVybm9y
IG1lbnUKWyAgICAxLjM5NTgxMl0gVENQIGN1YmljIHJlZ2lzdGVyZWQKWyAgICAxLjM5NTkwNF0g
TkVUOiBSZWdpc3RlcmVkIHByb3RvY29sIGZhbWlseSAxNwpbICAgIDEuMzk2MDA2XSBVc2luZyBJ
UEkgTm8tU2hvcnRjdXQgbW9kZQpbICAgIDEuMzk3NjAzXSBGcmVlaW5nIHVudXNlZCBrZXJuZWwg
bWVtb3J5OiAzNzJrIGZyZWVkClsgICAgMS40MDUzOTBdIG5hc2gtaG90cGx1ZyAoMzgpOiAvcHJv
Yy8zOC9vb21fYWRqIGlzIGRlcHJlY2F0ZWQsIHBsZWFzZSB1c2UgL3Byb2MvMzgvb29tX3Njb3Jl
X2FkaiBpbnN0ZWFkLgpbICAgIDEuNDQ5NzEyXSBpbnB1dDogQVQgVHJhbnNsYXRlZCBTZXQgMiBr
ZXlib2FyZCBhcyAvZGV2aWNlcy9wbGF0Zm9ybS9pODA0Mi9zZXJpbzAvaW5wdXQvaW5wdXQwClsg
ICAgMS42NzM3OTRdIFNDU0kgc3Vic3lzdGVtIGluaXRpYWxpemVkClsgICAgMS42ODIwNDBdIEZ1
c2lvbiBNUFQgYmFzZSBkcml2ZXIgMy4wNC4xOQpbICAgIDEuNjgyMTMzXSBDb3B5cmlnaHQgKGMp
IDE5OTktMjAwOCBMU0kgQ29ycG9yYXRpb24KWyAgICAxLjY4NjkyNl0gRnVzaW9uIE1QVCBTUEkg
SG9zdCBkcml2ZXIgMy4wNC4xOQpbICAgIDEuNjg3MDY0XSB4ZW46IHJlZ2lzdGVyaW5nIGdzaSAz
NCB0cmlnZ2VyaW5nIDAgcG9sYXJpdHkgMQpbICAgIDEuNjg3MTY5XSB4ZW46IC0tPiBwaXJxPTM0
IC0+IGlycT0zNCAoZ3NpPTM0KQpbICAgIDEuNjg3MjczXSBtcHRzcGkgMDAwMDowMjowNS4wOiBQ
Q0kgSU5UIEEgLT4gR1NJIDM0IChsZXZlbCwgbG93KSAtPiBJUlEgMzQKWyAgICAxLjY4NzM4MF0g
TlRfREJHOiB4ZW5faW9fdGxiX2VuZDogZGMzMmNmMDAsIGNvbnZlcnRlZCB0byAncGh5cyc6IDFj
MzJjZjAwLCB0aGVuICdidXMnOiAxMjBmZGZlZmYgZm9yIGFuc3dlciAxLgpbICAgIDEuNjg3NDkz
XSBOVF9EQkc6IGRtYV9zdXBwb3J0ZWQgcmV0dXJuaW5nIDEKWyAgICAxLjY4NzU4NV0gTlRfREJH
OiB4ZW5faW9fdGxiX2VuZDogZGMzMmNmMDAsIGNvbnZlcnRlZCB0byAncGh5cyc6IDFjMzJjZjAw
LCB0aGVuICdidXMnOiAxMjBmZGZlZmYgZm9yIGFuc3dlciAxLgpbICAgIDEuNjg3Njk3XSBOVF9E
Qkc6IGRtYV9zdXBwb3J0ZWQgcmV0dXJuaW5nIDEKWyAgICAxLjY4ODA2N10gbXB0YmFzZTogaW9j
MDogSW5pdGlhdGluZyBicmluZ3VwClsgICAgMi45MDAwODVdIGlvYzA6IExTSTUzQzEwMzAgQzA6
IENhcGFiaWxpdGllcz17SW5pdGlhdG9yLFRhcmdldH0KWyAgICA0LjU3ODk4NF0gc2NzaTAgOiBp
b2MwOiBMU0k1M0MxMDMwIEMwLCBGd1Jldj0wMTAzMjMwMGgsIFBvcnRzPTEsIE1heFE9MjU1LCBJ
UlE9MzQKWyAgICA1LjM3ODgzOF0gc2NzaSAwOjA6MDowOiBEaXJlY3QtQWNjZXNzICAgICBNQVhU
T1IgICBBVExBUzEwSzRfNzNTQ0EgIERGTTAgUFE6IDAgQU5TSTogMwpbICAgIDUuMzc4OTcyXSBz
Y3NpIHRhcmdldDA6MDowOiBCZWdpbm5pbmcgRG9tYWluIFZhbGlkYXRpb24KWyAgICA1LjM5MTg2
NV0gc2NzaSB0YXJnZXQwOjA6MDogRW5kaW5nIERvbWFpbiBWYWxpZGF0aW9uClsgICAgNS4zOTIw
ODBdIHNjc2kgdGFyZ2V0MDowOjA6IEZBU1QtMTYwIFdJREUgU0NTSSAzMjAuMCBNQi9zIERUIElV
IFJUSSAoNi4yNSBucywgb2Zmc2V0IDEyNykKWyAgICA1LjM5MzI1N10gc2QgMDowOjA6MDogW3Nk
YV0gMTQzMzc0NjUwIDUxMi1ieXRlIGxvZ2ljYWwgYmxvY2tzOiAoNzMuNCBHQi82OC4zIEdpQikK
WyAgICA1LjM5NTU5NF0gc2NzaSAwOjA6MTowOiBEaXJlY3QtQWNjZXNzICAgICBNQVhUT1IgICBB
VExBUzEwSzVfNzNTQ0EgIEpUMDAgUFE6IDAgQU5TSTogMwpbICAgIDUuMzk1NzUyXSBzY3NpIHRh
cmdldDA6MDoxOiBCZWdpbm5pbmcgRG9tYWluIFZhbGlkYXRpb24KWyAgICA1LjM5NTc4N10gc2Qg
MDowOjA6MDogW3NkYV0gV3JpdGUgUHJvdGVjdCBpcyBvZmYKWyAgICA1LjM5NTgwMl0gc2QgMDow
OjA6MDogW3NkYV0gTW9kZSBTZW5zZTogZWQgMDAgMTAgMDgKWyAgICA1LjM5NzcyM10gc2QgMDow
OjA6MDogW3NkYV0gV3JpdGUgY2FjaGU6IGRpc2FibGVkLCByZWFkIGNhY2hlOiBlbmFibGVkLCBz
dXBwb3J0cyBEUE8gYW5kIEZVQQpbICAgIDUuNDEwOTYxXSBzY3NpIHRhcmdldDA6MDoxOiBFbmRp
bmcgRG9tYWluIFZhbGlkYXRpb24KWyAgICA1LjQxMTE3NV0gc2NzaSB0YXJnZXQwOjA6MTogRkFT
VC0xNjAgV0lERSBTQ1NJIDMyMC4wIE1CL3MgRFQgSVUgUlRJICg2LjI1IG5zLCBvZmZzZXQgMTI3
KQpbICAgIDUuNDEyMzM3XSBzZCAwOjA6MTowOiBbc2RiXSAxNDMzNzQ2NTAgNTEyLWJ5dGUgbG9n
aWNhbCBibG9ja3M6ICg3My40IEdCLzY4LjMgR2lCKQpbICAgIDUuOTEyOTM1XSBzZCAwOjA6MTow
OiBbc2RiXSBXcml0ZSBQcm90ZWN0IGlzIG9mZgpbICAgIDUuOTEyOTkwXSAgc2RhOiBzZGExIHNk
YTIgc2RhMyBzZGE0IDwgc2RhNSA+ClsgICAgNS45MTMxNjddIHNkIDA6MDoxOjA6IFtzZGJdIE1v
ZGUgU2Vuc2U6IGJmIDAwIDEwIDA4ClsgICAgNi40MTcwNjhdIHNkIDA6MDoxOjA6IFtzZGJdIFdy
aXRlIGNhY2hlOiBkaXNhYmxlZCwgcmVhZCBjYWNoZTogZW5hYmxlZCwgc3VwcG9ydHMgRFBPIGFu
ZCBGVUEKWyAgICA2LjQyMjE1OV0gc2NzaSAwOjA6NjowOiBQcm9jZXNzb3IgICAgICAgICBQRS9Q
ViAgICAxeDIgU0NTSSBCUCAgICAgIDEuMCAgUFE6IDAgQU5TSTogMgpbICAgIDYuNDIyMzEzXSBz
Y3NpIHRhcmdldDA6MDo2OiBCZWdpbm5pbmcgRG9tYWluIFZhbGlkYXRpb24KWyAgICA2LjQyNzU2
M10gc2QgMDowOjA6MDogW3NkYV0gQXR0YWNoZWQgU0NTSSBkaXNrClsgICAgNi40NDI4OTZdIHNj
c2kgdGFyZ2V0MDowOjY6IEVuZGluZyBEb21haW4gVmFsaWRhdGlvbgpbICAgIDYuNDQzMTQ2XSBz
Y3NpIHRhcmdldDA6MDo2OiBhc3luY2hyb25vdXMKWyAgICA2LjQ0ODA3MF0gIHNkYjogc2RiMQpb
ICAgIDcuNDU0OTE1XSBzZCAwOjA6MTowOiBbc2RiXSBBdHRhY2hlZCBTQ1NJIGRpc2sKWyAgICA4
LjQ2MjE0OF0gRnVzaW9uIE1QVCBTQVMgSG9zdCBkcml2ZXIgMy4wNC4xOQpbICAgIDguNDY5ODE1
XSBsaWJhdGEgdmVyc2lvbiAzLjAwIGxvYWRlZC4KWyAgICA4LjQ3MjU1Nl0gYXRhX3BpaXggMDAw
MDowMDoxZi4xOiB2ZXJzaW9uIDIuMTMKWyAgICA4LjQ3MjY2N10gYXRhX3BpaXggMDAwMDowMDox
Zi4xOiBlbmFibGluZyBkZXZpY2UgKDAwMDUgLT4gMDAwNykKWyAgICA4LjQ3Mjc2OV0gYXRhX3Bp
aXggMDAwMDowMDoxZi4xOiBjYW4ndCBkZXJpdmUgcm91dGluZyBmb3IgUENJIElOVCBBClsgICAg
OC40NzI5MjFdIE5UX0RCRzogeGVuX2lvX3RsYl9lbmQ6IGRjMzJjZjAwLCBjb252ZXJ0ZWQgdG8g
J3BoeXMnOiAxYzMyY2YwMCwgdGhlbiAnYnVzJzogMTIwZmRmZWZmIGZvciBhbnN3ZXIgMS4KWyAg
ICA4LjQ3MzAzNV0gTlRfREJHOiBkbWFfc3VwcG9ydGVkIHJldHVybmluZyAwClsgICAgOC40NzMx
MjZdIGF0YV9waWl4IDAwMDA6MDA6MWYuMTogQk1ETUE6IGZhaWxlZCB0byBzZXQgZG1hIG1hc2ss
IGZhbGxpbmcgYmFjayB0byBQSU8KWyAgICA4LjQ3MzI3M10gYXRhX3BpaXggMDAwMDowMDoxZi4x
OiBzZXR0aW5nIGxhdGVuY3kgdGltZXIgdG8gNjQKWyAgICA4LjQ3Mzk3M10gc2NzaTEgOiBhdGFf
cGlpeApbICAgIDguNDc0MjUwXSBzY3NpMiA6IGF0YV9waWl4ClsgICAgOC40NzQ0MjddIGF0YTE6
IFBBVEEgbWF4IFBJTzQgY21kIDB4MWYwIGN0bCAweDNmNiBibWRtYSAweGZjMDAgaXJxIDE0Clsg
ICAgOC40NzQ1MjNdIGF0YTI6IFBBVEEgbWF4IFBJTzQgY21kIDB4MTcwIGN0bCAweDM3NiBibWRt
YSAweGZjMDggaXJxIDE1ClsgICAgOC42NTA0NTNdIGF0YTEuMDA6IEFUQVBJOiBQSElMSVBTIERW
RC1ST00gU0RSMDg5LCBURDM2LCBtYXggVURNQS8zMwpbICAgIDguNjcwMzMzXSBhdGExLjAwOiBj
b25maWd1cmVkIGZvciBQSU80ClsgICAgOC42NzE2ODddIHNjc2kgMTowOjA6MDogQ0QtUk9NICAg
ICAgICAgICAgUEhJTElQUyAgRFZELVJPTSBTRFIwODkgICBURDM2IFBROiAwIEFOU0k6IDUKWyAg
IDE5Ljg5MDAxM10gRVhUMy1mczogYmFycmllcnMgbm90IGVuYWJsZWQKWyAgIDE5LjkwMzc0NV0g
a2pvdXJuYWxkIHN0YXJ0aW5nLiAgQ29tbWl0IGludGVydmFsIDUgc2Vjb25kcwpbICAgMTkuOTAz
OTAxXSBFWFQzLWZzIChzZGEzKTogbW91bnRlZCBmaWxlc3lzdGVtIHdpdGggb3JkZXJlZCBkYXRh
IG1vZGUKWyAgIDIxLjY4NzQyN10gaW5wdXQ6IFBDIFNwZWFrZXIgYXMgL2RldmljZXMvcGxhdGZv
cm0vcGNzcGtyL2lucHV0L2lucHV0MQpbICAgMjEuODYxMjUwXSBpVENPX3ZlbmRvcl9zdXBwb3J0
OiB2ZW5kb3Itc3VwcG9ydD0wClsgICAyMS44NjQ1OTVdIGlUQ09fd2R0OiBJbnRlbCBUQ08gV2F0
Y2hEb2cgVGltZXIgRHJpdmVyIHYxLjA2ClsgICAyMS44NjQ3OTRdIGlUQ09fd2R0OiBGb3VuZCBh
IElDSDUgb3IgSUNINVIgVENPIGRldmljZSAoVmVyc2lvbj0xLCBUQ09CQVNFPTB4MDg2MCkKWyAg
IDIxLjg2NDk2Nl0gaVRDT193ZHQ6IGluaXRpYWxpemVkLiBoZWFydGJlYXQ9MzAgc2VjIChub3dh
eW91dD0xKQpbICAgMjEuODY1NjUyXSB4ZW46IHJlZ2lzdGVyaW5nIGdzaSAyMyB0cmlnZ2VyaW5n
IDAgcG9sYXJpdHkgMQpbICAgMjEuODY1Njc2XSB4ZW46IC0tPiBwaXJxPTIzIC0+IGlycT0yMyAo
Z3NpPTIzKQpbICAgMjEuODY1NzAwXSBwYXRhX2FjcGkgMDAwMDowOTowNi4wOiBQQ0kgSU5UIEEg
LT4gR1NJIDIzIChsZXZlbCwgbG93KSAtPiBJUlEgMjMKWyAgIDIxLjg2NTc3OF0gTlRfREJHOiB4
ZW5faW9fdGxiX2VuZDogZGMzMmNmMDAsIGNvbnZlcnRlZCB0byAncGh5cyc6IDFjMzJjZjAwLCB0
aGVuICdidXMnOiAxMjBmZGZlZmYgZm9yIGFuc3dlciAxLgpbICAgMjEuODY1Nzg3XSBOVF9EQkc6
IGRtYV9zdXBwb3J0ZWQgcmV0dXJuaW5nIDAKWyAgIDIxLjg2NTc5Nl0gcGF0YV9hY3BpIDAwMDA6
MDk6MDYuMDogQk1ETUE6IGZhaWxlZCB0byBzZXQgZG1hIG1hc2ssIGZhbGxpbmcgYmFjayB0byBQ
SU8KWyAgIDIxLjg2NTg1OV0gcGF0YV9hY3BpIDAwMDA6MDk6MDYuMDogUENJIElOVCBBIGRpc2Fi
bGVkClsgICAyMS44ODg5ODFdIHBhdGFfc2lsNjgwIDAwMDA6MDk6MDYuMDogdmVyc2lvbiAwLjQu
OQpbICAgMjEuODg5MDExXSB4ZW46IHJlZ2lzdGVyaW5nIGdzaSAyMyB0cmlnZ2VyaW5nIDAgcG9s
YXJpdHkgMQpbICAgMjEuODg5MDIwXSB4ZW5fbWFwX3BpcnFfZ3NpOiByZXR1cm5pbmcgaXJxIDIz
IGZvciBnc2kgMjMKWyAgIDIxLjg4OTAyNl0geGVuOiAtLT4gcGlycT0yMyAtPiBpcnE9MjMgKGdz
aT0yMykKWyAgIDIxLjg4OTAzNl0gQWxyZWFkeSBzZXR1cCB0aGUgR1NJIDoyMwpbICAgMjEuODg5
MDQ0XSBwYXRhX3NpbDY4MCAwMDAwOjA5OjA2LjA6IFBDSSBJTlQgQSAtPiBHU0kgMjMgKGxldmVs
LCBsb3cpIC0+IElSUSAyMwpbICAgMjEuODg5MTA4XSBzaWw2ODA6IDEzM01IeiBjbG9jay4KWyAg
IDIxLjg4OTE2OV0gTlRfREJHOiB4ZW5faW9fdGxiX2VuZDogZGMzMmNmMDAsIGNvbnZlcnRlZCB0
byAncGh5cyc6IDFjMzJjZjAwLCB0aGVuICdidXMnOiAxMjBmZGZlZmYgZm9yIGFuc3dlciAxLgpb
ICAgMjEuODg5MTc2XSBOVF9EQkc6IGRtYV9zdXBwb3J0ZWQgcmV0dXJuaW5nIDAKWyAgIDIxLjg4
OTE4Ml0gcGF0YV9zaWw2ODAgMDAwMDowOTowNi4wOiBCTURNQTogZmFpbGVkIHRvIHNldCBkbWEg
bWFzaywgZmFsbGluZyBiYWNrIHRvIFBJTwpbICAgMjEuODg5ODExXSBzY3NpMyA6IHBhdGFfc2ls
NjgwClsgICAyMS44OTAwMDhdIHNjc2k0IDogcGF0YV9zaWw2ODAKWyAgIDIxLjg5MDE2Nl0gYXRh
MzogUEFUQSBtYXggUElPNCBjbWQgMHhiY2YwIGN0bCAweGJjZTQgYm1kbWEgMHhiYzcwIGlycSAy
MwpbICAgMjEuODkwMTc2XSBhdGE0OiBQQVRBIG1heCBQSU80IGNtZCAweGJjZDggY3RsIDB4YmNk
MCBibWRtYSAweGJjNzggaXJxIDIzClsgICAyMi4wOTE1MjVdIGF0YTMuMDA6IEFUQVBJOiBWSVJU
VUFMRkxPUFBZIERSSVZFICAgICAgICAgICAgICAgRmxvcHB5LCAsIG1heCBQSU8zClsgICAyMi4w
OTE1NDJdIGF0YTMuMDE6IEFUQVBJOiBWSVJUVUFMQ0RST00gRFJJVkUsICwgbWF4IFBJTzMKWyAg
IDIyLjExMDUxM10gYXRhMy4wMDogY29uZmlndXJlZCBmb3IgUElPMwpbICAgMjIuMTMwNDY4XSBh
dGEzLjAxOiBjb25maWd1cmVkIGZvciBQSU8zClsgICAyMi4xNjU3MzhdIHNjc2kgMzowOjA6MDog
RGlyZWN0LUFjY2VzcyAgICAgREVMTCAgICAgICBWU0YgICAgICAgICAgICAwMTIzIFBROiAwIEFO
U0k6IDUKWyAgIDIyLjE3NTczMV0gc2NzaSAzOjA6MTowOiBDRC1ST00gICAgICAgICAgICBERUxM
ICAgICAgIFZDRCAgICAgICAgICAgIDAxMzMgUFE6IDAgQU5TSTogNQpbICAgMjIuMjEzNDM3XSBG
REMgMCBpcyBhIE5hdGlvbmFsIFNlbWljb25kdWN0b3IgUEM4NzMwNgpbICAgMjIuMjE1OTU1XSBz
ZCAzOjA6MDowOiBbc2RjXSBBdHRhY2hlZCBTQ1NJIHJlbW92YWJsZSBkaXNrClsgICAyMi4zODIx
MTRdIGlucHV0OiBQb3dlciBCdXR0b24gYXMgL2RldmljZXMvTE5YU1lTVE06MDAvTE5YUFdSQk46
MDAvaW5wdXQvaW5wdXQyClsgICAyMi4zODIxMzZdIEFDUEk6IFBvd2VyIEJ1dHRvbiBbUFdSRl0K
WyAgIDIyLjUzOTEzMV0gZTEwMDA6IEludGVsKFIpIFBSTy8xMDAwIE5ldHdvcmsgRHJpdmVyIC0g
dmVyc2lvbiA3LjMuMjEtazgtTkFQSQpbICAgMjIuNTM5MTQxXSBlMTAwMDogQ29weXJpZ2h0IChj
KSAxOTk5LTIwMDYgSW50ZWwgQ29ycG9yYXRpb24uClsgICAyMi41MzkyMTJdIHhlbjogcmVnaXN0
ZXJpbmcgZ3NpIDY0IHRyaWdnZXJpbmcgMCBwb2xhcml0eSAxClsgICAyMi41MzkyMzRdIHhlbjog
LS0+IHBpcnE9NjQgLT4gaXJxPTY0IChnc2k9NjQpClsgICAyMi41MzkyNTZdIGUxMDAwIDAwMDA6
MDY6MDcuMDogUENJIElOVCBBIC0+IEdTSSA2NCAobGV2ZWwsIGxvdykgLT4gSVJRIDY0ClsgICAy
Mi41Mzk2MTRdIE5UX0RCRzogZTEwMDBfZ2V0X2J1c19pbmZvOmJ1c19pbmZvIHN0YXR1czogNTIw
OTkKWyAgIDIyLjUzOTYyM10gTlRfREJHOiBody0+YnVzX3R5cGU6MSwgZTEwMDBfYnVzX3R5cGVf
cGNpeDogMgpbICAgMjIuNTM5NjM0XSBOVF9EQkc6IHhlbl9pb190bGJfZW5kOiBkYzMyY2YwMCwg
Y29udmVydGVkIHRvICdwaHlzJzogMWMzMmNmMDAsIHRoZW4gJ2J1cyc6IDEyMGZkZmVmZiBmb3Ig
YW5zd2VyIDEuClsgICAyMi41Mzk2NDRdIE5UX0RCRzogZG1hX3N1cHBvcnRlZCByZXR1cm5pbmcg
MApbICAgMjIuNTM5NjUwXSBlMTAwMDogTm8gdXNhYmxlIERNQSBjb25maWcsIGFib3J0aW5nClsg
ICAyMi41Mzk4NjNdIGUxMDAwIDAwMDA6MDY6MDcuMDogUENJIElOVCBBIGRpc2FibGVkClsgICAy
Mi41Mzk4ODBdIGUxMDAwOiBwcm9iZSBvZiAwMDAwOjA2OjA3LjAgZmFpbGVkIHdpdGggZXJyb3Ig
LTUKWyAgIDIyLjUzOTkxMV0geGVuOiByZWdpc3RlcmluZyBnc2kgNjUgdHJpZ2dlcmluZyAwIHBv
bGFyaXR5IDEKWyAgIDIyLjUzOTkyN10geGVuOiAtLT4gcGlycT02NSAtPiBpcnE9NjUgKGdzaT02
NSkKWyAgIDIyLjUzOTk0Ml0gZTEwMDAgMDAwMDowNzowOC4wOiBQQ0kgSU5UIEEgLT4gR1NJIDY1
IChsZXZlbCwgbG93KSAtPiBJUlEgNjUKWyAgIDIyLjU0MDQzMV0gTlRfREJHOiBlMTAwMF9nZXRf
YnVzX2luZm86YnVzX2luZm8gc3RhdHVzOiA1MTk2OQpbICAgMjIuNTQwNDQxXSBOVF9EQkc6IGh3
LT5idXNfdHlwZToxLCBlMTAwMF9idXNfdHlwZV9wY2l4OiAyClsgICAyMi41NDA0NTFdIE5UX0RC
RzogeGVuX2lvX3RsYl9lbmQ6IGRjMzJjZjAwLCBjb252ZXJ0ZWQgdG8gJ3BoeXMnOiAxYzMyY2Yw
MCwgdGhlbiAnYnVzJzogMTIwZmRmZWZmIGZvciBhbnN3ZXIgMS4KWyAgIDIyLjU0MDQ2MF0gTlRf
REJHOiBkbWFfc3VwcG9ydGVkIHJldHVybmluZyAwClsgICAyMi41NDA0NjddIGUxMDAwOiBObyB1
c2FibGUgRE1BIGNvbmZpZywgYWJvcnRpbmcKWyAgIDIyLjU0MDY5MV0gZTEwMDAgMDAwMDowNzow
OC4wOiBQQ0kgSU5UIEEgZGlzYWJsZWQKWyAgIDIyLjU0MDcxMV0gZTEwMDA6IHByb2JlIG9mIDAw
MDA6MDc6MDguMCBmYWlsZWQgd2l0aCBlcnJvciAtNQpbICAgMzEuODExMzc0XSBzcjA6IHNjc2kz
LW1tYyBkcml2ZTogMjR4LzI0eCBjZC9ydyB4YS9mb3JtMiBjZGRhIHRyYXkKWyAgIDMxLjgxMTM4
N10gY2Ryb206IFVuaWZvcm0gQ0QtUk9NIGRyaXZlciBSZXZpc2lvbjogMy4yMApbICAgMzEuODEx
NjE1XSBzciAxOjA6MDowOiBBdHRhY2hlZCBzY3NpIENELVJPTSBzcjAKWyAgIDMxLjg0NjM1NF0g
c3IxOiBzY3NpLTEgZHJpdmUKWyAgIDMxLjg0NjYyN10gc3IgMzowOjE6MDogQXR0YWNoZWQgc2Nz
aSBDRC1ST00gc3IxClsgICAzMi4xMjc2NzddIHNkIDA6MDowOjA6IEF0dGFjaGVkIHNjc2kgZ2Vu
ZXJpYyBzZzAgdHlwZSAwClsgICAzMi4xMjc3ODhdIHNkIDA6MDoxOjA6IEF0dGFjaGVkIHNjc2kg
Z2VuZXJpYyBzZzEgdHlwZSAwClsgICAzMi4xMjc4ODhdIHNjc2kgMDowOjY6MDogQXR0YWNoZWQg
c2NzaSBnZW5lcmljIHNnMiB0eXBlIDMKWyAgIDMyLjEyNzk4Nl0gc3IgMTowOjA6MDogQXR0YWNo
ZWQgc2NzaSBnZW5lcmljIHNnMyB0eXBlIDUKWyAgIDMyLjEyODA4Nl0gc2QgMzowOjA6MDogQXR0
YWNoZWQgc2NzaSBnZW5lcmljIHNnNCB0eXBlIDAKWyAgIDMyLjEyODE4OF0gc3IgMzowOjE6MDog
QXR0YWNoZWQgc2NzaSBnZW5lcmljIHNnNSB0eXBlIDUKWyAgIDMzLjcyNjc4NV0gTm9uLXZvbGF0
aWxlIG1lbW9yeSBkcml2ZXIgdjEuMwpbICAgMzQuMjcwNDc0XSBtZDogQXV0b2RldGVjdGluZyBS
QUlEIGFycmF5cy4KWyAgIDM0LjI3MDQ4NV0gbWQ6IFNjYW5uZWQgMCBhbmQgYWRkZWQgMCBkZXZp
Y2VzLgpbICAgMzQuMjcwNDkyXSBtZDogYXV0b3J1biAuLi4KWyAgIDM0LjI3MDQ5OF0gbWQ6IC4u
LiBhdXRvcnVuIERPTkUuClsgICAzNC4zMjg0MzVdIGRldmljZS1tYXBwZXI6IGlvY3RsOiA0LjIw
LjAtaW9jdGwgKDIwMTEtMDItMDIpIGluaXRpYWxpc2VkOiBkbS1kZXZlbEByZWRoYXQuY29tClsg
ICAzNC4zODE2OTZdIGRldmljZS1tYXBwZXI6IG11bHRpcGF0aDogdmVyc2lvbiAxLjMuMCBsb2Fk
ZWQKWyAgIDM0LjY1NjExOV0gbG9vcDogbW9kdWxlIGxvYWRlZApbICAgMzUuMzE4MDUwXSBFWFQz
LWZzIChzZGEzKTogdXNpbmcgaW50ZXJuYWwgam91cm5hbApbICAgMzUuMzc5MDM2XSBFWFQzLWZz
OiBiYXJyaWVycyBub3QgZW5hYmxlZApbICAgMzUuMzc5MzkxXSBram91cm5hbGQgc3RhcnRpbmcu
ICBDb21taXQgaW50ZXJ2YWwgNSBzZWNvbmRzClsgICAzNS4zODY0OTldIEVYVDMtZnMgKHNkYTIp
OiB1c2luZyBpbnRlcm5hbCBqb3VybmFsClsgICAzNS4zODY1MDldIEVYVDMtZnMgKHNkYTIpOiBt
b3VudGVkIGZpbGVzeXN0ZW0gd2l0aCBvcmRlcmVkIGRhdGEgbW9kZQpbICAgMzUuNDAxOTk0XSBF
WFQzLWZzOiBiYXJyaWVycyBub3QgZW5hYmxlZApbICAgMzUuNDAyMzIyXSBram91cm5hbGQgc3Rh
cnRpbmcuICBDb21taXQgaW50ZXJ2YWwgNSBzZWNvbmRzClsgICAzNS40MDg0NTZdIEVYVDMtZnMg
KGRtLTApOiB1c2luZyBpbnRlcm5hbCBqb3VybmFsClsgICAzNS40MDg0NjVdIEVYVDMtZnMgKGRt
LTApOiBtb3VudGVkIGZpbGVzeXN0ZW0gd2l0aCBvcmRlcmVkIGRhdGEgbW9kZQo=

--_002_3E243B26F475504B9BB0BCC9728B0DA629E17AEAUSILMS110Acacom_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--_002_3E243B26F475504B9BB0BCC9728B0DA629E17AEAUSILMS110Acacom_--


From xen-devel-bounces@lists.xensource.com Mon Dec 12 22:12:45 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 22:12:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaE6g-0004Ej-Od; Mon, 12 Dec 2011 22:12:22 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Neal.Taylor@ca.com>) id 1RaE6e-0004EY-Dm
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 22:12:21 +0000
X-Env-Sender: Neal.Taylor@ca.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1323727882!5070800!1
X-Originating-IP: [74.125.149.76]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10826 invoked from network); 12 Dec 2011 22:11:25 -0000
Received: from na3sys009aob106.obsmtp.com (HELO na3sys009aog106.obsmtp.com)
	(74.125.149.76)
	by server-14.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 12 Dec 2011 22:11:25 -0000
Received: from USILMS190.ca.com ([141.202.246.44]) (using TLSv1) by
	na3sys009aob106.postini.com ([74.125.148.12]) with SMTP
	ID DSNKTuZ8CvFuwF/UlYpfg9Qmk1XIS569J1RG@postini.com;
	Mon, 12 Dec 2011 14:11:24 PST
Received: from USILMS173.ca.com (141.202.6.23) by USILMS190.ca.com
	(141.202.246.44) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Mon, 12 Dec 2011 17:11:21 -0500
Received: from USILMS110A.ca.com ([169.254.1.109]) by usilms173.ca.com
	([141.202.6.23]) with mapi id 14.01.0289.001;
	Mon, 12 Dec 2011 17:11:21 -0500
From: "Taylor, Neal E" <Neal.Taylor@ca.com>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
Thread-Topic: [Xen-devel] Buffers not reachable by PCI
Thread-Index: Acy2r+Ulg1PsfbmtTl6QVj0jZAx7mwAK1xcAAIXl/sA=
Date: Mon, 12 Dec 2011 22:11:20 +0000
Message-ID: <3E243B26F475504B9BB0BCC9728B0DA629E17AEA@USILMS110A.ca.com>
References: <3E243B26F475504B9BB0BCC9728B0DA629E16E01@USILMS110A.ca.com>
	<20111209203010.GA14412@andromeda.dapyr.net>
In-Reply-To: <20111209203010.GA14412@andromeda.dapyr.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [138.42.46.105]
Content-Type: multipart/mixed;
	boundary="_002_3E243B26F475504B9BB0BCC9728B0DA629E17AEAUSILMS110Acacom_"
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>, "Kalev,
	Leonid" <Leonid.Kalev@ca.com>, "Dave, Tushar N" <tushar.n.dave@intel.com>
Subject: Re: [Xen-devel] Buffers not reachable by PCI
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--_002_3E243B26F475504B9BB0BCC9728B0DA629E17AEAUSILMS110Acacom_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

We're having trouble getting a serial log. Are there other ways to capture =
the information you need?

Attached is a dmesg with 'debug loglevel 8' set on the kernel line... actua=
lly, with =20

   #define DEFAULT_MESSAGE_LOGLEVEL 8

set near the top of printk.c as well, since I wasn't seeing any difference =
in the log files with loglevel set to 8.

Neal

-----Original Message-----
From: Konrad Rzeszutek Wilk [mailto:konrad@darnok.org]=20
Sent: Friday, December 09, 2011 12:30 PM
To: Taylor, Neal E
Cc: xen-devel; Kalev, Leonid; Dave, Tushar N
Subject: Re: [Xen-devel] Buffers not reachable by PCI

On Fri, Dec 09, 2011 at 08:19:47PM +0000, Taylor, Neal E wrote:
> We're running 64-bit Xex 4.1.1 and 32-bit Linux 3.0.4 Dom0 (Linux 3.1 sho=
ws the same symptom.)

Hm, 32-bit. Did it work if the Dom0 was 64-bit?
>=20
> Several PCI drivers are unable to use DMA. Most fallback to using PIO but=
 in two instances the network drivers (e1000 and pcinet32) abort. The same =
kernel running on the same hardware without Xen works fine.
>=20
> Digging through the code, in swiotlb-xen.c I find "DMA_BIT_MASK(32)" (0x0=
0000000ffffffff) compared to "xen_virt_to_bus(xen_io_tlb_end - 1)" which re=
solves to 0x1,20fd,feff. Since the address is larger than the mask, DMA is =
declared as unsupportable.

<blinks>

xen_io_tlb_end resolved to 120fdfeff? That is a definite bug. Can you
attach you full bootup serial log with 'debug loglevel=3D8' parameters on
the Linux line please?



> In talking with others I hear Linux handles this situation with bounce bu=
ffers. Is there a config setting I've missed to enable that for Xen? (Confi=
g file attached)

The Xen SWIOTLB is by default enabled, so it is on, but the
xen_virt_to_bus(xen_io_tlb_end - 1) _MUST_ never be above 4GB. In your
case it is, which is bad. It is rather surprising as I had not seen this
ever happen.

--_002_3E243B26F475504B9BB0BCC9728B0DA629E17AEAUSILMS110Acacom_
Content-Type: application/octet-stream; name="dmesg-log8.3"
Content-Description: dmesg-log8.3
Content-Disposition: attachment; filename="dmesg-log8.3"; size=45419;
	creation-date="Mon, 12 Dec 2011 22:10:04 GMT";
	modification-date="Mon, 12 Dec 2011 20:34:19 GMT"
Content-Transfer-Encoding: base64

WyAgICAwLjAwMDAwMF0gUmVzZXJ2aW5nIHZpcnR1YWwgYWRkcmVzcyBzcGFjZSBhYm92ZSAweGZm
ODAwMDAwClsgICAgMC4wMDAwMDBdIExpbnV4IHZlcnNpb24gMy4wLjQtMzYueGVuMCAocm9vdEBu
dC1kZXYtQ2VudDU1LTMyKSAoZ2NjIHZlcnNpb24gNC4xLjIgMjAwODA3MDQgKFJlZCBIYXQgNC4x
LjItNDgpKSAjMSBTTVAgTW9uIERlYyAxMiAxNDo1NDozOSBFU1QgMjAxMQpbICAgIDAuMDAwMDAw
XSByZWxlYXNlZCAwIHBhZ2VzIG9mIHVudXNlZCBtZW1vcnkKWyAgICAwLjAwMDAwMF0gMS0xIG1h
cHBpbmcgb24gYTAtPjEwMApbICAgIDAuMDAwMDAwXSAxLTEgbWFwcGluZyBvbiBiZmZjMC0+MTAw
MDAwClsgICAgMC4wMDAwMDBdIFNldCAyNjIzMDQgcGFnZShzKSB0byAxLTEgbWFwcGluZy4KWyAg
ICAwLjAwMDAwMF0gQklPUy1wcm92aWRlZCBwaHlzaWNhbCBSQU0gbWFwOgpbICAgIDAuMDAwMDAw
XSAgWGVuOiAwMDAwMDAwMDAwMDAwMDAwIC0gMDAwMDAwMDAwMDBhMDAwMCAodXNhYmxlKQpbICAg
IDAuMDAwMDAwXSAgWGVuOiAwMDAwMDAwMDAwMGEwMDAwIC0gMDAwMDAwMDAwMDEwMDAwMCAocmVz
ZXJ2ZWQpClsgICAgMC4wMDAwMDBdICBYZW46IDAwMDAwMDAwMDAxMDAwMDAgLSAwMDAwMDAwMDIw
MDAwMDAwICh1c2FibGUpClsgICAgMC4wMDAwMDBdICBYZW46IDAwMDAwMDAwMjAwMDAwMDAgLSAw
MDAwMDAwMGJmZmMwMDAwICh1bnVzYWJsZSkKWyAgICAwLjAwMDAwMF0gIFhlbjogMDAwMDAwMDBi
ZmZjMDAwMCAtIDAwMDAwMDAwYmZmY2ZjMDAgKEFDUEkgZGF0YSkKWyAgICAwLjAwMDAwMF0gIFhl
bjogMDAwMDAwMDBiZmZjZmMwMCAtIDAwMDAwMDAwYmZmZmYwMDAgKHJlc2VydmVkKQpbICAgIDAu
MDAwMDAwXSAgWGVuOiAwMDAwMDAwMGUwMDAwMDAwIC0gMDAwMDAwMDBmZWM5MDAwMCAocmVzZXJ2
ZWQpClsgICAgMC4wMDAwMDBdICBYZW46IDAwMDAwMDAwZmVkMDAwMDAgLSAwMDAwMDAwMGZlZDAw
NDAwIChyZXNlcnZlZCkKWyAgICAwLjAwMDAwMF0gIFhlbjogMDAwMDAwMDBmZWUwMDAwMCAtIDAw
MDAwMDAwZmVlMTAwMDAgKHJlc2VydmVkKQpbICAgIDAuMDAwMDAwXSAgWGVuOiAwMDAwMDAwMGZm
YjAwMDAwIC0gMDAwMDAwMDEwMDAwMDAwMCAocmVzZXJ2ZWQpClsgICAgMC4wMDAwMDBdICBYZW46
IDAwMDAwMDAxMDAwMDAwMDAgLSAwMDAwMDAwMWRmZmMwMDAwICh1c2FibGUpClsgICAgMC4wMDAw
MDBdIE5YIChFeGVjdXRlIERpc2FibGUpIHByb3RlY3Rpb246IGFjdGl2ZQpbICAgIDAuMDAwMDAw
XSBETUkgMi4zIHByZXNlbnQuClsgICAgMC4wMDAwMDBdIERNSTogRGVsbCBDb21wdXRlciBDb3Jw
b3JhdGlvbiBQb3dlckVkZ2UgMTg1MC8wUkMxMzAsIEJJT1MgQTA1IDAxLzA5LzIwMDYKWyAgICAw
LjAwMDAwMF0gZTgyMCB1cGRhdGUgcmFuZ2U6IDAwMDAwMDAwMDAwMDAwMDAgLSAwMDAwMDAwMDAw
MDEwMDAwICh1c2FibGUpID09PiAocmVzZXJ2ZWQpClsgICAgMC4wMDAwMDBdIGU4MjAgcmVtb3Zl
IHJhbmdlOiAwMDAwMDAwMDAwMGEwMDAwIC0gMDAwMDAwMDAwMDEwMDAwMCAodXNhYmxlKQpbICAg
IDAuMDAwMDAwXSBsYXN0X3BmbiA9IDB4MWRmZmMwIG1heF9hcmNoX3BmbiA9IDB4MTAwMDAwMApb
ICAgIDAuMDAwMDAwXSBmb3VuZCBTTVAgTVAtdGFibGUgYXQgW2MwMGZlNzEwXSBmZTcxMApbICAg
IDAuMDAwMDAwXSBpbml0aWFsIG1lbW9yeSBtYXBwZWQgOiAwIC0gMDIzZmYwMDAKWyAgICAwLjAw
MDAwMF0gQmFzZSBtZW1vcnkgdHJhbXBvbGluZSBhdCBbYzAwOWYwMDBdIDlmMDAwIHNpemUgNDA5
NgpbICAgIDAuMDAwMDAwXSBpbml0X21lbW9yeV9tYXBwaW5nOiAwMDAwMDAwMDAwMDAwMDAwLTAw
MDAwMDAwMzczZmUwMDAKWyAgICAwLjAwMDAwMF0gIDAwMDAwMDAwMDAgLSAwMDM3M2ZlMDAwIHBh
Z2UgNGsKWyAgICAwLjAwMDAwMF0ga2VybmVsIGRpcmVjdCBtYXBwaW5nIHRhYmxlcyB1cCB0byAz
NzNmZTAwMCBAIDIyNDIwMDAtMjNmZjAwMApbICAgIDAuMDAwMDAwXSB4ZW46IHNldHRpbmcgUlcg
dGhlIHJhbmdlIDIzZWEwMDAgLSAyM2ZmMDAwClsgICAgMC4wMDAwMDBdIFJBTURJU0s6IDAxNmZi
MDAwIC0gMDFhYjIwMDAKWyAgICAwLjAwMDAwMF0gQUNQSTogUlNEUCAwMDBmZDViMCAwMDAxNCAo
djAwIERFTEwgICkKWyAgICAwLjAwMDAwMF0gQUNQSTogUlNEVCAwMDBmZDVjNCAwMDAzOCAodjAx
IERFTEwgICBQRSBCS0MgICAwMDAwMDAwMSBNU0ZUIDAxMDAwMDBBKQpbICAgIDAuMDAwMDAwXSBB
Q1BJOiBGQUNQIDAwMGZkNjIwIDAwMDc0ICh2MDEgREVMTCAgIFBFIEJLQyAgIDAwMDAwMDAxIE1T
RlQgMDEwMDAwMEEpClsgICAgMC4wMDAwMDBdIEFDUEk6IERTRFQgYmZmYzAwMDAgMDNDQ0QgKHYw
MSBERUxMICAgUEUgQktDICAgMDAwMDAwMDEgTVNGVCAwMTAwMDAwRSkKWyAgICAwLjAwMDAwMF0g
QUNQSTogRkFDUyBiZmZjZmMwMCAwMDA0MApbICAgIDAuMDAwMDAwXSBBQ1BJOiBBUElDIDAwMGZk
Njk0IDAwMEQ0ICh2MDEgREVMTCAgIFBFIEJLQyAgIDAwMDAwMDAxIE1TRlQgMDEwMDAwMEEpClsg
ICAgMC4wMDAwMDBdIEFDUEk6IFNQQ1IgMDAwZmQ3NzQgMDAwNTAgKHYwMSBERUxMICAgUEUgQktD
ICAgMDAwMDAwMDEgTVNGVCAwMTAwMDAwQSkKWyAgICAwLjAwMDAwMF0gQUNQSTogSFBFVCAwMDBm
ZDdjNCAwMDAzOCAodjAxIERFTEwgICBQRSBCS0MgICAwMDAwMDAwMSBNU0ZUIDAxMDAwMDBBKQpb
ICAgIDAuMDAwMDAwXSBBQ1BJOiBNQ0ZHIDAwMGZkN2ZjIDAwMDNDICh2MDEgREVMTCAgIFBFIEJL
QyAgIDAwMDAwMDAxIE1TRlQgMDEwMDAwMEEpClsgICAgMC4wMDAwMDBdIEFDUEk6IExvY2FsIEFQ
SUMgYWRkcmVzcyAweGZlZTAwMDAwClsgICAgMC4wMDAwMDBdIDY3OTVNQiBISUdITUVNIGF2YWls
YWJsZS4KWyAgICAwLjAwMDAwMF0gODgzTUIgTE9XTUVNIGF2YWlsYWJsZS4KWyAgICAwLjAwMDAw
MF0gICBtYXBwZWQgbG93IHJhbTogMCAtIDM3M2ZlMDAwClsgICAgMC4wMDAwMDBdICAgbG93IHJh
bTogMCAtIDM3M2ZlMDAwClsgICAgMC4wMDAwMDBdIFpvbmUgUEZOIHJhbmdlczoKWyAgICAwLjAw
MDAwMF0gICBETUEgICAgICAweDAwMDAwMDEwIC0+IDB4MDAwMDEwMDAKWyAgICAwLjAwMDAwMF0g
ICBOb3JtYWwgICAweDAwMDAxMDAwIC0+IDB4MDAwMzczZmUKWyAgICAwLjAwMDAwMF0gICBIaWdo
TWVtICAweDAwMDM3M2ZlIC0+IDB4MDAxZGZmYzAKWyAgICAwLjAwMDAwMF0gTW92YWJsZSB6b25l
IHN0YXJ0IFBGTiBmb3IgZWFjaCBub2RlClsgICAgMC4wMDAwMDBdIGVhcmx5X25vZGVfbWFwWzNd
IGFjdGl2ZSBQRk4gcmFuZ2VzClsgICAgMC4wMDAwMDBdICAgICAwOiAweDAwMDAwMDEwIC0+IDB4
MDAwMDAwYTAKWyAgICAwLjAwMDAwMF0gICAgIDA6IDB4MDAwMDAxMDAgLT4gMHgwMDAyMDAwMApb
ICAgIDAuMDAwMDAwXSAgICAgMDogMHgwMDEwMDAwMCAtPiAweDAwMWRmZmMwClsgICAgMC4wMDAw
MDBdIE9uIG5vZGUgMCB0b3RhbHBhZ2VzOiAxMDQ4NDAwClsgICAgMC4wMDAwMDBdIGZyZWVfYXJl
YV9pbml0X25vZGU6IG5vZGUgMCwgcGdkYXQgYzEzNmViMDAsIG5vZGVfbWVtX21hcCBkYzNmZjIw
MApbICAgIDAuMDAwMDAwXSAgIERNQSB6b25lOiAzMiBwYWdlcyB1c2VkIGZvciBtZW1tYXAKWyAg
ICAwLjAwMDAwMF0gICBETUEgem9uZTogMCBwYWdlcyByZXNlcnZlZApbICAgIDAuMDAwMDAwXSAg
IERNQSB6b25lOiAzOTUyIHBhZ2VzLCBMSUZPIGJhdGNoOjAKWyAgICAwLjAwMDAwMF0gICBOb3Jt
YWwgem9uZTogMTczNiBwYWdlcyB1c2VkIGZvciBtZW1tYXAKWyAgICAwLjAwMDAwMF0gICBOb3Jt
YWwgem9uZTogMTI1MjQwIHBhZ2VzLCBMSUZPIGJhdGNoOjMxClsgICAgMC4wMDAwMDBdICAgSGln
aE1lbSB6b25lOiAxMzU5MiBwYWdlcyB1c2VkIGZvciBtZW1tYXAKWyAgICAwLjAwMDAwMF0gICBI
aWdoTWVtIHpvbmU6IDkwMzg0OCBwYWdlcywgTElGTyBiYXRjaDozMQpbICAgIDAuMDAwMDAwXSBV
c2luZyBBUElDIGRyaXZlciBkZWZhdWx0ClsgICAgMC4wMDAwMDBdIEFDUEk6IFBNLVRpbWVyIElP
IFBvcnQ6IDB4ODA4ClsgICAgMC4wMDAwMDBdIEFDUEk6IExvY2FsIEFQSUMgYWRkcmVzcyAweGZl
ZTAwMDAwClsgICAgMC4wMDAwMDBdIEFDUEk6IExBUElDIChhY3BpX2lkWzB4MDFdIGxhcGljX2lk
WzB4MDBdIGVuYWJsZWQpClsgICAgMC4wMDAwMDBdIEJJT1MgYnVnOiBBUElDIHZlcnNpb24gaXMg
MCBmb3IgQ1BVIDAvMHgwLCBmaXhpbmcgdXAgdG8gMHgxMApbICAgIDAuMDAwMDAwXSBBQ1BJOiBM
QVBJQyAoYWNwaV9pZFsweDAyXSBsYXBpY19pZFsweDA2XSBlbmFibGVkKQpbICAgIDAuMDAwMDAw
XSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDAzXSBsYXBpY19pZFsweDAxXSBlbmFibGVkKQpbICAg
IDAuMDAwMDAwXSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDA0XSBsYXBpY19pZFsweDA3XSBlbmFi
bGVkKQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDA1XSBsYXBpY19pZFsw
eDAyXSBkaXNhYmxlZCkKWyAgICAwLjAwMDAwMF0gQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwNl0g
bGFwaWNfaWRbMHgwNF0gZGlzYWJsZWQpClsgICAgMC4wMDAwMDBdIEFDUEk6IExBUElDIChhY3Bp
X2lkWzB4MDddIGxhcGljX2lkWzB4MDNdIGRpc2FibGVkKQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBM
QVBJQyAoYWNwaV9pZFsweDA4XSBsYXBpY19pZFsweDA1XSBkaXNhYmxlZCkKWyAgICAwLjAwMDAw
MF0gQUNQSTogTEFQSUNfTk1JIChhY3BpX2lkWzB4MDFdIGhpZ2ggZWRnZSBsaW50WzB4MV0pClsg
ICAgMC4wMDAwMDBdIEFDUEk6IExBUElDX05NSSAoYWNwaV9pZFsweDAyXSBoaWdoIGVkZ2UgbGlu
dFsweDFdKQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJQ19OTUkgKGFjcGlfaWRbMHgwM10gaGln
aCBlZGdlIGxpbnRbMHgxXSkKWyAgICAwLjAwMDAwMF0gQUNQSTogTEFQSUNfTk1JIChhY3BpX2lk
WzB4MDRdIGhpZ2ggZWRnZSBsaW50WzB4MV0pClsgICAgMC4wMDAwMDBdIEFDUEk6IExBUElDX05N
SSAoYWNwaV9pZFsweDA1XSBoaWdoIGVkZ2UgbGludFsweDFdKQpbICAgIDAuMDAwMDAwXSBBQ1BJ
OiBMQVBJQ19OTUkgKGFjcGlfaWRbMHgwNl0gaGlnaCBlZGdlIGxpbnRbMHgxXSkKWyAgICAwLjAw
MDAwMF0gQUNQSTogTEFQSUNfTk1JIChhY3BpX2lkWzB4MDddIGhpZ2ggZWRnZSBsaW50WzB4MV0p
ClsgICAgMC4wMDAwMDBdIEFDUEk6IExBUElDX05NSSAoYWNwaV9pZFsweDA4XSBoaWdoIGVkZ2Ug
bGludFsweDFdKQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBJT0FQSUMgKGlkWzB4MDhdIGFkZHJlc3Nb
MHhmZWMwMDAwMF0gZ3NpX2Jhc2VbMF0pClsgICAgMC4wMDAwMDBdIElPQVBJQ1swXTogYXBpY19p
ZCA4LCB2ZXJzaW9uIDI1NSwgYWRkcmVzcyAweGZlYzAwMDAwLCBHU0kgMC0yNTUKWyAgICAwLjAw
MDAwMF0gQUNQSTogSU9BUElDIChpZFsweDA5XSBhZGRyZXNzWzB4ZmVjODAwMDBdIGdzaV9iYXNl
WzMyXSkKWyAgICAwLjAwMDAwMF0gSU9BUElDWzFdOiBhcGljX2lkIDksIHZlcnNpb24gMjU1LCBh
ZGRyZXNzIDB4ZmVjODAwMDAsIEdTSSAzMi0yODcKWyAgICAwLjAwMDAwMF0gQUNQSTogSU9BUElD
IChpZFsweDBhXSBhZGRyZXNzWzB4ZmVjODMwMDBdIGdzaV9iYXNlWzY0XSkKWyAgICAwLjAwMDAw
MF0gSU9BUElDWzJdOiBhcGljX2lkIDEwLCB2ZXJzaW9uIDI1NSwgYWRkcmVzcyAweGZlYzgzMDAw
LCBHU0kgNjQtMzE5ClsgICAgMC4wMDAwMDBdIEFDUEk6IElOVF9TUkNfT1ZSIChidXMgMCBidXNf
aXJxIDAgZ2xvYmFsX2lycSAyIGRmbCBkZmwpClsgICAgMC4wMDAwMDBdIEFDUEk6IElOVF9TUkNf
T1ZSIChidXMgMCBidXNfaXJxIDkgZ2xvYmFsX2lycSA5IGhpZ2ggbGV2ZWwpClsgICAgMC4wMDAw
MDBdIEFDUEk6IElSUTAgdXNlZCBieSBvdmVycmlkZS4KWyAgICAwLjAwMDAwMF0gQUNQSTogSVJR
MiB1c2VkIGJ5IG92ZXJyaWRlLgpbICAgIDAuMDAwMDAwXSBBQ1BJOiBJUlE5IHVzZWQgYnkgb3Zl
cnJpZGUuClsgICAgMC4wMDAwMDBdIFVzaW5nIEFDUEkgKE1BRFQpIGZvciBTTVAgY29uZmlndXJh
dGlvbiBpbmZvcm1hdGlvbgpbICAgIDAuMDAwMDAwXSBTTVA6IEFsbG93aW5nIDggQ1BVcywgNCBo
b3RwbHVnIENQVXMKWyAgICAwLjAwMDAwMF0gbnJfaXJxc19nc2k6IDMzNgpbICAgIDAuMDAwMDAw
XSBBbGxvY2F0aW5nIFBDSSByZXNvdXJjZXMgc3RhcnRpbmcgYXQgYmZmZmYwMDAgKGdhcDogYmZm
ZmYwMDA6MjAwMDEwMDApClsgICAgMC4wMDAwMDBdIEJvb3RpbmcgcGFyYXZpcnR1YWxpemVkIGtl
cm5lbCBvbiBYZW4KWyAgICAwLjAwMDAwMF0gWGVuIHZlcnNpb246IDQuMS4xIChwcmVzZXJ2ZS1B
RCkKWyAgICAwLjAwMDAwMF0gc2V0dXBfcGVyY3B1OiBOUl9DUFVTOjggbnJfY3B1bWFza19iaXRz
OjggbnJfY3B1X2lkczo4IG5yX25vZGVfaWRzOjEKWyAgICAwLjAwMDAwMF0gUEVSQ1BVOiBFbWJl
ZGRlZCAxMiBwYWdlcy9jcHUgQGRjMzhkMDAwIHMyNzEzNiByMCBkMjIwMTYgdTQ5MTUyClsgICAg
MC4wMDAwMDBdIHBjcHUtYWxsb2M6IHMyNzEzNiByMCBkMjIwMTYgdTQ5MTUyIGFsbG9jPTEyKjQw
OTYKWyAgICAwLjAwMDAwMF0gcGNwdS1hbGxvYzogWzBdIDAgWzBdIDEgWzBdIDIgWzBdIDMgWzBd
IDQgWzBdIDUgWzBdIDYgWzBdIDcgClsgICAgMC4wMDAwMDBdIEJ1aWx0IDEgem9uZWxpc3RzIGlu
IFpvbmUgb3JkZXIsIG1vYmlsaXR5IGdyb3VwaW5nIG9uLiAgVG90YWwgcGFnZXM6IDEwMzMwNDAK
WyAgICAwLjAwMDAwMF0gS2VybmVsIGNvbW1hbmQgbGluZTogbm91c2IgIHJvb3Q9TEFCRUw9L21u
dC9hcGxib290MSBzZWxpbnV4PTAgIG1heF9sb29wPTI1NiBkZWJ1ZyBsb2dsZXZlbD04ClsgICAg
MC4wMDAwMDBdIFBJRCBoYXNoIHRhYmxlIGVudHJpZXM6IDIwNDggKG9yZGVyOiAxLCA4MTkyIGJ5
dGVzKQpbICAgIDAuMDAwMDAwXSBEZW50cnkgY2FjaGUgaGFzaCB0YWJsZSBlbnRyaWVzOiA2NTUz
NiAob3JkZXI6IDYsIDI2MjE0NCBieXRlcykKWyAgICAwLjAwMDAwMF0gSW5vZGUtY2FjaGUgaGFz
aCB0YWJsZSBlbnRyaWVzOiAzMjc2OCAob3JkZXI6IDUsIDEzMTA3MiBieXRlcykKWyAgICAwLjAw
MDAwMF0gSW5pdGlhbGl6aW5nIENQVSMwClsgICAgMC4wMDAwMDBdIFBsYWNpbmcgNjRNQiBzb2Z0
d2FyZSBJTyBUTEIgYmV0d2VlbiBkODMyY2YwMCAtIGRjMzJjZjAwClsgICAgMC4wMDAwMDBdIHNv
ZnR3YXJlIElPIFRMQiBhdCBwaHlzIDB4MTgzMmNmMDAgLSAweDFjMzJjZjAwClsgICAgMC4wMDAw
MDBdIEluaXRpYWxpemluZyBIaWdoTWVtIGZvciBub2RlIDAgKDAwMDM3M2ZlOjAwMWRmZmMwKQpb
ICAgIDAuMDAwMDAwXSBNZW1vcnk6IDM4NDgwNGsvNzg2NDA2NGsgYXZhaWxhYmxlICgyMzM4ayBr
ZXJuZWwgY29kZSwgMTM5MDM2ayByZXNlcnZlZCwgMTE5N2sgZGF0YSwgMzcyayBpbml0LCAwayBo
aWdobWVtKQpbICAgIDAuMDAwMDAwXSB2aXJ0dWFsIGtlcm5lbCBtZW1vcnkgbGF5b3V0OgpbICAg
IDAuMDAwMDAwXSAgICAgZml4bWFwICA6IDB4ZmY3MTYwMDAgLSAweGZmN2ZmMDAwICAgKCA5MzIg
a0IpClsgICAgMC4wMDAwMDBdICAgICBwa21hcCAgIDogMHhmZjQwMDAwMCAtIDB4ZmY2MDAwMDAg
ICAoMjA0OCBrQikKWyAgICAwLjAwMDAwMF0gICAgIHZtYWxsb2MgOiAweGY3YmZlMDAwIC0gMHhm
ZjNmZTAwMCAgICggMTIwIE1CKQpbICAgIDAuMDAwMDAwXSAgICAgbG93bWVtICA6IDB4YzAwMDAw
MDAgLSAweGY3M2ZlMDAwICAgKCA4ODMgTUIpClsgICAgMC4wMDAwMDBdICAgICAgIC5pbml0IDog
MHhjMTM3NDAwMCAtIDB4YzEzZDEwMDAgICAoIDM3MiBrQikKWyAgICAwLjAwMDAwMF0gICAgICAg
LmRhdGEgOiAweGMxMjQ4ODI1IC0gMHhjMTM3NDAwMCAgICgxMTk3IGtCKQpbICAgIDAuMDAwMDAw
XSAgICAgICAudGV4dCA6IDB4YzEwMDAwMDAgLSAweGMxMjQ4ODI1ICAgKDIzMzgga0IpClsgICAg
MC4wMDAwMDBdIEhpZXJhcmNoaWNhbCBSQ1UgaW1wbGVtZW50YXRpb24uClsgICAgMC4wMDAwMDBd
IE5SX0lSUVM6MjU2MApbICAgIDAuMDAwMDAwXSBDUFUgMCBpcnFzdGFja3MsIGhhcmQ9ZDdjMTAw
MDAgc29mdD1kN2MxMjAwMApbICAgIDAuMDAwMDAwXSB4ZW46IHNjaSBvdmVycmlkZTogZ2xvYmFs
X2lycT05IHRyaWdnZXI9MCBwb2xhcml0eT0wClsgICAgMC4wMDAwMDBdIHhlbjogcmVnaXN0ZXJp
bmcgZ3NpIDkgdHJpZ2dlcmluZyAwIHBvbGFyaXR5IDAKWyAgICAwLjAwMDAwMF0geGVuOiAtLT4g
cGlycT05IC0+IGlycT05IChnc2k9OSkKWyAgICAwLjAwMDAwMF0geGVuOiBhY3BpIHNjaSA5Clsg
ICAgMC4wMDAwMDBdIHhlbjogLS0+IHBpcnE9MSAtPiBpcnE9MSAoZ3NpPTEpClsgICAgMC4wMDAw
MDBdIHhlbjogLS0+IHBpcnE9MiAtPiBpcnE9MiAoZ3NpPTIpClsgICAgMC4wMDAwMDBdIHhlbjog
LS0+IHBpcnE9MyAtPiBpcnE9MyAoZ3NpPTMpClsgICAgMC4wMDAwMDBdIHhlbjogLS0+IHBpcnE9
NCAtPiBpcnE9NCAoZ3NpPTQpClsgICAgMC4wMDAwMDBdIHhlbjogLS0+IHBpcnE9NSAtPiBpcnE9
NSAoZ3NpPTUpClsgICAgMC4wMDAwMDBdIHhlbjogLS0+IHBpcnE9NiAtPiBpcnE9NiAoZ3NpPTYp
ClsgICAgMC4wMDAwMDBdIHhlbjogLS0+IHBpcnE9NyAtPiBpcnE9NyAoZ3NpPTcpClsgICAgMC4w
MDAwMDBdIHhlbjogLS0+IHBpcnE9OCAtPiBpcnE9OCAoZ3NpPTgpClsgICAgMC4wMDAwMDBdIHhl
bl9tYXBfcGlycV9nc2k6IHJldHVybmluZyBpcnEgOSBmb3IgZ3NpIDkKWyAgICAwLjAwMDAwMF0g
eGVuOiAtLT4gcGlycT05IC0+IGlycT05IChnc2k9OSkKWyAgICAwLjAwMDAwMF0geGVuOiAtLT4g
cGlycT0xMCAtPiBpcnE9MTAgKGdzaT0xMCkKWyAgICAwLjAwMDAwMF0geGVuOiAtLT4gcGlycT0x
MSAtPiBpcnE9MTEgKGdzaT0xMSkKWyAgICAwLjAwMDAwMF0geGVuOiAtLT4gcGlycT0xMiAtPiBp
cnE9MTIgKGdzaT0xMikKWyAgICAwLjAwMDAwMF0geGVuOiAtLT4gcGlycT0xMyAtPiBpcnE9MTMg
KGdzaT0xMykKWyAgICAwLjAwMDAwMF0geGVuOiAtLT4gcGlycT0xNCAtPiBpcnE9MTQgKGdzaT0x
NCkKWyAgICAwLjAwMDAwMF0geGVuOiAtLT4gcGlycT0xNSAtPiBpcnE9MTUgKGdzaT0xNSkKWyAg
ICAwLjAwMDAwMF0gQ29uc29sZTogY29sb3VyIFZHQSsgODB4MjUKWyAgICAwLjAwMDAwMF0gY29u
c29sZSBbdHR5MF0gZW5hYmxlZApbICAgIDAuMDAwMDAwXSBYZW46IHVzaW5nIHZjcHVvcCB0aW1l
ciBpbnRlcmZhY2UKWyAgICAwLjAwMDAwMF0gaW5zdGFsbGluZyBYZW4gdGltZXIgZm9yIENQVSAw
ClsgICAgMC4wMDAwMDBdIERldGVjdGVkIDI5OTIuODI4IE1IeiBwcm9jZXNzb3IuClsgICAgMC4w
MTAwMDBdIENhbGlicmF0aW5nIGRlbGF5IGxvb3AgKHNraXBwZWQpLCB2YWx1ZSBjYWxjdWxhdGVk
IHVzaW5nIHRpbWVyIGZyZXF1ZW5jeS4uIDU5ODUuNjUgQm9nb01JUFMgKGxwaj0yOTkyODI4MCkK
WyAgICAwLjAxMDAwMF0gcGlkX21heDogZGVmYXVsdDogMzI3NjggbWluaW11bTogMzAxClsgICAg
MC4wMTAwMDBdIE1vdW50LWNhY2hlIGhhc2ggdGFibGUgZW50cmllczogNTEyClsgICAgMC4wMTAw
MDBdIENQVTogUGh5c2ljYWwgUHJvY2Vzc29yIElEOiAwClsgICAgMC4wMTAwMDBdIENQVTogUHJv
Y2Vzc29yIENvcmUgSUQ6IDAKWyAgICAwLjAxMDAwMF0gQUNQSTogQ29yZSByZXZpc2lvbiAyMDEx
MDQxMwpbICAgIDAuMDE1MTQ3XSBQZXJmb3JtYW5jZSBFdmVudHM6IHVuc3VwcG9ydGVkIE5ldGJ1
cnN0IENQVSBtb2RlbCA0IG5vIFBNVSBkcml2ZXIsIHNvZnR3YXJlIGV2ZW50cyBvbmx5LgpbICAg
IDAuMDE1ODkyXSBDUFUgMSBpcnFzdGFja3MsIGhhcmQ9ZDdjODAwMDAgc29mdD1kN2M4MjAwMApb
ICAgIDAuMDE1OTg2XSBpbnN0YWxsaW5nIFhlbiB0aW1lciBmb3IgQ1BVIDEKWyAgICAwLjAxMDAw
MF0gSW5pdGlhbGl6aW5nIENQVSMxClsgICAgMC4wMTY1NDVdIENQVSAyIGlycXN0YWNrcywgaGFy
ZD1kN2M4YzAwMCBzb2Z0PWQ3YzhlMDAwClsgICAgMC4wMTY3MjJdIGluc3RhbGxpbmcgWGVuIHRp
bWVyIGZvciBDUFUgMgpbICAgIDAuMDEwMDAwXSBJbml0aWFsaXppbmcgQ1BVIzIKWyAgICAwLjAx
NzI4OF0gQ1BVIDMgaXJxc3RhY2tzLCBoYXJkPWQ3Y2JhMDAwIHNvZnQ9ZDdjYmMwMDAKWyAgICAw
LjAxNzQ2NV0gaW5zdGFsbGluZyBYZW4gdGltZXIgZm9yIENQVSAzClsgICAgMC4wMTAwMDBdIElu
aXRpYWxpemluZyBDUFUjMwpbICAgIDAuMDE3NzY2XSBCcm91Z2h0IHVwIDQgQ1BVcwpbICAgIDAu
MDE4MTU3XSBHcmFudCB0YWJsZSBpbml0aWFsaXplZApbICAgIDAuMDE4MTU3XSBORVQ6IFJlZ2lz
dGVyZWQgcHJvdG9jb2wgZmFtaWx5IDE2ClsgICAgMC4wMjAxODddIEFDUEk6IGJ1cyB0eXBlIHBj
aSByZWdpc3RlcmVkClsgICAgMC4wMjA1MzddIFBDSTogTU1DT05GSUcgZm9yIGRvbWFpbiAwMDAw
IFtidXMgMDAtZmZdIGF0IFttZW0gMHhlMDAwMDAwMC0weGVmZmZmZmZmXSAoYmFzZSAweGUwMDAw
MDAwKQpbICAgIDAuMDIwNjQ5XSBQQ0k6IEludGVsIENvcnBvcmF0aW9uIEU3NTIwIE1lbW9yeSBD
b250cm9sbGVyIEh1YiB3aXRoIE1NQ09ORklHIHN1cHBvcnQKWyAgICAwLjAyMDc3NF0gUENJOiBN
TUNPTkZJRyBhdCBbbWVtIDB4ZTAwMDAwMDAtMHhlZmZmZmZmZl0gcmVzZXJ2ZWQgaW4gRTgyMApb
ICAgIDAuMDIwODY4XSBQQ0k6IFVzaW5nIE1NQ09ORklHIGZvciBleHRlbmRlZCBjb25maWcgc3Bh
Y2UKWyAgICAwLjAyMDk2MF0gUENJOiBVc2luZyBjb25maWd1cmF0aW9uIHR5cGUgMSBmb3IgYmFz
ZSBhY2Nlc3MKWyAgICAwLjAyMjIyOV0gYmlvOiBjcmVhdGUgc2xhYiA8YmlvLTA+IGF0IDAKWyAg
ICAwLjAyNDMwOF0gQUNQSTogRUM6IExvb2sgdXAgRUMgaW4gRFNEVApbICAgIDAuMDQzMTU0XSBB
Q1BJOiBJbnRlcnByZXRlciBlbmFibGVkClsgICAgMC4wNDMyNDRdIEFDUEk6IChzdXBwb3J0cyBT
MCBTNSkKWyAgICAwLjA0MzQ5NV0gQUNQSTogVXNpbmcgSU9BUElDIGZvciBpbnRlcnJ1cHQgcm91
dGluZwpbICAgIDAuMDYwMzUwXSBQQ0k6IElnbm9yaW5nIGhvc3QgYnJpZGdlIHdpbmRvd3MgZnJv
bSBBQ1BJOyBpZiBuZWNlc3NhcnksIHVzZSAicGNpPXVzZV9jcnMiIGFuZCByZXBvcnQgYSBidWcK
WyAgICAwLjA2MTYyNl0gQUNQSTogUENJIFJvb3QgQnJpZGdlIFtQQ0kwXSAoZG9tYWluIDAwMDAg
W2J1cyAwMC1mZl0pClsgICAgMC4wNjQwMjNdIHBjaV9yb290IFBOUDBBMDM6MDA6IGhvc3QgYnJp
ZGdlIHdpbmRvdyBbaW8gIDB4MDAwMC0weDBjZjddIChpZ25vcmVkKQpbICAgIDAuMDY0MTM1XSBw
Y2lfcm9vdCBQTlAwQTAzOjAwOiBob3N0IGJyaWRnZSB3aW5kb3cgW2lvICAweDBkMDAtMHhmZmZm
XSAoaWdub3JlZCkKWyAgICAwLjA2NDI0Nl0gcGNpX3Jvb3QgUE5QMEEwMzowMDogaG9zdCBicmlk
Z2Ugd2luZG93IFttZW0gMHgwMDBhMDAwMC0weDAwMGJmZmZmXSAoaWdub3JlZCkKWyAgICAwLjA2
NDM1OF0gcGNpX3Jvb3QgUE5QMEEwMzowMDogaG9zdCBicmlkZ2Ugd2luZG93IFttZW0gMHhjMDAw
MDAwMC0weGZlYmZmZmZmXSAoaWdub3JlZCkKWyAgICAwLjA2NDUwNl0gcGNpIDAwMDA6MDA6MDAu
MDogWzgwODY6MzU5MF0gdHlwZSAwIGNsYXNzIDB4MDAwNjAwClsgICAgMC4wNjQ4NDBdIHBjaSAw
MDAwOjAwOjAyLjA6IFs4MDg2OjM1OTVdIHR5cGUgMSBjbGFzcyAweDAwMDYwNApbICAgIDAuMDY1
MTEyXSBwY2kgMDAwMDowMDowMi4wOiBQTUUjIHN1cHBvcnRlZCBmcm9tIEQwIEQzaG90IEQzY29s
ZApbICAgIDAuMDY1MjEzXSBwY2kgMDAwMDowMDowMi4wOiBQTUUjIGRpc2FibGVkClsgICAgMC4w
NjUzODBdIHBjaSAwMDAwOjAwOjA0LjA6IFs4MDg2OjM1OTddIHR5cGUgMSBjbGFzcyAweDAwMDYw
NApbICAgIDAuMDY1NjUwXSBwY2kgMDAwMDowMDowNC4wOiBQTUUjIHN1cHBvcnRlZCBmcm9tIEQw
IEQzaG90IEQzY29sZApbICAgIDAuMDY1NzUyXSBwY2kgMDAwMDowMDowNC4wOiBQTUUjIGRpc2Fi
bGVkClsgICAgMC4wNjU5MTJdIHBjaSAwMDAwOjAwOjA1LjA6IFs4MDg2OjM1OThdIHR5cGUgMSBj
bGFzcyAweDAwMDYwNApbICAgIDAuMDY2MTgyXSBwY2kgMDAwMDowMDowNS4wOiBQTUUjIHN1cHBv
cnRlZCBmcm9tIEQwIEQzaG90IEQzY29sZApbICAgIDAuMDY2Mjk0XSBwY2kgMDAwMDowMDowNS4w
OiBQTUUjIGRpc2FibGVkClsgICAgMC4wNjY0NThdIHBjaSAwMDAwOjAwOjA2LjA6IFs4MDg2OjM1
OTldIHR5cGUgMSBjbGFzcyAweDAwMDYwNApbICAgIDAuMDY2NzI4XSBwY2kgMDAwMDowMDowNi4w
OiBQTUUjIHN1cHBvcnRlZCBmcm9tIEQwIEQzaG90IEQzY29sZApbICAgIDAuMDY2ODI5XSBwY2kg
MDAwMDowMDowNi4wOiBQTUUjIGRpc2FibGVkClsgICAgMC4wNjcwNDRdIHBjaSAwMDAwOjAwOjFk
LjA6IFs4MDg2OjI0ZDJdIHR5cGUgMCBjbGFzcyAweDAwMGMwMwpbICAgIDAuMDY3MjcyXSBwY2kg
MDAwMDowMDoxZC4wOiByZWcgMjA6IFtpbyAgMHhhY2UwLTB4YWNmZl0KWyAgICAwLjA2NzQ2MF0g
cGNpIDAwMDA6MDA6MWQuMTogWzgwODY6MjRkNF0gdHlwZSAwIGNsYXNzIDB4MDAwYzAzClsgICAg
MC4wNjc2ODhdIHBjaSAwMDAwOjAwOjFkLjE6IHJlZyAyMDogW2lvICAweGFjYzAtMHhhY2RmXQpb
ICAgIDAuMDY3ODczXSBwY2kgMDAwMDowMDoxZC4yOiBbODA4NjoyNGQ3XSB0eXBlIDAgY2xhc3Mg
MHgwMDBjMDMKWyAgICAwLjA2ODA5OV0gcGNpIDAwMDA6MDA6MWQuMjogcmVnIDIwOiBbaW8gIDB4
YWNhMC0weGFjYmZdClsgICAgMC4wNjgzMTldIHBjaSAwMDAwOjAwOjFkLjc6IFs4MDg2OjI0ZGRd
IHR5cGUgMCBjbGFzcyAweDAwMGMwMwpbICAgIDAuMDcwMDAwXSBwY2kgMDAwMDowMDoxZC43OiBy
ZWcgMTA6IFttZW0gMHhkZmYwMDAwMC0weGRmZjAwM2ZmXQpbICAgIDAuMDcwMDAwXSBwY2kgMDAw
MDowMDoxZC43OiBQTUUjIHN1cHBvcnRlZCBmcm9tIEQwIEQzaG90IEQzY29sZApbICAgIDAuMDcw
MDAwXSBwY2kgMDAwMDowMDoxZC43OiBQTUUjIGRpc2FibGVkClsgICAgMC4wNzAwMDBdIHBjaSAw
MDAwOjAwOjFlLjA6IFs4MDg2OjI0NGVdIHR5cGUgMSBjbGFzcyAweDAwMDYwNApbICAgIDAuMDcw
MDM0XSBwY2kgMDAwMDowMDoxZi4wOiBbODA4NjoyNGQwXSB0eXBlIDAgY2xhc3MgMHgwMDA2MDEK
WyAgICAwLjA3MDM2Ml0gcGNpIDAwMDA6MDA6MWYuMTogWzgwODY6MjRkYl0gdHlwZSAwIGNsYXNz
IDB4MDAwMTAxClsgICAgMC4wNzA0OTNdIHBjaSAwMDAwOjAwOjFmLjE6IHJlZyAxMDogW2lvICAw
eDAwMDAtMHgwMDA3XQpbICAgIDAuMDcwNjEyXSBwY2kgMDAwMDowMDoxZi4xOiByZWcgMTQ6IFtp
byAgMHgwMDAwLTB4MDAwM10KWyAgICAwLjA3MDczMV0gcGNpIDAwMDA6MDA6MWYuMTogcmVnIDE4
OiBbaW8gIDB4MDAwMC0weDAwMDddClsgICAgMC4wNzA4NTBdIHBjaSAwMDAwOjAwOjFmLjE6IHJl
ZyAxYzogW2lvICAweDAwMDAtMHgwMDAzXQpbICAgIDAuMDcwOTcwXSBwY2kgMDAwMDowMDoxZi4x
OiByZWcgMjA6IFtpbyAgMHhmYzAwLTB4ZmMwZl0KWyAgICAwLjA3MTA4OV0gcGNpIDAwMDA6MDA6
MWYuMTogcmVnIDI0OiBbbWVtIDB4MDAwMDAwMDAtMHgwMDAwMDNmZl0KWyAgICAwLjA3MTQwN10g
cGNpIDAwMDA6MDE6MDAuMDogWzgwODY6MDMzMF0gdHlwZSAxIGNsYXNzIDB4MDAwNjA0ClsgICAg
MC4wNzE2ODNdIHBjaSAwMDAwOjAxOjAwLjA6IFBNRSMgc3VwcG9ydGVkIGZyb20gRDAgRDNob3Qg
RDNjb2xkClsgICAgMC4wNzE3ODVdIHBjaSAwMDAwOjAxOjAwLjA6IFBNRSMgZGlzYWJsZWQKWyAg
ICAwLjA3MTk0Nl0gcGNpIDAwMDA6MDE6MDAuMjogWzgwODY6MDMzMl0gdHlwZSAxIGNsYXNzIDB4
MDAwNjA0ClsgICAgMC4wNzIyMjJdIHBjaSAwMDAwOjAxOjAwLjI6IFBNRSMgc3VwcG9ydGVkIGZy
b20gRDAgRDNob3QgRDNjb2xkClsgICAgMC4wNzIzMjNdIHBjaSAwMDAwOjAxOjAwLjI6IFBNRSMg
ZGlzYWJsZWQKWyAgICAwLjA3MjQ3MF0gcGNpIDAwMDA6MDE6MDAuMDogZGlzYWJsaW5nIEFTUE0g
b24gcHJlLTEuMSBQQ0llIGRldmljZS4gIFlvdSBjYW4gZW5hYmxlIGl0IHdpdGggJ3BjaWVfYXNw
bT1mb3JjZScKWyAgICAwLjA3MjYxMl0gcGNpIDAwMDA6MDA6MDIuMDogUENJIGJyaWRnZSB0byBb
YnVzIDAxLTAzXQpbICAgIDAuMDcyNzEzXSBwY2kgMDAwMDowMDowMi4wOiAgIGJyaWRnZSB3aW5k
b3cgW2lvICAweGUwMDAtMHhlZmZmXQpbICAgIDAuMDcyODE1XSBwY2kgMDAwMDowMDowMi4wOiAg
IGJyaWRnZSB3aW5kb3cgW21lbSAweGRmYzAwMDAwLTB4ZGZlZmZmZmZdClsgICAgMC4wNzI5MjVd
IHBjaSAwMDAwOjAwOjAyLjA6ICAgYnJpZGdlIHdpbmRvdyBbbWVtIDB4ZDgwMDAwMDAtMHhkOGZm
ZmZmZiA2NGJpdCBwcmVmXQpbICAgIDAuMDczMjA1XSBwY2kgMDAwMDowMjowNS4wOiBbMTAwMDow
MDMwXSB0eXBlIDAgY2xhc3MgMHgwMDAxMDAKWyAgICAwLjA3MzM1OV0gcGNpIDAwMDA6MDI6MDUu
MDogcmVnIDEwOiBbaW8gIDB4ZWMwMC0weGVjZmZdClsgICAgMC4wNzM0OTFdIHBjaSAwMDAwOjAy
OjA1LjA6IHJlZyAxNDogW21lbSAweGRmZGYwMDAwLTB4ZGZkZmZmZmYgNjRiaXRdClsgICAgMC4w
NzM2MjVdIHBjaSAwMDAwOjAyOjA1LjA6IHJlZyAxYzogW21lbSAweGRmZGUwMDAwLTB4ZGZkZWZm
ZmYgNjRiaXRdClsgICAgMC4wNzM3NzBdIHBjaSAwMDAwOjAyOjA1LjA6IHJlZyAzMDogW21lbSAw
eGRmZTAwMDAwLTB4ZGZlZmZmZmYgcHJlZl0KWyAgICAwLjA3MzkzOF0gcGNpIDAwMDA6MDI6MDUu
MDogc3VwcG9ydHMgRDEgRDIKWyAgICAwLjA3NDE0N10gcGNpIDAwMDA6MDE6MDAuMDogUENJIGJy
aWRnZSB0byBbYnVzIDAyLTAyXQpbICAgIDAuMDc0MjQ3XSBwY2kgMDAwMDowMTowMC4wOiAgIGJy
aWRnZSB3aW5kb3cgW2lvICAweGUwMDAtMHhlZmZmXQpbICAgIDAuMDc0MzQ5XSBwY2kgMDAwMDow
MTowMC4wOiAgIGJyaWRnZSB3aW5kb3cgW21lbSAweGRmZDAwMDAwLTB4ZGZlZmZmZmZdClsgICAg
MC4wNzQ0NTldIHBjaSAwMDAwOjAxOjAwLjA6ICAgYnJpZGdlIHdpbmRvdyBbbWVtIDB4ZDgwMDAw
MDAtMHhkOGZmZmZmZiA2NGJpdCBwcmVmXQpbICAgIDAuMDc0Nzg5XSBwY2kgMDAwMDowMTowMC4y
OiBQQ0kgYnJpZGdlIHRvIFtidXMgMDMtMDNdClsgICAgMC4wNzQ4OTBdIHBjaSAwMDAwOjAxOjAw
LjI6ICAgYnJpZGdlIHdpbmRvdyBbaW8gIDB4ZjAwMC0weDAwMDBdIChkaXNhYmxlZCkKWyAgICAw
LjA3NDk5NF0gcGNpIDAwMDA6MDE6MDAuMjogICBicmlkZ2Ugd2luZG93IFttZW0gMHhmZmYwMDAw
MC0weDAwMGZmZmZmXSAoZGlzYWJsZWQpClsgICAgMC4wNzUxMTldIHBjaSAwMDAwOjAxOjAwLjI6
ICAgYnJpZGdlIHdpbmRvdyBbbWVtIDB4ZmZmMDAwMDAtMHgwMDBmZmZmZiBwcmVmXSAoZGlzYWJs
ZWQpClsgICAgMC4wNzUzOTVdIHBjaSAwMDAwOjAwOjA0LjA6IFBDSSBicmlkZ2UgdG8gW2J1cyAw
NC0wNF0KWyAgICAwLjA3NTQ5NV0gcGNpIDAwMDA6MDA6MDQuMDogICBicmlkZ2Ugd2luZG93IFtp
byAgMHhmMDAwLTB4MDAwMF0gKGRpc2FibGVkKQpbICAgIDAuMDc1NTk5XSBwY2kgMDAwMDowMDow
NC4wOiAgIGJyaWRnZSB3aW5kb3cgW21lbSAweGZmZjAwMDAwLTB4MDAwZmZmZmZdIChkaXNhYmxl
ZCkKWyAgICAwLjA3NTcyNF0gcGNpIDAwMDA6MDA6MDQuMDogICBicmlkZ2Ugd2luZG93IFttZW0g
MHhmZmYwMDAwMC0weDAwMGZmZmZmIHByZWZdIChkaXNhYmxlZCkKWyAgICAwLjA3NTk4N10gcGNp
IDAwMDA6MDU6MDAuMDogWzgwODY6MDMyOV0gdHlwZSAxIGNsYXNzIDB4MDAwNjA0ClsgICAgMC4w
NzYxNDZdIHBjaSAwMDAwOjA1OjAwLjA6IFBYSCBxdWlyayBkZXRlY3RlZDsgU0hQQyBkZXZpY2Ug
TVNJIGRpc2FibGVkClsgICAgMC4wNzY0MTddIHBjaSAwMDAwOjA1OjAwLjA6IFBNRSMgc3VwcG9y
dGVkIGZyb20gRDAgRDNob3QgRDNjb2xkClsgICAgMC4wNzY1MjFdIHBjaSAwMDAwOjA1OjAwLjA6
IFBNRSMgZGlzYWJsZWQKWyAgICAwLjA3NjY4Nl0gcGNpIDAwMDA6MDU6MDAuMjogWzgwODY6MDMy
YV0gdHlwZSAxIGNsYXNzIDB4MDAwNjA0ClsgICAgMC4wNzY4NDRdIHBjaSAwMDAwOjA1OjAwLjI6
IFBYSCBxdWlyayBkZXRlY3RlZDsgU0hQQyBkZXZpY2UgTVNJIGRpc2FibGVkClsgICAgMC4wNzcx
MTVdIHBjaSAwMDAwOjA1OjAwLjI6IFBNRSMgc3VwcG9ydGVkIGZyb20gRDAgRDNob3QgRDNjb2xk
ClsgICAgMC4wNzcyMTZdIHBjaSAwMDAwOjA1OjAwLjI6IFBNRSMgZGlzYWJsZWQKWyAgICAwLjA3
NzM2Ml0gcGNpIDAwMDA6MDU6MDAuMDogZGlzYWJsaW5nIEFTUE0gb24gcHJlLTEuMSBQQ0llIGRl
dmljZS4gIFlvdSBjYW4gZW5hYmxlIGl0IHdpdGggJ3BjaWVfYXNwbT1mb3JjZScKWyAgICAwLjA3
NzUwNl0gcGNpIDAwMDA6MDA6MDUuMDogUENJIGJyaWRnZSB0byBbYnVzIDA1LTA3XQpbICAgIDAu
MDc3NjA4XSBwY2kgMDAwMDowMDowNS4wOiAgIGJyaWRnZSB3aW5kb3cgW2lvICAweGMwMDAtMHhk
ZmZmXQpbICAgIDAuMDc3NzEwXSBwY2kgMDAwMDowMDowNS4wOiAgIGJyaWRnZSB3aW5kb3cgW21l
bSAweGRmNzAwMDAwLTB4ZGZiZmZmZmZdClsgICAgMC4wNzc4MjBdIHBjaSAwMDAwOjAwOjA1LjA6
ICAgYnJpZGdlIHdpbmRvdyBbbWVtIDB4ZmZmMDAwMDAtMHgwMDBmZmZmZiBwcmVmXSAoZGlzYWJs
ZWQpClsgICAgMC4wNzgxMDFdIHBjaSAwMDAwOjA2OjA3LjA6IFs4MDg2OjEwNzZdIHR5cGUgMCBj
bGFzcyAweDAwMDIwMApbICAgIDAuMDc4MjQ5XSBwY2kgMDAwMDowNjowNy4wOiByZWcgMTA6IFtt
ZW0gMHhkZmFlMDAwMC0weGRmYWZmZmZmXQpbICAgIDAuMDc4MzkzXSBwY2kgMDAwMDowNjowNy4w
OiByZWcgMTg6IFtpbyAgMHhkY2MwLTB4ZGNmZl0KWyAgICAwLjA3ODY0NF0gcGNpIDAwMDA6MDY6
MDcuMDogUE1FIyBzdXBwb3J0ZWQgZnJvbSBEMCBEM2hvdCBEM2NvbGQKWyAgICAwLjA3ODc0NV0g
cGNpIDAwMDA6MDY6MDcuMDogUE1FIyBkaXNhYmxlZApbICAgIDAuMDc4OTQxXSBwY2kgMDAwMDow
NTowMC4wOiBQQ0kgYnJpZGdlIHRvIFtidXMgMDYtMDZdClsgICAgMC4wNzkwNDFdIHBjaSAwMDAw
OjA1OjAwLjA6ICAgYnJpZGdlIHdpbmRvdyBbaW8gIDB4ZDAwMC0weGRmZmZdClsgICAgMC4wNzkx
NDNdIHBjaSAwMDAwOjA1OjAwLjA6ICAgYnJpZGdlIHdpbmRvdyBbbWVtIDB4ZGZhMDAwMDAtMHhk
ZmJmZmZmZl0KWyAgICAwLjA3OTI1M10gcGNpIDAwMDA6MDU6MDAuMDogICBicmlkZ2Ugd2luZG93
IFttZW0gMHhmZmYwMDAwMC0weDAwMGZmZmZmIHByZWZdIChkaXNhYmxlZCkKWyAgICAwLjA3OTU0
NF0gcGNpIDAwMDA6MDc6MDguMDogWzgwODY6MTA3Nl0gdHlwZSAwIGNsYXNzIDB4MDAwMjAwClsg
ICAgMC4wNzk2OTJdIHBjaSAwMDAwOjA3OjA4LjA6IHJlZyAxMDogW21lbSAweGRmOGUwMDAwLTB4
ZGY4ZmZmZmZdClsgICAgMC4wNzk4MzZdIHBjaSAwMDAwOjA3OjA4LjA6IHJlZyAxODogW2lvICAw
eGNjYzAtMHhjY2ZmXQpbICAgIDAuMDgwMDAwXSBwY2kgMDAwMDowNzowOC4wOiBQTUUjIHN1cHBv
cnRlZCBmcm9tIEQwIEQzaG90IEQzY29sZApbICAgIDAuMDgwMDAwXSBwY2kgMDAwMDowNzowOC4w
OiBQTUUjIGRpc2FibGVkClsgICAgMC4wODAwMDBdIHBjaSAwMDAwOjA1OjAwLjI6IFBDSSBicmlk
Z2UgdG8gW2J1cyAwNy0wN10KWyAgICAwLjA4MDAwMF0gcGNpIDAwMDA6MDU6MDAuMjogICBicmlk
Z2Ugd2luZG93IFtpbyAgMHhjMDAwLTB4Y2ZmZl0KWyAgICAwLjA4MDAwMF0gcGNpIDAwMDA6MDU6
MDAuMjogICBicmlkZ2Ugd2luZG93IFttZW0gMHhkZjgwMDAwMC0weGRmOWZmZmZmXQpbICAgIDAu
MDgwMDAwXSBwY2kgMDAwMDowNTowMC4yOiAgIGJyaWRnZSB3aW5kb3cgW21lbSAweGZmZjAwMDAw
LTB4MDAwZmZmZmYgcHJlZl0gKGRpc2FibGVkKQpbICAgIDAuMDgwMDAwXSBwY2kgMDAwMDowMDow
Ni4wOiBQQ0kgYnJpZGdlIHRvIFtidXMgMDgtMDhdClsgICAgMC4wODAwMDBdIHBjaSAwMDAwOjAw
OjA2LjA6ICAgYnJpZGdlIHdpbmRvdyBbaW8gIDB4ZjAwMC0weDAwMDBdIChkaXNhYmxlZCkKWyAg
ICAwLjA4MDAwMF0gcGNpIDAwMDA6MDA6MDYuMDogICBicmlkZ2Ugd2luZG93IFttZW0gMHhmZmYw
MDAwMC0weDAwMGZmZmZmXSAoZGlzYWJsZWQpClsgICAgMC4wODAwMDBdIHBjaSAwMDAwOjAwOjA2
LjA6ICAgYnJpZGdlIHdpbmRvdyBbbWVtIDB4ZmZmMDAwMDAtMHgwMDBmZmZmZiBwcmVmXSAoZGlz
YWJsZWQpClsgICAgMC4wODAwNzddIHBjaSAwMDAwOjA5OjA1LjA6IFsxMDI4OjAwMTFdIHR5cGUg
MCBjbGFzcyAweDAwZmYwMApbICAgIDAuMDgwMjE5XSBwY2kgMDAwMDowOTowNS4wOiByZWcgMTA6
IFttZW0gMHhkN2ZmZjAwMC0weGQ3ZmZmZmZmIHByZWZdClsgICAgMC4wODAzNDFdIHBjaSAwMDAw
OjA5OjA1LjA6IHJlZyAxNDogW2lvICAweGJjZjgtMHhiY2ZmXQpbICAgIDAuMDgwNDYwXSBwY2kg
MDAwMDowOTowNS4wOiByZWcgMTg6IFtpbyAgMHhiY2U4LTB4YmNlZl0KWyAgICAwLjA4MDY1NV0g
cGNpIDAwMDA6MDk6MDUuMDogcmVnIDMwOiBbbWVtIDB4ZGY2MDAwMDAtMHhkZjYwZmZmZiBwcmVm
XQpbICAgIDAuMDgwODQ4XSBwY2kgMDAwMDowOTowNS4xOiBbMTAyODowMDEyXSB0eXBlIDAgY2xh
c3MgMHgwMGZmMDAKWyAgICAwLjA4MDk5MF0gcGNpIDAwMDA6MDk6MDUuMTogcmVnIDEwOiBbbWVt
IDB4ZGY1ZmYwMDAtMHhkZjVmZmZmZl0KWyAgICAwLjA4MTExMF0gcGNpIDAwMDA6MDk6MDUuMTog
cmVnIDE0OiBbaW8gIDB4YmM4MC0weGJjYmZdClsgICAgMC4wODEyMzBdIHBjaSAwMDAwOjA5OjA1
LjE6IHJlZyAxODogW21lbSAweGQ3ZjAwMDAwLTB4ZDdmN2ZmZmYgcHJlZl0KWyAgICAwLjA4MTUx
OF0gcGNpIDAwMDA6MDk6MDUuMjogWzEwMjg6MDAxNF0gdHlwZSAwIGNsYXNzIDB4MDBmZjAwClsg
ICAgMC4wODE5MTNdIHBjaSAwMDAwOjA5OjA2LjA6IFsxMDk1OjA2ODBdIHR5cGUgMCBjbGFzcyAw
eDAwMDEwMQpbICAgIDAuMDgyMDUzXSBwY2kgMDAwMDowOTowNi4wOiByZWcgMTA6IFtpbyAgMHhi
Y2YwLTB4YmNmN10KWyAgICAwLjA4MjE3Ml0gcGNpIDAwMDA6MDk6MDYuMDogcmVnIDE0OiBbaW8g
IDB4YmNlNC0weGJjZTddClsgICAgMC4wODIyOTFdIHBjaSAwMDAwOjA5OjA2LjA6IHJlZyAxODog
W2lvICAweGJjZDgtMHhiY2RmXQpbICAgIDAuMDgyNDA5XSBwY2kgMDAwMDowOTowNi4wOiByZWcg
MWM6IFtpbyAgMHhiY2QwLTB4YmNkM10KWyAgICAwLjA4MjUyOF0gcGNpIDAwMDA6MDk6MDYuMDog
cmVnIDIwOiBbaW8gIDB4YmM3MC0weGJjN2ZdClsgICAgMC4wODI2NDddIHBjaSAwMDAwOjA5OjA2
LjA6IHJlZyAyNDogW21lbSAweGRmNWZlYzAwLTB4ZGY1ZmVjZmZdClsgICAgMC4wODI3NjZdIHBj
aSAwMDAwOjA5OjA2LjA6IHJlZyAzMDogW21lbSAweGRmNjAwMDAwLTB4ZGY2N2ZmZmYgcHJlZl0K
WyAgICAwLjA4MjkxNV0gcGNpIDAwMDA6MDk6MDYuMDogc3VwcG9ydHMgRDEgRDIKWyAgICAwLjA4
MzA3MV0gcGNpIDAwMDA6MDk6MGQuMDogWzEwMDI6NTE1OV0gdHlwZSAwIGNsYXNzIDB4MDAwMzAw
ClsgICAgMC4wODMyMTFdIHBjaSAwMDAwOjA5OjBkLjA6IHJlZyAxMDogW21lbSAweGM4MDAwMDAw
LTB4Y2ZmZmZmZmYgcHJlZl0KWyAgICAwLjA4MzMzMl0gcGNpIDAwMDA6MDk6MGQuMDogcmVnIDE0
OiBbaW8gIDB4YjgwMC0weGI4ZmZdClsgICAgMC4wODM0NTFdIHBjaSAwMDAwOjA5OjBkLjA6IHJl
ZyAxODogW21lbSAweGRmNWUwMDAwLTB4ZGY1ZWZmZmZdClsgICAgMC4wODM2NDNdIHBjaSAwMDAw
OjA5OjBkLjA6IHJlZyAzMDogW21lbSAweDAwMDAwMDAwLTB4MDAwMWZmZmYgcHJlZl0KWyAgICAw
LjA4Mzc4OF0gcGNpIDAwMDA6MDk6MGQuMDogc3VwcG9ydHMgRDEgRDIKWyAgICAwLjA4Mzk1OF0g
cGNpIDAwMDA6MDA6MWUuMDogUENJIGJyaWRnZSB0byBbYnVzIDA5LTA5XSAoc3VidHJhY3RpdmUg
ZGVjb2RlKQpbICAgIDAuMDg0MDcwXSBwY2kgMDAwMDowMDoxZS4wOiAgIGJyaWRnZSB3aW5kb3cg
W2lvICAweGIwMDAtMHhiZmZmXQpbICAgIDAuMDg0MTczXSBwY2kgMDAwMDowMDoxZS4wOiAgIGJy
aWRnZSB3aW5kb3cgW21lbSAweGRmNTAwMDAwLTB4ZGY2ZmZmZmZdClsgICAgMC4wODQyNzZdIHBj
aSAwMDAwOjAwOjFlLjA6ICAgYnJpZGdlIHdpbmRvdyBbbWVtIDB4YzgwMDAwMDAtMHhkN2ZmZmZm
ZiBwcmVmXQpbICAgIDAuMDg0Mzg3XSBwY2kgMDAwMDowMDoxZS4wOiAgIGJyaWRnZSB3aW5kb3cg
W2lvICAweDAwMDAtMHhmZmZmXSAoc3VidHJhY3RpdmUgZGVjb2RlKQpbICAgIDAuMDg0NDk5XSBw
Y2kgMDAwMDowMDoxZS4wOiAgIGJyaWRnZSB3aW5kb3cgW21lbSAweDAwMDAwMDAwLTB4ZmZmZmZm
ZmZmXSAoc3VidHJhY3RpdmUgZGVjb2RlKQpbICAgIDAuMDg0Njg0XSBwY2lfYnVzIDAwMDA6MDA6
IG9uIE5VTUEgbm9kZSAwClsgICAgMC4wODQ3NzldIEFDUEk6IFBDSSBJbnRlcnJ1cHQgUm91dGlu
ZyBUYWJsZSBbXF9TQl8uUENJMC5fUFJUXQpbICAgIDAuMDg1NTUxXSBBQ1BJOiBQQ0kgSW50ZXJy
dXB0IFJvdXRpbmcgVGFibGUgW1xfU0JfLlBDSTAuUEFMTy5fUFJUXQpbICAgIDAuMDg1OTkyXSBB
Q1BJOiBQQ0kgSW50ZXJydXB0IFJvdXRpbmcgVGFibGUgW1xfU0JfLlBDSTAuUEFMTy5ET0JBLl9Q
UlRdClsgICAgMC4wODY2MzBdIEFDUEk6IFBDSSBJbnRlcnJ1cHQgUm91dGluZyBUYWJsZSBbXF9T
Ql8uUENJMC5QQUxPLkRPQkIuX1BSVF0KWyAgICAwLjA4NzE0MV0gQUNQSTogUENJIEludGVycnVw
dCBSb3V0aW5nIFRhYmxlIFtcX1NCXy5QQ0kwLlBCTE8uX1BSVF0KWyAgICAwLjA4NzU0OV0gQUNQ
STogUENJIEludGVycnVwdCBSb3V0aW5nIFRhYmxlIFtcX1NCXy5QQ0kwLlZQUjAuX1BSVF0KWyAg
ICAwLjA4Nzk1Nl0gQUNQSTogUENJIEludGVycnVwdCBSb3V0aW5nIFRhYmxlIFtcX1NCXy5QQ0kw
LlBCSEkuX1BSVF0KWyAgICAwLjA4ODM5NV0gQUNQSTogUENJIEludGVycnVwdCBSb3V0aW5nIFRh
YmxlIFtcX1NCXy5QQ0kwLlBCSEkuUFhCMS5fUFJUXQpbICAgIDAuMDg4Njk5XSBBQ1BJOiBQQ0kg
SW50ZXJydXB0IFJvdXRpbmcgVGFibGUgW1xfU0JfLlBDSTAuUEJISS5QWEIyLl9QUlRdClsgICAg
MC4wODg5NzFdIEFDUEk6IFBDSSBJbnRlcnJ1cHQgUm91dGluZyBUYWJsZSBbXF9TQl8uUENJMC5Q
SUNILl9QUlRdClsgICAgMC4wODk4NDVdICBwY2kwMDAwOjAwOiBSZXF1ZXN0aW5nIEFDUEkgX09T
QyBjb250cm9sICgweDFkKQpbICAgIDAuMDg5OTQyXSAgcGNpMDAwMDowMDogQUNQSSBfT1NDIHJl
cXVlc3QgZmFpbGVkIChBRV9OT1RfRk9VTkQpLCByZXR1cm5lZCBjb250cm9sIG1hc2s6IDB4MWQK
WyAgICAwLjA5MDAxMF0gQUNQSSBfT1NDIGNvbnRyb2wgZm9yIFBDSWUgbm90IGdyYW50ZWQsIGRp
c2FibGluZyBBU1BNClsgICAgMC4wOTkxMDFdIEFDUEk6IFBDSSBJbnRlcnJ1cHQgTGluayBbTE5L
QV0gKElSUXMgMyA0IDUgNiA3IDEwICoxMSAxMikKWyAgICAwLjEwMDA0OF0gQUNQSTogUENJIElu
dGVycnVwdCBMaW5rIFtMTktCXSAoSVJRcyAqMyA0IDUgNiA3IDEwIDExIDEyKQpbICAgIDAuMTAx
MDMyXSBBQ1BJOiBQQ0kgSW50ZXJydXB0IExpbmsgW0xOS0NdIChJUlFzIDMgNCA1IDYgKjcgMTAg
MTEgMTIpClsgICAgMC4xMDIwMTRdIEFDUEk6IFBDSSBJbnRlcnJ1cHQgTGluayBbTE5LRF0gKElS
UXMgMyA0IDUgNiA3ICoxMCAxMSAxMikKWyAgICAwLjEwMjk5Nl0gQUNQSTogUENJIEludGVycnVw
dCBMaW5rIFtMTktFXSAoSVJRcyAzIDQgNSA2IDcgMTAgKjExIDEyKQpbICAgIDAuMTAzOTc4XSBB
Q1BJOiBQQ0kgSW50ZXJydXB0IExpbmsgW0xOS0ZdIChJUlFzIDMgNCA1IDYgNyAqMTAgMTEgMTIp
ClsgICAgMC4xMDQ5NzFdIEFDUEk6IFBDSSBJbnRlcnJ1cHQgTGluayBbTE5LR10gKElSUXMgMyA0
IDUgNiA3IDEwIDExIDEyKSAqMCwgZGlzYWJsZWQuClsgICAgMC4xMDYxMDhdIEFDUEk6IFBDSSBJ
bnRlcnJ1cHQgTGluayBbTE5LSF0gKElSUXMgMyA0ICo1IDYgNyAxMCAxMSAxMikKWyAgICAwLjEw
Njk3Nl0geGVuL2JhbGxvb246IEluaXRpYWxpc2luZyBiYWxsb29uIGRyaXZlci4KWyAgICAwLjEw
NzA3MV0gbGFzdF9wZm4gPSAweDFkZmZjMCBtYXhfYXJjaF9wZm4gPSAweDEwMDAwMDAKWyAgICAw
LjEyNjU3MF0geGVuLWJhbGxvb246IEluaXRpYWxpc2luZyBiYWxsb29uIGRyaXZlci4KWyAgICAw
LjEyNjgzOV0gdmdhYXJiOiBkZXZpY2UgYWRkZWQ6IFBDSTowMDAwOjA5OjBkLjAsZGVjb2Rlcz1p
byttZW0sb3ducz1pbyttZW0sbG9ja3M9bm9uZQpbICAgIDAuMTI2OTUxXSB2Z2FhcmI6IGxvYWRl
ZApbICAgIDAuMTI3MDM5XSB2Z2FhcmI6IGJyaWRnZSBjb250cm9sIHBvc3NpYmxlIDAwMDA6MDk6
MGQuMApbICAgIDAuMTI3MTMxXSB1c2Jjb3JlOiBVU0Igc3VwcG9ydCBkaXNhYmxlZApbICAgIDAu
MTI3MzUzXSBQQ0k6IFVzaW5nIEFDUEkgZm9yIElSUSByb3V0aW5nClsgICAgMC4xMzAwMDBdIFBD
STogcGNpX2NhY2hlX2xpbmVfc2l6ZSBzZXQgdG8gNjQgYnl0ZXMKWyAgICAwLjEzMDAwMF0gcmVz
ZXJ2ZSBSQU0gYnVmZmVyOiAwMDAwMDAwMWRmZmMwMDAwIC0gMDAwMDAwMDFkZmZmZmZmZiAKWyAg
ICAwLjEzMDI5M10gU3dpdGNoaW5nIHRvIGNsb2Nrc291cmNlIHhlbgpbICAgIDAuMTMwNzM4XSBw
bnA6IFBuUCBBQ1BJIGluaXQKWyAgICAwLjEzMDgzOV0gQUNQSTogYnVzIHR5cGUgcG5wIHJlZ2lz
dGVyZWQKWyAgICAwLjEzMjE0NV0gcG5wIDAwOjAwOiBbYnVzIDAwLWZmXQpbICAgIDAuMTMyMjM4
XSBwbnAgMDA6MDA6IFtpbyAgMHgwMDAwLTB4MGNmNyB3aW5kb3ddClsgICAgMC4xMzIzMzFdIHBu
cCAwMDowMDogW2lvICAweDBjZjgtMHgwY2ZmXQpbICAgIDAuMTMyNDIzXSBwbnAgMDA6MDA6IFtp
byAgMHgwZDAwLTB4ZmZmZiB3aW5kb3ddClsgICAgMC4xMzI1MTZdIHBucCAwMDowMDogW21lbSAw
eDAwMGEwMDAwLTB4MDAwYmZmZmYgd2luZG93XQpbICAgIDAuMTMyNjEwXSBwbnAgMDA6MDA6IFtt
ZW0gMHhjMDAwMDAwMC0weGZlYmZmZmZmIHdpbmRvd10KWyAgICAwLjEzMjcwNF0gcG5wIDAwOjAw
OiBbbWVtIDB4MTAwMDAwMDAwLTB4ZmZmZmZmZmZmIHdpbmRvd10KWyAgICAwLjEzMjkwNF0gcG5w
IDAwOjAwOiBQbHVnIGFuZCBQbGF5IEFDUEkgZGV2aWNlLCBJRHMgUE5QMGEwMyAoYWN0aXZlKQpb
ICAgIDAuMTMzMDgzXSBwbnAgMDA6MDE6IFtpbyAgMHgwMDgwLTB4MDA5Zl0KWyAgICAwLjEzMzE3
NV0gcG5wIDAwOjAxOiBbaW8gIDB4MDAwMC0weDAwMWZdClsgICAgMC4xMzMyNjddIHBucCAwMDow
MTogW2lvICAweDAwYzAtMHgwMGRmXQpbICAgIDAuMTMzMzU5XSBwbnAgMDA6MDE6IFtkbWEgNF0K
WyAgICAwLjEzMzUwMV0gcG5wIDAwOjAxOiBQbHVnIGFuZCBQbGF5IEFDUEkgZGV2aWNlLCBJRHMg
UE5QMDIwMCAoYWN0aXZlKQpbICAgIDAuMTMzNjY4XSBwbnAgMDA6MDI6IFtpbyAgMHgwMGYwLTB4
MDBmZl0KWyAgICAwLjEzMzc2NF0geGVuOiByZWdpc3RlcmluZyBnc2kgMTMgdHJpZ2dlcmluZyAx
IHBvbGFyaXR5IDAKWyAgICAwLjEzMzg1OF0geGVuX21hcF9waXJxX2dzaTogcmV0dXJuaW5nIGly
cSAxMyBmb3IgZ3NpIDEzClsgICAgMC4xMzM5NTBdIHhlbjogLS0+IHBpcnE9MTMgLT4gaXJxPTEz
IChnc2k9MTMpClsgICAgMC4xMzQwNTVdIHBucCAwMDowMjogW2lycSAxM10KWyAgICAwLjEzNDIw
MV0gcG5wIDAwOjAyOiBQbHVnIGFuZCBQbGF5IEFDUEkgZGV2aWNlLCBJRHMgUE5QMGMwNCAoYWN0
aXZlKQpbICAgIDAuMTM1NDM3XSBTd2l0Y2hlZCB0byBOT0h6IG1vZGUgb24gQ1BVICMxClsgICAg
MC4xMzYyNzhdIHBucCAwMDowMzogW2lvICAweDAwNjFdClsgICAgMC4xMzY0MjldIHBucCAwMDow
MzogUGx1ZyBhbmQgUGxheSBBQ1BJIGRldmljZSwgSURzIFBOUDA4MDAgKGFjdGl2ZSkKWyAgICAw
LjEzNjU5Nl0gcG5wIDAwOjA0OiBbaW8gIDB4MDA3MC0weDAwN2ZdClsgICAgMC4xMzY2ODhdIHhl
bjogcmVnaXN0ZXJpbmcgZ3NpIDggdHJpZ2dlcmluZyAxIHBvbGFyaXR5IDAKWyAgICAwLjEzNjIz
N10gU3dpdGNoZWQgdG8gTk9IeiBtb2RlIG9uIENQVSAjMgpbICAgIDAuMTM2ODY2XSB4ZW5fbWFw
X3BpcnFfZ3NpOiByZXR1cm5pbmcgaXJxIDggZm9yIGdzaSA4ClsgICAgMC4xMzY5NThdIHhlbjog
LS0+IHBpcnE9OCAtPiBpcnE9OCAoZ3NpPTgpClsgICAgMC4xMzcwNTVdIHBucCAwMDowNDogW2ly
cSA4XQpbICAgIDAuMTM3MjAxXSBwbnAgMDA6MDQ6IFBsdWcgYW5kIFBsYXkgQUNQSSBkZXZpY2Us
IElEcyBQTlAwYjAwIChhY3RpdmUpClsgICAgMC4xMzY5NzJdIFN3aXRjaGVkIHRvIE5PSHogbW9k
ZSBvbiBDUFUgIzMKWyAgICAwLjEzODEzMl0gcG5wIDAwOjA1OiBbaW8gIDB4MDNmMC0weDAzZjVd
ClsgICAgMC4xMzgyMjVdIHBucCAwMDowNTogW2lvICAweDAzZjddClsgICAgMC4xMzgzMTVdIHhl
bjogcmVnaXN0ZXJpbmcgZ3NpIDYgdHJpZ2dlcmluZyAxIHBvbGFyaXR5IDAKWyAgICAwLjEzODQw
OF0geGVuX21hcF9waXJxX2dzaTogcmV0dXJuaW5nIGlycSA2IGZvciBnc2kgNgpbICAgIDAuMTM4
NTAwXSB4ZW46IC0tPiBwaXJxPTYgLT4gaXJxPTYgKGdzaT02KQpbICAgIDAuMTM4NTk2XSBwbnAg
MDA6MDU6IFtpcnEgNl0KWyAgICAwLjEzODY4Nl0gcG5wIDAwOjA1OiBbZG1hIDJdClsgICAgMC4x
Mzg5MzRdIHBucCAwMDowNTogUGx1ZyBhbmQgUGxheSBBQ1BJIGRldmljZSwgSURzIFBOUDA3MDAg
KGFjdGl2ZSkKWyAgICAwLjEzOTgxMl0gcG5wIDAwOjA2OiBbaW8gIDB4MDA2MF0KWyAgICAwLjEz
OTkwNV0gcG5wIDAwOjA2OiBbaW8gIDB4MDA2NF0KWyAgICAwLjEzOTk5NV0geGVuOiByZWdpc3Rl
cmluZyBnc2kgMSB0cmlnZ2VyaW5nIDEgcG9sYXJpdHkgMApbICAgIDAuMTQwMDAwXSB4ZW5fbWFw
X3BpcnFfZ3NpOiByZXR1cm5pbmcgaXJxIDEgZm9yIGdzaSAxClsgICAgMC4xNDAwMDBdIHhlbjog
LS0+IHBpcnE9MSAtPiBpcnE9MSAoZ3NpPTEpClsgICAgMC4xNDAwMDBdIFN3aXRjaGVkIHRvIE5P
SHogbW9kZSBvbiBDUFUgIzAKWyAgICAwLjE0MDAwMF0gcG5wIDAwOjA2OiBbaXJxIDFdClsgICAg
MC4xNDAwMjldIHBucCAwMDowNjogUGx1ZyBhbmQgUGxheSBBQ1BJIGRldmljZSwgSURzIFBOUDAz
MDMgKGFjdGl2ZSkKWyAgICAwLjE0MTUzNV0geGVuOiByZWdpc3RlcmluZyBnc2kgMTIgdHJpZ2dl
cmluZyAxIHBvbGFyaXR5IDAKWyAgICAwLjE0MTYyOV0geGVuX21hcF9waXJxX2dzaTogcmV0dXJu
aW5nIGlycSAxMiBmb3IgZ3NpIDEyClsgICAgMC4xNDE3MjFdIHhlbjogLS0+IHBpcnE9MTIgLT4g
aXJxPTEyIChnc2k9MTIpClsgICAgMC4xNDE4MThdIHBucCAwMDowNzogW2lycSAxMl0KWyAgICAw
LjE0MTk3MV0gcG5wIDAwOjA3OiBQbHVnIGFuZCBQbGF5IEFDUEkgZGV2aWNlLCBJRHMgUE5QMGYx
MyAoYWN0aXZlKQpbICAgIDAuMTQyNjA0XSBwbnAgMDA6MDg6IFtpbyAgMHgwM2Y4LTB4MDNmZl0K
WyAgICAwLjE0MjY5N10geGVuOiByZWdpc3RlcmluZyBnc2kgNCB0cmlnZ2VyaW5nIDEgcG9sYXJp
dHkgMApbICAgIDAuMTQyNzkwXSB4ZW5fbWFwX3BpcnFfZ3NpOiByZXR1cm5pbmcgaXJxIDQgZm9y
IGdzaSA0ClsgICAgMC4xNDI4ODJdIHhlbjogLS0+IHBpcnE9NCAtPiBpcnE9NCAoZ3NpPTQpClsg
ICAgMC4xNDI5NzhdIHBucCAwMDowODogW2lycSA0XQpbICAgIDAuMTQzMjA5XSBwbnAgMDA6MDg6
IFBsdWcgYW5kIFBsYXkgQUNQSSBkZXZpY2UsIElEcyBQTlAwNTAxIChhY3RpdmUpClsgICAgMC4x
NDQ5MTVdIHBucCAwMDowOTogW2lvICAweDA4MDAtMHgwODdmXQpbICAgIDAuMTQ1MDA3XSBwbnAg
MDA6MDk6IFtpbyAgMHgwODgwLTB4MDhiZl0KWyAgICAwLjE0NTA5OV0gcG5wIDAwOjA5OiBbaW8g
IDB4MDhjMC0weDA4ZGZdClsgICAgMC4xNDUxOTBdIHBucCAwMDowOTogW2lvICAweDA4ZTAtMHgw
OGUzXQpbICAgIDAuMTQ1MjgyXSBwbnAgMDA6MDk6IFtpbyAgMHgwYzAwLTB4MGMwZl0KWyAgICAw
LjE0NTM3M10gcG5wIDAwOjA5OiBbaW8gIDB4MGMxMC0weDBjMWZdClsgICAgMC4xNDU0NjVdIHBu
cCAwMDowOTogW2lvICAweDBjYTAtMHgwY2E3XQpbICAgIDAuMTQ1NTU5XSBwbnAgMDA6MDk6IFtp
byAgMHgwY2E5LTB4MGNhYl0KWyAgICAwLjE0NTY1MF0gcG5wIDAwOjA5OiBbaW8gIDB4MGNhZC0w
eDBjYWZdClsgICAgMC4xNDU3NDJdIHBucCAwMDowOTogW2lvICAweDBjMjAtMHgwYzNmXQpbICAg
IDAuMTQ1ODMzXSBwbnAgMDA6MDk6IFtpbyAgMHgwMGUwLTB4MDBlN10KWyAgICAwLjE0NTkyNV0g
cG5wIDAwOjA5OiBbaW8gIDB4MDA2MC0weDAwNWYgZGlzYWJsZWRdClsgICAgMC4xNDYwMThdIHBu
cCAwMDowOTogW2lvICAweDAwNjQtMHgwMDYzIGRpc2FibGVkXQpbICAgIDAuMTQ2MjU1XSBzeXN0
ZW0gMDA6MDk6IFtpbyAgMHgwODAwLTB4MDg3Zl0gaGFzIGJlZW4gcmVzZXJ2ZWQKWyAgICAwLjE0
NjM1MV0gc3lzdGVtIDAwOjA5OiBbaW8gIDB4MDg4MC0weDA4YmZdIGhhcyBiZWVuIHJlc2VydmVk
ClsgICAgMC4xNDY0NDldIHN5c3RlbSAwMDowOTogW2lvICAweDA4YzAtMHgwOGRmXSBoYXMgYmVl
biByZXNlcnZlZApbICAgIDAuMTQ2NTQ1XSBzeXN0ZW0gMDA6MDk6IFtpbyAgMHgwOGUwLTB4MDhl
M10gaGFzIGJlZW4gcmVzZXJ2ZWQKWyAgICAwLjE0NjY0MF0gc3lzdGVtIDAwOjA5OiBbaW8gIDB4
MGMwMC0weDBjMGZdIGhhcyBiZWVuIHJlc2VydmVkClsgICAgMC4xNDY3MzZdIHN5c3RlbSAwMDow
OTogW2lvICAweDBjMTAtMHgwYzFmXSBoYXMgYmVlbiByZXNlcnZlZApbICAgIDAuMTQ2ODMxXSBz
eXN0ZW0gMDA6MDk6IFtpbyAgMHgwY2EwLTB4MGNhN10gaGFzIGJlZW4gcmVzZXJ2ZWQKWyAgICAw
LjE0NjkyN10gc3lzdGVtIDAwOjA5OiBbaW8gIDB4MGNhOS0weDBjYWJdIGhhcyBiZWVuIHJlc2Vy
dmVkClsgICAgMC4xNDcwMjJdIHN5c3RlbSAwMDowOTogW2lvICAweDBjYWQtMHgwY2FmXSBoYXMg
YmVlbiByZXNlcnZlZApbICAgIDAuMTQ3MTE4XSBzeXN0ZW0gMDA6MDk6IFtpbyAgMHgwYzIwLTB4
MGMzZl0gaGFzIGJlZW4gcmVzZXJ2ZWQKWyAgICAwLjE0NzIxNF0gc3lzdGVtIDAwOjA5OiBQbHVn
IGFuZCBQbGF5IEFDUEkgZGV2aWNlLCBJRHMgUE5QMGMwMSAoYWN0aXZlKQpbICAgIDAuMTQ3NDk4
XSBwbnAgMDA6MGE6IFtpbyAgMHgwY2E4XQpbICAgIDAuMTQ3NTg5XSBwbnAgMDA6MGE6IFtpbyAg
MHgwY2FjXQpbICAgIDAuMTQ3NzQ4XSBwbnAgMDA6MGE6IFBsdWcgYW5kIFBsYXkgQUNQSSBkZXZp
Y2UsIElEcyBJUEkwMDAxIChhY3RpdmUpClsgICAgMC4xNDkzMzFdIHBucCAwMDowYjogW21lbSAw
eGUwMDAwMDAwLTB4ZWZmZmZmZmZdClsgICAgMC4xNDk1NTldIHN5c3RlbSAwMDowYjogW21lbSAw
eGUwMDAwMDAwLTB4ZWZmZmZmZmZdIGhhcyBiZWVuIHJlc2VydmVkClsgICAgMC4xNDk2NTZdIHN5
c3RlbSAwMDowYjogUGx1ZyBhbmQgUGxheSBBQ1BJIGRldmljZSwgSURzIFBOUDBjMDIgKGFjdGl2
ZSkKWyAgICAwLjE0OTc4N10gcG5wIDAwOjBjOiBbbWVtIDB4ZmVkMDAwMDAtMHhmZWQwMDNmZl0K
WyAgICAwLjE0OTk2MV0gcG5wIDAwOjBjOiBQbHVnIGFuZCBQbGF5IEFDUEkgZGV2aWNlLCBJRHMg
UE5QMDEwMyAoYWN0aXZlKQpbICAgIDAuMTUwMjExXSBwbnA6IFBuUCBBQ1BJOiBmb3VuZCAxMyBk
ZXZpY2VzClsgICAgMC4xNTAyMTFdIEFDUEk6IEFDUEkgYnVzIHR5cGUgcG5wIHVucmVnaXN0ZXJl
ZApbICAgIDAuMTYwMTQwXSBQTS1UaW1lciBmYWlsZWQgY29uc2lzdGVuY3kgY2hlY2sgICgweDB4
ZmZmZmZmKSAtIGFib3J0aW5nLgpbICAgIDAuMTYwMjc2XSBwY2kgMDAwMDowOTowNi4wOiBhZGRy
ZXNzIHNwYWNlIGNvbGxpc2lvbjogW21lbSAweGRmNjAwMDAwLTB4ZGY2N2ZmZmYgcHJlZl0gY29u
ZmxpY3RzIHdpdGggMDAwMDowOTowNS4wIFttZW0gMHhkZjYwMDAwMC0weGRmNjBmZmZmIHByZWZd
ClsgICAgMC4xNjA0MDBdIFBDSTogbWF4IGJ1cyBkZXB0aDogMiBwY2lfdHJ5X251bTogMwpbICAg
IDAuMTYwNjcyXSBwY2kgMDAwMDowMDoxZi4xOiBCQVIgNTogYXNzaWduZWQgW21lbSAweGJmZmZm
MDAwLTB4YmZmZmYzZmZdClsgICAgMC4xNjA3NzddIHBjaSAwMDAwOjAwOjFmLjE6IEJBUiA1OiBz
ZXQgdG8gW21lbSAweGJmZmZmMDAwLTB4YmZmZmYzZmZdIChQQ0kgYWRkcmVzcyBbMHhiZmZmZjAw
MC0weGJmZmZmM2ZmXSkKWyAgICAwLjE2MDg5M10gcGNpIDAwMDA6MDE6MDAuMDogUENJIGJyaWRn
ZSB0byBbYnVzIDAyLTAyXQpbICAgIDAuMTYwOTg5XSBwY2kgMDAwMDowMTowMC4wOiAgIGJyaWRn
ZSB3aW5kb3cgW2lvICAweGUwMDAtMHhlZmZmXQpbICAgIDAuMTYxMDk0XSBwY2kgMDAwMDowMTow
MC4wOiAgIGJyaWRnZSB3aW5kb3cgW21lbSAweGRmZDAwMDAwLTB4ZGZlZmZmZmZdClsgICAgMC4x
NjExOTZdIHBjaSAwMDAwOjAxOjAwLjA6ICAgYnJpZGdlIHdpbmRvdyBbbWVtIDB4ZDgwMDAwMDAt
MHhkOGZmZmZmZiA2NGJpdCBwcmVmXQpbICAgIDAuMTYxMzIwXSBwY2kgMDAwMDowMTowMC4yOiBQ
Q0kgYnJpZGdlIHRvIFtidXMgMDMtMDNdClsgICAgMC4xNjE0MTJdIHBjaSAwMDAwOjAxOjAwLjI6
ICAgYnJpZGdlIHdpbmRvdyBbaW8gIGRpc2FibGVkXQpbICAgIDAuMTYxNTE0XSBwY2kgMDAwMDow
MTowMC4yOiAgIGJyaWRnZSB3aW5kb3cgW21lbSBkaXNhYmxlZF0KWyAgICAwLjE2MTYxM10gcGNp
IDAwMDA6MDE6MDAuMjogICBicmlkZ2Ugd2luZG93IFttZW0gcHJlZiBkaXNhYmxlZF0KWyAgICAw
LjE2MTcyMV0gcGNpIDAwMDA6MDA6MDIuMDogUENJIGJyaWRnZSB0byBbYnVzIDAxLTAzXQpbICAg
IDAuMTYxODE3XSBwY2kgMDAwMDowMDowMi4wOiAgIGJyaWRnZSB3aW5kb3cgW2lvICAweGUwMDAt
MHhlZmZmXQpbICAgIDAuMTYxOTIyXSBwY2kgMDAwMDowMDowMi4wOiAgIGJyaWRnZSB3aW5kb3cg
W21lbSAweGRmYzAwMDAwLTB4ZGZlZmZmZmZdClsgICAgMC4xNjIwMjRdIHBjaSAwMDAwOjAwOjAy
LjA6ICAgYnJpZGdlIHdpbmRvdyBbbWVtIDB4ZDgwMDAwMDAtMHhkOGZmZmZmZiA2NGJpdCBwcmVm
XQpbICAgIDAuMTYyMTQ4XSBwY2kgMDAwMDowMDowNC4wOiBQQ0kgYnJpZGdlIHRvIFtidXMgMDQt
MDRdClsgICAgMC4xNjIyNDBdIHBjaSAwMDAwOjAwOjA0LjA6ICAgYnJpZGdlIHdpbmRvdyBbaW8g
IGRpc2FibGVkXQpbICAgIDAuMTYyMzQzXSBwY2kgMDAwMDowMDowNC4wOiAgIGJyaWRnZSB3aW5k
b3cgW21lbSBkaXNhYmxlZF0KWyAgICAwLjE2MjQ0Ml0gcGNpIDAwMDA6MDA6MDQuMDogICBicmlk
Z2Ugd2luZG93IFttZW0gcHJlZiBkaXNhYmxlZF0KWyAgICAwLjE2MjU1MV0gcGNpIDAwMDA6MDU6
MDAuMDogUENJIGJyaWRnZSB0byBbYnVzIDA2LTA2XQpbICAgIDAuMTYyNjQ3XSBwY2kgMDAwMDow
NTowMC4wOiAgIGJyaWRnZSB3aW5kb3cgW2lvICAweGQwMDAtMHhkZmZmXQpbICAgIDAuMTYyNzUx
XSBwY2kgMDAwMDowNTowMC4wOiAgIGJyaWRnZSB3aW5kb3cgW21lbSAweGRmYTAwMDAwLTB4ZGZi
ZmZmZmZdClsgICAgMC4xNjI4NTJdIHBjaSAwMDAwOjA1OjAwLjA6ICAgYnJpZGdlIHdpbmRvdyBb
bWVtIHByZWYgZGlzYWJsZWRdClsgICAgMC4xNjI5NjBdIHBjaSAwMDAwOjA1OjAwLjI6IFBDSSBi
cmlkZ2UgdG8gW2J1cyAwNy0wN10KWyAgICAwLjE2MzA1Nl0gcGNpIDAwMDA6MDU6MDAuMjogICBi
cmlkZ2Ugd2luZG93IFtpbyAgMHhjMDAwLTB4Y2ZmZl0KWyAgICAwLjE2MzE2MV0gcGNpIDAwMDA6
MDU6MDAuMjogICBicmlkZ2Ugd2luZG93IFttZW0gMHhkZjgwMDAwMC0weGRmOWZmZmZmXQpbICAg
IDAuMTYzMjYyXSBwY2kgMDAwMDowNTowMC4yOiAgIGJyaWRnZSB3aW5kb3cgW21lbSBwcmVmIGRp
c2FibGVkXQpbICAgIDAuMTYzMzY5XSBwY2kgMDAwMDowMDowNS4wOiBQQ0kgYnJpZGdlIHRvIFti
dXMgMDUtMDddClsgICAgMC4xNjM0NjVdIHBjaSAwMDAwOjAwOjA1LjA6ICAgYnJpZGdlIHdpbmRv
dyBbaW8gIDB4YzAwMC0weGRmZmZdClsgICAgMC4xNjM1NjldIHBjaSAwMDAwOjAwOjA1LjA6ICAg
YnJpZGdlIHdpbmRvdyBbbWVtIDB4ZGY3MDAwMDAtMHhkZmJmZmZmZl0KWyAgICAwLjE2MzY3MF0g
cGNpIDAwMDA6MDA6MDUuMDogICBicmlkZ2Ugd2luZG93IFttZW0gcHJlZiBkaXNhYmxlZF0KWyAg
ICAwLjE2Mzc3OF0gcGNpIDAwMDA6MDA6MDYuMDogUENJIGJyaWRnZSB0byBbYnVzIDA4LTA4XQpb
ICAgIDAuMTYzODcwXSBwY2kgMDAwMDowMDowNi4wOiAgIGJyaWRnZSB3aW5kb3cgW2lvICBkaXNh
YmxlZF0KWyAgICAwLjE2Mzk3Ml0gcGNpIDAwMDA6MDA6MDYuMDogICBicmlkZ2Ugd2luZG93IFtt
ZW0gZGlzYWJsZWRdClsgICAgMC4xNjQwNzJdIHBjaSAwMDAwOjAwOjA2LjA6ICAgYnJpZGdlIHdp
bmRvdyBbbWVtIHByZWYgZGlzYWJsZWRdClsgICAgMC4xNjQxODNdIHBjaSAwMDAwOjA5OjA2LjA6
IEJBUiA2OiBhc3NpZ25lZCBbbWVtIDB4ZDAwMDAwMDAtMHhkMDA3ZmZmZiBwcmVmXQpbICAgIDAu
MTY0Mjk1XSBwY2kgMDAwMDowOTowZC4wOiBCQVIgNjogYXNzaWduZWQgW21lbSAweGQwMDgwMDAw
LTB4ZDAwOWZmZmYgcHJlZl0KWyAgICAwLjE2NDQwN10gcGNpIDAwMDA6MDA6MWUuMDogUENJIGJy
aWRnZSB0byBbYnVzIDA5LTA5XQpbICAgIDAuMTY0NTAzXSBwY2kgMDAwMDowMDoxZS4wOiAgIGJy
aWRnZSB3aW5kb3cgW2lvICAweGIwMDAtMHhiZmZmXQpbICAgIDAuMTY0NjA4XSBwY2kgMDAwMDow
MDoxZS4wOiAgIGJyaWRnZSB3aW5kb3cgW21lbSAweGRmNTAwMDAwLTB4ZGY2ZmZmZmZdClsgICAg
MC4xNjQ3MTBdIHBjaSAwMDAwOjAwOjFlLjA6ICAgYnJpZGdlIHdpbmRvdyBbbWVtIDB4YzgwMDAw
MDAtMHhkN2ZmZmZmZiBwcmVmXQpbICAgIDAuMTY0ODQ4XSB4ZW46IHJlZ2lzdGVyaW5nIGdzaSAx
NiB0cmlnZ2VyaW5nIDAgcG9sYXJpdHkgMQpbICAgIDAuMTY0OTUwXSB4ZW46IC0tPiBwaXJxPTE2
IC0+IGlycT0xNiAoZ3NpPTE2KQpbICAgIDAuMTY1MDQ4XSBwY2kgMDAwMDowMDowMi4wOiBQQ0kg
SU5UIEEgLT4gR1NJIDE2IChsZXZlbCwgbG93KSAtPiBJUlEgMTYKWyAgICAwLjE2NTE1M10gcGNp
IDAwMDA6MDA6MDIuMDogc2V0dGluZyBsYXRlbmN5IHRpbWVyIHRvIDY0ClsgICAgMC4xNjUyNjhd
IHBjaSAwMDAwOjAxOjAwLjA6IHNldHRpbmcgbGF0ZW5jeSB0aW1lciB0byA2NApbICAgIDAuMTY1
MzgyXSBwY2kgMDAwMDowMTowMC4yOiBzZXR0aW5nIGxhdGVuY3kgdGltZXIgdG8gNjQKWyAgICAw
LjE2NTQ4OV0geGVuOiByZWdpc3RlcmluZyBnc2kgMTYgdHJpZ2dlcmluZyAwIHBvbGFyaXR5IDEK
WyAgICAwLjE2NTU4Ml0geGVuX21hcF9waXJxX2dzaTogcmV0dXJuaW5nIGlycSAxNiBmb3IgZ3Np
IDE2ClsgICAgMC4xNjU2NzRdIHhlbjogLS0+IHBpcnE9MTYgLT4gaXJxPTE2IChnc2k9MTYpClsg
ICAgMC4xNjU3NjddIEFscmVhZHkgc2V0dXAgdGhlIEdTSSA6MTYKWyAgICAwLjE2NTg1OF0gcGNp
IDAwMDA6MDA6MDQuMDogUENJIElOVCBBIC0+IEdTSSAxNiAobGV2ZWwsIGxvdykgLT4gSVJRIDE2
ClsgICAgMC4xNjU5NjFdIHBjaSAwMDAwOjAwOjA0LjA6IHNldHRpbmcgbGF0ZW5jeSB0aW1lciB0
byA2NApbICAgIDAuMTY2MDY4XSB4ZW46IHJlZ2lzdGVyaW5nIGdzaSAxNiB0cmlnZ2VyaW5nIDAg
cG9sYXJpdHkgMQpbICAgIDAuMTY2MTYxXSB4ZW5fbWFwX3BpcnFfZ3NpOiByZXR1cm5pbmcgaXJx
IDE2IGZvciBnc2kgMTYKWyAgICAwLjE2NjI1M10geGVuOiAtLT4gcGlycT0xNiAtPiBpcnE9MTYg
KGdzaT0xNikKWyAgICAwLjE2NjM0Nl0gQWxyZWFkeSBzZXR1cCB0aGUgR1NJIDoxNgpbICAgIDAu
MTY2NDM3XSBwY2kgMDAwMDowMDowNS4wOiBQQ0kgSU5UIEEgLT4gR1NJIDE2IChsZXZlbCwgbG93
KSAtPiBJUlEgMTYKWyAgICAwLjE2NjU0MF0gcGNpIDAwMDA6MDA6MDUuMDogc2V0dGluZyBsYXRl
bmN5IHRpbWVyIHRvIDY0ClsgICAgMC4xNjY2NTRdIHBjaSAwMDAwOjA1OjAwLjA6IHNldHRpbmcg
bGF0ZW5jeSB0aW1lciB0byA2NApbICAgIDAuMTY2NzY5XSBwY2kgMDAwMDowNTowMC4yOiBzZXR0
aW5nIGxhdGVuY3kgdGltZXIgdG8gNjQKWyAgICAwLjE2Njg3Nl0geGVuOiByZWdpc3RlcmluZyBn
c2kgMTYgdHJpZ2dlcmluZyAwIHBvbGFyaXR5IDEKWyAgICAwLjE2Njk2OF0geGVuX21hcF9waXJx
X2dzaTogcmV0dXJuaW5nIGlycSAxNiBmb3IgZ3NpIDE2ClsgICAgMC4xNjcwNjFdIHhlbjogLS0+
IHBpcnE9MTYgLT4gaXJxPTE2IChnc2k9MTYpClsgICAgMC4xNjcxNTNdIEFscmVhZHkgc2V0dXAg
dGhlIEdTSSA6MTYKWyAgICAwLjE2NzI0NF0gcGNpIDAwMDA6MDA6MDYuMDogUENJIElOVCBBIC0+
IEdTSSAxNiAobGV2ZWwsIGxvdykgLT4gSVJRIDE2ClsgICAgMC4xNjczNDddIHBjaSAwMDAwOjAw
OjA2LjA6IHNldHRpbmcgbGF0ZW5jeSB0aW1lciB0byA2NApbICAgIDAuMTY3NDU5XSBwY2kgMDAw
MDowMDoxZS4wOiBzZXR0aW5nIGxhdGVuY3kgdGltZXIgdG8gNjQKWyAgICAwLjE2NzU2MF0gcGNp
X2J1cyAwMDAwOjAwOiByZXNvdXJjZSAwIFtpbyAgMHgwMDAwLTB4ZmZmZl0KWyAgICAwLjE2NzY1
Nl0gcGNpX2J1cyAwMDAwOjAwOiByZXNvdXJjZSAxIFttZW0gMHgwMDAwMDAwMC0weGZmZmZmZmZm
Zl0KWyAgICAwLjE2Nzc1MV0gcGNpX2J1cyAwMDAwOjAxOiByZXNvdXJjZSAwIFtpbyAgMHhlMDAw
LTB4ZWZmZl0KWyAgICAwLjE2Nzg0NF0gcGNpX2J1cyAwMDAwOjAxOiByZXNvdXJjZSAxIFttZW0g
MHhkZmMwMDAwMC0weGRmZWZmZmZmXQpbICAgIDAuMTY3OTM5XSBwY2lfYnVzIDAwMDA6MDE6IHJl
c291cmNlIDIgW21lbSAweGQ4MDAwMDAwLTB4ZDhmZmZmZmYgNjRiaXQgcHJlZl0KWyAgICAwLjE2
ODA0OV0gcGNpX2J1cyAwMDAwOjAyOiByZXNvdXJjZSAwIFtpbyAgMHhlMDAwLTB4ZWZmZl0KWyAg
ICAwLjE2ODE0M10gcGNpX2J1cyAwMDAwOjAyOiByZXNvdXJjZSAxIFttZW0gMHhkZmQwMDAwMC0w
eGRmZWZmZmZmXQpbICAgIDAuMTY4MjM3XSBwY2lfYnVzIDAwMDA6MDI6IHJlc291cmNlIDIgW21l
bSAweGQ4MDAwMDAwLTB4ZDhmZmZmZmYgNjRiaXQgcHJlZl0KWyAgICAwLjE2ODM0OF0gcGNpX2J1
cyAwMDAwOjA1OiByZXNvdXJjZSAwIFtpbyAgMHhjMDAwLTB4ZGZmZl0KWyAgICAwLjE2ODQ0MV0g
cGNpX2J1cyAwMDAwOjA1OiByZXNvdXJjZSAxIFttZW0gMHhkZjcwMDAwMC0weGRmYmZmZmZmXQpb
ICAgIDAuMTY4NTM2XSBwY2lfYnVzIDAwMDA6MDY6IHJlc291cmNlIDAgW2lvICAweGQwMDAtMHhk
ZmZmXQpbICAgIDAuMTY4NjI5XSBwY2lfYnVzIDAwMDA6MDY6IHJlc291cmNlIDEgW21lbSAweGRm
YTAwMDAwLTB4ZGZiZmZmZmZdClsgICAgMC4xNjg3MjddIHBjaV9idXMgMDAwMDowNzogcmVzb3Vy
Y2UgMCBbaW8gIDB4YzAwMC0weGNmZmZdClsgICAgMC4xNjg4MjBdIHBjaV9idXMgMDAwMDowNzog
cmVzb3VyY2UgMSBbbWVtIDB4ZGY4MDAwMDAtMHhkZjlmZmZmZl0KWyAgICAwLjE2ODkxNV0gcGNp
X2J1cyAwMDAwOjA5OiByZXNvdXJjZSAwIFtpbyAgMHhiMDAwLTB4YmZmZl0KWyAgICAwLjE2OTAw
OV0gcGNpX2J1cyAwMDAwOjA5OiByZXNvdXJjZSAxIFttZW0gMHhkZjUwMDAwMC0weGRmNmZmZmZm
XQpbICAgIDAuMTY5MTAzXSBwY2lfYnVzIDAwMDA6MDk6IHJlc291cmNlIDIgW21lbSAweGM4MDAw
MDAwLTB4ZDdmZmZmZmYgcHJlZl0KWyAgICAwLjE2OTE5OV0gcGNpX2J1cyAwMDAwOjA5OiByZXNv
dXJjZSA0IFtpbyAgMHgwMDAwLTB4ZmZmZl0KWyAgICAwLjE2OTI5Ml0gcGNpX2J1cyAwMDAwOjA5
OiByZXNvdXJjZSA1IFttZW0gMHgwMDAwMDAwMC0weGZmZmZmZmZmZl0KWyAgICAwLjE2OTU5M10g
TkVUOiBSZWdpc3RlcmVkIHByb3RvY29sIGZhbWlseSAyClsgICAgMC4xNjk4NjNdIElQIHJvdXRl
IGNhY2hlIGhhc2ggdGFibGUgZW50cmllczogNDA5NiAob3JkZXI6IDIsIDE2Mzg0IGJ5dGVzKQpb
ICAgIDAuMTcwMzMxXSBUQ1AgZXN0YWJsaXNoZWQgaGFzaCB0YWJsZSBlbnRyaWVzOiAxNjM4NCAo
b3JkZXI6IDUsIDEzMTA3MiBieXRlcykKWyAgICAwLjE3MDUyOV0gVENQIGJpbmQgaGFzaCB0YWJs
ZSBlbnRyaWVzOiAxNjM4NCAob3JkZXI6IDUsIDEzMTA3MiBieXRlcykKWyAgICAwLjE3MDcwMl0g
VENQOiBIYXNoIHRhYmxlcyBjb25maWd1cmVkIChlc3RhYmxpc2hlZCAxNjM4NCBiaW5kIDE2Mzg0
KQpbICAgIDAuMTcwNzk2XSBUQ1AgcmVubyByZWdpc3RlcmVkClsgICAgMC4xNzA4ODhdIFVEUCBo
YXNoIHRhYmxlIGVudHJpZXM6IDI1NiAob3JkZXI6IDEsIDgxOTIgYnl0ZXMpClsgICAgMC4xNzA5
ODhdIFVEUC1MaXRlIGhhc2ggdGFibGUgZW50cmllczogMjU2IChvcmRlcjogMSwgODE5MiBieXRl
cykKWyAgICAwLjE3MTUxMV0gTkVUOiBSZWdpc3RlcmVkIHByb3RvY29sIGZhbWlseSAxClsgICAg
MC4xNzM3NjZdIFBDSTogQ0xTIG1pc21hdGNoICg2NCAhPSA0KSwgdXNpbmcgNjQgYnl0ZXMKWyAg
ICAwLjE3Mzg3MF0gcGNpIDAwMDA6MDk6MGQuMDogQm9vdCB2aWRlbyBkZXZpY2UKWyAgICAwLjE3
NDA1Ml0gVW5wYWNraW5nIGluaXRyYW1mcy4uLgpbICAgIDAuMTgxNjMxXSBGcmVlaW5nIGluaXRy
ZCBtZW1vcnk6IDM4MDRrIGZyZWVkClsgICAgMC4xODQ3NTZdIG1pY3JvY29kZTogQ1BVMCBzaWc9
MHhmNDMsIHBmPTB4MSwgcmV2aXNpb249MHg1ClsgICAgMC4xODQ4NzddIG1pY3JvY29kZTogQ1BV
MSBzaWc9MHhmNDMsIHBmPTB4MSwgcmV2aXNpb249MHg1ClsgICAgMC4xODUwMjBdIG1pY3JvY29k
ZTogQ1BVMiBzaWc9MHhmNDMsIHBmPTB4MSwgcmV2aXNpb249MHg1ClsgICAgMC4xODUxNTNdIG1p
Y3JvY29kZTogQ1BVMyBzaWc9MHhmNDMsIHBmPTB4MSwgcmV2aXNpb249MHg1ClsgICAgMC4xODUy
OTBdIG1pY3JvY29kZTogTWljcm9jb2RlIFVwZGF0ZSBEcml2ZXI6IHYyLjAwIDx0aWdyYW5AYWl2
YXppYW4uZnNuZXQuY28udWs+LCBQZXRlciBPcnViYQpbICAgIDAuMTg4MTUyXSBtc2dtbmkgaGFz
IGJlZW4gc2V0IHRvIDc1OQpbICAgIDAuMTg4ODcwXSBCbG9jayBsYXllciBTQ1NJIGdlbmVyaWMg
KGJzZykgZHJpdmVyIHZlcnNpb24gMC40IGxvYWRlZCAobWFqb3IgMjU0KQpbICAgIDAuMTg4OTg4
XSBpbyBzY2hlZHVsZXIgbm9vcCByZWdpc3RlcmVkClsgICAgMC4xODkwNzldIGlvIHNjaGVkdWxl
ciBkZWFkbGluZSByZWdpc3RlcmVkClsgICAgMC4xODkyMzBdIGlvIHNjaGVkdWxlciBjZnEgcmVn
aXN0ZXJlZCAoZGVmYXVsdCkKWyAgICAwLjE5MDE2MF0gQUNQSTogYWNwaV9pZGxlIHJlZ2lzdGVy
ZWQgd2l0aCBjcHVpZGxlClsgICAgMC4xOTc4NDBdIEV2ZW50LWNoYW5uZWwgZGV2aWNlIGluc3Rh
bGxlZC4KWyAgICAwLjE5ODM4NV0gU2VyaWFsOiA4MjUwLzE2NTUwIGRyaXZlciwgNCBwb3J0cywg
SVJRIHNoYXJpbmcgZW5hYmxlZApbICAgIDAuNTAwNTQwXSBzZXJpYWw4MjUwOiB0dHlTMCBhdCBJ
L08gMHgzZjggKGlycSA9IDQpIGlzIGEgMTY1NTBBClsgICAgMS4wODAwNTldIDAwOjA4OiB0dHlT
MCBhdCBJL08gMHgzZjggKGlycSA9IDQpIGlzIGEgMTY1NTBBClsgICAgMS4yMzAyMjVdIHhlbjog
cmVnaXN0ZXJpbmcgZ3NpIDIxIHRyaWdnZXJpbmcgMCBwb2xhcml0eSAxClsgICAgMS4yMzAzMjVd
IHhlbjogLS0+IHBpcnE9MjEgLT4gaXJxPTIxIChnc2k9MjEpClsgICAgMS4yMzA0MjZdIHNlcmlh
bCAwMDAwOjA5OjA1LjE6IFBDSSBJTlQgQiAtPiBHU0kgMjEgKGxldmVsLCBsb3cpIC0+IElSUSAy
MQpbICAgIDEuMjQwMDU5XSAwMDAwOjA5OjA1LjE6IHR0eVMxIGF0IEkvTyAweGJjODAgKGlycSA9
IDIxKSBpcyBhIDE2NTUwQQpbICAgIDEuMzkwMjEyXSBSZWFsIFRpbWUgQ2xvY2sgRHJpdmVyIHYx
LjEyYgpbICAgIDEuMzkwNDUxXSBpbnRlbF9ybmc6IEZXSCBub3QgZGV0ZWN0ZWQKWyAgICAxLjM5
MTk3MF0gaTgwNDI6IFBOUDogUFMvMiBDb250cm9sbGVyIFtQTlAwMzAzOktCRCxQTlAwZjEzOk1P
VV0gYXQgMHg2MCwweDY0IGlycSAxLDEyClsgICAgMS4zOTQ3ODVdIHNlcmlvOiBpODA0MiBLQkQg
cG9ydCBhdCAweDYwLDB4NjQgaXJxIDEKWyAgICAxLjM5NDg4N10gc2VyaW86IGk4MDQyIEFVWCBw
b3J0IGF0IDB4NjAsMHg2NCBpcnEgMTIKWyAgICAxLjM5NTA3M10gbW91c2VkZXY6IFBTLzIgbW91
c2UgZGV2aWNlIGNvbW1vbiBmb3IgYWxsIG1pY2UKWyAgICAxLjM5NTIwN10gY3B1aWRsZTogdXNp
bmcgZ292ZXJub3IgbGFkZGVyClsgICAgMS4zOTUyOThdIGNwdWlkbGU6IHVzaW5nIGdvdmVybm9y
IG1lbnUKWyAgICAxLjM5NTgxMl0gVENQIGN1YmljIHJlZ2lzdGVyZWQKWyAgICAxLjM5NTkwNF0g
TkVUOiBSZWdpc3RlcmVkIHByb3RvY29sIGZhbWlseSAxNwpbICAgIDEuMzk2MDA2XSBVc2luZyBJ
UEkgTm8tU2hvcnRjdXQgbW9kZQpbICAgIDEuMzk3NjAzXSBGcmVlaW5nIHVudXNlZCBrZXJuZWwg
bWVtb3J5OiAzNzJrIGZyZWVkClsgICAgMS40MDUzOTBdIG5hc2gtaG90cGx1ZyAoMzgpOiAvcHJv
Yy8zOC9vb21fYWRqIGlzIGRlcHJlY2F0ZWQsIHBsZWFzZSB1c2UgL3Byb2MvMzgvb29tX3Njb3Jl
X2FkaiBpbnN0ZWFkLgpbICAgIDEuNDQ5NzEyXSBpbnB1dDogQVQgVHJhbnNsYXRlZCBTZXQgMiBr
ZXlib2FyZCBhcyAvZGV2aWNlcy9wbGF0Zm9ybS9pODA0Mi9zZXJpbzAvaW5wdXQvaW5wdXQwClsg
ICAgMS42NzM3OTRdIFNDU0kgc3Vic3lzdGVtIGluaXRpYWxpemVkClsgICAgMS42ODIwNDBdIEZ1
c2lvbiBNUFQgYmFzZSBkcml2ZXIgMy4wNC4xOQpbICAgIDEuNjgyMTMzXSBDb3B5cmlnaHQgKGMp
IDE5OTktMjAwOCBMU0kgQ29ycG9yYXRpb24KWyAgICAxLjY4NjkyNl0gRnVzaW9uIE1QVCBTUEkg
SG9zdCBkcml2ZXIgMy4wNC4xOQpbICAgIDEuNjg3MDY0XSB4ZW46IHJlZ2lzdGVyaW5nIGdzaSAz
NCB0cmlnZ2VyaW5nIDAgcG9sYXJpdHkgMQpbICAgIDEuNjg3MTY5XSB4ZW46IC0tPiBwaXJxPTM0
IC0+IGlycT0zNCAoZ3NpPTM0KQpbICAgIDEuNjg3MjczXSBtcHRzcGkgMDAwMDowMjowNS4wOiBQ
Q0kgSU5UIEEgLT4gR1NJIDM0IChsZXZlbCwgbG93KSAtPiBJUlEgMzQKWyAgICAxLjY4NzM4MF0g
TlRfREJHOiB4ZW5faW9fdGxiX2VuZDogZGMzMmNmMDAsIGNvbnZlcnRlZCB0byAncGh5cyc6IDFj
MzJjZjAwLCB0aGVuICdidXMnOiAxMjBmZGZlZmYgZm9yIGFuc3dlciAxLgpbICAgIDEuNjg3NDkz
XSBOVF9EQkc6IGRtYV9zdXBwb3J0ZWQgcmV0dXJuaW5nIDEKWyAgICAxLjY4NzU4NV0gTlRfREJH
OiB4ZW5faW9fdGxiX2VuZDogZGMzMmNmMDAsIGNvbnZlcnRlZCB0byAncGh5cyc6IDFjMzJjZjAw
LCB0aGVuICdidXMnOiAxMjBmZGZlZmYgZm9yIGFuc3dlciAxLgpbICAgIDEuNjg3Njk3XSBOVF9E
Qkc6IGRtYV9zdXBwb3J0ZWQgcmV0dXJuaW5nIDEKWyAgICAxLjY4ODA2N10gbXB0YmFzZTogaW9j
MDogSW5pdGlhdGluZyBicmluZ3VwClsgICAgMi45MDAwODVdIGlvYzA6IExTSTUzQzEwMzAgQzA6
IENhcGFiaWxpdGllcz17SW5pdGlhdG9yLFRhcmdldH0KWyAgICA0LjU3ODk4NF0gc2NzaTAgOiBp
b2MwOiBMU0k1M0MxMDMwIEMwLCBGd1Jldj0wMTAzMjMwMGgsIFBvcnRzPTEsIE1heFE9MjU1LCBJ
UlE9MzQKWyAgICA1LjM3ODgzOF0gc2NzaSAwOjA6MDowOiBEaXJlY3QtQWNjZXNzICAgICBNQVhU
T1IgICBBVExBUzEwSzRfNzNTQ0EgIERGTTAgUFE6IDAgQU5TSTogMwpbICAgIDUuMzc4OTcyXSBz
Y3NpIHRhcmdldDA6MDowOiBCZWdpbm5pbmcgRG9tYWluIFZhbGlkYXRpb24KWyAgICA1LjM5MTg2
NV0gc2NzaSB0YXJnZXQwOjA6MDogRW5kaW5nIERvbWFpbiBWYWxpZGF0aW9uClsgICAgNS4zOTIw
ODBdIHNjc2kgdGFyZ2V0MDowOjA6IEZBU1QtMTYwIFdJREUgU0NTSSAzMjAuMCBNQi9zIERUIElV
IFJUSSAoNi4yNSBucywgb2Zmc2V0IDEyNykKWyAgICA1LjM5MzI1N10gc2QgMDowOjA6MDogW3Nk
YV0gMTQzMzc0NjUwIDUxMi1ieXRlIGxvZ2ljYWwgYmxvY2tzOiAoNzMuNCBHQi82OC4zIEdpQikK
WyAgICA1LjM5NTU5NF0gc2NzaSAwOjA6MTowOiBEaXJlY3QtQWNjZXNzICAgICBNQVhUT1IgICBB
VExBUzEwSzVfNzNTQ0EgIEpUMDAgUFE6IDAgQU5TSTogMwpbICAgIDUuMzk1NzUyXSBzY3NpIHRh
cmdldDA6MDoxOiBCZWdpbm5pbmcgRG9tYWluIFZhbGlkYXRpb24KWyAgICA1LjM5NTc4N10gc2Qg
MDowOjA6MDogW3NkYV0gV3JpdGUgUHJvdGVjdCBpcyBvZmYKWyAgICA1LjM5NTgwMl0gc2QgMDow
OjA6MDogW3NkYV0gTW9kZSBTZW5zZTogZWQgMDAgMTAgMDgKWyAgICA1LjM5NzcyM10gc2QgMDow
OjA6MDogW3NkYV0gV3JpdGUgY2FjaGU6IGRpc2FibGVkLCByZWFkIGNhY2hlOiBlbmFibGVkLCBz
dXBwb3J0cyBEUE8gYW5kIEZVQQpbICAgIDUuNDEwOTYxXSBzY3NpIHRhcmdldDA6MDoxOiBFbmRp
bmcgRG9tYWluIFZhbGlkYXRpb24KWyAgICA1LjQxMTE3NV0gc2NzaSB0YXJnZXQwOjA6MTogRkFT
VC0xNjAgV0lERSBTQ1NJIDMyMC4wIE1CL3MgRFQgSVUgUlRJICg2LjI1IG5zLCBvZmZzZXQgMTI3
KQpbICAgIDUuNDEyMzM3XSBzZCAwOjA6MTowOiBbc2RiXSAxNDMzNzQ2NTAgNTEyLWJ5dGUgbG9n
aWNhbCBibG9ja3M6ICg3My40IEdCLzY4LjMgR2lCKQpbICAgIDUuOTEyOTM1XSBzZCAwOjA6MTow
OiBbc2RiXSBXcml0ZSBQcm90ZWN0IGlzIG9mZgpbICAgIDUuOTEyOTkwXSAgc2RhOiBzZGExIHNk
YTIgc2RhMyBzZGE0IDwgc2RhNSA+ClsgICAgNS45MTMxNjddIHNkIDA6MDoxOjA6IFtzZGJdIE1v
ZGUgU2Vuc2U6IGJmIDAwIDEwIDA4ClsgICAgNi40MTcwNjhdIHNkIDA6MDoxOjA6IFtzZGJdIFdy
aXRlIGNhY2hlOiBkaXNhYmxlZCwgcmVhZCBjYWNoZTogZW5hYmxlZCwgc3VwcG9ydHMgRFBPIGFu
ZCBGVUEKWyAgICA2LjQyMjE1OV0gc2NzaSAwOjA6NjowOiBQcm9jZXNzb3IgICAgICAgICBQRS9Q
ViAgICAxeDIgU0NTSSBCUCAgICAgIDEuMCAgUFE6IDAgQU5TSTogMgpbICAgIDYuNDIyMzEzXSBz
Y3NpIHRhcmdldDA6MDo2OiBCZWdpbm5pbmcgRG9tYWluIFZhbGlkYXRpb24KWyAgICA2LjQyNzU2
M10gc2QgMDowOjA6MDogW3NkYV0gQXR0YWNoZWQgU0NTSSBkaXNrClsgICAgNi40NDI4OTZdIHNj
c2kgdGFyZ2V0MDowOjY6IEVuZGluZyBEb21haW4gVmFsaWRhdGlvbgpbICAgIDYuNDQzMTQ2XSBz
Y3NpIHRhcmdldDA6MDo2OiBhc3luY2hyb25vdXMKWyAgICA2LjQ0ODA3MF0gIHNkYjogc2RiMQpb
ICAgIDcuNDU0OTE1XSBzZCAwOjA6MTowOiBbc2RiXSBBdHRhY2hlZCBTQ1NJIGRpc2sKWyAgICA4
LjQ2MjE0OF0gRnVzaW9uIE1QVCBTQVMgSG9zdCBkcml2ZXIgMy4wNC4xOQpbICAgIDguNDY5ODE1
XSBsaWJhdGEgdmVyc2lvbiAzLjAwIGxvYWRlZC4KWyAgICA4LjQ3MjU1Nl0gYXRhX3BpaXggMDAw
MDowMDoxZi4xOiB2ZXJzaW9uIDIuMTMKWyAgICA4LjQ3MjY2N10gYXRhX3BpaXggMDAwMDowMDox
Zi4xOiBlbmFibGluZyBkZXZpY2UgKDAwMDUgLT4gMDAwNykKWyAgICA4LjQ3Mjc2OV0gYXRhX3Bp
aXggMDAwMDowMDoxZi4xOiBjYW4ndCBkZXJpdmUgcm91dGluZyBmb3IgUENJIElOVCBBClsgICAg
OC40NzI5MjFdIE5UX0RCRzogeGVuX2lvX3RsYl9lbmQ6IGRjMzJjZjAwLCBjb252ZXJ0ZWQgdG8g
J3BoeXMnOiAxYzMyY2YwMCwgdGhlbiAnYnVzJzogMTIwZmRmZWZmIGZvciBhbnN3ZXIgMS4KWyAg
ICA4LjQ3MzAzNV0gTlRfREJHOiBkbWFfc3VwcG9ydGVkIHJldHVybmluZyAwClsgICAgOC40NzMx
MjZdIGF0YV9waWl4IDAwMDA6MDA6MWYuMTogQk1ETUE6IGZhaWxlZCB0byBzZXQgZG1hIG1hc2ss
IGZhbGxpbmcgYmFjayB0byBQSU8KWyAgICA4LjQ3MzI3M10gYXRhX3BpaXggMDAwMDowMDoxZi4x
OiBzZXR0aW5nIGxhdGVuY3kgdGltZXIgdG8gNjQKWyAgICA4LjQ3Mzk3M10gc2NzaTEgOiBhdGFf
cGlpeApbICAgIDguNDc0MjUwXSBzY3NpMiA6IGF0YV9waWl4ClsgICAgOC40NzQ0MjddIGF0YTE6
IFBBVEEgbWF4IFBJTzQgY21kIDB4MWYwIGN0bCAweDNmNiBibWRtYSAweGZjMDAgaXJxIDE0Clsg
ICAgOC40NzQ1MjNdIGF0YTI6IFBBVEEgbWF4IFBJTzQgY21kIDB4MTcwIGN0bCAweDM3NiBibWRt
YSAweGZjMDggaXJxIDE1ClsgICAgOC42NTA0NTNdIGF0YTEuMDA6IEFUQVBJOiBQSElMSVBTIERW
RC1ST00gU0RSMDg5LCBURDM2LCBtYXggVURNQS8zMwpbICAgIDguNjcwMzMzXSBhdGExLjAwOiBj
b25maWd1cmVkIGZvciBQSU80ClsgICAgOC42NzE2ODddIHNjc2kgMTowOjA6MDogQ0QtUk9NICAg
ICAgICAgICAgUEhJTElQUyAgRFZELVJPTSBTRFIwODkgICBURDM2IFBROiAwIEFOU0k6IDUKWyAg
IDE5Ljg5MDAxM10gRVhUMy1mczogYmFycmllcnMgbm90IGVuYWJsZWQKWyAgIDE5LjkwMzc0NV0g
a2pvdXJuYWxkIHN0YXJ0aW5nLiAgQ29tbWl0IGludGVydmFsIDUgc2Vjb25kcwpbICAgMTkuOTAz
OTAxXSBFWFQzLWZzIChzZGEzKTogbW91bnRlZCBmaWxlc3lzdGVtIHdpdGggb3JkZXJlZCBkYXRh
IG1vZGUKWyAgIDIxLjY4NzQyN10gaW5wdXQ6IFBDIFNwZWFrZXIgYXMgL2RldmljZXMvcGxhdGZv
cm0vcGNzcGtyL2lucHV0L2lucHV0MQpbICAgMjEuODYxMjUwXSBpVENPX3ZlbmRvcl9zdXBwb3J0
OiB2ZW5kb3Itc3VwcG9ydD0wClsgICAyMS44NjQ1OTVdIGlUQ09fd2R0OiBJbnRlbCBUQ08gV2F0
Y2hEb2cgVGltZXIgRHJpdmVyIHYxLjA2ClsgICAyMS44NjQ3OTRdIGlUQ09fd2R0OiBGb3VuZCBh
IElDSDUgb3IgSUNINVIgVENPIGRldmljZSAoVmVyc2lvbj0xLCBUQ09CQVNFPTB4MDg2MCkKWyAg
IDIxLjg2NDk2Nl0gaVRDT193ZHQ6IGluaXRpYWxpemVkLiBoZWFydGJlYXQ9MzAgc2VjIChub3dh
eW91dD0xKQpbICAgMjEuODY1NjUyXSB4ZW46IHJlZ2lzdGVyaW5nIGdzaSAyMyB0cmlnZ2VyaW5n
IDAgcG9sYXJpdHkgMQpbICAgMjEuODY1Njc2XSB4ZW46IC0tPiBwaXJxPTIzIC0+IGlycT0yMyAo
Z3NpPTIzKQpbICAgMjEuODY1NzAwXSBwYXRhX2FjcGkgMDAwMDowOTowNi4wOiBQQ0kgSU5UIEEg
LT4gR1NJIDIzIChsZXZlbCwgbG93KSAtPiBJUlEgMjMKWyAgIDIxLjg2NTc3OF0gTlRfREJHOiB4
ZW5faW9fdGxiX2VuZDogZGMzMmNmMDAsIGNvbnZlcnRlZCB0byAncGh5cyc6IDFjMzJjZjAwLCB0
aGVuICdidXMnOiAxMjBmZGZlZmYgZm9yIGFuc3dlciAxLgpbICAgMjEuODY1Nzg3XSBOVF9EQkc6
IGRtYV9zdXBwb3J0ZWQgcmV0dXJuaW5nIDAKWyAgIDIxLjg2NTc5Nl0gcGF0YV9hY3BpIDAwMDA6
MDk6MDYuMDogQk1ETUE6IGZhaWxlZCB0byBzZXQgZG1hIG1hc2ssIGZhbGxpbmcgYmFjayB0byBQ
SU8KWyAgIDIxLjg2NTg1OV0gcGF0YV9hY3BpIDAwMDA6MDk6MDYuMDogUENJIElOVCBBIGRpc2Fi
bGVkClsgICAyMS44ODg5ODFdIHBhdGFfc2lsNjgwIDAwMDA6MDk6MDYuMDogdmVyc2lvbiAwLjQu
OQpbICAgMjEuODg5MDExXSB4ZW46IHJlZ2lzdGVyaW5nIGdzaSAyMyB0cmlnZ2VyaW5nIDAgcG9s
YXJpdHkgMQpbICAgMjEuODg5MDIwXSB4ZW5fbWFwX3BpcnFfZ3NpOiByZXR1cm5pbmcgaXJxIDIz
IGZvciBnc2kgMjMKWyAgIDIxLjg4OTAyNl0geGVuOiAtLT4gcGlycT0yMyAtPiBpcnE9MjMgKGdz
aT0yMykKWyAgIDIxLjg4OTAzNl0gQWxyZWFkeSBzZXR1cCB0aGUgR1NJIDoyMwpbICAgMjEuODg5
MDQ0XSBwYXRhX3NpbDY4MCAwMDAwOjA5OjA2LjA6IFBDSSBJTlQgQSAtPiBHU0kgMjMgKGxldmVs
LCBsb3cpIC0+IElSUSAyMwpbICAgMjEuODg5MTA4XSBzaWw2ODA6IDEzM01IeiBjbG9jay4KWyAg
IDIxLjg4OTE2OV0gTlRfREJHOiB4ZW5faW9fdGxiX2VuZDogZGMzMmNmMDAsIGNvbnZlcnRlZCB0
byAncGh5cyc6IDFjMzJjZjAwLCB0aGVuICdidXMnOiAxMjBmZGZlZmYgZm9yIGFuc3dlciAxLgpb
ICAgMjEuODg5MTc2XSBOVF9EQkc6IGRtYV9zdXBwb3J0ZWQgcmV0dXJuaW5nIDAKWyAgIDIxLjg4
OTE4Ml0gcGF0YV9zaWw2ODAgMDAwMDowOTowNi4wOiBCTURNQTogZmFpbGVkIHRvIHNldCBkbWEg
bWFzaywgZmFsbGluZyBiYWNrIHRvIFBJTwpbICAgMjEuODg5ODExXSBzY3NpMyA6IHBhdGFfc2ls
NjgwClsgICAyMS44OTAwMDhdIHNjc2k0IDogcGF0YV9zaWw2ODAKWyAgIDIxLjg5MDE2Nl0gYXRh
MzogUEFUQSBtYXggUElPNCBjbWQgMHhiY2YwIGN0bCAweGJjZTQgYm1kbWEgMHhiYzcwIGlycSAy
MwpbICAgMjEuODkwMTc2XSBhdGE0OiBQQVRBIG1heCBQSU80IGNtZCAweGJjZDggY3RsIDB4YmNk
MCBibWRtYSAweGJjNzggaXJxIDIzClsgICAyMi4wOTE1MjVdIGF0YTMuMDA6IEFUQVBJOiBWSVJU
VUFMRkxPUFBZIERSSVZFICAgICAgICAgICAgICAgRmxvcHB5LCAsIG1heCBQSU8zClsgICAyMi4w
OTE1NDJdIGF0YTMuMDE6IEFUQVBJOiBWSVJUVUFMQ0RST00gRFJJVkUsICwgbWF4IFBJTzMKWyAg
IDIyLjExMDUxM10gYXRhMy4wMDogY29uZmlndXJlZCBmb3IgUElPMwpbICAgMjIuMTMwNDY4XSBh
dGEzLjAxOiBjb25maWd1cmVkIGZvciBQSU8zClsgICAyMi4xNjU3MzhdIHNjc2kgMzowOjA6MDog
RGlyZWN0LUFjY2VzcyAgICAgREVMTCAgICAgICBWU0YgICAgICAgICAgICAwMTIzIFBROiAwIEFO
U0k6IDUKWyAgIDIyLjE3NTczMV0gc2NzaSAzOjA6MTowOiBDRC1ST00gICAgICAgICAgICBERUxM
ICAgICAgIFZDRCAgICAgICAgICAgIDAxMzMgUFE6IDAgQU5TSTogNQpbICAgMjIuMjEzNDM3XSBG
REMgMCBpcyBhIE5hdGlvbmFsIFNlbWljb25kdWN0b3IgUEM4NzMwNgpbICAgMjIuMjE1OTU1XSBz
ZCAzOjA6MDowOiBbc2RjXSBBdHRhY2hlZCBTQ1NJIHJlbW92YWJsZSBkaXNrClsgICAyMi4zODIx
MTRdIGlucHV0OiBQb3dlciBCdXR0b24gYXMgL2RldmljZXMvTE5YU1lTVE06MDAvTE5YUFdSQk46
MDAvaW5wdXQvaW5wdXQyClsgICAyMi4zODIxMzZdIEFDUEk6IFBvd2VyIEJ1dHRvbiBbUFdSRl0K
WyAgIDIyLjUzOTEzMV0gZTEwMDA6IEludGVsKFIpIFBSTy8xMDAwIE5ldHdvcmsgRHJpdmVyIC0g
dmVyc2lvbiA3LjMuMjEtazgtTkFQSQpbICAgMjIuNTM5MTQxXSBlMTAwMDogQ29weXJpZ2h0IChj
KSAxOTk5LTIwMDYgSW50ZWwgQ29ycG9yYXRpb24uClsgICAyMi41MzkyMTJdIHhlbjogcmVnaXN0
ZXJpbmcgZ3NpIDY0IHRyaWdnZXJpbmcgMCBwb2xhcml0eSAxClsgICAyMi41MzkyMzRdIHhlbjog
LS0+IHBpcnE9NjQgLT4gaXJxPTY0IChnc2k9NjQpClsgICAyMi41MzkyNTZdIGUxMDAwIDAwMDA6
MDY6MDcuMDogUENJIElOVCBBIC0+IEdTSSA2NCAobGV2ZWwsIGxvdykgLT4gSVJRIDY0ClsgICAy
Mi41Mzk2MTRdIE5UX0RCRzogZTEwMDBfZ2V0X2J1c19pbmZvOmJ1c19pbmZvIHN0YXR1czogNTIw
OTkKWyAgIDIyLjUzOTYyM10gTlRfREJHOiBody0+YnVzX3R5cGU6MSwgZTEwMDBfYnVzX3R5cGVf
cGNpeDogMgpbICAgMjIuNTM5NjM0XSBOVF9EQkc6IHhlbl9pb190bGJfZW5kOiBkYzMyY2YwMCwg
Y29udmVydGVkIHRvICdwaHlzJzogMWMzMmNmMDAsIHRoZW4gJ2J1cyc6IDEyMGZkZmVmZiBmb3Ig
YW5zd2VyIDEuClsgICAyMi41Mzk2NDRdIE5UX0RCRzogZG1hX3N1cHBvcnRlZCByZXR1cm5pbmcg
MApbICAgMjIuNTM5NjUwXSBlMTAwMDogTm8gdXNhYmxlIERNQSBjb25maWcsIGFib3J0aW5nClsg
ICAyMi41Mzk4NjNdIGUxMDAwIDAwMDA6MDY6MDcuMDogUENJIElOVCBBIGRpc2FibGVkClsgICAy
Mi41Mzk4ODBdIGUxMDAwOiBwcm9iZSBvZiAwMDAwOjA2OjA3LjAgZmFpbGVkIHdpdGggZXJyb3Ig
LTUKWyAgIDIyLjUzOTkxMV0geGVuOiByZWdpc3RlcmluZyBnc2kgNjUgdHJpZ2dlcmluZyAwIHBv
bGFyaXR5IDEKWyAgIDIyLjUzOTkyN10geGVuOiAtLT4gcGlycT02NSAtPiBpcnE9NjUgKGdzaT02
NSkKWyAgIDIyLjUzOTk0Ml0gZTEwMDAgMDAwMDowNzowOC4wOiBQQ0kgSU5UIEEgLT4gR1NJIDY1
IChsZXZlbCwgbG93KSAtPiBJUlEgNjUKWyAgIDIyLjU0MDQzMV0gTlRfREJHOiBlMTAwMF9nZXRf
YnVzX2luZm86YnVzX2luZm8gc3RhdHVzOiA1MTk2OQpbICAgMjIuNTQwNDQxXSBOVF9EQkc6IGh3
LT5idXNfdHlwZToxLCBlMTAwMF9idXNfdHlwZV9wY2l4OiAyClsgICAyMi41NDA0NTFdIE5UX0RC
RzogeGVuX2lvX3RsYl9lbmQ6IGRjMzJjZjAwLCBjb252ZXJ0ZWQgdG8gJ3BoeXMnOiAxYzMyY2Yw
MCwgdGhlbiAnYnVzJzogMTIwZmRmZWZmIGZvciBhbnN3ZXIgMS4KWyAgIDIyLjU0MDQ2MF0gTlRf
REJHOiBkbWFfc3VwcG9ydGVkIHJldHVybmluZyAwClsgICAyMi41NDA0NjddIGUxMDAwOiBObyB1
c2FibGUgRE1BIGNvbmZpZywgYWJvcnRpbmcKWyAgIDIyLjU0MDY5MV0gZTEwMDAgMDAwMDowNzow
OC4wOiBQQ0kgSU5UIEEgZGlzYWJsZWQKWyAgIDIyLjU0MDcxMV0gZTEwMDA6IHByb2JlIG9mIDAw
MDA6MDc6MDguMCBmYWlsZWQgd2l0aCBlcnJvciAtNQpbICAgMzEuODExMzc0XSBzcjA6IHNjc2kz
LW1tYyBkcml2ZTogMjR4LzI0eCBjZC9ydyB4YS9mb3JtMiBjZGRhIHRyYXkKWyAgIDMxLjgxMTM4
N10gY2Ryb206IFVuaWZvcm0gQ0QtUk9NIGRyaXZlciBSZXZpc2lvbjogMy4yMApbICAgMzEuODEx
NjE1XSBzciAxOjA6MDowOiBBdHRhY2hlZCBzY3NpIENELVJPTSBzcjAKWyAgIDMxLjg0NjM1NF0g
c3IxOiBzY3NpLTEgZHJpdmUKWyAgIDMxLjg0NjYyN10gc3IgMzowOjE6MDogQXR0YWNoZWQgc2Nz
aSBDRC1ST00gc3IxClsgICAzMi4xMjc2NzddIHNkIDA6MDowOjA6IEF0dGFjaGVkIHNjc2kgZ2Vu
ZXJpYyBzZzAgdHlwZSAwClsgICAzMi4xMjc3ODhdIHNkIDA6MDoxOjA6IEF0dGFjaGVkIHNjc2kg
Z2VuZXJpYyBzZzEgdHlwZSAwClsgICAzMi4xMjc4ODhdIHNjc2kgMDowOjY6MDogQXR0YWNoZWQg
c2NzaSBnZW5lcmljIHNnMiB0eXBlIDMKWyAgIDMyLjEyNzk4Nl0gc3IgMTowOjA6MDogQXR0YWNo
ZWQgc2NzaSBnZW5lcmljIHNnMyB0eXBlIDUKWyAgIDMyLjEyODA4Nl0gc2QgMzowOjA6MDogQXR0
YWNoZWQgc2NzaSBnZW5lcmljIHNnNCB0eXBlIDAKWyAgIDMyLjEyODE4OF0gc3IgMzowOjE6MDog
QXR0YWNoZWQgc2NzaSBnZW5lcmljIHNnNSB0eXBlIDUKWyAgIDMzLjcyNjc4NV0gTm9uLXZvbGF0
aWxlIG1lbW9yeSBkcml2ZXIgdjEuMwpbICAgMzQuMjcwNDc0XSBtZDogQXV0b2RldGVjdGluZyBS
QUlEIGFycmF5cy4KWyAgIDM0LjI3MDQ4NV0gbWQ6IFNjYW5uZWQgMCBhbmQgYWRkZWQgMCBkZXZp
Y2VzLgpbICAgMzQuMjcwNDkyXSBtZDogYXV0b3J1biAuLi4KWyAgIDM0LjI3MDQ5OF0gbWQ6IC4u
LiBhdXRvcnVuIERPTkUuClsgICAzNC4zMjg0MzVdIGRldmljZS1tYXBwZXI6IGlvY3RsOiA0LjIw
LjAtaW9jdGwgKDIwMTEtMDItMDIpIGluaXRpYWxpc2VkOiBkbS1kZXZlbEByZWRoYXQuY29tClsg
ICAzNC4zODE2OTZdIGRldmljZS1tYXBwZXI6IG11bHRpcGF0aDogdmVyc2lvbiAxLjMuMCBsb2Fk
ZWQKWyAgIDM0LjY1NjExOV0gbG9vcDogbW9kdWxlIGxvYWRlZApbICAgMzUuMzE4MDUwXSBFWFQz
LWZzIChzZGEzKTogdXNpbmcgaW50ZXJuYWwgam91cm5hbApbICAgMzUuMzc5MDM2XSBFWFQzLWZz
OiBiYXJyaWVycyBub3QgZW5hYmxlZApbICAgMzUuMzc5MzkxXSBram91cm5hbGQgc3RhcnRpbmcu
ICBDb21taXQgaW50ZXJ2YWwgNSBzZWNvbmRzClsgICAzNS4zODY0OTldIEVYVDMtZnMgKHNkYTIp
OiB1c2luZyBpbnRlcm5hbCBqb3VybmFsClsgICAzNS4zODY1MDldIEVYVDMtZnMgKHNkYTIpOiBt
b3VudGVkIGZpbGVzeXN0ZW0gd2l0aCBvcmRlcmVkIGRhdGEgbW9kZQpbICAgMzUuNDAxOTk0XSBF
WFQzLWZzOiBiYXJyaWVycyBub3QgZW5hYmxlZApbICAgMzUuNDAyMzIyXSBram91cm5hbGQgc3Rh
cnRpbmcuICBDb21taXQgaW50ZXJ2YWwgNSBzZWNvbmRzClsgICAzNS40MDg0NTZdIEVYVDMtZnMg
KGRtLTApOiB1c2luZyBpbnRlcm5hbCBqb3VybmFsClsgICAzNS40MDg0NjVdIEVYVDMtZnMgKGRt
LTApOiBtb3VudGVkIGZpbGVzeXN0ZW0gd2l0aCBvcmRlcmVkIGRhdGEgbW9kZQo=

--_002_3E243B26F475504B9BB0BCC9728B0DA629E17AEAUSILMS110Acacom_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--_002_3E243B26F475504B9BB0BCC9728B0DA629E17AEAUSILMS110Acacom_--


From xen-devel-bounces@lists.xensource.com Mon Dec 12 22:31:47 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 22: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.xensource.com>)
	id 1RaEP1-0004cR-Sq; Mon, 12 Dec 2011 22:31:19 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <thunderbird2k@gmail.com>) id 1RaEP0-0004cM-Cg
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 22:31:18 +0000
X-Env-Sender: thunderbird2k@gmail.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1323728985!47574257!1
X-Originating-IP: [209.85.161.171]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24988 invoked from network); 12 Dec 2011 22:29:46 -0000
Received: from mail-gx0-f171.google.com (HELO mail-gx0-f171.google.com)
	(209.85.161.171)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Dec 2011 22:29:46 -0000
Received: by ggnh4 with SMTP id h4so55053813ggn.30
	for <xen-devel@lists.xensource.com>;
	Mon, 12 Dec 2011 14:30:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	bh=GDNM4sKYaMh95AmvcuaEDBZI/eNNkUl57sh+hDwpF+8=;
	b=QHfDp+nkQGyKiTTyPpZraC71AKtv3LDLJILPTdzS95W/ufpWGxxT1mvQc1H+vEk5BB
	z8CjRI5NLxxAWmSLyYpOYLaW/QfAurITwZuDTfB0D3HpSQwqeKTfrUm7CtXXCHzEuFZg
	IirsnsMq4VltrlrrP4vkMwSKTB4WItaHt+Yoc=
MIME-Version: 1.0
Received: by 10.236.79.38 with SMTP id h26mr29549973yhe.39.1323729025053; Mon,
	12 Dec 2011 14:30:25 -0800 (PST)
Received: by 10.100.48.10 with HTTP; Mon, 12 Dec 2011 14:30:24 -0800 (PST)
In-Reply-To: <CAEc3jaCJ6wP27Ffm0wpOggWMgqcSNJiGxhtkszq6jgRD1nrZLg@mail.gmail.com>
References: <CAEc3jaAa7y8C2NNBn1=L3AhS0uuYFP6ze8o1cZ9yG2VYHx6qMA@mail.gmail.com>
	<4ED5215D.1010403@hfp.de>
	<20111129230212.GA23958@andromeda.dapyr.net>
	<CAEc3jaAO0JhtOt6phQHwtE_A+NF7uGHGZ8uJv3BirEYybfVceg@mail.gmail.com>
	<CAEc3jaACffpr9D1Hq_012vHAGhPLEfvsZjh7YyJ=Q-3FdtHS0Q@mail.gmail.com>
	<CAPbh3rtOQ1HTPReqYcpE3vzk+-na0MTLLHZD15=Fg4yxB+ypaA@mail.gmail.com>
	<CAEc3jaBdQKmVJToNZRf+25GtJXqGc274ieHf_yHKRJ+YOKWdgA@mail.gmail.com>
	<20111208234624.GD32474@konrad-lan>
	<CAEc3jaC9=HiMoxSYZmXKRzoFcMYRaT9jrX3m1ZQO+M8CrH35Fg@mail.gmail.com>
	<CAEc3jaBBYBME0G3Ku_sTvzQz+oKQnpBPffA+bRUKxxRPABAeww@mail.gmail.com>
	<20111211125247.GQ12984@reaktio.net>
	<CAEc3jaCJ6wP27Ffm0wpOggWMgqcSNJiGxhtkszq6jgRD1nrZLg@mail.gmail.com>
Date: Mon, 12 Dec 2011 22:30:24 +0000
Message-ID: <CAEc3jaBS6WUB_oViMp=qT_0RP+LPjZuEV8Qko9Jabs6qaeSibQ@mail.gmail.com>
From: Roderick Colenbrander <thunderbird2k@gmail.com>
To: =?ISO-8859-1?Q?Pasi_K=E4rkk=E4inen?= <pasik@iki.fi>
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>, xen-devel@lists.xensource.com,
	Andreas Kinzler <ml-xen-devel@hfp.de>
Subject: Re: [Xen-devel] Questions about GPLPV stability tests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Sun, Dec 11, 2011 at 6:58 PM, Roderick Colenbrander
<thunderbird2k@gmail.com> wrote:
> On Sun, Dec 11, 2011 at 4:52 AM, Pasi K=E4rkk=E4inen <pasik@iki.fi> wrote:
>> On Fri, Dec 09, 2011 at 02:02:31PM -0800, Roderick Colenbrander wrote:
>>> One interesting observation. This morning I had another of my stress
>>> machines with the problem. I never had it on this problem before and
>>> it didn't have any of the new logging / software updates yet.
>>>
>>> The system was in the same state as the other machine which I reported
>>> about before. I tried SysRq stuff and other things. While I was about
>>> to reboot the system, a login prompt appeared again on the VGA. I
>>> don't know whether any of the stuff I did triggered it or not. Anyway
>>> it means Linux is not really dead. I tried logging, but I don't even
>>> see characters appearing. The system feels to be very, very, very
>>> slow.
>>>
>>
>> Hmm.. I wonder if this is the same issue I'm sometimes seeing on my lapt=
op..
>> suddenly it starts becoming slower, and after a while it's *very* slow..
>> not dead, but unusably slow..
>>
>> I haven't had time to (try to) debug it..
>>
>> -- Pasi
>>
>
> I'm seeing slowness issues on our systems as well. As in some code
> starts running really, really slowly. Local TCP 'heartbeat' like
> mechanism from Dom0 to a DomU timing out. Code which should execute
> quickly becoming orders of magnitude slower for no obvious reason.
> Typically we see evidence of this in logging.
>
> I felt there was a connection between this slowness and the
> 'unresponsive Dom0' but I haven't been able to confirm this. Normally
> we see weird things in our logs, but on the unresponsive systems I
> didn't see anything strange in the logs yet. Most likely the logs
> weren't synced to disk yet.
>
> After more investigation it seems that in my case all issues, seem to
> happen after the DomU is up and we somehow 'start' using it. During
> startup of our own software, both DomU and Dom0 would at least see a
> spike in cpu/disk activity before things settle down a bit. My feeling
> is (based on some logs) that this is when Dom0 sometimes becomes
> unresponsive.
>
> I'm still running tests on a number of machines, but it takes ages to
> get results.
>
> Roderick

Today, yet another of my machines went down. To explain the setup, I'm
running tests across a couple of similar machines. On some of the
machines I updated to latest 2.6.32.x and Xen 4.1.x (and I upgrade
every machine which goes down). The machine which just went down
wasn't using the latest versions yet, but some more logging was
enabled in 'dmesg'.

This box still had Xen 4.1.2 and 2.6.32.37. I'm not sure if the
logging is too useful, yet but it may be of some use. The log output
is mostly from the serial console. I looked at some log files on
disks. Some files give clues, but some important log files didn't get
synced to disk before bad things happened. The last timestamp I was
able to find was at '16:13:55' which some of our own software wrote
some line to its logs.

The few log files which got synced to disk tell that the VM started
around 16:13:02 which matches PCIe device ownership to the VM:

(XEN) [2011-12-10 16:13:03] [VT-D]iommu.c:1501: d0:PCIe: unmap bdf =3D 3:0.0
(XEN) [2011-12-10 16:13:03] [VT-D]iommu.c:1374: d1109:PCIe: map bdf =3D 3:0=
.0
(XEN) [2011-12-10 16:13:03] [VT-D]io.c:304: d1109: bind: m_gsi=3D55
g_gsi=3D32 device=3D4 intx=3D0
(XEN) [2011-12-10 16:13:23] [VT-D]io.c:328: d1109: unbind: m_gsi=3D55
g_gsi=3D32 device=3D4 intx=3D0
(XEN) [2011-12-10 16:13:23] [VT-D]io.c:386: d1109 unmap: m_irq=3D55
device=3D4 intx=3D0
(XEN) [2011-12-10 16:13:23] [VT-D]io.c:304: d1109: bind: m_gsi=3D16
g_gsi=3D32 device=3D4 intx=3D0


We are using the tapdisk driver for disk 'xvdc' which is referred to
as 'tdc' I guess. It is a copy-on-write
VHD disk which uses a raw disk image as its backing store. Apparently
there are all sorts of read errors.
Not sure if the read errors are too bad.

[905276.510737] blkback: ring-ref 15658, event-channel 13, protocol 1
(unspecified, assuming native)
[905276.512128] blkback: ring-ref 15658, event-channel 13, protocol 1
(unspecified, assuming native)
[905277.113215] block tdc: sector-size: 512 capacity: 118785
[905277.215872] blkback: ring-ref 15775, event-channel 14, protocol 1
(unspecified, assuming native)
[905680.196850] end_request: I/O error, dev tdc, sector 45689
[905680.197293] end_request: I/O error, dev tdc, sector 45689
[905680.197624] end_request: I/O error, dev tdc, sector 45688
[905680.197993] end_request: I/O error, dev tdc, sector 45696

More blktap issues hours later, right? The real problem must have
happened much earlier then.

[912393.552881] blkback: ring-ref 15810, event-channel 13, protocol 1
(unspecified, assuming native)
[912394.101667] block tdc: sector-size: 512 capacity: 118785
[912394.384715] blkback: ring-ref 15660, event-channel 14, protocol 1
(unspecified, assuming native)
[912402.433492] BUG: unable to handle kernel NULL pointer dereference
at 00000000000002f0
[912402.434077] IP: [<ffffffff81249ac2>] blktap_device_end_request+0x4e/0x68
[912402.434384] PGD 384bb067 PUD 3a55f067 PMD 0
[912402.434752] Oops: 0000 [#1] SMP
[912402.435096] last sysfs file: /sys/devices/virtual/block/tdc/removable
[912402.435363] CPU 2
[912402.435653] Modules linked in: dm_snapshot dm_mod ipmi_si ipmi_devintf
[912402.436092] Pid: 16994, comm: tapdisk2 Not tainted 2.6.32.37 #1 X8STi
[912402.436595] RIP: e030:[<ffffffff81249ac2>]  [<ffffffff81249ac2>]
blktap_device_end_request+0x4e/0x68
[912402.437117] RSP: e02b:ffff8800616f9d08  EFLAGS: 00010046
[912402.437380] RAX: 0000000000000000 RBX: ffff880014ef29b0 RCX:
0000000000000018
[912402.437884] RDX: 0000000000000000 RSI: 0000000000000000 RDI:
ffff88007fcebd58
[912402.438368] RBP: 0000000000000000 R08: ffffffff816a9488 R09:
ffff8800123af040
[912402.438855] R10: 00000001365d23c7 R11: ffffffff810861e1 R12:
ffff88007bea4e70
[912402.439358] R13: ffff88007b8aa800 R14: 0000000000000000 R15:
ffff880014ef29b0
[912402.439848] FS:  00007fde3bbe2730(0000) GS:ffff880028070000(0000)
knlGS:0000000000000000
[912402.440341] CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
[912402.440621] CR2: 00000000000002f0 CR3: 000000001f721000 CR4:
0000000000002660
[912402.441102] DR0: 0000000000000000 DR1: 0000000000000000 DR2:
0000000000000000
[912402.441583] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7:
0000000000000400
[912402.442083] Process tapdisk2 (pid: 16994, threadinfo
ffff8800616f8000, task ffff88007bab4ec0)
[912402.442569] Stack:
[912402.442825]  ffffea000185d038 0000000000000001 ffff88007bab4ec0
0000000000000000
[912402.443199] <0> ffff88007b8aa800 ffffffff81248c3b 00000000000001ff
0000000000000000
[912402.443871] <0> 00033e583f482159 000000000000e030 ffff88006f6da480
0000039f000003a0
[912402.444793] Call Trace:
[912402.445054]  [<ffffffff81248c3b>] ? blktap_ring_ioctl+0x137/0x228
[912402.445326]  [<ffffffff810bea63>] ? core_sys_select+0x1ee/0x21e
[912402.445599]  [<ffffffff810dc64f>] ? really_put_req+0x62/0x8f
[912402.445871]  [<ffffffff8100e865>] ? xen_force_evtchn_callback+0x9/0xa
[912402.446159]  [<ffffffff8100eef2>] ? check_events+0x12/0x20
[912402.446434]  [<ffffffff810dc4e4>] ? aio_read_evt+0x26/0xe4
[912402.446704]  [<ffffffff810dd71a>] ? sys_io_getevents+0x10e/0x356
[912402.446984]  [<ffffffff810bcc47>] ? vfs_ioctl+0x56/0x6c
[912402.447255]  [<ffffffff810bd133>] ? do_vfs_ioctl+0x460/0x49e
[912402.447543]  [<ffffffff81059699>] ? getnstimeofday+0x55/0xaf
[912402.447814]  [<ffffffff810bd1c2>] ? sys_ioctl+0x51/0x70
[912402.448083]  [<ffffffff81011a02>] ? system_call_fastpath+0x16/0x1b
[912402.448351] Code: e8 a5 f5 ff ff 49 8b 44 24 40 48 8b b8 f0 02 00
00 e8 a5 37 27 00 41 8b 54 24 60 44 89 f6 4c 89 e7 e8 85 13 f8 ff 49
8b 44 24 40 <48> 8b 80 f0 02 00 00 fe 00 ff 14 25 28 0d 6a 81 5b 5b 41
5c 41
[912402.451398] RIP  [<ffffffff81249ac2>] blktap_device_end_request+0x4e/0x=
68
[912402.451733]  RSP <ffff8800616f9d08>
[912402.451997] CR2: 00000000000002f0
[912402.452265] ---[ end trace f20c5f7e976fe78b ]---

Half a minute later I get tons of these:
[912432.458625] ata6.00: exception Emask 0x0 SAct 0xf SErr 0x0 action 0x6 f=
rozen
[912432.458893] ata6.00: failed command: READ FPDMA QUEUED
[912432.459172] ata6.00: cmd 60/08:00:f2:13:e3/00:00:0d:00:00/40 tag 0
ncq 4096 in

And tons of these:
[912478.690536] sd 5:0:0:0: [sda] Unhandled error code
[912478.690798] sd 5:0:0:0: [sda] Result: hostbyte=3DDID_BAD_TARGET
driverbyte=3DDRIVER_OK
[912478.691306] sd 5:0:0:0: [sda] CDB: Read(10): 28 00 00 e6 95 05 00 00 68=
 00

I wonder if we are having real SATA issues or whether this is somehow
caused by the 'real' problem which is tapdisk?

Finally I also get timeouts in the network code. I think these are
just caused by the bad things happening.
[912737.470673] WARNING: at net/sched/sch_generic.c:261
dev_watchdog+0xd2/0x16e()
[912737.471170] Hardware name: X8STi
[912737.471426] NETDEV WATCHDOG: eth0 (e1000e): transmit queue 0 timed out
[912737.471686] Modules linked in: dm_snapshot dm_mod ipmi_si ipmi_devintf
[912737.472106] Pid: 0, comm: swapper Tainted: G      D    2.6.32.37 #1
[912737.472586] Call Trace:
[912737.472838]  <IRQ>  [<ffffffff813c8e12>] ? dev_watchdog+0xd2/0x16e
[912737.473130]  [<ffffffff813c8e12>] ? dev_watchdog+0xd2/0x16e
[912737.473391]  [<ffffffff81040fb1>] ? warn_slowpath_common+0x77/0xa3
[912737.473668]  [<ffffffff813c8d40>] ? dev_watchdog+0x0/0x16e
[912737.473928]  [<ffffffff81041039 > ] ? warn_slowpk
_dev_program_evt+ 0xe3/0x18c
[90/0x60
[912737.474988]  [<ffffffff8100e865>] ? xen_force_evtchn_callback+0x9/0xa
[912737.480706]  [<ffffffff8100eef2>] ? check_events+0x12/0x20
[912737.480965]  [<ffffffff813c8d15>] ? netif_tx_lock+0x3d/0x68
[912737.481222]  [<ffffffff813c8d40>] ? dev_watchdog+0x0/0x16e
[912737.481481]  [<ffffffff813b83a0>] ? netdev_drivername+0x3b/0x40
[912737.481741]  [<ffffffff813c8e12>] ? dev_watchdog+0xd2/0x16e
[912737.482015]  [<ffffffff81049614>] ? run_timer_softirq+0x16c/0x1d9
[912737.482274]  [<ffffffff81078fb8>] ? handle_percpu_irq+0x4e/0x6a
[912737.482534]  [<ffffffff81045bc8>] ? __do_softirq+0x91/0x116
[912737.482794]  [<ffffffff81012b6c>] ? call_softirq+0x1c/0x30
[912737.483052]  [<ffffffff810140e7>] ? do_softirq+0x3f/0x7c
[912737.483324]  [<ffffffff81045a64>] ? irq_exit+0x36/0x76
[912737.483584]  [<ffffffff8123b6ad>] ? xen_evtchn_do_upcall+0x33/0x42
[912737.483843]  [<ffffffff81012bbe>] ? xen_do_hypervisor_callback+0x1e/0x30
[912737.484101]  <EOI>  [<ffffffff8100eedf>] ? xen_restore_fl_direct_end+0x=
0/0x1
[912737.484394]  [<ffffffff810093aa>] ? hypercall_page+0x3aa/0x1001
[912737.484670]  [<ffffffff810093aa>] ? hypercall_page+0x3aa/0x1001
[912737.484930]  [<ffffffff8100e8e3>] ? xen_safe_halt+0xc/0x15
[912737.485188]  [<ffffffff81017f07>] ? default_idle+0x21/0x3d
[912737.485447]  [<ffffffff81010df1>] ? cpu_idle+0x59/0x91
[912737.485704] ---[ end trace f20c5f7e976fe78c ]---


Does this feel like blktap issues? Or is it more likely that something
else happened which causes blktap and the other things to fail?

Roderick

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 12 22:31:47 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 Dec 2011 22: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.xensource.com>)
	id 1RaEP1-0004cR-Sq; Mon, 12 Dec 2011 22:31:19 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <thunderbird2k@gmail.com>) id 1RaEP0-0004cM-Cg
	for xen-devel@lists.xensource.com; Mon, 12 Dec 2011 22:31:18 +0000
X-Env-Sender: thunderbird2k@gmail.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1323728985!47574257!1
X-Originating-IP: [209.85.161.171]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24988 invoked from network); 12 Dec 2011 22:29:46 -0000
Received: from mail-gx0-f171.google.com (HELO mail-gx0-f171.google.com)
	(209.85.161.171)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Dec 2011 22:29:46 -0000
Received: by ggnh4 with SMTP id h4so55053813ggn.30
	for <xen-devel@lists.xensource.com>;
	Mon, 12 Dec 2011 14:30:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	bh=GDNM4sKYaMh95AmvcuaEDBZI/eNNkUl57sh+hDwpF+8=;
	b=QHfDp+nkQGyKiTTyPpZraC71AKtv3LDLJILPTdzS95W/ufpWGxxT1mvQc1H+vEk5BB
	z8CjRI5NLxxAWmSLyYpOYLaW/QfAurITwZuDTfB0D3HpSQwqeKTfrUm7CtXXCHzEuFZg
	IirsnsMq4VltrlrrP4vkMwSKTB4WItaHt+Yoc=
MIME-Version: 1.0
Received: by 10.236.79.38 with SMTP id h26mr29549973yhe.39.1323729025053; Mon,
	12 Dec 2011 14:30:25 -0800 (PST)
Received: by 10.100.48.10 with HTTP; Mon, 12 Dec 2011 14:30:24 -0800 (PST)
In-Reply-To: <CAEc3jaCJ6wP27Ffm0wpOggWMgqcSNJiGxhtkszq6jgRD1nrZLg@mail.gmail.com>
References: <CAEc3jaAa7y8C2NNBn1=L3AhS0uuYFP6ze8o1cZ9yG2VYHx6qMA@mail.gmail.com>
	<4ED5215D.1010403@hfp.de>
	<20111129230212.GA23958@andromeda.dapyr.net>
	<CAEc3jaAO0JhtOt6phQHwtE_A+NF7uGHGZ8uJv3BirEYybfVceg@mail.gmail.com>
	<CAEc3jaACffpr9D1Hq_012vHAGhPLEfvsZjh7YyJ=Q-3FdtHS0Q@mail.gmail.com>
	<CAPbh3rtOQ1HTPReqYcpE3vzk+-na0MTLLHZD15=Fg4yxB+ypaA@mail.gmail.com>
	<CAEc3jaBdQKmVJToNZRf+25GtJXqGc274ieHf_yHKRJ+YOKWdgA@mail.gmail.com>
	<20111208234624.GD32474@konrad-lan>
	<CAEc3jaC9=HiMoxSYZmXKRzoFcMYRaT9jrX3m1ZQO+M8CrH35Fg@mail.gmail.com>
	<CAEc3jaBBYBME0G3Ku_sTvzQz+oKQnpBPffA+bRUKxxRPABAeww@mail.gmail.com>
	<20111211125247.GQ12984@reaktio.net>
	<CAEc3jaCJ6wP27Ffm0wpOggWMgqcSNJiGxhtkszq6jgRD1nrZLg@mail.gmail.com>
Date: Mon, 12 Dec 2011 22:30:24 +0000
Message-ID: <CAEc3jaBS6WUB_oViMp=qT_0RP+LPjZuEV8Qko9Jabs6qaeSibQ@mail.gmail.com>
From: Roderick Colenbrander <thunderbird2k@gmail.com>
To: =?ISO-8859-1?Q?Pasi_K=E4rkk=E4inen?= <pasik@iki.fi>
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>, xen-devel@lists.xensource.com,
	Andreas Kinzler <ml-xen-devel@hfp.de>
Subject: Re: [Xen-devel] Questions about GPLPV stability tests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Sun, Dec 11, 2011 at 6:58 PM, Roderick Colenbrander
<thunderbird2k@gmail.com> wrote:
> On Sun, Dec 11, 2011 at 4:52 AM, Pasi K=E4rkk=E4inen <pasik@iki.fi> wrote:
>> On Fri, Dec 09, 2011 at 02:02:31PM -0800, Roderick Colenbrander wrote:
>>> One interesting observation. This morning I had another of my stress
>>> machines with the problem. I never had it on this problem before and
>>> it didn't have any of the new logging / software updates yet.
>>>
>>> The system was in the same state as the other machine which I reported
>>> about before. I tried SysRq stuff and other things. While I was about
>>> to reboot the system, a login prompt appeared again on the VGA. I
>>> don't know whether any of the stuff I did triggered it or not. Anyway
>>> it means Linux is not really dead. I tried logging, but I don't even
>>> see characters appearing. The system feels to be very, very, very
>>> slow.
>>>
>>
>> Hmm.. I wonder if this is the same issue I'm sometimes seeing on my lapt=
op..
>> suddenly it starts becoming slower, and after a while it's *very* slow..
>> not dead, but unusably slow..
>>
>> I haven't had time to (try to) debug it..
>>
>> -- Pasi
>>
>
> I'm seeing slowness issues on our systems as well. As in some code
> starts running really, really slowly. Local TCP 'heartbeat' like
> mechanism from Dom0 to a DomU timing out. Code which should execute
> quickly becoming orders of magnitude slower for no obvious reason.
> Typically we see evidence of this in logging.
>
> I felt there was a connection between this slowness and the
> 'unresponsive Dom0' but I haven't been able to confirm this. Normally
> we see weird things in our logs, but on the unresponsive systems I
> didn't see anything strange in the logs yet. Most likely the logs
> weren't synced to disk yet.
>
> After more investigation it seems that in my case all issues, seem to
> happen after the DomU is up and we somehow 'start' using it. During
> startup of our own software, both DomU and Dom0 would at least see a
> spike in cpu/disk activity before things settle down a bit. My feeling
> is (based on some logs) that this is when Dom0 sometimes becomes
> unresponsive.
>
> I'm still running tests on a number of machines, but it takes ages to
> get results.
>
> Roderick

Today, yet another of my machines went down. To explain the setup, I'm
running tests across a couple of similar machines. On some of the
machines I updated to latest 2.6.32.x and Xen 4.1.x (and I upgrade
every machine which goes down). The machine which just went down
wasn't using the latest versions yet, but some more logging was
enabled in 'dmesg'.

This box still had Xen 4.1.2 and 2.6.32.37. I'm not sure if the
logging is too useful, yet but it may be of some use. The log output
is mostly from the serial console. I looked at some log files on
disks. Some files give clues, but some important log files didn't get
synced to disk before bad things happened. The last timestamp I was
able to find was at '16:13:55' which some of our own software wrote
some line to its logs.

The few log files which got synced to disk tell that the VM started
around 16:13:02 which matches PCIe device ownership to the VM:

(XEN) [2011-12-10 16:13:03] [VT-D]iommu.c:1501: d0:PCIe: unmap bdf =3D 3:0.0
(XEN) [2011-12-10 16:13:03] [VT-D]iommu.c:1374: d1109:PCIe: map bdf =3D 3:0=
.0
(XEN) [2011-12-10 16:13:03] [VT-D]io.c:304: d1109: bind: m_gsi=3D55
g_gsi=3D32 device=3D4 intx=3D0
(XEN) [2011-12-10 16:13:23] [VT-D]io.c:328: d1109: unbind: m_gsi=3D55
g_gsi=3D32 device=3D4 intx=3D0
(XEN) [2011-12-10 16:13:23] [VT-D]io.c:386: d1109 unmap: m_irq=3D55
device=3D4 intx=3D0
(XEN) [2011-12-10 16:13:23] [VT-D]io.c:304: d1109: bind: m_gsi=3D16
g_gsi=3D32 device=3D4 intx=3D0


We are using the tapdisk driver for disk 'xvdc' which is referred to
as 'tdc' I guess. It is a copy-on-write
VHD disk which uses a raw disk image as its backing store. Apparently
there are all sorts of read errors.
Not sure if the read errors are too bad.

[905276.510737] blkback: ring-ref 15658, event-channel 13, protocol 1
(unspecified, assuming native)
[905276.512128] blkback: ring-ref 15658, event-channel 13, protocol 1
(unspecified, assuming native)
[905277.113215] block tdc: sector-size: 512 capacity: 118785
[905277.215872] blkback: ring-ref 15775, event-channel 14, protocol 1
(unspecified, assuming native)
[905680.196850] end_request: I/O error, dev tdc, sector 45689
[905680.197293] end_request: I/O error, dev tdc, sector 45689
[905680.197624] end_request: I/O error, dev tdc, sector 45688
[905680.197993] end_request: I/O error, dev tdc, sector 45696

More blktap issues hours later, right? The real problem must have
happened much earlier then.

[912393.552881] blkback: ring-ref 15810, event-channel 13, protocol 1
(unspecified, assuming native)
[912394.101667] block tdc: sector-size: 512 capacity: 118785
[912394.384715] blkback: ring-ref 15660, event-channel 14, protocol 1
(unspecified, assuming native)
[912402.433492] BUG: unable to handle kernel NULL pointer dereference
at 00000000000002f0
[912402.434077] IP: [<ffffffff81249ac2>] blktap_device_end_request+0x4e/0x68
[912402.434384] PGD 384bb067 PUD 3a55f067 PMD 0
[912402.434752] Oops: 0000 [#1] SMP
[912402.435096] last sysfs file: /sys/devices/virtual/block/tdc/removable
[912402.435363] CPU 2
[912402.435653] Modules linked in: dm_snapshot dm_mod ipmi_si ipmi_devintf
[912402.436092] Pid: 16994, comm: tapdisk2 Not tainted 2.6.32.37 #1 X8STi
[912402.436595] RIP: e030:[<ffffffff81249ac2>]  [<ffffffff81249ac2>]
blktap_device_end_request+0x4e/0x68
[912402.437117] RSP: e02b:ffff8800616f9d08  EFLAGS: 00010046
[912402.437380] RAX: 0000000000000000 RBX: ffff880014ef29b0 RCX:
0000000000000018
[912402.437884] RDX: 0000000000000000 RSI: 0000000000000000 RDI:
ffff88007fcebd58
[912402.438368] RBP: 0000000000000000 R08: ffffffff816a9488 R09:
ffff8800123af040
[912402.438855] R10: 00000001365d23c7 R11: ffffffff810861e1 R12:
ffff88007bea4e70
[912402.439358] R13: ffff88007b8aa800 R14: 0000000000000000 R15:
ffff880014ef29b0
[912402.439848] FS:  00007fde3bbe2730(0000) GS:ffff880028070000(0000)
knlGS:0000000000000000
[912402.440341] CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
[912402.440621] CR2: 00000000000002f0 CR3: 000000001f721000 CR4:
0000000000002660
[912402.441102] DR0: 0000000000000000 DR1: 0000000000000000 DR2:
0000000000000000
[912402.441583] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7:
0000000000000400
[912402.442083] Process tapdisk2 (pid: 16994, threadinfo
ffff8800616f8000, task ffff88007bab4ec0)
[912402.442569] Stack:
[912402.442825]  ffffea000185d038 0000000000000001 ffff88007bab4ec0
0000000000000000
[912402.443199] <0> ffff88007b8aa800 ffffffff81248c3b 00000000000001ff
0000000000000000
[912402.443871] <0> 00033e583f482159 000000000000e030 ffff88006f6da480
0000039f000003a0
[912402.444793] Call Trace:
[912402.445054]  [<ffffffff81248c3b>] ? blktap_ring_ioctl+0x137/0x228
[912402.445326]  [<ffffffff810bea63>] ? core_sys_select+0x1ee/0x21e
[912402.445599]  [<ffffffff810dc64f>] ? really_put_req+0x62/0x8f
[912402.445871]  [<ffffffff8100e865>] ? xen_force_evtchn_callback+0x9/0xa
[912402.446159]  [<ffffffff8100eef2>] ? check_events+0x12/0x20
[912402.446434]  [<ffffffff810dc4e4>] ? aio_read_evt+0x26/0xe4
[912402.446704]  [<ffffffff810dd71a>] ? sys_io_getevents+0x10e/0x356
[912402.446984]  [<ffffffff810bcc47>] ? vfs_ioctl+0x56/0x6c
[912402.447255]  [<ffffffff810bd133>] ? do_vfs_ioctl+0x460/0x49e
[912402.447543]  [<ffffffff81059699>] ? getnstimeofday+0x55/0xaf
[912402.447814]  [<ffffffff810bd1c2>] ? sys_ioctl+0x51/0x70
[912402.448083]  [<ffffffff81011a02>] ? system_call_fastpath+0x16/0x1b
[912402.448351] Code: e8 a5 f5 ff ff 49 8b 44 24 40 48 8b b8 f0 02 00
00 e8 a5 37 27 00 41 8b 54 24 60 44 89 f6 4c 89 e7 e8 85 13 f8 ff 49
8b 44 24 40 <48> 8b 80 f0 02 00 00 fe 00 ff 14 25 28 0d 6a 81 5b 5b 41
5c 41
[912402.451398] RIP  [<ffffffff81249ac2>] blktap_device_end_request+0x4e/0x=
68
[912402.451733]  RSP <ffff8800616f9d08>
[912402.451997] CR2: 00000000000002f0
[912402.452265] ---[ end trace f20c5f7e976fe78b ]---

Half a minute later I get tons of these:
[912432.458625] ata6.00: exception Emask 0x0 SAct 0xf SErr 0x0 action 0x6 f=
rozen
[912432.458893] ata6.00: failed command: READ FPDMA QUEUED
[912432.459172] ata6.00: cmd 60/08:00:f2:13:e3/00:00:0d:00:00/40 tag 0
ncq 4096 in

And tons of these:
[912478.690536] sd 5:0:0:0: [sda] Unhandled error code
[912478.690798] sd 5:0:0:0: [sda] Result: hostbyte=3DDID_BAD_TARGET
driverbyte=3DDRIVER_OK
[912478.691306] sd 5:0:0:0: [sda] CDB: Read(10): 28 00 00 e6 95 05 00 00 68=
 00

I wonder if we are having real SATA issues or whether this is somehow
caused by the 'real' problem which is tapdisk?

Finally I also get timeouts in the network code. I think these are
just caused by the bad things happening.
[912737.470673] WARNING: at net/sched/sch_generic.c:261
dev_watchdog+0xd2/0x16e()
[912737.471170] Hardware name: X8STi
[912737.471426] NETDEV WATCHDOG: eth0 (e1000e): transmit queue 0 timed out
[912737.471686] Modules linked in: dm_snapshot dm_mod ipmi_si ipmi_devintf
[912737.472106] Pid: 0, comm: swapper Tainted: G      D    2.6.32.37 #1
[912737.472586] Call Trace:
[912737.472838]  <IRQ>  [<ffffffff813c8e12>] ? dev_watchdog+0xd2/0x16e
[912737.473130]  [<ffffffff813c8e12>] ? dev_watchdog+0xd2/0x16e
[912737.473391]  [<ffffffff81040fb1>] ? warn_slowpath_common+0x77/0xa3
[912737.473668]  [<ffffffff813c8d40>] ? dev_watchdog+0x0/0x16e
[912737.473928]  [<ffffffff81041039 > ] ? warn_slowpk
_dev_program_evt+ 0xe3/0x18c
[90/0x60
[912737.474988]  [<ffffffff8100e865>] ? xen_force_evtchn_callback+0x9/0xa
[912737.480706]  [<ffffffff8100eef2>] ? check_events+0x12/0x20
[912737.480965]  [<ffffffff813c8d15>] ? netif_tx_lock+0x3d/0x68
[912737.481222]  [<ffffffff813c8d40>] ? dev_watchdog+0x0/0x16e
[912737.481481]  [<ffffffff813b83a0>] ? netdev_drivername+0x3b/0x40
[912737.481741]  [<ffffffff813c8e12>] ? dev_watchdog+0xd2/0x16e
[912737.482015]  [<ffffffff81049614>] ? run_timer_softirq+0x16c/0x1d9
[912737.482274]  [<ffffffff81078fb8>] ? handle_percpu_irq+0x4e/0x6a
[912737.482534]  [<ffffffff81045bc8>] ? __do_softirq+0x91/0x116
[912737.482794]  [<ffffffff81012b6c>] ? call_softirq+0x1c/0x30
[912737.483052]  [<ffffffff810140e7>] ? do_softirq+0x3f/0x7c
[912737.483324]  [<ffffffff81045a64>] ? irq_exit+0x36/0x76
[912737.483584]  [<ffffffff8123b6ad>] ? xen_evtchn_do_upcall+0x33/0x42
[912737.483843]  [<ffffffff81012bbe>] ? xen_do_hypervisor_callback+0x1e/0x30
[912737.484101]  <EOI>  [<ffffffff8100eedf>] ? xen_restore_fl_direct_end+0x=
0/0x1
[912737.484394]  [<ffffffff810093aa>] ? hypercall_page+0x3aa/0x1001
[912737.484670]  [<ffffffff810093aa>] ? hypercall_page+0x3aa/0x1001
[912737.484930]  [<ffffffff8100e8e3>] ? xen_safe_halt+0xc/0x15
[912737.485188]  [<ffffffff81017f07>] ? default_idle+0x21/0x3d
[912737.485447]  [<ffffffff81010df1>] ? cpu_idle+0x59/0x91
[912737.485704] ---[ end trace f20c5f7e976fe78c ]---


Does this feel like blktap issues? Or is it more likely that something
else happened which causes blktap and the other things to fail?

Roderick

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 00:13:34 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 00:13:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaFzF-0005nC-S3; Tue, 13 Dec 2011 00:12:49 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RaFzE-0005n7-SR
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 00:12:49 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1323735081!50328617!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDc5MA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23520 invoked from network); 13 Dec 2011 00:11:21 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 00:11:21 -0000
X-IronPort-AV: E=Sophos;i="4.71,342,1320624000"; 
   d="scan'208";a="9428707"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Dec 2011 00:11:59 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 13 Dec 2011 00:11:59 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RaFyR-0002QB-9Y;
	Tue, 13 Dec 2011 00:11:59 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RaFyR-0003h9-8t;
	Tue, 13 Dec 2011 00:11:59 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10480-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 13 Dec 2011 00:11:59 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10480: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10480 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10480/

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-amd64-xl-sedf     11 guest-localmigrate        fail REGR. vs. 10474
 test-amd64-amd64-win          7 windows-install           fail REGR. vs. 10474

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-i386-i386-xl-winxpsp3    7 windows-install              fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install          fail never pass
 test-amd64-i386-xl-win7-amd64  7 windows-install              fail  never pass
 test-amd64-i386-xend-winxpsp3  7 windows-install              fail  never pass
 test-amd64-amd64-xl-win7-amd64  7 windows-install              fail never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win           7 windows-install              fail   like 10473
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  7ca56cca09ad
baseline version:
 xen                  1c58bb664d8d

------------------------------------------------------------
People who touched revisions under test:
  Andre Przywara <andre.przywara@amd.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Roger Pau Monne <roger.pau@entel.upc.edu>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 336 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 00:13:34 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 00:13:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaFzF-0005nC-S3; Tue, 13 Dec 2011 00:12:49 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RaFzE-0005n7-SR
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 00:12:49 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1323735081!50328617!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDc5MA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23520 invoked from network); 13 Dec 2011 00:11:21 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 00:11:21 -0000
X-IronPort-AV: E=Sophos;i="4.71,342,1320624000"; 
   d="scan'208";a="9428707"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Dec 2011 00:11:59 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 13 Dec 2011 00:11:59 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RaFyR-0002QB-9Y;
	Tue, 13 Dec 2011 00:11:59 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RaFyR-0003h9-8t;
	Tue, 13 Dec 2011 00:11:59 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10480-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 13 Dec 2011 00:11:59 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10480: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10480 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10480/

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-amd64-xl-sedf     11 guest-localmigrate        fail REGR. vs. 10474
 test-amd64-amd64-win          7 windows-install           fail REGR. vs. 10474

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-i386-i386-xl-winxpsp3    7 windows-install              fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install          fail never pass
 test-amd64-i386-xl-win7-amd64  7 windows-install              fail  never pass
 test-amd64-i386-xend-winxpsp3  7 windows-install              fail  never pass
 test-amd64-amd64-xl-win7-amd64  7 windows-install              fail never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win           7 windows-install              fail   like 10473
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  7ca56cca09ad
baseline version:
 xen                  1c58bb664d8d

------------------------------------------------------------
People who touched revisions under test:
  Andre Przywara <andre.przywara@amd.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Roger Pau Monne <roger.pau@entel.upc.edu>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 336 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 00:20:46 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 00: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.xensource.com>)
	id 1RaG6V-0005wX-41; Tue, 13 Dec 2011 00:20:19 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.r.wilk@gmail.com>) id 1RaG6T-0005w9-2W
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 00:20:17 +0000
X-Env-Sender: konrad.r.wilk@gmail.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1323735562!6953902!1
X-Originating-IP: [209.85.220.171]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9509 invoked from network); 13 Dec 2011 00:19:23 -0000
Received: from mail-vx0-f171.google.com (HELO mail-vx0-f171.google.com)
	(209.85.220.171)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 00:19:23 -0000
Received: by vcbfo1 with SMTP id fo1so16804598vcb.30
	for <xen-devel@lists.xensource.com>;
	Mon, 12 Dec 2011 16:19:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:date:from:to:cc:subject:message-id:references:mime-version
	:content-type:content-disposition:in-reply-to:user-agent;
	bh=tR5Jlrr+d60vpVzMHw4ceG24OPCW9aJ2/K+/VNhBpiw=;
	b=rUCkWrvudLMl5lJOXL7xc4xLchKrIK01XzH8MNGcm51qXdZNLKB1es3YraYgKihg5x
	ZM9AgJDHUYG472Ak7yYI6qK8YF9t7xWYZzZ3TULvCL2LBNWlisJfPdyC0bPaAnN+wG79
	8XDbJ9orxlHUMNTcNTRb69CQ3TR7fuXZe4uic=
Received: by 10.52.240.144 with SMTP id wa16mr205845vdc.33.1323735561988;
	Mon, 12 Dec 2011 16:19:21 -0800 (PST)
Received: from konrad-lan (209-6-85-33.c3-0.smr-ubr2.sbo-smr.ma.cable.rcn.com.
	[209.6.85.33]) by mx.google.com with ESMTPS id
	dn20sm12091705vdb.15.2011.12.12.16.19.20
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 12 Dec 2011 16:19:21 -0800 (PST)
Date: Mon, 12 Dec 2011 19:19:13 -0500
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: "Taylor, Neal E" <Neal.Taylor@ca.com>
Message-ID: <20111213001912.GA2730@konrad-lan>
References: <3E243B26F475504B9BB0BCC9728B0DA629E16E01@USILMS110A.ca.com>
	<20111209203010.GA14412@andromeda.dapyr.net>
	<3E243B26F475504B9BB0BCC9728B0DA629E17AEA@USILMS110A.ca.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <3E243B26F475504B9BB0BCC9728B0DA629E17AEA@USILMS110A.ca.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: xen-devel <xen-devel@lists.xensource.com>, "Kalev,
	Leonid" <Leonid.Kalev@ca.com>, "Dave, Tushar N" <tushar.n.dave@intel.com>
Subject: Re: [Xen-devel] Buffers not reachable by PCI
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Dec 12, 2011 at 10:11:20PM +0000, Taylor, Neal E wrote:
> We're having trouble getting a serial log. Are there other ways to capture the information you need?
> 
> Attached is a dmesg with 'debug loglevel 8' set on the kernel line... actually, with  
> 
>    #define DEFAULT_MESSAGE_LOGLEVEL 8
> 
> set near the top of printk.c as well, since I wasn't seeing any difference in the log files with loglevel set to 8.

I needed this:

[    0.000000] Reserving virtual address space above 0xff800000
[    0.000000] Linux version 3.0.4-36.xen0 (root@nt-dev-Cent55-32) (gcc version 4.1.2 20080704 (Red Hat 4.1.2-48)) #1 SMP Mon Dec 12 14:54:39 EST 2011
[    0.000000] released 0 pages of unused memory
[    0.000000] 1-1 mapping on a0->100
[    0.000000] 1-1 mapping on bffc0->100000
[    0.000000] Set 262304 page(s) to 1-1 mapping.
[    0.000000] BIOS-provided physical RAM map:
[    0.000000]  Xen: 0000000000000000 - 00000000000a0000 (usable)
[    0.000000]  Xen: 00000000000a0000 - 0000000000100000 (reserved)
[    0.000000]  Xen: 0000000000100000 - 0000000020000000 (usable)
[    0.000000]  Xen: 0000000020000000 - 00000000bffc0000 (unusable)
[    0.000000]  Xen: 00000000bffc0000 - 00000000bffcfc00 (ACPI data)
[    0.000000]  Xen: 00000000bffcfc00 - 00000000bffff000 (reserved)
[    0.000000]  Xen: 00000000e0000000 - 00000000fec90000 (reserved)
[    0.000000]  Xen: 00000000fed00000 - 00000000fed00400 (reserved)
[    0.000000]  Xen: 00000000fee00000 - 00000000fee10000 (reserved)
[    0.000000]  Xen: 00000000ffb00000 - 0000000100000000 (reserved)
[    0.000000]  Xen: 0000000100000000 - 00000001dffc0000 (usable)
[    0.000000] NX (Execute Disable) protection: active
[    0.000000] DMI 2.3 present.
[    0.000000] DMI: Dell Computer Corporation PowerEdge 1850/0RC130, BIOS A05 01/09/2006
[    0.000000] e820 update range: 0000000000000000 - 0000000000010000 (usable) ==> (reserved)
[    0.000000] e820 remove range: 00000000000a0000 - 0000000000100000 (usable)
[    0.000000] last_pfn = 0x1dffc0 max_arch_pfn = 0x1000000
[    0.000000] found SMP MP-table at [c00fe710] fe710
[    0.000000] initial memory mapped : 0 - 023ff000
[    0.000000] Base memory trampoline at [c009f000] 9f000 size 4096
[    0.000000] init_memory_mapping: 0000000000000000-00000000373fe000
[    0.000000]  0000000000 - 00373fe000 page 4k
[    0.000000] kernel direct mapping tables up to 373fe000 @ 2242000-23ff000
[    0.000000] xen: setting RW the range 23ea000 - 23ff000
[    0.000000] RAMDISK: 016fb000 - 01ab2000
.. snip..
[    0.000000] Placing 64MB software IO TLB between d832cf00 - dc32cf00
[    0.000000] software IO TLB at phys 0x1832cf00 - 0x1c32cf00

And that tells me that 1) it is allocated above the 4GB - which
from a PFN perspectivie is not a big deal, as the MFNs are below 4GB
2), but it messes up the other drivers which expect the SWIOTLB to be
under 4GB.


Try this patch:

diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index 8e964b9..600b53c 100644
--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -166,7 +166,7 @@ retry:
 	/*
 	 * Get IO TLB memory from any location.
 	 */
-	xen_io_tlb_start = alloc_bootmem(bytes);
+	xen_io_tlb_start = alloc_bootmem_low(bytes);
 	if (!xen_io_tlb_start) {
 		m = "Cannot allocate Xen-SWIOTLB buffer!\n";
 		goto error;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 00:20:46 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 00: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.xensource.com>)
	id 1RaG6V-0005wX-41; Tue, 13 Dec 2011 00:20:19 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.r.wilk@gmail.com>) id 1RaG6T-0005w9-2W
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 00:20:17 +0000
X-Env-Sender: konrad.r.wilk@gmail.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1323735562!6953902!1
X-Originating-IP: [209.85.220.171]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9509 invoked from network); 13 Dec 2011 00:19:23 -0000
Received: from mail-vx0-f171.google.com (HELO mail-vx0-f171.google.com)
	(209.85.220.171)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 00:19:23 -0000
Received: by vcbfo1 with SMTP id fo1so16804598vcb.30
	for <xen-devel@lists.xensource.com>;
	Mon, 12 Dec 2011 16:19:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:date:from:to:cc:subject:message-id:references:mime-version
	:content-type:content-disposition:in-reply-to:user-agent;
	bh=tR5Jlrr+d60vpVzMHw4ceG24OPCW9aJ2/K+/VNhBpiw=;
	b=rUCkWrvudLMl5lJOXL7xc4xLchKrIK01XzH8MNGcm51qXdZNLKB1es3YraYgKihg5x
	ZM9AgJDHUYG472Ak7yYI6qK8YF9t7xWYZzZ3TULvCL2LBNWlisJfPdyC0bPaAnN+wG79
	8XDbJ9orxlHUMNTcNTRb69CQ3TR7fuXZe4uic=
Received: by 10.52.240.144 with SMTP id wa16mr205845vdc.33.1323735561988;
	Mon, 12 Dec 2011 16:19:21 -0800 (PST)
Received: from konrad-lan (209-6-85-33.c3-0.smr-ubr2.sbo-smr.ma.cable.rcn.com.
	[209.6.85.33]) by mx.google.com with ESMTPS id
	dn20sm12091705vdb.15.2011.12.12.16.19.20
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 12 Dec 2011 16:19:21 -0800 (PST)
Date: Mon, 12 Dec 2011 19:19:13 -0500
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: "Taylor, Neal E" <Neal.Taylor@ca.com>
Message-ID: <20111213001912.GA2730@konrad-lan>
References: <3E243B26F475504B9BB0BCC9728B0DA629E16E01@USILMS110A.ca.com>
	<20111209203010.GA14412@andromeda.dapyr.net>
	<3E243B26F475504B9BB0BCC9728B0DA629E17AEA@USILMS110A.ca.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <3E243B26F475504B9BB0BCC9728B0DA629E17AEA@USILMS110A.ca.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: xen-devel <xen-devel@lists.xensource.com>, "Kalev,
	Leonid" <Leonid.Kalev@ca.com>, "Dave, Tushar N" <tushar.n.dave@intel.com>
Subject: Re: [Xen-devel] Buffers not reachable by PCI
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Dec 12, 2011 at 10:11:20PM +0000, Taylor, Neal E wrote:
> We're having trouble getting a serial log. Are there other ways to capture the information you need?
> 
> Attached is a dmesg with 'debug loglevel 8' set on the kernel line... actually, with  
> 
>    #define DEFAULT_MESSAGE_LOGLEVEL 8
> 
> set near the top of printk.c as well, since I wasn't seeing any difference in the log files with loglevel set to 8.

I needed this:

[    0.000000] Reserving virtual address space above 0xff800000
[    0.000000] Linux version 3.0.4-36.xen0 (root@nt-dev-Cent55-32) (gcc version 4.1.2 20080704 (Red Hat 4.1.2-48)) #1 SMP Mon Dec 12 14:54:39 EST 2011
[    0.000000] released 0 pages of unused memory
[    0.000000] 1-1 mapping on a0->100
[    0.000000] 1-1 mapping on bffc0->100000
[    0.000000] Set 262304 page(s) to 1-1 mapping.
[    0.000000] BIOS-provided physical RAM map:
[    0.000000]  Xen: 0000000000000000 - 00000000000a0000 (usable)
[    0.000000]  Xen: 00000000000a0000 - 0000000000100000 (reserved)
[    0.000000]  Xen: 0000000000100000 - 0000000020000000 (usable)
[    0.000000]  Xen: 0000000020000000 - 00000000bffc0000 (unusable)
[    0.000000]  Xen: 00000000bffc0000 - 00000000bffcfc00 (ACPI data)
[    0.000000]  Xen: 00000000bffcfc00 - 00000000bffff000 (reserved)
[    0.000000]  Xen: 00000000e0000000 - 00000000fec90000 (reserved)
[    0.000000]  Xen: 00000000fed00000 - 00000000fed00400 (reserved)
[    0.000000]  Xen: 00000000fee00000 - 00000000fee10000 (reserved)
[    0.000000]  Xen: 00000000ffb00000 - 0000000100000000 (reserved)
[    0.000000]  Xen: 0000000100000000 - 00000001dffc0000 (usable)
[    0.000000] NX (Execute Disable) protection: active
[    0.000000] DMI 2.3 present.
[    0.000000] DMI: Dell Computer Corporation PowerEdge 1850/0RC130, BIOS A05 01/09/2006
[    0.000000] e820 update range: 0000000000000000 - 0000000000010000 (usable) ==> (reserved)
[    0.000000] e820 remove range: 00000000000a0000 - 0000000000100000 (usable)
[    0.000000] last_pfn = 0x1dffc0 max_arch_pfn = 0x1000000
[    0.000000] found SMP MP-table at [c00fe710] fe710
[    0.000000] initial memory mapped : 0 - 023ff000
[    0.000000] Base memory trampoline at [c009f000] 9f000 size 4096
[    0.000000] init_memory_mapping: 0000000000000000-00000000373fe000
[    0.000000]  0000000000 - 00373fe000 page 4k
[    0.000000] kernel direct mapping tables up to 373fe000 @ 2242000-23ff000
[    0.000000] xen: setting RW the range 23ea000 - 23ff000
[    0.000000] RAMDISK: 016fb000 - 01ab2000
.. snip..
[    0.000000] Placing 64MB software IO TLB between d832cf00 - dc32cf00
[    0.000000] software IO TLB at phys 0x1832cf00 - 0x1c32cf00

And that tells me that 1) it is allocated above the 4GB - which
from a PFN perspectivie is not a big deal, as the MFNs are below 4GB
2), but it messes up the other drivers which expect the SWIOTLB to be
under 4GB.


Try this patch:

diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index 8e964b9..600b53c 100644
--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -166,7 +166,7 @@ retry:
 	/*
 	 * Get IO TLB memory from any location.
 	 */
-	xen_io_tlb_start = alloc_bootmem(bytes);
+	xen_io_tlb_start = alloc_bootmem_low(bytes);
 	if (!xen_io_tlb_start) {
 		m = "Cannot allocate Xen-SWIOTLB buffer!\n";
 		goto error;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 01:52:47 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 01: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.xensource.com>)
	id 1RaHXC-0002IR-IX; Tue, 13 Dec 2011 01:51:58 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <james.harper@bendigoit.com.au>) id 1RaHXA-0002IM-9Z
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 01:51:56 +0000
X-Env-Sender: james.harper@bendigoit.com.au
X-Msg-Ref: server-7.tower-174.messagelabs.com!1323741059!5285376!1
X-Originating-IP: [203.16.224.4]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7801 invoked from network); 13 Dec 2011 01:51:02 -0000
Received: from smtp1.bendigoit.com.au (HELO smtp1.bendigoit.com.au)
	(203.16.224.4)
	by server-7.tower-174.messagelabs.com with AES256-SHA encrypted SMTP;
	13 Dec 2011 01:51:02 -0000
Received: from smtp2.bendigoit.com.au ([203.16.207.99]
	helo=mail.bendigoit.com.au)
	by smtp1.bendigoit.com.au with esmtp (Exim 4.69)
	(envelope-from <james.harper@bendigoit.com.au>)
	id 1RaHVm-00083K-TW; Tue, 13 Dec 2011 12:50:30 +1100
MIME-Version: 1.0
Content-class: urn:content-classes:message
X-MimeOLE: Produced By Microsoft Exchange V6.5
Date: Tue, 13 Dec 2011 12:50:30 +1100
Message-ID: <AEC6C66638C05B468B556EA548C1A77D01EE02DF@trantor>
In-Reply-To: <CAEc3jaBS6WUB_oViMp=qT_0RP+LPjZuEV8Qko9Jabs6qaeSibQ@mail.gmail.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Xen-devel] Questions about GPLPV stability tests
Thread-Index: Acy5Hsbke8mElGU7SluoOCtnc5igNgAGqiDw
References: <CAEc3jaAa7y8C2NNBn1=L3AhS0uuYFP6ze8o1cZ9yG2VYHx6qMA@mail.gmail.com><4ED5215D.1010403@hfp.de><20111129230212.GA23958@andromeda.dapyr.net><CAEc3jaAO0JhtOt6phQHwtE_A+NF7uGHGZ8uJv3BirEYybfVceg@mail.gmail.com><CAEc3jaACffpr9D1Hq_012vHAGhPLEfvsZjh7YyJ=Q-3FdtHS0Q@mail.gmail.com><CAPbh3rtOQ1HTPReqYcpE3vzk+-na0MTLLHZD15=Fg4yxB+ypaA@mail.gmail.com><CAEc3jaBdQKmVJToNZRf+25GtJXqGc274ieHf_yHKRJ+YOKWdgA@mail.gmail.com><20111208234624.GD32474@konrad-lan><CAEc3jaC9=HiMoxSYZmXKRzoFcMYRaT9jrX3m1ZQO+M8CrH35Fg@mail.gmail.com><CAEc3jaBBYBME0G3Ku_sTvzQz+oKQnpBPffA+bRUKxxRPABAeww@mail.gmail.com><20111211125247.GQ12984@reaktio.net><CAEc3jaCJ6wP27Ffm0wpOggWMgqcSNJiGxhtkszq6jgRD1nrZLg@mail.gmail.com>
	<CAEc3jaBS6WUB_oViMp=qT_0RP+LPjZuEV8Qko9Jabs6qaeSibQ@mail.gmail.com>
From: "James Harper" <james.harper@bendigoit.com.au>
To: "Roderick Colenbrander" <thunderbird2k@gmail.com>,
	=?iso-8859-1?Q?Pasi_K=E4rkk=E4inen?= <pasik@iki.fi>
X-Really-From-Bendigo-IT: magichashvalue
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>, xen-devel@lists.xensource.com,
	Andreas Kinzler <ml-xen-devel@hfp.de>
Subject: Re: [Xen-devel] Questions about GPLPV stability tests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> 
> Does this feel like blktap issues? Or is it more likely that something else
> happened which causes blktap and the other things to fail?
> 

How easy is it to use another backend type without changing too much else?

James

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 01:52:47 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 01: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.xensource.com>)
	id 1RaHXC-0002IR-IX; Tue, 13 Dec 2011 01:51:58 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <james.harper@bendigoit.com.au>) id 1RaHXA-0002IM-9Z
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 01:51:56 +0000
X-Env-Sender: james.harper@bendigoit.com.au
X-Msg-Ref: server-7.tower-174.messagelabs.com!1323741059!5285376!1
X-Originating-IP: [203.16.224.4]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7801 invoked from network); 13 Dec 2011 01:51:02 -0000
Received: from smtp1.bendigoit.com.au (HELO smtp1.bendigoit.com.au)
	(203.16.224.4)
	by server-7.tower-174.messagelabs.com with AES256-SHA encrypted SMTP;
	13 Dec 2011 01:51:02 -0000
Received: from smtp2.bendigoit.com.au ([203.16.207.99]
	helo=mail.bendigoit.com.au)
	by smtp1.bendigoit.com.au with esmtp (Exim 4.69)
	(envelope-from <james.harper@bendigoit.com.au>)
	id 1RaHVm-00083K-TW; Tue, 13 Dec 2011 12:50:30 +1100
MIME-Version: 1.0
Content-class: urn:content-classes:message
X-MimeOLE: Produced By Microsoft Exchange V6.5
Date: Tue, 13 Dec 2011 12:50:30 +1100
Message-ID: <AEC6C66638C05B468B556EA548C1A77D01EE02DF@trantor>
In-Reply-To: <CAEc3jaBS6WUB_oViMp=qT_0RP+LPjZuEV8Qko9Jabs6qaeSibQ@mail.gmail.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Xen-devel] Questions about GPLPV stability tests
Thread-Index: Acy5Hsbke8mElGU7SluoOCtnc5igNgAGqiDw
References: <CAEc3jaAa7y8C2NNBn1=L3AhS0uuYFP6ze8o1cZ9yG2VYHx6qMA@mail.gmail.com><4ED5215D.1010403@hfp.de><20111129230212.GA23958@andromeda.dapyr.net><CAEc3jaAO0JhtOt6phQHwtE_A+NF7uGHGZ8uJv3BirEYybfVceg@mail.gmail.com><CAEc3jaACffpr9D1Hq_012vHAGhPLEfvsZjh7YyJ=Q-3FdtHS0Q@mail.gmail.com><CAPbh3rtOQ1HTPReqYcpE3vzk+-na0MTLLHZD15=Fg4yxB+ypaA@mail.gmail.com><CAEc3jaBdQKmVJToNZRf+25GtJXqGc274ieHf_yHKRJ+YOKWdgA@mail.gmail.com><20111208234624.GD32474@konrad-lan><CAEc3jaC9=HiMoxSYZmXKRzoFcMYRaT9jrX3m1ZQO+M8CrH35Fg@mail.gmail.com><CAEc3jaBBYBME0G3Ku_sTvzQz+oKQnpBPffA+bRUKxxRPABAeww@mail.gmail.com><20111211125247.GQ12984@reaktio.net><CAEc3jaCJ6wP27Ffm0wpOggWMgqcSNJiGxhtkszq6jgRD1nrZLg@mail.gmail.com>
	<CAEc3jaBS6WUB_oViMp=qT_0RP+LPjZuEV8Qko9Jabs6qaeSibQ@mail.gmail.com>
From: "James Harper" <james.harper@bendigoit.com.au>
To: "Roderick Colenbrander" <thunderbird2k@gmail.com>,
	=?iso-8859-1?Q?Pasi_K=E4rkk=E4inen?= <pasik@iki.fi>
X-Really-From-Bendigo-IT: magichashvalue
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>, xen-devel@lists.xensource.com,
	Andreas Kinzler <ml-xen-devel@hfp.de>
Subject: Re: [Xen-devel] Questions about GPLPV stability tests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> 
> Does this feel like blktap issues? Or is it more likely that something else
> happened which causes blktap and the other things to fail?
> 

How easy is it to use another backend type without changing too much else?

James

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 02:04:04 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 02:04:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaHiK-0002wL-TR; Tue, 13 Dec 2011 02:03:28 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.r.wilk@gmail.com>) id 1RaHiI-0002wG-LM
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 02:03:27 +0000
X-Env-Sender: konrad.r.wilk@gmail.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1323741736!58654427!1
X-Originating-IP: [209.85.216.43]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20728 invoked from network); 13 Dec 2011 02:02:17 -0000
Received: from mail-qw0-f43.google.com (HELO mail-qw0-f43.google.com)
	(209.85.216.43)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 02:02:17 -0000
Received: by qabg27 with SMTP id g27so22051306qab.9
	for <xen-devel@lists.xensource.com>;
	Mon, 12 Dec 2011 18:02:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:date:from:to:cc:subject:message-id:references:mime-version
	:content-type:content-disposition:in-reply-to:user-agent;
	bh=dBa8EsDXXi6wiOvmKbNFmfnhftQ8RWwgdNayiP0OgVo=;
	b=l0fMv5HOAj2sKU1MVPSSr9Lmjf63w74yepk3onXFI+u3Bey+HvANFon6vEItjsjf1E
	C+EtBvbIf5rNckYYxixq7puHOLUTpKpU4zBF0PBrNPugXhKRIA0G5YxQSbcHB7E+zsEM
	dgwJ5GgbIrlf9qNccTuX2LDg+i7w7s6u0DNcE=
Received: by 10.224.183.65 with SMTP id cf1mr376737qab.55.1323741754722;
	Mon, 12 Dec 2011 18:02:34 -0800 (PST)
Received: from konrad-lan (209-6-85-33.c3-0.smr-ubr2.sbo-smr.ma.cable.rcn.com.
	[209.6.85.33])
	by mx.google.com with ESMTPS id ft9sm5199560qab.20.2011.12.12.18.02.33
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 12 Dec 2011 18:02:33 -0800 (PST)
Date: Mon, 12 Dec 2011 21:02:30 -0500
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Roderick Colenbrander <thunderbird2k@gmail.com>
Message-ID: <20111213020229.GB2730@konrad-lan>
References: <CAEc3jaAO0JhtOt6phQHwtE_A+NF7uGHGZ8uJv3BirEYybfVceg@mail.gmail.com>
	<CAEc3jaACffpr9D1Hq_012vHAGhPLEfvsZjh7YyJ=Q-3FdtHS0Q@mail.gmail.com>
	<CAPbh3rtOQ1HTPReqYcpE3vzk+-na0MTLLHZD15=Fg4yxB+ypaA@mail.gmail.com>
	<CAEc3jaBdQKmVJToNZRf+25GtJXqGc274ieHf_yHKRJ+YOKWdgA@mail.gmail.com>
	<20111208234624.GD32474@konrad-lan>
	<CAEc3jaC9=HiMoxSYZmXKRzoFcMYRaT9jrX3m1ZQO+M8CrH35Fg@mail.gmail.com>
	<CAEc3jaBBYBME0G3Ku_sTvzQz+oKQnpBPffA+bRUKxxRPABAeww@mail.gmail.com>
	<20111211125247.GQ12984@reaktio.net>
	<CAEc3jaCJ6wP27Ffm0wpOggWMgqcSNJiGxhtkszq6jgRD1nrZLg@mail.gmail.com>
	<CAEc3jaBS6WUB_oViMp=qT_0RP+LPjZuEV8Qko9Jabs6qaeSibQ@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAEc3jaBS6WUB_oViMp=qT_0RP+LPjZuEV8Qko9Jabs6qaeSibQ@mail.gmail.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: xen-devel@lists.xensource.com, Andreas Kinzler <ml-xen-devel@hfp.de>
Subject: Re: [Xen-devel] Questions about GPLPV stability tests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> Today, yet another of my machines went down. To explain the setup, I'm
> running tests across a couple of similar machines. On some of the
> machines I updated to latest 2.6.32.x and Xen 4.1.x (and I upgrade
> every machine which goes down). The machine which just went down
> wasn't using the latest versions yet, but some more logging was
> enabled in 'dmesg'.
> 
> This box still had Xen 4.1.2 and 2.6.32.37. I'm not sure if the
> logging is too useful, yet but it may be of some use. The log output
> is mostly from the serial console. I looked at some log files on
> disks. Some files give clues, but some important log files didn't get
> synced to disk before bad things happened. The last timestamp I was
> able to find was at '16:13:55' which some of our own software wrote
> some line to its logs.
> 
> The few log files which got synced to disk tell that the VM started
> around 16:13:02 which matches PCIe device ownership to the VM:
> 
> (XEN) [2011-12-10 16:13:03] [VT-D]iommu.c:1501: d0:PCIe: unmap bdf = 3:0.0
> (XEN) [2011-12-10 16:13:03] [VT-D]iommu.c:1374: d1109:PCIe: map bdf = 3:0.0
> (XEN) [2011-12-10 16:13:03] [VT-D]io.c:304: d1109: bind: m_gsi=55
> g_gsi=32 device=4 intx=0
> (XEN) [2011-12-10 16:13:23] [VT-D]io.c:328: d1109: unbind: m_gsi=55
> g_gsi=32 device=4 intx=0
> (XEN) [2011-12-10 16:13:23] [VT-D]io.c:386: d1109 unmap: m_irq=55
> device=4 intx=0
> (XEN) [2011-12-10 16:13:23] [VT-D]io.c:304: d1109: bind: m_gsi=16
> g_gsi=32 device=4 intx=0
> 
> 
> We are using the tapdisk driver for disk 'xvdc' which is referred to
> as 'tdc' I guess. It is a copy-on-write

tdc would be what the disk is in dom 0.
> VHD disk which uses a raw disk image as its backing store. Apparently
> there are all sorts of read errors.
> Not sure if the read errors are too bad.
> 
> [905276.510737] blkback: ring-ref 15658, event-channel 13, protocol 1
> (unspecified, assuming native)
> [905276.512128] blkback: ring-ref 15658, event-channel 13, protocol 1
> (unspecified, assuming native)
> [905277.113215] block tdc: sector-size: 512 capacity: 118785
> [905277.215872] blkback: ring-ref 15775, event-channel 14, protocol 1
> (unspecified, assuming native)
> [905680.196850] end_request: I/O error, dev tdc, sector 45689
> [905680.197293] end_request: I/O error, dev tdc, sector 45689
> [905680.197624] end_request: I/O error, dev tdc, sector 45688
> [905680.197993] end_request: I/O error, dev tdc, sector 45696
> 
> More blktap issues hours later, right? The real problem must have
> happened much earlier then.

Any chance you can eliminate blktap from the picture? Can you use
blkback?

> 
> [912393.552881] blkback: ring-ref 15810, event-channel 13, protocol 1
> (unspecified, assuming native)
> [912394.101667] block tdc: sector-size: 512 capacity: 118785
> [912394.384715] blkback: ring-ref 15660, event-channel 14, protocol 1
> (unspecified, assuming native)
> [912402.433492] BUG: unable to handle kernel NULL pointer dereference
> at 00000000000002f0
> [912402.434077] IP: [<ffffffff81249ac2>] blktap_device_end_request+0x4e/0x68
> [912402.434384] PGD 384bb067 PUD 3a55f067 PMD 0
> [912402.434752] Oops: 0000 [#1] SMP
> [912402.435096] last sysfs file: /sys/devices/virtual/block/tdc/removable
> [912402.435363] CPU 2
> [912402.435653] Modules linked in: dm_snapshot dm_mod ipmi_si ipmi_devintf
> [912402.436092] Pid: 16994, comm: tapdisk2 Not tainted 2.6.32.37 #1 X8STi
> [912402.436595] RIP: e030:[<ffffffff81249ac2>]  [<ffffffff81249ac2>]
> blktap_device_end_request+0x4e/0x68
> [912402.437117] RSP: e02b:ffff8800616f9d08  EFLAGS: 00010046
> [912402.437380] RAX: 0000000000000000 RBX: ffff880014ef29b0 RCX:
> 0000000000000018
> [912402.437884] RDX: 0000000000000000 RSI: 0000000000000000 RDI:
> ffff88007fcebd58
> [912402.438368] RBP: 0000000000000000 R08: ffffffff816a9488 R09:
> ffff8800123af040
> [912402.438855] R10: 00000001365d23c7 R11: ffffffff810861e1 R12:
> ffff88007bea4e70
> [912402.439358] R13: ffff88007b8aa800 R14: 0000000000000000 R15:
> ffff880014ef29b0
> [912402.439848] FS:  00007fde3bbe2730(0000) GS:ffff880028070000(0000)
> knlGS:0000000000000000
> [912402.440341] CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
> [912402.440621] CR2: 00000000000002f0 CR3: 000000001f721000 CR4:
> 0000000000002660
> [912402.441102] DR0: 0000000000000000 DR1: 0000000000000000 DR2:
> 0000000000000000
> [912402.441583] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7:
> 0000000000000400
> [912402.442083] Process tapdisk2 (pid: 16994, threadinfo
> ffff8800616f8000, task ffff88007bab4ec0)
> [912402.442569] Stack:
> [912402.442825]  ffffea000185d038 0000000000000001 ffff88007bab4ec0
> 0000000000000000
> [912402.443199] <0> ffff88007b8aa800 ffffffff81248c3b 00000000000001ff
> 0000000000000000
> [912402.443871] <0> 00033e583f482159 000000000000e030 ffff88006f6da480
> 0000039f000003a0
> [912402.444793] Call Trace:
> [912402.445054]  [<ffffffff81248c3b>] ? blktap_ring_ioctl+0x137/0x228
> [912402.445326]  [<ffffffff810bea63>] ? core_sys_select+0x1ee/0x21e
> [912402.445599]  [<ffffffff810dc64f>] ? really_put_req+0x62/0x8f
> [912402.445871]  [<ffffffff8100e865>] ? xen_force_evtchn_callback+0x9/0xa
> [912402.446159]  [<ffffffff8100eef2>] ? check_events+0x12/0x20
> [912402.446434]  [<ffffffff810dc4e4>] ? aio_read_evt+0x26/0xe4
> [912402.446704]  [<ffffffff810dd71a>] ? sys_io_getevents+0x10e/0x356
> [912402.446984]  [<ffffffff810bcc47>] ? vfs_ioctl+0x56/0x6c
> [912402.447255]  [<ffffffff810bd133>] ? do_vfs_ioctl+0x460/0x49e
> [912402.447543]  [<ffffffff81059699>] ? getnstimeofday+0x55/0xaf
> [912402.447814]  [<ffffffff810bd1c2>] ? sys_ioctl+0x51/0x70
> [912402.448083]  [<ffffffff81011a02>] ? system_call_fastpath+0x16/0x1b
> [912402.448351] Code: e8 a5 f5 ff ff 49 8b 44 24 40 48 8b b8 f0 02 00
> 00 e8 a5 37 27 00 41 8b 54 24 60 44 89 f6 4c 89 e7 e8 85 13 f8 ff 49
> 8b 44 24 40 <48> 8b 80 f0 02 00 00 fe 00 ff 14 25 28 0d 6a 81 5b 5b 41
> 5c 41
> [912402.451398] RIP  [<ffffffff81249ac2>] blktap_device_end_request+0x4e/0x68
> [912402.451733]  RSP <ffff8800616f9d08>
> [912402.451997] CR2: 00000000000002f0
> [912402.452265] ---[ end trace f20c5f7e976fe78b ]---
> 
> Half a minute later I get tons of these:
> [912432.458625] ata6.00: exception Emask 0x0 SAct 0xf SErr 0x0 action 0x6 frozen

.. frozen..
> [912432.458893] ata6.00: failed command: READ FPDMA QUEUED
> [912432.459172] ata6.00: cmd 60/08:00:f2:13:e3/00:00:0d:00:00/40 tag 0
> ncq 4096 in
> 
> And tons of these:
> [912478.690536] sd 5:0:0:0: [sda] Unhandled error code
> [912478.690798] sd 5:0:0:0: [sda] Result: hostbyte=DID_BAD_TARGET
> driverbyte=DRIVER_OK
> [912478.691306] sd 5:0:0:0: [sda] CDB: Read(10): 28 00 00 e6 95 05 00 00 68 00
> 
> I wonder if we are having real SATA issues or whether this is somehow

That really looks to cause blktap to die when the command failed.


> caused by the 'real' problem which is tapdisk?
> 
> Finally I also get timeouts in the network code. I think these are
> just caused by the bad things happening.
> [912737.470673] WARNING: at net/sched/sch_generic.c:261
> dev_watchdog+0xd2/0x16e()
> [912737.471170] Hardware name: X8STi
> [912737.471426] NETDEV WATCHDOG: eth0 (e1000e): transmit queue 0 timed out

and then this time out..

> [912737.471686] Modules linked in: dm_snapshot dm_mod ipmi_si ipmi_devintf
> [912737.472106] Pid: 0, comm: swapper Tainted: G      D    2.6.32.37 #1
> [912737.472586] Call Trace:
> [912737.472838]  <IRQ>  [<ffffffff813c8e12>] ? dev_watchdog+0xd2/0x16e
> [912737.473130]  [<ffffffff813c8e12>] ? dev_watchdog+0xd2/0x16e
> [912737.473391]  [<ffffffff81040fb1>] ? warn_slowpath_common+0x77/0xa3
> [912737.473668]  [<ffffffff813c8d40>] ? dev_watchdog+0x0/0x16e
> [912737.473928]  [<ffffffff81041039 > ] ? warn_slowpk
> _dev_program_evt+ 0xe3/0x18c
> [90/0x60
> [912737.474988]  [<ffffffff8100e865>] ? xen_force_evtchn_callback+0x9/0xa
> [912737.480706]  [<ffffffff8100eef2>] ? check_events+0x12/0x20
> [912737.480965]  [<ffffffff813c8d15>] ? netif_tx_lock+0x3d/0x68
> [912737.481222]  [<ffffffff813c8d40>] ? dev_watchdog+0x0/0x16e
> [912737.481481]  [<ffffffff813b83a0>] ? netdev_drivername+0x3b/0x40
> [912737.481741]  [<ffffffff813c8e12>] ? dev_watchdog+0xd2/0x16e
> [912737.482015]  [<ffffffff81049614>] ? run_timer_softirq+0x16c/0x1d9
> [912737.482274]  [<ffffffff81078fb8>] ? handle_percpu_irq+0x4e/0x6a
> [912737.482534]  [<ffffffff81045bc8>] ? __do_softirq+0x91/0x116
> [912737.482794]  [<ffffffff81012b6c>] ? call_softirq+0x1c/0x30
> [912737.483052]  [<ffffffff810140e7>] ? do_softirq+0x3f/0x7c
> [912737.483324]  [<ffffffff81045a64>] ? irq_exit+0x36/0x76
> [912737.483584]  [<ffffffff8123b6ad>] ? xen_evtchn_do_upcall+0x33/0x42
> [912737.483843]  [<ffffffff81012bbe>] ? xen_do_hypervisor_callback+0x1e/0x30
> [912737.484101]  <EOI>  [<ffffffff8100eedf>] ? xen_restore_fl_direct_end+0x0/0x1
> [912737.484394]  [<ffffffff810093aa>] ? hypercall_page+0x3aa/0x1001
> [912737.484670]  [<ffffffff810093aa>] ? hypercall_page+0x3aa/0x1001
> [912737.484930]  [<ffffffff8100e8e3>] ? xen_safe_halt+0xc/0x15
> [912737.485188]  [<ffffffff81017f07>] ? default_idle+0x21/0x3d
> [912737.485447]  [<ffffffff81010df1>] ? cpu_idle+0x59/0x91
> [912737.485704] ---[ end trace f20c5f7e976fe78c ]---
> 
> 
> Does this feel like blktap issues? Or is it more likely that something
> else happened which causes blktap and the other things to fail?

It looks like the interrupts stopped. Perhaps you can run the C code
(attached) on the serial console and see _what_ (or perhaps _when_)
the interrupts stops (and also verify that the timeouts and 'frozen'
happen due to no interrupts being received).

There are a couple of bugs that were discovered in the interrupt code
(that had been there since 2.6.27!) that went to the stable tree - so
they should been backported to 2.6.32.x tree - but I honestly don't
recall the names. I can look them up tomorrow.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 02:04:04 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 02:04:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaHiK-0002wL-TR; Tue, 13 Dec 2011 02:03:28 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.r.wilk@gmail.com>) id 1RaHiI-0002wG-LM
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 02:03:27 +0000
X-Env-Sender: konrad.r.wilk@gmail.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1323741736!58654427!1
X-Originating-IP: [209.85.216.43]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20728 invoked from network); 13 Dec 2011 02:02:17 -0000
Received: from mail-qw0-f43.google.com (HELO mail-qw0-f43.google.com)
	(209.85.216.43)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 02:02:17 -0000
Received: by qabg27 with SMTP id g27so22051306qab.9
	for <xen-devel@lists.xensource.com>;
	Mon, 12 Dec 2011 18:02:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:date:from:to:cc:subject:message-id:references:mime-version
	:content-type:content-disposition:in-reply-to:user-agent;
	bh=dBa8EsDXXi6wiOvmKbNFmfnhftQ8RWwgdNayiP0OgVo=;
	b=l0fMv5HOAj2sKU1MVPSSr9Lmjf63w74yepk3onXFI+u3Bey+HvANFon6vEItjsjf1E
	C+EtBvbIf5rNckYYxixq7puHOLUTpKpU4zBF0PBrNPugXhKRIA0G5YxQSbcHB7E+zsEM
	dgwJ5GgbIrlf9qNccTuX2LDg+i7w7s6u0DNcE=
Received: by 10.224.183.65 with SMTP id cf1mr376737qab.55.1323741754722;
	Mon, 12 Dec 2011 18:02:34 -0800 (PST)
Received: from konrad-lan (209-6-85-33.c3-0.smr-ubr2.sbo-smr.ma.cable.rcn.com.
	[209.6.85.33])
	by mx.google.com with ESMTPS id ft9sm5199560qab.20.2011.12.12.18.02.33
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 12 Dec 2011 18:02:33 -0800 (PST)
Date: Mon, 12 Dec 2011 21:02:30 -0500
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Roderick Colenbrander <thunderbird2k@gmail.com>
Message-ID: <20111213020229.GB2730@konrad-lan>
References: <CAEc3jaAO0JhtOt6phQHwtE_A+NF7uGHGZ8uJv3BirEYybfVceg@mail.gmail.com>
	<CAEc3jaACffpr9D1Hq_012vHAGhPLEfvsZjh7YyJ=Q-3FdtHS0Q@mail.gmail.com>
	<CAPbh3rtOQ1HTPReqYcpE3vzk+-na0MTLLHZD15=Fg4yxB+ypaA@mail.gmail.com>
	<CAEc3jaBdQKmVJToNZRf+25GtJXqGc274ieHf_yHKRJ+YOKWdgA@mail.gmail.com>
	<20111208234624.GD32474@konrad-lan>
	<CAEc3jaC9=HiMoxSYZmXKRzoFcMYRaT9jrX3m1ZQO+M8CrH35Fg@mail.gmail.com>
	<CAEc3jaBBYBME0G3Ku_sTvzQz+oKQnpBPffA+bRUKxxRPABAeww@mail.gmail.com>
	<20111211125247.GQ12984@reaktio.net>
	<CAEc3jaCJ6wP27Ffm0wpOggWMgqcSNJiGxhtkszq6jgRD1nrZLg@mail.gmail.com>
	<CAEc3jaBS6WUB_oViMp=qT_0RP+LPjZuEV8Qko9Jabs6qaeSibQ@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAEc3jaBS6WUB_oViMp=qT_0RP+LPjZuEV8Qko9Jabs6qaeSibQ@mail.gmail.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: xen-devel@lists.xensource.com, Andreas Kinzler <ml-xen-devel@hfp.de>
Subject: Re: [Xen-devel] Questions about GPLPV stability tests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> Today, yet another of my machines went down. To explain the setup, I'm
> running tests across a couple of similar machines. On some of the
> machines I updated to latest 2.6.32.x and Xen 4.1.x (and I upgrade
> every machine which goes down). The machine which just went down
> wasn't using the latest versions yet, but some more logging was
> enabled in 'dmesg'.
> 
> This box still had Xen 4.1.2 and 2.6.32.37. I'm not sure if the
> logging is too useful, yet but it may be of some use. The log output
> is mostly from the serial console. I looked at some log files on
> disks. Some files give clues, but some important log files didn't get
> synced to disk before bad things happened. The last timestamp I was
> able to find was at '16:13:55' which some of our own software wrote
> some line to its logs.
> 
> The few log files which got synced to disk tell that the VM started
> around 16:13:02 which matches PCIe device ownership to the VM:
> 
> (XEN) [2011-12-10 16:13:03] [VT-D]iommu.c:1501: d0:PCIe: unmap bdf = 3:0.0
> (XEN) [2011-12-10 16:13:03] [VT-D]iommu.c:1374: d1109:PCIe: map bdf = 3:0.0
> (XEN) [2011-12-10 16:13:03] [VT-D]io.c:304: d1109: bind: m_gsi=55
> g_gsi=32 device=4 intx=0
> (XEN) [2011-12-10 16:13:23] [VT-D]io.c:328: d1109: unbind: m_gsi=55
> g_gsi=32 device=4 intx=0
> (XEN) [2011-12-10 16:13:23] [VT-D]io.c:386: d1109 unmap: m_irq=55
> device=4 intx=0
> (XEN) [2011-12-10 16:13:23] [VT-D]io.c:304: d1109: bind: m_gsi=16
> g_gsi=32 device=4 intx=0
> 
> 
> We are using the tapdisk driver for disk 'xvdc' which is referred to
> as 'tdc' I guess. It is a copy-on-write

tdc would be what the disk is in dom 0.
> VHD disk which uses a raw disk image as its backing store. Apparently
> there are all sorts of read errors.
> Not sure if the read errors are too bad.
> 
> [905276.510737] blkback: ring-ref 15658, event-channel 13, protocol 1
> (unspecified, assuming native)
> [905276.512128] blkback: ring-ref 15658, event-channel 13, protocol 1
> (unspecified, assuming native)
> [905277.113215] block tdc: sector-size: 512 capacity: 118785
> [905277.215872] blkback: ring-ref 15775, event-channel 14, protocol 1
> (unspecified, assuming native)
> [905680.196850] end_request: I/O error, dev tdc, sector 45689
> [905680.197293] end_request: I/O error, dev tdc, sector 45689
> [905680.197624] end_request: I/O error, dev tdc, sector 45688
> [905680.197993] end_request: I/O error, dev tdc, sector 45696
> 
> More blktap issues hours later, right? The real problem must have
> happened much earlier then.

Any chance you can eliminate blktap from the picture? Can you use
blkback?

> 
> [912393.552881] blkback: ring-ref 15810, event-channel 13, protocol 1
> (unspecified, assuming native)
> [912394.101667] block tdc: sector-size: 512 capacity: 118785
> [912394.384715] blkback: ring-ref 15660, event-channel 14, protocol 1
> (unspecified, assuming native)
> [912402.433492] BUG: unable to handle kernel NULL pointer dereference
> at 00000000000002f0
> [912402.434077] IP: [<ffffffff81249ac2>] blktap_device_end_request+0x4e/0x68
> [912402.434384] PGD 384bb067 PUD 3a55f067 PMD 0
> [912402.434752] Oops: 0000 [#1] SMP
> [912402.435096] last sysfs file: /sys/devices/virtual/block/tdc/removable
> [912402.435363] CPU 2
> [912402.435653] Modules linked in: dm_snapshot dm_mod ipmi_si ipmi_devintf
> [912402.436092] Pid: 16994, comm: tapdisk2 Not tainted 2.6.32.37 #1 X8STi
> [912402.436595] RIP: e030:[<ffffffff81249ac2>]  [<ffffffff81249ac2>]
> blktap_device_end_request+0x4e/0x68
> [912402.437117] RSP: e02b:ffff8800616f9d08  EFLAGS: 00010046
> [912402.437380] RAX: 0000000000000000 RBX: ffff880014ef29b0 RCX:
> 0000000000000018
> [912402.437884] RDX: 0000000000000000 RSI: 0000000000000000 RDI:
> ffff88007fcebd58
> [912402.438368] RBP: 0000000000000000 R08: ffffffff816a9488 R09:
> ffff8800123af040
> [912402.438855] R10: 00000001365d23c7 R11: ffffffff810861e1 R12:
> ffff88007bea4e70
> [912402.439358] R13: ffff88007b8aa800 R14: 0000000000000000 R15:
> ffff880014ef29b0
> [912402.439848] FS:  00007fde3bbe2730(0000) GS:ffff880028070000(0000)
> knlGS:0000000000000000
> [912402.440341] CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
> [912402.440621] CR2: 00000000000002f0 CR3: 000000001f721000 CR4:
> 0000000000002660
> [912402.441102] DR0: 0000000000000000 DR1: 0000000000000000 DR2:
> 0000000000000000
> [912402.441583] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7:
> 0000000000000400
> [912402.442083] Process tapdisk2 (pid: 16994, threadinfo
> ffff8800616f8000, task ffff88007bab4ec0)
> [912402.442569] Stack:
> [912402.442825]  ffffea000185d038 0000000000000001 ffff88007bab4ec0
> 0000000000000000
> [912402.443199] <0> ffff88007b8aa800 ffffffff81248c3b 00000000000001ff
> 0000000000000000
> [912402.443871] <0> 00033e583f482159 000000000000e030 ffff88006f6da480
> 0000039f000003a0
> [912402.444793] Call Trace:
> [912402.445054]  [<ffffffff81248c3b>] ? blktap_ring_ioctl+0x137/0x228
> [912402.445326]  [<ffffffff810bea63>] ? core_sys_select+0x1ee/0x21e
> [912402.445599]  [<ffffffff810dc64f>] ? really_put_req+0x62/0x8f
> [912402.445871]  [<ffffffff8100e865>] ? xen_force_evtchn_callback+0x9/0xa
> [912402.446159]  [<ffffffff8100eef2>] ? check_events+0x12/0x20
> [912402.446434]  [<ffffffff810dc4e4>] ? aio_read_evt+0x26/0xe4
> [912402.446704]  [<ffffffff810dd71a>] ? sys_io_getevents+0x10e/0x356
> [912402.446984]  [<ffffffff810bcc47>] ? vfs_ioctl+0x56/0x6c
> [912402.447255]  [<ffffffff810bd133>] ? do_vfs_ioctl+0x460/0x49e
> [912402.447543]  [<ffffffff81059699>] ? getnstimeofday+0x55/0xaf
> [912402.447814]  [<ffffffff810bd1c2>] ? sys_ioctl+0x51/0x70
> [912402.448083]  [<ffffffff81011a02>] ? system_call_fastpath+0x16/0x1b
> [912402.448351] Code: e8 a5 f5 ff ff 49 8b 44 24 40 48 8b b8 f0 02 00
> 00 e8 a5 37 27 00 41 8b 54 24 60 44 89 f6 4c 89 e7 e8 85 13 f8 ff 49
> 8b 44 24 40 <48> 8b 80 f0 02 00 00 fe 00 ff 14 25 28 0d 6a 81 5b 5b 41
> 5c 41
> [912402.451398] RIP  [<ffffffff81249ac2>] blktap_device_end_request+0x4e/0x68
> [912402.451733]  RSP <ffff8800616f9d08>
> [912402.451997] CR2: 00000000000002f0
> [912402.452265] ---[ end trace f20c5f7e976fe78b ]---
> 
> Half a minute later I get tons of these:
> [912432.458625] ata6.00: exception Emask 0x0 SAct 0xf SErr 0x0 action 0x6 frozen

.. frozen..
> [912432.458893] ata6.00: failed command: READ FPDMA QUEUED
> [912432.459172] ata6.00: cmd 60/08:00:f2:13:e3/00:00:0d:00:00/40 tag 0
> ncq 4096 in
> 
> And tons of these:
> [912478.690536] sd 5:0:0:0: [sda] Unhandled error code
> [912478.690798] sd 5:0:0:0: [sda] Result: hostbyte=DID_BAD_TARGET
> driverbyte=DRIVER_OK
> [912478.691306] sd 5:0:0:0: [sda] CDB: Read(10): 28 00 00 e6 95 05 00 00 68 00
> 
> I wonder if we are having real SATA issues or whether this is somehow

That really looks to cause blktap to die when the command failed.


> caused by the 'real' problem which is tapdisk?
> 
> Finally I also get timeouts in the network code. I think these are
> just caused by the bad things happening.
> [912737.470673] WARNING: at net/sched/sch_generic.c:261
> dev_watchdog+0xd2/0x16e()
> [912737.471170] Hardware name: X8STi
> [912737.471426] NETDEV WATCHDOG: eth0 (e1000e): transmit queue 0 timed out

and then this time out..

> [912737.471686] Modules linked in: dm_snapshot dm_mod ipmi_si ipmi_devintf
> [912737.472106] Pid: 0, comm: swapper Tainted: G      D    2.6.32.37 #1
> [912737.472586] Call Trace:
> [912737.472838]  <IRQ>  [<ffffffff813c8e12>] ? dev_watchdog+0xd2/0x16e
> [912737.473130]  [<ffffffff813c8e12>] ? dev_watchdog+0xd2/0x16e
> [912737.473391]  [<ffffffff81040fb1>] ? warn_slowpath_common+0x77/0xa3
> [912737.473668]  [<ffffffff813c8d40>] ? dev_watchdog+0x0/0x16e
> [912737.473928]  [<ffffffff81041039 > ] ? warn_slowpk
> _dev_program_evt+ 0xe3/0x18c
> [90/0x60
> [912737.474988]  [<ffffffff8100e865>] ? xen_force_evtchn_callback+0x9/0xa
> [912737.480706]  [<ffffffff8100eef2>] ? check_events+0x12/0x20
> [912737.480965]  [<ffffffff813c8d15>] ? netif_tx_lock+0x3d/0x68
> [912737.481222]  [<ffffffff813c8d40>] ? dev_watchdog+0x0/0x16e
> [912737.481481]  [<ffffffff813b83a0>] ? netdev_drivername+0x3b/0x40
> [912737.481741]  [<ffffffff813c8e12>] ? dev_watchdog+0xd2/0x16e
> [912737.482015]  [<ffffffff81049614>] ? run_timer_softirq+0x16c/0x1d9
> [912737.482274]  [<ffffffff81078fb8>] ? handle_percpu_irq+0x4e/0x6a
> [912737.482534]  [<ffffffff81045bc8>] ? __do_softirq+0x91/0x116
> [912737.482794]  [<ffffffff81012b6c>] ? call_softirq+0x1c/0x30
> [912737.483052]  [<ffffffff810140e7>] ? do_softirq+0x3f/0x7c
> [912737.483324]  [<ffffffff81045a64>] ? irq_exit+0x36/0x76
> [912737.483584]  [<ffffffff8123b6ad>] ? xen_evtchn_do_upcall+0x33/0x42
> [912737.483843]  [<ffffffff81012bbe>] ? xen_do_hypervisor_callback+0x1e/0x30
> [912737.484101]  <EOI>  [<ffffffff8100eedf>] ? xen_restore_fl_direct_end+0x0/0x1
> [912737.484394]  [<ffffffff810093aa>] ? hypercall_page+0x3aa/0x1001
> [912737.484670]  [<ffffffff810093aa>] ? hypercall_page+0x3aa/0x1001
> [912737.484930]  [<ffffffff8100e8e3>] ? xen_safe_halt+0xc/0x15
> [912737.485188]  [<ffffffff81017f07>] ? default_idle+0x21/0x3d
> [912737.485447]  [<ffffffff81010df1>] ? cpu_idle+0x59/0x91
> [912737.485704] ---[ end trace f20c5f7e976fe78c ]---
> 
> 
> Does this feel like blktap issues? Or is it more likely that something
> else happened which causes blktap and the other things to fail?

It looks like the interrupts stopped. Perhaps you can run the C code
(attached) on the serial console and see _what_ (or perhaps _when_)
the interrupts stops (and also verify that the timeouts and 'frozen'
happen due to no interrupts being received).

There are a couple of bugs that were discovered in the interrupt code
(that had been there since 2.6.27!) that went to the stable tree - so
they should been backported to 2.6.32.x tree - but I honestly don't
recall the names. I can look them up tomorrow.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 02:07:11 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 02:07:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaHlS-00032X-Ih; Tue, 13 Dec 2011 02:06:42 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <thunderbird2k@gmail.com>) id 1RaHlQ-00032F-QH
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 02:06:41 +0000
X-Env-Sender: thunderbird2k@gmail.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1323741945!5106784!1
X-Originating-IP: [209.85.161.171]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22650 invoked from network); 13 Dec 2011 02:05:47 -0000
Received: from mail-gx0-f171.google.com (HELO mail-gx0-f171.google.com)
	(209.85.161.171)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 02:05:47 -0000
Received: by ggnh4 with SMTP id h4so57502998ggn.30
	for <xen-devel@lists.xensource.com>;
	Mon, 12 Dec 2011 18:05:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=dktS2uOSjCqY0SHmo031jl1kWFuC7hr/NyAYCyOnqFo=;
	b=fd2kZrJ/JdMVJx5buGm/IS3zFL0mH5SCpqptyuSogsGONrIMILQdcDJtDukvhHhZ3E
	NLaeWwzdzv4TzcsuVFdEbyWGEff0YSmRXj7TYlDpbw2zg1dYsxvAMQcfWWL8o6TlXf6+
	CLXM6piEcYjkcUCJ+lUEVpIb5mWCOvO2Ufs7s=
MIME-Version: 1.0
Received: by 10.101.182.28 with SMTP id j28mr186437anp.46.1323741535079; Mon,
	12 Dec 2011 17:58:55 -0800 (PST)
Received: by 10.100.48.10 with HTTP; Mon, 12 Dec 2011 17:58:55 -0800 (PST)
In-Reply-To: <AEC6C66638C05B468B556EA548C1A77D01EE02DF@trantor>
References: <CAEc3jaAa7y8C2NNBn1=L3AhS0uuYFP6ze8o1cZ9yG2VYHx6qMA@mail.gmail.com>
	<4ED5215D.1010403@hfp.de>
	<20111129230212.GA23958@andromeda.dapyr.net>
	<CAEc3jaAO0JhtOt6phQHwtE_A+NF7uGHGZ8uJv3BirEYybfVceg@mail.gmail.com>
	<CAEc3jaACffpr9D1Hq_012vHAGhPLEfvsZjh7YyJ=Q-3FdtHS0Q@mail.gmail.com>
	<CAPbh3rtOQ1HTPReqYcpE3vzk+-na0MTLLHZD15=Fg4yxB+ypaA@mail.gmail.com>
	<CAEc3jaBdQKmVJToNZRf+25GtJXqGc274ieHf_yHKRJ+YOKWdgA@mail.gmail.com>
	<20111208234624.GD32474@konrad-lan>
	<CAEc3jaC9=HiMoxSYZmXKRzoFcMYRaT9jrX3m1ZQO+M8CrH35Fg@mail.gmail.com>
	<CAEc3jaBBYBME0G3Ku_sTvzQz+oKQnpBPffA+bRUKxxRPABAeww@mail.gmail.com>
	<20111211125247.GQ12984@reaktio.net>
	<CAEc3jaCJ6wP27Ffm0wpOggWMgqcSNJiGxhtkszq6jgRD1nrZLg@mail.gmail.com>
	<CAEc3jaBS6WUB_oViMp=qT_0RP+LPjZuEV8Qko9Jabs6qaeSibQ@mail.gmail.com>
	<AEC6C66638C05B468B556EA548C1A77D01EE02DF@trantor>
Date: Mon, 12 Dec 2011 17:58:55 -0800
Message-ID: <CAEc3jaDo_GGNx2yCyFwTvtGOS-h8Y4USGAy6Mt3OL-GEn+1=Lw@mail.gmail.com>
From: Roderick Colenbrander <thunderbird2k@gmail.com>
To: James Harper <james.harper@bendigoit.com.au>
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>, xen-devel@lists.xensource.com,
	Andreas Kinzler <ml-xen-devel@hfp.de>
Subject: Re: [Xen-devel] Questions about GPLPV stability tests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Dec 12, 2011 at 5:50 PM, James Harper
<james.harper@bendigoit.com.au> wrote:
>>
>> Does this feel like blktap issues? Or is it more likely that something else
>> happened which causes blktap and the other things to fail?
>>
>
> How easy is it to use another backend type without changing too much else?
>
> James

I may be able to change the tapdisk based disk to a different format
(from vhd to qcow) to force qdisk. Looking at that now.

Roderick

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 02:07:11 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 02:07:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaHlS-00032X-Ih; Tue, 13 Dec 2011 02:06:42 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <thunderbird2k@gmail.com>) id 1RaHlQ-00032F-QH
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 02:06:41 +0000
X-Env-Sender: thunderbird2k@gmail.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1323741945!5106784!1
X-Originating-IP: [209.85.161.171]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22650 invoked from network); 13 Dec 2011 02:05:47 -0000
Received: from mail-gx0-f171.google.com (HELO mail-gx0-f171.google.com)
	(209.85.161.171)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 02:05:47 -0000
Received: by ggnh4 with SMTP id h4so57502998ggn.30
	for <xen-devel@lists.xensource.com>;
	Mon, 12 Dec 2011 18:05:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=dktS2uOSjCqY0SHmo031jl1kWFuC7hr/NyAYCyOnqFo=;
	b=fd2kZrJ/JdMVJx5buGm/IS3zFL0mH5SCpqptyuSogsGONrIMILQdcDJtDukvhHhZ3E
	NLaeWwzdzv4TzcsuVFdEbyWGEff0YSmRXj7TYlDpbw2zg1dYsxvAMQcfWWL8o6TlXf6+
	CLXM6piEcYjkcUCJ+lUEVpIb5mWCOvO2Ufs7s=
MIME-Version: 1.0
Received: by 10.101.182.28 with SMTP id j28mr186437anp.46.1323741535079; Mon,
	12 Dec 2011 17:58:55 -0800 (PST)
Received: by 10.100.48.10 with HTTP; Mon, 12 Dec 2011 17:58:55 -0800 (PST)
In-Reply-To: <AEC6C66638C05B468B556EA548C1A77D01EE02DF@trantor>
References: <CAEc3jaAa7y8C2NNBn1=L3AhS0uuYFP6ze8o1cZ9yG2VYHx6qMA@mail.gmail.com>
	<4ED5215D.1010403@hfp.de>
	<20111129230212.GA23958@andromeda.dapyr.net>
	<CAEc3jaAO0JhtOt6phQHwtE_A+NF7uGHGZ8uJv3BirEYybfVceg@mail.gmail.com>
	<CAEc3jaACffpr9D1Hq_012vHAGhPLEfvsZjh7YyJ=Q-3FdtHS0Q@mail.gmail.com>
	<CAPbh3rtOQ1HTPReqYcpE3vzk+-na0MTLLHZD15=Fg4yxB+ypaA@mail.gmail.com>
	<CAEc3jaBdQKmVJToNZRf+25GtJXqGc274ieHf_yHKRJ+YOKWdgA@mail.gmail.com>
	<20111208234624.GD32474@konrad-lan>
	<CAEc3jaC9=HiMoxSYZmXKRzoFcMYRaT9jrX3m1ZQO+M8CrH35Fg@mail.gmail.com>
	<CAEc3jaBBYBME0G3Ku_sTvzQz+oKQnpBPffA+bRUKxxRPABAeww@mail.gmail.com>
	<20111211125247.GQ12984@reaktio.net>
	<CAEc3jaCJ6wP27Ffm0wpOggWMgqcSNJiGxhtkszq6jgRD1nrZLg@mail.gmail.com>
	<CAEc3jaBS6WUB_oViMp=qT_0RP+LPjZuEV8Qko9Jabs6qaeSibQ@mail.gmail.com>
	<AEC6C66638C05B468B556EA548C1A77D01EE02DF@trantor>
Date: Mon, 12 Dec 2011 17:58:55 -0800
Message-ID: <CAEc3jaDo_GGNx2yCyFwTvtGOS-h8Y4USGAy6Mt3OL-GEn+1=Lw@mail.gmail.com>
From: Roderick Colenbrander <thunderbird2k@gmail.com>
To: James Harper <james.harper@bendigoit.com.au>
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>, xen-devel@lists.xensource.com,
	Andreas Kinzler <ml-xen-devel@hfp.de>
Subject: Re: [Xen-devel] Questions about GPLPV stability tests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Dec 12, 2011 at 5:50 PM, James Harper
<james.harper@bendigoit.com.au> wrote:
>>
>> Does this feel like blktap issues? Or is it more likely that something else
>> happened which causes blktap and the other things to fail?
>>
>
> How easy is it to use another backend type without changing too much else?
>
> James

I may be able to change the tapdisk based disk to a different format
(from vhd to qcow) to force qdisk. Looking at that now.

Roderick

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 02:26:31 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 02:26:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaI4B-0003ZG-0j; Tue, 13 Dec 2011 02:26:03 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <hui.lv@intel.com>) id 1RaI49-0003Z3-Lq
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 02:26:01 +0000
X-Env-Sender: hui.lv@intel.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1323743107!8532707!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDI5ODMwMQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14417 invoked from network); 13 Dec 2011 02:25:07 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-2.tower-216.messagelabs.com with SMTP;
	13 Dec 2011 02:25:07 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga101.fm.intel.com with ESMTP; 12 Dec 2011 18:25:06 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="101484784"
Received: from pgsmsx601.gar.corp.intel.com ([10.221.43.69])
	by fmsmga002.fm.intel.com with ESMTP; 12 Dec 2011 18:25:04 -0800
Received: from pgsmsx102.gar.corp.intel.com (10.221.44.80) by
	pgsmsx601.gar.corp.intel.com (10.221.43.69) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Tue, 13 Dec 2011 10:24:26 +0800
Received: from shsmsx601.ccr.corp.intel.com (10.239.4.112) by
	PGSMSX102.gar.corp.intel.com (10.221.44.80) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Tue, 13 Dec 2011 10:24:25 +0800
Received: from shsmsx502.ccr.corp.intel.com ([10.239.4.96]) by
	shsmsx601.ccr.corp.intel.com ([10.239.4.112]) with mapi;
	Tue, 13 Dec 2011 10:24:09 +0800
From: "Lv, Hui" <hui.lv@intel.com>
To: George Dunlap <George.Dunlap@eu.citrix.com>
Date: Tue, 13 Dec 2011 10:24:09 +0800
Thread-Topic: [Xen-devel] [PATCH] scheduler rate controller
Thread-Index: Acy4w0rrjGBdKpm7Q2mZu+955PrCVgAefFcw
Message-ID: <C10D3FB0CD45994C8A51FEC1227CE22F3766B3C738@shsmsx502.ccr.corp.intel.com>
References: <C10D3FB0CD45994C8A51FEC1227CE22F340768D793@shsmsx502.ccr.corp.intel.com>
	<CAFLBxZZ9nqeb7CVqTZCsEtJRjgGMTHF2Ak929kvauj2KUFSOyg@mail.gmail.com>
	<C10D3FB0CD45994C8A51FEC1227CE22F3428CB5EF9@shsmsx502.ccr.corp.intel.com>
	<1319789425.19320.12.camel@Abyss>
	<C10D3FB0CD45994C8A51FEC1227CE22F3428CB61F2@shsmsx502.ccr.corp.intel.com>
	<1319796584.19320.31.camel@Abyss>	<1319818714.21033.414.camel@elijah>
	<C10D3FB0CD45994C8A51FEC1227CE22F34B3905D03@shsmsx502.ccr.corp.intel.com>
	<CAFLBxZa5v_YgnC1LTa4a5wis4h6eQPijCAfUDLDsR4ucMuBXWg@mail.gmail.com>
	<C10D3FB0CD45994C8A51FEC1227CE22F37499C2733@shsmsx502.ccr.corp.intel.com>
	<CAFLBxZZ-F2hNTNHtiBCuQ0tVqJDe6btPnvofHK4KaDDQz8Rxtw@mail.gmail.com>
	<C10D3FB0CD45994C8A51FEC1227CE22F37666D5EA5@shsmsx502.ccr.corp.intel.com>
	<CAFLBxZZtpwncpEXJ9Atv0=isT_5FNJi8sEhZbAZnsJFbwvZpjw@mail.gmail.com>
In-Reply-To: <CAFLBxZZtpwncpEXJ9Atv0=isT_5FNJi8sEhZbAZnsJFbwvZpjw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "Tian, Kevin" <kevin.tian@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, "Dong, 
	Eddie" <eddie.dong@intel.com>, George Dunlap <george.dunlap@citrix.com>,
	"Duan, Jiangang" <jiangang.duan@intel.com>,
	Dario Faggioli <raistlin@linux.it>
Subject: Re: [Xen-devel] [PATCH] scheduler rate controller
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> Thanks Hui, those are good results.  Just one question: What's QoS
> supposed to measure?  Is this a metric that SPECVirt reports?  Is
> higher or lower better?
> 
Yes, it was reported by SPECvirt. The lower, the better.
 
> The patch looks good, but there's one last nitpick: Several of your
> lines have hard tab characters in them; tabs are officially verboten
> in the Xen code.  Please replace them with spaces.  After that, I
> think we're ready to check it in.
>
Great!!
 
> the command to use is as follows:
> 
> xentrace -D -e 0x21000 -T 30 /path/to/file.trace
> 
> This will take *just* scheduling traces for 30 seconds.  If you could
> run it when the benchmark is going full throttle, that should help me
> get an idea what the scheduling looks like.
> 
Yes, I'd like to do this. 
Hope the data size is not very large. Since, for full throttle condition, Xen hypervisor occupied a large CPU time (around 20%). 
Correspondingly, the trace data is very big.
I'll let you know when data is ready.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 02:26:31 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 02:26:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaI4B-0003ZG-0j; Tue, 13 Dec 2011 02:26:03 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <hui.lv@intel.com>) id 1RaI49-0003Z3-Lq
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 02:26:01 +0000
X-Env-Sender: hui.lv@intel.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1323743107!8532707!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDI5ODMwMQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14417 invoked from network); 13 Dec 2011 02:25:07 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-2.tower-216.messagelabs.com with SMTP;
	13 Dec 2011 02:25:07 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga101.fm.intel.com with ESMTP; 12 Dec 2011 18:25:06 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="101484784"
Received: from pgsmsx601.gar.corp.intel.com ([10.221.43.69])
	by fmsmga002.fm.intel.com with ESMTP; 12 Dec 2011 18:25:04 -0800
Received: from pgsmsx102.gar.corp.intel.com (10.221.44.80) by
	pgsmsx601.gar.corp.intel.com (10.221.43.69) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Tue, 13 Dec 2011 10:24:26 +0800
Received: from shsmsx601.ccr.corp.intel.com (10.239.4.112) by
	PGSMSX102.gar.corp.intel.com (10.221.44.80) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Tue, 13 Dec 2011 10:24:25 +0800
Received: from shsmsx502.ccr.corp.intel.com ([10.239.4.96]) by
	shsmsx601.ccr.corp.intel.com ([10.239.4.112]) with mapi;
	Tue, 13 Dec 2011 10:24:09 +0800
From: "Lv, Hui" <hui.lv@intel.com>
To: George Dunlap <George.Dunlap@eu.citrix.com>
Date: Tue, 13 Dec 2011 10:24:09 +0800
Thread-Topic: [Xen-devel] [PATCH] scheduler rate controller
Thread-Index: Acy4w0rrjGBdKpm7Q2mZu+955PrCVgAefFcw
Message-ID: <C10D3FB0CD45994C8A51FEC1227CE22F3766B3C738@shsmsx502.ccr.corp.intel.com>
References: <C10D3FB0CD45994C8A51FEC1227CE22F340768D793@shsmsx502.ccr.corp.intel.com>
	<CAFLBxZZ9nqeb7CVqTZCsEtJRjgGMTHF2Ak929kvauj2KUFSOyg@mail.gmail.com>
	<C10D3FB0CD45994C8A51FEC1227CE22F3428CB5EF9@shsmsx502.ccr.corp.intel.com>
	<1319789425.19320.12.camel@Abyss>
	<C10D3FB0CD45994C8A51FEC1227CE22F3428CB61F2@shsmsx502.ccr.corp.intel.com>
	<1319796584.19320.31.camel@Abyss>	<1319818714.21033.414.camel@elijah>
	<C10D3FB0CD45994C8A51FEC1227CE22F34B3905D03@shsmsx502.ccr.corp.intel.com>
	<CAFLBxZa5v_YgnC1LTa4a5wis4h6eQPijCAfUDLDsR4ucMuBXWg@mail.gmail.com>
	<C10D3FB0CD45994C8A51FEC1227CE22F37499C2733@shsmsx502.ccr.corp.intel.com>
	<CAFLBxZZ-F2hNTNHtiBCuQ0tVqJDe6btPnvofHK4KaDDQz8Rxtw@mail.gmail.com>
	<C10D3FB0CD45994C8A51FEC1227CE22F37666D5EA5@shsmsx502.ccr.corp.intel.com>
	<CAFLBxZZtpwncpEXJ9Atv0=isT_5FNJi8sEhZbAZnsJFbwvZpjw@mail.gmail.com>
In-Reply-To: <CAFLBxZZtpwncpEXJ9Atv0=isT_5FNJi8sEhZbAZnsJFbwvZpjw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "Tian, Kevin" <kevin.tian@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, "Dong, 
	Eddie" <eddie.dong@intel.com>, George Dunlap <george.dunlap@citrix.com>,
	"Duan, Jiangang" <jiangang.duan@intel.com>,
	Dario Faggioli <raistlin@linux.it>
Subject: Re: [Xen-devel] [PATCH] scheduler rate controller
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> Thanks Hui, those are good results.  Just one question: What's QoS
> supposed to measure?  Is this a metric that SPECVirt reports?  Is
> higher or lower better?
> 
Yes, it was reported by SPECvirt. The lower, the better.
 
> The patch looks good, but there's one last nitpick: Several of your
> lines have hard tab characters in them; tabs are officially verboten
> in the Xen code.  Please replace them with spaces.  After that, I
> think we're ready to check it in.
>
Great!!
 
> the command to use is as follows:
> 
> xentrace -D -e 0x21000 -T 30 /path/to/file.trace
> 
> This will take *just* scheduling traces for 30 seconds.  If you could
> run it when the benchmark is going full throttle, that should help me
> get an idea what the scheduling looks like.
> 
Yes, I'd like to do this. 
Hope the data size is not very large. Since, for full throttle condition, Xen hypervisor occupied a large CPU time (around 20%). 
Correspondingly, the trace data is very big.
I'll let you know when data is ready.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 03:44:39 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 03:44:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaJHg-0004OA-7Y; Tue, 13 Dec 2011 03:44:04 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RaJHe-0004Nw-Ha
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 03:44:02 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-7.tower-182.messagelabs.com!1323747787!6914982!1
X-Originating-IP: [208.97.132.66]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi42NiA9PiAxNTE1Mg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19763 invoked from network); 13 Dec 2011 03:43:08 -0000
Received: from caiajhbdcagg.dreamhost.com (HELO homiemail-a21.g.dreamhost.com)
	(208.97.132.66) by server-7.tower-182.messagelabs.com with SMTP;
	13 Dec 2011 03:43:08 -0000
Received: from homiemail-a21.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTP id 0E40030006C;
	Mon, 12 Dec 2011 19:43:06 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=QUDibi03pHmNwGBg0ox/oucFVVslP8jWrDmkip520xdu
	PxRHZ8xs2lsLTugW7CTHVhMMufPzjuWZzIFLSCzkf1Jlqsm7dnbKqbRA9wnXHIfL
	IVZWLR6TkdxE3laScSxnQW/t9iWgu3Sg/ubAONkH2gPFN2SQGgCVpMQ5KMuCTr0=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=1kYkW9/9kszxPiNukE7gCM8fTrE=; b=LdDpszrK
	eKyaZzP+TFdQXM+/nFxKjNJGWpW8mpQKpJN9KmvbvhvcaxGqVgWE1l/9Ua01X6y0
	vZFI4u8QoDPgsckdVH50IwV19LbdyBmRpPcNqu/FDz4D9tunitLPawYMqRUo8FVy
	hIFURm1H0t3P7PpoHEOW7FxLbOSKiw3GhiQ=
Received: from webmail.lagarcavilla.org (ahfbbjcaiaae.dreamhost.com
	[75.119.208.4]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTPA id AE43C300061; 
	Mon, 12 Dec 2011 19:43:05 -0800 (PST)
Received: from 38.108.208.89 (proxying for 38.108.208.89)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Mon, 12 Dec 2011 19:43:06 -0800
Message-ID: <a221d43997a6992363f8690a30d0ac9c.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <1323686356.20077.133.camel@zakaz.uk.xensource.com>
References: <patchbomb.1323472550@xdev.gridcentric.ca>
	<6e8b8fb2c8b23e39d910.1323472555@xdev.gridcentric.ca>
	<1323686356.20077.133.camel@zakaz.uk.xensource.com>
Date: Mon, 12 Dec 2011 19:43:06 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>,
	"andres@gridcentric.ca" <andres@gridcentric.ca>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Tim \(Xen.org\)" <tim@xen.org>,
	"adin@gridcentric.ca" <adin@gridcentric.ca>
Subject: Re: [Xen-devel] [PATCH 5 of 8] Tools: Expose to libxc the total
 number of shared frames and space saved
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> On Fri, 2011-12-09 at 23:15 +0000, Andres Lagar-Cavilla wrote:
>> tools/libxc/xc_private.c |  10 ++++++++++
>>  tools/libxc/xenctrl.h    |   4 ++++
>>  2 files changed, 14 insertions(+), 0 deletions(-)
>>
>>
>> Signed-off-by: Adin Scannell <adin@scannell.ca>
>
> If you pass on someone elses work I think it is normal to add your own
> Signed-off-by (per DCO clause (c)).
>
> [...]
>> diff -r a22140d92931 -r 6e8b8fb2c8b2 tools/libxc/xenctrl.h
>> --- a/tools/libxc/xenctrl.h
>> +++ b/tools/libxc/xenctrl.h
>> @@ -1227,6 +1227,10 @@ int xc_mmuext_op(xc_interface *xch, stru
>>  /* System wide memory properties */
>>  long xc_maximum_ram_page(xc_interface *xch);
>>
>> +long xc_sharing_freed_pages(xc_interface *xch);
>> +
>> +long xc_sharing_used_frames(xc_interface *xch);
We'll comment, certainly. For the record:

used_frames indicates the number of frames of memory that are shared,
each, by two or more domains. We use the term "frame" because it's
commonly used in textbooks for MMUs, in the sense that "a frame hosts a
page" or "a page maps to a frame". Thus our use of shared frames,
representing a different page (albeit with identical contents) to
different domains.

freed_pages indicates the number of individual pages freed as a result of
sharing. These are pages, one per domain.

Andres
>
> A quick comment on what each function returns might be worthwhile, maybe
> it's obvious to someone who knows the sharing stuff, but e.g. does
> "used" mean used right now or does it mean have ever been used? I
> suppose "freed" must be historical.
>
> Also why pages vs frames? The underlying domctl is always pages.
>
> Ian.
>
>> +
>>  /* Get current total pages allocated to a domain. */
>>  long xc_get_tot_pages(xc_interface *xch, uint32_t domid);
>>
>
>
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 03:44:39 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 03:44:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaJHg-0004OA-7Y; Tue, 13 Dec 2011 03:44:04 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RaJHe-0004Nw-Ha
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 03:44:02 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-7.tower-182.messagelabs.com!1323747787!6914982!1
X-Originating-IP: [208.97.132.66]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi42NiA9PiAxNTE1Mg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19763 invoked from network); 13 Dec 2011 03:43:08 -0000
Received: from caiajhbdcagg.dreamhost.com (HELO homiemail-a21.g.dreamhost.com)
	(208.97.132.66) by server-7.tower-182.messagelabs.com with SMTP;
	13 Dec 2011 03:43:08 -0000
Received: from homiemail-a21.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTP id 0E40030006C;
	Mon, 12 Dec 2011 19:43:06 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=QUDibi03pHmNwGBg0ox/oucFVVslP8jWrDmkip520xdu
	PxRHZ8xs2lsLTugW7CTHVhMMufPzjuWZzIFLSCzkf1Jlqsm7dnbKqbRA9wnXHIfL
	IVZWLR6TkdxE3laScSxnQW/t9iWgu3Sg/ubAONkH2gPFN2SQGgCVpMQ5KMuCTr0=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=1kYkW9/9kszxPiNukE7gCM8fTrE=; b=LdDpszrK
	eKyaZzP+TFdQXM+/nFxKjNJGWpW8mpQKpJN9KmvbvhvcaxGqVgWE1l/9Ua01X6y0
	vZFI4u8QoDPgsckdVH50IwV19LbdyBmRpPcNqu/FDz4D9tunitLPawYMqRUo8FVy
	hIFURm1H0t3P7PpoHEOW7FxLbOSKiw3GhiQ=
Received: from webmail.lagarcavilla.org (ahfbbjcaiaae.dreamhost.com
	[75.119.208.4]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTPA id AE43C300061; 
	Mon, 12 Dec 2011 19:43:05 -0800 (PST)
Received: from 38.108.208.89 (proxying for 38.108.208.89)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Mon, 12 Dec 2011 19:43:06 -0800
Message-ID: <a221d43997a6992363f8690a30d0ac9c.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <1323686356.20077.133.camel@zakaz.uk.xensource.com>
References: <patchbomb.1323472550@xdev.gridcentric.ca>
	<6e8b8fb2c8b23e39d910.1323472555@xdev.gridcentric.ca>
	<1323686356.20077.133.camel@zakaz.uk.xensource.com>
Date: Mon, 12 Dec 2011 19:43:06 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>,
	"andres@gridcentric.ca" <andres@gridcentric.ca>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Tim \(Xen.org\)" <tim@xen.org>,
	"adin@gridcentric.ca" <adin@gridcentric.ca>
Subject: Re: [Xen-devel] [PATCH 5 of 8] Tools: Expose to libxc the total
 number of shared frames and space saved
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> On Fri, 2011-12-09 at 23:15 +0000, Andres Lagar-Cavilla wrote:
>> tools/libxc/xc_private.c |  10 ++++++++++
>>  tools/libxc/xenctrl.h    |   4 ++++
>>  2 files changed, 14 insertions(+), 0 deletions(-)
>>
>>
>> Signed-off-by: Adin Scannell <adin@scannell.ca>
>
> If you pass on someone elses work I think it is normal to add your own
> Signed-off-by (per DCO clause (c)).
>
> [...]
>> diff -r a22140d92931 -r 6e8b8fb2c8b2 tools/libxc/xenctrl.h
>> --- a/tools/libxc/xenctrl.h
>> +++ b/tools/libxc/xenctrl.h
>> @@ -1227,6 +1227,10 @@ int xc_mmuext_op(xc_interface *xch, stru
>>  /* System wide memory properties */
>>  long xc_maximum_ram_page(xc_interface *xch);
>>
>> +long xc_sharing_freed_pages(xc_interface *xch);
>> +
>> +long xc_sharing_used_frames(xc_interface *xch);
We'll comment, certainly. For the record:

used_frames indicates the number of frames of memory that are shared,
each, by two or more domains. We use the term "frame" because it's
commonly used in textbooks for MMUs, in the sense that "a frame hosts a
page" or "a page maps to a frame". Thus our use of shared frames,
representing a different page (albeit with identical contents) to
different domains.

freed_pages indicates the number of individual pages freed as a result of
sharing. These are pages, one per domain.

Andres
>
> A quick comment on what each function returns might be worthwhile, maybe
> it's obvious to someone who knows the sharing stuff, but e.g. does
> "used" mean used right now or does it mean have ever been used? I
> suppose "freed" must be historical.
>
> Also why pages vs frames? The underlying domctl is always pages.
>
> Ian.
>
>> +
>>  /* Get current total pages allocated to a domain. */
>>  long xc_get_tot_pages(xc_interface *xch, uint32_t domid);
>>
>
>
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 04:20:02 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 04:20:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaJpo-000573-6B; Tue, 13 Dec 2011 04:19:20 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RaJpm-00056y-LL
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 04:19:19 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-4.tower-216.messagelabs.com!1323749904!7189686!1
X-Originating-IP: [208.97.132.202]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4yMDIgPT4gMTU0NTE=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28125 invoked from network); 13 Dec 2011 04:18:24 -0000
Received: from caiajhbdccac.dreamhost.com (HELO homiemail-a20.g.dreamhost.com)
	(208.97.132.202) by server-4.tower-216.messagelabs.com with SMTP;
	13 Dec 2011 04:18:24 -0000
Received: from homiemail-a20.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTP id 86CCB7EC064;
	Mon, 12 Dec 2011 20:18:23 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=TBMt+LtdppSnK40YY/aH1kNLBqVy1r2Sm8FBOkrqu9Rn
	Mtlkuj0LGbwvOu3xu293WLy+C3Rs7q7UubsDaWELEQEK5E3R5fU5sCew0L8670Bh
	uvdn5TTSgu0t7wX+fmCcFhSDOTjZoqGhIqW+nb4uKrR3sAjysbEgonYDt4KueJ4=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=bEvFx3kptfRr01HhQJ/ufdmSNf0=; b=PUU3qrO6
	GDW2j3VIdCFPeZ86lCqNx8ViM1uDi+KTKkFcYrkHR9MncJlu8P6H5hEyUkSN+0sa
	9W4vapgruVBIZwGFM7SsxQmwIJD5sGOm1afPO149XPBnc7APBWn+TzuSRC8hG9Iy
	I8+3iNOZEEKFWHuuu/KfYpoNolusYaRRAPg=
Received: from webmail.lagarcavilla.org (ahfbbjcaiaae.dreamhost.com
	[75.119.208.4]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTPA id 4D9AE7EC063; 
	Mon, 12 Dec 2011 20:18:23 -0800 (PST)
Received: from 38.108.208.89 (proxying for 38.108.208.89)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Mon, 12 Dec 2011 20:18:23 -0800
Message-ID: <2ad2f51b6a5456afb4e8afb53b600c44.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <1323684832.20077.120.camel@zakaz.uk.xensource.com>
References: <patchbomb.1323472550@xdev.gridcentric.ca>
	<e16f5d2643c910d9b8c1.1323472553@xdev.gridcentric.ca>
	<1323684832.20077.120.camel@zakaz.uk.xensource.com>
Date: Mon, 12 Dec 2011 20:18:23 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>,
	"andres@gridcentric.ca" <andres@gridcentric.ca>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Tim \(Xen.org\)" <tim@xen.org>,
	"adin@gridcentric.ca" <adin@gridcentric.ca>
Subject: Re: [Xen-devel] [PATCH 3 of 8] Tools: Update memshr tool to use new
	sharing API
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> On Fri, 2011-12-09 at 23:15 +0000, Andres Lagar-Cavilla wrote:
>> tools/blktap2/drivers/Makefile        |   2 +-
>>  tools/blktap2/drivers/tapdisk-image.c |   2 +-
>>  tools/blktap2/drivers/tapdisk-vbd.c   |   6 +++---
>>  tools/blktap2/drivers/tapdisk.h       |   6 +++++-
>>  tools/memshr/bidir-daemon.c           |  34
>> ++++++++++++++++++++++++----------
>>  tools/memshr/bidir-hash.h             |  13 ++++++++-----
>>  tools/memshr/interface.c              |  30
>> ++++++++++++++++++------------
>>  tools/memshr/memshr.h                 |  11 +++++++++--
>>  8 files changed, 69 insertions(+), 35 deletions(-)
>>
>>
>> The only (in-tree, that we know of) consumer of the mem sharing API
>> is the memshr tool (conditionally linked into blktap2). Update it to
>> use the new API.
>
> At least some of this must happen in the previous 2 patches so that the
> build is not broken.
>
> Is there any benefit to conditionally linking this stuff? Is it lots of
> code or does it have some other undesirable impact when built even when
> it is quiescent? Seems like a recipe for bit rot to not build it, plus
> it makes it harder for people to consume via distro packages etc.

Let me clarify this a bit: our interest in memshr is in not breaking it
with our changes. We don't know why it's built that way. It was like that
wen we arrived. We don't change that. We certainly don't intend to own it.

I would frame line 44 at
http://xenbits.xensource.com/hg/xen-unstable.hg/file/1c58bb664d8d/tools/blktap2/drivers/Makefile
as the definition of bit rot

Andres

>
>> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
>>
>> diff -r 892049dfc1c9 -r e16f5d2643c9 tools/blktap2/drivers/Makefile
>> --- a/tools/blktap2/drivers/Makefile
>> +++ b/tools/blktap2/drivers/Makefile
>> @@ -43,7 +43,7 @@ MEMSHR_DIR = $(XEN_ROOT)/tools/memshr
>>  MEMSHRLIBS :=
>>  ifeq ($(CONFIG_Linux), __fixme__)
>>  CFLAGS += -DMEMSHR
>> -MEMSHRLIBS += $(MEMSHR_DIR)/libmemshr.a
>> +MEMSHRLIBS += -L$(XEN_ROOT)/tools/libxc -lxenctrl
>> $(MEMSHR_DIR)/libmemshr.a
>
> Please use $(LDLIBS_libxenctrl).
>
> Is there a reason libmemshr is not a shared library?
>
>>  endif
>>
>>  ifeq ($(VHD_STATIC),y)
>> diff -r 892049dfc1c9 -r e16f5d2643c9
>> tools/blktap2/drivers/tapdisk-image.c
>> --- a/tools/blktap2/drivers/tapdisk-image.c
>> +++ b/tools/blktap2/drivers/tapdisk-image.c
>> @@ -60,7 +60,7 @@ tapdisk_image_allocate(const char *file,
>>         image->storage   = storage;
>>         image->private   = private;
>>  #ifdef MEMSHR
>> -       image->memshr_id = memshr_vbd_image_get(file);
>> +       image->memshr_id = memshr_vbd_image_get((char *)file);
>
> Casting away the const here raises a big red flag. Why is this
> necessary? You should either fix the API of memshr_vbd_image_get or
> tapdisk_image_allocate IMHO and propagate the change as necessary.
> AFAICT there is no reason not to push the const'ness down into the
> memshr API.
>
>>  #endif
>>         INIT_LIST_HEAD(&image->next);
>>
> [...]
>
>> diff -r 892049dfc1c9 -r e16f5d2643c9 tools/memshr/bidir-hash.h
>> --- a/tools/memshr/bidir-hash.h
>> +++ b/tools/memshr/bidir-hash.h
>> @@ -81,15 +81,16 @@ static int fgprtshr_mfn_cmp(uint32_t m1,
>>  #undef BIDIR_VALUE
>>  #undef BIDIR_KEY_T
>>  #undef BIDIR_VALUE_T
>> +
>>  /* TODO better hashes! */
>>  static inline uint32_t blockshr_block_hash(vbdblk_t block)
>>  {
>>      return (uint32_t)(block.sec) ^ (uint32_t)(block.disk_id);
>>  }
>>
>> -static inline uint32_t blockshr_shrhnd_hash(uint64_t shrhnd)
>> +static inline uint32_t blockshr_shrhnd_hash(share_tuple_t shrhnd)
>>  {
>> -    return (uint32_t)shrhnd;
>> +    return ((uint32_t) shrhnd.handle);
>>  }
>>
>>  static inline int blockshr_block_cmp(vbdblk_t b1, vbdblk_t b2)
>> @@ -97,15 +98,17 @@ static inline int blockshr_block_cmp(vbd
>>      return (b1.sec == b2.sec) && (b1.disk_id == b2.disk_id);
>>  }
>>
>> -static inline int blockshr_shrhnd_cmp(uint64_t h1, uint64_t h2)
>> +static inline int blockshr_shrhnd_cmp(share_tuple_t h1, share_tuple_t
>> h2)
>>  {
>> -    return (h1 == h2);
>> +    return ( (h1.domain == h2.domain) &&
>> +             (h1.frame  == h2.frame) &&
>> +             (h1.handle == h2.handle) );
>
> memcmp?
>
>>  }
>>  #define BIDIR_NAME_PREFIX       blockshr
>>  #define BIDIR_KEY               block
>>  #define BIDIR_VALUE             shrhnd
>>  #define BIDIR_KEY_T             vbdblk_t
>> -#define BIDIR_VALUE_T           uint64_t
>> +#define BIDIR_VALUE_T           share_tuple_t
>>  #include "bidir-namedefs.h"
>>
>>  #endif /* BLOCK_MAP */
>> diff -r 892049dfc1c9 -r e16f5d2643c9 tools/memshr/interface.c
>> --- a/tools/memshr/interface.c
>> +++ b/tools/memshr/interface.c
>> @@ -145,16 +145,17 @@ void memshr_vbd_image_put(uint16_t memsh
>>
>>  int memshr_vbd_issue_ro_request(char *buf,
>>                                  grant_ref_t gref,
>> -                                uint16_t file_id,
>> +                                uint16_t file_id,
>>                                  uint64_t sec,
>>                                  int secs,
>> -                                uint64_t *hnd)
>> +                                share_tuple_t *hnd)
>>  {
>>      vbdblk_t blk;
>> -    uint64_t s_hnd, c_hnd;
>> +    share_tuple_t source_st, client_st;
>> +    uint64_t c_hnd;
>>      int ret;
>>
>> -    *hnd = 0;
>> +    *hnd = (share_tuple_t){ 0, 0, 0 };
>>      if(!vbd_info.enabled)
>>          return -1;
>>
>> @@ -169,26 +170,31 @@ int memshr_vbd_issue_ro_request(char *bu
>>      /* If page couldn't be made sharable, we cannot do anything about
>> it */
>>      if(ret != 0)
>>          return -3;
>> -    *hnd = c_hnd;
>> +
>> +    *(&client_st) = (share_tuple_t){ vbd_info.domid, gref, c_hnd };
>
> Is "*(&thing)" somehow different to "thing"?
>
>> +    *hnd = client_st;
>>
>>      /* Check if we've read matching disk block previously */
>>      blk.sec     = sec;
>>      blk.disk_id = file_id;
>> -    if(blockshr_block_lookup(memshr.blks, blk, &s_hnd) > 0)
>> +    if(blockshr_block_lookup(memshr.blks, blk, &source_st) > 0)
>>      {
>> -        ret = xc_memshr_share(vbd_info.xc_handle, s_hnd, c_hnd);
>> +        ret = xc_memshr_share(vbd_info.xc_handle, source_st.domain,
>> source_st.frame,
>> +                                source_st.handle, 1, vbd_info.domid,
>> gref, c_hnd, 1);
>
> These 1's == is a gref but I only know that because I was just reading
> that patch. If you decide you do need to keep the flag separate then
> this would be better as a flags argument with named values
> XC_MEMSHR_SOURCE_IS_GREF etc.
>
>> diff -r 892049dfc1c9 -r e16f5d2643c9 tools/memshr/memshr.h
>> --- a/tools/memshr/memshr.h
>> +++ b/tools/memshr/memshr.h
>> @@ -25,6 +25,13 @@
>>
>>  typedef uint64_t xen_mfn_t;
>>
>> +typedef struct share_tuple
>> +{
>> +    uint32_t domain;
>> +    uint64_t frame;
>> +    uint64_t handle;
>> +} share_tuple_t;
>
> Didn't you just add these as three separate parameters to
> xc_memshr_share? Seems like this could be xc_memshr_tuple (or some
> better name with more meaning than "tuple") and used throughout.
>
> Ian.
>
>
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 04:20:02 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 04:20:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaJpo-000573-6B; Tue, 13 Dec 2011 04:19:20 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RaJpm-00056y-LL
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 04:19:19 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-4.tower-216.messagelabs.com!1323749904!7189686!1
X-Originating-IP: [208.97.132.202]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4yMDIgPT4gMTU0NTE=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28125 invoked from network); 13 Dec 2011 04:18:24 -0000
Received: from caiajhbdccac.dreamhost.com (HELO homiemail-a20.g.dreamhost.com)
	(208.97.132.202) by server-4.tower-216.messagelabs.com with SMTP;
	13 Dec 2011 04:18:24 -0000
Received: from homiemail-a20.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTP id 86CCB7EC064;
	Mon, 12 Dec 2011 20:18:23 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=TBMt+LtdppSnK40YY/aH1kNLBqVy1r2Sm8FBOkrqu9Rn
	Mtlkuj0LGbwvOu3xu293WLy+C3Rs7q7UubsDaWELEQEK5E3R5fU5sCew0L8670Bh
	uvdn5TTSgu0t7wX+fmCcFhSDOTjZoqGhIqW+nb4uKrR3sAjysbEgonYDt4KueJ4=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=bEvFx3kptfRr01HhQJ/ufdmSNf0=; b=PUU3qrO6
	GDW2j3VIdCFPeZ86lCqNx8ViM1uDi+KTKkFcYrkHR9MncJlu8P6H5hEyUkSN+0sa
	9W4vapgruVBIZwGFM7SsxQmwIJD5sGOm1afPO149XPBnc7APBWn+TzuSRC8hG9Iy
	I8+3iNOZEEKFWHuuu/KfYpoNolusYaRRAPg=
Received: from webmail.lagarcavilla.org (ahfbbjcaiaae.dreamhost.com
	[75.119.208.4]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTPA id 4D9AE7EC063; 
	Mon, 12 Dec 2011 20:18:23 -0800 (PST)
Received: from 38.108.208.89 (proxying for 38.108.208.89)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Mon, 12 Dec 2011 20:18:23 -0800
Message-ID: <2ad2f51b6a5456afb4e8afb53b600c44.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <1323684832.20077.120.camel@zakaz.uk.xensource.com>
References: <patchbomb.1323472550@xdev.gridcentric.ca>
	<e16f5d2643c910d9b8c1.1323472553@xdev.gridcentric.ca>
	<1323684832.20077.120.camel@zakaz.uk.xensource.com>
Date: Mon, 12 Dec 2011 20:18:23 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>,
	"andres@gridcentric.ca" <andres@gridcentric.ca>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Tim \(Xen.org\)" <tim@xen.org>,
	"adin@gridcentric.ca" <adin@gridcentric.ca>
Subject: Re: [Xen-devel] [PATCH 3 of 8] Tools: Update memshr tool to use new
	sharing API
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> On Fri, 2011-12-09 at 23:15 +0000, Andres Lagar-Cavilla wrote:
>> tools/blktap2/drivers/Makefile        |   2 +-
>>  tools/blktap2/drivers/tapdisk-image.c |   2 +-
>>  tools/blktap2/drivers/tapdisk-vbd.c   |   6 +++---
>>  tools/blktap2/drivers/tapdisk.h       |   6 +++++-
>>  tools/memshr/bidir-daemon.c           |  34
>> ++++++++++++++++++++++++----------
>>  tools/memshr/bidir-hash.h             |  13 ++++++++-----
>>  tools/memshr/interface.c              |  30
>> ++++++++++++++++++------------
>>  tools/memshr/memshr.h                 |  11 +++++++++--
>>  8 files changed, 69 insertions(+), 35 deletions(-)
>>
>>
>> The only (in-tree, that we know of) consumer of the mem sharing API
>> is the memshr tool (conditionally linked into blktap2). Update it to
>> use the new API.
>
> At least some of this must happen in the previous 2 patches so that the
> build is not broken.
>
> Is there any benefit to conditionally linking this stuff? Is it lots of
> code or does it have some other undesirable impact when built even when
> it is quiescent? Seems like a recipe for bit rot to not build it, plus
> it makes it harder for people to consume via distro packages etc.

Let me clarify this a bit: our interest in memshr is in not breaking it
with our changes. We don't know why it's built that way. It was like that
wen we arrived. We don't change that. We certainly don't intend to own it.

I would frame line 44 at
http://xenbits.xensource.com/hg/xen-unstable.hg/file/1c58bb664d8d/tools/blktap2/drivers/Makefile
as the definition of bit rot

Andres

>
>> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
>>
>> diff -r 892049dfc1c9 -r e16f5d2643c9 tools/blktap2/drivers/Makefile
>> --- a/tools/blktap2/drivers/Makefile
>> +++ b/tools/blktap2/drivers/Makefile
>> @@ -43,7 +43,7 @@ MEMSHR_DIR = $(XEN_ROOT)/tools/memshr
>>  MEMSHRLIBS :=
>>  ifeq ($(CONFIG_Linux), __fixme__)
>>  CFLAGS += -DMEMSHR
>> -MEMSHRLIBS += $(MEMSHR_DIR)/libmemshr.a
>> +MEMSHRLIBS += -L$(XEN_ROOT)/tools/libxc -lxenctrl
>> $(MEMSHR_DIR)/libmemshr.a
>
> Please use $(LDLIBS_libxenctrl).
>
> Is there a reason libmemshr is not a shared library?
>
>>  endif
>>
>>  ifeq ($(VHD_STATIC),y)
>> diff -r 892049dfc1c9 -r e16f5d2643c9
>> tools/blktap2/drivers/tapdisk-image.c
>> --- a/tools/blktap2/drivers/tapdisk-image.c
>> +++ b/tools/blktap2/drivers/tapdisk-image.c
>> @@ -60,7 +60,7 @@ tapdisk_image_allocate(const char *file,
>>         image->storage   = storage;
>>         image->private   = private;
>>  #ifdef MEMSHR
>> -       image->memshr_id = memshr_vbd_image_get(file);
>> +       image->memshr_id = memshr_vbd_image_get((char *)file);
>
> Casting away the const here raises a big red flag. Why is this
> necessary? You should either fix the API of memshr_vbd_image_get or
> tapdisk_image_allocate IMHO and propagate the change as necessary.
> AFAICT there is no reason not to push the const'ness down into the
> memshr API.
>
>>  #endif
>>         INIT_LIST_HEAD(&image->next);
>>
> [...]
>
>> diff -r 892049dfc1c9 -r e16f5d2643c9 tools/memshr/bidir-hash.h
>> --- a/tools/memshr/bidir-hash.h
>> +++ b/tools/memshr/bidir-hash.h
>> @@ -81,15 +81,16 @@ static int fgprtshr_mfn_cmp(uint32_t m1,
>>  #undef BIDIR_VALUE
>>  #undef BIDIR_KEY_T
>>  #undef BIDIR_VALUE_T
>> +
>>  /* TODO better hashes! */
>>  static inline uint32_t blockshr_block_hash(vbdblk_t block)
>>  {
>>      return (uint32_t)(block.sec) ^ (uint32_t)(block.disk_id);
>>  }
>>
>> -static inline uint32_t blockshr_shrhnd_hash(uint64_t shrhnd)
>> +static inline uint32_t blockshr_shrhnd_hash(share_tuple_t shrhnd)
>>  {
>> -    return (uint32_t)shrhnd;
>> +    return ((uint32_t) shrhnd.handle);
>>  }
>>
>>  static inline int blockshr_block_cmp(vbdblk_t b1, vbdblk_t b2)
>> @@ -97,15 +98,17 @@ static inline int blockshr_block_cmp(vbd
>>      return (b1.sec == b2.sec) && (b1.disk_id == b2.disk_id);
>>  }
>>
>> -static inline int blockshr_shrhnd_cmp(uint64_t h1, uint64_t h2)
>> +static inline int blockshr_shrhnd_cmp(share_tuple_t h1, share_tuple_t
>> h2)
>>  {
>> -    return (h1 == h2);
>> +    return ( (h1.domain == h2.domain) &&
>> +             (h1.frame  == h2.frame) &&
>> +             (h1.handle == h2.handle) );
>
> memcmp?
>
>>  }
>>  #define BIDIR_NAME_PREFIX       blockshr
>>  #define BIDIR_KEY               block
>>  #define BIDIR_VALUE             shrhnd
>>  #define BIDIR_KEY_T             vbdblk_t
>> -#define BIDIR_VALUE_T           uint64_t
>> +#define BIDIR_VALUE_T           share_tuple_t
>>  #include "bidir-namedefs.h"
>>
>>  #endif /* BLOCK_MAP */
>> diff -r 892049dfc1c9 -r e16f5d2643c9 tools/memshr/interface.c
>> --- a/tools/memshr/interface.c
>> +++ b/tools/memshr/interface.c
>> @@ -145,16 +145,17 @@ void memshr_vbd_image_put(uint16_t memsh
>>
>>  int memshr_vbd_issue_ro_request(char *buf,
>>                                  grant_ref_t gref,
>> -                                uint16_t file_id,
>> +                                uint16_t file_id,
>>                                  uint64_t sec,
>>                                  int secs,
>> -                                uint64_t *hnd)
>> +                                share_tuple_t *hnd)
>>  {
>>      vbdblk_t blk;
>> -    uint64_t s_hnd, c_hnd;
>> +    share_tuple_t source_st, client_st;
>> +    uint64_t c_hnd;
>>      int ret;
>>
>> -    *hnd = 0;
>> +    *hnd = (share_tuple_t){ 0, 0, 0 };
>>      if(!vbd_info.enabled)
>>          return -1;
>>
>> @@ -169,26 +170,31 @@ int memshr_vbd_issue_ro_request(char *bu
>>      /* If page couldn't be made sharable, we cannot do anything about
>> it */
>>      if(ret != 0)
>>          return -3;
>> -    *hnd = c_hnd;
>> +
>> +    *(&client_st) = (share_tuple_t){ vbd_info.domid, gref, c_hnd };
>
> Is "*(&thing)" somehow different to "thing"?
>
>> +    *hnd = client_st;
>>
>>      /* Check if we've read matching disk block previously */
>>      blk.sec     = sec;
>>      blk.disk_id = file_id;
>> -    if(blockshr_block_lookup(memshr.blks, blk, &s_hnd) > 0)
>> +    if(blockshr_block_lookup(memshr.blks, blk, &source_st) > 0)
>>      {
>> -        ret = xc_memshr_share(vbd_info.xc_handle, s_hnd, c_hnd);
>> +        ret = xc_memshr_share(vbd_info.xc_handle, source_st.domain,
>> source_st.frame,
>> +                                source_st.handle, 1, vbd_info.domid,
>> gref, c_hnd, 1);
>
> These 1's == is a gref but I only know that because I was just reading
> that patch. If you decide you do need to keep the flag separate then
> this would be better as a flags argument with named values
> XC_MEMSHR_SOURCE_IS_GREF etc.
>
>> diff -r 892049dfc1c9 -r e16f5d2643c9 tools/memshr/memshr.h
>> --- a/tools/memshr/memshr.h
>> +++ b/tools/memshr/memshr.h
>> @@ -25,6 +25,13 @@
>>
>>  typedef uint64_t xen_mfn_t;
>>
>> +typedef struct share_tuple
>> +{
>> +    uint32_t domain;
>> +    uint64_t frame;
>> +    uint64_t handle;
>> +} share_tuple_t;
>
> Didn't you just add these as three separate parameters to
> xc_memshr_share? Seems like this could be xc_memshr_tuple (or some
> better name with more meaning than "tuple") and used throughout.
>
> Ian.
>
>
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 04:24:22 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 04:24:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaJuD-0005H3-7c; Tue, 13 Dec 2011 04:23:53 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RaJuA-0005Gp-Uz
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 04:23:51 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-5.tower-21.messagelabs.com!1323750176!1692223!1
X-Originating-IP: [208.97.132.83]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi44MyA9PiAxNTYwMw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20280 invoked from network); 13 Dec 2011 04:22:56 -0000
Received: from caiajhbdcaid.dreamhost.com (HELO homiemail-a76.g.dreamhost.com)
	(208.97.132.83) by server-5.tower-21.messagelabs.com with SMTP;
	13 Dec 2011 04:22:56 -0000
Received: from homiemail-a76.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTP id CA67245807B;
	Mon, 12 Dec 2011 20:22:55 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=MGL26IW9tZ3VnZhWq8UnlzODRlV3IFEdA1QXtrNq1gbh
	aLVnGnsadBNXgC+P1HavqVMpK4lsGIv6dkzPJbiunJ7Jk0isWQ9MayvAF4/xDaSf
	nWEa8a9YriRVlcULmNc4ZPC5Y6A5BJKH8R/GwK74UkZ7yiOHow6Y2y9YtqZQOG8=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=DC5tSzySTCGOM9QrV7F3s5OReVE=; b=V+Nyng4J
	q81YKZmsr8rFMbjnYmdaqN2f9y7b/Ep3gGYBCajAiTegQToXrH2zTCkpGKmpbBc9
	x3BDkaRDRZ9vqMoQAp1q55Ry4ObcTxSZRCqCGwXD6kXKfyxPBs03Xa9jde+X0nFB
	aYDiCUPEwjzYxV7T2S2NuWX2eq8OK10F1TE=
Received: from webmail.lagarcavilla.org (ahfbbjcaiaae.dreamhost.com
	[75.119.208.4]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTPA id 1D5B1458079; 
	Mon, 12 Dec 2011 20:22:55 -0800 (PST)
Received: from 38.108.208.89 (proxying for 38.108.208.89)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Mon, 12 Dec 2011 20:22:55 -0800
Message-ID: <b98ae4e300d803cac48ad7ce3bcf2874.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <4EE5D8640200007800066DDF@nat28.tlf.novell.com>
References: <patchbomb.1323462147@xdev.gridcentric.ca>
	<5b9b36648e439bca97b0.1323462155@xdev.gridcentric.ca>
	<4EE5D8640200007800066DDF@nat28.tlf.novell.com>
Date: Mon, 12 Dec 2011 20:22:55 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Jan Beulich" <JBeulich@suse.com>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: andres@gridcentric.ca, keir.xen@gmail.com, tim@xen.org,
	xen-devel@lists.xensource.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 8 of 9] x86/mm: New domctl: Perform sharing
	audit
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>  >>> On 09.12.11 at 21:22, Andres Lagar-Cavilla <andres@lagarcavilla.org>
> wrote:
>> Sharing audits are heavyweight, so instead of performing them inline,
>> we make them callable via a domctl.
>
> As said before - there's again no consumer of this new code within the
> series, and hence you're asking to add dead code.

Stands to reason that audit domctls are generally useful things. We
already have p2m audit domctls with no consumer. And that's not the end of
the list of things in the tree without a consumer.

I think your comments about dead code are a bit excessive. The only
consumer in this tree of the sharing API is memshr. Have a look at how
memshr is currently linked into blktap2. Maybe we should just submit one
patch removing all of memshr and the Xen sharing code?

Instead, we're trying to undo the bit rot here.

Thanks,
Andres
>
> Jan
>
>> Signed-off-by: Adin Scannell <adin@scannell.ca>
>
>
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 04:24:22 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 04:24:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaJuD-0005H3-7c; Tue, 13 Dec 2011 04:23:53 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RaJuA-0005Gp-Uz
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 04:23:51 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-5.tower-21.messagelabs.com!1323750176!1692223!1
X-Originating-IP: [208.97.132.83]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi44MyA9PiAxNTYwMw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20280 invoked from network); 13 Dec 2011 04:22:56 -0000
Received: from caiajhbdcaid.dreamhost.com (HELO homiemail-a76.g.dreamhost.com)
	(208.97.132.83) by server-5.tower-21.messagelabs.com with SMTP;
	13 Dec 2011 04:22:56 -0000
Received: from homiemail-a76.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTP id CA67245807B;
	Mon, 12 Dec 2011 20:22:55 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=MGL26IW9tZ3VnZhWq8UnlzODRlV3IFEdA1QXtrNq1gbh
	aLVnGnsadBNXgC+P1HavqVMpK4lsGIv6dkzPJbiunJ7Jk0isWQ9MayvAF4/xDaSf
	nWEa8a9YriRVlcULmNc4ZPC5Y6A5BJKH8R/GwK74UkZ7yiOHow6Y2y9YtqZQOG8=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=DC5tSzySTCGOM9QrV7F3s5OReVE=; b=V+Nyng4J
	q81YKZmsr8rFMbjnYmdaqN2f9y7b/Ep3gGYBCajAiTegQToXrH2zTCkpGKmpbBc9
	x3BDkaRDRZ9vqMoQAp1q55Ry4ObcTxSZRCqCGwXD6kXKfyxPBs03Xa9jde+X0nFB
	aYDiCUPEwjzYxV7T2S2NuWX2eq8OK10F1TE=
Received: from webmail.lagarcavilla.org (ahfbbjcaiaae.dreamhost.com
	[75.119.208.4]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTPA id 1D5B1458079; 
	Mon, 12 Dec 2011 20:22:55 -0800 (PST)
Received: from 38.108.208.89 (proxying for 38.108.208.89)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Mon, 12 Dec 2011 20:22:55 -0800
Message-ID: <b98ae4e300d803cac48ad7ce3bcf2874.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <4EE5D8640200007800066DDF@nat28.tlf.novell.com>
References: <patchbomb.1323462147@xdev.gridcentric.ca>
	<5b9b36648e439bca97b0.1323462155@xdev.gridcentric.ca>
	<4EE5D8640200007800066DDF@nat28.tlf.novell.com>
Date: Mon, 12 Dec 2011 20:22:55 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Jan Beulich" <JBeulich@suse.com>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: andres@gridcentric.ca, keir.xen@gmail.com, tim@xen.org,
	xen-devel@lists.xensource.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 8 of 9] x86/mm: New domctl: Perform sharing
	audit
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>  >>> On 09.12.11 at 21:22, Andres Lagar-Cavilla <andres@lagarcavilla.org>
> wrote:
>> Sharing audits are heavyweight, so instead of performing them inline,
>> we make them callable via a domctl.
>
> As said before - there's again no consumer of this new code within the
> series, and hence you're asking to add dead code.

Stands to reason that audit domctls are generally useful things. We
already have p2m audit domctls with no consumer. And that's not the end of
the list of things in the tree without a consumer.

I think your comments about dead code are a bit excessive. The only
consumer in this tree of the sharing API is memshr. Have a look at how
memshr is currently linked into blktap2. Maybe we should just submit one
patch removing all of memshr and the Xen sharing code?

Instead, we're trying to undo the bit rot here.

Thanks,
Andres
>
> Jan
>
>> Signed-off-by: Adin Scannell <adin@scannell.ca>
>
>
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 04:30:31 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 04:30:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaK0A-0005SK-1o; Tue, 13 Dec 2011 04:30:02 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RaK08-0005SE-Up
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 04:30:01 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-6.tower-21.messagelabs.com!1323750546!7799903!1
X-Originating-IP: [208.97.132.145]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNDUgPT4gMTY0MTE=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13509 invoked from network); 13 Dec 2011 04:29:07 -0000
Received: from caiajhbdcbef.dreamhost.com (HELO homiemail-a75.g.dreamhost.com)
	(208.97.132.145) by server-6.tower-21.messagelabs.com with SMTP;
	13 Dec 2011 04:29:07 -0000
Received: from homiemail-a75.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a75.g.dreamhost.com (Postfix) with ESMTP id EA7C65EC07E;
	Mon, 12 Dec 2011 20:29:05 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=Y7IR1PmQDEIpuiFU4/kdbuYWfrKlib5pmjiNsaxEhnNh
	bLqwYDHHiKnrPfpJRO7yhUK9ECh7t+I0uCDrXk7u919+LNNM2Bnqb3uxAA8slfs+
	MpKBkcmupVbrDrBqDWH1l2U2mbuGMeNfuYFBumcFcLJJ9gdMKHtJ0KDZWXAWozk=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=TmN4rVSBcLfqg2KyE19cfuv8DIE=; b=Lo3H9I0F
	iEu2Z6qz5VR6yUVN71Iz/ItoR6Dkgj9Ub6FICOLz5EQ+EBr4h4NpdZHU539SIPWP
	za42StKoJdfVMobiSPb9twTwg/E921twfU8jp2/u73lZV0jvW/t36LJ8X5rPlkhb
	q0ZNJVS5xRmn7JKsxS9aSszZJCkg7fYmyWA=
Received: from webmail.lagarcavilla.org (ahfbbjcaiaae.dreamhost.com
	[75.119.208.4]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a75.g.dreamhost.com (Postfix) with ESMTPA id 7F4D65EC07C; 
	Mon, 12 Dec 2011 20:29:05 -0800 (PST)
Received: from 38.108.208.89 (proxying for 38.108.208.89)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Mon, 12 Dec 2011 20:29:05 -0800
Message-ID: <2a51b2486dd46edb6bc0926610df802a.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <4EE5D7910200007800066DD9@nat28.tlf.novell.com>
References: <patchbomb.1323462147@xdev.gridcentric.ca>
	<bfebf49b3eb63eb09751.1323462152@xdev.gridcentric.ca>
	<4EE5D7910200007800066DD9@nat28.tlf.novell.com>
Date: Mon, 12 Dec 2011 20:29:05 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Jan Beulich" <JBeulich@suse.com>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: andres@gridcentric.ca, keir.xen@gmail.com, Tim Deegan <tim@xen.org>,
	xen-devel@lists.xensource.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 5 of 9] x86/mm: Add per-page locking for
 memory sharing, when audits are disabled
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>  >>> On 09.12.11 at 21:22, Andres Lagar-Cavilla <andres@lagarcavilla.org>
> wrote:
>> With the removal of the hash table, all that is needed now is locking
>> of individual shared pages, as new (gfn,domain) pairs are removed or
>> added from the list of mappings.
>>
>> We recycle PGT_locked and use it to lock individual pages. We ensure
>> deadlock
>> is averted by locking pages in increasing order. We leverage an
>> "external"
>> order enforcing construct from mm-locks.h to ensure the p2m_lock (needed
>> to
>> modify gfn entries during sharing) is always taken after page_locks.
>
> As said before, I view taking a coarse lock inside a fine grained one as
> inappropriate, and hence recommend to not apply this patch without
> knowing if/when the promised follow-up patch will make it in.

Glad you brought that up.

The get_gfn*/put_gfn API change was brought forward as a prelude to
fully-synchronized p2m access: both lookups and modifications take a lock.
That code is not in the tree yet, because I'm fighting a few issues with
lock ordering inversions in the sharing code.

But once that code makes it in, get_gfn/put_gfn pairs delimit critical
sections protected by the p2m lock. And the sharing page_lock()s will be
nested inside those sections. In other words, p2m lock first, page lock
second, no lock inside page lock regions.

That will also require inverting the order in which locks are declared at
mm-locks.h. I hope to break through in the p2m locking during January.
Certainly before 4.2-rc1.

Thanks
Andres

>
> Jan
>
>> The global lock remains for the benefit of the auditing code, and is
>> thus enabled only as a compile-time option.
>>
>> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
>
>
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 04:30:31 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 04:30:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaK0A-0005SK-1o; Tue, 13 Dec 2011 04:30:02 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RaK08-0005SE-Up
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 04:30:01 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-6.tower-21.messagelabs.com!1323750546!7799903!1
X-Originating-IP: [208.97.132.145]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNDUgPT4gMTY0MTE=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13509 invoked from network); 13 Dec 2011 04:29:07 -0000
Received: from caiajhbdcbef.dreamhost.com (HELO homiemail-a75.g.dreamhost.com)
	(208.97.132.145) by server-6.tower-21.messagelabs.com with SMTP;
	13 Dec 2011 04:29:07 -0000
Received: from homiemail-a75.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a75.g.dreamhost.com (Postfix) with ESMTP id EA7C65EC07E;
	Mon, 12 Dec 2011 20:29:05 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=Y7IR1PmQDEIpuiFU4/kdbuYWfrKlib5pmjiNsaxEhnNh
	bLqwYDHHiKnrPfpJRO7yhUK9ECh7t+I0uCDrXk7u919+LNNM2Bnqb3uxAA8slfs+
	MpKBkcmupVbrDrBqDWH1l2U2mbuGMeNfuYFBumcFcLJJ9gdMKHtJ0KDZWXAWozk=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=TmN4rVSBcLfqg2KyE19cfuv8DIE=; b=Lo3H9I0F
	iEu2Z6qz5VR6yUVN71Iz/ItoR6Dkgj9Ub6FICOLz5EQ+EBr4h4NpdZHU539SIPWP
	za42StKoJdfVMobiSPb9twTwg/E921twfU8jp2/u73lZV0jvW/t36LJ8X5rPlkhb
	q0ZNJVS5xRmn7JKsxS9aSszZJCkg7fYmyWA=
Received: from webmail.lagarcavilla.org (ahfbbjcaiaae.dreamhost.com
	[75.119.208.4]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a75.g.dreamhost.com (Postfix) with ESMTPA id 7F4D65EC07C; 
	Mon, 12 Dec 2011 20:29:05 -0800 (PST)
Received: from 38.108.208.89 (proxying for 38.108.208.89)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Mon, 12 Dec 2011 20:29:05 -0800
Message-ID: <2a51b2486dd46edb6bc0926610df802a.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <4EE5D7910200007800066DD9@nat28.tlf.novell.com>
References: <patchbomb.1323462147@xdev.gridcentric.ca>
	<bfebf49b3eb63eb09751.1323462152@xdev.gridcentric.ca>
	<4EE5D7910200007800066DD9@nat28.tlf.novell.com>
Date: Mon, 12 Dec 2011 20:29:05 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Jan Beulich" <JBeulich@suse.com>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: andres@gridcentric.ca, keir.xen@gmail.com, Tim Deegan <tim@xen.org>,
	xen-devel@lists.xensource.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 5 of 9] x86/mm: Add per-page locking for
 memory sharing, when audits are disabled
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>  >>> On 09.12.11 at 21:22, Andres Lagar-Cavilla <andres@lagarcavilla.org>
> wrote:
>> With the removal of the hash table, all that is needed now is locking
>> of individual shared pages, as new (gfn,domain) pairs are removed or
>> added from the list of mappings.
>>
>> We recycle PGT_locked and use it to lock individual pages. We ensure
>> deadlock
>> is averted by locking pages in increasing order. We leverage an
>> "external"
>> order enforcing construct from mm-locks.h to ensure the p2m_lock (needed
>> to
>> modify gfn entries during sharing) is always taken after page_locks.
>
> As said before, I view taking a coarse lock inside a fine grained one as
> inappropriate, and hence recommend to not apply this patch without
> knowing if/when the promised follow-up patch will make it in.

Glad you brought that up.

The get_gfn*/put_gfn API change was brought forward as a prelude to
fully-synchronized p2m access: both lookups and modifications take a lock.
That code is not in the tree yet, because I'm fighting a few issues with
lock ordering inversions in the sharing code.

But once that code makes it in, get_gfn/put_gfn pairs delimit critical
sections protected by the p2m lock. And the sharing page_lock()s will be
nested inside those sections. In other words, p2m lock first, page lock
second, no lock inside page lock regions.

That will also require inverting the order in which locks are declared at
mm-locks.h. I hope to break through in the p2m locking during January.
Certainly before 4.2-rc1.

Thanks
Andres

>
> Jan
>
>> The global lock remains for the benefit of the auditing code, and is
>> thus enabled only as a compile-time option.
>>
>> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
>
>
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 05:23:31 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 05: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.xensource.com>)
	id 1RaKpQ-0006Sx-PW; Tue, 13 Dec 2011 05:23:00 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RaKpP-0006Sq-7v
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 05:22:59 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1323753724!7183282!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDc5MA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29335 invoked from network); 13 Dec 2011 05:22:05 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 05:22:05 -0000
X-IronPort-AV: E=Sophos;i="4.71,343,1320624000"; 
   d="scan'208";a="9430428"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Dec 2011 05:22:04 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 13 Dec 2011 05:22:04 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RaKoV-00047T-V9;
	Tue, 13 Dec 2011 05:22:03 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RaKoV-0005Dl-Ub;
	Tue, 13 Dec 2011 05:22:03 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10481-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 13 Dec 2011 05:22:03 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10481: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10481 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10481/

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-amd64-win          7 windows-install           fail REGR. vs. 10474

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-pv           9 guest-start                 fail pass in 10480
 test-amd64-amd64-xl-sedf-pin 11 guest-localmigrate          fail pass in 10480
 test-amd64-amd64-xl-sedf     11 guest-localmigrate fail in 10480 pass in 10481

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3    7 windows-install              fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install fail in 10480 like 10474
 test-amd64-i386-xend-winxpsp3  7 windows-install      fail in 10480 like 10474
 test-amd64-i386-xl-win7-amd64  7 windows-install      fail in 10480 like 10474
 test-amd64-amd64-xl-win7-amd64  7 windows-install     fail in 10480 like 10474
 test-amd64-i386-win           7 windows-install       fail in 10480 like 10473

version targeted for testing:
 xen                  7ca56cca09ad
baseline version:
 xen                  1c58bb664d8d

------------------------------------------------------------
People who touched revisions under test:
  Andre Przywara <andre.przywara@amd.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Roger Pau Monne <roger.pau@entel.upc.edu>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          fail    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 336 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 05:23:31 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 05: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.xensource.com>)
	id 1RaKpQ-0006Sx-PW; Tue, 13 Dec 2011 05:23:00 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RaKpP-0006Sq-7v
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 05:22:59 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1323753724!7183282!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDc5MA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29335 invoked from network); 13 Dec 2011 05:22:05 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 05:22:05 -0000
X-IronPort-AV: E=Sophos;i="4.71,343,1320624000"; 
   d="scan'208";a="9430428"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Dec 2011 05:22:04 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 13 Dec 2011 05:22:04 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RaKoV-00047T-V9;
	Tue, 13 Dec 2011 05:22:03 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RaKoV-0005Dl-Ub;
	Tue, 13 Dec 2011 05:22:03 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10481-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 13 Dec 2011 05:22:03 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10481: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10481 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10481/

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-amd64-win          7 windows-install           fail REGR. vs. 10474

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-pv           9 guest-start                 fail pass in 10480
 test-amd64-amd64-xl-sedf-pin 11 guest-localmigrate          fail pass in 10480
 test-amd64-amd64-xl-sedf     11 guest-localmigrate fail in 10480 pass in 10481

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3    7 windows-install              fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install fail in 10480 like 10474
 test-amd64-i386-xend-winxpsp3  7 windows-install      fail in 10480 like 10474
 test-amd64-i386-xl-win7-amd64  7 windows-install      fail in 10480 like 10474
 test-amd64-amd64-xl-win7-amd64  7 windows-install     fail in 10480 like 10474
 test-amd64-i386-win           7 windows-install       fail in 10480 like 10473

version targeted for testing:
 xen                  7ca56cca09ad
baseline version:
 xen                  1c58bb664d8d

------------------------------------------------------------
People who touched revisions under test:
  Andre Przywara <andre.przywara@amd.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Roger Pau Monne <roger.pau@entel.upc.edu>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          fail    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 336 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 07:47:14 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 07: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.xensource.com>)
	id 1RaN49-0007h8-NI; Tue, 13 Dec 2011 07:46:21 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RaN49-0007h3-2P
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 07:46:21 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1323762326!5281658!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18469 invoked from network); 13 Dec 2011 07:45:26 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-2.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 13 Dec 2011 07:45:26 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 13 Dec 2011 07:45:24 +0000
Message-Id: <4EE710A00200007800067274@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 13 Dec 2011 07:45:20 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <1322673664-14642-1-git-send-email-konrad.wilk@oracle.com>
	<1322673664-14642-6-git-send-email-konrad.wilk@oracle.com>
	<4ED755D70200007800064987@nat28.tlf.novell.com>
	<20111212172941.GA8619@phenom.dumpdata.com>
In-Reply-To: <20111212172941.GA8619@phenom.dumpdata.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: kevin.tian@intel.com, xen-devel@lists.xensource.com,
	Ian.Campbell@citrix.com, linux-acpi@vger.kernel.org,
	mike.mcclurg@citrix.com, jeremy@goop.org,
	stefan.bader@canonical.com, linux-kernel@vger.kernel.org,
	rjw@sisk.pl, konrad@kernel.org, liang.tang@oracle.com,
	ke.yu@intel.com, lenb@kernel.org
Subject: Re: [Xen-devel] [PATCH 5/8] ACPI: add processor driver for Xen
 virtual CPUs.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 12.12.11 at 18:29, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> On Thu, Dec 01, 2011 at 09:24:23AM +0000, Jan Beulich wrote:
>> >>> On 30.11.11 at 18:21, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
>> > --- a/drivers/acpi/Makefile
>> > +++ b/drivers/acpi/Makefile
>> > @@ -66,6 +66,7 @@ obj-$(CONFIG_ACPI_CUSTOM_METHOD)+= custom_method.o
>> >  # processor has its own "processor." module_param namespace
>> >  processor-y			:= processor_driver.o processor_throttling.o
>> >  processor-y			+= processor_idle.o processor_thermal.o
>> > +processor-y			+= processor_xen.o
>> 
>> This should minimally be processor-$(CONFIG_XEN), with other things
>> adjusted as necessary.
> 
> I was under the impression that this was required to get the 
> processor_xen.ko
> to be a module. Otherwise it would only compile as built-in.

processor_xen.ko? Why not have all the code go into processor.ko?
(And the original construct didn't aim in that direction either.)

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 07:47:14 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 07: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.xensource.com>)
	id 1RaN49-0007h8-NI; Tue, 13 Dec 2011 07:46:21 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RaN49-0007h3-2P
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 07:46:21 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1323762326!5281658!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18469 invoked from network); 13 Dec 2011 07:45:26 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-2.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 13 Dec 2011 07:45:26 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 13 Dec 2011 07:45:24 +0000
Message-Id: <4EE710A00200007800067274@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 13 Dec 2011 07:45:20 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <1322673664-14642-1-git-send-email-konrad.wilk@oracle.com>
	<1322673664-14642-6-git-send-email-konrad.wilk@oracle.com>
	<4ED755D70200007800064987@nat28.tlf.novell.com>
	<20111212172941.GA8619@phenom.dumpdata.com>
In-Reply-To: <20111212172941.GA8619@phenom.dumpdata.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: kevin.tian@intel.com, xen-devel@lists.xensource.com,
	Ian.Campbell@citrix.com, linux-acpi@vger.kernel.org,
	mike.mcclurg@citrix.com, jeremy@goop.org,
	stefan.bader@canonical.com, linux-kernel@vger.kernel.org,
	rjw@sisk.pl, konrad@kernel.org, liang.tang@oracle.com,
	ke.yu@intel.com, lenb@kernel.org
Subject: Re: [Xen-devel] [PATCH 5/8] ACPI: add processor driver for Xen
 virtual CPUs.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 12.12.11 at 18:29, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> On Thu, Dec 01, 2011 at 09:24:23AM +0000, Jan Beulich wrote:
>> >>> On 30.11.11 at 18:21, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
>> > --- a/drivers/acpi/Makefile
>> > +++ b/drivers/acpi/Makefile
>> > @@ -66,6 +66,7 @@ obj-$(CONFIG_ACPI_CUSTOM_METHOD)+= custom_method.o
>> >  # processor has its own "processor." module_param namespace
>> >  processor-y			:= processor_driver.o processor_throttling.o
>> >  processor-y			+= processor_idle.o processor_thermal.o
>> > +processor-y			+= processor_xen.o
>> 
>> This should minimally be processor-$(CONFIG_XEN), with other things
>> adjusted as necessary.
> 
> I was under the impression that this was required to get the 
> processor_xen.ko
> to be a module. Otherwise it would only compile as built-in.

processor_xen.ko? Why not have all the code go into processor.ko?
(And the original construct didn't aim in that direction either.)

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 07:53:02 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 07:53:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaNA0-0007pC-HX; Tue, 13 Dec 2011 07:52:24 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RaN9y-0007p5-Pz
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 07:52:23 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1323762688!5314068!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27666 invoked from network); 13 Dec 2011 07:51:28 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-6.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 13 Dec 2011 07:51:28 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 13 Dec 2011 07:51:28 +0000
Message-Id: <4EE7120C0200007800067289@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 13 Dec 2011 07:51:24 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: <andres@lagarcavilla.org>
References: <patchbomb.1323462147@xdev.gridcentric.ca>
	<5b9b36648e439bca97b0.1323462155@xdev.gridcentric.ca>
	<4EE5D8640200007800066DDF@nat28.tlf.novell.com>
	<b98ae4e300d803cac48ad7ce3bcf2874.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <b98ae4e300d803cac48ad7ce3bcf2874.squirrel@webmail.lagarcavilla.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: andres@gridcentric.ca, keir.xen@gmail.com, tim@xen.org,
	xen-devel@lists.xensource.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 8 of 9] x86/mm: New domctl: Perform sharing
	audit
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 13.12.11 at 05:22, "Andres Lagar-Cavilla" <andres@lagarcavilla.org> wrote:
>>   >>> On 09.12.11 at 21:22, Andres Lagar-Cavilla <andres@lagarcavilla.org>
>> wrote:
>>> Sharing audits are heavyweight, so instead of performing them inline,
>>> we make them callable via a domctl.
>>
>> As said before - there's again no consumer of this new code within the
>> series, and hence you're asking to add dead code.
> 
> Stands to reason that audit domctls are generally useful things. We
> already have p2m audit domctls with no consumer. And that's not the end of
> the list of things in the tree without a consumer.
> 
> I think your comments about dead code are a bit excessive. The only
> consumer in this tree of the sharing API is memshr. Have a look at how
> memshr is currently linked into blktap2. Maybe we should just submit one
> patch removing all of memshr and the Xen sharing code?

Seems like I should have more clear that my request went more in
the direction of you submitting the (assumed to be existing) consumer
code that you must have used for testing these.

But from a more abstract perspective - yes, dead code should be
removed (and shouldn't have been allowed in) without a clear path
towards a consumer. It's not a law of nature that software
components must only ever grow in size (and usually slow down
accordingly).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 07:53:02 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 07:53:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaNA0-0007pC-HX; Tue, 13 Dec 2011 07:52:24 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RaN9y-0007p5-Pz
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 07:52:23 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1323762688!5314068!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27666 invoked from network); 13 Dec 2011 07:51:28 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-6.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 13 Dec 2011 07:51:28 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 13 Dec 2011 07:51:28 +0000
Message-Id: <4EE7120C0200007800067289@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 13 Dec 2011 07:51:24 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: <andres@lagarcavilla.org>
References: <patchbomb.1323462147@xdev.gridcentric.ca>
	<5b9b36648e439bca97b0.1323462155@xdev.gridcentric.ca>
	<4EE5D8640200007800066DDF@nat28.tlf.novell.com>
	<b98ae4e300d803cac48ad7ce3bcf2874.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <b98ae4e300d803cac48ad7ce3bcf2874.squirrel@webmail.lagarcavilla.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: andres@gridcentric.ca, keir.xen@gmail.com, tim@xen.org,
	xen-devel@lists.xensource.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 8 of 9] x86/mm: New domctl: Perform sharing
	audit
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 13.12.11 at 05:22, "Andres Lagar-Cavilla" <andres@lagarcavilla.org> wrote:
>>   >>> On 09.12.11 at 21:22, Andres Lagar-Cavilla <andres@lagarcavilla.org>
>> wrote:
>>> Sharing audits are heavyweight, so instead of performing them inline,
>>> we make them callable via a domctl.
>>
>> As said before - there's again no consumer of this new code within the
>> series, and hence you're asking to add dead code.
> 
> Stands to reason that audit domctls are generally useful things. We
> already have p2m audit domctls with no consumer. And that's not the end of
> the list of things in the tree without a consumer.
> 
> I think your comments about dead code are a bit excessive. The only
> consumer in this tree of the sharing API is memshr. Have a look at how
> memshr is currently linked into blktap2. Maybe we should just submit one
> patch removing all of memshr and the Xen sharing code?

Seems like I should have more clear that my request went more in
the direction of you submitting the (assumed to be existing) consumer
code that you must have used for testing these.

But from a more abstract perspective - yes, dead code should be
removed (and shouldn't have been allowed in) without a clear path
towards a consumer. It's not a law of nature that software
components must only ever grow in size (and usually slow down
accordingly).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 08:24:50 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 08:24:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaNem-0000Jg-Sd; Tue, 13 Dec 2011 08:24:13 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RaNel-0000Jb-9Y
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 08:24:11 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1323764596!5267977!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=2.0 required=7.0 tests=SUBJECT_RANDOMQ
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31430 invoked from network); 13 Dec 2011 08:23:17 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-12.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 13 Dec 2011 08:23:17 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 13 Dec 2011 08:23:16 +0000
Message-Id: <4EE71980020000780006729E@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 13 Dec 2011 08:23:12 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Keir Fraser" <keir@xen.org>
References: <4EE631A2020000780006701F@nat28.tlf.novell.com>
	<CB0BEF78.35B12%keir@xen.org>
In-Reply-To: <CB0BEF78.35B12%keir@xen.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Allen M Kay <allen.m.kay@intel.com>
Subject: Re: [Xen-devel] [PATCH] VT-d: bind IRQs to CPUs local to the node
 the IOMMU is on
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 12.12.11 at 18:50, Keir Fraser <keir@xen.org> wrote:
> On 12/12/2011 15:53, "Jan Beulich" <JBeulich@suse.com> wrote:
> 
>> This extends create_irq() to take a node parameter, allowing the
>> resulting IRQ to have its destination set to a CPU on that node right
>> away, which is more natural than having to post-adjust this (and
>> get e.g. a new IRQ vector assigned despite a fresh one was just
>> obtained).
>> 
>> All other callers of create_irq() pass NUMA_NO_NODE for the time being.
> 
> I don't know about this one. Does the current 'inefficient' way things work
> really matter?

The depends on the NUMA interconnect. My general perspective on
this is that whenever NUMA locality information is available, we should
aim at making use of it (unless it conflicts with something else*). And
there's certainly ways to go in this respect.

* When coming up with this, I actually looked at whether using the
proximity information now passed down by Dom0 for PCI devices
could be used for properly binding at least MSI interrupts. That didn't
turn out reasonable, since we're already setting the IRQ affinity to
match the pCPU the target vCPU is running on (which is likely
providing greater benefit, as this allows avoiding IPIs; the
efficiency of this can certainly be tweaked - I'm meanwhile thinking
that we might be overly aggressive here, but that's to some part
related to the scheduler apparently migrating vCPU-s more often
than really desirable). But for Xen internal interrupts (like in the case
of the IOMMU ones) this clearly ought to be done when possible. For
the AMD case I just wasn't able to spot whether locality information
is available.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 08:24:50 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 08:24:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaNem-0000Jg-Sd; Tue, 13 Dec 2011 08:24:13 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RaNel-0000Jb-9Y
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 08:24:11 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1323764596!5267977!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=2.0 required=7.0 tests=SUBJECT_RANDOMQ
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31430 invoked from network); 13 Dec 2011 08:23:17 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-12.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 13 Dec 2011 08:23:17 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 13 Dec 2011 08:23:16 +0000
Message-Id: <4EE71980020000780006729E@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 13 Dec 2011 08:23:12 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Keir Fraser" <keir@xen.org>
References: <4EE631A2020000780006701F@nat28.tlf.novell.com>
	<CB0BEF78.35B12%keir@xen.org>
In-Reply-To: <CB0BEF78.35B12%keir@xen.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Allen M Kay <allen.m.kay@intel.com>
Subject: Re: [Xen-devel] [PATCH] VT-d: bind IRQs to CPUs local to the node
 the IOMMU is on
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 12.12.11 at 18:50, Keir Fraser <keir@xen.org> wrote:
> On 12/12/2011 15:53, "Jan Beulich" <JBeulich@suse.com> wrote:
> 
>> This extends create_irq() to take a node parameter, allowing the
>> resulting IRQ to have its destination set to a CPU on that node right
>> away, which is more natural than having to post-adjust this (and
>> get e.g. a new IRQ vector assigned despite a fresh one was just
>> obtained).
>> 
>> All other callers of create_irq() pass NUMA_NO_NODE for the time being.
> 
> I don't know about this one. Does the current 'inefficient' way things work
> really matter?

The depends on the NUMA interconnect. My general perspective on
this is that whenever NUMA locality information is available, we should
aim at making use of it (unless it conflicts with something else*). And
there's certainly ways to go in this respect.

* When coming up with this, I actually looked at whether using the
proximity information now passed down by Dom0 for PCI devices
could be used for properly binding at least MSI interrupts. That didn't
turn out reasonable, since we're already setting the IRQ affinity to
match the pCPU the target vCPU is running on (which is likely
providing greater benefit, as this allows avoiding IPIs; the
efficiency of this can certainly be tweaked - I'm meanwhile thinking
that we might be overly aggressive here, but that's to some part
related to the scheduler apparently migrating vCPU-s more often
than really desirable). But for Xen internal interrupts (like in the case
of the IOMMU ones) this clearly ought to be done when possible. For
the AMD case I just wasn't able to spot whether locality information
is available.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 08:34:05 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 08: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.xensource.com>)
	id 1RaNnO-0000Y0-7S; Tue, 13 Dec 2011 08:33:06 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RaNnM-0000Xs-HE
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 08:33:04 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1323765130!7003002!1
X-Originating-IP: [209.85.214.43]
X-SpamReason: No, hits=2.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,SUBJECT_RANDOMQ,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17070 invoked from network); 13 Dec 2011 08:32:10 -0000
Received: from mail-bw0-f43.google.com (HELO mail-bw0-f43.google.com)
	(209.85.214.43)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 08:32:10 -0000
Received: by bkbzs2 with SMTP id zs2so21103386bkb.30
	for <xen-devel@lists.xensource.com>;
	Tue, 13 Dec 2011 00:32:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=g781bZuLGiHb2GdfKKOOxz3taugu6xj07Ww6CkM2o6c=;
	b=bykw1LmPRs/9kF2FjinFvfbZMOarzgB84maYclsBZs28Ij5EjbxZdgMFRrAC4c3hW1
	f0z+FrhaYW7TqUzDS1SlmR8V4Ig+7/4bBl3oHqxPrwlfkJvpiEKh2O0/owNd/baiGOd4
	vZJq4TYfSGb+9Vx8UpTDXEipAp80HpuL0iY8A=
Received: by 10.205.125.135 with SMTP id gs7mr12329926bkc.51.1323765130171;
	Tue, 13 Dec 2011 00:32:10 -0800 (PST)
Received: from [192.168.1.70] (host81-152-17-11.range81-152.btcentralplus.com.
	[81.152.17.11])
	by mx.google.com with ESMTPS id e9sm17166463bka.15.2011.12.13.00.32.07
	(version=SSLv3 cipher=OTHER); Tue, 13 Dec 2011 00:32:09 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Tue, 13 Dec 2011 08:31:58 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <CB0CBDFE.27180%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH] VT-d: bind IRQs to CPUs local to the node
	the IOMMU is on
Thread-Index: Acy5ca19SSi1+GTRPEGjDfzJREiuVA==
In-Reply-To: <4EE71980020000780006729E@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Allen M Kay <allen.m.kay@intel.com>
Subject: Re: [Xen-devel] [PATCH] VT-d: bind IRQs to CPUs local to the node
 the IOMMU is on
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 13/12/2011 08:23, "Jan Beulich" <JBeulich@suse.com> wrote:

>>>> On 12.12.11 at 18:50, Keir Fraser <keir@xen.org> wrote:
>> On 12/12/2011 15:53, "Jan Beulich" <JBeulich@suse.com> wrote:
>> 
>>> This extends create_irq() to take a node parameter, allowing the
>>> resulting IRQ to have its destination set to a CPU on that node right
>>> away, which is more natural than having to post-adjust this (and
>>> get e.g. a new IRQ vector assigned despite a fresh one was just
>>> obtained).
>>> 
>>> All other callers of create_irq() pass NUMA_NO_NODE for the time being.
>> 
>> I don't know about this one. Does the current 'inefficient' way things work
>> really matter?
> 
> The depends on the NUMA interconnect. My general perspective on
> this is that whenever NUMA locality information is available, we should
> aim at making use of it (unless it conflicts with something else*). And
> there's certainly ways to go in this respect.

Oh, I misunderstood the patch comment, and thought we *were* already
post-adjusting the affinity. But we're not, so this patch does make sense.

Acked-by: Keir Fraser <keir@xen.org>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 08:34:05 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 08: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.xensource.com>)
	id 1RaNnO-0000Y0-7S; Tue, 13 Dec 2011 08:33:06 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RaNnM-0000Xs-HE
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 08:33:04 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1323765130!7003002!1
X-Originating-IP: [209.85.214.43]
X-SpamReason: No, hits=2.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,SUBJECT_RANDOMQ,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17070 invoked from network); 13 Dec 2011 08:32:10 -0000
Received: from mail-bw0-f43.google.com (HELO mail-bw0-f43.google.com)
	(209.85.214.43)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 08:32:10 -0000
Received: by bkbzs2 with SMTP id zs2so21103386bkb.30
	for <xen-devel@lists.xensource.com>;
	Tue, 13 Dec 2011 00:32:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=g781bZuLGiHb2GdfKKOOxz3taugu6xj07Ww6CkM2o6c=;
	b=bykw1LmPRs/9kF2FjinFvfbZMOarzgB84maYclsBZs28Ij5EjbxZdgMFRrAC4c3hW1
	f0z+FrhaYW7TqUzDS1SlmR8V4Ig+7/4bBl3oHqxPrwlfkJvpiEKh2O0/owNd/baiGOd4
	vZJq4TYfSGb+9Vx8UpTDXEipAp80HpuL0iY8A=
Received: by 10.205.125.135 with SMTP id gs7mr12329926bkc.51.1323765130171;
	Tue, 13 Dec 2011 00:32:10 -0800 (PST)
Received: from [192.168.1.70] (host81-152-17-11.range81-152.btcentralplus.com.
	[81.152.17.11])
	by mx.google.com with ESMTPS id e9sm17166463bka.15.2011.12.13.00.32.07
	(version=SSLv3 cipher=OTHER); Tue, 13 Dec 2011 00:32:09 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Tue, 13 Dec 2011 08:31:58 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <CB0CBDFE.27180%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH] VT-d: bind IRQs to CPUs local to the node
	the IOMMU is on
Thread-Index: Acy5ca19SSi1+GTRPEGjDfzJREiuVA==
In-Reply-To: <4EE71980020000780006729E@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Allen M Kay <allen.m.kay@intel.com>
Subject: Re: [Xen-devel] [PATCH] VT-d: bind IRQs to CPUs local to the node
 the IOMMU is on
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 13/12/2011 08:23, "Jan Beulich" <JBeulich@suse.com> wrote:

>>>> On 12.12.11 at 18:50, Keir Fraser <keir@xen.org> wrote:
>> On 12/12/2011 15:53, "Jan Beulich" <JBeulich@suse.com> wrote:
>> 
>>> This extends create_irq() to take a node parameter, allowing the
>>> resulting IRQ to have its destination set to a CPU on that node right
>>> away, which is more natural than having to post-adjust this (and
>>> get e.g. a new IRQ vector assigned despite a fresh one was just
>>> obtained).
>>> 
>>> All other callers of create_irq() pass NUMA_NO_NODE for the time being.
>> 
>> I don't know about this one. Does the current 'inefficient' way things work
>> really matter?
> 
> The depends on the NUMA interconnect. My general perspective on
> this is that whenever NUMA locality information is available, we should
> aim at making use of it (unless it conflicts with something else*). And
> there's certainly ways to go in this respect.

Oh, I misunderstood the patch comment, and thought we *were* already
post-adjusting the affinity. But we're not, so this patch does make sense.

Acked-by: Keir Fraser <keir@xen.org>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 09:11:25 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 09:11:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaONy-0000uc-RW; Tue, 13 Dec 2011 09:10:54 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <george.shuklin@gmail.com>) id 1RaONx-0000uW-JQ
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 09:10:53 +0000
X-Env-Sender: george.shuklin@gmail.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1323767399!7020931!1
X-Originating-IP: [209.85.214.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17036 invoked from network); 13 Dec 2011 09:09:59 -0000
Received: from mail-bw0-f43.google.com (HELO mail-bw0-f43.google.com)
	(209.85.214.43)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 09:09:59 -0000
Received: by bkbzs2 with SMTP id zs2so21226128bkb.30
	for <xen-devel@lists.xensource.com>;
	Tue, 13 Dec 2011 01:09:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=message-id:date:from:user-agent:mime-version:to:subject:references
	:in-reply-to:content-type:content-transfer-encoding;
	bh=sTk/cXG3XgLwch7qf49M1Nww679HeCSwaDp4esxjpA0=;
	b=aE4Mc+NkoriNJw+tDvisM94eFhwjIGNLNiNALLC7G1lbhZbWEqeUnw7ogaKyOI5V1U
	hMgM/vWTWZ8iHUg4CoT+4djMHI8LBXVfQIY2A+Rx7qlUSssBBc4iYG5klKAbHtPTpC1p
	1dBddJYebDLbbZTafEVg6GbgqCFQ9VL7rL0LU=
Received: by 10.205.138.20 with SMTP id iq20mr7275823bkc.86.1323767398965;
	Tue, 13 Dec 2011 01:09:58 -0800 (PST)
Received: from [192.168.40.44] (officecvt.selectel.ru. [188.93.16.50])
	by mx.google.com with ESMTPS id j9sm39179985bkd.2.2011.12.13.01.09.56
	(version=SSLv3 cipher=OTHER); Tue, 13 Dec 2011 01:09:57 -0800 (PST)
Message-ID: <4EE71663.5040308@gmail.com>
Date: Tue, 13 Dec 2011 13:09:55 +0400
From: George Shuklin <george.shuklin@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:9.0) Gecko/20111209 Thunderbird/9.0
MIME-Version: 1.0
To: xen-devel@lists.xensource.com
References: <4EE675A8.3030609@niemail.de>
In-Reply-To: <4EE675A8.3030609@niemail.de>
Subject: Re: [Xen-devel] a ton of kernel issues
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Use suse and Centos5 (not 6) kernels. They works right with xen better 
then others. OpenSUSE release pretty offten, so they have at least 
2.6.34, 2.6.37 and 3.1. Or you can use old centos 2.6.18.

All those kernels is '-xen', not vanilla. pv_ops is still have some 
issues with memory limits, but any new kernel (3.0+) will boot normal 
and operates with very minor glitches. Older pv_ops (f.e. debian 2.6.32) 
have some more major issues.

On 13.12.2011 01:44, Tim Evers wrote:
> Hi folks,
>
> please forgive me if I'm not 100% right on this list but I'm going mad
> about the current xen development as far as the pv_ops kernel are
> involved. I've been using Xen since 3.0 in various productive setups
> without any serious problems for years now.
>
> And now, since the support for the "patched" distro-kernel like debian 5
> run out I'm trying to setup a working xen+pv_ops kernel with regard to
> cpu and ram hotplug and live migration. Nothing special I thought but
> hell I'm totally lost: After testing two month now dozens of
> combinations I was not able to find a single kernel / xen combination
> which supports the abovementioned features. Some crash after hotplug on
> a migrated domu, some crash right at the migration and some crash right
> at the start if vcpu_avail>  vcpus.
>
> I've tested
>
> xen-4.0
> xen-4.1
>
> debian 6 32 and 64 bit (2.6.32-x kernel)
> ubuntu lucid 32 and 64 bit kernels including karmic, natty and even
> oneric backports
>
> I've put some questions on the users mailinglist, wrote bug reports but
> today after two month work on this I'm as stuck as one can get.
>
> Is it possible that there is not a single working xen+pv_ops setup out
> there which matches my needs? I can't believe it.
>
> I appreciate _any_ hint!
>
> Regards
>
> Tim
>
> http://lists.xen.org/archives/html/xen-users/2011-11/msg00553.html
> http://lists.xen.org/archives/html/xen-users/2011-11/msg00523.html
> http://lists.xen.org/archives/html/xen-users/2011-11/msg00295.html
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/893177
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 09:11:25 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 09:11:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaONy-0000uc-RW; Tue, 13 Dec 2011 09:10:54 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <george.shuklin@gmail.com>) id 1RaONx-0000uW-JQ
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 09:10:53 +0000
X-Env-Sender: george.shuklin@gmail.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1323767399!7020931!1
X-Originating-IP: [209.85.214.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17036 invoked from network); 13 Dec 2011 09:09:59 -0000
Received: from mail-bw0-f43.google.com (HELO mail-bw0-f43.google.com)
	(209.85.214.43)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 09:09:59 -0000
Received: by bkbzs2 with SMTP id zs2so21226128bkb.30
	for <xen-devel@lists.xensource.com>;
	Tue, 13 Dec 2011 01:09:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=message-id:date:from:user-agent:mime-version:to:subject:references
	:in-reply-to:content-type:content-transfer-encoding;
	bh=sTk/cXG3XgLwch7qf49M1Nww679HeCSwaDp4esxjpA0=;
	b=aE4Mc+NkoriNJw+tDvisM94eFhwjIGNLNiNALLC7G1lbhZbWEqeUnw7ogaKyOI5V1U
	hMgM/vWTWZ8iHUg4CoT+4djMHI8LBXVfQIY2A+Rx7qlUSssBBc4iYG5klKAbHtPTpC1p
	1dBddJYebDLbbZTafEVg6GbgqCFQ9VL7rL0LU=
Received: by 10.205.138.20 with SMTP id iq20mr7275823bkc.86.1323767398965;
	Tue, 13 Dec 2011 01:09:58 -0800 (PST)
Received: from [192.168.40.44] (officecvt.selectel.ru. [188.93.16.50])
	by mx.google.com with ESMTPS id j9sm39179985bkd.2.2011.12.13.01.09.56
	(version=SSLv3 cipher=OTHER); Tue, 13 Dec 2011 01:09:57 -0800 (PST)
Message-ID: <4EE71663.5040308@gmail.com>
Date: Tue, 13 Dec 2011 13:09:55 +0400
From: George Shuklin <george.shuklin@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:9.0) Gecko/20111209 Thunderbird/9.0
MIME-Version: 1.0
To: xen-devel@lists.xensource.com
References: <4EE675A8.3030609@niemail.de>
In-Reply-To: <4EE675A8.3030609@niemail.de>
Subject: Re: [Xen-devel] a ton of kernel issues
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Use suse and Centos5 (not 6) kernels. They works right with xen better 
then others. OpenSUSE release pretty offten, so they have at least 
2.6.34, 2.6.37 and 3.1. Or you can use old centos 2.6.18.

All those kernels is '-xen', not vanilla. pv_ops is still have some 
issues with memory limits, but any new kernel (3.0+) will boot normal 
and operates with very minor glitches. Older pv_ops (f.e. debian 2.6.32) 
have some more major issues.

On 13.12.2011 01:44, Tim Evers wrote:
> Hi folks,
>
> please forgive me if I'm not 100% right on this list but I'm going mad
> about the current xen development as far as the pv_ops kernel are
> involved. I've been using Xen since 3.0 in various productive setups
> without any serious problems for years now.
>
> And now, since the support for the "patched" distro-kernel like debian 5
> run out I'm trying to setup a working xen+pv_ops kernel with regard to
> cpu and ram hotplug and live migration. Nothing special I thought but
> hell I'm totally lost: After testing two month now dozens of
> combinations I was not able to find a single kernel / xen combination
> which supports the abovementioned features. Some crash after hotplug on
> a migrated domu, some crash right at the migration and some crash right
> at the start if vcpu_avail>  vcpus.
>
> I've tested
>
> xen-4.0
> xen-4.1
>
> debian 6 32 and 64 bit (2.6.32-x kernel)
> ubuntu lucid 32 and 64 bit kernels including karmic, natty and even
> oneric backports
>
> I've put some questions on the users mailinglist, wrote bug reports but
> today after two month work on this I'm as stuck as one can get.
>
> Is it possible that there is not a single working xen+pv_ops setup out
> there which matches my needs? I can't believe it.
>
> I appreciate _any_ hint!
>
> Regards
>
> Tim
>
> http://lists.xen.org/archives/html/xen-users/2011-11/msg00553.html
> http://lists.xen.org/archives/html/xen-users/2011-11/msg00523.html
> http://lists.xen.org/archives/html/xen-users/2011-11/msg00295.html
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/893177
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 09:27:58 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 09:27:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaOdt-00015Y-E1; Tue, 13 Dec 2011 09:27:21 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <liang.tang@oracle.com>) id 1RaOdr-00015T-D0
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 09:27:19 +0000
X-Env-Sender: liang.tang@oracle.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1323768361!51935695!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQzMjQ0Mw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17043 invoked from network); 13 Dec 2011 09:26:02 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-13.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Dec 2011 09:26:02 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pBD9QF2u007757
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 13 Dec 2011 09:26:16 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pBD9QB9x003237
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 13 Dec 2011 09:26:14 GMT
Received: from abhmt105.oracle.com (abhmt105.oracle.com [141.146.116.57])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pBD9Q3Cp004127; Tue, 13 Dec 2011 03:26:03 -0600
Received: from [10.182.38.104] (/10.182.38.104)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 13 Dec 2011 01:26:03 -0800
Message-ID: <4EE71A62.9050700@oracle.com>
Date: Tue, 13 Dec 2011 17:26:58 +0800
From: liang tang <liang.tang@oracle.com>
Organization: Oracle Corporation
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.9.2.23) Gecko/20110920 Thunderbird/3.1.15
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1322673664-14642-1-git-send-email-konrad.wilk@oracle.com>
	<1322673664-14642-6-git-send-email-konrad.wilk@oracle.com>
	<4ED755D70200007800064987@nat28.tlf.novell.com>
	<20111212172941.GA8619@phenom.dumpdata.com>
	<4EE710A00200007800067274@nat28.tlf.novell.com>
In-Reply-To: <4EE710A00200007800067274@nat28.tlf.novell.com>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090205.4EE71A3A.0064,ss=1,re=0.000,fgs=0
Cc: jeremy@goop.org, xen-devel@lists.xensource.com, Ian.Campbell@citrix.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	mike.mcclurg@citrix.com, kevin.tian@intel.com,
	stefan.bader@canonical.com, linux-kernel@vger.kernel.org,
	rjw@sisk.pl, konrad@kernel.org, ke.yu@intel.com,
	linux-acpi@vger.kernel.org, lenb@kernel.org
Subject: Re: [Xen-devel] [PATCH 5/8] ACPI: add processor driver for Xen
 virtual CPUs.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 2011-12-13 15:45, Jan Beulich wrote:
>>>> On 12.12.11 at 18:29, Konrad Rzeszutek Wilk<konrad.wilk@oracle.com>  wrote:
>> On Thu, Dec 01, 2011 at 09:24:23AM +0000, Jan Beulich wrote:
>>>>>> On 30.11.11 at 18:21, Konrad Rzeszutek Wilk<konrad.wilk@oracle.com>  wrote:
>>>> --- a/drivers/acpi/Makefile
>>>> +++ b/drivers/acpi/Makefile
>>>> @@ -66,6 +66,7 @@ obj-$(CONFIG_ACPI_CUSTOM_METHOD)+= custom_method.o
>>>>   # processor has its own "processor." module_param namespace
>>>>   processor-y			:= processor_driver.o processor_throttling.o
>>>>   processor-y			+= processor_idle.o processor_thermal.o
>>>> +processor-y			+= processor_xen.o
>>> This should minimally be processor-$(CONFIG_XEN), with other things
>>> adjusted as necessary.
>> I was under the impression that this was required to get the
>> processor_xen.ko
>> to be a module. Otherwise it would only compile as built-in.
> processor_xen.ko? Why not have all the code go into processor.ko?
> (And the original construct didn't aim in that direction either.)
>
> Jan
>
the code about driver function which kernel 
require(drivers/acpi/processor_xen.c )  build into processor.ko.
the code which have more relation with xen 
(drivers/xen/acpi_processor.c)  did not build into processor.ko.
liang

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 09:27:58 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 09:27:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaOdt-00015Y-E1; Tue, 13 Dec 2011 09:27:21 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <liang.tang@oracle.com>) id 1RaOdr-00015T-D0
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 09:27:19 +0000
X-Env-Sender: liang.tang@oracle.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1323768361!51935695!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQzMjQ0Mw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17043 invoked from network); 13 Dec 2011 09:26:02 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-13.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Dec 2011 09:26:02 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pBD9QF2u007757
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 13 Dec 2011 09:26:16 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pBD9QB9x003237
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 13 Dec 2011 09:26:14 GMT
Received: from abhmt105.oracle.com (abhmt105.oracle.com [141.146.116.57])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pBD9Q3Cp004127; Tue, 13 Dec 2011 03:26:03 -0600
Received: from [10.182.38.104] (/10.182.38.104)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 13 Dec 2011 01:26:03 -0800
Message-ID: <4EE71A62.9050700@oracle.com>
Date: Tue, 13 Dec 2011 17:26:58 +0800
From: liang tang <liang.tang@oracle.com>
Organization: Oracle Corporation
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.9.2.23) Gecko/20110920 Thunderbird/3.1.15
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1322673664-14642-1-git-send-email-konrad.wilk@oracle.com>
	<1322673664-14642-6-git-send-email-konrad.wilk@oracle.com>
	<4ED755D70200007800064987@nat28.tlf.novell.com>
	<20111212172941.GA8619@phenom.dumpdata.com>
	<4EE710A00200007800067274@nat28.tlf.novell.com>
In-Reply-To: <4EE710A00200007800067274@nat28.tlf.novell.com>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090205.4EE71A3A.0064,ss=1,re=0.000,fgs=0
Cc: jeremy@goop.org, xen-devel@lists.xensource.com, Ian.Campbell@citrix.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	mike.mcclurg@citrix.com, kevin.tian@intel.com,
	stefan.bader@canonical.com, linux-kernel@vger.kernel.org,
	rjw@sisk.pl, konrad@kernel.org, ke.yu@intel.com,
	linux-acpi@vger.kernel.org, lenb@kernel.org
Subject: Re: [Xen-devel] [PATCH 5/8] ACPI: add processor driver for Xen
 virtual CPUs.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 2011-12-13 15:45, Jan Beulich wrote:
>>>> On 12.12.11 at 18:29, Konrad Rzeszutek Wilk<konrad.wilk@oracle.com>  wrote:
>> On Thu, Dec 01, 2011 at 09:24:23AM +0000, Jan Beulich wrote:
>>>>>> On 30.11.11 at 18:21, Konrad Rzeszutek Wilk<konrad.wilk@oracle.com>  wrote:
>>>> --- a/drivers/acpi/Makefile
>>>> +++ b/drivers/acpi/Makefile
>>>> @@ -66,6 +66,7 @@ obj-$(CONFIG_ACPI_CUSTOM_METHOD)+= custom_method.o
>>>>   # processor has its own "processor." module_param namespace
>>>>   processor-y			:= processor_driver.o processor_throttling.o
>>>>   processor-y			+= processor_idle.o processor_thermal.o
>>>> +processor-y			+= processor_xen.o
>>> This should minimally be processor-$(CONFIG_XEN), with other things
>>> adjusted as necessary.
>> I was under the impression that this was required to get the
>> processor_xen.ko
>> to be a module. Otherwise it would only compile as built-in.
> processor_xen.ko? Why not have all the code go into processor.ko?
> (And the original construct didn't aim in that direction either.)
>
> Jan
>
the code about driver function which kernel 
require(drivers/acpi/processor_xen.c )  build into processor.ko.
the code which have more relation with xen 
(drivers/xen/acpi_processor.c)  did not build into processor.ko.
liang

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 09:30:13 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 09: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.xensource.com>)
	id 1RaOgJ-0001B5-D5; Tue, 13 Dec 2011 09:29:51 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RaOgH-0001AW-Mh
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 09:29:49 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1323768534!7022555!1
X-Originating-IP: [209.85.216.50]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4484 invoked from network); 13 Dec 2011 09:28:55 -0000
Received: from mail-qw0-f50.google.com (HELO mail-qw0-f50.google.com)
	(209.85.216.50)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 09:28:55 -0000
Received: by qaea17 with SMTP id a17so33205897qae.9
	for <xen-devel@lists.xensource.com>;
	Tue, 13 Dec 2011 01:28:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=Ymfx+PH4KRzww91ZZBiksFIwEgmxFd5Ln5jpW04l+C0=;
	b=KTKo4b3iPDzz4M0r5CLM0zWIXpPbMpCOPdpr+AAZyFK9IjPp9JVSCX5VeMgQVWtv0h
	jfHW87VByQJlOFMgotZtKMP+PvXg9Dl8kXiNRKFKeTH4TN4uLHIlJi9PUd5IZKjfN7yR
	IGvCSAPnoBYPexIbQqAPKZjaQ1C6ug42CUC78=
Received: by 10.224.211.194 with SMTP id gp2mr1641933qab.99.1323768534178;
	Tue, 13 Dec 2011 01:28:54 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id dj8sm16234641qab.19.2011.12.13.01.28.52
	(version=TLSv1/SSLv3 cipher=OTHER);
	Tue, 13 Dec 2011 01:28:53 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: a0f9c898470cedc6d9009fde182a5bd73e587a28
Message-Id: <a0f9c898470cedc6d900.1323768376@loki.upc.es>
In-Reply-To: <patchbomb.1323768375@loki.upc.es>
References: <patchbomb.1323768375@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Tue, 13 Dec 2011 10:26:16 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 01 of 14 v4] xenbackendd: pass type of block
 device to hotplug script
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1317386335 -7200
# Node ID a0f9c898470cedc6d9009fde182a5bd73e587a28
# Parent  1c58bb664d8d55e475d179cb5f81693991859fc8
xenbackendd: pass type of block device to hotplug script

Pass the type of block device to attach to the block script instead
of reading it from xenstore, since new Xen versions don't make a
difference between a block device or an image.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 1c58bb664d8d -r a0f9c898470c tools/hotplug/NetBSD/block
--- a/tools/hotplug/NetBSD/block	Thu Dec 08 17:15:16 2011 +0000
+++ b/tools/hotplug/NetBSD/block	Fri Sep 30 14:38:55 2011 +0200
@@ -19,7 +19,7 @@ error() {
 
 xpath=$1
 xstatus=$2
-xtype=$(xenstore-read "$xpath/type")
+xtype=$3
 xparams=$(xenstore-read "$xpath/params")
 
 case $xstatus in
diff -r 1c58bb664d8d -r a0f9c898470c tools/xenbackendd/xenbackendd.c
--- a/tools/xenbackendd/xenbackendd.c	Thu Dec 08 17:15:16 2011 +0000
+++ b/tools/xenbackendd/xenbackendd.c	Fri Sep 30 14:38:55 2011 +0200
@@ -89,15 +89,15 @@ dodebug(const char *fmt, ...)
 }
 
 static void
-doexec(const char *cmd, const char *arg1, const char *arg2)
+doexec(const char *cmd, const char *arg1, const char *arg2, const char *arg3)
 {
-	dodebug("exec %s %s %s", cmd, arg1, arg2);
+	dodebug("exec %s %s %s %s", cmd, arg1, arg2, arg3);
 	switch(vfork()) {
 	case -1:
 		dolog(LOG_ERR, "can't vfork: %s", strerror(errno));
 		break;
 	case 0:
-		execl(cmd, cmd, arg1, arg2, NULL);
+		execl(cmd, cmd, arg1, arg2, arg3, NULL);
 		dolog(LOG_ERR, "can't exec %s: %s", cmd, strerror(errno));
 		exit(EXIT_FAILURE);
 		/* NOTREACHED */
@@ -145,11 +145,14 @@ xen_setup(void)
 int
 main(int argc, char * const argv[])
 {
+	struct stat stab;
 	char **vec;
 	unsigned int num;
 	char *s;
 	int state;
 	char *sstate;
+	char *stype;
+	char *params;
 	char *p;
 	char buf[80];
 	int type;
@@ -297,11 +300,38 @@ main(int argc, char * const argv[])
 				    strerror(errno));
 				goto next2;
 			}
-			doexec(s, vec[XS_WATCH_PATH], sstate);
+			doexec(s, vec[XS_WATCH_PATH], sstate, NULL);
 			break;
 
 		case DEVTYPE_VBD:
-			doexec(vbd_script, vec[XS_WATCH_PATH], sstate);
+			/* check if given file is a block device or a raw image */
+			snprintf(buf, sizeof(buf), "%s/params", vec[XS_WATCH_PATH]);
+			params = xs_read(xs, XBT_NULL, buf, 0);
+			if(params == NULL) {
+				dolog(LOG_ERR,
+					"Failed to read %s (%s)", buf, strerror(errno));
+				goto next2;
+			}
+			if (stat(params, &stab) < 0) {
+				dolog(LOG_ERR,
+					"Failed to get info about %s (%s)", params,
+					strerror(errno));
+				goto next3;
+			}
+			stype = NULL;
+			if (S_ISBLK(stab.st_mode))
+				stype = "phy";
+			if (S_ISREG(stab.st_mode))
+				stype = "file";
+			if (stype == NULL) {
+				dolog(LOG_ERR,
+					"Failed to attach %s (not a block device or raw image)",
+					params, strerror(errno));
+				goto next3;
+			}
+			doexec(vbd_script, vec[XS_WATCH_PATH], sstate, stype);
+next3:
+			free(params);
 			break;
 
 		default:

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 09:30:13 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 09: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.xensource.com>)
	id 1RaOgJ-0001B5-D5; Tue, 13 Dec 2011 09:29:51 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RaOgH-0001AW-Mh
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 09:29:49 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1323768534!7022555!1
X-Originating-IP: [209.85.216.50]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4484 invoked from network); 13 Dec 2011 09:28:55 -0000
Received: from mail-qw0-f50.google.com (HELO mail-qw0-f50.google.com)
	(209.85.216.50)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 09:28:55 -0000
Received: by qaea17 with SMTP id a17so33205897qae.9
	for <xen-devel@lists.xensource.com>;
	Tue, 13 Dec 2011 01:28:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=Ymfx+PH4KRzww91ZZBiksFIwEgmxFd5Ln5jpW04l+C0=;
	b=KTKo4b3iPDzz4M0r5CLM0zWIXpPbMpCOPdpr+AAZyFK9IjPp9JVSCX5VeMgQVWtv0h
	jfHW87VByQJlOFMgotZtKMP+PvXg9Dl8kXiNRKFKeTH4TN4uLHIlJi9PUd5IZKjfN7yR
	IGvCSAPnoBYPexIbQqAPKZjaQ1C6ug42CUC78=
Received: by 10.224.211.194 with SMTP id gp2mr1641933qab.99.1323768534178;
	Tue, 13 Dec 2011 01:28:54 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id dj8sm16234641qab.19.2011.12.13.01.28.52
	(version=TLSv1/SSLv3 cipher=OTHER);
	Tue, 13 Dec 2011 01:28:53 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: a0f9c898470cedc6d9009fde182a5bd73e587a28
Message-Id: <a0f9c898470cedc6d900.1323768376@loki.upc.es>
In-Reply-To: <patchbomb.1323768375@loki.upc.es>
References: <patchbomb.1323768375@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Tue, 13 Dec 2011 10:26:16 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 01 of 14 v4] xenbackendd: pass type of block
 device to hotplug script
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1317386335 -7200
# Node ID a0f9c898470cedc6d9009fde182a5bd73e587a28
# Parent  1c58bb664d8d55e475d179cb5f81693991859fc8
xenbackendd: pass type of block device to hotplug script

Pass the type of block device to attach to the block script instead
of reading it from xenstore, since new Xen versions don't make a
difference between a block device or an image.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 1c58bb664d8d -r a0f9c898470c tools/hotplug/NetBSD/block
--- a/tools/hotplug/NetBSD/block	Thu Dec 08 17:15:16 2011 +0000
+++ b/tools/hotplug/NetBSD/block	Fri Sep 30 14:38:55 2011 +0200
@@ -19,7 +19,7 @@ error() {
 
 xpath=$1
 xstatus=$2
-xtype=$(xenstore-read "$xpath/type")
+xtype=$3
 xparams=$(xenstore-read "$xpath/params")
 
 case $xstatus in
diff -r 1c58bb664d8d -r a0f9c898470c tools/xenbackendd/xenbackendd.c
--- a/tools/xenbackendd/xenbackendd.c	Thu Dec 08 17:15:16 2011 +0000
+++ b/tools/xenbackendd/xenbackendd.c	Fri Sep 30 14:38:55 2011 +0200
@@ -89,15 +89,15 @@ dodebug(const char *fmt, ...)
 }
 
 static void
-doexec(const char *cmd, const char *arg1, const char *arg2)
+doexec(const char *cmd, const char *arg1, const char *arg2, const char *arg3)
 {
-	dodebug("exec %s %s %s", cmd, arg1, arg2);
+	dodebug("exec %s %s %s %s", cmd, arg1, arg2, arg3);
 	switch(vfork()) {
 	case -1:
 		dolog(LOG_ERR, "can't vfork: %s", strerror(errno));
 		break;
 	case 0:
-		execl(cmd, cmd, arg1, arg2, NULL);
+		execl(cmd, cmd, arg1, arg2, arg3, NULL);
 		dolog(LOG_ERR, "can't exec %s: %s", cmd, strerror(errno));
 		exit(EXIT_FAILURE);
 		/* NOTREACHED */
@@ -145,11 +145,14 @@ xen_setup(void)
 int
 main(int argc, char * const argv[])
 {
+	struct stat stab;
 	char **vec;
 	unsigned int num;
 	char *s;
 	int state;
 	char *sstate;
+	char *stype;
+	char *params;
 	char *p;
 	char buf[80];
 	int type;
@@ -297,11 +300,38 @@ main(int argc, char * const argv[])
 				    strerror(errno));
 				goto next2;
 			}
-			doexec(s, vec[XS_WATCH_PATH], sstate);
+			doexec(s, vec[XS_WATCH_PATH], sstate, NULL);
 			break;
 
 		case DEVTYPE_VBD:
-			doexec(vbd_script, vec[XS_WATCH_PATH], sstate);
+			/* check if given file is a block device or a raw image */
+			snprintf(buf, sizeof(buf), "%s/params", vec[XS_WATCH_PATH]);
+			params = xs_read(xs, XBT_NULL, buf, 0);
+			if(params == NULL) {
+				dolog(LOG_ERR,
+					"Failed to read %s (%s)", buf, strerror(errno));
+				goto next2;
+			}
+			if (stat(params, &stab) < 0) {
+				dolog(LOG_ERR,
+					"Failed to get info about %s (%s)", params,
+					strerror(errno));
+				goto next3;
+			}
+			stype = NULL;
+			if (S_ISBLK(stab.st_mode))
+				stype = "phy";
+			if (S_ISREG(stab.st_mode))
+				stype = "file";
+			if (stype == NULL) {
+				dolog(LOG_ERR,
+					"Failed to attach %s (not a block device or raw image)",
+					params, strerror(errno));
+				goto next3;
+			}
+			doexec(vbd_script, vec[XS_WATCH_PATH], sstate, stype);
+next3:
+			free(params);
 			break;
 
 		default:

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 09:30:14 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 09:30:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaOgO-0001C0-Ar; Tue, 13 Dec 2011 09:29:56 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RaOgM-0001Av-Ur
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 09:29:55 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1323768509!51936179!2
X-Originating-IP: [209.85.216.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25874 invoked from network); 13 Dec 2011 09:28:37 -0000
Received: from mail-qy0-f171.google.com (HELO mail-qy0-f171.google.com)
	(209.85.216.171)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 09:28:37 -0000
Received: by mail-qy0-f171.google.com with SMTP id c20so52043537qcs.30
	for <xen-devel@lists.xensource.com>;
	Tue, 13 Dec 2011 01:29:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=xu1g4GDBWFCdtvJtpsSyzGJWdeDZObIo6wQXrYjyP0Y=;
	b=W75t7S3ZzXRyeBFIvZT8Mj5Y4YZNo8pNnuoNUsjsUv1hrOo7Fll6UzHXsODci1Dz37
	oKVLYo7N1K9dCiV1oxCcTUhW/Mu/HhXcMNxOHYUeYFn+CTS9DSPhG6YKc7airUTIZQ0q
	ZiVqeXCeQe9bpi+4OiotA8Efpj0EKUDjc00r8=
Received: by 10.224.214.138 with SMTP id ha10mr1647511qab.41.1323768540507;
	Tue, 13 Dec 2011 01:29:00 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id dj8sm16234641qab.19.2011.12.13.01.28.57
	(version=TLSv1/SSLv3 cipher=OTHER);
	Tue, 13 Dec 2011 01:28:58 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 573a246bf0c6b3ad01473d350a2c3c5aad30c351
Message-Id: <573a246bf0c6b3ad0147.1323768378@loki.upc.es>
In-Reply-To: <patchbomb.1323768375@loki.upc.es>
References: <patchbomb.1323768375@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Tue, 13 Dec 2011 10:26:18 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 03 of 14 v4] libxl: add libxl__forkexec function
	to libxl_exec
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1323766195 -3600
# Node ID 573a246bf0c6b3ad01473d350a2c3c5aad30c351
# Parent  e3907ed912201e5270ff19265fab2c979b3929cc
libxl: add libxl__forkexec function to libxl_exec

Add a new function to libxl_exec that performs a fork and executes
the passed arguments using libxl__exec.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r e3907ed91220 -r 573a246bf0c6 tools/libxl/libxl_exec.c
--- a/tools/libxl/libxl_exec.c	Fri Sep 30 14:38:55 2011 +0200
+++ b/tools/libxl/libxl_exec.c	Tue Dec 13 09:49:55 2011 +0100
@@ -450,6 +450,39 @@ int libxl__spawn_check(libxl__gc *gc, li
     return ERROR_FAIL;
 }
 
+int libxl__forkexec(libxl__gc *gc, int stdinfd, int stdoutfd,
+                    int stderrfd, char **args)
+{
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+    int status;
+    int rc = 0;
+    pid_t pid = fork();
+
+    switch (pid) {
+    case -1:
+        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "fork failed\n");
+        rc = -1;
+        break;
+    case 0:
+        libxl__exec(stdinfd, stdoutfd, stderrfd, args[0], args);
+        /* libxl__exec never returns */
+    default:
+        while (waitpid(pid, &status, 0) < 0) {
+            if (errno != EINTR) {
+                LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "waitpid failed\n");
+                rc = -1;
+                break;
+            }
+        }
+        if (status)
+            libxl_report_child_exitstatus(ctx, LIBXL__LOG_ERROR,
+                                          args[0], pid, status);
+        rc = status;
+        break;
+    }
+    return rc;
+}
+
 /*
  * Local variables:
  * mode: C
diff -r e3907ed91220 -r 573a246bf0c6 tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Fri Sep 30 14:38:55 2011 +0200
+++ b/tools/libxl/libxl_internal.h	Tue Dec 13 09:49:55 2011 +0100
@@ -400,6 +400,22 @@ _hidden int libxl__spawn_check(libxl__gc
 _hidden void libxl__exec(int stdinfd, int stdoutfd, int stderrfd,
                const char *arg0, char **args); // logs errors, never returns
 
+/*
+ * libxl__forkexec - Executes a file synchronously
+ * gc: allocation pool
+ * stdinfd, stdoutfd, stderrfd: fds to pass to libxl__exec
+ * args: file to execute and arguments to pass in the following format
+ *      args[0]: file to execute
+ *      args[1]: first argument to pass to the called program
+ *      ...
+ *      args[n-1]: (n-1)th argument to pass to the called program
+ *      args[n]: NULL
+ *
+ * Returns the exit status, as reported by waitpid.
+ */
+_hidden int libxl__forkexec(libxl__gc *gc, int stdinfd, int stdoutfd,
+                            int stderrfd, char **args);
+
 /* from xl_create */
 _hidden int libxl__domain_make(libxl__gc *gc, libxl_domain_create_info *info, uint32_t *domid);
 _hidden int libxl__domain_build(libxl__gc *gc,

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 09:30:14 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 09:30:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaOgO-0001C0-Ar; Tue, 13 Dec 2011 09:29:56 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RaOgM-0001Av-Ur
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 09:29:55 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1323768509!51936179!2
X-Originating-IP: [209.85.216.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25874 invoked from network); 13 Dec 2011 09:28:37 -0000
Received: from mail-qy0-f171.google.com (HELO mail-qy0-f171.google.com)
	(209.85.216.171)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 09:28:37 -0000
Received: by mail-qy0-f171.google.com with SMTP id c20so52043537qcs.30
	for <xen-devel@lists.xensource.com>;
	Tue, 13 Dec 2011 01:29:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=xu1g4GDBWFCdtvJtpsSyzGJWdeDZObIo6wQXrYjyP0Y=;
	b=W75t7S3ZzXRyeBFIvZT8Mj5Y4YZNo8pNnuoNUsjsUv1hrOo7Fll6UzHXsODci1Dz37
	oKVLYo7N1K9dCiV1oxCcTUhW/Mu/HhXcMNxOHYUeYFn+CTS9DSPhG6YKc7airUTIZQ0q
	ZiVqeXCeQe9bpi+4OiotA8Efpj0EKUDjc00r8=
Received: by 10.224.214.138 with SMTP id ha10mr1647511qab.41.1323768540507;
	Tue, 13 Dec 2011 01:29:00 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id dj8sm16234641qab.19.2011.12.13.01.28.57
	(version=TLSv1/SSLv3 cipher=OTHER);
	Tue, 13 Dec 2011 01:28:58 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 573a246bf0c6b3ad01473d350a2c3c5aad30c351
Message-Id: <573a246bf0c6b3ad0147.1323768378@loki.upc.es>
In-Reply-To: <patchbomb.1323768375@loki.upc.es>
References: <patchbomb.1323768375@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Tue, 13 Dec 2011 10:26:18 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 03 of 14 v4] libxl: add libxl__forkexec function
	to libxl_exec
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1323766195 -3600
# Node ID 573a246bf0c6b3ad01473d350a2c3c5aad30c351
# Parent  e3907ed912201e5270ff19265fab2c979b3929cc
libxl: add libxl__forkexec function to libxl_exec

Add a new function to libxl_exec that performs a fork and executes
the passed arguments using libxl__exec.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r e3907ed91220 -r 573a246bf0c6 tools/libxl/libxl_exec.c
--- a/tools/libxl/libxl_exec.c	Fri Sep 30 14:38:55 2011 +0200
+++ b/tools/libxl/libxl_exec.c	Tue Dec 13 09:49:55 2011 +0100
@@ -450,6 +450,39 @@ int libxl__spawn_check(libxl__gc *gc, li
     return ERROR_FAIL;
 }
 
+int libxl__forkexec(libxl__gc *gc, int stdinfd, int stdoutfd,
+                    int stderrfd, char **args)
+{
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+    int status;
+    int rc = 0;
+    pid_t pid = fork();
+
+    switch (pid) {
+    case -1:
+        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "fork failed\n");
+        rc = -1;
+        break;
+    case 0:
+        libxl__exec(stdinfd, stdoutfd, stderrfd, args[0], args);
+        /* libxl__exec never returns */
+    default:
+        while (waitpid(pid, &status, 0) < 0) {
+            if (errno != EINTR) {
+                LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "waitpid failed\n");
+                rc = -1;
+                break;
+            }
+        }
+        if (status)
+            libxl_report_child_exitstatus(ctx, LIBXL__LOG_ERROR,
+                                          args[0], pid, status);
+        rc = status;
+        break;
+    }
+    return rc;
+}
+
 /*
  * Local variables:
  * mode: C
diff -r e3907ed91220 -r 573a246bf0c6 tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Fri Sep 30 14:38:55 2011 +0200
+++ b/tools/libxl/libxl_internal.h	Tue Dec 13 09:49:55 2011 +0100
@@ -400,6 +400,22 @@ _hidden int libxl__spawn_check(libxl__gc
 _hidden void libxl__exec(int stdinfd, int stdoutfd, int stderrfd,
                const char *arg0, char **args); // logs errors, never returns
 
+/*
+ * libxl__forkexec - Executes a file synchronously
+ * gc: allocation pool
+ * stdinfd, stdoutfd, stderrfd: fds to pass to libxl__exec
+ * args: file to execute and arguments to pass in the following format
+ *      args[0]: file to execute
+ *      args[1]: first argument to pass to the called program
+ *      ...
+ *      args[n-1]: (n-1)th argument to pass to the called program
+ *      args[n]: NULL
+ *
+ * Returns the exit status, as reported by waitpid.
+ */
+_hidden int libxl__forkexec(libxl__gc *gc, int stdinfd, int stdoutfd,
+                            int stderrfd, char **args);
+
 /* from xl_create */
 _hidden int libxl__domain_make(libxl__gc *gc, libxl_domain_create_info *info, uint32_t *domid);
 _hidden int libxl__domain_build(libxl__gc *gc,

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 09:30:14 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 09:30:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaOgW-0001FL-8F; Tue, 13 Dec 2011 09:30:04 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RaOgU-0001Cr-9U
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 09:30:02 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1323768509!51936179!4
X-Originating-IP: [209.85.216.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26571 invoked from network); 13 Dec 2011 09:28:47 -0000
Received: from mail-qy0-f171.google.com (HELO mail-qy0-f171.google.com)
	(209.85.216.171)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 09:28:47 -0000
Received: by mail-qy0-f171.google.com with SMTP id c20so52043537qcs.30
	for <xen-devel@lists.xensource.com>;
	Tue, 13 Dec 2011 01:29:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=JIcqX+lg4T/PHU5C/2iXE0cX3HZ+Kwpc1q/17GvCQIA=;
	b=QV3/5p2C3xF2nAokE7XVu3X5gIkahy6XcYHzXLfnYqhJTTRUuEPQPgW0fOzJs5brN8
	bomot9AcQ4g6oknBFF0jXGhd/3IkRwNHAMqRSR0jES8YK4qW3Kn2TYQKAq47sAwfcaxZ
	xA9bVYlycOr7USvJy89nEU9/kiIl5XSBfbFz8=
Received: by 10.224.187.20 with SMTP id cu20mr1640826qab.43.1323768549870;
	Tue, 13 Dec 2011 01:29:09 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id dj8sm16234641qab.19.2011.12.13.01.29.08
	(version=TLSv1/SSLv3 cipher=OTHER);
	Tue, 13 Dec 2011 01:29:09 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 30f2db9a780fe36eeacf6dabd76bb2577248edea
Message-Id: <30f2db9a780fe36eeacf.1323768383@loki.upc.es>
In-Reply-To: <patchbomb.1323768375@loki.upc.es>
References: <patchbomb.1323768375@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Tue, 13 Dec 2011 10:26:23 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 08 of 14 v4] xenbackendd: pass action to hotplug
	script
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1323766195 -3600
# Node ID 30f2db9a780fe36eeacf6dabd76bb2577248edea
# Parent  51404e6e2d6f4d53a14deadca4b62748d449782b
xenbackendd: pass action to hotplug script

Pass an action to hotplug scripts instead of a xenbus state.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 51404e6e2d6f -r 30f2db9a780f tools/xenbackendd/xenbackendd.c
--- a/tools/xenbackendd/xenbackendd.c	Tue Dec 13 09:49:55 2011 +0100
+++ b/tools/xenbackendd/xenbackendd.c	Tue Dec 13 09:49:55 2011 +0100
@@ -34,6 +34,9 @@
 #define DEVTYPE_VIF 1
 #define DEVTYPE_VBD 2
 
+#define CONNECT "1"
+#define DISCONNECT "2"
+
 #define DOMAIN_PATH "/local/domain/0"
 
 #ifndef XEN_SCRIPT_DIR
@@ -150,6 +153,7 @@ main(int argc, char * const argv[])
 	unsigned int num;
 	char *s;
 	int state;
+	char *action;
 	char *sstate;
 	char *stype;
 	char *params;
@@ -300,7 +304,8 @@ main(int argc, char * const argv[])
 				    strerror(errno));
 				goto next2;
 			}
-			doexec(s, vec[XS_WATCH_PATH], sstate, NULL);
+			action = (state == 6 ? DISCONNECT : CONNECT);
+			doexec(s, vec[XS_WATCH_PATH], action, NULL);
 			break;
 
 		case DEVTYPE_VBD:
@@ -329,7 +334,8 @@ main(int argc, char * const argv[])
 					params, strerror(errno));
 				goto next3;
 			}
-			doexec(vbd_script, vec[XS_WATCH_PATH], sstate, stype);
+			action = (state == 6 ? DISCONNECT : CONNECT);
+			doexec(vbd_script, vec[XS_WATCH_PATH], action, stype);
 next3:
 			free(params);
 			break;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 09:30:14 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 09:30:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaOgU-0001EZ-Pw; Tue, 13 Dec 2011 09:30:02 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RaOgS-0001Bn-Sa
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 09:30:01 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1323768534!7022555!2
X-Originating-IP: [209.85.216.50]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5604 invoked from network); 13 Dec 2011 09:29:06 -0000
Received: from mail-qw0-f50.google.com (HELO mail-qw0-f50.google.com)
	(209.85.216.50)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 09:29:06 -0000
Received: by mail-qw0-f50.google.com with SMTP id a17so33205897qae.9
	for <xen-devel@lists.xensource.com>;
	Tue, 13 Dec 2011 01:29:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=+QsSsAH8dfIE8YARCFIDyqTHHVzX3YhnMEz9athK9eU=;
	b=PiS7FRwEhlprKY5JFhwhsfeiQO5jgnpzKVeb1n5uDYYv4GZEgGOKs0yafXMyWXEB0t
	DMMtapAfwuv5cpMT0UnySZEzMSbxqpvdiVXzIRC0xHJo7rUXVzGu4mZCOiH4jKzxwqog
	7XzSZ5Kh5ZgsXzu4Tya9prNnKYKUQIMiw/l2M=
Received: by 10.224.1.136 with SMTP id 8mr1668057qaf.54.1323768546171;
	Tue, 13 Dec 2011 01:29:06 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id dj8sm16234641qab.19.2011.12.13.01.29.04
	(version=TLSv1/SSLv3 cipher=OTHER);
	Tue, 13 Dec 2011 01:29:05 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: a3a95ea16ca4e34c8213522d4aae854ec16b6057
Message-Id: <a3a95ea16ca4e34c8213.1323768381@loki.upc.es>
In-Reply-To: <patchbomb.1323768375@loki.upc.es>
References: <patchbomb.1323768375@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Tue, 13 Dec 2011 10:26:21 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 06 of 14 v4] libxl: execute hotplug scripts
	directly from libxl
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1317386335 -7200
# Node ID a3a95ea16ca4e34c8213522d4aae854ec16b6057
# Parent  148765a54f6ed77fb83ea6c8788e420a0781f225
libxl: execute hotplug scripts directly from libxl.

Added the necessary handlers to execute hotplug scripts when necessary
from libxl. Split NetBSD and Linux hotplug calls into two separate
files, because parameters for hotplug scripts are different. Linux
has empty functions, since the calling of hotplug scripts is still
done using udev.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 148765a54f6e -r a3a95ea16ca4 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Tue Dec 13 09:49:55 2011 +0100
+++ b/tools/libxl/libxl.c	Fri Sep 30 14:38:55 2011 +0200
@@ -1019,6 +1019,11 @@ int libxl_device_disk_add(libxl_ctx *ctx
             flexarray_append(back, "params");
             flexarray_append(back, dev);
 
+            flexarray_append(back, "script");
+            flexarray_append(back, libxl__sprintf(&gc, "%s/%s",
+                                                  libxl_xen_script_dir_path(),
+                                                  "block"));
+
             assert(device.backend_kind == LIBXL__DEVICE_KIND_VBD);
             break;
         case LIBXL_DISK_BACKEND_TAP:
@@ -1095,6 +1100,15 @@ int libxl_device_disk_add(libxl_ctx *ctx
             goto out_free;
         }
     }
+
+    /* Call hotplug scripts to attach device */
+    if (libxl__device_execute_hotplug(&gc, &device, CONNECT) < 0) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to execute hotplug script for disk: %s\n",
+                   disk->pdev_path);
+        rc = -1;
+        goto out_free;
+    }
+
     rc = 0;
 
 out_free:
@@ -1557,6 +1571,15 @@ int libxl_device_nic_add(libxl_ctx *ctx,
             goto out_free;
         }
     }
+
+    /* Call hotplug scripts to attach device */
+    if (libxl__device_execute_hotplug(&gc, &device, CONNECT) < 0) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to execute hotplug script for nic: %s\n",
+                   nic->ifname);
+        rc = -1;
+        goto out_free;
+    }
+
     rc = 0;
 
 out_free:
diff -r 148765a54f6e -r a3a95ea16ca4 tools/libxl/libxl_device.c
--- a/tools/libxl/libxl_device.c	Tue Dec 13 09:49:55 2011 +0100
+++ b/tools/libxl/libxl_device.c	Fri Sep 30 14:38:55 2011 +0200
@@ -68,6 +68,25 @@ int libxl__parse_backend_path(libxl__gc 
     return libxl__device_kind_from_string(strkind, &dev->backend_kind);
 }
 
+int libxl__device_execute_hotplug(libxl__gc *gc, libxl__device *dev,
+                                  libxl__hotplug_action action)
+{
+    int rc = 0;
+
+    switch(dev->kind) {
+    case LIBXL__DEVICE_KIND_VIF:
+        rc = libxl__nic_hotplug(gc, dev, action);
+        break;
+    case LIBXL__DEVICE_KIND_VBD:
+        rc = libxl__disk_hotplug(gc, dev, action);
+        break;
+    default:
+        break;
+    }
+
+    return rc;
+}
+
 int libxl__device_generic_add(libxl__gc *gc, libxl__device *device,
                              char **bents, char **fents)
 {
@@ -449,6 +468,7 @@ int libxl__device_remove(libxl__gc *gc, 
     if (!state)
         goto out;
     if (atoi(state) != 4) {
+        libxl__device_execute_hotplug(gc, dev, DISCONNECT);
         libxl__device_destroy_tapdisk(gc, be_path);
         xs_rm(ctx->xsh, XBT_NULL, be_path);
         goto out;
@@ -493,6 +513,12 @@ int libxl__device_destroy(libxl__gc *gc,
     char *be_path = libxl__device_backend_path(gc, dev);
     char *fe_path = libxl__device_frontend_path(gc, dev);
 
+    /* 
+     * Run hotplug scripts, which will probably not be able to
+     * execute successfully since the device may still be plugged
+     */
+    libxl__device_execute_hotplug(gc, dev, DISCONNECT);
+
     xs_rm(ctx->xsh, XBT_NULL, be_path);
     xs_rm(ctx->xsh, XBT_NULL, fe_path);
 
diff -r 148765a54f6e -r a3a95ea16ca4 tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Tue Dec 13 09:49:55 2011 +0100
+++ b/tools/libxl/libxl_internal.h	Fri Sep 30 14:38:55 2011 +0200
@@ -289,6 +289,46 @@ _hidden int libxl__wait_for_device_state
  */
 _hidden int libxl__try_phy_backend(mode_t st_mode);
 
+/* hotplug functions */
+
+/* Action to pass to hotplug caller functions */
+typedef enum {
+    CONNECT = 1,
+    DISCONNECT = 2
+} libxl__hotplug_action;
+
+/*
+ * libxl__device_execute_hotplug - generic function to execute hotplug scripts
+ * gc: allocation pool
+ * dev: reference to the device that executes the hotplug scripts
+ * action: action to execute
+ *
+ * Returns 0 on success, and < 0 on error.
+ */
+_hidden int libxl__device_execute_hotplug(libxl__gc *gc, libxl__device *dev,
+                                          libxl__hotplug_action action);
+
+/*
+ * libxl__disk_hotplug - execute hotplug script for a disk type device
+ * gc: allocation pool
+ * dev: reference to the disk device
+ * action: action to execute
+ *
+ * Returns 0 on success, and < 0 on error.
+ */
+_hidden int libxl__disk_hotplug(libxl__gc *gc, libxl__device *dev,
+                                libxl__hotplug_action action);
+
+/*
+ * libxl__nic_hotplug - execute hotplug script for a nic type device
+ * gc: allocation pool
+ * dev: reference to the nic device
+ *
+ * Returns 0 on success, and < 0 on error.
+ */
+_hidden int libxl__nic_hotplug(libxl__gc *gc, libxl__device *dev,
+                               libxl__hotplug_action action);
+
 /* from libxl_pci */
 
 _hidden int libxl__device_pci_add(libxl__gc *gc, uint32_t domid, libxl_device_pci *pcidev, int starting);
diff -r 148765a54f6e -r a3a95ea16ca4 tools/libxl/libxl_linux.c
--- a/tools/libxl/libxl_linux.c	Tue Dec 13 09:49:55 2011 +0100
+++ b/tools/libxl/libxl_linux.c	Fri Sep 30 14:38:55 2011 +0200
@@ -25,3 +25,17 @@ int libxl__try_phy_backend(mode_t st_mod
 
     return 1;
 }
+
+/* Hotplug scripts caller functions */
+
+int libxl_disk_hotplug(libxl__gc *gc, libxl__device *dev,
+                       libxl__hotplug_action action)
+{
+    return 0;
+}
+
+int libxl_nic_hotplug_connect(libxl__gc *gc, libxl__device *dev,
+                              libxl__hotplug_action action)
+{
+    return 0;
+}
diff -r 148765a54f6e -r a3a95ea16ca4 tools/libxl/libxl_netbsd.c
--- a/tools/libxl/libxl_netbsd.c	Tue Dec 13 09:49:55 2011 +0100
+++ b/tools/libxl/libxl_netbsd.c	Fri Sep 30 14:38:55 2011 +0200
@@ -14,6 +14,7 @@
  */
  
 #include <sys/stat.h>
+#include <sys/wait.h>
 
 #include "libxl_internal.h"
 
@@ -24,3 +25,130 @@ int libxl__try_phy_backend(mode_t st_mod
 
     return 0;
 }
+
+/* Hotplug scripts caller functions */
+
+int libxl__disk_hotplug(libxl__gc *gc, libxl__device *dev,
+                        libxl__hotplug_action action)
+{
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+    char *be_path = libxl__device_backend_path(gc, dev);
+    struct stat stab;
+    char *stype, *sstate, *script, *params;
+    char **args;
+    int status, nr = 0;
+    int rc = -1;
+    flexarray_t *f_args;
+
+    script = libxl__xs_read(gc, XBT_NULL,
+                            libxl__sprintf(gc, "%s/%s", be_path, "script"));
+    if (!script) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Unable to read script from %s",
+                                          be_path);
+        return -1;
+    }
+
+    params = libxl__xs_read(gc, XBT_NULL,
+                            libxl__sprintf(gc, "%s/%s", be_path, "params"));
+    if (!params)
+        return -1;
+
+    sstate = libxl__xs_read(gc, XBT_NULL,
+                            libxl__sprintf(gc, "%s/%s", be_path, "state"));
+    if (!sstate) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Unable to read state from %s",
+                   be_path);
+        return -1;
+    }
+
+    if (stat(params, &stab) < 0) {
+        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "failed to get stat info\n");
+        return -1;
+    }
+    if (S_ISBLK(stab.st_mode))
+        stype = "phy";
+    if (S_ISREG(stab.st_mode))
+        stype = "file";
+    if (stype == NULL) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Not block or regular file");
+        return -1;
+    }
+
+    f_args = flexarray_make(5, 1);
+    if (!f_args)
+        return -1;
+
+    flexarray_set(f_args, nr++, script);
+    flexarray_set(f_args, nr++, be_path);
+    flexarray_set(f_args, nr++, libxl__sprintf(gc, "%d", action));
+    flexarray_set(f_args, nr++, stype);
+    flexarray_set(f_args, nr++, NULL);
+
+    args = (char **) flexarray_contents(f_args);
+
+    LIBXL__LOG(ctx, LIBXL__LOG_DEBUG,
+               "Calling disk hotplug script: %s %s %s %s",
+               args[0], args[1], args[2], args[3]);
+    status = libxl__forkexec(gc, -1, -1, -1, args);
+    if (!WIFEXITED(status) || WEXITSTATUS(status) == EXIT_FAILURE) {
+        rc = -1;
+        goto out;
+    }
+    rc = 0;
+
+out:
+    free(args);
+    return rc;
+}
+
+int libxl__nic_hotplug(libxl__gc *gc, libxl__device *dev,
+                       libxl__hotplug_action action)
+{
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+    char *be_path = libxl__device_backend_path(gc, dev);
+    char *sstate, *script;
+    char **args;
+    int status, nr = 0;
+    int rc = -1;
+    flexarray_t *f_args;
+
+    script = libxl__xs_read(gc, XBT_NULL,
+                            libxl__sprintf(gc, "%s/%s", be_path, "script"));
+    if (!script) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Unable to read script from %s",
+                   be_path);
+        return -1;
+    }
+
+    sstate = libxl__xs_read(gc, XBT_NULL,
+                            libxl__sprintf(gc, "%s/%s", be_path, "state"));
+    if (!sstate) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Unable to read state from %s",
+                                          be_path);
+        return -1;
+    }
+
+    f_args = flexarray_make(4, 1);
+    if (!f_args)
+        return -1;
+
+    flexarray_set(f_args, nr++, script);
+    flexarray_set(f_args, nr++, be_path);
+    flexarray_set(f_args, nr++, libxl__sprintf(gc, "%d", action));
+    flexarray_set(f_args, nr++, NULL);
+
+    args = (char **) flexarray_contents(f_args);
+
+    LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Calling nic hotplug script: %s %s %s",
+               args[0], args[1], args[2]);
+    status = libxl__forkexec(gc, -1, -1, -1, args);
+    if (!WIFEXITED(status) || WEXITSTATUS(status) == EXIT_FAILURE) {
+        rc = -1;
+        goto out;
+    }
+    rc = 0;
+
+out:
+    free(args);
+    return rc;
+}

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 09:30:14 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 09:30:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaOgW-0001FL-8F; Tue, 13 Dec 2011 09:30:04 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RaOgU-0001Cr-9U
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 09:30:02 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1323768509!51936179!4
X-Originating-IP: [209.85.216.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26571 invoked from network); 13 Dec 2011 09:28:47 -0000
Received: from mail-qy0-f171.google.com (HELO mail-qy0-f171.google.com)
	(209.85.216.171)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 09:28:47 -0000
Received: by mail-qy0-f171.google.com with SMTP id c20so52043537qcs.30
	for <xen-devel@lists.xensource.com>;
	Tue, 13 Dec 2011 01:29:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=JIcqX+lg4T/PHU5C/2iXE0cX3HZ+Kwpc1q/17GvCQIA=;
	b=QV3/5p2C3xF2nAokE7XVu3X5gIkahy6XcYHzXLfnYqhJTTRUuEPQPgW0fOzJs5brN8
	bomot9AcQ4g6oknBFF0jXGhd/3IkRwNHAMqRSR0jES8YK4qW3Kn2TYQKAq47sAwfcaxZ
	xA9bVYlycOr7USvJy89nEU9/kiIl5XSBfbFz8=
Received: by 10.224.187.20 with SMTP id cu20mr1640826qab.43.1323768549870;
	Tue, 13 Dec 2011 01:29:09 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id dj8sm16234641qab.19.2011.12.13.01.29.08
	(version=TLSv1/SSLv3 cipher=OTHER);
	Tue, 13 Dec 2011 01:29:09 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 30f2db9a780fe36eeacf6dabd76bb2577248edea
Message-Id: <30f2db9a780fe36eeacf.1323768383@loki.upc.es>
In-Reply-To: <patchbomb.1323768375@loki.upc.es>
References: <patchbomb.1323768375@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Tue, 13 Dec 2011 10:26:23 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 08 of 14 v4] xenbackendd: pass action to hotplug
	script
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1323766195 -3600
# Node ID 30f2db9a780fe36eeacf6dabd76bb2577248edea
# Parent  51404e6e2d6f4d53a14deadca4b62748d449782b
xenbackendd: pass action to hotplug script

Pass an action to hotplug scripts instead of a xenbus state.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 51404e6e2d6f -r 30f2db9a780f tools/xenbackendd/xenbackendd.c
--- a/tools/xenbackendd/xenbackendd.c	Tue Dec 13 09:49:55 2011 +0100
+++ b/tools/xenbackendd/xenbackendd.c	Tue Dec 13 09:49:55 2011 +0100
@@ -34,6 +34,9 @@
 #define DEVTYPE_VIF 1
 #define DEVTYPE_VBD 2
 
+#define CONNECT "1"
+#define DISCONNECT "2"
+
 #define DOMAIN_PATH "/local/domain/0"
 
 #ifndef XEN_SCRIPT_DIR
@@ -150,6 +153,7 @@ main(int argc, char * const argv[])
 	unsigned int num;
 	char *s;
 	int state;
+	char *action;
 	char *sstate;
 	char *stype;
 	char *params;
@@ -300,7 +304,8 @@ main(int argc, char * const argv[])
 				    strerror(errno));
 				goto next2;
 			}
-			doexec(s, vec[XS_WATCH_PATH], sstate, NULL);
+			action = (state == 6 ? DISCONNECT : CONNECT);
+			doexec(s, vec[XS_WATCH_PATH], action, NULL);
 			break;
 
 		case DEVTYPE_VBD:
@@ -329,7 +334,8 @@ main(int argc, char * const argv[])
 					params, strerror(errno));
 				goto next3;
 			}
-			doexec(vbd_script, vec[XS_WATCH_PATH], sstate, stype);
+			action = (state == 6 ? DISCONNECT : CONNECT);
+			doexec(vbd_script, vec[XS_WATCH_PATH], action, stype);
 next3:
 			free(params);
 			break;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 09:30:14 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 09:30:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaOgU-0001EZ-Pw; Tue, 13 Dec 2011 09:30:02 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RaOgS-0001Bn-Sa
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 09:30:01 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1323768534!7022555!2
X-Originating-IP: [209.85.216.50]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5604 invoked from network); 13 Dec 2011 09:29:06 -0000
Received: from mail-qw0-f50.google.com (HELO mail-qw0-f50.google.com)
	(209.85.216.50)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 09:29:06 -0000
Received: by mail-qw0-f50.google.com with SMTP id a17so33205897qae.9
	for <xen-devel@lists.xensource.com>;
	Tue, 13 Dec 2011 01:29:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=+QsSsAH8dfIE8YARCFIDyqTHHVzX3YhnMEz9athK9eU=;
	b=PiS7FRwEhlprKY5JFhwhsfeiQO5jgnpzKVeb1n5uDYYv4GZEgGOKs0yafXMyWXEB0t
	DMMtapAfwuv5cpMT0UnySZEzMSbxqpvdiVXzIRC0xHJo7rUXVzGu4mZCOiH4jKzxwqog
	7XzSZ5Kh5ZgsXzu4Tya9prNnKYKUQIMiw/l2M=
Received: by 10.224.1.136 with SMTP id 8mr1668057qaf.54.1323768546171;
	Tue, 13 Dec 2011 01:29:06 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id dj8sm16234641qab.19.2011.12.13.01.29.04
	(version=TLSv1/SSLv3 cipher=OTHER);
	Tue, 13 Dec 2011 01:29:05 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: a3a95ea16ca4e34c8213522d4aae854ec16b6057
Message-Id: <a3a95ea16ca4e34c8213.1323768381@loki.upc.es>
In-Reply-To: <patchbomb.1323768375@loki.upc.es>
References: <patchbomb.1323768375@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Tue, 13 Dec 2011 10:26:21 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 06 of 14 v4] libxl: execute hotplug scripts
	directly from libxl
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1317386335 -7200
# Node ID a3a95ea16ca4e34c8213522d4aae854ec16b6057
# Parent  148765a54f6ed77fb83ea6c8788e420a0781f225
libxl: execute hotplug scripts directly from libxl.

Added the necessary handlers to execute hotplug scripts when necessary
from libxl. Split NetBSD and Linux hotplug calls into two separate
files, because parameters for hotplug scripts are different. Linux
has empty functions, since the calling of hotplug scripts is still
done using udev.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 148765a54f6e -r a3a95ea16ca4 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Tue Dec 13 09:49:55 2011 +0100
+++ b/tools/libxl/libxl.c	Fri Sep 30 14:38:55 2011 +0200
@@ -1019,6 +1019,11 @@ int libxl_device_disk_add(libxl_ctx *ctx
             flexarray_append(back, "params");
             flexarray_append(back, dev);
 
+            flexarray_append(back, "script");
+            flexarray_append(back, libxl__sprintf(&gc, "%s/%s",
+                                                  libxl_xen_script_dir_path(),
+                                                  "block"));
+
             assert(device.backend_kind == LIBXL__DEVICE_KIND_VBD);
             break;
         case LIBXL_DISK_BACKEND_TAP:
@@ -1095,6 +1100,15 @@ int libxl_device_disk_add(libxl_ctx *ctx
             goto out_free;
         }
     }
+
+    /* Call hotplug scripts to attach device */
+    if (libxl__device_execute_hotplug(&gc, &device, CONNECT) < 0) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to execute hotplug script for disk: %s\n",
+                   disk->pdev_path);
+        rc = -1;
+        goto out_free;
+    }
+
     rc = 0;
 
 out_free:
@@ -1557,6 +1571,15 @@ int libxl_device_nic_add(libxl_ctx *ctx,
             goto out_free;
         }
     }
+
+    /* Call hotplug scripts to attach device */
+    if (libxl__device_execute_hotplug(&gc, &device, CONNECT) < 0) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to execute hotplug script for nic: %s\n",
+                   nic->ifname);
+        rc = -1;
+        goto out_free;
+    }
+
     rc = 0;
 
 out_free:
diff -r 148765a54f6e -r a3a95ea16ca4 tools/libxl/libxl_device.c
--- a/tools/libxl/libxl_device.c	Tue Dec 13 09:49:55 2011 +0100
+++ b/tools/libxl/libxl_device.c	Fri Sep 30 14:38:55 2011 +0200
@@ -68,6 +68,25 @@ int libxl__parse_backend_path(libxl__gc 
     return libxl__device_kind_from_string(strkind, &dev->backend_kind);
 }
 
+int libxl__device_execute_hotplug(libxl__gc *gc, libxl__device *dev,
+                                  libxl__hotplug_action action)
+{
+    int rc = 0;
+
+    switch(dev->kind) {
+    case LIBXL__DEVICE_KIND_VIF:
+        rc = libxl__nic_hotplug(gc, dev, action);
+        break;
+    case LIBXL__DEVICE_KIND_VBD:
+        rc = libxl__disk_hotplug(gc, dev, action);
+        break;
+    default:
+        break;
+    }
+
+    return rc;
+}
+
 int libxl__device_generic_add(libxl__gc *gc, libxl__device *device,
                              char **bents, char **fents)
 {
@@ -449,6 +468,7 @@ int libxl__device_remove(libxl__gc *gc, 
     if (!state)
         goto out;
     if (atoi(state) != 4) {
+        libxl__device_execute_hotplug(gc, dev, DISCONNECT);
         libxl__device_destroy_tapdisk(gc, be_path);
         xs_rm(ctx->xsh, XBT_NULL, be_path);
         goto out;
@@ -493,6 +513,12 @@ int libxl__device_destroy(libxl__gc *gc,
     char *be_path = libxl__device_backend_path(gc, dev);
     char *fe_path = libxl__device_frontend_path(gc, dev);
 
+    /* 
+     * Run hotplug scripts, which will probably not be able to
+     * execute successfully since the device may still be plugged
+     */
+    libxl__device_execute_hotplug(gc, dev, DISCONNECT);
+
     xs_rm(ctx->xsh, XBT_NULL, be_path);
     xs_rm(ctx->xsh, XBT_NULL, fe_path);
 
diff -r 148765a54f6e -r a3a95ea16ca4 tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Tue Dec 13 09:49:55 2011 +0100
+++ b/tools/libxl/libxl_internal.h	Fri Sep 30 14:38:55 2011 +0200
@@ -289,6 +289,46 @@ _hidden int libxl__wait_for_device_state
  */
 _hidden int libxl__try_phy_backend(mode_t st_mode);
 
+/* hotplug functions */
+
+/* Action to pass to hotplug caller functions */
+typedef enum {
+    CONNECT = 1,
+    DISCONNECT = 2
+} libxl__hotplug_action;
+
+/*
+ * libxl__device_execute_hotplug - generic function to execute hotplug scripts
+ * gc: allocation pool
+ * dev: reference to the device that executes the hotplug scripts
+ * action: action to execute
+ *
+ * Returns 0 on success, and < 0 on error.
+ */
+_hidden int libxl__device_execute_hotplug(libxl__gc *gc, libxl__device *dev,
+                                          libxl__hotplug_action action);
+
+/*
+ * libxl__disk_hotplug - execute hotplug script for a disk type device
+ * gc: allocation pool
+ * dev: reference to the disk device
+ * action: action to execute
+ *
+ * Returns 0 on success, and < 0 on error.
+ */
+_hidden int libxl__disk_hotplug(libxl__gc *gc, libxl__device *dev,
+                                libxl__hotplug_action action);
+
+/*
+ * libxl__nic_hotplug - execute hotplug script for a nic type device
+ * gc: allocation pool
+ * dev: reference to the nic device
+ *
+ * Returns 0 on success, and < 0 on error.
+ */
+_hidden int libxl__nic_hotplug(libxl__gc *gc, libxl__device *dev,
+                               libxl__hotplug_action action);
+
 /* from libxl_pci */
 
 _hidden int libxl__device_pci_add(libxl__gc *gc, uint32_t domid, libxl_device_pci *pcidev, int starting);
diff -r 148765a54f6e -r a3a95ea16ca4 tools/libxl/libxl_linux.c
--- a/tools/libxl/libxl_linux.c	Tue Dec 13 09:49:55 2011 +0100
+++ b/tools/libxl/libxl_linux.c	Fri Sep 30 14:38:55 2011 +0200
@@ -25,3 +25,17 @@ int libxl__try_phy_backend(mode_t st_mod
 
     return 1;
 }
+
+/* Hotplug scripts caller functions */
+
+int libxl_disk_hotplug(libxl__gc *gc, libxl__device *dev,
+                       libxl__hotplug_action action)
+{
+    return 0;
+}
+
+int libxl_nic_hotplug_connect(libxl__gc *gc, libxl__device *dev,
+                              libxl__hotplug_action action)
+{
+    return 0;
+}
diff -r 148765a54f6e -r a3a95ea16ca4 tools/libxl/libxl_netbsd.c
--- a/tools/libxl/libxl_netbsd.c	Tue Dec 13 09:49:55 2011 +0100
+++ b/tools/libxl/libxl_netbsd.c	Fri Sep 30 14:38:55 2011 +0200
@@ -14,6 +14,7 @@
  */
  
 #include <sys/stat.h>
+#include <sys/wait.h>
 
 #include "libxl_internal.h"
 
@@ -24,3 +25,130 @@ int libxl__try_phy_backend(mode_t st_mod
 
     return 0;
 }
+
+/* Hotplug scripts caller functions */
+
+int libxl__disk_hotplug(libxl__gc *gc, libxl__device *dev,
+                        libxl__hotplug_action action)
+{
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+    char *be_path = libxl__device_backend_path(gc, dev);
+    struct stat stab;
+    char *stype, *sstate, *script, *params;
+    char **args;
+    int status, nr = 0;
+    int rc = -1;
+    flexarray_t *f_args;
+
+    script = libxl__xs_read(gc, XBT_NULL,
+                            libxl__sprintf(gc, "%s/%s", be_path, "script"));
+    if (!script) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Unable to read script from %s",
+                                          be_path);
+        return -1;
+    }
+
+    params = libxl__xs_read(gc, XBT_NULL,
+                            libxl__sprintf(gc, "%s/%s", be_path, "params"));
+    if (!params)
+        return -1;
+
+    sstate = libxl__xs_read(gc, XBT_NULL,
+                            libxl__sprintf(gc, "%s/%s", be_path, "state"));
+    if (!sstate) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Unable to read state from %s",
+                   be_path);
+        return -1;
+    }
+
+    if (stat(params, &stab) < 0) {
+        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "failed to get stat info\n");
+        return -1;
+    }
+    if (S_ISBLK(stab.st_mode))
+        stype = "phy";
+    if (S_ISREG(stab.st_mode))
+        stype = "file";
+    if (stype == NULL) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Not block or regular file");
+        return -1;
+    }
+
+    f_args = flexarray_make(5, 1);
+    if (!f_args)
+        return -1;
+
+    flexarray_set(f_args, nr++, script);
+    flexarray_set(f_args, nr++, be_path);
+    flexarray_set(f_args, nr++, libxl__sprintf(gc, "%d", action));
+    flexarray_set(f_args, nr++, stype);
+    flexarray_set(f_args, nr++, NULL);
+
+    args = (char **) flexarray_contents(f_args);
+
+    LIBXL__LOG(ctx, LIBXL__LOG_DEBUG,
+               "Calling disk hotplug script: %s %s %s %s",
+               args[0], args[1], args[2], args[3]);
+    status = libxl__forkexec(gc, -1, -1, -1, args);
+    if (!WIFEXITED(status) || WEXITSTATUS(status) == EXIT_FAILURE) {
+        rc = -1;
+        goto out;
+    }
+    rc = 0;
+
+out:
+    free(args);
+    return rc;
+}
+
+int libxl__nic_hotplug(libxl__gc *gc, libxl__device *dev,
+                       libxl__hotplug_action action)
+{
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+    char *be_path = libxl__device_backend_path(gc, dev);
+    char *sstate, *script;
+    char **args;
+    int status, nr = 0;
+    int rc = -1;
+    flexarray_t *f_args;
+
+    script = libxl__xs_read(gc, XBT_NULL,
+                            libxl__sprintf(gc, "%s/%s", be_path, "script"));
+    if (!script) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Unable to read script from %s",
+                   be_path);
+        return -1;
+    }
+
+    sstate = libxl__xs_read(gc, XBT_NULL,
+                            libxl__sprintf(gc, "%s/%s", be_path, "state"));
+    if (!sstate) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Unable to read state from %s",
+                                          be_path);
+        return -1;
+    }
+
+    f_args = flexarray_make(4, 1);
+    if (!f_args)
+        return -1;
+
+    flexarray_set(f_args, nr++, script);
+    flexarray_set(f_args, nr++, be_path);
+    flexarray_set(f_args, nr++, libxl__sprintf(gc, "%d", action));
+    flexarray_set(f_args, nr++, NULL);
+
+    args = (char **) flexarray_contents(f_args);
+
+    LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Calling nic hotplug script: %s %s %s",
+               args[0], args[1], args[2]);
+    status = libxl__forkexec(gc, -1, -1, -1, args);
+    if (!WIFEXITED(status) || WEXITSTATUS(status) == EXIT_FAILURE) {
+        rc = -1;
+        goto out;
+    }
+    rc = 0;
+
+out:
+    free(args);
+    return rc;
+}

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 09:30:14 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 09:30:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaOgE-0001Ag-W9; Tue, 13 Dec 2011 09:29:46 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RaOgD-0001AQ-Ke
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 09:29:45 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1323768509!51936179!1
X-Originating-IP: [209.85.216.171]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25417 invoked from network); 13 Dec 2011 09:28:30 -0000
Received: from mail-qy0-f171.google.com (HELO mail-qy0-f171.google.com)
	(209.85.216.171)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 09:28:30 -0000
Received: by qcsc20 with SMTP id c20so52043537qcs.30
	for <xen-devel@lists.xensource.com>;
	Tue, 13 Dec 2011 01:28:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:message-id:user-agent:date:from:to;
	bh=F3TIsAbKTB13JsQ4nF9+DZkUNKQ+gi1rRLn6Cgf1XCw=;
	b=JuOauR5I4nVBs/YOB1ko733aaagENSKZLTaeikRJCifgydwI29/Lmhxi/v8GK5bIk7
	0pJUIkdnJb6GCiIIs4L35GzYs9R89yqMPa2r8FI/s3Rgh5hNGJ2guZAZZImYY38SKoLj
	KDV4RP0PgP7G7CP0PWcYCgLvSNukHJYxfjdnM=
Received: by 10.224.116.145 with SMTP id m17mr1657109qaq.64.1323768532255;
	Tue, 13 Dec 2011 01:28:52 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id dj8sm16234641qab.19.2011.12.13.01.28.50
	(version=TLSv1/SSLv3 cipher=OTHER);
	Tue, 13 Dec 2011 01:28:51 -0800 (PST)
MIME-Version: 1.0
Message-Id: <patchbomb.1323768375@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Tue, 13 Dec 2011 10:26:15 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 00 of 14 v4] libxl: add support for hotplug
 script calling from libxl
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This patch series adds support for hotplug script calling directly
from libxl, instead of relying on xenbackendd. Also some patches
contain general bug fixes.

Currently Linux hotplug script call functions are empty, so Linux
continues to use udev rules to call hotplug scripts.

Patches 1, 7, 8, 9, 10 are NetBSD specific, and basicaly pave the way
for the application of the bigger changes present in this series.

Patch 11 is a trivial update for an error message.

Patch 2 adds support for mounting raw image files using the vnd
device. Since NetBSD doesn't have qdisk or blktap support, the only
way to use raw images with guests is to mount the image and pass the
block device as a "PHY" backend. To check wheter an OS supports raw
images as "PHY" backends two new files are added to the project, to
avoid using #ifdefs, that contain a helper function. The file
to be included is decided during the compilation process.

Patch 3 adds a generic function to fork the current process and
execute a given file, which will be later used to execute hotplug
scripts synchronously.

Patches 4 and 5 add a new function to wait for a device to reach a
certain state, and replace wait_for_dev_destroy with this more generic
implementation. This function is also used to wait for device
initialization before calling hotplug scripts. The added function will
benefit from a rework after event support is added to libxl.

Patch 6 adds the calling of hotplug scripts when devices are
initializated and removed. Two new files are also added to support
hotplug scripts, since Linux and NetBSD hotplug scripts have different
call parameters. The path of the script to execute is retrieved
from xenstore. The file to include is also decided at compile
time.

Patches 12, 13, 14 sets frontend status to 6 when a domain is
destroyed, so devices are disconnected and then execute hotplug
scripts. Also the syntax of the libxl_domain_destroy and 
libxl__devices_destroy has been changed to always force the destruction.

Changes since v3:

 * Merged the destroy fixes with the hotplug series.

Please review, Roger.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 09:30:14 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 09:30:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaOgS-0001DP-BM; Tue, 13 Dec 2011 09:30:00 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RaOgQ-0001BS-K3
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 09:29:58 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1323768537!5313926!3
X-Originating-IP: [209.85.216.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9225 invoked from network); 13 Dec 2011 09:29:04 -0000
Received: from mail-qw0-f43.google.com (HELO mail-qw0-f43.google.com)
	(209.85.216.43)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 09:29:04 -0000
Received: by mail-qw0-f43.google.com with SMTP id g27so23025472qab.9
	for <xen-devel@lists.xensource.com>;
	Tue, 13 Dec 2011 01:29:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=fHTKOCeNs5l4HD2AV1kR6yBt9AmMN5A++GKxpHbefGk=;
	b=O1VIiPM6SOJkbBuSeMEpEaDc/+gpZvLWzg5C2pIuxg34wh4bQ1YgUCzjYJ2ppRb3sj
	MJCvov8LM7SPjYRL90t7S3kxvX4Y2cERz4Fuy3Abth8svOV6Qa/49Fz/lt1PquuGuhlA
	MQjuwCW7dPXhUHplKlGcCt9zMMwy8EGP4Dqm0=
Received: by 10.224.17.209 with SMTP id t17mr1642289qaa.24.1323768544123;
	Tue, 13 Dec 2011 01:29:04 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id dj8sm16234641qab.19.2011.12.13.01.29.02
	(version=TLSv1/SSLv3 cipher=OTHER);
	Tue, 13 Dec 2011 01:29:03 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 148765a54f6ed77fb83ea6c8788e420a0781f225
Message-Id: <148765a54f6ed77fb83e.1323768380@loki.upc.es>
In-Reply-To: <patchbomb.1323768375@loki.upc.es>
References: <patchbomb.1323768375@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Tue, 13 Dec 2011 10:26:20 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 05 of 14 v4] libxl: wait for devices to
 initialize upon addition to the domain
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1323766195 -3600
# Node ID 148765a54f6ed77fb83ea6c8788e420a0781f225
# Parent  d5f1ab565bf64c98c04720bafe50fa4cb6b1592f
libxl: wait for devices to initialize upon addition to the domain.

Block waiting for devices to initialize (switch to state 2). This is
necessary because we need to call the hotplug scripts when state is
2, otherwise the execution fails. Make use of the newly introduced
function libxl__wait_for_device_state.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r d5f1ab565bf6 -r 148765a54f6e tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Tue Dec 13 09:49:55 2011 +0100
+++ b/tools/libxl/libxl.c	Tue Dec 13 09:49:55 2011 +0100
@@ -972,6 +972,8 @@ int libxl_device_disk_add(libxl_ctx *ctx
     flexarray_t *front;
     flexarray_t *back;
     char *dev;
+    char *be_path, *state_path, *state;
+    struct timeval tv;
     libxl__device device;
     int major, minor, rc;
 
@@ -1076,6 +1078,23 @@ int libxl_device_disk_add(libxl_ctx *ctx
                              libxl__xs_kvs_of_flexarray(&gc, back, back->count),
                              libxl__xs_kvs_of_flexarray(&gc, front, front->count));
 
+    be_path = libxl__device_backend_path(&gc, &device);
+    state_path = libxl__sprintf(&gc, "%s/state", be_path);
+    state = libxl__xs_read(&gc, XBT_NULL, state_path);
+
+    if (atoi(state) != XenbusStateInitWait) {
+        xs_watch(ctx->xsh, state_path, be_path);
+        tv.tv_sec = LIBXL_DESTROY_TIMEOUT;
+        tv.tv_usec = 0;
+        rc = libxl__wait_for_device_state(&gc, &tv, XenbusStateInitWait, NULL);
+        xs_unwatch(ctx->xsh, state_path, be_path);
+        if (rc < 0) {
+            LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
+                       "unable to initialize disk device: %s\n",
+                       disk->pdev_path);
+            goto out_free;
+        }
+    }
     rc = 0;
 
 out_free:
@@ -1451,6 +1470,8 @@ int libxl_device_nic_add(libxl_ctx *ctx,
     flexarray_t *back;
     libxl__device device;
     char *dompath, **l;
+    char *be_path, *state_path, *state;
+    struct timeval tv;
     unsigned int nb, rc;
 
     front = flexarray_make(16, 1);
@@ -1519,8 +1540,25 @@ int libxl_device_nic_add(libxl_ctx *ctx,
                              libxl__xs_kvs_of_flexarray(&gc, back, back->count),
                              libxl__xs_kvs_of_flexarray(&gc, front, front->count));
 
-    /* FIXME: wait for plug */
+    be_path = libxl__device_backend_path(&gc, &device);
+    state_path = libxl__sprintf(&gc, "%s/state", be_path);
+    state = libxl__xs_read(&gc, XBT_NULL, state_path);
+
+    if (atoi(state) != XenbusStateInitWait) {
+        xs_watch(ctx->xsh, state_path, be_path);
+        tv.tv_sec = LIBXL_DESTROY_TIMEOUT;
+        tv.tv_usec = 0;
+        rc = libxl__wait_for_device_state(&gc, &tv, XenbusStateInitWait, NULL);
+        xs_unwatch(ctx->xsh, state_path, be_path);
+        if (rc < 0) {
+            LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
+                       "unable to initialize nic device: %s\n",
+                       nic->ifname);
+            goto out_free;
+        }
+    }
     rc = 0;
+
 out_free:
     flexarray_free(back);
     flexarray_free(front);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 09:30:14 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 09:30:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaOgE-0001Ag-W9; Tue, 13 Dec 2011 09:29:46 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RaOgD-0001AQ-Ke
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 09:29:45 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1323768509!51936179!1
X-Originating-IP: [209.85.216.171]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25417 invoked from network); 13 Dec 2011 09:28:30 -0000
Received: from mail-qy0-f171.google.com (HELO mail-qy0-f171.google.com)
	(209.85.216.171)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 09:28:30 -0000
Received: by qcsc20 with SMTP id c20so52043537qcs.30
	for <xen-devel@lists.xensource.com>;
	Tue, 13 Dec 2011 01:28:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:message-id:user-agent:date:from:to;
	bh=F3TIsAbKTB13JsQ4nF9+DZkUNKQ+gi1rRLn6Cgf1XCw=;
	b=JuOauR5I4nVBs/YOB1ko733aaagENSKZLTaeikRJCifgydwI29/Lmhxi/v8GK5bIk7
	0pJUIkdnJb6GCiIIs4L35GzYs9R89yqMPa2r8FI/s3Rgh5hNGJ2guZAZZImYY38SKoLj
	KDV4RP0PgP7G7CP0PWcYCgLvSNukHJYxfjdnM=
Received: by 10.224.116.145 with SMTP id m17mr1657109qaq.64.1323768532255;
	Tue, 13 Dec 2011 01:28:52 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id dj8sm16234641qab.19.2011.12.13.01.28.50
	(version=TLSv1/SSLv3 cipher=OTHER);
	Tue, 13 Dec 2011 01:28:51 -0800 (PST)
MIME-Version: 1.0
Message-Id: <patchbomb.1323768375@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Tue, 13 Dec 2011 10:26:15 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 00 of 14 v4] libxl: add support for hotplug
 script calling from libxl
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This patch series adds support for hotplug script calling directly
from libxl, instead of relying on xenbackendd. Also some patches
contain general bug fixes.

Currently Linux hotplug script call functions are empty, so Linux
continues to use udev rules to call hotplug scripts.

Patches 1, 7, 8, 9, 10 are NetBSD specific, and basicaly pave the way
for the application of the bigger changes present in this series.

Patch 11 is a trivial update for an error message.

Patch 2 adds support for mounting raw image files using the vnd
device. Since NetBSD doesn't have qdisk or blktap support, the only
way to use raw images with guests is to mount the image and pass the
block device as a "PHY" backend. To check wheter an OS supports raw
images as "PHY" backends two new files are added to the project, to
avoid using #ifdefs, that contain a helper function. The file
to be included is decided during the compilation process.

Patch 3 adds a generic function to fork the current process and
execute a given file, which will be later used to execute hotplug
scripts synchronously.

Patches 4 and 5 add a new function to wait for a device to reach a
certain state, and replace wait_for_dev_destroy with this more generic
implementation. This function is also used to wait for device
initialization before calling hotplug scripts. The added function will
benefit from a rework after event support is added to libxl.

Patch 6 adds the calling of hotplug scripts when devices are
initializated and removed. Two new files are also added to support
hotplug scripts, since Linux and NetBSD hotplug scripts have different
call parameters. The path of the script to execute is retrieved
from xenstore. The file to include is also decided at compile
time.

Patches 12, 13, 14 sets frontend status to 6 when a domain is
destroyed, so devices are disconnected and then execute hotplug
scripts. Also the syntax of the libxl_domain_destroy and 
libxl__devices_destroy has been changed to always force the destruction.

Changes since v3:

 * Merged the destroy fixes with the hotplug series.

Please review, Roger.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 09:30:14 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 09:30:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaOgS-0001DP-BM; Tue, 13 Dec 2011 09:30:00 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RaOgQ-0001BS-K3
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 09:29:58 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1323768537!5313926!3
X-Originating-IP: [209.85.216.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9225 invoked from network); 13 Dec 2011 09:29:04 -0000
Received: from mail-qw0-f43.google.com (HELO mail-qw0-f43.google.com)
	(209.85.216.43)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 09:29:04 -0000
Received: by mail-qw0-f43.google.com with SMTP id g27so23025472qab.9
	for <xen-devel@lists.xensource.com>;
	Tue, 13 Dec 2011 01:29:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=fHTKOCeNs5l4HD2AV1kR6yBt9AmMN5A++GKxpHbefGk=;
	b=O1VIiPM6SOJkbBuSeMEpEaDc/+gpZvLWzg5C2pIuxg34wh4bQ1YgUCzjYJ2ppRb3sj
	MJCvov8LM7SPjYRL90t7S3kxvX4Y2cERz4Fuy3Abth8svOV6Qa/49Fz/lt1PquuGuhlA
	MQjuwCW7dPXhUHplKlGcCt9zMMwy8EGP4Dqm0=
Received: by 10.224.17.209 with SMTP id t17mr1642289qaa.24.1323768544123;
	Tue, 13 Dec 2011 01:29:04 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id dj8sm16234641qab.19.2011.12.13.01.29.02
	(version=TLSv1/SSLv3 cipher=OTHER);
	Tue, 13 Dec 2011 01:29:03 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 148765a54f6ed77fb83ea6c8788e420a0781f225
Message-Id: <148765a54f6ed77fb83e.1323768380@loki.upc.es>
In-Reply-To: <patchbomb.1323768375@loki.upc.es>
References: <patchbomb.1323768375@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Tue, 13 Dec 2011 10:26:20 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 05 of 14 v4] libxl: wait for devices to
 initialize upon addition to the domain
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1323766195 -3600
# Node ID 148765a54f6ed77fb83ea6c8788e420a0781f225
# Parent  d5f1ab565bf64c98c04720bafe50fa4cb6b1592f
libxl: wait for devices to initialize upon addition to the domain.

Block waiting for devices to initialize (switch to state 2). This is
necessary because we need to call the hotplug scripts when state is
2, otherwise the execution fails. Make use of the newly introduced
function libxl__wait_for_device_state.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r d5f1ab565bf6 -r 148765a54f6e tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Tue Dec 13 09:49:55 2011 +0100
+++ b/tools/libxl/libxl.c	Tue Dec 13 09:49:55 2011 +0100
@@ -972,6 +972,8 @@ int libxl_device_disk_add(libxl_ctx *ctx
     flexarray_t *front;
     flexarray_t *back;
     char *dev;
+    char *be_path, *state_path, *state;
+    struct timeval tv;
     libxl__device device;
     int major, minor, rc;
 
@@ -1076,6 +1078,23 @@ int libxl_device_disk_add(libxl_ctx *ctx
                              libxl__xs_kvs_of_flexarray(&gc, back, back->count),
                              libxl__xs_kvs_of_flexarray(&gc, front, front->count));
 
+    be_path = libxl__device_backend_path(&gc, &device);
+    state_path = libxl__sprintf(&gc, "%s/state", be_path);
+    state = libxl__xs_read(&gc, XBT_NULL, state_path);
+
+    if (atoi(state) != XenbusStateInitWait) {
+        xs_watch(ctx->xsh, state_path, be_path);
+        tv.tv_sec = LIBXL_DESTROY_TIMEOUT;
+        tv.tv_usec = 0;
+        rc = libxl__wait_for_device_state(&gc, &tv, XenbusStateInitWait, NULL);
+        xs_unwatch(ctx->xsh, state_path, be_path);
+        if (rc < 0) {
+            LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
+                       "unable to initialize disk device: %s\n",
+                       disk->pdev_path);
+            goto out_free;
+        }
+    }
     rc = 0;
 
 out_free:
@@ -1451,6 +1470,8 @@ int libxl_device_nic_add(libxl_ctx *ctx,
     flexarray_t *back;
     libxl__device device;
     char *dompath, **l;
+    char *be_path, *state_path, *state;
+    struct timeval tv;
     unsigned int nb, rc;
 
     front = flexarray_make(16, 1);
@@ -1519,8 +1540,25 @@ int libxl_device_nic_add(libxl_ctx *ctx,
                              libxl__xs_kvs_of_flexarray(&gc, back, back->count),
                              libxl__xs_kvs_of_flexarray(&gc, front, front->count));
 
-    /* FIXME: wait for plug */
+    be_path = libxl__device_backend_path(&gc, &device);
+    state_path = libxl__sprintf(&gc, "%s/state", be_path);
+    state = libxl__xs_read(&gc, XBT_NULL, state_path);
+
+    if (atoi(state) != XenbusStateInitWait) {
+        xs_watch(ctx->xsh, state_path, be_path);
+        tv.tv_sec = LIBXL_DESTROY_TIMEOUT;
+        tv.tv_usec = 0;
+        rc = libxl__wait_for_device_state(&gc, &tv, XenbusStateInitWait, NULL);
+        xs_unwatch(ctx->xsh, state_path, be_path);
+        if (rc < 0) {
+            LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
+                       "unable to initialize nic device: %s\n",
+                       nic->ifname);
+            goto out_free;
+        }
+    }
     rc = 0;
+
 out_free:
     flexarray_free(back);
     flexarray_free(front);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 09:30:15 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 09: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.xensource.com>)
	id 1RaOgN-0001Bo-Rx; Tue, 13 Dec 2011 09:29:55 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RaOgM-0001Aq-Bi
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 09:29:54 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1323768537!5313926!1
X-Originating-IP: [209.85.216.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8666 invoked from network); 13 Dec 2011 09:28:59 -0000
Received: from mail-qw0-f43.google.com (HELO mail-qw0-f43.google.com)
	(209.85.216.43)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 09:28:59 -0000
Received: by qabg27 with SMTP id g27so23025472qab.9
	for <xen-devel@lists.xensource.com>;
	Tue, 13 Dec 2011 01:28:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=2xbQUVUJVvsBKjNAKM4wR8lthbDQ9CD1VMZDkiaM2gc=;
	b=SaYaYIvhjzRaPy8wspsH+ytTzd1YMVB5a0z4Vxhqo9tiAfcqjiGXjcrLEbtEdUX9Ck
	pzvqNAtQToMkeVyyaxqCmPP76o6z1lEStoNZ3bzv7ZAQkF8QV0RS20I9/9xrCpSdL+dH
	NyUnehU1Rzj4r3ItYQ4tkHNZqV2pkbDXwDLuc=
Received: by 10.224.187.20 with SMTP id cu20mr1640135qab.43.1323768537563;
	Tue, 13 Dec 2011 01:28:57 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id dj8sm16234641qab.19.2011.12.13.01.28.54
	(version=TLSv1/SSLv3 cipher=OTHER);
	Tue, 13 Dec 2011 01:28:55 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: e3907ed912201e5270ff19265fab2c979b3929cc
Message-Id: <e3907ed912201e5270ff.1323768377@loki.upc.es>
In-Reply-To: <patchbomb.1323768375@loki.upc.es>
References: <patchbomb.1323768375@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Tue, 13 Dec 2011 10:26:17 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 02 of 14 v4] libxl: add support for image files
	for NetBSD
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1317386335 -7200
# Node ID e3907ed912201e5270ff19265fab2c979b3929cc
# Parent  a0f9c898470cedc6d9009fde182a5bd73e587a28
libxl: add support for image files for NetBSD

Created a helper function to detect if the OS is capable of using
image files as phy backends. Create two OS specific files, and
changed the Makefile to choose the correct one at compile time.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r a0f9c898470c -r e3907ed91220 tools/libxl/Makefile
--- a/tools/libxl/Makefile	Fri Sep 30 14:38:55 2011 +0200
+++ b/tools/libxl/Makefile	Fri Sep 30 14:38:55 2011 +0200
@@ -32,6 +32,15 @@ endif
 LIBXL_OBJS-$(CONFIG_X86) += libxl_cpuid.o
 LIBXL_OBJS-$(CONFIG_IA64) += libxl_nocpuid.o
 
+ifeq ($(CONFIG_NetBSD),y)
+LIBXL_OBJS-y += libxl_netbsd.o
+else ifeq ($(CONFIG_Linux),y)
+LIBXL_OBJS-y += libxl_linux.o
+else
+$(error Your Operating System is not supported by libxenlight, \
+please check libxl_linux.c and libxl_netbsd.c to see how to get it ported)
+endif
+
 LIBXL_LIBS += -lyajl
 
 LIBXL_OBJS = flexarray.o libxl.o libxl_create.o libxl_dm.o libxl_pci.o \
diff -r a0f9c898470c -r e3907ed91220 tools/libxl/libxl_device.c
--- a/tools/libxl/libxl_device.c	Fri Sep 30 14:38:55 2011 +0200
+++ b/tools/libxl/libxl_device.c	Fri Sep 30 14:38:55 2011 +0200
@@ -138,15 +138,14 @@ static int disk_try_backend(disk_try_bac
               a->disk->format == LIBXL_DISK_FORMAT_EMPTY)) {
             goto bad_format;
         }
-        if (a->disk->format != LIBXL_DISK_FORMAT_EMPTY &&
-            !S_ISBLK(a->stab.st_mode)) {
-            LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Disk vdev=%s, backend phy"
-                       " unsuitable as phys path not a block device",
-                       a->disk->vdev);
-            return 0;
-        }
 
-        return backend;
+        if (libxl__try_phy_backend(a->stab.st_mode))
+            return backend;
+
+        LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Disk vdev=%s, backend phy"
+                   " unsuitable as phys path not a block device",
+                   a->disk->vdev);
+        return 0;
 
     case LIBXL_DISK_BACKEND_TAP:
         if (!libxl__blktap_enabled(a->gc)) {
diff -r a0f9c898470c -r e3907ed91220 tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Fri Sep 30 14:38:55 2011 +0200
+++ b/tools/libxl/libxl_internal.h	Fri Sep 30 14:38:55 2011 +0200
@@ -252,6 +252,15 @@ _hidden int libxl__device_destroy(libxl_
 _hidden int libxl__devices_destroy(libxl__gc *gc, uint32_t domid, int force);
 _hidden int libxl__wait_for_backend(libxl__gc *gc, char *be_path, char *state);
 
+/*
+ * libxl__try_phy_backend - Check if there's support for the passed
+ * type of file using the PHY backend
+ * st_mode: mode_t of the file, as returned by stat function
+ *
+ * Returns 0 on success, and < 0 on error.
+ */
+_hidden int libxl__try_phy_backend(mode_t st_mode);
+
 /* from libxl_pci */
 
 _hidden int libxl__device_pci_add(libxl__gc *gc, uint32_t domid, libxl_device_pci *pcidev, int starting);
diff -r a0f9c898470c -r e3907ed91220 tools/libxl/libxl_linux.c
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/tools/libxl/libxl_linux.c	Fri Sep 30 14:38:55 2011 +0200
@@ -0,0 +1,27 @@
+/*
+ * Copyright (C) 2011
+ * Author Roger Pau Monne <roger.pau@entel.upc.edu>
+ *
+ * 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 <sys/stat.h>
+
+#include "libxl_internal.h"
+ 
+int libxl__try_phy_backend(mode_t st_mode)
+{
+    if (!S_ISBLK(st_mode)) {
+        return 0;
+    }
+
+    return 1;
+}
diff -r a0f9c898470c -r e3907ed91220 tools/libxl/libxl_netbsd.c
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/tools/libxl/libxl_netbsd.c	Fri Sep 30 14:38:55 2011 +0200
@@ -0,0 +1,26 @@
+/*
+ * Copyright (C) 2011
+ * Author Roger Pau Monne <roger.pau@entel.upc.edu>
+ *
+ * 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 <sys/stat.h>
+
+#include "libxl_internal.h"
+
+int libxl__try_phy_backend(mode_t st_mode)
+{
+    if (S_ISREG(st_mode) || S_ISBLK(st_mode))
+        return 1;
+
+    return 0;
+}

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 09:30:15 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 09: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.xensource.com>)
	id 1RaOgN-0001Bo-Rx; Tue, 13 Dec 2011 09:29:55 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RaOgM-0001Aq-Bi
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 09:29:54 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1323768537!5313926!1
X-Originating-IP: [209.85.216.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8666 invoked from network); 13 Dec 2011 09:28:59 -0000
Received: from mail-qw0-f43.google.com (HELO mail-qw0-f43.google.com)
	(209.85.216.43)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 09:28:59 -0000
Received: by qabg27 with SMTP id g27so23025472qab.9
	for <xen-devel@lists.xensource.com>;
	Tue, 13 Dec 2011 01:28:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=2xbQUVUJVvsBKjNAKM4wR8lthbDQ9CD1VMZDkiaM2gc=;
	b=SaYaYIvhjzRaPy8wspsH+ytTzd1YMVB5a0z4Vxhqo9tiAfcqjiGXjcrLEbtEdUX9Ck
	pzvqNAtQToMkeVyyaxqCmPP76o6z1lEStoNZ3bzv7ZAQkF8QV0RS20I9/9xrCpSdL+dH
	NyUnehU1Rzj4r3ItYQ4tkHNZqV2pkbDXwDLuc=
Received: by 10.224.187.20 with SMTP id cu20mr1640135qab.43.1323768537563;
	Tue, 13 Dec 2011 01:28:57 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id dj8sm16234641qab.19.2011.12.13.01.28.54
	(version=TLSv1/SSLv3 cipher=OTHER);
	Tue, 13 Dec 2011 01:28:55 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: e3907ed912201e5270ff19265fab2c979b3929cc
Message-Id: <e3907ed912201e5270ff.1323768377@loki.upc.es>
In-Reply-To: <patchbomb.1323768375@loki.upc.es>
References: <patchbomb.1323768375@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Tue, 13 Dec 2011 10:26:17 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 02 of 14 v4] libxl: add support for image files
	for NetBSD
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1317386335 -7200
# Node ID e3907ed912201e5270ff19265fab2c979b3929cc
# Parent  a0f9c898470cedc6d9009fde182a5bd73e587a28
libxl: add support for image files for NetBSD

Created a helper function to detect if the OS is capable of using
image files as phy backends. Create two OS specific files, and
changed the Makefile to choose the correct one at compile time.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r a0f9c898470c -r e3907ed91220 tools/libxl/Makefile
--- a/tools/libxl/Makefile	Fri Sep 30 14:38:55 2011 +0200
+++ b/tools/libxl/Makefile	Fri Sep 30 14:38:55 2011 +0200
@@ -32,6 +32,15 @@ endif
 LIBXL_OBJS-$(CONFIG_X86) += libxl_cpuid.o
 LIBXL_OBJS-$(CONFIG_IA64) += libxl_nocpuid.o
 
+ifeq ($(CONFIG_NetBSD),y)
+LIBXL_OBJS-y += libxl_netbsd.o
+else ifeq ($(CONFIG_Linux),y)
+LIBXL_OBJS-y += libxl_linux.o
+else
+$(error Your Operating System is not supported by libxenlight, \
+please check libxl_linux.c and libxl_netbsd.c to see how to get it ported)
+endif
+
 LIBXL_LIBS += -lyajl
 
 LIBXL_OBJS = flexarray.o libxl.o libxl_create.o libxl_dm.o libxl_pci.o \
diff -r a0f9c898470c -r e3907ed91220 tools/libxl/libxl_device.c
--- a/tools/libxl/libxl_device.c	Fri Sep 30 14:38:55 2011 +0200
+++ b/tools/libxl/libxl_device.c	Fri Sep 30 14:38:55 2011 +0200
@@ -138,15 +138,14 @@ static int disk_try_backend(disk_try_bac
               a->disk->format == LIBXL_DISK_FORMAT_EMPTY)) {
             goto bad_format;
         }
-        if (a->disk->format != LIBXL_DISK_FORMAT_EMPTY &&
-            !S_ISBLK(a->stab.st_mode)) {
-            LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Disk vdev=%s, backend phy"
-                       " unsuitable as phys path not a block device",
-                       a->disk->vdev);
-            return 0;
-        }
 
-        return backend;
+        if (libxl__try_phy_backend(a->stab.st_mode))
+            return backend;
+
+        LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Disk vdev=%s, backend phy"
+                   " unsuitable as phys path not a block device",
+                   a->disk->vdev);
+        return 0;
 
     case LIBXL_DISK_BACKEND_TAP:
         if (!libxl__blktap_enabled(a->gc)) {
diff -r a0f9c898470c -r e3907ed91220 tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Fri Sep 30 14:38:55 2011 +0200
+++ b/tools/libxl/libxl_internal.h	Fri Sep 30 14:38:55 2011 +0200
@@ -252,6 +252,15 @@ _hidden int libxl__device_destroy(libxl_
 _hidden int libxl__devices_destroy(libxl__gc *gc, uint32_t domid, int force);
 _hidden int libxl__wait_for_backend(libxl__gc *gc, char *be_path, char *state);
 
+/*
+ * libxl__try_phy_backend - Check if there's support for the passed
+ * type of file using the PHY backend
+ * st_mode: mode_t of the file, as returned by stat function
+ *
+ * Returns 0 on success, and < 0 on error.
+ */
+_hidden int libxl__try_phy_backend(mode_t st_mode);
+
 /* from libxl_pci */
 
 _hidden int libxl__device_pci_add(libxl__gc *gc, uint32_t domid, libxl_device_pci *pcidev, int starting);
diff -r a0f9c898470c -r e3907ed91220 tools/libxl/libxl_linux.c
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/tools/libxl/libxl_linux.c	Fri Sep 30 14:38:55 2011 +0200
@@ -0,0 +1,27 @@
+/*
+ * Copyright (C) 2011
+ * Author Roger Pau Monne <roger.pau@entel.upc.edu>
+ *
+ * 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 <sys/stat.h>
+
+#include "libxl_internal.h"
+ 
+int libxl__try_phy_backend(mode_t st_mode)
+{
+    if (!S_ISBLK(st_mode)) {
+        return 0;
+    }
+
+    return 1;
+}
diff -r a0f9c898470c -r e3907ed91220 tools/libxl/libxl_netbsd.c
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/tools/libxl/libxl_netbsd.c	Fri Sep 30 14:38:55 2011 +0200
@@ -0,0 +1,26 @@
+/*
+ * Copyright (C) 2011
+ * Author Roger Pau Monne <roger.pau@entel.upc.edu>
+ *
+ * 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 <sys/stat.h>
+
+#include "libxl_internal.h"
+
+int libxl__try_phy_backend(mode_t st_mode)
+{
+    if (S_ISREG(st_mode) || S_ISBLK(st_mode))
+        return 1;
+
+    return 0;
+}

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 09:30:15 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 09: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.xensource.com>)
	id 1RaOgW-0001FZ-LG; Tue, 13 Dec 2011 09:30:04 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RaOgU-0001CF-JU
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 09:30:02 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1323768509!51936179!3
X-Originating-IP: [209.85.216.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26489 invoked from network); 13 Dec 2011 09:28:45 -0000
Received: from mail-qy0-f171.google.com (HELO mail-qy0-f171.google.com)
	(209.85.216.171)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 09:28:45 -0000
Received: by mail-qy0-f171.google.com with SMTP id c20so52043537qcs.30
	for <xen-devel@lists.xensource.com>;
	Tue, 13 Dec 2011 01:29:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=ruvPIr0Sz44+TFvcoZEOwgYXP3cTDNcIDbcxFBDtY9o=;
	b=JnZXBxPFsm6XUBhmryp15tvN08Zsc01943rKpGoUwZc9Fa7YhVd/7bSSITUiwDGJH6
	deImxNj+oEkevOUHfji1tU3tHhEt/PfFHmwD7mmwlJRikF33zFRSFBrkoaUkw1ITvtan
	0g3RJiXaL3s+KjrYKfQ6XBlpbOLVH1z/JRpVA=
Received: by 10.229.135.149 with SMTP id n21mr511773qct.53.1323768548073;
	Tue, 13 Dec 2011 01:29:08 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id dj8sm16234641qab.19.2011.12.13.01.29.06
	(version=TLSv1/SSLv3 cipher=OTHER);
	Tue, 13 Dec 2011 01:29:07 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 51404e6e2d6f4d53a14deadca4b62748d449782b
Message-Id: <51404e6e2d6f4d53a14d.1323768382@loki.upc.es>
In-Reply-To: <patchbomb.1323768375@loki.upc.es>
References: <patchbomb.1323768375@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Tue, 13 Dec 2011 10:26:22 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 07 of 14 v4] hotplug NetBSD: pass an action
 instead of a state to hotplug scripts
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1323766195 -3600
# Node ID 51404e6e2d6f4d53a14deadca4b62748d449782b
# Parent  a3a95ea16ca4e34c8213522d4aae854ec16b6057
hotplug NetBSD: pass an action instead of a state to hotplug scripts

change second parameter of NetBSD hotplug scripts to take an action
(CONNECT/DISCONNECT) instead of a xenbus state.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r a3a95ea16ca4 -r 51404e6e2d6f tools/hotplug/NetBSD/block
--- a/tools/hotplug/NetBSD/block	Fri Sep 30 14:38:55 2011 +0200
+++ b/tools/hotplug/NetBSD/block	Tue Dec 13 09:49:55 2011 +0100
@@ -18,12 +18,12 @@ error() {
 	
 
 xpath=$1
-xstatus=$2
+xaction=$2
 xtype=$3
 xparams=$(xenstore-read "$xpath/params")
 
-case $xstatus in
-6)
+case $xaction in
+2)
 	# device removed
 	case $xtype in
 	file)
@@ -41,7 +41,7 @@ 6)
 	xenstore-rm $xpath
 	exit 0
 	;;
-2)
+1)
 	case $xtype in
 	file)
 		# Store the list of available vnd(4) devices in
diff -r a3a95ea16ca4 -r 51404e6e2d6f tools/hotplug/NetBSD/vif-bridge
--- a/tools/hotplug/NetBSD/vif-bridge	Fri Sep 30 14:38:55 2011 +0200
+++ b/tools/hotplug/NetBSD/vif-bridge	Tue Dec 13 09:49:55 2011 +0100
@@ -11,15 +11,15 @@ PATH=${BINDIR}:${SBINDIR}:${LIBEXEC}:${P
 export PATH
 
 xpath=$1
-xstatus=$2
+xaction=$2
 
-case $xstatus in
-6)
+case $xaction in
+2)
 	# device removed
 	xenstore-rm $xpath
 	exit 0
 	;;
-2)
+1)
 	xbridge=$(xenstore-read "$xpath/bridge")
 	xfid=$(xenstore-read "$xpath/frontend-id")
 	xhandle=$(xenstore-read "$xpath/handle")
diff -r a3a95ea16ca4 -r 51404e6e2d6f tools/hotplug/NetBSD/vif-ip
--- a/tools/hotplug/NetBSD/vif-ip	Fri Sep 30 14:38:55 2011 +0200
+++ b/tools/hotplug/NetBSD/vif-ip	Tue Dec 13 09:49:55 2011 +0100
@@ -11,15 +11,15 @@ PATH=${BINDIR}:${SBINDIR}:${LIBEXEC}:${P
 export PATH
 
 xpath=$1
-xstatus=$2
+xaction=$2
 
-case $xstatus in
-6)
+case $xaction in
+2)
 	# device removed
 	xenstore-rm $xpath
 	exit 0
 	;;
-2)
+1)
 	xip=$(xenstore-read "$xpath/ip")
 	xfid=$(xenstore-read "$xpath/frontend-id")
 	xhandle=$(xenstore-read "$xpath/handle")

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 09:30:15 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 09: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.xensource.com>)
	id 1RaOgW-0001FZ-LG; Tue, 13 Dec 2011 09:30:04 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RaOgU-0001CF-JU
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 09:30:02 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1323768509!51936179!3
X-Originating-IP: [209.85.216.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26489 invoked from network); 13 Dec 2011 09:28:45 -0000
Received: from mail-qy0-f171.google.com (HELO mail-qy0-f171.google.com)
	(209.85.216.171)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 09:28:45 -0000
Received: by mail-qy0-f171.google.com with SMTP id c20so52043537qcs.30
	for <xen-devel@lists.xensource.com>;
	Tue, 13 Dec 2011 01:29:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=ruvPIr0Sz44+TFvcoZEOwgYXP3cTDNcIDbcxFBDtY9o=;
	b=JnZXBxPFsm6XUBhmryp15tvN08Zsc01943rKpGoUwZc9Fa7YhVd/7bSSITUiwDGJH6
	deImxNj+oEkevOUHfji1tU3tHhEt/PfFHmwD7mmwlJRikF33zFRSFBrkoaUkw1ITvtan
	0g3RJiXaL3s+KjrYKfQ6XBlpbOLVH1z/JRpVA=
Received: by 10.229.135.149 with SMTP id n21mr511773qct.53.1323768548073;
	Tue, 13 Dec 2011 01:29:08 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id dj8sm16234641qab.19.2011.12.13.01.29.06
	(version=TLSv1/SSLv3 cipher=OTHER);
	Tue, 13 Dec 2011 01:29:07 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 51404e6e2d6f4d53a14deadca4b62748d449782b
Message-Id: <51404e6e2d6f4d53a14d.1323768382@loki.upc.es>
In-Reply-To: <patchbomb.1323768375@loki.upc.es>
References: <patchbomb.1323768375@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Tue, 13 Dec 2011 10:26:22 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 07 of 14 v4] hotplug NetBSD: pass an action
 instead of a state to hotplug scripts
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1323766195 -3600
# Node ID 51404e6e2d6f4d53a14deadca4b62748d449782b
# Parent  a3a95ea16ca4e34c8213522d4aae854ec16b6057
hotplug NetBSD: pass an action instead of a state to hotplug scripts

change second parameter of NetBSD hotplug scripts to take an action
(CONNECT/DISCONNECT) instead of a xenbus state.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r a3a95ea16ca4 -r 51404e6e2d6f tools/hotplug/NetBSD/block
--- a/tools/hotplug/NetBSD/block	Fri Sep 30 14:38:55 2011 +0200
+++ b/tools/hotplug/NetBSD/block	Tue Dec 13 09:49:55 2011 +0100
@@ -18,12 +18,12 @@ error() {
 	
 
 xpath=$1
-xstatus=$2
+xaction=$2
 xtype=$3
 xparams=$(xenstore-read "$xpath/params")
 
-case $xstatus in
-6)
+case $xaction in
+2)
 	# device removed
 	case $xtype in
 	file)
@@ -41,7 +41,7 @@ 6)
 	xenstore-rm $xpath
 	exit 0
 	;;
-2)
+1)
 	case $xtype in
 	file)
 		# Store the list of available vnd(4) devices in
diff -r a3a95ea16ca4 -r 51404e6e2d6f tools/hotplug/NetBSD/vif-bridge
--- a/tools/hotplug/NetBSD/vif-bridge	Fri Sep 30 14:38:55 2011 +0200
+++ b/tools/hotplug/NetBSD/vif-bridge	Tue Dec 13 09:49:55 2011 +0100
@@ -11,15 +11,15 @@ PATH=${BINDIR}:${SBINDIR}:${LIBEXEC}:${P
 export PATH
 
 xpath=$1
-xstatus=$2
+xaction=$2
 
-case $xstatus in
-6)
+case $xaction in
+2)
 	# device removed
 	xenstore-rm $xpath
 	exit 0
 	;;
-2)
+1)
 	xbridge=$(xenstore-read "$xpath/bridge")
 	xfid=$(xenstore-read "$xpath/frontend-id")
 	xhandle=$(xenstore-read "$xpath/handle")
diff -r a3a95ea16ca4 -r 51404e6e2d6f tools/hotplug/NetBSD/vif-ip
--- a/tools/hotplug/NetBSD/vif-ip	Fri Sep 30 14:38:55 2011 +0200
+++ b/tools/hotplug/NetBSD/vif-ip	Tue Dec 13 09:49:55 2011 +0100
@@ -11,15 +11,15 @@ PATH=${BINDIR}:${SBINDIR}:${LIBEXEC}:${P
 export PATH
 
 xpath=$1
-xstatus=$2
+xaction=$2
 
-case $xstatus in
-6)
+case $xaction in
+2)
 	# device removed
 	xenstore-rm $xpath
 	exit 0
 	;;
-2)
+1)
 	xip=$(xenstore-read "$xpath/ip")
 	xfid=$(xenstore-read "$xpath/frontend-id")
 	xhandle=$(xenstore-read "$xpath/handle")

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 09:30:15 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 09: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.xensource.com>)
	id 1RaOgR-0001D7-Uv; Tue, 13 Dec 2011 09:29:59 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RaOgP-0001BJ-NN
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 09:29:58 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1323768537!5313926!2
X-Originating-IP: [209.85.216.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9166 invoked from network); 13 Dec 2011 09:29:03 -0000
Received: from mail-qw0-f43.google.com (HELO mail-qw0-f43.google.com)
	(209.85.216.43)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 09:29:03 -0000
Received: by mail-qw0-f43.google.com with SMTP id g27so23025472qab.9
	for <xen-devel@lists.xensource.com>;
	Tue, 13 Dec 2011 01:29:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=puEk+rCZRNSseDZAJ9njYY+BnI21RuEuldAf6s/BG/w=;
	b=QfI5678xaQalgdcfuSe3z6L1vOyaKywSAO1ia7vu3TnjNf6uSHKs0pa3s+8qlP/Igx
	hf8K0D4jqR6MRmJHwKSMTOKzmj7TwMC7OQ5+vVb2r7GNuHwVd2Ee9YkrYpPmj6WT0lCq
	qsLq+RPd4UjcbMQWqlhlZadtOtT8Cw8OpI5UY=
Received: by 10.224.106.5 with SMTP id v5mr1650329qao.74.1323768542324;
	Tue, 13 Dec 2011 01:29:02 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id dj8sm16234641qab.19.2011.12.13.01.29.00
	(version=TLSv1/SSLv3 cipher=OTHER);
	Tue, 13 Dec 2011 01:29:01 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: d5f1ab565bf64c98c04720bafe50fa4cb6b1592f
Message-Id: <d5f1ab565bf64c98c047.1323768379@loki.upc.es>
In-Reply-To: <patchbomb.1323768375@loki.upc.es>
References: <patchbomb.1323768375@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Tue, 13 Dec 2011 10:26:19 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 04 of 14 v4] libxl: introduce
	libxl__wait_for_device_state
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1323766195 -3600
# Node ID d5f1ab565bf64c98c04720bafe50fa4cb6b1592f
# Parent  573a246bf0c6b3ad01473d350a2c3c5aad30c351
libxl: introduce libxl__wait_for_device_state

This is a generic function, that waits for xs watches to reach a
certain state and then executes the passed helper function. Removed
wait_for_dev_destroy and used this new function instead. This
function will also be used by future patches that need to wait for
the initialization of devices before executing hotplug scripts.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 573a246bf0c6 -r d5f1ab565bf6 tools/libxl/libxl_device.c
--- a/tools/libxl/libxl_device.c	Tue Dec 13 09:49:55 2011 +0100
+++ b/tools/libxl/libxl_device.c	Tue Dec 13 09:49:55 2011 +0100
@@ -370,7 +370,9 @@ int libxl__device_disk_dev_number(const 
  * Returns 0 if a device is removed, ERROR_* if an error
  * or timeout occurred.
  */
-static int wait_for_dev_destroy(libxl__gc *gc, struct timeval *tv)
+int libxl__wait_for_device_state(libxl__gc *gc, struct timeval *tv,
+                                 XenbusState state,
+                                 libxl__device_state_handler handler)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
     int nfds, rc;
@@ -395,17 +397,14 @@ start:
         default:
             l1 = xs_read_watch(ctx->xsh, &n);
             if (l1 != NULL) {
-                char *state = libxl__xs_read(gc, XBT_NULL,
+                char *sstate = libxl__xs_read(gc, XBT_NULL,
                                              l1[XS_WATCH_PATH]);
-                if (!state || atoi(state) == 6) {
-                    xs_unwatch(ctx->xsh, l1[0], l1[1]);
-                    xs_rm(ctx->xsh, XBT_NULL, l1[XS_WATCH_TOKEN]);
-                    LIBXL__LOG(ctx, LIBXL__LOG_DEBUG,
-                               "Destroyed device backend at %s",
-                               l1[XS_WATCH_TOKEN]);
-                    rc = 0;
+                if (!sstate || atoi(sstate) == state) {
+                    /* Call handler function if present */
+                    if (handler)
+                        rc = handler(gc, l1, sstate);
                 } else {
-                    /* State is not "disconnected", continue waiting... */
+                    /* State is different than expected, continue waiting... */
                     goto start;
                 }
                 free(l1);
@@ -418,6 +417,23 @@ start:
 }
 
 /*
+ * Handler function for device destruction to be passed to
+ * libxl__wait_for_device_state
+ */
+static int destroy_device(libxl__gc *gc, char **l1, char *state)
+{
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+
+    xs_unwatch(ctx->xsh, l1[0], l1[1]);
+    xs_rm(ctx->xsh, XBT_NULL, l1[XS_WATCH_TOKEN]);
+    LIBXL__LOG(ctx, LIBXL__LOG_DEBUG,
+               "Destroyed device backend at %s",
+               l1[XS_WATCH_TOKEN]);
+
+    return 0;
+}
+
+/*
  * Returns 0 (device already destroyed) or 1 (caller must
  * wait_for_dev_destroy) on success, ERROR_* on fail.
  */
@@ -458,7 +474,8 @@ retry_transaction:
         struct timeval tv;
         tv.tv_sec = LIBXL_DESTROY_TIMEOUT;
         tv.tv_usec = 0;
-        rc = wait_for_dev_destroy(gc, &tv);
+        rc = libxl__wait_for_device_state(gc, &tv, XenbusStateClosed,
+                                          destroy_device);
         if (rc < 0) /* an error or timeout occurred, clear watches */
             xs_unwatch(ctx->xsh, state_path, be_path);
         xs_rm(ctx->xsh, XBT_NULL, libxl__device_frontend_path(gc, dev));
@@ -566,7 +583,8 @@ int libxl__devices_destroy(libxl__gc *gc
         tv.tv_sec = LIBXL_DESTROY_TIMEOUT;
         tv.tv_usec = 0;
         while (n_watches > 0) {
-            if (wait_for_dev_destroy(gc, &tv) < 0) {
+            if (libxl__wait_for_device_state(gc, &tv, XenbusStateClosed,
+                                             destroy_device) < 0) {
                 /* function returned ERROR_* */
                 break;
             } else {
diff -r 573a246bf0c6 -r d5f1ab565bf6 tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Tue Dec 13 09:49:55 2011 +0100
+++ b/tools/libxl/libxl_internal.h	Tue Dec 13 09:49:55 2011 +0100
@@ -20,11 +20,14 @@
 #include <stdint.h>
 #include <stdarg.h>
 #include <stdlib.h>
+#include <sys/time.h>
 
 #include <xs.h>
 #include <xenctrl.h>
 #include "xentoollog.h"
 
+#include <xen/io/xenbus.h>
+
 #if __GNUC__ > 3 || (__GNUC__ == 3 && __GNUC_MINOR__ >= 1)
 #define _hidden __attribute__((visibility("hidden")))
 #define _protected __attribute__((visibility("protected")))
@@ -252,6 +255,31 @@ _hidden int libxl__device_destroy(libxl_
 _hidden int libxl__devices_destroy(libxl__gc *gc, uint32_t domid, int force);
 _hidden int libxl__wait_for_backend(libxl__gc *gc, char *be_path, char *state);
 
+/* Handler for the libxl__wait_for_device_state callback */
+/*
+ * libxl__device_state_handler - Handler for the libxl__wait_for_device_state
+ * gc: allocation pool
+ * l1: array containing the path and token
+ * state: string that contains the state of the device
+ *
+ * Returns 0 on success, and < 0 on error.
+ */
+typedef int libxl__device_state_handler(libxl__gc *gc, char **l1, char *state);
+
+/*
+ * libxl__wait_for_device_state - waits a given time for a device to
+ * reach a given state
+ * gc: allocation pool
+ * tv: timeval struct containing the maximum time to wait
+ * state: state to wait for (check xen/io/xenbus.h)
+ * handler: callback function to execute when state is reached
+ *
+ * Returns 0 on success, and < 0 on error.
+ */
+_hidden int libxl__wait_for_device_state(libxl__gc *gc, struct timeval *tv,
+                                         XenbusState state,
+                                         libxl__device_state_handler handler);
+
 /*
  * libxl__try_phy_backend - Check if there's support for the passed
  * type of file using the PHY backend

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 09:30:15 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 09: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.xensource.com>)
	id 1RaOgR-0001D7-Uv; Tue, 13 Dec 2011 09:29:59 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RaOgP-0001BJ-NN
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 09:29:58 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1323768537!5313926!2
X-Originating-IP: [209.85.216.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9166 invoked from network); 13 Dec 2011 09:29:03 -0000
Received: from mail-qw0-f43.google.com (HELO mail-qw0-f43.google.com)
	(209.85.216.43)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 09:29:03 -0000
Received: by mail-qw0-f43.google.com with SMTP id g27so23025472qab.9
	for <xen-devel@lists.xensource.com>;
	Tue, 13 Dec 2011 01:29:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=puEk+rCZRNSseDZAJ9njYY+BnI21RuEuldAf6s/BG/w=;
	b=QfI5678xaQalgdcfuSe3z6L1vOyaKywSAO1ia7vu3TnjNf6uSHKs0pa3s+8qlP/Igx
	hf8K0D4jqR6MRmJHwKSMTOKzmj7TwMC7OQ5+vVb2r7GNuHwVd2Ee9YkrYpPmj6WT0lCq
	qsLq+RPd4UjcbMQWqlhlZadtOtT8Cw8OpI5UY=
Received: by 10.224.106.5 with SMTP id v5mr1650329qao.74.1323768542324;
	Tue, 13 Dec 2011 01:29:02 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id dj8sm16234641qab.19.2011.12.13.01.29.00
	(version=TLSv1/SSLv3 cipher=OTHER);
	Tue, 13 Dec 2011 01:29:01 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: d5f1ab565bf64c98c04720bafe50fa4cb6b1592f
Message-Id: <d5f1ab565bf64c98c047.1323768379@loki.upc.es>
In-Reply-To: <patchbomb.1323768375@loki.upc.es>
References: <patchbomb.1323768375@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Tue, 13 Dec 2011 10:26:19 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 04 of 14 v4] libxl: introduce
	libxl__wait_for_device_state
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1323766195 -3600
# Node ID d5f1ab565bf64c98c04720bafe50fa4cb6b1592f
# Parent  573a246bf0c6b3ad01473d350a2c3c5aad30c351
libxl: introduce libxl__wait_for_device_state

This is a generic function, that waits for xs watches to reach a
certain state and then executes the passed helper function. Removed
wait_for_dev_destroy and used this new function instead. This
function will also be used by future patches that need to wait for
the initialization of devices before executing hotplug scripts.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 573a246bf0c6 -r d5f1ab565bf6 tools/libxl/libxl_device.c
--- a/tools/libxl/libxl_device.c	Tue Dec 13 09:49:55 2011 +0100
+++ b/tools/libxl/libxl_device.c	Tue Dec 13 09:49:55 2011 +0100
@@ -370,7 +370,9 @@ int libxl__device_disk_dev_number(const 
  * Returns 0 if a device is removed, ERROR_* if an error
  * or timeout occurred.
  */
-static int wait_for_dev_destroy(libxl__gc *gc, struct timeval *tv)
+int libxl__wait_for_device_state(libxl__gc *gc, struct timeval *tv,
+                                 XenbusState state,
+                                 libxl__device_state_handler handler)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
     int nfds, rc;
@@ -395,17 +397,14 @@ start:
         default:
             l1 = xs_read_watch(ctx->xsh, &n);
             if (l1 != NULL) {
-                char *state = libxl__xs_read(gc, XBT_NULL,
+                char *sstate = libxl__xs_read(gc, XBT_NULL,
                                              l1[XS_WATCH_PATH]);
-                if (!state || atoi(state) == 6) {
-                    xs_unwatch(ctx->xsh, l1[0], l1[1]);
-                    xs_rm(ctx->xsh, XBT_NULL, l1[XS_WATCH_TOKEN]);
-                    LIBXL__LOG(ctx, LIBXL__LOG_DEBUG,
-                               "Destroyed device backend at %s",
-                               l1[XS_WATCH_TOKEN]);
-                    rc = 0;
+                if (!sstate || atoi(sstate) == state) {
+                    /* Call handler function if present */
+                    if (handler)
+                        rc = handler(gc, l1, sstate);
                 } else {
-                    /* State is not "disconnected", continue waiting... */
+                    /* State is different than expected, continue waiting... */
                     goto start;
                 }
                 free(l1);
@@ -418,6 +417,23 @@ start:
 }
 
 /*
+ * Handler function for device destruction to be passed to
+ * libxl__wait_for_device_state
+ */
+static int destroy_device(libxl__gc *gc, char **l1, char *state)
+{
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+
+    xs_unwatch(ctx->xsh, l1[0], l1[1]);
+    xs_rm(ctx->xsh, XBT_NULL, l1[XS_WATCH_TOKEN]);
+    LIBXL__LOG(ctx, LIBXL__LOG_DEBUG,
+               "Destroyed device backend at %s",
+               l1[XS_WATCH_TOKEN]);
+
+    return 0;
+}
+
+/*
  * Returns 0 (device already destroyed) or 1 (caller must
  * wait_for_dev_destroy) on success, ERROR_* on fail.
  */
@@ -458,7 +474,8 @@ retry_transaction:
         struct timeval tv;
         tv.tv_sec = LIBXL_DESTROY_TIMEOUT;
         tv.tv_usec = 0;
-        rc = wait_for_dev_destroy(gc, &tv);
+        rc = libxl__wait_for_device_state(gc, &tv, XenbusStateClosed,
+                                          destroy_device);
         if (rc < 0) /* an error or timeout occurred, clear watches */
             xs_unwatch(ctx->xsh, state_path, be_path);
         xs_rm(ctx->xsh, XBT_NULL, libxl__device_frontend_path(gc, dev));
@@ -566,7 +583,8 @@ int libxl__devices_destroy(libxl__gc *gc
         tv.tv_sec = LIBXL_DESTROY_TIMEOUT;
         tv.tv_usec = 0;
         while (n_watches > 0) {
-            if (wait_for_dev_destroy(gc, &tv) < 0) {
+            if (libxl__wait_for_device_state(gc, &tv, XenbusStateClosed,
+                                             destroy_device) < 0) {
                 /* function returned ERROR_* */
                 break;
             } else {
diff -r 573a246bf0c6 -r d5f1ab565bf6 tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Tue Dec 13 09:49:55 2011 +0100
+++ b/tools/libxl/libxl_internal.h	Tue Dec 13 09:49:55 2011 +0100
@@ -20,11 +20,14 @@
 #include <stdint.h>
 #include <stdarg.h>
 #include <stdlib.h>
+#include <sys/time.h>
 
 #include <xs.h>
 #include <xenctrl.h>
 #include "xentoollog.h"
 
+#include <xen/io/xenbus.h>
+
 #if __GNUC__ > 3 || (__GNUC__ == 3 && __GNUC_MINOR__ >= 1)
 #define _hidden __attribute__((visibility("hidden")))
 #define _protected __attribute__((visibility("protected")))
@@ -252,6 +255,31 @@ _hidden int libxl__device_destroy(libxl_
 _hidden int libxl__devices_destroy(libxl__gc *gc, uint32_t domid, int force);
 _hidden int libxl__wait_for_backend(libxl__gc *gc, char *be_path, char *state);
 
+/* Handler for the libxl__wait_for_device_state callback */
+/*
+ * libxl__device_state_handler - Handler for the libxl__wait_for_device_state
+ * gc: allocation pool
+ * l1: array containing the path and token
+ * state: string that contains the state of the device
+ *
+ * Returns 0 on success, and < 0 on error.
+ */
+typedef int libxl__device_state_handler(libxl__gc *gc, char **l1, char *state);
+
+/*
+ * libxl__wait_for_device_state - waits a given time for a device to
+ * reach a given state
+ * gc: allocation pool
+ * tv: timeval struct containing the maximum time to wait
+ * state: state to wait for (check xen/io/xenbus.h)
+ * handler: callback function to execute when state is reached
+ *
+ * Returns 0 on success, and < 0 on error.
+ */
+_hidden int libxl__wait_for_device_state(libxl__gc *gc, struct timeval *tv,
+                                         XenbusState state,
+                                         libxl__device_state_handler handler);
+
 /*
  * libxl__try_phy_backend - Check if there's support for the passed
  * type of file using the PHY backend

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 09:30:16 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 09:30:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaOge-0001Lm-Fw; Tue, 13 Dec 2011 09:30:12 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RaOgd-0001GH-2Z
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 09:30:11 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1323768509!51936179!5
X-Originating-IP: [209.85.216.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26982 invoked from network); 13 Dec 2011 09:28:54 -0000
Received: from mail-qy0-f171.google.com (HELO mail-qy0-f171.google.com)
	(209.85.216.171)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 09:28:54 -0000
Received: by mail-qy0-f171.google.com with SMTP id c20so52043537qcs.30
	for <xen-devel@lists.xensource.com>;
	Tue, 13 Dec 2011 01:29:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=KxXM347uy8TRYzo9fS13aMn+kM2rf5S9WxU09D//Euk=;
	b=YGxUm/K1IhSqE+uLBumkJhlKrN6SUQuRjIJvCCghvnmP0G+off8gbMztH8l9qOqdyj
	uvCRraE8/qoLqNu0QH/azMiSP6Yece4RzO5+e/9a867kZ+X2UEtO4rKujr39dkgGDNHu
	WYSSmUkVTskGV+N0bl5r/inadcKL36HBuM8A0=
Received: by 10.224.113.137 with SMTP id a9mr1641396qaq.87.1323768556922;
	Tue, 13 Dec 2011 01:29:16 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id dj8sm16234641qab.19.2011.12.13.01.29.15
	(version=TLSv1/SSLv3 cipher=OTHER);
	Tue, 13 Dec 2011 01:29:16 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 35c322e6020501447936e56cafceb8bbc1b2e980
Message-Id: <35c322e6020501447936.1323768387@loki.upc.es>
In-Reply-To: <patchbomb.1323768375@loki.upc.es>
References: <patchbomb.1323768375@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Tue, 13 Dec 2011 10:26:27 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 12 of 14 v4] libxl: set frontend status to 6 on
	domain destroy
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1323766195 -3600
# Node ID 35c322e6020501447936e56cafceb8bbc1b2e980
# Parent  a36942bf253c957179d4fb406ac0a45c0ddd2b28
libxl: set frontend status to 6 on domain destroy

Set frontend status to 6 on domain destruction and wait for devices to
be disconnected before executing hotplug scripts.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r a36942bf253c -r 35c322e60205 tools/libxl/libxl_device.c
--- a/tools/libxl/libxl_device.c	Tue Dec 13 09:49:55 2011 +0100
+++ b/tools/libxl/libxl_device.c	Tue Dec 13 09:49:55 2011 +0100
@@ -513,10 +513,7 @@ int libxl__device_destroy(libxl__gc *gc,
     char *be_path = libxl__device_backend_path(gc, dev);
     char *fe_path = libxl__device_frontend_path(gc, dev);
 
-    /* 
-     * Run hotplug scripts, which will probably not be able to
-     * execute successfully since the device may still be plugged
-     */
+    libxl__xs_write(gc, XBT_NULL, libxl__sprintf(gc, "%s/%s", fe_path, "state"), "6");
     libxl__device_execute_hotplug(gc, dev, DISCONNECT);
 
     xs_rm(ctx->xsh, XBT_NULL, be_path);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 09:30:16 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 09:30:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaOge-0001Lm-Fw; Tue, 13 Dec 2011 09:30:12 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RaOgd-0001GH-2Z
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 09:30:11 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1323768509!51936179!5
X-Originating-IP: [209.85.216.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26982 invoked from network); 13 Dec 2011 09:28:54 -0000
Received: from mail-qy0-f171.google.com (HELO mail-qy0-f171.google.com)
	(209.85.216.171)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 09:28:54 -0000
Received: by mail-qy0-f171.google.com with SMTP id c20so52043537qcs.30
	for <xen-devel@lists.xensource.com>;
	Tue, 13 Dec 2011 01:29:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=KxXM347uy8TRYzo9fS13aMn+kM2rf5S9WxU09D//Euk=;
	b=YGxUm/K1IhSqE+uLBumkJhlKrN6SUQuRjIJvCCghvnmP0G+off8gbMztH8l9qOqdyj
	uvCRraE8/qoLqNu0QH/azMiSP6Yece4RzO5+e/9a867kZ+X2UEtO4rKujr39dkgGDNHu
	WYSSmUkVTskGV+N0bl5r/inadcKL36HBuM8A0=
Received: by 10.224.113.137 with SMTP id a9mr1641396qaq.87.1323768556922;
	Tue, 13 Dec 2011 01:29:16 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id dj8sm16234641qab.19.2011.12.13.01.29.15
	(version=TLSv1/SSLv3 cipher=OTHER);
	Tue, 13 Dec 2011 01:29:16 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 35c322e6020501447936e56cafceb8bbc1b2e980
Message-Id: <35c322e6020501447936.1323768387@loki.upc.es>
In-Reply-To: <patchbomb.1323768375@loki.upc.es>
References: <patchbomb.1323768375@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Tue, 13 Dec 2011 10:26:27 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 12 of 14 v4] libxl: set frontend status to 6 on
	domain destroy
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1323766195 -3600
# Node ID 35c322e6020501447936e56cafceb8bbc1b2e980
# Parent  a36942bf253c957179d4fb406ac0a45c0ddd2b28
libxl: set frontend status to 6 on domain destroy

Set frontend status to 6 on domain destruction and wait for devices to
be disconnected before executing hotplug scripts.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r a36942bf253c -r 35c322e60205 tools/libxl/libxl_device.c
--- a/tools/libxl/libxl_device.c	Tue Dec 13 09:49:55 2011 +0100
+++ b/tools/libxl/libxl_device.c	Tue Dec 13 09:49:55 2011 +0100
@@ -513,10 +513,7 @@ int libxl__device_destroy(libxl__gc *gc,
     char *be_path = libxl__device_backend_path(gc, dev);
     char *fe_path = libxl__device_frontend_path(gc, dev);
 
-    /* 
-     * Run hotplug scripts, which will probably not be able to
-     * execute successfully since the device may still be plugged
-     */
+    libxl__xs_write(gc, XBT_NULL, libxl__sprintf(gc, "%s/%s", fe_path, "state"), "6");
     libxl__device_execute_hotplug(gc, dev, DISCONNECT);
 
     xs_rm(ctx->xsh, XBT_NULL, be_path);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 09:30:16 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 09:30:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaOgZ-0001HK-94; Tue, 13 Dec 2011 09:30:07 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RaOgY-0001Dd-3S
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 09:30:06 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1323768534!7022555!3
X-Originating-IP: [209.85.216.50]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6540 invoked from network); 13 Dec 2011 09:29:12 -0000
Received: from mail-qw0-f50.google.com (HELO mail-qw0-f50.google.com)
	(209.85.216.50)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 09:29:12 -0000
Received: by mail-qw0-f50.google.com with SMTP id a17so33205897qae.9
	for <xen-devel@lists.xensource.com>;
	Tue, 13 Dec 2011 01:29:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=0QHAY9/F58PZ481DRrKD9T7jPqQdHSW4RcKqcu3aIpw=;
	b=MD2HfZ61tWM+n97D6RU1lhwgcUq/E3sznipV5fvWPX/2r8JEEjF/faHsYi222MSVCC
	ovtt2+0l8F3KMDCd3zXqb1jIFc1z7VkUk8eEBgeNdGbOpqhWRXXMrHDLBta6LIWgqSC6
	cBHyNUZDi0+UweulG+mKsFGAupMIUF+eeeomw=
Received: by 10.224.177.16 with SMTP id bg16mr1649747qab.7.1323768551842;
	Tue, 13 Dec 2011 01:29:11 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id dj8sm16234641qab.19.2011.12.13.01.29.10
	(version=TLSv1/SSLv3 cipher=OTHER);
	Tue, 13 Dec 2011 01:29:10 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 263959b9bc339a60da119c09c4fe229d29d7911e
Message-Id: <263959b9bc339a60da11.1323768384@loki.upc.es>
In-Reply-To: <patchbomb.1323768375@loki.upc.es>
References: <patchbomb.1323768375@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Tue, 13 Dec 2011 10:26:24 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 09 of 14 v4] hotplug: remove debug messages from
 NetBSD hotplug scripts
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1323766195 -3600
# Node ID 263959b9bc339a60da119c09c4fe229d29d7911e
# Parent  30f2db9a780fe36eeacf6dabd76bb2577248edea
hotplug: remove debug messages from NetBSD hotplug scripts

Remove unecessary debug messages from NetBSD hotplug scripts, left
error messages only.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 30f2db9a780f -r 263959b9bc33 tools/hotplug/NetBSD/block
--- a/tools/hotplug/NetBSD/block	Tue Dec 13 09:49:55 2011 +0100
+++ b/tools/hotplug/NetBSD/block	Tue Dec 13 09:49:55 2011 +0100
@@ -64,14 +64,12 @@ 1)
 			if [ "$status" = "free" ] && \
 			    vnconfig /dev/${disk}d $xparams >/dev/null; then
 				device=/dev/${disk}d
-				echo vnconfig /dev/${disk}d $xparams
 				break	
 			fi
 		done
 		if [ x$device = x ] ; then
 			error "no available vnd device"
 		fi
-		echo xenstore-write $xpath/vnd $device
 		xenstore-write $xpath/vnd $device
 		;;
 	phy)
@@ -79,9 +77,7 @@ 1)
 		;;
 	esac
 	physical_device=$(stat -f '%r' "$device")
-	echo xenstore-write $xpath/physical-device $physical_device
 	xenstore-write $xpath/physical-device $physical_device
-	echo xenstore-write $xpath/hotplug-status connected
 	xenstore-write $xpath/hotplug-status connected
 	exit 0
 	;;
diff -r 30f2db9a780f -r 263959b9bc33 tools/hotplug/NetBSD/vif-bridge
--- a/tools/hotplug/NetBSD/vif-bridge	Tue Dec 13 09:49:55 2011 +0100
+++ b/tools/hotplug/NetBSD/vif-bridge	Tue Dec 13 09:49:55 2011 +0100
@@ -24,12 +24,9 @@ 1)
 	xfid=$(xenstore-read "$xpath/frontend-id")
 	xhandle=$(xenstore-read "$xpath/handle")
 	iface=$(xenstore-read "$xpath/vifname")
-	echo ifconfig $iface up
 	ifconfig $iface up
 	brconfig $xbridge add $iface
-	echo brconfig $xbridge add $iface
 	xenstore-write $xpath/hotplug-status connected
-	echo xenstore-write $xpath/hotplug-status connected
 	exit 0
 	;;
 *)
diff -r 30f2db9a780f -r 263959b9bc33 tools/hotplug/NetBSD/vif-ip
--- a/tools/hotplug/NetBSD/vif-ip	Tue Dec 13 09:49:55 2011 +0100
+++ b/tools/hotplug/NetBSD/vif-ip	Tue Dec 13 09:49:55 2011 +0100
@@ -24,10 +24,8 @@ 1)
 	xfid=$(xenstore-read "$xpath/frontend-id")
 	xhandle=$(xenstore-read "$xpath/handle")
 	iface=$(xenstore-read "$xpath/vifname")
-	echo ifconfig $iface $xip up
 	ifconfig $iface $xip up
 	xenstore-write $xpath/hotplug-status connected
-	echo xenstore-write $xpath/hotplug-status connected
 	exit 0
 	;;
 *)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 09:30:16 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 09:30:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaOgZ-0001HK-94; Tue, 13 Dec 2011 09:30:07 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RaOgY-0001Dd-3S
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 09:30:06 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1323768534!7022555!3
X-Originating-IP: [209.85.216.50]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6540 invoked from network); 13 Dec 2011 09:29:12 -0000
Received: from mail-qw0-f50.google.com (HELO mail-qw0-f50.google.com)
	(209.85.216.50)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 09:29:12 -0000
Received: by mail-qw0-f50.google.com with SMTP id a17so33205897qae.9
	for <xen-devel@lists.xensource.com>;
	Tue, 13 Dec 2011 01:29:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=0QHAY9/F58PZ481DRrKD9T7jPqQdHSW4RcKqcu3aIpw=;
	b=MD2HfZ61tWM+n97D6RU1lhwgcUq/E3sznipV5fvWPX/2r8JEEjF/faHsYi222MSVCC
	ovtt2+0l8F3KMDCd3zXqb1jIFc1z7VkUk8eEBgeNdGbOpqhWRXXMrHDLBta6LIWgqSC6
	cBHyNUZDi0+UweulG+mKsFGAupMIUF+eeeomw=
Received: by 10.224.177.16 with SMTP id bg16mr1649747qab.7.1323768551842;
	Tue, 13 Dec 2011 01:29:11 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id dj8sm16234641qab.19.2011.12.13.01.29.10
	(version=TLSv1/SSLv3 cipher=OTHER);
	Tue, 13 Dec 2011 01:29:10 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 263959b9bc339a60da119c09c4fe229d29d7911e
Message-Id: <263959b9bc339a60da11.1323768384@loki.upc.es>
In-Reply-To: <patchbomb.1323768375@loki.upc.es>
References: <patchbomb.1323768375@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Tue, 13 Dec 2011 10:26:24 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 09 of 14 v4] hotplug: remove debug messages from
 NetBSD hotplug scripts
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1323766195 -3600
# Node ID 263959b9bc339a60da119c09c4fe229d29d7911e
# Parent  30f2db9a780fe36eeacf6dabd76bb2577248edea
hotplug: remove debug messages from NetBSD hotplug scripts

Remove unecessary debug messages from NetBSD hotplug scripts, left
error messages only.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 30f2db9a780f -r 263959b9bc33 tools/hotplug/NetBSD/block
--- a/tools/hotplug/NetBSD/block	Tue Dec 13 09:49:55 2011 +0100
+++ b/tools/hotplug/NetBSD/block	Tue Dec 13 09:49:55 2011 +0100
@@ -64,14 +64,12 @@ 1)
 			if [ "$status" = "free" ] && \
 			    vnconfig /dev/${disk}d $xparams >/dev/null; then
 				device=/dev/${disk}d
-				echo vnconfig /dev/${disk}d $xparams
 				break	
 			fi
 		done
 		if [ x$device = x ] ; then
 			error "no available vnd device"
 		fi
-		echo xenstore-write $xpath/vnd $device
 		xenstore-write $xpath/vnd $device
 		;;
 	phy)
@@ -79,9 +77,7 @@ 1)
 		;;
 	esac
 	physical_device=$(stat -f '%r' "$device")
-	echo xenstore-write $xpath/physical-device $physical_device
 	xenstore-write $xpath/physical-device $physical_device
-	echo xenstore-write $xpath/hotplug-status connected
 	xenstore-write $xpath/hotplug-status connected
 	exit 0
 	;;
diff -r 30f2db9a780f -r 263959b9bc33 tools/hotplug/NetBSD/vif-bridge
--- a/tools/hotplug/NetBSD/vif-bridge	Tue Dec 13 09:49:55 2011 +0100
+++ b/tools/hotplug/NetBSD/vif-bridge	Tue Dec 13 09:49:55 2011 +0100
@@ -24,12 +24,9 @@ 1)
 	xfid=$(xenstore-read "$xpath/frontend-id")
 	xhandle=$(xenstore-read "$xpath/handle")
 	iface=$(xenstore-read "$xpath/vifname")
-	echo ifconfig $iface up
 	ifconfig $iface up
 	brconfig $xbridge add $iface
-	echo brconfig $xbridge add $iface
 	xenstore-write $xpath/hotplug-status connected
-	echo xenstore-write $xpath/hotplug-status connected
 	exit 0
 	;;
 *)
diff -r 30f2db9a780f -r 263959b9bc33 tools/hotplug/NetBSD/vif-ip
--- a/tools/hotplug/NetBSD/vif-ip	Tue Dec 13 09:49:55 2011 +0100
+++ b/tools/hotplug/NetBSD/vif-ip	Tue Dec 13 09:49:55 2011 +0100
@@ -24,10 +24,8 @@ 1)
 	xfid=$(xenstore-read "$xpath/frontend-id")
 	xhandle=$(xenstore-read "$xpath/handle")
 	iface=$(xenstore-read "$xpath/vifname")
-	echo ifconfig $iface $xip up
 	ifconfig $iface $xip up
 	xenstore-write $xpath/hotplug-status connected
-	echo xenstore-write $xpath/hotplug-status connected
 	exit 0
 	;;
 *)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 09:30:19 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 09:30:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaOgd-0001KT-2b; Tue, 13 Dec 2011 09:30:11 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RaOgb-0001FE-G4
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 09:30:09 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1323768534!7022555!4
X-Originating-IP: [209.85.216.50]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6813 invoked from network); 13 Dec 2011 09:29:15 -0000
Received: from mail-qw0-f50.google.com (HELO mail-qw0-f50.google.com)
	(209.85.216.50)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 09:29:15 -0000
Received: by mail-qw0-f50.google.com with SMTP id a17so33205897qae.9
	for <xen-devel@lists.xensource.com>;
	Tue, 13 Dec 2011 01:29:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=hLMksiLAhxUXxd4/s6vb751OysR39nYT44ccfT5nqbA=;
	b=BnBYi6T6Y1VoHa9bP1y3GZV154lp7igqfxNmouUrl7D9ZGrjyA7m4F8/jYmSBLo7Fs
	eCgcHao5Oyuxhcekj3nRJKbw0PM2BiIq4776vy/pnSfe7KzYHJtGwzREzvQ0+oL9g2ms
	FcPFZzDQk/ZvVwPDHyvyhSVlqKpGuT9+MvDCI=
Received: by 10.224.116.145 with SMTP id m17mr1658388qaq.64.1323768555295;
	Tue, 13 Dec 2011 01:29:15 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id dj8sm16234641qab.19.2011.12.13.01.29.13
	(version=TLSv1/SSLv3 cipher=OTHER);
	Tue, 13 Dec 2011 01:29:14 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: a36942bf253c957179d4fb406ac0a45c0ddd2b28
Message-Id: <a36942bf253c957179d4.1323768386@loki.upc.es>
In-Reply-To: <patchbomb.1323768375@loki.upc.es>
References: <patchbomb.1323768375@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Tue, 13 Dec 2011 10:26:26 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 11 of 14 v4] libxl: fix incorrect log message in
 libxl_domain_destroy
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1323766195 -3600
# Node ID a36942bf253c957179d4fb406ac0a45c0ddd2b28
# Parent  d599451d870d77e05c6b12b5560f45192f6c046e
libxl: fix incorrect log message in libxl_domain_destroy

Fix a log message that was referring to libxl_devices_dispose instead
of libxl__devices_destroy.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r d599451d870d -r a36942bf253c tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Fri Sep 30 14:38:55 2011 +0200
+++ b/tools/libxl/libxl.c	Tue Dec 13 09:49:55 2011 +0100
@@ -769,7 +769,7 @@ int libxl_domain_destroy(libxl_ctx *ctx,
         libxl__qmp_cleanup(&gc, domid);
     }
     if (libxl__devices_destroy(&gc, domid, force) < 0)
-        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "libxl_devices_dispose failed for %d", domid);
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "libxl__devices_destroy failed for %d", domid);
 
     vm_path = libxl__xs_read(&gc, XBT_NULL, libxl__sprintf(&gc, "%s/vm", dom_path));
     if (vm_path)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 09:30:19 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 09:30:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaOgd-0001KT-2b; Tue, 13 Dec 2011 09:30:11 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RaOgb-0001FE-G4
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 09:30:09 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1323768534!7022555!4
X-Originating-IP: [209.85.216.50]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6813 invoked from network); 13 Dec 2011 09:29:15 -0000
Received: from mail-qw0-f50.google.com (HELO mail-qw0-f50.google.com)
	(209.85.216.50)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 09:29:15 -0000
Received: by mail-qw0-f50.google.com with SMTP id a17so33205897qae.9
	for <xen-devel@lists.xensource.com>;
	Tue, 13 Dec 2011 01:29:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=hLMksiLAhxUXxd4/s6vb751OysR39nYT44ccfT5nqbA=;
	b=BnBYi6T6Y1VoHa9bP1y3GZV154lp7igqfxNmouUrl7D9ZGrjyA7m4F8/jYmSBLo7Fs
	eCgcHao5Oyuxhcekj3nRJKbw0PM2BiIq4776vy/pnSfe7KzYHJtGwzREzvQ0+oL9g2ms
	FcPFZzDQk/ZvVwPDHyvyhSVlqKpGuT9+MvDCI=
Received: by 10.224.116.145 with SMTP id m17mr1658388qaq.64.1323768555295;
	Tue, 13 Dec 2011 01:29:15 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id dj8sm16234641qab.19.2011.12.13.01.29.13
	(version=TLSv1/SSLv3 cipher=OTHER);
	Tue, 13 Dec 2011 01:29:14 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: a36942bf253c957179d4fb406ac0a45c0ddd2b28
Message-Id: <a36942bf253c957179d4.1323768386@loki.upc.es>
In-Reply-To: <patchbomb.1323768375@loki.upc.es>
References: <patchbomb.1323768375@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Tue, 13 Dec 2011 10:26:26 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 11 of 14 v4] libxl: fix incorrect log message in
 libxl_domain_destroy
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1323766195 -3600
# Node ID a36942bf253c957179d4fb406ac0a45c0ddd2b28
# Parent  d599451d870d77e05c6b12b5560f45192f6c046e
libxl: fix incorrect log message in libxl_domain_destroy

Fix a log message that was referring to libxl_devices_dispose instead
of libxl__devices_destroy.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r d599451d870d -r a36942bf253c tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Fri Sep 30 14:38:55 2011 +0200
+++ b/tools/libxl/libxl.c	Tue Dec 13 09:49:55 2011 +0100
@@ -769,7 +769,7 @@ int libxl_domain_destroy(libxl_ctx *ctx,
         libxl__qmp_cleanup(&gc, domid);
     }
     if (libxl__devices_destroy(&gc, domid, force) < 0)
-        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "libxl_devices_dispose failed for %d", domid);
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "libxl__devices_destroy failed for %d", domid);
 
     vm_path = libxl__xs_read(&gc, XBT_NULL, libxl__sprintf(&gc, "%s/vm", dom_path));
     if (vm_path)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 09:30:19 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 09:30:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaOgc-0001K1-MG; Tue, 13 Dec 2011 09:30:10 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RaOga-0001Er-Qc
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 09:30:09 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1323768537!5313926!4
X-Originating-IP: [209.85.216.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9820 invoked from network); 13 Dec 2011 09:29:13 -0000
Received: from mail-qw0-f43.google.com (HELO mail-qw0-f43.google.com)
	(209.85.216.43)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 09:29:13 -0000
Received: by mail-qw0-f43.google.com with SMTP id g27so23025472qab.9
	for <xen-devel@lists.xensource.com>;
	Tue, 13 Dec 2011 01:29:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=CzJ1HRLuC6N5/s9YNUVjBO2/JbxxXID0H6ORVUC9fP4=;
	b=cBf5dHCpeqtGbpUvrL+/JNmpLhl3D+dG0XIJTGLcQ9Vdp1bJ+QMQ2xm6lf0peQWL5Q
	XScXcEN6HpPHuCesfYGlFiKlAaUPut5zAOgvQ9DkGzLk8/P+opS0U2MUVa9tdr9BD7c4
	lDhJ/4JUKzLLtxGNc7H8RXmDOVtTRhUpRRAI4=
Received: by 10.224.189.11 with SMTP id dc11mr1655025qab.35.1323768553653;
	Tue, 13 Dec 2011 01:29:13 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id dj8sm16234641qab.19.2011.12.13.01.29.11
	(version=TLSv1/SSLv3 cipher=OTHER);
	Tue, 13 Dec 2011 01:29:12 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: d599451d870d77e05c6b12b5560f45192f6c046e
Message-Id: <d599451d870d77e05c6b.1323768385@loki.upc.es>
In-Reply-To: <patchbomb.1323768375@loki.upc.es>
References: <patchbomb.1323768375@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Tue, 13 Dec 2011 10:26:25 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 10 of 14 v4] rc.d NetBSD: don't start
 xenbackendd by default, only when xend needs it
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1317386335 -7200
# Node ID d599451d870d77e05c6b12b5560f45192f6c046e
# Parent  263959b9bc339a60da119c09c4fe229d29d7911e
rc.d NetBSD: don't start xenbackendd by default, only when xend needs it.

With the move of hotplug scripts from xenbackendd to libxl
xenbackendd is no longer needed by libxl, only start it when xend is
started.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 263959b9bc33 -r d599451d870d tools/hotplug/NetBSD/rc.d/xenbackendd
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/tools/hotplug/NetBSD/rc.d/xenbackendd	Fri Sep 30 14:38:55 2011 +0200
@@ -0,0 +1,27 @@
+#!/bin/sh
+#
+# PROVIDE: xenbackendd
+# REQUIRE: xencommons
+
+. /etc/rc.subr
+
+DIR=$(dirname "$0")
+. "${DIR}/xen-hotplugpath.sh"
+
+LD_LIBRARY_PATH="${LIBDIR}"
+export LD_LIBRARY_PATH PYTHONPATH
+PATH="${PATH}:${SBINDIR}"
+export PATH
+
+name="xenbackendd"
+rcvar=$name
+command="${SBINDIR}/xenbackendd"
+if [ -n "${XENBACKENDD_DEBUG}" ]; then
+	command_args="${XENBACKENDD_ARGS} -d"
+else
+	command_args="${XENBACKENDD_ARGS}"
+fi
+
+load_rc_config $name
+run_rc_command "$1"
+
diff -r 263959b9bc33 -r d599451d870d tools/hotplug/NetBSD/rc.d/xencommons
--- a/tools/hotplug/NetBSD/rc.d/xencommons	Tue Dec 13 09:49:55 2011 +0100
+++ b/tools/hotplug/NetBSD/rc.d/xencommons	Fri Sep 30 14:38:55 2011 +0200
@@ -22,8 +22,6 @@ required_files="/kern/xen/privcmd"
 
 XENSTORED_PIDFILE="/var/run/xenstored.pid"
 XENCONSOLED_PIDFILE="/var/run/xenconsoled.pid"
-XENBACKENDD_PIDFILE="/var/run/xenbackendd.pid"
-#XENBACKENDD_DEBUG=1
 #XENCONSOLED_TRACE="/var/log/xen/xenconsole-trace.log"
 #XENSTORED_TRACE="/var/log/xen/xenstore-trace.log"
 
@@ -46,7 +44,7 @@ xen_startcmd()
 			XENSTORED_ROOTDIR="/var/lib/xenstored"
 		fi
 		rm -f ${XENSTORED_ROOTDIR}/tdb* >/dev/null 2>&1
-		printf "Starting xenservices: xenstored, xenconsoled, xenbackendd."
+		printf "Starting xenservices: xenstored, xenconsoled."
 		XENSTORED_ARGS=" --pid-file ${XENSTORED_PIDFILE}"
 		if [ -n "${XENSTORED_TRACE}" ]; then
 			XENSTORED_ARGS="${XENSTORED_ARGS} -T /var/log/xen/xenstored-trace.log"
@@ -58,7 +56,7 @@ xen_startcmd()
 			sleep 1
 		done
 	else
-		printf "Starting xenservices: xenconsoled, xenbackendd."
+		printf "Starting xenservices: xenconsoled."
 	fi
 
 	XENCONSOLED_ARGS=""
@@ -68,13 +66,6 @@ xen_startcmd()
 
 	${SBINDIR}/xenconsoled ${XENCONSOLED_ARGS}
 
-	XENBACKENDD_ARGS=""
-	if [ -n "${XENBACKENDD_DEBUG}" ]; then
-		XENBACKENDD_ARGS="${XENBACKENDD_ARGS} -d"
-	fi
-
-	${SBINDIR}/xenbackendd ${XENBACKENDD_ARGS}
-
 	printf "\n"
 
 	printf "Setting domain 0 name.\n"
@@ -87,8 +78,6 @@ xen_stop()
 	printf "Stopping xencommons.\n"
 	printf "WARNING: Not stopping xenstored, as it cannot be restarted.\n"
 
-	rc_pid=$(check_pidfile ${XENBACKENDD_PIDFILE} ${SBINDIR}/xenbackendd)
-	pids="$pids $rc_pid"
 	rc_pid=$(check_pidfile ${XENCONSOLED_PIDFILE} ${SBINDIR}/xenconsoled)
 	pids="$pids $rc_pid"
 
@@ -108,17 +97,12 @@ xen_status()
 		pids="$pids $xenconsoled_pid"
 	fi
 
-	xenbackend_pid=$(check_pidfile ${XENBACKENDD_PIDFILE} ${SBINDIR}/xenbackendd)
-	if test -n ${xenbackend_pid}; then
-		pids="$pids $xenbackend_pid"
-	fi
-
-	if test -n "$xenbackend_pid" -a -n "$xenconsoled_pid" -a -n "$xenstored_pid";
+	if test -n "$xenconsoled_pid" -a -n "$xenstored_pid";
 	then
 		echo "xencommons are running as pids $pids."
 		return 0
 	fi
-	if test -z "$xenbackend_pid" -a -z "$xenconsoled_pid" -a -z "$xenstored_pid";
+	if test -z "$xenconsoled_pid" -a -z "$xenstored_pid";
 	then
 		echo "xencommons are not running."
 		return 0
@@ -134,11 +118,6 @@ xen_status()
 	else
 		echo "xenconsoled is not running."
 	fi
-	if test -n $xenbackend_pid; then
-		echo "xenbackendd is running as pid $xenbackend_pid."
-	else
-		echo "xenbackendd is not running."
-	fi
 }
 
 load_rc_config $name
diff -r 263959b9bc33 -r d599451d870d tools/hotplug/NetBSD/rc.d/xend
--- a/tools/hotplug/NetBSD/rc.d/xend	Tue Dec 13 09:49:55 2011 +0100
+++ b/tools/hotplug/NetBSD/rc.d/xend	Fri Sep 30 14:38:55 2011 +0200
@@ -1,7 +1,7 @@
 #!/bin/sh
 #
 # PROVIDE: xend
-# REQUIRE: xencommons
+# REQUIRE: xencommons xenbackendd
 
 . /etc/rc.subr
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 09:30:19 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 09:30:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaOgc-0001K1-MG; Tue, 13 Dec 2011 09:30:10 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RaOga-0001Er-Qc
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 09:30:09 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1323768537!5313926!4
X-Originating-IP: [209.85.216.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9820 invoked from network); 13 Dec 2011 09:29:13 -0000
Received: from mail-qw0-f43.google.com (HELO mail-qw0-f43.google.com)
	(209.85.216.43)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 09:29:13 -0000
Received: by mail-qw0-f43.google.com with SMTP id g27so23025472qab.9
	for <xen-devel@lists.xensource.com>;
	Tue, 13 Dec 2011 01:29:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=CzJ1HRLuC6N5/s9YNUVjBO2/JbxxXID0H6ORVUC9fP4=;
	b=cBf5dHCpeqtGbpUvrL+/JNmpLhl3D+dG0XIJTGLcQ9Vdp1bJ+QMQ2xm6lf0peQWL5Q
	XScXcEN6HpPHuCesfYGlFiKlAaUPut5zAOgvQ9DkGzLk8/P+opS0U2MUVa9tdr9BD7c4
	lDhJ/4JUKzLLtxGNc7H8RXmDOVtTRhUpRRAI4=
Received: by 10.224.189.11 with SMTP id dc11mr1655025qab.35.1323768553653;
	Tue, 13 Dec 2011 01:29:13 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id dj8sm16234641qab.19.2011.12.13.01.29.11
	(version=TLSv1/SSLv3 cipher=OTHER);
	Tue, 13 Dec 2011 01:29:12 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: d599451d870d77e05c6b12b5560f45192f6c046e
Message-Id: <d599451d870d77e05c6b.1323768385@loki.upc.es>
In-Reply-To: <patchbomb.1323768375@loki.upc.es>
References: <patchbomb.1323768375@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Tue, 13 Dec 2011 10:26:25 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 10 of 14 v4] rc.d NetBSD: don't start
 xenbackendd by default, only when xend needs it
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1317386335 -7200
# Node ID d599451d870d77e05c6b12b5560f45192f6c046e
# Parent  263959b9bc339a60da119c09c4fe229d29d7911e
rc.d NetBSD: don't start xenbackendd by default, only when xend needs it.

With the move of hotplug scripts from xenbackendd to libxl
xenbackendd is no longer needed by libxl, only start it when xend is
started.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 263959b9bc33 -r d599451d870d tools/hotplug/NetBSD/rc.d/xenbackendd
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/tools/hotplug/NetBSD/rc.d/xenbackendd	Fri Sep 30 14:38:55 2011 +0200
@@ -0,0 +1,27 @@
+#!/bin/sh
+#
+# PROVIDE: xenbackendd
+# REQUIRE: xencommons
+
+. /etc/rc.subr
+
+DIR=$(dirname "$0")
+. "${DIR}/xen-hotplugpath.sh"
+
+LD_LIBRARY_PATH="${LIBDIR}"
+export LD_LIBRARY_PATH PYTHONPATH
+PATH="${PATH}:${SBINDIR}"
+export PATH
+
+name="xenbackendd"
+rcvar=$name
+command="${SBINDIR}/xenbackendd"
+if [ -n "${XENBACKENDD_DEBUG}" ]; then
+	command_args="${XENBACKENDD_ARGS} -d"
+else
+	command_args="${XENBACKENDD_ARGS}"
+fi
+
+load_rc_config $name
+run_rc_command "$1"
+
diff -r 263959b9bc33 -r d599451d870d tools/hotplug/NetBSD/rc.d/xencommons
--- a/tools/hotplug/NetBSD/rc.d/xencommons	Tue Dec 13 09:49:55 2011 +0100
+++ b/tools/hotplug/NetBSD/rc.d/xencommons	Fri Sep 30 14:38:55 2011 +0200
@@ -22,8 +22,6 @@ required_files="/kern/xen/privcmd"
 
 XENSTORED_PIDFILE="/var/run/xenstored.pid"
 XENCONSOLED_PIDFILE="/var/run/xenconsoled.pid"
-XENBACKENDD_PIDFILE="/var/run/xenbackendd.pid"
-#XENBACKENDD_DEBUG=1
 #XENCONSOLED_TRACE="/var/log/xen/xenconsole-trace.log"
 #XENSTORED_TRACE="/var/log/xen/xenstore-trace.log"
 
@@ -46,7 +44,7 @@ xen_startcmd()
 			XENSTORED_ROOTDIR="/var/lib/xenstored"
 		fi
 		rm -f ${XENSTORED_ROOTDIR}/tdb* >/dev/null 2>&1
-		printf "Starting xenservices: xenstored, xenconsoled, xenbackendd."
+		printf "Starting xenservices: xenstored, xenconsoled."
 		XENSTORED_ARGS=" --pid-file ${XENSTORED_PIDFILE}"
 		if [ -n "${XENSTORED_TRACE}" ]; then
 			XENSTORED_ARGS="${XENSTORED_ARGS} -T /var/log/xen/xenstored-trace.log"
@@ -58,7 +56,7 @@ xen_startcmd()
 			sleep 1
 		done
 	else
-		printf "Starting xenservices: xenconsoled, xenbackendd."
+		printf "Starting xenservices: xenconsoled."
 	fi
 
 	XENCONSOLED_ARGS=""
@@ -68,13 +66,6 @@ xen_startcmd()
 
 	${SBINDIR}/xenconsoled ${XENCONSOLED_ARGS}
 
-	XENBACKENDD_ARGS=""
-	if [ -n "${XENBACKENDD_DEBUG}" ]; then
-		XENBACKENDD_ARGS="${XENBACKENDD_ARGS} -d"
-	fi
-
-	${SBINDIR}/xenbackendd ${XENBACKENDD_ARGS}
-
 	printf "\n"
 
 	printf "Setting domain 0 name.\n"
@@ -87,8 +78,6 @@ xen_stop()
 	printf "Stopping xencommons.\n"
 	printf "WARNING: Not stopping xenstored, as it cannot be restarted.\n"
 
-	rc_pid=$(check_pidfile ${XENBACKENDD_PIDFILE} ${SBINDIR}/xenbackendd)
-	pids="$pids $rc_pid"
 	rc_pid=$(check_pidfile ${XENCONSOLED_PIDFILE} ${SBINDIR}/xenconsoled)
 	pids="$pids $rc_pid"
 
@@ -108,17 +97,12 @@ xen_status()
 		pids="$pids $xenconsoled_pid"
 	fi
 
-	xenbackend_pid=$(check_pidfile ${XENBACKENDD_PIDFILE} ${SBINDIR}/xenbackendd)
-	if test -n ${xenbackend_pid}; then
-		pids="$pids $xenbackend_pid"
-	fi
-
-	if test -n "$xenbackend_pid" -a -n "$xenconsoled_pid" -a -n "$xenstored_pid";
+	if test -n "$xenconsoled_pid" -a -n "$xenstored_pid";
 	then
 		echo "xencommons are running as pids $pids."
 		return 0
 	fi
-	if test -z "$xenbackend_pid" -a -z "$xenconsoled_pid" -a -z "$xenstored_pid";
+	if test -z "$xenconsoled_pid" -a -z "$xenstored_pid";
 	then
 		echo "xencommons are not running."
 		return 0
@@ -134,11 +118,6 @@ xen_status()
 	else
 		echo "xenconsoled is not running."
 	fi
-	if test -n $xenbackend_pid; then
-		echo "xenbackendd is running as pid $xenbackend_pid."
-	else
-		echo "xenbackendd is not running."
-	fi
 }
 
 load_rc_config $name
diff -r 263959b9bc33 -r d599451d870d tools/hotplug/NetBSD/rc.d/xend
--- a/tools/hotplug/NetBSD/rc.d/xend	Tue Dec 13 09:49:55 2011 +0100
+++ b/tools/hotplug/NetBSD/rc.d/xend	Fri Sep 30 14:38:55 2011 +0200
@@ -1,7 +1,7 @@
 #!/bin/sh
 #
 # PROVIDE: xend
-# REQUIRE: xencommons
+# REQUIRE: xencommons xenbackendd
 
 . /etc/rc.subr
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 09:30:19 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 09:30:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaOgh-0001Ov-2c; Tue, 13 Dec 2011 09:30:15 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RaOgf-0001Hw-Bl
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 09:30:13 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1323768534!7022555!5
X-Originating-IP: [209.85.216.50]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7056 invoked from network); 13 Dec 2011 09:29:19 -0000
Received: from mail-qw0-f50.google.com (HELO mail-qw0-f50.google.com)
	(209.85.216.50)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 09:29:19 -0000
Received: by mail-qw0-f50.google.com with SMTP id a17so33205897qae.9
	for <xen-devel@lists.xensource.com>;
	Tue, 13 Dec 2011 01:29:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=7TNf4h1ESoxxCnMwfc2uD5zeJOkRDmUpORrECjm/RnE=;
	b=UeaUXWksfIPJJo/DHqkAfLmUqObapD2SoYhNW2wl2/1NQCv0UB3hpPsdzf9tOBXtLJ
	VITQlPPSyjDIaw2M221n1XAVY3RIC2sP+JZKGEqG2jtOlFRjLHFIiP8e5S071rkfMqcD
	V0evIowax1gzMWAlTMJHeUNNqFURypOHTlmNw=
Received: by 10.224.202.8 with SMTP id fc8mr1670095qab.10.1323768558861;
	Tue, 13 Dec 2011 01:29:18 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id dj8sm16234641qab.19.2011.12.13.01.29.17
	(version=TLSv1/SSLv3 cipher=OTHER);
	Tue, 13 Dec 2011 01:29:18 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: ea1a9fe2ef02f0737fa6f0c884a5ebaeb2b08872
Message-Id: <ea1a9fe2ef02f0737fa6.1323768388@loki.upc.es>
In-Reply-To: <patchbomb.1323768375@loki.upc.es>
References: <patchbomb.1323768375@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Tue, 13 Dec 2011 10:26:28 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 13 of 14 v4] libxl: remove force parameter from
 libxl_domain_destroy
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1323766195 -3600
# Node ID ea1a9fe2ef02f0737fa6f0c884a5ebaeb2b08872
# Parent  35c322e6020501447936e56cafceb8bbc1b2e980
libxl: remove force parameter from libxl_domain_destroy

Since a destroy is considered a forced shutdown, there's no point in
passing a force parameter. All the occurences of this function have
been replaced with the proper syntax.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 35c322e60205 -r ea1a9fe2ef02 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Tue Dec 13 09:49:55 2011 +0100
+++ b/tools/libxl/libxl.c	Tue Dec 13 09:49:55 2011 +0100
@@ -719,7 +719,7 @@ int libxl_event_get_disk_eject_info(libx
     return 1;
 }
 
-int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid, int force)
+int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid)
 {
     libxl__gc gc = LIBXL_INIT_GC(ctx);
     libxl_dominfo dominfo;
@@ -768,7 +768,7 @@ int libxl_domain_destroy(libxl_ctx *ctx,
 
         libxl__qmp_cleanup(&gc, domid);
     }
-    if (libxl__devices_destroy(&gc, domid, force) < 0)
+    if (libxl__devices_destroy(&gc, domid, 1) < 0)
         LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "libxl__devices_destroy failed for %d", domid);
 
     vm_path = libxl__xs_read(&gc, XBT_NULL, libxl__sprintf(&gc, "%s/vm", dom_path));
diff -r 35c322e60205 -r ea1a9fe2ef02 tools/libxl/libxl.h
--- a/tools/libxl/libxl.h	Tue Dec 13 09:49:55 2011 +0100
+++ b/tools/libxl/libxl.h	Tue Dec 13 09:49:55 2011 +0100
@@ -269,7 +269,7 @@ int libxl_domain_suspend(libxl_ctx *ctx,
                           uint32_t domid, int fd);
 int libxl_domain_resume(libxl_ctx *ctx, uint32_t domid);
 int libxl_domain_shutdown(libxl_ctx *ctx, uint32_t domid, int req);
-int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid, int force);
+int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid);
 int libxl_domain_preserve(libxl_ctx *ctx, uint32_t domid, libxl_domain_create_info *info, const char *name_suffix, libxl_uuid new_uuid);
 
 /* get max. number of cpus supported by hypervisor */
diff -r 35c322e60205 -r ea1a9fe2ef02 tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Tue Dec 13 09:49:55 2011 +0100
+++ b/tools/libxl/libxl_create.c	Tue Dec 13 09:49:55 2011 +0100
@@ -664,7 +664,7 @@ static int do_domain_create(libxl__gc *g
 
 error_out:
     if (domid)
-        libxl_domain_destroy(ctx, domid, 0);
+        libxl_domain_destroy(ctx, domid);
 
     return ret;
 }
diff -r 35c322e60205 -r ea1a9fe2ef02 tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Tue Dec 13 09:49:55 2011 +0100
+++ b/tools/libxl/libxl_dm.c	Tue Dec 13 09:49:55 2011 +0100
@@ -919,7 +919,7 @@ int libxl__destroy_device_model(libxl__g
             goto out;
         }
         LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Device model is a stubdom, domid=%d", stubdomid);
-        ret = libxl_domain_destroy(ctx, stubdomid, 0);
+        ret = libxl_domain_destroy(ctx, stubdomid);
         if (ret)
             goto out;
     } else {
diff -r 35c322e60205 -r ea1a9fe2ef02 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Tue Dec 13 09:49:55 2011 +0100
+++ b/tools/libxl/xl_cmdimpl.c	Tue Dec 13 09:49:55 2011 +0100
@@ -1283,7 +1283,7 @@ static int handle_domain_death(libxl_ctx
         /* fall-through */
     case LIBXL_ACTION_ON_SHUTDOWN_DESTROY:
         LOG("Domain %d needs to be cleaned up: destroying the domain", domid);
-        libxl_domain_destroy(ctx, domid, 0);
+        libxl_domain_destroy(ctx, domid);
         break;
 
     case LIBXL_ACTION_ON_SHUTDOWN_COREDUMP_DESTROY:
@@ -1786,7 +1786,7 @@ start:
 error_out:
     release_lock();
     if (libxl_domid_valid_guest(domid))
-        libxl_domain_destroy(ctx, domid, 0);
+        libxl_domain_destroy(ctx, domid);
 
 out:
     if (logfile != 2)
@@ -2256,7 +2256,7 @@ static void destroy_domain(const char *p
         fprintf(stderr, "Cannot destroy privileged domain 0.\n\n");
         exit(-1);
     }
-    rc = libxl_domain_destroy(ctx, domid, 0);
+    rc = libxl_domain_destroy(ctx, domid);
     if (rc) { fprintf(stderr,"destroy failed (rc=%d)\n",rc); exit(-1); }
 }
 
@@ -2502,7 +2502,7 @@ static int save_domain(const char *p, co
     if (checkpoint)
         libxl_domain_unpause(ctx, domid);
     else
-        libxl_domain_destroy(ctx, domid, 0);
+        libxl_domain_destroy(ctx, domid);
 
     exit(0);
 }
@@ -2735,7 +2735,7 @@ static void migrate_domain(const char *d
     }
 
     fprintf(stderr, "migration sender: Target reports successful startup.\n");
-    libxl_domain_destroy(ctx, domid, 1); /* bang! */
+    libxl_domain_destroy(ctx, domid); /* bang! */
     fprintf(stderr, "Migration successful.\n");
     exit(0);
 
@@ -2852,7 +2852,7 @@ static void migrate_receive(int debug, i
     if (rc) {
         fprintf(stderr, "migration target: Failure, destroying our copy.\n");
 
-        rc2 = libxl_domain_destroy(ctx, domid, 1);
+        rc2 = libxl_domain_destroy(ctx, domid);
         if (rc2) {
             fprintf(stderr, "migration target: Failed to destroy our copy"
                     " (code %d).\n", rc2);
diff -r 35c322e60205 -r ea1a9fe2ef02 tools/python/xen/lowlevel/xl/xl.c
--- a/tools/python/xen/lowlevel/xl/xl.c	Tue Dec 13 09:49:55 2011 +0100
+++ b/tools/python/xen/lowlevel/xl/xl.c	Tue Dec 13 09:49:55 2011 +0100
@@ -437,10 +437,10 @@ static PyObject *pyxl_domain_shutdown(Xl
 
 static PyObject *pyxl_domain_destroy(XlObject *self, PyObject *args)
 {
-    int domid, force = 1;
-    if ( !PyArg_ParseTuple(args, "i|i", &domid, &force) )
+    int domid;
+    if ( !PyArg_ParseTuple(args, "i", &domid) )
         return NULL;
-    if ( libxl_domain_destroy(self->ctx, domid, force) ) {
+    if ( libxl_domain_destroy(self->ctx, domid) ) {
         PyErr_SetString(xl_error_obj, "cannot destroy domain");
         return NULL;
     }

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 09:30:19 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 09:30:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaOgh-0001Ov-2c; Tue, 13 Dec 2011 09:30:15 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RaOgf-0001Hw-Bl
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 09:30:13 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1323768534!7022555!5
X-Originating-IP: [209.85.216.50]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7056 invoked from network); 13 Dec 2011 09:29:19 -0000
Received: from mail-qw0-f50.google.com (HELO mail-qw0-f50.google.com)
	(209.85.216.50)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 09:29:19 -0000
Received: by mail-qw0-f50.google.com with SMTP id a17so33205897qae.9
	for <xen-devel@lists.xensource.com>;
	Tue, 13 Dec 2011 01:29:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=7TNf4h1ESoxxCnMwfc2uD5zeJOkRDmUpORrECjm/RnE=;
	b=UeaUXWksfIPJJo/DHqkAfLmUqObapD2SoYhNW2wl2/1NQCv0UB3hpPsdzf9tOBXtLJ
	VITQlPPSyjDIaw2M221n1XAVY3RIC2sP+JZKGEqG2jtOlFRjLHFIiP8e5S071rkfMqcD
	V0evIowax1gzMWAlTMJHeUNNqFURypOHTlmNw=
Received: by 10.224.202.8 with SMTP id fc8mr1670095qab.10.1323768558861;
	Tue, 13 Dec 2011 01:29:18 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id dj8sm16234641qab.19.2011.12.13.01.29.17
	(version=TLSv1/SSLv3 cipher=OTHER);
	Tue, 13 Dec 2011 01:29:18 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: ea1a9fe2ef02f0737fa6f0c884a5ebaeb2b08872
Message-Id: <ea1a9fe2ef02f0737fa6.1323768388@loki.upc.es>
In-Reply-To: <patchbomb.1323768375@loki.upc.es>
References: <patchbomb.1323768375@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Tue, 13 Dec 2011 10:26:28 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 13 of 14 v4] libxl: remove force parameter from
 libxl_domain_destroy
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1323766195 -3600
# Node ID ea1a9fe2ef02f0737fa6f0c884a5ebaeb2b08872
# Parent  35c322e6020501447936e56cafceb8bbc1b2e980
libxl: remove force parameter from libxl_domain_destroy

Since a destroy is considered a forced shutdown, there's no point in
passing a force parameter. All the occurences of this function have
been replaced with the proper syntax.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 35c322e60205 -r ea1a9fe2ef02 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Tue Dec 13 09:49:55 2011 +0100
+++ b/tools/libxl/libxl.c	Tue Dec 13 09:49:55 2011 +0100
@@ -719,7 +719,7 @@ int libxl_event_get_disk_eject_info(libx
     return 1;
 }
 
-int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid, int force)
+int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid)
 {
     libxl__gc gc = LIBXL_INIT_GC(ctx);
     libxl_dominfo dominfo;
@@ -768,7 +768,7 @@ int libxl_domain_destroy(libxl_ctx *ctx,
 
         libxl__qmp_cleanup(&gc, domid);
     }
-    if (libxl__devices_destroy(&gc, domid, force) < 0)
+    if (libxl__devices_destroy(&gc, domid, 1) < 0)
         LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "libxl__devices_destroy failed for %d", domid);
 
     vm_path = libxl__xs_read(&gc, XBT_NULL, libxl__sprintf(&gc, "%s/vm", dom_path));
diff -r 35c322e60205 -r ea1a9fe2ef02 tools/libxl/libxl.h
--- a/tools/libxl/libxl.h	Tue Dec 13 09:49:55 2011 +0100
+++ b/tools/libxl/libxl.h	Tue Dec 13 09:49:55 2011 +0100
@@ -269,7 +269,7 @@ int libxl_domain_suspend(libxl_ctx *ctx,
                           uint32_t domid, int fd);
 int libxl_domain_resume(libxl_ctx *ctx, uint32_t domid);
 int libxl_domain_shutdown(libxl_ctx *ctx, uint32_t domid, int req);
-int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid, int force);
+int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid);
 int libxl_domain_preserve(libxl_ctx *ctx, uint32_t domid, libxl_domain_create_info *info, const char *name_suffix, libxl_uuid new_uuid);
 
 /* get max. number of cpus supported by hypervisor */
diff -r 35c322e60205 -r ea1a9fe2ef02 tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Tue Dec 13 09:49:55 2011 +0100
+++ b/tools/libxl/libxl_create.c	Tue Dec 13 09:49:55 2011 +0100
@@ -664,7 +664,7 @@ static int do_domain_create(libxl__gc *g
 
 error_out:
     if (domid)
-        libxl_domain_destroy(ctx, domid, 0);
+        libxl_domain_destroy(ctx, domid);
 
     return ret;
 }
diff -r 35c322e60205 -r ea1a9fe2ef02 tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Tue Dec 13 09:49:55 2011 +0100
+++ b/tools/libxl/libxl_dm.c	Tue Dec 13 09:49:55 2011 +0100
@@ -919,7 +919,7 @@ int libxl__destroy_device_model(libxl__g
             goto out;
         }
         LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Device model is a stubdom, domid=%d", stubdomid);
-        ret = libxl_domain_destroy(ctx, stubdomid, 0);
+        ret = libxl_domain_destroy(ctx, stubdomid);
         if (ret)
             goto out;
     } else {
diff -r 35c322e60205 -r ea1a9fe2ef02 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Tue Dec 13 09:49:55 2011 +0100
+++ b/tools/libxl/xl_cmdimpl.c	Tue Dec 13 09:49:55 2011 +0100
@@ -1283,7 +1283,7 @@ static int handle_domain_death(libxl_ctx
         /* fall-through */
     case LIBXL_ACTION_ON_SHUTDOWN_DESTROY:
         LOG("Domain %d needs to be cleaned up: destroying the domain", domid);
-        libxl_domain_destroy(ctx, domid, 0);
+        libxl_domain_destroy(ctx, domid);
         break;
 
     case LIBXL_ACTION_ON_SHUTDOWN_COREDUMP_DESTROY:
@@ -1786,7 +1786,7 @@ start:
 error_out:
     release_lock();
     if (libxl_domid_valid_guest(domid))
-        libxl_domain_destroy(ctx, domid, 0);
+        libxl_domain_destroy(ctx, domid);
 
 out:
     if (logfile != 2)
@@ -2256,7 +2256,7 @@ static void destroy_domain(const char *p
         fprintf(stderr, "Cannot destroy privileged domain 0.\n\n");
         exit(-1);
     }
-    rc = libxl_domain_destroy(ctx, domid, 0);
+    rc = libxl_domain_destroy(ctx, domid);
     if (rc) { fprintf(stderr,"destroy failed (rc=%d)\n",rc); exit(-1); }
 }
 
@@ -2502,7 +2502,7 @@ static int save_domain(const char *p, co
     if (checkpoint)
         libxl_domain_unpause(ctx, domid);
     else
-        libxl_domain_destroy(ctx, domid, 0);
+        libxl_domain_destroy(ctx, domid);
 
     exit(0);
 }
@@ -2735,7 +2735,7 @@ static void migrate_domain(const char *d
     }
 
     fprintf(stderr, "migration sender: Target reports successful startup.\n");
-    libxl_domain_destroy(ctx, domid, 1); /* bang! */
+    libxl_domain_destroy(ctx, domid); /* bang! */
     fprintf(stderr, "Migration successful.\n");
     exit(0);
 
@@ -2852,7 +2852,7 @@ static void migrate_receive(int debug, i
     if (rc) {
         fprintf(stderr, "migration target: Failure, destroying our copy.\n");
 
-        rc2 = libxl_domain_destroy(ctx, domid, 1);
+        rc2 = libxl_domain_destroy(ctx, domid);
         if (rc2) {
             fprintf(stderr, "migration target: Failed to destroy our copy"
                     " (code %d).\n", rc2);
diff -r 35c322e60205 -r ea1a9fe2ef02 tools/python/xen/lowlevel/xl/xl.c
--- a/tools/python/xen/lowlevel/xl/xl.c	Tue Dec 13 09:49:55 2011 +0100
+++ b/tools/python/xen/lowlevel/xl/xl.c	Tue Dec 13 09:49:55 2011 +0100
@@ -437,10 +437,10 @@ static PyObject *pyxl_domain_shutdown(Xl
 
 static PyObject *pyxl_domain_destroy(XlObject *self, PyObject *args)
 {
-    int domid, force = 1;
-    if ( !PyArg_ParseTuple(args, "i|i", &domid, &force) )
+    int domid;
+    if ( !PyArg_ParseTuple(args, "i", &domid) )
         return NULL;
-    if ( libxl_domain_destroy(self->ctx, domid, force) ) {
+    if ( libxl_domain_destroy(self->ctx, domid) ) {
         PyErr_SetString(xl_error_obj, "cannot destroy domain");
         return NULL;
     }

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 09:30:25 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 09: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.xensource.com>)
	id 1RaOgi-0001SG-TK; Tue, 13 Dec 2011 09:30:16 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RaOgh-0001JZ-G1
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 09:30:15 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1323768537!5313926!5
X-Originating-IP: [209.85.216.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10152 invoked from network); 13 Dec 2011 09:29:20 -0000
Received: from mail-qw0-f43.google.com (HELO mail-qw0-f43.google.com)
	(209.85.216.43)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 09:29:20 -0000
Received: by mail-qw0-f43.google.com with SMTP id g27so23025472qab.9
	for <xen-devel@lists.xensource.com>;
	Tue, 13 Dec 2011 01:29:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=b40M7HJ6VJDWrXdkRKUcpLPGckhgcZqcOfUEXrZjVRs=;
	b=da7u6jnpp2QrpuWjO/KtQoDSrmWskK8liu5vdOPPgbpdwD2Zdv5LTN0qIhwJE9ZJgC
	VZ6Y46UTBir1aM/++bF8lAd3Pe+W0ZlY5KpYB0GRI7lQhkLIBYxMfcS7K/1GrDBUx1Wi
	b3Rl1YIdAeJowXQFmFuHzZD+OMT0FXRIzverQ=
Received: by 10.224.105.83 with SMTP id s19mr1674909qao.73.1323768560539;
	Tue, 13 Dec 2011 01:29:20 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id dj8sm16234641qab.19.2011.12.13.01.29.18
	(version=TLSv1/SSLv3 cipher=OTHER);
	Tue, 13 Dec 2011 01:29:19 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 8a84f53376862427f254a017cb52c928dbdd3d32
Message-Id: <8a84f53376862427f254.1323768389@loki.upc.es>
In-Reply-To: <patchbomb.1323768375@loki.upc.es>
References: <patchbomb.1323768375@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Tue, 13 Dec 2011 10:26:29 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 14 of 14 v4] libxl: remove force parameter from
 libxl__devices_destroy
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1323766195 -3600
# Node ID 8a84f53376862427f254a017cb52c928dbdd3d32
# Parent  ea1a9fe2ef02f0737fa6f0c884a5ebaeb2b08872
libxl: remove force parameter from libxl__devices_destroy

Remove the force flag, and always use forced destruction.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r ea1a9fe2ef02 -r 8a84f5337686 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Tue Dec 13 09:49:55 2011 +0100
+++ b/tools/libxl/libxl.c	Tue Dec 13 09:49:55 2011 +0100
@@ -768,7 +768,7 @@ int libxl_domain_destroy(libxl_ctx *ctx,
 
         libxl__qmp_cleanup(&gc, domid);
     }
-    if (libxl__devices_destroy(&gc, domid, 1) < 0)
+    if (libxl__devices_destroy(&gc, domid) < 0)
         LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "libxl__devices_destroy failed for %d", domid);
 
     vm_path = libxl__xs_read(&gc, XBT_NULL, libxl__sprintf(&gc, "%s/vm", dom_path));
diff -r ea1a9fe2ef02 -r 8a84f5337686 tools/libxl/libxl_device.c
--- a/tools/libxl/libxl_device.c	Tue Dec 13 09:49:55 2011 +0100
+++ b/tools/libxl/libxl_device.c	Tue Dec 13 09:49:55 2011 +0100
@@ -524,13 +524,13 @@ int libxl__device_destroy(libxl__gc *gc,
     return 0;
 }
 
-int libxl__devices_destroy(libxl__gc *gc, uint32_t domid, int force)
+int libxl__devices_destroy(libxl__gc *gc, uint32_t domid)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
     char *path;
     unsigned int num_kinds, num_devs;
     char **kinds = NULL, **devs = NULL;
-    int i, j, n_watches = 0;
+    int i, j;
     libxl__device dev;
     libxl__device_kind kind;
 
@@ -561,16 +561,7 @@ int libxl__devices_destroy(libxl__gc *gc
                 dev.kind = kind;
                 dev.devid = atoi(devs[j]);
 
-                if (force) {
-                    libxl__device_destroy(gc, &dev);
-                } else {
-                    int rc = libxl__device_remove(gc, &dev, 0);
-                    if (rc < 0)
-                        LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
-                                   "cannot remove device %s\n", path);
-                    else
-                        n_watches += rc;
-                }
+                libxl__device_destroy(gc, &dev);
             }
         }
     }
@@ -584,37 +575,9 @@ int libxl__devices_destroy(libxl__gc *gc
         dev.kind = LIBXL__DEVICE_KIND_CONSOLE;
         dev.devid = 0;
 
-        if (force) {
-            libxl__device_destroy(gc, &dev);
-        } else {
-            int rc = libxl__device_remove(gc, &dev, 0);
-            if (rc < 0)
-                LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
-                           "cannot remove device %s\n", path);
-            else
-                n_watches += rc;
-        }
+        libxl__device_destroy(gc, &dev);
     }
 
-    if (!force) {
-        /* Linux-ism. Most implementations leave the timeout
-         * untouched after select. Linux, however, will chip
-         * away the elapsed time from it, which is what we
-         * need to enforce a single time span waiting for
-         * device destruction. */
-        struct timeval tv;
-        tv.tv_sec = LIBXL_DESTROY_TIMEOUT;
-        tv.tv_usec = 0;
-        while (n_watches > 0) {
-            if (libxl__wait_for_device_state(gc, &tv, XenbusStateClosed,
-                                             destroy_device) < 0) {
-                /* function returned ERROR_* */
-                break;
-            } else {
-                n_watches--;
-            }
-        }
-    }
 out:
     return 0;
 }
diff -r ea1a9fe2ef02 -r 8a84f5337686 tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Tue Dec 13 09:49:55 2011 +0100
+++ b/tools/libxl/libxl_internal.h	Tue Dec 13 09:49:55 2011 +0100
@@ -252,7 +252,7 @@ _hidden int libxl__parse_backend_path(li
                                       libxl__device *dev);
 _hidden int libxl__device_remove(libxl__gc *gc, libxl__device *dev, int wait);
 _hidden int libxl__device_destroy(libxl__gc *gc, libxl__device *dev);
-_hidden int libxl__devices_destroy(libxl__gc *gc, uint32_t domid, int force);
+_hidden int libxl__devices_destroy(libxl__gc *gc, uint32_t domid);
 _hidden int libxl__wait_for_backend(libxl__gc *gc, char *be_path, char *state);
 
 /* Handler for the libxl__wait_for_device_state callback */

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 09:30:25 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 09: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.xensource.com>)
	id 1RaOgi-0001SG-TK; Tue, 13 Dec 2011 09:30:16 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RaOgh-0001JZ-G1
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 09:30:15 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1323768537!5313926!5
X-Originating-IP: [209.85.216.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10152 invoked from network); 13 Dec 2011 09:29:20 -0000
Received: from mail-qw0-f43.google.com (HELO mail-qw0-f43.google.com)
	(209.85.216.43)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 09:29:20 -0000
Received: by mail-qw0-f43.google.com with SMTP id g27so23025472qab.9
	for <xen-devel@lists.xensource.com>;
	Tue, 13 Dec 2011 01:29:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=b40M7HJ6VJDWrXdkRKUcpLPGckhgcZqcOfUEXrZjVRs=;
	b=da7u6jnpp2QrpuWjO/KtQoDSrmWskK8liu5vdOPPgbpdwD2Zdv5LTN0qIhwJE9ZJgC
	VZ6Y46UTBir1aM/++bF8lAd3Pe+W0ZlY5KpYB0GRI7lQhkLIBYxMfcS7K/1GrDBUx1Wi
	b3Rl1YIdAeJowXQFmFuHzZD+OMT0FXRIzverQ=
Received: by 10.224.105.83 with SMTP id s19mr1674909qao.73.1323768560539;
	Tue, 13 Dec 2011 01:29:20 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id dj8sm16234641qab.19.2011.12.13.01.29.18
	(version=TLSv1/SSLv3 cipher=OTHER);
	Tue, 13 Dec 2011 01:29:19 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 8a84f53376862427f254a017cb52c928dbdd3d32
Message-Id: <8a84f53376862427f254.1323768389@loki.upc.es>
In-Reply-To: <patchbomb.1323768375@loki.upc.es>
References: <patchbomb.1323768375@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Tue, 13 Dec 2011 10:26:29 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 14 of 14 v4] libxl: remove force parameter from
 libxl__devices_destroy
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1323766195 -3600
# Node ID 8a84f53376862427f254a017cb52c928dbdd3d32
# Parent  ea1a9fe2ef02f0737fa6f0c884a5ebaeb2b08872
libxl: remove force parameter from libxl__devices_destroy

Remove the force flag, and always use forced destruction.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r ea1a9fe2ef02 -r 8a84f5337686 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Tue Dec 13 09:49:55 2011 +0100
+++ b/tools/libxl/libxl.c	Tue Dec 13 09:49:55 2011 +0100
@@ -768,7 +768,7 @@ int libxl_domain_destroy(libxl_ctx *ctx,
 
         libxl__qmp_cleanup(&gc, domid);
     }
-    if (libxl__devices_destroy(&gc, domid, 1) < 0)
+    if (libxl__devices_destroy(&gc, domid) < 0)
         LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "libxl__devices_destroy failed for %d", domid);
 
     vm_path = libxl__xs_read(&gc, XBT_NULL, libxl__sprintf(&gc, "%s/vm", dom_path));
diff -r ea1a9fe2ef02 -r 8a84f5337686 tools/libxl/libxl_device.c
--- a/tools/libxl/libxl_device.c	Tue Dec 13 09:49:55 2011 +0100
+++ b/tools/libxl/libxl_device.c	Tue Dec 13 09:49:55 2011 +0100
@@ -524,13 +524,13 @@ int libxl__device_destroy(libxl__gc *gc,
     return 0;
 }
 
-int libxl__devices_destroy(libxl__gc *gc, uint32_t domid, int force)
+int libxl__devices_destroy(libxl__gc *gc, uint32_t domid)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
     char *path;
     unsigned int num_kinds, num_devs;
     char **kinds = NULL, **devs = NULL;
-    int i, j, n_watches = 0;
+    int i, j;
     libxl__device dev;
     libxl__device_kind kind;
 
@@ -561,16 +561,7 @@ int libxl__devices_destroy(libxl__gc *gc
                 dev.kind = kind;
                 dev.devid = atoi(devs[j]);
 
-                if (force) {
-                    libxl__device_destroy(gc, &dev);
-                } else {
-                    int rc = libxl__device_remove(gc, &dev, 0);
-                    if (rc < 0)
-                        LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
-                                   "cannot remove device %s\n", path);
-                    else
-                        n_watches += rc;
-                }
+                libxl__device_destroy(gc, &dev);
             }
         }
     }
@@ -584,37 +575,9 @@ int libxl__devices_destroy(libxl__gc *gc
         dev.kind = LIBXL__DEVICE_KIND_CONSOLE;
         dev.devid = 0;
 
-        if (force) {
-            libxl__device_destroy(gc, &dev);
-        } else {
-            int rc = libxl__device_remove(gc, &dev, 0);
-            if (rc < 0)
-                LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
-                           "cannot remove device %s\n", path);
-            else
-                n_watches += rc;
-        }
+        libxl__device_destroy(gc, &dev);
     }
 
-    if (!force) {
-        /* Linux-ism. Most implementations leave the timeout
-         * untouched after select. Linux, however, will chip
-         * away the elapsed time from it, which is what we
-         * need to enforce a single time span waiting for
-         * device destruction. */
-        struct timeval tv;
-        tv.tv_sec = LIBXL_DESTROY_TIMEOUT;
-        tv.tv_usec = 0;
-        while (n_watches > 0) {
-            if (libxl__wait_for_device_state(gc, &tv, XenbusStateClosed,
-                                             destroy_device) < 0) {
-                /* function returned ERROR_* */
-                break;
-            } else {
-                n_watches--;
-            }
-        }
-    }
 out:
     return 0;
 }
diff -r ea1a9fe2ef02 -r 8a84f5337686 tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Tue Dec 13 09:49:55 2011 +0100
+++ b/tools/libxl/libxl_internal.h	Tue Dec 13 09:49:55 2011 +0100
@@ -252,7 +252,7 @@ _hidden int libxl__parse_backend_path(li
                                       libxl__device *dev);
 _hidden int libxl__device_remove(libxl__gc *gc, libxl__device *dev, int wait);
 _hidden int libxl__device_destroy(libxl__gc *gc, libxl__device *dev);
-_hidden int libxl__devices_destroy(libxl__gc *gc, uint32_t domid, int force);
+_hidden int libxl__devices_destroy(libxl__gc *gc, uint32_t domid);
 _hidden int libxl__wait_for_backend(libxl__gc *gc, char *be_path, char *state);
 
 /* Handler for the libxl__wait_for_device_state callback */

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 09:31:01 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 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.xensource.com>)
	id 1RaOhN-0001rM-D8; Tue, 13 Dec 2011 09:30:57 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RaOhL-0001pX-9g
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 09:30:55 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1323768566!50376449!1
X-Originating-IP: [209.85.216.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22252 invoked from network); 13 Dec 2011 09:29:27 -0000
Received: from mail-qw0-f43.google.com (HELO mail-qw0-f43.google.com)
	(209.85.216.43)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 09:29:27 -0000
Received: by qabg27 with SMTP id g27so23028001qab.9
	for <xen-devel@lists.xensource.com>;
	Tue, 13 Dec 2011 01:30:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:user-agent:date:from:to;
	bh=1OlITc29oWF163hhL1uGOhqKY3u/6eALEi565KhS/1A=;
	b=AjUOSw6DaiBm+HMEFWCECu8EfDOT8mvyHtn9szgBfODb7ftHUgN76kNFqW0Jmj6+Wc
	EoewpkWVMpCQ43ORvJh4pytgDciN2pmkgGE4Sa6RdfM9aW1LJ2feM1PmikQtBAsbfr54
	tZpdU/wTFvwWbHjz4Ir8q8MZ+AdzdBTQo6GKs=
Received: by 10.224.116.145 with SMTP id m17mr1661142qaq.64.1323768605113;
	Tue, 13 Dec 2011 01:30:05 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id dk9sm42481309qab.0.2011.12.13.01.30.03
	(version=TLSv1/SSLv3 cipher=OTHER);
	Tue, 13 Dec 2011 01:30:04 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 7697ee23b08b8eaca9aee4f6b79cf550a490bef7
Message-Id: <7697ee23b08b8eaca9ae.1323768649@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Tue, 13 Dec 2011 10:30:49 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH] xenpaging: remove XOPEN_SOURCE
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1323768129 -3600
# Node ID 7697ee23b08b8eaca9aee4f6b79cf550a490bef7
# Parent  8a84f53376862427f254a017cb52c928dbdd3d32
xenpaging: remove XOPEN_SOURCE

The XOPEN_SOURCE define was breaking the compilation under NetBSD.
I've removed it becasue it is not necessary (at least under NetBSD).
If it is necessary for Linux, we can add a ifdef conditional to remove
this only under NetBSD.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 8a84f5337686 -r 7697ee23b08b tools/xenpaging/xenpaging.c
--- a/tools/xenpaging/xenpaging.c	Tue Dec 13 09:49:55 2011 +0100
+++ b/tools/xenpaging/xenpaging.c	Tue Dec 13 10:22:09 2011 +0100
@@ -18,7 +18,6 @@
  * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
  */
 
-#define _XOPEN_SOURCE	600
 #define _GNU_SOURCE
 
 #include <inttypes.h>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 09:31:01 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 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.xensource.com>)
	id 1RaOhN-0001rM-D8; Tue, 13 Dec 2011 09:30:57 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RaOhL-0001pX-9g
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 09:30:55 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1323768566!50376449!1
X-Originating-IP: [209.85.216.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22252 invoked from network); 13 Dec 2011 09:29:27 -0000
Received: from mail-qw0-f43.google.com (HELO mail-qw0-f43.google.com)
	(209.85.216.43)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 09:29:27 -0000
Received: by qabg27 with SMTP id g27so23028001qab.9
	for <xen-devel@lists.xensource.com>;
	Tue, 13 Dec 2011 01:30:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:user-agent:date:from:to;
	bh=1OlITc29oWF163hhL1uGOhqKY3u/6eALEi565KhS/1A=;
	b=AjUOSw6DaiBm+HMEFWCECu8EfDOT8mvyHtn9szgBfODb7ftHUgN76kNFqW0Jmj6+Wc
	EoewpkWVMpCQ43ORvJh4pytgDciN2pmkgGE4Sa6RdfM9aW1LJ2feM1PmikQtBAsbfr54
	tZpdU/wTFvwWbHjz4Ir8q8MZ+AdzdBTQo6GKs=
Received: by 10.224.116.145 with SMTP id m17mr1661142qaq.64.1323768605113;
	Tue, 13 Dec 2011 01:30:05 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id dk9sm42481309qab.0.2011.12.13.01.30.03
	(version=TLSv1/SSLv3 cipher=OTHER);
	Tue, 13 Dec 2011 01:30:04 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 7697ee23b08b8eaca9aee4f6b79cf550a490bef7
Message-Id: <7697ee23b08b8eaca9ae.1323768649@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Tue, 13 Dec 2011 10:30:49 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH] xenpaging: remove XOPEN_SOURCE
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1323768129 -3600
# Node ID 7697ee23b08b8eaca9aee4f6b79cf550a490bef7
# Parent  8a84f53376862427f254a017cb52c928dbdd3d32
xenpaging: remove XOPEN_SOURCE

The XOPEN_SOURCE define was breaking the compilation under NetBSD.
I've removed it becasue it is not necessary (at least under NetBSD).
If it is necessary for Linux, we can add a ifdef conditional to remove
this only under NetBSD.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 8a84f5337686 -r 7697ee23b08b tools/xenpaging/xenpaging.c
--- a/tools/xenpaging/xenpaging.c	Tue Dec 13 09:49:55 2011 +0100
+++ b/tools/xenpaging/xenpaging.c	Tue Dec 13 10:22:09 2011 +0100
@@ -18,7 +18,6 @@
  * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
  */
 
-#define _XOPEN_SOURCE	600
 #define _GNU_SOURCE
 
 #include <inttypes.h>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 09:31:22 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 09: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.xensource.com>)
	id 1RaOhe-00023j-R1; Tue, 13 Dec 2011 09:31:14 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RaOhd-0001zr-W3
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 09:31:14 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1323768619!7241415!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTI1NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23331 invoked from network); 13 Dec 2011 09:30:19 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 09:30:19 -0000
X-IronPort-AV: E=Sophos;i="4.71,344,1320624000"; 
   d="scan'208";a="9433722"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Dec 2011 09:29:16 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 13 Dec 2011 09:29:17 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RaOfk-0005UR-M0;
	Tue, 13 Dec 2011 09:29:16 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RaOfk-0000gU-Kn;
	Tue, 13 Dec 2011 09:29:16 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10486-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 13 Dec 2011 09:29:16 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10486: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10486 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10486/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  7ca56cca09ad
baseline version:
 xen                  1c58bb664d8d

------------------------------------------------------------
People who touched revisions under test:
  Andre Przywara <andre.przywara@amd.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Roger Pau Monne <roger.pau@entel.upc.edu>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-unstable
+ revision=7ca56cca09ad
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-unstable 7ca56cca09ad
+ branch=xen-unstable
+ revision=7ca56cca09ad
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ : xen@xenbits.xensource.com
+ : xen@xenbits.xensource.com:git/linux-pvops
+ : master
+ : tested/2.6.39.x
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r 7ca56cca09ad ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 16 changesets with 55 changes to 36 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 09:31:22 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 09: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.xensource.com>)
	id 1RaOhe-00023j-R1; Tue, 13 Dec 2011 09:31:14 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RaOhd-0001zr-W3
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 09:31:14 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1323768619!7241415!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTI1NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23331 invoked from network); 13 Dec 2011 09:30:19 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 09:30:19 -0000
X-IronPort-AV: E=Sophos;i="4.71,344,1320624000"; 
   d="scan'208";a="9433722"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Dec 2011 09:29:16 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 13 Dec 2011 09:29:17 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RaOfk-0005UR-M0;
	Tue, 13 Dec 2011 09:29:16 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RaOfk-0000gU-Kn;
	Tue, 13 Dec 2011 09:29:16 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10486-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 13 Dec 2011 09:29:16 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10486: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10486 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10486/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  7ca56cca09ad
baseline version:
 xen                  1c58bb664d8d

------------------------------------------------------------
People who touched revisions under test:
  Andre Przywara <andre.przywara@amd.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Roger Pau Monne <roger.pau@entel.upc.edu>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-unstable
+ revision=7ca56cca09ad
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-unstable 7ca56cca09ad
+ branch=xen-unstable
+ revision=7ca56cca09ad
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ : xen@xenbits.xensource.com
+ : xen@xenbits.xensource.com:git/linux-pvops
+ : master
+ : tested/2.6.39.x
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r 7ca56cca09ad ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 16 changesets with 55 changes to 36 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 09:46:42 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 09:46:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaOwJ-0004ZE-7g; Tue, 13 Dec 2011 09:46:23 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RaOwH-0004Z9-Cv
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 09:46:21 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1323769526!6670792!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTI1NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28661 invoked from network); 13 Dec 2011 09:45:27 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 09:45:27 -0000
X-IronPort-AV: E=Sophos;i="4.71,344,1320624000"; 
   d="scan'208";a="9434220"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Dec 2011 09:44:24 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 13 Dec 2011 09:44:24 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 13 Dec 2011 09:44:24 +0000
In-Reply-To: <osstest-10481-mainreport@xen.org>
References: <osstest-10481-mainreport@xen.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323769464.20077.262.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [xen-unstable test] 10481: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2011-12-13 at 05:22 +0000, xen.org wrote:
> flight 10481 xen-unstable real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/10481/
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking:
>  test-amd64-amd64-win          7 windows-install           fail REGR. vs. 10474

Failed the network connection after install
        011-12-13 01:38:35 Z guest win.guest.osstest 5a:36:0e:f1:00:0c 8936 link/ip/tcp: waiting 7000s...
        2011-12-13 01:38:35 Z guest win.guest.osstest 5a:36:0e:f1:00:0c 8936 link/ip/tcp: no active lease (waiting) ...
        2011-12-13 01:57:28 Z guest win.guest.osstest 5a:36:0e:f1:00:0c 8936 link/ip/tcp: nc: 256 (UNKNOWN) [10.80.251.132] 8936 (?) : Connection timed out |  (waiting) ...

VNC screenshot suggests the guest has booted fine and is sitting at the
screensaver.

brctl and ifconfig show that the devices are set up and in the right
places. PV NIC is not initialised (as expected) so we would expect to be
using the tap interface which has seemingly passed some traffic:
        tap5.0    Link encap:Ethernet  HWaddr fe:ff:ff:ff:ff:ff  
                  inet6 addr: fe80::fcff:ffff:feff:ffff/64 Scope:Link
                  UP BROADCAST RUNNING PROMISC MULTICAST  MTU:1500  Metric:1
                  RX packets:442 errors:0 dropped:0 overruns:0 frame:0
                  TX packets:378027 errors:0 dropped:0 overruns:0 carrier:0
                  collisions:0 txqueuelen:500 
                  RX bytes:33714 (32.9 KiB)  TX bytes:24976607 (23.8 MiB)

This being a Windows guest there isn't much debug from within the guest.
Could this be an infrastructure thing? Other similar tests passed just
fine although two similar winxp sp3 tests also failed in a similar way
(this one was sp2, some other sp3 tests did pass though). This was a
xend test while others which failed similarly were xl based so there
appears to be no correlation there.

> Tests which are failing intermittently (not blocking):
>  test-amd64-amd64-pv           9 guest-start                 fail pass in 10480

This PV guest appears to have failed for similar reasons to the above
Windows guests:

        2011-12-13 00:58:20 Z FAILURE: guest debian.guest.osstest 5a:36:0e:f1:00:01 22 link/ip/tcp: wait timed out: no active lease.
        failure: guest debian.guest.osstest 5a:36:0e:f1:00:01 22 link/ip/tcp: wait timed out: no active lease.

The guest log shows it did get an IP address at least:

        Setting kernel variables ...done.
        Configuring network interfaces...Internet Systems Consortium DHCP Client 4.1.1-P1
        Copyright 2004-2010 Internet Systems Consortium.
        All rights reserved.
        For info, please visit https://www.isc.org/software/dhcp/
        
        Listening on LPF/eth0/5a:36:0e:f1:00:01
        Sending on   LPF/eth0/5a:36:0e:f1:00:01
        Sending on   Socket/fallback
        DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 7
        DHCPOFFER from 10.80.2.2
        DHCPREQUEST on eth0 to 255.255.255.255 port 67
        DHCPACK from 10.80.2.3
        bound to 10.80.3.117 -- renewal in 18880 seconds.

>  test-amd64-amd64-xl-sedf-pin 11 guest-localmigrate          fail pass in 10480
>  test-amd64-amd64-xl-sedf     11 guest-localmigrate fail in 10480 pass in 10481
> 
> Tests which did not succeed, but are not blocking,
> including regressions (tests previously passed) regarded as allowable:

(reordered to group similar)

> test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass 
> test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
> test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
> test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
> test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
> test-i386-i386-xl-win        13 guest-stop                   fail   never pass 

These are all failing because "xl shutdown" cannot be used with a guest
without PV drivers (and prints a warning to that effect).
        2011-12-13 01:33:56 Z executing ssh ... root@10.80.249.57 xl shutdown -w win.guest.osstest
        libxl: error: libxl.c:581:libxl_domain_shutdown: HVM domain without PV drivers: graceful shutdown not possible, use destroy
        shutdown failed (rc=-3)
        
I think "xl trigger <dom> power" would be what is wanted here -- e.g.
send an ACPI power event. It could be argued that xl shutdown could do
this automatically?

>  test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass

No active link message again but this time the guest says:
        For info, please visit https://www.isc.org/software/dhcp/
        
        SIOCSIFADDR: No such device
        eth0: ERROR while getting interface flags: No such device
        eth0: ERROR while getting interface flags: No such device
        Bind socket to interface: No such device
        Failed to bring up eth0.
        done.
        Cleaning up temporary files....

If we could preserve a guest in that state and login it might prove
informative. My guess would either be a missing/faulty VF driver or udev
renaming things.

>  test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
>  test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass

Both of these appear to be similar harness issues:
        2011-12-13 02:11:21 Z toolstack xl
        Use of uninitialized value in concatenation (.) or string at ./ts-guest-start line 13.
        2011-12-13 02:11:21 Z executing ssh ... root@10.80.249.148 xl create 
        Config file not specified and none in save file

>  test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
>  test-i386-i386-win           16 leak-check/check             fail   never pass
>  test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
>  test-amd64-i386-win          16 leak-check/check             fail   never pass

These all leaked a load of /var/lib/xen/qemu-resume.N. This should be
quick & easy to fix, I'll have a look.

>  test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   never pass
>  test-i386-i386-xl-winxpsp3    7 windows-install              fail   never pass

These are failing in the same way as the one discussed right at the top.

>  test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install fail in 10480 like 10474
>  test-amd64-i386-xend-winxpsp3  7 windows-install      fail in 10480 like 10474
>  test-amd64-i386-xl-win7-amd64  7 windows-install      fail in 10480 like 10474
>  test-amd64-amd64-xl-win7-amd64  7 windows-install     fail in 10480 like 10474
>  test-amd64-i386-win           7 windows-install       fail in 10480 like 10473

These don't appear to have failed per the grid at
http://www.chiark.greenend.org.uk/~xensrcts/logs/10481/ ?

e.g. test-amd64-i386-xl-winxpsp3-vcpus1 appears to have failed at
guest-stop instead (and indeed is also listed above in that capacity)

This appears to be reporting a failure in a previous run, part of the
heisenbug detector? It might be nice to put those in a separate section
or to include some indication as the the criteria being evaluated (e.g.
are we waiting for a 3rd test to tiebreak?)

> 
> version targeted for testing:
>  xen                  7ca56cca09ad
> baseline version:
>  xen                  1c58bb664d8d
> 
> ------------------------------------------------------------
> People who touched revisions under test:
>   Andre Przywara <andre.przywara@amd.com>
>   Ian Campbell <ian.campbell@citrix.com>
>   Ian Jackson <ian.jackson@eu.citrix.com>
>   Jan Beulich <jbeulich@suse.com>
>   Roger Pau Monne <roger.pau@entel.upc.edu>
> ------------------------------------------------------------
> 
> jobs:
>  build-amd64                                                  pass    
>  build-i386                                                   pass    
>  build-amd64-oldkern                                          pass    
>  build-i386-oldkern                                           pass    
>  build-amd64-pvops                                            pass    
>  build-i386-pvops                                             pass    
>  test-amd64-amd64-xl                                          pass    
>  test-amd64-i386-xl                                           pass    
>  test-i386-i386-xl                                            pass    
>  test-amd64-i386-rhel6hvm-amd                                 fail    
>  test-amd64-amd64-xl-win7-amd64                               fail    
>  test-amd64-i386-xl-win7-amd64                                fail    
>  test-amd64-i386-xl-credit2                                   pass    
>  test-amd64-amd64-xl-pcipt-intel                              fail    
>  test-amd64-i386-rhel6hvm-intel                               fail    
>  test-amd64-i386-xl-multivcpu                                 pass    
>  test-amd64-amd64-pair                                        pass    
>  test-amd64-i386-pair                                         pass    
>  test-i386-i386-pair                                          pass    
>  test-amd64-amd64-xl-sedf-pin                                 fail    
>  test-amd64-amd64-pv                                          fail    
>  test-amd64-i386-pv                                           pass    
>  test-i386-i386-pv                                            pass    
>  test-amd64-amd64-xl-sedf                                     pass    
>  test-amd64-i386-win-vcpus1                                   fail    
>  test-amd64-i386-xl-win-vcpus1                                fail    
>  test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
>  test-amd64-amd64-win                                         fail    
>  test-amd64-i386-win                                          fail    
>  test-i386-i386-win                                           fail    
>  test-amd64-amd64-xl-win                                      fail    
>  test-i386-i386-xl-win                                        fail    
>  test-amd64-i386-xend-winxpsp3                                fail    
>  test-amd64-amd64-xl-winxpsp3                                 fail    
>  test-i386-i386-xl-winxpsp3                                   fail    
> 
> 
> ------------------------------------------------------------
> sg-report-flight on woking.cam.xci-test.com
> logs: /home/xc_osstest/logs
> images: /home/xc_osstest/images
> 
> Logs, config files, etc. are available at
>     http://www.chiark.greenend.org.uk/~xensrcts/logs
> 
> Test harness code can be found at
>     http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary
> 
> 
> Not pushing.
> 
> (No revision log; it would be 336 lines long.)
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 09:46:42 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 09:46:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaOwJ-0004ZE-7g; Tue, 13 Dec 2011 09:46:23 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RaOwH-0004Z9-Cv
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 09:46:21 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1323769526!6670792!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTI1NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28661 invoked from network); 13 Dec 2011 09:45:27 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 09:45:27 -0000
X-IronPort-AV: E=Sophos;i="4.71,344,1320624000"; 
   d="scan'208";a="9434220"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Dec 2011 09:44:24 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 13 Dec 2011 09:44:24 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 13 Dec 2011 09:44:24 +0000
In-Reply-To: <osstest-10481-mainreport@xen.org>
References: <osstest-10481-mainreport@xen.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323769464.20077.262.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [xen-unstable test] 10481: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2011-12-13 at 05:22 +0000, xen.org wrote:
> flight 10481 xen-unstable real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/10481/
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking:
>  test-amd64-amd64-win          7 windows-install           fail REGR. vs. 10474

Failed the network connection after install
        011-12-13 01:38:35 Z guest win.guest.osstest 5a:36:0e:f1:00:0c 8936 link/ip/tcp: waiting 7000s...
        2011-12-13 01:38:35 Z guest win.guest.osstest 5a:36:0e:f1:00:0c 8936 link/ip/tcp: no active lease (waiting) ...
        2011-12-13 01:57:28 Z guest win.guest.osstest 5a:36:0e:f1:00:0c 8936 link/ip/tcp: nc: 256 (UNKNOWN) [10.80.251.132] 8936 (?) : Connection timed out |  (waiting) ...

VNC screenshot suggests the guest has booted fine and is sitting at the
screensaver.

brctl and ifconfig show that the devices are set up and in the right
places. PV NIC is not initialised (as expected) so we would expect to be
using the tap interface which has seemingly passed some traffic:
        tap5.0    Link encap:Ethernet  HWaddr fe:ff:ff:ff:ff:ff  
                  inet6 addr: fe80::fcff:ffff:feff:ffff/64 Scope:Link
                  UP BROADCAST RUNNING PROMISC MULTICAST  MTU:1500  Metric:1
                  RX packets:442 errors:0 dropped:0 overruns:0 frame:0
                  TX packets:378027 errors:0 dropped:0 overruns:0 carrier:0
                  collisions:0 txqueuelen:500 
                  RX bytes:33714 (32.9 KiB)  TX bytes:24976607 (23.8 MiB)

This being a Windows guest there isn't much debug from within the guest.
Could this be an infrastructure thing? Other similar tests passed just
fine although two similar winxp sp3 tests also failed in a similar way
(this one was sp2, some other sp3 tests did pass though). This was a
xend test while others which failed similarly were xl based so there
appears to be no correlation there.

> Tests which are failing intermittently (not blocking):
>  test-amd64-amd64-pv           9 guest-start                 fail pass in 10480

This PV guest appears to have failed for similar reasons to the above
Windows guests:

        2011-12-13 00:58:20 Z FAILURE: guest debian.guest.osstest 5a:36:0e:f1:00:01 22 link/ip/tcp: wait timed out: no active lease.
        failure: guest debian.guest.osstest 5a:36:0e:f1:00:01 22 link/ip/tcp: wait timed out: no active lease.

The guest log shows it did get an IP address at least:

        Setting kernel variables ...done.
        Configuring network interfaces...Internet Systems Consortium DHCP Client 4.1.1-P1
        Copyright 2004-2010 Internet Systems Consortium.
        All rights reserved.
        For info, please visit https://www.isc.org/software/dhcp/
        
        Listening on LPF/eth0/5a:36:0e:f1:00:01
        Sending on   LPF/eth0/5a:36:0e:f1:00:01
        Sending on   Socket/fallback
        DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 7
        DHCPOFFER from 10.80.2.2
        DHCPREQUEST on eth0 to 255.255.255.255 port 67
        DHCPACK from 10.80.2.3
        bound to 10.80.3.117 -- renewal in 18880 seconds.

>  test-amd64-amd64-xl-sedf-pin 11 guest-localmigrate          fail pass in 10480
>  test-amd64-amd64-xl-sedf     11 guest-localmigrate fail in 10480 pass in 10481
> 
> Tests which did not succeed, but are not blocking,
> including regressions (tests previously passed) regarded as allowable:

(reordered to group similar)

> test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass 
> test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
> test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
> test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
> test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
> test-i386-i386-xl-win        13 guest-stop                   fail   never pass 

These are all failing because "xl shutdown" cannot be used with a guest
without PV drivers (and prints a warning to that effect).
        2011-12-13 01:33:56 Z executing ssh ... root@10.80.249.57 xl shutdown -w win.guest.osstest
        libxl: error: libxl.c:581:libxl_domain_shutdown: HVM domain without PV drivers: graceful shutdown not possible, use destroy
        shutdown failed (rc=-3)
        
I think "xl trigger <dom> power" would be what is wanted here -- e.g.
send an ACPI power event. It could be argued that xl shutdown could do
this automatically?

>  test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass

No active link message again but this time the guest says:
        For info, please visit https://www.isc.org/software/dhcp/
        
        SIOCSIFADDR: No such device
        eth0: ERROR while getting interface flags: No such device
        eth0: ERROR while getting interface flags: No such device
        Bind socket to interface: No such device
        Failed to bring up eth0.
        done.
        Cleaning up temporary files....

If we could preserve a guest in that state and login it might prove
informative. My guess would either be a missing/faulty VF driver or udev
renaming things.

>  test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
>  test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass

Both of these appear to be similar harness issues:
        2011-12-13 02:11:21 Z toolstack xl
        Use of uninitialized value in concatenation (.) or string at ./ts-guest-start line 13.
        2011-12-13 02:11:21 Z executing ssh ... root@10.80.249.148 xl create 
        Config file not specified and none in save file

>  test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
>  test-i386-i386-win           16 leak-check/check             fail   never pass
>  test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
>  test-amd64-i386-win          16 leak-check/check             fail   never pass

These all leaked a load of /var/lib/xen/qemu-resume.N. This should be
quick & easy to fix, I'll have a look.

>  test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   never pass
>  test-i386-i386-xl-winxpsp3    7 windows-install              fail   never pass

These are failing in the same way as the one discussed right at the top.

>  test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install fail in 10480 like 10474
>  test-amd64-i386-xend-winxpsp3  7 windows-install      fail in 10480 like 10474
>  test-amd64-i386-xl-win7-amd64  7 windows-install      fail in 10480 like 10474
>  test-amd64-amd64-xl-win7-amd64  7 windows-install     fail in 10480 like 10474
>  test-amd64-i386-win           7 windows-install       fail in 10480 like 10473

These don't appear to have failed per the grid at
http://www.chiark.greenend.org.uk/~xensrcts/logs/10481/ ?

e.g. test-amd64-i386-xl-winxpsp3-vcpus1 appears to have failed at
guest-stop instead (and indeed is also listed above in that capacity)

This appears to be reporting a failure in a previous run, part of the
heisenbug detector? It might be nice to put those in a separate section
or to include some indication as the the criteria being evaluated (e.g.
are we waiting for a 3rd test to tiebreak?)

> 
> version targeted for testing:
>  xen                  7ca56cca09ad
> baseline version:
>  xen                  1c58bb664d8d
> 
> ------------------------------------------------------------
> People who touched revisions under test:
>   Andre Przywara <andre.przywara@amd.com>
>   Ian Campbell <ian.campbell@citrix.com>
>   Ian Jackson <ian.jackson@eu.citrix.com>
>   Jan Beulich <jbeulich@suse.com>
>   Roger Pau Monne <roger.pau@entel.upc.edu>
> ------------------------------------------------------------
> 
> jobs:
>  build-amd64                                                  pass    
>  build-i386                                                   pass    
>  build-amd64-oldkern                                          pass    
>  build-i386-oldkern                                           pass    
>  build-amd64-pvops                                            pass    
>  build-i386-pvops                                             pass    
>  test-amd64-amd64-xl                                          pass    
>  test-amd64-i386-xl                                           pass    
>  test-i386-i386-xl                                            pass    
>  test-amd64-i386-rhel6hvm-amd                                 fail    
>  test-amd64-amd64-xl-win7-amd64                               fail    
>  test-amd64-i386-xl-win7-amd64                                fail    
>  test-amd64-i386-xl-credit2                                   pass    
>  test-amd64-amd64-xl-pcipt-intel                              fail    
>  test-amd64-i386-rhel6hvm-intel                               fail    
>  test-amd64-i386-xl-multivcpu                                 pass    
>  test-amd64-amd64-pair                                        pass    
>  test-amd64-i386-pair                                         pass    
>  test-i386-i386-pair                                          pass    
>  test-amd64-amd64-xl-sedf-pin                                 fail    
>  test-amd64-amd64-pv                                          fail    
>  test-amd64-i386-pv                                           pass    
>  test-i386-i386-pv                                            pass    
>  test-amd64-amd64-xl-sedf                                     pass    
>  test-amd64-i386-win-vcpus1                                   fail    
>  test-amd64-i386-xl-win-vcpus1                                fail    
>  test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
>  test-amd64-amd64-win                                         fail    
>  test-amd64-i386-win                                          fail    
>  test-i386-i386-win                                           fail    
>  test-amd64-amd64-xl-win                                      fail    
>  test-i386-i386-xl-win                                        fail    
>  test-amd64-i386-xend-winxpsp3                                fail    
>  test-amd64-amd64-xl-winxpsp3                                 fail    
>  test-i386-i386-xl-winxpsp3                                   fail    
> 
> 
> ------------------------------------------------------------
> sg-report-flight on woking.cam.xci-test.com
> logs: /home/xc_osstest/logs
> images: /home/xc_osstest/images
> 
> Logs, config files, etc. are available at
>     http://www.chiark.greenend.org.uk/~xensrcts/logs
> 
> Test harness code can be found at
>     http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary
> 
> 
> Not pushing.
> 
> (No revision log; it would be 336 lines long.)
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 10:03:32 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 10:03:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaPCh-0004tg-9b; Tue, 13 Dec 2011 10:03:19 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RaPCg-0004tM-I8
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 10:03:18 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1323770544!7256360!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTI1NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3579 invoked from network); 13 Dec 2011 10:02:24 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 10:02:24 -0000
X-IronPort-AV: E=Sophos;i="4.71,344,1320624000"; 
   d="scan'208";a="9434751"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Dec 2011 10:02:24 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 13 Dec 2011 10:02:24 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau Monne <roger.pau@entel.upc.edu>
Date: Tue, 13 Dec 2011 10:02:24 +0000
In-Reply-To: <7697ee23b08b8eaca9ae.1323768649@loki.upc.es>
References: <7697ee23b08b8eaca9ae.1323768649@loki.upc.es>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323770544.20077.268.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] xenpaging: remove XOPEN_SOURCE
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2011-12-13 at 09:30 +0000, Roger Pau Monne wrote:
> # HG changeset patch
> # User Roger Pau Monne <roger.pau@entel.upc.edu>
> # Date 1323768129 -3600
> # Node ID 7697ee23b08b8eaca9aee4f6b79cf550a490bef7
> # Parent  8a84f53376862427f254a017cb52c928dbdd3d32
> xenpaging: remove XOPEN_SOURCE
> 
> The XOPEN_SOURCE define was breaking the compilation under NetBSD.

How?

> I've removed it becasue it is not necessary (at least under NetBSD).
> If it is necessary for Linux, we can add a ifdef conditional to remove
> this only under NetBSD.

Removing it seems to not break Linux, at least for me.

> Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

Acked-by: Ian Campbell <ian.campbell@citrix.com>
> 
> diff -r 8a84f5337686 -r 7697ee23b08b tools/xenpaging/xenpaging.c
> --- a/tools/xenpaging/xenpaging.c	Tue Dec 13 09:49:55 2011 +0100
> +++ b/tools/xenpaging/xenpaging.c	Tue Dec 13 10:22:09 2011 +0100
> @@ -18,7 +18,6 @@
>   * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
>   */
>  
> -#define _XOPEN_SOURCE	600
>  #define _GNU_SOURCE
>  
>  #include <inttypes.h>
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 10:03:32 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 10:03:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaPCh-0004tg-9b; Tue, 13 Dec 2011 10:03:19 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RaPCg-0004tM-I8
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 10:03:18 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1323770544!7256360!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTI1NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3579 invoked from network); 13 Dec 2011 10:02:24 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 10:02:24 -0000
X-IronPort-AV: E=Sophos;i="4.71,344,1320624000"; 
   d="scan'208";a="9434751"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Dec 2011 10:02:24 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 13 Dec 2011 10:02:24 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau Monne <roger.pau@entel.upc.edu>
Date: Tue, 13 Dec 2011 10:02:24 +0000
In-Reply-To: <7697ee23b08b8eaca9ae.1323768649@loki.upc.es>
References: <7697ee23b08b8eaca9ae.1323768649@loki.upc.es>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323770544.20077.268.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] xenpaging: remove XOPEN_SOURCE
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2011-12-13 at 09:30 +0000, Roger Pau Monne wrote:
> # HG changeset patch
> # User Roger Pau Monne <roger.pau@entel.upc.edu>
> # Date 1323768129 -3600
> # Node ID 7697ee23b08b8eaca9aee4f6b79cf550a490bef7
> # Parent  8a84f53376862427f254a017cb52c928dbdd3d32
> xenpaging: remove XOPEN_SOURCE
> 
> The XOPEN_SOURCE define was breaking the compilation under NetBSD.

How?

> I've removed it becasue it is not necessary (at least under NetBSD).
> If it is necessary for Linux, we can add a ifdef conditional to remove
> this only under NetBSD.

Removing it seems to not break Linux, at least for me.

> Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

Acked-by: Ian Campbell <ian.campbell@citrix.com>
> 
> diff -r 8a84f5337686 -r 7697ee23b08b tools/xenpaging/xenpaging.c
> --- a/tools/xenpaging/xenpaging.c	Tue Dec 13 09:49:55 2011 +0100
> +++ b/tools/xenpaging/xenpaging.c	Tue Dec 13 10:22:09 2011 +0100
> @@ -18,7 +18,6 @@
>   * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
>   */
>  
> -#define _XOPEN_SOURCE	600
>  #define _GNU_SOURCE
>  
>  #include <inttypes.h>
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 10:21:34 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 10: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.xensource.com>)
	id 1RaPU6-0005J1-5G; Tue, 13 Dec 2011 10:21:18 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <sandr8@gmail.com>) id 1RaPU4-0005Iw-7q
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 10:21:16 +0000
X-Env-Sender: sandr8@gmail.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1323771620!7034358!1
X-Originating-IP: [209.85.213.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32697 invoked from network); 13 Dec 2011 10:20:22 -0000
Received: from mail-yw0-f43.google.com (HELO mail-yw0-f43.google.com)
	(209.85.213.43)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 10:20:22 -0000
Received: by yhr49 with SMTP id 49so6314213yhr.30
	for <xen-devel@lists.xensource.com>;
	Tue, 13 Dec 2011 02:20:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:reply-to:in-reply-to:references:from:date:message-id
	:subject:to:cc:content-type:content-transfer-encoding;
	bh=RE/gv+8Y9zHjWI6Yo5Cg/936IAP7uCJiAndz+uB66R8=;
	b=w4ZdHgDLAVv5sfkMNd3BUj+/ZspAW2c14eqXufZVnlxrgOfmNfNDzjp6b8GEAJJA7q
	r6zxHo5kdR3cBH7xga3VQEA1w0vmPwQVpZuTZZx1NDQ+4N/1tJUhVIjXf5YndjUt7kkZ
	tp7+wxkYy0n++Kr+EvKNH9wytyXEQgnZC/e+g=
Received: by 10.236.161.103 with SMTP id v67mr2446979yhk.87.1323771617267;
	Tue, 13 Dec 2011 02:20:17 -0800 (PST)
MIME-Version: 1.0
Received: by 10.236.60.132 with HTTP; Tue, 13 Dec 2011 02:19:46 -0800 (PST)
In-Reply-To: <4EE71663.5040308@gmail.com>
References: <4EE675A8.3030609@niemail.de> <4EE71663.5040308@gmail.com>
From: Alessandro Salvatori <sandr8@gmail.com>
Date: Tue, 13 Dec 2011 02:19:46 -0800
Message-ID: <CAJeBh4sxdNTxM_oLFAuA6Mw75=LaYysrpS5b8NsZMbkf_swNVw@mail.gmail.com>
To: George Shuklin <george.shuklin@gmail.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] a ton of kernel issues
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: sandr8@gmail.com
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

George,

> pv_ops is still have some issues with memory limits, but any
> new kernel (3.0+) will boot normal and operates with very
> minor glitches. Older pv_ops (f.e. debian 2.6.32) have some
> more major issues.

what glitches should one expect with 3.0+, and having the choice,
would it be better to go with 3.1 or even 3.2?

thank you!
-Alessandro-
=A0Here i am, A young man,
=A0A crashing computer program,
=A0Here is a pen, write out my name...

(from: The Servant - Orchestra)



On Tue, Dec 13, 2011 at 01:09, George Shuklin <george.shuklin@gmail.com> wr=
ote:
> Use suse and Centos5 (not 6) kernels. They works right with xen better th=
en
> others. OpenSUSE release pretty offten, so they have at least 2.6.34, 2.6=
.37
> and 3.1. Or you can use old centos 2.6.18.
>
> All those kernels is '-xen', not vanilla. pv_ops is still have some issues
> with memory limits, but any new kernel (3.0+) will boot normal and operat=
es
> with very minor glitches. Older pv_ops (f.e. debian 2.6.32) have some more
> major issues.
>
>
> On 13.12.2011 01:44, Tim Evers wrote:
>>
>> Hi folks,
>>
>> please forgive me if I'm not 100% right on this list but I'm going mad
>> about the current xen development as far as the pv_ops kernel are
>> involved. I've been using Xen since 3.0 in various productive setups
>> without any serious problems for years now.
>>
>> And now, since the support for the "patched" distro-kernel like debian 5
>> run out I'm trying to setup a working xen+pv_ops kernel with regard to
>> cpu and ram hotplug and live migration. Nothing special I thought but
>> hell I'm totally lost: After testing two month now dozens of
>> combinations I was not able to find a single kernel / xen combination
>> which supports the abovementioned features. Some crash after hotplug on
>> a migrated domu, some crash right at the migration and some crash right
>> at the start if vcpu_avail> =A0vcpus.
>>
>> I've tested
>>
>> xen-4.0
>> xen-4.1
>>
>> debian 6 32 and 64 bit (2.6.32-x kernel)
>> ubuntu lucid 32 and 64 bit kernels including karmic, natty and even
>> oneric backports
>>
>> I've put some questions on the users mailinglist, wrote bug reports but
>> today after two month work on this I'm as stuck as one can get.
>>
>> Is it possible that there is not a single working xen+pv_ops setup out
>> there which matches my needs? I can't believe it.
>>
>> I appreciate _any_ hint!
>>
>> Regards
>>
>> Tim
>>
>> http://lists.xen.org/archives/html/xen-users/2011-11/msg00553.html
>> http://lists.xen.org/archives/html/xen-users/2011-11/msg00523.html
>> http://lists.xen.org/archives/html/xen-users/2011-11/msg00295.html
>> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/893177
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 10:21:34 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 10: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.xensource.com>)
	id 1RaPU6-0005J1-5G; Tue, 13 Dec 2011 10:21:18 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <sandr8@gmail.com>) id 1RaPU4-0005Iw-7q
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 10:21:16 +0000
X-Env-Sender: sandr8@gmail.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1323771620!7034358!1
X-Originating-IP: [209.85.213.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32697 invoked from network); 13 Dec 2011 10:20:22 -0000
Received: from mail-yw0-f43.google.com (HELO mail-yw0-f43.google.com)
	(209.85.213.43)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 10:20:22 -0000
Received: by yhr49 with SMTP id 49so6314213yhr.30
	for <xen-devel@lists.xensource.com>;
	Tue, 13 Dec 2011 02:20:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:reply-to:in-reply-to:references:from:date:message-id
	:subject:to:cc:content-type:content-transfer-encoding;
	bh=RE/gv+8Y9zHjWI6Yo5Cg/936IAP7uCJiAndz+uB66R8=;
	b=w4ZdHgDLAVv5sfkMNd3BUj+/ZspAW2c14eqXufZVnlxrgOfmNfNDzjp6b8GEAJJA7q
	r6zxHo5kdR3cBH7xga3VQEA1w0vmPwQVpZuTZZx1NDQ+4N/1tJUhVIjXf5YndjUt7kkZ
	tp7+wxkYy0n++Kr+EvKNH9wytyXEQgnZC/e+g=
Received: by 10.236.161.103 with SMTP id v67mr2446979yhk.87.1323771617267;
	Tue, 13 Dec 2011 02:20:17 -0800 (PST)
MIME-Version: 1.0
Received: by 10.236.60.132 with HTTP; Tue, 13 Dec 2011 02:19:46 -0800 (PST)
In-Reply-To: <4EE71663.5040308@gmail.com>
References: <4EE675A8.3030609@niemail.de> <4EE71663.5040308@gmail.com>
From: Alessandro Salvatori <sandr8@gmail.com>
Date: Tue, 13 Dec 2011 02:19:46 -0800
Message-ID: <CAJeBh4sxdNTxM_oLFAuA6Mw75=LaYysrpS5b8NsZMbkf_swNVw@mail.gmail.com>
To: George Shuklin <george.shuklin@gmail.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] a ton of kernel issues
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: sandr8@gmail.com
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

George,

> pv_ops is still have some issues with memory limits, but any
> new kernel (3.0+) will boot normal and operates with very
> minor glitches. Older pv_ops (f.e. debian 2.6.32) have some
> more major issues.

what glitches should one expect with 3.0+, and having the choice,
would it be better to go with 3.1 or even 3.2?

thank you!
-Alessandro-
=A0Here i am, A young man,
=A0A crashing computer program,
=A0Here is a pen, write out my name...

(from: The Servant - Orchestra)



On Tue, Dec 13, 2011 at 01:09, George Shuklin <george.shuklin@gmail.com> wr=
ote:
> Use suse and Centos5 (not 6) kernels. They works right with xen better th=
en
> others. OpenSUSE release pretty offten, so they have at least 2.6.34, 2.6=
.37
> and 3.1. Or you can use old centos 2.6.18.
>
> All those kernels is '-xen', not vanilla. pv_ops is still have some issues
> with memory limits, but any new kernel (3.0+) will boot normal and operat=
es
> with very minor glitches. Older pv_ops (f.e. debian 2.6.32) have some more
> major issues.
>
>
> On 13.12.2011 01:44, Tim Evers wrote:
>>
>> Hi folks,
>>
>> please forgive me if I'm not 100% right on this list but I'm going mad
>> about the current xen development as far as the pv_ops kernel are
>> involved. I've been using Xen since 3.0 in various productive setups
>> without any serious problems for years now.
>>
>> And now, since the support for the "patched" distro-kernel like debian 5
>> run out I'm trying to setup a working xen+pv_ops kernel with regard to
>> cpu and ram hotplug and live migration. Nothing special I thought but
>> hell I'm totally lost: After testing two month now dozens of
>> combinations I was not able to find a single kernel / xen combination
>> which supports the abovementioned features. Some crash after hotplug on
>> a migrated domu, some crash right at the migration and some crash right
>> at the start if vcpu_avail> =A0vcpus.
>>
>> I've tested
>>
>> xen-4.0
>> xen-4.1
>>
>> debian 6 32 and 64 bit (2.6.32-x kernel)
>> ubuntu lucid 32 and 64 bit kernels including karmic, natty and even
>> oneric backports
>>
>> I've put some questions on the users mailinglist, wrote bug reports but
>> today after two month work on this I'm as stuck as one can get.
>>
>> Is it possible that there is not a single working xen+pv_ops setup out
>> there which matches my needs? I can't believe it.
>>
>> I appreciate _any_ hint!
>>
>> Regards
>>
>> Tim
>>
>> http://lists.xen.org/archives/html/xen-users/2011-11/msg00553.html
>> http://lists.xen.org/archives/html/xen-users/2011-11/msg00523.html
>> http://lists.xen.org/archives/html/xen-users/2011-11/msg00295.html
>> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/893177
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 10:36:09 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 10: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.xensource.com>)
	id 1RaPi0-0005cJ-Hc; Tue, 13 Dec 2011 10:35:40 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RaPhy-0005cE-CG
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 10:35:38 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1323772483!7747596!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=UPPERCASE_25_50
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21280 invoked from network); 13 Dec 2011 10:34:44 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-10.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 13 Dec 2011 10:34:44 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 13 Dec 2011 10:34:43 +0000
Message-Id: <4EE7384F0200007800067373@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 13 Dec 2011 10:34:39 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartC4EB602F.0__="
Subject: [Xen-devel] [PATCH] stubdom: allow to build with older tool chain
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__PartC4EB602F.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

GNU make prior to 3.81 doesn't support $(realpath ...). This fixes a
regression introduced in 23368:0f670f5146c8 (the option tested via
cc-option-add got interpreted as the argument of the -I compiler
option, as its intended argument was blank, and hence the compiler was
falsely considered to support *any* option in the pciutils sub-tree).

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/Config.mk
+++ b/Config.mk
@@ -4,6 +4,9 @@ ifeq ($(filter /%,$(XEN_ROOT)),)
 $(error XEN_ROOT must be absolute)
 endif
=20
+# fallback for older make
+realpath =3D $(wildcard $(foreach file,$(1),$(shell cd -P $(dir $(file)) =
&& echo "$$PWD/$(notdir $(file))")))
+
 -include $(XEN_ROOT)/.config
=20
 # A debug build of Xen and tools?
--- a/stubdom/Makefile
+++ b/stubdom/Makefile
@@ -158,7 +158,7 @@ $(LIBPCI_STAMPFILE): pciutils-$(XEN_TARG
 	  chmod u+w lib/config.h && \
 	  echo '#define PCILIB_VERSION "$(LIBPCI_VERSION)"' >> lib/config.h=
 && \
 	  ln -sf ../../libpci.config.mak lib/config.mk && \
-	  $(CROSS_MAKE) CC=3D"$(CC) $(TARGET_CPPFLAGS) $(TARGET_CFLAGS) =
-I$(realpath $(MINI_OS)/include)" lib/libpci.a && \
+	  $(CROSS_MAKE) CC=3D"$(CC) $(TARGET_CPPFLAGS) $(TARGET_CFLAGS) =
-I$(call realpath,$(MINI_OS)/include)" lib/libpci.a && \
 	  $(INSTALL_DATA) lib/libpci.a $(CROSS_PREFIX)/$(GNU_TARGET_ARCH)-x=
en-elf/lib/ && \
 	  $(INSTALL_DIR) $(CROSS_PREFIX)/$(GNU_TARGET_ARCH)-xen-elf/include=
/pci && \
 	  $(INSTALL_DATA) lib/config.h lib/header.h lib/pci.h lib/types.h =
$(CROSS_PREFIX)/$(GNU_TARGET_ARCH)-xen-elf/include/pci/ \




--=__PartC4EB602F.0__=
Content-Type: text/plain; name="stubdom-realpath-old-make.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="stubdom-realpath-old-make.patch"

stubdom: allow to build with older tool chain=0A=0AGNU make prior to 3.81 =
doesn't support $(realpath ...). This fixes a=0Aregression introduced in =
23368:0f670f5146c8 (the option tested via=0Acc-option-add got interpreted =
as the argument of the -I compiler=0Aoption, as its intended argument was =
blank, and hence the compiler was=0Afalsely considered to support *any* =
option in the pciutils sub-tree).=0A=0ASigned-off-by: Jan Beulich =
<jbeulich@suse.com>=0A=0A--- a/Config.mk=0A+++ b/Config.mk=0A@@ -4,6 +4,9 =
@@ ifeq ($(filter /%,$(XEN_ROOT)),)=0A $(error XEN_ROOT must be =
absolute)=0A endif=0A =0A+# fallback for older make=0A+realpath =3D =
$(wildcard $(foreach file,$(1),$(shell cd -P $(dir $(file)) && echo =
"$$PWD/$(notdir $(file))")))=0A+=0A -include $(XEN_ROOT)/.config=0A =0A # =
A debug build of Xen and tools?=0A--- a/stubdom/Makefile=0A+++ b/stubdom/Ma=
kefile=0A@@ -158,7 +158,7 @@ $(LIBPCI_STAMPFILE): pciutils-$(XEN_TARG=0A 	=
  chmod u+w lib/config.h && \=0A 	  echo '#define PCILIB_VERSION =
"$(LIBPCI_VERSION)"' >> lib/config.h && \=0A 	  ln -sf ../../libpci.confi=
g.mak lib/config.mk && \=0A-	  $(CROSS_MAKE) CC=3D"$(CC) $(TARGET_CPPFLA=
GS) $(TARGET_CFLAGS) -I$(realpath $(MINI_OS)/include)" lib/libpci.a && =
\=0A+	  $(CROSS_MAKE) CC=3D"$(CC) $(TARGET_CPPFLAGS) $(TARGET_CFLAGS) =
-I$(call realpath,$(MINI_OS)/include)" lib/libpci.a && \=0A 	  =
$(INSTALL_DATA) lib/libpci.a $(CROSS_PREFIX)/$(GNU_TARGET_ARCH)-xen-elf/lib=
/ && \=0A 	  $(INSTALL_DIR) $(CROSS_PREFIX)/$(GNU_TARGET_ARCH)-xen-elf=
/include/pci && \=0A 	  $(INSTALL_DATA) lib/config.h lib/header.h =
lib/pci.h lib/types.h $(CROSS_PREFIX)/$(GNU_TARGET_ARCH)-xen-elf/include/pc=
i/ \=0A
--=__PartC4EB602F.0__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--=__PartC4EB602F.0__=--


From xen-devel-bounces@lists.xensource.com Tue Dec 13 10:36:09 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 10: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.xensource.com>)
	id 1RaPi0-0005cJ-Hc; Tue, 13 Dec 2011 10:35:40 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RaPhy-0005cE-CG
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 10:35:38 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1323772483!7747596!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=UPPERCASE_25_50
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21280 invoked from network); 13 Dec 2011 10:34:44 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-10.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 13 Dec 2011 10:34:44 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 13 Dec 2011 10:34:43 +0000
Message-Id: <4EE7384F0200007800067373@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 13 Dec 2011 10:34:39 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartC4EB602F.0__="
Subject: [Xen-devel] [PATCH] stubdom: allow to build with older tool chain
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__PartC4EB602F.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

GNU make prior to 3.81 doesn't support $(realpath ...). This fixes a
regression introduced in 23368:0f670f5146c8 (the option tested via
cc-option-add got interpreted as the argument of the -I compiler
option, as its intended argument was blank, and hence the compiler was
falsely considered to support *any* option in the pciutils sub-tree).

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/Config.mk
+++ b/Config.mk
@@ -4,6 +4,9 @@ ifeq ($(filter /%,$(XEN_ROOT)),)
 $(error XEN_ROOT must be absolute)
 endif
=20
+# fallback for older make
+realpath =3D $(wildcard $(foreach file,$(1),$(shell cd -P $(dir $(file)) =
&& echo "$$PWD/$(notdir $(file))")))
+
 -include $(XEN_ROOT)/.config
=20
 # A debug build of Xen and tools?
--- a/stubdom/Makefile
+++ b/stubdom/Makefile
@@ -158,7 +158,7 @@ $(LIBPCI_STAMPFILE): pciutils-$(XEN_TARG
 	  chmod u+w lib/config.h && \
 	  echo '#define PCILIB_VERSION "$(LIBPCI_VERSION)"' >> lib/config.h=
 && \
 	  ln -sf ../../libpci.config.mak lib/config.mk && \
-	  $(CROSS_MAKE) CC=3D"$(CC) $(TARGET_CPPFLAGS) $(TARGET_CFLAGS) =
-I$(realpath $(MINI_OS)/include)" lib/libpci.a && \
+	  $(CROSS_MAKE) CC=3D"$(CC) $(TARGET_CPPFLAGS) $(TARGET_CFLAGS) =
-I$(call realpath,$(MINI_OS)/include)" lib/libpci.a && \
 	  $(INSTALL_DATA) lib/libpci.a $(CROSS_PREFIX)/$(GNU_TARGET_ARCH)-x=
en-elf/lib/ && \
 	  $(INSTALL_DIR) $(CROSS_PREFIX)/$(GNU_TARGET_ARCH)-xen-elf/include=
/pci && \
 	  $(INSTALL_DATA) lib/config.h lib/header.h lib/pci.h lib/types.h =
$(CROSS_PREFIX)/$(GNU_TARGET_ARCH)-xen-elf/include/pci/ \




--=__PartC4EB602F.0__=
Content-Type: text/plain; name="stubdom-realpath-old-make.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="stubdom-realpath-old-make.patch"

stubdom: allow to build with older tool chain=0A=0AGNU make prior to 3.81 =
doesn't support $(realpath ...). This fixes a=0Aregression introduced in =
23368:0f670f5146c8 (the option tested via=0Acc-option-add got interpreted =
as the argument of the -I compiler=0Aoption, as its intended argument was =
blank, and hence the compiler was=0Afalsely considered to support *any* =
option in the pciutils sub-tree).=0A=0ASigned-off-by: Jan Beulich =
<jbeulich@suse.com>=0A=0A--- a/Config.mk=0A+++ b/Config.mk=0A@@ -4,6 +4,9 =
@@ ifeq ($(filter /%,$(XEN_ROOT)),)=0A $(error XEN_ROOT must be =
absolute)=0A endif=0A =0A+# fallback for older make=0A+realpath =3D =
$(wildcard $(foreach file,$(1),$(shell cd -P $(dir $(file)) && echo =
"$$PWD/$(notdir $(file))")))=0A+=0A -include $(XEN_ROOT)/.config=0A =0A # =
A debug build of Xen and tools?=0A--- a/stubdom/Makefile=0A+++ b/stubdom/Ma=
kefile=0A@@ -158,7 +158,7 @@ $(LIBPCI_STAMPFILE): pciutils-$(XEN_TARG=0A 	=
  chmod u+w lib/config.h && \=0A 	  echo '#define PCILIB_VERSION =
"$(LIBPCI_VERSION)"' >> lib/config.h && \=0A 	  ln -sf ../../libpci.confi=
g.mak lib/config.mk && \=0A-	  $(CROSS_MAKE) CC=3D"$(CC) $(TARGET_CPPFLA=
GS) $(TARGET_CFLAGS) -I$(realpath $(MINI_OS)/include)" lib/libpci.a && =
\=0A+	  $(CROSS_MAKE) CC=3D"$(CC) $(TARGET_CPPFLAGS) $(TARGET_CFLAGS) =
-I$(call realpath,$(MINI_OS)/include)" lib/libpci.a && \=0A 	  =
$(INSTALL_DATA) lib/libpci.a $(CROSS_PREFIX)/$(GNU_TARGET_ARCH)-xen-elf/lib=
/ && \=0A 	  $(INSTALL_DIR) $(CROSS_PREFIX)/$(GNU_TARGET_ARCH)-xen-elf=
/include/pci && \=0A 	  $(INSTALL_DATA) lib/config.h lib/header.h =
lib/pci.h lib/types.h $(CROSS_PREFIX)/$(GNU_TARGET_ARCH)-xen-elf/include/pc=
i/ \=0A
--=__PartC4EB602F.0__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--=__PartC4EB602F.0__=--


From xen-devel-bounces@lists.xensource.com Tue Dec 13 10:37:28 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 10:37:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaPjM-0005fT-1T; Tue, 13 Dec 2011 10:37:04 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <george.shuklin@gmail.com>) id 1RaPjL-0005fC-6t
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 10:37:03 +0000
X-Env-Sender: george.shuklin@gmail.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1323772568!5345322!1
X-Originating-IP: [209.85.214.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23183 invoked from network); 13 Dec 2011 10:36:08 -0000
Received: from mail-bw0-f43.google.com (HELO mail-bw0-f43.google.com)
	(209.85.214.43)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 10:36:08 -0000
Received: by bkbzs2 with SMTP id zs2so21512513bkb.30
	for <xen-devel@lists.xensource.com>;
	Tue, 13 Dec 2011 02:36:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=message-id:date:from:user-agent:mime-version:to:cc:subject
	:references:in-reply-to:content-type:content-transfer-encoding;
	bh=56TugDOIYo0rCf90QEAf+ZLl0sk9Hnq0mRI2enMebZc=;
	b=AgCMZcfVWPKkUyDKnsOz8EzDR+YWk/6BiQBvz4pdL0wRUDgZO+DTxRiusm+VN6lWLr
	f+EFtXR1w+QJVJpn0zD+v5awsyrQy+PLBy07zHvtka7evF6WaHW7RD9AnmFet+V7pkXX
	vNwkICTLNmXUWP3E5T2YNJGZJuYZy7SX/wSzs=
Received: by 10.205.112.6 with SMTP id eq6mr12834518bkc.16.1323772567682;
	Tue, 13 Dec 2011 02:36:07 -0800 (PST)
Received: from [192.168.40.44] (officecvt.selectel.ru. [188.93.16.50])
	by mx.google.com with ESMTPS id w3sm39729287bkq.3.2011.12.13.02.36.05
	(version=SSLv3 cipher=OTHER); Tue, 13 Dec 2011 02:36:06 -0800 (PST)
Message-ID: <4EE72A94.6040904@gmail.com>
Date: Tue, 13 Dec 2011 14:36:04 +0400
From: George Shuklin <george.shuklin@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:9.0) Gecko/20111209 Thunderbird/9.0
MIME-Version: 1.0
To: sandr8@gmail.com
References: <4EE675A8.3030609@niemail.de> <4EE71663.5040308@gmail.com>
	<CAJeBh4sxdNTxM_oLFAuA6Mw75=LaYysrpS5b8NsZMbkf_swNVw@mail.gmail.com>
In-Reply-To: <CAJeBh4sxdNTxM_oLFAuA6Mw75=LaYysrpS5b8NsZMbkf_swNVw@mail.gmail.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] a ton of kernel issues
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 13.12.2011 14:19, Alessandro Salvatori wrote:
>
>> pv_ops is still have some issues with memory limits, but any
>> new kernel (3.0+) will boot normal and operates with very
>> minor glitches. Older pv_ops (f.e. debian 2.6.32) have some
>> more major issues.
> what glitches should one expect with 3.0+, and having the choice,
> would it be better to go with 3.1 or even 3.2?
>
>
Right now I know about two of them:
When you set up memory for virtual machine using xenballon, value in 
dom0 differ from value in domU. The issue is that -xen kernels 'hide' 
some memory in 'used' memory, and pv-ops just reducing TotalMem to value 
without that memory. Practically that means if you set up memory for 
domain to 2GiB client will saw only 1.95GiB and so on.

The second issue is lack of support of 'pre-inflated balloon', means you 
can not set up memory-static-max to 2GiB, target to 1GiB and do 'memory 
grow' from 1 G to 2 G latter without VM reboot. -xen kernels allow this 
(up to memory-static-max limit).



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 10:37:28 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 10:37:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaPjM-0005fT-1T; Tue, 13 Dec 2011 10:37:04 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <george.shuklin@gmail.com>) id 1RaPjL-0005fC-6t
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 10:37:03 +0000
X-Env-Sender: george.shuklin@gmail.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1323772568!5345322!1
X-Originating-IP: [209.85.214.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23183 invoked from network); 13 Dec 2011 10:36:08 -0000
Received: from mail-bw0-f43.google.com (HELO mail-bw0-f43.google.com)
	(209.85.214.43)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 10:36:08 -0000
Received: by bkbzs2 with SMTP id zs2so21512513bkb.30
	for <xen-devel@lists.xensource.com>;
	Tue, 13 Dec 2011 02:36:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=message-id:date:from:user-agent:mime-version:to:cc:subject
	:references:in-reply-to:content-type:content-transfer-encoding;
	bh=56TugDOIYo0rCf90QEAf+ZLl0sk9Hnq0mRI2enMebZc=;
	b=AgCMZcfVWPKkUyDKnsOz8EzDR+YWk/6BiQBvz4pdL0wRUDgZO+DTxRiusm+VN6lWLr
	f+EFtXR1w+QJVJpn0zD+v5awsyrQy+PLBy07zHvtka7evF6WaHW7RD9AnmFet+V7pkXX
	vNwkICTLNmXUWP3E5T2YNJGZJuYZy7SX/wSzs=
Received: by 10.205.112.6 with SMTP id eq6mr12834518bkc.16.1323772567682;
	Tue, 13 Dec 2011 02:36:07 -0800 (PST)
Received: from [192.168.40.44] (officecvt.selectel.ru. [188.93.16.50])
	by mx.google.com with ESMTPS id w3sm39729287bkq.3.2011.12.13.02.36.05
	(version=SSLv3 cipher=OTHER); Tue, 13 Dec 2011 02:36:06 -0800 (PST)
Message-ID: <4EE72A94.6040904@gmail.com>
Date: Tue, 13 Dec 2011 14:36:04 +0400
From: George Shuklin <george.shuklin@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:9.0) Gecko/20111209 Thunderbird/9.0
MIME-Version: 1.0
To: sandr8@gmail.com
References: <4EE675A8.3030609@niemail.de> <4EE71663.5040308@gmail.com>
	<CAJeBh4sxdNTxM_oLFAuA6Mw75=LaYysrpS5b8NsZMbkf_swNVw@mail.gmail.com>
In-Reply-To: <CAJeBh4sxdNTxM_oLFAuA6Mw75=LaYysrpS5b8NsZMbkf_swNVw@mail.gmail.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] a ton of kernel issues
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 13.12.2011 14:19, Alessandro Salvatori wrote:
>
>> pv_ops is still have some issues with memory limits, but any
>> new kernel (3.0+) will boot normal and operates with very
>> minor glitches. Older pv_ops (f.e. debian 2.6.32) have some
>> more major issues.
> what glitches should one expect with 3.0+, and having the choice,
> would it be better to go with 3.1 or even 3.2?
>
>
Right now I know about two of them:
When you set up memory for virtual machine using xenballon, value in 
dom0 differ from value in domU. The issue is that -xen kernels 'hide' 
some memory in 'used' memory, and pv-ops just reducing TotalMem to value 
without that memory. Practically that means if you set up memory for 
domain to 2GiB client will saw only 1.95GiB and so on.

The second issue is lack of support of 'pre-inflated balloon', means you 
can not set up memory-static-max to 2GiB, target to 1GiB and do 'memory 
grow' from 1 G to 2 G latter without VM reboot. -xen kernels allow this 
(up to memory-static-max limit).



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 10:37:38 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 10:37:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaPjW-0005gZ-EY; Tue, 13 Dec 2011 10:37:14 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RaPjV-0005fi-ER
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 10:37:13 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1323772578!7040186!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTI1NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25759 invoked from network); 13 Dec 2011 10:36:19 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 10:36:19 -0000
X-IronPort-AV: E=Sophos;i="4.71,344,1320624000"; 
   d="scan'208";a="9435732"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Dec 2011 10:36:17 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 13 Dec 2011 10:36:17 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 13 Dec 2011 10:36:16 +0000
In-Reply-To: <1323769464.20077.262.camel@zakaz.uk.xensource.com>
References: <osstest-10481-mainreport@xen.org>
	<1323769464.20077.262.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323772577.20077.271.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: [Xen-devel] [PATCH] libxl: do not leak qemu saved state on restore
 (Was: Re: [xen-unstable test] 10481: regressions - FAIL)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2011-12-13 at 09:44 +0000, Ian Campbell wrote:
> 
> >  test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
> >  test-i386-i386-win           16 leak-check/check             fail   never pass
> >  test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
> >  test-amd64-i386-win          16 leak-check/check             fail   never pass
> 
> These all leaked a load of /var/lib/xen/qemu-resume.N. This should be
> quick & easy to fix, I'll have a look. 

These happen to all be xend failures but the only reason xl doesn't have
this is that those tests all fail at the guest-stop stage and never get
as far as the migration test. Here is the fix for the xl version, fixing
the xend side seems less trivial and I don't propose to dig into it.

Ian.

8<--------------------------------------------------

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1323772303 0
# Node ID 9ea12474c6dcd75bbbc7a5c62a2b96de902ccb83
# Parent  88df802b4905d7e34032eacf1942b70c76d150a4
libxl: do not leak qemu saved state on restore

In particular do not leak /var/lib/xen/qemu-resume.<domid>.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 88df802b4905 -r 9ea12474c6dc tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Mon Dec 12 17:43:55 2011 +0000
+++ b/tools/libxl/libxl_create.c	Tue Dec 13 10:31:43 2011 +0000
@@ -622,7 +622,7 @@ static int do_domain_create(libxl__gc *g
             == LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN) {
             libxl__qmp_initializations(ctx, domid);
         }
-        ret = libxl__confirm_device_model_startup(gc, dm_starting);
+        ret = libxl__confirm_device_model_startup(gc, dm_info, dm_starting);
         if (ret < 0) {
             LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
                        "device model did not start: %d", ret);
diff -r 88df802b4905 -r 9ea12474c6dc tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Mon Dec 12 17:43:55 2011 +0000
+++ b/tools/libxl/libxl_dm.c	Tue Dec 13 10:31:43 2011 +0000
@@ -753,7 +753,8 @@ retry_transaction:
         ret = ERROR_FAIL;
         goto out_free;
     }
-    if (libxl__confirm_device_model_startup(gc, dm_starting) < 0) {
+    if (libxl__confirm_device_model_startup(gc, &xenpv_dm_info,
+                                            dm_starting) < 0) {
         ret = ERROR_FAIL;
         goto out_free;
     }
@@ -894,14 +895,26 @@ out:
 
 
 int libxl__confirm_device_model_startup(libxl__gc *gc,
-                                       libxl__spawner_starting *starting)
+                                libxl_device_model_info *dm_info,
+                                libxl__spawner_starting *starting)
 {
+    libxl_ctx *ctx = libxl__gc_owner(gc);
     char *path;
     int domid = starting->domid;
+    int ret, ret2;
     path = libxl__sprintf(gc, "/local/domain/0/device-model/%d/state", domid);
-    return libxl__spawn_confirm_offspring_startup(gc,
+    ret = libxl__spawn_confirm_offspring_startup(gc,
                                      LIBXL_DEVICE_MODEL_START_TIMEOUT,
                                      "Device Model", path, "running", starting);
+    if (dm_info->saved_state) {
+        ret2 = unlink(dm_info->saved_state);
+        if (ret2) LIBXL__LOG_ERRNO(ctx, XTL_ERROR,
+                                   "failed to remove device-model state %s\n",
+                                   dm_info->saved_state);
+        /* Do not clobber spawn_confirm error code with unlink error code. */
+        if (!ret) ret = ret2;
+    }
+    return ret;
 }
 
 int libxl__destroy_device_model(libxl__gc *gc, uint32_t domid)
diff -r 88df802b4905 -r 9ea12474c6dc tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Mon Dec 12 17:43:55 2011 +0000
+++ b/tools/libxl/libxl_internal.h	Tue Dec 13 10:31:43 2011 +0000
@@ -419,6 +419,7 @@ _hidden int libxl__need_xenpv_qemu(libxl
    * return pass *starting_r (which will be non-0) to
    * libxl__confirm_device_model_startup or libxl__detach_device_model. */
 _hidden int libxl__confirm_device_model_startup(libxl__gc *gc,
+                              libxl_device_model_info *dm_info,
                               libxl__spawner_starting *starting);
 _hidden int libxl__detach_device_model(libxl__gc *gc, libxl__spawner_starting *starting);
 _hidden int libxl__wait_for_device_model(libxl__gc *gc,



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 10:37:38 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 10:37:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaPjW-0005gZ-EY; Tue, 13 Dec 2011 10:37:14 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RaPjV-0005fi-ER
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 10:37:13 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1323772578!7040186!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTI1NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25759 invoked from network); 13 Dec 2011 10:36:19 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 10:36:19 -0000
X-IronPort-AV: E=Sophos;i="4.71,344,1320624000"; 
   d="scan'208";a="9435732"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Dec 2011 10:36:17 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 13 Dec 2011 10:36:17 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 13 Dec 2011 10:36:16 +0000
In-Reply-To: <1323769464.20077.262.camel@zakaz.uk.xensource.com>
References: <osstest-10481-mainreport@xen.org>
	<1323769464.20077.262.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323772577.20077.271.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: [Xen-devel] [PATCH] libxl: do not leak qemu saved state on restore
 (Was: Re: [xen-unstable test] 10481: regressions - FAIL)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2011-12-13 at 09:44 +0000, Ian Campbell wrote:
> 
> >  test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
> >  test-i386-i386-win           16 leak-check/check             fail   never pass
> >  test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
> >  test-amd64-i386-win          16 leak-check/check             fail   never pass
> 
> These all leaked a load of /var/lib/xen/qemu-resume.N. This should be
> quick & easy to fix, I'll have a look. 

These happen to all be xend failures but the only reason xl doesn't have
this is that those tests all fail at the guest-stop stage and never get
as far as the migration test. Here is the fix for the xl version, fixing
the xend side seems less trivial and I don't propose to dig into it.

Ian.

8<--------------------------------------------------

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1323772303 0
# Node ID 9ea12474c6dcd75bbbc7a5c62a2b96de902ccb83
# Parent  88df802b4905d7e34032eacf1942b70c76d150a4
libxl: do not leak qemu saved state on restore

In particular do not leak /var/lib/xen/qemu-resume.<domid>.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 88df802b4905 -r 9ea12474c6dc tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Mon Dec 12 17:43:55 2011 +0000
+++ b/tools/libxl/libxl_create.c	Tue Dec 13 10:31:43 2011 +0000
@@ -622,7 +622,7 @@ static int do_domain_create(libxl__gc *g
             == LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN) {
             libxl__qmp_initializations(ctx, domid);
         }
-        ret = libxl__confirm_device_model_startup(gc, dm_starting);
+        ret = libxl__confirm_device_model_startup(gc, dm_info, dm_starting);
         if (ret < 0) {
             LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
                        "device model did not start: %d", ret);
diff -r 88df802b4905 -r 9ea12474c6dc tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Mon Dec 12 17:43:55 2011 +0000
+++ b/tools/libxl/libxl_dm.c	Tue Dec 13 10:31:43 2011 +0000
@@ -753,7 +753,8 @@ retry_transaction:
         ret = ERROR_FAIL;
         goto out_free;
     }
-    if (libxl__confirm_device_model_startup(gc, dm_starting) < 0) {
+    if (libxl__confirm_device_model_startup(gc, &xenpv_dm_info,
+                                            dm_starting) < 0) {
         ret = ERROR_FAIL;
         goto out_free;
     }
@@ -894,14 +895,26 @@ out:
 
 
 int libxl__confirm_device_model_startup(libxl__gc *gc,
-                                       libxl__spawner_starting *starting)
+                                libxl_device_model_info *dm_info,
+                                libxl__spawner_starting *starting)
 {
+    libxl_ctx *ctx = libxl__gc_owner(gc);
     char *path;
     int domid = starting->domid;
+    int ret, ret2;
     path = libxl__sprintf(gc, "/local/domain/0/device-model/%d/state", domid);
-    return libxl__spawn_confirm_offspring_startup(gc,
+    ret = libxl__spawn_confirm_offspring_startup(gc,
                                      LIBXL_DEVICE_MODEL_START_TIMEOUT,
                                      "Device Model", path, "running", starting);
+    if (dm_info->saved_state) {
+        ret2 = unlink(dm_info->saved_state);
+        if (ret2) LIBXL__LOG_ERRNO(ctx, XTL_ERROR,
+                                   "failed to remove device-model state %s\n",
+                                   dm_info->saved_state);
+        /* Do not clobber spawn_confirm error code with unlink error code. */
+        if (!ret) ret = ret2;
+    }
+    return ret;
 }
 
 int libxl__destroy_device_model(libxl__gc *gc, uint32_t domid)
diff -r 88df802b4905 -r 9ea12474c6dc tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Mon Dec 12 17:43:55 2011 +0000
+++ b/tools/libxl/libxl_internal.h	Tue Dec 13 10:31:43 2011 +0000
@@ -419,6 +419,7 @@ _hidden int libxl__need_xenpv_qemu(libxl
    * return pass *starting_r (which will be non-0) to
    * libxl__confirm_device_model_startup or libxl__detach_device_model. */
 _hidden int libxl__confirm_device_model_startup(libxl__gc *gc,
+                              libxl_device_model_info *dm_info,
                               libxl__spawner_starting *starting);
 _hidden int libxl__detach_device_model(libxl__gc *gc, libxl__spawner_starting *starting);
 _hidden int libxl__wait_for_device_model(libxl__gc *gc,



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 10:39:03 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 10:39:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaPky-0005qu-V3; Tue, 13 Dec 2011 10:38:44 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <hn_nemati1985@yahoo.com>) id 1RaPkx-0005qA-7B
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 10:38:43 +0000
X-Env-Sender: hn_nemati1985@yahoo.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1323772668!7147537!1
X-Originating-IP: [98.139.213.154]
X-SpamReason: No, hits=2.9 required=7.0 tests=FROM_HAS_ULINE_NUMS,
	HTML_90_100,HTML_MESSAGE,HTML_SHORT_LENGTH,ML_RADAR_SPEW_LINKS_12,
	ML_RADAR_SPEW_LINKS_14,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18843 invoked from network); 13 Dec 2011 10:37:48 -0000
Received: from nm9-vm0.bullet.mail.bf1.yahoo.com (HELO
	nm9-vm0.bullet.mail.bf1.yahoo.com) (98.139.213.154)
	by server-10.tower-216.messagelabs.com with SMTP;
	13 Dec 2011 10:37:48 -0000
Received: from [98.139.212.150] by nm9.bullet.mail.bf1.yahoo.com with NNFMP;
	13 Dec 2011 10:37:48 -0000
Received: from [98.139.212.202] by tm7.bullet.mail.bf1.yahoo.com with NNFMP;
	13 Dec 2011 10:37:48 -0000
Received: from [127.0.0.1] by omp1011.mail.bf1.yahoo.com with NNFMP;
	13 Dec 2011 10:37:48 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 48429.41848.bm@omp1011.mail.bf1.yahoo.com
Received: (qmail 51073 invoked by uid 60001); 13 Dec 2011 10:37:47 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024;
	t=1323772667; bh=UYNdKyik/tWczdVtVtD54Tbu+oqXSXjncVmk/2+WPjc=;
	h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:Cc:MIME-Version:Content-Type;
	b=BaqGS3vgeg3M4/9J3rCOJsiLWHVsJ57vErYLiW0H6/pf/VcbAPLX6e2eg0IR1lECU15DY7PK1g5rvZv/PL6hqcERxNau93qXsPRLqKT0MB384ir0LKSR+x/5nHKnUuRykUJ4na0U4lZFSi1mavgUoOckRny8kwfnCrmFJ3RxaSs=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com;
	h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:Cc:MIME-Version:Content-Type;
	b=vRFzLMBOgwOwDKZydnD3WVToUCLqqfZ2+LaQ65xVBxCDxoYalg6tdLVudRdu36cQvLiNxD5wnOjcHkBTmFRKkA+CIzJOE1JhRaryL5rs6r7mW20Gqs6Mw5jbb79y8WZp9rtjWWhv3CayFKiq2WASns5EfJhqaWoDrCktVWIoSPM=;
X-YMail-OSG: X8jFaHgVM1kEyCTRPPqcIBpBKrhSV2OYWMEBG6YXSgkS3Lh
	a5gam7chIFAn1bErRsDEWLinWf.KGbA82EBksnbK0SRH5ZJIkCPFXKB525Yy
	LwAQkKQV72lYyWHv9MVaP6E0SQx_bN8lKhExkL_yNzccH2dBjhQvWwzkzr69
	HMt97seUe2gEj75Amv4ZnDXgl.xG1R5.ytQaLA0rDt0PswpY0QOSehqBtFjC
	o4jnEc8pjtmp7Iz8ORgoC_QfhkUyBGYKSPPzXiLBhkK_fLB0CZhbehIrn1rm
	PwPwmvr4V_NO4mfNKE6n.a87iVIrfQvepRZ6fLnZQMmu6BCI_PYQY1quLG_p
	8TGg2FJtHiJKz4NenbOzr8Y9_5rkaJ8rrjbg0Cy9TRgm4hCxzoxg.eKuIqEq
	eum1uSkwC7.3F9L.dGiNkwkHvSEWJuN2mKvAd
Received: from [76.73.45.34] by web160904.mail.bf1.yahoo.com via HTTP;
	Tue, 13 Dec 2011 02:37:47 PST
X-Mailer: YahooMailClassic/15.0.4 YahooMailWebService/0.8.115.331698
Message-ID: <1323772667.41630.YahooMailClassic@web160904.mail.bf1.yahoo.com>
Date: Tue, 13 Dec 2011 02:37:47 -0800 (PST)
From: jack nemati <hn_nemati1985@yahoo.com>
To: Tim Deegan <tim@xen.org>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Xen shadow page table
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============4857670439615173482=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============4857670439615173482==
Content-Type: multipart/alternative; boundary="-517069186-1016382116-1323772667=:41630"

---517069186-1016382116-1323772667=:41630
Content-Type: text/plain; charset=us-ascii

Thank you. 

---517069186-1016382116-1323772667=:41630
Content-Type: text/html; charset=us-ascii

<table cellspacing="0" cellpadding="0" border="0" ><tr><td valign="top" style="font: inherit;"><div id="yiv1273281733">Thank you. <br></div></td></tr></table>
---517069186-1016382116-1323772667=:41630--


--===============4857670439615173482==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============4857670439615173482==--


From xen-devel-bounces@lists.xensource.com Tue Dec 13 10:39:03 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 10:39:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaPky-0005qu-V3; Tue, 13 Dec 2011 10:38:44 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <hn_nemati1985@yahoo.com>) id 1RaPkx-0005qA-7B
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 10:38:43 +0000
X-Env-Sender: hn_nemati1985@yahoo.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1323772668!7147537!1
X-Originating-IP: [98.139.213.154]
X-SpamReason: No, hits=2.9 required=7.0 tests=FROM_HAS_ULINE_NUMS,
	HTML_90_100,HTML_MESSAGE,HTML_SHORT_LENGTH,ML_RADAR_SPEW_LINKS_12,
	ML_RADAR_SPEW_LINKS_14,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18843 invoked from network); 13 Dec 2011 10:37:48 -0000
Received: from nm9-vm0.bullet.mail.bf1.yahoo.com (HELO
	nm9-vm0.bullet.mail.bf1.yahoo.com) (98.139.213.154)
	by server-10.tower-216.messagelabs.com with SMTP;
	13 Dec 2011 10:37:48 -0000
Received: from [98.139.212.150] by nm9.bullet.mail.bf1.yahoo.com with NNFMP;
	13 Dec 2011 10:37:48 -0000
Received: from [98.139.212.202] by tm7.bullet.mail.bf1.yahoo.com with NNFMP;
	13 Dec 2011 10:37:48 -0000
Received: from [127.0.0.1] by omp1011.mail.bf1.yahoo.com with NNFMP;
	13 Dec 2011 10:37:48 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 48429.41848.bm@omp1011.mail.bf1.yahoo.com
Received: (qmail 51073 invoked by uid 60001); 13 Dec 2011 10:37:47 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024;
	t=1323772667; bh=UYNdKyik/tWczdVtVtD54Tbu+oqXSXjncVmk/2+WPjc=;
	h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:Cc:MIME-Version:Content-Type;
	b=BaqGS3vgeg3M4/9J3rCOJsiLWHVsJ57vErYLiW0H6/pf/VcbAPLX6e2eg0IR1lECU15DY7PK1g5rvZv/PL6hqcERxNau93qXsPRLqKT0MB384ir0LKSR+x/5nHKnUuRykUJ4na0U4lZFSi1mavgUoOckRny8kwfnCrmFJ3RxaSs=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com;
	h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:Cc:MIME-Version:Content-Type;
	b=vRFzLMBOgwOwDKZydnD3WVToUCLqqfZ2+LaQ65xVBxCDxoYalg6tdLVudRdu36cQvLiNxD5wnOjcHkBTmFRKkA+CIzJOE1JhRaryL5rs6r7mW20Gqs6Mw5jbb79y8WZp9rtjWWhv3CayFKiq2WASns5EfJhqaWoDrCktVWIoSPM=;
X-YMail-OSG: X8jFaHgVM1kEyCTRPPqcIBpBKrhSV2OYWMEBG6YXSgkS3Lh
	a5gam7chIFAn1bErRsDEWLinWf.KGbA82EBksnbK0SRH5ZJIkCPFXKB525Yy
	LwAQkKQV72lYyWHv9MVaP6E0SQx_bN8lKhExkL_yNzccH2dBjhQvWwzkzr69
	HMt97seUe2gEj75Amv4ZnDXgl.xG1R5.ytQaLA0rDt0PswpY0QOSehqBtFjC
	o4jnEc8pjtmp7Iz8ORgoC_QfhkUyBGYKSPPzXiLBhkK_fLB0CZhbehIrn1rm
	PwPwmvr4V_NO4mfNKE6n.a87iVIrfQvepRZ6fLnZQMmu6BCI_PYQY1quLG_p
	8TGg2FJtHiJKz4NenbOzr8Y9_5rkaJ8rrjbg0Cy9TRgm4hCxzoxg.eKuIqEq
	eum1uSkwC7.3F9L.dGiNkwkHvSEWJuN2mKvAd
Received: from [76.73.45.34] by web160904.mail.bf1.yahoo.com via HTTP;
	Tue, 13 Dec 2011 02:37:47 PST
X-Mailer: YahooMailClassic/15.0.4 YahooMailWebService/0.8.115.331698
Message-ID: <1323772667.41630.YahooMailClassic@web160904.mail.bf1.yahoo.com>
Date: Tue, 13 Dec 2011 02:37:47 -0800 (PST)
From: jack nemati <hn_nemati1985@yahoo.com>
To: Tim Deegan <tim@xen.org>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Xen shadow page table
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============4857670439615173482=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============4857670439615173482==
Content-Type: multipart/alternative; boundary="-517069186-1016382116-1323772667=:41630"

---517069186-1016382116-1323772667=:41630
Content-Type: text/plain; charset=us-ascii

Thank you. 

---517069186-1016382116-1323772667=:41630
Content-Type: text/html; charset=us-ascii

<table cellspacing="0" cellpadding="0" border="0" ><tr><td valign="top" style="font: inherit;"><div id="yiv1273281733">Thank you. <br></div></td></tr></table>
---517069186-1016382116-1323772667=:41630--


--===============4857670439615173482==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============4857670439615173482==--


From xen-devel-bounces@lists.xensource.com Tue Dec 13 10:39:21 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 10:39:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaPlM-0005uE-C4; Tue, 13 Dec 2011 10:39:08 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <lersek@redhat.com>) id 1RaPlL-0005tB-Cd
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 10:39:07 +0000
X-Env-Sender: lersek@redhat.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1323772692!7147634!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDYxNzY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20543 invoked from network); 13 Dec 2011 10:38:13 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-10.tower-216.messagelabs.com with SMTP;
	13 Dec 2011 10:38:13 -0000
Received: from int-mx01.intmail.prod.int.phx2.redhat.com
	(int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id pBDAc66P014879
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 13 Dec 2011 05:38:06 -0500
Received: from [10.34.1.169] (dhcp-1-169.brq.redhat.com [10.34.1.169])
	by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP
	id pBDAc4EX015333; Tue, 13 Dec 2011 05:38:05 -0500
Message-ID: <4EE72B7C.7030006@redhat.com>
Date: Tue, 13 Dec 2011 11:39:56 +0100
From: Laszlo Ersek <lersek@redhat.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.24) Gecko/20111108 Fedora/3.1.16-1.fc14
	Lightning/1.0b3pre Mnenhy/0.8.4 Thunderbird/3.1.16
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <7697ee23b08b8eaca9ae.1323768649@loki.upc.es>
	<1323770544.20077.268.camel@zakaz.uk.xensource.com>
In-Reply-To: <1323770544.20077.268.camel@zakaz.uk.xensource.com>
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.11
Cc: Roger Pau Monne <roger.pau@entel.upc.edu>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] xenpaging: remove XOPEN_SOURCE
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 12/13/11 11:02, Ian Campbell wrote:
> On Tue, 2011-12-13 at 09:30 +0000, Roger Pau Monne wrote:
>> # HG changeset patch
>> # User Roger Pau Monne<roger.pau@entel.upc.edu>
>> # Date 1323768129 -3600
>> # Node ID 7697ee23b08b8eaca9aee4f6b79cf550a490bef7
>> # Parent  8a84f53376862427f254a017cb52c928dbdd3d32
>> xenpaging: remove XOPEN_SOURCE
>>
>> The XOPEN_SOURCE define was breaking the compilation under NetBSD.
>
> How?

Indeed. Both the commit that added it [1] [2] and this patch provide 
very little useful info in their respective messages. It's interesting 
because it could point out a SUSv3 incompatibility in in NetBSD.

>> I've removed it becasue it is not necessary (at least under NetBSD).
>> If it is necessary for Linux, we can add a ifdef conditional to remove
>> this only under NetBSD.
>
> Removing it seems to not break Linux, at least for me.

The stuff made visible by _GNU_SOURCE (with glibc) includes everything 
_XOPEN_SOURCE makes visible [3]. [4] introduced it because of asprintf().

Laszlo

[1] 
http://old-list-archives.xen.org/archives/html/xen-devel/2010-08/msg01110.html
[2] http://xenbits.xensource.com/hg/xen-unstable.hg/rev/22023
[3] 
http://www.gnu.org/software/libc/manual/html_node/Feature-Test-Macros.html#index-g_t_005fGNU_005fSOURCE-51
[4] http://xenbits.xensource.com/hg/xen-unstable.hg/rev/24223


>
>> Signed-off-by: Roger Pau Monne<roger.pau@entel.upc.edu>
>
> Acked-by: Ian Campbell<ian.campbell@citrix.com>
>>
>> diff -r 8a84f5337686 -r 7697ee23b08b tools/xenpaging/xenpaging.c
>> --- a/tools/xenpaging/xenpaging.c	Tue Dec 13 09:49:55 2011 +0100
>> +++ b/tools/xenpaging/xenpaging.c	Tue Dec 13 10:22:09 2011 +0100
>> @@ -18,7 +18,6 @@
>>    * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
>>    */
>>
>> -#define _XOPEN_SOURCE	600
>>   #define _GNU_SOURCE
>>
>>   #include<inttypes.h>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 10:39:21 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 10:39:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaPlM-0005uE-C4; Tue, 13 Dec 2011 10:39:08 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <lersek@redhat.com>) id 1RaPlL-0005tB-Cd
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 10:39:07 +0000
X-Env-Sender: lersek@redhat.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1323772692!7147634!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDYxNzY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20543 invoked from network); 13 Dec 2011 10:38:13 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-10.tower-216.messagelabs.com with SMTP;
	13 Dec 2011 10:38:13 -0000
Received: from int-mx01.intmail.prod.int.phx2.redhat.com
	(int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id pBDAc66P014879
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 13 Dec 2011 05:38:06 -0500
Received: from [10.34.1.169] (dhcp-1-169.brq.redhat.com [10.34.1.169])
	by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP
	id pBDAc4EX015333; Tue, 13 Dec 2011 05:38:05 -0500
Message-ID: <4EE72B7C.7030006@redhat.com>
Date: Tue, 13 Dec 2011 11:39:56 +0100
From: Laszlo Ersek <lersek@redhat.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.24) Gecko/20111108 Fedora/3.1.16-1.fc14
	Lightning/1.0b3pre Mnenhy/0.8.4 Thunderbird/3.1.16
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <7697ee23b08b8eaca9ae.1323768649@loki.upc.es>
	<1323770544.20077.268.camel@zakaz.uk.xensource.com>
In-Reply-To: <1323770544.20077.268.camel@zakaz.uk.xensource.com>
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.11
Cc: Roger Pau Monne <roger.pau@entel.upc.edu>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] xenpaging: remove XOPEN_SOURCE
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 12/13/11 11:02, Ian Campbell wrote:
> On Tue, 2011-12-13 at 09:30 +0000, Roger Pau Monne wrote:
>> # HG changeset patch
>> # User Roger Pau Monne<roger.pau@entel.upc.edu>
>> # Date 1323768129 -3600
>> # Node ID 7697ee23b08b8eaca9aee4f6b79cf550a490bef7
>> # Parent  8a84f53376862427f254a017cb52c928dbdd3d32
>> xenpaging: remove XOPEN_SOURCE
>>
>> The XOPEN_SOURCE define was breaking the compilation under NetBSD.
>
> How?

Indeed. Both the commit that added it [1] [2] and this patch provide 
very little useful info in their respective messages. It's interesting 
because it could point out a SUSv3 incompatibility in in NetBSD.

>> I've removed it becasue it is not necessary (at least under NetBSD).
>> If it is necessary for Linux, we can add a ifdef conditional to remove
>> this only under NetBSD.
>
> Removing it seems to not break Linux, at least for me.

The stuff made visible by _GNU_SOURCE (with glibc) includes everything 
_XOPEN_SOURCE makes visible [3]. [4] introduced it because of asprintf().

Laszlo

[1] 
http://old-list-archives.xen.org/archives/html/xen-devel/2010-08/msg01110.html
[2] http://xenbits.xensource.com/hg/xen-unstable.hg/rev/22023
[3] 
http://www.gnu.org/software/libc/manual/html_node/Feature-Test-Macros.html#index-g_t_005fGNU_005fSOURCE-51
[4] http://xenbits.xensource.com/hg/xen-unstable.hg/rev/24223


>
>> Signed-off-by: Roger Pau Monne<roger.pau@entel.upc.edu>
>
> Acked-by: Ian Campbell<ian.campbell@citrix.com>
>>
>> diff -r 8a84f5337686 -r 7697ee23b08b tools/xenpaging/xenpaging.c
>> --- a/tools/xenpaging/xenpaging.c	Tue Dec 13 09:49:55 2011 +0100
>> +++ b/tools/xenpaging/xenpaging.c	Tue Dec 13 10:22:09 2011 +0100
>> @@ -18,7 +18,6 @@
>>    * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
>>    */
>>
>> -#define _XOPEN_SOURCE	600
>>   #define _GNU_SOURCE
>>
>>   #include<inttypes.h>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 11:25:28 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 11:25:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaQTo-0006xO-18; Tue, 13 Dec 2011 11:25:04 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RaQTm-0006xD-50
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 11:25:02 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1323775446!7651251!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTI1NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27559 invoked from network); 13 Dec 2011 11:24:06 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 11:24:06 -0000
X-IronPort-AV: E=Sophos;i="4.71,344,1320624000"; 
   d="scan'208";a="9437255"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Dec 2011 11:24:06 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 13 Dec 2011 11:24:06 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RaQSr-00060Q-PA; Tue, 13 Dec 2011 11:24:05 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RaQSr-0002E8-NF;
	Tue, 13 Dec 2011 11:24:05 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20199.13781.707303.400465@mariner.uk.xensource.com>
Date: Tue, 13 Dec 2011 11:24:05 +0000
To: Roger Pau =?iso-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
In-Reply-To: <CAPLaKK4qK1sZJ_d-ivjmfG8biABvgrxP9JdjCMfJex4iXoP7Xw@mail.gmail.com>
References: <patchbomb.1322752087@loki.upc.es>
	<20198.16898.814613.705263@mariner.uk.xensource.com>
	<CAPLaKK4qK1sZJ_d-ivjmfG8biABvgrxP9JdjCMfJex4iXoP7Xw@mail.gmail.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 00 of 11 v3] libxl: add support for hotplug
 script calling from libxl
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Roger Pau Monn=E9 writes ("Re: [Xen-devel] [PATCH 00 of 11 v3] libxl: add s=
upport for hotplug script calling from libxl"):
> 2011/12/12 Ian Jackson <Ian.Jackson@eu.citrix.com>:
> > FYI this has now got to the top of my list. =A0I hope to give it some
> > serious review time tomorrow. =A0In the meantime, if you have any final
> > tweaks, feel free to send an updated version.
> =

> I will try to post an updated version tomorrow morning, that applies
> to tip without rejections. I also have another smaller series pending,
> the one about libxl not being able to destroy a domain correctly under
> NetBSD. I think it will be good to merge the two series, since they
> are quite related (the destroy issue is related to libxl not removing
> frontend entries before attempting to destroy the devices).

Sure, thanks.  And sorry about the huge conflicts you're probably
seeing...

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 11:25:28 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 11:25:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaQTo-0006xO-18; Tue, 13 Dec 2011 11:25:04 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RaQTm-0006xD-50
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 11:25:02 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1323775446!7651251!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTI1NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27559 invoked from network); 13 Dec 2011 11:24:06 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 11:24:06 -0000
X-IronPort-AV: E=Sophos;i="4.71,344,1320624000"; 
   d="scan'208";a="9437255"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Dec 2011 11:24:06 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 13 Dec 2011 11:24:06 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RaQSr-00060Q-PA; Tue, 13 Dec 2011 11:24:05 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RaQSr-0002E8-NF;
	Tue, 13 Dec 2011 11:24:05 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20199.13781.707303.400465@mariner.uk.xensource.com>
Date: Tue, 13 Dec 2011 11:24:05 +0000
To: Roger Pau =?iso-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
In-Reply-To: <CAPLaKK4qK1sZJ_d-ivjmfG8biABvgrxP9JdjCMfJex4iXoP7Xw@mail.gmail.com>
References: <patchbomb.1322752087@loki.upc.es>
	<20198.16898.814613.705263@mariner.uk.xensource.com>
	<CAPLaKK4qK1sZJ_d-ivjmfG8biABvgrxP9JdjCMfJex4iXoP7Xw@mail.gmail.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 00 of 11 v3] libxl: add support for hotplug
 script calling from libxl
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Roger Pau Monn=E9 writes ("Re: [Xen-devel] [PATCH 00 of 11 v3] libxl: add s=
upport for hotplug script calling from libxl"):
> 2011/12/12 Ian Jackson <Ian.Jackson@eu.citrix.com>:
> > FYI this has now got to the top of my list. =A0I hope to give it some
> > serious review time tomorrow. =A0In the meantime, if you have any final
> > tweaks, feel free to send an updated version.
> =

> I will try to post an updated version tomorrow morning, that applies
> to tip without rejections. I also have another smaller series pending,
> the one about libxl not being able to destroy a domain correctly under
> NetBSD. I think it will be good to merge the two series, since they
> are quite related (the destroy issue is related to libxl not removing
> frontend entries before attempting to destroy the devices).

Sure, thanks.  And sorry about the huge conflicts you're probably
seeing...

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 11:31:08 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 11: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.xensource.com>)
	id 1RaQZK-0007Ct-RC; Tue, 13 Dec 2011 11:30:46 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RaQZJ-0007Cn-Tz
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 11:30:46 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1323775742!57078975!1
X-Originating-IP: [209.85.214.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP,UPPERCASE_25_50
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3020 invoked from network); 13 Dec 2011 11:29:03 -0000
Received: from mail-bw0-f43.google.com (HELO mail-bw0-f43.google.com)
	(209.85.214.43)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 11:29:03 -0000
Received: by bkbzs2 with SMTP id zs2so21698226bkb.30
	for <xen-devel@lists.xensource.com>;
	Tue, 13 Dec 2011 03:29:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=/j/x0vgngb2XaUYSsyME5vjzay8UtDtN+EysNCwJwQ4=;
	b=FmFFXz4K5jSNqRuDjepLwNZZJKRpUmwaq7TE1tmCTRTWJlkNxbe2xMR7xusRysXKSu
	mKrIJS5LMKwRaIoA1OQmL53NXOHmvGoMfat3HetHEG0t4i7flZoizHHMrVtSWqcDwuiL
	oUrJfU6uJllPq0/DHihVgMd56z6dCjxVW17Is=
Received: by 10.205.128.132 with SMTP id he4mr12803823bkc.123.1323775791296;
	Tue, 13 Dec 2011 03:29:51 -0800 (PST)
Received: from [192.168.1.3] (host81-152-17-11.range81-152.btcentralplus.com.
	[81.152.17.11])
	by mx.google.com with ESMTPS id z7sm40083941bka.1.2011.12.13.03.29.50
	(version=SSLv3 cipher=OTHER); Tue, 13 Dec 2011 03:29:50 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Tue, 13 Dec 2011 11:29:45 +0000
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Message-ID: <CB0CE7A9.35B83%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH] stubdom: allow to build with older tool chain
Thread-Index: Acy5ioOEBn0QwpFY6kiq9xUznuy6Gw==
In-Reply-To: <4EE7384F0200007800067373@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH] stubdom: allow to build with older tool
	chain
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 13/12/2011 10:34, "Jan Beulich" <JBeulich@suse.com> wrote:

> GNU make prior to 3.81 doesn't support $(realpath ...). This fixes a
> regression introduced in 23368:0f670f5146c8 (the option tested via
> cc-option-add got interpreted as the argument of the -I compiler
> option, as its intended argument was blank, and hence the compiler was
> falsely considered to support *any* option in the pciutils sub-tree).
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Keir Fraser <keir@xen.org>

> --- a/Config.mk
> +++ b/Config.mk
> @@ -4,6 +4,9 @@ ifeq ($(filter /%,$(XEN_ROOT)),)
>  $(error XEN_ROOT must be absolute)
>  endif
>  
> +# fallback for older make
> +realpath = $(wildcard $(foreach file,$(1),$(shell cd -P $(dir $(file)) &&
> echo "$$PWD/$(notdir $(file))")))
> +
>  -include $(XEN_ROOT)/.config
>  
>  # A debug build of Xen and tools?
> --- a/stubdom/Makefile
> +++ b/stubdom/Makefile
> @@ -158,7 +158,7 @@ $(LIBPCI_STAMPFILE): pciutils-$(XEN_TARG
>  chmod u+w lib/config.h && \
>  echo '#define PCILIB_VERSION "$(LIBPCI_VERSION)"' >> lib/config.h && \
>  ln -sf ../../libpci.config.mak lib/config.mk && \
> -   $(CROSS_MAKE) CC="$(CC) $(TARGET_CPPFLAGS) $(TARGET_CFLAGS) -I$(realpath
> $(MINI_OS)/include)" lib/libpci.a && \
> +   $(CROSS_MAKE) CC="$(CC) $(TARGET_CPPFLAGS) $(TARGET_CFLAGS) -I$(call
> realpath,$(MINI_OS)/include)" lib/libpci.a && \
>  $(INSTALL_DATA) lib/libpci.a $(CROSS_PREFIX)/$(GNU_TARGET_ARCH)-xen-elf/lib/
> && \
>  $(INSTALL_DIR) $(CROSS_PREFIX)/$(GNU_TARGET_ARCH)-xen-elf/include/pci && \
>  $(INSTALL_DATA) lib/config.h lib/header.h lib/pci.h lib/types.h
> $(CROSS_PREFIX)/$(GNU_TARGET_ARCH)-xen-elf/include/pci/ \
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 11:31:08 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 11: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.xensource.com>)
	id 1RaQZK-0007Ct-RC; Tue, 13 Dec 2011 11:30:46 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RaQZJ-0007Cn-Tz
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 11:30:46 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1323775742!57078975!1
X-Originating-IP: [209.85.214.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP,UPPERCASE_25_50
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3020 invoked from network); 13 Dec 2011 11:29:03 -0000
Received: from mail-bw0-f43.google.com (HELO mail-bw0-f43.google.com)
	(209.85.214.43)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 11:29:03 -0000
Received: by bkbzs2 with SMTP id zs2so21698226bkb.30
	for <xen-devel@lists.xensource.com>;
	Tue, 13 Dec 2011 03:29:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=/j/x0vgngb2XaUYSsyME5vjzay8UtDtN+EysNCwJwQ4=;
	b=FmFFXz4K5jSNqRuDjepLwNZZJKRpUmwaq7TE1tmCTRTWJlkNxbe2xMR7xusRysXKSu
	mKrIJS5LMKwRaIoA1OQmL53NXOHmvGoMfat3HetHEG0t4i7flZoizHHMrVtSWqcDwuiL
	oUrJfU6uJllPq0/DHihVgMd56z6dCjxVW17Is=
Received: by 10.205.128.132 with SMTP id he4mr12803823bkc.123.1323775791296;
	Tue, 13 Dec 2011 03:29:51 -0800 (PST)
Received: from [192.168.1.3] (host81-152-17-11.range81-152.btcentralplus.com.
	[81.152.17.11])
	by mx.google.com with ESMTPS id z7sm40083941bka.1.2011.12.13.03.29.50
	(version=SSLv3 cipher=OTHER); Tue, 13 Dec 2011 03:29:50 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Tue, 13 Dec 2011 11:29:45 +0000
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Message-ID: <CB0CE7A9.35B83%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH] stubdom: allow to build with older tool chain
Thread-Index: Acy5ioOEBn0QwpFY6kiq9xUznuy6Gw==
In-Reply-To: <4EE7384F0200007800067373@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH] stubdom: allow to build with older tool
	chain
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 13/12/2011 10:34, "Jan Beulich" <JBeulich@suse.com> wrote:

> GNU make prior to 3.81 doesn't support $(realpath ...). This fixes a
> regression introduced in 23368:0f670f5146c8 (the option tested via
> cc-option-add got interpreted as the argument of the -I compiler
> option, as its intended argument was blank, and hence the compiler was
> falsely considered to support *any* option in the pciutils sub-tree).
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Keir Fraser <keir@xen.org>

> --- a/Config.mk
> +++ b/Config.mk
> @@ -4,6 +4,9 @@ ifeq ($(filter /%,$(XEN_ROOT)),)
>  $(error XEN_ROOT must be absolute)
>  endif
>  
> +# fallback for older make
> +realpath = $(wildcard $(foreach file,$(1),$(shell cd -P $(dir $(file)) &&
> echo "$$PWD/$(notdir $(file))")))
> +
>  -include $(XEN_ROOT)/.config
>  
>  # A debug build of Xen and tools?
> --- a/stubdom/Makefile
> +++ b/stubdom/Makefile
> @@ -158,7 +158,7 @@ $(LIBPCI_STAMPFILE): pciutils-$(XEN_TARG
>  chmod u+w lib/config.h && \
>  echo '#define PCILIB_VERSION "$(LIBPCI_VERSION)"' >> lib/config.h && \
>  ln -sf ../../libpci.config.mak lib/config.mk && \
> -   $(CROSS_MAKE) CC="$(CC) $(TARGET_CPPFLAGS) $(TARGET_CFLAGS) -I$(realpath
> $(MINI_OS)/include)" lib/libpci.a && \
> +   $(CROSS_MAKE) CC="$(CC) $(TARGET_CPPFLAGS) $(TARGET_CFLAGS) -I$(call
> realpath,$(MINI_OS)/include)" lib/libpci.a && \
>  $(INSTALL_DATA) lib/libpci.a $(CROSS_PREFIX)/$(GNU_TARGET_ARCH)-xen-elf/lib/
> && \
>  $(INSTALL_DIR) $(CROSS_PREFIX)/$(GNU_TARGET_ARCH)-xen-elf/include/pci && \
>  $(INSTALL_DATA) lib/config.h lib/header.h lib/pci.h lib/types.h
> $(CROSS_PREFIX)/$(GNU_TARGET_ARCH)-xen-elf/include/pci/ \
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 11:35:24 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 11:35:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaQdU-0007Le-Gt; Tue, 13 Dec 2011 11:35:04 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RaQdS-0007LS-Pu
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 11:35:03 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1323776009!50402280!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTI1NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16675 invoked from network); 13 Dec 2011 11:33:29 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 11:33:29 -0000
X-IronPort-AV: E=Sophos;i="4.71,344,1320624000"; 
   d="scan'208";a="9437538"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Dec 2011 11:33:29 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 13 Dec 2011 11:33:27 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RaQbu-00065j-Lz; Tue, 13 Dec 2011 11:33:26 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RaQbu-0002ES-Jj;
	Tue, 13 Dec 2011 11:33:26 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20199.14342.599850.739029@mariner.uk.xensource.com>
Date: Tue, 13 Dec 2011 11:33:26 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1323769464.20077.262.camel@zakaz.uk.xensource.com>
References: <osstest-10481-mainreport@xen.org>
	<1323769464.20077.262.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [xen-unstable test] 10481: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("Re: [Xen-devel] [xen-unstable test] 10481: regressions - FAIL"):
> I think "xl trigger <dom> power" would be what is wanted here -- e.g.
> send an ACPI power event. It could be argued that xl shutdown could do
> this automatically?

libxl_domain_shutdown should do it automatically for HVM guests with
no PV drivers.

Ian.

> No active link message again but this time the guest says:
>         For info, please visit https://www.isc.org/software/dhcp/
>         
>         SIOCSIFADDR: No such device
>         eth0: ERROR while getting interface flags: No such device
>         eth0: ERROR while getting interface flags: No such device
>         Bind socket to interface: No such device
>         Failed to bring up eth0.
>         done.
>         Cleaning up temporary files....
> 
> If we could preserve a guest in that state and login it might prove
> informative. My guess would either be a missing/faulty VF driver or udev
> renaming things.

> >  test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
> >  test-i386-i386-win           16 leak-check/check             fail   never pass
> >  test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
> >  test-amd64-i386-win          16 leak-check/check             fail   never pass
> 
> These all leaked a load of /var/lib/xen/qemu-resume.N. This should be
> quick & easy to fix, I'll have a look.

These are all xend, of course...

> >  test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install fail in 10480 like 10474
> >  test-amd64-i386-xend-winxpsp3  7 windows-install      fail in 10480 like 10474
> >  test-amd64-i386-xl-win7-amd64  7 windows-install      fail in 10480 like 10474
> >  test-amd64-amd64-xl-win7-amd64  7 windows-install     fail in 10480 like 10474
> >  test-amd64-i386-win           7 windows-install       fail in 10480 like 10473
> 
> These don't appear to have failed per the grid at
> http://www.chiark.greenend.org.uk/~xensrcts/logs/10481/ ?
> 
> e.g. test-amd64-i386-xl-winxpsp3-vcpus1 appears to have failed at
> guest-stop instead (and indeed is also listed above in that capacity)

Perhaps the heading

> > Tests which did not succeed, but are not blocking,
> > including regressions (tests previously passed) regarded as allowable:

is slightly misleading, but it does say "fail in 10480".  Ie it passed
in 10481 but failed in 10480 which tested the same changeset.

> This appears to be reporting a failure in a previous run, part of the
> heisenbug detector? It might be nice to put those in a separate section
> or to include some indication as the the criteria being evaluated (e.g.
> are we waiting for a 3rd test to tiebreak?)

These are "not blocking" so they don't prevent a push.

I see we got a push in 10486...

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 11:35:24 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 11:35:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaQdU-0007Le-Gt; Tue, 13 Dec 2011 11:35:04 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RaQdS-0007LS-Pu
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 11:35:03 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1323776009!50402280!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTI1NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16675 invoked from network); 13 Dec 2011 11:33:29 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 11:33:29 -0000
X-IronPort-AV: E=Sophos;i="4.71,344,1320624000"; 
   d="scan'208";a="9437538"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Dec 2011 11:33:29 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 13 Dec 2011 11:33:27 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RaQbu-00065j-Lz; Tue, 13 Dec 2011 11:33:26 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RaQbu-0002ES-Jj;
	Tue, 13 Dec 2011 11:33:26 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20199.14342.599850.739029@mariner.uk.xensource.com>
Date: Tue, 13 Dec 2011 11:33:26 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1323769464.20077.262.camel@zakaz.uk.xensource.com>
References: <osstest-10481-mainreport@xen.org>
	<1323769464.20077.262.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [xen-unstable test] 10481: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("Re: [Xen-devel] [xen-unstable test] 10481: regressions - FAIL"):
> I think "xl trigger <dom> power" would be what is wanted here -- e.g.
> send an ACPI power event. It could be argued that xl shutdown could do
> this automatically?

libxl_domain_shutdown should do it automatically for HVM guests with
no PV drivers.

Ian.

> No active link message again but this time the guest says:
>         For info, please visit https://www.isc.org/software/dhcp/
>         
>         SIOCSIFADDR: No such device
>         eth0: ERROR while getting interface flags: No such device
>         eth0: ERROR while getting interface flags: No such device
>         Bind socket to interface: No such device
>         Failed to bring up eth0.
>         done.
>         Cleaning up temporary files....
> 
> If we could preserve a guest in that state and login it might prove
> informative. My guess would either be a missing/faulty VF driver or udev
> renaming things.

> >  test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
> >  test-i386-i386-win           16 leak-check/check             fail   never pass
> >  test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
> >  test-amd64-i386-win          16 leak-check/check             fail   never pass
> 
> These all leaked a load of /var/lib/xen/qemu-resume.N. This should be
> quick & easy to fix, I'll have a look.

These are all xend, of course...

> >  test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install fail in 10480 like 10474
> >  test-amd64-i386-xend-winxpsp3  7 windows-install      fail in 10480 like 10474
> >  test-amd64-i386-xl-win7-amd64  7 windows-install      fail in 10480 like 10474
> >  test-amd64-amd64-xl-win7-amd64  7 windows-install     fail in 10480 like 10474
> >  test-amd64-i386-win           7 windows-install       fail in 10480 like 10473
> 
> These don't appear to have failed per the grid at
> http://www.chiark.greenend.org.uk/~xensrcts/logs/10481/ ?
> 
> e.g. test-amd64-i386-xl-winxpsp3-vcpus1 appears to have failed at
> guest-stop instead (and indeed is also listed above in that capacity)

Perhaps the heading

> > Tests which did not succeed, but are not blocking,
> > including regressions (tests previously passed) regarded as allowable:

is slightly misleading, but it does say "fail in 10480".  Ie it passed
in 10481 but failed in 10480 which tested the same changeset.

> This appears to be reporting a failure in a previous run, part of the
> heisenbug detector? It might be nice to put those in a separate section
> or to include some indication as the the criteria being evaluated (e.g.
> are we waiting for a 3rd test to tiebreak?)

These are "not blocking" so they don't prevent a push.

I see we got a push in 10486...

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 11:46:25 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 11:46:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaQo0-0007dz-Ud; Tue, 13 Dec 2011 11:45:56 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RaQnz-0007du-H5
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 11:45:55 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1323776700!7275870!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16689 invoked from network); 13 Dec 2011 11:45:01 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-9.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 13 Dec 2011 11:45:01 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 13 Dec 2011 11:45:00 +0000
Message-Id: <4EE748C90200007800067408@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 13 Dec 2011 11:44:56 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part537CF7A8.0__="
Subject: [Xen-devel] [PATCH] linux-2.6.18/x86: don't build i8237.o
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__Part537CF7A8.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

This complements c/s 155:fbfa306ab465 ("Suppress all use of ISA DMA on
Xen") - the code is simply useless on Xen.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/arch/i386/kernel/Makefile
+++ b/arch/i386/kernel/Makefile
@@ -84,5 +84,5 @@ $(obj)/vsyscall-syms.o: $(src)/vsyscall.
 early_printk-y            +=3D ../../x86_64/kernel/early_printk.o
 k8-y                      +=3D ../../x86_64/kernel/k8.o
=20
-disabled-obj-$(CONFIG_XEN) :=3D i8259.o reboot.o smpboot.o
+disabled-obj-$(CONFIG_XEN) :=3D i8237.o i8259.o reboot.o smpboot.o
 %/head.o %/head.s: $(if $(CONFIG_XEN),EXTRA_AFLAGS,dummy) :=3D
--- a/arch/x86_64/kernel/Makefile
+++ b/arch/x86_64/kernel/Makefile
@@ -61,5 +61,5 @@ dmi_scan-y			+=3D ../../i386/kernel/dmi_=
sc
 time-$(CONFIG_XEN)		+=3D ../../i386/kernel/time.o
 pci-dma-$(CONFIG_XEN)		+=3D ../../i386/kernel/pci-dma.o
=20
-disabled-obj-$(CONFIG_XEN)	:=3D i8259.o reboot.o smpboot.o trampoline.=
o
+disabled-obj-$(CONFIG_XEN)	:=3D i8237.o i8259.o reboot.o smpboot.o =
trampoline.o
 %/head.o %/head.s: $(if $(CONFIG_XEN),EXTRA_AFLAGS,dummy) :=3D




--=__Part537CF7A8.0__=
Content-Type: text/plain; name="xen-x86-no-i8237.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="xen-x86-no-i8237.patch"

x86: don't build i8237.o=0A=0AThis complements c/s 155:fbfa306ab465 =
("Suppress all use of ISA DMA on=0AXen") - the code is simply useless on =
Xen.=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=0A=0A--- =
a/arch/i386/kernel/Makefile=0A+++ b/arch/i386/kernel/Makefile=0A@@ -84,5 =
+84,5 @@ $(obj)/vsyscall-syms.o: $(src)/vsyscall.=0A early_printk-y        =
    +=3D ../../x86_64/kernel/early_printk.o=0A k8-y                      =
+=3D ../../x86_64/kernel/k8.o=0A =0A-disabled-obj-$(CONFIG_XEN) :=3D =
i8259.o reboot.o smpboot.o=0A+disabled-obj-$(CONFIG_XEN) :=3D i8237.o =
i8259.o reboot.o smpboot.o=0A %/head.o %/head.s: $(if $(CONFIG_XEN),EXTRA_A=
FLAGS,dummy) :=3D=0A--- a/arch/x86_64/kernel/Makefile=0A+++ b/arch/x86_64/k=
ernel/Makefile=0A@@ -61,5 +61,5 @@ dmi_scan-y			+=3D =
../../i386/kernel/dmi_sc=0A time-$(CONFIG_XEN)		+=3D ../../i386/ker=
nel/time.o=0A pci-dma-$(CONFIG_XEN)		+=3D ../../i386/kernel/pci-=
dma.o=0A =0A-disabled-obj-$(CONFIG_XEN)	:=3D i8259.o reboot.o smpboot.o =
trampoline.o=0A+disabled-obj-$(CONFIG_XEN)	:=3D i8237.o i8259.o =
reboot.o smpboot.o trampoline.o=0A %/head.o %/head.s: $(if $(CONFIG_XEN),EX=
TRA_AFLAGS,dummy) :=3D=0A
--=__Part537CF7A8.0__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--=__Part537CF7A8.0__=--


From xen-devel-bounces@lists.xensource.com Tue Dec 13 11:46:25 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 11:46:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaQo0-0007dz-Ud; Tue, 13 Dec 2011 11:45:56 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RaQnz-0007du-H5
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 11:45:55 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1323776700!7275870!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16689 invoked from network); 13 Dec 2011 11:45:01 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-9.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 13 Dec 2011 11:45:01 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 13 Dec 2011 11:45:00 +0000
Message-Id: <4EE748C90200007800067408@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 13 Dec 2011 11:44:56 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part537CF7A8.0__="
Subject: [Xen-devel] [PATCH] linux-2.6.18/x86: don't build i8237.o
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__Part537CF7A8.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

This complements c/s 155:fbfa306ab465 ("Suppress all use of ISA DMA on
Xen") - the code is simply useless on Xen.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/arch/i386/kernel/Makefile
+++ b/arch/i386/kernel/Makefile
@@ -84,5 +84,5 @@ $(obj)/vsyscall-syms.o: $(src)/vsyscall.
 early_printk-y            +=3D ../../x86_64/kernel/early_printk.o
 k8-y                      +=3D ../../x86_64/kernel/k8.o
=20
-disabled-obj-$(CONFIG_XEN) :=3D i8259.o reboot.o smpboot.o
+disabled-obj-$(CONFIG_XEN) :=3D i8237.o i8259.o reboot.o smpboot.o
 %/head.o %/head.s: $(if $(CONFIG_XEN),EXTRA_AFLAGS,dummy) :=3D
--- a/arch/x86_64/kernel/Makefile
+++ b/arch/x86_64/kernel/Makefile
@@ -61,5 +61,5 @@ dmi_scan-y			+=3D ../../i386/kernel/dmi_=
sc
 time-$(CONFIG_XEN)		+=3D ../../i386/kernel/time.o
 pci-dma-$(CONFIG_XEN)		+=3D ../../i386/kernel/pci-dma.o
=20
-disabled-obj-$(CONFIG_XEN)	:=3D i8259.o reboot.o smpboot.o trampoline.=
o
+disabled-obj-$(CONFIG_XEN)	:=3D i8237.o i8259.o reboot.o smpboot.o =
trampoline.o
 %/head.o %/head.s: $(if $(CONFIG_XEN),EXTRA_AFLAGS,dummy) :=3D




--=__Part537CF7A8.0__=
Content-Type: text/plain; name="xen-x86-no-i8237.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="xen-x86-no-i8237.patch"

x86: don't build i8237.o=0A=0AThis complements c/s 155:fbfa306ab465 =
("Suppress all use of ISA DMA on=0AXen") - the code is simply useless on =
Xen.=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=0A=0A--- =
a/arch/i386/kernel/Makefile=0A+++ b/arch/i386/kernel/Makefile=0A@@ -84,5 =
+84,5 @@ $(obj)/vsyscall-syms.o: $(src)/vsyscall.=0A early_printk-y        =
    +=3D ../../x86_64/kernel/early_printk.o=0A k8-y                      =
+=3D ../../x86_64/kernel/k8.o=0A =0A-disabled-obj-$(CONFIG_XEN) :=3D =
i8259.o reboot.o smpboot.o=0A+disabled-obj-$(CONFIG_XEN) :=3D i8237.o =
i8259.o reboot.o smpboot.o=0A %/head.o %/head.s: $(if $(CONFIG_XEN),EXTRA_A=
FLAGS,dummy) :=3D=0A--- a/arch/x86_64/kernel/Makefile=0A+++ b/arch/x86_64/k=
ernel/Makefile=0A@@ -61,5 +61,5 @@ dmi_scan-y			+=3D =
../../i386/kernel/dmi_sc=0A time-$(CONFIG_XEN)		+=3D ../../i386/ker=
nel/time.o=0A pci-dma-$(CONFIG_XEN)		+=3D ../../i386/kernel/pci-=
dma.o=0A =0A-disabled-obj-$(CONFIG_XEN)	:=3D i8259.o reboot.o smpboot.o =
trampoline.o=0A+disabled-obj-$(CONFIG_XEN)	:=3D i8237.o i8259.o =
reboot.o smpboot.o trampoline.o=0A %/head.o %/head.s: $(if $(CONFIG_XEN),EX=
TRA_AFLAGS,dummy) :=3D=0A
--=__Part537CF7A8.0__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--=__Part537CF7A8.0__=--


From xen-devel-bounces@lists.xensource.com Tue Dec 13 11:55:07 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 11:55:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaQwY-0007oF-Vj; Tue, 13 Dec 2011 11:54:46 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RaQwY-0007o9-0u
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 11:54:46 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1323777230!7045831!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTI1NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3502 invoked from network); 13 Dec 2011 11:53:50 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 11:53:50 -0000
X-IronPort-AV: E=Sophos;i="4.71,344,1320624000"; 
   d="scan'208";a="9438014"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Dec 2011 11:53:34 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 13 Dec 2011 11:53:34 +0000
Date: Tue, 13 Dec 2011 11:55:15 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
In-Reply-To: <alpine.DEB.2.00.1112121527130.3517@kaball-desktop>
Message-ID: <alpine.DEB.2.00.1112131141170.3517@kaball-desktop>
References: <1323467645-24271-1-git-send-email-anthony.perard@citrix.com>
	<1323467645-24271-6-git-send-email-anthony.perard@citrix.com>
	<4EE3382D.80903@web.de>
	<alpine.DEB.2.00.1112121259180.3517@kaball-desktop>
	<4EE609BF.1070307@siemens.com>
	<alpine.DEB.2.00.1112121438410.3517@kaball-desktop>
	<4EE617BA.4030102@siemens.com>
	<alpine.DEB.2.00.1112121527130.3517@kaball-desktop>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Anthony Perard <anthony.perard@citrix.com>,
	Jan Kiszka <jan.kiszka@siemens.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	QEMU-devel <qemu-devel@nongnu.org>
Subject: [Xen-devel] early_savevm (was: [PATCH V2 5/5] vga-cirrus:
 Workaround during restore when using Xen.)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 12 Dec 2011, Stefano Stabellini wrote:
> > Really, I think this is something inherently incompatible with the
> > current memory API. If Xen has this unfixable special "requirement"
> > (it's rather a design issue IMHO), adjust the API and adapt all devices.
> > Hot-fixing only a single one this way is no good idea long term.
> 
> Fair enough.
> What about introducing a type of savevm state that is going to be
> restored before machine->init?
> This way we could save and restore our physmap and we could handle
> memory maps and allocations transparently.
> 

A bit more context to my suggestion:

- we open the save state file and check the magic number and the
version number before machine->init();

- we add a new set of entries to the save state file that contains
early_savevm functions: they are called before machine->init();

- after reaching the end of the early_savevm functions we stop parsing
the save state file and we call machine->init();

- after machine->init() is completed we continue parsing the save state
file as usual.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 11:55:07 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 11:55:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaQwY-0007oF-Vj; Tue, 13 Dec 2011 11:54:46 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RaQwY-0007o9-0u
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 11:54:46 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1323777230!7045831!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTI1NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3502 invoked from network); 13 Dec 2011 11:53:50 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 11:53:50 -0000
X-IronPort-AV: E=Sophos;i="4.71,344,1320624000"; 
   d="scan'208";a="9438014"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Dec 2011 11:53:34 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 13 Dec 2011 11:53:34 +0000
Date: Tue, 13 Dec 2011 11:55:15 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
In-Reply-To: <alpine.DEB.2.00.1112121527130.3517@kaball-desktop>
Message-ID: <alpine.DEB.2.00.1112131141170.3517@kaball-desktop>
References: <1323467645-24271-1-git-send-email-anthony.perard@citrix.com>
	<1323467645-24271-6-git-send-email-anthony.perard@citrix.com>
	<4EE3382D.80903@web.de>
	<alpine.DEB.2.00.1112121259180.3517@kaball-desktop>
	<4EE609BF.1070307@siemens.com>
	<alpine.DEB.2.00.1112121438410.3517@kaball-desktop>
	<4EE617BA.4030102@siemens.com>
	<alpine.DEB.2.00.1112121527130.3517@kaball-desktop>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Anthony Perard <anthony.perard@citrix.com>,
	Jan Kiszka <jan.kiszka@siemens.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	QEMU-devel <qemu-devel@nongnu.org>
Subject: [Xen-devel] early_savevm (was: [PATCH V2 5/5] vga-cirrus:
 Workaround during restore when using Xen.)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 12 Dec 2011, Stefano Stabellini wrote:
> > Really, I think this is something inherently incompatible with the
> > current memory API. If Xen has this unfixable special "requirement"
> > (it's rather a design issue IMHO), adjust the API and adapt all devices.
> > Hot-fixing only a single one this way is no good idea long term.
> 
> Fair enough.
> What about introducing a type of savevm state that is going to be
> restored before machine->init?
> This way we could save and restore our physmap and we could handle
> memory maps and allocations transparently.
> 

A bit more context to my suggestion:

- we open the save state file and check the magic number and the
version number before machine->init();

- we add a new set of entries to the save state file that contains
early_savevm functions: they are called before machine->init();

- after reaching the end of the early_savevm functions we stop parsing
the save state file and we call machine->init();

- after machine->init() is completed we continue parsing the save state
file as usual.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 12:09:43 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 12:09:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaRAd-0008D5-0X; Tue, 13 Dec 2011 12:09:19 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <svenvan.van@gmail.com>) id 1RaRAb-0008Cz-Hl
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 12:09:17 +0000
X-Env-Sender: svenvan.van@gmail.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1323778102!6515739!1
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5266 invoked from network); 13 Dec 2011 12:08:23 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 12:08:23 -0000
Received: by wgbds11 with SMTP id ds11so11684591wgb.24
	for <xen-devel@lists.xensource.com>;
	Tue, 13 Dec 2011 04:08:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=XSMarndbYz3bT60Ik/ZU7C+tfeBX9urLvdN+uSi+H4s=;
	b=E4u/1Z+W2luLoPRNX6HLGqTavtvjcC7rFScxBY2ZY8foBydulATK+zxlk49aTb31oo
	jYTlinW0iyi29uEvmpSlxv1eznYBb2GpPPzA4G7ZdRi7WD4c8HG2rd7snwh/RoMplTvK
	NXuuyujkVhxoP3DID9OMcEdyC9cU4KmPcs2cQ=
MIME-Version: 1.0
Received: by 10.227.197.10 with SMTP id ei10mr17053718wbb.11.1323778101255;
	Tue, 13 Dec 2011 04:08:21 -0800 (PST)
Received: by 10.223.76.15 with HTTP; Tue, 13 Dec 2011 04:08:21 -0800 (PST)
In-Reply-To: <20111212220013.GC12106@andromeda.dapyr.net>
References: <CAJmQyTik==F8PuR+j3SVRjxQQ_aVLjHeBZdboekD3iOVRR9Y0A@mail.gmail.com>
	<CAJmQyThnnRjvuHBzB-2P43FvHOu8=C8dkD_0yYGLFew3HnoAXg@mail.gmail.com>
	<20111212220013.GC12106@andromeda.dapyr.net>
Date: Tue, 13 Dec 2011 13:08:21 +0100
Message-ID: <CAJmQyTifE4Ms9iXSGAnTi0PfShTXjPUtwC0RmZ0rfTx78sQ+LA@mail.gmail.com>
From: svenvan svenvan <svenvan.van@gmail.com>
To: xen-devel@lists.xensource.com
Cc: konrad@darnok.org
Subject: Re: [Xen-devel] xen 4.0.1/w 2.6.32 swapper: page allocation failure
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============8613017439481575337=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============8613017439481575337==
Content-Type: multipart/alternative; boundary=0015174c1a927c9ded04b3f81b45

--0015174c1a927c9ded04b3f81b45
Content-Type: text/plain; charset=ISO-8859-1

2011/12/12 Konrad Rzeszutek Wilk <konrad@darnok.org>

> On Sun, Dec 11, 2011 at 06:21:52PM +0100, svenvan svenvan wrote:
> > 2011/12/5 svenvan svenvan <svenvan.van@gmail.com>
> > > > hi
> > > xen 4.0.1 w/2.6.32.41
> > >> > Last week dom0 experienced an hard crash and box need to be
> restarted
> > > manually (despite kernel.panic=20).
> > > Serial console was not setup, only netconsole.  No relevant entries
> > > through netconsole, but analyzing logs I see some crashes twenty
> minutes
> > > before fatal hang.
>
> >Browsing archive I found a reply from  Konrad Rzeszutek about something
> > similar:
> >
> http://old-list-archives.xen.org/archives/html/xen-devel/2011-09/msg00600.html
> >> Someone can confirm if it's the same issue or not?  Konrad maybe?
>


> You would get much more traction if you CC-ed me.
> Anyhow, no idea - 2.6.32-41 is a bit ancient and this thread does not
> seem to have relevant data (such as serial console for examples, or the
> "some crashes").
>


Thanks.  I have now setup serial console too
Adding more infos:  it happened in the night when there are some heavy
rsync from guests to a nfs server for backup purpose.

Just thinking about this one:

Page allocation failure with e1000
http://lists.debian.org/debian-backports/2011/01/msg00037.html
http://forums.gentoo.org/viewtopic-t-899896.html

and this one:
http://xen.1045712.n5.nabble.com/devel-next-2-6-39-SLUB-Unable-to-allocate-memory-on-node-1-gfp-0x20-tt4418288.html#a4422100


Maybe something related to e1000e driver?
Increasing /proc/sys/vm/min_free_kbytes can help?


xend-config.sxp relevant entries
(dom0-min-mem 1024)
(enable-dom0-ballooning no)

grub relevant entry
kernel          /boot/xen-4.0.1.gz dom0_mem=1024M max_cstate=1

Do I need to add  'mem=1GB'  too?
Thanks

--0015174c1a927c9ded04b3f81b45
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><div class=3D"gmail_quote">2011/12/12 Konrad Rzeszutek Wilk <span dir=
=3D"ltr">&lt;<a href=3D"mailto:konrad@darnok.org">konrad@darnok.org</a>&gt;=
</span><br><blockquote class=3D"gmail_quote" style=3D"margin:0pt 0pt 0pt 0.=
8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class=3D"HOEnZb"><div class=3D"h5">On Sun, Dec 11, 2011 at 06:21:52PM =
+0100, svenvan svenvan wrote:<br>
&gt; 2011/12/5 svenvan svenvan &lt;<a href=3D"mailto:svenvan.van@gmail.com"=
>svenvan.van@gmail.com</a>&gt;<br>
&gt;
&gt; &gt; hi<br>
&gt; &gt; xen 4.0.1 w/<a href=3D"http://2.6.32.41" target=3D"_blank">2.6.32=
.41</a><br>
&gt; &gt;&gt; &gt; Last week dom0 experienced an hard crash and box need to=
 be restarted<br>
&gt; &gt; manually (despite kernel.panic=3D20).<br>
&gt; &gt; Serial console was not setup, only netconsole. =A0No relevant ent=
ries<br>
&gt; &gt; through netconsole, but analyzing logs I see some crashes twenty =
minutes<br>
&gt; &gt; before fatal hang.<br></div></div></blockquote><div></div><blockq=
uote class=3D"gmail_quote" style=3D"margin:0pt 0pt 0pt 0.8ex;border-left:1p=
x solid rgb(204,204,204);padding-left:1ex"><div class=3D"HOEnZb"><div class=
=3D"h5">

&gt; &gt;Browsing archive I found a reply from =A0Konrad Rzeszutek about so=
mething<br>
&gt; similar:<br>
&gt; <a href=3D"http://old-list-archives.xen.org/archives/html/xen-devel/20=
11-09/msg00600.html" target=3D"_blank">http://old-list-archives.xen.org/arc=
hives/html/xen-devel/2011-09/msg00600.html</a><br>
&gt;&gt; Someone can confirm if it&#39;s the same issue or not? =A0Konrad m=
aybe?<br>

</div></div></blockquote><div>=A0</div><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padd=
ing-left:1ex">You would get much more traction if you CC-ed me.<br>

Anyhow, no idea - 2.6.32-41 is a bit ancient and this thread does not<br>
seem to have relevant data (such as serial console for examples, or the<br>
&quot;some crashes&quot;).<br>
</blockquote></div><br><br>Thanks.=A0 I have now setup serial console too<b=
r>Adding more infos:=A0 it happened in the night when there are some heavy =
rsync from guests to a nfs server for backup purpose.<br><br>Just thinking =
about this one:<br>
<br>Page allocation failure with e1000<br><a href=3D"http://lists.debian.or=
g/debian-backports/2011/01/msg00037.html">http://lists.debian.org/debian-ba=
ckports/2011/01/msg00037.html</a><br><a href=3D"http://forums.gentoo.org/vi=
ewtopic-t-899896.html">http://forums.gentoo.org/viewtopic-t-899896.html</a>=
<br>
<br>and this one:<br><a href=3D"http://xen.1045712.n5.nabble.com/devel-next=
-2-6-39-SLUB-Unable-to-allocate-memory-on-node-1-gfp-0x20-tt4418288.html#a4=
422100">http://xen.1045712.n5.nabble.com/devel-next-2-6-39-SLUB-Unable-to-a=
llocate-memory-on-node-1-gfp-0x20-tt4418288.html#a4422100</a><br>
<br><br>Maybe something related to e1000e driver?<br>Increasing /proc/sys/v=
m/min_free_kbytes can help? <br><br><br>xend-config.sxp relevant entries<br=
>(dom0-min-mem 1024)<br>(enable-dom0-ballooning no)<br><br>grub relevant en=
try<br>
kernel=A0=A0=A0=A0=A0=A0=A0=A0=A0 /boot/xen-4.0.1.gz dom0_mem=3D1024M max_c=
state=3D1<br><br>Do I need to add=A0 &#39;mem=3D1GB&#39;=A0 too?<br>Thanks<=
br><br><br><br><br><br>

--0015174c1a927c9ded04b3f81b45--


--===============8613017439481575337==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============8613017439481575337==--


From xen-devel-bounces@lists.xensource.com Tue Dec 13 12:09:43 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 12:09:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaRAd-0008D5-0X; Tue, 13 Dec 2011 12:09:19 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <svenvan.van@gmail.com>) id 1RaRAb-0008Cz-Hl
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 12:09:17 +0000
X-Env-Sender: svenvan.van@gmail.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1323778102!6515739!1
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5266 invoked from network); 13 Dec 2011 12:08:23 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 12:08:23 -0000
Received: by wgbds11 with SMTP id ds11so11684591wgb.24
	for <xen-devel@lists.xensource.com>;
	Tue, 13 Dec 2011 04:08:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=XSMarndbYz3bT60Ik/ZU7C+tfeBX9urLvdN+uSi+H4s=;
	b=E4u/1Z+W2luLoPRNX6HLGqTavtvjcC7rFScxBY2ZY8foBydulATK+zxlk49aTb31oo
	jYTlinW0iyi29uEvmpSlxv1eznYBb2GpPPzA4G7ZdRi7WD4c8HG2rd7snwh/RoMplTvK
	NXuuyujkVhxoP3DID9OMcEdyC9cU4KmPcs2cQ=
MIME-Version: 1.0
Received: by 10.227.197.10 with SMTP id ei10mr17053718wbb.11.1323778101255;
	Tue, 13 Dec 2011 04:08:21 -0800 (PST)
Received: by 10.223.76.15 with HTTP; Tue, 13 Dec 2011 04:08:21 -0800 (PST)
In-Reply-To: <20111212220013.GC12106@andromeda.dapyr.net>
References: <CAJmQyTik==F8PuR+j3SVRjxQQ_aVLjHeBZdboekD3iOVRR9Y0A@mail.gmail.com>
	<CAJmQyThnnRjvuHBzB-2P43FvHOu8=C8dkD_0yYGLFew3HnoAXg@mail.gmail.com>
	<20111212220013.GC12106@andromeda.dapyr.net>
Date: Tue, 13 Dec 2011 13:08:21 +0100
Message-ID: <CAJmQyTifE4Ms9iXSGAnTi0PfShTXjPUtwC0RmZ0rfTx78sQ+LA@mail.gmail.com>
From: svenvan svenvan <svenvan.van@gmail.com>
To: xen-devel@lists.xensource.com
Cc: konrad@darnok.org
Subject: Re: [Xen-devel] xen 4.0.1/w 2.6.32 swapper: page allocation failure
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============8613017439481575337=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============8613017439481575337==
Content-Type: multipart/alternative; boundary=0015174c1a927c9ded04b3f81b45

--0015174c1a927c9ded04b3f81b45
Content-Type: text/plain; charset=ISO-8859-1

2011/12/12 Konrad Rzeszutek Wilk <konrad@darnok.org>

> On Sun, Dec 11, 2011 at 06:21:52PM +0100, svenvan svenvan wrote:
> > 2011/12/5 svenvan svenvan <svenvan.van@gmail.com>
> > > > hi
> > > xen 4.0.1 w/2.6.32.41
> > >> > Last week dom0 experienced an hard crash and box need to be
> restarted
> > > manually (despite kernel.panic=20).
> > > Serial console was not setup, only netconsole.  No relevant entries
> > > through netconsole, but analyzing logs I see some crashes twenty
> minutes
> > > before fatal hang.
>
> >Browsing archive I found a reply from  Konrad Rzeszutek about something
> > similar:
> >
> http://old-list-archives.xen.org/archives/html/xen-devel/2011-09/msg00600.html
> >> Someone can confirm if it's the same issue or not?  Konrad maybe?
>


> You would get much more traction if you CC-ed me.
> Anyhow, no idea - 2.6.32-41 is a bit ancient and this thread does not
> seem to have relevant data (such as serial console for examples, or the
> "some crashes").
>


Thanks.  I have now setup serial console too
Adding more infos:  it happened in the night when there are some heavy
rsync from guests to a nfs server for backup purpose.

Just thinking about this one:

Page allocation failure with e1000
http://lists.debian.org/debian-backports/2011/01/msg00037.html
http://forums.gentoo.org/viewtopic-t-899896.html

and this one:
http://xen.1045712.n5.nabble.com/devel-next-2-6-39-SLUB-Unable-to-allocate-memory-on-node-1-gfp-0x20-tt4418288.html#a4422100


Maybe something related to e1000e driver?
Increasing /proc/sys/vm/min_free_kbytes can help?


xend-config.sxp relevant entries
(dom0-min-mem 1024)
(enable-dom0-ballooning no)

grub relevant entry
kernel          /boot/xen-4.0.1.gz dom0_mem=1024M max_cstate=1

Do I need to add  'mem=1GB'  too?
Thanks

--0015174c1a927c9ded04b3f81b45
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><div class=3D"gmail_quote">2011/12/12 Konrad Rzeszutek Wilk <span dir=
=3D"ltr">&lt;<a href=3D"mailto:konrad@darnok.org">konrad@darnok.org</a>&gt;=
</span><br><blockquote class=3D"gmail_quote" style=3D"margin:0pt 0pt 0pt 0.=
8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class=3D"HOEnZb"><div class=3D"h5">On Sun, Dec 11, 2011 at 06:21:52PM =
+0100, svenvan svenvan wrote:<br>
&gt; 2011/12/5 svenvan svenvan &lt;<a href=3D"mailto:svenvan.van@gmail.com"=
>svenvan.van@gmail.com</a>&gt;<br>
&gt;
&gt; &gt; hi<br>
&gt; &gt; xen 4.0.1 w/<a href=3D"http://2.6.32.41" target=3D"_blank">2.6.32=
.41</a><br>
&gt; &gt;&gt; &gt; Last week dom0 experienced an hard crash and box need to=
 be restarted<br>
&gt; &gt; manually (despite kernel.panic=3D20).<br>
&gt; &gt; Serial console was not setup, only netconsole. =A0No relevant ent=
ries<br>
&gt; &gt; through netconsole, but analyzing logs I see some crashes twenty =
minutes<br>
&gt; &gt; before fatal hang.<br></div></div></blockquote><div></div><blockq=
uote class=3D"gmail_quote" style=3D"margin:0pt 0pt 0pt 0.8ex;border-left:1p=
x solid rgb(204,204,204);padding-left:1ex"><div class=3D"HOEnZb"><div class=
=3D"h5">

&gt; &gt;Browsing archive I found a reply from =A0Konrad Rzeszutek about so=
mething<br>
&gt; similar:<br>
&gt; <a href=3D"http://old-list-archives.xen.org/archives/html/xen-devel/20=
11-09/msg00600.html" target=3D"_blank">http://old-list-archives.xen.org/arc=
hives/html/xen-devel/2011-09/msg00600.html</a><br>
&gt;&gt; Someone can confirm if it&#39;s the same issue or not? =A0Konrad m=
aybe?<br>

</div></div></blockquote><div>=A0</div><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padd=
ing-left:1ex">You would get much more traction if you CC-ed me.<br>

Anyhow, no idea - 2.6.32-41 is a bit ancient and this thread does not<br>
seem to have relevant data (such as serial console for examples, or the<br>
&quot;some crashes&quot;).<br>
</blockquote></div><br><br>Thanks.=A0 I have now setup serial console too<b=
r>Adding more infos:=A0 it happened in the night when there are some heavy =
rsync from guests to a nfs server for backup purpose.<br><br>Just thinking =
about this one:<br>
<br>Page allocation failure with e1000<br><a href=3D"http://lists.debian.or=
g/debian-backports/2011/01/msg00037.html">http://lists.debian.org/debian-ba=
ckports/2011/01/msg00037.html</a><br><a href=3D"http://forums.gentoo.org/vi=
ewtopic-t-899896.html">http://forums.gentoo.org/viewtopic-t-899896.html</a>=
<br>
<br>and this one:<br><a href=3D"http://xen.1045712.n5.nabble.com/devel-next=
-2-6-39-SLUB-Unable-to-allocate-memory-on-node-1-gfp-0x20-tt4418288.html#a4=
422100">http://xen.1045712.n5.nabble.com/devel-next-2-6-39-SLUB-Unable-to-a=
llocate-memory-on-node-1-gfp-0x20-tt4418288.html#a4422100</a><br>
<br><br>Maybe something related to e1000e driver?<br>Increasing /proc/sys/v=
m/min_free_kbytes can help? <br><br><br>xend-config.sxp relevant entries<br=
>(dom0-min-mem 1024)<br>(enable-dom0-ballooning no)<br><br>grub relevant en=
try<br>
kernel=A0=A0=A0=A0=A0=A0=A0=A0=A0 /boot/xen-4.0.1.gz dom0_mem=3D1024M max_c=
state=3D1<br><br>Do I need to add=A0 &#39;mem=3D1GB&#39;=A0 too?<br>Thanks<=
br><br><br><br><br><br>

--0015174c1a927c9ded04b3f81b45--


--===============8613017439481575337==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============8613017439481575337==--


From xen-devel-bounces@lists.xensource.com Tue Dec 13 12:36:55 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 12:36:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaRak-0008To-TS; Tue, 13 Dec 2011 12:36:18 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jan.kiszka@siemens.com>) id 1RaRaj-0008Tj-S9
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 12:36:18 +0000
X-Env-Sender: jan.kiszka@siemens.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1323779723!6672346!1
X-Originating-IP: [192.35.17.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjM1LjE3LjI4ID0+IDI5NTcwNw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22763 invoked from network); 13 Dec 2011 12:35:23 -0000
Received: from goliath.siemens.de (HELO goliath.siemens.de) (192.35.17.28)
	by server-13.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 13 Dec 2011 12:35:23 -0000
Received: from mail1.siemens.de (localhost [127.0.0.1])
	by goliath.siemens.de (8.13.6/8.13.6) with ESMTP id pBDCZHFf007915;
	Tue, 13 Dec 2011 13:35:17 +0100
Received: from mchn199C.mchp.siemens.de ([139.25.109.49])
	by mail1.siemens.de (8.13.6/8.13.6) with ESMTP id pBDCZGmM014186;
	Tue, 13 Dec 2011 13:35:16 +0100
Message-ID: <4EE74684.7010708@siemens.com>
Date: Tue, 13 Dec 2011 13:35:16 +0100
From: Jan Kiszka <jan.kiszka@siemens.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de;
	rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12
	Mnenhy/0.7.5.666
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <1323467645-24271-1-git-send-email-anthony.perard@citrix.com>
	<1323467645-24271-6-git-send-email-anthony.perard@citrix.com>
	<4EE3382D.80903@web.de>
	<alpine.DEB.2.00.1112121259180.3517@kaball-desktop>
	<4EE609BF.1070307@siemens.com>
	<alpine.DEB.2.00.1112121438410.3517@kaball-desktop>
	<4EE617BA.4030102@siemens.com>
	<alpine.DEB.2.00.1112121527130.3517@kaball-desktop>
	<alpine.DEB.2.00.1112131141170.3517@kaball-desktop>
In-Reply-To: <alpine.DEB.2.00.1112131141170.3517@kaball-desktop>
Cc: Anthony Perard <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	QEMU-devel <qemu-devel@nongnu.org>
Subject: Re: [Xen-devel] early_savevm
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 2011-12-13 12:55, Stefano Stabellini wrote:
> On Mon, 12 Dec 2011, Stefano Stabellini wrote:
>>> Really, I think this is something inherently incompatible with the
>>> current memory API. If Xen has this unfixable special "requirement"
>>> (it's rather a design issue IMHO), adjust the API and adapt all devices.
>>> Hot-fixing only a single one this way is no good idea long term.
>>
>> Fair enough.
>> What about introducing a type of savevm state that is going to be
>> restored before machine->init?
>> This way we could save and restore our physmap and we could handle
>> memory maps and allocations transparently.
>>
> 
> A bit more context to my suggestion:
> 
> - we open the save state file and check the magic number and the
> version number before machine->init();
> 
> - we add a new set of entries to the save state file that contains
> early_savevm functions: they are called before machine->init();
> 
> - after reaching the end of the early_savevm functions we stop parsing
> the save state file and we call machine->init();
> 
> - after machine->init() is completed we continue parsing the save state
> file as usual.

Hmm, just wondering if another use case for this early incoming
migration step is transferring the machine configuration so that the
receiver need not worry about synchronizing it out of band. That may
help motivating this likely not trivial change.

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 12:36:55 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 12:36:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaRak-0008To-TS; Tue, 13 Dec 2011 12:36:18 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jan.kiszka@siemens.com>) id 1RaRaj-0008Tj-S9
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 12:36:18 +0000
X-Env-Sender: jan.kiszka@siemens.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1323779723!6672346!1
X-Originating-IP: [192.35.17.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjM1LjE3LjI4ID0+IDI5NTcwNw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22763 invoked from network); 13 Dec 2011 12:35:23 -0000
Received: from goliath.siemens.de (HELO goliath.siemens.de) (192.35.17.28)
	by server-13.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 13 Dec 2011 12:35:23 -0000
Received: from mail1.siemens.de (localhost [127.0.0.1])
	by goliath.siemens.de (8.13.6/8.13.6) with ESMTP id pBDCZHFf007915;
	Tue, 13 Dec 2011 13:35:17 +0100
Received: from mchn199C.mchp.siemens.de ([139.25.109.49])
	by mail1.siemens.de (8.13.6/8.13.6) with ESMTP id pBDCZGmM014186;
	Tue, 13 Dec 2011 13:35:16 +0100
Message-ID: <4EE74684.7010708@siemens.com>
Date: Tue, 13 Dec 2011 13:35:16 +0100
From: Jan Kiszka <jan.kiszka@siemens.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de;
	rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12
	Mnenhy/0.7.5.666
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <1323467645-24271-1-git-send-email-anthony.perard@citrix.com>
	<1323467645-24271-6-git-send-email-anthony.perard@citrix.com>
	<4EE3382D.80903@web.de>
	<alpine.DEB.2.00.1112121259180.3517@kaball-desktop>
	<4EE609BF.1070307@siemens.com>
	<alpine.DEB.2.00.1112121438410.3517@kaball-desktop>
	<4EE617BA.4030102@siemens.com>
	<alpine.DEB.2.00.1112121527130.3517@kaball-desktop>
	<alpine.DEB.2.00.1112131141170.3517@kaball-desktop>
In-Reply-To: <alpine.DEB.2.00.1112131141170.3517@kaball-desktop>
Cc: Anthony Perard <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	QEMU-devel <qemu-devel@nongnu.org>
Subject: Re: [Xen-devel] early_savevm
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 2011-12-13 12:55, Stefano Stabellini wrote:
> On Mon, 12 Dec 2011, Stefano Stabellini wrote:
>>> Really, I think this is something inherently incompatible with the
>>> current memory API. If Xen has this unfixable special "requirement"
>>> (it's rather a design issue IMHO), adjust the API and adapt all devices.
>>> Hot-fixing only a single one this way is no good idea long term.
>>
>> Fair enough.
>> What about introducing a type of savevm state that is going to be
>> restored before machine->init?
>> This way we could save and restore our physmap and we could handle
>> memory maps and allocations transparently.
>>
> 
> A bit more context to my suggestion:
> 
> - we open the save state file and check the magic number and the
> version number before machine->init();
> 
> - we add a new set of entries to the save state file that contains
> early_savevm functions: they are called before machine->init();
> 
> - after reaching the end of the early_savevm functions we stop parsing
> the save state file and we call machine->init();
> 
> - after machine->init() is completed we continue parsing the save state
> file as usual.

Hmm, just wondering if another use case for this early incoming
migration step is transferring the machine configuration so that the
receiver need not worry about synchronizing it out of band. That may
help motivating this likely not trivial change.

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 13:19:17 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 13:19:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaSFs-0000jH-Bf; Tue, 13 Dec 2011 13:18:48 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1RaSFr-0000jC-AY
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 13:18:47 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1323782242!56489162!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjAzMzQ=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16084 invoked from network); 13 Dec 2011 13:17:23 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 13:17:23 -0000
X-IronPort-AV: E=Sophos;i="4.71,345,1320642000"; d="scan'208";a="173934392"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Dec 2011 08:17:53 -0500
Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX02.citrite.net
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Tue, 13 Dec 2011
	08:17:53 -0500
Message-ID: <4EE75080.1000909@citrix.com>
Date: Tue, 13 Dec 2011 13:17:52 +0000
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20111110 Icedove/3.0.11
MIME-Version: 1.0
To: George Shuklin <george.shuklin@gmail.com>
References: <4EE675A8.3030609@niemail.de>
	<4EE71663.5040308@gmail.com>	<CAJeBh4sxdNTxM_oLFAuA6Mw75=LaYysrpS5b8NsZMbkf_swNVw@mail.gmail.com>
	<4EE72A94.6040904@gmail.com>
In-Reply-To: <4EE72A94.6040904@gmail.com>
Cc: xen-devel@lists.xensource.com, sandr8@gmail.com
Subject: Re: [Xen-devel] a ton of kernel issues
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 13/12/11 10:36, George Shuklin wrote:
> On 13.12.2011 14:19, Alessandro Salvatori wrote:
>>
>>> pv_ops is still have some issues with memory limits, but any
>>> new kernel (3.0+) will boot normal and operates with very
>>> minor glitches. Older pv_ops (f.e. debian 2.6.32) have some
>>> more major issues.
>> what glitches should one expect with 3.0+, and having the choice,
>> would it be better to go with 3.1 or even 3.2?
>>
>>
> Right now I know about two of them:
> When you set up memory for virtual machine using xenballon, value in
> dom0 differ from value in domU. The issue is that -xen kernels 'hide'
> some memory in 'used' memory, and pv-ops just reducing TotalMem to value
> without that memory. Practically that means if you set up memory for
> domain to 2GiB client will saw only 1.95GiB and so on.

This really makes no practical difference.  The memory is "used" is
either case and the different reporting is a side-effect of the change
in how certain memory allocations are done.

> The second issue is lack of support of 'pre-inflated balloon', means you
> can not set up memory-static-max to 2GiB, target to 1GiB and do 'memory
> grow' from 1 G to 2 G latter without VM reboot. -xen kernels allow this
> (up to memory-static-max limit).

This should work if memory hotplug is enabled.

It is also supported without memory hotplug but this requires that the
tools supply a suitable memory map that covers the largest
memory-static-max limit you wish to support.  I'm not sure if the tools
can do this yet.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 13:19:17 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 13:19:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaSFs-0000jH-Bf; Tue, 13 Dec 2011 13:18:48 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1RaSFr-0000jC-AY
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 13:18:47 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1323782242!56489162!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjAzMzQ=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16084 invoked from network); 13 Dec 2011 13:17:23 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 13:17:23 -0000
X-IronPort-AV: E=Sophos;i="4.71,345,1320642000"; d="scan'208";a="173934392"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Dec 2011 08:17:53 -0500
Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX02.citrite.net
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Tue, 13 Dec 2011
	08:17:53 -0500
Message-ID: <4EE75080.1000909@citrix.com>
Date: Tue, 13 Dec 2011 13:17:52 +0000
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20111110 Icedove/3.0.11
MIME-Version: 1.0
To: George Shuklin <george.shuklin@gmail.com>
References: <4EE675A8.3030609@niemail.de>
	<4EE71663.5040308@gmail.com>	<CAJeBh4sxdNTxM_oLFAuA6Mw75=LaYysrpS5b8NsZMbkf_swNVw@mail.gmail.com>
	<4EE72A94.6040904@gmail.com>
In-Reply-To: <4EE72A94.6040904@gmail.com>
Cc: xen-devel@lists.xensource.com, sandr8@gmail.com
Subject: Re: [Xen-devel] a ton of kernel issues
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 13/12/11 10:36, George Shuklin wrote:
> On 13.12.2011 14:19, Alessandro Salvatori wrote:
>>
>>> pv_ops is still have some issues with memory limits, but any
>>> new kernel (3.0+) will boot normal and operates with very
>>> minor glitches. Older pv_ops (f.e. debian 2.6.32) have some
>>> more major issues.
>> what glitches should one expect with 3.0+, and having the choice,
>> would it be better to go with 3.1 or even 3.2?
>>
>>
> Right now I know about two of them:
> When you set up memory for virtual machine using xenballon, value in
> dom0 differ from value in domU. The issue is that -xen kernels 'hide'
> some memory in 'used' memory, and pv-ops just reducing TotalMem to value
> without that memory. Practically that means if you set up memory for
> domain to 2GiB client will saw only 1.95GiB and so on.

This really makes no practical difference.  The memory is "used" is
either case and the different reporting is a side-effect of the change
in how certain memory allocations are done.

> The second issue is lack of support of 'pre-inflated balloon', means you
> can not set up memory-static-max to 2GiB, target to 1GiB and do 'memory
> grow' from 1 G to 2 G latter without VM reboot. -xen kernels allow this
> (up to memory-static-max limit).

This should work if memory hotplug is enabled.

It is also supported without memory hotplug but this requires that the
tools supply a suitable memory map that covers the largest
memory-static-max limit you wish to support.  I'm not sure if the tools
can do this yet.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 13:22:49 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 13:22:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaSJB-0000rU-4K; Tue, 13 Dec 2011 13:22:13 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RaSJA-0000rF-7j
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 13:22:12 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1323782476!5343837!1
X-Originating-IP: [209.85.216.50]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2829 invoked from network); 13 Dec 2011 13:21:17 -0000
Received: from mail-qw0-f50.google.com (HELO mail-qw0-f50.google.com)
	(209.85.216.50)
	by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 13:21:17 -0000
Received: by qaea17 with SMTP id a17so33727883qae.9
	for <xen-devel@lists.xensource.com>;
	Tue, 13 Dec 2011 05:21:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=VEWDadGki8WdJnFMrA4CRnENgBrOTHSvFxWwWSfgiBA=;
	b=ramGEV21qetRTFEqiWa/PQPRne5hNFJgZSJq1XGymOKmcTuhyfnWxIKqOsfXSLXD1a
	/kDgtpKapo7W8HQXqy2ugWODIKxIyiiYn78OuyTI5qffNwq7ADKZXKNs4jYsmC/muG9C
	jtOsDRXmgLY9E1rnfy/Rnoti7lv5b+gAyymhs=
MIME-Version: 1.0
Received: by 10.224.185.203 with SMTP id cp11mr2522175qab.93.1323782476393;
	Tue, 13 Dec 2011 05:21:16 -0800 (PST)
Received: by 10.229.163.208 with HTTP; Tue, 13 Dec 2011 05:21:16 -0800 (PST)
In-Reply-To: <4EE72B7C.7030006@redhat.com>
References: <7697ee23b08b8eaca9ae.1323768649@loki.upc.es>
	<1323770544.20077.268.camel@zakaz.uk.xensource.com>
	<4EE72B7C.7030006@redhat.com>
Date: Tue, 13 Dec 2011 14:21:16 +0100
X-Google-Sender-Auth: _FUNngNBq7-BvWO6pBks6iyEb-c
Message-ID: <CAPLaKK5+Cup9w5HJKhMmu7RQG=EDp_FL8kjHQuaUW9PX373R=A@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Laszlo Ersek <lersek@redhat.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH] xenpaging: remove XOPEN_SOURCE
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

MjAxMS8xMi8xMyBMYXN6bG8gRXJzZWsgPGxlcnNla0ByZWRoYXQuY29tPjoKPiBPbiAxMi8xMy8x
MSAxMTowMiwgSWFuIENhbXBiZWxsIHdyb3RlOgo+Pgo+PiBPbiBUdWUsIDIwMTEtMTItMTMgYXQg
MDk6MzAgKzAwMDAsIFJvZ2VyIFBhdSBNb25uZSB3cm90ZToKPj4+Cj4+PiAjIEhHIGNoYW5nZXNl
dCBwYXRjaAo+Pj4gIyBVc2VyIFJvZ2VyIFBhdSBNb25uZTxyb2dlci5wYXVAZW50ZWwudXBjLmVk
dT4KPj4+ICMgRGF0ZSAxMzIzNzY4MTI5IC0zNjAwCj4+PiAjIE5vZGUgSUQgNzY5N2VlMjNiMDhi
OGVhY2E5YWVlNGY2Yjc5Y2Y1NTBhNDkwYmVmNwo+Pj4gIyBQYXJlbnQgwqA4YTg0ZjUzMzc2ODYy
NDI3ZjI1NGEwMTdjYjUyYzkyOGRiZGQzZDMyCj4+PiB4ZW5wYWdpbmc6IHJlbW92ZSBYT1BFTl9T
T1VSQ0UKPj4+Cj4+PiBUaGUgWE9QRU5fU09VUkNFIGRlZmluZSB3YXMgYnJlYWtpbmcgdGhlIGNv
bXBpbGF0aW9uIHVuZGVyIE5ldEJTRC4KPj4KPj4KPj4gSG93PwoKSWYgX1hPUEVOX1NPVUNFIGlz
IGRlZmluZWQsIHRoZW4gdGhlIGNvbXBpbGVyIGNhbm5vdCBmaW5kIHRoZQpwcm90b3R5cGUgb2Yg
YXNwcmludGYgYW5kIGl0IHRocm93cyBhIHdhcm5pbmcgdGhhdCBzdG9wcyB0aGUKY29tcGlsYXRp
b24uCgpUaGlzIGlzIGJlY2F1c2UgdGhlIHByb3RvdHlwZSBvZiBhc3ByaW50ZiBpcyBkZWNsYXJl
ZCBhcyBmb2xsb3dzIHVuZGVyIE5ldEJTRDoKCiNpZiBkZWZpbmVkKF9ORVRCU0RfU09VUkNFKQpb
Li4uXQppbnQgICAgICBhc3ByaW50ZihjaGFyICoqIF9fcmVzdHJpY3QsIGNvbnN0IGNoYXIgKiBf
X3Jlc3RyaWN0LCAuLi4pCiAgICAgICAgICAgICAgICBfX3ByaW50Zmxpa2UoMiwgMyk7ClsuLi5d
CiNlbmRpZgoKQW5kIF9ORVRCU0RfU09VUkNFIGlzIGRlZmluZWQgaWY6CgojaWYgIWRlZmluZWQo
X0FOU0lfU09VUkNFKSAmJiAhZGVmaW5lZChfUE9TSVhfQ19TT1VSQ0UpICYmIFwKICAgICFkZWZp
bmVkKF9YT1BFTl9TT1VSQ0UpICYmICFkZWZpbmVkKF9ORVRCU0RfU09VUkNFKQojZGVmaW5lIF9O
RVRCU0RfU09VUkNFIDEKI2VuZGlmCgpQcm9iYWJseSB0aGUgYXNwcmludGYgcHJvdG90eXBlIHNo
b3VsZCBiZSBkZWZpbmVkIGFzOgoKI2lmIGRlZmluZWQoX05FVEJTRF9TT1VSQ0UpIHx8IGRlZmlu
ZWQoX1hPUEVOX1NPVVJDRSkKWy4uLl0KaW50ICAgICAgYXNwcmludGYoY2hhciAqKiBfX3Jlc3Ry
aWN0LCBjb25zdCBjaGFyICogX19yZXN0cmljdCwgLi4uKQogICAgICAgICAgICAgICAgX19wcmlu
dGZsaWtlKDIsIDMpOwo+Cj4gSW5kZWVkLiBCb3RoIHRoZSBjb21taXQgdGhhdCBhZGRlZCBpdCBb
MV0gWzJdIGFuZCB0aGlzIHBhdGNoIHByb3ZpZGUgdmVyeQo+IGxpdHRsZSB1c2VmdWwgaW5mbyBp
biB0aGVpciByZXNwZWN0aXZlIG1lc3NhZ2VzLiBJdCdzIGludGVyZXN0aW5nIGJlY2F1c2UgaXQK
PiBjb3VsZCBwb2ludCBvdXQgYSBTVVN2MyBpbmNvbXBhdGliaWxpdHkgaW4gaW4gTmV0QlNELgo+
Cj4KPj4+IEkndmUgcmVtb3ZlZCBpdCBiZWNhc3VlIGl0IGlzIG5vdCBuZWNlc3NhcnkgKGF0IGxl
YXN0IHVuZGVyIE5ldEJTRCkuCj4+PiBJZiBpdCBpcyBuZWNlc3NhcnkgZm9yIExpbnV4LCB3ZSBj
YW4gYWRkIGEgaWZkZWYgY29uZGl0aW9uYWwgdG8gcmVtb3ZlCj4+PiB0aGlzIG9ubHkgdW5kZXIg
TmV0QlNELgo+Pgo+Pgo+PiBSZW1vdmluZyBpdCBzZWVtcyB0byBub3QgYnJlYWsgTGludXgsIGF0
IGxlYXN0IGZvciBtZS4KPgo+Cj4gVGhlIHN0dWZmIG1hZGUgdmlzaWJsZSBieSBfR05VX1NPVVJD
RSAod2l0aCBnbGliYykgaW5jbHVkZXMgZXZlcnl0aGluZwo+IF9YT1BFTl9TT1VSQ0UgbWFrZXMg
dmlzaWJsZSBbM10uIFs0XSBpbnRyb2R1Y2VkIGl0IGJlY2F1c2Ugb2YgYXNwcmludGYoKS4KCklm
IGl0J3Mgbm90IG5lY2Vzc2FyeSBJIHRoaW5rIGl0J3MgYmVzdCB0byByZW1vdmUgdGhlIGRlZmlu
aXRpb24sIHRvCmF2b2lkIGhhdmluZyBhIGxvdCBvZiB1c2VsZXNzIGRlZmluZXMgYWxsIG92ZXIg
dGhlIGNvZGUuCgo+IExhc3psbwo+Cj4gWzFdCj4gaHR0cDovL29sZC1saXN0LWFyY2hpdmVzLnhl
bi5vcmcvYXJjaGl2ZXMvaHRtbC94ZW4tZGV2ZWwvMjAxMC0wOC9tc2cwMTExMC5odG1sCj4gWzJd
IGh0dHA6Ly94ZW5iaXRzLnhlbnNvdXJjZS5jb20vaGcveGVuLXVuc3RhYmxlLmhnL3Jldi8yMjAy
Mwo+IFszXQo+IGh0dHA6Ly93d3cuZ251Lm9yZy9zb2Z0d2FyZS9saWJjL21hbnVhbC9odG1sX25v
ZGUvRmVhdHVyZS1UZXN0LU1hY3Jvcy5odG1sI2luZGV4LWdfdF8wMDVmR05VXzAwNWZTT1VSQ0Ut
NTEKPiBbNF0gaHR0cDovL3hlbmJpdHMueGVuc291cmNlLmNvbS9oZy94ZW4tdW5zdGFibGUuaGcv
cmV2LzI0MjIzCj4KPgo+Cj4+Cj4+PiBTaWduZWQtb2ZmLWJ5OiBSb2dlciBQYXUgTW9ubmU8cm9n
ZXIucGF1QGVudGVsLnVwYy5lZHU+Cj4+Cj4+Cj4+IEFja2VkLWJ5OiBJYW4gQ2FtcGJlbGw8aWFu
LmNhbXBiZWxsQGNpdHJpeC5jb20+Cj4+Pgo+Pj4KPj4+IGRpZmYgLXIgOGE4NGY1MzM3Njg2IC1y
IDc2OTdlZTIzYjA4YiB0b29scy94ZW5wYWdpbmcveGVucGFnaW5nLmMKPj4+IC0tLSBhL3Rvb2xz
L3hlbnBhZ2luZy94ZW5wYWdpbmcuYyDCoCDCoCDCoCBUdWUgRGVjIDEzIDA5OjQ5OjU1IDIwMTEg
KzAxMDAKPj4+ICsrKyBiL3Rvb2xzL3hlbnBhZ2luZy94ZW5wYWdpbmcuYyDCoCDCoCDCoCBUdWUg
RGVjIDEzIDEwOjIyOjA5IDIwMTEgKzAxMDAKPj4+IEBAIC0xOCw3ICsxOCw2IEBACj4+PiDCoCAq
IEZvdW5kYXRpb24sIEluYy4sIDU5IFRlbXBsZSBQbGFjZSwgU3VpdGUgMzMwLCBCb3N0b24sIE1B
IMKgMDIxMTEtMTMwNwo+Pj4gwqBVU0EKPj4+IMKgICovCj4+Pgo+Pj4gLSNkZWZpbmUgX1hPUEVO
X1NPVVJDRSDCoDYwMAo+Pj4gwqAjZGVmaW5lIF9HTlVfU09VUkNFCj4+Pgo+Pj4gwqAjaW5jbHVk
ZTxpbnR0eXBlcy5oPgo+Cj4KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fXwo+IFhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKPiBYZW4tZGV2ZWxAbGlzdHMueGVu
c291cmNlLmNvbQo+IGh0dHA6Ly9saXN0cy54ZW5zb3VyY2UuY29tL3hlbi1kZXZlbAoKX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxp
bmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuc291cmNlLmNvbQpodHRwOi8vbGlzdHMueGVuc291
cmNlLmNvbS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Tue Dec 13 13:22:49 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 13:22:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaSJB-0000rU-4K; Tue, 13 Dec 2011 13:22:13 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RaSJA-0000rF-7j
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 13:22:12 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1323782476!5343837!1
X-Originating-IP: [209.85.216.50]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2829 invoked from network); 13 Dec 2011 13:21:17 -0000
Received: from mail-qw0-f50.google.com (HELO mail-qw0-f50.google.com)
	(209.85.216.50)
	by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 13:21:17 -0000
Received: by qaea17 with SMTP id a17so33727883qae.9
	for <xen-devel@lists.xensource.com>;
	Tue, 13 Dec 2011 05:21:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=VEWDadGki8WdJnFMrA4CRnENgBrOTHSvFxWwWSfgiBA=;
	b=ramGEV21qetRTFEqiWa/PQPRne5hNFJgZSJq1XGymOKmcTuhyfnWxIKqOsfXSLXD1a
	/kDgtpKapo7W8HQXqy2ugWODIKxIyiiYn78OuyTI5qffNwq7ADKZXKNs4jYsmC/muG9C
	jtOsDRXmgLY9E1rnfy/Rnoti7lv5b+gAyymhs=
MIME-Version: 1.0
Received: by 10.224.185.203 with SMTP id cp11mr2522175qab.93.1323782476393;
	Tue, 13 Dec 2011 05:21:16 -0800 (PST)
Received: by 10.229.163.208 with HTTP; Tue, 13 Dec 2011 05:21:16 -0800 (PST)
In-Reply-To: <4EE72B7C.7030006@redhat.com>
References: <7697ee23b08b8eaca9ae.1323768649@loki.upc.es>
	<1323770544.20077.268.camel@zakaz.uk.xensource.com>
	<4EE72B7C.7030006@redhat.com>
Date: Tue, 13 Dec 2011 14:21:16 +0100
X-Google-Sender-Auth: _FUNngNBq7-BvWO6pBks6iyEb-c
Message-ID: <CAPLaKK5+Cup9w5HJKhMmu7RQG=EDp_FL8kjHQuaUW9PX373R=A@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Laszlo Ersek <lersek@redhat.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH] xenpaging: remove XOPEN_SOURCE
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

MjAxMS8xMi8xMyBMYXN6bG8gRXJzZWsgPGxlcnNla0ByZWRoYXQuY29tPjoKPiBPbiAxMi8xMy8x
MSAxMTowMiwgSWFuIENhbXBiZWxsIHdyb3RlOgo+Pgo+PiBPbiBUdWUsIDIwMTEtMTItMTMgYXQg
MDk6MzAgKzAwMDAsIFJvZ2VyIFBhdSBNb25uZSB3cm90ZToKPj4+Cj4+PiAjIEhHIGNoYW5nZXNl
dCBwYXRjaAo+Pj4gIyBVc2VyIFJvZ2VyIFBhdSBNb25uZTxyb2dlci5wYXVAZW50ZWwudXBjLmVk
dT4KPj4+ICMgRGF0ZSAxMzIzNzY4MTI5IC0zNjAwCj4+PiAjIE5vZGUgSUQgNzY5N2VlMjNiMDhi
OGVhY2E5YWVlNGY2Yjc5Y2Y1NTBhNDkwYmVmNwo+Pj4gIyBQYXJlbnQgwqA4YTg0ZjUzMzc2ODYy
NDI3ZjI1NGEwMTdjYjUyYzkyOGRiZGQzZDMyCj4+PiB4ZW5wYWdpbmc6IHJlbW92ZSBYT1BFTl9T
T1VSQ0UKPj4+Cj4+PiBUaGUgWE9QRU5fU09VUkNFIGRlZmluZSB3YXMgYnJlYWtpbmcgdGhlIGNv
bXBpbGF0aW9uIHVuZGVyIE5ldEJTRC4KPj4KPj4KPj4gSG93PwoKSWYgX1hPUEVOX1NPVUNFIGlz
IGRlZmluZWQsIHRoZW4gdGhlIGNvbXBpbGVyIGNhbm5vdCBmaW5kIHRoZQpwcm90b3R5cGUgb2Yg
YXNwcmludGYgYW5kIGl0IHRocm93cyBhIHdhcm5pbmcgdGhhdCBzdG9wcyB0aGUKY29tcGlsYXRp
b24uCgpUaGlzIGlzIGJlY2F1c2UgdGhlIHByb3RvdHlwZSBvZiBhc3ByaW50ZiBpcyBkZWNsYXJl
ZCBhcyBmb2xsb3dzIHVuZGVyIE5ldEJTRDoKCiNpZiBkZWZpbmVkKF9ORVRCU0RfU09VUkNFKQpb
Li4uXQppbnQgICAgICBhc3ByaW50ZihjaGFyICoqIF9fcmVzdHJpY3QsIGNvbnN0IGNoYXIgKiBf
X3Jlc3RyaWN0LCAuLi4pCiAgICAgICAgICAgICAgICBfX3ByaW50Zmxpa2UoMiwgMyk7ClsuLi5d
CiNlbmRpZgoKQW5kIF9ORVRCU0RfU09VUkNFIGlzIGRlZmluZWQgaWY6CgojaWYgIWRlZmluZWQo
X0FOU0lfU09VUkNFKSAmJiAhZGVmaW5lZChfUE9TSVhfQ19TT1VSQ0UpICYmIFwKICAgICFkZWZp
bmVkKF9YT1BFTl9TT1VSQ0UpICYmICFkZWZpbmVkKF9ORVRCU0RfU09VUkNFKQojZGVmaW5lIF9O
RVRCU0RfU09VUkNFIDEKI2VuZGlmCgpQcm9iYWJseSB0aGUgYXNwcmludGYgcHJvdG90eXBlIHNo
b3VsZCBiZSBkZWZpbmVkIGFzOgoKI2lmIGRlZmluZWQoX05FVEJTRF9TT1VSQ0UpIHx8IGRlZmlu
ZWQoX1hPUEVOX1NPVVJDRSkKWy4uLl0KaW50ICAgICAgYXNwcmludGYoY2hhciAqKiBfX3Jlc3Ry
aWN0LCBjb25zdCBjaGFyICogX19yZXN0cmljdCwgLi4uKQogICAgICAgICAgICAgICAgX19wcmlu
dGZsaWtlKDIsIDMpOwo+Cj4gSW5kZWVkLiBCb3RoIHRoZSBjb21taXQgdGhhdCBhZGRlZCBpdCBb
MV0gWzJdIGFuZCB0aGlzIHBhdGNoIHByb3ZpZGUgdmVyeQo+IGxpdHRsZSB1c2VmdWwgaW5mbyBp
biB0aGVpciByZXNwZWN0aXZlIG1lc3NhZ2VzLiBJdCdzIGludGVyZXN0aW5nIGJlY2F1c2UgaXQK
PiBjb3VsZCBwb2ludCBvdXQgYSBTVVN2MyBpbmNvbXBhdGliaWxpdHkgaW4gaW4gTmV0QlNELgo+
Cj4KPj4+IEkndmUgcmVtb3ZlZCBpdCBiZWNhc3VlIGl0IGlzIG5vdCBuZWNlc3NhcnkgKGF0IGxl
YXN0IHVuZGVyIE5ldEJTRCkuCj4+PiBJZiBpdCBpcyBuZWNlc3NhcnkgZm9yIExpbnV4LCB3ZSBj
YW4gYWRkIGEgaWZkZWYgY29uZGl0aW9uYWwgdG8gcmVtb3ZlCj4+PiB0aGlzIG9ubHkgdW5kZXIg
TmV0QlNELgo+Pgo+Pgo+PiBSZW1vdmluZyBpdCBzZWVtcyB0byBub3QgYnJlYWsgTGludXgsIGF0
IGxlYXN0IGZvciBtZS4KPgo+Cj4gVGhlIHN0dWZmIG1hZGUgdmlzaWJsZSBieSBfR05VX1NPVVJD
RSAod2l0aCBnbGliYykgaW5jbHVkZXMgZXZlcnl0aGluZwo+IF9YT1BFTl9TT1VSQ0UgbWFrZXMg
dmlzaWJsZSBbM10uIFs0XSBpbnRyb2R1Y2VkIGl0IGJlY2F1c2Ugb2YgYXNwcmludGYoKS4KCklm
IGl0J3Mgbm90IG5lY2Vzc2FyeSBJIHRoaW5rIGl0J3MgYmVzdCB0byByZW1vdmUgdGhlIGRlZmlu
aXRpb24sIHRvCmF2b2lkIGhhdmluZyBhIGxvdCBvZiB1c2VsZXNzIGRlZmluZXMgYWxsIG92ZXIg
dGhlIGNvZGUuCgo+IExhc3psbwo+Cj4gWzFdCj4gaHR0cDovL29sZC1saXN0LWFyY2hpdmVzLnhl
bi5vcmcvYXJjaGl2ZXMvaHRtbC94ZW4tZGV2ZWwvMjAxMC0wOC9tc2cwMTExMC5odG1sCj4gWzJd
IGh0dHA6Ly94ZW5iaXRzLnhlbnNvdXJjZS5jb20vaGcveGVuLXVuc3RhYmxlLmhnL3Jldi8yMjAy
Mwo+IFszXQo+IGh0dHA6Ly93d3cuZ251Lm9yZy9zb2Z0d2FyZS9saWJjL21hbnVhbC9odG1sX25v
ZGUvRmVhdHVyZS1UZXN0LU1hY3Jvcy5odG1sI2luZGV4LWdfdF8wMDVmR05VXzAwNWZTT1VSQ0Ut
NTEKPiBbNF0gaHR0cDovL3hlbmJpdHMueGVuc291cmNlLmNvbS9oZy94ZW4tdW5zdGFibGUuaGcv
cmV2LzI0MjIzCj4KPgo+Cj4+Cj4+PiBTaWduZWQtb2ZmLWJ5OiBSb2dlciBQYXUgTW9ubmU8cm9n
ZXIucGF1QGVudGVsLnVwYy5lZHU+Cj4+Cj4+Cj4+IEFja2VkLWJ5OiBJYW4gQ2FtcGJlbGw8aWFu
LmNhbXBiZWxsQGNpdHJpeC5jb20+Cj4+Pgo+Pj4KPj4+IGRpZmYgLXIgOGE4NGY1MzM3Njg2IC1y
IDc2OTdlZTIzYjA4YiB0b29scy94ZW5wYWdpbmcveGVucGFnaW5nLmMKPj4+IC0tLSBhL3Rvb2xz
L3hlbnBhZ2luZy94ZW5wYWdpbmcuYyDCoCDCoCDCoCBUdWUgRGVjIDEzIDA5OjQ5OjU1IDIwMTEg
KzAxMDAKPj4+ICsrKyBiL3Rvb2xzL3hlbnBhZ2luZy94ZW5wYWdpbmcuYyDCoCDCoCDCoCBUdWUg
RGVjIDEzIDEwOjIyOjA5IDIwMTEgKzAxMDAKPj4+IEBAIC0xOCw3ICsxOCw2IEBACj4+PiDCoCAq
IEZvdW5kYXRpb24sIEluYy4sIDU5IFRlbXBsZSBQbGFjZSwgU3VpdGUgMzMwLCBCb3N0b24sIE1B
IMKgMDIxMTEtMTMwNwo+Pj4gwqBVU0EKPj4+IMKgICovCj4+Pgo+Pj4gLSNkZWZpbmUgX1hPUEVO
X1NPVVJDRSDCoDYwMAo+Pj4gwqAjZGVmaW5lIF9HTlVfU09VUkNFCj4+Pgo+Pj4gwqAjaW5jbHVk
ZTxpbnR0eXBlcy5oPgo+Cj4KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fXwo+IFhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKPiBYZW4tZGV2ZWxAbGlzdHMueGVu
c291cmNlLmNvbQo+IGh0dHA6Ly9saXN0cy54ZW5zb3VyY2UuY29tL3hlbi1kZXZlbAoKX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxp
bmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuc291cmNlLmNvbQpodHRwOi8vbGlzdHMueGVuc291
cmNlLmNvbS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Tue Dec 13 13:33:48 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 13:33:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaSTz-0001EH-Cz; Tue, 13 Dec 2011 13:33:23 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RaSTx-0001EC-R5
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 13:33:22 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1323783145!5345782!1
X-Originating-IP: [209.85.216.50]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21630 invoked from network); 13 Dec 2011 13:32:27 -0000
Received: from mail-qw0-f50.google.com (HELO mail-qw0-f50.google.com)
	(209.85.216.50)
	by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 13:32:27 -0000
Received: by qaea17 with SMTP id a17so33757280qae.9
	for <xen-devel@lists.xensource.com>;
	Tue, 13 Dec 2011 05:32:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=q7pIC8bn+V1AWk0xleaVP83UFXbNvH5M7Sa6llKUhiQ=;
	b=gPZrldYL8llc3LigaPyNrbYKe/t7lbeFe6U/slhdaHkVr2p5IX7NJSJK3WhkFCCl8h
	4pgc8PoceYAzozXeqk449p/4gLGXjMV/rwKqNTFWTInvmf4i2d/srMw6sdAXL4O2y8+S
	0y46HE4LmGPlOU4z1qQNKdbvGu7aWw1qc7xSM=
MIME-Version: 1.0
Received: by 10.224.186.74 with SMTP id cr10mr2525783qab.67.1323782792382;
	Tue, 13 Dec 2011 05:26:32 -0800 (PST)
Received: by 10.229.163.208 with HTTP; Tue, 13 Dec 2011 05:26:32 -0800 (PST)
In-Reply-To: <20199.13781.707303.400465@mariner.uk.xensource.com>
References: <patchbomb.1322752087@loki.upc.es>
	<20198.16898.814613.705263@mariner.uk.xensource.com>
	<CAPLaKK4qK1sZJ_d-ivjmfG8biABvgrxP9JdjCMfJex4iXoP7Xw@mail.gmail.com>
	<20199.13781.707303.400465@mariner.uk.xensource.com>
Date: Tue, 13 Dec 2011 14:26:32 +0100
X-Google-Sender-Auth: xW_qnluze5jHDqBolSonunR6O3w
Message-ID: <CAPLaKK6=AgHvSULtPuNAPAhms3LsTja+WWHoPpxA5LSUu09v=w@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 00 of 11 v3] libxl: add support for hotplug
 script calling from libxl
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

MjAxMS8xMi8xMyBJYW4gSmFja3NvbiA8SWFuLkphY2tzb25AZXUuY2l0cml4LmNvbT46Cj4gU3Vy
ZSwgdGhhbmtzLiDCoEFuZCBzb3JyeSBhYm91dCB0aGUgaHVnZSBjb25mbGljdHMgeW91J3JlIHBy
b2JhYmx5Cj4gc2VlaW5nLi4uCgpJIHdpbGwgaGF2ZSB0byBzZW5kIHRoZSBzZXJpZXMgYWdhaW4s
IHNpbmNlIHRoZSBwdXNoIG9mIHRoZSBuZXcgY29kZQp3YXMgYWZ0ZXIgSSd2ZSBzdWJtaXR0ZWQg
dGhlIHBhdGNoZXMsIHNvcnJ5IGZvciB0aGUgZnVzcywgbGV0J3Mgc2VlIGlmCkkgY2FuIGZpbmlz
aCB0aGlzIHRvZGF5Li4uCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2Uu
Y29tCmh0dHA6Ly9saXN0cy54ZW5zb3VyY2UuY29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Tue Dec 13 13:33:48 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 13:33:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaSTz-0001EH-Cz; Tue, 13 Dec 2011 13:33:23 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RaSTx-0001EC-R5
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 13:33:22 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1323783145!5345782!1
X-Originating-IP: [209.85.216.50]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21630 invoked from network); 13 Dec 2011 13:32:27 -0000
Received: from mail-qw0-f50.google.com (HELO mail-qw0-f50.google.com)
	(209.85.216.50)
	by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 13:32:27 -0000
Received: by qaea17 with SMTP id a17so33757280qae.9
	for <xen-devel@lists.xensource.com>;
	Tue, 13 Dec 2011 05:32:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=q7pIC8bn+V1AWk0xleaVP83UFXbNvH5M7Sa6llKUhiQ=;
	b=gPZrldYL8llc3LigaPyNrbYKe/t7lbeFe6U/slhdaHkVr2p5IX7NJSJK3WhkFCCl8h
	4pgc8PoceYAzozXeqk449p/4gLGXjMV/rwKqNTFWTInvmf4i2d/srMw6sdAXL4O2y8+S
	0y46HE4LmGPlOU4z1qQNKdbvGu7aWw1qc7xSM=
MIME-Version: 1.0
Received: by 10.224.186.74 with SMTP id cr10mr2525783qab.67.1323782792382;
	Tue, 13 Dec 2011 05:26:32 -0800 (PST)
Received: by 10.229.163.208 with HTTP; Tue, 13 Dec 2011 05:26:32 -0800 (PST)
In-Reply-To: <20199.13781.707303.400465@mariner.uk.xensource.com>
References: <patchbomb.1322752087@loki.upc.es>
	<20198.16898.814613.705263@mariner.uk.xensource.com>
	<CAPLaKK4qK1sZJ_d-ivjmfG8biABvgrxP9JdjCMfJex4iXoP7Xw@mail.gmail.com>
	<20199.13781.707303.400465@mariner.uk.xensource.com>
Date: Tue, 13 Dec 2011 14:26:32 +0100
X-Google-Sender-Auth: xW_qnluze5jHDqBolSonunR6O3w
Message-ID: <CAPLaKK6=AgHvSULtPuNAPAhms3LsTja+WWHoPpxA5LSUu09v=w@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 00 of 11 v3] libxl: add support for hotplug
 script calling from libxl
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

MjAxMS8xMi8xMyBJYW4gSmFja3NvbiA8SWFuLkphY2tzb25AZXUuY2l0cml4LmNvbT46Cj4gU3Vy
ZSwgdGhhbmtzLiDCoEFuZCBzb3JyeSBhYm91dCB0aGUgaHVnZSBjb25mbGljdHMgeW91J3JlIHBy
b2JhYmx5Cj4gc2VlaW5nLi4uCgpJIHdpbGwgaGF2ZSB0byBzZW5kIHRoZSBzZXJpZXMgYWdhaW4s
IHNpbmNlIHRoZSBwdXNoIG9mIHRoZSBuZXcgY29kZQp3YXMgYWZ0ZXIgSSd2ZSBzdWJtaXR0ZWQg
dGhlIHBhdGNoZXMsIHNvcnJ5IGZvciB0aGUgZnVzcywgbGV0J3Mgc2VlIGlmCkkgY2FuIGZpbmlz
aCB0aGlzIHRvZGF5Li4uCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2Uu
Y29tCmh0dHA6Ly9saXN0cy54ZW5zb3VyY2UuY29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Tue Dec 13 13:38:33 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 13:38:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaSYX-0001MD-9f; Tue, 13 Dec 2011 13:38:05 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RaSYV-0001M6-Dk
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 13:38:03 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1323783428!7065176!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTI1NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27323 invoked from network); 13 Dec 2011 13:37:09 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 13:37:09 -0000
X-IronPort-AV: E=Sophos;i="4.71,345,1320624000"; 
   d="scan'208";a="9440845"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Dec 2011 13:37:08 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 13 Dec 2011 13:37:08 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
Date: Tue, 13 Dec 2011 13:37:08 +0000
In-Reply-To: <4EE75080.1000909@citrix.com>
References: <4EE675A8.3030609@niemail.de>	<4EE71663.5040308@gmail.com>
	<CAJeBh4sxdNTxM_oLFAuA6Mw75=LaYysrpS5b8NsZMbkf_swNVw@mail.gmail.com>
	<4EE72A94.6040904@gmail.com> <4EE75080.1000909@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323783428.20077.298.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	George Shuklin <george.shuklin@gmail.com>,
	"sandr8@gmail.com" <sandr8@gmail.com>
Subject: Re: [Xen-devel] a ton of kernel issues
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2011-12-13 at 13:17 +0000, David Vrabel wrote:
> On 13/12/11 10:36, George Shuklin wrote:
> > On 13.12.2011 14:19, Alessandro Salvatori wrote:
> >>
> >>> pv_ops is still have some issues with memory limits, but any
> >>> new kernel (3.0+) will boot normal and operates with very
> >>> minor glitches. Older pv_ops (f.e. debian 2.6.32) have some
> >>> more major issues.
> >> what glitches should one expect with 3.0+, and having the choice,
> >> would it be better to go with 3.1 or even 3.2?
> >>
> >>
> > Right now I know about two of them:
> > When you set up memory for virtual machine using xenballon, value in
> > dom0 differ from value in domU. The issue is that -xen kernels 'hide'
> > some memory in 'used' memory, and pv-ops just reducing TotalMem to value
> > without that memory. Practically that means if you set up memory for
> > domain to 2GiB client will saw only 1.95GiB and so on.
> 
> This really makes no practical difference.  The memory is "used" is
> either case and the different reporting is a side-effect of the change
> in how certain memory allocations are done.
> 
> > The second issue is lack of support of 'pre-inflated balloon', means you
> > can not set up memory-static-max to 2GiB, target to 1GiB and do 'memory
> > grow' from 1 G to 2 G latter without VM reboot. -xen kernels allow this
> > (up to memory-static-max limit).
> 
> This should work if memory hotplug is enabled.
> 
> It is also supported without memory hotplug but this requires that the
> tools supply a suitable memory map that covers the largest
> memory-static-max limit you wish to support.  I'm not sure if the tools
> can do this yet.

With xl this should work using the "maxmem" option. (xm probably uses
the same name)

Ian.

> 
> David
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 13:38:33 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 13:38:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaSYX-0001MD-9f; Tue, 13 Dec 2011 13:38:05 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RaSYV-0001M6-Dk
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 13:38:03 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1323783428!7065176!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTI1NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27323 invoked from network); 13 Dec 2011 13:37:09 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 13:37:09 -0000
X-IronPort-AV: E=Sophos;i="4.71,345,1320624000"; 
   d="scan'208";a="9440845"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Dec 2011 13:37:08 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 13 Dec 2011 13:37:08 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
Date: Tue, 13 Dec 2011 13:37:08 +0000
In-Reply-To: <4EE75080.1000909@citrix.com>
References: <4EE675A8.3030609@niemail.de>	<4EE71663.5040308@gmail.com>
	<CAJeBh4sxdNTxM_oLFAuA6Mw75=LaYysrpS5b8NsZMbkf_swNVw@mail.gmail.com>
	<4EE72A94.6040904@gmail.com> <4EE75080.1000909@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323783428.20077.298.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	George Shuklin <george.shuklin@gmail.com>,
	"sandr8@gmail.com" <sandr8@gmail.com>
Subject: Re: [Xen-devel] a ton of kernel issues
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2011-12-13 at 13:17 +0000, David Vrabel wrote:
> On 13/12/11 10:36, George Shuklin wrote:
> > On 13.12.2011 14:19, Alessandro Salvatori wrote:
> >>
> >>> pv_ops is still have some issues with memory limits, but any
> >>> new kernel (3.0+) will boot normal and operates with very
> >>> minor glitches. Older pv_ops (f.e. debian 2.6.32) have some
> >>> more major issues.
> >> what glitches should one expect with 3.0+, and having the choice,
> >> would it be better to go with 3.1 or even 3.2?
> >>
> >>
> > Right now I know about two of them:
> > When you set up memory for virtual machine using xenballon, value in
> > dom0 differ from value in domU. The issue is that -xen kernels 'hide'
> > some memory in 'used' memory, and pv-ops just reducing TotalMem to value
> > without that memory. Practically that means if you set up memory for
> > domain to 2GiB client will saw only 1.95GiB and so on.
> 
> This really makes no practical difference.  The memory is "used" is
> either case and the different reporting is a side-effect of the change
> in how certain memory allocations are done.
> 
> > The second issue is lack of support of 'pre-inflated balloon', means you
> > can not set up memory-static-max to 2GiB, target to 1GiB and do 'memory
> > grow' from 1 G to 2 G latter without VM reboot. -xen kernels allow this
> > (up to memory-static-max limit).
> 
> This should work if memory hotplug is enabled.
> 
> It is also supported without memory hotplug but this requires that the
> tools supply a suitable memory map that covers the largest
> memory-static-max limit you wish to support.  I'm not sure if the tools
> can do this yet.

With xl this should work using the "maxmem" option. (xm probably uses
the same name)

Ian.

> 
> David
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 13:39:57 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 13:39:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaSa2-0001R2-Pa; Tue, 13 Dec 2011 13:39:38 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1RaSa1-0001Qc-Vu
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 13:39:38 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1323783522!8070445!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjAzMzQ=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16113 invoked from network); 13 Dec 2011 13:38:43 -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;
	13 Dec 2011 13:38:43 -0000
X-IronPort-AV: E=Sophos;i="4.71,345,1320642000"; d="scan'208";a="173937151"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Dec 2011 08:38:42 -0500
Received: from [10.80.2.18] (10.80.2.18) by FTLPMAILMX02.citrite.net
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Tue, 13 Dec 2011
	08:38:42 -0500
Message-ID: <4EE75560.4090703@citrix.com>
Date: Tue, 13 Dec 2011 13:38:40 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.23) Gecko/20110921 Lightning/1.0b2 Thunderbird/3.1.15
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
X-Enigmail-Version: 1.1.2
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Keir Fraser <keir.xen@gmail.com>
Subject: [Xen-devel] headers.chk failing under certain circumstances.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hello,

Back in changeset 19772:aaab04808ee7, you introduced headers.chk to
check the header files for ansi conformance.

To fix the current 32/64bit interaction errors with the kexec
hypercalls, I need to use uint64_aligned_t as a datatype.  For the
normal compile, this is all fine, but as header.chk does not define
__XEN__ or __XEN_TOOLS__, the declaration of uint64_aligned_t is never
made, leading to the check failing.

There are other hypercall interfaces which use these datatypes: domctl,
sysctl and hvm_op, but these header files are explicitly filtered out
from the prerequisites for header.chk.  Given that uint64_aligned_t is a
sensible datatype to be using with the hypercall interface, fixing the
check seems to be the correct solution.

In your oppinion, which is the best course of action? To define __XEN__
or __XEN_TOOLS__ as part of the check (this throws up other errors as
part of the check process, suggesting that the header files are hiding
ansi non-conformance in certain blocks), or dont predicate the
definition of uint64_aligned_t on the presence of the above defines?

In addition, why are certain header files excluded from being checked? 
Does this imply that then should be fixed up to be ansi conformant as well?

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 13:39:57 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 13:39:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaSa2-0001R2-Pa; Tue, 13 Dec 2011 13:39:38 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1RaSa1-0001Qc-Vu
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 13:39:38 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1323783522!8070445!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjAzMzQ=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16113 invoked from network); 13 Dec 2011 13:38:43 -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;
	13 Dec 2011 13:38:43 -0000
X-IronPort-AV: E=Sophos;i="4.71,345,1320642000"; d="scan'208";a="173937151"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Dec 2011 08:38:42 -0500
Received: from [10.80.2.18] (10.80.2.18) by FTLPMAILMX02.citrite.net
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Tue, 13 Dec 2011
	08:38:42 -0500
Message-ID: <4EE75560.4090703@citrix.com>
Date: Tue, 13 Dec 2011 13:38:40 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.23) Gecko/20110921 Lightning/1.0b2 Thunderbird/3.1.15
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
X-Enigmail-Version: 1.1.2
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Keir Fraser <keir.xen@gmail.com>
Subject: [Xen-devel] headers.chk failing under certain circumstances.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hello,

Back in changeset 19772:aaab04808ee7, you introduced headers.chk to
check the header files for ansi conformance.

To fix the current 32/64bit interaction errors with the kexec
hypercalls, I need to use uint64_aligned_t as a datatype.  For the
normal compile, this is all fine, but as header.chk does not define
__XEN__ or __XEN_TOOLS__, the declaration of uint64_aligned_t is never
made, leading to the check failing.

There are other hypercall interfaces which use these datatypes: domctl,
sysctl and hvm_op, but these header files are explicitly filtered out
from the prerequisites for header.chk.  Given that uint64_aligned_t is a
sensible datatype to be using with the hypercall interface, fixing the
check seems to be the correct solution.

In your oppinion, which is the best course of action? To define __XEN__
or __XEN_TOOLS__ as part of the check (this throws up other errors as
part of the check process, suggesting that the header files are hiding
ansi non-conformance in certain blocks), or dont predicate the
definition of uint64_aligned_t on the presence of the above defines?

In addition, why are certain header files excluded from being checked? 
Does this imply that then should be fixed up to be ansi conformant as well?

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 13:41:51 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 13:41:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaSbs-0001ay-Fa; Tue, 13 Dec 2011 13:41:32 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RaSbr-0001aT-6O
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 13:41:31 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-4.tower-174.messagelabs.com!1323783634!5362002!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.5 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMDQ0MTE=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMDQ0MTE=\n,BODY_RANDOM_LONG
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21799 invoked from network); 13 Dec 2011 13:40:34 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-4.tower-174.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 13 Dec 2011 13:40:34 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1323783634; l=940;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=C5MkjwWvdvwZcLwOWjvxD/D/dF4=;
	b=YrnFskTxHlzXSMJtVmD4rVb4p296Fvs0JSO7pJ70lOjFcHqnn14N3Li2zwiur4KuhBr
	WW2DPWxlyBMiZo5hZmTpA4l8Q5fbCJbsgTZHPbBFQ2JhE6+jvh4YhNgfkdALIAmayE16Q
	YG05StYNKNyDF7PhMAS5XCqJe5iUofOfk1E=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFPjzIQEqWbbQ==
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-111-180.pools.arcor-ip.net [88.65.111.180])
	by smtp.strato.de (fruni mo24) (RZmta 26.15 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id v03bc5nBDCsMsf ;
	Tue, 13 Dec 2011 14:40:17 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id AF2B118637; Tue, 13 Dec 2011 14:40:16 +0100 (CET)
Date: Tue, 13 Dec 2011 14:40:16 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20111213134016.GA20700@aepfle.de>
References: <mailman.3873.1323460242.12970.xen-devel@lists.xensource.com>
	<449af29a31a68b8381c2ea83ee08af52.squirrel@webmail.lagarcavilla.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <449af29a31a68b8381c2ea83ee08af52.squirrel@webmail.lagarcavilla.org>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: xen-devel@lists.xensource.com, tim@xen.org
Subject: Re: [Xen-devel] [PATCH] mem_event: use wait queue when ring is full
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Dec 09, Andres Lagar-Cavilla wrote:

> Olaf,
> Tim pointed out we need both solutions to ring management in the
> hypervisor. With our patch ("Improve ring management for memory events. Do
> not lose guest events."), we can handle the common case quickly, without
> preempting VMs. With your patch, we can handle extreme situations of ring
> congestion with the big hammer called wait queue.

With my patch the requests get processed as they come in, both foreign
and target requests get handled equally. There is no special accounting.

A few questions about your requirements:
- Is the goal is that each guest vcpu can always put at least one request?
- How many requests should foreign vcpus place in the ring if the guest
  has more vcpus than available slots in the ring? Just a single one so
  that foreigners can also make some progress?
- Should access and paging have the same rules for accounting?

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 13:41:51 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 13:41:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaSbs-0001ay-Fa; Tue, 13 Dec 2011 13:41:32 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RaSbr-0001aT-6O
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 13:41:31 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-4.tower-174.messagelabs.com!1323783634!5362002!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.5 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMDQ0MTE=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMDQ0MTE=\n,BODY_RANDOM_LONG
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21799 invoked from network); 13 Dec 2011 13:40:34 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-4.tower-174.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 13 Dec 2011 13:40:34 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1323783634; l=940;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=C5MkjwWvdvwZcLwOWjvxD/D/dF4=;
	b=YrnFskTxHlzXSMJtVmD4rVb4p296Fvs0JSO7pJ70lOjFcHqnn14N3Li2zwiur4KuhBr
	WW2DPWxlyBMiZo5hZmTpA4l8Q5fbCJbsgTZHPbBFQ2JhE6+jvh4YhNgfkdALIAmayE16Q
	YG05StYNKNyDF7PhMAS5XCqJe5iUofOfk1E=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFPjzIQEqWbbQ==
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-111-180.pools.arcor-ip.net [88.65.111.180])
	by smtp.strato.de (fruni mo24) (RZmta 26.15 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id v03bc5nBDCsMsf ;
	Tue, 13 Dec 2011 14:40:17 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id AF2B118637; Tue, 13 Dec 2011 14:40:16 +0100 (CET)
Date: Tue, 13 Dec 2011 14:40:16 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20111213134016.GA20700@aepfle.de>
References: <mailman.3873.1323460242.12970.xen-devel@lists.xensource.com>
	<449af29a31a68b8381c2ea83ee08af52.squirrel@webmail.lagarcavilla.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <449af29a31a68b8381c2ea83ee08af52.squirrel@webmail.lagarcavilla.org>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: xen-devel@lists.xensource.com, tim@xen.org
Subject: Re: [Xen-devel] [PATCH] mem_event: use wait queue when ring is full
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Dec 09, Andres Lagar-Cavilla wrote:

> Olaf,
> Tim pointed out we need both solutions to ring management in the
> hypervisor. With our patch ("Improve ring management for memory events. Do
> not lose guest events."), we can handle the common case quickly, without
> preempting VMs. With your patch, we can handle extreme situations of ring
> congestion with the big hammer called wait queue.

With my patch the requests get processed as they come in, both foreign
and target requests get handled equally. There is no special accounting.

A few questions about your requirements:
- Is the goal is that each guest vcpu can always put at least one request?
- How many requests should foreign vcpus place in the ring if the guest
  has more vcpus than available slots in the ring? Just a single one so
  that foreigners can also make some progress?
- Should access and paging have the same rules for accounting?

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 13:55:58 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 13:55:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaSpT-0001sm-Tz; Tue, 13 Dec 2011 13:55:35 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RaSpS-0001sh-3H
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 13:55:34 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1323784479!7009765!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4419 invoked from network); 13 Dec 2011 13:54:40 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-15.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 13 Dec 2011 13:54:40 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 13 Dec 2011 13:54:39 +0000
Message-Id: <4EE7672902000078000674D4@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 13 Dec 2011 13:54:33 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Stefano Stabellini" <stefano.stabellini@eu.citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: [Xen-devel] map_domain_emuirq_pirq() imbalance with
 unmap_domain_pirq_emuirq()?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi Stefano,

in your patch to introduce pIRQ interrupt remapping for HVM guests,
you have physdev_map_pirq() call unmap_domain_pirq_emuirq()
unconditionally in the HVM case, yet physdev_hvm_map_pirq() call
map_domain_emuirq_pirq() only if no machine_gsi was found. I'm
suspecting this to be the reason for pass-through device hot unplug
resource leaks (leading eventually to hot plug failure on repeated
attempts), as in this case it is my understanding that
unmap_domain_pirq_emuirq() can only be expected to fail (for there
not being an established mapping), leading to physdev_unmap_pirq()
bailing out early.

As it's not immediately clear whether using the same lookup approach
that physdev_hvm_map_pirq() uses would be valid in the unmap path,
I'm hoping for your advice how to address this problem. Is there
perhaps a map_domain_emuirq_pirq(..., IRQ_PT) call missing?

Besides that, in 23806:4226ea1785b5 you move a call to
map_domain_emuirq_pirq() from xen/arch/x86/physdev.c to
xen/common/event_channel.c, but neither before nor after the patch
the function's return value gets checked, yet the function has various
ways to fail. Is failure here really benign?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 13:55:58 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 13:55:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaSpT-0001sm-Tz; Tue, 13 Dec 2011 13:55:35 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RaSpS-0001sh-3H
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 13:55:34 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1323784479!7009765!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4419 invoked from network); 13 Dec 2011 13:54:40 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-15.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 13 Dec 2011 13:54:40 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 13 Dec 2011 13:54:39 +0000
Message-Id: <4EE7672902000078000674D4@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 13 Dec 2011 13:54:33 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Stefano Stabellini" <stefano.stabellini@eu.citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: [Xen-devel] map_domain_emuirq_pirq() imbalance with
 unmap_domain_pirq_emuirq()?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi Stefano,

in your patch to introduce pIRQ interrupt remapping for HVM guests,
you have physdev_map_pirq() call unmap_domain_pirq_emuirq()
unconditionally in the HVM case, yet physdev_hvm_map_pirq() call
map_domain_emuirq_pirq() only if no machine_gsi was found. I'm
suspecting this to be the reason for pass-through device hot unplug
resource leaks (leading eventually to hot plug failure on repeated
attempts), as in this case it is my understanding that
unmap_domain_pirq_emuirq() can only be expected to fail (for there
not being an established mapping), leading to physdev_unmap_pirq()
bailing out early.

As it's not immediately clear whether using the same lookup approach
that physdev_hvm_map_pirq() uses would be valid in the unmap path,
I'm hoping for your advice how to address this problem. Is there
perhaps a map_domain_emuirq_pirq(..., IRQ_PT) call missing?

Besides that, in 23806:4226ea1785b5 you move a call to
map_domain_emuirq_pirq() from xen/arch/x86/physdev.c to
xen/common/event_channel.c, but neither before nor after the patch
the function's return value gets checked, yet the function has various
ways to fail. Is failure here really benign?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 13:59:01 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 13:59:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaSsY-0001yn-Hb; Tue, 13 Dec 2011 13:58:46 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RaSsX-0001yY-0J
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 13:58:45 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1323784670!7070931!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTI1NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5198 invoked from network); 13 Dec 2011 13:57:51 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 13:57:51 -0000
X-IronPort-AV: E=Sophos;i="4.71,345,1320624000"; 
   d="scan'208";a="9441412"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Dec 2011 13:57:50 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 13 Dec 2011 13:57:50 +0000
Date: Tue, 13 Dec 2011 13:59:33 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Jan Kiszka <jan.kiszka@siemens.com>
In-Reply-To: <4EE74684.7010708@siemens.com>
Message-ID: <alpine.DEB.2.00.1112131358160.3517@kaball-desktop>
References: <1323467645-24271-1-git-send-email-anthony.perard@citrix.com>
	<1323467645-24271-6-git-send-email-anthony.perard@citrix.com>
	<4EE3382D.80903@web.de>
	<alpine.DEB.2.00.1112121259180.3517@kaball-desktop>
	<4EE609BF.1070307@siemens.com>
	<alpine.DEB.2.00.1112121438410.3517@kaball-desktop>
	<4EE617BA.4030102@siemens.com>
	<alpine.DEB.2.00.1112121527130.3517@kaball-desktop>
	<alpine.DEB.2.00.1112131141170.3517@kaball-desktop>
	<4EE74684.7010708@siemens.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Anthony Perard <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	QEMU-devel <qemu-devel@nongnu.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] early_savevm
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 13 Dec 2011, Jan Kiszka wrote:
> On 2011-12-13 12:55, Stefano Stabellini wrote:
> > On Mon, 12 Dec 2011, Stefano Stabellini wrote:
> >>> Really, I think this is something inherently incompatible with the
> >>> current memory API. If Xen has this unfixable special "requirement"
> >>> (it's rather a design issue IMHO), adjust the API and adapt all devices.
> >>> Hot-fixing only a single one this way is no good idea long term.
> >>
> >> Fair enough.
> >> What about introducing a type of savevm state that is going to be
> >> restored before machine->init?
> >> This way we could save and restore our physmap and we could handle
> >> memory maps and allocations transparently.
> >>
> > 
> > A bit more context to my suggestion:
> > 
> > - we open the save state file and check the magic number and the
> > version number before machine->init();
> > 
> > - we add a new set of entries to the save state file that contains
> > early_savevm functions: they are called before machine->init();
> > 
> > - after reaching the end of the early_savevm functions we stop parsing
> > the save state file and we call machine->init();
> > 
> > - after machine->init() is completed we continue parsing the save state
> > file as usual.
> 
> Hmm, just wondering if another use case for this early incoming
> migration step is transferring the machine configuration so that the
> receiver need not worry about synchronizing it out of band. That may
> help motivating this likely not trivial change.

Actually I was thinking the same thing. I am sure that if we had such a
thing as early_savevm, a few other use cases will certainly show up.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 13:59:01 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 13:59:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaSsY-0001yn-Hb; Tue, 13 Dec 2011 13:58:46 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RaSsX-0001yY-0J
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 13:58:45 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1323784670!7070931!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTI1NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5198 invoked from network); 13 Dec 2011 13:57:51 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 13:57:51 -0000
X-IronPort-AV: E=Sophos;i="4.71,345,1320624000"; 
   d="scan'208";a="9441412"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Dec 2011 13:57:50 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 13 Dec 2011 13:57:50 +0000
Date: Tue, 13 Dec 2011 13:59:33 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Jan Kiszka <jan.kiszka@siemens.com>
In-Reply-To: <4EE74684.7010708@siemens.com>
Message-ID: <alpine.DEB.2.00.1112131358160.3517@kaball-desktop>
References: <1323467645-24271-1-git-send-email-anthony.perard@citrix.com>
	<1323467645-24271-6-git-send-email-anthony.perard@citrix.com>
	<4EE3382D.80903@web.de>
	<alpine.DEB.2.00.1112121259180.3517@kaball-desktop>
	<4EE609BF.1070307@siemens.com>
	<alpine.DEB.2.00.1112121438410.3517@kaball-desktop>
	<4EE617BA.4030102@siemens.com>
	<alpine.DEB.2.00.1112121527130.3517@kaball-desktop>
	<alpine.DEB.2.00.1112131141170.3517@kaball-desktop>
	<4EE74684.7010708@siemens.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Anthony Perard <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	QEMU-devel <qemu-devel@nongnu.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] early_savevm
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 13 Dec 2011, Jan Kiszka wrote:
> On 2011-12-13 12:55, Stefano Stabellini wrote:
> > On Mon, 12 Dec 2011, Stefano Stabellini wrote:
> >>> Really, I think this is something inherently incompatible with the
> >>> current memory API. If Xen has this unfixable special "requirement"
> >>> (it's rather a design issue IMHO), adjust the API and adapt all devices.
> >>> Hot-fixing only a single one this way is no good idea long term.
> >>
> >> Fair enough.
> >> What about introducing a type of savevm state that is going to be
> >> restored before machine->init?
> >> This way we could save and restore our physmap and we could handle
> >> memory maps and allocations transparently.
> >>
> > 
> > A bit more context to my suggestion:
> > 
> > - we open the save state file and check the magic number and the
> > version number before machine->init();
> > 
> > - we add a new set of entries to the save state file that contains
> > early_savevm functions: they are called before machine->init();
> > 
> > - after reaching the end of the early_savevm functions we stop parsing
> > the save state file and we call machine->init();
> > 
> > - after machine->init() is completed we continue parsing the save state
> > file as usual.
> 
> Hmm, just wondering if another use case for this early incoming
> migration step is transferring the machine configuration so that the
> receiver need not worry about synchronizing it out of band. That may
> help motivating this likely not trivial change.

Actually I was thinking the same thing. I am sure that if we had such a
thing as early_savevm, a few other use cases will certainly show up.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 14:00:24 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 14:00:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaStp-000284-1M; Tue, 13 Dec 2011 14:00:05 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RaStn-00024L-Ec
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 14:00:03 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1323784749!7246402!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTI1NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7240 invoked from network); 13 Dec 2011 13:59:09 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 13:59:09 -0000
X-IronPort-AV: E=Sophos;i="4.71,345,1320624000"; 
   d="scan'208";a="9441447"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Dec 2011 13:59:09 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 13 Dec 2011 13:59:08 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Tue, 13 Dec 2011 13:59:08 +0000
In-Reply-To: <alpine.DEB.2.00.1112121613330.3517@kaball-desktop>
References: <1323108621-22654-1-git-send-email-ian.jackson@eu.citrix.com>
	<1323108621-22654-16-git-send-email-ian.jackson@eu.citrix.com>
	<alpine.DEB.2.00.1112091558300.3517@kaball-desktop>
	<20194.22539.574524.956955@mariner.uk.xensource.com>
	<1323463293.20936.11.camel@dagon.hellion.org.uk>
	<20197.59428.699013.507183@mariner.uk.xensource.com>
	<1323692225.20077.183.camel@zakaz.uk.xensource.com>
	<20197.62462.189827.239656@mariner.uk.xensource.com>
	<1323697723.20077.212.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1112121453050.3517@kaball-desktop>
	<20198.9737.680162.103418@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1112121613330.3517@kaball-desktop>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323784748.20077.304.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 15/15] libxl: New event generation API
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2011-12-12 at 19:24 +0000, Stefano Stabellini wrote:
> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> index cd613f7..94bdbba 100644
> --- a/tools/libxl/libxl.c
> +++ b/tools/libxl/libxl.c
> @@ -63,6 +63,12 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
>       * only as an initialiser, not as an expression. */
>      memcpy(&ctx->lock, &mutex_value, sizeof(ctx->lock));
>  
> +    if(pthread_key_create(&ctx->tls_key, NULL) < 0) {
> +        LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, errno,
> +            "cannot create tls key");
> +        return ERROR_FAIL;

You need a corresponding pthread_key_delete in the free function.

> [...]

> @@ -65,17 +66,41 @@ int libxl__ptr_add(libxl__gc *gc, void *ptr)
>      return 0;
>  }
>  
> +libxl__gc *libxl__init_gc(libxl_ctx *ctx)
> +{
> +    libxl__gc *gc = (libxl__gc *) pthread_getspecific(ctx->tls_key);
> +    if (gc == NULL) {
> +        gc = (libxl__gc *) malloc(sizeof(libxl__gc));
> +        if (gc == NULL)
> +            return NULL;
> +        gc->alloc_maxsize = 0;
> +        gc->alloc_ptrs = 0;
> +        gc->owner = ctx;
> +        gc->nested = 1;
> +        pthread_setspecific(ctx->tls_key, gc);

pthread_setspecific can fail. 

> [...]

>  void libxl__free_all(libxl__gc *gc)
>  {
>      void *ptr;
>      int i;
>  
> +    gc->nested--;
> +    if (gc->nested > 0)
> +        return;
> +
>      for (i = 0; i < gc->alloc_maxsize; i++) {
>          ptr = gc->alloc_ptrs[i];
>          gc->alloc_ptrs[i] = NULL;
>          free(ptr);
>      }
>      free(gc->alloc_ptrs);
> +    pthread_setspecific(CTX->tls_key, NULL);

As above this can also fail. I think this one might be a bit harder to
deal with in general.

> +    free(gc);
>  }
>  

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 14:00:24 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 14:00:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaStp-000284-1M; Tue, 13 Dec 2011 14:00:05 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RaStn-00024L-Ec
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 14:00:03 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1323784749!7246402!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTI1NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7240 invoked from network); 13 Dec 2011 13:59:09 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 13:59:09 -0000
X-IronPort-AV: E=Sophos;i="4.71,345,1320624000"; 
   d="scan'208";a="9441447"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Dec 2011 13:59:09 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 13 Dec 2011 13:59:08 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Tue, 13 Dec 2011 13:59:08 +0000
In-Reply-To: <alpine.DEB.2.00.1112121613330.3517@kaball-desktop>
References: <1323108621-22654-1-git-send-email-ian.jackson@eu.citrix.com>
	<1323108621-22654-16-git-send-email-ian.jackson@eu.citrix.com>
	<alpine.DEB.2.00.1112091558300.3517@kaball-desktop>
	<20194.22539.574524.956955@mariner.uk.xensource.com>
	<1323463293.20936.11.camel@dagon.hellion.org.uk>
	<20197.59428.699013.507183@mariner.uk.xensource.com>
	<1323692225.20077.183.camel@zakaz.uk.xensource.com>
	<20197.62462.189827.239656@mariner.uk.xensource.com>
	<1323697723.20077.212.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1112121453050.3517@kaball-desktop>
	<20198.9737.680162.103418@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1112121613330.3517@kaball-desktop>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323784748.20077.304.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 15/15] libxl: New event generation API
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2011-12-12 at 19:24 +0000, Stefano Stabellini wrote:
> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> index cd613f7..94bdbba 100644
> --- a/tools/libxl/libxl.c
> +++ b/tools/libxl/libxl.c
> @@ -63,6 +63,12 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
>       * only as an initialiser, not as an expression. */
>      memcpy(&ctx->lock, &mutex_value, sizeof(ctx->lock));
>  
> +    if(pthread_key_create(&ctx->tls_key, NULL) < 0) {
> +        LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, errno,
> +            "cannot create tls key");
> +        return ERROR_FAIL;

You need a corresponding pthread_key_delete in the free function.

> [...]

> @@ -65,17 +66,41 @@ int libxl__ptr_add(libxl__gc *gc, void *ptr)
>      return 0;
>  }
>  
> +libxl__gc *libxl__init_gc(libxl_ctx *ctx)
> +{
> +    libxl__gc *gc = (libxl__gc *) pthread_getspecific(ctx->tls_key);
> +    if (gc == NULL) {
> +        gc = (libxl__gc *) malloc(sizeof(libxl__gc));
> +        if (gc == NULL)
> +            return NULL;
> +        gc->alloc_maxsize = 0;
> +        gc->alloc_ptrs = 0;
> +        gc->owner = ctx;
> +        gc->nested = 1;
> +        pthread_setspecific(ctx->tls_key, gc);

pthread_setspecific can fail. 

> [...]

>  void libxl__free_all(libxl__gc *gc)
>  {
>      void *ptr;
>      int i;
>  
> +    gc->nested--;
> +    if (gc->nested > 0)
> +        return;
> +
>      for (i = 0; i < gc->alloc_maxsize; i++) {
>          ptr = gc->alloc_ptrs[i];
>          gc->alloc_ptrs[i] = NULL;
>          free(ptr);
>      }
>      free(gc->alloc_ptrs);
> +    pthread_setspecific(CTX->tls_key, NULL);

As above this can also fail. I think this one might be a bit harder to
deal with in general.

> +    free(gc);
>  }
>  

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 14:09:53 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 14:09:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaT35-0002bA-47; Tue, 13 Dec 2011 14:09:39 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RaT32-0002az-PC
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 14:09:37 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1323785322!5381008!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTI1NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3624 invoked from network); 13 Dec 2011 14:08:42 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 14:08:42 -0000
X-IronPort-AV: E=Sophos;i="4.71,345,1320624000"; 
   d="scan'208";a="9441848"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Dec 2011 14:07:40 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 13 Dec 2011 14:07:40 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 13 Dec 2011 14:07:40 +0000
In-Reply-To: <20199.14342.599850.739029@mariner.uk.xensource.com>
References: <osstest-10481-mainreport@xen.org>
	<1323769464.20077.262.camel@zakaz.uk.xensource.com>
	<20199.14342.599850.739029@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323785260.20077.307.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [xen-unstable test] 10481: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2011-12-13 at 11:33 +0000, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [xen-unstable test] 10481: regressions - FAIL"):
> > I think "xl trigger <dom> power" would be what is wanted here -- e.g.
> > send an ACPI power event. It could be argued that xl shutdown could do
> > this automatically?
> 
> libxl_domain_shutdown should do it automatically for HVM guests with
> no PV drivers.

I was about half way through implementing this when it occurred to me
that the reaction to a power button press is a guest OS option and can
result in a shutdown, a reboot or even a suspend.

Unless I'm mistaken?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 14:09:53 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 14:09:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaT35-0002bA-47; Tue, 13 Dec 2011 14:09:39 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RaT32-0002az-PC
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 14:09:37 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1323785322!5381008!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTI1NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3624 invoked from network); 13 Dec 2011 14:08:42 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 14:08:42 -0000
X-IronPort-AV: E=Sophos;i="4.71,345,1320624000"; 
   d="scan'208";a="9441848"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Dec 2011 14:07:40 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 13 Dec 2011 14:07:40 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 13 Dec 2011 14:07:40 +0000
In-Reply-To: <20199.14342.599850.739029@mariner.uk.xensource.com>
References: <osstest-10481-mainreport@xen.org>
	<1323769464.20077.262.camel@zakaz.uk.xensource.com>
	<20199.14342.599850.739029@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323785260.20077.307.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [xen-unstable test] 10481: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2011-12-13 at 11:33 +0000, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [xen-unstable test] 10481: regressions - FAIL"):
> > I think "xl trigger <dom> power" would be what is wanted here -- e.g.
> > send an ACPI power event. It could be argued that xl shutdown could do
> > this automatically?
> 
> libxl_domain_shutdown should do it automatically for HVM guests with
> no PV drivers.

I was about half way through implementing this when it occurred to me
that the reaction to a power button press is a guest OS option and can
result in a shutdown, a reboot or even a suspend.

Unless I'm mistaken?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 14:16:10 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 14:16:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaT97-0002p8-3j; Tue, 13 Dec 2011 14:15:53 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RaT95-0002ou-RT
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 14:15:52 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1323785697!7075048!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTI1NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23507 invoked from network); 13 Dec 2011 14:14:57 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 14:14:57 -0000
X-IronPort-AV: E=Sophos;i="4.71,345,1320624000"; 
   d="scan'208";a="9442043"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Dec 2011 14:14:57 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 13 Dec 2011 14:14:56 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RaT8C-0006zh-JH; Tue, 13 Dec 2011 14:14:56 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RaT8C-0002Pc-IK;
	Tue, 13 Dec 2011 14:14:56 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20199.24032.555383.178696@mariner.uk.xensource.com>
Date: Tue, 13 Dec 2011 14:14:56 +0000
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
In-Reply-To: <alpine.DEB.2.00.1112121613330.3517@kaball-desktop>
References: <1323108621-22654-1-git-send-email-ian.jackson@eu.citrix.com>
	<1323108621-22654-16-git-send-email-ian.jackson@eu.citrix.com>
	<alpine.DEB.2.00.1112091558300.3517@kaball-desktop>
	<20194.22539.574524.956955@mariner.uk.xensource.com>
	<1323463293.20936.11.camel@dagon.hellion.org.uk>
	<20197.59428.699013.507183@mariner.uk.xensource.com>
	<1323692225.20077.183.camel@zakaz.uk.xensource.com>
	<20197.62462.189827.239656@mariner.uk.xensource.com>
	<1323697723.20077.212.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1112121453050.3517@kaball-desktop>
	<20198.9737.680162.103418@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1112121613330.3517@kaball-desktop>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH 15/15] libxl: New event generation API
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Stefano Stabellini writes ("Re: [Xen-devel] [PATCH 15/15] libxl: New event generation API"):
> +#define GC_INIT(ctx)  libxl__gc *gc = libxl__init_gc(ctx); if (gc == NULL) return ERROR_NOMEM;

I think we should avoid macros which return from their containing
function, unless they are unavoidable.

Only event-generating libxl entrypoints need to know about the special
rules for handling the lock and ctx.  The set of event-generating
entrypoints to libxl is bounded - they are all part of the event
generation core.

Also, what you are doing here complicates the usual, simple, case.
I would prefer to keep the case that can be simple, simple.

So I think in this case it is better to document the restrictions
rather than try to abolish them with additional behind-the-scenes
machinery.

See also Ian C's comments.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 14:16:10 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 14:16:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaT97-0002p8-3j; Tue, 13 Dec 2011 14:15:53 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RaT95-0002ou-RT
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 14:15:52 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1323785697!7075048!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTI1NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23507 invoked from network); 13 Dec 2011 14:14:57 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 14:14:57 -0000
X-IronPort-AV: E=Sophos;i="4.71,345,1320624000"; 
   d="scan'208";a="9442043"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Dec 2011 14:14:57 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 13 Dec 2011 14:14:56 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RaT8C-0006zh-JH; Tue, 13 Dec 2011 14:14:56 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RaT8C-0002Pc-IK;
	Tue, 13 Dec 2011 14:14:56 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20199.24032.555383.178696@mariner.uk.xensource.com>
Date: Tue, 13 Dec 2011 14:14:56 +0000
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
In-Reply-To: <alpine.DEB.2.00.1112121613330.3517@kaball-desktop>
References: <1323108621-22654-1-git-send-email-ian.jackson@eu.citrix.com>
	<1323108621-22654-16-git-send-email-ian.jackson@eu.citrix.com>
	<alpine.DEB.2.00.1112091558300.3517@kaball-desktop>
	<20194.22539.574524.956955@mariner.uk.xensource.com>
	<1323463293.20936.11.camel@dagon.hellion.org.uk>
	<20197.59428.699013.507183@mariner.uk.xensource.com>
	<1323692225.20077.183.camel@zakaz.uk.xensource.com>
	<20197.62462.189827.239656@mariner.uk.xensource.com>
	<1323697723.20077.212.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1112121453050.3517@kaball-desktop>
	<20198.9737.680162.103418@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1112121613330.3517@kaball-desktop>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH 15/15] libxl: New event generation API
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Stefano Stabellini writes ("Re: [Xen-devel] [PATCH 15/15] libxl: New event generation API"):
> +#define GC_INIT(ctx)  libxl__gc *gc = libxl__init_gc(ctx); if (gc == NULL) return ERROR_NOMEM;

I think we should avoid macros which return from their containing
function, unless they are unavoidable.

Only event-generating libxl entrypoints need to know about the special
rules for handling the lock and ctx.  The set of event-generating
entrypoints to libxl is bounded - they are all part of the event
generation core.

Also, what you are doing here complicates the usual, simple, case.
I would prefer to keep the case that can be simple, simple.

So I think in this case it is better to document the restrictions
rather than try to abolish them with additional behind-the-scenes
machinery.

See also Ian C's comments.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 14:17:37 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 14:17:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaTAV-0002u4-KT; Tue, 13 Dec 2011 14:17:19 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RaTAT-0002tg-Rn
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 14:17:18 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1323785783!5179720!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTI1NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30447 invoked from network); 13 Dec 2011 14:16:23 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 14:16:23 -0000
X-IronPort-AV: E=Sophos;i="4.71,345,1320624000"; 
   d="scan'208";a="9442087"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Dec 2011 14:16:22 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 13 Dec 2011 14:16:22 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RaT9a-00070J-GG; Tue, 13 Dec 2011 14:16:22 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RaT9a-0002Pm-FQ;
	Tue, 13 Dec 2011 14:16:22 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20199.24118.465585.933183@mariner.uk.xensource.com>
Date: Tue, 13 Dec 2011 14:16:22 +0000
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
In-Reply-To: <alpine.DEB.2.00.1112121924520.3517@kaball-desktop>
References: <alpine.DEB.2.00.1111221551510.31179@kaball-desktop>
	<1322056320-5826-5-git-send-email-stefano.stabellini@eu.citrix.com>
	<20198.15417.932169.223332@mariner.uk.xensource.com>
	<1323712001.20077.234.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1112121924520.3517@kaball-desktop>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH v9 5/6] Clone and build Seabios by default
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Stefano Stabellini writes ("Re: [Xen-devel] [PATCH v9 5/6] Clone and build Seabios by default"):
> On Mon, 12 Dec 2011, Ian Campbell wrote:
> > On Mon, 2011-12-12 at 17:39 +0000, Ian Jackson wrote:
> > > I see you have included a lockstep changeset number in xen-unstable
> > > but are we really able to force these to update in lockstep ?

Did you have an answer for this ?

> > We should have a mirror on xenbits, we generally avoid reliance on third
> > party resources in our builds. Not just source repositories but also for
> > things like tarball downloads.
> > 
> > Also the upstream for seabios is git://git.seabios.org/seabios.git I
> > don't think indirecting via qemu buys us anything.
>  
> I don't have a strong opinion on this, so if you'd like to change the
> url to a xenbits tree, I am OK with that.
> I guess you don't need me to send a patch for that, but let me know if
> you want me to change something.

I agree with Ian's comments about using xenbits.

But before you set up any trees there, please let's answer the
question about our update paradigm.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 14:17:37 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 14:17:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaTAV-0002u4-KT; Tue, 13 Dec 2011 14:17:19 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RaTAT-0002tg-Rn
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 14:17:18 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1323785783!5179720!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTI1NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30447 invoked from network); 13 Dec 2011 14:16:23 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 14:16:23 -0000
X-IronPort-AV: E=Sophos;i="4.71,345,1320624000"; 
   d="scan'208";a="9442087"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Dec 2011 14:16:22 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 13 Dec 2011 14:16:22 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RaT9a-00070J-GG; Tue, 13 Dec 2011 14:16:22 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RaT9a-0002Pm-FQ;
	Tue, 13 Dec 2011 14:16:22 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20199.24118.465585.933183@mariner.uk.xensource.com>
Date: Tue, 13 Dec 2011 14:16:22 +0000
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
In-Reply-To: <alpine.DEB.2.00.1112121924520.3517@kaball-desktop>
References: <alpine.DEB.2.00.1111221551510.31179@kaball-desktop>
	<1322056320-5826-5-git-send-email-stefano.stabellini@eu.citrix.com>
	<20198.15417.932169.223332@mariner.uk.xensource.com>
	<1323712001.20077.234.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1112121924520.3517@kaball-desktop>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH v9 5/6] Clone and build Seabios by default
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Stefano Stabellini writes ("Re: [Xen-devel] [PATCH v9 5/6] Clone and build Seabios by default"):
> On Mon, 12 Dec 2011, Ian Campbell wrote:
> > On Mon, 2011-12-12 at 17:39 +0000, Ian Jackson wrote:
> > > I see you have included a lockstep changeset number in xen-unstable
> > > but are we really able to force these to update in lockstep ?

Did you have an answer for this ?

> > We should have a mirror on xenbits, we generally avoid reliance on third
> > party resources in our builds. Not just source repositories but also for
> > things like tarball downloads.
> > 
> > Also the upstream for seabios is git://git.seabios.org/seabios.git I
> > don't think indirecting via qemu buys us anything.
>  
> I don't have a strong opinion on this, so if you'd like to change the
> url to a xenbits tree, I am OK with that.
> I guess you don't need me to send a patch for that, but let me know if
> you want me to change something.

I agree with Ian's comments about using xenbits.

But before you set up any trees there, please let's answer the
question about our update paradigm.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 14:18:34 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 14:18:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaTBU-0002zq-3B; Tue, 13 Dec 2011 14:18:20 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RaTBR-0002yz-OY
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 14:18:17 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1323785824!58755699!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23103 invoked from network); 13 Dec 2011 14:17:05 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-15.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 13 Dec 2011 14:17:05 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 13 Dec 2011 14:17:22 +0000
Message-Id: <4EE76C7E0200007800067541@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 13 Dec 2011 14:17:18 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>
References: <4EE75560.4090703@citrix.com>
In-Reply-To: <4EE75560.4090703@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: KeirFraser <keir.xen@gmail.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] headers.chk failing under certain circumstances.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 13.12.11 at 14:38, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
> To fix the current 32/64bit interaction errors with the kexec
> hypercalls, I need to use uint64_aligned_t as a datatype.  For the
> normal compile, this is all fine, but as header.chk does not define
> __XEN__ or __XEN_TOOLS__, the declaration of uint64_aligned_t is never
> made, leading to the check failing.
> 
> There are other hypercall interfaces which use these datatypes: domctl,
> sysctl and hvm_op, but these header files are explicitly filtered out
> from the prerequisites for header.chk.

This is really intentional for the domctl and sysctl cases - these are
"internal" interfaces (between the tools and the hypervisor), and
hence can be more relaxed in style.

Pretty much the same goes for the hvm op definitions - we simply
assume that users of this use a compiler capable of dealing with this
(I'm not fully convinced this is The Right Thing To Do, but it's the
status quo at least).

> Given that uint64_aligned_t is a
> sensible datatype to be using with the hypercall interface, fixing the
> check seems to be the correct solution.

Sensible or not, you would have to find a way to define such a type
in a compiler-independent (i.e. ANSI conforming) manner, and I'm
afraid you won't be able to.

> In your oppinion, which is the best course of action? To define __XEN__
> or __XEN_TOOLS__ as part of the check (this throws up other errors as
> part of the check process, suggesting that the header files are hiding
> ansi non-conformance in certain blocks), or dont predicate the
> definition of uint64_aligned_t on the presence of the above defines?

__XEN__ and __XEN_TOOLS__ must specifically not be defined for
these checks (and these symbols indeed get used to frame certain
definitions that are considered "internal" as outlined above - obviously,
by framing any definition this way we hide them from "foreign"
consumers *and* the [pointless in this case] style checking).

So bottom line is - no, you can't use uint64_aligned_t as much as any
other non-ANSI extension. Preventing anyone to try is what the
check was introduced for.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 14:18:34 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 14:18:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaTBU-0002zq-3B; Tue, 13 Dec 2011 14:18:20 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RaTBR-0002yz-OY
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 14:18:17 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1323785824!58755699!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23103 invoked from network); 13 Dec 2011 14:17:05 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-15.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 13 Dec 2011 14:17:05 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 13 Dec 2011 14:17:22 +0000
Message-Id: <4EE76C7E0200007800067541@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 13 Dec 2011 14:17:18 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>
References: <4EE75560.4090703@citrix.com>
In-Reply-To: <4EE75560.4090703@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: KeirFraser <keir.xen@gmail.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] headers.chk failing under certain circumstances.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 13.12.11 at 14:38, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
> To fix the current 32/64bit interaction errors with the kexec
> hypercalls, I need to use uint64_aligned_t as a datatype.  For the
> normal compile, this is all fine, but as header.chk does not define
> __XEN__ or __XEN_TOOLS__, the declaration of uint64_aligned_t is never
> made, leading to the check failing.
> 
> There are other hypercall interfaces which use these datatypes: domctl,
> sysctl and hvm_op, but these header files are explicitly filtered out
> from the prerequisites for header.chk.

This is really intentional for the domctl and sysctl cases - these are
"internal" interfaces (between the tools and the hypervisor), and
hence can be more relaxed in style.

Pretty much the same goes for the hvm op definitions - we simply
assume that users of this use a compiler capable of dealing with this
(I'm not fully convinced this is The Right Thing To Do, but it's the
status quo at least).

> Given that uint64_aligned_t is a
> sensible datatype to be using with the hypercall interface, fixing the
> check seems to be the correct solution.

Sensible or not, you would have to find a way to define such a type
in a compiler-independent (i.e. ANSI conforming) manner, and I'm
afraid you won't be able to.

> In your oppinion, which is the best course of action? To define __XEN__
> or __XEN_TOOLS__ as part of the check (this throws up other errors as
> part of the check process, suggesting that the header files are hiding
> ansi non-conformance in certain blocks), or dont predicate the
> definition of uint64_aligned_t on the presence of the above defines?

__XEN__ and __XEN_TOOLS__ must specifically not be defined for
these checks (and these symbols indeed get used to frame certain
definitions that are considered "internal" as outlined above - obviously,
by framing any definition this way we hide them from "foreign"
consumers *and* the [pointless in this case] style checking).

So bottom line is - no, you can't use uint64_aligned_t as much as any
other non-ANSI extension. Preventing anyone to try is what the
check was introduced for.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 14:19:58 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 14:19:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaTCg-00038v-Nh; Tue, 13 Dec 2011 14:19:34 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1RaTCe-000386-WB
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 14:19:33 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-3.tower-216.messagelabs.com!1323785916!7249660!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9542 invoked from network); 13 Dec 2011 14:18:38 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-3.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 13 Dec 2011 14:18:38 -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
	pBDEIZkE032385
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Tue, 13 Dec 2011 09:18:35 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pBDEIZw7032383;
	Tue, 13 Dec 2011 09:18:35 -0500
Date: Tue, 13 Dec 2011 10:18:35 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: George Shuklin <george.shuklin@gmail.com>
Message-ID: <20111213141835.GA32247@andromeda.dapyr.net>
References: <4EE675A8.3030609@niemail.de> <4EE71663.5040308@gmail.com>
	<CAJeBh4sxdNTxM_oLFAuA6Mw75=LaYysrpS5b8NsZMbkf_swNVw@mail.gmail.com>
	<4EE72A94.6040904@gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4EE72A94.6040904@gmail.com>
User-Agent: Mutt/1.5.9i
Cc: xen-devel@lists.xensource.com, sandr8@gmail.com
Subject: Re: [Xen-devel] a ton of kernel issues
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Dec 13, 2011 at 02:36:04PM +0400, George Shuklin wrote:
> On 13.12.2011 14:19, Alessandro Salvatori wrote:
> >
> >>pv_ops is still have some issues with memory limits, but any
> >>new kernel (3.0+) will boot normal and operates with very
> >>minor glitches. Older pv_ops (f.e. debian 2.6.32) have some
> >>more major issues.
> >what glitches should one expect with 3.0+, and having the choice,
> >would it be better to go with 3.1 or even 3.2?
> >
> >
> Right now I know about two of them:
> When you set up memory for virtual machine using xenballon, value in 
> dom0 differ from value in domU. The issue is that -xen kernels 'hide' 
> some memory in 'used' memory, and pv-ops just reducing TotalMem to value 
> without that memory. Practically that means if you set up memory for 
> domain to 2GiB client will saw only 1.95GiB and so on.
> 
> The second issue is lack of support of 'pre-inflated balloon', means you 
> can not set up memory-static-max to 2GiB, target to 1GiB and do 'memory 
> grow' from 1 G to 2 G latter without VM reboot. -xen kernels allow this 
> (up to memory-static-max limit).

Is all of this with 'xm' or with 'xl' tools? What happens when you 'grow'
the memory from 1G to 2G? Are you using the hotplug memory balloon or
the older one?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 14:19:58 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 14:19:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaTCg-00038v-Nh; Tue, 13 Dec 2011 14:19:34 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1RaTCe-000386-WB
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 14:19:33 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-3.tower-216.messagelabs.com!1323785916!7249660!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9542 invoked from network); 13 Dec 2011 14:18:38 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-3.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 13 Dec 2011 14:18:38 -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
	pBDEIZkE032385
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Tue, 13 Dec 2011 09:18:35 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pBDEIZw7032383;
	Tue, 13 Dec 2011 09:18:35 -0500
Date: Tue, 13 Dec 2011 10:18:35 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: George Shuklin <george.shuklin@gmail.com>
Message-ID: <20111213141835.GA32247@andromeda.dapyr.net>
References: <4EE675A8.3030609@niemail.de> <4EE71663.5040308@gmail.com>
	<CAJeBh4sxdNTxM_oLFAuA6Mw75=LaYysrpS5b8NsZMbkf_swNVw@mail.gmail.com>
	<4EE72A94.6040904@gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4EE72A94.6040904@gmail.com>
User-Agent: Mutt/1.5.9i
Cc: xen-devel@lists.xensource.com, sandr8@gmail.com
Subject: Re: [Xen-devel] a ton of kernel issues
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Dec 13, 2011 at 02:36:04PM +0400, George Shuklin wrote:
> On 13.12.2011 14:19, Alessandro Salvatori wrote:
> >
> >>pv_ops is still have some issues with memory limits, but any
> >>new kernel (3.0+) will boot normal and operates with very
> >>minor glitches. Older pv_ops (f.e. debian 2.6.32) have some
> >>more major issues.
> >what glitches should one expect with 3.0+, and having the choice,
> >would it be better to go with 3.1 or even 3.2?
> >
> >
> Right now I know about two of them:
> When you set up memory for virtual machine using xenballon, value in 
> dom0 differ from value in domU. The issue is that -xen kernels 'hide' 
> some memory in 'used' memory, and pv-ops just reducing TotalMem to value 
> without that memory. Practically that means if you set up memory for 
> domain to 2GiB client will saw only 1.95GiB and so on.
> 
> The second issue is lack of support of 'pre-inflated balloon', means you 
> can not set up memory-static-max to 2GiB, target to 1GiB and do 'memory 
> grow' from 1 G to 2 G latter without VM reboot. -xen kernels allow this 
> (up to memory-static-max limit).

Is all of this with 'xm' or with 'xl' tools? What happens when you 'grow'
the memory from 1G to 2G? Are you using the hotplug memory balloon or
the older one?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 14:20:21 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 14:20:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaTDF-0003Dh-5t; Tue, 13 Dec 2011 14:20:09 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Christoph.Egger@amd.com>) id 1RaTDD-0003CX-AP
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 14:20:07 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1323785934!49105588!1
X-Originating-IP: [213.199.154.141]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5128 invoked from network); 13 Dec 2011 14:18:54 -0000
Received: from db3ehsobe003.messaging.microsoft.com (HELO
	DB3EHSOBE003.bigfish.com) (213.199.154.141)
	by server-11.tower-27.messagelabs.com with AES128-SHA encrypted SMTP;
	13 Dec 2011 14:18:54 -0000
Received: from mail96-db3-R.bigfish.com (10.3.81.241) by
	DB3EHSOBE003.bigfish.com (10.3.84.23) with Microsoft SMTP Server id
	14.1.225.23; Tue, 13 Dec 2011 14:19:13 +0000
Received: from mail96-db3 (localhost [127.0.0.1])	by mail96-db3-R.bigfish.com
	(Postfix) with ESMTP id 1837C2602A0;
	Tue, 13 Dec 2011 14:19:13 +0000 (UTC)
X-SpamScore: -10
X-BigFish: VPS-10(zzbb2dI1432N98dKzz1202hzzz2dh668h839h)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
X-FB-SS: 13,
Received: from mail96-db3 (localhost.localdomain [127.0.0.1]) by mail96-db3
	(MessageSwitch) id 13237859535894_18030; Tue, 13 Dec 2011 14:19:13 +0000
	(UTC)
Received: from DB3EHSMHS015.bigfish.com (unknown [10.3.81.252])	by
	mail96-db3.bigfish.com (Postfix) with ESMTP id EC1192E0044;
	Tue, 13 Dec 2011 14:19:12 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	DB3EHSMHS015.bigfish.com (10.3.87.115) with Microsoft SMTP Server id
	14.1.225.23; Tue, 13 Dec 2011 14:19:10 +0000
X-WSS-ID: 0LW5BRV-01-AI8-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 265CD1028051;	Tue, 13 Dec 2011 08:19:06 -0600 (CST)
Received: from sausexhtp02.amd.com (163.181.3.152) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Tue, 13 Dec 2011 08:19:16 -0600
Received: from storexhtp02.amd.com (172.24.4.4) by sausexhtp02.amd.com
	(163.181.3.152) with Microsoft SMTP Server (TLS) id 8.3.213.0;
	Tue, 13 Dec 2011 08:19:07 -0600
Received: from rhodium.osrc.amd.com (165.204.15.173) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Tue, 13 Dec 2011
	09:19:06 -0500
Message-ID: <4EE75ED9.4030407@amd.com>
Date: Tue, 13 Dec 2011 15:19:05 +0100
From: Christoph Egger <Christoph.Egger@amd.com>
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:8.0) Gecko/20111114 Thunderbird/8.0
MIME-Version: 1.0
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
References: <4EDDE199.2090801@amd.com>
	<20198.5427.127204.527798@mariner.uk.xensource.com>
In-Reply-To: <20198.5427.127204.527798@mariner.uk.xensource.com>
X-OriginatorOrg: amd.com
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH] libxc: switch to XC_PAGE_*
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 12/12/11 15:52, Ian Jackson wrote:
> Christoph Egger writes ("[Xen-devel] [PATCH] libxc: switch to XC_PAGE_*"):
>> Switch to a consistent set of XC_PAGE_* constants.
>
> This looks reasonable to me but: can you confirm what tests you've
> done to check that this doesn't have any actual change to the code ?

Is it enough to say a guest boots and runs as before?

> Eg it would be good to run it through the preprocessor and see if the
> output is identical to before.
>
> Ian.
>


-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo, Andrew Bowd
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 14:20:21 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 14:20:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaTDF-0003Dh-5t; Tue, 13 Dec 2011 14:20:09 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Christoph.Egger@amd.com>) id 1RaTDD-0003CX-AP
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 14:20:07 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1323785934!49105588!1
X-Originating-IP: [213.199.154.141]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5128 invoked from network); 13 Dec 2011 14:18:54 -0000
Received: from db3ehsobe003.messaging.microsoft.com (HELO
	DB3EHSOBE003.bigfish.com) (213.199.154.141)
	by server-11.tower-27.messagelabs.com with AES128-SHA encrypted SMTP;
	13 Dec 2011 14:18:54 -0000
Received: from mail96-db3-R.bigfish.com (10.3.81.241) by
	DB3EHSOBE003.bigfish.com (10.3.84.23) with Microsoft SMTP Server id
	14.1.225.23; Tue, 13 Dec 2011 14:19:13 +0000
Received: from mail96-db3 (localhost [127.0.0.1])	by mail96-db3-R.bigfish.com
	(Postfix) with ESMTP id 1837C2602A0;
	Tue, 13 Dec 2011 14:19:13 +0000 (UTC)
X-SpamScore: -10
X-BigFish: VPS-10(zzbb2dI1432N98dKzz1202hzzz2dh668h839h)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
X-FB-SS: 13,
Received: from mail96-db3 (localhost.localdomain [127.0.0.1]) by mail96-db3
	(MessageSwitch) id 13237859535894_18030; Tue, 13 Dec 2011 14:19:13 +0000
	(UTC)
Received: from DB3EHSMHS015.bigfish.com (unknown [10.3.81.252])	by
	mail96-db3.bigfish.com (Postfix) with ESMTP id EC1192E0044;
	Tue, 13 Dec 2011 14:19:12 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	DB3EHSMHS015.bigfish.com (10.3.87.115) with Microsoft SMTP Server id
	14.1.225.23; Tue, 13 Dec 2011 14:19:10 +0000
X-WSS-ID: 0LW5BRV-01-AI8-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 265CD1028051;	Tue, 13 Dec 2011 08:19:06 -0600 (CST)
Received: from sausexhtp02.amd.com (163.181.3.152) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Tue, 13 Dec 2011 08:19:16 -0600
Received: from storexhtp02.amd.com (172.24.4.4) by sausexhtp02.amd.com
	(163.181.3.152) with Microsoft SMTP Server (TLS) id 8.3.213.0;
	Tue, 13 Dec 2011 08:19:07 -0600
Received: from rhodium.osrc.amd.com (165.204.15.173) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Tue, 13 Dec 2011
	09:19:06 -0500
Message-ID: <4EE75ED9.4030407@amd.com>
Date: Tue, 13 Dec 2011 15:19:05 +0100
From: Christoph Egger <Christoph.Egger@amd.com>
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:8.0) Gecko/20111114 Thunderbird/8.0
MIME-Version: 1.0
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
References: <4EDDE199.2090801@amd.com>
	<20198.5427.127204.527798@mariner.uk.xensource.com>
In-Reply-To: <20198.5427.127204.527798@mariner.uk.xensource.com>
X-OriginatorOrg: amd.com
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH] libxc: switch to XC_PAGE_*
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 12/12/11 15:52, Ian Jackson wrote:
> Christoph Egger writes ("[Xen-devel] [PATCH] libxc: switch to XC_PAGE_*"):
>> Switch to a consistent set of XC_PAGE_* constants.
>
> This looks reasonable to me but: can you confirm what tests you've
> done to check that this doesn't have any actual change to the code ?

Is it enough to say a guest boots and runs as before?

> Eg it would be good to run it through the preprocessor and see if the
> output is identical to before.
>
> Ian.
>


-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo, Andrew Bowd
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 14:21:25 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 14:21:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaTEG-0003PA-Np; Tue, 13 Dec 2011 14:21:12 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RaTEF-0003Oh-5c
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 14:21:11 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1323785973!48816549!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25601 invoked from network); 13 Dec 2011 14:19:33 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-3.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 13 Dec 2011 14:19:33 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 13 Dec 2011 14:20:16 +0000
Message-Id: <4EE76D2C020000780006755B@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 13 Dec 2011 14:20:12 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>,
	"Ian Jackson" <Ian.Jackson@eu.citrix.com>
References: <osstest-10481-mainreport@xen.org>
	<1323769464.20077.262.camel@zakaz.uk.xensource.com>
	<20199.14342.599850.739029@mariner.uk.xensource.com>
	<1323785260.20077.307.camel@zakaz.uk.xensource.com>
In-Reply-To: <1323785260.20077.307.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [xen-unstable test] 10481: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 13.12.11 at 15:07, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Tue, 2011-12-13 at 11:33 +0000, Ian Jackson wrote:
>> Ian Campbell writes ("Re: [Xen-devel] [xen-unstable test] 10481: regressions - 
> FAIL"):
>> > I think "xl trigger <dom> power" would be what is wanted here -- e.g.
>> > send an ACPI power event. It could be argued that xl shutdown could do
>> > this automatically?
>> 
>> libxl_domain_shutdown should do it automatically for HVM guests with
>> no PV drivers.
> 
> I was about half way through implementing this when it occurred to me
> that the reaction to a power button press is a guest OS option and can
> result in a shutdown, a reboot or even a suspend.

Correct.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 14:21:25 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 14:21:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaTEG-0003PA-Np; Tue, 13 Dec 2011 14:21:12 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RaTEF-0003Oh-5c
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 14:21:11 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1323785973!48816549!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25601 invoked from network); 13 Dec 2011 14:19:33 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-3.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 13 Dec 2011 14:19:33 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 13 Dec 2011 14:20:16 +0000
Message-Id: <4EE76D2C020000780006755B@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 13 Dec 2011 14:20:12 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>,
	"Ian Jackson" <Ian.Jackson@eu.citrix.com>
References: <osstest-10481-mainreport@xen.org>
	<1323769464.20077.262.camel@zakaz.uk.xensource.com>
	<20199.14342.599850.739029@mariner.uk.xensource.com>
	<1323785260.20077.307.camel@zakaz.uk.xensource.com>
In-Reply-To: <1323785260.20077.307.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [xen-unstable test] 10481: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 13.12.11 at 15:07, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Tue, 2011-12-13 at 11:33 +0000, Ian Jackson wrote:
>> Ian Campbell writes ("Re: [Xen-devel] [xen-unstable test] 10481: regressions - 
> FAIL"):
>> > I think "xl trigger <dom> power" would be what is wanted here -- e.g.
>> > send an ACPI power event. It could be argued that xl shutdown could do
>> > this automatically?
>> 
>> libxl_domain_shutdown should do it automatically for HVM guests with
>> no PV drivers.
> 
> I was about half way through implementing this when it occurred to me
> that the reaction to a power button press is a guest OS option and can
> result in a shutdown, a reboot or even a suspend.

Correct.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 14:21:28 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 14:21:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaTEN-0003Q8-54; Tue, 13 Dec 2011 14:21:19 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RaTEL-0003P6-BS
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 14:21:17 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1323786021!5383276!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTI1NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23065 invoked from network); 13 Dec 2011 14:20:22 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 14:20:22 -0000
X-IronPort-AV: E=Sophos;i="4.71,345,1320624000"; 
   d="scan'208";a="9442215"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Dec 2011 14:20:21 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 13 Dec 2011 14:20:21 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RaTDR-00071z-70; Tue, 13 Dec 2011 14:20:21 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RaTDR-0002QK-6H;
	Tue, 13 Dec 2011 14:20:21 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20199.24357.180937.882607@mariner.uk.xensource.com>
Date: Tue, 13 Dec 2011 14:20:21 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1323785260.20077.307.camel@zakaz.uk.xensource.com>
References: <osstest-10481-mainreport@xen.org>
	<1323769464.20077.262.camel@zakaz.uk.xensource.com>
	<20199.14342.599850.739029@mariner.uk.xensource.com>
	<1323785260.20077.307.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [xen-unstable test] 10481: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("Re: [Xen-devel] [xen-unstable test] 10481: regressions - FAIL"):
> I was about half way through implementing this when it occurred to me
> that the reaction to a power button press is a guest OS option and can
> result in a shutdown, a reboot or even a suspend.
> 
> Unless I'm mistaken?

Firstly, aren't there several possible indications we could send, in
which case we pick one most likely to make the guest shut down ?

Secondly, having the guest attempt to reboot is probably better than
simply shooting it in the head.  (We could even intercept that and
have it be destroyed anyway.)  At least this way if the user wants
graceful shutdown they can configure the guest to do a shutdown and
then xl shutdown will work.

At the moment it doesn't work at all without pv drivers.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 14:21:28 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 14:21:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaTEN-0003Q8-54; Tue, 13 Dec 2011 14:21:19 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RaTEL-0003P6-BS
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 14:21:17 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1323786021!5383276!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTI1NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23065 invoked from network); 13 Dec 2011 14:20:22 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 14:20:22 -0000
X-IronPort-AV: E=Sophos;i="4.71,345,1320624000"; 
   d="scan'208";a="9442215"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Dec 2011 14:20:21 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 13 Dec 2011 14:20:21 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RaTDR-00071z-70; Tue, 13 Dec 2011 14:20:21 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RaTDR-0002QK-6H;
	Tue, 13 Dec 2011 14:20:21 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20199.24357.180937.882607@mariner.uk.xensource.com>
Date: Tue, 13 Dec 2011 14:20:21 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1323785260.20077.307.camel@zakaz.uk.xensource.com>
References: <osstest-10481-mainreport@xen.org>
	<1323769464.20077.262.camel@zakaz.uk.xensource.com>
	<20199.14342.599850.739029@mariner.uk.xensource.com>
	<1323785260.20077.307.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [xen-unstable test] 10481: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("Re: [Xen-devel] [xen-unstable test] 10481: regressions - FAIL"):
> I was about half way through implementing this when it occurred to me
> that the reaction to a power button press is a guest OS option and can
> result in a shutdown, a reboot or even a suspend.
> 
> Unless I'm mistaken?

Firstly, aren't there several possible indications we could send, in
which case we pick one most likely to make the guest shut down ?

Secondly, having the guest attempt to reboot is probably better than
simply shooting it in the head.  (We could even intercept that and
have it be destroyed anyway.)  At least this way if the user wants
graceful shutdown they can configure the guest to do a shutdown and
then xl shutdown will work.

At the moment it doesn't work at all without pv drivers.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 14:22:35 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 14:22:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaTFR-0003f7-0d; Tue, 13 Dec 2011 14:22:25 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RaTFO-0003ds-Kc
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 14:22:22 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1323786084!7888195!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTI1NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30166 invoked from network); 13 Dec 2011 14:21:28 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 14:21:28 -0000
X-IronPort-AV: E=Sophos;i="4.71,345,1320624000"; 
   d="scan'208";a="9442240"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Dec 2011 14:21:12 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 13 Dec 2011 14:21:11 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RaTEF-00072G-Np; Tue, 13 Dec 2011 14:21:11 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RaTEF-0002Qc-NC;
	Tue, 13 Dec 2011 14:21:11 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20199.24407.707599.482890@mariner.uk.xensource.com>
Date: Tue, 13 Dec 2011 14:21:11 +0000
To: Christoph Egger <Christoph.Egger@amd.com>
In-Reply-To: <4EE75ED9.4030407@amd.com>
References: <4EDDE199.2090801@amd.com>
	<20198.5427.127204.527798@mariner.uk.xensource.com>
	<4EE75ED9.4030407@amd.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH] libxc: switch to XC_PAGE_*
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Christoph Egger writes ("Re: [Xen-devel] [PATCH] libxc: switch to XC_PAGE_*"):
> On 12/12/11 15:52, Ian Jackson wrote:
> > Christoph Egger writes ("[Xen-devel] [PATCH] libxc: switch to XC_PAGE_*"):
> >> Switch to a consistent set of XC_PAGE_* constants.
> >
> > This looks reasonable to me but: can you confirm what tests you've
> > done to check that this doesn't have any actual change to the code ?
> 
> Is it enough to say a guest boots and runs as before?

No, because you cannot possibly have tested every combination of
platforms.

Since the change you are making is supposed to make no difference to
the actual compiled code, you should check that directly.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 14:22:35 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 14:22:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaTFR-0003f7-0d; Tue, 13 Dec 2011 14:22:25 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RaTFO-0003ds-Kc
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 14:22:22 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1323786084!7888195!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTI1NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30166 invoked from network); 13 Dec 2011 14:21:28 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 14:21:28 -0000
X-IronPort-AV: E=Sophos;i="4.71,345,1320624000"; 
   d="scan'208";a="9442240"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Dec 2011 14:21:12 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 13 Dec 2011 14:21:11 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RaTEF-00072G-Np; Tue, 13 Dec 2011 14:21:11 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RaTEF-0002Qc-NC;
	Tue, 13 Dec 2011 14:21:11 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20199.24407.707599.482890@mariner.uk.xensource.com>
Date: Tue, 13 Dec 2011 14:21:11 +0000
To: Christoph Egger <Christoph.Egger@amd.com>
In-Reply-To: <4EE75ED9.4030407@amd.com>
References: <4EDDE199.2090801@amd.com>
	<20198.5427.127204.527798@mariner.uk.xensource.com>
	<4EE75ED9.4030407@amd.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH] libxc: switch to XC_PAGE_*
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Christoph Egger writes ("Re: [Xen-devel] [PATCH] libxc: switch to XC_PAGE_*"):
> On 12/12/11 15:52, Ian Jackson wrote:
> > Christoph Egger writes ("[Xen-devel] [PATCH] libxc: switch to XC_PAGE_*"):
> >> Switch to a consistent set of XC_PAGE_* constants.
> >
> > This looks reasonable to me but: can you confirm what tests you've
> > done to check that this doesn't have any actual change to the code ?
> 
> Is it enough to say a guest boots and runs as before?

No, because you cannot possibly have tested every combination of
platforms.

Since the change you are making is supposed to make no difference to
the actual compiled code, you should check that directly.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 14:22:48 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 14:22:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaTFf-0003iQ-Ea; Tue, 13 Dec 2011 14:22:39 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RaTFd-0003gj-Qo
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 14:22:38 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1323786103!7277730!1
X-Originating-IP: [209.85.215.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32565 invoked from network); 13 Dec 2011 14:21:43 -0000
Received: from mail-lpp01m010-f43.google.com (HELO
	mail-lpp01m010-f43.google.com) (209.85.215.43)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 14:21:43 -0000
Received: by lagw12 with SMTP id w12so3354403lag.30
	for <xen-devel@lists.xensource.com>;
	Tue, 13 Dec 2011 06:21:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=eoBPaDRREtqsaTSdgf1jZBcu0yXTc0aIRYT54c2W6NY=;
	b=sZdvSuRmCTIbb7ptUPOfJdofNKfcA7EJeRqvvKeCmWu3qqqZQCWKORpqOgw8F729t9
	9PNS+1AcbSD3BPx/P0qY1/fH03rY40jpevE21ZxdB+MMZnrMhni+ZkYhWNhdqI4ipTYc
	EYn8G99SWyOOHBq0oT6REBA2Ym43Jn4BQg4aA=
Received: by 10.152.104.130 with SMTP id ge2mr15265561lab.43.1323786102807;
	Tue, 13 Dec 2011 06:21:42 -0800 (PST)
Received: from [192.168.1.3] (host81-152-17-11.range81-152.btcentralplus.com.
	[81.152.17.11])
	by mx.google.com with ESMTPS id ne3sm20157110lab.7.2011.12.13.06.21.41
	(version=SSLv3 cipher=OTHER); Tue, 13 Dec 2011 06:21:42 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Tue, 13 Dec 2011 14:21:42 +0000
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>, Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <CB0D0FF6.35BAD%keir@xen.org>
Thread-Topic: headers.chk failing under certain circumstances.
Thread-Index: Acy5oojt0F4xokTt40eBDOHwa+yjEw==
In-Reply-To: <4EE76C7E0200007800067541@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] headers.chk failing under certain circumstances.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 13/12/2011 14:17, "Jan Beulich" <JBeulich@suse.com> wrote:

>> Given that uint64_aligned_t is a
>> sensible datatype to be using with the hypercall interface, fixing the
>> check seems to be the correct solution.
> 
> Sensible or not, you would have to find a way to define such a type
> in a compiler-independent (i.e. ANSI conforming) manner, and I'm
> afraid you won't be able to.

Yes, as barbaric as it may seem you just have to make sure that uint64_t
gets naturally 8-byte aligned. Luckily none of our interface structures are
particularly large, and I believe you can get them checked for 32/64-bit
invariance by adding them to xlat.lst.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 14:22:48 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 14:22:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaTFf-0003iQ-Ea; Tue, 13 Dec 2011 14:22:39 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RaTFd-0003gj-Qo
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 14:22:38 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1323786103!7277730!1
X-Originating-IP: [209.85.215.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32565 invoked from network); 13 Dec 2011 14:21:43 -0000
Received: from mail-lpp01m010-f43.google.com (HELO
	mail-lpp01m010-f43.google.com) (209.85.215.43)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 14:21:43 -0000
Received: by lagw12 with SMTP id w12so3354403lag.30
	for <xen-devel@lists.xensource.com>;
	Tue, 13 Dec 2011 06:21:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=eoBPaDRREtqsaTSdgf1jZBcu0yXTc0aIRYT54c2W6NY=;
	b=sZdvSuRmCTIbb7ptUPOfJdofNKfcA7EJeRqvvKeCmWu3qqqZQCWKORpqOgw8F729t9
	9PNS+1AcbSD3BPx/P0qY1/fH03rY40jpevE21ZxdB+MMZnrMhni+ZkYhWNhdqI4ipTYc
	EYn8G99SWyOOHBq0oT6REBA2Ym43Jn4BQg4aA=
Received: by 10.152.104.130 with SMTP id ge2mr15265561lab.43.1323786102807;
	Tue, 13 Dec 2011 06:21:42 -0800 (PST)
Received: from [192.168.1.3] (host81-152-17-11.range81-152.btcentralplus.com.
	[81.152.17.11])
	by mx.google.com with ESMTPS id ne3sm20157110lab.7.2011.12.13.06.21.41
	(version=SSLv3 cipher=OTHER); Tue, 13 Dec 2011 06:21:42 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Tue, 13 Dec 2011 14:21:42 +0000
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>, Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <CB0D0FF6.35BAD%keir@xen.org>
Thread-Topic: headers.chk failing under certain circumstances.
Thread-Index: Acy5oojt0F4xokTt40eBDOHwa+yjEw==
In-Reply-To: <4EE76C7E0200007800067541@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] headers.chk failing under certain circumstances.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 13/12/2011 14:17, "Jan Beulich" <JBeulich@suse.com> wrote:

>> Given that uint64_aligned_t is a
>> sensible datatype to be using with the hypercall interface, fixing the
>> check seems to be the correct solution.
> 
> Sensible or not, you would have to find a way to define such a type
> in a compiler-independent (i.e. ANSI conforming) manner, and I'm
> afraid you won't be able to.

Yes, as barbaric as it may seem you just have to make sure that uint64_t
gets naturally 8-byte aligned. Luckily none of our interface structures are
particularly large, and I believe you can get them checked for 32/64-bit
invariance by adding them to xlat.lst.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 14:24:02 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 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.xensource.com>)
	id 1RaTGr-00040O-Va; Tue, 13 Dec 2011 14:23:53 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Christoph.Egger@amd.com>) id 1RaTGp-0003yy-I7
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 14:23:51 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1323786175!7250435!1
X-Originating-IP: [216.32.180.12]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26925 invoked from network); 13 Dec 2011 14:22:56 -0000
Received: from va3ehsobe002.messaging.microsoft.com (HELO
	VA3EHSOBE002.bigfish.com) (216.32.180.12)
	by server-3.tower-216.messagelabs.com with AES128-SHA encrypted SMTP;
	13 Dec 2011 14:22:56 -0000
Received: from mail195-va3-R.bigfish.com (10.7.14.245) by
	VA3EHSOBE002.bigfish.com (10.7.40.22) with Microsoft SMTP Server id
	14.1.225.23; Tue, 13 Dec 2011 14:22:55 +0000
Received: from mail195-va3 (localhost [127.0.0.1])	by
	mail195-va3-R.bigfish.com (Postfix) with ESMTP id 7C5AD400294;
	Tue, 13 Dec 2011 14:22:55 +0000 (UTC)
X-SpamScore: -15
X-BigFish: VPS-15(zzbb2dI1803Mc85dh1432N98dKzz1202hzz8275bhz2dh668h839h34h61h)
X-Spam-TCS-SCL: 0:0
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
Received: from mail195-va3 (localhost.localdomain [127.0.0.1]) by mail195-va3
	(MessageSwitch) id 1323786173602198_3043;
	Tue, 13 Dec 2011 14:22:53 +0000 (UTC)
Received: from VA3EHSMHS005.bigfish.com (unknown [10.7.14.242])	by
	mail195-va3.bigfish.com (Postfix) with ESMTP id 4C8F0500042;
	Tue, 13 Dec 2011 14:22:50 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	VA3EHSMHS005.bigfish.com (10.7.99.15) with Microsoft SMTP Server id
	14.1.225.23; Tue, 13 Dec 2011 14:22:48 +0000
X-WSS-ID: 0LW5BXY-01-ARM-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 23EC2102804C;	Tue, 13 Dec 2011 08:22:45 -0600 (CST)
Received: from SAUSEXDAG02.amd.com (163.181.55.2) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Tue, 13 Dec 2011 08:22:55 -0600
Received: from storexhtp02.amd.com (172.24.4.4) by sausexdag02.amd.com
	(163.181.55.2) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Tue, 13 Dec 2011 08:22:46 -0600
Received: from rhodium.osrc.amd.com (165.204.15.173) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Tue, 13 Dec 2011
	09:22:45 -0500
Message-ID: <4EE75FB4.30609@amd.com>
Date: Tue, 13 Dec 2011 15:22:44 +0100
From: Christoph Egger <Christoph.Egger@amd.com>
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:8.0) Gecko/20111114 Thunderbird/8.0
MIME-Version: 1.0
To: Keir Fraser <keir@xen.org>
References: <CB0BC143.35A76%keir@xen.org>
In-Reply-To: <CB0BC143.35A76%keir@xen.org>
Content-Type: multipart/mixed; boundary="------------010607040104090401080708"
X-OriginatorOrg: amd.com
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] microcode fix
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--------------010607040104090401080708
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit

On 12/12/11 15:33, Keir Fraser wrote:
> On 12/12/2011 14:02, "Christoph Egger"<Christoph.Egger@amd.com>  wrote:
>
>>
>> Remove hardcoded maximum size a microcode patch can have.
>> This is dynamic now.
>
> The patch doesn't apply to xen-unstable tip.

Ported to xen-unstable.

Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>

>
>   -- Keir
>
>> The microcode patch for family15h can be larger than 2048 bytes
>> and gets silently truncated.
>>
>> Signed-off-by: Christoph Egger<Christoph.Egger@amd.com>
>>
>> P.S. Please apply this to Xen 4.1, 4.0, 3.4 and 3.3, too.
>
>
>


-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo, Andrew Bowd
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632

--------------010607040104090401080708
Content-Type: text/plain; name="xen_microcode_fam15.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="xen_microcode_fam15.diff"
Content-Description: xen_microcode_fam15.diff

diff -r f1ab2c2138d8 xen/arch/x86/microcode_amd.c
--- a/xen/arch/x86/microcode_amd.c	Mon Dec 12 10:47:26 2011 +0100
+++ b/xen/arch/x86/microcode_amd.c	Tue Dec 13 15:16:02 2011 +0100
@@ -26,8 +26,6 @@
 #include <asm/processor.h>
 #include <asm/microcode.h>
 
-#define pr_debug(x...) ((void)0)
-
 struct equiv_cpu_entry {
     uint32_t installed_cpu;
     uint32_t fixed_errata_mask;
@@ -57,14 +55,17 @@ struct microcode_header_amd {
 #define UCODE_EQUIV_CPU_TABLE_TYPE 0x00000000
 #define UCODE_UCODE_TYPE           0x00000001
 
-#define UCODE_MAX_SIZE          (2048)
-#define MC_HEADER_SIZE          (sizeof(struct microcode_header_amd))
+struct microcode_amd {
+    void *mpb;
+    size_t mpb_size;
+    struct equiv_cpu_entry *equiv_cpu_table;
+    size_t equiv_cpu_table_size;
+};
 
-struct microcode_amd {
-    struct microcode_header_amd hdr;
-    unsigned int mpb[(UCODE_MAX_SIZE - MC_HEADER_SIZE) / 4];
-    unsigned int equiv_cpu_table_size;
-    struct equiv_cpu_entry equiv_cpu_table[];
+struct mpbhdr {
+    uint32_t type;
+    uint32_t len;
+    const uint8_t data;
 };
 
 /* serialize access to the physical write */
@@ -94,7 +95,7 @@ static int collect_cpu_info(int cpu, str
 static int microcode_fits(const struct microcode_amd *mc_amd, int cpu)
 {
     struct ucode_cpu_info *uci = &per_cpu(ucode_cpu_info, cpu);
-    const struct microcode_header_amd *mc_header = &mc_amd->hdr;
+    const struct microcode_header_amd *mc_header = mc_amd->mpb;
     const struct equiv_cpu_entry *equiv_cpu_table = mc_amd->equiv_cpu_table;
     unsigned int current_cpu_id;
     unsigned int equiv_cpu_id = 0x0;
@@ -141,16 +142,19 @@ static int apply_microcode(int cpu)
     struct ucode_cpu_info *uci = &per_cpu(ucode_cpu_info, cpu);
     uint32_t rev;
     struct microcode_amd *mc_amd = uci->mc.mc_amd;
+    struct microcode_header_amd *hdr = mc_amd->mpb;
 
     /* We should bind the task to the CPU */
     BUG_ON(raw_smp_processor_id() != cpu);
 
     if ( mc_amd == NULL )
         return -EINVAL;
+    if ( mc_amd->mpb == NULL )
+        return -EINVAL;
 
     spin_lock_irqsave(&microcode_update_lock, flags);
 
-    wrmsrl(MSR_AMD_PATCHLOADER, (unsigned long)&mc_amd->hdr.data_code);
+    wrmsrl(MSR_AMD_PATCHLOADER, (unsigned long)mc_amd->mpb);
 
     /* get patch id after patching */
     rdmsrl(MSR_AMD_PATCHLEVEL, rev);
@@ -158,57 +162,60 @@ static int apply_microcode(int cpu)
     spin_unlock_irqrestore(&microcode_update_lock, flags);
 
     /* check current patch id and patch's id for match */
-    if ( rev != mc_amd->hdr.patch_id )
+    if ( rev != hdr->patch_id )
     {
         printk(KERN_ERR "microcode: CPU%d update from revision "
                "0x%x to 0x%x failed\n", cpu,
-               mc_amd->hdr.patch_id, rev);
+               hdr->patch_id, rev);
         return -EIO;
     }
 
     printk(KERN_INFO "microcode: CPU%d updated from revision %#x to %#x\n",
-           cpu, uci->cpu_sig.rev, mc_amd->hdr.patch_id);
+           cpu, uci->cpu_sig.rev, hdr->patch_id);
 
     uci->cpu_sig.rev = rev;
 
     return 0;
 }
 
-static int get_next_ucode_from_buffer_amd(void *mc, const void *buf,
-                                         size_t size, unsigned long *offset)
+static int get_next_ucode_from_buffer_amd(struct microcode_amd *mc_amd,
+    const void *buf, size_t bufsize, unsigned long *offset)
 {
-    size_t total_size;
     const uint8_t *bufp = buf;
     unsigned long off;
+    const struct mpbhdr *mpbuf;
 
     off = *offset;
 
     /* No more data */
-    if ( off >= size )
+    if ( off >= bufsize )
         return 1;
 
-    if ( bufp[off] != UCODE_UCODE_TYPE )
+    mpbuf = (const struct mpbhdr *)&bufp[off];
+    if ( mpbuf->type != UCODE_UCODE_TYPE )
     {
         printk(KERN_ERR "microcode: error! "
                "Wrong microcode payload type field\n");
         return -EINVAL;
     }
 
-    total_size = (unsigned long) (bufp[off+4] + (bufp[off+5] << 8));
+    printk(KERN_DEBUG "microcode: size %lu, block size %u, offset %ld\n",
+           (unsigned long)bufsize, mpbuf->len, off);
 
-    printk(KERN_DEBUG "microcode: size %lu, total_size %lu, offset %ld\n",
-           (unsigned long)size, total_size, off);
-
-    if ( (off + total_size) > size )
+    if ( (off + mpbuf->len) > bufsize )
     {
         printk(KERN_ERR "microcode: error! Bad data in microcode data file\n");
         return -EINVAL;
     }
 
-    memset(mc, 0, UCODE_MAX_SIZE);
-    memcpy(mc, (const void *)(&bufp[off + 8]), total_size);
+    if (mc_amd->mpb_size < mpbuf->len) {
+        xfree(mc_amd->mpb);
+        mc_amd->mpb = xmalloc_bytes(mpbuf->len);
+        mc_amd->mpb_size = mpbuf->len;
+    }
+    memcpy(mc_amd->mpb, (const void *)&mpbuf->data, mpbuf->len);
 
-    *offset = off + total_size + 8;
+    *offset = off + mpbuf->len + 8;
 
     return 0;
 }
@@ -234,10 +241,18 @@ static int install_equiv_cpu_table(
     if ( size == 0 )
     {
         printk(KERN_ERR "microcode: error! "
-               "Wrong microcode equivalnet cpu table length\n");
+               "Wrong microcode equivalent cpu table length\n");
         return -EINVAL;
     }
 
+    mc_amd->equiv_cpu_table = xmalloc_bytes(size);
+    if ( !mc_amd->equiv_cpu_table )
+    {
+        printk(KERN_ERR "microcode: error! "
+               "Can not allocate memory for equivalent cpu table\n");
+        return -ENOMEM;
+    }
+
     memcpy(mc_amd->equiv_cpu_table, &buf_pos[3], size);
     mc_amd->equiv_cpu_table_size = size;
 
@@ -246,11 +261,11 @@ static int install_equiv_cpu_table(
     return 0;
 }
 
-static int cpu_request_microcode(int cpu, const void *buf, size_t size)
+static int cpu_request_microcode(int cpu, const void *buf, size_t bufsize)
 {
     const uint32_t *buf_pos;
     struct microcode_amd *mc_amd, *mc_old;
-    unsigned long offset = size;
+    size_t offset = bufsize;
     int error = 0;
     int ret;
     struct ucode_cpu_info *uci = &per_cpu(ucode_cpu_info, cpu);
@@ -263,11 +278,11 @@ static int cpu_request_microcode(int cpu
     if ( buf_pos[0] != UCODE_MAGIC )
     {
         printk(KERN_ERR "microcode: error! Wrong "
-               "microcode patch file magic\n");
+            "microcode patch file magic\n");
         return -EINVAL;
     }
 
-    mc_amd = xmalloc_bytes(sizeof(*mc_amd) + buf_pos[2]);
+    mc_amd = xmalloc_bytes(sizeof(*mc_amd));
     if ( !mc_amd )
     {
         printk(KERN_ERR "microcode: error! "
@@ -291,8 +306,10 @@ static int cpu_request_microcode(int cpu
      * It's possible the data file has multiple matching ucode,
      * lets keep searching till the latest version
      */
-    while ( (ret = get_next_ucode_from_buffer_amd(&mc_amd->hdr, buf, size,
-                                                  &offset)) == 0 )
+    mc_amd->mpb = NULL;
+    mc_amd->mpb_size = 0;
+    while ( (ret = get_next_ucode_from_buffer_amd(mc_amd,
+        buf, bufsize, &offset)) == 0 )
     {
         error = microcode_fits(mc_amd, cpu);
         if (error <= 0)
@@ -335,17 +352,36 @@ static int microcode_resume_match(int cp
 
     if ( src != mc_amd )
     {
+        xfree(mc_amd->equiv_cpu_table);
+        xfree(mc_amd->mpb);
         xfree(mc_amd);
-        mc_amd = xmalloc_bytes(sizeof(*src) + src->equiv_cpu_table_size);
+
+        mc_amd = xmalloc_bytes(sizeof(*src));
+        if ( !mc_amd )
+            goto err0;
+        mc_amd->equiv_cpu_table = xmalloc_bytes(src->equiv_cpu_table_size);
+        if ( !mc_amd->equiv_cpu_table )
+            goto err1;
+        mc_amd->mpb = xmalloc_bytes(src->mpb_size);
+        if ( !mc_amd->mpb )
+            goto err2;
+
+        mc_amd->equiv_cpu_table_size = src->equiv_cpu_table_size;
+        mc_amd->mpb_size = src->mpb_size;
         uci->mc.mc_amd = mc_amd;
-        if ( !mc_amd )
-            return -ENOMEM;
-        memcpy(mc_amd, src, UCODE_MAX_SIZE);
+        memcpy(mc_amd->mpb, src->mpb, src->mpb_size);
         memcpy(mc_amd->equiv_cpu_table, src->equiv_cpu_table,
                src->equiv_cpu_table_size);
     }
 
     return 1;
+
+err2:
+    xfree(mc_amd->equiv_cpu_table);
+err1:
+    xfree(mc_amd);
+err0:
+    return -ENOMEM;
 }
 
 static const struct microcode_ops microcode_amd_ops = {

--------------010607040104090401080708
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--------------010607040104090401080708--


From xen-devel-bounces@lists.xensource.com Tue Dec 13 14:24:02 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 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.xensource.com>)
	id 1RaTGr-00040O-Va; Tue, 13 Dec 2011 14:23:53 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Christoph.Egger@amd.com>) id 1RaTGp-0003yy-I7
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 14:23:51 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1323786175!7250435!1
X-Originating-IP: [216.32.180.12]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26925 invoked from network); 13 Dec 2011 14:22:56 -0000
Received: from va3ehsobe002.messaging.microsoft.com (HELO
	VA3EHSOBE002.bigfish.com) (216.32.180.12)
	by server-3.tower-216.messagelabs.com with AES128-SHA encrypted SMTP;
	13 Dec 2011 14:22:56 -0000
Received: from mail195-va3-R.bigfish.com (10.7.14.245) by
	VA3EHSOBE002.bigfish.com (10.7.40.22) with Microsoft SMTP Server id
	14.1.225.23; Tue, 13 Dec 2011 14:22:55 +0000
Received: from mail195-va3 (localhost [127.0.0.1])	by
	mail195-va3-R.bigfish.com (Postfix) with ESMTP id 7C5AD400294;
	Tue, 13 Dec 2011 14:22:55 +0000 (UTC)
X-SpamScore: -15
X-BigFish: VPS-15(zzbb2dI1803Mc85dh1432N98dKzz1202hzz8275bhz2dh668h839h34h61h)
X-Spam-TCS-SCL: 0:0
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
Received: from mail195-va3 (localhost.localdomain [127.0.0.1]) by mail195-va3
	(MessageSwitch) id 1323786173602198_3043;
	Tue, 13 Dec 2011 14:22:53 +0000 (UTC)
Received: from VA3EHSMHS005.bigfish.com (unknown [10.7.14.242])	by
	mail195-va3.bigfish.com (Postfix) with ESMTP id 4C8F0500042;
	Tue, 13 Dec 2011 14:22:50 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	VA3EHSMHS005.bigfish.com (10.7.99.15) with Microsoft SMTP Server id
	14.1.225.23; Tue, 13 Dec 2011 14:22:48 +0000
X-WSS-ID: 0LW5BXY-01-ARM-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 23EC2102804C;	Tue, 13 Dec 2011 08:22:45 -0600 (CST)
Received: from SAUSEXDAG02.amd.com (163.181.55.2) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Tue, 13 Dec 2011 08:22:55 -0600
Received: from storexhtp02.amd.com (172.24.4.4) by sausexdag02.amd.com
	(163.181.55.2) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Tue, 13 Dec 2011 08:22:46 -0600
Received: from rhodium.osrc.amd.com (165.204.15.173) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Tue, 13 Dec 2011
	09:22:45 -0500
Message-ID: <4EE75FB4.30609@amd.com>
Date: Tue, 13 Dec 2011 15:22:44 +0100
From: Christoph Egger <Christoph.Egger@amd.com>
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:8.0) Gecko/20111114 Thunderbird/8.0
MIME-Version: 1.0
To: Keir Fraser <keir@xen.org>
References: <CB0BC143.35A76%keir@xen.org>
In-Reply-To: <CB0BC143.35A76%keir@xen.org>
Content-Type: multipart/mixed; boundary="------------010607040104090401080708"
X-OriginatorOrg: amd.com
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] microcode fix
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--------------010607040104090401080708
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit

On 12/12/11 15:33, Keir Fraser wrote:
> On 12/12/2011 14:02, "Christoph Egger"<Christoph.Egger@amd.com>  wrote:
>
>>
>> Remove hardcoded maximum size a microcode patch can have.
>> This is dynamic now.
>
> The patch doesn't apply to xen-unstable tip.

Ported to xen-unstable.

Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>

>
>   -- Keir
>
>> The microcode patch for family15h can be larger than 2048 bytes
>> and gets silently truncated.
>>
>> Signed-off-by: Christoph Egger<Christoph.Egger@amd.com>
>>
>> P.S. Please apply this to Xen 4.1, 4.0, 3.4 and 3.3, too.
>
>
>


-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo, Andrew Bowd
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632

--------------010607040104090401080708
Content-Type: text/plain; name="xen_microcode_fam15.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="xen_microcode_fam15.diff"
Content-Description: xen_microcode_fam15.diff

diff -r f1ab2c2138d8 xen/arch/x86/microcode_amd.c
--- a/xen/arch/x86/microcode_amd.c	Mon Dec 12 10:47:26 2011 +0100
+++ b/xen/arch/x86/microcode_amd.c	Tue Dec 13 15:16:02 2011 +0100
@@ -26,8 +26,6 @@
 #include <asm/processor.h>
 #include <asm/microcode.h>
 
-#define pr_debug(x...) ((void)0)
-
 struct equiv_cpu_entry {
     uint32_t installed_cpu;
     uint32_t fixed_errata_mask;
@@ -57,14 +55,17 @@ struct microcode_header_amd {
 #define UCODE_EQUIV_CPU_TABLE_TYPE 0x00000000
 #define UCODE_UCODE_TYPE           0x00000001
 
-#define UCODE_MAX_SIZE          (2048)
-#define MC_HEADER_SIZE          (sizeof(struct microcode_header_amd))
+struct microcode_amd {
+    void *mpb;
+    size_t mpb_size;
+    struct equiv_cpu_entry *equiv_cpu_table;
+    size_t equiv_cpu_table_size;
+};
 
-struct microcode_amd {
-    struct microcode_header_amd hdr;
-    unsigned int mpb[(UCODE_MAX_SIZE - MC_HEADER_SIZE) / 4];
-    unsigned int equiv_cpu_table_size;
-    struct equiv_cpu_entry equiv_cpu_table[];
+struct mpbhdr {
+    uint32_t type;
+    uint32_t len;
+    const uint8_t data;
 };
 
 /* serialize access to the physical write */
@@ -94,7 +95,7 @@ static int collect_cpu_info(int cpu, str
 static int microcode_fits(const struct microcode_amd *mc_amd, int cpu)
 {
     struct ucode_cpu_info *uci = &per_cpu(ucode_cpu_info, cpu);
-    const struct microcode_header_amd *mc_header = &mc_amd->hdr;
+    const struct microcode_header_amd *mc_header = mc_amd->mpb;
     const struct equiv_cpu_entry *equiv_cpu_table = mc_amd->equiv_cpu_table;
     unsigned int current_cpu_id;
     unsigned int equiv_cpu_id = 0x0;
@@ -141,16 +142,19 @@ static int apply_microcode(int cpu)
     struct ucode_cpu_info *uci = &per_cpu(ucode_cpu_info, cpu);
     uint32_t rev;
     struct microcode_amd *mc_amd = uci->mc.mc_amd;
+    struct microcode_header_amd *hdr = mc_amd->mpb;
 
     /* We should bind the task to the CPU */
     BUG_ON(raw_smp_processor_id() != cpu);
 
     if ( mc_amd == NULL )
         return -EINVAL;
+    if ( mc_amd->mpb == NULL )
+        return -EINVAL;
 
     spin_lock_irqsave(&microcode_update_lock, flags);
 
-    wrmsrl(MSR_AMD_PATCHLOADER, (unsigned long)&mc_amd->hdr.data_code);
+    wrmsrl(MSR_AMD_PATCHLOADER, (unsigned long)mc_amd->mpb);
 
     /* get patch id after patching */
     rdmsrl(MSR_AMD_PATCHLEVEL, rev);
@@ -158,57 +162,60 @@ static int apply_microcode(int cpu)
     spin_unlock_irqrestore(&microcode_update_lock, flags);
 
     /* check current patch id and patch's id for match */
-    if ( rev != mc_amd->hdr.patch_id )
+    if ( rev != hdr->patch_id )
     {
         printk(KERN_ERR "microcode: CPU%d update from revision "
                "0x%x to 0x%x failed\n", cpu,
-               mc_amd->hdr.patch_id, rev);
+               hdr->patch_id, rev);
         return -EIO;
     }
 
     printk(KERN_INFO "microcode: CPU%d updated from revision %#x to %#x\n",
-           cpu, uci->cpu_sig.rev, mc_amd->hdr.patch_id);
+           cpu, uci->cpu_sig.rev, hdr->patch_id);
 
     uci->cpu_sig.rev = rev;
 
     return 0;
 }
 
-static int get_next_ucode_from_buffer_amd(void *mc, const void *buf,
-                                         size_t size, unsigned long *offset)
+static int get_next_ucode_from_buffer_amd(struct microcode_amd *mc_amd,
+    const void *buf, size_t bufsize, unsigned long *offset)
 {
-    size_t total_size;
     const uint8_t *bufp = buf;
     unsigned long off;
+    const struct mpbhdr *mpbuf;
 
     off = *offset;
 
     /* No more data */
-    if ( off >= size )
+    if ( off >= bufsize )
         return 1;
 
-    if ( bufp[off] != UCODE_UCODE_TYPE )
+    mpbuf = (const struct mpbhdr *)&bufp[off];
+    if ( mpbuf->type != UCODE_UCODE_TYPE )
     {
         printk(KERN_ERR "microcode: error! "
                "Wrong microcode payload type field\n");
         return -EINVAL;
     }
 
-    total_size = (unsigned long) (bufp[off+4] + (bufp[off+5] << 8));
+    printk(KERN_DEBUG "microcode: size %lu, block size %u, offset %ld\n",
+           (unsigned long)bufsize, mpbuf->len, off);
 
-    printk(KERN_DEBUG "microcode: size %lu, total_size %lu, offset %ld\n",
-           (unsigned long)size, total_size, off);
-
-    if ( (off + total_size) > size )
+    if ( (off + mpbuf->len) > bufsize )
     {
         printk(KERN_ERR "microcode: error! Bad data in microcode data file\n");
         return -EINVAL;
     }
 
-    memset(mc, 0, UCODE_MAX_SIZE);
-    memcpy(mc, (const void *)(&bufp[off + 8]), total_size);
+    if (mc_amd->mpb_size < mpbuf->len) {
+        xfree(mc_amd->mpb);
+        mc_amd->mpb = xmalloc_bytes(mpbuf->len);
+        mc_amd->mpb_size = mpbuf->len;
+    }
+    memcpy(mc_amd->mpb, (const void *)&mpbuf->data, mpbuf->len);
 
-    *offset = off + total_size + 8;
+    *offset = off + mpbuf->len + 8;
 
     return 0;
 }
@@ -234,10 +241,18 @@ static int install_equiv_cpu_table(
     if ( size == 0 )
     {
         printk(KERN_ERR "microcode: error! "
-               "Wrong microcode equivalnet cpu table length\n");
+               "Wrong microcode equivalent cpu table length\n");
         return -EINVAL;
     }
 
+    mc_amd->equiv_cpu_table = xmalloc_bytes(size);
+    if ( !mc_amd->equiv_cpu_table )
+    {
+        printk(KERN_ERR "microcode: error! "
+               "Can not allocate memory for equivalent cpu table\n");
+        return -ENOMEM;
+    }
+
     memcpy(mc_amd->equiv_cpu_table, &buf_pos[3], size);
     mc_amd->equiv_cpu_table_size = size;
 
@@ -246,11 +261,11 @@ static int install_equiv_cpu_table(
     return 0;
 }
 
-static int cpu_request_microcode(int cpu, const void *buf, size_t size)
+static int cpu_request_microcode(int cpu, const void *buf, size_t bufsize)
 {
     const uint32_t *buf_pos;
     struct microcode_amd *mc_amd, *mc_old;
-    unsigned long offset = size;
+    size_t offset = bufsize;
     int error = 0;
     int ret;
     struct ucode_cpu_info *uci = &per_cpu(ucode_cpu_info, cpu);
@@ -263,11 +278,11 @@ static int cpu_request_microcode(int cpu
     if ( buf_pos[0] != UCODE_MAGIC )
     {
         printk(KERN_ERR "microcode: error! Wrong "
-               "microcode patch file magic\n");
+            "microcode patch file magic\n");
         return -EINVAL;
     }
 
-    mc_amd = xmalloc_bytes(sizeof(*mc_amd) + buf_pos[2]);
+    mc_amd = xmalloc_bytes(sizeof(*mc_amd));
     if ( !mc_amd )
     {
         printk(KERN_ERR "microcode: error! "
@@ -291,8 +306,10 @@ static int cpu_request_microcode(int cpu
      * It's possible the data file has multiple matching ucode,
      * lets keep searching till the latest version
      */
-    while ( (ret = get_next_ucode_from_buffer_amd(&mc_amd->hdr, buf, size,
-                                                  &offset)) == 0 )
+    mc_amd->mpb = NULL;
+    mc_amd->mpb_size = 0;
+    while ( (ret = get_next_ucode_from_buffer_amd(mc_amd,
+        buf, bufsize, &offset)) == 0 )
     {
         error = microcode_fits(mc_amd, cpu);
         if (error <= 0)
@@ -335,17 +352,36 @@ static int microcode_resume_match(int cp
 
     if ( src != mc_amd )
     {
+        xfree(mc_amd->equiv_cpu_table);
+        xfree(mc_amd->mpb);
         xfree(mc_amd);
-        mc_amd = xmalloc_bytes(sizeof(*src) + src->equiv_cpu_table_size);
+
+        mc_amd = xmalloc_bytes(sizeof(*src));
+        if ( !mc_amd )
+            goto err0;
+        mc_amd->equiv_cpu_table = xmalloc_bytes(src->equiv_cpu_table_size);
+        if ( !mc_amd->equiv_cpu_table )
+            goto err1;
+        mc_amd->mpb = xmalloc_bytes(src->mpb_size);
+        if ( !mc_amd->mpb )
+            goto err2;
+
+        mc_amd->equiv_cpu_table_size = src->equiv_cpu_table_size;
+        mc_amd->mpb_size = src->mpb_size;
         uci->mc.mc_amd = mc_amd;
-        if ( !mc_amd )
-            return -ENOMEM;
-        memcpy(mc_amd, src, UCODE_MAX_SIZE);
+        memcpy(mc_amd->mpb, src->mpb, src->mpb_size);
         memcpy(mc_amd->equiv_cpu_table, src->equiv_cpu_table,
                src->equiv_cpu_table_size);
     }
 
     return 1;
+
+err2:
+    xfree(mc_amd->equiv_cpu_table);
+err1:
+    xfree(mc_amd);
+err0:
+    return -ENOMEM;
 }
 
 static const struct microcode_ops microcode_amd_ops = {

--------------010607040104090401080708
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--------------010607040104090401080708--


From xen-devel-bounces@lists.xensource.com Tue Dec 13 14:27:00 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 14:27:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaTJf-0004R0-UA; Tue, 13 Dec 2011 14:26:47 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RaTJd-0004QX-W6
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 14:26:46 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1323786314!46533758!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24318 invoked from network); 13 Dec 2011 14:25:14 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-5.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 13 Dec 2011 14:25:14 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 13 Dec 2011 14:25:53 +0000
Message-Id: <4EE76E7D020000780006758F@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 13 Dec 2011 14:25:49 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>, "Keir Fraser" <keir@xen.org>
References: <4EE76C7E0200007800067541@nat28.tlf.novell.com>
	<CB0D0FF6.35BAD%keir@xen.org>
In-Reply-To: <CB0D0FF6.35BAD%keir@xen.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] headers.chk failing under certain circumstances.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 13.12.11 at 15:21, Keir Fraser <keir@xen.org> wrote:
> On 13/12/2011 14:17, "Jan Beulich" <JBeulich@suse.com> wrote:
> 
>>> Given that uint64_aligned_t is a
>>> sensible datatype to be using with the hypercall interface, fixing the
>>> check seems to be the correct solution.
>> 
>> Sensible or not, you would have to find a way to define such a type
>> in a compiler-independent (i.e. ANSI conforming) manner, and I'm
>> afraid you won't be able to.
> 
> Yes, as barbaric as it may seem you just have to make sure that uint64_t
> gets naturally 8-byte aligned. Luckily none of our interface structures are
> particularly large, and I believe you can get them checked for 32/64-bit
> invariance by adding them to xlat.lst.

... and invoking the resultant check macro somewhere in the sources.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 14:27:00 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 14:27:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaTJf-0004R0-UA; Tue, 13 Dec 2011 14:26:47 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RaTJd-0004QX-W6
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 14:26:46 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1323786314!46533758!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24318 invoked from network); 13 Dec 2011 14:25:14 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-5.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 13 Dec 2011 14:25:14 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 13 Dec 2011 14:25:53 +0000
Message-Id: <4EE76E7D020000780006758F@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 13 Dec 2011 14:25:49 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>, "Keir Fraser" <keir@xen.org>
References: <4EE76C7E0200007800067541@nat28.tlf.novell.com>
	<CB0D0FF6.35BAD%keir@xen.org>
In-Reply-To: <CB0D0FF6.35BAD%keir@xen.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] headers.chk failing under certain circumstances.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 13.12.11 at 15:21, Keir Fraser <keir@xen.org> wrote:
> On 13/12/2011 14:17, "Jan Beulich" <JBeulich@suse.com> wrote:
> 
>>> Given that uint64_aligned_t is a
>>> sensible datatype to be using with the hypercall interface, fixing the
>>> check seems to be the correct solution.
>> 
>> Sensible or not, you would have to find a way to define such a type
>> in a compiler-independent (i.e. ANSI conforming) manner, and I'm
>> afraid you won't be able to.
> 
> Yes, as barbaric as it may seem you just have to make sure that uint64_t
> gets naturally 8-byte aligned. Luckily none of our interface structures are
> particularly large, and I believe you can get them checked for 32/64-bit
> invariance by adding them to xlat.lst.

... and invoking the resultant check macro somewhere in the sources.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 14:30:50 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 14: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.xensource.com>)
	id 1RaTNR-0004g4-LS; Tue, 13 Dec 2011 14:30:41 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RaTNQ-0004fq-8R
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 14:30:40 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1323786532!60553993!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11009 invoked from network); 13 Dec 2011 14:28:53 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-7.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 13 Dec 2011 14:28:53 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 13 Dec 2011 14:29:45 +0000
Message-Id: <4EE76F6602000078000675BC@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 13 Dec 2011 14:29:42 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>,
	"Ian Jackson" <Ian.Jackson@eu.citrix.com>
References: <osstest-10481-mainreport@xen.org>
	<1323769464.20077.262.camel@zakaz.uk.xensource.com>
	<20199.14342.599850.739029@mariner.uk.xensource.com>
	<1323785260.20077.307.camel@zakaz.uk.xensource.com>
	<20199.24357.180937.882607@mariner.uk.xensource.com>
In-Reply-To: <20199.24357.180937.882607@mariner.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [xen-unstable test] 10481: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 13.12.11 at 15:20, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote:
> Ian Campbell writes ("Re: [Xen-devel] [xen-unstable test] 10481: regressions - 
> FAIL"):
>> I was about half way through implementing this when it occurred to me
>> that the reaction to a power button press is a guest OS option and can
>> result in a shutdown, a reboot or even a suspend.
>> 
>> Unless I'm mistaken?
> 
> Firstly, aren't there several possible indications we could send, in
> which case we pick one most likely to make the guest shut down ?
> 
> Secondly, having the guest attempt to reboot is probably better than
> simply shooting it in the head.  (We could even intercept that and
> have it be destroyed anyway.)

That would be acceptable when picking between shutdown and reboot,
but converting a guest attempt to suspend (to RAM) into shutdown
certainly isn't.

> At least this way if the user wants
> graceful shutdown they can configure the guest to do a shutdown and
> then xl shutdown will work.
> 
> At the moment it doesn't work at all without pv drivers.

Isn't that the way it is intended to be?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 14:30:50 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 14: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.xensource.com>)
	id 1RaTNR-0004g4-LS; Tue, 13 Dec 2011 14:30:41 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RaTNQ-0004fq-8R
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 14:30:40 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1323786532!60553993!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11009 invoked from network); 13 Dec 2011 14:28:53 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-7.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 13 Dec 2011 14:28:53 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 13 Dec 2011 14:29:45 +0000
Message-Id: <4EE76F6602000078000675BC@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 13 Dec 2011 14:29:42 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>,
	"Ian Jackson" <Ian.Jackson@eu.citrix.com>
References: <osstest-10481-mainreport@xen.org>
	<1323769464.20077.262.camel@zakaz.uk.xensource.com>
	<20199.14342.599850.739029@mariner.uk.xensource.com>
	<1323785260.20077.307.camel@zakaz.uk.xensource.com>
	<20199.24357.180937.882607@mariner.uk.xensource.com>
In-Reply-To: <20199.24357.180937.882607@mariner.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [xen-unstable test] 10481: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 13.12.11 at 15:20, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote:
> Ian Campbell writes ("Re: [Xen-devel] [xen-unstable test] 10481: regressions - 
> FAIL"):
>> I was about half way through implementing this when it occurred to me
>> that the reaction to a power button press is a guest OS option and can
>> result in a shutdown, a reboot or even a suspend.
>> 
>> Unless I'm mistaken?
> 
> Firstly, aren't there several possible indications we could send, in
> which case we pick one most likely to make the guest shut down ?
> 
> Secondly, having the guest attempt to reboot is probably better than
> simply shooting it in the head.  (We could even intercept that and
> have it be destroyed anyway.)

That would be acceptable when picking between shutdown and reboot,
but converting a guest attempt to suspend (to RAM) into shutdown
certainly isn't.

> At least this way if the user wants
> graceful shutdown they can configure the guest to do a shutdown and
> then xl shutdown will work.
> 
> At the moment it doesn't work at all without pv drivers.

Isn't that the way it is intended to be?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 14:33:21 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 14:33:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaTPp-0004s1-Fy; Tue, 13 Dec 2011 14:33:09 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RaTPo-0004rj-7F
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 14:33:08 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1323786732!7065700!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjAzMzQ=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21431 invoked from network); 13 Dec 2011 14:32:13 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 14:32:13 -0000
X-IronPort-AV: E=Sophos;i="4.71,345,1320642000"; d="scan'208";a="173946472"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Dec 2011 09:32:12 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Tue, 13 Dec 2011 09:32:12 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pBDEWAX3027848;	Tue, 13 Dec 2011 06:32:10 -0800
MIME-Version: 1.0
X-Mercurial-Node: 1a48c8fbcae917bed86f861c26bcca8638905efe
Message-ID: <1a48c8fbcae917bed86f.1323786729@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Tue, 13 Dec 2011 14:32:09 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com, Andrew Pounce <andrew.pounce@citrix.com>,
	Adda Rathbone <addarathbone@googlemail.com>
Subject: [Xen-devel] [PATCH] libxl: Compile with -Wformat-nonliteral
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1323786705 0
# Node ID 1a48c8fbcae917bed86f861c26bcca8638905efe
# Parent  f28c55c5a90aacef252bd7100aa4ceb4c2077f0b
libxl: Compile with -Wformat-nonliteral.

At least one compiler (some Ubuntu version) uses this by default and it seems
like a good idea anyway and the fixup required is trivial.

One hunk is from a patch by Ian Jackson.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Reported-by: Adda Rathbone <addarathbone@googlemail.com>
Tested-by: Adda Rathbone <addarathbone@googlemail.com>
Tested-by: Andrew Pounce <andrew.pounce@citrix.com>

diff -r f28c55c5a90a -r 1a48c8fbcae9 tools/libxl/Makefile
--- a/tools/libxl/Makefile	Tue Dec 13 14:20:00 2011 +0000
+++ b/tools/libxl/Makefile	Tue Dec 13 14:31:45 2011 +0000
@@ -12,7 +12,7 @@ XLUMAJOR = 1.0
 XLUMINOR = 0
 
 CFLAGS += -Werror -Wno-format-zero-length -Wmissing-declarations \
-	-Wno-declaration-after-statement
+	-Wno-declaration-after-statement -Wformat-nonliteral
 CFLAGS += -I. -fPIC
 
 ifeq ($(CONFIG_Linux),y)
diff -r f28c55c5a90a -r 1a48c8fbcae9 tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Tue Dec 13 14:20:00 2011 +0000
+++ b/tools/libxl/libxl_create.c	Tue Dec 13 14:31:45 2011 +0000
@@ -459,8 +459,8 @@ static int store_libxl_entry(libxl__gc *
 
     path = libxl__xs_libxl_path(gc, domid);
     path = libxl__sprintf(gc, "%s/dm-version", path);
-    return libxl__xs_write(gc, XBT_NULL, path, "%s", libxl__strdup(gc,
-        libxl_device_model_version_to_string(dm_info->device_model_version)));
+    return libxl__xs_write(gc, XBT_NULL, path, "%s",
+        libxl_device_model_version_to_string(dm_info->device_model_version));
 }
 
 static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
diff -r f28c55c5a90a -r 1a48c8fbcae9 tools/libxl/libxl_device.c
--- a/tools/libxl/libxl_device.c	Tue Dec 13 14:20:00 2011 +0000
+++ b/tools/libxl/libxl_device.c	Tue Dec 13 14:31:45 2011 +0000
@@ -515,7 +515,7 @@ int libxl__devices_destroy(libxl__gc *gc
         for (j = 0; j < num_devs; j++) {
             path = libxl__sprintf(gc, "/local/domain/%d/device/%s/%s/backend",
                                   domid, kinds[i], devs[j]);
-            path = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s", path));
+            path = libxl__xs_read(gc, XBT_NULL, path);
             if (path && libxl__parse_backend_path(gc, path, &dev) == 0) {
                 dev.domid = domid;
                 dev.kind = kind;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 14:33:21 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 14:33:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaTPp-0004s1-Fy; Tue, 13 Dec 2011 14:33:09 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RaTPo-0004rj-7F
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 14:33:08 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1323786732!7065700!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjAzMzQ=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21431 invoked from network); 13 Dec 2011 14:32:13 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 14:32:13 -0000
X-IronPort-AV: E=Sophos;i="4.71,345,1320642000"; d="scan'208";a="173946472"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Dec 2011 09:32:12 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Tue, 13 Dec 2011 09:32:12 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pBDEWAX3027848;	Tue, 13 Dec 2011 06:32:10 -0800
MIME-Version: 1.0
X-Mercurial-Node: 1a48c8fbcae917bed86f861c26bcca8638905efe
Message-ID: <1a48c8fbcae917bed86f.1323786729@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Tue, 13 Dec 2011 14:32:09 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com, Andrew Pounce <andrew.pounce@citrix.com>,
	Adda Rathbone <addarathbone@googlemail.com>
Subject: [Xen-devel] [PATCH] libxl: Compile with -Wformat-nonliteral
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1323786705 0
# Node ID 1a48c8fbcae917bed86f861c26bcca8638905efe
# Parent  f28c55c5a90aacef252bd7100aa4ceb4c2077f0b
libxl: Compile with -Wformat-nonliteral.

At least one compiler (some Ubuntu version) uses this by default and it seems
like a good idea anyway and the fixup required is trivial.

One hunk is from a patch by Ian Jackson.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Reported-by: Adda Rathbone <addarathbone@googlemail.com>
Tested-by: Adda Rathbone <addarathbone@googlemail.com>
Tested-by: Andrew Pounce <andrew.pounce@citrix.com>

diff -r f28c55c5a90a -r 1a48c8fbcae9 tools/libxl/Makefile
--- a/tools/libxl/Makefile	Tue Dec 13 14:20:00 2011 +0000
+++ b/tools/libxl/Makefile	Tue Dec 13 14:31:45 2011 +0000
@@ -12,7 +12,7 @@ XLUMAJOR = 1.0
 XLUMINOR = 0
 
 CFLAGS += -Werror -Wno-format-zero-length -Wmissing-declarations \
-	-Wno-declaration-after-statement
+	-Wno-declaration-after-statement -Wformat-nonliteral
 CFLAGS += -I. -fPIC
 
 ifeq ($(CONFIG_Linux),y)
diff -r f28c55c5a90a -r 1a48c8fbcae9 tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Tue Dec 13 14:20:00 2011 +0000
+++ b/tools/libxl/libxl_create.c	Tue Dec 13 14:31:45 2011 +0000
@@ -459,8 +459,8 @@ static int store_libxl_entry(libxl__gc *
 
     path = libxl__xs_libxl_path(gc, domid);
     path = libxl__sprintf(gc, "%s/dm-version", path);
-    return libxl__xs_write(gc, XBT_NULL, path, "%s", libxl__strdup(gc,
-        libxl_device_model_version_to_string(dm_info->device_model_version)));
+    return libxl__xs_write(gc, XBT_NULL, path, "%s",
+        libxl_device_model_version_to_string(dm_info->device_model_version));
 }
 
 static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
diff -r f28c55c5a90a -r 1a48c8fbcae9 tools/libxl/libxl_device.c
--- a/tools/libxl/libxl_device.c	Tue Dec 13 14:20:00 2011 +0000
+++ b/tools/libxl/libxl_device.c	Tue Dec 13 14:31:45 2011 +0000
@@ -515,7 +515,7 @@ int libxl__devices_destroy(libxl__gc *gc
         for (j = 0; j < num_devs; j++) {
             path = libxl__sprintf(gc, "/local/domain/%d/device/%s/%s/backend",
                                   domid, kinds[i], devs[j]);
-            path = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s", path));
+            path = libxl__xs_read(gc, XBT_NULL, path);
             if (path && libxl__parse_backend_path(gc, path, &dev) == 0) {
                 dev.domid = domid;
                 dev.kind = kind;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 14:35:48 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 14:35:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaTSF-00050D-1z; Tue, 13 Dec 2011 14:35:39 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1RaTSE-000506-5d
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 14:35:38 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1323786853!52248950!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjAzMzQ=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26159 invoked from network); 13 Dec 2011 14:34:14 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 14:34:14 -0000
X-IronPort-AV: E=Sophos;i="4.71,345,1320642000"; d="scan'208";a="173946950"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Dec 2011 09:34:27 -0500
Received: from [10.80.2.18] (10.80.2.18) by FTLPMAILMX02.citrite.net
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Tue, 13 Dec 2011
	09:34:26 -0500
Message-ID: <4EE76271.7090509@citrix.com>
Date: Tue, 13 Dec 2011 14:34:25 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.23) Gecko/20110921 Lightning/1.0b2 Thunderbird/3.1.15
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>, "Keir (Xen.org)" <keir@xen.org>
References: <4EE76C7E0200007800067541@nat28.tlf.novell.com>
	<CB0D0FF6.35BAD%keir@xen.org>
	<4EE76E7D020000780006758F@nat28.tlf.novell.com>
In-Reply-To: <4EE76E7D020000780006758F@nat28.tlf.novell.com>
X-Enigmail-Version: 1.1.2
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] headers.chk failing under certain circumstances.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 13/12/11 14:25, Jan Beulich wrote:
>>>> On 13.12.11 at 15:21, Keir Fraser <keir@xen.org> wrote:
>> On 13/12/2011 14:17, "Jan Beulich" <JBeulich@suse.com> wrote:
>>
>>>> Given that uint64_aligned_t is a
>>>> sensible datatype to be using with the hypercall interface, fixing the
>>>> check seems to be the correct solution.
>>> Sensible or not, you would have to find a way to define such a type
>>> in a compiler-independent (i.e. ANSI conforming) manner, and I'm
>>> afraid you won't be able to.
>> Yes, as barbaric as it may seem you just have to make sure that uint64_t
>> gets naturally 8-byte aligned. Luckily none of our interface structures are
>> particularly large, and I believe you can get them checked for 32/64-bit
>> invariance by adding them to xlat.lst.
> ... and invoking the resultant check macro somewhere in the sources.
>
> Jan

Righ ok.  Thanks for the explanation.

Luckily, it appears that all my uint64_t's do actually align on 8 bytes
so I will just use that.

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 14:35:48 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 14:35:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaTSF-00050D-1z; Tue, 13 Dec 2011 14:35:39 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1RaTSE-000506-5d
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 14:35:38 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1323786853!52248950!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjAzMzQ=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26159 invoked from network); 13 Dec 2011 14:34:14 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 14:34:14 -0000
X-IronPort-AV: E=Sophos;i="4.71,345,1320642000"; d="scan'208";a="173946950"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Dec 2011 09:34:27 -0500
Received: from [10.80.2.18] (10.80.2.18) by FTLPMAILMX02.citrite.net
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Tue, 13 Dec 2011
	09:34:26 -0500
Message-ID: <4EE76271.7090509@citrix.com>
Date: Tue, 13 Dec 2011 14:34:25 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.23) Gecko/20110921 Lightning/1.0b2 Thunderbird/3.1.15
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>, "Keir (Xen.org)" <keir@xen.org>
References: <4EE76C7E0200007800067541@nat28.tlf.novell.com>
	<CB0D0FF6.35BAD%keir@xen.org>
	<4EE76E7D020000780006758F@nat28.tlf.novell.com>
In-Reply-To: <4EE76E7D020000780006758F@nat28.tlf.novell.com>
X-Enigmail-Version: 1.1.2
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] headers.chk failing under certain circumstances.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 13/12/11 14:25, Jan Beulich wrote:
>>>> On 13.12.11 at 15:21, Keir Fraser <keir@xen.org> wrote:
>> On 13/12/2011 14:17, "Jan Beulich" <JBeulich@suse.com> wrote:
>>
>>>> Given that uint64_aligned_t is a
>>>> sensible datatype to be using with the hypercall interface, fixing the
>>>> check seems to be the correct solution.
>>> Sensible or not, you would have to find a way to define such a type
>>> in a compiler-independent (i.e. ANSI conforming) manner, and I'm
>>> afraid you won't be able to.
>> Yes, as barbaric as it may seem you just have to make sure that uint64_t
>> gets naturally 8-byte aligned. Luckily none of our interface structures are
>> particularly large, and I believe you can get them checked for 32/64-bit
>> invariance by adding them to xlat.lst.
> ... and invoking the resultant check macro somewhere in the sources.
>
> Jan

Righ ok.  Thanks for the explanation.

Luckily, it appears that all my uint64_t's do actually align on 8 bytes
so I will just use that.

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 14:45:41 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 14:45:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaTbj-0005GD-6B; Tue, 13 Dec 2011 14:45:27 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RaTbh-0005G8-TT
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 14:45:26 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1323786461!7171074!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTI1NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6019 invoked from network); 13 Dec 2011 14:27:42 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 14:27:42 -0000
X-IronPort-AV: E=Sophos;i="4.71,345,1320624000"; 
   d="scan'208";a="9442419"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Dec 2011 14:27:41 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 13 Dec 2011 14:27:41 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 13 Dec 2011 14:27:41 +0000
In-Reply-To: <20199.24357.180937.882607@mariner.uk.xensource.com>
References: <osstest-10481-mainreport@xen.org>
	<1323769464.20077.262.camel@zakaz.uk.xensource.com>
	<20199.14342.599850.739029@mariner.uk.xensource.com>
	<1323785260.20077.307.camel@zakaz.uk.xensource.com>
	<20199.24357.180937.882607@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323786461.20077.312.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [xen-unstable test] 10481: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2011-12-13 at 14:20 +0000, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [xen-unstable test] 10481: regressions - FAIL"):
> > I was about half way through implementing this when it occurred to me
> > that the reaction to a power button press is a guest OS option and can
> > result in a shutdown, a reboot or even a suspend.
> > 
> > Unless I'm mistaken?
> 
> Firstly, aren't there several possible indications we could send, in
> which case we pick one most likely to make the guest shut down ?

The choices are (omitting the ia64 only ones):
xen/include/public/domctl.h:#define XEN_DOMCTL_SENDTRIGGER_NMI    0
xen/include/public/domctl.h:#define XEN_DOMCTL_SENDTRIGGER_POWER  3
xen/include/public/domctl.h:#define XEN_DOMCTL_SENDTRIGGER_SLEEP  4

Of those I think POWER is the only appropriate one and we have no
control over what it will actually do.

> Secondly, having the guest attempt to reboot is probably better than
> simply shooting it in the head.  (We could even intercept that and
> have it be destroyed anyway.)  At least this way if the user wants
> graceful shutdown they can configure the guest to do a shutdown and
> then xl shutdown will work.
> 
> At the moment it doesn't work at all without pv drivers.

You can explicitly ask for a power button event with "xl button-press".
At a minimum the error message should point to this in preference to
destroy.

You can also send the same event with "xl trigger". Quite why we need
two ways to do this I've no idea...

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 14:45:41 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 14:45:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaTbj-0005GD-6B; Tue, 13 Dec 2011 14:45:27 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RaTbh-0005G8-TT
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 14:45:26 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1323786461!7171074!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTI1NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6019 invoked from network); 13 Dec 2011 14:27:42 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 14:27:42 -0000
X-IronPort-AV: E=Sophos;i="4.71,345,1320624000"; 
   d="scan'208";a="9442419"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Dec 2011 14:27:41 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 13 Dec 2011 14:27:41 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 13 Dec 2011 14:27:41 +0000
In-Reply-To: <20199.24357.180937.882607@mariner.uk.xensource.com>
References: <osstest-10481-mainreport@xen.org>
	<1323769464.20077.262.camel@zakaz.uk.xensource.com>
	<20199.14342.599850.739029@mariner.uk.xensource.com>
	<1323785260.20077.307.camel@zakaz.uk.xensource.com>
	<20199.24357.180937.882607@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323786461.20077.312.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [xen-unstable test] 10481: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2011-12-13 at 14:20 +0000, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [xen-unstable test] 10481: regressions - FAIL"):
> > I was about half way through implementing this when it occurred to me
> > that the reaction to a power button press is a guest OS option and can
> > result in a shutdown, a reboot or even a suspend.
> > 
> > Unless I'm mistaken?
> 
> Firstly, aren't there several possible indications we could send, in
> which case we pick one most likely to make the guest shut down ?

The choices are (omitting the ia64 only ones):
xen/include/public/domctl.h:#define XEN_DOMCTL_SENDTRIGGER_NMI    0
xen/include/public/domctl.h:#define XEN_DOMCTL_SENDTRIGGER_POWER  3
xen/include/public/domctl.h:#define XEN_DOMCTL_SENDTRIGGER_SLEEP  4

Of those I think POWER is the only appropriate one and we have no
control over what it will actually do.

> Secondly, having the guest attempt to reboot is probably better than
> simply shooting it in the head.  (We could even intercept that and
> have it be destroyed anyway.)  At least this way if the user wants
> graceful shutdown they can configure the guest to do a shutdown and
> then xl shutdown will work.
> 
> At the moment it doesn't work at all without pv drivers.

You can explicitly ask for a power button event with "xl button-press".
At a minimum the error message should point to this in preference to
destroy.

You can also send the same event with "xl trigger". Quite why we need
two ways to do this I've no idea...

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 14:50:09 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 14:50:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaTg2-0005Oc-T8; Tue, 13 Dec 2011 14:49:54 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RaTg1-0005OM-4Z
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 14:49:53 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1323787730!8083232!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTI1NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11767 invoked from network); 13 Dec 2011 14:48:51 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 14:48:51 -0000
X-IronPort-AV: E=Sophos;i="4.71,345,1320624000"; 
   d="scan'208";a="9443067"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Dec 2011 14:48:36 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 13 Dec 2011 14:48:36 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RaTel-0007BH-QC; Tue, 13 Dec 2011 14:48:35 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RaTel-0002Sg-Ow;
	Tue, 13 Dec 2011 14:48:35 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20199.26051.761880.513100@mariner.uk.xensource.com>
Date: Tue, 13 Dec 2011 14:48:35 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1323786461.20077.312.camel@zakaz.uk.xensource.com>
References: <osstest-10481-mainreport@xen.org>
	<1323769464.20077.262.camel@zakaz.uk.xensource.com>
	<20199.14342.599850.739029@mariner.uk.xensource.com>
	<1323785260.20077.307.camel@zakaz.uk.xensource.com>
	<20199.24357.180937.882607@mariner.uk.xensource.com>
	<1323786461.20077.312.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [xen-unstable test] 10481: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("Re: [Xen-devel] [xen-unstable test] 10481: regressions - FAIL"):
> The choices are (omitting the ia64 only ones):
> xen/include/public/domctl.h:#define XEN_DOMCTL_SENDTRIGGER_NMI    0
> xen/include/public/domctl.h:#define XEN_DOMCTL_SENDTRIGGER_POWER  3
> xen/include/public/domctl.h:#define XEN_DOMCTL_SENDTRIGGER_SLEEP  4
> 
> Of those I think POWER is the only appropriate one and we have no
> control over what it will actually do.

Right.

> > At the moment it doesn't work at all without pv drivers.

I think it would be better for "xl shutdown" to send a power button
event than to do nothing and print an error message.

> You can explicitly ask for a power button event with "xl button-press".
> At a minimum the error message should point to this in preference to
> destroy.

That would be a better improvement.

> You can also send the same event with "xl trigger". Quite why we need
> two ways to do this I've no idea...

Hmmm.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 14:50:09 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 14:50:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaTg2-0005Oc-T8; Tue, 13 Dec 2011 14:49:54 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RaTg1-0005OM-4Z
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 14:49:53 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1323787730!8083232!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTI1NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11767 invoked from network); 13 Dec 2011 14:48:51 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 14:48:51 -0000
X-IronPort-AV: E=Sophos;i="4.71,345,1320624000"; 
   d="scan'208";a="9443067"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Dec 2011 14:48:36 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 13 Dec 2011 14:48:36 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RaTel-0007BH-QC; Tue, 13 Dec 2011 14:48:35 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RaTel-0002Sg-Ow;
	Tue, 13 Dec 2011 14:48:35 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20199.26051.761880.513100@mariner.uk.xensource.com>
Date: Tue, 13 Dec 2011 14:48:35 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1323786461.20077.312.camel@zakaz.uk.xensource.com>
References: <osstest-10481-mainreport@xen.org>
	<1323769464.20077.262.camel@zakaz.uk.xensource.com>
	<20199.14342.599850.739029@mariner.uk.xensource.com>
	<1323785260.20077.307.camel@zakaz.uk.xensource.com>
	<20199.24357.180937.882607@mariner.uk.xensource.com>
	<1323786461.20077.312.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [xen-unstable test] 10481: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("Re: [Xen-devel] [xen-unstable test] 10481: regressions - FAIL"):
> The choices are (omitting the ia64 only ones):
> xen/include/public/domctl.h:#define XEN_DOMCTL_SENDTRIGGER_NMI    0
> xen/include/public/domctl.h:#define XEN_DOMCTL_SENDTRIGGER_POWER  3
> xen/include/public/domctl.h:#define XEN_DOMCTL_SENDTRIGGER_SLEEP  4
> 
> Of those I think POWER is the only appropriate one and we have no
> control over what it will actually do.

Right.

> > At the moment it doesn't work at all without pv drivers.

I think it would be better for "xl shutdown" to send a power button
event than to do nothing and print an error message.

> You can explicitly ask for a power button event with "xl button-press".
> At a minimum the error message should point to this in preference to
> destroy.

That would be a better improvement.

> You can also send the same event with "xl trigger". Quite why we need
> two ways to do this I've no idea...

Hmmm.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 14:52:37 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 14:52:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaTiQ-0005WV-Ft; Tue, 13 Dec 2011 14:52:22 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RaTiP-0005WC-GR
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 14:52:21 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1323787886!5359926!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTI1NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29851 invoked from network); 13 Dec 2011 14:51:27 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 14:51:27 -0000
X-IronPort-AV: E=Sophos;i="4.71,345,1320624000"; 
   d="scan'208";a="9443152"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Dec 2011 14:51:26 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 13 Dec 2011 14:51:26 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 13 Dec 2011 14:51:26 +0000
In-Reply-To: <20199.26051.761880.513100@mariner.uk.xensource.com>
References: <osstest-10481-mainreport@xen.org>
	<1323769464.20077.262.camel@zakaz.uk.xensource.com>
	<20199.14342.599850.739029@mariner.uk.xensource.com>
	<1323785260.20077.307.camel@zakaz.uk.xensource.com>
	<20199.24357.180937.882607@mariner.uk.xensource.com>
	<1323786461.20077.312.camel@zakaz.uk.xensource.com>
	<20199.26051.761880.513100@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323787886.20077.314.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [xen-unstable test] 10481: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2011-12-13 at 14:48 +0000, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [xen-unstable test] 10481: regressions - FAIL"):
> > The choices are (omitting the ia64 only ones):
> > xen/include/public/domctl.h:#define XEN_DOMCTL_SENDTRIGGER_NMI    0
> > xen/include/public/domctl.h:#define XEN_DOMCTL_SENDTRIGGER_POWER  3
> > xen/include/public/domctl.h:#define XEN_DOMCTL_SENDTRIGGER_SLEEP  4
> > 
> > Of those I think POWER is the only appropriate one and we have no
> > control over what it will actually do.
> 
> Right.
> 
> > > At the moment it doesn't work at all without pv drivers.
> 
> I think it would be better for "xl shutdown" to send a power button
> event than to do nothing and print an error message.
> 
> > You can explicitly ask for a power button event with "xl button-press".
> > At a minimum the error message should point to this in preference to
> > destroy.
> 
> That would be a better improvement.

So which do you prefer? An error message pointing to "xl button-press"
or sending the button press?

Ian.

> 
> > You can also send the same event with "xl trigger". Quite why we need
> > two ways to do this I've no idea...
> 
> Hmmm.
> 
> Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 14:52:37 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 14:52:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaTiQ-0005WV-Ft; Tue, 13 Dec 2011 14:52:22 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RaTiP-0005WC-GR
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 14:52:21 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1323787886!5359926!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTI1NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29851 invoked from network); 13 Dec 2011 14:51:27 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 14:51:27 -0000
X-IronPort-AV: E=Sophos;i="4.71,345,1320624000"; 
   d="scan'208";a="9443152"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Dec 2011 14:51:26 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 13 Dec 2011 14:51:26 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 13 Dec 2011 14:51:26 +0000
In-Reply-To: <20199.26051.761880.513100@mariner.uk.xensource.com>
References: <osstest-10481-mainreport@xen.org>
	<1323769464.20077.262.camel@zakaz.uk.xensource.com>
	<20199.14342.599850.739029@mariner.uk.xensource.com>
	<1323785260.20077.307.camel@zakaz.uk.xensource.com>
	<20199.24357.180937.882607@mariner.uk.xensource.com>
	<1323786461.20077.312.camel@zakaz.uk.xensource.com>
	<20199.26051.761880.513100@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323787886.20077.314.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [xen-unstable test] 10481: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2011-12-13 at 14:48 +0000, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [xen-unstable test] 10481: regressions - FAIL"):
> > The choices are (omitting the ia64 only ones):
> > xen/include/public/domctl.h:#define XEN_DOMCTL_SENDTRIGGER_NMI    0
> > xen/include/public/domctl.h:#define XEN_DOMCTL_SENDTRIGGER_POWER  3
> > xen/include/public/domctl.h:#define XEN_DOMCTL_SENDTRIGGER_SLEEP  4
> > 
> > Of those I think POWER is the only appropriate one and we have no
> > control over what it will actually do.
> 
> Right.
> 
> > > At the moment it doesn't work at all without pv drivers.
> 
> I think it would be better for "xl shutdown" to send a power button
> event than to do nothing and print an error message.
> 
> > You can explicitly ask for a power button event with "xl button-press".
> > At a minimum the error message should point to this in preference to
> > destroy.
> 
> That would be a better improvement.

So which do you prefer? An error message pointing to "xl button-press"
or sending the button press?

Ian.

> 
> > You can also send the same event with "xl trigger". Quite why we need
> > two ways to do this I've no idea...
> 
> Hmmm.
> 
> Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 14:55:00 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 14:55:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaTkh-0005hC-2L; Tue, 13 Dec 2011 14:54:43 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RaTkf-0005gj-3b
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 14:54:41 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1323788025!5360337!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTI1NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6709 invoked from network); 13 Dec 2011 14:53:46 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 14:53:46 -0000
X-IronPort-AV: E=Sophos;i="4.71,345,1320624000"; 
   d="scan'208";a="9443217"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Dec 2011 14:53:22 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 13 Dec 2011 14:53:22 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RaTjO-0007D2-BB; Tue, 13 Dec 2011 14:53:22 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RaTjO-0002TO-AK;
	Tue, 13 Dec 2011 14:53:22 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20199.26338.308105.913566@mariner.uk.xensource.com>
Date: Tue, 13 Dec 2011 14:53:22 +0000
To: Roger Pau =?iso-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <CAPLaKK5+Cup9w5HJKhMmu7RQG=EDp_FL8kjHQuaUW9PX373R=A@mail.gmail.com>
References: <7697ee23b08b8eaca9ae.1323768649@loki.upc.es>
	<1323770544.20077.268.camel@zakaz.uk.xensource.com>
	<4EE72B7C.7030006@redhat.com>
	<CAPLaKK5+Cup9w5HJKhMmu7RQG=EDp_FL8kjHQuaUW9PX373R=A@mail.gmail.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Laszlo Ersek <lersek@redhat.com>, Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH] xenpaging: remove XOPEN_SOURCE
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Roger Pau Monn=E9 writes ("Re: [Xen-devel] [PATCH] xenpaging: remove XOPEN_=
SOURCE"):
> 2011/12/13 Laszlo Ersek <lersek@redhat.com>:
> > The stuff made visible by _GNU_SOURCE (with glibc) includes everything
> > _XOPEN_SOURCE makes visible [3]. [4] introduced it because of asprintf(=
).
> =

> If it's not necessary I think it's best to remove the definition, to
> avoid having a lot of useless defines all over the code.

I disagree.  The purpose of these kind of macros is purely to allow
systems to claim standards-compliance and absence of namespace
pollution, by default.

The logical conclusion is that these kind of problems should be fixed
by adding more requests for platform-specific features, not removing
them.

In this case that would mean adding:
 #define _NETBSD_SOURCE

If the prevalance of these kind of macros is getting irritating they
can easily be moved into a common header file somewhere.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 14:55:00 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 14:55:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaTkh-0005hC-2L; Tue, 13 Dec 2011 14:54:43 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RaTkf-0005gj-3b
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 14:54:41 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1323788025!5360337!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTI1NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6709 invoked from network); 13 Dec 2011 14:53:46 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 14:53:46 -0000
X-IronPort-AV: E=Sophos;i="4.71,345,1320624000"; 
   d="scan'208";a="9443217"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Dec 2011 14:53:22 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 13 Dec 2011 14:53:22 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RaTjO-0007D2-BB; Tue, 13 Dec 2011 14:53:22 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RaTjO-0002TO-AK;
	Tue, 13 Dec 2011 14:53:22 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20199.26338.308105.913566@mariner.uk.xensource.com>
Date: Tue, 13 Dec 2011 14:53:22 +0000
To: Roger Pau =?iso-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <CAPLaKK5+Cup9w5HJKhMmu7RQG=EDp_FL8kjHQuaUW9PX373R=A@mail.gmail.com>
References: <7697ee23b08b8eaca9ae.1323768649@loki.upc.es>
	<1323770544.20077.268.camel@zakaz.uk.xensource.com>
	<4EE72B7C.7030006@redhat.com>
	<CAPLaKK5+Cup9w5HJKhMmu7RQG=EDp_FL8kjHQuaUW9PX373R=A@mail.gmail.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Laszlo Ersek <lersek@redhat.com>, Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH] xenpaging: remove XOPEN_SOURCE
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Roger Pau Monn=E9 writes ("Re: [Xen-devel] [PATCH] xenpaging: remove XOPEN_=
SOURCE"):
> 2011/12/13 Laszlo Ersek <lersek@redhat.com>:
> > The stuff made visible by _GNU_SOURCE (with glibc) includes everything
> > _XOPEN_SOURCE makes visible [3]. [4] introduced it because of asprintf(=
).
> =

> If it's not necessary I think it's best to remove the definition, to
> avoid having a lot of useless defines all over the code.

I disagree.  The purpose of these kind of macros is purely to allow
systems to claim standards-compliance and absence of namespace
pollution, by default.

The logical conclusion is that these kind of problems should be fixed
by adding more requests for platform-specific features, not removing
them.

In this case that would mean adding:
 #define _NETBSD_SOURCE

If the prevalance of these kind of macros is getting irritating they
can easily be moved into a common header file somewhere.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 14:55:22 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 14:55:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaTlD-0005ke-N2; Tue, 13 Dec 2011 14:55:15 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RaTlD-0005k1-5Z
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 14:55:15 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1323788060!5185696!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTI1NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6091 invoked from network); 13 Dec 2011 14:54:20 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 14:54:20 -0000
X-IronPort-AV: E=Sophos;i="4.71,345,1320624000"; 
   d="scan'208";a="9443247"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Dec 2011 14:54:12 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 13 Dec 2011 14:54:12 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RaTkC-0007DP-7d; Tue, 13 Dec 2011 14:54:12 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RaTkC-0002TW-6u;
	Tue, 13 Dec 2011 14:54:12 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20199.26388.187010.379029@mariner.uk.xensource.com>
Date: Tue, 13 Dec 2011 14:54:12 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1323787886.20077.314.camel@zakaz.uk.xensource.com>
References: <osstest-10481-mainreport@xen.org>
	<1323769464.20077.262.camel@zakaz.uk.xensource.com>
	<20199.14342.599850.739029@mariner.uk.xensource.com>
	<1323785260.20077.307.camel@zakaz.uk.xensource.com>
	<20199.24357.180937.882607@mariner.uk.xensource.com>
	<1323786461.20077.312.camel@zakaz.uk.xensource.com>
	<20199.26051.761880.513100@mariner.uk.xensource.com>
	<1323787886.20077.314.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [xen-unstable test] 10481: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("Re: [Xen-devel] [xen-unstable test] 10481: regressions - FAIL"):
> On Tue, 2011-12-13 at 14:48 +0000, Ian Jackson wrote:
> > Ian Campbell writes ("Re: [Xen-devel] [xen-unstable test] 10481: regressions - FAIL"):
> > > You can explicitly ask for a power button event with "xl button-press".
> > > At a minimum the error message should point to this in preference to
> > > destroy.
> > 
> > That would be a better improvement.
> 
> So which do you prefer? An error message pointing to "xl button-press"
> or sending the button press?

Sorry, I misphrased my email.  I should have said that would be a
"minimal improvement".  I would prefer "xl shutdown" to send the
button press.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 14:55:22 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 14:55:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaTlD-0005ke-N2; Tue, 13 Dec 2011 14:55:15 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RaTlD-0005k1-5Z
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 14:55:15 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1323788060!5185696!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTI1NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6091 invoked from network); 13 Dec 2011 14:54:20 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 14:54:20 -0000
X-IronPort-AV: E=Sophos;i="4.71,345,1320624000"; 
   d="scan'208";a="9443247"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Dec 2011 14:54:12 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 13 Dec 2011 14:54:12 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RaTkC-0007DP-7d; Tue, 13 Dec 2011 14:54:12 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RaTkC-0002TW-6u;
	Tue, 13 Dec 2011 14:54:12 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20199.26388.187010.379029@mariner.uk.xensource.com>
Date: Tue, 13 Dec 2011 14:54:12 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1323787886.20077.314.camel@zakaz.uk.xensource.com>
References: <osstest-10481-mainreport@xen.org>
	<1323769464.20077.262.camel@zakaz.uk.xensource.com>
	<20199.14342.599850.739029@mariner.uk.xensource.com>
	<1323785260.20077.307.camel@zakaz.uk.xensource.com>
	<20199.24357.180937.882607@mariner.uk.xensource.com>
	<1323786461.20077.312.camel@zakaz.uk.xensource.com>
	<20199.26051.761880.513100@mariner.uk.xensource.com>
	<1323787886.20077.314.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [xen-unstable test] 10481: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("Re: [Xen-devel] [xen-unstable test] 10481: regressions - FAIL"):
> On Tue, 2011-12-13 at 14:48 +0000, Ian Jackson wrote:
> > Ian Campbell writes ("Re: [Xen-devel] [xen-unstable test] 10481: regressions - FAIL"):
> > > You can explicitly ask for a power button event with "xl button-press".
> > > At a minimum the error message should point to this in preference to
> > > destroy.
> > 
> > That would be a better improvement.
> 
> So which do you prefer? An error message pointing to "xl button-press"
> or sending the button press?

Sorry, I misphrased my email.  I should have said that would be a
"minimal improvement".  I would prefer "xl shutdown" to send the
button press.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 15:00:38 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 15:00:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaTqE-00068O-Gy; Tue, 13 Dec 2011 15:00:26 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RaTqD-00068H-FS
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 15:00:25 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1323788369!7082993!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTI1NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32143 invoked from network); 13 Dec 2011 14:59:30 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 14:59:30 -0000
X-IronPort-AV: E=Sophos;i="4.71,345,1320624000"; 
   d="scan'208";a="9443400"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Dec 2011 14:59:28 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 13 Dec 2011 14:59:28 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RaTpI-0007FE-8S; Tue, 13 Dec 2011 14:59:28 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RaTpI-0002Tz-71;
	Tue, 13 Dec 2011 14:59:28 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20199.26704.180513.152682@mariner.uk.xensource.com>
Date: Tue, 13 Dec 2011 14:59:28 +0000
To: Roger Pau Monne <roger.pau@entel.upc.edu>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <d5f1ab565bf64c98c047.1323768379@loki.upc.es>
References: <patchbomb.1323768375@loki.upc.es>
	<d5f1ab565bf64c98c047.1323768379@loki.upc.es>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 04 of 14 v4] libxl:
	introduce	libxl__wait_for_device_state
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Roger Pau Monne writes ("[Xen-devel] [PATCH 04 of 14 v4] libxl: introduce libxl__wait_for_device_state"):
> libxl: introduce libxl__wait_for_device_state
> 
> This is a generic function, that waits for xs watches to reach a
> certain state and then executes the passed helper function. Removed
> wait_for_dev_destroy and used this new function instead. This
> function will also be used by future patches that need to wait for
> the initialization of devices before executing hotplug scripts.

I think this is a reasonable step forwards.

However, given my plans for new asynchronous event handling, this
function will have to be turned half-inside-out by me shortly.  So
under the circumstances I don't propose to review it very closely
now.

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 15:00:38 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 15:00:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaTqE-00068O-Gy; Tue, 13 Dec 2011 15:00:26 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RaTqD-00068H-FS
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 15:00:25 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1323788369!7082993!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTI1NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32143 invoked from network); 13 Dec 2011 14:59:30 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 14:59:30 -0000
X-IronPort-AV: E=Sophos;i="4.71,345,1320624000"; 
   d="scan'208";a="9443400"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Dec 2011 14:59:28 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 13 Dec 2011 14:59:28 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RaTpI-0007FE-8S; Tue, 13 Dec 2011 14:59:28 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RaTpI-0002Tz-71;
	Tue, 13 Dec 2011 14:59:28 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20199.26704.180513.152682@mariner.uk.xensource.com>
Date: Tue, 13 Dec 2011 14:59:28 +0000
To: Roger Pau Monne <roger.pau@entel.upc.edu>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <d5f1ab565bf64c98c047.1323768379@loki.upc.es>
References: <patchbomb.1323768375@loki.upc.es>
	<d5f1ab565bf64c98c047.1323768379@loki.upc.es>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 04 of 14 v4] libxl:
	introduce	libxl__wait_for_device_state
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Roger Pau Monne writes ("[Xen-devel] [PATCH 04 of 14 v4] libxl: introduce libxl__wait_for_device_state"):
> libxl: introduce libxl__wait_for_device_state
> 
> This is a generic function, that waits for xs watches to reach a
> certain state and then executes the passed helper function. Removed
> wait_for_dev_destroy and used this new function instead. This
> function will also be used by future patches that need to wait for
> the initialization of devices before executing hotplug scripts.

I think this is a reasonable step forwards.

However, given my plans for new asynchronous event handling, this
function will have to be turned half-inside-out by me shortly.  So
under the circumstances I don't propose to review it very closely
now.

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 15:01:02 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 15: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.xensource.com>)
	id 1RaTqe-0006AY-V3; Tue, 13 Dec 2011 15:00:52 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RaTqd-0006AJ-0e
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 15:00:51 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1323788362!46539530!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTI1NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23530 invoked from network); 13 Dec 2011 14:59:22 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 14:59:22 -0000
X-IronPort-AV: E=Sophos;i="4.71,345,1320624000"; 
   d="scan'208";a="9443412"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Dec 2011 15:00:01 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 13 Dec 2011 15:00:01 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RaTpp-0007FR-HB; Tue, 13 Dec 2011 15:00:01 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RaTpp-0002UG-GU;
	Tue, 13 Dec 2011 15:00:01 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20199.26737.499839.99038@mariner.uk.xensource.com>
Date: Tue, 13 Dec 2011 15:00:01 +0000
To: Roger Pau Monne <roger.pau@entel.upc.edu>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <263959b9bc339a60da11.1323768384@loki.upc.es>
References: <patchbomb.1323768375@loki.upc.es>
	<263959b9bc339a60da11.1323768384@loki.upc.es>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 09 of 14 v4] hotplug: remove debug messages
 from NetBSD hotplug scripts
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Roger Pau Monne writes ("[Xen-devel] [PATCH 09 of 14 v4] hotplug: remove debug messages from NetBSD hotplug scripts"):
> hotplug: remove debug messages from NetBSD hotplug scripts
> 
> Remove unecessary debug messages from NetBSD hotplug scripts, left
> error messages only.

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 15:01:02 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 15: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.xensource.com>)
	id 1RaTqe-0006AY-V3; Tue, 13 Dec 2011 15:00:52 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RaTqd-0006AJ-0e
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 15:00:51 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1323788362!46539530!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTI1NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23530 invoked from network); 13 Dec 2011 14:59:22 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 14:59:22 -0000
X-IronPort-AV: E=Sophos;i="4.71,345,1320624000"; 
   d="scan'208";a="9443412"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Dec 2011 15:00:01 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 13 Dec 2011 15:00:01 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RaTpp-0007FR-HB; Tue, 13 Dec 2011 15:00:01 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RaTpp-0002UG-GU;
	Tue, 13 Dec 2011 15:00:01 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20199.26737.499839.99038@mariner.uk.xensource.com>
Date: Tue, 13 Dec 2011 15:00:01 +0000
To: Roger Pau Monne <roger.pau@entel.upc.edu>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <263959b9bc339a60da11.1323768384@loki.upc.es>
References: <patchbomb.1323768375@loki.upc.es>
	<263959b9bc339a60da11.1323768384@loki.upc.es>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 09 of 14 v4] hotplug: remove debug messages
 from NetBSD hotplug scripts
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Roger Pau Monne writes ("[Xen-devel] [PATCH 09 of 14 v4] hotplug: remove debug messages from NetBSD hotplug scripts"):
> hotplug: remove debug messages from NetBSD hotplug scripts
> 
> Remove unecessary debug messages from NetBSD hotplug scripts, left
> error messages only.

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 15:02:10 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 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.xensource.com>)
	id 1RaTri-0006HY-E7; Tue, 13 Dec 2011 15:01:58 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RaTrg-0006Gs-6O
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 15:01:56 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1323788461!5186816!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTI1NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2169 invoked from network); 13 Dec 2011 15:01:02 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 15:01:02 -0000
X-IronPort-AV: E=Sophos;i="4.71,345,1320624000"; 
   d="scan'208";a="9443441"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Dec 2011 15:01:01 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 13 Dec 2011 15:01:01 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RaTqn-0007Fo-0T; Tue, 13 Dec 2011 15:01:01 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RaTqm-0002UP-Vt;
	Tue, 13 Dec 2011 15:01:00 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20199.26796.938574.235947@mariner.uk.xensource.com>
Date: Tue, 13 Dec 2011 15:01:00 +0000
To: Roger Pau Monne <roger.pau@entel.upc.edu>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <a0f9c898470cedc6d900.1323768376@loki.upc.es>
References: <patchbomb.1323768375@loki.upc.es>
	<a0f9c898470cedc6d900.1323768376@loki.upc.es>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 01 of 14 v4] xenbackendd: pass type of block
 device to hotplug script
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Roger Pau Monne writes ("[Xen-devel] [PATCH 01 of 14 v4] xenbackendd: pass type of block device to hotplug script"):
> xenbackendd: pass type of block device to hotplug script
> 
> Pass the type of block device to attach to the block script instead
> of reading it from xenstore, since new Xen versions don't make a
> difference between a block device or an image.

Why can the hotplug script not use test(1) ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 15:02:10 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 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.xensource.com>)
	id 1RaTri-0006HY-E7; Tue, 13 Dec 2011 15:01:58 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RaTrg-0006Gs-6O
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 15:01:56 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1323788461!5186816!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTI1NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2169 invoked from network); 13 Dec 2011 15:01:02 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 15:01:02 -0000
X-IronPort-AV: E=Sophos;i="4.71,345,1320624000"; 
   d="scan'208";a="9443441"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Dec 2011 15:01:01 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 13 Dec 2011 15:01:01 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RaTqn-0007Fo-0T; Tue, 13 Dec 2011 15:01:01 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RaTqm-0002UP-Vt;
	Tue, 13 Dec 2011 15:01:00 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20199.26796.938574.235947@mariner.uk.xensource.com>
Date: Tue, 13 Dec 2011 15:01:00 +0000
To: Roger Pau Monne <roger.pau@entel.upc.edu>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <a0f9c898470cedc6d900.1323768376@loki.upc.es>
References: <patchbomb.1323768375@loki.upc.es>
	<a0f9c898470cedc6d900.1323768376@loki.upc.es>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 01 of 14 v4] xenbackendd: pass type of block
 device to hotplug script
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Roger Pau Monne writes ("[Xen-devel] [PATCH 01 of 14 v4] xenbackendd: pass type of block device to hotplug script"):
> xenbackendd: pass type of block device to hotplug script
> 
> Pass the type of block device to attach to the block script instead
> of reading it from xenstore, since new Xen versions don't make a
> difference between a block device or an image.

Why can the hotplug script not use test(1) ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 15:03:18 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 15:03:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaTst-0006QD-Tp; Tue, 13 Dec 2011 15:03:11 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RaTss-0006Ph-Fl
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 15:03:10 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1323788518!58763529!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTI1NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4409 invoked from network); 13 Dec 2011 15:01:58 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 15:01:58 -0000
X-IronPort-AV: E=Sophos;i="4.71,345,1320624000"; 
   d="scan'208";a="9443481"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Dec 2011 15:02:16 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 13 Dec 2011 15:02:15 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 13 Dec 2011 15:02:15 +0000
In-Reply-To: <20199.26388.187010.379029@mariner.uk.xensource.com>
References: <osstest-10481-mainreport@xen.org>
	<1323769464.20077.262.camel@zakaz.uk.xensource.com>
	<20199.14342.599850.739029@mariner.uk.xensource.com>
	<1323785260.20077.307.camel@zakaz.uk.xensource.com>
	<20199.24357.180937.882607@mariner.uk.xensource.com>
	<1323786461.20077.312.camel@zakaz.uk.xensource.com>
	<20199.26051.761880.513100@mariner.uk.xensource.com>
	<1323787886.20077.314.camel@zakaz.uk.xensource.com>
	<20199.26388.187010.379029@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323788535.20077.321.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [xen-unstable test] 10481: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2011-12-13 at 14:54 +0000, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [xen-unstable test] 10481: regressions - FAIL"):
> > On Tue, 2011-12-13 at 14:48 +0000, Ian Jackson wrote:
> > > Ian Campbell writes ("Re: [Xen-devel] [xen-unstable test] 10481: regressions - FAIL"):
> > > > You can explicitly ask for a power button event with "xl button-press".
> > > > At a minimum the error message should point to this in preference to
> > > > destroy.
> > > 
> > > That would be a better improvement.
> > 
> > So which do you prefer? An error message pointing to "xl button-press"
> > or sending the button press?
> 
> Sorry, I misphrased my email.  I should have said that would be a
> "minimal improvement".  I would prefer "xl shutdown" to send the
> button press.

Just to clarify a bit further: do you think libxl_domain_shutdown should
implement this fallback or should it be left to xl to do?

Shall "xl reboot"/libxl_domain_reboot do the same?

NB: currently we have libxl_domain_shutdown which takes an integer
"request" type. I intend to split this into
libxl_domain_{shutdown,reboot}. There are some other request types
currently but they are not useful:

      * "suspend" is already provided by libxl_domain_suspend, which
        includes all the other required scaffolding which
        libxl_domain_shutdown does not,.
      * "halt" which is a synonym for shutdown 
      * "crash" which is unused and isn't supported at least by Linux,
        someone can add "xl crash" and libxl_domain_crash if they really
        want it.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 15:03:18 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 15:03:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaTst-0006QD-Tp; Tue, 13 Dec 2011 15:03:11 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RaTss-0006Ph-Fl
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 15:03:10 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1323788518!58763529!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTI1NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4409 invoked from network); 13 Dec 2011 15:01:58 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 15:01:58 -0000
X-IronPort-AV: E=Sophos;i="4.71,345,1320624000"; 
   d="scan'208";a="9443481"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Dec 2011 15:02:16 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 13 Dec 2011 15:02:15 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 13 Dec 2011 15:02:15 +0000
In-Reply-To: <20199.26388.187010.379029@mariner.uk.xensource.com>
References: <osstest-10481-mainreport@xen.org>
	<1323769464.20077.262.camel@zakaz.uk.xensource.com>
	<20199.14342.599850.739029@mariner.uk.xensource.com>
	<1323785260.20077.307.camel@zakaz.uk.xensource.com>
	<20199.24357.180937.882607@mariner.uk.xensource.com>
	<1323786461.20077.312.camel@zakaz.uk.xensource.com>
	<20199.26051.761880.513100@mariner.uk.xensource.com>
	<1323787886.20077.314.camel@zakaz.uk.xensource.com>
	<20199.26388.187010.379029@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323788535.20077.321.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [xen-unstable test] 10481: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2011-12-13 at 14:54 +0000, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [xen-unstable test] 10481: regressions - FAIL"):
> > On Tue, 2011-12-13 at 14:48 +0000, Ian Jackson wrote:
> > > Ian Campbell writes ("Re: [Xen-devel] [xen-unstable test] 10481: regressions - FAIL"):
> > > > You can explicitly ask for a power button event with "xl button-press".
> > > > At a minimum the error message should point to this in preference to
> > > > destroy.
> > > 
> > > That would be a better improvement.
> > 
> > So which do you prefer? An error message pointing to "xl button-press"
> > or sending the button press?
> 
> Sorry, I misphrased my email.  I should have said that would be a
> "minimal improvement".  I would prefer "xl shutdown" to send the
> button press.

Just to clarify a bit further: do you think libxl_domain_shutdown should
implement this fallback or should it be left to xl to do?

Shall "xl reboot"/libxl_domain_reboot do the same?

NB: currently we have libxl_domain_shutdown which takes an integer
"request" type. I intend to split this into
libxl_domain_{shutdown,reboot}. There are some other request types
currently but they are not useful:

      * "suspend" is already provided by libxl_domain_suspend, which
        includes all the other required scaffolding which
        libxl_domain_shutdown does not,.
      * "halt" which is a synonym for shutdown 
      * "crash" which is unused and isn't supported at least by Linux,
        someone can add "xl crash" and libxl_domain_crash if they really
        want it.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 15:03:47 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 15:03:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaTtJ-0006TZ-C5; Tue, 13 Dec 2011 15:03:37 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RaTtI-0006Sq-3X
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 15:03:36 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1323788561!7023400!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTI1NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8204 invoked from network); 13 Dec 2011 15:02:41 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 15:02:41 -0000
X-IronPort-AV: E=Sophos;i="4.71,345,1320624000"; 
   d="scan'208";a="9443502"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Dec 2011 15:02:41 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 13 Dec 2011 15:02:41 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RaTsO-0007GO-VD; Tue, 13 Dec 2011 15:02:40 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RaTsO-0002Uf-UL;
	Tue, 13 Dec 2011 15:02:40 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20199.26896.928532.781947@mariner.uk.xensource.com>
Date: Tue, 13 Dec 2011 15:02:40 +0000
To: Roger Pau Monne <roger.pau@entel.upc.edu>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <35c322e6020501447936.1323768387@loki.upc.es>
References: <patchbomb.1323768375@loki.upc.es>
	<35c322e6020501447936.1323768387@loki.upc.es>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 12 of 14 v4] libxl: set frontend status to 6
	on	domain destroy
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Roger Pau Monne writes ("[Xen-devel] [PATCH 12 of 14 v4] libxl: set frontend status to 6 on domain destroy"):
> libxl: set frontend status to 6 on domain destroy
> 
> Set frontend status to 6 on domain destruction and wait for devices to
> be disconnected before executing hotplug scripts.

There seems to be a race here.

> +    libxl__xs_write(gc, XBT_NULL, libxl__sprintf(gc, "%s/%s", fe_path, "state"), "6");

So here, the kernel or backendd start racing, and you hope that they
win the race and close the device before ...

>      libxl__device_execute_hotplug(gc, dev, DISCONNECT);

... the hotplug script tries to remove it.

Is there something we can do to make sure that we always get this
right ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 15:03:47 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 15:03:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaTtJ-0006TZ-C5; Tue, 13 Dec 2011 15:03:37 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RaTtI-0006Sq-3X
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 15:03:36 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1323788561!7023400!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTI1NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8204 invoked from network); 13 Dec 2011 15:02:41 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 15:02:41 -0000
X-IronPort-AV: E=Sophos;i="4.71,345,1320624000"; 
   d="scan'208";a="9443502"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Dec 2011 15:02:41 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 13 Dec 2011 15:02:41 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RaTsO-0007GO-VD; Tue, 13 Dec 2011 15:02:40 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RaTsO-0002Uf-UL;
	Tue, 13 Dec 2011 15:02:40 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20199.26896.928532.781947@mariner.uk.xensource.com>
Date: Tue, 13 Dec 2011 15:02:40 +0000
To: Roger Pau Monne <roger.pau@entel.upc.edu>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <35c322e6020501447936.1323768387@loki.upc.es>
References: <patchbomb.1323768375@loki.upc.es>
	<35c322e6020501447936.1323768387@loki.upc.es>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 12 of 14 v4] libxl: set frontend status to 6
	on	domain destroy
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Roger Pau Monne writes ("[Xen-devel] [PATCH 12 of 14 v4] libxl: set frontend status to 6 on domain destroy"):
> libxl: set frontend status to 6 on domain destroy
> 
> Set frontend status to 6 on domain destruction and wait for devices to
> be disconnected before executing hotplug scripts.

There seems to be a race here.

> +    libxl__xs_write(gc, XBT_NULL, libxl__sprintf(gc, "%s/%s", fe_path, "state"), "6");

So here, the kernel or backendd start racing, and you hope that they
win the race and close the device before ...

>      libxl__device_execute_hotplug(gc, dev, DISCONNECT);

... the hotplug script tries to remove it.

Is there something we can do to make sure that we always get this
right ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 15:05:07 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 15:05:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaTuc-0006gX-SU; Tue, 13 Dec 2011 15:04:58 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RaTua-0006fZ-KP
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 15:04:56 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1323788641!7231222!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2899 invoked from network); 13 Dec 2011 15:04:02 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-14.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 13 Dec 2011 15:04:02 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 13 Dec 2011 15:04:01 +0000
Message-Id: <4EE7776E0200007800067623@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 13 Dec 2011 15:03:58 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Christoph Egger" <Christoph.Egger@amd.com>, "Keir Fraser" <keir@xen.org>
References: <CB0BC143.35A76%keir@xen.org> <4EE75FB4.30609@amd.com>
In-Reply-To: <4EE75FB4.30609@amd.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] microcode fix
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 13.12.11 at 15:22, Christoph Egger <Christoph.Egger@amd.com> wrote:
>@@ -335,17 +352,36 @@ static int microcode_resume_match(int cp
> 
>     if ( src != mc_amd )
>     {
>+        xfree(mc_amd->equiv_cpu_table);
>+        xfree(mc_amd->mpb);

mc_amd can be NULL here.

>         xfree(mc_amd);
>-        mc_amd = xmalloc_bytes(sizeof(*src) + src->equiv_cpu_table_size);
>+
>+        mc_amd = xmalloc_bytes(sizeof(*src));

xmalloc(struct microcode_amd)

>+        if ( !mc_amd )
>+            goto err0;

The error handling is broken here. You need to clear out
uci->mc.mc_amd (i.e. move up the respective assignment).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 15:05:07 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 15:05:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaTuc-0006gX-SU; Tue, 13 Dec 2011 15:04:58 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RaTua-0006fZ-KP
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 15:04:56 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1323788641!7231222!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2899 invoked from network); 13 Dec 2011 15:04:02 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-14.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 13 Dec 2011 15:04:02 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 13 Dec 2011 15:04:01 +0000
Message-Id: <4EE7776E0200007800067623@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 13 Dec 2011 15:03:58 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Christoph Egger" <Christoph.Egger@amd.com>, "Keir Fraser" <keir@xen.org>
References: <CB0BC143.35A76%keir@xen.org> <4EE75FB4.30609@amd.com>
In-Reply-To: <4EE75FB4.30609@amd.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] microcode fix
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 13.12.11 at 15:22, Christoph Egger <Christoph.Egger@amd.com> wrote:
>@@ -335,17 +352,36 @@ static int microcode_resume_match(int cp
> 
>     if ( src != mc_amd )
>     {
>+        xfree(mc_amd->equiv_cpu_table);
>+        xfree(mc_amd->mpb);

mc_amd can be NULL here.

>         xfree(mc_amd);
>-        mc_amd = xmalloc_bytes(sizeof(*src) + src->equiv_cpu_table_size);
>+
>+        mc_amd = xmalloc_bytes(sizeof(*src));

xmalloc(struct microcode_amd)

>+        if ( !mc_amd )
>+            goto err0;

The error handling is broken here. You need to clear out
uci->mc.mc_amd (i.e. move up the respective assignment).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 15:07:13 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 15:07:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaTwf-00071J-Ec; Tue, 13 Dec 2011 15:07:05 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RaTwd-00070i-RY
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 15:07:04 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1323788769!7084527!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTI1NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23844 invoked from network); 13 Dec 2011 15:06:09 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 15:06:09 -0000
X-IronPort-AV: E=Sophos;i="4.71,345,1320624000"; 
   d="scan'208";a="9443653"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Dec 2011 15:06:09 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 13 Dec 2011 15:06:09 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RaTvl-0007Hf-4Y; Tue, 13 Dec 2011 15:06:09 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RaTvl-0002Ux-3e;
	Tue, 13 Dec 2011 15:06:09 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20199.27104.948333.593110@mariner.uk.xensource.com>
Date: Tue, 13 Dec 2011 15:06:08 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1323788535.20077.321.camel@zakaz.uk.xensource.com>
References: <osstest-10481-mainreport@xen.org>
	<1323769464.20077.262.camel@zakaz.uk.xensource.com>
	<20199.14342.599850.739029@mariner.uk.xensource.com>
	<1323785260.20077.307.camel@zakaz.uk.xensource.com>
	<20199.24357.180937.882607@mariner.uk.xensource.com>
	<1323786461.20077.312.camel@zakaz.uk.xensource.com>
	<20199.26051.761880.513100@mariner.uk.xensource.com>
	<1323787886.20077.314.camel@zakaz.uk.xensource.com>
	<20199.26388.187010.379029@mariner.uk.xensource.com>
	<1323788535.20077.321.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [xen-unstable test] 10481: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("Re: [Xen-devel] [xen-unstable test] 10481: regressions - FAIL"):
> Just to clarify a bit further: do you think libxl_domain_shutdown should
> implement this fallback or should it be left to xl to do?

I'm not sure.

> Shall "xl reboot"/libxl_domain_reboot do the same?

Yes.

Putting those things together, it seems to me that something needs to
know that "reboot" or "shutdown" are being simulated with the power
button.

That's so that if you say "reboot" or "shutdown" and we press the
guest's power button, we know whether, when the guest does shut down,
whether we actually want to restart it.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 15:07:13 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 15:07:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaTwf-00071J-Ec; Tue, 13 Dec 2011 15:07:05 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RaTwd-00070i-RY
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 15:07:04 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1323788769!7084527!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTI1NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23844 invoked from network); 13 Dec 2011 15:06:09 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 15:06:09 -0000
X-IronPort-AV: E=Sophos;i="4.71,345,1320624000"; 
   d="scan'208";a="9443653"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Dec 2011 15:06:09 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 13 Dec 2011 15:06:09 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RaTvl-0007Hf-4Y; Tue, 13 Dec 2011 15:06:09 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RaTvl-0002Ux-3e;
	Tue, 13 Dec 2011 15:06:09 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20199.27104.948333.593110@mariner.uk.xensource.com>
Date: Tue, 13 Dec 2011 15:06:08 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1323788535.20077.321.camel@zakaz.uk.xensource.com>
References: <osstest-10481-mainreport@xen.org>
	<1323769464.20077.262.camel@zakaz.uk.xensource.com>
	<20199.14342.599850.739029@mariner.uk.xensource.com>
	<1323785260.20077.307.camel@zakaz.uk.xensource.com>
	<20199.24357.180937.882607@mariner.uk.xensource.com>
	<1323786461.20077.312.camel@zakaz.uk.xensource.com>
	<20199.26051.761880.513100@mariner.uk.xensource.com>
	<1323787886.20077.314.camel@zakaz.uk.xensource.com>
	<20199.26388.187010.379029@mariner.uk.xensource.com>
	<1323788535.20077.321.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [xen-unstable test] 10481: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("Re: [Xen-devel] [xen-unstable test] 10481: regressions - FAIL"):
> Just to clarify a bit further: do you think libxl_domain_shutdown should
> implement this fallback or should it be left to xl to do?

I'm not sure.

> Shall "xl reboot"/libxl_domain_reboot do the same?

Yes.

Putting those things together, it seems to me that something needs to
know that "reboot" or "shutdown" are being simulated with the power
button.

That's so that if you say "reboot" or "shutdown" and we press the
guest's power button, we know whether, when the guest does shut down,
whether we actually want to restart it.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 15:07:22 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 15:07:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaTwo-00072i-SH; Tue, 13 Dec 2011 15:07:14 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RaTwn-00071i-8B
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 15:07:13 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1323788778!7950764!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTI1NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4112 invoked from network); 13 Dec 2011 15:06:18 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 15:06:18 -0000
X-IronPort-AV: E=Sophos;i="4.71,345,1320624000"; 
   d="scan'208";a="9443656"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Dec 2011 15:06:18 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 13 Dec 2011 15:06:17 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RaTvt-0007Hk-LY; Tue, 13 Dec 2011 15:06:17 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RaTvt-0002V7-Kt;
	Tue, 13 Dec 2011 15:06:17 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20199.27113.636096.845679@mariner.uk.xensource.com>
Date: Tue, 13 Dec 2011 15:06:17 +0000
To: Roger Pau Monne <roger.pau@entel.upc.edu>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <ea1a9fe2ef02f0737fa6.1323768388@loki.upc.es>
References: <patchbomb.1323768375@loki.upc.es>
	<ea1a9fe2ef02f0737fa6.1323768388@loki.upc.es>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 13 of 14 v4] libxl: remove force parameter
 from libxl_domain_destroy
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Roger Pau Monne writes ("[Xen-devel] [PATCH 13 of 14 v4] libxl: remove force parameter from libxl_domain_destroy"):
> libxl: remove force parameter from libxl_domain_destroy
> 
> Since a destroy is considered a forced shutdown, there's no point in
> passing a force parameter. All the occurences of this function have
> been replaced with the proper syntax.
> 
> Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 15:07:22 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 15:07:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaTwo-00072i-SH; Tue, 13 Dec 2011 15:07:14 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RaTwn-00071i-8B
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 15:07:13 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1323788778!7950764!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTI1NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4112 invoked from network); 13 Dec 2011 15:06:18 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 15:06:18 -0000
X-IronPort-AV: E=Sophos;i="4.71,345,1320624000"; 
   d="scan'208";a="9443656"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Dec 2011 15:06:18 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 13 Dec 2011 15:06:17 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RaTvt-0007Hk-LY; Tue, 13 Dec 2011 15:06:17 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RaTvt-0002V7-Kt;
	Tue, 13 Dec 2011 15:06:17 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20199.27113.636096.845679@mariner.uk.xensource.com>
Date: Tue, 13 Dec 2011 15:06:17 +0000
To: Roger Pau Monne <roger.pau@entel.upc.edu>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <ea1a9fe2ef02f0737fa6.1323768388@loki.upc.es>
References: <patchbomb.1323768375@loki.upc.es>
	<ea1a9fe2ef02f0737fa6.1323768388@loki.upc.es>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 13 of 14 v4] libxl: remove force parameter
 from libxl_domain_destroy
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Roger Pau Monne writes ("[Xen-devel] [PATCH 13 of 14 v4] libxl: remove force parameter from libxl_domain_destroy"):
> libxl: remove force parameter from libxl_domain_destroy
> 
> Since a destroy is considered a forced shutdown, there's no point in
> passing a force parameter. All the occurences of this function have
> been replaced with the proper syntax.
> 
> Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 15:15:27 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 15:15:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaU4c-0007V4-5V; Tue, 13 Dec 2011 15:15:18 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RaU4b-0007Uz-Ha
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 15:15:17 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1323789262!5378665!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTI1NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25701 invoked from network); 13 Dec 2011 15:14:23 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 15:14:23 -0000
X-IronPort-AV: E=Sophos;i="4.71,345,1320624000"; 
   d="scan'208";a="9443903"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Dec 2011 15:14:22 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 13 Dec 2011 15:14:22 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RaU3i-0007KT-7I; Tue, 13 Dec 2011 15:14:22 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RaU3i-0002Vf-6Q;
	Tue, 13 Dec 2011 15:14:22 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20199.27598.186154.715821@mariner.uk.xensource.com>
Date: Tue, 13 Dec 2011 15:14:22 +0000
To: Roger Pau Monne <roger.pau@entel.upc.edu>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <573a246bf0c6b3ad0147.1323768378@loki.upc.es>
References: <patchbomb.1323768375@loki.upc.es>
	<573a246bf0c6b3ad0147.1323768378@loki.upc.es>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 03 of 14 v4] libxl: add libxl__forkexec
	function	to libxl_exec
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Roger Pau Monne writes ("[Xen-devel] [PATCH 03 of 14 v4] libxl: add libxl__forkexec function to libxl_exec"):
> +int libxl__forkexec(libxl__gc *gc, int stdinfd, int stdoutfd,
> +                    int stderrfd, char **args)
> +{
...
> +        libxl__exec(stdinfd, stdoutfd, stderrfd, args[0], args);
...
> +            libxl_report_child_exitstatus(ctx, LIBXL__LOG_ERROR,
> +                                          args[0], pid, status);

I think this function should allow passing separate values for arg0
and args.  It would also be useful to allow passing a separate "what"
to libxl_report_child_exitstatus: for example, that would allow you to
distinguish the various call sites for running a hotplug script, so
that failures in the plug and unplug give different answers.  It also
allows the caller to use libxl__sprintf if they want to give
more information about the program.

> +/*
> + * libxl__forkexec - Executes a file synchronously

OK, but:

> + * gc: allocation pool
> + * stdinfd, stdoutfd, stderrfd: fds to pass to libxl__exec
> + * args: file to execute and arguments to pass in the following format
> + *      args[0]: file to execute
> + *      args[1]: first argument to pass to the called program
> + *      ...
> + *      args[n-1]: (n-1)th argument to pass to the called program
> + *      args[n]: NULL

IMO all of the above is obvious and should be eliminated.  (This is
exactly the kind of "fd is the file descriptor" stuff that I was
complaining about in another recent thread.)

> + * Returns the exit status, as reported by waitpid.

And this fails to go into enough detail.  Indeed it is false.
In particular, it fails to mention:
  - what the function does if some system call fails
  - whether any messages are logged

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 15:15:27 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 15:15:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaU4c-0007V4-5V; Tue, 13 Dec 2011 15:15:18 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RaU4b-0007Uz-Ha
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 15:15:17 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1323789262!5378665!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTI1NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25701 invoked from network); 13 Dec 2011 15:14:23 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 15:14:23 -0000
X-IronPort-AV: E=Sophos;i="4.71,345,1320624000"; 
   d="scan'208";a="9443903"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Dec 2011 15:14:22 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 13 Dec 2011 15:14:22 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RaU3i-0007KT-7I; Tue, 13 Dec 2011 15:14:22 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RaU3i-0002Vf-6Q;
	Tue, 13 Dec 2011 15:14:22 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20199.27598.186154.715821@mariner.uk.xensource.com>
Date: Tue, 13 Dec 2011 15:14:22 +0000
To: Roger Pau Monne <roger.pau@entel.upc.edu>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <573a246bf0c6b3ad0147.1323768378@loki.upc.es>
References: <patchbomb.1323768375@loki.upc.es>
	<573a246bf0c6b3ad0147.1323768378@loki.upc.es>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 03 of 14 v4] libxl: add libxl__forkexec
	function	to libxl_exec
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Roger Pau Monne writes ("[Xen-devel] [PATCH 03 of 14 v4] libxl: add libxl__forkexec function to libxl_exec"):
> +int libxl__forkexec(libxl__gc *gc, int stdinfd, int stdoutfd,
> +                    int stderrfd, char **args)
> +{
...
> +        libxl__exec(stdinfd, stdoutfd, stderrfd, args[0], args);
...
> +            libxl_report_child_exitstatus(ctx, LIBXL__LOG_ERROR,
> +                                          args[0], pid, status);

I think this function should allow passing separate values for arg0
and args.  It would also be useful to allow passing a separate "what"
to libxl_report_child_exitstatus: for example, that would allow you to
distinguish the various call sites for running a hotplug script, so
that failures in the plug and unplug give different answers.  It also
allows the caller to use libxl__sprintf if they want to give
more information about the program.

> +/*
> + * libxl__forkexec - Executes a file synchronously

OK, but:

> + * gc: allocation pool
> + * stdinfd, stdoutfd, stderrfd: fds to pass to libxl__exec
> + * args: file to execute and arguments to pass in the following format
> + *      args[0]: file to execute
> + *      args[1]: first argument to pass to the called program
> + *      ...
> + *      args[n-1]: (n-1)th argument to pass to the called program
> + *      args[n]: NULL

IMO all of the above is obvious and should be eliminated.  (This is
exactly the kind of "fd is the file descriptor" stuff that I was
complaining about in another recent thread.)

> + * Returns the exit status, as reported by waitpid.

And this fails to go into enough detail.  Indeed it is false.
In particular, it fails to mention:
  - what the function does if some system call fails
  - whether any messages are logged

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 15:19:10 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 15:19:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaU89-0007cx-QX; Tue, 13 Dec 2011 15:18:57 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RaU88-0007cn-Jp
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 15:18:56 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1323789482!7084853!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTI1NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12557 invoked from network); 13 Dec 2011 15:18:02 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 15:18:02 -0000
X-IronPort-AV: E=Sophos;i="4.71,345,1320624000"; 
   d="scan'208";a="9444008"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Dec 2011 15:18:01 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 13 Dec 2011 15:18:01 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RaU7F-0007Lr-3x; Tue, 13 Dec 2011 15:18:01 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RaU7F-0002W2-34;
	Tue, 13 Dec 2011 15:18:01 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20199.27817.69693.627762@mariner.uk.xensource.com>
Date: Tue, 13 Dec 2011 15:18:01 +0000
To: Roger Pau Monne <roger.pau@entel.upc.edu>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <a3a95ea16ca4e34c8213.1323768381@loki.upc.es>
References: <patchbomb.1323768375@loki.upc.es>
	<a3a95ea16ca4e34c8213.1323768381@loki.upc.es>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 06 of 14 v4] libxl: execute hotplug
	scripts	directly from libxl
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Roger Pau Monne writes ("[Xen-devel] [PATCH 06 of 14 v4] libxl: execute hotplug scripts directly from libxl"):
> libxl: execute hotplug scripts directly from libxl.
> 
> Added the necessary handlers to execute hotplug scripts when necessary
> >from libxl. Split NetBSD and Linux hotplug calls into two separate
> files, because parameters for hotplug scripts are different. Linux
> has empty functions, since the calling of hotplug scripts is still
> done using udev.

I think this would be improved by an explanation of what the job of
the hotplug scripts are and what their calling conventions are, on
NetBSD.  I'm afraid as it is I don't understand what the hotplug
scripts do on NetBSD.

I know what they do on Linux for vifs.  On Linux we are missing script
support for block devices, but it's not clear that they are really
"hotplug" scripts.

Also your patch has some long lines.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 15:19:10 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 15:19:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaU89-0007cx-QX; Tue, 13 Dec 2011 15:18:57 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RaU88-0007cn-Jp
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 15:18:56 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1323789482!7084853!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTI1NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12557 invoked from network); 13 Dec 2011 15:18:02 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 15:18:02 -0000
X-IronPort-AV: E=Sophos;i="4.71,345,1320624000"; 
   d="scan'208";a="9444008"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Dec 2011 15:18:01 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 13 Dec 2011 15:18:01 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RaU7F-0007Lr-3x; Tue, 13 Dec 2011 15:18:01 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RaU7F-0002W2-34;
	Tue, 13 Dec 2011 15:18:01 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20199.27817.69693.627762@mariner.uk.xensource.com>
Date: Tue, 13 Dec 2011 15:18:01 +0000
To: Roger Pau Monne <roger.pau@entel.upc.edu>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <a3a95ea16ca4e34c8213.1323768381@loki.upc.es>
References: <patchbomb.1323768375@loki.upc.es>
	<a3a95ea16ca4e34c8213.1323768381@loki.upc.es>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 06 of 14 v4] libxl: execute hotplug
	scripts	directly from libxl
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Roger Pau Monne writes ("[Xen-devel] [PATCH 06 of 14 v4] libxl: execute hotplug scripts directly from libxl"):
> libxl: execute hotplug scripts directly from libxl.
> 
> Added the necessary handlers to execute hotplug scripts when necessary
> >from libxl. Split NetBSD and Linux hotplug calls into two separate
> files, because parameters for hotplug scripts are different. Linux
> has empty functions, since the calling of hotplug scripts is still
> done using udev.

I think this would be improved by an explanation of what the job of
the hotplug scripts are and what their calling conventions are, on
NetBSD.  I'm afraid as it is I don't understand what the hotplug
scripts do on NetBSD.

I know what they do on Linux for vifs.  On Linux we are missing script
support for block devices, but it's not clear that they are really
"hotplug" scripts.

Also your patch has some long lines.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 15:20:00 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 15:20:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaU90-0007gj-Or; Tue, 13 Dec 2011 15:19:50 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RaU8y-0007gP-9T
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 15:19:48 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1323789533!5395630!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTI1NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26370 invoked from network); 13 Dec 2011 15:18:53 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 15:18:53 -0000
X-IronPort-AV: E=Sophos;i="4.71,345,1320624000"; 
   d="scan'208";a="9444034"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Dec 2011 15:18:53 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 13 Dec 2011 15:18:53 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 13 Dec 2011 15:18:53 +0000
In-Reply-To: <20199.27104.948333.593110@mariner.uk.xensource.com>
References: <osstest-10481-mainreport@xen.org>
	<1323769464.20077.262.camel@zakaz.uk.xensource.com>
	<20199.14342.599850.739029@mariner.uk.xensource.com>
	<1323785260.20077.307.camel@zakaz.uk.xensource.com>
	<20199.24357.180937.882607@mariner.uk.xensource.com>
	<1323786461.20077.312.camel@zakaz.uk.xensource.com>
	<20199.26051.761880.513100@mariner.uk.xensource.com>
	<1323787886.20077.314.camel@zakaz.uk.xensource.com>
	<20199.26388.187010.379029@mariner.uk.xensource.com>
	<1323788535.20077.321.camel@zakaz.uk.xensource.com>
	<20199.27104.948333.593110@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323789533.20077.326.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [xen-unstable test] 10481: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2011-12-13 at 15:06 +0000, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [xen-unstable test] 10481: regressions - FAIL"):
> > Just to clarify a bit further: do you think libxl_domain_shutdown should
> > implement this fallback or should it be left to xl to do?
> 
> I'm not sure.
> 
> > Shall "xl reboot"/libxl_domain_reboot do the same?
> 
> Yes.
> 
> Putting those things together, it seems to me that something needs to
> know that "reboot" or "shutdown" are being simulated with the power
> button.

I think this requires deferring the fallback to xl. Which makes sense
since other toolstacks may have other policies in this regard.

> That's so that if you say "reboot" or "shutdown" and we press the
> guest's power button, we know whether, when the guest does shut down,
> whether we actually want to restart it.

That would involve potentially communicating with the daemonized version
of xl which is monitoring the domain (if it exists) and/or taking over
it's function in the xl instance running the shutdown.

I'm tempted to just go with the minimal improvement at this stage.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 15:20:00 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 15:20:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaU90-0007gj-Or; Tue, 13 Dec 2011 15:19:50 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RaU8y-0007gP-9T
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 15:19:48 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1323789533!5395630!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTI1NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26370 invoked from network); 13 Dec 2011 15:18:53 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 15:18:53 -0000
X-IronPort-AV: E=Sophos;i="4.71,345,1320624000"; 
   d="scan'208";a="9444034"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Dec 2011 15:18:53 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 13 Dec 2011 15:18:53 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 13 Dec 2011 15:18:53 +0000
In-Reply-To: <20199.27104.948333.593110@mariner.uk.xensource.com>
References: <osstest-10481-mainreport@xen.org>
	<1323769464.20077.262.camel@zakaz.uk.xensource.com>
	<20199.14342.599850.739029@mariner.uk.xensource.com>
	<1323785260.20077.307.camel@zakaz.uk.xensource.com>
	<20199.24357.180937.882607@mariner.uk.xensource.com>
	<1323786461.20077.312.camel@zakaz.uk.xensource.com>
	<20199.26051.761880.513100@mariner.uk.xensource.com>
	<1323787886.20077.314.camel@zakaz.uk.xensource.com>
	<20199.26388.187010.379029@mariner.uk.xensource.com>
	<1323788535.20077.321.camel@zakaz.uk.xensource.com>
	<20199.27104.948333.593110@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323789533.20077.326.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [xen-unstable test] 10481: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2011-12-13 at 15:06 +0000, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [xen-unstable test] 10481: regressions - FAIL"):
> > Just to clarify a bit further: do you think libxl_domain_shutdown should
> > implement this fallback or should it be left to xl to do?
> 
> I'm not sure.
> 
> > Shall "xl reboot"/libxl_domain_reboot do the same?
> 
> Yes.
> 
> Putting those things together, it seems to me that something needs to
> know that "reboot" or "shutdown" are being simulated with the power
> button.

I think this requires deferring the fallback to xl. Which makes sense
since other toolstacks may have other policies in this regard.

> That's so that if you say "reboot" or "shutdown" and we press the
> guest's power button, we know whether, when the guest does shut down,
> whether we actually want to restart it.

That would involve potentially communicating with the daemonized version
of xl which is monitoring the domain (if it exists) and/or taking over
it's function in the xl instance running the shutdown.

I'm tempted to just go with the minimal improvement at this stage.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 15:21:25 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 15:21:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaUAK-0007nR-9p; Tue, 13 Dec 2011 15:21:12 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RaUAI-0007mv-W6
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 15:21:11 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1323789614!1778613!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTI1NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22936 invoked from network); 13 Dec 2011 15:20:15 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 15:20:15 -0000
X-IronPort-AV: E=Sophos;i="4.71,345,1320624000"; 
   d="scan'208";a="9444074"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Dec 2011 15:20:14 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 13 Dec 2011 15:20:14 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RaU9N-0007Mt-Ra; Tue, 13 Dec 2011 15:20:13 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RaU9N-0002Wb-Qi;
	Tue, 13 Dec 2011 15:20:13 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20199.27949.795096.263945@mariner.uk.xensource.com>
Date: Tue, 13 Dec 2011 15:20:13 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1323789533.20077.326.camel@zakaz.uk.xensource.com>
References: <osstest-10481-mainreport@xen.org>
	<1323769464.20077.262.camel@zakaz.uk.xensource.com>
	<20199.14342.599850.739029@mariner.uk.xensource.com>
	<1323785260.20077.307.camel@zakaz.uk.xensource.com>
	<20199.24357.180937.882607@mariner.uk.xensource.com>
	<1323786461.20077.312.camel@zakaz.uk.xensource.com>
	<20199.26051.761880.513100@mariner.uk.xensource.com>
	<1323787886.20077.314.camel@zakaz.uk.xensource.com>
	<20199.26388.187010.379029@mariner.uk.xensource.com>
	<1323788535.20077.321.camel@zakaz.uk.xensource.com>
	<20199.27104.948333.593110@mariner.uk.xensource.com>
	<1323789533.20077.326.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [xen-unstable test] 10481: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("Re: [Xen-devel] [xen-unstable test] 10481: regressions - FAIL"):
> On Tue, 2011-12-13 at 15:06 +0000, Ian Jackson wrote:
> > That's so that if you say "reboot" or "shutdown" and we press the
> > guest's power button, we know whether, when the guest does shut down,
> > whether we actually want to restart it.
> 
> That would involve potentially communicating with the daemonized version
> of xl which is monitoring the domain (if it exists) and/or taking over
> it's function in the xl instance running the shutdown.

Yes.  That could be done via xenstore of course.

> I'm tempted to just go with the minimal improvement at this stage.

Fair enough.  It's not going to make the test pass though :-).

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 15:21:25 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 15:21:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaUAK-0007nR-9p; Tue, 13 Dec 2011 15:21:12 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RaUAI-0007mv-W6
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 15:21:11 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1323789614!1778613!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTI1NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22936 invoked from network); 13 Dec 2011 15:20:15 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 15:20:15 -0000
X-IronPort-AV: E=Sophos;i="4.71,345,1320624000"; 
   d="scan'208";a="9444074"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Dec 2011 15:20:14 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 13 Dec 2011 15:20:14 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RaU9N-0007Mt-Ra; Tue, 13 Dec 2011 15:20:13 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RaU9N-0002Wb-Qi;
	Tue, 13 Dec 2011 15:20:13 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20199.27949.795096.263945@mariner.uk.xensource.com>
Date: Tue, 13 Dec 2011 15:20:13 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1323789533.20077.326.camel@zakaz.uk.xensource.com>
References: <osstest-10481-mainreport@xen.org>
	<1323769464.20077.262.camel@zakaz.uk.xensource.com>
	<20199.14342.599850.739029@mariner.uk.xensource.com>
	<1323785260.20077.307.camel@zakaz.uk.xensource.com>
	<20199.24357.180937.882607@mariner.uk.xensource.com>
	<1323786461.20077.312.camel@zakaz.uk.xensource.com>
	<20199.26051.761880.513100@mariner.uk.xensource.com>
	<1323787886.20077.314.camel@zakaz.uk.xensource.com>
	<20199.26388.187010.379029@mariner.uk.xensource.com>
	<1323788535.20077.321.camel@zakaz.uk.xensource.com>
	<20199.27104.948333.593110@mariner.uk.xensource.com>
	<1323789533.20077.326.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [xen-unstable test] 10481: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("Re: [Xen-devel] [xen-unstable test] 10481: regressions - FAIL"):
> On Tue, 2011-12-13 at 15:06 +0000, Ian Jackson wrote:
> > That's so that if you say "reboot" or "shutdown" and we press the
> > guest's power button, we know whether, when the guest does shut down,
> > whether we actually want to restart it.
> 
> That would involve potentially communicating with the daemonized version
> of xl which is monitoring the domain (if it exists) and/or taking over
> it's function in the xl instance running the shutdown.

Yes.  That could be done via xenstore of course.

> I'm tempted to just go with the minimal improvement at this stage.

Fair enough.  It's not going to make the test pass though :-).

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 15:22:06 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 15:22:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaUB4-0007tL-Os; Tue, 13 Dec 2011 15:21:58 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RaUB2-0007sS-Q3
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 15:21:57 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1323789662!5215845!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTI1NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20589 invoked from network); 13 Dec 2011 15:21:02 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 15:21:02 -0000
X-IronPort-AV: E=Sophos;i="4.71,345,1320624000"; 
   d="scan'208";a="9444088"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Dec 2011 15:21:02 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 13 Dec 2011 15:21:02 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RaUA9-0007N8-Vm; Tue, 13 Dec 2011 15:21:02 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RaUA9-0002Wp-V9;
	Tue, 13 Dec 2011 15:21:01 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20199.27997.953982.386709@mariner.uk.xensource.com>
Date: Tue, 13 Dec 2011 15:21:01 +0000
To: Roger Pau Monne <roger.pau@entel.upc.edu>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <51404e6e2d6f4d53a14d.1323768382@loki.upc.es>
References: <patchbomb.1323768375@loki.upc.es>
	<51404e6e2d6f4d53a14d.1323768382@loki.upc.es>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 07 of 14 v4] hotplug NetBSD: pass an action
 instead of a state to hotplug scripts
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Roger Pau Monne writes ("[Xen-devel] [PATCH 07 of 14 v4] hotplug NetBSD: pass an action instead of a state to hotplug scripts"):
> hotplug NetBSD: pass an action instead of a state to hotplug scripts
> 
> change second parameter of NetBSD hotplug scripts to take an action
> (CONNECT/DISCONNECT) instead of a xenbus state.

Aren't these hotplug scripts generally installed in /etc, where people
and tools will avoid simply overwriting old versions with new ?

In which case this apparently-subtle but actually-radical change to
their API might be a problem.

Or am I wrong ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 15:22:06 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 15:22:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaUB4-0007tL-Os; Tue, 13 Dec 2011 15:21:58 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RaUB2-0007sS-Q3
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 15:21:57 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1323789662!5215845!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTI1NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20589 invoked from network); 13 Dec 2011 15:21:02 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 15:21:02 -0000
X-IronPort-AV: E=Sophos;i="4.71,345,1320624000"; 
   d="scan'208";a="9444088"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Dec 2011 15:21:02 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 13 Dec 2011 15:21:02 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RaUA9-0007N8-Vm; Tue, 13 Dec 2011 15:21:02 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RaUA9-0002Wp-V9;
	Tue, 13 Dec 2011 15:21:01 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20199.27997.953982.386709@mariner.uk.xensource.com>
Date: Tue, 13 Dec 2011 15:21:01 +0000
To: Roger Pau Monne <roger.pau@entel.upc.edu>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <51404e6e2d6f4d53a14d.1323768382@loki.upc.es>
References: <patchbomb.1323768375@loki.upc.es>
	<51404e6e2d6f4d53a14d.1323768382@loki.upc.es>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 07 of 14 v4] hotplug NetBSD: pass an action
 instead of a state to hotplug scripts
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Roger Pau Monne writes ("[Xen-devel] [PATCH 07 of 14 v4] hotplug NetBSD: pass an action instead of a state to hotplug scripts"):
> hotplug NetBSD: pass an action instead of a state to hotplug scripts
> 
> change second parameter of NetBSD hotplug scripts to take an action
> (CONNECT/DISCONNECT) instead of a xenbus state.

Aren't these hotplug scripts generally installed in /etc, where people
and tools will avoid simply overwriting old versions with new ?

In which case this apparently-subtle but actually-radical change to
their API might be a problem.

Or am I wrong ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 15:22:46 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 15:22:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaUBf-0007yf-6Y; Tue, 13 Dec 2011 15:22:35 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RaUBd-0007xr-Vv
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 15:22:34 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1323789699!5379983!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTI1NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21254 invoked from network); 13 Dec 2011 15:21:39 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 15:21:39 -0000
X-IronPort-AV: E=Sophos;i="4.71,345,1320624000"; 
   d="scan'208";a="9444106"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Dec 2011 15:21:39 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 13 Dec 2011 15:21:38 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RaUAk-0007NP-JH; Tue, 13 Dec 2011 15:21:38 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RaUAk-0002Wy-IW;
	Tue, 13 Dec 2011 15:21:38 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20199.28034.561245.490103@mariner.uk.xensource.com>
Date: Tue, 13 Dec 2011 15:21:38 +0000
To: Roger Pau Monne <roger.pau@entel.upc.edu>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <a36942bf253c957179d4.1323768386@loki.upc.es>
References: <patchbomb.1323768375@loki.upc.es>
	<a36942bf253c957179d4.1323768386@loki.upc.es>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 11 of 14 v4] libxl: fix incorrect log
 message in libxl_domain_destroy
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Roger Pau Monne writes ("[Xen-devel] [PATCH 11 of 14 v4] libxl: fix incorrect lo> libxl: fix incorrect log message in libxl_domain_destroy
> 
> Fix a log message that was referring to libxl_devices_dispose instead
> of libxl__devices_destroy.
> 
> Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

(Although it would be nice if you'd wrapped the long line while you
were there.)

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 15:22:46 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 15:22:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaUBf-0007yf-6Y; Tue, 13 Dec 2011 15:22:35 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RaUBd-0007xr-Vv
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 15:22:34 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1323789699!5379983!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTI1NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21254 invoked from network); 13 Dec 2011 15:21:39 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 15:21:39 -0000
X-IronPort-AV: E=Sophos;i="4.71,345,1320624000"; 
   d="scan'208";a="9444106"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Dec 2011 15:21:39 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 13 Dec 2011 15:21:38 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RaUAk-0007NP-JH; Tue, 13 Dec 2011 15:21:38 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RaUAk-0002Wy-IW;
	Tue, 13 Dec 2011 15:21:38 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20199.28034.561245.490103@mariner.uk.xensource.com>
Date: Tue, 13 Dec 2011 15:21:38 +0000
To: Roger Pau Monne <roger.pau@entel.upc.edu>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <a36942bf253c957179d4.1323768386@loki.upc.es>
References: <patchbomb.1323768375@loki.upc.es>
	<a36942bf253c957179d4.1323768386@loki.upc.es>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 11 of 14 v4] libxl: fix incorrect log
 message in libxl_domain_destroy
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Roger Pau Monne writes ("[Xen-devel] [PATCH 11 of 14 v4] libxl: fix incorrect lo> libxl: fix incorrect log message in libxl_domain_destroy
> 
> Fix a log message that was referring to libxl_devices_dispose instead
> of libxl__devices_destroy.
> 
> Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

(Although it would be nice if you'd wrapped the long line while you
were there.)

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 15:24:06 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 15:24:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaUCy-0008Ag-NJ; Tue, 13 Dec 2011 15:23:56 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RaUCx-00089l-9u
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 15:23:55 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1323789780!5394235!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTI1NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15275 invoked from network); 13 Dec 2011 15:23:00 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 15:23:00 -0000
X-IronPort-AV: E=Sophos;i="4.71,345,1320624000"; 
   d="scan'208";a="9444159"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Dec 2011 15:23:00 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 13 Dec 2011 15:22:59 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RaUC3-0007Ny-Op; Tue, 13 Dec 2011 15:22:59 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RaUC3-0002XH-O3;
	Tue, 13 Dec 2011 15:22:59 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20199.28115.521058.50778@mariner.uk.xensource.com>
Date: Tue, 13 Dec 2011 15:22:59 +0000
To: Roger Pau Monne <roger.pau@entel.upc.edu>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <e3907ed912201e5270ff.1323768377@loki.upc.es>
References: <patchbomb.1323768375@loki.upc.es>
	<e3907ed912201e5270ff.1323768377@loki.upc.es>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 02 of 14 v4] libxl: add support for image
	files	for NetBSD
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Roger Pau Monne writes ("[Xen-devel] [PATCH 02 of 14 v4] libxl: add support for image files for NetBSD"):
> libxl: add support for image files for NetBSD
> 
> Created a helper function to detect if the OS is capable of using
> image files as phy backends. Create two OS specific files, and
> changed the Makefile to choose the correct one at compile time.
> 
> Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 15:24:06 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 15:24:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaUCy-0008Ag-NJ; Tue, 13 Dec 2011 15:23:56 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RaUCx-00089l-9u
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 15:23:55 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1323789780!5394235!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTI1NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15275 invoked from network); 13 Dec 2011 15:23:00 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 15:23:00 -0000
X-IronPort-AV: E=Sophos;i="4.71,345,1320624000"; 
   d="scan'208";a="9444159"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Dec 2011 15:23:00 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 13 Dec 2011 15:22:59 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RaUC3-0007Ny-Op; Tue, 13 Dec 2011 15:22:59 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RaUC3-0002XH-O3;
	Tue, 13 Dec 2011 15:22:59 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20199.28115.521058.50778@mariner.uk.xensource.com>
Date: Tue, 13 Dec 2011 15:22:59 +0000
To: Roger Pau Monne <roger.pau@entel.upc.edu>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <e3907ed912201e5270ff.1323768377@loki.upc.es>
References: <patchbomb.1323768375@loki.upc.es>
	<e3907ed912201e5270ff.1323768377@loki.upc.es>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 02 of 14 v4] libxl: add support for image
	files	for NetBSD
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Roger Pau Monne writes ("[Xen-devel] [PATCH 02 of 14 v4] libxl: add support for image files for NetBSD"):
> libxl: add support for image files for NetBSD
> 
> Created a helper function to detect if the OS is capable of using
> image files as phy backends. Create two OS specific files, and
> changed the Makefile to choose the correct one at compile time.
> 
> Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 15:24:08 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 15:24:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaUD2-0008BC-4i; Tue, 13 Dec 2011 15:24:00 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RaUD0-0008AB-A0
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 15:23:58 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1323789780!5394235!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTI1NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15804 invoked from network); 13 Dec 2011 15:23:04 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 15:23:04 -0000
X-IronPort-AV: E=Sophos;i="4.71,345,1320624000"; 
   d="scan'208";a="9444122"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Dec 2011 15:22:02 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 13 Dec 2011 15:22:02 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RaUB7-0007NZ-Re; Tue, 13 Dec 2011 15:22:01 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RaUB7-0002X7-Qz;
	Tue, 13 Dec 2011 15:22:01 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20199.28057.824839.918782@mariner.uk.xensource.com>
Date: Tue, 13 Dec 2011 15:22:01 +0000
To: Roger Pau Monne <roger.pau@entel.upc.edu>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <8a84f53376862427f254.1323768389@loki.upc.es>
References: <patchbomb.1323768375@loki.upc.es>
	<8a84f53376862427f254.1323768389@loki.upc.es>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 14 of 14 v4] libxl: remove force parameter
 from libxl__devices_destroy
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Roger Pau Monne writes ("[Xen-devel] [PATCH 14 of 14 v4] libxl: remove force parameter from libxl__devices_destroy"):
> libxl: remove force parameter from libxl__devices_destroy
> 
> Remove the force flag, and always use forced destruction.

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 15:24:08 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 15:24:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaUD2-0008BC-4i; Tue, 13 Dec 2011 15:24:00 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RaUD0-0008AB-A0
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 15:23:58 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1323789780!5394235!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTI1NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15804 invoked from network); 13 Dec 2011 15:23:04 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 15:23:04 -0000
X-IronPort-AV: E=Sophos;i="4.71,345,1320624000"; 
   d="scan'208";a="9444122"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Dec 2011 15:22:02 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 13 Dec 2011 15:22:02 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RaUB7-0007NZ-Re; Tue, 13 Dec 2011 15:22:01 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RaUB7-0002X7-Qz;
	Tue, 13 Dec 2011 15:22:01 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20199.28057.824839.918782@mariner.uk.xensource.com>
Date: Tue, 13 Dec 2011 15:22:01 +0000
To: Roger Pau Monne <roger.pau@entel.upc.edu>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <8a84f53376862427f254.1323768389@loki.upc.es>
References: <patchbomb.1323768375@loki.upc.es>
	<8a84f53376862427f254.1323768389@loki.upc.es>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 14 of 14 v4] libxl: remove force parameter
 from libxl__devices_destroy
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Roger Pau Monne writes ("[Xen-devel] [PATCH 14 of 14 v4] libxl: remove force parameter from libxl__devices_destroy"):
> libxl: remove force parameter from libxl__devices_destroy
> 
> Remove the force flag, and always use forced destruction.

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 15:25:40 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 15:25:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaUET-0008SX-L6; Tue, 13 Dec 2011 15:25:29 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RaUES-0008SC-8x
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 15:25:28 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1323789830!57123811!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTI1NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 340 invoked from network); 13 Dec 2011 15:23:50 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 15:23:50 -0000
X-IronPort-AV: E=Sophos;i="4.71,345,1320624000"; 
   d="scan'208";a="9444214"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Dec 2011 15:24:38 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 13 Dec 2011 15:24:38 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RaUDe-0007Oa-Do; Tue, 13 Dec 2011 15:24:38 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RaUDe-0002XS-Cz;
	Tue, 13 Dec 2011 15:24:38 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20199.28214.389585.995522@mariner.uk.xensource.com>
Date: Tue, 13 Dec 2011 15:24:38 +0000
To: Roger Pau Monne <roger.pau@entel.upc.edu>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <51404e6e2d6f4d53a14d.1323768382@loki.upc.es>,
	<30f2db9a780fe36eeacf.1323768383@loki.upc.es>
References: <patchbomb.1323768375@loki.upc.es>
	<30f2db9a780fe36eeacf.1323768383@loki.upc.es>
	<51404e6e2d6f4d53a14d.1323768382@loki.upc.es>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 07 of 14 v4] hotplug NetBSD: pass an action
 instead of a state to hotplug scripts [and 1 more messages]
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Roger Pau Monne writes ("[Xen-devel] [PATCH 07 of 14 v4] hotplug NetBSD: pass an action instead of a state to hotplug scripts"):
> hotplug NetBSD: pass an action instead of a state to hotplug scripts
> 
> change second parameter of NetBSD hotplug scripts to take an action
> (CONNECT/DISCONNECT) instead of a xenbus state.

Roger Pau Monne writes ("[Xen-devel] [PATCH 08 of 14 v4] xenbackendd: pass action to hotplug script"):
> xenbackendd: pass action to hotplug script
> 
> Pass an action to hotplug scripts instead of a xenbus state.
> 
> Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

Also I have just spotted that you seem to have made two halves of a
mutually-incompatble change in different patches.

Don't do that, because it breaks bisectability.  The tree should be
buildable and useable at every point.

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 15:25:40 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 15:25:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaUET-0008SX-L6; Tue, 13 Dec 2011 15:25:29 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RaUES-0008SC-8x
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 15:25:28 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1323789830!57123811!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTI1NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 340 invoked from network); 13 Dec 2011 15:23:50 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 15:23:50 -0000
X-IronPort-AV: E=Sophos;i="4.71,345,1320624000"; 
   d="scan'208";a="9444214"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Dec 2011 15:24:38 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 13 Dec 2011 15:24:38 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RaUDe-0007Oa-Do; Tue, 13 Dec 2011 15:24:38 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RaUDe-0002XS-Cz;
	Tue, 13 Dec 2011 15:24:38 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20199.28214.389585.995522@mariner.uk.xensource.com>
Date: Tue, 13 Dec 2011 15:24:38 +0000
To: Roger Pau Monne <roger.pau@entel.upc.edu>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <51404e6e2d6f4d53a14d.1323768382@loki.upc.es>,
	<30f2db9a780fe36eeacf.1323768383@loki.upc.es>
References: <patchbomb.1323768375@loki.upc.es>
	<30f2db9a780fe36eeacf.1323768383@loki.upc.es>
	<51404e6e2d6f4d53a14d.1323768382@loki.upc.es>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 07 of 14 v4] hotplug NetBSD: pass an action
 instead of a state to hotplug scripts [and 1 more messages]
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Roger Pau Monne writes ("[Xen-devel] [PATCH 07 of 14 v4] hotplug NetBSD: pass an action instead of a state to hotplug scripts"):
> hotplug NetBSD: pass an action instead of a state to hotplug scripts
> 
> change second parameter of NetBSD hotplug scripts to take an action
> (CONNECT/DISCONNECT) instead of a xenbus state.

Roger Pau Monne writes ("[Xen-devel] [PATCH 08 of 14 v4] xenbackendd: pass action to hotplug script"):
> xenbackendd: pass action to hotplug script
> 
> Pass an action to hotplug scripts instead of a xenbus state.
> 
> Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

Also I have just spotted that you seem to have made two halves of a
mutually-incompatble change in different patches.

Don't do that, because it breaks bisectability.  The tree should be
buildable and useable at every point.

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 15:25:42 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 15:25:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaUEZ-0008UJ-8q; Tue, 13 Dec 2011 15:25:35 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RaUEX-0008Sh-Df
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 15:25:33 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1323789830!57123811!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTI1NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 467 invoked from network); 13 Dec 2011 15:23:52 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 15:23:52 -0000
X-IronPort-AV: E=Sophos;i="4.71,345,1320624000"; 
   d="scan'208";a="9444218"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Dec 2011 15:24:41 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 13 Dec 2011 15:24:41 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 13 Dec 2011 15:24:40 +0000
In-Reply-To: <20199.27949.795096.263945@mariner.uk.xensource.com>
References: <osstest-10481-mainreport@xen.org>
	<1323769464.20077.262.camel@zakaz.uk.xensource.com>
	<20199.14342.599850.739029@mariner.uk.xensource.com>
	<1323785260.20077.307.camel@zakaz.uk.xensource.com>
	<20199.24357.180937.882607@mariner.uk.xensource.com>
	<1323786461.20077.312.camel@zakaz.uk.xensource.com>
	<20199.26051.761880.513100@mariner.uk.xensource.com>
	<1323787886.20077.314.camel@zakaz.uk.xensource.com>
	<20199.26388.187010.379029@mariner.uk.xensource.com>
	<1323788535.20077.321.camel@zakaz.uk.xensource.com>
	<20199.27104.948333.593110@mariner.uk.xensource.com>
	<1323789533.20077.326.camel@zakaz.uk.xensource.com>
	<20199.27949.795096.263945@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323789881.20077.330.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [xen-unstable test] 10481: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2011-12-13 at 15:20 +0000, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [xen-unstable test] 10481: regressions - FAIL"):
> > On Tue, 2011-12-13 at 15:06 +0000, Ian Jackson wrote:
> > > That's so that if you say "reboot" or "shutdown" and we press the
> > > guest's power button, we know whether, when the guest does shut down,
> > > whether we actually want to restart it.
> > 
> > That would involve potentially communicating with the daemonized version
> > of xl which is monitoring the domain (if it exists) and/or taking over
> > it's function in the xl instance running the shutdown.
> 
> Yes.  That could be done via xenstore of course.

Sure, but there's still a bunch of moving parts to arrange etc.

> > I'm tempted to just go with the minimal improvement at this stage.
> 
> Fair enough.  It's not going to make the test pass though :-).

Makes the test buggy though :-P

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 15:25:42 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 15:25:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaUEZ-0008UJ-8q; Tue, 13 Dec 2011 15:25:35 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RaUEX-0008Sh-Df
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 15:25:33 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1323789830!57123811!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTI1NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 467 invoked from network); 13 Dec 2011 15:23:52 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 15:23:52 -0000
X-IronPort-AV: E=Sophos;i="4.71,345,1320624000"; 
   d="scan'208";a="9444218"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Dec 2011 15:24:41 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 13 Dec 2011 15:24:41 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 13 Dec 2011 15:24:40 +0000
In-Reply-To: <20199.27949.795096.263945@mariner.uk.xensource.com>
References: <osstest-10481-mainreport@xen.org>
	<1323769464.20077.262.camel@zakaz.uk.xensource.com>
	<20199.14342.599850.739029@mariner.uk.xensource.com>
	<1323785260.20077.307.camel@zakaz.uk.xensource.com>
	<20199.24357.180937.882607@mariner.uk.xensource.com>
	<1323786461.20077.312.camel@zakaz.uk.xensource.com>
	<20199.26051.761880.513100@mariner.uk.xensource.com>
	<1323787886.20077.314.camel@zakaz.uk.xensource.com>
	<20199.26388.187010.379029@mariner.uk.xensource.com>
	<1323788535.20077.321.camel@zakaz.uk.xensource.com>
	<20199.27104.948333.593110@mariner.uk.xensource.com>
	<1323789533.20077.326.camel@zakaz.uk.xensource.com>
	<20199.27949.795096.263945@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323789881.20077.330.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [xen-unstable test] 10481: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2011-12-13 at 15:20 +0000, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [xen-unstable test] 10481: regressions - FAIL"):
> > On Tue, 2011-12-13 at 15:06 +0000, Ian Jackson wrote:
> > > That's so that if you say "reboot" or "shutdown" and we press the
> > > guest's power button, we know whether, when the guest does shut down,
> > > whether we actually want to restart it.
> > 
> > That would involve potentially communicating with the daemonized version
> > of xl which is monitoring the domain (if it exists) and/or taking over
> > it's function in the xl instance running the shutdown.
> 
> Yes.  That could be done via xenstore of course.

Sure, but there's still a bunch of moving parts to arrange etc.

> > I'm tempted to just go with the minimal improvement at this stage.
> 
> Fair enough.  It's not going to make the test pass though :-).

Makes the test buggy though :-P

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 15:31:28 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 15:31:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaUK5-0000eu-4M; Tue, 13 Dec 2011 15:31:17 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RaUK3-0000el-M7
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 15:31:15 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1323790221!5374351!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTI1NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26871 invoked from network); 13 Dec 2011 15:30:21 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 15:30:21 -0000
X-IronPort-AV: E=Sophos;i="4.71,345,1320624000"; 
   d="scan'208";a="9444397"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Dec 2011 15:30:20 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 13 Dec 2011 15:30:20 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RaUJA-0007QT-I1; Tue, 13 Dec 2011 15:30:20 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RaUJA-0002Y5-HB;
	Tue, 13 Dec 2011 15:30:20 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20199.28556.518715.556159@mariner.uk.xensource.com>
Date: Tue, 13 Dec 2011 15:30:20 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1323789881.20077.330.camel@zakaz.uk.xensource.com>
References: <osstest-10481-mainreport@xen.org>
	<1323769464.20077.262.camel@zakaz.uk.xensource.com>
	<20199.14342.599850.739029@mariner.uk.xensource.com>
	<1323785260.20077.307.camel@zakaz.uk.xensource.com>
	<20199.24357.180937.882607@mariner.uk.xensource.com>
	<1323786461.20077.312.camel@zakaz.uk.xensource.com>
	<20199.26051.761880.513100@mariner.uk.xensource.com>
	<1323787886.20077.314.camel@zakaz.uk.xensource.com>
	<20199.26388.187010.379029@mariner.uk.xensource.com>
	<1323788535.20077.321.camel@zakaz.uk.xensource.com>
	<20199.27104.948333.593110@mariner.uk.xensource.com>
	<1323789533.20077.326.camel@zakaz.uk.xensource.com>
	<20199.27949.795096.263945@mariner.uk.xensource.com>
	<1323789881.20077.330.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [xen-unstable test] 10481: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("Re: [Xen-devel] [xen-unstable test] 10481: regressions - FAIL"):
> On Tue, 2011-12-13 at 15:20 +0000, Ian Jackson wrote:
> > Fair enough.  It's not going to make the test pass though :-).
> 
> Makes the test buggy though :-P

As discussed, I think that "xl shutdown" should work and therefore the
test is not broken.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 15:31:28 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 15:31:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaUK5-0000eu-4M; Tue, 13 Dec 2011 15:31:17 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RaUK3-0000el-M7
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 15:31:15 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1323790221!5374351!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTI1NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26871 invoked from network); 13 Dec 2011 15:30:21 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 15:30:21 -0000
X-IronPort-AV: E=Sophos;i="4.71,345,1320624000"; 
   d="scan'208";a="9444397"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Dec 2011 15:30:20 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 13 Dec 2011 15:30:20 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RaUJA-0007QT-I1; Tue, 13 Dec 2011 15:30:20 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RaUJA-0002Y5-HB;
	Tue, 13 Dec 2011 15:30:20 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20199.28556.518715.556159@mariner.uk.xensource.com>
Date: Tue, 13 Dec 2011 15:30:20 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1323789881.20077.330.camel@zakaz.uk.xensource.com>
References: <osstest-10481-mainreport@xen.org>
	<1323769464.20077.262.camel@zakaz.uk.xensource.com>
	<20199.14342.599850.739029@mariner.uk.xensource.com>
	<1323785260.20077.307.camel@zakaz.uk.xensource.com>
	<20199.24357.180937.882607@mariner.uk.xensource.com>
	<1323786461.20077.312.camel@zakaz.uk.xensource.com>
	<20199.26051.761880.513100@mariner.uk.xensource.com>
	<1323787886.20077.314.camel@zakaz.uk.xensource.com>
	<20199.26388.187010.379029@mariner.uk.xensource.com>
	<1323788535.20077.321.camel@zakaz.uk.xensource.com>
	<20199.27104.948333.593110@mariner.uk.xensource.com>
	<1323789533.20077.326.camel@zakaz.uk.xensource.com>
	<20199.27949.795096.263945@mariner.uk.xensource.com>
	<1323789881.20077.330.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [xen-unstable test] 10481: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("Re: [Xen-devel] [xen-unstable test] 10481: regressions - FAIL"):
> On Tue, 2011-12-13 at 15:20 +0000, Ian Jackson wrote:
> > Fair enough.  It's not going to make the test pass though :-).
> 
> Makes the test buggy though :-P

As discussed, I think that "xl shutdown" should work and therefore the
test is not broken.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 15:32:28 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 15:32:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaUL0-0000i7-Jq; Tue, 13 Dec 2011 15:32:14 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RaUKz-0000hq-Jt
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 15:32:13 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1323790228!60566082!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTI1NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6430 invoked from network); 13 Dec 2011 15:30:28 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 15:30:28 -0000
X-IronPort-AV: E=Sophos;i="4.71,345,1320624000"; 
   d="scan'208";a="9444422"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Dec 2011 15:31:21 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 13 Dec 2011 15:31:21 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RaUK8-0007Qq-TV; Tue, 13 Dec 2011 15:31:20 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RaUK8-0002Zl-Sd;
	Tue, 13 Dec 2011 15:31:20 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20199.28616.853424.457471@mariner.uk.xensource.com>
Date: Tue, 13 Dec 2011 15:31:20 +0000
To: Ian Campbell <ian.campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1a48c8fbcae917bed86f.1323786729@cosworth.uk.xensource.com>
References: <1a48c8fbcae917bed86f.1323786729@cosworth.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: ian.jackson@citrix.com, xen-devel@lists.xensource.com,
	Adda Rathbone <addarathbone@googlemail.com>,
	Andrew Pounce <andrew.pounce@citrix.com>
Subject: Re: [Xen-devel] [PATCH] libxl: Compile with -Wformat-nonliteral
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("[Xen-devel] [PATCH] libxl: Compile with -Wformat-nonliteral"):
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> Reported-by: Adda Rathbone <addarathbone@googlemail.com>
> Tested-by: Adda Rathbone <addarathbone@googlemail.com>
> Tested-by: Andrew Pounce <andrew.pounce@citrix.com>

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 15:32:28 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 15:32:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaUL0-0000i7-Jq; Tue, 13 Dec 2011 15:32:14 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RaUKz-0000hq-Jt
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 15:32:13 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1323790228!60566082!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTI1NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6430 invoked from network); 13 Dec 2011 15:30:28 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 15:30:28 -0000
X-IronPort-AV: E=Sophos;i="4.71,345,1320624000"; 
   d="scan'208";a="9444422"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Dec 2011 15:31:21 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 13 Dec 2011 15:31:21 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RaUK8-0007Qq-TV; Tue, 13 Dec 2011 15:31:20 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RaUK8-0002Zl-Sd;
	Tue, 13 Dec 2011 15:31:20 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20199.28616.853424.457471@mariner.uk.xensource.com>
Date: Tue, 13 Dec 2011 15:31:20 +0000
To: Ian Campbell <ian.campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1a48c8fbcae917bed86f.1323786729@cosworth.uk.xensource.com>
References: <1a48c8fbcae917bed86f.1323786729@cosworth.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: ian.jackson@citrix.com, xen-devel@lists.xensource.com,
	Adda Rathbone <addarathbone@googlemail.com>,
	Andrew Pounce <andrew.pounce@citrix.com>
Subject: Re: [Xen-devel] [PATCH] libxl: Compile with -Wformat-nonliteral
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("[Xen-devel] [PATCH] libxl: Compile with -Wformat-nonliteral"):
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> Reported-by: Adda Rathbone <addarathbone@googlemail.com>
> Tested-by: Adda Rathbone <addarathbone@googlemail.com>
> Tested-by: Andrew Pounce <andrew.pounce@citrix.com>

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 15:33:55 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 15:33:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaUMU-0000rd-4K; Tue, 13 Dec 2011 15:33:46 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RaUMS-0000rK-7w
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 15:33:44 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1323789547!7179938!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTI1NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9558 invoked from network); 13 Dec 2011 15:19:08 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 15:19:08 -0000
X-IronPort-AV: E=Sophos;i="4.71,345,1320624000"; 
   d="scan'208";a="9444040"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Dec 2011 15:19:07 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 13 Dec 2011 15:19:07 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RaU8J-0007MF-8A; Tue, 13 Dec 2011 15:19:07 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RaU8J-0002WL-7H;
	Tue, 13 Dec 2011 15:19:07 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20199.27883.212315.5167@mariner.uk.xensource.com>
Date: Tue, 13 Dec 2011 15:19:07 +0000
To: Roger Pau Monne <roger.pau@entel.upc.edu>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <d599451d870d77e05c6b.1323768385@loki.upc.es>
References: <patchbomb.1323768375@loki.upc.es>
	<d599451d870d77e05c6b.1323768385@loki.upc.es>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 10 of 14 v4] rc.d NetBSD: don't start
 xenbackendd by default, only when xend needs it
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Roger Pau Monne writes ("[Xen-devel] [PATCH 10 of 14 v4] rc.d NetBSD: don't start xenbackendd by default, only when xend needs it"):
> rc.d NetBSD: don't start xenbackendd by default, only when xend needs it.
> 
> With the move of hotplug scripts from xenbackendd to libxl
> xenbackendd is no longer needed by libxl, only start it when xend is
> started.

This looks plausible given the other patches in the series.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 15:33:55 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 15:33:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaUMU-0000rd-4K; Tue, 13 Dec 2011 15:33:46 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RaUMS-0000rK-7w
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 15:33:44 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1323789547!7179938!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTI1NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9558 invoked from network); 13 Dec 2011 15:19:08 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 15:19:08 -0000
X-IronPort-AV: E=Sophos;i="4.71,345,1320624000"; 
   d="scan'208";a="9444040"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Dec 2011 15:19:07 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 13 Dec 2011 15:19:07 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RaU8J-0007MF-8A; Tue, 13 Dec 2011 15:19:07 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RaU8J-0002WL-7H;
	Tue, 13 Dec 2011 15:19:07 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20199.27883.212315.5167@mariner.uk.xensource.com>
Date: Tue, 13 Dec 2011 15:19:07 +0000
To: Roger Pau Monne <roger.pau@entel.upc.edu>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <d599451d870d77e05c6b.1323768385@loki.upc.es>
References: <patchbomb.1323768375@loki.upc.es>
	<d599451d870d77e05c6b.1323768385@loki.upc.es>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 10 of 14 v4] rc.d NetBSD: don't start
 xenbackendd by default, only when xend needs it
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Roger Pau Monne writes ("[Xen-devel] [PATCH 10 of 14 v4] rc.d NetBSD: don't start xenbackendd by default, only when xend needs it"):
> rc.d NetBSD: don't start xenbackendd by default, only when xend needs it.
> 
> With the move of hotplug scripts from xenbackendd to libxl
> xenbackendd is no longer needed by libxl, only start it when xend is
> started.

This looks plausible given the other patches in the series.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 15:41:31 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 15:41:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaUTm-0001EX-3I; Tue, 13 Dec 2011 15:41:18 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RaUTk-0001ES-KH
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 15:41:16 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1323790821!7081886!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTI1NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1644 invoked from network); 13 Dec 2011 15:40:22 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 15:40:22 -0000
X-IronPort-AV: E=Sophos;i="4.71,345,1320624000"; 
   d="scan'208";a="9444674"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Dec 2011 15:40:14 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 13 Dec 2011 15:40:14 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RaUSk-0007Tx-00; Tue, 13 Dec 2011 15:40:14 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RaUSj-0002ab-VT;
	Tue, 13 Dec 2011 15:40:13 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20199.29149.962530.171668@mariner.uk.xensource.com>
Date: Tue, 13 Dec 2011 15:40:13 +0000
To: Miroslav Rezanina <mrezanin@redhat.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <83000c07-d9cc-48fe-ab0a-e07aaf2f1b3b@zmail13.collab.prod.int.phx2.redhat.com>
References: <54c8f8bc-2f0d-439e-8106-937b433b73a8@zmail13.collab.prod.int.phx2.redhat.com>
	<83000c07-d9cc-48fe-ab0a-e07aaf2f1b3b@zmail13.collab.prod.int.phx2.redhat.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] pygrub: Fix entry editing in grub2
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Miroslav Rezanina writes ("[Xen-devel] pygrub: Fix entry editing in grub2"):
> When user wants to change entry in grub2 menu in pygrub, there's no
> response in case of appending command line arguments ('a' key) and
> may be crash of pygrub in case of editing item ('e' key).

Thanks.  I applied this.  It should really have been two separate
patches, since these are unrelated bugfixes.  I split it up for you
into two separate commits.

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 15:41:31 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 15:41:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaUTm-0001EX-3I; Tue, 13 Dec 2011 15:41:18 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RaUTk-0001ES-KH
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 15:41:16 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1323790821!7081886!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTI1NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1644 invoked from network); 13 Dec 2011 15:40:22 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 15:40:22 -0000
X-IronPort-AV: E=Sophos;i="4.71,345,1320624000"; 
   d="scan'208";a="9444674"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Dec 2011 15:40:14 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 13 Dec 2011 15:40:14 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RaUSk-0007Tx-00; Tue, 13 Dec 2011 15:40:14 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RaUSj-0002ab-VT;
	Tue, 13 Dec 2011 15:40:13 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20199.29149.962530.171668@mariner.uk.xensource.com>
Date: Tue, 13 Dec 2011 15:40:13 +0000
To: Miroslav Rezanina <mrezanin@redhat.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <83000c07-d9cc-48fe-ab0a-e07aaf2f1b3b@zmail13.collab.prod.int.phx2.redhat.com>
References: <54c8f8bc-2f0d-439e-8106-937b433b73a8@zmail13.collab.prod.int.phx2.redhat.com>
	<83000c07-d9cc-48fe-ab0a-e07aaf2f1b3b@zmail13.collab.prod.int.phx2.redhat.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] pygrub: Fix entry editing in grub2
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Miroslav Rezanina writes ("[Xen-devel] pygrub: Fix entry editing in grub2"):
> When user wants to change entry in grub2 menu in pygrub, there's no
> response in case of appending command line arguments ('a' key) and
> may be crash of pygrub in case of editing item ('e' key).

Thanks.  I applied this.  It should really have been two separate
patches, since these are unrelated bugfixes.  I split it up for you
into two separate commits.

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 15:43:49 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 15:43:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaUW1-0001KP-Kz; Tue, 13 Dec 2011 15:43:37 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RaUW0-0001K5-Et
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 15:43:36 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1323790962!7079249!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTI1NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31078 invoked from network); 13 Dec 2011 15:42:42 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 15:42:42 -0000
X-IronPort-AV: E=Sophos;i="4.71,345,1320624000"; 
   d="scan'208";a="9444753"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Dec 2011 15:42:41 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 13 Dec 2011 15:42:41 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RaUV7-0007Ui-8w; Tue, 13 Dec 2011 15:42:41 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RaUV7-0002gq-7u;
	Tue, 13 Dec 2011 15:42:41 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20199.29297.231504.202689@mariner.uk.xensource.com>
Date: Tue, 13 Dec 2011 15:42:41 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1323772577.20077.271.camel@zakaz.uk.xensource.com>
References: <osstest-10481-mainreport@xen.org>
	<1323769464.20077.262.camel@zakaz.uk.xensource.com>
	<1323772577.20077.271.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH] libxl: do not leak qemu saved state on restore
 (Was: Re: [xen-unstable test] 10481: regressions - FAIL)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("[Xen-devel] [PATCH] libxl: do not leak qemu saved state on restore (Was: Re: [xen-unstable test] 10481: regressions - FAIL)"):
> These happen to all be xend failures but the only reason xl doesn't have
> this is that those tests all fail at the guest-stop stage and never get
> as far as the migration test. Here is the fix for the xl version, fixing
> the xend side seems less trivial and I don't propose to dig into it.

Thanks.

> # HG changeset patch
> # User Ian Campbell <ian.campbell@citrix.com>
> # Date 1323772303 0
> # Node ID 9ea12474c6dcd75bbbc7a5c62a2b96de902ccb83
> # Parent  88df802b4905d7e34032eacf1942b70c76d150a4
> libxl: do not leak qemu saved state on restore
> 
> In particular do not leak /var/lib/xen/qemu-resume.<domid>.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 15:43:49 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 15:43:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaUW1-0001KP-Kz; Tue, 13 Dec 2011 15:43:37 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RaUW0-0001K5-Et
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 15:43:36 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1323790962!7079249!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTI1NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31078 invoked from network); 13 Dec 2011 15:42:42 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 15:42:42 -0000
X-IronPort-AV: E=Sophos;i="4.71,345,1320624000"; 
   d="scan'208";a="9444753"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Dec 2011 15:42:41 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 13 Dec 2011 15:42:41 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RaUV7-0007Ui-8w; Tue, 13 Dec 2011 15:42:41 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RaUV7-0002gq-7u;
	Tue, 13 Dec 2011 15:42:41 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20199.29297.231504.202689@mariner.uk.xensource.com>
Date: Tue, 13 Dec 2011 15:42:41 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1323772577.20077.271.camel@zakaz.uk.xensource.com>
References: <osstest-10481-mainreport@xen.org>
	<1323769464.20077.262.camel@zakaz.uk.xensource.com>
	<1323772577.20077.271.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH] libxl: do not leak qemu saved state on restore
 (Was: Re: [xen-unstable test] 10481: regressions - FAIL)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("[Xen-devel] [PATCH] libxl: do not leak qemu saved state on restore (Was: Re: [xen-unstable test] 10481: regressions - FAIL)"):
> These happen to all be xend failures but the only reason xl doesn't have
> this is that those tests all fail at the guest-stop stage and never get
> as far as the migration test. Here is the fix for the xl version, fixing
> the xend side seems less trivial and I don't propose to dig into it.

Thanks.

> # HG changeset patch
> # User Ian Campbell <ian.campbell@citrix.com>
> # Date 1323772303 0
> # Node ID 9ea12474c6dcd75bbbc7a5c62a2b96de902ccb83
> # Parent  88df802b4905d7e34032eacf1942b70c76d150a4
> libxl: do not leak qemu saved state on restore
> 
> In particular do not leak /var/lib/xen/qemu-resume.<domid>.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 15:46:21 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 15:46:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaUYV-0001UZ-BI; Tue, 13 Dec 2011 15:46:11 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RaUYT-0001UE-TH
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 15:46:10 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1323791115!8643104!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTI1NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26422 invoked from network); 13 Dec 2011 15:45:15 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 15:45:15 -0000
X-IronPort-AV: E=Sophos;i="4.71,345,1320624000"; 
   d="scan'208";a="9444815"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Dec 2011 15:45:14 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 13 Dec 2011 15:45:14 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RaUXa-0007VZ-CE; Tue, 13 Dec 2011 15:45:14 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RaUXa-0002hJ-BP;
	Tue, 13 Dec 2011 15:45:14 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20199.29450.340394.886899@mariner.uk.xensource.com>
Date: Tue, 13 Dec 2011 15:45:14 +0000
To: Paul Durrant <paul.durrant@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <9eaac880f504a12c145d.1323250728@cosworth.uk.xensource.com>
References: <9eaac880f504a12c145d.1323250728@cosworth.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] VM generation ID save/restore and migrate
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Paul Durrant writes ("[Xen-devel] [PATCH] VM generation ID save/restore and migrate"):
> VM generation ID save/restore and migrate.
> 
> Add code to track the address of the VM generation id buffer across a
> save/restore or migrate and increment it as necessary.
> The address of the buffer is written into xenstore by hvmloader at
> boot time. It must be read from xenstore by the caller of
> xc_domain_save() and then written back again by the caller of
> xc_domain_restore().
...
> +        if ( RDEXACT(fd, &buf->vm_gid_addr, sizeof(uint32_t)) ||
> +             RDEXACT(fd, &buf->vm_gid_addr, sizeof(uint64_t)) )

I'm generally OK with this, but I have two comments.  Firstly
"vm_gid_addr" etc. is a bit opaque and there might be lots of things
called a "g identifier".

Perhaps we could call these variables
  vm_generationid_addr
or something ?

> +    ents[12] = "data/generation-id";

And this xenstore key suggests that the value is the id, not the
address.  I think it should be renamed.

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 15:46:21 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 15:46:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaUYV-0001UZ-BI; Tue, 13 Dec 2011 15:46:11 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RaUYT-0001UE-TH
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 15:46:10 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1323791115!8643104!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTI1NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26422 invoked from network); 13 Dec 2011 15:45:15 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 15:45:15 -0000
X-IronPort-AV: E=Sophos;i="4.71,345,1320624000"; 
   d="scan'208";a="9444815"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Dec 2011 15:45:14 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 13 Dec 2011 15:45:14 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RaUXa-0007VZ-CE; Tue, 13 Dec 2011 15:45:14 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RaUXa-0002hJ-BP;
	Tue, 13 Dec 2011 15:45:14 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20199.29450.340394.886899@mariner.uk.xensource.com>
Date: Tue, 13 Dec 2011 15:45:14 +0000
To: Paul Durrant <paul.durrant@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <9eaac880f504a12c145d.1323250728@cosworth.uk.xensource.com>
References: <9eaac880f504a12c145d.1323250728@cosworth.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] VM generation ID save/restore and migrate
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Paul Durrant writes ("[Xen-devel] [PATCH] VM generation ID save/restore and migrate"):
> VM generation ID save/restore and migrate.
> 
> Add code to track the address of the VM generation id buffer across a
> save/restore or migrate and increment it as necessary.
> The address of the buffer is written into xenstore by hvmloader at
> boot time. It must be read from xenstore by the caller of
> xc_domain_save() and then written back again by the caller of
> xc_domain_restore().
...
> +        if ( RDEXACT(fd, &buf->vm_gid_addr, sizeof(uint32_t)) ||
> +             RDEXACT(fd, &buf->vm_gid_addr, sizeof(uint64_t)) )

I'm generally OK with this, but I have two comments.  Firstly
"vm_gid_addr" etc. is a bit opaque and there might be lots of things
called a "g identifier".

Perhaps we could call these variables
  vm_generationid_addr
or something ?

> +    ents[12] = "data/generation-id";

And this xenstore key suggests that the value is the id, not the
address.  I think it should be renamed.

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 15:46:55 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 15:46:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaUZ2-0001Y6-Pc; Tue, 13 Dec 2011 15:46:44 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RaUZ1-0001XS-7u
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 15:46:43 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1323791148!6558537!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTI1NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8855 invoked from network); 13 Dec 2011 15:45:49 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 15:45:49 -0000
X-IronPort-AV: E=Sophos;i="4.71,345,1320624000"; 
   d="scan'208";a="9444832"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Dec 2011 15:45:48 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 13 Dec 2011 15:45:48 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 13 Dec 2011 15:45:48 +0000
In-Reply-To: <20199.27598.186154.715821@mariner.uk.xensource.com>
References: <patchbomb.1323768375@loki.upc.es>
	<573a246bf0c6b3ad0147.1323768378@loki.upc.es>
	<20199.27598.186154.715821@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323791148.20077.338.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Roger Pau Monne <roger.pau@entel.upc.edu>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 03 of 14 v4] libxl: add libxl__forkexec
 function	to libxl_exec
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2011-12-13 at 15:14 +0000, Ian Jackson wrote:
> 
> > + * gc: allocation pool
> > + * stdinfd, stdoutfd, stderrfd: fds to pass to libxl__exec
> > + * args: file to execute and arguments to pass in the following
> format
> > + *      args[0]: file to execute
> > + *      args[1]: first argument to pass to the called program
> > + *      ...
> > + *      args[n-1]: (n-1)th argument to pass to the called program
> > + *      args[n]: NULL
> 
> IMO all of the above is obvious and should be eliminated.  (This is
> exactly the kind of "fd is the file descriptor" stuff that I was
> complaining about in another recent thread.) 

The definition of args[0] as the actual executable (or argv0) and the
requirement for args[n] == NULL are interesting enough to mention I
think (the NULL thing in particular often trips people up). But you
could also just reference execvp(3).

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 15:46:55 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 15:46:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaUZ2-0001Y6-Pc; Tue, 13 Dec 2011 15:46:44 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RaUZ1-0001XS-7u
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 15:46:43 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1323791148!6558537!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTI1NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8855 invoked from network); 13 Dec 2011 15:45:49 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 15:45:49 -0000
X-IronPort-AV: E=Sophos;i="4.71,345,1320624000"; 
   d="scan'208";a="9444832"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Dec 2011 15:45:48 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 13 Dec 2011 15:45:48 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 13 Dec 2011 15:45:48 +0000
In-Reply-To: <20199.27598.186154.715821@mariner.uk.xensource.com>
References: <patchbomb.1323768375@loki.upc.es>
	<573a246bf0c6b3ad0147.1323768378@loki.upc.es>
	<20199.27598.186154.715821@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323791148.20077.338.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Roger Pau Monne <roger.pau@entel.upc.edu>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 03 of 14 v4] libxl: add libxl__forkexec
 function	to libxl_exec
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2011-12-13 at 15:14 +0000, Ian Jackson wrote:
> 
> > + * gc: allocation pool
> > + * stdinfd, stdoutfd, stderrfd: fds to pass to libxl__exec
> > + * args: file to execute and arguments to pass in the following
> format
> > + *      args[0]: file to execute
> > + *      args[1]: first argument to pass to the called program
> > + *      ...
> > + *      args[n-1]: (n-1)th argument to pass to the called program
> > + *      args[n]: NULL
> 
> IMO all of the above is obvious and should be eliminated.  (This is
> exactly the kind of "fd is the file descriptor" stuff that I was
> complaining about in another recent thread.) 

The definition of args[0] as the actual executable (or argv0) and the
requirement for args[n] == NULL are interesting enough to mention I
think (the NULL thing in particular often trips people up). But you
could also just reference execvp(3).

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 15:47:13 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 15:47:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaUZM-0001aS-6o; Tue, 13 Dec 2011 15:47:04 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RaUZL-0001Zf-GU
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 15:47:03 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1323791168!1783046!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTI1NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13461 invoked from network); 13 Dec 2011 15:46:08 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 15:46:08 -0000
X-IronPort-AV: E=Sophos;i="4.71,345,1320624000"; 
   d="scan'208";a="9444844"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Dec 2011 15:46:08 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 13 Dec 2011 15:46:08 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 13 Dec 2011 15:46:07 +0000
In-Reply-To: <20199.28556.518715.556159@mariner.uk.xensource.com>
References: <osstest-10481-mainreport@xen.org>
	<1323769464.20077.262.camel@zakaz.uk.xensource.com>
	<20199.14342.599850.739029@mariner.uk.xensource.com>
	<1323785260.20077.307.camel@zakaz.uk.xensource.com>
	<20199.24357.180937.882607@mariner.uk.xensource.com>
	<1323786461.20077.312.camel@zakaz.uk.xensource.com>
	<20199.26051.761880.513100@mariner.uk.xensource.com>
	<1323787886.20077.314.camel@zakaz.uk.xensource.com>
	<20199.26388.187010.379029@mariner.uk.xensource.com>
	<1323788535.20077.321.camel@zakaz.uk.xensource.com>
	<20199.27104.948333.593110@mariner.uk.xensource.com>
	<1323789533.20077.326.camel@zakaz.uk.xensource.com>
	<20199.27949.795096.263945@mariner.uk.xensource.com>
	<1323789881.20077.330.camel@zakaz.uk.xensource.com>
	<20199.28556.518715.556159@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323791167.20077.339.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [xen-unstable test] 10481: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2011-12-13 at 15:30 +0000, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [xen-unstable test] 10481: regressions - FAIL"):
> > On Tue, 2011-12-13 at 15:20 +0000, Ian Jackson wrote:
> > > Fair enough.  It's not going to make the test pass though :-).
> > 
> > Makes the test buggy though :-P
> 
> As discussed, I think that "xl shutdown" should work and therefore the
> test is not broken.

"xl shutdown" is currently behaving precisely as documented.

Setting aside the complexity of implementing the behaviour you desire
playing tricks with turning power button derived reboots into shutdowns
and vice versa "xl shutdown" cannot work reliably because the guest can
perform effectively arbitrary actions on power button press, doing
nothing is one option and suspend/hibernation is the other common
reaction which we certainly do not want to trigger when attempting to
shutdown or reboot.

In short I don't think the behaviour you desire is ever going to happen.

This test failure is preventing us from testing a much more interesting
scenario, specifically HVM guest migration.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 15:47:13 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 15:47:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaUZM-0001aS-6o; Tue, 13 Dec 2011 15:47:04 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RaUZL-0001Zf-GU
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 15:47:03 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1323791168!1783046!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTI1NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13461 invoked from network); 13 Dec 2011 15:46:08 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 15:46:08 -0000
X-IronPort-AV: E=Sophos;i="4.71,345,1320624000"; 
   d="scan'208";a="9444844"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Dec 2011 15:46:08 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 13 Dec 2011 15:46:08 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 13 Dec 2011 15:46:07 +0000
In-Reply-To: <20199.28556.518715.556159@mariner.uk.xensource.com>
References: <osstest-10481-mainreport@xen.org>
	<1323769464.20077.262.camel@zakaz.uk.xensource.com>
	<20199.14342.599850.739029@mariner.uk.xensource.com>
	<1323785260.20077.307.camel@zakaz.uk.xensource.com>
	<20199.24357.180937.882607@mariner.uk.xensource.com>
	<1323786461.20077.312.camel@zakaz.uk.xensource.com>
	<20199.26051.761880.513100@mariner.uk.xensource.com>
	<1323787886.20077.314.camel@zakaz.uk.xensource.com>
	<20199.26388.187010.379029@mariner.uk.xensource.com>
	<1323788535.20077.321.camel@zakaz.uk.xensource.com>
	<20199.27104.948333.593110@mariner.uk.xensource.com>
	<1323789533.20077.326.camel@zakaz.uk.xensource.com>
	<20199.27949.795096.263945@mariner.uk.xensource.com>
	<1323789881.20077.330.camel@zakaz.uk.xensource.com>
	<20199.28556.518715.556159@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323791167.20077.339.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [xen-unstable test] 10481: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2011-12-13 at 15:30 +0000, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [xen-unstable test] 10481: regressions - FAIL"):
> > On Tue, 2011-12-13 at 15:20 +0000, Ian Jackson wrote:
> > > Fair enough.  It's not going to make the test pass though :-).
> > 
> > Makes the test buggy though :-P
> 
> As discussed, I think that "xl shutdown" should work and therefore the
> test is not broken.

"xl shutdown" is currently behaving precisely as documented.

Setting aside the complexity of implementing the behaviour you desire
playing tricks with turning power button derived reboots into shutdowns
and vice versa "xl shutdown" cannot work reliably because the guest can
perform effectively arbitrary actions on power button press, doing
nothing is one option and suspend/hibernation is the other common
reaction which we certainly do not want to trigger when attempting to
shutdown or reboot.

In short I don't think the behaviour you desire is ever going to happen.

This test failure is preventing us from testing a much more interesting
scenario, specifically HVM guest migration.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 15:49:15 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 15:49:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaUbL-0001wm-VT; Tue, 13 Dec 2011 15:49:07 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RaUbK-0001vq-DJ
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 15:49:06 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1323791291!7100754!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTI1NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14229 invoked from network); 13 Dec 2011 15:48:12 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 15:48:12 -0000
X-IronPort-AV: E=Sophos;i="4.71,345,1320624000"; 
   d="scan'208";a="9444908"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Dec 2011 15:48:11 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 13 Dec 2011 15:48:11 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RaUaR-0007Wa-2h; Tue, 13 Dec 2011 15:48:11 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RaUaR-0002jG-1r;
	Tue, 13 Dec 2011 15:48:11 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20199.29623.232910.65813@mariner.uk.xensource.com>
Date: Tue, 13 Dec 2011 15:48:07 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1323791148.20077.338.camel@zakaz.uk.xensource.com>
References: <patchbomb.1323768375@loki.upc.es>
	<573a246bf0c6b3ad0147.1323768378@loki.upc.es>
	<20199.27598.186154.715821@mariner.uk.xensource.com>
	<1323791148.20077.338.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Roger Pau Monne <roger.pau@entel.upc.edu>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 03 of 14 v4] libxl: add libxl__forkexec
 function	to libxl_exec
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("Re: [Xen-devel] [PATCH 03 of 14 v4] libxl: add libxl__forkexec function	to libxl_exec"):
> On Tue, 2011-12-13 at 15:14 +0000, Ian Jackson wrote:
> > IMO all of the above is obvious and should be eliminated.  (This is
> > exactly the kind of "fd is the file descriptor" stuff that I was
> > complaining about in another recent thread.) 
> 
> The definition of args[0] as the actual executable (or argv0) and the
> requirement for args[n] == NULL are interesting enough to mention I
> think (the NULL thing in particular often trips people up). But you
> could also just reference execvp(3).

I think it would be better to reference execvp.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 15:49:15 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 15:49:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaUbL-0001wm-VT; Tue, 13 Dec 2011 15:49:07 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RaUbK-0001vq-DJ
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 15:49:06 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1323791291!7100754!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTI1NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14229 invoked from network); 13 Dec 2011 15:48:12 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 15:48:12 -0000
X-IronPort-AV: E=Sophos;i="4.71,345,1320624000"; 
   d="scan'208";a="9444908"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Dec 2011 15:48:11 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 13 Dec 2011 15:48:11 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RaUaR-0007Wa-2h; Tue, 13 Dec 2011 15:48:11 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RaUaR-0002jG-1r;
	Tue, 13 Dec 2011 15:48:11 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20199.29623.232910.65813@mariner.uk.xensource.com>
Date: Tue, 13 Dec 2011 15:48:07 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1323791148.20077.338.camel@zakaz.uk.xensource.com>
References: <patchbomb.1323768375@loki.upc.es>
	<573a246bf0c6b3ad0147.1323768378@loki.upc.es>
	<20199.27598.186154.715821@mariner.uk.xensource.com>
	<1323791148.20077.338.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Roger Pau Monne <roger.pau@entel.upc.edu>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 03 of 14 v4] libxl: add libxl__forkexec
 function	to libxl_exec
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("Re: [Xen-devel] [PATCH 03 of 14 v4] libxl: add libxl__forkexec function	to libxl_exec"):
> On Tue, 2011-12-13 at 15:14 +0000, Ian Jackson wrote:
> > IMO all of the above is obvious and should be eliminated.  (This is
> > exactly the kind of "fd is the file descriptor" stuff that I was
> > complaining about in another recent thread.) 
> 
> The definition of args[0] as the actual executable (or argv0) and the
> requirement for args[n] == NULL are interesting enough to mention I
> think (the NULL thing in particular often trips people up). But you
> could also just reference execvp(3).

I think it would be better to reference execvp.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 15:50:14 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 15:50:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaUcF-00024g-E9; Tue, 13 Dec 2011 15:50:03 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RaUcD-00023j-KI
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 15:50:01 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1323791346!5220762!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTI1NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6201 invoked from network); 13 Dec 2011 15:49:07 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 15:49:07 -0000
X-IronPort-AV: E=Sophos;i="4.71,346,1320624000"; 
   d="scan'208";a="9444916"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Dec 2011 15:48:35 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 13 Dec 2011 15:48:35 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RaUap-0007Wi-6U; Tue, 13 Dec 2011 15:48:35 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RaUap-0002jK-5p;
	Tue, 13 Dec 2011 15:48:35 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20199.29651.168419.834001@mariner.uk.xensource.com>
Date: Tue, 13 Dec 2011 15:48:35 +0000
To: Ian Campbell <ian.campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <patchbomb.1323432164@cosworth.uk.xensource.com>
References: <patchbomb.1323432164@cosworth.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 0 of 2] Qemu stubdom PCI fixlets
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("[Xen-devel] [PATCH 0 of 2] Qemu stubdom PCI fixlets"):
> 

Applied both, thanks.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 15:50:14 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 15:50:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaUcF-00024g-E9; Tue, 13 Dec 2011 15:50:03 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RaUcD-00023j-KI
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 15:50:01 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1323791346!5220762!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTI1NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6201 invoked from network); 13 Dec 2011 15:49:07 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 15:49:07 -0000
X-IronPort-AV: E=Sophos;i="4.71,346,1320624000"; 
   d="scan'208";a="9444916"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Dec 2011 15:48:35 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 13 Dec 2011 15:48:35 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RaUap-0007Wi-6U; Tue, 13 Dec 2011 15:48:35 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RaUap-0002jK-5p;
	Tue, 13 Dec 2011 15:48:35 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20199.29651.168419.834001@mariner.uk.xensource.com>
Date: Tue, 13 Dec 2011 15:48:35 +0000
To: Ian Campbell <ian.campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <patchbomb.1323432164@cosworth.uk.xensource.com>
References: <patchbomb.1323432164@cosworth.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 0 of 2] Qemu stubdom PCI fixlets
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("[Xen-devel] [PATCH 0 of 2] Qemu stubdom PCI fixlets"):
> 

Applied both, thanks.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 15:53:32 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 15:53:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaUfT-0002O1-2z; Tue, 13 Dec 2011 15:53:23 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RaUfR-0002Ng-V2
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 15:53:22 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1323791547!7241468!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTI1NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21884 invoked from network); 13 Dec 2011 15:52:27 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 15:52:27 -0000
X-IronPort-AV: E=Sophos;i="4.71,346,1320624000"; 
   d="scan'208";a="9445072"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Dec 2011 15:52:27 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 13 Dec 2011 15:52:26 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RaUeY-0007YF-NF; Tue, 13 Dec 2011 15:52:26 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RaUeY-0003u9-MD;
	Tue, 13 Dec 2011 15:52:26 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20199.29882.675830.388738@mariner.uk.xensource.com>
Date: Tue, 13 Dec 2011 15:52:26 +0000
To: Ian Campbell <ian.campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <74f94e15bfe1dad412d0.1323448643@cosworth.uk.xensource.com>
References: <patchbomb.1323448640@cosworth.uk.xensource.com>
	<74f94e15bfe1dad412d0.1323448643@cosworth.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Olaf Hering <olaf@aepfle.de>, xen-devel@lists.xensource.com,
	Vincent Hanquez <Vincent.Hanquez@eu.citrix.com>,
	Jonathan Ludlam <Jonathan.Ludlam@eu.citrix.com>, konrad.wilk@oracle.com
Subject: Re: [Xen-devel] [PATCH 3 of 4] oxenstored: handle unknown
 operations by returning an error to the client
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("[Xen-devel] [PATCH 3 of 4] oxenstored: handle unknown operations by returning an error to the client"):
> oxenstored: handle unknown operations by returning an error to the client

This introduces a new warning:

  File "logging.ml", line 157, characters 14-1067:
  Warning P: this pattern-matching is not exhaustive.
  Here is an example of a value that is not matched:
  Invalid

I have applied 1/4 and 2/4.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 15:53:32 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 15:53:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaUfT-0002O1-2z; Tue, 13 Dec 2011 15:53:23 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RaUfR-0002Ng-V2
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 15:53:22 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1323791547!7241468!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTI1NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21884 invoked from network); 13 Dec 2011 15:52:27 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 15:52:27 -0000
X-IronPort-AV: E=Sophos;i="4.71,346,1320624000"; 
   d="scan'208";a="9445072"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Dec 2011 15:52:27 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 13 Dec 2011 15:52:26 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RaUeY-0007YF-NF; Tue, 13 Dec 2011 15:52:26 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RaUeY-0003u9-MD;
	Tue, 13 Dec 2011 15:52:26 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20199.29882.675830.388738@mariner.uk.xensource.com>
Date: Tue, 13 Dec 2011 15:52:26 +0000
To: Ian Campbell <ian.campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <74f94e15bfe1dad412d0.1323448643@cosworth.uk.xensource.com>
References: <patchbomb.1323448640@cosworth.uk.xensource.com>
	<74f94e15bfe1dad412d0.1323448643@cosworth.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Olaf Hering <olaf@aepfle.de>, xen-devel@lists.xensource.com,
	Vincent Hanquez <Vincent.Hanquez@eu.citrix.com>,
	Jonathan Ludlam <Jonathan.Ludlam@eu.citrix.com>, konrad.wilk@oracle.com
Subject: Re: [Xen-devel] [PATCH 3 of 4] oxenstored: handle unknown
 operations by returning an error to the client
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("[Xen-devel] [PATCH 3 of 4] oxenstored: handle unknown operations by returning an error to the client"):
> oxenstored: handle unknown operations by returning an error to the client

This introduces a new warning:

  File "logging.ml", line 157, characters 14-1067:
  Warning P: this pattern-matching is not exhaustive.
  Here is an example of a value that is not matched:
  Invalid

I have applied 1/4 and 2/4.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 15:55:33 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 15:55:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaUhN-0002WY-Kq; Tue, 13 Dec 2011 15:55:21 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RaUhL-0002W2-LJ
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 15:55:19 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1323791664!8644328!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTI1NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25214 invoked from network); 13 Dec 2011 15:54:25 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 15:54:25 -0000
X-IronPort-AV: E=Sophos;i="4.71,346,1320624000"; 
   d="scan'208";a="9445143"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Dec 2011 15:54:24 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 13 Dec 2011 15:54:24 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RaUgS-0007Yu-9Z; Tue, 13 Dec 2011 15:54:24 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RaUgS-0003uQ-8j;
	Tue, 13 Dec 2011 15:54:24 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20199.30000.105401.697750@mariner.uk.xensource.com>
Date: Tue, 13 Dec 2011 15:54:24 +0000
To: Sander Eikelenboom <linux@eikelenboom.it>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <707238508.20111212194525@eikelenboom.it>
References: <20198.11738.646611.204591@mariner.uk.xensource.com>
	<707238508.20111212194525@eikelenboom.it>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Lars Kurth <lars.kurth@citrix.com>, xen-devel@lists.xensource.com,
	security@xen.org
Subject: Re: [Xen-devel] Security vulnerability process - confirmed
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Sander Eikelenboom writes ("Re: [Xen-devel] Security vulnerability process - confirmed"):
> Monday, December 12, 2011, 5:37:46 PM, you wrote:
> >    Public advisories will be posted to xen-devel.
...> 
> >    Copies will also be sent to the pre-disclosure list, unless
> >    the advisory was already sent there previously during the embargo
> >    period and has not been updated since.
> 
> shouldn't this include at least xen-users and xen-announce,

I think the Xen.org security team will be happy to send the messages
to a wider audience.  Lars, can you change this to say:

   Public advisories will be posted to xen-devel, xen-users and
   xen-annnounce.

?

> and perhaps a special read only list for security advisories ?

I think xen-announce will probably do.  It's very low traffic.

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 15:55:33 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 15:55:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaUhN-0002WY-Kq; Tue, 13 Dec 2011 15:55:21 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RaUhL-0002W2-LJ
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 15:55:19 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1323791664!8644328!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTI1NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25214 invoked from network); 13 Dec 2011 15:54:25 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 15:54:25 -0000
X-IronPort-AV: E=Sophos;i="4.71,346,1320624000"; 
   d="scan'208";a="9445143"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Dec 2011 15:54:24 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 13 Dec 2011 15:54:24 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RaUgS-0007Yu-9Z; Tue, 13 Dec 2011 15:54:24 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RaUgS-0003uQ-8j;
	Tue, 13 Dec 2011 15:54:24 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20199.30000.105401.697750@mariner.uk.xensource.com>
Date: Tue, 13 Dec 2011 15:54:24 +0000
To: Sander Eikelenboom <linux@eikelenboom.it>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <707238508.20111212194525@eikelenboom.it>
References: <20198.11738.646611.204591@mariner.uk.xensource.com>
	<707238508.20111212194525@eikelenboom.it>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Lars Kurth <lars.kurth@citrix.com>, xen-devel@lists.xensource.com,
	security@xen.org
Subject: Re: [Xen-devel] Security vulnerability process - confirmed
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Sander Eikelenboom writes ("Re: [Xen-devel] Security vulnerability process - confirmed"):
> Monday, December 12, 2011, 5:37:46 PM, you wrote:
> >    Public advisories will be posted to xen-devel.
...> 
> >    Copies will also be sent to the pre-disclosure list, unless
> >    the advisory was already sent there previously during the embargo
> >    period and has not been updated since.
> 
> shouldn't this include at least xen-users and xen-announce,

I think the Xen.org security team will be happy to send the messages
to a wider audience.  Lars, can you change this to say:

   Public advisories will be posted to xen-devel, xen-users and
   xen-annnounce.

?

> and perhaps a special read only list for security advisories ?

I think xen-announce will probably do.  It's very low traffic.

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 15:57:20 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 15:57:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaUj8-0002fL-8b; Tue, 13 Dec 2011 15:57:10 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RaUj7-0002f2-JA
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 15:57:09 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1323791774!7293652!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTI1NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11381 invoked from network); 13 Dec 2011 15:56:15 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 15:56:15 -0000
X-IronPort-AV: E=Sophos;i="4.71,346,1320624000"; 
   d="scan'208";a="9445196"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Dec 2011 15:56:14 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 13 Dec 2011 15:56:14 +0000
Date: Tue, 13 Dec 2011 15:57:56 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1323445279.20077.76.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1112131554400.3517@kaball-desktop>
References: <alpine.DEB.2.00.1112091208420.3517@kaball-desktop>
	<1323436408-16335-6-git-send-email-stefano.stabellini@eu.citrix.com>
	<4EE21C4602000078000667AA@nat28.tlf.novell.com>
	<1323438026.20077.51.camel@zakaz.uk.xensource.com> 
	<4EE2335A020000780006688C@nat28.tlf.novell.com>
	<1323444231.20077.72.camel@zakaz.uk.xensource.com>
	<4EE2388702000078000668BF@nat28.tlf.novell.com>
	<1323445279.20077.76.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"keir.xen@gmail.com" <keir.xen@gmail.com>,
	"Tim Deegan \(3P\)" <Tim.Deegan@citrix.com>,
	Jan Beulich <JBeulich@suse.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v2 06/25] libelf-loader: introduce
	elf_load_image
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 9 Dec 2011, Ian Campbell wrote:
> This ARM port has no PV guests so it has no "user" in the sense that
> x86's copy_to_user means, so copy_to_user and copy_to_guest are both the
> same and do things the HVM way.
> 
> Maybe the right thing to do is to not supply copy_to_user on ARM at all.
> I had feared this would be a big bit of string to pull on but it seems
> that copy_to_user isn't actually widely used in common code:
> $ rgrep --binary-files=without-match copy_to_user xen | grep -vE x86\|ia64\|asm
> xen/common/gdbstub.c:        r = gdb_arch_copy_to_user((void*)addr, (void*)&val, 1);
> xen/include/linux/gdbstub.h:unsigned int gdb_arch_copy_to_user(
> xen/include/xen/gdbstub.h:unsigned int gdb_arch_copy_to_user(

We are not compiling gdbstub at the moment.

> Stefano, what do you think?

I think we should only provide the *_guest functions in our port.

The only downside is that the clear_user patch will grow also to
implement clear_guest for ia64 and x86 as well. Nothing difficult, but
more code.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 15:57:20 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 15:57:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaUj8-0002fL-8b; Tue, 13 Dec 2011 15:57:10 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RaUj7-0002f2-JA
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 15:57:09 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1323791774!7293652!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTI1NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11381 invoked from network); 13 Dec 2011 15:56:15 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 15:56:15 -0000
X-IronPort-AV: E=Sophos;i="4.71,346,1320624000"; 
   d="scan'208";a="9445196"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Dec 2011 15:56:14 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 13 Dec 2011 15:56:14 +0000
Date: Tue, 13 Dec 2011 15:57:56 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1323445279.20077.76.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1112131554400.3517@kaball-desktop>
References: <alpine.DEB.2.00.1112091208420.3517@kaball-desktop>
	<1323436408-16335-6-git-send-email-stefano.stabellini@eu.citrix.com>
	<4EE21C4602000078000667AA@nat28.tlf.novell.com>
	<1323438026.20077.51.camel@zakaz.uk.xensource.com> 
	<4EE2335A020000780006688C@nat28.tlf.novell.com>
	<1323444231.20077.72.camel@zakaz.uk.xensource.com>
	<4EE2388702000078000668BF@nat28.tlf.novell.com>
	<1323445279.20077.76.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"keir.xen@gmail.com" <keir.xen@gmail.com>,
	"Tim Deegan \(3P\)" <Tim.Deegan@citrix.com>,
	Jan Beulich <JBeulich@suse.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v2 06/25] libelf-loader: introduce
	elf_load_image
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 9 Dec 2011, Ian Campbell wrote:
> This ARM port has no PV guests so it has no "user" in the sense that
> x86's copy_to_user means, so copy_to_user and copy_to_guest are both the
> same and do things the HVM way.
> 
> Maybe the right thing to do is to not supply copy_to_user on ARM at all.
> I had feared this would be a big bit of string to pull on but it seems
> that copy_to_user isn't actually widely used in common code:
> $ rgrep --binary-files=without-match copy_to_user xen | grep -vE x86\|ia64\|asm
> xen/common/gdbstub.c:        r = gdb_arch_copy_to_user((void*)addr, (void*)&val, 1);
> xen/include/linux/gdbstub.h:unsigned int gdb_arch_copy_to_user(
> xen/include/xen/gdbstub.h:unsigned int gdb_arch_copy_to_user(

We are not compiling gdbstub at the moment.

> Stefano, what do you think?

I think we should only provide the *_guest functions in our port.

The only downside is that the clear_user patch will grow also to
implement clear_guest for ia64 and x86 as well. Nothing difficult, but
more code.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 16:01:51 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 16:01:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaUnV-0003S1-15; Tue, 13 Dec 2011 16:01:41 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <lars.kurth@citrix.com>) id 1RaUnT-0003Rt-TM
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 16:01:40 +0000
X-Env-Sender: lars.kurth@citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1323792044!5222657!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTI1NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17127 invoked from network); 13 Dec 2011 16:00:45 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 16:00:45 -0000
X-IronPort-AV: E=Sophos;i="4.71,346,1320624000"; 
   d="scan'208";a="9445353"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Dec 2011 16:00:44 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.161]) by
	LONPMAILMX01.citrite.net ([10.30.203.162]) with mapi; Tue, 13 Dec 2011
	16:00:44 +0000
From: Lars Kurth <lars.kurth@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>, Sander Eikelenboom
	<linux@eikelenboom.it>
Date: Tue, 13 Dec 2011 16:00:44 +0000
Thread-Topic: [Xen-devel] Security vulnerability process - confirmed
Thread-Index: Acy5r32Z8C3r2BvwR5mb1cBg2suiwQAANi0w
Message-ID: <344C0F67BC927847A2C92F9EE358DB0EBAFAC50C17@LONPMAILBOX01.citrite.net>
References: <20198.11738.646611.204591@mariner.uk.xensource.com>
	<707238508.20111212194525@eikelenboom.it>
	<20199.30000.105401.697750@mariner.uk.xensource.com>
In-Reply-To: <20199.30000.105401.697750@mariner.uk.xensource.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"security@xen.org" <security@xen.org>
Subject: Re: [Xen-devel] Security vulnerability process - confirmed
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

I can do this, if nobody objects
Lars

-----Original Message-----
From: Ian Jackson [mailto:Ian.Jackson@eu.citrix.com] 
Sent: 13 December 2011 15:54
To: Sander Eikelenboom
Cc: security@xen.org; Lars Kurth; xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Security vulnerability process - confirmed

Sander Eikelenboom writes ("Re: [Xen-devel] Security vulnerability process - confirmed"):
> Monday, December 12, 2011, 5:37:46 PM, you wrote:
> >    Public advisories will be posted to xen-devel.
...> 
> >    Copies will also be sent to the pre-disclosure list, unless
> >    the advisory was already sent there previously during the embargo
> >    period and has not been updated since.
> 
> shouldn't this include at least xen-users and xen-announce,

I think the Xen.org security team will be happy to send the messages
to a wider audience.  Lars, can you change this to say:

   Public advisories will be posted to xen-devel, xen-users and
   xen-annnounce.

?

> and perhaps a special read only list for security advisories ?

I think xen-announce will probably do.  It's very low traffic.

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 16:01:51 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 16:01:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaUnV-0003S1-15; Tue, 13 Dec 2011 16:01:41 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <lars.kurth@citrix.com>) id 1RaUnT-0003Rt-TM
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 16:01:40 +0000
X-Env-Sender: lars.kurth@citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1323792044!5222657!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTI1NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17127 invoked from network); 13 Dec 2011 16:00:45 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 16:00:45 -0000
X-IronPort-AV: E=Sophos;i="4.71,346,1320624000"; 
   d="scan'208";a="9445353"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Dec 2011 16:00:44 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.161]) by
	LONPMAILMX01.citrite.net ([10.30.203.162]) with mapi; Tue, 13 Dec 2011
	16:00:44 +0000
From: Lars Kurth <lars.kurth@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>, Sander Eikelenboom
	<linux@eikelenboom.it>
Date: Tue, 13 Dec 2011 16:00:44 +0000
Thread-Topic: [Xen-devel] Security vulnerability process - confirmed
Thread-Index: Acy5r32Z8C3r2BvwR5mb1cBg2suiwQAANi0w
Message-ID: <344C0F67BC927847A2C92F9EE358DB0EBAFAC50C17@LONPMAILBOX01.citrite.net>
References: <20198.11738.646611.204591@mariner.uk.xensource.com>
	<707238508.20111212194525@eikelenboom.it>
	<20199.30000.105401.697750@mariner.uk.xensource.com>
In-Reply-To: <20199.30000.105401.697750@mariner.uk.xensource.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"security@xen.org" <security@xen.org>
Subject: Re: [Xen-devel] Security vulnerability process - confirmed
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

I can do this, if nobody objects
Lars

-----Original Message-----
From: Ian Jackson [mailto:Ian.Jackson@eu.citrix.com] 
Sent: 13 December 2011 15:54
To: Sander Eikelenboom
Cc: security@xen.org; Lars Kurth; xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Security vulnerability process - confirmed

Sander Eikelenboom writes ("Re: [Xen-devel] Security vulnerability process - confirmed"):
> Monday, December 12, 2011, 5:37:46 PM, you wrote:
> >    Public advisories will be posted to xen-devel.
...> 
> >    Copies will also be sent to the pre-disclosure list, unless
> >    the advisory was already sent there previously during the embargo
> >    period and has not been updated since.
> 
> shouldn't this include at least xen-users and xen-announce,

I think the Xen.org security team will be happy to send the messages
to a wider audience.  Lars, can you change this to say:

   Public advisories will be posted to xen-devel, xen-users and
   xen-annnounce.

?

> and perhaps a special read only list for security advisories ?

I think xen-announce will probably do.  It's very low traffic.

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 16:03:53 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 16:03:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaUpS-0003Xv-Hs; Tue, 13 Dec 2011 16:03:42 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RaUpR-0003XY-DU
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 16:03:41 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1323792166!7105954!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTI1NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13109 invoked from network); 13 Dec 2011 16:02:47 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 16:02:47 -0000
X-IronPort-AV: E=Sophos;i="4.71,346,1320624000"; 
   d="scan'208";a="9445404"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Dec 2011 16:02:32 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 13 Dec 2011 16:02:32 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RaUoH-0007bY-42;
	Tue, 13 Dec 2011 16:02:29 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RaUoG-0007wC-RZ;
	Tue, 13 Dec 2011 16:02:28 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10489-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 13 Dec 2011 16:02:28 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10489: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10489 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10489/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install          fail like 10480
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   never pass
 test-amd64-i386-xend-winxpsp3  7 windows-install              fail  like 10480
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  3b563fbde6e0
baseline version:
 xen                  7ca56cca09ad

------------------------------------------------------------
People who touched revisions under test:
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-unstable
+ revision=3b563fbde6e0
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-unstable 3b563fbde6e0
+ branch=xen-unstable
+ revision=3b563fbde6e0
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ : xen@xenbits.xensource.com
+ : xen@xenbits.xensource.com:git/linux-pvops
+ : master
+ : tested/2.6.39.x
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r 3b563fbde6e0 ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 10 changesets with 50 changes to 45 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 16:03:53 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 16:03:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaUpS-0003Xv-Hs; Tue, 13 Dec 2011 16:03:42 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RaUpR-0003XY-DU
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 16:03:41 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1323792166!7105954!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTI1NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13109 invoked from network); 13 Dec 2011 16:02:47 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 16:02:47 -0000
X-IronPort-AV: E=Sophos;i="4.71,346,1320624000"; 
   d="scan'208";a="9445404"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Dec 2011 16:02:32 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 13 Dec 2011 16:02:32 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RaUoH-0007bY-42;
	Tue, 13 Dec 2011 16:02:29 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RaUoG-0007wC-RZ;
	Tue, 13 Dec 2011 16:02:28 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10489-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 13 Dec 2011 16:02:28 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10489: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10489 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10489/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install          fail like 10480
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   never pass
 test-amd64-i386-xend-winxpsp3  7 windows-install              fail  like 10480
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  3b563fbde6e0
baseline version:
 xen                  7ca56cca09ad

------------------------------------------------------------
People who touched revisions under test:
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-unstable
+ revision=3b563fbde6e0
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-unstable 3b563fbde6e0
+ branch=xen-unstable
+ revision=3b563fbde6e0
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ : xen@xenbits.xensource.com
+ : xen@xenbits.xensource.com:git/linux-pvops
+ : master
+ : tested/2.6.39.x
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r 3b563fbde6e0 ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 10 changesets with 50 changes to 45 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 16:05:05 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 16:05:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaUqc-0003dR-1M; Tue, 13 Dec 2011 16:04:54 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RaUqZ-0003cl-TN
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 16:04:52 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1323792237!7312505!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTI1NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10833 invoked from network); 13 Dec 2011 16:03:57 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 16:03:57 -0000
X-IronPort-AV: E=Sophos;i="4.71,346,1320624000"; 
   d="scan'208";a="9445455"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Dec 2011 16:03:57 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 13 Dec 2011 16:03:57 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 13 Dec 2011 16:03:57 +0000
In-Reply-To: <20199.29882.675830.388738@mariner.uk.xensource.com>
References: <patchbomb.1323448640@cosworth.uk.xensource.com>
	<74f94e15bfe1dad412d0.1323448643@cosworth.uk.xensource.com>
	<20199.29882.675830.388738@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323792237.20077.340.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Olaf Hering <olaf@aepfle.de>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Vincent Hanquez <Vincent.Hanquez@eu.citrix.com>,
	Jonathan Ludlam <Jonathan.Ludlam@eu.citrix.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH 3 of 4] oxenstored: handle unknown
 operations by returning an error to the client
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2011-12-13 at 15:52 +0000, Ian Jackson wrote:
> Ian Campbell writes ("[Xen-devel] [PATCH 3 of 4] oxenstored: handle unknown operations by returning an error to the client"):
> > oxenstored: handle unknown operations by returning an error to the client
> 
> This introduces a new warning:
> 
>   File "logging.ml", line 157, characters 14-1067:
>   Warning P: this pattern-matching is not exhaustive.
>   Here is an example of a value that is not matched:
>   Invalid

Sorry, will fix and resend.

> I have applied 1/4 and 2/4.

Did you see "5/4" and "6/4"? In any case I shall include them in my
resend.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 16:05:05 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 16:05:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaUqc-0003dR-1M; Tue, 13 Dec 2011 16:04:54 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RaUqZ-0003cl-TN
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 16:04:52 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1323792237!7312505!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTI1NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10833 invoked from network); 13 Dec 2011 16:03:57 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 16:03:57 -0000
X-IronPort-AV: E=Sophos;i="4.71,346,1320624000"; 
   d="scan'208";a="9445455"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Dec 2011 16:03:57 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 13 Dec 2011 16:03:57 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 13 Dec 2011 16:03:57 +0000
In-Reply-To: <20199.29882.675830.388738@mariner.uk.xensource.com>
References: <patchbomb.1323448640@cosworth.uk.xensource.com>
	<74f94e15bfe1dad412d0.1323448643@cosworth.uk.xensource.com>
	<20199.29882.675830.388738@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323792237.20077.340.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Olaf Hering <olaf@aepfle.de>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Vincent Hanquez <Vincent.Hanquez@eu.citrix.com>,
	Jonathan Ludlam <Jonathan.Ludlam@eu.citrix.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH 3 of 4] oxenstored: handle unknown
 operations by returning an error to the client
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2011-12-13 at 15:52 +0000, Ian Jackson wrote:
> Ian Campbell writes ("[Xen-devel] [PATCH 3 of 4] oxenstored: handle unknown operations by returning an error to the client"):
> > oxenstored: handle unknown operations by returning an error to the client
> 
> This introduces a new warning:
> 
>   File "logging.ml", line 157, characters 14-1067:
>   Warning P: this pattern-matching is not exhaustive.
>   Here is an example of a value that is not matched:
>   Invalid

Sorry, will fix and resend.

> I have applied 1/4 and 2/4.

Did you see "5/4" and "6/4"? In any case I shall include them in my
resend.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 16:06:12 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 16:06:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaUrf-0003lV-Mz; Tue, 13 Dec 2011 16:05:59 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RaUre-0003ko-Ck
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 16:05:58 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1323792303!7961032!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTI1NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19357 invoked from network); 13 Dec 2011 16:05:04 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 16:05:04 -0000
X-IronPort-AV: E=Sophos;i="4.71,346,1320624000"; 
   d="scan'208";a="9445481"
Received: from lonpmailmx02.citrite.net ([10.30.203.163])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Dec 2011 16:05:03 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.161]) by
	LONPMAILMX02.citrite.net ([10.30.203.163]) with mapi; Tue, 13 Dec 2011
	16:05:03 +0000
From: Paul Durrant <Paul.Durrant@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 13 Dec 2011 16:05:23 +0000
Thread-Topic: [Xen-devel] [PATCH] VM generation ID save/restore and migrate
Thread-Index: Acy5rjTdGN1eUXfDSYO4Uf+czDC46QAAoTdA
Message-ID: <291EDFCB1E9E224A99088639C4762022B5988E580F@LONPMAILBOX01.citrite.net>
References: <9eaac880f504a12c145d.1323250728@cosworth.uk.xensource.com>
	<20199.29450.340394.886899@mariner.uk.xensource.com>
In-Reply-To: <20199.29450.340394.886899@mariner.uk.xensource.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] VM generation ID save/restore and migrate
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> -----Original Message-----
> From: Ian Jackson [mailto:Ian.Jackson@eu.citrix.com]
> Sent: 13 December 2011 15:45
> To: Paul Durrant
> Cc: xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] [PATCH] VM generation ID save/restore and
> migrate
> 
> Paul Durrant writes ("[Xen-devel] [PATCH] VM generation ID
> save/restore and migrate"):
> > VM generation ID save/restore and migrate.
> >
> > Add code to track the address of the VM generation id buffer
> across a
> > save/restore or migrate and increment it as necessary.
> > The address of the buffer is written into xenstore by hvmloader at
> > boot time. It must be read from xenstore by the caller of
> > xc_domain_save() and then written back again by the caller of
> > xc_domain_restore().
> ...
> > +        if ( RDEXACT(fd, &buf->vm_gid_addr, sizeof(uint32_t)) ||
> > +             RDEXACT(fd, &buf->vm_gid_addr, sizeof(uint64_t)) )
> 
> I'm generally OK with this, but I have two comments.  Firstly
> "vm_gid_addr" etc. is a bit opaque and there might be lots of things
> called a "g identifier".
> 
> Perhaps we could call these variables
>   vm_generationid_addr
> or something ?
> 

If you're happy that's not too long, I'll go with that.

> > +    ents[12] = "data/generation-id";
> 
> And this xenstore key suggests that the value is the id, not the
> address.  I think it should be renamed.
> 

Ok. I'll need to patch hvmloader again then. I'll prepend a patch this one to change the name.

  Paul

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 16:06:12 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 16:06:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaUrf-0003lV-Mz; Tue, 13 Dec 2011 16:05:59 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RaUre-0003ko-Ck
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 16:05:58 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1323792303!7961032!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTI1NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19357 invoked from network); 13 Dec 2011 16:05:04 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 16:05:04 -0000
X-IronPort-AV: E=Sophos;i="4.71,346,1320624000"; 
   d="scan'208";a="9445481"
Received: from lonpmailmx02.citrite.net ([10.30.203.163])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Dec 2011 16:05:03 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.161]) by
	LONPMAILMX02.citrite.net ([10.30.203.163]) with mapi; Tue, 13 Dec 2011
	16:05:03 +0000
From: Paul Durrant <Paul.Durrant@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 13 Dec 2011 16:05:23 +0000
Thread-Topic: [Xen-devel] [PATCH] VM generation ID save/restore and migrate
Thread-Index: Acy5rjTdGN1eUXfDSYO4Uf+czDC46QAAoTdA
Message-ID: <291EDFCB1E9E224A99088639C4762022B5988E580F@LONPMAILBOX01.citrite.net>
References: <9eaac880f504a12c145d.1323250728@cosworth.uk.xensource.com>
	<20199.29450.340394.886899@mariner.uk.xensource.com>
In-Reply-To: <20199.29450.340394.886899@mariner.uk.xensource.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] VM generation ID save/restore and migrate
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> -----Original Message-----
> From: Ian Jackson [mailto:Ian.Jackson@eu.citrix.com]
> Sent: 13 December 2011 15:45
> To: Paul Durrant
> Cc: xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] [PATCH] VM generation ID save/restore and
> migrate
> 
> Paul Durrant writes ("[Xen-devel] [PATCH] VM generation ID
> save/restore and migrate"):
> > VM generation ID save/restore and migrate.
> >
> > Add code to track the address of the VM generation id buffer
> across a
> > save/restore or migrate and increment it as necessary.
> > The address of the buffer is written into xenstore by hvmloader at
> > boot time. It must be read from xenstore by the caller of
> > xc_domain_save() and then written back again by the caller of
> > xc_domain_restore().
> ...
> > +        if ( RDEXACT(fd, &buf->vm_gid_addr, sizeof(uint32_t)) ||
> > +             RDEXACT(fd, &buf->vm_gid_addr, sizeof(uint64_t)) )
> 
> I'm generally OK with this, but I have two comments.  Firstly
> "vm_gid_addr" etc. is a bit opaque and there might be lots of things
> called a "g identifier".
> 
> Perhaps we could call these variables
>   vm_generationid_addr
> or something ?
> 

If you're happy that's not too long, I'll go with that.

> > +    ents[12] = "data/generation-id";
> 
> And this xenstore key suggests that the value is the id, not the
> address.  I think it should be renamed.
> 

Ok. I'll need to patch hvmloader again then. I'll prepend a patch this one to change the name.

  Paul

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 16:14:09 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 16: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.xensource.com>)
	id 1RaUzM-0004RU-VV; Tue, 13 Dec 2011 16:13:56 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RaUzL-0004RN-Lr
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 16:13:55 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1323792755!44704502!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDUzNzY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 791 invoked from network); 13 Dec 2011 16:12:36 -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;
	13 Dec 2011 16:12:36 -0000
X-IronPort-AV: E=Sophos;i="4.71,346,1320642000"; d="scan'208";a="19923712"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Dec 2011 11:13:04 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Tue, 13 Dec 2011 11:13:04 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pBDGD0pT028078;	Tue, 13 Dec 2011 08:13:02 -0800
MIME-Version: 1.0
X-Mercurial-Node: 06c6ba6641640a2fa0ef6f998405f5f7c43bb258
Message-ID: <06c6ba6641640a2fa0ef.1323792780@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1323792779@cosworth.uk.xensource.com>
References: <patchbomb.1323792779@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Tue, 13 Dec 2011 16:13:00 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com, Olaf Hering <olaf@aepfle.de>,
	Vincent Hanquez <Vincent.Hanquez@eu.citrix.com>,
	Jonathan Ludlam <Jonathan.Ludlam@eu.citrix.com>, konrad.wilk@oracle.com
Subject: [Xen-devel] [PATCH 1 of 4 V2] oxenstored: handle unknown operations
 by returning an error to the client
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1323792488 0
# Node ID 06c6ba6641640a2fa0ef6f998405f5f7c43bb258
# Parent  74ab4d0c8ebac8d9d344dab3bf440f510d23377d
oxenstored: handle unknown operations by returning an error to the client

Previous an unknown operation would be decoded as a Not_found exception which
would bubble all the way up to the try ... with surrounding the call to
main_loop where it would be logged and ignored.

This would leave the guest hanging waiting for a response to the invalid
request.

Instead introduce a specific "Invalid" operation. Higher level functionality,
such as Process.process_packet, already handles operations which are not
understood with an error reply due to the final wildcard entry in
Process.function_of_type but explicitly handle Invalid this way to make it
clear what is going on.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 74ab4d0c8eba -r 06c6ba664164 tools/ocaml/libs/xb/op.ml
--- a/tools/ocaml/libs/xb/op.ml	Tue Dec 13 16:07:40 2011 +0000
+++ b/tools/ocaml/libs/xb/op.ml	Tue Dec 13 16:08:08 2011 +0000
@@ -19,8 +19,7 @@ type operation = Debug | Directory | Rea
                  Transaction_end | Introduce | Release |
                  Getdomainpath | Write | Mkdir | Rm |
                  Setperms | Watchevent | Error | Isintroduced |
-                 Resume | Set_target
-               | Restrict 
+                 Resume | Set_target | Restrict | Invalid
 
 let operation_c_mapping =
 	[| Debug; Directory; Read; Getperms;
@@ -41,7 +40,7 @@ let array_search el a =
 let of_cval i =
 	if i >= 0 && i < size
 	then operation_c_mapping.(i)
-	else raise Not_found
+	else Invalid
 
 let to_cval op =
 	array_search op operation_c_mapping
@@ -69,3 +68,4 @@ let to_string ty =
 	| Resume		-> "RESUME"
 	| Set_target		-> "SET_TARGET"
 	| Restrict		-> "RESTRICT"
+	| Invalid		-> "INVALID"
diff -r 74ab4d0c8eba -r 06c6ba664164 tools/ocaml/libs/xb/xb.mli
--- a/tools/ocaml/libs/xb/xb.mli	Tue Dec 13 16:07:40 2011 +0000
+++ b/tools/ocaml/libs/xb/xb.mli	Tue Dec 13 16:08:08 2011 +0000
@@ -23,6 +23,7 @@ module Op :
       | Resume
       | Set_target
       | Restrict
+      | Invalid (* Not a valid wire operation *)
     val operation_c_mapping : operation array
     val size : int
     val array_search : 'a -> 'a array -> int
diff -r 74ab4d0c8eba -r 06c6ba664164 tools/ocaml/xenstored/logging.ml
--- a/tools/ocaml/xenstored/logging.ml	Tue Dec 13 16:07:40 2011 +0000
+++ b/tools/ocaml/xenstored/logging.ml	Tue Dec 13 16:08:08 2011 +0000
@@ -182,6 +182,7 @@ let string_of_access_type = function
 
 	| Xenbus.Xb.Op.Error             -> "error    "
 	| Xenbus.Xb.Op.Watchevent        -> "w event  "
+	| Xenbus.Xb.Op.Invalid           -> "invalid  "
 	(*
 	| x                       -> Xenbus.Xb.Op.to_string x
 	*)
diff -r 74ab4d0c8eba -r 06c6ba664164 tools/ocaml/xenstored/process.ml
--- a/tools/ocaml/xenstored/process.ml	Tue Dec 13 16:07:40 2011 +0000
+++ b/tools/ocaml/xenstored/process.ml	Tue Dec 13 16:08:08 2011 +0000
@@ -324,7 +324,8 @@ let function_of_type ty =
 	| Xenbus.Xb.Op.Resume            -> reply_ack do_resume
 	| Xenbus.Xb.Op.Set_target        -> reply_ack do_set_target
 	| Xenbus.Xb.Op.Restrict          -> reply_ack do_restrict
-	| _                       -> reply_ack do_error
+	| Xenbus.Xb.Op.Invalid           -> reply_ack do_error
+	| _                              -> reply_ack do_error
 
 let input_handle_error ~cons ~doms ~fct ~ty ~con ~t ~rid ~data =
 	let reply_error e =
diff -r 74ab4d0c8eba -r 06c6ba664164 tools/ocaml/xenstored/xenstored.ml
--- a/tools/ocaml/xenstored/xenstored.ml	Tue Dec 13 16:07:40 2011 +0000
+++ b/tools/ocaml/xenstored/xenstored.ml	Tue Dec 13 16:08:08 2011 +0000
@@ -43,9 +43,7 @@ let process_connection_fds store cons do
 			debug "closing socket connection"
 		in
 	let process_fdset_with fds fct =
-		List.iter (fun fd ->
-		           try try_fct fct (Connections.find cons fd)
-		           with Not_found -> ()) fds
+		List.iter (fun fd -> try_fct fct (Connections.find cons fd)) fds
 	in
 	process_fdset_with rset Process.do_input;
 	process_fdset_with wset Process.do_output

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 16:14:09 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 16: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.xensource.com>)
	id 1RaUzM-0004RU-VV; Tue, 13 Dec 2011 16:13:56 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RaUzL-0004RN-Lr
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 16:13:55 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1323792755!44704502!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDUzNzY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 791 invoked from network); 13 Dec 2011 16:12:36 -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;
	13 Dec 2011 16:12:36 -0000
X-IronPort-AV: E=Sophos;i="4.71,346,1320642000"; d="scan'208";a="19923712"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Dec 2011 11:13:04 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Tue, 13 Dec 2011 11:13:04 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pBDGD0pT028078;	Tue, 13 Dec 2011 08:13:02 -0800
MIME-Version: 1.0
X-Mercurial-Node: 06c6ba6641640a2fa0ef6f998405f5f7c43bb258
Message-ID: <06c6ba6641640a2fa0ef.1323792780@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1323792779@cosworth.uk.xensource.com>
References: <patchbomb.1323792779@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Tue, 13 Dec 2011 16:13:00 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com, Olaf Hering <olaf@aepfle.de>,
	Vincent Hanquez <Vincent.Hanquez@eu.citrix.com>,
	Jonathan Ludlam <Jonathan.Ludlam@eu.citrix.com>, konrad.wilk@oracle.com
Subject: [Xen-devel] [PATCH 1 of 4 V2] oxenstored: handle unknown operations
 by returning an error to the client
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1323792488 0
# Node ID 06c6ba6641640a2fa0ef6f998405f5f7c43bb258
# Parent  74ab4d0c8ebac8d9d344dab3bf440f510d23377d
oxenstored: handle unknown operations by returning an error to the client

Previous an unknown operation would be decoded as a Not_found exception which
would bubble all the way up to the try ... with surrounding the call to
main_loop where it would be logged and ignored.

This would leave the guest hanging waiting for a response to the invalid
request.

Instead introduce a specific "Invalid" operation. Higher level functionality,
such as Process.process_packet, already handles operations which are not
understood with an error reply due to the final wildcard entry in
Process.function_of_type but explicitly handle Invalid this way to make it
clear what is going on.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 74ab4d0c8eba -r 06c6ba664164 tools/ocaml/libs/xb/op.ml
--- a/tools/ocaml/libs/xb/op.ml	Tue Dec 13 16:07:40 2011 +0000
+++ b/tools/ocaml/libs/xb/op.ml	Tue Dec 13 16:08:08 2011 +0000
@@ -19,8 +19,7 @@ type operation = Debug | Directory | Rea
                  Transaction_end | Introduce | Release |
                  Getdomainpath | Write | Mkdir | Rm |
                  Setperms | Watchevent | Error | Isintroduced |
-                 Resume | Set_target
-               | Restrict 
+                 Resume | Set_target | Restrict | Invalid
 
 let operation_c_mapping =
 	[| Debug; Directory; Read; Getperms;
@@ -41,7 +40,7 @@ let array_search el a =
 let of_cval i =
 	if i >= 0 && i < size
 	then operation_c_mapping.(i)
-	else raise Not_found
+	else Invalid
 
 let to_cval op =
 	array_search op operation_c_mapping
@@ -69,3 +68,4 @@ let to_string ty =
 	| Resume		-> "RESUME"
 	| Set_target		-> "SET_TARGET"
 	| Restrict		-> "RESTRICT"
+	| Invalid		-> "INVALID"
diff -r 74ab4d0c8eba -r 06c6ba664164 tools/ocaml/libs/xb/xb.mli
--- a/tools/ocaml/libs/xb/xb.mli	Tue Dec 13 16:07:40 2011 +0000
+++ b/tools/ocaml/libs/xb/xb.mli	Tue Dec 13 16:08:08 2011 +0000
@@ -23,6 +23,7 @@ module Op :
       | Resume
       | Set_target
       | Restrict
+      | Invalid (* Not a valid wire operation *)
     val operation_c_mapping : operation array
     val size : int
     val array_search : 'a -> 'a array -> int
diff -r 74ab4d0c8eba -r 06c6ba664164 tools/ocaml/xenstored/logging.ml
--- a/tools/ocaml/xenstored/logging.ml	Tue Dec 13 16:07:40 2011 +0000
+++ b/tools/ocaml/xenstored/logging.ml	Tue Dec 13 16:08:08 2011 +0000
@@ -182,6 +182,7 @@ let string_of_access_type = function
 
 	| Xenbus.Xb.Op.Error             -> "error    "
 	| Xenbus.Xb.Op.Watchevent        -> "w event  "
+	| Xenbus.Xb.Op.Invalid           -> "invalid  "
 	(*
 	| x                       -> Xenbus.Xb.Op.to_string x
 	*)
diff -r 74ab4d0c8eba -r 06c6ba664164 tools/ocaml/xenstored/process.ml
--- a/tools/ocaml/xenstored/process.ml	Tue Dec 13 16:07:40 2011 +0000
+++ b/tools/ocaml/xenstored/process.ml	Tue Dec 13 16:08:08 2011 +0000
@@ -324,7 +324,8 @@ let function_of_type ty =
 	| Xenbus.Xb.Op.Resume            -> reply_ack do_resume
 	| Xenbus.Xb.Op.Set_target        -> reply_ack do_set_target
 	| Xenbus.Xb.Op.Restrict          -> reply_ack do_restrict
-	| _                       -> reply_ack do_error
+	| Xenbus.Xb.Op.Invalid           -> reply_ack do_error
+	| _                              -> reply_ack do_error
 
 let input_handle_error ~cons ~doms ~fct ~ty ~con ~t ~rid ~data =
 	let reply_error e =
diff -r 74ab4d0c8eba -r 06c6ba664164 tools/ocaml/xenstored/xenstored.ml
--- a/tools/ocaml/xenstored/xenstored.ml	Tue Dec 13 16:07:40 2011 +0000
+++ b/tools/ocaml/xenstored/xenstored.ml	Tue Dec 13 16:08:08 2011 +0000
@@ -43,9 +43,7 @@ let process_connection_fds store cons do
 			debug "closing socket connection"
 		in
 	let process_fdset_with fds fct =
-		List.iter (fun fd ->
-		           try try_fct fct (Connections.find cons fd)
-		           with Not_found -> ()) fds
+		List.iter (fun fd -> try_fct fct (Connections.find cons fd)) fds
 	in
 	process_fdset_with rset Process.do_input;
 	process_fdset_with wset Process.do_output

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 16:14:10 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 16:14:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaUzQ-0004Ro-Bk; Tue, 13 Dec 2011 16:14:00 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RaUzO-0004RM-RQ
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 16:13:59 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1323792783!7287705!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjAzMzQ=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28546 invoked from network); 13 Dec 2011 16:13:04 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 16:13:04 -0000
X-IronPort-AV: E=Sophos;i="4.71,346,1320642000"; d="scan'208";a="173967223"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Dec 2011 11:13:03 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Tue, 13 Dec 2011 11:13:02 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pBDGD0pS028078;	Tue, 13 Dec 2011 08:13:00 -0800
MIME-Version: 1.0
Message-ID: <patchbomb.1323792779@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Tue, 13 Dec 2011 16:12:59 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com, Olaf Hering <olaf@aepfle.de>,
	Vincent Hanquez <Vincent.Hanquez@eu.citrix.com>,
	Jonathan Ludlam <Jonathan.Ludlam@eu.citrix.com>, konrad.wilk@oracle.com
Subject: [Xen-devel] [PATCH 0 of 4 V2] oxenstored fixes -- fixes recent
	pvops kernel hang
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Currently PVHVM Linux guests after ddacf5ef684a "xen/pv-on-hvm kexec:
add xs_reset_watches to shutdown watches from old kernel" hang when
run against oxenstored because it does not handle the unknown
XS_RESET_WATCHES operation and does not reply.

The symptom of this issue is a hang during boot at this point:
    cpu 1 spinlock event irq 70
    CPU 1 irqstacks, hard=dec94000 soft=dec96000
    Booting Node   0, Processors  #1
    smpboot cpu 1: start_ip = 99000
    Initializing CPU#1
    installing Xen timer for CPU 1
    Brought up 2 CPUs
    Total of 2 processors activated (9625.99 BogoMIPS).
    NET: Registered protocol family 16
    <HANG>

This series makes oxenstored handle unknown operations by returning an
error indicating that the operation is unknown. I have not actually
implemented support for XS_RESET_WATCHES.

I also include a patch which I've been using for some time to enable
the use of oxenstored in preference to C xenstored when available.

Also included are two (more) little cleanup patches

Changes since v1: 

* First two cleanup patches applied already
* Two more cleanup patches added
* Fixed warning in "handle unknown operations by returning an error to
  the client"

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 16:14:10 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 16:14:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaUzQ-0004Ro-Bk; Tue, 13 Dec 2011 16:14:00 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RaUzO-0004RM-RQ
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 16:13:59 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1323792783!7287705!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjAzMzQ=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28546 invoked from network); 13 Dec 2011 16:13:04 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 16:13:04 -0000
X-IronPort-AV: E=Sophos;i="4.71,346,1320642000"; d="scan'208";a="173967223"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Dec 2011 11:13:03 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Tue, 13 Dec 2011 11:13:02 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pBDGD0pS028078;	Tue, 13 Dec 2011 08:13:00 -0800
MIME-Version: 1.0
Message-ID: <patchbomb.1323792779@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Tue, 13 Dec 2011 16:12:59 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com, Olaf Hering <olaf@aepfle.de>,
	Vincent Hanquez <Vincent.Hanquez@eu.citrix.com>,
	Jonathan Ludlam <Jonathan.Ludlam@eu.citrix.com>, konrad.wilk@oracle.com
Subject: [Xen-devel] [PATCH 0 of 4 V2] oxenstored fixes -- fixes recent
	pvops kernel hang
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Currently PVHVM Linux guests after ddacf5ef684a "xen/pv-on-hvm kexec:
add xs_reset_watches to shutdown watches from old kernel" hang when
run against oxenstored because it does not handle the unknown
XS_RESET_WATCHES operation and does not reply.

The symptom of this issue is a hang during boot at this point:
    cpu 1 spinlock event irq 70
    CPU 1 irqstacks, hard=dec94000 soft=dec96000
    Booting Node   0, Processors  #1
    smpboot cpu 1: start_ip = 99000
    Initializing CPU#1
    installing Xen timer for CPU 1
    Brought up 2 CPUs
    Total of 2 processors activated (9625.99 BogoMIPS).
    NET: Registered protocol family 16
    <HANG>

This series makes oxenstored handle unknown operations by returning an
error indicating that the operation is unknown. I have not actually
implemented support for XS_RESET_WATCHES.

I also include a patch which I've been using for some time to enable
the use of oxenstored in preference to C xenstored when available.

Also included are two (more) little cleanup patches

Changes since v1: 

* First two cleanup patches applied already
* Two more cleanup patches added
* Fixed warning in "handle unknown operations by returning an error to
  the client"

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 16:14:11 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 16: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.xensource.com>)
	id 1RaUzU-0004Sh-70; Tue, 13 Dec 2011 16:14:04 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RaUzS-0004RT-9P
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 16:14:02 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1323792783!7287705!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjAzMzQ=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28693 invoked from network); 13 Dec 2011 16:13:07 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 16:13:07 -0000
X-IronPort-AV: E=Sophos;i="4.71,346,1320642000"; d="scan'208";a="173967242"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Dec 2011 11:13:07 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Tue, 13 Dec 2011 11:13:07 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pBDGD0pV028078;	Tue, 13 Dec 2011 08:13:05 -0800
MIME-Version: 1.0
X-Mercurial-Node: fd321c47d4b8e7095758e008ad3801e5d16461a7
Message-ID: <fd321c47d4b8e7095758.1323792782@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1323792779@cosworth.uk.xensource.com>
References: <patchbomb.1323792779@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Tue, 13 Dec 2011 16:13:02 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com, Olaf Hering <olaf@aepfle.de>,
	Vincent Hanquez <Vincent.Hanquez@eu.citrix.com>,
	Jonathan Ludlam <Jonathan.Ludlam@eu.citrix.com>, konrad.wilk@oracle.com
Subject: [Xen-devel] [PATCH 3 of 4 V2] oxenstored: install configuration file
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1323792537 0
# Node ID fd321c47d4b8e7095758e008ad3801e5d16461a7
# Parent  f4586d1a539c869e31fadc8b3c3223bd118b37fc
oxenstored: install configuration file

First though:
  - Move it to /etc/xen/oxenstored.conf.
  - Use /var/run/xenstored.pid as default pid file
  - Disable test-eagain "Randomly failed a transaction with EAGAIN. Used for
    testing Xs user". Doesn't sound fun by default...

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r f4586d1a539c -r fd321c47d4b8 tools/ocaml/xenstored/Makefile
--- a/tools/ocaml/xenstored/Makefile	Tue Dec 13 16:08:27 2011 +0000
+++ b/tools/ocaml/xenstored/Makefile	Tue Dec 13 16:08:57 2011 +0000
@@ -52,5 +52,7 @@ bins: $(PROGRAMS)
 install: all
 	$(INSTALL_DIR) $(DESTDIR)$(SBINDIR)
 	$(INSTALL_PROG) oxenstored $(DESTDIR)$(SBINDIR)
+	$(INSTALL_DIR) $(DESTDIR)$(XEN_CONFIG_DIR)
+	$(INSTALL_DATA) oxenstored.conf $(DESTDIR)$(XEN_CONFIG_DIR)
 
 include $(OCAML_TOPLEVEL)/Makefile.rules
diff -r f4586d1a539c -r fd321c47d4b8 tools/ocaml/xenstored/define.ml
--- a/tools/ocaml/xenstored/define.ml	Tue Dec 13 16:08:27 2011 +0000
+++ b/tools/ocaml/xenstored/define.ml	Tue Dec 13 16:08:57 2011 +0000
@@ -23,7 +23,7 @@ let xenstored_proc_port = "/proc/xen/xsd
 let xs_daemon_socket = "/var/run/xenstored/socket"
 let xs_daemon_socket_ro = "/var/run/xenstored/socket_ro"
 
-let default_config_dir = "/etc/xensource"
+let default_config_dir = "/etc/xen"
 
 let maxwatch = ref (50)
 let maxtransaction = ref (20)
diff -r f4586d1a539c -r fd321c47d4b8 tools/ocaml/xenstored/oxenstored.conf
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/tools/ocaml/xenstored/oxenstored.conf	Tue Dec 13 16:08:57 2011 +0000
@@ -0,0 +1,35 @@
+# default xenstored config
+
+# Where the pid file is stored
+pid-file = /var/run/xenstored.pid
+
+# Randomly failed a transaction with EAGAIN. Used for testing Xs user
+test-eagain = false
+
+# Activate transaction merge support
+merge-activate = true
+
+# Activate node permission system
+perms-activate = true
+
+# Activate quota
+quota-activate = true
+quota-maxentity = 1000
+quota-maxsize = 2048
+quota-maxwatch = 100
+quota-transaction = 10
+
+# Activate filed base backend
+persistant = false
+
+# Xenstored logs
+# xenstored-log-file = /var/log/xenstored.log
+# xenstored-log-level = null
+# xenstored-log-nb-files = 10
+
+# Xenstored access logs
+# access-log-file = /var/log/xenstored-access.log
+# access-log-nb-lines = 13215
+# acesss-log-nb-chars = 180
+# access-log-special-ops = false
+
diff -r f4586d1a539c -r fd321c47d4b8 tools/ocaml/xenstored/xenstored.conf
--- a/tools/ocaml/xenstored/xenstored.conf	Tue Dec 13 16:08:27 2011 +0000
+++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
@@ -1,35 +0,0 @@
-# default xenstored config
-
-# Where the pid file is stored
-pid-file = /var/run/xensource/xenstored.pid
-
-# Randomly failed a transaction with EAGAIN. Used for testing Xs user
-test-eagain = true
-
-# Activate transaction merge support
-merge-activate = true
-
-# Activate node permission system
-perms-activate = true
-
-# Activate quota
-quota-activate = true
-quota-maxentity = 1000
-quota-maxsize = 2048
-quota-maxwatch = 100
-quota-transaction = 10
-
-# Activate filed base backend
-persistant = false
-
-# Xenstored logs
-# xenstored-log-file = /var/log/xenstored.log
-# xenstored-log-level = null
-# xenstored-log-nb-files = 10
-
-# Xenstored access logs
-# access-log-file = /var/log/xenstored-access.log
-# access-log-nb-lines = 13215
-# acesss-log-nb-chars = 180
-# access-log-special-ops = false
-
diff -r f4586d1a539c -r fd321c47d4b8 tools/ocaml/xenstored/xenstored.ml
--- a/tools/ocaml/xenstored/xenstored.ml	Tue Dec 13 16:08:27 2011 +0000
+++ b/tools/ocaml/xenstored/xenstored.ml	Tue Dec 13 16:08:57 2011 +0000
@@ -71,7 +71,7 @@ let sighup_handler _ =
 let config_filename cf =
 	match cf.config_file with
 	| Some name -> name
-	| None      -> Define.default_config_dir ^ "/xenstored.conf"
+	| None      -> Define.default_config_dir ^ "/oxenstored.conf"
 
 let default_pidfile = "/var/run/xenstored.pid"
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 16:14:11 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 16: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.xensource.com>)
	id 1RaUzU-0004Sh-70; Tue, 13 Dec 2011 16:14:04 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RaUzS-0004RT-9P
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 16:14:02 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1323792783!7287705!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjAzMzQ=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28693 invoked from network); 13 Dec 2011 16:13:07 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 16:13:07 -0000
X-IronPort-AV: E=Sophos;i="4.71,346,1320642000"; d="scan'208";a="173967242"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Dec 2011 11:13:07 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Tue, 13 Dec 2011 11:13:07 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pBDGD0pV028078;	Tue, 13 Dec 2011 08:13:05 -0800
MIME-Version: 1.0
X-Mercurial-Node: fd321c47d4b8e7095758e008ad3801e5d16461a7
Message-ID: <fd321c47d4b8e7095758.1323792782@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1323792779@cosworth.uk.xensource.com>
References: <patchbomb.1323792779@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Tue, 13 Dec 2011 16:13:02 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com, Olaf Hering <olaf@aepfle.de>,
	Vincent Hanquez <Vincent.Hanquez@eu.citrix.com>,
	Jonathan Ludlam <Jonathan.Ludlam@eu.citrix.com>, konrad.wilk@oracle.com
Subject: [Xen-devel] [PATCH 3 of 4 V2] oxenstored: install configuration file
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1323792537 0
# Node ID fd321c47d4b8e7095758e008ad3801e5d16461a7
# Parent  f4586d1a539c869e31fadc8b3c3223bd118b37fc
oxenstored: install configuration file

First though:
  - Move it to /etc/xen/oxenstored.conf.
  - Use /var/run/xenstored.pid as default pid file
  - Disable test-eagain "Randomly failed a transaction with EAGAIN. Used for
    testing Xs user". Doesn't sound fun by default...

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r f4586d1a539c -r fd321c47d4b8 tools/ocaml/xenstored/Makefile
--- a/tools/ocaml/xenstored/Makefile	Tue Dec 13 16:08:27 2011 +0000
+++ b/tools/ocaml/xenstored/Makefile	Tue Dec 13 16:08:57 2011 +0000
@@ -52,5 +52,7 @@ bins: $(PROGRAMS)
 install: all
 	$(INSTALL_DIR) $(DESTDIR)$(SBINDIR)
 	$(INSTALL_PROG) oxenstored $(DESTDIR)$(SBINDIR)
+	$(INSTALL_DIR) $(DESTDIR)$(XEN_CONFIG_DIR)
+	$(INSTALL_DATA) oxenstored.conf $(DESTDIR)$(XEN_CONFIG_DIR)
 
 include $(OCAML_TOPLEVEL)/Makefile.rules
diff -r f4586d1a539c -r fd321c47d4b8 tools/ocaml/xenstored/define.ml
--- a/tools/ocaml/xenstored/define.ml	Tue Dec 13 16:08:27 2011 +0000
+++ b/tools/ocaml/xenstored/define.ml	Tue Dec 13 16:08:57 2011 +0000
@@ -23,7 +23,7 @@ let xenstored_proc_port = "/proc/xen/xsd
 let xs_daemon_socket = "/var/run/xenstored/socket"
 let xs_daemon_socket_ro = "/var/run/xenstored/socket_ro"
 
-let default_config_dir = "/etc/xensource"
+let default_config_dir = "/etc/xen"
 
 let maxwatch = ref (50)
 let maxtransaction = ref (20)
diff -r f4586d1a539c -r fd321c47d4b8 tools/ocaml/xenstored/oxenstored.conf
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/tools/ocaml/xenstored/oxenstored.conf	Tue Dec 13 16:08:57 2011 +0000
@@ -0,0 +1,35 @@
+# default xenstored config
+
+# Where the pid file is stored
+pid-file = /var/run/xenstored.pid
+
+# Randomly failed a transaction with EAGAIN. Used for testing Xs user
+test-eagain = false
+
+# Activate transaction merge support
+merge-activate = true
+
+# Activate node permission system
+perms-activate = true
+
+# Activate quota
+quota-activate = true
+quota-maxentity = 1000
+quota-maxsize = 2048
+quota-maxwatch = 100
+quota-transaction = 10
+
+# Activate filed base backend
+persistant = false
+
+# Xenstored logs
+# xenstored-log-file = /var/log/xenstored.log
+# xenstored-log-level = null
+# xenstored-log-nb-files = 10
+
+# Xenstored access logs
+# access-log-file = /var/log/xenstored-access.log
+# access-log-nb-lines = 13215
+# acesss-log-nb-chars = 180
+# access-log-special-ops = false
+
diff -r f4586d1a539c -r fd321c47d4b8 tools/ocaml/xenstored/xenstored.conf
--- a/tools/ocaml/xenstored/xenstored.conf	Tue Dec 13 16:08:27 2011 +0000
+++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
@@ -1,35 +0,0 @@
-# default xenstored config
-
-# Where the pid file is stored
-pid-file = /var/run/xensource/xenstored.pid
-
-# Randomly failed a transaction with EAGAIN. Used for testing Xs user
-test-eagain = true
-
-# Activate transaction merge support
-merge-activate = true
-
-# Activate node permission system
-perms-activate = true
-
-# Activate quota
-quota-activate = true
-quota-maxentity = 1000
-quota-maxsize = 2048
-quota-maxwatch = 100
-quota-transaction = 10
-
-# Activate filed base backend
-persistant = false
-
-# Xenstored logs
-# xenstored-log-file = /var/log/xenstored.log
-# xenstored-log-level = null
-# xenstored-log-nb-files = 10
-
-# Xenstored access logs
-# access-log-file = /var/log/xenstored-access.log
-# access-log-nb-lines = 13215
-# acesss-log-nb-chars = 180
-# access-log-special-ops = false
-
diff -r f4586d1a539c -r fd321c47d4b8 tools/ocaml/xenstored/xenstored.ml
--- a/tools/ocaml/xenstored/xenstored.ml	Tue Dec 13 16:08:27 2011 +0000
+++ b/tools/ocaml/xenstored/xenstored.ml	Tue Dec 13 16:08:57 2011 +0000
@@ -71,7 +71,7 @@ let sighup_handler _ =
 let config_filename cf =
 	match cf.config_file with
 	| Some name -> name
-	| None      -> Define.default_config_dir ^ "/xenstored.conf"
+	| None      -> Define.default_config_dir ^ "/oxenstored.conf"
 
 let default_pidfile = "/var/run/xenstored.pid"
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 16:14:11 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 16: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.xensource.com>)
	id 1RaUzQ-0004Rz-Pl; Tue, 13 Dec 2011 16:14:00 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RaUzP-0004RO-Bi
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 16:13:59 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1323792755!44704502!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDUzNzY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 894 invoked from network); 13 Dec 2011 16:12:37 -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;
	13 Dec 2011 16:12:37 -0000
X-IronPort-AV: E=Sophos;i="4.71,346,1320642000"; d="scan'208";a="19923714"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Dec 2011 11:13:05 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Tue, 13 Dec 2011 11:13:05 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pBDGD0pU028078;	Tue, 13 Dec 2011 08:13:04 -0800
MIME-Version: 1.0
X-Mercurial-Node: f4586d1a539c869e31fadc8b3c3223bd118b37fc
Message-ID: <f4586d1a539c869e31fa.1323792781@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1323792779@cosworth.uk.xensource.com>
References: <patchbomb.1323792779@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Tue, 13 Dec 2011 16:13:01 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com, Olaf Hering <olaf@aepfle.de>,
	Vincent Hanquez <Vincent.Hanquez@eu.citrix.com>,
	Jonathan Ludlam <Jonathan.Ludlam@eu.citrix.com>, konrad.wilk@oracle.com
Subject: [Xen-devel] [PATCH 2 of 4 V2] Linux/xencommons: Use oxenstored by
 default when available
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1323792507 0
# Node ID f4586d1a539c869e31fadc8b3c3223bd118b37fc
# Parent  06c6ba6641640a2fa0ef6f998405f5f7c43bb258
Linux/xencommons: Use oxenstored by default when available

oxenstored is an ocaml implementation of the xenstore daemon. It is faster,
more scalable and more reliable than the C xenstored.

In particular the transaction model in oxenstored does not involve taking a
complete copy of the database and aborting on any (even non-conflicting) other
change.

There is a paper on the design and implementation of oxenstored at
http://gazagnaire.org/pub/GH09.pdf which includes a performance evaluation and
comparison with the C daemon etc.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 06c6ba664164 -r f4586d1a539c tools/hotplug/Linux/init.d/sysconfig.xencommons
--- a/tools/hotplug/Linux/init.d/sysconfig.xencommons	Tue Dec 13 16:08:08 2011 +0000
+++ b/tools/hotplug/Linux/init.d/sysconfig.xencommons	Tue Dec 13 16:08:27 2011 +0000
@@ -1,6 +1,9 @@
 # Log xenconsoled messages (cf xl dmesg)
 XENCONSOLED_TRACE=guest
 
+# Select xenstored implementation
+#XENSTORED=[oxenstored|xenstored]
+
 # Log xenstored messages
 #XENSTORED_TRACE=[yes|on|1]
 
diff -r 06c6ba664164 -r f4586d1a539c tools/hotplug/Linux/init.d/xencommons
--- a/tools/hotplug/Linux/init.d/xencommons	Tue Dec 13 16:08:08 2011 +0000
+++ b/tools/hotplug/Linux/init.d/xencommons	Tue Dec 13 16:08:27 2011 +0000
@@ -70,8 +70,19 @@ do_start () {
 		rm -f "$XENSTORED_ROOTDIR"/tdb* &>/dev/null
 		test -z "$XENSTORED_TRACE" || XENSTORED_ARGS=" -T /var/log/xen/xenstored-trace.log"
 
-		echo -n Starting xenstored...
-		xenstored --pid-file=/var/run/xenstored.pid $XENSTORED_ARGS
+		if [ -n "$XENSTORED" ] ; then
+		    echo -n Starting $XENSTORED...
+		    $XENSTORED --pid-file /var/run/xenstored.pid $XENSTORED_ARGS
+		elif [ -x /usr/sbin/oxenstored ] ; then
+		    echo -n Starting oxenstored...
+		    /usr/sbin/oxenstored --pid-file /var/run/xenstored.pid $XENSTORED_ARGS
+		elif [ -x /usr/sbin/xenstored ] ; then
+		    echo -n Starting C xenstored...
+		    /usr/sbin/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 ] && ! `xenstore-read -s / >/dev/null 2>&1` ; do

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 16:14:11 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 16: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.xensource.com>)
	id 1RaUzQ-0004Rz-Pl; Tue, 13 Dec 2011 16:14:00 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RaUzP-0004RO-Bi
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 16:13:59 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1323792755!44704502!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDUzNzY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 894 invoked from network); 13 Dec 2011 16:12:37 -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;
	13 Dec 2011 16:12:37 -0000
X-IronPort-AV: E=Sophos;i="4.71,346,1320642000"; d="scan'208";a="19923714"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Dec 2011 11:13:05 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Tue, 13 Dec 2011 11:13:05 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pBDGD0pU028078;	Tue, 13 Dec 2011 08:13:04 -0800
MIME-Version: 1.0
X-Mercurial-Node: f4586d1a539c869e31fadc8b3c3223bd118b37fc
Message-ID: <f4586d1a539c869e31fa.1323792781@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1323792779@cosworth.uk.xensource.com>
References: <patchbomb.1323792779@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Tue, 13 Dec 2011 16:13:01 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com, Olaf Hering <olaf@aepfle.de>,
	Vincent Hanquez <Vincent.Hanquez@eu.citrix.com>,
	Jonathan Ludlam <Jonathan.Ludlam@eu.citrix.com>, konrad.wilk@oracle.com
Subject: [Xen-devel] [PATCH 2 of 4 V2] Linux/xencommons: Use oxenstored by
 default when available
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1323792507 0
# Node ID f4586d1a539c869e31fadc8b3c3223bd118b37fc
# Parent  06c6ba6641640a2fa0ef6f998405f5f7c43bb258
Linux/xencommons: Use oxenstored by default when available

oxenstored is an ocaml implementation of the xenstore daemon. It is faster,
more scalable and more reliable than the C xenstored.

In particular the transaction model in oxenstored does not involve taking a
complete copy of the database and aborting on any (even non-conflicting) other
change.

There is a paper on the design and implementation of oxenstored at
http://gazagnaire.org/pub/GH09.pdf which includes a performance evaluation and
comparison with the C daemon etc.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 06c6ba664164 -r f4586d1a539c tools/hotplug/Linux/init.d/sysconfig.xencommons
--- a/tools/hotplug/Linux/init.d/sysconfig.xencommons	Tue Dec 13 16:08:08 2011 +0000
+++ b/tools/hotplug/Linux/init.d/sysconfig.xencommons	Tue Dec 13 16:08:27 2011 +0000
@@ -1,6 +1,9 @@
 # Log xenconsoled messages (cf xl dmesg)
 XENCONSOLED_TRACE=guest
 
+# Select xenstored implementation
+#XENSTORED=[oxenstored|xenstored]
+
 # Log xenstored messages
 #XENSTORED_TRACE=[yes|on|1]
 
diff -r 06c6ba664164 -r f4586d1a539c tools/hotplug/Linux/init.d/xencommons
--- a/tools/hotplug/Linux/init.d/xencommons	Tue Dec 13 16:08:08 2011 +0000
+++ b/tools/hotplug/Linux/init.d/xencommons	Tue Dec 13 16:08:27 2011 +0000
@@ -70,8 +70,19 @@ do_start () {
 		rm -f "$XENSTORED_ROOTDIR"/tdb* &>/dev/null
 		test -z "$XENSTORED_TRACE" || XENSTORED_ARGS=" -T /var/log/xen/xenstored-trace.log"
 
-		echo -n Starting xenstored...
-		xenstored --pid-file=/var/run/xenstored.pid $XENSTORED_ARGS
+		if [ -n "$XENSTORED" ] ; then
+		    echo -n Starting $XENSTORED...
+		    $XENSTORED --pid-file /var/run/xenstored.pid $XENSTORED_ARGS
+		elif [ -x /usr/sbin/oxenstored ] ; then
+		    echo -n Starting oxenstored...
+		    /usr/sbin/oxenstored --pid-file /var/run/xenstored.pid $XENSTORED_ARGS
+		elif [ -x /usr/sbin/xenstored ] ; then
+		    echo -n Starting C xenstored...
+		    /usr/sbin/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 ] && ! `xenstore-read -s / >/dev/null 2>&1` ; do

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 16:14:13 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 16:14:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaUzV-0004T6-Kp; Tue, 13 Dec 2011 16:14:05 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RaUzT-0004Rb-Nb
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 16:14:03 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1323792783!7287705!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjAzMzQ=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28794 invoked from network); 13 Dec 2011 16:13:09 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 16:13:09 -0000
X-IronPort-AV: E=Sophos;i="4.71,346,1320642000"; d="scan'208";a="173967251"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Dec 2011 11:13:08 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Tue, 13 Dec 2011 11:13:08 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pBDGD0pW028078;	Tue, 13 Dec 2011 08:13:07 -0800
MIME-Version: 1.0
X-Mercurial-Node: f2e14742b2a2c1f40bc36063a1485b4072865fd1
Message-ID: <f2e14742b2a2c1f40bc3.1323792783@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1323792779@cosworth.uk.xensource.com>
References: <patchbomb.1323792779@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Tue, 13 Dec 2011 16:13:03 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com, Olaf Hering <olaf@aepfle.de>,
	Vincent Hanquez <Vincent.Hanquez@eu.citrix.com>,
	Jonathan Ludlam <Jonathan.Ludlam@eu.citrix.com>, konrad.wilk@oracle.com
Subject: [Xen-devel] [PATCH 4 of 4 V2] oxenstored: Always log something at
 start of day (if logging enabled at all)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1323792620 0
# Node ID f2e14742b2a2c1f40bc36063a1485b4072865fd1
# Parent  fd321c47d4b8e7095758e008ad3801e5d16461a7
oxenstored: Always log something at start of day (if logging enabled at all)

Otherwise at the default level we rarely log anything at all.

A completely empty log file is a good sign, but only if you know you are
looking in the right place...

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r fd321c47d4b8 -r f2e14742b2a2 tools/ocaml/xenstored/logging.ml
--- a/tools/ocaml/xenstored/logging.ml	Tue Dec 13 16:08:57 2011 +0000
+++ b/tools/ocaml/xenstored/logging.ml	Tue Dec 13 16:10:20 2011 +0000
@@ -117,6 +117,9 @@ let init_xenstored_log () =
 			make_logger 
 				!xenstored_log_file !xenstored_log_nb_files !xenstored_log_nb_lines
 				!xenstored_log_nb_chars ignore in
+		let date = string_of_date() in
+		logger.write ("[%s|%5s|%s] Xen Storage Daemon, version %d.%d") date "" "startup"
+		  Define.xenstored_major Define.xenstored_minor;
 		xenstored_logger := Some logger
 
 let xenstored_logging level key (fmt: (_,_,_,_) format4) =
diff -r fd321c47d4b8 -r f2e14742b2a2 tools/ocaml/xenstored/xenstored.ml
--- a/tools/ocaml/xenstored/xenstored.ml	Tue Dec 13 16:08:57 2011 +0000
+++ b/tools/ocaml/xenstored/xenstored.ml	Tue Dec 13 16:10:20 2011 +0000
@@ -284,9 +284,6 @@ let _ =
 		Logging.init_access_log post_rotate
 	end;
 
-	info "Xen Storage Daemon, version %d.%d"
-	     Define.xenstored_major Define.xenstored_minor;
-
 	let spec_fds =
 		(match rw_sock with None -> [] | Some x -> [ x ]) @
 		(match ro_sock with None -> [] | Some x -> [ x ]) @

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 16:14:13 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 16:14:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaUzV-0004T6-Kp; Tue, 13 Dec 2011 16:14:05 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RaUzT-0004Rb-Nb
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 16:14:03 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1323792783!7287705!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjAzMzQ=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28794 invoked from network); 13 Dec 2011 16:13:09 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 16:13:09 -0000
X-IronPort-AV: E=Sophos;i="4.71,346,1320642000"; d="scan'208";a="173967251"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Dec 2011 11:13:08 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Tue, 13 Dec 2011 11:13:08 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pBDGD0pW028078;	Tue, 13 Dec 2011 08:13:07 -0800
MIME-Version: 1.0
X-Mercurial-Node: f2e14742b2a2c1f40bc36063a1485b4072865fd1
Message-ID: <f2e14742b2a2c1f40bc3.1323792783@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1323792779@cosworth.uk.xensource.com>
References: <patchbomb.1323792779@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Tue, 13 Dec 2011 16:13:03 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com, Olaf Hering <olaf@aepfle.de>,
	Vincent Hanquez <Vincent.Hanquez@eu.citrix.com>,
	Jonathan Ludlam <Jonathan.Ludlam@eu.citrix.com>, konrad.wilk@oracle.com
Subject: [Xen-devel] [PATCH 4 of 4 V2] oxenstored: Always log something at
 start of day (if logging enabled at all)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1323792620 0
# Node ID f2e14742b2a2c1f40bc36063a1485b4072865fd1
# Parent  fd321c47d4b8e7095758e008ad3801e5d16461a7
oxenstored: Always log something at start of day (if logging enabled at all)

Otherwise at the default level we rarely log anything at all.

A completely empty log file is a good sign, but only if you know you are
looking in the right place...

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r fd321c47d4b8 -r f2e14742b2a2 tools/ocaml/xenstored/logging.ml
--- a/tools/ocaml/xenstored/logging.ml	Tue Dec 13 16:08:57 2011 +0000
+++ b/tools/ocaml/xenstored/logging.ml	Tue Dec 13 16:10:20 2011 +0000
@@ -117,6 +117,9 @@ let init_xenstored_log () =
 			make_logger 
 				!xenstored_log_file !xenstored_log_nb_files !xenstored_log_nb_lines
 				!xenstored_log_nb_chars ignore in
+		let date = string_of_date() in
+		logger.write ("[%s|%5s|%s] Xen Storage Daemon, version %d.%d") date "" "startup"
+		  Define.xenstored_major Define.xenstored_minor;
 		xenstored_logger := Some logger
 
 let xenstored_logging level key (fmt: (_,_,_,_) format4) =
diff -r fd321c47d4b8 -r f2e14742b2a2 tools/ocaml/xenstored/xenstored.ml
--- a/tools/ocaml/xenstored/xenstored.ml	Tue Dec 13 16:08:57 2011 +0000
+++ b/tools/ocaml/xenstored/xenstored.ml	Tue Dec 13 16:10:20 2011 +0000
@@ -284,9 +284,6 @@ let _ =
 		Logging.init_access_log post_rotate
 	end;
 
-	info "Xen Storage Daemon, version %d.%d"
-	     Define.xenstored_major Define.xenstored_minor;
-
 	let spec_fds =
 		(match rw_sock with None -> [] | Some x -> [ x ]) @
 		(match ro_sock with None -> [] | Some x -> [ x ]) @

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 16:20:32 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 16:20:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaV5Y-0005Dk-QU; Tue, 13 Dec 2011 16:20:20 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <lars.kurth@citrix.com>) id 1RaV5X-0005DN-Hb
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 16:20:19 +0000
X-Env-Sender: lars.kurth@citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1323793161!7085926!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTI1NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22365 invoked from network); 13 Dec 2011 16:19:22 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 16:19:22 -0000
X-IronPort-AV: E=Sophos;i="4.71,346,1320624000"; 
   d="scan'208";a="9445895"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Dec 2011 16:19:21 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.161]) by
	LONPMAILMX01.citrite.net ([10.30.203.162]) with mapi; Tue, 13 Dec 2011
	16:19:21 +0000
From: Lars Kurth <lars.kurth@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>, Sander Eikelenboom
	<linux@eikelenboom.it>
Date: Tue, 13 Dec 2011 16:19:20 +0000
Thread-Topic: [Xen-devel] Security vulnerability process - confirmed
Thread-Index: Acy5r32Z8C3r2BvwR5mb1cBg2suiwQAA3LIA
Message-ID: <344C0F67BC927847A2C92F9EE358DB0EBAFAC50C29@LONPMAILBOX01.citrite.net>
References: <20198.11738.646611.204591@mariner.uk.xensource.com>
	<707238508.20111212194525@eikelenboom.it>
	<20199.30000.105401.697750@mariner.uk.xensource.com>
In-Reply-To: <20199.30000.105401.697750@mariner.uk.xensource.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"security@xen.org" <security@xen.org>
Subject: Re: [Xen-devel] Security vulnerability process - confirmed
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Done: will go live at 16:30

-----Original Message-----
From: Ian Jackson [mailto:Ian.Jackson@eu.citrix.com] 
Sent: 13 December 2011 15:54
To: Sander Eikelenboom
Cc: security@xen.org; Lars Kurth; xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Security vulnerability process - confirmed

Sander Eikelenboom writes ("Re: [Xen-devel] Security vulnerability process - confirmed"):
> Monday, December 12, 2011, 5:37:46 PM, you wrote:
> >    Public advisories will be posted to xen-devel.
...> 
> >    Copies will also be sent to the pre-disclosure list, unless
> >    the advisory was already sent there previously during the embargo
> >    period and has not been updated since.
> 
> shouldn't this include at least xen-users and xen-announce,

I think the Xen.org security team will be happy to send the messages
to a wider audience.  Lars, can you change this to say:

   Public advisories will be posted to xen-devel, xen-users and
   xen-annnounce.

?

> and perhaps a special read only list for security advisories ?

I think xen-announce will probably do.  It's very low traffic.

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 16:20:32 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 16:20:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaV5Y-0005Dk-QU; Tue, 13 Dec 2011 16:20:20 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <lars.kurth@citrix.com>) id 1RaV5X-0005DN-Hb
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 16:20:19 +0000
X-Env-Sender: lars.kurth@citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1323793161!7085926!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTI1NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22365 invoked from network); 13 Dec 2011 16:19:22 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 16:19:22 -0000
X-IronPort-AV: E=Sophos;i="4.71,346,1320624000"; 
   d="scan'208";a="9445895"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Dec 2011 16:19:21 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.161]) by
	LONPMAILMX01.citrite.net ([10.30.203.162]) with mapi; Tue, 13 Dec 2011
	16:19:21 +0000
From: Lars Kurth <lars.kurth@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>, Sander Eikelenboom
	<linux@eikelenboom.it>
Date: Tue, 13 Dec 2011 16:19:20 +0000
Thread-Topic: [Xen-devel] Security vulnerability process - confirmed
Thread-Index: Acy5r32Z8C3r2BvwR5mb1cBg2suiwQAA3LIA
Message-ID: <344C0F67BC927847A2C92F9EE358DB0EBAFAC50C29@LONPMAILBOX01.citrite.net>
References: <20198.11738.646611.204591@mariner.uk.xensource.com>
	<707238508.20111212194525@eikelenboom.it>
	<20199.30000.105401.697750@mariner.uk.xensource.com>
In-Reply-To: <20199.30000.105401.697750@mariner.uk.xensource.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"security@xen.org" <security@xen.org>
Subject: Re: [Xen-devel] Security vulnerability process - confirmed
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Done: will go live at 16:30

-----Original Message-----
From: Ian Jackson [mailto:Ian.Jackson@eu.citrix.com] 
Sent: 13 December 2011 15:54
To: Sander Eikelenboom
Cc: security@xen.org; Lars Kurth; xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Security vulnerability process - confirmed

Sander Eikelenboom writes ("Re: [Xen-devel] Security vulnerability process - confirmed"):
> Monday, December 12, 2011, 5:37:46 PM, you wrote:
> >    Public advisories will be posted to xen-devel.
...> 
> >    Copies will also be sent to the pre-disclosure list, unless
> >    the advisory was already sent there previously during the embargo
> >    period and has not been updated since.
> 
> shouldn't this include at least xen-users and xen-announce,

I think the Xen.org security team will be happy to send the messages
to a wider audience.  Lars, can you change this to say:

   Public advisories will be posted to xen-devel, xen-users and
   xen-annnounce.

?

> and perhaps a special read only list for security advisories ?

I think xen-announce will probably do.  It's very low traffic.

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 16:25:45 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 16:25:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaVAY-0005O8-Ie; Tue, 13 Dec 2011 16:25:30 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RaVAX-0005O2-9j
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 16:25:29 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1323793473!8058086!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDUzNzY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20137 invoked from network); 13 Dec 2011 16:24:34 -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;
	13 Dec 2011 16:24:34 -0000
X-IronPort-AV: E=Sophos;i="4.71,346,1320642000"; d="scan'208";a="19924342"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Dec 2011 11:24:33 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Tue, 13 Dec 2011 11:24:32 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pBDGOT46028100;	Tue, 13 Dec 2011 08:24:31 -0800
MIME-Version: 1.0
X-Mercurial-Node: 97677918e3a4c8e724d7c8a6aba9cec570400c99
Message-ID: <97677918e3a4c8e724d7.1323793469@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1323793468@cosworth.uk.xensource.com>
References: <patchbomb.1323793468@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Tue, 13 Dec 2011 16:24:29 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 1 of 3] libxl: add
 libxl__domain_pvcontrol_{available, read, write}
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1323793378 0
# Node ID 97677918e3a4c8e724d7c8a6aba9cec570400c99
# Parent  f2e14742b2a2c1f40bc36063a1485b4072865fd1
libxl: add libxl__domain_pvcontrol_{available,read,write}

Use instead of open coding.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r f2e14742b2a2 -r 97677918e3a4 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Tue Dec 13 16:10:20 2011 +0000
+++ b/tools/libxl/libxl.c	Tue Dec 13 16:22:58 2011 +0000
@@ -542,6 +542,58 @@ int libxl_domain_unpause(libxl_ctx *ctx,
     return rc;
 }
 
+int libxl__domain_pvcontrol_available(libxl__gc *gc, uint32_t domid)
+{
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+
+    unsigned long pvdriver = 0;
+    int ret;
+
+    if (LIBXL__DOMAIN_IS_TYPE(gc, domid, PV))
+        return 1;
+
+    ret = xc_get_hvm_param(ctx->xch, domid, HVM_PARAM_CALLBACK_IRQ, &pvdriver);
+    if (ret<0) {
+        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "getting HVM callback IRQ");
+        return ERROR_FAIL;
+    }
+    return !!pvdriver;
+}
+
+char * libxl__domain_pvcontrol_read(libxl__gc *gc, xs_transaction_t t,
+                                    uint32_t domid)
+{
+    const char *shutdown_path;
+    const char *dom_path;
+
+    dom_path = libxl__xs_get_dompath(gc, domid);
+    if (!dom_path)
+        return NULL;
+
+    shutdown_path = libxl__sprintf(gc, "%s/control/shutdown", dom_path);
+    if (!shutdown_path)
+        return NULL;
+
+    return libxl__xs_read(gc, t, shutdown_path);
+}
+
+int libxl__domain_pvcontrol_write(libxl__gc *gc, xs_transaction_t t,
+                                  uint32_t domid, const char *cmd)
+{
+    const char *shutdown_path;
+    const char *dom_path;
+
+    dom_path = libxl__xs_get_dompath(gc, domid);
+    if (!dom_path)
+        return ERROR_FAIL;
+
+    shutdown_path = libxl__sprintf(gc, "%s/control/shutdown", dom_path);
+    if (!shutdown_path)
+        return ERROR_FAIL;
+
+    return libxl__xs_write(gc, t, shutdown_path, "%s", cmd);
+}
+
 static char *req_table[] = {
     [0] = "poweroff",
     [1] = "reboot",
@@ -553,42 +605,29 @@ static char *req_table[] = {
 int libxl_domain_shutdown(libxl_ctx *ctx, uint32_t domid, int req)
 {
     GC_INIT(ctx);
-    char *shutdown_path;
-    char *dom_path;
+    int ret;
 
     if (req > ARRAY_SIZE(req_table)) {
         GC_FREE;
         return ERROR_INVAL;
     }
 
-    dom_path = libxl__xs_get_dompath(gc, domid);
-    if (!dom_path) {
-        GC_FREE;
-        return ERROR_FAIL;
+    ret = libxl__domain_pvcontrol_available(gc, domid);
+    if (ret < 0)
+        goto out;
+
+    if (!ret) {
+        LIBXL__LOG(CTX, LIBXL__LOG_ERROR, "PV shutdown control not available:"
+                   " graceful shutdown not possible, use destroy");
+        ret = ERROR_FAIL;
+        goto out;
     }
 
-    if (LIBXL__DOMAIN_IS_TYPE(gc,  domid, HVM)) {
-        unsigned long pvdriver = 0;
-        int ret;
-        ret = xc_get_hvm_param(ctx->xch, domid, HVM_PARAM_CALLBACK_IRQ, &pvdriver);
-        if (ret<0) {
-            LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "getting HVM callback IRQ");
-            GC_FREE;
-            return ERROR_FAIL;
-        }
-        if (!pvdriver) {
-            LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "HVM domain without PV drivers:"
-                       " graceful shutdown not possible, use destroy");
-            GC_FREE;
-            return ERROR_FAIL;
-        }
-    }
-
-    shutdown_path = libxl__sprintf(gc, "%s/control/shutdown", dom_path);
-    xs_write(ctx->xsh, XBT_NULL, shutdown_path, req_table[req], strlen(req_table[req]));
-
+    ret = libxl__domain_pvcontrol_write(gc, XBT_NULL, domid, req_table[req]);
+
+out:
     GC_FREE;
-    return 0;
+    return ret;
 }
 
 int libxl_get_wait_fd(libxl_ctx *ctx, int *fd)
diff -r f2e14742b2a2 -r 97677918e3a4 tools/libxl/libxl_dom.c
--- a/tools/libxl/libxl_dom.c	Tue Dec 13 16:10:20 2011 +0000
+++ b/tools/libxl/libxl_dom.c	Tue Dec 13 16:22:58 2011 +0000
@@ -415,7 +415,7 @@ static int libxl__domain_suspend_common_
     struct suspendinfo *si = data;
     unsigned long hvm_s_state = 0, hvm_pvdrv = 0;
     int ret;
-    char *path, *state = "suspend";
+    char *state = "suspend";
     int watchdog;
     libxl_ctx *ctx = libxl__gc_owner(si->gc);
     xs_transaction_t t;
@@ -451,15 +451,14 @@ static int libxl__domain_suspend_common_
         LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "issuing %s suspend request via XenBus control node",
                    si->hvm ? "PVHVM" : "PV");
 
-        path = libxl__sprintf(si->gc, "%s/control/shutdown", libxl__xs_get_dompath(si->gc, si->domid));
-        libxl__xs_write(si->gc, XBT_NULL, path, "suspend");
+        libxl__domain_pvcontrol_write(si->gc, XBT_NULL, si->domid, "suspend");
 
         LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "wait for the guest to acknowledge suspend request");
         watchdog = 60;
         while (!strcmp(state, "suspend") && watchdog > 0) {
             usleep(100000);
 
-            state = libxl__xs_read(si->gc, XBT_NULL, path);
+            state = libxl__domain_pvcontrol_read(si->gc, XBT_NULL, si->domid);
             if (!state) state = "";
 
             watchdog--;
@@ -479,11 +478,11 @@ static int libxl__domain_suspend_common_
         retry_transaction:
             t = xs_transaction_start(ctx->xsh);
 
-            state = libxl__xs_read(si->gc, t, path);
+            state = libxl__domain_pvcontrol_read(si->gc, t, si->domid);
             if (!state) state = "";
 
             if (!strcmp(state, "suspend"))
-                libxl__xs_write(si->gc, t, path, "");
+                libxl__domain_pvcontrol_write(si->gc, t, si->domid, "");
 
             if (!xs_transaction_end(ctx->xsh, t, 0))
                 if (errno == EAGAIN)
diff -r f2e14742b2a2 -r 97677918e3a4 tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Tue Dec 13 16:10:20 2011 +0000
+++ b/tools/libxl/libxl_internal.h	Tue Dec 13 16:22:58 2011 +0000
@@ -247,6 +247,12 @@ _hidden int libxl__domain_suspend_common
 _hidden int libxl__domain_save_device_model(libxl__gc *gc, uint32_t domid, int fd);
 _hidden void libxl__userdata_destroyall(libxl__gc *gc, uint32_t domid);
 
+_hidden int libxl__domain_pvcontrol_available(libxl__gc *gc, uint32_t domid);
+_hidden char * libxl__domain_pvcontrol_read(libxl__gc *gc,
+                                            xs_transaction_t t, uint32_t domid);
+_hidden int libxl__domain_pvcontrol_write(libxl__gc *gc, xs_transaction_t t,
+                                          uint32_t domid, const char *cmd);
+
 /* from xl_device */
 _hidden char *libxl__device_disk_string_of_backend(libxl_disk_backend backend);
 _hidden char *libxl__device_disk_string_of_format(libxl_disk_format format);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 16:25:45 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 16:25:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaVAY-0005O8-Ie; Tue, 13 Dec 2011 16:25:30 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RaVAX-0005O2-9j
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 16:25:29 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1323793473!8058086!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDUzNzY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20137 invoked from network); 13 Dec 2011 16:24:34 -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;
	13 Dec 2011 16:24:34 -0000
X-IronPort-AV: E=Sophos;i="4.71,346,1320642000"; d="scan'208";a="19924342"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Dec 2011 11:24:33 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Tue, 13 Dec 2011 11:24:32 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pBDGOT46028100;	Tue, 13 Dec 2011 08:24:31 -0800
MIME-Version: 1.0
X-Mercurial-Node: 97677918e3a4c8e724d7c8a6aba9cec570400c99
Message-ID: <97677918e3a4c8e724d7.1323793469@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1323793468@cosworth.uk.xensource.com>
References: <patchbomb.1323793468@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Tue, 13 Dec 2011 16:24:29 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 1 of 3] libxl: add
 libxl__domain_pvcontrol_{available, read, write}
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1323793378 0
# Node ID 97677918e3a4c8e724d7c8a6aba9cec570400c99
# Parent  f2e14742b2a2c1f40bc36063a1485b4072865fd1
libxl: add libxl__domain_pvcontrol_{available,read,write}

Use instead of open coding.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r f2e14742b2a2 -r 97677918e3a4 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Tue Dec 13 16:10:20 2011 +0000
+++ b/tools/libxl/libxl.c	Tue Dec 13 16:22:58 2011 +0000
@@ -542,6 +542,58 @@ int libxl_domain_unpause(libxl_ctx *ctx,
     return rc;
 }
 
+int libxl__domain_pvcontrol_available(libxl__gc *gc, uint32_t domid)
+{
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+
+    unsigned long pvdriver = 0;
+    int ret;
+
+    if (LIBXL__DOMAIN_IS_TYPE(gc, domid, PV))
+        return 1;
+
+    ret = xc_get_hvm_param(ctx->xch, domid, HVM_PARAM_CALLBACK_IRQ, &pvdriver);
+    if (ret<0) {
+        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "getting HVM callback IRQ");
+        return ERROR_FAIL;
+    }
+    return !!pvdriver;
+}
+
+char * libxl__domain_pvcontrol_read(libxl__gc *gc, xs_transaction_t t,
+                                    uint32_t domid)
+{
+    const char *shutdown_path;
+    const char *dom_path;
+
+    dom_path = libxl__xs_get_dompath(gc, domid);
+    if (!dom_path)
+        return NULL;
+
+    shutdown_path = libxl__sprintf(gc, "%s/control/shutdown", dom_path);
+    if (!shutdown_path)
+        return NULL;
+
+    return libxl__xs_read(gc, t, shutdown_path);
+}
+
+int libxl__domain_pvcontrol_write(libxl__gc *gc, xs_transaction_t t,
+                                  uint32_t domid, const char *cmd)
+{
+    const char *shutdown_path;
+    const char *dom_path;
+
+    dom_path = libxl__xs_get_dompath(gc, domid);
+    if (!dom_path)
+        return ERROR_FAIL;
+
+    shutdown_path = libxl__sprintf(gc, "%s/control/shutdown", dom_path);
+    if (!shutdown_path)
+        return ERROR_FAIL;
+
+    return libxl__xs_write(gc, t, shutdown_path, "%s", cmd);
+}
+
 static char *req_table[] = {
     [0] = "poweroff",
     [1] = "reboot",
@@ -553,42 +605,29 @@ static char *req_table[] = {
 int libxl_domain_shutdown(libxl_ctx *ctx, uint32_t domid, int req)
 {
     GC_INIT(ctx);
-    char *shutdown_path;
-    char *dom_path;
+    int ret;
 
     if (req > ARRAY_SIZE(req_table)) {
         GC_FREE;
         return ERROR_INVAL;
     }
 
-    dom_path = libxl__xs_get_dompath(gc, domid);
-    if (!dom_path) {
-        GC_FREE;
-        return ERROR_FAIL;
+    ret = libxl__domain_pvcontrol_available(gc, domid);
+    if (ret < 0)
+        goto out;
+
+    if (!ret) {
+        LIBXL__LOG(CTX, LIBXL__LOG_ERROR, "PV shutdown control not available:"
+                   " graceful shutdown not possible, use destroy");
+        ret = ERROR_FAIL;
+        goto out;
     }
 
-    if (LIBXL__DOMAIN_IS_TYPE(gc,  domid, HVM)) {
-        unsigned long pvdriver = 0;
-        int ret;
-        ret = xc_get_hvm_param(ctx->xch, domid, HVM_PARAM_CALLBACK_IRQ, &pvdriver);
-        if (ret<0) {
-            LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "getting HVM callback IRQ");
-            GC_FREE;
-            return ERROR_FAIL;
-        }
-        if (!pvdriver) {
-            LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "HVM domain without PV drivers:"
-                       " graceful shutdown not possible, use destroy");
-            GC_FREE;
-            return ERROR_FAIL;
-        }
-    }
-
-    shutdown_path = libxl__sprintf(gc, "%s/control/shutdown", dom_path);
-    xs_write(ctx->xsh, XBT_NULL, shutdown_path, req_table[req], strlen(req_table[req]));
-
+    ret = libxl__domain_pvcontrol_write(gc, XBT_NULL, domid, req_table[req]);
+
+out:
     GC_FREE;
-    return 0;
+    return ret;
 }
 
 int libxl_get_wait_fd(libxl_ctx *ctx, int *fd)
diff -r f2e14742b2a2 -r 97677918e3a4 tools/libxl/libxl_dom.c
--- a/tools/libxl/libxl_dom.c	Tue Dec 13 16:10:20 2011 +0000
+++ b/tools/libxl/libxl_dom.c	Tue Dec 13 16:22:58 2011 +0000
@@ -415,7 +415,7 @@ static int libxl__domain_suspend_common_
     struct suspendinfo *si = data;
     unsigned long hvm_s_state = 0, hvm_pvdrv = 0;
     int ret;
-    char *path, *state = "suspend";
+    char *state = "suspend";
     int watchdog;
     libxl_ctx *ctx = libxl__gc_owner(si->gc);
     xs_transaction_t t;
@@ -451,15 +451,14 @@ static int libxl__domain_suspend_common_
         LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "issuing %s suspend request via XenBus control node",
                    si->hvm ? "PVHVM" : "PV");
 
-        path = libxl__sprintf(si->gc, "%s/control/shutdown", libxl__xs_get_dompath(si->gc, si->domid));
-        libxl__xs_write(si->gc, XBT_NULL, path, "suspend");
+        libxl__domain_pvcontrol_write(si->gc, XBT_NULL, si->domid, "suspend");
 
         LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "wait for the guest to acknowledge suspend request");
         watchdog = 60;
         while (!strcmp(state, "suspend") && watchdog > 0) {
             usleep(100000);
 
-            state = libxl__xs_read(si->gc, XBT_NULL, path);
+            state = libxl__domain_pvcontrol_read(si->gc, XBT_NULL, si->domid);
             if (!state) state = "";
 
             watchdog--;
@@ -479,11 +478,11 @@ static int libxl__domain_suspend_common_
         retry_transaction:
             t = xs_transaction_start(ctx->xsh);
 
-            state = libxl__xs_read(si->gc, t, path);
+            state = libxl__domain_pvcontrol_read(si->gc, t, si->domid);
             if (!state) state = "";
 
             if (!strcmp(state, "suspend"))
-                libxl__xs_write(si->gc, t, path, "");
+                libxl__domain_pvcontrol_write(si->gc, t, si->domid, "");
 
             if (!xs_transaction_end(ctx->xsh, t, 0))
                 if (errno == EAGAIN)
diff -r f2e14742b2a2 -r 97677918e3a4 tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Tue Dec 13 16:10:20 2011 +0000
+++ b/tools/libxl/libxl_internal.h	Tue Dec 13 16:22:58 2011 +0000
@@ -247,6 +247,12 @@ _hidden int libxl__domain_suspend_common
 _hidden int libxl__domain_save_device_model(libxl__gc *gc, uint32_t domid, int fd);
 _hidden void libxl__userdata_destroyall(libxl__gc *gc, uint32_t domid);
 
+_hidden int libxl__domain_pvcontrol_available(libxl__gc *gc, uint32_t domid);
+_hidden char * libxl__domain_pvcontrol_read(libxl__gc *gc,
+                                            xs_transaction_t t, uint32_t domid);
+_hidden int libxl__domain_pvcontrol_write(libxl__gc *gc, xs_transaction_t t,
+                                          uint32_t domid, const char *cmd);
+
 /* from xl_device */
 _hidden char *libxl__device_disk_string_of_backend(libxl_disk_backend backend);
 _hidden char *libxl__device_disk_string_of_format(libxl_disk_format format);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 16:25:47 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 16: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.xensource.com>)
	id 1RaVAa-0005OM-V9; Tue, 13 Dec 2011 16:25:32 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RaVAY-0005O3-Sd
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 16:25:31 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1323793473!8058086!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDUzNzY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20207 invoked from network); 13 Dec 2011 16:24:36 -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;
	13 Dec 2011 16:24:36 -0000
X-IronPort-AV: E=Sophos;i="4.71,346,1320642000"; d="scan'208";a="19924345"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Dec 2011 11:24:35 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Tue, 13 Dec 2011 11:24:35 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pBDGOT48028100;	Tue, 13 Dec 2011 08:24:34 -0800
MIME-Version: 1.0
X-Mercurial-Node: 47606788dec2f110aecf5b356b250d65343070ac
Message-ID: <47606788dec2f110aecf.1323793471@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1323793468@cosworth.uk.xensource.com>
References: <patchbomb.1323793468@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Tue, 13 Dec 2011 16:24:31 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 3 of 3] libxl: report failure to reboot/shutdown
 due to lackof PV interfaces to caller
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1323793457 0
# Node ID 47606788dec2f110aecf5b356b250d65343070ac
# Parent  e0f020d3d812e00aeb0c271a9627206279da3964
libxl: report failure to reboot/shutdown due to lackof PV interfaces to caller

This allow the caller to react as they think is appropriate. xl now prints a
message much like the library did previously, although hopefully somewhat more
informative.

Update the xl(1) man page to be similarly more informative.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r e0f020d3d812 -r 47606788dec2 docs/man/xl.pod.1
--- a/docs/man/xl.pod.1	Tue Dec 13 16:24:04 2011 +0000
+++ b/docs/man/xl.pod.1	Tue Dec 13 16:24:17 2011 +0000
@@ -368,7 +368,11 @@ Reboot a domain.  This acts just as if t
 command run from the console.  The command returns as soon as it has
 executed the reboot action, which may be significantly before the
 domain actually reboots.
-It requires PV drivers installed in your guest OS.
+
+For HVM domains this requires PV drivers to be installed in your guest
+OS. If PV drivers are not present but you have configured the guest OS
+to behave appropriately you may be able to use the I<button-press>
+subcommand to trigger a power button press.
 
 The behavior of what happens to a domain when it reboots is set by the
 B<on_reboot> parameter of the domain configuration file when the
@@ -424,9 +428,15 @@ Leave domain running after creating the 
 Gracefully shuts down a domain.  This coordinates with the domain OS
 to perform graceful shutdown, so there is no guarantee that it will
 succeed, and may take a variable length of time depending on what
-services must be shutdown in the domain.  The command returns
-immediately after signally the domain unless that B<-w> flag is used.
-For HVM domains it requires PV drivers to be installed in your guest OS.
+services must be shutdown in the domain.
+
+For HVM domains this requires PV drivers to be installed in your guest
+OS. If PV drivers are not present but you have configured the guest OS
+to behave appropriately you may be able to use the I<button-press>
+subcommand to trigger a power button press.
+
+The command returns immediately after signally the domain unless that
+B<-w> flag is used.
 
 The behavior of what happens to a domain when it reboots is set by the
 B<on_shutdown> parameter of the domain configuration file when the
diff -r e0f020d3d812 -r 47606788dec2 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Tue Dec 13 16:24:04 2011 +0000
+++ b/tools/libxl/libxl.c	Tue Dec 13 16:24:17 2011 +0000
@@ -604,9 +604,7 @@ int libxl_domain_shutdown(libxl_ctx *ctx
         goto out;
 
     if (!ret) {
-        LIBXL__LOG(CTX, LIBXL__LOG_ERROR, "PV control interface not available:"
-                   " graceful shutdown not possible, use destroy");
-        ret = ERROR_FAIL;
+        ret = ERROR_NOPARAVIRT;
         goto out;
     }
 
@@ -627,9 +625,7 @@ int libxl_domain_reboot(libxl_ctx *ctx, 
         goto out;
 
     if (!ret) {
-        LIBXL__LOG(CTX, LIBXL__LOG_ERROR, "PV control interface not available:"
-                   " graceful reboot not possible, use destroy+create");
-        ret = ERROR_FAIL;
+        ret = ERROR_NOPARAVIRT;
         goto out;
     }
 
diff -r e0f020d3d812 -r 47606788dec2 tools/libxl/libxl.h
--- a/tools/libxl/libxl.h	Tue Dec 13 16:24:04 2011 +0000
+++ b/tools/libxl/libxl.h	Tue Dec 13 16:24:17 2011 +0000
@@ -222,6 +222,7 @@ enum {
     ERROR_BADFAIL = -7,
     ERROR_GUEST_TIMEDOUT = -8,
     ERROR_TIMEDOUT = -9,
+    ERROR_NOPARAVIRT = -10,
 };
 
 #define LIBXL_VERSION 0
diff -r e0f020d3d812 -r 47606788dec2 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Tue Dec 13 16:24:04 2011 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Tue Dec 13 16:24:17 2011 +0000
@@ -2266,7 +2266,15 @@ static void shutdown_domain(const char *
 
     find_domain(p);
     rc=libxl_domain_shutdown(ctx, domid);
-    if (rc) { fprintf(stderr,"shutdown failed (rc=%d)\n",rc);exit(-1); }
+    if (rc) {
+        if (rc == ERROR_NOPARAVIRT) {
+            fprintf(stderr, "PV control interface not available:"
+                    " external graceful shutdown not possible.\n");
+            fprintf(stderr, "Use \"xl button-press <dom> power\" or"
+                    " \"xl destroy <dom>\".\n");
+        }
+        fprintf(stderr,"shutdown failed (rc=%d)\n",rc);exit(-1);
+    }
 
     if (wait) {
         libxl_waiter waiter;
@@ -2308,7 +2316,14 @@ static void reboot_domain(const char *p)
     int rc;
     find_domain(p);
     rc=libxl_domain_reboot(ctx, domid);
-    if (rc) { fprintf(stderr,"reboot failed (rc=%d)\n",rc);exit(-1); }
+    if (rc) {
+        if (rc == ERROR_NOPARAVIRT) {
+            fprintf(stderr, "PV control interface not available:"
+                    " external graceful reboot not possible.\n");
+            fprintf(stderr, "Use \"xl button-press <dom> power\" or"
+                    " \"xl destroy <dom>\".\n");
+        }
+        fprintf(stderr,"reboot failed (rc=%d)\n",rc);exit(-1); }
 }
 
 static void list_domains_details(const libxl_dominfo *info, int nb_domain)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 16:25:47 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 16: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.xensource.com>)
	id 1RaVAa-0005OM-V9; Tue, 13 Dec 2011 16:25:32 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RaVAY-0005O3-Sd
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 16:25:31 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1323793473!8058086!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDUzNzY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20207 invoked from network); 13 Dec 2011 16:24:36 -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;
	13 Dec 2011 16:24:36 -0000
X-IronPort-AV: E=Sophos;i="4.71,346,1320642000"; d="scan'208";a="19924345"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Dec 2011 11:24:35 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Tue, 13 Dec 2011 11:24:35 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pBDGOT48028100;	Tue, 13 Dec 2011 08:24:34 -0800
MIME-Version: 1.0
X-Mercurial-Node: 47606788dec2f110aecf5b356b250d65343070ac
Message-ID: <47606788dec2f110aecf.1323793471@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1323793468@cosworth.uk.xensource.com>
References: <patchbomb.1323793468@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Tue, 13 Dec 2011 16:24:31 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 3 of 3] libxl: report failure to reboot/shutdown
 due to lackof PV interfaces to caller
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1323793457 0
# Node ID 47606788dec2f110aecf5b356b250d65343070ac
# Parent  e0f020d3d812e00aeb0c271a9627206279da3964
libxl: report failure to reboot/shutdown due to lackof PV interfaces to caller

This allow the caller to react as they think is appropriate. xl now prints a
message much like the library did previously, although hopefully somewhat more
informative.

Update the xl(1) man page to be similarly more informative.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r e0f020d3d812 -r 47606788dec2 docs/man/xl.pod.1
--- a/docs/man/xl.pod.1	Tue Dec 13 16:24:04 2011 +0000
+++ b/docs/man/xl.pod.1	Tue Dec 13 16:24:17 2011 +0000
@@ -368,7 +368,11 @@ Reboot a domain.  This acts just as if t
 command run from the console.  The command returns as soon as it has
 executed the reboot action, which may be significantly before the
 domain actually reboots.
-It requires PV drivers installed in your guest OS.
+
+For HVM domains this requires PV drivers to be installed in your guest
+OS. If PV drivers are not present but you have configured the guest OS
+to behave appropriately you may be able to use the I<button-press>
+subcommand to trigger a power button press.
 
 The behavior of what happens to a domain when it reboots is set by the
 B<on_reboot> parameter of the domain configuration file when the
@@ -424,9 +428,15 @@ Leave domain running after creating the 
 Gracefully shuts down a domain.  This coordinates with the domain OS
 to perform graceful shutdown, so there is no guarantee that it will
 succeed, and may take a variable length of time depending on what
-services must be shutdown in the domain.  The command returns
-immediately after signally the domain unless that B<-w> flag is used.
-For HVM domains it requires PV drivers to be installed in your guest OS.
+services must be shutdown in the domain.
+
+For HVM domains this requires PV drivers to be installed in your guest
+OS. If PV drivers are not present but you have configured the guest OS
+to behave appropriately you may be able to use the I<button-press>
+subcommand to trigger a power button press.
+
+The command returns immediately after signally the domain unless that
+B<-w> flag is used.
 
 The behavior of what happens to a domain when it reboots is set by the
 B<on_shutdown> parameter of the domain configuration file when the
diff -r e0f020d3d812 -r 47606788dec2 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Tue Dec 13 16:24:04 2011 +0000
+++ b/tools/libxl/libxl.c	Tue Dec 13 16:24:17 2011 +0000
@@ -604,9 +604,7 @@ int libxl_domain_shutdown(libxl_ctx *ctx
         goto out;
 
     if (!ret) {
-        LIBXL__LOG(CTX, LIBXL__LOG_ERROR, "PV control interface not available:"
-                   " graceful shutdown not possible, use destroy");
-        ret = ERROR_FAIL;
+        ret = ERROR_NOPARAVIRT;
         goto out;
     }
 
@@ -627,9 +625,7 @@ int libxl_domain_reboot(libxl_ctx *ctx, 
         goto out;
 
     if (!ret) {
-        LIBXL__LOG(CTX, LIBXL__LOG_ERROR, "PV control interface not available:"
-                   " graceful reboot not possible, use destroy+create");
-        ret = ERROR_FAIL;
+        ret = ERROR_NOPARAVIRT;
         goto out;
     }
 
diff -r e0f020d3d812 -r 47606788dec2 tools/libxl/libxl.h
--- a/tools/libxl/libxl.h	Tue Dec 13 16:24:04 2011 +0000
+++ b/tools/libxl/libxl.h	Tue Dec 13 16:24:17 2011 +0000
@@ -222,6 +222,7 @@ enum {
     ERROR_BADFAIL = -7,
     ERROR_GUEST_TIMEDOUT = -8,
     ERROR_TIMEDOUT = -9,
+    ERROR_NOPARAVIRT = -10,
 };
 
 #define LIBXL_VERSION 0
diff -r e0f020d3d812 -r 47606788dec2 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Tue Dec 13 16:24:04 2011 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Tue Dec 13 16:24:17 2011 +0000
@@ -2266,7 +2266,15 @@ static void shutdown_domain(const char *
 
     find_domain(p);
     rc=libxl_domain_shutdown(ctx, domid);
-    if (rc) { fprintf(stderr,"shutdown failed (rc=%d)\n",rc);exit(-1); }
+    if (rc) {
+        if (rc == ERROR_NOPARAVIRT) {
+            fprintf(stderr, "PV control interface not available:"
+                    " external graceful shutdown not possible.\n");
+            fprintf(stderr, "Use \"xl button-press <dom> power\" or"
+                    " \"xl destroy <dom>\".\n");
+        }
+        fprintf(stderr,"shutdown failed (rc=%d)\n",rc);exit(-1);
+    }
 
     if (wait) {
         libxl_waiter waiter;
@@ -2308,7 +2316,14 @@ static void reboot_domain(const char *p)
     int rc;
     find_domain(p);
     rc=libxl_domain_reboot(ctx, domid);
-    if (rc) { fprintf(stderr,"reboot failed (rc=%d)\n",rc);exit(-1); }
+    if (rc) {
+        if (rc == ERROR_NOPARAVIRT) {
+            fprintf(stderr, "PV control interface not available:"
+                    " external graceful reboot not possible.\n");
+            fprintf(stderr, "Use \"xl button-press <dom> power\" or"
+                    " \"xl destroy <dom>\".\n");
+        }
+        fprintf(stderr,"reboot failed (rc=%d)\n",rc);exit(-1); }
 }
 
 static void list_domains_details(const libxl_dominfo *info, int nb_domain)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 16:26:07 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 16:26:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaVAx-0005Rc-Ox; Tue, 13 Dec 2011 16:25:55 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RaVAw-0005Qj-MR
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 16:25:54 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1323793497!7097033!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjAzMzQ=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27496 invoked from network); 13 Dec 2011 16:24:59 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 16:24:59 -0000
X-IronPort-AV: E=Sophos;i="4.71,346,1320642000"; d="scan'208";a="173969973"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Dec 2011 11:24:34 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Tue, 13 Dec 2011 11:24:34 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pBDGOT47028100;	Tue, 13 Dec 2011 08:24:33 -0800
MIME-Version: 1.0
X-Mercurial-Node: e0f020d3d812e00aeb0c271a9627206279da3964
Message-ID: <e0f020d3d812e00aeb0c.1323793470@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1323793468@cosworth.uk.xensource.com>
References: <patchbomb.1323793468@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Tue, 13 Dec 2011 16:24:30 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 2 of 3] libxl: split libxl_domain_shutdown into
 libxl_domain_shutdown & libxl_domain_reboot
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1323793444 0
# Node ID e0f020d3d812e00aeb0c271a9627206279da3964
# Parent  97677918e3a4c8e724d7c8a6aba9cec570400c99
libxl: split libxl_domain_shutdown into libxl_domain_shutdown & libxl_domain_reboot

The other integer request types which shutdown supported are not useful. Specifically:

 * "suspend" is not usable via this interface since it requires other
   scaffolding, libxl_domain_suspend provides this already.
 * "halt" is the same as "poweroff".
 * "crash" is unused and at least Linux does not implement it. If a user
   steps forward then libxl_domain_crash is trivial to add.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 97677918e3a4 -r e0f020d3d812 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Tue Dec 13 16:22:58 2011 +0000
+++ b/tools/libxl/libxl.c	Tue Dec 13 16:24:04 2011 +0000
@@ -594,36 +594,46 @@ int libxl__domain_pvcontrol_write(libxl_
     return libxl__xs_write(gc, t, shutdown_path, "%s", cmd);
 }
 
-static char *req_table[] = {
-    [0] = "poweroff",
-    [1] = "reboot",
-    [2] = "suspend",
-    [3] = "crash",
-    [4] = "halt",
-};
-
-int libxl_domain_shutdown(libxl_ctx *ctx, uint32_t domid, int req)
+int libxl_domain_shutdown(libxl_ctx *ctx, uint32_t domid)
 {
     GC_INIT(ctx);
     int ret;
 
-    if (req > ARRAY_SIZE(req_table)) {
-        GC_FREE;
-        return ERROR_INVAL;
-    }
-
     ret = libxl__domain_pvcontrol_available(gc, domid);
     if (ret < 0)
         goto out;
 
     if (!ret) {
-        LIBXL__LOG(CTX, LIBXL__LOG_ERROR, "PV shutdown control not available:"
+        LIBXL__LOG(CTX, LIBXL__LOG_ERROR, "PV control interface not available:"
                    " graceful shutdown not possible, use destroy");
         ret = ERROR_FAIL;
         goto out;
     }
 
-    ret = libxl__domain_pvcontrol_write(gc, XBT_NULL, domid, req_table[req]);
+    ret = libxl__domain_pvcontrol_write(gc, XBT_NULL, domid, "poweroff");
+
+out:
+    GC_FREE;
+    return ret;
+}
+
+int libxl_domain_reboot(libxl_ctx *ctx, uint32_t domid)
+{
+    GC_INIT(ctx);
+    int ret;
+
+    ret = libxl__domain_pvcontrol_available(gc, domid);
+    if (ret < 0)
+        goto out;
+
+    if (!ret) {
+        LIBXL__LOG(CTX, LIBXL__LOG_ERROR, "PV control interface not available:"
+                   " graceful reboot not possible, use destroy+create");
+        ret = ERROR_FAIL;
+        goto out;
+    }
+
+    ret = libxl__domain_pvcontrol_write(gc, XBT_NULL, domid, "reboot");
 
 out:
     GC_FREE;
diff -r 97677918e3a4 -r e0f020d3d812 tools/libxl/libxl.h
--- a/tools/libxl/libxl.h	Tue Dec 13 16:22:58 2011 +0000
+++ b/tools/libxl/libxl.h	Tue Dec 13 16:24:04 2011 +0000
@@ -268,7 +268,8 @@ void libxl_domain_config_dispose(libxl_d
 int libxl_domain_suspend(libxl_ctx *ctx, libxl_domain_suspend_info *info,
                           uint32_t domid, int fd);
 int libxl_domain_resume(libxl_ctx *ctx, uint32_t domid);
-int libxl_domain_shutdown(libxl_ctx *ctx, uint32_t domid, int req);
+int libxl_domain_shutdown(libxl_ctx *ctx, uint32_t domid);
+int libxl_domain_reboot(libxl_ctx *ctx, uint32_t domid);
 int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid, int force);
 int libxl_domain_preserve(libxl_ctx *ctx, uint32_t domid, libxl_domain_create_info *info, const char *name_suffix, libxl_uuid new_uuid);
 
diff -r 97677918e3a4 -r e0f020d3d812 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Tue Dec 13 16:22:58 2011 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Tue Dec 13 16:24:04 2011 +0000
@@ -2265,7 +2265,7 @@ static void shutdown_domain(const char *
     int rc;
 
     find_domain(p);
-    rc=libxl_domain_shutdown(ctx, domid, 0);
+    rc=libxl_domain_shutdown(ctx, domid);
     if (rc) { fprintf(stderr,"shutdown failed (rc=%d)\n",rc);exit(-1); }
 
     if (wait) {
@@ -2307,7 +2307,7 @@ static void reboot_domain(const char *p)
 {
     int rc;
     find_domain(p);
-    rc=libxl_domain_shutdown(ctx, domid, 1);
+    rc=libxl_domain_reboot(ctx, domid);
     if (rc) { fprintf(stderr,"reboot failed (rc=%d)\n",rc);exit(-1); }
 }
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 16:26:07 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 16:26:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaVAx-0005Rc-Ox; Tue, 13 Dec 2011 16:25:55 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RaVAw-0005Qj-MR
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 16:25:54 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1323793497!7097033!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjAzMzQ=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27496 invoked from network); 13 Dec 2011 16:24:59 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 16:24:59 -0000
X-IronPort-AV: E=Sophos;i="4.71,346,1320642000"; d="scan'208";a="173969973"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Dec 2011 11:24:34 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Tue, 13 Dec 2011 11:24:34 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pBDGOT47028100;	Tue, 13 Dec 2011 08:24:33 -0800
MIME-Version: 1.0
X-Mercurial-Node: e0f020d3d812e00aeb0c271a9627206279da3964
Message-ID: <e0f020d3d812e00aeb0c.1323793470@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1323793468@cosworth.uk.xensource.com>
References: <patchbomb.1323793468@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Tue, 13 Dec 2011 16:24:30 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 2 of 3] libxl: split libxl_domain_shutdown into
 libxl_domain_shutdown & libxl_domain_reboot
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1323793444 0
# Node ID e0f020d3d812e00aeb0c271a9627206279da3964
# Parent  97677918e3a4c8e724d7c8a6aba9cec570400c99
libxl: split libxl_domain_shutdown into libxl_domain_shutdown & libxl_domain_reboot

The other integer request types which shutdown supported are not useful. Specifically:

 * "suspend" is not usable via this interface since it requires other
   scaffolding, libxl_domain_suspend provides this already.
 * "halt" is the same as "poweroff".
 * "crash" is unused and at least Linux does not implement it. If a user
   steps forward then libxl_domain_crash is trivial to add.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 97677918e3a4 -r e0f020d3d812 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Tue Dec 13 16:22:58 2011 +0000
+++ b/tools/libxl/libxl.c	Tue Dec 13 16:24:04 2011 +0000
@@ -594,36 +594,46 @@ int libxl__domain_pvcontrol_write(libxl_
     return libxl__xs_write(gc, t, shutdown_path, "%s", cmd);
 }
 
-static char *req_table[] = {
-    [0] = "poweroff",
-    [1] = "reboot",
-    [2] = "suspend",
-    [3] = "crash",
-    [4] = "halt",
-};
-
-int libxl_domain_shutdown(libxl_ctx *ctx, uint32_t domid, int req)
+int libxl_domain_shutdown(libxl_ctx *ctx, uint32_t domid)
 {
     GC_INIT(ctx);
     int ret;
 
-    if (req > ARRAY_SIZE(req_table)) {
-        GC_FREE;
-        return ERROR_INVAL;
-    }
-
     ret = libxl__domain_pvcontrol_available(gc, domid);
     if (ret < 0)
         goto out;
 
     if (!ret) {
-        LIBXL__LOG(CTX, LIBXL__LOG_ERROR, "PV shutdown control not available:"
+        LIBXL__LOG(CTX, LIBXL__LOG_ERROR, "PV control interface not available:"
                    " graceful shutdown not possible, use destroy");
         ret = ERROR_FAIL;
         goto out;
     }
 
-    ret = libxl__domain_pvcontrol_write(gc, XBT_NULL, domid, req_table[req]);
+    ret = libxl__domain_pvcontrol_write(gc, XBT_NULL, domid, "poweroff");
+
+out:
+    GC_FREE;
+    return ret;
+}
+
+int libxl_domain_reboot(libxl_ctx *ctx, uint32_t domid)
+{
+    GC_INIT(ctx);
+    int ret;
+
+    ret = libxl__domain_pvcontrol_available(gc, domid);
+    if (ret < 0)
+        goto out;
+
+    if (!ret) {
+        LIBXL__LOG(CTX, LIBXL__LOG_ERROR, "PV control interface not available:"
+                   " graceful reboot not possible, use destroy+create");
+        ret = ERROR_FAIL;
+        goto out;
+    }
+
+    ret = libxl__domain_pvcontrol_write(gc, XBT_NULL, domid, "reboot");
 
 out:
     GC_FREE;
diff -r 97677918e3a4 -r e0f020d3d812 tools/libxl/libxl.h
--- a/tools/libxl/libxl.h	Tue Dec 13 16:22:58 2011 +0000
+++ b/tools/libxl/libxl.h	Tue Dec 13 16:24:04 2011 +0000
@@ -268,7 +268,8 @@ void libxl_domain_config_dispose(libxl_d
 int libxl_domain_suspend(libxl_ctx *ctx, libxl_domain_suspend_info *info,
                           uint32_t domid, int fd);
 int libxl_domain_resume(libxl_ctx *ctx, uint32_t domid);
-int libxl_domain_shutdown(libxl_ctx *ctx, uint32_t domid, int req);
+int libxl_domain_shutdown(libxl_ctx *ctx, uint32_t domid);
+int libxl_domain_reboot(libxl_ctx *ctx, uint32_t domid);
 int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid, int force);
 int libxl_domain_preserve(libxl_ctx *ctx, uint32_t domid, libxl_domain_create_info *info, const char *name_suffix, libxl_uuid new_uuid);
 
diff -r 97677918e3a4 -r e0f020d3d812 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Tue Dec 13 16:22:58 2011 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Tue Dec 13 16:24:04 2011 +0000
@@ -2265,7 +2265,7 @@ static void shutdown_domain(const char *
     int rc;
 
     find_domain(p);
-    rc=libxl_domain_shutdown(ctx, domid, 0);
+    rc=libxl_domain_shutdown(ctx, domid);
     if (rc) { fprintf(stderr,"shutdown failed (rc=%d)\n",rc);exit(-1); }
 
     if (wait) {
@@ -2307,7 +2307,7 @@ static void reboot_domain(const char *p)
 {
     int rc;
     find_domain(p);
-    rc=libxl_domain_shutdown(ctx, domid, 1);
+    rc=libxl_domain_reboot(ctx, domid);
     if (rc) { fprintf(stderr,"reboot failed (rc=%d)\n",rc);exit(-1); }
 }
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 16:26:08 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 16:26:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaVAx-0005RU-Ch; Tue, 13 Dec 2011 16:25:55 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RaVAv-0005Qb-Qe
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 16:25:54 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1323793497!7097033!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjAzMzQ=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27467 invoked from network); 13 Dec 2011 16:24:58 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 16:24:58 -0000
X-IronPort-AV: E=Sophos;i="4.71,346,1320642000"; d="scan'208";a="173969970"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Dec 2011 11:24:31 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Tue, 13 Dec 2011 11:24:31 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pBDGOT45028100;	Tue, 13 Dec 2011 08:24:30 -0800
MIME-Version: 1.0
Message-ID: <patchbomb.1323793468@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Tue, 13 Dec 2011 16:24:28 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 0 of 3] libxl: domain shutdown cleanup
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

The existing libxl_domain_shutdown is a bit odd, it takes an integer
"req" which can be used to indicate one of:
  * [0] = "poweroff",
  * [1] = "reboot",
  * [2] = "suspend",
  * [3] = "crash",
  * [4] = "halt",

"suspend" is not usable via this interface since it requires other
scaffolding, libxl_domain_suspend provides this already.

"halt" is the same as "poweroff".

"crash" is unused and at least Linux does not implement it. If a user
steps forward then libxl_domain_crash is trivial to add.

Therefore split libxl_domain_shutdown into libxl_domain_shutdown and
libxl_domain_reboot corresponding to "poweroff" and "reboot"
respectively.

Also push responsibility for dealing with lack of PV drivers into the
caller and at the same time improve the error messages presented to
the user when they try and "xl shutdown/reboot" an HVM guest with no
PV drivers and the corresponding documentation.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 16:26:08 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 16:26:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaVAx-0005RU-Ch; Tue, 13 Dec 2011 16:25:55 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RaVAv-0005Qb-Qe
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 16:25:54 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1323793497!7097033!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjAzMzQ=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27467 invoked from network); 13 Dec 2011 16:24:58 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 16:24:58 -0000
X-IronPort-AV: E=Sophos;i="4.71,346,1320642000"; d="scan'208";a="173969970"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Dec 2011 11:24:31 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Tue, 13 Dec 2011 11:24:31 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pBDGOT45028100;	Tue, 13 Dec 2011 08:24:30 -0800
MIME-Version: 1.0
Message-ID: <patchbomb.1323793468@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Tue, 13 Dec 2011 16:24:28 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 0 of 3] libxl: domain shutdown cleanup
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

The existing libxl_domain_shutdown is a bit odd, it takes an integer
"req" which can be used to indicate one of:
  * [0] = "poweroff",
  * [1] = "reboot",
  * [2] = "suspend",
  * [3] = "crash",
  * [4] = "halt",

"suspend" is not usable via this interface since it requires other
scaffolding, libxl_domain_suspend provides this already.

"halt" is the same as "poweroff".

"crash" is unused and at least Linux does not implement it. If a user
steps forward then libxl_domain_crash is trivial to add.

Therefore split libxl_domain_shutdown into libxl_domain_shutdown and
libxl_domain_reboot corresponding to "poweroff" and "reboot"
respectively.

Also push responsibility for dealing with lack of PV drivers into the
caller and at the same time improve the error messages presented to
the user when they try and "xl shutdown/reboot" an HVM guest with no
PV drivers and the corresponding documentation.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 16:44:25 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 16:44:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaVSZ-0006AZ-O0; Tue, 13 Dec 2011 16:44:07 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1RaVSX-0006AU-Jy
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 16:44:05 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-7.tower-174.messagelabs.com!1323794589!5406692!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22274 invoked from network); 13 Dec 2011 16:43:11 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-7.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 13 Dec 2011 16:43:11 -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
	pBDGgRfF009500
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Tue, 13 Dec 2011 11:42:27 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pBDGgQ4t009498;
	Tue, 13 Dec 2011 11:42:26 -0500
Date: Tue, 13 Dec 2011 12:42:26 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Borislav Petkov <bp@amd64.org>, hpa@zytor.com
Message-ID: <20111213164226.GA9081@andromeda.dapyr.net>
References: <4ED6676F02000078000646BC@nat28.tlf.novell.com>
	<20111130222359.GC16651@andromeda.dapyr.net>
	<4ED7433A0200007800064903@nat28.tlf.novell.com>
	<1322733358.31810.174.camel@zakaz.uk.xensource.com>
	<4ED75EB202000078000649E9@nat28.tlf.novell.com>
	<20111201103808.GB31552@aftab>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20111201103808.GB31552@aftab>
User-Agent: Mutt/1.5.9i
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Jan Beulich <JBeulich@suse.com>, "hpa@zytor.com" <hpa@zytor.com>
Subject: Re: [Xen-devel] [PATCH 2/2] x86/microcode: enable boot time
	(pre-Dom0) loading
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Dec 01, 2011 at 11:38:08AM +0100, Borislav Petkov wrote:
> On Thu, Dec 01, 2011 at 10:02:10AM +0000, Jan Beulich wrote:
> > >>> On 01.12.11 at 10:55, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > > On Thu, 2011-12-01 at 08:04 +0000, Jan Beulich wrote:
> > >> 
> > >> > I got the impression they wanted some new .pack format or so?
> > >> > Or is the format that they were talking about exactly what you
> > >> picked?
> > >> 
> > >> I merely picked the binary formats that are already in use; I see no
> > >> reason to invent another one. 
> > > 
> > > Adding a header/magic number so you can detect which of the blobs is
> > > microcode?
> > 
> > This is precisely what I did *not* want to do.
> 
> Well, AFAICR, we talked about using the setup_data linked list in
> the user-mode kernel header and since parse_setup_data() looks at
> data->type, then probably something should state the type of the ucode
> image, but I'm not sure on the details.
> 
> FWIW, hpa mentioned at KS he already has some code doing early ucode
> loading so I'll let him chime in here. He's away this week though so it
> could take a while.

ping?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 16:44:25 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 16:44:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaVSZ-0006AZ-O0; Tue, 13 Dec 2011 16:44:07 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1RaVSX-0006AU-Jy
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 16:44:05 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-7.tower-174.messagelabs.com!1323794589!5406692!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22274 invoked from network); 13 Dec 2011 16:43:11 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-7.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 13 Dec 2011 16:43:11 -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
	pBDGgRfF009500
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Tue, 13 Dec 2011 11:42:27 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pBDGgQ4t009498;
	Tue, 13 Dec 2011 11:42:26 -0500
Date: Tue, 13 Dec 2011 12:42:26 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Borislav Petkov <bp@amd64.org>, hpa@zytor.com
Message-ID: <20111213164226.GA9081@andromeda.dapyr.net>
References: <4ED6676F02000078000646BC@nat28.tlf.novell.com>
	<20111130222359.GC16651@andromeda.dapyr.net>
	<4ED7433A0200007800064903@nat28.tlf.novell.com>
	<1322733358.31810.174.camel@zakaz.uk.xensource.com>
	<4ED75EB202000078000649E9@nat28.tlf.novell.com>
	<20111201103808.GB31552@aftab>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20111201103808.GB31552@aftab>
User-Agent: Mutt/1.5.9i
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Jan Beulich <JBeulich@suse.com>, "hpa@zytor.com" <hpa@zytor.com>
Subject: Re: [Xen-devel] [PATCH 2/2] x86/microcode: enable boot time
	(pre-Dom0) loading
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Dec 01, 2011 at 11:38:08AM +0100, Borislav Petkov wrote:
> On Thu, Dec 01, 2011 at 10:02:10AM +0000, Jan Beulich wrote:
> > >>> On 01.12.11 at 10:55, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > > On Thu, 2011-12-01 at 08:04 +0000, Jan Beulich wrote:
> > >> 
> > >> > I got the impression they wanted some new .pack format or so?
> > >> > Or is the format that they were talking about exactly what you
> > >> picked?
> > >> 
> > >> I merely picked the binary formats that are already in use; I see no
> > >> reason to invent another one. 
> > > 
> > > Adding a header/magic number so you can detect which of the blobs is
> > > microcode?
> > 
> > This is precisely what I did *not* want to do.
> 
> Well, AFAICR, we talked about using the setup_data linked list in
> the user-mode kernel header and since parse_setup_data() looks at
> data->type, then probably something should state the type of the ucode
> image, but I'm not sure on the details.
> 
> FWIW, hpa mentioned at KS he already has some code doing early ucode
> loading so I'll let him chime in here. He's away this week though so it
> could take a while.

ping?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 17:10:32 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 17:10:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaVrm-0006vB-Rt; Tue, 13 Dec 2011 17:10:10 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RaVrl-0006ub-C1
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 17:10:10 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1323796152!8064511!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjAzMzQ=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10103 invoked from network); 13 Dec 2011 17:09: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;
	13 Dec 2011 17:09:13 -0000
X-IronPort-AV: E=Sophos;i="4.71,346,1320642000"; d="scan'208";a="173979414"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Dec 2011 12:09:12 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Tue, 13 Dec 2011 12:09:11 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pBDH9A8G028289;	Tue, 13 Dec 2011 09:09:10 -0800
MIME-Version: 1.0
X-Mercurial-Node: 738c34b1b0450724c4b91b739d1e9cae09f26035
Message-ID: <738c34b1b0450724c4b9.1323796149@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Tue, 13 Dec 2011 17:09:09 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH] libxl: remove stubdom device model save file
 when destroying stubdom
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1323795995 0
# Node ID 738c34b1b0450724c4b91b739d1e9cae09f26035
# Parent  47606788dec2f110aecf5b356b250d65343070ac
libxl: remove stubdom device model save file when destroying stubdom

/var/lib/xen/qemu-save.<domid> is created when the stub domain is started
(connected to a stubdom console) and is used to save the device model state on
suspend/migrate but never cleaned up.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 47606788dec2 -r 738c34b1b045 tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Tue Dec 13 16:24:17 2011 +0000
+++ b/tools/libxl/libxl_dm.c	Tue Dec 13 17:06:35 2011 +0000
@@ -36,6 +36,11 @@ static const char *libxl_tapif_script(li
 #endif
 }
 
+const char *libxl__device_model_savefile(libxl__gc *gc, uint32_t domid)
+{
+    return libxl__sprintf(gc, "/var/lib/xen/qemu-save.%d", domid);
+}
+
 const char *libxl__domain_device_model(libxl__gc *gc,
                                        libxl_device_model_info *info)
 {
@@ -721,7 +726,8 @@ retry_transaction:
                 free(filename);
                 break;
             case STUBDOM_CONSOLE_SAVE:
-                console[i].output = libxl__sprintf(gc, "file:"SAVEFILE".%d", info->domid);
+                console[i].output = libxl__sprintf(gc, "file:%s",
+                                libxl__device_model_savefile(gc, info->domid));
                 break;
             case STUBDOM_CONSOLE_RESTORE:
                 if (info->saved_state)
@@ -924,6 +930,8 @@ int libxl__destroy_device_model(libxl__g
     pid = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "/local/domain/%d/image/device-model-pid", domid));
     if (!pid) {
         int stubdomid = libxl_get_stubdom_id(ctx, domid);
+        const char *savefile;
+
         if (!stubdomid) {
             LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "Couldn't find device model's pid");
             ret = ERROR_INVAL;
@@ -933,6 +941,20 @@ int libxl__destroy_device_model(libxl__g
         ret = libxl_domain_destroy(ctx, stubdomid, 0);
         if (ret)
             goto out;
+
+        savefile = libxl__device_model_savefile(gc, domid);
+        ret = unlink(savefile);
+        /*
+         * On suspend libxl__domain_save_device_model will have already
+         * unlinked the save file.
+         */
+        if (ret && errno == ENOENT) ret = 0;
+        if (ret) {
+            LIBXL__LOG_ERRNO(ctx, XTL_ERROR,
+                             "failed to remove device-model savefile %s\n",
+                             savefile);
+            goto out;
+        }
     } else {
         ret = kill(atoi(pid), SIGHUP);
         if (ret < 0 && errno == ESRCH) {
diff -r 47606788dec2 -r 738c34b1b045 tools/libxl/libxl_dom.c
--- a/tools/libxl/libxl_dom.c	Tue Dec 13 16:24:17 2011 +0000
+++ b/tools/libxl/libxl_dom.c	Tue Dec 13 17:06:35 2011 +0000
@@ -607,7 +607,7 @@ int libxl__domain_save_device_model(libx
     libxl_ctx *ctx = libxl__gc_owner(gc);
     int fd2, c;
     char buf[1024];
-    char *filename = libxl__sprintf(gc, "/var/lib/xen/qemu-save.%d", domid);
+    const char *filename = libxl__device_model_savefile(gc, domid);
     struct stat st;
     uint32_t qemu_state_len;
 
diff -r 47606788dec2 -r 738c34b1b045 tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Tue Dec 13 16:24:17 2011 +0000
+++ b/tools/libxl/libxl_internal.h	Tue Dec 13 17:06:35 2011 +0000
@@ -59,7 +59,6 @@
 #define STUBDOM_CONSOLE_RESTORE 2
 #define STUBDOM_CONSOLE_SERIAL 3
 #define STUBDOM_SPECIAL_CONSOLES 3
-#define SAVEFILE "/var/lib/xen/qemu-save"
 
 #define ARRAY_SIZE(a) (sizeof(a) / sizeof(a[0]))
 
@@ -244,6 +243,7 @@ _hidden int libxl__domain_restore_common
 _hidden int libxl__domain_suspend_common(libxl__gc *gc, uint32_t domid, int fd,
                                          libxl_domain_type type,
                                          int live, int debug);
+_hidden const char *libxl__device_model_savefile(libxl__gc *gc, uint32_t domid);
 _hidden int libxl__domain_save_device_model(libxl__gc *gc, uint32_t domid, int fd);
 _hidden void libxl__userdata_destroyall(libxl__gc *gc, uint32_t domid);
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 17:10:32 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 17:10:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaVrm-0006vB-Rt; Tue, 13 Dec 2011 17:10:10 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RaVrl-0006ub-C1
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 17:10:10 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1323796152!8064511!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjAzMzQ=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10103 invoked from network); 13 Dec 2011 17:09: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;
	13 Dec 2011 17:09:13 -0000
X-IronPort-AV: E=Sophos;i="4.71,346,1320642000"; d="scan'208";a="173979414"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Dec 2011 12:09:12 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Tue, 13 Dec 2011 12:09:11 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pBDH9A8G028289;	Tue, 13 Dec 2011 09:09:10 -0800
MIME-Version: 1.0
X-Mercurial-Node: 738c34b1b0450724c4b91b739d1e9cae09f26035
Message-ID: <738c34b1b0450724c4b9.1323796149@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Tue, 13 Dec 2011 17:09:09 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH] libxl: remove stubdom device model save file
 when destroying stubdom
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1323795995 0
# Node ID 738c34b1b0450724c4b91b739d1e9cae09f26035
# Parent  47606788dec2f110aecf5b356b250d65343070ac
libxl: remove stubdom device model save file when destroying stubdom

/var/lib/xen/qemu-save.<domid> is created when the stub domain is started
(connected to a stubdom console) and is used to save the device model state on
suspend/migrate but never cleaned up.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 47606788dec2 -r 738c34b1b045 tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Tue Dec 13 16:24:17 2011 +0000
+++ b/tools/libxl/libxl_dm.c	Tue Dec 13 17:06:35 2011 +0000
@@ -36,6 +36,11 @@ static const char *libxl_tapif_script(li
 #endif
 }
 
+const char *libxl__device_model_savefile(libxl__gc *gc, uint32_t domid)
+{
+    return libxl__sprintf(gc, "/var/lib/xen/qemu-save.%d", domid);
+}
+
 const char *libxl__domain_device_model(libxl__gc *gc,
                                        libxl_device_model_info *info)
 {
@@ -721,7 +726,8 @@ retry_transaction:
                 free(filename);
                 break;
             case STUBDOM_CONSOLE_SAVE:
-                console[i].output = libxl__sprintf(gc, "file:"SAVEFILE".%d", info->domid);
+                console[i].output = libxl__sprintf(gc, "file:%s",
+                                libxl__device_model_savefile(gc, info->domid));
                 break;
             case STUBDOM_CONSOLE_RESTORE:
                 if (info->saved_state)
@@ -924,6 +930,8 @@ int libxl__destroy_device_model(libxl__g
     pid = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "/local/domain/%d/image/device-model-pid", domid));
     if (!pid) {
         int stubdomid = libxl_get_stubdom_id(ctx, domid);
+        const char *savefile;
+
         if (!stubdomid) {
             LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "Couldn't find device model's pid");
             ret = ERROR_INVAL;
@@ -933,6 +941,20 @@ int libxl__destroy_device_model(libxl__g
         ret = libxl_domain_destroy(ctx, stubdomid, 0);
         if (ret)
             goto out;
+
+        savefile = libxl__device_model_savefile(gc, domid);
+        ret = unlink(savefile);
+        /*
+         * On suspend libxl__domain_save_device_model will have already
+         * unlinked the save file.
+         */
+        if (ret && errno == ENOENT) ret = 0;
+        if (ret) {
+            LIBXL__LOG_ERRNO(ctx, XTL_ERROR,
+                             "failed to remove device-model savefile %s\n",
+                             savefile);
+            goto out;
+        }
     } else {
         ret = kill(atoi(pid), SIGHUP);
         if (ret < 0 && errno == ESRCH) {
diff -r 47606788dec2 -r 738c34b1b045 tools/libxl/libxl_dom.c
--- a/tools/libxl/libxl_dom.c	Tue Dec 13 16:24:17 2011 +0000
+++ b/tools/libxl/libxl_dom.c	Tue Dec 13 17:06:35 2011 +0000
@@ -607,7 +607,7 @@ int libxl__domain_save_device_model(libx
     libxl_ctx *ctx = libxl__gc_owner(gc);
     int fd2, c;
     char buf[1024];
-    char *filename = libxl__sprintf(gc, "/var/lib/xen/qemu-save.%d", domid);
+    const char *filename = libxl__device_model_savefile(gc, domid);
     struct stat st;
     uint32_t qemu_state_len;
 
diff -r 47606788dec2 -r 738c34b1b045 tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Tue Dec 13 16:24:17 2011 +0000
+++ b/tools/libxl/libxl_internal.h	Tue Dec 13 17:06:35 2011 +0000
@@ -59,7 +59,6 @@
 #define STUBDOM_CONSOLE_RESTORE 2
 #define STUBDOM_CONSOLE_SERIAL 3
 #define STUBDOM_SPECIAL_CONSOLES 3
-#define SAVEFILE "/var/lib/xen/qemu-save"
 
 #define ARRAY_SIZE(a) (sizeof(a) / sizeof(a[0]))
 
@@ -244,6 +243,7 @@ _hidden int libxl__domain_restore_common
 _hidden int libxl__domain_suspend_common(libxl__gc *gc, uint32_t domid, int fd,
                                          libxl_domain_type type,
                                          int live, int debug);
+_hidden const char *libxl__device_model_savefile(libxl__gc *gc, uint32_t domid);
 _hidden int libxl__domain_save_device_model(libxl__gc *gc, uint32_t domid, int fd);
 _hidden void libxl__userdata_destroyall(libxl__gc *gc, uint32_t domid);
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 17:10:35 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 17: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.xensource.com>)
	id 1RaVrs-0006vp-8p; Tue, 13 Dec 2011 17:10:16 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RaVrq-0006ux-7t
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 17:10:14 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1323796158!7045278!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDUzNzY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29063 invoked from network); 13 Dec 2011 17:09:19 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 17:09:19 -0000
X-IronPort-AV: E=Sophos;i="4.71,346,1320642000"; d="scan'208";a="19926321"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Dec 2011 12:09:17 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Tue, 13 Dec 2011 12:09:17 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pBDH9Grs028292;	Tue, 13 Dec 2011 09:09:16 -0800
MIME-Version: 1.0
X-Mercurial-Node: 64e48ae2ef6760db221fe1896f7571260b0fd6ba
Message-ID: <64e48ae2ef6760db221f.1323796155@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Tue, 13 Dec 2011 17:09:15 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH] libxl: improve error handling when saving
	device model state
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1323795995 0
# Node ID 64e48ae2ef6760db221fe1896f7571260b0fd6ba
# Parent  738c34b1b0450724c4b91b739d1e9cae09f26035
libxl: improve error handling when saving device model state.

Do not leak a file descriptor (fd2 when used with upstream qemu) or a file (the
save file which is leaked on failure).

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 738c34b1b045 -r 64e48ae2ef67 tools/libxl/libxl_dom.c
--- a/tools/libxl/libxl_dom.c	Tue Dec 13 17:06:35 2011 +0000
+++ b/tools/libxl/libxl_dom.c	Tue Dec 13 17:06:35 2011 +0000
@@ -605,7 +605,7 @@ out:
 int libxl__domain_save_device_model(libxl__gc *gc, uint32_t domid, int fd)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
-    int fd2, c;
+    int ret, fd2, c;
     char buf[1024];
     const char *filename = libxl__device_model_savefile(gc, domid);
     struct stat st;
@@ -630,8 +630,10 @@ int libxl__domain_save_device_model(libx
             return ERROR_FAIL;
         }
         /* Save DM state into fd2 */
-        if (libxl__qmp_migrate(gc, domid, fd2))
-            return ERROR_FAIL;
+        ret = libxl__qmp_migrate(gc, domid, fd2);
+        close(fd2);
+        if (ret)
+            goto out_unlink;
         break;
     default:
         return ERROR_INVAL;
@@ -646,31 +648,35 @@ int libxl__domain_save_device_model(libx
     qemu_state_len = st.st_size;
     LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Qemu state is %d bytes\n", qemu_state_len);
 
-    c = libxl_write_exactly(ctx, fd, QEMU_SIGNATURE, strlen(QEMU_SIGNATURE),
-                            "saved-state file", "qemu signature");
-    if (c)
-        return c;
+    ret = libxl_write_exactly(ctx, fd, QEMU_SIGNATURE, strlen(QEMU_SIGNATURE),
+                              "saved-state file", "qemu signature");
+    if (ret)
+        goto out_unlink;
 
-    c = libxl_write_exactly(ctx, fd, &qemu_state_len, sizeof(qemu_state_len),
+    ret = libxl_write_exactly(ctx, fd, &qemu_state_len, sizeof(qemu_state_len),
                             "saved-state file", "saved-state length");
-    if (c)
-        return c;
+    if (ret)
+        goto out_unlink;
 
     fd2 = open(filename, O_RDONLY);
     while ((c = read(fd2, buf, sizeof(buf))) != 0) {
         if (c < 0) {
             if (errno == EINTR)
                 continue;
-            return errno;
+            ret = errno;
+            goto out_close_fd2;
         }
-        c = libxl_write_exactly(
+        ret = libxl_write_exactly(
             ctx, fd, buf, c, "saved-state file", "qemu state");
-        if (c)
-            return c;
+        if (ret)
+            goto out_close_fd2;
     }
+    ret = 0;
+out_close_fd2:
     close(fd2);
+out_unlink:
     unlink(filename);
-    return 0;
+    return ret;
 }
 
 char *libxl__uuid2string(libxl__gc *gc, const libxl_uuid uuid)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 17:10:35 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 17: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.xensource.com>)
	id 1RaVrs-0006vp-8p; Tue, 13 Dec 2011 17:10:16 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RaVrq-0006ux-7t
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 17:10:14 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1323796158!7045278!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDUzNzY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29063 invoked from network); 13 Dec 2011 17:09:19 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 17:09:19 -0000
X-IronPort-AV: E=Sophos;i="4.71,346,1320642000"; d="scan'208";a="19926321"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Dec 2011 12:09:17 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Tue, 13 Dec 2011 12:09:17 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pBDH9Grs028292;	Tue, 13 Dec 2011 09:09:16 -0800
MIME-Version: 1.0
X-Mercurial-Node: 64e48ae2ef6760db221fe1896f7571260b0fd6ba
Message-ID: <64e48ae2ef6760db221f.1323796155@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Tue, 13 Dec 2011 17:09:15 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH] libxl: improve error handling when saving
	device model state
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1323795995 0
# Node ID 64e48ae2ef6760db221fe1896f7571260b0fd6ba
# Parent  738c34b1b0450724c4b91b739d1e9cae09f26035
libxl: improve error handling when saving device model state.

Do not leak a file descriptor (fd2 when used with upstream qemu) or a file (the
save file which is leaked on failure).

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 738c34b1b045 -r 64e48ae2ef67 tools/libxl/libxl_dom.c
--- a/tools/libxl/libxl_dom.c	Tue Dec 13 17:06:35 2011 +0000
+++ b/tools/libxl/libxl_dom.c	Tue Dec 13 17:06:35 2011 +0000
@@ -605,7 +605,7 @@ out:
 int libxl__domain_save_device_model(libxl__gc *gc, uint32_t domid, int fd)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
-    int fd2, c;
+    int ret, fd2, c;
     char buf[1024];
     const char *filename = libxl__device_model_savefile(gc, domid);
     struct stat st;
@@ -630,8 +630,10 @@ int libxl__domain_save_device_model(libx
             return ERROR_FAIL;
         }
         /* Save DM state into fd2 */
-        if (libxl__qmp_migrate(gc, domid, fd2))
-            return ERROR_FAIL;
+        ret = libxl__qmp_migrate(gc, domid, fd2);
+        close(fd2);
+        if (ret)
+            goto out_unlink;
         break;
     default:
         return ERROR_INVAL;
@@ -646,31 +648,35 @@ int libxl__domain_save_device_model(libx
     qemu_state_len = st.st_size;
     LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Qemu state is %d bytes\n", qemu_state_len);
 
-    c = libxl_write_exactly(ctx, fd, QEMU_SIGNATURE, strlen(QEMU_SIGNATURE),
-                            "saved-state file", "qemu signature");
-    if (c)
-        return c;
+    ret = libxl_write_exactly(ctx, fd, QEMU_SIGNATURE, strlen(QEMU_SIGNATURE),
+                              "saved-state file", "qemu signature");
+    if (ret)
+        goto out_unlink;
 
-    c = libxl_write_exactly(ctx, fd, &qemu_state_len, sizeof(qemu_state_len),
+    ret = libxl_write_exactly(ctx, fd, &qemu_state_len, sizeof(qemu_state_len),
                             "saved-state file", "saved-state length");
-    if (c)
-        return c;
+    if (ret)
+        goto out_unlink;
 
     fd2 = open(filename, O_RDONLY);
     while ((c = read(fd2, buf, sizeof(buf))) != 0) {
         if (c < 0) {
             if (errno == EINTR)
                 continue;
-            return errno;
+            ret = errno;
+            goto out_close_fd2;
         }
-        c = libxl_write_exactly(
+        ret = libxl_write_exactly(
             ctx, fd, buf, c, "saved-state file", "qemu state");
-        if (c)
-            return c;
+        if (ret)
+            goto out_close_fd2;
     }
+    ret = 0;
+out_close_fd2:
     close(fd2);
+out_unlink:
     unlink(filename);
-    return 0;
+    return ret;
 }
 
 char *libxl__uuid2string(libxl__gc *gc, const libxl_uuid uuid)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 17:10:36 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 17:10:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaVrv-0006wF-LQ; Tue, 13 Dec 2011 17:10:19 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <amscanne@gridcentric.ca>) id 1RaVru-0006vS-Bo
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 17:10:18 +0000
X-Env-Sender: amscanne@gridcentric.ca
X-Msg-Ref: server-13.tower-174.messagelabs.com!1323796163!5401476!1
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24674 invoked from network); 13 Dec 2011 17:09:23 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 17:09:23 -0000
Received: by wgbds11 with SMTP id ds11so12121795wgb.24
	for <xen-devel@lists.xensource.com>;
	Tue, 13 Dec 2011 09:09:23 -0800 (PST)
Received: by 10.227.198.142 with SMTP id eo14mr17115240wbb.28.1323796163197;
	Tue, 13 Dec 2011 09:09:23 -0800 (PST)
MIME-Version: 1.0
Received: by 10.223.120.68 with HTTP; Tue, 13 Dec 2011 09:08:52 -0800 (PST)
In-Reply-To: <a221d43997a6992363f8690a30d0ac9c.squirrel@webmail.lagarcavilla.org>
References: <patchbomb.1323472550@xdev.gridcentric.ca>
	<6e8b8fb2c8b23e39d910.1323472555@xdev.gridcentric.ca>
	<1323686356.20077.133.camel@zakaz.uk.xensource.com>
	<a221d43997a6992363f8690a30d0ac9c.squirrel@webmail.lagarcavilla.org>
From: Adin Scannell <adin@gridcentric.ca>
Date: Tue, 13 Dec 2011 12:08:52 -0500
X-Google-Sender-Auth: GC5yTZsun6ZmEWXo_8Rp3e-jgiY
Message-ID: <CAAJKtqqmVCyMfAO8iYOuUAnbwFEzoMB0=_fUv5fxpvi2w4tTbg@mail.gmail.com>
To: andres@lagarcavilla.org
Cc: Ian Jackson <ian.jackson@eu.citrix.com>,
	"andres@gridcentric.ca" <andres@gridcentric.ca>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Tim \(Xen.org\)" <tim@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH 5 of 8] Tools: Expose to libxc the total
 number of shared frames and space saved
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Dec 12, 2011 at 10:43 PM, Andres Lagar-Cavilla
<andres@lagarcavilla.org> wrote:
> used_frames indicates the number of frames of memory that are shared,
> each, by two or more domains. We use the term "frame" because it's
> commonly used in textbooks for MMUs, in the sense that "a frame hosts a
> page" or "a page maps to a frame". Thus our use of shared frames,
> representing a different page (albeit with identical contents) to
> different domains.

As Andres has pointed out, I named it frames to clearly differentiate
it from other page-based domctls (it worked!).  With the unusual
condition of multiple domains pointing to the same frame, the
nomenclature gets a bit hairy.  Any suggestions on this front?

> freed_pages indicates the number of individual pages freed as a result of
> sharing. These are pages, one per domain.

Here's a quick explanation and reason for these stats:

The way I see it, there are three easy-to-track, non-historical stats
about sharing.
X - The total number of domain pages that map to shared frames.
Y - The number of frames saved with sharing.
Z - The total number of shared frames (i.e. pages owned by dom_cow).

Any two of these will give you the third (via X = Y + Z).  In this
case, we used Y & Z because I think that they are the simplest to
reason about (and therefore the most likely to be wanted).  An
argument could easily be made for others though, if someone feels
strongly.

There are certainly some historical stats (# of unshares, etc.) and
lots of per-page/frame stats that would be of interest as well. But,
bit by bit...

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 17:10:36 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 17:10:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaVrv-0006wF-LQ; Tue, 13 Dec 2011 17:10:19 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <amscanne@gridcentric.ca>) id 1RaVru-0006vS-Bo
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 17:10:18 +0000
X-Env-Sender: amscanne@gridcentric.ca
X-Msg-Ref: server-13.tower-174.messagelabs.com!1323796163!5401476!1
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24674 invoked from network); 13 Dec 2011 17:09:23 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 17:09:23 -0000
Received: by wgbds11 with SMTP id ds11so12121795wgb.24
	for <xen-devel@lists.xensource.com>;
	Tue, 13 Dec 2011 09:09:23 -0800 (PST)
Received: by 10.227.198.142 with SMTP id eo14mr17115240wbb.28.1323796163197;
	Tue, 13 Dec 2011 09:09:23 -0800 (PST)
MIME-Version: 1.0
Received: by 10.223.120.68 with HTTP; Tue, 13 Dec 2011 09:08:52 -0800 (PST)
In-Reply-To: <a221d43997a6992363f8690a30d0ac9c.squirrel@webmail.lagarcavilla.org>
References: <patchbomb.1323472550@xdev.gridcentric.ca>
	<6e8b8fb2c8b23e39d910.1323472555@xdev.gridcentric.ca>
	<1323686356.20077.133.camel@zakaz.uk.xensource.com>
	<a221d43997a6992363f8690a30d0ac9c.squirrel@webmail.lagarcavilla.org>
From: Adin Scannell <adin@gridcentric.ca>
Date: Tue, 13 Dec 2011 12:08:52 -0500
X-Google-Sender-Auth: GC5yTZsun6ZmEWXo_8Rp3e-jgiY
Message-ID: <CAAJKtqqmVCyMfAO8iYOuUAnbwFEzoMB0=_fUv5fxpvi2w4tTbg@mail.gmail.com>
To: andres@lagarcavilla.org
Cc: Ian Jackson <ian.jackson@eu.citrix.com>,
	"andres@gridcentric.ca" <andres@gridcentric.ca>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Tim \(Xen.org\)" <tim@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH 5 of 8] Tools: Expose to libxc the total
 number of shared frames and space saved
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Dec 12, 2011 at 10:43 PM, Andres Lagar-Cavilla
<andres@lagarcavilla.org> wrote:
> used_frames indicates the number of frames of memory that are shared,
> each, by two or more domains. We use the term "frame" because it's
> commonly used in textbooks for MMUs, in the sense that "a frame hosts a
> page" or "a page maps to a frame". Thus our use of shared frames,
> representing a different page (albeit with identical contents) to
> different domains.

As Andres has pointed out, I named it frames to clearly differentiate
it from other page-based domctls (it worked!).  With the unusual
condition of multiple domains pointing to the same frame, the
nomenclature gets a bit hairy.  Any suggestions on this front?

> freed_pages indicates the number of individual pages freed as a result of
> sharing. These are pages, one per domain.

Here's a quick explanation and reason for these stats:

The way I see it, there are three easy-to-track, non-historical stats
about sharing.
X - The total number of domain pages that map to shared frames.
Y - The number of frames saved with sharing.
Z - The total number of shared frames (i.e. pages owned by dom_cow).

Any two of these will give you the third (via X = Y + Z).  In this
case, we used Y & Z because I think that they are the simplest to
reason about (and therefore the most likely to be wanted).  An
argument could easily be made for others though, if someone feels
strongly.

There are certainly some historical stats (# of unshares, etc.) and
lots of per-page/frame stats that would be of interest as well. But,
bit by bit...

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 17:12:16 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 17:12:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaVta-0007BM-6S; Tue, 13 Dec 2011 17:12:02 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RaVtZ-0007AR-57
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 17:12:01 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1323796266!7915016!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTI1NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3301 invoked from network); 13 Dec 2011 17:11:06 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 17:11:06 -0000
X-IronPort-AV: E=Sophos;i="4.71,346,1320624000"; 
   d="scan'208";a="9447230"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Dec 2011 17:11:05 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 13 Dec 2011 17:11:05 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Tue, 13 Dec 2011 17:11:05 +0000
In-Reply-To: <e0f020d3d812e00aeb0c.1323793470@cosworth.uk.xensource.com>
References: <patchbomb.1323793468@cosworth.uk.xensource.com>
	<e0f020d3d812e00aeb0c.1323793470@cosworth.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323796265.20077.341.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 2 of 3] libxl: split libxl_domain_shutdown
 into libxl_domain_shutdown & libxl_domain_reboot
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2011-12-13 at 16:24 +0000, Ian Campbell wrote:
> # HG changeset patch
> # User Ian Campbell <ian.campbell@citrix.com>
> # Date 1323793444 0
> # Node ID e0f020d3d812e00aeb0c271a9627206279da3964
> # Parent  97677918e3a4c8e724d7c8a6aba9cec570400c99
> libxl: split libxl_domain_shutdown into libxl_domain_shutdown & libxl_domain_reboot
> 
> The other integer request types which shutdown supported are not useful. Specifically:
> 
>  * "suspend" is not usable via this interface since it requires other
>    scaffolding, libxl_domain_suspend provides this already.
>  * "halt" is the same as "poweroff".
>  * "crash" is unused and at least Linux does not implement it. If a user
>    steps forward then libxl_domain_crash is trivial to add.
> 

I forgot to build test the language bindings and of course this broke
them. Please stand by for an updated patch.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 17:12:16 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 17:12:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaVta-0007BM-6S; Tue, 13 Dec 2011 17:12:02 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RaVtZ-0007AR-57
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 17:12:01 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1323796266!7915016!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTI1NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3301 invoked from network); 13 Dec 2011 17:11:06 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 17:11:06 -0000
X-IronPort-AV: E=Sophos;i="4.71,346,1320624000"; 
   d="scan'208";a="9447230"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Dec 2011 17:11:05 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 13 Dec 2011 17:11:05 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Tue, 13 Dec 2011 17:11:05 +0000
In-Reply-To: <e0f020d3d812e00aeb0c.1323793470@cosworth.uk.xensource.com>
References: <patchbomb.1323793468@cosworth.uk.xensource.com>
	<e0f020d3d812e00aeb0c.1323793470@cosworth.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323796265.20077.341.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 2 of 3] libxl: split libxl_domain_shutdown
 into libxl_domain_shutdown & libxl_domain_reboot
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2011-12-13 at 16:24 +0000, Ian Campbell wrote:
> # HG changeset patch
> # User Ian Campbell <ian.campbell@citrix.com>
> # Date 1323793444 0
> # Node ID e0f020d3d812e00aeb0c271a9627206279da3964
> # Parent  97677918e3a4c8e724d7c8a6aba9cec570400c99
> libxl: split libxl_domain_shutdown into libxl_domain_shutdown & libxl_domain_reboot
> 
> The other integer request types which shutdown supported are not useful. Specifically:
> 
>  * "suspend" is not usable via this interface since it requires other
>    scaffolding, libxl_domain_suspend provides this already.
>  * "halt" is the same as "poweroff".
>  * "crash" is unused and at least Linux does not implement it. If a user
>    steps forward then libxl_domain_crash is trivial to add.
> 

I forgot to build test the language bindings and of course this broke
them. Please stand by for an updated patch.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 17:15:20 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 17:15:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaVwU-0007Us-Q4; Tue, 13 Dec 2011 17:15:02 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <amscanne@gridcentric.ca>) id 1RaVwS-0007UJ-DA
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 17:15:00 +0000
X-Env-Sender: amscanne@gridcentric.ca
X-Msg-Ref: server-6.tower-182.messagelabs.com!1323796445!7107360!1
X-Originating-IP: [209.85.161.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23690 invoked from network); 13 Dec 2011 17:14:05 -0000
Received: from mail-fx0-f43.google.com (HELO mail-fx0-f43.google.com)
	(209.85.161.43)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 17:14:05 -0000
Received: by faap21 with SMTP id p21so622539faa.30
	for <xen-devel@lists.xensource.com>;
	Tue, 13 Dec 2011 09:14:05 -0800 (PST)
Received: by 10.216.158.73 with SMTP id p51mr3040453wek.0.1323796445316; Tue,
	13 Dec 2011 09:14:05 -0800 (PST)
MIME-Version: 1.0
Received: by 10.223.120.68 with HTTP; Tue, 13 Dec 2011 09:13:44 -0800 (PST)
In-Reply-To: <1323686627.20077.137.camel@zakaz.uk.xensource.com>
References: <patchbomb.1323472550@xdev.gridcentric.ca>
	<3fc7875c8d98cbc74598.1323472556@xdev.gridcentric.ca>
	<1323686627.20077.137.camel@zakaz.uk.xensource.com>
From: Adin Scannell <adin@gridcentric.ca>
Date: Tue, 13 Dec 2011 12:13:44 -0500
X-Google-Sender-Auth: miPeXKjOxUAVDhTuS2ERIjUkU78
Message-ID: <CAAJKtqq7fJWCtdNVd0vO1xekQoq+AzKaFHOyQw=iUOLcP2LRSw@mail.gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"andres@gridcentric.ca" <andres@gridcentric.ca>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Tim \(Xen.org\)" <tim@xen.org>,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>
Subject: Re: [Xen-devel] [PATCH 6 of 8] Tools: Allow libxl/xl to expose the
 total number of shared frames and space saved
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Dec 12, 2011 at 5:43 AM, Ian Campbell <Ian.Campbell@citrix.com> wro=
te:
> On Fri, 2011-12-09 at 23:15 +0000, Andres Lagar-Cavilla wrote:
>> diff -r 6e8b8fb2c8b2 -r 3fc7875c8d98 tools/libxl/libxl.h
>> --- a/tools/libxl/libxl.h
>> +++ b/tools/libxl/libxl.h
>> @@ -350,6 +350,9 @@ int libxl_domain_rename(libxl_ctx *ctx,
>> =A0int libxl_domain_pause(libxl_ctx *ctx, uint32_t domid);
>> =A0int libxl_domain_unpause(libxl_ctx *ctx, uint32_t domid);
>>
>> +long libxl_sharing_used_frames(libxl_ctx *ctx);
>> +long libxl_sharing_freed_pages(libxl_ctx *ctx);
>
> I'm undecided but perhaps it would be appropriate to add these to
> libxl_physinfo? In which case the output of "xl physinfo" or "xl info"
> would be a nice home for these. Or perhaps a new meminfo or hostinfo
> struct?

Sure, libxl_physinfo makes sense.

Cheers!
-Adin

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 17:15:20 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 17:15:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaVwU-0007Us-Q4; Tue, 13 Dec 2011 17:15:02 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <amscanne@gridcentric.ca>) id 1RaVwS-0007UJ-DA
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 17:15:00 +0000
X-Env-Sender: amscanne@gridcentric.ca
X-Msg-Ref: server-6.tower-182.messagelabs.com!1323796445!7107360!1
X-Originating-IP: [209.85.161.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23690 invoked from network); 13 Dec 2011 17:14:05 -0000
Received: from mail-fx0-f43.google.com (HELO mail-fx0-f43.google.com)
	(209.85.161.43)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 17:14:05 -0000
Received: by faap21 with SMTP id p21so622539faa.30
	for <xen-devel@lists.xensource.com>;
	Tue, 13 Dec 2011 09:14:05 -0800 (PST)
Received: by 10.216.158.73 with SMTP id p51mr3040453wek.0.1323796445316; Tue,
	13 Dec 2011 09:14:05 -0800 (PST)
MIME-Version: 1.0
Received: by 10.223.120.68 with HTTP; Tue, 13 Dec 2011 09:13:44 -0800 (PST)
In-Reply-To: <1323686627.20077.137.camel@zakaz.uk.xensource.com>
References: <patchbomb.1323472550@xdev.gridcentric.ca>
	<3fc7875c8d98cbc74598.1323472556@xdev.gridcentric.ca>
	<1323686627.20077.137.camel@zakaz.uk.xensource.com>
From: Adin Scannell <adin@gridcentric.ca>
Date: Tue, 13 Dec 2011 12:13:44 -0500
X-Google-Sender-Auth: miPeXKjOxUAVDhTuS2ERIjUkU78
Message-ID: <CAAJKtqq7fJWCtdNVd0vO1xekQoq+AzKaFHOyQw=iUOLcP2LRSw@mail.gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"andres@gridcentric.ca" <andres@gridcentric.ca>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Tim \(Xen.org\)" <tim@xen.org>,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>
Subject: Re: [Xen-devel] [PATCH 6 of 8] Tools: Allow libxl/xl to expose the
 total number of shared frames and space saved
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Dec 12, 2011 at 5:43 AM, Ian Campbell <Ian.Campbell@citrix.com> wro=
te:
> On Fri, 2011-12-09 at 23:15 +0000, Andres Lagar-Cavilla wrote:
>> diff -r 6e8b8fb2c8b2 -r 3fc7875c8d98 tools/libxl/libxl.h
>> --- a/tools/libxl/libxl.h
>> +++ b/tools/libxl/libxl.h
>> @@ -350,6 +350,9 @@ int libxl_domain_rename(libxl_ctx *ctx,
>> =A0int libxl_domain_pause(libxl_ctx *ctx, uint32_t domid);
>> =A0int libxl_domain_unpause(libxl_ctx *ctx, uint32_t domid);
>>
>> +long libxl_sharing_used_frames(libxl_ctx *ctx);
>> +long libxl_sharing_freed_pages(libxl_ctx *ctx);
>
> I'm undecided but perhaps it would be appropriate to add these to
> libxl_physinfo? In which case the output of "xl physinfo" or "xl info"
> would be a nice home for these. Or perhaps a new meminfo or hostinfo
> struct?

Sure, libxl_physinfo makes sense.

Cheers!
-Adin

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 17:15:24 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 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.xensource.com>)
	id 1RaVwf-0007WB-76; Tue, 13 Dec 2011 17:15:13 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RaVwd-0007VG-Kz
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 17:15:11 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1323796457!8105453!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTI1NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22873 invoked from network); 13 Dec 2011 17:14:17 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 17:14:17 -0000
X-IronPort-AV: E=Sophos;i="4.71,346,1320624000"; 
   d="scan'208";a="9447283"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Dec 2011 17:14:17 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 13 Dec 2011 17:14:17 +0000
Date: Tue, 13 Dec 2011 17:16:01 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Jan Beulich <JBeulich@suse.com>
In-Reply-To: <4EE7672902000078000674D4@nat28.tlf.novell.com>
Message-ID: <alpine.DEB.2.00.1112131646150.3517@kaball-desktop>
References: <4EE7672902000078000674D4@nat28.tlf.novell.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] map_domain_emuirq_pirq() imbalance with
 unmap_domain_pirq_emuirq()?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 13 Dec 2011, Jan Beulich wrote:
> Hi Stefano,
> 
> in your patch to introduce pIRQ interrupt remapping for HVM guests,
> you have physdev_map_pirq() call unmap_domain_pirq_emuirq()

I take you mean physdev_unmap_pirq here.

> unconditionally in the HVM case, yet physdev_hvm_map_pirq() call
> map_domain_emuirq_pirq() only if no machine_gsi was found. I'm
> suspecting this to be the reason for pass-through device hot unplug
> resource leaks (leading eventually to hot plug failure on repeated
> attempts), as in this case it is my understanding that
> unmap_domain_pirq_emuirq() can only be expected to fail (for there
> not being an established mapping), leading to physdev_unmap_pirq()
> bailing out early.
> As it's not immediately clear whether using the same lookup approach
> that physdev_hvm_map_pirq() uses would be valid in the unmap path,
> I'm hoping for your advice how to address this problem. Is there
> perhaps a map_domain_emuirq_pirq(..., IRQ_PT) call missing?

I think I understand what the problem is: since 'xen: fix
hvm_domain_use_pirq's behavior' the pirq to emuirq mapping remains set
to IRQ_UNBOUND until an event channel has been bound to the pirq.
That means that if the guest is not binding any event channels at all,
the mapping remains IRQ_UNBOUND for the life of the VM.
Eventually when physdev_unmap_pirq gets called, nothing happens because
unmap_domain_pirq_emuirq keeps failing. This wasn't the original
behavior because it used to be the case that the mapping would always be
either IRQ_PT or a positive number.

A simple solution to this issue would be to introduce a check in
physdev_unmap_pirq:


diff --git a/xen/arch/x86/physdev.c b/xen/arch/x86/physdev.c
index cca56bb..c1a7fcc 100644
--- a/xen/arch/x86/physdev.c
+++ b/xen/arch/x86/physdev.c
@@ -216,14 +216,16 @@ int physdev_unmap_pirq(domid_t domid, int pirq)
     if ( ret )
         return ret;
 
-    if ( is_hvm_domain(d) )
+    if ( is_hvm_domain(d) && domain_pirq_to_emuirq(d, pirq) != IRQ_UNBOUND)
     {
         spin_lock(&d->event_lock);
         ret = unmap_domain_pirq_emuirq(d, pirq);
         spin_unlock(&d->event_lock);
-        if ( domid == DOMID_SELF || ret )
+        if ( ret )
             goto free_domain;
     }
+    if ( domid == DOMID_SELF )
+        goto free_domain;
 
     ret = -EPERM;
     if ( !IS_PRIV_FOR(current->domain, d) )


> Besides that, in 23806:4226ea1785b5 you move a call to
> map_domain_emuirq_pirq() from xen/arch/x86/physdev.c to
> xen/common/event_channel.c, but neither before nor after the patch
> the function's return value gets checked, yet the function has various
> ways to fail. Is failure here really benign?
 
No, it is not. We should return an error if map_domain_emuirq_pirq
fails.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 17:15:24 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 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.xensource.com>)
	id 1RaVwf-0007WB-76; Tue, 13 Dec 2011 17:15:13 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RaVwd-0007VG-Kz
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 17:15:11 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1323796457!8105453!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTI1NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22873 invoked from network); 13 Dec 2011 17:14:17 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 17:14:17 -0000
X-IronPort-AV: E=Sophos;i="4.71,346,1320624000"; 
   d="scan'208";a="9447283"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Dec 2011 17:14:17 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 13 Dec 2011 17:14:17 +0000
Date: Tue, 13 Dec 2011 17:16:01 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Jan Beulich <JBeulich@suse.com>
In-Reply-To: <4EE7672902000078000674D4@nat28.tlf.novell.com>
Message-ID: <alpine.DEB.2.00.1112131646150.3517@kaball-desktop>
References: <4EE7672902000078000674D4@nat28.tlf.novell.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] map_domain_emuirq_pirq() imbalance with
 unmap_domain_pirq_emuirq()?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 13 Dec 2011, Jan Beulich wrote:
> Hi Stefano,
> 
> in your patch to introduce pIRQ interrupt remapping for HVM guests,
> you have physdev_map_pirq() call unmap_domain_pirq_emuirq()

I take you mean physdev_unmap_pirq here.

> unconditionally in the HVM case, yet physdev_hvm_map_pirq() call
> map_domain_emuirq_pirq() only if no machine_gsi was found. I'm
> suspecting this to be the reason for pass-through device hot unplug
> resource leaks (leading eventually to hot plug failure on repeated
> attempts), as in this case it is my understanding that
> unmap_domain_pirq_emuirq() can only be expected to fail (for there
> not being an established mapping), leading to physdev_unmap_pirq()
> bailing out early.
> As it's not immediately clear whether using the same lookup approach
> that physdev_hvm_map_pirq() uses would be valid in the unmap path,
> I'm hoping for your advice how to address this problem. Is there
> perhaps a map_domain_emuirq_pirq(..., IRQ_PT) call missing?

I think I understand what the problem is: since 'xen: fix
hvm_domain_use_pirq's behavior' the pirq to emuirq mapping remains set
to IRQ_UNBOUND until an event channel has been bound to the pirq.
That means that if the guest is not binding any event channels at all,
the mapping remains IRQ_UNBOUND for the life of the VM.
Eventually when physdev_unmap_pirq gets called, nothing happens because
unmap_domain_pirq_emuirq keeps failing. This wasn't the original
behavior because it used to be the case that the mapping would always be
either IRQ_PT or a positive number.

A simple solution to this issue would be to introduce a check in
physdev_unmap_pirq:


diff --git a/xen/arch/x86/physdev.c b/xen/arch/x86/physdev.c
index cca56bb..c1a7fcc 100644
--- a/xen/arch/x86/physdev.c
+++ b/xen/arch/x86/physdev.c
@@ -216,14 +216,16 @@ int physdev_unmap_pirq(domid_t domid, int pirq)
     if ( ret )
         return ret;
 
-    if ( is_hvm_domain(d) )
+    if ( is_hvm_domain(d) && domain_pirq_to_emuirq(d, pirq) != IRQ_UNBOUND)
     {
         spin_lock(&d->event_lock);
         ret = unmap_domain_pirq_emuirq(d, pirq);
         spin_unlock(&d->event_lock);
-        if ( domid == DOMID_SELF || ret )
+        if ( ret )
             goto free_domain;
     }
+    if ( domid == DOMID_SELF )
+        goto free_domain;
 
     ret = -EPERM;
     if ( !IS_PRIV_FOR(current->domain, d) )


> Besides that, in 23806:4226ea1785b5 you move a call to
> map_domain_emuirq_pirq() from xen/arch/x86/physdev.c to
> xen/common/event_channel.c, but neither before nor after the patch
> the function's return value gets checked, yet the function has various
> ways to fail. Is failure here really benign?
 
No, it is not. We should return an error if map_domain_emuirq_pirq
fails.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 17:19:58 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 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.xensource.com>)
	id 1RaW11-0007vN-3y; Tue, 13 Dec 2011 17:19:43 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RaW10-0007v8-0o
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 17:19:42 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1323796727!7213466!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTI1NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8093 invoked from network); 13 Dec 2011 17:18:47 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 17:18:47 -0000
X-IronPort-AV: E=Sophos;i="4.71,346,1320624000"; 
   d="scan'208";a="9447360"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Dec 2011 17:18:27 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 13 Dec 2011 17:18:27 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Tue, 13 Dec 2011 17:18:27 +0000
In-Reply-To: <1323796265.20077.341.camel@zakaz.uk.xensource.com>
References: <patchbomb.1323793468@cosworth.uk.xensource.com>
	<e0f020d3d812e00aeb0c.1323793470@cosworth.uk.xensource.com>
	<1323796265.20077.341.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323796707.20077.346.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 2 of 3] libxl: split libxl_domain_shutdown
 into libxl_domain_shutdown & libxl_domain_reboot
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2011-12-13 at 17:11 +0000, Ian Campbell wrote:
> On Tue, 2011-12-13 at 16:24 +0000, Ian Campbell wrote:
> > # HG changeset patch
> > # User Ian Campbell <ian.campbell@citrix.com>
> > # Date 1323793444 0
> > # Node ID e0f020d3d812e00aeb0c271a9627206279da3964
> > # Parent  97677918e3a4c8e724d7c8a6aba9cec570400c99
> > libxl: split libxl_domain_shutdown into libxl_domain_shutdown & libxl_domain_reboot
> > 
> > The other integer request types which shutdown supported are not useful. Specifically:
> > 
> >  * "suspend" is not usable via this interface since it requires other
> >    scaffolding, libxl_domain_suspend provides this already.
> >  * "halt" is the same as "poweroff".
> >  * "crash" is unused and at least Linux does not implement it. If a user
> >    steps forward then libxl_domain_crash is trivial to add.
> > 
> 
> I forgot to build test the language bindings and of course this broke
> them. Please stand by for an updated patch.

8<------------------------------------------------------------

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1323796506 0
# Node ID c03b6bccb479740f7c70b96f4b1c0951dd70e615
# Parent  97677918e3a4c8e724d7c8a6aba9cec570400c99
libxl: split libxl_domain_shutdown into libxl_domain_shutdown & libxl_domain_reboot

The other integer request types which shutdown supported are not useful. Specifically:

 * "suspend" is not usable via this interface since it requires other
   scaffolding, libxl_domain_suspend provides this already.
 * "halt" is the same as "poweroff".
 * "crash" is unused and at least Linux does not implement it. If a user
   steps forward then libxl_domain_crash is trivial to add.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 97677918e3a4 -r c03b6bccb479 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Tue Dec 13 16:22:58 2011 +0000
+++ b/tools/libxl/libxl.c	Tue Dec 13 17:15:06 2011 +0000
@@ -594,36 +594,46 @@ int libxl__domain_pvcontrol_write(libxl_
     return libxl__xs_write(gc, t, shutdown_path, "%s", cmd);
 }
 
-static char *req_table[] = {
-    [0] = "poweroff",
-    [1] = "reboot",
-    [2] = "suspend",
-    [3] = "crash",
-    [4] = "halt",
-};
-
-int libxl_domain_shutdown(libxl_ctx *ctx, uint32_t domid, int req)
+int libxl_domain_shutdown(libxl_ctx *ctx, uint32_t domid)
 {
     GC_INIT(ctx);
     int ret;
 
-    if (req > ARRAY_SIZE(req_table)) {
-        GC_FREE;
-        return ERROR_INVAL;
-    }
-
     ret = libxl__domain_pvcontrol_available(gc, domid);
     if (ret < 0)
         goto out;
 
     if (!ret) {
-        LIBXL__LOG(CTX, LIBXL__LOG_ERROR, "PV shutdown control not available:"
+        LIBXL__LOG(CTX, LIBXL__LOG_ERROR, "PV control interface not available:"
                    " graceful shutdown not possible, use destroy");
         ret = ERROR_FAIL;
         goto out;
     }
 
-    ret = libxl__domain_pvcontrol_write(gc, XBT_NULL, domid, req_table[req]);
+    ret = libxl__domain_pvcontrol_write(gc, XBT_NULL, domid, "poweroff");
+
+out:
+    GC_FREE;
+    return ret;
+}
+
+int libxl_domain_reboot(libxl_ctx *ctx, uint32_t domid)
+{
+    GC_INIT(ctx);
+    int ret;
+
+    ret = libxl__domain_pvcontrol_available(gc, domid);
+    if (ret < 0)
+        goto out;
+
+    if (!ret) {
+        LIBXL__LOG(CTX, LIBXL__LOG_ERROR, "PV control interface not available:"
+                   " graceful reboot not possible, use destroy+create");
+        ret = ERROR_FAIL;
+        goto out;
+    }
+
+    ret = libxl__domain_pvcontrol_write(gc, XBT_NULL, domid, "reboot");
 
 out:
     GC_FREE;
diff -r 97677918e3a4 -r c03b6bccb479 tools/libxl/libxl.h
--- a/tools/libxl/libxl.h	Tue Dec 13 16:22:58 2011 +0000
+++ b/tools/libxl/libxl.h	Tue Dec 13 17:15:06 2011 +0000
@@ -268,7 +268,8 @@ void libxl_domain_config_dispose(libxl_d
 int libxl_domain_suspend(libxl_ctx *ctx, libxl_domain_suspend_info *info,
                           uint32_t domid, int fd);
 int libxl_domain_resume(libxl_ctx *ctx, uint32_t domid);
-int libxl_domain_shutdown(libxl_ctx *ctx, uint32_t domid, int req);
+int libxl_domain_shutdown(libxl_ctx *ctx, uint32_t domid);
+int libxl_domain_reboot(libxl_ctx *ctx, uint32_t domid);
 int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid, int force);
 int libxl_domain_preserve(libxl_ctx *ctx, uint32_t domid, libxl_domain_create_info *info, const char *name_suffix, libxl_uuid new_uuid);
 
diff -r 97677918e3a4 -r c03b6bccb479 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Tue Dec 13 16:22:58 2011 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Tue Dec 13 17:15:06 2011 +0000
@@ -2265,7 +2265,7 @@ static void shutdown_domain(const char *
     int rc;
 
     find_domain(p);
-    rc=libxl_domain_shutdown(ctx, domid, 0);
+    rc=libxl_domain_shutdown(ctx, domid);
     if (rc) { fprintf(stderr,"shutdown failed (rc=%d)\n",rc);exit(-1); }
 
     if (wait) {
@@ -2307,7 +2307,7 @@ static void reboot_domain(const char *p)
 {
     int rc;
     find_domain(p);
-    rc=libxl_domain_shutdown(ctx, domid, 1);
+    rc=libxl_domain_reboot(ctx, domid);
     if (rc) { fprintf(stderr,"reboot failed (rc=%d)\n",rc);exit(-1); }
 }
 
diff -r 97677918e3a4 -r c03b6bccb479 tools/python/xen/lowlevel/xl/xl.c
--- a/tools/python/xen/lowlevel/xl/xl.c	Tue Dec 13 16:22:58 2011 +0000
+++ b/tools/python/xen/lowlevel/xl/xl.c	Tue Dec 13 17:15:06 2011 +0000
@@ -424,10 +424,10 @@ static PyObject *pyxl_domid_to_name(XlOb
 
 static PyObject *pyxl_domain_shutdown(XlObject *self, PyObject *args)
 {
-    int domid, req = 0;
-    if ( !PyArg_ParseTuple(args, "i|i", &domid, &req) )
+    int domid;
+    if ( !PyArg_ParseTuple(args, "i", &domid) )
         return NULL;
-    if ( libxl_domain_shutdown(self->ctx, domid, req) ) {
+    if ( libxl_domain_shutdown(self->ctx, domid) ) {
         PyErr_SetString(xl_error_obj, "cannot shutdown domain");
         return NULL;
     }
@@ -435,6 +435,19 @@ static PyObject *pyxl_domain_shutdown(Xl
     return Py_None;
 }
 
+static PyObject *pyxl_domain_reboot(XlObject *self, PyObject *args)
+{
+    int domid;
+    if ( !PyArg_ParseTuple(args, "i", &domid) )
+        return NULL;
+    if ( libxl_domain_reboot(self->ctx, domid) ) {
+        PyErr_SetString(xl_error_obj, "cannot reboot domain");
+        return NULL;
+    }
+    Py_INCREF(Py_None);
+    return Py_None;
+}
+
 static PyObject *pyxl_domain_destroy(XlObject *self, PyObject *args)
 {
     int domid, force = 1;
@@ -637,6 +650,8 @@ static PyMethodDef pyxl_methods[] = {
          "Retrieve name from domain-id"},
     {"domain_shutdown", (PyCFunction)pyxl_domain_shutdown, METH_VARARGS,
          "Shutdown a domain"},
+    {"domain_reboot", (PyCFunction)pyxl_domain_reboot, METH_VARARGS,
+         "Reboot a domain"},
     {"domain_destroy", (PyCFunction)pyxl_domain_destroy, METH_VARARGS,
          "Destroy a domain"},
     {"domain_pause", (PyCFunction)pyxl_domain_pause, METH_VARARGS,



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 17:19:58 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 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.xensource.com>)
	id 1RaW11-0007vN-3y; Tue, 13 Dec 2011 17:19:43 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RaW10-0007v8-0o
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 17:19:42 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1323796727!7213466!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTI1NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8093 invoked from network); 13 Dec 2011 17:18:47 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 17:18:47 -0000
X-IronPort-AV: E=Sophos;i="4.71,346,1320624000"; 
   d="scan'208";a="9447360"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Dec 2011 17:18:27 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 13 Dec 2011 17:18:27 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Tue, 13 Dec 2011 17:18:27 +0000
In-Reply-To: <1323796265.20077.341.camel@zakaz.uk.xensource.com>
References: <patchbomb.1323793468@cosworth.uk.xensource.com>
	<e0f020d3d812e00aeb0c.1323793470@cosworth.uk.xensource.com>
	<1323796265.20077.341.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323796707.20077.346.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 2 of 3] libxl: split libxl_domain_shutdown
 into libxl_domain_shutdown & libxl_domain_reboot
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2011-12-13 at 17:11 +0000, Ian Campbell wrote:
> On Tue, 2011-12-13 at 16:24 +0000, Ian Campbell wrote:
> > # HG changeset patch
> > # User Ian Campbell <ian.campbell@citrix.com>
> > # Date 1323793444 0
> > # Node ID e0f020d3d812e00aeb0c271a9627206279da3964
> > # Parent  97677918e3a4c8e724d7c8a6aba9cec570400c99
> > libxl: split libxl_domain_shutdown into libxl_domain_shutdown & libxl_domain_reboot
> > 
> > The other integer request types which shutdown supported are not useful. Specifically:
> > 
> >  * "suspend" is not usable via this interface since it requires other
> >    scaffolding, libxl_domain_suspend provides this already.
> >  * "halt" is the same as "poweroff".
> >  * "crash" is unused and at least Linux does not implement it. If a user
> >    steps forward then libxl_domain_crash is trivial to add.
> > 
> 
> I forgot to build test the language bindings and of course this broke
> them. Please stand by for an updated patch.

8<------------------------------------------------------------

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1323796506 0
# Node ID c03b6bccb479740f7c70b96f4b1c0951dd70e615
# Parent  97677918e3a4c8e724d7c8a6aba9cec570400c99
libxl: split libxl_domain_shutdown into libxl_domain_shutdown & libxl_domain_reboot

The other integer request types which shutdown supported are not useful. Specifically:

 * "suspend" is not usable via this interface since it requires other
   scaffolding, libxl_domain_suspend provides this already.
 * "halt" is the same as "poweroff".
 * "crash" is unused and at least Linux does not implement it. If a user
   steps forward then libxl_domain_crash is trivial to add.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 97677918e3a4 -r c03b6bccb479 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Tue Dec 13 16:22:58 2011 +0000
+++ b/tools/libxl/libxl.c	Tue Dec 13 17:15:06 2011 +0000
@@ -594,36 +594,46 @@ int libxl__domain_pvcontrol_write(libxl_
     return libxl__xs_write(gc, t, shutdown_path, "%s", cmd);
 }
 
-static char *req_table[] = {
-    [0] = "poweroff",
-    [1] = "reboot",
-    [2] = "suspend",
-    [3] = "crash",
-    [4] = "halt",
-};
-
-int libxl_domain_shutdown(libxl_ctx *ctx, uint32_t domid, int req)
+int libxl_domain_shutdown(libxl_ctx *ctx, uint32_t domid)
 {
     GC_INIT(ctx);
     int ret;
 
-    if (req > ARRAY_SIZE(req_table)) {
-        GC_FREE;
-        return ERROR_INVAL;
-    }
-
     ret = libxl__domain_pvcontrol_available(gc, domid);
     if (ret < 0)
         goto out;
 
     if (!ret) {
-        LIBXL__LOG(CTX, LIBXL__LOG_ERROR, "PV shutdown control not available:"
+        LIBXL__LOG(CTX, LIBXL__LOG_ERROR, "PV control interface not available:"
                    " graceful shutdown not possible, use destroy");
         ret = ERROR_FAIL;
         goto out;
     }
 
-    ret = libxl__domain_pvcontrol_write(gc, XBT_NULL, domid, req_table[req]);
+    ret = libxl__domain_pvcontrol_write(gc, XBT_NULL, domid, "poweroff");
+
+out:
+    GC_FREE;
+    return ret;
+}
+
+int libxl_domain_reboot(libxl_ctx *ctx, uint32_t domid)
+{
+    GC_INIT(ctx);
+    int ret;
+
+    ret = libxl__domain_pvcontrol_available(gc, domid);
+    if (ret < 0)
+        goto out;
+
+    if (!ret) {
+        LIBXL__LOG(CTX, LIBXL__LOG_ERROR, "PV control interface not available:"
+                   " graceful reboot not possible, use destroy+create");
+        ret = ERROR_FAIL;
+        goto out;
+    }
+
+    ret = libxl__domain_pvcontrol_write(gc, XBT_NULL, domid, "reboot");
 
 out:
     GC_FREE;
diff -r 97677918e3a4 -r c03b6bccb479 tools/libxl/libxl.h
--- a/tools/libxl/libxl.h	Tue Dec 13 16:22:58 2011 +0000
+++ b/tools/libxl/libxl.h	Tue Dec 13 17:15:06 2011 +0000
@@ -268,7 +268,8 @@ void libxl_domain_config_dispose(libxl_d
 int libxl_domain_suspend(libxl_ctx *ctx, libxl_domain_suspend_info *info,
                           uint32_t domid, int fd);
 int libxl_domain_resume(libxl_ctx *ctx, uint32_t domid);
-int libxl_domain_shutdown(libxl_ctx *ctx, uint32_t domid, int req);
+int libxl_domain_shutdown(libxl_ctx *ctx, uint32_t domid);
+int libxl_domain_reboot(libxl_ctx *ctx, uint32_t domid);
 int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid, int force);
 int libxl_domain_preserve(libxl_ctx *ctx, uint32_t domid, libxl_domain_create_info *info, const char *name_suffix, libxl_uuid new_uuid);
 
diff -r 97677918e3a4 -r c03b6bccb479 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Tue Dec 13 16:22:58 2011 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Tue Dec 13 17:15:06 2011 +0000
@@ -2265,7 +2265,7 @@ static void shutdown_domain(const char *
     int rc;
 
     find_domain(p);
-    rc=libxl_domain_shutdown(ctx, domid, 0);
+    rc=libxl_domain_shutdown(ctx, domid);
     if (rc) { fprintf(stderr,"shutdown failed (rc=%d)\n",rc);exit(-1); }
 
     if (wait) {
@@ -2307,7 +2307,7 @@ static void reboot_domain(const char *p)
 {
     int rc;
     find_domain(p);
-    rc=libxl_domain_shutdown(ctx, domid, 1);
+    rc=libxl_domain_reboot(ctx, domid);
     if (rc) { fprintf(stderr,"reboot failed (rc=%d)\n",rc);exit(-1); }
 }
 
diff -r 97677918e3a4 -r c03b6bccb479 tools/python/xen/lowlevel/xl/xl.c
--- a/tools/python/xen/lowlevel/xl/xl.c	Tue Dec 13 16:22:58 2011 +0000
+++ b/tools/python/xen/lowlevel/xl/xl.c	Tue Dec 13 17:15:06 2011 +0000
@@ -424,10 +424,10 @@ static PyObject *pyxl_domid_to_name(XlOb
 
 static PyObject *pyxl_domain_shutdown(XlObject *self, PyObject *args)
 {
-    int domid, req = 0;
-    if ( !PyArg_ParseTuple(args, "i|i", &domid, &req) )
+    int domid;
+    if ( !PyArg_ParseTuple(args, "i", &domid) )
         return NULL;
-    if ( libxl_domain_shutdown(self->ctx, domid, req) ) {
+    if ( libxl_domain_shutdown(self->ctx, domid) ) {
         PyErr_SetString(xl_error_obj, "cannot shutdown domain");
         return NULL;
     }
@@ -435,6 +435,19 @@ static PyObject *pyxl_domain_shutdown(Xl
     return Py_None;
 }
 
+static PyObject *pyxl_domain_reboot(XlObject *self, PyObject *args)
+{
+    int domid;
+    if ( !PyArg_ParseTuple(args, "i", &domid) )
+        return NULL;
+    if ( libxl_domain_reboot(self->ctx, domid) ) {
+        PyErr_SetString(xl_error_obj, "cannot reboot domain");
+        return NULL;
+    }
+    Py_INCREF(Py_None);
+    return Py_None;
+}
+
 static PyObject *pyxl_domain_destroy(XlObject *self, PyObject *args)
 {
     int domid, force = 1;
@@ -637,6 +650,8 @@ static PyMethodDef pyxl_methods[] = {
          "Retrieve name from domain-id"},
     {"domain_shutdown", (PyCFunction)pyxl_domain_shutdown, METH_VARARGS,
          "Shutdown a domain"},
+    {"domain_reboot", (PyCFunction)pyxl_domain_reboot, METH_VARARGS,
+         "Reboot a domain"},
     {"domain_destroy", (PyCFunction)pyxl_domain_destroy, METH_VARARGS,
          "Destroy a domain"},
     {"domain_pause", (PyCFunction)pyxl_domain_pause, METH_VARARGS,



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 17:28:45 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 17:28:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaW9V-0008AM-5q; Tue, 13 Dec 2011 17:28:29 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RaW9T-0008AA-Kq
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 17:28:27 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1323797253!7306708!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTI1NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20825 invoked from network); 13 Dec 2011 17:27:33 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 17:27:33 -0000
X-IronPort-AV: E=Sophos;i="4.71,346,1320624000"; 
   d="scan'208";a="9447424"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Dec 2011 17:22:30 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 13 Dec 2011 17:22:30 +0000
Date: Tue, 13 Dec 2011 17:24:15 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
In-Reply-To: <20199.24118.465585.933183@mariner.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1112131720250.3517@kaball-desktop>
References: <alpine.DEB.2.00.1111221551510.31179@kaball-desktop>
	<1322056320-5826-5-git-send-email-stefano.stabellini@eu.citrix.com>
	<20198.15417.932169.223332@mariner.uk.xensource.com>
	<1323712001.20077.234.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1112121924520.3517@kaball-desktop>
	<20199.24118.465585.933183@mariner.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v9 5/6] Clone and build Seabios by default
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 13 Dec 2011, Ian Jackson wrote:
> Stefano Stabellini writes ("Re: [Xen-devel] [PATCH v9 5/6] Clone and build Seabios by default"):
> > On Mon, 12 Dec 2011, Ian Campbell wrote:
> > > On Mon, 2011-12-12 at 17:39 +0000, Ian Jackson wrote:
> > > > I see you have included a lockstep changeset number in xen-unstable
> > > > but are we really able to force these to update in lockstep ?
> 
> Did you have an answer for this ?

The answer is yes. Unless there is a bug that I didn't manage to find of
course.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 17:28:45 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 17:28:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaW9V-0008AM-5q; Tue, 13 Dec 2011 17:28:29 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RaW9T-0008AA-Kq
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 17:28:27 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1323797253!7306708!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTI1NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20825 invoked from network); 13 Dec 2011 17:27:33 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 17:27:33 -0000
X-IronPort-AV: E=Sophos;i="4.71,346,1320624000"; 
   d="scan'208";a="9447424"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Dec 2011 17:22:30 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 13 Dec 2011 17:22:30 +0000
Date: Tue, 13 Dec 2011 17:24:15 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
In-Reply-To: <20199.24118.465585.933183@mariner.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1112131720250.3517@kaball-desktop>
References: <alpine.DEB.2.00.1111221551510.31179@kaball-desktop>
	<1322056320-5826-5-git-send-email-stefano.stabellini@eu.citrix.com>
	<20198.15417.932169.223332@mariner.uk.xensource.com>
	<1323712001.20077.234.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1112121924520.3517@kaball-desktop>
	<20199.24118.465585.933183@mariner.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v9 5/6] Clone and build Seabios by default
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 13 Dec 2011, Ian Jackson wrote:
> Stefano Stabellini writes ("Re: [Xen-devel] [PATCH v9 5/6] Clone and build Seabios by default"):
> > On Mon, 12 Dec 2011, Ian Campbell wrote:
> > > On Mon, 2011-12-12 at 17:39 +0000, Ian Jackson wrote:
> > > > I see you have included a lockstep changeset number in xen-unstable
> > > > but are we really able to force these to update in lockstep ?
> 
> Did you have an answer for this ?

The answer is yes. Unless there is a bug that I didn't manage to find of
course.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 17:28:50 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 17:28:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaW9b-0008Aj-I2; Tue, 13 Dec 2011 17:28:35 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RaW9Z-0008AX-Sy
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 17:28:34 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1323797220!48848663!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24264 invoked from network); 13 Dec 2011 17:27:00 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-3.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 13 Dec 2011 17:27:00 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 13 Dec 2011 17:27:43 +0000
Message-Id: <4EE7991C0200007800067787@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 13 Dec 2011 17:27:40 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Stefano Stabellini" <stefano.stabellini@eu.citrix.com>
References: <4EE7672902000078000674D4@nat28.tlf.novell.com>
	<alpine.DEB.2.00.1112131646150.3517@kaball-desktop>
In-Reply-To: <alpine.DEB.2.00.1112131646150.3517@kaball-desktop>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] map_domain_emuirq_pirq() imbalance with
 unmap_domain_pirq_emuirq()?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 13.12.11 at 18:16, Stefano Stabellini <stefano.stabellini@eu.citrix.com> wrote:
> I think I understand what the problem is: since 'xen: fix
> hvm_domain_use_pirq's behavior' the pirq to emuirq mapping remains set
> to IRQ_UNBOUND until an event channel has been bound to the pirq.
> That means that if the guest is not binding any event channels at all,
> the mapping remains IRQ_UNBOUND for the life of the VM.
> Eventually when physdev_unmap_pirq gets called, nothing happens because
> unmap_domain_pirq_emuirq keeps failing. This wasn't the original
> behavior because it used to be the case that the mapping would always be
> either IRQ_PT or a positive number.
> 
> A simple solution to this issue would be to introduce a check in
> physdev_unmap_pirq:
> 
> --- a/xen/arch/x86/physdev.c
> +++ b/xen/arch/x86/physdev.c
> @@ -216,14 +216,16 @@ int physdev_unmap_pirq(domid_t domid, int pirq)
>      if ( ret )
>          return ret;
>  
> -    if ( is_hvm_domain(d) )
> +    if ( is_hvm_domain(d) && domain_pirq_to_emuirq(d, pirq) != IRQ_UNBOUND)
>      {
>          spin_lock(&d->event_lock);
>          ret = unmap_domain_pirq_emuirq(d, pirq);
>          spin_unlock(&d->event_lock);
> -        if ( domid == DOMID_SELF || ret )
> +        if ( ret )
>              goto free_domain;
>      }
> +    if ( domid == DOMID_SELF )
> +        goto free_domain;

I don't think this is correct for the pv case, seems to need a
"is_hvm_domain() && " in front of it. If you agree, we can give this
a try.

>  
>      ret = -EPERM;
>      if ( !IS_PRIV_FOR(current->domain, d) )
> 
> 
>> Besides that, in 23806:4226ea1785b5 you move a call to
>> map_domain_emuirq_pirq() from xen/arch/x86/physdev.c to
>> xen/common/event_channel.c, but neither before nor after the patch
>> the function's return value gets checked, yet the function has various
>> ways to fail. Is failure here really benign?
>  
> No, it is not. We should return an error if map_domain_emuirq_pirq
> fails.

I'm afraid it's not just a matter of returning an error here, but also
needs (correct) undoing of everything that was already done.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 17:28:50 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 17:28:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaW9b-0008Aj-I2; Tue, 13 Dec 2011 17:28:35 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RaW9Z-0008AX-Sy
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 17:28:34 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1323797220!48848663!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24264 invoked from network); 13 Dec 2011 17:27:00 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-3.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 13 Dec 2011 17:27:00 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 13 Dec 2011 17:27:43 +0000
Message-Id: <4EE7991C0200007800067787@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 13 Dec 2011 17:27:40 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Stefano Stabellini" <stefano.stabellini@eu.citrix.com>
References: <4EE7672902000078000674D4@nat28.tlf.novell.com>
	<alpine.DEB.2.00.1112131646150.3517@kaball-desktop>
In-Reply-To: <alpine.DEB.2.00.1112131646150.3517@kaball-desktop>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] map_domain_emuirq_pirq() imbalance with
 unmap_domain_pirq_emuirq()?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 13.12.11 at 18:16, Stefano Stabellini <stefano.stabellini@eu.citrix.com> wrote:
> I think I understand what the problem is: since 'xen: fix
> hvm_domain_use_pirq's behavior' the pirq to emuirq mapping remains set
> to IRQ_UNBOUND until an event channel has been bound to the pirq.
> That means that if the guest is not binding any event channels at all,
> the mapping remains IRQ_UNBOUND for the life of the VM.
> Eventually when physdev_unmap_pirq gets called, nothing happens because
> unmap_domain_pirq_emuirq keeps failing. This wasn't the original
> behavior because it used to be the case that the mapping would always be
> either IRQ_PT or a positive number.
> 
> A simple solution to this issue would be to introduce a check in
> physdev_unmap_pirq:
> 
> --- a/xen/arch/x86/physdev.c
> +++ b/xen/arch/x86/physdev.c
> @@ -216,14 +216,16 @@ int physdev_unmap_pirq(domid_t domid, int pirq)
>      if ( ret )
>          return ret;
>  
> -    if ( is_hvm_domain(d) )
> +    if ( is_hvm_domain(d) && domain_pirq_to_emuirq(d, pirq) != IRQ_UNBOUND)
>      {
>          spin_lock(&d->event_lock);
>          ret = unmap_domain_pirq_emuirq(d, pirq);
>          spin_unlock(&d->event_lock);
> -        if ( domid == DOMID_SELF || ret )
> +        if ( ret )
>              goto free_domain;
>      }
> +    if ( domid == DOMID_SELF )
> +        goto free_domain;

I don't think this is correct for the pv case, seems to need a
"is_hvm_domain() && " in front of it. If you agree, we can give this
a try.

>  
>      ret = -EPERM;
>      if ( !IS_PRIV_FOR(current->domain, d) )
> 
> 
>> Besides that, in 23806:4226ea1785b5 you move a call to
>> map_domain_emuirq_pirq() from xen/arch/x86/physdev.c to
>> xen/common/event_channel.c, but neither before nor after the patch
>> the function's return value gets checked, yet the function has various
>> ways to fail. Is failure here really benign?
>  
> No, it is not. We should return an error if map_domain_emuirq_pirq
> fails.

I'm afraid it's not just a matter of returning an error here, but also
needs (correct) undoing of everything that was already done.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 17:35:49 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 17:35:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaWGL-0000A4-E5; Tue, 13 Dec 2011 17:35:33 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RaWGJ-00009y-TK
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 17:35:32 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1323797677!6723574!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTI1NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21988 invoked from network); 13 Dec 2011 17:34:37 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 17:34:37 -0000
X-IronPort-AV: E=Sophos;i="4.71,346,1320624000"; 
   d="scan'208";a="9447605"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Dec 2011 17:34:37 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 13 Dec 2011 17:34:37 +0000
Date: Tue, 13 Dec 2011 17:36:23 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Jan Beulich <JBeulich@suse.com>
In-Reply-To: <4EE7991C0200007800067787@nat28.tlf.novell.com>
Message-ID: <alpine.DEB.2.00.1112131732250.3517@kaball-desktop>
References: <4EE7672902000078000674D4@nat28.tlf.novell.com>
	<alpine.DEB.2.00.1112131646150.3517@kaball-desktop>
	<4EE7991C0200007800067787@nat28.tlf.novell.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] map_domain_emuirq_pirq() imbalance with
 unmap_domain_pirq_emuirq()?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 13 Dec 2011, Jan Beulich wrote:
> >>> On 13.12.11 at 18:16, Stefano Stabellini <stefano.stabellini@eu.citrix.com> wrote:
> > I think I understand what the problem is: since 'xen: fix
> > hvm_domain_use_pirq's behavior' the pirq to emuirq mapping remains set
> > to IRQ_UNBOUND until an event channel has been bound to the pirq.
> > That means that if the guest is not binding any event channels at all,
> > the mapping remains IRQ_UNBOUND for the life of the VM.
> > Eventually when physdev_unmap_pirq gets called, nothing happens because
> > unmap_domain_pirq_emuirq keeps failing. This wasn't the original
> > behavior because it used to be the case that the mapping would always be
> > either IRQ_PT or a positive number.
> > 
> > A simple solution to this issue would be to introduce a check in
> > physdev_unmap_pirq:
> > 
> > --- a/xen/arch/x86/physdev.c
> > +++ b/xen/arch/x86/physdev.c
> > @@ -216,14 +216,16 @@ int physdev_unmap_pirq(domid_t domid, int pirq)
> >      if ( ret )
> >          return ret;
> >  
> > -    if ( is_hvm_domain(d) )
> > +    if ( is_hvm_domain(d) && domain_pirq_to_emuirq(d, pirq) != IRQ_UNBOUND)
> >      {
> >          spin_lock(&d->event_lock);
> >          ret = unmap_domain_pirq_emuirq(d, pirq);
> >          spin_unlock(&d->event_lock);
> > -        if ( domid == DOMID_SELF || ret )
> > +        if ( ret )
> >              goto free_domain;
> >      }
> > +    if ( domid == DOMID_SELF )
> > +        goto free_domain;
> 
> I don't think this is correct for the pv case, seems to need a
> "is_hvm_domain() && " in front of it. If you agree, we can give this
> a try.

Yes, you are right.


> >      ret = -EPERM;
> >      if ( !IS_PRIV_FOR(current->domain, d) )
> > 
> > 
> >> Besides that, in 23806:4226ea1785b5 you move a call to
> >> map_domain_emuirq_pirq() from xen/arch/x86/physdev.c to
> >> xen/common/event_channel.c, but neither before nor after the patch
> >> the function's return value gets checked, yet the function has various
> >> ways to fail. Is failure here really benign?
> >  
> > No, it is not. We should return an error if map_domain_emuirq_pirq
> > fails.
> 
> I'm afraid it's not just a matter of returning an error here, but also
> needs (correct) undoing of everything that was already done.
 
I don't think there is a particular reason why map_domain_emuirq_pirq
should be at the end of the function, after link_pirq_port. It could be
moved close to the previous goto out, we just need to know the pirq
number.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 17:35:49 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 17:35:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaWGL-0000A4-E5; Tue, 13 Dec 2011 17:35:33 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RaWGJ-00009y-TK
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 17:35:32 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1323797677!6723574!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTI1NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21988 invoked from network); 13 Dec 2011 17:34:37 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 17:34:37 -0000
X-IronPort-AV: E=Sophos;i="4.71,346,1320624000"; 
   d="scan'208";a="9447605"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Dec 2011 17:34:37 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 13 Dec 2011 17:34:37 +0000
Date: Tue, 13 Dec 2011 17:36:23 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Jan Beulich <JBeulich@suse.com>
In-Reply-To: <4EE7991C0200007800067787@nat28.tlf.novell.com>
Message-ID: <alpine.DEB.2.00.1112131732250.3517@kaball-desktop>
References: <4EE7672902000078000674D4@nat28.tlf.novell.com>
	<alpine.DEB.2.00.1112131646150.3517@kaball-desktop>
	<4EE7991C0200007800067787@nat28.tlf.novell.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] map_domain_emuirq_pirq() imbalance with
 unmap_domain_pirq_emuirq()?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 13 Dec 2011, Jan Beulich wrote:
> >>> On 13.12.11 at 18:16, Stefano Stabellini <stefano.stabellini@eu.citrix.com> wrote:
> > I think I understand what the problem is: since 'xen: fix
> > hvm_domain_use_pirq's behavior' the pirq to emuirq mapping remains set
> > to IRQ_UNBOUND until an event channel has been bound to the pirq.
> > That means that if the guest is not binding any event channels at all,
> > the mapping remains IRQ_UNBOUND for the life of the VM.
> > Eventually when physdev_unmap_pirq gets called, nothing happens because
> > unmap_domain_pirq_emuirq keeps failing. This wasn't the original
> > behavior because it used to be the case that the mapping would always be
> > either IRQ_PT or a positive number.
> > 
> > A simple solution to this issue would be to introduce a check in
> > physdev_unmap_pirq:
> > 
> > --- a/xen/arch/x86/physdev.c
> > +++ b/xen/arch/x86/physdev.c
> > @@ -216,14 +216,16 @@ int physdev_unmap_pirq(domid_t domid, int pirq)
> >      if ( ret )
> >          return ret;
> >  
> > -    if ( is_hvm_domain(d) )
> > +    if ( is_hvm_domain(d) && domain_pirq_to_emuirq(d, pirq) != IRQ_UNBOUND)
> >      {
> >          spin_lock(&d->event_lock);
> >          ret = unmap_domain_pirq_emuirq(d, pirq);
> >          spin_unlock(&d->event_lock);
> > -        if ( domid == DOMID_SELF || ret )
> > +        if ( ret )
> >              goto free_domain;
> >      }
> > +    if ( domid == DOMID_SELF )
> > +        goto free_domain;
> 
> I don't think this is correct for the pv case, seems to need a
> "is_hvm_domain() && " in front of it. If you agree, we can give this
> a try.

Yes, you are right.


> >      ret = -EPERM;
> >      if ( !IS_PRIV_FOR(current->domain, d) )
> > 
> > 
> >> Besides that, in 23806:4226ea1785b5 you move a call to
> >> map_domain_emuirq_pirq() from xen/arch/x86/physdev.c to
> >> xen/common/event_channel.c, but neither before nor after the patch
> >> the function's return value gets checked, yet the function has various
> >> ways to fail. Is failure here really benign?
> >  
> > No, it is not. We should return an error if map_domain_emuirq_pirq
> > fails.
> 
> I'm afraid it's not just a matter of returning an error here, but also
> needs (correct) undoing of everything that was already done.
 
I don't think there is a particular reason why map_domain_emuirq_pirq
should be at the end of the function, after link_pirq_port. It could be
moved close to the previous goto out, we just need to know the pirq
number.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 17:41:34 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 17:41:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaWLq-0000N8-6u; Tue, 13 Dec 2011 17:41:14 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RaWLo-0000Mv-Kv
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 17:41:12 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1323798012!7050377!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTI1NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27519 invoked from network); 13 Dec 2011 17:40:17 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 17:40:17 -0000
X-IronPort-AV: E=Sophos;i="4.71,347,1320624000"; 
   d="scan'208";a="9447700"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Dec 2011 17:40:12 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 13 Dec 2011 17:40:12 +0000
Date: Tue, 13 Dec 2011 17:42:08 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
In-Reply-To: <20199.24032.555383.178696@mariner.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1112131725310.3517@kaball-desktop>
References: <1323108621-22654-1-git-send-email-ian.jackson@eu.citrix.com>
	<1323108621-22654-16-git-send-email-ian.jackson@eu.citrix.com>
	<alpine.DEB.2.00.1112091558300.3517@kaball-desktop>
	<20194.22539.574524.956955@mariner.uk.xensource.com>
	<1323463293.20936.11.camel@dagon.hellion.org.uk>
	<20197.59428.699013.507183@mariner.uk.xensource.com>
	<1323692225.20077.183.camel@zakaz.uk.xensource.com>
	<20197.62462.189827.239656@mariner.uk.xensource.com>
	<1323697723.20077.212.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1112121453050.3517@kaball-desktop>
	<20198.9737.680162.103418@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1112121613330.3517@kaball-desktop>
	<20199.24032.555383.178696@mariner.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 15/15] libxl: New event generation API
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 13 Dec 2011, Ian Jackson wrote:
> Stefano Stabellini writes ("Re: [Xen-devel] [PATCH 15/15] libxl: New event generation API"):
> > +#define GC_INIT(ctx)  libxl__gc *gc = libxl__init_gc(ctx); if (gc == NULL) return ERROR_NOMEM;
> 
> I think we should avoid macros which return from their containing
> function, unless they are unavoidable.
> 
> Only event-generating libxl entrypoints need to know about the special
> rules for handling the lock and ctx.  The set of event-generating
> entrypoints to libxl is bounded - they are all part of the event
> generation core.
> 
> Also, what you are doing here complicates the usual, simple, case.
> I would prefer to keep the case that can be simple, simple.
> 
> So I think in this case it is better to document the restrictions
> rather than try to abolish them with additional behind-the-scenes
> machinery.

I would agree with you if you were not about to introduce an even more
complicate machinery in the library. A machinery that needs a different
entry point compared to regular libxl functions. Actually I think that
introducing different modes of operations in the same codebase is very
confusing for everyone that works on it. No matter how well you document
them. The kernel is very well documented, but still it is difficult to
understand when you can sleep and when you cannot.
So I am up for anything that would remove this duality.

Also it is very hard to predict whether the event-generating entrypoints
are going to stay bounded.


That said, there is a very easy solution to this problem: we remove the
macro, that I personally dislike anyway, and we open code the check at
the beginning of every function. Now that we are using C99 there isn't
any problem with doing this. It is also much easier to understand what is
going on this way, no hidden behaviors, nothing returning behind your
back, or declaring a new variable a macro.
We could easily make it comply the CODE_STYLE with the addition of a
single line.

@@ -235,7 +241,7 @@ int libxl__domain_rename(libxl__gc *gc, uint32_t domid,
 int libxl_domain_rename(libxl_ctx *ctx, uint32_t domid,
                         const char *old_name, const char *new_name)
 {
-    GC_INIT(ctx);
+    libxl__gc *gc = libxl__init_gc(ctx); if (gc == NULL) return ERROR_NOMEM;
     int rc;
     rc = libxl__domain_rename(gc, domid, old_name, new_name, XBT_NULL);
     GC_FREE;



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 17:41:34 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 17:41:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaWLq-0000N8-6u; Tue, 13 Dec 2011 17:41:14 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RaWLo-0000Mv-Kv
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 17:41:12 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1323798012!7050377!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTI1NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27519 invoked from network); 13 Dec 2011 17:40:17 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 17:40:17 -0000
X-IronPort-AV: E=Sophos;i="4.71,347,1320624000"; 
   d="scan'208";a="9447700"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Dec 2011 17:40:12 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 13 Dec 2011 17:40:12 +0000
Date: Tue, 13 Dec 2011 17:42:08 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
In-Reply-To: <20199.24032.555383.178696@mariner.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1112131725310.3517@kaball-desktop>
References: <1323108621-22654-1-git-send-email-ian.jackson@eu.citrix.com>
	<1323108621-22654-16-git-send-email-ian.jackson@eu.citrix.com>
	<alpine.DEB.2.00.1112091558300.3517@kaball-desktop>
	<20194.22539.574524.956955@mariner.uk.xensource.com>
	<1323463293.20936.11.camel@dagon.hellion.org.uk>
	<20197.59428.699013.507183@mariner.uk.xensource.com>
	<1323692225.20077.183.camel@zakaz.uk.xensource.com>
	<20197.62462.189827.239656@mariner.uk.xensource.com>
	<1323697723.20077.212.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1112121453050.3517@kaball-desktop>
	<20198.9737.680162.103418@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1112121613330.3517@kaball-desktop>
	<20199.24032.555383.178696@mariner.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 15/15] libxl: New event generation API
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 13 Dec 2011, Ian Jackson wrote:
> Stefano Stabellini writes ("Re: [Xen-devel] [PATCH 15/15] libxl: New event generation API"):
> > +#define GC_INIT(ctx)  libxl__gc *gc = libxl__init_gc(ctx); if (gc == NULL) return ERROR_NOMEM;
> 
> I think we should avoid macros which return from their containing
> function, unless they are unavoidable.
> 
> Only event-generating libxl entrypoints need to know about the special
> rules for handling the lock and ctx.  The set of event-generating
> entrypoints to libxl is bounded - they are all part of the event
> generation core.
> 
> Also, what you are doing here complicates the usual, simple, case.
> I would prefer to keep the case that can be simple, simple.
> 
> So I think in this case it is better to document the restrictions
> rather than try to abolish them with additional behind-the-scenes
> machinery.

I would agree with you if you were not about to introduce an even more
complicate machinery in the library. A machinery that needs a different
entry point compared to regular libxl functions. Actually I think that
introducing different modes of operations in the same codebase is very
confusing for everyone that works on it. No matter how well you document
them. The kernel is very well documented, but still it is difficult to
understand when you can sleep and when you cannot.
So I am up for anything that would remove this duality.

Also it is very hard to predict whether the event-generating entrypoints
are going to stay bounded.


That said, there is a very easy solution to this problem: we remove the
macro, that I personally dislike anyway, and we open code the check at
the beginning of every function. Now that we are using C99 there isn't
any problem with doing this. It is also much easier to understand what is
going on this way, no hidden behaviors, nothing returning behind your
back, or declaring a new variable a macro.
We could easily make it comply the CODE_STYLE with the addition of a
single line.

@@ -235,7 +241,7 @@ int libxl__domain_rename(libxl__gc *gc, uint32_t domid,
 int libxl_domain_rename(libxl_ctx *ctx, uint32_t domid,
                         const char *old_name, const char *new_name)
 {
-    GC_INIT(ctx);
+    libxl__gc *gc = libxl__init_gc(ctx); if (gc == NULL) return ERROR_NOMEM;
     int rc;
     rc = libxl__domain_rename(gc, domid, old_name, new_name, XBT_NULL);
     GC_FREE;



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 17:54:18 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 17: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.xensource.com>)
	id 1RaWYB-0000YO-Hs; Tue, 13 Dec 2011 17:53:59 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RaWY9-0000YJ-LT
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 17:53:57 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1323798782!5418224!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTI1NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21975 invoked from network); 13 Dec 2011 17:53:03 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 17:53:03 -0000
X-IronPort-AV: E=Sophos;i="4.71,347,1320624000"; 
   d="scan'208";a="9447952"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Dec 2011 17:53:02 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 13 Dec 2011 17:53:02 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RaWXG-0008Hz-0f; Tue, 13 Dec 2011 17:53:02 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RaWXF-00046F-VK;
	Tue, 13 Dec 2011 17:53:01 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20199.37117.779165.894809@mariner.uk.xensource.com>
Date: Tue, 13 Dec 2011 17:53:01 +0000
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
In-Reply-To: <alpine.DEB.2.00.1112131720250.3517@kaball-desktop>
References: <alpine.DEB.2.00.1111221551510.31179@kaball-desktop>
	<1322056320-5826-5-git-send-email-stefano.stabellini@eu.citrix.com>
	<20198.15417.932169.223332@mariner.uk.xensource.com>
	<1323712001.20077.234.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1112121924520.3517@kaball-desktop>
	<20199.24118.465585.933183@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1112131720250.3517@kaball-desktop>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH v9 5/6] Clone and build Seabios by default
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Stefano Stabellini writes ("Re: [Xen-devel] [PATCH v9 5/6] Clone and build Seabios by default"):
> On Tue, 13 Dec 2011, Ian Jackson wrote:
> > Stefano Stabellini writes ("Re: [Xen-devel] [PATCH v9 5/6] Clone and build Seabios by default"):
> > > On Mon, 12 Dec 2011, Ian Campbell wrote:
> > > > On Mon, 2011-12-12 at 17:39 +0000, Ian Jackson wrote:
> > > > > I see you have included a lockstep changeset number in xen-unstable
> > > > > but are we really able to force these to update in lockstep ?
> > 
> > Did you have an answer for this ?
> 
> The answer is yes. Unless there is a bug that I didn't manage to find of
> course.

That doesn't sound like an answer to my question.

To put it another way: are we intending to permanently maintain a
branch of seabios and a branch of qemu upstream ?  Are we going to
have one such branch for each branch of Xen ?  Are we expecting our
downstreams to use our specific version of qemu and seabios, rather
than building from upstream ?

If the answer to any of these questions is "no" then attempting to
nominate a specific changeset won't work.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 17:54:18 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 17: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.xensource.com>)
	id 1RaWYB-0000YO-Hs; Tue, 13 Dec 2011 17:53:59 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RaWY9-0000YJ-LT
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 17:53:57 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1323798782!5418224!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTI1NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21975 invoked from network); 13 Dec 2011 17:53:03 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 17:53:03 -0000
X-IronPort-AV: E=Sophos;i="4.71,347,1320624000"; 
   d="scan'208";a="9447952"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Dec 2011 17:53:02 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 13 Dec 2011 17:53:02 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RaWXG-0008Hz-0f; Tue, 13 Dec 2011 17:53:02 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RaWXF-00046F-VK;
	Tue, 13 Dec 2011 17:53:01 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20199.37117.779165.894809@mariner.uk.xensource.com>
Date: Tue, 13 Dec 2011 17:53:01 +0000
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
In-Reply-To: <alpine.DEB.2.00.1112131720250.3517@kaball-desktop>
References: <alpine.DEB.2.00.1111221551510.31179@kaball-desktop>
	<1322056320-5826-5-git-send-email-stefano.stabellini@eu.citrix.com>
	<20198.15417.932169.223332@mariner.uk.xensource.com>
	<1323712001.20077.234.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1112121924520.3517@kaball-desktop>
	<20199.24118.465585.933183@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1112131720250.3517@kaball-desktop>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH v9 5/6] Clone and build Seabios by default
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Stefano Stabellini writes ("Re: [Xen-devel] [PATCH v9 5/6] Clone and build Seabios by default"):
> On Tue, 13 Dec 2011, Ian Jackson wrote:
> > Stefano Stabellini writes ("Re: [Xen-devel] [PATCH v9 5/6] Clone and build Seabios by default"):
> > > On Mon, 12 Dec 2011, Ian Campbell wrote:
> > > > On Mon, 2011-12-12 at 17:39 +0000, Ian Jackson wrote:
> > > > > I see you have included a lockstep changeset number in xen-unstable
> > > > > but are we really able to force these to update in lockstep ?
> > 
> > Did you have an answer for this ?
> 
> The answer is yes. Unless there is a bug that I didn't manage to find of
> course.

That doesn't sound like an answer to my question.

To put it another way: are we intending to permanently maintain a
branch of seabios and a branch of qemu upstream ?  Are we going to
have one such branch for each branch of Xen ?  Are we expecting our
downstreams to use our specific version of qemu and seabios, rather
than building from upstream ?

If the answer to any of these questions is "no" then attempting to
nominate a specific changeset won't work.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 18:03:15 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 18: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.xensource.com>)
	id 1RaWgt-0000rq-P4; Tue, 13 Dec 2011 18:02:59 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RaWgs-0000rl-2f
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 18:02:58 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1323799276!60589837!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTI1NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3911 invoked from network); 13 Dec 2011 18:01:16 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 18:01:16 -0000
X-IronPort-AV: E=Sophos;i="4.71,347,1320624000"; 
   d="scan'208";a="9448153"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Dec 2011 18:02:08 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 13 Dec 2011 18:02:08 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
In-Reply-To: <alpine.DEB.2.00.1112131725310.3517@kaball-desktop>
References: <1323108621-22654-1-git-send-email-ian.jackson@eu.citrix.com>
	<1323108621-22654-16-git-send-email-ian.jackson@eu.citrix.com>
	<alpine.DEB.2.00.1112091558300.3517@kaball-desktop>
	<20194.22539.574524.956955@mariner.uk.xensource.com>
	<1323463293.20936.11.camel@dagon.hellion.org.uk>
	<20197.59428.699013.507183@mariner.uk.xensource.com>
	<1323692225.20077.183.camel@zakaz.uk.xensource.com>
	<20197.62462.189827.239656@mariner.uk.xensource.com>
	<1323697723.20077.212.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1112121453050.3517@kaball-desktop>
	<20198.9737.680162.103418@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1112121613330.3517@kaball-desktop>
	<20199.24032.555383.178696@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1112131725310.3517@kaball-desktop>
Organization: Citrix Systems, Inc.
Date: Tue, 13 Dec 2011 18:02:08 +0000
Message-ID: <1323799328.20936.80.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
X-Mailer: Evolution 2.32.3 
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 15/15] libxl: New event generation API
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2011-12-13 at 17:42 +0000, Stefano Stabellini wrote:
> So I am up for anything that would remove this duality.

That's a very strong statement to make about a patch which Ian hasn't
posted yet (nor, I suspect, has he even finished writing it).

Rather than entrenching positions now lets wait and evaluate that patch
on its merits.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 18:03:15 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 18: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.xensource.com>)
	id 1RaWgt-0000rq-P4; Tue, 13 Dec 2011 18:02:59 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RaWgs-0000rl-2f
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 18:02:58 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1323799276!60589837!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTI1NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3911 invoked from network); 13 Dec 2011 18:01:16 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 18:01:16 -0000
X-IronPort-AV: E=Sophos;i="4.71,347,1320624000"; 
   d="scan'208";a="9448153"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Dec 2011 18:02:08 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 13 Dec 2011 18:02:08 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
In-Reply-To: <alpine.DEB.2.00.1112131725310.3517@kaball-desktop>
References: <1323108621-22654-1-git-send-email-ian.jackson@eu.citrix.com>
	<1323108621-22654-16-git-send-email-ian.jackson@eu.citrix.com>
	<alpine.DEB.2.00.1112091558300.3517@kaball-desktop>
	<20194.22539.574524.956955@mariner.uk.xensource.com>
	<1323463293.20936.11.camel@dagon.hellion.org.uk>
	<20197.59428.699013.507183@mariner.uk.xensource.com>
	<1323692225.20077.183.camel@zakaz.uk.xensource.com>
	<20197.62462.189827.239656@mariner.uk.xensource.com>
	<1323697723.20077.212.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1112121453050.3517@kaball-desktop>
	<20198.9737.680162.103418@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1112121613330.3517@kaball-desktop>
	<20199.24032.555383.178696@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1112131725310.3517@kaball-desktop>
Organization: Citrix Systems, Inc.
Date: Tue, 13 Dec 2011 18:02:08 +0000
Message-ID: <1323799328.20936.80.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
X-Mailer: Evolution 2.32.3 
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 15/15] libxl: New event generation API
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2011-12-13 at 17:42 +0000, Stefano Stabellini wrote:
> So I am up for anything that would remove this duality.

That's a very strong statement to make about a patch which Ian hasn't
posted yet (nor, I suspect, has he even finished writing it).

Rather than entrenching positions now lets wait and evaluate that patch
on its merits.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 18:16:35 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 18: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.xensource.com>)
	id 1RaWtg-00018k-5J; Tue, 13 Dec 2011 18:16:12 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RaWte-00018f-Vd
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 18:16:11 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1323800116!7303502!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTI1NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31112 invoked from network); 13 Dec 2011 18:15:16 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 18:15:16 -0000
X-IronPort-AV: E=Sophos;i="4.71,347,1320624000"; 
   d="scan'208";a="9448309"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Dec 2011 18:15:15 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 13 Dec 2011 18:15:15 +0000
Date: Tue, 13 Dec 2011 18:17:12 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1323799328.20936.80.camel@dagon.hellion.org.uk>
Message-ID: <alpine.DEB.2.00.1112131812280.3517@kaball-desktop>
References: <1323108621-22654-1-git-send-email-ian.jackson@eu.citrix.com>
	<1323108621-22654-16-git-send-email-ian.jackson@eu.citrix.com>
	<alpine.DEB.2.00.1112091558300.3517@kaball-desktop>
	<20194.22539.574524.956955@mariner.uk.xensource.com> 
	<1323463293.20936.11.camel@dagon.hellion.org.uk>
	<20197.59428.699013.507183@mariner.uk.xensource.com>
	<1323692225.20077.183.camel@zakaz.uk.xensource.com>
	<20197.62462.189827.239656@mariner.uk.xensource.com>
	<1323697723.20077.212.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1112121453050.3517@kaball-desktop>
	<20198.9737.680162.103418@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1112121613330.3517@kaball-desktop>
	<20199.24032.555383.178696@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1112131725310.3517@kaball-desktop>
	<1323799328.20936.80.camel@dagon.hellion.org.uk>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 15/15] libxl: New event generation API
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 13 Dec 2011, Ian Campbell wrote:
> On Tue, 2011-12-13 at 17:42 +0000, Stefano Stabellini wrote:
> > So I am up for anything that would remove this duality.
> 
> That's a very strong statement to make about a patch which Ian hasn't
> posted yet (nor, I suspect, has he even finished writing it).
> 
> Rather than entrenching positions now lets wait and evaluate that patch
> on its merits.
 
I am not against this "future" patch or even the concept behind it.
And I am certainly not going to argue against a patch I haven't even
seen yet.

What I am saying is that if we need a malloc allocated gc is the near
future then I am very strongly in favor of changing the allocation of
all of them rather than only some.

Also, there is the matter of the recursive lock, that started this
discussion and brought us here.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 18:16:35 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 18: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.xensource.com>)
	id 1RaWtg-00018k-5J; Tue, 13 Dec 2011 18:16:12 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RaWte-00018f-Vd
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 18:16:11 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1323800116!7303502!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTI1NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31112 invoked from network); 13 Dec 2011 18:15:16 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 18:15:16 -0000
X-IronPort-AV: E=Sophos;i="4.71,347,1320624000"; 
   d="scan'208";a="9448309"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Dec 2011 18:15:15 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 13 Dec 2011 18:15:15 +0000
Date: Tue, 13 Dec 2011 18:17:12 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1323799328.20936.80.camel@dagon.hellion.org.uk>
Message-ID: <alpine.DEB.2.00.1112131812280.3517@kaball-desktop>
References: <1323108621-22654-1-git-send-email-ian.jackson@eu.citrix.com>
	<1323108621-22654-16-git-send-email-ian.jackson@eu.citrix.com>
	<alpine.DEB.2.00.1112091558300.3517@kaball-desktop>
	<20194.22539.574524.956955@mariner.uk.xensource.com> 
	<1323463293.20936.11.camel@dagon.hellion.org.uk>
	<20197.59428.699013.507183@mariner.uk.xensource.com>
	<1323692225.20077.183.camel@zakaz.uk.xensource.com>
	<20197.62462.189827.239656@mariner.uk.xensource.com>
	<1323697723.20077.212.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1112121453050.3517@kaball-desktop>
	<20198.9737.680162.103418@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1112121613330.3517@kaball-desktop>
	<20199.24032.555383.178696@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1112131725310.3517@kaball-desktop>
	<1323799328.20936.80.camel@dagon.hellion.org.uk>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 15/15] libxl: New event generation API
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 13 Dec 2011, Ian Campbell wrote:
> On Tue, 2011-12-13 at 17:42 +0000, Stefano Stabellini wrote:
> > So I am up for anything that would remove this duality.
> 
> That's a very strong statement to make about a patch which Ian hasn't
> posted yet (nor, I suspect, has he even finished writing it).
> 
> Rather than entrenching positions now lets wait and evaluate that patch
> on its merits.
 
I am not against this "future" patch or even the concept behind it.
And I am certainly not going to argue against a patch I haven't even
seen yet.

What I am saying is that if we need a malloc allocated gc is the near
future then I am very strongly in favor of changing the allocation of
all of them rather than only some.

Also, there is the matter of the recursive lock, that started this
discussion and brought us here.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 18:21:51 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 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.xensource.com>)
	id 1RaWyg-0001KK-T6; Tue, 13 Dec 2011 18:21:22 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RaWyf-0001KA-V4
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 18:21:22 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1323800427!5419393!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTI1NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24134 invoked from network); 13 Dec 2011 18:20:27 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 18:20:27 -0000
X-IronPort-AV: E=Sophos;i="4.71,347,1320624000"; 
   d="scan'208";a="9448374"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Dec 2011 18:20:27 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 13 Dec 2011 18:20:26 +0000
Date: Tue, 13 Dec 2011 18:22:13 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
In-Reply-To: <20199.37117.779165.894809@mariner.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1112131817300.3517@kaball-desktop>
References: <alpine.DEB.2.00.1111221551510.31179@kaball-desktop>
	<1322056320-5826-5-git-send-email-stefano.stabellini@eu.citrix.com>
	<20198.15417.932169.223332@mariner.uk.xensource.com>
	<1323712001.20077.234.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1112121924520.3517@kaball-desktop>
	<20199.24118.465585.933183@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1112131720250.3517@kaball-desktop>
	<20199.37117.779165.894809@mariner.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v9 5/6] Clone and build Seabios by default
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 13 Dec 2011, Ian Jackson wrote:
> Stefano Stabellini writes ("Re: [Xen-devel] [PATCH v9 5/6] Clone and build Seabios by default"):
> > On Tue, 13 Dec 2011, Ian Jackson wrote:
> > > Stefano Stabellini writes ("Re: [Xen-devel] [PATCH v9 5/6] Clone and build Seabios by default"):
> > > > On Mon, 12 Dec 2011, Ian Campbell wrote:
> > > > > On Mon, 2011-12-12 at 17:39 +0000, Ian Jackson wrote:
> > > > > > I see you have included a lockstep changeset number in xen-unstable
> > > > > > but are we really able to force these to update in lockstep ?
> > > 
> > > Did you have an answer for this ?
> > 
> > The answer is yes. Unless there is a bug that I didn't manage to find of
> > course.
> 
> That doesn't sound like an answer to my question.
> 
> To put it another way: are we intending to permanently maintain a
> branch of seabios and a branch of qemu upstream ?  Are we going to
> have one such branch for each branch of Xen ?  Are we expecting our
> downstreams to use our specific version of qemu and seabios, rather
> than building from upstream ?

I think "yes" in case of qemu, at the very least for the different
release times of the xen and qemu projects.
I don't have an opinion on seabios because I am nore sure how many
changes are we going to make to it. However I recall that you and/or
IanC were in favor of having or own branch of seabios as well.
BTW I think it is probably better if IanC maintains seabios if we decide
to have our own branch, given that he is the one that did most of the
work on it so far.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 18:21:51 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 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.xensource.com>)
	id 1RaWyg-0001KK-T6; Tue, 13 Dec 2011 18:21:22 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RaWyf-0001KA-V4
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 18:21:22 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1323800427!5419393!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTI1NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24134 invoked from network); 13 Dec 2011 18:20:27 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 18:20:27 -0000
X-IronPort-AV: E=Sophos;i="4.71,347,1320624000"; 
   d="scan'208";a="9448374"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Dec 2011 18:20:27 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 13 Dec 2011 18:20:26 +0000
Date: Tue, 13 Dec 2011 18:22:13 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
In-Reply-To: <20199.37117.779165.894809@mariner.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1112131817300.3517@kaball-desktop>
References: <alpine.DEB.2.00.1111221551510.31179@kaball-desktop>
	<1322056320-5826-5-git-send-email-stefano.stabellini@eu.citrix.com>
	<20198.15417.932169.223332@mariner.uk.xensource.com>
	<1323712001.20077.234.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1112121924520.3517@kaball-desktop>
	<20199.24118.465585.933183@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1112131720250.3517@kaball-desktop>
	<20199.37117.779165.894809@mariner.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v9 5/6] Clone and build Seabios by default
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 13 Dec 2011, Ian Jackson wrote:
> Stefano Stabellini writes ("Re: [Xen-devel] [PATCH v9 5/6] Clone and build Seabios by default"):
> > On Tue, 13 Dec 2011, Ian Jackson wrote:
> > > Stefano Stabellini writes ("Re: [Xen-devel] [PATCH v9 5/6] Clone and build Seabios by default"):
> > > > On Mon, 12 Dec 2011, Ian Campbell wrote:
> > > > > On Mon, 2011-12-12 at 17:39 +0000, Ian Jackson wrote:
> > > > > > I see you have included a lockstep changeset number in xen-unstable
> > > > > > but are we really able to force these to update in lockstep ?
> > > 
> > > Did you have an answer for this ?
> > 
> > The answer is yes. Unless there is a bug that I didn't manage to find of
> > course.
> 
> That doesn't sound like an answer to my question.
> 
> To put it another way: are we intending to permanently maintain a
> branch of seabios and a branch of qemu upstream ?  Are we going to
> have one such branch for each branch of Xen ?  Are we expecting our
> downstreams to use our specific version of qemu and seabios, rather
> than building from upstream ?

I think "yes" in case of qemu, at the very least for the different
release times of the xen and qemu projects.
I don't have an opinion on seabios because I am nore sure how many
changes are we going to make to it. However I recall that you and/or
IanC were in favor of having or own branch of seabios as well.
BTW I think it is probably better if IanC maintains seabios if we decide
to have our own branch, given that he is the one that did most of the
work on it so far.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 19:36:01 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 19:36:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaY8A-0001zK-R6; Tue, 13 Dec 2011 19:35:14 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Neal.Taylor@ca.com>) id 1RaY89-0001zF-5t
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 19:35:13 +0000
X-Env-Sender: Neal.Taylor@ca.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1323804855!8092810!1
X-Originating-IP: [74.125.149.145]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7967 invoked from network); 13 Dec 2011 19:34:17 -0000
Received: from na3sys009aog121.obsmtp.com (HELO na3sys009aog121.obsmtp.com)
	(74.125.149.145)
	by server-15.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Dec 2011 19:34:17 -0000
Received: from USILMS190.ca.com ([141.202.246.44]) (using TLSv1) by
	na3sys009aob121.postini.com ([74.125.148.12]) with SMTP
	ID DSNKTueotuuhSH6JhQQzCugO/gpT2zLzuSE2@postini.com;
	Tue, 13 Dec 2011 11:34:17 PST
Received: from USILMS170.ca.com (141.202.6.20) by USILMS190.ca.com
	(141.202.246.44) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Tue, 13 Dec 2011 14:34:14 -0500
Received: from USILMS110A.ca.com ([169.254.1.109]) by USILMS170.ca.com
	([141.202.6.20]) with mapi id 14.01.0289.001;
	Tue, 13 Dec 2011 14:34:13 -0500
From: "Taylor, Neal E" <Neal.Taylor@ca.com>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
Thread-Topic: [Xen-devel] Buffers not reachable by PCI
Thread-Index: Acy2r+Ulg1PsfbmtTl6QVj0jZAx7mwAK1xcAAIXl/sAAGPmvgAAb3CMA
Date: Tue, 13 Dec 2011 19:34:13 +0000
Message-ID: <3E243B26F475504B9BB0BCC9728B0DA629E183CC@USILMS110A.ca.com>
References: <3E243B26F475504B9BB0BCC9728B0DA629E16E01@USILMS110A.ca.com>
	<20111209203010.GA14412@andromeda.dapyr.net>
	<3E243B26F475504B9BB0BCC9728B0DA629E17AEA@USILMS110A.ca.com>
	<20111213001912.GA2730@konrad-lan>
In-Reply-To: <20111213001912.GA2730@konrad-lan>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [138.42.46.105]
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>, "Kalev,
	Leonid" <Leonid.Kalev@ca.com>, "Dave, Tushar N" <tushar.n.dave@intel.com>
Subject: Re: [Xen-devel] Buffers not reachable by PCI
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

I'm not seeing any difference in symptom or log.

Also, where is the log telling you that it's allocated above 4GB?

Same snippet of the new log:
[    0.000000] Reserving virtual address space above 0xff800000
[    0.000000] Linux version 3.0.4-37.xen0 (root@nt-dev-Cent55-32) (gcc version 4.1.2 20080704 (Red Hat 4.1.2-48)) #1 SMP Tue Dec 13 12:19:21 EST 2011
[    0.000000] released 0 pages of unused memory
[    0.000000] Set 262304 page(s) to 1-1 mapping.
[    0.000000] BIOS-provided physical RAM map:
[    0.000000]  Xen: 0000000000000000 - 00000000000a0000 (usable)
[    0.000000]  Xen: 00000000000a0000 - 0000000000100000 (reserved)
[    0.000000]  Xen: 0000000000100000 - 0000000020000000 (usable)
[    0.000000]  Xen: 0000000020000000 - 00000000bffc0000 (unusable)
[    0.000000]  Xen: 00000000bffc0000 - 00000000bffcfc00 (ACPI data)
[    0.000000]  Xen: 00000000bffcfc00 - 00000000bffff000 (reserved)
[    0.000000]  Xen: 00000000e0000000 - 00000000fec90000 (reserved)
[    0.000000]  Xen: 00000000fed00000 - 00000000fed00400 (reserved)
[    0.000000]  Xen: 00000000fee00000 - 00000000fee10000 (reserved)
[    0.000000]  Xen: 00000000ffb00000 - 0000000100000000 (reserved)
[    0.000000]  Xen: 0000000100000000 - 00000001dffc0000 (usable)
[    0.000000] NX (Execute Disable) protection: active
[    0.000000] DMI 2.3 present.
[    0.000000] last_pfn = 0x1dffc0 max_arch_pfn = 0x1000000
[    0.000000] found SMP MP-table at [c00fe710] fe710
[    0.000000] init_memory_mapping: 0000000000000000-00000000373fe000
[    0.000000] RAMDISK: 016fb000 - 01ab2000
.. snip..
[    0.000000] Placing 64MB software IO TLB between d832cf00 - dc32cf00
[    0.000000] software IO TLB at phys 0x1832cf00 - 0x1c32cf00


And, to let you double check that not chasing a error on my part, this is the place and how I'm seeing the above 4GB address:

last lines of drivers/xen/swiotlb-xen.c:
/*
 * Return whether the given device DMA address mask can be supported
 * properly.  For example, if your device can only drive the low 24-bits
 * during bus mastering, then you would pass 0x00ffffff as the mask to
 * this function.
 */
int
xen_swiotlb_dma_supported(struct device *hwdev, u64 mask)
{
  phys_addr_t phys;
  dma_addr_t tlb_end;
  phys = virt_to_phys(xen_io_tlb_end);
  tlb_end = xen_virt_to_bus(xen_io_tlb_end - 1);
  printk(KERN_ERR "NT_DBG: xen_io_tlb_end: %lx, converted to 'phys': %Lx, then 'bus': %Lx for answer %d.\n",
       xen_io_tlb_end, phys, tlb_end, (tlb_end <= mask));
  return tlb_end <= mask;
//      return xen_virt_to_bus(xen_io_tlb_end - 1) <= mask;
}
EXPORT_SYMBOL_GPL(xen_swiotlb_dma_supported);

Neal

-----Original Message-----
From: Konrad Rzeszutek Wilk [mailto:konrad.r.wilk@gmail.com] On Behalf Of Konrad Rzeszutek Wilk
Sent: Monday, December 12, 2011 4:19 PM
To: Taylor, Neal E
Cc: xen-devel; Kalev, Leonid; Dave, Tushar N
Subject: Re: [Xen-devel] Buffers not reachable by PCI

On Mon, Dec 12, 2011 at 10:11:20PM +0000, Taylor, Neal E wrote:
> We're having trouble getting a serial log. Are there other ways to capture the information you need?
> 
> Attached is a dmesg with 'debug loglevel 8' set on the kernel line... actually, with  
> 
>    #define DEFAULT_MESSAGE_LOGLEVEL 8
> 
> set near the top of printk.c as well, since I wasn't seeing any difference in the log files with loglevel set to 8.

I needed this:

[    0.000000] Reserving virtual address space above 0xff800000
[    0.000000] Linux version 3.0.4-36.xen0 (root@nt-dev-Cent55-32) (gcc version 4.1.2 20080704 (Red Hat 4.1.2-48)) #1 SMP Mon Dec 12 14:54:39 EST 2011
[    0.000000] released 0 pages of unused memory
[    0.000000] 1-1 mapping on a0->100
[    0.000000] 1-1 mapping on bffc0->100000
[    0.000000] Set 262304 page(s) to 1-1 mapping.
[    0.000000] BIOS-provided physical RAM map:
[    0.000000]  Xen: 0000000000000000 - 00000000000a0000 (usable)
[    0.000000]  Xen: 00000000000a0000 - 0000000000100000 (reserved)
[    0.000000]  Xen: 0000000000100000 - 0000000020000000 (usable)
[    0.000000]  Xen: 0000000020000000 - 00000000bffc0000 (unusable)
[    0.000000]  Xen: 00000000bffc0000 - 00000000bffcfc00 (ACPI data)
[    0.000000]  Xen: 00000000bffcfc00 - 00000000bffff000 (reserved)
[    0.000000]  Xen: 00000000e0000000 - 00000000fec90000 (reserved)
[    0.000000]  Xen: 00000000fed00000 - 00000000fed00400 (reserved)
[    0.000000]  Xen: 00000000fee00000 - 00000000fee10000 (reserved)
[    0.000000]  Xen: 00000000ffb00000 - 0000000100000000 (reserved)
[    0.000000]  Xen: 0000000100000000 - 00000001dffc0000 (usable)
[    0.000000] NX (Execute Disable) protection: active
[    0.000000] DMI 2.3 present.
[    0.000000] DMI: Dell Computer Corporation PowerEdge 1850/0RC130, BIOS A05 01/09/2006
[    0.000000] e820 update range: 0000000000000000 - 0000000000010000 (usable) ==> (reserved)
[    0.000000] e820 remove range: 00000000000a0000 - 0000000000100000 (usable)
[    0.000000] last_pfn = 0x1dffc0 max_arch_pfn = 0x1000000
[    0.000000] found SMP MP-table at [c00fe710] fe710
[    0.000000] initial memory mapped : 0 - 023ff000
[    0.000000] Base memory trampoline at [c009f000] 9f000 size 4096
[    0.000000] init_memory_mapping: 0000000000000000-00000000373fe000
[    0.000000]  0000000000 - 00373fe000 page 4k
[    0.000000] kernel direct mapping tables up to 373fe000 @ 2242000-23ff000
[    0.000000] xen: setting RW the range 23ea000 - 23ff000
[    0.000000] RAMDISK: 016fb000 - 01ab2000
.. snip..
[    0.000000] Placing 64MB software IO TLB between d832cf00 - dc32cf00
[    0.000000] software IO TLB at phys 0x1832cf00 - 0x1c32cf00

And that tells me that 1) it is allocated above the 4GB - which
from a PFN perspectivie is not a big deal, as the MFNs are below 4GB
2), but it messes up the other drivers which expect the SWIOTLB to be
under 4GB.


Try this patch:

diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index 8e964b9..600b53c 100644
--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -166,7 +166,7 @@ retry:
 	/*
 	 * Get IO TLB memory from any location.
 	 */
-	xen_io_tlb_start = alloc_bootmem(bytes);
+	xen_io_tlb_start = alloc_bootmem_low(bytes);
 	if (!xen_io_tlb_start) {
 		m = "Cannot allocate Xen-SWIOTLB buffer!\n";
 		goto error;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 19:36:01 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 19:36:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaY8A-0001zK-R6; Tue, 13 Dec 2011 19:35:14 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Neal.Taylor@ca.com>) id 1RaY89-0001zF-5t
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 19:35:13 +0000
X-Env-Sender: Neal.Taylor@ca.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1323804855!8092810!1
X-Originating-IP: [74.125.149.145]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7967 invoked from network); 13 Dec 2011 19:34:17 -0000
Received: from na3sys009aog121.obsmtp.com (HELO na3sys009aog121.obsmtp.com)
	(74.125.149.145)
	by server-15.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Dec 2011 19:34:17 -0000
Received: from USILMS190.ca.com ([141.202.246.44]) (using TLSv1) by
	na3sys009aob121.postini.com ([74.125.148.12]) with SMTP
	ID DSNKTueotuuhSH6JhQQzCugO/gpT2zLzuSE2@postini.com;
	Tue, 13 Dec 2011 11:34:17 PST
Received: from USILMS170.ca.com (141.202.6.20) by USILMS190.ca.com
	(141.202.246.44) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Tue, 13 Dec 2011 14:34:14 -0500
Received: from USILMS110A.ca.com ([169.254.1.109]) by USILMS170.ca.com
	([141.202.6.20]) with mapi id 14.01.0289.001;
	Tue, 13 Dec 2011 14:34:13 -0500
From: "Taylor, Neal E" <Neal.Taylor@ca.com>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
Thread-Topic: [Xen-devel] Buffers not reachable by PCI
Thread-Index: Acy2r+Ulg1PsfbmtTl6QVj0jZAx7mwAK1xcAAIXl/sAAGPmvgAAb3CMA
Date: Tue, 13 Dec 2011 19:34:13 +0000
Message-ID: <3E243B26F475504B9BB0BCC9728B0DA629E183CC@USILMS110A.ca.com>
References: <3E243B26F475504B9BB0BCC9728B0DA629E16E01@USILMS110A.ca.com>
	<20111209203010.GA14412@andromeda.dapyr.net>
	<3E243B26F475504B9BB0BCC9728B0DA629E17AEA@USILMS110A.ca.com>
	<20111213001912.GA2730@konrad-lan>
In-Reply-To: <20111213001912.GA2730@konrad-lan>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [138.42.46.105]
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>, "Kalev,
	Leonid" <Leonid.Kalev@ca.com>, "Dave, Tushar N" <tushar.n.dave@intel.com>
Subject: Re: [Xen-devel] Buffers not reachable by PCI
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

I'm not seeing any difference in symptom or log.

Also, where is the log telling you that it's allocated above 4GB?

Same snippet of the new log:
[    0.000000] Reserving virtual address space above 0xff800000
[    0.000000] Linux version 3.0.4-37.xen0 (root@nt-dev-Cent55-32) (gcc version 4.1.2 20080704 (Red Hat 4.1.2-48)) #1 SMP Tue Dec 13 12:19:21 EST 2011
[    0.000000] released 0 pages of unused memory
[    0.000000] Set 262304 page(s) to 1-1 mapping.
[    0.000000] BIOS-provided physical RAM map:
[    0.000000]  Xen: 0000000000000000 - 00000000000a0000 (usable)
[    0.000000]  Xen: 00000000000a0000 - 0000000000100000 (reserved)
[    0.000000]  Xen: 0000000000100000 - 0000000020000000 (usable)
[    0.000000]  Xen: 0000000020000000 - 00000000bffc0000 (unusable)
[    0.000000]  Xen: 00000000bffc0000 - 00000000bffcfc00 (ACPI data)
[    0.000000]  Xen: 00000000bffcfc00 - 00000000bffff000 (reserved)
[    0.000000]  Xen: 00000000e0000000 - 00000000fec90000 (reserved)
[    0.000000]  Xen: 00000000fed00000 - 00000000fed00400 (reserved)
[    0.000000]  Xen: 00000000fee00000 - 00000000fee10000 (reserved)
[    0.000000]  Xen: 00000000ffb00000 - 0000000100000000 (reserved)
[    0.000000]  Xen: 0000000100000000 - 00000001dffc0000 (usable)
[    0.000000] NX (Execute Disable) protection: active
[    0.000000] DMI 2.3 present.
[    0.000000] last_pfn = 0x1dffc0 max_arch_pfn = 0x1000000
[    0.000000] found SMP MP-table at [c00fe710] fe710
[    0.000000] init_memory_mapping: 0000000000000000-00000000373fe000
[    0.000000] RAMDISK: 016fb000 - 01ab2000
.. snip..
[    0.000000] Placing 64MB software IO TLB between d832cf00 - dc32cf00
[    0.000000] software IO TLB at phys 0x1832cf00 - 0x1c32cf00


And, to let you double check that not chasing a error on my part, this is the place and how I'm seeing the above 4GB address:

last lines of drivers/xen/swiotlb-xen.c:
/*
 * Return whether the given device DMA address mask can be supported
 * properly.  For example, if your device can only drive the low 24-bits
 * during bus mastering, then you would pass 0x00ffffff as the mask to
 * this function.
 */
int
xen_swiotlb_dma_supported(struct device *hwdev, u64 mask)
{
  phys_addr_t phys;
  dma_addr_t tlb_end;
  phys = virt_to_phys(xen_io_tlb_end);
  tlb_end = xen_virt_to_bus(xen_io_tlb_end - 1);
  printk(KERN_ERR "NT_DBG: xen_io_tlb_end: %lx, converted to 'phys': %Lx, then 'bus': %Lx for answer %d.\n",
       xen_io_tlb_end, phys, tlb_end, (tlb_end <= mask));
  return tlb_end <= mask;
//      return xen_virt_to_bus(xen_io_tlb_end - 1) <= mask;
}
EXPORT_SYMBOL_GPL(xen_swiotlb_dma_supported);

Neal

-----Original Message-----
From: Konrad Rzeszutek Wilk [mailto:konrad.r.wilk@gmail.com] On Behalf Of Konrad Rzeszutek Wilk
Sent: Monday, December 12, 2011 4:19 PM
To: Taylor, Neal E
Cc: xen-devel; Kalev, Leonid; Dave, Tushar N
Subject: Re: [Xen-devel] Buffers not reachable by PCI

On Mon, Dec 12, 2011 at 10:11:20PM +0000, Taylor, Neal E wrote:
> We're having trouble getting a serial log. Are there other ways to capture the information you need?
> 
> Attached is a dmesg with 'debug loglevel 8' set on the kernel line... actually, with  
> 
>    #define DEFAULT_MESSAGE_LOGLEVEL 8
> 
> set near the top of printk.c as well, since I wasn't seeing any difference in the log files with loglevel set to 8.

I needed this:

[    0.000000] Reserving virtual address space above 0xff800000
[    0.000000] Linux version 3.0.4-36.xen0 (root@nt-dev-Cent55-32) (gcc version 4.1.2 20080704 (Red Hat 4.1.2-48)) #1 SMP Mon Dec 12 14:54:39 EST 2011
[    0.000000] released 0 pages of unused memory
[    0.000000] 1-1 mapping on a0->100
[    0.000000] 1-1 mapping on bffc0->100000
[    0.000000] Set 262304 page(s) to 1-1 mapping.
[    0.000000] BIOS-provided physical RAM map:
[    0.000000]  Xen: 0000000000000000 - 00000000000a0000 (usable)
[    0.000000]  Xen: 00000000000a0000 - 0000000000100000 (reserved)
[    0.000000]  Xen: 0000000000100000 - 0000000020000000 (usable)
[    0.000000]  Xen: 0000000020000000 - 00000000bffc0000 (unusable)
[    0.000000]  Xen: 00000000bffc0000 - 00000000bffcfc00 (ACPI data)
[    0.000000]  Xen: 00000000bffcfc00 - 00000000bffff000 (reserved)
[    0.000000]  Xen: 00000000e0000000 - 00000000fec90000 (reserved)
[    0.000000]  Xen: 00000000fed00000 - 00000000fed00400 (reserved)
[    0.000000]  Xen: 00000000fee00000 - 00000000fee10000 (reserved)
[    0.000000]  Xen: 00000000ffb00000 - 0000000100000000 (reserved)
[    0.000000]  Xen: 0000000100000000 - 00000001dffc0000 (usable)
[    0.000000] NX (Execute Disable) protection: active
[    0.000000] DMI 2.3 present.
[    0.000000] DMI: Dell Computer Corporation PowerEdge 1850/0RC130, BIOS A05 01/09/2006
[    0.000000] e820 update range: 0000000000000000 - 0000000000010000 (usable) ==> (reserved)
[    0.000000] e820 remove range: 00000000000a0000 - 0000000000100000 (usable)
[    0.000000] last_pfn = 0x1dffc0 max_arch_pfn = 0x1000000
[    0.000000] found SMP MP-table at [c00fe710] fe710
[    0.000000] initial memory mapped : 0 - 023ff000
[    0.000000] Base memory trampoline at [c009f000] 9f000 size 4096
[    0.000000] init_memory_mapping: 0000000000000000-00000000373fe000
[    0.000000]  0000000000 - 00373fe000 page 4k
[    0.000000] kernel direct mapping tables up to 373fe000 @ 2242000-23ff000
[    0.000000] xen: setting RW the range 23ea000 - 23ff000
[    0.000000] RAMDISK: 016fb000 - 01ab2000
.. snip..
[    0.000000] Placing 64MB software IO TLB between d832cf00 - dc32cf00
[    0.000000] software IO TLB at phys 0x1832cf00 - 0x1c32cf00

And that tells me that 1) it is allocated above the 4GB - which
from a PFN perspectivie is not a big deal, as the MFNs are below 4GB
2), but it messes up the other drivers which expect the SWIOTLB to be
under 4GB.


Try this patch:

diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index 8e964b9..600b53c 100644
--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -166,7 +166,7 @@ retry:
 	/*
 	 * Get IO TLB memory from any location.
 	 */
-	xen_io_tlb_start = alloc_bootmem(bytes);
+	xen_io_tlb_start = alloc_bootmem_low(bytes);
 	if (!xen_io_tlb_start) {
 		m = "Cannot allocate Xen-SWIOTLB buffer!\n";
 		goto error;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 19:54:45 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 19:54:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaYQT-0002D9-GG; Tue, 13 Dec 2011 19:54:09 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RaYQR-0002D1-6v
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 19:54:07 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1323805989!5398766!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTI1NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11542 invoked from network); 13 Dec 2011 19:53:10 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 19:53:10 -0000
X-IronPort-AV: E=Sophos;i="4.71,347,1320624000"; 
   d="scan'208";a="9449231"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Dec 2011 19:53:09 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 13 Dec 2011 19:53:09 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RaYPU-0000VB-Ml;
	Tue, 13 Dec 2011 19:53:08 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RaYPU-0001ut-EX;
	Tue, 13 Dec 2011 19:53:08 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10490-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 13 Dec 2011 19:53:08 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10490: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10490 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10490/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install          fail like 10489
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xend-winxpsp3  7 windows-install              fail  like 10489
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  03138a08366b
baseline version:
 xen                  3b563fbde6e0

------------------------------------------------------------
People who touched revisions under test:
  Adda Rathbone <addarathbone@googlemail.com>
  Andrew Pounce <andrew.pounce@citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Miroslav Rezanina <mrezanin@redhat.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-unstable
+ revision=03138a08366b
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-unstable 03138a08366b
+ branch=xen-unstable
+ revision=03138a08366b
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ : xen@xenbits.xensource.com
+ : xen@xenbits.xensource.com:git/linux-pvops
+ : master
+ : tested/2.6.39.x
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r 03138a08366b ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 9 changesets with 16 changes to 14 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 19:54:45 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 19:54:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaYQT-0002D9-GG; Tue, 13 Dec 2011 19:54:09 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RaYQR-0002D1-6v
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 19:54:07 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1323805989!5398766!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTI1NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11542 invoked from network); 13 Dec 2011 19:53:10 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 19:53:10 -0000
X-IronPort-AV: E=Sophos;i="4.71,347,1320624000"; 
   d="scan'208";a="9449231"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Dec 2011 19:53:09 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 13 Dec 2011 19:53:09 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RaYPU-0000VB-Ml;
	Tue, 13 Dec 2011 19:53:08 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RaYPU-0001ut-EX;
	Tue, 13 Dec 2011 19:53:08 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10490-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 13 Dec 2011 19:53:08 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10490: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10490 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10490/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install          fail like 10489
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xend-winxpsp3  7 windows-install              fail  like 10489
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  03138a08366b
baseline version:
 xen                  3b563fbde6e0

------------------------------------------------------------
People who touched revisions under test:
  Adda Rathbone <addarathbone@googlemail.com>
  Andrew Pounce <andrew.pounce@citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Miroslav Rezanina <mrezanin@redhat.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-unstable
+ revision=03138a08366b
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-unstable 03138a08366b
+ branch=xen-unstable
+ revision=03138a08366b
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ : xen@xenbits.xensource.com
+ : xen@xenbits.xensource.com:git/linux-pvops
+ : master
+ : tested/2.6.39.x
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r 03138a08366b ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 9 changesets with 16 changes to 14 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 20:39:57 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 20:39:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaZ8S-0003Dc-Ew; Tue, 13 Dec 2011 20:39:36 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RaZ8R-0003C6-OA
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 20:39:35 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-8.tower-21.messagelabs.com!1323808720!8083753!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25564 invoked from network); 13 Dec 2011 20:38:41 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-8.tower-21.messagelabs.com with SMTP;
	13 Dec 2011 20:38:41 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea01.nsa.gov (8.12.10/8.12.10) with ESMTP id
	pBDKcdRx010715; Tue, 13 Dec 2011 20:38:39 GMT
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id pBDKcdnv017251; 
	Tue, 13 Dec 2011 15:38:39 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com, Keir Fraser <keir@xen.org>
Date: Tue, 13 Dec 2011 15:38:50 -0500
Message-Id: <1323808737-29125-2-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.4
In-Reply-To: <1323808737-29125-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1323808737-29125-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 1/8] xsm/flask: Add missing unlock on error path
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 xen/xsm/flask/ss/services.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/xen/xsm/flask/ss/services.c b/xen/xsm/flask/ss/services.c
index c810e9b..7b08e73 100644
--- a/xen/xsm/flask/ss/services.c
+++ b/xen/xsm/flask/ss/services.c
@@ -1428,6 +1428,7 @@ int security_load_policy(void *data, size_t len)
         }
         if ( validate_classes(&policydb) )
         {
+            LOAD_UNLOCK;
             printk(KERN_ERR
                    "Flask:  the definition of a class is incorrect\n");
             sidtab_destroy(&sidtab);
-- 
1.7.7.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 20:39:57 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 20:39:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaZ8U-0003Ea-44; Tue, 13 Dec 2011 20:39:38 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RaZ8S-0003CB-2w
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 20:39:36 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-10.tower-21.messagelabs.com!1323808720!7832077!1
X-Originating-IP: [63.239.65.40]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26642 invoked from network); 13 Dec 2011 20:38:41 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-10.tower-21.messagelabs.com with SMTP;
	13 Dec 2011 20:38:41 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea02.nsa.gov (8.12.10/8.12.10) with ESMTP id
	pBDKcexP012683; Tue, 13 Dec 2011 20:38:40 GMT
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id pBDKcdo0017251; 
	Tue, 13 Dec 2011 15:38:39 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com, Keir Fraser <keir@xen.org>
Date: Tue, 13 Dec 2011 15:38:53 -0500
Message-Id: <1323808737-29125-5-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.4
In-Reply-To: <1323808737-29125-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1323808737-29125-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 4/8] xsm: add remote_remap permission
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

The mmu_update hypercall can be used to manipulate the page tables of a
remote domain. Add a check for this in the XSM hook in addition to
the existing check on mapping pages of a remote domain.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 tools/flask/policy/policy/flask/access_vectors |    1 +
 xen/arch/x86/mm.c                              |    2 +-
 xen/include/xsm/xsm.h                          |   10 +++++-----
 xen/xsm/dummy.c                                |    4 ++--
 xen/xsm/flask/hooks.c                          |    9 +++++++--
 xen/xsm/flask/include/av_perm_to_string.h      |    1 +
 xen/xsm/flask/include/av_permissions.h         |    1 +
 7 files changed, 18 insertions(+), 10 deletions(-)

diff --git a/tools/flask/policy/policy/flask/access_vectors b/tools/flask/policy/policy/flask/access_vectors
index 1b2687a..38036d0 100644
--- a/tools/flask/policy/policy/flask/access_vectors
+++ b/tools/flask/policy/policy/flask/access_vectors
@@ -128,6 +128,7 @@ class mmu
     pinpage
     mfnlist
     memorymap
+    remote_remap
 }
 
 class shadow
diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index 7bb3ea1..19391fc 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -3517,7 +3517,7 @@ int do_mmu_update(
         {
             p2m_type_t p2mt;
 
-            rc = xsm_mmu_normal_update(d, pg_owner, req.val);
+            rc = xsm_mmu_normal_update(d, pt_owner, pg_owner, req.val);
             if ( rc )
                 break;
             rc = -EINVAL;
diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
index ce3b6aa..43829c7 100644
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -141,8 +141,8 @@ struct xsm_operations {
     int (*getidletime) (void);
     int (*machine_memory_map) (void);
     int (*domain_memory_map) (struct domain *d);
-    int (*mmu_normal_update) (struct domain *d, struct domain *f, 
-                                                                intpte_t fpte);
+    int (*mmu_normal_update) (struct domain *d, struct domain *t,
+                              struct domain *f, intpte_t fpte);
     int (*mmu_machphys_update) (struct domain *d, unsigned long mfn);
     int (*update_va_mapping) (struct domain *d, struct domain *f, 
                                                             l1_pgentry_t pte);
@@ -593,10 +593,10 @@ static inline int xsm_domain_memory_map(struct domain *d)
     return xsm_call(domain_memory_map(d));
 }
 
-static inline int xsm_mmu_normal_update (struct domain *d, struct domain *f, 
-                                                                intpte_t fpte)
+static inline int xsm_mmu_normal_update (struct domain *d, struct domain *t,
+                                         struct domain *f, intpte_t fpte)
 {
-    return xsm_call(mmu_normal_update(d, f, fpte));
+    return xsm_call(mmu_normal_update(d, t, f, fpte));
 }
 
 static inline int xsm_mmu_machphys_update (struct domain *d, unsigned long mfn)
diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c
index d6f2da0..7066dfb 100644
--- a/xen/xsm/dummy.c
+++ b/xen/xsm/dummy.c
@@ -399,8 +399,8 @@ static int dummy_domain_memory_map (struct domain *d)
     return 0;
 }
 
-static int dummy_mmu_normal_update (struct domain *d, struct domain *f, 
-                                                                intpte_t fpte)
+static int dummy_mmu_normal_update (struct domain *d, struct domain *t,
+                                    struct domain *f, intpte_t fpte)
 {
     return 0;
 }
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index 1a3f3b3..04c2f68 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -1008,8 +1008,8 @@ static int flask_domain_memory_map(struct domain *d)
     return domain_has_perm(current->domain, d, SECCLASS_MMU, MMU__MEMORYMAP);
 }
 
-static int flask_mmu_normal_update(struct domain *d, struct domain *f, 
-                                   intpte_t fpte)
+static int flask_mmu_normal_update(struct domain *d, struct domain *t,
+                                   struct domain *f, intpte_t fpte)
 {
     int rc = 0;
     u32 map_perms = MMU__MAP_READ;
@@ -1017,6 +1017,11 @@ static int flask_mmu_normal_update(struct domain *d, struct domain *f,
     struct domain_security_struct *dsec;
     u32 fsid;
 
+    if (d != t)
+        rc = domain_has_perm(d, t, SECCLASS_MMU, MMU__REMOTE_REMAP);
+    if ( rc )
+        return rc;
+
     if ( !(l1e_get_flags(l1e_from_intpte(fpte)) & _PAGE_PRESENT) )
         return 0;
 
diff --git a/xen/xsm/flask/include/av_perm_to_string.h b/xen/xsm/flask/include/av_perm_to_string.h
index 70aa02d..56572a7 100644
--- a/xen/xsm/flask/include/av_perm_to_string.h
+++ b/xen/xsm/flask/include/av_perm_to_string.h
@@ -87,6 +87,7 @@
    S_(SECCLASS_MMU, MMU__PINPAGE, "pinpage")
    S_(SECCLASS_MMU, MMU__MFNLIST, "mfnlist")
    S_(SECCLASS_MMU, MMU__MEMORYMAP, "memorymap")
+   S_(SECCLASS_MMU, MMU__REMOTE_REMAP, "remote_remap")
    S_(SECCLASS_SHADOW, SHADOW__DISABLE, "disable")
    S_(SECCLASS_SHADOW, SHADOW__ENABLE, "enable")
    S_(SECCLASS_SHADOW, SHADOW__LOGDIRTY, "logdirty")
diff --git a/xen/xsm/flask/include/av_permissions.h b/xen/xsm/flask/include/av_permissions.h
index 4c2ffb6..67511ad 100644
--- a/xen/xsm/flask/include/av_permissions.h
+++ b/xen/xsm/flask/include/av_permissions.h
@@ -92,6 +92,7 @@
 #define MMU__PINPAGE                              0x00000200UL
 #define MMU__MFNLIST                              0x00000400UL
 #define MMU__MEMORYMAP                            0x00000800UL
+#define MMU__REMOTE_REMAP                         0x00001000UL
 
 #define SHADOW__DISABLE                           0x00000001UL
 #define SHADOW__ENABLE                            0x00000002UL
-- 
1.7.7.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 20:39:57 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 20:39:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaZ8V-0003G5-2C; Tue, 13 Dec 2011 20:39:39 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RaZ8S-0003CH-Pz
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 20:39:37 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-10.tower-174.messagelabs.com!1323808721!5433785!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3285 invoked from network); 13 Dec 2011 20:38:41 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-10.tower-174.messagelabs.com with SMTP;
	13 Dec 2011 20:38:41 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea01.nsa.gov (8.12.10/8.12.10) with ESMTP id
	pBDKceRx010719; Tue, 13 Dec 2011 20:38:40 GMT
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id pBDKcdo2017251; 
	Tue, 13 Dec 2011 15:38:40 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com, Keir Fraser <keir@xen.org>
Date: Tue, 13 Dec 2011 15:38:55 -0500
Message-Id: <1323808737-29125-7-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.4
In-Reply-To: <1323808737-29125-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1323808737-29125-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 6/8] xsm: fix up dummy ops
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 xen/xsm/dummy.c |  146 +++++++++++++++++++++++++++++++++++++++++++++++--------
 1 files changed, 126 insertions(+), 20 deletions(-)

diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c
index 7066dfb..a4accb8 100644
--- a/xen/xsm/dummy.c
+++ b/xen/xsm/dummy.c
@@ -89,6 +89,11 @@ static int dummy_set_target (struct domain *d, struct domain *e)
     return 0;
 }
 
+static int dummy_domctl(struct domain *d, int cmd)
+{
+    return 0;
+}
+
 static int dummy_tbufcontrol (void)
 {
     return 0;
@@ -139,11 +144,21 @@ static int dummy_get_pmstat (void)
     return 0;
 }
 
+static int dummy_setpminfo (void)
+{
+    return 0;
+}
+
 static int dummy_pm_op (void)
 {
     return 0;
 }
 
+static int dummy_do_mca (void)
+{
+    return 0;
+}
+
 static int dummy_availheap (void)
 {
     return 0;
@@ -268,6 +283,77 @@ static void dummy_free_security_evtchn (struct evtchn *chn)
     return;
 }
 
+static int dummy_test_assign_device (uint32_t machine_bdf)
+{
+    return 0;
+}
+
+static int dummy_assign_device (struct domain *d, uint32_t machine_bdf)
+{
+    return 0;
+}
+
+static int dummy_deassign_device (struct domain *d, uint32_t machine_bdf)
+{
+    return 0;
+}
+
+static int dummy_resource_plug_core (void)
+{
+    return 0;
+}
+
+static int dummy_resource_unplug_core (void)
+{
+    return 0;
+}
+
+static int dummy_resource_plug_pci (uint32_t machine_bdf)
+{
+    return 0;
+}
+
+static int dummy_resource_unplug_pci (uint32_t machine_bdf)
+{
+    return 0;
+}
+
+static int dummy_resource_setup_pci (uint32_t machine_bdf)
+{
+    return 0;
+}
+
+static int dummy_resource_setup_gsi (int gsi)
+{
+    return 0;
+}
+
+static int dummy_resource_setup_misc (void)
+{
+    return 0;
+}
+
+static int dummy_page_offline (uint32_t cmd)
+{
+    return 0;
+}
+
+static int dummy_lockprof (void)
+{
+    return 0;
+}
+
+static int dummy_cpupool_op (void)
+{
+    return 0;
+}
+
+static int dummy_sched_op (void)
+{
+    return 0;
+}
+
+
 static long dummy___do_xsm_op(XEN_GUEST_HANDLE(xsm_op_t) op)
 {
     return -ENOSYS;
@@ -339,6 +425,21 @@ static int dummy_hvm_set_pci_link_route (struct domain *d)
     return 0;
 }
 
+static int dummy_hvm_inject_msi (struct domain *d)
+{
+    return 0;
+}
+
+static int dummy_mem_event (struct domain *d)
+{
+    return 0;
+}
+
+static int dummy_mem_sharing (struct domain *d)
+{
+    return 0;
+}
+
 static int dummy_apic (struct domain *d, int cmd)
 {
     return 0;
@@ -426,21 +527,6 @@ static int dummy_sendtrigger (struct domain *d)
     return 0;
 }
 
-static int dummy_test_assign_device (uint32_t machine_bdf)
-{
-    return 0;
-}
-
-static int dummy_assign_device (struct domain *d, uint32_t machine_bdf)
-{
-    return 0;
-}
-
-static int dummy_deassign_device (struct domain *d, uint32_t machine_bdf)
-{
-    return 0;
-}
-
 static int dummy_bind_pt_irq (struct domain *d, struct xen_domctl_bind_pt_irq *bind)
 {
     return 0;
@@ -497,6 +583,7 @@ void xsm_fixup_ops (struct xsm_operations *ops)
     set_to_dummy_if_null(ops, getvcpuinfo);
     set_to_dummy_if_null(ops, domain_settime);
     set_to_dummy_if_null(ops, set_target);
+    set_to_dummy_if_null(ops, domctl);
     set_to_dummy_if_null(ops, tbufcontrol);
     set_to_dummy_if_null(ops, readconsole);
     set_to_dummy_if_null(ops, sched_id);
@@ -506,9 +593,11 @@ void xsm_fixup_ops (struct xsm_operations *ops)
     set_to_dummy_if_null(ops, perfcontrol);
     set_to_dummy_if_null(ops, debug_keys);
     set_to_dummy_if_null(ops, getcpuinfo);
-    set_to_dummy_if_null(ops, pm_op);
-    set_to_dummy_if_null(ops, get_pmstat);
     set_to_dummy_if_null(ops, availheap);
+    set_to_dummy_if_null(ops, get_pmstat);
+    set_to_dummy_if_null(ops, setpminfo);
+    set_to_dummy_if_null(ops, pm_op);
+    set_to_dummy_if_null(ops, do_mca);
 
     set_to_dummy_if_null(ops, evtchn_unbound);
     set_to_dummy_if_null(ops, evtchn_interdomain);
@@ -543,6 +632,23 @@ void xsm_fixup_ops (struct xsm_operations *ops)
     set_to_dummy_if_null(ops, irq_permission);
     set_to_dummy_if_null(ops, iomem_permission);
 
+    set_to_dummy_if_null(ops, test_assign_device);
+    set_to_dummy_if_null(ops, assign_device);
+    set_to_dummy_if_null(ops, deassign_device);
+
+    set_to_dummy_if_null(ops, resource_plug_core);
+    set_to_dummy_if_null(ops, resource_unplug_core);
+    set_to_dummy_if_null(ops, resource_plug_pci);
+    set_to_dummy_if_null(ops, resource_unplug_pci);
+    set_to_dummy_if_null(ops, resource_setup_pci);
+    set_to_dummy_if_null(ops, resource_setup_gsi);
+    set_to_dummy_if_null(ops, resource_setup_misc);
+
+    set_to_dummy_if_null(ops, page_offline);
+    set_to_dummy_if_null(ops, lockprof);
+    set_to_dummy_if_null(ops, cpupool_op);
+    set_to_dummy_if_null(ops, sched_op);
+
     set_to_dummy_if_null(ops, __do_xsm_op);
 
 #ifdef CONFIG_X86
@@ -557,6 +663,9 @@ void xsm_fixup_ops (struct xsm_operations *ops)
     set_to_dummy_if_null(ops, hvm_set_pci_intx_level);
     set_to_dummy_if_null(ops, hvm_set_isa_irq_level);
     set_to_dummy_if_null(ops, hvm_set_pci_link_route);
+    set_to_dummy_if_null(ops, hvm_inject_msi);
+    set_to_dummy_if_null(ops, mem_event);
+    set_to_dummy_if_null(ops, mem_sharing);
     set_to_dummy_if_null(ops, apic);
     set_to_dummy_if_null(ops, xen_settime);
     set_to_dummy_if_null(ops, memtype);
@@ -574,9 +683,6 @@ void xsm_fixup_ops (struct xsm_operations *ops)
     set_to_dummy_if_null(ops, update_va_mapping);
     set_to_dummy_if_null(ops, add_to_physmap);
     set_to_dummy_if_null(ops, sendtrigger);
-    set_to_dummy_if_null(ops, test_assign_device);
-    set_to_dummy_if_null(ops, assign_device);
-    set_to_dummy_if_null(ops, deassign_device);
     set_to_dummy_if_null(ops, bind_pt_irq);
     set_to_dummy_if_null(ops, pin_mem_cacheattr);
     set_to_dummy_if_null(ops, ext_vcpucontext);
-- 
1.7.7.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 20:39:57 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 20:39:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaZ8U-0003Ea-44; Tue, 13 Dec 2011 20:39:38 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RaZ8S-0003CB-2w
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 20:39:36 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-10.tower-21.messagelabs.com!1323808720!7832077!1
X-Originating-IP: [63.239.65.40]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26642 invoked from network); 13 Dec 2011 20:38:41 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-10.tower-21.messagelabs.com with SMTP;
	13 Dec 2011 20:38:41 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea02.nsa.gov (8.12.10/8.12.10) with ESMTP id
	pBDKcexP012683; Tue, 13 Dec 2011 20:38:40 GMT
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id pBDKcdo0017251; 
	Tue, 13 Dec 2011 15:38:39 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com, Keir Fraser <keir@xen.org>
Date: Tue, 13 Dec 2011 15:38:53 -0500
Message-Id: <1323808737-29125-5-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.4
In-Reply-To: <1323808737-29125-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1323808737-29125-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 4/8] xsm: add remote_remap permission
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

The mmu_update hypercall can be used to manipulate the page tables of a
remote domain. Add a check for this in the XSM hook in addition to
the existing check on mapping pages of a remote domain.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 tools/flask/policy/policy/flask/access_vectors |    1 +
 xen/arch/x86/mm.c                              |    2 +-
 xen/include/xsm/xsm.h                          |   10 +++++-----
 xen/xsm/dummy.c                                |    4 ++--
 xen/xsm/flask/hooks.c                          |    9 +++++++--
 xen/xsm/flask/include/av_perm_to_string.h      |    1 +
 xen/xsm/flask/include/av_permissions.h         |    1 +
 7 files changed, 18 insertions(+), 10 deletions(-)

diff --git a/tools/flask/policy/policy/flask/access_vectors b/tools/flask/policy/policy/flask/access_vectors
index 1b2687a..38036d0 100644
--- a/tools/flask/policy/policy/flask/access_vectors
+++ b/tools/flask/policy/policy/flask/access_vectors
@@ -128,6 +128,7 @@ class mmu
     pinpage
     mfnlist
     memorymap
+    remote_remap
 }
 
 class shadow
diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index 7bb3ea1..19391fc 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -3517,7 +3517,7 @@ int do_mmu_update(
         {
             p2m_type_t p2mt;
 
-            rc = xsm_mmu_normal_update(d, pg_owner, req.val);
+            rc = xsm_mmu_normal_update(d, pt_owner, pg_owner, req.val);
             if ( rc )
                 break;
             rc = -EINVAL;
diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
index ce3b6aa..43829c7 100644
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -141,8 +141,8 @@ struct xsm_operations {
     int (*getidletime) (void);
     int (*machine_memory_map) (void);
     int (*domain_memory_map) (struct domain *d);
-    int (*mmu_normal_update) (struct domain *d, struct domain *f, 
-                                                                intpte_t fpte);
+    int (*mmu_normal_update) (struct domain *d, struct domain *t,
+                              struct domain *f, intpte_t fpte);
     int (*mmu_machphys_update) (struct domain *d, unsigned long mfn);
     int (*update_va_mapping) (struct domain *d, struct domain *f, 
                                                             l1_pgentry_t pte);
@@ -593,10 +593,10 @@ static inline int xsm_domain_memory_map(struct domain *d)
     return xsm_call(domain_memory_map(d));
 }
 
-static inline int xsm_mmu_normal_update (struct domain *d, struct domain *f, 
-                                                                intpte_t fpte)
+static inline int xsm_mmu_normal_update (struct domain *d, struct domain *t,
+                                         struct domain *f, intpte_t fpte)
 {
-    return xsm_call(mmu_normal_update(d, f, fpte));
+    return xsm_call(mmu_normal_update(d, t, f, fpte));
 }
 
 static inline int xsm_mmu_machphys_update (struct domain *d, unsigned long mfn)
diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c
index d6f2da0..7066dfb 100644
--- a/xen/xsm/dummy.c
+++ b/xen/xsm/dummy.c
@@ -399,8 +399,8 @@ static int dummy_domain_memory_map (struct domain *d)
     return 0;
 }
 
-static int dummy_mmu_normal_update (struct domain *d, struct domain *f, 
-                                                                intpte_t fpte)
+static int dummy_mmu_normal_update (struct domain *d, struct domain *t,
+                                    struct domain *f, intpte_t fpte)
 {
     return 0;
 }
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index 1a3f3b3..04c2f68 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -1008,8 +1008,8 @@ static int flask_domain_memory_map(struct domain *d)
     return domain_has_perm(current->domain, d, SECCLASS_MMU, MMU__MEMORYMAP);
 }
 
-static int flask_mmu_normal_update(struct domain *d, struct domain *f, 
-                                   intpte_t fpte)
+static int flask_mmu_normal_update(struct domain *d, struct domain *t,
+                                   struct domain *f, intpte_t fpte)
 {
     int rc = 0;
     u32 map_perms = MMU__MAP_READ;
@@ -1017,6 +1017,11 @@ static int flask_mmu_normal_update(struct domain *d, struct domain *f,
     struct domain_security_struct *dsec;
     u32 fsid;
 
+    if (d != t)
+        rc = domain_has_perm(d, t, SECCLASS_MMU, MMU__REMOTE_REMAP);
+    if ( rc )
+        return rc;
+
     if ( !(l1e_get_flags(l1e_from_intpte(fpte)) & _PAGE_PRESENT) )
         return 0;
 
diff --git a/xen/xsm/flask/include/av_perm_to_string.h b/xen/xsm/flask/include/av_perm_to_string.h
index 70aa02d..56572a7 100644
--- a/xen/xsm/flask/include/av_perm_to_string.h
+++ b/xen/xsm/flask/include/av_perm_to_string.h
@@ -87,6 +87,7 @@
    S_(SECCLASS_MMU, MMU__PINPAGE, "pinpage")
    S_(SECCLASS_MMU, MMU__MFNLIST, "mfnlist")
    S_(SECCLASS_MMU, MMU__MEMORYMAP, "memorymap")
+   S_(SECCLASS_MMU, MMU__REMOTE_REMAP, "remote_remap")
    S_(SECCLASS_SHADOW, SHADOW__DISABLE, "disable")
    S_(SECCLASS_SHADOW, SHADOW__ENABLE, "enable")
    S_(SECCLASS_SHADOW, SHADOW__LOGDIRTY, "logdirty")
diff --git a/xen/xsm/flask/include/av_permissions.h b/xen/xsm/flask/include/av_permissions.h
index 4c2ffb6..67511ad 100644
--- a/xen/xsm/flask/include/av_permissions.h
+++ b/xen/xsm/flask/include/av_permissions.h
@@ -92,6 +92,7 @@
 #define MMU__PINPAGE                              0x00000200UL
 #define MMU__MFNLIST                              0x00000400UL
 #define MMU__MEMORYMAP                            0x00000800UL
+#define MMU__REMOTE_REMAP                         0x00001000UL
 
 #define SHADOW__DISABLE                           0x00000001UL
 #define SHADOW__ENABLE                            0x00000002UL
-- 
1.7.7.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 20:39:57 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 20:39:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaZ8V-0003G5-2C; Tue, 13 Dec 2011 20:39:39 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RaZ8S-0003CH-Pz
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 20:39:37 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-10.tower-174.messagelabs.com!1323808721!5433785!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3285 invoked from network); 13 Dec 2011 20:38:41 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-10.tower-174.messagelabs.com with SMTP;
	13 Dec 2011 20:38:41 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea01.nsa.gov (8.12.10/8.12.10) with ESMTP id
	pBDKceRx010719; Tue, 13 Dec 2011 20:38:40 GMT
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id pBDKcdo2017251; 
	Tue, 13 Dec 2011 15:38:40 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com, Keir Fraser <keir@xen.org>
Date: Tue, 13 Dec 2011 15:38:55 -0500
Message-Id: <1323808737-29125-7-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.4
In-Reply-To: <1323808737-29125-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1323808737-29125-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 6/8] xsm: fix up dummy ops
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 xen/xsm/dummy.c |  146 +++++++++++++++++++++++++++++++++++++++++++++++--------
 1 files changed, 126 insertions(+), 20 deletions(-)

diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c
index 7066dfb..a4accb8 100644
--- a/xen/xsm/dummy.c
+++ b/xen/xsm/dummy.c
@@ -89,6 +89,11 @@ static int dummy_set_target (struct domain *d, struct domain *e)
     return 0;
 }
 
+static int dummy_domctl(struct domain *d, int cmd)
+{
+    return 0;
+}
+
 static int dummy_tbufcontrol (void)
 {
     return 0;
@@ -139,11 +144,21 @@ static int dummy_get_pmstat (void)
     return 0;
 }
 
+static int dummy_setpminfo (void)
+{
+    return 0;
+}
+
 static int dummy_pm_op (void)
 {
     return 0;
 }
 
+static int dummy_do_mca (void)
+{
+    return 0;
+}
+
 static int dummy_availheap (void)
 {
     return 0;
@@ -268,6 +283,77 @@ static void dummy_free_security_evtchn (struct evtchn *chn)
     return;
 }
 
+static int dummy_test_assign_device (uint32_t machine_bdf)
+{
+    return 0;
+}
+
+static int dummy_assign_device (struct domain *d, uint32_t machine_bdf)
+{
+    return 0;
+}
+
+static int dummy_deassign_device (struct domain *d, uint32_t machine_bdf)
+{
+    return 0;
+}
+
+static int dummy_resource_plug_core (void)
+{
+    return 0;
+}
+
+static int dummy_resource_unplug_core (void)
+{
+    return 0;
+}
+
+static int dummy_resource_plug_pci (uint32_t machine_bdf)
+{
+    return 0;
+}
+
+static int dummy_resource_unplug_pci (uint32_t machine_bdf)
+{
+    return 0;
+}
+
+static int dummy_resource_setup_pci (uint32_t machine_bdf)
+{
+    return 0;
+}
+
+static int dummy_resource_setup_gsi (int gsi)
+{
+    return 0;
+}
+
+static int dummy_resource_setup_misc (void)
+{
+    return 0;
+}
+
+static int dummy_page_offline (uint32_t cmd)
+{
+    return 0;
+}
+
+static int dummy_lockprof (void)
+{
+    return 0;
+}
+
+static int dummy_cpupool_op (void)
+{
+    return 0;
+}
+
+static int dummy_sched_op (void)
+{
+    return 0;
+}
+
+
 static long dummy___do_xsm_op(XEN_GUEST_HANDLE(xsm_op_t) op)
 {
     return -ENOSYS;
@@ -339,6 +425,21 @@ static int dummy_hvm_set_pci_link_route (struct domain *d)
     return 0;
 }
 
+static int dummy_hvm_inject_msi (struct domain *d)
+{
+    return 0;
+}
+
+static int dummy_mem_event (struct domain *d)
+{
+    return 0;
+}
+
+static int dummy_mem_sharing (struct domain *d)
+{
+    return 0;
+}
+
 static int dummy_apic (struct domain *d, int cmd)
 {
     return 0;
@@ -426,21 +527,6 @@ static int dummy_sendtrigger (struct domain *d)
     return 0;
 }
 
-static int dummy_test_assign_device (uint32_t machine_bdf)
-{
-    return 0;
-}
-
-static int dummy_assign_device (struct domain *d, uint32_t machine_bdf)
-{
-    return 0;
-}
-
-static int dummy_deassign_device (struct domain *d, uint32_t machine_bdf)
-{
-    return 0;
-}
-
 static int dummy_bind_pt_irq (struct domain *d, struct xen_domctl_bind_pt_irq *bind)
 {
     return 0;
@@ -497,6 +583,7 @@ void xsm_fixup_ops (struct xsm_operations *ops)
     set_to_dummy_if_null(ops, getvcpuinfo);
     set_to_dummy_if_null(ops, domain_settime);
     set_to_dummy_if_null(ops, set_target);
+    set_to_dummy_if_null(ops, domctl);
     set_to_dummy_if_null(ops, tbufcontrol);
     set_to_dummy_if_null(ops, readconsole);
     set_to_dummy_if_null(ops, sched_id);
@@ -506,9 +593,11 @@ void xsm_fixup_ops (struct xsm_operations *ops)
     set_to_dummy_if_null(ops, perfcontrol);
     set_to_dummy_if_null(ops, debug_keys);
     set_to_dummy_if_null(ops, getcpuinfo);
-    set_to_dummy_if_null(ops, pm_op);
-    set_to_dummy_if_null(ops, get_pmstat);
     set_to_dummy_if_null(ops, availheap);
+    set_to_dummy_if_null(ops, get_pmstat);
+    set_to_dummy_if_null(ops, setpminfo);
+    set_to_dummy_if_null(ops, pm_op);
+    set_to_dummy_if_null(ops, do_mca);
 
     set_to_dummy_if_null(ops, evtchn_unbound);
     set_to_dummy_if_null(ops, evtchn_interdomain);
@@ -543,6 +632,23 @@ void xsm_fixup_ops (struct xsm_operations *ops)
     set_to_dummy_if_null(ops, irq_permission);
     set_to_dummy_if_null(ops, iomem_permission);
 
+    set_to_dummy_if_null(ops, test_assign_device);
+    set_to_dummy_if_null(ops, assign_device);
+    set_to_dummy_if_null(ops, deassign_device);
+
+    set_to_dummy_if_null(ops, resource_plug_core);
+    set_to_dummy_if_null(ops, resource_unplug_core);
+    set_to_dummy_if_null(ops, resource_plug_pci);
+    set_to_dummy_if_null(ops, resource_unplug_pci);
+    set_to_dummy_if_null(ops, resource_setup_pci);
+    set_to_dummy_if_null(ops, resource_setup_gsi);
+    set_to_dummy_if_null(ops, resource_setup_misc);
+
+    set_to_dummy_if_null(ops, page_offline);
+    set_to_dummy_if_null(ops, lockprof);
+    set_to_dummy_if_null(ops, cpupool_op);
+    set_to_dummy_if_null(ops, sched_op);
+
     set_to_dummy_if_null(ops, __do_xsm_op);
 
 #ifdef CONFIG_X86
@@ -557,6 +663,9 @@ void xsm_fixup_ops (struct xsm_operations *ops)
     set_to_dummy_if_null(ops, hvm_set_pci_intx_level);
     set_to_dummy_if_null(ops, hvm_set_isa_irq_level);
     set_to_dummy_if_null(ops, hvm_set_pci_link_route);
+    set_to_dummy_if_null(ops, hvm_inject_msi);
+    set_to_dummy_if_null(ops, mem_event);
+    set_to_dummy_if_null(ops, mem_sharing);
     set_to_dummy_if_null(ops, apic);
     set_to_dummy_if_null(ops, xen_settime);
     set_to_dummy_if_null(ops, memtype);
@@ -574,9 +683,6 @@ void xsm_fixup_ops (struct xsm_operations *ops)
     set_to_dummy_if_null(ops, update_va_mapping);
     set_to_dummy_if_null(ops, add_to_physmap);
     set_to_dummy_if_null(ops, sendtrigger);
-    set_to_dummy_if_null(ops, test_assign_device);
-    set_to_dummy_if_null(ops, assign_device);
-    set_to_dummy_if_null(ops, deassign_device);
     set_to_dummy_if_null(ops, bind_pt_irq);
     set_to_dummy_if_null(ops, pin_mem_cacheattr);
     set_to_dummy_if_null(ops, ext_vcpucontext);
-- 
1.7.7.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 20:39:57 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 20:39:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaZ8S-0003Dc-Ew; Tue, 13 Dec 2011 20:39:36 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RaZ8R-0003C6-OA
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 20:39:35 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-8.tower-21.messagelabs.com!1323808720!8083753!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25564 invoked from network); 13 Dec 2011 20:38:41 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-8.tower-21.messagelabs.com with SMTP;
	13 Dec 2011 20:38:41 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea01.nsa.gov (8.12.10/8.12.10) with ESMTP id
	pBDKcdRx010715; Tue, 13 Dec 2011 20:38:39 GMT
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id pBDKcdnv017251; 
	Tue, 13 Dec 2011 15:38:39 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com, Keir Fraser <keir@xen.org>
Date: Tue, 13 Dec 2011 15:38:50 -0500
Message-Id: <1323808737-29125-2-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.4
In-Reply-To: <1323808737-29125-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1323808737-29125-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 1/8] xsm/flask: Add missing unlock on error path
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 xen/xsm/flask/ss/services.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/xen/xsm/flask/ss/services.c b/xen/xsm/flask/ss/services.c
index c810e9b..7b08e73 100644
--- a/xen/xsm/flask/ss/services.c
+++ b/xen/xsm/flask/ss/services.c
@@ -1428,6 +1428,7 @@ int security_load_policy(void *data, size_t len)
         }
         if ( validate_classes(&policydb) )
         {
+            LOAD_UNLOCK;
             printk(KERN_ERR
                    "Flask:  the definition of a class is incorrect\n");
             sidtab_destroy(&sidtab);
-- 
1.7.7.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 20:39:57 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 20:39:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaZ8T-0003EK-LF; Tue, 13 Dec 2011 20:39:37 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RaZ8S-0003CA-14
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 20:39:36 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-15.tower-216.messagelabs.com!1323808721!7314827!1
X-Originating-IP: [63.239.65.40]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 568 invoked from network); 13 Dec 2011 20:38:41 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-15.tower-216.messagelabs.com with SMTP;
	13 Dec 2011 20:38:41 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea02.nsa.gov (8.12.10/8.12.10) with ESMTP id
	pBDKcexP012689; Tue, 13 Dec 2011 20:38:40 GMT
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id pBDKcdo4017251; 
	Tue, 13 Dec 2011 15:38:40 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com, Keir Fraser <keir@xen.org>
Date: Tue, 13 Dec 2011 15:38:57 -0500
Message-Id: <1323808737-29125-9-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.4
In-Reply-To: <1323808737-29125-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1323808737-29125-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 8/8] xl.pod.1: improve documentation of FLASK
	commands
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 docs/man/xl.pod.1 |   38 ++++++++++++++++++++++----------------
 1 files changed, 22 insertions(+), 16 deletions(-)

diff --git a/docs/man/xl.pod.1 b/docs/man/xl.pod.1
index 5a39ae5..72196ee 100644
--- a/docs/man/xl.pod.1
+++ b/docs/man/xl.pod.1
@@ -197,10 +197,6 @@ I<filename> specified, without pausing the domain.  The dump file will
 be written to a distribution specific directory for dump files.  Such
 as: /var/lib/xen/dump or /var/xen/dump.
 
-=item B<getenforce>
-
-Returns the current enforcing mode of the Flask Xen security module.
-
 =item B<help> [I<--long>]
 
 Displays the short help message (i.e. common commands).
@@ -303,10 +299,6 @@ less utilized than a high CPU workload.  Consider yourself warned.
 
 =back
 
-=item B<loadpolicy> I<policyfile>
-
-Loads a new policy int the Flask Xen security module.
-
 =item B<mem-max> I<domain-id> I<mem>
 
 Specify the maximum amount of memory the domain is able to use, appending 't'
@@ -397,10 +389,6 @@ Enable debug messages.
 
 =back
 
-=item B<setenforce> I<1|0|Enforcing|Permissive>
-
-Sets the current enforcing mode of the Flask Xen security module
-
 =item B<save> [I<OPTIONS>] I<domain-id> I<CheckpointFile> [I<ConfigFile>]
 
 Saves a running domain to a state file so that it can be restored
@@ -997,6 +985,28 @@ Get information about how much freeable memory (MB) is in-use by tmem.
 
 =back
 
+=head2 FLASK
+
+=over 4
+
+=item B<getenforce>
+
+Determine if the FLASK security module is loaded and enforcing its policy.
+
+=item B<setenforce> I<1|0|Enforcing|Permissive>
+
+Enable or disable enforcing of the FLASK access controls. The default is
+permissive and can be changed using the flask_enforcing option on the
+hypervisor's command line.
+
+=item B<loadpolicy> I<policy-file>
+
+Load FLASK policy from the given policy file. The initial policy is provided to
+the hypervisor as a multiboot module; this command allows runtime updates to the
+policy. Loading new security policy will reset runtime changes to device labels.
+
+=back
+
 =head1 TO BE DOCUMENTED
 
 We need better documentation for:
@@ -1007,10 +1017,6 @@ We need better documentation for:
 
 Trascendent Memory.
 
-=item B<Flask>
-
-Xen Flask security module.
-
 =back
 
 =head1 SEE ALSO
-- 
1.7.7.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 20:39:57 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 20:39:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaZ8T-0003EK-LF; Tue, 13 Dec 2011 20:39:37 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RaZ8S-0003CA-14
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 20:39:36 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-15.tower-216.messagelabs.com!1323808721!7314827!1
X-Originating-IP: [63.239.65.40]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 568 invoked from network); 13 Dec 2011 20:38:41 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-15.tower-216.messagelabs.com with SMTP;
	13 Dec 2011 20:38:41 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea02.nsa.gov (8.12.10/8.12.10) with ESMTP id
	pBDKcexP012689; Tue, 13 Dec 2011 20:38:40 GMT
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id pBDKcdo4017251; 
	Tue, 13 Dec 2011 15:38:40 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com, Keir Fraser <keir@xen.org>
Date: Tue, 13 Dec 2011 15:38:57 -0500
Message-Id: <1323808737-29125-9-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.4
In-Reply-To: <1323808737-29125-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1323808737-29125-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 8/8] xl.pod.1: improve documentation of FLASK
	commands
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 docs/man/xl.pod.1 |   38 ++++++++++++++++++++++----------------
 1 files changed, 22 insertions(+), 16 deletions(-)

diff --git a/docs/man/xl.pod.1 b/docs/man/xl.pod.1
index 5a39ae5..72196ee 100644
--- a/docs/man/xl.pod.1
+++ b/docs/man/xl.pod.1
@@ -197,10 +197,6 @@ I<filename> specified, without pausing the domain.  The dump file will
 be written to a distribution specific directory for dump files.  Such
 as: /var/lib/xen/dump or /var/xen/dump.
 
-=item B<getenforce>
-
-Returns the current enforcing mode of the Flask Xen security module.
-
 =item B<help> [I<--long>]
 
 Displays the short help message (i.e. common commands).
@@ -303,10 +299,6 @@ less utilized than a high CPU workload.  Consider yourself warned.
 
 =back
 
-=item B<loadpolicy> I<policyfile>
-
-Loads a new policy int the Flask Xen security module.
-
 =item B<mem-max> I<domain-id> I<mem>
 
 Specify the maximum amount of memory the domain is able to use, appending 't'
@@ -397,10 +389,6 @@ Enable debug messages.
 
 =back
 
-=item B<setenforce> I<1|0|Enforcing|Permissive>
-
-Sets the current enforcing mode of the Flask Xen security module
-
 =item B<save> [I<OPTIONS>] I<domain-id> I<CheckpointFile> [I<ConfigFile>]
 
 Saves a running domain to a state file so that it can be restored
@@ -997,6 +985,28 @@ Get information about how much freeable memory (MB) is in-use by tmem.
 
 =back
 
+=head2 FLASK
+
+=over 4
+
+=item B<getenforce>
+
+Determine if the FLASK security module is loaded and enforcing its policy.
+
+=item B<setenforce> I<1|0|Enforcing|Permissive>
+
+Enable or disable enforcing of the FLASK access controls. The default is
+permissive and can be changed using the flask_enforcing option on the
+hypervisor's command line.
+
+=item B<loadpolicy> I<policy-file>
+
+Load FLASK policy from the given policy file. The initial policy is provided to
+the hypervisor as a multiboot module; this command allows runtime updates to the
+policy. Loading new security policy will reset runtime changes to device labels.
+
+=back
+
 =head1 TO BE DOCUMENTED
 
 We need better documentation for:
@@ -1007,10 +1017,6 @@ We need better documentation for:
 
 Trascendent Memory.
 
-=item B<Flask>
-
-Xen Flask security module.
-
 =back
 
 =head1 SEE ALSO
-- 
1.7.7.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 20:39:57 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 20:39:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaZ8T-0003E8-8V; Tue, 13 Dec 2011 20:39:37 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RaZ8R-0003C9-RU
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 20:39:36 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-7.tower-216.messagelabs.com!1323808720!7335010!1
X-Originating-IP: [63.239.65.40]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 442 invoked from network); 13 Dec 2011 20:38:41 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-7.tower-216.messagelabs.com with SMTP;
	13 Dec 2011 20:38:41 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea02.nsa.gov (8.12.10/8.12.10) with ESMTP id
	pBDKcdxP012681; Tue, 13 Dec 2011 20:38:39 GMT
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id pBDKcdnw017251; 
	Tue, 13 Dec 2011 15:38:39 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com, Keir Fraser <keir@xen.org>
Date: Tue, 13 Dec 2011 15:38:51 -0500
Message-Id: <1323808737-29125-3-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.4
In-Reply-To: <1323808737-29125-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1323808737-29125-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 2/8] xsm/flask: report memory and IO ranges in
	audit messages
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This information is useful when determining the cause of an AVC denial
caused by missing label on device memory or IRQs.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 xen/xsm/flask/avc.c         |   11 ++++++++++-
 xen/xsm/flask/hooks.c       |   18 ++++++++++--------
 xen/xsm/flask/include/avc.h |   13 +++++++++++--
 3 files changed, 31 insertions(+), 11 deletions(-)

diff --git a/xen/xsm/flask/avc.c b/xen/xsm/flask/avc.c
index c47dd40..9475d92 100644
--- a/xen/xsm/flask/avc.c
+++ b/xen/xsm/flask/avc.c
@@ -568,8 +568,17 @@ void avc_audit(u32 ssid, u32 tsid, u16 tclass, u32 requested,
         d = a->d;
     if ( d )
         printk("domid=%d ", d->domain_id);
-    if ( a && a->device )
+    switch ( a ? a->type : 0 ) {
+    case AVC_AUDIT_DATA_DEV:
         printk("device=0x%lx ", a->device);
+        break;
+    case AVC_AUDIT_DATA_IRQ:
+        printk("irq=%d ", a->irq);
+        break;
+    case AVC_AUDIT_DATA_RANGE:
+        printk("range=0x%lx-0x%lx ", a->range.start, a->range.end);
+        break;
+    }
 
     avc_dump_query(ssid, tsid, tclass);
     printk("\n");
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index 0feb070..1a3f3b3 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -670,8 +670,8 @@ static int flask_irq_permission (struct domain *d, int pirq, uint8_t access)
     if ( rc )
         return rc;
 
-    AVC_AUDIT_DATA_INIT(&ad, DEV);
-    ad.device = (unsigned long) pirq;
+    AVC_AUDIT_DATA_INIT(&ad, IRQ);
+    ad.irq = pirq;
 
     rc = avc_has_perm(ssec->sid, rsid, SECCLASS_RESOURCE, perm, &ad);
     if ( rc )
@@ -694,8 +694,9 @@ static int _iomem_has_perm(void *v, u32 sid, unsigned long start, unsigned long
     struct avc_audit_data ad;
     int rc = -EPERM;
 
-    AVC_AUDIT_DATA_INIT(&ad, DEV);
-    ad.device = start;
+    AVC_AUDIT_DATA_INIT(&ad, RANGE);
+    ad.range.start = start;
+    ad.range.end = end;
 
     rc = avc_has_perm(data->ssec->sid, sid, SECCLASS_RESOURCE, data->perm, &ad);
 
@@ -771,8 +772,9 @@ static int _ioport_has_perm(void *v, u32 sid, unsigned long start, unsigned long
     struct avc_audit_data ad;
     int rc;
 
-    AVC_AUDIT_DATA_INIT(&ad, DEV);
-    ad.device = start;
+    AVC_AUDIT_DATA_INIT(&ad, RANGE);
+    ad.range.start = start;
+    ad.range.end = end;
 
     rc = avc_has_perm(data->ssec->sid, sid, SECCLASS_RESOURCE, data->perm, &ad);
 
@@ -1155,8 +1157,8 @@ static int flask_bind_pt_irq (struct domain *d, struct xen_domctl_bind_pt_irq *b
     if ( rc )
         return rc;
 
-    AVC_AUDIT_DATA_INIT(&ad, DEV);
-    ad.device = (unsigned long)irq;
+    AVC_AUDIT_DATA_INIT(&ad, IRQ);
+    ad.irq = irq;
 
     ssec = current->domain->ssid;
     rc = avc_has_perm(ssec->sid, rsid, SECCLASS_HVM, HVM__BIND_IRQ, &ad);
diff --git a/xen/xsm/flask/include/avc.h b/xen/xsm/flask/include/avc.h
index 2168585..1b19189 100644
--- a/xen/xsm/flask/include/avc.h
+++ b/xen/xsm/flask/include/avc.h
@@ -38,9 +38,18 @@ struct sk_buff;
 /* Auxiliary data to use in generating the audit record. */
 struct avc_audit_data {
     char    type;
-#define AVC_AUDIT_DATA_DEV  1
+#define AVC_AUDIT_DATA_DEV   1
+#define AVC_AUDIT_DATA_IRQ   2
+#define AVC_AUDIT_DATA_RANGE 3
     struct domain *d;
-    unsigned long device;
+    union {
+        unsigned long device;
+        int irq;
+        struct {
+            unsigned long start;
+            unsigned long end;
+        } range;
+    };
 };
 
 #define v4info fam.v4
-- 
1.7.7.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 20:39:57 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 20:39:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaZ8O-0003CK-9c; Tue, 13 Dec 2011 20:39:32 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RaZ8M-0003C8-Vo
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 20:39:31 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-11.tower-27.messagelabs.com!1323808702!49154870!1
X-Originating-IP: [63.239.65.40]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20695 invoked from network); 13 Dec 2011 20:38:22 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-11.tower-27.messagelabs.com with SMTP;
	13 Dec 2011 20:38:22 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea02.nsa.gov (8.12.10/8.12.10) with ESMTP id
	pBDKcdxP012682; Tue, 13 Dec 2011 20:38:39 GMT
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id pBDKcdnx017251; 
	Tue, 13 Dec 2011 15:38:39 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com, Keir Fraser <keir@xen.org>
Date: Tue, 13 Dec 2011 15:38:52 -0500
Message-Id: <1323808737-29125-4-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.4
In-Reply-To: <1323808737-29125-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1323808737-29125-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 3/8] xsm: only log dummy override if not setting
	up dummy_xsm_ops
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

The log messages from dummy overrides appear on every boot with XSM
enabled, and are just noise when filling in the dummy_xsm_ops structure.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 xen/xsm/dummy.c |   17 +++++++++--------
 1 files changed, 9 insertions(+), 8 deletions(-)

diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c
index a629396..d6f2da0 100644
--- a/xen/xsm/dummy.c
+++ b/xen/xsm/dummy.c
@@ -469,14 +469,15 @@ static int dummy_ioport_permission (struct domain *d, uint32_t s, uint32_t e, ui
 
 struct xsm_operations dummy_xsm_ops;
 
-#define set_to_dummy_if_null(ops, function)                        \
-    do {                                                           \
-        if ( !ops->function )                                      \
-        {                                                          \
-            ops->function = dummy_##function;                      \
-            dprintk(XENLOG_DEBUG, "Had to override the " #function \
-                " security operation with the dummy one.\n");      \
-        }                                                          \
+#define set_to_dummy_if_null(ops, function)                            \
+    do {                                                               \
+        if ( !ops->function )                                          \
+        {                                                              \
+            ops->function = dummy_##function;                          \
+            if (ops != &dummy_xsm_ops)                                 \
+                dprintk(XENLOG_DEBUG, "Had to override the " #function \
+                    " security operation with the dummy one.\n");      \
+        }                                                              \
     } while (0)
 
 void xsm_fixup_ops (struct xsm_operations *ops)
-- 
1.7.7.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 20:39:57 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 20:39:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaZ8T-0003E8-8V; Tue, 13 Dec 2011 20:39:37 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RaZ8R-0003C9-RU
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 20:39:36 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-7.tower-216.messagelabs.com!1323808720!7335010!1
X-Originating-IP: [63.239.65.40]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 442 invoked from network); 13 Dec 2011 20:38:41 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-7.tower-216.messagelabs.com with SMTP;
	13 Dec 2011 20:38:41 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea02.nsa.gov (8.12.10/8.12.10) with ESMTP id
	pBDKcdxP012681; Tue, 13 Dec 2011 20:38:39 GMT
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id pBDKcdnw017251; 
	Tue, 13 Dec 2011 15:38:39 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com, Keir Fraser <keir@xen.org>
Date: Tue, 13 Dec 2011 15:38:51 -0500
Message-Id: <1323808737-29125-3-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.4
In-Reply-To: <1323808737-29125-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1323808737-29125-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 2/8] xsm/flask: report memory and IO ranges in
	audit messages
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This information is useful when determining the cause of an AVC denial
caused by missing label on device memory or IRQs.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 xen/xsm/flask/avc.c         |   11 ++++++++++-
 xen/xsm/flask/hooks.c       |   18 ++++++++++--------
 xen/xsm/flask/include/avc.h |   13 +++++++++++--
 3 files changed, 31 insertions(+), 11 deletions(-)

diff --git a/xen/xsm/flask/avc.c b/xen/xsm/flask/avc.c
index c47dd40..9475d92 100644
--- a/xen/xsm/flask/avc.c
+++ b/xen/xsm/flask/avc.c
@@ -568,8 +568,17 @@ void avc_audit(u32 ssid, u32 tsid, u16 tclass, u32 requested,
         d = a->d;
     if ( d )
         printk("domid=%d ", d->domain_id);
-    if ( a && a->device )
+    switch ( a ? a->type : 0 ) {
+    case AVC_AUDIT_DATA_DEV:
         printk("device=0x%lx ", a->device);
+        break;
+    case AVC_AUDIT_DATA_IRQ:
+        printk("irq=%d ", a->irq);
+        break;
+    case AVC_AUDIT_DATA_RANGE:
+        printk("range=0x%lx-0x%lx ", a->range.start, a->range.end);
+        break;
+    }
 
     avc_dump_query(ssid, tsid, tclass);
     printk("\n");
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index 0feb070..1a3f3b3 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -670,8 +670,8 @@ static int flask_irq_permission (struct domain *d, int pirq, uint8_t access)
     if ( rc )
         return rc;
 
-    AVC_AUDIT_DATA_INIT(&ad, DEV);
-    ad.device = (unsigned long) pirq;
+    AVC_AUDIT_DATA_INIT(&ad, IRQ);
+    ad.irq = pirq;
 
     rc = avc_has_perm(ssec->sid, rsid, SECCLASS_RESOURCE, perm, &ad);
     if ( rc )
@@ -694,8 +694,9 @@ static int _iomem_has_perm(void *v, u32 sid, unsigned long start, unsigned long
     struct avc_audit_data ad;
     int rc = -EPERM;
 
-    AVC_AUDIT_DATA_INIT(&ad, DEV);
-    ad.device = start;
+    AVC_AUDIT_DATA_INIT(&ad, RANGE);
+    ad.range.start = start;
+    ad.range.end = end;
 
     rc = avc_has_perm(data->ssec->sid, sid, SECCLASS_RESOURCE, data->perm, &ad);
 
@@ -771,8 +772,9 @@ static int _ioport_has_perm(void *v, u32 sid, unsigned long start, unsigned long
     struct avc_audit_data ad;
     int rc;
 
-    AVC_AUDIT_DATA_INIT(&ad, DEV);
-    ad.device = start;
+    AVC_AUDIT_DATA_INIT(&ad, RANGE);
+    ad.range.start = start;
+    ad.range.end = end;
 
     rc = avc_has_perm(data->ssec->sid, sid, SECCLASS_RESOURCE, data->perm, &ad);
 
@@ -1155,8 +1157,8 @@ static int flask_bind_pt_irq (struct domain *d, struct xen_domctl_bind_pt_irq *b
     if ( rc )
         return rc;
 
-    AVC_AUDIT_DATA_INIT(&ad, DEV);
-    ad.device = (unsigned long)irq;
+    AVC_AUDIT_DATA_INIT(&ad, IRQ);
+    ad.irq = irq;
 
     ssec = current->domain->ssid;
     rc = avc_has_perm(ssec->sid, rsid, SECCLASS_HVM, HVM__BIND_IRQ, &ad);
diff --git a/xen/xsm/flask/include/avc.h b/xen/xsm/flask/include/avc.h
index 2168585..1b19189 100644
--- a/xen/xsm/flask/include/avc.h
+++ b/xen/xsm/flask/include/avc.h
@@ -38,9 +38,18 @@ struct sk_buff;
 /* Auxiliary data to use in generating the audit record. */
 struct avc_audit_data {
     char    type;
-#define AVC_AUDIT_DATA_DEV  1
+#define AVC_AUDIT_DATA_DEV   1
+#define AVC_AUDIT_DATA_IRQ   2
+#define AVC_AUDIT_DATA_RANGE 3
     struct domain *d;
-    unsigned long device;
+    union {
+        unsigned long device;
+        int irq;
+        struct {
+            unsigned long start;
+            unsigned long end;
+        } range;
+    };
 };
 
 #define v4info fam.v4
-- 
1.7.7.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 20:39:58 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 20:39:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaZ8Q-0003Cp-RD; Tue, 13 Dec 2011 20:39:34 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RaZ8O-0003CI-JA
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 20:39:33 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-13.tower-27.messagelabs.com!1323808697!52045454!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32682 invoked from network); 13 Dec 2011 20:38:18 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-13.tower-27.messagelabs.com with SMTP;
	13 Dec 2011 20:38:18 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea01.nsa.gov (8.12.10/8.12.10) with ESMTP id
	pBDKceRx010718; Tue, 13 Dec 2011 20:38:40 GMT
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id pBDKcdo1017251; 
	Tue, 13 Dec 2011 15:38:39 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com, Keir Fraser <keir@xen.org>
Date: Tue, 13 Dec 2011 15:38:54 -0500
Message-Id: <1323808737-29125-6-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.4
In-Reply-To: <1323808737-29125-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1323808737-29125-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 5/8] xsm: Add missing access checks
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Actions requiring IS_PRIV should also require some XSM access control in
order for XSM to be useful in confining multiple privileged domains. Add
XSM hooks for new hypercalls and sub-commands that are under IS_PRIV but
not currently under any access checks.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 tools/flask/policy/policy/flask/access_vectors |   14 ++
 xen/arch/ia64/xen/mm.c                         |    8 +
 xen/arch/x86/cpu/mcheck/mce.c                  |    4 +
 xen/arch/x86/domctl.c                          |   17 ++-
 xen/arch/x86/hvm/hvm.c                         |   26 +++
 xen/arch/x86/mm.c                              |   10 +-
 xen/arch/x86/msi.c                             |    6 +
 xen/arch/x86/physdev.c                         |    9 +
 xen/arch/x86/platform_hypercall.c              |   28 +++
 xen/arch/x86/sysctl.c                          |   14 ++
 xen/common/domctl.c                            |   10 +-
 xen/common/grant_table.c                       |   10 +
 xen/common/sysctl.c                            |   17 ++
 xen/drivers/passthrough/iommu.c                |    8 +
 xen/drivers/passthrough/pci.c                  |   17 ++-
 xen/include/xsm/xsm.h                          |  122 +++++++++++++
 xen/xsm/flask/hooks.c                          |  221 +++++++++++++++++++++++-
 xen/xsm/flask/include/av_perm_to_string.h      |   14 ++
 xen/xsm/flask/include/av_permissions.h         |   14 ++
 19 files changed, 556 insertions(+), 13 deletions(-)

diff --git a/tools/flask/policy/policy/flask/access_vectors b/tools/flask/policy/policy/flask/access_vectors
index 38036d0..644f2e1 100644
--- a/tools/flask/policy/policy/flask/access_vectors
+++ b/tools/flask/policy/policy/flask/access_vectors
@@ -45,6 +45,11 @@ class xen
 	debug
 	getcpuinfo
 	heap
+	pm_op
+	mca_op
+	lockprof
+	cpupool_op
+	sched_op
 }
 
 class domain
@@ -77,6 +82,9 @@ class domain
 	setextvcpucontext
 	getvcpuextstate
 	setvcpuextstate
+	getpodtarget
+	setpodtarget
+	set_misc_info
 }
 
 class hvm
@@ -91,6 +99,9 @@ class hvm
 	bind_irq
 	cacheattr
     trackdirtyvram
+    hvmctl
+    mem_event
+    mem_sharing
 }
 
 class event
@@ -152,6 +163,9 @@ class resource
 	stat_device
 	add_device
 	remove_device
+	plug
+	unplug
+	setup
 }
 
 class security
diff --git a/xen/arch/ia64/xen/mm.c b/xen/arch/ia64/xen/mm.c
index d440e4d..694bf95 100644
--- a/xen/arch/ia64/xen/mm.c
+++ b/xen/arch/ia64/xen/mm.c
@@ -3496,6 +3496,14 @@ arch_memory_op(int op, XEN_GUEST_HANDLE(void) arg)
             return rc;
 
         if ( op == XENMEM_set_pod_target )
+            rc = xsm_set_pod_target(d);
+        else
+            rc = xsm_get_pod_target(d);
+
+        if ( rc != 0 )
+            goto pod_target_out_unlock;
+
+        if ( op == XENMEM_set_pod_target )
         {
             /* if -ENOSYS is returned,
                domain builder aborts domain creation. */
diff --git a/xen/arch/x86/cpu/mcheck/mce.c b/xen/arch/x86/cpu/mcheck/mce.c
index 6af93c0..b592041 100644
--- a/xen/arch/x86/cpu/mcheck/mce.c
+++ b/xen/arch/x86/cpu/mcheck/mce.c
@@ -1384,6 +1384,10 @@ long do_mca(XEN_GUEST_HANDLE(xen_mc_t) u_xen_mc)
     if (!IS_PRIV(v->domain) )
         return x86_mcerr(NULL, -EPERM);
 
+    ret = xsm_do_mca();
+    if ( ret )
+        return x86_mcerr(NULL, ret);
+
     if ( copy_from_guest(op, u_xen_mc, 1) )
         return x86_mcerr("do_mca: failed copyin of xen_mc_t", -EFAULT);
 
diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c
index 4e258f3..9c9d5d1 100644
--- a/xen/arch/x86/domctl.c
+++ b/xen/arch/x86/domctl.c
@@ -1441,8 +1441,10 @@ long arch_do_domctl(
         d = rcu_lock_domain_by_id(domctl->domain);
         if ( d != NULL )
         {
-            ret = mem_event_domctl(d, &domctl->u.mem_event_op,
-                                   guest_handle_cast(u_domctl, void));
+            ret = xsm_mem_event(d);
+            if ( !ret )
+                ret = mem_event_domctl(d, &domctl->u.mem_event_op,
+                                       guest_handle_cast(u_domctl, void));
             rcu_unlock_domain(d);
             copy_to_guest(u_domctl, domctl, 1);
         } 
@@ -1457,7 +1459,9 @@ long arch_do_domctl(
         d = rcu_lock_domain_by_id(domctl->domain);
         if ( d != NULL )
         {
-            ret = mem_sharing_domctl(d, &domctl->u.mem_sharing_op);
+            ret = xsm_mem_sharing(d);
+            if ( !ret )
+                ret = mem_sharing_domctl(d, &domctl->u.mem_sharing_op);
             rcu_unlock_domain(d);
             copy_to_guest(u_domctl, domctl, 1);
         } 
@@ -1498,8 +1502,11 @@ long arch_do_domctl(
         d = rcu_lock_domain_by_id(domctl->domain);
         if ( d != NULL )
         {
-            p2m = p2m_get_hostp2m(d);
-            p2m->access_required = domctl->u.access_required.access_required;
+            ret = xsm_mem_event(d);
+            if ( !ret ) {
+                p2m = p2m_get_hostp2m(d);
+                p2m->access_required = domctl->u.access_required.access_required;
+            }
             rcu_unlock_domain(d);
         } 
     }
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 901132d..bae3696 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -3869,6 +3869,10 @@ long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE(void) arg)
         if ( rc != 0 )
             return rc;
 
+        rc = xsm_hvm_param(d, op);
+        if ( rc )
+            goto param_fail_getmemtype;
+
         rc = -EINVAL;
         if ( is_hvm_domain(d) )
         {
@@ -3883,6 +3887,8 @@ long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE(void) arg)
                 a.mem_type =  HVMMEM_mmio_dm;
             rc = copy_to_guest(arg, &a, 1) ? -EFAULT : 0;
         }
+
+    param_fail_getmemtype:
         rcu_unlock_domain(d);
         break;
     }
@@ -3911,6 +3917,10 @@ long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE(void) arg)
         if ( !is_hvm_domain(d) )
             goto param_fail4;
 
+        rc = xsm_hvm_param(d, op);
+        if ( rc )
+            goto param_fail4;
+
         rc = -EINVAL;
         if ( (a.first_pfn > domain_get_maximum_gpfn(d)) ||
              ((a.first_pfn + a.nr - 1) < a.first_pfn) ||
@@ -3986,6 +3996,10 @@ long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE(void) arg)
         if ( !is_hvm_domain(d) )
             goto param_fail5;
 
+        rc = xsm_hvm_param(d, op);
+        if ( rc )
+            goto param_fail5;
+
         rc = -EINVAL;
         if ( (a.first_pfn > domain_get_maximum_gpfn(d)) ||
              ((a.first_pfn + a.nr - 1) < a.first_pfn) ||
@@ -4016,6 +4030,10 @@ long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE(void) arg)
         if ( !is_hvm_domain(d) )
             goto param_fail6;
 
+        rc = xsm_hvm_param(d, op);
+        if ( rc )
+            goto param_fail6;
+
         rc = -EINVAL;
         if ( (a.pfn > domain_get_maximum_gpfn(d)) && a.pfn != ~0ull )
             goto param_fail6;
@@ -4048,6 +4066,10 @@ long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE(void) arg)
         if ( !is_hvm_domain(d) || !paging_mode_shadow(d) )
             goto param_fail7;
 
+        rc = xsm_hvm_param(d, op);
+        if ( rc )
+            goto param_fail7;
+
         rc = 0;
         pagetable_dying(d, a.gpa);
 
@@ -4098,6 +4120,10 @@ long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE(void) arg)
         if ( !is_hvm_domain(d) )
             goto param_fail8;
 
+        rc = xsm_hvm_param(d, op);
+        if ( rc )
+            goto param_fail8;
+
         rc = -ENOENT;
         if ( tr.vcpuid >= d->max_vcpus || (v = d->vcpu[tr.vcpuid]) == NULL )
             goto param_fail8;
diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index 19391fc..67f5630 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -5041,7 +5041,7 @@ long arch_memory_op(int op, XEN_GUEST_HANDLE(void) arg)
 
         /* Support DOMID_SELF? */
         if ( !IS_PRIV(current->domain) )
-            return -EINVAL;
+            return -EPERM;
 
         if ( copy_from_guest(&target, arg, 1) )
             return -EFAULT;
@@ -5051,6 +5051,14 @@ long arch_memory_op(int op, XEN_GUEST_HANDLE(void) arg)
             return rc;
 
         if ( op == XENMEM_set_pod_target )
+            rc = xsm_set_pod_target(d);
+        else
+            rc = xsm_get_pod_target(d);
+
+        if ( rc != 0 )
+            goto pod_target_out_unlock;
+
+        if ( op == XENMEM_set_pod_target )
         {
             if ( target.target_pages > d->max_pages )
             {
diff --git a/xen/arch/x86/msi.c b/xen/arch/x86/msi.c
index 2d86006..782b84b 100644
--- a/xen/arch/x86/msi.c
+++ b/xen/arch/x86/msi.c
@@ -29,6 +29,7 @@
 #include <io_ports.h>
 #include <public/physdev.h>
 #include <xen/iommu.h>
+#include <xsm/xsm.h>
 
 /* bitmap indicate which fixed map is free */
 DEFINE_SPINLOCK(msix_fixmap_lock);
@@ -992,6 +993,7 @@ int pci_restore_msi_state(struct pci_dev *pdev)
 {
     unsigned long flags;
     int irq;
+    int ret;
     struct msi_desc *entry, *tmp;
     struct irq_desc *desc;
 
@@ -1000,6 +1002,10 @@ int pci_restore_msi_state(struct pci_dev *pdev)
     if (!pdev)
         return -EINVAL;
 
+    ret = xsm_resource_setup_pci((pdev->seg << 16) | (pdev->bus << 8) | pdev->devfn);
+    if ( ret )
+        return ret;
+
     list_for_each_entry_safe( entry, tmp, &pdev->msi_list, list )
     {
         irq = entry->irq;
diff --git a/xen/arch/x86/physdev.c b/xen/arch/x86/physdev.c
index c1c7e54..ca4fb59 100644
--- a/xen/arch/x86/physdev.c
+++ b/xen/arch/x86/physdev.c
@@ -600,6 +600,10 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg)
         if ( !IS_PRIV(current->domain) )
             break;
 
+        ret = xsm_resource_setup_misc();
+        if ( ret )
+            break;
+
         ret = -EFAULT;
         if ( copy_from_guest(&info, arg, 1) )
             break;
@@ -662,6 +666,11 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg)
         ret = -EINVAL;
         if ( setup_gsi.gsi < 0 || setup_gsi.gsi >= nr_irqs_gsi )
             break;
+
+        ret = xsm_resource_setup_gsi(setup_gsi.gsi);
+        if ( ret )
+            break;
+
         ret = mp_register_gsi(setup_gsi.gsi, setup_gsi.triggering,
                               setup_gsi.polarity);
         break; 
diff --git a/xen/arch/x86/platform_hypercall.c b/xen/arch/x86/platform_hypercall.c
index a0d23ba..f9a836a 100644
--- a/xen/arch/x86/platform_hypercall.c
+++ b/xen/arch/x86/platform_hypercall.c
@@ -390,6 +390,10 @@ ret_t do_platform_op(XEN_GUEST_HANDLE(xen_platform_op_t) u_xenpf_op)
     break;
 
     case XENPF_set_processor_pminfo:
+        ret = xsm_setpminfo();
+        if ( ret )
+            break;
+
         switch ( op->u.set_pminfo.type )
         {
         case XEN_PM_PX:
@@ -440,6 +444,10 @@ ret_t do_platform_op(XEN_GUEST_HANDLE(xen_platform_op_t) u_xenpf_op)
 
         g_info = &op->u.pcpu_info;
 
+        ret = xsm_getcpuinfo();
+        if ( ret )
+            break;
+
         if ( !get_cpu_maps() )
         {
             ret = -EBUSY;
@@ -509,6 +517,10 @@ ret_t do_platform_op(XEN_GUEST_HANDLE(xen_platform_op_t) u_xenpf_op)
     {
         int cpu = op->u.cpu_ol.cpuid;
 
+        ret = xsm_resource_plug_core();
+        if ( ret )
+            break;
+
         if ( cpu >= nr_cpu_ids || !cpu_present(cpu) )
         {
             ret = -EINVAL;
@@ -521,6 +533,10 @@ ret_t do_platform_op(XEN_GUEST_HANDLE(xen_platform_op_t) u_xenpf_op)
             break;
         }
 
+        ret = xsm_resource_plug_core();
+        if ( ret )
+            break;
+
         ret = continue_hypercall_on_cpu(
             0, cpu_up_helper, (void *)(unsigned long)cpu);
         break;
@@ -530,6 +546,10 @@ ret_t do_platform_op(XEN_GUEST_HANDLE(xen_platform_op_t) u_xenpf_op)
     {
         int cpu = op->u.cpu_ol.cpuid;
 
+        ret = xsm_resource_unplug_core();
+        if ( ret )
+            break;
+
         if ( cpu == 0 )
         {
             ret = -EOPNOTSUPP;
@@ -555,12 +575,20 @@ ret_t do_platform_op(XEN_GUEST_HANDLE(xen_platform_op_t) u_xenpf_op)
     break;
 
     case XENPF_cpu_hotadd:
+        ret = xsm_resource_plug_core();
+        if ( ret )
+            break;
+
         ret = cpu_add(op->u.cpu_add.apic_id,
                       op->u.cpu_add.acpi_id,
                       op->u.cpu_add.pxm);
     break;
 
     case XENPF_mem_hotadd:
+        ret = xsm_resource_plug_core();
+        if ( ret )
+            break;
+
         ret = memory_add(op->u.mem_add.spfn,
                       op->u.mem_add.epfn,
                       op->u.mem_add.pxm);
diff --git a/xen/arch/x86/sysctl.c b/xen/arch/x86/sysctl.c
index 738e517..379f071 100644
--- a/xen/arch/x86/sysctl.c
+++ b/xen/arch/x86/sysctl.c
@@ -103,6 +103,10 @@ long arch_do_sysctl(
         uint32_t i, max_cpu_index, last_online_cpu;
         xen_sysctl_topologyinfo_t *ti = &sysctl->u.topologyinfo;
 
+        ret = xsm_physinfo();
+        if ( ret )
+            break;
+
         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;
@@ -139,6 +143,10 @@ long arch_do_sysctl(
         uint32_t i, j, max_node_index, last_online_node;
         xen_sysctl_numainfo_t *ni = &sysctl->u.numainfo;
 
+        ret = xsm_physinfo();
+        if ( ret )
+            break;
+
         last_online_node = last_node(node_online_map);
         max_node_index = min_t(uint32_t, ni->max_node_index, last_online_node);
         ni->max_node_index = last_online_node;
@@ -189,10 +197,16 @@ long arch_do_sysctl(
         switch ( sysctl->u.cpu_hotplug.op )
         {
         case XEN_SYSCTL_CPU_HOTPLUG_ONLINE:
+            ret = xsm_resource_plug_core();
+            if ( ret )
+                break;
             ret = continue_hypercall_on_cpu(
                 0, cpu_up_helper, (void *)(unsigned long)cpu);
             break;
         case XEN_SYSCTL_CPU_HOTPLUG_OFFLINE:
+            ret = xsm_resource_unplug_core();
+            if ( ret )
+                break;
             ret = continue_hypercall_on_cpu(
                 0, cpu_down_helper, (void *)(unsigned long)cpu);
             break;
diff --git a/xen/common/domctl.c b/xen/common/domctl.c
index 06594a0..d6ae09b 100644
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -972,9 +972,10 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domctl_t) u_domctl)
         d = rcu_lock_domain_by_id(op->domain);
         if ( d != NULL )
         {
-            d->suspend_evtchn = op->u.subscribe.port;
+            ret = xsm_domctl(d, op->cmd);
+            if ( !ret )
+                d->suspend_evtchn = op->u.subscribe.port;
             rcu_unlock_domain(d);
-            ret = 0;
         }
     }
     break;
@@ -985,9 +986,10 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domctl_t) u_domctl)
         ret = -ESRCH;
         if ( (d = rcu_lock_domain_by_id(op->domain)) != NULL )
         {
-            d->disable_migrate = op->u.disable_migrate.disable;
+            ret = xsm_domctl(d, op->cmd);
+            if ( !ret )
+                d->disable_migrate = op->u.disable_migrate.disable;
             rcu_unlock_domain(d);
-            ret = 0;
         }
     }
     break;
diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c
index e2b103b..fefa838 100644
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -2208,6 +2208,11 @@ gnttab_get_status_frames(XEN_GUEST_HANDLE(gnttab_get_status_frames_t) uop,
             op.status = GNTST_general_error;
         goto out1;
     }
+    rc = xsm_grant_setup(current->domain, d);
+    if ( rc ) {
+        op.status = GNTST_permission_denied;
+        goto out1;
+    }
 
     gt = d->grant_table;
 
@@ -2259,6 +2264,11 @@ gnttab_get_version(XEN_GUEST_HANDLE(gnttab_get_version_t uop))
         rcu_unlock_domain(d);
         return -EPERM;
     }
+    if ( xsm_grant_query_size(current->domain, d) )
+    {
+        rcu_unlock_domain(d);
+        return -EPERM;
+    }
     spin_lock(&d->grant_table->lock);
     op.version = d->grant_table->gt_version;
     spin_unlock(&d->grant_table->lock);
diff --git a/xen/common/sysctl.c b/xen/common/sysctl.c
index ccfdb22..f8f7cf8 100644
--- a/xen/common/sysctl.c
+++ b/xen/common/sysctl.c
@@ -152,6 +152,11 @@ long do_sysctl(XEN_GUEST_HANDLE(xen_sysctl_t) u_sysctl)
 #ifdef LOCK_PROFILE
     case XEN_SYSCTL_lockprof_op:
     {
+        ret = xsm_lockprof();
+        if ( ret )
+            break;
+
+        ret = perfc_control(&op->u.perfc_op);
         ret = spinlock_profile_control(&op->u.lockprof_op);
         if ( copy_to_guest(u_sysctl, op, 1) )
             ret = -EFAULT;
@@ -260,6 +265,10 @@ long do_sysctl(XEN_GUEST_HANDLE(xen_sysctl_t) u_sysctl)
         uint32_t *status, *ptr;
         unsigned long pfn;
 
+        ret = xsm_page_offline(op->u.page_offline.cmd);
+        if ( ret )
+            break;
+
         ptr = status = xmalloc_bytes( sizeof(uint32_t) *
                                 (op->u.page_offline.end -
                                   op->u.page_offline.start + 1));
@@ -314,6 +323,10 @@ long do_sysctl(XEN_GUEST_HANDLE(xen_sysctl_t) u_sysctl)
 
     case XEN_SYSCTL_cpupool_op:
     {
+        ret = xsm_cpupool_op();
+        if ( ret )
+            break;
+
         ret = cpupool_do_sysctl(&op->u.cpupool_op);
         if ( (ret == 0) && copy_to_guest(u_sysctl, op, 1) )
             ret = -EFAULT;
@@ -322,6 +335,10 @@ long do_sysctl(XEN_GUEST_HANDLE(xen_sysctl_t) u_sysctl)
 
     case XEN_SYSCTL_scheduler_op:
     {
+        ret = xsm_sched_op();
+        if ( ret )
+            break;
+
         ret = sched_adjust_global(&op->u.scheduler_op);
         if ( (ret == 0) && copy_to_guest(u_sysctl, op, 1) )
             ret = -EFAULT;
diff --git a/xen/drivers/passthrough/iommu.c b/xen/drivers/passthrough/iommu.c
index bacca11..d88e9d7 100644
--- a/xen/drivers/passthrough/iommu.c
+++ b/xen/drivers/passthrough/iommu.c
@@ -425,12 +425,16 @@ static int iommu_get_device_group(
              ((pdev->bus == bus) && (pdev->devfn == devfn)) )
             continue;
 
+        if ( xsm_get_device_group((seg << 16) | (pdev->bus << 8) | pdev->devfn) )
+            continue;
+
         sdev_id = ops->get_device_group_id(seg, pdev->bus, pdev->devfn);
         if ( (sdev_id == group_id) && (i < max_sdevs) )
         {
             bdf = 0;
             bdf |= (pdev->bus & 0xff) << 16;
             bdf |= (pdev->devfn & 0xff) << 8;
+
             if ( unlikely(copy_to_guest_offset(buf, i, &bdf, 1)) )
             {
                 spin_unlock(&pcidevs_lock);
@@ -519,6 +523,10 @@ int iommu_do_domctl(
         u32 max_sdevs;
         XEN_GUEST_HANDLE_64(uint32) sdevs;
 
+        ret = xsm_get_device_group(domctl->u.get_device_group.machine_sbdf);
+        if ( ret )
+            break;
+
         ret = -EINVAL;
         if ( (d = rcu_lock_domain_by_id(domctl->domain)) == NULL )
             break;
diff --git a/xen/drivers/passthrough/pci.c b/xen/drivers/passthrough/pci.c
index b7f87d0..50d337a 100644
--- a/xen/drivers/passthrough/pci.c
+++ b/xen/drivers/passthrough/pci.c
@@ -28,6 +28,7 @@
 #include <xen/keyhandler.h>
 #include <xen/radix-tree.h>
 #include <xen/tasklet.h>
+#include <xsm/xsm.h>
 #ifdef CONFIG_X86
 #include <asm/msi.h>
 #endif
@@ -297,7 +298,7 @@ int pci_add_device(u16 seg, u8 bus, u8 devfn, const struct pci_dev_info *info)
     struct pci_dev *pdev;
     unsigned int slot = PCI_SLOT(devfn), func = PCI_FUNC(devfn);
     const char *pdev_type;
-    int ret = -ENOMEM;
+    int ret;
 
     if (!info)
         pdev_type = "device";
@@ -318,6 +319,12 @@ int pci_add_device(u16 seg, u8 bus, u8 devfn, const struct pci_dev_info *info)
         pdev_type = "device";
     }
 
+    ret = xsm_resource_plug_pci((seg << 16) | (bus << 8) | devfn);
+    if ( ret )
+        return ret;
+
+    ret = -ENOMEM;
+
     spin_lock(&pcidevs_lock);
     pseg = alloc_pseg(seg);
     if ( !pseg )
@@ -426,7 +433,13 @@ int pci_remove_device(u16 seg, u8 bus, u8 devfn)
 {
     struct pci_seg *pseg = get_pseg(seg);
     struct pci_dev *pdev;
-    int ret = -ENODEV;
+    int ret;
+
+    ret = xsm_resource_unplug_pci((seg << 16) | (bus << 8) | devfn);
+    if ( ret )
+        return ret;
+
+    ret = -ENODEV;
 
     if ( !pseg )
         return -ENODEV;
diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
index 43829c7..0c7f248 100644
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -63,6 +63,7 @@ struct xsm_operations {
     int (*getvcpuinfo) (struct domain *d);
     int (*domain_settime) (struct domain *d);
     int (*set_target) (struct domain *d, struct domain *e);
+    int (*domctl) (struct domain *d, int cmd);
     int (*tbufcontrol) (void);
     int (*readconsole) (uint32_t clear);
     int (*sched_id) (void);
@@ -74,7 +75,9 @@ struct xsm_operations {
     int (*getcpuinfo) (void);
     int (*availheap) (void);
     int (*get_pmstat) (void);
+    int (*setpminfo) (void);
     int (*pm_op) (void);
+    int (*do_mca) (void);
 
     int (*evtchn_unbound) (struct domain *d, struct evtchn *chn, domid_t id2);
     int (*evtchn_interdomain) (struct domain *d1, struct evtchn *chn1,
@@ -96,6 +99,8 @@ struct xsm_operations {
     int (*alloc_security_evtchn) (struct evtchn *chn);
     void (*free_security_evtchn) (struct evtchn *chn);
 
+    int (*get_pod_target) (struct domain *d);
+    int (*set_pod_target) (struct domain *d);
     int (*memory_adjust_reservation) (struct domain *d1, struct domain *d2);
     int (*memory_stat_reservation) (struct domain *d1, struct domain *d2);
     int (*memory_pin_page) (struct domain *d, struct page_info *page);
@@ -109,10 +114,24 @@ struct xsm_operations {
     int (*irq_permission) (struct domain *d, int pirq, uint8_t allow);
     int (*iomem_permission) (struct domain *d, uint64_t s, uint64_t e, uint8_t allow);
 
+    int (*get_device_group) (uint32_t machine_bdf);
     int (*test_assign_device) (uint32_t machine_bdf);
     int (*assign_device) (struct domain *d, uint32_t machine_bdf);
     int (*deassign_device) (struct domain *d, uint32_t machine_bdf);
 
+    int (*resource_plug_core) (void);
+    int (*resource_unplug_core) (void);
+    int (*resource_plug_pci) (uint32_t machine_bdf);
+    int (*resource_unplug_pci) (uint32_t machine_bdf);
+    int (*resource_setup_pci) (uint32_t machine_bdf);
+    int (*resource_setup_gsi) (int gsi);
+    int (*resource_setup_misc) (void);
+
+    int (*page_offline)(uint32_t cmd);
+    int (*lockprof)(void);
+    int (*cpupool_op)(void);
+    int (*sched_op)(void);
+
     long (*__do_xsm_op) (XEN_GUEST_HANDLE(xsm_op_t) op);
 
 #ifdef CONFIG_X86
@@ -128,6 +147,8 @@ struct xsm_operations {
     int (*hvm_set_isa_irq_level) (struct domain *d);
     int (*hvm_set_pci_link_route) (struct domain *d);
     int (*hvm_inject_msi) (struct domain *d);
+    int (*mem_event) (struct domain *d);
+    int (*mem_sharing) (struct domain *d);
     int (*apic) (struct domain *d, int cmd);
     int (*xen_settime) (void);
     int (*memtype) (uint32_t access);
@@ -149,6 +170,7 @@ struct xsm_operations {
     int (*add_to_physmap) (struct domain *d1, struct domain *d2);
     int (*sendtrigger) (struct domain *d);
     int (*bind_pt_irq) (struct domain *d, struct xen_domctl_bind_pt_irq *bind);
+    int (*unbind_pt_irq) (struct domain *d);
     int (*pin_mem_cacheattr) (struct domain *d);
     int (*ext_vcpucontext) (struct domain *d, uint32_t cmd);
     int (*vcpuextstate) (struct domain *d, uint32_t cmd);
@@ -236,6 +258,11 @@ static inline int xsm_set_target (struct domain *d, struct domain *e)
     return xsm_call(set_target(d, e));
 }
 
+static inline int xsm_domctl (struct domain *d, int cmd)
+{
+    return xsm_call(domctl(d, cmd));
+}
+
 static inline int xsm_tbufcontrol (void)
 {
     return xsm_call(tbufcontrol());
@@ -291,11 +318,21 @@ static inline int xsm_get_pmstat(void)
     return xsm_call(get_pmstat());
 }
 
+static inline int xsm_setpminfo(void)
+{
+	return xsm_call(setpminfo());
+}
+
 static inline int xsm_pm_op(void)
 {
     return xsm_call(pm_op());
 }
 
+static inline int xsm_do_mca(void)
+{
+    return xsm_call(do_mca());
+}
+
 static inline int xsm_evtchn_unbound (struct domain *d1, struct evtchn *chn,
                                                                     domid_t id2)
 {
@@ -379,6 +416,16 @@ static inline void xsm_free_security_evtchn (struct evtchn *chn)
     (void)xsm_call(free_security_evtchn(chn));
 }
 
+static inline int xsm_get_pod_target (struct domain *d)
+{
+    return xsm_call(get_pod_target(d));
+}
+
+static inline int xsm_set_pod_target (struct domain *d)
+{
+    return xsm_call(set_pod_target(d));
+}
+
 static inline int xsm_memory_adjust_reservation (struct domain *d1, struct
                                                                     domain *d2)
 {
@@ -426,6 +473,11 @@ static inline int xsm_iomem_permission (struct domain *d, uint64_t s, uint64_t e
     return xsm_call(iomem_permission(d, s, e, allow));
 }
 
+static inline int xsm_get_device_group(uint32_t machine_bdf)
+{
+    return xsm_call(get_device_group(machine_bdf));
+}
+
 static inline int xsm_test_assign_device(uint32_t machine_bdf)
 {
     return xsm_call(test_assign_device(machine_bdf));
@@ -441,6 +493,61 @@ static inline int xsm_deassign_device(struct domain *d, uint32_t machine_bdf)
     return xsm_call(deassign_device(d, machine_bdf));
 }
 
+static inline int xsm_resource_plug_pci (uint32_t machine_bdf)
+{
+    return xsm_call(resource_plug_pci(machine_bdf));
+}
+
+static inline int xsm_resource_unplug_pci (uint32_t machine_bdf)
+{
+    return xsm_call(resource_unplug_pci(machine_bdf));
+}
+
+static inline int xsm_resource_plug_core (void)
+{
+    return xsm_call(resource_plug_core());
+}
+
+static inline int xsm_resource_unplug_core (void)
+{
+    return xsm_call(resource_unplug_core());
+}
+
+static inline int xsm_resource_setup_pci (uint32_t machine_bdf)
+{
+    return xsm_call(resource_setup_pci(machine_bdf));
+}
+
+static inline int xsm_resource_setup_gsi (int gsi)
+{
+    return xsm_call(resource_setup_gsi(gsi));
+}
+
+static inline int xsm_resource_setup_misc (void)
+{
+    return xsm_call(resource_setup_misc());
+}
+
+static inline int xsm_page_offline(uint32_t cmd)
+{
+    return xsm_call(page_offline(cmd));
+}
+
+static inline int xsm_lockprof(void)
+{
+    return xsm_call(lockprof());
+}
+
+static inline int xsm_cpupool_op(void)
+{
+    return xsm_call(cpupool_op());
+}
+
+static inline int xsm_sched_op(void)
+{
+    return xsm_call(sched_op());
+}
+
 static inline long __do_xsm_op (XEN_GUEST_HANDLE(xsm_op_t) op)
 {
 #ifdef XSM_ENABLE
@@ -528,6 +635,16 @@ static inline int xsm_hvm_inject_msi (struct domain *d)
     return xsm_call(hvm_inject_msi(d));
 }
 
+static inline int xsm_mem_event (struct domain *d)
+{
+    return xsm_call(mem_event(d));
+}
+
+static inline int xsm_mem_sharing (struct domain *d)
+{
+    return xsm_call(mem_sharing(d));
+}
+
 static inline int xsm_apic (struct domain *d, int cmd)
 {
     return xsm_call(apic(d, cmd));
@@ -626,6 +743,11 @@ static inline int xsm_bind_pt_irq(struct domain *d,
     return xsm_call(bind_pt_irq(d, bind));
 }
 
+static inline int xsm_unbind_pt_irq(struct domain *d)
+{
+    return xsm_call(unbind_pt_irq(d));
+}
+
 static inline int xsm_pin_mem_cacheattr(struct domain *d)
 {
     return xsm_call(pin_mem_cacheattr(d));
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index 04c2f68..efe52bb 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -368,6 +368,16 @@ static int get_mfn_sid(unsigned long mfn, u32 *sid)
     return rc;    
 }
 
+static int flask_get_pod_target(struct domain *d)
+{
+    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN, DOMAIN__GETPODTARGET);
+}
+
+static int flask_set_pod_target(struct domain *d)
+{
+    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN, DOMAIN__SETPODTARGET);
+}
+
 static int flask_memory_adjust_reservation(struct domain *d1, struct domain *d2)
 {
     return domain_has_perm(d1, d2, SECCLASS_MMU, MMU__ADJUST);
@@ -582,6 +592,11 @@ static int flask_set_target(struct domain *d, struct domain *e)
     return domain_has_perm(d, e, SECCLASS_DOMAIN, DOMAIN__SET_TARGET);
 }
 
+static int flask_domctl(struct domain *d, int cmd)
+{
+    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN, DOMAIN__SET_MISC_INFO);
+}
+
 static int flask_tbufcontrol(void)
 {
     return domain_has_xen(current->domain, XEN__TBUFCONTROL);
@@ -635,6 +650,26 @@ static int flask_availheap(void)
     return domain_has_xen(current->domain, XEN__HEAP);
 }
 
+static int flask_get_pmstat(void)
+{
+    return domain_has_xen(current->domain, XEN__PM_OP);
+}
+
+static int flask_setpminfo(void)
+{
+    return domain_has_xen(current->domain, XEN__PM_OP);
+}
+
+static int flask_pm_op(void)
+{
+    return domain_has_xen(current->domain, XEN__PM_OP);
+}
+
+static int flask_do_mca(void)
+{
+    return domain_has_xen(current->domain, XEN__MCA_OP);
+}
+
 static inline u32 resource_to_perm(uint8_t access)
 {
     if ( access )
@@ -727,6 +762,135 @@ static int flask_iomem_permission(struct domain *d, uint64_t start, uint64_t end
     return security_iterate_iomem_sids(start, end, _iomem_has_perm, &data);
 }
 
+static int flask_resource_plug_core(void)
+{
+    struct domain_security_struct *ssec;
+
+    ssec = current->domain->ssid;
+    return avc_has_perm(ssec->sid, SECINITSID_DOMXEN, SECCLASS_RESOURCE, RESOURCE__PLUG, NULL);
+}
+
+static int flask_resource_unplug_core(void)
+{
+    struct domain_security_struct *ssec;
+
+    ssec = current->domain->ssid;
+    return avc_has_perm(ssec->sid, SECINITSID_DOMXEN, SECCLASS_RESOURCE, RESOURCE__UNPLUG, NULL);
+}
+
+static int flask_resource_use_core(void)
+{
+    struct domain_security_struct *ssec;
+
+    ssec = current->domain->ssid;
+    return avc_has_perm(ssec->sid, SECINITSID_DOMXEN, SECCLASS_RESOURCE, RESOURCE__USE, NULL);
+}
+
+static int flask_resource_plug_pci(uint32_t machine_bdf)
+{
+    u32 rsid;
+    int rc = -EPERM;
+    struct avc_audit_data ad;
+    struct domain_security_struct *ssec;
+
+    rc = security_device_sid(machine_bdf, &rsid);
+    if ( rc )
+        return rc;
+
+    AVC_AUDIT_DATA_INIT(&ad, DEV);
+    ad.device = (unsigned long) machine_bdf;
+    ssec = current->domain->ssid;
+    return avc_has_perm(ssec->sid, rsid, SECCLASS_RESOURCE, RESOURCE__PLUG, &ad);
+}
+
+static int flask_resource_unplug_pci(uint32_t machine_bdf)
+{
+    u32 rsid;
+    int rc = -EPERM;
+    struct avc_audit_data ad;
+    struct domain_security_struct *ssec;
+
+    rc = security_device_sid(machine_bdf, &rsid);
+    if ( rc )
+        return rc;
+
+    AVC_AUDIT_DATA_INIT(&ad, DEV);
+    ad.device = (unsigned long) machine_bdf;
+    ssec = current->domain->ssid;
+    return avc_has_perm(ssec->sid, rsid, SECCLASS_RESOURCE, RESOURCE__UNPLUG, &ad);
+}
+
+static int flask_resource_setup_pci(uint32_t machine_bdf)
+{
+    u32 rsid;
+    int rc = -EPERM;
+    struct avc_audit_data ad;
+    struct domain_security_struct *ssec;
+
+    rc = security_device_sid(machine_bdf, &rsid);
+    if ( rc )
+        return rc;
+
+    AVC_AUDIT_DATA_INIT(&ad, DEV);
+    ad.device = (unsigned long) machine_bdf;
+    ssec = current->domain->ssid;
+    return avc_has_perm(ssec->sid, rsid, SECCLASS_RESOURCE, RESOURCE__SETUP, &ad);
+}
+
+static int flask_resource_setup_gsi(int gsi)
+{
+    u32 rsid;
+    int rc = -EPERM;
+    struct avc_audit_data ad;
+    struct domain_security_struct *ssec;
+
+    rc = security_irq_sid(gsi, &rsid);
+    if ( rc )
+        return rc;
+
+    AVC_AUDIT_DATA_INIT(&ad, IRQ);
+    ad.irq = gsi;
+    ssec = current->domain->ssid;
+    return avc_has_perm(ssec->sid, rsid, SECCLASS_RESOURCE, RESOURCE__SETUP, &ad);
+}
+
+static int flask_resource_setup_misc(void)
+{
+    struct domain_security_struct *ssec;
+
+    ssec = current->domain->ssid;
+    return avc_has_perm(ssec->sid, SECINITSID_XEN, SECCLASS_RESOURCE, RESOURCE__SETUP, NULL);
+}
+
+static inline int flask_page_offline(uint32_t cmd)
+{
+    switch (cmd) {
+    case sysctl_page_offline:
+        return flask_resource_unplug_core();
+    case sysctl_page_online:
+        return flask_resource_plug_core();
+    case sysctl_query_page_offline:
+        return flask_resource_use_core();
+    default:
+        return -EPERM;
+    }
+}
+
+static inline int flask_lockprof(void)
+{
+    return domain_has_xen(current->domain, XEN__LOCKPROF);
+}
+
+static inline int flask_cpupool_op(void)
+{
+    return domain_has_xen(current->domain, XEN__CPUPOOL_OP);
+}
+
+static inline int flask_sched_op(void)
+{
+    return domain_has_xen(current->domain, XEN__SCHED_OP);
+}
+
 static int flask_perfcontrol(void)
 {
     return domain_has_xen(current->domain, XEN__PERFCONTROL);
@@ -887,8 +1051,11 @@ static int flask_hvm_param(struct domain *d, unsigned long op)
     case HVMOP_get_param:
         perm = HVM__GETPARAM;
         break;
+    case HVMOP_track_dirty_vram:
+        perm = HVM__TRACKDIRTYVRAM;
+        break;
     default:
-        return -EPERM;
+        perm = HVM__HVMCTL;
     }
 
     return domain_has_perm(current->domain, d, SECCLASS_HVM, perm);
@@ -909,6 +1076,16 @@ static int flask_hvm_set_pci_link_route(struct domain *d)
     return domain_has_perm(current->domain, d, SECCLASS_HVM, HVM__PCIROUTE);
 }
 
+static int flask_mem_event(struct domain *d)
+{
+    return domain_has_perm(current->domain, d, SECCLASS_HVM, HVM__MEM_EVENT);
+}
+
+static int flask_mem_sharing(struct domain *d)
+{
+    return domain_has_perm(current->domain, d, SECCLASS_HVM, HVM__MEM_SHARING);
+}
+
 static int flask_apic(struct domain *d, int cmd)
 {
     u32 perm;
@@ -1088,6 +1265,19 @@ static int flask_sendtrigger(struct domain *d)
     return domain_has_perm(current->domain, d, SECCLASS_DOMAIN, DOMAIN__TRIGGER);
 }
 
+static int flask_get_device_group(uint32_t machine_bdf)
+{
+    u32 rsid;
+    int rc = -EPERM;
+    struct domain_security_struct *ssec = current->domain->ssid;
+
+    rc = security_device_sid(machine_bdf, &rsid);
+    if ( rc )
+        return rc;
+
+    return avc_has_perm(ssec->sid, rsid, SECCLASS_RESOURCE, RESOURCE__STAT_DEVICE, NULL);
+}
+
 static int flask_test_assign_device(uint32_t machine_bdf)
 {
     u32 rsid;
@@ -1174,6 +1364,11 @@ static int flask_bind_pt_irq (struct domain *d, struct xen_domctl_bind_pt_irq *b
     return avc_has_perm(tsec->sid, rsid, SECCLASS_RESOURCE, RESOURCE__USE, &ad);
 }
 
+static int flask_unbind_pt_irq (struct domain *d)
+{
+    return domain_has_perm(current->domain, d, SECCLASS_RESOURCE, RESOURCE__REMOVE);
+}
+
 static int flask_pin_mem_cacheattr (struct domain *d)
 {
     return domain_has_perm(current->domain, d, SECCLASS_HVM, HVM__CACHEATTR);
@@ -1236,6 +1431,7 @@ static struct xsm_operations flask_ops = {
     .getvcpuinfo = flask_getvcpuinfo,
     .domain_settime = flask_domain_settime,
     .set_target = flask_set_target,
+    .domctl = flask_domctl,
     .tbufcontrol = flask_tbufcontrol,
     .readconsole = flask_readconsole,
     .sched_id = flask_sched_id,
@@ -1246,6 +1442,10 @@ static struct xsm_operations flask_ops = {
     .debug_keys = flask_debug_keys,
     .getcpuinfo = flask_getcpuinfo,
     .availheap = flask_availheap,
+    .get_pmstat = flask_get_pmstat,
+    .setpminfo = flask_setpminfo,
+    .pm_op = flask_pm_op,
+    .do_mca = flask_do_mca,
 
     .evtchn_unbound = flask_evtchn_unbound,
     .evtchn_interdomain = flask_evtchn_interdomain,
@@ -1266,6 +1466,8 @@ static struct xsm_operations flask_ops = {
     .alloc_security_evtchn = flask_alloc_security_evtchn,
     .free_security_evtchn = flask_free_security_evtchn,
 
+    .get_pod_target = flask_get_pod_target,
+    .set_pod_target = flask_set_pod_target,
     .memory_adjust_reservation = flask_memory_adjust_reservation,
     .memory_stat_reservation = flask_memory_stat_reservation,
     .memory_pin_page = flask_memory_pin_page,
@@ -1280,6 +1482,19 @@ static struct xsm_operations flask_ops = {
     .irq_permission = flask_irq_permission,
     .iomem_permission = flask_iomem_permission,
 
+    .resource_plug_core = flask_resource_plug_core,
+    .resource_unplug_core = flask_resource_unplug_core,
+    .resource_plug_pci = flask_resource_plug_pci,
+    .resource_unplug_pci = flask_resource_unplug_pci,
+    .resource_setup_pci = flask_resource_setup_pci,
+    .resource_setup_gsi = flask_resource_setup_gsi,
+    .resource_setup_misc = flask_resource_setup_misc,
+
+    .page_offline = flask_page_offline,
+    .lockprof = flask_lockprof,
+    .cpupool_op = flask_cpupool_op,
+    .sched_op = flask_sched_op,
+
     .__do_xsm_op = do_flask_op,
 
 #ifdef CONFIG_X86
@@ -1293,6 +1508,8 @@ static struct xsm_operations flask_ops = {
     .hvm_set_pci_intx_level = flask_hvm_set_pci_intx_level,
     .hvm_set_isa_irq_level = flask_hvm_set_isa_irq_level,
     .hvm_set_pci_link_route = flask_hvm_set_pci_link_route,
+    .mem_event = flask_mem_event,
+    .mem_sharing = flask_mem_sharing,
     .apic = flask_apic,
     .xen_settime = flask_xen_settime,
     .memtype = flask_memtype,
@@ -1310,10 +1527,12 @@ static struct xsm_operations flask_ops = {
     .update_va_mapping = flask_update_va_mapping,
     .add_to_physmap = flask_add_to_physmap,
     .sendtrigger = flask_sendtrigger,
+    .get_device_group = flask_get_device_group,
     .test_assign_device = flask_test_assign_device,
     .assign_device = flask_assign_device,
     .deassign_device = flask_deassign_device,
     .bind_pt_irq = flask_bind_pt_irq,
+    .unbind_pt_irq = flask_unbind_pt_irq,
     .pin_mem_cacheattr = flask_pin_mem_cacheattr,
     .ext_vcpucontext = flask_ext_vcpucontext,
     .vcpuextstate = flask_vcpuextstate,
diff --git a/xen/xsm/flask/include/av_perm_to_string.h b/xen/xsm/flask/include/av_perm_to_string.h
index 56572a7..85cbffc 100644
--- a/xen/xsm/flask/include/av_perm_to_string.h
+++ b/xen/xsm/flask/include/av_perm_to_string.h
@@ -24,6 +24,11 @@
    S_(SECCLASS_XEN, XEN__DEBUG, "debug")
    S_(SECCLASS_XEN, XEN__GETCPUINFO, "getcpuinfo")
    S_(SECCLASS_XEN, XEN__HEAP, "heap")
+   S_(SECCLASS_XEN, XEN__PM_OP, "pm_op")
+   S_(SECCLASS_XEN, XEN__MCA_OP, "mca_op")
+   S_(SECCLASS_XEN, XEN__LOCKPROF, "lockprof")
+   S_(SECCLASS_XEN, XEN__CPUPOOL_OP, "cpupool_op")
+   S_(SECCLASS_XEN, XEN__SCHED_OP, "sched_op")
    S_(SECCLASS_DOMAIN, DOMAIN__SETVCPUCONTEXT, "setvcpucontext")
    S_(SECCLASS_DOMAIN, DOMAIN__PAUSE, "pause")
    S_(SECCLASS_DOMAIN, DOMAIN__UNPAUSE, "unpause")
@@ -52,6 +57,9 @@
    S_(SECCLASS_DOMAIN, DOMAIN__SETEXTVCPUCONTEXT, "setextvcpucontext")
    S_(SECCLASS_DOMAIN, DOMAIN__GETVCPUEXTSTATE, "getvcpuextstate")
    S_(SECCLASS_DOMAIN, DOMAIN__SETVCPUEXTSTATE, "setvcpuextstate")
+   S_(SECCLASS_DOMAIN, DOMAIN__GETPODTARGET, "getpodtarget")
+   S_(SECCLASS_DOMAIN, DOMAIN__SETPODTARGET, "setpodtarget")
+   S_(SECCLASS_DOMAIN, DOMAIN__SET_MISC_INFO, "set_misc_info")
    S_(SECCLASS_HVM, HVM__SETHVMC, "sethvmc")
    S_(SECCLASS_HVM, HVM__GETHVMC, "gethvmc")
    S_(SECCLASS_HVM, HVM__SETPARAM, "setparam")
@@ -62,6 +70,9 @@
    S_(SECCLASS_HVM, HVM__BIND_IRQ, "bind_irq")
    S_(SECCLASS_HVM, HVM__CACHEATTR, "cacheattr")
    S_(SECCLASS_HVM, HVM__TRACKDIRTYVRAM, "trackdirtyvram")
+   S_(SECCLASS_HVM, HVM__HVMCTL, "hvmctl")
+   S_(SECCLASS_HVM, HVM__MEM_EVENT, "mem_event")
+   S_(SECCLASS_HVM, HVM__MEM_SHARING, "mem_sharing")
    S_(SECCLASS_EVENT, EVENT__BIND, "bind")
    S_(SECCLASS_EVENT, EVENT__SEND, "send")
    S_(SECCLASS_EVENT, EVENT__STATUS, "status")
@@ -103,6 +114,9 @@
    S_(SECCLASS_RESOURCE, RESOURCE__STAT_DEVICE, "stat_device")
    S_(SECCLASS_RESOURCE, RESOURCE__ADD_DEVICE, "add_device")
    S_(SECCLASS_RESOURCE, RESOURCE__REMOVE_DEVICE, "remove_device")
+   S_(SECCLASS_RESOURCE, RESOURCE__PLUG, "plug")
+   S_(SECCLASS_RESOURCE, RESOURCE__UNPLUG, "unplug")
+   S_(SECCLASS_RESOURCE, RESOURCE__SETUP, "setup")
    S_(SECCLASS_SECURITY, SECURITY__COMPUTE_AV, "compute_av")
    S_(SECCLASS_SECURITY, SECURITY__COMPUTE_CREATE, "compute_create")
    S_(SECCLASS_SECURITY, SECURITY__COMPUTE_MEMBER, "compute_member")
diff --git a/xen/xsm/flask/include/av_permissions.h b/xen/xsm/flask/include/av_permissions.h
index 67511ad..9e55a86 100644
--- a/xen/xsm/flask/include/av_permissions.h
+++ b/xen/xsm/flask/include/av_permissions.h
@@ -24,6 +24,11 @@
 #define XEN__DEBUG                                0x00400000UL
 #define XEN__GETCPUINFO                           0x00800000UL
 #define XEN__HEAP                                 0x01000000UL
+#define XEN__PM_OP                                0x02000000UL
+#define XEN__MCA_OP                               0x04000000UL
+#define XEN__LOCKPROF                             0x08000000UL
+#define XEN__CPUPOOL_OP                           0x10000000UL
+#define XEN__SCHED_OP                             0x20000000UL
 
 #define DOMAIN__SETVCPUCONTEXT                    0x00000001UL
 #define DOMAIN__PAUSE                             0x00000002UL
@@ -53,6 +58,9 @@
 #define DOMAIN__SETEXTVCPUCONTEXT                 0x02000000UL
 #define DOMAIN__GETVCPUEXTSTATE                   0x04000000UL
 #define DOMAIN__SETVCPUEXTSTATE                   0x08000000UL
+#define DOMAIN__GETPODTARGET                      0x10000000UL
+#define DOMAIN__SETPODTARGET                      0x20000000UL
+#define DOMAIN__SET_MISC_INFO                     0x40000000UL
 
 #define HVM__SETHVMC                              0x00000001UL
 #define HVM__GETHVMC                              0x00000002UL
@@ -64,6 +72,9 @@
 #define HVM__BIND_IRQ                             0x00000080UL
 #define HVM__CACHEATTR                            0x00000100UL
 #define HVM__TRACKDIRTYVRAM                       0x00000200UL
+#define HVM__HVMCTL                               0x00000400UL
+#define HVM__MEM_EVENT                            0x00000800UL
+#define HVM__MEM_SHARING                          0x00001000UL
 
 #define EVENT__BIND                               0x00000001UL
 #define EVENT__SEND                               0x00000002UL
@@ -110,6 +121,9 @@
 #define RESOURCE__STAT_DEVICE                     0x00000200UL
 #define RESOURCE__ADD_DEVICE                      0x00000400UL
 #define RESOURCE__REMOVE_DEVICE                   0x00000800UL
+#define RESOURCE__PLUG                            0x00001000UL
+#define RESOURCE__UNPLUG                          0x00002000UL
+#define RESOURCE__SETUP                           0x00004000UL
 
 #define SECURITY__COMPUTE_AV                      0x00000001UL
 #define SECURITY__COMPUTE_CREATE                  0x00000002UL
-- 
1.7.7.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 20:39:57 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 20:39:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaZ8O-0003CK-9c; Tue, 13 Dec 2011 20:39:32 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RaZ8M-0003C8-Vo
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 20:39:31 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-11.tower-27.messagelabs.com!1323808702!49154870!1
X-Originating-IP: [63.239.65.40]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20695 invoked from network); 13 Dec 2011 20:38:22 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-11.tower-27.messagelabs.com with SMTP;
	13 Dec 2011 20:38:22 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea02.nsa.gov (8.12.10/8.12.10) with ESMTP id
	pBDKcdxP012682; Tue, 13 Dec 2011 20:38:39 GMT
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id pBDKcdnx017251; 
	Tue, 13 Dec 2011 15:38:39 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com, Keir Fraser <keir@xen.org>
Date: Tue, 13 Dec 2011 15:38:52 -0500
Message-Id: <1323808737-29125-4-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.4
In-Reply-To: <1323808737-29125-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1323808737-29125-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 3/8] xsm: only log dummy override if not setting
	up dummy_xsm_ops
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

The log messages from dummy overrides appear on every boot with XSM
enabled, and are just noise when filling in the dummy_xsm_ops structure.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 xen/xsm/dummy.c |   17 +++++++++--------
 1 files changed, 9 insertions(+), 8 deletions(-)

diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c
index a629396..d6f2da0 100644
--- a/xen/xsm/dummy.c
+++ b/xen/xsm/dummy.c
@@ -469,14 +469,15 @@ static int dummy_ioport_permission (struct domain *d, uint32_t s, uint32_t e, ui
 
 struct xsm_operations dummy_xsm_ops;
 
-#define set_to_dummy_if_null(ops, function)                        \
-    do {                                                           \
-        if ( !ops->function )                                      \
-        {                                                          \
-            ops->function = dummy_##function;                      \
-            dprintk(XENLOG_DEBUG, "Had to override the " #function \
-                " security operation with the dummy one.\n");      \
-        }                                                          \
+#define set_to_dummy_if_null(ops, function)                            \
+    do {                                                               \
+        if ( !ops->function )                                          \
+        {                                                              \
+            ops->function = dummy_##function;                          \
+            if (ops != &dummy_xsm_ops)                                 \
+                dprintk(XENLOG_DEBUG, "Had to override the " #function \
+                    " security operation with the dummy one.\n");      \
+        }                                                              \
     } while (0)
 
 void xsm_fixup_ops (struct xsm_operations *ops)
-- 
1.7.7.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 20:39:58 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 20:39:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaZ8S-0003Dn-S9; Tue, 13 Dec 2011 20:39:36 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RaZ8R-0003C4-P4
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 20:39:36 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-5.tower-182.messagelabs.com!1323808720!7149482!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16228 invoked from network); 13 Dec 2011 20:38:41 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-5.tower-182.messagelabs.com with SMTP;
	13 Dec 2011 20:38:41 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea01.nsa.gov (8.12.10/8.12.10) with ESMTP id
	pBDKcdRx010714; Tue, 13 Dec 2011 20:38:39 GMT
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id pBDKcdnu017251; 
	Tue, 13 Dec 2011 15:38:39 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com, Keir Fraser <keir@xen.org>
Date: Tue, 13 Dec 2011 15:38:49 -0500
Message-Id: <1323808737-29125-1-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.4
Subject: [Xen-devel] [PATCH 0/8] New XSM hooks and updates
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Since the introduction of the FLASK security module, new hypercalls and
access paths have been added to Xen without corresponding XSM hooks.
This series adds access checks on these operations and also fixes some
bugs in error paths.

[PATCH 1/8] xsm/flask: Add missing unlock on error path
[PATCH 2/8] xsm/flask: report memory and IO ranges in audit messages
[PATCH 3/8] xsm: only log dummy override if not setting up
[PATCH 4/8] xsm: add remote_remap permission
[PATCH 5/8] xsm: Add missing access checks
[PATCH 6/8] xsm: fix up dummy ops
[PATCH 7/8] xsm: add checks on PCI configuration access
[PATCH 8/8] xl.pod.1: improve documentation of FLASK commands

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 20:39:58 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 20:39:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaZ8Q-0003Cp-RD; Tue, 13 Dec 2011 20:39:34 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RaZ8O-0003CI-JA
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 20:39:33 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-13.tower-27.messagelabs.com!1323808697!52045454!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32682 invoked from network); 13 Dec 2011 20:38:18 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-13.tower-27.messagelabs.com with SMTP;
	13 Dec 2011 20:38:18 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea01.nsa.gov (8.12.10/8.12.10) with ESMTP id
	pBDKceRx010718; Tue, 13 Dec 2011 20:38:40 GMT
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id pBDKcdo1017251; 
	Tue, 13 Dec 2011 15:38:39 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com, Keir Fraser <keir@xen.org>
Date: Tue, 13 Dec 2011 15:38:54 -0500
Message-Id: <1323808737-29125-6-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.4
In-Reply-To: <1323808737-29125-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1323808737-29125-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 5/8] xsm: Add missing access checks
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Actions requiring IS_PRIV should also require some XSM access control in
order for XSM to be useful in confining multiple privileged domains. Add
XSM hooks for new hypercalls and sub-commands that are under IS_PRIV but
not currently under any access checks.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 tools/flask/policy/policy/flask/access_vectors |   14 ++
 xen/arch/ia64/xen/mm.c                         |    8 +
 xen/arch/x86/cpu/mcheck/mce.c                  |    4 +
 xen/arch/x86/domctl.c                          |   17 ++-
 xen/arch/x86/hvm/hvm.c                         |   26 +++
 xen/arch/x86/mm.c                              |   10 +-
 xen/arch/x86/msi.c                             |    6 +
 xen/arch/x86/physdev.c                         |    9 +
 xen/arch/x86/platform_hypercall.c              |   28 +++
 xen/arch/x86/sysctl.c                          |   14 ++
 xen/common/domctl.c                            |   10 +-
 xen/common/grant_table.c                       |   10 +
 xen/common/sysctl.c                            |   17 ++
 xen/drivers/passthrough/iommu.c                |    8 +
 xen/drivers/passthrough/pci.c                  |   17 ++-
 xen/include/xsm/xsm.h                          |  122 +++++++++++++
 xen/xsm/flask/hooks.c                          |  221 +++++++++++++++++++++++-
 xen/xsm/flask/include/av_perm_to_string.h      |   14 ++
 xen/xsm/flask/include/av_permissions.h         |   14 ++
 19 files changed, 556 insertions(+), 13 deletions(-)

diff --git a/tools/flask/policy/policy/flask/access_vectors b/tools/flask/policy/policy/flask/access_vectors
index 38036d0..644f2e1 100644
--- a/tools/flask/policy/policy/flask/access_vectors
+++ b/tools/flask/policy/policy/flask/access_vectors
@@ -45,6 +45,11 @@ class xen
 	debug
 	getcpuinfo
 	heap
+	pm_op
+	mca_op
+	lockprof
+	cpupool_op
+	sched_op
 }
 
 class domain
@@ -77,6 +82,9 @@ class domain
 	setextvcpucontext
 	getvcpuextstate
 	setvcpuextstate
+	getpodtarget
+	setpodtarget
+	set_misc_info
 }
 
 class hvm
@@ -91,6 +99,9 @@ class hvm
 	bind_irq
 	cacheattr
     trackdirtyvram
+    hvmctl
+    mem_event
+    mem_sharing
 }
 
 class event
@@ -152,6 +163,9 @@ class resource
 	stat_device
 	add_device
 	remove_device
+	plug
+	unplug
+	setup
 }
 
 class security
diff --git a/xen/arch/ia64/xen/mm.c b/xen/arch/ia64/xen/mm.c
index d440e4d..694bf95 100644
--- a/xen/arch/ia64/xen/mm.c
+++ b/xen/arch/ia64/xen/mm.c
@@ -3496,6 +3496,14 @@ arch_memory_op(int op, XEN_GUEST_HANDLE(void) arg)
             return rc;
 
         if ( op == XENMEM_set_pod_target )
+            rc = xsm_set_pod_target(d);
+        else
+            rc = xsm_get_pod_target(d);
+
+        if ( rc != 0 )
+            goto pod_target_out_unlock;
+
+        if ( op == XENMEM_set_pod_target )
         {
             /* if -ENOSYS is returned,
                domain builder aborts domain creation. */
diff --git a/xen/arch/x86/cpu/mcheck/mce.c b/xen/arch/x86/cpu/mcheck/mce.c
index 6af93c0..b592041 100644
--- a/xen/arch/x86/cpu/mcheck/mce.c
+++ b/xen/arch/x86/cpu/mcheck/mce.c
@@ -1384,6 +1384,10 @@ long do_mca(XEN_GUEST_HANDLE(xen_mc_t) u_xen_mc)
     if (!IS_PRIV(v->domain) )
         return x86_mcerr(NULL, -EPERM);
 
+    ret = xsm_do_mca();
+    if ( ret )
+        return x86_mcerr(NULL, ret);
+
     if ( copy_from_guest(op, u_xen_mc, 1) )
         return x86_mcerr("do_mca: failed copyin of xen_mc_t", -EFAULT);
 
diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c
index 4e258f3..9c9d5d1 100644
--- a/xen/arch/x86/domctl.c
+++ b/xen/arch/x86/domctl.c
@@ -1441,8 +1441,10 @@ long arch_do_domctl(
         d = rcu_lock_domain_by_id(domctl->domain);
         if ( d != NULL )
         {
-            ret = mem_event_domctl(d, &domctl->u.mem_event_op,
-                                   guest_handle_cast(u_domctl, void));
+            ret = xsm_mem_event(d);
+            if ( !ret )
+                ret = mem_event_domctl(d, &domctl->u.mem_event_op,
+                                       guest_handle_cast(u_domctl, void));
             rcu_unlock_domain(d);
             copy_to_guest(u_domctl, domctl, 1);
         } 
@@ -1457,7 +1459,9 @@ long arch_do_domctl(
         d = rcu_lock_domain_by_id(domctl->domain);
         if ( d != NULL )
         {
-            ret = mem_sharing_domctl(d, &domctl->u.mem_sharing_op);
+            ret = xsm_mem_sharing(d);
+            if ( !ret )
+                ret = mem_sharing_domctl(d, &domctl->u.mem_sharing_op);
             rcu_unlock_domain(d);
             copy_to_guest(u_domctl, domctl, 1);
         } 
@@ -1498,8 +1502,11 @@ long arch_do_domctl(
         d = rcu_lock_domain_by_id(domctl->domain);
         if ( d != NULL )
         {
-            p2m = p2m_get_hostp2m(d);
-            p2m->access_required = domctl->u.access_required.access_required;
+            ret = xsm_mem_event(d);
+            if ( !ret ) {
+                p2m = p2m_get_hostp2m(d);
+                p2m->access_required = domctl->u.access_required.access_required;
+            }
             rcu_unlock_domain(d);
         } 
     }
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 901132d..bae3696 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -3869,6 +3869,10 @@ long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE(void) arg)
         if ( rc != 0 )
             return rc;
 
+        rc = xsm_hvm_param(d, op);
+        if ( rc )
+            goto param_fail_getmemtype;
+
         rc = -EINVAL;
         if ( is_hvm_domain(d) )
         {
@@ -3883,6 +3887,8 @@ long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE(void) arg)
                 a.mem_type =  HVMMEM_mmio_dm;
             rc = copy_to_guest(arg, &a, 1) ? -EFAULT : 0;
         }
+
+    param_fail_getmemtype:
         rcu_unlock_domain(d);
         break;
     }
@@ -3911,6 +3917,10 @@ long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE(void) arg)
         if ( !is_hvm_domain(d) )
             goto param_fail4;
 
+        rc = xsm_hvm_param(d, op);
+        if ( rc )
+            goto param_fail4;
+
         rc = -EINVAL;
         if ( (a.first_pfn > domain_get_maximum_gpfn(d)) ||
              ((a.first_pfn + a.nr - 1) < a.first_pfn) ||
@@ -3986,6 +3996,10 @@ long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE(void) arg)
         if ( !is_hvm_domain(d) )
             goto param_fail5;
 
+        rc = xsm_hvm_param(d, op);
+        if ( rc )
+            goto param_fail5;
+
         rc = -EINVAL;
         if ( (a.first_pfn > domain_get_maximum_gpfn(d)) ||
              ((a.first_pfn + a.nr - 1) < a.first_pfn) ||
@@ -4016,6 +4030,10 @@ long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE(void) arg)
         if ( !is_hvm_domain(d) )
             goto param_fail6;
 
+        rc = xsm_hvm_param(d, op);
+        if ( rc )
+            goto param_fail6;
+
         rc = -EINVAL;
         if ( (a.pfn > domain_get_maximum_gpfn(d)) && a.pfn != ~0ull )
             goto param_fail6;
@@ -4048,6 +4066,10 @@ long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE(void) arg)
         if ( !is_hvm_domain(d) || !paging_mode_shadow(d) )
             goto param_fail7;
 
+        rc = xsm_hvm_param(d, op);
+        if ( rc )
+            goto param_fail7;
+
         rc = 0;
         pagetable_dying(d, a.gpa);
 
@@ -4098,6 +4120,10 @@ long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE(void) arg)
         if ( !is_hvm_domain(d) )
             goto param_fail8;
 
+        rc = xsm_hvm_param(d, op);
+        if ( rc )
+            goto param_fail8;
+
         rc = -ENOENT;
         if ( tr.vcpuid >= d->max_vcpus || (v = d->vcpu[tr.vcpuid]) == NULL )
             goto param_fail8;
diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index 19391fc..67f5630 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -5041,7 +5041,7 @@ long arch_memory_op(int op, XEN_GUEST_HANDLE(void) arg)
 
         /* Support DOMID_SELF? */
         if ( !IS_PRIV(current->domain) )
-            return -EINVAL;
+            return -EPERM;
 
         if ( copy_from_guest(&target, arg, 1) )
             return -EFAULT;
@@ -5051,6 +5051,14 @@ long arch_memory_op(int op, XEN_GUEST_HANDLE(void) arg)
             return rc;
 
         if ( op == XENMEM_set_pod_target )
+            rc = xsm_set_pod_target(d);
+        else
+            rc = xsm_get_pod_target(d);
+
+        if ( rc != 0 )
+            goto pod_target_out_unlock;
+
+        if ( op == XENMEM_set_pod_target )
         {
             if ( target.target_pages > d->max_pages )
             {
diff --git a/xen/arch/x86/msi.c b/xen/arch/x86/msi.c
index 2d86006..782b84b 100644
--- a/xen/arch/x86/msi.c
+++ b/xen/arch/x86/msi.c
@@ -29,6 +29,7 @@
 #include <io_ports.h>
 #include <public/physdev.h>
 #include <xen/iommu.h>
+#include <xsm/xsm.h>
 
 /* bitmap indicate which fixed map is free */
 DEFINE_SPINLOCK(msix_fixmap_lock);
@@ -992,6 +993,7 @@ int pci_restore_msi_state(struct pci_dev *pdev)
 {
     unsigned long flags;
     int irq;
+    int ret;
     struct msi_desc *entry, *tmp;
     struct irq_desc *desc;
 
@@ -1000,6 +1002,10 @@ int pci_restore_msi_state(struct pci_dev *pdev)
     if (!pdev)
         return -EINVAL;
 
+    ret = xsm_resource_setup_pci((pdev->seg << 16) | (pdev->bus << 8) | pdev->devfn);
+    if ( ret )
+        return ret;
+
     list_for_each_entry_safe( entry, tmp, &pdev->msi_list, list )
     {
         irq = entry->irq;
diff --git a/xen/arch/x86/physdev.c b/xen/arch/x86/physdev.c
index c1c7e54..ca4fb59 100644
--- a/xen/arch/x86/physdev.c
+++ b/xen/arch/x86/physdev.c
@@ -600,6 +600,10 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg)
         if ( !IS_PRIV(current->domain) )
             break;
 
+        ret = xsm_resource_setup_misc();
+        if ( ret )
+            break;
+
         ret = -EFAULT;
         if ( copy_from_guest(&info, arg, 1) )
             break;
@@ -662,6 +666,11 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg)
         ret = -EINVAL;
         if ( setup_gsi.gsi < 0 || setup_gsi.gsi >= nr_irqs_gsi )
             break;
+
+        ret = xsm_resource_setup_gsi(setup_gsi.gsi);
+        if ( ret )
+            break;
+
         ret = mp_register_gsi(setup_gsi.gsi, setup_gsi.triggering,
                               setup_gsi.polarity);
         break; 
diff --git a/xen/arch/x86/platform_hypercall.c b/xen/arch/x86/platform_hypercall.c
index a0d23ba..f9a836a 100644
--- a/xen/arch/x86/platform_hypercall.c
+++ b/xen/arch/x86/platform_hypercall.c
@@ -390,6 +390,10 @@ ret_t do_platform_op(XEN_GUEST_HANDLE(xen_platform_op_t) u_xenpf_op)
     break;
 
     case XENPF_set_processor_pminfo:
+        ret = xsm_setpminfo();
+        if ( ret )
+            break;
+
         switch ( op->u.set_pminfo.type )
         {
         case XEN_PM_PX:
@@ -440,6 +444,10 @@ ret_t do_platform_op(XEN_GUEST_HANDLE(xen_platform_op_t) u_xenpf_op)
 
         g_info = &op->u.pcpu_info;
 
+        ret = xsm_getcpuinfo();
+        if ( ret )
+            break;
+
         if ( !get_cpu_maps() )
         {
             ret = -EBUSY;
@@ -509,6 +517,10 @@ ret_t do_platform_op(XEN_GUEST_HANDLE(xen_platform_op_t) u_xenpf_op)
     {
         int cpu = op->u.cpu_ol.cpuid;
 
+        ret = xsm_resource_plug_core();
+        if ( ret )
+            break;
+
         if ( cpu >= nr_cpu_ids || !cpu_present(cpu) )
         {
             ret = -EINVAL;
@@ -521,6 +533,10 @@ ret_t do_platform_op(XEN_GUEST_HANDLE(xen_platform_op_t) u_xenpf_op)
             break;
         }
 
+        ret = xsm_resource_plug_core();
+        if ( ret )
+            break;
+
         ret = continue_hypercall_on_cpu(
             0, cpu_up_helper, (void *)(unsigned long)cpu);
         break;
@@ -530,6 +546,10 @@ ret_t do_platform_op(XEN_GUEST_HANDLE(xen_platform_op_t) u_xenpf_op)
     {
         int cpu = op->u.cpu_ol.cpuid;
 
+        ret = xsm_resource_unplug_core();
+        if ( ret )
+            break;
+
         if ( cpu == 0 )
         {
             ret = -EOPNOTSUPP;
@@ -555,12 +575,20 @@ ret_t do_platform_op(XEN_GUEST_HANDLE(xen_platform_op_t) u_xenpf_op)
     break;
 
     case XENPF_cpu_hotadd:
+        ret = xsm_resource_plug_core();
+        if ( ret )
+            break;
+
         ret = cpu_add(op->u.cpu_add.apic_id,
                       op->u.cpu_add.acpi_id,
                       op->u.cpu_add.pxm);
     break;
 
     case XENPF_mem_hotadd:
+        ret = xsm_resource_plug_core();
+        if ( ret )
+            break;
+
         ret = memory_add(op->u.mem_add.spfn,
                       op->u.mem_add.epfn,
                       op->u.mem_add.pxm);
diff --git a/xen/arch/x86/sysctl.c b/xen/arch/x86/sysctl.c
index 738e517..379f071 100644
--- a/xen/arch/x86/sysctl.c
+++ b/xen/arch/x86/sysctl.c
@@ -103,6 +103,10 @@ long arch_do_sysctl(
         uint32_t i, max_cpu_index, last_online_cpu;
         xen_sysctl_topologyinfo_t *ti = &sysctl->u.topologyinfo;
 
+        ret = xsm_physinfo();
+        if ( ret )
+            break;
+
         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;
@@ -139,6 +143,10 @@ long arch_do_sysctl(
         uint32_t i, j, max_node_index, last_online_node;
         xen_sysctl_numainfo_t *ni = &sysctl->u.numainfo;
 
+        ret = xsm_physinfo();
+        if ( ret )
+            break;
+
         last_online_node = last_node(node_online_map);
         max_node_index = min_t(uint32_t, ni->max_node_index, last_online_node);
         ni->max_node_index = last_online_node;
@@ -189,10 +197,16 @@ long arch_do_sysctl(
         switch ( sysctl->u.cpu_hotplug.op )
         {
         case XEN_SYSCTL_CPU_HOTPLUG_ONLINE:
+            ret = xsm_resource_plug_core();
+            if ( ret )
+                break;
             ret = continue_hypercall_on_cpu(
                 0, cpu_up_helper, (void *)(unsigned long)cpu);
             break;
         case XEN_SYSCTL_CPU_HOTPLUG_OFFLINE:
+            ret = xsm_resource_unplug_core();
+            if ( ret )
+                break;
             ret = continue_hypercall_on_cpu(
                 0, cpu_down_helper, (void *)(unsigned long)cpu);
             break;
diff --git a/xen/common/domctl.c b/xen/common/domctl.c
index 06594a0..d6ae09b 100644
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -972,9 +972,10 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domctl_t) u_domctl)
         d = rcu_lock_domain_by_id(op->domain);
         if ( d != NULL )
         {
-            d->suspend_evtchn = op->u.subscribe.port;
+            ret = xsm_domctl(d, op->cmd);
+            if ( !ret )
+                d->suspend_evtchn = op->u.subscribe.port;
             rcu_unlock_domain(d);
-            ret = 0;
         }
     }
     break;
@@ -985,9 +986,10 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domctl_t) u_domctl)
         ret = -ESRCH;
         if ( (d = rcu_lock_domain_by_id(op->domain)) != NULL )
         {
-            d->disable_migrate = op->u.disable_migrate.disable;
+            ret = xsm_domctl(d, op->cmd);
+            if ( !ret )
+                d->disable_migrate = op->u.disable_migrate.disable;
             rcu_unlock_domain(d);
-            ret = 0;
         }
     }
     break;
diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c
index e2b103b..fefa838 100644
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -2208,6 +2208,11 @@ gnttab_get_status_frames(XEN_GUEST_HANDLE(gnttab_get_status_frames_t) uop,
             op.status = GNTST_general_error;
         goto out1;
     }
+    rc = xsm_grant_setup(current->domain, d);
+    if ( rc ) {
+        op.status = GNTST_permission_denied;
+        goto out1;
+    }
 
     gt = d->grant_table;
 
@@ -2259,6 +2264,11 @@ gnttab_get_version(XEN_GUEST_HANDLE(gnttab_get_version_t uop))
         rcu_unlock_domain(d);
         return -EPERM;
     }
+    if ( xsm_grant_query_size(current->domain, d) )
+    {
+        rcu_unlock_domain(d);
+        return -EPERM;
+    }
     spin_lock(&d->grant_table->lock);
     op.version = d->grant_table->gt_version;
     spin_unlock(&d->grant_table->lock);
diff --git a/xen/common/sysctl.c b/xen/common/sysctl.c
index ccfdb22..f8f7cf8 100644
--- a/xen/common/sysctl.c
+++ b/xen/common/sysctl.c
@@ -152,6 +152,11 @@ long do_sysctl(XEN_GUEST_HANDLE(xen_sysctl_t) u_sysctl)
 #ifdef LOCK_PROFILE
     case XEN_SYSCTL_lockprof_op:
     {
+        ret = xsm_lockprof();
+        if ( ret )
+            break;
+
+        ret = perfc_control(&op->u.perfc_op);
         ret = spinlock_profile_control(&op->u.lockprof_op);
         if ( copy_to_guest(u_sysctl, op, 1) )
             ret = -EFAULT;
@@ -260,6 +265,10 @@ long do_sysctl(XEN_GUEST_HANDLE(xen_sysctl_t) u_sysctl)
         uint32_t *status, *ptr;
         unsigned long pfn;
 
+        ret = xsm_page_offline(op->u.page_offline.cmd);
+        if ( ret )
+            break;
+
         ptr = status = xmalloc_bytes( sizeof(uint32_t) *
                                 (op->u.page_offline.end -
                                   op->u.page_offline.start + 1));
@@ -314,6 +323,10 @@ long do_sysctl(XEN_GUEST_HANDLE(xen_sysctl_t) u_sysctl)
 
     case XEN_SYSCTL_cpupool_op:
     {
+        ret = xsm_cpupool_op();
+        if ( ret )
+            break;
+
         ret = cpupool_do_sysctl(&op->u.cpupool_op);
         if ( (ret == 0) && copy_to_guest(u_sysctl, op, 1) )
             ret = -EFAULT;
@@ -322,6 +335,10 @@ long do_sysctl(XEN_GUEST_HANDLE(xen_sysctl_t) u_sysctl)
 
     case XEN_SYSCTL_scheduler_op:
     {
+        ret = xsm_sched_op();
+        if ( ret )
+            break;
+
         ret = sched_adjust_global(&op->u.scheduler_op);
         if ( (ret == 0) && copy_to_guest(u_sysctl, op, 1) )
             ret = -EFAULT;
diff --git a/xen/drivers/passthrough/iommu.c b/xen/drivers/passthrough/iommu.c
index bacca11..d88e9d7 100644
--- a/xen/drivers/passthrough/iommu.c
+++ b/xen/drivers/passthrough/iommu.c
@@ -425,12 +425,16 @@ static int iommu_get_device_group(
              ((pdev->bus == bus) && (pdev->devfn == devfn)) )
             continue;
 
+        if ( xsm_get_device_group((seg << 16) | (pdev->bus << 8) | pdev->devfn) )
+            continue;
+
         sdev_id = ops->get_device_group_id(seg, pdev->bus, pdev->devfn);
         if ( (sdev_id == group_id) && (i < max_sdevs) )
         {
             bdf = 0;
             bdf |= (pdev->bus & 0xff) << 16;
             bdf |= (pdev->devfn & 0xff) << 8;
+
             if ( unlikely(copy_to_guest_offset(buf, i, &bdf, 1)) )
             {
                 spin_unlock(&pcidevs_lock);
@@ -519,6 +523,10 @@ int iommu_do_domctl(
         u32 max_sdevs;
         XEN_GUEST_HANDLE_64(uint32) sdevs;
 
+        ret = xsm_get_device_group(domctl->u.get_device_group.machine_sbdf);
+        if ( ret )
+            break;
+
         ret = -EINVAL;
         if ( (d = rcu_lock_domain_by_id(domctl->domain)) == NULL )
             break;
diff --git a/xen/drivers/passthrough/pci.c b/xen/drivers/passthrough/pci.c
index b7f87d0..50d337a 100644
--- a/xen/drivers/passthrough/pci.c
+++ b/xen/drivers/passthrough/pci.c
@@ -28,6 +28,7 @@
 #include <xen/keyhandler.h>
 #include <xen/radix-tree.h>
 #include <xen/tasklet.h>
+#include <xsm/xsm.h>
 #ifdef CONFIG_X86
 #include <asm/msi.h>
 #endif
@@ -297,7 +298,7 @@ int pci_add_device(u16 seg, u8 bus, u8 devfn, const struct pci_dev_info *info)
     struct pci_dev *pdev;
     unsigned int slot = PCI_SLOT(devfn), func = PCI_FUNC(devfn);
     const char *pdev_type;
-    int ret = -ENOMEM;
+    int ret;
 
     if (!info)
         pdev_type = "device";
@@ -318,6 +319,12 @@ int pci_add_device(u16 seg, u8 bus, u8 devfn, const struct pci_dev_info *info)
         pdev_type = "device";
     }
 
+    ret = xsm_resource_plug_pci((seg << 16) | (bus << 8) | devfn);
+    if ( ret )
+        return ret;
+
+    ret = -ENOMEM;
+
     spin_lock(&pcidevs_lock);
     pseg = alloc_pseg(seg);
     if ( !pseg )
@@ -426,7 +433,13 @@ int pci_remove_device(u16 seg, u8 bus, u8 devfn)
 {
     struct pci_seg *pseg = get_pseg(seg);
     struct pci_dev *pdev;
-    int ret = -ENODEV;
+    int ret;
+
+    ret = xsm_resource_unplug_pci((seg << 16) | (bus << 8) | devfn);
+    if ( ret )
+        return ret;
+
+    ret = -ENODEV;
 
     if ( !pseg )
         return -ENODEV;
diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
index 43829c7..0c7f248 100644
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -63,6 +63,7 @@ struct xsm_operations {
     int (*getvcpuinfo) (struct domain *d);
     int (*domain_settime) (struct domain *d);
     int (*set_target) (struct domain *d, struct domain *e);
+    int (*domctl) (struct domain *d, int cmd);
     int (*tbufcontrol) (void);
     int (*readconsole) (uint32_t clear);
     int (*sched_id) (void);
@@ -74,7 +75,9 @@ struct xsm_operations {
     int (*getcpuinfo) (void);
     int (*availheap) (void);
     int (*get_pmstat) (void);
+    int (*setpminfo) (void);
     int (*pm_op) (void);
+    int (*do_mca) (void);
 
     int (*evtchn_unbound) (struct domain *d, struct evtchn *chn, domid_t id2);
     int (*evtchn_interdomain) (struct domain *d1, struct evtchn *chn1,
@@ -96,6 +99,8 @@ struct xsm_operations {
     int (*alloc_security_evtchn) (struct evtchn *chn);
     void (*free_security_evtchn) (struct evtchn *chn);
 
+    int (*get_pod_target) (struct domain *d);
+    int (*set_pod_target) (struct domain *d);
     int (*memory_adjust_reservation) (struct domain *d1, struct domain *d2);
     int (*memory_stat_reservation) (struct domain *d1, struct domain *d2);
     int (*memory_pin_page) (struct domain *d, struct page_info *page);
@@ -109,10 +114,24 @@ struct xsm_operations {
     int (*irq_permission) (struct domain *d, int pirq, uint8_t allow);
     int (*iomem_permission) (struct domain *d, uint64_t s, uint64_t e, uint8_t allow);
 
+    int (*get_device_group) (uint32_t machine_bdf);
     int (*test_assign_device) (uint32_t machine_bdf);
     int (*assign_device) (struct domain *d, uint32_t machine_bdf);
     int (*deassign_device) (struct domain *d, uint32_t machine_bdf);
 
+    int (*resource_plug_core) (void);
+    int (*resource_unplug_core) (void);
+    int (*resource_plug_pci) (uint32_t machine_bdf);
+    int (*resource_unplug_pci) (uint32_t machine_bdf);
+    int (*resource_setup_pci) (uint32_t machine_bdf);
+    int (*resource_setup_gsi) (int gsi);
+    int (*resource_setup_misc) (void);
+
+    int (*page_offline)(uint32_t cmd);
+    int (*lockprof)(void);
+    int (*cpupool_op)(void);
+    int (*sched_op)(void);
+
     long (*__do_xsm_op) (XEN_GUEST_HANDLE(xsm_op_t) op);
 
 #ifdef CONFIG_X86
@@ -128,6 +147,8 @@ struct xsm_operations {
     int (*hvm_set_isa_irq_level) (struct domain *d);
     int (*hvm_set_pci_link_route) (struct domain *d);
     int (*hvm_inject_msi) (struct domain *d);
+    int (*mem_event) (struct domain *d);
+    int (*mem_sharing) (struct domain *d);
     int (*apic) (struct domain *d, int cmd);
     int (*xen_settime) (void);
     int (*memtype) (uint32_t access);
@@ -149,6 +170,7 @@ struct xsm_operations {
     int (*add_to_physmap) (struct domain *d1, struct domain *d2);
     int (*sendtrigger) (struct domain *d);
     int (*bind_pt_irq) (struct domain *d, struct xen_domctl_bind_pt_irq *bind);
+    int (*unbind_pt_irq) (struct domain *d);
     int (*pin_mem_cacheattr) (struct domain *d);
     int (*ext_vcpucontext) (struct domain *d, uint32_t cmd);
     int (*vcpuextstate) (struct domain *d, uint32_t cmd);
@@ -236,6 +258,11 @@ static inline int xsm_set_target (struct domain *d, struct domain *e)
     return xsm_call(set_target(d, e));
 }
 
+static inline int xsm_domctl (struct domain *d, int cmd)
+{
+    return xsm_call(domctl(d, cmd));
+}
+
 static inline int xsm_tbufcontrol (void)
 {
     return xsm_call(tbufcontrol());
@@ -291,11 +318,21 @@ static inline int xsm_get_pmstat(void)
     return xsm_call(get_pmstat());
 }
 
+static inline int xsm_setpminfo(void)
+{
+	return xsm_call(setpminfo());
+}
+
 static inline int xsm_pm_op(void)
 {
     return xsm_call(pm_op());
 }
 
+static inline int xsm_do_mca(void)
+{
+    return xsm_call(do_mca());
+}
+
 static inline int xsm_evtchn_unbound (struct domain *d1, struct evtchn *chn,
                                                                     domid_t id2)
 {
@@ -379,6 +416,16 @@ static inline void xsm_free_security_evtchn (struct evtchn *chn)
     (void)xsm_call(free_security_evtchn(chn));
 }
 
+static inline int xsm_get_pod_target (struct domain *d)
+{
+    return xsm_call(get_pod_target(d));
+}
+
+static inline int xsm_set_pod_target (struct domain *d)
+{
+    return xsm_call(set_pod_target(d));
+}
+
 static inline int xsm_memory_adjust_reservation (struct domain *d1, struct
                                                                     domain *d2)
 {
@@ -426,6 +473,11 @@ static inline int xsm_iomem_permission (struct domain *d, uint64_t s, uint64_t e
     return xsm_call(iomem_permission(d, s, e, allow));
 }
 
+static inline int xsm_get_device_group(uint32_t machine_bdf)
+{
+    return xsm_call(get_device_group(machine_bdf));
+}
+
 static inline int xsm_test_assign_device(uint32_t machine_bdf)
 {
     return xsm_call(test_assign_device(machine_bdf));
@@ -441,6 +493,61 @@ static inline int xsm_deassign_device(struct domain *d, uint32_t machine_bdf)
     return xsm_call(deassign_device(d, machine_bdf));
 }
 
+static inline int xsm_resource_plug_pci (uint32_t machine_bdf)
+{
+    return xsm_call(resource_plug_pci(machine_bdf));
+}
+
+static inline int xsm_resource_unplug_pci (uint32_t machine_bdf)
+{
+    return xsm_call(resource_unplug_pci(machine_bdf));
+}
+
+static inline int xsm_resource_plug_core (void)
+{
+    return xsm_call(resource_plug_core());
+}
+
+static inline int xsm_resource_unplug_core (void)
+{
+    return xsm_call(resource_unplug_core());
+}
+
+static inline int xsm_resource_setup_pci (uint32_t machine_bdf)
+{
+    return xsm_call(resource_setup_pci(machine_bdf));
+}
+
+static inline int xsm_resource_setup_gsi (int gsi)
+{
+    return xsm_call(resource_setup_gsi(gsi));
+}
+
+static inline int xsm_resource_setup_misc (void)
+{
+    return xsm_call(resource_setup_misc());
+}
+
+static inline int xsm_page_offline(uint32_t cmd)
+{
+    return xsm_call(page_offline(cmd));
+}
+
+static inline int xsm_lockprof(void)
+{
+    return xsm_call(lockprof());
+}
+
+static inline int xsm_cpupool_op(void)
+{
+    return xsm_call(cpupool_op());
+}
+
+static inline int xsm_sched_op(void)
+{
+    return xsm_call(sched_op());
+}
+
 static inline long __do_xsm_op (XEN_GUEST_HANDLE(xsm_op_t) op)
 {
 #ifdef XSM_ENABLE
@@ -528,6 +635,16 @@ static inline int xsm_hvm_inject_msi (struct domain *d)
     return xsm_call(hvm_inject_msi(d));
 }
 
+static inline int xsm_mem_event (struct domain *d)
+{
+    return xsm_call(mem_event(d));
+}
+
+static inline int xsm_mem_sharing (struct domain *d)
+{
+    return xsm_call(mem_sharing(d));
+}
+
 static inline int xsm_apic (struct domain *d, int cmd)
 {
     return xsm_call(apic(d, cmd));
@@ -626,6 +743,11 @@ static inline int xsm_bind_pt_irq(struct domain *d,
     return xsm_call(bind_pt_irq(d, bind));
 }
 
+static inline int xsm_unbind_pt_irq(struct domain *d)
+{
+    return xsm_call(unbind_pt_irq(d));
+}
+
 static inline int xsm_pin_mem_cacheattr(struct domain *d)
 {
     return xsm_call(pin_mem_cacheattr(d));
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index 04c2f68..efe52bb 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -368,6 +368,16 @@ static int get_mfn_sid(unsigned long mfn, u32 *sid)
     return rc;    
 }
 
+static int flask_get_pod_target(struct domain *d)
+{
+    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN, DOMAIN__GETPODTARGET);
+}
+
+static int flask_set_pod_target(struct domain *d)
+{
+    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN, DOMAIN__SETPODTARGET);
+}
+
 static int flask_memory_adjust_reservation(struct domain *d1, struct domain *d2)
 {
     return domain_has_perm(d1, d2, SECCLASS_MMU, MMU__ADJUST);
@@ -582,6 +592,11 @@ static int flask_set_target(struct domain *d, struct domain *e)
     return domain_has_perm(d, e, SECCLASS_DOMAIN, DOMAIN__SET_TARGET);
 }
 
+static int flask_domctl(struct domain *d, int cmd)
+{
+    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN, DOMAIN__SET_MISC_INFO);
+}
+
 static int flask_tbufcontrol(void)
 {
     return domain_has_xen(current->domain, XEN__TBUFCONTROL);
@@ -635,6 +650,26 @@ static int flask_availheap(void)
     return domain_has_xen(current->domain, XEN__HEAP);
 }
 
+static int flask_get_pmstat(void)
+{
+    return domain_has_xen(current->domain, XEN__PM_OP);
+}
+
+static int flask_setpminfo(void)
+{
+    return domain_has_xen(current->domain, XEN__PM_OP);
+}
+
+static int flask_pm_op(void)
+{
+    return domain_has_xen(current->domain, XEN__PM_OP);
+}
+
+static int flask_do_mca(void)
+{
+    return domain_has_xen(current->domain, XEN__MCA_OP);
+}
+
 static inline u32 resource_to_perm(uint8_t access)
 {
     if ( access )
@@ -727,6 +762,135 @@ static int flask_iomem_permission(struct domain *d, uint64_t start, uint64_t end
     return security_iterate_iomem_sids(start, end, _iomem_has_perm, &data);
 }
 
+static int flask_resource_plug_core(void)
+{
+    struct domain_security_struct *ssec;
+
+    ssec = current->domain->ssid;
+    return avc_has_perm(ssec->sid, SECINITSID_DOMXEN, SECCLASS_RESOURCE, RESOURCE__PLUG, NULL);
+}
+
+static int flask_resource_unplug_core(void)
+{
+    struct domain_security_struct *ssec;
+
+    ssec = current->domain->ssid;
+    return avc_has_perm(ssec->sid, SECINITSID_DOMXEN, SECCLASS_RESOURCE, RESOURCE__UNPLUG, NULL);
+}
+
+static int flask_resource_use_core(void)
+{
+    struct domain_security_struct *ssec;
+
+    ssec = current->domain->ssid;
+    return avc_has_perm(ssec->sid, SECINITSID_DOMXEN, SECCLASS_RESOURCE, RESOURCE__USE, NULL);
+}
+
+static int flask_resource_plug_pci(uint32_t machine_bdf)
+{
+    u32 rsid;
+    int rc = -EPERM;
+    struct avc_audit_data ad;
+    struct domain_security_struct *ssec;
+
+    rc = security_device_sid(machine_bdf, &rsid);
+    if ( rc )
+        return rc;
+
+    AVC_AUDIT_DATA_INIT(&ad, DEV);
+    ad.device = (unsigned long) machine_bdf;
+    ssec = current->domain->ssid;
+    return avc_has_perm(ssec->sid, rsid, SECCLASS_RESOURCE, RESOURCE__PLUG, &ad);
+}
+
+static int flask_resource_unplug_pci(uint32_t machine_bdf)
+{
+    u32 rsid;
+    int rc = -EPERM;
+    struct avc_audit_data ad;
+    struct domain_security_struct *ssec;
+
+    rc = security_device_sid(machine_bdf, &rsid);
+    if ( rc )
+        return rc;
+
+    AVC_AUDIT_DATA_INIT(&ad, DEV);
+    ad.device = (unsigned long) machine_bdf;
+    ssec = current->domain->ssid;
+    return avc_has_perm(ssec->sid, rsid, SECCLASS_RESOURCE, RESOURCE__UNPLUG, &ad);
+}
+
+static int flask_resource_setup_pci(uint32_t machine_bdf)
+{
+    u32 rsid;
+    int rc = -EPERM;
+    struct avc_audit_data ad;
+    struct domain_security_struct *ssec;
+
+    rc = security_device_sid(machine_bdf, &rsid);
+    if ( rc )
+        return rc;
+
+    AVC_AUDIT_DATA_INIT(&ad, DEV);
+    ad.device = (unsigned long) machine_bdf;
+    ssec = current->domain->ssid;
+    return avc_has_perm(ssec->sid, rsid, SECCLASS_RESOURCE, RESOURCE__SETUP, &ad);
+}
+
+static int flask_resource_setup_gsi(int gsi)
+{
+    u32 rsid;
+    int rc = -EPERM;
+    struct avc_audit_data ad;
+    struct domain_security_struct *ssec;
+
+    rc = security_irq_sid(gsi, &rsid);
+    if ( rc )
+        return rc;
+
+    AVC_AUDIT_DATA_INIT(&ad, IRQ);
+    ad.irq = gsi;
+    ssec = current->domain->ssid;
+    return avc_has_perm(ssec->sid, rsid, SECCLASS_RESOURCE, RESOURCE__SETUP, &ad);
+}
+
+static int flask_resource_setup_misc(void)
+{
+    struct domain_security_struct *ssec;
+
+    ssec = current->domain->ssid;
+    return avc_has_perm(ssec->sid, SECINITSID_XEN, SECCLASS_RESOURCE, RESOURCE__SETUP, NULL);
+}
+
+static inline int flask_page_offline(uint32_t cmd)
+{
+    switch (cmd) {
+    case sysctl_page_offline:
+        return flask_resource_unplug_core();
+    case sysctl_page_online:
+        return flask_resource_plug_core();
+    case sysctl_query_page_offline:
+        return flask_resource_use_core();
+    default:
+        return -EPERM;
+    }
+}
+
+static inline int flask_lockprof(void)
+{
+    return domain_has_xen(current->domain, XEN__LOCKPROF);
+}
+
+static inline int flask_cpupool_op(void)
+{
+    return domain_has_xen(current->domain, XEN__CPUPOOL_OP);
+}
+
+static inline int flask_sched_op(void)
+{
+    return domain_has_xen(current->domain, XEN__SCHED_OP);
+}
+
 static int flask_perfcontrol(void)
 {
     return domain_has_xen(current->domain, XEN__PERFCONTROL);
@@ -887,8 +1051,11 @@ static int flask_hvm_param(struct domain *d, unsigned long op)
     case HVMOP_get_param:
         perm = HVM__GETPARAM;
         break;
+    case HVMOP_track_dirty_vram:
+        perm = HVM__TRACKDIRTYVRAM;
+        break;
     default:
-        return -EPERM;
+        perm = HVM__HVMCTL;
     }
 
     return domain_has_perm(current->domain, d, SECCLASS_HVM, perm);
@@ -909,6 +1076,16 @@ static int flask_hvm_set_pci_link_route(struct domain *d)
     return domain_has_perm(current->domain, d, SECCLASS_HVM, HVM__PCIROUTE);
 }
 
+static int flask_mem_event(struct domain *d)
+{
+    return domain_has_perm(current->domain, d, SECCLASS_HVM, HVM__MEM_EVENT);
+}
+
+static int flask_mem_sharing(struct domain *d)
+{
+    return domain_has_perm(current->domain, d, SECCLASS_HVM, HVM__MEM_SHARING);
+}
+
 static int flask_apic(struct domain *d, int cmd)
 {
     u32 perm;
@@ -1088,6 +1265,19 @@ static int flask_sendtrigger(struct domain *d)
     return domain_has_perm(current->domain, d, SECCLASS_DOMAIN, DOMAIN__TRIGGER);
 }
 
+static int flask_get_device_group(uint32_t machine_bdf)
+{
+    u32 rsid;
+    int rc = -EPERM;
+    struct domain_security_struct *ssec = current->domain->ssid;
+
+    rc = security_device_sid(machine_bdf, &rsid);
+    if ( rc )
+        return rc;
+
+    return avc_has_perm(ssec->sid, rsid, SECCLASS_RESOURCE, RESOURCE__STAT_DEVICE, NULL);
+}
+
 static int flask_test_assign_device(uint32_t machine_bdf)
 {
     u32 rsid;
@@ -1174,6 +1364,11 @@ static int flask_bind_pt_irq (struct domain *d, struct xen_domctl_bind_pt_irq *b
     return avc_has_perm(tsec->sid, rsid, SECCLASS_RESOURCE, RESOURCE__USE, &ad);
 }
 
+static int flask_unbind_pt_irq (struct domain *d)
+{
+    return domain_has_perm(current->domain, d, SECCLASS_RESOURCE, RESOURCE__REMOVE);
+}
+
 static int flask_pin_mem_cacheattr (struct domain *d)
 {
     return domain_has_perm(current->domain, d, SECCLASS_HVM, HVM__CACHEATTR);
@@ -1236,6 +1431,7 @@ static struct xsm_operations flask_ops = {
     .getvcpuinfo = flask_getvcpuinfo,
     .domain_settime = flask_domain_settime,
     .set_target = flask_set_target,
+    .domctl = flask_domctl,
     .tbufcontrol = flask_tbufcontrol,
     .readconsole = flask_readconsole,
     .sched_id = flask_sched_id,
@@ -1246,6 +1442,10 @@ static struct xsm_operations flask_ops = {
     .debug_keys = flask_debug_keys,
     .getcpuinfo = flask_getcpuinfo,
     .availheap = flask_availheap,
+    .get_pmstat = flask_get_pmstat,
+    .setpminfo = flask_setpminfo,
+    .pm_op = flask_pm_op,
+    .do_mca = flask_do_mca,
 
     .evtchn_unbound = flask_evtchn_unbound,
     .evtchn_interdomain = flask_evtchn_interdomain,
@@ -1266,6 +1466,8 @@ static struct xsm_operations flask_ops = {
     .alloc_security_evtchn = flask_alloc_security_evtchn,
     .free_security_evtchn = flask_free_security_evtchn,
 
+    .get_pod_target = flask_get_pod_target,
+    .set_pod_target = flask_set_pod_target,
     .memory_adjust_reservation = flask_memory_adjust_reservation,
     .memory_stat_reservation = flask_memory_stat_reservation,
     .memory_pin_page = flask_memory_pin_page,
@@ -1280,6 +1482,19 @@ static struct xsm_operations flask_ops = {
     .irq_permission = flask_irq_permission,
     .iomem_permission = flask_iomem_permission,
 
+    .resource_plug_core = flask_resource_plug_core,
+    .resource_unplug_core = flask_resource_unplug_core,
+    .resource_plug_pci = flask_resource_plug_pci,
+    .resource_unplug_pci = flask_resource_unplug_pci,
+    .resource_setup_pci = flask_resource_setup_pci,
+    .resource_setup_gsi = flask_resource_setup_gsi,
+    .resource_setup_misc = flask_resource_setup_misc,
+
+    .page_offline = flask_page_offline,
+    .lockprof = flask_lockprof,
+    .cpupool_op = flask_cpupool_op,
+    .sched_op = flask_sched_op,
+
     .__do_xsm_op = do_flask_op,
 
 #ifdef CONFIG_X86
@@ -1293,6 +1508,8 @@ static struct xsm_operations flask_ops = {
     .hvm_set_pci_intx_level = flask_hvm_set_pci_intx_level,
     .hvm_set_isa_irq_level = flask_hvm_set_isa_irq_level,
     .hvm_set_pci_link_route = flask_hvm_set_pci_link_route,
+    .mem_event = flask_mem_event,
+    .mem_sharing = flask_mem_sharing,
     .apic = flask_apic,
     .xen_settime = flask_xen_settime,
     .memtype = flask_memtype,
@@ -1310,10 +1527,12 @@ static struct xsm_operations flask_ops = {
     .update_va_mapping = flask_update_va_mapping,
     .add_to_physmap = flask_add_to_physmap,
     .sendtrigger = flask_sendtrigger,
+    .get_device_group = flask_get_device_group,
     .test_assign_device = flask_test_assign_device,
     .assign_device = flask_assign_device,
     .deassign_device = flask_deassign_device,
     .bind_pt_irq = flask_bind_pt_irq,
+    .unbind_pt_irq = flask_unbind_pt_irq,
     .pin_mem_cacheattr = flask_pin_mem_cacheattr,
     .ext_vcpucontext = flask_ext_vcpucontext,
     .vcpuextstate = flask_vcpuextstate,
diff --git a/xen/xsm/flask/include/av_perm_to_string.h b/xen/xsm/flask/include/av_perm_to_string.h
index 56572a7..85cbffc 100644
--- a/xen/xsm/flask/include/av_perm_to_string.h
+++ b/xen/xsm/flask/include/av_perm_to_string.h
@@ -24,6 +24,11 @@
    S_(SECCLASS_XEN, XEN__DEBUG, "debug")
    S_(SECCLASS_XEN, XEN__GETCPUINFO, "getcpuinfo")
    S_(SECCLASS_XEN, XEN__HEAP, "heap")
+   S_(SECCLASS_XEN, XEN__PM_OP, "pm_op")
+   S_(SECCLASS_XEN, XEN__MCA_OP, "mca_op")
+   S_(SECCLASS_XEN, XEN__LOCKPROF, "lockprof")
+   S_(SECCLASS_XEN, XEN__CPUPOOL_OP, "cpupool_op")
+   S_(SECCLASS_XEN, XEN__SCHED_OP, "sched_op")
    S_(SECCLASS_DOMAIN, DOMAIN__SETVCPUCONTEXT, "setvcpucontext")
    S_(SECCLASS_DOMAIN, DOMAIN__PAUSE, "pause")
    S_(SECCLASS_DOMAIN, DOMAIN__UNPAUSE, "unpause")
@@ -52,6 +57,9 @@
    S_(SECCLASS_DOMAIN, DOMAIN__SETEXTVCPUCONTEXT, "setextvcpucontext")
    S_(SECCLASS_DOMAIN, DOMAIN__GETVCPUEXTSTATE, "getvcpuextstate")
    S_(SECCLASS_DOMAIN, DOMAIN__SETVCPUEXTSTATE, "setvcpuextstate")
+   S_(SECCLASS_DOMAIN, DOMAIN__GETPODTARGET, "getpodtarget")
+   S_(SECCLASS_DOMAIN, DOMAIN__SETPODTARGET, "setpodtarget")
+   S_(SECCLASS_DOMAIN, DOMAIN__SET_MISC_INFO, "set_misc_info")
    S_(SECCLASS_HVM, HVM__SETHVMC, "sethvmc")
    S_(SECCLASS_HVM, HVM__GETHVMC, "gethvmc")
    S_(SECCLASS_HVM, HVM__SETPARAM, "setparam")
@@ -62,6 +70,9 @@
    S_(SECCLASS_HVM, HVM__BIND_IRQ, "bind_irq")
    S_(SECCLASS_HVM, HVM__CACHEATTR, "cacheattr")
    S_(SECCLASS_HVM, HVM__TRACKDIRTYVRAM, "trackdirtyvram")
+   S_(SECCLASS_HVM, HVM__HVMCTL, "hvmctl")
+   S_(SECCLASS_HVM, HVM__MEM_EVENT, "mem_event")
+   S_(SECCLASS_HVM, HVM__MEM_SHARING, "mem_sharing")
    S_(SECCLASS_EVENT, EVENT__BIND, "bind")
    S_(SECCLASS_EVENT, EVENT__SEND, "send")
    S_(SECCLASS_EVENT, EVENT__STATUS, "status")
@@ -103,6 +114,9 @@
    S_(SECCLASS_RESOURCE, RESOURCE__STAT_DEVICE, "stat_device")
    S_(SECCLASS_RESOURCE, RESOURCE__ADD_DEVICE, "add_device")
    S_(SECCLASS_RESOURCE, RESOURCE__REMOVE_DEVICE, "remove_device")
+   S_(SECCLASS_RESOURCE, RESOURCE__PLUG, "plug")
+   S_(SECCLASS_RESOURCE, RESOURCE__UNPLUG, "unplug")
+   S_(SECCLASS_RESOURCE, RESOURCE__SETUP, "setup")
    S_(SECCLASS_SECURITY, SECURITY__COMPUTE_AV, "compute_av")
    S_(SECCLASS_SECURITY, SECURITY__COMPUTE_CREATE, "compute_create")
    S_(SECCLASS_SECURITY, SECURITY__COMPUTE_MEMBER, "compute_member")
diff --git a/xen/xsm/flask/include/av_permissions.h b/xen/xsm/flask/include/av_permissions.h
index 67511ad..9e55a86 100644
--- a/xen/xsm/flask/include/av_permissions.h
+++ b/xen/xsm/flask/include/av_permissions.h
@@ -24,6 +24,11 @@
 #define XEN__DEBUG                                0x00400000UL
 #define XEN__GETCPUINFO                           0x00800000UL
 #define XEN__HEAP                                 0x01000000UL
+#define XEN__PM_OP                                0x02000000UL
+#define XEN__MCA_OP                               0x04000000UL
+#define XEN__LOCKPROF                             0x08000000UL
+#define XEN__CPUPOOL_OP                           0x10000000UL
+#define XEN__SCHED_OP                             0x20000000UL
 
 #define DOMAIN__SETVCPUCONTEXT                    0x00000001UL
 #define DOMAIN__PAUSE                             0x00000002UL
@@ -53,6 +58,9 @@
 #define DOMAIN__SETEXTVCPUCONTEXT                 0x02000000UL
 #define DOMAIN__GETVCPUEXTSTATE                   0x04000000UL
 #define DOMAIN__SETVCPUEXTSTATE                   0x08000000UL
+#define DOMAIN__GETPODTARGET                      0x10000000UL
+#define DOMAIN__SETPODTARGET                      0x20000000UL
+#define DOMAIN__SET_MISC_INFO                     0x40000000UL
 
 #define HVM__SETHVMC                              0x00000001UL
 #define HVM__GETHVMC                              0x00000002UL
@@ -64,6 +72,9 @@
 #define HVM__BIND_IRQ                             0x00000080UL
 #define HVM__CACHEATTR                            0x00000100UL
 #define HVM__TRACKDIRTYVRAM                       0x00000200UL
+#define HVM__HVMCTL                               0x00000400UL
+#define HVM__MEM_EVENT                            0x00000800UL
+#define HVM__MEM_SHARING                          0x00001000UL
 
 #define EVENT__BIND                               0x00000001UL
 #define EVENT__SEND                               0x00000002UL
@@ -110,6 +121,9 @@
 #define RESOURCE__STAT_DEVICE                     0x00000200UL
 #define RESOURCE__ADD_DEVICE                      0x00000400UL
 #define RESOURCE__REMOVE_DEVICE                   0x00000800UL
+#define RESOURCE__PLUG                            0x00001000UL
+#define RESOURCE__UNPLUG                          0x00002000UL
+#define RESOURCE__SETUP                           0x00004000UL
 
 #define SECURITY__COMPUTE_AV                      0x00000001UL
 #define SECURITY__COMPUTE_CREATE                  0x00000002UL
-- 
1.7.7.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 20:39:58 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 20:39:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaZ8U-0003Fn-HG; Tue, 13 Dec 2011 20:39:38 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RaZ8S-0003CC-Gj
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 20:39:36 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-10.tower-182.messagelabs.com!1323808721!7125560!1
X-Originating-IP: [63.239.65.40]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31134 invoked from network); 13 Dec 2011 20:38:41 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-10.tower-182.messagelabs.com with SMTP;
	13 Dec 2011 20:38:41 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea02.nsa.gov (8.12.10/8.12.10) with ESMTP id
	pBDKcexP012688; Tue, 13 Dec 2011 20:38:40 GMT
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id pBDKcdo3017251; 
	Tue, 13 Dec 2011 15:38:40 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com, Keir Fraser <keir@xen.org>
Date: Tue, 13 Dec 2011 15:38:56 -0500
Message-Id: <1323808737-29125-8-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.4
In-Reply-To: <1323808737-29125-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1323808737-29125-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 7/8] xsm: add checks on PCI configuration access
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

PCI configuration access is allowed to any privileged domain regardless
of I/O port access restrictions; add XSM hooks for these accesses.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 xen/arch/x86/traps.c              |   26 ++++++++++++++++++++++----
 xen/arch/x86/x86_64/mmconfig_64.c |   13 +++++++++++++
 xen/include/xsm/xsm.h             |    6 ++++++
 xen/xsm/dummy.c                   |    8 ++++++++
 xen/xsm/flask/hooks.c             |   24 ++++++++++++++++++++++++
 5 files changed, 73 insertions(+), 4 deletions(-)

diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
index 7f38ddc..2d585c8 100644
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -72,6 +72,7 @@
 #include <asm/mc146818rtc.h>
 #include <asm/hpet.h>
 #include <public/arch-x86/cpuid.h>
+#include <xsm/xsm.h>
 
 /*
  * opt_nmi: one of 'ignore', 'dom0', or 'fatal'.
@@ -1680,6 +1681,21 @@ static int admin_io_okay(
     return ioports_access_permitted(v->domain, port, port + bytes - 1);
 }
 
+static int pci_cfg_ok(struct domain *d, int write, int size)
+{
+    uint32_t machine_bdf;
+    uint16_t start, end;
+    if (!IS_PRIV(d))
+        return 0;
+
+    machine_bdf = (d->arch.pci_cf8 >> 8) & 0xFFFF;
+    start = d->arch.pci_cf8 & 0xFF;
+    end = start + size - 1;
+    if (xsm_pci_config_permission(d, machine_bdf, start, end, write))
+        return 0;
+    return 1;
+}
+
 static uint32_t guest_io_read(
     unsigned int port, unsigned int bytes,
     struct vcpu *v, struct cpu_user_regs *regs)
@@ -1726,12 +1742,13 @@ static uint32_t guest_io_read(
             size = 4;
             sub_data = v->domain->arch.pci_cf8;
         }
-        else if ( ((port & 0xfffc) == 0xcfc) && IS_PRIV(v->domain) )
+        else if ( (port & 0xfffc) == 0xcfc )
         {
             size = min(bytes, 4 - (port & 3));
             if ( size == 3 )
                 size = 2;
-            sub_data = pci_conf_read(v->domain->arch.pci_cf8, port & 3, size);
+            if ( pci_cfg_ok(v->domain, 0, size) )
+                sub_data = pci_conf_read(v->domain->arch.pci_cf8, port & 3, size);
         }
 
         if ( size == 4 )
@@ -1798,12 +1815,13 @@ static void guest_io_write(
             size = 4;
             v->domain->arch.pci_cf8 = data;
         }
-        else if ( ((port & 0xfffc) == 0xcfc) && IS_PRIV(v->domain) )
+        else if ( (port & 0xfffc) == 0xcfc )
         {
             size = min(bytes, 4 - (port & 3));
             if ( size == 3 )
                 size = 2;
-            pci_conf_write(v->domain->arch.pci_cf8, port & 3, size, data);
+            if ( pci_cfg_ok(v->domain, 1, size) )
+                pci_conf_write(v->domain->arch.pci_cf8, port & 3, size, data);
         }
 
         if ( size == 4 )
diff --git a/xen/arch/x86/x86_64/mmconfig_64.c b/xen/arch/x86/x86_64/mmconfig_64.c
index 16d432e..f2e7fed 100644
--- a/xen/arch/x86/x86_64/mmconfig_64.c
+++ b/xen/arch/x86/x86_64/mmconfig_64.c
@@ -14,6 +14,7 @@
 #include <xen/xmalloc.h>
 #include <xen/pci.h>
 #include <xen/pci_regs.h>
+#include <xsm/xsm.h>
 
 #include "mmconfig.h"
 
@@ -58,6 +59,7 @@ int pci_mmcfg_read(unsigned int seg, unsigned int bus,
               unsigned int devfn, int reg, int len, u32 *value)
 {
     char __iomem *addr;
+    uint32_t mbdf;
 
     /* Why do we have this when nobody checks it. How about a BUG()!? -AK */
     if (unlikely((bus > 255) || (devfn > 255) || (reg > 4095))) {
@@ -65,6 +67,12 @@ err:        *value = -1;
         return -EINVAL;
     }
 
+    mbdf = (seg << 16) | (bus << 8) | devfn;
+    if (xsm_pci_config_permission(current->domain, mbdf, reg, reg + len - 1, 0)) {
+        *value = -1;
+        return -EPERM;
+    }
+
     addr = pci_dev_base(seg, bus, devfn);
     if (!addr)
         goto err;
@@ -88,11 +96,16 @@ int pci_mmcfg_write(unsigned int seg, unsigned int bus,
                unsigned int devfn, int reg, int len, u32 value)
 {
     char __iomem *addr;
+    uint32_t mbdf;
 
     /* Why do we have this when nobody checks it. How about a BUG()!? -AK */
     if (unlikely((bus > 255) || (devfn > 255) || (reg > 4095)))
         return -EINVAL;
 
+    mbdf = (seg << 16) | (bus << 8) | devfn;
+    if (xsm_pci_config_permission(current->domain, mbdf, reg, reg + len - 1, 1))
+        return -EPERM;
+
     addr = pci_dev_base(seg, bus, devfn);
     if (!addr)
         return -EINVAL;
diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
index 0c7f248..df6cec2 100644
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -113,6 +113,7 @@ struct xsm_operations {
     int (*schedop_shutdown) (struct domain *d1, struct domain *d2);
     int (*irq_permission) (struct domain *d, int pirq, uint8_t allow);
     int (*iomem_permission) (struct domain *d, uint64_t s, uint64_t e, uint8_t allow);
+    int (*pci_config_permission) (struct domain *d, uint32_t machine_bdf, uint16_t start, uint16_t end, uint8_t access);
 
     int (*get_device_group) (uint32_t machine_bdf);
     int (*test_assign_device) (uint32_t machine_bdf);
@@ -473,6 +474,11 @@ static inline int xsm_iomem_permission (struct domain *d, uint64_t s, uint64_t e
     return xsm_call(iomem_permission(d, s, e, allow));
 }
 
+static inline int xsm_pci_config_permission (struct domain *d, uint32_t machine_bdf, uint16_t start, uint16_t end, uint8_t access)
+{
+    return xsm_call(pci_config_permission(d, machine_bdf, start, end, access));
+}
+
 static inline int xsm_get_device_group(uint32_t machine_bdf)
 {
     return xsm_call(get_device_group(machine_bdf));
diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c
index a4accb8..4bbfbff 100644
--- a/xen/xsm/dummy.c
+++ b/xen/xsm/dummy.c
@@ -369,6 +369,13 @@ static int dummy_iomem_permission (struct domain *d, uint64_t s, uint64_t e, uin
     return 0;
 }
 
+static int dummy_pci_config_permission (struct domain *d, uint32_t machine_bdf,
+                                        uint16_t start, uint16_t end,
+                                        uint8_t access)
+{
+    return 0;
+}
+
 #ifdef CONFIG_X86
 static int dummy_shadow_control (struct domain *d, uint32_t op)
 {
@@ -631,6 +638,7 @@ void xsm_fixup_ops (struct xsm_operations *ops)
 
     set_to_dummy_if_null(ops, irq_permission);
     set_to_dummy_if_null(ops, iomem_permission);
+    set_to_dummy_if_null(ops, pci_config_permission);
 
     set_to_dummy_if_null(ops, test_assign_device);
     set_to_dummy_if_null(ops, assign_device);
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index efe52bb..0d35767 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -762,6 +762,29 @@ static int flask_iomem_permission(struct domain *d, uint64_t start, uint64_t end
     return security_iterate_iomem_sids(start, end, _iomem_has_perm, &data);
 }
 
+static int flask_pci_config_permission(struct domain *d, uint32_t machine_bdf, uint16_t start, uint16_t end, uint8_t access)
+{
+    u32 rsid;
+    int rc = -EPERM;
+    struct avc_audit_data ad;
+    struct domain_security_struct *ssec;
+    u32 perm = RESOURCE__USE;
+
+    rc = security_device_sid(machine_bdf, &rsid);
+    if ( rc )
+        return rc;
+
+    /* Writes to the BARs count as setup */
+    if ( access && (end >= 0x10 && start < 0x28) )
+        perm = RESOURCE__SETUP;
+
+    AVC_AUDIT_DATA_INIT(&ad, DEV);
+    ad.device = (unsigned long) machine_bdf;
+    ssec = d->ssid;
+    return avc_has_perm(ssec->sid, rsid, SECCLASS_RESOURCE, perm, &ad);
+
+}
+
 static int flask_resource_plug_core(void)
 {
     struct domain_security_struct *ssec;
@@ -1481,6 +1504,7 @@ static struct xsm_operations flask_ops = {
 
     .irq_permission = flask_irq_permission,
     .iomem_permission = flask_iomem_permission,
+    .pci_config_permission = flask_pci_config_permission,
 
     .resource_plug_core = flask_resource_plug_core,
     .resource_unplug_core = flask_resource_unplug_core,
-- 
1.7.7.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 20:39:58 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 20:39:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaZ8S-0003Dn-S9; Tue, 13 Dec 2011 20:39:36 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RaZ8R-0003C4-P4
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 20:39:36 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-5.tower-182.messagelabs.com!1323808720!7149482!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16228 invoked from network); 13 Dec 2011 20:38:41 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-5.tower-182.messagelabs.com with SMTP;
	13 Dec 2011 20:38:41 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea01.nsa.gov (8.12.10/8.12.10) with ESMTP id
	pBDKcdRx010714; Tue, 13 Dec 2011 20:38:39 GMT
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id pBDKcdnu017251; 
	Tue, 13 Dec 2011 15:38:39 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com, Keir Fraser <keir@xen.org>
Date: Tue, 13 Dec 2011 15:38:49 -0500
Message-Id: <1323808737-29125-1-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.4
Subject: [Xen-devel] [PATCH 0/8] New XSM hooks and updates
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Since the introduction of the FLASK security module, new hypercalls and
access paths have been added to Xen without corresponding XSM hooks.
This series adds access checks on these operations and also fixes some
bugs in error paths.

[PATCH 1/8] xsm/flask: Add missing unlock on error path
[PATCH 2/8] xsm/flask: report memory and IO ranges in audit messages
[PATCH 3/8] xsm: only log dummy override if not setting up
[PATCH 4/8] xsm: add remote_remap permission
[PATCH 5/8] xsm: Add missing access checks
[PATCH 6/8] xsm: fix up dummy ops
[PATCH 7/8] xsm: add checks on PCI configuration access
[PATCH 8/8] xl.pod.1: improve documentation of FLASK commands

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 20:39:58 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 20:39:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaZ8U-0003Fn-HG; Tue, 13 Dec 2011 20:39:38 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RaZ8S-0003CC-Gj
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 20:39:36 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-10.tower-182.messagelabs.com!1323808721!7125560!1
X-Originating-IP: [63.239.65.40]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31134 invoked from network); 13 Dec 2011 20:38:41 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-10.tower-182.messagelabs.com with SMTP;
	13 Dec 2011 20:38:41 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea02.nsa.gov (8.12.10/8.12.10) with ESMTP id
	pBDKcexP012688; Tue, 13 Dec 2011 20:38:40 GMT
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id pBDKcdo3017251; 
	Tue, 13 Dec 2011 15:38:40 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com, Keir Fraser <keir@xen.org>
Date: Tue, 13 Dec 2011 15:38:56 -0500
Message-Id: <1323808737-29125-8-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.4
In-Reply-To: <1323808737-29125-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1323808737-29125-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 7/8] xsm: add checks on PCI configuration access
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

PCI configuration access is allowed to any privileged domain regardless
of I/O port access restrictions; add XSM hooks for these accesses.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 xen/arch/x86/traps.c              |   26 ++++++++++++++++++++++----
 xen/arch/x86/x86_64/mmconfig_64.c |   13 +++++++++++++
 xen/include/xsm/xsm.h             |    6 ++++++
 xen/xsm/dummy.c                   |    8 ++++++++
 xen/xsm/flask/hooks.c             |   24 ++++++++++++++++++++++++
 5 files changed, 73 insertions(+), 4 deletions(-)

diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
index 7f38ddc..2d585c8 100644
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -72,6 +72,7 @@
 #include <asm/mc146818rtc.h>
 #include <asm/hpet.h>
 #include <public/arch-x86/cpuid.h>
+#include <xsm/xsm.h>
 
 /*
  * opt_nmi: one of 'ignore', 'dom0', or 'fatal'.
@@ -1680,6 +1681,21 @@ static int admin_io_okay(
     return ioports_access_permitted(v->domain, port, port + bytes - 1);
 }
 
+static int pci_cfg_ok(struct domain *d, int write, int size)
+{
+    uint32_t machine_bdf;
+    uint16_t start, end;
+    if (!IS_PRIV(d))
+        return 0;
+
+    machine_bdf = (d->arch.pci_cf8 >> 8) & 0xFFFF;
+    start = d->arch.pci_cf8 & 0xFF;
+    end = start + size - 1;
+    if (xsm_pci_config_permission(d, machine_bdf, start, end, write))
+        return 0;
+    return 1;
+}
+
 static uint32_t guest_io_read(
     unsigned int port, unsigned int bytes,
     struct vcpu *v, struct cpu_user_regs *regs)
@@ -1726,12 +1742,13 @@ static uint32_t guest_io_read(
             size = 4;
             sub_data = v->domain->arch.pci_cf8;
         }
-        else if ( ((port & 0xfffc) == 0xcfc) && IS_PRIV(v->domain) )
+        else if ( (port & 0xfffc) == 0xcfc )
         {
             size = min(bytes, 4 - (port & 3));
             if ( size == 3 )
                 size = 2;
-            sub_data = pci_conf_read(v->domain->arch.pci_cf8, port & 3, size);
+            if ( pci_cfg_ok(v->domain, 0, size) )
+                sub_data = pci_conf_read(v->domain->arch.pci_cf8, port & 3, size);
         }
 
         if ( size == 4 )
@@ -1798,12 +1815,13 @@ static void guest_io_write(
             size = 4;
             v->domain->arch.pci_cf8 = data;
         }
-        else if ( ((port & 0xfffc) == 0xcfc) && IS_PRIV(v->domain) )
+        else if ( (port & 0xfffc) == 0xcfc )
         {
             size = min(bytes, 4 - (port & 3));
             if ( size == 3 )
                 size = 2;
-            pci_conf_write(v->domain->arch.pci_cf8, port & 3, size, data);
+            if ( pci_cfg_ok(v->domain, 1, size) )
+                pci_conf_write(v->domain->arch.pci_cf8, port & 3, size, data);
         }
 
         if ( size == 4 )
diff --git a/xen/arch/x86/x86_64/mmconfig_64.c b/xen/arch/x86/x86_64/mmconfig_64.c
index 16d432e..f2e7fed 100644
--- a/xen/arch/x86/x86_64/mmconfig_64.c
+++ b/xen/arch/x86/x86_64/mmconfig_64.c
@@ -14,6 +14,7 @@
 #include <xen/xmalloc.h>
 #include <xen/pci.h>
 #include <xen/pci_regs.h>
+#include <xsm/xsm.h>
 
 #include "mmconfig.h"
 
@@ -58,6 +59,7 @@ int pci_mmcfg_read(unsigned int seg, unsigned int bus,
               unsigned int devfn, int reg, int len, u32 *value)
 {
     char __iomem *addr;
+    uint32_t mbdf;
 
     /* Why do we have this when nobody checks it. How about a BUG()!? -AK */
     if (unlikely((bus > 255) || (devfn > 255) || (reg > 4095))) {
@@ -65,6 +67,12 @@ err:        *value = -1;
         return -EINVAL;
     }
 
+    mbdf = (seg << 16) | (bus << 8) | devfn;
+    if (xsm_pci_config_permission(current->domain, mbdf, reg, reg + len - 1, 0)) {
+        *value = -1;
+        return -EPERM;
+    }
+
     addr = pci_dev_base(seg, bus, devfn);
     if (!addr)
         goto err;
@@ -88,11 +96,16 @@ int pci_mmcfg_write(unsigned int seg, unsigned int bus,
                unsigned int devfn, int reg, int len, u32 value)
 {
     char __iomem *addr;
+    uint32_t mbdf;
 
     /* Why do we have this when nobody checks it. How about a BUG()!? -AK */
     if (unlikely((bus > 255) || (devfn > 255) || (reg > 4095)))
         return -EINVAL;
 
+    mbdf = (seg << 16) | (bus << 8) | devfn;
+    if (xsm_pci_config_permission(current->domain, mbdf, reg, reg + len - 1, 1))
+        return -EPERM;
+
     addr = pci_dev_base(seg, bus, devfn);
     if (!addr)
         return -EINVAL;
diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
index 0c7f248..df6cec2 100644
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -113,6 +113,7 @@ struct xsm_operations {
     int (*schedop_shutdown) (struct domain *d1, struct domain *d2);
     int (*irq_permission) (struct domain *d, int pirq, uint8_t allow);
     int (*iomem_permission) (struct domain *d, uint64_t s, uint64_t e, uint8_t allow);
+    int (*pci_config_permission) (struct domain *d, uint32_t machine_bdf, uint16_t start, uint16_t end, uint8_t access);
 
     int (*get_device_group) (uint32_t machine_bdf);
     int (*test_assign_device) (uint32_t machine_bdf);
@@ -473,6 +474,11 @@ static inline int xsm_iomem_permission (struct domain *d, uint64_t s, uint64_t e
     return xsm_call(iomem_permission(d, s, e, allow));
 }
 
+static inline int xsm_pci_config_permission (struct domain *d, uint32_t machine_bdf, uint16_t start, uint16_t end, uint8_t access)
+{
+    return xsm_call(pci_config_permission(d, machine_bdf, start, end, access));
+}
+
 static inline int xsm_get_device_group(uint32_t machine_bdf)
 {
     return xsm_call(get_device_group(machine_bdf));
diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c
index a4accb8..4bbfbff 100644
--- a/xen/xsm/dummy.c
+++ b/xen/xsm/dummy.c
@@ -369,6 +369,13 @@ static int dummy_iomem_permission (struct domain *d, uint64_t s, uint64_t e, uin
     return 0;
 }
 
+static int dummy_pci_config_permission (struct domain *d, uint32_t machine_bdf,
+                                        uint16_t start, uint16_t end,
+                                        uint8_t access)
+{
+    return 0;
+}
+
 #ifdef CONFIG_X86
 static int dummy_shadow_control (struct domain *d, uint32_t op)
 {
@@ -631,6 +638,7 @@ void xsm_fixup_ops (struct xsm_operations *ops)
 
     set_to_dummy_if_null(ops, irq_permission);
     set_to_dummy_if_null(ops, iomem_permission);
+    set_to_dummy_if_null(ops, pci_config_permission);
 
     set_to_dummy_if_null(ops, test_assign_device);
     set_to_dummy_if_null(ops, assign_device);
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index efe52bb..0d35767 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -762,6 +762,29 @@ static int flask_iomem_permission(struct domain *d, uint64_t start, uint64_t end
     return security_iterate_iomem_sids(start, end, _iomem_has_perm, &data);
 }
 
+static int flask_pci_config_permission(struct domain *d, uint32_t machine_bdf, uint16_t start, uint16_t end, uint8_t access)
+{
+    u32 rsid;
+    int rc = -EPERM;
+    struct avc_audit_data ad;
+    struct domain_security_struct *ssec;
+    u32 perm = RESOURCE__USE;
+
+    rc = security_device_sid(machine_bdf, &rsid);
+    if ( rc )
+        return rc;
+
+    /* Writes to the BARs count as setup */
+    if ( access && (end >= 0x10 && start < 0x28) )
+        perm = RESOURCE__SETUP;
+
+    AVC_AUDIT_DATA_INIT(&ad, DEV);
+    ad.device = (unsigned long) machine_bdf;
+    ssec = d->ssid;
+    return avc_has_perm(ssec->sid, rsid, SECCLASS_RESOURCE, perm, &ad);
+
+}
+
 static int flask_resource_plug_core(void)
 {
     struct domain_security_struct *ssec;
@@ -1481,6 +1504,7 @@ static struct xsm_operations flask_ops = {
 
     .irq_permission = flask_irq_permission,
     .iomem_permission = flask_iomem_permission,
+    .pci_config_permission = flask_pci_config_permission,
 
     .resource_plug_core = flask_resource_plug_core,
     .resource_unplug_core = flask_resource_unplug_core,
-- 
1.7.7.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 21:00:25 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 21: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.xensource.com>)
	id 1RaZSJ-0005s1-BN; Tue, 13 Dec 2011 21:00:07 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <george.shuklin@gmail.com>) id 1RaZSH-0005pz-Nj
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 21:00:05 +0000
X-Env-Sender: george.shuklin@gmail.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1323809951!7151035!1
X-Originating-IP: [209.85.215.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31018 invoked from network); 13 Dec 2011 20:59:11 -0000
Received: from mail-ey0-f171.google.com (HELO mail-ey0-f171.google.com)
	(209.85.215.171)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 20:59:11 -0000
Received: by eaa1 with SMTP id 1so324620eaa.30
	for <xen-devel@lists.xensource.com>;
	Tue, 13 Dec 2011 12:59:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=message-id:date:from:user-agent:mime-version:to:cc:subject
	:references:in-reply-to:content-type:content-transfer-encoding;
	bh=l9XULOWMD7rsUQOoME8aEKNH46Nvji0xcTE1LFQgRso=;
	b=gfy+LoBg59Yph2wu2EsZPZL1VBqlM4dcif+Vo4HwLlph4d8hvmi8sETQe2OZ6y3sep
	OVib/y2iYhP2UyT0FuGFrPBZ0Ly77Lb+4kzR39cpEIKVeMcH7WRhT+Bb6LoMM6WJ/6s1
	oZeFmeAUNxhnZSsqhXS5JFn4VxT9tpQ+ksAjg=
Received: by 10.204.151.209 with SMTP id d17mr8595147bkw.52.1323809950925;
	Tue, 13 Dec 2011 12:59:10 -0800 (PST)
Received: from [192.168.0.220] (desunote.ru. [95.161.2.76])
	by mx.google.com with ESMTPS id jf4sm612304bkc.5.2011.12.13.12.59.08
	(version=SSLv3 cipher=OTHER); Tue, 13 Dec 2011 12:59:09 -0800 (PST)
Message-ID: <4EE7BC9B.6040003@gmail.com>
Date: Wed, 14 Dec 2011 00:59:07 +0400
From: George Shuklin <george.shuklin@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:9.0) Gecko/20111209 Thunderbird/9.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <4EE675A8.3030609@niemail.de>	<4EE71663.5040308@gmail.com>
	<CAJeBh4sxdNTxM_oLFAuA6Mw75=LaYysrpS5b8NsZMbkf_swNVw@mail.gmail.com>
	<4EE72A94.6040904@gmail.com> <4EE75080.1000909@citrix.com>
	<1323783428.20077.298.camel@zakaz.uk.xensource.com>
In-Reply-To: <1323783428.20077.298.camel@zakaz.uk.xensource.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	David Vrabel <david.vrabel@citrix.com>,
	"sandr8@gmail.com" <sandr8@gmail.com>
Subject: Re: [Xen-devel] a ton of kernel issues
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 13.12.2011 17:37, Ian Campbell wrote:
>> This should work if memory hotplug is enabled.
>>
>> It is also supported without memory hotplug but this requires that the
>> tools supply a suitable memory map that covers the largest
>> memory-static-max limit you wish to support.  I'm not sure if the tools
>> can do this yet.
> With xl this should work using the "maxmem" option. (xm probably uses
> the same name)
>
I'm not sure what maxmem do, but I can say, this option does not allow 
to go beyond initial boot memory for pv_ops kernels and beyond 
static-max memory for -xen kernel.

I tested it with following python script (under xcp, with shutdowned 
squeezed to be sure not get 'reballanced'):

xc.domain_setmaxmem(domid,memory)
xs.write("","/local/domain/%i/memory/dynamic-min"%domid,str(memory*1024))
xs.write("","/local/domain/%i/memory/dynamic-max"%domid,str(memory*1024))
xs.write("","/local/domain/%i/memory/static-max"%domid,str(memory*1024))
xs.write("","/local/domain/%i/memory/target"%domid,str(memory*1024))

It works fine within noted ranges, but simply ignores any request higher 
them.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 21:00:25 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 21: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.xensource.com>)
	id 1RaZSJ-0005s1-BN; Tue, 13 Dec 2011 21:00:07 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <george.shuklin@gmail.com>) id 1RaZSH-0005pz-Nj
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 21:00:05 +0000
X-Env-Sender: george.shuklin@gmail.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1323809951!7151035!1
X-Originating-IP: [209.85.215.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31018 invoked from network); 13 Dec 2011 20:59:11 -0000
Received: from mail-ey0-f171.google.com (HELO mail-ey0-f171.google.com)
	(209.85.215.171)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 20:59:11 -0000
Received: by eaa1 with SMTP id 1so324620eaa.30
	for <xen-devel@lists.xensource.com>;
	Tue, 13 Dec 2011 12:59:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=message-id:date:from:user-agent:mime-version:to:cc:subject
	:references:in-reply-to:content-type:content-transfer-encoding;
	bh=l9XULOWMD7rsUQOoME8aEKNH46Nvji0xcTE1LFQgRso=;
	b=gfy+LoBg59Yph2wu2EsZPZL1VBqlM4dcif+Vo4HwLlph4d8hvmi8sETQe2OZ6y3sep
	OVib/y2iYhP2UyT0FuGFrPBZ0Ly77Lb+4kzR39cpEIKVeMcH7WRhT+Bb6LoMM6WJ/6s1
	oZeFmeAUNxhnZSsqhXS5JFn4VxT9tpQ+ksAjg=
Received: by 10.204.151.209 with SMTP id d17mr8595147bkw.52.1323809950925;
	Tue, 13 Dec 2011 12:59:10 -0800 (PST)
Received: from [192.168.0.220] (desunote.ru. [95.161.2.76])
	by mx.google.com with ESMTPS id jf4sm612304bkc.5.2011.12.13.12.59.08
	(version=SSLv3 cipher=OTHER); Tue, 13 Dec 2011 12:59:09 -0800 (PST)
Message-ID: <4EE7BC9B.6040003@gmail.com>
Date: Wed, 14 Dec 2011 00:59:07 +0400
From: George Shuklin <george.shuklin@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:9.0) Gecko/20111209 Thunderbird/9.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <4EE675A8.3030609@niemail.de>	<4EE71663.5040308@gmail.com>
	<CAJeBh4sxdNTxM_oLFAuA6Mw75=LaYysrpS5b8NsZMbkf_swNVw@mail.gmail.com>
	<4EE72A94.6040904@gmail.com> <4EE75080.1000909@citrix.com>
	<1323783428.20077.298.camel@zakaz.uk.xensource.com>
In-Reply-To: <1323783428.20077.298.camel@zakaz.uk.xensource.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	David Vrabel <david.vrabel@citrix.com>,
	"sandr8@gmail.com" <sandr8@gmail.com>
Subject: Re: [Xen-devel] a ton of kernel issues
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 13.12.2011 17:37, Ian Campbell wrote:
>> This should work if memory hotplug is enabled.
>>
>> It is also supported without memory hotplug but this requires that the
>> tools supply a suitable memory map that covers the largest
>> memory-static-max limit you wish to support.  I'm not sure if the tools
>> can do this yet.
> With xl this should work using the "maxmem" option. (xm probably uses
> the same name)
>
I'm not sure what maxmem do, but I can say, this option does not allow 
to go beyond initial boot memory for pv_ops kernels and beyond 
static-max memory for -xen kernel.

I tested it with following python script (under xcp, with shutdowned 
squeezed to be sure not get 'reballanced'):

xc.domain_setmaxmem(domid,memory)
xs.write("","/local/domain/%i/memory/dynamic-min"%domid,str(memory*1024))
xs.write("","/local/domain/%i/memory/dynamic-max"%domid,str(memory*1024))
xs.write("","/local/domain/%i/memory/static-max"%domid,str(memory*1024))
xs.write("","/local/domain/%i/memory/target"%domid,str(memory*1024))

It works fine within noted ranges, but simply ignores any request higher 
them.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 21:05:10 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 21: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.xensource.com>)
	id 1RaZWz-00066y-2e; Tue, 13 Dec 2011 21:04:57 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <sythrar@gmail.com>) id 1RaZWx-00066n-Bf
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 21:04:55 +0000
X-Env-Sender: sythrar@gmail.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1323810239!7317302!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6286 invoked from network); 13 Dec 2011 21:04:00 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-6.tower-216.messagelabs.com with AES256-SHA encrypted SMTP;
	13 Dec 2011 21:04:00 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <sythrar@gmail.com>) id 1RaZW3-0002FC-3W
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 13:03:59 -0800
Date: Tue, 13 Dec 2011 13:03:59 -0800 (PST)
From: Sythrar <sythrar@gmail.com>
To: xen-devel@lists.xensource.com
Message-ID: <1323810239102-5072769.post@n5.nabble.com>
In-Reply-To: <1323520193389-5064245.post@n5.nabble.com>
References: <20110923172115.GI12984@reaktio.net>
	<1318672856439-4904945.post@n5.nabble.com>
	<1319630071722-4939528.post@n5.nabble.com>
	<1319636130.20499.YahooMailNeo@web29808.mail.ird.yahoo.com>
	<1319695116310-4942047.post@n5.nabble.com>
	<1319710499.206.YahooMailNeo@web29804.mail.ird.yahoo.com>
	<1323123990448-5050354.post@n5.nabble.com>
	<1323170568.90631.YahooMailNeo@web29813.mail.ird.yahoo.com>
	<1323504740494-5063848.post@n5.nabble.com>
	<1323520193389-5064245.post@n5.nabble.com>
MIME-Version: 1.0
Subject: Re: [Xen-devel] Re : Re : Re : Re : Re : Re : Re : Re: Patches for
 VGA-Passthrough XEN 4.2 unstable
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

n4rC0t1C, test for me is to run domU with vnc and tell me how was the
performance. Thank you very much.
My dream is to play games on linux without wine.
sorry my english

--
View this message in context: http://xen.1045712.n5.nabble.com/Patches-for-VGA-Passthrough-XEN-4-2-unstable-tp4406265p5072769.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 21:05:10 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 21: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.xensource.com>)
	id 1RaZWz-00066y-2e; Tue, 13 Dec 2011 21:04:57 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <sythrar@gmail.com>) id 1RaZWx-00066n-Bf
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 21:04:55 +0000
X-Env-Sender: sythrar@gmail.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1323810239!7317302!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6286 invoked from network); 13 Dec 2011 21:04:00 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-6.tower-216.messagelabs.com with AES256-SHA encrypted SMTP;
	13 Dec 2011 21:04:00 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <sythrar@gmail.com>) id 1RaZW3-0002FC-3W
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 13:03:59 -0800
Date: Tue, 13 Dec 2011 13:03:59 -0800 (PST)
From: Sythrar <sythrar@gmail.com>
To: xen-devel@lists.xensource.com
Message-ID: <1323810239102-5072769.post@n5.nabble.com>
In-Reply-To: <1323520193389-5064245.post@n5.nabble.com>
References: <20110923172115.GI12984@reaktio.net>
	<1318672856439-4904945.post@n5.nabble.com>
	<1319630071722-4939528.post@n5.nabble.com>
	<1319636130.20499.YahooMailNeo@web29808.mail.ird.yahoo.com>
	<1319695116310-4942047.post@n5.nabble.com>
	<1319710499.206.YahooMailNeo@web29804.mail.ird.yahoo.com>
	<1323123990448-5050354.post@n5.nabble.com>
	<1323170568.90631.YahooMailNeo@web29813.mail.ird.yahoo.com>
	<1323504740494-5063848.post@n5.nabble.com>
	<1323520193389-5064245.post@n5.nabble.com>
MIME-Version: 1.0
Subject: Re: [Xen-devel] Re : Re : Re : Re : Re : Re : Re : Re: Patches for
 VGA-Passthrough XEN 4.2 unstable
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

n4rC0t1C, test for me is to run domU with vnc and tell me how was the
performance. Thank you very much.
My dream is to play games on linux without wine.
sorry my english

--
View this message in context: http://xen.1045712.n5.nabble.com/Patches-for-VGA-Passthrough-XEN-4-2-unstable-tp4406265p5072769.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 21:06:44 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 21: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.xensource.com>)
	id 1RaZYW-0006E4-Io; Tue, 13 Dec 2011 21:06:32 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <george.shuklin@gmail.com>) id 1RaZYV-0006Dg-B8
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 21:06:31 +0000
X-Env-Sender: george.shuklin@gmail.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1323810336!5245724!1
X-Originating-IP: [209.85.215.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3625 invoked from network); 13 Dec 2011 21:05:36 -0000
Received: from mail-ey0-f171.google.com (HELO mail-ey0-f171.google.com)
	(209.85.215.171)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 21:05:36 -0000
Received: by eaa1 with SMTP id 1so343508eaa.30
	for <xen-devel@lists.xensource.com>;
	Tue, 13 Dec 2011 13:05:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=message-id:date:from:user-agent:mime-version:to:cc:subject
	:references:in-reply-to:content-type:content-transfer-encoding;
	bh=ay1KLksTB6+clHUZTHX+e1arlXxD4hcQaiftwLEt2IM=;
	b=j/wgFbSuRv94eXubfzTzqQ4rLOQi0QU+O235ZKN96daFDMnaf6jUDqdPsRKH4gusFc
	AZNs7adG39bvfswlSGcIIYluDgU1gvVSnLIO3qkR/O+Ac9+ANFLXUxGVwv9TUxAO2E51
	Kg3fdl/MTSysTMRLMxLOwHp2vU3eOkheymZz8=
Received: by 10.205.127.65 with SMTP id gz1mr14540620bkc.106.1323810335737;
	Tue, 13 Dec 2011 13:05:35 -0800 (PST)
Received: from [192.168.0.220] (desunote.ru. [95.161.2.76])
	by mx.google.com with ESMTPS id t6sm596835bka.12.2011.12.13.13.05.33
	(version=SSLv3 cipher=OTHER); Tue, 13 Dec 2011 13:05:34 -0800 (PST)
Message-ID: <4EE7BE1B.6070509@gmail.com>
Date: Wed, 14 Dec 2011 01:05:31 +0400
From: George Shuklin <george.shuklin@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:9.0) Gecko/20111209 Thunderbird/9.0
MIME-Version: 1.0
To: David Vrabel <david.vrabel@citrix.com>
References: <4EE675A8.3030609@niemail.de>
	<4EE71663.5040308@gmail.com>	<CAJeBh4sxdNTxM_oLFAuA6Mw75=LaYysrpS5b8NsZMbkf_swNVw@mail.gmail.com>
	<4EE72A94.6040904@gmail.com> <4EE75080.1000909@citrix.com>
In-Reply-To: <4EE75080.1000909@citrix.com>
Cc: xen-devel@lists.xensource.com, sandr8@gmail.com
Subject: Re: [Xen-devel] a ton of kernel issues
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


On 13.12.2011 17:17, David Vrabel wrote:
>>>> pv_ops is still have some issues with memory limits, but any
>>>> new kernel (3.0+) will boot normal and operates with very
>>>> minor glitches. Older pv_ops (f.e. debian 2.6.32) have some
>>>> more major issues.
>>> what glitches should one expect with 3.0+, and having the choice,
>>> would it be better to go with 3.1 or even 3.2?
>> Right now I know about two of them:
>> When you set up memory for virtual machine using xenballon, value in
>> dom0 differ from value in domU. The issue is that -xen kernels 'hide'
>> some memory in 'used' memory, and pv-ops just reducing TotalMem to value
>> without that memory. Practically that means if you set up memory for
>> domain to 2GiB client will saw only 1.95GiB and so on.
> This really makes no practical difference.  The memory is "used" is
> either case and the different reporting is a side-effect of the change
> in how certain memory allocations are done.
Well... For us it make HUGE difference. We running cloud with very 
precise accounting of  fast automaric memory allocation for customer's 
domains and we account them for ... em... KiB*hr value, so if we account 
domains based on xc.get_domain_memkb value and customers saw difference 
between TotalMem and our values this will make them feel like we 
cheating. We not greedy and ready to 'cut' our mem_kb value to their 
TotalMem, but I hasn't found any formula for that (calculate TotalMem 
from static-max and dom_kb values) and I can't trust any data from 
customer's domains (except request for memory we accept, serve and 
happily take money for 'more memory').

It sounds ridiculous, but we avoiding pv_ops kernels usage due that 
little ~50Mb steal. We stuck with -xen kernels (forward porting from 
SUSE and native CentOS 2.6.18-xen). I don't know what we will do in the 
future, but right now PV-ops is not good...

>> The second issue is lack of support of 'pre-inflated balloon', means you
>> can not set up memory-static-max to 2GiB, target to 1GiB and do 'memory
>> grow' from 1 G to 2 G latter without VM reboot. -xen kernels allow this
>> (up to memory-static-max limit).
> This should work if memory hotplug is enabled.
>
> It is also supported without memory hotplug but this requires that the
> tools supply a suitable memory map that covers the largest
> memory-static-max limit you wish to support.  I'm not sure if the tools
> can do this yet.
>
Well... I post few weeks ago about problems with memory hotplug - I see 
this message in dmesg:

[1935380.223401] System RAM resource 18000000 - 27ffffff cannot be added
[1935380.223414] xen_balloon: reserve_additional_memory: add_memory() 
failed: -17

I post about that: 
http://old-list-archives.xen.org/archives/html/xen-users/2011-11/msg00278.html


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 21:06:44 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 21: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.xensource.com>)
	id 1RaZYW-0006E4-Io; Tue, 13 Dec 2011 21:06:32 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <george.shuklin@gmail.com>) id 1RaZYV-0006Dg-B8
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 21:06:31 +0000
X-Env-Sender: george.shuklin@gmail.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1323810336!5245724!1
X-Originating-IP: [209.85.215.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3625 invoked from network); 13 Dec 2011 21:05:36 -0000
Received: from mail-ey0-f171.google.com (HELO mail-ey0-f171.google.com)
	(209.85.215.171)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 21:05:36 -0000
Received: by eaa1 with SMTP id 1so343508eaa.30
	for <xen-devel@lists.xensource.com>;
	Tue, 13 Dec 2011 13:05:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=message-id:date:from:user-agent:mime-version:to:cc:subject
	:references:in-reply-to:content-type:content-transfer-encoding;
	bh=ay1KLksTB6+clHUZTHX+e1arlXxD4hcQaiftwLEt2IM=;
	b=j/wgFbSuRv94eXubfzTzqQ4rLOQi0QU+O235ZKN96daFDMnaf6jUDqdPsRKH4gusFc
	AZNs7adG39bvfswlSGcIIYluDgU1gvVSnLIO3qkR/O+Ac9+ANFLXUxGVwv9TUxAO2E51
	Kg3fdl/MTSysTMRLMxLOwHp2vU3eOkheymZz8=
Received: by 10.205.127.65 with SMTP id gz1mr14540620bkc.106.1323810335737;
	Tue, 13 Dec 2011 13:05:35 -0800 (PST)
Received: from [192.168.0.220] (desunote.ru. [95.161.2.76])
	by mx.google.com with ESMTPS id t6sm596835bka.12.2011.12.13.13.05.33
	(version=SSLv3 cipher=OTHER); Tue, 13 Dec 2011 13:05:34 -0800 (PST)
Message-ID: <4EE7BE1B.6070509@gmail.com>
Date: Wed, 14 Dec 2011 01:05:31 +0400
From: George Shuklin <george.shuklin@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:9.0) Gecko/20111209 Thunderbird/9.0
MIME-Version: 1.0
To: David Vrabel <david.vrabel@citrix.com>
References: <4EE675A8.3030609@niemail.de>
	<4EE71663.5040308@gmail.com>	<CAJeBh4sxdNTxM_oLFAuA6Mw75=LaYysrpS5b8NsZMbkf_swNVw@mail.gmail.com>
	<4EE72A94.6040904@gmail.com> <4EE75080.1000909@citrix.com>
In-Reply-To: <4EE75080.1000909@citrix.com>
Cc: xen-devel@lists.xensource.com, sandr8@gmail.com
Subject: Re: [Xen-devel] a ton of kernel issues
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


On 13.12.2011 17:17, David Vrabel wrote:
>>>> pv_ops is still have some issues with memory limits, but any
>>>> new kernel (3.0+) will boot normal and operates with very
>>>> minor glitches. Older pv_ops (f.e. debian 2.6.32) have some
>>>> more major issues.
>>> what glitches should one expect with 3.0+, and having the choice,
>>> would it be better to go with 3.1 or even 3.2?
>> Right now I know about two of them:
>> When you set up memory for virtual machine using xenballon, value in
>> dom0 differ from value in domU. The issue is that -xen kernels 'hide'
>> some memory in 'used' memory, and pv-ops just reducing TotalMem to value
>> without that memory. Practically that means if you set up memory for
>> domain to 2GiB client will saw only 1.95GiB and so on.
> This really makes no practical difference.  The memory is "used" is
> either case and the different reporting is a side-effect of the change
> in how certain memory allocations are done.
Well... For us it make HUGE difference. We running cloud with very 
precise accounting of  fast automaric memory allocation for customer's 
domains and we account them for ... em... KiB*hr value, so if we account 
domains based on xc.get_domain_memkb value and customers saw difference 
between TotalMem and our values this will make them feel like we 
cheating. We not greedy and ready to 'cut' our mem_kb value to their 
TotalMem, but I hasn't found any formula for that (calculate TotalMem 
from static-max and dom_kb values) and I can't trust any data from 
customer's domains (except request for memory we accept, serve and 
happily take money for 'more memory').

It sounds ridiculous, but we avoiding pv_ops kernels usage due that 
little ~50Mb steal. We stuck with -xen kernels (forward porting from 
SUSE and native CentOS 2.6.18-xen). I don't know what we will do in the 
future, but right now PV-ops is not good...

>> The second issue is lack of support of 'pre-inflated balloon', means you
>> can not set up memory-static-max to 2GiB, target to 1GiB and do 'memory
>> grow' from 1 G to 2 G latter without VM reboot. -xen kernels allow this
>> (up to memory-static-max limit).
> This should work if memory hotplug is enabled.
>
> It is also supported without memory hotplug but this requires that the
> tools supply a suitable memory map that covers the largest
> memory-static-max limit you wish to support.  I'm not sure if the tools
> can do this yet.
>
Well... I post few weeks ago about problems with memory hotplug - I see 
this message in dmesg:

[1935380.223401] System RAM resource 18000000 - 27ffffff cannot be added
[1935380.223414] xen_balloon: reserve_additional_memory: add_memory() 
failed: -17

I post about that: 
http://old-list-archives.xen.org/archives/html/xen-users/2011-11/msg00278.html


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 21:11:51 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 21:11:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaZdT-0006Vg-C2; Tue, 13 Dec 2011 21:11:39 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <george.shuklin@gmail.com>) id 1RaZdR-0006VW-QQ
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 21:11:38 +0000
X-Env-Sender: george.shuklin@gmail.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1323810643!7992394!1
X-Originating-IP: [209.85.215.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24964 invoked from network); 13 Dec 2011 21:10:43 -0000
Received: from mail-ey0-f171.google.com (HELO mail-ey0-f171.google.com)
	(209.85.215.171)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 21:10:43 -0000
Received: by eaa1 with SMTP id 1so360217eaa.30
	for <xen-devel@lists.xensource.com>;
	Tue, 13 Dec 2011 13:10:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=message-id:date:from:user-agent:mime-version:to:cc:subject
	:references:in-reply-to:content-type:content-transfer-encoding;
	bh=261yioNjhfy7zFvrGnYkUeBnd3p+HMIHJMihOJY9ZYo=;
	b=MXSMo13q12d9zOOsYbx32Rhbfzl8OSzMywM5KzPuv4nzKjHqdC4Kc1zKuFn2MZ3C7P
	eAb59bjmxccUvDb4LI7kM8lIYc5y+gh2lb6bPThUcB7cUzhiSSQNWuIwMdmD9N5MvY1b
	69CKohHK1UapfPBy13sLiFoicr8PJn8WzaGSA=
Received: by 10.205.130.5 with SMTP id hk5mr13722516bkc.74.1323810642988;
	Tue, 13 Dec 2011 13:10:42 -0800 (PST)
Received: from [192.168.0.220] (desunote.ru. [95.161.2.76])
	by mx.google.com with ESMTPS id z7sm719194bka.1.2011.12.13.13.10.41
	(version=SSLv3 cipher=OTHER); Tue, 13 Dec 2011 13:10:42 -0800 (PST)
Message-ID: <4EE7BF4F.7030700@gmail.com>
Date: Wed, 14 Dec 2011 01:10:39 +0400
From: George Shuklin <george.shuklin@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:9.0) Gecko/20111209 Thunderbird/9.0
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
References: <4EE675A8.3030609@niemail.de> <4EE71663.5040308@gmail.com>
	<CAJeBh4sxdNTxM_oLFAuA6Mw75=LaYysrpS5b8NsZMbkf_swNVw@mail.gmail.com>
	<4EE72A94.6040904@gmail.com>
	<20111213141835.GA32247@andromeda.dapyr.net>
In-Reply-To: <20111213141835.GA32247@andromeda.dapyr.net>
Cc: xen-devel@lists.xensource.com, sandr8@gmail.com
Subject: Re: [Xen-devel] a ton of kernel issues
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 13.12.2011 18:18, Konrad Rzeszutek Wilk wrote:

>>> what glitches should one expect with 3.0+, and having the choice,
>>> would it be better to go with 3.1 or even 3.2?
>>>
>> Right now I know about two of them:
>> When you set up memory for virtual machine using xenballon, value in
>> dom0 differ from value in domU. The issue is that -xen kernels 'hide'
>> some memory in 'used' memory, and pv-ops just reducing TotalMem to value
>> without that memory. Practically that means if you set up memory for
>> domain to 2GiB client will saw only 1.95GiB and so on.
>>
>> The second issue is lack of support of 'pre-inflated balloon', means you
>> can not set up memory-static-max to 2GiB, target to 1GiB and do 'memory
>> grow' from 1 G to 2 G latter without VM reboot. -xen kernels allow this
>> (up to memory-static-max limit).
> Is all of this with 'xm' or with 'xl' tools? What happens when you 'grow'
> the memory from 1G to 2G? Are you using the hotplug memory balloon or
> the older one?
This is xcp (with shutdowned squeezed, it not a problem), so we using 
direct calls to xc (domain_set_maxkb), but I can repeat this with xl 
(which one and only one available in XCP), with same results. If I 
create VM with static-max 2GiB, dynamic-max 1GiB, boot it, then:

1) with PV_ops I can go lower than 1GiB, but never any higher than 1GiB
2) with -xen kernels I can go upper to 2GiB.

If I compile kernel with xenballoon hotplug option enabled, after some 
(very small) memory growth (within preallocated memory?) after future 
attempts I getting this message:

[1935380.223401] System RAM resource 18000000 - 27ffffff cannot be added
[1935380.223414] xen_balloon: reserve_additional_memory: add_memory() 
failed: -17

(tested with vanilla 3.0, 3.1 and some RCs of 3.2)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 21:11:51 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 21:11:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaZdT-0006Vg-C2; Tue, 13 Dec 2011 21:11:39 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <george.shuklin@gmail.com>) id 1RaZdR-0006VW-QQ
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 21:11:38 +0000
X-Env-Sender: george.shuklin@gmail.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1323810643!7992394!1
X-Originating-IP: [209.85.215.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24964 invoked from network); 13 Dec 2011 21:10:43 -0000
Received: from mail-ey0-f171.google.com (HELO mail-ey0-f171.google.com)
	(209.85.215.171)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 21:10:43 -0000
Received: by eaa1 with SMTP id 1so360217eaa.30
	for <xen-devel@lists.xensource.com>;
	Tue, 13 Dec 2011 13:10:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=message-id:date:from:user-agent:mime-version:to:cc:subject
	:references:in-reply-to:content-type:content-transfer-encoding;
	bh=261yioNjhfy7zFvrGnYkUeBnd3p+HMIHJMihOJY9ZYo=;
	b=MXSMo13q12d9zOOsYbx32Rhbfzl8OSzMywM5KzPuv4nzKjHqdC4Kc1zKuFn2MZ3C7P
	eAb59bjmxccUvDb4LI7kM8lIYc5y+gh2lb6bPThUcB7cUzhiSSQNWuIwMdmD9N5MvY1b
	69CKohHK1UapfPBy13sLiFoicr8PJn8WzaGSA=
Received: by 10.205.130.5 with SMTP id hk5mr13722516bkc.74.1323810642988;
	Tue, 13 Dec 2011 13:10:42 -0800 (PST)
Received: from [192.168.0.220] (desunote.ru. [95.161.2.76])
	by mx.google.com with ESMTPS id z7sm719194bka.1.2011.12.13.13.10.41
	(version=SSLv3 cipher=OTHER); Tue, 13 Dec 2011 13:10:42 -0800 (PST)
Message-ID: <4EE7BF4F.7030700@gmail.com>
Date: Wed, 14 Dec 2011 01:10:39 +0400
From: George Shuklin <george.shuklin@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:9.0) Gecko/20111209 Thunderbird/9.0
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
References: <4EE675A8.3030609@niemail.de> <4EE71663.5040308@gmail.com>
	<CAJeBh4sxdNTxM_oLFAuA6Mw75=LaYysrpS5b8NsZMbkf_swNVw@mail.gmail.com>
	<4EE72A94.6040904@gmail.com>
	<20111213141835.GA32247@andromeda.dapyr.net>
In-Reply-To: <20111213141835.GA32247@andromeda.dapyr.net>
Cc: xen-devel@lists.xensource.com, sandr8@gmail.com
Subject: Re: [Xen-devel] a ton of kernel issues
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 13.12.2011 18:18, Konrad Rzeszutek Wilk wrote:

>>> what glitches should one expect with 3.0+, and having the choice,
>>> would it be better to go with 3.1 or even 3.2?
>>>
>> Right now I know about two of them:
>> When you set up memory for virtual machine using xenballon, value in
>> dom0 differ from value in domU. The issue is that -xen kernels 'hide'
>> some memory in 'used' memory, and pv-ops just reducing TotalMem to value
>> without that memory. Practically that means if you set up memory for
>> domain to 2GiB client will saw only 1.95GiB and so on.
>>
>> The second issue is lack of support of 'pre-inflated balloon', means you
>> can not set up memory-static-max to 2GiB, target to 1GiB and do 'memory
>> grow' from 1 G to 2 G latter without VM reboot. -xen kernels allow this
>> (up to memory-static-max limit).
> Is all of this with 'xm' or with 'xl' tools? What happens when you 'grow'
> the memory from 1G to 2G? Are you using the hotplug memory balloon or
> the older one?
This is xcp (with shutdowned squeezed, it not a problem), so we using 
direct calls to xc (domain_set_maxkb), but I can repeat this with xl 
(which one and only one available in XCP), with same results. If I 
create VM with static-max 2GiB, dynamic-max 1GiB, boot it, then:

1) with PV_ops I can go lower than 1GiB, but never any higher than 1GiB
2) with -xen kernels I can go upper to 2GiB.

If I compile kernel with xenballoon hotplug option enabled, after some 
(very small) memory growth (within preallocated memory?) after future 
attempts I getting this message:

[1935380.223401] System RAM resource 18000000 - 27ffffff cannot be added
[1935380.223414] xen_balloon: reserve_additional_memory: add_memory() 
failed: -17

(tested with vanilla 3.0, 3.1 and some RCs of 3.2)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 21:21:49 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 21: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.xensource.com>)
	id 1RaZn8-0006yM-57; Tue, 13 Dec 2011 21:21:38 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.r.wilk@gmail.com>) id 1RaZn6-0006yC-3v
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 21:21:36 +0000
X-Env-Sender: konrad.r.wilk@gmail.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1323811240!6598049!1
X-Originating-IP: [209.85.216.171]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18542 invoked from network); 13 Dec 2011 21:20:41 -0000
Received: from mail-qy0-f171.google.com (HELO mail-qy0-f171.google.com)
	(209.85.216.171)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 21:20:41 -0000
Received: by qcsc20 with SMTP id c20so618644qcs.30
	for <xen-devel@lists.xensource.com>;
	Tue, 13 Dec 2011 13:20:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:date:from:to:cc:subject:message-id:references:mime-version
	:content-type:content-disposition:in-reply-to:user-agent;
	bh=UNs+zjQrj/AvSC0g1QPIoyePyZPQ93p/j2i6eHlVBWY=;
	b=wutJoMxv6opGlwIo4lB3UTCaexmjc6aP0vuWb0mjVnyYONWsdcfZgS8T4YURqcq6tK
	JBGWCA9uHtbKn1+wSbIcftFmxUiDzJVZhRpM7Tfy7OWaSHC7HAkVKuGshJlxJOQgjd52
	6B5oYTl9+62MzkJTChfus5ZNd1tT7hJgYWcwg=
Received: by 10.224.197.137 with SMTP id ek9mr5332746qab.52.1323811239890;
	Tue, 13 Dec 2011 13:20:39 -0800 (PST)
Received: from konrad-lan (209-6-85-33.c3-0.smr-ubr2.sbo-smr.ma.cable.rcn.com.
	[209.6.85.33])
	by mx.google.com with ESMTPS id dm3sm673625qab.12.2011.12.13.13.20.38
	(version=TLSv1/SSLv3 cipher=OTHER);
	Tue, 13 Dec 2011 13:20:39 -0800 (PST)
Date: Tue, 13 Dec 2011 16:20:32 -0500
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Roderick Colenbrander <thunderbird2k@gmail.com>
Message-ID: <20111213212031.GA8410@konrad-lan>
References: <CAEc3jaACffpr9D1Hq_012vHAGhPLEfvsZjh7YyJ=Q-3FdtHS0Q@mail.gmail.com>
	<CAPbh3rtOQ1HTPReqYcpE3vzk+-na0MTLLHZD15=Fg4yxB+ypaA@mail.gmail.com>
	<CAEc3jaBdQKmVJToNZRf+25GtJXqGc274ieHf_yHKRJ+YOKWdgA@mail.gmail.com>
	<20111208234624.GD32474@konrad-lan>
	<CAEc3jaC9=HiMoxSYZmXKRzoFcMYRaT9jrX3m1ZQO+M8CrH35Fg@mail.gmail.com>
	<CAEc3jaBBYBME0G3Ku_sTvzQz+oKQnpBPffA+bRUKxxRPABAeww@mail.gmail.com>
	<20111211125247.GQ12984@reaktio.net>
	<CAEc3jaCJ6wP27Ffm0wpOggWMgqcSNJiGxhtkszq6jgRD1nrZLg@mail.gmail.com>
	<CAEc3jaBS6WUB_oViMp=qT_0RP+LPjZuEV8Qko9Jabs6qaeSibQ@mail.gmail.com>
	<20111213020229.GB2730@konrad-lan>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20111213020229.GB2730@konrad-lan>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: xen-devel@lists.xensource.com, Andreas Kinzler <ml-xen-devel@hfp.de>
Subject: Re: [Xen-devel] Questions about GPLPV stability tests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> > Does this feel like blktap issues? Or is it more likely that something
> > else happened which causes blktap and the other things to fail?
> 
> It looks like the interrupts stopped. Perhaps you can run the C code
> (attached) on the serial console and see _what_ (or perhaps _when_)
> the interrupts stops (and also verify that the timeouts and 'frozen'
> happen due to no interrupts being received).

The C code is http://darnok.org/xen/read_interrupts.c

> 
> There are a couple of bugs that were discovered in the interrupt code
> (that had been there since 2.6.27!) that went to the stable tree - so
> they should been backported to 2.6.32.x tree - but I honestly don't
> recall the names. I can look them up tomorrow.

xen: x86_32: do not enable iterrupts when returning from exception in
interrupt context (git commit d198d499148a0c64a41b3aba9e7dd43772832b91)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 21:21:49 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 21: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.xensource.com>)
	id 1RaZn8-0006yM-57; Tue, 13 Dec 2011 21:21:38 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.r.wilk@gmail.com>) id 1RaZn6-0006yC-3v
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 21:21:36 +0000
X-Env-Sender: konrad.r.wilk@gmail.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1323811240!6598049!1
X-Originating-IP: [209.85.216.171]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18542 invoked from network); 13 Dec 2011 21:20:41 -0000
Received: from mail-qy0-f171.google.com (HELO mail-qy0-f171.google.com)
	(209.85.216.171)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 21:20:41 -0000
Received: by qcsc20 with SMTP id c20so618644qcs.30
	for <xen-devel@lists.xensource.com>;
	Tue, 13 Dec 2011 13:20:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:date:from:to:cc:subject:message-id:references:mime-version
	:content-type:content-disposition:in-reply-to:user-agent;
	bh=UNs+zjQrj/AvSC0g1QPIoyePyZPQ93p/j2i6eHlVBWY=;
	b=wutJoMxv6opGlwIo4lB3UTCaexmjc6aP0vuWb0mjVnyYONWsdcfZgS8T4YURqcq6tK
	JBGWCA9uHtbKn1+wSbIcftFmxUiDzJVZhRpM7Tfy7OWaSHC7HAkVKuGshJlxJOQgjd52
	6B5oYTl9+62MzkJTChfus5ZNd1tT7hJgYWcwg=
Received: by 10.224.197.137 with SMTP id ek9mr5332746qab.52.1323811239890;
	Tue, 13 Dec 2011 13:20:39 -0800 (PST)
Received: from konrad-lan (209-6-85-33.c3-0.smr-ubr2.sbo-smr.ma.cable.rcn.com.
	[209.6.85.33])
	by mx.google.com with ESMTPS id dm3sm673625qab.12.2011.12.13.13.20.38
	(version=TLSv1/SSLv3 cipher=OTHER);
	Tue, 13 Dec 2011 13:20:39 -0800 (PST)
Date: Tue, 13 Dec 2011 16:20:32 -0500
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Roderick Colenbrander <thunderbird2k@gmail.com>
Message-ID: <20111213212031.GA8410@konrad-lan>
References: <CAEc3jaACffpr9D1Hq_012vHAGhPLEfvsZjh7YyJ=Q-3FdtHS0Q@mail.gmail.com>
	<CAPbh3rtOQ1HTPReqYcpE3vzk+-na0MTLLHZD15=Fg4yxB+ypaA@mail.gmail.com>
	<CAEc3jaBdQKmVJToNZRf+25GtJXqGc274ieHf_yHKRJ+YOKWdgA@mail.gmail.com>
	<20111208234624.GD32474@konrad-lan>
	<CAEc3jaC9=HiMoxSYZmXKRzoFcMYRaT9jrX3m1ZQO+M8CrH35Fg@mail.gmail.com>
	<CAEc3jaBBYBME0G3Ku_sTvzQz+oKQnpBPffA+bRUKxxRPABAeww@mail.gmail.com>
	<20111211125247.GQ12984@reaktio.net>
	<CAEc3jaCJ6wP27Ffm0wpOggWMgqcSNJiGxhtkszq6jgRD1nrZLg@mail.gmail.com>
	<CAEc3jaBS6WUB_oViMp=qT_0RP+LPjZuEV8Qko9Jabs6qaeSibQ@mail.gmail.com>
	<20111213020229.GB2730@konrad-lan>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20111213020229.GB2730@konrad-lan>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: xen-devel@lists.xensource.com, Andreas Kinzler <ml-xen-devel@hfp.de>
Subject: Re: [Xen-devel] Questions about GPLPV stability tests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> > Does this feel like blktap issues? Or is it more likely that something
> > else happened which causes blktap and the other things to fail?
> 
> It looks like the interrupts stopped. Perhaps you can run the C code
> (attached) on the serial console and see _what_ (or perhaps _when_)
> the interrupts stops (and also verify that the timeouts and 'frozen'
> happen due to no interrupts being received).

The C code is http://darnok.org/xen/read_interrupts.c

> 
> There are a couple of bugs that were discovered in the interrupt code
> (that had been there since 2.6.27!) that went to the stable tree - so
> they should been backported to 2.6.32.x tree - but I honestly don't
> recall the names. I can look them up tomorrow.

xen: x86_32: do not enable iterrupts when returning from exception in
interrupt context (git commit d198d499148a0c64a41b3aba9e7dd43772832b91)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 21:29:06 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 21:29:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaZu9-0007FR-2V; Tue, 13 Dec 2011 21:28:53 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jim_burn@bellsouth.net>) id 1RaZu7-0007F6-SE
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 21:28:52 +0000
X-Env-Sender: jim_burn@bellsouth.net
X-Msg-Ref: server-5.tower-216.messagelabs.com!1323811676!7345257!1
X-Originating-IP: [66.94.237.91]
X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17543 invoked from network); 13 Dec 2011 21:27:57 -0000
Received: from nm26.access.bullet.mail.mud.yahoo.com (HELO
	nm26.access.bullet.mail.mud.yahoo.com) (66.94.237.91)
	by server-5.tower-216.messagelabs.com with SMTP;
	13 Dec 2011 21:27:57 -0000
Received: from [66.94.237.194] by nm26.access.bullet.mail.mud.yahoo.com with
	NNFMP; 13 Dec 2011 21:27:56 -0000
Received: from [98.139.221.55] by tm5.access.bullet.mail.mud.yahoo.com with
	NNFMP; 13 Dec 2011 21:27:56 -0000
Received: from [127.0.0.1] by smtp108.sbc.mail.bf1.yahoo.com with NNFMP;
	13 Dec 2011 21:27:56 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bellsouth.net; s=s1024;
	t=1323811676; bh=Ia9QuSWeUIMb+EeD37ahxZZgpkFbmXcIIcIKnVztRF0=;
	h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:From:To:Cc:Subject:Date:Message-ID:User-Agent:MIME-Version:Content-Transfer-Encoding:Content-Type;
	b=UaLQhFtBB0OdldNcwmUe/ZPCj04kSgAu86+uY6ffIVsozsuKLegGxtCW0Zbyxrgw6fg1R5jwKMqu5bsHx+7tjnPDDxdzndTObmbiMFiqLq/ypn3nu45Fzw1rQ+EcPp2uKQzPYwi1Gj+Fb1bx++/Qea5IWRZ8VnEuQkuC1yT1Sl4=
X-Yahoo-Newman-Id: 396762.98527.bm@smtp108.sbc.mail.bf1.yahoo.com
X-Yahoo-Newman-Property: ymail-3
X-YMail-OSG: mZJEAdIVM1n0VELWTtoZUE9mMmCt5hAAjRzasxHBUD6jzth
	MeM8j4Xufdsj6XPSQsIg6xg1nXZMNaV7WK5xBAXotj05izyi8FAcEc2oF7U8
	Z1DQoi8Gs8uzKk9JG1deQrgIFPwQsy1K4VAoWPWF57BSQIkhQ7T1SlUxVEEZ
	Rj4UP_kfHq9d0QyUShYx8NGrGl5Q3Isj8PMtksNWnw.CVb87daz_UcGnGV_o
	BQYLixMPaNat1KSZzllxvmEjZhTircY3qz5lbaeRAEdp5.wNfm6M_6UPrqTb
	Nu29t7zff8c_k5RY2uIPCsxZ.0KrYiUDBaGNtSSXGWLrW.fisqBoN5P5B6YZ
	A7RrOFc.OYz5P0LoIiYVKNZuqbkyM84MW_idmGhpr9rTGtbKoowTPe714r1V s
X-Yahoo-SMTP: g0AhWW2swBA2djJKuhuwxPlPqLrHlDrycdPnfR9kZNrpKCA-
Received: from dell4550.localnet (jim_burn@184.36.12.137 with plain)
	by smtp108.sbc.mail.bf1.yahoo.com with SMTP;
	13 Dec 2011 13:27:56 -0800 PST
From: jim burns <jim_burn@bellsouth.net>
To: xen-devel@lists.xensource.com, JBeulich@suse.com
Date: Tue, 13 Dec 2011 16:27:47 -0500
Message-ID: <5240506.YiTi8lqF86@dell4550>
User-Agent: KMail/4.7.4 (Linux/3.1.0-1.2-default; KDE/4.7.4; i686; ; )
MIME-Version: 1.0
Cc: xen-users@lists.xensource.com
Subject: [Xen-devel] openSUSE 12.1 does not have complete xen rpms
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi Jan -

I just upgraded yesterday from suse 11.4 to 12.1. 12.1 only has xen-libs, and 
xen-tools (both 4.1.2) is for a domu. (Technically, a dom0 is just a 
privileged domu. None the less, 11.4 had a xen-tools *and* a xen-tools-domu.) 
There is no xen hypervisor - my /boot/xen.gz is still the 4.0.2 from 11.4 - or 
any xen rpm at all. No /etc/xen, /etc/udev, /usr/lib/xen, xend, xm, xl, etc.

Do you have some insight into what the hold up is? Thanx.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 21:29:06 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 21:29:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaZu9-0007FR-2V; Tue, 13 Dec 2011 21:28:53 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jim_burn@bellsouth.net>) id 1RaZu7-0007F6-SE
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 21:28:52 +0000
X-Env-Sender: jim_burn@bellsouth.net
X-Msg-Ref: server-5.tower-216.messagelabs.com!1323811676!7345257!1
X-Originating-IP: [66.94.237.91]
X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17543 invoked from network); 13 Dec 2011 21:27:57 -0000
Received: from nm26.access.bullet.mail.mud.yahoo.com (HELO
	nm26.access.bullet.mail.mud.yahoo.com) (66.94.237.91)
	by server-5.tower-216.messagelabs.com with SMTP;
	13 Dec 2011 21:27:57 -0000
Received: from [66.94.237.194] by nm26.access.bullet.mail.mud.yahoo.com with
	NNFMP; 13 Dec 2011 21:27:56 -0000
Received: from [98.139.221.55] by tm5.access.bullet.mail.mud.yahoo.com with
	NNFMP; 13 Dec 2011 21:27:56 -0000
Received: from [127.0.0.1] by smtp108.sbc.mail.bf1.yahoo.com with NNFMP;
	13 Dec 2011 21:27:56 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bellsouth.net; s=s1024;
	t=1323811676; bh=Ia9QuSWeUIMb+EeD37ahxZZgpkFbmXcIIcIKnVztRF0=;
	h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:From:To:Cc:Subject:Date:Message-ID:User-Agent:MIME-Version:Content-Transfer-Encoding:Content-Type;
	b=UaLQhFtBB0OdldNcwmUe/ZPCj04kSgAu86+uY6ffIVsozsuKLegGxtCW0Zbyxrgw6fg1R5jwKMqu5bsHx+7tjnPDDxdzndTObmbiMFiqLq/ypn3nu45Fzw1rQ+EcPp2uKQzPYwi1Gj+Fb1bx++/Qea5IWRZ8VnEuQkuC1yT1Sl4=
X-Yahoo-Newman-Id: 396762.98527.bm@smtp108.sbc.mail.bf1.yahoo.com
X-Yahoo-Newman-Property: ymail-3
X-YMail-OSG: mZJEAdIVM1n0VELWTtoZUE9mMmCt5hAAjRzasxHBUD6jzth
	MeM8j4Xufdsj6XPSQsIg6xg1nXZMNaV7WK5xBAXotj05izyi8FAcEc2oF7U8
	Z1DQoi8Gs8uzKk9JG1deQrgIFPwQsy1K4VAoWPWF57BSQIkhQ7T1SlUxVEEZ
	Rj4UP_kfHq9d0QyUShYx8NGrGl5Q3Isj8PMtksNWnw.CVb87daz_UcGnGV_o
	BQYLixMPaNat1KSZzllxvmEjZhTircY3qz5lbaeRAEdp5.wNfm6M_6UPrqTb
	Nu29t7zff8c_k5RY2uIPCsxZ.0KrYiUDBaGNtSSXGWLrW.fisqBoN5P5B6YZ
	A7RrOFc.OYz5P0LoIiYVKNZuqbkyM84MW_idmGhpr9rTGtbKoowTPe714r1V s
X-Yahoo-SMTP: g0AhWW2swBA2djJKuhuwxPlPqLrHlDrycdPnfR9kZNrpKCA-
Received: from dell4550.localnet (jim_burn@184.36.12.137 with plain)
	by smtp108.sbc.mail.bf1.yahoo.com with SMTP;
	13 Dec 2011 13:27:56 -0800 PST
From: jim burns <jim_burn@bellsouth.net>
To: xen-devel@lists.xensource.com, JBeulich@suse.com
Date: Tue, 13 Dec 2011 16:27:47 -0500
Message-ID: <5240506.YiTi8lqF86@dell4550>
User-Agent: KMail/4.7.4 (Linux/3.1.0-1.2-default; KDE/4.7.4; i686; ; )
MIME-Version: 1.0
Cc: xen-users@lists.xensource.com
Subject: [Xen-devel] openSUSE 12.1 does not have complete xen rpms
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi Jan -

I just upgraded yesterday from suse 11.4 to 12.1. 12.1 only has xen-libs, and 
xen-tools (both 4.1.2) is for a domu. (Technically, a dom0 is just a 
privileged domu. None the less, 11.4 had a xen-tools *and* a xen-tools-domu.) 
There is no xen hypervisor - my /boot/xen.gz is still the 4.0.2 from 11.4 - or 
any xen rpm at all. No /etc/xen, /etc/udev, /usr/lib/xen, xend, xm, xl, etc.

Do you have some insight into what the hold up is? Thanx.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 21:40:22 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 21: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.xensource.com>)
	id 1Raa4q-0007xS-1u; Tue, 13 Dec 2011 21:39:56 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1Raa4o-0007xD-GQ
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 21:39:54 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-13.tower-216.messagelabs.com!1323812338!6743897!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29613 invoked from network); 13 Dec 2011 21:38:59 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-13.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 13 Dec 2011 21:38:59 -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
	pBDLculL029181
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Tue, 13 Dec 2011 16:38:56 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pBDLcuMd029179;
	Tue, 13 Dec 2011 16:38:56 -0500
Date: Tue, 13 Dec 2011 17:38:56 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: George Shuklin <george.shuklin@gmail.com>
Message-ID: <20111213213856.GA29005@andromeda.dapyr.net>
References: <4EE675A8.3030609@niemail.de> <4EE71663.5040308@gmail.com>
	<CAJeBh4sxdNTxM_oLFAuA6Mw75=LaYysrpS5b8NsZMbkf_swNVw@mail.gmail.com>
	<4EE72A94.6040904@gmail.com>
	<20111213141835.GA32247@andromeda.dapyr.net>
	<4EE7BF4F.7030700@gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4EE7BF4F.7030700@gmail.com>
User-Agent: Mutt/1.5.9i
Cc: xen-devel@lists.xensource.com, sandr8@gmail.com
Subject: Re: [Xen-devel] a ton of kernel issues
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Dec 14, 2011 at 01:10:39AM +0400, George Shuklin wrote:
> On 13.12.2011 18:18, Konrad Rzeszutek Wilk wrote:
> 
> >>>what glitches should one expect with 3.0+, and having the choice,
> >>>would it be better to go with 3.1 or even 3.2?
> >>>
> >>Right now I know about two of them:
> >>When you set up memory for virtual machine using xenballon, value in
> >>dom0 differ from value in domU. The issue is that -xen kernels 'hide'
> >>some memory in 'used' memory, and pv-ops just reducing TotalMem to value
> >>without that memory. Practically that means if you set up memory for
> >>domain to 2GiB client will saw only 1.95GiB and so on.
> >>
> >>The second issue is lack of support of 'pre-inflated balloon', means you
> >>can not set up memory-static-max to 2GiB, target to 1GiB and do 'memory
> >>grow' from 1 G to 2 G latter without VM reboot. -xen kernels allow this
> >>(up to memory-static-max limit).
> >Is all of this with 'xm' or with 'xl' tools? What happens when you 'grow'
> >the memory from 1G to 2G? Are you using the hotplug memory balloon or
> >the older one?
> This is xcp (with shutdowned squeezed, it not a problem), so we using 
> direct calls to xc (domain_set_maxkb), but I can repeat this with xl 
> (which one and only one available in XCP), with same results. If I 
> create VM with static-max 2GiB, dynamic-max 1GiB, boot it, then:
> 
> 1) with PV_ops I can go lower than 1GiB, but never any higher than 1GiB

I just tried this, and had these two options in my guest config:

maxmem=2048
mem=1024

booted up the guest and from dom0 did "xm mem-set latest 2048"
and it expanded to 2G. Did "xm mem-set latest 10248" and it went down.

Is this how you are doing it as well? (I have to confess I don't know
much about XCP so don't know if those 'static-max, dynamic-max'
are the same thing).

Is this PV bootup? Or HVM?

> 2) with -xen kernels I can go upper to 2GiB.
> 
> If I compile kernel with xenballoon hotplug option enabled, after some 
> (very small) memory growth (within preallocated memory?) after future 
> attempts I getting this message:
> 
> [1935380.223401] System RAM resource 18000000 - 27ffffff cannot be added
> [1935380.223414] xen_balloon: reserve_additional_memory: add_memory() 
> failed: -17

Hm, that looks like a bug. But the old style balloon code does work.
Not sure why with a default .config you are hitting these issues.
> 
> (tested with vanilla 3.0, 3.1 and some RCs of 3.2)
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 21:40:22 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 21: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.xensource.com>)
	id 1Raa4q-0007xS-1u; Tue, 13 Dec 2011 21:39:56 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1Raa4o-0007xD-GQ
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 21:39:54 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-13.tower-216.messagelabs.com!1323812338!6743897!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29613 invoked from network); 13 Dec 2011 21:38:59 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-13.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 13 Dec 2011 21:38:59 -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
	pBDLculL029181
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Tue, 13 Dec 2011 16:38:56 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pBDLcuMd029179;
	Tue, 13 Dec 2011 16:38:56 -0500
Date: Tue, 13 Dec 2011 17:38:56 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: George Shuklin <george.shuklin@gmail.com>
Message-ID: <20111213213856.GA29005@andromeda.dapyr.net>
References: <4EE675A8.3030609@niemail.de> <4EE71663.5040308@gmail.com>
	<CAJeBh4sxdNTxM_oLFAuA6Mw75=LaYysrpS5b8NsZMbkf_swNVw@mail.gmail.com>
	<4EE72A94.6040904@gmail.com>
	<20111213141835.GA32247@andromeda.dapyr.net>
	<4EE7BF4F.7030700@gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4EE7BF4F.7030700@gmail.com>
User-Agent: Mutt/1.5.9i
Cc: xen-devel@lists.xensource.com, sandr8@gmail.com
Subject: Re: [Xen-devel] a ton of kernel issues
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Dec 14, 2011 at 01:10:39AM +0400, George Shuklin wrote:
> On 13.12.2011 18:18, Konrad Rzeszutek Wilk wrote:
> 
> >>>what glitches should one expect with 3.0+, and having the choice,
> >>>would it be better to go with 3.1 or even 3.2?
> >>>
> >>Right now I know about two of them:
> >>When you set up memory for virtual machine using xenballon, value in
> >>dom0 differ from value in domU. The issue is that -xen kernels 'hide'
> >>some memory in 'used' memory, and pv-ops just reducing TotalMem to value
> >>without that memory. Practically that means if you set up memory for
> >>domain to 2GiB client will saw only 1.95GiB and so on.
> >>
> >>The second issue is lack of support of 'pre-inflated balloon', means you
> >>can not set up memory-static-max to 2GiB, target to 1GiB and do 'memory
> >>grow' from 1 G to 2 G latter without VM reboot. -xen kernels allow this
> >>(up to memory-static-max limit).
> >Is all of this with 'xm' or with 'xl' tools? What happens when you 'grow'
> >the memory from 1G to 2G? Are you using the hotplug memory balloon or
> >the older one?
> This is xcp (with shutdowned squeezed, it not a problem), so we using 
> direct calls to xc (domain_set_maxkb), but I can repeat this with xl 
> (which one and only one available in XCP), with same results. If I 
> create VM with static-max 2GiB, dynamic-max 1GiB, boot it, then:
> 
> 1) with PV_ops I can go lower than 1GiB, but never any higher than 1GiB

I just tried this, and had these two options in my guest config:

maxmem=2048
mem=1024

booted up the guest and from dom0 did "xm mem-set latest 2048"
and it expanded to 2G. Did "xm mem-set latest 10248" and it went down.

Is this how you are doing it as well? (I have to confess I don't know
much about XCP so don't know if those 'static-max, dynamic-max'
are the same thing).

Is this PV bootup? Or HVM?

> 2) with -xen kernels I can go upper to 2GiB.
> 
> If I compile kernel with xenballoon hotplug option enabled, after some 
> (very small) memory growth (within preallocated memory?) after future 
> attempts I getting this message:
> 
> [1935380.223401] System RAM resource 18000000 - 27ffffff cannot be added
> [1935380.223414] xen_balloon: reserve_additional_memory: add_memory() 
> failed: -17

Hm, that looks like a bug. But the old style balloon code does work.
Not sure why with a default .config you are hitting these issues.
> 
> (tested with vanilla 3.0, 3.1 and some RCs of 3.2)
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 21:46:45 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 21:46:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaaB4-000897-Vx; Tue, 13 Dec 2011 21:46:22 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1RaaB3-000892-I9
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 21:46:21 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-3.tower-216.messagelabs.com!1323812725!7302679!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27090 invoked from network); 13 Dec 2011 21:45:26 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-3.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 13 Dec 2011 21:45:26 -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
	pBDLjNHP029468
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Tue, 13 Dec 2011 16:45:23 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pBDLjNhB029466;
	Tue, 13 Dec 2011 16:45:23 -0500
Date: Tue, 13 Dec 2011 17:45:23 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: George Shuklin <george.shuklin@gmail.com>
Message-ID: <20111213214522.GB29005@andromeda.dapyr.net>
References: <4EE675A8.3030609@niemail.de> <4EE71663.5040308@gmail.com>
	<CAJeBh4sxdNTxM_oLFAuA6Mw75=LaYysrpS5b8NsZMbkf_swNVw@mail.gmail.com>
	<4EE72A94.6040904@gmail.com> <4EE75080.1000909@citrix.com>
	<4EE7BE1B.6070509@gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4EE7BE1B.6070509@gmail.com>
User-Agent: Mutt/1.5.9i
Cc: xen-devel@lists.xensource.com, David Vrabel <david.vrabel@citrix.com>,
	sandr8@gmail.com
Subject: Re: [Xen-devel] a ton of kernel issues
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Dec 14, 2011 at 01:05:31AM +0400, George Shuklin wrote:
> 
> On 13.12.2011 17:17, David Vrabel wrote:
> >>>>pv_ops is still have some issues with memory limits, but any
> >>>>new kernel (3.0+) will boot normal and operates with very
> >>>>minor glitches. Older pv_ops (f.e. debian 2.6.32) have some
> >>>>more major issues.
> >>>what glitches should one expect with 3.0+, and having the choice,
> >>>would it be better to go with 3.1 or even 3.2?
> >>Right now I know about two of them:
> >>When you set up memory for virtual machine using xenballon, value in
> >>dom0 differ from value in domU. The issue is that -xen kernels 'hide'
> >>some memory in 'used' memory, and pv-ops just reducing TotalMem to value
> >>without that memory. Practically that means if you set up memory for
> >>domain to 2GiB client will saw only 1.95GiB and so on.
> >This really makes no practical difference.  The memory is "used" is
> >either case and the different reporting is a side-effect of the change
> >in how certain memory allocations are done.

David,

You are thinking that this is the vmalloc vs kmalloc memory for the
frontends?

> Well... For us it make HUGE difference. We running cloud with very 
> precise accounting of  fast automaric memory allocation for customer's 
> domains and we account them for ... em... KiB*hr value, so if we account 
> domains based on xc.get_domain_memkb value and customers saw difference 
> between TotalMem and our values this will make them feel like we 
> cheating. We not greedy and ready to 'cut' our mem_kb value to their 
> TotalMem, but I hasn't found any formula for that (calculate TotalMem 
> from static-max and dom_kb values) and I can't trust any data from 
> customer's domains (except request for memory we accept, serve and 
> happily take money for 'more memory').
> 
> It sounds ridiculous, but we avoiding pv_ops kernels usage due that 
> little ~50Mb steal. We stuck with -xen kernels (forward porting from 
> SUSE and native CentOS 2.6.18-xen). I don't know what we will do in the 
> future, but right now PV-ops is not good...

50MB is rather a large amount - it should be more of a couple of MBs -
unless there are other things in the picture (P2M? per-cpu?). Have you
tried to run the same kernel version but different architecture - so a
SuSE 2.6.X kernel with a pvops 2.6.X, where X=X? If so, were there any
obvious disreprancies in the e820 and in the "Memory reserved" values?
Were the .config similar?


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 21:46:45 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 21:46:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaaB4-000897-Vx; Tue, 13 Dec 2011 21:46:22 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1RaaB3-000892-I9
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 21:46:21 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-3.tower-216.messagelabs.com!1323812725!7302679!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27090 invoked from network); 13 Dec 2011 21:45:26 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-3.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 13 Dec 2011 21:45:26 -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
	pBDLjNHP029468
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Tue, 13 Dec 2011 16:45:23 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pBDLjNhB029466;
	Tue, 13 Dec 2011 16:45:23 -0500
Date: Tue, 13 Dec 2011 17:45:23 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: George Shuklin <george.shuklin@gmail.com>
Message-ID: <20111213214522.GB29005@andromeda.dapyr.net>
References: <4EE675A8.3030609@niemail.de> <4EE71663.5040308@gmail.com>
	<CAJeBh4sxdNTxM_oLFAuA6Mw75=LaYysrpS5b8NsZMbkf_swNVw@mail.gmail.com>
	<4EE72A94.6040904@gmail.com> <4EE75080.1000909@citrix.com>
	<4EE7BE1B.6070509@gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4EE7BE1B.6070509@gmail.com>
User-Agent: Mutt/1.5.9i
Cc: xen-devel@lists.xensource.com, David Vrabel <david.vrabel@citrix.com>,
	sandr8@gmail.com
Subject: Re: [Xen-devel] a ton of kernel issues
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Dec 14, 2011 at 01:05:31AM +0400, George Shuklin wrote:
> 
> On 13.12.2011 17:17, David Vrabel wrote:
> >>>>pv_ops is still have some issues with memory limits, but any
> >>>>new kernel (3.0+) will boot normal and operates with very
> >>>>minor glitches. Older pv_ops (f.e. debian 2.6.32) have some
> >>>>more major issues.
> >>>what glitches should one expect with 3.0+, and having the choice,
> >>>would it be better to go with 3.1 or even 3.2?
> >>Right now I know about two of them:
> >>When you set up memory for virtual machine using xenballon, value in
> >>dom0 differ from value in domU. The issue is that -xen kernels 'hide'
> >>some memory in 'used' memory, and pv-ops just reducing TotalMem to value
> >>without that memory. Practically that means if you set up memory for
> >>domain to 2GiB client will saw only 1.95GiB and so on.
> >This really makes no practical difference.  The memory is "used" is
> >either case and the different reporting is a side-effect of the change
> >in how certain memory allocations are done.

David,

You are thinking that this is the vmalloc vs kmalloc memory for the
frontends?

> Well... For us it make HUGE difference. We running cloud with very 
> precise accounting of  fast automaric memory allocation for customer's 
> domains and we account them for ... em... KiB*hr value, so if we account 
> domains based on xc.get_domain_memkb value and customers saw difference 
> between TotalMem and our values this will make them feel like we 
> cheating. We not greedy and ready to 'cut' our mem_kb value to their 
> TotalMem, but I hasn't found any formula for that (calculate TotalMem 
> from static-max and dom_kb values) and I can't trust any data from 
> customer's domains (except request for memory we accept, serve and 
> happily take money for 'more memory').
> 
> It sounds ridiculous, but we avoiding pv_ops kernels usage due that 
> little ~50Mb steal. We stuck with -xen kernels (forward porting from 
> SUSE and native CentOS 2.6.18-xen). I don't know what we will do in the 
> future, but right now PV-ops is not good...

50MB is rather a large amount - it should be more of a couple of MBs -
unless there are other things in the picture (P2M? per-cpu?). Have you
tried to run the same kernel version but different architecture - so a
SuSE 2.6.X kernel with a pvops 2.6.X, where X=X? If so, were there any
obvious disreprancies in the e820 and in the "Memory reserved" values?
Were the .config similar?


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 22:19:18 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 22:19:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaagV-0008Q3-Nu; Tue, 13 Dec 2011 22:18:51 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Neal.Taylor@ca.com>) id 1RaagT-0008Pv-P2
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 22:18:50 +0000
X-Env-Sender: Neal.Taylor@ca.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1323814672!7145979!1
X-Originating-IP: [74.125.149.69]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1349 invoked from network); 13 Dec 2011 22:17:54 -0000
Received: from na3sys009aog102.obsmtp.com (HELO na3sys009aog102.obsmtp.com)
	(74.125.149.69)
	by server-3.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Dec 2011 22:17:54 -0000
Received: from USILMS190.ca.com ([141.202.246.44]) (using TLSv1) by
	na3sys009aob102.postini.com ([74.125.148.12]) with SMTP
	ID DSNKTufPD5yX8uqhK2vAQy3QiZ17mYaw0Uao@postini.com;
	Tue, 13 Dec 2011 14:17:53 PST
Received: from USILMS173.ca.com (141.202.6.23) by USILMS190.ca.com
	(141.202.246.44) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Tue, 13 Dec 2011 17:17:51 -0500
Received: from USILMS110A.ca.com ([169.254.1.109]) by usilms173.ca.com
	([141.202.6.23]) with mapi id 14.01.0289.001;
	Tue, 13 Dec 2011 17:17:50 -0500
From: "Taylor, Neal E" <Neal.Taylor@ca.com>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
Thread-Topic: [Xen-devel] Buffers not reachable by PCI
Thread-Index: Acy2r+Ulg1PsfbmtTl6QVj0jZAx7mwAK1xcAAIXl/sAAGPmvgAAhEiCw
Date: Tue, 13 Dec 2011 22:17:50 +0000
Message-ID: <3E243B26F475504B9BB0BCC9728B0DA629E184FA@USILMS110A.ca.com>
References: <3E243B26F475504B9BB0BCC9728B0DA629E16E01@USILMS110A.ca.com>
	<20111209203010.GA14412@andromeda.dapyr.net>
	<3E243B26F475504B9BB0BCC9728B0DA629E17AEA@USILMS110A.ca.com>
	<20111213001912.GA2730@konrad-lan>
In-Reply-To: <20111213001912.GA2730@konrad-lan>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [138.42.46.105]
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>, "Kalev,
	Leonid" <Leonid.Kalev@ca.com>, "Dave, Tushar N" <tushar.n.dave@intel.com>
Subject: Re: [Xen-devel] Buffers not reachable by PCI
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


Is it the translation that's in error?

Modeled after the translation in xen_swiotlb_dma_supported that's used for the problematic comparison, I added "the same" translation to swiotlb_print. I don't understand the results as dend - dstart is vastly larger that pend - pstart.



 void swiotlb_print_info(void)
 {
         unsigned long bytes = io_tlb_nslabs << IO_TLB_SHIFT;
         phys_addr_t pstart, pend;
+        dma_addr_t dstart, dend;
 
+        pstart = virt_to_phys(io_tlb_start);
+        pend = virt_to_phys(io_tlb_end);
+
         dstart = phys_to_machine(XPADDR(pstart)).maddr;
         dend   = phys_to_machine(XPADDR(pend)). maddr;
 
         printk(KERN_INFO "Placing %luMB software IO TLB between %p - %p\n",
                bytes >> 20, io_tlb_start, io_tlb_end);
         printk(KERN_INFO "software IO TLB at phys %#llx - %#llx\n",
                (unsigned long long)pstart,
                 (unsigned long long)pend);
+        printk(KERN_INFO "software IO TLB at bus %#llx - %#llx\n",
+               (unsigned long long)dstart,
+                (unsigned long long)dend);
 }

Yields:
[    0.000000] Placing 64MB software IO TLB between d832cf00 - dc32cf00
[    0.000000] software IO TLB at phys 0x1832cf00 - 0x1c32cf00
[    0.000000] software IO TLB at bus 0x1c0f00 - 0x120fdff00

-----Original Message-----
From: Konrad Rzeszutek Wilk [mailto:konrad.r.wilk@gmail.com] On Behalf Of Konrad Rzeszutek Wilk
Sent: Monday, December 12, 2011 4:19 PM
To: Taylor, Neal E
Cc: xen-devel; Kalev, Leonid; Dave, Tushar N
Subject: Re: [Xen-devel] Buffers not reachable by PCI

On Mon, Dec 12, 2011 at 10:11:20PM +0000, Taylor, Neal E wrote:
> We're having trouble getting a serial log. Are there other ways to capture the information you need?
> 
> Attached is a dmesg with 'debug loglevel 8' set on the kernel line... actually, with  
> 
>    #define DEFAULT_MESSAGE_LOGLEVEL 8
> 
> set near the top of printk.c as well, since I wasn't seeing any difference in the log files with loglevel set to 8.

I needed this:

[    0.000000] Reserving virtual address space above 0xff800000
[    0.000000] Linux version 3.0.4-36.xen0 (root@nt-dev-Cent55-32) (gcc version 4.1.2 20080704 (Red Hat 4.1.2-48)) #1 SMP Mon Dec 12 14:54:39 EST 2011
[    0.000000] released 0 pages of unused memory
[    0.000000] 1-1 mapping on a0->100
[    0.000000] 1-1 mapping on bffc0->100000
[    0.000000] Set 262304 page(s) to 1-1 mapping.
[    0.000000] BIOS-provided physical RAM map:
[    0.000000]  Xen: 0000000000000000 - 00000000000a0000 (usable)
[    0.000000]  Xen: 00000000000a0000 - 0000000000100000 (reserved)
[    0.000000]  Xen: 0000000000100000 - 0000000020000000 (usable)
[    0.000000]  Xen: 0000000020000000 - 00000000bffc0000 (unusable)
[    0.000000]  Xen: 00000000bffc0000 - 00000000bffcfc00 (ACPI data)
[    0.000000]  Xen: 00000000bffcfc00 - 00000000bffff000 (reserved)
[    0.000000]  Xen: 00000000e0000000 - 00000000fec90000 (reserved)
[    0.000000]  Xen: 00000000fed00000 - 00000000fed00400 (reserved)
[    0.000000]  Xen: 00000000fee00000 - 00000000fee10000 (reserved)
[    0.000000]  Xen: 00000000ffb00000 - 0000000100000000 (reserved)
[    0.000000]  Xen: 0000000100000000 - 00000001dffc0000 (usable)
[    0.000000] NX (Execute Disable) protection: active
[    0.000000] DMI 2.3 present.
[    0.000000] DMI: Dell Computer Corporation PowerEdge 1850/0RC130, BIOS A05 01/09/2006
[    0.000000] e820 update range: 0000000000000000 - 0000000000010000 (usable) ==> (reserved)
[    0.000000] e820 remove range: 00000000000a0000 - 0000000000100000 (usable)
[    0.000000] last_pfn = 0x1dffc0 max_arch_pfn = 0x1000000
[    0.000000] found SMP MP-table at [c00fe710] fe710
[    0.000000] initial memory mapped : 0 - 023ff000
[    0.000000] Base memory trampoline at [c009f000] 9f000 size 4096
[    0.000000] init_memory_mapping: 0000000000000000-00000000373fe000
[    0.000000]  0000000000 - 00373fe000 page 4k
[    0.000000] kernel direct mapping tables up to 373fe000 @ 2242000-23ff000
[    0.000000] xen: setting RW the range 23ea000 - 23ff000
[    0.000000] RAMDISK: 016fb000 - 01ab2000
.. snip..
[    0.000000] Placing 64MB software IO TLB between d832cf00 - dc32cf00
[    0.000000] software IO TLB at phys 0x1832cf00 - 0x1c32cf00

And that tells me that 1) it is allocated above the 4GB - which
from a PFN perspectivie is not a big deal, as the MFNs are below 4GB
2), but it messes up the other drivers which expect the SWIOTLB to be
under 4GB.


Try this patch:

diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index 8e964b9..600b53c 100644
--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -166,7 +166,7 @@ retry:
 	/*
 	 * Get IO TLB memory from any location.
 	 */
-	xen_io_tlb_start = alloc_bootmem(bytes);
+	xen_io_tlb_start = alloc_bootmem_low(bytes);
 	if (!xen_io_tlb_start) {
 		m = "Cannot allocate Xen-SWIOTLB buffer!\n";
 		goto error;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 22:19:18 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 22:19:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaagV-0008Q3-Nu; Tue, 13 Dec 2011 22:18:51 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Neal.Taylor@ca.com>) id 1RaagT-0008Pv-P2
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 22:18:50 +0000
X-Env-Sender: Neal.Taylor@ca.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1323814672!7145979!1
X-Originating-IP: [74.125.149.69]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1349 invoked from network); 13 Dec 2011 22:17:54 -0000
Received: from na3sys009aog102.obsmtp.com (HELO na3sys009aog102.obsmtp.com)
	(74.125.149.69)
	by server-3.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Dec 2011 22:17:54 -0000
Received: from USILMS190.ca.com ([141.202.246.44]) (using TLSv1) by
	na3sys009aob102.postini.com ([74.125.148.12]) with SMTP
	ID DSNKTufPD5yX8uqhK2vAQy3QiZ17mYaw0Uao@postini.com;
	Tue, 13 Dec 2011 14:17:53 PST
Received: from USILMS173.ca.com (141.202.6.23) by USILMS190.ca.com
	(141.202.246.44) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Tue, 13 Dec 2011 17:17:51 -0500
Received: from USILMS110A.ca.com ([169.254.1.109]) by usilms173.ca.com
	([141.202.6.23]) with mapi id 14.01.0289.001;
	Tue, 13 Dec 2011 17:17:50 -0500
From: "Taylor, Neal E" <Neal.Taylor@ca.com>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
Thread-Topic: [Xen-devel] Buffers not reachable by PCI
Thread-Index: Acy2r+Ulg1PsfbmtTl6QVj0jZAx7mwAK1xcAAIXl/sAAGPmvgAAhEiCw
Date: Tue, 13 Dec 2011 22:17:50 +0000
Message-ID: <3E243B26F475504B9BB0BCC9728B0DA629E184FA@USILMS110A.ca.com>
References: <3E243B26F475504B9BB0BCC9728B0DA629E16E01@USILMS110A.ca.com>
	<20111209203010.GA14412@andromeda.dapyr.net>
	<3E243B26F475504B9BB0BCC9728B0DA629E17AEA@USILMS110A.ca.com>
	<20111213001912.GA2730@konrad-lan>
In-Reply-To: <20111213001912.GA2730@konrad-lan>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [138.42.46.105]
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>, "Kalev,
	Leonid" <Leonid.Kalev@ca.com>, "Dave, Tushar N" <tushar.n.dave@intel.com>
Subject: Re: [Xen-devel] Buffers not reachable by PCI
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


Is it the translation that's in error?

Modeled after the translation in xen_swiotlb_dma_supported that's used for the problematic comparison, I added "the same" translation to swiotlb_print. I don't understand the results as dend - dstart is vastly larger that pend - pstart.



 void swiotlb_print_info(void)
 {
         unsigned long bytes = io_tlb_nslabs << IO_TLB_SHIFT;
         phys_addr_t pstart, pend;
+        dma_addr_t dstart, dend;
 
+        pstart = virt_to_phys(io_tlb_start);
+        pend = virt_to_phys(io_tlb_end);
+
         dstart = phys_to_machine(XPADDR(pstart)).maddr;
         dend   = phys_to_machine(XPADDR(pend)). maddr;
 
         printk(KERN_INFO "Placing %luMB software IO TLB between %p - %p\n",
                bytes >> 20, io_tlb_start, io_tlb_end);
         printk(KERN_INFO "software IO TLB at phys %#llx - %#llx\n",
                (unsigned long long)pstart,
                 (unsigned long long)pend);
+        printk(KERN_INFO "software IO TLB at bus %#llx - %#llx\n",
+               (unsigned long long)dstart,
+                (unsigned long long)dend);
 }

Yields:
[    0.000000] Placing 64MB software IO TLB between d832cf00 - dc32cf00
[    0.000000] software IO TLB at phys 0x1832cf00 - 0x1c32cf00
[    0.000000] software IO TLB at bus 0x1c0f00 - 0x120fdff00

-----Original Message-----
From: Konrad Rzeszutek Wilk [mailto:konrad.r.wilk@gmail.com] On Behalf Of Konrad Rzeszutek Wilk
Sent: Monday, December 12, 2011 4:19 PM
To: Taylor, Neal E
Cc: xen-devel; Kalev, Leonid; Dave, Tushar N
Subject: Re: [Xen-devel] Buffers not reachable by PCI

On Mon, Dec 12, 2011 at 10:11:20PM +0000, Taylor, Neal E wrote:
> We're having trouble getting a serial log. Are there other ways to capture the information you need?
> 
> Attached is a dmesg with 'debug loglevel 8' set on the kernel line... actually, with  
> 
>    #define DEFAULT_MESSAGE_LOGLEVEL 8
> 
> set near the top of printk.c as well, since I wasn't seeing any difference in the log files with loglevel set to 8.

I needed this:

[    0.000000] Reserving virtual address space above 0xff800000
[    0.000000] Linux version 3.0.4-36.xen0 (root@nt-dev-Cent55-32) (gcc version 4.1.2 20080704 (Red Hat 4.1.2-48)) #1 SMP Mon Dec 12 14:54:39 EST 2011
[    0.000000] released 0 pages of unused memory
[    0.000000] 1-1 mapping on a0->100
[    0.000000] 1-1 mapping on bffc0->100000
[    0.000000] Set 262304 page(s) to 1-1 mapping.
[    0.000000] BIOS-provided physical RAM map:
[    0.000000]  Xen: 0000000000000000 - 00000000000a0000 (usable)
[    0.000000]  Xen: 00000000000a0000 - 0000000000100000 (reserved)
[    0.000000]  Xen: 0000000000100000 - 0000000020000000 (usable)
[    0.000000]  Xen: 0000000020000000 - 00000000bffc0000 (unusable)
[    0.000000]  Xen: 00000000bffc0000 - 00000000bffcfc00 (ACPI data)
[    0.000000]  Xen: 00000000bffcfc00 - 00000000bffff000 (reserved)
[    0.000000]  Xen: 00000000e0000000 - 00000000fec90000 (reserved)
[    0.000000]  Xen: 00000000fed00000 - 00000000fed00400 (reserved)
[    0.000000]  Xen: 00000000fee00000 - 00000000fee10000 (reserved)
[    0.000000]  Xen: 00000000ffb00000 - 0000000100000000 (reserved)
[    0.000000]  Xen: 0000000100000000 - 00000001dffc0000 (usable)
[    0.000000] NX (Execute Disable) protection: active
[    0.000000] DMI 2.3 present.
[    0.000000] DMI: Dell Computer Corporation PowerEdge 1850/0RC130, BIOS A05 01/09/2006
[    0.000000] e820 update range: 0000000000000000 - 0000000000010000 (usable) ==> (reserved)
[    0.000000] e820 remove range: 00000000000a0000 - 0000000000100000 (usable)
[    0.000000] last_pfn = 0x1dffc0 max_arch_pfn = 0x1000000
[    0.000000] found SMP MP-table at [c00fe710] fe710
[    0.000000] initial memory mapped : 0 - 023ff000
[    0.000000] Base memory trampoline at [c009f000] 9f000 size 4096
[    0.000000] init_memory_mapping: 0000000000000000-00000000373fe000
[    0.000000]  0000000000 - 00373fe000 page 4k
[    0.000000] kernel direct mapping tables up to 373fe000 @ 2242000-23ff000
[    0.000000] xen: setting RW the range 23ea000 - 23ff000
[    0.000000] RAMDISK: 016fb000 - 01ab2000
.. snip..
[    0.000000] Placing 64MB software IO TLB between d832cf00 - dc32cf00
[    0.000000] software IO TLB at phys 0x1832cf00 - 0x1c32cf00

And that tells me that 1) it is allocated above the 4GB - which
from a PFN perspectivie is not a big deal, as the MFNs are below 4GB
2), but it messes up the other drivers which expect the SWIOTLB to be
under 4GB.


Try this patch:

diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index 8e964b9..600b53c 100644
--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -166,7 +166,7 @@ retry:
 	/*
 	 * Get IO TLB memory from any location.
 	 */
-	xen_io_tlb_start = alloc_bootmem(bytes);
+	xen_io_tlb_start = alloc_bootmem_low(bytes);
 	if (!xen_io_tlb_start) {
 		m = "Cannot allocate Xen-SWIOTLB buffer!\n";
 		goto error;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 22:31:48 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 22:31:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Raasg-0000PR-2n; Tue, 13 Dec 2011 22:31:26 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Raase-0000PM-8A
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 22:31:24 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1323815429!5438866!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTI1NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30045 invoked from network); 13 Dec 2011 22:30:29 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 22:30:29 -0000
X-IronPort-AV: E=Sophos;i="4.71,349,1320624000"; 
   d="scan'208";a="9450965"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Dec 2011 22:30:28 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 13 Dec 2011 22:30:28 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: George Shuklin <george.shuklin@gmail.com>
In-Reply-To: <4EE7BC9B.6040003@gmail.com>
References: <4EE675A8.3030609@niemail.de>	<4EE71663.5040308@gmail.com>
	<CAJeBh4sxdNTxM_oLFAuA6Mw75=LaYysrpS5b8NsZMbkf_swNVw@mail.gmail.com>
	<4EE72A94.6040904@gmail.com> <4EE75080.1000909@citrix.com>
	<1323783428.20077.298.camel@zakaz.uk.xensource.com>
	<4EE7BC9B.6040003@gmail.com>
Organization: Citrix Systems, Inc.
Date: Tue, 13 Dec 2011 22:30:27 +0000
Message-ID: <1323815427.20936.96.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
X-Mailer: Evolution 2.32.3 
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	David Vrabel <david.vrabel@citrix.com>,
	"sandr8@gmail.com" <sandr8@gmail.com>
Subject: Re: [Xen-devel] a ton of kernel issues
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2011-12-13 at 20:59 +0000, George Shuklin wrote:
> On 13.12.2011 17:37, Ian Campbell wrote:
> >> This should work if memory hotplug is enabled.
> >>
> >> It is also supported without memory hotplug but this requires that the
> >> tools supply a suitable memory map that covers the largest
> >> memory-static-max limit you wish to support.  I'm not sure if the tools
> >> can do this yet.
> > With xl this should work using the "maxmem" option. (xm probably uses
> > the same name)
> >
> I'm not sure what maxmem do

maxmem sets static-max for the guest in the xl toolstack.

> but I can say, this option does not allow 
> to go beyond initial boot memory for pv_ops kernels and beyond 
> static-max memory for -xen kernel.

AFAIK the toolstack support for memory hotplug (i.e. growing beyond
static-max) does not yet exist.

> I tested it with following python script (under xcp, with shutdowned 
> squeezed to be sure not get 'reballanced'):
> 
> xc.domain_setmaxmem(domid,memory)
> xs.write("","/local/domain/%i/memory/dynamic-min"%domid,str(memory*1024))
> xs.write("","/local/domain/%i/memory/dynamic-max"%domid,str(memory*1024))
> xs.write("","/local/domain/%i/memory/static-max"%domid,str(memory*1024))
> xs.write("","/local/domain/%i/memory/target"%domid,str(memory*1024))
> 
> It works fine within noted ranges, but simply ignores any request higher 
> them.

If you are stepping outside the toolstack and doing this sort of thing
behind its back then all bets are off and you can't really expect people
here to help you.

Please try and reproduce the issue using the standard toolstack options.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 22:31:48 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 22:31:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Raasg-0000PR-2n; Tue, 13 Dec 2011 22:31:26 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Raase-0000PM-8A
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 22:31:24 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1323815429!5438866!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTI1NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30045 invoked from network); 13 Dec 2011 22:30:29 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 22:30:29 -0000
X-IronPort-AV: E=Sophos;i="4.71,349,1320624000"; 
   d="scan'208";a="9450965"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Dec 2011 22:30:28 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 13 Dec 2011 22:30:28 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: George Shuklin <george.shuklin@gmail.com>
In-Reply-To: <4EE7BC9B.6040003@gmail.com>
References: <4EE675A8.3030609@niemail.de>	<4EE71663.5040308@gmail.com>
	<CAJeBh4sxdNTxM_oLFAuA6Mw75=LaYysrpS5b8NsZMbkf_swNVw@mail.gmail.com>
	<4EE72A94.6040904@gmail.com> <4EE75080.1000909@citrix.com>
	<1323783428.20077.298.camel@zakaz.uk.xensource.com>
	<4EE7BC9B.6040003@gmail.com>
Organization: Citrix Systems, Inc.
Date: Tue, 13 Dec 2011 22:30:27 +0000
Message-ID: <1323815427.20936.96.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
X-Mailer: Evolution 2.32.3 
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	David Vrabel <david.vrabel@citrix.com>,
	"sandr8@gmail.com" <sandr8@gmail.com>
Subject: Re: [Xen-devel] a ton of kernel issues
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2011-12-13 at 20:59 +0000, George Shuklin wrote:
> On 13.12.2011 17:37, Ian Campbell wrote:
> >> This should work if memory hotplug is enabled.
> >>
> >> It is also supported without memory hotplug but this requires that the
> >> tools supply a suitable memory map that covers the largest
> >> memory-static-max limit you wish to support.  I'm not sure if the tools
> >> can do this yet.
> > With xl this should work using the "maxmem" option. (xm probably uses
> > the same name)
> >
> I'm not sure what maxmem do

maxmem sets static-max for the guest in the xl toolstack.

> but I can say, this option does not allow 
> to go beyond initial boot memory for pv_ops kernels and beyond 
> static-max memory for -xen kernel.

AFAIK the toolstack support for memory hotplug (i.e. growing beyond
static-max) does not yet exist.

> I tested it with following python script (under xcp, with shutdowned 
> squeezed to be sure not get 'reballanced'):
> 
> xc.domain_setmaxmem(domid,memory)
> xs.write("","/local/domain/%i/memory/dynamic-min"%domid,str(memory*1024))
> xs.write("","/local/domain/%i/memory/dynamic-max"%domid,str(memory*1024))
> xs.write("","/local/domain/%i/memory/static-max"%domid,str(memory*1024))
> xs.write("","/local/domain/%i/memory/target"%domid,str(memory*1024))
> 
> It works fine within noted ranges, but simply ignores any request higher 
> them.

If you are stepping outside the toolstack and doing this sort of thing
behind its back then all bets are off and you can't really expect people
here to help you.

Please try and reproduce the issue using the standard toolstack options.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 22:54:32 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 22:54:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RabEg-0001W8-2B; Tue, 13 Dec 2011 22:54:10 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <george.shuklin@gmail.com>) id 1RabEe-0001Vy-Tp
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 22:54:09 +0000
X-Env-Sender: george.shuklin@gmail.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1323816780!49163960!1
X-Originating-IP: [74.125.82.41]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5903 invoked from network); 13 Dec 2011 22:53:00 -0000
Received: from mail-ww0-f41.google.com (HELO mail-ww0-f41.google.com)
	(74.125.82.41)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 22:53:00 -0000
Received: by wgbdt12 with SMTP id dt12so134043wgb.0
	for <xen-devel@lists.xensource.com>;
	Tue, 13 Dec 2011 14:53:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=message-id:date:from:user-agent:mime-version:to:cc:subject
	:references:in-reply-to:content-type:content-transfer-encoding;
	bh=gUv1B8lhtzFvZvIPiwsgORPoyKiJbI0EgTPDW5kSknc=;
	b=I4lDMaDEqY9Yg+Q3TiBlHkPVEnkYP4zvLYamCVJ6Ce7fcCea4iYPJ+2JnwJqkAPz4O
	w2+8rpJrVx8wI9aUMMFJD8QLm155dR0zVnTfGV4AwbseTRpboWuft+yDJt7e4m9TG4iH
	B9YfBMfV7Q3KW3shyLiOBfWbj6/Oaq1kmMGVs=
Received: by 10.180.104.35 with SMTP id gb3mr777536wib.11.1323816798801;
	Tue, 13 Dec 2011 14:53:18 -0800 (PST)
Received: from [192.168.0.220] (desunote.ru. [95.161.2.76])
	by mx.google.com with ESMTPS id bl10sm779173wib.15.2011.12.13.14.53.17
	(version=SSLv3 cipher=OTHER); Tue, 13 Dec 2011 14:53:17 -0800 (PST)
Message-ID: <4EE7D75B.6080209@gmail.com>
Date: Wed, 14 Dec 2011 02:53:15 +0400
From: George Shuklin <george.shuklin@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:9.0) Gecko/20111209 Thunderbird/9.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <4EE675A8.3030609@niemail.de>	<4EE71663.5040308@gmail.com>
	<CAJeBh4sxdNTxM_oLFAuA6Mw75=LaYysrpS5b8NsZMbkf_swNVw@mail.gmail.com>
	<4EE72A94.6040904@gmail.com> <4EE75080.1000909@citrix.com>
	<1323783428.20077.298.camel@zakaz.uk.xensource.com>
	<4EE7BC9B.6040003@gmail.com>
	<1323815427.20936.96.camel@dagon.hellion.org.uk>
In-Reply-To: <1323815427.20936.96.camel@dagon.hellion.org.uk>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	David Vrabel <david.vrabel@citrix.com>,
	"sandr8@gmail.com" <sandr8@gmail.com>
Subject: Re: [Xen-devel] a ton of kernel issues
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 14.12.2011 02:30, Ian Campbell wrote:
> On Tue, 2011-12-13 at 20:59 +0000, George Shuklin wrote:
>> On 13.12.2011 17:37, Ian Campbell wrote:
>>>> This should work if memory hotplug is enabled.
>>>>
>>>> It is also supported without memory hotplug but this requires that the
>>>> tools supply a suitable memory map that covers the largest
>>>> memory-static-max limit you wish to support.  I'm not sure if the tools
>>>> can do this yet.
>>> With xl this should work using the "maxmem" option. (xm probably uses
>>> the same name)
>>>
>> I'm not sure what maxmem do
> maxmem sets static-max for the guest in the xl toolstack.

Well, I understand that, I simply don't understand what maxmem do with 
domain in xen (the hypervisor part). My hypothesis is just put a limit 
for amount of allocated PFN for domain.

>
>> but I can say, this option does not allow
>> to go beyond initial boot memory for pv_ops kernels and beyond
>> static-max memory for -xen kernel.
> AFAIK the toolstack support for memory hotplug (i.e. growing beyond
> static-max) does not yet exist.

As far as I know toolstack is not really do some work for this (if I 
wrong I'll be really appreciated for information). For memory control we 
need to set maxmem and send request to guest xenballon for new target 
(via xenstore). This works without running xapi and squeezed (of course, 
for VM start/reboot we need them), but simple memory management can be 
done manually without helps of xapi/squeezed. (Again, if I wrong, I do 
really like to now where I wrong).  As far as I understand xapi writing 
dynamic-min, dynamic-max to xenstore for domain and call squeezed via 
xenstore-rpc to rebalance memory, and squeezed read request, read those 
values, calculate new target and writes it  to xenstore for each domain.

My current description (I can be wrong) of stuff happens during memory 
resizing:
1) Set up maxmem
2) Send via memory/target target to xenballoon
3) Xenballoon request new  memory from hypervisor (or return back some of)
4) Xenballoon manipulate with domU memory management to allow use (or 
snatch away) memory pages.
>> I tested it with following python script (under xcp, with shutdowned
>> squeezed to be sure not get 'reballanced'):
>>
>> xc.domain_setmaxmem(domid,memory)
>> xs.write("","/local/domain/%i/memory/dynamic-min"%domid,str(memory*1024))
>> xs.write("","/local/domain/%i/memory/dynamic-max"%domid,str(memory*1024))
>> xs.write("","/local/domain/%i/memory/static-max"%domid,str(memory*1024))
>> xs.write("","/local/domain/%i/memory/target"%domid,str(memory*1024))
>>
>> It works fine within noted ranges, but simply ignores any request higher
>> them.
> If you are stepping outside the toolstack and doing this sort of thing
> behind its back then all bets are off and you can't really expect people
> here to help you.
>
> Please try and reproduce the issue using the standard toolstack options.
>
I am very well understand that, so I've tested this (not with all kernel 
versions) with normal XCP setup with default memory management:
set up vm, make dyn-max=1GiB,static-max=2GiB, start vm, use xe 
vm-memory-target-set to 2GiB - and memory is still 1GiB.
I've tested this with few pv_ops kernels, including those on 
xs-tools.iso (tested on XCP 0.5, 1.0 and 1.1, and even on XenServer 6) - 
same result.


P.S. Thank you for your attention to this issue.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 22:54:32 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 22:54:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RabEg-0001W8-2B; Tue, 13 Dec 2011 22:54:10 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <george.shuklin@gmail.com>) id 1RabEe-0001Vy-Tp
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 22:54:09 +0000
X-Env-Sender: george.shuklin@gmail.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1323816780!49163960!1
X-Originating-IP: [74.125.82.41]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5903 invoked from network); 13 Dec 2011 22:53:00 -0000
Received: from mail-ww0-f41.google.com (HELO mail-ww0-f41.google.com)
	(74.125.82.41)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 22:53:00 -0000
Received: by wgbdt12 with SMTP id dt12so134043wgb.0
	for <xen-devel@lists.xensource.com>;
	Tue, 13 Dec 2011 14:53:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=message-id:date:from:user-agent:mime-version:to:cc:subject
	:references:in-reply-to:content-type:content-transfer-encoding;
	bh=gUv1B8lhtzFvZvIPiwsgORPoyKiJbI0EgTPDW5kSknc=;
	b=I4lDMaDEqY9Yg+Q3TiBlHkPVEnkYP4zvLYamCVJ6Ce7fcCea4iYPJ+2JnwJqkAPz4O
	w2+8rpJrVx8wI9aUMMFJD8QLm155dR0zVnTfGV4AwbseTRpboWuft+yDJt7e4m9TG4iH
	B9YfBMfV7Q3KW3shyLiOBfWbj6/Oaq1kmMGVs=
Received: by 10.180.104.35 with SMTP id gb3mr777536wib.11.1323816798801;
	Tue, 13 Dec 2011 14:53:18 -0800 (PST)
Received: from [192.168.0.220] (desunote.ru. [95.161.2.76])
	by mx.google.com with ESMTPS id bl10sm779173wib.15.2011.12.13.14.53.17
	(version=SSLv3 cipher=OTHER); Tue, 13 Dec 2011 14:53:17 -0800 (PST)
Message-ID: <4EE7D75B.6080209@gmail.com>
Date: Wed, 14 Dec 2011 02:53:15 +0400
From: George Shuklin <george.shuklin@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:9.0) Gecko/20111209 Thunderbird/9.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <4EE675A8.3030609@niemail.de>	<4EE71663.5040308@gmail.com>
	<CAJeBh4sxdNTxM_oLFAuA6Mw75=LaYysrpS5b8NsZMbkf_swNVw@mail.gmail.com>
	<4EE72A94.6040904@gmail.com> <4EE75080.1000909@citrix.com>
	<1323783428.20077.298.camel@zakaz.uk.xensource.com>
	<4EE7BC9B.6040003@gmail.com>
	<1323815427.20936.96.camel@dagon.hellion.org.uk>
In-Reply-To: <1323815427.20936.96.camel@dagon.hellion.org.uk>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	David Vrabel <david.vrabel@citrix.com>,
	"sandr8@gmail.com" <sandr8@gmail.com>
Subject: Re: [Xen-devel] a ton of kernel issues
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 14.12.2011 02:30, Ian Campbell wrote:
> On Tue, 2011-12-13 at 20:59 +0000, George Shuklin wrote:
>> On 13.12.2011 17:37, Ian Campbell wrote:
>>>> This should work if memory hotplug is enabled.
>>>>
>>>> It is also supported without memory hotplug but this requires that the
>>>> tools supply a suitable memory map that covers the largest
>>>> memory-static-max limit you wish to support.  I'm not sure if the tools
>>>> can do this yet.
>>> With xl this should work using the "maxmem" option. (xm probably uses
>>> the same name)
>>>
>> I'm not sure what maxmem do
> maxmem sets static-max for the guest in the xl toolstack.

Well, I understand that, I simply don't understand what maxmem do with 
domain in xen (the hypervisor part). My hypothesis is just put a limit 
for amount of allocated PFN for domain.

>
>> but I can say, this option does not allow
>> to go beyond initial boot memory for pv_ops kernels and beyond
>> static-max memory for -xen kernel.
> AFAIK the toolstack support for memory hotplug (i.e. growing beyond
> static-max) does not yet exist.

As far as I know toolstack is not really do some work for this (if I 
wrong I'll be really appreciated for information). For memory control we 
need to set maxmem and send request to guest xenballon for new target 
(via xenstore). This works without running xapi and squeezed (of course, 
for VM start/reboot we need them), but simple memory management can be 
done manually without helps of xapi/squeezed. (Again, if I wrong, I do 
really like to now where I wrong).  As far as I understand xapi writing 
dynamic-min, dynamic-max to xenstore for domain and call squeezed via 
xenstore-rpc to rebalance memory, and squeezed read request, read those 
values, calculate new target and writes it  to xenstore for each domain.

My current description (I can be wrong) of stuff happens during memory 
resizing:
1) Set up maxmem
2) Send via memory/target target to xenballoon
3) Xenballoon request new  memory from hypervisor (or return back some of)
4) Xenballoon manipulate with domU memory management to allow use (or 
snatch away) memory pages.
>> I tested it with following python script (under xcp, with shutdowned
>> squeezed to be sure not get 'reballanced'):
>>
>> xc.domain_setmaxmem(domid,memory)
>> xs.write("","/local/domain/%i/memory/dynamic-min"%domid,str(memory*1024))
>> xs.write("","/local/domain/%i/memory/dynamic-max"%domid,str(memory*1024))
>> xs.write("","/local/domain/%i/memory/static-max"%domid,str(memory*1024))
>> xs.write("","/local/domain/%i/memory/target"%domid,str(memory*1024))
>>
>> It works fine within noted ranges, but simply ignores any request higher
>> them.
> If you are stepping outside the toolstack and doing this sort of thing
> behind its back then all bets are off and you can't really expect people
> here to help you.
>
> Please try and reproduce the issue using the standard toolstack options.
>
I am very well understand that, so I've tested this (not with all kernel 
versions) with normal XCP setup with default memory management:
set up vm, make dyn-max=1GiB,static-max=2GiB, start vm, use xe 
vm-memory-target-set to 2GiB - and memory is still 1GiB.
I've tested this with few pv_ops kernels, including those on 
xs-tools.iso (tested on XCP 0.5, 1.0 and 1.1, and even on XenServer 6) - 
same result.


P.S. Thank you for your attention to this issue.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 23:29:33 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 23:29:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RabmU-0002NF-OG; Tue, 13 Dec 2011 23:29:06 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.r.wilk@gmail.com>) id 1RabmS-0002N7-JD
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 23:29:04 +0000
X-Env-Sender: konrad.r.wilk@gmail.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1323818888!7361616!1
X-Originating-IP: [209.85.216.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3505 invoked from network); 13 Dec 2011 23:28:09 -0000
Received: from mail-qy0-f171.google.com (HELO mail-qy0-f171.google.com)
	(209.85.216.171)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 23:28:09 -0000
Received: by qcsc20 with SMTP id c20so1237519qcs.30
	for <xen-devel@lists.xensource.com>;
	Tue, 13 Dec 2011 15:28:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:date:from:to:cc:subject:message-id:references:mime-version
	:content-type:content-disposition:in-reply-to:user-agent;
	bh=vstriwvsOiy8PI8OlnQ13/+wYUOeCVcFcO9vpT1wfy4=;
	b=pnhSFO8BLZhpjtIMhVHRy1zodnxh7MrMS5tj8RzT0t5xE36x8fBguN6BSxD587S1Fc
	NL64Om6I/Sxb39scf/g13UPeEMh1QG57gDSDUqQ3wlE9VityWopJQIwJg8hiyEtHEhH0
	u2AG3tmHpvurRhYaEjNkFBy3JERbdI+dWa0FM=
Received: by 10.229.76.217 with SMTP id d25mr1931409qck.146.1323818888503;
	Tue, 13 Dec 2011 15:28:08 -0800 (PST)
Received: from konrad-lan (209-6-85-33.c3-0.smr-ubr2.sbo-smr.ma.cable.rcn.com.
	[209.6.85.33])
	by mx.google.com with ESMTPS id gg6sm1444896qab.3.2011.12.13.15.28.07
	(version=TLSv1/SSLv3 cipher=OTHER);
	Tue, 13 Dec 2011 15:28:07 -0800 (PST)
Date: Tue, 13 Dec 2011 18:28:00 -0500
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: "Taylor, Neal E" <Neal.Taylor@ca.com>
Message-ID: <20111213232759.GA8702@konrad-lan>
References: <3E243B26F475504B9BB0BCC9728B0DA629E16E01@USILMS110A.ca.com>
	<20111209203010.GA14412@andromeda.dapyr.net>
	<3E243B26F475504B9BB0BCC9728B0DA629E17AEA@USILMS110A.ca.com>
	<20111213001912.GA2730@konrad-lan>
	<3E243B26F475504B9BB0BCC9728B0DA629E184FA@USILMS110A.ca.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <3E243B26F475504B9BB0BCC9728B0DA629E184FA@USILMS110A.ca.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: xen-devel <xen-devel@lists.xensource.com>, "Kalev,
	Leonid" <Leonid.Kalev@ca.com>, "Dave, Tushar N" <tushar.n.dave@intel.com>
Subject: Re: [Xen-devel] Buffers not reachable by PCI
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Dec 13, 2011 at 10:17:50PM +0000, Taylor, Neal E wrote:
> 
> Is it the translation that's in error?
> 
> Modeled after the translation in xen_swiotlb_dma_supported that's used for the problematic comparison, I added "the same" translation to swiotlb_print. I don't understand the results as dend - dstart is vastly larger that pend - pstart.

You might want to instrument the xen_swiotlb_fixup code to get an idea.

But basically there are "chunks" of 2MB (I think) of contingous memory
that is swizzled in to the memory that starts at io_tlb_start. But
all of that memory SHOULD be under the 4GB limit (set by max_dma_bits).

Sadly in your case one of those "chunks" ends up being past the 4GB
limit - which should never happen. Or if it did happen it would print
out "Failed to get contiguous memory for DMA from.."

But you don't get any of that.


To get a good idea of this, you could do something like this

unsigned long mfn, next_mfn;

mfn= PFN_DOWN(phys_to_machine(XPADDR(pstart)).maddr);

for (i = pstart; i < pend;) {
	next_mfn = PFN_DOWN(phys_to_machine(XPADDR(i)).maddr);
	if (next_mfn == mfn+1) {
		mfn++;
	} else {
		printk(KERN_INFO "MFN 0x%lx->0x%lx\n", mfn, next_mfn);
		mfn = next_mfn;
	}
	i+=PAGE_SIZE;
}

which should print you those "chunks", if my logic here is right.


Can you send me your 'xl info' (or 'xl dmesg'), please?

I tried to reproduce this with a 3.0.4 kernel on a 8GB and I couldn't
reproduce this. Hm, will look in your .config in case there is something
funky there.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 13 23:29:33 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 Dec 2011 23:29:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RabmU-0002NF-OG; Tue, 13 Dec 2011 23:29:06 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.r.wilk@gmail.com>) id 1RabmS-0002N7-JD
	for xen-devel@lists.xensource.com; Tue, 13 Dec 2011 23:29:04 +0000
X-Env-Sender: konrad.r.wilk@gmail.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1323818888!7361616!1
X-Originating-IP: [209.85.216.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3505 invoked from network); 13 Dec 2011 23:28:09 -0000
Received: from mail-qy0-f171.google.com (HELO mail-qy0-f171.google.com)
	(209.85.216.171)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2011 23:28:09 -0000
Received: by qcsc20 with SMTP id c20so1237519qcs.30
	for <xen-devel@lists.xensource.com>;
	Tue, 13 Dec 2011 15:28:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:date:from:to:cc:subject:message-id:references:mime-version
	:content-type:content-disposition:in-reply-to:user-agent;
	bh=vstriwvsOiy8PI8OlnQ13/+wYUOeCVcFcO9vpT1wfy4=;
	b=pnhSFO8BLZhpjtIMhVHRy1zodnxh7MrMS5tj8RzT0t5xE36x8fBguN6BSxD587S1Fc
	NL64Om6I/Sxb39scf/g13UPeEMh1QG57gDSDUqQ3wlE9VityWopJQIwJg8hiyEtHEhH0
	u2AG3tmHpvurRhYaEjNkFBy3JERbdI+dWa0FM=
Received: by 10.229.76.217 with SMTP id d25mr1931409qck.146.1323818888503;
	Tue, 13 Dec 2011 15:28:08 -0800 (PST)
Received: from konrad-lan (209-6-85-33.c3-0.smr-ubr2.sbo-smr.ma.cable.rcn.com.
	[209.6.85.33])
	by mx.google.com with ESMTPS id gg6sm1444896qab.3.2011.12.13.15.28.07
	(version=TLSv1/SSLv3 cipher=OTHER);
	Tue, 13 Dec 2011 15:28:07 -0800 (PST)
Date: Tue, 13 Dec 2011 18:28:00 -0500
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: "Taylor, Neal E" <Neal.Taylor@ca.com>
Message-ID: <20111213232759.GA8702@konrad-lan>
References: <3E243B26F475504B9BB0BCC9728B0DA629E16E01@USILMS110A.ca.com>
	<20111209203010.GA14412@andromeda.dapyr.net>
	<3E243B26F475504B9BB0BCC9728B0DA629E17AEA@USILMS110A.ca.com>
	<20111213001912.GA2730@konrad-lan>
	<3E243B26F475504B9BB0BCC9728B0DA629E184FA@USILMS110A.ca.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <3E243B26F475504B9BB0BCC9728B0DA629E184FA@USILMS110A.ca.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: xen-devel <xen-devel@lists.xensource.com>, "Kalev,
	Leonid" <Leonid.Kalev@ca.com>, "Dave, Tushar N" <tushar.n.dave@intel.com>
Subject: Re: [Xen-devel] Buffers not reachable by PCI
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Dec 13, 2011 at 10:17:50PM +0000, Taylor, Neal E wrote:
> 
> Is it the translation that's in error?
> 
> Modeled after the translation in xen_swiotlb_dma_supported that's used for the problematic comparison, I added "the same" translation to swiotlb_print. I don't understand the results as dend - dstart is vastly larger that pend - pstart.

You might want to instrument the xen_swiotlb_fixup code to get an idea.

But basically there are "chunks" of 2MB (I think) of contingous memory
that is swizzled in to the memory that starts at io_tlb_start. But
all of that memory SHOULD be under the 4GB limit (set by max_dma_bits).

Sadly in your case one of those "chunks" ends up being past the 4GB
limit - which should never happen. Or if it did happen it would print
out "Failed to get contiguous memory for DMA from.."

But you don't get any of that.


To get a good idea of this, you could do something like this

unsigned long mfn, next_mfn;

mfn= PFN_DOWN(phys_to_machine(XPADDR(pstart)).maddr);

for (i = pstart; i < pend;) {
	next_mfn = PFN_DOWN(phys_to_machine(XPADDR(i)).maddr);
	if (next_mfn == mfn+1) {
		mfn++;
	} else {
		printk(KERN_INFO "MFN 0x%lx->0x%lx\n", mfn, next_mfn);
		mfn = next_mfn;
	}
	i+=PAGE_SIZE;
}

which should print you those "chunks", if my logic here is right.


Can you send me your 'xl info' (or 'xl dmesg'), please?

I tried to reproduce this with a 3.0.4 kernel on a 8GB and I couldn't
reproduce this. Hm, will look in your .config in case there is something
funky there.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 00:39:43 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 00:39:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RacsF-0003YZ-M1; Wed, 14 Dec 2011 00:39:07 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Neal.Taylor@ca.com>) id 1RacsD-0003YR-V2
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 00:39:06 +0000
X-Env-Sender: Neal.Taylor@ca.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1323823052!46596926!1
X-Originating-IP: [74.125.149.76]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1821 invoked from network); 14 Dec 2011 00:37:35 -0000
Received: from na3sys009aob106.obsmtp.com (HELO na3sys009aog106.obsmtp.com)
	(74.125.149.76)
	by server-5.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Dec 2011 00:37:35 -0000
Received: from USILMS190.ca.com ([141.202.246.44]) (using TLSv1) by
	na3sys009aob106.postini.com ([74.125.148.12]) with SMTP
	ID DSNKTufv9CghxTkQbQTblc+LqbCcazw6k+gD@postini.com;
	Tue, 13 Dec 2011 16:38:13 PST
Received: from USILMS171.ca.com (141.202.6.21) by USILMS190.ca.com
	(141.202.246.44) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Tue, 13 Dec 2011 19:38:11 -0500
Received: from USILMS110A.ca.com ([169.254.1.109]) by USILMS171.ca.com
	([141.202.6.21]) with mapi id 14.01.0289.001;
	Tue, 13 Dec 2011 19:38:10 -0500
From: "Taylor, Neal E" <Neal.Taylor@ca.com>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
Thread-Topic: [Xen-devel] Buffers not reachable by PCI
Thread-Index: Acy2r+Ulg1PsfbmtTl6QVj0jZAx7mwAK1xcAAIXl/sAAGPmvgAAhEiCwAA9ukQAACILlsA==
Date: Wed, 14 Dec 2011 00:38:09 +0000
Message-ID: <3E243B26F475504B9BB0BCC9728B0DA629E18564@USILMS110A.ca.com>
References: <3E243B26F475504B9BB0BCC9728B0DA629E16E01@USILMS110A.ca.com>
	<20111209203010.GA14412@andromeda.dapyr.net>
	<3E243B26F475504B9BB0BCC9728B0DA629E17AEA@USILMS110A.ca.com>
	<20111213001912.GA2730@konrad-lan>
	<3E243B26F475504B9BB0BCC9728B0DA629E184FA@USILMS110A.ca.com>
	<20111213232759.GA8702@konrad-lan>
In-Reply-To: <20111213232759.GA8702@konrad-lan>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [138.42.46.105]
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>, "Kalev,
	Leonid" <Leonid.Kalev@ca.com>, "Dave, Tushar N" <tushar.n.dave@intel.com>
Subject: Re: [Xen-devel] Buffers not reachable by PCI
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Instrumentation results:

[    0.000000] MFN 0x1c0->0x1c0
[    0.000000] MFN 0x1ff->0x180
[    0.000000] MFN 0x1bf->0x140
[    0.000000] MFN 0x17f->0x100
[    0.000000] MFN 0x13f->0x3c0
[    0.000000] MFN 0x3ff->0x380
[    0.000000] MFN 0x3bf->0x340
[    0.000000] MFN 0x37f->0x300
[    0.000000] MFN 0x33f->0x2c0
[    0.000000] MFN 0x2ff->0x280
[    0.000000] MFN 0x2bf->0x240
[    0.000000] MFN 0x27f->0x200
[    0.000000] MFN 0x23f->0x7c0
[    0.000000] MFN 0x7ff->0x780
[    0.000000] MFN 0x7bf->0x740
[    0.000000] MFN 0x77f->0x700
[    0.000000] MFN 0x73f->0x6c0
[    0.000000] MFN 0x6ff->0x680
[    0.000000] MFN 0x6bf->0x640
[    0.000000] MFN 0x67f->0x600
[    0.000000] MFN 0x63f->0x5c0
[    0.000000] MFN 0x5ff->0x580
[    0.000000] MFN 0x5bf->0x540
[    0.000000] MFN 0x57f->0x500
[    0.000000] MFN 0x53f->0x4c0
[    0.000000] MFN 0x4ff->0x480
[    0.000000] MFN 0x4bf->0x440
[    0.000000] MFN 0x47f->0x400
[    0.000000] MFN 0x43f->0xfc0
[    0.000000] MFN 0xfff->0xf80
[    0.000000] MFN 0xfbf->0xf40
[    0.000000] MFN 0xf7f->0xf00
[    0.000000] MFN 0xf3f->0xec0
[    0.000000] MFN 0xeff->0xe80
[    0.000000] MFN 0xebf->0xe40
[    0.000000] MFN 0xe7f->0xe00
[    0.000000] MFN 0xe3f->0xdc0
[    0.000000] MFN 0xdff->0xd80
[    0.000000] MFN 0xdbf->0xd40
[    0.000000] MFN 0xd7f->0xd00
[    0.000000] MFN 0xd3f->0xcc0
[    0.000000] MFN 0xcff->0xc80
[    0.000000] MFN 0xcbf->0xc40
[    0.000000] MFN 0xc7f->0xc00
[    0.000000] MFN 0xc3f->0xbc0
[    0.000000] MFN 0xbff->0xb80
[    0.000000] MFN 0xbbf->0xb40
[    0.000000] MFN 0xb7f->0xb00
[    0.000000] MFN 0xb3f->0xac0
[    0.000000] MFN 0xaff->0xa80
[    0.000000] MFN 0xabf->0xa40
[    0.000000] MFN 0xa7f->0xa00
[    0.000000] MFN 0xa3f->0x9c0
[    0.000000] MFN 0x9ff->0x980
[    0.000000] MFN 0x9bf->0x940
[    0.000000] MFN 0x97f->0x900
[    0.000000] MFN 0x93f->0x8c0
[    0.000000] MFN 0x8ff->0x880
[    0.000000] MFN 0x8bf->0x840
[    0.000000] MFN 0x87f->0x800
[    0.000000] MFN 0x83f->0x1fc0
[    0.000000] MFN 0x1fff->0x1f80
[    0.000000] MFN 0x1fbf->0x1f40
[    0.000000] MFN 0x1f7f->0x1f00
[    0.000000] MFN 0x1f3f->0x1ec0
[    0.000000] MFN 0x1eff->0x1e80
[    0.000000] MFN 0x1ebf->0x1e40
[    0.000000] MFN 0x1e7f->0x1e00
[    0.000000] MFN 0x1e3f->0x1dc0
[    0.000000] MFN 0x1dff->0x1d80
[    0.000000] MFN 0x1dbf->0x1d40
[    0.000000] MFN 0x1d7f->0x1d00
[    0.000000] MFN 0x1d3f->0x1cc0
[    0.000000] MFN 0x1cff->0x1c80
[    0.000000] MFN 0x1cbf->0x1c40
[    0.000000] MFN 0x1c7f->0x1c00
[    0.000000] MFN 0x1c3f->0x1bc0
[    0.000000] MFN 0x1bff->0x1b80
[    0.000000] MFN 0x1bbf->0x1b40
[    0.000000] MFN 0x1b7f->0x1b00
[    0.000000] MFN 0x1b3f->0x1ac0
[    0.000000] MFN 0x1aff->0x1a80
[    0.000000] MFN 0x1abf->0x1a40
[    0.000000] MFN 0x1a7f->0x1a00
[    0.000000] MFN 0x1a3f->0x19c0
[    0.000000] MFN 0x19ff->0x1980
[    0.000000] MFN 0x19bf->0x1940
[    0.000000] MFN 0x197f->0x1900
[    0.000000] MFN 0x193f->0x18c0
[    0.000000] MFN 0x18ff->0x1880
[    0.000000] MFN 0x18bf->0x1840
[    0.000000] MFN 0x187f->0x1800
[    0.000000] MFN 0x183f->0x17c0
[    0.000000] MFN 0x17ff->0x1780
[    0.000000] MFN 0x17bf->0x1740
[    0.000000] MFN 0x177f->0x1700
[    0.000000] MFN 0x173f->0x16c0
[    0.000000] MFN 0x16ff->0x1680
[    0.000000] MFN 0x16bf->0x1640
[    0.000000] MFN 0x167f->0x1600
[    0.000000] MFN 0x163f->0x15c0
[    0.000000] MFN 0x15ff->0x1580
[    0.000000] MFN 0x15bf->0x1540
[    0.000000] MFN 0x157f->0x1500
[    0.000000] MFN 0x153f->0x14c0
[    0.000000] MFN 0x14ff->0x1480
[    0.000000] MFN 0x14bf->0x1440
[    0.000000] MFN 0x147f->0x1400
[    0.000000] MFN 0x143f->0x13c0
[    0.000000] MFN 0x13ff->0x1380
[    0.000000] MFN 0x13bf->0x1340
[    0.000000] MFN 0x137f->0x1300
[    0.000000] MFN 0x133f->0x12c0
[    0.000000] MFN 0x12ff->0x1280
[    0.000000] MFN 0x12bf->0x1240
[    0.000000] MFN 0x127f->0x1200
[    0.000000] MFN 0x123f->0x11c0
[    0.000000] MFN 0x11ff->0x1180
[    0.000000] MFN 0x11bf->0x1140
[    0.000000] MFN 0x117f->0x1100
[    0.000000] MFN 0x113f->0x10c0
[    0.000000] MFN 0x10ff->0x1080
[    0.000000] MFN 0x10bf->0x1040
[    0.000000] MFN 0x107f->0x1000
[    0.000000] MFN 0x103f->0x3fc0
[    0.000000] MFN 0x3fff->0x3f80
[    0.000000] MFN 0x3fbf->0x3f40
[    0.000000] MFN 0x3f7f->0x3f00
[    0.000000] MFN 0x3f3f->0x3ec0
[    0.000000] MFN 0x3eff->0x3e80
[    0.000000] MFN 0x3ebf->0x3e40
[    0.000000] MFN 0x3e7f->0x3e00
[    0.000000] MFN 0x3e3f->0x3dc0
[    0.000000] MFN 0x3dff->0x3d80
[    0.000000] MFN 0x3dbf->0x3d40
[    0.000000] MFN 0x3d7f->0x3d00
[    0.000000] MFN 0x3d3f->0x3cc0
[    0.000000] MFN 0x3cff->0x3c80
[    0.000000] MFN 0x3cbf->0x3c40
[    0.000000] MFN 0x3c7f->0x3c00
[    0.000000] MFN 0x3c3f->0x3bc0
[    0.000000] MFN 0x3bff->0x3b80
[    0.000000] MFN 0x3bbf->0x3b40
[    0.000000] MFN 0x3b7f->0x3b00
[    0.000000] MFN 0x3b3f->0x3ac0
[    0.000000] MFN 0x3aff->0x3a80
[    0.000000] MFN 0x3abf->0x3a40
[    0.000000] MFN 0x3a7f->0x3a00
[    0.000000] MFN 0x3a3f->0x39c0
[    0.000000] MFN 0x39ff->0x3980
[    0.000000] MFN 0x39bf->0x3940
[    0.000000] MFN 0x397f->0x3900
[    0.000000] MFN 0x393f->0x38c0
[    0.000000] MFN 0x38ff->0x3880
[    0.000000] MFN 0x38bf->0x3840
[    0.000000] MFN 0x387f->0x3800
[    0.000000] MFN 0x383f->0x37c0
[    0.000000] MFN 0x37ff->0x3780
[    0.000000] MFN 0x37bf->0x3740
[    0.000000] MFN 0x377f->0x3700
[    0.000000] MFN 0x373f->0x36c0
[    0.000000] MFN 0x36ff->0x3680
[    0.000000] MFN 0x36bf->0x3640
[    0.000000] MFN 0x367f->0x3600
[    0.000000] MFN 0x363f->0x35c0
[    0.000000] MFN 0x35ff->0x3580
[    0.000000] MFN 0x35bf->0x3540
[    0.000000] MFN 0x357f->0x3500
[    0.000000] MFN 0x353f->0x34c0
[    0.000000] MFN 0x34ff->0x3480
[    0.000000] MFN 0x34bf->0x3440
[    0.000000] MFN 0x347f->0x3400
[    0.000000] MFN 0x343f->0x33c0
[    0.000000] MFN 0x33ff->0x3380
[    0.000000] MFN 0x33bf->0x3340
[    0.000000] MFN 0x337f->0x3300
[    0.000000] MFN 0x333f->0x32c0
[    0.000000] MFN 0x32ff->0x3280
[    0.000000] MFN 0x32bf->0x3240
[    0.000000] MFN 0x327f->0x3200
[    0.000000] MFN 0x323f->0x31c0
[    0.000000] MFN 0x31ff->0x3180
[    0.000000] MFN 0x31bf->0x3140
[    0.000000] MFN 0x317f->0x3100
[    0.000000] MFN 0x313f->0x30c0
[    0.000000] MFN 0x30ff->0x3080
[    0.000000] MFN 0x30bf->0x3040
[    0.000000] MFN 0x307f->0x3000
[    0.000000] MFN 0x303f->0x2fc0
[    0.000000] MFN 0x2fff->0x2f80
[    0.000000] MFN 0x2fbf->0x2f40
[    0.000000] MFN 0x2f7f->0x2f00
[    0.000000] MFN 0x2f3f->0x2ec0
[    0.000000] MFN 0x2eff->0x2e80
[    0.000000] MFN 0x2ebf->0x2e40
[    0.000000] MFN 0x2e7f->0x2e00
[    0.000000] MFN 0x2e3f->0x2dc0
[    0.000000] MFN 0x2dff->0x2d80
[    0.000000] MFN 0x2dbf->0x2d40
[    0.000000] MFN 0x2d7f->0x2d00
[    0.000000] MFN 0x2d3f->0x2cc0
[    0.000000] MFN 0x2cff->0x2c80
[    0.000000] MFN 0x2cbf->0x2c40
[    0.000000] MFN 0x2c7f->0x2c00
[    0.000000] MFN 0x2c3f->0x2bc0
[    0.000000] MFN 0x2bff->0x2b80
[    0.000000] MFN 0x2bbf->0x2b40
[    0.000000] MFN 0x2b7f->0x2b00
[    0.000000] MFN 0x2b3f->0x2ac0
[    0.000000] MFN 0x2aff->0x2a80
[    0.000000] MFN 0x2abf->0x2a40
[    0.000000] MFN 0x2a7f->0x2a00
[    0.000000] MFN 0x2a3f->0x29c0
[    0.000000] MFN 0x29ff->0x2980
[    0.000000] MFN 0x29bf->0x2940
[    0.000000] MFN 0x297f->0x2900
[    0.000000] MFN 0x293f->0x28c0
[    0.000000] MFN 0x28ff->0x2880
[    0.000000] MFN 0x28bf->0x2840
[    0.000000] MFN 0x287f->0x2800
[    0.000000] MFN 0x283f->0x27c0
[    0.000000] MFN 0x27ff->0x2780
[    0.000000] MFN 0x27bf->0x2740
[    0.000000] MFN 0x277f->0x2700
[    0.000000] MFN 0x273f->0x26c0
[    0.000000] MFN 0x26ff->0x2680
[    0.000000] MFN 0x26bf->0x2640
[    0.000000] MFN 0x267f->0x2600
[    0.000000] MFN 0x263f->0x25c0
[    0.000000] MFN 0x25ff->0x2580
[    0.000000] MFN 0x25bf->0x2540
[    0.000000] MFN 0x257f->0x2500
[    0.000000] MFN 0x253f->0x24c0
[    0.000000] MFN 0x24ff->0x2480
[    0.000000] MFN 0x24bf->0x2440
[    0.000000] MFN 0x247f->0x2400
[    0.000000] MFN 0x243f->0x23c0
[    0.000000] MFN 0x23ff->0x2380
[    0.000000] MFN 0x23bf->0x2340
[    0.000000] MFN 0x237f->0x2300
[    0.000000] MFN 0x233f->0x22c0
[    0.000000] MFN 0x22ff->0x2280
[    0.000000] MFN 0x22bf->0x2240
[    0.000000] MFN 0x227f->0x2200
[    0.000000] MFN 0x223f->0x21c0
[    0.000000] MFN 0x21ff->0x2180
[    0.000000] MFN 0x21bf->0x2140
[    0.000000] MFN 0x217f->0x2100
[    0.000000] MFN 0x213f->0x20c0
[    0.000000] MFN 0x20ff->0x2080
[    0.000000] MFN 0x20bf->0x2040
[    0.000000] MFN 0x207f->0x2000
[    0.000000] MFN 0x203f->0x7fc0
[    0.000000] MFN 0x7fff->0x7f80
[    0.000000] MFN 0x7fbf->0x7f40
[    0.000000] MFN 0x7f7f->0x7f00
[    0.000000] Placing 64MB software IO TLB between d832cf00 - dc32cf00
[    0.000000] software IO TLB at phys 0x1832cf00 - 0x1c32cf00
[    0.000000] software IO TLB at bus 0x1c0f00 - 0x120fdff00
[    0.000000] Initializing HighMem for node 0 (000373fe:001dffc0)
[    0.000000] Memory: 384804k/7864064k available (2338k kernel code, 139036k reserved, 1197k data, 372k init, 0k highmem)

Actual code in xen_swiotlb_init after xen_swiotlb_fixup call:

        {
                phys_addr_t pstart, pend;
                unsigned long mfn, next_mfn;
                int i;

                pstart = virt_to_phys(xen_io_tlb_start);
                pend = virt_to_phys(xen_io_tlb_end);

                mfn= PFN_DOWN(phys_to_machine(XPADDR(pstart)).maddr);

                for (i = pstart; i < pend;) {
                        next_mfn = PFN_DOWN(phys_to_machine(XPADDR(i)).maddr);
                        if (next_mfn == mfn+1) {
                                mfn++;
                        } else {
                                printk(KERN_INFO "MFN 0x%lx->0x%lx\n", mfn, next_mfn);
                                mfn = next_mfn;
                        }
                i+=PAGE_SIZE;
                }

        }

We're not getting so far along as to be running xend yet. That normally gets started remotely and without networks it doesn't happen. I can probably do that tomorrow.

-----Original Message-----
From: Konrad Rzeszutek Wilk [mailto:konrad.r.wilk@gmail.com] On Behalf Of Konrad Rzeszutek Wilk
Sent: Tuesday, December 13, 2011 3:28 PM
To: Taylor, Neal E
Cc: xen-devel; Kalev, Leonid; Dave, Tushar N
Subject: Re: [Xen-devel] Buffers not reachable by PCI

On Tue, Dec 13, 2011 at 10:17:50PM +0000, Taylor, Neal E wrote:
> 
> Is it the translation that's in error?
> 
> Modeled after the translation in xen_swiotlb_dma_supported that's used for the problematic comparison, I added "the same" translation to swiotlb_print. I don't understand the results as dend - dstart is vastly larger that pend - pstart.

You might want to instrument the xen_swiotlb_fixup code to get an idea.

But basically there are "chunks" of 2MB (I think) of contingous memory
that is swizzled in to the memory that starts at io_tlb_start. But
all of that memory SHOULD be under the 4GB limit (set by max_dma_bits).

Sadly in your case one of those "chunks" ends up being past the 4GB
limit - which should never happen. Or if it did happen it would print
out "Failed to get contiguous memory for DMA from.."

But you don't get any of that.


To get a good idea of this, you could do something like this

unsigned long mfn, next_mfn;

mfn= PFN_DOWN(phys_to_machine(XPADDR(pstart)).maddr);

for (i = pstart; i < pend;) {
	next_mfn = PFN_DOWN(phys_to_machine(XPADDR(i)).maddr);
	if (next_mfn == mfn+1) {
		mfn++;
	} else {
		printk(KERN_INFO "MFN 0x%lx->0x%lx\n", mfn, next_mfn);
		mfn = next_mfn;
	}
	i+=PAGE_SIZE;
}

which should print you those "chunks", if my logic here is right.


Can you send me your 'xl info' (or 'xl dmesg'), please?

I tried to reproduce this with a 3.0.4 kernel on a 8GB and I couldn't
reproduce this. Hm, will look in your .config in case there is something
funky there.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 00:39:43 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 00:39:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RacsF-0003YZ-M1; Wed, 14 Dec 2011 00:39:07 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Neal.Taylor@ca.com>) id 1RacsD-0003YR-V2
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 00:39:06 +0000
X-Env-Sender: Neal.Taylor@ca.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1323823052!46596926!1
X-Originating-IP: [74.125.149.76]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1821 invoked from network); 14 Dec 2011 00:37:35 -0000
Received: from na3sys009aob106.obsmtp.com (HELO na3sys009aog106.obsmtp.com)
	(74.125.149.76)
	by server-5.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Dec 2011 00:37:35 -0000
Received: from USILMS190.ca.com ([141.202.246.44]) (using TLSv1) by
	na3sys009aob106.postini.com ([74.125.148.12]) with SMTP
	ID DSNKTufv9CghxTkQbQTblc+LqbCcazw6k+gD@postini.com;
	Tue, 13 Dec 2011 16:38:13 PST
Received: from USILMS171.ca.com (141.202.6.21) by USILMS190.ca.com
	(141.202.246.44) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Tue, 13 Dec 2011 19:38:11 -0500
Received: from USILMS110A.ca.com ([169.254.1.109]) by USILMS171.ca.com
	([141.202.6.21]) with mapi id 14.01.0289.001;
	Tue, 13 Dec 2011 19:38:10 -0500
From: "Taylor, Neal E" <Neal.Taylor@ca.com>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
Thread-Topic: [Xen-devel] Buffers not reachable by PCI
Thread-Index: Acy2r+Ulg1PsfbmtTl6QVj0jZAx7mwAK1xcAAIXl/sAAGPmvgAAhEiCwAA9ukQAACILlsA==
Date: Wed, 14 Dec 2011 00:38:09 +0000
Message-ID: <3E243B26F475504B9BB0BCC9728B0DA629E18564@USILMS110A.ca.com>
References: <3E243B26F475504B9BB0BCC9728B0DA629E16E01@USILMS110A.ca.com>
	<20111209203010.GA14412@andromeda.dapyr.net>
	<3E243B26F475504B9BB0BCC9728B0DA629E17AEA@USILMS110A.ca.com>
	<20111213001912.GA2730@konrad-lan>
	<3E243B26F475504B9BB0BCC9728B0DA629E184FA@USILMS110A.ca.com>
	<20111213232759.GA8702@konrad-lan>
In-Reply-To: <20111213232759.GA8702@konrad-lan>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [138.42.46.105]
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>, "Kalev,
	Leonid" <Leonid.Kalev@ca.com>, "Dave, Tushar N" <tushar.n.dave@intel.com>
Subject: Re: [Xen-devel] Buffers not reachable by PCI
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Instrumentation results:

[    0.000000] MFN 0x1c0->0x1c0
[    0.000000] MFN 0x1ff->0x180
[    0.000000] MFN 0x1bf->0x140
[    0.000000] MFN 0x17f->0x100
[    0.000000] MFN 0x13f->0x3c0
[    0.000000] MFN 0x3ff->0x380
[    0.000000] MFN 0x3bf->0x340
[    0.000000] MFN 0x37f->0x300
[    0.000000] MFN 0x33f->0x2c0
[    0.000000] MFN 0x2ff->0x280
[    0.000000] MFN 0x2bf->0x240
[    0.000000] MFN 0x27f->0x200
[    0.000000] MFN 0x23f->0x7c0
[    0.000000] MFN 0x7ff->0x780
[    0.000000] MFN 0x7bf->0x740
[    0.000000] MFN 0x77f->0x700
[    0.000000] MFN 0x73f->0x6c0
[    0.000000] MFN 0x6ff->0x680
[    0.000000] MFN 0x6bf->0x640
[    0.000000] MFN 0x67f->0x600
[    0.000000] MFN 0x63f->0x5c0
[    0.000000] MFN 0x5ff->0x580
[    0.000000] MFN 0x5bf->0x540
[    0.000000] MFN 0x57f->0x500
[    0.000000] MFN 0x53f->0x4c0
[    0.000000] MFN 0x4ff->0x480
[    0.000000] MFN 0x4bf->0x440
[    0.000000] MFN 0x47f->0x400
[    0.000000] MFN 0x43f->0xfc0
[    0.000000] MFN 0xfff->0xf80
[    0.000000] MFN 0xfbf->0xf40
[    0.000000] MFN 0xf7f->0xf00
[    0.000000] MFN 0xf3f->0xec0
[    0.000000] MFN 0xeff->0xe80
[    0.000000] MFN 0xebf->0xe40
[    0.000000] MFN 0xe7f->0xe00
[    0.000000] MFN 0xe3f->0xdc0
[    0.000000] MFN 0xdff->0xd80
[    0.000000] MFN 0xdbf->0xd40
[    0.000000] MFN 0xd7f->0xd00
[    0.000000] MFN 0xd3f->0xcc0
[    0.000000] MFN 0xcff->0xc80
[    0.000000] MFN 0xcbf->0xc40
[    0.000000] MFN 0xc7f->0xc00
[    0.000000] MFN 0xc3f->0xbc0
[    0.000000] MFN 0xbff->0xb80
[    0.000000] MFN 0xbbf->0xb40
[    0.000000] MFN 0xb7f->0xb00
[    0.000000] MFN 0xb3f->0xac0
[    0.000000] MFN 0xaff->0xa80
[    0.000000] MFN 0xabf->0xa40
[    0.000000] MFN 0xa7f->0xa00
[    0.000000] MFN 0xa3f->0x9c0
[    0.000000] MFN 0x9ff->0x980
[    0.000000] MFN 0x9bf->0x940
[    0.000000] MFN 0x97f->0x900
[    0.000000] MFN 0x93f->0x8c0
[    0.000000] MFN 0x8ff->0x880
[    0.000000] MFN 0x8bf->0x840
[    0.000000] MFN 0x87f->0x800
[    0.000000] MFN 0x83f->0x1fc0
[    0.000000] MFN 0x1fff->0x1f80
[    0.000000] MFN 0x1fbf->0x1f40
[    0.000000] MFN 0x1f7f->0x1f00
[    0.000000] MFN 0x1f3f->0x1ec0
[    0.000000] MFN 0x1eff->0x1e80
[    0.000000] MFN 0x1ebf->0x1e40
[    0.000000] MFN 0x1e7f->0x1e00
[    0.000000] MFN 0x1e3f->0x1dc0
[    0.000000] MFN 0x1dff->0x1d80
[    0.000000] MFN 0x1dbf->0x1d40
[    0.000000] MFN 0x1d7f->0x1d00
[    0.000000] MFN 0x1d3f->0x1cc0
[    0.000000] MFN 0x1cff->0x1c80
[    0.000000] MFN 0x1cbf->0x1c40
[    0.000000] MFN 0x1c7f->0x1c00
[    0.000000] MFN 0x1c3f->0x1bc0
[    0.000000] MFN 0x1bff->0x1b80
[    0.000000] MFN 0x1bbf->0x1b40
[    0.000000] MFN 0x1b7f->0x1b00
[    0.000000] MFN 0x1b3f->0x1ac0
[    0.000000] MFN 0x1aff->0x1a80
[    0.000000] MFN 0x1abf->0x1a40
[    0.000000] MFN 0x1a7f->0x1a00
[    0.000000] MFN 0x1a3f->0x19c0
[    0.000000] MFN 0x19ff->0x1980
[    0.000000] MFN 0x19bf->0x1940
[    0.000000] MFN 0x197f->0x1900
[    0.000000] MFN 0x193f->0x18c0
[    0.000000] MFN 0x18ff->0x1880
[    0.000000] MFN 0x18bf->0x1840
[    0.000000] MFN 0x187f->0x1800
[    0.000000] MFN 0x183f->0x17c0
[    0.000000] MFN 0x17ff->0x1780
[    0.000000] MFN 0x17bf->0x1740
[    0.000000] MFN 0x177f->0x1700
[    0.000000] MFN 0x173f->0x16c0
[    0.000000] MFN 0x16ff->0x1680
[    0.000000] MFN 0x16bf->0x1640
[    0.000000] MFN 0x167f->0x1600
[    0.000000] MFN 0x163f->0x15c0
[    0.000000] MFN 0x15ff->0x1580
[    0.000000] MFN 0x15bf->0x1540
[    0.000000] MFN 0x157f->0x1500
[    0.000000] MFN 0x153f->0x14c0
[    0.000000] MFN 0x14ff->0x1480
[    0.000000] MFN 0x14bf->0x1440
[    0.000000] MFN 0x147f->0x1400
[    0.000000] MFN 0x143f->0x13c0
[    0.000000] MFN 0x13ff->0x1380
[    0.000000] MFN 0x13bf->0x1340
[    0.000000] MFN 0x137f->0x1300
[    0.000000] MFN 0x133f->0x12c0
[    0.000000] MFN 0x12ff->0x1280
[    0.000000] MFN 0x12bf->0x1240
[    0.000000] MFN 0x127f->0x1200
[    0.000000] MFN 0x123f->0x11c0
[    0.000000] MFN 0x11ff->0x1180
[    0.000000] MFN 0x11bf->0x1140
[    0.000000] MFN 0x117f->0x1100
[    0.000000] MFN 0x113f->0x10c0
[    0.000000] MFN 0x10ff->0x1080
[    0.000000] MFN 0x10bf->0x1040
[    0.000000] MFN 0x107f->0x1000
[    0.000000] MFN 0x103f->0x3fc0
[    0.000000] MFN 0x3fff->0x3f80
[    0.000000] MFN 0x3fbf->0x3f40
[    0.000000] MFN 0x3f7f->0x3f00
[    0.000000] MFN 0x3f3f->0x3ec0
[    0.000000] MFN 0x3eff->0x3e80
[    0.000000] MFN 0x3ebf->0x3e40
[    0.000000] MFN 0x3e7f->0x3e00
[    0.000000] MFN 0x3e3f->0x3dc0
[    0.000000] MFN 0x3dff->0x3d80
[    0.000000] MFN 0x3dbf->0x3d40
[    0.000000] MFN 0x3d7f->0x3d00
[    0.000000] MFN 0x3d3f->0x3cc0
[    0.000000] MFN 0x3cff->0x3c80
[    0.000000] MFN 0x3cbf->0x3c40
[    0.000000] MFN 0x3c7f->0x3c00
[    0.000000] MFN 0x3c3f->0x3bc0
[    0.000000] MFN 0x3bff->0x3b80
[    0.000000] MFN 0x3bbf->0x3b40
[    0.000000] MFN 0x3b7f->0x3b00
[    0.000000] MFN 0x3b3f->0x3ac0
[    0.000000] MFN 0x3aff->0x3a80
[    0.000000] MFN 0x3abf->0x3a40
[    0.000000] MFN 0x3a7f->0x3a00
[    0.000000] MFN 0x3a3f->0x39c0
[    0.000000] MFN 0x39ff->0x3980
[    0.000000] MFN 0x39bf->0x3940
[    0.000000] MFN 0x397f->0x3900
[    0.000000] MFN 0x393f->0x38c0
[    0.000000] MFN 0x38ff->0x3880
[    0.000000] MFN 0x38bf->0x3840
[    0.000000] MFN 0x387f->0x3800
[    0.000000] MFN 0x383f->0x37c0
[    0.000000] MFN 0x37ff->0x3780
[    0.000000] MFN 0x37bf->0x3740
[    0.000000] MFN 0x377f->0x3700
[    0.000000] MFN 0x373f->0x36c0
[    0.000000] MFN 0x36ff->0x3680
[    0.000000] MFN 0x36bf->0x3640
[    0.000000] MFN 0x367f->0x3600
[    0.000000] MFN 0x363f->0x35c0
[    0.000000] MFN 0x35ff->0x3580
[    0.000000] MFN 0x35bf->0x3540
[    0.000000] MFN 0x357f->0x3500
[    0.000000] MFN 0x353f->0x34c0
[    0.000000] MFN 0x34ff->0x3480
[    0.000000] MFN 0x34bf->0x3440
[    0.000000] MFN 0x347f->0x3400
[    0.000000] MFN 0x343f->0x33c0
[    0.000000] MFN 0x33ff->0x3380
[    0.000000] MFN 0x33bf->0x3340
[    0.000000] MFN 0x337f->0x3300
[    0.000000] MFN 0x333f->0x32c0
[    0.000000] MFN 0x32ff->0x3280
[    0.000000] MFN 0x32bf->0x3240
[    0.000000] MFN 0x327f->0x3200
[    0.000000] MFN 0x323f->0x31c0
[    0.000000] MFN 0x31ff->0x3180
[    0.000000] MFN 0x31bf->0x3140
[    0.000000] MFN 0x317f->0x3100
[    0.000000] MFN 0x313f->0x30c0
[    0.000000] MFN 0x30ff->0x3080
[    0.000000] MFN 0x30bf->0x3040
[    0.000000] MFN 0x307f->0x3000
[    0.000000] MFN 0x303f->0x2fc0
[    0.000000] MFN 0x2fff->0x2f80
[    0.000000] MFN 0x2fbf->0x2f40
[    0.000000] MFN 0x2f7f->0x2f00
[    0.000000] MFN 0x2f3f->0x2ec0
[    0.000000] MFN 0x2eff->0x2e80
[    0.000000] MFN 0x2ebf->0x2e40
[    0.000000] MFN 0x2e7f->0x2e00
[    0.000000] MFN 0x2e3f->0x2dc0
[    0.000000] MFN 0x2dff->0x2d80
[    0.000000] MFN 0x2dbf->0x2d40
[    0.000000] MFN 0x2d7f->0x2d00
[    0.000000] MFN 0x2d3f->0x2cc0
[    0.000000] MFN 0x2cff->0x2c80
[    0.000000] MFN 0x2cbf->0x2c40
[    0.000000] MFN 0x2c7f->0x2c00
[    0.000000] MFN 0x2c3f->0x2bc0
[    0.000000] MFN 0x2bff->0x2b80
[    0.000000] MFN 0x2bbf->0x2b40
[    0.000000] MFN 0x2b7f->0x2b00
[    0.000000] MFN 0x2b3f->0x2ac0
[    0.000000] MFN 0x2aff->0x2a80
[    0.000000] MFN 0x2abf->0x2a40
[    0.000000] MFN 0x2a7f->0x2a00
[    0.000000] MFN 0x2a3f->0x29c0
[    0.000000] MFN 0x29ff->0x2980
[    0.000000] MFN 0x29bf->0x2940
[    0.000000] MFN 0x297f->0x2900
[    0.000000] MFN 0x293f->0x28c0
[    0.000000] MFN 0x28ff->0x2880
[    0.000000] MFN 0x28bf->0x2840
[    0.000000] MFN 0x287f->0x2800
[    0.000000] MFN 0x283f->0x27c0
[    0.000000] MFN 0x27ff->0x2780
[    0.000000] MFN 0x27bf->0x2740
[    0.000000] MFN 0x277f->0x2700
[    0.000000] MFN 0x273f->0x26c0
[    0.000000] MFN 0x26ff->0x2680
[    0.000000] MFN 0x26bf->0x2640
[    0.000000] MFN 0x267f->0x2600
[    0.000000] MFN 0x263f->0x25c0
[    0.000000] MFN 0x25ff->0x2580
[    0.000000] MFN 0x25bf->0x2540
[    0.000000] MFN 0x257f->0x2500
[    0.000000] MFN 0x253f->0x24c0
[    0.000000] MFN 0x24ff->0x2480
[    0.000000] MFN 0x24bf->0x2440
[    0.000000] MFN 0x247f->0x2400
[    0.000000] MFN 0x243f->0x23c0
[    0.000000] MFN 0x23ff->0x2380
[    0.000000] MFN 0x23bf->0x2340
[    0.000000] MFN 0x237f->0x2300
[    0.000000] MFN 0x233f->0x22c0
[    0.000000] MFN 0x22ff->0x2280
[    0.000000] MFN 0x22bf->0x2240
[    0.000000] MFN 0x227f->0x2200
[    0.000000] MFN 0x223f->0x21c0
[    0.000000] MFN 0x21ff->0x2180
[    0.000000] MFN 0x21bf->0x2140
[    0.000000] MFN 0x217f->0x2100
[    0.000000] MFN 0x213f->0x20c0
[    0.000000] MFN 0x20ff->0x2080
[    0.000000] MFN 0x20bf->0x2040
[    0.000000] MFN 0x207f->0x2000
[    0.000000] MFN 0x203f->0x7fc0
[    0.000000] MFN 0x7fff->0x7f80
[    0.000000] MFN 0x7fbf->0x7f40
[    0.000000] MFN 0x7f7f->0x7f00
[    0.000000] Placing 64MB software IO TLB between d832cf00 - dc32cf00
[    0.000000] software IO TLB at phys 0x1832cf00 - 0x1c32cf00
[    0.000000] software IO TLB at bus 0x1c0f00 - 0x120fdff00
[    0.000000] Initializing HighMem for node 0 (000373fe:001dffc0)
[    0.000000] Memory: 384804k/7864064k available (2338k kernel code, 139036k reserved, 1197k data, 372k init, 0k highmem)

Actual code in xen_swiotlb_init after xen_swiotlb_fixup call:

        {
                phys_addr_t pstart, pend;
                unsigned long mfn, next_mfn;
                int i;

                pstart = virt_to_phys(xen_io_tlb_start);
                pend = virt_to_phys(xen_io_tlb_end);

                mfn= PFN_DOWN(phys_to_machine(XPADDR(pstart)).maddr);

                for (i = pstart; i < pend;) {
                        next_mfn = PFN_DOWN(phys_to_machine(XPADDR(i)).maddr);
                        if (next_mfn == mfn+1) {
                                mfn++;
                        } else {
                                printk(KERN_INFO "MFN 0x%lx->0x%lx\n", mfn, next_mfn);
                                mfn = next_mfn;
                        }
                i+=PAGE_SIZE;
                }

        }

We're not getting so far along as to be running xend yet. That normally gets started remotely and without networks it doesn't happen. I can probably do that tomorrow.

-----Original Message-----
From: Konrad Rzeszutek Wilk [mailto:konrad.r.wilk@gmail.com] On Behalf Of Konrad Rzeszutek Wilk
Sent: Tuesday, December 13, 2011 3:28 PM
To: Taylor, Neal E
Cc: xen-devel; Kalev, Leonid; Dave, Tushar N
Subject: Re: [Xen-devel] Buffers not reachable by PCI

On Tue, Dec 13, 2011 at 10:17:50PM +0000, Taylor, Neal E wrote:
> 
> Is it the translation that's in error?
> 
> Modeled after the translation in xen_swiotlb_dma_supported that's used for the problematic comparison, I added "the same" translation to swiotlb_print. I don't understand the results as dend - dstart is vastly larger that pend - pstart.

You might want to instrument the xen_swiotlb_fixup code to get an idea.

But basically there are "chunks" of 2MB (I think) of contingous memory
that is swizzled in to the memory that starts at io_tlb_start. But
all of that memory SHOULD be under the 4GB limit (set by max_dma_bits).

Sadly in your case one of those "chunks" ends up being past the 4GB
limit - which should never happen. Or if it did happen it would print
out "Failed to get contiguous memory for DMA from.."

But you don't get any of that.


To get a good idea of this, you could do something like this

unsigned long mfn, next_mfn;

mfn= PFN_DOWN(phys_to_machine(XPADDR(pstart)).maddr);

for (i = pstart; i < pend;) {
	next_mfn = PFN_DOWN(phys_to_machine(XPADDR(i)).maddr);
	if (next_mfn == mfn+1) {
		mfn++;
	} else {
		printk(KERN_INFO "MFN 0x%lx->0x%lx\n", mfn, next_mfn);
		mfn = next_mfn;
	}
	i+=PAGE_SIZE;
}

which should print you those "chunks", if my logic here is right.


Can you send me your 'xl info' (or 'xl dmesg'), please?

I tried to reproduce this with a 3.0.4 kernel on a 8GB and I couldn't
reproduce this. Hm, will look in your .config in case there is something
funky there.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 00:44:11 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 00:44:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Racwe-0003fl-Cc; Wed, 14 Dec 2011 00:43:40 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jim_burn@bellsouth.net>) id 1Racwc-0003fU-QU
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 00:43:39 +0000
X-Env-Sender: jim_burn@bellsouth.net
X-Msg-Ref: server-12.tower-182.messagelabs.com!1323823363!7153879!1
X-Originating-IP: [98.139.44.136]
X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6256 invoked from network); 14 Dec 2011 00:42:43 -0000
Received: from nm9.access.bullet.mail.sp2.yahoo.com (HELO
	nm9.access.bullet.mail.sp2.yahoo.com) (98.139.44.136)
	by server-12.tower-182.messagelabs.com with SMTP;
	14 Dec 2011 00:42:43 -0000
Received: from [98.139.44.100] by nm9.access.bullet.mail.sp2.yahoo.com with
	NNFMP; 14 Dec 2011 00:42:42 -0000
Received: from [98.139.44.76] by tm5.access.bullet.mail.sp2.yahoo.com with
	NNFMP; 14 Dec 2011 00:42:42 -0000
Received: from [127.0.0.1] by omp1013.access.mail.sp2.yahoo.com with NNFMP;
	14 Dec 2011 00:42:42 -0000
X-Yahoo-Newman-Id: 427497.7832.bm@omp1013.access.mail.sp2.yahoo.com
Received: (qmail 67656 invoked from network); 14 Dec 2011 00:42:42 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bellsouth.net; s=s1024;
	t=1323823362; bh=G8GbZkNT9GFu+O+bxhr1waCsNhlJD7w0BdOICsvNuCc=;
	h=X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:From:To:Cc:Subject:Date:Message-ID:User-Agent:In-Reply-To:References:MIME-Version:Content-Transfer-Encoding:Content-Type;
	b=YDmFJUGkhsMeE0eQ2TcopGP0WM7+SZTi2ppIVUDIsRhzsqQqVWygivHrqBQOyEIC4HqPIeuwDKE0C5MqsabK+3Gpj9vq19S5l5zre4nIRCYE8x4LBK4tDMqB7MibR/KD/vxTFtB8s6PkPdqbUIhFd+1XMBHxtcrzAUMt16CmGdw=
X-Yahoo-Newman-Property: ymail-3
X-YMail-OSG: hsEQ5F8VM1nE4TKUGzJawKCQv1dyIjy6Eu4eBDEg6cub6zk
	5.nBQrqQdXLLVh1icy2IbqIEMPKP2bNqo3ST_BQxcaggbIcx4yfPddgcvIgL
	db8dRwkOug8ERIoynsOjVAjH4y53fDWV4VyLmmkIlDfZJ9rL3pH3fMkgvLwt
	9cQzxfCiHm9Zfj3zgFLP6KSSWBnIMyexQzkwYsVqjQJl9MNwHHWPdonZ3_e9
	6GTkg1wvXgIzL1D0J3ewtFuTjVwcaEXjJEAPa7MLhb2ckhqga6Hay8QuWeeJ
	K1YK7nFmTTJHu.f21VJVGXoDOcX65n.aBVXgK9QonS5KzrSdkeJkVE5rNH_R
	MxhXMd5B4d8HI3XWB_DqQVA5JRbwXeL4BYgOmLS_Dh.UF0wAvfpguptMoufZ
	MmsTAUPcLiARzg2X1WjLjwbR8.EaUuGq0mT_y
X-Yahoo-SMTP: g0AhWW2swBA2djJKuhuwxPlPqLrHlDrycdPnfR9kZNrpKCA-
Received: from dell4550.localnet (jim_burn@184.36.12.137 with plain)
	by smtp110.sbc.mail.gq1.yahoo.com with SMTP;
	13 Dec 2011 16:42:41 -0800 PST
From: jim burns <jim_burn@bellsouth.net>
To: Mark Pryor <tlviewer@yahoo.com>, xen-devel@lists.xensource.com,
	JBeulich@suse.com
Date: Tue, 13 Dec 2011 19:42:31 -0500
Message-ID: <2418222.I2RnIRCVYI@dell4550>
User-Agent: KMail/4.7.4 (Linux/3.1.0-1.2-default; KDE/4.7.4; i686; ; )
In-Reply-To: <1323816494.57363.YahooMailNeo@web35601.mail.mud.yahoo.com>
References: <5240506.YiTi8lqF86@dell4550>
	<1323816494.57363.YahooMailNeo@web35601.mail.mud.yahoo.com>
MIME-Version: 1.0
Cc: "xen-users@lists.xensource.com" <xen-users@lists.xensource.com>
Subject: Re: [Xen-devel] [Xen-users] openSUSE 12.1 does not have complete
	xen rpms
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue December 13 2011, 2:48:14 PM, Mark Pryor wrote:
> Move to x86_64 and you will have a complete dom0 upgrade. Its true that
> i586 is not supporting a full dom0.

Not possible - it's a 32 bit system.

I suppose I could download the xen .src.rpm, and recompile it, assuming they 
haven't disabled i586 for some reason. I just want to know if it's supported, 
or suse ran into a snag getting it to work for i586.

Anyone know if they will eventually support it?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 00:44:11 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 00:44:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Racwe-0003fl-Cc; Wed, 14 Dec 2011 00:43:40 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jim_burn@bellsouth.net>) id 1Racwc-0003fU-QU
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 00:43:39 +0000
X-Env-Sender: jim_burn@bellsouth.net
X-Msg-Ref: server-12.tower-182.messagelabs.com!1323823363!7153879!1
X-Originating-IP: [98.139.44.136]
X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6256 invoked from network); 14 Dec 2011 00:42:43 -0000
Received: from nm9.access.bullet.mail.sp2.yahoo.com (HELO
	nm9.access.bullet.mail.sp2.yahoo.com) (98.139.44.136)
	by server-12.tower-182.messagelabs.com with SMTP;
	14 Dec 2011 00:42:43 -0000
Received: from [98.139.44.100] by nm9.access.bullet.mail.sp2.yahoo.com with
	NNFMP; 14 Dec 2011 00:42:42 -0000
Received: from [98.139.44.76] by tm5.access.bullet.mail.sp2.yahoo.com with
	NNFMP; 14 Dec 2011 00:42:42 -0000
Received: from [127.0.0.1] by omp1013.access.mail.sp2.yahoo.com with NNFMP;
	14 Dec 2011 00:42:42 -0000
X-Yahoo-Newman-Id: 427497.7832.bm@omp1013.access.mail.sp2.yahoo.com
Received: (qmail 67656 invoked from network); 14 Dec 2011 00:42:42 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bellsouth.net; s=s1024;
	t=1323823362; bh=G8GbZkNT9GFu+O+bxhr1waCsNhlJD7w0BdOICsvNuCc=;
	h=X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:From:To:Cc:Subject:Date:Message-ID:User-Agent:In-Reply-To:References:MIME-Version:Content-Transfer-Encoding:Content-Type;
	b=YDmFJUGkhsMeE0eQ2TcopGP0WM7+SZTi2ppIVUDIsRhzsqQqVWygivHrqBQOyEIC4HqPIeuwDKE0C5MqsabK+3Gpj9vq19S5l5zre4nIRCYE8x4LBK4tDMqB7MibR/KD/vxTFtB8s6PkPdqbUIhFd+1XMBHxtcrzAUMt16CmGdw=
X-Yahoo-Newman-Property: ymail-3
X-YMail-OSG: hsEQ5F8VM1nE4TKUGzJawKCQv1dyIjy6Eu4eBDEg6cub6zk
	5.nBQrqQdXLLVh1icy2IbqIEMPKP2bNqo3ST_BQxcaggbIcx4yfPddgcvIgL
	db8dRwkOug8ERIoynsOjVAjH4y53fDWV4VyLmmkIlDfZJ9rL3pH3fMkgvLwt
	9cQzxfCiHm9Zfj3zgFLP6KSSWBnIMyexQzkwYsVqjQJl9MNwHHWPdonZ3_e9
	6GTkg1wvXgIzL1D0J3ewtFuTjVwcaEXjJEAPa7MLhb2ckhqga6Hay8QuWeeJ
	K1YK7nFmTTJHu.f21VJVGXoDOcX65n.aBVXgK9QonS5KzrSdkeJkVE5rNH_R
	MxhXMd5B4d8HI3XWB_DqQVA5JRbwXeL4BYgOmLS_Dh.UF0wAvfpguptMoufZ
	MmsTAUPcLiARzg2X1WjLjwbR8.EaUuGq0mT_y
X-Yahoo-SMTP: g0AhWW2swBA2djJKuhuwxPlPqLrHlDrycdPnfR9kZNrpKCA-
Received: from dell4550.localnet (jim_burn@184.36.12.137 with plain)
	by smtp110.sbc.mail.gq1.yahoo.com with SMTP;
	13 Dec 2011 16:42:41 -0800 PST
From: jim burns <jim_burn@bellsouth.net>
To: Mark Pryor <tlviewer@yahoo.com>, xen-devel@lists.xensource.com,
	JBeulich@suse.com
Date: Tue, 13 Dec 2011 19:42:31 -0500
Message-ID: <2418222.I2RnIRCVYI@dell4550>
User-Agent: KMail/4.7.4 (Linux/3.1.0-1.2-default; KDE/4.7.4; i686; ; )
In-Reply-To: <1323816494.57363.YahooMailNeo@web35601.mail.mud.yahoo.com>
References: <5240506.YiTi8lqF86@dell4550>
	<1323816494.57363.YahooMailNeo@web35601.mail.mud.yahoo.com>
MIME-Version: 1.0
Cc: "xen-users@lists.xensource.com" <xen-users@lists.xensource.com>
Subject: Re: [Xen-devel] [Xen-users] openSUSE 12.1 does not have complete
	xen rpms
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue December 13 2011, 2:48:14 PM, Mark Pryor wrote:
> Move to x86_64 and you will have a complete dom0 upgrade. Its true that
> i586 is not supporting a full dom0.

Not possible - it's a 32 bit system.

I suppose I could download the xen .src.rpm, and recompile it, assuming they 
haven't disabled i586 for some reason. I just want to know if it's supported, 
or suse ran into a snag getting it to work for i586.

Anyone know if they will eventually support it?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 06:39:25 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 06:39:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaiU9-0002v2-0Q; Wed, 14 Dec 2011 06:38:37 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RaiU6-0002ux-Lj
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 06:38:34 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1323844659!1427538!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTM5Mw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19699 invoked from network); 14 Dec 2011 06:37:39 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Dec 2011 06:37:39 -0000
X-IronPort-AV: E=Sophos;i="4.71,350,1320624000"; 
   d="scan'208";a="9453340"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Dec 2011 06:37:39 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 14 Dec 2011 06:37:39 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RaiTD-00046i-0n;
	Wed, 14 Dec 2011 06:37:39 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RaiTB-0008IM-7v;
	Wed, 14 Dec 2011 06:37:38 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10491-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 14 Dec 2011 06:37:37 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10491: tolerable FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10491 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10491/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-i386-i386-xl-winxpsp3    7 windows-install             fail pass in 10490

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install          fail like 10490
 test-amd64-i386-xend-winxpsp3  7 windows-install              fail  like 10490
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop            fail in 10490 never pass

version targeted for testing:
 xen                  03138a08366b
baseline version:
 xen                  03138a08366b

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 06:39:25 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 06:39:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaiU9-0002v2-0Q; Wed, 14 Dec 2011 06:38:37 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RaiU6-0002ux-Lj
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 06:38:34 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1323844659!1427538!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTM5Mw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19699 invoked from network); 14 Dec 2011 06:37:39 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Dec 2011 06:37:39 -0000
X-IronPort-AV: E=Sophos;i="4.71,350,1320624000"; 
   d="scan'208";a="9453340"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Dec 2011 06:37:39 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 14 Dec 2011 06:37:39 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RaiTD-00046i-0n;
	Wed, 14 Dec 2011 06:37:39 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RaiTB-0008IM-7v;
	Wed, 14 Dec 2011 06:37:38 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10491-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 14 Dec 2011 06:37:37 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10491: tolerable FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10491 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10491/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-i386-i386-xl-winxpsp3    7 windows-install             fail pass in 10490

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install          fail like 10490
 test-amd64-i386-xend-winxpsp3  7 windows-install              fail  like 10490
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop            fail in 10490 never pass

version targeted for testing:
 xen                  03138a08366b
baseline version:
 xen                  03138a08366b

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 07:21:30 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 07:21:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Raj8z-0003WY-Vz; Wed, 14 Dec 2011 07:20:49 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wnlo.zwt@gmail.com>) id 1Raj8y-0003WT-FT
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 07:20:48 +0000
X-Env-Sender: wnlo.zwt@gmail.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1323847192!5483539!1
X-Originating-IP: [209.85.212.43]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12650 invoked from network); 14 Dec 2011 07:19:53 -0000
Received: from mail-vw0-f43.google.com (HELO mail-vw0-f43.google.com)
	(209.85.212.43)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Dec 2011 07:19:53 -0000
Received: by vbbfq11 with SMTP id fq11so1161093vbb.30
	for <xen-devel@lists.xensource.com>;
	Tue, 13 Dec 2011 23:19:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:content-type; bh=wREo6he9oTDKbYq6GAGa6uiI7uflocBXMAsB75i5+FA=;
	b=T7Iqr37umE3/5YxdP8zX4uu0qAzMX64FqRieYz40rdu7zfsmeiI7D/QF9XpWSQXaCQ
	yolUbdyEHgglVxcM0nL1elmRFZbc9PTHxmC21yhyonXNzX5AbHQYdL00sSro591J4ER6
	f+HTmK1ZUFivWc0rlmecxv1jwi/TingjVdEo8=
MIME-Version: 1.0
Received: by 10.52.35.210 with SMTP id k18mr3193571vdj.37.1323847191908; Tue,
	13 Dec 2011 23:19:51 -0800 (PST)
Received: by 10.52.112.131 with HTTP; Tue, 13 Dec 2011 23:19:51 -0800 (PST)
In-Reply-To: <CAJZuLfe+QsePaJps=3SdG4ALYs0PixB3xcrb0nx1+v-o0VmMaw@mail.gmail.com>
References: <CAJZuLfe+QsePaJps=3SdG4ALYs0PixB3xcrb0nx1+v-o0VmMaw@mail.gmail.com>
Date: Wed, 14 Dec 2011 15:19:51 +0800
Message-ID: <CAJZuLff7otKaraAYF_wFG7vRzgVcFNg9cbos2UVS=M0pMZ34zQ@mail.gmail.com>
From: Wentao Zhang <wnlo.zwt@gmail.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] how to make the new python codes effective
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============7497301737821742051=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============7497301737821742051==
Content-Type: multipart/alternative; boundary=20cf307ac3ff9c52d904b4083187

--20cf307ac3ff9c52d904b4083187
Content-Type: text/plain; charset=ISO-8859-1

Hi,
    Something troubles me several days.  I had changed some codes in
tools/python/xen/xm/main.py, but how can I make them effective ?
I had tried with 'make xen && make install-xen', but failed !
    Who can tell me how to update these python modules ?

--20cf307ac3ff9c52d904b4083187
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote"><br>Hi,=A0<div>=A0 =A0 Something troubles me sev=
eral days. =A0I had changed some codes in tools/python/xen/xm/main.py, but =
how can I make them effective ?</div><div>I had tried with &#39;make xen &a=
mp;&amp; make install-xen&#39;, but failed !=A0</div>

<div>=A0 =A0 Who can tell me how to update these python modules ?</div>
</div><br>

--20cf307ac3ff9c52d904b4083187--


--===============7497301737821742051==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============7497301737821742051==--


From xen-devel-bounces@lists.xensource.com Wed Dec 14 07:21:30 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 07:21:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Raj8z-0003WY-Vz; Wed, 14 Dec 2011 07:20:49 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wnlo.zwt@gmail.com>) id 1Raj8y-0003WT-FT
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 07:20:48 +0000
X-Env-Sender: wnlo.zwt@gmail.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1323847192!5483539!1
X-Originating-IP: [209.85.212.43]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12650 invoked from network); 14 Dec 2011 07:19:53 -0000
Received: from mail-vw0-f43.google.com (HELO mail-vw0-f43.google.com)
	(209.85.212.43)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Dec 2011 07:19:53 -0000
Received: by vbbfq11 with SMTP id fq11so1161093vbb.30
	for <xen-devel@lists.xensource.com>;
	Tue, 13 Dec 2011 23:19:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:content-type; bh=wREo6he9oTDKbYq6GAGa6uiI7uflocBXMAsB75i5+FA=;
	b=T7Iqr37umE3/5YxdP8zX4uu0qAzMX64FqRieYz40rdu7zfsmeiI7D/QF9XpWSQXaCQ
	yolUbdyEHgglVxcM0nL1elmRFZbc9PTHxmC21yhyonXNzX5AbHQYdL00sSro591J4ER6
	f+HTmK1ZUFivWc0rlmecxv1jwi/TingjVdEo8=
MIME-Version: 1.0
Received: by 10.52.35.210 with SMTP id k18mr3193571vdj.37.1323847191908; Tue,
	13 Dec 2011 23:19:51 -0800 (PST)
Received: by 10.52.112.131 with HTTP; Tue, 13 Dec 2011 23:19:51 -0800 (PST)
In-Reply-To: <CAJZuLfe+QsePaJps=3SdG4ALYs0PixB3xcrb0nx1+v-o0VmMaw@mail.gmail.com>
References: <CAJZuLfe+QsePaJps=3SdG4ALYs0PixB3xcrb0nx1+v-o0VmMaw@mail.gmail.com>
Date: Wed, 14 Dec 2011 15:19:51 +0800
Message-ID: <CAJZuLff7otKaraAYF_wFG7vRzgVcFNg9cbos2UVS=M0pMZ34zQ@mail.gmail.com>
From: Wentao Zhang <wnlo.zwt@gmail.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] how to make the new python codes effective
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============7497301737821742051=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============7497301737821742051==
Content-Type: multipart/alternative; boundary=20cf307ac3ff9c52d904b4083187

--20cf307ac3ff9c52d904b4083187
Content-Type: text/plain; charset=ISO-8859-1

Hi,
    Something troubles me several days.  I had changed some codes in
tools/python/xen/xm/main.py, but how can I make them effective ?
I had tried with 'make xen && make install-xen', but failed !
    Who can tell me how to update these python modules ?

--20cf307ac3ff9c52d904b4083187
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote"><br>Hi,=A0<div>=A0 =A0 Something troubles me sev=
eral days. =A0I had changed some codes in tools/python/xen/xm/main.py, but =
how can I make them effective ?</div><div>I had tried with &#39;make xen &a=
mp;&amp; make install-xen&#39;, but failed !=A0</div>

<div>=A0 =A0 Who can tell me how to update these python modules ?</div>
</div><br>

--20cf307ac3ff9c52d904b4083187--


--===============7497301737821742051==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============7497301737821742051==--


From xen-devel-bounces@lists.xensource.com Wed Dec 14 07:26:56 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 07:26:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RajEM-0003ec-P1; Wed, 14 Dec 2011 07:26:22 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RajEK-0003eV-IT
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 07:26:20 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1323847524!7171962!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTM5Mw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18625 invoked from network); 14 Dec 2011 07:25:24 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Dec 2011 07:25:24 -0000
X-IronPort-AV: E=Sophos;i="4.71,350,1320624000"; 
   d="scan'208";a="9453750"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Dec 2011 07:25:24 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 14 Dec 2011 07:25:23 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: George Shuklin <george.shuklin@gmail.com>
In-Reply-To: <4EE7D75B.6080209@gmail.com>
References: <4EE675A8.3030609@niemail.de>	<4EE71663.5040308@gmail.com>
	<CAJeBh4sxdNTxM_oLFAuA6Mw75=LaYysrpS5b8NsZMbkf_swNVw@mail.gmail.com>
	<4EE72A94.6040904@gmail.com> <4EE75080.1000909@citrix.com>
	<1323783428.20077.298.camel@zakaz.uk.xensource.com>
	<4EE7BC9B.6040003@gmail.com>
	<1323815427.20936.96.camel@dagon.hellion.org.uk>
	<4EE7D75B.6080209@gmail.com>
Organization: Citrix Systems, Inc.
Date: Wed, 14 Dec 2011 07:25:23 +0000
Message-ID: <1323847523.20936.110.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
X-Mailer: Evolution 2.32.3 
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	David Vrabel <david.vrabel@citrix.com>,
	"sandr8@gmail.com" <sandr8@gmail.com>
Subject: Re: [Xen-devel] a ton of kernel issues
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2011-12-13 at 22:53 +0000, George Shuklin wrote:
> On 14.12.2011 02:30, Ian Campbell wrote:
> > On Tue, 2011-12-13 at 20:59 +0000, George Shuklin wrote:
> >> On 13.12.2011 17:37, Ian Campbell wrote:
> >>>> This should work if memory hotplug is enabled.
> >>>>
> >>>> It is also supported without memory hotplug but this requires that the
> >>>> tools supply a suitable memory map that covers the largest
> >>>> memory-static-max limit you wish to support.  I'm not sure if the tools
> >>>> can do this yet.
> >>> With xl this should work using the "maxmem" option. (xm probably uses
> >>> the same name)
> >>>
> >> I'm not sure what maxmem do
> > maxmem sets static-max for the guest in the xl toolstack.
> 
> Well, I understand that, I simply don't understand what maxmem do with 
> domain in xen (the hypervisor part). My hypothesis is just put a limit 
> for amount of allocated PFN for domain.

It controls precisely the behaviour you need! Try "maxmem=2048" and
"memory=1024" in your guest configuration, it should boot with 1G of RAM
and allow you to balloon to 2G and back.

The maxmem option mainly passes an appropriate e820 table to the guest
to cause it to allocate enough space for 2G of pages.

On some versions of Linux you might also need to add mem=2G to the
kernel command line to work around a bug. That is fixed in the most
recent versions though.

> >
> >> but I can say, this option does not allow
> >> to go beyond initial boot memory for pv_ops kernels and beyond
> >> static-max memory for -xen kernel.
> > AFAIK the toolstack support for memory hotplug (i.e. growing beyond
> > static-max) does not yet exist.
> 
> As far as I know toolstack is not really do some work for this (if I 
> wrong I'll be really appreciated for information).

I'm not really sure what you are referring to here. Memory hotplug does
not currently work so lets leave it aside and talk only about the
booting with the balloon pre-inflated case since that should work.

You seem to be using XAPI in which case xen-api@ is the right list to
ask for information. I believe you can set various VM.memory-* options
on the VM to control all this stuff.

>  For memory control we 
> need to set maxmem and send request to guest xenballon for new target 
> (via xenstore). This works without running xapi and squeezed (of course, 
> for VM start/reboot we need them), but simple memory management can be 
> done manually without helps of xapi/squeezed.

No. You might find that it works sometimes but going behind the
toolstack's back is not supported.

>  (Again, if I wrong, I do 
> really like to now where I wrong).  As far as I understand xapi writing 
> dynamic-min, dynamic-max to xenstore for domain and call squeezed via 
> xenstore-rpc to rebalance memory, and squeezed read request, read those 
> values, calculate new target and writes it  to xenstore for each domain.

You'd have to ask xen-api@ about that stuff. I'm sure you can disable
squeezed for a host or a domain without killing the daemon(s) and doing
things manually. Setting dynamic-min and max to the same thing probably
has the same effect.

> My current description (I can be wrong) of stuff happens during memory 
> resizing:

Step "0) Boot guest with static-max larger than initial allocation" is
important for this to work.

> 1) Set up maxmem
> 2) Send via memory/target target to xenballoon
> 3) Xenballoon request new  memory from hypervisor (or return back some of)
> 4) Xenballoon manipulate with domU memory management to allow use (or 
> snatch away) memory pages.
> >> I tested it with following python script (under xcp, with shutdowned
> >> squeezed to be sure not get 'reballanced'):
> >>
> >> xc.domain_setmaxmem(domid,memory)
> >> xs.write("","/local/domain/%i/memory/dynamic-min"%domid,str(memory*1024))
> >> xs.write("","/local/domain/%i/memory/dynamic-max"%domid,str(memory*1024))
> >> xs.write("","/local/domain/%i/memory/static-max"%domid,str(memory*1024))
> >> xs.write("","/local/domain/%i/memory/target"%domid,str(memory*1024))
> >>
> >> It works fine within noted ranges, but simply ignores any request higher
> >> them.
> > If you are stepping outside the toolstack and doing this sort of thing
> > behind its back then all bets are off and you can't really expect people
> > here to help you.
> >
> > Please try and reproduce the issue using the standard toolstack options.
> >
> I am very well understand that, so I've tested this (not with all kernel 
> versions) with normal XCP setup with default memory management:
> set up vm, make dyn-max=1GiB,static-max=2GiB, start vm, use xe 
> vm-memory-target-set to 2GiB - and memory is still 1GiB.
> I've tested this with few pv_ops kernels, including those on 
> xs-tools.iso (tested on XCP 0.5, 1.0 and 1.1, and even on XenServer 6) - 
> same result.

And which result is that? What does "doesn't work" actually mean?

Please take a look at
http://wiki.xen.org/wiki/Reporting_Bugs_against_Xen and consider
including your precise kernel configuration, appropriate log files,
dmesg etc etc. You might also be best off reporting as a separate thread
and since you are using XCP you should include xen-api@.

> 
> 
> P.S. Thank you for your attention to this issue.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 07:26:56 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 07:26:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RajEM-0003ec-P1; Wed, 14 Dec 2011 07:26:22 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RajEK-0003eV-IT
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 07:26:20 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1323847524!7171962!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTM5Mw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18625 invoked from network); 14 Dec 2011 07:25:24 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Dec 2011 07:25:24 -0000
X-IronPort-AV: E=Sophos;i="4.71,350,1320624000"; 
   d="scan'208";a="9453750"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Dec 2011 07:25:24 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 14 Dec 2011 07:25:23 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: George Shuklin <george.shuklin@gmail.com>
In-Reply-To: <4EE7D75B.6080209@gmail.com>
References: <4EE675A8.3030609@niemail.de>	<4EE71663.5040308@gmail.com>
	<CAJeBh4sxdNTxM_oLFAuA6Mw75=LaYysrpS5b8NsZMbkf_swNVw@mail.gmail.com>
	<4EE72A94.6040904@gmail.com> <4EE75080.1000909@citrix.com>
	<1323783428.20077.298.camel@zakaz.uk.xensource.com>
	<4EE7BC9B.6040003@gmail.com>
	<1323815427.20936.96.camel@dagon.hellion.org.uk>
	<4EE7D75B.6080209@gmail.com>
Organization: Citrix Systems, Inc.
Date: Wed, 14 Dec 2011 07:25:23 +0000
Message-ID: <1323847523.20936.110.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
X-Mailer: Evolution 2.32.3 
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	David Vrabel <david.vrabel@citrix.com>,
	"sandr8@gmail.com" <sandr8@gmail.com>
Subject: Re: [Xen-devel] a ton of kernel issues
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2011-12-13 at 22:53 +0000, George Shuklin wrote:
> On 14.12.2011 02:30, Ian Campbell wrote:
> > On Tue, 2011-12-13 at 20:59 +0000, George Shuklin wrote:
> >> On 13.12.2011 17:37, Ian Campbell wrote:
> >>>> This should work if memory hotplug is enabled.
> >>>>
> >>>> It is also supported without memory hotplug but this requires that the
> >>>> tools supply a suitable memory map that covers the largest
> >>>> memory-static-max limit you wish to support.  I'm not sure if the tools
> >>>> can do this yet.
> >>> With xl this should work using the "maxmem" option. (xm probably uses
> >>> the same name)
> >>>
> >> I'm not sure what maxmem do
> > maxmem sets static-max for the guest in the xl toolstack.
> 
> Well, I understand that, I simply don't understand what maxmem do with 
> domain in xen (the hypervisor part). My hypothesis is just put a limit 
> for amount of allocated PFN for domain.

It controls precisely the behaviour you need! Try "maxmem=2048" and
"memory=1024" in your guest configuration, it should boot with 1G of RAM
and allow you to balloon to 2G and back.

The maxmem option mainly passes an appropriate e820 table to the guest
to cause it to allocate enough space for 2G of pages.

On some versions of Linux you might also need to add mem=2G to the
kernel command line to work around a bug. That is fixed in the most
recent versions though.

> >
> >> but I can say, this option does not allow
> >> to go beyond initial boot memory for pv_ops kernels and beyond
> >> static-max memory for -xen kernel.
> > AFAIK the toolstack support for memory hotplug (i.e. growing beyond
> > static-max) does not yet exist.
> 
> As far as I know toolstack is not really do some work for this (if I 
> wrong I'll be really appreciated for information).

I'm not really sure what you are referring to here. Memory hotplug does
not currently work so lets leave it aside and talk only about the
booting with the balloon pre-inflated case since that should work.

You seem to be using XAPI in which case xen-api@ is the right list to
ask for information. I believe you can set various VM.memory-* options
on the VM to control all this stuff.

>  For memory control we 
> need to set maxmem and send request to guest xenballon for new target 
> (via xenstore). This works without running xapi and squeezed (of course, 
> for VM start/reboot we need them), but simple memory management can be 
> done manually without helps of xapi/squeezed.

No. You might find that it works sometimes but going behind the
toolstack's back is not supported.

>  (Again, if I wrong, I do 
> really like to now where I wrong).  As far as I understand xapi writing 
> dynamic-min, dynamic-max to xenstore for domain and call squeezed via 
> xenstore-rpc to rebalance memory, and squeezed read request, read those 
> values, calculate new target and writes it  to xenstore for each domain.

You'd have to ask xen-api@ about that stuff. I'm sure you can disable
squeezed for a host or a domain without killing the daemon(s) and doing
things manually. Setting dynamic-min and max to the same thing probably
has the same effect.

> My current description (I can be wrong) of stuff happens during memory 
> resizing:

Step "0) Boot guest with static-max larger than initial allocation" is
important for this to work.

> 1) Set up maxmem
> 2) Send via memory/target target to xenballoon
> 3) Xenballoon request new  memory from hypervisor (or return back some of)
> 4) Xenballoon manipulate with domU memory management to allow use (or 
> snatch away) memory pages.
> >> I tested it with following python script (under xcp, with shutdowned
> >> squeezed to be sure not get 'reballanced'):
> >>
> >> xc.domain_setmaxmem(domid,memory)
> >> xs.write("","/local/domain/%i/memory/dynamic-min"%domid,str(memory*1024))
> >> xs.write("","/local/domain/%i/memory/dynamic-max"%domid,str(memory*1024))
> >> xs.write("","/local/domain/%i/memory/static-max"%domid,str(memory*1024))
> >> xs.write("","/local/domain/%i/memory/target"%domid,str(memory*1024))
> >>
> >> It works fine within noted ranges, but simply ignores any request higher
> >> them.
> > If you are stepping outside the toolstack and doing this sort of thing
> > behind its back then all bets are off and you can't really expect people
> > here to help you.
> >
> > Please try and reproduce the issue using the standard toolstack options.
> >
> I am very well understand that, so I've tested this (not with all kernel 
> versions) with normal XCP setup with default memory management:
> set up vm, make dyn-max=1GiB,static-max=2GiB, start vm, use xe 
> vm-memory-target-set to 2GiB - and memory is still 1GiB.
> I've tested this with few pv_ops kernels, including those on 
> xs-tools.iso (tested on XCP 0.5, 1.0 and 1.1, and even on XenServer 6) - 
> same result.

And which result is that? What does "doesn't work" actually mean?

Please take a look at
http://wiki.xen.org/wiki/Reporting_Bugs_against_Xen and consider
including your precise kernel configuration, appropriate log files,
dmesg etc etc. You might also be best off reporting as a separate thread
and since you are using XCP you should include xen-api@.

> 
> 
> P.S. Thank you for your attention to this issue.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 07:49:30 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 07:49:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RajaC-00041E-15; Wed, 14 Dec 2011 07:48:56 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fajar@fajar.net>) id 1RajaA-000419-Vy
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 07:48:55 +0000
X-Env-Sender: fajar@fajar.net
X-Msg-Ref: server-6.tower-21.messagelabs.com!1323848878!7980789!1
X-Originating-IP: [209.85.213.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28612 invoked from network); 14 Dec 2011 07:47:59 -0000
Received: from mail-yx0-f171.google.com (HELO mail-yx0-f171.google.com)
	(209.85.213.171)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Dec 2011 07:47:59 -0000
Received: by yenr9 with SMTP id r9so8026608yen.30
	for <xen-devel@lists.xensource.com>;
	Tue, 13 Dec 2011 23:47:58 -0800 (PST)
MIME-Version: 1.0
Received: by 10.236.176.3 with SMTP id a3mr9652889yhm.111.1323848878445; Tue,
	13 Dec 2011 23:47:58 -0800 (PST)
Received: by 10.147.156.11 with HTTP; Tue, 13 Dec 2011 23:47:58 -0800 (PST)
In-Reply-To: <4EE7BE1B.6070509@gmail.com>
References: <4EE675A8.3030609@niemail.de> <4EE71663.5040308@gmail.com>
	<CAJeBh4sxdNTxM_oLFAuA6Mw75=LaYysrpS5b8NsZMbkf_swNVw@mail.gmail.com>
	<4EE72A94.6040904@gmail.com> <4EE75080.1000909@citrix.com>
	<4EE7BE1B.6070509@gmail.com>
Date: Wed, 14 Dec 2011 14:47:58 +0700
Message-ID: <CAG1y0sfbgrCsgLgF5-PZ24vzznwTjrPHkWMwAJO7qKYnVT+ODg@mail.gmail.com>
From: "Fajar A. Nugraha" <list@fajar.net>
To: George Shuklin <george.shuklin@gmail.com>
Cc: xen-devel@lists.xensource.com, David Vrabel <david.vrabel@citrix.com>,
	sandr8@gmail.com
Subject: Re: [Xen-devel] a ton of kernel issues
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Dec 14, 2011 at 4:05 AM, George Shuklin
<george.shuklin@gmail.com> wrote:
> Well... For us it make HUGE difference. We running cloud with very precise
> accounting of =A0fast automaric memory allocation for customer's domains =
and
> we account them for ... em... KiB*hr value, so if we account domains based
> on xc.get_domain_memkb value and customers saw difference between TotalMem
> and our values this will make them feel like we cheating. We not greedy a=
nd
> ready to 'cut' our mem_kb value to their TotalMem, but I hasn't found any
> formula for that (calculate TotalMem from static-max and dom_kb values) a=
nd
> I can't trust any data from customer's domains (except request for memory=
 we
> accept, serve and happily take money for 'more memory').
>
> It sounds ridiculous, but we avoiding pv_ops kernels usage due that little
> ~50Mb steal. We stuck with -xen kernels (forward porting from SUSE and
> native CentOS 2.6.18-xen). I don't know what we will do in the future, but
> right now PV-ops is not good...

Why not just explain what really happened in a noob-friendly language?

For example, when buying a computer with built-in graphic card,
MemTotal is always lower than the ammount of memory actually
installed. Yet a simple explanation "some of the memory is used by the
built-in graphic card" is enough, without having to go into details of
what is the formula to calculate how much memory actualy used.

-- =

Fajar

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 07:49:30 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 07:49:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RajaC-00041E-15; Wed, 14 Dec 2011 07:48:56 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fajar@fajar.net>) id 1RajaA-000419-Vy
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 07:48:55 +0000
X-Env-Sender: fajar@fajar.net
X-Msg-Ref: server-6.tower-21.messagelabs.com!1323848878!7980789!1
X-Originating-IP: [209.85.213.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28612 invoked from network); 14 Dec 2011 07:47:59 -0000
Received: from mail-yx0-f171.google.com (HELO mail-yx0-f171.google.com)
	(209.85.213.171)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Dec 2011 07:47:59 -0000
Received: by yenr9 with SMTP id r9so8026608yen.30
	for <xen-devel@lists.xensource.com>;
	Tue, 13 Dec 2011 23:47:58 -0800 (PST)
MIME-Version: 1.0
Received: by 10.236.176.3 with SMTP id a3mr9652889yhm.111.1323848878445; Tue,
	13 Dec 2011 23:47:58 -0800 (PST)
Received: by 10.147.156.11 with HTTP; Tue, 13 Dec 2011 23:47:58 -0800 (PST)
In-Reply-To: <4EE7BE1B.6070509@gmail.com>
References: <4EE675A8.3030609@niemail.de> <4EE71663.5040308@gmail.com>
	<CAJeBh4sxdNTxM_oLFAuA6Mw75=LaYysrpS5b8NsZMbkf_swNVw@mail.gmail.com>
	<4EE72A94.6040904@gmail.com> <4EE75080.1000909@citrix.com>
	<4EE7BE1B.6070509@gmail.com>
Date: Wed, 14 Dec 2011 14:47:58 +0700
Message-ID: <CAG1y0sfbgrCsgLgF5-PZ24vzznwTjrPHkWMwAJO7qKYnVT+ODg@mail.gmail.com>
From: "Fajar A. Nugraha" <list@fajar.net>
To: George Shuklin <george.shuklin@gmail.com>
Cc: xen-devel@lists.xensource.com, David Vrabel <david.vrabel@citrix.com>,
	sandr8@gmail.com
Subject: Re: [Xen-devel] a ton of kernel issues
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Dec 14, 2011 at 4:05 AM, George Shuklin
<george.shuklin@gmail.com> wrote:
> Well... For us it make HUGE difference. We running cloud with very precise
> accounting of =A0fast automaric memory allocation for customer's domains =
and
> we account them for ... em... KiB*hr value, so if we account domains based
> on xc.get_domain_memkb value and customers saw difference between TotalMem
> and our values this will make them feel like we cheating. We not greedy a=
nd
> ready to 'cut' our mem_kb value to their TotalMem, but I hasn't found any
> formula for that (calculate TotalMem from static-max and dom_kb values) a=
nd
> I can't trust any data from customer's domains (except request for memory=
 we
> accept, serve and happily take money for 'more memory').
>
> It sounds ridiculous, but we avoiding pv_ops kernels usage due that little
> ~50Mb steal. We stuck with -xen kernels (forward porting from SUSE and
> native CentOS 2.6.18-xen). I don't know what we will do in the future, but
> right now PV-ops is not good...

Why not just explain what really happened in a noob-friendly language?

For example, when buying a computer with built-in graphic card,
MemTotal is always lower than the ammount of memory actually
installed. Yet a simple explanation "some of the memory is used by the
built-in graphic card" is enough, without having to go into details of
what is the formula to calculate how much memory actualy used.

-- =

Fajar

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 08:07:47 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 08:07:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rajrx-0004mT-K9; Wed, 14 Dec 2011 08:07:17 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xieliwei@gmail.com>) id 1Rajrv-0004mO-Pu
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 08:07:16 +0000
X-Env-Sender: xieliwei@gmail.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1323849978!1865188!1
X-Originating-IP: [209.85.213.43]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24255 invoked from network); 14 Dec 2011 08:06:20 -0000
Received: from mail-yw0-f43.google.com (HELO mail-yw0-f43.google.com)
	(209.85.213.43)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Dec 2011 08:06:20 -0000
Received: by yhr49 with SMTP id 49so21380620yhr.30
	for <xen-devel@lists.xensource.com>;
	Wed, 14 Dec 2011 00:06:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:from:date:message-id:subject:to:content-type;
	bh=mxnMk3cYpPDUK4kgxUzlhIwEKFFqJtuXcban24oGibw=;
	b=IeUIeqdDA8UtQHLWthLJHIJYnhIFnFr/BXwQvMpuzTRLqDtnLSY6bYEvfwsUIrLCfx
	XfQx0mux/LxpchYEQtMx+Rp0TrpVpdtbysftJX5n/0+kJ9UM6eEDoHlut1bhIOJo3rny
	V5XZObYin5XzLmCHGPzo4HaNEWZxGK8KUwsSg=
Received: by 10.236.174.3 with SMTP id w3mr9750462yhl.117.1323849978379; Wed,
	14 Dec 2011 00:06:18 -0800 (PST)
MIME-Version: 1.0
Received: by 10.100.10.4 with HTTP; Wed, 14 Dec 2011 00:05:57 -0800 (PST)
From: Liwei <xieliwei@gmail.com>
Date: Wed, 14 Dec 2011 16:05:57 +0800
Message-ID: <CAPE0SYwsqRKDuPTz66r0nTVPYcsFx0Dk2j0pWpCiHELuU5W2iA@mail.gmail.com>
To: xen-devel <xen-devel@lists.xensource.com>
Subject: [Xen-devel] PTE Write access is not set
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hello list,
    Using the 3.1.5 kernel and 4.1.3-rc1-pre xen (Latest ChangeSet:
Tue Dec 06 10:53:12 2011 +0000 23199:d9f8316a8291), these crashes
occur after about a day or so of running a HVM:
=================8<=================
(XEN) realmode.c:115:d9 Failed to emulate insn.
(XEN) realmode.c:165:d9 Real-mode emulation failed @ e40a:00005f6c: d9
33 01 fc 30 34
(XEN) domain_crash called from realmode.c:166
(XEN) Domain 9 (vcpu#0) crashed on cpu#6:
(XEN) ----[ Xen-4.1.3-rc1-pre  x86_64  debug=n  Not tainted ]----
(XEN) CPU:    6
(XEN) RIP:    e40a:[<0000000000005f6c>]
(XEN) RFLAGS: 0000000000010002   CONTEXT: hvm guest
(XEN) rax: 000000000000e7e5   rbx: 0000000000000000   rcx: 00000000000d0000
(XEN) rdx: 00000000000001f7   rsi: 0000000000000000   rdi: 0000000000000dba
(XEN) rbp: 0000000000000182   rsp: 0000000000000db0   r8:  0000000000000000
(XEN) r9:  0000000000000000   r10: 0000000000000000   r11: 0000000000000000
(XEN) r12: 0000000000000000   r13: 0000000000000000   r14: 0000000000000000
(XEN) r15: 0000000000000000   cr0: 0000000000000010   cr4: 0000000000000000
(XEN) cr3: 0000000000000000   cr2: 0000000000000000
(XEN) ds: 9fc0   es: 9e00   fs: 0000   gs: 0000   ss: 9e00   cs: e40a
=================8<=================
(XEN) realmode.c:115:d5 Failed to emulate insn.
(XEN) realmode.c:165:d5 Real-mode emulation failed @ c5d5:000242bc: d9
33 01 fc 30 34
(XEN) domain_crash called from realmode.c:166
(XEN) Domain 5 (vcpu#0) crashed on cpu#0:
(XEN) ----[ Xen-4.1.3-rc1-pre  x86_64  debug=n  Not tainted ]----
(XEN) CPU:    0
(XEN) RIP:    c5d5:[<00000000000242bc>]
(XEN) RFLAGS: 0000000000010013   CONTEXT: hvm guest
(XEN) rax: 000000000000001b   rbx: 0000000000000702   rcx: 0000000000010ba7
(XEN) rdx: 0000000000008fd5   rsi: 0000000000001333   rdi: 000000000000900e
(XEN) rbp: 000000000000703e   rsp: 000000000000c5cf   r8:  0000000000000000
(XEN) r9:  0000000000000000   r10: 0000000000000000   r11: 0000000000000000
(XEN) r12: 0000000000000000   r13: 0000000000000000   r14: 0000000000000000
(XEN) r15: 0000000000000000   cr0: 0000000000000010   cr4: 0000000000000000
(XEN) cr3: 0000000000000000   cr2: 0000000000000000
(XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: 0000   cs: c5d5
(XEN) [VT-D]iommu.c:856: iommu_fault_status: Primary Pending Fault
(XEN) [VT-D]iommu.c:831: DMAR:[DMA Write] Request device [0d:00.1]
fault addr d8964f44000, iommu reg = ffff82c3fff57000
(XEN) DMAR:[fault reason 05h] PTE Write access is not set
(XEN) print_vtd_entries: iommu = ffff83045ce565c0 bdf = d:0.1 gmfn = d8964f44
(XEN)     root_entry = ffff8304519d1000
(XEN)     root_entry[d] = 4127af001
(XEN)     context = ffff8304127af000
(XEN)     context[1] = 2_414aca001
(XEN)     l4 = ffff830414aca000
(XEN)     l4_index = 1b
(XEN)     l4[1b] = 0
(XEN)     l4[1b] not present
=================8<=================

    If I try to restart the crashed VM, the same crash always occurs
again during POST (the last thing I see on the VNC console is the BIOS
boot, before the connection terminates). A dom0 reboot is necessary to
get things to work again.
    0d:00.1 is part of an Intel 82575GB quad port network adapter. The
adapter contains three ports, 0d:00.0, 0d:00.1, 0e:00.0, 0e:00.1. Each
of them is assigned to a VM. So far the crashes have occurred to VMs
using 0d:00.1, 0e:00.0 and 0e:00.1. (Pretty sure a crash involving
0d:00.0 will come soon).
    Is this a potential bug, or (more likely?) problematic hardware?

The relevant PCI subtree looks like this:
=================8<=================
 \-[0000:00]-+-00.0
             +-03.0-[01]--+-00.0
             |            \-00.1
             +-05.0-[02-0e]----00.0-[03-0e]--+-00.0-[04]----00.0

+-02.0-[05-0a]----00.0-[06-0a]--+-02.0-[07]----00.0
                                             |
      +-03.0-[08]----00.0
                                             |
      +-04.0-[09]----00.0
                                             |
      \-05.0-[0a]----00.0

\-03.0-[0b-0e]----00.0-[0c-0e]--+-02.0-[0d]--+-00.0

      |            \-00.1

      \-04.0-[0e]--+-00.0

                   \-00.1
=================8<=================

Thanks!

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 08:07:47 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 08:07:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rajrx-0004mT-K9; Wed, 14 Dec 2011 08:07:17 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xieliwei@gmail.com>) id 1Rajrv-0004mO-Pu
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 08:07:16 +0000
X-Env-Sender: xieliwei@gmail.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1323849978!1865188!1
X-Originating-IP: [209.85.213.43]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24255 invoked from network); 14 Dec 2011 08:06:20 -0000
Received: from mail-yw0-f43.google.com (HELO mail-yw0-f43.google.com)
	(209.85.213.43)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Dec 2011 08:06:20 -0000
Received: by yhr49 with SMTP id 49so21380620yhr.30
	for <xen-devel@lists.xensource.com>;
	Wed, 14 Dec 2011 00:06:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:from:date:message-id:subject:to:content-type;
	bh=mxnMk3cYpPDUK4kgxUzlhIwEKFFqJtuXcban24oGibw=;
	b=IeUIeqdDA8UtQHLWthLJHIJYnhIFnFr/BXwQvMpuzTRLqDtnLSY6bYEvfwsUIrLCfx
	XfQx0mux/LxpchYEQtMx+Rp0TrpVpdtbysftJX5n/0+kJ9UM6eEDoHlut1bhIOJo3rny
	V5XZObYin5XzLmCHGPzo4HaNEWZxGK8KUwsSg=
Received: by 10.236.174.3 with SMTP id w3mr9750462yhl.117.1323849978379; Wed,
	14 Dec 2011 00:06:18 -0800 (PST)
MIME-Version: 1.0
Received: by 10.100.10.4 with HTTP; Wed, 14 Dec 2011 00:05:57 -0800 (PST)
From: Liwei <xieliwei@gmail.com>
Date: Wed, 14 Dec 2011 16:05:57 +0800
Message-ID: <CAPE0SYwsqRKDuPTz66r0nTVPYcsFx0Dk2j0pWpCiHELuU5W2iA@mail.gmail.com>
To: xen-devel <xen-devel@lists.xensource.com>
Subject: [Xen-devel] PTE Write access is not set
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hello list,
    Using the 3.1.5 kernel and 4.1.3-rc1-pre xen (Latest ChangeSet:
Tue Dec 06 10:53:12 2011 +0000 23199:d9f8316a8291), these crashes
occur after about a day or so of running a HVM:
=================8<=================
(XEN) realmode.c:115:d9 Failed to emulate insn.
(XEN) realmode.c:165:d9 Real-mode emulation failed @ e40a:00005f6c: d9
33 01 fc 30 34
(XEN) domain_crash called from realmode.c:166
(XEN) Domain 9 (vcpu#0) crashed on cpu#6:
(XEN) ----[ Xen-4.1.3-rc1-pre  x86_64  debug=n  Not tainted ]----
(XEN) CPU:    6
(XEN) RIP:    e40a:[<0000000000005f6c>]
(XEN) RFLAGS: 0000000000010002   CONTEXT: hvm guest
(XEN) rax: 000000000000e7e5   rbx: 0000000000000000   rcx: 00000000000d0000
(XEN) rdx: 00000000000001f7   rsi: 0000000000000000   rdi: 0000000000000dba
(XEN) rbp: 0000000000000182   rsp: 0000000000000db0   r8:  0000000000000000
(XEN) r9:  0000000000000000   r10: 0000000000000000   r11: 0000000000000000
(XEN) r12: 0000000000000000   r13: 0000000000000000   r14: 0000000000000000
(XEN) r15: 0000000000000000   cr0: 0000000000000010   cr4: 0000000000000000
(XEN) cr3: 0000000000000000   cr2: 0000000000000000
(XEN) ds: 9fc0   es: 9e00   fs: 0000   gs: 0000   ss: 9e00   cs: e40a
=================8<=================
(XEN) realmode.c:115:d5 Failed to emulate insn.
(XEN) realmode.c:165:d5 Real-mode emulation failed @ c5d5:000242bc: d9
33 01 fc 30 34
(XEN) domain_crash called from realmode.c:166
(XEN) Domain 5 (vcpu#0) crashed on cpu#0:
(XEN) ----[ Xen-4.1.3-rc1-pre  x86_64  debug=n  Not tainted ]----
(XEN) CPU:    0
(XEN) RIP:    c5d5:[<00000000000242bc>]
(XEN) RFLAGS: 0000000000010013   CONTEXT: hvm guest
(XEN) rax: 000000000000001b   rbx: 0000000000000702   rcx: 0000000000010ba7
(XEN) rdx: 0000000000008fd5   rsi: 0000000000001333   rdi: 000000000000900e
(XEN) rbp: 000000000000703e   rsp: 000000000000c5cf   r8:  0000000000000000
(XEN) r9:  0000000000000000   r10: 0000000000000000   r11: 0000000000000000
(XEN) r12: 0000000000000000   r13: 0000000000000000   r14: 0000000000000000
(XEN) r15: 0000000000000000   cr0: 0000000000000010   cr4: 0000000000000000
(XEN) cr3: 0000000000000000   cr2: 0000000000000000
(XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: 0000   cs: c5d5
(XEN) [VT-D]iommu.c:856: iommu_fault_status: Primary Pending Fault
(XEN) [VT-D]iommu.c:831: DMAR:[DMA Write] Request device [0d:00.1]
fault addr d8964f44000, iommu reg = ffff82c3fff57000
(XEN) DMAR:[fault reason 05h] PTE Write access is not set
(XEN) print_vtd_entries: iommu = ffff83045ce565c0 bdf = d:0.1 gmfn = d8964f44
(XEN)     root_entry = ffff8304519d1000
(XEN)     root_entry[d] = 4127af001
(XEN)     context = ffff8304127af000
(XEN)     context[1] = 2_414aca001
(XEN)     l4 = ffff830414aca000
(XEN)     l4_index = 1b
(XEN)     l4[1b] = 0
(XEN)     l4[1b] not present
=================8<=================

    If I try to restart the crashed VM, the same crash always occurs
again during POST (the last thing I see on the VNC console is the BIOS
boot, before the connection terminates). A dom0 reboot is necessary to
get things to work again.
    0d:00.1 is part of an Intel 82575GB quad port network adapter. The
adapter contains three ports, 0d:00.0, 0d:00.1, 0e:00.0, 0e:00.1. Each
of them is assigned to a VM. So far the crashes have occurred to VMs
using 0d:00.1, 0e:00.0 and 0e:00.1. (Pretty sure a crash involving
0d:00.0 will come soon).
    Is this a potential bug, or (more likely?) problematic hardware?

The relevant PCI subtree looks like this:
=================8<=================
 \-[0000:00]-+-00.0
             +-03.0-[01]--+-00.0
             |            \-00.1
             +-05.0-[02-0e]----00.0-[03-0e]--+-00.0-[04]----00.0

+-02.0-[05-0a]----00.0-[06-0a]--+-02.0-[07]----00.0
                                             |
      +-03.0-[08]----00.0
                                             |
      +-04.0-[09]----00.0
                                             |
      \-05.0-[0a]----00.0

\-03.0-[0b-0e]----00.0-[0c-0e]--+-02.0-[0d]--+-00.0

      |            \-00.1

      \-04.0-[0e]--+-00.0

                   \-00.1
=================8<=================

Thanks!

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 08:25:22 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 08:25:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rak8u-0004xO-AD; Wed, 14 Dec 2011 08:24:48 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rak8s-0004xI-Lk
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 08:24:46 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1323851031!1874884!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTM5Mw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12245 invoked from network); 14 Dec 2011 08:23:51 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Dec 2011 08:23:51 -0000
X-IronPort-AV: E=Sophos;i="4.71,350,1320624000"; 
   d="scan'208";a="9454450"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Dec 2011 08:23:29 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 14 Dec 2011 08:23:28 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Wentao Zhang <wnlo.zwt@gmail.com>
In-Reply-To: <CAJZuLff7otKaraAYF_wFG7vRzgVcFNg9cbos2UVS=M0pMZ34zQ@mail.gmail.com>
References: <CAJZuLfe+QsePaJps=3SdG4ALYs0PixB3xcrb0nx1+v-o0VmMaw@mail.gmail.com>
	<CAJZuLff7otKaraAYF_wFG7vRzgVcFNg9cbos2UVS=M0pMZ34zQ@mail.gmail.com>
Organization: Citrix Systems, Inc.
Date: Wed, 14 Dec 2011 08:23:28 +0000
Message-ID: <1323851008.20936.112.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
X-Mailer: Evolution 2.32.3 
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] how to make the new python codes effective
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2011-12-14 at 07:19 +0000, Wentao Zhang wrote:
> 
> Hi, 
>     Something troubles me several days.  I had changed some codes in
> tools/python/xen/xm/main.py, but how can I make them effective ?
> I had tried with 'make xen && make install-xen', but failed ! 

"make tools && make tools-install" ought to do it (the "xen" targets
relate to the hypervisor itself).

Note that xend is unmaintained and deprecated in xen-unstable. libxl/xl
is the preferred toolstack for all new development.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 08:25:22 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 08:25:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rak8u-0004xO-AD; Wed, 14 Dec 2011 08:24:48 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rak8s-0004xI-Lk
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 08:24:46 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1323851031!1874884!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTM5Mw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12245 invoked from network); 14 Dec 2011 08:23:51 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Dec 2011 08:23:51 -0000
X-IronPort-AV: E=Sophos;i="4.71,350,1320624000"; 
   d="scan'208";a="9454450"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Dec 2011 08:23:29 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 14 Dec 2011 08:23:28 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Wentao Zhang <wnlo.zwt@gmail.com>
In-Reply-To: <CAJZuLff7otKaraAYF_wFG7vRzgVcFNg9cbos2UVS=M0pMZ34zQ@mail.gmail.com>
References: <CAJZuLfe+QsePaJps=3SdG4ALYs0PixB3xcrb0nx1+v-o0VmMaw@mail.gmail.com>
	<CAJZuLff7otKaraAYF_wFG7vRzgVcFNg9cbos2UVS=M0pMZ34zQ@mail.gmail.com>
Organization: Citrix Systems, Inc.
Date: Wed, 14 Dec 2011 08:23:28 +0000
Message-ID: <1323851008.20936.112.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
X-Mailer: Evolution 2.32.3 
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] how to make the new python codes effective
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2011-12-14 at 07:19 +0000, Wentao Zhang wrote:
> 
> Hi, 
>     Something troubles me several days.  I had changed some codes in
> tools/python/xen/xm/main.py, but how can I make them effective ?
> I had tried with 'make xen && make install-xen', but failed ! 

"make tools && make tools-install" ought to do it (the "xen" targets
relate to the hypervisor itself).

Note that xend is unmaintained and deprecated in xen-unstable. libxl/xl
is the preferred toolstack for all new development.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 09:01:47 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 09:01:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RakiB-0005Rj-Gc; Wed, 14 Dec 2011 09:01:15 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <it@niemail.de>) id 1Raki9-0005Re-Jf
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 09:01:13 +0000
X-Env-Sender: it@niemail.de
X-Msg-Ref: server-5.tower-27.messagelabs.com!1323853183!46636551!1
X-Originating-IP: [80.252.97.80]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuMjUyLjk3LjgwID0+IDIzNTMy\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11900 invoked from network); 14 Dec 2011 08:59:43 -0000
Received: from mailout.artfiles.de (HELO mailout.artfiles.de) (80.252.97.80)
	by server-5.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Dec 2011 08:59:43 -0000
Received: from [80.252.98.156] (helo=tim-everss-macbook-pro.local)
	auth=te@artfiles.de by mailout.artfiles.de with esmtpa (Exim 4.72)
	id 1RakhK-0005pS-QX; Wed, 14 Dec 2011 10:00:22 +0100
Message-ID: <4EE86598.2060905@niemail.de>
Date: Wed, 14 Dec 2011 10:00:08 +0100
From: Tim Evers <it@niemail.de>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6;
	rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
References: <4EE675A8.3030609@niemail.de>
	<20111212215652.GA12106@andromeda.dapyr.net>
In-Reply-To: <20111212215652.GA12106@andromeda.dapyr.net>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] a ton of kernel issues
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Am 12.12.11 22:56, schrieb Konrad Rzeszutek Wilk:

> Did you try the latest and greatest? Meaning anything that is based on a
> 3.0 (or higher) kernel?

Not the latest. Oneric Kernel is 3.0. Unfortunately I'm short on time
right now but I will setup a complete testscenario and report back.

>> a migrated domu, some crash right at the migration and some crash right
>> at the start if vcpu_avail > vcpus.
> 
> Is this with more than 32 CPUs?

No, happens with vcpu_avail=2 and vcpus=1.

>> 
>> I've tested
>> 
>> xen-4.0
>> xen-4.1
>> 
>> debian 6 32 and 64 bit (2.6.32-x kernel)
>> ubuntu lucid 32 and 64 bit kernels including karmic, natty and even
>> oneric backports
> 
> backports? Why not just .

Didn't get that. Till now I was trying to get away with standard
distro's ressources since I have to give some of the work in others
hands which I do not want to confront with kernel-compiling stuff.

> Looking at your BUG, did you look in the .config to see if you
> had MAXSMP or NR_CPUS defined? If you had MAXSMP, there was a bug
> for that fixed in 2.6.39 time-frame (I think). And if you look
> at the NR_CPUS, do you see the NR_CPUs > 0 virtual_cpus?
> 
> 
> Otherwise, does the virgin kernel boot if you specify maxvcpus=vcpus
> and then later on use xm to take CPUs away?

Yes, but It crashes sometimes if I re-plug the CPUs. I will include this
in my test scenario.

> 
>> 
>> I've put some questions on the users mailinglist, wrote bug reports but
>> today after two month work on this I'm as stuck as one can get.
> 
> Uh? Hm somehow we [kernel engineers] never got copied on it.

Well, thanks for your prompt reply right now. I will do my best to put
all my findings together in a way that helps solving the problems (or
finding the point where I made the big mistake:)

Regards,

Tim


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 09:01:47 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 09:01:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RakiB-0005Rj-Gc; Wed, 14 Dec 2011 09:01:15 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <it@niemail.de>) id 1Raki9-0005Re-Jf
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 09:01:13 +0000
X-Env-Sender: it@niemail.de
X-Msg-Ref: server-5.tower-27.messagelabs.com!1323853183!46636551!1
X-Originating-IP: [80.252.97.80]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuMjUyLjk3LjgwID0+IDIzNTMy\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11900 invoked from network); 14 Dec 2011 08:59:43 -0000
Received: from mailout.artfiles.de (HELO mailout.artfiles.de) (80.252.97.80)
	by server-5.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Dec 2011 08:59:43 -0000
Received: from [80.252.98.156] (helo=tim-everss-macbook-pro.local)
	auth=te@artfiles.de by mailout.artfiles.de with esmtpa (Exim 4.72)
	id 1RakhK-0005pS-QX; Wed, 14 Dec 2011 10:00:22 +0100
Message-ID: <4EE86598.2060905@niemail.de>
Date: Wed, 14 Dec 2011 10:00:08 +0100
From: Tim Evers <it@niemail.de>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6;
	rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
References: <4EE675A8.3030609@niemail.de>
	<20111212215652.GA12106@andromeda.dapyr.net>
In-Reply-To: <20111212215652.GA12106@andromeda.dapyr.net>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] a ton of kernel issues
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Am 12.12.11 22:56, schrieb Konrad Rzeszutek Wilk:

> Did you try the latest and greatest? Meaning anything that is based on a
> 3.0 (or higher) kernel?

Not the latest. Oneric Kernel is 3.0. Unfortunately I'm short on time
right now but I will setup a complete testscenario and report back.

>> a migrated domu, some crash right at the migration and some crash right
>> at the start if vcpu_avail > vcpus.
> 
> Is this with more than 32 CPUs?

No, happens with vcpu_avail=2 and vcpus=1.

>> 
>> I've tested
>> 
>> xen-4.0
>> xen-4.1
>> 
>> debian 6 32 and 64 bit (2.6.32-x kernel)
>> ubuntu lucid 32 and 64 bit kernels including karmic, natty and even
>> oneric backports
> 
> backports? Why not just .

Didn't get that. Till now I was trying to get away with standard
distro's ressources since I have to give some of the work in others
hands which I do not want to confront with kernel-compiling stuff.

> Looking at your BUG, did you look in the .config to see if you
> had MAXSMP or NR_CPUS defined? If you had MAXSMP, there was a bug
> for that fixed in 2.6.39 time-frame (I think). And if you look
> at the NR_CPUS, do you see the NR_CPUs > 0 virtual_cpus?
> 
> 
> Otherwise, does the virgin kernel boot if you specify maxvcpus=vcpus
> and then later on use xm to take CPUs away?

Yes, but It crashes sometimes if I re-plug the CPUs. I will include this
in my test scenario.

> 
>> 
>> I've put some questions on the users mailinglist, wrote bug reports but
>> today after two month work on this I'm as stuck as one can get.
> 
> Uh? Hm somehow we [kernel engineers] never got copied on it.

Well, thanks for your prompt reply right now. I will do my best to put
all my findings together in a way that helps solving the problems (or
finding the point where I made the big mistake:)

Regards,

Tim


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 09:04:56 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 09: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.xensource.com>)
	id 1RaklM-0005Xd-4H; Wed, 14 Dec 2011 09:04:32 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pasik@iki.fi>) id 1RaklK-0005XV-P5
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 09:04:30 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-10.tower-27.messagelabs.com!1323853380!47790985!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiAzOTQyMzA=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32192 invoked from network); 14 Dec 2011 09:03:00 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-10.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Dec 2011 09:03:00 -0000
X-Originating-Ip: [194.89.68.22]
Received: from ydin.reaktio.net (reaktio.net [194.89.68.22])
	by smtp.tele.fi (Postfix) with ESMTP id 4D84A267C;
	Wed, 14 Dec 2011 11:03:39 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 0BA1220056; Wed, 14 Dec 2011 11:03:39 +0200 (EET)
Date: Wed, 14 Dec 2011 11:03:38 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <20111214090338.GS12984@reaktio.net>
References: <alpine.DEB.2.00.1110192358140.15667@vega-a.dur.ac.uk>
	<1319293366.98429.YahooMailClassic@web65903.mail.ac4.yahoo.com>
	<20111116184108.GM12984@reaktio.net>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20111116184108.GM12984@reaktio.net>
User-Agent: Mutt/1.5.18 (2008-05-17)
Cc: xen-devel@lists.xensource.com, Ian Campbell <Ian.Campbell@citrix.com>,
	M A Young <m.a.young@durham.ac.uk>
Subject: Re: [Xen-devel] [PATCH 0 of 6] pygrub fixes to support a Fedora
	16	guest
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Nov 16, 2011 at 08:41:08PM +0200, Pasi K=E4rkk=E4inen wrote:
> On Sat, Oct 22, 2011 at 07:22:46AM -0700, Boris Derzhavets wrote:
> >    Please, back port  to xen-4.1-testing.hg.
> > =

> =

> Yep, this pygrub patch series is already in xen-unstable.hg,
> and it should be backported to xen-4.1-testing.hg aswell,
> so upcoming Xen 4.1.3 will support F16 PV domUs.
> =

> (It's already included in Michael's Fedora 16 xen rpms,
> and works well there.)
> =


Fedora 16 Xen 4.1.2 src.rpm is for example here:
ftp://ftp.funet.fi/pub/mirrors/fedora.redhat.com/pub/fedora/linux/updates/1=
6/SRPMS/xen-4.1.2-2.fc16.src.rpm

and that includes a working backport of these pygryb patches,
in a case they don't apply cleanly to xen-4.1-testing.hg.

-- Pasi


> =

> =

> > =

> >    --- On Wed, 10/19/11, M A Young <m.a.young@durham.ac.uk> wrote:
> > =

> >      From: M A Young <m.a.young@durham.ac.uk>
> >      Subject: [Xen-devel] [PATCH 0 of 6] pygrub fixes to support a Fedo=
ra 16
> >      guest
> >      To: xen-devel@lists.xensource.com
> >      Cc: "Ian Campbell" <Ian.Campbell@citrix.com>
> >      Date: Wednesday, October 19, 2011, 7:02 PM
> > =

> >      This series contains patches that may be needed to allow pygrub to=
 boot
> >      a Fedora 16 guest.
> > =

> >      By default, Fedora 16 has GPT partitions and uses grub2. The first=
 GPT
> >      partition is a grub2 boot partition to store the grub2 code. The s=
econd
> >      GPT partition contains the /boot filesystem with the kernel and
> >      initramfs files and grub2 configuration files. The remaining space=
 is an
> >      LVM partition containing the remaining file systems.
> > =

> >      The first patch allows pygrub to check all the GPT partitions, rat=
her
> >      than just the first. This is a repost of the patch I submitted a f=
ew
> >      days ago with a slightly edited introductory text.
> > =

> >      The second patch allows pygrub to find the grub2 configuration file
> >      which are in the /boot/grub2 directory on Fedora 16.
> > =

> >      The third patch allows pygrub to handle partition references such =
as
> >      (hd0,gpt2) which occur in the Fedora 16 grub2 configuration file.
> > =

> >      The fourth patch allows pygrub to parse grub2 configuration files =
with
> >      sub menus by ignoring the submenu line and the corresponding } lin=
e. A
> >      default Fedora 16 grub2 configuration file doesn't have sub menus =
but
> >      they do occur if the xen hypervisor is installed on the guest.
> > =

> >      The fifth patch allows pygrub to parse grub2 configurations with t=
he
> >      line
> >      set default=3D"${saved_entry}"
> >      which can occur in the Fedora 16 grub2 configuration file.
> > =

> >      The final patch adds a sample Fedora 16 grub2 configuration file
> >      containing the problems fixed by patches 3,4 and 5.
> > =

> >          Michael Young
> > =

> >      _______________________________________________
> >      Xen-devel mailing list
> >      [1]Xen-devel@lists.xensource.com
> >      [2]http://lists.xensource.com/xen-devel
> > =

> > References
> > =

> >    Visible links
> >    1. file:///mc/compose?to=3DXen-devel@lists.xensource.com
> >    2. http://lists.xensource.com/xen-devel
> =

> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xensource.com
> > http://lists.xensource.com/xen-devel
> =

> =

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 09:04:56 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 09: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.xensource.com>)
	id 1RaklM-0005Xd-4H; Wed, 14 Dec 2011 09:04:32 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pasik@iki.fi>) id 1RaklK-0005XV-P5
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 09:04:30 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-10.tower-27.messagelabs.com!1323853380!47790985!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiAzOTQyMzA=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32192 invoked from network); 14 Dec 2011 09:03:00 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-10.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Dec 2011 09:03:00 -0000
X-Originating-Ip: [194.89.68.22]
Received: from ydin.reaktio.net (reaktio.net [194.89.68.22])
	by smtp.tele.fi (Postfix) with ESMTP id 4D84A267C;
	Wed, 14 Dec 2011 11:03:39 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 0BA1220056; Wed, 14 Dec 2011 11:03:39 +0200 (EET)
Date: Wed, 14 Dec 2011 11:03:38 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <20111214090338.GS12984@reaktio.net>
References: <alpine.DEB.2.00.1110192358140.15667@vega-a.dur.ac.uk>
	<1319293366.98429.YahooMailClassic@web65903.mail.ac4.yahoo.com>
	<20111116184108.GM12984@reaktio.net>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20111116184108.GM12984@reaktio.net>
User-Agent: Mutt/1.5.18 (2008-05-17)
Cc: xen-devel@lists.xensource.com, Ian Campbell <Ian.Campbell@citrix.com>,
	M A Young <m.a.young@durham.ac.uk>
Subject: Re: [Xen-devel] [PATCH 0 of 6] pygrub fixes to support a Fedora
	16	guest
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Nov 16, 2011 at 08:41:08PM +0200, Pasi K=E4rkk=E4inen wrote:
> On Sat, Oct 22, 2011 at 07:22:46AM -0700, Boris Derzhavets wrote:
> >    Please, back port  to xen-4.1-testing.hg.
> > =

> =

> Yep, this pygrub patch series is already in xen-unstable.hg,
> and it should be backported to xen-4.1-testing.hg aswell,
> so upcoming Xen 4.1.3 will support F16 PV domUs.
> =

> (It's already included in Michael's Fedora 16 xen rpms,
> and works well there.)
> =


Fedora 16 Xen 4.1.2 src.rpm is for example here:
ftp://ftp.funet.fi/pub/mirrors/fedora.redhat.com/pub/fedora/linux/updates/1=
6/SRPMS/xen-4.1.2-2.fc16.src.rpm

and that includes a working backport of these pygryb patches,
in a case they don't apply cleanly to xen-4.1-testing.hg.

-- Pasi


> =

> =

> > =

> >    --- On Wed, 10/19/11, M A Young <m.a.young@durham.ac.uk> wrote:
> > =

> >      From: M A Young <m.a.young@durham.ac.uk>
> >      Subject: [Xen-devel] [PATCH 0 of 6] pygrub fixes to support a Fedo=
ra 16
> >      guest
> >      To: xen-devel@lists.xensource.com
> >      Cc: "Ian Campbell" <Ian.Campbell@citrix.com>
> >      Date: Wednesday, October 19, 2011, 7:02 PM
> > =

> >      This series contains patches that may be needed to allow pygrub to=
 boot
> >      a Fedora 16 guest.
> > =

> >      By default, Fedora 16 has GPT partitions and uses grub2. The first=
 GPT
> >      partition is a grub2 boot partition to store the grub2 code. The s=
econd
> >      GPT partition contains the /boot filesystem with the kernel and
> >      initramfs files and grub2 configuration files. The remaining space=
 is an
> >      LVM partition containing the remaining file systems.
> > =

> >      The first patch allows pygrub to check all the GPT partitions, rat=
her
> >      than just the first. This is a repost of the patch I submitted a f=
ew
> >      days ago with a slightly edited introductory text.
> > =

> >      The second patch allows pygrub to find the grub2 configuration file
> >      which are in the /boot/grub2 directory on Fedora 16.
> > =

> >      The third patch allows pygrub to handle partition references such =
as
> >      (hd0,gpt2) which occur in the Fedora 16 grub2 configuration file.
> > =

> >      The fourth patch allows pygrub to parse grub2 configuration files =
with
> >      sub menus by ignoring the submenu line and the corresponding } lin=
e. A
> >      default Fedora 16 grub2 configuration file doesn't have sub menus =
but
> >      they do occur if the xen hypervisor is installed on the guest.
> > =

> >      The fifth patch allows pygrub to parse grub2 configurations with t=
he
> >      line
> >      set default=3D"${saved_entry}"
> >      which can occur in the Fedora 16 grub2 configuration file.
> > =

> >      The final patch adds a sample Fedora 16 grub2 configuration file
> >      containing the problems fixed by patches 3,4 and 5.
> > =

> >          Michael Young
> > =

> >      _______________________________________________
> >      Xen-devel mailing list
> >      [1]Xen-devel@lists.xensource.com
> >      [2]http://lists.xensource.com/xen-devel
> > =

> > References
> > =

> >    Visible links
> >    1. file:///mc/compose?to=3DXen-devel@lists.xensource.com
> >    2. http://lists.xensource.com/xen-devel
> =

> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xensource.com
> > http://lists.xensource.com/xen-devel
> =

> =

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 09:15:25 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 09: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.xensource.com>)
	id 1RakvR-0005li-CT; Wed, 14 Dec 2011 09:14:57 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RakvP-0005ld-Pq
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 09:14:56 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1323853999!47792796!1
X-Originating-IP: [209.85.210.43]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11169 invoked from network); 14 Dec 2011 09:13:20 -0000
Received: from mail-pz0-f43.google.com (HELO mail-pz0-f43.google.com)
	(209.85.210.43)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Dec 2011 09:13:20 -0000
Received: by daec6 with SMTP id c6so2208644dae.30
	for <xen-devel@lists.xensource.com>;
	Wed, 14 Dec 2011 01:13:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=uRfxx+x7Tu8cLth2Yu7TeW+8qf3Hq9AaOAqxEXSlUyk=;
	b=SRJZJ7RpKX7ScX8A9eiU9zleUAXPSdrkQNO2a+64c94s6ue8u0KAHRmSv0i+btw2s1
	94oRXg4iA9vxoSpbm8wuecaipLZ9BPTkOA/8SCUSDhzDO8kv6P3qxLeJkaZNHzRG5Ldy
	UkyQafiLvctidku0D3DKZPAjwUf7sv8BIeZfI=
MIME-Version: 1.0
Received: by 10.68.74.105 with SMTP id s9mr2434797pbv.64.1323854038485; Wed,
	14 Dec 2011 01:13:58 -0800 (PST)
Received: by 10.142.47.17 with HTTP; Wed, 14 Dec 2011 01:13:58 -0800 (PST)
In-Reply-To: <20199.26896.928532.781947@mariner.uk.xensource.com>
References: <patchbomb.1323768375@loki.upc.es>
	<35c322e6020501447936.1323768387@loki.upc.es>
	<20199.26896.928532.781947@mariner.uk.xensource.com>
Date: Wed, 14 Dec 2011 10:13:58 +0100
X-Google-Sender-Auth: fSFeTHZWRRm1J6S0b3CMc0zzLiM
Message-ID: <CAPLaKK6wqa+VAxgzLWudQ2C2kaoXww9KK3BQhU4fKmoCAMFCzQ@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 12 of 14 v4] libxl: set frontend status to 6
 on domain destroy
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

MjAxMS8xMi8xMyBJYW4gSmFja3NvbiA8SWFuLkphY2tzb25AZXUuY2l0cml4LmNvbT46Cj4gUm9n
ZXIgUGF1IE1vbm5lIHdyaXRlcyAoIltYZW4tZGV2ZWxdIFtQQVRDSCAxMiBvZiAxNCB2NF0gbGli
eGw6IHNldCBmcm9udGVuZCBzdGF0dXMgdG8gNiBvbiBkb21haW4gZGVzdHJveSIpOgo+PiBsaWJ4
bDogc2V0IGZyb250ZW5kIHN0YXR1cyB0byA2IG9uIGRvbWFpbiBkZXN0cm95Cj4+Cj4+IFNldCBm
cm9udGVuZCBzdGF0dXMgdG8gNiBvbiBkb21haW4gZGVzdHJ1Y3Rpb24gYW5kIHdhaXQgZm9yIGRl
dmljZXMgdG8KPj4gYmUgZGlzY29ubmVjdGVkIGJlZm9yZSBleGVjdXRpbmcgaG90cGx1ZyBzY3Jp
cHRzLgo+Cj4gVGhlcmUgc2VlbXMgdG8gYmUgYSByYWNlIGhlcmUuCj4KPj4gKyDCoCDCoGxpYnhs
X194c193cml0ZShnYywgWEJUX05VTEwsIGxpYnhsX19zcHJpbnRmKGdjLCAiJXMvJXMiLCBmZV9w
YXRoLCAic3RhdGUiKSwgIjYiKTsKPgo+IFNvIGhlcmUsIHRoZSBrZXJuZWwgb3IgYmFja2VuZGQg
c3RhcnQgcmFjaW5nLCBhbmQgeW91IGhvcGUgdGhhdCB0aGV5Cj4gd2luIHRoZSByYWNlIGFuZCBj
bG9zZSB0aGUgZGV2aWNlIGJlZm9yZSAuLi4KCkZyb20gbXkgZXhwZXJpZW5jZSBpbiBOZXRCU0Qs
IHRoZSBrZXJuZWwgb25seSBjbG9zZXMgdGhlIGRldmljZSB3aGVuCml0J3MgZnJvbnRlbmQgc3Rh
dGUgaXMgc2V0IHRvIDYsIHNpbmNlIHdlIGRlc3Ryb3kgdGhlIGRvbWFpbiwgaXQgaXMKdW5hYmxl
IHRvIHNldCB0aGUgc3RhdHVzIHRvIDYsIGFuZCB0aHVzIHRoZSBrZXJuZWwgZG9lc24ndCBkZXRh
Y2ggdGhlCmRldmljZXMuIEkndmUgYWRkZWQgc29tZSBsaWJ4bF9fd2FpdF9mb3JfZGV2aWNlX3N0
YXRlIGxvZ2ljIGhlcmUsIHRvCmFzc3VyZSB0aGUgYmFja2VuZCBzdGF0ZSBpcyBzZXQgdG8gNiBi
ZWZvcmUgdHJ5aW5nIHRvIGV4ZWN1dGUgaG90cGx1ZwpzY3JpcHRzLiBUaGUgdHJ1dGggaXMgdGhh
dCBJIGhhZCBpdCBpbiBwcmV2aW91cyB2ZXJzaW9ucyBvZiBteSBwYXRjaCwKYnV0IGl0IHNlZW1z
IHRoZSBrZXJuZWwgYWx3YXlzIHN3aXRjaGVzIGNvbnRleHRzIGFuZCBkZXRhY2hlcyB0aGUKZGV2
aWNlcyBiZWZvcmUgZXhlY3V0aW5nIGhvdHBsdWcgc2NyaXB0cyAoaXQgbWlnaHQganVzdCBiZSBs
dWNrKS4KCkFsc28gdGhpcyBwYXRjaCBzcGVlZHMgZG9tYWluIGRlc3RydWN0aW9uIGEgbG90ICh3
aGljaCBpcyBhbHNvIHF1aXRlCnNsb3cgdW5kZXIgTGludXggZnJvbSB3aGF0IEkgc2F3KS4KCj4+
IMKgIMKgIMKgbGlieGxfX2RldmljZV9leGVjdXRlX2hvdHBsdWcoZ2MsIGRldiwgRElTQ09OTkVD
VCk7Cj4KPiAuLi4gdGhlIGhvdHBsdWcgc2NyaXB0IHRyaWVzIHRvIHJlbW92ZSBpdC4KPgo+IElz
IHRoZXJlIHNvbWV0aGluZyB3ZSBjYW4gZG8gdG8gbWFrZSBzdXJlIHRoYXQgd2UgYWx3YXlzIGdl
dCB0aGlzCj4gcmlnaHQgPwo+Cj4gSWFuLgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMu
eGVuc291cmNlLmNvbQpodHRwOi8vbGlzdHMueGVuc291cmNlLmNvbS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Wed Dec 14 09:15:25 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 09: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.xensource.com>)
	id 1RakvR-0005li-CT; Wed, 14 Dec 2011 09:14:57 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RakvP-0005ld-Pq
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 09:14:56 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1323853999!47792796!1
X-Originating-IP: [209.85.210.43]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11169 invoked from network); 14 Dec 2011 09:13:20 -0000
Received: from mail-pz0-f43.google.com (HELO mail-pz0-f43.google.com)
	(209.85.210.43)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Dec 2011 09:13:20 -0000
Received: by daec6 with SMTP id c6so2208644dae.30
	for <xen-devel@lists.xensource.com>;
	Wed, 14 Dec 2011 01:13:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=uRfxx+x7Tu8cLth2Yu7TeW+8qf3Hq9AaOAqxEXSlUyk=;
	b=SRJZJ7RpKX7ScX8A9eiU9zleUAXPSdrkQNO2a+64c94s6ue8u0KAHRmSv0i+btw2s1
	94oRXg4iA9vxoSpbm8wuecaipLZ9BPTkOA/8SCUSDhzDO8kv6P3qxLeJkaZNHzRG5Ldy
	UkyQafiLvctidku0D3DKZPAjwUf7sv8BIeZfI=
MIME-Version: 1.0
Received: by 10.68.74.105 with SMTP id s9mr2434797pbv.64.1323854038485; Wed,
	14 Dec 2011 01:13:58 -0800 (PST)
Received: by 10.142.47.17 with HTTP; Wed, 14 Dec 2011 01:13:58 -0800 (PST)
In-Reply-To: <20199.26896.928532.781947@mariner.uk.xensource.com>
References: <patchbomb.1323768375@loki.upc.es>
	<35c322e6020501447936.1323768387@loki.upc.es>
	<20199.26896.928532.781947@mariner.uk.xensource.com>
Date: Wed, 14 Dec 2011 10:13:58 +0100
X-Google-Sender-Auth: fSFeTHZWRRm1J6S0b3CMc0zzLiM
Message-ID: <CAPLaKK6wqa+VAxgzLWudQ2C2kaoXww9KK3BQhU4fKmoCAMFCzQ@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 12 of 14 v4] libxl: set frontend status to 6
 on domain destroy
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

MjAxMS8xMi8xMyBJYW4gSmFja3NvbiA8SWFuLkphY2tzb25AZXUuY2l0cml4LmNvbT46Cj4gUm9n
ZXIgUGF1IE1vbm5lIHdyaXRlcyAoIltYZW4tZGV2ZWxdIFtQQVRDSCAxMiBvZiAxNCB2NF0gbGli
eGw6IHNldCBmcm9udGVuZCBzdGF0dXMgdG8gNiBvbiBkb21haW4gZGVzdHJveSIpOgo+PiBsaWJ4
bDogc2V0IGZyb250ZW5kIHN0YXR1cyB0byA2IG9uIGRvbWFpbiBkZXN0cm95Cj4+Cj4+IFNldCBm
cm9udGVuZCBzdGF0dXMgdG8gNiBvbiBkb21haW4gZGVzdHJ1Y3Rpb24gYW5kIHdhaXQgZm9yIGRl
dmljZXMgdG8KPj4gYmUgZGlzY29ubmVjdGVkIGJlZm9yZSBleGVjdXRpbmcgaG90cGx1ZyBzY3Jp
cHRzLgo+Cj4gVGhlcmUgc2VlbXMgdG8gYmUgYSByYWNlIGhlcmUuCj4KPj4gKyDCoCDCoGxpYnhs
X194c193cml0ZShnYywgWEJUX05VTEwsIGxpYnhsX19zcHJpbnRmKGdjLCAiJXMvJXMiLCBmZV9w
YXRoLCAic3RhdGUiKSwgIjYiKTsKPgo+IFNvIGhlcmUsIHRoZSBrZXJuZWwgb3IgYmFja2VuZGQg
c3RhcnQgcmFjaW5nLCBhbmQgeW91IGhvcGUgdGhhdCB0aGV5Cj4gd2luIHRoZSByYWNlIGFuZCBj
bG9zZSB0aGUgZGV2aWNlIGJlZm9yZSAuLi4KCkZyb20gbXkgZXhwZXJpZW5jZSBpbiBOZXRCU0Qs
IHRoZSBrZXJuZWwgb25seSBjbG9zZXMgdGhlIGRldmljZSB3aGVuCml0J3MgZnJvbnRlbmQgc3Rh
dGUgaXMgc2V0IHRvIDYsIHNpbmNlIHdlIGRlc3Ryb3kgdGhlIGRvbWFpbiwgaXQgaXMKdW5hYmxl
IHRvIHNldCB0aGUgc3RhdHVzIHRvIDYsIGFuZCB0aHVzIHRoZSBrZXJuZWwgZG9lc24ndCBkZXRh
Y2ggdGhlCmRldmljZXMuIEkndmUgYWRkZWQgc29tZSBsaWJ4bF9fd2FpdF9mb3JfZGV2aWNlX3N0
YXRlIGxvZ2ljIGhlcmUsIHRvCmFzc3VyZSB0aGUgYmFja2VuZCBzdGF0ZSBpcyBzZXQgdG8gNiBi
ZWZvcmUgdHJ5aW5nIHRvIGV4ZWN1dGUgaG90cGx1ZwpzY3JpcHRzLiBUaGUgdHJ1dGggaXMgdGhh
dCBJIGhhZCBpdCBpbiBwcmV2aW91cyB2ZXJzaW9ucyBvZiBteSBwYXRjaCwKYnV0IGl0IHNlZW1z
IHRoZSBrZXJuZWwgYWx3YXlzIHN3aXRjaGVzIGNvbnRleHRzIGFuZCBkZXRhY2hlcyB0aGUKZGV2
aWNlcyBiZWZvcmUgZXhlY3V0aW5nIGhvdHBsdWcgc2NyaXB0cyAoaXQgbWlnaHQganVzdCBiZSBs
dWNrKS4KCkFsc28gdGhpcyBwYXRjaCBzcGVlZHMgZG9tYWluIGRlc3RydWN0aW9uIGEgbG90ICh3
aGljaCBpcyBhbHNvIHF1aXRlCnNsb3cgdW5kZXIgTGludXggZnJvbSB3aGF0IEkgc2F3KS4KCj4+
IMKgIMKgIMKgbGlieGxfX2RldmljZV9leGVjdXRlX2hvdHBsdWcoZ2MsIGRldiwgRElTQ09OTkVD
VCk7Cj4KPiAuLi4gdGhlIGhvdHBsdWcgc2NyaXB0IHRyaWVzIHRvIHJlbW92ZSBpdC4KPgo+IElz
IHRoZXJlIHNvbWV0aGluZyB3ZSBjYW4gZG8gdG8gbWFrZSBzdXJlIHRoYXQgd2UgYWx3YXlzIGdl
dCB0aGlzCj4gcmlnaHQgPwo+Cj4gSWFuLgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMu
eGVuc291cmNlLmNvbQpodHRwOi8vbGlzdHMueGVuc291cmNlLmNvbS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Wed Dec 14 09:21:38 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 09:21:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ral1X-0005uu-7q; Wed, 14 Dec 2011 09:21:15 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Ral1V-0005un-9d
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 09:21:13 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1323854415!7192144!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25236 invoked from network); 14 Dec 2011 09:20:18 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-4.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Dec 2011 09:20:18 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 14 Dec 2011 09:20:15 +0000
Message-Id: <4EE8785A0200007800067A16@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 14 Dec 2011 09:20:10 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Neal E Taylor" <Neal.Taylor@ca.com>
References: <3E243B26F475504B9BB0BCC9728B0DA629E16E01@USILMS110A.ca.com>
	<20111209203010.GA14412@andromeda.dapyr.net>
	<3E243B26F475504B9BB0BCC9728B0DA629E17AEA@USILMS110A.ca.com>
	<20111213001912.GA2730@konrad-lan>
	<3E243B26F475504B9BB0BCC9728B0DA629E184FA@USILMS110A.ca.com>
	<20111213232759.GA8702@konrad-lan>
	<3E243B26F475504B9BB0BCC9728B0DA629E18564@USILMS110A.ca.com>
In-Reply-To: <3E243B26F475504B9BB0BCC9728B0DA629E18564@USILMS110A.ca.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>,
	xen-devel <xen-devel@lists.xensource.com>,
	Leonid Kalev <Leonid.Kalev@ca.com>, Tushar N Dave <tushar.n.dave@intel.com>
Subject: Re: [Xen-devel] Buffers not reachable by PCI
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 14.12.11 at 01:38, "Taylor, Neal E" <Neal.Taylor@ca.com> wrote:
> [    0.000000] MFN 0x7f7f->0x7f00

This is clearly indicating the last chunk ends well below the 4G boundary.

> [    0.000000] Placing 64MB software IO TLB between d832cf00 - dc32cf00
> [    0.000000] software IO TLB at phys 0x1832cf00 - 0x1c32cf00
> [    0.000000] software IO TLB at bus 0x1c0f00 - 0x120fdff00

Consequently, the question is how you got to this value, or what
changed between the first and last quoted printouts.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 09:21:38 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 09:21:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ral1X-0005uu-7q; Wed, 14 Dec 2011 09:21:15 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Ral1V-0005un-9d
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 09:21:13 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1323854415!7192144!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25236 invoked from network); 14 Dec 2011 09:20:18 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-4.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Dec 2011 09:20:18 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 14 Dec 2011 09:20:15 +0000
Message-Id: <4EE8785A0200007800067A16@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 14 Dec 2011 09:20:10 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Neal E Taylor" <Neal.Taylor@ca.com>
References: <3E243B26F475504B9BB0BCC9728B0DA629E16E01@USILMS110A.ca.com>
	<20111209203010.GA14412@andromeda.dapyr.net>
	<3E243B26F475504B9BB0BCC9728B0DA629E17AEA@USILMS110A.ca.com>
	<20111213001912.GA2730@konrad-lan>
	<3E243B26F475504B9BB0BCC9728B0DA629E184FA@USILMS110A.ca.com>
	<20111213232759.GA8702@konrad-lan>
	<3E243B26F475504B9BB0BCC9728B0DA629E18564@USILMS110A.ca.com>
In-Reply-To: <3E243B26F475504B9BB0BCC9728B0DA629E18564@USILMS110A.ca.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>,
	xen-devel <xen-devel@lists.xensource.com>,
	Leonid Kalev <Leonid.Kalev@ca.com>, Tushar N Dave <tushar.n.dave@intel.com>
Subject: Re: [Xen-devel] Buffers not reachable by PCI
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 14.12.11 at 01:38, "Taylor, Neal E" <Neal.Taylor@ca.com> wrote:
> [    0.000000] MFN 0x7f7f->0x7f00

This is clearly indicating the last chunk ends well below the 4G boundary.

> [    0.000000] Placing 64MB software IO TLB between d832cf00 - dc32cf00
> [    0.000000] software IO TLB at phys 0x1832cf00 - 0x1c32cf00
> [    0.000000] software IO TLB at bus 0x1c0f00 - 0x120fdff00

Consequently, the question is how you got to this value, or what
changed between the first and last quoted printouts.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 09:35:38 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 09:35:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RalF6-0006E1-JT; Wed, 14 Dec 2011 09:35:16 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>)
	id 1RalF4-0006Dt-CL; Wed, 14 Dec 2011 09:35:14 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1323855258!5465429!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1220 invoked from network); 14 Dec 2011 09:34:19 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-2.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Dec 2011 09:34:19 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 14 Dec 2011 09:34:18 +0000
Message-Id: <4EE87BA80200007800067A2A@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 14 Dec 2011 09:34:16 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "jim burns" <jim_burn@bellsouth.net>
References: <5240506.YiTi8lqF86@dell4550>
	<1323816494.57363.YahooMailNeo@web35601.mail.mud.yahoo.com>
	<2418222.I2RnIRCVYI@dell4550>
In-Reply-To: <2418222.I2RnIRCVYI@dell4550>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Mark Pryor <tlviewer@yahoo.com>, xen-devel@lists.xensource.com,
	"xen-users@lists.xensource.com" <xen-users@lists.xensource.com>
Subject: Re: [Xen-devel] [Xen-users] openSUSE 12.1 does not have complete
	xen rpms
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 14.12.11 at 01:42, jim burns <jim_burn@bellsouth.net> wrote:
> On Tue December 13 2011, 2:48:14 PM, Mark Pryor wrote:
>> Move to x86_64 and you will have a complete dom0 upgrade. Its true that
>> i586 is not supporting a full dom0.
> 
> Not possible - it's a 32 bit system.
> 
> I suppose I could download the xen .src.rpm, and recompile it, assuming they 
> haven't disabled i586 for some reason. I just want to know if it's 
> supported, or suse ran into a snag getting it to work for i586.

It's not supported, but it's being evaluated to re-add the 32-bit
hypervisor (which got dropped largely because the same source tree
gets used for SLE11 SP2, where the dropping of support for it implies
the removal of the package). See bug 732424.

> Anyone know if they will eventually support it?

No, I do not expect it to get considered supported again. You'll be
left on your own in dealing with eventual problems (which doesn't
exclude us merging fixes that get provided or pointed out), as stated
in comment 15 of aforementioned bug.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 09:35:38 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 09:35:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RalF6-0006E1-JT; Wed, 14 Dec 2011 09:35:16 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>)
	id 1RalF4-0006Dt-CL; Wed, 14 Dec 2011 09:35:14 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1323855258!5465429!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1220 invoked from network); 14 Dec 2011 09:34:19 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-2.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Dec 2011 09:34:19 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 14 Dec 2011 09:34:18 +0000
Message-Id: <4EE87BA80200007800067A2A@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 14 Dec 2011 09:34:16 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "jim burns" <jim_burn@bellsouth.net>
References: <5240506.YiTi8lqF86@dell4550>
	<1323816494.57363.YahooMailNeo@web35601.mail.mud.yahoo.com>
	<2418222.I2RnIRCVYI@dell4550>
In-Reply-To: <2418222.I2RnIRCVYI@dell4550>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Mark Pryor <tlviewer@yahoo.com>, xen-devel@lists.xensource.com,
	"xen-users@lists.xensource.com" <xen-users@lists.xensource.com>
Subject: Re: [Xen-devel] [Xen-users] openSUSE 12.1 does not have complete
	xen rpms
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 14.12.11 at 01:42, jim burns <jim_burn@bellsouth.net> wrote:
> On Tue December 13 2011, 2:48:14 PM, Mark Pryor wrote:
>> Move to x86_64 and you will have a complete dom0 upgrade. Its true that
>> i586 is not supporting a full dom0.
> 
> Not possible - it's a 32 bit system.
> 
> I suppose I could download the xen .src.rpm, and recompile it, assuming they 
> haven't disabled i586 for some reason. I just want to know if it's 
> supported, or suse ran into a snag getting it to work for i586.

It's not supported, but it's being evaluated to re-add the 32-bit
hypervisor (which got dropped largely because the same source tree
gets used for SLE11 SP2, where the dropping of support for it implies
the removal of the package). See bug 732424.

> Anyone know if they will eventually support it?

No, I do not expect it to get considered supported again. You'll be
left on your own in dealing with eventual problems (which doesn't
exclude us merging fixes that get provided or pointed out), as stated
in comment 15 of aforementioned bug.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 09:36:24 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 09:36:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RalFt-0006HM-AM; Wed, 14 Dec 2011 09:36:05 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RalFr-0006Gk-Rv
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 09:36:04 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1323855306!5305691!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjA4OTk=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26719 invoked from network); 14 Dec 2011 09:35:08 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Dec 2011 09:35:08 -0000
X-IronPort-AV: E=Sophos;i="4.71,351,1320642000"; d="scan'208";a="174077596"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Dec 2011 04:35:05 -0500
Received: from cosworth.uk.xensource.com (10.80.16.52) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 14 Dec 2011 04:35:05 -0500
MIME-Version: 1.0
Message-ID: <patchbomb.1323855070@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Wed, 14 Dec 2011 09:31:10 +0000
From: Paul Durrant <paul.durrant@citrix.com>
To: xen-devel@lists.xensource.com
Cc: paul.durrant@citrix.com
Subject: [Xen-devel] [PATCH 0 of 2] Support for VM generation ID
	save/restore and migrate
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This patch series adds support for preservation of the VM generation ID
buffer address in xenstore across save/restore and migrate, and also
code to increment the value in all cases except for migration.
The vast majority of the code is in second patch. The first patch
merely changes the xenstore key name used by hvmloader to store the
buffer address.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 09:36:24 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 09:36:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RalFt-0006HM-AM; Wed, 14 Dec 2011 09:36:05 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RalFr-0006Gk-Rv
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 09:36:04 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1323855306!5305691!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjA4OTk=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26719 invoked from network); 14 Dec 2011 09:35:08 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Dec 2011 09:35:08 -0000
X-IronPort-AV: E=Sophos;i="4.71,351,1320642000"; d="scan'208";a="174077596"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Dec 2011 04:35:05 -0500
Received: from cosworth.uk.xensource.com (10.80.16.52) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 14 Dec 2011 04:35:05 -0500
MIME-Version: 1.0
Message-ID: <patchbomb.1323855070@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Wed, 14 Dec 2011 09:31:10 +0000
From: Paul Durrant <paul.durrant@citrix.com>
To: xen-devel@lists.xensource.com
Cc: paul.durrant@citrix.com
Subject: [Xen-devel] [PATCH 0 of 2] Support for VM generation ID
	save/restore and migrate
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This patch series adds support for preservation of the VM generation ID
buffer address in xenstore across save/restore and migrate, and also
code to increment the value in all cases except for migration.
The vast majority of the code is in second patch. The first patch
merely changes the xenstore key name used by hvmloader to store the
buffer address.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 09:36:28 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 09:36:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RalFu-0006Hd-N3; Wed, 14 Dec 2011 09:36:06 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RalFt-0006Gt-2I
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 09:36:05 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1323855306!5305691!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjA4OTk=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26773 invoked from network); 14 Dec 2011 09:35:09 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Dec 2011 09:35:09 -0000
X-IronPort-AV: E=Sophos;i="4.71,351,1320642000"; d="scan'208";a="174077598"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Dec 2011 04:35:07 -0500
Received: from cosworth.uk.xensource.com (10.80.16.52) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 14 Dec 2011 04:35:07 -0500
MIME-Version: 1.0
X-Mercurial-Node: 972927dc84c7e22520f4771d58d4770bf2726816
Message-ID: <972927dc84c7e22520f4.1323855072@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1323855070@cosworth.uk.xensource.com>
References: <patchbomb.1323855070@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Wed, 14 Dec 2011 09:31:12 +0000
From: Paul Durrant <paul.durrant@citrix.com>
To: xen-devel@lists.xensource.com
Cc: paul.durrant@citrix.com
Subject: [Xen-devel] [PATCH 2 of 2] VM generation ID save/restore and migrate
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Paul Durrant <paul.durrant@citrix.com>
# Date 1323854955 0
# Node ID 972927dc84c7e22520f4771d58d4770bf2726816
# Parent  fded65be5d82461e87de54960db14ce8feb4625f
VM generation ID save/restore and migrate.

Add code to track the address of the VM generation ID buffer across a
save/restore or migrate, and increment it as necessary.
The address of the buffer is written into xenstore by hvmloader at
boot time. It must be read from xenstore by the caller of
xc_domain_save() and then written back again by the caller of
xc_domain_restore().

Signed-off-by: Paul Durrant <paul.durrant@citrix.com>

diff -r fded65be5d82 -r 972927dc84c7 tools/libxc/ia64/xc_ia64_linux_restore.c
--- a/tools/libxc/ia64/xc_ia64_linux_restore.c	Wed Dec 14 09:29:12 2011 +0000
+++ b/tools/libxc/ia64/xc_ia64_linux_restore.c	Wed Dec 14 09:29:15 2011 +0000
@@ -548,7 +548,8 @@ int
 xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
                   unsigned int store_evtchn, unsigned long *store_mfn,
                   unsigned int console_evtchn, unsigned long *console_mfn,
-                  unsigned int hvm, unsigned int pae, int superpages)
+                  unsigned int hvm, unsigned int pae, int superpages,
+                  int no_incr_generationid, unsigned long *vm_generationid_addr)
 {
     DECLARE_DOMCTL;
     int rc = 1;
diff -r fded65be5d82 -r 972927dc84c7 tools/libxc/ia64/xc_ia64_linux_save.c
--- a/tools/libxc/ia64/xc_ia64_linux_save.c	Wed Dec 14 09:29:12 2011 +0000
+++ b/tools/libxc/ia64/xc_ia64_linux_save.c	Wed Dec 14 09:29:15 2011 +0000
@@ -382,7 +382,8 @@ out:
 int
 xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iters,
                uint32_t max_factor, uint32_t flags,
-               struct save_callbacks* callbacks, int hvm)
+               struct save_callbacks* callbacks, int hvm,
+               unsigned long vm_generationid_addr)
 {
     DECLARE_DOMCTL;
     xc_dominfo_t info;
diff -r fded65be5d82 -r 972927dc84c7 tools/libxc/xc_domain_restore.c
--- a/tools/libxc/xc_domain_restore.c	Wed Dec 14 09:29:12 2011 +0000
+++ b/tools/libxc/xc_domain_restore.c	Wed Dec 14 09:29:15 2011 +0000
@@ -681,6 +681,7 @@ typedef struct {
     uint64_t console_pfn;
     uint64_t acpi_ioport_location;
     uint64_t viridian;
+    uint64_t vm_generationid_addr;
 } pagebuf_t;
 
 static int pagebuf_init(pagebuf_t* buf)
@@ -860,6 +861,17 @@ static int pagebuf_get_one(xc_interface 
         }
         return compbuf_size;
 
+    case XC_SAVE_ID_HVM_GENERATION_ID_ADDR:
+        /* Skip padding 4 bytes then read the generation id buffer location. */
+        if ( RDEXACT(fd, &buf->vm_generationid_addr, sizeof(uint32_t)) ||
+             RDEXACT(fd, &buf->vm_generationid_addr, sizeof(uint64_t)) )
+        {
+            PERROR("error read the generation id buffer location");
+            return -1;
+        }
+        DPRINTF("read generation id buffer address");
+        return pagebuf_get_one(xch, ctx, buf, fd, dom);
+
     default:
         if ( (count > MAX_BATCH_SIZE) || (count < 0) ) {
             ERROR("Max batch size exceeded (%d). Giving up.", count);
@@ -1248,7 +1260,8 @@ static int apply_batch(xc_interface *xch
 int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
                       unsigned int store_evtchn, unsigned long *store_mfn,
                       unsigned int console_evtchn, unsigned long *console_mfn,
-                      unsigned int hvm, unsigned int pae, int superpages)
+                      unsigned int hvm, unsigned int pae, int superpages,
+                      int no_incr_generationid, unsigned long *vm_generationid_addr)
 {
     DECLARE_DOMCTL;
     int rc = 1, frc, i, j, n, m, pae_extended_cr3 = 0, ext_vcpucontext = 0;
@@ -1449,6 +1462,39 @@ int xc_domain_restore(xc_interface *xch,
                 xc_set_hvm_param(xch, dom, HVM_PARAM_VM86_TSS, pagebuf.vm86_tss);
             if ( pagebuf.console_pfn )
                 console_pfn = pagebuf.console_pfn;
+            if ( pagebuf.vm_generationid_addr ) {
+                if ( !no_incr_generationid ) {
+                    unsigned int offset;
+                    unsigned char *buf;
+                    unsigned long long generationid;
+
+                    /*
+                     * Map the VM generation id buffer and inject the new value.
+                     */
+
+                    pfn = pagebuf.vm_generationid_addr >> PAGE_SHIFT;
+                    offset = pagebuf.vm_generationid_addr & (PAGE_SIZE - 1);
+                
+                    if ( (pfn >= dinfo->p2m_size) ||
+                         (pfn_type[pfn] != XEN_DOMCTL_PFINFO_NOTAB) )
+                    {
+                        ERROR("generation id buffer frame is bad");
+                        goto out;
+                    }
+
+                    mfn = ctx->p2m[pfn];
+                    buf = xc_map_foreign_range(xch, dom, PAGE_SIZE,
+                                               PROT_READ | PROT_WRITE, mfn);
+
+                    generationid = *(unsigned long long *)(buf + offset);
+                    *(unsigned long long *)(buf + offset) = generationid + 1;
+
+                    munmap(buf, PAGE_SIZE);
+                }
+
+                *vm_generationid_addr = pagebuf.vm_generationid_addr;
+            }
+
             break;  /* our work here is done */
         }
 
diff -r fded65be5d82 -r 972927dc84c7 tools/libxc/xc_domain_save.c
--- a/tools/libxc/xc_domain_save.c	Wed Dec 14 09:29:12 2011 +0000
+++ b/tools/libxc/xc_domain_save.c	Wed Dec 14 09:29:15 2011 +0000
@@ -804,7 +804,8 @@ static int save_tsc_info(xc_interface *x
 
 int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iters,
                    uint32_t max_factor, uint32_t flags,
-                   struct save_callbacks* callbacks, int hvm)
+                   struct save_callbacks* callbacks, int hvm,
+                   unsigned long vm_generationid_addr)
 {
     xc_dominfo_t info;
     DECLARE_DOMCTL;
@@ -1616,6 +1617,16 @@ int xc_domain_save(xc_interface *xch, in
             uint64_t data;
         } chunk = { 0, };
 
+        chunk.id = XC_SAVE_ID_HVM_GENERATION_ID_ADDR;
+        chunk.data = vm_generationid_addr;
+
+        if ( (chunk.data != 0) &&
+             wrexact(io_fd, &chunk, sizeof(chunk)) )
+        {
+            PERROR("Error when writing the generation id buffer location for guest");
+            goto out;
+        }
+
         chunk.id = XC_SAVE_ID_HVM_IDENT_PT;
         chunk.data = 0;
         xc_get_hvm_param(xch, dom, HVM_PARAM_IDENT_PT,
diff -r fded65be5d82 -r 972927dc84c7 tools/libxc/xenguest.h
--- a/tools/libxc/xenguest.h	Wed Dec 14 09:29:12 2011 +0000
+++ b/tools/libxc/xenguest.h	Wed Dec 14 09:29:15 2011 +0000
@@ -58,7 +58,8 @@ struct save_callbacks {
  */
 int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iters,
                    uint32_t max_factor, uint32_t flags /* XCFLAGS_xxx */,
-                   struct save_callbacks* callbacks, int hvm);
+                   struct save_callbacks* callbacks, int hvm,
+                   unsigned long vm_generationid_addr);
 
 
 /**
@@ -72,12 +73,15 @@ int xc_domain_save(xc_interface *xch, in
  * @parm hvm non-zero if this is a HVM restore
  * @parm pae non-zero if this HVM domain has PAE support enabled
  * @parm superpages non-zero to allocate guest memory with superpages
+ * @parm no_incr_generationid non-zero if generation id is NOT to be incremented
+ * @parm vm_generationid_addr returned with the address of the generation id buffer
  * @return 0 on success, -1 on failure
  */
 int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
                       unsigned int store_evtchn, unsigned long *store_mfn,
                       unsigned int console_evtchn, unsigned long *console_mfn,
-                      unsigned int hvm, unsigned int pae, int superpages);
+                      unsigned int hvm, unsigned int pae, int superpages,
+                      int no_incr_generationid, unsigned long *vm_generationid_addr);
 /**
  * xc_domain_restore writes a file to disk that contains the device
  * model saved state.
diff -r fded65be5d82 -r 972927dc84c7 tools/libxc/xg_save_restore.h
--- a/tools/libxc/xg_save_restore.h	Wed Dec 14 09:29:12 2011 +0000
+++ b/tools/libxc/xg_save_restore.h	Wed Dec 14 09:29:15 2011 +0000
@@ -253,6 +253,7 @@
 #define XC_SAVE_ID_HVM_VIRIDIAN       -11
 #define XC_SAVE_ID_COMPRESSED_DATA    -12 /* Marker to indicate arrival of compressed data */
 #define XC_SAVE_ID_ENABLE_COMPRESSION -13 /* Marker to enable compression logic at receiver side */
+#define XC_SAVE_ID_HVM_GENERATION_ID_ADDR -14
 
 /*
 ** We process save/restore/migrate in batches of pages; the below
diff -r fded65be5d82 -r 972927dc84c7 tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Wed Dec 14 09:29:12 2011 +0000
+++ b/tools/libxl/libxl_create.c	Wed Dec 14 09:29:15 2011 +0000
@@ -99,6 +99,7 @@ int libxl_init_build_info(libxl_ctx *ctx
         b_info->u.hvm.vpt_align = 1;
         b_info->u.hvm.timer_mode = 1;
         b_info->u.hvm.nested_hvm = 0;
+        b_info->u.hvm.no_incr_generationid = 0;
         break;
     case LIBXL_DOMAIN_TYPE_PV:
         b_info->u.pv.slack_memkb = 8 * 1024;
diff -r fded65be5d82 -r 972927dc84c7 tools/libxl/libxl_dom.c
--- a/tools/libxl/libxl_dom.c	Wed Dec 14 09:29:12 2011 +0000
+++ b/tools/libxl/libxl_dom.c	Wed Dec 14 09:29:15 2011 +0000
@@ -124,7 +124,7 @@ int libxl__build_post(libxl__gc *gc, uin
     if (info->cpuid != NULL)
         libxl_cpuid_set(ctx, domid, info->cpuid);
 
-    ents = libxl__calloc(gc, 12 + (info->max_vcpus * 2) + 2, sizeof(char *));
+    ents = libxl__calloc(gc, 14 + (info->max_vcpus * 2) + 2, sizeof(char *));
     ents[0] = "memory/static-max";
     ents[1] = libxl__sprintf(gc, "%d", info->max_memkb);
     ents[2] = "memory/target";
@@ -137,9 +137,11 @@ int libxl__build_post(libxl__gc *gc, uin
     ents[9] = libxl__sprintf(gc, "%"PRIu32, state->store_port);
     ents[10] = "store/ring-ref";
     ents[11] = libxl__sprintf(gc, "%lu", state->store_mfn);
+    ents[12] = "data/generation-id-address";
+    ents[13] = libxl__sprintf(gc, "0x%lx", state->vm_generationid_addr);
     for (i = 0; i < info->max_vcpus; i++) {
-        ents[12+(i*2)]   = libxl__sprintf(gc, "cpu/%d/availability", i);
-        ents[12+(i*2)+1] = (i && info->cur_vcpus && !(info->cur_vcpus & (1 << i)))
+        ents[14+(i*2)]   = libxl__sprintf(gc, "cpu/%d/availability", i);
+        ents[14+(i*2)+1] = (i && info->cur_vcpus && !(info->cur_vcpus & (1 << i)))
                             ? "offline" : "online";
     }
 
@@ -356,16 +358,19 @@ int libxl__domain_restore_common(libxl__
     /* read signature */
     int rc;
     int hvm, pae, superpages;
+    int no_incr_generationid;
     switch (info->type) {
     case LIBXL_DOMAIN_TYPE_HVM:
         hvm = 1;
         superpages = 1;
         pae = info->u.hvm.pae;
+        no_incr_generationid = info->u.hvm.no_incr_generationid;
         break;
     case LIBXL_DOMAIN_TYPE_PV:
         hvm = 0;
         superpages = 0;
         pae = 1;
+        no_incr_generationid = 0;
         break;
     default:
         return ERROR_INVAL;
@@ -373,7 +378,8 @@ int libxl__domain_restore_common(libxl__
     rc = xc_domain_restore(ctx->xch, fd, domid,
                            state->store_port, &state->store_mfn,
                            state->console_port, &state->console_mfn,
-                           hvm, pae, superpages);
+                           hvm, pae, superpages, no_incr_generationid,
+                           &state->vm_generationid_addr);
     if ( rc ) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "restoring domain");
         return ERROR_FAIL;
@@ -539,12 +545,22 @@ int libxl__domain_suspend_common(libxl__
     struct save_callbacks callbacks;
     struct suspendinfo si;
     int hvm, rc = ERROR_FAIL;
+    unsigned long vm_generationid_addr;
 
     switch (type) {
-    case LIBXL_DOMAIN_TYPE_HVM:
+    case LIBXL_DOMAIN_TYPE_HVM: {
+        char *path;
+        char *addr;
+
+        path = libxl__sprintf(gc, "%s/data/generation-id-address", libxl__xs_get_dompath(gc, domid));
+        addr = libxl__xs_read(gc, XBT_NULL, path);
+
+        vm_generationid_addr = (addr) ? strtoul(addr, NULL, 0) : 0;
         hvm = 1;
         break;
+    }
     case LIBXL_DOMAIN_TYPE_PV:
+        vm_generationid_addr = 0;
         hvm = 0;
         break;
     default:
@@ -582,7 +598,8 @@ int libxl__domain_suspend_common(libxl__
     callbacks.switch_qemu_logdirty = libxl__domain_suspend_common_switch_qemu_logdirty;
     callbacks.data = &si;
 
-    rc = xc_domain_save(ctx->xch, fd, domid, 0, 0, flags, &callbacks, hvm);
+    rc = xc_domain_save(ctx->xch, fd, domid, 0, 0, flags, &callbacks,
+                        hvm, vm_generationid_addr);
     if ( rc ) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "saving domain: %s",
                          si.guest_responded ?
diff -r fded65be5d82 -r 972927dc84c7 tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Wed Dec 14 09:29:12 2011 +0000
+++ b/tools/libxl/libxl_internal.h	Wed Dec 14 09:29:15 2011 +0000
@@ -218,6 +218,7 @@ typedef struct {
 
     uint32_t console_port;
     unsigned long console_mfn;
+    unsigned long vm_generationid_addr;
 } libxl__domain_build_state;
 
 _hidden int libxl__build_pre(libxl__gc *gc, uint32_t domid,
diff -r fded65be5d82 -r 972927dc84c7 tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Wed Dec 14 09:29:12 2011 +0000
+++ b/tools/libxl/libxl_types.idl	Wed Dec 14 09:29:15 2011 +0000
@@ -184,6 +184,7 @@ libxl_domain_build_info = Struct("domain
                                        ("vpt_align", bool),
                                        ("timer_mode", integer),
                                        ("nested_hvm", bool),
+                                       ("no_incr_generationid", bool),
                                        ])),
                  ("pv", Struct(None, [("kernel", libxl_file_reference),
                                       ("slack_memkb", uint32),
diff -r fded65be5d82 -r 972927dc84c7 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Wed Dec 14 09:29:12 2011 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Wed Dec 14 09:29:15 2011 +0000
@@ -360,6 +360,7 @@ static void printf_info(int domid,
         printf("\t\t\t(vpt_align %d)\n", b_info->u.hvm.vpt_align);
         printf("\t\t\t(timer_mode %d)\n", b_info->u.hvm.timer_mode);
         printf("\t\t\t(nestedhvm %d)\n", b_info->u.hvm.nested_hvm);
+        printf("\t\t\t(no_incr_generationid %d)\n", b_info->u.hvm.no_incr_generationid);
 
         printf("\t\t\t(device_model %s)\n", dm_info->device_model ? : "default");
         printf("\t\t\t(videoram %d)\n", dm_info->videoram);
@@ -1362,6 +1363,7 @@ struct domain_create {
     const char *restore_file;
     int migrate_fd; /* -1 means none */
     char **migration_domname_r; /* from malloc */
+    int no_incr_generationid;
 };
 
 static int freemem(libxl_domain_build_info *b_info, libxl_device_model_info *dm_info)
@@ -1575,6 +1577,8 @@ static int create_domain(struct domain_c
         }
     }
 
+    d_config.b_info.u.hvm.no_incr_generationid = dom_info->no_incr_generationid;
+
     if (debug || dom_info->dryrun)
         printf_info(-1, &d_config, &d_config.dm_info);
 
@@ -2800,6 +2804,7 @@ static void migrate_receive(int debug, i
     dom_info.restore_file = "incoming migration stream";
     dom_info.migrate_fd = 0; /* stdin */
     dom_info.migration_domname_r = &migration_domname;
+    dom_info.no_incr_generationid = 1;
 
     rc = create_domain(&dom_info);
     if (rc < 0) {
diff -r fded65be5d82 -r 972927dc84c7 tools/python/xen/lowlevel/checkpoint/libcheckpoint.c
--- a/tools/python/xen/lowlevel/checkpoint/libcheckpoint.c	Wed Dec 14 09:29:12 2011 +0000
+++ b/tools/python/xen/lowlevel/checkpoint/libcheckpoint.c	Wed Dec 14 09:29:15 2011 +0000
@@ -175,6 +175,7 @@ int checkpoint_start(checkpoint_state* s
 {
     int hvm, rc;
     int flags = XCFLAGS_LIVE;
+    unsigned long vm_generationid_addr;
 
     if (!s->domid) {
        s->errstr = "checkpoint state not opened";
@@ -185,16 +186,27 @@ int checkpoint_start(checkpoint_state* s
 
     hvm = s->domtype > dt_pv;
     if (hvm) {
+       char path[128];
+       char *addr;
+
+       sprintf(path, "/local/domain/%u/data/generation-id-address", s->domid);
+       addr = xs_read(s->xsh, XBT_NULL, path, NULL);
+
+       vm_generationid_addr = (addr) ? strtoul(addr, NULL, 0) : 0;
+       free(addr);
+
        flags |= XCFLAGS_HVM;
        if (switch_qemu_logdirty(s, 1))
            return -1;
+    } else {
+       vm_generationid_addr = 0;
     }
     if (remus_flags & CHECKPOINT_FLAGS_COMPRESSION)
       flags |= XCFLAGS_CHECKPOINT_COMPRESS;
 
     callbacks->switch_qemu_logdirty = noop_switch_logdirty;
 
-    rc = xc_domain_save(s->xch, fd, s->domid, 0, 0, flags, callbacks, hvm);
+    rc = xc_domain_save(s->xch, fd, s->domid, 0, 0, flags, callbacks, hvm, vm_generationid_addr);
 
     if (hvm)
        switch_qemu_logdirty(s, 0);
diff -r fded65be5d82 -r 972927dc84c7 tools/xcutils/xc_restore.c
--- a/tools/xcutils/xc_restore.c	Wed Dec 14 09:29:12 2011 +0000
+++ b/tools/xcutils/xc_restore.c	Wed Dec 14 09:29:15 2011 +0000
@@ -23,11 +23,12 @@ main(int argc, char **argv)
     xc_interface *xch;
     int io_fd, ret;
     int superpages;
-    unsigned long store_mfn, console_mfn;
+    unsigned long store_mfn, console_mfn, vm_generationid_addr;
+    int no_incr_generationid;
 
-    if ( (argc != 8) && (argc != 9) )
+    if ( (argc < 8) || (argc > 10) )
         errx(1, "usage: %s iofd domid store_evtchn "
-             "console_evtchn hvm pae apic [superpages]", argv[0]);
+             "console_evtchn hvm pae apic [superpages [no_incr_generationid]]", argv[0]);
 
     xch = xc_interface_open(0,0,0);
     if ( !xch )
@@ -40,19 +41,25 @@ main(int argc, char **argv)
     hvm  = atoi(argv[5]);
     pae  = atoi(argv[6]);
     apic = atoi(argv[7]);
-    if ( argc == 9 )
+    if ( argc >= 9 )
 	    superpages = atoi(argv[8]);
     else
 	    superpages = !!hvm;
+    if ( argc == 10 )
+	    no_incr_generationid = !atoi(argv[9]);
+    else
+	    no_incr_generationid = 0;
 
     ret = xc_domain_restore(xch, io_fd, domid, store_evtchn, &store_mfn,
-                            console_evtchn, &console_mfn, hvm, pae, superpages);
+                            console_evtchn, &console_mfn, hvm, pae, superpages,
+                            no_incr_generationid, &vm_generationid_addr);
 
     if ( ret == 0 )
     {
 	printf("store-mfn %li\n", store_mfn);
         if ( !hvm )
             printf("console-mfn %li\n", console_mfn);
+	printf("vm-gid-addr %lx\n", vm_generationid_addr);
 	fflush(stdout);
     }
 
diff -r fded65be5d82 -r 972927dc84c7 tools/xcutils/xc_save.c
--- a/tools/xcutils/xc_save.c	Wed Dec 14 09:29:12 2011 +0000
+++ b/tools/xcutils/xc_save.c	Wed Dec 14 09:29:15 2011 +0000
@@ -169,6 +169,10 @@ main(int argc, char **argv)
     unsigned int maxit, max_f;
     int io_fd, ret, port;
     struct save_callbacks callbacks;
+    char path[128];
+    struct xs_handle *xs;
+    char *addr;
+    unsigned long vm_generationid_addr;
 
     if (argc != 6)
         errx(1, "usage: %s iofd domid maxit maxf flags", argv[0]);
@@ -207,8 +211,21 @@ main(int argc, char **argv)
     memset(&callbacks, 0, sizeof(callbacks));
     callbacks.suspend = suspend;
     callbacks.switch_qemu_logdirty = switch_qemu_logdirty;
+
+    sprintf(path, "/local/domain/%d/data/generation-id-address", si.domid);
+
+    if ((xs = xs_daemon_open()) == NULL)
+        errx(1, "Couldn't contact xenstore");
+
+    addr = xs_read(xs, XBT_NULL, path, NULL);
+
+    xs_daemon_close(xs);
+
+    vm_generationid_addr = (addr) ? strtoul(addr, NULL, 0) : 0;
+    free(addr);
+
     ret = xc_domain_save(si.xch, io_fd, si.domid, maxit, max_f, si.flags, 
-                         &callbacks, !!(si.flags & XCFLAGS_HVM));
+                         &callbacks, !!(si.flags & XCFLAGS_HVM), vm_generationid_addr);
 
     if (si.suspend_evtchn > 0)
 	 xc_suspend_evtchn_release(si.xch, si.xce, si.domid, si.suspend_evtchn);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 09:36:28 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 09:36:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RalFu-0006Hd-N3; Wed, 14 Dec 2011 09:36:06 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RalFt-0006Gt-2I
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 09:36:05 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1323855306!5305691!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjA4OTk=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26773 invoked from network); 14 Dec 2011 09:35:09 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Dec 2011 09:35:09 -0000
X-IronPort-AV: E=Sophos;i="4.71,351,1320642000"; d="scan'208";a="174077598"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Dec 2011 04:35:07 -0500
Received: from cosworth.uk.xensource.com (10.80.16.52) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 14 Dec 2011 04:35:07 -0500
MIME-Version: 1.0
X-Mercurial-Node: 972927dc84c7e22520f4771d58d4770bf2726816
Message-ID: <972927dc84c7e22520f4.1323855072@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1323855070@cosworth.uk.xensource.com>
References: <patchbomb.1323855070@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Wed, 14 Dec 2011 09:31:12 +0000
From: Paul Durrant <paul.durrant@citrix.com>
To: xen-devel@lists.xensource.com
Cc: paul.durrant@citrix.com
Subject: [Xen-devel] [PATCH 2 of 2] VM generation ID save/restore and migrate
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Paul Durrant <paul.durrant@citrix.com>
# Date 1323854955 0
# Node ID 972927dc84c7e22520f4771d58d4770bf2726816
# Parent  fded65be5d82461e87de54960db14ce8feb4625f
VM generation ID save/restore and migrate.

Add code to track the address of the VM generation ID buffer across a
save/restore or migrate, and increment it as necessary.
The address of the buffer is written into xenstore by hvmloader at
boot time. It must be read from xenstore by the caller of
xc_domain_save() and then written back again by the caller of
xc_domain_restore().

Signed-off-by: Paul Durrant <paul.durrant@citrix.com>

diff -r fded65be5d82 -r 972927dc84c7 tools/libxc/ia64/xc_ia64_linux_restore.c
--- a/tools/libxc/ia64/xc_ia64_linux_restore.c	Wed Dec 14 09:29:12 2011 +0000
+++ b/tools/libxc/ia64/xc_ia64_linux_restore.c	Wed Dec 14 09:29:15 2011 +0000
@@ -548,7 +548,8 @@ int
 xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
                   unsigned int store_evtchn, unsigned long *store_mfn,
                   unsigned int console_evtchn, unsigned long *console_mfn,
-                  unsigned int hvm, unsigned int pae, int superpages)
+                  unsigned int hvm, unsigned int pae, int superpages,
+                  int no_incr_generationid, unsigned long *vm_generationid_addr)
 {
     DECLARE_DOMCTL;
     int rc = 1;
diff -r fded65be5d82 -r 972927dc84c7 tools/libxc/ia64/xc_ia64_linux_save.c
--- a/tools/libxc/ia64/xc_ia64_linux_save.c	Wed Dec 14 09:29:12 2011 +0000
+++ b/tools/libxc/ia64/xc_ia64_linux_save.c	Wed Dec 14 09:29:15 2011 +0000
@@ -382,7 +382,8 @@ out:
 int
 xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iters,
                uint32_t max_factor, uint32_t flags,
-               struct save_callbacks* callbacks, int hvm)
+               struct save_callbacks* callbacks, int hvm,
+               unsigned long vm_generationid_addr)
 {
     DECLARE_DOMCTL;
     xc_dominfo_t info;
diff -r fded65be5d82 -r 972927dc84c7 tools/libxc/xc_domain_restore.c
--- a/tools/libxc/xc_domain_restore.c	Wed Dec 14 09:29:12 2011 +0000
+++ b/tools/libxc/xc_domain_restore.c	Wed Dec 14 09:29:15 2011 +0000
@@ -681,6 +681,7 @@ typedef struct {
     uint64_t console_pfn;
     uint64_t acpi_ioport_location;
     uint64_t viridian;
+    uint64_t vm_generationid_addr;
 } pagebuf_t;
 
 static int pagebuf_init(pagebuf_t* buf)
@@ -860,6 +861,17 @@ static int pagebuf_get_one(xc_interface 
         }
         return compbuf_size;
 
+    case XC_SAVE_ID_HVM_GENERATION_ID_ADDR:
+        /* Skip padding 4 bytes then read the generation id buffer location. */
+        if ( RDEXACT(fd, &buf->vm_generationid_addr, sizeof(uint32_t)) ||
+             RDEXACT(fd, &buf->vm_generationid_addr, sizeof(uint64_t)) )
+        {
+            PERROR("error read the generation id buffer location");
+            return -1;
+        }
+        DPRINTF("read generation id buffer address");
+        return pagebuf_get_one(xch, ctx, buf, fd, dom);
+
     default:
         if ( (count > MAX_BATCH_SIZE) || (count < 0) ) {
             ERROR("Max batch size exceeded (%d). Giving up.", count);
@@ -1248,7 +1260,8 @@ static int apply_batch(xc_interface *xch
 int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
                       unsigned int store_evtchn, unsigned long *store_mfn,
                       unsigned int console_evtchn, unsigned long *console_mfn,
-                      unsigned int hvm, unsigned int pae, int superpages)
+                      unsigned int hvm, unsigned int pae, int superpages,
+                      int no_incr_generationid, unsigned long *vm_generationid_addr)
 {
     DECLARE_DOMCTL;
     int rc = 1, frc, i, j, n, m, pae_extended_cr3 = 0, ext_vcpucontext = 0;
@@ -1449,6 +1462,39 @@ int xc_domain_restore(xc_interface *xch,
                 xc_set_hvm_param(xch, dom, HVM_PARAM_VM86_TSS, pagebuf.vm86_tss);
             if ( pagebuf.console_pfn )
                 console_pfn = pagebuf.console_pfn;
+            if ( pagebuf.vm_generationid_addr ) {
+                if ( !no_incr_generationid ) {
+                    unsigned int offset;
+                    unsigned char *buf;
+                    unsigned long long generationid;
+
+                    /*
+                     * Map the VM generation id buffer and inject the new value.
+                     */
+
+                    pfn = pagebuf.vm_generationid_addr >> PAGE_SHIFT;
+                    offset = pagebuf.vm_generationid_addr & (PAGE_SIZE - 1);
+                
+                    if ( (pfn >= dinfo->p2m_size) ||
+                         (pfn_type[pfn] != XEN_DOMCTL_PFINFO_NOTAB) )
+                    {
+                        ERROR("generation id buffer frame is bad");
+                        goto out;
+                    }
+
+                    mfn = ctx->p2m[pfn];
+                    buf = xc_map_foreign_range(xch, dom, PAGE_SIZE,
+                                               PROT_READ | PROT_WRITE, mfn);
+
+                    generationid = *(unsigned long long *)(buf + offset);
+                    *(unsigned long long *)(buf + offset) = generationid + 1;
+
+                    munmap(buf, PAGE_SIZE);
+                }
+
+                *vm_generationid_addr = pagebuf.vm_generationid_addr;
+            }
+
             break;  /* our work here is done */
         }
 
diff -r fded65be5d82 -r 972927dc84c7 tools/libxc/xc_domain_save.c
--- a/tools/libxc/xc_domain_save.c	Wed Dec 14 09:29:12 2011 +0000
+++ b/tools/libxc/xc_domain_save.c	Wed Dec 14 09:29:15 2011 +0000
@@ -804,7 +804,8 @@ static int save_tsc_info(xc_interface *x
 
 int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iters,
                    uint32_t max_factor, uint32_t flags,
-                   struct save_callbacks* callbacks, int hvm)
+                   struct save_callbacks* callbacks, int hvm,
+                   unsigned long vm_generationid_addr)
 {
     xc_dominfo_t info;
     DECLARE_DOMCTL;
@@ -1616,6 +1617,16 @@ int xc_domain_save(xc_interface *xch, in
             uint64_t data;
         } chunk = { 0, };
 
+        chunk.id = XC_SAVE_ID_HVM_GENERATION_ID_ADDR;
+        chunk.data = vm_generationid_addr;
+
+        if ( (chunk.data != 0) &&
+             wrexact(io_fd, &chunk, sizeof(chunk)) )
+        {
+            PERROR("Error when writing the generation id buffer location for guest");
+            goto out;
+        }
+
         chunk.id = XC_SAVE_ID_HVM_IDENT_PT;
         chunk.data = 0;
         xc_get_hvm_param(xch, dom, HVM_PARAM_IDENT_PT,
diff -r fded65be5d82 -r 972927dc84c7 tools/libxc/xenguest.h
--- a/tools/libxc/xenguest.h	Wed Dec 14 09:29:12 2011 +0000
+++ b/tools/libxc/xenguest.h	Wed Dec 14 09:29:15 2011 +0000
@@ -58,7 +58,8 @@ struct save_callbacks {
  */
 int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iters,
                    uint32_t max_factor, uint32_t flags /* XCFLAGS_xxx */,
-                   struct save_callbacks* callbacks, int hvm);
+                   struct save_callbacks* callbacks, int hvm,
+                   unsigned long vm_generationid_addr);
 
 
 /**
@@ -72,12 +73,15 @@ int xc_domain_save(xc_interface *xch, in
  * @parm hvm non-zero if this is a HVM restore
  * @parm pae non-zero if this HVM domain has PAE support enabled
  * @parm superpages non-zero to allocate guest memory with superpages
+ * @parm no_incr_generationid non-zero if generation id is NOT to be incremented
+ * @parm vm_generationid_addr returned with the address of the generation id buffer
  * @return 0 on success, -1 on failure
  */
 int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
                       unsigned int store_evtchn, unsigned long *store_mfn,
                       unsigned int console_evtchn, unsigned long *console_mfn,
-                      unsigned int hvm, unsigned int pae, int superpages);
+                      unsigned int hvm, unsigned int pae, int superpages,
+                      int no_incr_generationid, unsigned long *vm_generationid_addr);
 /**
  * xc_domain_restore writes a file to disk that contains the device
  * model saved state.
diff -r fded65be5d82 -r 972927dc84c7 tools/libxc/xg_save_restore.h
--- a/tools/libxc/xg_save_restore.h	Wed Dec 14 09:29:12 2011 +0000
+++ b/tools/libxc/xg_save_restore.h	Wed Dec 14 09:29:15 2011 +0000
@@ -253,6 +253,7 @@
 #define XC_SAVE_ID_HVM_VIRIDIAN       -11
 #define XC_SAVE_ID_COMPRESSED_DATA    -12 /* Marker to indicate arrival of compressed data */
 #define XC_SAVE_ID_ENABLE_COMPRESSION -13 /* Marker to enable compression logic at receiver side */
+#define XC_SAVE_ID_HVM_GENERATION_ID_ADDR -14
 
 /*
 ** We process save/restore/migrate in batches of pages; the below
diff -r fded65be5d82 -r 972927dc84c7 tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Wed Dec 14 09:29:12 2011 +0000
+++ b/tools/libxl/libxl_create.c	Wed Dec 14 09:29:15 2011 +0000
@@ -99,6 +99,7 @@ int libxl_init_build_info(libxl_ctx *ctx
         b_info->u.hvm.vpt_align = 1;
         b_info->u.hvm.timer_mode = 1;
         b_info->u.hvm.nested_hvm = 0;
+        b_info->u.hvm.no_incr_generationid = 0;
         break;
     case LIBXL_DOMAIN_TYPE_PV:
         b_info->u.pv.slack_memkb = 8 * 1024;
diff -r fded65be5d82 -r 972927dc84c7 tools/libxl/libxl_dom.c
--- a/tools/libxl/libxl_dom.c	Wed Dec 14 09:29:12 2011 +0000
+++ b/tools/libxl/libxl_dom.c	Wed Dec 14 09:29:15 2011 +0000
@@ -124,7 +124,7 @@ int libxl__build_post(libxl__gc *gc, uin
     if (info->cpuid != NULL)
         libxl_cpuid_set(ctx, domid, info->cpuid);
 
-    ents = libxl__calloc(gc, 12 + (info->max_vcpus * 2) + 2, sizeof(char *));
+    ents = libxl__calloc(gc, 14 + (info->max_vcpus * 2) + 2, sizeof(char *));
     ents[0] = "memory/static-max";
     ents[1] = libxl__sprintf(gc, "%d", info->max_memkb);
     ents[2] = "memory/target";
@@ -137,9 +137,11 @@ int libxl__build_post(libxl__gc *gc, uin
     ents[9] = libxl__sprintf(gc, "%"PRIu32, state->store_port);
     ents[10] = "store/ring-ref";
     ents[11] = libxl__sprintf(gc, "%lu", state->store_mfn);
+    ents[12] = "data/generation-id-address";
+    ents[13] = libxl__sprintf(gc, "0x%lx", state->vm_generationid_addr);
     for (i = 0; i < info->max_vcpus; i++) {
-        ents[12+(i*2)]   = libxl__sprintf(gc, "cpu/%d/availability", i);
-        ents[12+(i*2)+1] = (i && info->cur_vcpus && !(info->cur_vcpus & (1 << i)))
+        ents[14+(i*2)]   = libxl__sprintf(gc, "cpu/%d/availability", i);
+        ents[14+(i*2)+1] = (i && info->cur_vcpus && !(info->cur_vcpus & (1 << i)))
                             ? "offline" : "online";
     }
 
@@ -356,16 +358,19 @@ int libxl__domain_restore_common(libxl__
     /* read signature */
     int rc;
     int hvm, pae, superpages;
+    int no_incr_generationid;
     switch (info->type) {
     case LIBXL_DOMAIN_TYPE_HVM:
         hvm = 1;
         superpages = 1;
         pae = info->u.hvm.pae;
+        no_incr_generationid = info->u.hvm.no_incr_generationid;
         break;
     case LIBXL_DOMAIN_TYPE_PV:
         hvm = 0;
         superpages = 0;
         pae = 1;
+        no_incr_generationid = 0;
         break;
     default:
         return ERROR_INVAL;
@@ -373,7 +378,8 @@ int libxl__domain_restore_common(libxl__
     rc = xc_domain_restore(ctx->xch, fd, domid,
                            state->store_port, &state->store_mfn,
                            state->console_port, &state->console_mfn,
-                           hvm, pae, superpages);
+                           hvm, pae, superpages, no_incr_generationid,
+                           &state->vm_generationid_addr);
     if ( rc ) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "restoring domain");
         return ERROR_FAIL;
@@ -539,12 +545,22 @@ int libxl__domain_suspend_common(libxl__
     struct save_callbacks callbacks;
     struct suspendinfo si;
     int hvm, rc = ERROR_FAIL;
+    unsigned long vm_generationid_addr;
 
     switch (type) {
-    case LIBXL_DOMAIN_TYPE_HVM:
+    case LIBXL_DOMAIN_TYPE_HVM: {
+        char *path;
+        char *addr;
+
+        path = libxl__sprintf(gc, "%s/data/generation-id-address", libxl__xs_get_dompath(gc, domid));
+        addr = libxl__xs_read(gc, XBT_NULL, path);
+
+        vm_generationid_addr = (addr) ? strtoul(addr, NULL, 0) : 0;
         hvm = 1;
         break;
+    }
     case LIBXL_DOMAIN_TYPE_PV:
+        vm_generationid_addr = 0;
         hvm = 0;
         break;
     default:
@@ -582,7 +598,8 @@ int libxl__domain_suspend_common(libxl__
     callbacks.switch_qemu_logdirty = libxl__domain_suspend_common_switch_qemu_logdirty;
     callbacks.data = &si;
 
-    rc = xc_domain_save(ctx->xch, fd, domid, 0, 0, flags, &callbacks, hvm);
+    rc = xc_domain_save(ctx->xch, fd, domid, 0, 0, flags, &callbacks,
+                        hvm, vm_generationid_addr);
     if ( rc ) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "saving domain: %s",
                          si.guest_responded ?
diff -r fded65be5d82 -r 972927dc84c7 tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Wed Dec 14 09:29:12 2011 +0000
+++ b/tools/libxl/libxl_internal.h	Wed Dec 14 09:29:15 2011 +0000
@@ -218,6 +218,7 @@ typedef struct {
 
     uint32_t console_port;
     unsigned long console_mfn;
+    unsigned long vm_generationid_addr;
 } libxl__domain_build_state;
 
 _hidden int libxl__build_pre(libxl__gc *gc, uint32_t domid,
diff -r fded65be5d82 -r 972927dc84c7 tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Wed Dec 14 09:29:12 2011 +0000
+++ b/tools/libxl/libxl_types.idl	Wed Dec 14 09:29:15 2011 +0000
@@ -184,6 +184,7 @@ libxl_domain_build_info = Struct("domain
                                        ("vpt_align", bool),
                                        ("timer_mode", integer),
                                        ("nested_hvm", bool),
+                                       ("no_incr_generationid", bool),
                                        ])),
                  ("pv", Struct(None, [("kernel", libxl_file_reference),
                                       ("slack_memkb", uint32),
diff -r fded65be5d82 -r 972927dc84c7 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Wed Dec 14 09:29:12 2011 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Wed Dec 14 09:29:15 2011 +0000
@@ -360,6 +360,7 @@ static void printf_info(int domid,
         printf("\t\t\t(vpt_align %d)\n", b_info->u.hvm.vpt_align);
         printf("\t\t\t(timer_mode %d)\n", b_info->u.hvm.timer_mode);
         printf("\t\t\t(nestedhvm %d)\n", b_info->u.hvm.nested_hvm);
+        printf("\t\t\t(no_incr_generationid %d)\n", b_info->u.hvm.no_incr_generationid);
 
         printf("\t\t\t(device_model %s)\n", dm_info->device_model ? : "default");
         printf("\t\t\t(videoram %d)\n", dm_info->videoram);
@@ -1362,6 +1363,7 @@ struct domain_create {
     const char *restore_file;
     int migrate_fd; /* -1 means none */
     char **migration_domname_r; /* from malloc */
+    int no_incr_generationid;
 };
 
 static int freemem(libxl_domain_build_info *b_info, libxl_device_model_info *dm_info)
@@ -1575,6 +1577,8 @@ static int create_domain(struct domain_c
         }
     }
 
+    d_config.b_info.u.hvm.no_incr_generationid = dom_info->no_incr_generationid;
+
     if (debug || dom_info->dryrun)
         printf_info(-1, &d_config, &d_config.dm_info);
 
@@ -2800,6 +2804,7 @@ static void migrate_receive(int debug, i
     dom_info.restore_file = "incoming migration stream";
     dom_info.migrate_fd = 0; /* stdin */
     dom_info.migration_domname_r = &migration_domname;
+    dom_info.no_incr_generationid = 1;
 
     rc = create_domain(&dom_info);
     if (rc < 0) {
diff -r fded65be5d82 -r 972927dc84c7 tools/python/xen/lowlevel/checkpoint/libcheckpoint.c
--- a/tools/python/xen/lowlevel/checkpoint/libcheckpoint.c	Wed Dec 14 09:29:12 2011 +0000
+++ b/tools/python/xen/lowlevel/checkpoint/libcheckpoint.c	Wed Dec 14 09:29:15 2011 +0000
@@ -175,6 +175,7 @@ int checkpoint_start(checkpoint_state* s
 {
     int hvm, rc;
     int flags = XCFLAGS_LIVE;
+    unsigned long vm_generationid_addr;
 
     if (!s->domid) {
        s->errstr = "checkpoint state not opened";
@@ -185,16 +186,27 @@ int checkpoint_start(checkpoint_state* s
 
     hvm = s->domtype > dt_pv;
     if (hvm) {
+       char path[128];
+       char *addr;
+
+       sprintf(path, "/local/domain/%u/data/generation-id-address", s->domid);
+       addr = xs_read(s->xsh, XBT_NULL, path, NULL);
+
+       vm_generationid_addr = (addr) ? strtoul(addr, NULL, 0) : 0;
+       free(addr);
+
        flags |= XCFLAGS_HVM;
        if (switch_qemu_logdirty(s, 1))
            return -1;
+    } else {
+       vm_generationid_addr = 0;
     }
     if (remus_flags & CHECKPOINT_FLAGS_COMPRESSION)
       flags |= XCFLAGS_CHECKPOINT_COMPRESS;
 
     callbacks->switch_qemu_logdirty = noop_switch_logdirty;
 
-    rc = xc_domain_save(s->xch, fd, s->domid, 0, 0, flags, callbacks, hvm);
+    rc = xc_domain_save(s->xch, fd, s->domid, 0, 0, flags, callbacks, hvm, vm_generationid_addr);
 
     if (hvm)
        switch_qemu_logdirty(s, 0);
diff -r fded65be5d82 -r 972927dc84c7 tools/xcutils/xc_restore.c
--- a/tools/xcutils/xc_restore.c	Wed Dec 14 09:29:12 2011 +0000
+++ b/tools/xcutils/xc_restore.c	Wed Dec 14 09:29:15 2011 +0000
@@ -23,11 +23,12 @@ main(int argc, char **argv)
     xc_interface *xch;
     int io_fd, ret;
     int superpages;
-    unsigned long store_mfn, console_mfn;
+    unsigned long store_mfn, console_mfn, vm_generationid_addr;
+    int no_incr_generationid;
 
-    if ( (argc != 8) && (argc != 9) )
+    if ( (argc < 8) || (argc > 10) )
         errx(1, "usage: %s iofd domid store_evtchn "
-             "console_evtchn hvm pae apic [superpages]", argv[0]);
+             "console_evtchn hvm pae apic [superpages [no_incr_generationid]]", argv[0]);
 
     xch = xc_interface_open(0,0,0);
     if ( !xch )
@@ -40,19 +41,25 @@ main(int argc, char **argv)
     hvm  = atoi(argv[5]);
     pae  = atoi(argv[6]);
     apic = atoi(argv[7]);
-    if ( argc == 9 )
+    if ( argc >= 9 )
 	    superpages = atoi(argv[8]);
     else
 	    superpages = !!hvm;
+    if ( argc == 10 )
+	    no_incr_generationid = !atoi(argv[9]);
+    else
+	    no_incr_generationid = 0;
 
     ret = xc_domain_restore(xch, io_fd, domid, store_evtchn, &store_mfn,
-                            console_evtchn, &console_mfn, hvm, pae, superpages);
+                            console_evtchn, &console_mfn, hvm, pae, superpages,
+                            no_incr_generationid, &vm_generationid_addr);
 
     if ( ret == 0 )
     {
 	printf("store-mfn %li\n", store_mfn);
         if ( !hvm )
             printf("console-mfn %li\n", console_mfn);
+	printf("vm-gid-addr %lx\n", vm_generationid_addr);
 	fflush(stdout);
     }
 
diff -r fded65be5d82 -r 972927dc84c7 tools/xcutils/xc_save.c
--- a/tools/xcutils/xc_save.c	Wed Dec 14 09:29:12 2011 +0000
+++ b/tools/xcutils/xc_save.c	Wed Dec 14 09:29:15 2011 +0000
@@ -169,6 +169,10 @@ main(int argc, char **argv)
     unsigned int maxit, max_f;
     int io_fd, ret, port;
     struct save_callbacks callbacks;
+    char path[128];
+    struct xs_handle *xs;
+    char *addr;
+    unsigned long vm_generationid_addr;
 
     if (argc != 6)
         errx(1, "usage: %s iofd domid maxit maxf flags", argv[0]);
@@ -207,8 +211,21 @@ main(int argc, char **argv)
     memset(&callbacks, 0, sizeof(callbacks));
     callbacks.suspend = suspend;
     callbacks.switch_qemu_logdirty = switch_qemu_logdirty;
+
+    sprintf(path, "/local/domain/%d/data/generation-id-address", si.domid);
+
+    if ((xs = xs_daemon_open()) == NULL)
+        errx(1, "Couldn't contact xenstore");
+
+    addr = xs_read(xs, XBT_NULL, path, NULL);
+
+    xs_daemon_close(xs);
+
+    vm_generationid_addr = (addr) ? strtoul(addr, NULL, 0) : 0;
+    free(addr);
+
     ret = xc_domain_save(si.xch, io_fd, si.domid, maxit, max_f, si.flags, 
-                         &callbacks, !!(si.flags & XCFLAGS_HVM));
+                         &callbacks, !!(si.flags & XCFLAGS_HVM), vm_generationid_addr);
 
     if (si.suspend_evtchn > 0)
 	 xc_suspend_evtchn_release(si.xch, si.xce, si.domid, si.suspend_evtchn);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 09:37:23 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 09: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.xensource.com>)
	id 1RalGo-0006Pg-DH; Wed, 14 Dec 2011 09:37:02 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RalGn-0006PO-8N
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 09:37:01 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1323855326!48927233!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDYyMDY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21391 invoked from network); 14 Dec 2011 09:35:27 -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;
	14 Dec 2011 09:35:27 -0000
X-IronPort-AV: E=Sophos;i="4.71,351,1320642000"; d="scan'208";a="19946982"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Dec 2011 04:35:06 -0500
Received: from cosworth.uk.xensource.com (10.80.16.52) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 14 Dec 2011 04:35:06 -0500
MIME-Version: 1.0
X-Mercurial-Node: fded65be5d82461e87de54960db14ce8feb4625f
Message-ID: <fded65be5d82461e87de.1323855071@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1323855070@cosworth.uk.xensource.com>
References: <patchbomb.1323855070@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Wed, 14 Dec 2011 09:31:11 +0000
From: Paul Durrant <paul.durrant@citrix.com>
To: xen-devel@lists.xensource.com
Cc: paul.durrant@citrix.com
Subject: [Xen-devel] [PATCH 1 of 2] Re-name xenstore key used to save VM
 generation ID buffer address
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Paul Durrant <paul.durrant@citrix.com>
# Date 1323854952 0
# Node ID fded65be5d82461e87de54960db14ce8feb4625f
# Parent  03138a08366b895d79e143119d4c9c72833cdbcd
Re-name xenstore key used to save VM generation ID buffer address.

Signed-off-by: Paul Durrant <paul.durrant@citrix.com>

diff -r 03138a08366b -r fded65be5d82 tools/firmware/hvmloader/acpi/build.c
--- a/tools/firmware/hvmloader/acpi/build.c	Fri Dec 09 16:19:36 2011 +0000
+++ b/tools/firmware/hvmloader/acpi/build.c	Wed Dec 14 09:29:12 2011 +0000
@@ -309,7 +309,7 @@ unsigned long new_vm_gid(void)
     if ( snprintf(addr, sizeof(addr), "0x%lx", virt_to_phys(buf))
          >= sizeof(addr) )
         return 0;
-    xenstore_write("data/generation-id", addr);
+    xenstore_write("data/generation-id-address", addr);
 
     gid = strtoll(xenstore_read("platform/generation-id", "0"), NULL, 0);
     *(uint64_t *)buf = gid;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 09:37:23 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 09: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.xensource.com>)
	id 1RalGo-0006Pg-DH; Wed, 14 Dec 2011 09:37:02 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RalGn-0006PO-8N
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 09:37:01 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1323855326!48927233!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDYyMDY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21391 invoked from network); 14 Dec 2011 09:35:27 -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;
	14 Dec 2011 09:35:27 -0000
X-IronPort-AV: E=Sophos;i="4.71,351,1320642000"; d="scan'208";a="19946982"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Dec 2011 04:35:06 -0500
Received: from cosworth.uk.xensource.com (10.80.16.52) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 14 Dec 2011 04:35:06 -0500
MIME-Version: 1.0
X-Mercurial-Node: fded65be5d82461e87de54960db14ce8feb4625f
Message-ID: <fded65be5d82461e87de.1323855071@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1323855070@cosworth.uk.xensource.com>
References: <patchbomb.1323855070@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Wed, 14 Dec 2011 09:31:11 +0000
From: Paul Durrant <paul.durrant@citrix.com>
To: xen-devel@lists.xensource.com
Cc: paul.durrant@citrix.com
Subject: [Xen-devel] [PATCH 1 of 2] Re-name xenstore key used to save VM
 generation ID buffer address
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Paul Durrant <paul.durrant@citrix.com>
# Date 1323854952 0
# Node ID fded65be5d82461e87de54960db14ce8feb4625f
# Parent  03138a08366b895d79e143119d4c9c72833cdbcd
Re-name xenstore key used to save VM generation ID buffer address.

Signed-off-by: Paul Durrant <paul.durrant@citrix.com>

diff -r 03138a08366b -r fded65be5d82 tools/firmware/hvmloader/acpi/build.c
--- a/tools/firmware/hvmloader/acpi/build.c	Fri Dec 09 16:19:36 2011 +0000
+++ b/tools/firmware/hvmloader/acpi/build.c	Wed Dec 14 09:29:12 2011 +0000
@@ -309,7 +309,7 @@ unsigned long new_vm_gid(void)
     if ( snprintf(addr, sizeof(addr), "0x%lx", virt_to_phys(buf))
          >= sizeof(addr) )
         return 0;
-    xenstore_write("data/generation-id", addr);
+    xenstore_write("data/generation-id-address", addr);
 
     gid = strtoll(xenstore_read("platform/generation-id", "0"), NULL, 0);
     *(uint64_t *)buf = gid;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 09:37:24 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 09:37:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RalGu-0006R4-Qt; Wed, 14 Dec 2011 09:37:08 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RalGt-0006Pf-NR
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 09:37:07 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1323855372!7333264!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTc4Ng==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 901 invoked from network); 14 Dec 2011 09:36:12 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Dec 2011 09:36:12 -0000
X-IronPort-AV: E=Sophos;i="4.71,351,1320624000"; 
   d="scan'208";a="9456353"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Dec 2011 09:36:12 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 14 Dec 2011 09:36:12 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Liwei <xieliwei@gmail.com>
Date: Wed, 14 Dec 2011 09:36:11 +0000
In-Reply-To: <CAPE0SYwsqRKDuPTz66r0nTVPYcsFx0Dk2j0pWpCiHELuU5W2iA@mail.gmail.com>
References: <CAPE0SYwsqRKDuPTz66r0nTVPYcsFx0Dk2j0pWpCiHELuU5W2iA@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323855372.20077.362.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] PTE Write access is not set
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2011-12-14 at 08:05 +0000, Liwei wrote:
> Hello list,
>     Using the 3.1.5 kernel and 4.1.3-rc1-pre xen (Latest ChangeSet:
> Tue Dec 06 10:53:12 2011 +0000 23199:d9f8316a8291), these crashes
> occur after about a day or so of running a HVM:
> =================8<=================
> (XEN) realmode.c:115:d9 Failed to emulate insn.
> (XEN) realmode.c:165:d9 Real-mode emulation failed @ e40a:00005f6c: d9
> 33 01 fc 30 34

I think this is FNSTENV/FSTENV which doesn't seem to be emulated by
Xen :-( xen/arch/x86/x86_emulate/x86_emulate.c has:
                 /* case 6: fstenv - TODO */

Ian.

> (XEN) domain_crash called from realmode.c:166
> (XEN) Domain 9 (vcpu#0) crashed on cpu#6:
> (XEN) ----[ Xen-4.1.3-rc1-pre  x86_64  debug=n  Not tainted ]----
> (XEN) CPU:    6
> (XEN) RIP:    e40a:[<0000000000005f6c>]
> (XEN) RFLAGS: 0000000000010002   CONTEXT: hvm guest
> (XEN) rax: 000000000000e7e5   rbx: 0000000000000000   rcx: 00000000000d0000
> (XEN) rdx: 00000000000001f7   rsi: 0000000000000000   rdi: 0000000000000dba
> (XEN) rbp: 0000000000000182   rsp: 0000000000000db0   r8:  0000000000000000
> (XEN) r9:  0000000000000000   r10: 0000000000000000   r11: 0000000000000000
> (XEN) r12: 0000000000000000   r13: 0000000000000000   r14: 0000000000000000
> (XEN) r15: 0000000000000000   cr0: 0000000000000010   cr4: 0000000000000000
> (XEN) cr3: 0000000000000000   cr2: 0000000000000000
> (XEN) ds: 9fc0   es: 9e00   fs: 0000   gs: 0000   ss: 9e00   cs: e40a
> =================8<=================
> (XEN) realmode.c:115:d5 Failed to emulate insn.
> (XEN) realmode.c:165:d5 Real-mode emulation failed @ c5d5:000242bc: d9
> 33 01 fc 30 34
> (XEN) domain_crash called from realmode.c:166
> (XEN) Domain 5 (vcpu#0) crashed on cpu#0:
> (XEN) ----[ Xen-4.1.3-rc1-pre  x86_64  debug=n  Not tainted ]----
> (XEN) CPU:    0
> (XEN) RIP:    c5d5:[<00000000000242bc>]
> (XEN) RFLAGS: 0000000000010013   CONTEXT: hvm guest
> (XEN) rax: 000000000000001b   rbx: 0000000000000702   rcx: 0000000000010ba7
> (XEN) rdx: 0000000000008fd5   rsi: 0000000000001333   rdi: 000000000000900e
> (XEN) rbp: 000000000000703e   rsp: 000000000000c5cf   r8:  0000000000000000
> (XEN) r9:  0000000000000000   r10: 0000000000000000   r11: 0000000000000000
> (XEN) r12: 0000000000000000   r13: 0000000000000000   r14: 0000000000000000
> (XEN) r15: 0000000000000000   cr0: 0000000000000010   cr4: 0000000000000000
> (XEN) cr3: 0000000000000000   cr2: 0000000000000000
> (XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: 0000   cs: c5d5
> (XEN) [VT-D]iommu.c:856: iommu_fault_status: Primary Pending Fault
> (XEN) [VT-D]iommu.c:831: DMAR:[DMA Write] Request device [0d:00.1]
> fault addr d8964f44000, iommu reg = ffff82c3fff57000
> (XEN) DMAR:[fault reason 05h] PTE Write access is not set
> (XEN) print_vtd_entries: iommu = ffff83045ce565c0 bdf = d:0.1 gmfn = d8964f44
> (XEN)     root_entry = ffff8304519d1000
> (XEN)     root_entry[d] = 4127af001
> (XEN)     context = ffff8304127af000
> (XEN)     context[1] = 2_414aca001
> (XEN)     l4 = ffff830414aca000
> (XEN)     l4_index = 1b
> (XEN)     l4[1b] = 0
> (XEN)     l4[1b] not present
> =================8<=================
> 
>     If I try to restart the crashed VM, the same crash always occurs
> again during POST (the last thing I see on the VNC console is the BIOS
> boot, before the connection terminates). A dom0 reboot is necessary to
> get things to work again.
>     0d:00.1 is part of an Intel 82575GB quad port network adapter. The
> adapter contains three ports, 0d:00.0, 0d:00.1, 0e:00.0, 0e:00.1. Each
> of them is assigned to a VM. So far the crashes have occurred to VMs
> using 0d:00.1, 0e:00.0 and 0e:00.1. (Pretty sure a crash involving
> 0d:00.0 will come soon).
>     Is this a potential bug, or (more likely?) problematic hardware?
> 
> The relevant PCI subtree looks like this:
> =================8<=================
>  \-[0000:00]-+-00.0
>              +-03.0-[01]--+-00.0
>              |            \-00.1
>              +-05.0-[02-0e]----00.0-[03-0e]--+-00.0-[04]----00.0
> 
> +-02.0-[05-0a]----00.0-[06-0a]--+-02.0-[07]----00.0
>                                              |
>       +-03.0-[08]----00.0
>                                              |
>       +-04.0-[09]----00.0
>                                              |
>       \-05.0-[0a]----00.0
> 
> \-03.0-[0b-0e]----00.0-[0c-0e]--+-02.0-[0d]--+-00.0
> 
>       |            \-00.1
> 
>       \-04.0-[0e]--+-00.0
> 
>                    \-00.1
> =================8<=================
> 
> Thanks!
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 09:37:24 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 09:37:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RalGu-0006R4-Qt; Wed, 14 Dec 2011 09:37:08 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RalGt-0006Pf-NR
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 09:37:07 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1323855372!7333264!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTc4Ng==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 901 invoked from network); 14 Dec 2011 09:36:12 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Dec 2011 09:36:12 -0000
X-IronPort-AV: E=Sophos;i="4.71,351,1320624000"; 
   d="scan'208";a="9456353"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Dec 2011 09:36:12 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 14 Dec 2011 09:36:12 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Liwei <xieliwei@gmail.com>
Date: Wed, 14 Dec 2011 09:36:11 +0000
In-Reply-To: <CAPE0SYwsqRKDuPTz66r0nTVPYcsFx0Dk2j0pWpCiHELuU5W2iA@mail.gmail.com>
References: <CAPE0SYwsqRKDuPTz66r0nTVPYcsFx0Dk2j0pWpCiHELuU5W2iA@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323855372.20077.362.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] PTE Write access is not set
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2011-12-14 at 08:05 +0000, Liwei wrote:
> Hello list,
>     Using the 3.1.5 kernel and 4.1.3-rc1-pre xen (Latest ChangeSet:
> Tue Dec 06 10:53:12 2011 +0000 23199:d9f8316a8291), these crashes
> occur after about a day or so of running a HVM:
> =================8<=================
> (XEN) realmode.c:115:d9 Failed to emulate insn.
> (XEN) realmode.c:165:d9 Real-mode emulation failed @ e40a:00005f6c: d9
> 33 01 fc 30 34

I think this is FNSTENV/FSTENV which doesn't seem to be emulated by
Xen :-( xen/arch/x86/x86_emulate/x86_emulate.c has:
                 /* case 6: fstenv - TODO */

Ian.

> (XEN) domain_crash called from realmode.c:166
> (XEN) Domain 9 (vcpu#0) crashed on cpu#6:
> (XEN) ----[ Xen-4.1.3-rc1-pre  x86_64  debug=n  Not tainted ]----
> (XEN) CPU:    6
> (XEN) RIP:    e40a:[<0000000000005f6c>]
> (XEN) RFLAGS: 0000000000010002   CONTEXT: hvm guest
> (XEN) rax: 000000000000e7e5   rbx: 0000000000000000   rcx: 00000000000d0000
> (XEN) rdx: 00000000000001f7   rsi: 0000000000000000   rdi: 0000000000000dba
> (XEN) rbp: 0000000000000182   rsp: 0000000000000db0   r8:  0000000000000000
> (XEN) r9:  0000000000000000   r10: 0000000000000000   r11: 0000000000000000
> (XEN) r12: 0000000000000000   r13: 0000000000000000   r14: 0000000000000000
> (XEN) r15: 0000000000000000   cr0: 0000000000000010   cr4: 0000000000000000
> (XEN) cr3: 0000000000000000   cr2: 0000000000000000
> (XEN) ds: 9fc0   es: 9e00   fs: 0000   gs: 0000   ss: 9e00   cs: e40a
> =================8<=================
> (XEN) realmode.c:115:d5 Failed to emulate insn.
> (XEN) realmode.c:165:d5 Real-mode emulation failed @ c5d5:000242bc: d9
> 33 01 fc 30 34
> (XEN) domain_crash called from realmode.c:166
> (XEN) Domain 5 (vcpu#0) crashed on cpu#0:
> (XEN) ----[ Xen-4.1.3-rc1-pre  x86_64  debug=n  Not tainted ]----
> (XEN) CPU:    0
> (XEN) RIP:    c5d5:[<00000000000242bc>]
> (XEN) RFLAGS: 0000000000010013   CONTEXT: hvm guest
> (XEN) rax: 000000000000001b   rbx: 0000000000000702   rcx: 0000000000010ba7
> (XEN) rdx: 0000000000008fd5   rsi: 0000000000001333   rdi: 000000000000900e
> (XEN) rbp: 000000000000703e   rsp: 000000000000c5cf   r8:  0000000000000000
> (XEN) r9:  0000000000000000   r10: 0000000000000000   r11: 0000000000000000
> (XEN) r12: 0000000000000000   r13: 0000000000000000   r14: 0000000000000000
> (XEN) r15: 0000000000000000   cr0: 0000000000000010   cr4: 0000000000000000
> (XEN) cr3: 0000000000000000   cr2: 0000000000000000
> (XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: 0000   cs: c5d5
> (XEN) [VT-D]iommu.c:856: iommu_fault_status: Primary Pending Fault
> (XEN) [VT-D]iommu.c:831: DMAR:[DMA Write] Request device [0d:00.1]
> fault addr d8964f44000, iommu reg = ffff82c3fff57000
> (XEN) DMAR:[fault reason 05h] PTE Write access is not set
> (XEN) print_vtd_entries: iommu = ffff83045ce565c0 bdf = d:0.1 gmfn = d8964f44
> (XEN)     root_entry = ffff8304519d1000
> (XEN)     root_entry[d] = 4127af001
> (XEN)     context = ffff8304127af000
> (XEN)     context[1] = 2_414aca001
> (XEN)     l4 = ffff830414aca000
> (XEN)     l4_index = 1b
> (XEN)     l4[1b] = 0
> (XEN)     l4[1b] not present
> =================8<=================
> 
>     If I try to restart the crashed VM, the same crash always occurs
> again during POST (the last thing I see on the VNC console is the BIOS
> boot, before the connection terminates). A dom0 reboot is necessary to
> get things to work again.
>     0d:00.1 is part of an Intel 82575GB quad port network adapter. The
> adapter contains three ports, 0d:00.0, 0d:00.1, 0e:00.0, 0e:00.1. Each
> of them is assigned to a VM. So far the crashes have occurred to VMs
> using 0d:00.1, 0e:00.0 and 0e:00.1. (Pretty sure a crash involving
> 0d:00.0 will come soon).
>     Is this a potential bug, or (more likely?) problematic hardware?
> 
> The relevant PCI subtree looks like this:
> =================8<=================
>  \-[0000:00]-+-00.0
>              +-03.0-[01]--+-00.0
>              |            \-00.1
>              +-05.0-[02-0e]----00.0-[03-0e]--+-00.0-[04]----00.0
> 
> +-02.0-[05-0a]----00.0-[06-0a]--+-02.0-[07]----00.0
>                                              |
>       +-03.0-[08]----00.0
>                                              |
>       +-04.0-[09]----00.0
>                                              |
>       \-05.0-[0a]----00.0
> 
> \-03.0-[0b-0e]----00.0-[0c-0e]--+-02.0-[0d]--+-00.0
> 
>       |            \-00.1
> 
>       \-04.0-[0e]--+-00.0
> 
>                    \-00.1
> =================8<=================
> 
> Thanks!
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 09:41:29 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 09:41:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RalKo-0006xf-PI; Wed, 14 Dec 2011 09:41:10 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RalKn-0006xC-Qo
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 09:41:10 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1323855613!7378224!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjA4OTk=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19329 invoked from network); 14 Dec 2011 09:40:14 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Dec 2011 09:40:14 -0000
X-IronPort-AV: E=Sophos;i="4.71,351,1320642000"; d="scan'208";a="174077998"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Dec 2011 04:40:12 -0500
Received: from cosworth.uk.xensource.com (10.80.16.52) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 14 Dec 2011 04:40:12 -0500
MIME-Version: 1.0
X-Mercurial-Node: acc14cb01dc00acfaf00cf59521666da55e43993
Message-ID: <acc14cb01dc00acfaf00.1323855594@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Wed, 14 Dec 2011 09:39:54 +0000
From: Paul Durrant <paul.durrant@citrix.com>
To: xen-devel@lists.xensource.com
Cc: paul.durrant@citrix.com
Subject: [Xen-devel] [PATCH] Allow VMs to query their own grant table version
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Paul Durrant <paul.durrant@citrix.com>
# Date 1323855588 0
# Node ID acc14cb01dc00acfaf00cf59521666da55e43993
# Parent  03138a08366b895d79e143119d4c9c72833cdbcd
Allow VMs to query their own grant table version.

Signed-off-by: Paul Durrant <paul.durrant@citrix.com>

diff -r 03138a08366b -r acc14cb01dc0 xen/arch/x86/hvm/hvm.c
--- a/xen/arch/x86/hvm/hvm.c	Fri Dec 09 16:19:36 2011 +0000
+++ b/xen/arch/x86/hvm/hvm.c	Wed Dec 14 09:39:48 2011 +0000
@@ -2857,6 +2857,7 @@ static int grant_table_op_is_allowed(uns
     case GNTTABOP_query_size:
     case GNTTABOP_setup_table:
     case GNTTABOP_set_version:
+    case GNTTABOP_get_version:
     case GNTTABOP_copy:
     case GNTTABOP_map_grant_ref:
     case GNTTABOP_unmap_grant_ref:
diff -r 03138a08366b -r acc14cb01dc0 xen/common/grant_table.c
--- a/xen/common/grant_table.c	Fri Dec 09 16:19:36 2011 +0000
+++ b/xen/common/grant_table.c	Wed Dec 14 09:39:48 2011 +0000
@@ -2248,17 +2248,14 @@ gnttab_get_version(XEN_GUEST_HANDLE(gntt
 {
     gnttab_get_version_t op;
     struct domain *d;
+    int rc;
 
     if ( copy_from_guest(&op, uop, 1) )
         return -EFAULT;
-    d = rcu_lock_domain_by_id(op.dom);
-    if ( d == NULL )
-        return -ESRCH;
-    if ( !IS_PRIV_FOR(current->domain, d) )
-    {
-        rcu_unlock_domain(d);
-        return -EPERM;
-    }
+    rc = rcu_lock_target_domain_by_id(op.dom, &d);
+    if ( rc < 0 )
+        return rc;
+
     spin_lock(&d->grant_table->lock);
     op.version = d->grant_table->gt_version;
     spin_unlock(&d->grant_table->lock);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 09:41:29 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 09:41:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RalKo-0006xf-PI; Wed, 14 Dec 2011 09:41:10 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RalKn-0006xC-Qo
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 09:41:10 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1323855613!7378224!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjA4OTk=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19329 invoked from network); 14 Dec 2011 09:40:14 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Dec 2011 09:40:14 -0000
X-IronPort-AV: E=Sophos;i="4.71,351,1320642000"; d="scan'208";a="174077998"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Dec 2011 04:40:12 -0500
Received: from cosworth.uk.xensource.com (10.80.16.52) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 14 Dec 2011 04:40:12 -0500
MIME-Version: 1.0
X-Mercurial-Node: acc14cb01dc00acfaf00cf59521666da55e43993
Message-ID: <acc14cb01dc00acfaf00.1323855594@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Wed, 14 Dec 2011 09:39:54 +0000
From: Paul Durrant <paul.durrant@citrix.com>
To: xen-devel@lists.xensource.com
Cc: paul.durrant@citrix.com
Subject: [Xen-devel] [PATCH] Allow VMs to query their own grant table version
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Paul Durrant <paul.durrant@citrix.com>
# Date 1323855588 0
# Node ID acc14cb01dc00acfaf00cf59521666da55e43993
# Parent  03138a08366b895d79e143119d4c9c72833cdbcd
Allow VMs to query their own grant table version.

Signed-off-by: Paul Durrant <paul.durrant@citrix.com>

diff -r 03138a08366b -r acc14cb01dc0 xen/arch/x86/hvm/hvm.c
--- a/xen/arch/x86/hvm/hvm.c	Fri Dec 09 16:19:36 2011 +0000
+++ b/xen/arch/x86/hvm/hvm.c	Wed Dec 14 09:39:48 2011 +0000
@@ -2857,6 +2857,7 @@ static int grant_table_op_is_allowed(uns
     case GNTTABOP_query_size:
     case GNTTABOP_setup_table:
     case GNTTABOP_set_version:
+    case GNTTABOP_get_version:
     case GNTTABOP_copy:
     case GNTTABOP_map_grant_ref:
     case GNTTABOP_unmap_grant_ref:
diff -r 03138a08366b -r acc14cb01dc0 xen/common/grant_table.c
--- a/xen/common/grant_table.c	Fri Dec 09 16:19:36 2011 +0000
+++ b/xen/common/grant_table.c	Wed Dec 14 09:39:48 2011 +0000
@@ -2248,17 +2248,14 @@ gnttab_get_version(XEN_GUEST_HANDLE(gntt
 {
     gnttab_get_version_t op;
     struct domain *d;
+    int rc;
 
     if ( copy_from_guest(&op, uop, 1) )
         return -EFAULT;
-    d = rcu_lock_domain_by_id(op.dom);
-    if ( d == NULL )
-        return -ESRCH;
-    if ( !IS_PRIV_FOR(current->domain, d) )
-    {
-        rcu_unlock_domain(d);
-        return -EPERM;
-    }
+    rc = rcu_lock_target_domain_by_id(op.dom, &d);
+    if ( rc < 0 )
+        return rc;
+
     spin_lock(&d->grant_table->lock);
     op.version = d->grant_table->gt_version;
     spin_unlock(&d->grant_table->lock);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 09:42:46 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 09:42:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RalM7-00074l-8H; Wed, 14 Dec 2011 09:42:31 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RalM5-000744-MN
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 09:42:29 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1323855693!5481072!1
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3224 invoked from network); 14 Dec 2011 09:41:33 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Dec 2011 09:41:33 -0000
Received: by wgbds11 with SMTP id ds11so1156064wgb.24
	for <xen-devel@lists.xensource.com>;
	Wed, 14 Dec 2011 01:41:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=pnE5HKaomKTDiNHoQI7gISzcR3pkVPBI/ZUUokO8gxw=;
	b=Rs6pbe0HmaFZ5KoMa2YQYg+py1iuantCkAWpXqMhgc/f96OELZ5mKp76Y4OMpxSDzE
	fyEOuWHI9qYnoDPaoHeKD69VsJ4mDshMwBeITPXBHKZqIHkRMbuTFxgdDCTHEUTcP/x6
	Ou9OBhoMtABFoo7dvKyIVatlxXcC+ISHdXvdQ=
Received: by 10.216.135.233 with SMTP id u83mr747401wei.33.1323855692434;
	Wed, 14 Dec 2011 01:41:32 -0800 (PST)
Received: from [192.168.1.3] (host81-152-17-11.range81-152.btcentralplus.com.
	[81.152.17.11])
	by mx.google.com with ESMTPS id ff1sm2885954wbb.5.2011.12.14.01.41.30
	(version=SSLv3 cipher=OTHER); Wed, 14 Dec 2011 01:41:31 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Wed, 14 Dec 2011 09:41:27 +0000
From: Keir Fraser <keir@xen.org>
To: Ian Campbell <Ian.Campbell@citrix.com>,
	Liwei <xieliwei@gmail.com>
Message-ID: <CB0E1FC7.35E37%keir@xen.org>
Thread-Topic: [Xen-devel] PTE Write access is not set
Thread-Index: Acy6RIzRN0898P1otUKB68Uml5JEbg==
In-Reply-To: <1323855372.20077.362.camel@zakaz.uk.xensource.com>
Mime-version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] PTE Write access is not set
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 14/12/2011 09:36, "Ian Campbell" <Ian.Campbell@citrix.com> wrote:

> On Wed, 2011-12-14 at 08:05 +0000, Liwei wrote:
>> Hello list,
>>     Using the 3.1.5 kernel and 4.1.3-rc1-pre xen (Latest ChangeSet:
>> Tue Dec 06 10:53:12 2011 +0000 23199:d9f8316a8291), these crashes
>> occur after about a day or so of running a HVM:
>> =================8<=================
>> (XEN) realmode.c:115:d9 Failed to emulate insn.
>> (XEN) realmode.c:165:d9 Real-mode emulation failed @ e40a:00005f6c: d9
>> 33 01 fc 30 34
> 
> I think this is FNSTENV/FSTENV which doesn't seem to be emulated by
> Xen :-( xen/arch/x86/x86_emulate/x86_emulate.c has:
>                  /* case 6: fstenv - TODO */

I wonder why a long-running HVM guest would be in real mode executing FP
code. That seems a bit fishy.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 09:42:46 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 09:42:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RalM7-00074l-8H; Wed, 14 Dec 2011 09:42:31 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RalM5-000744-MN
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 09:42:29 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1323855693!5481072!1
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3224 invoked from network); 14 Dec 2011 09:41:33 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Dec 2011 09:41:33 -0000
Received: by wgbds11 with SMTP id ds11so1156064wgb.24
	for <xen-devel@lists.xensource.com>;
	Wed, 14 Dec 2011 01:41:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=pnE5HKaomKTDiNHoQI7gISzcR3pkVPBI/ZUUokO8gxw=;
	b=Rs6pbe0HmaFZ5KoMa2YQYg+py1iuantCkAWpXqMhgc/f96OELZ5mKp76Y4OMpxSDzE
	fyEOuWHI9qYnoDPaoHeKD69VsJ4mDshMwBeITPXBHKZqIHkRMbuTFxgdDCTHEUTcP/x6
	Ou9OBhoMtABFoo7dvKyIVatlxXcC+ISHdXvdQ=
Received: by 10.216.135.233 with SMTP id u83mr747401wei.33.1323855692434;
	Wed, 14 Dec 2011 01:41:32 -0800 (PST)
Received: from [192.168.1.3] (host81-152-17-11.range81-152.btcentralplus.com.
	[81.152.17.11])
	by mx.google.com with ESMTPS id ff1sm2885954wbb.5.2011.12.14.01.41.30
	(version=SSLv3 cipher=OTHER); Wed, 14 Dec 2011 01:41:31 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Wed, 14 Dec 2011 09:41:27 +0000
From: Keir Fraser <keir@xen.org>
To: Ian Campbell <Ian.Campbell@citrix.com>,
	Liwei <xieliwei@gmail.com>
Message-ID: <CB0E1FC7.35E37%keir@xen.org>
Thread-Topic: [Xen-devel] PTE Write access is not set
Thread-Index: Acy6RIzRN0898P1otUKB68Uml5JEbg==
In-Reply-To: <1323855372.20077.362.camel@zakaz.uk.xensource.com>
Mime-version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] PTE Write access is not set
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 14/12/2011 09:36, "Ian Campbell" <Ian.Campbell@citrix.com> wrote:

> On Wed, 2011-12-14 at 08:05 +0000, Liwei wrote:
>> Hello list,
>>     Using the 3.1.5 kernel and 4.1.3-rc1-pre xen (Latest ChangeSet:
>> Tue Dec 06 10:53:12 2011 +0000 23199:d9f8316a8291), these crashes
>> occur after about a day or so of running a HVM:
>> =================8<=================
>> (XEN) realmode.c:115:d9 Failed to emulate insn.
>> (XEN) realmode.c:165:d9 Real-mode emulation failed @ e40a:00005f6c: d9
>> 33 01 fc 30 34
> 
> I think this is FNSTENV/FSTENV which doesn't seem to be emulated by
> Xen :-( xen/arch/x86/x86_emulate/x86_emulate.c has:
>                  /* case 6: fstenv - TODO */

I wonder why a long-running HVM guest would be in real mode executing FP
code. That seems a bit fishy.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 09:43:31 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 09:43:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RalMp-0007Ab-MJ; Wed, 14 Dec 2011 09:43:15 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RalMo-00079r-9x
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 09:43:14 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1323855739!7333945!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTc4Ng==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17681 invoked from network); 14 Dec 2011 09:42:19 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Dec 2011 09:42:19 -0000
X-IronPort-AV: E=Sophos;i="4.71,351,1320624000"; 
   d="scan'208";a="9456606"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Dec 2011 09:42:19 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 14 Dec 2011 09:42:19 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Date: Wed, 14 Dec 2011 09:42:18 +0000
In-Reply-To: <alpine.DEB.2.00.1112131817300.3517@kaball-desktop>
References: <alpine.DEB.2.00.1111221551510.31179@kaball-desktop>
	<1322056320-5826-5-git-send-email-stefano.stabellini@eu.citrix.com>
	<20198.15417.932169.223332@mariner.uk.xensource.com>
	<1323712001.20077.234.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1112121924520.3517@kaball-desktop>
	<20199.24118.465585.933183@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1112131720250.3517@kaball-desktop>
	<20199.37117.779165.894809@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1112131817300.3517@kaball-desktop>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323855739.20077.365.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "Keir \(Xen.org\)" <keir@xen.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v9 5/6] Clone and build Seabios by default
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2011-12-13 at 18:22 +0000, Stefano Stabellini wrote:
> On Tue, 13 Dec 2011, Ian Jackson wrote:
> > Stefano Stabellini writes ("Re: [Xen-devel] [PATCH v9 5/6] Clone and build Seabios by default"):
> > > On Tue, 13 Dec 2011, Ian Jackson wrote:
> > > > Stefano Stabellini writes ("Re: [Xen-devel] [PATCH v9 5/6] Clone and build Seabios by default"):
> > > > > On Mon, 12 Dec 2011, Ian Campbell wrote:
> > > > > > On Mon, 2011-12-12 at 17:39 +0000, Ian Jackson wrote:
> > > > > > > I see you have included a lockstep changeset number in xen-unstable
> > > > > > > but are we really able to force these to update in lockstep ?
> > > > 
> > > > Did you have an answer for this ?
> > > 
> > > The answer is yes. Unless there is a bug that I didn't manage to find of
> > > course.
> > 
> > That doesn't sound like an answer to my question.
> > 
> > To put it another way: are we intending to permanently maintain a
> > branch of seabios and a branch of qemu upstream ?  Are we going to
> > have one such branch for each branch of Xen ?  Are we expecting our
> > downstreams to use our specific version of qemu and seabios, rather
> > than building from upstream ?
> 
> I think "yes" in case of qemu, at the very least for the different
> release times of the xen and qemu projects.

Unfortunately I expect that distros will want to package qemu once (from
upstream) with support for all the various options, including Xen,
enabled and depend on that in their Xen packaging rather than packaging
a slightly different qemu a second time.

I'm not sure how we can address this without exploding our test matrix.
It seems like we need to test at a minimum the current qemu stable and
development branches :-/

> I don't have an opinion on seabios because I am nore sure how many
> changes are we going to make to it. However I recall that you and/or
> IanC were in favor of having or own branch of seabios as well.

I think that even if we never diverge from upstream and irrespective of
whether we stick in lockstep or not we should host a tree to point our
users (and default build) at. This gives us flexibility if we ever do
need to diverge and also isolates our users from issues with 3rd party
servers.

> BTW I think it is probably better if IanC maintains seabios if we decide
> to have our own branch, given that he is the one that did most of the
> work on it so far.

I'm happy to do that.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 09:43:31 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 09:43:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RalMp-0007Ab-MJ; Wed, 14 Dec 2011 09:43:15 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RalMo-00079r-9x
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 09:43:14 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1323855739!7333945!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTc4Ng==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17681 invoked from network); 14 Dec 2011 09:42:19 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Dec 2011 09:42:19 -0000
X-IronPort-AV: E=Sophos;i="4.71,351,1320624000"; 
   d="scan'208";a="9456606"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Dec 2011 09:42:19 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 14 Dec 2011 09:42:19 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Date: Wed, 14 Dec 2011 09:42:18 +0000
In-Reply-To: <alpine.DEB.2.00.1112131817300.3517@kaball-desktop>
References: <alpine.DEB.2.00.1111221551510.31179@kaball-desktop>
	<1322056320-5826-5-git-send-email-stefano.stabellini@eu.citrix.com>
	<20198.15417.932169.223332@mariner.uk.xensource.com>
	<1323712001.20077.234.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1112121924520.3517@kaball-desktop>
	<20199.24118.465585.933183@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1112131720250.3517@kaball-desktop>
	<20199.37117.779165.894809@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1112131817300.3517@kaball-desktop>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323855739.20077.365.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "Keir \(Xen.org\)" <keir@xen.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v9 5/6] Clone and build Seabios by default
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2011-12-13 at 18:22 +0000, Stefano Stabellini wrote:
> On Tue, 13 Dec 2011, Ian Jackson wrote:
> > Stefano Stabellini writes ("Re: [Xen-devel] [PATCH v9 5/6] Clone and build Seabios by default"):
> > > On Tue, 13 Dec 2011, Ian Jackson wrote:
> > > > Stefano Stabellini writes ("Re: [Xen-devel] [PATCH v9 5/6] Clone and build Seabios by default"):
> > > > > On Mon, 12 Dec 2011, Ian Campbell wrote:
> > > > > > On Mon, 2011-12-12 at 17:39 +0000, Ian Jackson wrote:
> > > > > > > I see you have included a lockstep changeset number in xen-unstable
> > > > > > > but are we really able to force these to update in lockstep ?
> > > > 
> > > > Did you have an answer for this ?
> > > 
> > > The answer is yes. Unless there is a bug that I didn't manage to find of
> > > course.
> > 
> > That doesn't sound like an answer to my question.
> > 
> > To put it another way: are we intending to permanently maintain a
> > branch of seabios and a branch of qemu upstream ?  Are we going to
> > have one such branch for each branch of Xen ?  Are we expecting our
> > downstreams to use our specific version of qemu and seabios, rather
> > than building from upstream ?
> 
> I think "yes" in case of qemu, at the very least for the different
> release times of the xen and qemu projects.

Unfortunately I expect that distros will want to package qemu once (from
upstream) with support for all the various options, including Xen,
enabled and depend on that in their Xen packaging rather than packaging
a slightly different qemu a second time.

I'm not sure how we can address this without exploding our test matrix.
It seems like we need to test at a minimum the current qemu stable and
development branches :-/

> I don't have an opinion on seabios because I am nore sure how many
> changes are we going to make to it. However I recall that you and/or
> IanC were in favor of having or own branch of seabios as well.

I think that even if we never diverge from upstream and irrespective of
whether we stick in lockstep or not we should host a tree to point our
users (and default build) at. This gives us flexibility if we ever do
need to diverge and also isolates our users from issues with 3rd party
servers.

> BTW I think it is probably better if IanC maintains seabios if we decide
> to have our own branch, given that he is the one that did most of the
> work on it so far.

I'm happy to do that.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 09:45:02 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 09:45:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RalON-0007Kg-7F; Wed, 14 Dec 2011 09:44:51 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <tobias.geiger@vido.info>) id 1RalOL-0007Ju-31
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 09:44:49 +0000
X-Env-Sender: tobias.geiger@vido.info
X-Msg-Ref: server-10.tower-216.messagelabs.com!1323855833!7295127!1
X-Originating-IP: [78.47.43.171]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29912 invoked from network); 14 Dec 2011 09:43:53 -0000
Received: from www.vido.info (HELO mail.vido.info) (78.47.43.171)
	by server-10.tower-216.messagelabs.com with SMTP;
	14 Dec 2011 09:43:53 -0000
Received: from localhost (ip6-localhost [127.0.0.1])
	by mail.vido.info (Postfix) with ESMTP id 896B0D34760;
	Wed, 14 Dec 2011 10:43:53 +0100 (CET)
X-Virus-Scanned: by amavis at mail.vido.info
Received: from mail.vido.info ([127.0.0.1])
	by localhost (mail.vido.info [127.0.0.1]) (amavisd-new, port 10024)
	with LMTP id dTpz-TmC0Olz; Wed, 14 Dec 2011 10:43:47 +0100 (CET)
Received: from lxgeigert.localnet (et-1-10.gw-nat.bs.kae.de.oneandone.net
	[212.227.35.74])
	by mail.vido.info (Postfix) with ESMTPSA id B9019D34668;
	Wed, 14 Dec 2011 10:43:47 +0100 (CET)
From: Tobias Geiger <tobias.geiger@vido.info>
Organization: VIDO IT-Service
To: xen-devel@lists.xensource.com
Date: Wed, 14 Dec 2011 10:43:45 +0100
User-Agent: KMail/1.13.7 (Linux/3.0.0-1-amd64; KDE/4.6.5; x86_64; ; )
References: <20110923172115.GI12984@reaktio.net>
	<1323520193389-5064245.post@n5.nabble.com>
	<1323810239102-5072769.post@n5.nabble.com>
In-Reply-To: <1323810239102-5072769.post@n5.nabble.com>
MIME-Version: 1.0
Message-Id: <201112141043.45780.tobias.geiger@vido.info>
Cc: Sythrar <sythrar@gmail.com>
Subject: Re: [Xen-devel] Re : Re : Re : Re : Re : Re : Re : Re: Patches for
	VGA-Passthrough XEN 4.2 unstable
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi Sythrar,

you can't see the output of the passed-through-VGA Card in VNC. At least not 
in the qemu-vnc server; The output to that emulated (Cirrus?) Card stops as 
soon as  the Driver for the passed-through-VGA Card is loaded within the DomU.
>From that moment on the you can only see the output on a Monitor attached to 
the passed-through-VGA Card. VNC is of course possible with the DomU 
facilities, i.e. install a VNC Server within DomU and attach a vncviewer to it 
- but its not really practical regarding 3D- or Movie Output (at least not 
without optimizations to the VNC Server/Client)

But your dream is possible: Buy a VT-D capable Motherboard and a ATI 6xxx 
Graphics-Card to pass through and you're good to go!
(Nvidia may also work with some patches, but the newer ATI ones don't need any 
patches)

Greetings
Tobias

Am Dienstag, 13. Dezember 2011, 22:03:59 schrieb Sythrar:
> n4rC0t1C, test for me is to run domU with vnc and tell me how was the
> performance. Thank you very much.
> My dream is to play games on linux without wine.
> sorry my english
> 
> --
> View this message in context:
> http://xen.1045712.n5.nabble.com/Patches-for-VGA-Passthrough-XEN-4-2-unsta
> ble-tp4406265p5072769.html Sent from the Xen - Dev mailing list archive at
> Nabble.com.
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 09:45:02 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 09:45:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RalON-0007Kg-7F; Wed, 14 Dec 2011 09:44:51 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <tobias.geiger@vido.info>) id 1RalOL-0007Ju-31
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 09:44:49 +0000
X-Env-Sender: tobias.geiger@vido.info
X-Msg-Ref: server-10.tower-216.messagelabs.com!1323855833!7295127!1
X-Originating-IP: [78.47.43.171]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29912 invoked from network); 14 Dec 2011 09:43:53 -0000
Received: from www.vido.info (HELO mail.vido.info) (78.47.43.171)
	by server-10.tower-216.messagelabs.com with SMTP;
	14 Dec 2011 09:43:53 -0000
Received: from localhost (ip6-localhost [127.0.0.1])
	by mail.vido.info (Postfix) with ESMTP id 896B0D34760;
	Wed, 14 Dec 2011 10:43:53 +0100 (CET)
X-Virus-Scanned: by amavis at mail.vido.info
Received: from mail.vido.info ([127.0.0.1])
	by localhost (mail.vido.info [127.0.0.1]) (amavisd-new, port 10024)
	with LMTP id dTpz-TmC0Olz; Wed, 14 Dec 2011 10:43:47 +0100 (CET)
Received: from lxgeigert.localnet (et-1-10.gw-nat.bs.kae.de.oneandone.net
	[212.227.35.74])
	by mail.vido.info (Postfix) with ESMTPSA id B9019D34668;
	Wed, 14 Dec 2011 10:43:47 +0100 (CET)
From: Tobias Geiger <tobias.geiger@vido.info>
Organization: VIDO IT-Service
To: xen-devel@lists.xensource.com
Date: Wed, 14 Dec 2011 10:43:45 +0100
User-Agent: KMail/1.13.7 (Linux/3.0.0-1-amd64; KDE/4.6.5; x86_64; ; )
References: <20110923172115.GI12984@reaktio.net>
	<1323520193389-5064245.post@n5.nabble.com>
	<1323810239102-5072769.post@n5.nabble.com>
In-Reply-To: <1323810239102-5072769.post@n5.nabble.com>
MIME-Version: 1.0
Message-Id: <201112141043.45780.tobias.geiger@vido.info>
Cc: Sythrar <sythrar@gmail.com>
Subject: Re: [Xen-devel] Re : Re : Re : Re : Re : Re : Re : Re: Patches for
	VGA-Passthrough XEN 4.2 unstable
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi Sythrar,

you can't see the output of the passed-through-VGA Card in VNC. At least not 
in the qemu-vnc server; The output to that emulated (Cirrus?) Card stops as 
soon as  the Driver for the passed-through-VGA Card is loaded within the DomU.
>From that moment on the you can only see the output on a Monitor attached to 
the passed-through-VGA Card. VNC is of course possible with the DomU 
facilities, i.e. install a VNC Server within DomU and attach a vncviewer to it 
- but its not really practical regarding 3D- or Movie Output (at least not 
without optimizations to the VNC Server/Client)

But your dream is possible: Buy a VT-D capable Motherboard and a ATI 6xxx 
Graphics-Card to pass through and you're good to go!
(Nvidia may also work with some patches, but the newer ATI ones don't need any 
patches)

Greetings
Tobias

Am Dienstag, 13. Dezember 2011, 22:03:59 schrieb Sythrar:
> n4rC0t1C, test for me is to run domU with vnc and tell me how was the
> performance. Thank you very much.
> My dream is to play games on linux without wine.
> sorry my english
> 
> --
> View this message in context:
> http://xen.1045712.n5.nabble.com/Patches-for-VGA-Passthrough-XEN-4-2-unsta
> ble-tp4406265p5072769.html Sent from the Xen - Dev mailing list archive at
> Nabble.com.
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 09:58:55 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 09:58:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ralbl-0007f9-Oh; Wed, 14 Dec 2011 09:58:41 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Ralbk-0007f4-I6
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 09:58:40 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1323856664!7196605!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19307 invoked from network); 14 Dec 2011 09:57:45 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-10.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Dec 2011 09:57:45 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 14 Dec 2011 09:57:44 +0000
Message-Id: <4EE881270200007800067A65@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 14 Dec 2011 09:57:43 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Liwei" <xieliwei@gmail.com>
References: <CAPE0SYwsqRKDuPTz66r0nTVPYcsFx0Dk2j0pWpCiHELuU5W2iA@mail.gmail.com>
In-Reply-To: <CAPE0SYwsqRKDuPTz66r0nTVPYcsFx0Dk2j0pWpCiHELuU5W2iA@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] PTE Write access is not set
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 14.12.11 at 09:05, Liwei <xieliwei@gmail.com> wrote:
>     Using the 3.1.5 kernel and 4.1.3-rc1-pre xen (Latest ChangeSet:

The kernel version is the HVM guest one or the host one, because ...

> Tue Dec 06 10:53:12 2011 +0000 23199:d9f8316a8291), these crashes
> occur after about a day or so of running a HVM:
> =================8<=================
> (XEN) realmode.c:115:d9 Failed to emulate insn.
> (XEN) realmode.c:165:d9 Real-mode emulation failed @ e40a:00005f6c: d9
> 33 01 fc 30 34

... if this is Linux I'm having a rather hard time seeing why it would
enter realmode at normal run time (and then even use floating point
instructions there). This would be expected at boot time and at most
during guest-internal suspend/resume, but I'm sure you would have
mentioned if the guest was in the process of doing the latter (and
you excluded the former).

I'm rather suspecting the VM to have gone astray earlier.

> (XEN) domain_crash called from realmode.c:166
> (XEN) Domain 9 (vcpu#0) crashed on cpu#6:
> (XEN) ----[ Xen-4.1.3-rc1-pre  x86_64  debug=n  Not tainted ]----
> (XEN) CPU:    6
> (XEN) RIP:    e40a:[<0000000000005f6c>]
> (XEN) RFLAGS: 0000000000010002   CONTEXT: hvm guest
> (XEN) rax: 000000000000e7e5   rbx: 0000000000000000   rcx: 00000000000d0000
> (XEN) rdx: 00000000000001f7   rsi: 0000000000000000   rdi: 0000000000000dba
> (XEN) rbp: 0000000000000182   rsp: 0000000000000db0   r8:  0000000000000000
> (XEN) r9:  0000000000000000   r10: 0000000000000000   r11: 0000000000000000
> (XEN) r12: 0000000000000000   r13: 0000000000000000   r14: 0000000000000000
> (XEN) r15: 0000000000000000   cr0: 0000000000000010   cr4: 0000000000000000
> (XEN) cr3: 0000000000000000   cr2: 0000000000000000
> (XEN) ds: 9fc0   es: 9e00   fs: 0000   gs: 0000   ss: 9e00   cs: e40a
> =================8<=================
> (XEN) realmode.c:115:d5 Failed to emulate insn.
> (XEN) realmode.c:165:d5 Real-mode emulation failed @ c5d5:000242bc: d9
> 33 01 fc 30 34
> (XEN) domain_crash called from realmode.c:166
> (XEN) Domain 5 (vcpu#0) crashed on cpu#0:
> (XEN) ----[ Xen-4.1.3-rc1-pre  x86_64  debug=n  Not tainted ]----
> (XEN) CPU:    0
> (XEN) RIP:    c5d5:[<00000000000242bc>]
> (XEN) RFLAGS: 0000000000010013   CONTEXT: hvm guest
> (XEN) rax: 000000000000001b   rbx: 0000000000000702   rcx: 0000000000010ba7
> (XEN) rdx: 0000000000008fd5   rsi: 0000000000001333   rdi: 000000000000900e
> (XEN) rbp: 000000000000703e   rsp: 000000000000c5cf   r8:  0000000000000000
> (XEN) r9:  0000000000000000   r10: 0000000000000000   r11: 0000000000000000
> (XEN) r12: 0000000000000000   r13: 0000000000000000   r14: 0000000000000000
> (XEN) r15: 0000000000000000   cr0: 0000000000000010   cr4: 0000000000000000
> (XEN) cr3: 0000000000000000   cr2: 0000000000000000
> (XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: 0000   cs: c5d5

Further, you present two instances of a VM death, ...

> (XEN) [VT-D]iommu.c:856: iommu_fault_status: Primary Pending Fault
> (XEN) [VT-D]iommu.c:831: DMAR:[DMA Write] Request device [0d:00.1]
> fault addr d8964f44000, iommu reg = ffff82c3fff57000
> (XEN) DMAR:[fault reason 05h] PTE Write access is not set
> (XEN) print_vtd_entries: iommu = ffff83045ce565c0 bdf = d:0.1 gmfn = 
> d8964f44
> (XEN)     root_entry = ffff8304519d1000
> (XEN)     root_entry[d] = 4127af001
> (XEN)     context = ffff8304127af000
> (XEN)     context[1] = 2_414aca001
> (XEN)     l4 = ffff830414aca000
> (XEN)     l4_index = 1b
> (XEN)     l4[1b] = 0
> (XEN)     l4[1b] not present

... but only one instance of an IOMMU fault. Hence it's not even clear
they are connected. It also can't be the result of an immediate guest
restart, as the second VM that's dying has a lower numbered domain
ID than the first one.

Further, the IOMMU fault is not about the lack of write access, but the
requested mapping simply is not present at all. Which is because the gmfn
looks rather bogus - I doubt you're running a guest with nearly 14Tb
of memory (Xen doesn't even support that much) or with an extremely
spares physical address space (you would have to have arranged this
yourself, no VMs get created this way afaik).

Please provide consistent and complete information.

Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 09:58:55 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 09:58:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ralbl-0007f9-Oh; Wed, 14 Dec 2011 09:58:41 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Ralbk-0007f4-I6
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 09:58:40 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1323856664!7196605!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19307 invoked from network); 14 Dec 2011 09:57:45 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-10.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Dec 2011 09:57:45 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 14 Dec 2011 09:57:44 +0000
Message-Id: <4EE881270200007800067A65@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 14 Dec 2011 09:57:43 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Liwei" <xieliwei@gmail.com>
References: <CAPE0SYwsqRKDuPTz66r0nTVPYcsFx0Dk2j0pWpCiHELuU5W2iA@mail.gmail.com>
In-Reply-To: <CAPE0SYwsqRKDuPTz66r0nTVPYcsFx0Dk2j0pWpCiHELuU5W2iA@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] PTE Write access is not set
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 14.12.11 at 09:05, Liwei <xieliwei@gmail.com> wrote:
>     Using the 3.1.5 kernel and 4.1.3-rc1-pre xen (Latest ChangeSet:

The kernel version is the HVM guest one or the host one, because ...

> Tue Dec 06 10:53:12 2011 +0000 23199:d9f8316a8291), these crashes
> occur after about a day or so of running a HVM:
> =================8<=================
> (XEN) realmode.c:115:d9 Failed to emulate insn.
> (XEN) realmode.c:165:d9 Real-mode emulation failed @ e40a:00005f6c: d9
> 33 01 fc 30 34

... if this is Linux I'm having a rather hard time seeing why it would
enter realmode at normal run time (and then even use floating point
instructions there). This would be expected at boot time and at most
during guest-internal suspend/resume, but I'm sure you would have
mentioned if the guest was in the process of doing the latter (and
you excluded the former).

I'm rather suspecting the VM to have gone astray earlier.

> (XEN) domain_crash called from realmode.c:166
> (XEN) Domain 9 (vcpu#0) crashed on cpu#6:
> (XEN) ----[ Xen-4.1.3-rc1-pre  x86_64  debug=n  Not tainted ]----
> (XEN) CPU:    6
> (XEN) RIP:    e40a:[<0000000000005f6c>]
> (XEN) RFLAGS: 0000000000010002   CONTEXT: hvm guest
> (XEN) rax: 000000000000e7e5   rbx: 0000000000000000   rcx: 00000000000d0000
> (XEN) rdx: 00000000000001f7   rsi: 0000000000000000   rdi: 0000000000000dba
> (XEN) rbp: 0000000000000182   rsp: 0000000000000db0   r8:  0000000000000000
> (XEN) r9:  0000000000000000   r10: 0000000000000000   r11: 0000000000000000
> (XEN) r12: 0000000000000000   r13: 0000000000000000   r14: 0000000000000000
> (XEN) r15: 0000000000000000   cr0: 0000000000000010   cr4: 0000000000000000
> (XEN) cr3: 0000000000000000   cr2: 0000000000000000
> (XEN) ds: 9fc0   es: 9e00   fs: 0000   gs: 0000   ss: 9e00   cs: e40a
> =================8<=================
> (XEN) realmode.c:115:d5 Failed to emulate insn.
> (XEN) realmode.c:165:d5 Real-mode emulation failed @ c5d5:000242bc: d9
> 33 01 fc 30 34
> (XEN) domain_crash called from realmode.c:166
> (XEN) Domain 5 (vcpu#0) crashed on cpu#0:
> (XEN) ----[ Xen-4.1.3-rc1-pre  x86_64  debug=n  Not tainted ]----
> (XEN) CPU:    0
> (XEN) RIP:    c5d5:[<00000000000242bc>]
> (XEN) RFLAGS: 0000000000010013   CONTEXT: hvm guest
> (XEN) rax: 000000000000001b   rbx: 0000000000000702   rcx: 0000000000010ba7
> (XEN) rdx: 0000000000008fd5   rsi: 0000000000001333   rdi: 000000000000900e
> (XEN) rbp: 000000000000703e   rsp: 000000000000c5cf   r8:  0000000000000000
> (XEN) r9:  0000000000000000   r10: 0000000000000000   r11: 0000000000000000
> (XEN) r12: 0000000000000000   r13: 0000000000000000   r14: 0000000000000000
> (XEN) r15: 0000000000000000   cr0: 0000000000000010   cr4: 0000000000000000
> (XEN) cr3: 0000000000000000   cr2: 0000000000000000
> (XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: 0000   cs: c5d5

Further, you present two instances of a VM death, ...

> (XEN) [VT-D]iommu.c:856: iommu_fault_status: Primary Pending Fault
> (XEN) [VT-D]iommu.c:831: DMAR:[DMA Write] Request device [0d:00.1]
> fault addr d8964f44000, iommu reg = ffff82c3fff57000
> (XEN) DMAR:[fault reason 05h] PTE Write access is not set
> (XEN) print_vtd_entries: iommu = ffff83045ce565c0 bdf = d:0.1 gmfn = 
> d8964f44
> (XEN)     root_entry = ffff8304519d1000
> (XEN)     root_entry[d] = 4127af001
> (XEN)     context = ffff8304127af000
> (XEN)     context[1] = 2_414aca001
> (XEN)     l4 = ffff830414aca000
> (XEN)     l4_index = 1b
> (XEN)     l4[1b] = 0
> (XEN)     l4[1b] not present

... but only one instance of an IOMMU fault. Hence it's not even clear
they are connected. It also can't be the result of an immediate guest
restart, as the second VM that's dying has a lower numbered domain
ID than the first one.

Further, the IOMMU fault is not about the lack of write access, but the
requested mapping simply is not present at all. Which is because the gmfn
looks rather bogus - I doubt you're running a guest with nearly 14Tb
of memory (Xen doesn't even support that much) or with an extremely
spares physical address space (you would have to have arranged this
yourself, no VMs get created this way afaik).

Please provide consistent and complete information.

Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 10:02:25 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 10:02:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RalfA-0007xY-Cu; Wed, 14 Dec 2011 10:02:12 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Ralf9-0007xR-0s
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 10:02:11 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1323856875!7199729!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTc4Ng==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17244 invoked from network); 14 Dec 2011 10:01:16 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Dec 2011 10:01:16 -0000
X-IronPort-AV: E=Sophos;i="4.71,351,1320624000"; 
   d="scan'208";a="9457102"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Dec 2011 10:01:15 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 14 Dec 2011 10:01:15 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Keir Fraser <keir@xen.org>
Date: Wed, 14 Dec 2011 10:01:15 +0000
In-Reply-To: <CB0E1FC7.35E37%keir@xen.org>
References: <CB0E1FC7.35E37%keir@xen.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323856875.20077.374.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Liwei <xieliwei@gmail.com>, xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] PTE Write access is not set
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2011-12-14 at 09:41 +0000, Keir Fraser wrote:
> On 14/12/2011 09:36, "Ian Campbell" <Ian.Campbell@citrix.com> wrote:
> 
> > On Wed, 2011-12-14 at 08:05 +0000, Liwei wrote:
> >> Hello list,
> >>     Using the 3.1.5 kernel and 4.1.3-rc1-pre xen (Latest ChangeSet:
> >> Tue Dec 06 10:53:12 2011 +0000 23199:d9f8316a8291), these crashes
> >> occur after about a day or so of running a HVM:
> >> =================8<=================
> >> (XEN) realmode.c:115:d9 Failed to emulate insn.
> >> (XEN) realmode.c:165:d9 Real-mode emulation failed @ e40a:00005f6c: d9
> >> 33 01 fc 30 34
> > 
> > I think this is FNSTENV/FSTENV which doesn't seem to be emulated by
> > Xen :-( xen/arch/x86/x86_emulate/x86_emulate.c has:
> >                  /* case 6: fstenv - TODO */
> 
> I wonder why a long-running HVM guest would be in real mode executing FP
> code. That seems a bit fishy.

I assumed it was some driver calling into a BIOS ROM or something
horrific like that. 

RFLAGS was 0x0000000000010002 (RF and the MB1 bit), no VM86 etc in
there.

CS is e40a -- Is that ring 2? surely not... I don't see anything in
Linux which uses that segment (it's not an easy grep though).

So, yes, fishy.

Ian.

> 
>  -- Keir
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 10:02:25 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 10:02:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RalfA-0007xY-Cu; Wed, 14 Dec 2011 10:02:12 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Ralf9-0007xR-0s
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 10:02:11 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1323856875!7199729!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTc4Ng==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17244 invoked from network); 14 Dec 2011 10:01:16 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Dec 2011 10:01:16 -0000
X-IronPort-AV: E=Sophos;i="4.71,351,1320624000"; 
   d="scan'208";a="9457102"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Dec 2011 10:01:15 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 14 Dec 2011 10:01:15 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Keir Fraser <keir@xen.org>
Date: Wed, 14 Dec 2011 10:01:15 +0000
In-Reply-To: <CB0E1FC7.35E37%keir@xen.org>
References: <CB0E1FC7.35E37%keir@xen.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323856875.20077.374.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Liwei <xieliwei@gmail.com>, xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] PTE Write access is not set
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2011-12-14 at 09:41 +0000, Keir Fraser wrote:
> On 14/12/2011 09:36, "Ian Campbell" <Ian.Campbell@citrix.com> wrote:
> 
> > On Wed, 2011-12-14 at 08:05 +0000, Liwei wrote:
> >> Hello list,
> >>     Using the 3.1.5 kernel and 4.1.3-rc1-pre xen (Latest ChangeSet:
> >> Tue Dec 06 10:53:12 2011 +0000 23199:d9f8316a8291), these crashes
> >> occur after about a day or so of running a HVM:
> >> =================8<=================
> >> (XEN) realmode.c:115:d9 Failed to emulate insn.
> >> (XEN) realmode.c:165:d9 Real-mode emulation failed @ e40a:00005f6c: d9
> >> 33 01 fc 30 34
> > 
> > I think this is FNSTENV/FSTENV which doesn't seem to be emulated by
> > Xen :-( xen/arch/x86/x86_emulate/x86_emulate.c has:
> >                  /* case 6: fstenv - TODO */
> 
> I wonder why a long-running HVM guest would be in real mode executing FP
> code. That seems a bit fishy.

I assumed it was some driver calling into a BIOS ROM or something
horrific like that. 

RFLAGS was 0x0000000000010002 (RF and the MB1 bit), no VM86 etc in
there.

CS is e40a -- Is that ring 2? surely not... I don't see anything in
Linux which uses that segment (it's not an easy grep though).

So, yes, fishy.

Ian.

> 
>  -- Keir
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 10:13:14 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 10:13:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RalpT-0008D0-SO; Wed, 14 Dec 2011 10:12:51 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RalpR-0008Ct-C3
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 10:12:49 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1323857513!7418379!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTc4Ng==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9997 invoked from network); 14 Dec 2011 10:11:54 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Dec 2011 10:11:54 -0000
X-IronPort-AV: E=Sophos;i="4.71,351,1320624000"; 
   d="scan'208";a="9457500"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Dec 2011 10:11:53 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 14 Dec 2011 10:11:53 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Paul Durrant <paul.durrant@citrix.com>
Date: Wed, 14 Dec 2011 10:11:52 +0000
In-Reply-To: <fded65be5d82461e87de.1323855071@cosworth.uk.xensource.com>
References: <patchbomb.1323855070@cosworth.uk.xensource.com>
	<fded65be5d82461e87de.1323855071@cosworth.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323857513.20077.380.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 1 of 2] Re-name xenstore key used to save VM
 generation ID buffer address
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2011-12-14 at 09:31 +0000, Paul Durrant wrote:
> # HG changeset patch
> # User Paul Durrant <paul.durrant@citrix.com>
> # Date 1323854952 0
> # Node ID fded65be5d82461e87de54960db14ce8feb4625f
> # Parent  03138a08366b895d79e143119d4c9c72833cdbcd
> Re-name xenstore key used to save VM generation ID buffer address.
> 
> Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
> 
> diff -r 03138a08366b -r fded65be5d82 tools/firmware/hvmloader/acpi/build.c
> --- a/tools/firmware/hvmloader/acpi/build.c	Fri Dec 09 16:19:36 2011 +0000
> +++ b/tools/firmware/hvmloader/acpi/build.c	Wed Dec 14 09:29:12 2011 +0000
> @@ -309,7 +309,7 @@ unsigned long new_vm_gid(void)
>      if ( snprintf(addr, sizeof(addr), "0x%lx", virt_to_phys(buf))
>           >= sizeof(addr) )
>          return 0;
> -    xenstore_write("data/generation-id", addr);
> +    xenstore_write("data/generation-id-address", addr);

data/ seems like an odd home for this, isn't that the area where guests
can expect to store their own bits and bobs, agent stuff etc?

Although this key is going to be guest writeable (so hvmloader can write
it) it really ought to be off somewhere out of the way. We select the
bios with /local/domain/<domid>/hvmloader/bios so perhaps something
under there or /local/domain/<domid>/platform?

(/me adds "do archaeology and document valid/best-practice xenstore
paths to TODO list)

Ian.

>  
>      gid = strtoll(xenstore_read("platform/generation-id", "0"), NULL, 0);
>      *(uint64_t *)buf = gid;
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 10:13:14 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 10:13:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RalpT-0008D0-SO; Wed, 14 Dec 2011 10:12:51 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RalpR-0008Ct-C3
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 10:12:49 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1323857513!7418379!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTc4Ng==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9997 invoked from network); 14 Dec 2011 10:11:54 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Dec 2011 10:11:54 -0000
X-IronPort-AV: E=Sophos;i="4.71,351,1320624000"; 
   d="scan'208";a="9457500"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Dec 2011 10:11:53 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 14 Dec 2011 10:11:53 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Paul Durrant <paul.durrant@citrix.com>
Date: Wed, 14 Dec 2011 10:11:52 +0000
In-Reply-To: <fded65be5d82461e87de.1323855071@cosworth.uk.xensource.com>
References: <patchbomb.1323855070@cosworth.uk.xensource.com>
	<fded65be5d82461e87de.1323855071@cosworth.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323857513.20077.380.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 1 of 2] Re-name xenstore key used to save VM
 generation ID buffer address
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2011-12-14 at 09:31 +0000, Paul Durrant wrote:
> # HG changeset patch
> # User Paul Durrant <paul.durrant@citrix.com>
> # Date 1323854952 0
> # Node ID fded65be5d82461e87de54960db14ce8feb4625f
> # Parent  03138a08366b895d79e143119d4c9c72833cdbcd
> Re-name xenstore key used to save VM generation ID buffer address.
> 
> Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
> 
> diff -r 03138a08366b -r fded65be5d82 tools/firmware/hvmloader/acpi/build.c
> --- a/tools/firmware/hvmloader/acpi/build.c	Fri Dec 09 16:19:36 2011 +0000
> +++ b/tools/firmware/hvmloader/acpi/build.c	Wed Dec 14 09:29:12 2011 +0000
> @@ -309,7 +309,7 @@ unsigned long new_vm_gid(void)
>      if ( snprintf(addr, sizeof(addr), "0x%lx", virt_to_phys(buf))
>           >= sizeof(addr) )
>          return 0;
> -    xenstore_write("data/generation-id", addr);
> +    xenstore_write("data/generation-id-address", addr);

data/ seems like an odd home for this, isn't that the area where guests
can expect to store their own bits and bobs, agent stuff etc?

Although this key is going to be guest writeable (so hvmloader can write
it) it really ought to be off somewhere out of the way. We select the
bios with /local/domain/<domid>/hvmloader/bios so perhaps something
under there or /local/domain/<domid>/platform?

(/me adds "do archaeology and document valid/best-practice xenstore
paths to TODO list)

Ian.

>  
>      gid = strtoll(xenstore_read("platform/generation-id", "0"), NULL, 0);
>      *(uint64_t *)buf = gid;
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 10:16:11 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 10:16:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RalsQ-0008MC-2C; Wed, 14 Dec 2011 10:15:54 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RalsO-0008Lv-N0
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 10:15:52 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1323857695!5312986!1
X-Originating-IP: [209.85.210.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10166 invoked from network); 14 Dec 2011 10:14:57 -0000
Received: from mail-pz0-f43.google.com (HELO mail-pz0-f43.google.com)
	(209.85.210.43)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Dec 2011 10:14:57 -0000
Received: by daec6 with SMTP id c6so2377450dae.30
	for <xen-devel@lists.xensource.com>;
	Wed, 14 Dec 2011 02:14:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=fRWTOgXXZc3XAjCSzzkl6jNOtSuCH7Y8gRSjwpPEgow=;
	b=kCQ5cCpwoer+Pq/XX3W1l7jyUxHEU3d6BRXSicDZbRhaF/kbhdcdY59CYU3nvqlMsU
	EdmVod8ULXSgK2wcR5XGvViTpa+YEXKMPy8NTk4eZc+b4cK8U4f7leAUOnzd2aqdcdLG
	A1sQE3a94+Nl06ybGKKrg+rKszPtLazi80K+c=
MIME-Version: 1.0
Received: by 10.68.74.164 with SMTP id u4mr2682317pbv.30.1323857695287; Wed,
	14 Dec 2011 02:14:55 -0800 (PST)
Received: by 10.142.47.17 with HTTP; Wed, 14 Dec 2011 02:14:55 -0800 (PST)
In-Reply-To: <20199.26338.308105.913566@mariner.uk.xensource.com>
References: <7697ee23b08b8eaca9ae.1323768649@loki.upc.es>
	<1323770544.20077.268.camel@zakaz.uk.xensource.com>
	<4EE72B7C.7030006@redhat.com>
	<CAPLaKK5+Cup9w5HJKhMmu7RQG=EDp_FL8kjHQuaUW9PX373R=A@mail.gmail.com>
	<20199.26338.308105.913566@mariner.uk.xensource.com>
Date: Wed, 14 Dec 2011 11:14:55 +0100
X-Google-Sender-Auth: 6HMY9vJ1MRmGAEnvMWkZXXpMDWQ
Message-ID: <CAPLaKK7JXCsmcxQU0-27_-N7coPFM+wpB9Y-JDCziB8OG7=Dhw@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Laszlo Ersek <lersek@redhat.com>, Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH] xenpaging: remove XOPEN_SOURCE
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

MjAxMS8xMi8xMyBJYW4gSmFja3NvbiA8SWFuLkphY2tzb25AZXUuY2l0cml4LmNvbT46Cj4gSSBk
aXNhZ3JlZS4gwqBUaGUgcHVycG9zZSBvZiB0aGVzZSBraW5kIG9mIG1hY3JvcyBpcyBwdXJlbHkg
dG8gYWxsb3cKPiBzeXN0ZW1zIHRvIGNsYWltIHN0YW5kYXJkcy1jb21wbGlhbmNlIGFuZCBhYnNl
bmNlIG9mIG5hbWVzcGFjZQo+IHBvbGx1dGlvbiwgYnkgZGVmYXVsdC4KPgo+IFRoZSBsb2dpY2Fs
IGNvbmNsdXNpb24gaXMgdGhhdCB0aGVzZSBraW5kIG9mIHByb2JsZW1zIHNob3VsZCBiZSBmaXhl
ZAo+IGJ5IGFkZGluZyBtb3JlIHJlcXVlc3RzIGZvciBwbGF0Zm9ybS1zcGVjaWZpYyBmZWF0dXJl
cywgbm90IHJlbW92aW5nCj4gdGhlbS4KPgo+IEluIHRoaXMgY2FzZSB0aGF0IHdvdWxkIG1lYW4g
YWRkaW5nOgo+IMKgI2RlZmluZSBfTkVUQlNEX1NPVVJDRQo+Cj4gSWYgdGhlIHByZXZhbGFuY2Ug
b2YgdGhlc2Uga2luZCBvZiBtYWNyb3MgaXMgZ2V0dGluZyBpcnJpdGF0aW5nIHRoZXkKPiBjYW4g
ZWFzaWx5IGJlIG1vdmVkIGludG8gYSBjb21tb24gaGVhZGVyIGZpbGUgc29tZXdoZXJlLgoKT2ss
IEkgd2lsbCByZXNlbmQgdGhlIHBhdGNoIGFkZGluZyBfTkVUQlNEX1NPVVJDRSBpbnN0ZWFkIG9m
IHJlbW92aW5nCl9YT1BFTl9TT1VSQ0UuCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54
ZW5zb3VyY2UuY29tCmh0dHA6Ly9saXN0cy54ZW5zb3VyY2UuY29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Wed Dec 14 10:16:11 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 10:16:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RalsQ-0008MC-2C; Wed, 14 Dec 2011 10:15:54 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RalsO-0008Lv-N0
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 10:15:52 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1323857695!5312986!1
X-Originating-IP: [209.85.210.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10166 invoked from network); 14 Dec 2011 10:14:57 -0000
Received: from mail-pz0-f43.google.com (HELO mail-pz0-f43.google.com)
	(209.85.210.43)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Dec 2011 10:14:57 -0000
Received: by daec6 with SMTP id c6so2377450dae.30
	for <xen-devel@lists.xensource.com>;
	Wed, 14 Dec 2011 02:14:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=fRWTOgXXZc3XAjCSzzkl6jNOtSuCH7Y8gRSjwpPEgow=;
	b=kCQ5cCpwoer+Pq/XX3W1l7jyUxHEU3d6BRXSicDZbRhaF/kbhdcdY59CYU3nvqlMsU
	EdmVod8ULXSgK2wcR5XGvViTpa+YEXKMPy8NTk4eZc+b4cK8U4f7leAUOnzd2aqdcdLG
	A1sQE3a94+Nl06ybGKKrg+rKszPtLazi80K+c=
MIME-Version: 1.0
Received: by 10.68.74.164 with SMTP id u4mr2682317pbv.30.1323857695287; Wed,
	14 Dec 2011 02:14:55 -0800 (PST)
Received: by 10.142.47.17 with HTTP; Wed, 14 Dec 2011 02:14:55 -0800 (PST)
In-Reply-To: <20199.26338.308105.913566@mariner.uk.xensource.com>
References: <7697ee23b08b8eaca9ae.1323768649@loki.upc.es>
	<1323770544.20077.268.camel@zakaz.uk.xensource.com>
	<4EE72B7C.7030006@redhat.com>
	<CAPLaKK5+Cup9w5HJKhMmu7RQG=EDp_FL8kjHQuaUW9PX373R=A@mail.gmail.com>
	<20199.26338.308105.913566@mariner.uk.xensource.com>
Date: Wed, 14 Dec 2011 11:14:55 +0100
X-Google-Sender-Auth: 6HMY9vJ1MRmGAEnvMWkZXXpMDWQ
Message-ID: <CAPLaKK7JXCsmcxQU0-27_-N7coPFM+wpB9Y-JDCziB8OG7=Dhw@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Laszlo Ersek <lersek@redhat.com>, Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH] xenpaging: remove XOPEN_SOURCE
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

MjAxMS8xMi8xMyBJYW4gSmFja3NvbiA8SWFuLkphY2tzb25AZXUuY2l0cml4LmNvbT46Cj4gSSBk
aXNhZ3JlZS4gwqBUaGUgcHVycG9zZSBvZiB0aGVzZSBraW5kIG9mIG1hY3JvcyBpcyBwdXJlbHkg
dG8gYWxsb3cKPiBzeXN0ZW1zIHRvIGNsYWltIHN0YW5kYXJkcy1jb21wbGlhbmNlIGFuZCBhYnNl
bmNlIG9mIG5hbWVzcGFjZQo+IHBvbGx1dGlvbiwgYnkgZGVmYXVsdC4KPgo+IFRoZSBsb2dpY2Fs
IGNvbmNsdXNpb24gaXMgdGhhdCB0aGVzZSBraW5kIG9mIHByb2JsZW1zIHNob3VsZCBiZSBmaXhl
ZAo+IGJ5IGFkZGluZyBtb3JlIHJlcXVlc3RzIGZvciBwbGF0Zm9ybS1zcGVjaWZpYyBmZWF0dXJl
cywgbm90IHJlbW92aW5nCj4gdGhlbS4KPgo+IEluIHRoaXMgY2FzZSB0aGF0IHdvdWxkIG1lYW4g
YWRkaW5nOgo+IMKgI2RlZmluZSBfTkVUQlNEX1NPVVJDRQo+Cj4gSWYgdGhlIHByZXZhbGFuY2Ug
b2YgdGhlc2Uga2luZCBvZiBtYWNyb3MgaXMgZ2V0dGluZyBpcnJpdGF0aW5nIHRoZXkKPiBjYW4g
ZWFzaWx5IGJlIG1vdmVkIGludG8gYSBjb21tb24gaGVhZGVyIGZpbGUgc29tZXdoZXJlLgoKT2ss
IEkgd2lsbCByZXNlbmQgdGhlIHBhdGNoIGFkZGluZyBfTkVUQlNEX1NPVVJDRSBpbnN0ZWFkIG9m
IHJlbW92aW5nCl9YT1BFTl9TT1VSQ0UuCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54
ZW5zb3VyY2UuY29tCmh0dHA6Ly9saXN0cy54ZW5zb3VyY2UuY29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Wed Dec 14 10:18:35 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 10: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.xensource.com>)
	id 1Ralul-0008VT-O4; Wed, 14 Dec 2011 10:18:19 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Christoph.Egger@amd.com>) id 1Raluk-0008VB-LT
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 10:18:18 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1323857841!7416834!1
X-Originating-IP: [216.32.180.11]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32069 invoked from network); 14 Dec 2011 10:17:22 -0000
Received: from va3ehsobe001.messaging.microsoft.com (HELO
	VA3EHSOBE008.bigfish.com) (216.32.180.11)
	by server-9.tower-216.messagelabs.com with AES128-SHA encrypted SMTP;
	14 Dec 2011 10:17:22 -0000
Received: from mail79-va3-R.bigfish.com (10.7.14.238) by
	VA3EHSOBE008.bigfish.com (10.7.40.28) with Microsoft SMTP Server id
	14.1.225.23; Wed, 14 Dec 2011 10:17:24 +0000
Received: from mail79-va3 (localhost [127.0.0.1])	by mail79-va3-R.bigfish.com
	(Postfix) with ESMTP id 22FE64C0193;
	Wed, 14 Dec 2011 10:17:24 +0000 (UTC)
X-SpamScore: -10
X-BigFish: VPS-10(zzbb2dIc85dh1432N98dKzz1202hzz8275bhz2dh668h839h34h61h)
X-Spam-TCS-SCL: 0:0
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
Received: from mail79-va3 (localhost.localdomain [127.0.0.1]) by mail79-va3
	(MessageSwitch) id 1323857843700669_3067;
	Wed, 14 Dec 2011 10:17:23 +0000 (UTC)
Received: from VA3EHSMHS019.bigfish.com (unknown [10.7.14.240])	by
	mail79-va3.bigfish.com (Postfix) with ESMTP id 9F240640052;
	Wed, 14 Dec 2011 10:17:23 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	VA3EHSMHS019.bigfish.com (10.7.99.29) with Microsoft SMTP Server id
	14.1.225.22; Wed, 14 Dec 2011 10:17:20 +0000
X-WSS-ID: 0LW6V8R-02-0FN-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp02.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 20328C8081;	Wed, 14 Dec 2011 04:17:15 -0600 (CST)
Received: from sausexhtp02.amd.com (163.181.3.152) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Wed, 14 Dec 2011 04:17:27 -0600
Received: from storexhtp01.amd.com (172.24.4.3) by sausexhtp02.amd.com
	(163.181.3.152) with Microsoft SMTP Server (TLS) id 8.3.213.0;
	Wed, 14 Dec 2011 04:17:15 -0600
Received: from rhodium.osrc.amd.com (165.204.15.173) by storexhtp01.amd.com
	(172.24.4.3) with Microsoft SMTP Server id 8.3.213.0; Wed, 14 Dec 2011
	05:17:15 -0500
Message-ID: <4EE877A8.7080706@amd.com>
Date: Wed, 14 Dec 2011 11:17:12 +0100
From: Christoph Egger <Christoph.Egger@amd.com>
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:8.0) Gecko/20111114 Thunderbird/8.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <CB0BC143.35A76%keir@xen.org> <4EE75FB4.30609@amd.com>
	<4EE7776E0200007800067623@nat28.tlf.novell.com>
In-Reply-To: <4EE7776E0200007800067623@nat28.tlf.novell.com>
Content-Type: multipart/mixed; boundary="------------080508050405020500030201"
X-OriginatorOrg: amd.com
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Keir Fraser <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH] microcode fix
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--------------080508050405020500030201
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit

On 12/13/11 16:03, Jan Beulich wrote:
>>>> On 13.12.11 at 15:22, Christoph Egger<Christoph.Egger@amd.com>  wrote:
>> @@ -335,17 +352,36 @@ static int microcode_resume_match(int cp
>>
>>      if ( src != mc_amd )
>>      {
>> +        xfree(mc_amd->equiv_cpu_table);
>> +        xfree(mc_amd->mpb);
>
> mc_amd can be NULL here.
>
>>          xfree(mc_amd);
>> -        mc_amd = xmalloc_bytes(sizeof(*src) + src->equiv_cpu_table_size);
>> +
>> +        mc_amd = xmalloc_bytes(sizeof(*src));
>
> xmalloc(struct microcode_amd)
>
>> +        if ( !mc_amd )
>> +            goto err0;
>
> The error handling is broken here. You need to clear out
> uci->mc.mc_amd (i.e. move up the respective assignment).

Thanks for review.
New version attached.

Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>


-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo, Andrew Bowd
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632

--------------080508050405020500030201
Content-Type: text/plain; name="xen_microcode_fam15.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="xen_microcode_fam15.diff"
Content-Description: xen_microcode_fam15.diff

diff -r f1ab2c2138d8 xen/arch/x86/microcode_amd.c
--- a/xen/arch/x86/microcode_amd.c	Mon Dec 12 10:47:26 2011 +0100
+++ b/xen/arch/x86/microcode_amd.c	Wed Dec 14 11:16:04 2011 +0100
@@ -26,8 +26,6 @@
 #include <asm/processor.h>
 #include <asm/microcode.h>
 
-#define pr_debug(x...) ((void)0)
-
 struct equiv_cpu_entry {
     uint32_t installed_cpu;
     uint32_t fixed_errata_mask;
@@ -57,14 +55,17 @@ struct microcode_header_amd {
 #define UCODE_EQUIV_CPU_TABLE_TYPE 0x00000000
 #define UCODE_UCODE_TYPE           0x00000001
 
-#define UCODE_MAX_SIZE          (2048)
-#define MC_HEADER_SIZE          (sizeof(struct microcode_header_amd))
+struct microcode_amd {
+    void *mpb;
+    size_t mpb_size;
+    struct equiv_cpu_entry *equiv_cpu_table;
+    size_t equiv_cpu_table_size;
+};
 
-struct microcode_amd {
-    struct microcode_header_amd hdr;
-    unsigned int mpb[(UCODE_MAX_SIZE - MC_HEADER_SIZE) / 4];
-    unsigned int equiv_cpu_table_size;
-    struct equiv_cpu_entry equiv_cpu_table[];
+struct mpbhdr {
+    uint32_t type;
+    uint32_t len;
+    const uint8_t data;
 };
 
 /* serialize access to the physical write */
@@ -94,7 +95,7 @@ static int collect_cpu_info(int cpu, str
 static int microcode_fits(const struct microcode_amd *mc_amd, int cpu)
 {
     struct ucode_cpu_info *uci = &per_cpu(ucode_cpu_info, cpu);
-    const struct microcode_header_amd *mc_header = &mc_amd->hdr;
+    const struct microcode_header_amd *mc_header = mc_amd->mpb;
     const struct equiv_cpu_entry *equiv_cpu_table = mc_amd->equiv_cpu_table;
     unsigned int current_cpu_id;
     unsigned int equiv_cpu_id = 0x0;
@@ -141,16 +142,19 @@ static int apply_microcode(int cpu)
     struct ucode_cpu_info *uci = &per_cpu(ucode_cpu_info, cpu);
     uint32_t rev;
     struct microcode_amd *mc_amd = uci->mc.mc_amd;
+    struct microcode_header_amd *hdr = mc_amd->mpb;
 
     /* We should bind the task to the CPU */
     BUG_ON(raw_smp_processor_id() != cpu);
 
     if ( mc_amd == NULL )
         return -EINVAL;
+    if ( mc_amd->mpb == NULL )
+        return -EINVAL;
 
     spin_lock_irqsave(&microcode_update_lock, flags);
 
-    wrmsrl(MSR_AMD_PATCHLOADER, (unsigned long)&mc_amd->hdr.data_code);
+    wrmsrl(MSR_AMD_PATCHLOADER, (unsigned long)mc_amd->mpb);
 
     /* get patch id after patching */
     rdmsrl(MSR_AMD_PATCHLEVEL, rev);
@@ -158,57 +162,60 @@ static int apply_microcode(int cpu)
     spin_unlock_irqrestore(&microcode_update_lock, flags);
 
     /* check current patch id and patch's id for match */
-    if ( rev != mc_amd->hdr.patch_id )
+    if ( rev != hdr->patch_id )
     {
         printk(KERN_ERR "microcode: CPU%d update from revision "
                "0x%x to 0x%x failed\n", cpu,
-               mc_amd->hdr.patch_id, rev);
+               hdr->patch_id, rev);
         return -EIO;
     }
 
     printk(KERN_INFO "microcode: CPU%d updated from revision %#x to %#x\n",
-           cpu, uci->cpu_sig.rev, mc_amd->hdr.patch_id);
+           cpu, uci->cpu_sig.rev, hdr->patch_id);
 
     uci->cpu_sig.rev = rev;
 
     return 0;
 }
 
-static int get_next_ucode_from_buffer_amd(void *mc, const void *buf,
-                                         size_t size, unsigned long *offset)
+static int get_next_ucode_from_buffer_amd(struct microcode_amd *mc_amd,
+    const void *buf, size_t bufsize, unsigned long *offset)
 {
-    size_t total_size;
     const uint8_t *bufp = buf;
     unsigned long off;
+    const struct mpbhdr *mpbuf;
 
     off = *offset;
 
     /* No more data */
-    if ( off >= size )
+    if ( off >= bufsize )
         return 1;
 
-    if ( bufp[off] != UCODE_UCODE_TYPE )
+    mpbuf = (const struct mpbhdr *)&bufp[off];
+    if ( mpbuf->type != UCODE_UCODE_TYPE )
     {
         printk(KERN_ERR "microcode: error! "
                "Wrong microcode payload type field\n");
         return -EINVAL;
     }
 
-    total_size = (unsigned long) (bufp[off+4] + (bufp[off+5] << 8));
+    printk(KERN_DEBUG "microcode: size %lu, block size %u, offset %ld\n",
+           (unsigned long)bufsize, mpbuf->len, off);
 
-    printk(KERN_DEBUG "microcode: size %lu, total_size %lu, offset %ld\n",
-           (unsigned long)size, total_size, off);
-
-    if ( (off + total_size) > size )
+    if ( (off + mpbuf->len) > bufsize )
     {
         printk(KERN_ERR "microcode: error! Bad data in microcode data file\n");
         return -EINVAL;
     }
 
-    memset(mc, 0, UCODE_MAX_SIZE);
-    memcpy(mc, (const void *)(&bufp[off + 8]), total_size);
+    if (mc_amd->mpb_size < mpbuf->len) {
+        xfree(mc_amd->mpb);
+        mc_amd->mpb = xmalloc_bytes(mpbuf->len);
+        mc_amd->mpb_size = mpbuf->len;
+    }
+    memcpy(mc_amd->mpb, (const void *)&mpbuf->data, mpbuf->len);
 
-    *offset = off + total_size + 8;
+    *offset = off + mpbuf->len + 8;
 
     return 0;
 }
@@ -234,10 +241,18 @@ static int install_equiv_cpu_table(
     if ( size == 0 )
     {
         printk(KERN_ERR "microcode: error! "
-               "Wrong microcode equivalnet cpu table length\n");
+               "Wrong microcode equivalent cpu table length\n");
         return -EINVAL;
     }
 
+    mc_amd->equiv_cpu_table = xmalloc_bytes(size);
+    if ( !mc_amd->equiv_cpu_table )
+    {
+        printk(KERN_ERR "microcode: error! "
+               "Can not allocate memory for equivalent cpu table\n");
+        return -ENOMEM;
+    }
+
     memcpy(mc_amd->equiv_cpu_table, &buf_pos[3], size);
     mc_amd->equiv_cpu_table_size = size;
 
@@ -246,11 +261,11 @@ static int install_equiv_cpu_table(
     return 0;
 }
 
-static int cpu_request_microcode(int cpu, const void *buf, size_t size)
+static int cpu_request_microcode(int cpu, const void *buf, size_t bufsize)
 {
     const uint32_t *buf_pos;
     struct microcode_amd *mc_amd, *mc_old;
-    unsigned long offset = size;
+    size_t offset = bufsize;
     int error = 0;
     int ret;
     struct ucode_cpu_info *uci = &per_cpu(ucode_cpu_info, cpu);
@@ -263,11 +278,11 @@ static int cpu_request_microcode(int cpu
     if ( buf_pos[0] != UCODE_MAGIC )
     {
         printk(KERN_ERR "microcode: error! Wrong "
-               "microcode patch file magic\n");
+            "microcode patch file magic\n");
         return -EINVAL;
     }
 
-    mc_amd = xmalloc_bytes(sizeof(*mc_amd) + buf_pos[2]);
+    mc_amd = xmalloc_bytes(sizeof(*mc_amd));
     if ( !mc_amd )
     {
         printk(KERN_ERR "microcode: error! "
@@ -291,8 +306,10 @@ static int cpu_request_microcode(int cpu
      * It's possible the data file has multiple matching ucode,
      * lets keep searching till the latest version
      */
-    while ( (ret = get_next_ucode_from_buffer_amd(&mc_amd->hdr, buf, size,
-                                                  &offset)) == 0 )
+    mc_amd->mpb = NULL;
+    mc_amd->mpb_size = 0;
+    while ( (ret = get_next_ucode_from_buffer_amd(mc_amd,
+        buf, bufsize, &offset)) == 0 )
     {
         error = microcode_fits(mc_amd, cpu);
         if (error <= 0)
@@ -333,19 +350,44 @@ static int microcode_resume_match(int cp
     if ( res <= 0 )
         return res;
 
+    ASSERT(src != NULL);
     if ( src != mc_amd )
     {
-        xfree(mc_amd);
-        mc_amd = xmalloc_bytes(sizeof(*src) + src->equiv_cpu_table_size);
-        uci->mc.mc_amd = mc_amd;
+        if (mc_amd != NULL) {
+            if (mc_amd->equiv_cpu_table)
+                xfree(mc_amd->equiv_cpu_table);
+            if (mc_amd->mpb)
+                xfree(mc_amd->mpb);
+            xfree(mc_amd);
+        }
+
+        mc_amd = xmalloc(struct microcode_amd);
         if ( !mc_amd )
-            return -ENOMEM;
-        memcpy(mc_amd, src, UCODE_MAX_SIZE);
+            goto err0;
+        mc_amd->equiv_cpu_table = xmalloc_bytes(src->equiv_cpu_table_size);
+        if ( !mc_amd->equiv_cpu_table )
+            goto err1;
+        mc_amd->mpb = xmalloc_bytes(src->mpb_size);
+        if ( !mc_amd->mpb )
+            goto err2;
+
+        mc_amd->equiv_cpu_table_size = src->equiv_cpu_table_size;
+        mc_amd->mpb_size = src->mpb_size;
+        memcpy(mc_amd->mpb, src->mpb, src->mpb_size);
         memcpy(mc_amd->equiv_cpu_table, src->equiv_cpu_table,
                src->equiv_cpu_table_size);
     }
 
+    uci->mc.mc_amd = mc_amd;
     return 1;
+
+err2:
+    xfree(mc_amd->equiv_cpu_table);
+err1:
+    xfree(mc_amd);
+err0:
+    uci->mc.mc_amd = mc_amd = NULL;
+    return -ENOMEM;
 }
 
 static const struct microcode_ops microcode_amd_ops = {

--------------080508050405020500030201
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--------------080508050405020500030201--


From xen-devel-bounces@lists.xensource.com Wed Dec 14 10:18:35 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 10: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.xensource.com>)
	id 1Ralul-0008VT-O4; Wed, 14 Dec 2011 10:18:19 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Christoph.Egger@amd.com>) id 1Raluk-0008VB-LT
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 10:18:18 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1323857841!7416834!1
X-Originating-IP: [216.32.180.11]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32069 invoked from network); 14 Dec 2011 10:17:22 -0000
Received: from va3ehsobe001.messaging.microsoft.com (HELO
	VA3EHSOBE008.bigfish.com) (216.32.180.11)
	by server-9.tower-216.messagelabs.com with AES128-SHA encrypted SMTP;
	14 Dec 2011 10:17:22 -0000
Received: from mail79-va3-R.bigfish.com (10.7.14.238) by
	VA3EHSOBE008.bigfish.com (10.7.40.28) with Microsoft SMTP Server id
	14.1.225.23; Wed, 14 Dec 2011 10:17:24 +0000
Received: from mail79-va3 (localhost [127.0.0.1])	by mail79-va3-R.bigfish.com
	(Postfix) with ESMTP id 22FE64C0193;
	Wed, 14 Dec 2011 10:17:24 +0000 (UTC)
X-SpamScore: -10
X-BigFish: VPS-10(zzbb2dIc85dh1432N98dKzz1202hzz8275bhz2dh668h839h34h61h)
X-Spam-TCS-SCL: 0:0
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
Received: from mail79-va3 (localhost.localdomain [127.0.0.1]) by mail79-va3
	(MessageSwitch) id 1323857843700669_3067;
	Wed, 14 Dec 2011 10:17:23 +0000 (UTC)
Received: from VA3EHSMHS019.bigfish.com (unknown [10.7.14.240])	by
	mail79-va3.bigfish.com (Postfix) with ESMTP id 9F240640052;
	Wed, 14 Dec 2011 10:17:23 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	VA3EHSMHS019.bigfish.com (10.7.99.29) with Microsoft SMTP Server id
	14.1.225.22; Wed, 14 Dec 2011 10:17:20 +0000
X-WSS-ID: 0LW6V8R-02-0FN-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp02.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 20328C8081;	Wed, 14 Dec 2011 04:17:15 -0600 (CST)
Received: from sausexhtp02.amd.com (163.181.3.152) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Wed, 14 Dec 2011 04:17:27 -0600
Received: from storexhtp01.amd.com (172.24.4.3) by sausexhtp02.amd.com
	(163.181.3.152) with Microsoft SMTP Server (TLS) id 8.3.213.0;
	Wed, 14 Dec 2011 04:17:15 -0600
Received: from rhodium.osrc.amd.com (165.204.15.173) by storexhtp01.amd.com
	(172.24.4.3) with Microsoft SMTP Server id 8.3.213.0; Wed, 14 Dec 2011
	05:17:15 -0500
Message-ID: <4EE877A8.7080706@amd.com>
Date: Wed, 14 Dec 2011 11:17:12 +0100
From: Christoph Egger <Christoph.Egger@amd.com>
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:8.0) Gecko/20111114 Thunderbird/8.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <CB0BC143.35A76%keir@xen.org> <4EE75FB4.30609@amd.com>
	<4EE7776E0200007800067623@nat28.tlf.novell.com>
In-Reply-To: <4EE7776E0200007800067623@nat28.tlf.novell.com>
Content-Type: multipart/mixed; boundary="------------080508050405020500030201"
X-OriginatorOrg: amd.com
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Keir Fraser <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH] microcode fix
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--------------080508050405020500030201
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit

On 12/13/11 16:03, Jan Beulich wrote:
>>>> On 13.12.11 at 15:22, Christoph Egger<Christoph.Egger@amd.com>  wrote:
>> @@ -335,17 +352,36 @@ static int microcode_resume_match(int cp
>>
>>      if ( src != mc_amd )
>>      {
>> +        xfree(mc_amd->equiv_cpu_table);
>> +        xfree(mc_amd->mpb);
>
> mc_amd can be NULL here.
>
>>          xfree(mc_amd);
>> -        mc_amd = xmalloc_bytes(sizeof(*src) + src->equiv_cpu_table_size);
>> +
>> +        mc_amd = xmalloc_bytes(sizeof(*src));
>
> xmalloc(struct microcode_amd)
>
>> +        if ( !mc_amd )
>> +            goto err0;
>
> The error handling is broken here. You need to clear out
> uci->mc.mc_amd (i.e. move up the respective assignment).

Thanks for review.
New version attached.

Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>


-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo, Andrew Bowd
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632

--------------080508050405020500030201
Content-Type: text/plain; name="xen_microcode_fam15.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="xen_microcode_fam15.diff"
Content-Description: xen_microcode_fam15.diff

diff -r f1ab2c2138d8 xen/arch/x86/microcode_amd.c
--- a/xen/arch/x86/microcode_amd.c	Mon Dec 12 10:47:26 2011 +0100
+++ b/xen/arch/x86/microcode_amd.c	Wed Dec 14 11:16:04 2011 +0100
@@ -26,8 +26,6 @@
 #include <asm/processor.h>
 #include <asm/microcode.h>
 
-#define pr_debug(x...) ((void)0)
-
 struct equiv_cpu_entry {
     uint32_t installed_cpu;
     uint32_t fixed_errata_mask;
@@ -57,14 +55,17 @@ struct microcode_header_amd {
 #define UCODE_EQUIV_CPU_TABLE_TYPE 0x00000000
 #define UCODE_UCODE_TYPE           0x00000001
 
-#define UCODE_MAX_SIZE          (2048)
-#define MC_HEADER_SIZE          (sizeof(struct microcode_header_amd))
+struct microcode_amd {
+    void *mpb;
+    size_t mpb_size;
+    struct equiv_cpu_entry *equiv_cpu_table;
+    size_t equiv_cpu_table_size;
+};
 
-struct microcode_amd {
-    struct microcode_header_amd hdr;
-    unsigned int mpb[(UCODE_MAX_SIZE - MC_HEADER_SIZE) / 4];
-    unsigned int equiv_cpu_table_size;
-    struct equiv_cpu_entry equiv_cpu_table[];
+struct mpbhdr {
+    uint32_t type;
+    uint32_t len;
+    const uint8_t data;
 };
 
 /* serialize access to the physical write */
@@ -94,7 +95,7 @@ static int collect_cpu_info(int cpu, str
 static int microcode_fits(const struct microcode_amd *mc_amd, int cpu)
 {
     struct ucode_cpu_info *uci = &per_cpu(ucode_cpu_info, cpu);
-    const struct microcode_header_amd *mc_header = &mc_amd->hdr;
+    const struct microcode_header_amd *mc_header = mc_amd->mpb;
     const struct equiv_cpu_entry *equiv_cpu_table = mc_amd->equiv_cpu_table;
     unsigned int current_cpu_id;
     unsigned int equiv_cpu_id = 0x0;
@@ -141,16 +142,19 @@ static int apply_microcode(int cpu)
     struct ucode_cpu_info *uci = &per_cpu(ucode_cpu_info, cpu);
     uint32_t rev;
     struct microcode_amd *mc_amd = uci->mc.mc_amd;
+    struct microcode_header_amd *hdr = mc_amd->mpb;
 
     /* We should bind the task to the CPU */
     BUG_ON(raw_smp_processor_id() != cpu);
 
     if ( mc_amd == NULL )
         return -EINVAL;
+    if ( mc_amd->mpb == NULL )
+        return -EINVAL;
 
     spin_lock_irqsave(&microcode_update_lock, flags);
 
-    wrmsrl(MSR_AMD_PATCHLOADER, (unsigned long)&mc_amd->hdr.data_code);
+    wrmsrl(MSR_AMD_PATCHLOADER, (unsigned long)mc_amd->mpb);
 
     /* get patch id after patching */
     rdmsrl(MSR_AMD_PATCHLEVEL, rev);
@@ -158,57 +162,60 @@ static int apply_microcode(int cpu)
     spin_unlock_irqrestore(&microcode_update_lock, flags);
 
     /* check current patch id and patch's id for match */
-    if ( rev != mc_amd->hdr.patch_id )
+    if ( rev != hdr->patch_id )
     {
         printk(KERN_ERR "microcode: CPU%d update from revision "
                "0x%x to 0x%x failed\n", cpu,
-               mc_amd->hdr.patch_id, rev);
+               hdr->patch_id, rev);
         return -EIO;
     }
 
     printk(KERN_INFO "microcode: CPU%d updated from revision %#x to %#x\n",
-           cpu, uci->cpu_sig.rev, mc_amd->hdr.patch_id);
+           cpu, uci->cpu_sig.rev, hdr->patch_id);
 
     uci->cpu_sig.rev = rev;
 
     return 0;
 }
 
-static int get_next_ucode_from_buffer_amd(void *mc, const void *buf,
-                                         size_t size, unsigned long *offset)
+static int get_next_ucode_from_buffer_amd(struct microcode_amd *mc_amd,
+    const void *buf, size_t bufsize, unsigned long *offset)
 {
-    size_t total_size;
     const uint8_t *bufp = buf;
     unsigned long off;
+    const struct mpbhdr *mpbuf;
 
     off = *offset;
 
     /* No more data */
-    if ( off >= size )
+    if ( off >= bufsize )
         return 1;
 
-    if ( bufp[off] != UCODE_UCODE_TYPE )
+    mpbuf = (const struct mpbhdr *)&bufp[off];
+    if ( mpbuf->type != UCODE_UCODE_TYPE )
     {
         printk(KERN_ERR "microcode: error! "
                "Wrong microcode payload type field\n");
         return -EINVAL;
     }
 
-    total_size = (unsigned long) (bufp[off+4] + (bufp[off+5] << 8));
+    printk(KERN_DEBUG "microcode: size %lu, block size %u, offset %ld\n",
+           (unsigned long)bufsize, mpbuf->len, off);
 
-    printk(KERN_DEBUG "microcode: size %lu, total_size %lu, offset %ld\n",
-           (unsigned long)size, total_size, off);
-
-    if ( (off + total_size) > size )
+    if ( (off + mpbuf->len) > bufsize )
     {
         printk(KERN_ERR "microcode: error! Bad data in microcode data file\n");
         return -EINVAL;
     }
 
-    memset(mc, 0, UCODE_MAX_SIZE);
-    memcpy(mc, (const void *)(&bufp[off + 8]), total_size);
+    if (mc_amd->mpb_size < mpbuf->len) {
+        xfree(mc_amd->mpb);
+        mc_amd->mpb = xmalloc_bytes(mpbuf->len);
+        mc_amd->mpb_size = mpbuf->len;
+    }
+    memcpy(mc_amd->mpb, (const void *)&mpbuf->data, mpbuf->len);
 
-    *offset = off + total_size + 8;
+    *offset = off + mpbuf->len + 8;
 
     return 0;
 }
@@ -234,10 +241,18 @@ static int install_equiv_cpu_table(
     if ( size == 0 )
     {
         printk(KERN_ERR "microcode: error! "
-               "Wrong microcode equivalnet cpu table length\n");
+               "Wrong microcode equivalent cpu table length\n");
         return -EINVAL;
     }
 
+    mc_amd->equiv_cpu_table = xmalloc_bytes(size);
+    if ( !mc_amd->equiv_cpu_table )
+    {
+        printk(KERN_ERR "microcode: error! "
+               "Can not allocate memory for equivalent cpu table\n");
+        return -ENOMEM;
+    }
+
     memcpy(mc_amd->equiv_cpu_table, &buf_pos[3], size);
     mc_amd->equiv_cpu_table_size = size;
 
@@ -246,11 +261,11 @@ static int install_equiv_cpu_table(
     return 0;
 }
 
-static int cpu_request_microcode(int cpu, const void *buf, size_t size)
+static int cpu_request_microcode(int cpu, const void *buf, size_t bufsize)
 {
     const uint32_t *buf_pos;
     struct microcode_amd *mc_amd, *mc_old;
-    unsigned long offset = size;
+    size_t offset = bufsize;
     int error = 0;
     int ret;
     struct ucode_cpu_info *uci = &per_cpu(ucode_cpu_info, cpu);
@@ -263,11 +278,11 @@ static int cpu_request_microcode(int cpu
     if ( buf_pos[0] != UCODE_MAGIC )
     {
         printk(KERN_ERR "microcode: error! Wrong "
-               "microcode patch file magic\n");
+            "microcode patch file magic\n");
         return -EINVAL;
     }
 
-    mc_amd = xmalloc_bytes(sizeof(*mc_amd) + buf_pos[2]);
+    mc_amd = xmalloc_bytes(sizeof(*mc_amd));
     if ( !mc_amd )
     {
         printk(KERN_ERR "microcode: error! "
@@ -291,8 +306,10 @@ static int cpu_request_microcode(int cpu
      * It's possible the data file has multiple matching ucode,
      * lets keep searching till the latest version
      */
-    while ( (ret = get_next_ucode_from_buffer_amd(&mc_amd->hdr, buf, size,
-                                                  &offset)) == 0 )
+    mc_amd->mpb = NULL;
+    mc_amd->mpb_size = 0;
+    while ( (ret = get_next_ucode_from_buffer_amd(mc_amd,
+        buf, bufsize, &offset)) == 0 )
     {
         error = microcode_fits(mc_amd, cpu);
         if (error <= 0)
@@ -333,19 +350,44 @@ static int microcode_resume_match(int cp
     if ( res <= 0 )
         return res;
 
+    ASSERT(src != NULL);
     if ( src != mc_amd )
     {
-        xfree(mc_amd);
-        mc_amd = xmalloc_bytes(sizeof(*src) + src->equiv_cpu_table_size);
-        uci->mc.mc_amd = mc_amd;
+        if (mc_amd != NULL) {
+            if (mc_amd->equiv_cpu_table)
+                xfree(mc_amd->equiv_cpu_table);
+            if (mc_amd->mpb)
+                xfree(mc_amd->mpb);
+            xfree(mc_amd);
+        }
+
+        mc_amd = xmalloc(struct microcode_amd);
         if ( !mc_amd )
-            return -ENOMEM;
-        memcpy(mc_amd, src, UCODE_MAX_SIZE);
+            goto err0;
+        mc_amd->equiv_cpu_table = xmalloc_bytes(src->equiv_cpu_table_size);
+        if ( !mc_amd->equiv_cpu_table )
+            goto err1;
+        mc_amd->mpb = xmalloc_bytes(src->mpb_size);
+        if ( !mc_amd->mpb )
+            goto err2;
+
+        mc_amd->equiv_cpu_table_size = src->equiv_cpu_table_size;
+        mc_amd->mpb_size = src->mpb_size;
+        memcpy(mc_amd->mpb, src->mpb, src->mpb_size);
         memcpy(mc_amd->equiv_cpu_table, src->equiv_cpu_table,
                src->equiv_cpu_table_size);
     }
 
+    uci->mc.mc_amd = mc_amd;
     return 1;
+
+err2:
+    xfree(mc_amd->equiv_cpu_table);
+err1:
+    xfree(mc_amd);
+err0:
+    uci->mc.mc_amd = mc_amd = NULL;
+    return -ENOMEM;
 }
 
 static const struct microcode_ops microcode_amd_ops = {

--------------080508050405020500030201
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--------------080508050405020500030201--


From xen-devel-bounces@lists.xensource.com Wed Dec 14 10:21:57 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 10:21:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Raly1-0000Ee-D3; Wed, 14 Dec 2011 10:21:41 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1Ralxz-0000ES-85
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 10:21:39 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1323858010!52366221!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjA4OTk=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1707 invoked from network); 14 Dec 2011 10:20: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;
	14 Dec 2011 10:20:11 -0000
X-IronPort-AV: E=Sophos;i="4.71,351,1320642000"; d="scan'208";a="174082003"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Dec 2011 05:20:43 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Wed, 14 Dec 2011 05:20:43 -0500
Received: from [10.80.2.24] (elijah.uk.xensource.com [10.80.2.24])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pBEAKdie030575;
	Wed, 14 Dec 2011 02:20:40 -0800
From: George Dunlap <george.dunlap@citrix.com>
To: Dario Faggioli <raistlin@linux.it>
In-Reply-To: <1323270131.22009.18.camel@Solace>
References: <1322060131.30168.15.camel@Abyss> <1322060876.30168.18.camel@Abyss>
	<1322065473.1005.151.camel@zakaz.uk.xensource.com>
	<1323269351.22009.15.camel@Solace> <1323270131.22009.18.camel@Solace>
Date: Wed, 14 Dec 2011 10:24:59 +0000
Message-ID: <1323858299.18923.14.camel@elijah>
MIME-Version: 1.0
X-Mailer: Evolution 2.28.3 
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCHv2 1 of 1] Rework locking for sched_adjust.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Dario, this patch won't apply due to wordwrap damage.  Try using "hg
email", or sending as an attachment.

Thanks,
 -George

On Wed, 2011-12-07 at 15:02 +0000, Dario Faggioli wrote:
> The main idea is to move (as much as possible) locking logic
> from generic code to the various pluggable schedulers.
> 
> While at it, the following is also accomplished:
>  - pausing all the non-current VCPUs of a domain while changing its
>    scheduling parameters is not effective in avoiding races and it is
>    prone to deadlock, so that is removed.
>  - sedf needs a global lock for preventing races while adjusting
>    domains' scheduling parameters (as it is for credit and credit2),
>    so that is added.
> 
> Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
> 
> diff -r 38eb74c01d9d xen/common/sched_credit.c
> --- a/xen/common/sched_credit.c	Tue Dec 06 21:16:56 2011 +0000
> +++ b/xen/common/sched_credit.c	Wed Dec 07 15:45:55 2011 +0100
> @@ -161,6 +161,7 @@ struct csched_dom {
>   * System-wide private data
>   */
>  struct csched_private {
> +    /* lock for the whole pluggable scheduler, nests inside cpupool_lock */
>      spinlock_t lock;
>      struct list_head active_sdom;
>      uint32_t ncpus;
> @@ -800,6 +801,10 @@ csched_dom_cntl(
>      struct csched_private *prv = CSCHED_PRIV(ops);
>      unsigned long flags;
>  
> +    /* Protect both get and put branches with the pluggable scheduler
> +     * lock. Runq lock not needed anywhere in here. */
> +    spin_lock_irqsave(&prv->lock, flags);
> +
>      if ( op->cmd == XEN_DOMCTL_SCHEDOP_getinfo )
>      {
>          op->u.credit.weight = sdom->weight;
> @@ -809,8 +814,6 @@ csched_dom_cntl(
>      {
>          ASSERT(op->cmd == XEN_DOMCTL_SCHEDOP_putinfo);
>  
> -        spin_lock_irqsave(&prv->lock, flags);
> -
>          if ( op->u.credit.weight != 0 )
>          {
>              if ( !list_empty(&sdom->active_sdom_elem) )
> @@ -824,9 +827,10 @@ csched_dom_cntl(
>          if ( op->u.credit.cap != (uint16_t)~0U )
>              sdom->cap = op->u.credit.cap;
>  
> -        spin_unlock_irqrestore(&prv->lock, flags);
>      }
>  
> +    spin_unlock_irqrestore(&prv->lock, flags);
> +
>      return 0;
>  }
>  
> diff -r 38eb74c01d9d xen/common/sched_credit2.c
> --- a/xen/common/sched_credit2.c	Tue Dec 06 21:16:56 2011 +0000
> +++ b/xen/common/sched_credit2.c	Wed Dec 07 15:45:55 2011 +0100
> @@ -1384,6 +1384,10 @@ csched_dom_cntl(
>      struct csched_private *prv = CSCHED_PRIV(ops);
>      unsigned long flags;
>  
> +    /* Must hold csched_priv lock to read and update sdom,
> +     * runq lock to update csvcs. */
> +    spin_lock_irqsave(&prv->lock, flags);
> +
>      if ( op->cmd == XEN_DOMCTL_SCHEDOP_getinfo )
>      {
>          op->u.credit2.weight = sdom->weight;
> @@ -1397,10 +1401,6 @@ csched_dom_cntl(
>              struct list_head *iter;
>              int old_weight;
>  
> -            /* Must hold csched_priv lock to update sdom, runq lock to
> -             * update csvcs. */
> -            spin_lock_irqsave(&prv->lock, flags);
> -
>              old_weight = sdom->weight;
>  
>              sdom->weight = op->u.credit2.weight;
> @@ -1411,22 +1411,23 @@ csched_dom_cntl(
>                  struct csched_vcpu *svc = list_entry(iter, struct csched_vcpu, sdom_elem);
>  
>                  /* NB: Locking order is important here.  Because we grab this lock here, we
> -                 * must never lock csched_priv.lock if we're holding a runqueue
> -                 * lock. */
> -                vcpu_schedule_lock_irq(svc->vcpu);
> +                 * must never lock csched_priv.lock if we're holding a runqueue lock.
> +                 * Also, calling vcpu_schedule_lock() is enough, since IRQs have already
> +                 * been disabled. */
> +                vcpu_schedule_lock(svc->vcpu);
>  
>                  BUG_ON(svc->rqd != RQD(ops, svc->vcpu->processor));
>  
>                  svc->weight = sdom->weight;
>                  update_max_weight(svc->rqd, svc->weight, old_weight);
>  
> -                vcpu_schedule_unlock_irq(svc->vcpu);
> +                vcpu_schedule_unlock(svc->vcpu);
>              }
> -
> -            spin_unlock_irqrestore(&prv->lock, flags);
>          }
>      }
>  
> +    spin_unlock_irqrestore(&prv->lock, flags);
> +
>      return 0;
>  }
>  
> diff -r 38eb74c01d9d xen/common/sched_sedf.c
> --- a/xen/common/sched_sedf.c	Tue Dec 06 21:16:56 2011 +0000
> +++ b/xen/common/sched_sedf.c	Wed Dec 07 15:45:55 2011 +0100
> @@ -61,6 +61,11 @@ struct sedf_dom_info {
>      struct domain  *domain;
>  };
>  
> +struct sedf_priv_info {
> +    /* lock for the whole pluggable scheduler, nests inside cpupool_lock */
> +    spinlock_t lock;
> +};
> +
>  struct sedf_vcpu_info {
>      struct vcpu *vcpu;
>      struct list_head list;
> @@ -115,6 +120,8 @@ struct sedf_cpu_info {
>      s_time_t         current_slice_expires;
>  };
>  
> +#define SEDF_PRIV(_ops) \
> +    ((struct sedf_priv_info *)((_ops)->sched_data))
>  #define EDOM_INFO(d)   ((struct sedf_vcpu_info *)((d)->sched_priv))
>  #define CPU_INFO(cpu)  \
>      ((struct sedf_cpu_info *)per_cpu(schedule_data, cpu).sched_priv)
> @@ -772,6 +779,31 @@ static struct task_slice sedf_do_extra_s
>  }
>  
> 
> +static int sedf_init(struct scheduler *ops)
> +{
> +    struct sedf_priv_info *prv;
> +
> +    prv = xzalloc(struct sedf_priv_info);
> +    if ( prv == NULL )
> +        return -ENOMEM;
> +
> +    ops->sched_data = prv;
> +    spin_lock_init(&prv->lock);
> +
> +    return 0;
> +}
> +
> +
> +static void sedf_deinit(const struct scheduler *ops)
> +{
> +    struct sedf_priv_info *prv;
> +
> +    prv = SEDF_PRIV(ops);
> +    if ( prv != NULL )
> +        xfree(prv);
> +}
> +
> +
>  /* Main scheduling function
>     Reasons for calling this function are:
>     -timeslice for the current period used up
> @@ -1320,22 +1352,15 @@ static void sedf_dump_cpu_state(const st
>  
> 
>  /* Adjusts periods and slices of the domains accordingly to their weights. */
> -static int sedf_adjust_weights(struct cpupool *c, struct xen_domctl_scheduler_op *cmd)
> +static int sedf_adjust_weights(struct cpupool *c, int nr_cpus, int *sumw, s_time_t *sumt)
>  {
>      struct vcpu *p;
>      struct domain      *d;
> -    unsigned int        cpu, nr_cpus = cpumask_last(&cpu_online_map) + 1;
> -    int                *sumw = xzalloc_array(int, nr_cpus);
> -    s_time_t           *sumt = xzalloc_array(s_time_t, nr_cpus);
> +    unsigned int        cpu;
>  
> -    if ( !sumw || !sumt )
> -    {
> -        xfree(sumt);
> -        xfree(sumw);
> -        return -ENOMEM;
> -    }
> -
> -    /* Sum across all weights. */
> +    /* Sum across all weights. Notice that no runq locking is needed
> +     * here: the caller holds sedf_priv_info.lock and we're not changing
> +     * anything that is accessed during scheduling. */
>      rcu_read_lock(&domlist_read_lock);
>      for_each_domain_in_cpupool( d, c )
>      {
> @@ -1365,7 +1390,9 @@ static int sedf_adjust_weights(struct cp
>      }
>      rcu_read_unlock(&domlist_read_lock);
>  
> -    /* Adjust all slices (and periods) to the new weight. */
> +    /* Adjust all slices (and periods) to the new weight. Unlike above, we
> +     * need to take thr runq lock for the various VCPUs: we're modyfing
> +     * slice and period which are referenced during scheduling. */
>      rcu_read_lock(&domlist_read_lock);
>      for_each_domain_in_cpupool( d, c )
>      {
> @@ -1375,20 +1402,20 @@ static int sedf_adjust_weights(struct cp
>                  continue;
>              if ( EDOM_INFO(p)->weight )
>              {
> +                /* Interrupts already off */
> +                vcpu_schedule_lock(p);
>                  EDOM_INFO(p)->period_orig = 
>                      EDOM_INFO(p)->period  = WEIGHT_PERIOD;
>                  EDOM_INFO(p)->slice_orig  =
>                      EDOM_INFO(p)->slice   = 
>                      (EDOM_INFO(p)->weight *
>                       (WEIGHT_PERIOD - WEIGHT_SAFETY - sumt[cpu])) / sumw[cpu];
> +                vcpu_schedule_unlock(p);
>              }
>          }
>      }
>      rcu_read_unlock(&domlist_read_lock);
>  
> -    xfree(sumt);
> -    xfree(sumw);
> -
>      return 0;
>  }
>  
> @@ -1396,19 +1423,45 @@ static int sedf_adjust_weights(struct cp
>  /* set or fetch domain scheduling parameters */
>  static int sedf_adjust(const struct scheduler *ops, struct domain *p, struct xen_domctl_scheduler_op *op)
>  {
> +    struct sedf_priv_info *prv = SEDF_PRIV(ops);
> +    unsigned long flags;
> +    unsigned int nr_cpus = cpumask_last(&cpu_online_map) + 1;
> +    int *sumw = xzalloc_array(int, nr_cpus);
> +    s_time_t *sumt = xzalloc_array(s_time_t, nr_cpus);
>      struct vcpu *v;
> -    int rc;
> +    int rc = 0;
>  
>      PRINT(2,"sedf_adjust was called, domain-id %i new period %"PRIu64" "
>            "new slice %"PRIu64"\nlatency %"PRIu64" extra:%s\n",
>            p->domain_id, op->u.sedf.period, op->u.sedf.slice,
>            op->u.sedf.latency, (op->u.sedf.extratime)?"yes":"no");
>  
> +    /* Serialize against the pluggable scheduler lock to protect from
> +     * concurrent updates. We need to take the runq lock for the VCPUs
> +     * as well, since we are touching extraweight, weight, slice and
> +     * period. As in sched_credit2.c, runq locks nest inside the
> +     * pluggable scheduler lock. */
> +    spin_lock_irqsave(&prv->lock, flags);
> +
>      if ( op->cmd == XEN_DOMCTL_SCHEDOP_putinfo )
>      {
> +        /* These are used in sedf_adjust_weights() but have to be allocated in
> +         * this function, as we need to avoid nesting xmem_pool_alloc's lock
> +         * within our prv->lock. */
> +        if ( !sumw || !sumt )
> +        {
> +            /* Check for errors here, the _getinfo branch doesn't care */
> +            rc = -ENOMEM;
> +            goto out;
> +        }
> +
>          /* Check for sane parameters. */
>          if ( !op->u.sedf.period && !op->u.sedf.weight )
> -            return -EINVAL;
> +        {
> +            rc = -EINVAL;
> +            goto out;
> +        }
> +
>          if ( op->u.sedf.weight )
>          {
>              if ( (op->u.sedf.extratime & EXTRA_AWARE) &&
> @@ -1417,59 +1470,78 @@ static int sedf_adjust(const struct sche
>                  /* Weight-driven domains with extratime only. */
>                  for_each_vcpu ( p, v )
>                  {
> +                    /* (Here and everywhere in the following) IRQs are already off,
> +                     * hence vcpu_spin_lock() is the one. */
> +                    vcpu_schedule_lock(v);
>                      EDOM_INFO(v)->extraweight = op->u.sedf.weight;
>                      EDOM_INFO(v)->weight = 0;
>                      EDOM_INFO(v)->slice = 0;
>                      EDOM_INFO(v)->period = WEIGHT_PERIOD;
> +                    vcpu_schedule_unlock(v);
>                  }
>              }
>              else
>              {
>                  /* Weight-driven domains with real-time execution. */
> -                for_each_vcpu ( p, v )
> +                for_each_vcpu ( p, v ) {
> +                    vcpu_schedule_lock(v);
>                      EDOM_INFO(v)->weight = op->u.sedf.weight;
> +                    vcpu_schedule_unlock(v);
> +                }
>              }
>          }
>          else
>          {
> +            /*
> +             * Sanity checking: note that disabling extra weight requires
> +             * that we set a non-zero slice.
> +             */
> +            if ( (op->u.sedf.period > PERIOD_MAX) ||
> +                 (op->u.sedf.period < PERIOD_MIN) ||
> +                 (op->u.sedf.slice  > op->u.sedf.period) ||
> +                 (op->u.sedf.slice  < SLICE_MIN) )
> +            {
> +                rc = -EINVAL;
> +                goto out;
> +            }
> +
>              /* Time-driven domains. */
>              for_each_vcpu ( p, v )
>              {
> -                /*
> -                 * Sanity checking: note that disabling extra weight requires
> -                 * that we set a non-zero slice.
> -                 */
> -                if ( (op->u.sedf.period > PERIOD_MAX) ||
> -                     (op->u.sedf.period < PERIOD_MIN) ||
> -                     (op->u.sedf.slice  > op->u.sedf.period) ||
> -                     (op->u.sedf.slice  < SLICE_MIN) )
> -                    return -EINVAL;
> +                vcpu_schedule_lock(v);
>                  EDOM_INFO(v)->weight = 0;
>                  EDOM_INFO(v)->extraweight = 0;
>                  EDOM_INFO(v)->period_orig = 
>                      EDOM_INFO(v)->period  = op->u.sedf.period;
>                  EDOM_INFO(v)->slice_orig  = 
>                      EDOM_INFO(v)->slice   = op->u.sedf.slice;
> +                vcpu_schedule_unlock(v);
>              }
>          }
>  
> -        rc = sedf_adjust_weights(p->cpupool, op);
> +        rc = sedf_adjust_weights(p->cpupool, nr_cpus, sumw, sumt);
>          if ( rc )
> -            return rc;
> +            goto out;
>  
>          for_each_vcpu ( p, v )
>          {
> +            vcpu_schedule_lock(v);
>              EDOM_INFO(v)->status  = 
>                  (EDOM_INFO(v)->status &
>                   ~EXTRA_AWARE) | (op->u.sedf.extratime & EXTRA_AWARE);
>              EDOM_INFO(v)->latency = op->u.sedf.latency;
>              extraq_check(v);
> +            vcpu_schedule_unlock(v);
>          }
>      }
>      else if ( op->cmd == XEN_DOMCTL_SCHEDOP_getinfo )
>      {
>          if ( p->vcpu[0] == NULL )
> -            return -EINVAL;
> +        {
> +            rc = -EINVAL;
> +            goto out;
> +        }
> +
>          op->u.sedf.period    = EDOM_INFO(p->vcpu[0])->period;
>          op->u.sedf.slice     = EDOM_INFO(p->vcpu[0])->slice;
>          op->u.sedf.extratime = EDOM_INFO(p->vcpu[0])->status & EXTRA_AWARE;
> @@ -1477,14 +1549,23 @@ static int sedf_adjust(const struct sche
>          op->u.sedf.weight    = EDOM_INFO(p->vcpu[0])->weight;
>      }
>  
> -    PRINT(2,"sedf_adjust_finished\n");
> -    return 0;
> +out:
> +    spin_unlock_irqrestore(&prv->lock, flags);
> +
> +    xfree(sumt);
> +    xfree(sumw);
> +
> +    PRINT(2,"sedf_adjust_finished with return code %d\n", rc);
> +    return rc;
>  }
>  
> +static struct sedf_priv_info _sedf_priv;
> +
>  const struct scheduler sched_sedf_def = {
> -    .name     = "Simple EDF Scheduler",
> -    .opt_name = "sedf",
> -    .sched_id = XEN_SCHEDULER_SEDF,
> +    .name           = "Simple EDF Scheduler",
> +    .opt_name       = "sedf",
> +    .sched_id       = XEN_SCHEDULER_SEDF,
> +    .sched_data     = &_sedf_priv,
>      
>      .init_domain    = sedf_init_domain,
>      .destroy_domain = sedf_destroy_domain,
> @@ -1498,6 +1579,9 @@ const struct scheduler sched_sedf_def = 
>      .alloc_domdata  = sedf_alloc_domdata,
>      .free_domdata   = sedf_free_domdata,
>  
> +    .init           = sedf_init,
> +    .deinit         = sedf_deinit,
> +
>      .do_schedule    = sedf_do_schedule,
>      .pick_cpu       = sedf_pick_cpu,
>      .dump_cpu_state = sedf_dump_cpu_state,
> diff -r 38eb74c01d9d xen/common/schedule.c
> --- a/xen/common/schedule.c	Tue Dec 06 21:16:56 2011 +0000
> +++ b/xen/common/schedule.c	Wed Dec 07 15:45:55 2011 +0100
> @@ -1005,7 +1005,6 @@ int sched_id(void)
>  /* Adjust scheduling parameter for a given domain. */
>  long sched_adjust(struct domain *d, struct xen_domctl_scheduler_op *op)
>  {
> -    struct vcpu *v;
>      long ret;
>      
>      if ( (op->sched_id != DOM2OP(d)->sched_id) ||
> @@ -1013,40 +1012,11 @@ long sched_adjust(struct domain *d, stru
>            (op->cmd != XEN_DOMCTL_SCHEDOP_getinfo)) )
>          return -EINVAL;
>  
> -    /*
> -     * Most VCPUs we can simply pause. If we are adjusting this VCPU then
> -     * we acquire the local schedule_lock to guard against concurrent updates.
> -     *
> -     * We only acquire the local schedule lock after we have paused all other
> -     * VCPUs in this domain. There are two reasons for this:
> -     * 1- We don't want to hold up interrupts as pausing a VCPU can
> -     *    trigger a tlb shootdown.
> -     * 2- Pausing other VCPUs involves briefly locking the schedule
> -     *    lock of the CPU they are running on. This CPU could be the
> -     *    same as ours.
> -     */
> -
> -    for_each_vcpu ( d, v )
> -    {
> -        if ( v != current )
> -            vcpu_pause(v);
> -    }
> -
> -    if ( d == current->domain )
> -        vcpu_schedule_lock_irq(current);
> -
> +    /* NB: the pluggable scheduler code needs to take care
> +     * of locking by itself. */
>      if ( (ret = SCHED_OP(DOM2OP(d), adjust, d, op)) == 0 )
>          TRACE_1D(TRC_SCHED_ADJDOM, d->domain_id);
>  
> -    if ( d == current->domain )
> -        vcpu_schedule_unlock_irq(current);
> -
> -    for_each_vcpu ( d, v )
> -    {
> -        if ( v != current )
> -            vcpu_unpause(v);
> -    }
> -
>      return ret;
>  }
>  
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 10:21:57 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 10:21:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Raly1-0000Ee-D3; Wed, 14 Dec 2011 10:21:41 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1Ralxz-0000ES-85
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 10:21:39 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1323858010!52366221!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjA4OTk=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1707 invoked from network); 14 Dec 2011 10:20: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;
	14 Dec 2011 10:20:11 -0000
X-IronPort-AV: E=Sophos;i="4.71,351,1320642000"; d="scan'208";a="174082003"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Dec 2011 05:20:43 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Wed, 14 Dec 2011 05:20:43 -0500
Received: from [10.80.2.24] (elijah.uk.xensource.com [10.80.2.24])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pBEAKdie030575;
	Wed, 14 Dec 2011 02:20:40 -0800
From: George Dunlap <george.dunlap@citrix.com>
To: Dario Faggioli <raistlin@linux.it>
In-Reply-To: <1323270131.22009.18.camel@Solace>
References: <1322060131.30168.15.camel@Abyss> <1322060876.30168.18.camel@Abyss>
	<1322065473.1005.151.camel@zakaz.uk.xensource.com>
	<1323269351.22009.15.camel@Solace> <1323270131.22009.18.camel@Solace>
Date: Wed, 14 Dec 2011 10:24:59 +0000
Message-ID: <1323858299.18923.14.camel@elijah>
MIME-Version: 1.0
X-Mailer: Evolution 2.28.3 
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCHv2 1 of 1] Rework locking for sched_adjust.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Dario, this patch won't apply due to wordwrap damage.  Try using "hg
email", or sending as an attachment.

Thanks,
 -George

On Wed, 2011-12-07 at 15:02 +0000, Dario Faggioli wrote:
> The main idea is to move (as much as possible) locking logic
> from generic code to the various pluggable schedulers.
> 
> While at it, the following is also accomplished:
>  - pausing all the non-current VCPUs of a domain while changing its
>    scheduling parameters is not effective in avoiding races and it is
>    prone to deadlock, so that is removed.
>  - sedf needs a global lock for preventing races while adjusting
>    domains' scheduling parameters (as it is for credit and credit2),
>    so that is added.
> 
> Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
> 
> diff -r 38eb74c01d9d xen/common/sched_credit.c
> --- a/xen/common/sched_credit.c	Tue Dec 06 21:16:56 2011 +0000
> +++ b/xen/common/sched_credit.c	Wed Dec 07 15:45:55 2011 +0100
> @@ -161,6 +161,7 @@ struct csched_dom {
>   * System-wide private data
>   */
>  struct csched_private {
> +    /* lock for the whole pluggable scheduler, nests inside cpupool_lock */
>      spinlock_t lock;
>      struct list_head active_sdom;
>      uint32_t ncpus;
> @@ -800,6 +801,10 @@ csched_dom_cntl(
>      struct csched_private *prv = CSCHED_PRIV(ops);
>      unsigned long flags;
>  
> +    /* Protect both get and put branches with the pluggable scheduler
> +     * lock. Runq lock not needed anywhere in here. */
> +    spin_lock_irqsave(&prv->lock, flags);
> +
>      if ( op->cmd == XEN_DOMCTL_SCHEDOP_getinfo )
>      {
>          op->u.credit.weight = sdom->weight;
> @@ -809,8 +814,6 @@ csched_dom_cntl(
>      {
>          ASSERT(op->cmd == XEN_DOMCTL_SCHEDOP_putinfo);
>  
> -        spin_lock_irqsave(&prv->lock, flags);
> -
>          if ( op->u.credit.weight != 0 )
>          {
>              if ( !list_empty(&sdom->active_sdom_elem) )
> @@ -824,9 +827,10 @@ csched_dom_cntl(
>          if ( op->u.credit.cap != (uint16_t)~0U )
>              sdom->cap = op->u.credit.cap;
>  
> -        spin_unlock_irqrestore(&prv->lock, flags);
>      }
>  
> +    spin_unlock_irqrestore(&prv->lock, flags);
> +
>      return 0;
>  }
>  
> diff -r 38eb74c01d9d xen/common/sched_credit2.c
> --- a/xen/common/sched_credit2.c	Tue Dec 06 21:16:56 2011 +0000
> +++ b/xen/common/sched_credit2.c	Wed Dec 07 15:45:55 2011 +0100
> @@ -1384,6 +1384,10 @@ csched_dom_cntl(
>      struct csched_private *prv = CSCHED_PRIV(ops);
>      unsigned long flags;
>  
> +    /* Must hold csched_priv lock to read and update sdom,
> +     * runq lock to update csvcs. */
> +    spin_lock_irqsave(&prv->lock, flags);
> +
>      if ( op->cmd == XEN_DOMCTL_SCHEDOP_getinfo )
>      {
>          op->u.credit2.weight = sdom->weight;
> @@ -1397,10 +1401,6 @@ csched_dom_cntl(
>              struct list_head *iter;
>              int old_weight;
>  
> -            /* Must hold csched_priv lock to update sdom, runq lock to
> -             * update csvcs. */
> -            spin_lock_irqsave(&prv->lock, flags);
> -
>              old_weight = sdom->weight;
>  
>              sdom->weight = op->u.credit2.weight;
> @@ -1411,22 +1411,23 @@ csched_dom_cntl(
>                  struct csched_vcpu *svc = list_entry(iter, struct csched_vcpu, sdom_elem);
>  
>                  /* NB: Locking order is important here.  Because we grab this lock here, we
> -                 * must never lock csched_priv.lock if we're holding a runqueue
> -                 * lock. */
> -                vcpu_schedule_lock_irq(svc->vcpu);
> +                 * must never lock csched_priv.lock if we're holding a runqueue lock.
> +                 * Also, calling vcpu_schedule_lock() is enough, since IRQs have already
> +                 * been disabled. */
> +                vcpu_schedule_lock(svc->vcpu);
>  
>                  BUG_ON(svc->rqd != RQD(ops, svc->vcpu->processor));
>  
>                  svc->weight = sdom->weight;
>                  update_max_weight(svc->rqd, svc->weight, old_weight);
>  
> -                vcpu_schedule_unlock_irq(svc->vcpu);
> +                vcpu_schedule_unlock(svc->vcpu);
>              }
> -
> -            spin_unlock_irqrestore(&prv->lock, flags);
>          }
>      }
>  
> +    spin_unlock_irqrestore(&prv->lock, flags);
> +
>      return 0;
>  }
>  
> diff -r 38eb74c01d9d xen/common/sched_sedf.c
> --- a/xen/common/sched_sedf.c	Tue Dec 06 21:16:56 2011 +0000
> +++ b/xen/common/sched_sedf.c	Wed Dec 07 15:45:55 2011 +0100
> @@ -61,6 +61,11 @@ struct sedf_dom_info {
>      struct domain  *domain;
>  };
>  
> +struct sedf_priv_info {
> +    /* lock for the whole pluggable scheduler, nests inside cpupool_lock */
> +    spinlock_t lock;
> +};
> +
>  struct sedf_vcpu_info {
>      struct vcpu *vcpu;
>      struct list_head list;
> @@ -115,6 +120,8 @@ struct sedf_cpu_info {
>      s_time_t         current_slice_expires;
>  };
>  
> +#define SEDF_PRIV(_ops) \
> +    ((struct sedf_priv_info *)((_ops)->sched_data))
>  #define EDOM_INFO(d)   ((struct sedf_vcpu_info *)((d)->sched_priv))
>  #define CPU_INFO(cpu)  \
>      ((struct sedf_cpu_info *)per_cpu(schedule_data, cpu).sched_priv)
> @@ -772,6 +779,31 @@ static struct task_slice sedf_do_extra_s
>  }
>  
> 
> +static int sedf_init(struct scheduler *ops)
> +{
> +    struct sedf_priv_info *prv;
> +
> +    prv = xzalloc(struct sedf_priv_info);
> +    if ( prv == NULL )
> +        return -ENOMEM;
> +
> +    ops->sched_data = prv;
> +    spin_lock_init(&prv->lock);
> +
> +    return 0;
> +}
> +
> +
> +static void sedf_deinit(const struct scheduler *ops)
> +{
> +    struct sedf_priv_info *prv;
> +
> +    prv = SEDF_PRIV(ops);
> +    if ( prv != NULL )
> +        xfree(prv);
> +}
> +
> +
>  /* Main scheduling function
>     Reasons for calling this function are:
>     -timeslice for the current period used up
> @@ -1320,22 +1352,15 @@ static void sedf_dump_cpu_state(const st
>  
> 
>  /* Adjusts periods and slices of the domains accordingly to their weights. */
> -static int sedf_adjust_weights(struct cpupool *c, struct xen_domctl_scheduler_op *cmd)
> +static int sedf_adjust_weights(struct cpupool *c, int nr_cpus, int *sumw, s_time_t *sumt)
>  {
>      struct vcpu *p;
>      struct domain      *d;
> -    unsigned int        cpu, nr_cpus = cpumask_last(&cpu_online_map) + 1;
> -    int                *sumw = xzalloc_array(int, nr_cpus);
> -    s_time_t           *sumt = xzalloc_array(s_time_t, nr_cpus);
> +    unsigned int        cpu;
>  
> -    if ( !sumw || !sumt )
> -    {
> -        xfree(sumt);
> -        xfree(sumw);
> -        return -ENOMEM;
> -    }
> -
> -    /* Sum across all weights. */
> +    /* Sum across all weights. Notice that no runq locking is needed
> +     * here: the caller holds sedf_priv_info.lock and we're not changing
> +     * anything that is accessed during scheduling. */
>      rcu_read_lock(&domlist_read_lock);
>      for_each_domain_in_cpupool( d, c )
>      {
> @@ -1365,7 +1390,9 @@ static int sedf_adjust_weights(struct cp
>      }
>      rcu_read_unlock(&domlist_read_lock);
>  
> -    /* Adjust all slices (and periods) to the new weight. */
> +    /* Adjust all slices (and periods) to the new weight. Unlike above, we
> +     * need to take thr runq lock for the various VCPUs: we're modyfing
> +     * slice and period which are referenced during scheduling. */
>      rcu_read_lock(&domlist_read_lock);
>      for_each_domain_in_cpupool( d, c )
>      {
> @@ -1375,20 +1402,20 @@ static int sedf_adjust_weights(struct cp
>                  continue;
>              if ( EDOM_INFO(p)->weight )
>              {
> +                /* Interrupts already off */
> +                vcpu_schedule_lock(p);
>                  EDOM_INFO(p)->period_orig = 
>                      EDOM_INFO(p)->period  = WEIGHT_PERIOD;
>                  EDOM_INFO(p)->slice_orig  =
>                      EDOM_INFO(p)->slice   = 
>                      (EDOM_INFO(p)->weight *
>                       (WEIGHT_PERIOD - WEIGHT_SAFETY - sumt[cpu])) / sumw[cpu];
> +                vcpu_schedule_unlock(p);
>              }
>          }
>      }
>      rcu_read_unlock(&domlist_read_lock);
>  
> -    xfree(sumt);
> -    xfree(sumw);
> -
>      return 0;
>  }
>  
> @@ -1396,19 +1423,45 @@ static int sedf_adjust_weights(struct cp
>  /* set or fetch domain scheduling parameters */
>  static int sedf_adjust(const struct scheduler *ops, struct domain *p, struct xen_domctl_scheduler_op *op)
>  {
> +    struct sedf_priv_info *prv = SEDF_PRIV(ops);
> +    unsigned long flags;
> +    unsigned int nr_cpus = cpumask_last(&cpu_online_map) + 1;
> +    int *sumw = xzalloc_array(int, nr_cpus);
> +    s_time_t *sumt = xzalloc_array(s_time_t, nr_cpus);
>      struct vcpu *v;
> -    int rc;
> +    int rc = 0;
>  
>      PRINT(2,"sedf_adjust was called, domain-id %i new period %"PRIu64" "
>            "new slice %"PRIu64"\nlatency %"PRIu64" extra:%s\n",
>            p->domain_id, op->u.sedf.period, op->u.sedf.slice,
>            op->u.sedf.latency, (op->u.sedf.extratime)?"yes":"no");
>  
> +    /* Serialize against the pluggable scheduler lock to protect from
> +     * concurrent updates. We need to take the runq lock for the VCPUs
> +     * as well, since we are touching extraweight, weight, slice and
> +     * period. As in sched_credit2.c, runq locks nest inside the
> +     * pluggable scheduler lock. */
> +    spin_lock_irqsave(&prv->lock, flags);
> +
>      if ( op->cmd == XEN_DOMCTL_SCHEDOP_putinfo )
>      {
> +        /* These are used in sedf_adjust_weights() but have to be allocated in
> +         * this function, as we need to avoid nesting xmem_pool_alloc's lock
> +         * within our prv->lock. */
> +        if ( !sumw || !sumt )
> +        {
> +            /* Check for errors here, the _getinfo branch doesn't care */
> +            rc = -ENOMEM;
> +            goto out;
> +        }
> +
>          /* Check for sane parameters. */
>          if ( !op->u.sedf.period && !op->u.sedf.weight )
> -            return -EINVAL;
> +        {
> +            rc = -EINVAL;
> +            goto out;
> +        }
> +
>          if ( op->u.sedf.weight )
>          {
>              if ( (op->u.sedf.extratime & EXTRA_AWARE) &&
> @@ -1417,59 +1470,78 @@ static int sedf_adjust(const struct sche
>                  /* Weight-driven domains with extratime only. */
>                  for_each_vcpu ( p, v )
>                  {
> +                    /* (Here and everywhere in the following) IRQs are already off,
> +                     * hence vcpu_spin_lock() is the one. */
> +                    vcpu_schedule_lock(v);
>                      EDOM_INFO(v)->extraweight = op->u.sedf.weight;
>                      EDOM_INFO(v)->weight = 0;
>                      EDOM_INFO(v)->slice = 0;
>                      EDOM_INFO(v)->period = WEIGHT_PERIOD;
> +                    vcpu_schedule_unlock(v);
>                  }
>              }
>              else
>              {
>                  /* Weight-driven domains with real-time execution. */
> -                for_each_vcpu ( p, v )
> +                for_each_vcpu ( p, v ) {
> +                    vcpu_schedule_lock(v);
>                      EDOM_INFO(v)->weight = op->u.sedf.weight;
> +                    vcpu_schedule_unlock(v);
> +                }
>              }
>          }
>          else
>          {
> +            /*
> +             * Sanity checking: note that disabling extra weight requires
> +             * that we set a non-zero slice.
> +             */
> +            if ( (op->u.sedf.period > PERIOD_MAX) ||
> +                 (op->u.sedf.period < PERIOD_MIN) ||
> +                 (op->u.sedf.slice  > op->u.sedf.period) ||
> +                 (op->u.sedf.slice  < SLICE_MIN) )
> +            {
> +                rc = -EINVAL;
> +                goto out;
> +            }
> +
>              /* Time-driven domains. */
>              for_each_vcpu ( p, v )
>              {
> -                /*
> -                 * Sanity checking: note that disabling extra weight requires
> -                 * that we set a non-zero slice.
> -                 */
> -                if ( (op->u.sedf.period > PERIOD_MAX) ||
> -                     (op->u.sedf.period < PERIOD_MIN) ||
> -                     (op->u.sedf.slice  > op->u.sedf.period) ||
> -                     (op->u.sedf.slice  < SLICE_MIN) )
> -                    return -EINVAL;
> +                vcpu_schedule_lock(v);
>                  EDOM_INFO(v)->weight = 0;
>                  EDOM_INFO(v)->extraweight = 0;
>                  EDOM_INFO(v)->period_orig = 
>                      EDOM_INFO(v)->period  = op->u.sedf.period;
>                  EDOM_INFO(v)->slice_orig  = 
>                      EDOM_INFO(v)->slice   = op->u.sedf.slice;
> +                vcpu_schedule_unlock(v);
>              }
>          }
>  
> -        rc = sedf_adjust_weights(p->cpupool, op);
> +        rc = sedf_adjust_weights(p->cpupool, nr_cpus, sumw, sumt);
>          if ( rc )
> -            return rc;
> +            goto out;
>  
>          for_each_vcpu ( p, v )
>          {
> +            vcpu_schedule_lock(v);
>              EDOM_INFO(v)->status  = 
>                  (EDOM_INFO(v)->status &
>                   ~EXTRA_AWARE) | (op->u.sedf.extratime & EXTRA_AWARE);
>              EDOM_INFO(v)->latency = op->u.sedf.latency;
>              extraq_check(v);
> +            vcpu_schedule_unlock(v);
>          }
>      }
>      else if ( op->cmd == XEN_DOMCTL_SCHEDOP_getinfo )
>      {
>          if ( p->vcpu[0] == NULL )
> -            return -EINVAL;
> +        {
> +            rc = -EINVAL;
> +            goto out;
> +        }
> +
>          op->u.sedf.period    = EDOM_INFO(p->vcpu[0])->period;
>          op->u.sedf.slice     = EDOM_INFO(p->vcpu[0])->slice;
>          op->u.sedf.extratime = EDOM_INFO(p->vcpu[0])->status & EXTRA_AWARE;
> @@ -1477,14 +1549,23 @@ static int sedf_adjust(const struct sche
>          op->u.sedf.weight    = EDOM_INFO(p->vcpu[0])->weight;
>      }
>  
> -    PRINT(2,"sedf_adjust_finished\n");
> -    return 0;
> +out:
> +    spin_unlock_irqrestore(&prv->lock, flags);
> +
> +    xfree(sumt);
> +    xfree(sumw);
> +
> +    PRINT(2,"sedf_adjust_finished with return code %d\n", rc);
> +    return rc;
>  }
>  
> +static struct sedf_priv_info _sedf_priv;
> +
>  const struct scheduler sched_sedf_def = {
> -    .name     = "Simple EDF Scheduler",
> -    .opt_name = "sedf",
> -    .sched_id = XEN_SCHEDULER_SEDF,
> +    .name           = "Simple EDF Scheduler",
> +    .opt_name       = "sedf",
> +    .sched_id       = XEN_SCHEDULER_SEDF,
> +    .sched_data     = &_sedf_priv,
>      
>      .init_domain    = sedf_init_domain,
>      .destroy_domain = sedf_destroy_domain,
> @@ -1498,6 +1579,9 @@ const struct scheduler sched_sedf_def = 
>      .alloc_domdata  = sedf_alloc_domdata,
>      .free_domdata   = sedf_free_domdata,
>  
> +    .init           = sedf_init,
> +    .deinit         = sedf_deinit,
> +
>      .do_schedule    = sedf_do_schedule,
>      .pick_cpu       = sedf_pick_cpu,
>      .dump_cpu_state = sedf_dump_cpu_state,
> diff -r 38eb74c01d9d xen/common/schedule.c
> --- a/xen/common/schedule.c	Tue Dec 06 21:16:56 2011 +0000
> +++ b/xen/common/schedule.c	Wed Dec 07 15:45:55 2011 +0100
> @@ -1005,7 +1005,6 @@ int sched_id(void)
>  /* Adjust scheduling parameter for a given domain. */
>  long sched_adjust(struct domain *d, struct xen_domctl_scheduler_op *op)
>  {
> -    struct vcpu *v;
>      long ret;
>      
>      if ( (op->sched_id != DOM2OP(d)->sched_id) ||
> @@ -1013,40 +1012,11 @@ long sched_adjust(struct domain *d, stru
>            (op->cmd != XEN_DOMCTL_SCHEDOP_getinfo)) )
>          return -EINVAL;
>  
> -    /*
> -     * Most VCPUs we can simply pause. If we are adjusting this VCPU then
> -     * we acquire the local schedule_lock to guard against concurrent updates.
> -     *
> -     * We only acquire the local schedule lock after we have paused all other
> -     * VCPUs in this domain. There are two reasons for this:
> -     * 1- We don't want to hold up interrupts as pausing a VCPU can
> -     *    trigger a tlb shootdown.
> -     * 2- Pausing other VCPUs involves briefly locking the schedule
> -     *    lock of the CPU they are running on. This CPU could be the
> -     *    same as ours.
> -     */
> -
> -    for_each_vcpu ( d, v )
> -    {
> -        if ( v != current )
> -            vcpu_pause(v);
> -    }
> -
> -    if ( d == current->domain )
> -        vcpu_schedule_lock_irq(current);
> -
> +    /* NB: the pluggable scheduler code needs to take care
> +     * of locking by itself. */
>      if ( (ret = SCHED_OP(DOM2OP(d), adjust, d, op)) == 0 )
>          TRACE_1D(TRC_SCHED_ADJDOM, d->domain_id);
>  
> -    if ( d == current->domain )
> -        vcpu_schedule_unlock_irq(current);
> -
> -    for_each_vcpu ( d, v )
> -    {
> -        if ( v != current )
> -            vcpu_unpause(v);
> -    }
> -
>      return ret;
>  }
>  
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 10:24:44 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 10:24:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ram0l-0000OO-8Y; Wed, 14 Dec 2011 10:24:31 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1Ram0j-0000OC-OH
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 10:24:30 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-2.tower-174.messagelabs.com!1323858213!5474197!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMDc5NzQ=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMDc5NzQ=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16444 invoked from network); 14 Dec 2011 10:23:34 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-2.tower-174.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 14 Dec 2011 10:23:34 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1323858213; l=245;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Transfer-Encoding:Content-Type:MIME-Version:
	References:Subject:Cc:To:From:Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=6z8XbMBV4HyL8WCyrY8MaPGcUY4=;
	b=V+WlbHGbYLVMDbHvbenFiAL0+MLiCVtfpjRolQUOTsiwc5wD/5/r6VuSJf9yo+VEAth
	lmbghh2i3H7+BnuM+x+H2+NEJhwNv3V06eGZUWjRblE/EdQf1hegKYdA6d8+J98244TgB
	Qkdt/ULMtuHcIKxGSD50h2e3Mus0ZyZuMMY=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFPjDQQEWpphA==
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-127-223.pools.arcor-ip.net [88.65.127.223])
	by post.strato.de (mrclete mo29) (RZmta 26.15 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id u056c2nBE9Pta9 ;
	Wed, 14 Dec 2011 11:23:10 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 6475118637; Wed, 14 Dec 2011 11:23:09 +0100 (CET)
Date: Wed, 14 Dec 2011 11:23:09 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@entel.upc.edu>
Message-ID: <20111214102309.GA13038@aepfle.de>
References: <7697ee23b08b8eaca9ae.1323768649@loki.upc.es>
	<1323770544.20077.268.camel@zakaz.uk.xensource.com>
	<4EE72B7C.7030006@redhat.com>
	<CAPLaKK5+Cup9w5HJKhMmu7RQG=EDp_FL8kjHQuaUW9PX373R=A@mail.gmail.com>
	<20199.26338.308105.913566@mariner.uk.xensource.com>
	<CAPLaKK7JXCsmcxQU0-27_-N7coPFM+wpB9Y-JDCziB8OG7=Dhw@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAPLaKK7JXCsmcxQU0-27_-N7coPFM+wpB9Y-JDCziB8OG7=Dhw@mail.gmail.com>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: Laszlo Ersek <lersek@redhat.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH] xenpaging: remove XOPEN_SOURCE
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gV2VkLCBEZWMgMTQsIFJvZ2VyIFBhdSBNb25uw6kgd3JvdGU6Cgo+IE9rLCBJIHdpbGwgcmVz
ZW5kIHRoZSBwYXRjaCBhZGRpbmcgX05FVEJTRF9TT1VSQ0UgaW5zdGVhZCBvZiByZW1vdmluZwo+
IF9YT1BFTl9TT1VSQ0UuCgpIb3cgZG8gb3RoZXIgc291cmNlIGZpbGVzIHdpdGggYXNwcmludGYo
KSBjYWxscyBjb21waWxlIGZvciB5b3U/IChsaWJ4bCkKV2h5IGlzIHhlbnBhZ2luZyBzcGVjaWFs
PwoKT2xhZgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18K
WGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuc291cmNlLmNvbQpodHRw
Oi8vbGlzdHMueGVuc291cmNlLmNvbS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Wed Dec 14 10:24:44 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 10:24:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ram0l-0000OO-8Y; Wed, 14 Dec 2011 10:24:31 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1Ram0j-0000OC-OH
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 10:24:30 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-2.tower-174.messagelabs.com!1323858213!5474197!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMDc5NzQ=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMDc5NzQ=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16444 invoked from network); 14 Dec 2011 10:23:34 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-2.tower-174.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 14 Dec 2011 10:23:34 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1323858213; l=245;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Transfer-Encoding:Content-Type:MIME-Version:
	References:Subject:Cc:To:From:Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=6z8XbMBV4HyL8WCyrY8MaPGcUY4=;
	b=V+WlbHGbYLVMDbHvbenFiAL0+MLiCVtfpjRolQUOTsiwc5wD/5/r6VuSJf9yo+VEAth
	lmbghh2i3H7+BnuM+x+H2+NEJhwNv3V06eGZUWjRblE/EdQf1hegKYdA6d8+J98244TgB
	Qkdt/ULMtuHcIKxGSD50h2e3Mus0ZyZuMMY=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFPjDQQEWpphA==
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-127-223.pools.arcor-ip.net [88.65.127.223])
	by post.strato.de (mrclete mo29) (RZmta 26.15 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id u056c2nBE9Pta9 ;
	Wed, 14 Dec 2011 11:23:10 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 6475118637; Wed, 14 Dec 2011 11:23:09 +0100 (CET)
Date: Wed, 14 Dec 2011 11:23:09 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@entel.upc.edu>
Message-ID: <20111214102309.GA13038@aepfle.de>
References: <7697ee23b08b8eaca9ae.1323768649@loki.upc.es>
	<1323770544.20077.268.camel@zakaz.uk.xensource.com>
	<4EE72B7C.7030006@redhat.com>
	<CAPLaKK5+Cup9w5HJKhMmu7RQG=EDp_FL8kjHQuaUW9PX373R=A@mail.gmail.com>
	<20199.26338.308105.913566@mariner.uk.xensource.com>
	<CAPLaKK7JXCsmcxQU0-27_-N7coPFM+wpB9Y-JDCziB8OG7=Dhw@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAPLaKK7JXCsmcxQU0-27_-N7coPFM+wpB9Y-JDCziB8OG7=Dhw@mail.gmail.com>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: Laszlo Ersek <lersek@redhat.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH] xenpaging: remove XOPEN_SOURCE
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gV2VkLCBEZWMgMTQsIFJvZ2VyIFBhdSBNb25uw6kgd3JvdGU6Cgo+IE9rLCBJIHdpbGwgcmVz
ZW5kIHRoZSBwYXRjaCBhZGRpbmcgX05FVEJTRF9TT1VSQ0UgaW5zdGVhZCBvZiByZW1vdmluZwo+
IF9YT1BFTl9TT1VSQ0UuCgpIb3cgZG8gb3RoZXIgc291cmNlIGZpbGVzIHdpdGggYXNwcmludGYo
KSBjYWxscyBjb21waWxlIGZvciB5b3U/IChsaWJ4bCkKV2h5IGlzIHhlbnBhZ2luZyBzcGVjaWFs
PwoKT2xhZgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18K
WGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuc291cmNlLmNvbQpodHRw
Oi8vbGlzdHMueGVuc291cmNlLmNvbS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Wed Dec 14 10:42:35 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 10:42:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RamHq-0000lL-9P; Wed, 14 Dec 2011 10:42:10 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RamHo-0000lG-7F
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 10:42:08 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1323859272!7208708!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTc4Ng==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 875 invoked from network); 14 Dec 2011 10:41:13 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Dec 2011 10:41:13 -0000
X-IronPort-AV: E=Sophos;i="4.71,351,1320624000"; 
   d="scan'208";a="9458897"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Dec 2011 10:41:12 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 14 Dec 2011 10:41:12 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Date: Wed, 14 Dec 2011 10:41:12 +0000
In-Reply-To: <1323808737-29125-9-git-send-email-dgdegra@tycho.nsa.gov>
References: <1323808737-29125-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1323808737-29125-9-git-send-email-dgdegra@tycho.nsa.gov>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323859272.20077.388.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Keir
	\(Xen.org\)" <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH 8/8] xl.pod.1: improve documentation of
 FLASK commands
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2011-12-13 at 20:38 +0000, Daniel De Graaf wrote:
> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>

Thanks.

> +=item B<getenforce>
> +=item B<setenforce> I<1|0|Enforcing|Permissive>
> +=item B<loadpolicy> I<policy-file>

I think the intention was that commands be alphabetical within their
section, although this section is so small I'm not sure it really
matters.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 10:42:35 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 10:42:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RamHq-0000lL-9P; Wed, 14 Dec 2011 10:42:10 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RamHo-0000lG-7F
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 10:42:08 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1323859272!7208708!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTc4Ng==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 875 invoked from network); 14 Dec 2011 10:41:13 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Dec 2011 10:41:13 -0000
X-IronPort-AV: E=Sophos;i="4.71,351,1320624000"; 
   d="scan'208";a="9458897"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Dec 2011 10:41:12 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 14 Dec 2011 10:41:12 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Date: Wed, 14 Dec 2011 10:41:12 +0000
In-Reply-To: <1323808737-29125-9-git-send-email-dgdegra@tycho.nsa.gov>
References: <1323808737-29125-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1323808737-29125-9-git-send-email-dgdegra@tycho.nsa.gov>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323859272.20077.388.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Keir
	\(Xen.org\)" <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH 8/8] xl.pod.1: improve documentation of
 FLASK commands
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2011-12-13 at 20:38 +0000, Daniel De Graaf wrote:
> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>

Thanks.

> +=item B<getenforce>
> +=item B<setenforce> I<1|0|Enforcing|Permissive>
> +=item B<loadpolicy> I<policy-file>

I think the intention was that commands be alphabetical within their
section, although this section is so small I'm not sure it really
matters.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 10:48:22 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 10:48:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RamNX-0000uW-3W; Wed, 14 Dec 2011 10:48:03 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RamNV-0000uQ-Tl
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 10:48:02 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1323859625!7346669!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTc4Ng==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11091 invoked from network); 14 Dec 2011 10:47:06 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Dec 2011 10:47:06 -0000
X-IronPort-AV: E=Sophos;i="4.71,351,1320624000"; 
   d="scan'208";a="9459142"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Dec 2011 10:47:05 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 14 Dec 2011 10:47:05 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Adin Scannell <adin@gridcentric.ca>
Date: Wed, 14 Dec 2011 10:47:05 +0000
In-Reply-To: <CAAJKtqqmVCyMfAO8iYOuUAnbwFEzoMB0=_fUv5fxpvi2w4tTbg@mail.gmail.com>
References: <patchbomb.1323472550@xdev.gridcentric.ca>
	<6e8b8fb2c8b23e39d910.1323472555@xdev.gridcentric.ca>
	<1323686356.20077.133.camel@zakaz.uk.xensource.com>
	<a221d43997a6992363f8690a30d0ac9c.squirrel@webmail.lagarcavilla.org>
	<CAAJKtqqmVCyMfAO8iYOuUAnbwFEzoMB0=_fUv5fxpvi2w4tTbg@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323859625.20077.392.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"andres@gridcentric.ca" <andres@gridcentric.ca>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Tim
	\(Xen.org\)" <tim@xen.org>,
	"andres@lagarcavilla.org" <andres@lagarcavilla.org>
Subject: Re: [Xen-devel] [PATCH 5 of 8] Tools: Expose to libxc the total
 number of shared frames and space saved
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2011-12-13 at 17:08 +0000, Adin Scannell wrote:
> On Mon, Dec 12, 2011 at 10:43 PM, Andres Lagar-Cavilla
> <andres@lagarcavilla.org> wrote:
> > used_frames indicates the number of frames of memory that are shared,
> > each, by two or more domains. We use the term "frame" because it's
> > commonly used in textbooks for MMUs, in the sense that "a frame hosts a
> > page" or "a page maps to a frame". Thus our use of shared frames,
> > representing a different page (albeit with identical contents) to
> > different domains.
> 
> As Andres has pointed out, I named it frames to clearly differentiate
> it from other page-based domctls (it worked!).  With the unusual
> condition of multiple domains pointing to the same frame, the
> nomenclature gets a bit hairy.  Any suggestions on this front?

Nothing useful, your explanation makes sense and I can't think of a
better way of putting it.

It would be good if you described these semantics in the section of
xl(1) dealing with whichever command displays them (perhaps xl info if
you add the numbers to physinfo?).

> > freed_pages indicates the number of individual pages freed as a result of
> > sharing. These are pages, one per domain.
> 
> Here's a quick explanation and reason for these stats:
> 
> The way I see it, there are three easy-to-track, non-historical stats
> about sharing.
> X - The total number of domain pages that map to shared frames.
> Y - The number of frames saved with sharing.
> Z - The total number of shared frames (i.e. pages owned by dom_cow).
> 
> Any two of these will give you the third (via X = Y + Z).  In this
> case, we used Y & Z because I think that they are the simplest to
> reason about (and therefore the most likely to be wanted).  An
> argument could easily be made for others though, if someone feels
> strongly.
> 
> There are certainly some historical stats (# of unshares, etc.) and
> lots of per-page/frame stats that would be of interest as well. But,
> bit by bit...

Sure...

Ian.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 10:48:22 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 10:48:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RamNX-0000uW-3W; Wed, 14 Dec 2011 10:48:03 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RamNV-0000uQ-Tl
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 10:48:02 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1323859625!7346669!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTc4Ng==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11091 invoked from network); 14 Dec 2011 10:47:06 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Dec 2011 10:47:06 -0000
X-IronPort-AV: E=Sophos;i="4.71,351,1320624000"; 
   d="scan'208";a="9459142"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Dec 2011 10:47:05 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 14 Dec 2011 10:47:05 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Adin Scannell <adin@gridcentric.ca>
Date: Wed, 14 Dec 2011 10:47:05 +0000
In-Reply-To: <CAAJKtqqmVCyMfAO8iYOuUAnbwFEzoMB0=_fUv5fxpvi2w4tTbg@mail.gmail.com>
References: <patchbomb.1323472550@xdev.gridcentric.ca>
	<6e8b8fb2c8b23e39d910.1323472555@xdev.gridcentric.ca>
	<1323686356.20077.133.camel@zakaz.uk.xensource.com>
	<a221d43997a6992363f8690a30d0ac9c.squirrel@webmail.lagarcavilla.org>
	<CAAJKtqqmVCyMfAO8iYOuUAnbwFEzoMB0=_fUv5fxpvi2w4tTbg@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323859625.20077.392.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"andres@gridcentric.ca" <andres@gridcentric.ca>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Tim
	\(Xen.org\)" <tim@xen.org>,
	"andres@lagarcavilla.org" <andres@lagarcavilla.org>
Subject: Re: [Xen-devel] [PATCH 5 of 8] Tools: Expose to libxc the total
 number of shared frames and space saved
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2011-12-13 at 17:08 +0000, Adin Scannell wrote:
> On Mon, Dec 12, 2011 at 10:43 PM, Andres Lagar-Cavilla
> <andres@lagarcavilla.org> wrote:
> > used_frames indicates the number of frames of memory that are shared,
> > each, by two or more domains. We use the term "frame" because it's
> > commonly used in textbooks for MMUs, in the sense that "a frame hosts a
> > page" or "a page maps to a frame". Thus our use of shared frames,
> > representing a different page (albeit with identical contents) to
> > different domains.
> 
> As Andres has pointed out, I named it frames to clearly differentiate
> it from other page-based domctls (it worked!).  With the unusual
> condition of multiple domains pointing to the same frame, the
> nomenclature gets a bit hairy.  Any suggestions on this front?

Nothing useful, your explanation makes sense and I can't think of a
better way of putting it.

It would be good if you described these semantics in the section of
xl(1) dealing with whichever command displays them (perhaps xl info if
you add the numbers to physinfo?).

> > freed_pages indicates the number of individual pages freed as a result of
> > sharing. These are pages, one per domain.
> 
> Here's a quick explanation and reason for these stats:
> 
> The way I see it, there are three easy-to-track, non-historical stats
> about sharing.
> X - The total number of domain pages that map to shared frames.
> Y - The number of frames saved with sharing.
> Z - The total number of shared frames (i.e. pages owned by dom_cow).
> 
> Any two of these will give you the third (via X = Y + Z).  In this
> case, we used Y & Z because I think that they are the simplest to
> reason about (and therefore the most likely to be wanted).  An
> argument could easily be made for others though, if someone feels
> strongly.
> 
> There are certainly some historical stats (# of unshares, etc.) and
> lots of per-page/frame stats that would be of interest as well. But,
> bit by bit...

Sure...

Ian.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 10:56:15 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 10: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.xensource.com>)
	id 1RamV8-00015P-2N; Wed, 14 Dec 2011 10:55:54 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RamV6-00015K-MX
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 10:55:52 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1323860097!7210233!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTc4Ng==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3910 invoked from network); 14 Dec 2011 10:54:57 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Dec 2011 10:54:57 -0000
X-IronPort-AV: E=Sophos;i="4.71,351,1320624000"; 
   d="scan'208";a="9459453"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Dec 2011 10:54:57 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 14 Dec 2011 10:54:57 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau =?ISO-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
Date: Wed, 14 Dec 2011 10:54:56 +0000
In-Reply-To: <CAPLaKK6wqa+VAxgzLWudQ2C2kaoXww9KK3BQhU4fKmoCAMFCzQ@mail.gmail.com>
References: <patchbomb.1323768375@loki.upc.es>
	<35c322e6020501447936.1323768387@loki.upc.es>
	<20199.26896.928532.781947@mariner.uk.xensource.com>
	<CAPLaKK6wqa+VAxgzLWudQ2C2kaoXww9KK3BQhU4fKmoCAMFCzQ@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323860097.20077.394.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 12 of 14 v4] libxl: set frontend status to 6
 on domain destroy
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gV2VkLCAyMDExLTEyLTE0IGF0IDA5OjEzICswMDAwLCBSb2dlciBQYXUgTW9ubsOpIHdyb3Rl
Ogo+IDIwMTEvMTIvMTMgSWFuIEphY2tzb24gPElhbi5KYWNrc29uQGV1LmNpdHJpeC5jb20+Ogo+
ID4gUm9nZXIgUGF1IE1vbm5lIHdyaXRlcyAoIltYZW4tZGV2ZWxdIFtQQVRDSCAxMiBvZiAxNCB2
NF0gbGlieGw6IHNldCBmcm9udGVuZCBzdGF0dXMgdG8gNiBvbiBkb21haW4gZGVzdHJveSIpOgo+
ID4+IGxpYnhsOiBzZXQgZnJvbnRlbmQgc3RhdHVzIHRvIDYgb24gZG9tYWluIGRlc3Ryb3kKPiA+
Pgo+ID4+IFNldCBmcm9udGVuZCBzdGF0dXMgdG8gNiBvbiBkb21haW4gZGVzdHJ1Y3Rpb24gYW5k
IHdhaXQgZm9yIGRldmljZXMgdG8KPiA+PiBiZSBkaXNjb25uZWN0ZWQgYmVmb3JlIGV4ZWN1dGlu
ZyBob3RwbHVnIHNjcmlwdHMuCj4gPgo+ID4gVGhlcmUgc2VlbXMgdG8gYmUgYSByYWNlIGhlcmUu
Cj4gPgo+ID4+ICsgICAgbGlieGxfX3hzX3dyaXRlKGdjLCBYQlRfTlVMTCwgbGlieGxfX3Nwcmlu
dGYoZ2MsICIlcy8lcyIsIGZlX3BhdGgsICJzdGF0ZSIpLCAiNiIpOwo+ID4KPiA+IFNvIGhlcmUs
IHRoZSBrZXJuZWwgb3IgYmFja2VuZGQgc3RhcnQgcmFjaW5nLCBhbmQgeW91IGhvcGUgdGhhdCB0
aGV5Cj4gPiB3aW4gdGhlIHJhY2UgYW5kIGNsb3NlIHRoZSBkZXZpY2UgYmVmb3JlIC4uLgo+IAo+
IEZyb20gbXkgZXhwZXJpZW5jZSBpbiBOZXRCU0QsIHRoZSBrZXJuZWwgb25seSBjbG9zZXMgdGhl
IGRldmljZSB3aGVuCj4gaXQncyBmcm9udGVuZCBzdGF0ZSBpcyBzZXQgdG8gNiwgc2luY2Ugd2Ug
ZGVzdHJveSB0aGUgZG9tYWluLCBpdCBpcwo+IHVuYWJsZSB0byBzZXQgdGhlIHN0YXR1cyB0byA2
LCBhbmQgdGh1cyB0aGUga2VybmVsIGRvZXNuJ3QgZGV0YWNoIHRoZQo+IGRldmljZXMuCgpTbyBp
ZiB5b3Ugcm0gdGhlIGJhY2tlbmQgZGlyZWN0b3J5IHRoZSBOZXRCU0QgZG9lcyBub3QgdGFrZSB0
aGF0IGFzIGEKc2lnbiB0byB0ZWFyIGRvd24gdGhlIGRldmljZT8gVGhhdCBzb3VuZHMgbGlrZSBh
IGJ1ZyBpbiB0aGUgTmV0QlNECmJhY2tlbmQgLS0gaXQgc2hvdWxkIHRyZWF0IGRlbGV0aW9uIG9m
IHRoZSBiYWNrZW5kIHN0YXRlIGRpciBhcyBpZiBpdAp3ZXJlIHJlYWRpbmcgc3RhdGUgPSAiNiIg
YW5kIHNodXQgZXZlcnl0aGluZyBkb3duLgoKT3IgaXMgdGhlIGlzc3VlIG9ubHkgaW4gdGhlIHVz
ZXJzcGFjZSBwb3J0aW9ucz8KCj4gIEkndmUgYWRkZWQgc29tZSBsaWJ4bF9fd2FpdF9mb3JfZGV2
aWNlX3N0YXRlIGxvZ2ljIGhlcmUsIHRvCj4gYXNzdXJlIHRoZSBiYWNrZW5kIHN0YXRlIGlzIHNl
dCB0byA2IGJlZm9yZSB0cnlpbmcgdG8gZXhlY3V0ZSBob3RwbHVnCj4gc2NyaXB0cy4KCkJ1dCB0
aGF0IHdpbGwgYWx3YXlzIGJlIHRydWUgd2l0aCB0aGlzIHBhdGNoIHNpbmNlIHlvdSBzZXQgaXQg
dGhhdCB3YXkKanVzdCBiZWZvcmUsIHJpZ2h0PwoKSWYgeW91IGdvIGRvd24gdGhpcyBwYXRoIHRo
ZW4gSSB0aGluayB5b3UgbmVlZCB0byBzZXQgdGhlIHN0YXRlIHRvCiI1IiAoQ2xvc2luZykgaW4g
b3JkZXIgdG8gcHJvbXB0IHRoZSBiYWNrZW5kIHRvIHRyYW5zaXRpb24gdG8KIjYiIChDbG9zZWQp
IGl0c2VsZi4gSG93ZXZlciB5b3UgbmVlZCB0byBiZSBjYXJlZnVsIGFib3V0IGFkZGluZyBhCnN5
bmNocm9ub3VzIHdhaXQgdG8gdGhlIGRldmljZSBkZXN0cm95IGZ1bmN0aW9uLiBUaGlzIHNob3Vs
ZCBldmVudHVhbGx5CndvcmsgZXZlbiBpZiB0aGUgZnJvbnRlbmQgYW5kIGJhY2tlbmQgYXJlIG5v
dCBjby1vcGVyYXRpbmcuIFRoYXQgc3RhcnRzCnRvIGxvb2sgYSBiaXQgbGlrZSBjYWxsaW5nIGxp
YnhsX19kZXZpY2VfcmVtb3ZlIGluc3RlYWQuCgo+ICBUaGUgdHJ1dGggaXMgdGhhdCBJIGhhZCBp
dCBpbiBwcmV2aW91cyB2ZXJzaW9ucyBvZiBteSBwYXRjaCwKPiBidXQgaXQgc2VlbXMgdGhlIGtl
cm5lbCBhbHdheXMgc3dpdGNoZXMgY29udGV4dHMgYW5kIGRldGFjaGVzIHRoZQo+IGRldmljZXMg
YmVmb3JlIGV4ZWN1dGluZyBob3RwbHVnIHNjcmlwdHMgKGl0IG1pZ2h0IGp1c3QgYmUgbHVjayku
CgpQcm9iYWJseSBqdXN0IGx1Y2sgYW5kIHBhcnRseSBkdWUgZS5nLiB0byB5b3VyIHByZXN1bWFi
bHkgc3lzdGVtIGJlaW5nCm9ubHkgdmVyeSBsaWdodGx5IGxvYWRlZC4KCklhbi4KCj4gCj4gQWxz
byB0aGlzIHBhdGNoIHNwZWVkcyBkb21haW4gZGVzdHJ1Y3Rpb24gYSBsb3QgKHdoaWNoIGlzIGFs
c28gcXVpdGUKPiBzbG93IHVuZGVyIExpbnV4IGZyb20gd2hhdCBJIHNhdykuCj4gCj4gPj4gICAg
ICBsaWJ4bF9fZGV2aWNlX2V4ZWN1dGVfaG90cGx1ZyhnYywgZGV2LCBESVNDT05ORUNUKTsKPiA+
Cj4gPiAuLi4gdGhlIGhvdHBsdWcgc2NyaXB0IHRyaWVzIHRvIHJlbW92ZSBpdC4KPiA+Cj4gPiBJ
cyB0aGVyZSBzb21ldGhpbmcgd2UgY2FuIGRvIHRvIG1ha2Ugc3VyZSB0aGF0IHdlIGFsd2F5cyBn
ZXQgdGhpcwo+ID4gcmlnaHQgPwo+ID4KPiA+IElhbi4KPiAKPiBfX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+IFhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKPiBY
ZW4tZGV2ZWxAbGlzdHMueGVuc291cmNlLmNvbQo+IGh0dHA6Ly9saXN0cy54ZW5zb3VyY2UuY29t
L3hlbi1kZXZlbAoKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29t
Cmh0dHA6Ly9saXN0cy54ZW5zb3VyY2UuY29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Wed Dec 14 10:56:15 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 10: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.xensource.com>)
	id 1RamV8-00015P-2N; Wed, 14 Dec 2011 10:55:54 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RamV6-00015K-MX
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 10:55:52 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1323860097!7210233!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTc4Ng==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3910 invoked from network); 14 Dec 2011 10:54:57 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Dec 2011 10:54:57 -0000
X-IronPort-AV: E=Sophos;i="4.71,351,1320624000"; 
   d="scan'208";a="9459453"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Dec 2011 10:54:57 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 14 Dec 2011 10:54:57 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau =?ISO-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
Date: Wed, 14 Dec 2011 10:54:56 +0000
In-Reply-To: <CAPLaKK6wqa+VAxgzLWudQ2C2kaoXww9KK3BQhU4fKmoCAMFCzQ@mail.gmail.com>
References: <patchbomb.1323768375@loki.upc.es>
	<35c322e6020501447936.1323768387@loki.upc.es>
	<20199.26896.928532.781947@mariner.uk.xensource.com>
	<CAPLaKK6wqa+VAxgzLWudQ2C2kaoXww9KK3BQhU4fKmoCAMFCzQ@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323860097.20077.394.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 12 of 14 v4] libxl: set frontend status to 6
 on domain destroy
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gV2VkLCAyMDExLTEyLTE0IGF0IDA5OjEzICswMDAwLCBSb2dlciBQYXUgTW9ubsOpIHdyb3Rl
Ogo+IDIwMTEvMTIvMTMgSWFuIEphY2tzb24gPElhbi5KYWNrc29uQGV1LmNpdHJpeC5jb20+Ogo+
ID4gUm9nZXIgUGF1IE1vbm5lIHdyaXRlcyAoIltYZW4tZGV2ZWxdIFtQQVRDSCAxMiBvZiAxNCB2
NF0gbGlieGw6IHNldCBmcm9udGVuZCBzdGF0dXMgdG8gNiBvbiBkb21haW4gZGVzdHJveSIpOgo+
ID4+IGxpYnhsOiBzZXQgZnJvbnRlbmQgc3RhdHVzIHRvIDYgb24gZG9tYWluIGRlc3Ryb3kKPiA+
Pgo+ID4+IFNldCBmcm9udGVuZCBzdGF0dXMgdG8gNiBvbiBkb21haW4gZGVzdHJ1Y3Rpb24gYW5k
IHdhaXQgZm9yIGRldmljZXMgdG8KPiA+PiBiZSBkaXNjb25uZWN0ZWQgYmVmb3JlIGV4ZWN1dGlu
ZyBob3RwbHVnIHNjcmlwdHMuCj4gPgo+ID4gVGhlcmUgc2VlbXMgdG8gYmUgYSByYWNlIGhlcmUu
Cj4gPgo+ID4+ICsgICAgbGlieGxfX3hzX3dyaXRlKGdjLCBYQlRfTlVMTCwgbGlieGxfX3Nwcmlu
dGYoZ2MsICIlcy8lcyIsIGZlX3BhdGgsICJzdGF0ZSIpLCAiNiIpOwo+ID4KPiA+IFNvIGhlcmUs
IHRoZSBrZXJuZWwgb3IgYmFja2VuZGQgc3RhcnQgcmFjaW5nLCBhbmQgeW91IGhvcGUgdGhhdCB0
aGV5Cj4gPiB3aW4gdGhlIHJhY2UgYW5kIGNsb3NlIHRoZSBkZXZpY2UgYmVmb3JlIC4uLgo+IAo+
IEZyb20gbXkgZXhwZXJpZW5jZSBpbiBOZXRCU0QsIHRoZSBrZXJuZWwgb25seSBjbG9zZXMgdGhl
IGRldmljZSB3aGVuCj4gaXQncyBmcm9udGVuZCBzdGF0ZSBpcyBzZXQgdG8gNiwgc2luY2Ugd2Ug
ZGVzdHJveSB0aGUgZG9tYWluLCBpdCBpcwo+IHVuYWJsZSB0byBzZXQgdGhlIHN0YXR1cyB0byA2
LCBhbmQgdGh1cyB0aGUga2VybmVsIGRvZXNuJ3QgZGV0YWNoIHRoZQo+IGRldmljZXMuCgpTbyBp
ZiB5b3Ugcm0gdGhlIGJhY2tlbmQgZGlyZWN0b3J5IHRoZSBOZXRCU0QgZG9lcyBub3QgdGFrZSB0
aGF0IGFzIGEKc2lnbiB0byB0ZWFyIGRvd24gdGhlIGRldmljZT8gVGhhdCBzb3VuZHMgbGlrZSBh
IGJ1ZyBpbiB0aGUgTmV0QlNECmJhY2tlbmQgLS0gaXQgc2hvdWxkIHRyZWF0IGRlbGV0aW9uIG9m
IHRoZSBiYWNrZW5kIHN0YXRlIGRpciBhcyBpZiBpdAp3ZXJlIHJlYWRpbmcgc3RhdGUgPSAiNiIg
YW5kIHNodXQgZXZlcnl0aGluZyBkb3duLgoKT3IgaXMgdGhlIGlzc3VlIG9ubHkgaW4gdGhlIHVz
ZXJzcGFjZSBwb3J0aW9ucz8KCj4gIEkndmUgYWRkZWQgc29tZSBsaWJ4bF9fd2FpdF9mb3JfZGV2
aWNlX3N0YXRlIGxvZ2ljIGhlcmUsIHRvCj4gYXNzdXJlIHRoZSBiYWNrZW5kIHN0YXRlIGlzIHNl
dCB0byA2IGJlZm9yZSB0cnlpbmcgdG8gZXhlY3V0ZSBob3RwbHVnCj4gc2NyaXB0cy4KCkJ1dCB0
aGF0IHdpbGwgYWx3YXlzIGJlIHRydWUgd2l0aCB0aGlzIHBhdGNoIHNpbmNlIHlvdSBzZXQgaXQg
dGhhdCB3YXkKanVzdCBiZWZvcmUsIHJpZ2h0PwoKSWYgeW91IGdvIGRvd24gdGhpcyBwYXRoIHRo
ZW4gSSB0aGluayB5b3UgbmVlZCB0byBzZXQgdGhlIHN0YXRlIHRvCiI1IiAoQ2xvc2luZykgaW4g
b3JkZXIgdG8gcHJvbXB0IHRoZSBiYWNrZW5kIHRvIHRyYW5zaXRpb24gdG8KIjYiIChDbG9zZWQp
IGl0c2VsZi4gSG93ZXZlciB5b3UgbmVlZCB0byBiZSBjYXJlZnVsIGFib3V0IGFkZGluZyBhCnN5
bmNocm9ub3VzIHdhaXQgdG8gdGhlIGRldmljZSBkZXN0cm95IGZ1bmN0aW9uLiBUaGlzIHNob3Vs
ZCBldmVudHVhbGx5CndvcmsgZXZlbiBpZiB0aGUgZnJvbnRlbmQgYW5kIGJhY2tlbmQgYXJlIG5v
dCBjby1vcGVyYXRpbmcuIFRoYXQgc3RhcnRzCnRvIGxvb2sgYSBiaXQgbGlrZSBjYWxsaW5nIGxp
YnhsX19kZXZpY2VfcmVtb3ZlIGluc3RlYWQuCgo+ICBUaGUgdHJ1dGggaXMgdGhhdCBJIGhhZCBp
dCBpbiBwcmV2aW91cyB2ZXJzaW9ucyBvZiBteSBwYXRjaCwKPiBidXQgaXQgc2VlbXMgdGhlIGtl
cm5lbCBhbHdheXMgc3dpdGNoZXMgY29udGV4dHMgYW5kIGRldGFjaGVzIHRoZQo+IGRldmljZXMg
YmVmb3JlIGV4ZWN1dGluZyBob3RwbHVnIHNjcmlwdHMgKGl0IG1pZ2h0IGp1c3QgYmUgbHVjayku
CgpQcm9iYWJseSBqdXN0IGx1Y2sgYW5kIHBhcnRseSBkdWUgZS5nLiB0byB5b3VyIHByZXN1bWFi
bHkgc3lzdGVtIGJlaW5nCm9ubHkgdmVyeSBsaWdodGx5IGxvYWRlZC4KCklhbi4KCj4gCj4gQWxz
byB0aGlzIHBhdGNoIHNwZWVkcyBkb21haW4gZGVzdHJ1Y3Rpb24gYSBsb3QgKHdoaWNoIGlzIGFs
c28gcXVpdGUKPiBzbG93IHVuZGVyIExpbnV4IGZyb20gd2hhdCBJIHNhdykuCj4gCj4gPj4gICAg
ICBsaWJ4bF9fZGV2aWNlX2V4ZWN1dGVfaG90cGx1ZyhnYywgZGV2LCBESVNDT05ORUNUKTsKPiA+
Cj4gPiAuLi4gdGhlIGhvdHBsdWcgc2NyaXB0IHRyaWVzIHRvIHJlbW92ZSBpdC4KPiA+Cj4gPiBJ
cyB0aGVyZSBzb21ldGhpbmcgd2UgY2FuIGRvIHRvIG1ha2Ugc3VyZSB0aGF0IHdlIGFsd2F5cyBn
ZXQgdGhpcwo+ID4gcmlnaHQgPwo+ID4KPiA+IElhbi4KPiAKPiBfX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+IFhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKPiBY
ZW4tZGV2ZWxAbGlzdHMueGVuc291cmNlLmNvbQo+IGh0dHA6Ly9saXN0cy54ZW5zb3VyY2UuY29t
L3hlbi1kZXZlbAoKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29t
Cmh0dHA6Ly9saXN0cy54ZW5zb3VyY2UuY29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Wed Dec 14 11:03:56 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 11:03:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ramcb-0001PI-0S; Wed, 14 Dec 2011 11:03:37 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RamcZ-0001PC-Mv
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 11:03:35 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1323860557!7209112!1
X-Originating-IP: [209.85.210.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28388 invoked from network); 14 Dec 2011 11:02:39 -0000
Received: from mail-pz0-f43.google.com (HELO mail-pz0-f43.google.com)
	(209.85.210.43)
	by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Dec 2011 11:02:39 -0000
Received: by daec6 with SMTP id c6so2490263dae.30
	for <xen-devel@lists.xensource.com>;
	Wed, 14 Dec 2011 03:02:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=ZtBYBX3vgIU2OatAksT80VzXtXkvdF49sR246lOlPQI=;
	b=r0Yh6URt/pw2PPXVVfHhI6mJpZIS8JKGolG4qOl2/nBLZcs74j5h60/bBgyLa7vHRE
	lLGejkxCAIW3RISrYHkfPRLa+bTz1vHe7BOmd75k2NcFyLFAuC4rQvYAIkkFDesCEScb
	O7/hUwCeS5B824hysFNYvQu+3PzzNiUss50RM=
MIME-Version: 1.0
Received: by 10.68.211.225 with SMTP id nf1mr2847250pbc.47.1323860557248; Wed,
	14 Dec 2011 03:02:37 -0800 (PST)
Received: by 10.142.47.17 with HTTP; Wed, 14 Dec 2011 03:02:37 -0800 (PST)
In-Reply-To: <20111214102309.GA13038@aepfle.de>
References: <7697ee23b08b8eaca9ae.1323768649@loki.upc.es>
	<1323770544.20077.268.camel@zakaz.uk.xensource.com>
	<4EE72B7C.7030006@redhat.com>
	<CAPLaKK5+Cup9w5HJKhMmu7RQG=EDp_FL8kjHQuaUW9PX373R=A@mail.gmail.com>
	<20199.26338.308105.913566@mariner.uk.xensource.com>
	<CAPLaKK7JXCsmcxQU0-27_-N7coPFM+wpB9Y-JDCziB8OG7=Dhw@mail.gmail.com>
	<20111214102309.GA13038@aepfle.de>
Date: Wed, 14 Dec 2011 12:02:37 +0100
X-Google-Sender-Auth: ZWaTnJwvcZW0lfF2Hx5-a6HPWw0
Message-ID: <CAPLaKK4Qop53qg8A37KHe=_ULGpaU0hvnxosDhnD2dAK=VS7Dw@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Olaf Hering <olaf@aepfle.de>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Laszlo Ersek <lersek@redhat.com>, Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH] xenpaging: remove XOPEN_SOURCE
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

MjAxMS8xMi8xNCBPbGFmIEhlcmluZyA8b2xhZkBhZXBmbGUuZGU+Ogo+IE9uIFdlZCwgRGVjIDE0
LCBSb2dlciBQYXUgTW9ubsOpIHdyb3RlOgo+Cj4+IE9rLCBJIHdpbGwgcmVzZW5kIHRoZSBwYXRj
aCBhZGRpbmcgX05FVEJTRF9TT1VSQ0UgaW5zdGVhZCBvZiByZW1vdmluZwo+PiBfWE9QRU5fU09V
UkNFLgo+Cj4gSG93IGRvIG90aGVyIHNvdXJjZSBmaWxlcyB3aXRoIGFzcHJpbnRmKCkgY2FsbHMg
Y29tcGlsZSBmb3IgeW91PyAobGlieGwpCj4gV2h5IGlzIHhlbnBhZ2luZyBzcGVjaWFsPwoKbGli
eGwgZG9lc24ndCBkZWZpbmUgX1hPUEVOX1NPVVJDRSBhbHRob3VnaCBpdCB1c2VzIGFzcHJpbnRm
LCBhbmQKb3RoZXIgcGxhY2VzIHRoYXQgZGVmaW5lIF9YT1BFTl9TT1VSQ0UgZG9uJ3QgdXNlIGFz
cHJpbnRmLCB0aGF0J3Mgd2h5CkkgZGlkbid0IGhhdmUgcHJvYmxlbXMgd2l0aCB0aGF0IGJlZm9y
ZS4KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1k
ZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbnNvdXJjZS5jb20KaHR0cDovL2xp
c3RzLnhlbnNvdXJjZS5jb20veGVuLWRldmVsCg==

From xen-devel-bounces@lists.xensource.com Wed Dec 14 11:03:56 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 11:03:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ramcb-0001PI-0S; Wed, 14 Dec 2011 11:03:37 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RamcZ-0001PC-Mv
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 11:03:35 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1323860557!7209112!1
X-Originating-IP: [209.85.210.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28388 invoked from network); 14 Dec 2011 11:02:39 -0000
Received: from mail-pz0-f43.google.com (HELO mail-pz0-f43.google.com)
	(209.85.210.43)
	by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Dec 2011 11:02:39 -0000
Received: by daec6 with SMTP id c6so2490263dae.30
	for <xen-devel@lists.xensource.com>;
	Wed, 14 Dec 2011 03:02:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=ZtBYBX3vgIU2OatAksT80VzXtXkvdF49sR246lOlPQI=;
	b=r0Yh6URt/pw2PPXVVfHhI6mJpZIS8JKGolG4qOl2/nBLZcs74j5h60/bBgyLa7vHRE
	lLGejkxCAIW3RISrYHkfPRLa+bTz1vHe7BOmd75k2NcFyLFAuC4rQvYAIkkFDesCEScb
	O7/hUwCeS5B824hysFNYvQu+3PzzNiUss50RM=
MIME-Version: 1.0
Received: by 10.68.211.225 with SMTP id nf1mr2847250pbc.47.1323860557248; Wed,
	14 Dec 2011 03:02:37 -0800 (PST)
Received: by 10.142.47.17 with HTTP; Wed, 14 Dec 2011 03:02:37 -0800 (PST)
In-Reply-To: <20111214102309.GA13038@aepfle.de>
References: <7697ee23b08b8eaca9ae.1323768649@loki.upc.es>
	<1323770544.20077.268.camel@zakaz.uk.xensource.com>
	<4EE72B7C.7030006@redhat.com>
	<CAPLaKK5+Cup9w5HJKhMmu7RQG=EDp_FL8kjHQuaUW9PX373R=A@mail.gmail.com>
	<20199.26338.308105.913566@mariner.uk.xensource.com>
	<CAPLaKK7JXCsmcxQU0-27_-N7coPFM+wpB9Y-JDCziB8OG7=Dhw@mail.gmail.com>
	<20111214102309.GA13038@aepfle.de>
Date: Wed, 14 Dec 2011 12:02:37 +0100
X-Google-Sender-Auth: ZWaTnJwvcZW0lfF2Hx5-a6HPWw0
Message-ID: <CAPLaKK4Qop53qg8A37KHe=_ULGpaU0hvnxosDhnD2dAK=VS7Dw@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Olaf Hering <olaf@aepfle.de>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Laszlo Ersek <lersek@redhat.com>, Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH] xenpaging: remove XOPEN_SOURCE
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

MjAxMS8xMi8xNCBPbGFmIEhlcmluZyA8b2xhZkBhZXBmbGUuZGU+Ogo+IE9uIFdlZCwgRGVjIDE0
LCBSb2dlciBQYXUgTW9ubsOpIHdyb3RlOgo+Cj4+IE9rLCBJIHdpbGwgcmVzZW5kIHRoZSBwYXRj
aCBhZGRpbmcgX05FVEJTRF9TT1VSQ0UgaW5zdGVhZCBvZiByZW1vdmluZwo+PiBfWE9QRU5fU09V
UkNFLgo+Cj4gSG93IGRvIG90aGVyIHNvdXJjZSBmaWxlcyB3aXRoIGFzcHJpbnRmKCkgY2FsbHMg
Y29tcGlsZSBmb3IgeW91PyAobGlieGwpCj4gV2h5IGlzIHhlbnBhZ2luZyBzcGVjaWFsPwoKbGli
eGwgZG9lc24ndCBkZWZpbmUgX1hPUEVOX1NPVVJDRSBhbHRob3VnaCBpdCB1c2VzIGFzcHJpbnRm
LCBhbmQKb3RoZXIgcGxhY2VzIHRoYXQgZGVmaW5lIF9YT1BFTl9TT1VSQ0UgZG9uJ3QgdXNlIGFz
cHJpbnRmLCB0aGF0J3Mgd2h5CkkgZGlkbid0IGhhdmUgcHJvYmxlbXMgd2l0aCB0aGF0IGJlZm9y
ZS4KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1k
ZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbnNvdXJjZS5jb20KaHR0cDovL2xp
c3RzLnhlbnNvdXJjZS5jb20veGVuLWRldmVsCg==

From xen-devel-bounces@lists.xensource.com Wed Dec 14 11:13:54 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 11:13:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RammG-0001Zu-4F; Wed, 14 Dec 2011 11:13:36 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RammD-0001Zp-PG
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 11:13:33 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1323861112!48948080!1
X-Originating-IP: [209.85.160.43]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31587 invoked from network); 14 Dec 2011 11:11:54 -0000
Received: from mail-pw0-f43.google.com (HELO mail-pw0-f43.google.com)
	(209.85.160.43)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Dec 2011 11:11:54 -0000
Received: by pbbb11 with SMTP id b11so3159457pbb.30
	for <xen-devel@lists.xensource.com>;
	Wed, 14 Dec 2011 03:12:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=zZXdRnv4IkrBpRC20bSPn/avD8Y0/gHCATUX+Iu9a+4=;
	b=A/ljdB3mRZM/NCCwUIq/AlWRaU9IH+fgfnzVDq91ezJvB95q+brwdb5kde81i7YmVR
	h2mZNBBnhoHk5qvFvEtVQNLPoP0R7e1FeZrfVN5EFsUDPyQjjk5jcGTD63t5ZYUArnMW
	0C5dvQaInbvyjBU1+rB4u4lPphx8K2syl5X/U=
MIME-Version: 1.0
Received: by 10.68.211.225 with SMTP id nf1mr2890908pbc.47.1323861156257; Wed,
	14 Dec 2011 03:12:36 -0800 (PST)
Received: by 10.142.47.17 with HTTP; Wed, 14 Dec 2011 03:12:36 -0800 (PST)
In-Reply-To: <1323860097.20077.394.camel@zakaz.uk.xensource.com>
References: <patchbomb.1323768375@loki.upc.es>
	<35c322e6020501447936.1323768387@loki.upc.es>
	<20199.26896.928532.781947@mariner.uk.xensource.com>
	<CAPLaKK6wqa+VAxgzLWudQ2C2kaoXww9KK3BQhU4fKmoCAMFCzQ@mail.gmail.com>
	<1323860097.20077.394.camel@zakaz.uk.xensource.com>
Date: Wed, 14 Dec 2011 12:12:36 +0100
X-Google-Sender-Auth: 3wd9ag7qqChjWMJp_ZTs08IghQU
Message-ID: <CAPLaKK7Wv2HeRbg5Ze=B8DFe=wbzq=V35s6WVFXqrynh0ikRTw@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 12 of 14 v4] libxl: set frontend status to 6
 on domain destroy
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

MjAxMS8xMi8xNCBJYW4gQ2FtcGJlbGwgPElhbi5DYW1wYmVsbEBjaXRyaXguY29tPjoKPiBTbyBp
ZiB5b3Ugcm0gdGhlIGJhY2tlbmQgZGlyZWN0b3J5IHRoZSBOZXRCU0QgZG9lcyBub3QgdGFrZSB0
aGF0IGFzIGEKPiBzaWduIHRvIHRlYXIgZG93biB0aGUgZGV2aWNlPyBUaGF0IHNvdW5kcyBsaWtl
IGEgYnVnIGluIHRoZSBOZXRCU0QKPiBiYWNrZW5kIC0tIGl0IHNob3VsZCB0cmVhdCBkZWxldGlv
biBvZiB0aGUgYmFja2VuZCBzdGF0ZSBkaXIgYXMgaWYgaXQKPiB3ZXJlIHJlYWRpbmcgc3RhdGUg
PSAiNiIgYW5kIHNodXQgZXZlcnl0aGluZyBkb3duLgoKWWVzLCBpZiBJIGRlbGV0ZSB0aGUgZnJv
bnRlbmQgZnJvbSB4ZW5zdG9yZSwgdGhlIGRldmljZXMgYXJlIGRldGFjaGVkLgpBbnl3YXksIGRv
aW5nIGl0IG9uZSB3YXkgb3IgYW5vdGhlciAoZGVsZXRpb24gb3Igc2V0dGluZyBzdGF0ZSB0byA2
KQpkb2Vzbid0IHJlYWxseSBtYWtlIGEgZGlmZmVyZW5jZSwgeW91IHN0aWxsIGhhdmUgdG8gd2Fp
dCBmb3IgdGhlCmJhY2tlbmQgdG8gYmUgZGlzY29ubmVjdGVkIChkZXRhY2hlZCkgYmVmb3JlIGV4
ZWN1dGluZyBob3RwbHVnCnNjcmlwdHMuCgo+IE9yIGlzIHRoZSBpc3N1ZSBvbmx5IGluIHRoZSB1
c2Vyc3BhY2UgcG9ydGlvbnM/Cj4KPj4gwqBJJ3ZlIGFkZGVkIHNvbWUgbGlieGxfX3dhaXRfZm9y
X2RldmljZV9zdGF0ZSBsb2dpYyBoZXJlLCB0bwo+PiBhc3N1cmUgdGhlIGJhY2tlbmQgc3RhdGUg
aXMgc2V0IHRvIDYgYmVmb3JlIHRyeWluZyB0byBleGVjdXRlIGhvdHBsdWcKPj4gc2NyaXB0cy4K
Pgo+IEJ1dCB0aGF0IHdpbGwgYWx3YXlzIGJlIHRydWUgd2l0aCB0aGlzIHBhdGNoIHNpbmNlIHlv
dSBzZXQgaXQgdGhhdCB3YXkKPiBqdXN0IGJlZm9yZSwgcmlnaHQ/CgpJIHNldCBmcm9udGVuZCBz
dGF0dXMgdG8gNiwgYW5kIEkgc3VnZ2VzdCB0byB3YWl0IGZvciBiYWNrZW5kIHN0YXR1cwp0byBi
ZSA2IGFsc28sIHRoZW4gZXhlY3V0ZSBob3RwbHVnIHNjcmlwdHMuIEl0IHdvbid0IGJlIHRydWUs
IGJlY2F1c2UKZnJvbnRlbmQgYW5kIGJhY2tlbmQgc3RhdHVzIGFyZSBub3QgdGllZCAoaW4gdGhl
IE5ldEJTRCBjYXNlIGJhY2tlbmQKc3RhdHVzIGlzIHNldCBieSB0aGUgRG9tMCBrZXJuZWwgb3Ig
aG90cGx1ZyBzY3JpcHRzLCB3aGlsZSBmcm9udGVuZApzdGF0dXMgaXMgc2V0IGJ5IHRoZSBEb21V
KS4KCj4gSWYgeW91IGdvIGRvd24gdGhpcyBwYXRoIHRoZW4gSSB0aGluayB5b3UgbmVlZCB0byBz
ZXQgdGhlIHN0YXRlIHRvCj4gIjUiIChDbG9zaW5nKSBpbiBvcmRlciB0byBwcm9tcHQgdGhlIGJh
Y2tlbmQgdG8gdHJhbnNpdGlvbiB0bwo+ICI2IiAoQ2xvc2VkKSBpdHNlbGYuIEhvd2V2ZXIgeW91
IG5lZWQgdG8gYmUgY2FyZWZ1bCBhYm91dCBhZGRpbmcgYQo+IHN5bmNocm9ub3VzIHdhaXQgdG8g
dGhlIGRldmljZSBkZXN0cm95IGZ1bmN0aW9uLiBUaGlzIHNob3VsZCBldmVudHVhbGx5Cj4gd29y
ayBldmVuIGlmIHRoZSBmcm9udGVuZCBhbmQgYmFja2VuZCBhcmUgbm90IGNvLW9wZXJhdGluZy4g
VGhhdCBzdGFydHMKPiB0byBsb29rIGEgYml0IGxpa2UgY2FsbGluZyBsaWJ4bF9fZGV2aWNlX3Jl
bW92ZSBpbnN0ZWFkLgoKRG8geW91IG1lYW4gdG8gc2V0IGJhY2tlbmQgc3RhdHVzIHRvIDUgaW5z
dGVhZCBvZiBzZXR0aW5nIGZyb250ZW5kIHRvCjYsIGFuZCB0aGVuIHdhaXQgZm9yIHRoZSBrZXJu
ZWwgdG8gZG8gdGhlIHRyYW5zaXRpb24gZnJvbSA1IHRvIDYsCmluc3RlYWQgb2Ygc2V0dGluZyB0
aGUgZnJvbnRlbmQgdG8gNj8KCj4+IMKgVGhlIHRydXRoIGlzIHRoYXQgSSBoYWQgaXQgaW4gcHJl
dmlvdXMgdmVyc2lvbnMgb2YgbXkgcGF0Y2gsCj4+IGJ1dCBpdCBzZWVtcyB0aGUga2VybmVsIGFs
d2F5cyBzd2l0Y2hlcyBjb250ZXh0cyBhbmQgZGV0YWNoZXMgdGhlCj4+IGRldmljZXMgYmVmb3Jl
IGV4ZWN1dGluZyBob3RwbHVnIHNjcmlwdHMgKGl0IG1pZ2h0IGp1c3QgYmUgbHVjaykuCj4KPiBQ
cm9iYWJseSBqdXN0IGx1Y2sgYW5kIHBhcnRseSBkdWUgZS5nLiB0byB5b3VyIHByZXN1bWFibHkg
c3lzdGVtIGJlaW5nCj4gb25seSB2ZXJ5IGxpZ2h0bHkgbG9hZGVkLgo+Cj4gSWFuLgoKX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxp
bmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuc291cmNlLmNvbQpodHRwOi8vbGlzdHMueGVuc291
cmNlLmNvbS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Wed Dec 14 11:13:54 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 11:13:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RammG-0001Zu-4F; Wed, 14 Dec 2011 11:13:36 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RammD-0001Zp-PG
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 11:13:33 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1323861112!48948080!1
X-Originating-IP: [209.85.160.43]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31587 invoked from network); 14 Dec 2011 11:11:54 -0000
Received: from mail-pw0-f43.google.com (HELO mail-pw0-f43.google.com)
	(209.85.160.43)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Dec 2011 11:11:54 -0000
Received: by pbbb11 with SMTP id b11so3159457pbb.30
	for <xen-devel@lists.xensource.com>;
	Wed, 14 Dec 2011 03:12:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=zZXdRnv4IkrBpRC20bSPn/avD8Y0/gHCATUX+Iu9a+4=;
	b=A/ljdB3mRZM/NCCwUIq/AlWRaU9IH+fgfnzVDq91ezJvB95q+brwdb5kde81i7YmVR
	h2mZNBBnhoHk5qvFvEtVQNLPoP0R7e1FeZrfVN5EFsUDPyQjjk5jcGTD63t5ZYUArnMW
	0C5dvQaInbvyjBU1+rB4u4lPphx8K2syl5X/U=
MIME-Version: 1.0
Received: by 10.68.211.225 with SMTP id nf1mr2890908pbc.47.1323861156257; Wed,
	14 Dec 2011 03:12:36 -0800 (PST)
Received: by 10.142.47.17 with HTTP; Wed, 14 Dec 2011 03:12:36 -0800 (PST)
In-Reply-To: <1323860097.20077.394.camel@zakaz.uk.xensource.com>
References: <patchbomb.1323768375@loki.upc.es>
	<35c322e6020501447936.1323768387@loki.upc.es>
	<20199.26896.928532.781947@mariner.uk.xensource.com>
	<CAPLaKK6wqa+VAxgzLWudQ2C2kaoXww9KK3BQhU4fKmoCAMFCzQ@mail.gmail.com>
	<1323860097.20077.394.camel@zakaz.uk.xensource.com>
Date: Wed, 14 Dec 2011 12:12:36 +0100
X-Google-Sender-Auth: 3wd9ag7qqChjWMJp_ZTs08IghQU
Message-ID: <CAPLaKK7Wv2HeRbg5Ze=B8DFe=wbzq=V35s6WVFXqrynh0ikRTw@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 12 of 14 v4] libxl: set frontend status to 6
 on domain destroy
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

MjAxMS8xMi8xNCBJYW4gQ2FtcGJlbGwgPElhbi5DYW1wYmVsbEBjaXRyaXguY29tPjoKPiBTbyBp
ZiB5b3Ugcm0gdGhlIGJhY2tlbmQgZGlyZWN0b3J5IHRoZSBOZXRCU0QgZG9lcyBub3QgdGFrZSB0
aGF0IGFzIGEKPiBzaWduIHRvIHRlYXIgZG93biB0aGUgZGV2aWNlPyBUaGF0IHNvdW5kcyBsaWtl
IGEgYnVnIGluIHRoZSBOZXRCU0QKPiBiYWNrZW5kIC0tIGl0IHNob3VsZCB0cmVhdCBkZWxldGlv
biBvZiB0aGUgYmFja2VuZCBzdGF0ZSBkaXIgYXMgaWYgaXQKPiB3ZXJlIHJlYWRpbmcgc3RhdGUg
PSAiNiIgYW5kIHNodXQgZXZlcnl0aGluZyBkb3duLgoKWWVzLCBpZiBJIGRlbGV0ZSB0aGUgZnJv
bnRlbmQgZnJvbSB4ZW5zdG9yZSwgdGhlIGRldmljZXMgYXJlIGRldGFjaGVkLgpBbnl3YXksIGRv
aW5nIGl0IG9uZSB3YXkgb3IgYW5vdGhlciAoZGVsZXRpb24gb3Igc2V0dGluZyBzdGF0ZSB0byA2
KQpkb2Vzbid0IHJlYWxseSBtYWtlIGEgZGlmZmVyZW5jZSwgeW91IHN0aWxsIGhhdmUgdG8gd2Fp
dCBmb3IgdGhlCmJhY2tlbmQgdG8gYmUgZGlzY29ubmVjdGVkIChkZXRhY2hlZCkgYmVmb3JlIGV4
ZWN1dGluZyBob3RwbHVnCnNjcmlwdHMuCgo+IE9yIGlzIHRoZSBpc3N1ZSBvbmx5IGluIHRoZSB1
c2Vyc3BhY2UgcG9ydGlvbnM/Cj4KPj4gwqBJJ3ZlIGFkZGVkIHNvbWUgbGlieGxfX3dhaXRfZm9y
X2RldmljZV9zdGF0ZSBsb2dpYyBoZXJlLCB0bwo+PiBhc3N1cmUgdGhlIGJhY2tlbmQgc3RhdGUg
aXMgc2V0IHRvIDYgYmVmb3JlIHRyeWluZyB0byBleGVjdXRlIGhvdHBsdWcKPj4gc2NyaXB0cy4K
Pgo+IEJ1dCB0aGF0IHdpbGwgYWx3YXlzIGJlIHRydWUgd2l0aCB0aGlzIHBhdGNoIHNpbmNlIHlv
dSBzZXQgaXQgdGhhdCB3YXkKPiBqdXN0IGJlZm9yZSwgcmlnaHQ/CgpJIHNldCBmcm9udGVuZCBz
dGF0dXMgdG8gNiwgYW5kIEkgc3VnZ2VzdCB0byB3YWl0IGZvciBiYWNrZW5kIHN0YXR1cwp0byBi
ZSA2IGFsc28sIHRoZW4gZXhlY3V0ZSBob3RwbHVnIHNjcmlwdHMuIEl0IHdvbid0IGJlIHRydWUs
IGJlY2F1c2UKZnJvbnRlbmQgYW5kIGJhY2tlbmQgc3RhdHVzIGFyZSBub3QgdGllZCAoaW4gdGhl
IE5ldEJTRCBjYXNlIGJhY2tlbmQKc3RhdHVzIGlzIHNldCBieSB0aGUgRG9tMCBrZXJuZWwgb3Ig
aG90cGx1ZyBzY3JpcHRzLCB3aGlsZSBmcm9udGVuZApzdGF0dXMgaXMgc2V0IGJ5IHRoZSBEb21V
KS4KCj4gSWYgeW91IGdvIGRvd24gdGhpcyBwYXRoIHRoZW4gSSB0aGluayB5b3UgbmVlZCB0byBz
ZXQgdGhlIHN0YXRlIHRvCj4gIjUiIChDbG9zaW5nKSBpbiBvcmRlciB0byBwcm9tcHQgdGhlIGJh
Y2tlbmQgdG8gdHJhbnNpdGlvbiB0bwo+ICI2IiAoQ2xvc2VkKSBpdHNlbGYuIEhvd2V2ZXIgeW91
IG5lZWQgdG8gYmUgY2FyZWZ1bCBhYm91dCBhZGRpbmcgYQo+IHN5bmNocm9ub3VzIHdhaXQgdG8g
dGhlIGRldmljZSBkZXN0cm95IGZ1bmN0aW9uLiBUaGlzIHNob3VsZCBldmVudHVhbGx5Cj4gd29y
ayBldmVuIGlmIHRoZSBmcm9udGVuZCBhbmQgYmFja2VuZCBhcmUgbm90IGNvLW9wZXJhdGluZy4g
VGhhdCBzdGFydHMKPiB0byBsb29rIGEgYml0IGxpa2UgY2FsbGluZyBsaWJ4bF9fZGV2aWNlX3Jl
bW92ZSBpbnN0ZWFkLgoKRG8geW91IG1lYW4gdG8gc2V0IGJhY2tlbmQgc3RhdHVzIHRvIDUgaW5z
dGVhZCBvZiBzZXR0aW5nIGZyb250ZW5kIHRvCjYsIGFuZCB0aGVuIHdhaXQgZm9yIHRoZSBrZXJu
ZWwgdG8gZG8gdGhlIHRyYW5zaXRpb24gZnJvbSA1IHRvIDYsCmluc3RlYWQgb2Ygc2V0dGluZyB0
aGUgZnJvbnRlbmQgdG8gNj8KCj4+IMKgVGhlIHRydXRoIGlzIHRoYXQgSSBoYWQgaXQgaW4gcHJl
dmlvdXMgdmVyc2lvbnMgb2YgbXkgcGF0Y2gsCj4+IGJ1dCBpdCBzZWVtcyB0aGUga2VybmVsIGFs
d2F5cyBzd2l0Y2hlcyBjb250ZXh0cyBhbmQgZGV0YWNoZXMgdGhlCj4+IGRldmljZXMgYmVmb3Jl
IGV4ZWN1dGluZyBob3RwbHVnIHNjcmlwdHMgKGl0IG1pZ2h0IGp1c3QgYmUgbHVjaykuCj4KPiBQ
cm9iYWJseSBqdXN0IGx1Y2sgYW5kIHBhcnRseSBkdWUgZS5nLiB0byB5b3VyIHByZXN1bWFibHkg
c3lzdGVtIGJlaW5nCj4gb25seSB2ZXJ5IGxpZ2h0bHkgbG9hZGVkLgo+Cj4gSWFuLgoKX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxp
bmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuc291cmNlLmNvbQpodHRwOi8vbGlzdHMueGVuc291
cmNlLmNvbS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Wed Dec 14 11:17:56 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 11:17:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ramq9-0001hW-RD; Wed, 14 Dec 2011 11:17:37 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1Ramq8-0001hK-KY
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 11:17:36 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1323861385!58879501!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTc4Ng==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28764 invoked from network); 14 Dec 2011 11:16:25 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Dec 2011 11:16:25 -0000
X-IronPort-AV: E=Sophos;i="4.71,351,1320624000"; 
   d="scan'208";a="9460000"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Dec 2011 11:16:43 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.161]) by
	LONPMAILMX01.citrite.net ([10.30.203.162]) with mapi; Wed, 14 Dec 2011
	11:16:43 +0000
From: Paul Durrant <Paul.Durrant@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Wed, 14 Dec 2011 11:17:02 +0000
Thread-Topic: [Xen-devel] [PATCH 1 of 2] Re-name xenstore key used to save
	VM generation ID buffer address
Thread-Index: Acy6SM19fQU7e+nCS9KXqH7l+CzJXAACIvEw
Message-ID: <291EDFCB1E9E224A99088639C4762022B5988E58B7@LONPMAILBOX01.citrite.net>
References: <patchbomb.1323855070@cosworth.uk.xensource.com>
	<fded65be5d82461e87de.1323855071@cosworth.uk.xensource.com>
	<1323857513.20077.380.camel@zakaz.uk.xensource.com>
In-Reply-To: <1323857513.20077.380.camel@zakaz.uk.xensource.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 1 of 2] Re-name xenstore key used to save VM
 generation ID buffer address
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com



> -----Original Message-----
> From: Ian Campbell
> Sent: 14 December 2011 10:12
> To: Paul Durrant
> Cc: xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] [PATCH 1 of 2] Re-name xenstore key used to
> save VM generation ID buffer address
> 
> On Wed, 2011-12-14 at 09:31 +0000, Paul Durrant wrote:
> > # HG changeset patch
> > # User Paul Durrant <paul.durrant@citrix.com> # Date 1323854952 0
> #
> > Node ID fded65be5d82461e87de54960db14ce8feb4625f
> > # Parent  03138a08366b895d79e143119d4c9c72833cdbcd
> > Re-name xenstore key used to save VM generation ID buffer address.
> >
> > Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
> >
> > diff -r 03138a08366b -r fded65be5d82
> tools/firmware/hvmloader/acpi/build.c
> > --- a/tools/firmware/hvmloader/acpi/build.c	Fri Dec 09 16:19:36
> 2011 +0000
> > +++ b/tools/firmware/hvmloader/acpi/build.c	Wed Dec 14 09:29:12
> 2011 +0000
> > @@ -309,7 +309,7 @@ unsigned long new_vm_gid(void)
> >      if ( snprintf(addr, sizeof(addr), "0x%lx", virt_to_phys(buf))
> >           >= sizeof(addr) )
> >          return 0;
> > -    xenstore_write("data/generation-id", addr);
> > +    xenstore_write("data/generation-id-address", addr);
> 
> data/ seems like an odd home for this, isn't that the area where
> guests can expect to store their own bits and bobs, agent stuff etc?
> 

No what data is 'for' as such. It seemed like a reasonable place to put something created by the guest and for the tools' consumption. I could move it under hvmloader, but is that the right place? hvmloader/bios is *read* by hvmloader, not written by it.

  Paul

> Although this key is going to be guest writeable (so hvmloader can
> write
> it) it really ought to be off somewhere out of the way. We select
> the bios with /local/domain/<domid>/hvmloader/bios so perhaps
> something under there or /local/domain/<domid>/platform?
> 
> (/me adds "do archaeology and document valid/best-practice xenstore
> paths to TODO list)
> 
> Ian.
> 
> >
> >      gid = strtoll(xenstore_read("platform/generation-id", "0"),
> NULL, 0);
> >      *(uint64_t *)buf = gid;
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xensource.com
> > http://lists.xensource.com/xen-devel
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 11:17:56 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 11:17:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ramq9-0001hW-RD; Wed, 14 Dec 2011 11:17:37 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1Ramq8-0001hK-KY
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 11:17:36 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1323861385!58879501!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTc4Ng==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28764 invoked from network); 14 Dec 2011 11:16:25 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Dec 2011 11:16:25 -0000
X-IronPort-AV: E=Sophos;i="4.71,351,1320624000"; 
   d="scan'208";a="9460000"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Dec 2011 11:16:43 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.161]) by
	LONPMAILMX01.citrite.net ([10.30.203.162]) with mapi; Wed, 14 Dec 2011
	11:16:43 +0000
From: Paul Durrant <Paul.Durrant@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Wed, 14 Dec 2011 11:17:02 +0000
Thread-Topic: [Xen-devel] [PATCH 1 of 2] Re-name xenstore key used to save
	VM generation ID buffer address
Thread-Index: Acy6SM19fQU7e+nCS9KXqH7l+CzJXAACIvEw
Message-ID: <291EDFCB1E9E224A99088639C4762022B5988E58B7@LONPMAILBOX01.citrite.net>
References: <patchbomb.1323855070@cosworth.uk.xensource.com>
	<fded65be5d82461e87de.1323855071@cosworth.uk.xensource.com>
	<1323857513.20077.380.camel@zakaz.uk.xensource.com>
In-Reply-To: <1323857513.20077.380.camel@zakaz.uk.xensource.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 1 of 2] Re-name xenstore key used to save VM
 generation ID buffer address
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com



> -----Original Message-----
> From: Ian Campbell
> Sent: 14 December 2011 10:12
> To: Paul Durrant
> Cc: xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] [PATCH 1 of 2] Re-name xenstore key used to
> save VM generation ID buffer address
> 
> On Wed, 2011-12-14 at 09:31 +0000, Paul Durrant wrote:
> > # HG changeset patch
> > # User Paul Durrant <paul.durrant@citrix.com> # Date 1323854952 0
> #
> > Node ID fded65be5d82461e87de54960db14ce8feb4625f
> > # Parent  03138a08366b895d79e143119d4c9c72833cdbcd
> > Re-name xenstore key used to save VM generation ID buffer address.
> >
> > Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
> >
> > diff -r 03138a08366b -r fded65be5d82
> tools/firmware/hvmloader/acpi/build.c
> > --- a/tools/firmware/hvmloader/acpi/build.c	Fri Dec 09 16:19:36
> 2011 +0000
> > +++ b/tools/firmware/hvmloader/acpi/build.c	Wed Dec 14 09:29:12
> 2011 +0000
> > @@ -309,7 +309,7 @@ unsigned long new_vm_gid(void)
> >      if ( snprintf(addr, sizeof(addr), "0x%lx", virt_to_phys(buf))
> >           >= sizeof(addr) )
> >          return 0;
> > -    xenstore_write("data/generation-id", addr);
> > +    xenstore_write("data/generation-id-address", addr);
> 
> data/ seems like an odd home for this, isn't that the area where
> guests can expect to store their own bits and bobs, agent stuff etc?
> 

No what data is 'for' as such. It seemed like a reasonable place to put something created by the guest and for the tools' consumption. I could move it under hvmloader, but is that the right place? hvmloader/bios is *read* by hvmloader, not written by it.

  Paul

> Although this key is going to be guest writeable (so hvmloader can
> write
> it) it really ought to be off somewhere out of the way. We select
> the bios with /local/domain/<domid>/hvmloader/bios so perhaps
> something under there or /local/domain/<domid>/platform?
> 
> (/me adds "do archaeology and document valid/best-practice xenstore
> paths to TODO list)
> 
> Ian.
> 
> >
> >      gid = strtoll(xenstore_read("platform/generation-id", "0"),
> NULL, 0);
> >      *(uint64_t *)buf = gid;
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xensource.com
> > http://lists.xensource.com/xen-devel
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 11:30:20 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 11:30:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ran2A-0001wk-GW; Wed, 14 Dec 2011 11:30:02 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Ran28-0001wf-Np
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 11:30:00 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1323862144!5465285!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21173 invoked from network); 14 Dec 2011 11:29:05 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-12.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Dec 2011 11:29:05 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 14 Dec 2011 11:29:04 +0000
Message-Id: <4EE8968D0200007800067AB0@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 14 Dec 2011 11:29:01 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Stefano Stabellini" <stefano.stabellini@eu.citrix.com>
References: <4EE7672902000078000674D4@nat28.tlf.novell.com>
	<alpine.DEB.2.00.1112131646150.3517@kaball-desktop>
In-Reply-To: <alpine.DEB.2.00.1112131646150.3517@kaball-desktop>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] map_domain_emuirq_pirq() imbalance with
 unmap_domain_pirq_emuirq()?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 13.12.11 at 18:16, Stefano Stabellini <stefano.stabellini@eu.citrix.com> wrote:
> --- a/xen/arch/x86/physdev.c
> +++ b/xen/arch/x86/physdev.c
> @@ -216,14 +216,16 @@ int physdev_unmap_pirq(domid_t domid, int pirq)
>      if ( ret )
>          return ret;
>  
> -    if ( is_hvm_domain(d) )
> +    if ( is_hvm_domain(d) && domain_pirq_to_emuirq(d, pirq) != IRQ_UNBOUND)
>      {
>          spin_lock(&d->event_lock);
>          ret = unmap_domain_pirq_emuirq(d, pirq);
>          spin_unlock(&d->event_lock);
> -        if ( domid == DOMID_SELF || ret )
> +        if ( ret )
>              goto free_domain;
>      }
> +    if ( domid == DOMID_SELF )
> +        goto free_domain;
>  
>      ret = -EPERM;
>      if ( !IS_PRIV_FOR(current->domain, d) )

I think this is the correct change (untested so far):

@@ -228,7 +228,8 @@ static int physdev_unmap_pirq(struct phy
     if ( is_hvm_domain(d) )
     {
         spin_lock(&d->event_lock);
-        ret = unmap_domain_pirq_emuirq(d, pirq);
+        if ( domain_pirq_to_emuirq(d, pirq) != IRQ_UNBOUND )
+            ret = unmap_domain_pirq_emuirq(d, pirq);
         spin_unlock(&d->event_lock);
         if ( unmap->domid == DOMID_SELF || ret )
             goto free_domain;

i.e. do the lookup with the lock held (and taking advantage of 'ret'
being zero when reaching the enclosing if()).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 11:30:20 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 11:30:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ran2A-0001wk-GW; Wed, 14 Dec 2011 11:30:02 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Ran28-0001wf-Np
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 11:30:00 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1323862144!5465285!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21173 invoked from network); 14 Dec 2011 11:29:05 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-12.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Dec 2011 11:29:05 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 14 Dec 2011 11:29:04 +0000
Message-Id: <4EE8968D0200007800067AB0@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 14 Dec 2011 11:29:01 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Stefano Stabellini" <stefano.stabellini@eu.citrix.com>
References: <4EE7672902000078000674D4@nat28.tlf.novell.com>
	<alpine.DEB.2.00.1112131646150.3517@kaball-desktop>
In-Reply-To: <alpine.DEB.2.00.1112131646150.3517@kaball-desktop>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] map_domain_emuirq_pirq() imbalance with
 unmap_domain_pirq_emuirq()?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 13.12.11 at 18:16, Stefano Stabellini <stefano.stabellini@eu.citrix.com> wrote:
> --- a/xen/arch/x86/physdev.c
> +++ b/xen/arch/x86/physdev.c
> @@ -216,14 +216,16 @@ int physdev_unmap_pirq(domid_t domid, int pirq)
>      if ( ret )
>          return ret;
>  
> -    if ( is_hvm_domain(d) )
> +    if ( is_hvm_domain(d) && domain_pirq_to_emuirq(d, pirq) != IRQ_UNBOUND)
>      {
>          spin_lock(&d->event_lock);
>          ret = unmap_domain_pirq_emuirq(d, pirq);
>          spin_unlock(&d->event_lock);
> -        if ( domid == DOMID_SELF || ret )
> +        if ( ret )
>              goto free_domain;
>      }
> +    if ( domid == DOMID_SELF )
> +        goto free_domain;
>  
>      ret = -EPERM;
>      if ( !IS_PRIV_FOR(current->domain, d) )

I think this is the correct change (untested so far):

@@ -228,7 +228,8 @@ static int physdev_unmap_pirq(struct phy
     if ( is_hvm_domain(d) )
     {
         spin_lock(&d->event_lock);
-        ret = unmap_domain_pirq_emuirq(d, pirq);
+        if ( domain_pirq_to_emuirq(d, pirq) != IRQ_UNBOUND )
+            ret = unmap_domain_pirq_emuirq(d, pirq);
         spin_unlock(&d->event_lock);
         if ( unmap->domid == DOMID_SELF || ret )
             goto free_domain;

i.e. do the lookup with the lock held (and taking advantage of 'ret'
being zero when reaching the enclosing if()).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 11:40:09 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 11:40:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RanBf-0002Fe-Kg; Wed, 14 Dec 2011 11:39:51 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RanBe-0002FZ-QJ
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 11:39:51 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1323862718!49241097!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTc4Ng==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29124 invoked from network); 14 Dec 2011 11:38:38 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Dec 2011 11:38:38 -0000
X-IronPort-AV: E=Sophos;i="4.71,351,1320624000"; 
   d="scan'208";a="9460562"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Dec 2011 11:38:54 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 14 Dec 2011 11:38:54 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Paul Durrant <Paul.Durrant@citrix.com>
Date: Wed, 14 Dec 2011 11:38:53 +0000
In-Reply-To: <291EDFCB1E9E224A99088639C4762022B5988E58B7@LONPMAILBOX01.citrite.net>
References: <patchbomb.1323855070@cosworth.uk.xensource.com>
	<fded65be5d82461e87de.1323855071@cosworth.uk.xensource.com>
	<1323857513.20077.380.camel@zakaz.uk.xensource.com>
	<291EDFCB1E9E224A99088639C4762022B5988E58B7@LONPMAILBOX01.citrite.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323862734.20077.396.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 1 of 2] Re-name xenstore key used to save VM
 generation ID buffer address
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2011-12-14 at 11:17 +0000, Paul Durrant wrote:
> 
> > -----Original Message-----
> > From: Ian Campbell
> > Sent: 14 December 2011 10:12
> > To: Paul Durrant
> > Cc: xen-devel@lists.xensource.com
> > Subject: Re: [Xen-devel] [PATCH 1 of 2] Re-name xenstore key used to
> > save VM generation ID buffer address
> > 
> > On Wed, 2011-12-14 at 09:31 +0000, Paul Durrant wrote:
> > > # HG changeset patch
> > > # User Paul Durrant <paul.durrant@citrix.com> # Date 1323854952 0
> > #
> > > Node ID fded65be5d82461e87de54960db14ce8feb4625f
> > > # Parent  03138a08366b895d79e143119d4c9c72833cdbcd
> > > Re-name xenstore key used to save VM generation ID buffer address.
> > >
> > > Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
> > >
> > > diff -r 03138a08366b -r fded65be5d82
> > tools/firmware/hvmloader/acpi/build.c
> > > --- a/tools/firmware/hvmloader/acpi/build.c	Fri Dec 09 16:19:36
> > 2011 +0000
> > > +++ b/tools/firmware/hvmloader/acpi/build.c	Wed Dec 14 09:29:12
> > 2011 +0000
> > > @@ -309,7 +309,7 @@ unsigned long new_vm_gid(void)
> > >      if ( snprintf(addr, sizeof(addr), "0x%lx", virt_to_phys(buf))
> > >           >= sizeof(addr) )
> > >          return 0;
> > > -    xenstore_write("data/generation-id", addr);
> > > +    xenstore_write("data/generation-id-address", addr);
> > 
> > data/ seems like an odd home for this, isn't that the area where
> > guests can expect to store their own bits and bobs, agent stuff etc?
> > 
> 
> No what data is 'for' as such. It seemed like a reasonable place to
> put something created by the guest and for the tools' consumption.

Although it runs in guest context hvmloader should really be considered
an extension of the tools and not part of the guest.

> I could move it under hvmloader, but is that the right place?
> hvmloader/bios is *read* by hvmloader, not written by it.

I think it's a good as anywhere else.

Ian.

> 
>   Paul
> 
> > Although this key is going to be guest writeable (so hvmloader can
> > write
> > it) it really ought to be off somewhere out of the way. We select
> > the bios with /local/domain/<domid>/hvmloader/bios so perhaps
> > something under there or /local/domain/<domid>/platform?
> > 
> > (/me adds "do archaeology and document valid/best-practice xenstore
> > paths to TODO list)
> > 
> > Ian.
> > 
> > >
> > >      gid = strtoll(xenstore_read("platform/generation-id", "0"),
> > NULL, 0);
> > >      *(uint64_t *)buf = gid;
> > >
> > > _______________________________________________
> > > Xen-devel mailing list
> > > Xen-devel@lists.xensource.com
> > > http://lists.xensource.com/xen-devel
> > 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 11:40:09 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 11:40:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RanBf-0002Fe-Kg; Wed, 14 Dec 2011 11:39:51 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RanBe-0002FZ-QJ
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 11:39:51 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1323862718!49241097!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTc4Ng==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29124 invoked from network); 14 Dec 2011 11:38:38 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Dec 2011 11:38:38 -0000
X-IronPort-AV: E=Sophos;i="4.71,351,1320624000"; 
   d="scan'208";a="9460562"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Dec 2011 11:38:54 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 14 Dec 2011 11:38:54 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Paul Durrant <Paul.Durrant@citrix.com>
Date: Wed, 14 Dec 2011 11:38:53 +0000
In-Reply-To: <291EDFCB1E9E224A99088639C4762022B5988E58B7@LONPMAILBOX01.citrite.net>
References: <patchbomb.1323855070@cosworth.uk.xensource.com>
	<fded65be5d82461e87de.1323855071@cosworth.uk.xensource.com>
	<1323857513.20077.380.camel@zakaz.uk.xensource.com>
	<291EDFCB1E9E224A99088639C4762022B5988E58B7@LONPMAILBOX01.citrite.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323862734.20077.396.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 1 of 2] Re-name xenstore key used to save VM
 generation ID buffer address
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2011-12-14 at 11:17 +0000, Paul Durrant wrote:
> 
> > -----Original Message-----
> > From: Ian Campbell
> > Sent: 14 December 2011 10:12
> > To: Paul Durrant
> > Cc: xen-devel@lists.xensource.com
> > Subject: Re: [Xen-devel] [PATCH 1 of 2] Re-name xenstore key used to
> > save VM generation ID buffer address
> > 
> > On Wed, 2011-12-14 at 09:31 +0000, Paul Durrant wrote:
> > > # HG changeset patch
> > > # User Paul Durrant <paul.durrant@citrix.com> # Date 1323854952 0
> > #
> > > Node ID fded65be5d82461e87de54960db14ce8feb4625f
> > > # Parent  03138a08366b895d79e143119d4c9c72833cdbcd
> > > Re-name xenstore key used to save VM generation ID buffer address.
> > >
> > > Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
> > >
> > > diff -r 03138a08366b -r fded65be5d82
> > tools/firmware/hvmloader/acpi/build.c
> > > --- a/tools/firmware/hvmloader/acpi/build.c	Fri Dec 09 16:19:36
> > 2011 +0000
> > > +++ b/tools/firmware/hvmloader/acpi/build.c	Wed Dec 14 09:29:12
> > 2011 +0000
> > > @@ -309,7 +309,7 @@ unsigned long new_vm_gid(void)
> > >      if ( snprintf(addr, sizeof(addr), "0x%lx", virt_to_phys(buf))
> > >           >= sizeof(addr) )
> > >          return 0;
> > > -    xenstore_write("data/generation-id", addr);
> > > +    xenstore_write("data/generation-id-address", addr);
> > 
> > data/ seems like an odd home for this, isn't that the area where
> > guests can expect to store their own bits and bobs, agent stuff etc?
> > 
> 
> No what data is 'for' as such. It seemed like a reasonable place to
> put something created by the guest and for the tools' consumption.

Although it runs in guest context hvmloader should really be considered
an extension of the tools and not part of the guest.

> I could move it under hvmloader, but is that the right place?
> hvmloader/bios is *read* by hvmloader, not written by it.

I think it's a good as anywhere else.

Ian.

> 
>   Paul
> 
> > Although this key is going to be guest writeable (so hvmloader can
> > write
> > it) it really ought to be off somewhere out of the way. We select
> > the bios with /local/domain/<domid>/hvmloader/bios so perhaps
> > something under there or /local/domain/<domid>/platform?
> > 
> > (/me adds "do archaeology and document valid/best-practice xenstore
> > paths to TODO list)
> > 
> > Ian.
> > 
> > >
> > >      gid = strtoll(xenstore_read("platform/generation-id", "0"),
> > NULL, 0);
> > >      *(uint64_t *)buf = gid;
> > >
> > > _______________________________________________
> > > Xen-devel mailing list
> > > Xen-devel@lists.xensource.com
> > > http://lists.xensource.com/xen-devel
> > 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 11:50:21 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 11:50:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RanLQ-0002PQ-Nx; Wed, 14 Dec 2011 11:49:56 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RanLP-0002PK-Df
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 11:49:55 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1323863339!7161284!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTc4Ng==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7559 invoked from network); 14 Dec 2011 11:49:00 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Dec 2011 11:49:00 -0000
X-IronPort-AV: E=Sophos;i="4.71,351,1320624000"; 
   d="scan'208";a="9460766"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Dec 2011 11:48:53 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.161]) by
	LONPMAILMX01.citrite.net ([10.30.203.162]) with mapi; Wed, 14 Dec 2011
	11:48:53 +0000
From: Paul Durrant <Paul.Durrant@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Wed, 14 Dec 2011 11:49:12 +0000
Thread-Topic: [Xen-devel] [PATCH 1 of 2] Re-name xenstore key used to save
	VM generation ID buffer address
Thread-Index: Acy6VPWGmFcOnhy9QROCbh29tEI6HwAAN/Qg
Message-ID: <291EDFCB1E9E224A99088639C4762022B598ED0D72@LONPMAILBOX01.citrite.net>
References: <patchbomb.1323855070@cosworth.uk.xensource.com>
	<fded65be5d82461e87de.1323855071@cosworth.uk.xensource.com>
	<1323857513.20077.380.camel@zakaz.uk.xensource.com>
	<291EDFCB1E9E224A99088639C4762022B5988E58B7@LONPMAILBOX01.citrite.net>
	<1323862734.20077.396.camel@zakaz.uk.xensource.com>
In-Reply-To: <1323862734.20077.396.camel@zakaz.uk.xensource.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 1 of 2] Re-name xenstore key used to save VM
 generation ID buffer address
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> -----Original Message-----
> From: Ian Campbell
> Sent: 14 December 2011 11:39
> To: Paul Durrant
> Cc: xen-devel@lists.xensource.com
> Subject: RE: [Xen-devel] [PATCH 1 of 2] Re-name xenstore key used to
> save VM generation ID buffer address
> 
> On Wed, 2011-12-14 at 11:17 +0000, Paul Durrant wrote:
> >
> > > -----Original Message-----
> > > From: Ian Campbell
> > > Sent: 14 December 2011 10:12
> > > To: Paul Durrant
> > > Cc: xen-devel@lists.xensource.com
> > > Subject: Re: [Xen-devel] [PATCH 1 of 2] Re-name xenstore key
> used to
> > > save VM generation ID buffer address
> > >
> > > On Wed, 2011-12-14 at 09:31 +0000, Paul Durrant wrote:
> > > > # HG changeset patch
> > > > # User Paul Durrant <paul.durrant@citrix.com> # Date
> 1323854952 0
> > > #
> > > > Node ID fded65be5d82461e87de54960db14ce8feb4625f
> > > > # Parent  03138a08366b895d79e143119d4c9c72833cdbcd
> > > > Re-name xenstore key used to save VM generation ID buffer
> address.
> > > >
> > > > Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
> > > >
> > > > diff -r 03138a08366b -r fded65be5d82
> > > tools/firmware/hvmloader/acpi/build.c
> > > > --- a/tools/firmware/hvmloader/acpi/build.c	Fri Dec 09
> 16:19:36
> > > 2011 +0000
> > > > +++ b/tools/firmware/hvmloader/acpi/build.c	Wed Dec 14
> 09:29:12
> > > 2011 +0000
> > > > @@ -309,7 +309,7 @@ unsigned long new_vm_gid(void)
> > > >      if ( snprintf(addr, sizeof(addr), "0x%lx",
> virt_to_phys(buf))
> > > >           >= sizeof(addr) )
> > > >          return 0;
> > > > -    xenstore_write("data/generation-id", addr);
> > > > +    xenstore_write("data/generation-id-address", addr);
> > >
> > > data/ seems like an odd home for this, isn't that the area where
> > > guests can expect to store their own bits and bobs, agent stuff
> etc?
> > >
> >
> > No what data is 'for' as such. It seemed like a reasonable place
> to
> > put something created by the guest and for the tools' consumption.
> 
> Although it runs in guest context hvmloader should really be
> considered an extension of the tools and not part of the guest.
> 
> > I could move it under hvmloader, but is that the right place?
> > hvmloader/bios is *read* by hvmloader, not written by it.
> 
> I think it's a good as anywhere else.
> 

Ok, does that mean that we should create hmvloader as writable by the guest, or should we special-case the generation-id-address key?

  Paul
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 11:50:21 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 11:50:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RanLQ-0002PQ-Nx; Wed, 14 Dec 2011 11:49:56 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RanLP-0002PK-Df
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 11:49:55 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1323863339!7161284!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTc4Ng==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7559 invoked from network); 14 Dec 2011 11:49:00 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Dec 2011 11:49:00 -0000
X-IronPort-AV: E=Sophos;i="4.71,351,1320624000"; 
   d="scan'208";a="9460766"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Dec 2011 11:48:53 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.161]) by
	LONPMAILMX01.citrite.net ([10.30.203.162]) with mapi; Wed, 14 Dec 2011
	11:48:53 +0000
From: Paul Durrant <Paul.Durrant@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Wed, 14 Dec 2011 11:49:12 +0000
Thread-Topic: [Xen-devel] [PATCH 1 of 2] Re-name xenstore key used to save
	VM generation ID buffer address
Thread-Index: Acy6VPWGmFcOnhy9QROCbh29tEI6HwAAN/Qg
Message-ID: <291EDFCB1E9E224A99088639C4762022B598ED0D72@LONPMAILBOX01.citrite.net>
References: <patchbomb.1323855070@cosworth.uk.xensource.com>
	<fded65be5d82461e87de.1323855071@cosworth.uk.xensource.com>
	<1323857513.20077.380.camel@zakaz.uk.xensource.com>
	<291EDFCB1E9E224A99088639C4762022B5988E58B7@LONPMAILBOX01.citrite.net>
	<1323862734.20077.396.camel@zakaz.uk.xensource.com>
In-Reply-To: <1323862734.20077.396.camel@zakaz.uk.xensource.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 1 of 2] Re-name xenstore key used to save VM
 generation ID buffer address
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> -----Original Message-----
> From: Ian Campbell
> Sent: 14 December 2011 11:39
> To: Paul Durrant
> Cc: xen-devel@lists.xensource.com
> Subject: RE: [Xen-devel] [PATCH 1 of 2] Re-name xenstore key used to
> save VM generation ID buffer address
> 
> On Wed, 2011-12-14 at 11:17 +0000, Paul Durrant wrote:
> >
> > > -----Original Message-----
> > > From: Ian Campbell
> > > Sent: 14 December 2011 10:12
> > > To: Paul Durrant
> > > Cc: xen-devel@lists.xensource.com
> > > Subject: Re: [Xen-devel] [PATCH 1 of 2] Re-name xenstore key
> used to
> > > save VM generation ID buffer address
> > >
> > > On Wed, 2011-12-14 at 09:31 +0000, Paul Durrant wrote:
> > > > # HG changeset patch
> > > > # User Paul Durrant <paul.durrant@citrix.com> # Date
> 1323854952 0
> > > #
> > > > Node ID fded65be5d82461e87de54960db14ce8feb4625f
> > > > # Parent  03138a08366b895d79e143119d4c9c72833cdbcd
> > > > Re-name xenstore key used to save VM generation ID buffer
> address.
> > > >
> > > > Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
> > > >
> > > > diff -r 03138a08366b -r fded65be5d82
> > > tools/firmware/hvmloader/acpi/build.c
> > > > --- a/tools/firmware/hvmloader/acpi/build.c	Fri Dec 09
> 16:19:36
> > > 2011 +0000
> > > > +++ b/tools/firmware/hvmloader/acpi/build.c	Wed Dec 14
> 09:29:12
> > > 2011 +0000
> > > > @@ -309,7 +309,7 @@ unsigned long new_vm_gid(void)
> > > >      if ( snprintf(addr, sizeof(addr), "0x%lx",
> virt_to_phys(buf))
> > > >           >= sizeof(addr) )
> > > >          return 0;
> > > > -    xenstore_write("data/generation-id", addr);
> > > > +    xenstore_write("data/generation-id-address", addr);
> > >
> > > data/ seems like an odd home for this, isn't that the area where
> > > guests can expect to store their own bits and bobs, agent stuff
> etc?
> > >
> >
> > No what data is 'for' as such. It seemed like a reasonable place
> to
> > put something created by the guest and for the tools' consumption.
> 
> Although it runs in guest context hvmloader should really be
> considered an extension of the tools and not part of the guest.
> 
> > I could move it under hvmloader, but is that the right place?
> > hvmloader/bios is *read* by hvmloader, not written by it.
> 
> I think it's a good as anywhere else.
> 

Ok, does that mean that we should create hmvloader as writable by the guest, or should we special-case the generation-id-address key?

  Paul
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 11:55:31 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 11:55:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RanQW-0002YO-Fu; Wed, 14 Dec 2011 11:55:12 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RanQU-0002YI-G6
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 11:55:10 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1323863610!57252501!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTc4Ng==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29542 invoked from network); 14 Dec 2011 11:53:31 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Dec 2011 11:53:31 -0000
X-IronPort-AV: E=Sophos;i="4.71,351,1320624000"; 
   d="scan'208";a="9460888"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Dec 2011 11:54:19 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 14 Dec 2011 11:54:19 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RanPf-0005sc-6S; Wed, 14 Dec 2011 11:54:19 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RanPf-0004xO-5O;
	Wed, 14 Dec 2011 11:54:19 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20200.36458.940679.842443@mariner.uk.xensource.com>
Date: Wed, 14 Dec 2011 11:54:18 +0000
To: Roger Pau =?iso-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
In-Reply-To: <CAPLaKK6wqa+VAxgzLWudQ2C2kaoXww9KK3BQhU4fKmoCAMFCzQ@mail.gmail.com>
References: <patchbomb.1323768375@loki.upc.es>
	<35c322e6020501447936.1323768387@loki.upc.es>
	<20199.26896.928532.781947@mariner.uk.xensource.com>
	<CAPLaKK6wqa+VAxgzLWudQ2C2kaoXww9KK3BQhU4fKmoCAMFCzQ@mail.gmail.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 12 of 14 v4] libxl: set frontend status to 6
 on domain destroy
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Roger Pau Monn=E9 writes ("Re: [Xen-devel] [PATCH 12 of 14 v4] libxl: set f=
rontend status to 6 on domain destroy"):
> 2011/12/13 Ian Jackson <Ian.Jackson@eu.citrix.com>:
> > So here, the kernel or backendd start racing, and you hope that they
> > win the race and close the device before ...
> =

> From my experience in NetBSD, the kernel only closes the device when
> it's frontend state is set to 6, since we destroy the domain, it is
> unable to set the status to 6, and thus the kernel doesn't detach the
> devices.

This is no good, because you need to be able to force unplug a device
without guest cooperation, and the frontend state is controlled by the
guest.  So I think there is a NetBSD kernel bug in this area.

It needs to be possible to tell the backend to shut down without
regard to the frontend state.

> I've added some libxl__wait_for_device_state logic here, to
> assure the backend state is set to 6 before trying to execute hotplug
> scripts. The truth is that I had it in previous versions of my patch,
> but it seems the kernel always switches contexts and detaches the
> devices before executing hotplug scripts (it might just be luck).

Well that's very nice but of course not reliable.

> Also this patch speeds domain destruction a lot (which is also quite
> slow under Linux from what I saw).

You're saying that not waiting for the backends to close speeds up
domain destruction ?  Where is the time going ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 11:55:31 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 11:55:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RanQW-0002YO-Fu; Wed, 14 Dec 2011 11:55:12 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RanQU-0002YI-G6
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 11:55:10 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1323863610!57252501!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTc4Ng==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29542 invoked from network); 14 Dec 2011 11:53:31 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Dec 2011 11:53:31 -0000
X-IronPort-AV: E=Sophos;i="4.71,351,1320624000"; 
   d="scan'208";a="9460888"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Dec 2011 11:54:19 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 14 Dec 2011 11:54:19 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RanPf-0005sc-6S; Wed, 14 Dec 2011 11:54:19 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RanPf-0004xO-5O;
	Wed, 14 Dec 2011 11:54:19 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20200.36458.940679.842443@mariner.uk.xensource.com>
Date: Wed, 14 Dec 2011 11:54:18 +0000
To: Roger Pau =?iso-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
In-Reply-To: <CAPLaKK6wqa+VAxgzLWudQ2C2kaoXww9KK3BQhU4fKmoCAMFCzQ@mail.gmail.com>
References: <patchbomb.1323768375@loki.upc.es>
	<35c322e6020501447936.1323768387@loki.upc.es>
	<20199.26896.928532.781947@mariner.uk.xensource.com>
	<CAPLaKK6wqa+VAxgzLWudQ2C2kaoXww9KK3BQhU4fKmoCAMFCzQ@mail.gmail.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 12 of 14 v4] libxl: set frontend status to 6
 on domain destroy
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Roger Pau Monn=E9 writes ("Re: [Xen-devel] [PATCH 12 of 14 v4] libxl: set f=
rontend status to 6 on domain destroy"):
> 2011/12/13 Ian Jackson <Ian.Jackson@eu.citrix.com>:
> > So here, the kernel or backendd start racing, and you hope that they
> > win the race and close the device before ...
> =

> From my experience in NetBSD, the kernel only closes the device when
> it's frontend state is set to 6, since we destroy the domain, it is
> unable to set the status to 6, and thus the kernel doesn't detach the
> devices.

This is no good, because you need to be able to force unplug a device
without guest cooperation, and the frontend state is controlled by the
guest.  So I think there is a NetBSD kernel bug in this area.

It needs to be possible to tell the backend to shut down without
regard to the frontend state.

> I've added some libxl__wait_for_device_state logic here, to
> assure the backend state is set to 6 before trying to execute hotplug
> scripts. The truth is that I had it in previous versions of my patch,
> but it seems the kernel always switches contexts and detaches the
> devices before executing hotplug scripts (it might just be luck).

Well that's very nice but of course not reliable.

> Also this patch speeds domain destruction a lot (which is also quite
> slow under Linux from what I saw).

You're saying that not waiting for the backends to close speeds up
domain destruction ?  Where is the time going ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 11:56:54 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 11:56:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RanRq-0002cW-Vl; Wed, 14 Dec 2011 11:56:34 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RanRp-0002c9-Jf
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 11:56:33 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1323863737!7421999!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTc4Ng==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7050 invoked from network); 14 Dec 2011 11:55:38 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Dec 2011 11:55:38 -0000
X-IronPort-AV: E=Sophos;i="4.71,351,1320624000"; 
   d="scan'208";a="9460923"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Dec 2011 11:55:36 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 14 Dec 2011 11:55:36 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RanQu-0005t7-7Z; Wed, 14 Dec 2011 11:55:36 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RanQu-0004xY-6V;
	Wed, 14 Dec 2011 11:55:36 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20200.36536.187256.61611@mariner.uk.xensource.com>
Date: Wed, 14 Dec 2011 11:55:36 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1323855739.20077.365.camel@zakaz.uk.xensource.com>
References: <alpine.DEB.2.00.1111221551510.31179@kaball-desktop>
	<1322056320-5826-5-git-send-email-stefano.stabellini@eu.citrix.com>
	<20198.15417.932169.223332@mariner.uk.xensource.com>
	<1323712001.20077.234.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1112121924520.3517@kaball-desktop>
	<20199.24118.465585.933183@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1112131720250.3517@kaball-desktop>
	<20199.37117.779165.894809@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1112131817300.3517@kaball-desktop>
	<1323855739.20077.365.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Keir
	\(Xen.org\)" <keir@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v9 5/6] Clone and build Seabios by default
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("Re: [Xen-devel] [PATCH v9 5/6] Clone and build Seabios by default"):
> Unfortunately I expect that distros will want to package qemu once (from
> upstream) with support for all the various options, including Xen,
> enabled and depend on that in their Xen packaging rather than packaging
> a slightly different qemu a second time.

Quite.

> I'm not sure how we can address this without exploding our test matrix.
> It seems like we need to test at a minimum the current qemu stable and
> development branches :-/

This is no different to the kernel, of course.  We don't do a very
good job of testing different upstream kernels but it's on my todo
list.

> > I don't have an opinion on seabios because I am nore sure how many
> > changes are we going to make to it. However I recall that you and/or
> > IanC were in favor of having or own branch of seabios as well.
> 
> I think that even if we never diverge from upstream and irrespective of
> whether we stick in lockstep or not we should host a tree to point our
> users (and default build) at. This gives us flexibility if we ever do
> need to diverge and also isolates our users from issues with 3rd party
> servers.

Indeed so.  But should it be one tree for each Xen branch, and does it
need a push gate ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 11:56:54 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 11:56:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RanRq-0002cW-Vl; Wed, 14 Dec 2011 11:56:34 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RanRp-0002c9-Jf
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 11:56:33 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1323863737!7421999!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTc4Ng==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7050 invoked from network); 14 Dec 2011 11:55:38 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Dec 2011 11:55:38 -0000
X-IronPort-AV: E=Sophos;i="4.71,351,1320624000"; 
   d="scan'208";a="9460923"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Dec 2011 11:55:36 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 14 Dec 2011 11:55:36 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RanQu-0005t7-7Z; Wed, 14 Dec 2011 11:55:36 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RanQu-0004xY-6V;
	Wed, 14 Dec 2011 11:55:36 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20200.36536.187256.61611@mariner.uk.xensource.com>
Date: Wed, 14 Dec 2011 11:55:36 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1323855739.20077.365.camel@zakaz.uk.xensource.com>
References: <alpine.DEB.2.00.1111221551510.31179@kaball-desktop>
	<1322056320-5826-5-git-send-email-stefano.stabellini@eu.citrix.com>
	<20198.15417.932169.223332@mariner.uk.xensource.com>
	<1323712001.20077.234.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1112121924520.3517@kaball-desktop>
	<20199.24118.465585.933183@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1112131720250.3517@kaball-desktop>
	<20199.37117.779165.894809@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1112131817300.3517@kaball-desktop>
	<1323855739.20077.365.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Keir
	\(Xen.org\)" <keir@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v9 5/6] Clone and build Seabios by default
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("Re: [Xen-devel] [PATCH v9 5/6] Clone and build Seabios by default"):
> Unfortunately I expect that distros will want to package qemu once (from
> upstream) with support for all the various options, including Xen,
> enabled and depend on that in their Xen packaging rather than packaging
> a slightly different qemu a second time.

Quite.

> I'm not sure how we can address this without exploding our test matrix.
> It seems like we need to test at a minimum the current qemu stable and
> development branches :-/

This is no different to the kernel, of course.  We don't do a very
good job of testing different upstream kernels but it's on my todo
list.

> > I don't have an opinion on seabios because I am nore sure how many
> > changes are we going to make to it. However I recall that you and/or
> > IanC were in favor of having or own branch of seabios as well.
> 
> I think that even if we never diverge from upstream and irrespective of
> whether we stick in lockstep or not we should host a tree to point our
> users (and default build) at. This gives us flexibility if we ever do
> need to diverge and also isolates our users from issues with 3rd party
> servers.

Indeed so.  But should it be one tree for each Xen branch, and does it
need a push gate ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 11:59:21 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 11: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.xensource.com>)
	id 1RanUC-0002mL-Hj; Wed, 14 Dec 2011 11:59:00 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RanUB-0002lk-HA
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 11:58:59 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1323863884!6233107!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTc4Ng==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21577 invoked from network); 14 Dec 2011 11:58:04 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Dec 2011 11:58:04 -0000
X-IronPort-AV: E=Sophos;i="4.71,351,1320624000"; 
   d="scan'208";a="9460993"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Dec 2011 11:58:04 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 14 Dec 2011 11:58:04 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RanTH-0005tv-Kv; Wed, 14 Dec 2011 11:58:03 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RanTH-0004xo-Jr;
	Wed, 14 Dec 2011 11:58:03 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20200.36683.601224.172611@mariner.uk.xensource.com>
Date: Wed, 14 Dec 2011 11:58:03 +0000
To: Roger Pau =?iso-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
In-Reply-To: <CAPLaKK7Wv2HeRbg5Ze=B8DFe=wbzq=V35s6WVFXqrynh0ikRTw@mail.gmail.com>
References: <patchbomb.1323768375@loki.upc.es>
	<35c322e6020501447936.1323768387@loki.upc.es>
	<20199.26896.928532.781947@mariner.uk.xensource.com>
	<CAPLaKK6wqa+VAxgzLWudQ2C2kaoXww9KK3BQhU4fKmoCAMFCzQ@mail.gmail.com>
	<1323860097.20077.394.camel@zakaz.uk.xensource.com>
	<CAPLaKK7Wv2HeRbg5Ze=B8DFe=wbzq=V35s6WVFXqrynh0ikRTw@mail.gmail.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH 12 of 14 v4] libxl: set frontend status to 6
 on domain destroy
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Roger Pau Monn=E9 writes ("Re: [Xen-devel] [PATCH 12 of 14 v4] libxl: set f=
rontend status to 6 on domain destroy"):
> 2011/12/14 Ian Campbell <Ian.Campbell@citrix.com>:
> > So if you rm the backend directory the NetBSD does not take that as a
> > sign to tear down the device? That sounds like a bug in the NetBSD
> > backend -- it should treat deletion of the backend state dir as if it
> > were reading state =3D "6" and shut everything down.
> =

> Yes, if I delete the frontend from xenstore, the devices are detached.
> Anyway, doing it one way or another (deletion or setting state to 6)
> doesn't really make a difference, you still have to wait for the
> backend to be disconnected (detached) before executing hotplug
> scripts.

So device destruction could be achieved by simply deleting the backend
directory.  But, we would need some other way to detect when the
backend has actually closed the device so that we can run the script.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 11:59:21 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 11: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.xensource.com>)
	id 1RanUC-0002mL-Hj; Wed, 14 Dec 2011 11:59:00 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RanUB-0002lk-HA
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 11:58:59 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1323863884!6233107!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTc4Ng==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21577 invoked from network); 14 Dec 2011 11:58:04 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Dec 2011 11:58:04 -0000
X-IronPort-AV: E=Sophos;i="4.71,351,1320624000"; 
   d="scan'208";a="9460993"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Dec 2011 11:58:04 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 14 Dec 2011 11:58:04 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RanTH-0005tv-Kv; Wed, 14 Dec 2011 11:58:03 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RanTH-0004xo-Jr;
	Wed, 14 Dec 2011 11:58:03 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20200.36683.601224.172611@mariner.uk.xensource.com>
Date: Wed, 14 Dec 2011 11:58:03 +0000
To: Roger Pau =?iso-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
In-Reply-To: <CAPLaKK7Wv2HeRbg5Ze=B8DFe=wbzq=V35s6WVFXqrynh0ikRTw@mail.gmail.com>
References: <patchbomb.1323768375@loki.upc.es>
	<35c322e6020501447936.1323768387@loki.upc.es>
	<20199.26896.928532.781947@mariner.uk.xensource.com>
	<CAPLaKK6wqa+VAxgzLWudQ2C2kaoXww9KK3BQhU4fKmoCAMFCzQ@mail.gmail.com>
	<1323860097.20077.394.camel@zakaz.uk.xensource.com>
	<CAPLaKK7Wv2HeRbg5Ze=B8DFe=wbzq=V35s6WVFXqrynh0ikRTw@mail.gmail.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH 12 of 14 v4] libxl: set frontend status to 6
 on domain destroy
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Roger Pau Monn=E9 writes ("Re: [Xen-devel] [PATCH 12 of 14 v4] libxl: set f=
rontend status to 6 on domain destroy"):
> 2011/12/14 Ian Campbell <Ian.Campbell@citrix.com>:
> > So if you rm the backend directory the NetBSD does not take that as a
> > sign to tear down the device? That sounds like a bug in the NetBSD
> > backend -- it should treat deletion of the backend state dir as if it
> > were reading state =3D "6" and shut everything down.
> =

> Yes, if I delete the frontend from xenstore, the devices are detached.
> Anyway, doing it one way or another (deletion or setting state to 6)
> doesn't really make a difference, you still have to wait for the
> backend to be disconnected (detached) before executing hotplug
> scripts.

So device destruction could be achieved by simply deleting the backend
directory.  But, we would need some other way to detect when the
backend has actually closed the device so that we can run the script.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 12:00:08 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 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.xensource.com>)
	id 1RanV3-0002qs-0K; Wed, 14 Dec 2011 11:59:53 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RanV0-0002qH-0q
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 11:59:50 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1323863934!7233484!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTc4Ng==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5528 invoked from network); 14 Dec 2011 11:58:54 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Dec 2011 11:58:54 -0000
X-IronPort-AV: E=Sophos;i="4.71,351,1320624000"; 
   d="scan'208";a="9461003"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Dec 2011 11:58:34 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 14 Dec 2011 11:58:34 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau =?ISO-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
Date: Wed, 14 Dec 2011 11:58:34 +0000
In-Reply-To: <CAPLaKK7Wv2HeRbg5Ze=B8DFe=wbzq=V35s6WVFXqrynh0ikRTw@mail.gmail.com>
References: <patchbomb.1323768375@loki.upc.es>
	<35c322e6020501447936.1323768387@loki.upc.es>
	<20199.26896.928532.781947@mariner.uk.xensource.com>
	<CAPLaKK6wqa+VAxgzLWudQ2C2kaoXww9KK3BQhU4fKmoCAMFCzQ@mail.gmail.com>
	<1323860097.20077.394.camel@zakaz.uk.xensource.com>
	<CAPLaKK7Wv2HeRbg5Ze=B8DFe=wbzq=V35s6WVFXqrynh0ikRTw@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323863914.20077.400.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 12 of 14 v4] libxl: set frontend status to 6
 on domain destroy
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gV2VkLCAyMDExLTEyLTE0IGF0IDExOjEyICswMDAwLCBSb2dlciBQYXUgTW9ubsOpIHdyb3Rl
Ogo+IDIwMTEvMTIvMTQgSWFuIENhbXBiZWxsIDxJYW4uQ2FtcGJlbGxAY2l0cml4LmNvbT46Cj4g
PiBTbyBpZiB5b3Ugcm0gdGhlIGJhY2tlbmQgZGlyZWN0b3J5IHRoZSBOZXRCU0QgZG9lcyBub3Qg
dGFrZSB0aGF0IGFzIGEKPiA+IHNpZ24gdG8gdGVhciBkb3duIHRoZSBkZXZpY2U/IFRoYXQgc291
bmRzIGxpa2UgYSBidWcgaW4gdGhlIE5ldEJTRAo+ID4gYmFja2VuZCAtLSBpdCBzaG91bGQgdHJl
YXQgZGVsZXRpb24gb2YgdGhlIGJhY2tlbmQgc3RhdGUgZGlyIGFzIGlmIGl0Cj4gPiB3ZXJlIHJl
YWRpbmcgc3RhdGUgPSAiNiIgYW5kIHNodXQgZXZlcnl0aGluZyBkb3duLgo+IAo+IFllcywgaWYg
SSBkZWxldGUgdGhlIGZyb250ZW5kIGZyb20geGVuc3RvcmUsIHRoZSBkZXZpY2VzIGFyZSBkZXRh
Y2hlZC4KPiBBbnl3YXksIGRvaW5nIGl0IG9uZSB3YXkgb3IgYW5vdGhlciAoZGVsZXRpb24gb3Ig
c2V0dGluZyBzdGF0ZSB0byA2KQo+IGRvZXNuJ3QgcmVhbGx5IG1ha2UgYSBkaWZmZXJlbmNlLCB5
b3Ugc3RpbGwgaGF2ZSB0byB3YWl0IGZvciB0aGUKPiBiYWNrZW5kIHRvIGJlIGRpc2Nvbm5lY3Rl
ZCAoZGV0YWNoZWQpIGJlZm9yZSBleGVjdXRpbmcgaG90cGx1Zwo+IHNjcmlwdHMuCgpSaWdodC4g
VGhpcyBtaWdodCBhY3R1YWxseSBiZSB0cmlja3kgaW4gdGhlIGNhc2Ugd2hlcmUgdGhlIGJhY2tl
bmQgZGlyCmhhcyBiZWVuIHJlbW92ZWQgc2luY2UgSSBleHBlY3QgdGhlcmUgd2lsbCBiZSBub3do
ZXJlIGVsc2Ugd2hpY2gKaW5kaWNhdGVzIHRoaXMuCgo+ID4gT3IgaXMgdGhlIGlzc3VlIG9ubHkg
aW4gdGhlIHVzZXJzcGFjZSBwb3J0aW9ucz8KPiA+Cj4gPj4gIEkndmUgYWRkZWQgc29tZSBsaWJ4
bF9fd2FpdF9mb3JfZGV2aWNlX3N0YXRlIGxvZ2ljIGhlcmUsIHRvCj4gPj4gYXNzdXJlIHRoZSBi
YWNrZW5kIHN0YXRlIGlzIHNldCB0byA2IGJlZm9yZSB0cnlpbmcgdG8gZXhlY3V0ZSBob3RwbHVn
Cj4gPj4gc2NyaXB0cy4KPiA+Cj4gPiBCdXQgdGhhdCB3aWxsIGFsd2F5cyBiZSB0cnVlIHdpdGgg
dGhpcyBwYXRjaCBzaW5jZSB5b3Ugc2V0IGl0IHRoYXQgd2F5Cj4gPiBqdXN0IGJlZm9yZSwgcmln
aHQ/Cj4gCj4gSSBzZXQgZnJvbnRlbmQgc3RhdHVzIHRvIDYsIGFuZCBJIHN1Z2dlc3QgdG8gd2Fp
dCBmb3IgYmFja2VuZCBzdGF0dXMKPiB0byBiZSA2IGFsc28sIHRoZW4gZXhlY3V0ZSBob3RwbHVn
IHNjcmlwdHMuIEl0IHdvbid0IGJlIHRydWUsIGJlY2F1c2UKPiBmcm9udGVuZCBhbmQgYmFja2Vu
ZCBzdGF0dXMgYXJlIG5vdCB0aWVkIChpbiB0aGUgTmV0QlNEIGNhc2UgYmFja2VuZAo+IHN0YXR1
cyBpcyBzZXQgYnkgdGhlIERvbTAga2VybmVsIG9yIGhvdHBsdWcgc2NyaXB0cywgd2hpbGUgZnJv
bnRlbmQKPiBzdGF0dXMgaXMgc2V0IGJ5IHRoZSBEb21VKS4KCkkgdGhpbmsgKGJ1dCBJJ20gbm90
IHN1cmUpIHRoYXQgaXQgaXMgbm90IHBlcm1pc3NpYmxlIGZvciB0aGUgdG9vbHN0YWNrCnRvIG1l
c3Mgd2l0aCB0aGUgZnJvbnRlbmQgc3RhdGUgbGlrZSB0aGF0LgoKPiA+IElmIHlvdSBnbyBkb3du
IHRoaXMgcGF0aCB0aGVuIEkgdGhpbmsgeW91IG5lZWQgdG8gc2V0IHRoZSBzdGF0ZSB0bwo+ID4g
IjUiIChDbG9zaW5nKSBpbiBvcmRlciB0byBwcm9tcHQgdGhlIGJhY2tlbmQgdG8gdHJhbnNpdGlv
biB0bwo+ID4gIjYiIChDbG9zZWQpIGl0c2VsZi4gSG93ZXZlciB5b3UgbmVlZCB0byBiZSBjYXJl
ZnVsIGFib3V0IGFkZGluZyBhCj4gPiBzeW5jaHJvbm91cyB3YWl0IHRvIHRoZSBkZXZpY2UgZGVz
dHJveSBmdW5jdGlvbi4gVGhpcyBzaG91bGQgZXZlbnR1YWxseQo+ID4gd29yayBldmVuIGlmIHRo
ZSBmcm9udGVuZCBhbmQgYmFja2VuZCBhcmUgbm90IGNvLW9wZXJhdGluZy4gVGhhdCBzdGFydHMK
PiA+IHRvIGxvb2sgYSBiaXQgbGlrZSBjYWxsaW5nIGxpYnhsX19kZXZpY2VfcmVtb3ZlIGluc3Rl
YWQuCj4gCj4gRG8geW91IG1lYW4gdG8gc2V0IGJhY2tlbmQgc3RhdHVzIHRvIDUgaW5zdGVhZCBv
ZiBzZXR0aW5nIGZyb250ZW5kIHRvCj4gNiwgYW5kIHRoZW4gd2FpdCBmb3IgdGhlIGtlcm5lbCB0
byBkbyB0aGUgdHJhbnNpdGlvbiBmcm9tIDUgdG8gNiwKPiBpbnN0ZWFkIG9mIHNldHRpbmcgdGhl
IGZyb250ZW5kIHRvIDY/CgpZZXMuCgpJYW4uCgoKCl9fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxp
c3RzLnhlbnNvdXJjZS5jb20KaHR0cDovL2xpc3RzLnhlbnNvdXJjZS5jb20veGVuLWRldmVsCg==

From xen-devel-bounces@lists.xensource.com Wed Dec 14 12:00:08 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 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.xensource.com>)
	id 1RanV3-0002qs-0K; Wed, 14 Dec 2011 11:59:53 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RanV0-0002qH-0q
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 11:59:50 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1323863934!7233484!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTc4Ng==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5528 invoked from network); 14 Dec 2011 11:58:54 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Dec 2011 11:58:54 -0000
X-IronPort-AV: E=Sophos;i="4.71,351,1320624000"; 
   d="scan'208";a="9461003"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Dec 2011 11:58:34 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 14 Dec 2011 11:58:34 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau =?ISO-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
Date: Wed, 14 Dec 2011 11:58:34 +0000
In-Reply-To: <CAPLaKK7Wv2HeRbg5Ze=B8DFe=wbzq=V35s6WVFXqrynh0ikRTw@mail.gmail.com>
References: <patchbomb.1323768375@loki.upc.es>
	<35c322e6020501447936.1323768387@loki.upc.es>
	<20199.26896.928532.781947@mariner.uk.xensource.com>
	<CAPLaKK6wqa+VAxgzLWudQ2C2kaoXww9KK3BQhU4fKmoCAMFCzQ@mail.gmail.com>
	<1323860097.20077.394.camel@zakaz.uk.xensource.com>
	<CAPLaKK7Wv2HeRbg5Ze=B8DFe=wbzq=V35s6WVFXqrynh0ikRTw@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323863914.20077.400.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 12 of 14 v4] libxl: set frontend status to 6
 on domain destroy
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gV2VkLCAyMDExLTEyLTE0IGF0IDExOjEyICswMDAwLCBSb2dlciBQYXUgTW9ubsOpIHdyb3Rl
Ogo+IDIwMTEvMTIvMTQgSWFuIENhbXBiZWxsIDxJYW4uQ2FtcGJlbGxAY2l0cml4LmNvbT46Cj4g
PiBTbyBpZiB5b3Ugcm0gdGhlIGJhY2tlbmQgZGlyZWN0b3J5IHRoZSBOZXRCU0QgZG9lcyBub3Qg
dGFrZSB0aGF0IGFzIGEKPiA+IHNpZ24gdG8gdGVhciBkb3duIHRoZSBkZXZpY2U/IFRoYXQgc291
bmRzIGxpa2UgYSBidWcgaW4gdGhlIE5ldEJTRAo+ID4gYmFja2VuZCAtLSBpdCBzaG91bGQgdHJl
YXQgZGVsZXRpb24gb2YgdGhlIGJhY2tlbmQgc3RhdGUgZGlyIGFzIGlmIGl0Cj4gPiB3ZXJlIHJl
YWRpbmcgc3RhdGUgPSAiNiIgYW5kIHNodXQgZXZlcnl0aGluZyBkb3duLgo+IAo+IFllcywgaWYg
SSBkZWxldGUgdGhlIGZyb250ZW5kIGZyb20geGVuc3RvcmUsIHRoZSBkZXZpY2VzIGFyZSBkZXRh
Y2hlZC4KPiBBbnl3YXksIGRvaW5nIGl0IG9uZSB3YXkgb3IgYW5vdGhlciAoZGVsZXRpb24gb3Ig
c2V0dGluZyBzdGF0ZSB0byA2KQo+IGRvZXNuJ3QgcmVhbGx5IG1ha2UgYSBkaWZmZXJlbmNlLCB5
b3Ugc3RpbGwgaGF2ZSB0byB3YWl0IGZvciB0aGUKPiBiYWNrZW5kIHRvIGJlIGRpc2Nvbm5lY3Rl
ZCAoZGV0YWNoZWQpIGJlZm9yZSBleGVjdXRpbmcgaG90cGx1Zwo+IHNjcmlwdHMuCgpSaWdodC4g
VGhpcyBtaWdodCBhY3R1YWxseSBiZSB0cmlja3kgaW4gdGhlIGNhc2Ugd2hlcmUgdGhlIGJhY2tl
bmQgZGlyCmhhcyBiZWVuIHJlbW92ZWQgc2luY2UgSSBleHBlY3QgdGhlcmUgd2lsbCBiZSBub3do
ZXJlIGVsc2Ugd2hpY2gKaW5kaWNhdGVzIHRoaXMuCgo+ID4gT3IgaXMgdGhlIGlzc3VlIG9ubHkg
aW4gdGhlIHVzZXJzcGFjZSBwb3J0aW9ucz8KPiA+Cj4gPj4gIEkndmUgYWRkZWQgc29tZSBsaWJ4
bF9fd2FpdF9mb3JfZGV2aWNlX3N0YXRlIGxvZ2ljIGhlcmUsIHRvCj4gPj4gYXNzdXJlIHRoZSBi
YWNrZW5kIHN0YXRlIGlzIHNldCB0byA2IGJlZm9yZSB0cnlpbmcgdG8gZXhlY3V0ZSBob3RwbHVn
Cj4gPj4gc2NyaXB0cy4KPiA+Cj4gPiBCdXQgdGhhdCB3aWxsIGFsd2F5cyBiZSB0cnVlIHdpdGgg
dGhpcyBwYXRjaCBzaW5jZSB5b3Ugc2V0IGl0IHRoYXQgd2F5Cj4gPiBqdXN0IGJlZm9yZSwgcmln
aHQ/Cj4gCj4gSSBzZXQgZnJvbnRlbmQgc3RhdHVzIHRvIDYsIGFuZCBJIHN1Z2dlc3QgdG8gd2Fp
dCBmb3IgYmFja2VuZCBzdGF0dXMKPiB0byBiZSA2IGFsc28sIHRoZW4gZXhlY3V0ZSBob3RwbHVn
IHNjcmlwdHMuIEl0IHdvbid0IGJlIHRydWUsIGJlY2F1c2UKPiBmcm9udGVuZCBhbmQgYmFja2Vu
ZCBzdGF0dXMgYXJlIG5vdCB0aWVkIChpbiB0aGUgTmV0QlNEIGNhc2UgYmFja2VuZAo+IHN0YXR1
cyBpcyBzZXQgYnkgdGhlIERvbTAga2VybmVsIG9yIGhvdHBsdWcgc2NyaXB0cywgd2hpbGUgZnJv
bnRlbmQKPiBzdGF0dXMgaXMgc2V0IGJ5IHRoZSBEb21VKS4KCkkgdGhpbmsgKGJ1dCBJJ20gbm90
IHN1cmUpIHRoYXQgaXQgaXMgbm90IHBlcm1pc3NpYmxlIGZvciB0aGUgdG9vbHN0YWNrCnRvIG1l
c3Mgd2l0aCB0aGUgZnJvbnRlbmQgc3RhdGUgbGlrZSB0aGF0LgoKPiA+IElmIHlvdSBnbyBkb3du
IHRoaXMgcGF0aCB0aGVuIEkgdGhpbmsgeW91IG5lZWQgdG8gc2V0IHRoZSBzdGF0ZSB0bwo+ID4g
IjUiIChDbG9zaW5nKSBpbiBvcmRlciB0byBwcm9tcHQgdGhlIGJhY2tlbmQgdG8gdHJhbnNpdGlv
biB0bwo+ID4gIjYiIChDbG9zZWQpIGl0c2VsZi4gSG93ZXZlciB5b3UgbmVlZCB0byBiZSBjYXJl
ZnVsIGFib3V0IGFkZGluZyBhCj4gPiBzeW5jaHJvbm91cyB3YWl0IHRvIHRoZSBkZXZpY2UgZGVz
dHJveSBmdW5jdGlvbi4gVGhpcyBzaG91bGQgZXZlbnR1YWxseQo+ID4gd29yayBldmVuIGlmIHRo
ZSBmcm9udGVuZCBhbmQgYmFja2VuZCBhcmUgbm90IGNvLW9wZXJhdGluZy4gVGhhdCBzdGFydHMK
PiA+IHRvIGxvb2sgYSBiaXQgbGlrZSBjYWxsaW5nIGxpYnhsX19kZXZpY2VfcmVtb3ZlIGluc3Rl
YWQuCj4gCj4gRG8geW91IG1lYW4gdG8gc2V0IGJhY2tlbmQgc3RhdHVzIHRvIDUgaW5zdGVhZCBv
ZiBzZXR0aW5nIGZyb250ZW5kIHRvCj4gNiwgYW5kIHRoZW4gd2FpdCBmb3IgdGhlIGtlcm5lbCB0
byBkbyB0aGUgdHJhbnNpdGlvbiBmcm9tIDUgdG8gNiwKPiBpbnN0ZWFkIG9mIHNldHRpbmcgdGhl
IGZyb250ZW5kIHRvIDY/CgpZZXMuCgpJYW4uCgoKCl9fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxp
c3RzLnhlbnNvdXJjZS5jb20KaHR0cDovL2xpc3RzLnhlbnNvdXJjZS5jb20veGVuLWRldmVsCg==

From xen-devel-bounces@lists.xensource.com Wed Dec 14 12:13:29 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 12:13:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ranhy-0003Ww-68; Wed, 14 Dec 2011 12:13:14 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1Ranhw-0003Wr-Ka
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 12:13:12 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1323864716!52136910!1
X-Originating-IP: [209.85.160.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5917 invoked from network); 14 Dec 2011 12:11:58 -0000
Received: from mail-pw0-f43.google.com (HELO mail-pw0-f43.google.com)
	(209.85.160.43)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Dec 2011 12:11:58 -0000
Received: by pbbb11 with SMTP id b11so3240494pbb.30
	for <xen-devel@lists.xensource.com>;
	Wed, 14 Dec 2011 04:12:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=imQ8y0MwSKH5i58HsqJiEXnZ0eHzQlaP28NktaJTcM8=;
	b=WnHM6gpys+cW2/ciuVPBO5G+0AjJAbkKVRET9VkcDu/CXpJt8B717EhnToIXEbOnv2
	fzfIdKfYGVhZE4paVwlx9+HcrCrqdAbAnlc1PaVtYUNmHbr95zovqfaQKiyz2j3M+J/L
	RuV/aR1KL1T7tS0AOcGh7WOwHnyPl+aCv57Og=
MIME-Version: 1.0
Received: by 10.68.73.103 with SMTP id k7mr3016711pbv.132.1323864739491; Wed,
	14 Dec 2011 04:12:19 -0800 (PST)
Received: by 10.142.47.17 with HTTP; Wed, 14 Dec 2011 04:12:19 -0800 (PST)
In-Reply-To: <20200.36683.601224.172611@mariner.uk.xensource.com>
References: <patchbomb.1323768375@loki.upc.es>
	<35c322e6020501447936.1323768387@loki.upc.es>
	<20199.26896.928532.781947@mariner.uk.xensource.com>
	<CAPLaKK6wqa+VAxgzLWudQ2C2kaoXww9KK3BQhU4fKmoCAMFCzQ@mail.gmail.com>
	<1323860097.20077.394.camel@zakaz.uk.xensource.com>
	<CAPLaKK7Wv2HeRbg5Ze=B8DFe=wbzq=V35s6WVFXqrynh0ikRTw@mail.gmail.com>
	<20200.36683.601224.172611@mariner.uk.xensource.com>
Date: Wed, 14 Dec 2011 13:12:19 +0100
X-Google-Sender-Auth: bxTMtWHdBLJ7wQ0UyJPzxBaKHno
Message-ID: <CAPLaKK5h2PJko6o4v3usJkfttfdFqp9L6DEnfs0YYSSBWS63Eg@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH 12 of 14 v4] libxl: set frontend status to 6
 on domain destroy
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

MjAxMS8xMi8xNCBJYW4gSmFja3NvbiA8SWFuLkphY2tzb25AZXUuY2l0cml4LmNvbT46Cj4+IFll
cywgaWYgSSBkZWxldGUgdGhlIGZyb250ZW5kIGZyb20geGVuc3RvcmUsIHRoZSBkZXZpY2VzIGFy
ZSBkZXRhY2hlZC4KPj4gQW55d2F5LCBkb2luZyBpdCBvbmUgd2F5IG9yIGFub3RoZXIgKGRlbGV0
aW9uIG9yIHNldHRpbmcgc3RhdGUgdG8gNikKPj4gZG9lc24ndCByZWFsbHkgbWFrZSBhIGRpZmZl
cmVuY2UsIHlvdSBzdGlsbCBoYXZlIHRvIHdhaXQgZm9yIHRoZQo+PiBiYWNrZW5kIHRvIGJlIGRp
c2Nvbm5lY3RlZCAoZGV0YWNoZWQpIGJlZm9yZSBleGVjdXRpbmcgaG90cGx1Zwo+PiBzY3JpcHRz
Lgo+Cj4gU28gZGV2aWNlIGRlc3RydWN0aW9uIGNvdWxkIGJlIGFjaGlldmVkIGJ5IHNpbXBseSBk
ZWxldGluZyB0aGUgYmFja2VuZAo+IGRpcmVjdG9yeS4gwqBCdXQsIHdlIHdvdWxkIG5lZWQgc29t
ZSBvdGhlciB3YXkgdG8gZGV0ZWN0IHdoZW4gdGhlCj4gYmFja2VuZCBoYXMgYWN0dWFsbHkgY2xv
c2VkIHRoZSBkZXZpY2Ugc28gdGhhdCB3ZSBjYW4gcnVuIHRoZSBzY3JpcHQuCgpEZXZpY2UgZGV0
YWNoLCB3aWxsIGluIHR1cm4gYWxsb3dzIGRlc3RydWN0aW9uLCBjYW4gYmUgYWNoaWV2ZWQgaW4g
dHdvIHdheXM6CgogKiBTZXQgZnJvbnRlbmQgc3RhdHVzIHRvIDYuCiAqIFJlbW92ZSBmcm9udGVu
ZCBlbnRyaWVzLgoKVGhlcmUgaXMgbm8gbmVlZCB0byBjaGFuZ2UgYmFja2VuZCBlbnRyaWVzIHRv
IGZvcmNlIGRldGFjaCBhIGRldmljZS4KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhl
bnNvdXJjZS5jb20KaHR0cDovL2xpc3RzLnhlbnNvdXJjZS5jb20veGVuLWRldmVsCg==

From xen-devel-bounces@lists.xensource.com Wed Dec 14 12:13:29 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 12:13:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ranhy-0003Ww-68; Wed, 14 Dec 2011 12:13:14 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1Ranhw-0003Wr-Ka
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 12:13:12 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1323864716!52136910!1
X-Originating-IP: [209.85.160.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5917 invoked from network); 14 Dec 2011 12:11:58 -0000
Received: from mail-pw0-f43.google.com (HELO mail-pw0-f43.google.com)
	(209.85.160.43)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Dec 2011 12:11:58 -0000
Received: by pbbb11 with SMTP id b11so3240494pbb.30
	for <xen-devel@lists.xensource.com>;
	Wed, 14 Dec 2011 04:12:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=imQ8y0MwSKH5i58HsqJiEXnZ0eHzQlaP28NktaJTcM8=;
	b=WnHM6gpys+cW2/ciuVPBO5G+0AjJAbkKVRET9VkcDu/CXpJt8B717EhnToIXEbOnv2
	fzfIdKfYGVhZE4paVwlx9+HcrCrqdAbAnlc1PaVtYUNmHbr95zovqfaQKiyz2j3M+J/L
	RuV/aR1KL1T7tS0AOcGh7WOwHnyPl+aCv57Og=
MIME-Version: 1.0
Received: by 10.68.73.103 with SMTP id k7mr3016711pbv.132.1323864739491; Wed,
	14 Dec 2011 04:12:19 -0800 (PST)
Received: by 10.142.47.17 with HTTP; Wed, 14 Dec 2011 04:12:19 -0800 (PST)
In-Reply-To: <20200.36683.601224.172611@mariner.uk.xensource.com>
References: <patchbomb.1323768375@loki.upc.es>
	<35c322e6020501447936.1323768387@loki.upc.es>
	<20199.26896.928532.781947@mariner.uk.xensource.com>
	<CAPLaKK6wqa+VAxgzLWudQ2C2kaoXww9KK3BQhU4fKmoCAMFCzQ@mail.gmail.com>
	<1323860097.20077.394.camel@zakaz.uk.xensource.com>
	<CAPLaKK7Wv2HeRbg5Ze=B8DFe=wbzq=V35s6WVFXqrynh0ikRTw@mail.gmail.com>
	<20200.36683.601224.172611@mariner.uk.xensource.com>
Date: Wed, 14 Dec 2011 13:12:19 +0100
X-Google-Sender-Auth: bxTMtWHdBLJ7wQ0UyJPzxBaKHno
Message-ID: <CAPLaKK5h2PJko6o4v3usJkfttfdFqp9L6DEnfs0YYSSBWS63Eg@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH 12 of 14 v4] libxl: set frontend status to 6
 on domain destroy
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

MjAxMS8xMi8xNCBJYW4gSmFja3NvbiA8SWFuLkphY2tzb25AZXUuY2l0cml4LmNvbT46Cj4+IFll
cywgaWYgSSBkZWxldGUgdGhlIGZyb250ZW5kIGZyb20geGVuc3RvcmUsIHRoZSBkZXZpY2VzIGFy
ZSBkZXRhY2hlZC4KPj4gQW55d2F5LCBkb2luZyBpdCBvbmUgd2F5IG9yIGFub3RoZXIgKGRlbGV0
aW9uIG9yIHNldHRpbmcgc3RhdGUgdG8gNikKPj4gZG9lc24ndCByZWFsbHkgbWFrZSBhIGRpZmZl
cmVuY2UsIHlvdSBzdGlsbCBoYXZlIHRvIHdhaXQgZm9yIHRoZQo+PiBiYWNrZW5kIHRvIGJlIGRp
c2Nvbm5lY3RlZCAoZGV0YWNoZWQpIGJlZm9yZSBleGVjdXRpbmcgaG90cGx1Zwo+PiBzY3JpcHRz
Lgo+Cj4gU28gZGV2aWNlIGRlc3RydWN0aW9uIGNvdWxkIGJlIGFjaGlldmVkIGJ5IHNpbXBseSBk
ZWxldGluZyB0aGUgYmFja2VuZAo+IGRpcmVjdG9yeS4gwqBCdXQsIHdlIHdvdWxkIG5lZWQgc29t
ZSBvdGhlciB3YXkgdG8gZGV0ZWN0IHdoZW4gdGhlCj4gYmFja2VuZCBoYXMgYWN0dWFsbHkgY2xv
c2VkIHRoZSBkZXZpY2Ugc28gdGhhdCB3ZSBjYW4gcnVuIHRoZSBzY3JpcHQuCgpEZXZpY2UgZGV0
YWNoLCB3aWxsIGluIHR1cm4gYWxsb3dzIGRlc3RydWN0aW9uLCBjYW4gYmUgYWNoaWV2ZWQgaW4g
dHdvIHdheXM6CgogKiBTZXQgZnJvbnRlbmQgc3RhdHVzIHRvIDYuCiAqIFJlbW92ZSBmcm9udGVu
ZCBlbnRyaWVzLgoKVGhlcmUgaXMgbm8gbmVlZCB0byBjaGFuZ2UgYmFja2VuZCBlbnRyaWVzIHRv
IGZvcmNlIGRldGFjaCBhIGRldmljZS4KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhl
bnNvdXJjZS5jb20KaHR0cDovL2xpc3RzLnhlbnNvdXJjZS5jb20veGVuLWRldmVsCg==

From xen-devel-bounces@lists.xensource.com Wed Dec 14 12:13:34 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 12:13:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rani0-0003X7-J5; Wed, 14 Dec 2011 12:13:16 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <m.a.young@durham.ac.uk>) id 1Ranhy-0003Wq-49
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 12:13:14 +0000
X-Env-Sender: m.a.young@durham.ac.uk
X-Msg-Ref: server-13.tower-182.messagelabs.com!1323864738!6691463!1
X-Originating-IP: [129.234.248.2]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTI5LjIzNC4yNDguMiA9PiA3OTM5OA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2315 invoked from network); 14 Dec 2011 12:12:18 -0000
Received: from hermes2.dur.ac.uk (HELO hermes2.dur.ac.uk) (129.234.248.2)
	by server-13.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Dec 2011 12:12:18 -0000
Received: from smtphost3.dur.ac.uk (smtphost3.dur.ac.uk [129.234.252.3])
	by hermes2.dur.ac.uk (8.13.8/8.13.7) with ESMTP id pBECBoj6026149;
	Wed, 14 Dec 2011 12:11:54 GMT
Received: from vega-a.dur.ac.uk (vega-a.dur.ac.uk [129.234.250.133])
	by smtphost3.dur.ac.uk (8.13.8/8.13.7) with ESMTP id pBECBY5f011078
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 14 Dec 2011 12:11:34 GMT
Received: from vega-a.dur.ac.uk (localhost [127.0.0.1])
	by vega-a.dur.ac.uk (8.14.3/8.11.1) with ESMTP id pBECBY6T018657;
	Wed, 14 Dec 2011 12:11:34 GMT
Received: from localhost (dcl0may@localhost)
	by vega-a.dur.ac.uk (8.14.3/8.14.3/Submit) with ESMTP id pBECBX9p018653;
	Wed, 14 Dec 2011 12:11:33 GMT
Date: Wed, 14 Dec 2011 12:11:33 +0000 (GMT)
From: M A Young <m.a.young@durham.ac.uk>
To: =?ISO-8859-15?Q?Pasi_K=E4rkk=E4inen?= <pasik@iki.fi>
In-Reply-To: <20111214090338.GS12984@reaktio.net>
Message-ID: <alpine.DEB.2.00.1112141151340.11802@vega-a.dur.ac.uk>
References: <alpine.DEB.2.00.1110192358140.15667@vega-a.dur.ac.uk>
	<1319293366.98429.YahooMailClassic@web65903.mail.ac4.yahoo.com>
	<20111116184108.GM12984@reaktio.net>
	<20111214090338.GS12984@reaktio.net>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="8323329-886250819-1323864693=:11802"
X-DurhamAcUk-MailScanner: Found to be clean, Found to be clean
X-DurhamAcUk-MailScanner-ID: pBECBoj6026149
Cc: xen-devel@lists.xensource.com, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH 0 of 6] pygrub fixes to support a Fedora 16
 guest
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--8323329-886250819-1323864693=:11802
Content-Type: TEXT/PLAIN; charset=iso-8859-1; format=flowed
Content-Transfer-Encoding: 8BIT

On Wed, 14 Dec 2011, Pasi Kärkkäinen wrote:

> On Wed, Nov 16, 2011 at 08:41:08PM +0200, Pasi Kärkkäinen wrote:
>> On Sat, Oct 22, 2011 at 07:22:46AM -0700, Boris Derzhavets wrote:
>>>    Please, back port  to xen-4.1-testing.hg.
>>>
>>
>> Yep, this pygrub patch series is already in xen-unstable.hg,
>> and it should be backported to xen-4.1-testing.hg aswell,
>> so upcoming Xen 4.1.3 will support F16 PV domUs.
>>
>> (It's already included in Michael's Fedora 16 xen rpms,
>> and works well there.)
>>
>
> Fedora 16 Xen 4.1.2 src.rpm is for example here:
> ftp://ftp.funet.fi/pub/mirrors/fedora.redhat.com/pub/fedora/linux/updates/16/SRPMS/xen-4.1.2-2.fc16.src.rpm
>
> and that includes a working backport of these pygryb patches,
> in a case they don't apply cleanly to xen-4.1-testing.hg.

It doesn't have 24003:c681dd5aecf3 which adds a sample grub2 configuration 
file though I expect that will backport cleanly, as should 
23998:85d7b207fabc , 24000:65679fee0177 , 24001:152049468175 and
24002:979bc34d0ad0 .
The exception is 23999:138f707fa598 (getting pygrub to look in the /grub2 
directories that Fedora 16 uses) which needs obvious adjustments because 
the checking order changed from grub, grub2, extlinux in 4.1 to grub2, 
extlinux, grub in 4.2.
The relevant bits of the Fedora package for this (if my mail client 
doesn't mess them up) are below

 	Michael Young

--- xen-4.1.2/tools/pygrub/src/pygrub.orig	2011-10-13 18:56:41.000000000 +0100
+++ xen-4.1.2/tools/pygrub/src/pygrub	2011-10-13 20:46:58.000000000 +0100
@@ -394,7 +404,8 @@
                             ["/boot/grub/menu.lst", "/boot/grub/grub.conf",
                              "/grub/menu.lst", "/grub/grub.conf"]) + \
                         map(lambda x: (x,grub.GrubConf.Grub2ConfigFile),
-                           ["/boot/grub/grub.cfg", "/grub/grub.cfg"]) + \
+                           ["/boot/grub/grub.cfg", "/grub/grub.cfg",
+                            "/boot/grub2/grub.cfg", "/grub2/grub.cfg"]) + \
                         map(lambda x: (x,grub.ExtLinuxConf.ExtLinuxConfigFile),
                             ["/boot/isolinux/isolinux.cfg",
                              "/boot/extlinux.conf"])
--8323329-886250819-1323864693=:11802
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--8323329-886250819-1323864693=:11802--


From xen-devel-bounces@lists.xensource.com Wed Dec 14 12:13:34 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 12:13:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rani0-0003X7-J5; Wed, 14 Dec 2011 12:13:16 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <m.a.young@durham.ac.uk>) id 1Ranhy-0003Wq-49
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 12:13:14 +0000
X-Env-Sender: m.a.young@durham.ac.uk
X-Msg-Ref: server-13.tower-182.messagelabs.com!1323864738!6691463!1
X-Originating-IP: [129.234.248.2]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTI5LjIzNC4yNDguMiA9PiA3OTM5OA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2315 invoked from network); 14 Dec 2011 12:12:18 -0000
Received: from hermes2.dur.ac.uk (HELO hermes2.dur.ac.uk) (129.234.248.2)
	by server-13.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Dec 2011 12:12:18 -0000
Received: from smtphost3.dur.ac.uk (smtphost3.dur.ac.uk [129.234.252.3])
	by hermes2.dur.ac.uk (8.13.8/8.13.7) with ESMTP id pBECBoj6026149;
	Wed, 14 Dec 2011 12:11:54 GMT
Received: from vega-a.dur.ac.uk (vega-a.dur.ac.uk [129.234.250.133])
	by smtphost3.dur.ac.uk (8.13.8/8.13.7) with ESMTP id pBECBY5f011078
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 14 Dec 2011 12:11:34 GMT
Received: from vega-a.dur.ac.uk (localhost [127.0.0.1])
	by vega-a.dur.ac.uk (8.14.3/8.11.1) with ESMTP id pBECBY6T018657;
	Wed, 14 Dec 2011 12:11:34 GMT
Received: from localhost (dcl0may@localhost)
	by vega-a.dur.ac.uk (8.14.3/8.14.3/Submit) with ESMTP id pBECBX9p018653;
	Wed, 14 Dec 2011 12:11:33 GMT
Date: Wed, 14 Dec 2011 12:11:33 +0000 (GMT)
From: M A Young <m.a.young@durham.ac.uk>
To: =?ISO-8859-15?Q?Pasi_K=E4rkk=E4inen?= <pasik@iki.fi>
In-Reply-To: <20111214090338.GS12984@reaktio.net>
Message-ID: <alpine.DEB.2.00.1112141151340.11802@vega-a.dur.ac.uk>
References: <alpine.DEB.2.00.1110192358140.15667@vega-a.dur.ac.uk>
	<1319293366.98429.YahooMailClassic@web65903.mail.ac4.yahoo.com>
	<20111116184108.GM12984@reaktio.net>
	<20111214090338.GS12984@reaktio.net>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="8323329-886250819-1323864693=:11802"
X-DurhamAcUk-MailScanner: Found to be clean, Found to be clean
X-DurhamAcUk-MailScanner-ID: pBECBoj6026149
Cc: xen-devel@lists.xensource.com, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH 0 of 6] pygrub fixes to support a Fedora 16
 guest
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--8323329-886250819-1323864693=:11802
Content-Type: TEXT/PLAIN; charset=iso-8859-1; format=flowed
Content-Transfer-Encoding: 8BIT

On Wed, 14 Dec 2011, Pasi Kärkkäinen wrote:

> On Wed, Nov 16, 2011 at 08:41:08PM +0200, Pasi Kärkkäinen wrote:
>> On Sat, Oct 22, 2011 at 07:22:46AM -0700, Boris Derzhavets wrote:
>>>    Please, back port  to xen-4.1-testing.hg.
>>>
>>
>> Yep, this pygrub patch series is already in xen-unstable.hg,
>> and it should be backported to xen-4.1-testing.hg aswell,
>> so upcoming Xen 4.1.3 will support F16 PV domUs.
>>
>> (It's already included in Michael's Fedora 16 xen rpms,
>> and works well there.)
>>
>
> Fedora 16 Xen 4.1.2 src.rpm is for example here:
> ftp://ftp.funet.fi/pub/mirrors/fedora.redhat.com/pub/fedora/linux/updates/16/SRPMS/xen-4.1.2-2.fc16.src.rpm
>
> and that includes a working backport of these pygryb patches,
> in a case they don't apply cleanly to xen-4.1-testing.hg.

It doesn't have 24003:c681dd5aecf3 which adds a sample grub2 configuration 
file though I expect that will backport cleanly, as should 
23998:85d7b207fabc , 24000:65679fee0177 , 24001:152049468175 and
24002:979bc34d0ad0 .
The exception is 23999:138f707fa598 (getting pygrub to look in the /grub2 
directories that Fedora 16 uses) which needs obvious adjustments because 
the checking order changed from grub, grub2, extlinux in 4.1 to grub2, 
extlinux, grub in 4.2.
The relevant bits of the Fedora package for this (if my mail client 
doesn't mess them up) are below

 	Michael Young

--- xen-4.1.2/tools/pygrub/src/pygrub.orig	2011-10-13 18:56:41.000000000 +0100
+++ xen-4.1.2/tools/pygrub/src/pygrub	2011-10-13 20:46:58.000000000 +0100
@@ -394,7 +404,8 @@
                             ["/boot/grub/menu.lst", "/boot/grub/grub.conf",
                              "/grub/menu.lst", "/grub/grub.conf"]) + \
                         map(lambda x: (x,grub.GrubConf.Grub2ConfigFile),
-                           ["/boot/grub/grub.cfg", "/grub/grub.cfg"]) + \
+                           ["/boot/grub/grub.cfg", "/grub/grub.cfg",
+                            "/boot/grub2/grub.cfg", "/grub2/grub.cfg"]) + \
                         map(lambda x: (x,grub.ExtLinuxConf.ExtLinuxConfigFile),
                             ["/boot/isolinux/isolinux.cfg",
                              "/boot/extlinux.conf"])
--8323329-886250819-1323864693=:11802
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--8323329-886250819-1323864693=:11802--


From xen-devel-bounces@lists.xensource.com Wed Dec 14 12:14:32 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 12:14:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ranj0-0003cR-23; Wed, 14 Dec 2011 12:14:18 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wnlo.zwt@gmail.com>) id 1Raniy-0003cF-V6
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 12:14:17 +0000
X-Env-Sender: wnlo.zwt@gmail.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1323864752!60693946!1
X-Originating-IP: [209.85.212.43]
X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31550 invoked from network); 14 Dec 2011 12:12:33 -0000
Received: from mail-vw0-f43.google.com (HELO mail-vw0-f43.google.com)
	(209.85.212.43)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Dec 2011 12:12:33 -0000
Received: by vbbfq11 with SMTP id fq11so1620209vbb.30
	for <xen-devel@lists.xensource.com>;
	Wed, 14 Dec 2011 04:13:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=LK8bbhj3Yq1NxEQ8ptrtlAo4ZQcsDZ9/Ujeta/e52VA=;
	b=bd225uAuIRegVmXqlNmIkypKVzaeQCLPlQjhX5k9EU/QqQEwa0b7YWE6YgH9DojgRz
	hRL2pW6rjk3SGd09k84GuM+P4SedH2ajyf2Q0j/XGqVOiDmvrQKJcTZ0h1Jl5hI13Ism
	zPwnbe/Avb0Ldi0xWvuB7tpp3gEy0xRfB7vgw=
MIME-Version: 1.0
Received: by 10.52.67.129 with SMTP id n1mr4045343vdt.105.1323864805107; Wed,
	14 Dec 2011 04:13:25 -0800 (PST)
Received: by 10.52.112.131 with HTTP; Wed, 14 Dec 2011 04:13:25 -0800 (PST)
In-Reply-To: <1323851008.20936.112.camel@dagon.hellion.org.uk>
References: <CAJZuLfe+QsePaJps=3SdG4ALYs0PixB3xcrb0nx1+v-o0VmMaw@mail.gmail.com>
	<CAJZuLff7otKaraAYF_wFG7vRzgVcFNg9cbos2UVS=M0pMZ34zQ@mail.gmail.com>
	<1323851008.20936.112.camel@dagon.hellion.org.uk>
Date: Wed, 14 Dec 2011 20:13:25 +0800
Message-ID: <CAJZuLfcRbYXhtm9HN1v+nx5L+Xay0tK1PQj8PCOSZZhRthZ3LQ@mail.gmail.com>
From: Wentao Zhang <wnlo.zwt@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] how to make the new python codes effective
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============7405030440694683030=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============7405030440694683030==
Content-Type: multipart/alternative; boundary=20cf307f3b3c70691904b40c4bda

--20cf307f3b3c70691904b40c4bda
Content-Type: text/plain; charset=ISO-8859-1

thanks very much !

2011/12/14 Ian Campbell <Ian.Campbell@citrix.com>

> On Wed, 2011-12-14 at 07:19 +0000, Wentao Zhang wrote:
> >
> > Hi,
> >     Something troubles me several days.  I had changed some codes in
> > tools/python/xen/xm/main.py, but how can I make them effective ?
> > I had tried with 'make xen && make install-xen', but failed !
>
> "make tools && make tools-install" ought to do it (the "xen" targets
> relate to the hypervisor itself).
>
> Note that xend is unmaintained and deprecated in xen-unstable. libxl/xl
> is the preferred toolstack for all new development.
>
> Ian.
>
>
>


-- 
Best wishes !

--20cf307f3b3c70691904b40c4bda
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

thanks very much !<br><br><div class=3D"gmail_quote">2011/12/14 Ian Campbel=
l <span dir=3D"ltr">&lt;<a href=3D"mailto:Ian.Campbell@citrix.com">Ian.Camp=
bell@citrix.com</a>&gt;</span><br><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class=3D"im">On Wed, 2011-12-14 at 07:19 +0000, Wentao Zhang wrote:<br=
>
&gt;<br>
&gt; Hi,<br>
&gt; =A0 =A0 Something troubles me several days. =A0I had changed some code=
s in<br>
&gt; tools/python/xen/xm/main.py, but how can I make them effective ?<br>
&gt; I had tried with &#39;make xen &amp;&amp; make install-xen&#39;, but f=
ailed !<br>
<br>
</div>&quot;make tools &amp;&amp; make tools-install&quot; ought to do it (=
the &quot;xen&quot; targets<br>
relate to the hypervisor itself).<br>
<br>
Note that xend is unmaintained and deprecated in xen-unstable. libxl/xl<br>
is the preferred toolstack for all new development.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
Ian.<br>
<br>
<br>
</font></span></blockquote></div><br><br clear=3D"all"><div><br></div>-- <b=
r>Best wishes !<br>

--20cf307f3b3c70691904b40c4bda--


--===============7405030440694683030==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============7405030440694683030==--


From xen-devel-bounces@lists.xensource.com Wed Dec 14 12:14:32 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 12:14:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ranj0-0003cR-23; Wed, 14 Dec 2011 12:14:18 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wnlo.zwt@gmail.com>) id 1Raniy-0003cF-V6
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 12:14:17 +0000
X-Env-Sender: wnlo.zwt@gmail.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1323864752!60693946!1
X-Originating-IP: [209.85.212.43]
X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31550 invoked from network); 14 Dec 2011 12:12:33 -0000
Received: from mail-vw0-f43.google.com (HELO mail-vw0-f43.google.com)
	(209.85.212.43)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Dec 2011 12:12:33 -0000
Received: by vbbfq11 with SMTP id fq11so1620209vbb.30
	for <xen-devel@lists.xensource.com>;
	Wed, 14 Dec 2011 04:13:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=LK8bbhj3Yq1NxEQ8ptrtlAo4ZQcsDZ9/Ujeta/e52VA=;
	b=bd225uAuIRegVmXqlNmIkypKVzaeQCLPlQjhX5k9EU/QqQEwa0b7YWE6YgH9DojgRz
	hRL2pW6rjk3SGd09k84GuM+P4SedH2ajyf2Q0j/XGqVOiDmvrQKJcTZ0h1Jl5hI13Ism
	zPwnbe/Avb0Ldi0xWvuB7tpp3gEy0xRfB7vgw=
MIME-Version: 1.0
Received: by 10.52.67.129 with SMTP id n1mr4045343vdt.105.1323864805107; Wed,
	14 Dec 2011 04:13:25 -0800 (PST)
Received: by 10.52.112.131 with HTTP; Wed, 14 Dec 2011 04:13:25 -0800 (PST)
In-Reply-To: <1323851008.20936.112.camel@dagon.hellion.org.uk>
References: <CAJZuLfe+QsePaJps=3SdG4ALYs0PixB3xcrb0nx1+v-o0VmMaw@mail.gmail.com>
	<CAJZuLff7otKaraAYF_wFG7vRzgVcFNg9cbos2UVS=M0pMZ34zQ@mail.gmail.com>
	<1323851008.20936.112.camel@dagon.hellion.org.uk>
Date: Wed, 14 Dec 2011 20:13:25 +0800
Message-ID: <CAJZuLfcRbYXhtm9HN1v+nx5L+Xay0tK1PQj8PCOSZZhRthZ3LQ@mail.gmail.com>
From: Wentao Zhang <wnlo.zwt@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] how to make the new python codes effective
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============7405030440694683030=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============7405030440694683030==
Content-Type: multipart/alternative; boundary=20cf307f3b3c70691904b40c4bda

--20cf307f3b3c70691904b40c4bda
Content-Type: text/plain; charset=ISO-8859-1

thanks very much !

2011/12/14 Ian Campbell <Ian.Campbell@citrix.com>

> On Wed, 2011-12-14 at 07:19 +0000, Wentao Zhang wrote:
> >
> > Hi,
> >     Something troubles me several days.  I had changed some codes in
> > tools/python/xen/xm/main.py, but how can I make them effective ?
> > I had tried with 'make xen && make install-xen', but failed !
>
> "make tools && make tools-install" ought to do it (the "xen" targets
> relate to the hypervisor itself).
>
> Note that xend is unmaintained and deprecated in xen-unstable. libxl/xl
> is the preferred toolstack for all new development.
>
> Ian.
>
>
>


-- 
Best wishes !

--20cf307f3b3c70691904b40c4bda
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

thanks very much !<br><br><div class=3D"gmail_quote">2011/12/14 Ian Campbel=
l <span dir=3D"ltr">&lt;<a href=3D"mailto:Ian.Campbell@citrix.com">Ian.Camp=
bell@citrix.com</a>&gt;</span><br><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class=3D"im">On Wed, 2011-12-14 at 07:19 +0000, Wentao Zhang wrote:<br=
>
&gt;<br>
&gt; Hi,<br>
&gt; =A0 =A0 Something troubles me several days. =A0I had changed some code=
s in<br>
&gt; tools/python/xen/xm/main.py, but how can I make them effective ?<br>
&gt; I had tried with &#39;make xen &amp;&amp; make install-xen&#39;, but f=
ailed !<br>
<br>
</div>&quot;make tools &amp;&amp; make tools-install&quot; ought to do it (=
the &quot;xen&quot; targets<br>
relate to the hypervisor itself).<br>
<br>
Note that xend is unmaintained and deprecated in xen-unstable. libxl/xl<br>
is the preferred toolstack for all new development.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
Ian.<br>
<br>
<br>
</font></span></blockquote></div><br><br clear=3D"all"><div><br></div>-- <b=
r>Best wishes !<br>

--20cf307f3b3c70691904b40c4bda--


--===============7405030440694683030==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============7405030440694683030==--


From xen-devel-bounces@lists.xensource.com Wed Dec 14 12:17:22 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 12:17:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ranlj-0003qn-ML; Wed, 14 Dec 2011 12:17:07 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Ranlh-0003q0-Rl
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 12:17:06 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1323864969!7431601!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTc4Ng==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26456 invoked from network); 14 Dec 2011 12:16:09 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Dec 2011 12:16:09 -0000
X-IronPort-AV: E=Sophos;i="4.71,351,1320624000"; 
   d="scan'208";a="9461440"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Dec 2011 12:16:09 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 14 Dec 2011 12:16:09 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: George Shuklin <george.shuklin@gmail.com>, Konrad Rzeszutek Wilk
	<konrad.wilk@oracle.com>
Date: Wed, 14 Dec 2011 12:16:08 +0000
In-Reply-To: <1323847523.20936.110.camel@dagon.hellion.org.uk>
References: <4EE675A8.3030609@niemail.de>	<4EE71663.5040308@gmail.com>
	<CAJeBh4sxdNTxM_oLFAuA6Mw75=LaYysrpS5b8NsZMbkf_swNVw@mail.gmail.com>
	<4EE72A94.6040904@gmail.com> <4EE75080.1000909@citrix.com>
	<1323783428.20077.298.camel@zakaz.uk.xensource.com>
	<4EE7BC9B.6040003@gmail.com>
	<1323815427.20936.96.camel@dagon.hellion.org.uk>
	<4EE7D75B.6080209@gmail.com>
	<1323847523.20936.110.camel@dagon.hellion.org.uk>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323864969.20077.405.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, David
	Vrabel <david.vrabel@citrix.com>, "sandr8@gmail.com" <sandr8@gmail.com>
Subject: Re: [Xen-devel] a ton of kernel issues
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2011-12-14 at 07:25 +0000, Ian Campbell wrote:
> 
> It controls precisely the behaviour you need! Try "maxmem=2048" and
> "memory=1024" in your guest configuration, it should boot with 1G of
> RAM and allow you to balloon to 2G and back. 

I take it back, there is indeed a bug in the PV ops kernel in this
regard.

It works with xm/xend because they set the maximum reservation for
guests to static-max on boot. xl (and, I think, xapi) instead set the
maximum reservation to the current balloon target and change it
dynamically as the target is changed (as a method of enforcing the
targets). However the pvops kernel incorrectly uses the maximum
reservation at boot to size the physical address space for guests.

The patch below fixes this.

Ian.

8<-------------------------------------------------------------

>From 649ca3b7ddca1cdda85c27e34f806f30484172ec Mon Sep 17 00:00:00 2001
From: Ian Campbell <ian.campbell@citrix.com>
Date: Wed, 14 Dec 2011 12:00:38 +0000
Subject: [PATCH] xen: only limit memory map to maximum reservation for domain 0.

d312ae878b6a "xen: use maximum reservation to limit amount of usable RAM"
clamped the total amount of RAM to the current maximum reservation. This is
correct for dom0 but is not correct for guest domains. In order to boot a guest
"pre-ballooned" (e.g. with memory=1G but maxmem=2G) in order to allow for
future memory expansion the guest must derive max_pfn from the e820 provided by
the toolstack and not the current maximum reservation (which can reflect only
the current maximum, not the guest lifetime max). The existing algorithm
already behaves this correctly if we do not artificially limit the maximum
number of pages for the guest case.

For a guest booted with maxmem=512, memory=128 this results in:
 [    0.000000] BIOS-provided physical RAM map:
 [    0.000000]  Xen: 0000000000000000 - 00000000000a0000 (usable)
 [    0.000000]  Xen: 00000000000a0000 - 0000000000100000 (reserved)
-[    0.000000]  Xen: 0000000000100000 - 0000000008100000 (usable)
-[    0.000000]  Xen: 0000000008100000 - 0000000020800000 (unusable)
+[    0.000000]  Xen: 0000000000100000 - 0000000020800000 (usable)
...
 [    0.000000] NX (Execute Disable) protection: active
 [    0.000000] DMI not present or invalid.
 [    0.000000] e820 update range: 0000000000000000 - 0000000000010000 (usable) ==> (reserved)
 [    0.000000] e820 remove range: 00000000000a0000 - 0000000000100000 (usable)
-[    0.000000] last_pfn = 0x8100 max_arch_pfn = 0x1000000
+[    0.000000] last_pfn = 0x20800 max_arch_pfn = 0x1000000
 [    0.000000] initial memory mapped : 0 - 027ff000
 [    0.000000] Base memory trampoline at [c009f000] 9f000 size 4096
-[    0.000000] init_memory_mapping: 0000000000000000-0000000008100000
-[    0.000000]  0000000000 - 0008100000 page 4k
-[    0.000000] kernel direct mapping tables up to 8100000 @ 27bb000-27ff000
+[    0.000000] init_memory_mapping: 0000000000000000-0000000020800000
+[    0.000000]  0000000000 - 0020800000 page 4k
+[    0.000000] kernel direct mapping tables up to 20800000 @ 26f8000-27ff000
 [    0.000000] xen: setting RW the range 27e8000 - 27ff000
 [    0.000000] 0MB HIGHMEM available.
-[    0.000000] 129MB LOWMEM available.
-[    0.000000]   mapped low ram: 0 - 08100000
-[    0.000000]   low ram: 0 - 08100000
+[    0.000000] 520MB LOWMEM available.
+[    0.000000]   mapped low ram: 0 - 20800000
+[    0.000000]   low ram: 0 - 20800000

With this change "xl mem-set <domain> 512M" will successfully increase the
guest RAM (by reducing the balloon).

There is no change for dom0.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Cc: stable@kernel.org
Cc: David Vrabel <david.vrabel@citrix.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 arch/x86/xen/setup.c |   18 +++++++++++++++---
 1 files changed, 15 insertions(+), 3 deletions(-)

diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
index 38d0af4..a54ff1a 100644
--- a/arch/x86/xen/setup.c
+++ b/arch/x86/xen/setup.c
@@ -173,9 +173,21 @@ static unsigned long __init xen_get_max_pages(void)
 	domid_t domid = DOMID_SELF;
 	int ret;
 
-	ret = HYPERVISOR_memory_op(XENMEM_maximum_reservation, &domid);
-	if (ret > 0)
-		max_pages = ret;
+	/*
+	 * For the initial domain we use the maximum reservation as
+	 * the maximum page.
+	 *
+	 * For guest domains the current maximum reservation reflects
+	 * the current maximum rather than the static maximum. In this
+	 * case the e820 map provided to us will cover the static
+	 * maximum region.
+	 */
+	if (xen_initial_domain()) {
+		ret = HYPERVISOR_memory_op(XENMEM_maximum_reservation, &domid);
+		if (ret > 0)
+			max_pages = ret;
+	}
+
 	return min(max_pages, MAX_DOMAIN_PAGES);
 }
 
-- 
1.7.2.5




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 12:17:22 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 12:17:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ranlj-0003qn-ML; Wed, 14 Dec 2011 12:17:07 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Ranlh-0003q0-Rl
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 12:17:06 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1323864969!7431601!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTc4Ng==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26456 invoked from network); 14 Dec 2011 12:16:09 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Dec 2011 12:16:09 -0000
X-IronPort-AV: E=Sophos;i="4.71,351,1320624000"; 
   d="scan'208";a="9461440"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Dec 2011 12:16:09 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 14 Dec 2011 12:16:09 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: George Shuklin <george.shuklin@gmail.com>, Konrad Rzeszutek Wilk
	<konrad.wilk@oracle.com>
Date: Wed, 14 Dec 2011 12:16:08 +0000
In-Reply-To: <1323847523.20936.110.camel@dagon.hellion.org.uk>
References: <4EE675A8.3030609@niemail.de>	<4EE71663.5040308@gmail.com>
	<CAJeBh4sxdNTxM_oLFAuA6Mw75=LaYysrpS5b8NsZMbkf_swNVw@mail.gmail.com>
	<4EE72A94.6040904@gmail.com> <4EE75080.1000909@citrix.com>
	<1323783428.20077.298.camel@zakaz.uk.xensource.com>
	<4EE7BC9B.6040003@gmail.com>
	<1323815427.20936.96.camel@dagon.hellion.org.uk>
	<4EE7D75B.6080209@gmail.com>
	<1323847523.20936.110.camel@dagon.hellion.org.uk>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323864969.20077.405.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, David
	Vrabel <david.vrabel@citrix.com>, "sandr8@gmail.com" <sandr8@gmail.com>
Subject: Re: [Xen-devel] a ton of kernel issues
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2011-12-14 at 07:25 +0000, Ian Campbell wrote:
> 
> It controls precisely the behaviour you need! Try "maxmem=2048" and
> "memory=1024" in your guest configuration, it should boot with 1G of
> RAM and allow you to balloon to 2G and back. 

I take it back, there is indeed a bug in the PV ops kernel in this
regard.

It works with xm/xend because they set the maximum reservation for
guests to static-max on boot. xl (and, I think, xapi) instead set the
maximum reservation to the current balloon target and change it
dynamically as the target is changed (as a method of enforcing the
targets). However the pvops kernel incorrectly uses the maximum
reservation at boot to size the physical address space for guests.

The patch below fixes this.

Ian.

8<-------------------------------------------------------------

>From 649ca3b7ddca1cdda85c27e34f806f30484172ec Mon Sep 17 00:00:00 2001
From: Ian Campbell <ian.campbell@citrix.com>
Date: Wed, 14 Dec 2011 12:00:38 +0000
Subject: [PATCH] xen: only limit memory map to maximum reservation for domain 0.

d312ae878b6a "xen: use maximum reservation to limit amount of usable RAM"
clamped the total amount of RAM to the current maximum reservation. This is
correct for dom0 but is not correct for guest domains. In order to boot a guest
"pre-ballooned" (e.g. with memory=1G but maxmem=2G) in order to allow for
future memory expansion the guest must derive max_pfn from the e820 provided by
the toolstack and not the current maximum reservation (which can reflect only
the current maximum, not the guest lifetime max). The existing algorithm
already behaves this correctly if we do not artificially limit the maximum
number of pages for the guest case.

For a guest booted with maxmem=512, memory=128 this results in:
 [    0.000000] BIOS-provided physical RAM map:
 [    0.000000]  Xen: 0000000000000000 - 00000000000a0000 (usable)
 [    0.000000]  Xen: 00000000000a0000 - 0000000000100000 (reserved)
-[    0.000000]  Xen: 0000000000100000 - 0000000008100000 (usable)
-[    0.000000]  Xen: 0000000008100000 - 0000000020800000 (unusable)
+[    0.000000]  Xen: 0000000000100000 - 0000000020800000 (usable)
...
 [    0.000000] NX (Execute Disable) protection: active
 [    0.000000] DMI not present or invalid.
 [    0.000000] e820 update range: 0000000000000000 - 0000000000010000 (usable) ==> (reserved)
 [    0.000000] e820 remove range: 00000000000a0000 - 0000000000100000 (usable)
-[    0.000000] last_pfn = 0x8100 max_arch_pfn = 0x1000000
+[    0.000000] last_pfn = 0x20800 max_arch_pfn = 0x1000000
 [    0.000000] initial memory mapped : 0 - 027ff000
 [    0.000000] Base memory trampoline at [c009f000] 9f000 size 4096
-[    0.000000] init_memory_mapping: 0000000000000000-0000000008100000
-[    0.000000]  0000000000 - 0008100000 page 4k
-[    0.000000] kernel direct mapping tables up to 8100000 @ 27bb000-27ff000
+[    0.000000] init_memory_mapping: 0000000000000000-0000000020800000
+[    0.000000]  0000000000 - 0020800000 page 4k
+[    0.000000] kernel direct mapping tables up to 20800000 @ 26f8000-27ff000
 [    0.000000] xen: setting RW the range 27e8000 - 27ff000
 [    0.000000] 0MB HIGHMEM available.
-[    0.000000] 129MB LOWMEM available.
-[    0.000000]   mapped low ram: 0 - 08100000
-[    0.000000]   low ram: 0 - 08100000
+[    0.000000] 520MB LOWMEM available.
+[    0.000000]   mapped low ram: 0 - 20800000
+[    0.000000]   low ram: 0 - 20800000

With this change "xl mem-set <domain> 512M" will successfully increase the
guest RAM (by reducing the balloon).

There is no change for dom0.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Cc: stable@kernel.org
Cc: David Vrabel <david.vrabel@citrix.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 arch/x86/xen/setup.c |   18 +++++++++++++++---
 1 files changed, 15 insertions(+), 3 deletions(-)

diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
index 38d0af4..a54ff1a 100644
--- a/arch/x86/xen/setup.c
+++ b/arch/x86/xen/setup.c
@@ -173,9 +173,21 @@ static unsigned long __init xen_get_max_pages(void)
 	domid_t domid = DOMID_SELF;
 	int ret;
 
-	ret = HYPERVISOR_memory_op(XENMEM_maximum_reservation, &domid);
-	if (ret > 0)
-		max_pages = ret;
+	/*
+	 * For the initial domain we use the maximum reservation as
+	 * the maximum page.
+	 *
+	 * For guest domains the current maximum reservation reflects
+	 * the current maximum rather than the static maximum. In this
+	 * case the e820 map provided to us will cover the static
+	 * maximum region.
+	 */
+	if (xen_initial_domain()) {
+		ret = HYPERVISOR_memory_op(XENMEM_maximum_reservation, &domid);
+		if (ret > 0)
+			max_pages = ret;
+	}
+
 	return min(max_pages, MAX_DOMAIN_PAGES);
 }
 
-- 
1.7.2.5




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 12:19:50 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 12:19:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rano5-000430-BT; Wed, 14 Dec 2011 12:19:33 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1Rano3-00042a-T7
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 12:19:32 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1323865114!5526441!1
X-Originating-IP: [209.85.210.43]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31283 invoked from network); 14 Dec 2011 12:18:36 -0000
Received: from mail-pz0-f43.google.com (HELO mail-pz0-f43.google.com)
	(209.85.210.43)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Dec 2011 12:18:36 -0000
Received: by daec6 with SMTP id c6so2674574dae.30
	for <xen-devel@lists.xensource.com>;
	Wed, 14 Dec 2011 04:18:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=QlENX0WX7FTHaRsHa8NumcbJq19z/wGFGOWw6OoCXAs=;
	b=Dp+tFEegdtIcWDVdo6/PR2dtSI7csr92fEvNrdHh11IFJsVW6o5REvP1xb5akG+mCZ
	49QM92I9jXoTBEJp+v/UHhwkLEODPrp5FuWDfWeX4g2wUg9lfbvsE/u4s/61FUFcIapC
	2eqIDAIzDyhPpqBff8gBkb1FW5LrRWdc5XGaI=
MIME-Version: 1.0
Received: by 10.68.74.164 with SMTP id u4mr3167767pbv.30.1323865113951; Wed,
	14 Dec 2011 04:18:33 -0800 (PST)
Received: by 10.142.47.17 with HTTP; Wed, 14 Dec 2011 04:18:33 -0800 (PST)
In-Reply-To: <1323863914.20077.400.camel@zakaz.uk.xensource.com>
References: <patchbomb.1323768375@loki.upc.es>
	<35c322e6020501447936.1323768387@loki.upc.es>
	<20199.26896.928532.781947@mariner.uk.xensource.com>
	<CAPLaKK6wqa+VAxgzLWudQ2C2kaoXww9KK3BQhU4fKmoCAMFCzQ@mail.gmail.com>
	<1323860097.20077.394.camel@zakaz.uk.xensource.com>
	<CAPLaKK7Wv2HeRbg5Ze=B8DFe=wbzq=V35s6WVFXqrynh0ikRTw@mail.gmail.com>
	<1323863914.20077.400.camel@zakaz.uk.xensource.com>
Date: Wed, 14 Dec 2011 13:18:33 +0100
X-Google-Sender-Auth: cN8E14r9MgFVf4Y0_ErIgZPl_lc
Message-ID: <CAPLaKK6dHr8fBujk-BSFO=-Ly3ZcQVEGTJcAwQRkfSWqk2Wb4g@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 12 of 14 v4] libxl: set frontend status to 6
 on domain destroy
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

MjAxMS8xMi8xNCBJYW4gQ2FtcGJlbGwgPElhbi5DYW1wYmVsbEBjaXRyaXguY29tPjoKPiBPbiBX
ZWQsIDIwMTEtMTItMTQgYXQgMTE6MTIgKzAwMDAsIFJvZ2VyIFBhdSBNb25uw6kgd3JvdGU6Cj4+
IDIwMTEvMTIvMTQgSWFuIENhbXBiZWxsIDxJYW4uQ2FtcGJlbGxAY2l0cml4LmNvbT46Cj4+ID4g
U28gaWYgeW91IHJtIHRoZSBiYWNrZW5kIGRpcmVjdG9yeSB0aGUgTmV0QlNEIGRvZXMgbm90IHRh
a2UgdGhhdCBhcyBhCj4+ID4gc2lnbiB0byB0ZWFyIGRvd24gdGhlIGRldmljZT8gVGhhdCBzb3Vu
ZHMgbGlrZSBhIGJ1ZyBpbiB0aGUgTmV0QlNECj4+ID4gYmFja2VuZCAtLSBpdCBzaG91bGQgdHJl
YXQgZGVsZXRpb24gb2YgdGhlIGJhY2tlbmQgc3RhdGUgZGlyIGFzIGlmIGl0Cj4+ID4gd2VyZSBy
ZWFkaW5nIHN0YXRlID0gIjYiIGFuZCBzaHV0IGV2ZXJ5dGhpbmcgZG93bi4KPj4KPj4gWWVzLCBp
ZiBJIGRlbGV0ZSB0aGUgZnJvbnRlbmQgZnJvbSB4ZW5zdG9yZSwgdGhlIGRldmljZXMgYXJlIGRl
dGFjaGVkLgo+PiBBbnl3YXksIGRvaW5nIGl0IG9uZSB3YXkgb3IgYW5vdGhlciAoZGVsZXRpb24g
b3Igc2V0dGluZyBzdGF0ZSB0byA2KQo+PiBkb2Vzbid0IHJlYWxseSBtYWtlIGEgZGlmZmVyZW5j
ZSwgeW91IHN0aWxsIGhhdmUgdG8gd2FpdCBmb3IgdGhlCj4+IGJhY2tlbmQgdG8gYmUgZGlzY29u
bmVjdGVkIChkZXRhY2hlZCkgYmVmb3JlIGV4ZWN1dGluZyBob3RwbHVnCj4+IHNjcmlwdHMuCj4K
PiBSaWdodC4gVGhpcyBtaWdodCBhY3R1YWxseSBiZSB0cmlja3kgaW4gdGhlIGNhc2Ugd2hlcmUg
dGhlIGJhY2tlbmQgZGlyCj4gaGFzIGJlZW4gcmVtb3ZlZCBzaW5jZSBJIGV4cGVjdCB0aGVyZSB3
aWxsIGJlIG5vd2hlcmUgZWxzZSB3aGljaAo+IGluZGljYXRlcyB0aGlzLgoKTm8sIHRoZXJlJ3Mg
bm8gb3RoZXIgZWFzeSB3YXkgdG8ga25vdyBpZiB0aGUgZGV2aWNlIGhhcyBiZWVuIGRldGFjaGVk
LgpJZiBob3RwbHVnIHNjcmlwdHMgYXJlIGV4ZWN1dGVkIGZyb20geGwsIEkgdGhpbmsgaXQgaXMg
c2FmZSB0byBhc3N1bWUKdGhhdCBub2JvZHkgZWxzZSBpcyBtZXNzaW5nIHdpdGggeGVuc3RvcmUg
ZW50cmllcy4gQmFja2VuZCBmb2xkZXIKc2hvdWxkIG5vdCBiZSByZW1vdmVkIHVudGlsbCBob3Rw
bHVnIHNjcmlwdCBleGVjdXRpb24gaGFzIGhhcHBlbmVkLgoKPgo+PiA+IE9yIGlzIHRoZSBpc3N1
ZSBvbmx5IGluIHRoZSB1c2Vyc3BhY2UgcG9ydGlvbnM/Cj4+ID4KPj4gPj4gwqBJJ3ZlIGFkZGVk
IHNvbWUgbGlieGxfX3dhaXRfZm9yX2RldmljZV9zdGF0ZSBsb2dpYyBoZXJlLCB0bwo+PiA+PiBh
c3N1cmUgdGhlIGJhY2tlbmQgc3RhdGUgaXMgc2V0IHRvIDYgYmVmb3JlIHRyeWluZyB0byBleGVj
dXRlIGhvdHBsdWcKPj4gPj4gc2NyaXB0cy4KPj4gPgo+PiA+IEJ1dCB0aGF0IHdpbGwgYWx3YXlz
IGJlIHRydWUgd2l0aCB0aGlzIHBhdGNoIHNpbmNlIHlvdSBzZXQgaXQgdGhhdCB3YXkKPj4gPiBq
dXN0IGJlZm9yZSwgcmlnaHQ/Cj4+Cj4+IEkgc2V0IGZyb250ZW5kIHN0YXR1cyB0byA2LCBhbmQg
SSBzdWdnZXN0IHRvIHdhaXQgZm9yIGJhY2tlbmQgc3RhdHVzCj4+IHRvIGJlIDYgYWxzbywgdGhl
biBleGVjdXRlIGhvdHBsdWcgc2NyaXB0cy4gSXQgd29uJ3QgYmUgdHJ1ZSwgYmVjYXVzZQo+PiBm
cm9udGVuZCBhbmQgYmFja2VuZCBzdGF0dXMgYXJlIG5vdCB0aWVkIChpbiB0aGUgTmV0QlNEIGNh
c2UgYmFja2VuZAo+PiBzdGF0dXMgaXMgc2V0IGJ5IHRoZSBEb20wIGtlcm5lbCBvciBob3RwbHVn
IHNjcmlwdHMsIHdoaWxlIGZyb250ZW5kCj4+IHN0YXR1cyBpcyBzZXQgYnkgdGhlIERvbVUpLgo+
Cj4gSSB0aGluayAoYnV0IEknbSBub3Qgc3VyZSkgdGhhdCBpdCBpcyBub3QgcGVybWlzc2libGUg
Zm9yIHRoZSB0b29sc3RhY2sKPiB0byBtZXNzIHdpdGggdGhlIGZyb250ZW5kIHN0YXRlIGxpa2Ug
dGhhdC4KCldlbGwsIHhsIGFscmVhZHkgcmVtb3ZlcyBmcm9udGVuZCB4ZW5zdG9yZSBlbnRyaWVz
LCBzbyBJIGFzc3VtZWQKc2V0dGluZyBmcm9udGVuZCBzdGF0dXMgdG8gNiB3YXMgbm90IGEgcHJv
YmxlbS4gSWYgaXQgaXMsIEkgY291bGQKYWx3YXlzIGRvIHRoZSBmb2xsb3dpbmcgc2VxdWVuY2Ug
dG8gZm9yY2UgdGhlIGRldGFjaDoKCjEuIERlbGV0ZSBmcm9udGVuZCB4ZW5zdG9yZSBkaXIuCjIu
IFdhaXQgZm9yIGJhY2tlbmQgeGVuc3RvcmUgdG8gc3dpdGNoIHRvIGRpc2Nvbm5lY3RlZCBzdGF0
ZSAoNikuCjMuIEV4ZWN1dGUgaG90cGx1ZyBzY3JpcHQuCjQuIFJlbW92ZSBiYWNrZW5kLgoKPj4g
PiBJZiB5b3UgZ28gZG93biB0aGlzIHBhdGggdGhlbiBJIHRoaW5rIHlvdSBuZWVkIHRvIHNldCB0
aGUgc3RhdGUgdG8KPj4gPiAiNSIgKENsb3NpbmcpIGluIG9yZGVyIHRvIHByb21wdCB0aGUgYmFj
a2VuZCB0byB0cmFuc2l0aW9uIHRvCj4+ID4gIjYiIChDbG9zZWQpIGl0c2VsZi4gSG93ZXZlciB5
b3UgbmVlZCB0byBiZSBjYXJlZnVsIGFib3V0IGFkZGluZyBhCj4+ID4gc3luY2hyb25vdXMgd2Fp
dCB0byB0aGUgZGV2aWNlIGRlc3Ryb3kgZnVuY3Rpb24uIFRoaXMgc2hvdWxkIGV2ZW50dWFsbHkK
Pj4gPiB3b3JrIGV2ZW4gaWYgdGhlIGZyb250ZW5kIGFuZCBiYWNrZW5kIGFyZSBub3QgY28tb3Bl
cmF0aW5nLiBUaGF0IHN0YXJ0cwo+PiA+IHRvIGxvb2sgYSBiaXQgbGlrZSBjYWxsaW5nIGxpYnhs
X19kZXZpY2VfcmVtb3ZlIGluc3RlYWQuCj4+Cj4+IERvIHlvdSBtZWFuIHRvIHNldCBiYWNrZW5k
IHN0YXR1cyB0byA1IGluc3RlYWQgb2Ygc2V0dGluZyBmcm9udGVuZCB0bwo+PiA2LCBhbmQgdGhl
biB3YWl0IGZvciB0aGUga2VybmVsIHRvIGRvIHRoZSB0cmFuc2l0aW9uIGZyb20gNSB0byA2LAo+
PiBpbnN0ZWFkIG9mIHNldHRpbmcgdGhlIGZyb250ZW5kIHRvIDY/Cj4KPiBZZXMuCgpObyBsdWNr
LCBzZXR0aW5nIGJhY2tlbmQgc3RhdGUgdG8gNSBkaWQgbm90IG1ha2UgdGhlIGtlcm5lbCBkZXRh
Y2ggdGhlCmRldmljZS4gSXQgc2VlbXMgbGlrZSB0aGUga2VybmVsIGlzIG9ubHkgd2F0Y2hpbmcg
ZnJvbnRlbmQgeGVuc3RvcmUKZW50cmllcy4KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3Rz
LnhlbnNvdXJjZS5jb20KaHR0cDovL2xpc3RzLnhlbnNvdXJjZS5jb20veGVuLWRldmVsCg==

From xen-devel-bounces@lists.xensource.com Wed Dec 14 12:19:50 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 12:19:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rano5-000430-BT; Wed, 14 Dec 2011 12:19:33 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1Rano3-00042a-T7
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 12:19:32 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1323865114!5526441!1
X-Originating-IP: [209.85.210.43]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31283 invoked from network); 14 Dec 2011 12:18:36 -0000
Received: from mail-pz0-f43.google.com (HELO mail-pz0-f43.google.com)
	(209.85.210.43)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Dec 2011 12:18:36 -0000
Received: by daec6 with SMTP id c6so2674574dae.30
	for <xen-devel@lists.xensource.com>;
	Wed, 14 Dec 2011 04:18:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=QlENX0WX7FTHaRsHa8NumcbJq19z/wGFGOWw6OoCXAs=;
	b=Dp+tFEegdtIcWDVdo6/PR2dtSI7csr92fEvNrdHh11IFJsVW6o5REvP1xb5akG+mCZ
	49QM92I9jXoTBEJp+v/UHhwkLEODPrp5FuWDfWeX4g2wUg9lfbvsE/u4s/61FUFcIapC
	2eqIDAIzDyhPpqBff8gBkb1FW5LrRWdc5XGaI=
MIME-Version: 1.0
Received: by 10.68.74.164 with SMTP id u4mr3167767pbv.30.1323865113951; Wed,
	14 Dec 2011 04:18:33 -0800 (PST)
Received: by 10.142.47.17 with HTTP; Wed, 14 Dec 2011 04:18:33 -0800 (PST)
In-Reply-To: <1323863914.20077.400.camel@zakaz.uk.xensource.com>
References: <patchbomb.1323768375@loki.upc.es>
	<35c322e6020501447936.1323768387@loki.upc.es>
	<20199.26896.928532.781947@mariner.uk.xensource.com>
	<CAPLaKK6wqa+VAxgzLWudQ2C2kaoXww9KK3BQhU4fKmoCAMFCzQ@mail.gmail.com>
	<1323860097.20077.394.camel@zakaz.uk.xensource.com>
	<CAPLaKK7Wv2HeRbg5Ze=B8DFe=wbzq=V35s6WVFXqrynh0ikRTw@mail.gmail.com>
	<1323863914.20077.400.camel@zakaz.uk.xensource.com>
Date: Wed, 14 Dec 2011 13:18:33 +0100
X-Google-Sender-Auth: cN8E14r9MgFVf4Y0_ErIgZPl_lc
Message-ID: <CAPLaKK6dHr8fBujk-BSFO=-Ly3ZcQVEGTJcAwQRkfSWqk2Wb4g@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 12 of 14 v4] libxl: set frontend status to 6
 on domain destroy
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

MjAxMS8xMi8xNCBJYW4gQ2FtcGJlbGwgPElhbi5DYW1wYmVsbEBjaXRyaXguY29tPjoKPiBPbiBX
ZWQsIDIwMTEtMTItMTQgYXQgMTE6MTIgKzAwMDAsIFJvZ2VyIFBhdSBNb25uw6kgd3JvdGU6Cj4+
IDIwMTEvMTIvMTQgSWFuIENhbXBiZWxsIDxJYW4uQ2FtcGJlbGxAY2l0cml4LmNvbT46Cj4+ID4g
U28gaWYgeW91IHJtIHRoZSBiYWNrZW5kIGRpcmVjdG9yeSB0aGUgTmV0QlNEIGRvZXMgbm90IHRh
a2UgdGhhdCBhcyBhCj4+ID4gc2lnbiB0byB0ZWFyIGRvd24gdGhlIGRldmljZT8gVGhhdCBzb3Vu
ZHMgbGlrZSBhIGJ1ZyBpbiB0aGUgTmV0QlNECj4+ID4gYmFja2VuZCAtLSBpdCBzaG91bGQgdHJl
YXQgZGVsZXRpb24gb2YgdGhlIGJhY2tlbmQgc3RhdGUgZGlyIGFzIGlmIGl0Cj4+ID4gd2VyZSBy
ZWFkaW5nIHN0YXRlID0gIjYiIGFuZCBzaHV0IGV2ZXJ5dGhpbmcgZG93bi4KPj4KPj4gWWVzLCBp
ZiBJIGRlbGV0ZSB0aGUgZnJvbnRlbmQgZnJvbSB4ZW5zdG9yZSwgdGhlIGRldmljZXMgYXJlIGRl
dGFjaGVkLgo+PiBBbnl3YXksIGRvaW5nIGl0IG9uZSB3YXkgb3IgYW5vdGhlciAoZGVsZXRpb24g
b3Igc2V0dGluZyBzdGF0ZSB0byA2KQo+PiBkb2Vzbid0IHJlYWxseSBtYWtlIGEgZGlmZmVyZW5j
ZSwgeW91IHN0aWxsIGhhdmUgdG8gd2FpdCBmb3IgdGhlCj4+IGJhY2tlbmQgdG8gYmUgZGlzY29u
bmVjdGVkIChkZXRhY2hlZCkgYmVmb3JlIGV4ZWN1dGluZyBob3RwbHVnCj4+IHNjcmlwdHMuCj4K
PiBSaWdodC4gVGhpcyBtaWdodCBhY3R1YWxseSBiZSB0cmlja3kgaW4gdGhlIGNhc2Ugd2hlcmUg
dGhlIGJhY2tlbmQgZGlyCj4gaGFzIGJlZW4gcmVtb3ZlZCBzaW5jZSBJIGV4cGVjdCB0aGVyZSB3
aWxsIGJlIG5vd2hlcmUgZWxzZSB3aGljaAo+IGluZGljYXRlcyB0aGlzLgoKTm8sIHRoZXJlJ3Mg
bm8gb3RoZXIgZWFzeSB3YXkgdG8ga25vdyBpZiB0aGUgZGV2aWNlIGhhcyBiZWVuIGRldGFjaGVk
LgpJZiBob3RwbHVnIHNjcmlwdHMgYXJlIGV4ZWN1dGVkIGZyb20geGwsIEkgdGhpbmsgaXQgaXMg
c2FmZSB0byBhc3N1bWUKdGhhdCBub2JvZHkgZWxzZSBpcyBtZXNzaW5nIHdpdGggeGVuc3RvcmUg
ZW50cmllcy4gQmFja2VuZCBmb2xkZXIKc2hvdWxkIG5vdCBiZSByZW1vdmVkIHVudGlsbCBob3Rw
bHVnIHNjcmlwdCBleGVjdXRpb24gaGFzIGhhcHBlbmVkLgoKPgo+PiA+IE9yIGlzIHRoZSBpc3N1
ZSBvbmx5IGluIHRoZSB1c2Vyc3BhY2UgcG9ydGlvbnM/Cj4+ID4KPj4gPj4gwqBJJ3ZlIGFkZGVk
IHNvbWUgbGlieGxfX3dhaXRfZm9yX2RldmljZV9zdGF0ZSBsb2dpYyBoZXJlLCB0bwo+PiA+PiBh
c3N1cmUgdGhlIGJhY2tlbmQgc3RhdGUgaXMgc2V0IHRvIDYgYmVmb3JlIHRyeWluZyB0byBleGVj
dXRlIGhvdHBsdWcKPj4gPj4gc2NyaXB0cy4KPj4gPgo+PiA+IEJ1dCB0aGF0IHdpbGwgYWx3YXlz
IGJlIHRydWUgd2l0aCB0aGlzIHBhdGNoIHNpbmNlIHlvdSBzZXQgaXQgdGhhdCB3YXkKPj4gPiBq
dXN0IGJlZm9yZSwgcmlnaHQ/Cj4+Cj4+IEkgc2V0IGZyb250ZW5kIHN0YXR1cyB0byA2LCBhbmQg
SSBzdWdnZXN0IHRvIHdhaXQgZm9yIGJhY2tlbmQgc3RhdHVzCj4+IHRvIGJlIDYgYWxzbywgdGhl
biBleGVjdXRlIGhvdHBsdWcgc2NyaXB0cy4gSXQgd29uJ3QgYmUgdHJ1ZSwgYmVjYXVzZQo+PiBm
cm9udGVuZCBhbmQgYmFja2VuZCBzdGF0dXMgYXJlIG5vdCB0aWVkIChpbiB0aGUgTmV0QlNEIGNh
c2UgYmFja2VuZAo+PiBzdGF0dXMgaXMgc2V0IGJ5IHRoZSBEb20wIGtlcm5lbCBvciBob3RwbHVn
IHNjcmlwdHMsIHdoaWxlIGZyb250ZW5kCj4+IHN0YXR1cyBpcyBzZXQgYnkgdGhlIERvbVUpLgo+
Cj4gSSB0aGluayAoYnV0IEknbSBub3Qgc3VyZSkgdGhhdCBpdCBpcyBub3QgcGVybWlzc2libGUg
Zm9yIHRoZSB0b29sc3RhY2sKPiB0byBtZXNzIHdpdGggdGhlIGZyb250ZW5kIHN0YXRlIGxpa2Ug
dGhhdC4KCldlbGwsIHhsIGFscmVhZHkgcmVtb3ZlcyBmcm9udGVuZCB4ZW5zdG9yZSBlbnRyaWVz
LCBzbyBJIGFzc3VtZWQKc2V0dGluZyBmcm9udGVuZCBzdGF0dXMgdG8gNiB3YXMgbm90IGEgcHJv
YmxlbS4gSWYgaXQgaXMsIEkgY291bGQKYWx3YXlzIGRvIHRoZSBmb2xsb3dpbmcgc2VxdWVuY2Ug
dG8gZm9yY2UgdGhlIGRldGFjaDoKCjEuIERlbGV0ZSBmcm9udGVuZCB4ZW5zdG9yZSBkaXIuCjIu
IFdhaXQgZm9yIGJhY2tlbmQgeGVuc3RvcmUgdG8gc3dpdGNoIHRvIGRpc2Nvbm5lY3RlZCBzdGF0
ZSAoNikuCjMuIEV4ZWN1dGUgaG90cGx1ZyBzY3JpcHQuCjQuIFJlbW92ZSBiYWNrZW5kLgoKPj4g
PiBJZiB5b3UgZ28gZG93biB0aGlzIHBhdGggdGhlbiBJIHRoaW5rIHlvdSBuZWVkIHRvIHNldCB0
aGUgc3RhdGUgdG8KPj4gPiAiNSIgKENsb3NpbmcpIGluIG9yZGVyIHRvIHByb21wdCB0aGUgYmFj
a2VuZCB0byB0cmFuc2l0aW9uIHRvCj4+ID4gIjYiIChDbG9zZWQpIGl0c2VsZi4gSG93ZXZlciB5
b3UgbmVlZCB0byBiZSBjYXJlZnVsIGFib3V0IGFkZGluZyBhCj4+ID4gc3luY2hyb25vdXMgd2Fp
dCB0byB0aGUgZGV2aWNlIGRlc3Ryb3kgZnVuY3Rpb24uIFRoaXMgc2hvdWxkIGV2ZW50dWFsbHkK
Pj4gPiB3b3JrIGV2ZW4gaWYgdGhlIGZyb250ZW5kIGFuZCBiYWNrZW5kIGFyZSBub3QgY28tb3Bl
cmF0aW5nLiBUaGF0IHN0YXJ0cwo+PiA+IHRvIGxvb2sgYSBiaXQgbGlrZSBjYWxsaW5nIGxpYnhs
X19kZXZpY2VfcmVtb3ZlIGluc3RlYWQuCj4+Cj4+IERvIHlvdSBtZWFuIHRvIHNldCBiYWNrZW5k
IHN0YXR1cyB0byA1IGluc3RlYWQgb2Ygc2V0dGluZyBmcm9udGVuZCB0bwo+PiA2LCBhbmQgdGhl
biB3YWl0IGZvciB0aGUga2VybmVsIHRvIGRvIHRoZSB0cmFuc2l0aW9uIGZyb20gNSB0byA2LAo+
PiBpbnN0ZWFkIG9mIHNldHRpbmcgdGhlIGZyb250ZW5kIHRvIDY/Cj4KPiBZZXMuCgpObyBsdWNr
LCBzZXR0aW5nIGJhY2tlbmQgc3RhdGUgdG8gNSBkaWQgbm90IG1ha2UgdGhlIGtlcm5lbCBkZXRh
Y2ggdGhlCmRldmljZS4gSXQgc2VlbXMgbGlrZSB0aGUga2VybmVsIGlzIG9ubHkgd2F0Y2hpbmcg
ZnJvbnRlbmQgeGVuc3RvcmUKZW50cmllcy4KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3Rz
LnhlbnNvdXJjZS5jb20KaHR0cDovL2xpc3RzLnhlbnNvdXJjZS5jb20veGVuLWRldmVsCg==

From xen-devel-bounces@lists.xensource.com Wed Dec 14 12:22:51 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 12: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.xensource.com>)
	id 1Ranr7-0004Dg-AF; Wed, 14 Dec 2011 12:22:41 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1Ranr6-0004DR-8X
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 12:22:40 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1323865303!6693164!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjA4OTk=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9092 invoked from network); 14 Dec 2011 12:21:44 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Dec 2011 12:21:44 -0000
X-IronPort-AV: E=Sophos;i="4.71,351,1320642000"; d="scan'208";a="174092515"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Dec 2011 07:21:43 -0500
Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX02.citrite.net
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Wed, 14 Dec 2011
	07:21:43 -0500
Message-ID: <4EE894D5.5010107@citrix.com>
Date: Wed, 14 Dec 2011 12:21:41 +0000
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20111110 Icedove/3.0.11
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <4EE675A8.3030609@niemail.de>	<4EE71663.5040308@gmail.com>	
	<CAJeBh4sxdNTxM_oLFAuA6Mw75=LaYysrpS5b8NsZMbkf_swNVw@mail.gmail.com>	
	<4EE72A94.6040904@gmail.com> <4EE75080.1000909@citrix.com>	
	<1323783428.20077.298.camel@zakaz.uk.xensource.com>	
	<4EE7BC9B.6040003@gmail.com>	
	<1323815427.20936.96.camel@dagon.hellion.org.uk>		<4EE7D75B.6080209@gmail.com>	
	<1323847523.20936.110.camel@dagon.hellion.org.uk>
	<1323864969.20077.405.camel@zakaz.uk.xensource.com>
In-Reply-To: <1323864969.20077.405.camel@zakaz.uk.xensource.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	George Shuklin <george.shuklin@gmail.com>,
	"sandr8@gmail.com" <sandr8@gmail.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] a ton of kernel issues
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 14/12/11 12:16, Ian Campbell wrote:
> On Wed, 2011-12-14 at 07:25 +0000, Ian Campbell wrote:
>>
>> It controls precisely the behaviour you need! Try "maxmem=2048" and
>> "memory=1024" in your guest configuration, it should boot with 1G of
>> RAM and allow you to balloon to 2G and back. 
> 
> I take it back, there is indeed a bug in the PV ops kernel in this
> regard.
> 
> It works with xm/xend because they set the maximum reservation for
> guests to static-max on boot. xl (and, I think, xapi) instead set the
> maximum reservation to the current balloon target and change it
> dynamically as the target is changed (as a method of enforcing the
> targets). However the pvops kernel incorrectly uses the maximum
> reservation at boot to size the physical address space for guests.
> 
> The patch below fixes this.
> 
> Ian.
> 
> 8<-------------------------------------------------------------
> 
> From 649ca3b7ddca1cdda85c27e34f806f30484172ec Mon Sep 17 00:00:00 2001
> From: Ian Campbell <ian.campbell@citrix.com>
> Date: Wed, 14 Dec 2011 12:00:38 +0000
> Subject: [PATCH] xen: only limit memory map to maximum reservation for domain 0.
> 
> d312ae878b6a "xen: use maximum reservation to limit amount of usable RAM"
> clamped the total amount of RAM to the current maximum reservation. This is
> correct for dom0 but is not correct for guest domains. In order to boot a guest
> "pre-ballooned" (e.g. with memory=1G but maxmem=2G) in order to allow for
> future memory expansion the guest must derive max_pfn from the e820 provided by
> the toolstack and not the current maximum reservation (which can reflect only
> the current maximum, not the guest lifetime max). The existing algorithm
> already behaves this correctly if we do not artificially limit the maximum
> number of pages for the guest case.
[...]
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> Cc: stable@kernel.org
> Cc: David Vrabel <david.vrabel@citrix.com>
> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Acked-by: David Vrabel <david.vrabel@citrix.com>

or Reviewed-by if that's more appropriate.

David


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 12:22:51 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 12: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.xensource.com>)
	id 1Ranr7-0004Dg-AF; Wed, 14 Dec 2011 12:22:41 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1Ranr6-0004DR-8X
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 12:22:40 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1323865303!6693164!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjA4OTk=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9092 invoked from network); 14 Dec 2011 12:21:44 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Dec 2011 12:21:44 -0000
X-IronPort-AV: E=Sophos;i="4.71,351,1320642000"; d="scan'208";a="174092515"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Dec 2011 07:21:43 -0500
Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX02.citrite.net
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Wed, 14 Dec 2011
	07:21:43 -0500
Message-ID: <4EE894D5.5010107@citrix.com>
Date: Wed, 14 Dec 2011 12:21:41 +0000
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20111110 Icedove/3.0.11
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <4EE675A8.3030609@niemail.de>	<4EE71663.5040308@gmail.com>	
	<CAJeBh4sxdNTxM_oLFAuA6Mw75=LaYysrpS5b8NsZMbkf_swNVw@mail.gmail.com>	
	<4EE72A94.6040904@gmail.com> <4EE75080.1000909@citrix.com>	
	<1323783428.20077.298.camel@zakaz.uk.xensource.com>	
	<4EE7BC9B.6040003@gmail.com>	
	<1323815427.20936.96.camel@dagon.hellion.org.uk>		<4EE7D75B.6080209@gmail.com>	
	<1323847523.20936.110.camel@dagon.hellion.org.uk>
	<1323864969.20077.405.camel@zakaz.uk.xensource.com>
In-Reply-To: <1323864969.20077.405.camel@zakaz.uk.xensource.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	George Shuklin <george.shuklin@gmail.com>,
	"sandr8@gmail.com" <sandr8@gmail.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] a ton of kernel issues
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 14/12/11 12:16, Ian Campbell wrote:
> On Wed, 2011-12-14 at 07:25 +0000, Ian Campbell wrote:
>>
>> It controls precisely the behaviour you need! Try "maxmem=2048" and
>> "memory=1024" in your guest configuration, it should boot with 1G of
>> RAM and allow you to balloon to 2G and back. 
> 
> I take it back, there is indeed a bug in the PV ops kernel in this
> regard.
> 
> It works with xm/xend because they set the maximum reservation for
> guests to static-max on boot. xl (and, I think, xapi) instead set the
> maximum reservation to the current balloon target and change it
> dynamically as the target is changed (as a method of enforcing the
> targets). However the pvops kernel incorrectly uses the maximum
> reservation at boot to size the physical address space for guests.
> 
> The patch below fixes this.
> 
> Ian.
> 
> 8<-------------------------------------------------------------
> 
> From 649ca3b7ddca1cdda85c27e34f806f30484172ec Mon Sep 17 00:00:00 2001
> From: Ian Campbell <ian.campbell@citrix.com>
> Date: Wed, 14 Dec 2011 12:00:38 +0000
> Subject: [PATCH] xen: only limit memory map to maximum reservation for domain 0.
> 
> d312ae878b6a "xen: use maximum reservation to limit amount of usable RAM"
> clamped the total amount of RAM to the current maximum reservation. This is
> correct for dom0 but is not correct for guest domains. In order to boot a guest
> "pre-ballooned" (e.g. with memory=1G but maxmem=2G) in order to allow for
> future memory expansion the guest must derive max_pfn from the e820 provided by
> the toolstack and not the current maximum reservation (which can reflect only
> the current maximum, not the guest lifetime max). The existing algorithm
> already behaves this correctly if we do not artificially limit the maximum
> number of pages for the guest case.
[...]
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> Cc: stable@kernel.org
> Cc: David Vrabel <david.vrabel@citrix.com>
> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Acked-by: David Vrabel <david.vrabel@citrix.com>

or Reviewed-by if that's more appropriate.

David


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 12:25:00 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 12: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.xensource.com>)
	id 1RantA-0004PQ-5n; Wed, 14 Dec 2011 12:24:48 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rant9-0004Ov-CY
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 12:24:47 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1323865431!5532439!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTc4Ng==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9266 invoked from network); 14 Dec 2011 12:23:52 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Dec 2011 12:23:52 -0000
X-IronPort-AV: E=Sophos;i="4.71,351,1320624000"; 
   d="scan'208";a="9461582"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Dec 2011 12:22:49 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 14 Dec 2011 12:22:49 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau =?ISO-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
Date: Wed, 14 Dec 2011 12:22:49 +0000
In-Reply-To: <CAPLaKK5h2PJko6o4v3usJkfttfdFqp9L6DEnfs0YYSSBWS63Eg@mail.gmail.com>
References: <patchbomb.1323768375@loki.upc.es>
	<35c322e6020501447936.1323768387@loki.upc.es>
	<20199.26896.928532.781947@mariner.uk.xensource.com>
	<CAPLaKK6wqa+VAxgzLWudQ2C2kaoXww9KK3BQhU4fKmoCAMFCzQ@mail.gmail.com>
	<1323860097.20077.394.camel@zakaz.uk.xensource.com>
	<CAPLaKK7Wv2HeRbg5Ze=B8DFe=wbzq=V35s6WVFXqrynh0ikRTw@mail.gmail.com>
	<20200.36683.601224.172611@mariner.uk.xensource.com>
	<CAPLaKK5h2PJko6o4v3usJkfttfdFqp9L6DEnfs0YYSSBWS63Eg@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323865369.20077.412.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 12 of 14 v4] libxl: set frontend status to 6
 on domain destroy
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gV2VkLCAyMDExLTEyLTE0IGF0IDEyOjEyICswMDAwLCBSb2dlciBQYXUgTW9ubsOpIHdyb3Rl
Ogo+IDIwMTEvMTIvMTQgSWFuIEphY2tzb24gPElhbi5KYWNrc29uQGV1LmNpdHJpeC5jb20+Ogo+
ID4+IFllcywgaWYgSSBkZWxldGUgdGhlIGZyb250ZW5kIGZyb20geGVuc3RvcmUsIHRoZSBkZXZp
Y2VzIGFyZSBkZXRhY2hlZC4KPiA+PiBBbnl3YXksIGRvaW5nIGl0IG9uZSB3YXkgb3IgYW5vdGhl
ciAoZGVsZXRpb24gb3Igc2V0dGluZyBzdGF0ZSB0byA2KQo+ID4+IGRvZXNuJ3QgcmVhbGx5IG1h
a2UgYSBkaWZmZXJlbmNlLCB5b3Ugc3RpbGwgaGF2ZSB0byB3YWl0IGZvciB0aGUKPiA+PiBiYWNr
ZW5kIHRvIGJlIGRpc2Nvbm5lY3RlZCAoZGV0YWNoZWQpIGJlZm9yZSBleGVjdXRpbmcgaG90cGx1
Zwo+ID4+IHNjcmlwdHMuCj4gPgo+ID4gU28gZGV2aWNlIGRlc3RydWN0aW9uIGNvdWxkIGJlIGFj
aGlldmVkIGJ5IHNpbXBseSBkZWxldGluZyB0aGUgYmFja2VuZAo+ID4gZGlyZWN0b3J5LiAgQnV0
LCB3ZSB3b3VsZCBuZWVkIHNvbWUgb3RoZXIgd2F5IHRvIGRldGVjdCB3aGVuIHRoZQo+ID4gYmFj
a2VuZCBoYXMgYWN0dWFsbHkgY2xvc2VkIHRoZSBkZXZpY2Ugc28gdGhhdCB3ZSBjYW4gcnVuIHRo
ZSBzY3JpcHQuCj4gCj4gRGV2aWNlIGRldGFjaCwgd2lsbCBpbiB0dXJuIGFsbG93cyBkZXN0cnVj
dGlvbiwgY2FuIGJlIGFjaGlldmVkIGluIHR3byB3YXlzOgo+IAo+ICAqIFNldCBmcm9udGVuZCBz
dGF0dXMgdG8gNi4KPiAgKiBSZW1vdmUgZnJvbnRlbmQgZW50cmllcy4KPiAKPiBUaGVyZSBpcyBu
byBuZWVkIHRvIGNoYW5nZSBiYWNrZW5kIGVudHJpZXMgdG8gZm9yY2UgZGV0YWNoIGEgZGV2aWNl
LgoKVGhlIGNvcnJlY3QgbWV0aG9kIGZvciBmb3JjaWJseSBkZXN0cm95aW5nIGEgZGV2aWNlIGlz
IHRvIHJlbW92ZSB0aGUKYmFja2VuZCBkaXJlY3RvcnkuCgpUaGUgY29ycmVjdCBtZXRob2QgdG8g
cGVyZm9ybSBhIGdyYWNlZnVsIHJlbW92ZSBpcyB0byBzZXQgdGhlIGJhY2tlbmQKc3RhdGUgdG8g
IjUiIGFuZCB3YWl0IGZvciBpdCB0byBjb29yZGluYXRlIHdpdGggdGhlIGd1ZXN0IHRvIHJlYWNo
IHN0YXRlCiI2Ii4gSG93ZXZlciB0aGlzIGlzIG5vdCBhIGZvcmNlZCBvcGVyYXRpb24gYW5kIG1h
eSBub3QgY29tcGxldGUgaW4gYQp0aW1lbHkgbWFubmVyIG9yIGluZGVlZCBhdCBhbGwuCgpTb21l
IGJhY2tlbmRzIGFsc28gc3VwcG9ydCBhbiAib25saW5lIiBub2RlIHdoaWNoLCBpZiBsZWZ0IHNl
dCB0byAxIHdoZW4Kc2V0dGluZyB0aGUgYmFja2VuZCBzdGF0ZSB0byA1IiBmb3IgYSBncmFjZWZ1
bCBzaHV0ZG93biwgY2F1c2VzIHRoZQpiYWNrZW5kIHRvIGRldGFjaCBidXQgcmVtYWluIGFjdGl2
ZSAoYXMgb3Bwb3NlZCB0byBzZWxmIGRlc3RydWN0aW5nKSBpbgp0aGUgZXhwZWN0YXRpb24gb2Yg
YSBmcm9udGVuZCByZWNvbm5lY3RpbmcgYWdhaW4gbGF0ZXIgLS0gdGhpcyBpcyB1c2VkCmZvciBl
eGFtcGxlIHdoZW4ga2V4ZWNpbmcgYSBQViBkb21haW4uCgpJbiBubyBjYXNlIHNob3VsZCB0aGUg
dG9vbHN0YWNrIGJlIG1lc3Npbmcgd2l0aCB0aGUgZnJvbnRlbmQgc3RhdGUsCmFsdGhvdWdoIG9i
dmlvdXNseSBpbiB0aGUgZGVzdHJveSBjYXNlIGl0IGlzIGF0IGxpYmVydHkgc2hvcnRseQphZnRl
cndhcmRzIHRvIGFsc28gbnVrZSB0aGUgZnJvbnRlbmQgZGlyZWN0b3J5LgoKSWFuLgoKCgpfX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFp
bGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tCmh0dHA6Ly9saXN0cy54ZW5z
b3VyY2UuY29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Wed Dec 14 12:25:00 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 12: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.xensource.com>)
	id 1RantA-0004PQ-5n; Wed, 14 Dec 2011 12:24:48 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rant9-0004Ov-CY
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 12:24:47 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1323865431!5532439!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTc4Ng==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9266 invoked from network); 14 Dec 2011 12:23:52 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Dec 2011 12:23:52 -0000
X-IronPort-AV: E=Sophos;i="4.71,351,1320624000"; 
   d="scan'208";a="9461582"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Dec 2011 12:22:49 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 14 Dec 2011 12:22:49 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau =?ISO-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
Date: Wed, 14 Dec 2011 12:22:49 +0000
In-Reply-To: <CAPLaKK5h2PJko6o4v3usJkfttfdFqp9L6DEnfs0YYSSBWS63Eg@mail.gmail.com>
References: <patchbomb.1323768375@loki.upc.es>
	<35c322e6020501447936.1323768387@loki.upc.es>
	<20199.26896.928532.781947@mariner.uk.xensource.com>
	<CAPLaKK6wqa+VAxgzLWudQ2C2kaoXww9KK3BQhU4fKmoCAMFCzQ@mail.gmail.com>
	<1323860097.20077.394.camel@zakaz.uk.xensource.com>
	<CAPLaKK7Wv2HeRbg5Ze=B8DFe=wbzq=V35s6WVFXqrynh0ikRTw@mail.gmail.com>
	<20200.36683.601224.172611@mariner.uk.xensource.com>
	<CAPLaKK5h2PJko6o4v3usJkfttfdFqp9L6DEnfs0YYSSBWS63Eg@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323865369.20077.412.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 12 of 14 v4] libxl: set frontend status to 6
 on domain destroy
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gV2VkLCAyMDExLTEyLTE0IGF0IDEyOjEyICswMDAwLCBSb2dlciBQYXUgTW9ubsOpIHdyb3Rl
Ogo+IDIwMTEvMTIvMTQgSWFuIEphY2tzb24gPElhbi5KYWNrc29uQGV1LmNpdHJpeC5jb20+Ogo+
ID4+IFllcywgaWYgSSBkZWxldGUgdGhlIGZyb250ZW5kIGZyb20geGVuc3RvcmUsIHRoZSBkZXZp
Y2VzIGFyZSBkZXRhY2hlZC4KPiA+PiBBbnl3YXksIGRvaW5nIGl0IG9uZSB3YXkgb3IgYW5vdGhl
ciAoZGVsZXRpb24gb3Igc2V0dGluZyBzdGF0ZSB0byA2KQo+ID4+IGRvZXNuJ3QgcmVhbGx5IG1h
a2UgYSBkaWZmZXJlbmNlLCB5b3Ugc3RpbGwgaGF2ZSB0byB3YWl0IGZvciB0aGUKPiA+PiBiYWNr
ZW5kIHRvIGJlIGRpc2Nvbm5lY3RlZCAoZGV0YWNoZWQpIGJlZm9yZSBleGVjdXRpbmcgaG90cGx1
Zwo+ID4+IHNjcmlwdHMuCj4gPgo+ID4gU28gZGV2aWNlIGRlc3RydWN0aW9uIGNvdWxkIGJlIGFj
aGlldmVkIGJ5IHNpbXBseSBkZWxldGluZyB0aGUgYmFja2VuZAo+ID4gZGlyZWN0b3J5LiAgQnV0
LCB3ZSB3b3VsZCBuZWVkIHNvbWUgb3RoZXIgd2F5IHRvIGRldGVjdCB3aGVuIHRoZQo+ID4gYmFj
a2VuZCBoYXMgYWN0dWFsbHkgY2xvc2VkIHRoZSBkZXZpY2Ugc28gdGhhdCB3ZSBjYW4gcnVuIHRo
ZSBzY3JpcHQuCj4gCj4gRGV2aWNlIGRldGFjaCwgd2lsbCBpbiB0dXJuIGFsbG93cyBkZXN0cnVj
dGlvbiwgY2FuIGJlIGFjaGlldmVkIGluIHR3byB3YXlzOgo+IAo+ICAqIFNldCBmcm9udGVuZCBz
dGF0dXMgdG8gNi4KPiAgKiBSZW1vdmUgZnJvbnRlbmQgZW50cmllcy4KPiAKPiBUaGVyZSBpcyBu
byBuZWVkIHRvIGNoYW5nZSBiYWNrZW5kIGVudHJpZXMgdG8gZm9yY2UgZGV0YWNoIGEgZGV2aWNl
LgoKVGhlIGNvcnJlY3QgbWV0aG9kIGZvciBmb3JjaWJseSBkZXN0cm95aW5nIGEgZGV2aWNlIGlz
IHRvIHJlbW92ZSB0aGUKYmFja2VuZCBkaXJlY3RvcnkuCgpUaGUgY29ycmVjdCBtZXRob2QgdG8g
cGVyZm9ybSBhIGdyYWNlZnVsIHJlbW92ZSBpcyB0byBzZXQgdGhlIGJhY2tlbmQKc3RhdGUgdG8g
IjUiIGFuZCB3YWl0IGZvciBpdCB0byBjb29yZGluYXRlIHdpdGggdGhlIGd1ZXN0IHRvIHJlYWNo
IHN0YXRlCiI2Ii4gSG93ZXZlciB0aGlzIGlzIG5vdCBhIGZvcmNlZCBvcGVyYXRpb24gYW5kIG1h
eSBub3QgY29tcGxldGUgaW4gYQp0aW1lbHkgbWFubmVyIG9yIGluZGVlZCBhdCBhbGwuCgpTb21l
IGJhY2tlbmRzIGFsc28gc3VwcG9ydCBhbiAib25saW5lIiBub2RlIHdoaWNoLCBpZiBsZWZ0IHNl
dCB0byAxIHdoZW4Kc2V0dGluZyB0aGUgYmFja2VuZCBzdGF0ZSB0byA1IiBmb3IgYSBncmFjZWZ1
bCBzaHV0ZG93biwgY2F1c2VzIHRoZQpiYWNrZW5kIHRvIGRldGFjaCBidXQgcmVtYWluIGFjdGl2
ZSAoYXMgb3Bwb3NlZCB0byBzZWxmIGRlc3RydWN0aW5nKSBpbgp0aGUgZXhwZWN0YXRpb24gb2Yg
YSBmcm9udGVuZCByZWNvbm5lY3RpbmcgYWdhaW4gbGF0ZXIgLS0gdGhpcyBpcyB1c2VkCmZvciBl
eGFtcGxlIHdoZW4ga2V4ZWNpbmcgYSBQViBkb21haW4uCgpJbiBubyBjYXNlIHNob3VsZCB0aGUg
dG9vbHN0YWNrIGJlIG1lc3Npbmcgd2l0aCB0aGUgZnJvbnRlbmQgc3RhdGUsCmFsdGhvdWdoIG9i
dmlvdXNseSBpbiB0aGUgZGVzdHJveSBjYXNlIGl0IGlzIGF0IGxpYmVydHkgc2hvcnRseQphZnRl
cndhcmRzIHRvIGFsc28gbnVrZSB0aGUgZnJvbnRlbmQgZGlyZWN0b3J5LgoKSWFuLgoKCgpfX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFp
bGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tCmh0dHA6Ly9saXN0cy54ZW5z
b3VyY2UuY29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Wed Dec 14 12:25:54 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 12:25:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ranu5-0004Tv-Kb; Wed, 14 Dec 2011 12:25:45 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Ranu4-0004TC-GB
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 12:25:44 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1323865489!7439868!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTc4Ng==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3327 invoked from network); 14 Dec 2011 12:24:49 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Dec 2011 12:24:49 -0000
X-IronPort-AV: E=Sophos;i="4.71,351,1320624000"; 
   d="scan'208";a="9461630"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Dec 2011 12:24:49 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 14 Dec 2011 12:24:49 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Paul Durrant <Paul.Durrant@citrix.com>
Date: Wed, 14 Dec 2011 12:24:48 +0000
In-Reply-To: <291EDFCB1E9E224A99088639C4762022B598ED0D72@LONPMAILBOX01.citrite.net>
References: <patchbomb.1323855070@cosworth.uk.xensource.com>
	<fded65be5d82461e87de.1323855071@cosworth.uk.xensource.com>
	<1323857513.20077.380.camel@zakaz.uk.xensource.com>
	<291EDFCB1E9E224A99088639C4762022B5988E58B7@LONPMAILBOX01.citrite.net>
	<1323862734.20077.396.camel@zakaz.uk.xensource.com>
	<291EDFCB1E9E224A99088639C4762022B598ED0D72@LONPMAILBOX01.citrite.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323865488.20077.413.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 1 of 2] Re-name xenstore key used to save VM
 generation ID buffer address
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2011-12-14 at 11:49 +0000, Paul Durrant wrote:
> > -----Original Message-----
> > From: Ian Campbell
> > Sent: 14 December 2011 11:39
> > To: Paul Durrant
> > Cc: xen-devel@lists.xensource.com
> > Subject: RE: [Xen-devel] [PATCH 1 of 2] Re-name xenstore key used to
> > save VM generation ID buffer address
> > 
> > On Wed, 2011-12-14 at 11:17 +0000, Paul Durrant wrote:
> > >
> > > > -----Original Message-----
> > > > From: Ian Campbell
> > > > Sent: 14 December 2011 10:12
> > > > To: Paul Durrant
> > > > Cc: xen-devel@lists.xensource.com
> > > > Subject: Re: [Xen-devel] [PATCH 1 of 2] Re-name xenstore key
> > used to
> > > > save VM generation ID buffer address
> > > >
> > > > On Wed, 2011-12-14 at 09:31 +0000, Paul Durrant wrote:
> > > > > # HG changeset patch
> > > > > # User Paul Durrant <paul.durrant@citrix.com> # Date
> > 1323854952 0
> > > > #
> > > > > Node ID fded65be5d82461e87de54960db14ce8feb4625f
> > > > > # Parent  03138a08366b895d79e143119d4c9c72833cdbcd
> > > > > Re-name xenstore key used to save VM generation ID buffer
> > address.
> > > > >
> > > > > Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
> > > > >
> > > > > diff -r 03138a08366b -r fded65be5d82
> > > > tools/firmware/hvmloader/acpi/build.c
> > > > > --- a/tools/firmware/hvmloader/acpi/build.c	Fri Dec 09
> > 16:19:36
> > > > 2011 +0000
> > > > > +++ b/tools/firmware/hvmloader/acpi/build.c	Wed Dec 14
> > 09:29:12
> > > > 2011 +0000
> > > > > @@ -309,7 +309,7 @@ unsigned long new_vm_gid(void)
> > > > >      if ( snprintf(addr, sizeof(addr), "0x%lx",
> > virt_to_phys(buf))
> > > > >           >= sizeof(addr) )
> > > > >          return 0;
> > > > > -    xenstore_write("data/generation-id", addr);
> > > > > +    xenstore_write("data/generation-id-address", addr);
> > > >
> > > > data/ seems like an odd home for this, isn't that the area where
> > > > guests can expect to store their own bits and bobs, agent stuff
> > etc?
> > > >
> > >
> > > No what data is 'for' as such. It seemed like a reasonable place
> > to
> > > put something created by the guest and for the tools' consumption.
> > 
> > Although it runs in guest context hvmloader should really be
> > considered an extension of the tools and not part of the guest.
> > 
> > > I could move it under hvmloader, but is that the right place?
> > > hvmloader/bios is *read* by hvmloader, not written by it.
> > 
> > I think it's a good as anywhere else.
> > 
> 
> Ok, does that mean that we should create hmvloader as writable by the
> guest, or should we special-case the generation-id-address key?

Just the specific key.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 12:25:54 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 12:25:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ranu5-0004Tv-Kb; Wed, 14 Dec 2011 12:25:45 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Ranu4-0004TC-GB
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 12:25:44 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1323865489!7439868!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTc4Ng==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3327 invoked from network); 14 Dec 2011 12:24:49 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Dec 2011 12:24:49 -0000
X-IronPort-AV: E=Sophos;i="4.71,351,1320624000"; 
   d="scan'208";a="9461630"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Dec 2011 12:24:49 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 14 Dec 2011 12:24:49 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Paul Durrant <Paul.Durrant@citrix.com>
Date: Wed, 14 Dec 2011 12:24:48 +0000
In-Reply-To: <291EDFCB1E9E224A99088639C4762022B598ED0D72@LONPMAILBOX01.citrite.net>
References: <patchbomb.1323855070@cosworth.uk.xensource.com>
	<fded65be5d82461e87de.1323855071@cosworth.uk.xensource.com>
	<1323857513.20077.380.camel@zakaz.uk.xensource.com>
	<291EDFCB1E9E224A99088639C4762022B5988E58B7@LONPMAILBOX01.citrite.net>
	<1323862734.20077.396.camel@zakaz.uk.xensource.com>
	<291EDFCB1E9E224A99088639C4762022B598ED0D72@LONPMAILBOX01.citrite.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323865488.20077.413.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 1 of 2] Re-name xenstore key used to save VM
 generation ID buffer address
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2011-12-14 at 11:49 +0000, Paul Durrant wrote:
> > -----Original Message-----
> > From: Ian Campbell
> > Sent: 14 December 2011 11:39
> > To: Paul Durrant
> > Cc: xen-devel@lists.xensource.com
> > Subject: RE: [Xen-devel] [PATCH 1 of 2] Re-name xenstore key used to
> > save VM generation ID buffer address
> > 
> > On Wed, 2011-12-14 at 11:17 +0000, Paul Durrant wrote:
> > >
> > > > -----Original Message-----
> > > > From: Ian Campbell
> > > > Sent: 14 December 2011 10:12
> > > > To: Paul Durrant
> > > > Cc: xen-devel@lists.xensource.com
> > > > Subject: Re: [Xen-devel] [PATCH 1 of 2] Re-name xenstore key
> > used to
> > > > save VM generation ID buffer address
> > > >
> > > > On Wed, 2011-12-14 at 09:31 +0000, Paul Durrant wrote:
> > > > > # HG changeset patch
> > > > > # User Paul Durrant <paul.durrant@citrix.com> # Date
> > 1323854952 0
> > > > #
> > > > > Node ID fded65be5d82461e87de54960db14ce8feb4625f
> > > > > # Parent  03138a08366b895d79e143119d4c9c72833cdbcd
> > > > > Re-name xenstore key used to save VM generation ID buffer
> > address.
> > > > >
> > > > > Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
> > > > >
> > > > > diff -r 03138a08366b -r fded65be5d82
> > > > tools/firmware/hvmloader/acpi/build.c
> > > > > --- a/tools/firmware/hvmloader/acpi/build.c	Fri Dec 09
> > 16:19:36
> > > > 2011 +0000
> > > > > +++ b/tools/firmware/hvmloader/acpi/build.c	Wed Dec 14
> > 09:29:12
> > > > 2011 +0000
> > > > > @@ -309,7 +309,7 @@ unsigned long new_vm_gid(void)
> > > > >      if ( snprintf(addr, sizeof(addr), "0x%lx",
> > virt_to_phys(buf))
> > > > >           >= sizeof(addr) )
> > > > >          return 0;
> > > > > -    xenstore_write("data/generation-id", addr);
> > > > > +    xenstore_write("data/generation-id-address", addr);
> > > >
> > > > data/ seems like an odd home for this, isn't that the area where
> > > > guests can expect to store their own bits and bobs, agent stuff
> > etc?
> > > >
> > >
> > > No what data is 'for' as such. It seemed like a reasonable place
> > to
> > > put something created by the guest and for the tools' consumption.
> > 
> > Although it runs in guest context hvmloader should really be
> > considered an extension of the tools and not part of the guest.
> > 
> > > I could move it under hvmloader, but is that the right place?
> > > hvmloader/bios is *read* by hvmloader, not written by it.
> > 
> > I think it's a good as anywhere else.
> > 
> 
> Ok, does that mean that we should create hmvloader as writable by the
> guest, or should we special-case the generation-id-address key?

Just the specific key.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 12:26:30 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 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.xensource.com>)
	id 1Ranuf-0004Xz-3L; Wed, 14 Dec 2011 12:26:21 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Ranuc-0004XF-VV
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 12:26:19 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1323865415!56121565!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTc4Ng==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19221 invoked from network); 14 Dec 2011 12:23:35 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Dec 2011 12:23:35 -0000
X-IronPort-AV: E=Sophos;i="4.71,351,1320624000"; 
   d="scan'208";a="9461644"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Dec 2011 12:25:25 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 14 Dec 2011 12:25:25 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau =?ISO-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
Date: Wed, 14 Dec 2011 12:25:25 +0000
In-Reply-To: <CAPLaKK6dHr8fBujk-BSFO=-Ly3ZcQVEGTJcAwQRkfSWqk2Wb4g@mail.gmail.com>
References: <patchbomb.1323768375@loki.upc.es>
	<35c322e6020501447936.1323768387@loki.upc.es>
	<20199.26896.928532.781947@mariner.uk.xensource.com>
	<CAPLaKK6wqa+VAxgzLWudQ2C2kaoXww9KK3BQhU4fKmoCAMFCzQ@mail.gmail.com>
	<1323860097.20077.394.camel@zakaz.uk.xensource.com>
	<CAPLaKK7Wv2HeRbg5Ze=B8DFe=wbzq=V35s6WVFXqrynh0ikRTw@mail.gmail.com>
	<1323863914.20077.400.camel@zakaz.uk.xensource.com>
	<CAPLaKK6dHr8fBujk-BSFO=-Ly3ZcQVEGTJcAwQRkfSWqk2Wb4g@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323865525.20077.414.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 12 of 14 v4] libxl: set frontend status to 6
 on domain destroy
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gV2VkLCAyMDExLTEyLTE0IGF0IDEyOjE4ICswMDAwLCBSb2dlciBQYXUgTW9ubsOpIHdyb3Rl
Ogo+IAo+IE5vIGx1Y2ssIHNldHRpbmcgYmFja2VuZCBzdGF0ZSB0byA1IGRpZCBub3QgbWFrZSB0
aGUga2VybmVsIGRldGFjaCB0aGUKPiBkZXZpY2UuIEl0IHNlZW1zIGxpa2UgdGhlIGtlcm5lbCBp
cyBvbmx5IHdhdGNoaW5nIGZyb250ZW5kIHhlbnN0b3JlCj4gZW50cmllcy4KCkRvZXMgaG90IHJl
bW92YWwgb2YgZGV2aWNlcyB3b3JrPyBUaGlzIHVzZXMgdGhlIHNhbWUgbWVjaGFuaXNtLgoKSWFu
LgoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1k
ZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbnNvdXJjZS5jb20KaHR0cDovL2xp
c3RzLnhlbnNvdXJjZS5jb20veGVuLWRldmVsCg==

From xen-devel-bounces@lists.xensource.com Wed Dec 14 12:26:30 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 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.xensource.com>)
	id 1Ranuf-0004Xz-3L; Wed, 14 Dec 2011 12:26:21 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Ranuc-0004XF-VV
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 12:26:19 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1323865415!56121565!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTc4Ng==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19221 invoked from network); 14 Dec 2011 12:23:35 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Dec 2011 12:23:35 -0000
X-IronPort-AV: E=Sophos;i="4.71,351,1320624000"; 
   d="scan'208";a="9461644"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Dec 2011 12:25:25 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 14 Dec 2011 12:25:25 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau =?ISO-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
Date: Wed, 14 Dec 2011 12:25:25 +0000
In-Reply-To: <CAPLaKK6dHr8fBujk-BSFO=-Ly3ZcQVEGTJcAwQRkfSWqk2Wb4g@mail.gmail.com>
References: <patchbomb.1323768375@loki.upc.es>
	<35c322e6020501447936.1323768387@loki.upc.es>
	<20199.26896.928532.781947@mariner.uk.xensource.com>
	<CAPLaKK6wqa+VAxgzLWudQ2C2kaoXww9KK3BQhU4fKmoCAMFCzQ@mail.gmail.com>
	<1323860097.20077.394.camel@zakaz.uk.xensource.com>
	<CAPLaKK7Wv2HeRbg5Ze=B8DFe=wbzq=V35s6WVFXqrynh0ikRTw@mail.gmail.com>
	<1323863914.20077.400.camel@zakaz.uk.xensource.com>
	<CAPLaKK6dHr8fBujk-BSFO=-Ly3ZcQVEGTJcAwQRkfSWqk2Wb4g@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323865525.20077.414.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 12 of 14 v4] libxl: set frontend status to 6
 on domain destroy
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gV2VkLCAyMDExLTEyLTE0IGF0IDEyOjE4ICswMDAwLCBSb2dlciBQYXUgTW9ubsOpIHdyb3Rl
Ogo+IAo+IE5vIGx1Y2ssIHNldHRpbmcgYmFja2VuZCBzdGF0ZSB0byA1IGRpZCBub3QgbWFrZSB0
aGUga2VybmVsIGRldGFjaCB0aGUKPiBkZXZpY2UuIEl0IHNlZW1zIGxpa2UgdGhlIGtlcm5lbCBp
cyBvbmx5IHdhdGNoaW5nIGZyb250ZW5kIHhlbnN0b3JlCj4gZW50cmllcy4KCkRvZXMgaG90IHJl
bW92YWwgb2YgZGV2aWNlcyB3b3JrPyBUaGlzIHVzZXMgdGhlIHNhbWUgbWVjaGFuaXNtLgoKSWFu
LgoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1k
ZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbnNvdXJjZS5jb20KaHR0cDovL2xp
c3RzLnhlbnNvdXJjZS5jb20veGVuLWRldmVsCg==

From xen-devel-bounces@lists.xensource.com Wed Dec 14 12:29:15 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 12:29:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RanxH-0004pc-Mn; Wed, 14 Dec 2011 12:29:03 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1RanxG-0004pI-Ja
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 12:29:02 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1323865685!7921713!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjA4OTk=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32109 invoked from network); 14 Dec 2011 12:28:07 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Dec 2011 12:28:07 -0000
X-IronPort-AV: E=Sophos;i="4.71,351,1320642000"; d="scan'208";a="174093140"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Dec 2011 07:28:05 -0500
Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX01.citrite.net
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Wed, 14 Dec 2011
	07:28:05 -0500
Message-ID: <4EE89654.5040905@citrix.com>
Date: Wed, 14 Dec 2011 12:28:04 +0000
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20111110 Icedove/3.0.11
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
References: <4EE675A8.3030609@niemail.de> <4EE71663.5040308@gmail.com>
	<CAJeBh4sxdNTxM_oLFAuA6Mw75=LaYysrpS5b8NsZMbkf_swNVw@mail.gmail.com>
	<4EE72A94.6040904@gmail.com> <4EE75080.1000909@citrix.com>
	<4EE7BE1B.6070509@gmail.com>
	<20111213214522.GB29005@andromeda.dapyr.net>
In-Reply-To: <20111213214522.GB29005@andromeda.dapyr.net>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	George Shuklin <george.shuklin@gmail.com>,
	"sandr8@gmail.com" <sandr8@gmail.com>
Subject: Re: [Xen-devel] a ton of kernel issues
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 13/12/11 21:45, Konrad Rzeszutek Wilk wrote:
> On Wed, Dec 14, 2011 at 01:05:31AM +0400, George Shuklin wrote:
>>
>> On 13.12.2011 17:17, David Vrabel wrote:
>>>>>> pv_ops is still have some issues with memory limits, but any
>>>>>> new kernel (3.0+) will boot normal and operates with very
>>>>>> minor glitches. Older pv_ops (f.e. debian 2.6.32) have some
>>>>>> more major issues.
>>>>> what glitches should one expect with 3.0+, and having the choice,
>>>>> would it be better to go with 3.1 or even 3.2?
>>>> Right now I know about two of them:
>>>> When you set up memory for virtual machine using xenballon, value in
>>>> dom0 differ from value in domU. The issue is that -xen kernels 'hide'
>>>> some memory in 'used' memory, and pv-ops just reducing TotalMem to value
>>>> without that memory. Practically that means if you set up memory for
>>>> domain to 2GiB client will saw only 1.95GiB and so on.
>>> This really makes no practical difference.  The memory is "used" is
>>> either case and the different reporting is a side-effect of the change
>>> in how certain memory allocations are done.
> 
> David,
> 
> You are thinking that this is the vmalloc vs kmalloc memory for the
> frontends?

That wasn't what I was thinking.  When I looked (not very hard) at this
in dom0 I thought most of it was the swiotlb buffer.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 12:29:15 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 12:29:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RanxH-0004pc-Mn; Wed, 14 Dec 2011 12:29:03 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1RanxG-0004pI-Ja
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 12:29:02 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1323865685!7921713!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjA4OTk=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32109 invoked from network); 14 Dec 2011 12:28:07 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Dec 2011 12:28:07 -0000
X-IronPort-AV: E=Sophos;i="4.71,351,1320642000"; d="scan'208";a="174093140"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Dec 2011 07:28:05 -0500
Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX01.citrite.net
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Wed, 14 Dec 2011
	07:28:05 -0500
Message-ID: <4EE89654.5040905@citrix.com>
Date: Wed, 14 Dec 2011 12:28:04 +0000
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20111110 Icedove/3.0.11
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
References: <4EE675A8.3030609@niemail.de> <4EE71663.5040308@gmail.com>
	<CAJeBh4sxdNTxM_oLFAuA6Mw75=LaYysrpS5b8NsZMbkf_swNVw@mail.gmail.com>
	<4EE72A94.6040904@gmail.com> <4EE75080.1000909@citrix.com>
	<4EE7BE1B.6070509@gmail.com>
	<20111213214522.GB29005@andromeda.dapyr.net>
In-Reply-To: <20111213214522.GB29005@andromeda.dapyr.net>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	George Shuklin <george.shuklin@gmail.com>,
	"sandr8@gmail.com" <sandr8@gmail.com>
Subject: Re: [Xen-devel] a ton of kernel issues
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 13/12/11 21:45, Konrad Rzeszutek Wilk wrote:
> On Wed, Dec 14, 2011 at 01:05:31AM +0400, George Shuklin wrote:
>>
>> On 13.12.2011 17:17, David Vrabel wrote:
>>>>>> pv_ops is still have some issues with memory limits, but any
>>>>>> new kernel (3.0+) will boot normal and operates with very
>>>>>> minor glitches. Older pv_ops (f.e. debian 2.6.32) have some
>>>>>> more major issues.
>>>>> what glitches should one expect with 3.0+, and having the choice,
>>>>> would it be better to go with 3.1 or even 3.2?
>>>> Right now I know about two of them:
>>>> When you set up memory for virtual machine using xenballon, value in
>>>> dom0 differ from value in domU. The issue is that -xen kernels 'hide'
>>>> some memory in 'used' memory, and pv-ops just reducing TotalMem to value
>>>> without that memory. Practically that means if you set up memory for
>>>> domain to 2GiB client will saw only 1.95GiB and so on.
>>> This really makes no practical difference.  The memory is "used" is
>>> either case and the different reporting is a side-effect of the change
>>> in how certain memory allocations are done.
> 
> David,
> 
> You are thinking that this is the vmalloc vs kmalloc memory for the
> frontends?

That wasn't what I was thinking.  When I looked (not very hard) at this
in dom0 I thought most of it was the swiotlb buffer.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 12:44:05 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 12:44:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaoBa-0005GR-50; Wed, 14 Dec 2011 12:43:50 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RaoBY-0005GM-V1
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 12:43:49 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1323866538!50580488!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11677 invoked from network); 14 Dec 2011 12:42:19 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-6.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Dec 2011 12:42:19 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 14 Dec 2011 12:42:57 +0000
Message-Id: <4EE8A7DE0200007800067B17@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 14 Dec 2011 12:42:54 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Christoph Egger" <Christoph.Egger@amd.com>
References: <CB0BC143.35A76%keir@xen.org> <4EE75FB4.30609@amd.com>
	<4EE7776E0200007800067623@nat28.tlf.novell.com>
	<4EE877A8.7080706@amd.com>
In-Reply-To: <4EE877A8.7080706@amd.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Keir Fraser <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH] microcode fix
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 14.12.11 at 11:17, Christoph Egger <Christoph.Egger@amd.com> wrote:
>+struct mpbhdr {
>+    uint32_t type;
>+    uint32_t len;
>+    const uint8_t data;

What's this? If anything, this should be data[] (and no need for const).

>@@ -141,16 +142,19 @@ static int apply_microcode(int cpu)
>     struct ucode_cpu_info *uci = &per_cpu(ucode_cpu_info, cpu);
>     uint32_t rev;
>     struct microcode_amd *mc_amd = uci->mc.mc_amd;
>+    struct microcode_header_amd *hdr = mc_amd->mpb;

Using mc_amd here, but ...
 
>     /* We should bind the task to the CPU */
>     BUG_ON(raw_smp_processor_id() != cpu);
> 
>     if ( mc_amd == NULL )
>         return -EINVAL;

... the NULL check is only here.

>+    if ( mc_amd->mpb == NULL )
>+        return -EINVAL;

And quite obviously you should preferably use the local variable
here...

>-    wrmsrl(MSR_AMD_PATCHLOADER, (unsigned long)&mc_amd->hdr.data_code);
>+    wrmsrl(MSR_AMD_PATCHLOADER, (unsigned long)mc_amd->mpb);

... and here.

>+    printk(KERN_DEBUG "microcode: size %lu, block size %u, offset %ld\n",
>+           (unsigned long)bufsize, mpbuf->len, off);

The cast is pointless; to avoid it, use %zu as format string or declare
the parameter as 'unsigned long'.

>+    if (mc_amd->mpb_size < mpbuf->len) {
>+        xfree(mc_amd->mpb);
>+        mc_amd->mpb = xmalloc_bytes(mpbuf->len);
>+        mc_amd->mpb_size = mpbuf->len;

NULL check missing here (and in such event the clearing of
->mpb_size).

>+    memcpy(mc_amd->mpb, (const void *)&mpbuf->data, mpbuf->len);

Unnecessary cast.

>         printk(KERN_ERR "microcode: error! Wrong "
>-               "microcode patch file magic\n");
>+            "microcode patch file magic\n");

Why are you still mis-adjusting indentation here?

>+    mc_amd = xmalloc_bytes(sizeof(*mc_amd));

As said during the first review round - this ought to be

    mc_amd = xmalloc(struct microcode_amd);

>+    while ( (ret = get_next_ucode_from_buffer_amd(mc_amd,
>+        buf, bufsize, &offset)) == 0 )

Bad indentation.

>+    ASSERT(src != NULL);

Pointless.

>+        if (mc_amd != NULL) {

While this NULL check is needed, ...

>+            if (mc_amd->equiv_cpu_table)

... this and ...

>+                xfree(mc_amd->equiv_cpu_table);
>+            if (mc_amd->mpb)

... this are pointless.

>+                xfree(mc_amd->mpb);
>+            xfree(mc_amd);
>+        }
>+
>+        mc_amd = xmalloc(struct microcode_amd);

    uci->mc.mc_amd = mc_amd;

>         if ( !mc_amd )

(as was the case in the original code). No need to do this once in the
success path and once in the error one.

>+    uci->mc.mc_amd = mc_amd = NULL;
>+    return -ENOMEM;

Even if it was necessary to keep it this way, initializing a local variable
immediately before returning is bogus (and calling for a compiler
warning and hence a build failure due to -Werror sooner or later).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 12:44:05 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 12:44:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaoBa-0005GR-50; Wed, 14 Dec 2011 12:43:50 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RaoBY-0005GM-V1
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 12:43:49 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1323866538!50580488!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11677 invoked from network); 14 Dec 2011 12:42:19 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-6.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Dec 2011 12:42:19 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 14 Dec 2011 12:42:57 +0000
Message-Id: <4EE8A7DE0200007800067B17@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 14 Dec 2011 12:42:54 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Christoph Egger" <Christoph.Egger@amd.com>
References: <CB0BC143.35A76%keir@xen.org> <4EE75FB4.30609@amd.com>
	<4EE7776E0200007800067623@nat28.tlf.novell.com>
	<4EE877A8.7080706@amd.com>
In-Reply-To: <4EE877A8.7080706@amd.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Keir Fraser <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH] microcode fix
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 14.12.11 at 11:17, Christoph Egger <Christoph.Egger@amd.com> wrote:
>+struct mpbhdr {
>+    uint32_t type;
>+    uint32_t len;
>+    const uint8_t data;

What's this? If anything, this should be data[] (and no need for const).

>@@ -141,16 +142,19 @@ static int apply_microcode(int cpu)
>     struct ucode_cpu_info *uci = &per_cpu(ucode_cpu_info, cpu);
>     uint32_t rev;
>     struct microcode_amd *mc_amd = uci->mc.mc_amd;
>+    struct microcode_header_amd *hdr = mc_amd->mpb;

Using mc_amd here, but ...
 
>     /* We should bind the task to the CPU */
>     BUG_ON(raw_smp_processor_id() != cpu);
> 
>     if ( mc_amd == NULL )
>         return -EINVAL;

... the NULL check is only here.

>+    if ( mc_amd->mpb == NULL )
>+        return -EINVAL;

And quite obviously you should preferably use the local variable
here...

>-    wrmsrl(MSR_AMD_PATCHLOADER, (unsigned long)&mc_amd->hdr.data_code);
>+    wrmsrl(MSR_AMD_PATCHLOADER, (unsigned long)mc_amd->mpb);

... and here.

>+    printk(KERN_DEBUG "microcode: size %lu, block size %u, offset %ld\n",
>+           (unsigned long)bufsize, mpbuf->len, off);

The cast is pointless; to avoid it, use %zu as format string or declare
the parameter as 'unsigned long'.

>+    if (mc_amd->mpb_size < mpbuf->len) {
>+        xfree(mc_amd->mpb);
>+        mc_amd->mpb = xmalloc_bytes(mpbuf->len);
>+        mc_amd->mpb_size = mpbuf->len;

NULL check missing here (and in such event the clearing of
->mpb_size).

>+    memcpy(mc_amd->mpb, (const void *)&mpbuf->data, mpbuf->len);

Unnecessary cast.

>         printk(KERN_ERR "microcode: error! Wrong "
>-               "microcode patch file magic\n");
>+            "microcode patch file magic\n");

Why are you still mis-adjusting indentation here?

>+    mc_amd = xmalloc_bytes(sizeof(*mc_amd));

As said during the first review round - this ought to be

    mc_amd = xmalloc(struct microcode_amd);

>+    while ( (ret = get_next_ucode_from_buffer_amd(mc_amd,
>+        buf, bufsize, &offset)) == 0 )

Bad indentation.

>+    ASSERT(src != NULL);

Pointless.

>+        if (mc_amd != NULL) {

While this NULL check is needed, ...

>+            if (mc_amd->equiv_cpu_table)

... this and ...

>+                xfree(mc_amd->equiv_cpu_table);
>+            if (mc_amd->mpb)

... this are pointless.

>+                xfree(mc_amd->mpb);
>+            xfree(mc_amd);
>+        }
>+
>+        mc_amd = xmalloc(struct microcode_amd);

    uci->mc.mc_amd = mc_amd;

>         if ( !mc_amd )

(as was the case in the original code). No need to do this once in the
success path and once in the error one.

>+    uci->mc.mc_amd = mc_amd = NULL;
>+    return -ENOMEM;

Even if it was necessary to keep it this way, initializing a local variable
immediately before returning is bogus (and calling for a compiler
warning and hence a build failure due to -Werror sooner or later).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 12:59:55 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 12:59:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaoQo-0005RV-Lj; Wed, 14 Dec 2011 12:59:34 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RaoQm-0005RQ-Hu
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 12:59:32 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-13.tower-216.messagelabs.com!1323867517!6836444!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31225 invoked from network); 14 Dec 2011 12:58:37 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-13.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Dec 2011 12:58:37 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RaoPp-000JLP-AL; Wed, 14 Dec 2011 12:58:33 +0000
Date: Wed, 14 Dec 2011 12:58:33 +0000
From: Tim Deegan <tim@xen.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20111214125833.GA51060@ocelot.phlegethon.org>
References: <CAPE0SYwsqRKDuPTz66r0nTVPYcsFx0Dk2j0pWpCiHELuU5W2iA@mail.gmail.com>
	<4EE881270200007800067A65@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4EE881270200007800067A65@nat28.tlf.novell.com>
User-Agent: Mutt/1.4.2.1i
Cc: Liwei <xieliwei@gmail.com>, xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] PTE Write access is not set
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 09:57 +0000 on 14 Dec (1323856663), Jan Beulich wrote:
> > (XEN) realmode.c:115:d9 Failed to emulate insn.
> > (XEN) realmode.c:165:d9 Real-mode emulation failed @ e40a:00005f6c: d9
> > 33 01 fc 30 34
> 
> ... if this is Linux I'm having a rather hard time seeing why it would
> enter realmode at normal run time (and then even use floating point
> instructions there). This would be expected at boot time and at most
> during guest-internal suspend/resume, but I'm sure you would have
> mentioned if the guest was in the process of doing the latter (and
> you excluded the former).
> 
> I'm rather suspecting the VM to have gone astray earlier.
> 
> > (XEN) domain_crash called from realmode.c:166
> > (XEN) Domain 9 (vcpu#0) crashed on cpu#6:
> > (XEN) ----[ Xen-4.1.3-rc1-pre  x86_64  debug=n  Not tainted ]----
> > (XEN) CPU:    6
> > (XEN) RIP:    e40a:[<0000000000005f6c>]
> > (XEN) RFLAGS: 0000000000010002   CONTEXT: hvm guest
> > (XEN) rax: 000000000000e7e5   rbx: 0000000000000000   rcx: 00000000000d0000
> > (XEN) rdx: 00000000000001f7   rsi: 0000000000000000   rdi: 0000000000000dba
> > (XEN) rbp: 0000000000000182   rsp: 0000000000000db0   r8:  0000000000000000
> > (XEN) r9:  0000000000000000   r10: 0000000000000000   r11: 0000000000000000
> > (XEN) r12: 0000000000000000   r13: 0000000000000000   r14: 0000000000000000
> > (XEN) r15: 0000000000000000   cr0: 0000000000000010   cr4: 0000000000000000
> > (XEN) cr3: 0000000000000000   cr2: 0000000000000000
> > (XEN) ds: 9fc0   es: 9e00   fs: 0000   gs: 0000   ss: 9e00   cs: e40a

I'd say the guest has recently rebooted - even if it was going back
down to real mode for some reason, I doubt that cr2 and cr3 would be all
zeros.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 12:59:55 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 12:59:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaoQo-0005RV-Lj; Wed, 14 Dec 2011 12:59:34 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RaoQm-0005RQ-Hu
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 12:59:32 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-13.tower-216.messagelabs.com!1323867517!6836444!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31225 invoked from network); 14 Dec 2011 12:58:37 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-13.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Dec 2011 12:58:37 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RaoPp-000JLP-AL; Wed, 14 Dec 2011 12:58:33 +0000
Date: Wed, 14 Dec 2011 12:58:33 +0000
From: Tim Deegan <tim@xen.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20111214125833.GA51060@ocelot.phlegethon.org>
References: <CAPE0SYwsqRKDuPTz66r0nTVPYcsFx0Dk2j0pWpCiHELuU5W2iA@mail.gmail.com>
	<4EE881270200007800067A65@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4EE881270200007800067A65@nat28.tlf.novell.com>
User-Agent: Mutt/1.4.2.1i
Cc: Liwei <xieliwei@gmail.com>, xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] PTE Write access is not set
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 09:57 +0000 on 14 Dec (1323856663), Jan Beulich wrote:
> > (XEN) realmode.c:115:d9 Failed to emulate insn.
> > (XEN) realmode.c:165:d9 Real-mode emulation failed @ e40a:00005f6c: d9
> > 33 01 fc 30 34
> 
> ... if this is Linux I'm having a rather hard time seeing why it would
> enter realmode at normal run time (and then even use floating point
> instructions there). This would be expected at boot time and at most
> during guest-internal suspend/resume, but I'm sure you would have
> mentioned if the guest was in the process of doing the latter (and
> you excluded the former).
> 
> I'm rather suspecting the VM to have gone astray earlier.
> 
> > (XEN) domain_crash called from realmode.c:166
> > (XEN) Domain 9 (vcpu#0) crashed on cpu#6:
> > (XEN) ----[ Xen-4.1.3-rc1-pre  x86_64  debug=n  Not tainted ]----
> > (XEN) CPU:    6
> > (XEN) RIP:    e40a:[<0000000000005f6c>]
> > (XEN) RFLAGS: 0000000000010002   CONTEXT: hvm guest
> > (XEN) rax: 000000000000e7e5   rbx: 0000000000000000   rcx: 00000000000d0000
> > (XEN) rdx: 00000000000001f7   rsi: 0000000000000000   rdi: 0000000000000dba
> > (XEN) rbp: 0000000000000182   rsp: 0000000000000db0   r8:  0000000000000000
> > (XEN) r9:  0000000000000000   r10: 0000000000000000   r11: 0000000000000000
> > (XEN) r12: 0000000000000000   r13: 0000000000000000   r14: 0000000000000000
> > (XEN) r15: 0000000000000000   cr0: 0000000000000010   cr4: 0000000000000000
> > (XEN) cr3: 0000000000000000   cr2: 0000000000000000
> > (XEN) ds: 9fc0   es: 9e00   fs: 0000   gs: 0000   ss: 9e00   cs: e40a

I'd say the guest has recently rebooted - even if it was going back
down to real mode for some reason, I doubt that cr2 and cr3 would be all
zeros.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 13:12:29 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 13: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.xensource.com>)
	id 1Raod0-0005nO-19; Wed, 14 Dec 2011 13:12:10 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Raocy-0005nJ-1I
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 13:12:08 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1323868162!56131310!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10598 invoked from network); 14 Dec 2011 13:09:22 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-8.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Dec 2011 13:09:22 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 14 Dec 2011 13:11:11 +0000
Message-Id: <4EE8AE7D0200007800067B4A@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 14 Dec 2011 13:11:09 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
References: <4EE675A8.3030609@niemail.de> <4EE71663.5040308@gmail.com>
	<CAJeBh4sxdNTxM_oLFAuA6Mw75=LaYysrpS5b8NsZMbkf_swNVw@mail.gmail.com>
	<4EE72A94.6040904@gmail.com> <4EE75080.1000909@citrix.com>
	<1323783428.20077.298.camel@zakaz.uk.xensource.com>
	<4EE7BC9B.6040003@gmail.com>
	<1323815427.20936.96.camel@dagon.hellion.org.uk>
	<4EE7D75B.6080209@gmail.com>
	<1323847523.20936.110.camel@dagon.hellion.org.uk>
	<1323864969.20077.405.camel@zakaz.uk.xensource.com>
In-Reply-To: <1323864969.20077.405.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	George Shuklin <george.shuklin@gmail.com>,
	DavidVrabel <david.vrabel@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"sandr8@gmail.com" <sandr8@gmail.com>
Subject: Re: [Xen-devel] a ton of kernel issues
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 14.12.11 at 13:16, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> It works with xm/xend because they set the maximum reservation for
> guests to static-max on boot. xl (and, I think, xapi) instead set the
> maximum reservation to the current balloon target and change it

Hmm, is that even compatible with the old (non-pvops) kernels? I
always assumed that the maximum reservation was a true maximum,
not something that can change at any time during the life of a VM.
What's the purpose of this being adjustable and there also being a
current target?

Is the old tool stack also setting up a suitable E820 table? Assuming
so, is it at all reasonable to have the outer world establish a static
upper bound on the VM if such an immutable upper bound doesn't
really exist (rather than having the VM determine for itself - via
"mem=" - how far it wants to be able to go)?

Jan

> dynamically as the target is changed (as a method of enforcing the
> targets). However the pvops kernel incorrectly uses the maximum
> reservation at boot to size the physical address space for guests.
> 
> The patch below fixes this.
> 
> Ian.
> 
> 8<-------------------------------------------------------------
> 
> From 649ca3b7ddca1cdda85c27e34f806f30484172ec Mon Sep 17 00:00:00 2001
> From: Ian Campbell <ian.campbell@citrix.com>
> Date: Wed, 14 Dec 2011 12:00:38 +0000
> Subject: [PATCH] xen: only limit memory map to maximum reservation for 
> domain 0.
> 
> d312ae878b6a "xen: use maximum reservation to limit amount of usable RAM"
> clamped the total amount of RAM to the current maximum reservation. This is
> correct for dom0 but is not correct for guest domains. In order to boot a 
> guest
> "pre-ballooned" (e.g. with memory=1G but maxmem=2G) in order to allow for
> future memory expansion the guest must derive max_pfn from the e820 provided 
> by
> the toolstack and not the current maximum reservation (which can reflect 
> only
> the current maximum, not the guest lifetime max). The existing algorithm
> already behaves this correctly if we do not artificially limit the maximum
> number of pages for the guest case.
> 
> For a guest booted with maxmem=512, memory=128 this results in:
>  [    0.000000] BIOS-provided physical RAM map:
>  [    0.000000]  Xen: 0000000000000000 - 00000000000a0000 (usable)
>  [    0.000000]  Xen: 00000000000a0000 - 0000000000100000 (reserved)
> -[    0.000000]  Xen: 0000000000100000 - 0000000008100000 (usable)
> -[    0.000000]  Xen: 0000000008100000 - 0000000020800000 (unusable)
> +[    0.000000]  Xen: 0000000000100000 - 0000000020800000 (usable)
> ...
>  [    0.000000] NX (Execute Disable) protection: active
>  [    0.000000] DMI not present or invalid.
>  [    0.000000] e820 update range: 0000000000000000 - 0000000000010000 
> (usable) ==> (reserved)
>  [    0.000000] e820 remove range: 00000000000a0000 - 0000000000100000 
> (usable)
> -[    0.000000] last_pfn = 0x8100 max_arch_pfn = 0x1000000
> +[    0.000000] last_pfn = 0x20800 max_arch_pfn = 0x1000000
>  [    0.000000] initial memory mapped : 0 - 027ff000
>  [    0.000000] Base memory trampoline at [c009f000] 9f000 size 4096
> -[    0.000000] init_memory_mapping: 0000000000000000-0000000008100000
> -[    0.000000]  0000000000 - 0008100000 page 4k
> -[    0.000000] kernel direct mapping tables up to 8100000 @ 27bb000-27ff000
> +[    0.000000] init_memory_mapping: 0000000000000000-0000000020800000
> +[    0.000000]  0000000000 - 0020800000 page 4k
> +[    0.000000] kernel direct mapping tables up to 20800000 @ 26f8000-27ff000
>  [    0.000000] xen: setting RW the range 27e8000 - 27ff000
>  [    0.000000] 0MB HIGHMEM available.
> -[    0.000000] 129MB LOWMEM available.
> -[    0.000000]   mapped low ram: 0 - 08100000
> -[    0.000000]   low ram: 0 - 08100000
> +[    0.000000] 520MB LOWMEM available.
> +[    0.000000]   mapped low ram: 0 - 20800000
> +[    0.000000]   low ram: 0 - 20800000
> 
> With this change "xl mem-set <domain> 512M" will successfully increase the
> guest RAM (by reducing the balloon).
> 
> There is no change for dom0.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> Cc: stable@kernel.org 
> Cc: David Vrabel <david.vrabel@citrix.com>
> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> ---
>  arch/x86/xen/setup.c |   18 +++++++++++++++---
>  1 files changed, 15 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
> index 38d0af4..a54ff1a 100644
> --- a/arch/x86/xen/setup.c
> +++ b/arch/x86/xen/setup.c
> @@ -173,9 +173,21 @@ static unsigned long __init xen_get_max_pages(void)
>  	domid_t domid = DOMID_SELF;
>  	int ret;
>  
> -	ret = HYPERVISOR_memory_op(XENMEM_maximum_reservation, &domid);
> -	if (ret > 0)
> -		max_pages = ret;
> +	/*
> +	 * For the initial domain we use the maximum reservation as
> +	 * the maximum page.
> +	 *
> +	 * For guest domains the current maximum reservation reflects
> +	 * the current maximum rather than the static maximum. In this
> +	 * case the e820 map provided to us will cover the static
> +	 * maximum region.
> +	 */
> +	if (xen_initial_domain()) {
> +		ret = HYPERVISOR_memory_op(XENMEM_maximum_reservation, &domid);
> +		if (ret > 0)
> +			max_pages = ret;
> +	}
> +
>  	return min(max_pages, MAX_DOMAIN_PAGES);
>  }
>  
> -- 
> 1.7.2.5
> 
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com 
> http://lists.xensource.com/xen-devel 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 13:12:29 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 13: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.xensource.com>)
	id 1Raod0-0005nO-19; Wed, 14 Dec 2011 13:12:10 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Raocy-0005nJ-1I
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 13:12:08 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1323868162!56131310!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10598 invoked from network); 14 Dec 2011 13:09:22 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-8.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Dec 2011 13:09:22 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 14 Dec 2011 13:11:11 +0000
Message-Id: <4EE8AE7D0200007800067B4A@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 14 Dec 2011 13:11:09 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
References: <4EE675A8.3030609@niemail.de> <4EE71663.5040308@gmail.com>
	<CAJeBh4sxdNTxM_oLFAuA6Mw75=LaYysrpS5b8NsZMbkf_swNVw@mail.gmail.com>
	<4EE72A94.6040904@gmail.com> <4EE75080.1000909@citrix.com>
	<1323783428.20077.298.camel@zakaz.uk.xensource.com>
	<4EE7BC9B.6040003@gmail.com>
	<1323815427.20936.96.camel@dagon.hellion.org.uk>
	<4EE7D75B.6080209@gmail.com>
	<1323847523.20936.110.camel@dagon.hellion.org.uk>
	<1323864969.20077.405.camel@zakaz.uk.xensource.com>
In-Reply-To: <1323864969.20077.405.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	George Shuklin <george.shuklin@gmail.com>,
	DavidVrabel <david.vrabel@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"sandr8@gmail.com" <sandr8@gmail.com>
Subject: Re: [Xen-devel] a ton of kernel issues
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 14.12.11 at 13:16, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> It works with xm/xend because they set the maximum reservation for
> guests to static-max on boot. xl (and, I think, xapi) instead set the
> maximum reservation to the current balloon target and change it

Hmm, is that even compatible with the old (non-pvops) kernels? I
always assumed that the maximum reservation was a true maximum,
not something that can change at any time during the life of a VM.
What's the purpose of this being adjustable and there also being a
current target?

Is the old tool stack also setting up a suitable E820 table? Assuming
so, is it at all reasonable to have the outer world establish a static
upper bound on the VM if such an immutable upper bound doesn't
really exist (rather than having the VM determine for itself - via
"mem=" - how far it wants to be able to go)?

Jan

> dynamically as the target is changed (as a method of enforcing the
> targets). However the pvops kernel incorrectly uses the maximum
> reservation at boot to size the physical address space for guests.
> 
> The patch below fixes this.
> 
> Ian.
> 
> 8<-------------------------------------------------------------
> 
> From 649ca3b7ddca1cdda85c27e34f806f30484172ec Mon Sep 17 00:00:00 2001
> From: Ian Campbell <ian.campbell@citrix.com>
> Date: Wed, 14 Dec 2011 12:00:38 +0000
> Subject: [PATCH] xen: only limit memory map to maximum reservation for 
> domain 0.
> 
> d312ae878b6a "xen: use maximum reservation to limit amount of usable RAM"
> clamped the total amount of RAM to the current maximum reservation. This is
> correct for dom0 but is not correct for guest domains. In order to boot a 
> guest
> "pre-ballooned" (e.g. with memory=1G but maxmem=2G) in order to allow for
> future memory expansion the guest must derive max_pfn from the e820 provided 
> by
> the toolstack and not the current maximum reservation (which can reflect 
> only
> the current maximum, not the guest lifetime max). The existing algorithm
> already behaves this correctly if we do not artificially limit the maximum
> number of pages for the guest case.
> 
> For a guest booted with maxmem=512, memory=128 this results in:
>  [    0.000000] BIOS-provided physical RAM map:
>  [    0.000000]  Xen: 0000000000000000 - 00000000000a0000 (usable)
>  [    0.000000]  Xen: 00000000000a0000 - 0000000000100000 (reserved)
> -[    0.000000]  Xen: 0000000000100000 - 0000000008100000 (usable)
> -[    0.000000]  Xen: 0000000008100000 - 0000000020800000 (unusable)
> +[    0.000000]  Xen: 0000000000100000 - 0000000020800000 (usable)
> ...
>  [    0.000000] NX (Execute Disable) protection: active
>  [    0.000000] DMI not present or invalid.
>  [    0.000000] e820 update range: 0000000000000000 - 0000000000010000 
> (usable) ==> (reserved)
>  [    0.000000] e820 remove range: 00000000000a0000 - 0000000000100000 
> (usable)
> -[    0.000000] last_pfn = 0x8100 max_arch_pfn = 0x1000000
> +[    0.000000] last_pfn = 0x20800 max_arch_pfn = 0x1000000
>  [    0.000000] initial memory mapped : 0 - 027ff000
>  [    0.000000] Base memory trampoline at [c009f000] 9f000 size 4096
> -[    0.000000] init_memory_mapping: 0000000000000000-0000000008100000
> -[    0.000000]  0000000000 - 0008100000 page 4k
> -[    0.000000] kernel direct mapping tables up to 8100000 @ 27bb000-27ff000
> +[    0.000000] init_memory_mapping: 0000000000000000-0000000020800000
> +[    0.000000]  0000000000 - 0020800000 page 4k
> +[    0.000000] kernel direct mapping tables up to 20800000 @ 26f8000-27ff000
>  [    0.000000] xen: setting RW the range 27e8000 - 27ff000
>  [    0.000000] 0MB HIGHMEM available.
> -[    0.000000] 129MB LOWMEM available.
> -[    0.000000]   mapped low ram: 0 - 08100000
> -[    0.000000]   low ram: 0 - 08100000
> +[    0.000000] 520MB LOWMEM available.
> +[    0.000000]   mapped low ram: 0 - 20800000
> +[    0.000000]   low ram: 0 - 20800000
> 
> With this change "xl mem-set <domain> 512M" will successfully increase the
> guest RAM (by reducing the balloon).
> 
> There is no change for dom0.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> Cc: stable@kernel.org 
> Cc: David Vrabel <david.vrabel@citrix.com>
> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> ---
>  arch/x86/xen/setup.c |   18 +++++++++++++++---
>  1 files changed, 15 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
> index 38d0af4..a54ff1a 100644
> --- a/arch/x86/xen/setup.c
> +++ b/arch/x86/xen/setup.c
> @@ -173,9 +173,21 @@ static unsigned long __init xen_get_max_pages(void)
>  	domid_t domid = DOMID_SELF;
>  	int ret;
>  
> -	ret = HYPERVISOR_memory_op(XENMEM_maximum_reservation, &domid);
> -	if (ret > 0)
> -		max_pages = ret;
> +	/*
> +	 * For the initial domain we use the maximum reservation as
> +	 * the maximum page.
> +	 *
> +	 * For guest domains the current maximum reservation reflects
> +	 * the current maximum rather than the static maximum. In this
> +	 * case the e820 map provided to us will cover the static
> +	 * maximum region.
> +	 */
> +	if (xen_initial_domain()) {
> +		ret = HYPERVISOR_memory_op(XENMEM_maximum_reservation, &domid);
> +		if (ret > 0)
> +			max_pages = ret;
> +	}
> +
>  	return min(max_pages, MAX_DOMAIN_PAGES);
>  }
>  
> -- 
> 1.7.2.5
> 
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com 
> http://lists.xensource.com/xen-devel 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 13:38:52 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 13:38:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rap2O-0006C3-MD; Wed, 14 Dec 2011 13:38:24 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <shandivo@gmail.com>) id 1Rap2N-0006By-SD
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 13:38:24 +0000
X-Env-Sender: shandivo@gmail.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1323869846!5544758!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19496 invoked from network); 14 Dec 2011 13:37:27 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-9.tower-174.messagelabs.com with AES256-SHA encrypted SMTP;
	14 Dec 2011 13:37:27 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <shandivo@gmail.com>) id 1Rap1R-0002Ov-9X
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 05:37:25 -0800
Date: Wed, 14 Dec 2011 05:37:25 -0800 (PST)
From: n4rC0t1C <shandivo@gmail.com>
To: xen-devel@lists.xensource.com
Message-ID: <1323869845289-5074485.post@n5.nabble.com>
In-Reply-To: <201112141043.45780.tobias.geiger@vido.info>
References: <1319630071722-4939528.post@n5.nabble.com>
	<1319636130.20499.YahooMailNeo@web29808.mail.ird.yahoo.com>
	<1319695116310-4942047.post@n5.nabble.com>
	<1319710499.206.YahooMailNeo@web29804.mail.ird.yahoo.com>
	<1323123990448-5050354.post@n5.nabble.com>
	<1323170568.90631.YahooMailNeo@web29813.mail.ird.yahoo.com>
	<1323504740494-5063848.post@n5.nabble.com>
	<1323520193389-5064245.post@n5.nabble.com>
	<1323810239102-5072769.post@n5.nabble.com>
	<201112141043.45780.tobias.geiger@vido.info>
MIME-Version: 1.0
Subject: Re: [Xen-devel] Re : Re : Re : Re : Re : Re : Re : Re: Patches for
 VGA-Passthrough XEN 4.2 unstable
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Agreed 100% with what Tobias said. Ati is maybe easier and according to what
Liwei says in this thread, it works in Windows 7 domU too. 
My passthrough doesn't work in Win7 domu using 275.33 nvidia drivers. The
system boots, it recognizes the card, but everything is really slow, and
xl-top shows like the domu is always waiting for some kind of interrupt. As
soon as I open the nvidia control panel it reboots with error 
VIDEO_TDR_FAILURE (116). 
It's strange because all the memory and I/O assignments to the card are the
same as the bare metal Windows 7. 
I would really like to know what's the difference between how winxp and win7
access the video card.


--
View this message in context: http://xen.1045712.n5.nabble.com/Patches-for-VGA-Passthrough-XEN-4-2-unstable-tp4406265p5074485.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 13:38:52 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 13:38:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rap2O-0006C3-MD; Wed, 14 Dec 2011 13:38:24 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <shandivo@gmail.com>) id 1Rap2N-0006By-SD
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 13:38:24 +0000
X-Env-Sender: shandivo@gmail.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1323869846!5544758!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19496 invoked from network); 14 Dec 2011 13:37:27 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-9.tower-174.messagelabs.com with AES256-SHA encrypted SMTP;
	14 Dec 2011 13:37:27 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <shandivo@gmail.com>) id 1Rap1R-0002Ov-9X
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 05:37:25 -0800
Date: Wed, 14 Dec 2011 05:37:25 -0800 (PST)
From: n4rC0t1C <shandivo@gmail.com>
To: xen-devel@lists.xensource.com
Message-ID: <1323869845289-5074485.post@n5.nabble.com>
In-Reply-To: <201112141043.45780.tobias.geiger@vido.info>
References: <1319630071722-4939528.post@n5.nabble.com>
	<1319636130.20499.YahooMailNeo@web29808.mail.ird.yahoo.com>
	<1319695116310-4942047.post@n5.nabble.com>
	<1319710499.206.YahooMailNeo@web29804.mail.ird.yahoo.com>
	<1323123990448-5050354.post@n5.nabble.com>
	<1323170568.90631.YahooMailNeo@web29813.mail.ird.yahoo.com>
	<1323504740494-5063848.post@n5.nabble.com>
	<1323520193389-5064245.post@n5.nabble.com>
	<1323810239102-5072769.post@n5.nabble.com>
	<201112141043.45780.tobias.geiger@vido.info>
MIME-Version: 1.0
Subject: Re: [Xen-devel] Re : Re : Re : Re : Re : Re : Re : Re: Patches for
 VGA-Passthrough XEN 4.2 unstable
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Agreed 100% with what Tobias said. Ati is maybe easier and according to what
Liwei says in this thread, it works in Windows 7 domU too. 
My passthrough doesn't work in Win7 domu using 275.33 nvidia drivers. The
system boots, it recognizes the card, but everything is really slow, and
xl-top shows like the domu is always waiting for some kind of interrupt. As
soon as I open the nvidia control panel it reboots with error 
VIDEO_TDR_FAILURE (116). 
It's strange because all the memory and I/O assignments to the card are the
same as the bare metal Windows 7. 
I would really like to know what's the difference between how winxp and win7
access the video card.


--
View this message in context: http://xen.1045712.n5.nabble.com/Patches-for-VGA-Passthrough-XEN-4-2-unstable-tp4406265p5074485.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 13:39:36 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 13:39:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rap38-0006Dp-40; Wed, 14 Dec 2011 13:39:10 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1Rap36-0006Db-7h
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 13:39:08 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-10.tower-21.messagelabs.com!1323869892!7933350!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyOTkxODA=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyOTkxODA=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15242 invoked from network); 14 Dec 2011 13:38:12 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-10.tower-21.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 14 Dec 2011 13:38:12 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1323869892; l=826;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=CVkrfqGq76UR/gRFYRvtVPqubps=;
	b=fVeImhsJZMYPudwrabN4IfAz0oi44TKa5dt2PxrtHeYP+mVo93So/1Ox0+SBku7nnYd
	Ws+/MyZezfCC4mOavWsN+U8YoO+H3M+7iK5/yurvm8EFXw3xa4CvTvD9jDAIcSulyJmkp
	DXcshfdqX5jhXvDfwfz8WCS8cmc3Itq40dg=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFPjDQQEWpphA==
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-127-223.pools.arcor-ip.net [88.65.127.223])
	by smtp.strato.de (fruni mo29) (RZmta 26.15 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id u03f92nBEBu501 ;
	Wed, 14 Dec 2011 14:37:52 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id E020218637; Wed, 14 Dec 2011 14:37:45 +0100 (CET)
Date: Wed, 14 Dec 2011 14:37:45 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Roger Pau Monne <roger.pau@entel.upc.edu>
Message-ID: <20111214133745.GA20665@aepfle.de>
References: <7697ee23b08b8eaca9ae.1323768649@loki.upc.es>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <7697ee23b08b8eaca9ae.1323768649@loki.upc.es>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] xenpaging: remove XOPEN_SOURCE
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Dec 13, Roger Pau Monne wrote:

> # HG changeset patch
> # User Roger Pau Monne <roger.pau@entel.upc.edu>
> # Date 1323768129 -3600
> # Node ID 7697ee23b08b8eaca9aee4f6b79cf550a490bef7
> # Parent  8a84f53376862427f254a017cb52c928dbdd3d32
> xenpaging: remove XOPEN_SOURCE
> 
> The XOPEN_SOURCE define was breaking the compilation under NetBSD.
> I've removed it becasue it is not necessary (at least under NetBSD).
> If it is necessary for Linux, we can add a ifdef conditional to remove
> this only under NetBSD.

Please resend with the exact error message in NetBSD.

24223:9e3c2ef70c8a should have removed  _XOPEN_SOURCE, and
22023:af6799abc6e9 should have added  _GNU_SOURCE in the first place
(and give the exact error message as well).

Other than that:

Acked-by: Olaf Hering <olaf@aepfle.de>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 13:39:36 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 13:39:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rap38-0006Dp-40; Wed, 14 Dec 2011 13:39:10 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1Rap36-0006Db-7h
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 13:39:08 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-10.tower-21.messagelabs.com!1323869892!7933350!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyOTkxODA=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyOTkxODA=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15242 invoked from network); 14 Dec 2011 13:38:12 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-10.tower-21.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 14 Dec 2011 13:38:12 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1323869892; l=826;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=CVkrfqGq76UR/gRFYRvtVPqubps=;
	b=fVeImhsJZMYPudwrabN4IfAz0oi44TKa5dt2PxrtHeYP+mVo93So/1Ox0+SBku7nnYd
	Ws+/MyZezfCC4mOavWsN+U8YoO+H3M+7iK5/yurvm8EFXw3xa4CvTvD9jDAIcSulyJmkp
	DXcshfdqX5jhXvDfwfz8WCS8cmc3Itq40dg=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFPjDQQEWpphA==
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-127-223.pools.arcor-ip.net [88.65.127.223])
	by smtp.strato.de (fruni mo29) (RZmta 26.15 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id u03f92nBEBu501 ;
	Wed, 14 Dec 2011 14:37:52 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id E020218637; Wed, 14 Dec 2011 14:37:45 +0100 (CET)
Date: Wed, 14 Dec 2011 14:37:45 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Roger Pau Monne <roger.pau@entel.upc.edu>
Message-ID: <20111214133745.GA20665@aepfle.de>
References: <7697ee23b08b8eaca9ae.1323768649@loki.upc.es>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <7697ee23b08b8eaca9ae.1323768649@loki.upc.es>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] xenpaging: remove XOPEN_SOURCE
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Dec 13, Roger Pau Monne wrote:

> # HG changeset patch
> # User Roger Pau Monne <roger.pau@entel.upc.edu>
> # Date 1323768129 -3600
> # Node ID 7697ee23b08b8eaca9aee4f6b79cf550a490bef7
> # Parent  8a84f53376862427f254a017cb52c928dbdd3d32
> xenpaging: remove XOPEN_SOURCE
> 
> The XOPEN_SOURCE define was breaking the compilation under NetBSD.
> I've removed it becasue it is not necessary (at least under NetBSD).
> If it is necessary for Linux, we can add a ifdef conditional to remove
> this only under NetBSD.

Please resend with the exact error message in NetBSD.

24223:9e3c2ef70c8a should have removed  _XOPEN_SOURCE, and
22023:af6799abc6e9 should have added  _GNU_SOURCE in the first place
(and give the exact error message as well).

Other than that:

Acked-by: Olaf Hering <olaf@aepfle.de>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 13:50:16 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 13:50:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RapDS-0006Vj-9N; Wed, 14 Dec 2011 13:49:50 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RapDQ-0006Vd-8c
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 13:49:48 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1323870495!50592342!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTc4Ng==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21572 invoked from network); 14 Dec 2011 13:48:15 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Dec 2011 13:48:15 -0000
X-IronPort-AV: E=Sophos;i="4.71,352,1320624000"; 
   d="scan'208";a="9464763"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Dec 2011 13:48:37 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 14 Dec 2011 13:48:37 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Wed, 14 Dec 2011 13:48:37 +0000
In-Reply-To: <4EE8AE7D0200007800067B4A@nat28.tlf.novell.com>
References: <4EE675A8.3030609@niemail.de> <4EE71663.5040308@gmail.com>
	<CAJeBh4sxdNTxM_oLFAuA6Mw75=LaYysrpS5b8NsZMbkf_swNVw@mail.gmail.com>
	<4EE72A94.6040904@gmail.com> <4EE75080.1000909@citrix.com>
	<1323783428.20077.298.camel@zakaz.uk.xensource.com>
	<4EE7BC9B.6040003@gmail.com>
	<1323815427.20936.96.camel@dagon.hellion.org.uk>
	<4EE7D75B.6080209@gmail.com>
	<1323847523.20936.110.camel@dagon.hellion.org.uk>
	<1323864969.20077.405.camel@zakaz.uk.xensource.com>
	<4EE8AE7D0200007800067B4A@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323870517.20077.424.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	George Shuklin <george.shuklin@gmail.com>,
	David Vrabel <david.vrabel@citrix.com>, Konrad
	Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"sandr8@gmail.com" <sandr8@gmail.com>
Subject: Re: [Xen-devel] a ton of kernel issues
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2011-12-14 at 13:11 +0000, Jan Beulich wrote:
> >>> On 14.12.11 at 13:16, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > It works with xm/xend because they set the maximum reservation for
> > guests to static-max on boot. xl (and, I think, xapi) instead set the
> > maximum reservation to the current balloon target and change it
> 
> Hmm, is that even compatible with the old (non-pvops) kernels? I
> always assumed that the maximum reservation was a true maximum,
> not something that can change at any time during the life of a VM.
> What's the purpose of this being adjustable and there also being a
> current target?

The target is a target which we ask the guest to aim for, the maximum is
a hard maximum which Xen will actually enforce.

Toolstack can set them the same if they want to make sure that the guest
does not try and exceed its current target. Setting the maximum doesn't
reduce the memory a guest is currently using but it does ensure that
progress towards the target never regresses.

The xapi toolstack has been doing this for several years and we aren't
aware of any incompatibilities, there were some bugs in various kernels
(they would give up ballooning altogether if they hit the hard limit)
but they were all fixed quite some time ago IIRC.

> Is the old tool stack also setting up a suitable E820 table?

I believe so, this behaviour long predates xl. The difference with xend
is that it doesn't set the maximum to the target but rather to the
static-max, this is a toolstack policy decision.

> Assuming
> so, is it at all reasonable to have the outer world establish a static
> upper bound on the VM if such an immutable upper bound doesn't
> really exist

Yes, this is what many host administrators want, they want to control
this stuff via the host configuration APIs rather than by digging into
each guest.

>  (rather than having the VM determine for itself - via
> "mem=" - how far it wants to be able to go)?

mem= takes precedence over the e820 table, so we effectively have the
best of both worlds.

Ian.

> 
> Jan
> 
> > dynamically as the target is changed (as a method of enforcing the
> > targets). However the pvops kernel incorrectly uses the maximum
> > reservation at boot to size the physical address space for guests.
> > 
> > The patch below fixes this.
> > 
> > Ian.
> > 
> > 8<-------------------------------------------------------------
> > 
> > From 649ca3b7ddca1cdda85c27e34f806f30484172ec Mon Sep 17 00:00:00 2001
> > From: Ian Campbell <ian.campbell@citrix.com>
> > Date: Wed, 14 Dec 2011 12:00:38 +0000
> > Subject: [PATCH] xen: only limit memory map to maximum reservation for 
> > domain 0.
> > 
> > d312ae878b6a "xen: use maximum reservation to limit amount of usable RAM"
> > clamped the total amount of RAM to the current maximum reservation. This is
> > correct for dom0 but is not correct for guest domains. In order to boot a 
> > guest
> > "pre-ballooned" (e.g. with memory=1G but maxmem=2G) in order to allow for
> > future memory expansion the guest must derive max_pfn from the e820 provided 
> > by
> > the toolstack and not the current maximum reservation (which can reflect 
> > only
> > the current maximum, not the guest lifetime max). The existing algorithm
> > already behaves this correctly if we do not artificially limit the maximum
> > number of pages for the guest case.
> > 
> > For a guest booted with maxmem=512, memory=128 this results in:
> >  [    0.000000] BIOS-provided physical RAM map:
> >  [    0.000000]  Xen: 0000000000000000 - 00000000000a0000 (usable)
> >  [    0.000000]  Xen: 00000000000a0000 - 0000000000100000 (reserved)
> > -[    0.000000]  Xen: 0000000000100000 - 0000000008100000 (usable)
> > -[    0.000000]  Xen: 0000000008100000 - 0000000020800000 (unusable)
> > +[    0.000000]  Xen: 0000000000100000 - 0000000020800000 (usable)
> > ...
> >  [    0.000000] NX (Execute Disable) protection: active
> >  [    0.000000] DMI not present or invalid.
> >  [    0.000000] e820 update range: 0000000000000000 - 0000000000010000 
> > (usable) ==> (reserved)
> >  [    0.000000] e820 remove range: 00000000000a0000 - 0000000000100000 
> > (usable)
> > -[    0.000000] last_pfn = 0x8100 max_arch_pfn = 0x1000000
> > +[    0.000000] last_pfn = 0x20800 max_arch_pfn = 0x1000000
> >  [    0.000000] initial memory mapped : 0 - 027ff000
> >  [    0.000000] Base memory trampoline at [c009f000] 9f000 size 4096
> > -[    0.000000] init_memory_mapping: 0000000000000000-0000000008100000
> > -[    0.000000]  0000000000 - 0008100000 page 4k
> > -[    0.000000] kernel direct mapping tables up to 8100000 @ 27bb000-27ff000
> > +[    0.000000] init_memory_mapping: 0000000000000000-0000000020800000
> > +[    0.000000]  0000000000 - 0020800000 page 4k
> > +[    0.000000] kernel direct mapping tables up to 20800000 @ 26f8000-27ff000
> >  [    0.000000] xen: setting RW the range 27e8000 - 27ff000
> >  [    0.000000] 0MB HIGHMEM available.
> > -[    0.000000] 129MB LOWMEM available.
> > -[    0.000000]   mapped low ram: 0 - 08100000
> > -[    0.000000]   low ram: 0 - 08100000
> > +[    0.000000] 520MB LOWMEM available.
> > +[    0.000000]   mapped low ram: 0 - 20800000
> > +[    0.000000]   low ram: 0 - 20800000
> > 
> > With this change "xl mem-set <domain> 512M" will successfully increase the
> > guest RAM (by reducing the balloon).
> > 
> > There is no change for dom0.
> > 
> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> > Cc: stable@kernel.org 
> > Cc: David Vrabel <david.vrabel@citrix.com>
> > Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > ---
> >  arch/x86/xen/setup.c |   18 +++++++++++++++---
> >  1 files changed, 15 insertions(+), 3 deletions(-)
> > 
> > diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
> > index 38d0af4..a54ff1a 100644
> > --- a/arch/x86/xen/setup.c
> > +++ b/arch/x86/xen/setup.c
> > @@ -173,9 +173,21 @@ static unsigned long __init xen_get_max_pages(void)
> >  	domid_t domid = DOMID_SELF;
> >  	int ret;
> >  
> > -	ret = HYPERVISOR_memory_op(XENMEM_maximum_reservation, &domid);
> > -	if (ret > 0)
> > -		max_pages = ret;
> > +	/*
> > +	 * For the initial domain we use the maximum reservation as
> > +	 * the maximum page.
> > +	 *
> > +	 * For guest domains the current maximum reservation reflects
> > +	 * the current maximum rather than the static maximum. In this
> > +	 * case the e820 map provided to us will cover the static
> > +	 * maximum region.
> > +	 */
> > +	if (xen_initial_domain()) {
> > +		ret = HYPERVISOR_memory_op(XENMEM_maximum_reservation, &domid);
> > +		if (ret > 0)
> > +			max_pages = ret;
> > +	}
> > +
> >  	return min(max_pages, MAX_DOMAIN_PAGES);
> >  }
> >  
> > -- 
> > 1.7.2.5
> > 
> > 
> > 
> > 
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xensource.com 
> > http://lists.xensource.com/xen-devel 
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 13:50:16 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 13:50:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RapDS-0006Vj-9N; Wed, 14 Dec 2011 13:49:50 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RapDQ-0006Vd-8c
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 13:49:48 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1323870495!50592342!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTc4Ng==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21572 invoked from network); 14 Dec 2011 13:48:15 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Dec 2011 13:48:15 -0000
X-IronPort-AV: E=Sophos;i="4.71,352,1320624000"; 
   d="scan'208";a="9464763"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Dec 2011 13:48:37 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 14 Dec 2011 13:48:37 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Wed, 14 Dec 2011 13:48:37 +0000
In-Reply-To: <4EE8AE7D0200007800067B4A@nat28.tlf.novell.com>
References: <4EE675A8.3030609@niemail.de> <4EE71663.5040308@gmail.com>
	<CAJeBh4sxdNTxM_oLFAuA6Mw75=LaYysrpS5b8NsZMbkf_swNVw@mail.gmail.com>
	<4EE72A94.6040904@gmail.com> <4EE75080.1000909@citrix.com>
	<1323783428.20077.298.camel@zakaz.uk.xensource.com>
	<4EE7BC9B.6040003@gmail.com>
	<1323815427.20936.96.camel@dagon.hellion.org.uk>
	<4EE7D75B.6080209@gmail.com>
	<1323847523.20936.110.camel@dagon.hellion.org.uk>
	<1323864969.20077.405.camel@zakaz.uk.xensource.com>
	<4EE8AE7D0200007800067B4A@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323870517.20077.424.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	George Shuklin <george.shuklin@gmail.com>,
	David Vrabel <david.vrabel@citrix.com>, Konrad
	Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"sandr8@gmail.com" <sandr8@gmail.com>
Subject: Re: [Xen-devel] a ton of kernel issues
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2011-12-14 at 13:11 +0000, Jan Beulich wrote:
> >>> On 14.12.11 at 13:16, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > It works with xm/xend because they set the maximum reservation for
> > guests to static-max on boot. xl (and, I think, xapi) instead set the
> > maximum reservation to the current balloon target and change it
> 
> Hmm, is that even compatible with the old (non-pvops) kernels? I
> always assumed that the maximum reservation was a true maximum,
> not something that can change at any time during the life of a VM.
> What's the purpose of this being adjustable and there also being a
> current target?

The target is a target which we ask the guest to aim for, the maximum is
a hard maximum which Xen will actually enforce.

Toolstack can set them the same if they want to make sure that the guest
does not try and exceed its current target. Setting the maximum doesn't
reduce the memory a guest is currently using but it does ensure that
progress towards the target never regresses.

The xapi toolstack has been doing this for several years and we aren't
aware of any incompatibilities, there were some bugs in various kernels
(they would give up ballooning altogether if they hit the hard limit)
but they were all fixed quite some time ago IIRC.

> Is the old tool stack also setting up a suitable E820 table?

I believe so, this behaviour long predates xl. The difference with xend
is that it doesn't set the maximum to the target but rather to the
static-max, this is a toolstack policy decision.

> Assuming
> so, is it at all reasonable to have the outer world establish a static
> upper bound on the VM if such an immutable upper bound doesn't
> really exist

Yes, this is what many host administrators want, they want to control
this stuff via the host configuration APIs rather than by digging into
each guest.

>  (rather than having the VM determine for itself - via
> "mem=" - how far it wants to be able to go)?

mem= takes precedence over the e820 table, so we effectively have the
best of both worlds.

Ian.

> 
> Jan
> 
> > dynamically as the target is changed (as a method of enforcing the
> > targets). However the pvops kernel incorrectly uses the maximum
> > reservation at boot to size the physical address space for guests.
> > 
> > The patch below fixes this.
> > 
> > Ian.
> > 
> > 8<-------------------------------------------------------------
> > 
> > From 649ca3b7ddca1cdda85c27e34f806f30484172ec Mon Sep 17 00:00:00 2001
> > From: Ian Campbell <ian.campbell@citrix.com>
> > Date: Wed, 14 Dec 2011 12:00:38 +0000
> > Subject: [PATCH] xen: only limit memory map to maximum reservation for 
> > domain 0.
> > 
> > d312ae878b6a "xen: use maximum reservation to limit amount of usable RAM"
> > clamped the total amount of RAM to the current maximum reservation. This is
> > correct for dom0 but is not correct for guest domains. In order to boot a 
> > guest
> > "pre-ballooned" (e.g. with memory=1G but maxmem=2G) in order to allow for
> > future memory expansion the guest must derive max_pfn from the e820 provided 
> > by
> > the toolstack and not the current maximum reservation (which can reflect 
> > only
> > the current maximum, not the guest lifetime max). The existing algorithm
> > already behaves this correctly if we do not artificially limit the maximum
> > number of pages for the guest case.
> > 
> > For a guest booted with maxmem=512, memory=128 this results in:
> >  [    0.000000] BIOS-provided physical RAM map:
> >  [    0.000000]  Xen: 0000000000000000 - 00000000000a0000 (usable)
> >  [    0.000000]  Xen: 00000000000a0000 - 0000000000100000 (reserved)
> > -[    0.000000]  Xen: 0000000000100000 - 0000000008100000 (usable)
> > -[    0.000000]  Xen: 0000000008100000 - 0000000020800000 (unusable)
> > +[    0.000000]  Xen: 0000000000100000 - 0000000020800000 (usable)
> > ...
> >  [    0.000000] NX (Execute Disable) protection: active
> >  [    0.000000] DMI not present or invalid.
> >  [    0.000000] e820 update range: 0000000000000000 - 0000000000010000 
> > (usable) ==> (reserved)
> >  [    0.000000] e820 remove range: 00000000000a0000 - 0000000000100000 
> > (usable)
> > -[    0.000000] last_pfn = 0x8100 max_arch_pfn = 0x1000000
> > +[    0.000000] last_pfn = 0x20800 max_arch_pfn = 0x1000000
> >  [    0.000000] initial memory mapped : 0 - 027ff000
> >  [    0.000000] Base memory trampoline at [c009f000] 9f000 size 4096
> > -[    0.000000] init_memory_mapping: 0000000000000000-0000000008100000
> > -[    0.000000]  0000000000 - 0008100000 page 4k
> > -[    0.000000] kernel direct mapping tables up to 8100000 @ 27bb000-27ff000
> > +[    0.000000] init_memory_mapping: 0000000000000000-0000000020800000
> > +[    0.000000]  0000000000 - 0020800000 page 4k
> > +[    0.000000] kernel direct mapping tables up to 20800000 @ 26f8000-27ff000
> >  [    0.000000] xen: setting RW the range 27e8000 - 27ff000
> >  [    0.000000] 0MB HIGHMEM available.
> > -[    0.000000] 129MB LOWMEM available.
> > -[    0.000000]   mapped low ram: 0 - 08100000
> > -[    0.000000]   low ram: 0 - 08100000
> > +[    0.000000] 520MB LOWMEM available.
> > +[    0.000000]   mapped low ram: 0 - 20800000
> > +[    0.000000]   low ram: 0 - 20800000
> > 
> > With this change "xl mem-set <domain> 512M" will successfully increase the
> > guest RAM (by reducing the balloon).
> > 
> > There is no change for dom0.
> > 
> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> > Cc: stable@kernel.org 
> > Cc: David Vrabel <david.vrabel@citrix.com>
> > Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > ---
> >  arch/x86/xen/setup.c |   18 +++++++++++++++---
> >  1 files changed, 15 insertions(+), 3 deletions(-)
> > 
> > diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
> > index 38d0af4..a54ff1a 100644
> > --- a/arch/x86/xen/setup.c
> > +++ b/arch/x86/xen/setup.c
> > @@ -173,9 +173,21 @@ static unsigned long __init xen_get_max_pages(void)
> >  	domid_t domid = DOMID_SELF;
> >  	int ret;
> >  
> > -	ret = HYPERVISOR_memory_op(XENMEM_maximum_reservation, &domid);
> > -	if (ret > 0)
> > -		max_pages = ret;
> > +	/*
> > +	 * For the initial domain we use the maximum reservation as
> > +	 * the maximum page.
> > +	 *
> > +	 * For guest domains the current maximum reservation reflects
> > +	 * the current maximum rather than the static maximum. In this
> > +	 * case the e820 map provided to us will cover the static
> > +	 * maximum region.
> > +	 */
> > +	if (xen_initial_domain()) {
> > +		ret = HYPERVISOR_memory_op(XENMEM_maximum_reservation, &domid);
> > +		if (ret > 0)
> > +			max_pages = ret;
> > +	}
> > +
> >  	return min(max_pages, MAX_DOMAIN_PAGES);
> >  }
> >  
> > -- 
> > 1.7.2.5
> > 
> > 
> > 
> > 
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xensource.com 
> > http://lists.xensource.com/xen-devel 
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 13:55:07 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 13:55:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RapIE-0006dq-0e; Wed, 14 Dec 2011 13:54:46 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Christoph.Egger@amd.com>) id 1RapIC-0006da-2e
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 13:54:44 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1323870827!61632!1
X-Originating-IP: [213.199.154.140]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13223 invoked from network); 14 Dec 2011 13:53:47 -0000
Received: from db3ehsobe002.messaging.microsoft.com (HELO
	DB3EHSOBE002.bigfish.com) (213.199.154.140)
	by server-16.tower-182.messagelabs.com with AES128-SHA encrypted SMTP;
	14 Dec 2011 13:53:47 -0000
Received: from mail73-db3-R.bigfish.com (10.3.81.249) by
	DB3EHSOBE002.bigfish.com (10.3.84.22) with Microsoft SMTP Server id
	14.1.225.23; Wed, 14 Dec 2011 13:53:49 +0000
Received: from mail73-db3 (localhost [127.0.0.1])	by mail73-db3-R.bigfish.com
	(Postfix) with ESMTP id 3E4BB1E031D;
	Wed, 14 Dec 2011 13:53:50 +0000 (UTC)
X-SpamScore: -13
X-BigFish: VPS-13(zzbb2dI146fKc85dh1432N98dKzz1202hzz8275bhz2dh668h839h34h)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
X-FB-SS: 13,
Received: from mail73-db3 (localhost.localdomain [127.0.0.1]) by mail73-db3
	(MessageSwitch) id 132387083082488_8650; Wed, 14 Dec 2011 13:53:50 +0000
	(UTC)
Received: from DB3EHSMHS015.bigfish.com (unknown [10.3.81.245])	by
	mail73-db3.bigfish.com (Postfix) with ESMTP id 0F91C80044;
	Wed, 14 Dec 2011 13:53:50 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	DB3EHSMHS015.bigfish.com (10.3.87.115) with Microsoft SMTP Server id
	14.1.225.23; Wed, 14 Dec 2011 13:53:48 +0000
X-WSS-ID: 0LW759I-01-1G7-02
X-M-MSG: 
Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com
	[163.181.249.73])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 258EE1028052;	Wed, 14 Dec 2011 07:53:42 -0600 (CST)
Received: from SAUSEXDAG03.amd.com (163.181.55.3) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Wed, 14 Dec 2011 07:53:54 -0600
Received: from storexhtp02.amd.com (172.24.4.4) by sausexdag03.amd.com
	(163.181.55.3) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Wed, 14 Dec 2011 07:53:43 -0600
Received: from rhodium.osrc.amd.com (165.204.15.173) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Wed, 14 Dec 2011
	08:53:07 -0500
Message-ID: <4EE8AA3F.9040704@amd.com>
Date: Wed, 14 Dec 2011 14:53:03 +0100
From: Christoph Egger <Christoph.Egger@amd.com>
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:8.0) Gecko/20111114 Thunderbird/8.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <CB0BC143.35A76%keir@xen.org> <4EE75FB4.30609@amd.com>
	<4EE7776E0200007800067623@nat28.tlf.novell.com>
	<4EE877A8.7080706@amd.com>
	<4EE8A7DE0200007800067B17@nat28.tlf.novell.com>
In-Reply-To: <4EE8A7DE0200007800067B17@nat28.tlf.novell.com>
Content-Type: multipart/mixed; boundary="------------080706070403020908090207"
X-OriginatorOrg: amd.com
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Keir Fraser <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH] microcode fix
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--------------080706070403020908090207
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit

On 12/14/11 13:42, Jan Beulich wrote:
>>>> On 14.12.11 at 11:17, Christoph Egger<Christoph.Egger@amd.com>  wrote:
>> +struct mpbhdr {
>> +    uint32_t type;
>> +    uint32_t len;
>> +    const uint8_t data;
>
> What's this?

This little structure eliminates the uses buf_pos[x] throughout the
code which is much easier to read and understand.

> If anything, this should be data[] (and no need for const).

Then it is data[]

>> @@ -141,16 +142,19 @@ static int apply_microcode(int cpu)
>>      struct ucode_cpu_info *uci =&per_cpu(ucode_cpu_info, cpu);
>>      uint32_t rev;
>>      struct microcode_amd *mc_amd = uci->mc.mc_amd;
>> +    struct microcode_header_amd *hdr = mc_amd->mpb;
>
> Using mc_amd here, but ...
>
>>      /* We should bind the task to the CPU */
>>      BUG_ON(raw_smp_processor_id() != cpu);
>>
>>      if ( mc_amd == NULL )
>>          return -EINVAL;
>
> ... the NULL check is only here.
>
>> +    if ( mc_amd->mpb == NULL )
>> +        return -EINVAL;
>
> And quite obviously you should preferably use the local variable
> here...
>
>> -    wrmsrl(MSR_AMD_PATCHLOADER, (unsigned long)&mc_amd->hdr.data_code);
>> +    wrmsrl(MSR_AMD_PATCHLOADER, (unsigned long)mc_amd->mpb);
>
> ... and here.

done (assuming you mean 'hdr').

>> +    printk(KERN_DEBUG "microcode: size %lu, block size %u, offset %ld\n",
>> +           (unsigned long)bufsize, mpbuf->len, off);
>
> The cast is pointless; to avoid it, use %zu as format string or declare
> the parameter as 'unsigned long'.

done.

>> +    if (mc_amd->mpb_size<  mpbuf->len) {
>> +        xfree(mc_amd->mpb);
>> +        mc_amd->mpb = xmalloc_bytes(mpbuf->len);
>> +        mc_amd->mpb_size = mpbuf->len;
>
> NULL check missing here (and in such event the clearing of
> ->mpb_size).

done.

>> +    memcpy(mc_amd->mpb, (const void *)&mpbuf->data, mpbuf->len);
>
> Unnecessary cast.

Right.

>>          printk(KERN_ERR "microcode: error! Wrong "
>> -               "microcode patch file magic\n");
>> +            "microcode patch file magic\n");
>
> Why are you still mis-adjusting indentation here?

oh...

>> +    mc_amd = xmalloc_bytes(sizeof(*mc_amd));
>
> As said during the first review round - this ought to be
>
>      mc_amd = xmalloc(struct microcode_amd);

sorry, didn't realize that it was not only relevant to the shown line
of code.

>> +    while ( (ret = get_next_ucode_from_buffer_amd(mc_amd,
>> +        buf, bufsize,&offset)) == 0 )
>
> Bad indentation.

Fixed.

>> +    ASSERT(src != NULL);
>
> Pointless.

Maybe. Maybe not. Anyway, I removed it.

>> +        if (mc_amd != NULL) {
>
> While this NULL check is needed, ...
>
>> +            if (mc_amd->equiv_cpu_table)
>
> ... this and ...
>
>> +                xfree(mc_amd->equiv_cpu_table);
>> +            if (mc_amd->mpb)
>
> ... this are pointless.
>
>> +                xfree(mc_amd->mpb);
>> +            xfree(mc_amd);
>> +        }
>> +
>> +        mc_amd = xmalloc(struct microcode_amd);
>
>      uci->mc.mc_amd = mc_amd;
>
>>          if ( !mc_amd )
>
> (as was the case in the original code). No need to do this once in the
> success path and once in the error one.
>
>> +    uci->mc.mc_amd = mc_amd = NULL;
>> +    return -ENOMEM;
>
> Even if it was necessary to keep it this way, initializing a local variable
> immediately before returning is bogus (and calling for a compiler
> warning and hence a build failure due to -Werror sooner or later).

Fixed.

New version attached.
Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>

> Jan
>
>


-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo, Andrew Bowd
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632

--------------080706070403020908090207
Content-Type: text/plain; name="xen_microcode_fam15.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="xen_microcode_fam15.diff"
Content-Description: xen_microcode_fam15.diff

diff -r f1ab2c2138d8 xen/arch/x86/microcode_amd.c
--- a/xen/arch/x86/microcode_amd.c	Mon Dec 12 10:47:26 2011 +0100
+++ b/xen/arch/x86/microcode_amd.c	Wed Dec 14 14:52:04 2011 +0100
@@ -26,8 +26,6 @@
 #include <asm/processor.h>
 #include <asm/microcode.h>
 
-#define pr_debug(x...) ((void)0)
-
 struct equiv_cpu_entry {
     uint32_t installed_cpu;
     uint32_t fixed_errata_mask;
@@ -57,14 +55,17 @@ struct microcode_header_amd {
 #define UCODE_EQUIV_CPU_TABLE_TYPE 0x00000000
 #define UCODE_UCODE_TYPE           0x00000001
 
-#define UCODE_MAX_SIZE          (2048)
-#define MC_HEADER_SIZE          (sizeof(struct microcode_header_amd))
+struct microcode_amd {
+    void *mpb;
+    size_t mpb_size;
+    struct equiv_cpu_entry *equiv_cpu_table;
+    size_t equiv_cpu_table_size;
+};
 
-struct microcode_amd {
-    struct microcode_header_amd hdr;
-    unsigned int mpb[(UCODE_MAX_SIZE - MC_HEADER_SIZE) / 4];
-    unsigned int equiv_cpu_table_size;
-    struct equiv_cpu_entry equiv_cpu_table[];
+struct mpbhdr {
+    uint32_t type;
+    uint32_t len;
+    uint8_t data[];
 };
 
 /* serialize access to the physical write */
@@ -94,7 +95,7 @@ static int collect_cpu_info(int cpu, str
 static int microcode_fits(const struct microcode_amd *mc_amd, int cpu)
 {
     struct ucode_cpu_info *uci = &per_cpu(ucode_cpu_info, cpu);
-    const struct microcode_header_amd *mc_header = &mc_amd->hdr;
+    const struct microcode_header_amd *mc_header = mc_amd->mpb;
     const struct equiv_cpu_entry *equiv_cpu_table = mc_amd->equiv_cpu_table;
     unsigned int current_cpu_id;
     unsigned int equiv_cpu_id = 0x0;
@@ -141,6 +142,7 @@ static int apply_microcode(int cpu)
     struct ucode_cpu_info *uci = &per_cpu(ucode_cpu_info, cpu);
     uint32_t rev;
     struct microcode_amd *mc_amd = uci->mc.mc_amd;
+    struct microcode_header_amd *hdr;
 
     /* We should bind the task to the CPU */
     BUG_ON(raw_smp_processor_id() != cpu);
@@ -148,9 +150,13 @@ static int apply_microcode(int cpu)
     if ( mc_amd == NULL )
         return -EINVAL;
 
+    hdr = mc_amd->mpb;
+    if ( hdr == NULL )
+        return -EINVAL;
+
     spin_lock_irqsave(&microcode_update_lock, flags);
 
-    wrmsrl(MSR_AMD_PATCHLOADER, (unsigned long)&mc_amd->hdr.data_code);
+    wrmsrl(MSR_AMD_PATCHLOADER, (unsigned long)hdr);
 
     /* get patch id after patching */
     rdmsrl(MSR_AMD_PATCHLEVEL, rev);
@@ -158,99 +164,115 @@ static int apply_microcode(int cpu)
     spin_unlock_irqrestore(&microcode_update_lock, flags);
 
     /* check current patch id and patch's id for match */
-    if ( rev != mc_amd->hdr.patch_id )
+    if ( rev != hdr->patch_id )
     {
         printk(KERN_ERR "microcode: CPU%d update from revision "
                "0x%x to 0x%x failed\n", cpu,
-               mc_amd->hdr.patch_id, rev);
+               hdr->patch_id, rev);
         return -EIO;
     }
 
     printk(KERN_INFO "microcode: CPU%d updated from revision %#x to %#x\n",
-           cpu, uci->cpu_sig.rev, mc_amd->hdr.patch_id);
+           cpu, uci->cpu_sig.rev, hdr->patch_id);
 
     uci->cpu_sig.rev = rev;
 
     return 0;
 }
 
-static int get_next_ucode_from_buffer_amd(void *mc, const void *buf,
-                                         size_t size, unsigned long *offset)
+static int get_next_ucode_from_buffer_amd(struct microcode_amd *mc_amd,
+    const void *buf, size_t bufsize, unsigned long *offset)
 {
-    size_t total_size;
     const uint8_t *bufp = buf;
     unsigned long off;
+    const struct mpbhdr *mpbuf;
 
     off = *offset;
 
     /* No more data */
-    if ( off >= size )
+    if ( off >= bufsize )
         return 1;
 
-    if ( bufp[off] != UCODE_UCODE_TYPE )
+    mpbuf = (const struct mpbhdr *)&bufp[off];
+    if ( mpbuf->type != UCODE_UCODE_TYPE )
     {
         printk(KERN_ERR "microcode: error! "
                "Wrong microcode payload type field\n");
         return -EINVAL;
     }
 
-    total_size = (unsigned long) (bufp[off+4] + (bufp[off+5] << 8));
+    printk(KERN_DEBUG "microcode: size %zu, block size %u, offset %ld\n",
+           bufsize, mpbuf->len, off);
 
-    printk(KERN_DEBUG "microcode: size %lu, total_size %lu, offset %ld\n",
-           (unsigned long)size, total_size, off);
-
-    if ( (off + total_size) > size )
+    if ( (off + mpbuf->len) > bufsize )
     {
         printk(KERN_ERR "microcode: error! Bad data in microcode data file\n");
         return -EINVAL;
     }
 
-    memset(mc, 0, UCODE_MAX_SIZE);
-    memcpy(mc, (const void *)(&bufp[off + 8]), total_size);
+    if (mc_amd->mpb_size < mpbuf->len) {
+        if (mc_amd->mpb) {
+            xfree(mc_amd->mpb);
+            mc_amd->mpb_size = 0;
+        }
+        mc_amd->mpb = xmalloc_bytes(mpbuf->len);
+        if (mc_amd->mpb == NULL)
+            return -ENOMEM;
+        mc_amd->mpb_size = mpbuf->len;
+    }
+    memcpy(mc_amd->mpb, mpbuf->data, mpbuf->len);
 
-    *offset = off + total_size + 8;
+    *offset = off + mpbuf->len + 8;
 
     return 0;
 }
 
 static int install_equiv_cpu_table(
     struct microcode_amd *mc_amd,
-    const uint32_t *buf_pos,
+    const uint32_t *buf,
     unsigned long *offset)
 {
-    uint32_t size = buf_pos[2];
+    const struct mpbhdr *mpbuf = (const struct mpbhdr *)&buf[1];
 
     /* No more data */
-    if ( size + 12 >= *offset )
+    if ( mpbuf->len + 12 >= *offset )
         return -EINVAL;
 
-    if ( buf_pos[1] != UCODE_EQUIV_CPU_TABLE_TYPE )
+    if ( mpbuf->type != UCODE_EQUIV_CPU_TABLE_TYPE )
     {
         printk(KERN_ERR "microcode: error! "
                "Wrong microcode equivalent cpu table type field\n");
         return -EINVAL;
     }
 
-    if ( size == 0 )
+    if ( mpbuf->len == 0 )
     {
         printk(KERN_ERR "microcode: error! "
-               "Wrong microcode equivalnet cpu table length\n");
+               "Wrong microcode equivalent cpu table length\n");
         return -EINVAL;
     }
 
-    memcpy(mc_amd->equiv_cpu_table, &buf_pos[3], size);
-    mc_amd->equiv_cpu_table_size = size;
+    mc_amd->equiv_cpu_table = xmalloc_bytes(mpbuf->len);
+    if ( !mc_amd->equiv_cpu_table )
+    {
+        printk(KERN_ERR "microcode: error! "
+               "Can not allocate memory for equivalent cpu table\n");
+        return -ENOMEM;
+    }
 
-    *offset = size + 12;	/* add header length */
+    memcpy(mc_amd->equiv_cpu_table, mpbuf->data, mpbuf->len);
+    mc_amd->equiv_cpu_table_size = mpbuf->len;
+
+    *offset = mpbuf->len + 12;	/* add header length */
 
     return 0;
 }
 
-static int cpu_request_microcode(int cpu, const void *buf, size_t size)
+static int cpu_request_microcode(int cpu, const void *buf, size_t bufsize)
 {
-    const uint32_t *buf_pos;
+    const uint32_t *magic;
     struct microcode_amd *mc_amd, *mc_old;
-    unsigned long offset = size;
+    size_t offset = bufsize;
     int error = 0;
     int ret;
     struct ucode_cpu_info *uci = &per_cpu(ucode_cpu_info, cpu);
@@ -258,16 +280,15 @@ static int cpu_request_microcode(int cpu
     /* We should bind the task to the CPU */
     BUG_ON(cpu != raw_smp_processor_id());
 
-    buf_pos = (const uint32_t *)buf;
-
-    if ( buf_pos[0] != UCODE_MAGIC )
+    magic = (const uint32_t *)buf;
+    if ( *magic != UCODE_MAGIC )
     {
         printk(KERN_ERR "microcode: error! Wrong "
                "microcode patch file magic\n");
         return -EINVAL;
     }
 
-    mc_amd = xmalloc_bytes(sizeof(*mc_amd) + buf_pos[2]);
+    mc_amd = xmalloc(struct microcode_amd);
     if ( !mc_amd )
     {
         printk(KERN_ERR "microcode: error! "
@@ -291,7 +312,9 @@ static int cpu_request_microcode(int cpu
      * It's possible the data file has multiple matching ucode,
      * lets keep searching till the latest version
      */
-    while ( (ret = get_next_ucode_from_buffer_amd(&mc_amd->hdr, buf, size,
+    mc_amd->mpb = NULL;
+    mc_amd->mpb_size = 0;
+    while ( (ret = get_next_ucode_from_buffer_amd(mc_amd, buf, bufsize,
                                                   &offset)) == 0 )
     {
         error = microcode_fits(mc_amd, cpu);
@@ -335,17 +358,39 @@ static int microcode_resume_match(int cp
 
     if ( src != mc_amd )
     {
-        xfree(mc_amd);
-        mc_amd = xmalloc_bytes(sizeof(*src) + src->equiv_cpu_table_size);
+        if (mc_amd != NULL) {
+            xfree(mc_amd->equiv_cpu_table);
+            xfree(mc_amd->mpb);
+            xfree(mc_amd);
+        }
+
+        mc_amd = xmalloc(struct microcode_amd);
         uci->mc.mc_amd = mc_amd;
         if ( !mc_amd )
-            return -ENOMEM;
-        memcpy(mc_amd, src, UCODE_MAX_SIZE);
+            goto err0;
+        mc_amd->equiv_cpu_table = xmalloc_bytes(src->equiv_cpu_table_size);
+        if ( !mc_amd->equiv_cpu_table )
+            goto err1;
+        mc_amd->mpb = xmalloc_bytes(src->mpb_size);
+        if ( !mc_amd->mpb )
+            goto err2;
+
+        mc_amd->equiv_cpu_table_size = src->equiv_cpu_table_size;
+        mc_amd->mpb_size = src->mpb_size;
+        memcpy(mc_amd->mpb, src->mpb, src->mpb_size);
         memcpy(mc_amd->equiv_cpu_table, src->equiv_cpu_table,
                src->equiv_cpu_table_size);
     }
 
     return 1;
+
+err2:
+    xfree(mc_amd->equiv_cpu_table);
+err1:
+    xfree(mc_amd);
+err0:
+    uci->mc.mc_amd = NULL;
+    return -ENOMEM;
 }
 
 static const struct microcode_ops microcode_amd_ops = {

--------------080706070403020908090207
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--------------080706070403020908090207--


From xen-devel-bounces@lists.xensource.com Wed Dec 14 13:55:07 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 13:55:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RapIE-0006dq-0e; Wed, 14 Dec 2011 13:54:46 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Christoph.Egger@amd.com>) id 1RapIC-0006da-2e
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 13:54:44 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1323870827!61632!1
X-Originating-IP: [213.199.154.140]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13223 invoked from network); 14 Dec 2011 13:53:47 -0000
Received: from db3ehsobe002.messaging.microsoft.com (HELO
	DB3EHSOBE002.bigfish.com) (213.199.154.140)
	by server-16.tower-182.messagelabs.com with AES128-SHA encrypted SMTP;
	14 Dec 2011 13:53:47 -0000
Received: from mail73-db3-R.bigfish.com (10.3.81.249) by
	DB3EHSOBE002.bigfish.com (10.3.84.22) with Microsoft SMTP Server id
	14.1.225.23; Wed, 14 Dec 2011 13:53:49 +0000
Received: from mail73-db3 (localhost [127.0.0.1])	by mail73-db3-R.bigfish.com
	(Postfix) with ESMTP id 3E4BB1E031D;
	Wed, 14 Dec 2011 13:53:50 +0000 (UTC)
X-SpamScore: -13
X-BigFish: VPS-13(zzbb2dI146fKc85dh1432N98dKzz1202hzz8275bhz2dh668h839h34h)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
X-FB-SS: 13,
Received: from mail73-db3 (localhost.localdomain [127.0.0.1]) by mail73-db3
	(MessageSwitch) id 132387083082488_8650; Wed, 14 Dec 2011 13:53:50 +0000
	(UTC)
Received: from DB3EHSMHS015.bigfish.com (unknown [10.3.81.245])	by
	mail73-db3.bigfish.com (Postfix) with ESMTP id 0F91C80044;
	Wed, 14 Dec 2011 13:53:50 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	DB3EHSMHS015.bigfish.com (10.3.87.115) with Microsoft SMTP Server id
	14.1.225.23; Wed, 14 Dec 2011 13:53:48 +0000
X-WSS-ID: 0LW759I-01-1G7-02
X-M-MSG: 
Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com
	[163.181.249.73])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 258EE1028052;	Wed, 14 Dec 2011 07:53:42 -0600 (CST)
Received: from SAUSEXDAG03.amd.com (163.181.55.3) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Wed, 14 Dec 2011 07:53:54 -0600
Received: from storexhtp02.amd.com (172.24.4.4) by sausexdag03.amd.com
	(163.181.55.3) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Wed, 14 Dec 2011 07:53:43 -0600
Received: from rhodium.osrc.amd.com (165.204.15.173) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Wed, 14 Dec 2011
	08:53:07 -0500
Message-ID: <4EE8AA3F.9040704@amd.com>
Date: Wed, 14 Dec 2011 14:53:03 +0100
From: Christoph Egger <Christoph.Egger@amd.com>
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:8.0) Gecko/20111114 Thunderbird/8.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <CB0BC143.35A76%keir@xen.org> <4EE75FB4.30609@amd.com>
	<4EE7776E0200007800067623@nat28.tlf.novell.com>
	<4EE877A8.7080706@amd.com>
	<4EE8A7DE0200007800067B17@nat28.tlf.novell.com>
In-Reply-To: <4EE8A7DE0200007800067B17@nat28.tlf.novell.com>
Content-Type: multipart/mixed; boundary="------------080706070403020908090207"
X-OriginatorOrg: amd.com
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Keir Fraser <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH] microcode fix
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--------------080706070403020908090207
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit

On 12/14/11 13:42, Jan Beulich wrote:
>>>> On 14.12.11 at 11:17, Christoph Egger<Christoph.Egger@amd.com>  wrote:
>> +struct mpbhdr {
>> +    uint32_t type;
>> +    uint32_t len;
>> +    const uint8_t data;
>
> What's this?

This little structure eliminates the uses buf_pos[x] throughout the
code which is much easier to read and understand.

> If anything, this should be data[] (and no need for const).

Then it is data[]

>> @@ -141,16 +142,19 @@ static int apply_microcode(int cpu)
>>      struct ucode_cpu_info *uci =&per_cpu(ucode_cpu_info, cpu);
>>      uint32_t rev;
>>      struct microcode_amd *mc_amd = uci->mc.mc_amd;
>> +    struct microcode_header_amd *hdr = mc_amd->mpb;
>
> Using mc_amd here, but ...
>
>>      /* We should bind the task to the CPU */
>>      BUG_ON(raw_smp_processor_id() != cpu);
>>
>>      if ( mc_amd == NULL )
>>          return -EINVAL;
>
> ... the NULL check is only here.
>
>> +    if ( mc_amd->mpb == NULL )
>> +        return -EINVAL;
>
> And quite obviously you should preferably use the local variable
> here...
>
>> -    wrmsrl(MSR_AMD_PATCHLOADER, (unsigned long)&mc_amd->hdr.data_code);
>> +    wrmsrl(MSR_AMD_PATCHLOADER, (unsigned long)mc_amd->mpb);
>
> ... and here.

done (assuming you mean 'hdr').

>> +    printk(KERN_DEBUG "microcode: size %lu, block size %u, offset %ld\n",
>> +           (unsigned long)bufsize, mpbuf->len, off);
>
> The cast is pointless; to avoid it, use %zu as format string or declare
> the parameter as 'unsigned long'.

done.

>> +    if (mc_amd->mpb_size<  mpbuf->len) {
>> +        xfree(mc_amd->mpb);
>> +        mc_amd->mpb = xmalloc_bytes(mpbuf->len);
>> +        mc_amd->mpb_size = mpbuf->len;
>
> NULL check missing here (and in such event the clearing of
> ->mpb_size).

done.

>> +    memcpy(mc_amd->mpb, (const void *)&mpbuf->data, mpbuf->len);
>
> Unnecessary cast.

Right.

>>          printk(KERN_ERR "microcode: error! Wrong "
>> -               "microcode patch file magic\n");
>> +            "microcode patch file magic\n");
>
> Why are you still mis-adjusting indentation here?

oh...

>> +    mc_amd = xmalloc_bytes(sizeof(*mc_amd));
>
> As said during the first review round - this ought to be
>
>      mc_amd = xmalloc(struct microcode_amd);

sorry, didn't realize that it was not only relevant to the shown line
of code.

>> +    while ( (ret = get_next_ucode_from_buffer_amd(mc_amd,
>> +        buf, bufsize,&offset)) == 0 )
>
> Bad indentation.

Fixed.

>> +    ASSERT(src != NULL);
>
> Pointless.

Maybe. Maybe not. Anyway, I removed it.

>> +        if (mc_amd != NULL) {
>
> While this NULL check is needed, ...
>
>> +            if (mc_amd->equiv_cpu_table)
>
> ... this and ...
>
>> +                xfree(mc_amd->equiv_cpu_table);
>> +            if (mc_amd->mpb)
>
> ... this are pointless.
>
>> +                xfree(mc_amd->mpb);
>> +            xfree(mc_amd);
>> +        }
>> +
>> +        mc_amd = xmalloc(struct microcode_amd);
>
>      uci->mc.mc_amd = mc_amd;
>
>>          if ( !mc_amd )
>
> (as was the case in the original code). No need to do this once in the
> success path and once in the error one.
>
>> +    uci->mc.mc_amd = mc_amd = NULL;
>> +    return -ENOMEM;
>
> Even if it was necessary to keep it this way, initializing a local variable
> immediately before returning is bogus (and calling for a compiler
> warning and hence a build failure due to -Werror sooner or later).

Fixed.

New version attached.
Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>

> Jan
>
>


-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo, Andrew Bowd
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632

--------------080706070403020908090207
Content-Type: text/plain; name="xen_microcode_fam15.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="xen_microcode_fam15.diff"
Content-Description: xen_microcode_fam15.diff

diff -r f1ab2c2138d8 xen/arch/x86/microcode_amd.c
--- a/xen/arch/x86/microcode_amd.c	Mon Dec 12 10:47:26 2011 +0100
+++ b/xen/arch/x86/microcode_amd.c	Wed Dec 14 14:52:04 2011 +0100
@@ -26,8 +26,6 @@
 #include <asm/processor.h>
 #include <asm/microcode.h>
 
-#define pr_debug(x...) ((void)0)
-
 struct equiv_cpu_entry {
     uint32_t installed_cpu;
     uint32_t fixed_errata_mask;
@@ -57,14 +55,17 @@ struct microcode_header_amd {
 #define UCODE_EQUIV_CPU_TABLE_TYPE 0x00000000
 #define UCODE_UCODE_TYPE           0x00000001
 
-#define UCODE_MAX_SIZE          (2048)
-#define MC_HEADER_SIZE          (sizeof(struct microcode_header_amd))
+struct microcode_amd {
+    void *mpb;
+    size_t mpb_size;
+    struct equiv_cpu_entry *equiv_cpu_table;
+    size_t equiv_cpu_table_size;
+};
 
-struct microcode_amd {
-    struct microcode_header_amd hdr;
-    unsigned int mpb[(UCODE_MAX_SIZE - MC_HEADER_SIZE) / 4];
-    unsigned int equiv_cpu_table_size;
-    struct equiv_cpu_entry equiv_cpu_table[];
+struct mpbhdr {
+    uint32_t type;
+    uint32_t len;
+    uint8_t data[];
 };
 
 /* serialize access to the physical write */
@@ -94,7 +95,7 @@ static int collect_cpu_info(int cpu, str
 static int microcode_fits(const struct microcode_amd *mc_amd, int cpu)
 {
     struct ucode_cpu_info *uci = &per_cpu(ucode_cpu_info, cpu);
-    const struct microcode_header_amd *mc_header = &mc_amd->hdr;
+    const struct microcode_header_amd *mc_header = mc_amd->mpb;
     const struct equiv_cpu_entry *equiv_cpu_table = mc_amd->equiv_cpu_table;
     unsigned int current_cpu_id;
     unsigned int equiv_cpu_id = 0x0;
@@ -141,6 +142,7 @@ static int apply_microcode(int cpu)
     struct ucode_cpu_info *uci = &per_cpu(ucode_cpu_info, cpu);
     uint32_t rev;
     struct microcode_amd *mc_amd = uci->mc.mc_amd;
+    struct microcode_header_amd *hdr;
 
     /* We should bind the task to the CPU */
     BUG_ON(raw_smp_processor_id() != cpu);
@@ -148,9 +150,13 @@ static int apply_microcode(int cpu)
     if ( mc_amd == NULL )
         return -EINVAL;
 
+    hdr = mc_amd->mpb;
+    if ( hdr == NULL )
+        return -EINVAL;
+
     spin_lock_irqsave(&microcode_update_lock, flags);
 
-    wrmsrl(MSR_AMD_PATCHLOADER, (unsigned long)&mc_amd->hdr.data_code);
+    wrmsrl(MSR_AMD_PATCHLOADER, (unsigned long)hdr);
 
     /* get patch id after patching */
     rdmsrl(MSR_AMD_PATCHLEVEL, rev);
@@ -158,99 +164,115 @@ static int apply_microcode(int cpu)
     spin_unlock_irqrestore(&microcode_update_lock, flags);
 
     /* check current patch id and patch's id for match */
-    if ( rev != mc_amd->hdr.patch_id )
+    if ( rev != hdr->patch_id )
     {
         printk(KERN_ERR "microcode: CPU%d update from revision "
                "0x%x to 0x%x failed\n", cpu,
-               mc_amd->hdr.patch_id, rev);
+               hdr->patch_id, rev);
         return -EIO;
     }
 
     printk(KERN_INFO "microcode: CPU%d updated from revision %#x to %#x\n",
-           cpu, uci->cpu_sig.rev, mc_amd->hdr.patch_id);
+           cpu, uci->cpu_sig.rev, hdr->patch_id);
 
     uci->cpu_sig.rev = rev;
 
     return 0;
 }
 
-static int get_next_ucode_from_buffer_amd(void *mc, const void *buf,
-                                         size_t size, unsigned long *offset)
+static int get_next_ucode_from_buffer_amd(struct microcode_amd *mc_amd,
+    const void *buf, size_t bufsize, unsigned long *offset)
 {
-    size_t total_size;
     const uint8_t *bufp = buf;
     unsigned long off;
+    const struct mpbhdr *mpbuf;
 
     off = *offset;
 
     /* No more data */
-    if ( off >= size )
+    if ( off >= bufsize )
         return 1;
 
-    if ( bufp[off] != UCODE_UCODE_TYPE )
+    mpbuf = (const struct mpbhdr *)&bufp[off];
+    if ( mpbuf->type != UCODE_UCODE_TYPE )
     {
         printk(KERN_ERR "microcode: error! "
                "Wrong microcode payload type field\n");
         return -EINVAL;
     }
 
-    total_size = (unsigned long) (bufp[off+4] + (bufp[off+5] << 8));
+    printk(KERN_DEBUG "microcode: size %zu, block size %u, offset %ld\n",
+           bufsize, mpbuf->len, off);
 
-    printk(KERN_DEBUG "microcode: size %lu, total_size %lu, offset %ld\n",
-           (unsigned long)size, total_size, off);
-
-    if ( (off + total_size) > size )
+    if ( (off + mpbuf->len) > bufsize )
     {
         printk(KERN_ERR "microcode: error! Bad data in microcode data file\n");
         return -EINVAL;
     }
 
-    memset(mc, 0, UCODE_MAX_SIZE);
-    memcpy(mc, (const void *)(&bufp[off + 8]), total_size);
+    if (mc_amd->mpb_size < mpbuf->len) {
+        if (mc_amd->mpb) {
+            xfree(mc_amd->mpb);
+            mc_amd->mpb_size = 0;
+        }
+        mc_amd->mpb = xmalloc_bytes(mpbuf->len);
+        if (mc_amd->mpb == NULL)
+            return -ENOMEM;
+        mc_amd->mpb_size = mpbuf->len;
+    }
+    memcpy(mc_amd->mpb, mpbuf->data, mpbuf->len);
 
-    *offset = off + total_size + 8;
+    *offset = off + mpbuf->len + 8;
 
     return 0;
 }
 
 static int install_equiv_cpu_table(
     struct microcode_amd *mc_amd,
-    const uint32_t *buf_pos,
+    const uint32_t *buf,
     unsigned long *offset)
 {
-    uint32_t size = buf_pos[2];
+    const struct mpbhdr *mpbuf = (const struct mpbhdr *)&buf[1];
 
     /* No more data */
-    if ( size + 12 >= *offset )
+    if ( mpbuf->len + 12 >= *offset )
         return -EINVAL;
 
-    if ( buf_pos[1] != UCODE_EQUIV_CPU_TABLE_TYPE )
+    if ( mpbuf->type != UCODE_EQUIV_CPU_TABLE_TYPE )
     {
         printk(KERN_ERR "microcode: error! "
                "Wrong microcode equivalent cpu table type field\n");
         return -EINVAL;
     }
 
-    if ( size == 0 )
+    if ( mpbuf->len == 0 )
     {
         printk(KERN_ERR "microcode: error! "
-               "Wrong microcode equivalnet cpu table length\n");
+               "Wrong microcode equivalent cpu table length\n");
         return -EINVAL;
     }
 
-    memcpy(mc_amd->equiv_cpu_table, &buf_pos[3], size);
-    mc_amd->equiv_cpu_table_size = size;
+    mc_amd->equiv_cpu_table = xmalloc_bytes(mpbuf->len);
+    if ( !mc_amd->equiv_cpu_table )
+    {
+        printk(KERN_ERR "microcode: error! "
+               "Can not allocate memory for equivalent cpu table\n");
+        return -ENOMEM;
+    }
 
-    *offset = size + 12;	/* add header length */
+    memcpy(mc_amd->equiv_cpu_table, mpbuf->data, mpbuf->len);
+    mc_amd->equiv_cpu_table_size = mpbuf->len;
+
+    *offset = mpbuf->len + 12;	/* add header length */
 
     return 0;
 }
 
-static int cpu_request_microcode(int cpu, const void *buf, size_t size)
+static int cpu_request_microcode(int cpu, const void *buf, size_t bufsize)
 {
-    const uint32_t *buf_pos;
+    const uint32_t *magic;
     struct microcode_amd *mc_amd, *mc_old;
-    unsigned long offset = size;
+    size_t offset = bufsize;
     int error = 0;
     int ret;
     struct ucode_cpu_info *uci = &per_cpu(ucode_cpu_info, cpu);
@@ -258,16 +280,15 @@ static int cpu_request_microcode(int cpu
     /* We should bind the task to the CPU */
     BUG_ON(cpu != raw_smp_processor_id());
 
-    buf_pos = (const uint32_t *)buf;
-
-    if ( buf_pos[0] != UCODE_MAGIC )
+    magic = (const uint32_t *)buf;
+    if ( *magic != UCODE_MAGIC )
     {
         printk(KERN_ERR "microcode: error! Wrong "
                "microcode patch file magic\n");
         return -EINVAL;
     }
 
-    mc_amd = xmalloc_bytes(sizeof(*mc_amd) + buf_pos[2]);
+    mc_amd = xmalloc(struct microcode_amd);
     if ( !mc_amd )
     {
         printk(KERN_ERR "microcode: error! "
@@ -291,7 +312,9 @@ static int cpu_request_microcode(int cpu
      * It's possible the data file has multiple matching ucode,
      * lets keep searching till the latest version
      */
-    while ( (ret = get_next_ucode_from_buffer_amd(&mc_amd->hdr, buf, size,
+    mc_amd->mpb = NULL;
+    mc_amd->mpb_size = 0;
+    while ( (ret = get_next_ucode_from_buffer_amd(mc_amd, buf, bufsize,
                                                   &offset)) == 0 )
     {
         error = microcode_fits(mc_amd, cpu);
@@ -335,17 +358,39 @@ static int microcode_resume_match(int cp
 
     if ( src != mc_amd )
     {
-        xfree(mc_amd);
-        mc_amd = xmalloc_bytes(sizeof(*src) + src->equiv_cpu_table_size);
+        if (mc_amd != NULL) {
+            xfree(mc_amd->equiv_cpu_table);
+            xfree(mc_amd->mpb);
+            xfree(mc_amd);
+        }
+
+        mc_amd = xmalloc(struct microcode_amd);
         uci->mc.mc_amd = mc_amd;
         if ( !mc_amd )
-            return -ENOMEM;
-        memcpy(mc_amd, src, UCODE_MAX_SIZE);
+            goto err0;
+        mc_amd->equiv_cpu_table = xmalloc_bytes(src->equiv_cpu_table_size);
+        if ( !mc_amd->equiv_cpu_table )
+            goto err1;
+        mc_amd->mpb = xmalloc_bytes(src->mpb_size);
+        if ( !mc_amd->mpb )
+            goto err2;
+
+        mc_amd->equiv_cpu_table_size = src->equiv_cpu_table_size;
+        mc_amd->mpb_size = src->mpb_size;
+        memcpy(mc_amd->mpb, src->mpb, src->mpb_size);
         memcpy(mc_amd->equiv_cpu_table, src->equiv_cpu_table,
                src->equiv_cpu_table_size);
     }
 
     return 1;
+
+err2:
+    xfree(mc_amd->equiv_cpu_table);
+err1:
+    xfree(mc_amd);
+err0:
+    uci->mc.mc_amd = NULL;
+    return -ENOMEM;
 }
 
 static const struct microcode_ops microcode_amd_ops = {

--------------080706070403020908090207
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--------------080706070403020908090207--


From xen-devel-bounces@lists.xensource.com Wed Dec 14 13:59:55 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 13:59:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RapMy-0006pn-1f; Wed, 14 Dec 2011 13:59:40 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1RapMw-0006pf-Bi
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 13:59:38 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1323871121!7340367!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDYyMDY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13206 invoked from network); 14 Dec 2011 13:58:42 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Dec 2011 13:58:42 -0000
X-IronPort-AV: E=Sophos;i="4.71,352,1320642000"; d="scan'208";a="19953784"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Dec 2011 08:58:41 -0500
Received: from [10.80.2.18] (10.80.2.18) by FTLPMAILMX02.citrite.net
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Wed, 14 Dec 2011
	08:58:41 -0500
Message-ID: <4EE8AB90.90505@citrix.com>
Date: Wed, 14 Dec 2011 13:58:40 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.23) Gecko/20110921 Lightning/1.0b2 Thunderbird/3.1.15
MIME-Version: 1.0
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
X-Enigmail-Version: 1.1.2
Content-Type: multipart/mixed; boundary="------------050404040902080509030901"
Subject: [Xen-devel] XLAT whitespace correction.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--------------050404040902080509030901
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit


-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com


--------------050404040902080509030901
Content-Type: text/x-patch; name="XLAT-whitespace-fix.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="XLAT-whitespace-fix.patch"

XLAT.lst whitespace fix.

Replace spaces with tabs to be in line with file format.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

diff -r 1c58bb664d8d xen/include/xlat.lst
--- a/xen/include/xlat.lst
+++ b/xen/include/xlat.lst
@@ -2,7 +2,7 @@
 # ! - needs translation
 # ? - needs checking
 ?	dom0_vga_console_info		xen.h
-?   xenctl_cpumap               xen.h
+?	xenctl_cpumap			xen.h
 ?	mmu_update			xen.h
 !	mmuext_op			xen.h
 !	start_info			xen.h

--------------050404040902080509030901
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--------------050404040902080509030901--


From xen-devel-bounces@lists.xensource.com Wed Dec 14 13:59:55 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 13:59:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RapMy-0006pn-1f; Wed, 14 Dec 2011 13:59:40 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1RapMw-0006pf-Bi
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 13:59:38 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1323871121!7340367!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDYyMDY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13206 invoked from network); 14 Dec 2011 13:58:42 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Dec 2011 13:58:42 -0000
X-IronPort-AV: E=Sophos;i="4.71,352,1320642000"; d="scan'208";a="19953784"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Dec 2011 08:58:41 -0500
Received: from [10.80.2.18] (10.80.2.18) by FTLPMAILMX02.citrite.net
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Wed, 14 Dec 2011
	08:58:41 -0500
Message-ID: <4EE8AB90.90505@citrix.com>
Date: Wed, 14 Dec 2011 13:58:40 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.23) Gecko/20110921 Lightning/1.0b2 Thunderbird/3.1.15
MIME-Version: 1.0
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
X-Enigmail-Version: 1.1.2
Content-Type: multipart/mixed; boundary="------------050404040902080509030901"
Subject: [Xen-devel] XLAT whitespace correction.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--------------050404040902080509030901
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit


-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com


--------------050404040902080509030901
Content-Type: text/x-patch; name="XLAT-whitespace-fix.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="XLAT-whitespace-fix.patch"

XLAT.lst whitespace fix.

Replace spaces with tabs to be in line with file format.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

diff -r 1c58bb664d8d xen/include/xlat.lst
--- a/xen/include/xlat.lst
+++ b/xen/include/xlat.lst
@@ -2,7 +2,7 @@
 # ! - needs translation
 # ? - needs checking
 ?	dom0_vga_console_info		xen.h
-?   xenctl_cpumap               xen.h
+?	xenctl_cpumap			xen.h
 ?	mmu_update			xen.h
 !	mmuext_op			xen.h
 !	start_info			xen.h

--------------050404040902080509030901
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--------------050404040902080509030901--


From xen-devel-bounces@lists.xensource.com Wed Dec 14 14:03:33 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 14:03:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RapQB-00079c-Lm; Wed, 14 Dec 2011 14:02:59 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1RapQ9-00079X-5J
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 14:02:57 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1323871306!58910158!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjA4OTk=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32658 invoked from network); 14 Dec 2011 14:01:47 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Dec 2011 14:01:47 -0000
X-IronPort-AV: E=Sophos;i="4.71,352,1320642000"; d="scan'208";a="174106368"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Dec 2011 09:02:03 -0500
Received: from [10.80.2.18] (10.80.2.18) by FTLPMAILMX01.citrite.net
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Wed, 14 Dec 2011
	09:02:03 -0500
Message-ID: <4EE8AC5A.4050205@citrix.com>
Date: Wed, 14 Dec 2011 14:02:02 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.23) Gecko/20110921 Lightning/1.0b2 Thunderbird/3.1.15
MIME-Version: 1.0
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
X-Enigmail-Version: 1.1.2
Content-Type: multipart/mixed; boundary="------------000408080904020902020701"
Subject: [Xen-devel] KEXEC fix 32/64bit issues with KEXEC_CMD_kexec_get_range
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--------------000408080904020902020701
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit

Attached is my first attempt at this fix.  It has been compile tested
for x86_{64,32} and so far, dev tested in so much as it does not break
backwards compatibility for 32bit dom0 on 64bit Xen.  It is untested as
far as ia64 goes, but I believe it should be correct from code inspection.

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com


--------------000408080904020902020701
Content-Type: text/x-patch; name="KEXEC-new-hypercall.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="KEXEC-new-hypercall.patch"

KEXEC: Add new hypercall to fix 64/32bit truncation errors.

Currently, KEXEC_CMD_kexec_get_range in compat mode, or with 32bit
Xen, will truncate 64bit pointers to 32bits, leading to problems on
machines with more than 4GiB of RAM.  As 32bit dom0 kernels tend to be
PAE capable, this is especially wasteful, as most structures currently
limited to <4GiB could easily be <64GiB instead.

Therefore, introduce a new hypercall 'KEXEC_CMD_kexec64_get_range'
which passes similar information as KEXEC_CMD_kexec_get_range, but
which uses a structure with explicitly specified field widths, causing
it to be identical in the compat and regular case.  This new
structure, xen_kexec64_range_t, will be the same as xen_kexec_range_t
if Xen is compiled for x86_64, but will still use 64bit integers if
Xen is compiled for x86_32.

To fix 32bit Xen which uses 32bit intergers for addresses and sizes,
change the internals to use xen_kexec64_range_t which will use 64bit
integers instead.  This also invovles changing several casts to
explicitly use uint64_ts rather than unsigned longs.

In addition, the hypercall entry points need updating to be able to
cater for all possiblities.

|Xen/dom0 bits|          Bit width of addresses in structure for        |
+------+------+---------------------------+-----------------------------+
| Xen  | dom0 | KEXEC_CMD_kexec_get_range | KEXEC_CMD_kexec64_get_range |
+------+------+---------------------------+-----------------------------+
|  32  |  32  |             32            |              64             |
|  64  |  32  |             32            |              64             |
|  64  |  64  |             64            |              64             |
+------+------+---------------------------+-----------------------------+

This has been solved by splitting do_kexec_op_internal back into
do_kexec_op{,_compat} and changing kexec_get_range{,_compat} to
kexec_get_range{32,64} which now exist irrispective of CONFIG_COMPAT
or not.

The knock-on effect of removing do_kexec_op_internal means that
kexec_load_unload_compat is only ever called from inside an #ifdef
CONFIG_COMPAT codepath, which does not exist on Xen x86_32.
Therefore, move the #ifdef CONFIG_COMPAT guards to include the entire
function.

Finally, and a little unrelatedly, fix KEXEC_CMD_kexec_{load,unload}
to return -EBUSY instead of EOK if a kexec is in progress.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

diff -r d960ea9b337d xen/arch/ia64/xen/machine_kexec.c
--- a/xen/arch/ia64/xen/machine_kexec.c
+++ b/xen/arch/ia64/xen/machine_kexec.c
@@ -102,10 +102,10 @@ void machine_reboot_kexec(xen_kexec_imag
 	machine_kexec(image);
 }
 
-int machine_kexec_get_xen(xen_kexec_range_t *range)
+int machine_kexec_get_xen(xen_kexec64_range_t *range)
 {
 	range->start = ia64_tpa(_text);
-	range->size = (unsigned long)_end - (unsigned long)_text;
+	range->size = (uint64_t)_end - (uint64_t)_text;
 	return 0;
 }
 
@@ -113,31 +113,31 @@ int machine_kexec_get_xen(xen_kexec_rang
 #define ELF_PAGE_SIZE  (__IA64_UL_CONST(1) << ELF_PAGE_SHIFT)
 #define ELF_PAGE_MASK  (~(ELF_PAGE_SIZE - 1))
 
-static int machine_kexec_get_xenheap(xen_kexec_range_t *range)
+static int machine_kexec_get_xenheap(xen_kexec64_range_t *range)
 {
 	range->start = (ia64_tpa(_end) + (ELF_PAGE_SIZE - 1)) & ELF_PAGE_MASK;
 	range->size =
-		(((unsigned long)range->start + KERNEL_TR_PAGE_SIZE) &
+		(((uint64_t)range->start + KERNEL_TR_PAGE_SIZE) &
          ~(KERNEL_TR_PAGE_SIZE - 1))
-		- (unsigned long)range->start;
+		- (uint64_t)range->start;
 	return 0;
 }
 
-static int machine_kexec_get_boot_param(xen_kexec_range_t *range)
+static int machine_kexec_get_boot_param(xen_kexec64_range_t *range)
 {
 	range->start = __pa(ia64_boot_param);
 	range->size = sizeof(*ia64_boot_param);
 	return 0;
 }
 
-static int machine_kexec_get_efi_memmap(xen_kexec_range_t *range)
+static int machine_kexec_get_efi_memmap(xen_kexec64_range_t *range)
 {
 	range->start = ia64_boot_param->efi_memmap;
 	range->size = ia64_boot_param->efi_memmap_size;
 	return 0;
 }
 
-int machine_kexec_get(xen_kexec_range_t *range)
+int machine_kexec_get(xen_kexec64_range_t *range)
 {
 	switch (range->range) {
 	case KEXEC_RANGE_MA_XEN:
diff -r d960ea9b337d xen/arch/x86/machine_kexec.c
--- a/xen/arch/x86/machine_kexec.c
+++ b/xen/arch/x86/machine_kexec.c
@@ -120,7 +120,7 @@ void machine_kexec(xen_kexec_image_t *im
     }
 }
 
-int machine_kexec_get(xen_kexec_range_t *range)
+int machine_kexec_get(xen_kexec64_range_t *range)
 {
 	if (range->range != KEXEC_RANGE_MA_XEN)
 		return -EINVAL;
diff -r d960ea9b337d xen/arch/x86/x86_32/machine_kexec.c
--- a/xen/arch/x86/x86_32/machine_kexec.c
+++ b/xen/arch/x86/x86_32/machine_kexec.c
@@ -11,11 +11,11 @@
 #include <asm/page.h>
 #include <public/kexec.h>
 
-int machine_kexec_get_xen(xen_kexec_range_t *range)
+int machine_kexec_get_xen(xen_kexec64_range_t *range)
 {
         range->start = virt_to_maddr(_start);
-        range->size = (unsigned long)xenheap_phys_end -
-                      (unsigned long)range->start;
+        range->size = (uint64_t)xenheap_phys_end -
+                      (uint64_t)range->start;
         return 0;
 }
 
diff -r d960ea9b337d xen/arch/x86/x86_64/machine_kexec.c
--- a/xen/arch/x86/x86_64/machine_kexec.c
+++ b/xen/arch/x86/x86_64/machine_kexec.c
@@ -11,10 +11,10 @@
 #include <asm/page.h>
 #include <public/kexec.h>
 
-int machine_kexec_get_xen(xen_kexec_range_t *range)
+int machine_kexec_get_xen(xen_kexec64_range_t *range)
 {
         range->start = virt_to_maddr(_start);
-        range->size = virt_to_maddr(_end) - (unsigned long)range->start;
+        range->size = virt_to_maddr(_end) - (uint64_t)range->start;
         return 0;
 }
 
diff -r d960ea9b337d xen/common/kexec.c
--- a/xen/common/kexec.c
+++ b/xen/common/kexec.c
@@ -56,6 +56,14 @@ static struct {
     unsigned long size;
 } ranges[16] __initdata;
 
+/* This XLAT macro is required now even without CONFIG_COMPAT. */
+#define TRANSLATE_kexec_range(_d_, _s_) do { \
+    (_d_)->range = (_s_)->range; \
+    (_d_)->nr = (_s_)->nr; \
+    (_d_)->size = (_s_)->size; \
+    (_d_)->start = (_s_)->start; \
+} while (0)
+
 /*
  * Parse command lines in the format
  *
@@ -280,7 +288,7 @@ static int sizeof_note(const char *name,
             ELFNOTE_ALIGN(descsz));
 }
 
-static int kexec_get_reserve(xen_kexec_range_t *range)
+static int kexec_get_reserve(xen_kexec64_range_t *range)
 {
     if ( kexec_crash_area.size > 0 && kexec_crash_area.start > 0) {
         range->start = kexec_crash_area.start;
@@ -291,7 +299,7 @@ static int kexec_get_reserve(xen_kexec_r
     return 0;
 }
 
-static int kexec_get_cpu(xen_kexec_range_t *range)
+static int kexec_get_cpu(xen_kexec64_range_t *range)
 {
     int nr = range->nr;
     int nr_bytes = 0;
@@ -335,14 +343,14 @@ static int kexec_get_cpu(xen_kexec_range
     return 0;
 }
 
-static int kexec_get_vmcoreinfo(xen_kexec_range_t *range)
+static int kexec_get_vmcoreinfo(xen_kexec64_range_t *range)
 {
     range->start = __pa((unsigned long)vmcoreinfo_data);
     range->size = VMCOREINFO_BYTES;
     return 0;
 }
 
-static int kexec_get_range_internal(xen_kexec_range_t *range)
+static int kexec_get_range_internal(xen_kexec64_range_t *range)
 {
     int ret = -EINVAL;
 
@@ -365,9 +373,14 @@ static int kexec_get_range_internal(xen_
     return ret;
 }
 
-static int kexec_get_range(XEN_GUEST_HANDLE(void) uarg)
+/* This function can be invoked from either a KEXEC_CMD_kexec64_get_range
+ * hypercall, or from a KEXEC_CMD_kexec_get_range hypercall with 64bit dom0
+ * on 64bit Xen.  In the first case, the guest structure is a 
+ * xen_kexec64_range_t, and in the second case, the xen_kexec_range_t guest
+ * structure is identical to xen_kexec64_range_t. */
+static int kexec_get_range64(XEN_GUEST_HANDLE(void) uarg)
 {
-    xen_kexec_range_t range;
+    xen_kexec64_range_t range;
     int ret = -EINVAL;
 
     if ( unlikely(copy_from_guest(&range, uarg, 1)) )
@@ -381,34 +394,40 @@ static int kexec_get_range(XEN_GUEST_HAN
     return ret;
 }
 
-static int kexec_get_range_compat(XEN_GUEST_HANDLE(void) uarg)
+/* This function can be invoked from either a KEXEC_CMD_kexec_get_range
+ * compat hypercall for 32bit dom0 on 64bit Xen, or from the same hypercall
+ * on 32bit Xen.  In both cases, the guest argument uses 32bit integers, so 
+ * translate them to 64bit for use by kexec_get_range_internal.  The
+ * preprocessor guards are to choose the correct 32bit structure, as the
+ * compat_* structures dont exist in 32bit Xen. */
+static int kexec_get_range32(XEN_GUEST_HANDLE(void) uarg)
 {
+    xen_kexec64_range_t range64;
 #ifdef CONFIG_COMPAT
-    xen_kexec_range_t range;
-    compat_kexec_range_t compat_range;
+    compat_kexec_range_t range32;
+#else
+    xen_kexec_range_t range32;
+#endif
     int ret = -EINVAL;
 
-    if ( unlikely(copy_from_guest(&compat_range, uarg, 1)) )
+    if ( unlikely(copy_from_guest(&range32, uarg, 1)) )
         return -EFAULT;
 
-    XLAT_kexec_range(&range, &compat_range);
+    TRANSLATE_kexec_range(&range64, &range32);
 
-    ret = kexec_get_range_internal(&range);
+    ret = kexec_get_range_internal(&range64);
 
     /* Dont silently truncate physical addresses or sizes. */
-    if ( (range.start | range.size) & ~(unsigned long)(~0u) )
+    if ( (range64.start | range64.size) & ~(unsigned long)(~0u) )
         return -ERANGE;
 
     if ( ret == 0 ) {
-        XLAT_kexec_range(&compat_range, &range);
-        if ( unlikely(copy_to_guest(uarg, &compat_range, 1)) )
+        TRANSLATE_kexec_range(&range32, &range64);
+        if ( unlikely(copy_to_guest(uarg, &range32, 1)) )
              return -EFAULT;
     }
 
     return ret;
-#else /* CONFIG_COMPAT */
-    return 0;
-#endif /* CONFIG_COMPAT */
 }
 
 static int kexec_load_get_bits(int type, int *base, int *bit)
@@ -543,10 +562,10 @@ static int kexec_load_unload(unsigned lo
     return kexec_load_unload_internal(op, &load);
 }
 
+#ifdef CONFIG_COMPAT
 static int kexec_load_unload_compat(unsigned long op,
                                     XEN_GUEST_HANDLE(void) uarg)
 {
-#ifdef CONFIG_COMPAT
     compat_kexec_load_t compat_load;
     xen_kexec_load_t load;
 
@@ -564,10 +583,8 @@ static int kexec_load_unload_compat(unsi
     XLAT_kexec_image(&load.image, &compat_load.image);
 
     return kexec_load_unload_internal(op, &load);
-#else /* CONFIG_COMPAT */
-    return 0;
+}
 #endif /* CONFIG_COMPAT */
-}
 
 static int kexec_exec(XEN_GUEST_HANDLE(void) uarg)
 {
@@ -601,8 +618,51 @@ static int kexec_exec(XEN_GUEST_HANDLE(v
     return -EINVAL; /* never reached */
 }
 
-int do_kexec_op_internal(unsigned long op, XEN_GUEST_HANDLE(void) uarg,
-                           int compat)
+long do_kexec_op(unsigned long op, XEN_GUEST_HANDLE(void) uarg)
+{
+    unsigned long flags;
+    int ret = -EINVAL;
+
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+
+    ret = xsm_kexec();
+    if ( ret )
+        return ret;
+
+    switch ( op )
+    {
+#ifdef __i386__
+    case KEXEC_CMD_kexec_get_range:
+        ret = kexec_get_range32(uarg);
+        break;
+#else
+    case KEXEC_CMD_kexec_get_range:
+#endif
+    case KEXEC_CMD_kexec64_get_range:
+        ret = kexec_get_range64(uarg);
+        break;
+
+    case KEXEC_CMD_kexec_load:
+    case KEXEC_CMD_kexec_unload:
+        spin_lock_irqsave(&kexec_lock, flags);
+        if (!test_bit(KEXEC_FLAG_IN_PROGRESS, &kexec_flags))
+            ret = kexec_load_unload(op, uarg);
+        else
+            ret = -EBUSY;
+        spin_unlock_irqrestore(&kexec_lock, flags);
+        break;
+
+    case KEXEC_CMD_kexec:
+        ret = kexec_exec(uarg);
+        break;
+    }
+
+    return ret;
+}
+
+#ifdef CONFIG_COMPAT
+int compat_kexec_op(unsigned long op, XEN_GUEST_HANDLE(void) uarg)
 {
     unsigned long flags;
     int ret = -EINVAL;
@@ -617,23 +677,21 @@ int do_kexec_op_internal(unsigned long o
     switch ( op )
     {
     case KEXEC_CMD_kexec_get_range:
-        if (compat)
-                ret = kexec_get_range_compat(uarg);
-        else
-                ret = kexec_get_range(uarg);
+        ret = kexec_get_range32(uarg);
+        break;
+    case KEXEC_CMD_kexec64_get_range:
+        ret = kexec_get_range64(uarg);
         break;
     case KEXEC_CMD_kexec_load:
     case KEXEC_CMD_kexec_unload:
         spin_lock_irqsave(&kexec_lock, flags);
         if (!test_bit(KEXEC_FLAG_IN_PROGRESS, &kexec_flags))
-        {
-                if (compat)
-                        ret = kexec_load_unload_compat(op, uarg);
-                else
-                        ret = kexec_load_unload(op, uarg);
-        }
+            ret = kexec_load_unload_compat(op, uarg);
+        else
+            ret = -EBUSY;
         spin_unlock_irqrestore(&kexec_lock, flags);
         break;
+
     case KEXEC_CMD_kexec:
         ret = kexec_exec(uarg);
         break;
@@ -641,17 +699,6 @@ int do_kexec_op_internal(unsigned long o
 
     return ret;
 }
-
-long do_kexec_op(unsigned long op, XEN_GUEST_HANDLE(void) uarg)
-{
-    return do_kexec_op_internal(op, uarg, 0);
-}
-
-#ifdef CONFIG_COMPAT
-int compat_kexec_op(unsigned long op, XEN_GUEST_HANDLE(void) uarg)
-{
-    return do_kexec_op_internal(op, uarg, 1);
-}
 #endif
 
 /*
diff -r d960ea9b337d xen/include/public/kexec.h
--- a/xen/include/public/kexec.h
+++ b/xen/include/public/kexec.h
@@ -155,6 +155,15 @@ typedef struct xen_kexec_range {
     unsigned long start;
 } xen_kexec_range_t;
 
+#define KEXEC_CMD_kexec64_get_range      4
+/* xen_kexec_range_t using explicit sizes for fields. */
+typedef struct xen_kexec64_range {
+    int32_t range;
+    int32_t nr;
+    uint64_t size;
+    uint64_t start;
+} xen_kexec64_range_t;
+
 #endif /* _XEN_PUBLIC_KEXEC_H */
 
 /*
diff -r d960ea9b337d xen/include/xen/kexec.h
--- a/xen/include/xen/kexec.h
+++ b/xen/include/xen/kexec.h
@@ -34,8 +34,8 @@ void kexec_crash(void);
 void kexec_crash_save_cpu(void);
 crash_xen_info_t *kexec_crash_save_info(void);
 void machine_crash_shutdown(void);
-int machine_kexec_get(xen_kexec_range_t *range);
-int machine_kexec_get_xen(xen_kexec_range_t *range);
+int machine_kexec_get(xen_kexec64_range_t *range);
+int machine_kexec_get_xen(xen_kexec64_range_t *range);
 
 void compat_machine_kexec(unsigned long rnk,
                           unsigned long indirection_page,
diff -r d960ea9b337d xen/include/xlat.lst
--- a/xen/include/xlat.lst
+++ b/xen/include/xlat.lst
@@ -50,9 +50,7 @@
 ?	grant_entry_v1			grant_table.h
 ?       grant_entry_header              grant_table.h
 ?	grant_entry_v2			grant_table.h
-?	kexec_exec			kexec.h
 !	kexec_image			kexec.h
-!	kexec_range			kexec.h
 !	add_to_physmap			memory.h
 !	foreign_memory_map		memory.h
 !	memory_exchange			memory.h

--------------000408080904020902020701
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--------------000408080904020902020701--


From xen-devel-bounces@lists.xensource.com Wed Dec 14 14:03:33 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 14:03:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RapQB-00079c-Lm; Wed, 14 Dec 2011 14:02:59 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1RapQ9-00079X-5J
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 14:02:57 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1323871306!58910158!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjA4OTk=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32658 invoked from network); 14 Dec 2011 14:01:47 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Dec 2011 14:01:47 -0000
X-IronPort-AV: E=Sophos;i="4.71,352,1320642000"; d="scan'208";a="174106368"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Dec 2011 09:02:03 -0500
Received: from [10.80.2.18] (10.80.2.18) by FTLPMAILMX01.citrite.net
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Wed, 14 Dec 2011
	09:02:03 -0500
Message-ID: <4EE8AC5A.4050205@citrix.com>
Date: Wed, 14 Dec 2011 14:02:02 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.23) Gecko/20110921 Lightning/1.0b2 Thunderbird/3.1.15
MIME-Version: 1.0
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
X-Enigmail-Version: 1.1.2
Content-Type: multipart/mixed; boundary="------------000408080904020902020701"
Subject: [Xen-devel] KEXEC fix 32/64bit issues with KEXEC_CMD_kexec_get_range
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--------------000408080904020902020701
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit

Attached is my first attempt at this fix.  It has been compile tested
for x86_{64,32} and so far, dev tested in so much as it does not break
backwards compatibility for 32bit dom0 on 64bit Xen.  It is untested as
far as ia64 goes, but I believe it should be correct from code inspection.

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com


--------------000408080904020902020701
Content-Type: text/x-patch; name="KEXEC-new-hypercall.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="KEXEC-new-hypercall.patch"

KEXEC: Add new hypercall to fix 64/32bit truncation errors.

Currently, KEXEC_CMD_kexec_get_range in compat mode, or with 32bit
Xen, will truncate 64bit pointers to 32bits, leading to problems on
machines with more than 4GiB of RAM.  As 32bit dom0 kernels tend to be
PAE capable, this is especially wasteful, as most structures currently
limited to <4GiB could easily be <64GiB instead.

Therefore, introduce a new hypercall 'KEXEC_CMD_kexec64_get_range'
which passes similar information as KEXEC_CMD_kexec_get_range, but
which uses a structure with explicitly specified field widths, causing
it to be identical in the compat and regular case.  This new
structure, xen_kexec64_range_t, will be the same as xen_kexec_range_t
if Xen is compiled for x86_64, but will still use 64bit integers if
Xen is compiled for x86_32.

To fix 32bit Xen which uses 32bit intergers for addresses and sizes,
change the internals to use xen_kexec64_range_t which will use 64bit
integers instead.  This also invovles changing several casts to
explicitly use uint64_ts rather than unsigned longs.

In addition, the hypercall entry points need updating to be able to
cater for all possiblities.

|Xen/dom0 bits|          Bit width of addresses in structure for        |
+------+------+---------------------------+-----------------------------+
| Xen  | dom0 | KEXEC_CMD_kexec_get_range | KEXEC_CMD_kexec64_get_range |
+------+------+---------------------------+-----------------------------+
|  32  |  32  |             32            |              64             |
|  64  |  32  |             32            |              64             |
|  64  |  64  |             64            |              64             |
+------+------+---------------------------+-----------------------------+

This has been solved by splitting do_kexec_op_internal back into
do_kexec_op{,_compat} and changing kexec_get_range{,_compat} to
kexec_get_range{32,64} which now exist irrispective of CONFIG_COMPAT
or not.

The knock-on effect of removing do_kexec_op_internal means that
kexec_load_unload_compat is only ever called from inside an #ifdef
CONFIG_COMPAT codepath, which does not exist on Xen x86_32.
Therefore, move the #ifdef CONFIG_COMPAT guards to include the entire
function.

Finally, and a little unrelatedly, fix KEXEC_CMD_kexec_{load,unload}
to return -EBUSY instead of EOK if a kexec is in progress.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

diff -r d960ea9b337d xen/arch/ia64/xen/machine_kexec.c
--- a/xen/arch/ia64/xen/machine_kexec.c
+++ b/xen/arch/ia64/xen/machine_kexec.c
@@ -102,10 +102,10 @@ void machine_reboot_kexec(xen_kexec_imag
 	machine_kexec(image);
 }
 
-int machine_kexec_get_xen(xen_kexec_range_t *range)
+int machine_kexec_get_xen(xen_kexec64_range_t *range)
 {
 	range->start = ia64_tpa(_text);
-	range->size = (unsigned long)_end - (unsigned long)_text;
+	range->size = (uint64_t)_end - (uint64_t)_text;
 	return 0;
 }
 
@@ -113,31 +113,31 @@ int machine_kexec_get_xen(xen_kexec_rang
 #define ELF_PAGE_SIZE  (__IA64_UL_CONST(1) << ELF_PAGE_SHIFT)
 #define ELF_PAGE_MASK  (~(ELF_PAGE_SIZE - 1))
 
-static int machine_kexec_get_xenheap(xen_kexec_range_t *range)
+static int machine_kexec_get_xenheap(xen_kexec64_range_t *range)
 {
 	range->start = (ia64_tpa(_end) + (ELF_PAGE_SIZE - 1)) & ELF_PAGE_MASK;
 	range->size =
-		(((unsigned long)range->start + KERNEL_TR_PAGE_SIZE) &
+		(((uint64_t)range->start + KERNEL_TR_PAGE_SIZE) &
          ~(KERNEL_TR_PAGE_SIZE - 1))
-		- (unsigned long)range->start;
+		- (uint64_t)range->start;
 	return 0;
 }
 
-static int machine_kexec_get_boot_param(xen_kexec_range_t *range)
+static int machine_kexec_get_boot_param(xen_kexec64_range_t *range)
 {
 	range->start = __pa(ia64_boot_param);
 	range->size = sizeof(*ia64_boot_param);
 	return 0;
 }
 
-static int machine_kexec_get_efi_memmap(xen_kexec_range_t *range)
+static int machine_kexec_get_efi_memmap(xen_kexec64_range_t *range)
 {
 	range->start = ia64_boot_param->efi_memmap;
 	range->size = ia64_boot_param->efi_memmap_size;
 	return 0;
 }
 
-int machine_kexec_get(xen_kexec_range_t *range)
+int machine_kexec_get(xen_kexec64_range_t *range)
 {
 	switch (range->range) {
 	case KEXEC_RANGE_MA_XEN:
diff -r d960ea9b337d xen/arch/x86/machine_kexec.c
--- a/xen/arch/x86/machine_kexec.c
+++ b/xen/arch/x86/machine_kexec.c
@@ -120,7 +120,7 @@ void machine_kexec(xen_kexec_image_t *im
     }
 }
 
-int machine_kexec_get(xen_kexec_range_t *range)
+int machine_kexec_get(xen_kexec64_range_t *range)
 {
 	if (range->range != KEXEC_RANGE_MA_XEN)
 		return -EINVAL;
diff -r d960ea9b337d xen/arch/x86/x86_32/machine_kexec.c
--- a/xen/arch/x86/x86_32/machine_kexec.c
+++ b/xen/arch/x86/x86_32/machine_kexec.c
@@ -11,11 +11,11 @@
 #include <asm/page.h>
 #include <public/kexec.h>
 
-int machine_kexec_get_xen(xen_kexec_range_t *range)
+int machine_kexec_get_xen(xen_kexec64_range_t *range)
 {
         range->start = virt_to_maddr(_start);
-        range->size = (unsigned long)xenheap_phys_end -
-                      (unsigned long)range->start;
+        range->size = (uint64_t)xenheap_phys_end -
+                      (uint64_t)range->start;
         return 0;
 }
 
diff -r d960ea9b337d xen/arch/x86/x86_64/machine_kexec.c
--- a/xen/arch/x86/x86_64/machine_kexec.c
+++ b/xen/arch/x86/x86_64/machine_kexec.c
@@ -11,10 +11,10 @@
 #include <asm/page.h>
 #include <public/kexec.h>
 
-int machine_kexec_get_xen(xen_kexec_range_t *range)
+int machine_kexec_get_xen(xen_kexec64_range_t *range)
 {
         range->start = virt_to_maddr(_start);
-        range->size = virt_to_maddr(_end) - (unsigned long)range->start;
+        range->size = virt_to_maddr(_end) - (uint64_t)range->start;
         return 0;
 }
 
diff -r d960ea9b337d xen/common/kexec.c
--- a/xen/common/kexec.c
+++ b/xen/common/kexec.c
@@ -56,6 +56,14 @@ static struct {
     unsigned long size;
 } ranges[16] __initdata;
 
+/* This XLAT macro is required now even without CONFIG_COMPAT. */
+#define TRANSLATE_kexec_range(_d_, _s_) do { \
+    (_d_)->range = (_s_)->range; \
+    (_d_)->nr = (_s_)->nr; \
+    (_d_)->size = (_s_)->size; \
+    (_d_)->start = (_s_)->start; \
+} while (0)
+
 /*
  * Parse command lines in the format
  *
@@ -280,7 +288,7 @@ static int sizeof_note(const char *name,
             ELFNOTE_ALIGN(descsz));
 }
 
-static int kexec_get_reserve(xen_kexec_range_t *range)
+static int kexec_get_reserve(xen_kexec64_range_t *range)
 {
     if ( kexec_crash_area.size > 0 && kexec_crash_area.start > 0) {
         range->start = kexec_crash_area.start;
@@ -291,7 +299,7 @@ static int kexec_get_reserve(xen_kexec_r
     return 0;
 }
 
-static int kexec_get_cpu(xen_kexec_range_t *range)
+static int kexec_get_cpu(xen_kexec64_range_t *range)
 {
     int nr = range->nr;
     int nr_bytes = 0;
@@ -335,14 +343,14 @@ static int kexec_get_cpu(xen_kexec_range
     return 0;
 }
 
-static int kexec_get_vmcoreinfo(xen_kexec_range_t *range)
+static int kexec_get_vmcoreinfo(xen_kexec64_range_t *range)
 {
     range->start = __pa((unsigned long)vmcoreinfo_data);
     range->size = VMCOREINFO_BYTES;
     return 0;
 }
 
-static int kexec_get_range_internal(xen_kexec_range_t *range)
+static int kexec_get_range_internal(xen_kexec64_range_t *range)
 {
     int ret = -EINVAL;
 
@@ -365,9 +373,14 @@ static int kexec_get_range_internal(xen_
     return ret;
 }
 
-static int kexec_get_range(XEN_GUEST_HANDLE(void) uarg)
+/* This function can be invoked from either a KEXEC_CMD_kexec64_get_range
+ * hypercall, or from a KEXEC_CMD_kexec_get_range hypercall with 64bit dom0
+ * on 64bit Xen.  In the first case, the guest structure is a 
+ * xen_kexec64_range_t, and in the second case, the xen_kexec_range_t guest
+ * structure is identical to xen_kexec64_range_t. */
+static int kexec_get_range64(XEN_GUEST_HANDLE(void) uarg)
 {
-    xen_kexec_range_t range;
+    xen_kexec64_range_t range;
     int ret = -EINVAL;
 
     if ( unlikely(copy_from_guest(&range, uarg, 1)) )
@@ -381,34 +394,40 @@ static int kexec_get_range(XEN_GUEST_HAN
     return ret;
 }
 
-static int kexec_get_range_compat(XEN_GUEST_HANDLE(void) uarg)
+/* This function can be invoked from either a KEXEC_CMD_kexec_get_range
+ * compat hypercall for 32bit dom0 on 64bit Xen, or from the same hypercall
+ * on 32bit Xen.  In both cases, the guest argument uses 32bit integers, so 
+ * translate them to 64bit for use by kexec_get_range_internal.  The
+ * preprocessor guards are to choose the correct 32bit structure, as the
+ * compat_* structures dont exist in 32bit Xen. */
+static int kexec_get_range32(XEN_GUEST_HANDLE(void) uarg)
 {
+    xen_kexec64_range_t range64;
 #ifdef CONFIG_COMPAT
-    xen_kexec_range_t range;
-    compat_kexec_range_t compat_range;
+    compat_kexec_range_t range32;
+#else
+    xen_kexec_range_t range32;
+#endif
     int ret = -EINVAL;
 
-    if ( unlikely(copy_from_guest(&compat_range, uarg, 1)) )
+    if ( unlikely(copy_from_guest(&range32, uarg, 1)) )
         return -EFAULT;
 
-    XLAT_kexec_range(&range, &compat_range);
+    TRANSLATE_kexec_range(&range64, &range32);
 
-    ret = kexec_get_range_internal(&range);
+    ret = kexec_get_range_internal(&range64);
 
     /* Dont silently truncate physical addresses or sizes. */
-    if ( (range.start | range.size) & ~(unsigned long)(~0u) )
+    if ( (range64.start | range64.size) & ~(unsigned long)(~0u) )
         return -ERANGE;
 
     if ( ret == 0 ) {
-        XLAT_kexec_range(&compat_range, &range);
-        if ( unlikely(copy_to_guest(uarg, &compat_range, 1)) )
+        TRANSLATE_kexec_range(&range32, &range64);
+        if ( unlikely(copy_to_guest(uarg, &range32, 1)) )
              return -EFAULT;
     }
 
     return ret;
-#else /* CONFIG_COMPAT */
-    return 0;
-#endif /* CONFIG_COMPAT */
 }
 
 static int kexec_load_get_bits(int type, int *base, int *bit)
@@ -543,10 +562,10 @@ static int kexec_load_unload(unsigned lo
     return kexec_load_unload_internal(op, &load);
 }
 
+#ifdef CONFIG_COMPAT
 static int kexec_load_unload_compat(unsigned long op,
                                     XEN_GUEST_HANDLE(void) uarg)
 {
-#ifdef CONFIG_COMPAT
     compat_kexec_load_t compat_load;
     xen_kexec_load_t load;
 
@@ -564,10 +583,8 @@ static int kexec_load_unload_compat(unsi
     XLAT_kexec_image(&load.image, &compat_load.image);
 
     return kexec_load_unload_internal(op, &load);
-#else /* CONFIG_COMPAT */
-    return 0;
+}
 #endif /* CONFIG_COMPAT */
-}
 
 static int kexec_exec(XEN_GUEST_HANDLE(void) uarg)
 {
@@ -601,8 +618,51 @@ static int kexec_exec(XEN_GUEST_HANDLE(v
     return -EINVAL; /* never reached */
 }
 
-int do_kexec_op_internal(unsigned long op, XEN_GUEST_HANDLE(void) uarg,
-                           int compat)
+long do_kexec_op(unsigned long op, XEN_GUEST_HANDLE(void) uarg)
+{
+    unsigned long flags;
+    int ret = -EINVAL;
+
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+
+    ret = xsm_kexec();
+    if ( ret )
+        return ret;
+
+    switch ( op )
+    {
+#ifdef __i386__
+    case KEXEC_CMD_kexec_get_range:
+        ret = kexec_get_range32(uarg);
+        break;
+#else
+    case KEXEC_CMD_kexec_get_range:
+#endif
+    case KEXEC_CMD_kexec64_get_range:
+        ret = kexec_get_range64(uarg);
+        break;
+
+    case KEXEC_CMD_kexec_load:
+    case KEXEC_CMD_kexec_unload:
+        spin_lock_irqsave(&kexec_lock, flags);
+        if (!test_bit(KEXEC_FLAG_IN_PROGRESS, &kexec_flags))
+            ret = kexec_load_unload(op, uarg);
+        else
+            ret = -EBUSY;
+        spin_unlock_irqrestore(&kexec_lock, flags);
+        break;
+
+    case KEXEC_CMD_kexec:
+        ret = kexec_exec(uarg);
+        break;
+    }
+
+    return ret;
+}
+
+#ifdef CONFIG_COMPAT
+int compat_kexec_op(unsigned long op, XEN_GUEST_HANDLE(void) uarg)
 {
     unsigned long flags;
     int ret = -EINVAL;
@@ -617,23 +677,21 @@ int do_kexec_op_internal(unsigned long o
     switch ( op )
     {
     case KEXEC_CMD_kexec_get_range:
-        if (compat)
-                ret = kexec_get_range_compat(uarg);
-        else
-                ret = kexec_get_range(uarg);
+        ret = kexec_get_range32(uarg);
+        break;
+    case KEXEC_CMD_kexec64_get_range:
+        ret = kexec_get_range64(uarg);
         break;
     case KEXEC_CMD_kexec_load:
     case KEXEC_CMD_kexec_unload:
         spin_lock_irqsave(&kexec_lock, flags);
         if (!test_bit(KEXEC_FLAG_IN_PROGRESS, &kexec_flags))
-        {
-                if (compat)
-                        ret = kexec_load_unload_compat(op, uarg);
-                else
-                        ret = kexec_load_unload(op, uarg);
-        }
+            ret = kexec_load_unload_compat(op, uarg);
+        else
+            ret = -EBUSY;
         spin_unlock_irqrestore(&kexec_lock, flags);
         break;
+
     case KEXEC_CMD_kexec:
         ret = kexec_exec(uarg);
         break;
@@ -641,17 +699,6 @@ int do_kexec_op_internal(unsigned long o
 
     return ret;
 }
-
-long do_kexec_op(unsigned long op, XEN_GUEST_HANDLE(void) uarg)
-{
-    return do_kexec_op_internal(op, uarg, 0);
-}
-
-#ifdef CONFIG_COMPAT
-int compat_kexec_op(unsigned long op, XEN_GUEST_HANDLE(void) uarg)
-{
-    return do_kexec_op_internal(op, uarg, 1);
-}
 #endif
 
 /*
diff -r d960ea9b337d xen/include/public/kexec.h
--- a/xen/include/public/kexec.h
+++ b/xen/include/public/kexec.h
@@ -155,6 +155,15 @@ typedef struct xen_kexec_range {
     unsigned long start;
 } xen_kexec_range_t;
 
+#define KEXEC_CMD_kexec64_get_range      4
+/* xen_kexec_range_t using explicit sizes for fields. */
+typedef struct xen_kexec64_range {
+    int32_t range;
+    int32_t nr;
+    uint64_t size;
+    uint64_t start;
+} xen_kexec64_range_t;
+
 #endif /* _XEN_PUBLIC_KEXEC_H */
 
 /*
diff -r d960ea9b337d xen/include/xen/kexec.h
--- a/xen/include/xen/kexec.h
+++ b/xen/include/xen/kexec.h
@@ -34,8 +34,8 @@ void kexec_crash(void);
 void kexec_crash_save_cpu(void);
 crash_xen_info_t *kexec_crash_save_info(void);
 void machine_crash_shutdown(void);
-int machine_kexec_get(xen_kexec_range_t *range);
-int machine_kexec_get_xen(xen_kexec_range_t *range);
+int machine_kexec_get(xen_kexec64_range_t *range);
+int machine_kexec_get_xen(xen_kexec64_range_t *range);
 
 void compat_machine_kexec(unsigned long rnk,
                           unsigned long indirection_page,
diff -r d960ea9b337d xen/include/xlat.lst
--- a/xen/include/xlat.lst
+++ b/xen/include/xlat.lst
@@ -50,9 +50,7 @@
 ?	grant_entry_v1			grant_table.h
 ?       grant_entry_header              grant_table.h
 ?	grant_entry_v2			grant_table.h
-?	kexec_exec			kexec.h
 !	kexec_image			kexec.h
-!	kexec_range			kexec.h
 !	add_to_physmap			memory.h
 !	foreign_memory_map		memory.h
 !	memory_exchange			memory.h

--------------000408080904020902020701
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--------------000408080904020902020701--


From xen-devel-bounces@lists.xensource.com Wed Dec 14 14:05:35 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 14:05:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RapSO-0007Gg-7W; Wed, 14 Dec 2011 14:05:16 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RapSN-0007GO-9P
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 14:05:15 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1323871457!8783703!1
X-Originating-IP: [209.85.210.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20763 invoked from network); 14 Dec 2011 14:04:19 -0000
Received: from mail-pz0-f43.google.com (HELO mail-pz0-f43.google.com)
	(209.85.210.43)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Dec 2011 14:04:19 -0000
Received: by daec6 with SMTP id c6so2971027dae.30
	for <xen-devel@lists.xensource.com>;
	Wed, 14 Dec 2011 06:04:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=SGVxG33nsk/1ld+2c71/9BmlOUx71IgJjmpvo0/iHk0=;
	b=pN1XHSKP5rnoJlQCtAo5aAaDXn7fna2hcT0z0Bozl8kOVocg6h3uSW8BAVrzyd5dpq
	i0xjuR4dMQ0Zwg5QCcMyLXkcncaUnwhXfMlK32KLA3E23IDsJO+aFPRR8bxHAqWp6ps6
	fG8FyMJIo4PFRUc7RiAYW+Q4/hpxDRYtXo3Yk=
MIME-Version: 1.0
Received: by 10.68.75.129 with SMTP id c1mr3550986pbw.98.1323871457120; Wed,
	14 Dec 2011 06:04:17 -0800 (PST)
Received: by 10.142.47.17 with HTTP; Wed, 14 Dec 2011 06:04:17 -0800 (PST)
In-Reply-To: <1323865525.20077.414.camel@zakaz.uk.xensource.com>
References: <patchbomb.1323768375@loki.upc.es>
	<35c322e6020501447936.1323768387@loki.upc.es>
	<20199.26896.928532.781947@mariner.uk.xensource.com>
	<CAPLaKK6wqa+VAxgzLWudQ2C2kaoXww9KK3BQhU4fKmoCAMFCzQ@mail.gmail.com>
	<1323860097.20077.394.camel@zakaz.uk.xensource.com>
	<CAPLaKK7Wv2HeRbg5Ze=B8DFe=wbzq=V35s6WVFXqrynh0ikRTw@mail.gmail.com>
	<1323863914.20077.400.camel@zakaz.uk.xensource.com>
	<CAPLaKK6dHr8fBujk-BSFO=-Ly3ZcQVEGTJcAwQRkfSWqk2Wb4g@mail.gmail.com>
	<1323865525.20077.414.camel@zakaz.uk.xensource.com>
Date: Wed, 14 Dec 2011 15:04:17 +0100
X-Google-Sender-Auth: 8pFRBOibGbmHvc6gRqfvSNfc3KU
Message-ID: <CAPLaKK4vZ3yoCsna+UWxtPrGfM_xDEZXc18uYaLuCKPh5k=C-Q@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 12 of 14 v4] libxl: set frontend status to 6
 on domain destroy
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

MjAxMS8xMi8xNCBJYW4gQ2FtcGJlbGwgPElhbi5DYW1wYmVsbEBjaXRyaXguY29tPjoKPiBPbiBX
ZWQsIDIwMTEtMTItMTQgYXQgMTI6MTggKzAwMDAsIFJvZ2VyIFBhdSBNb25uw6kgd3JvdGU6Cj4+
Cj4+IE5vIGx1Y2ssIHNldHRpbmcgYmFja2VuZCBzdGF0ZSB0byA1IGRpZCBub3QgbWFrZSB0aGUg
a2VybmVsIGRldGFjaCB0aGUKPj4gZGV2aWNlLiBJdCBzZWVtcyBsaWtlIHRoZSBrZXJuZWwgaXMg
b25seSB3YXRjaGluZyBmcm9udGVuZCB4ZW5zdG9yZQo+PiBlbnRyaWVzLgo+Cj4gRG9lcyBob3Qg
cmVtb3ZhbCBvZiBkZXZpY2VzIHdvcms/IFRoaXMgdXNlcyB0aGUgc2FtZSBtZWNoYW5pc20uCgpB
dHRhY2hpbmcgb2YgZGV2aWNlIGRvZXNuJ3Qgd29yayB2ZXJ5IHdlbGwgYmVjYXVzZSBvZiBrZXJu
ZWwgcHJvYmxlbXMsCmFuZCBkZXRhY2hpbmcgc29tZXRpbWVzIG1ha2VzIHRoZSBrZXJuZWwgY3Jh
c2guCgpJJ3ZlIHRyaWVkIHRoZSBmb2xsb3dpbmcgcHJvY2VkdXJlIGZvciBkb21haW4gZGVzdHJ1
Y3Rpb24sIGFuZCBpdCB3b3JrcyBvazoKCjEuIHJlbW92ZSBmcm9udGVuZC4KMi4gd2FpdCBmb3Ig
YmFja2VuZCB0byBzd2l0Y2ggdG8gZGlzY29ubmVjdGVkIHN0YXRlLgozLiBleGVjdXRlIGhvdHBs
dWcgc2NyaXB0cy4KNC4gcmVtb3ZlIGJhY2tlbmQuCgpJcyB0aGlzIGFjY2VwdGFibGU/CgpfX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFp
bGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tCmh0dHA6Ly9saXN0cy54ZW5z
b3VyY2UuY29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Wed Dec 14 14:05:35 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 14:05:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RapSO-0007Gg-7W; Wed, 14 Dec 2011 14:05:16 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RapSN-0007GO-9P
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 14:05:15 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1323871457!8783703!1
X-Originating-IP: [209.85.210.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20763 invoked from network); 14 Dec 2011 14:04:19 -0000
Received: from mail-pz0-f43.google.com (HELO mail-pz0-f43.google.com)
	(209.85.210.43)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Dec 2011 14:04:19 -0000
Received: by daec6 with SMTP id c6so2971027dae.30
	for <xen-devel@lists.xensource.com>;
	Wed, 14 Dec 2011 06:04:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=SGVxG33nsk/1ld+2c71/9BmlOUx71IgJjmpvo0/iHk0=;
	b=pN1XHSKP5rnoJlQCtAo5aAaDXn7fna2hcT0z0Bozl8kOVocg6h3uSW8BAVrzyd5dpq
	i0xjuR4dMQ0Zwg5QCcMyLXkcncaUnwhXfMlK32KLA3E23IDsJO+aFPRR8bxHAqWp6ps6
	fG8FyMJIo4PFRUc7RiAYW+Q4/hpxDRYtXo3Yk=
MIME-Version: 1.0
Received: by 10.68.75.129 with SMTP id c1mr3550986pbw.98.1323871457120; Wed,
	14 Dec 2011 06:04:17 -0800 (PST)
Received: by 10.142.47.17 with HTTP; Wed, 14 Dec 2011 06:04:17 -0800 (PST)
In-Reply-To: <1323865525.20077.414.camel@zakaz.uk.xensource.com>
References: <patchbomb.1323768375@loki.upc.es>
	<35c322e6020501447936.1323768387@loki.upc.es>
	<20199.26896.928532.781947@mariner.uk.xensource.com>
	<CAPLaKK6wqa+VAxgzLWudQ2C2kaoXww9KK3BQhU4fKmoCAMFCzQ@mail.gmail.com>
	<1323860097.20077.394.camel@zakaz.uk.xensource.com>
	<CAPLaKK7Wv2HeRbg5Ze=B8DFe=wbzq=V35s6WVFXqrynh0ikRTw@mail.gmail.com>
	<1323863914.20077.400.camel@zakaz.uk.xensource.com>
	<CAPLaKK6dHr8fBujk-BSFO=-Ly3ZcQVEGTJcAwQRkfSWqk2Wb4g@mail.gmail.com>
	<1323865525.20077.414.camel@zakaz.uk.xensource.com>
Date: Wed, 14 Dec 2011 15:04:17 +0100
X-Google-Sender-Auth: 8pFRBOibGbmHvc6gRqfvSNfc3KU
Message-ID: <CAPLaKK4vZ3yoCsna+UWxtPrGfM_xDEZXc18uYaLuCKPh5k=C-Q@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 12 of 14 v4] libxl: set frontend status to 6
 on domain destroy
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

MjAxMS8xMi8xNCBJYW4gQ2FtcGJlbGwgPElhbi5DYW1wYmVsbEBjaXRyaXguY29tPjoKPiBPbiBX
ZWQsIDIwMTEtMTItMTQgYXQgMTI6MTggKzAwMDAsIFJvZ2VyIFBhdSBNb25uw6kgd3JvdGU6Cj4+
Cj4+IE5vIGx1Y2ssIHNldHRpbmcgYmFja2VuZCBzdGF0ZSB0byA1IGRpZCBub3QgbWFrZSB0aGUg
a2VybmVsIGRldGFjaCB0aGUKPj4gZGV2aWNlLiBJdCBzZWVtcyBsaWtlIHRoZSBrZXJuZWwgaXMg
b25seSB3YXRjaGluZyBmcm9udGVuZCB4ZW5zdG9yZQo+PiBlbnRyaWVzLgo+Cj4gRG9lcyBob3Qg
cmVtb3ZhbCBvZiBkZXZpY2VzIHdvcms/IFRoaXMgdXNlcyB0aGUgc2FtZSBtZWNoYW5pc20uCgpB
dHRhY2hpbmcgb2YgZGV2aWNlIGRvZXNuJ3Qgd29yayB2ZXJ5IHdlbGwgYmVjYXVzZSBvZiBrZXJu
ZWwgcHJvYmxlbXMsCmFuZCBkZXRhY2hpbmcgc29tZXRpbWVzIG1ha2VzIHRoZSBrZXJuZWwgY3Jh
c2guCgpJJ3ZlIHRyaWVkIHRoZSBmb2xsb3dpbmcgcHJvY2VkdXJlIGZvciBkb21haW4gZGVzdHJ1
Y3Rpb24sIGFuZCBpdCB3b3JrcyBvazoKCjEuIHJlbW92ZSBmcm9udGVuZC4KMi4gd2FpdCBmb3Ig
YmFja2VuZCB0byBzd2l0Y2ggdG8gZGlzY29ubmVjdGVkIHN0YXRlLgozLiBleGVjdXRlIGhvdHBs
dWcgc2NyaXB0cy4KNC4gcmVtb3ZlIGJhY2tlbmQuCgpJcyB0aGlzIGFjY2VwdGFibGU/CgpfX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFp
bGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tCmh0dHA6Ly9saXN0cy54ZW5z
b3VyY2UuY29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Wed Dec 14 14:10:30 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 14:10:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RapXE-0007UH-0J; Wed, 14 Dec 2011 14:10:16 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RapXC-0007U9-3p
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 14:10:14 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1323871758!6876222!1
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 789 invoked from network); 14 Dec 2011 14:09:18 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Dec 2011 14:09:18 -0000
Received: by wgbds11 with SMTP id ds11so1561083wgb.24
	for <xen-devel@lists.xensource.com>;
	Wed, 14 Dec 2011 06:09:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:user-agent:date:from:to;
	bh=0ZWaKiWq2XkdGxNwPuiLguThzanPNcASCvuBmsW/xhw=;
	b=tBSaC6iQnTx6c9eAjt0I7/zI5iEb00tG9KXyXLeLQZzqyHnP4yr6uqXSD8SoTSuIvR
	SZElVEO6yLj0MWzJDPGs5IJwynGsnuq5Dek7EkXyWoy4wlDD1O5VCXLHMZblcEdjjKBT
	dA/F5Qt93YIOdT9j+Ho8LvjswSf1GyKGhjLGk=
Received: by 10.227.199.14 with SMTP id eq14mr2769173wbb.14.1323871758393;
	Wed, 14 Dec 2011 06:09:18 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id fo3sm3616463wib.11.2011.12.14.06.09.16
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 14 Dec 2011 06:09:17 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 3bac38f7a427af3eb9f60db08d0c2394bdf416dc
Message-Id: <3bac38f7a427af3eb9f6.1323871739@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Wed, 14 Dec 2011 15:08:59 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH v2] xenpaging: remove _XOPEN_SOURCE
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1323871725 -3600
# Node ID 3bac38f7a427af3eb9f60db08d0c2394bdf416dc
# Parent  75eff8e03cb4c2e0361cddf2baf6f7719bc76653
xenpaging: remove _XOPEN_SOURCE

The _XOPEN_SOURCE define was breaking the compilation under NetBSD.
I've removed it becasue it is not necessary.

Error message:

gcc  -O1 -fno-omit-frame-pointer -m64 -g -fno-strict-aliasing
-std=gnu99 -Wall -Wstrict-prototypes -Wno-unused-value
-Wdeclaration-after-statement   -D__XEN_TOOLS__ -MMD -MF
.xenpaging.o.d -fno-optimize-sibling-calls
-I/root/xen-04102011/tools/xenpaging/../../tools/libxc
-I/root/xen-04102011/tools/xenpaging/../../tools/include
-I/root/xen-04102011/tools/xenpaging/../../tools/xenstore
-I/root/xen-04102011/tools/xenpaging/../../tools/include -Werror
-Wno-unused -g  -c -o xenpaging.o xenpaging.c  -I/usr/xen42/include
-I/usr/include
cc1: warnings being treated as errors
xenpaging.c: In function 'xenpaging_init':
xenpaging.c:333: warning: implicit declaration of function 'asprintf'

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 75eff8e03cb4 -r 3bac38f7a427 tools/xenpaging/xenpaging.c
--- a/tools/xenpaging/xenpaging.c	Wed Dec 14 13:57:52 2011 +0100
+++ b/tools/xenpaging/xenpaging.c	Wed Dec 14 15:08:45 2011 +0100
@@ -18,7 +18,6 @@
  * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
  */
 
-#define _XOPEN_SOURCE	600
 #define _GNU_SOURCE
 
 #include <inttypes.h>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 14:10:30 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 14:10:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RapXE-0007UH-0J; Wed, 14 Dec 2011 14:10:16 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RapXC-0007U9-3p
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 14:10:14 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1323871758!6876222!1
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 789 invoked from network); 14 Dec 2011 14:09:18 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Dec 2011 14:09:18 -0000
Received: by wgbds11 with SMTP id ds11so1561083wgb.24
	for <xen-devel@lists.xensource.com>;
	Wed, 14 Dec 2011 06:09:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:user-agent:date:from:to;
	bh=0ZWaKiWq2XkdGxNwPuiLguThzanPNcASCvuBmsW/xhw=;
	b=tBSaC6iQnTx6c9eAjt0I7/zI5iEb00tG9KXyXLeLQZzqyHnP4yr6uqXSD8SoTSuIvR
	SZElVEO6yLj0MWzJDPGs5IJwynGsnuq5Dek7EkXyWoy4wlDD1O5VCXLHMZblcEdjjKBT
	dA/F5Qt93YIOdT9j+Ho8LvjswSf1GyKGhjLGk=
Received: by 10.227.199.14 with SMTP id eq14mr2769173wbb.14.1323871758393;
	Wed, 14 Dec 2011 06:09:18 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id fo3sm3616463wib.11.2011.12.14.06.09.16
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 14 Dec 2011 06:09:17 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 3bac38f7a427af3eb9f60db08d0c2394bdf416dc
Message-Id: <3bac38f7a427af3eb9f6.1323871739@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Wed, 14 Dec 2011 15:08:59 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH v2] xenpaging: remove _XOPEN_SOURCE
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1323871725 -3600
# Node ID 3bac38f7a427af3eb9f60db08d0c2394bdf416dc
# Parent  75eff8e03cb4c2e0361cddf2baf6f7719bc76653
xenpaging: remove _XOPEN_SOURCE

The _XOPEN_SOURCE define was breaking the compilation under NetBSD.
I've removed it becasue it is not necessary.

Error message:

gcc  -O1 -fno-omit-frame-pointer -m64 -g -fno-strict-aliasing
-std=gnu99 -Wall -Wstrict-prototypes -Wno-unused-value
-Wdeclaration-after-statement   -D__XEN_TOOLS__ -MMD -MF
.xenpaging.o.d -fno-optimize-sibling-calls
-I/root/xen-04102011/tools/xenpaging/../../tools/libxc
-I/root/xen-04102011/tools/xenpaging/../../tools/include
-I/root/xen-04102011/tools/xenpaging/../../tools/xenstore
-I/root/xen-04102011/tools/xenpaging/../../tools/include -Werror
-Wno-unused -g  -c -o xenpaging.o xenpaging.c  -I/usr/xen42/include
-I/usr/include
cc1: warnings being treated as errors
xenpaging.c: In function 'xenpaging_init':
xenpaging.c:333: warning: implicit declaration of function 'asprintf'

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 75eff8e03cb4 -r 3bac38f7a427 tools/xenpaging/xenpaging.c
--- a/tools/xenpaging/xenpaging.c	Wed Dec 14 13:57:52 2011 +0100
+++ b/tools/xenpaging/xenpaging.c	Wed Dec 14 15:08:45 2011 +0100
@@ -18,7 +18,6 @@
  * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
  */
 
-#define _XOPEN_SOURCE	600
 #define _GNU_SOURCE
 
 #include <inttypes.h>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 14:33:24 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 14: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.xensource.com>)
	id 1RaptL-0008GN-Ey; Wed, 14 Dec 2011 14:33:07 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xieliwei@gmail.com>) id 1RaptJ-0008G1-0D
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 14:33:05 +0000
X-Env-Sender: xieliwei@gmail.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1323873091!46700932!1
X-Originating-IP: [209.85.213.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8735 invoked from network); 14 Dec 2011 14:31:32 -0000
Received: from mail-yw0-f43.google.com (HELO mail-yw0-f43.google.com)
	(209.85.213.43)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Dec 2011 14:31:32 -0000
Received: by yhr49 with SMTP id 49so25986552yhr.30
	for <xen-devel@lists.xensource.com>;
	Wed, 14 Dec 2011 06:32:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type;
	bh=UckpZW54hnxt2E4BpJgj8kIuoqU4/HrxOs70at+zCZ4=;
	b=FnlBOcDsVbZFgMiMet3smMrWJD5ZFbczrSeH4E8Wqvu7XZ0R2KnwOBZZzIzC/jxBcu
	WU+hgDA5X973Nfw69n/ni3qK5Cd5FtztER0DbZoIA4Ry2HNCVpu2VppIjJDCAHP/5vWM
	Dtql0U7cCB5zOpaXsl06vJd3WdBRiFzPSchK0=
Received: by 10.236.201.194 with SMTP id b42mr12576034yho.32.1323873131195;
	Wed, 14 Dec 2011 06:32:11 -0800 (PST)
MIME-Version: 1.0
Received: by 10.100.10.4 with HTTP; Wed, 14 Dec 2011 06:31:50 -0800 (PST)
In-Reply-To: <20111214125833.GA51060@ocelot.phlegethon.org>
References: <CAPE0SYwsqRKDuPTz66r0nTVPYcsFx0Dk2j0pWpCiHELuU5W2iA@mail.gmail.com>
	<4EE881270200007800067A65@nat28.tlf.novell.com>
	<20111214125833.GA51060@ocelot.phlegethon.org>
From: Liwei <xieliwei@gmail.com>
Date: Wed, 14 Dec 2011 22:31:50 +0800
Message-ID: <CAPE0SYzJLCjO_9Nt5v7jxuMvbv=DFbGGs41=XANRXujbhAW5Vw@mail.gmail.com>
To: Tim Deegan <tim@xen.org>, Ian.Campbell@citrix.com, keir@xen.org, 
	Jan Beulich <JBeulich@suse.com>
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] PTE Write access is not set
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hello all,
    My apologies for the unclear email. Here are the events in
chronological order:

======First instance of VM Crash======
Guest is openSuSE 11.4 on 2.6.37.6-0.5-desktop
No symptoms in guest logs, logging just stopped.
Looking at the serial logs, it appears that the guest just vapourised
(unless the "First re-creation of guest" below is actually the first
crash, though Jan and Tim mentioned that that crash couldn't have
occurred during run-time).
This VM has one part of the Intel 82575GB (0e:00.1) pass-throughed.

++++First re-creation of guest++++
xl create /etc/xen/vm-test4.cfg

----Xen log----
(XEN) HVM7: ata0-0: PCHS=16383/16/63 translation=lba LCHS=1024/255/63
(XEN) HVM7: ata0 master: QEMU HARDDISK ATA-7 Hard-Disk ( 160 GBytes)
(XEN) realmode.c:115:d7 Failed to emulate insn.
(XEN) realmode.c:165:d7 Real-mode emulation failed @ a8c0:00005a8e: ff
fa 00 15 99 2c
(XEN) domain_crash called from realmode.c:166
(XEN) Domain 7 (vcpu#0) crashed on cpu#3:
(XEN) ----[ Xen-4.1.3-rc1-pre  x86_64  debug=n  Not tainted ]----
(XEN) CPU:    3
(XEN) RIP:    a8c0:[<0000000000005a8e>]
(XEN) RFLAGS: 0000000000010006   CONTEXT: hvm guest
(XEN) rax: 0000000000000120   rbx: 0000000000000000   rcx: 00000000000dffff
(XEN) rdx: 00000000000001f7   rsi: 000000000000ffff   rdi: 000000000000fffe
(XEN) rbp: 0000000000000db5   rsp: 000000000000eff8   r8:  0000000000000000
(XEN) r9:  0000000000000000   r10: 0000000000000000   r11: 0000000000000000
(XEN) r12: 0000000000000000   r13: 0000000000000000   r14: 0000000000000000
(XEN) r15: 0000000000000000   cr0: 0000000000000010   cr4: 0000000000000000
(XEN) cr3: 0000000000000000   cr2: 0000000000000000
(XEN) ds: 9fc0   es: 9e00   fs: 0000   gs: 0000   ss: 9e00   cs: a8c0

++++Second re-creation of guest++++
xl create /etc/xen/vm-test4.cfg

(XEN) HVM8: ata0-0: PCHS=16383/16/63 translation=lba LCHS=1024/255/63
(XEN) HVM8: ata0 master: QEMU HARDDISK ATA-7 Hard-Disk ( 160 GBytes)
(XEN) realmode.c:115:d8 Failed to emulate insn.
(XEN) realmode.c:165:d8 Real-mode emulation failed @ a8c0:0000fcb5: 72
5c 1b 80 c4 82
(XEN) domain_crash called from realmode.c:166
(XEN) Domain 8 (vcpu#0) crashed on cpu#5:
(XEN) ----[ Xen-4.1.3-rc1-pre  x86_64  debug=n  Not tainted ]----
(XEN) CPU:    5
(XEN) RIP:    a8c0:[<000000000000fcb5>]
(XEN) RFLAGS: 0000000000010002   CONTEXT: hvm guest
(XEN) rax: 0000000000000000   rbx: 0000000000000000   rcx: 00000000000d0000
(XEN) rdx: 00000000000001f7   rsi: 0000000000000000   rdi: 0000000000000dba
(XEN) rbp: 0000000000000db8   rsp: 0000000000000d38   r8:  0000000000000000
(XEN) r9:  0000000000000000   r10: 0000000000000000   r11: 0000000000000000
(XEN) r12: 0000000000000000   r13: 0000000000000000   r14: 0000000000000000
(XEN) r15: 0000000000000000   cr0: 0000000000000010   cr4: 0000000000000000
(XEN) cr3: 0000000000000000   cr2: 0000000000000000
(XEN) ds: 9fc0   es: 9e00   fs: 0000   gs: 0000   ss: 9e00   cs: a8c0

[Did the same thing a few more times with similar results and gave up,
rebooted dom0 and all was well]


[About 20 hours later]
======Second instance of VM Crash======
Guest is pfSense 2.1 on FreeBSD 8.1-RELEASE-p6
Unfortunately, I didn't get the chance to extract the guest logs as
they're purged on boot.
Similarly, looking at the serial logs, it appears that the guest just
vapourised (unless the "First re-creation of guest" below is actually
the first crash, though Jan and Tim mentioned that that crash couldn't
have occurred during run-time).
This VM has two parts of the Intel 82575GB (0d:00.0 and 0d:00.1) pass-throughed.

++++First re-creation of guest++++
xl create /etc/xen/vm-pfsense.cfg

(XEN) HVM5: Booting from Hard Disk...
(XEN) HVM5: Booting from 0000:7c00
(XEN) realmode.c:115:d5 Failed to emulate insn.
(XEN) realmode.c:165:d5 Real-mode emulation failed @ c5d5:000242bc: d9
33 01 fc 30 34
(XEN) domain_crash called from realmode.c:166
(XEN) Domain 5 (vcpu#0) crashed on cpu#0:
(XEN) ----[ Xen-4.1.3-rc1-pre  x86_64  debug=n  Not tainted ]----
(XEN) CPU:    0
(XEN) RIP:    c5d5:[<00000000000242bc>]
(XEN) RFLAGS: 0000000000010013   CONTEXT: hvm guest
(XEN) rax: 000000000000001b   rbx: 0000000000000702   rcx: 0000000000010ba7
(XEN) rdx: 0000000000008fd5   rsi: 0000000000001333   rdi: 000000000000900e
(XEN) rbp: 000000000000703e   rsp: 000000000000c5cf   r8:  0000000000000000
(XEN) r9:  0000000000000000   r10: 0000000000000000   r11: 0000000000000000
(XEN) r12: 0000000000000000   r13: 0000000000000000   r14: 0000000000000000
(XEN) r15: 0000000000000000   cr0: 0000000000000010   cr4: 0000000000000000
(XEN) cr3: 0000000000000000   cr2: 0000000000000000
(XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: 0000   cs: c5d5
(XEN) [VT-D]iommu.c:856: iommu_fault_status: Primary Pending Fault
(XEN) [VT-D]iommu.c:831: DMAR:[DMA Write] Request device [0d:00.1]
fault addr d8964f44000, iommu reg = ffff82c3fff57000
(XEN) DMAR:[fault reason 05h] PTE Write access is not set
(XEN) print_vtd_entries: iommu = ffff83045ce565c0 bdf = d:0.1 gmfn = d8964f44
(XEN)     root_entry = ffff8304519d1000
(XEN)     root_entry[d] = 4127af001
(XEN)     context = ffff8304127af000
(XEN)     context[1] = 2_414aca001
(XEN)     l4 = ffff830414aca000
(XEN)     l4_index = 1b
(XEN)     l4[1b] = 0
(XEN)     l4[1b] not present

++++Second re-creation of guest++++
xl create /etc/xen/vm-pfsense.cfg

(XEN) HVM6: Options: apmbios pcibios eltorito PMM
(XEN) HVM6:
(XEN) realmode.c:115:d6 Failed to emulate insn.
(XEN) realmode.c:165:d6 Real-mode emulation failed @ a8c0:00005a83: 72
5c 1b 80 c4 82
(XEN) domain_crash called from realmode.c:166
(XEN) Domain 6 (vcpu#0) crashed on cpu#6:
(XEN) ----[ Xen-4.1.3-rc1-pre  x86_64  debug=n  Not tainted ]----
(XEN) CPU:    6
(XEN) RIP:    a8c0:[<0000000000005a83>]
(XEN) RFLAGS: 0000000000010086   CONTEXT: hvm guest
(XEN) rax: 0000000000000000   rbx: 0000000000000db4   rcx: 00000000000f0027
(XEN) rdx: 0000000000000004   rsi: 0000000000000006   rdi: 0000000000000db2
(XEN) rbp: 0000000000000dc8   rsp: 000000000000df33   r8:  0000000000000000
(XEN) r9:  0000000000000000   r10: 0000000000000000   r11: 0000000000000000
(XEN) r12: 0000000000000000   r13: 0000000000000000   r14: 0000000000000000
(XEN) r15: 0000000000000000   cr0: 0000000000000010   cr4: 0000000000000000
(XEN) cr3: 0000000000000000   cr2: 0000000000000000
(XEN) ds: 9fc0   es: c000   fs: 0000   gs: 0000   ss: 9e00   cs: a8c0
(XEN) [VT-D]iommu.c:856: iommu_fault_status: Primary Pending Fault
(XEN) [VT-D]iommu.c:831: DMAR:[DMA Write] Request device [0d:00.1]
fault addr 1a16ee8000000, iommu reg = ffff82c3fff57000
(XEN) DMAR:[fault reason 04h] Access beyond MGAW
(XEN) print_vtd_entries: iommu = ffff83045ce565c0 bdf = d:0.1 gmfn = 1a16ee8000
(XEN)     root_entry = ffff8304519d1000
(XEN)     root_entry[d] = 4127af001
(XEN)     context = ffff8304127af000
(XEN)     context[1] = 102_2159b1001
(XEN)     l4 = ffff8302159b1000
(XEN)     l4_index = 142
(XEN)     l4[142] = 0
(XEN)     l4[142] not present

[Did the same thing a few more times with similar results and gave up,
rebooted dom0 and all was well]

Typical log of a booting openSuSE guest:
(XEN) HVM2: HVM Loader
(XEN) HVM2: Detected Xen v4.1.3-rc1-pre
(XEN) HVM2: CPU speed is 2930 MHz
(XEN) HVM2: Xenbus rings @0xfeffc000, event channel 9
(XEN) irq.c:264: Dom2 PCI link 0 changed 0 -> 5
(XEN) HVM2: PCI-ISA link 0 routed to IRQ5
(XEN) irq.c:264: Dom2 PCI link 1 changed 0 -> 10
(XEN) HVM2: PCI-ISA link 1 routed to IRQ10
(XEN) irq.c:264: Dom2 PCI link 2 changed 0 -> 11
(XEN) HVM2: PCI-ISA link 2 routed to IRQ11
(XEN) irq.c:264: Dom2 PCI link 3 changed 0 -> 5
(XEN) HVM2: PCI-ISA link 3 routed to IRQ5
(XEN) HVM2: pci dev 01:2 INTD->IRQ5
(XEN) HVM2: pci dev 01:3 INTA->IRQ10
(XEN) HVM2: pci dev 03:0 INTA->IRQ5
(XEN) HVM2: pci dev 04:0 INTA->IRQ5
(XEN) HVM2: pci dev 05:0 INTB->IRQ11
(XEN) HVM2: pci dev 02:0 bar 10 size 02000000: f0000008
(XEN) HVM2: pci dev 03:0 bar 14 size 01000000: f2000008
(XEN) HVM2: pci dev 05:0 bar 14 size 00200000: f3000000
(XEN) domctl.c:982:d0 memory_map:add: gfn=f3000 mfn=fb400 nr_mfns=200
(XEN) domctl.c:982:d0 memory_map:add: gfn=f3200 mfn=fb620 nr_mfns=20
(XEN) HVM2: pci dev 05:0 bar 10 size 00020000: f3200000
(XEN) domctl.c:982:d0 memory_map:add: gfn=f3220 mfn=fb644 nr_mfns=4
(XEN) domctl.c:992:d0 memory_map:remove: gfn=f3220 mfn=fb644 nr_mfns=1
(XEN) HVM2: pci dev 05:0 bar 1c size 00004000: f3220000
(XEN) HVM2: pci dev 02:0 bar 14 size 00001000: f3224000
(XEN) HVM2: pci dev 04:0 bar 10 size 00000400: 0000c001
(XEN) HVM2: pci dev 03:0 bar 10 size 00000100: 0000c401
(XEN) HVM2: pci dev 04:0 bar 14 size 00000100: 0000c501
(XEN) HVM2: pci dev 01:2 bar 20 size 00000020: 0000c601
(XEN) HVM2: pci dev 05:0 bar 18 size 00000020: 0000c621
(XEN) domctl.c:1038:d0 ioport_map:add f_gport=c620 f_mport=a880 np=20
(XEN) HVM2: pci dev 01:1 bar 20 size 00000010: 0000c641
(XEN) HVM2: Multiprocessor initialisation:
(XEN) HVM2:  - CPU0 ... 36-bit phys ... fixed MTRRs ... var MTRRs
[2/8] ... done.
(XEN) HVM2:  - CPU1 ... 36-bit phys ... fixed MTRRs ... var MTRRs
[2/8] ... done.
(XEN) HVM2:  - CPU2 ... 36-bit phys ... fixed MTRRs ... var MTRRs
[2/8] ... done.
(XEN) HVM2:  - CPU3 ... 36-bit phys ... fixed MTRRs ... var MTRRs
[2/8] ... done.
(XEN) HVM2:  - CPU4 ... 36-bit phys ... fixed MTRRs ... var MTRRs
[2/8] ... done.
(XEN) HVM2:  - CPU5 ... 36-bit phys ... fixed MTRRs ... var MTRRs
[2/8] ... done.
(XEN) HVM2:  - CPU6 ... 36-bit phys ... fixed MTRRs ... var MTRRs
[2/8] ... done.
(XEN) HVM2:  - CPU7 ... 36-bit phys ... fixed MTRRs ... var MTRRs
[2/8] ... done.
(XEN) HVM2: Writing SMBIOS tables ...
(XEN) HVM2: Loading ROMBIOS ...
(XEN) HVM2: 12604 bytes of ROMBIOS high-memory extensions:
(XEN) HVM2:   Relocating to 0xfc000000-0xfc00313c ... done
(XEN) HVM2: Creating MP tables ...
(XEN) HVM2: Loading Cirrus VGABIOS ...
(XEN) HVM2: Loading ACPI ...
(XEN) HVM2:  - Lo data: 000ea020-000ea04f
(XEN) HVM2:  - Hi data: fc003400-fc01355f
(XEN) HVM2: vm86 TSS at fc013800
(XEN) HVM2: BIOS map:
(XEN) HVM2:  c0000-c8fff: VGA BIOS
(XEN) HVM2:  eb000-eb26b: SMBIOS tables
(XEN) HVM2:  f0000-fffff: Main BIOS
(XEN) HVM2: E820 table:
(XEN) HVM2:  [00]: 00000000:00000000 - 00000000:0009e000: RAM
(XEN) HVM2:  [01]: 00000000:0009e000 - 00000000:0009fc00: RESERVED
(XEN) HVM2:  [02]: 00000000:0009fc00 - 00000000:000a0000: RESERVED
(XEN) HVM2:  HOLE: 00000000:000a0000 - 00000000:000e0000
(XEN) HVM2:  [03]: 00000000:000e0000 - 00000000:00100000: RESERVED
(XEN) HVM2:  [04]: 00000000:00100000 - 00000000:7f800000: RAM
(XEN) HVM2:  HOLE: 00000000:7f800000 - 00000000:fc000000
(XEN) HVM2:  [05]: 00000000:fc000000 - 00000001:00000000: RESERVED
(XEN) HVM2: Invoking ROMBIOS ...
(XEN) HVM2: $Revision: 1.221 $ $Date: 2008/12/07 17:32:29 $
(XEN) stdvga.c:147:d2 entering stdvga and caching modes
(XEN) HVM2: VGABios $Id: vgabios.c,v 1.67 2008/01/27 09:44:12 vruppert Exp $
(XEN) HVM2: Bochs BIOS - build: 06/23/99
(XEN) HVM2: $Revision: 1.221 $ $Date: 2008/12/07 17:32:29 $
(XEN) HVM2: Options: apmbios pcibios eltorito PMM
(XEN) HVM2:
(XEN) HVM2: ata0-0: PCHS=16383/16/63 translation=lba LCHS=1024/255/63
(XEN) HVM2: ata0 master: QEMU HARDDISK ATA-7 Hard-Disk ( 160 GBytes)
(XEN) HVM2: IDE time out
(XEN) HVM2:
(XEN) HVM2:
(XEN) HVM2:
(XEN) HVM2: Press F12 for boot menu.
(XEN) HVM2:
(XEN) HVM2: Booting from Hard Disk...
(XEN) HVM2: Booting from 0000:7c00
(XEN) HVM2: int13_harddisk: function 41, unmapped device for ELDL=81
(XEN) HVM2: int13_harddisk: function 08, unmapped device for ELDL=81
(XEN) HVM2: *** int 15h function AX=00c0, BX=0000 not yet supported!
(XEN) stdvga.c:151:d2 leaving stdvga
(XEN) stdvga.c:147:d2 entering stdvga and caching modes
(XEN) HVM2: *** int 15h function AX=ec00, BX=0002 not yet supported!
(XEN) HVM2: KBD: unsupported int 16h function 03
(XEN) HVM2: *** int 15h function AX=e980, BX=0000 not yet supported!
(XEN) HVM2: int13_harddisk: function 41, unmapped device for ELDL=81
(XEN) HVM2: int13_harddisk: function 02, unmapped device for ELDL=81
(XEN) HVM2: int13_harddisk: function 41, unmapped device for ELDL=82
(XEN) HVM2: int13_harddisk: function 02, unmapped device for ELDL=82
(XEN) HVM2: int13_harddisk: function 41, unmapped device for ELDL=83
(XEN) HVM2: int13_harddisk: function 02, unmapped device for ELDL=83
(XEN) HVM2: int13_harddisk: function 41, unmapped device for ELDL=84
(XEN) HVM2: int13_harddisk: function 02, unmapped device for ELDL=84
(XEN) HVM2: int13_harddisk: function 41, unmapped device for ELDL=85
(XEN) HVM2: int13_harddisk: function 02, unmapped device for ELDL=85
(XEN) HVM2: int13_harddisk: function 41, unmapped device for ELDL=86
(XEN) HVM2: int13_harddisk: function 02, unmapped device for ELDL=86
(XEN) HVM2: int13_harddisk: function 41, unmapped device for ELDL=87
(XEN) HVM2: int13_harddisk: function 02, unmapped device for ELDL=87
(XEN) HVM2: int13_harddisk: function 41, ELDL out of range 88
(XEN) HVM2: int13_harddisk: function 02, ELDL out of range 88
(XEN) HVM2: int13_harddisk: function 41, ELDL out of range 89
(XEN) HVM2: int13_harddisk: function 02, ELDL out of range 89
(XEN) HVM2: int13_harddisk: function 41, ELDL out of range 8a
(XEN) HVM2: int13_harddisk: function 02, ELDL out of range 8a
(XEN) HVM2: int13_harddisk: function 41, ELDL out of range 8b
(XEN) HVM2: int13_harddisk: function 02, ELDL out of range 8b
(XEN) HVM2: int13_harddisk: function 41, ELDL out of range 8c
(XEN) HVM2: int13_harddisk: function 02, ELDL out of range 8c
(XEN) HVM2: int13_harddisk: function 41, ELDL out of range 8d
(XEN) HVM2: int13_harddisk: function 02, ELDL out of range 8d
(XEN) HVM2: int13_harddisk: function 41, ELDL out of range 8e
(XEN) HVM2: int13_harddisk: function 02, ELDL out of range 8e
(XEN) HVM2: int13_harddisk: function 41, ELDL out of range 8f
(XEN) HVM2: int13_harddisk: function 02, ELDL out of range 8f
(XEN) stdvga.c:151:d2 leaving stdvga
(XEN) domctl.c:992:d0 memory_map:remove: gfn=f3200 mfn=fb620 nr_mfns=20
(XEN) domctl.c:992:d0 memory_map:remove: gfn=f3000 mfn=fb400 nr_mfns=200
(XEN) domctl.c:1062:d0 ioport_map:remove f_gport=c620 f_mport=a880 np=20
(XEN) domctl.c:982:d0 memory_map:add: gfn=f3220 mfn=fb644 nr_mfns=1
(XEN) domctl.c:992:d0 memory_map:remove: gfn=f3220 mfn=fb644 nr_mfns=4
(XEN) domctl.c:982:d0 memory_map:add: gfn=f3200 mfn=fb620 nr_mfns=20
(XEN) domctl.c:982:d0 memory_map:add: gfn=f3000 mfn=fb400 nr_mfns=200
(XEN) domctl.c:1038:d0 ioport_map:add f_gport=c620 f_mport=a880 np=20
(XEN) domctl.c:982:d0 memory_map:add: gfn=f3220 mfn=fb644 nr_mfns=4
(XEN) domctl.c:992:d0 memory_map:remove: gfn=f3220 mfn=fb644 nr_mfns=1
(XEN) domctl.c:992:d0 memory_map:remove: gfn=f3200 mfn=fb620 nr_mfns=20
(XEN) domctl.c:992:d0 memory_map:remove: gfn=f3000 mfn=fb400 nr_mfns=200
(XEN) domctl.c:1062:d0 ioport_map:remove f_gport=c620 f_mport=a880 np=20
(XEN) domctl.c:982:d0 memory_map:add: gfn=f3220 mfn=fb644 nr_mfns=1
(XEN) domctl.c:992:d0 memory_map:remove: gfn=f3220 mfn=fb644 nr_mfns=4
(XEN) domctl.c:982:d0 memory_map:add: gfn=f3200 mfn=fb620 nr_mfns=20
(XEN) domctl.c:982:d0 memory_map:add: gfn=f3000 mfn=fb400 nr_mfns=200
(XEN) domctl.c:1038:d0 ioport_map:add f_gport=c620 f_mport=a880 np=20
(XEN) domctl.c:982:d0 memory_map:add: gfn=f3220 mfn=fb644 nr_mfns=4
(XEN) domctl.c:992:d0 memory_map:remove: gfn=f3220 mfn=fb644 nr_mfns=1
(XEN) domctl.c:992:d0 memory_map:remove: gfn=f3200 mfn=fb620 nr_mfns=20
(XEN) domctl.c:992:d0 memory_map:remove: gfn=f3000 mfn=fb400 nr_mfns=200
(XEN) domctl.c:1062:d0 ioport_map:remove f_gport=c620 f_mport=a880 np=20
(XEN) domctl.c:982:d0 memory_map:add: gfn=f3220 mfn=fb644 nr_mfns=1
(XEN) domctl.c:992:d0 memory_map:remove: gfn=f3220 mfn=fb644 nr_mfns=4
(XEN) domctl.c:982:d0 memory_map:add: gfn=f3200 mfn=fb620 nr_mfns=20
(XEN) domctl.c:982:d0 memory_map:add: gfn=f3000 mfn=fb400 nr_mfns=200
(XEN) domctl.c:1038:d0 ioport_map:add f_gport=c620 f_mport=a880 np=20
(XEN) domctl.c:982:d0 memory_map:add: gfn=f3220 mfn=fb644 nr_mfns=4
(XEN) domctl.c:992:d0 memory_map:remove: gfn=f3220 mfn=fb644 nr_mfns=1
(XEN) domctl.c:992:d0 memory_map:remove: gfn=f3200 mfn=fb620 nr_mfns=20
(XEN) domctl.c:992:d0 memory_map:remove: gfn=f3000 mfn=fb400 nr_mfns=200
(XEN) domctl.c:1062:d0 ioport_map:remove f_gport=c620 f_mport=a880 np=20
(XEN) domctl.c:982:d0 memory_map:add: gfn=f3220 mfn=fb644 nr_mfns=1
(XEN) domctl.c:992:d0 memory_map:remove: gfn=f3220 mfn=fb644 nr_mfns=4
(XEN) domctl.c:982:d0 memory_map:add: gfn=f3200 mfn=fb620 nr_mfns=20
(XEN) domctl.c:982:d0 memory_map:add: gfn=f3000 mfn=fb400 nr_mfns=200
(XEN) domctl.c:1038:d0 ioport_map:add f_gport=c620 f_mport=a880 np=20
(XEN) domctl.c:982:d0 memory_map:add: gfn=f3220 mfn=fb644 nr_mfns=4
(XEN) domctl.c:992:d0 memory_map:remove: gfn=f3220 mfn=fb644 nr_mfns=1
(XEN) domctl.c:992:d0 memory_map:remove: gfn=f3200 mfn=fb620 nr_mfns=20
(XEN) domctl.c:992:d0 memory_map:remove: gfn=f3000 mfn=fb400 nr_mfns=200
(XEN) domctl.c:1062:d0 ioport_map:remove f_gport=c620 f_mport=a880 np=20
(XEN) domctl.c:982:d0 memory_map:add: gfn=f3220 mfn=fb644 nr_mfns=1
(XEN) domctl.c:992:d0 memory_map:remove: gfn=f3220 mfn=fb644 nr_mfns=4
(XEN) domctl.c:982:d0 memory_map:add: gfn=f3200 mfn=fb620 nr_mfns=20
(XEN) domctl.c:982:d0 memory_map:add: gfn=f3000 mfn=fb400 nr_mfns=200
(XEN) domctl.c:1038:d0 ioport_map:add f_gport=c620 f_mport=a880 np=20
(XEN) domctl.c:982:d0 memory_map:add: gfn=f3220 mfn=fb644 nr_mfns=4
(XEN) domctl.c:992:d0 memory_map:remove: gfn=f3220 mfn=fb644 nr_mfns=1
(XEN) domctl.c:992:d0 memory_map:remove: gfn=f3200 mfn=fb620 nr_mfns=20
(XEN) domctl.c:992:d0 memory_map:remove: gfn=f3000 mfn=fb400 nr_mfns=200
(XEN) domctl.c:1062:d0 ioport_map:remove f_gport=c620 f_mport=a880 np=20
(XEN) domctl.c:982:d0 memory_map:add: gfn=f3220 mfn=fb644 nr_mfns=1
(XEN) domctl.c:992:d0 memory_map:remove: gfn=f3220 mfn=fb644 nr_mfns=4
(XEN) domctl.c:982:d0 memory_map:add: gfn=f3200 mfn=fb620 nr_mfns=20
(XEN) domctl.c:982:d0 memory_map:add: gfn=f3000 mfn=fb400 nr_mfns=200
(XEN) domctl.c:1038:d0 ioport_map:add f_gport=c620 f_mport=a880 np=20
(XEN) domctl.c:982:d0 memory_map:add: gfn=f3220 mfn=fb644 nr_mfns=4
(XEN) domctl.c:992:d0 memory_map:remove: gfn=f3220 mfn=fb644 nr_mfns=1
(XEN) domctl.c:992:d0 memory_map:remove: gfn=f3200 mfn=fb620 nr_mfns=20
(XEN) domctl.c:992:d0 memory_map:remove: gfn=f3000 mfn=fb400 nr_mfns=200
(XEN) domctl.c:1062:d0 ioport_map:remove f_gport=c620 f_mport=a880 np=20
(XEN) domctl.c:982:d0 memory_map:add: gfn=f3220 mfn=fb644 nr_mfns=1
(XEN) domctl.c:992:d0 memory_map:remove: gfn=f3220 mfn=fb644 nr_mfns=4
(XEN) domctl.c:982:d0 memory_map:add: gfn=f3200 mfn=fb620 nr_mfns=20
(XEN) domctl.c:982:d0 memory_map:add: gfn=f3000 mfn=fb400 nr_mfns=200
(XEN) domctl.c:1038:d0 ioport_map:add f_gport=c620 f_mport=a880 np=20
(XEN) domctl.c:982:d0 memory_map:add: gfn=f3220 mfn=fb644 nr_mfns=4
(XEN) domctl.c:992:d0 memory_map:remove: gfn=f3220 mfn=fb644 nr_mfns=1
(XEN) irq.c:264: Dom2 PCI link 0 changed 5 -> 0
(XEN) irq.c:264: Dom2 PCI link 1 changed 10 -> 0
(XEN) irq.c:264: Dom2 PCI link 2 changed 11 -> 0
(XEN) irq.c:264: Dom2 PCI link 3 changed 5 -> 0
(XEN) irq.c:330: Dom2 callback via changed to PCI INTx Dev 0x03 IntA
(XEN) msi.c:867: MSI is already in use on device 0e:00.1
(XEN) msi.c:867: MSI is already in use on device 0e:00.1
(XEN) msi.c:867: MSI is already in use on device 0e:00.1
(XEN) msi.c:867: MSI is already in use on device 0e:00.1
(XEN) msi.c:867: MSI is already in use on device 0e:00.1
(XEN) msi.c:867: MSI is already in use on device 0e:00.1
(XEN) msi.c:867: MSI is already in use on device 0e:00.1
(XEN) msi.c:867: MSI is already in use on device 0e:00.1
(XEN) msi.c:867: MSI is already in use on device 0e:00.1
(XEN) physdev.c:170: dom3: 16:-1 already mapped to 16
(XEN) physdev.c:170: dom3: 19:-1 already mapped to 20

Typical log of a booting pfSense guest:
(XEN) HVM1: HVM Loader
(XEN) HVM1: Detected Xen v4.1.3-rc1-pre
(XEN) HVM1: CPU speed is 2930 MHz
(XEN) HVM1: Xenbus rings @0xfeffc000, event channel 9
(XEN) irq.c:264: Dom1 PCI link 0 changed 0 -> 5
(XEN) HVM1: PCI-ISA link 0 routed to IRQ5
(XEN) irq.c:264: Dom1 PCI link 1 changed 0 -> 10
(XEN) HVM1: PCI-ISA link 1 routed to IRQ10
(XEN) irq.c:264: Dom1 PCI link 2 changed 0 -> 11
(XEN) HVM1: PCI-ISA link 2 routed to IRQ11
(XEN) irq.c:264: Dom1 PCI link 3 changed 0 -> 5
(XEN) HVM1: PCI-ISA link 3 routed to IRQ5
(XEN) HVM1: pci dev 01:3 INTA->IRQ10
(XEN) HVM1: pci dev 03:0 INTA->IRQ5
(XEN) HVM1: pci dev 04:0 INTA->IRQ5
(XEN) HVM1: pci dev 05:0 INTB->IRQ11
(XEN) HVM1: pci dev 02:0 bar 10 size 02000000: f0000008
(XEN) HVM1: pci dev 03:0 bar 14 size 01000000: f2000008
(XEN) HVM1: pci dev 04:0 bar 14 size 00200000: f3000000
(XEN) domctl.c:982:d0 memory_map:add: gfn=f3000 mfn=faa00 nr_mfns=200
(XEN) HVM1: pci dev 05:0 bar 14 size 00200000: f3200000
(XEN) domctl.c:982:d0 memory_map:add: gfn=f3200 mfn=fac00 nr_mfns=200
(XEN) domctl.c:982:d0 memory_map:add: gfn=f3400 mfn=fa900 nr_mfns=20
(XEN) HVM1: pci dev 04:0 bar 10 size 00020000: f3400000
(XEN) domctl.c:982:d0 memory_map:add: gfn=f3420 mfn=fa920 nr_mfns=20
(XEN) HVM1: pci dev 05:0 bar 10 size 00020000: f3420000
(XEN) domctl.c:982:d0 memory_map:add: gfn=f3440 mfn=fa940 nr_mfns=4
(XEN) domctl.c:992:d0 memory_map:remove: gfn=f3440 mfn=fa940 nr_mfns=1
(XEN) HVM1: pci dev 04:0 bar 1c size 00004000: f3440000
(XEN) domctl.c:982:d0 memory_map:add: gfn=f3444 mfn=fa944 nr_mfns=4
(XEN) domctl.c:992:d0 memory_map:remove: gfn=f3444 mfn=fa944 nr_mfns=1
(XEN) HVM1: pci dev 05:0 bar 1c size 00004000: f3444000
(XEN) HVM1: pci dev 02:0 bar 14 size 00001000: f3448000
(XEN) HVM1: pci dev 03:0 bar 10 size 00000100: 0000c001
(XEN) HVM1: pci dev 04:0 bar 18 size 00000020: 0000c101
(XEN) domctl.c:1038:d0 ioport_map:add f_gport=c100 f_mport=9c00 np=20
(XEN) HVM1: pci dev 05:0 bar 18 size 00000020: 0000c121
(XEN) domctl.c:1038:d0 ioport_map:add f_gport=c120 f_mport=9880 np=20
(XEN) HVM1: pci dev 01:1 bar 20 size 00000010: 0000c141
(XEN) HVM1: Multiprocessor initialisation:
(XEN) HVM1:  - CPU0 ... 36-bit phys ... fixed MTRRs ... var MTRRs
[2/8] ... done.
(XEN) HVM1:  - CPU1 ... 36-bit phys ... fixed MTRRs ... var MTRRs
[2/8] ... done.
(XEN) HVM1:  - CPU2 ... 36-bit phys ... fixed MTRRs ... var MTRRs
[2/8] ... done.
(XEN) HVM1:  - CPU3 ... 36-bit phys ... fixed MTRRs ... var MTRRs
[2/8] ... done.
(XEN) HVM1:  - CPU4 ... 36-bit phys ... fixed MTRRs ... var MTRRs
[2/8] ... done.
(XEN) HVM1:  - CPU5 ... 36-bit phys ... fixed MTRRs ... var MTRRs
[2/8] ... done.
(XEN) HVM1:  - CPU6 ... 36-bit phys ... fixed MTRRs ... var MTRRs
[2/8] ... done.
(XEN) HVM1:  - CPU7 ... 36-bit phys ... fixed MTRRs ... var MTRRs
[2/8] ... done.
(XEN) HVM1: Writing SMBIOS tables ...
(XEN) HVM1: Loading ROMBIOS ...
(XEN) HVM1: 12604 bytes of ROMBIOS high-memory extensions:
(XEN) HVM1:   Relocating to 0xfc000000-0xfc00313c ... done
(XEN) HVM1: Creating MP tables ...
(XEN) HVM1: Loading Cirrus VGABIOS ...
(XEN) HVM1: Loading ACPI ...
(XEN) HVM1:  - Lo data: 000ea020-000ea04f
(XEN) HVM1:  - Hi data: fc003400-fc01355f
(XEN) HVM1: vm86 TSS at fc013800
(XEN) HVM1: BIOS map:
(XEN) HVM1:  c0000-c8fff: VGA BIOS
(XEN) HVM1:  eb000-eb26b: SMBIOS tables
(XEN) HVM1:  f0000-fffff: Main BIOS
(XEN) HVM1: E820 table:
(XEN) HVM1:  [00]: 00000000:00000000 - 00000000:0009e000: RAM
(XEN) HVM1:  [01]: 00000000:0009e000 - 00000000:0009fc00: RESERVED
(XEN) HVM1:  [02]: 00000000:0009fc00 - 00000000:000a0000: RESERVED
(XEN) HVM1:  HOLE: 00000000:000a0000 - 00000000:000e0000
(XEN) HVM1:  [03]: 00000000:000e0000 - 00000000:00100000: RESERVED
(XEN) HVM1:  [04]: 00000000:00100000 - 00000000:3f800000: RAM
(XEN) HVM1:  HOLE: 00000000:3f800000 - 00000000:fc000000
(XEN) HVM1:  [05]: 00000000:fc000000 - 00000001:00000000: RESERVED
(XEN) HVM1: Invoking ROMBIOS ...
(XEN) HVM1: $Revision: 1.221 $ $Date: 2008/12/07 17:32:29 $
(XEN) stdvga.c:147:d1 entering stdvga and caching modes
(XEN) HVM1: VGABios $Id: vgabios.c,v 1.67 2008/01/27 09:44:12 vruppert Exp $
(XEN) HVM1: Bochs BIOS - build: 06/23/99
(XEN) HVM1: $Revision: 1.221 $ $Date: 2008/12/07 17:32:29 $
(XEN) HVM1: Options: apmbios pcibios eltorito PMM
(XEN) HVM1:
(XEN) HVM1: ata0 master: QEMU DVD-ROM ATAPI-4 CD-Rom/DVD-Rom
(XEN) HVM1: ata0-1: PCHS=16383/16/63 translation=lba LCHS=1024/255/63
(XEN) HVM1: ata0  slave: QEMU HARDDISK ATA-7 Hard-Disk (16384 MBytes)
(XEN) HVM1:
(XEN) HVM1:
(XEN) HVM1:
(XEN) HVM1: Press F12 for boot menu.
(XEN) HVM1:
(XEN) HVM1: Booting from Hard Disk...
(XEN) HVM1: Booting from 0000:7c00
(XEN) irq.c:264: Dom1 PCI link 0 changed 5 -> 0
(XEN) irq.c:264: Dom1 PCI link 1 changed 10 -> 0
(XEN) irq.c:264: Dom1 PCI link 2 changed 11 -> 0
(XEN) irq.c:264: Dom1 PCI link 3 changed 5 -> 0
(XEN) domctl.c:992:d0 memory_map:remove: gfn=f3400 mfn=fa900 nr_mfns=20
(XEN) domctl.c:992:d0 memory_map:remove: gfn=f3000 mfn=faa00 nr_mfns=200
(XEN) domctl.c:982:d0 memory_map:add: gfn=f3440 mfn=fa940 nr_mfns=1
(XEN) domctl.c:992:d0 memory_map:remove: gfn=f3440 mfn=fa940 nr_mfns=4
(XEN) domctl.c:982:d0 memory_map:add: gfn=f3400 mfn=fa900 nr_mfns=20
(XEN) domctl.c:982:d0 memory_map:add: gfn=f3000 mfn=faa00 nr_mfns=200
(XEN) domctl.c:982:d0 memory_map:add: gfn=f3440 mfn=fa940 nr_mfns=4
(XEN) domctl.c:992:d0 memory_map:remove: gfn=f3440 mfn=fa940 nr_mfns=1
(XEN) domctl.c:992:d0 memory_map:remove: gfn=f3400 mfn=fa900 nr_mfns=20
(XEN) domctl.c:992:d0 memory_map:remove: gfn=f3000 mfn=faa00 nr_mfns=200
(XEN) domctl.c:982:d0 memory_map:add: gfn=f3440 mfn=fa940 nr_mfns=1
(XEN) domctl.c:992:d0 memory_map:remove: gfn=f3440 mfn=fa940 nr_mfns=4
(XEN) domctl.c:982:d0 memory_map:add: gfn=f3400 mfn=fa900 nr_mfns=20
(XEN) domctl.c:982:d0 memory_map:add: gfn=f3000 mfn=faa00 nr_mfns=200
(XEN) domctl.c:982:d0 memory_map:add: gfn=f3440 mfn=fa940 nr_mfns=4
(XEN) domctl.c:992:d0 memory_map:remove: gfn=f3440 mfn=fa940 nr_mfns=1
(XEN) domctl.c:1062:d0 ioport_map:remove f_gport=c100 f_mport=9c00 np=20
(XEN) domctl.c:1038:d0 ioport_map:add f_gport=c100 f_mport=9c00 np=20
(XEN) domctl.c:992:d0 memory_map:remove: gfn=f3400 mfn=fa900 nr_mfns=20
(XEN) domctl.c:992:d0 memory_map:remove: gfn=f3000 mfn=faa00 nr_mfns=200
(XEN) domctl.c:982:d0 memory_map:add: gfn=f3440 mfn=fa940 nr_mfns=1
(XEN) domctl.c:992:d0 memory_map:remove: gfn=f3440 mfn=fa940 nr_mfns=4
(XEN) domctl.c:982:d0 memory_map:add: gfn=f3400 mfn=fa900 nr_mfns=20
(XEN) domctl.c:982:d0 memory_map:add: gfn=f3000 mfn=faa00 nr_mfns=200
(XEN) domctl.c:982:d0 memory_map:add: gfn=f3440 mfn=fa940 nr_mfns=4
(XEN) domctl.c:992:d0 memory_map:remove: gfn=f3440 mfn=fa940 nr_mfns=1
(XEN) domctl.c:992:d0 memory_map:remove: gfn=f3400 mfn=fa900 nr_mfns=20
(XEN) domctl.c:992:d0 memory_map:remove: gfn=f3000 mfn=faa00 nr_mfns=200
(XEN) domctl.c:982:d0 memory_map:add: gfn=f3440 mfn=fa940 nr_mfns=1
(XEN) domctl.c:992:d0 memory_map:remove: gfn=f3440 mfn=fa940 nr_mfns=4
(XEN) domctl.c:982:d0 memory_map:add: gfn=f3400 mfn=fa900 nr_mfns=20
(XEN) domctl.c:982:d0 memory_map:add: gfn=f3000 mfn=faa00 nr_mfns=200
(XEN) domctl.c:982:d0 memory_map:add: gfn=f3440 mfn=fa940 nr_mfns=4
(XEN) domctl.c:992:d0 memory_map:remove: gfn=f3440 mfn=fa940 nr_mfns=1
(XEN) domctl.c:992:d0 memory_map:remove: gfn=f3400 mfn=fa900 nr_mfns=20
(XEN) domctl.c:992:d0 memory_map:remove: gfn=f3000 mfn=faa00 nr_mfns=200
(XEN) domctl.c:982:d0 memory_map:add: gfn=f3440 mfn=fa940 nr_mfns=1
(XEN) domctl.c:992:d0 memory_map:remove: gfn=f3440 mfn=fa940 nr_mfns=4
(XEN) domctl.c:982:d0 memory_map:add: gfn=f3400 mfn=fa900 nr_mfns=20
(XEN) domctl.c:982:d0 memory_map:add: gfn=f3000 mfn=faa00 nr_mfns=200
(XEN) domctl.c:982:d0 memory_map:add: gfn=f3440 mfn=fa940 nr_mfns=4
(XEN) domctl.c:992:d0 memory_map:remove: gfn=f3440 mfn=fa940 nr_mfns=1
(XEN) domctl.c:992:d0 memory_map:remove: gfn=f3420 mfn=fa920 nr_mfns=20
(XEN) domctl.c:992:d0 memory_map:remove: gfn=f3200 mfn=fac00 nr_mfns=200
(XEN) domctl.c:982:d0 memory_map:add: gfn=f3444 mfn=fa944 nr_mfns=1
(XEN) domctl.c:992:d0 memory_map:remove: gfn=f3444 mfn=fa944 nr_mfns=4
(XEN) domctl.c:982:d0 memory_map:add: gfn=f3420 mfn=fa920 nr_mfns=20
(XEN) domctl.c:982:d0 memory_map:add: gfn=f3200 mfn=fac00 nr_mfns=200
(XEN) domctl.c:982:d0 memory_map:add: gfn=f3444 mfn=fa944 nr_mfns=4
(XEN) domctl.c:992:d0 memory_map:remove: gfn=f3444 mfn=fa944 nr_mfns=1
(XEN) domctl.c:992:d0 memory_map:remove: gfn=f3420 mfn=fa920 nr_mfns=20
(XEN) domctl.c:992:d0 memory_map:remove: gfn=f3200 mfn=fac00 nr_mfns=200
(XEN) domctl.c:982:d0 memory_map:add: gfn=f3444 mfn=fa944 nr_mfns=1
(XEN) domctl.c:992:d0 memory_map:remove: gfn=f3444 mfn=fa944 nr_mfns=4
(XEN) domctl.c:982:d0 memory_map:add: gfn=f3420 mfn=fa920 nr_mfns=20
(XEN) domctl.c:982:d0 memory_map:add: gfn=f3200 mfn=fac00 nr_mfns=200
(XEN) domctl.c:982:d0 memory_map:add: gfn=f3444 mfn=fa944 nr_mfns=4
(XEN) domctl.c:992:d0 memory_map:remove: gfn=f3444 mfn=fa944 nr_mfns=1
(XEN) domctl.c:1062:d0 ioport_map:remove f_gport=c120 f_mport=9880 np=20
(XEN) domctl.c:1038:d0 ioport_map:add f_gport=c120 f_mport=9880 np=20
(XEN) domctl.c:992:d0 memory_map:remove: gfn=f3420 mfn=fa920 nr_mfns=20
(XEN) domctl.c:992:d0 memory_map:remove: gfn=f3200 mfn=fac00 nr_mfns=200
(XEN) domctl.c:982:d0 memory_map:add: gfn=f3444 mfn=fa944 nr_mfns=1
(XEN) domctl.c:992:d0 memory_map:remove: gfn=f3444 mfn=fa944 nr_mfns=4
(XEN) domctl.c:982:d0 memory_map:add: gfn=f3420 mfn=fa920 nr_mfns=20
(XEN) domctl.c:982:d0 memory_map:add: gfn=f3200 mfn=fac00 nr_mfns=200
(XEN) domctl.c:982:d0 memory_map:add: gfn=f3444 mfn=fa944 nr_mfns=4
(XEN) domctl.c:992:d0 memory_map:remove: gfn=f3444 mfn=fa944 nr_mfns=1
(XEN) domctl.c:992:d0 memory_map:remove: gfn=f3420 mfn=fa920 nr_mfns=20
(XEN) domctl.c:992:d0 memory_map:remove: gfn=f3200 mfn=fac00 nr_mfns=200
(XEN) domctl.c:982:d0 memory_map:add: gfn=f3444 mfn=fa944 nr_mfns=1
(XEN) domctl.c:992:d0 memory_map:remove: gfn=f3444 mfn=fa944 nr_mfns=4
(XEN) domctl.c:982:d0 memory_map:add: gfn=f3420 mfn=fa920 nr_mfns=20
(XEN) domctl.c:982:d0 memory_map:add: gfn=f3200 mfn=fac00 nr_mfns=200
(XEN) domctl.c:982:d0 memory_map:add: gfn=f3444 mfn=fa944 nr_mfns=4
(XEN) domctl.c:992:d0 memory_map:remove: gfn=f3444 mfn=fa944 nr_mfns=1
(XEN) domctl.c:992:d0 memory_map:remove: gfn=f3420 mfn=fa920 nr_mfns=20
(XEN) domctl.c:992:d0 memory_map:remove: gfn=f3200 mfn=fac00 nr_mfns=200
(XEN) domctl.c:982:d0 memory_map:add: gfn=f3444 mfn=fa944 nr_mfns=1
(XEN) domctl.c:992:d0 memory_map:remove: gfn=f3444 mfn=fa944 nr_mfns=4
(XEN) domctl.c:982:d0 memory_map:add: gfn=f3420 mfn=fa920 nr_mfns=20
(XEN) domctl.c:982:d0 memory_map:add: gfn=f3200 mfn=fac00 nr_mfns=200
(XEN) domctl.c:982:d0 memory_map:add: gfn=f3444 mfn=fa944 nr_mfns=4
(XEN) domctl.c:992:d0 memory_map:remove: gfn=f3444 mfn=fa944 nr_mfns=1
(XEN) msi.c:867: MSI is already in use on device 0d:00.0
(XEN) msi.c:867: MSI is already in use on device 0d:00.0
(XEN) msi.c:867: MSI is already in use on device 0d:00.0
(XEN) msi.c:867: MSI is already in use on device 0d:00.0
(XEN) msi.c:867: MSI is already in use on device 0d:00.0
(XEN) msi.c:867: MSI is already in use on device 0d:00.1
(XEN) msi.c:867: MSI is already in use on device 0d:00.1
(XEN) msi.c:867: MSI is already in use on device 0d:00.1
(XEN) msi.c:867: MSI is already in use on device 0d:00.1
(XEN) msi.c:867: MSI is already in use on device 0d:00.1

Thanks!

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 14:33:24 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 14: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.xensource.com>)
	id 1RaptL-0008GN-Ey; Wed, 14 Dec 2011 14:33:07 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xieliwei@gmail.com>) id 1RaptJ-0008G1-0D
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 14:33:05 +0000
X-Env-Sender: xieliwei@gmail.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1323873091!46700932!1
X-Originating-IP: [209.85.213.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8735 invoked from network); 14 Dec 2011 14:31:32 -0000
Received: from mail-yw0-f43.google.com (HELO mail-yw0-f43.google.com)
	(209.85.213.43)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Dec 2011 14:31:32 -0000
Received: by yhr49 with SMTP id 49so25986552yhr.30
	for <xen-devel@lists.xensource.com>;
	Wed, 14 Dec 2011 06:32:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type;
	bh=UckpZW54hnxt2E4BpJgj8kIuoqU4/HrxOs70at+zCZ4=;
	b=FnlBOcDsVbZFgMiMet3smMrWJD5ZFbczrSeH4E8Wqvu7XZ0R2KnwOBZZzIzC/jxBcu
	WU+hgDA5X973Nfw69n/ni3qK5Cd5FtztER0DbZoIA4Ry2HNCVpu2VppIjJDCAHP/5vWM
	Dtql0U7cCB5zOpaXsl06vJd3WdBRiFzPSchK0=
Received: by 10.236.201.194 with SMTP id b42mr12576034yho.32.1323873131195;
	Wed, 14 Dec 2011 06:32:11 -0800 (PST)
MIME-Version: 1.0
Received: by 10.100.10.4 with HTTP; Wed, 14 Dec 2011 06:31:50 -0800 (PST)
In-Reply-To: <20111214125833.GA51060@ocelot.phlegethon.org>
References: <CAPE0SYwsqRKDuPTz66r0nTVPYcsFx0Dk2j0pWpCiHELuU5W2iA@mail.gmail.com>
	<4EE881270200007800067A65@nat28.tlf.novell.com>
	<20111214125833.GA51060@ocelot.phlegethon.org>
From: Liwei <xieliwei@gmail.com>
Date: Wed, 14 Dec 2011 22:31:50 +0800
Message-ID: <CAPE0SYzJLCjO_9Nt5v7jxuMvbv=DFbGGs41=XANRXujbhAW5Vw@mail.gmail.com>
To: Tim Deegan <tim@xen.org>, Ian.Campbell@citrix.com, keir@xen.org, 
	Jan Beulich <JBeulich@suse.com>
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] PTE Write access is not set
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hello all,
    My apologies for the unclear email. Here are the events in
chronological order:

======First instance of VM Crash======
Guest is openSuSE 11.4 on 2.6.37.6-0.5-desktop
No symptoms in guest logs, logging just stopped.
Looking at the serial logs, it appears that the guest just vapourised
(unless the "First re-creation of guest" below is actually the first
crash, though Jan and Tim mentioned that that crash couldn't have
occurred during run-time).
This VM has one part of the Intel 82575GB (0e:00.1) pass-throughed.

++++First re-creation of guest++++
xl create /etc/xen/vm-test4.cfg

----Xen log----
(XEN) HVM7: ata0-0: PCHS=16383/16/63 translation=lba LCHS=1024/255/63
(XEN) HVM7: ata0 master: QEMU HARDDISK ATA-7 Hard-Disk ( 160 GBytes)
(XEN) realmode.c:115:d7 Failed to emulate insn.
(XEN) realmode.c:165:d7 Real-mode emulation failed @ a8c0:00005a8e: ff
fa 00 15 99 2c
(XEN) domain_crash called from realmode.c:166
(XEN) Domain 7 (vcpu#0) crashed on cpu#3:
(XEN) ----[ Xen-4.1.3-rc1-pre  x86_64  debug=n  Not tainted ]----
(XEN) CPU:    3
(XEN) RIP:    a8c0:[<0000000000005a8e>]
(XEN) RFLAGS: 0000000000010006   CONTEXT: hvm guest
(XEN) rax: 0000000000000120   rbx: 0000000000000000   rcx: 00000000000dffff
(XEN) rdx: 00000000000001f7   rsi: 000000000000ffff   rdi: 000000000000fffe
(XEN) rbp: 0000000000000db5   rsp: 000000000000eff8   r8:  0000000000000000
(XEN) r9:  0000000000000000   r10: 0000000000000000   r11: 0000000000000000
(XEN) r12: 0000000000000000   r13: 0000000000000000   r14: 0000000000000000
(XEN) r15: 0000000000000000   cr0: 0000000000000010   cr4: 0000000000000000
(XEN) cr3: 0000000000000000   cr2: 0000000000000000
(XEN) ds: 9fc0   es: 9e00   fs: 0000   gs: 0000   ss: 9e00   cs: a8c0

++++Second re-creation of guest++++
xl create /etc/xen/vm-test4.cfg

(XEN) HVM8: ata0-0: PCHS=16383/16/63 translation=lba LCHS=1024/255/63
(XEN) HVM8: ata0 master: QEMU HARDDISK ATA-7 Hard-Disk ( 160 GBytes)
(XEN) realmode.c:115:d8 Failed to emulate insn.
(XEN) realmode.c:165:d8 Real-mode emulation failed @ a8c0:0000fcb5: 72
5c 1b 80 c4 82
(XEN) domain_crash called from realmode.c:166
(XEN) Domain 8 (vcpu#0) crashed on cpu#5:
(XEN) ----[ Xen-4.1.3-rc1-pre  x86_64  debug=n  Not tainted ]----
(XEN) CPU:    5
(XEN) RIP:    a8c0:[<000000000000fcb5>]
(XEN) RFLAGS: 0000000000010002   CONTEXT: hvm guest
(XEN) rax: 0000000000000000   rbx: 0000000000000000   rcx: 00000000000d0000
(XEN) rdx: 00000000000001f7   rsi: 0000000000000000   rdi: 0000000000000dba
(XEN) rbp: 0000000000000db8   rsp: 0000000000000d38   r8:  0000000000000000
(XEN) r9:  0000000000000000   r10: 0000000000000000   r11: 0000000000000000
(XEN) r12: 0000000000000000   r13: 0000000000000000   r14: 0000000000000000
(XEN) r15: 0000000000000000   cr0: 0000000000000010   cr4: 0000000000000000
(XEN) cr3: 0000000000000000   cr2: 0000000000000000
(XEN) ds: 9fc0   es: 9e00   fs: 0000   gs: 0000   ss: 9e00   cs: a8c0

[Did the same thing a few more times with similar results and gave up,
rebooted dom0 and all was well]


[About 20 hours later]
======Second instance of VM Crash======
Guest is pfSense 2.1 on FreeBSD 8.1-RELEASE-p6
Unfortunately, I didn't get the chance to extract the guest logs as
they're purged on boot.
Similarly, looking at the serial logs, it appears that the guest just
vapourised (unless the "First re-creation of guest" below is actually
the first crash, though Jan and Tim mentioned that that crash couldn't
have occurred during run-time).
This VM has two parts of the Intel 82575GB (0d:00.0 and 0d:00.1) pass-throughed.

++++First re-creation of guest++++
xl create /etc/xen/vm-pfsense.cfg

(XEN) HVM5: Booting from Hard Disk...
(XEN) HVM5: Booting from 0000:7c00
(XEN) realmode.c:115:d5 Failed to emulate insn.
(XEN) realmode.c:165:d5 Real-mode emulation failed @ c5d5:000242bc: d9
33 01 fc 30 34
(XEN) domain_crash called from realmode.c:166
(XEN) Domain 5 (vcpu#0) crashed on cpu#0:
(XEN) ----[ Xen-4.1.3-rc1-pre  x86_64  debug=n  Not tainted ]----
(XEN) CPU:    0
(XEN) RIP:    c5d5:[<00000000000242bc>]
(XEN) RFLAGS: 0000000000010013   CONTEXT: hvm guest
(XEN) rax: 000000000000001b   rbx: 0000000000000702   rcx: 0000000000010ba7
(XEN) rdx: 0000000000008fd5   rsi: 0000000000001333   rdi: 000000000000900e
(XEN) rbp: 000000000000703e   rsp: 000000000000c5cf   r8:  0000000000000000
(XEN) r9:  0000000000000000   r10: 0000000000000000   r11: 0000000000000000
(XEN) r12: 0000000000000000   r13: 0000000000000000   r14: 0000000000000000
(XEN) r15: 0000000000000000   cr0: 0000000000000010   cr4: 0000000000000000
(XEN) cr3: 0000000000000000   cr2: 0000000000000000
(XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: 0000   cs: c5d5
(XEN) [VT-D]iommu.c:856: iommu_fault_status: Primary Pending Fault
(XEN) [VT-D]iommu.c:831: DMAR:[DMA Write] Request device [0d:00.1]
fault addr d8964f44000, iommu reg = ffff82c3fff57000
(XEN) DMAR:[fault reason 05h] PTE Write access is not set
(XEN) print_vtd_entries: iommu = ffff83045ce565c0 bdf = d:0.1 gmfn = d8964f44
(XEN)     root_entry = ffff8304519d1000
(XEN)     root_entry[d] = 4127af001
(XEN)     context = ffff8304127af000
(XEN)     context[1] = 2_414aca001
(XEN)     l4 = ffff830414aca000
(XEN)     l4_index = 1b
(XEN)     l4[1b] = 0
(XEN)     l4[1b] not present

++++Second re-creation of guest++++
xl create /etc/xen/vm-pfsense.cfg

(XEN) HVM6: Options: apmbios pcibios eltorito PMM
(XEN) HVM6:
(XEN) realmode.c:115:d6 Failed to emulate insn.
(XEN) realmode.c:165:d6 Real-mode emulation failed @ a8c0:00005a83: 72
5c 1b 80 c4 82
(XEN) domain_crash called from realmode.c:166
(XEN) Domain 6 (vcpu#0) crashed on cpu#6:
(XEN) ----[ Xen-4.1.3-rc1-pre  x86_64  debug=n  Not tainted ]----
(XEN) CPU:    6
(XEN) RIP:    a8c0:[<0000000000005a83>]
(XEN) RFLAGS: 0000000000010086   CONTEXT: hvm guest
(XEN) rax: 0000000000000000   rbx: 0000000000000db4   rcx: 00000000000f0027
(XEN) rdx: 0000000000000004   rsi: 0000000000000006   rdi: 0000000000000db2
(XEN) rbp: 0000000000000dc8   rsp: 000000000000df33   r8:  0000000000000000
(XEN) r9:  0000000000000000   r10: 0000000000000000   r11: 0000000000000000
(XEN) r12: 0000000000000000   r13: 0000000000000000   r14: 0000000000000000
(XEN) r15: 0000000000000000   cr0: 0000000000000010   cr4: 0000000000000000
(XEN) cr3: 0000000000000000   cr2: 0000000000000000
(XEN) ds: 9fc0   es: c000   fs: 0000   gs: 0000   ss: 9e00   cs: a8c0
(XEN) [VT-D]iommu.c:856: iommu_fault_status: Primary Pending Fault
(XEN) [VT-D]iommu.c:831: DMAR:[DMA Write] Request device [0d:00.1]
fault addr 1a16ee8000000, iommu reg = ffff82c3fff57000
(XEN) DMAR:[fault reason 04h] Access beyond MGAW
(XEN) print_vtd_entries: iommu = ffff83045ce565c0 bdf = d:0.1 gmfn = 1a16ee8000
(XEN)     root_entry = ffff8304519d1000
(XEN)     root_entry[d] = 4127af001
(XEN)     context = ffff8304127af000
(XEN)     context[1] = 102_2159b1001
(XEN)     l4 = ffff8302159b1000
(XEN)     l4_index = 142
(XEN)     l4[142] = 0
(XEN)     l4[142] not present

[Did the same thing a few more times with similar results and gave up,
rebooted dom0 and all was well]

Typical log of a booting openSuSE guest:
(XEN) HVM2: HVM Loader
(XEN) HVM2: Detected Xen v4.1.3-rc1-pre
(XEN) HVM2: CPU speed is 2930 MHz
(XEN) HVM2: Xenbus rings @0xfeffc000, event channel 9
(XEN) irq.c:264: Dom2 PCI link 0 changed 0 -> 5
(XEN) HVM2: PCI-ISA link 0 routed to IRQ5
(XEN) irq.c:264: Dom2 PCI link 1 changed 0 -> 10
(XEN) HVM2: PCI-ISA link 1 routed to IRQ10
(XEN) irq.c:264: Dom2 PCI link 2 changed 0 -> 11
(XEN) HVM2: PCI-ISA link 2 routed to IRQ11
(XEN) irq.c:264: Dom2 PCI link 3 changed 0 -> 5
(XEN) HVM2: PCI-ISA link 3 routed to IRQ5
(XEN) HVM2: pci dev 01:2 INTD->IRQ5
(XEN) HVM2: pci dev 01:3 INTA->IRQ10
(XEN) HVM2: pci dev 03:0 INTA->IRQ5
(XEN) HVM2: pci dev 04:0 INTA->IRQ5
(XEN) HVM2: pci dev 05:0 INTB->IRQ11
(XEN) HVM2: pci dev 02:0 bar 10 size 02000000: f0000008
(XEN) HVM2: pci dev 03:0 bar 14 size 01000000: f2000008
(XEN) HVM2: pci dev 05:0 bar 14 size 00200000: f3000000
(XEN) domctl.c:982:d0 memory_map:add: gfn=f3000 mfn=fb400 nr_mfns=200
(XEN) domctl.c:982:d0 memory_map:add: gfn=f3200 mfn=fb620 nr_mfns=20
(XEN) HVM2: pci dev 05:0 bar 10 size 00020000: f3200000
(XEN) domctl.c:982:d0 memory_map:add: gfn=f3220 mfn=fb644 nr_mfns=4
(XEN) domctl.c:992:d0 memory_map:remove: gfn=f3220 mfn=fb644 nr_mfns=1
(XEN) HVM2: pci dev 05:0 bar 1c size 00004000: f3220000
(XEN) HVM2: pci dev 02:0 bar 14 size 00001000: f3224000
(XEN) HVM2: pci dev 04:0 bar 10 size 00000400: 0000c001
(XEN) HVM2: pci dev 03:0 bar 10 size 00000100: 0000c401
(XEN) HVM2: pci dev 04:0 bar 14 size 00000100: 0000c501
(XEN) HVM2: pci dev 01:2 bar 20 size 00000020: 0000c601
(XEN) HVM2: pci dev 05:0 bar 18 size 00000020: 0000c621
(XEN) domctl.c:1038:d0 ioport_map:add f_gport=c620 f_mport=a880 np=20
(XEN) HVM2: pci dev 01:1 bar 20 size 00000010: 0000c641
(XEN) HVM2: Multiprocessor initialisation:
(XEN) HVM2:  - CPU0 ... 36-bit phys ... fixed MTRRs ... var MTRRs
[2/8] ... done.
(XEN) HVM2:  - CPU1 ... 36-bit phys ... fixed MTRRs ... var MTRRs
[2/8] ... done.
(XEN) HVM2:  - CPU2 ... 36-bit phys ... fixed MTRRs ... var MTRRs
[2/8] ... done.
(XEN) HVM2:  - CPU3 ... 36-bit phys ... fixed MTRRs ... var MTRRs
[2/8] ... done.
(XEN) HVM2:  - CPU4 ... 36-bit phys ... fixed MTRRs ... var MTRRs
[2/8] ... done.
(XEN) HVM2:  - CPU5 ... 36-bit phys ... fixed MTRRs ... var MTRRs
[2/8] ... done.
(XEN) HVM2:  - CPU6 ... 36-bit phys ... fixed MTRRs ... var MTRRs
[2/8] ... done.
(XEN) HVM2:  - CPU7 ... 36-bit phys ... fixed MTRRs ... var MTRRs
[2/8] ... done.
(XEN) HVM2: Writing SMBIOS tables ...
(XEN) HVM2: Loading ROMBIOS ...
(XEN) HVM2: 12604 bytes of ROMBIOS high-memory extensions:
(XEN) HVM2:   Relocating to 0xfc000000-0xfc00313c ... done
(XEN) HVM2: Creating MP tables ...
(XEN) HVM2: Loading Cirrus VGABIOS ...
(XEN) HVM2: Loading ACPI ...
(XEN) HVM2:  - Lo data: 000ea020-000ea04f
(XEN) HVM2:  - Hi data: fc003400-fc01355f
(XEN) HVM2: vm86 TSS at fc013800
(XEN) HVM2: BIOS map:
(XEN) HVM2:  c0000-c8fff: VGA BIOS
(XEN) HVM2:  eb000-eb26b: SMBIOS tables
(XEN) HVM2:  f0000-fffff: Main BIOS
(XEN) HVM2: E820 table:
(XEN) HVM2:  [00]: 00000000:00000000 - 00000000:0009e000: RAM
(XEN) HVM2:  [01]: 00000000:0009e000 - 00000000:0009fc00: RESERVED
(XEN) HVM2:  [02]: 00000000:0009fc00 - 00000000:000a0000: RESERVED
(XEN) HVM2:  HOLE: 00000000:000a0000 - 00000000:000e0000
(XEN) HVM2:  [03]: 00000000:000e0000 - 00000000:00100000: RESERVED
(XEN) HVM2:  [04]: 00000000:00100000 - 00000000:7f800000: RAM
(XEN) HVM2:  HOLE: 00000000:7f800000 - 00000000:fc000000
(XEN) HVM2:  [05]: 00000000:fc000000 - 00000001:00000000: RESERVED
(XEN) HVM2: Invoking ROMBIOS ...
(XEN) HVM2: $Revision: 1.221 $ $Date: 2008/12/07 17:32:29 $
(XEN) stdvga.c:147:d2 entering stdvga and caching modes
(XEN) HVM2: VGABios $Id: vgabios.c,v 1.67 2008/01/27 09:44:12 vruppert Exp $
(XEN) HVM2: Bochs BIOS - build: 06/23/99
(XEN) HVM2: $Revision: 1.221 $ $Date: 2008/12/07 17:32:29 $
(XEN) HVM2: Options: apmbios pcibios eltorito PMM
(XEN) HVM2:
(XEN) HVM2: ata0-0: PCHS=16383/16/63 translation=lba LCHS=1024/255/63
(XEN) HVM2: ata0 master: QEMU HARDDISK ATA-7 Hard-Disk ( 160 GBytes)
(XEN) HVM2: IDE time out
(XEN) HVM2:
(XEN) HVM2:
(XEN) HVM2:
(XEN) HVM2: Press F12 for boot menu.
(XEN) HVM2:
(XEN) HVM2: Booting from Hard Disk...
(XEN) HVM2: Booting from 0000:7c00
(XEN) HVM2: int13_harddisk: function 41, unmapped device for ELDL=81
(XEN) HVM2: int13_harddisk: function 08, unmapped device for ELDL=81
(XEN) HVM2: *** int 15h function AX=00c0, BX=0000 not yet supported!
(XEN) stdvga.c:151:d2 leaving stdvga
(XEN) stdvga.c:147:d2 entering stdvga and caching modes
(XEN) HVM2: *** int 15h function AX=ec00, BX=0002 not yet supported!
(XEN) HVM2: KBD: unsupported int 16h function 03
(XEN) HVM2: *** int 15h function AX=e980, BX=0000 not yet supported!
(XEN) HVM2: int13_harddisk: function 41, unmapped device for ELDL=81
(XEN) HVM2: int13_harddisk: function 02, unmapped device for ELDL=81
(XEN) HVM2: int13_harddisk: function 41, unmapped device for ELDL=82
(XEN) HVM2: int13_harddisk: function 02, unmapped device for ELDL=82
(XEN) HVM2: int13_harddisk: function 41, unmapped device for ELDL=83
(XEN) HVM2: int13_harddisk: function 02, unmapped device for ELDL=83
(XEN) HVM2: int13_harddisk: function 41, unmapped device for ELDL=84
(XEN) HVM2: int13_harddisk: function 02, unmapped device for ELDL=84
(XEN) HVM2: int13_harddisk: function 41, unmapped device for ELDL=85
(XEN) HVM2: int13_harddisk: function 02, unmapped device for ELDL=85
(XEN) HVM2: int13_harddisk: function 41, unmapped device for ELDL=86
(XEN) HVM2: int13_harddisk: function 02, unmapped device for ELDL=86
(XEN) HVM2: int13_harddisk: function 41, unmapped device for ELDL=87
(XEN) HVM2: int13_harddisk: function 02, unmapped device for ELDL=87
(XEN) HVM2: int13_harddisk: function 41, ELDL out of range 88
(XEN) HVM2: int13_harddisk: function 02, ELDL out of range 88
(XEN) HVM2: int13_harddisk: function 41, ELDL out of range 89
(XEN) HVM2: int13_harddisk: function 02, ELDL out of range 89
(XEN) HVM2: int13_harddisk: function 41, ELDL out of range 8a
(XEN) HVM2: int13_harddisk: function 02, ELDL out of range 8a
(XEN) HVM2: int13_harddisk: function 41, ELDL out of range 8b
(XEN) HVM2: int13_harddisk: function 02, ELDL out of range 8b
(XEN) HVM2: int13_harddisk: function 41, ELDL out of range 8c
(XEN) HVM2: int13_harddisk: function 02, ELDL out of range 8c
(XEN) HVM2: int13_harddisk: function 41, ELDL out of range 8d
(XEN) HVM2: int13_harddisk: function 02, ELDL out of range 8d
(XEN) HVM2: int13_harddisk: function 41, ELDL out of range 8e
(XEN) HVM2: int13_harddisk: function 02, ELDL out of range 8e
(XEN) HVM2: int13_harddisk: function 41, ELDL out of range 8f
(XEN) HVM2: int13_harddisk: function 02, ELDL out of range 8f
(XEN) stdvga.c:151:d2 leaving stdvga
(XEN) domctl.c:992:d0 memory_map:remove: gfn=f3200 mfn=fb620 nr_mfns=20
(XEN) domctl.c:992:d0 memory_map:remove: gfn=f3000 mfn=fb400 nr_mfns=200
(XEN) domctl.c:1062:d0 ioport_map:remove f_gport=c620 f_mport=a880 np=20
(XEN) domctl.c:982:d0 memory_map:add: gfn=f3220 mfn=fb644 nr_mfns=1
(XEN) domctl.c:992:d0 memory_map:remove: gfn=f3220 mfn=fb644 nr_mfns=4
(XEN) domctl.c:982:d0 memory_map:add: gfn=f3200 mfn=fb620 nr_mfns=20
(XEN) domctl.c:982:d0 memory_map:add: gfn=f3000 mfn=fb400 nr_mfns=200
(XEN) domctl.c:1038:d0 ioport_map:add f_gport=c620 f_mport=a880 np=20
(XEN) domctl.c:982:d0 memory_map:add: gfn=f3220 mfn=fb644 nr_mfns=4
(XEN) domctl.c:992:d0 memory_map:remove: gfn=f3220 mfn=fb644 nr_mfns=1
(XEN) domctl.c:992:d0 memory_map:remove: gfn=f3200 mfn=fb620 nr_mfns=20
(XEN) domctl.c:992:d0 memory_map:remove: gfn=f3000 mfn=fb400 nr_mfns=200
(XEN) domctl.c:1062:d0 ioport_map:remove f_gport=c620 f_mport=a880 np=20
(XEN) domctl.c:982:d0 memory_map:add: gfn=f3220 mfn=fb644 nr_mfns=1
(XEN) domctl.c:992:d0 memory_map:remove: gfn=f3220 mfn=fb644 nr_mfns=4
(XEN) domctl.c:982:d0 memory_map:add: gfn=f3200 mfn=fb620 nr_mfns=20
(XEN) domctl.c:982:d0 memory_map:add: gfn=f3000 mfn=fb400 nr_mfns=200
(XEN) domctl.c:1038:d0 ioport_map:add f_gport=c620 f_mport=a880 np=20
(XEN) domctl.c:982:d0 memory_map:add: gfn=f3220 mfn=fb644 nr_mfns=4
(XEN) domctl.c:992:d0 memory_map:remove: gfn=f3220 mfn=fb644 nr_mfns=1
(XEN) domctl.c:992:d0 memory_map:remove: gfn=f3200 mfn=fb620 nr_mfns=20
(XEN) domctl.c:992:d0 memory_map:remove: gfn=f3000 mfn=fb400 nr_mfns=200
(XEN) domctl.c:1062:d0 ioport_map:remove f_gport=c620 f_mport=a880 np=20
(XEN) domctl.c:982:d0 memory_map:add: gfn=f3220 mfn=fb644 nr_mfns=1
(XEN) domctl.c:992:d0 memory_map:remove: gfn=f3220 mfn=fb644 nr_mfns=4
(XEN) domctl.c:982:d0 memory_map:add: gfn=f3200 mfn=fb620 nr_mfns=20
(XEN) domctl.c:982:d0 memory_map:add: gfn=f3000 mfn=fb400 nr_mfns=200
(XEN) domctl.c:1038:d0 ioport_map:add f_gport=c620 f_mport=a880 np=20
(XEN) domctl.c:982:d0 memory_map:add: gfn=f3220 mfn=fb644 nr_mfns=4
(XEN) domctl.c:992:d0 memory_map:remove: gfn=f3220 mfn=fb644 nr_mfns=1
(XEN) domctl.c:992:d0 memory_map:remove: gfn=f3200 mfn=fb620 nr_mfns=20
(XEN) domctl.c:992:d0 memory_map:remove: gfn=f3000 mfn=fb400 nr_mfns=200
(XEN) domctl.c:1062:d0 ioport_map:remove f_gport=c620 f_mport=a880 np=20
(XEN) domctl.c:982:d0 memory_map:add: gfn=f3220 mfn=fb644 nr_mfns=1
(XEN) domctl.c:992:d0 memory_map:remove: gfn=f3220 mfn=fb644 nr_mfns=4
(XEN) domctl.c:982:d0 memory_map:add: gfn=f3200 mfn=fb620 nr_mfns=20
(XEN) domctl.c:982:d0 memory_map:add: gfn=f3000 mfn=fb400 nr_mfns=200
(XEN) domctl.c:1038:d0 ioport_map:add f_gport=c620 f_mport=a880 np=20
(XEN) domctl.c:982:d0 memory_map:add: gfn=f3220 mfn=fb644 nr_mfns=4
(XEN) domctl.c:992:d0 memory_map:remove: gfn=f3220 mfn=fb644 nr_mfns=1
(XEN) domctl.c:992:d0 memory_map:remove: gfn=f3200 mfn=fb620 nr_mfns=20
(XEN) domctl.c:992:d0 memory_map:remove: gfn=f3000 mfn=fb400 nr_mfns=200
(XEN) domctl.c:1062:d0 ioport_map:remove f_gport=c620 f_mport=a880 np=20
(XEN) domctl.c:982:d0 memory_map:add: gfn=f3220 mfn=fb644 nr_mfns=1
(XEN) domctl.c:992:d0 memory_map:remove: gfn=f3220 mfn=fb644 nr_mfns=4
(XEN) domctl.c:982:d0 memory_map:add: gfn=f3200 mfn=fb620 nr_mfns=20
(XEN) domctl.c:982:d0 memory_map:add: gfn=f3000 mfn=fb400 nr_mfns=200
(XEN) domctl.c:1038:d0 ioport_map:add f_gport=c620 f_mport=a880 np=20
(XEN) domctl.c:982:d0 memory_map:add: gfn=f3220 mfn=fb644 nr_mfns=4
(XEN) domctl.c:992:d0 memory_map:remove: gfn=f3220 mfn=fb644 nr_mfns=1
(XEN) domctl.c:992:d0 memory_map:remove: gfn=f3200 mfn=fb620 nr_mfns=20
(XEN) domctl.c:992:d0 memory_map:remove: gfn=f3000 mfn=fb400 nr_mfns=200
(XEN) domctl.c:1062:d0 ioport_map:remove f_gport=c620 f_mport=a880 np=20
(XEN) domctl.c:982:d0 memory_map:add: gfn=f3220 mfn=fb644 nr_mfns=1
(XEN) domctl.c:992:d0 memory_map:remove: gfn=f3220 mfn=fb644 nr_mfns=4
(XEN) domctl.c:982:d0 memory_map:add: gfn=f3200 mfn=fb620 nr_mfns=20
(XEN) domctl.c:982:d0 memory_map:add: gfn=f3000 mfn=fb400 nr_mfns=200
(XEN) domctl.c:1038:d0 ioport_map:add f_gport=c620 f_mport=a880 np=20
(XEN) domctl.c:982:d0 memory_map:add: gfn=f3220 mfn=fb644 nr_mfns=4
(XEN) domctl.c:992:d0 memory_map:remove: gfn=f3220 mfn=fb644 nr_mfns=1
(XEN) domctl.c:992:d0 memory_map:remove: gfn=f3200 mfn=fb620 nr_mfns=20
(XEN) domctl.c:992:d0 memory_map:remove: gfn=f3000 mfn=fb400 nr_mfns=200
(XEN) domctl.c:1062:d0 ioport_map:remove f_gport=c620 f_mport=a880 np=20
(XEN) domctl.c:982:d0 memory_map:add: gfn=f3220 mfn=fb644 nr_mfns=1
(XEN) domctl.c:992:d0 memory_map:remove: gfn=f3220 mfn=fb644 nr_mfns=4
(XEN) domctl.c:982:d0 memory_map:add: gfn=f3200 mfn=fb620 nr_mfns=20
(XEN) domctl.c:982:d0 memory_map:add: gfn=f3000 mfn=fb400 nr_mfns=200
(XEN) domctl.c:1038:d0 ioport_map:add f_gport=c620 f_mport=a880 np=20
(XEN) domctl.c:982:d0 memory_map:add: gfn=f3220 mfn=fb644 nr_mfns=4
(XEN) domctl.c:992:d0 memory_map:remove: gfn=f3220 mfn=fb644 nr_mfns=1
(XEN) irq.c:264: Dom2 PCI link 0 changed 5 -> 0
(XEN) irq.c:264: Dom2 PCI link 1 changed 10 -> 0
(XEN) irq.c:264: Dom2 PCI link 2 changed 11 -> 0
(XEN) irq.c:264: Dom2 PCI link 3 changed 5 -> 0
(XEN) irq.c:330: Dom2 callback via changed to PCI INTx Dev 0x03 IntA
(XEN) msi.c:867: MSI is already in use on device 0e:00.1
(XEN) msi.c:867: MSI is already in use on device 0e:00.1
(XEN) msi.c:867: MSI is already in use on device 0e:00.1
(XEN) msi.c:867: MSI is already in use on device 0e:00.1
(XEN) msi.c:867: MSI is already in use on device 0e:00.1
(XEN) msi.c:867: MSI is already in use on device 0e:00.1
(XEN) msi.c:867: MSI is already in use on device 0e:00.1
(XEN) msi.c:867: MSI is already in use on device 0e:00.1
(XEN) msi.c:867: MSI is already in use on device 0e:00.1
(XEN) physdev.c:170: dom3: 16:-1 already mapped to 16
(XEN) physdev.c:170: dom3: 19:-1 already mapped to 20

Typical log of a booting pfSense guest:
(XEN) HVM1: HVM Loader
(XEN) HVM1: Detected Xen v4.1.3-rc1-pre
(XEN) HVM1: CPU speed is 2930 MHz
(XEN) HVM1: Xenbus rings @0xfeffc000, event channel 9
(XEN) irq.c:264: Dom1 PCI link 0 changed 0 -> 5
(XEN) HVM1: PCI-ISA link 0 routed to IRQ5
(XEN) irq.c:264: Dom1 PCI link 1 changed 0 -> 10
(XEN) HVM1: PCI-ISA link 1 routed to IRQ10
(XEN) irq.c:264: Dom1 PCI link 2 changed 0 -> 11
(XEN) HVM1: PCI-ISA link 2 routed to IRQ11
(XEN) irq.c:264: Dom1 PCI link 3 changed 0 -> 5
(XEN) HVM1: PCI-ISA link 3 routed to IRQ5
(XEN) HVM1: pci dev 01:3 INTA->IRQ10
(XEN) HVM1: pci dev 03:0 INTA->IRQ5
(XEN) HVM1: pci dev 04:0 INTA->IRQ5
(XEN) HVM1: pci dev 05:0 INTB->IRQ11
(XEN) HVM1: pci dev 02:0 bar 10 size 02000000: f0000008
(XEN) HVM1: pci dev 03:0 bar 14 size 01000000: f2000008
(XEN) HVM1: pci dev 04:0 bar 14 size 00200000: f3000000
(XEN) domctl.c:982:d0 memory_map:add: gfn=f3000 mfn=faa00 nr_mfns=200
(XEN) HVM1: pci dev 05:0 bar 14 size 00200000: f3200000
(XEN) domctl.c:982:d0 memory_map:add: gfn=f3200 mfn=fac00 nr_mfns=200
(XEN) domctl.c:982:d0 memory_map:add: gfn=f3400 mfn=fa900 nr_mfns=20
(XEN) HVM1: pci dev 04:0 bar 10 size 00020000: f3400000
(XEN) domctl.c:982:d0 memory_map:add: gfn=f3420 mfn=fa920 nr_mfns=20
(XEN) HVM1: pci dev 05:0 bar 10 size 00020000: f3420000
(XEN) domctl.c:982:d0 memory_map:add: gfn=f3440 mfn=fa940 nr_mfns=4
(XEN) domctl.c:992:d0 memory_map:remove: gfn=f3440 mfn=fa940 nr_mfns=1
(XEN) HVM1: pci dev 04:0 bar 1c size 00004000: f3440000
(XEN) domctl.c:982:d0 memory_map:add: gfn=f3444 mfn=fa944 nr_mfns=4
(XEN) domctl.c:992:d0 memory_map:remove: gfn=f3444 mfn=fa944 nr_mfns=1
(XEN) HVM1: pci dev 05:0 bar 1c size 00004000: f3444000
(XEN) HVM1: pci dev 02:0 bar 14 size 00001000: f3448000
(XEN) HVM1: pci dev 03:0 bar 10 size 00000100: 0000c001
(XEN) HVM1: pci dev 04:0 bar 18 size 00000020: 0000c101
(XEN) domctl.c:1038:d0 ioport_map:add f_gport=c100 f_mport=9c00 np=20
(XEN) HVM1: pci dev 05:0 bar 18 size 00000020: 0000c121
(XEN) domctl.c:1038:d0 ioport_map:add f_gport=c120 f_mport=9880 np=20
(XEN) HVM1: pci dev 01:1 bar 20 size 00000010: 0000c141
(XEN) HVM1: Multiprocessor initialisation:
(XEN) HVM1:  - CPU0 ... 36-bit phys ... fixed MTRRs ... var MTRRs
[2/8] ... done.
(XEN) HVM1:  - CPU1 ... 36-bit phys ... fixed MTRRs ... var MTRRs
[2/8] ... done.
(XEN) HVM1:  - CPU2 ... 36-bit phys ... fixed MTRRs ... var MTRRs
[2/8] ... done.
(XEN) HVM1:  - CPU3 ... 36-bit phys ... fixed MTRRs ... var MTRRs
[2/8] ... done.
(XEN) HVM1:  - CPU4 ... 36-bit phys ... fixed MTRRs ... var MTRRs
[2/8] ... done.
(XEN) HVM1:  - CPU5 ... 36-bit phys ... fixed MTRRs ... var MTRRs
[2/8] ... done.
(XEN) HVM1:  - CPU6 ... 36-bit phys ... fixed MTRRs ... var MTRRs
[2/8] ... done.
(XEN) HVM1:  - CPU7 ... 36-bit phys ... fixed MTRRs ... var MTRRs
[2/8] ... done.
(XEN) HVM1: Writing SMBIOS tables ...
(XEN) HVM1: Loading ROMBIOS ...
(XEN) HVM1: 12604 bytes of ROMBIOS high-memory extensions:
(XEN) HVM1:   Relocating to 0xfc000000-0xfc00313c ... done
(XEN) HVM1: Creating MP tables ...
(XEN) HVM1: Loading Cirrus VGABIOS ...
(XEN) HVM1: Loading ACPI ...
(XEN) HVM1:  - Lo data: 000ea020-000ea04f
(XEN) HVM1:  - Hi data: fc003400-fc01355f
(XEN) HVM1: vm86 TSS at fc013800
(XEN) HVM1: BIOS map:
(XEN) HVM1:  c0000-c8fff: VGA BIOS
(XEN) HVM1:  eb000-eb26b: SMBIOS tables
(XEN) HVM1:  f0000-fffff: Main BIOS
(XEN) HVM1: E820 table:
(XEN) HVM1:  [00]: 00000000:00000000 - 00000000:0009e000: RAM
(XEN) HVM1:  [01]: 00000000:0009e000 - 00000000:0009fc00: RESERVED
(XEN) HVM1:  [02]: 00000000:0009fc00 - 00000000:000a0000: RESERVED
(XEN) HVM1:  HOLE: 00000000:000a0000 - 00000000:000e0000
(XEN) HVM1:  [03]: 00000000:000e0000 - 00000000:00100000: RESERVED
(XEN) HVM1:  [04]: 00000000:00100000 - 00000000:3f800000: RAM
(XEN) HVM1:  HOLE: 00000000:3f800000 - 00000000:fc000000
(XEN) HVM1:  [05]: 00000000:fc000000 - 00000001:00000000: RESERVED
(XEN) HVM1: Invoking ROMBIOS ...
(XEN) HVM1: $Revision: 1.221 $ $Date: 2008/12/07 17:32:29 $
(XEN) stdvga.c:147:d1 entering stdvga and caching modes
(XEN) HVM1: VGABios $Id: vgabios.c,v 1.67 2008/01/27 09:44:12 vruppert Exp $
(XEN) HVM1: Bochs BIOS - build: 06/23/99
(XEN) HVM1: $Revision: 1.221 $ $Date: 2008/12/07 17:32:29 $
(XEN) HVM1: Options: apmbios pcibios eltorito PMM
(XEN) HVM1:
(XEN) HVM1: ata0 master: QEMU DVD-ROM ATAPI-4 CD-Rom/DVD-Rom
(XEN) HVM1: ata0-1: PCHS=16383/16/63 translation=lba LCHS=1024/255/63
(XEN) HVM1: ata0  slave: QEMU HARDDISK ATA-7 Hard-Disk (16384 MBytes)
(XEN) HVM1:
(XEN) HVM1:
(XEN) HVM1:
(XEN) HVM1: Press F12 for boot menu.
(XEN) HVM1:
(XEN) HVM1: Booting from Hard Disk...
(XEN) HVM1: Booting from 0000:7c00
(XEN) irq.c:264: Dom1 PCI link 0 changed 5 -> 0
(XEN) irq.c:264: Dom1 PCI link 1 changed 10 -> 0
(XEN) irq.c:264: Dom1 PCI link 2 changed 11 -> 0
(XEN) irq.c:264: Dom1 PCI link 3 changed 5 -> 0
(XEN) domctl.c:992:d0 memory_map:remove: gfn=f3400 mfn=fa900 nr_mfns=20
(XEN) domctl.c:992:d0 memory_map:remove: gfn=f3000 mfn=faa00 nr_mfns=200
(XEN) domctl.c:982:d0 memory_map:add: gfn=f3440 mfn=fa940 nr_mfns=1
(XEN) domctl.c:992:d0 memory_map:remove: gfn=f3440 mfn=fa940 nr_mfns=4
(XEN) domctl.c:982:d0 memory_map:add: gfn=f3400 mfn=fa900 nr_mfns=20
(XEN) domctl.c:982:d0 memory_map:add: gfn=f3000 mfn=faa00 nr_mfns=200
(XEN) domctl.c:982:d0 memory_map:add: gfn=f3440 mfn=fa940 nr_mfns=4
(XEN) domctl.c:992:d0 memory_map:remove: gfn=f3440 mfn=fa940 nr_mfns=1
(XEN) domctl.c:992:d0 memory_map:remove: gfn=f3400 mfn=fa900 nr_mfns=20
(XEN) domctl.c:992:d0 memory_map:remove: gfn=f3000 mfn=faa00 nr_mfns=200
(XEN) domctl.c:982:d0 memory_map:add: gfn=f3440 mfn=fa940 nr_mfns=1
(XEN) domctl.c:992:d0 memory_map:remove: gfn=f3440 mfn=fa940 nr_mfns=4
(XEN) domctl.c:982:d0 memory_map:add: gfn=f3400 mfn=fa900 nr_mfns=20
(XEN) domctl.c:982:d0 memory_map:add: gfn=f3000 mfn=faa00 nr_mfns=200
(XEN) domctl.c:982:d0 memory_map:add: gfn=f3440 mfn=fa940 nr_mfns=4
(XEN) domctl.c:992:d0 memory_map:remove: gfn=f3440 mfn=fa940 nr_mfns=1
(XEN) domctl.c:1062:d0 ioport_map:remove f_gport=c100 f_mport=9c00 np=20
(XEN) domctl.c:1038:d0 ioport_map:add f_gport=c100 f_mport=9c00 np=20
(XEN) domctl.c:992:d0 memory_map:remove: gfn=f3400 mfn=fa900 nr_mfns=20
(XEN) domctl.c:992:d0 memory_map:remove: gfn=f3000 mfn=faa00 nr_mfns=200
(XEN) domctl.c:982:d0 memory_map:add: gfn=f3440 mfn=fa940 nr_mfns=1
(XEN) domctl.c:992:d0 memory_map:remove: gfn=f3440 mfn=fa940 nr_mfns=4
(XEN) domctl.c:982:d0 memory_map:add: gfn=f3400 mfn=fa900 nr_mfns=20
(XEN) domctl.c:982:d0 memory_map:add: gfn=f3000 mfn=faa00 nr_mfns=200
(XEN) domctl.c:982:d0 memory_map:add: gfn=f3440 mfn=fa940 nr_mfns=4
(XEN) domctl.c:992:d0 memory_map:remove: gfn=f3440 mfn=fa940 nr_mfns=1
(XEN) domctl.c:992:d0 memory_map:remove: gfn=f3400 mfn=fa900 nr_mfns=20
(XEN) domctl.c:992:d0 memory_map:remove: gfn=f3000 mfn=faa00 nr_mfns=200
(XEN) domctl.c:982:d0 memory_map:add: gfn=f3440 mfn=fa940 nr_mfns=1
(XEN) domctl.c:992:d0 memory_map:remove: gfn=f3440 mfn=fa940 nr_mfns=4
(XEN) domctl.c:982:d0 memory_map:add: gfn=f3400 mfn=fa900 nr_mfns=20
(XEN) domctl.c:982:d0 memory_map:add: gfn=f3000 mfn=faa00 nr_mfns=200
(XEN) domctl.c:982:d0 memory_map:add: gfn=f3440 mfn=fa940 nr_mfns=4
(XEN) domctl.c:992:d0 memory_map:remove: gfn=f3440 mfn=fa940 nr_mfns=1
(XEN) domctl.c:992:d0 memory_map:remove: gfn=f3400 mfn=fa900 nr_mfns=20
(XEN) domctl.c:992:d0 memory_map:remove: gfn=f3000 mfn=faa00 nr_mfns=200
(XEN) domctl.c:982:d0 memory_map:add: gfn=f3440 mfn=fa940 nr_mfns=1
(XEN) domctl.c:992:d0 memory_map:remove: gfn=f3440 mfn=fa940 nr_mfns=4
(XEN) domctl.c:982:d0 memory_map:add: gfn=f3400 mfn=fa900 nr_mfns=20
(XEN) domctl.c:982:d0 memory_map:add: gfn=f3000 mfn=faa00 nr_mfns=200
(XEN) domctl.c:982:d0 memory_map:add: gfn=f3440 mfn=fa940 nr_mfns=4
(XEN) domctl.c:992:d0 memory_map:remove: gfn=f3440 mfn=fa940 nr_mfns=1
(XEN) domctl.c:992:d0 memory_map:remove: gfn=f3420 mfn=fa920 nr_mfns=20
(XEN) domctl.c:992:d0 memory_map:remove: gfn=f3200 mfn=fac00 nr_mfns=200
(XEN) domctl.c:982:d0 memory_map:add: gfn=f3444 mfn=fa944 nr_mfns=1
(XEN) domctl.c:992:d0 memory_map:remove: gfn=f3444 mfn=fa944 nr_mfns=4
(XEN) domctl.c:982:d0 memory_map:add: gfn=f3420 mfn=fa920 nr_mfns=20
(XEN) domctl.c:982:d0 memory_map:add: gfn=f3200 mfn=fac00 nr_mfns=200
(XEN) domctl.c:982:d0 memory_map:add: gfn=f3444 mfn=fa944 nr_mfns=4
(XEN) domctl.c:992:d0 memory_map:remove: gfn=f3444 mfn=fa944 nr_mfns=1
(XEN) domctl.c:992:d0 memory_map:remove: gfn=f3420 mfn=fa920 nr_mfns=20
(XEN) domctl.c:992:d0 memory_map:remove: gfn=f3200 mfn=fac00 nr_mfns=200
(XEN) domctl.c:982:d0 memory_map:add: gfn=f3444 mfn=fa944 nr_mfns=1
(XEN) domctl.c:992:d0 memory_map:remove: gfn=f3444 mfn=fa944 nr_mfns=4
(XEN) domctl.c:982:d0 memory_map:add: gfn=f3420 mfn=fa920 nr_mfns=20
(XEN) domctl.c:982:d0 memory_map:add: gfn=f3200 mfn=fac00 nr_mfns=200
(XEN) domctl.c:982:d0 memory_map:add: gfn=f3444 mfn=fa944 nr_mfns=4
(XEN) domctl.c:992:d0 memory_map:remove: gfn=f3444 mfn=fa944 nr_mfns=1
(XEN) domctl.c:1062:d0 ioport_map:remove f_gport=c120 f_mport=9880 np=20
(XEN) domctl.c:1038:d0 ioport_map:add f_gport=c120 f_mport=9880 np=20
(XEN) domctl.c:992:d0 memory_map:remove: gfn=f3420 mfn=fa920 nr_mfns=20
(XEN) domctl.c:992:d0 memory_map:remove: gfn=f3200 mfn=fac00 nr_mfns=200
(XEN) domctl.c:982:d0 memory_map:add: gfn=f3444 mfn=fa944 nr_mfns=1
(XEN) domctl.c:992:d0 memory_map:remove: gfn=f3444 mfn=fa944 nr_mfns=4
(XEN) domctl.c:982:d0 memory_map:add: gfn=f3420 mfn=fa920 nr_mfns=20
(XEN) domctl.c:982:d0 memory_map:add: gfn=f3200 mfn=fac00 nr_mfns=200
(XEN) domctl.c:982:d0 memory_map:add: gfn=f3444 mfn=fa944 nr_mfns=4
(XEN) domctl.c:992:d0 memory_map:remove: gfn=f3444 mfn=fa944 nr_mfns=1
(XEN) domctl.c:992:d0 memory_map:remove: gfn=f3420 mfn=fa920 nr_mfns=20
(XEN) domctl.c:992:d0 memory_map:remove: gfn=f3200 mfn=fac00 nr_mfns=200
(XEN) domctl.c:982:d0 memory_map:add: gfn=f3444 mfn=fa944 nr_mfns=1
(XEN) domctl.c:992:d0 memory_map:remove: gfn=f3444 mfn=fa944 nr_mfns=4
(XEN) domctl.c:982:d0 memory_map:add: gfn=f3420 mfn=fa920 nr_mfns=20
(XEN) domctl.c:982:d0 memory_map:add: gfn=f3200 mfn=fac00 nr_mfns=200
(XEN) domctl.c:982:d0 memory_map:add: gfn=f3444 mfn=fa944 nr_mfns=4
(XEN) domctl.c:992:d0 memory_map:remove: gfn=f3444 mfn=fa944 nr_mfns=1
(XEN) domctl.c:992:d0 memory_map:remove: gfn=f3420 mfn=fa920 nr_mfns=20
(XEN) domctl.c:992:d0 memory_map:remove: gfn=f3200 mfn=fac00 nr_mfns=200
(XEN) domctl.c:982:d0 memory_map:add: gfn=f3444 mfn=fa944 nr_mfns=1
(XEN) domctl.c:992:d0 memory_map:remove: gfn=f3444 mfn=fa944 nr_mfns=4
(XEN) domctl.c:982:d0 memory_map:add: gfn=f3420 mfn=fa920 nr_mfns=20
(XEN) domctl.c:982:d0 memory_map:add: gfn=f3200 mfn=fac00 nr_mfns=200
(XEN) domctl.c:982:d0 memory_map:add: gfn=f3444 mfn=fa944 nr_mfns=4
(XEN) domctl.c:992:d0 memory_map:remove: gfn=f3444 mfn=fa944 nr_mfns=1
(XEN) msi.c:867: MSI is already in use on device 0d:00.0
(XEN) msi.c:867: MSI is already in use on device 0d:00.0
(XEN) msi.c:867: MSI is already in use on device 0d:00.0
(XEN) msi.c:867: MSI is already in use on device 0d:00.0
(XEN) msi.c:867: MSI is already in use on device 0d:00.0
(XEN) msi.c:867: MSI is already in use on device 0d:00.1
(XEN) msi.c:867: MSI is already in use on device 0d:00.1
(XEN) msi.c:867: MSI is already in use on device 0d:00.1
(XEN) msi.c:867: MSI is already in use on device 0d:00.1
(XEN) msi.c:867: MSI is already in use on device 0d:00.1

Thanks!

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 14:47:27 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 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.xensource.com>)
	id 1Raq6t-0000LE-Df; Wed, 14 Dec 2011 14:47:07 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1Raq6r-0000L7-WD
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 14:47:06 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1323873950!52165047!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDYyMDY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1074 invoked from network); 14 Dec 2011 14:45:52 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Dec 2011 14:45:52 -0000
X-IronPort-AV: E=Sophos;i="4.71,352,1320642000"; d="scan'208";a="19955403"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Dec 2011 09:46:13 -0500
Received: from cosworth.uk.xensource.com (10.80.16.52) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 14 Dec 2011 09:46:13 -0500
MIME-Version: 1.0
X-Mercurial-Node: a4a5697297410d0d71adb5e96bee5ae061850310
Message-ID: <a4a5697297410d0d71ad.1323873460@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1323873459@cosworth.uk.xensource.com>
References: <patchbomb.1323873459@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Wed, 14 Dec 2011 14:37:40 +0000
From: Paul Durrant <paul.durrant@citrix.com>
To: xen-devel@lists.xensource.com
Cc: paul.durrant@citrix.com
Subject: [Xen-devel] [PATCH 1 of 3] Make ro_paths and rw_paths dynamic
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Paul Durrant <paul.durrant@citrix.com>
# Date 1323873285 0
# Node ID a4a5697297410d0d71adb5e96bee5ae061850310
# Parent  03138a08366b895d79e143119d4c9c72833cdbcd
Make ro_paths and rw_paths dynamic.

The paths need to be different for the HVM and non-HVM cases as, in
the HVM case, we need an 'hvmloader' key. This was previously
handled by creating the hvmloader key in libxl__create_device_model(),
which is only invoked for HVM guests. However, if we are to use the
hvmloader key to parent the 'generation-id-address' key, the creation
needs to move earlier in the sequence. Handling this by making
ro_paths and rw_paths dynamic in libxl__domain_make() seems like
the cleanest approach.
The read-only 'error', 'drivers', 'attr' and 'messages' keys are no
longer created as they seem to be completely unused.

Signed-off-by: Paul Durrant <paul.durrant@citrix.com>

diff -r 03138a08366b -r a4a569729741 tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Fri Dec 09 16:19:36 2011 +0000
+++ b/tools/libxl/libxl_create.c	Wed Dec 14 14:34:45 2011 +0000
@@ -322,9 +322,10 @@ int libxl__domain_make(libxl__gc *gc, li
     libxl_ctx *ctx = libxl__gc_owner(gc);
     int flags, ret, i, rc;
     char *uuid_string;
-    char *rw_paths[] = { "control/shutdown", "device", "device/suspend/event-channel" , "data"};
-    char *ro_paths[] = { "cpu", "memory", "device", "error", "drivers",
-                         "control", "attr", "messages" };
+    char **ro_paths;
+    int nr_ro_paths;
+    char **rw_paths;
+    int nr_rw_paths;
     char *dom_path, *vm_path, *libxl_path;
     struct xs_permissions roperm[2];
     struct xs_permissions rwperm[1];
@@ -341,6 +342,31 @@ int libxl__domain_make(libxl__gc *gc, li
         goto out;
     }
 
+    nr_ro_paths = 0;
+    if (info->type == LIBXL_DOMAIN_TYPE_HVM) {
+        ro_paths = libxl__calloc(gc, 5, sizeof(char *));
+        ro_paths[nr_ro_paths++] = "hvmloader";
+    } else {
+        ro_paths = libxl__calloc(gc, 4, sizeof(char *));
+    }
+
+    ro_paths[nr_ro_paths++] = "cpu";
+    ro_paths[nr_ro_paths++] = "memory";
+    ro_paths[nr_ro_paths++] = "device";
+    ro_paths[nr_ro_paths++] = "control";
+
+    nr_rw_paths = 0;
+    if (info->type == LIBXL_DOMAIN_TYPE_HVM) {
+        rw_paths = libxl__calloc(gc, 4, sizeof(char *));
+        rw_paths[nr_rw_paths++] = "hvmloader/generation-id-address";
+    } else {
+        rw_paths = libxl__calloc(gc, 3, sizeof(char *));
+    }
+
+    rw_paths[nr_rw_paths++] = "control/shutdown";
+    rw_paths[nr_rw_paths++] = "device/suspend/event-channel";
+    rw_paths[nr_rw_paths++] = "data";
+
     flags = 0;
     if (info->type == LIBXL_DOMAIN_TYPE_HVM) {
         flags |= XEN_DOMCTL_CDF_hvm_guest;
@@ -414,16 +440,16 @@ retry_transaction:
     if (rc)
         goto out;
 
-    for (i = 0; i < ARRAY_SIZE(rw_paths); i++) {
-        char *path = libxl__sprintf(gc, "%s/%s", dom_path, rw_paths[i]);
-        xs_mkdir(ctx->xsh, t, path);
-        xs_set_permissions(ctx->xsh, t, path, rwperm, ARRAY_SIZE(rwperm));
-    }
     for (i = 0; i < ARRAY_SIZE(ro_paths); i++) {
         char *path = libxl__sprintf(gc, "%s/%s", dom_path, ro_paths[i]);
         xs_mkdir(ctx->xsh, t, path);
         xs_set_permissions(ctx->xsh, t, path, roperm, ARRAY_SIZE(roperm));
     }
+    for (i = 0; i < nr_rw_paths; i++) {
+        char *path = libxl__sprintf(gc, "%s/%s", dom_path, rw_paths[i]);
+        xs_mkdir(ctx->xsh, t, path);
+        xs_set_permissions(ctx->xsh, t, path, rwperm, ARRAY_SIZE(rwperm));
+    }
 
     xs_write(ctx->xsh, t, libxl__sprintf(gc, "%s/uuid", vm_path), uuid_string, strlen(uuid_string));
     xs_write(ctx->xsh, t, libxl__sprintf(gc, "%s/name", vm_path), info->name, strlen(info->name));
diff -r 03138a08366b -r a4a569729741 tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Fri Dec 09 16:19:36 2011 +0000
+++ b/tools/libxl/libxl_dm.c	Wed Dec 14 14:34:45 2011 +0000
@@ -821,9 +821,7 @@ int libxl__create_device_model(libxl__gc
         goto out;
     }
 
-    path = libxl__sprintf(gc, "/local/domain/%d/hvmloader", info->domid);
-    xs_mkdir(ctx->xsh, XBT_NULL, path);
-    libxl__xs_write(gc, XBT_NULL, libxl__sprintf(gc, "%s/bios", path),
+    libxl__xs_write(gc, XBT_NULL, libxl__sprintf(gc, "/local/domain/%d/hvmloader/bios", info->domid),
                     "%s", libxl__domain_bios(gc, info));
 
     path = libxl__sprintf(gc, "/local/domain/0/device-model/%d", info->domid);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 14:47:27 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 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.xensource.com>)
	id 1Raq6t-0000LE-Df; Wed, 14 Dec 2011 14:47:07 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1Raq6r-0000L7-WD
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 14:47:06 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1323873950!52165047!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDYyMDY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1074 invoked from network); 14 Dec 2011 14:45:52 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Dec 2011 14:45:52 -0000
X-IronPort-AV: E=Sophos;i="4.71,352,1320642000"; d="scan'208";a="19955403"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Dec 2011 09:46:13 -0500
Received: from cosworth.uk.xensource.com (10.80.16.52) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 14 Dec 2011 09:46:13 -0500
MIME-Version: 1.0
X-Mercurial-Node: a4a5697297410d0d71adb5e96bee5ae061850310
Message-ID: <a4a5697297410d0d71ad.1323873460@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1323873459@cosworth.uk.xensource.com>
References: <patchbomb.1323873459@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Wed, 14 Dec 2011 14:37:40 +0000
From: Paul Durrant <paul.durrant@citrix.com>
To: xen-devel@lists.xensource.com
Cc: paul.durrant@citrix.com
Subject: [Xen-devel] [PATCH 1 of 3] Make ro_paths and rw_paths dynamic
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Paul Durrant <paul.durrant@citrix.com>
# Date 1323873285 0
# Node ID a4a5697297410d0d71adb5e96bee5ae061850310
# Parent  03138a08366b895d79e143119d4c9c72833cdbcd
Make ro_paths and rw_paths dynamic.

The paths need to be different for the HVM and non-HVM cases as, in
the HVM case, we need an 'hvmloader' key. This was previously
handled by creating the hvmloader key in libxl__create_device_model(),
which is only invoked for HVM guests. However, if we are to use the
hvmloader key to parent the 'generation-id-address' key, the creation
needs to move earlier in the sequence. Handling this by making
ro_paths and rw_paths dynamic in libxl__domain_make() seems like
the cleanest approach.
The read-only 'error', 'drivers', 'attr' and 'messages' keys are no
longer created as they seem to be completely unused.

Signed-off-by: Paul Durrant <paul.durrant@citrix.com>

diff -r 03138a08366b -r a4a569729741 tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Fri Dec 09 16:19:36 2011 +0000
+++ b/tools/libxl/libxl_create.c	Wed Dec 14 14:34:45 2011 +0000
@@ -322,9 +322,10 @@ int libxl__domain_make(libxl__gc *gc, li
     libxl_ctx *ctx = libxl__gc_owner(gc);
     int flags, ret, i, rc;
     char *uuid_string;
-    char *rw_paths[] = { "control/shutdown", "device", "device/suspend/event-channel" , "data"};
-    char *ro_paths[] = { "cpu", "memory", "device", "error", "drivers",
-                         "control", "attr", "messages" };
+    char **ro_paths;
+    int nr_ro_paths;
+    char **rw_paths;
+    int nr_rw_paths;
     char *dom_path, *vm_path, *libxl_path;
     struct xs_permissions roperm[2];
     struct xs_permissions rwperm[1];
@@ -341,6 +342,31 @@ int libxl__domain_make(libxl__gc *gc, li
         goto out;
     }
 
+    nr_ro_paths = 0;
+    if (info->type == LIBXL_DOMAIN_TYPE_HVM) {
+        ro_paths = libxl__calloc(gc, 5, sizeof(char *));
+        ro_paths[nr_ro_paths++] = "hvmloader";
+    } else {
+        ro_paths = libxl__calloc(gc, 4, sizeof(char *));
+    }
+
+    ro_paths[nr_ro_paths++] = "cpu";
+    ro_paths[nr_ro_paths++] = "memory";
+    ro_paths[nr_ro_paths++] = "device";
+    ro_paths[nr_ro_paths++] = "control";
+
+    nr_rw_paths = 0;
+    if (info->type == LIBXL_DOMAIN_TYPE_HVM) {
+        rw_paths = libxl__calloc(gc, 4, sizeof(char *));
+        rw_paths[nr_rw_paths++] = "hvmloader/generation-id-address";
+    } else {
+        rw_paths = libxl__calloc(gc, 3, sizeof(char *));
+    }
+
+    rw_paths[nr_rw_paths++] = "control/shutdown";
+    rw_paths[nr_rw_paths++] = "device/suspend/event-channel";
+    rw_paths[nr_rw_paths++] = "data";
+
     flags = 0;
     if (info->type == LIBXL_DOMAIN_TYPE_HVM) {
         flags |= XEN_DOMCTL_CDF_hvm_guest;
@@ -414,16 +440,16 @@ retry_transaction:
     if (rc)
         goto out;
 
-    for (i = 0; i < ARRAY_SIZE(rw_paths); i++) {
-        char *path = libxl__sprintf(gc, "%s/%s", dom_path, rw_paths[i]);
-        xs_mkdir(ctx->xsh, t, path);
-        xs_set_permissions(ctx->xsh, t, path, rwperm, ARRAY_SIZE(rwperm));
-    }
     for (i = 0; i < ARRAY_SIZE(ro_paths); i++) {
         char *path = libxl__sprintf(gc, "%s/%s", dom_path, ro_paths[i]);
         xs_mkdir(ctx->xsh, t, path);
         xs_set_permissions(ctx->xsh, t, path, roperm, ARRAY_SIZE(roperm));
     }
+    for (i = 0; i < nr_rw_paths; i++) {
+        char *path = libxl__sprintf(gc, "%s/%s", dom_path, rw_paths[i]);
+        xs_mkdir(ctx->xsh, t, path);
+        xs_set_permissions(ctx->xsh, t, path, rwperm, ARRAY_SIZE(rwperm));
+    }
 
     xs_write(ctx->xsh, t, libxl__sprintf(gc, "%s/uuid", vm_path), uuid_string, strlen(uuid_string));
     xs_write(ctx->xsh, t, libxl__sprintf(gc, "%s/name", vm_path), info->name, strlen(info->name));
diff -r 03138a08366b -r a4a569729741 tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Fri Dec 09 16:19:36 2011 +0000
+++ b/tools/libxl/libxl_dm.c	Wed Dec 14 14:34:45 2011 +0000
@@ -821,9 +821,7 @@ int libxl__create_device_model(libxl__gc
         goto out;
     }
 
-    path = libxl__sprintf(gc, "/local/domain/%d/hvmloader", info->domid);
-    xs_mkdir(ctx->xsh, XBT_NULL, path);
-    libxl__xs_write(gc, XBT_NULL, libxl__sprintf(gc, "%s/bios", path),
+    libxl__xs_write(gc, XBT_NULL, libxl__sprintf(gc, "/local/domain/%d/hvmloader/bios", info->domid),
                     "%s", libxl__domain_bios(gc, info));
 
     path = libxl__sprintf(gc, "/local/domain/0/device-model/%d", info->domid);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 14:47:30 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 14: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.xensource.com>)
	id 1Raq70-0000Lz-LL; Wed, 14 Dec 2011 14:47:14 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1Raq6z-0000LK-96
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 14:47:13 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1323873973!5558017!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjA4OTk=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22167 invoked from network); 14 Dec 2011 14:46:16 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Dec 2011 14:46:16 -0000
X-IronPort-AV: E=Sophos;i="4.71,352,1320642000"; d="scan'208";a="174115364"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Dec 2011 09:46:16 -0500
Received: from cosworth.uk.xensource.com (10.80.16.52) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 14 Dec 2011 09:46:15 -0500
MIME-Version: 1.0
X-Mercurial-Node: 5f0a09b7edc29076bd72bae4a53259c71545b0bf
Message-ID: <5f0a09b7edc29076bd72.1323873462@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1323873459@cosworth.uk.xensource.com>
References: <patchbomb.1323873459@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Wed, 14 Dec 2011 14:37:42 +0000
From: Paul Durrant <paul.durrant@citrix.com>
To: xen-devel@lists.xensource.com
Cc: paul.durrant@citrix.com
Subject: [Xen-devel] [PATCH 3 of 3] VM generation ID save/restore and migrate
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Paul Durrant <paul.durrant@citrix.com>
# Date 1323873288 0
# Node ID 5f0a09b7edc29076bd72bae4a53259c71545b0bf
# Parent  9618ee3b6896eb8202e737b3bb027b248af6dd70
VM generation ID save/restore and migrate.

Add code to track the address of the VM generation ID buffer across a
save/restore or migrate, and increment it as necessary.
The address of the buffer is written into xenstore by hvmloader at
boot time. It must be read from xenstore by the caller of
xc_domain_save() and then written back again by the caller of
xc_domain_restore().

Signed-off-by: Paul Durrant <paul.durrant@citrix.com>

diff -r 9618ee3b6896 -r 5f0a09b7edc2 tools/libxc/ia64/xc_ia64_linux_restore.c
--- a/tools/libxc/ia64/xc_ia64_linux_restore.c	Wed Dec 14 14:34:47 2011 +0000
+++ b/tools/libxc/ia64/xc_ia64_linux_restore.c	Wed Dec 14 14:34:48 2011 +0000
@@ -548,7 +548,8 @@ int
 xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
                   unsigned int store_evtchn, unsigned long *store_mfn,
                   unsigned int console_evtchn, unsigned long *console_mfn,
-                  unsigned int hvm, unsigned int pae, int superpages)
+                  unsigned int hvm, unsigned int pae, int superpages,
+                  int no_incr_generationid, unsigned long *vm_generationid_addr)
 {
     DECLARE_DOMCTL;
     int rc = 1;
diff -r 9618ee3b6896 -r 5f0a09b7edc2 tools/libxc/ia64/xc_ia64_linux_save.c
--- a/tools/libxc/ia64/xc_ia64_linux_save.c	Wed Dec 14 14:34:47 2011 +0000
+++ b/tools/libxc/ia64/xc_ia64_linux_save.c	Wed Dec 14 14:34:48 2011 +0000
@@ -382,7 +382,8 @@ out:
 int
 xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iters,
                uint32_t max_factor, uint32_t flags,
-               struct save_callbacks* callbacks, int hvm)
+               struct save_callbacks* callbacks, int hvm,
+               unsigned long vm_generationid_addr)
 {
     DECLARE_DOMCTL;
     xc_dominfo_t info;
diff -r 9618ee3b6896 -r 5f0a09b7edc2 tools/libxc/xc_domain_restore.c
--- a/tools/libxc/xc_domain_restore.c	Wed Dec 14 14:34:47 2011 +0000
+++ b/tools/libxc/xc_domain_restore.c	Wed Dec 14 14:34:48 2011 +0000
@@ -681,6 +681,7 @@ typedef struct {
     uint64_t console_pfn;
     uint64_t acpi_ioport_location;
     uint64_t viridian;
+    uint64_t vm_generationid_addr;
 } pagebuf_t;
 
 static int pagebuf_init(pagebuf_t* buf)
@@ -860,6 +861,17 @@ static int pagebuf_get_one(xc_interface 
         }
         return compbuf_size;
 
+    case XC_SAVE_ID_HVM_GENERATION_ID_ADDR:
+        /* Skip padding 4 bytes then read the generation id buffer location. */
+        if ( RDEXACT(fd, &buf->vm_generationid_addr, sizeof(uint32_t)) ||
+             RDEXACT(fd, &buf->vm_generationid_addr, sizeof(uint64_t)) )
+        {
+            PERROR("error read the generation id buffer location");
+            return -1;
+        }
+        DPRINTF("read generation id buffer address");
+        return pagebuf_get_one(xch, ctx, buf, fd, dom);
+
     default:
         if ( (count > MAX_BATCH_SIZE) || (count < 0) ) {
             ERROR("Max batch size exceeded (%d). Giving up.", count);
@@ -1248,7 +1260,8 @@ static int apply_batch(xc_interface *xch
 int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
                       unsigned int store_evtchn, unsigned long *store_mfn,
                       unsigned int console_evtchn, unsigned long *console_mfn,
-                      unsigned int hvm, unsigned int pae, int superpages)
+                      unsigned int hvm, unsigned int pae, int superpages,
+                      int no_incr_generationid, unsigned long *vm_generationid_addr)
 {
     DECLARE_DOMCTL;
     int rc = 1, frc, i, j, n, m, pae_extended_cr3 = 0, ext_vcpucontext = 0;
@@ -1449,6 +1462,39 @@ int xc_domain_restore(xc_interface *xch,
                 xc_set_hvm_param(xch, dom, HVM_PARAM_VM86_TSS, pagebuf.vm86_tss);
             if ( pagebuf.console_pfn )
                 console_pfn = pagebuf.console_pfn;
+            if ( pagebuf.vm_generationid_addr ) {
+                if ( !no_incr_generationid ) {
+                    unsigned int offset;
+                    unsigned char *buf;
+                    unsigned long long generationid;
+
+                    /*
+                     * Map the VM generation id buffer and inject the new value.
+                     */
+
+                    pfn = pagebuf.vm_generationid_addr >> PAGE_SHIFT;
+                    offset = pagebuf.vm_generationid_addr & (PAGE_SIZE - 1);
+                
+                    if ( (pfn >= dinfo->p2m_size) ||
+                         (pfn_type[pfn] != XEN_DOMCTL_PFINFO_NOTAB) )
+                    {
+                        ERROR("generation id buffer frame is bad");
+                        goto out;
+                    }
+
+                    mfn = ctx->p2m[pfn];
+                    buf = xc_map_foreign_range(xch, dom, PAGE_SIZE,
+                                               PROT_READ | PROT_WRITE, mfn);
+
+                    generationid = *(unsigned long long *)(buf + offset);
+                    *(unsigned long long *)(buf + offset) = generationid + 1;
+
+                    munmap(buf, PAGE_SIZE);
+                }
+
+                *vm_generationid_addr = pagebuf.vm_generationid_addr;
+            }
+
             break;  /* our work here is done */
         }
 
diff -r 9618ee3b6896 -r 5f0a09b7edc2 tools/libxc/xc_domain_save.c
--- a/tools/libxc/xc_domain_save.c	Wed Dec 14 14:34:47 2011 +0000
+++ b/tools/libxc/xc_domain_save.c	Wed Dec 14 14:34:48 2011 +0000
@@ -804,7 +804,8 @@ static int save_tsc_info(xc_interface *x
 
 int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iters,
                    uint32_t max_factor, uint32_t flags,
-                   struct save_callbacks* callbacks, int hvm)
+                   struct save_callbacks* callbacks, int hvm,
+                   unsigned long vm_generationid_addr)
 {
     xc_dominfo_t info;
     DECLARE_DOMCTL;
@@ -1616,6 +1617,16 @@ int xc_domain_save(xc_interface *xch, in
             uint64_t data;
         } chunk = { 0, };
 
+        chunk.id = XC_SAVE_ID_HVM_GENERATION_ID_ADDR;
+        chunk.data = vm_generationid_addr;
+
+        if ( (chunk.data != 0) &&
+             wrexact(io_fd, &chunk, sizeof(chunk)) )
+        {
+            PERROR("Error when writing the generation id buffer location for guest");
+            goto out;
+        }
+
         chunk.id = XC_SAVE_ID_HVM_IDENT_PT;
         chunk.data = 0;
         xc_get_hvm_param(xch, dom, HVM_PARAM_IDENT_PT,
diff -r 9618ee3b6896 -r 5f0a09b7edc2 tools/libxc/xenguest.h
--- a/tools/libxc/xenguest.h	Wed Dec 14 14:34:47 2011 +0000
+++ b/tools/libxc/xenguest.h	Wed Dec 14 14:34:48 2011 +0000
@@ -58,7 +58,8 @@ struct save_callbacks {
  */
 int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iters,
                    uint32_t max_factor, uint32_t flags /* XCFLAGS_xxx */,
-                   struct save_callbacks* callbacks, int hvm);
+                   struct save_callbacks* callbacks, int hvm,
+                   unsigned long vm_generationid_addr);
 
 
 /**
@@ -72,12 +73,15 @@ int xc_domain_save(xc_interface *xch, in
  * @parm hvm non-zero if this is a HVM restore
  * @parm pae non-zero if this HVM domain has PAE support enabled
  * @parm superpages non-zero to allocate guest memory with superpages
+ * @parm no_incr_generationid non-zero if generation id is NOT to be incremented
+ * @parm vm_generationid_addr returned with the address of the generation id buffer
  * @return 0 on success, -1 on failure
  */
 int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
                       unsigned int store_evtchn, unsigned long *store_mfn,
                       unsigned int console_evtchn, unsigned long *console_mfn,
-                      unsigned int hvm, unsigned int pae, int superpages);
+                      unsigned int hvm, unsigned int pae, int superpages,
+                      int no_incr_generationid, unsigned long *vm_generationid_addr);
 /**
  * xc_domain_restore writes a file to disk that contains the device
  * model saved state.
diff -r 9618ee3b6896 -r 5f0a09b7edc2 tools/libxc/xg_save_restore.h
--- a/tools/libxc/xg_save_restore.h	Wed Dec 14 14:34:47 2011 +0000
+++ b/tools/libxc/xg_save_restore.h	Wed Dec 14 14:34:48 2011 +0000
@@ -253,6 +253,7 @@
 #define XC_SAVE_ID_HVM_VIRIDIAN       -11
 #define XC_SAVE_ID_COMPRESSED_DATA    -12 /* Marker to indicate arrival of compressed data */
 #define XC_SAVE_ID_ENABLE_COMPRESSION -13 /* Marker to enable compression logic at receiver side */
+#define XC_SAVE_ID_HVM_GENERATION_ID_ADDR -14
 
 /*
 ** We process save/restore/migrate in batches of pages; the below
diff -r 9618ee3b6896 -r 5f0a09b7edc2 tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Wed Dec 14 14:34:47 2011 +0000
+++ b/tools/libxl/libxl_create.c	Wed Dec 14 14:34:48 2011 +0000
@@ -99,6 +99,7 @@ int libxl_init_build_info(libxl_ctx *ctx
         b_info->u.hvm.vpt_align = 1;
         b_info->u.hvm.timer_mode = 1;
         b_info->u.hvm.nested_hvm = 0;
+        b_info->u.hvm.no_incr_generationid = 0;
         break;
     case LIBXL_DOMAIN_TYPE_PV:
         b_info->u.pv.slack_memkb = 8 * 1024;
diff -r 9618ee3b6896 -r 5f0a09b7edc2 tools/libxl/libxl_dom.c
--- a/tools/libxl/libxl_dom.c	Wed Dec 14 14:34:47 2011 +0000
+++ b/tools/libxl/libxl_dom.c	Wed Dec 14 14:34:48 2011 +0000
@@ -106,6 +106,7 @@ int libxl__build_pre(libxl__gc *gc, uint
 
     state->store_port = xc_evtchn_alloc_unbound(ctx->xch, domid, 0);
     state->console_port = xc_evtchn_alloc_unbound(ctx->xch, domid, 0);
+    state->vm_generationid_addr = 0;
     return 0;
 }
 
@@ -117,7 +118,7 @@ int libxl__build_post(libxl__gc *gc, uin
     libxl_ctx *ctx = libxl__gc_owner(gc);
     char *dom_path, *vm_path;
     xs_transaction_t t;
-    char **ents;
+    char **ents, **hvm_ents;
     int i;
 
     libxl_cpuid_apply_policy(ctx, domid);
@@ -143,6 +144,13 @@ int libxl__build_post(libxl__gc *gc, uin
                             ? "offline" : "online";
     }
 
+    hvm_ents = NULL;
+    if (info->type == LIBXL_DOMAIN_TYPE_HVM) {
+        hvm_ents = libxl__calloc(gc, 3, sizeof(char *));
+        hvm_ents[0] = "hvmloader/generation-id-address";
+        hvm_ents[1] = libxl__sprintf(gc, "0x%lx", state->vm_generationid_addr);
+    }
+
     dom_path = libxl__xs_get_dompath(gc, domid);
     if (!dom_path) {
         return ERROR_FAIL;
@@ -153,6 +161,9 @@ retry_transaction:
     t = xs_transaction_start(ctx->xsh);
 
     libxl__xs_writev(gc, t, dom_path, ents);
+    if (info->type == LIBXL_DOMAIN_TYPE_HVM)
+        libxl__xs_writev(gc, t, dom_path, hvm_ents);
+
     libxl__xs_writev(gc, t, dom_path, local_ents);
     libxl__xs_writev(gc, t, vm_path, vms_ents);
 
@@ -356,16 +367,19 @@ int libxl__domain_restore_common(libxl__
     /* read signature */
     int rc;
     int hvm, pae, superpages;
+    int no_incr_generationid;
     switch (info->type) {
     case LIBXL_DOMAIN_TYPE_HVM:
         hvm = 1;
         superpages = 1;
         pae = info->u.hvm.pae;
+        no_incr_generationid = info->u.hvm.no_incr_generationid;
         break;
     case LIBXL_DOMAIN_TYPE_PV:
         hvm = 0;
         superpages = 0;
         pae = 1;
+        no_incr_generationid = 0;
         break;
     default:
         return ERROR_INVAL;
@@ -373,7 +387,8 @@ int libxl__domain_restore_common(libxl__
     rc = xc_domain_restore(ctx->xch, fd, domid,
                            state->store_port, &state->store_mfn,
                            state->console_port, &state->console_mfn,
-                           hvm, pae, superpages);
+                           hvm, pae, superpages, no_incr_generationid,
+                           &state->vm_generationid_addr);
     if ( rc ) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "restoring domain");
         return ERROR_FAIL;
@@ -539,12 +554,22 @@ int libxl__domain_suspend_common(libxl__
     struct save_callbacks callbacks;
     struct suspendinfo si;
     int hvm, rc = ERROR_FAIL;
+    unsigned long vm_generationid_addr;
 
     switch (type) {
-    case LIBXL_DOMAIN_TYPE_HVM:
+    case LIBXL_DOMAIN_TYPE_HVM: {
+        char *path;
+        char *addr;
+
+        path = libxl__sprintf(gc, "%s/hvmloader/generation-id-address", libxl__xs_get_dompath(gc, domid));
+        addr = libxl__xs_read(gc, XBT_NULL, path);
+
+        vm_generationid_addr = (addr) ? strtoul(addr, NULL, 0) : 0;
         hvm = 1;
         break;
+    }
     case LIBXL_DOMAIN_TYPE_PV:
+        vm_generationid_addr = 0;
         hvm = 0;
         break;
     default:
@@ -582,7 +607,8 @@ int libxl__domain_suspend_common(libxl__
     callbacks.switch_qemu_logdirty = libxl__domain_suspend_common_switch_qemu_logdirty;
     callbacks.data = &si;
 
-    rc = xc_domain_save(ctx->xch, fd, domid, 0, 0, flags, &callbacks, hvm);
+    rc = xc_domain_save(ctx->xch, fd, domid, 0, 0, flags, &callbacks,
+                        hvm, vm_generationid_addr);
     if ( rc ) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "saving domain: %s",
                          si.guest_responded ?
diff -r 9618ee3b6896 -r 5f0a09b7edc2 tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Wed Dec 14 14:34:47 2011 +0000
+++ b/tools/libxl/libxl_internal.h	Wed Dec 14 14:34:48 2011 +0000
@@ -218,6 +218,7 @@ typedef struct {
 
     uint32_t console_port;
     unsigned long console_mfn;
+    unsigned long vm_generationid_addr;
 } libxl__domain_build_state;
 
 _hidden int libxl__build_pre(libxl__gc *gc, uint32_t domid,
diff -r 9618ee3b6896 -r 5f0a09b7edc2 tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Wed Dec 14 14:34:47 2011 +0000
+++ b/tools/libxl/libxl_types.idl	Wed Dec 14 14:34:48 2011 +0000
@@ -184,6 +184,7 @@ libxl_domain_build_info = Struct("domain
                                        ("vpt_align", bool),
                                        ("timer_mode", integer),
                                        ("nested_hvm", bool),
+                                       ("no_incr_generationid", bool),
                                        ])),
                  ("pv", Struct(None, [("kernel", libxl_file_reference),
                                       ("slack_memkb", uint32),
diff -r 9618ee3b6896 -r 5f0a09b7edc2 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Wed Dec 14 14:34:47 2011 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Wed Dec 14 14:34:48 2011 +0000
@@ -360,6 +360,7 @@ static void printf_info(int domid,
         printf("\t\t\t(vpt_align %d)\n", b_info->u.hvm.vpt_align);
         printf("\t\t\t(timer_mode %d)\n", b_info->u.hvm.timer_mode);
         printf("\t\t\t(nestedhvm %d)\n", b_info->u.hvm.nested_hvm);
+        printf("\t\t\t(no_incr_generationid %d)\n", b_info->u.hvm.no_incr_generationid);
 
         printf("\t\t\t(device_model %s)\n", dm_info->device_model ? : "default");
         printf("\t\t\t(videoram %d)\n", dm_info->videoram);
@@ -1362,6 +1363,7 @@ struct domain_create {
     const char *restore_file;
     int migrate_fd; /* -1 means none */
     char **migration_domname_r; /* from malloc */
+    int no_incr_generationid;
 };
 
 static int freemem(libxl_domain_build_info *b_info, libxl_device_model_info *dm_info)
@@ -1575,6 +1577,8 @@ static int create_domain(struct domain_c
         }
     }
 
+    d_config.b_info.u.hvm.no_incr_generationid = dom_info->no_incr_generationid;
+
     if (debug || dom_info->dryrun)
         printf_info(-1, &d_config, &d_config.dm_info);
 
@@ -2800,6 +2804,7 @@ static void migrate_receive(int debug, i
     dom_info.restore_file = "incoming migration stream";
     dom_info.migrate_fd = 0; /* stdin */
     dom_info.migration_domname_r = &migration_domname;
+    dom_info.no_incr_generationid = 1;
 
     rc = create_domain(&dom_info);
     if (rc < 0) {
diff -r 9618ee3b6896 -r 5f0a09b7edc2 tools/python/xen/lowlevel/checkpoint/libcheckpoint.c
--- a/tools/python/xen/lowlevel/checkpoint/libcheckpoint.c	Wed Dec 14 14:34:47 2011 +0000
+++ b/tools/python/xen/lowlevel/checkpoint/libcheckpoint.c	Wed Dec 14 14:34:48 2011 +0000
@@ -175,6 +175,7 @@ int checkpoint_start(checkpoint_state* s
 {
     int hvm, rc;
     int flags = XCFLAGS_LIVE;
+    unsigned long vm_generationid_addr;
 
     if (!s->domid) {
        s->errstr = "checkpoint state not opened";
@@ -185,16 +186,27 @@ int checkpoint_start(checkpoint_state* s
 
     hvm = s->domtype > dt_pv;
     if (hvm) {
+       char path[128];
+       char *addr;
+
+       sprintf(path, "/local/domain/%u/hvmloader/generation-id-address", s->domid);
+       addr = xs_read(s->xsh, XBT_NULL, path, NULL);
+
+       vm_generationid_addr = (addr) ? strtoul(addr, NULL, 0) : 0;
+       free(addr);
+
        flags |= XCFLAGS_HVM;
        if (switch_qemu_logdirty(s, 1))
            return -1;
+    } else {
+       vm_generationid_addr = 0;
     }
     if (remus_flags & CHECKPOINT_FLAGS_COMPRESSION)
       flags |= XCFLAGS_CHECKPOINT_COMPRESS;
 
     callbacks->switch_qemu_logdirty = noop_switch_logdirty;
 
-    rc = xc_domain_save(s->xch, fd, s->domid, 0, 0, flags, callbacks, hvm);
+    rc = xc_domain_save(s->xch, fd, s->domid, 0, 0, flags, callbacks, hvm, vm_generationid_addr);
 
     if (hvm)
        switch_qemu_logdirty(s, 0);
diff -r 9618ee3b6896 -r 5f0a09b7edc2 tools/xcutils/xc_restore.c
--- a/tools/xcutils/xc_restore.c	Wed Dec 14 14:34:47 2011 +0000
+++ b/tools/xcutils/xc_restore.c	Wed Dec 14 14:34:48 2011 +0000
@@ -23,11 +23,12 @@ main(int argc, char **argv)
     xc_interface *xch;
     int io_fd, ret;
     int superpages;
-    unsigned long store_mfn, console_mfn;
+    unsigned long store_mfn, console_mfn, vm_generationid_addr;
+    int no_incr_generationid;
 
-    if ( (argc != 8) && (argc != 9) )
+    if ( (argc < 8) || (argc > 10) )
         errx(1, "usage: %s iofd domid store_evtchn "
-             "console_evtchn hvm pae apic [superpages]", argv[0]);
+             "console_evtchn hvm pae apic [superpages [no_incr_generationid]]", argv[0]);
 
     xch = xc_interface_open(0,0,0);
     if ( !xch )
@@ -40,19 +41,25 @@ main(int argc, char **argv)
     hvm  = atoi(argv[5]);
     pae  = atoi(argv[6]);
     apic = atoi(argv[7]);
-    if ( argc == 9 )
+    if ( argc >= 9 )
 	    superpages = atoi(argv[8]);
     else
 	    superpages = !!hvm;
+    if ( argc == 10 )
+	    no_incr_generationid = !atoi(argv[9]);
+    else
+	    no_incr_generationid = 0;
 
     ret = xc_domain_restore(xch, io_fd, domid, store_evtchn, &store_mfn,
-                            console_evtchn, &console_mfn, hvm, pae, superpages);
+                            console_evtchn, &console_mfn, hvm, pae, superpages,
+                            no_incr_generationid, &vm_generationid_addr);
 
     if ( ret == 0 )
     {
 	printf("store-mfn %li\n", store_mfn);
         if ( !hvm )
             printf("console-mfn %li\n", console_mfn);
+	printf("generation-id-address %lx\n", vm_generationid_addr);
 	fflush(stdout);
     }
 
diff -r 9618ee3b6896 -r 5f0a09b7edc2 tools/xcutils/xc_save.c
--- a/tools/xcutils/xc_save.c	Wed Dec 14 14:34:47 2011 +0000
+++ b/tools/xcutils/xc_save.c	Wed Dec 14 14:34:48 2011 +0000
@@ -169,6 +169,10 @@ main(int argc, char **argv)
     unsigned int maxit, max_f;
     int io_fd, ret, port;
     struct save_callbacks callbacks;
+    char path[128];
+    struct xs_handle *xs;
+    char *addr;
+    unsigned long vm_generationid_addr;
 
     if (argc != 6)
         errx(1, "usage: %s iofd domid maxit maxf flags", argv[0]);
@@ -207,8 +211,21 @@ main(int argc, char **argv)
     memset(&callbacks, 0, sizeof(callbacks));
     callbacks.suspend = suspend;
     callbacks.switch_qemu_logdirty = switch_qemu_logdirty;
+
+    sprintf(path, "/local/domain/%d/hvmloader/generation-id-address", si.domid);
+
+    if ((xs = xs_daemon_open()) == NULL)
+        errx(1, "Couldn't contact xenstore");
+
+    addr = xs_read(xs, XBT_NULL, path, NULL);
+
+    xs_daemon_close(xs);
+
+    vm_generationid_addr = (addr) ? strtoul(addr, NULL, 0) : 0;
+    free(addr);
+
     ret = xc_domain_save(si.xch, io_fd, si.domid, maxit, max_f, si.flags, 
-                         &callbacks, !!(si.flags & XCFLAGS_HVM));
+                         &callbacks, !!(si.flags & XCFLAGS_HVM), vm_generationid_addr);
 
     if (si.suspend_evtchn > 0)
 	 xc_suspend_evtchn_release(si.xch, si.xce, si.domid, si.suspend_evtchn);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 14:47:30 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 14: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.xensource.com>)
	id 1Raq70-0000Lz-LL; Wed, 14 Dec 2011 14:47:14 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1Raq6z-0000LK-96
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 14:47:13 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1323873973!5558017!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjA4OTk=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22167 invoked from network); 14 Dec 2011 14:46:16 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Dec 2011 14:46:16 -0000
X-IronPort-AV: E=Sophos;i="4.71,352,1320642000"; d="scan'208";a="174115364"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Dec 2011 09:46:16 -0500
Received: from cosworth.uk.xensource.com (10.80.16.52) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 14 Dec 2011 09:46:15 -0500
MIME-Version: 1.0
X-Mercurial-Node: 5f0a09b7edc29076bd72bae4a53259c71545b0bf
Message-ID: <5f0a09b7edc29076bd72.1323873462@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1323873459@cosworth.uk.xensource.com>
References: <patchbomb.1323873459@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Wed, 14 Dec 2011 14:37:42 +0000
From: Paul Durrant <paul.durrant@citrix.com>
To: xen-devel@lists.xensource.com
Cc: paul.durrant@citrix.com
Subject: [Xen-devel] [PATCH 3 of 3] VM generation ID save/restore and migrate
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Paul Durrant <paul.durrant@citrix.com>
# Date 1323873288 0
# Node ID 5f0a09b7edc29076bd72bae4a53259c71545b0bf
# Parent  9618ee3b6896eb8202e737b3bb027b248af6dd70
VM generation ID save/restore and migrate.

Add code to track the address of the VM generation ID buffer across a
save/restore or migrate, and increment it as necessary.
The address of the buffer is written into xenstore by hvmloader at
boot time. It must be read from xenstore by the caller of
xc_domain_save() and then written back again by the caller of
xc_domain_restore().

Signed-off-by: Paul Durrant <paul.durrant@citrix.com>

diff -r 9618ee3b6896 -r 5f0a09b7edc2 tools/libxc/ia64/xc_ia64_linux_restore.c
--- a/tools/libxc/ia64/xc_ia64_linux_restore.c	Wed Dec 14 14:34:47 2011 +0000
+++ b/tools/libxc/ia64/xc_ia64_linux_restore.c	Wed Dec 14 14:34:48 2011 +0000
@@ -548,7 +548,8 @@ int
 xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
                   unsigned int store_evtchn, unsigned long *store_mfn,
                   unsigned int console_evtchn, unsigned long *console_mfn,
-                  unsigned int hvm, unsigned int pae, int superpages)
+                  unsigned int hvm, unsigned int pae, int superpages,
+                  int no_incr_generationid, unsigned long *vm_generationid_addr)
 {
     DECLARE_DOMCTL;
     int rc = 1;
diff -r 9618ee3b6896 -r 5f0a09b7edc2 tools/libxc/ia64/xc_ia64_linux_save.c
--- a/tools/libxc/ia64/xc_ia64_linux_save.c	Wed Dec 14 14:34:47 2011 +0000
+++ b/tools/libxc/ia64/xc_ia64_linux_save.c	Wed Dec 14 14:34:48 2011 +0000
@@ -382,7 +382,8 @@ out:
 int
 xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iters,
                uint32_t max_factor, uint32_t flags,
-               struct save_callbacks* callbacks, int hvm)
+               struct save_callbacks* callbacks, int hvm,
+               unsigned long vm_generationid_addr)
 {
     DECLARE_DOMCTL;
     xc_dominfo_t info;
diff -r 9618ee3b6896 -r 5f0a09b7edc2 tools/libxc/xc_domain_restore.c
--- a/tools/libxc/xc_domain_restore.c	Wed Dec 14 14:34:47 2011 +0000
+++ b/tools/libxc/xc_domain_restore.c	Wed Dec 14 14:34:48 2011 +0000
@@ -681,6 +681,7 @@ typedef struct {
     uint64_t console_pfn;
     uint64_t acpi_ioport_location;
     uint64_t viridian;
+    uint64_t vm_generationid_addr;
 } pagebuf_t;
 
 static int pagebuf_init(pagebuf_t* buf)
@@ -860,6 +861,17 @@ static int pagebuf_get_one(xc_interface 
         }
         return compbuf_size;
 
+    case XC_SAVE_ID_HVM_GENERATION_ID_ADDR:
+        /* Skip padding 4 bytes then read the generation id buffer location. */
+        if ( RDEXACT(fd, &buf->vm_generationid_addr, sizeof(uint32_t)) ||
+             RDEXACT(fd, &buf->vm_generationid_addr, sizeof(uint64_t)) )
+        {
+            PERROR("error read the generation id buffer location");
+            return -1;
+        }
+        DPRINTF("read generation id buffer address");
+        return pagebuf_get_one(xch, ctx, buf, fd, dom);
+
     default:
         if ( (count > MAX_BATCH_SIZE) || (count < 0) ) {
             ERROR("Max batch size exceeded (%d). Giving up.", count);
@@ -1248,7 +1260,8 @@ static int apply_batch(xc_interface *xch
 int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
                       unsigned int store_evtchn, unsigned long *store_mfn,
                       unsigned int console_evtchn, unsigned long *console_mfn,
-                      unsigned int hvm, unsigned int pae, int superpages)
+                      unsigned int hvm, unsigned int pae, int superpages,
+                      int no_incr_generationid, unsigned long *vm_generationid_addr)
 {
     DECLARE_DOMCTL;
     int rc = 1, frc, i, j, n, m, pae_extended_cr3 = 0, ext_vcpucontext = 0;
@@ -1449,6 +1462,39 @@ int xc_domain_restore(xc_interface *xch,
                 xc_set_hvm_param(xch, dom, HVM_PARAM_VM86_TSS, pagebuf.vm86_tss);
             if ( pagebuf.console_pfn )
                 console_pfn = pagebuf.console_pfn;
+            if ( pagebuf.vm_generationid_addr ) {
+                if ( !no_incr_generationid ) {
+                    unsigned int offset;
+                    unsigned char *buf;
+                    unsigned long long generationid;
+
+                    /*
+                     * Map the VM generation id buffer and inject the new value.
+                     */
+
+                    pfn = pagebuf.vm_generationid_addr >> PAGE_SHIFT;
+                    offset = pagebuf.vm_generationid_addr & (PAGE_SIZE - 1);
+                
+                    if ( (pfn >= dinfo->p2m_size) ||
+                         (pfn_type[pfn] != XEN_DOMCTL_PFINFO_NOTAB) )
+                    {
+                        ERROR("generation id buffer frame is bad");
+                        goto out;
+                    }
+
+                    mfn = ctx->p2m[pfn];
+                    buf = xc_map_foreign_range(xch, dom, PAGE_SIZE,
+                                               PROT_READ | PROT_WRITE, mfn);
+
+                    generationid = *(unsigned long long *)(buf + offset);
+                    *(unsigned long long *)(buf + offset) = generationid + 1;
+
+                    munmap(buf, PAGE_SIZE);
+                }
+
+                *vm_generationid_addr = pagebuf.vm_generationid_addr;
+            }
+
             break;  /* our work here is done */
         }
 
diff -r 9618ee3b6896 -r 5f0a09b7edc2 tools/libxc/xc_domain_save.c
--- a/tools/libxc/xc_domain_save.c	Wed Dec 14 14:34:47 2011 +0000
+++ b/tools/libxc/xc_domain_save.c	Wed Dec 14 14:34:48 2011 +0000
@@ -804,7 +804,8 @@ static int save_tsc_info(xc_interface *x
 
 int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iters,
                    uint32_t max_factor, uint32_t flags,
-                   struct save_callbacks* callbacks, int hvm)
+                   struct save_callbacks* callbacks, int hvm,
+                   unsigned long vm_generationid_addr)
 {
     xc_dominfo_t info;
     DECLARE_DOMCTL;
@@ -1616,6 +1617,16 @@ int xc_domain_save(xc_interface *xch, in
             uint64_t data;
         } chunk = { 0, };
 
+        chunk.id = XC_SAVE_ID_HVM_GENERATION_ID_ADDR;
+        chunk.data = vm_generationid_addr;
+
+        if ( (chunk.data != 0) &&
+             wrexact(io_fd, &chunk, sizeof(chunk)) )
+        {
+            PERROR("Error when writing the generation id buffer location for guest");
+            goto out;
+        }
+
         chunk.id = XC_SAVE_ID_HVM_IDENT_PT;
         chunk.data = 0;
         xc_get_hvm_param(xch, dom, HVM_PARAM_IDENT_PT,
diff -r 9618ee3b6896 -r 5f0a09b7edc2 tools/libxc/xenguest.h
--- a/tools/libxc/xenguest.h	Wed Dec 14 14:34:47 2011 +0000
+++ b/tools/libxc/xenguest.h	Wed Dec 14 14:34:48 2011 +0000
@@ -58,7 +58,8 @@ struct save_callbacks {
  */
 int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iters,
                    uint32_t max_factor, uint32_t flags /* XCFLAGS_xxx */,
-                   struct save_callbacks* callbacks, int hvm);
+                   struct save_callbacks* callbacks, int hvm,
+                   unsigned long vm_generationid_addr);
 
 
 /**
@@ -72,12 +73,15 @@ int xc_domain_save(xc_interface *xch, in
  * @parm hvm non-zero if this is a HVM restore
  * @parm pae non-zero if this HVM domain has PAE support enabled
  * @parm superpages non-zero to allocate guest memory with superpages
+ * @parm no_incr_generationid non-zero if generation id is NOT to be incremented
+ * @parm vm_generationid_addr returned with the address of the generation id buffer
  * @return 0 on success, -1 on failure
  */
 int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
                       unsigned int store_evtchn, unsigned long *store_mfn,
                       unsigned int console_evtchn, unsigned long *console_mfn,
-                      unsigned int hvm, unsigned int pae, int superpages);
+                      unsigned int hvm, unsigned int pae, int superpages,
+                      int no_incr_generationid, unsigned long *vm_generationid_addr);
 /**
  * xc_domain_restore writes a file to disk that contains the device
  * model saved state.
diff -r 9618ee3b6896 -r 5f0a09b7edc2 tools/libxc/xg_save_restore.h
--- a/tools/libxc/xg_save_restore.h	Wed Dec 14 14:34:47 2011 +0000
+++ b/tools/libxc/xg_save_restore.h	Wed Dec 14 14:34:48 2011 +0000
@@ -253,6 +253,7 @@
 #define XC_SAVE_ID_HVM_VIRIDIAN       -11
 #define XC_SAVE_ID_COMPRESSED_DATA    -12 /* Marker to indicate arrival of compressed data */
 #define XC_SAVE_ID_ENABLE_COMPRESSION -13 /* Marker to enable compression logic at receiver side */
+#define XC_SAVE_ID_HVM_GENERATION_ID_ADDR -14
 
 /*
 ** We process save/restore/migrate in batches of pages; the below
diff -r 9618ee3b6896 -r 5f0a09b7edc2 tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Wed Dec 14 14:34:47 2011 +0000
+++ b/tools/libxl/libxl_create.c	Wed Dec 14 14:34:48 2011 +0000
@@ -99,6 +99,7 @@ int libxl_init_build_info(libxl_ctx *ctx
         b_info->u.hvm.vpt_align = 1;
         b_info->u.hvm.timer_mode = 1;
         b_info->u.hvm.nested_hvm = 0;
+        b_info->u.hvm.no_incr_generationid = 0;
         break;
     case LIBXL_DOMAIN_TYPE_PV:
         b_info->u.pv.slack_memkb = 8 * 1024;
diff -r 9618ee3b6896 -r 5f0a09b7edc2 tools/libxl/libxl_dom.c
--- a/tools/libxl/libxl_dom.c	Wed Dec 14 14:34:47 2011 +0000
+++ b/tools/libxl/libxl_dom.c	Wed Dec 14 14:34:48 2011 +0000
@@ -106,6 +106,7 @@ int libxl__build_pre(libxl__gc *gc, uint
 
     state->store_port = xc_evtchn_alloc_unbound(ctx->xch, domid, 0);
     state->console_port = xc_evtchn_alloc_unbound(ctx->xch, domid, 0);
+    state->vm_generationid_addr = 0;
     return 0;
 }
 
@@ -117,7 +118,7 @@ int libxl__build_post(libxl__gc *gc, uin
     libxl_ctx *ctx = libxl__gc_owner(gc);
     char *dom_path, *vm_path;
     xs_transaction_t t;
-    char **ents;
+    char **ents, **hvm_ents;
     int i;
 
     libxl_cpuid_apply_policy(ctx, domid);
@@ -143,6 +144,13 @@ int libxl__build_post(libxl__gc *gc, uin
                             ? "offline" : "online";
     }
 
+    hvm_ents = NULL;
+    if (info->type == LIBXL_DOMAIN_TYPE_HVM) {
+        hvm_ents = libxl__calloc(gc, 3, sizeof(char *));
+        hvm_ents[0] = "hvmloader/generation-id-address";
+        hvm_ents[1] = libxl__sprintf(gc, "0x%lx", state->vm_generationid_addr);
+    }
+
     dom_path = libxl__xs_get_dompath(gc, domid);
     if (!dom_path) {
         return ERROR_FAIL;
@@ -153,6 +161,9 @@ retry_transaction:
     t = xs_transaction_start(ctx->xsh);
 
     libxl__xs_writev(gc, t, dom_path, ents);
+    if (info->type == LIBXL_DOMAIN_TYPE_HVM)
+        libxl__xs_writev(gc, t, dom_path, hvm_ents);
+
     libxl__xs_writev(gc, t, dom_path, local_ents);
     libxl__xs_writev(gc, t, vm_path, vms_ents);
 
@@ -356,16 +367,19 @@ int libxl__domain_restore_common(libxl__
     /* read signature */
     int rc;
     int hvm, pae, superpages;
+    int no_incr_generationid;
     switch (info->type) {
     case LIBXL_DOMAIN_TYPE_HVM:
         hvm = 1;
         superpages = 1;
         pae = info->u.hvm.pae;
+        no_incr_generationid = info->u.hvm.no_incr_generationid;
         break;
     case LIBXL_DOMAIN_TYPE_PV:
         hvm = 0;
         superpages = 0;
         pae = 1;
+        no_incr_generationid = 0;
         break;
     default:
         return ERROR_INVAL;
@@ -373,7 +387,8 @@ int libxl__domain_restore_common(libxl__
     rc = xc_domain_restore(ctx->xch, fd, domid,
                            state->store_port, &state->store_mfn,
                            state->console_port, &state->console_mfn,
-                           hvm, pae, superpages);
+                           hvm, pae, superpages, no_incr_generationid,
+                           &state->vm_generationid_addr);
     if ( rc ) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "restoring domain");
         return ERROR_FAIL;
@@ -539,12 +554,22 @@ int libxl__domain_suspend_common(libxl__
     struct save_callbacks callbacks;
     struct suspendinfo si;
     int hvm, rc = ERROR_FAIL;
+    unsigned long vm_generationid_addr;
 
     switch (type) {
-    case LIBXL_DOMAIN_TYPE_HVM:
+    case LIBXL_DOMAIN_TYPE_HVM: {
+        char *path;
+        char *addr;
+
+        path = libxl__sprintf(gc, "%s/hvmloader/generation-id-address", libxl__xs_get_dompath(gc, domid));
+        addr = libxl__xs_read(gc, XBT_NULL, path);
+
+        vm_generationid_addr = (addr) ? strtoul(addr, NULL, 0) : 0;
         hvm = 1;
         break;
+    }
     case LIBXL_DOMAIN_TYPE_PV:
+        vm_generationid_addr = 0;
         hvm = 0;
         break;
     default:
@@ -582,7 +607,8 @@ int libxl__domain_suspend_common(libxl__
     callbacks.switch_qemu_logdirty = libxl__domain_suspend_common_switch_qemu_logdirty;
     callbacks.data = &si;
 
-    rc = xc_domain_save(ctx->xch, fd, domid, 0, 0, flags, &callbacks, hvm);
+    rc = xc_domain_save(ctx->xch, fd, domid, 0, 0, flags, &callbacks,
+                        hvm, vm_generationid_addr);
     if ( rc ) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "saving domain: %s",
                          si.guest_responded ?
diff -r 9618ee3b6896 -r 5f0a09b7edc2 tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Wed Dec 14 14:34:47 2011 +0000
+++ b/tools/libxl/libxl_internal.h	Wed Dec 14 14:34:48 2011 +0000
@@ -218,6 +218,7 @@ typedef struct {
 
     uint32_t console_port;
     unsigned long console_mfn;
+    unsigned long vm_generationid_addr;
 } libxl__domain_build_state;
 
 _hidden int libxl__build_pre(libxl__gc *gc, uint32_t domid,
diff -r 9618ee3b6896 -r 5f0a09b7edc2 tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Wed Dec 14 14:34:47 2011 +0000
+++ b/tools/libxl/libxl_types.idl	Wed Dec 14 14:34:48 2011 +0000
@@ -184,6 +184,7 @@ libxl_domain_build_info = Struct("domain
                                        ("vpt_align", bool),
                                        ("timer_mode", integer),
                                        ("nested_hvm", bool),
+                                       ("no_incr_generationid", bool),
                                        ])),
                  ("pv", Struct(None, [("kernel", libxl_file_reference),
                                       ("slack_memkb", uint32),
diff -r 9618ee3b6896 -r 5f0a09b7edc2 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Wed Dec 14 14:34:47 2011 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Wed Dec 14 14:34:48 2011 +0000
@@ -360,6 +360,7 @@ static void printf_info(int domid,
         printf("\t\t\t(vpt_align %d)\n", b_info->u.hvm.vpt_align);
         printf("\t\t\t(timer_mode %d)\n", b_info->u.hvm.timer_mode);
         printf("\t\t\t(nestedhvm %d)\n", b_info->u.hvm.nested_hvm);
+        printf("\t\t\t(no_incr_generationid %d)\n", b_info->u.hvm.no_incr_generationid);
 
         printf("\t\t\t(device_model %s)\n", dm_info->device_model ? : "default");
         printf("\t\t\t(videoram %d)\n", dm_info->videoram);
@@ -1362,6 +1363,7 @@ struct domain_create {
     const char *restore_file;
     int migrate_fd; /* -1 means none */
     char **migration_domname_r; /* from malloc */
+    int no_incr_generationid;
 };
 
 static int freemem(libxl_domain_build_info *b_info, libxl_device_model_info *dm_info)
@@ -1575,6 +1577,8 @@ static int create_domain(struct domain_c
         }
     }
 
+    d_config.b_info.u.hvm.no_incr_generationid = dom_info->no_incr_generationid;
+
     if (debug || dom_info->dryrun)
         printf_info(-1, &d_config, &d_config.dm_info);
 
@@ -2800,6 +2804,7 @@ static void migrate_receive(int debug, i
     dom_info.restore_file = "incoming migration stream";
     dom_info.migrate_fd = 0; /* stdin */
     dom_info.migration_domname_r = &migration_domname;
+    dom_info.no_incr_generationid = 1;
 
     rc = create_domain(&dom_info);
     if (rc < 0) {
diff -r 9618ee3b6896 -r 5f0a09b7edc2 tools/python/xen/lowlevel/checkpoint/libcheckpoint.c
--- a/tools/python/xen/lowlevel/checkpoint/libcheckpoint.c	Wed Dec 14 14:34:47 2011 +0000
+++ b/tools/python/xen/lowlevel/checkpoint/libcheckpoint.c	Wed Dec 14 14:34:48 2011 +0000
@@ -175,6 +175,7 @@ int checkpoint_start(checkpoint_state* s
 {
     int hvm, rc;
     int flags = XCFLAGS_LIVE;
+    unsigned long vm_generationid_addr;
 
     if (!s->domid) {
        s->errstr = "checkpoint state not opened";
@@ -185,16 +186,27 @@ int checkpoint_start(checkpoint_state* s
 
     hvm = s->domtype > dt_pv;
     if (hvm) {
+       char path[128];
+       char *addr;
+
+       sprintf(path, "/local/domain/%u/hvmloader/generation-id-address", s->domid);
+       addr = xs_read(s->xsh, XBT_NULL, path, NULL);
+
+       vm_generationid_addr = (addr) ? strtoul(addr, NULL, 0) : 0;
+       free(addr);
+
        flags |= XCFLAGS_HVM;
        if (switch_qemu_logdirty(s, 1))
            return -1;
+    } else {
+       vm_generationid_addr = 0;
     }
     if (remus_flags & CHECKPOINT_FLAGS_COMPRESSION)
       flags |= XCFLAGS_CHECKPOINT_COMPRESS;
 
     callbacks->switch_qemu_logdirty = noop_switch_logdirty;
 
-    rc = xc_domain_save(s->xch, fd, s->domid, 0, 0, flags, callbacks, hvm);
+    rc = xc_domain_save(s->xch, fd, s->domid, 0, 0, flags, callbacks, hvm, vm_generationid_addr);
 
     if (hvm)
        switch_qemu_logdirty(s, 0);
diff -r 9618ee3b6896 -r 5f0a09b7edc2 tools/xcutils/xc_restore.c
--- a/tools/xcutils/xc_restore.c	Wed Dec 14 14:34:47 2011 +0000
+++ b/tools/xcutils/xc_restore.c	Wed Dec 14 14:34:48 2011 +0000
@@ -23,11 +23,12 @@ main(int argc, char **argv)
     xc_interface *xch;
     int io_fd, ret;
     int superpages;
-    unsigned long store_mfn, console_mfn;
+    unsigned long store_mfn, console_mfn, vm_generationid_addr;
+    int no_incr_generationid;
 
-    if ( (argc != 8) && (argc != 9) )
+    if ( (argc < 8) || (argc > 10) )
         errx(1, "usage: %s iofd domid store_evtchn "
-             "console_evtchn hvm pae apic [superpages]", argv[0]);
+             "console_evtchn hvm pae apic [superpages [no_incr_generationid]]", argv[0]);
 
     xch = xc_interface_open(0,0,0);
     if ( !xch )
@@ -40,19 +41,25 @@ main(int argc, char **argv)
     hvm  = atoi(argv[5]);
     pae  = atoi(argv[6]);
     apic = atoi(argv[7]);
-    if ( argc == 9 )
+    if ( argc >= 9 )
 	    superpages = atoi(argv[8]);
     else
 	    superpages = !!hvm;
+    if ( argc == 10 )
+	    no_incr_generationid = !atoi(argv[9]);
+    else
+	    no_incr_generationid = 0;
 
     ret = xc_domain_restore(xch, io_fd, domid, store_evtchn, &store_mfn,
-                            console_evtchn, &console_mfn, hvm, pae, superpages);
+                            console_evtchn, &console_mfn, hvm, pae, superpages,
+                            no_incr_generationid, &vm_generationid_addr);
 
     if ( ret == 0 )
     {
 	printf("store-mfn %li\n", store_mfn);
         if ( !hvm )
             printf("console-mfn %li\n", console_mfn);
+	printf("generation-id-address %lx\n", vm_generationid_addr);
 	fflush(stdout);
     }
 
diff -r 9618ee3b6896 -r 5f0a09b7edc2 tools/xcutils/xc_save.c
--- a/tools/xcutils/xc_save.c	Wed Dec 14 14:34:47 2011 +0000
+++ b/tools/xcutils/xc_save.c	Wed Dec 14 14:34:48 2011 +0000
@@ -169,6 +169,10 @@ main(int argc, char **argv)
     unsigned int maxit, max_f;
     int io_fd, ret, port;
     struct save_callbacks callbacks;
+    char path[128];
+    struct xs_handle *xs;
+    char *addr;
+    unsigned long vm_generationid_addr;
 
     if (argc != 6)
         errx(1, "usage: %s iofd domid maxit maxf flags", argv[0]);
@@ -207,8 +211,21 @@ main(int argc, char **argv)
     memset(&callbacks, 0, sizeof(callbacks));
     callbacks.suspend = suspend;
     callbacks.switch_qemu_logdirty = switch_qemu_logdirty;
+
+    sprintf(path, "/local/domain/%d/hvmloader/generation-id-address", si.domid);
+
+    if ((xs = xs_daemon_open()) == NULL)
+        errx(1, "Couldn't contact xenstore");
+
+    addr = xs_read(xs, XBT_NULL, path, NULL);
+
+    xs_daemon_close(xs);
+
+    vm_generationid_addr = (addr) ? strtoul(addr, NULL, 0) : 0;
+    free(addr);
+
     ret = xc_domain_save(si.xch, io_fd, si.domid, maxit, max_f, si.flags, 
-                         &callbacks, !!(si.flags & XCFLAGS_HVM));
+                         &callbacks, !!(si.flags & XCFLAGS_HVM), vm_generationid_addr);
 
     if (si.suspend_evtchn > 0)
 	 xc_suspend_evtchn_release(si.xch, si.xce, si.domid, si.suspend_evtchn);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 14:47:31 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 14:47:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Raq6y-0000Lb-R1; Wed, 14 Dec 2011 14:47:12 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1Raq6x-0000L8-1J
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 14:47:11 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1323873973!5558017!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjA4OTk=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22090 invoked from network); 14 Dec 2011 14:46:15 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Dec 2011 14:46:15 -0000
X-IronPort-AV: E=Sophos;i="4.71,352,1320642000"; d="scan'208";a="174115341"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Dec 2011 09:46:13 -0500
Received: from cosworth.uk.xensource.com (10.80.16.52) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 14 Dec 2011 09:46:12 -0500
MIME-Version: 1.0
Message-ID: <patchbomb.1323873459@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Wed, 14 Dec 2011 14:37:39 +0000
From: Paul Durrant <paul.durrant@citrix.com>
To: xen-devel@lists.xensource.com
Cc: paul.durrant@citrix.com
Subject: [Xen-devel] [PATCH 0 of 3] Support for VM generation ID
	save/restore and migrate
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This patch series adds support for preservation of the VM generation ID buffer
address in xenstore across save/restore and migrate, and also code to
increment the value in all cases except for migration.
The first patch modifies creation of the hvmloader key in xenstore and adds
creation of a new read/write hvmloader/generation-id-addr key.
The second patch changes hvmloader to use the new key (as opposed to the old
data/generation-id key).
The third patch adds the infrastructure to save and restore the VM
generation ID address in xenstore and the code to increment the value.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 14:47:31 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 14:47:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Raq6y-0000Lb-R1; Wed, 14 Dec 2011 14:47:12 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1Raq6x-0000L8-1J
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 14:47:11 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1323873973!5558017!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjA4OTk=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22090 invoked from network); 14 Dec 2011 14:46:15 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Dec 2011 14:46:15 -0000
X-IronPort-AV: E=Sophos;i="4.71,352,1320642000"; d="scan'208";a="174115341"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Dec 2011 09:46:13 -0500
Received: from cosworth.uk.xensource.com (10.80.16.52) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 14 Dec 2011 09:46:12 -0500
MIME-Version: 1.0
Message-ID: <patchbomb.1323873459@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Wed, 14 Dec 2011 14:37:39 +0000
From: Paul Durrant <paul.durrant@citrix.com>
To: xen-devel@lists.xensource.com
Cc: paul.durrant@citrix.com
Subject: [Xen-devel] [PATCH 0 of 3] Support for VM generation ID
	save/restore and migrate
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This patch series adds support for preservation of the VM generation ID buffer
address in xenstore across save/restore and migrate, and also code to
increment the value in all cases except for migration.
The first patch modifies creation of the hvmloader key in xenstore and adds
creation of a new read/write hvmloader/generation-id-addr key.
The second patch changes hvmloader to use the new key (as opposed to the old
data/generation-id key).
The third patch adds the infrastructure to save and restore the VM
generation ID address in xenstore and the code to increment the value.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 14:47:31 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 14:47:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Raq6z-0000Lj-8E; Wed, 14 Dec 2011 14:47:13 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1Raq6x-0000LD-OU
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 14:47:11 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1323873973!5558017!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjA4OTk=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22115 invoked from network); 14 Dec 2011 14:46:15 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Dec 2011 14:46:15 -0000
X-IronPort-AV: E=Sophos;i="4.71,352,1320642000"; d="scan'208";a="174115355"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Dec 2011 09:46:15 -0500
Received: from cosworth.uk.xensource.com (10.80.16.52) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 14 Dec 2011 09:46:14 -0500
MIME-Version: 1.0
X-Mercurial-Node: 9618ee3b6896eb8202e737b3bb027b248af6dd70
Message-ID: <9618ee3b6896eb8202e7.1323873461@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1323873459@cosworth.uk.xensource.com>
References: <patchbomb.1323873459@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Wed, 14 Dec 2011 14:37:41 +0000
From: Paul Durrant <paul.durrant@citrix.com>
To: xen-devel@lists.xensource.com
Cc: paul.durrant@citrix.com
Subject: [Xen-devel] [PATCH 2 of 3] Re-name xenstore key used to save VM
 generation ID buffer address
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Paul Durrant <paul.durrant@citrix.com>
# Date 1323873287 0
# Node ID 9618ee3b6896eb8202e737b3bb027b248af6dd70
# Parent  a4a5697297410d0d71adb5e96bee5ae061850310
Re-name xenstore key used to save VM generation ID buffer address.

Signed-off-by: Paul Durrant <paul.durrant@citrix.com>

diff -r a4a569729741 -r 9618ee3b6896 tools/firmware/hvmloader/acpi/build.c
--- a/tools/firmware/hvmloader/acpi/build.c	Wed Dec 14 14:34:45 2011 +0000
+++ b/tools/firmware/hvmloader/acpi/build.c	Wed Dec 14 14:34:47 2011 +0000
@@ -309,7 +309,7 @@ unsigned long new_vm_gid(void)
     if ( snprintf(addr, sizeof(addr), "0x%lx", virt_to_phys(buf))
          >= sizeof(addr) )
         return 0;
-    xenstore_write("data/generation-id", addr);
+    xenstore_write("hvmloader/generation-id-address", addr);
 
     gid = strtoll(xenstore_read("platform/generation-id", "0"), NULL, 0);
     *(uint64_t *)buf = gid;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 14:47:31 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 14:47:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Raq6z-0000Lj-8E; Wed, 14 Dec 2011 14:47:13 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1Raq6x-0000LD-OU
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 14:47:11 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1323873973!5558017!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjA4OTk=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22115 invoked from network); 14 Dec 2011 14:46:15 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Dec 2011 14:46:15 -0000
X-IronPort-AV: E=Sophos;i="4.71,352,1320642000"; d="scan'208";a="174115355"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Dec 2011 09:46:15 -0500
Received: from cosworth.uk.xensource.com (10.80.16.52) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 14 Dec 2011 09:46:14 -0500
MIME-Version: 1.0
X-Mercurial-Node: 9618ee3b6896eb8202e737b3bb027b248af6dd70
Message-ID: <9618ee3b6896eb8202e7.1323873461@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1323873459@cosworth.uk.xensource.com>
References: <patchbomb.1323873459@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Wed, 14 Dec 2011 14:37:41 +0000
From: Paul Durrant <paul.durrant@citrix.com>
To: xen-devel@lists.xensource.com
Cc: paul.durrant@citrix.com
Subject: [Xen-devel] [PATCH 2 of 3] Re-name xenstore key used to save VM
 generation ID buffer address
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Paul Durrant <paul.durrant@citrix.com>
# Date 1323873287 0
# Node ID 9618ee3b6896eb8202e737b3bb027b248af6dd70
# Parent  a4a5697297410d0d71adb5e96bee5ae061850310
Re-name xenstore key used to save VM generation ID buffer address.

Signed-off-by: Paul Durrant <paul.durrant@citrix.com>

diff -r a4a569729741 -r 9618ee3b6896 tools/firmware/hvmloader/acpi/build.c
--- a/tools/firmware/hvmloader/acpi/build.c	Wed Dec 14 14:34:45 2011 +0000
+++ b/tools/firmware/hvmloader/acpi/build.c	Wed Dec 14 14:34:47 2011 +0000
@@ -309,7 +309,7 @@ unsigned long new_vm_gid(void)
     if ( snprintf(addr, sizeof(addr), "0x%lx", virt_to_phys(buf))
          >= sizeof(addr) )
         return 0;
-    xenstore_write("data/generation-id", addr);
+    xenstore_write("hvmloader/generation-id-address", addr);
 
     gid = strtoll(xenstore_read("platform/generation-id", "0"), NULL, 0);
     *(uint64_t *)buf = gid;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 14:53:55 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 14:53:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaqDD-0000x9-PK; Wed, 14 Dec 2011 14:53:39 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RaqDC-0000wj-S0
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 14:53:39 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1323874361!5344505!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28849 invoked from network); 14 Dec 2011 14:52:41 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-14.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Dec 2011 14:52:41 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 14 Dec 2011 14:52:40 +0000
Message-Id: <4EE8C6460200007800067C32@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 14 Dec 2011 14:52:38 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Liwei" <xieliwei@gmail.com>
References: <CAPE0SYwsqRKDuPTz66r0nTVPYcsFx0Dk2j0pWpCiHELuU5W2iA@mail.gmail.com>
	<4EE881270200007800067A65@nat28.tlf.novell.com>
	<20111214125833.GA51060@ocelot.phlegethon.org>
	<CAPE0SYzJLCjO_9Nt5v7jxuMvbv=DFbGGs41=XANRXujbhAW5Vw@mail.gmail.com>
In-Reply-To: <CAPE0SYzJLCjO_9Nt5v7jxuMvbv=DFbGGs41=XANRXujbhAW5Vw@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Tim Deegan <tim@xen.org>, xen-devel <xen-devel@lists.xensource.com>,
	keir@xen.org, Ian.Campbell@citrix.com
Subject: Re: [Xen-devel] PTE Write access is not set
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 14.12.11 at 15:31, Liwei <xieliwei@gmail.com> wrote:
> ======First instance of VM Crash======
> Guest is openSuSE 11.4 on 2.6.37.6-0.5-desktop
> No symptoms in guest logs, logging just stopped.
> Looking at the serial logs, it appears that the guest just vapourised
> (unless the "First re-creation of guest" below is actually the first
> crash, though Jan and Tim mentioned that that crash couldn't have
> occurred during run-time).
> This VM has one part of the Intel 82575GB (0e:00.1) pass-throughed.
> 
> ++++First re-creation of guest++++
> xl create /etc/xen/vm-test4.cfg
> 
> ----Xen log----
> (XEN) HVM7: ata0-0: PCHS=16383/16/63 translation=lba LCHS=1024/255/63
> (XEN) HVM7: ata0 master: QEMU HARDDISK ATA-7 Hard-Disk ( 160 GBytes)
> (XEN) realmode.c:115:d7 Failed to emulate insn.
> (XEN) realmode.c:165:d7 Real-mode emulation failed @ a8c0:00005a8e: ff
> fa 00 15 99 2c
> (XEN) domain_crash called from realmode.c:166
> 
> ++++Second re-creation of guest++++
> xl create /etc/xen/vm-test4.cfg
> 
> (XEN) HVM8: ata0-0: PCHS=16383/16/63 translation=lba LCHS=1024/255/63
> (XEN) HVM8: ata0 master: QEMU HARDDISK ATA-7 Hard-Disk ( 160 GBytes)
> (XEN) realmode.c:115:d8 Failed to emulate insn.
> (XEN) realmode.c:165:d8 Real-mode emulation failed @ a8c0:0000fcb5: 72
> 5c 1b 80 c4 82
> (XEN) domain_crash called from realmode.c:166
> 
> [Did the same thing a few more times with similar results and gave up,
> rebooted dom0 and all was well]

So this suggests that the virtual firmware has a problem coming back
up with the passed through device still active (and the IOMMU may in
fact be shielding the rest of the system from bad effects of this).

This by itself is a problem, and the sudden death of the guest is
another (particularly if indeed there's no trace of that event in any
logs). Debugging this may be difficult for anyone who can't
reproduce it, so we'll have to rely on you providing more insight.
Enable more debugging/verbosity in the hypervisor and try again is
probably all I can suggest at this point.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 14:53:55 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 14:53:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaqDD-0000x9-PK; Wed, 14 Dec 2011 14:53:39 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RaqDC-0000wj-S0
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 14:53:39 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1323874361!5344505!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28849 invoked from network); 14 Dec 2011 14:52:41 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-14.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Dec 2011 14:52:41 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 14 Dec 2011 14:52:40 +0000
Message-Id: <4EE8C6460200007800067C32@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 14 Dec 2011 14:52:38 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Liwei" <xieliwei@gmail.com>
References: <CAPE0SYwsqRKDuPTz66r0nTVPYcsFx0Dk2j0pWpCiHELuU5W2iA@mail.gmail.com>
	<4EE881270200007800067A65@nat28.tlf.novell.com>
	<20111214125833.GA51060@ocelot.phlegethon.org>
	<CAPE0SYzJLCjO_9Nt5v7jxuMvbv=DFbGGs41=XANRXujbhAW5Vw@mail.gmail.com>
In-Reply-To: <CAPE0SYzJLCjO_9Nt5v7jxuMvbv=DFbGGs41=XANRXujbhAW5Vw@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Tim Deegan <tim@xen.org>, xen-devel <xen-devel@lists.xensource.com>,
	keir@xen.org, Ian.Campbell@citrix.com
Subject: Re: [Xen-devel] PTE Write access is not set
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 14.12.11 at 15:31, Liwei <xieliwei@gmail.com> wrote:
> ======First instance of VM Crash======
> Guest is openSuSE 11.4 on 2.6.37.6-0.5-desktop
> No symptoms in guest logs, logging just stopped.
> Looking at the serial logs, it appears that the guest just vapourised
> (unless the "First re-creation of guest" below is actually the first
> crash, though Jan and Tim mentioned that that crash couldn't have
> occurred during run-time).
> This VM has one part of the Intel 82575GB (0e:00.1) pass-throughed.
> 
> ++++First re-creation of guest++++
> xl create /etc/xen/vm-test4.cfg
> 
> ----Xen log----
> (XEN) HVM7: ata0-0: PCHS=16383/16/63 translation=lba LCHS=1024/255/63
> (XEN) HVM7: ata0 master: QEMU HARDDISK ATA-7 Hard-Disk ( 160 GBytes)
> (XEN) realmode.c:115:d7 Failed to emulate insn.
> (XEN) realmode.c:165:d7 Real-mode emulation failed @ a8c0:00005a8e: ff
> fa 00 15 99 2c
> (XEN) domain_crash called from realmode.c:166
> 
> ++++Second re-creation of guest++++
> xl create /etc/xen/vm-test4.cfg
> 
> (XEN) HVM8: ata0-0: PCHS=16383/16/63 translation=lba LCHS=1024/255/63
> (XEN) HVM8: ata0 master: QEMU HARDDISK ATA-7 Hard-Disk ( 160 GBytes)
> (XEN) realmode.c:115:d8 Failed to emulate insn.
> (XEN) realmode.c:165:d8 Real-mode emulation failed @ a8c0:0000fcb5: 72
> 5c 1b 80 c4 82
> (XEN) domain_crash called from realmode.c:166
> 
> [Did the same thing a few more times with similar results and gave up,
> rebooted dom0 and all was well]

So this suggests that the virtual firmware has a problem coming back
up with the passed through device still active (and the IOMMU may in
fact be shielding the rest of the system from bad effects of this).

This by itself is a problem, and the sudden death of the guest is
another (particularly if indeed there's no trace of that event in any
logs). Debugging this may be difficult for anyone who can't
reproduce it, so we'll have to rely on you providing more insight.
Enable more debugging/verbosity in the hypervisor and try again is
probably all I can suggest at this point.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 15:01:10 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 15:01:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaqKB-0001HE-Jc; Wed, 14 Dec 2011 15:00:51 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xieliwei@gmail.com>) id 1RaqK9-0001H9-5C
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 15:00:49 +0000
X-Env-Sender: xieliwei@gmail.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1323874744!60726108!1
X-Originating-IP: [209.85.213.43]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19498 invoked from network); 14 Dec 2011 14:59:05 -0000
Received: from mail-yw0-f43.google.com (HELO mail-yw0-f43.google.com)
	(209.85.213.43)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Dec 2011 14:59:05 -0000
Received: by yhr49 with SMTP id 49so26341999yhr.30
	for <xen-devel@lists.xensource.com>;
	Wed, 14 Dec 2011 06:59:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type;
	bh=zx4DN3CGoLZo//WggtLtfrFoyXmloYQTNxbduk3ZpMY=;
	b=dNnFzx3NLzGLhhMN+uPGJ0EE42hmaz6fmaJRMO+SQVZf7DqWUsIm/BaXpJjFPAuC1t
	nXG9FhRrGBiVdRxANpGFcpkx1wEIYNdh3aYRQoHXLd67nQkBu3izB/SGwZ39gWiaL8x4
	pj661Q3NNyG6i2jeztzHSwVpmVM63Zx4fD6r0=
Received: by 10.236.201.194 with SMTP id b42mr12735351yho.32.1323874797418;
	Wed, 14 Dec 2011 06:59:57 -0800 (PST)
MIME-Version: 1.0
Received: by 10.100.10.4 with HTTP; Wed, 14 Dec 2011 06:59:36 -0800 (PST)
In-Reply-To: <4EE8C6460200007800067C32@nat28.tlf.novell.com>
References: <CAPE0SYwsqRKDuPTz66r0nTVPYcsFx0Dk2j0pWpCiHELuU5W2iA@mail.gmail.com>
	<4EE881270200007800067A65@nat28.tlf.novell.com>
	<20111214125833.GA51060@ocelot.phlegethon.org>
	<CAPE0SYzJLCjO_9Nt5v7jxuMvbv=DFbGGs41=XANRXujbhAW5Vw@mail.gmail.com>
	<4EE8C6460200007800067C32@nat28.tlf.novell.com>
From: Liwei <xieliwei@gmail.com>
Date: Wed, 14 Dec 2011 22:59:36 +0800
Message-ID: <CAPE0SYyYELhSPE4WP7mhUZ409Vj6S-sTNYNx0FCiK6AMYOc5yg@mail.gmail.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: Tim Deegan <tim@xen.org>, xen-devel <xen-devel@lists.xensource.com>,
	keir@xen.org, Ian.Campbell@citrix.com
Subject: Re: [Xen-devel] PTE Write access is not set
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 14 December 2011 22:52, Jan Beulich <JBeulich@suse.com> wrote:
>
> So this suggests that the virtual firmware has a problem coming back
> up with the passed through device still active (and the IOMMU may in
> fact be shielding the rest of the system from bad effects of this).
>
> This by itself is a problem, and the sudden death of the guest is
> another (particularly if indeed there's no trace of that event in any
> logs). Debugging this may be difficult for anyone who can't
> reproduce it, so we'll have to rely on you providing more insight.
> Enable more debugging/verbosity in the hypervisor and try again is
> probably all I can suggest at this point.

Currently I have earlyprintk=xen, loglvl=all and guest_loglvl=all.
Other than adding loglevel=10 and debug initcall_debug, what other
options and/or procedures do you suggest?

>
> Jan
>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 15:01:10 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 15:01:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaqKB-0001HE-Jc; Wed, 14 Dec 2011 15:00:51 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xieliwei@gmail.com>) id 1RaqK9-0001H9-5C
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 15:00:49 +0000
X-Env-Sender: xieliwei@gmail.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1323874744!60726108!1
X-Originating-IP: [209.85.213.43]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19498 invoked from network); 14 Dec 2011 14:59:05 -0000
Received: from mail-yw0-f43.google.com (HELO mail-yw0-f43.google.com)
	(209.85.213.43)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Dec 2011 14:59:05 -0000
Received: by yhr49 with SMTP id 49so26341999yhr.30
	for <xen-devel@lists.xensource.com>;
	Wed, 14 Dec 2011 06:59:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type;
	bh=zx4DN3CGoLZo//WggtLtfrFoyXmloYQTNxbduk3ZpMY=;
	b=dNnFzx3NLzGLhhMN+uPGJ0EE42hmaz6fmaJRMO+SQVZf7DqWUsIm/BaXpJjFPAuC1t
	nXG9FhRrGBiVdRxANpGFcpkx1wEIYNdh3aYRQoHXLd67nQkBu3izB/SGwZ39gWiaL8x4
	pj661Q3NNyG6i2jeztzHSwVpmVM63Zx4fD6r0=
Received: by 10.236.201.194 with SMTP id b42mr12735351yho.32.1323874797418;
	Wed, 14 Dec 2011 06:59:57 -0800 (PST)
MIME-Version: 1.0
Received: by 10.100.10.4 with HTTP; Wed, 14 Dec 2011 06:59:36 -0800 (PST)
In-Reply-To: <4EE8C6460200007800067C32@nat28.tlf.novell.com>
References: <CAPE0SYwsqRKDuPTz66r0nTVPYcsFx0Dk2j0pWpCiHELuU5W2iA@mail.gmail.com>
	<4EE881270200007800067A65@nat28.tlf.novell.com>
	<20111214125833.GA51060@ocelot.phlegethon.org>
	<CAPE0SYzJLCjO_9Nt5v7jxuMvbv=DFbGGs41=XANRXujbhAW5Vw@mail.gmail.com>
	<4EE8C6460200007800067C32@nat28.tlf.novell.com>
From: Liwei <xieliwei@gmail.com>
Date: Wed, 14 Dec 2011 22:59:36 +0800
Message-ID: <CAPE0SYyYELhSPE4WP7mhUZ409Vj6S-sTNYNx0FCiK6AMYOc5yg@mail.gmail.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: Tim Deegan <tim@xen.org>, xen-devel <xen-devel@lists.xensource.com>,
	keir@xen.org, Ian.Campbell@citrix.com
Subject: Re: [Xen-devel] PTE Write access is not set
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 14 December 2011 22:52, Jan Beulich <JBeulich@suse.com> wrote:
>
> So this suggests that the virtual firmware has a problem coming back
> up with the passed through device still active (and the IOMMU may in
> fact be shielding the rest of the system from bad effects of this).
>
> This by itself is a problem, and the sudden death of the guest is
> another (particularly if indeed there's no trace of that event in any
> logs). Debugging this may be difficult for anyone who can't
> reproduce it, so we'll have to rely on you providing more insight.
> Enable more debugging/verbosity in the hypervisor and try again is
> probably all I can suggest at this point.

Currently I have earlyprintk=xen, loglvl=all and guest_loglvl=all.
Other than adding loglevel=10 and debug initcall_debug, what other
options and/or procedures do you suggest?

>
> Jan
>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 15:10:04 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 15:10:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaqSc-0001Uk-J5; Wed, 14 Dec 2011 15:09:34 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RaqSa-0001Ub-PJ
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 15:09:32 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1323875317!7352400!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25801 invoked from network); 14 Dec 2011 15:08:37 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-10.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Dec 2011 15:08:37 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 14 Dec 2011 15:08:36 +0000
Message-Id: <4EE8CA030200007800067C6A@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 14 Dec 2011 15:08:35 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>
References: <4EE8AC5A.4050205@citrix.com>
In-Reply-To: <4EE8AC5A.4050205@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] KEXEC fix 32/64bit issues with
 KEXEC_CMD_kexec_get_range
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 14.12.11 at 15:02, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>To fix 32bit Xen which uses 32bit intergers for addresses and sizes,
>change the internals to use xen_kexec64_range_t which will use 64bit
>integers instead.  This also invovles changing several casts to
>explicitly use uint64_ts rather than unsigned longs.

I don't think fixing 32-bit Xen is really necessary: Neither does anyone
care much, nor should any address be beyond 4Gb in that case. Not
playing with this will likely simplify the patch quite a bit.

>--- a/xen/arch/ia64/xen/machine_kexec.c
>+++ b/xen/arch/ia64/xen/machine_kexec.c
>@@ -102,10 +102,10 @@ void machine_reboot_kexec(xen_kexec_imag
> 	machine_kexec(image);
> }
> 
>-int machine_kexec_get_xen(xen_kexec_range_t *range)
>+int machine_kexec_get_xen(xen_kexec64_range_t *range)
> {
> 	range->start = ia64_tpa(_text);
>-	range->size = (unsigned long)_end - (unsigned long)_text;
>+	range->size = (uint64_t)_end - (uint64_t)_text;

This is bogus and pointless (same thing a few lines down the patch).

> 	return 0;
> }
> 
>--- a/xen/arch/x86/x86_32/machine_kexec.c
>+++ b/xen/arch/x86/x86_32/machine_kexec.c
>@@ -11,11 +11,11 @@
> #include <asm/page.h>
> #include <public/kexec.h>
> 
>-int machine_kexec_get_xen(xen_kexec_range_t *range)
>+int machine_kexec_get_xen(xen_kexec64_range_t *range)
> {
>         range->start = virt_to_maddr(_start);
>-        range->size = (unsigned long)xenheap_phys_end -
>-                      (unsigned long)range->start;
>+        range->size = (uint64_t)xenheap_phys_end -

And here it's even wrong, and I doubt it compiles without warning
across the supported range of compilers.

>+                      (uint64_t)range->start;

Casting range->start here and elsewhere shouldn't be necessary at
all (the pre-existing cast was bogus too).

>         return 0;
> }
> 

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 15:10:04 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 15:10:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaqSc-0001Uk-J5; Wed, 14 Dec 2011 15:09:34 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RaqSa-0001Ub-PJ
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 15:09:32 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1323875317!7352400!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25801 invoked from network); 14 Dec 2011 15:08:37 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-10.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Dec 2011 15:08:37 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 14 Dec 2011 15:08:36 +0000
Message-Id: <4EE8CA030200007800067C6A@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 14 Dec 2011 15:08:35 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>
References: <4EE8AC5A.4050205@citrix.com>
In-Reply-To: <4EE8AC5A.4050205@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] KEXEC fix 32/64bit issues with
 KEXEC_CMD_kexec_get_range
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 14.12.11 at 15:02, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>To fix 32bit Xen which uses 32bit intergers for addresses and sizes,
>change the internals to use xen_kexec64_range_t which will use 64bit
>integers instead.  This also invovles changing several casts to
>explicitly use uint64_ts rather than unsigned longs.

I don't think fixing 32-bit Xen is really necessary: Neither does anyone
care much, nor should any address be beyond 4Gb in that case. Not
playing with this will likely simplify the patch quite a bit.

>--- a/xen/arch/ia64/xen/machine_kexec.c
>+++ b/xen/arch/ia64/xen/machine_kexec.c
>@@ -102,10 +102,10 @@ void machine_reboot_kexec(xen_kexec_imag
> 	machine_kexec(image);
> }
> 
>-int machine_kexec_get_xen(xen_kexec_range_t *range)
>+int machine_kexec_get_xen(xen_kexec64_range_t *range)
> {
> 	range->start = ia64_tpa(_text);
>-	range->size = (unsigned long)_end - (unsigned long)_text;
>+	range->size = (uint64_t)_end - (uint64_t)_text;

This is bogus and pointless (same thing a few lines down the patch).

> 	return 0;
> }
> 
>--- a/xen/arch/x86/x86_32/machine_kexec.c
>+++ b/xen/arch/x86/x86_32/machine_kexec.c
>@@ -11,11 +11,11 @@
> #include <asm/page.h>
> #include <public/kexec.h>
> 
>-int machine_kexec_get_xen(xen_kexec_range_t *range)
>+int machine_kexec_get_xen(xen_kexec64_range_t *range)
> {
>         range->start = virt_to_maddr(_start);
>-        range->size = (unsigned long)xenheap_phys_end -
>-                      (unsigned long)range->start;
>+        range->size = (uint64_t)xenheap_phys_end -

And here it's even wrong, and I doubt it compiles without warning
across the supported range of compilers.

>+                      (uint64_t)range->start;

Casting range->start here and elsewhere shouldn't be necessary at
all (the pre-existing cast was bogus too).

>         return 0;
> }
> 

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 15:17:45 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 15:17:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaqZu-0001vu-5c; Wed, 14 Dec 2011 15:17:06 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RaqZs-0001vn-Jw
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 15:17:04 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1323875768!5555012!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19825 invoked from network); 14 Dec 2011 15:16:09 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-6.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Dec 2011 15:16:09 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 14 Dec 2011 15:16:08 +0000
Message-Id: <4EE8CBC60200007800067C78@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 14 Dec 2011 15:16:06 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Liwei" <xieliwei@gmail.com>
References: <CAPE0SYwsqRKDuPTz66r0nTVPYcsFx0Dk2j0pWpCiHELuU5W2iA@mail.gmail.com>
	<4EE881270200007800067A65@nat28.tlf.novell.com>
	<20111214125833.GA51060@ocelot.phlegethon.org>
	<CAPE0SYzJLCjO_9Nt5v7jxuMvbv=DFbGGs41=XANRXujbhAW5Vw@mail.gmail.com>
	<4EE8C6460200007800067C32@nat28.tlf.novell.com>
	<CAPE0SYyYELhSPE4WP7mhUZ409Vj6S-sTNYNx0FCiK6AMYOc5yg@mail.gmail.com>
In-Reply-To: <CAPE0SYyYELhSPE4WP7mhUZ409Vj6S-sTNYNx0FCiK6AMYOc5yg@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Tim Deegan <tim@xen.org>, xen-devel <xen-devel@lists.xensource.com>,
	keir@xen.org, Ian.Campbell@citrix.com
Subject: Re: [Xen-devel] PTE Write access is not set
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 14.12.11 at 15:59, Liwei <xieliwei@gmail.com> wrote:
> On 14 December 2011 22:52, Jan Beulich <JBeulich@suse.com> wrote:
>>
>> So this suggests that the virtual firmware has a problem coming back
>> up with the passed through device still active (and the IOMMU may in
>> fact be shielding the rest of the system from bad effects of this).
>>
>> This by itself is a problem, and the sudden death of the guest is
>> another (particularly if indeed there's no trace of that event in any
>> logs). Debugging this may be difficult for anyone who can't
>> reproduce it, so we'll have to rely on you providing more insight.
>> Enable more debugging/verbosity in the hypervisor and try again is
>> probably all I can suggest at this point.
> 
> Currently I have earlyprintk=xen, loglvl=all and guest_loglvl=all.

"earlyprintk=xen" is completely irrelevant here. For the others, as
I see them commonly misplaced, I'll take the risk of embarrassing you
by asking whether they are on the Xen command line (and not the
kernel one).

> Other than adding loglevel=10 and debug initcall_debug, what other
> options and/or procedures do you suggest?

"hvm_debug=" comes to mind (grep for the various DBG_LEVEL_*
defines and uses to see which one might provide greatest benefit,
and be prepared to go through a lot of data afterwards, though
presumably just the tail is going to be interesting if you make the
guest not immediately restart after death).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 15:17:45 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 15:17:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaqZu-0001vu-5c; Wed, 14 Dec 2011 15:17:06 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RaqZs-0001vn-Jw
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 15:17:04 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1323875768!5555012!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19825 invoked from network); 14 Dec 2011 15:16:09 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-6.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Dec 2011 15:16:09 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 14 Dec 2011 15:16:08 +0000
Message-Id: <4EE8CBC60200007800067C78@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 14 Dec 2011 15:16:06 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Liwei" <xieliwei@gmail.com>
References: <CAPE0SYwsqRKDuPTz66r0nTVPYcsFx0Dk2j0pWpCiHELuU5W2iA@mail.gmail.com>
	<4EE881270200007800067A65@nat28.tlf.novell.com>
	<20111214125833.GA51060@ocelot.phlegethon.org>
	<CAPE0SYzJLCjO_9Nt5v7jxuMvbv=DFbGGs41=XANRXujbhAW5Vw@mail.gmail.com>
	<4EE8C6460200007800067C32@nat28.tlf.novell.com>
	<CAPE0SYyYELhSPE4WP7mhUZ409Vj6S-sTNYNx0FCiK6AMYOc5yg@mail.gmail.com>
In-Reply-To: <CAPE0SYyYELhSPE4WP7mhUZ409Vj6S-sTNYNx0FCiK6AMYOc5yg@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Tim Deegan <tim@xen.org>, xen-devel <xen-devel@lists.xensource.com>,
	keir@xen.org, Ian.Campbell@citrix.com
Subject: Re: [Xen-devel] PTE Write access is not set
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 14.12.11 at 15:59, Liwei <xieliwei@gmail.com> wrote:
> On 14 December 2011 22:52, Jan Beulich <JBeulich@suse.com> wrote:
>>
>> So this suggests that the virtual firmware has a problem coming back
>> up with the passed through device still active (and the IOMMU may in
>> fact be shielding the rest of the system from bad effects of this).
>>
>> This by itself is a problem, and the sudden death of the guest is
>> another (particularly if indeed there's no trace of that event in any
>> logs). Debugging this may be difficult for anyone who can't
>> reproduce it, so we'll have to rely on you providing more insight.
>> Enable more debugging/verbosity in the hypervisor and try again is
>> probably all I can suggest at this point.
> 
> Currently I have earlyprintk=xen, loglvl=all and guest_loglvl=all.

"earlyprintk=xen" is completely irrelevant here. For the others, as
I see them commonly misplaced, I'll take the risk of embarrassing you
by asking whether they are on the Xen command line (and not the
kernel one).

> Other than adding loglevel=10 and debug initcall_debug, what other
> options and/or procedures do you suggest?

"hvm_debug=" comes to mind (grep for the various DBG_LEVEL_*
defines and uses to see which one might provide greatest benefit,
and be prepared to go through a lot of data afterwards, though
presumably just the tail is going to be interesting if you make the
guest not immediately restart after death).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 15:26:37 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 15:26:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Raqij-0002Cp-7C; Wed, 14 Dec 2011 15:26:13 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1Raqih-0002Ci-US
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 15:26:12 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1323876296!58926535!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDYyMDY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31082 invoked from network); 14 Dec 2011 15:24:58 -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;
	14 Dec 2011 15:24:58 -0000
X-IronPort-AV: E=Sophos;i="4.71,352,1320642000"; d="scan'208";a="19957547"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Dec 2011 10:25:15 -0500
Received: from [10.80.2.18] (10.80.2.18) by FTLPMAILMX01.citrite.net
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Wed, 14 Dec 2011
	10:25:14 -0500
Message-ID: <4EE8BFD9.3080208@citrix.com>
Date: Wed, 14 Dec 2011 15:25:13 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.23) Gecko/20110921 Lightning/1.0b2 Thunderbird/3.1.15
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <4EE8AC5A.4050205@citrix.com>
	<4EE8CA030200007800067C6A@nat28.tlf.novell.com>
In-Reply-To: <4EE8CA030200007800067C6A@nat28.tlf.novell.com>
X-Enigmail-Version: 1.1.2
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] KEXEC fix 32/64bit issues with
	KEXEC_CMD_kexec_get_range
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 14/12/11 15:08, Jan Beulich wrote:
>>>> On 14.12.11 at 15:02, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>> To fix 32bit Xen which uses 32bit intergers for addresses and sizes,
>> change the internals to use xen_kexec64_range_t which will use 64bit
>> integers instead.  This also invovles changing several casts to
>> explicitly use uint64_ts rather than unsigned longs.
> I don't think fixing 32-bit Xen is really necessary: Neither does anyone
> care much, nor should any address be beyond 4Gb in that case. Not
> playing with this will likely simplify the patch quite a bit.

This point was discussed on the IRC channel and it was decided to be
worth doing, even though people are likely not to care else I would
happily collapse the patch somewhat.  Why should nothing be beyond 4GB
in the 32bit case? Anything with PAE support ought to be able to use
64GB or less.

>> --- a/xen/arch/ia64/xen/machine_kexec.c
>> +++ b/xen/arch/ia64/xen/machine_kexec.c
>> @@ -102,10 +102,10 @@ void machine_reboot_kexec(xen_kexec_imag
>> 	machine_kexec(image);
>> }
>>
>> -int machine_kexec_get_xen(xen_kexec_range_t *range)
>> +int machine_kexec_get_xen(xen_kexec64_range_t *range)
>> {
>> 	range->start = ia64_tpa(_text);
>> -	range->size = (unsigned long)_end - (unsigned long)_text;
>> +	range->size = (uint64_t)_end - (uint64_t)_text;
> This is bogus and pointless (same thing a few lines down the patch).

I can understand pointless as sizeof(unsigned long) == sizeof(uint64_t)
on 64bit builds, but why is it bogus?  I changed it for consistency with
xen_kexec64_range_t.

>> 	return 0;
>> }
>>
>> --- a/xen/arch/x86/x86_32/machine_kexec.c
>> +++ b/xen/arch/x86/x86_32/machine_kexec.c
>> @@ -11,11 +11,11 @@
>> #include <asm/page.h>
>> #include <public/kexec.h>
>>
>> -int machine_kexec_get_xen(xen_kexec_range_t *range)
>> +int machine_kexec_get_xen(xen_kexec64_range_t *range)
>> {
>>         range->start = virt_to_maddr(_start);
>> -        range->size = (unsigned long)xenheap_phys_end -
>> -                      (unsigned long)range->start;
>> +        range->size = (uint64_t)xenheap_phys_end -
> And here it's even wrong, and I doubt it compiles without warning
> across the supported range of compilers.

Why might there be warnings in this case?  At the worst, all it is doing
is explicitly promoting a 32bit integer to a 64bit.

>> +                      (uint64_t)range->start;
> Casting range->start here and elsewhere shouldn't be necessary at
> all (the pre-existing cast was bogus too).

Agreed, but same comment regarding consistency, with a mix of not
thinking about the implication on my behalf.

>>         return 0;
>> }
>>
> Jan
>

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 15:26:37 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 15:26:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Raqij-0002Cp-7C; Wed, 14 Dec 2011 15:26:13 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1Raqih-0002Ci-US
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 15:26:12 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1323876296!58926535!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDYyMDY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31082 invoked from network); 14 Dec 2011 15:24:58 -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;
	14 Dec 2011 15:24:58 -0000
X-IronPort-AV: E=Sophos;i="4.71,352,1320642000"; d="scan'208";a="19957547"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Dec 2011 10:25:15 -0500
Received: from [10.80.2.18] (10.80.2.18) by FTLPMAILMX01.citrite.net
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Wed, 14 Dec 2011
	10:25:14 -0500
Message-ID: <4EE8BFD9.3080208@citrix.com>
Date: Wed, 14 Dec 2011 15:25:13 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.23) Gecko/20110921 Lightning/1.0b2 Thunderbird/3.1.15
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <4EE8AC5A.4050205@citrix.com>
	<4EE8CA030200007800067C6A@nat28.tlf.novell.com>
In-Reply-To: <4EE8CA030200007800067C6A@nat28.tlf.novell.com>
X-Enigmail-Version: 1.1.2
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] KEXEC fix 32/64bit issues with
	KEXEC_CMD_kexec_get_range
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 14/12/11 15:08, Jan Beulich wrote:
>>>> On 14.12.11 at 15:02, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>> To fix 32bit Xen which uses 32bit intergers for addresses and sizes,
>> change the internals to use xen_kexec64_range_t which will use 64bit
>> integers instead.  This also invovles changing several casts to
>> explicitly use uint64_ts rather than unsigned longs.
> I don't think fixing 32-bit Xen is really necessary: Neither does anyone
> care much, nor should any address be beyond 4Gb in that case. Not
> playing with this will likely simplify the patch quite a bit.

This point was discussed on the IRC channel and it was decided to be
worth doing, even though people are likely not to care else I would
happily collapse the patch somewhat.  Why should nothing be beyond 4GB
in the 32bit case? Anything with PAE support ought to be able to use
64GB or less.

>> --- a/xen/arch/ia64/xen/machine_kexec.c
>> +++ b/xen/arch/ia64/xen/machine_kexec.c
>> @@ -102,10 +102,10 @@ void machine_reboot_kexec(xen_kexec_imag
>> 	machine_kexec(image);
>> }
>>
>> -int machine_kexec_get_xen(xen_kexec_range_t *range)
>> +int machine_kexec_get_xen(xen_kexec64_range_t *range)
>> {
>> 	range->start = ia64_tpa(_text);
>> -	range->size = (unsigned long)_end - (unsigned long)_text;
>> +	range->size = (uint64_t)_end - (uint64_t)_text;
> This is bogus and pointless (same thing a few lines down the patch).

I can understand pointless as sizeof(unsigned long) == sizeof(uint64_t)
on 64bit builds, but why is it bogus?  I changed it for consistency with
xen_kexec64_range_t.

>> 	return 0;
>> }
>>
>> --- a/xen/arch/x86/x86_32/machine_kexec.c
>> +++ b/xen/arch/x86/x86_32/machine_kexec.c
>> @@ -11,11 +11,11 @@
>> #include <asm/page.h>
>> #include <public/kexec.h>
>>
>> -int machine_kexec_get_xen(xen_kexec_range_t *range)
>> +int machine_kexec_get_xen(xen_kexec64_range_t *range)
>> {
>>         range->start = virt_to_maddr(_start);
>> -        range->size = (unsigned long)xenheap_phys_end -
>> -                      (unsigned long)range->start;
>> +        range->size = (uint64_t)xenheap_phys_end -
> And here it's even wrong, and I doubt it compiles without warning
> across the supported range of compilers.

Why might there be warnings in this case?  At the worst, all it is doing
is explicitly promoting a 32bit integer to a 64bit.

>> +                      (uint64_t)range->start;
> Casting range->start here and elsewhere shouldn't be necessary at
> all (the pre-existing cast was bogus too).

Agreed, but same comment regarding consistency, with a mix of not
thinking about the implication on my behalf.

>>         return 0;
>> }
>>
> Jan
>

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 15:33:41 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 15:33:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Raqpd-0002mW-Oz; Wed, 14 Dec 2011 15:33:21 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Raqpc-0002mK-4x
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 15:33:20 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1323876744!7394910!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29799 invoked from network); 14 Dec 2011 15:32:24 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-11.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Dec 2011 15:32:24 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 14 Dec 2011 15:32:24 +0000
Message-Id: <4EE8CF940200007800067CAA@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 14 Dec 2011 15:32:20 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>
References: <4EE8AC5A.4050205@citrix.com>
	<4EE8CA030200007800067C6A@nat28.tlf.novell.com>
	<4EE8BFD9.3080208@citrix.com>
In-Reply-To: <4EE8BFD9.3080208@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] KEXEC fix 32/64bit issues with
 KEXEC_CMD_kexec_get_range
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 14.12.11 at 16:25, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
> On 14/12/11 15:08, Jan Beulich wrote:
>>>>> On 14.12.11 at 15:02, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>>> To fix 32bit Xen which uses 32bit intergers for addresses and sizes,
>>> change the internals to use xen_kexec64_range_t which will use 64bit
>>> integers instead.  This also invovles changing several casts to
>>> explicitly use uint64_ts rather than unsigned longs.
>> I don't think fixing 32-bit Xen is really necessary: Neither does anyone
>> care much, nor should any address be beyond 4Gb in that case. Not
>> playing with this will likely simplify the patch quite a bit.
> 
> This point was discussed on the IRC channel and it was decided to be
> worth doing, even though people are likely not to care else I would
> happily collapse the patch somewhat.  Why should nothing be beyond 4GB
> in the 32bit case? Anything with PAE support ought to be able to use
> 64GB or less.
> 
>>> --- a/xen/arch/ia64/xen/machine_kexec.c
>>> +++ b/xen/arch/ia64/xen/machine_kexec.c
>>> @@ -102,10 +102,10 @@ void machine_reboot_kexec(xen_kexec_imag
>>> 	machine_kexec(image);
>>> }
>>>
>>> -int machine_kexec_get_xen(xen_kexec_range_t *range)
>>> +int machine_kexec_get_xen(xen_kexec64_range_t *range)
>>> {
>>> 	range->start = ia64_tpa(_text);
>>> -	range->size = (unsigned long)_end - (unsigned long)_text;
>>> +	range->size = (uint64_t)_end - (uint64_t)_text;
>> This is bogus and pointless (same thing a few lines down the patch).
> 
> I can understand pointless as sizeof(unsigned long) == sizeof(uint64_t)
> on 64bit builds, but why is it bogus?  I changed it for consistency with
> xen_kexec64_range_t.

Because of the casting of pointers to other than unsigned long.

>>> 	return 0;
>>> }
>>>
>>> --- a/xen/arch/x86/x86_32/machine_kexec.c
>>> +++ b/xen/arch/x86/x86_32/machine_kexec.c
>>> @@ -11,11 +11,11 @@
>>> #include <asm/page.h>
>>> #include <public/kexec.h>
>>>
>>> -int machine_kexec_get_xen(xen_kexec_range_t *range)
>>> +int machine_kexec_get_xen(xen_kexec64_range_t *range)
>>> {
>>>         range->start = virt_to_maddr(_start);
>>> -        range->size = (unsigned long)xenheap_phys_end -
>>> -                      (unsigned long)range->start;
>>> +        range->size = (uint64_t)xenheap_phys_end -
>> And here it's even wrong, and I doubt it compiles without warning
>> across the supported range of compilers.
> 
> Why might there be warnings in this case?  At the worst, all it is doing
> is explicitly promoting a 32bit integer to a 64bit.

Oh, sorry, I somehow thought xenheap_phys_end would be a linker
generated address symbol (mixed it with the various section end ones).
But then - please just remove the casts (and perhaps as a general
cleanup outside of this patch).

Jan

>>> +                      (uint64_t)range->start;
>> Casting range->start here and elsewhere shouldn't be necessary at
>> all (the pre-existing cast was bogus too).
> 
> Agreed, but same comment regarding consistency, with a mix of not
> thinking about the implication on my behalf.
> 
>>>         return 0;
>>> }
>>>
>> Jan
>>
> 
> -- 
> Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
> T: +44 (0)1223 225 900, http://www.citrix.com 




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 15:33:41 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 15:33:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Raqpd-0002mW-Oz; Wed, 14 Dec 2011 15:33:21 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Raqpc-0002mK-4x
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 15:33:20 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1323876744!7394910!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29799 invoked from network); 14 Dec 2011 15:32:24 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-11.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Dec 2011 15:32:24 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 14 Dec 2011 15:32:24 +0000
Message-Id: <4EE8CF940200007800067CAA@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 14 Dec 2011 15:32:20 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>
References: <4EE8AC5A.4050205@citrix.com>
	<4EE8CA030200007800067C6A@nat28.tlf.novell.com>
	<4EE8BFD9.3080208@citrix.com>
In-Reply-To: <4EE8BFD9.3080208@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] KEXEC fix 32/64bit issues with
 KEXEC_CMD_kexec_get_range
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 14.12.11 at 16:25, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
> On 14/12/11 15:08, Jan Beulich wrote:
>>>>> On 14.12.11 at 15:02, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>>> To fix 32bit Xen which uses 32bit intergers for addresses and sizes,
>>> change the internals to use xen_kexec64_range_t which will use 64bit
>>> integers instead.  This also invovles changing several casts to
>>> explicitly use uint64_ts rather than unsigned longs.
>> I don't think fixing 32-bit Xen is really necessary: Neither does anyone
>> care much, nor should any address be beyond 4Gb in that case. Not
>> playing with this will likely simplify the patch quite a bit.
> 
> This point was discussed on the IRC channel and it was decided to be
> worth doing, even though people are likely not to care else I would
> happily collapse the patch somewhat.  Why should nothing be beyond 4GB
> in the 32bit case? Anything with PAE support ought to be able to use
> 64GB or less.
> 
>>> --- a/xen/arch/ia64/xen/machine_kexec.c
>>> +++ b/xen/arch/ia64/xen/machine_kexec.c
>>> @@ -102,10 +102,10 @@ void machine_reboot_kexec(xen_kexec_imag
>>> 	machine_kexec(image);
>>> }
>>>
>>> -int machine_kexec_get_xen(xen_kexec_range_t *range)
>>> +int machine_kexec_get_xen(xen_kexec64_range_t *range)
>>> {
>>> 	range->start = ia64_tpa(_text);
>>> -	range->size = (unsigned long)_end - (unsigned long)_text;
>>> +	range->size = (uint64_t)_end - (uint64_t)_text;
>> This is bogus and pointless (same thing a few lines down the patch).
> 
> I can understand pointless as sizeof(unsigned long) == sizeof(uint64_t)
> on 64bit builds, but why is it bogus?  I changed it for consistency with
> xen_kexec64_range_t.

Because of the casting of pointers to other than unsigned long.

>>> 	return 0;
>>> }
>>>
>>> --- a/xen/arch/x86/x86_32/machine_kexec.c
>>> +++ b/xen/arch/x86/x86_32/machine_kexec.c
>>> @@ -11,11 +11,11 @@
>>> #include <asm/page.h>
>>> #include <public/kexec.h>
>>>
>>> -int machine_kexec_get_xen(xen_kexec_range_t *range)
>>> +int machine_kexec_get_xen(xen_kexec64_range_t *range)
>>> {
>>>         range->start = virt_to_maddr(_start);
>>> -        range->size = (unsigned long)xenheap_phys_end -
>>> -                      (unsigned long)range->start;
>>> +        range->size = (uint64_t)xenheap_phys_end -
>> And here it's even wrong, and I doubt it compiles without warning
>> across the supported range of compilers.
> 
> Why might there be warnings in this case?  At the worst, all it is doing
> is explicitly promoting a 32bit integer to a 64bit.

Oh, sorry, I somehow thought xenheap_phys_end would be a linker
generated address symbol (mixed it with the various section end ones).
But then - please just remove the casts (and perhaps as a general
cleanup outside of this patch).

Jan

>>> +                      (uint64_t)range->start;
>> Casting range->start here and elsewhere shouldn't be necessary at
>> all (the pre-existing cast was bogus too).
> 
> Agreed, but same comment regarding consistency, with a mix of not
> thinking about the implication on my behalf.
> 
>>>         return 0;
>>> }
>>>
>> Jan
>>
> 
> -- 
> Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
> T: +44 (0)1223 225 900, http://www.citrix.com 




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 15:36:31 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 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.xensource.com>)
	id 1Raqsb-00030C-EI; Wed, 14 Dec 2011 15:36:25 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Wang2@amd.com>) id 1RaqsY-0002uc-Ee
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 15:36:22 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1323876926!6728402!1
X-Originating-IP: [213.199.154.144]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8697 invoked from network); 14 Dec 2011 15:35:26 -0000
Received: from db3ehsobe006.messaging.microsoft.com (HELO
	DB3EHSOBE006.bigfish.com) (213.199.154.144)
	by server-13.tower-182.messagelabs.com with AES128-SHA encrypted SMTP;
	14 Dec 2011 15:35:26 -0000
Received: from mail68-db3-R.bigfish.com (10.3.81.241) by
	DB3EHSOBE006.bigfish.com (10.3.84.26) with Microsoft SMTP Server id
	14.1.225.23; Wed, 14 Dec 2011 15:35:28 +0000
Received: from mail68-db3 (localhost [127.0.0.1])	by mail68-db3-R.bigfish.com
	(Postfix) with ESMTP id 5E7235200B5;
	Wed, 14 Dec 2011 15:35:29 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzzz1202hzz8275bhz2dh668h839h944h)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
X-FB-SS: 13,
Received: from mail68-db3 (localhost.localdomain [127.0.0.1]) by mail68-db3
	(MessageSwitch) id 132387692883722_20829;
	Wed, 14 Dec 2011 15:35:28 +0000 (UTC)
Received: from DB3EHSMHS019.bigfish.com (unknown [10.3.81.253])	by
	mail68-db3.bigfish.com (Postfix) with ESMTP id EA56A620067;
	Wed, 14 Dec 2011 15:35:27 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	DB3EHSMHS019.bigfish.com (10.3.87.119) with Microsoft SMTP Server id
	14.1.225.23; Wed, 14 Dec 2011 15:35:22 +0000
X-WSS-ID: 0LW79YT-02-A9M-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp02.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2602DC807C;	Wed, 14 Dec 2011 09:35:16 -0600 (CST)
Received: from SAUSEXDAG02.amd.com (163.181.55.2) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Wed, 14 Dec 2011 09:35:30 -0600
Received: from storexhtp02.amd.com (172.24.4.4) by sausexdag02.amd.com
	(163.181.55.2) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Wed, 14 Dec 2011 09:35:18 -0600
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Wed, 14 Dec 2011
	10:35:16 -0500
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id D95FA49C665; Wed, 14 Dec 2011
	15:35:11 +0000 (GMT)
Received: from gran.amd.com (gran.osrc.amd.com [165.204.15.57])	by
	mail.osrc.amd.com (Postfix) with ESMTP id C41B2594883; Wed, 14 Dec 2011
	16:35:11 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 9a93e064dd3c467ce4b87ddef8739a3573ef547c
Message-ID: <9a93e064dd3c467ce4b8.1323876572@gran.amd.com>
In-Reply-To: <patchbomb.1323876561@gran.amd.com>
References: <patchbomb.1323876561@gran.amd.com>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Wed, 14 Dec 2011 16:29:32 +0100
From: Wei Wang <wei.wang2@amd.com>
To: <JBeulich@suse.com>, <keir@xen.org>
X-OriginatorOrg: amd.com
Cc: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 11 of 16] amd iommu: Add a new flag to
 indication iommuv2 feature enabled or not
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Wei Wang <wei.wang2@amd.com>
# Date 1323875776 -3600
# Node ID 9a93e064dd3c467ce4b87ddef8739a3573ef547c
# Parent  001681ff1a0c09c4d04fd8bd45e8d26805686246
amd iommu: Add a new flag to indication iommuv2 feature enabled or not.
Hypercalls should return early on non-iommuv2 systems.

Signed-off-by: Wei Wang <wei.wang2@amd.com>

diff -r 001681ff1a0c -r 9a93e064dd3c xen/drivers/passthrough/amd/iommu_guest.c
--- a/xen/drivers/passthrough/amd/iommu_guest.c	Wed Dec 14 16:16:15 2011 +0100
+++ b/xen/drivers/passthrough/amd/iommu_guest.c	Wed Dec 14 16:16:16 2011 +0100
@@ -48,6 +48,8 @@
         (reg)->hi = (val >> 32) & 0xFFFFFFFF; \
     } while(0)
 
+extern bool_t iommuv2_enabled;
+
 static unsigned int machine_bdf(struct domain *d, uint16_t guest_bdf)
 {
     struct pci_dev *pdev;
@@ -839,6 +841,9 @@ int guest_iommu_set_base(struct domain *
     p2m_type_t t;
     struct guest_iommu *iommu = domain_iommu(d);
 
+    if ( !is_hvm_domain(d) && !iommuv2_enabled )
+        return 1;
+
     iommu->mmio_base = base;
     base >>= PAGE_SHIFT;
 
@@ -898,7 +903,7 @@ int guest_iommu_init(struct domain* d)
     struct guest_iommu *iommu;
     struct hvm_iommu *hd  = domain_hvm_iommu(d);
 
-    if ( !is_hvm_domain(d) )
+    if ( !is_hvm_domain(d) && !iommuv2_enabled )
         return 0;
 
     iommu = xzalloc(struct guest_iommu);
@@ -940,7 +945,7 @@ void guest_iommu_destroy(struct domain *
 {
     struct guest_iommu *iommu;
 
-    if ( !is_hvm_domain(d) )
+    if ( !is_hvm_domain(d) && !iommuv2_enabled )
         return;
 
     iommu = domain_iommu(d);
@@ -973,7 +978,7 @@ int iommu_bind_bdf(struct domain* d, uin
     struct pci_dev *pdev;
     int ret = -ENODEV;
 
-    if ( !iommu_found() )
+    if ( !iommu_found() || !iommuv2_enabled )
         return 0;
 
     spin_lock(&pcidevs_lock);
@@ -998,7 +1003,7 @@ void iommu_set_msi(struct domain* d, uin
 {
     struct guest_iommu *iommu = domain_iommu(d);
 
-    if ( !iommu_found() )
+    if ( !iommu_found() || !iommuv2_enabled )
         return;
 
     iommu->msi.vector = vector;
diff -r 001681ff1a0c -r 9a93e064dd3c xen/drivers/passthrough/amd/iommu_init.c
--- a/xen/drivers/passthrough/amd/iommu_init.c	Wed Dec 14 16:16:15 2011 +0100
+++ b/xen/drivers/passthrough/amd/iommu_init.c	Wed Dec 14 16:16:16 2011 +0100
@@ -36,6 +36,7 @@ unsigned short ivrs_bdf_entries;
 static struct radix_tree_root ivrs_maps;
 struct list_head amd_iommu_head;
 struct table_struct device_table;
+bool_t iommuv2_enabled;
 
 static int iommu_has_ht_flag(struct amd_iommu *iommu, u8 mask)
 {
@@ -759,6 +760,10 @@ static void enable_iommu(struct amd_iomm
         amd_iommu_flush_all_caches(iommu);
 
     iommu->enabled = 1;
+
+    if ( iommu->features )
+        iommuv2_enabled = 1;
+
     spin_unlock_irqrestore(&iommu->lock, flags);
 
 }


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 15:36:31 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 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.xensource.com>)
	id 1RaqsT-0002v0-V8; Wed, 14 Dec 2011 15:36:17 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Wang2@amd.com>) id 1RaqsS-0002u5-MS
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 15:36:17 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1323876920!5558005!1
X-Originating-IP: [213.199.154.206]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30655 invoked from network); 14 Dec 2011 15:35:20 -0000
Received: from am1ehsobe003.messaging.microsoft.com (HELO
	AM1EHSOBE003.bigfish.com) (213.199.154.206)
	by server-6.tower-174.messagelabs.com with AES128-SHA encrypted SMTP;
	14 Dec 2011 15:35:20 -0000
Received: from mail36-am1-R.bigfish.com (10.3.201.245) by
	AM1EHSOBE003.bigfish.com (10.3.204.23) with Microsoft SMTP Server id
	14.1.225.23; Wed, 14 Dec 2011 15:35:22 +0000
Received: from mail36-am1 (localhost [127.0.0.1])	by mail36-am1-R.bigfish.com
	(Postfix) with ESMTP id 1FBE130028D;
	Wed, 14 Dec 2011 15:35:23 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzzz1202hzz8275bhz2dh668h839h944h)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
Received: from mail36-am1 (localhost.localdomain [127.0.0.1]) by mail36-am1
	(MessageSwitch) id 1323876922773293_15823;
	Wed, 14 Dec 2011 15:35:22 +0000 (UTC)
Received: from AM1EHSMHS004.bigfish.com (unknown [10.3.201.247])	by
	mail36-am1.bigfish.com (Postfix) with ESMTP id AF57C4A0046;
	Wed, 14 Dec 2011 15:35:22 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	AM1EHSMHS004.bigfish.com (10.3.207.104) with Microsoft SMTP Server id
	14.1.225.23; Wed, 14 Dec 2011 15:35:21 +0000
X-WSS-ID: 0LW79YR-02-A99-02
X-M-MSG: 
Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com
	[163.181.249.73])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp02.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 20CEAC808C;	Wed, 14 Dec 2011 09:35:15 -0600 (CST)
Received: from SAUSEXDAG02.amd.com (163.181.55.2) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Wed, 14 Dec 2011 09:35:29 -0600
Received: from storexhtp02.amd.com (172.24.4.4) by sausexdag02.amd.com
	(163.181.55.2) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Wed, 14 Dec 2011 09:35:17 -0600
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Wed, 14 Dec 2011
	10:35:16 -0500
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 80A9C49C661; Wed, 14 Dec 2011
	15:35:11 +0000 (GMT)
Received: from gran.amd.com (gran.osrc.amd.com [165.204.15.57])	by
	mail.osrc.amd.com (Postfix) with ESMTP id 6E383594887; Wed, 14 Dec 2011
	16:35:11 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: ef5698887d044ad58293bee3549eaa20310c2b17
Message-ID: <ef5698887d044ad58293.1323876568@gran.amd.com>
In-Reply-To: <patchbomb.1323876561@gran.amd.com>
References: <patchbomb.1323876561@gran.amd.com>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Wed, 14 Dec 2011 16:29:28 +0100
From: Wei Wang <wei.wang2@amd.com>
To: <JBeulich@suse.com>, <keir@xen.org>
X-OriginatorOrg: amd.com
Cc: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 07 of 16] amd iommu: Add 2 hypercalls for libxc
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Wei Wang <wei.wang2@amd.com>
# Date 1323875772 -3600
# Node ID ef5698887d044ad58293bee3549eaa20310c2b17
# Parent  fbed4e6011fce13d3a521bbc339f4959bf32a06c
amd iommu: Add 2 hypercalls for libxc

iommu_set_msi: used by qemu to inform hypervisor iommu vector number in guest
space. Hypervisor needs this vector to inject msi into guest when PPR logging
happens.

iommu_bind_bdf: used by xl to bind guest bdf number to machine bdf number.
IOMMU emulations codes receives commands from guest iommu driver and forwards
them to host iommu. But virtual device id from guest should be converted into
physical before sending to real hardware.

Signed -off-by: Wei Wang <wei.wang2@amd.com>

diff -r fbed4e6011fc -r ef5698887d04 xen/drivers/passthrough/amd/iommu_guest.c
--- a/xen/drivers/passthrough/amd/iommu_guest.c	Wed Dec 14 16:16:11 2011 +0100
+++ b/xen/drivers/passthrough/amd/iommu_guest.c	Wed Dec 14 16:16:12 2011 +0100
@@ -50,12 +50,27 @@
 
 static unsigned int machine_bdf(struct domain *d, uint16_t guest_bdf)
 {
-    return guest_bdf;
+    struct pci_dev *pdev;
+    uint16_t mbdf = 0;
+
+    for_each_pdev( d, pdev )
+    {
+        if ( pdev->gbdf == guest_bdf )
+        {
+            mbdf = PCI_BDF2(pdev->bus, pdev->devfn);
+            break;
+        }
+    }
+    return mbdf;
 }
 
 static uint16_t guest_bdf(struct domain *d, uint16_t machine_bdf)
 {
-    return machine_bdf;
+    struct pci_dev *pdev;
+
+    pdev = pci_get_pdev_by_domain(d, 0, PCI_BUS(machine_bdf),
+                                  PCI_DEVFN2(machine_bdf));
+    return pdev->gbdf;
 }
 
 static inline struct guest_iommu *domain_iommu(struct domain *d)
@@ -951,3 +966,43 @@ const struct hvm_mmio_handler iommu_mmio
     .read_handler = guest_iommu_mmio_read,
     .write_handler = guest_iommu_mmio_write
 };
+
+/* iommu hypercall handler */
+int iommu_bind_bdf(struct domain* d, uint16_t gbdf, uint16_t mbdf)
+{
+    struct pci_dev *pdev;
+    int ret = -ENODEV;
+
+    if ( !iommu_found() )
+        return 0;
+
+    spin_lock(&pcidevs_lock);
+
+    for_each_pdev( d, pdev )
+    {
+        if ( (pdev->bus != PCI_BUS(mbdf) ) || 
+             (pdev->devfn != PCI_DEVFN2(mbdf)) )
+            continue;
+
+        pdev->gbdf = gbdf;
+        ret = 0;
+    }
+
+    spin_unlock(&pcidevs_lock);
+    return ret;
+}
+
+void iommu_set_msi(struct domain* d, uint16_t vector, uint16_t dest,
+                   uint16_t dest_mode, uint16_t delivery_mode, 
+                   uint16_t trig_mode)
+{
+    struct guest_iommu *iommu = domain_iommu(d);
+
+    if ( !iommu_found() )
+        return;
+
+    iommu->msi.vector = vector;
+    iommu->msi.dest = dest;
+    iommu->msi.dest_mode = dest_mode;
+    iommu->msi.trig_mode = trig_mode;
+}
diff -r fbed4e6011fc -r ef5698887d04 xen/drivers/passthrough/iommu.c
--- a/xen/drivers/passthrough/iommu.c	Wed Dec 14 16:16:11 2011 +0100
+++ b/xen/drivers/passthrough/iommu.c	Wed Dec 14 16:16:12 2011 +0100
@@ -640,6 +640,40 @@ int iommu_do_domctl(
         put_domain(d);
         break;
 
+#ifndef __ia64__ 
+    case XEN_DOMCTL_guest_iommu_op:
+    {
+        xen_domctl_guest_iommu_op_t * guest_op;
+
+        if ( unlikely((d = get_domain_by_id(domctl->domain)) == NULL) )
+        {
+            gdprintk(XENLOG_ERR,
+                    "XEN_DOMCTL_guest_iommu_op: get_domain_by_id() failed\n");
+            ret = -EINVAL;
+            break;
+        }
+
+        guest_op = &(domctl->u.guest_iommu_op);
+        switch ( guest_op->op )
+        {
+            case XEN_DOMCTL_GUEST_IOMMU_OP_SET_MSI:
+                iommu_set_msi(d, guest_op->u.msi.vector, 
+                              guest_op->u.msi.dest,
+                              guest_op->u.msi.dest_mode, 
+                              guest_op->u.msi.delivery_mode,
+                              guest_op->u.msi.trig_mode);
+                ret = 0;
+                break;
+            case XEN_DOMCTL_GUEST_IOMMU_OP_BIND_BDF:
+                ret = iommu_bind_bdf(d, guest_op->u.bdf_bind.g_bdf,
+                                     guest_op->u.bdf_bind.m_bdf);
+                break;
+        }
+        put_domain(d);
+        break;
+    }
+#endif
+
     default:
         ret = -ENOSYS;
         break;
diff -r fbed4e6011fc -r ef5698887d04 xen/include/public/domctl.h
--- a/xen/include/public/domctl.h	Wed Dec 14 16:16:11 2011 +0100
+++ b/xen/include/public/domctl.h	Wed Dec 14 16:16:12 2011 +0100
@@ -848,6 +848,31 @@ struct xen_domctl_set_access_required {
 typedef struct xen_domctl_set_access_required xen_domctl_set_access_required_t;
 DEFINE_XEN_GUEST_HANDLE(xen_domctl_set_access_required_t);
 
+#if defined(__i386__) || defined(__x86_64__)
+/* Support for guest iommu emulation */
+struct xen_domctl_guest_iommu_op {
+    /* XEN_DOMCTL_GUEST_IOMMU_OP_* */
+#define XEN_DOMCTL_GUEST_IOMMU_OP_SET_MSI               0
+#define XEN_DOMCTL_GUEST_IOMMU_OP_BIND_BDF              1
+    uint8_t op;
+    union {
+        struct iommu_msi {
+        uint8_t  vector;
+        uint8_t  dest;
+        uint8_t  dest_mode;
+        uint8_t  delivery_mode;
+        uint8_t  trig_mode;
+        } msi;
+        struct bdf_bind { 
+            uint32_t            g_bdf;
+            uint32_t            m_bdf;
+        } bdf_bind;
+    } u;
+};
+typedef struct xen_domctl_guest_iommu_op xen_domctl_guest_iommu_op_t;
+DEFINE_XEN_GUEST_HANDLE(xen_domctl_guest_iommu_op_t);
+#endif
+
 struct xen_domctl {
     uint32_t cmd;
 #define XEN_DOMCTL_createdomain                   1
@@ -912,6 +937,7 @@ struct xen_domctl {
 #define XEN_DOMCTL_getvcpuextstate               63
 #define XEN_DOMCTL_set_access_required           64
 #define XEN_DOMCTL_audit_p2m                     65
+#define XEN_DOMCTL_guest_iommu_op                66
 #define XEN_DOMCTL_gdbsx_guestmemio            1000
 #define XEN_DOMCTL_gdbsx_pausevcpu             1001
 #define XEN_DOMCTL_gdbsx_unpausevcpu           1002
@@ -963,6 +989,7 @@ struct xen_domctl {
 #if defined(__i386__) || defined(__x86_64__)
         struct xen_domctl_cpuid             cpuid;
         struct xen_domctl_vcpuextstate      vcpuextstate;
+        struct xen_domctl_guest_iommu_op    guest_iommu_op;
 #endif
         struct xen_domctl_set_access_required access_required;
         struct xen_domctl_audit_p2m         audit_p2m;
diff -r fbed4e6011fc -r ef5698887d04 xen/include/xen/iommu.h
--- a/xen/include/xen/iommu.h	Wed Dec 14 16:16:11 2011 +0100
+++ b/xen/include/xen/iommu.h	Wed Dec 14 16:16:12 2011 +0100
@@ -164,6 +164,14 @@ int iommu_do_domctl(struct xen_domctl *,
 void iommu_iotlb_flush(struct domain *d, unsigned long gfn, unsigned int page_count);
 void iommu_iotlb_flush_all(struct domain *d);
 
+#ifndef __ia64_
+/* Only used by AMD IOMMU */
+void iommu_set_msi(struct domain* d, uint16_t vector, uint16_t dest,
+                   uint16_t dest_mode, uint16_t delivery_mode, 
+                   uint16_t trig_mode);
+int iommu_bind_bdf(struct domain* d, uint16_t gbdf, uint16_t mbdf);
+#endif
+
 /*
  * The purpose of the iommu_dont_flush_iotlb optional cpu flag is to
  * avoid unecessary iotlb_flush in the low level IOMMU code.
diff -r fbed4e6011fc -r ef5698887d04 xen/include/xen/pci.h
--- a/xen/include/xen/pci.h	Wed Dec 14 16:16:11 2011 +0100
+++ b/xen/include/xen/pci.h	Wed Dec 14 16:16:12 2011 +0100
@@ -63,6 +63,9 @@ struct pci_dev {
     const u8 devfn;
     struct pci_dev_info info;
     u64 vf_rlen[6];
+
+    /* used by amd iomm to represent bdf value in guest space */
+    u16 gbdf;
 };
 
 #define for_each_pdev(domain, pdev) \


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 15:36:31 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 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.xensource.com>)
	id 1RaqsV-0002vJ-Bw; Wed, 14 Dec 2011 15:36:19 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Wang2@amd.com>) id 1RaqsT-0002uB-Vm
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 15:36:18 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1323876921!7282925!1
X-Originating-IP: [213.199.154.143]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 397 invoked from network); 14 Dec 2011 15:35:22 -0000
Received: from db3ehsobe005.messaging.microsoft.com (HELO
	DB3EHSOBE005.bigfish.com) (213.199.154.143)
	by server-5.tower-182.messagelabs.com with AES128-SHA encrypted SMTP;
	14 Dec 2011 15:35:22 -0000
Received: from mail82-db3-R.bigfish.com (10.3.81.248) by
	DB3EHSOBE005.bigfish.com (10.3.84.25) with Microsoft SMTP Server id
	14.1.225.23; Wed, 14 Dec 2011 15:35:23 +0000
Received: from mail82-db3 (localhost [127.0.0.1])	by mail82-db3-R.bigfish.com
	(Postfix) with ESMTP id BF0B7A0106;
	Wed, 14 Dec 2011 15:35:24 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzzz1202hzz8275bhz2dh668h839h944h)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
X-FB-SS: 13,
Received: from mail82-db3 (localhost.localdomain [127.0.0.1]) by mail82-db3
	(MessageSwitch) id 1323876924640350_13637;
	Wed, 14 Dec 2011 15:35:24 +0000 (UTC)
Received: from DB3EHSMHS011.bigfish.com (unknown [10.3.81.242])	by
	mail82-db3.bigfish.com (Postfix) with ESMTP id 8EEA6C0056;
	Wed, 14 Dec 2011 15:35:24 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	DB3EHSMHS011.bigfish.com (10.3.87.111) with Microsoft SMTP Server id
	14.1.225.23; Wed, 14 Dec 2011 15:35:21 +0000
X-WSS-ID: 0LW79YR-02-A9D-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp02.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2A0FDC807F;	Wed, 14 Dec 2011 09:35:15 -0600 (CST)
Received: from SAUSEXDAG02.amd.com (163.181.55.2) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Wed, 14 Dec 2011 09:35:28 -0600
Received: from storexhtp02.amd.com (172.24.4.4) by sausexdag02.amd.com
	(163.181.55.2) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Wed, 14 Dec 2011 09:35:17 -0600
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Wed, 14 Dec 2011
	10:35:16 -0500
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 491A049C668; Wed, 14 Dec 2011
	15:35:12 +0000 (GMT)
Received: from gran.amd.com (gran.osrc.amd.com [165.204.15.57])	by
	mail.osrc.amd.com (Postfix) with ESMTP id 341AB5940FF; Wed, 14 Dec 2011
	16:35:12 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: f9575683f10a08a86a9c73226581610fa3f7be4b
Message-ID: <f9575683f10a08a86a9c.1323876575@gran.amd.com>
In-Reply-To: <patchbomb.1323876561@gran.amd.com>
References: <patchbomb.1323876561@gran.amd.com>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Wed, 14 Dec 2011 16:29:35 +0100
From: Wei Wang <wei.wang2@amd.com>
To: <JBeulich@suse.com>, <keir@xen.org>
X-OriginatorOrg: amd.com
Cc: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 14 of 16] libxl: bind virtual bdf to physical
 bdf after device assignment
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Wei Wang <wei.wang2@amd.com>
# Date 1323876142 -3600
# Node ID f9575683f10a08a86a9c73226581610fa3f7be4b
# Parent  04573463beff7fc9696f5ecdb940920dcc2ec0ca
libxl: bind virtual bdf to physical bdf after device assignment

Signed-off-by: Wei Wang <wei.wang2@amd.com>

diff -r 04573463beff -r f9575683f10a tools/libxl/libxl_pci.c
--- a/tools/libxl/libxl_pci.c	Wed Dec 14 16:22:21 2011 +0100
+++ b/tools/libxl/libxl_pci.c	Wed Dec 14 16:22:22 2011 +0100
@@ -735,6 +735,13 @@ out:
             LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, rc, "xc_assign_device failed");
             return ERROR_FAIL;
         }
+        if (LIBXL__DOMAIN_IS_TYPE(gc,  domid, HVM)) {
+            rc = xc_domain_bind_pt_bdf(ctx->xch, domid, pcidev->vdevfn, pcidev_encode_bdf(pcidev));
+            if ( rc ) {
+            LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, rc, "xc_domain_bind_pt_bdf failed");
+            return ERROR_FAIL;
+            }
+        }
     }
 
     if (!starting)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 15:36:31 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 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.xensource.com>)
	id 1RaqsX-0002wc-Ml; Wed, 14 Dec 2011 15:36:21 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Wang2@amd.com>) id 1RaqsV-0002uG-MI
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 15:36:20 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1323876922!1945913!1
X-Originating-IP: [213.199.154.139]
X-SpamReason: No, hits=0.0 required=7.0 tests=UPPERCASE_25_50
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1397 invoked from network); 14 Dec 2011 15:35:23 -0000
Received: from db3ehsobe001.messaging.microsoft.com (HELO
	DB3EHSOBE001.bigfish.com) (213.199.154.139)
	by server-5.tower-21.messagelabs.com with AES128-SHA encrypted SMTP;
	14 Dec 2011 15:35:23 -0000
Received: from mail108-db3-R.bigfish.com (10.3.81.242) by
	DB3EHSOBE001.bigfish.com (10.3.84.21) with Microsoft SMTP Server id
	14.1.225.23; Wed, 14 Dec 2011 15:35:25 +0000
Received: from mail108-db3 (localhost [127.0.0.1])	by
	mail108-db3-R.bigfish.com (Postfix) with ESMTP id D882070012D;
	Wed, 14 Dec 2011 15:35:25 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzzz1202hzz8275bhz2dh668h839h944h)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
X-FB-SS: 0,
Received: from mail108-db3 (localhost.localdomain [127.0.0.1]) by mail108-db3
	(MessageSwitch) id 1323876925607838_15233;
	Wed, 14 Dec 2011 15:35:25 +0000 (UTC)
Received: from DB3EHSMHS011.bigfish.com (unknown [10.3.81.241])	by
	mail108-db3.bigfish.com (Postfix) with ESMTP id 8A009600044;
	Wed, 14 Dec 2011 15:35:25 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	DB3EHSMHS011.bigfish.com (10.3.87.111) with Microsoft SMTP Server id
	14.1.225.23; Wed, 14 Dec 2011 15:35:22 +0000
X-WSS-ID: 0LW79YR-01-C4C-02
X-M-MSG: 
Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com
	[163.181.249.73])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2A2B51028053;	Wed, 14 Dec 2011 09:35:15 -0600 (CST)
Received: from SAUSEXDAG01.amd.com (163.181.55.1) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Wed, 14 Dec 2011 09:35:28 -0600
Received: from storexhtp01.amd.com (172.24.4.3) by sausexdag01.amd.com
	(163.181.55.1) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Wed, 14 Dec 2011 09:35:16 -0600
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp01.amd.com
	(172.24.4.3) with Microsoft SMTP Server id 8.3.213.0; Wed, 14 Dec 2011
	10:35:12 -0500
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 218C849C65C; Wed, 14 Dec 2011
	15:35:11 +0000 (GMT)
Received: from gran.amd.com (gran.osrc.amd.com [165.204.15.57])	by
	mail.osrc.amd.com (Postfix) with ESMTP id 0F0AA594883; Wed, 14 Dec 2011
	16:35:11 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: b190e3362524a0e160e9892cd600447cee2a022e
Message-ID: <b190e3362524a0e160e9.1323876563@gran.amd.com>
In-Reply-To: <patchbomb.1323876561@gran.amd.com>
References: <patchbomb.1323876561@gran.amd.com>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Wed, 14 Dec 2011 16:29:23 +0100
From: Wei Wang <wei.wang2@amd.com>
To: <JBeulich@suse.com>, <keir@xen.org>
X-OriginatorOrg: amd.com
Cc: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 02 of 16] amd iommu: Introduces new helper
 functions to simplify iommu bitwise operations
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Wei Wang <wei.wang2@amd.com>
# Date 1323863482 -3600
# Node ID b190e3362524a0e160e9892cd600447cee2a022e
# Parent  a3d2f93d82940a391de00717ddbf842f821fcea5
amd iommu: Introduces new helper functions to simplify iommu bitwise operations

Signed-off-by: Wei Wang <wei.wang2@amd.com

diff -r a3d2f93d8294 -r b190e3362524 xen/drivers/passthrough/amd/iommu_cmd.c
--- a/xen/drivers/passthrough/amd/iommu_cmd.c	Wed Dec 14 12:51:18 2011 +0100
+++ b/xen/drivers/passthrough/amd/iommu_cmd.c	Wed Dec 14 12:51:22 2011 +0100
@@ -33,10 +33,8 @@ static int queue_iommu_command(struct am
     if ( ++tail == iommu->cmd_buffer.entries )
         tail = 0;
 
-    head = get_field_from_reg_u32(readl(iommu->mmio_base + 
-                                        IOMMU_CMD_BUFFER_HEAD_OFFSET),
-                                  IOMMU_CMD_BUFFER_HEAD_MASK,
-                                  IOMMU_CMD_BUFFER_HEAD_SHIFT);
+    head = iommu_get_rb_pointer(readl(iommu->mmio_base + 
+                                      IOMMU_CMD_BUFFER_HEAD_OFFSET));
     if ( head != tail )
     {
         cmd_buffer = (u32 *)(iommu->cmd_buffer.buffer +
@@ -55,11 +53,9 @@ static int queue_iommu_command(struct am
 
 static void commit_iommu_command_buffer(struct amd_iommu *iommu)
 {
-    u32 tail;
+    u32 tail = 0;
 
-    set_field_in_reg_u32(iommu->cmd_buffer.tail, 0,
-                         IOMMU_CMD_BUFFER_TAIL_MASK,
-                         IOMMU_CMD_BUFFER_TAIL_SHIFT, &tail);
+    iommu_set_rb_pointer(&tail, iommu->cmd_buffer.tail);
     writel(tail, iommu->mmio_base+IOMMU_CMD_BUFFER_TAIL_OFFSET);
 }
 
diff -r a3d2f93d8294 -r b190e3362524 xen/drivers/passthrough/amd/iommu_init.c
--- a/xen/drivers/passthrough/amd/iommu_init.c	Wed Dec 14 12:51:18 2011 +0100
+++ b/xen/drivers/passthrough/amd/iommu_init.c	Wed Dec 14 12:51:22 2011 +0100
@@ -106,21 +106,21 @@ static void register_iommu_dev_table_in_
     u64 addr_64, addr_lo, addr_hi;
     u32 entry;
 
+    ASSERT( iommu->dev_table.buffer );
+
     addr_64 = (u64)virt_to_maddr(iommu->dev_table.buffer);
     addr_lo = addr_64 & DMA_32BIT_MASK;
     addr_hi = addr_64 >> 32;
 
-    set_field_in_reg_u32((u32)addr_lo >> PAGE_SHIFT, 0,
-                         IOMMU_DEV_TABLE_BASE_LOW_MASK,
-                         IOMMU_DEV_TABLE_BASE_LOW_SHIFT, &entry);
+    entry = 0;
+    iommu_set_addr_lo_to_reg(&entry, addr_lo >> PAGE_SHIFT);
     set_field_in_reg_u32((iommu->dev_table.alloc_size / PAGE_SIZE) - 1,
                          entry, IOMMU_DEV_TABLE_SIZE_MASK,
                          IOMMU_DEV_TABLE_SIZE_SHIFT, &entry);
     writel(entry, iommu->mmio_base + IOMMU_DEV_TABLE_BASE_LOW_OFFSET);
 
-    set_field_in_reg_u32((u32)addr_hi, 0,
-                         IOMMU_DEV_TABLE_BASE_HIGH_MASK,
-                         IOMMU_DEV_TABLE_BASE_HIGH_SHIFT, &entry);
+    entry = 0;
+    iommu_set_addr_hi_to_reg(&entry, addr_hi);
     writel(entry, iommu->mmio_base + IOMMU_DEV_TABLE_BASE_HIGH_OFFSET);
 }
 
@@ -130,21 +130,21 @@ static void register_iommu_cmd_buffer_in
     u32 power_of2_entries;
     u32 entry;
 
+    ASSERT( iommu->dev_table.buffer );
+
     addr_64 = (u64)virt_to_maddr(iommu->cmd_buffer.buffer);
     addr_lo = addr_64 & DMA_32BIT_MASK;
     addr_hi = addr_64 >> 32;
 
-    set_field_in_reg_u32((u32)addr_lo >> PAGE_SHIFT, 0,
-                         IOMMU_CMD_BUFFER_BASE_LOW_MASK,
-                         IOMMU_CMD_BUFFER_BASE_LOW_SHIFT, &entry);
+    entry = 0;
+    iommu_set_addr_lo_to_reg(&entry, addr_lo >> PAGE_SHIFT);
     writel(entry, iommu->mmio_base + IOMMU_CMD_BUFFER_BASE_LOW_OFFSET);
 
     power_of2_entries = get_order_from_bytes(iommu->cmd_buffer.alloc_size) +
         IOMMU_CMD_BUFFER_POWER_OF2_ENTRIES_PER_PAGE;
 
-    set_field_in_reg_u32((u32)addr_hi, 0,
-                         IOMMU_CMD_BUFFER_BASE_HIGH_MASK,
-                         IOMMU_CMD_BUFFER_BASE_HIGH_SHIFT, &entry);
+    entry = 0;
+    iommu_set_addr_hi_to_reg(&entry, addr_hi);
     set_field_in_reg_u32(power_of2_entries, entry,
                          IOMMU_CMD_BUFFER_LENGTH_MASK,
                          IOMMU_CMD_BUFFER_LENGTH_SHIFT, &entry);
@@ -157,21 +157,21 @@ static void register_iommu_event_log_in_
     u32 power_of2_entries;
     u32 entry;
 
+    ASSERT( iommu->dev_table.buffer );
+
     addr_64 = (u64)virt_to_maddr(iommu->event_log.buffer);
     addr_lo = addr_64 & DMA_32BIT_MASK;
     addr_hi = addr_64 >> 32;
 
-    set_field_in_reg_u32((u32)addr_lo >> PAGE_SHIFT, 0,
-                         IOMMU_EVENT_LOG_BASE_LOW_MASK,
-                         IOMMU_EVENT_LOG_BASE_LOW_SHIFT, &entry);
+    entry = 0;
+    iommu_set_addr_lo_to_reg(&entry, addr_lo >> PAGE_SHIFT);
     writel(entry, iommu->mmio_base + IOMMU_EVENT_LOG_BASE_LOW_OFFSET);
 
     power_of2_entries = get_order_from_bytes(iommu->event_log.alloc_size) +
                         IOMMU_EVENT_LOG_POWER_OF2_ENTRIES_PER_PAGE;
 
-    set_field_in_reg_u32((u32)addr_hi, 0,
-                        IOMMU_EVENT_LOG_BASE_HIGH_MASK,
-                        IOMMU_EVENT_LOG_BASE_HIGH_SHIFT, &entry);
+    entry = 0;
+    iommu_set_addr_hi_to_reg(&entry, addr_hi);
     set_field_in_reg_u32(power_of2_entries, entry,
                         IOMMU_EVENT_LOG_LENGTH_MASK,
                         IOMMU_EVENT_LOG_LENGTH_SHIFT, &entry);
@@ -234,14 +234,12 @@ static void register_iommu_exclusion_ran
     addr_lo = iommu->exclusion_base & DMA_32BIT_MASK;
     addr_hi = iommu->exclusion_base >> 32;
 
-    set_field_in_reg_u32((u32)addr_hi, 0,
-                         IOMMU_EXCLUSION_BASE_HIGH_MASK,
-                         IOMMU_EXCLUSION_BASE_HIGH_SHIFT, &entry);
+    entry = 0;
+    iommu_set_addr_hi_to_reg(&entry, addr_hi);
     writel(entry, iommu->mmio_base+IOMMU_EXCLUSION_BASE_HIGH_OFFSET);
 
-    set_field_in_reg_u32((u32)addr_lo >> PAGE_SHIFT, 0,
-                         IOMMU_EXCLUSION_BASE_LOW_MASK,
-                         IOMMU_EXCLUSION_BASE_LOW_SHIFT, &entry);
+    entry = 0;
+    iommu_set_addr_lo_to_reg(&entry, addr_lo >> PAGE_SHIFT);
 
     set_field_in_reg_u32(iommu->exclusion_allow_all, entry,
                          IOMMU_EXCLUSION_ALLOW_ALL_MASK,
@@ -490,9 +488,7 @@ static void parse_event_log_entry(struct
 
     if ( code == IOMMU_EVENT_IO_PAGE_FAULT )
     {
-        device_id = get_field_from_reg_u32(entry[0],
-                                           IOMMU_EVENT_DEVICE_ID_MASK,
-                                           IOMMU_EVENT_DEVICE_ID_SHIFT);
+        device_id = iommu_get_devid_from_event(entry[0]);
         domain_id = get_field_from_reg_u32(entry[1],
                                            IOMMU_EVENT_DOMAIN_ID_MASK,
                                            IOMMU_EVENT_DOMAIN_ID_SHIFT);
diff -r a3d2f93d8294 -r b190e3362524 xen/include/asm-x86/hvm/svm/amd-iommu-proto.h
--- a/xen/include/asm-x86/hvm/svm/amd-iommu-proto.h	Wed Dec 14 12:51:18 2011 +0100
+++ b/xen/include/asm-x86/hvm/svm/amd-iommu-proto.h	Wed Dec 14 12:51:22 2011 +0100
@@ -191,5 +191,85 @@ static inline int iommu_has_feature(stru
         return 0;
     return !!(iommu->features & (1U << bit));
 }
+/* access tail or head pointer of ring buffer */
+#define IOMMU_RING_BUFFER_PTR_MASK                         0x0007FFF0
+#define IOMMU_RING_BUFFER_PTR_SHIFT                        4
+static inline uint32_t iommu_get_rb_pointer(uint32_t reg)
+{
+    return get_field_from_reg_u32(reg, IOMMU_RING_BUFFER_PTR_MASK, 
+                                  IOMMU_RING_BUFFER_PTR_SHIFT);
+}
+
+static inline void iommu_set_rb_pointer(uint32_t *reg, uint32_t val)
+{
+    set_field_in_reg_u32(val, *reg, IOMMU_RING_BUFFER_PTR_MASK, 
+                         IOMMU_RING_BUFFER_PTR_SHIFT, reg);
+}
+
+/* access device field from iommu cmd */
+#define IOMMU_CMD_DEVICE_ID_MASK           0x0000FFFF
+#define IOMMU_CMD_DEVICE_ID_SHIFT          0
+
+static inline uint16_t iommu_get_devid_from_cmd(uint32_t cmd)
+{
+    return get_field_from_reg_u32(cmd, IOMMU_CMD_DEVICE_ID_MASK, 
+                                  IOMMU_CMD_DEVICE_ID_SHIFT);
+}
+
+static inline void iommu_set_devid_to_cmd(uint32_t *cmd, uint16_t id)
+{
+    set_field_in_reg_u32(id, *cmd, IOMMU_CMD_DEVICE_ID_MASK, 
+                         IOMMU_CMD_DEVICE_ID_SHIFT, cmd);
+}
+
+/* access address field from iommu cmd */
+#define IOMMU_CMD_ADDR_LOW_MASK 0xFFFFF000
+#define IOMMU_CMD_ADDR_LOW_SHIFT    12
+#define IOMMU_CMD_ADDR_HIGH_MASK    0xFFFFFFFF
+#define IOMMU_CMD_ADDR_HIGH_SHIFT   0
+
+static inline uint32_t iommu_get_addr_lo_from_cmd(uint32_t cmd)
+{
+    return get_field_from_reg_u32(cmd, IOMMU_CMD_ADDR_LOW_MASK, 
+                                  IOMMU_CMD_ADDR_LOW_SHIFT);
+}
+
+static inline uint32_t iommu_get_addr_hi_from_cmd(uint32_t cmd)
+{
+    return get_field_from_reg_u32(cmd, IOMMU_CMD_ADDR_LOW_MASK, 
+                                  IOMMU_CMD_ADDR_HIGH_SHIFT);
+}
+
+#define iommu_get_devid_from_event          iommu_get_devid_from_cmd
+
+/* access iommu base addresses from mmio regs */
+#define IOMMU_REG_BASE_ADDR_BASE_LOW_MASK         0xFFFFF000
+#define IOMMU_REG_BASE_ADDR_LOW_SHIFT             12
+#define IOMMU_REG_BASE_ADDR_HIGH_MASK             0x000FFFFF
+#define IOMMU_REG_BASE_ADDR_HIGH_SHIFT            0
+
+static inline void iommu_set_addr_lo_to_reg(uint32_t *reg, uint32_t addr)
+{
+    set_field_in_reg_u32(addr, *reg, IOMMU_REG_BASE_ADDR_BASE_LOW_MASK, 
+                         IOMMU_REG_BASE_ADDR_LOW_SHIFT, reg);
+}
+
+static inline void iommu_set_addr_hi_to_reg(uint32_t *reg, uint32_t addr)
+{
+    set_field_in_reg_u32(addr, *reg, IOMMU_REG_BASE_ADDR_HIGH_MASK, 
+                         IOMMU_REG_BASE_ADDR_HIGH_SHIFT, reg);
+}
+
+static inline uint32_t iommu_get_addr_lo_from_reg(uint32_t reg)
+{
+    return get_field_from_reg_u32(reg, IOMMU_REG_BASE_ADDR_BASE_LOW_MASK, 
+                                  IOMMU_REG_BASE_ADDR_LOW_SHIFT);
+}
+
+static inline uint32_t iommu_get_addr_hi_from_reg(uint32_t reg)
+{
+    return get_field_from_reg_u32(reg, IOMMU_REG_BASE_ADDR_HIGH_MASK, 
+                                  IOMMU_REG_BASE_ADDR_HIGH_SHIFT);
+}
 
 #endif /* _ASM_X86_64_AMD_IOMMU_PROTO_H */


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 15:36:31 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 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.xensource.com>)
	id 1RaqsZ-0002yX-UM; Wed, 14 Dec 2011 15:36:23 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Wang2@amd.com>) id 1RaqsV-0002uJ-Th
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 15:36:20 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1323876923!5527801!1
X-Originating-IP: [213.199.154.204]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29113 invoked from network); 14 Dec 2011 15:35:23 -0000
Received: from am1ehsobe001.messaging.microsoft.com (HELO
	AM1EHSOBE001.bigfish.com) (213.199.154.204)
	by server-2.tower-174.messagelabs.com with AES128-SHA encrypted SMTP;
	14 Dec 2011 15:35:23 -0000
Received: from mail75-am1-R.bigfish.com (10.3.201.243) by
	AM1EHSOBE001.bigfish.com (10.3.204.21) with Microsoft SMTP Server id
	14.1.225.23; Wed, 14 Dec 2011 15:35:25 +0000
Received: from mail75-am1 (localhost [127.0.0.1])	by mail75-am1-R.bigfish.com
	(Postfix) with ESMTP id 2C0C04C0066;
	Wed, 14 Dec 2011 15:35:26 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzzz1202hzz8275bhz2dh668h839h944h)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
Received: from mail75-am1 (localhost.localdomain [127.0.0.1]) by mail75-am1
	(MessageSwitch) id 1323876925884443_3823;
	Wed, 14 Dec 2011 15:35:25 +0000 (UTC)
Received: from AM1EHSMHS009.bigfish.com (unknown [10.3.201.241])	by
	mail75-am1.bigfish.com (Postfix) with ESMTP id C8AA36C0043;
	Wed, 14 Dec 2011 15:35:25 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	AM1EHSMHS009.bigfish.com (10.3.207.109) with Microsoft SMTP Server id
	14.1.225.23; Wed, 14 Dec 2011 15:35:22 +0000
X-WSS-ID: 0LW79YT-02-A9L-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp02.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 28130C8080;	Wed, 14 Dec 2011 09:35:16 -0600 (CST)
Received: from SAUSEXDAG01.amd.com (163.181.55.1) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Wed, 14 Dec 2011 09:35:30 -0600
Received: from storexhtp01.amd.com (172.24.4.3) by sausexdag01.amd.com
	(163.181.55.1) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Wed, 14 Dec 2011 09:35:18 -0600
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp01.amd.com
	(172.24.4.3) with Microsoft SMTP Server id 8.3.213.0; Wed, 14 Dec 2011
	10:35:12 -0500
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 4ECEF49C65E; Wed, 14 Dec 2011
	15:35:11 +0000 (GMT)
Received: from gran.amd.com (gran.osrc.amd.com [165.204.15.57])	by
	mail.osrc.amd.com (Postfix) with ESMTP id 3C940594885; Wed, 14 Dec 2011
	16:35:11 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: d3aa7f936872abacb7e059393fa8963db35c4045
Message-ID: <d3aa7f936872abacb7e0.1323876565@gran.amd.com>
In-Reply-To: <patchbomb.1323876561@gran.amd.com>
References: <patchbomb.1323876561@gran.amd.com>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Wed, 14 Dec 2011 16:29:25 +0100
From: Wei Wang <wei.wang2@amd.com>
To: <JBeulich@suse.com>, <keir@xen.org>
X-OriginatorOrg: amd.com
Cc: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 04 of 16] amd iommu: Enable ppr log
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Wei Wang <wei.wang2@amd.com>
# Date 1323875319 -3600
# Node ID d3aa7f936872abacb7e059393fa8963db35c4045
# Parent  ea52a2b93dffe708084fdc6ee663bd5eee8c1031
amd iommu: Enable ppr log.
IOMMUv2 writes peripheral page service request (PPR) records into ppr log
to report DMA page request from ATS devices to OS.

Signed-off-by: Wei Wang <wei.wang2@amd.com>

diff -r ea52a2b93dff -r d3aa7f936872 xen/drivers/passthrough/amd/iommu_init.c
--- a/xen/drivers/passthrough/amd/iommu_init.c	Wed Dec 14 12:58:17 2011 +0100
+++ b/xen/drivers/passthrough/amd/iommu_init.c	Wed Dec 14 16:08:39 2011 +0100
@@ -178,6 +178,34 @@ static void register_iommu_event_log_in_
     writel(entry, iommu->mmio_base+IOMMU_EVENT_LOG_BASE_HIGH_OFFSET);
 }
 
+static void register_iommu_ppr_log_in_mmio_space(struct amd_iommu *iommu)
+{
+    u64 addr_64, addr_lo, addr_hi;
+    u32 power_of2_entries;
+    u32 entry;
+
+    ASSERT ( iommu->ppr_log.buffer );
+
+    addr_64 = (u64)virt_to_maddr(iommu->ppr_log.buffer);
+    addr_lo = addr_64 & DMA_32BIT_MASK;
+    addr_hi = addr_64 >> 32;
+
+    entry = 0;
+    iommu_set_addr_lo_to_reg(&entry, addr_lo >> PAGE_SHIFT);
+    writel(entry, iommu->mmio_base + IOMMU_PPR_LOG_BASE_LOW_OFFSET);
+
+    power_of2_entries = get_order_from_bytes(iommu->ppr_log.alloc_size) +
+                        IOMMU_PPR_LOG_POWER_OF2_ENTRIES_PER_PAGE;
+
+    entry = 0;
+    iommu_set_addr_hi_to_reg(&entry, addr_hi);
+    set_field_in_reg_u32(power_of2_entries, entry,
+                        IOMMU_PPR_LOG_LENGTH_MASK,
+                        IOMMU_PPR_LOG_LENGTH_SHIFT, &entry);
+    writel(entry, iommu->mmio_base + IOMMU_PPR_LOG_BASE_HIGH_OFFSET);
+}
+
+
 static void set_iommu_translation_control(struct amd_iommu *iommu,
                                                  int enable)
 {
@@ -278,6 +306,35 @@ static void set_iommu_event_log_control(
     writel(entry, iommu->mmio_base + IOMMU_CONTROL_MMIO_OFFSET);
 }
 
+static void set_iommu_ppr_log_control(struct amd_iommu *iommu,
+                                      int enable)
+{
+    u32 entry;
+
+    entry = readl(iommu->mmio_base + IOMMU_CONTROL_MMIO_OFFSET);
+
+    /*reset head and tail pointer manually before enablement */
+    if ( enable )
+    {
+        writel(0x0, iommu->mmio_base + IOMMU_PPR_LOG_HEAD_OFFSET);
+        writel(0x0, iommu->mmio_base + IOMMU_PPR_LOG_TAIL_OFFSET);
+
+        iommu_set_bit(&entry, IOMMU_CONTROL_PPR_ENABLE_SHIFT);
+        iommu_set_bit(&entry, IOMMU_CONTROL_PPR_INT_SHIFT);
+        iommu_set_bit(&entry, IOMMU_CONTROL_PPR_LOG_ENABLE_SHIFT);
+    }
+    else
+    {
+        iommu_clear_bit(&entry, IOMMU_CONTROL_PPR_ENABLE_SHIFT);
+        iommu_clear_bit(&entry, IOMMU_CONTROL_PPR_INT_SHIFT);
+        iommu_clear_bit(&entry, IOMMU_CONTROL_PPR_LOG_ENABLE_SHIFT);
+    }
+
+    writel(entry, iommu->mmio_base + IOMMU_CONTROL_MMIO_OFFSET);
+    if ( enable )
+        AMD_IOMMU_DEBUG("PPR Log Enabled.\n");
+}
+
 static void parse_event_log_entry(struct amd_iommu *, u32 entry[]);
 
 static int amd_iommu_read_event_log(struct amd_iommu *iommu)
@@ -585,12 +642,19 @@ static void enable_iommu(struct amd_iomm
     register_iommu_event_log_in_mmio_space(iommu);
     register_iommu_exclusion_range(iommu);
 
+    if ( iommu_has_feature(iommu, IOMMU_EXT_FEATURE_PPRSUP_SHIFT) )
+        register_iommu_ppr_log_in_mmio_space(iommu);
+
     iommu_msi_set_affinity(irq_to_desc(iommu->irq), &cpu_online_map);
     amd_iommu_msi_enable(iommu, IOMMU_CONTROL_ENABLED);
 
     set_iommu_ht_flags(iommu);
     set_iommu_command_buffer_control(iommu, IOMMU_CONTROL_ENABLED);
     set_iommu_event_log_control(iommu, IOMMU_CONTROL_ENABLED);
+
+    if ( iommu_has_feature(iommu, IOMMU_EXT_FEATURE_PPRSUP_SHIFT) )
+        set_iommu_ppr_log_control(iommu, IOMMU_CONTROL_ENABLED);
+
     set_iommu_translation_control(iommu, IOMMU_CONTROL_ENABLED);
 
     if ( iommu_has_feature(iommu, IOMMU_EXT_FEATURE_IASUP_SHIFT) )
@@ -672,16 +736,29 @@ static void * __init allocate_event_log(
                                 IOMMU_EVENT_LOG_DEFAULT_ENTRIES, "Event Log");
 }
 
+static void * __init allocate_ppr_log(struct amd_iommu *iommu)
+{
+    /* allocate 'ppr log' in power of 2 increments of 4K */
+    return allocate_ring_buffer(&iommu->ppr_log, sizeof(ppr_entry_t),
+                                IOMMU_PPR_LOG_DEFAULT_ENTRIES, "PPR Log");
+}
+
 static int __init amd_iommu_init_one(struct amd_iommu *iommu)
 {
+    if ( map_iommu_mmio_region(iommu) != 0 )
+        goto error_out;
+
+    get_iommu_features(iommu);
+
     if ( allocate_cmd_buffer(iommu) == NULL )
         goto error_out;
 
     if ( allocate_event_log(iommu) == NULL )
         goto error_out;
 
-    if ( map_iommu_mmio_region(iommu) != 0 )
-        goto error_out;
+    if ( iommu_has_feature(iommu, IOMMU_EXT_FEATURE_PPRSUP_SHIFT) )
+        if ( allocate_ppr_log(iommu) == NULL )
+            goto error_out;
 
     if ( set_iommu_interrupt_handler(iommu) == 0 )
         goto error_out;
@@ -694,8 +771,6 @@ static int __init amd_iommu_init_one(str
     iommu->dev_table.entries = device_table.entries;
     iommu->dev_table.buffer = device_table.buffer;
 
-    get_iommu_features(iommu);
-
     enable_iommu(iommu);
     printk("AMD-Vi: IOMMU %d Enabled.\n", nr_amd_iommus );
     nr_amd_iommus++;
@@ -718,6 +793,7 @@ static void __init amd_iommu_init_cleanu
         {
             deallocate_ring_buffer(&iommu->cmd_buffer);
             deallocate_ring_buffer(&iommu->event_log);
+            deallocate_ring_buffer(&iommu->ppr_log);
             unmap_iommu_mmio_region(iommu);
         }
         xfree(iommu);
@@ -916,6 +992,10 @@ static void disable_iommu(struct amd_iom
     amd_iommu_msi_enable(iommu, IOMMU_CONTROL_DISABLED);
     set_iommu_command_buffer_control(iommu, IOMMU_CONTROL_DISABLED);
     set_iommu_event_log_control(iommu, IOMMU_CONTROL_DISABLED);
+
+    if ( iommu_has_feature(iommu, IOMMU_EXT_FEATURE_PPRSUP_SHIFT) )
+        set_iommu_ppr_log_control(iommu, IOMMU_CONTROL_DISABLED);
+
     set_iommu_translation_control(iommu, IOMMU_CONTROL_DISABLED);
 
     iommu->enabled = 0;
diff -r ea52a2b93dff -r d3aa7f936872 xen/include/asm-x86/amd-iommu.h
--- a/xen/include/asm-x86/amd-iommu.h	Wed Dec 14 12:58:17 2011 +0100
+++ b/xen/include/asm-x86/amd-iommu.h	Wed Dec 14 16:08:39 2011 +0100
@@ -94,6 +94,7 @@ struct amd_iommu {
     struct table_struct dev_table;
     struct ring_buffer cmd_buffer;
     struct ring_buffer event_log;
+    struct ring_buffer ppr_log;
 
     int exclusion_enable;
     int exclusion_allow_all;
diff -r ea52a2b93dff -r d3aa7f936872 xen/include/asm-x86/hvm/svm/amd-iommu-defs.h
--- a/xen/include/asm-x86/hvm/svm/amd-iommu-defs.h	Wed Dec 14 12:58:17 2011 +0100
+++ b/xen/include/asm-x86/hvm/svm/amd-iommu-defs.h	Wed Dec 14 16:08:39 2011 +0100
@@ -27,6 +27,9 @@
 /* IOMMU Event Log entries: in power of 2 increments, minimum of 256 */
 #define IOMMU_EVENT_LOG_DEFAULT_ENTRIES     512
 
+/* IOMMU PPR Log entries: in power of 2 increments, minimum of 256 */
+#define IOMMU_PPR_LOG_DEFAULT_ENTRIES       512
+
 #define PTE_PER_TABLE_SHIFT		9
 #define PTE_PER_TABLE_SIZE		(1 << PTE_PER_TABLE_SHIFT)
 #define PTE_PER_TABLE_MASK		(~(PTE_PER_TABLE_SIZE - 1))


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 15:36:31 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 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.xensource.com>)
	id 1Raqsb-00030C-EI; Wed, 14 Dec 2011 15:36:25 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Wang2@amd.com>) id 1RaqsY-0002uc-Ee
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 15:36:22 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1323876926!6728402!1
X-Originating-IP: [213.199.154.144]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8697 invoked from network); 14 Dec 2011 15:35:26 -0000
Received: from db3ehsobe006.messaging.microsoft.com (HELO
	DB3EHSOBE006.bigfish.com) (213.199.154.144)
	by server-13.tower-182.messagelabs.com with AES128-SHA encrypted SMTP;
	14 Dec 2011 15:35:26 -0000
Received: from mail68-db3-R.bigfish.com (10.3.81.241) by
	DB3EHSOBE006.bigfish.com (10.3.84.26) with Microsoft SMTP Server id
	14.1.225.23; Wed, 14 Dec 2011 15:35:28 +0000
Received: from mail68-db3 (localhost [127.0.0.1])	by mail68-db3-R.bigfish.com
	(Postfix) with ESMTP id 5E7235200B5;
	Wed, 14 Dec 2011 15:35:29 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzzz1202hzz8275bhz2dh668h839h944h)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
X-FB-SS: 13,
Received: from mail68-db3 (localhost.localdomain [127.0.0.1]) by mail68-db3
	(MessageSwitch) id 132387692883722_20829;
	Wed, 14 Dec 2011 15:35:28 +0000 (UTC)
Received: from DB3EHSMHS019.bigfish.com (unknown [10.3.81.253])	by
	mail68-db3.bigfish.com (Postfix) with ESMTP id EA56A620067;
	Wed, 14 Dec 2011 15:35:27 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	DB3EHSMHS019.bigfish.com (10.3.87.119) with Microsoft SMTP Server id
	14.1.225.23; Wed, 14 Dec 2011 15:35:22 +0000
X-WSS-ID: 0LW79YT-02-A9M-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp02.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2602DC807C;	Wed, 14 Dec 2011 09:35:16 -0600 (CST)
Received: from SAUSEXDAG02.amd.com (163.181.55.2) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Wed, 14 Dec 2011 09:35:30 -0600
Received: from storexhtp02.amd.com (172.24.4.4) by sausexdag02.amd.com
	(163.181.55.2) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Wed, 14 Dec 2011 09:35:18 -0600
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Wed, 14 Dec 2011
	10:35:16 -0500
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id D95FA49C665; Wed, 14 Dec 2011
	15:35:11 +0000 (GMT)
Received: from gran.amd.com (gran.osrc.amd.com [165.204.15.57])	by
	mail.osrc.amd.com (Postfix) with ESMTP id C41B2594883; Wed, 14 Dec 2011
	16:35:11 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 9a93e064dd3c467ce4b87ddef8739a3573ef547c
Message-ID: <9a93e064dd3c467ce4b8.1323876572@gran.amd.com>
In-Reply-To: <patchbomb.1323876561@gran.amd.com>
References: <patchbomb.1323876561@gran.amd.com>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Wed, 14 Dec 2011 16:29:32 +0100
From: Wei Wang <wei.wang2@amd.com>
To: <JBeulich@suse.com>, <keir@xen.org>
X-OriginatorOrg: amd.com
Cc: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 11 of 16] amd iommu: Add a new flag to
 indication iommuv2 feature enabled or not
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Wei Wang <wei.wang2@amd.com>
# Date 1323875776 -3600
# Node ID 9a93e064dd3c467ce4b87ddef8739a3573ef547c
# Parent  001681ff1a0c09c4d04fd8bd45e8d26805686246
amd iommu: Add a new flag to indication iommuv2 feature enabled or not.
Hypercalls should return early on non-iommuv2 systems.

Signed-off-by: Wei Wang <wei.wang2@amd.com>

diff -r 001681ff1a0c -r 9a93e064dd3c xen/drivers/passthrough/amd/iommu_guest.c
--- a/xen/drivers/passthrough/amd/iommu_guest.c	Wed Dec 14 16:16:15 2011 +0100
+++ b/xen/drivers/passthrough/amd/iommu_guest.c	Wed Dec 14 16:16:16 2011 +0100
@@ -48,6 +48,8 @@
         (reg)->hi = (val >> 32) & 0xFFFFFFFF; \
     } while(0)
 
+extern bool_t iommuv2_enabled;
+
 static unsigned int machine_bdf(struct domain *d, uint16_t guest_bdf)
 {
     struct pci_dev *pdev;
@@ -839,6 +841,9 @@ int guest_iommu_set_base(struct domain *
     p2m_type_t t;
     struct guest_iommu *iommu = domain_iommu(d);
 
+    if ( !is_hvm_domain(d) && !iommuv2_enabled )
+        return 1;
+
     iommu->mmio_base = base;
     base >>= PAGE_SHIFT;
 
@@ -898,7 +903,7 @@ int guest_iommu_init(struct domain* d)
     struct guest_iommu *iommu;
     struct hvm_iommu *hd  = domain_hvm_iommu(d);
 
-    if ( !is_hvm_domain(d) )
+    if ( !is_hvm_domain(d) && !iommuv2_enabled )
         return 0;
 
     iommu = xzalloc(struct guest_iommu);
@@ -940,7 +945,7 @@ void guest_iommu_destroy(struct domain *
 {
     struct guest_iommu *iommu;
 
-    if ( !is_hvm_domain(d) )
+    if ( !is_hvm_domain(d) && !iommuv2_enabled )
         return;
 
     iommu = domain_iommu(d);
@@ -973,7 +978,7 @@ int iommu_bind_bdf(struct domain* d, uin
     struct pci_dev *pdev;
     int ret = -ENODEV;
 
-    if ( !iommu_found() )
+    if ( !iommu_found() || !iommuv2_enabled )
         return 0;
 
     spin_lock(&pcidevs_lock);
@@ -998,7 +1003,7 @@ void iommu_set_msi(struct domain* d, uin
 {
     struct guest_iommu *iommu = domain_iommu(d);
 
-    if ( !iommu_found() )
+    if ( !iommu_found() || !iommuv2_enabled )
         return;
 
     iommu->msi.vector = vector;
diff -r 001681ff1a0c -r 9a93e064dd3c xen/drivers/passthrough/amd/iommu_init.c
--- a/xen/drivers/passthrough/amd/iommu_init.c	Wed Dec 14 16:16:15 2011 +0100
+++ b/xen/drivers/passthrough/amd/iommu_init.c	Wed Dec 14 16:16:16 2011 +0100
@@ -36,6 +36,7 @@ unsigned short ivrs_bdf_entries;
 static struct radix_tree_root ivrs_maps;
 struct list_head amd_iommu_head;
 struct table_struct device_table;
+bool_t iommuv2_enabled;
 
 static int iommu_has_ht_flag(struct amd_iommu *iommu, u8 mask)
 {
@@ -759,6 +760,10 @@ static void enable_iommu(struct amd_iomm
         amd_iommu_flush_all_caches(iommu);
 
     iommu->enabled = 1;
+
+    if ( iommu->features )
+        iommuv2_enabled = 1;
+
     spin_unlock_irqrestore(&iommu->lock, flags);
 
 }


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 15:36:31 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 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.xensource.com>)
	id 1RaqsZ-0002yX-UM; Wed, 14 Dec 2011 15:36:23 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Wang2@amd.com>) id 1RaqsV-0002uJ-Th
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 15:36:20 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1323876923!5527801!1
X-Originating-IP: [213.199.154.204]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29113 invoked from network); 14 Dec 2011 15:35:23 -0000
Received: from am1ehsobe001.messaging.microsoft.com (HELO
	AM1EHSOBE001.bigfish.com) (213.199.154.204)
	by server-2.tower-174.messagelabs.com with AES128-SHA encrypted SMTP;
	14 Dec 2011 15:35:23 -0000
Received: from mail75-am1-R.bigfish.com (10.3.201.243) by
	AM1EHSOBE001.bigfish.com (10.3.204.21) with Microsoft SMTP Server id
	14.1.225.23; Wed, 14 Dec 2011 15:35:25 +0000
Received: from mail75-am1 (localhost [127.0.0.1])	by mail75-am1-R.bigfish.com
	(Postfix) with ESMTP id 2C0C04C0066;
	Wed, 14 Dec 2011 15:35:26 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzzz1202hzz8275bhz2dh668h839h944h)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
Received: from mail75-am1 (localhost.localdomain [127.0.0.1]) by mail75-am1
	(MessageSwitch) id 1323876925884443_3823;
	Wed, 14 Dec 2011 15:35:25 +0000 (UTC)
Received: from AM1EHSMHS009.bigfish.com (unknown [10.3.201.241])	by
	mail75-am1.bigfish.com (Postfix) with ESMTP id C8AA36C0043;
	Wed, 14 Dec 2011 15:35:25 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	AM1EHSMHS009.bigfish.com (10.3.207.109) with Microsoft SMTP Server id
	14.1.225.23; Wed, 14 Dec 2011 15:35:22 +0000
X-WSS-ID: 0LW79YT-02-A9L-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp02.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 28130C8080;	Wed, 14 Dec 2011 09:35:16 -0600 (CST)
Received: from SAUSEXDAG01.amd.com (163.181.55.1) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Wed, 14 Dec 2011 09:35:30 -0600
Received: from storexhtp01.amd.com (172.24.4.3) by sausexdag01.amd.com
	(163.181.55.1) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Wed, 14 Dec 2011 09:35:18 -0600
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp01.amd.com
	(172.24.4.3) with Microsoft SMTP Server id 8.3.213.0; Wed, 14 Dec 2011
	10:35:12 -0500
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 4ECEF49C65E; Wed, 14 Dec 2011
	15:35:11 +0000 (GMT)
Received: from gran.amd.com (gran.osrc.amd.com [165.204.15.57])	by
	mail.osrc.amd.com (Postfix) with ESMTP id 3C940594885; Wed, 14 Dec 2011
	16:35:11 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: d3aa7f936872abacb7e059393fa8963db35c4045
Message-ID: <d3aa7f936872abacb7e0.1323876565@gran.amd.com>
In-Reply-To: <patchbomb.1323876561@gran.amd.com>
References: <patchbomb.1323876561@gran.amd.com>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Wed, 14 Dec 2011 16:29:25 +0100
From: Wei Wang <wei.wang2@amd.com>
To: <JBeulich@suse.com>, <keir@xen.org>
X-OriginatorOrg: amd.com
Cc: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 04 of 16] amd iommu: Enable ppr log
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Wei Wang <wei.wang2@amd.com>
# Date 1323875319 -3600
# Node ID d3aa7f936872abacb7e059393fa8963db35c4045
# Parent  ea52a2b93dffe708084fdc6ee663bd5eee8c1031
amd iommu: Enable ppr log.
IOMMUv2 writes peripheral page service request (PPR) records into ppr log
to report DMA page request from ATS devices to OS.

Signed-off-by: Wei Wang <wei.wang2@amd.com>

diff -r ea52a2b93dff -r d3aa7f936872 xen/drivers/passthrough/amd/iommu_init.c
--- a/xen/drivers/passthrough/amd/iommu_init.c	Wed Dec 14 12:58:17 2011 +0100
+++ b/xen/drivers/passthrough/amd/iommu_init.c	Wed Dec 14 16:08:39 2011 +0100
@@ -178,6 +178,34 @@ static void register_iommu_event_log_in_
     writel(entry, iommu->mmio_base+IOMMU_EVENT_LOG_BASE_HIGH_OFFSET);
 }
 
+static void register_iommu_ppr_log_in_mmio_space(struct amd_iommu *iommu)
+{
+    u64 addr_64, addr_lo, addr_hi;
+    u32 power_of2_entries;
+    u32 entry;
+
+    ASSERT ( iommu->ppr_log.buffer );
+
+    addr_64 = (u64)virt_to_maddr(iommu->ppr_log.buffer);
+    addr_lo = addr_64 & DMA_32BIT_MASK;
+    addr_hi = addr_64 >> 32;
+
+    entry = 0;
+    iommu_set_addr_lo_to_reg(&entry, addr_lo >> PAGE_SHIFT);
+    writel(entry, iommu->mmio_base + IOMMU_PPR_LOG_BASE_LOW_OFFSET);
+
+    power_of2_entries = get_order_from_bytes(iommu->ppr_log.alloc_size) +
+                        IOMMU_PPR_LOG_POWER_OF2_ENTRIES_PER_PAGE;
+
+    entry = 0;
+    iommu_set_addr_hi_to_reg(&entry, addr_hi);
+    set_field_in_reg_u32(power_of2_entries, entry,
+                        IOMMU_PPR_LOG_LENGTH_MASK,
+                        IOMMU_PPR_LOG_LENGTH_SHIFT, &entry);
+    writel(entry, iommu->mmio_base + IOMMU_PPR_LOG_BASE_HIGH_OFFSET);
+}
+
+
 static void set_iommu_translation_control(struct amd_iommu *iommu,
                                                  int enable)
 {
@@ -278,6 +306,35 @@ static void set_iommu_event_log_control(
     writel(entry, iommu->mmio_base + IOMMU_CONTROL_MMIO_OFFSET);
 }
 
+static void set_iommu_ppr_log_control(struct amd_iommu *iommu,
+                                      int enable)
+{
+    u32 entry;
+
+    entry = readl(iommu->mmio_base + IOMMU_CONTROL_MMIO_OFFSET);
+
+    /*reset head and tail pointer manually before enablement */
+    if ( enable )
+    {
+        writel(0x0, iommu->mmio_base + IOMMU_PPR_LOG_HEAD_OFFSET);
+        writel(0x0, iommu->mmio_base + IOMMU_PPR_LOG_TAIL_OFFSET);
+
+        iommu_set_bit(&entry, IOMMU_CONTROL_PPR_ENABLE_SHIFT);
+        iommu_set_bit(&entry, IOMMU_CONTROL_PPR_INT_SHIFT);
+        iommu_set_bit(&entry, IOMMU_CONTROL_PPR_LOG_ENABLE_SHIFT);
+    }
+    else
+    {
+        iommu_clear_bit(&entry, IOMMU_CONTROL_PPR_ENABLE_SHIFT);
+        iommu_clear_bit(&entry, IOMMU_CONTROL_PPR_INT_SHIFT);
+        iommu_clear_bit(&entry, IOMMU_CONTROL_PPR_LOG_ENABLE_SHIFT);
+    }
+
+    writel(entry, iommu->mmio_base + IOMMU_CONTROL_MMIO_OFFSET);
+    if ( enable )
+        AMD_IOMMU_DEBUG("PPR Log Enabled.\n");
+}
+
 static void parse_event_log_entry(struct amd_iommu *, u32 entry[]);
 
 static int amd_iommu_read_event_log(struct amd_iommu *iommu)
@@ -585,12 +642,19 @@ static void enable_iommu(struct amd_iomm
     register_iommu_event_log_in_mmio_space(iommu);
     register_iommu_exclusion_range(iommu);
 
+    if ( iommu_has_feature(iommu, IOMMU_EXT_FEATURE_PPRSUP_SHIFT) )
+        register_iommu_ppr_log_in_mmio_space(iommu);
+
     iommu_msi_set_affinity(irq_to_desc(iommu->irq), &cpu_online_map);
     amd_iommu_msi_enable(iommu, IOMMU_CONTROL_ENABLED);
 
     set_iommu_ht_flags(iommu);
     set_iommu_command_buffer_control(iommu, IOMMU_CONTROL_ENABLED);
     set_iommu_event_log_control(iommu, IOMMU_CONTROL_ENABLED);
+
+    if ( iommu_has_feature(iommu, IOMMU_EXT_FEATURE_PPRSUP_SHIFT) )
+        set_iommu_ppr_log_control(iommu, IOMMU_CONTROL_ENABLED);
+
     set_iommu_translation_control(iommu, IOMMU_CONTROL_ENABLED);
 
     if ( iommu_has_feature(iommu, IOMMU_EXT_FEATURE_IASUP_SHIFT) )
@@ -672,16 +736,29 @@ static void * __init allocate_event_log(
                                 IOMMU_EVENT_LOG_DEFAULT_ENTRIES, "Event Log");
 }
 
+static void * __init allocate_ppr_log(struct amd_iommu *iommu)
+{
+    /* allocate 'ppr log' in power of 2 increments of 4K */
+    return allocate_ring_buffer(&iommu->ppr_log, sizeof(ppr_entry_t),
+                                IOMMU_PPR_LOG_DEFAULT_ENTRIES, "PPR Log");
+}
+
 static int __init amd_iommu_init_one(struct amd_iommu *iommu)
 {
+    if ( map_iommu_mmio_region(iommu) != 0 )
+        goto error_out;
+
+    get_iommu_features(iommu);
+
     if ( allocate_cmd_buffer(iommu) == NULL )
         goto error_out;
 
     if ( allocate_event_log(iommu) == NULL )
         goto error_out;
 
-    if ( map_iommu_mmio_region(iommu) != 0 )
-        goto error_out;
+    if ( iommu_has_feature(iommu, IOMMU_EXT_FEATURE_PPRSUP_SHIFT) )
+        if ( allocate_ppr_log(iommu) == NULL )
+            goto error_out;
 
     if ( set_iommu_interrupt_handler(iommu) == 0 )
         goto error_out;
@@ -694,8 +771,6 @@ static int __init amd_iommu_init_one(str
     iommu->dev_table.entries = device_table.entries;
     iommu->dev_table.buffer = device_table.buffer;
 
-    get_iommu_features(iommu);
-
     enable_iommu(iommu);
     printk("AMD-Vi: IOMMU %d Enabled.\n", nr_amd_iommus );
     nr_amd_iommus++;
@@ -718,6 +793,7 @@ static void __init amd_iommu_init_cleanu
         {
             deallocate_ring_buffer(&iommu->cmd_buffer);
             deallocate_ring_buffer(&iommu->event_log);
+            deallocate_ring_buffer(&iommu->ppr_log);
             unmap_iommu_mmio_region(iommu);
         }
         xfree(iommu);
@@ -916,6 +992,10 @@ static void disable_iommu(struct amd_iom
     amd_iommu_msi_enable(iommu, IOMMU_CONTROL_DISABLED);
     set_iommu_command_buffer_control(iommu, IOMMU_CONTROL_DISABLED);
     set_iommu_event_log_control(iommu, IOMMU_CONTROL_DISABLED);
+
+    if ( iommu_has_feature(iommu, IOMMU_EXT_FEATURE_PPRSUP_SHIFT) )
+        set_iommu_ppr_log_control(iommu, IOMMU_CONTROL_DISABLED);
+
     set_iommu_translation_control(iommu, IOMMU_CONTROL_DISABLED);
 
     iommu->enabled = 0;
diff -r ea52a2b93dff -r d3aa7f936872 xen/include/asm-x86/amd-iommu.h
--- a/xen/include/asm-x86/amd-iommu.h	Wed Dec 14 12:58:17 2011 +0100
+++ b/xen/include/asm-x86/amd-iommu.h	Wed Dec 14 16:08:39 2011 +0100
@@ -94,6 +94,7 @@ struct amd_iommu {
     struct table_struct dev_table;
     struct ring_buffer cmd_buffer;
     struct ring_buffer event_log;
+    struct ring_buffer ppr_log;
 
     int exclusion_enable;
     int exclusion_allow_all;
diff -r ea52a2b93dff -r d3aa7f936872 xen/include/asm-x86/hvm/svm/amd-iommu-defs.h
--- a/xen/include/asm-x86/hvm/svm/amd-iommu-defs.h	Wed Dec 14 12:58:17 2011 +0100
+++ b/xen/include/asm-x86/hvm/svm/amd-iommu-defs.h	Wed Dec 14 16:08:39 2011 +0100
@@ -27,6 +27,9 @@
 /* IOMMU Event Log entries: in power of 2 increments, minimum of 256 */
 #define IOMMU_EVENT_LOG_DEFAULT_ENTRIES     512
 
+/* IOMMU PPR Log entries: in power of 2 increments, minimum of 256 */
+#define IOMMU_PPR_LOG_DEFAULT_ENTRIES       512
+
 #define PTE_PER_TABLE_SHIFT		9
 #define PTE_PER_TABLE_SIZE		(1 << PTE_PER_TABLE_SHIFT)
 #define PTE_PER_TABLE_MASK		(~(PTE_PER_TABLE_SIZE - 1))


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 15:36:31 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 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.xensource.com>)
	id 1RaqsV-0002vJ-Bw; Wed, 14 Dec 2011 15:36:19 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Wang2@amd.com>) id 1RaqsT-0002uB-Vm
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 15:36:18 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1323876921!7282925!1
X-Originating-IP: [213.199.154.143]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 397 invoked from network); 14 Dec 2011 15:35:22 -0000
Received: from db3ehsobe005.messaging.microsoft.com (HELO
	DB3EHSOBE005.bigfish.com) (213.199.154.143)
	by server-5.tower-182.messagelabs.com with AES128-SHA encrypted SMTP;
	14 Dec 2011 15:35:22 -0000
Received: from mail82-db3-R.bigfish.com (10.3.81.248) by
	DB3EHSOBE005.bigfish.com (10.3.84.25) with Microsoft SMTP Server id
	14.1.225.23; Wed, 14 Dec 2011 15:35:23 +0000
Received: from mail82-db3 (localhost [127.0.0.1])	by mail82-db3-R.bigfish.com
	(Postfix) with ESMTP id BF0B7A0106;
	Wed, 14 Dec 2011 15:35:24 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzzz1202hzz8275bhz2dh668h839h944h)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
X-FB-SS: 13,
Received: from mail82-db3 (localhost.localdomain [127.0.0.1]) by mail82-db3
	(MessageSwitch) id 1323876924640350_13637;
	Wed, 14 Dec 2011 15:35:24 +0000 (UTC)
Received: from DB3EHSMHS011.bigfish.com (unknown [10.3.81.242])	by
	mail82-db3.bigfish.com (Postfix) with ESMTP id 8EEA6C0056;
	Wed, 14 Dec 2011 15:35:24 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	DB3EHSMHS011.bigfish.com (10.3.87.111) with Microsoft SMTP Server id
	14.1.225.23; Wed, 14 Dec 2011 15:35:21 +0000
X-WSS-ID: 0LW79YR-02-A9D-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp02.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2A0FDC807F;	Wed, 14 Dec 2011 09:35:15 -0600 (CST)
Received: from SAUSEXDAG02.amd.com (163.181.55.2) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Wed, 14 Dec 2011 09:35:28 -0600
Received: from storexhtp02.amd.com (172.24.4.4) by sausexdag02.amd.com
	(163.181.55.2) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Wed, 14 Dec 2011 09:35:17 -0600
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Wed, 14 Dec 2011
	10:35:16 -0500
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 491A049C668; Wed, 14 Dec 2011
	15:35:12 +0000 (GMT)
Received: from gran.amd.com (gran.osrc.amd.com [165.204.15.57])	by
	mail.osrc.amd.com (Postfix) with ESMTP id 341AB5940FF; Wed, 14 Dec 2011
	16:35:12 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: f9575683f10a08a86a9c73226581610fa3f7be4b
Message-ID: <f9575683f10a08a86a9c.1323876575@gran.amd.com>
In-Reply-To: <patchbomb.1323876561@gran.amd.com>
References: <patchbomb.1323876561@gran.amd.com>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Wed, 14 Dec 2011 16:29:35 +0100
From: Wei Wang <wei.wang2@amd.com>
To: <JBeulich@suse.com>, <keir@xen.org>
X-OriginatorOrg: amd.com
Cc: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 14 of 16] libxl: bind virtual bdf to physical
 bdf after device assignment
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Wei Wang <wei.wang2@amd.com>
# Date 1323876142 -3600
# Node ID f9575683f10a08a86a9c73226581610fa3f7be4b
# Parent  04573463beff7fc9696f5ecdb940920dcc2ec0ca
libxl: bind virtual bdf to physical bdf after device assignment

Signed-off-by: Wei Wang <wei.wang2@amd.com>

diff -r 04573463beff -r f9575683f10a tools/libxl/libxl_pci.c
--- a/tools/libxl/libxl_pci.c	Wed Dec 14 16:22:21 2011 +0100
+++ b/tools/libxl/libxl_pci.c	Wed Dec 14 16:22:22 2011 +0100
@@ -735,6 +735,13 @@ out:
             LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, rc, "xc_assign_device failed");
             return ERROR_FAIL;
         }
+        if (LIBXL__DOMAIN_IS_TYPE(gc,  domid, HVM)) {
+            rc = xc_domain_bind_pt_bdf(ctx->xch, domid, pcidev->vdevfn, pcidev_encode_bdf(pcidev));
+            if ( rc ) {
+            LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, rc, "xc_domain_bind_pt_bdf failed");
+            return ERROR_FAIL;
+            }
+        }
     }
 
     if (!starting)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 15:36:31 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 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.xensource.com>)
	id 1RaqsX-0002wc-Ml; Wed, 14 Dec 2011 15:36:21 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Wang2@amd.com>) id 1RaqsV-0002uG-MI
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 15:36:20 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1323876922!1945913!1
X-Originating-IP: [213.199.154.139]
X-SpamReason: No, hits=0.0 required=7.0 tests=UPPERCASE_25_50
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1397 invoked from network); 14 Dec 2011 15:35:23 -0000
Received: from db3ehsobe001.messaging.microsoft.com (HELO
	DB3EHSOBE001.bigfish.com) (213.199.154.139)
	by server-5.tower-21.messagelabs.com with AES128-SHA encrypted SMTP;
	14 Dec 2011 15:35:23 -0000
Received: from mail108-db3-R.bigfish.com (10.3.81.242) by
	DB3EHSOBE001.bigfish.com (10.3.84.21) with Microsoft SMTP Server id
	14.1.225.23; Wed, 14 Dec 2011 15:35:25 +0000
Received: from mail108-db3 (localhost [127.0.0.1])	by
	mail108-db3-R.bigfish.com (Postfix) with ESMTP id D882070012D;
	Wed, 14 Dec 2011 15:35:25 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzzz1202hzz8275bhz2dh668h839h944h)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
X-FB-SS: 0,
Received: from mail108-db3 (localhost.localdomain [127.0.0.1]) by mail108-db3
	(MessageSwitch) id 1323876925607838_15233;
	Wed, 14 Dec 2011 15:35:25 +0000 (UTC)
Received: from DB3EHSMHS011.bigfish.com (unknown [10.3.81.241])	by
	mail108-db3.bigfish.com (Postfix) with ESMTP id 8A009600044;
	Wed, 14 Dec 2011 15:35:25 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	DB3EHSMHS011.bigfish.com (10.3.87.111) with Microsoft SMTP Server id
	14.1.225.23; Wed, 14 Dec 2011 15:35:22 +0000
X-WSS-ID: 0LW79YR-01-C4C-02
X-M-MSG: 
Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com
	[163.181.249.73])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2A2B51028053;	Wed, 14 Dec 2011 09:35:15 -0600 (CST)
Received: from SAUSEXDAG01.amd.com (163.181.55.1) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Wed, 14 Dec 2011 09:35:28 -0600
Received: from storexhtp01.amd.com (172.24.4.3) by sausexdag01.amd.com
	(163.181.55.1) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Wed, 14 Dec 2011 09:35:16 -0600
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp01.amd.com
	(172.24.4.3) with Microsoft SMTP Server id 8.3.213.0; Wed, 14 Dec 2011
	10:35:12 -0500
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 218C849C65C; Wed, 14 Dec 2011
	15:35:11 +0000 (GMT)
Received: from gran.amd.com (gran.osrc.amd.com [165.204.15.57])	by
	mail.osrc.amd.com (Postfix) with ESMTP id 0F0AA594883; Wed, 14 Dec 2011
	16:35:11 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: b190e3362524a0e160e9892cd600447cee2a022e
Message-ID: <b190e3362524a0e160e9.1323876563@gran.amd.com>
In-Reply-To: <patchbomb.1323876561@gran.amd.com>
References: <patchbomb.1323876561@gran.amd.com>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Wed, 14 Dec 2011 16:29:23 +0100
From: Wei Wang <wei.wang2@amd.com>
To: <JBeulich@suse.com>, <keir@xen.org>
X-OriginatorOrg: amd.com
Cc: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 02 of 16] amd iommu: Introduces new helper
 functions to simplify iommu bitwise operations
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Wei Wang <wei.wang2@amd.com>
# Date 1323863482 -3600
# Node ID b190e3362524a0e160e9892cd600447cee2a022e
# Parent  a3d2f93d82940a391de00717ddbf842f821fcea5
amd iommu: Introduces new helper functions to simplify iommu bitwise operations

Signed-off-by: Wei Wang <wei.wang2@amd.com

diff -r a3d2f93d8294 -r b190e3362524 xen/drivers/passthrough/amd/iommu_cmd.c
--- a/xen/drivers/passthrough/amd/iommu_cmd.c	Wed Dec 14 12:51:18 2011 +0100
+++ b/xen/drivers/passthrough/amd/iommu_cmd.c	Wed Dec 14 12:51:22 2011 +0100
@@ -33,10 +33,8 @@ static int queue_iommu_command(struct am
     if ( ++tail == iommu->cmd_buffer.entries )
         tail = 0;
 
-    head = get_field_from_reg_u32(readl(iommu->mmio_base + 
-                                        IOMMU_CMD_BUFFER_HEAD_OFFSET),
-                                  IOMMU_CMD_BUFFER_HEAD_MASK,
-                                  IOMMU_CMD_BUFFER_HEAD_SHIFT);
+    head = iommu_get_rb_pointer(readl(iommu->mmio_base + 
+                                      IOMMU_CMD_BUFFER_HEAD_OFFSET));
     if ( head != tail )
     {
         cmd_buffer = (u32 *)(iommu->cmd_buffer.buffer +
@@ -55,11 +53,9 @@ static int queue_iommu_command(struct am
 
 static void commit_iommu_command_buffer(struct amd_iommu *iommu)
 {
-    u32 tail;
+    u32 tail = 0;
 
-    set_field_in_reg_u32(iommu->cmd_buffer.tail, 0,
-                         IOMMU_CMD_BUFFER_TAIL_MASK,
-                         IOMMU_CMD_BUFFER_TAIL_SHIFT, &tail);
+    iommu_set_rb_pointer(&tail, iommu->cmd_buffer.tail);
     writel(tail, iommu->mmio_base+IOMMU_CMD_BUFFER_TAIL_OFFSET);
 }
 
diff -r a3d2f93d8294 -r b190e3362524 xen/drivers/passthrough/amd/iommu_init.c
--- a/xen/drivers/passthrough/amd/iommu_init.c	Wed Dec 14 12:51:18 2011 +0100
+++ b/xen/drivers/passthrough/amd/iommu_init.c	Wed Dec 14 12:51:22 2011 +0100
@@ -106,21 +106,21 @@ static void register_iommu_dev_table_in_
     u64 addr_64, addr_lo, addr_hi;
     u32 entry;
 
+    ASSERT( iommu->dev_table.buffer );
+
     addr_64 = (u64)virt_to_maddr(iommu->dev_table.buffer);
     addr_lo = addr_64 & DMA_32BIT_MASK;
     addr_hi = addr_64 >> 32;
 
-    set_field_in_reg_u32((u32)addr_lo >> PAGE_SHIFT, 0,
-                         IOMMU_DEV_TABLE_BASE_LOW_MASK,
-                         IOMMU_DEV_TABLE_BASE_LOW_SHIFT, &entry);
+    entry = 0;
+    iommu_set_addr_lo_to_reg(&entry, addr_lo >> PAGE_SHIFT);
     set_field_in_reg_u32((iommu->dev_table.alloc_size / PAGE_SIZE) - 1,
                          entry, IOMMU_DEV_TABLE_SIZE_MASK,
                          IOMMU_DEV_TABLE_SIZE_SHIFT, &entry);
     writel(entry, iommu->mmio_base + IOMMU_DEV_TABLE_BASE_LOW_OFFSET);
 
-    set_field_in_reg_u32((u32)addr_hi, 0,
-                         IOMMU_DEV_TABLE_BASE_HIGH_MASK,
-                         IOMMU_DEV_TABLE_BASE_HIGH_SHIFT, &entry);
+    entry = 0;
+    iommu_set_addr_hi_to_reg(&entry, addr_hi);
     writel(entry, iommu->mmio_base + IOMMU_DEV_TABLE_BASE_HIGH_OFFSET);
 }
 
@@ -130,21 +130,21 @@ static void register_iommu_cmd_buffer_in
     u32 power_of2_entries;
     u32 entry;
 
+    ASSERT( iommu->dev_table.buffer );
+
     addr_64 = (u64)virt_to_maddr(iommu->cmd_buffer.buffer);
     addr_lo = addr_64 & DMA_32BIT_MASK;
     addr_hi = addr_64 >> 32;
 
-    set_field_in_reg_u32((u32)addr_lo >> PAGE_SHIFT, 0,
-                         IOMMU_CMD_BUFFER_BASE_LOW_MASK,
-                         IOMMU_CMD_BUFFER_BASE_LOW_SHIFT, &entry);
+    entry = 0;
+    iommu_set_addr_lo_to_reg(&entry, addr_lo >> PAGE_SHIFT);
     writel(entry, iommu->mmio_base + IOMMU_CMD_BUFFER_BASE_LOW_OFFSET);
 
     power_of2_entries = get_order_from_bytes(iommu->cmd_buffer.alloc_size) +
         IOMMU_CMD_BUFFER_POWER_OF2_ENTRIES_PER_PAGE;
 
-    set_field_in_reg_u32((u32)addr_hi, 0,
-                         IOMMU_CMD_BUFFER_BASE_HIGH_MASK,
-                         IOMMU_CMD_BUFFER_BASE_HIGH_SHIFT, &entry);
+    entry = 0;
+    iommu_set_addr_hi_to_reg(&entry, addr_hi);
     set_field_in_reg_u32(power_of2_entries, entry,
                          IOMMU_CMD_BUFFER_LENGTH_MASK,
                          IOMMU_CMD_BUFFER_LENGTH_SHIFT, &entry);
@@ -157,21 +157,21 @@ static void register_iommu_event_log_in_
     u32 power_of2_entries;
     u32 entry;
 
+    ASSERT( iommu->dev_table.buffer );
+
     addr_64 = (u64)virt_to_maddr(iommu->event_log.buffer);
     addr_lo = addr_64 & DMA_32BIT_MASK;
     addr_hi = addr_64 >> 32;
 
-    set_field_in_reg_u32((u32)addr_lo >> PAGE_SHIFT, 0,
-                         IOMMU_EVENT_LOG_BASE_LOW_MASK,
-                         IOMMU_EVENT_LOG_BASE_LOW_SHIFT, &entry);
+    entry = 0;
+    iommu_set_addr_lo_to_reg(&entry, addr_lo >> PAGE_SHIFT);
     writel(entry, iommu->mmio_base + IOMMU_EVENT_LOG_BASE_LOW_OFFSET);
 
     power_of2_entries = get_order_from_bytes(iommu->event_log.alloc_size) +
                         IOMMU_EVENT_LOG_POWER_OF2_ENTRIES_PER_PAGE;
 
-    set_field_in_reg_u32((u32)addr_hi, 0,
-                        IOMMU_EVENT_LOG_BASE_HIGH_MASK,
-                        IOMMU_EVENT_LOG_BASE_HIGH_SHIFT, &entry);
+    entry = 0;
+    iommu_set_addr_hi_to_reg(&entry, addr_hi);
     set_field_in_reg_u32(power_of2_entries, entry,
                         IOMMU_EVENT_LOG_LENGTH_MASK,
                         IOMMU_EVENT_LOG_LENGTH_SHIFT, &entry);
@@ -234,14 +234,12 @@ static void register_iommu_exclusion_ran
     addr_lo = iommu->exclusion_base & DMA_32BIT_MASK;
     addr_hi = iommu->exclusion_base >> 32;
 
-    set_field_in_reg_u32((u32)addr_hi, 0,
-                         IOMMU_EXCLUSION_BASE_HIGH_MASK,
-                         IOMMU_EXCLUSION_BASE_HIGH_SHIFT, &entry);
+    entry = 0;
+    iommu_set_addr_hi_to_reg(&entry, addr_hi);
     writel(entry, iommu->mmio_base+IOMMU_EXCLUSION_BASE_HIGH_OFFSET);
 
-    set_field_in_reg_u32((u32)addr_lo >> PAGE_SHIFT, 0,
-                         IOMMU_EXCLUSION_BASE_LOW_MASK,
-                         IOMMU_EXCLUSION_BASE_LOW_SHIFT, &entry);
+    entry = 0;
+    iommu_set_addr_lo_to_reg(&entry, addr_lo >> PAGE_SHIFT);
 
     set_field_in_reg_u32(iommu->exclusion_allow_all, entry,
                          IOMMU_EXCLUSION_ALLOW_ALL_MASK,
@@ -490,9 +488,7 @@ static void parse_event_log_entry(struct
 
     if ( code == IOMMU_EVENT_IO_PAGE_FAULT )
     {
-        device_id = get_field_from_reg_u32(entry[0],
-                                           IOMMU_EVENT_DEVICE_ID_MASK,
-                                           IOMMU_EVENT_DEVICE_ID_SHIFT);
+        device_id = iommu_get_devid_from_event(entry[0]);
         domain_id = get_field_from_reg_u32(entry[1],
                                            IOMMU_EVENT_DOMAIN_ID_MASK,
                                            IOMMU_EVENT_DOMAIN_ID_SHIFT);
diff -r a3d2f93d8294 -r b190e3362524 xen/include/asm-x86/hvm/svm/amd-iommu-proto.h
--- a/xen/include/asm-x86/hvm/svm/amd-iommu-proto.h	Wed Dec 14 12:51:18 2011 +0100
+++ b/xen/include/asm-x86/hvm/svm/amd-iommu-proto.h	Wed Dec 14 12:51:22 2011 +0100
@@ -191,5 +191,85 @@ static inline int iommu_has_feature(stru
         return 0;
     return !!(iommu->features & (1U << bit));
 }
+/* access tail or head pointer of ring buffer */
+#define IOMMU_RING_BUFFER_PTR_MASK                         0x0007FFF0
+#define IOMMU_RING_BUFFER_PTR_SHIFT                        4
+static inline uint32_t iommu_get_rb_pointer(uint32_t reg)
+{
+    return get_field_from_reg_u32(reg, IOMMU_RING_BUFFER_PTR_MASK, 
+                                  IOMMU_RING_BUFFER_PTR_SHIFT);
+}
+
+static inline void iommu_set_rb_pointer(uint32_t *reg, uint32_t val)
+{
+    set_field_in_reg_u32(val, *reg, IOMMU_RING_BUFFER_PTR_MASK, 
+                         IOMMU_RING_BUFFER_PTR_SHIFT, reg);
+}
+
+/* access device field from iommu cmd */
+#define IOMMU_CMD_DEVICE_ID_MASK           0x0000FFFF
+#define IOMMU_CMD_DEVICE_ID_SHIFT          0
+
+static inline uint16_t iommu_get_devid_from_cmd(uint32_t cmd)
+{
+    return get_field_from_reg_u32(cmd, IOMMU_CMD_DEVICE_ID_MASK, 
+                                  IOMMU_CMD_DEVICE_ID_SHIFT);
+}
+
+static inline void iommu_set_devid_to_cmd(uint32_t *cmd, uint16_t id)
+{
+    set_field_in_reg_u32(id, *cmd, IOMMU_CMD_DEVICE_ID_MASK, 
+                         IOMMU_CMD_DEVICE_ID_SHIFT, cmd);
+}
+
+/* access address field from iommu cmd */
+#define IOMMU_CMD_ADDR_LOW_MASK 0xFFFFF000
+#define IOMMU_CMD_ADDR_LOW_SHIFT    12
+#define IOMMU_CMD_ADDR_HIGH_MASK    0xFFFFFFFF
+#define IOMMU_CMD_ADDR_HIGH_SHIFT   0
+
+static inline uint32_t iommu_get_addr_lo_from_cmd(uint32_t cmd)
+{
+    return get_field_from_reg_u32(cmd, IOMMU_CMD_ADDR_LOW_MASK, 
+                                  IOMMU_CMD_ADDR_LOW_SHIFT);
+}
+
+static inline uint32_t iommu_get_addr_hi_from_cmd(uint32_t cmd)
+{
+    return get_field_from_reg_u32(cmd, IOMMU_CMD_ADDR_LOW_MASK, 
+                                  IOMMU_CMD_ADDR_HIGH_SHIFT);
+}
+
+#define iommu_get_devid_from_event          iommu_get_devid_from_cmd
+
+/* access iommu base addresses from mmio regs */
+#define IOMMU_REG_BASE_ADDR_BASE_LOW_MASK         0xFFFFF000
+#define IOMMU_REG_BASE_ADDR_LOW_SHIFT             12
+#define IOMMU_REG_BASE_ADDR_HIGH_MASK             0x000FFFFF
+#define IOMMU_REG_BASE_ADDR_HIGH_SHIFT            0
+
+static inline void iommu_set_addr_lo_to_reg(uint32_t *reg, uint32_t addr)
+{
+    set_field_in_reg_u32(addr, *reg, IOMMU_REG_BASE_ADDR_BASE_LOW_MASK, 
+                         IOMMU_REG_BASE_ADDR_LOW_SHIFT, reg);
+}
+
+static inline void iommu_set_addr_hi_to_reg(uint32_t *reg, uint32_t addr)
+{
+    set_field_in_reg_u32(addr, *reg, IOMMU_REG_BASE_ADDR_HIGH_MASK, 
+                         IOMMU_REG_BASE_ADDR_HIGH_SHIFT, reg);
+}
+
+static inline uint32_t iommu_get_addr_lo_from_reg(uint32_t reg)
+{
+    return get_field_from_reg_u32(reg, IOMMU_REG_BASE_ADDR_BASE_LOW_MASK, 
+                                  IOMMU_REG_BASE_ADDR_LOW_SHIFT);
+}
+
+static inline uint32_t iommu_get_addr_hi_from_reg(uint32_t reg)
+{
+    return get_field_from_reg_u32(reg, IOMMU_REG_BASE_ADDR_HIGH_MASK, 
+                                  IOMMU_REG_BASE_ADDR_HIGH_SHIFT);
+}
 
 #endif /* _ASM_X86_64_AMD_IOMMU_PROTO_H */


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 15:36:31 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 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.xensource.com>)
	id 1RaqsT-0002v0-V8; Wed, 14 Dec 2011 15:36:17 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Wang2@amd.com>) id 1RaqsS-0002u5-MS
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 15:36:17 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1323876920!5558005!1
X-Originating-IP: [213.199.154.206]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30655 invoked from network); 14 Dec 2011 15:35:20 -0000
Received: from am1ehsobe003.messaging.microsoft.com (HELO
	AM1EHSOBE003.bigfish.com) (213.199.154.206)
	by server-6.tower-174.messagelabs.com with AES128-SHA encrypted SMTP;
	14 Dec 2011 15:35:20 -0000
Received: from mail36-am1-R.bigfish.com (10.3.201.245) by
	AM1EHSOBE003.bigfish.com (10.3.204.23) with Microsoft SMTP Server id
	14.1.225.23; Wed, 14 Dec 2011 15:35:22 +0000
Received: from mail36-am1 (localhost [127.0.0.1])	by mail36-am1-R.bigfish.com
	(Postfix) with ESMTP id 1FBE130028D;
	Wed, 14 Dec 2011 15:35:23 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzzz1202hzz8275bhz2dh668h839h944h)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
Received: from mail36-am1 (localhost.localdomain [127.0.0.1]) by mail36-am1
	(MessageSwitch) id 1323876922773293_15823;
	Wed, 14 Dec 2011 15:35:22 +0000 (UTC)
Received: from AM1EHSMHS004.bigfish.com (unknown [10.3.201.247])	by
	mail36-am1.bigfish.com (Postfix) with ESMTP id AF57C4A0046;
	Wed, 14 Dec 2011 15:35:22 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	AM1EHSMHS004.bigfish.com (10.3.207.104) with Microsoft SMTP Server id
	14.1.225.23; Wed, 14 Dec 2011 15:35:21 +0000
X-WSS-ID: 0LW79YR-02-A99-02
X-M-MSG: 
Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com
	[163.181.249.73])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp02.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 20CEAC808C;	Wed, 14 Dec 2011 09:35:15 -0600 (CST)
Received: from SAUSEXDAG02.amd.com (163.181.55.2) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Wed, 14 Dec 2011 09:35:29 -0600
Received: from storexhtp02.amd.com (172.24.4.4) by sausexdag02.amd.com
	(163.181.55.2) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Wed, 14 Dec 2011 09:35:17 -0600
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Wed, 14 Dec 2011
	10:35:16 -0500
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 80A9C49C661; Wed, 14 Dec 2011
	15:35:11 +0000 (GMT)
Received: from gran.amd.com (gran.osrc.amd.com [165.204.15.57])	by
	mail.osrc.amd.com (Postfix) with ESMTP id 6E383594887; Wed, 14 Dec 2011
	16:35:11 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: ef5698887d044ad58293bee3549eaa20310c2b17
Message-ID: <ef5698887d044ad58293.1323876568@gran.amd.com>
In-Reply-To: <patchbomb.1323876561@gran.amd.com>
References: <patchbomb.1323876561@gran.amd.com>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Wed, 14 Dec 2011 16:29:28 +0100
From: Wei Wang <wei.wang2@amd.com>
To: <JBeulich@suse.com>, <keir@xen.org>
X-OriginatorOrg: amd.com
Cc: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 07 of 16] amd iommu: Add 2 hypercalls for libxc
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Wei Wang <wei.wang2@amd.com>
# Date 1323875772 -3600
# Node ID ef5698887d044ad58293bee3549eaa20310c2b17
# Parent  fbed4e6011fce13d3a521bbc339f4959bf32a06c
amd iommu: Add 2 hypercalls for libxc

iommu_set_msi: used by qemu to inform hypervisor iommu vector number in guest
space. Hypervisor needs this vector to inject msi into guest when PPR logging
happens.

iommu_bind_bdf: used by xl to bind guest bdf number to machine bdf number.
IOMMU emulations codes receives commands from guest iommu driver and forwards
them to host iommu. But virtual device id from guest should be converted into
physical before sending to real hardware.

Signed -off-by: Wei Wang <wei.wang2@amd.com>

diff -r fbed4e6011fc -r ef5698887d04 xen/drivers/passthrough/amd/iommu_guest.c
--- a/xen/drivers/passthrough/amd/iommu_guest.c	Wed Dec 14 16:16:11 2011 +0100
+++ b/xen/drivers/passthrough/amd/iommu_guest.c	Wed Dec 14 16:16:12 2011 +0100
@@ -50,12 +50,27 @@
 
 static unsigned int machine_bdf(struct domain *d, uint16_t guest_bdf)
 {
-    return guest_bdf;
+    struct pci_dev *pdev;
+    uint16_t mbdf = 0;
+
+    for_each_pdev( d, pdev )
+    {
+        if ( pdev->gbdf == guest_bdf )
+        {
+            mbdf = PCI_BDF2(pdev->bus, pdev->devfn);
+            break;
+        }
+    }
+    return mbdf;
 }
 
 static uint16_t guest_bdf(struct domain *d, uint16_t machine_bdf)
 {
-    return machine_bdf;
+    struct pci_dev *pdev;
+
+    pdev = pci_get_pdev_by_domain(d, 0, PCI_BUS(machine_bdf),
+                                  PCI_DEVFN2(machine_bdf));
+    return pdev->gbdf;
 }
 
 static inline struct guest_iommu *domain_iommu(struct domain *d)
@@ -951,3 +966,43 @@ const struct hvm_mmio_handler iommu_mmio
     .read_handler = guest_iommu_mmio_read,
     .write_handler = guest_iommu_mmio_write
 };
+
+/* iommu hypercall handler */
+int iommu_bind_bdf(struct domain* d, uint16_t gbdf, uint16_t mbdf)
+{
+    struct pci_dev *pdev;
+    int ret = -ENODEV;
+
+    if ( !iommu_found() )
+        return 0;
+
+    spin_lock(&pcidevs_lock);
+
+    for_each_pdev( d, pdev )
+    {
+        if ( (pdev->bus != PCI_BUS(mbdf) ) || 
+             (pdev->devfn != PCI_DEVFN2(mbdf)) )
+            continue;
+
+        pdev->gbdf = gbdf;
+        ret = 0;
+    }
+
+    spin_unlock(&pcidevs_lock);
+    return ret;
+}
+
+void iommu_set_msi(struct domain* d, uint16_t vector, uint16_t dest,
+                   uint16_t dest_mode, uint16_t delivery_mode, 
+                   uint16_t trig_mode)
+{
+    struct guest_iommu *iommu = domain_iommu(d);
+
+    if ( !iommu_found() )
+        return;
+
+    iommu->msi.vector = vector;
+    iommu->msi.dest = dest;
+    iommu->msi.dest_mode = dest_mode;
+    iommu->msi.trig_mode = trig_mode;
+}
diff -r fbed4e6011fc -r ef5698887d04 xen/drivers/passthrough/iommu.c
--- a/xen/drivers/passthrough/iommu.c	Wed Dec 14 16:16:11 2011 +0100
+++ b/xen/drivers/passthrough/iommu.c	Wed Dec 14 16:16:12 2011 +0100
@@ -640,6 +640,40 @@ int iommu_do_domctl(
         put_domain(d);
         break;
 
+#ifndef __ia64__ 
+    case XEN_DOMCTL_guest_iommu_op:
+    {
+        xen_domctl_guest_iommu_op_t * guest_op;
+
+        if ( unlikely((d = get_domain_by_id(domctl->domain)) == NULL) )
+        {
+            gdprintk(XENLOG_ERR,
+                    "XEN_DOMCTL_guest_iommu_op: get_domain_by_id() failed\n");
+            ret = -EINVAL;
+            break;
+        }
+
+        guest_op = &(domctl->u.guest_iommu_op);
+        switch ( guest_op->op )
+        {
+            case XEN_DOMCTL_GUEST_IOMMU_OP_SET_MSI:
+                iommu_set_msi(d, guest_op->u.msi.vector, 
+                              guest_op->u.msi.dest,
+                              guest_op->u.msi.dest_mode, 
+                              guest_op->u.msi.delivery_mode,
+                              guest_op->u.msi.trig_mode);
+                ret = 0;
+                break;
+            case XEN_DOMCTL_GUEST_IOMMU_OP_BIND_BDF:
+                ret = iommu_bind_bdf(d, guest_op->u.bdf_bind.g_bdf,
+                                     guest_op->u.bdf_bind.m_bdf);
+                break;
+        }
+        put_domain(d);
+        break;
+    }
+#endif
+
     default:
         ret = -ENOSYS;
         break;
diff -r fbed4e6011fc -r ef5698887d04 xen/include/public/domctl.h
--- a/xen/include/public/domctl.h	Wed Dec 14 16:16:11 2011 +0100
+++ b/xen/include/public/domctl.h	Wed Dec 14 16:16:12 2011 +0100
@@ -848,6 +848,31 @@ struct xen_domctl_set_access_required {
 typedef struct xen_domctl_set_access_required xen_domctl_set_access_required_t;
 DEFINE_XEN_GUEST_HANDLE(xen_domctl_set_access_required_t);
 
+#if defined(__i386__) || defined(__x86_64__)
+/* Support for guest iommu emulation */
+struct xen_domctl_guest_iommu_op {
+    /* XEN_DOMCTL_GUEST_IOMMU_OP_* */
+#define XEN_DOMCTL_GUEST_IOMMU_OP_SET_MSI               0
+#define XEN_DOMCTL_GUEST_IOMMU_OP_BIND_BDF              1
+    uint8_t op;
+    union {
+        struct iommu_msi {
+        uint8_t  vector;
+        uint8_t  dest;
+        uint8_t  dest_mode;
+        uint8_t  delivery_mode;
+        uint8_t  trig_mode;
+        } msi;
+        struct bdf_bind { 
+            uint32_t            g_bdf;
+            uint32_t            m_bdf;
+        } bdf_bind;
+    } u;
+};
+typedef struct xen_domctl_guest_iommu_op xen_domctl_guest_iommu_op_t;
+DEFINE_XEN_GUEST_HANDLE(xen_domctl_guest_iommu_op_t);
+#endif
+
 struct xen_domctl {
     uint32_t cmd;
 #define XEN_DOMCTL_createdomain                   1
@@ -912,6 +937,7 @@ struct xen_domctl {
 #define XEN_DOMCTL_getvcpuextstate               63
 #define XEN_DOMCTL_set_access_required           64
 #define XEN_DOMCTL_audit_p2m                     65
+#define XEN_DOMCTL_guest_iommu_op                66
 #define XEN_DOMCTL_gdbsx_guestmemio            1000
 #define XEN_DOMCTL_gdbsx_pausevcpu             1001
 #define XEN_DOMCTL_gdbsx_unpausevcpu           1002
@@ -963,6 +989,7 @@ struct xen_domctl {
 #if defined(__i386__) || defined(__x86_64__)
         struct xen_domctl_cpuid             cpuid;
         struct xen_domctl_vcpuextstate      vcpuextstate;
+        struct xen_domctl_guest_iommu_op    guest_iommu_op;
 #endif
         struct xen_domctl_set_access_required access_required;
         struct xen_domctl_audit_p2m         audit_p2m;
diff -r fbed4e6011fc -r ef5698887d04 xen/include/xen/iommu.h
--- a/xen/include/xen/iommu.h	Wed Dec 14 16:16:11 2011 +0100
+++ b/xen/include/xen/iommu.h	Wed Dec 14 16:16:12 2011 +0100
@@ -164,6 +164,14 @@ int iommu_do_domctl(struct xen_domctl *,
 void iommu_iotlb_flush(struct domain *d, unsigned long gfn, unsigned int page_count);
 void iommu_iotlb_flush_all(struct domain *d);
 
+#ifndef __ia64_
+/* Only used by AMD IOMMU */
+void iommu_set_msi(struct domain* d, uint16_t vector, uint16_t dest,
+                   uint16_t dest_mode, uint16_t delivery_mode, 
+                   uint16_t trig_mode);
+int iommu_bind_bdf(struct domain* d, uint16_t gbdf, uint16_t mbdf);
+#endif
+
 /*
  * The purpose of the iommu_dont_flush_iotlb optional cpu flag is to
  * avoid unecessary iotlb_flush in the low level IOMMU code.
diff -r fbed4e6011fc -r ef5698887d04 xen/include/xen/pci.h
--- a/xen/include/xen/pci.h	Wed Dec 14 16:16:11 2011 +0100
+++ b/xen/include/xen/pci.h	Wed Dec 14 16:16:12 2011 +0100
@@ -63,6 +63,9 @@ struct pci_dev {
     const u8 devfn;
     struct pci_dev_info info;
     u64 vf_rlen[6];
+
+    /* used by amd iomm to represent bdf value in guest space */
+    u16 gbdf;
 };
 
 #define for_each_pdev(domain, pdev) \


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 15:36:31 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 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.xensource.com>)
	id 1Raqsa-0002zB-Gt; Wed, 14 Dec 2011 15:36:24 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Wang2@amd.com>) id 1RaqsW-0002uM-CV
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 15:36:20 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1323876924!7282933!1
X-Originating-IP: [213.199.154.140]
X-SpamReason: No, hits=0.0 required=7.0 tests=UPPERCASE_25_50
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 834 invoked from network); 14 Dec 2011 15:35:24 -0000
Received: from db3ehsobe002.messaging.microsoft.com (HELO
	DB3EHSOBE002.bigfish.com) (213.199.154.140)
	by server-5.tower-182.messagelabs.com with AES128-SHA encrypted SMTP;
	14 Dec 2011 15:35:24 -0000
Received: from mail110-db3-R.bigfish.com (10.3.81.253) by
	DB3EHSOBE002.bigfish.com (10.3.84.22) with Microsoft SMTP Server id
	14.1.225.23; Wed, 14 Dec 2011 15:35:26 +0000
Received: from mail110-db3 (localhost [127.0.0.1])	by
	mail110-db3-R.bigfish.com (Postfix) with ESMTP id 41A67A0313;
	Wed, 14 Dec 2011 15:35:27 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzzz1202hzz8275bhz2dh668h839h944h)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
X-FB-SS: 13,
Received: from mail110-db3 (localhost.localdomain [127.0.0.1]) by mail110-db3
	(MessageSwitch) id 1323876927111645_22874;
	Wed, 14 Dec 2011 15:35:27 +0000 (UTC)
Received: from DB3EHSMHS004.bigfish.com (unknown [10.3.81.243])	by
	mail110-db3.bigfish.com (Postfix) with ESMTP id 0B8B160046;
	Wed, 14 Dec 2011 15:35:27 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	DB3EHSMHS004.bigfish.com (10.3.87.104) with Microsoft SMTP Server id
	14.1.225.23; Wed, 14 Dec 2011 15:35:24 +0000
X-WSS-ID: 0LW79YU-02-A9P-02
X-M-MSG: 
Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com
	[163.181.249.73])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp02.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 25054C808B;	Wed, 14 Dec 2011 09:35:17 -0600 (CST)
Received: from SAUSEXDAG01.amd.com (163.181.55.1) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Wed, 14 Dec 2011 09:35:30 -0600
Received: from storexhtp01.amd.com (172.24.4.3) by sausexdag01.amd.com
	(163.181.55.1) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Wed, 14 Dec 2011 09:35:18 -0600
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp01.amd.com
	(172.24.4.3) with Microsoft SMTP Server id 8.3.213.0; Wed, 14 Dec 2011
	10:35:16 -0500
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 5E74F49C65F; Wed, 14 Dec 2011
	15:35:11 +0000 (GMT)
Received: from gran.amd.com (gran.osrc.amd.com [165.204.15.57])	by
	mail.osrc.amd.com (Postfix) with ESMTP id 4E05D5940FF; Wed, 14 Dec 2011
	16:35:11 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: be3f15ae6a4153504bbb3376291a2383684afee5
Message-ID: <be3f15ae6a4153504bbb.1323876566@gran.amd.com>
In-Reply-To: <patchbomb.1323876561@gran.amd.com>
References: <patchbomb.1323876561@gran.amd.com>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Wed, 14 Dec 2011 16:29:26 +0100
From: Wei Wang <wei.wang2@amd.com>
To: <JBeulich@suse.com>, <keir@xen.org>
X-OriginatorOrg: amd.com
Cc: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 05 of 16] amd iommu: Enable guest level
	translation
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Wei Wang <wei.wang2@amd.com>
# Date 1323875770 -3600
# Node ID be3f15ae6a4153504bbb3376291a2383684afee5
# Parent  d3aa7f936872abacb7e059393fa8963db35c4045
amd iommu: Enable guest level translation.
Similar to nested paging for SVM, IOMMUv2 supports two level translations for
DMA. This patch enables this feature.

Signed-off-by: Wei Wang <wei.wang2@amd.com>

diff -r d3aa7f936872 -r be3f15ae6a41 xen/drivers/passthrough/amd/iommu_init.c
--- a/xen/drivers/passthrough/amd/iommu_init.c	Wed Dec 14 16:08:39 2011 +0100
+++ b/xen/drivers/passthrough/amd/iommu_init.c	Wed Dec 14 16:16:10 2011 +0100
@@ -220,6 +220,23 @@ static void set_iommu_translation_contro
     writel(entry, iommu->mmio_base+IOMMU_CONTROL_MMIO_OFFSET);
 }
 
+static void set_iommu_guest_translation_control(struct amd_iommu *iommu,
+                                                int enable)
+{
+    u32 entry;
+
+    entry = readl(iommu->mmio_base + IOMMU_CONTROL_MMIO_OFFSET);
+
+    enable ?
+        iommu_set_bit(&entry, IOMMU_CONTROL_GT_ENABLE_SHIFT):
+        iommu_clear_bit(&entry, IOMMU_CONTROL_GT_ENABLE_SHIFT);
+
+    writel(entry, iommu->mmio_base+IOMMU_CONTROL_MMIO_OFFSET);
+
+    if ( enable )
+        AMD_IOMMU_DEBUG("Guest Translation Enabled.\n");
+}
+
 static void set_iommu_command_buffer_control(struct amd_iommu *iommu,
                                                     int enable)
 {
@@ -655,6 +672,9 @@ static void enable_iommu(struct amd_iomm
     if ( iommu_has_feature(iommu, IOMMU_EXT_FEATURE_PPRSUP_SHIFT) )
         set_iommu_ppr_log_control(iommu, IOMMU_CONTROL_ENABLED);
 
+    if ( iommu_has_feature(iommu, IOMMU_EXT_FEATURE_GTSUP_SHIFT) )
+        set_iommu_guest_translation_control(iommu, IOMMU_CONTROL_ENABLED);
+
     set_iommu_translation_control(iommu, IOMMU_CONTROL_ENABLED);
 
     if ( iommu_has_feature(iommu, IOMMU_EXT_FEATURE_IASUP_SHIFT) )
@@ -996,6 +1016,9 @@ static void disable_iommu(struct amd_iom
     if ( iommu_has_feature(iommu, IOMMU_EXT_FEATURE_PPRSUP_SHIFT) )
         set_iommu_ppr_log_control(iommu, IOMMU_CONTROL_DISABLED);
 
+    if ( iommu_has_feature(iommu, IOMMU_EXT_FEATURE_GTSUP_SHIFT) )
+        set_iommu_guest_translation_control(iommu, IOMMU_CONTROL_DISABLED);
+
     set_iommu_translation_control(iommu, IOMMU_CONTROL_DISABLED);
 
     iommu->enabled = 0;


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 15:36:31 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 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.xensource.com>)
	id 1RaqsX-0002wO-8D; Wed, 14 Dec 2011 15:36:21 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Wang2@amd.com>) id 1RaqsV-0002uF-KX
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 15:36:19 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1323876923!7262183!1
X-Originating-IP: [213.199.154.143]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24792 invoked from network); 14 Dec 2011 15:35:24 -0000
Received: from db3ehsobe005.messaging.microsoft.com (HELO
	DB3EHSOBE005.bigfish.com) (213.199.154.143)
	by server-6.tower-182.messagelabs.com with AES128-SHA encrypted SMTP;
	14 Dec 2011 15:35:24 -0000
Received: from mail47-db3-R.bigfish.com (10.3.81.240) by
	DB3EHSOBE005.bigfish.com (10.3.84.25) with Microsoft SMTP Server id
	14.1.225.23; Wed, 14 Dec 2011 15:35:26 +0000
Received: from mail47-db3 (localhost [127.0.0.1])	by mail47-db3-R.bigfish.com
	(Postfix) with ESMTP id 006422403FD;
	Wed, 14 Dec 2011 15:35:27 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzzz1202hzz8275bhz2dh668h839h944h)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
X-FB-SS: 13,
Received: from mail47-db3 (localhost.localdomain [127.0.0.1]) by mail47-db3
	(MessageSwitch) id 1323876926883492_2339;
	Wed, 14 Dec 2011 15:35:26 +0000 (UTC)
Received: from DB3EHSMHS018.bigfish.com (unknown [10.3.81.247])	by
	mail47-db3.bigfish.com (Postfix) with ESMTP id D26A14E0044;
	Wed, 14 Dec 2011 15:35:26 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	DB3EHSMHS018.bigfish.com (10.3.87.118) with Microsoft SMTP Server id
	14.1.225.23; Wed, 14 Dec 2011 15:35:21 +0000
X-WSS-ID: 0LW79YR-02-A9E-02
X-M-MSG: 
Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com
	[163.181.249.73])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp02.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2F70DC8088;	Wed, 14 Dec 2011 09:35:14 -0600 (CST)
Received: from SAUSEXDAG02.amd.com (163.181.55.2) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Wed, 14 Dec 2011 09:35:28 -0600
Received: from storexhtp02.amd.com (172.24.4.4) by sausexdag02.amd.com
	(163.181.55.2) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Wed, 14 Dec 2011 09:35:16 -0600
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Wed, 14 Dec 2011
	10:35:16 -0500
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id AB86A49C663; Wed, 14 Dec 2011
	15:35:11 +0000 (GMT)
Received: from gran.amd.com (gran.osrc.amd.com [165.204.15.57])	by
	mail.osrc.amd.com (Postfix) with ESMTP id 9859659488A; Wed, 14 Dec 2011
	16:35:11 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: f33af4d61321d074a4c624d909204fce5945f61b
Message-ID: <f33af4d61321d074a4c6.1323876570@gran.amd.com>
In-Reply-To: <patchbomb.1323876561@gran.amd.com>
References: <patchbomb.1323876561@gran.amd.com>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Wed, 14 Dec 2011 16:29:30 +0100
From: Wei Wang <wei.wang2@amd.com>
To: <JBeulich@suse.com>, <keir@xen.org>
X-OriginatorOrg: amd.com
Cc: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 09 of 16] amd iommu: add iommu mmio handler
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Wei Wang <wei.wang2@amd.com>
# Date 1323875774 -3600
# Node ID f33af4d61321d074a4c624d909204fce5945f61b
# Parent  52dbaf1fb0e0364fad40f9be330f80e157c935e4
amd iommu: add iommu mmio handler.

Signed-off-by: Wei Wang <wei.wang2@amd.com>

diff -r 52dbaf1fb0e0 -r f33af4d61321 xen/arch/x86/hvm/intercept.c
--- a/xen/arch/x86/hvm/intercept.c	Wed Dec 14 16:16:13 2011 +0100
+++ b/xen/arch/x86/hvm/intercept.c	Wed Dec 14 16:16:14 2011 +0100
@@ -38,7 +38,8 @@ hvm_mmio_handlers[HVM_MMIO_HANDLER_NR] =
     &hpet_mmio_handler,
     &vlapic_mmio_handler,
     &vioapic_mmio_handler,
-    &msixtbl_mmio_handler
+    &msixtbl_mmio_handler,
+    &iommu_mmio_handler
 };
 
 static int hvm_mmio_access(struct vcpu *v,
diff -r 52dbaf1fb0e0 -r f33af4d61321 xen/include/asm-x86/hvm/io.h
--- a/xen/include/asm-x86/hvm/io.h	Wed Dec 14 16:16:13 2011 +0100
+++ b/xen/include/asm-x86/hvm/io.h	Wed Dec 14 16:16:14 2011 +0100
@@ -69,8 +69,9 @@ extern const struct hvm_mmio_handler hpe
 extern const struct hvm_mmio_handler vlapic_mmio_handler;
 extern const struct hvm_mmio_handler vioapic_mmio_handler;
 extern const struct hvm_mmio_handler msixtbl_mmio_handler;
+extern const struct hvm_mmio_handler iommu_mmio_handler;
 
-#define HVM_MMIO_HANDLER_NR 4
+#define HVM_MMIO_HANDLER_NR 5
 
 int hvm_io_intercept(ioreq_t *p, int type);
 void register_io_handler(


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 15:36:31 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 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.xensource.com>)
	id 1Raqsa-0002zB-Gt; Wed, 14 Dec 2011 15:36:24 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Wang2@amd.com>) id 1RaqsW-0002uM-CV
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 15:36:20 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1323876924!7282933!1
X-Originating-IP: [213.199.154.140]
X-SpamReason: No, hits=0.0 required=7.0 tests=UPPERCASE_25_50
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 834 invoked from network); 14 Dec 2011 15:35:24 -0000
Received: from db3ehsobe002.messaging.microsoft.com (HELO
	DB3EHSOBE002.bigfish.com) (213.199.154.140)
	by server-5.tower-182.messagelabs.com with AES128-SHA encrypted SMTP;
	14 Dec 2011 15:35:24 -0000
Received: from mail110-db3-R.bigfish.com (10.3.81.253) by
	DB3EHSOBE002.bigfish.com (10.3.84.22) with Microsoft SMTP Server id
	14.1.225.23; Wed, 14 Dec 2011 15:35:26 +0000
Received: from mail110-db3 (localhost [127.0.0.1])	by
	mail110-db3-R.bigfish.com (Postfix) with ESMTP id 41A67A0313;
	Wed, 14 Dec 2011 15:35:27 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzzz1202hzz8275bhz2dh668h839h944h)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
X-FB-SS: 13,
Received: from mail110-db3 (localhost.localdomain [127.0.0.1]) by mail110-db3
	(MessageSwitch) id 1323876927111645_22874;
	Wed, 14 Dec 2011 15:35:27 +0000 (UTC)
Received: from DB3EHSMHS004.bigfish.com (unknown [10.3.81.243])	by
	mail110-db3.bigfish.com (Postfix) with ESMTP id 0B8B160046;
	Wed, 14 Dec 2011 15:35:27 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	DB3EHSMHS004.bigfish.com (10.3.87.104) with Microsoft SMTP Server id
	14.1.225.23; Wed, 14 Dec 2011 15:35:24 +0000
X-WSS-ID: 0LW79YU-02-A9P-02
X-M-MSG: 
Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com
	[163.181.249.73])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp02.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 25054C808B;	Wed, 14 Dec 2011 09:35:17 -0600 (CST)
Received: from SAUSEXDAG01.amd.com (163.181.55.1) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Wed, 14 Dec 2011 09:35:30 -0600
Received: from storexhtp01.amd.com (172.24.4.3) by sausexdag01.amd.com
	(163.181.55.1) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Wed, 14 Dec 2011 09:35:18 -0600
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp01.amd.com
	(172.24.4.3) with Microsoft SMTP Server id 8.3.213.0; Wed, 14 Dec 2011
	10:35:16 -0500
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 5E74F49C65F; Wed, 14 Dec 2011
	15:35:11 +0000 (GMT)
Received: from gran.amd.com (gran.osrc.amd.com [165.204.15.57])	by
	mail.osrc.amd.com (Postfix) with ESMTP id 4E05D5940FF; Wed, 14 Dec 2011
	16:35:11 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: be3f15ae6a4153504bbb3376291a2383684afee5
Message-ID: <be3f15ae6a4153504bbb.1323876566@gran.amd.com>
In-Reply-To: <patchbomb.1323876561@gran.amd.com>
References: <patchbomb.1323876561@gran.amd.com>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Wed, 14 Dec 2011 16:29:26 +0100
From: Wei Wang <wei.wang2@amd.com>
To: <JBeulich@suse.com>, <keir@xen.org>
X-OriginatorOrg: amd.com
Cc: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 05 of 16] amd iommu: Enable guest level
	translation
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Wei Wang <wei.wang2@amd.com>
# Date 1323875770 -3600
# Node ID be3f15ae6a4153504bbb3376291a2383684afee5
# Parent  d3aa7f936872abacb7e059393fa8963db35c4045
amd iommu: Enable guest level translation.
Similar to nested paging for SVM, IOMMUv2 supports two level translations for
DMA. This patch enables this feature.

Signed-off-by: Wei Wang <wei.wang2@amd.com>

diff -r d3aa7f936872 -r be3f15ae6a41 xen/drivers/passthrough/amd/iommu_init.c
--- a/xen/drivers/passthrough/amd/iommu_init.c	Wed Dec 14 16:08:39 2011 +0100
+++ b/xen/drivers/passthrough/amd/iommu_init.c	Wed Dec 14 16:16:10 2011 +0100
@@ -220,6 +220,23 @@ static void set_iommu_translation_contro
     writel(entry, iommu->mmio_base+IOMMU_CONTROL_MMIO_OFFSET);
 }
 
+static void set_iommu_guest_translation_control(struct amd_iommu *iommu,
+                                                int enable)
+{
+    u32 entry;
+
+    entry = readl(iommu->mmio_base + IOMMU_CONTROL_MMIO_OFFSET);
+
+    enable ?
+        iommu_set_bit(&entry, IOMMU_CONTROL_GT_ENABLE_SHIFT):
+        iommu_clear_bit(&entry, IOMMU_CONTROL_GT_ENABLE_SHIFT);
+
+    writel(entry, iommu->mmio_base+IOMMU_CONTROL_MMIO_OFFSET);
+
+    if ( enable )
+        AMD_IOMMU_DEBUG("Guest Translation Enabled.\n");
+}
+
 static void set_iommu_command_buffer_control(struct amd_iommu *iommu,
                                                     int enable)
 {
@@ -655,6 +672,9 @@ static void enable_iommu(struct amd_iomm
     if ( iommu_has_feature(iommu, IOMMU_EXT_FEATURE_PPRSUP_SHIFT) )
         set_iommu_ppr_log_control(iommu, IOMMU_CONTROL_ENABLED);
 
+    if ( iommu_has_feature(iommu, IOMMU_EXT_FEATURE_GTSUP_SHIFT) )
+        set_iommu_guest_translation_control(iommu, IOMMU_CONTROL_ENABLED);
+
     set_iommu_translation_control(iommu, IOMMU_CONTROL_ENABLED);
 
     if ( iommu_has_feature(iommu, IOMMU_EXT_FEATURE_IASUP_SHIFT) )
@@ -996,6 +1016,9 @@ static void disable_iommu(struct amd_iom
     if ( iommu_has_feature(iommu, IOMMU_EXT_FEATURE_PPRSUP_SHIFT) )
         set_iommu_ppr_log_control(iommu, IOMMU_CONTROL_DISABLED);
 
+    if ( iommu_has_feature(iommu, IOMMU_EXT_FEATURE_GTSUP_SHIFT) )
+        set_iommu_guest_translation_control(iommu, IOMMU_CONTROL_DISABLED);
+
     set_iommu_translation_control(iommu, IOMMU_CONTROL_DISABLED);
 
     iommu->enabled = 0;


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 15:36:31 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 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.xensource.com>)
	id 1RaqsX-0002wO-8D; Wed, 14 Dec 2011 15:36:21 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Wang2@amd.com>) id 1RaqsV-0002uF-KX
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 15:36:19 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1323876923!7262183!1
X-Originating-IP: [213.199.154.143]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24792 invoked from network); 14 Dec 2011 15:35:24 -0000
Received: from db3ehsobe005.messaging.microsoft.com (HELO
	DB3EHSOBE005.bigfish.com) (213.199.154.143)
	by server-6.tower-182.messagelabs.com with AES128-SHA encrypted SMTP;
	14 Dec 2011 15:35:24 -0000
Received: from mail47-db3-R.bigfish.com (10.3.81.240) by
	DB3EHSOBE005.bigfish.com (10.3.84.25) with Microsoft SMTP Server id
	14.1.225.23; Wed, 14 Dec 2011 15:35:26 +0000
Received: from mail47-db3 (localhost [127.0.0.1])	by mail47-db3-R.bigfish.com
	(Postfix) with ESMTP id 006422403FD;
	Wed, 14 Dec 2011 15:35:27 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzzz1202hzz8275bhz2dh668h839h944h)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
X-FB-SS: 13,
Received: from mail47-db3 (localhost.localdomain [127.0.0.1]) by mail47-db3
	(MessageSwitch) id 1323876926883492_2339;
	Wed, 14 Dec 2011 15:35:26 +0000 (UTC)
Received: from DB3EHSMHS018.bigfish.com (unknown [10.3.81.247])	by
	mail47-db3.bigfish.com (Postfix) with ESMTP id D26A14E0044;
	Wed, 14 Dec 2011 15:35:26 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	DB3EHSMHS018.bigfish.com (10.3.87.118) with Microsoft SMTP Server id
	14.1.225.23; Wed, 14 Dec 2011 15:35:21 +0000
X-WSS-ID: 0LW79YR-02-A9E-02
X-M-MSG: 
Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com
	[163.181.249.73])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp02.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2F70DC8088;	Wed, 14 Dec 2011 09:35:14 -0600 (CST)
Received: from SAUSEXDAG02.amd.com (163.181.55.2) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Wed, 14 Dec 2011 09:35:28 -0600
Received: from storexhtp02.amd.com (172.24.4.4) by sausexdag02.amd.com
	(163.181.55.2) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Wed, 14 Dec 2011 09:35:16 -0600
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Wed, 14 Dec 2011
	10:35:16 -0500
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id AB86A49C663; Wed, 14 Dec 2011
	15:35:11 +0000 (GMT)
Received: from gran.amd.com (gran.osrc.amd.com [165.204.15.57])	by
	mail.osrc.amd.com (Postfix) with ESMTP id 9859659488A; Wed, 14 Dec 2011
	16:35:11 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: f33af4d61321d074a4c624d909204fce5945f61b
Message-ID: <f33af4d61321d074a4c6.1323876570@gran.amd.com>
In-Reply-To: <patchbomb.1323876561@gran.amd.com>
References: <patchbomb.1323876561@gran.amd.com>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Wed, 14 Dec 2011 16:29:30 +0100
From: Wei Wang <wei.wang2@amd.com>
To: <JBeulich@suse.com>, <keir@xen.org>
X-OriginatorOrg: amd.com
Cc: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 09 of 16] amd iommu: add iommu mmio handler
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Wei Wang <wei.wang2@amd.com>
# Date 1323875774 -3600
# Node ID f33af4d61321d074a4c624d909204fce5945f61b
# Parent  52dbaf1fb0e0364fad40f9be330f80e157c935e4
amd iommu: add iommu mmio handler.

Signed-off-by: Wei Wang <wei.wang2@amd.com>

diff -r 52dbaf1fb0e0 -r f33af4d61321 xen/arch/x86/hvm/intercept.c
--- a/xen/arch/x86/hvm/intercept.c	Wed Dec 14 16:16:13 2011 +0100
+++ b/xen/arch/x86/hvm/intercept.c	Wed Dec 14 16:16:14 2011 +0100
@@ -38,7 +38,8 @@ hvm_mmio_handlers[HVM_MMIO_HANDLER_NR] =
     &hpet_mmio_handler,
     &vlapic_mmio_handler,
     &vioapic_mmio_handler,
-    &msixtbl_mmio_handler
+    &msixtbl_mmio_handler,
+    &iommu_mmio_handler
 };
 
 static int hvm_mmio_access(struct vcpu *v,
diff -r 52dbaf1fb0e0 -r f33af4d61321 xen/include/asm-x86/hvm/io.h
--- a/xen/include/asm-x86/hvm/io.h	Wed Dec 14 16:16:13 2011 +0100
+++ b/xen/include/asm-x86/hvm/io.h	Wed Dec 14 16:16:14 2011 +0100
@@ -69,8 +69,9 @@ extern const struct hvm_mmio_handler hpe
 extern const struct hvm_mmio_handler vlapic_mmio_handler;
 extern const struct hvm_mmio_handler vioapic_mmio_handler;
 extern const struct hvm_mmio_handler msixtbl_mmio_handler;
+extern const struct hvm_mmio_handler iommu_mmio_handler;
 
-#define HVM_MMIO_HANDLER_NR 4
+#define HVM_MMIO_HANDLER_NR 5
 
 int hvm_io_intercept(ioreq_t *p, int type);
 void register_io_handler(


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 15:36:31 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 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.xensource.com>)
	id 1RaqsW-0002wE-RA; Wed, 14 Dec 2011 15:36:20 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Wang2@amd.com>) id 1RaqsV-0002uE-9M
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 15:36:19 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1323876923!7262181!1
X-Originating-IP: [213.199.154.208]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24728 invoked from network); 14 Dec 2011 15:35:23 -0000
Received: from am1ehsobe005.messaging.microsoft.com (HELO
	AM1EHSOBE005.bigfish.com) (213.199.154.208)
	by server-6.tower-182.messagelabs.com with AES128-SHA encrypted SMTP;
	14 Dec 2011 15:35:23 -0000
Received: from mail60-am1-R.bigfish.com (10.3.201.241) by
	AM1EHSOBE005.bigfish.com (10.3.204.25) with Microsoft SMTP Server id
	14.1.225.23; Wed, 14 Dec 2011 15:35:24 +0000
Received: from mail60-am1 (localhost [127.0.0.1])	by mail60-am1-R.bigfish.com
	(Postfix) with ESMTP id B8A7D2A00CE;
	Wed, 14 Dec 2011 15:35:25 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzzz1202hzz8275bhz2dh668h839h944h)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
Received: from mail60-am1 (localhost.localdomain [127.0.0.1]) by mail60-am1
	(MessageSwitch) id 1323876924364929_15233;
	Wed, 14 Dec 2011 15:35:24 +0000 (UTC)
Received: from AM1EHSMHS004.bigfish.com (unknown [10.3.201.247])	by
	mail60-am1.bigfish.com (Postfix) with ESMTP id 4FFF66E0042;
	Wed, 14 Dec 2011 15:35:24 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	AM1EHSMHS004.bigfish.com (10.3.207.104) with Microsoft SMTP Server id
	14.1.225.23; Wed, 14 Dec 2011 15:35:22 +0000
X-WSS-ID: 0LW79YS-02-A9J-02
X-M-MSG: 
Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com
	[163.181.249.73])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp02.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2729CC8086;	Wed, 14 Dec 2011 09:35:16 -0600 (CST)
Received: from SAUSEXDAG02.amd.com (163.181.55.2) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Wed, 14 Dec 2011 09:35:30 -0600
Received: from storexhtp02.amd.com (172.24.4.4) by sausexdag02.amd.com
	(163.181.55.2) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Wed, 14 Dec 2011 09:35:18 -0600
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Wed, 14 Dec 2011
	10:35:16 -0500
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 6F10A49C660; Wed, 14 Dec 2011
	15:35:11 +0000 (GMT)
Received: from gran.amd.com (gran.osrc.amd.com [165.204.15.57])	by
	mail.osrc.amd.com (Postfix) with ESMTP id 5D9CF594886; Wed, 14 Dec 2011
	16:35:11 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: fbed4e6011fce13d3a521bbc339f4959bf32a06c
Message-ID: <fbed4e6011fce13d3a52.1323876567@gran.amd.com>
In-Reply-To: <patchbomb.1323876561@gran.amd.com>
References: <patchbomb.1323876561@gran.amd.com>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Wed, 14 Dec 2011 16:29:27 +0100
From: Wei Wang <wei.wang2@amd.com>
To: <JBeulich@suse.com>, <keir@xen.org>
X-OriginatorOrg: amd.com
Cc: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 06 of 16] amd iommu: add ppr log processing into
 iommu interrupt handling
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Wei Wang <wei.wang2@amd.com>
# Date 1323875771 -3600
# Node ID fbed4e6011fce13d3a521bbc339f4959bf32a06c
# Parent  be3f15ae6a4153504bbb3376291a2383684afee5
amd iommu: add ppr log processing into iommu interrupt handling
PPR log and event log share the same interrupt source. Interrupt handler
should check both of them.

Signed-off-by: Wei Wang <wei.wang2@amd.com>

diff -r be3f15ae6a41 -r fbed4e6011fc xen/drivers/passthrough/amd/iommu_init.c
--- a/xen/drivers/passthrough/amd/iommu_init.c	Wed Dec 14 16:16:10 2011 +0100
+++ b/xen/drivers/passthrough/amd/iommu_init.c	Wed Dec 14 16:16:11 2011 +0100
@@ -352,75 +352,91 @@ static void set_iommu_ppr_log_control(st
         AMD_IOMMU_DEBUG("PPR Log Enabled.\n");
 }
 
-static void parse_event_log_entry(struct amd_iommu *, u32 entry[]);
+/* read event log or ppr log from iommu ring buffer */
+static int iommu_read_log(struct amd_iommu *iommu, 
+                          struct ring_buffer *log,
+                          void (*parse_func)(struct amd_iommu *, u32 *))
+{
+    u32 tail, head, *entry, tail_offest, head_offset;
 
-static int amd_iommu_read_event_log(struct amd_iommu *iommu)
-{
-    u32 tail, head, *event_log;
-
-    BUG_ON( !iommu );
+    BUG_ON( !iommu || ((log != &iommu->event_log) && 
+            (log != &iommu->ppr_log)) );
 
     /* make sure there's an entry in the log */
-    tail = readl(iommu->mmio_base + IOMMU_EVENT_LOG_TAIL_OFFSET);
-    tail = get_field_from_reg_u32(tail,
-                                  IOMMU_EVENT_LOG_TAIL_MASK,
-                                  IOMMU_EVENT_LOG_TAIL_SHIFT);
+    tail_offest = ( log == &iommu->event_log ) ?
+        IOMMU_EVENT_LOG_TAIL_OFFSET:
+        IOMMU_PPR_LOG_TAIL_OFFSET;
 
-    while ( tail != iommu->event_log.head )
+    head_offset = ( log == &iommu->event_log ) ?
+        IOMMU_EVENT_LOG_HEAD_OFFSET:
+        IOMMU_PPR_LOG_HEAD_OFFSET;
+
+    tail = readl(iommu->mmio_base + tail_offest);
+    tail = iommu_get_rb_pointer(tail);
+
+    while ( tail != log->head )
     {
         /* read event log entry */
-        event_log = (u32 *)(iommu->event_log.buffer +
-                           (iommu->event_log.head *
-                           IOMMU_EVENT_LOG_ENTRY_SIZE));
+        entry = (u32 *)(log->buffer + log->head * log->entry_size);
 
-        parse_event_log_entry(iommu, event_log);
-
-        if ( ++iommu->event_log.head == iommu->event_log.entries )
-            iommu->event_log.head = 0;
+        parse_func(iommu, entry);
+        if ( ++log->head == log->entries )
+            log->head = 0;
 
         /* update head pointer */
-        set_field_in_reg_u32(iommu->event_log.head, 0,
-                             IOMMU_EVENT_LOG_HEAD_MASK,
-                             IOMMU_EVENT_LOG_HEAD_SHIFT, &head);
-        writel(head, iommu->mmio_base + IOMMU_EVENT_LOG_HEAD_OFFSET);
+        head = 0;
+        iommu_set_rb_pointer(&head, log->head);
+
+        writel(head, iommu->mmio_base + head_offset);
     }
 
     return 0;
 }
 
-static void amd_iommu_reset_event_log(struct amd_iommu *iommu)
+/* reset event log or ppr log when overflow */
+static void iommu_reset_log(struct amd_iommu *iommu,
+                            struct ring_buffer *log,
+                            void (*ctrl_func)(struct amd_iommu *iommu, int))
 {
     u32 entry;
-    int log_run;
+    int log_run, run_bit, of_bit;
     int loop_count = 1000;
 
+    BUG_ON( !iommu || ((log != &iommu->event_log) && 
+            (log != &iommu->ppr_log)) );
+
+    run_bit = ( log == &iommu->event_log ) ?
+        IOMMU_STATUS_EVENT_LOG_RUN_SHIFT:
+        IOMMU_STATUS_PPR_LOG_RUN_SHIFT;
+
+    of_bit = ( log == &iommu->event_log ) ?
+        IOMMU_STATUS_EVENT_OVERFLOW_SHIFT:
+        IOMMU_STATUS_PPR_LOG_OVERFLOW_SHIFT;
+
     /* wait until EventLogRun bit = 0 */
     do {
         entry = readl(iommu->mmio_base + IOMMU_STATUS_MMIO_OFFSET);
-        log_run = iommu_get_bit(entry, IOMMU_STATUS_EVENT_LOG_RUN_SHIFT);
+        log_run = iommu_get_bit(entry, run_bit);
         loop_count--;
     } while ( log_run && loop_count );
 
     if ( log_run )
     {
-        AMD_IOMMU_DEBUG("Warning: EventLogRun bit is not cleared"
-                        "before reset!\n");
+        AMD_IOMMU_DEBUG("Warning: Log Run bit %d is not cleared"
+                        "before reset! \n", run_bit);
         return;
     }
 
-    set_iommu_event_log_control(iommu, IOMMU_CONTROL_DISABLED);
+    ctrl_func(iommu, IOMMU_CONTROL_DISABLED);
 
-    /* read event log for debugging */
-    amd_iommu_read_event_log(iommu);
     /*clear overflow bit */
-    iommu_clear_bit(&entry, IOMMU_STATUS_EVENT_OVERFLOW_SHIFT);
-
-    writel(entry, iommu->mmio_base+IOMMU_STATUS_MMIO_OFFSET);
+    iommu_clear_bit(&entry, of_bit);
+    writel(entry, iommu->mmio_base + IOMMU_STATUS_MMIO_OFFSET);
 
     /*reset event log base address */
-    iommu->event_log.head = 0;
+    log->head = 0;
 
-    set_iommu_event_log_control(iommu, IOMMU_CONTROL_ENABLED);
+    ctrl_func(iommu, IOMMU_CONTROL_ENABLED);
 }
 
 static void iommu_msi_set_affinity(struct irq_desc *desc, const cpumask_t *mask)
@@ -592,30 +608,93 @@ static void parse_event_log_entry(struct
     }
 }
 
-static void amd_iommu_page_fault(int irq, void *dev_id,
-                             struct cpu_user_regs *regs)
+static void iommu_check_event_log(struct amd_iommu *iommu)
 {
     u32 entry;
     unsigned long flags;
-    struct amd_iommu *iommu = dev_id;
 
     spin_lock_irqsave(&iommu->lock, flags);
-    amd_iommu_read_event_log(iommu);
+
+    iommu_read_log(iommu, &iommu->event_log, parse_event_log_entry);
 
     /*check event overflow */
     entry = readl(iommu->mmio_base + IOMMU_STATUS_MMIO_OFFSET);
 
     if ( iommu_get_bit(entry, IOMMU_STATUS_EVENT_OVERFLOW_SHIFT) )
-        amd_iommu_reset_event_log(iommu);
+        iommu_reset_log(iommu, &iommu->event_log, set_iommu_event_log_control);
 
     /* reset interrupt status bit */
     entry = readl(iommu->mmio_base + IOMMU_STATUS_MMIO_OFFSET);
     iommu_set_bit(&entry, IOMMU_STATUS_EVENT_LOG_INT_SHIFT);
 
-    writel(entry, iommu->mmio_base+IOMMU_STATUS_MMIO_OFFSET);
+    writel(entry, iommu->mmio_base + IOMMU_STATUS_MMIO_OFFSET);
+
     spin_unlock_irqrestore(&iommu->lock, flags);
 }
 
+void parse_ppr_log_entry(struct amd_iommu *iommu, u32 entry[])
+{
+
+    u16 device_id;
+    u8 bus, devfn;
+    struct pci_dev *pdev;
+    struct domain *d;
+
+    /* here device_id is physical value */
+    device_id = iommu_get_devid_from_cmd(entry[0]);
+    bus = device_id >> 8;
+    devfn = device_id & 0xFF;
+
+    local_irq_enable();
+
+    spin_lock(&pcidevs_lock);
+    pdev = pci_get_pdev(0, bus, devfn);
+    spin_unlock(&pcidevs_lock);
+
+    local_irq_disable();
+
+    if ( pdev == NULL )
+        return; 
+
+    d = pdev->domain;
+
+    guest_iommu_add_ppr_log(d, entry);
+}
+
+static void iommu_check_ppr_log(struct amd_iommu *iommu)
+{
+    u32 entry;
+    unsigned long flags;
+
+    spin_lock_irqsave(&iommu->lock, flags);
+
+    iommu_read_log(iommu, &iommu->ppr_log, parse_ppr_log_entry);
+
+    /*check event overflow */
+    entry = readl(iommu->mmio_base + IOMMU_STATUS_MMIO_OFFSET);
+
+    if ( iommu_get_bit(entry, IOMMU_STATUS_PPR_LOG_OVERFLOW_SHIFT) )
+        iommu_reset_log(iommu, &iommu->ppr_log, set_iommu_ppr_log_control);
+
+    /* reset interrupt status bit */
+    entry = readl(iommu->mmio_base + IOMMU_STATUS_MMIO_OFFSET);
+    iommu_set_bit(&entry, IOMMU_STATUS_PPR_LOG_INT_SHIFT);
+
+    writel(entry, iommu->mmio_base + IOMMU_STATUS_MMIO_OFFSET);
+
+    spin_unlock_irqrestore(&iommu->lock, flags);
+}
+
+static void iommu_interrupt_handler(int irq, void *dev_id,
+                                    struct cpu_user_regs *regs)
+{
+    struct amd_iommu *iommu = dev_id;
+    iommu_check_event_log(iommu);
+
+    if ( iommu->ppr_log.buffer != NULL )
+        iommu_check_ppr_log(iommu);
+}
+
 static int __init set_iommu_interrupt_handler(struct amd_iommu *iommu)
 {
     int irq, ret;
@@ -628,8 +707,7 @@ static int __init set_iommu_interrupt_ha
     }
     
     irq_desc[irq].handler = &iommu_msi_type;
-    ret = request_irq(irq, amd_iommu_page_fault, 0,
-                             "amd_iommu", iommu);
+    ret = request_irq(irq, iommu_interrupt_handler, 0, "amd_iommu", iommu);
     if ( ret )
     {
         irq_desc[irq].handler = &no_irq_type;


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 15:36:31 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 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.xensource.com>)
	id 1RaqsT-0002ug-CW; Wed, 14 Dec 2011 15:36:17 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Wang2@amd.com>) id 1RaqsS-0002u4-BO
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 15:36:16 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1323876920!6728386!1
X-Originating-IP: [213.199.154.208]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8273 invoked from network); 14 Dec 2011 15:35:20 -0000
Received: from am1ehsobe005.messaging.microsoft.com (HELO
	AM1EHSOBE005.bigfish.com) (213.199.154.208)
	by server-13.tower-182.messagelabs.com with AES128-SHA encrypted SMTP;
	14 Dec 2011 15:35:20 -0000
Received: from mail45-am1-R.bigfish.com (10.3.201.240) by
	AM1EHSOBE005.bigfish.com (10.3.204.25) with Microsoft SMTP Server id
	14.1.225.23; Wed, 14 Dec 2011 15:35:22 +0000
Received: from mail45-am1 (localhost [127.0.0.1])	by mail45-am1-R.bigfish.com
	(Postfix) with ESMTP id 559C13C01F7;
	Wed, 14 Dec 2011 15:35:23 +0000 (UTC)
X-SpamScore: -4
X-BigFish: VPS-4(zz4015Lzz1202hzzz2dh668h839h944h)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
X-FB-SS: 13,
Received: from mail45-am1 (localhost.localdomain [127.0.0.1]) by mail45-am1
	(MessageSwitch) id 1323876923255414_19789;
	Wed, 14 Dec 2011 15:35:23 +0000 (UTC)
Received: from AM1EHSMHS005.bigfish.com (unknown [10.3.201.247])	by
	mail45-am1.bigfish.com (Postfix) with ESMTP id 391152C0042;
	Wed, 14 Dec 2011 15:35:23 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	AM1EHSMHS005.bigfish.com (10.3.207.105) with Microsoft SMTP Server id
	14.1.225.23; Wed, 14 Dec 2011 15:35:21 +0000
X-WSS-ID: 0LW79YR-02-A97-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp02.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2B01BC808A;	Wed, 14 Dec 2011 09:35:15 -0600 (CST)
Received: from SAUSEXDAG01.amd.com (163.181.55.1) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Wed, 14 Dec 2011 09:35:28 -0600
Received: from storexhtp01.amd.com (172.24.4.3) by sausexdag01.amd.com
	(163.181.55.1) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Wed, 14 Dec 2011 09:35:16 -0600
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp01.amd.com
	(172.24.4.3) with Microsoft SMTP Server id 8.3.213.0; Wed, 14 Dec 2011
	10:35:12 -0500
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 0025F49C1FF; Wed, 14 Dec 2011
	15:35:11 +0000 (GMT)
Received: from gran.amd.com (gran.osrc.amd.com [165.204.15.57])	by
	mail.osrc.amd.com (Postfix) with ESMTP id E080B5940FF; Wed, 14 Dec 2011
	16:35:10 +0100 (CET)
MIME-Version: 1.0
Message-ID: <patchbomb.1323876561@gran.amd.com>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Wed, 14 Dec 2011 16:29:21 +0100
From: Wei Wang <wei.wang2@amd.com>
To: <JBeulich@suse.com>, <keir@xen.org>
X-OriginatorOrg: amd.com
Cc: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 00 of 16] [RFC] amd iommu: support ATS device
 passthru on IOMMUv2 systems
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

ATS devices with PRI and PASID capabilities can communicate with iommuv2 to 
do 2 level (nested) DMA translation and IO demand paging. To do that, both 
iommu driver and ats device have to been enabled in guest OS. This patch set 
adds initial iommu emulation for hvm guests to support ATS device passthru. 
Please review.
Thanks,

Wei 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 15:36:31 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 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.xensource.com>)
	id 1RaqsW-0002wE-RA; Wed, 14 Dec 2011 15:36:20 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Wang2@amd.com>) id 1RaqsV-0002uE-9M
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 15:36:19 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1323876923!7262181!1
X-Originating-IP: [213.199.154.208]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24728 invoked from network); 14 Dec 2011 15:35:23 -0000
Received: from am1ehsobe005.messaging.microsoft.com (HELO
	AM1EHSOBE005.bigfish.com) (213.199.154.208)
	by server-6.tower-182.messagelabs.com with AES128-SHA encrypted SMTP;
	14 Dec 2011 15:35:23 -0000
Received: from mail60-am1-R.bigfish.com (10.3.201.241) by
	AM1EHSOBE005.bigfish.com (10.3.204.25) with Microsoft SMTP Server id
	14.1.225.23; Wed, 14 Dec 2011 15:35:24 +0000
Received: from mail60-am1 (localhost [127.0.0.1])	by mail60-am1-R.bigfish.com
	(Postfix) with ESMTP id B8A7D2A00CE;
	Wed, 14 Dec 2011 15:35:25 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzzz1202hzz8275bhz2dh668h839h944h)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
Received: from mail60-am1 (localhost.localdomain [127.0.0.1]) by mail60-am1
	(MessageSwitch) id 1323876924364929_15233;
	Wed, 14 Dec 2011 15:35:24 +0000 (UTC)
Received: from AM1EHSMHS004.bigfish.com (unknown [10.3.201.247])	by
	mail60-am1.bigfish.com (Postfix) with ESMTP id 4FFF66E0042;
	Wed, 14 Dec 2011 15:35:24 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	AM1EHSMHS004.bigfish.com (10.3.207.104) with Microsoft SMTP Server id
	14.1.225.23; Wed, 14 Dec 2011 15:35:22 +0000
X-WSS-ID: 0LW79YS-02-A9J-02
X-M-MSG: 
Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com
	[163.181.249.73])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp02.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2729CC8086;	Wed, 14 Dec 2011 09:35:16 -0600 (CST)
Received: from SAUSEXDAG02.amd.com (163.181.55.2) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Wed, 14 Dec 2011 09:35:30 -0600
Received: from storexhtp02.amd.com (172.24.4.4) by sausexdag02.amd.com
	(163.181.55.2) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Wed, 14 Dec 2011 09:35:18 -0600
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Wed, 14 Dec 2011
	10:35:16 -0500
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 6F10A49C660; Wed, 14 Dec 2011
	15:35:11 +0000 (GMT)
Received: from gran.amd.com (gran.osrc.amd.com [165.204.15.57])	by
	mail.osrc.amd.com (Postfix) with ESMTP id 5D9CF594886; Wed, 14 Dec 2011
	16:35:11 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: fbed4e6011fce13d3a521bbc339f4959bf32a06c
Message-ID: <fbed4e6011fce13d3a52.1323876567@gran.amd.com>
In-Reply-To: <patchbomb.1323876561@gran.amd.com>
References: <patchbomb.1323876561@gran.amd.com>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Wed, 14 Dec 2011 16:29:27 +0100
From: Wei Wang <wei.wang2@amd.com>
To: <JBeulich@suse.com>, <keir@xen.org>
X-OriginatorOrg: amd.com
Cc: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 06 of 16] amd iommu: add ppr log processing into
 iommu interrupt handling
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Wei Wang <wei.wang2@amd.com>
# Date 1323875771 -3600
# Node ID fbed4e6011fce13d3a521bbc339f4959bf32a06c
# Parent  be3f15ae6a4153504bbb3376291a2383684afee5
amd iommu: add ppr log processing into iommu interrupt handling
PPR log and event log share the same interrupt source. Interrupt handler
should check both of them.

Signed-off-by: Wei Wang <wei.wang2@amd.com>

diff -r be3f15ae6a41 -r fbed4e6011fc xen/drivers/passthrough/amd/iommu_init.c
--- a/xen/drivers/passthrough/amd/iommu_init.c	Wed Dec 14 16:16:10 2011 +0100
+++ b/xen/drivers/passthrough/amd/iommu_init.c	Wed Dec 14 16:16:11 2011 +0100
@@ -352,75 +352,91 @@ static void set_iommu_ppr_log_control(st
         AMD_IOMMU_DEBUG("PPR Log Enabled.\n");
 }
 
-static void parse_event_log_entry(struct amd_iommu *, u32 entry[]);
+/* read event log or ppr log from iommu ring buffer */
+static int iommu_read_log(struct amd_iommu *iommu, 
+                          struct ring_buffer *log,
+                          void (*parse_func)(struct amd_iommu *, u32 *))
+{
+    u32 tail, head, *entry, tail_offest, head_offset;
 
-static int amd_iommu_read_event_log(struct amd_iommu *iommu)
-{
-    u32 tail, head, *event_log;
-
-    BUG_ON( !iommu );
+    BUG_ON( !iommu || ((log != &iommu->event_log) && 
+            (log != &iommu->ppr_log)) );
 
     /* make sure there's an entry in the log */
-    tail = readl(iommu->mmio_base + IOMMU_EVENT_LOG_TAIL_OFFSET);
-    tail = get_field_from_reg_u32(tail,
-                                  IOMMU_EVENT_LOG_TAIL_MASK,
-                                  IOMMU_EVENT_LOG_TAIL_SHIFT);
+    tail_offest = ( log == &iommu->event_log ) ?
+        IOMMU_EVENT_LOG_TAIL_OFFSET:
+        IOMMU_PPR_LOG_TAIL_OFFSET;
 
-    while ( tail != iommu->event_log.head )
+    head_offset = ( log == &iommu->event_log ) ?
+        IOMMU_EVENT_LOG_HEAD_OFFSET:
+        IOMMU_PPR_LOG_HEAD_OFFSET;
+
+    tail = readl(iommu->mmio_base + tail_offest);
+    tail = iommu_get_rb_pointer(tail);
+
+    while ( tail != log->head )
     {
         /* read event log entry */
-        event_log = (u32 *)(iommu->event_log.buffer +
-                           (iommu->event_log.head *
-                           IOMMU_EVENT_LOG_ENTRY_SIZE));
+        entry = (u32 *)(log->buffer + log->head * log->entry_size);
 
-        parse_event_log_entry(iommu, event_log);
-
-        if ( ++iommu->event_log.head == iommu->event_log.entries )
-            iommu->event_log.head = 0;
+        parse_func(iommu, entry);
+        if ( ++log->head == log->entries )
+            log->head = 0;
 
         /* update head pointer */
-        set_field_in_reg_u32(iommu->event_log.head, 0,
-                             IOMMU_EVENT_LOG_HEAD_MASK,
-                             IOMMU_EVENT_LOG_HEAD_SHIFT, &head);
-        writel(head, iommu->mmio_base + IOMMU_EVENT_LOG_HEAD_OFFSET);
+        head = 0;
+        iommu_set_rb_pointer(&head, log->head);
+
+        writel(head, iommu->mmio_base + head_offset);
     }
 
     return 0;
 }
 
-static void amd_iommu_reset_event_log(struct amd_iommu *iommu)
+/* reset event log or ppr log when overflow */
+static void iommu_reset_log(struct amd_iommu *iommu,
+                            struct ring_buffer *log,
+                            void (*ctrl_func)(struct amd_iommu *iommu, int))
 {
     u32 entry;
-    int log_run;
+    int log_run, run_bit, of_bit;
     int loop_count = 1000;
 
+    BUG_ON( !iommu || ((log != &iommu->event_log) && 
+            (log != &iommu->ppr_log)) );
+
+    run_bit = ( log == &iommu->event_log ) ?
+        IOMMU_STATUS_EVENT_LOG_RUN_SHIFT:
+        IOMMU_STATUS_PPR_LOG_RUN_SHIFT;
+
+    of_bit = ( log == &iommu->event_log ) ?
+        IOMMU_STATUS_EVENT_OVERFLOW_SHIFT:
+        IOMMU_STATUS_PPR_LOG_OVERFLOW_SHIFT;
+
     /* wait until EventLogRun bit = 0 */
     do {
         entry = readl(iommu->mmio_base + IOMMU_STATUS_MMIO_OFFSET);
-        log_run = iommu_get_bit(entry, IOMMU_STATUS_EVENT_LOG_RUN_SHIFT);
+        log_run = iommu_get_bit(entry, run_bit);
         loop_count--;
     } while ( log_run && loop_count );
 
     if ( log_run )
     {
-        AMD_IOMMU_DEBUG("Warning: EventLogRun bit is not cleared"
-                        "before reset!\n");
+        AMD_IOMMU_DEBUG("Warning: Log Run bit %d is not cleared"
+                        "before reset! \n", run_bit);
         return;
     }
 
-    set_iommu_event_log_control(iommu, IOMMU_CONTROL_DISABLED);
+    ctrl_func(iommu, IOMMU_CONTROL_DISABLED);
 
-    /* read event log for debugging */
-    amd_iommu_read_event_log(iommu);
     /*clear overflow bit */
-    iommu_clear_bit(&entry, IOMMU_STATUS_EVENT_OVERFLOW_SHIFT);
-
-    writel(entry, iommu->mmio_base+IOMMU_STATUS_MMIO_OFFSET);
+    iommu_clear_bit(&entry, of_bit);
+    writel(entry, iommu->mmio_base + IOMMU_STATUS_MMIO_OFFSET);
 
     /*reset event log base address */
-    iommu->event_log.head = 0;
+    log->head = 0;
 
-    set_iommu_event_log_control(iommu, IOMMU_CONTROL_ENABLED);
+    ctrl_func(iommu, IOMMU_CONTROL_ENABLED);
 }
 
 static void iommu_msi_set_affinity(struct irq_desc *desc, const cpumask_t *mask)
@@ -592,30 +608,93 @@ static void parse_event_log_entry(struct
     }
 }
 
-static void amd_iommu_page_fault(int irq, void *dev_id,
-                             struct cpu_user_regs *regs)
+static void iommu_check_event_log(struct amd_iommu *iommu)
 {
     u32 entry;
     unsigned long flags;
-    struct amd_iommu *iommu = dev_id;
 
     spin_lock_irqsave(&iommu->lock, flags);
-    amd_iommu_read_event_log(iommu);
+
+    iommu_read_log(iommu, &iommu->event_log, parse_event_log_entry);
 
     /*check event overflow */
     entry = readl(iommu->mmio_base + IOMMU_STATUS_MMIO_OFFSET);
 
     if ( iommu_get_bit(entry, IOMMU_STATUS_EVENT_OVERFLOW_SHIFT) )
-        amd_iommu_reset_event_log(iommu);
+        iommu_reset_log(iommu, &iommu->event_log, set_iommu_event_log_control);
 
     /* reset interrupt status bit */
     entry = readl(iommu->mmio_base + IOMMU_STATUS_MMIO_OFFSET);
     iommu_set_bit(&entry, IOMMU_STATUS_EVENT_LOG_INT_SHIFT);
 
-    writel(entry, iommu->mmio_base+IOMMU_STATUS_MMIO_OFFSET);
+    writel(entry, iommu->mmio_base + IOMMU_STATUS_MMIO_OFFSET);
+
     spin_unlock_irqrestore(&iommu->lock, flags);
 }
 
+void parse_ppr_log_entry(struct amd_iommu *iommu, u32 entry[])
+{
+
+    u16 device_id;
+    u8 bus, devfn;
+    struct pci_dev *pdev;
+    struct domain *d;
+
+    /* here device_id is physical value */
+    device_id = iommu_get_devid_from_cmd(entry[0]);
+    bus = device_id >> 8;
+    devfn = device_id & 0xFF;
+
+    local_irq_enable();
+
+    spin_lock(&pcidevs_lock);
+    pdev = pci_get_pdev(0, bus, devfn);
+    spin_unlock(&pcidevs_lock);
+
+    local_irq_disable();
+
+    if ( pdev == NULL )
+        return; 
+
+    d = pdev->domain;
+
+    guest_iommu_add_ppr_log(d, entry);
+}
+
+static void iommu_check_ppr_log(struct amd_iommu *iommu)
+{
+    u32 entry;
+    unsigned long flags;
+
+    spin_lock_irqsave(&iommu->lock, flags);
+
+    iommu_read_log(iommu, &iommu->ppr_log, parse_ppr_log_entry);
+
+    /*check event overflow */
+    entry = readl(iommu->mmio_base + IOMMU_STATUS_MMIO_OFFSET);
+
+    if ( iommu_get_bit(entry, IOMMU_STATUS_PPR_LOG_OVERFLOW_SHIFT) )
+        iommu_reset_log(iommu, &iommu->ppr_log, set_iommu_ppr_log_control);
+
+    /* reset interrupt status bit */
+    entry = readl(iommu->mmio_base + IOMMU_STATUS_MMIO_OFFSET);
+    iommu_set_bit(&entry, IOMMU_STATUS_PPR_LOG_INT_SHIFT);
+
+    writel(entry, iommu->mmio_base + IOMMU_STATUS_MMIO_OFFSET);
+
+    spin_unlock_irqrestore(&iommu->lock, flags);
+}
+
+static void iommu_interrupt_handler(int irq, void *dev_id,
+                                    struct cpu_user_regs *regs)
+{
+    struct amd_iommu *iommu = dev_id;
+    iommu_check_event_log(iommu);
+
+    if ( iommu->ppr_log.buffer != NULL )
+        iommu_check_ppr_log(iommu);
+}
+
 static int __init set_iommu_interrupt_handler(struct amd_iommu *iommu)
 {
     int irq, ret;
@@ -628,8 +707,7 @@ static int __init set_iommu_interrupt_ha
     }
     
     irq_desc[irq].handler = &iommu_msi_type;
-    ret = request_irq(irq, amd_iommu_page_fault, 0,
-                             "amd_iommu", iommu);
+    ret = request_irq(irq, iommu_interrupt_handler, 0, "amd_iommu", iommu);
     if ( ret )
     {
         irq_desc[irq].handler = &no_irq_type;


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 15:36:31 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 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.xensource.com>)
	id 1RaqsY-0002wt-2u; Wed, 14 Dec 2011 15:36:22 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Wang2@amd.com>) id 1RaqsV-0002uK-UH
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 15:36:20 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1323876924!5544147!1
X-Originating-IP: [213.199.154.206]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2352 invoked from network); 14 Dec 2011 15:35:24 -0000
Received: from am1ehsobe003.messaging.microsoft.com (HELO
	AM1EHSOBE003.bigfish.com) (213.199.154.206)
	by server-4.tower-174.messagelabs.com with AES128-SHA encrypted SMTP;
	14 Dec 2011 15:35:24 -0000
Received: from mail116-am1-R.bigfish.com (10.3.201.246) by
	AM1EHSOBE003.bigfish.com (10.3.204.23) with Microsoft SMTP Server id
	14.1.225.23; Wed, 14 Dec 2011 15:35:26 +0000
Received: from mail116-am1 (localhost [127.0.0.1])	by
	mail116-am1-R.bigfish.com (Postfix) with ESMTP id 0F89B6C01CB;
	Wed, 14 Dec 2011 15:35:27 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzzz1202hzz8275bhz2dh668h839h944h)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
Received: from mail116-am1 (localhost.localdomain [127.0.0.1]) by mail116-am1
	(MessageSwitch) id 1323876926887018_20175;
	Wed, 14 Dec 2011 15:35:26 +0000 (UTC)
Received: from AM1EHSMHS011.bigfish.com (unknown [10.3.201.244])	by
	mail116-am1.bigfish.com (Postfix) with ESMTP id B9B82700054;
	Wed, 14 Dec 2011 15:35:26 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	AM1EHSMHS011.bigfish.com (10.3.207.111) with Microsoft SMTP Server id
	14.1.225.23; Wed, 14 Dec 2011 15:35:24 +0000
X-WSS-ID: 0LW79YU-02-A9S-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp02.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2EE9AC807F;	Wed, 14 Dec 2011 09:35:17 -0600 (CST)
Received: from SAUSEXDAG01.amd.com (163.181.55.1) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Wed, 14 Dec 2011 09:35:31 -0600
Received: from storexhtp01.amd.com (172.24.4.3) by sausexdag01.amd.com
	(163.181.55.1) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Wed, 14 Dec 2011 09:35:19 -0600
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp01.amd.com
	(172.24.4.3) with Microsoft SMTP Server id 8.3.213.0; Wed, 14 Dec 2011
	10:35:16 -0500
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id C4E2849C664; Wed, 14 Dec 2011
	15:35:11 +0000 (GMT)
Received: from gran.amd.com (gran.osrc.amd.com [165.204.15.57])	by
	mail.osrc.amd.com (Postfix) with ESMTP id B0EC8594882; Wed, 14 Dec 2011
	16:35:11 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 001681ff1a0c09c4d04fd8bd45e8d26805686246
Message-ID: <001681ff1a0c09c4d04f.1323876571@gran.amd.com>
In-Reply-To: <patchbomb.1323876561@gran.amd.com>
References: <patchbomb.1323876561@gran.amd.com>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Wed, 14 Dec 2011 16:29:31 +0100
From: Wei Wang <wei.wang2@amd.com>
To: <JBeulich@suse.com>, <keir@xen.org>
X-OriginatorOrg: amd.com
Cc: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 10 of 16] amd iommu: Enable FC bit in iommu host
	level PTE
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Wei Wang <wei.wang2@amd.com>
# Date 1323875775 -3600
# Node ID 001681ff1a0c09c4d04fd8bd45e8d26805686246
# Parent  f33af4d61321d074a4c624d909204fce5945f61b
amd iommu: Enable FC bit in iommu host level PTE

Signed-off-by: Wei Wang <wei.wang2@amd.com>

diff -r f33af4d61321 -r 001681ff1a0c xen/drivers/passthrough/amd/iommu_map.c
--- a/xen/drivers/passthrough/amd/iommu_map.c	Wed Dec 14 16:16:14 2011 +0100
+++ b/xen/drivers/passthrough/amd/iommu_map.c	Wed Dec 14 16:16:15 2011 +0100
@@ -83,6 +83,11 @@ static bool_t set_iommu_pde_present(u32 
     set_field_in_reg_u32(ir, entry,
                          IOMMU_PDE_IO_READ_PERMISSION_MASK,
                          IOMMU_PDE_IO_READ_PERMISSION_SHIFT, &entry);
+
+    /* IOMMUv2 needs FC bit enabled  */
+    if ( next_level == IOMMU_PAGING_MODE_LEVEL_0 )
+        set_field_in_reg_u32(IOMMU_CONTROL_ENABLED, entry,
+                             IOMMU_PTE_FC_MASK, IOMMU_PTE_FC_SHIFT, &entry);
     pde[1] = entry;
 
     /* mark next level as 'present' */


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 15:36:31 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 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.xensource.com>)
	id 1Raqsb-00030l-Qr; Wed, 14 Dec 2011 15:36:25 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Wang2@amd.com>) id 1RaqsZ-0002v4-DB
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 15:36:23 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1323876926!7249150!1
X-Originating-IP: [216.32.181.184]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8287 invoked from network); 14 Dec 2011 15:35:27 -0000
Received: from ch1ehsobe004.messaging.microsoft.com (HELO
	ch1outboundpool.messaging.microsoft.com) (216.32.181.184)
	by server-9.tower-182.messagelabs.com with AES128-SHA encrypted SMTP;
	14 Dec 2011 15:35:27 -0000
Received: from mail25-ch1-R.bigfish.com (10.43.68.254) by
	CH1EHSOBE005.bigfish.com (10.43.70.55) with Microsoft SMTP Server id
	14.1.225.23; Wed, 14 Dec 2011 15:35:28 +0000
Received: from mail25-ch1 (localhost [127.0.0.1])	by mail25-ch1-R.bigfish.com
	(Postfix) with ESMTP id 654632000F1;
	Wed, 14 Dec 2011 15:35:29 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzzz1202hzz8275bhz2dh668h839h944h)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
Received: from mail25-ch1 (localhost.localdomain [127.0.0.1]) by mail25-ch1
	(MessageSwitch) id 1323876927218701_3926;
	Wed, 14 Dec 2011 15:35:27 +0000 (UTC)
Received: from CH1EHSMHS007.bigfish.com (snatpool1.int.messaging.microsoft.com
	[10.43.68.254])	by mail25-ch1.bigfish.com (Postfix) with ESMTP id
	30AEC180048;	Wed, 14 Dec 2011 15:35:27 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	CH1EHSMHS007.bigfish.com (10.43.70.7) with Microsoft SMTP Server id
	14.1.225.23; Wed, 14 Dec 2011 15:35:23 +0000
X-WSS-ID: 0LW79YV-01-C4M-02
X-M-MSG: 
Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com
	[163.181.249.73])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2ABC51028059;	Wed, 14 Dec 2011 09:35:18 -0600 (CST)
Received: from SAUSEXDAG02.amd.com (163.181.55.2) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Wed, 14 Dec 2011 09:35:31 -0600
Received: from storexhtp02.amd.com (172.24.4.4) by sausexdag02.amd.com
	(163.181.55.2) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Wed, 14 Dec 2011 09:35:20 -0600
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Wed, 14 Dec 2011
	10:35:17 -0500
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 604D149C669; Wed, 14 Dec 2011
	15:35:12 +0000 (GMT)
Received: from gran.amd.com (gran.osrc.amd.com [165.204.15.57])	by
	mail.osrc.amd.com (Postfix) with ESMTP id 4883B594885; Wed, 14 Dec 2011
	16:35:12 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 93658ca85035d6a4e56e2e6602c02859974d30a4
Message-ID: <93658ca85035d6a4e56e.1323876576@gran.amd.com>
In-Reply-To: <patchbomb.1323876561@gran.amd.com>
References: <patchbomb.1323876561@gran.amd.com>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Wed, 14 Dec 2011 16:29:36 +0100
From: Wei Wang <wei.wang2@amd.com>
To: <JBeulich@suse.com>, <keir@xen.org>
X-OriginatorOrg: amd.com
Cc: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 15 of 16] libxl: Introduce a new guest config
	file parameter
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Wei Wang <wei.wang2@amd.com>
# Date 1323876143 -3600
# Node ID 93658ca85035d6a4e56e2e6602c02859974d30a4
# Parent  f9575683f10a08a86a9c73226581610fa3f7be4b
libxl: Introduce a new guest config file parameter
Use iommu = {1,0} to enable or disable guest iommu emulation.
Default value is 0.

Signed-off-by: Wei Wang <wei.wang2@amd.com>

diff -r f9575683f10a -r 93658ca85035 tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Wed Dec 14 16:22:22 2011 +0100
+++ b/tools/libxl/libxl_create.c	Wed Dec 14 16:22:23 2011 +0100
@@ -99,6 +99,7 @@ int libxl_init_build_info(libxl_ctx *ctx
         b_info->u.hvm.vpt_align = 1;
         b_info->u.hvm.timer_mode = 1;
         b_info->u.hvm.nested_hvm = 0;
+        b_info->u.hvm.iommu = 0;
         break;
     case LIBXL_DOMAIN_TYPE_PV:
         b_info->u.pv.slack_memkb = 8 * 1024;
diff -r f9575683f10a -r 93658ca85035 tools/libxl/libxl_dom.c
--- a/tools/libxl/libxl_dom.c	Wed Dec 14 16:22:22 2011 +0100
+++ b/tools/libxl/libxl_dom.c	Wed Dec 14 16:22:23 2011 +0100
@@ -266,6 +266,10 @@ static int hvm_build_set_params(xc_inter
     va_hvm = (struct hvm_info_table *)(va_map + HVM_INFO_OFFSET);
     va_hvm->apic_mode = info->u.hvm.apic;
     va_hvm->nr_vcpus = info->max_vcpus;
+
+    if ( info->u.hvm.iommu )
+         va_hvm->iommu_enabled = 1;
+
     memcpy(va_hvm->vcpu_online, &info->cur_vcpus, sizeof(info->cur_vcpus));
     for (i = 0, sum = 0; i < va_hvm->length; i++)
         sum += ((uint8_t *) va_hvm)[i];
diff -r f9575683f10a -r 93658ca85035 tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Wed Dec 14 16:22:22 2011 +0100
+++ b/tools/libxl/libxl_types.idl	Wed Dec 14 16:22:23 2011 +0100
@@ -184,6 +184,7 @@ libxl_domain_build_info = Struct("domain
                                        ("vpt_align", bool),
                                        ("timer_mode", integer),
                                        ("nested_hvm", bool),
+                                       ("iommu", bool),
                                        ])),
                  ("pv", Struct(None, [("kernel", libxl_file_reference),
                                       ("slack_memkb", uint32),
diff -r f9575683f10a -r 93658ca85035 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Wed Dec 14 16:22:22 2011 +0100
+++ b/tools/libxl/xl_cmdimpl.c	Wed Dec 14 16:22:23 2011 +0100
@@ -360,6 +360,7 @@ static void printf_info(int domid,
         printf("\t\t\t(vpt_align %d)\n", b_info->u.hvm.vpt_align);
         printf("\t\t\t(timer_mode %d)\n", b_info->u.hvm.timer_mode);
         printf("\t\t\t(nestedhvm %d)\n", b_info->u.hvm.nested_hvm);
+        printf("\t\t\t(iommu %d)\n", b_info->u.hvm.iommu);
 
         printf("\t\t\t(device_model %s)\n", dm_info->device_model ? : "default");
         printf("\t\t\t(videoram %d)\n", dm_info->videoram);
@@ -764,6 +765,8 @@ static void parse_config_data(const char
             b_info->u.hvm.timer_mode = l;
         if (!xlu_cfg_get_long (config, "nestedhvm", &l, 0))
             b_info->u.hvm.nested_hvm = l;
+        if (!xlu_cfg_get_long (config, "iommu", &l, 0))
+            b_info->u.hvm.iommu = l;
         break;
     case LIBXL_DOMAIN_TYPE_PV:
     {


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 15:36:31 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 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.xensource.com>)
	id 1RaqsT-0002ug-CW; Wed, 14 Dec 2011 15:36:17 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Wang2@amd.com>) id 1RaqsS-0002u4-BO
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 15:36:16 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1323876920!6728386!1
X-Originating-IP: [213.199.154.208]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8273 invoked from network); 14 Dec 2011 15:35:20 -0000
Received: from am1ehsobe005.messaging.microsoft.com (HELO
	AM1EHSOBE005.bigfish.com) (213.199.154.208)
	by server-13.tower-182.messagelabs.com with AES128-SHA encrypted SMTP;
	14 Dec 2011 15:35:20 -0000
Received: from mail45-am1-R.bigfish.com (10.3.201.240) by
	AM1EHSOBE005.bigfish.com (10.3.204.25) with Microsoft SMTP Server id
	14.1.225.23; Wed, 14 Dec 2011 15:35:22 +0000
Received: from mail45-am1 (localhost [127.0.0.1])	by mail45-am1-R.bigfish.com
	(Postfix) with ESMTP id 559C13C01F7;
	Wed, 14 Dec 2011 15:35:23 +0000 (UTC)
X-SpamScore: -4
X-BigFish: VPS-4(zz4015Lzz1202hzzz2dh668h839h944h)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
X-FB-SS: 13,
Received: from mail45-am1 (localhost.localdomain [127.0.0.1]) by mail45-am1
	(MessageSwitch) id 1323876923255414_19789;
	Wed, 14 Dec 2011 15:35:23 +0000 (UTC)
Received: from AM1EHSMHS005.bigfish.com (unknown [10.3.201.247])	by
	mail45-am1.bigfish.com (Postfix) with ESMTP id 391152C0042;
	Wed, 14 Dec 2011 15:35:23 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	AM1EHSMHS005.bigfish.com (10.3.207.105) with Microsoft SMTP Server id
	14.1.225.23; Wed, 14 Dec 2011 15:35:21 +0000
X-WSS-ID: 0LW79YR-02-A97-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp02.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2B01BC808A;	Wed, 14 Dec 2011 09:35:15 -0600 (CST)
Received: from SAUSEXDAG01.amd.com (163.181.55.1) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Wed, 14 Dec 2011 09:35:28 -0600
Received: from storexhtp01.amd.com (172.24.4.3) by sausexdag01.amd.com
	(163.181.55.1) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Wed, 14 Dec 2011 09:35:16 -0600
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp01.amd.com
	(172.24.4.3) with Microsoft SMTP Server id 8.3.213.0; Wed, 14 Dec 2011
	10:35:12 -0500
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 0025F49C1FF; Wed, 14 Dec 2011
	15:35:11 +0000 (GMT)
Received: from gran.amd.com (gran.osrc.amd.com [165.204.15.57])	by
	mail.osrc.amd.com (Postfix) with ESMTP id E080B5940FF; Wed, 14 Dec 2011
	16:35:10 +0100 (CET)
MIME-Version: 1.0
Message-ID: <patchbomb.1323876561@gran.amd.com>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Wed, 14 Dec 2011 16:29:21 +0100
From: Wei Wang <wei.wang2@amd.com>
To: <JBeulich@suse.com>, <keir@xen.org>
X-OriginatorOrg: amd.com
Cc: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 00 of 16] [RFC] amd iommu: support ATS device
 passthru on IOMMUv2 systems
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

ATS devices with PRI and PASID capabilities can communicate with iommuv2 to 
do 2 level (nested) DMA translation and IO demand paging. To do that, both 
iommu driver and ats device have to been enabled in guest OS. This patch set 
adds initial iommu emulation for hvm guests to support ATS device passthru. 
Please review.
Thanks,

Wei 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 15:36:31 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 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.xensource.com>)
	id 1RaqsY-0002wt-2u; Wed, 14 Dec 2011 15:36:22 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Wang2@amd.com>) id 1RaqsV-0002uK-UH
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 15:36:20 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1323876924!5544147!1
X-Originating-IP: [213.199.154.206]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2352 invoked from network); 14 Dec 2011 15:35:24 -0000
Received: from am1ehsobe003.messaging.microsoft.com (HELO
	AM1EHSOBE003.bigfish.com) (213.199.154.206)
	by server-4.tower-174.messagelabs.com with AES128-SHA encrypted SMTP;
	14 Dec 2011 15:35:24 -0000
Received: from mail116-am1-R.bigfish.com (10.3.201.246) by
	AM1EHSOBE003.bigfish.com (10.3.204.23) with Microsoft SMTP Server id
	14.1.225.23; Wed, 14 Dec 2011 15:35:26 +0000
Received: from mail116-am1 (localhost [127.0.0.1])	by
	mail116-am1-R.bigfish.com (Postfix) with ESMTP id 0F89B6C01CB;
	Wed, 14 Dec 2011 15:35:27 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzzz1202hzz8275bhz2dh668h839h944h)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
Received: from mail116-am1 (localhost.localdomain [127.0.0.1]) by mail116-am1
	(MessageSwitch) id 1323876926887018_20175;
	Wed, 14 Dec 2011 15:35:26 +0000 (UTC)
Received: from AM1EHSMHS011.bigfish.com (unknown [10.3.201.244])	by
	mail116-am1.bigfish.com (Postfix) with ESMTP id B9B82700054;
	Wed, 14 Dec 2011 15:35:26 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	AM1EHSMHS011.bigfish.com (10.3.207.111) with Microsoft SMTP Server id
	14.1.225.23; Wed, 14 Dec 2011 15:35:24 +0000
X-WSS-ID: 0LW79YU-02-A9S-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp02.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2EE9AC807F;	Wed, 14 Dec 2011 09:35:17 -0600 (CST)
Received: from SAUSEXDAG01.amd.com (163.181.55.1) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Wed, 14 Dec 2011 09:35:31 -0600
Received: from storexhtp01.amd.com (172.24.4.3) by sausexdag01.amd.com
	(163.181.55.1) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Wed, 14 Dec 2011 09:35:19 -0600
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp01.amd.com
	(172.24.4.3) with Microsoft SMTP Server id 8.3.213.0; Wed, 14 Dec 2011
	10:35:16 -0500
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id C4E2849C664; Wed, 14 Dec 2011
	15:35:11 +0000 (GMT)
Received: from gran.amd.com (gran.osrc.amd.com [165.204.15.57])	by
	mail.osrc.amd.com (Postfix) with ESMTP id B0EC8594882; Wed, 14 Dec 2011
	16:35:11 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 001681ff1a0c09c4d04fd8bd45e8d26805686246
Message-ID: <001681ff1a0c09c4d04f.1323876571@gran.amd.com>
In-Reply-To: <patchbomb.1323876561@gran.amd.com>
References: <patchbomb.1323876561@gran.amd.com>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Wed, 14 Dec 2011 16:29:31 +0100
From: Wei Wang <wei.wang2@amd.com>
To: <JBeulich@suse.com>, <keir@xen.org>
X-OriginatorOrg: amd.com
Cc: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 10 of 16] amd iommu: Enable FC bit in iommu host
	level PTE
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Wei Wang <wei.wang2@amd.com>
# Date 1323875775 -3600
# Node ID 001681ff1a0c09c4d04fd8bd45e8d26805686246
# Parent  f33af4d61321d074a4c624d909204fce5945f61b
amd iommu: Enable FC bit in iommu host level PTE

Signed-off-by: Wei Wang <wei.wang2@amd.com>

diff -r f33af4d61321 -r 001681ff1a0c xen/drivers/passthrough/amd/iommu_map.c
--- a/xen/drivers/passthrough/amd/iommu_map.c	Wed Dec 14 16:16:14 2011 +0100
+++ b/xen/drivers/passthrough/amd/iommu_map.c	Wed Dec 14 16:16:15 2011 +0100
@@ -83,6 +83,11 @@ static bool_t set_iommu_pde_present(u32 
     set_field_in_reg_u32(ir, entry,
                          IOMMU_PDE_IO_READ_PERMISSION_MASK,
                          IOMMU_PDE_IO_READ_PERMISSION_SHIFT, &entry);
+
+    /* IOMMUv2 needs FC bit enabled  */
+    if ( next_level == IOMMU_PAGING_MODE_LEVEL_0 )
+        set_field_in_reg_u32(IOMMU_CONTROL_ENABLED, entry,
+                             IOMMU_PTE_FC_MASK, IOMMU_PTE_FC_SHIFT, &entry);
     pde[1] = entry;
 
     /* mark next level as 'present' */


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 15:36:31 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 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.xensource.com>)
	id 1RaqsY-0002xb-Vs; Wed, 14 Dec 2011 15:36:22 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Wang2@amd.com>) id 1RaqsW-0002uL-0p
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 15:36:20 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1323876884!50611964!1
X-Originating-IP: [213.199.154.141]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12694 invoked from network); 14 Dec 2011 15:34:45 -0000
Received: from db3ehsobe003.messaging.microsoft.com (HELO
	DB3EHSOBE003.bigfish.com) (213.199.154.141)
	by server-6.tower-27.messagelabs.com with AES128-SHA encrypted SMTP;
	14 Dec 2011 15:34:45 -0000
Received: from mail109-db3-R.bigfish.com (10.3.81.242) by
	DB3EHSOBE003.bigfish.com (10.3.84.23) with Microsoft SMTP Server id
	14.1.225.23; Wed, 14 Dec 2011 15:35:26 +0000
Received: from mail109-db3 (localhost [127.0.0.1])	by
	mail109-db3-R.bigfish.com (Postfix) with ESMTP id 1C29E4E0060;
	Wed, 14 Dec 2011 15:35:27 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzzz1202hzz8275bhz2dh668h839h944h)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
X-FB-SS: 13,
Received: from mail109-db3 (localhost.localdomain [127.0.0.1]) by mail109-db3
	(MessageSwitch) id 1323876926956380_9306;
	Wed, 14 Dec 2011 15:35:26 +0000 (UTC)
Received: from DB3EHSMHS005.bigfish.com (unknown [10.3.81.249])	by
	mail109-db3.bigfish.com (Postfix) with ESMTP id E408D580046;
	Wed, 14 Dec 2011 15:35:26 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	DB3EHSMHS005.bigfish.com (10.3.87.105) with Microsoft SMTP Server id
	14.1.225.23; Wed, 14 Dec 2011 15:35:24 +0000
X-WSS-ID: 0LW79YV-01-C4R-02
X-M-MSG: 
Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com
	[163.181.249.73])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2C93C102805A;	Wed, 14 Dec 2011 09:35:18 -0600 (CST)
Received: from SAUSEXDAG01.amd.com (163.181.55.1) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Wed, 14 Dec 2011 09:35:31 -0600
Received: from storexhtp01.amd.com (172.24.4.3) by sausexdag01.amd.com
	(163.181.55.1) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Wed, 14 Dec 2011 09:35:19 -0600
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp01.amd.com
	(172.24.4.3) with Microsoft SMTP Server id 8.3.213.0; Wed, 14 Dec 2011
	10:35:16 -0500
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 35B9649C667; Wed, 14 Dec 2011
	15:35:12 +0000 (GMT)
Received: from gran.amd.com (gran.osrc.amd.com [165.204.15.57])	by
	mail.osrc.amd.com (Postfix) with ESMTP id 1573C594884; Wed, 14 Dec 2011
	16:35:12 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 04573463beff7fc9696f5ecdb940920dcc2ec0ca
Message-ID: <04573463beff7fc9696f.1323876574@gran.amd.com>
In-Reply-To: <patchbomb.1323876561@gran.amd.com>
References: <patchbomb.1323876561@gran.amd.com>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Wed, 14 Dec 2011 16:29:34 +0100
From: Wei Wang <wei.wang2@amd.com>
To: <JBeulich@suse.com>, <keir@xen.org>
X-OriginatorOrg: amd.com
Cc: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 13 of 16] libxc: add wrappers for new hypercalls
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Wei Wang <wei.wang2@amd.com>
# Date 1323876141 -3600
# Node ID 04573463beff7fc9696f5ecdb940920dcc2ec0ca
# Parent  42ecb2ba593c2827b2dc4e54360f8c6a42a4dbfc
libxc: add wrappers for new hypercalls

Signed-off-by: Wei Wang <wei.wang2@amd.com>

diff -r 42ecb2ba593c -r 04573463beff tools/libxc/xc_domain.c
--- a/tools/libxc/xc_domain.c	Wed Dec 14 16:22:20 2011 +0100
+++ b/tools/libxc/xc_domain.c	Wed Dec 14 16:22:21 2011 +0100
@@ -1352,6 +1352,55 @@ int xc_domain_bind_pt_isa_irq(
                                   PT_IRQ_TYPE_ISA, 0, 0, 0, machine_irq));
 }
 
+int xc_domain_update_iommu_msi(
+    xc_interface *xch,
+    uint32_t domid,
+    uint8_t vector,
+    uint8_t dest,
+    uint8_t dest_mode,
+    uint8_t delivery_mode,
+    uint8_t trig_mode)
+{
+    int rc;
+    DECLARE_DOMCTL;
+    xen_domctl_guest_iommu_op_t * iommu_op;
+
+    domctl.cmd = XEN_DOMCTL_guest_iommu_op;
+    domctl.domain = (domid_t)domid;
+
+    iommu_op = &(domctl.u.guest_iommu_op);
+    iommu_op->op = XEN_DOMCTL_GUEST_IOMMU_OP_SET_MSI;
+    iommu_op->u.msi.vector = vector;
+    iommu_op->u.msi.dest = dest;
+    iommu_op->u.msi.dest_mode = dest_mode;
+    iommu_op->u.msi.delivery_mode = delivery_mode;
+    iommu_op->u.msi.trig_mode = trig_mode;
+
+    rc = do_domctl(xch, &domctl);
+    return rc;
+}
+
+int xc_domain_bind_pt_bdf(xc_interface *xch,
+                          uint32_t domid,
+                          uint32_t gbdf,
+                          uint32_t mbdf)
+{
+    int rc;
+    DECLARE_DOMCTL;
+    xen_domctl_guest_iommu_op_t * guest_op;
+
+    domctl.cmd = XEN_DOMCTL_guest_iommu_op;
+    domctl.domain = (domid_t)domid;
+
+    guest_op = &(domctl.u.guest_iommu_op);
+    guest_op->op = XEN_DOMCTL_GUEST_IOMMU_OP_BIND_BDF;
+    guest_op->u.bdf_bind.g_bdf = gbdf;
+    guest_op->u.bdf_bind.m_bdf = mbdf;
+
+    rc = do_domctl(xch, &domctl);
+    return rc;
+}
+
 int xc_domain_memory_mapping(
     xc_interface *xch,
     uint32_t domid,
diff -r 42ecb2ba593c -r 04573463beff tools/libxc/xenctrl.h
--- a/tools/libxc/xenctrl.h	Wed Dec 14 16:22:20 2011 +0100
+++ b/tools/libxc/xenctrl.h	Wed Dec 14 16:22:21 2011 +0100
@@ -1697,6 +1697,19 @@ int xc_domain_bind_pt_isa_irq(xc_interfa
                               uint32_t domid,
                               uint8_t machine_irq);
 
+int xc_domain_bind_pt_bdf(xc_interface *xch,
+                          uint32_t domid,
+                          uint32_t gbdf,
+                          uint32_t mbdf);
+
+int xc_domain_update_iommu_msi(xc_interface *xch,
+                               uint32_t domid,
+                               uint8_t vector,
+                               uint8_t dest,
+                               uint8_t dest_mode,
+                               uint8_t delivery_mode,
+                               uint8_t trig_mode);
+
 int xc_domain_set_machine_address_size(xc_interface *xch,
 				       uint32_t domid,
 				       unsigned int width);


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 15:36:31 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 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.xensource.com>)
	id 1RaqsY-0002x9-IU; Wed, 14 Dec 2011 15:36:22 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Wang2@amd.com>) id 1RaqsV-0002uI-SX
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 15:36:20 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1323876923!7261262!1
X-Originating-IP: [213.199.154.140]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9913 invoked from network); 14 Dec 2011 15:35:24 -0000
Received: from db3ehsobe002.messaging.microsoft.com (HELO
	DB3EHSOBE002.bigfish.com) (213.199.154.140)
	by server-4.tower-182.messagelabs.com with AES128-SHA encrypted SMTP;
	14 Dec 2011 15:35:24 -0000
Received: from mail53-db3-R.bigfish.com (10.3.81.254) by
	DB3EHSOBE002.bigfish.com (10.3.84.22) with Microsoft SMTP Server id
	14.1.225.23; Wed, 14 Dec 2011 15:35:25 +0000
Received: from mail53-db3 (localhost [127.0.0.1])	by mail53-db3-R.bigfish.com
	(Postfix) with ESMTP id 8D05F80313;
	Wed, 14 Dec 2011 15:35:26 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzzz1202hzz8275bhz2dh668h839h944h)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
X-FB-SS: 13,
Received: from mail53-db3 (localhost.localdomain [127.0.0.1]) by mail53-db3
	(MessageSwitch) id 1323876926227852_5691;
	Wed, 14 Dec 2011 15:35:26 +0000 (UTC)
Received: from DB3EHSMHS002.bigfish.com (unknown [10.3.81.240])	by
	mail53-db3.bigfish.com (Postfix) with ESMTP id 286711C0046;
	Wed, 14 Dec 2011 15:35:26 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	DB3EHSMHS002.bigfish.com (10.3.87.102) with Microsoft SMTP Server id
	14.1.225.23; Wed, 14 Dec 2011 15:35:24 +0000
X-WSS-ID: 0LW79YV-01-C4N-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 219D21028051;	Wed, 14 Dec 2011 09:35:18 -0600 (CST)
Received: from SAUSEXDAG02.amd.com (163.181.55.2) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Wed, 14 Dec 2011 09:35:31 -0600
Received: from storexhtp02.amd.com (172.24.4.4) by sausexdag02.amd.com
	(163.181.55.2) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Wed, 14 Dec 2011 09:35:19 -0600
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Wed, 14 Dec 2011
	10:35:16 -0500
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 1642049C666; Wed, 14 Dec 2011
	15:35:12 +0000 (GMT)
Received: from gran.amd.com (gran.osrc.amd.com [165.204.15.57])	by
	mail.osrc.amd.com (Postfix) with ESMTP id D896559488B; Wed, 14 Dec 2011
	16:35:11 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 42ecb2ba593c2827b2dc4e54360f8c6a42a4dbfc
Message-ID: <42ecb2ba593c2827b2dc.1323876573@gran.amd.com>
In-Reply-To: <patchbomb.1323876561@gran.amd.com>
References: <patchbomb.1323876561@gran.amd.com>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Wed, 14 Dec 2011 16:29:33 +0100
From: Wei Wang <wei.wang2@amd.com>
To: <JBeulich@suse.com>, <keir@xen.org>
X-OriginatorOrg: amd.com
Cc: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 12 of 16] hvmloader: Build IVRS table
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Wei Wang <wei.wang2@amd.com>
# Date 1323876140 -3600
# Node ID 42ecb2ba593c2827b2dc4e54360f8c6a42a4dbfc
# Parent  9a93e064dd3c467ce4b87ddef8739a3573ef547c
hvmloader: Build IVRS table.
Signed-off-by: Wei Wang <wei.wang2@amd.com>

diff -r 9a93e064dd3c -r 42ecb2ba593c tools/firmware/hvmloader/acpi/acpi2_0.h
--- a/tools/firmware/hvmloader/acpi/acpi2_0.h	Wed Dec 14 16:16:16 2011 +0100
+++ b/tools/firmware/hvmloader/acpi/acpi2_0.h	Wed Dec 14 16:22:20 2011 +0100
@@ -389,6 +389,60 @@ struct acpi_20_madt_intsrcovr {
 #define ACPI_2_0_WAET_REVISION 0x01
 #define ACPI_1_0_FADT_REVISION 0x01
 
+#define IVRS_SIGNATURE ASCII32('I','V','R','S')
+#define IVRS_REVISION           1
+#define IVRS_VASIZE             64
+#define IVRS_PASIZE             52
+#define IVRS_GVASIZE            64
+
+#define IVHD_BLOCK_TYPE         0x10
+#define IVHD_FLAG_HTTUNEN       (1 << 0)
+#define IVHD_FLAG_PASSPW        (1 << 1)
+#define IVHD_FLAG_RESPASSPW     (1 << 2)
+#define IVHD_FLAG_ISOC          (1 << 3)
+#define IVHD_FLAG_IOTLBSUP      (1 << 4)
+#define IVHD_FLAG_COHERENT      (1 << 5)
+#define IVHD_FLAG_PREFSUP       (1 << 6)
+#define IVHD_FLAG_PPRSUP        (1 << 7)
+
+#define IVHD_EFR_GTSUP          (1 << 2)
+#define IVHD_EFR_IASUP          (1 << 5)
+
+#define IVHD_SELECT_4_BYTE      0x2
+
+struct ivrs_ivhd_block
+{
+    uint8_t    type;
+    uint8_t    flags;
+    uint16_t   length;
+    uint16_t   devid;
+    uint16_t   cap_offset;
+    uint64_t   iommu_base_addr;
+    uint16_t   pci_segment;
+    uint16_t   iommu_info;
+    uint32_t   reserved;
+};
+
+/* IVHD 4-byte device entries */
+struct ivrs_ivhd_device
+{
+   uint8_t  type;
+   uint16_t dev_id;
+   uint8_t  flags;
+};
+
+#define PT_DEV_MAX_NR           32
+#define IOMMU_CAP_OFFSET        0x40
+struct acpi_40_ivrs
+{
+    struct acpi_header                      header;
+    uint32_t                                iv_info;
+    uint32_t                                reserved[2];
+    struct ivrs_ivhd_block                  ivhd_block;
+    struct ivrs_ivhd_device                 ivhd_device[PT_DEV_MAX_NR];
+};
+
+
 #pragma pack ()
 
 struct acpi_config {
diff -r 9a93e064dd3c -r 42ecb2ba593c tools/firmware/hvmloader/acpi/build.c
--- a/tools/firmware/hvmloader/acpi/build.c	Wed Dec 14 16:16:16 2011 +0100
+++ b/tools/firmware/hvmloader/acpi/build.c	Wed Dec 14 16:22:20 2011 +0100
@@ -23,6 +23,8 @@
 #include "ssdt_pm.h"
 #include "../config.h"
 #include "../util.h"
+#include "../hypercall.h"
+#include <xen/hvm/params.h>
 
 #define align16(sz)        (((sz) + 15) & ~15)
 #define fixed_strcpy(d, s) strncpy((d), (s), sizeof(d))
@@ -198,6 +200,77 @@ static struct acpi_20_waet *construct_wa
     return waet;
 }
 
+extern uint32_t ptdev_bdf[PT_DEV_MAX_NR];
+extern uint32_t ptdev_nr;
+extern uint32_t iommu_bdf;
+static struct acpi_40_ivrs* construct_ivrs(void)
+{
+    struct acpi_40_ivrs *ivrs;
+    uint64_t mmio;
+    struct ivrs_ivhd_block *ivhd;
+    struct ivrs_ivhd_device *dev_entry;
+    struct xen_hvm_param p;
+
+    if (ptdev_nr == 0) return NULL;
+
+    ivrs = mem_alloc(sizeof(*ivrs), 16);
+    if (!ivrs) return NULL;
+
+    memset(ivrs, 0, sizeof(*ivrs));
+
+    /* initialize acpi header */
+    ivrs->header.signature = IVRS_SIGNATURE;
+    ivrs->header.revision = IVRS_REVISION;
+    fixed_strcpy(ivrs->header.oem_id, ACPI_OEM_ID);
+    fixed_strcpy(ivrs->header.oem_table_id, ACPI_OEM_TABLE_ID);
+
+    ivrs->header.oem_revision = ACPI_OEM_REVISION;
+    ivrs->header.creator_id   = ACPI_CREATOR_ID;
+    ivrs->header.creator_revision = ACPI_CREATOR_REVISION;
+
+    ivrs->header.length = sizeof(*ivrs);
+
+    /* initialize IVHD Block */
+    ivhd = &ivrs->ivhd_block;
+    ivrs->iv_info = (IVRS_VASIZE << 15) | (IVRS_PASIZE << 8) |
+                    (IVRS_GVASIZE << 5);
+
+    ivhd->type          = IVHD_BLOCK_TYPE;
+    ivhd->flags         = IVHD_FLAG_PPRSUP | IVHD_FLAG_IOTLBSUP;
+    ivhd->devid         = iommu_bdf;
+    ivhd->cap_offset    = IOMMU_CAP_OFFSET;
+
+    /*reserve 32K IOMMU MMIO space */
+    mmio = virt_to_phys(mem_alloc(0x8000, 0x1000));
+    if (!mmio) return NULL;
+
+    p.domid = DOMID_SELF;
+    p.index = HVM_PARAM_IOMMU_BASE;
+    p.value = mmio;
+
+    /* Return non-zero if IOMMUv2 hardware is not avaliable */
+    if ( hypercall_hvm_op(HVMOP_set_param, &p) )
+        return NULL;
+
+    ivhd->iommu_base_addr = mmio;
+    ivhd->reserved = IVHD_EFR_IASUP | IVHD_EFR_GTSUP;
+
+    /* Build IVHD device entries */
+    dev_entry = ivrs->ivhd_device;
+    for ( int i = 0; i < ptdev_nr; i++ )
+    {
+        dev_entry[i].type   = IVHD_SELECT_4_BYTE;
+        dev_entry[i].dev_id = ptdev_bdf[i];
+        dev_entry[i].flags  = 0;
+    }
+
+    ivhd->length = sizeof(*ivhd) + sizeof(*dev_entry) * PT_DEV_MAX_NR;
+    set_checksum(ivrs, offsetof(struct acpi_header, checksum), 
+                 ivrs->header.length);
+
+    return ivrs;
+}
+
 static int construct_secondary_tables(unsigned long *table_ptrs,
                                       struct acpi_info *info)
 {
@@ -206,6 +279,7 @@ static int construct_secondary_tables(un
     struct acpi_20_hpet *hpet;
     struct acpi_20_waet *waet;
     struct acpi_20_tcpa *tcpa;
+    struct acpi_40_ivrs *ivrs;
     unsigned char *ssdt;
     static const uint16_t tis_signature[] = {0x0001, 0x0001, 0x0001};
     uint16_t *tis_hdr;
@@ -293,6 +367,13 @@ static int construct_secondary_tables(un
         }
     }
 
+    if ( hvm_info->iommu_enabled )
+    {
+        ivrs = construct_ivrs();
+        if ( ivrs != NULL )
+            table_ptrs[nr_tables++] = (unsigned long)ivrs;
+    }
+
     table_ptrs[nr_tables] = 0;
     return nr_tables;
 }
diff -r 9a93e064dd3c -r 42ecb2ba593c tools/firmware/hvmloader/pci.c
--- a/tools/firmware/hvmloader/pci.c	Wed Dec 14 16:16:16 2011 +0100
+++ b/tools/firmware/hvmloader/pci.c	Wed Dec 14 16:22:20 2011 +0100
@@ -34,11 +34,17 @@ unsigned long pci_mem_end = PCI_MEM_END;
 enum virtual_vga virtual_vga = VGA_none;
 unsigned long igd_opregion_pgbase = 0;
 
+/* support up to 32 passthrough devices */
+#define PT_DEV_MAX_NR           32
+uint32_t ptdev_bdf[PT_DEV_MAX_NR];
+uint32_t ptdev_nr;
+uint32_t iommu_bdf;
+
 void pci_setup(void)
 {
     uint32_t base, devfn, bar_reg, bar_data, bar_sz, cmd, mmio_total = 0;
     uint32_t vga_devfn = 256;
-    uint16_t class, vendor_id, device_id;
+    uint16_t class, vendor_id, device_id, sub_vendor_id;
     unsigned int bar, pin, link, isa_irq;
 
     /* Resources assignable to PCI devices via BARs. */
@@ -72,11 +78,34 @@ void pci_setup(void)
         class     = pci_readw(devfn, PCI_CLASS_DEVICE);
         vendor_id = pci_readw(devfn, PCI_VENDOR_ID);
         device_id = pci_readw(devfn, PCI_DEVICE_ID);
+        sub_vendor_id = pci_readw(devfn, PCI_SUBSYSTEM_VENDOR_ID);
+
         if ( (vendor_id == 0xffff) && (device_id == 0xffff) )
             continue;
 
         ASSERT((devfn != PCI_ISA_DEVFN) ||
                ((vendor_id == 0x8086) && (device_id == 0x7000)));
+        /* Found amd iommu device. */
+        if ( class == 0x0806 && vendor_id == 0x1022 )
+        {
+            iommu_bdf = devfn;
+            printf("Found iommu devfn %x class %x\n", iommu_bdf, class);
+            continue;
+        }
+
+        /* IVRS: Detecting passthrough devices.
+         * sub_vendor_id != citrix && sub_vendor_id != qemu */
+        if ( sub_vendor_id != 0x5853 && sub_vendor_id != 0x1af4 )
+        {
+            /* found amd iommu device */
+            if ( ptdev_nr < PT_DEV_MAX_NR )
+            {
+                ptdev_bdf[ptdev_nr] = devfn;
+                ptdev_nr ++;
+            }
+            else
+                printf("Number of passthru devices > PT_DEV_MAX_NR \n");
+        }
 
         switch ( class )
         {
diff -r 9a93e064dd3c -r 42ecb2ba593c xen/include/public/hvm/hvm_info_table.h
--- a/xen/include/public/hvm/hvm_info_table.h	Wed Dec 14 16:16:16 2011 +0100
+++ b/xen/include/public/hvm/hvm_info_table.h	Wed Dec 14 16:22:20 2011 +0100
@@ -67,6 +67,9 @@ struct hvm_info_table {
 
     /* Bitmap of which CPUs are online at boot time. */
     uint8_t     vcpu_online[(HVM_MAX_VCPUS + 7)/8];
+
+    /* guest iommu enabled */
+    uint8_t     iommu_enabled;
 };
 
 #endif /* __XEN_PUBLIC_HVM_HVM_INFO_TABLE_H__ */


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 15:36:31 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 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.xensource.com>)
	id 1Raqsb-00030l-Qr; Wed, 14 Dec 2011 15:36:25 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Wang2@amd.com>) id 1RaqsZ-0002v4-DB
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 15:36:23 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1323876926!7249150!1
X-Originating-IP: [216.32.181.184]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8287 invoked from network); 14 Dec 2011 15:35:27 -0000
Received: from ch1ehsobe004.messaging.microsoft.com (HELO
	ch1outboundpool.messaging.microsoft.com) (216.32.181.184)
	by server-9.tower-182.messagelabs.com with AES128-SHA encrypted SMTP;
	14 Dec 2011 15:35:27 -0000
Received: from mail25-ch1-R.bigfish.com (10.43.68.254) by
	CH1EHSOBE005.bigfish.com (10.43.70.55) with Microsoft SMTP Server id
	14.1.225.23; Wed, 14 Dec 2011 15:35:28 +0000
Received: from mail25-ch1 (localhost [127.0.0.1])	by mail25-ch1-R.bigfish.com
	(Postfix) with ESMTP id 654632000F1;
	Wed, 14 Dec 2011 15:35:29 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzzz1202hzz8275bhz2dh668h839h944h)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
Received: from mail25-ch1 (localhost.localdomain [127.0.0.1]) by mail25-ch1
	(MessageSwitch) id 1323876927218701_3926;
	Wed, 14 Dec 2011 15:35:27 +0000 (UTC)
Received: from CH1EHSMHS007.bigfish.com (snatpool1.int.messaging.microsoft.com
	[10.43.68.254])	by mail25-ch1.bigfish.com (Postfix) with ESMTP id
	30AEC180048;	Wed, 14 Dec 2011 15:35:27 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	CH1EHSMHS007.bigfish.com (10.43.70.7) with Microsoft SMTP Server id
	14.1.225.23; Wed, 14 Dec 2011 15:35:23 +0000
X-WSS-ID: 0LW79YV-01-C4M-02
X-M-MSG: 
Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com
	[163.181.249.73])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2ABC51028059;	Wed, 14 Dec 2011 09:35:18 -0600 (CST)
Received: from SAUSEXDAG02.amd.com (163.181.55.2) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Wed, 14 Dec 2011 09:35:31 -0600
Received: from storexhtp02.amd.com (172.24.4.4) by sausexdag02.amd.com
	(163.181.55.2) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Wed, 14 Dec 2011 09:35:20 -0600
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Wed, 14 Dec 2011
	10:35:17 -0500
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 604D149C669; Wed, 14 Dec 2011
	15:35:12 +0000 (GMT)
Received: from gran.amd.com (gran.osrc.amd.com [165.204.15.57])	by
	mail.osrc.amd.com (Postfix) with ESMTP id 4883B594885; Wed, 14 Dec 2011
	16:35:12 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 93658ca85035d6a4e56e2e6602c02859974d30a4
Message-ID: <93658ca85035d6a4e56e.1323876576@gran.amd.com>
In-Reply-To: <patchbomb.1323876561@gran.amd.com>
References: <patchbomb.1323876561@gran.amd.com>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Wed, 14 Dec 2011 16:29:36 +0100
From: Wei Wang <wei.wang2@amd.com>
To: <JBeulich@suse.com>, <keir@xen.org>
X-OriginatorOrg: amd.com
Cc: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 15 of 16] libxl: Introduce a new guest config
	file parameter
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Wei Wang <wei.wang2@amd.com>
# Date 1323876143 -3600
# Node ID 93658ca85035d6a4e56e2e6602c02859974d30a4
# Parent  f9575683f10a08a86a9c73226581610fa3f7be4b
libxl: Introduce a new guest config file parameter
Use iommu = {1,0} to enable or disable guest iommu emulation.
Default value is 0.

Signed-off-by: Wei Wang <wei.wang2@amd.com>

diff -r f9575683f10a -r 93658ca85035 tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Wed Dec 14 16:22:22 2011 +0100
+++ b/tools/libxl/libxl_create.c	Wed Dec 14 16:22:23 2011 +0100
@@ -99,6 +99,7 @@ int libxl_init_build_info(libxl_ctx *ctx
         b_info->u.hvm.vpt_align = 1;
         b_info->u.hvm.timer_mode = 1;
         b_info->u.hvm.nested_hvm = 0;
+        b_info->u.hvm.iommu = 0;
         break;
     case LIBXL_DOMAIN_TYPE_PV:
         b_info->u.pv.slack_memkb = 8 * 1024;
diff -r f9575683f10a -r 93658ca85035 tools/libxl/libxl_dom.c
--- a/tools/libxl/libxl_dom.c	Wed Dec 14 16:22:22 2011 +0100
+++ b/tools/libxl/libxl_dom.c	Wed Dec 14 16:22:23 2011 +0100
@@ -266,6 +266,10 @@ static int hvm_build_set_params(xc_inter
     va_hvm = (struct hvm_info_table *)(va_map + HVM_INFO_OFFSET);
     va_hvm->apic_mode = info->u.hvm.apic;
     va_hvm->nr_vcpus = info->max_vcpus;
+
+    if ( info->u.hvm.iommu )
+         va_hvm->iommu_enabled = 1;
+
     memcpy(va_hvm->vcpu_online, &info->cur_vcpus, sizeof(info->cur_vcpus));
     for (i = 0, sum = 0; i < va_hvm->length; i++)
         sum += ((uint8_t *) va_hvm)[i];
diff -r f9575683f10a -r 93658ca85035 tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Wed Dec 14 16:22:22 2011 +0100
+++ b/tools/libxl/libxl_types.idl	Wed Dec 14 16:22:23 2011 +0100
@@ -184,6 +184,7 @@ libxl_domain_build_info = Struct("domain
                                        ("vpt_align", bool),
                                        ("timer_mode", integer),
                                        ("nested_hvm", bool),
+                                       ("iommu", bool),
                                        ])),
                  ("pv", Struct(None, [("kernel", libxl_file_reference),
                                       ("slack_memkb", uint32),
diff -r f9575683f10a -r 93658ca85035 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Wed Dec 14 16:22:22 2011 +0100
+++ b/tools/libxl/xl_cmdimpl.c	Wed Dec 14 16:22:23 2011 +0100
@@ -360,6 +360,7 @@ static void printf_info(int domid,
         printf("\t\t\t(vpt_align %d)\n", b_info->u.hvm.vpt_align);
         printf("\t\t\t(timer_mode %d)\n", b_info->u.hvm.timer_mode);
         printf("\t\t\t(nestedhvm %d)\n", b_info->u.hvm.nested_hvm);
+        printf("\t\t\t(iommu %d)\n", b_info->u.hvm.iommu);
 
         printf("\t\t\t(device_model %s)\n", dm_info->device_model ? : "default");
         printf("\t\t\t(videoram %d)\n", dm_info->videoram);
@@ -764,6 +765,8 @@ static void parse_config_data(const char
             b_info->u.hvm.timer_mode = l;
         if (!xlu_cfg_get_long (config, "nestedhvm", &l, 0))
             b_info->u.hvm.nested_hvm = l;
+        if (!xlu_cfg_get_long (config, "iommu", &l, 0))
+            b_info->u.hvm.iommu = l;
         break;
     case LIBXL_DOMAIN_TYPE_PV:
     {


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 15:36:31 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 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.xensource.com>)
	id 1RaqsZ-0002y8-IG; Wed, 14 Dec 2011 15:36:23 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Wang2@amd.com>) id 1RaqsV-0002uH-Rg
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 15:36:20 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1323876922!7261259!1
X-Originating-IP: [216.32.181.184]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9886 invoked from network); 14 Dec 2011 15:35:23 -0000
Received: from ch1ehsobe004.messaging.microsoft.com (HELO
	ch1outboundpool.messaging.microsoft.com) (216.32.181.184)
	by server-4.tower-182.messagelabs.com with AES128-SHA encrypted SMTP;
	14 Dec 2011 15:35:23 -0000
Received: from mail204-ch1-R.bigfish.com (10.43.68.249) by
	CH1EHSOBE017.bigfish.com (10.43.70.67) with Microsoft SMTP Server id
	14.1.225.23; Wed, 14 Dec 2011 15:35:24 +0000
Received: from mail204-ch1 (localhost [127.0.0.1])	by
	mail204-ch1-R.bigfish.com (Postfix) with ESMTP id 3A4C6340396;
	Wed, 14 Dec 2011 15:35:25 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzzz1202hzz8275bhz2dh668h839h944h)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
X-FB-SS: 13,
Received: from mail204-ch1 (localhost.localdomain [127.0.0.1]) by mail204-ch1
	(MessageSwitch) id 1323876924612877_6214;
	Wed, 14 Dec 2011 15:35:24 +0000 (UTC)
Received: from CH1EHSMHS010.bigfish.com (snatpool1.int.messaging.microsoft.com
	[10.43.68.242])	by mail204-ch1.bigfish.com (Postfix) with ESMTP id
	869A640043;	Wed, 14 Dec 2011 15:35:24 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	CH1EHSMHS010.bigfish.com (10.43.70.10) with Microsoft SMTP Server id
	14.1.225.22; Wed, 14 Dec 2011 15:35:21 +0000
X-WSS-ID: 0LW79YR-01-C4B-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2A0E11028052;	Wed, 14 Dec 2011 09:35:14 -0600 (CST)
Received: from SAUSEXDAG02.amd.com (163.181.55.2) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Wed, 14 Dec 2011 09:35:27 -0600
Received: from storexhtp02.amd.com (172.24.4.4) by sausexdag02.amd.com
	(163.181.55.2) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Wed, 14 Dec 2011 09:35:16 -0600
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Wed, 14 Dec 2011
	10:35:11 -0500
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 0FEE049C620; Wed, 14 Dec 2011
	15:35:11 +0000 (GMT)
Received: from gran.amd.com (gran.osrc.amd.com [165.204.15.57])	by
	mail.osrc.amd.com (Postfix) with ESMTP id F19BE594882; Wed, 14 Dec 2011
	16:35:10 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: a3d2f93d82940a391de00717ddbf842f821fcea5
Message-ID: <a3d2f93d82940a391de0.1323876562@gran.amd.com>
In-Reply-To: <patchbomb.1323876561@gran.amd.com>
References: <patchbomb.1323876561@gran.amd.com>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Wed, 14 Dec 2011 16:29:22 +0100
From: Wei Wang <wei.wang2@amd.com>
To: <JBeulich@suse.com>, <keir@xen.org>
X-OriginatorOrg: amd.com
Cc: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 01 of 16] amd iommu: Refactoring iommu ring
	buffer definition
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Wei Wang <wei.wang2@amd.com>
# Date 1323863478 -3600
# Node ID a3d2f93d82940a391de00717ddbf842f821fcea5
# Parent  846725c81ed924e03bf4e6d65f912be089c54a06
amd iommu: Refactoring iommu ring buffer definition.
Introduce struct ring_buffer to represent iommu cmd buffer, event log and ppr log

Signed-off-by: Wei Wang <wei.wang2@amd.com>

diff -r 846725c81ed9 -r a3d2f93d8294 xen/drivers/passthrough/amd/iommu_cmd.c
--- a/xen/drivers/passthrough/amd/iommu_cmd.c	Tue Dec 13 13:32:23 2011 +0100
+++ b/xen/drivers/passthrough/amd/iommu_cmd.c	Wed Dec 14 12:51:18 2011 +0100
@@ -29,7 +29,7 @@ static int queue_iommu_command(struct am
     u32 tail, head, *cmd_buffer;
     int i;
 
-    tail = iommu->cmd_buffer_tail;
+    tail = iommu->cmd_buffer.tail;
     if ( ++tail == iommu->cmd_buffer.entries )
         tail = 0;
 
@@ -40,13 +40,13 @@ static int queue_iommu_command(struct am
     if ( head != tail )
     {
         cmd_buffer = (u32 *)(iommu->cmd_buffer.buffer +
-                             (iommu->cmd_buffer_tail *
+                             (iommu->cmd_buffer.tail *
                              IOMMU_CMD_BUFFER_ENTRY_SIZE));
 
         for ( i = 0; i < IOMMU_CMD_BUFFER_U32_PER_ENTRY; i++ )
             cmd_buffer[i] = cmd[i];
 
-        iommu->cmd_buffer_tail = tail;
+        iommu->cmd_buffer.tail = tail;
         return 1;
     }
 
@@ -57,7 +57,7 @@ static void commit_iommu_command_buffer(
 {
     u32 tail;
 
-    set_field_in_reg_u32(iommu->cmd_buffer_tail, 0,
+    set_field_in_reg_u32(iommu->cmd_buffer.tail, 0,
                          IOMMU_CMD_BUFFER_TAIL_MASK,
                          IOMMU_CMD_BUFFER_TAIL_SHIFT, &tail);
     writel(tail, iommu->mmio_base+IOMMU_CMD_BUFFER_TAIL_OFFSET);
diff -r 846725c81ed9 -r a3d2f93d8294 xen/drivers/passthrough/amd/iommu_init.c
--- a/xen/drivers/passthrough/amd/iommu_init.c	Tue Dec 13 13:32:23 2011 +0100
+++ b/xen/drivers/passthrough/amd/iommu_init.c	Wed Dec 14 12:51:18 2011 +0100
@@ -294,20 +294,20 @@ static int amd_iommu_read_event_log(stru
                                   IOMMU_EVENT_LOG_TAIL_MASK,
                                   IOMMU_EVENT_LOG_TAIL_SHIFT);
 
-    while ( tail != iommu->event_log_head )
+    while ( tail != iommu->event_log.head )
     {
         /* read event log entry */
         event_log = (u32 *)(iommu->event_log.buffer +
-                           (iommu->event_log_head *
+                           (iommu->event_log.head *
                            IOMMU_EVENT_LOG_ENTRY_SIZE));
 
         parse_event_log_entry(iommu, event_log);
 
-        if ( ++iommu->event_log_head == iommu->event_log.entries )
-            iommu->event_log_head = 0;
+        if ( ++iommu->event_log.head == iommu->event_log.entries )
+            iommu->event_log.head = 0;
 
         /* update head pointer */
-        set_field_in_reg_u32(iommu->event_log_head, 0,
+        set_field_in_reg_u32(iommu->event_log.head, 0,
                              IOMMU_EVENT_LOG_HEAD_MASK,
                              IOMMU_EVENT_LOG_HEAD_SHIFT, &head);
         writel(head, iommu->mmio_base + IOMMU_EVENT_LOG_HEAD_OFFSET);
@@ -346,7 +346,7 @@ static void amd_iommu_reset_event_log(st
     writel(entry, iommu->mmio_base+IOMMU_STATUS_MMIO_OFFSET);
 
     /*reset event log base address */
-    iommu->event_log_head = 0;
+    iommu->event_log.head = 0;
 
     set_iommu_event_log_control(iommu, IOMMU_CONTROL_ENABLED);
 }
@@ -605,71 +605,83 @@ static void enable_iommu(struct amd_iomm
 
 }
 
-static void __init deallocate_iommu_table_struct(
-    struct table_struct *table)
+static void __init deallocate_buffer(void *buf, uint32_t sz)
 {
     int order = 0;
-    if ( table->buffer )
+    if ( buf )
     {
-        order = get_order_from_bytes(table->alloc_size);
-        __free_amd_iommu_tables(table->buffer, order);
-        table->buffer = NULL;
+        order = get_order_from_bytes(sz);
+        __free_amd_iommu_tables(buf, order);
     }
 }
 
-static int __init allocate_iommu_table_struct(struct table_struct *table,
-                                              const char *name)
+static void __init deallocate_device_table(struct table_struct *table)
 {
-    int order = 0;
-    if ( table->buffer == NULL )
-    {
-        order = get_order_from_bytes(table->alloc_size);
-        table->buffer = __alloc_amd_iommu_tables(order);
-
-        if ( table->buffer == NULL )
-        {
-            AMD_IOMMU_DEBUG("Error allocating %s\n", name);
-            return -ENOMEM;
-        }
-        memset(table->buffer, 0, PAGE_SIZE * (1UL << order));
-    }
-    return 0;
+    deallocate_buffer(table->buffer, table->alloc_size);
+    table->buffer = NULL;
 }
 
-static int __init allocate_cmd_buffer(struct amd_iommu *iommu)
+static void __init deallocate_ring_buffer(struct ring_buffer *ring_buf)
+{
+    deallocate_buffer(ring_buf->buffer, ring_buf->alloc_size);
+    ring_buf->buffer = NULL;
+    ring_buf->head = 0;
+    ring_buf->tail = 0;
+}
+
+static void * __init allocate_buffer(uint32_t alloc_size, const char *name)
+{
+    void * buffer;
+    int order = get_order_from_bytes(alloc_size);
+
+    buffer = __alloc_amd_iommu_tables(order);
+
+    if ( buffer == NULL )
+    {
+        AMD_IOMMU_DEBUG("Error allocating %s\n", name);
+        return NULL;
+    }
+
+    memset(buffer, 0, PAGE_SIZE * (1UL << order));
+    return buffer;
+}
+
+static void * __init allocate_ring_buffer(struct ring_buffer *ring_buf,
+                                          uint32_t entry_size, 
+                                          uint64_t entries, const char *name)
+{
+    ring_buf->head = 0;
+    ring_buf->tail = 0;
+
+    ring_buf->entry_size = entry_size;
+    ring_buf->alloc_size = PAGE_SIZE << get_order_from_bytes(entries * 
+                                                             entry_size);
+    ring_buf->entries = ring_buf->alloc_size / entry_size;
+    ring_buf->buffer = allocate_buffer(ring_buf->alloc_size, name);
+    return ring_buf->buffer;
+}
+
+static void * __init allocate_cmd_buffer(struct amd_iommu *iommu)
 {
     /* allocate 'command buffer' in power of 2 increments of 4K */
-    iommu->cmd_buffer_tail = 0;
-    iommu->cmd_buffer.alloc_size = PAGE_SIZE <<
-                                   get_order_from_bytes(
-                                   PAGE_ALIGN(IOMMU_CMD_BUFFER_DEFAULT_ENTRIES
-                                              * IOMMU_CMD_BUFFER_ENTRY_SIZE));
-    iommu->cmd_buffer.entries = iommu->cmd_buffer.alloc_size /
-                                IOMMU_CMD_BUFFER_ENTRY_SIZE;
-
-    return (allocate_iommu_table_struct(&iommu->cmd_buffer, "Command Buffer"));
+    return allocate_ring_buffer(&iommu->cmd_buffer, sizeof(cmd_entry_t),
+                                IOMMU_CMD_BUFFER_DEFAULT_ENTRIES, 
+                                "Command Buffer");
 }
 
-static int __init allocate_event_log(struct amd_iommu *iommu)
+static void * __init allocate_event_log(struct amd_iommu *iommu)
 {
-   /* allocate 'event log' in power of 2 increments of 4K */
-    iommu->event_log_head = 0;
-    iommu->event_log.alloc_size = PAGE_SIZE <<
-                                  get_order_from_bytes(
-                                  PAGE_ALIGN(IOMMU_EVENT_LOG_DEFAULT_ENTRIES *
-                                  IOMMU_EVENT_LOG_ENTRY_SIZE));
-    iommu->event_log.entries = iommu->event_log.alloc_size /
-                               IOMMU_EVENT_LOG_ENTRY_SIZE;
-
-    return (allocate_iommu_table_struct(&iommu->event_log, "Event Log"));
+    /* allocate 'event log' in power of 2 increments of 4K */
+    return allocate_ring_buffer(&iommu->event_log, sizeof(event_entry_t),
+                                IOMMU_EVENT_LOG_DEFAULT_ENTRIES, "Event Log");
 }
 
 static int __init amd_iommu_init_one(struct amd_iommu *iommu)
 {
-    if ( allocate_cmd_buffer(iommu) != 0 )
+    if ( allocate_cmd_buffer(iommu) == NULL )
         goto error_out;
 
-    if ( allocate_event_log(iommu) != 0 )
+    if ( allocate_event_log(iommu) == NULL )
         goto error_out;
 
     if ( map_iommu_mmio_region(iommu) != 0 )
@@ -708,8 +720,8 @@ static void __init amd_iommu_init_cleanu
         list_del(&iommu->list);
         if ( iommu->enabled )
         {
-            deallocate_iommu_table_struct(&iommu->cmd_buffer);
-            deallocate_iommu_table_struct(&iommu->event_log);
+            deallocate_ring_buffer(&iommu->cmd_buffer);
+            deallocate_ring_buffer(&iommu->event_log);
             unmap_iommu_mmio_region(iommu);
         }
         xfree(iommu);
@@ -719,7 +731,7 @@ static void __init amd_iommu_init_cleanu
     iterate_ivrs_entries(amd_iommu_free_intremap_table);
 
     /* free device table */
-    deallocate_iommu_table_struct(&device_table);
+    deallocate_device_table(&device_table);
 
     /* free ivrs_mappings[] */
     radix_tree_destroy(&ivrs_maps, xfree);
@@ -830,8 +842,10 @@ static int __init amd_iommu_setup_device
     device_table.entries = device_table.alloc_size /
                            IOMMU_DEV_TABLE_ENTRY_SIZE;
 
-    if ( allocate_iommu_table_struct(&device_table, "Device Table") != 0 )
-         return -ENOMEM;
+    device_table.buffer = allocate_buffer(device_table.alloc_size, 
+                                          "Device Table");
+    if  ( device_table.buffer == NULL )
+        return -ENOMEM;
 
     /* Add device table entries */
     for ( bdf = 0; bdf < ivrs_bdf_entries; bdf++ )
diff -r 846725c81ed9 -r a3d2f93d8294 xen/include/asm-x86/amd-iommu.h
--- a/xen/include/asm-x86/amd-iommu.h	Tue Dec 13 13:32:23 2011 +0100
+++ b/xen/include/asm-x86/amd-iommu.h	Wed Dec 14 12:51:18 2011 +0100
@@ -30,12 +30,43 @@
 
 extern struct list_head amd_iommu_head;
 
+#pragma pack(1)
+typedef struct event_entry
+{
+    uint32_t data[4];
+} event_entry_t;
+
+typedef struct ppr_entry
+{
+    uint32_t data[4];
+} ppr_entry_t;
+
+typedef struct cmd_entry
+{
+    uint32_t data[4];
+} cmd_entry_t;
+
+typedef struct dev_entry
+{
+    uint32_t data[8];
+} dev_entry_t;
+#pragma pack()
+
 struct table_struct {
     void *buffer;
     unsigned long entries;
     unsigned long alloc_size;
 };
 
+struct ring_buffer {
+    void *buffer;
+    unsigned long entries;
+    unsigned long alloc_size;
+    unsigned long entry_size;
+    uint32_t tail;
+    uint32_t head;
+};
+
 typedef struct iommu_cap {
     uint32_t header;                    /* offset 00h */
     uint32_t base_low;                  /* offset 04h */
@@ -60,10 +91,8 @@ struct amd_iommu {
     unsigned long mmio_base_phys;
 
     struct table_struct dev_table;
-    struct table_struct cmd_buffer;
-    u32 cmd_buffer_tail;
-    struct table_struct event_log;
-    u32 event_log_head;
+    struct ring_buffer cmd_buffer;
+    struct ring_buffer event_log;
 
     int exclusion_enable;
     int exclusion_allow_all;


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 15:36:31 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 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.xensource.com>)
	id 1Raqsb-0002zw-2G; Wed, 14 Dec 2011 15:36:25 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Wang2@amd.com>) id 1RaqsX-0002uV-KR
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 15:36:21 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1323876924!7202502!1
X-Originating-IP: [213.199.154.205]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32320 invoked from network); 14 Dec 2011 15:35:24 -0000
Received: from am1ehsobe002.messaging.microsoft.com (HELO
	AM1EHSOBE002.bigfish.com) (213.199.154.205)
	by server-15.tower-182.messagelabs.com with AES128-SHA encrypted SMTP;
	14 Dec 2011 15:35:24 -0000
Received: from mail73-am1-R.bigfish.com (10.3.201.251) by
	AM1EHSOBE002.bigfish.com (10.3.204.22) with Microsoft SMTP Server id
	14.1.225.23; Wed, 14 Dec 2011 15:35:26 +0000
Received: from mail73-am1 (localhost [127.0.0.1])	by mail73-am1-R.bigfish.com
	(Postfix) with ESMTP id A2FA71C025B;
	Wed, 14 Dec 2011 15:35:27 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzzz1202hzz8275bhz2dh668h839h944h)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
X-FB-SS: 13,
Received: from mail73-am1 (localhost.localdomain [127.0.0.1]) by mail73-am1
	(MessageSwitch) id 1323876927467799_28770;
	Wed, 14 Dec 2011 15:35:27 +0000 (UTC)
Received: from AM1EHSMHS004.bigfish.com (unknown [10.3.201.249])	by
	mail73-am1.bigfish.com (Postfix) with ESMTP id 6B062500082;
	Wed, 14 Dec 2011 15:35:27 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	AM1EHSMHS004.bigfish.com (10.3.207.104) with Microsoft SMTP Server id
	14.1.225.23; Wed, 14 Dec 2011 15:35:25 +0000
X-WSS-ID: 0LW79YV-02-A9Y-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp02.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 243CAC807C;	Wed, 14 Dec 2011 09:35:18 -0600 (CST)
Received: from SAUSEXDAG02.amd.com (163.181.55.2) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Wed, 14 Dec 2011 09:35:32 -0600
Received: from storexhtp02.amd.com (172.24.4.4) by sausexdag02.amd.com
	(163.181.55.2) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Wed, 14 Dec 2011 09:35:20 -0600
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Wed, 14 Dec 2011
	10:35:17 -0500
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 77E4449C66A; Wed, 14 Dec 2011
	15:35:12 +0000 (GMT)
Received: from gran.amd.com (gran.osrc.amd.com [165.204.15.57])	by
	mail.osrc.amd.com (Postfix) with ESMTP id 5F5F559488D; Wed, 14 Dec 2011
	16:35:12 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 24f4a0a23da71c58f457f0bf98aa8238dd45332d
Message-ID: <24f4a0a23da71c58f457.1323876577@gran.amd.com>
In-Reply-To: <patchbomb.1323876561@gran.amd.com>
References: <patchbomb.1323876561@gran.amd.com>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Wed, 14 Dec 2011 16:29:37 +0100
From: Wei Wang <wei.wang2@amd.com>
To: <JBeulich@suse.com>, <keir@xen.org>
X-OriginatorOrg: amd.com
Cc: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 16 of 16] libxl: add iommu parameter to qemu-dm
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Wei Wang <wei.wang2@amd.com>
# Date 1323876144 -3600
# Node ID 24f4a0a23da71c58f457f0bf98aa8238dd45332d
# Parent  93658ca85035d6a4e56e2e6602c02859974d30a4
libxl: add iommu parameter to qemu-dm.
When iomm = 0, virtual iommu device will be disabled.

Signed-off-by: Wei Wang <wei.wang2@amd.com>

diff -r 93658ca85035 -r 24f4a0a23da7 tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Wed Dec 14 16:22:23 2011 +0100
+++ b/tools/libxl/libxl_dm.c	Wed Dec 14 16:22:24 2011 +0100
@@ -194,6 +194,9 @@ static char ** libxl__build_device_model
         if (info->gfx_passthru) {
             flexarray_append(dm_args, "-gfx_passthru");
         }
+        if (info->iommu) {
+            flexarray_append(dm_args, "-iommu");
+        }
     }
     if (info->saved_state) {
         flexarray_vappend(dm_args, "-loadvm", info->saved_state, NULL);
@@ -404,6 +407,9 @@ static char ** libxl__build_device_model
         if (info->gfx_passthru) {
             flexarray_append(dm_args, "-gfx_passthru");
         }
+        if (info->iommu) {
+            flexarray_append(dm_args, "-iommu");
+        }
     }
     if (info->saved_state) {
         /* This file descriptor is meant to be used by QEMU */
diff -r 93658ca85035 -r 24f4a0a23da7 tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Wed Dec 14 16:22:23 2011 +0100
+++ b/tools/libxl/libxl_types.idl	Wed Dec 14 16:22:24 2011 +0100
@@ -254,6 +254,7 @@ The password never expires"""),
     ("extra",            libxl_string_list, False, "extra parameters pass directly to qemu, NULL terminated"),
     ("extra_pv",         libxl_string_list, False, "extra parameters pass directly to qemu for PV guest, NULL terminated"),
     ("extra_hvm",        libxl_string_list, False, "extra parameters pass directly to qemu for HVM guest, NULL terminated"),
+    ("iommu",            bool,              False, "guest iommu enabled or disabled"),
     ],
     comment=
 """Device Model information.
diff -r 93658ca85035 -r 24f4a0a23da7 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Wed Dec 14 16:22:23 2011 +0100
+++ b/tools/libxl/xl_cmdimpl.c	Wed Dec 14 16:22:24 2011 +0100
@@ -386,6 +386,7 @@ static void printf_info(int domid,
         printf("\t\t\t(spicedisable_ticketing %d)\n",
                     dm_info->spicedisable_ticketing);
         printf("\t\t\t(spiceagent_mouse %d)\n", dm_info->spiceagent_mouse);
+        printf("\t\t\t(iommu %d)\n", dm_info->iommu);
         printf("\t\t)\n");
         break;
     case LIBXL_DOMAIN_TYPE_PV:
@@ -1217,6 +1218,8 @@ skip_vfb:
         xlu_cfg_replace_string (config, "soundhw", &dm_info->soundhw, 0);
         if (!xlu_cfg_get_long (config, "xen_platform_pci", &l, 0))
             dm_info->xen_platform_pci = l;
+        if (!xlu_cfg_get_long (config, "iommu", &l, 0))
+            dm_info->iommu = l;
     }
 
     dm_info->type = c_info->type;


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 15:36:31 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 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.xensource.com>)
	id 1RaqsZ-0002y8-IG; Wed, 14 Dec 2011 15:36:23 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Wang2@amd.com>) id 1RaqsV-0002uH-Rg
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 15:36:20 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1323876922!7261259!1
X-Originating-IP: [216.32.181.184]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9886 invoked from network); 14 Dec 2011 15:35:23 -0000
Received: from ch1ehsobe004.messaging.microsoft.com (HELO
	ch1outboundpool.messaging.microsoft.com) (216.32.181.184)
	by server-4.tower-182.messagelabs.com with AES128-SHA encrypted SMTP;
	14 Dec 2011 15:35:23 -0000
Received: from mail204-ch1-R.bigfish.com (10.43.68.249) by
	CH1EHSOBE017.bigfish.com (10.43.70.67) with Microsoft SMTP Server id
	14.1.225.23; Wed, 14 Dec 2011 15:35:24 +0000
Received: from mail204-ch1 (localhost [127.0.0.1])	by
	mail204-ch1-R.bigfish.com (Postfix) with ESMTP id 3A4C6340396;
	Wed, 14 Dec 2011 15:35:25 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzzz1202hzz8275bhz2dh668h839h944h)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
X-FB-SS: 13,
Received: from mail204-ch1 (localhost.localdomain [127.0.0.1]) by mail204-ch1
	(MessageSwitch) id 1323876924612877_6214;
	Wed, 14 Dec 2011 15:35:24 +0000 (UTC)
Received: from CH1EHSMHS010.bigfish.com (snatpool1.int.messaging.microsoft.com
	[10.43.68.242])	by mail204-ch1.bigfish.com (Postfix) with ESMTP id
	869A640043;	Wed, 14 Dec 2011 15:35:24 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	CH1EHSMHS010.bigfish.com (10.43.70.10) with Microsoft SMTP Server id
	14.1.225.22; Wed, 14 Dec 2011 15:35:21 +0000
X-WSS-ID: 0LW79YR-01-C4B-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2A0E11028052;	Wed, 14 Dec 2011 09:35:14 -0600 (CST)
Received: from SAUSEXDAG02.amd.com (163.181.55.2) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Wed, 14 Dec 2011 09:35:27 -0600
Received: from storexhtp02.amd.com (172.24.4.4) by sausexdag02.amd.com
	(163.181.55.2) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Wed, 14 Dec 2011 09:35:16 -0600
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Wed, 14 Dec 2011
	10:35:11 -0500
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 0FEE049C620; Wed, 14 Dec 2011
	15:35:11 +0000 (GMT)
Received: from gran.amd.com (gran.osrc.amd.com [165.204.15.57])	by
	mail.osrc.amd.com (Postfix) with ESMTP id F19BE594882; Wed, 14 Dec 2011
	16:35:10 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: a3d2f93d82940a391de00717ddbf842f821fcea5
Message-ID: <a3d2f93d82940a391de0.1323876562@gran.amd.com>
In-Reply-To: <patchbomb.1323876561@gran.amd.com>
References: <patchbomb.1323876561@gran.amd.com>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Wed, 14 Dec 2011 16:29:22 +0100
From: Wei Wang <wei.wang2@amd.com>
To: <JBeulich@suse.com>, <keir@xen.org>
X-OriginatorOrg: amd.com
Cc: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 01 of 16] amd iommu: Refactoring iommu ring
	buffer definition
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Wei Wang <wei.wang2@amd.com>
# Date 1323863478 -3600
# Node ID a3d2f93d82940a391de00717ddbf842f821fcea5
# Parent  846725c81ed924e03bf4e6d65f912be089c54a06
amd iommu: Refactoring iommu ring buffer definition.
Introduce struct ring_buffer to represent iommu cmd buffer, event log and ppr log

Signed-off-by: Wei Wang <wei.wang2@amd.com>

diff -r 846725c81ed9 -r a3d2f93d8294 xen/drivers/passthrough/amd/iommu_cmd.c
--- a/xen/drivers/passthrough/amd/iommu_cmd.c	Tue Dec 13 13:32:23 2011 +0100
+++ b/xen/drivers/passthrough/amd/iommu_cmd.c	Wed Dec 14 12:51:18 2011 +0100
@@ -29,7 +29,7 @@ static int queue_iommu_command(struct am
     u32 tail, head, *cmd_buffer;
     int i;
 
-    tail = iommu->cmd_buffer_tail;
+    tail = iommu->cmd_buffer.tail;
     if ( ++tail == iommu->cmd_buffer.entries )
         tail = 0;
 
@@ -40,13 +40,13 @@ static int queue_iommu_command(struct am
     if ( head != tail )
     {
         cmd_buffer = (u32 *)(iommu->cmd_buffer.buffer +
-                             (iommu->cmd_buffer_tail *
+                             (iommu->cmd_buffer.tail *
                              IOMMU_CMD_BUFFER_ENTRY_SIZE));
 
         for ( i = 0; i < IOMMU_CMD_BUFFER_U32_PER_ENTRY; i++ )
             cmd_buffer[i] = cmd[i];
 
-        iommu->cmd_buffer_tail = tail;
+        iommu->cmd_buffer.tail = tail;
         return 1;
     }
 
@@ -57,7 +57,7 @@ static void commit_iommu_command_buffer(
 {
     u32 tail;
 
-    set_field_in_reg_u32(iommu->cmd_buffer_tail, 0,
+    set_field_in_reg_u32(iommu->cmd_buffer.tail, 0,
                          IOMMU_CMD_BUFFER_TAIL_MASK,
                          IOMMU_CMD_BUFFER_TAIL_SHIFT, &tail);
     writel(tail, iommu->mmio_base+IOMMU_CMD_BUFFER_TAIL_OFFSET);
diff -r 846725c81ed9 -r a3d2f93d8294 xen/drivers/passthrough/amd/iommu_init.c
--- a/xen/drivers/passthrough/amd/iommu_init.c	Tue Dec 13 13:32:23 2011 +0100
+++ b/xen/drivers/passthrough/amd/iommu_init.c	Wed Dec 14 12:51:18 2011 +0100
@@ -294,20 +294,20 @@ static int amd_iommu_read_event_log(stru
                                   IOMMU_EVENT_LOG_TAIL_MASK,
                                   IOMMU_EVENT_LOG_TAIL_SHIFT);
 
-    while ( tail != iommu->event_log_head )
+    while ( tail != iommu->event_log.head )
     {
         /* read event log entry */
         event_log = (u32 *)(iommu->event_log.buffer +
-                           (iommu->event_log_head *
+                           (iommu->event_log.head *
                            IOMMU_EVENT_LOG_ENTRY_SIZE));
 
         parse_event_log_entry(iommu, event_log);
 
-        if ( ++iommu->event_log_head == iommu->event_log.entries )
-            iommu->event_log_head = 0;
+        if ( ++iommu->event_log.head == iommu->event_log.entries )
+            iommu->event_log.head = 0;
 
         /* update head pointer */
-        set_field_in_reg_u32(iommu->event_log_head, 0,
+        set_field_in_reg_u32(iommu->event_log.head, 0,
                              IOMMU_EVENT_LOG_HEAD_MASK,
                              IOMMU_EVENT_LOG_HEAD_SHIFT, &head);
         writel(head, iommu->mmio_base + IOMMU_EVENT_LOG_HEAD_OFFSET);
@@ -346,7 +346,7 @@ static void amd_iommu_reset_event_log(st
     writel(entry, iommu->mmio_base+IOMMU_STATUS_MMIO_OFFSET);
 
     /*reset event log base address */
-    iommu->event_log_head = 0;
+    iommu->event_log.head = 0;
 
     set_iommu_event_log_control(iommu, IOMMU_CONTROL_ENABLED);
 }
@@ -605,71 +605,83 @@ static void enable_iommu(struct amd_iomm
 
 }
 
-static void __init deallocate_iommu_table_struct(
-    struct table_struct *table)
+static void __init deallocate_buffer(void *buf, uint32_t sz)
 {
     int order = 0;
-    if ( table->buffer )
+    if ( buf )
     {
-        order = get_order_from_bytes(table->alloc_size);
-        __free_amd_iommu_tables(table->buffer, order);
-        table->buffer = NULL;
+        order = get_order_from_bytes(sz);
+        __free_amd_iommu_tables(buf, order);
     }
 }
 
-static int __init allocate_iommu_table_struct(struct table_struct *table,
-                                              const char *name)
+static void __init deallocate_device_table(struct table_struct *table)
 {
-    int order = 0;
-    if ( table->buffer == NULL )
-    {
-        order = get_order_from_bytes(table->alloc_size);
-        table->buffer = __alloc_amd_iommu_tables(order);
-
-        if ( table->buffer == NULL )
-        {
-            AMD_IOMMU_DEBUG("Error allocating %s\n", name);
-            return -ENOMEM;
-        }
-        memset(table->buffer, 0, PAGE_SIZE * (1UL << order));
-    }
-    return 0;
+    deallocate_buffer(table->buffer, table->alloc_size);
+    table->buffer = NULL;
 }
 
-static int __init allocate_cmd_buffer(struct amd_iommu *iommu)
+static void __init deallocate_ring_buffer(struct ring_buffer *ring_buf)
+{
+    deallocate_buffer(ring_buf->buffer, ring_buf->alloc_size);
+    ring_buf->buffer = NULL;
+    ring_buf->head = 0;
+    ring_buf->tail = 0;
+}
+
+static void * __init allocate_buffer(uint32_t alloc_size, const char *name)
+{
+    void * buffer;
+    int order = get_order_from_bytes(alloc_size);
+
+    buffer = __alloc_amd_iommu_tables(order);
+
+    if ( buffer == NULL )
+    {
+        AMD_IOMMU_DEBUG("Error allocating %s\n", name);
+        return NULL;
+    }
+
+    memset(buffer, 0, PAGE_SIZE * (1UL << order));
+    return buffer;
+}
+
+static void * __init allocate_ring_buffer(struct ring_buffer *ring_buf,
+                                          uint32_t entry_size, 
+                                          uint64_t entries, const char *name)
+{
+    ring_buf->head = 0;
+    ring_buf->tail = 0;
+
+    ring_buf->entry_size = entry_size;
+    ring_buf->alloc_size = PAGE_SIZE << get_order_from_bytes(entries * 
+                                                             entry_size);
+    ring_buf->entries = ring_buf->alloc_size / entry_size;
+    ring_buf->buffer = allocate_buffer(ring_buf->alloc_size, name);
+    return ring_buf->buffer;
+}
+
+static void * __init allocate_cmd_buffer(struct amd_iommu *iommu)
 {
     /* allocate 'command buffer' in power of 2 increments of 4K */
-    iommu->cmd_buffer_tail = 0;
-    iommu->cmd_buffer.alloc_size = PAGE_SIZE <<
-                                   get_order_from_bytes(
-                                   PAGE_ALIGN(IOMMU_CMD_BUFFER_DEFAULT_ENTRIES
-                                              * IOMMU_CMD_BUFFER_ENTRY_SIZE));
-    iommu->cmd_buffer.entries = iommu->cmd_buffer.alloc_size /
-                                IOMMU_CMD_BUFFER_ENTRY_SIZE;
-
-    return (allocate_iommu_table_struct(&iommu->cmd_buffer, "Command Buffer"));
+    return allocate_ring_buffer(&iommu->cmd_buffer, sizeof(cmd_entry_t),
+                                IOMMU_CMD_BUFFER_DEFAULT_ENTRIES, 
+                                "Command Buffer");
 }
 
-static int __init allocate_event_log(struct amd_iommu *iommu)
+static void * __init allocate_event_log(struct amd_iommu *iommu)
 {
-   /* allocate 'event log' in power of 2 increments of 4K */
-    iommu->event_log_head = 0;
-    iommu->event_log.alloc_size = PAGE_SIZE <<
-                                  get_order_from_bytes(
-                                  PAGE_ALIGN(IOMMU_EVENT_LOG_DEFAULT_ENTRIES *
-                                  IOMMU_EVENT_LOG_ENTRY_SIZE));
-    iommu->event_log.entries = iommu->event_log.alloc_size /
-                               IOMMU_EVENT_LOG_ENTRY_SIZE;
-
-    return (allocate_iommu_table_struct(&iommu->event_log, "Event Log"));
+    /* allocate 'event log' in power of 2 increments of 4K */
+    return allocate_ring_buffer(&iommu->event_log, sizeof(event_entry_t),
+                                IOMMU_EVENT_LOG_DEFAULT_ENTRIES, "Event Log");
 }
 
 static int __init amd_iommu_init_one(struct amd_iommu *iommu)
 {
-    if ( allocate_cmd_buffer(iommu) != 0 )
+    if ( allocate_cmd_buffer(iommu) == NULL )
         goto error_out;
 
-    if ( allocate_event_log(iommu) != 0 )
+    if ( allocate_event_log(iommu) == NULL )
         goto error_out;
 
     if ( map_iommu_mmio_region(iommu) != 0 )
@@ -708,8 +720,8 @@ static void __init amd_iommu_init_cleanu
         list_del(&iommu->list);
         if ( iommu->enabled )
         {
-            deallocate_iommu_table_struct(&iommu->cmd_buffer);
-            deallocate_iommu_table_struct(&iommu->event_log);
+            deallocate_ring_buffer(&iommu->cmd_buffer);
+            deallocate_ring_buffer(&iommu->event_log);
             unmap_iommu_mmio_region(iommu);
         }
         xfree(iommu);
@@ -719,7 +731,7 @@ static void __init amd_iommu_init_cleanu
     iterate_ivrs_entries(amd_iommu_free_intremap_table);
 
     /* free device table */
-    deallocate_iommu_table_struct(&device_table);
+    deallocate_device_table(&device_table);
 
     /* free ivrs_mappings[] */
     radix_tree_destroy(&ivrs_maps, xfree);
@@ -830,8 +842,10 @@ static int __init amd_iommu_setup_device
     device_table.entries = device_table.alloc_size /
                            IOMMU_DEV_TABLE_ENTRY_SIZE;
 
-    if ( allocate_iommu_table_struct(&device_table, "Device Table") != 0 )
-         return -ENOMEM;
+    device_table.buffer = allocate_buffer(device_table.alloc_size, 
+                                          "Device Table");
+    if  ( device_table.buffer == NULL )
+        return -ENOMEM;
 
     /* Add device table entries */
     for ( bdf = 0; bdf < ivrs_bdf_entries; bdf++ )
diff -r 846725c81ed9 -r a3d2f93d8294 xen/include/asm-x86/amd-iommu.h
--- a/xen/include/asm-x86/amd-iommu.h	Tue Dec 13 13:32:23 2011 +0100
+++ b/xen/include/asm-x86/amd-iommu.h	Wed Dec 14 12:51:18 2011 +0100
@@ -30,12 +30,43 @@
 
 extern struct list_head amd_iommu_head;
 
+#pragma pack(1)
+typedef struct event_entry
+{
+    uint32_t data[4];
+} event_entry_t;
+
+typedef struct ppr_entry
+{
+    uint32_t data[4];
+} ppr_entry_t;
+
+typedef struct cmd_entry
+{
+    uint32_t data[4];
+} cmd_entry_t;
+
+typedef struct dev_entry
+{
+    uint32_t data[8];
+} dev_entry_t;
+#pragma pack()
+
 struct table_struct {
     void *buffer;
     unsigned long entries;
     unsigned long alloc_size;
 };
 
+struct ring_buffer {
+    void *buffer;
+    unsigned long entries;
+    unsigned long alloc_size;
+    unsigned long entry_size;
+    uint32_t tail;
+    uint32_t head;
+};
+
 typedef struct iommu_cap {
     uint32_t header;                    /* offset 00h */
     uint32_t base_low;                  /* offset 04h */
@@ -60,10 +91,8 @@ struct amd_iommu {
     unsigned long mmio_base_phys;
 
     struct table_struct dev_table;
-    struct table_struct cmd_buffer;
-    u32 cmd_buffer_tail;
-    struct table_struct event_log;
-    u32 event_log_head;
+    struct ring_buffer cmd_buffer;
+    struct ring_buffer event_log;
 
     int exclusion_enable;
     int exclusion_allow_all;


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 15:36:31 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 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.xensource.com>)
	id 1RaqsY-0002xb-Vs; Wed, 14 Dec 2011 15:36:22 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Wang2@amd.com>) id 1RaqsW-0002uL-0p
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 15:36:20 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1323876884!50611964!1
X-Originating-IP: [213.199.154.141]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12694 invoked from network); 14 Dec 2011 15:34:45 -0000
Received: from db3ehsobe003.messaging.microsoft.com (HELO
	DB3EHSOBE003.bigfish.com) (213.199.154.141)
	by server-6.tower-27.messagelabs.com with AES128-SHA encrypted SMTP;
	14 Dec 2011 15:34:45 -0000
Received: from mail109-db3-R.bigfish.com (10.3.81.242) by
	DB3EHSOBE003.bigfish.com (10.3.84.23) with Microsoft SMTP Server id
	14.1.225.23; Wed, 14 Dec 2011 15:35:26 +0000
Received: from mail109-db3 (localhost [127.0.0.1])	by
	mail109-db3-R.bigfish.com (Postfix) with ESMTP id 1C29E4E0060;
	Wed, 14 Dec 2011 15:35:27 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzzz1202hzz8275bhz2dh668h839h944h)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
X-FB-SS: 13,
Received: from mail109-db3 (localhost.localdomain [127.0.0.1]) by mail109-db3
	(MessageSwitch) id 1323876926956380_9306;
	Wed, 14 Dec 2011 15:35:26 +0000 (UTC)
Received: from DB3EHSMHS005.bigfish.com (unknown [10.3.81.249])	by
	mail109-db3.bigfish.com (Postfix) with ESMTP id E408D580046;
	Wed, 14 Dec 2011 15:35:26 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	DB3EHSMHS005.bigfish.com (10.3.87.105) with Microsoft SMTP Server id
	14.1.225.23; Wed, 14 Dec 2011 15:35:24 +0000
X-WSS-ID: 0LW79YV-01-C4R-02
X-M-MSG: 
Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com
	[163.181.249.73])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2C93C102805A;	Wed, 14 Dec 2011 09:35:18 -0600 (CST)
Received: from SAUSEXDAG01.amd.com (163.181.55.1) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Wed, 14 Dec 2011 09:35:31 -0600
Received: from storexhtp01.amd.com (172.24.4.3) by sausexdag01.amd.com
	(163.181.55.1) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Wed, 14 Dec 2011 09:35:19 -0600
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp01.amd.com
	(172.24.4.3) with Microsoft SMTP Server id 8.3.213.0; Wed, 14 Dec 2011
	10:35:16 -0500
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 35B9649C667; Wed, 14 Dec 2011
	15:35:12 +0000 (GMT)
Received: from gran.amd.com (gran.osrc.amd.com [165.204.15.57])	by
	mail.osrc.amd.com (Postfix) with ESMTP id 1573C594884; Wed, 14 Dec 2011
	16:35:12 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 04573463beff7fc9696f5ecdb940920dcc2ec0ca
Message-ID: <04573463beff7fc9696f.1323876574@gran.amd.com>
In-Reply-To: <patchbomb.1323876561@gran.amd.com>
References: <patchbomb.1323876561@gran.amd.com>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Wed, 14 Dec 2011 16:29:34 +0100
From: Wei Wang <wei.wang2@amd.com>
To: <JBeulich@suse.com>, <keir@xen.org>
X-OriginatorOrg: amd.com
Cc: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 13 of 16] libxc: add wrappers for new hypercalls
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Wei Wang <wei.wang2@amd.com>
# Date 1323876141 -3600
# Node ID 04573463beff7fc9696f5ecdb940920dcc2ec0ca
# Parent  42ecb2ba593c2827b2dc4e54360f8c6a42a4dbfc
libxc: add wrappers for new hypercalls

Signed-off-by: Wei Wang <wei.wang2@amd.com>

diff -r 42ecb2ba593c -r 04573463beff tools/libxc/xc_domain.c
--- a/tools/libxc/xc_domain.c	Wed Dec 14 16:22:20 2011 +0100
+++ b/tools/libxc/xc_domain.c	Wed Dec 14 16:22:21 2011 +0100
@@ -1352,6 +1352,55 @@ int xc_domain_bind_pt_isa_irq(
                                   PT_IRQ_TYPE_ISA, 0, 0, 0, machine_irq));
 }
 
+int xc_domain_update_iommu_msi(
+    xc_interface *xch,
+    uint32_t domid,
+    uint8_t vector,
+    uint8_t dest,
+    uint8_t dest_mode,
+    uint8_t delivery_mode,
+    uint8_t trig_mode)
+{
+    int rc;
+    DECLARE_DOMCTL;
+    xen_domctl_guest_iommu_op_t * iommu_op;
+
+    domctl.cmd = XEN_DOMCTL_guest_iommu_op;
+    domctl.domain = (domid_t)domid;
+
+    iommu_op = &(domctl.u.guest_iommu_op);
+    iommu_op->op = XEN_DOMCTL_GUEST_IOMMU_OP_SET_MSI;
+    iommu_op->u.msi.vector = vector;
+    iommu_op->u.msi.dest = dest;
+    iommu_op->u.msi.dest_mode = dest_mode;
+    iommu_op->u.msi.delivery_mode = delivery_mode;
+    iommu_op->u.msi.trig_mode = trig_mode;
+
+    rc = do_domctl(xch, &domctl);
+    return rc;
+}
+
+int xc_domain_bind_pt_bdf(xc_interface *xch,
+                          uint32_t domid,
+                          uint32_t gbdf,
+                          uint32_t mbdf)
+{
+    int rc;
+    DECLARE_DOMCTL;
+    xen_domctl_guest_iommu_op_t * guest_op;
+
+    domctl.cmd = XEN_DOMCTL_guest_iommu_op;
+    domctl.domain = (domid_t)domid;
+
+    guest_op = &(domctl.u.guest_iommu_op);
+    guest_op->op = XEN_DOMCTL_GUEST_IOMMU_OP_BIND_BDF;
+    guest_op->u.bdf_bind.g_bdf = gbdf;
+    guest_op->u.bdf_bind.m_bdf = mbdf;
+
+    rc = do_domctl(xch, &domctl);
+    return rc;
+}
+
 int xc_domain_memory_mapping(
     xc_interface *xch,
     uint32_t domid,
diff -r 42ecb2ba593c -r 04573463beff tools/libxc/xenctrl.h
--- a/tools/libxc/xenctrl.h	Wed Dec 14 16:22:20 2011 +0100
+++ b/tools/libxc/xenctrl.h	Wed Dec 14 16:22:21 2011 +0100
@@ -1697,6 +1697,19 @@ int xc_domain_bind_pt_isa_irq(xc_interfa
                               uint32_t domid,
                               uint8_t machine_irq);
 
+int xc_domain_bind_pt_bdf(xc_interface *xch,
+                          uint32_t domid,
+                          uint32_t gbdf,
+                          uint32_t mbdf);
+
+int xc_domain_update_iommu_msi(xc_interface *xch,
+                               uint32_t domid,
+                               uint8_t vector,
+                               uint8_t dest,
+                               uint8_t dest_mode,
+                               uint8_t delivery_mode,
+                               uint8_t trig_mode);
+
 int xc_domain_set_machine_address_size(xc_interface *xch,
 				       uint32_t domid,
 				       unsigned int width);


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 15:36:31 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 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.xensource.com>)
	id 1RaqsY-0002x9-IU; Wed, 14 Dec 2011 15:36:22 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Wang2@amd.com>) id 1RaqsV-0002uI-SX
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 15:36:20 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1323876923!7261262!1
X-Originating-IP: [213.199.154.140]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9913 invoked from network); 14 Dec 2011 15:35:24 -0000
Received: from db3ehsobe002.messaging.microsoft.com (HELO
	DB3EHSOBE002.bigfish.com) (213.199.154.140)
	by server-4.tower-182.messagelabs.com with AES128-SHA encrypted SMTP;
	14 Dec 2011 15:35:24 -0000
Received: from mail53-db3-R.bigfish.com (10.3.81.254) by
	DB3EHSOBE002.bigfish.com (10.3.84.22) with Microsoft SMTP Server id
	14.1.225.23; Wed, 14 Dec 2011 15:35:25 +0000
Received: from mail53-db3 (localhost [127.0.0.1])	by mail53-db3-R.bigfish.com
	(Postfix) with ESMTP id 8D05F80313;
	Wed, 14 Dec 2011 15:35:26 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzzz1202hzz8275bhz2dh668h839h944h)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
X-FB-SS: 13,
Received: from mail53-db3 (localhost.localdomain [127.0.0.1]) by mail53-db3
	(MessageSwitch) id 1323876926227852_5691;
	Wed, 14 Dec 2011 15:35:26 +0000 (UTC)
Received: from DB3EHSMHS002.bigfish.com (unknown [10.3.81.240])	by
	mail53-db3.bigfish.com (Postfix) with ESMTP id 286711C0046;
	Wed, 14 Dec 2011 15:35:26 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	DB3EHSMHS002.bigfish.com (10.3.87.102) with Microsoft SMTP Server id
	14.1.225.23; Wed, 14 Dec 2011 15:35:24 +0000
X-WSS-ID: 0LW79YV-01-C4N-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 219D21028051;	Wed, 14 Dec 2011 09:35:18 -0600 (CST)
Received: from SAUSEXDAG02.amd.com (163.181.55.2) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Wed, 14 Dec 2011 09:35:31 -0600
Received: from storexhtp02.amd.com (172.24.4.4) by sausexdag02.amd.com
	(163.181.55.2) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Wed, 14 Dec 2011 09:35:19 -0600
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Wed, 14 Dec 2011
	10:35:16 -0500
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 1642049C666; Wed, 14 Dec 2011
	15:35:12 +0000 (GMT)
Received: from gran.amd.com (gran.osrc.amd.com [165.204.15.57])	by
	mail.osrc.amd.com (Postfix) with ESMTP id D896559488B; Wed, 14 Dec 2011
	16:35:11 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 42ecb2ba593c2827b2dc4e54360f8c6a42a4dbfc
Message-ID: <42ecb2ba593c2827b2dc.1323876573@gran.amd.com>
In-Reply-To: <patchbomb.1323876561@gran.amd.com>
References: <patchbomb.1323876561@gran.amd.com>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Wed, 14 Dec 2011 16:29:33 +0100
From: Wei Wang <wei.wang2@amd.com>
To: <JBeulich@suse.com>, <keir@xen.org>
X-OriginatorOrg: amd.com
Cc: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 12 of 16] hvmloader: Build IVRS table
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Wei Wang <wei.wang2@amd.com>
# Date 1323876140 -3600
# Node ID 42ecb2ba593c2827b2dc4e54360f8c6a42a4dbfc
# Parent  9a93e064dd3c467ce4b87ddef8739a3573ef547c
hvmloader: Build IVRS table.
Signed-off-by: Wei Wang <wei.wang2@amd.com>

diff -r 9a93e064dd3c -r 42ecb2ba593c tools/firmware/hvmloader/acpi/acpi2_0.h
--- a/tools/firmware/hvmloader/acpi/acpi2_0.h	Wed Dec 14 16:16:16 2011 +0100
+++ b/tools/firmware/hvmloader/acpi/acpi2_0.h	Wed Dec 14 16:22:20 2011 +0100
@@ -389,6 +389,60 @@ struct acpi_20_madt_intsrcovr {
 #define ACPI_2_0_WAET_REVISION 0x01
 #define ACPI_1_0_FADT_REVISION 0x01
 
+#define IVRS_SIGNATURE ASCII32('I','V','R','S')
+#define IVRS_REVISION           1
+#define IVRS_VASIZE             64
+#define IVRS_PASIZE             52
+#define IVRS_GVASIZE            64
+
+#define IVHD_BLOCK_TYPE         0x10
+#define IVHD_FLAG_HTTUNEN       (1 << 0)
+#define IVHD_FLAG_PASSPW        (1 << 1)
+#define IVHD_FLAG_RESPASSPW     (1 << 2)
+#define IVHD_FLAG_ISOC          (1 << 3)
+#define IVHD_FLAG_IOTLBSUP      (1 << 4)
+#define IVHD_FLAG_COHERENT      (1 << 5)
+#define IVHD_FLAG_PREFSUP       (1 << 6)
+#define IVHD_FLAG_PPRSUP        (1 << 7)
+
+#define IVHD_EFR_GTSUP          (1 << 2)
+#define IVHD_EFR_IASUP          (1 << 5)
+
+#define IVHD_SELECT_4_BYTE      0x2
+
+struct ivrs_ivhd_block
+{
+    uint8_t    type;
+    uint8_t    flags;
+    uint16_t   length;
+    uint16_t   devid;
+    uint16_t   cap_offset;
+    uint64_t   iommu_base_addr;
+    uint16_t   pci_segment;
+    uint16_t   iommu_info;
+    uint32_t   reserved;
+};
+
+/* IVHD 4-byte device entries */
+struct ivrs_ivhd_device
+{
+   uint8_t  type;
+   uint16_t dev_id;
+   uint8_t  flags;
+};
+
+#define PT_DEV_MAX_NR           32
+#define IOMMU_CAP_OFFSET        0x40
+struct acpi_40_ivrs
+{
+    struct acpi_header                      header;
+    uint32_t                                iv_info;
+    uint32_t                                reserved[2];
+    struct ivrs_ivhd_block                  ivhd_block;
+    struct ivrs_ivhd_device                 ivhd_device[PT_DEV_MAX_NR];
+};
+
+
 #pragma pack ()
 
 struct acpi_config {
diff -r 9a93e064dd3c -r 42ecb2ba593c tools/firmware/hvmloader/acpi/build.c
--- a/tools/firmware/hvmloader/acpi/build.c	Wed Dec 14 16:16:16 2011 +0100
+++ b/tools/firmware/hvmloader/acpi/build.c	Wed Dec 14 16:22:20 2011 +0100
@@ -23,6 +23,8 @@
 #include "ssdt_pm.h"
 #include "../config.h"
 #include "../util.h"
+#include "../hypercall.h"
+#include <xen/hvm/params.h>
 
 #define align16(sz)        (((sz) + 15) & ~15)
 #define fixed_strcpy(d, s) strncpy((d), (s), sizeof(d))
@@ -198,6 +200,77 @@ static struct acpi_20_waet *construct_wa
     return waet;
 }
 
+extern uint32_t ptdev_bdf[PT_DEV_MAX_NR];
+extern uint32_t ptdev_nr;
+extern uint32_t iommu_bdf;
+static struct acpi_40_ivrs* construct_ivrs(void)
+{
+    struct acpi_40_ivrs *ivrs;
+    uint64_t mmio;
+    struct ivrs_ivhd_block *ivhd;
+    struct ivrs_ivhd_device *dev_entry;
+    struct xen_hvm_param p;
+
+    if (ptdev_nr == 0) return NULL;
+
+    ivrs = mem_alloc(sizeof(*ivrs), 16);
+    if (!ivrs) return NULL;
+
+    memset(ivrs, 0, sizeof(*ivrs));
+
+    /* initialize acpi header */
+    ivrs->header.signature = IVRS_SIGNATURE;
+    ivrs->header.revision = IVRS_REVISION;
+    fixed_strcpy(ivrs->header.oem_id, ACPI_OEM_ID);
+    fixed_strcpy(ivrs->header.oem_table_id, ACPI_OEM_TABLE_ID);
+
+    ivrs->header.oem_revision = ACPI_OEM_REVISION;
+    ivrs->header.creator_id   = ACPI_CREATOR_ID;
+    ivrs->header.creator_revision = ACPI_CREATOR_REVISION;
+
+    ivrs->header.length = sizeof(*ivrs);
+
+    /* initialize IVHD Block */
+    ivhd = &ivrs->ivhd_block;
+    ivrs->iv_info = (IVRS_VASIZE << 15) | (IVRS_PASIZE << 8) |
+                    (IVRS_GVASIZE << 5);
+
+    ivhd->type          = IVHD_BLOCK_TYPE;
+    ivhd->flags         = IVHD_FLAG_PPRSUP | IVHD_FLAG_IOTLBSUP;
+    ivhd->devid         = iommu_bdf;
+    ivhd->cap_offset    = IOMMU_CAP_OFFSET;
+
+    /*reserve 32K IOMMU MMIO space */
+    mmio = virt_to_phys(mem_alloc(0x8000, 0x1000));
+    if (!mmio) return NULL;
+
+    p.domid = DOMID_SELF;
+    p.index = HVM_PARAM_IOMMU_BASE;
+    p.value = mmio;
+
+    /* Return non-zero if IOMMUv2 hardware is not avaliable */
+    if ( hypercall_hvm_op(HVMOP_set_param, &p) )
+        return NULL;
+
+    ivhd->iommu_base_addr = mmio;
+    ivhd->reserved = IVHD_EFR_IASUP | IVHD_EFR_GTSUP;
+
+    /* Build IVHD device entries */
+    dev_entry = ivrs->ivhd_device;
+    for ( int i = 0; i < ptdev_nr; i++ )
+    {
+        dev_entry[i].type   = IVHD_SELECT_4_BYTE;
+        dev_entry[i].dev_id = ptdev_bdf[i];
+        dev_entry[i].flags  = 0;
+    }
+
+    ivhd->length = sizeof(*ivhd) + sizeof(*dev_entry) * PT_DEV_MAX_NR;
+    set_checksum(ivrs, offsetof(struct acpi_header, checksum), 
+                 ivrs->header.length);
+
+    return ivrs;
+}
+
 static int construct_secondary_tables(unsigned long *table_ptrs,
                                       struct acpi_info *info)
 {
@@ -206,6 +279,7 @@ static int construct_secondary_tables(un
     struct acpi_20_hpet *hpet;
     struct acpi_20_waet *waet;
     struct acpi_20_tcpa *tcpa;
+    struct acpi_40_ivrs *ivrs;
     unsigned char *ssdt;
     static const uint16_t tis_signature[] = {0x0001, 0x0001, 0x0001};
     uint16_t *tis_hdr;
@@ -293,6 +367,13 @@ static int construct_secondary_tables(un
         }
     }
 
+    if ( hvm_info->iommu_enabled )
+    {
+        ivrs = construct_ivrs();
+        if ( ivrs != NULL )
+            table_ptrs[nr_tables++] = (unsigned long)ivrs;
+    }
+
     table_ptrs[nr_tables] = 0;
     return nr_tables;
 }
diff -r 9a93e064dd3c -r 42ecb2ba593c tools/firmware/hvmloader/pci.c
--- a/tools/firmware/hvmloader/pci.c	Wed Dec 14 16:16:16 2011 +0100
+++ b/tools/firmware/hvmloader/pci.c	Wed Dec 14 16:22:20 2011 +0100
@@ -34,11 +34,17 @@ unsigned long pci_mem_end = PCI_MEM_END;
 enum virtual_vga virtual_vga = VGA_none;
 unsigned long igd_opregion_pgbase = 0;
 
+/* support up to 32 passthrough devices */
+#define PT_DEV_MAX_NR           32
+uint32_t ptdev_bdf[PT_DEV_MAX_NR];
+uint32_t ptdev_nr;
+uint32_t iommu_bdf;
+
 void pci_setup(void)
 {
     uint32_t base, devfn, bar_reg, bar_data, bar_sz, cmd, mmio_total = 0;
     uint32_t vga_devfn = 256;
-    uint16_t class, vendor_id, device_id;
+    uint16_t class, vendor_id, device_id, sub_vendor_id;
     unsigned int bar, pin, link, isa_irq;
 
     /* Resources assignable to PCI devices via BARs. */
@@ -72,11 +78,34 @@ void pci_setup(void)
         class     = pci_readw(devfn, PCI_CLASS_DEVICE);
         vendor_id = pci_readw(devfn, PCI_VENDOR_ID);
         device_id = pci_readw(devfn, PCI_DEVICE_ID);
+        sub_vendor_id = pci_readw(devfn, PCI_SUBSYSTEM_VENDOR_ID);
+
         if ( (vendor_id == 0xffff) && (device_id == 0xffff) )
             continue;
 
         ASSERT((devfn != PCI_ISA_DEVFN) ||
                ((vendor_id == 0x8086) && (device_id == 0x7000)));
+        /* Found amd iommu device. */
+        if ( class == 0x0806 && vendor_id == 0x1022 )
+        {
+            iommu_bdf = devfn;
+            printf("Found iommu devfn %x class %x\n", iommu_bdf, class);
+            continue;
+        }
+
+        /* IVRS: Detecting passthrough devices.
+         * sub_vendor_id != citrix && sub_vendor_id != qemu */
+        if ( sub_vendor_id != 0x5853 && sub_vendor_id != 0x1af4 )
+        {
+            /* found amd iommu device */
+            if ( ptdev_nr < PT_DEV_MAX_NR )
+            {
+                ptdev_bdf[ptdev_nr] = devfn;
+                ptdev_nr ++;
+            }
+            else
+                printf("Number of passthru devices > PT_DEV_MAX_NR \n");
+        }
 
         switch ( class )
         {
diff -r 9a93e064dd3c -r 42ecb2ba593c xen/include/public/hvm/hvm_info_table.h
--- a/xen/include/public/hvm/hvm_info_table.h	Wed Dec 14 16:16:16 2011 +0100
+++ b/xen/include/public/hvm/hvm_info_table.h	Wed Dec 14 16:22:20 2011 +0100
@@ -67,6 +67,9 @@ struct hvm_info_table {
 
     /* Bitmap of which CPUs are online at boot time. */
     uint8_t     vcpu_online[(HVM_MAX_VCPUS + 7)/8];
+
+    /* guest iommu enabled */
+    uint8_t     iommu_enabled;
 };
 
 #endif /* __XEN_PUBLIC_HVM_HVM_INFO_TABLE_H__ */


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 15:36:31 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 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.xensource.com>)
	id 1Raqsb-0002zw-2G; Wed, 14 Dec 2011 15:36:25 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Wang2@amd.com>) id 1RaqsX-0002uV-KR
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 15:36:21 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1323876924!7202502!1
X-Originating-IP: [213.199.154.205]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32320 invoked from network); 14 Dec 2011 15:35:24 -0000
Received: from am1ehsobe002.messaging.microsoft.com (HELO
	AM1EHSOBE002.bigfish.com) (213.199.154.205)
	by server-15.tower-182.messagelabs.com with AES128-SHA encrypted SMTP;
	14 Dec 2011 15:35:24 -0000
Received: from mail73-am1-R.bigfish.com (10.3.201.251) by
	AM1EHSOBE002.bigfish.com (10.3.204.22) with Microsoft SMTP Server id
	14.1.225.23; Wed, 14 Dec 2011 15:35:26 +0000
Received: from mail73-am1 (localhost [127.0.0.1])	by mail73-am1-R.bigfish.com
	(Postfix) with ESMTP id A2FA71C025B;
	Wed, 14 Dec 2011 15:35:27 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzzz1202hzz8275bhz2dh668h839h944h)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
X-FB-SS: 13,
Received: from mail73-am1 (localhost.localdomain [127.0.0.1]) by mail73-am1
	(MessageSwitch) id 1323876927467799_28770;
	Wed, 14 Dec 2011 15:35:27 +0000 (UTC)
Received: from AM1EHSMHS004.bigfish.com (unknown [10.3.201.249])	by
	mail73-am1.bigfish.com (Postfix) with ESMTP id 6B062500082;
	Wed, 14 Dec 2011 15:35:27 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	AM1EHSMHS004.bigfish.com (10.3.207.104) with Microsoft SMTP Server id
	14.1.225.23; Wed, 14 Dec 2011 15:35:25 +0000
X-WSS-ID: 0LW79YV-02-A9Y-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp02.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 243CAC807C;	Wed, 14 Dec 2011 09:35:18 -0600 (CST)
Received: from SAUSEXDAG02.amd.com (163.181.55.2) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Wed, 14 Dec 2011 09:35:32 -0600
Received: from storexhtp02.amd.com (172.24.4.4) by sausexdag02.amd.com
	(163.181.55.2) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Wed, 14 Dec 2011 09:35:20 -0600
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Wed, 14 Dec 2011
	10:35:17 -0500
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 77E4449C66A; Wed, 14 Dec 2011
	15:35:12 +0000 (GMT)
Received: from gran.amd.com (gran.osrc.amd.com [165.204.15.57])	by
	mail.osrc.amd.com (Postfix) with ESMTP id 5F5F559488D; Wed, 14 Dec 2011
	16:35:12 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 24f4a0a23da71c58f457f0bf98aa8238dd45332d
Message-ID: <24f4a0a23da71c58f457.1323876577@gran.amd.com>
In-Reply-To: <patchbomb.1323876561@gran.amd.com>
References: <patchbomb.1323876561@gran.amd.com>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Wed, 14 Dec 2011 16:29:37 +0100
From: Wei Wang <wei.wang2@amd.com>
To: <JBeulich@suse.com>, <keir@xen.org>
X-OriginatorOrg: amd.com
Cc: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 16 of 16] libxl: add iommu parameter to qemu-dm
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Wei Wang <wei.wang2@amd.com>
# Date 1323876144 -3600
# Node ID 24f4a0a23da71c58f457f0bf98aa8238dd45332d
# Parent  93658ca85035d6a4e56e2e6602c02859974d30a4
libxl: add iommu parameter to qemu-dm.
When iomm = 0, virtual iommu device will be disabled.

Signed-off-by: Wei Wang <wei.wang2@amd.com>

diff -r 93658ca85035 -r 24f4a0a23da7 tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Wed Dec 14 16:22:23 2011 +0100
+++ b/tools/libxl/libxl_dm.c	Wed Dec 14 16:22:24 2011 +0100
@@ -194,6 +194,9 @@ static char ** libxl__build_device_model
         if (info->gfx_passthru) {
             flexarray_append(dm_args, "-gfx_passthru");
         }
+        if (info->iommu) {
+            flexarray_append(dm_args, "-iommu");
+        }
     }
     if (info->saved_state) {
         flexarray_vappend(dm_args, "-loadvm", info->saved_state, NULL);
@@ -404,6 +407,9 @@ static char ** libxl__build_device_model
         if (info->gfx_passthru) {
             flexarray_append(dm_args, "-gfx_passthru");
         }
+        if (info->iommu) {
+            flexarray_append(dm_args, "-iommu");
+        }
     }
     if (info->saved_state) {
         /* This file descriptor is meant to be used by QEMU */
diff -r 93658ca85035 -r 24f4a0a23da7 tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Wed Dec 14 16:22:23 2011 +0100
+++ b/tools/libxl/libxl_types.idl	Wed Dec 14 16:22:24 2011 +0100
@@ -254,6 +254,7 @@ The password never expires"""),
     ("extra",            libxl_string_list, False, "extra parameters pass directly to qemu, NULL terminated"),
     ("extra_pv",         libxl_string_list, False, "extra parameters pass directly to qemu for PV guest, NULL terminated"),
     ("extra_hvm",        libxl_string_list, False, "extra parameters pass directly to qemu for HVM guest, NULL terminated"),
+    ("iommu",            bool,              False, "guest iommu enabled or disabled"),
     ],
     comment=
 """Device Model information.
diff -r 93658ca85035 -r 24f4a0a23da7 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Wed Dec 14 16:22:23 2011 +0100
+++ b/tools/libxl/xl_cmdimpl.c	Wed Dec 14 16:22:24 2011 +0100
@@ -386,6 +386,7 @@ static void printf_info(int domid,
         printf("\t\t\t(spicedisable_ticketing %d)\n",
                     dm_info->spicedisable_ticketing);
         printf("\t\t\t(spiceagent_mouse %d)\n", dm_info->spiceagent_mouse);
+        printf("\t\t\t(iommu %d)\n", dm_info->iommu);
         printf("\t\t)\n");
         break;
     case LIBXL_DOMAIN_TYPE_PV:
@@ -1217,6 +1218,8 @@ skip_vfb:
         xlu_cfg_replace_string (config, "soundhw", &dm_info->soundhw, 0);
         if (!xlu_cfg_get_long (config, "xen_platform_pci", &l, 0))
             dm_info->xen_platform_pci = l;
+        if (!xlu_cfg_get_long (config, "iommu", &l, 0))
+            dm_info->iommu = l;
     }
 
     dm_info->type = c_info->type;


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 15:36:44 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 15:36:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Raqss-0003KI-8y; Wed, 14 Dec 2011 15:36:42 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Wang2@amd.com>) id 1Raqsq-0003Dv-2P
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 15:36:40 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1323876944!1513098!1
X-Originating-IP: [213.199.154.141]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7651 invoked from network); 14 Dec 2011 15:35:44 -0000
Received: from db3ehsobe003.messaging.microsoft.com (HELO
	DB3EHSOBE003.bigfish.com) (213.199.154.141)
	by server-16.tower-21.messagelabs.com with AES128-SHA encrypted SMTP;
	14 Dec 2011 15:35:44 -0000
Received: from mail12-db3-R.bigfish.com (10.3.81.244) by
	DB3EHSOBE003.bigfish.com (10.3.84.23) with Microsoft SMTP Server id
	14.1.225.23; Wed, 14 Dec 2011 15:35:46 +0000
Received: from mail12-db3 (localhost [127.0.0.1])	by mail12-db3-R.bigfish.com
	(Postfix) with ESMTP id 230776C04B8;
	Wed, 14 Dec 2011 15:35:47 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzzz1202hzz8275bhz2dh668h839h944h)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
X-FB-SS: 13,
Received: from mail12-db3 (localhost.localdomain [127.0.0.1]) by mail12-db3
	(MessageSwitch) id 1323876928528693_31457;
	Wed, 14 Dec 2011 15:35:28 +0000 (UTC)
Received: from DB3EHSMHS010.bigfish.com (unknown [10.3.81.251])	by
	mail12-db3.bigfish.com (Postfix) with ESMTP id 69225340092;
	Wed, 14 Dec 2011 15:35:28 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	DB3EHSMHS010.bigfish.com (10.3.87.110) with Microsoft SMTP Server id
	14.1.225.23; Wed, 14 Dec 2011 15:35:25 +0000
X-WSS-ID: 0LW79YV-02-A9V-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp02.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 278A8C8086;	Wed, 14 Dec 2011 09:35:18 -0600 (CST)
Received: from SAUSEXDAG01.amd.com (163.181.55.1) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Wed, 14 Dec 2011 09:35:32 -0600
Received: from storexhtp01.amd.com (172.24.4.3) by sausexdag01.amd.com
	(163.181.55.1) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Wed, 14 Dec 2011 09:35:20 -0600
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp01.amd.com
	(172.24.4.3) with Microsoft SMTP Server id 8.3.213.0; Wed, 14 Dec 2011
	10:35:16 -0500
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 9968349C662; Wed, 14 Dec 2011
	15:35:11 +0000 (GMT)
Received: from gran.amd.com (gran.osrc.amd.com [165.204.15.57])	by
	mail.osrc.amd.com (Postfix) with ESMTP id 85F56594888; Wed, 14 Dec 2011
	16:35:11 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 52dbaf1fb0e0364fad40f9be330f80e157c935e4
Message-ID: <52dbaf1fb0e0364fad40.1323876569@gran.amd.com>
In-Reply-To: <patchbomb.1323876561@gran.amd.com>
References: <patchbomb.1323876561@gran.amd.com>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Wed, 14 Dec 2011 16:29:29 +0100
From: Wei Wang <wei.wang2@amd.com>
To: <JBeulich@suse.com>, <keir@xen.org>
X-OriginatorOrg: amd.com
Cc: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 08 of 16] amd iommu: Add a hypercall for
	hvmloader
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Wei Wang <wei.wang2@amd.com>
# Date 1323875773 -3600
# Node ID 52dbaf1fb0e0364fad40f9be330f80e157c935e4
# Parent  ef5698887d044ad58293bee3549eaa20310c2b17
amd iommu: Add a hypercall for hvmloader.
IOMMU MMIO base address is dynamically allocated by firmware.
This patch allows hvmloader to notify hypervisor where the
iommu mmio pages are.

Signed-off-by: Wei Wang <wei.wang2@amd.com>

diff -r ef5698887d04 -r 52dbaf1fb0e0 xen/arch/x86/hvm/hvm.c
--- a/xen/arch/x86/hvm/hvm.c	Wed Dec 14 16:16:12 2011 +0100
+++ b/xen/arch/x86/hvm/hvm.c	Wed Dec 14 16:16:13 2011 +0100
@@ -65,6 +65,7 @@
 #include <public/memory.h>
 #include <asm/mem_event.h>
 #include <public/mem_event.h>
+#include <asm/hvm/svm/amd-iommu-proto.h>
 
 bool_t __read_mostly hvm_enabled;
 
@@ -3676,6 +3677,9 @@ long do_hvm_op(unsigned long op, XEN_GUE
             case HVM_PARAM_BUFIOREQ_EVTCHN:
                 rc = -EINVAL;
                 break;
+            case HVM_PARAM_IOMMU_BASE:
+                rc = guest_iommu_set_base(d, a.value);
+                break;
             }
 
             if ( rc == 0 ) 
diff -r ef5698887d04 -r 52dbaf1fb0e0 xen/include/public/hvm/params.h
--- a/xen/include/public/hvm/params.h	Wed Dec 14 16:16:12 2011 +0100
+++ b/xen/include/public/hvm/params.h	Wed Dec 14 16:16:13 2011 +0100
@@ -142,6 +142,10 @@
 /* Boolean: Enable nestedhvm (hvm only) */
 #define HVM_PARAM_NESTEDHVM    24
 
-#define HVM_NR_PARAMS          27
+#ifndef __ia64__
+#define HVM_PARAM_IOMMU_BASE   27
+#endif
+
+#define HVM_NR_PARAMS          28
 
 #endif /* __XEN_PUBLIC_HVM_PARAMS_H__ */


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 15:36:44 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 15:36:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Raqss-0003KI-8y; Wed, 14 Dec 2011 15:36:42 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Wang2@amd.com>) id 1Raqsq-0003Dv-2P
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 15:36:40 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1323876944!1513098!1
X-Originating-IP: [213.199.154.141]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7651 invoked from network); 14 Dec 2011 15:35:44 -0000
Received: from db3ehsobe003.messaging.microsoft.com (HELO
	DB3EHSOBE003.bigfish.com) (213.199.154.141)
	by server-16.tower-21.messagelabs.com with AES128-SHA encrypted SMTP;
	14 Dec 2011 15:35:44 -0000
Received: from mail12-db3-R.bigfish.com (10.3.81.244) by
	DB3EHSOBE003.bigfish.com (10.3.84.23) with Microsoft SMTP Server id
	14.1.225.23; Wed, 14 Dec 2011 15:35:46 +0000
Received: from mail12-db3 (localhost [127.0.0.1])	by mail12-db3-R.bigfish.com
	(Postfix) with ESMTP id 230776C04B8;
	Wed, 14 Dec 2011 15:35:47 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzzz1202hzz8275bhz2dh668h839h944h)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
X-FB-SS: 13,
Received: from mail12-db3 (localhost.localdomain [127.0.0.1]) by mail12-db3
	(MessageSwitch) id 1323876928528693_31457;
	Wed, 14 Dec 2011 15:35:28 +0000 (UTC)
Received: from DB3EHSMHS010.bigfish.com (unknown [10.3.81.251])	by
	mail12-db3.bigfish.com (Postfix) with ESMTP id 69225340092;
	Wed, 14 Dec 2011 15:35:28 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	DB3EHSMHS010.bigfish.com (10.3.87.110) with Microsoft SMTP Server id
	14.1.225.23; Wed, 14 Dec 2011 15:35:25 +0000
X-WSS-ID: 0LW79YV-02-A9V-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp02.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 278A8C8086;	Wed, 14 Dec 2011 09:35:18 -0600 (CST)
Received: from SAUSEXDAG01.amd.com (163.181.55.1) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Wed, 14 Dec 2011 09:35:32 -0600
Received: from storexhtp01.amd.com (172.24.4.3) by sausexdag01.amd.com
	(163.181.55.1) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Wed, 14 Dec 2011 09:35:20 -0600
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp01.amd.com
	(172.24.4.3) with Microsoft SMTP Server id 8.3.213.0; Wed, 14 Dec 2011
	10:35:16 -0500
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 9968349C662; Wed, 14 Dec 2011
	15:35:11 +0000 (GMT)
Received: from gran.amd.com (gran.osrc.amd.com [165.204.15.57])	by
	mail.osrc.amd.com (Postfix) with ESMTP id 85F56594888; Wed, 14 Dec 2011
	16:35:11 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 52dbaf1fb0e0364fad40f9be330f80e157c935e4
Message-ID: <52dbaf1fb0e0364fad40.1323876569@gran.amd.com>
In-Reply-To: <patchbomb.1323876561@gran.amd.com>
References: <patchbomb.1323876561@gran.amd.com>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Wed, 14 Dec 2011 16:29:29 +0100
From: Wei Wang <wei.wang2@amd.com>
To: <JBeulich@suse.com>, <keir@xen.org>
X-OriginatorOrg: amd.com
Cc: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 08 of 16] amd iommu: Add a hypercall for
	hvmloader
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Wei Wang <wei.wang2@amd.com>
# Date 1323875773 -3600
# Node ID 52dbaf1fb0e0364fad40f9be330f80e157c935e4
# Parent  ef5698887d044ad58293bee3549eaa20310c2b17
amd iommu: Add a hypercall for hvmloader.
IOMMU MMIO base address is dynamically allocated by firmware.
This patch allows hvmloader to notify hypervisor where the
iommu mmio pages are.

Signed-off-by: Wei Wang <wei.wang2@amd.com>

diff -r ef5698887d04 -r 52dbaf1fb0e0 xen/arch/x86/hvm/hvm.c
--- a/xen/arch/x86/hvm/hvm.c	Wed Dec 14 16:16:12 2011 +0100
+++ b/xen/arch/x86/hvm/hvm.c	Wed Dec 14 16:16:13 2011 +0100
@@ -65,6 +65,7 @@
 #include <public/memory.h>
 #include <asm/mem_event.h>
 #include <public/mem_event.h>
+#include <asm/hvm/svm/amd-iommu-proto.h>
 
 bool_t __read_mostly hvm_enabled;
 
@@ -3676,6 +3677,9 @@ long do_hvm_op(unsigned long op, XEN_GUE
             case HVM_PARAM_BUFIOREQ_EVTCHN:
                 rc = -EINVAL;
                 break;
+            case HVM_PARAM_IOMMU_BASE:
+                rc = guest_iommu_set_base(d, a.value);
+                break;
             }
 
             if ( rc == 0 ) 
diff -r ef5698887d04 -r 52dbaf1fb0e0 xen/include/public/hvm/params.h
--- a/xen/include/public/hvm/params.h	Wed Dec 14 16:16:12 2011 +0100
+++ b/xen/include/public/hvm/params.h	Wed Dec 14 16:16:13 2011 +0100
@@ -142,6 +142,10 @@
 /* Boolean: Enable nestedhvm (hvm only) */
 #define HVM_PARAM_NESTEDHVM    24
 
-#define HVM_NR_PARAMS          27
+#ifndef __ia64__
+#define HVM_PARAM_IOMMU_BASE   27
+#endif
+
+#define HVM_NR_PARAMS          28
 
 #endif /* __XEN_PUBLIC_HVM_PARAMS_H__ */


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 15:36:58 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 15:36:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Raqt5-0003W7-U7; Wed, 14 Dec 2011 15:36:55 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Wang2@amd.com>) id 1Raqt4-0003Qz-IM
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 15:36:55 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1323876957!7262277!1
X-Originating-IP: [213.199.154.208]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26788 invoked from network); 14 Dec 2011 15:35:58 -0000
Received: from am1ehsobe005.messaging.microsoft.com (HELO
	AM1EHSOBE005.bigfish.com) (213.199.154.208)
	by server-6.tower-182.messagelabs.com with AES128-SHA encrypted SMTP;
	14 Dec 2011 15:35:58 -0000
Received: from mail10-am1-R.bigfish.com (10.3.201.245) by
	AM1EHSOBE005.bigfish.com (10.3.204.25) with Microsoft SMTP Server id
	14.1.225.23; Wed, 14 Dec 2011 15:35:59 +0000
Received: from mail10-am1 (localhost [127.0.0.1])	by mail10-am1-R.bigfish.com
	(Postfix) with ESMTP id BBF791C03AB;
	Wed, 14 Dec 2011 15:36:00 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzc8kzz1202hzz8275bh5eeeKz2dh668h839h944h)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
X-FB-SS: 0,
Received: from mail10-am1 (localhost.localdomain [127.0.0.1]) by mail10-am1
	(MessageSwitch) id 132387692674002_1808; Wed, 14 Dec 2011 15:35:26 +0000
	(UTC)
Received: from AM1EHSMHS007.bigfish.com (unknown [10.3.201.246])	by
	mail10-am1.bigfish.com (Postfix) with ESMTP id 0C3E63E12B0;
	Wed, 14 Dec 2011 15:35:26 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	AM1EHSMHS007.bigfish.com (10.3.207.107) with Microsoft SMTP Server id
	14.1.225.23; Wed, 14 Dec 2011 15:35:22 +0000
X-WSS-ID: 0LW79YR-02-A9F-02
X-M-MSG: 
Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com
	[163.181.249.73])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp02.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 24E1FC808D;	Wed, 14 Dec 2011 09:35:15 -0600 (CST)
Received: from SAUSEXDAG01.amd.com (163.181.55.1) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Wed, 14 Dec 2011 09:35:29 -0600
Received: from storexhtp01.amd.com (172.24.4.3) by sausexdag01.amd.com
	(163.181.55.1) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Wed, 14 Dec 2011 09:35:17 -0600
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp01.amd.com
	(172.24.4.3) with Microsoft SMTP Server id 8.3.213.0; Wed, 14 Dec 2011
	10:35:12 -0500
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 35D9549C65D; Wed, 14 Dec 2011
	15:35:11 +0000 (GMT)
Received: from gran.amd.com (gran.osrc.amd.com [165.204.15.57])	by
	mail.osrc.amd.com (Postfix) with ESMTP id 21C84594884; Wed, 14 Dec 2011
	16:35:11 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: ea52a2b93dffe708084fdc6ee663bd5eee8c1031
Message-ID: <ea52a2b93dffe708084f.1323876564@gran.amd.com>
In-Reply-To: <patchbomb.1323876561@gran.amd.com>
References: <patchbomb.1323876561@gran.amd.com>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Wed, 14 Dec 2011 16:29:24 +0100
From: Wei Wang <wei.wang2@amd.com>
To: <JBeulich@suse.com>, <keir@xen.org>
X-OriginatorOrg: amd.com
Cc: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 03 of 16] amd iommu: Add iommu emulation for hvm
	guest
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Wei Wang <wei.wang2@amd.com>
# Date 1323863897 -3600
# Node ID ea52a2b93dffe708084fdc6ee663bd5eee8c1031
# Parent  b190e3362524a0e160e9892cd600447cee2a022e
amd iommu: Add iommu emulation for hvm guest
ATS device driver that support PASID [1] and PRI [2] capabilites needs to work with iommu driver
in OS. If we want passthru ATS device to hvm guests using unmodified OS, we have to expose iommu
functionality to HVM guest.

Signed-off-by: Wei Wang <wei.wang2@amd.com>


[1] http://www.pcisig.com/specifications/pciexpress/specifications/ECN-PASID-ATS-2011-03-31.pdf
[2] http://www.pcisig.com/members/downloads/specifications/iov/ats_r1.1_26Jan09.pdf

diff -r b190e3362524 -r ea52a2b93dff xen/drivers/passthrough/amd/Makefile
--- a/xen/drivers/passthrough/amd/Makefile	Wed Dec 14 12:51:22 2011 +0100
+++ b/xen/drivers/passthrough/amd/Makefile	Wed Dec 14 12:58:17 2011 +0100
@@ -5,3 +5,4 @@ obj-y += pci_amd_iommu.o
 obj-bin-y += iommu_acpi.init.o
 obj-y += iommu_intr.o
 obj-y += iommu_cmd.o
+obj-y += iommu_guest.o
diff -r b190e3362524 -r ea52a2b93dff xen/drivers/passthrough/amd/iommu_cmd.c
--- a/xen/drivers/passthrough/amd/iommu_cmd.c	Wed Dec 14 12:51:22 2011 +0100
+++ b/xen/drivers/passthrough/amd/iommu_cmd.c	Wed Dec 14 12:58:17 2011 +0100
@@ -398,3 +398,15 @@ void amd_iommu_flush_all_caches(struct a
     invalidate_iommu_all(iommu);
     flush_command_buffer(iommu);
 }
+
+void amd_iommu_send_guest_cmd(struct amd_iommu *iommu, u32 cmd[])
+{
+    unsigned long flags;
+
+    spin_lock_irqsave(&iommu->lock, flags);
+
+    send_iommu_command(iommu, cmd);
+    flush_command_buffer(iommu);
+
+    spin_unlock_irqrestore(&iommu->lock, flags);
+}
diff -r b190e3362524 -r ea52a2b93dff xen/drivers/passthrough/amd/iommu_guest.c
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/drivers/passthrough/amd/iommu_guest.c	Wed Dec 14 12:58:17 2011 +0100
@@ -0,0 +1,953 @@
+/*
+ * Copyright (C) 2011 Advanced Micro Devices, Inc.
+ * Author: Wei Wang <wei.wang2@amd.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307 USA
+ */
+
+#include <xen/sched.h>
+#include <asm/p2m.h>
+#include <asm/hvm/iommu.h>
+#include <asm/amd-iommu.h>
+#include <asm/hvm/svm/amd-iommu-proto.h>
+
+
+#define IOMMU_MMIO_SIZE                         0x8000
+#define IOMMU_MMIO_PAGE_NR                      0x8
+#define RING_BF_LENGTH_MASK                     0x0F000000
+#define RING_BF_LENGTH_SHIFT                    24
+
+#define PASMAX_9_bit                            0x8
+#define GUEST_CR3_1_LEVEL                       0x0
+#define GUEST_ADDRESS_SIZE_6_LEVEL              0x2
+#define HOST_ADDRESS_SIZE_6_LEVEL               0x2
+
+#define guest_iommu_set_status(iommu, bit) \
+        iommu_set_bit(&((iommu)->reg_status.lo), bit)
+
+#define guest_iommu_clear_status(iommu, bit) \
+        iommu_clear_bit(&((iommu)->reg_status.lo), bit)
+
+#define reg_to_u64(reg) (((uint64_t)reg.hi << 32) | reg.lo )
+#define u64_to_reg(reg, val) \
+    do  \
+    {   \
+        (reg)->lo = val & 0xFFFFFFFF; \
+        (reg)->hi = (val >> 32) & 0xFFFFFFFF; \
+    } while(0)
+
+static unsigned int machine_bdf(struct domain *d, uint16_t guest_bdf)
+{
+    return guest_bdf;
+}
+
+static uint16_t guest_bdf(struct domain *d, uint16_t machine_bdf)
+{
+    return machine_bdf;
+}
+
+static inline struct guest_iommu *domain_iommu(struct domain *d)
+{
+    return domain_hvm_iommu(d)->g_iommu;
+}
+
+static inline struct guest_iommu *vcpu_iommu(struct vcpu *v)
+{
+    return domain_hvm_iommu(v->domain)->g_iommu;
+}
+
+static void guest_iommu_enable(struct guest_iommu *iommu)
+{
+    iommu->enabled = 1;
+}
+
+static void guest_iommu_disable(struct guest_iommu *iommu)
+{
+    iommu->enabled = 0;
+}
+
+static uint64_t get_guest_cr3_from_dte(dev_entry_t *dte)
+{
+    uint64_t gcr3_1, gcr3_2, gcr3_3;
+
+    gcr3_1 = get_field_from_reg_u32(dte->data[1],
+                                    IOMMU_DEV_TABLE_GCR3_1_MASK,
+                                    IOMMU_DEV_TABLE_GCR3_1_SHIFT);
+    gcr3_2 = get_field_from_reg_u32(dte->data[2],
+                                    IOMMU_DEV_TABLE_GCR3_2_MASK,
+                                    IOMMU_DEV_TABLE_GCR3_2_SHIFT);
+    gcr3_3 = get_field_from_reg_u32(dte->data[3],
+                                    IOMMU_DEV_TABLE_GCR3_3_MASK,
+                                    IOMMU_DEV_TABLE_GCR3_3_SHIFT);
+
+    return ((gcr3_3 << 31) | (gcr3_2 << 15 ) | (gcr3_1 << 12)) >> PAGE_SHIFT;
+}
+
+static uint16_t get_domid_from_dte(dev_entry_t *dte)
+{
+    return get_field_from_reg_u32(dte->data[2], IOMMU_DEV_TABLE_DOMAIN_ID_MASK, 
+                                  IOMMU_DEV_TABLE_DOMAIN_ID_SHIFT);
+}
+
+static uint16_t get_glx_from_dte(dev_entry_t *dte)
+{
+    return get_field_from_reg_u32(dte->data[1], IOMMU_DEV_TABLE_GLX_MASK,
+                                  IOMMU_DEV_TABLE_GLX_SHIFT);
+}
+
+static uint16_t get_gv_from_dte(dev_entry_t *dte)
+{
+    return get_field_from_reg_u32(dte->data[1],IOMMU_DEV_TABLE_GV_MASK,
+                                  IOMMU_DEV_TABLE_GV_SHIFT);
+}
+
+static unsigned int host_domid(struct domain *d, uint64_t g_domid)
+{
+    /* Only support one PPR device in guest for now */
+    return d->domain_id;
+}
+
+static void guest_iommu_deliver_msi(struct domain *d)
+{
+    uint8_t vector, dest, dest_mode, delivery_mode, trig_mode;
+    struct guest_iommu *iommu = domain_iommu(d);
+
+    vector = iommu->msi.vector;
+    dest = iommu->msi.dest;
+    dest_mode = iommu->msi.dest_mode;
+    delivery_mode = iommu->msi.delivery_mode;
+    trig_mode = iommu->msi.trig_mode;
+
+    vmsi_deliver(d, vector, dest, dest_mode, delivery_mode, trig_mode);
+}
+
+static struct page_info* guest_iommu_get_page(struct list_head *pglist,
+                                              unsigned int entry_size,
+                                              unsigned int pos)
+{
+    int idx;
+    struct list_head *head;
+    struct guest_pages *gpage = NULL;
+
+    idx = (pos * entry_size) >> PAGE_SHIFT;
+    list_for_each( head, pglist )
+    {
+        gpage = list_entry(head, struct guest_pages, list);
+        if ( (--idx) < 0 )
+            break;
+    }
+    return (gpage) ? gpage->page : NULL;
+}
+
+static void guest_iommu_map_table(uint64_t base_raw, struct list_head *head,
+                                  struct domain *d, unsigned long npages)
+{
+    struct guest_pages * gpage;
+    uint64_t addr_lo, addr_hi, addr64;
+    unsigned long gfn;
+    p2m_type_t p2mt;
+
+    addr_lo = iommu_get_addr_lo_from_reg(base_raw & DMA_32BIT_MASK);
+    addr_hi = iommu_get_addr_hi_from_reg(base_raw >> 32);
+    addr64 = (addr_hi << 32) | (addr_lo << PAGE_SHIFT);
+
+    ASSERT ( addr64 != 0 && head != NULL );
+
+    gfn = addr64 >> PAGE_SHIFT;
+
+    /*
+     * map guest table pages into Xen 
+     * Assuming guest table contiguous in guest space 
+     */
+    for ( int i = 0; i < npages; i++ )
+    {
+        gpage = (struct guest_pages *) xzalloc(struct guest_pages);
+        if ( unlikely(gpage == NULL) )
+        {
+            AMD_IOMMU_DEBUG("Cannot allocate guest_pages struct\n");
+            return;
+        }
+
+        gpage->page = mfn_to_page(mfn_x(get_gfn(d, gfn, &p2mt)));
+        list_add_tail(&gpage->list, head);
+        put_gfn(d,gfn);
+        gfn ++;
+    }
+}
+
+static void guest_iommu_enable_dev_table(struct guest_iommu *iommu)
+{
+    unsigned int npages;
+    uint32_t length_raw = get_field_from_reg_u32(iommu->dev_table.reg_base.lo,
+                                                 IOMMU_DEV_TABLE_SIZE_MASK,
+                                                 IOMMU_DEV_TABLE_SIZE_SHIFT);
+
+    iommu->dev_table.size = (length_raw + 1) * PAGE_SIZE;
+    npages = PAGE_ALIGN(iommu->dev_table.size) >> PAGE_SHIFT;
+
+    guest_iommu_map_table(reg_to_u64(iommu->dev_table.reg_base),
+                          &iommu->dev_table.page_list, iommu->domain, npages);
+}
+
+static void guest_iommu_enable_ring_buffer(struct guest_iommu *iommu,
+                                          struct guest_buffer *buffer,
+                                          uint32_t entry_size)
+{
+    unsigned npages;
+    uint32_t length_raw = get_field_from_reg_u32(buffer->reg_base.hi,
+                                                 RING_BF_LENGTH_MASK,
+                                                 RING_BF_LENGTH_SHIFT);
+    buffer->entries = 1 << length_raw;
+    npages = PAGE_ALIGN(buffer->entries * entry_size) >> PAGE_SHIFT;
+
+    guest_iommu_map_table(reg_to_u64(buffer->reg_base),
+                          &buffer->page_list, iommu->domain, npages);
+}
+
+void guest_iommu_add_ppr_log(struct domain *d, u32 entry[])
+{
+    uint16_t gdev_id;
+    ppr_entry_t *log, *log_base;
+    unsigned int tail;
+    struct guest_iommu *iommu;
+    struct page_info *page = NULL;
+
+    iommu = domain_iommu(d);
+    tail = iommu_get_rb_pointer(iommu->ppr_log.reg_tail.lo);
+
+    page = guest_iommu_get_page(&iommu->ppr_log.page_list, 
+                                sizeof(ppr_entry_t), tail);
+    if ( unlikely(page == NULL) )
+    {
+        AMD_IOMMU_DEBUG("Error: Cannot access guest event log pages\n");
+        return;
+    }
+
+    log_base = __map_domain_page(page);
+    log = log_base + tail % (PAGE_SIZE / sizeof(ppr_entry_t));
+
+    /* Convert physical device id back into virtual device id */
+    gdev_id = guest_bdf(d, iommu_get_devid_from_cmd(entry[0]));
+    iommu_set_devid_to_cmd(&entry[0], gdev_id);
+
+    memcpy(log, entry, sizeof(ppr_entry_t));
+
+    /* Now shift ppr log tail pointer */
+    tail++;
+    iommu_set_rb_pointer(&iommu->ppr_log.reg_tail.lo, tail);
+    unmap_domain_page(log_base);
+
+    guest_iommu_deliver_msi(d);
+}
+
+void guest_iommu_add_event_log(struct domain *d, u32 entry[])
+{
+    uint16_t dev_id;
+    struct event_entry *log, *log_base;
+    unsigned int tail;
+    struct guest_iommu *iommu;
+    struct page_info *page = NULL;
+
+    iommu = domain_iommu(d);
+    tail = iommu_get_rb_pointer(iommu->event_log.reg_tail.lo);
+
+    page = guest_iommu_get_page(&iommu->event_log.page_list, 
+                                sizeof(event_entry_t), tail);
+    if ( unlikely(page == NULL) )
+    {
+        AMD_IOMMU_DEBUG("Error: Cannot access guest event log pages\n");
+        return;
+    }
+
+    log_base = __map_domain_page(page);
+    log = log_base + tail % (PAGE_SIZE / sizeof(event_entry_t));
+
+    /* re-write physical device id into virtual device id */
+    dev_id = guest_bdf(d, iommu_get_devid_from_cmd(entry[0]));
+    iommu_set_devid_to_cmd(&entry[0], dev_id);
+    memcpy(log, entry, sizeof(event_entry_t));
+
+    /* Now shift event log tail pointer */
+    tail++;
+    iommu_set_rb_pointer(&iommu->event_log.reg_tail.lo, tail);
+    unmap_domain_page(log_base);
+
+    guest_iommu_deliver_msi(d);
+}
+
+static int do_complete_ppr_request(struct domain *d, cmd_entry_t *cmd)
+{
+    uint16_t dev_id;
+    struct amd_iommu *iommu;
+
+    dev_id = machine_bdf(d, iommu_get_devid_from_cmd(cmd->data[0]));
+    iommu = find_iommu_for_device(0, dev_id);
+
+    if ( !iommu )
+    {
+        AMD_IOMMU_DEBUG("%s Fail to find iommu for bdf %x\n", 
+                        __func__, dev_id);
+        return -ENODEV;
+    }
+
+    /* replace virtual device id into physical */
+    iommu_set_devid_to_cmd(&cmd->data[0], dev_id);
+    amd_iommu_send_guest_cmd(iommu, cmd->data);
+
+    return 0;
+}
+
+static int do_invalidate_pages(struct domain *d, cmd_entry_t *cmd)
+{
+    uint16_t gdom_id, hdom_id;
+    struct amd_iommu *iommu = NULL;
+
+    gdom_id = get_field_from_reg_u32(cmd->data[1],
+                                    IOMMU_INV_IOMMU_PAGES_DOMAIN_ID_MASK,
+                                    IOMMU_INV_IOMMU_PAGES_DOMAIN_ID_SHIFT);
+
+    hdom_id = host_domid(d, gdom_id);
+    set_field_in_reg_u32(hdom_id, cmd->data[1],
+                         IOMMU_INV_IOMMU_PAGES_DOMAIN_ID_MASK,
+                         IOMMU_INV_IOMMU_PAGES_DOMAIN_ID_SHIFT, &cmd->data[1]);
+
+    for_each_amd_iommu ( iommu )
+        amd_iommu_send_guest_cmd(iommu, cmd->data);
+
+    return 0;
+}
+
+static int do_invalidate_all(struct domain *d, cmd_entry_t *cmd)
+{
+    struct amd_iommu *iommu = NULL;
+
+    for_each_amd_iommu ( iommu )
+        amd_iommu_flush_all_pages(d);
+
+    return 0;
+}
+
+static int do_invalidate_iotlb_pages(struct domain *d, cmd_entry_t *cmd)
+{
+    struct amd_iommu *iommu;
+    uint16_t dev_id;
+
+    dev_id = machine_bdf(d, iommu_get_devid_from_cmd(cmd->data[0]));
+
+    iommu = find_iommu_for_device(0, dev_id);
+    if ( !iommu )
+    {
+        AMD_IOMMU_DEBUG("%s Fail to find iommu for bdf %x\n", 
+                         __func__, dev_id);
+        return -ENODEV;
+    }
+
+    iommu_set_devid_to_cmd(&cmd->data[0], dev_id);
+    amd_iommu_send_guest_cmd(iommu, cmd->data);
+
+    return 0;
+}
+
+static int do_completion_wait(struct domain *d, cmd_entry_t *cmd)
+{
+    bool_t com_wait_int_en, com_wait_int, i, s;
+    struct guest_iommu *iommu;
+    unsigned long gfn;
+    p2m_type_t p2mt;
+
+    iommu = domain_iommu(d);
+
+    i = iommu_get_bit(cmd->data[0], IOMMU_COMP_WAIT_I_FLAG_SHIFT);
+    s = iommu_get_bit(cmd->data[0], IOMMU_COMP_WAIT_S_FLAG_SHIFT);
+
+    if ( i )
+        guest_iommu_set_status(iommu, IOMMU_STATUS_COMP_WAIT_INT_SHIFT);
+
+    if ( s )
+    {
+        uint64_t gaddr_lo, gaddr_hi, gaddr_64, data;
+        void *vaddr;
+
+        data = (uint64_t) cmd->data[3] << 32 | cmd->data[2];
+        gaddr_lo = get_field_from_reg_u32(cmd->data[0],
+                                          IOMMU_COMP_WAIT_ADDR_LOW_MASK,
+                                          IOMMU_COMP_WAIT_ADDR_LOW_SHIFT);
+        gaddr_hi = get_field_from_reg_u32(cmd->data[1],
+                                          IOMMU_COMP_WAIT_ADDR_HIGH_MASK,
+                                          IOMMU_COMP_WAIT_ADDR_HIGH_SHIFT);
+
+        gaddr_64 = (gaddr_hi << 32) | (gaddr_lo << 3);
+
+        gfn = gaddr_64 >> PAGE_SHIFT;
+        vaddr = map_domain_page(mfn_x(get_gfn(d, gfn ,&p2mt)));
+        put_gfn(d, gfn);
+
+        write_u64_atomic((uint64_t*)(vaddr + (gaddr_64 & (PAGE_SIZE-1))), data);
+        unmap_domain_page(vaddr);
+    }
+
+    com_wait_int_en = iommu_get_bit(iommu->reg_ctrl.lo,
+                                    IOMMU_CONTROL_COMP_WAIT_INT_SHIFT);
+    com_wait_int = iommu_get_bit(iommu->reg_status.lo,
+                                 IOMMU_STATUS_COMP_WAIT_INT_SHIFT);
+
+    if ( com_wait_int_en && com_wait_int )
+        guest_iommu_deliver_msi(d);
+
+    return 0;
+}
+
+static int do_invalidate_dte(struct domain *d, cmd_entry_t *cmd)
+{
+    uint16_t gbdf, mbdf, req_id, gdom_id, hdom_id;
+    dev_entry_t *gdte, *mdte, *dte_base;
+    struct amd_iommu *iommu = NULL;
+    struct page_info *dte_page = NULL;
+    struct guest_iommu *g_iommu;
+    uint64_t gcr3_gfn, gcr3_mfn;
+    uint8_t glx, gv;
+    unsigned long flags;
+    p2m_type_t p2mt;
+
+    g_iommu = domain_iommu(d);
+    gbdf = iommu_get_devid_from_cmd(cmd->data[0]);
+    mbdf = machine_bdf(d, gbdf);
+
+    /* Guest can only update DTEs for its passthru devices */
+    if ( mbdf == 0 || gbdf == 0 )
+        return 0;
+
+    /* Sometimes guest invalidates devices from non-exists dtes */
+    if ( (gbdf * sizeof(dev_entry_t)) > g_iommu->dev_table.size )
+        return 0;
+
+    dte_page = guest_iommu_get_page(&g_iommu->dev_table.page_list,
+                                    sizeof(dev_entry_t), gbdf);
+    if ( unlikely(dte_page == NULL) )
+    {
+        AMD_IOMMU_DEBUG("Error: Cannot access guest device table\n");
+        return -ENOMEM ;
+    }
+
+    dte_base = __map_domain_page(dte_page);
+
+    gdte = dte_base + gbdf % (PAGE_SIZE / sizeof(dev_entry_t));
+
+    gdom_id  = get_domid_from_dte(gdte);
+    gcr3_gfn = get_guest_cr3_from_dte(gdte);
+
+    /* Do not update host dte before gcr3 has been set */
+    if ( gcr3_gfn == 0 )
+        return 0;
+
+    gcr3_mfn = mfn_x(get_gfn(d, gcr3_gfn, &p2mt));
+    put_gfn(d, gcr3_gfn);
+
+    ASSERT(mfn_valid(gcr3_mfn));
+
+    /* Read guest dte information */
+    iommu = find_iommu_for_device(0, mbdf);
+    if ( !iommu )
+    {
+        AMD_IOMMU_DEBUG("%s Fail to find iommu!\n",__func__);
+        return -ENODEV;
+    }
+
+    glx = get_glx_from_dte(gdte);
+    gv = get_gv_from_dte(gdte);
+
+    unmap_domain_page(dte_base);
+
+    /* Setup host device entry */
+    hdom_id = host_domid(d, gdom_id);
+    req_id = get_dma_requestor_id(iommu->seg, mbdf);
+    mdte = iommu->dev_table.buffer + (req_id * sizeof(dev_entry_t));
+
+    spin_lock_irqsave(&iommu->lock, flags);
+    iommu_dte_set_guest_cr3((u32*)mdte, hdom_id, 
+                            gcr3_mfn << PAGE_SHIFT, gv, glx);
+
+    amd_iommu_flush_device(iommu, req_id);
+    spin_unlock_irqrestore(&iommu->lock, flags);
+
+    return 0;
+}
+
+static void guest_iommu_process_command(unsigned long _d)
+{
+    unsigned int opcode, tail, head, entries_per_page;
+    cmd_entry_t *cmd, *cmd_base;
+    struct domain *d;
+    struct guest_iommu *iommu;
+    struct page_info *cmd_page = NULL;
+
+    d = (struct domain*) _d;
+    iommu = domain_iommu(d);
+
+    if ( !iommu->enabled )
+        return;
+
+    head = iommu_get_rb_pointer(iommu->cmd_buffer.reg_head.lo);
+    tail = iommu_get_rb_pointer(iommu->cmd_buffer.reg_tail.lo);
+
+    /* Tail pointer is rolled over by guest driver, value outside
+     * cmd_buffer_entries cause iommu disabled 
+     */
+    entries_per_page = PAGE_SIZE / sizeof(cmd_entry_t);
+
+    while ( head != tail )
+    {
+        int ret = 0;
+        cmd_page = guest_iommu_get_page(&iommu->cmd_buffer.page_list, 
+                                        sizeof(cmd_entry_t), head);
+        if ( unlikely(cmd_page == NULL) )
+        {
+            AMD_IOMMU_DEBUG("Error: cannot access guest cmd buffer head = %d\n",
+                            head);
+            return;
+        }
+
+        cmd_base = __map_domain_page(cmd_page);
+        cmd = cmd_base + head % entries_per_page;
+
+        opcode = get_field_from_reg_u32(cmd->data[1], 
+                                        IOMMU_CMD_OPCODE_MASK,
+                                        IOMMU_CMD_OPCODE_SHIFT);
+        switch ( opcode )
+        {
+            case IOMMU_CMD_COMPLETION_WAIT:
+                ret = do_completion_wait(d, cmd);
+                break;
+            case IOMMU_CMD_INVALIDATE_DEVTAB_ENTRY:
+                ret = do_invalidate_dte(d, cmd);
+                break;
+            case IOMMU_CMD_INVALIDATE_IOMMU_PAGES:
+                ret = do_invalidate_pages(d, cmd);
+                break;
+            case IOMMU_CMD_INVALIDATE_IOTLB_PAGES:
+                ret = do_invalidate_iotlb_pages(d, cmd);
+                break;
+            case IOMMU_CMD_INVALIDATE_INT_TABLE:
+                break;
+            case IOMMU_CMD_COMPLETE_PPR_REQUEST:
+                ret = do_complete_ppr_request(d, cmd);
+                break;
+            case IOMMU_CMD_INVALIDATE_IOMMU_ALL:
+                ret = do_invalidate_all(d, cmd);
+                break;
+            default:
+                AMD_IOMMU_DEBUG("CMD: Unknown command cmd_type = %x "
+                                "head = %d\n", opcode, head);
+                break;
+        }
+
+        unmap_domain_page(cmd_base);
+        if ( (++head) >= iommu->cmd_buffer.entries )
+            head = 0;
+        if ( ret )
+            guest_iommu_disable(iommu);
+    }
+
+    /* Now shift cmd buffer head pointer */ 
+    iommu_set_rb_pointer(&iommu->cmd_buffer.reg_head.lo, head);
+    return;
+}
+
+static int guest_iommu_write_ctrl(struct guest_iommu *iommu, uint64_t newctrl)
+{
+    bool_t cmd_en, event_en, iommu_en, ppr_en, ppr_log_en;
+    bool_t cmd_en_old, event_en_old, iommu_en_old;
+    bool_t cmd_run;
+
+    iommu_en = iommu_get_bit(newctrl, 
+                             IOMMU_CONTROL_TRANSLATION_ENABLE_SHIFT);
+    iommu_en_old = iommu_get_bit(iommu->reg_ctrl.lo,
+                                 IOMMU_CONTROL_TRANSLATION_ENABLE_SHIFT);
+
+    cmd_en = iommu_get_bit(newctrl, 
+                           IOMMU_CONTROL_COMMAND_BUFFER_ENABLE_SHIFT);
+    cmd_en_old = iommu_get_bit(iommu->reg_ctrl.lo,
+                               IOMMU_CONTROL_COMMAND_BUFFER_ENABLE_SHIFT);
+    cmd_run = iommu_get_bit(iommu->reg_status.lo, 
+
+                            IOMMU_STATUS_CMD_BUFFER_RUN_SHIFT);
+    event_en = iommu_get_bit(newctrl,
+                             IOMMU_CONTROL_EVENT_LOG_ENABLE_SHIFT);
+    event_en_old = iommu_get_bit(iommu->reg_ctrl.lo,
+                                 IOMMU_CONTROL_EVENT_LOG_ENABLE_SHIFT);
+
+    ppr_en = iommu_get_bit(newctrl, 
+                           IOMMU_CONTROL_PPR_ENABLE_SHIFT);
+    ppr_log_en = iommu_get_bit(newctrl,
+                               IOMMU_CONTROL_PPR_LOG_ENABLE_SHIFT);
+
+    if ( iommu_en )
+    {
+        guest_iommu_enable(iommu);
+        guest_iommu_enable_dev_table(iommu);
+    }
+
+    if ( iommu_en && cmd_en )
+    {
+        guest_iommu_enable_ring_buffer(iommu, &iommu->cmd_buffer,
+                                       sizeof(cmd_entry_t));
+        /* Enable iommu command processing */
+        tasklet_schedule(&iommu->cmd_buffer_tasklet);
+    }
+
+    if ( iommu_en && event_en )
+    {
+        guest_iommu_enable_ring_buffer(iommu, &iommu->event_log,
+                                       sizeof(event_entry_t));
+        guest_iommu_set_status(iommu, IOMMU_STATUS_EVENT_LOG_RUN_SHIFT);
+        guest_iommu_clear_status(iommu, IOMMU_STATUS_EVENT_OVERFLOW_SHIFT);
+    }
+
+    if ( iommu_en && ppr_en && ppr_log_en )
+    {
+        guest_iommu_enable_ring_buffer(iommu, &iommu->ppr_log,
+                                       sizeof(ppr_entry_t));
+        guest_iommu_set_status(iommu, IOMMU_STATUS_PPR_LOG_RUN_SHIFT);
+        guest_iommu_clear_status(iommu, IOMMU_STATUS_PPR_LOG_OVERFLOW_SHIFT);
+    }
+
+    if ( iommu_en && cmd_en_old && !cmd_en )
+    {
+        /* Disable iommu command processing */
+        tasklet_kill(&iommu->cmd_buffer_tasklet);
+    }
+
+    if ( event_en_old && !event_en )
+    {
+        guest_iommu_clear_status(iommu, IOMMU_STATUS_EVENT_LOG_RUN_SHIFT);
+    }
+
+    if ( !iommu_en && iommu_en_old )
+    {
+        guest_iommu_disable(iommu);
+    }
+
+    iommu->reg_ctrl.lo = newctrl & 0xffffffff;
+    iommu->reg_ctrl.hi = newctrl >> 32;
+    return 0;
+}
+
+static uint64_t iommu_mmio_read64(struct guest_iommu *iommu, 
+                                  unsigned long offset)
+{
+    uint64_t val;
+
+    switch ( offset )
+    {
+        case IOMMU_DEV_TABLE_BASE_LOW_OFFSET:
+            val = reg_to_u64(iommu->dev_table.reg_base);
+            break;
+        case IOMMU_CMD_BUFFER_BASE_LOW_OFFSET:
+            val = reg_to_u64(iommu->cmd_buffer.reg_base);
+            break;
+        case IOMMU_EVENT_LOG_BASE_LOW_OFFSET:
+            val = reg_to_u64(iommu->event_log.reg_base);
+            break;
+        case IOMMU_PPR_LOG_BASE_LOW_OFFSET:
+            val = reg_to_u64(iommu->ppr_log.reg_base);
+            break;
+        case IOMMU_CMD_BUFFER_HEAD_OFFSET:
+            val = reg_to_u64(iommu->cmd_buffer.reg_head);
+            break;
+        case IOMMU_CMD_BUFFER_TAIL_OFFSET:
+            val = reg_to_u64(iommu->cmd_buffer.reg_tail);
+            break;
+        case IOMMU_EVENT_LOG_HEAD_OFFSET:;
+            val = reg_to_u64(iommu->event_log.reg_head);
+            break;
+        case IOMMU_EVENT_LOG_TAIL_OFFSET:
+            val = reg_to_u64(iommu->event_log.reg_tail);
+            break;
+        case IOMMU_PPR_LOG_HEAD_OFFSET:
+            val = reg_to_u64(iommu->ppr_log.reg_head);
+            break;
+        case IOMMU_PPR_LOG_TAIL_OFFSET:
+            val = reg_to_u64(iommu->ppr_log.reg_tail);
+            break;
+        case IOMMU_CONTROL_MMIO_OFFSET:
+            val = reg_to_u64(iommu->reg_ctrl);
+            break;
+        case IOMMU_STATUS_MMIO_OFFSET:
+            val = reg_to_u64(iommu->reg_status);
+            break;
+        case IOMMU_EXT_FEATURE_MMIO_OFFSET:
+            val = reg_to_u64(iommu->reg_ext_feature);
+            break;
+
+        default:
+            AMD_IOMMU_DEBUG("Guest reads unknown mmio offset = %lx\n", 
+                             offset);
+            val = 0;
+            break;
+    }
+
+    return val;
+}
+
+static int guest_iommu_mmio_read(struct vcpu *v, unsigned long addr,
+                                 unsigned long len, unsigned long *pval)
+{
+    struct guest_iommu *iommu = vcpu_iommu(v);
+    unsigned long offset;
+    uint64_t val;
+    uint32_t mmio, shift;
+    uint64_t mask = 0;
+
+    offset = addr - iommu->mmio_base;
+
+    if ( unlikely((offset & (len - 1 )) || (len > 8)) )
+    {
+        AMD_IOMMU_DEBUG("iommu mmio write access is not aligned." 
+                        "offset = %lx, len = %lx \n", offset, len);
+        return X86EMUL_UNHANDLEABLE;
+    }
+
+    mask = (len == 8) ? (~0ULL) : (1ULL << (len * 8)) - 1;
+    shift = (offset & 7u) * 8;
+
+    /* mmio access is always aligned on 8-byte boundary */
+    mmio = offset & (~7u);
+
+    spin_lock(&iommu->lock);
+    val = iommu_mmio_read64(iommu, mmio);
+    spin_unlock(&iommu->lock);
+
+    *pval = (val >> shift ) & mask;
+
+    return X86EMUL_OKAY;
+}
+
+static void guest_iommu_mmio_write64(struct guest_iommu *iommu, 
+                                    unsigned long offset, uint64_t val)
+{
+    switch ( offset )
+    {
+        case IOMMU_DEV_TABLE_BASE_LOW_OFFSET:
+            u64_to_reg(&iommu->dev_table.reg_base, val);
+            break;
+        case IOMMU_CMD_BUFFER_BASE_LOW_OFFSET: 
+            u64_to_reg(&iommu->cmd_buffer.reg_base, val);
+            break;
+        case IOMMU_EVENT_LOG_BASE_LOW_OFFSET:
+            u64_to_reg(&iommu->event_log.reg_base, val);
+        case IOMMU_PPR_LOG_BASE_LOW_OFFSET:
+            u64_to_reg(&iommu->ppr_log.reg_base, val);
+            break;
+        case IOMMU_CONTROL_MMIO_OFFSET:
+            guest_iommu_write_ctrl(iommu, val);
+            break;
+        case IOMMU_CMD_BUFFER_HEAD_OFFSET:
+            u64_to_reg(&iommu->cmd_buffer.reg_head, val);
+            break;
+        case IOMMU_CMD_BUFFER_TAIL_OFFSET:
+            u64_to_reg(&iommu->cmd_buffer.reg_tail, val);
+            tasklet_schedule(&iommu->cmd_buffer_tasklet);
+            break;
+        case IOMMU_EVENT_LOG_HEAD_OFFSET:
+            u64_to_reg(&iommu->event_log.reg_head, val);
+            break;
+        case IOMMU_EVENT_LOG_TAIL_OFFSET:
+            u64_to_reg(&iommu->event_log.reg_tail, val);
+            break;
+        case IOMMU_PPR_LOG_HEAD_OFFSET:
+            u64_to_reg(&iommu->ppr_log.reg_head, val);
+            break;
+        case IOMMU_PPR_LOG_TAIL_OFFSET:
+            u64_to_reg(&iommu->ppr_log.reg_tail, val);
+            break;
+        case IOMMU_STATUS_MMIO_OFFSET:
+            u64_to_reg(&iommu->reg_status, val);
+            break;
+
+        default:
+            AMD_IOMMU_DEBUG("guest writes unknown mmio offset = %lx, "
+                            "val = %lx\n", offset, val);
+            break;
+    }
+}
+
+static int guest_iommu_mmio_write(struct vcpu *v, unsigned long addr,
+                                  unsigned long len, unsigned long val)
+{
+    struct guest_iommu *iommu = vcpu_iommu(v);
+    unsigned long offset;
+    uint64_t reg_old, mmio;
+    uint32_t shift;
+    uint64_t mask = 0;
+
+    offset = addr - iommu->mmio_base;
+
+    if ( unlikely((offset & (len - 1 )) || (len > 8)) )
+    {
+        AMD_IOMMU_DEBUG("iommu mmio write access is not aligned." 
+                        "offset = %lx, len = %lx \n", offset, len);
+        return X86EMUL_UNHANDLEABLE;
+    }
+
+    mask = (len == 8) ? (~0ULL): (1ULL << (len * 8)) - 1;
+    shift = (offset & 7u) * 8;
+
+    /* mmio access is always aligned on 8-byte boundary */
+    mmio = offset & (~7u);
+
+    spin_lock(&iommu->lock);
+
+    reg_old = iommu_mmio_read64(iommu, mmio);
+    reg_old &= ~( mask << shift );
+    val = reg_old | ((val & mask) << shift );
+    guest_iommu_mmio_write64(iommu, mmio, val);
+
+    spin_unlock(&iommu->lock);
+
+    return X86EMUL_OKAY;
+}
+
+int guest_iommu_set_base(struct domain *d, uint64_t base)
+{
+    p2m_type_t t;
+    struct guest_iommu *iommu = domain_iommu(d);
+
+    iommu->mmio_base = base;
+    base >>= PAGE_SHIFT;
+
+    for ( int i = 0; i < IOMMU_MMIO_PAGE_NR; i++ )
+    {
+        unsigned long gfn = base + i;
+
+        get_gfn_query(d, gfn, &t);
+        p2m_change_type(d, gfn, t, p2m_mmio_dm);
+        put_gfn(d, gfn);
+    }
+
+    return 0;
+}
+
+/* Initialize mmio read only bits */
+static void guest_iommu_reg_init(struct guest_iommu *iommu)
+{
+    uint32_t lower, upper;
+
+    lower = upper = 0;
+    /* Support prefetch */
+    iommu_set_bit(&lower,IOMMU_EXT_FEATURE_PREFSUP_SHIFT);
+    /* Support PPR log */
+    iommu_set_bit(&lower,IOMMU_EXT_FEATURE_PPRSUP_SHIFT);
+    /* Support guest translation */
+    iommu_set_bit(&lower,IOMMU_EXT_FEATURE_GTSUP_SHIFT);
+    /* Support invalidate all command */
+    iommu_set_bit(&lower,IOMMU_EXT_FEATURE_IASUP_SHIFT);
+
+    /* Host translation size has 6 levels */
+    set_field_in_reg_u32(HOST_ADDRESS_SIZE_6_LEVEL, lower,
+                         IOMMU_EXT_FEATURE_HATS_MASK,
+                         IOMMU_EXT_FEATURE_HATS_SHIFT,
+                         &lower);
+    /* Guest translation size has 6 levels */
+    set_field_in_reg_u32(GUEST_ADDRESS_SIZE_6_LEVEL, lower,
+                         IOMMU_EXT_FEATURE_GATS_MASK,
+                         IOMMU_EXT_FEATURE_GATS_SHIFT,
+                         &lower);
+    /* Single level gCR3 */
+    set_field_in_reg_u32(GUEST_CR3_1_LEVEL, lower, 
+                         IOMMU_EXT_FEATURE_GLXSUP_MASK,
+                         IOMMU_EXT_FEATURE_GLXSUP_SHIFT, &lower);
+    /* 9 bit PASID */
+    set_field_in_reg_u32(PASMAX_9_bit, upper, 
+                         IOMMU_EXT_FEATURE_PASMAX_MASK,
+                         IOMMU_EXT_FEATURE_PASMAX_SHIFT, &upper);
+
+    iommu->reg_ext_feature.lo = lower;
+    iommu->reg_ext_feature.hi = upper;
+}
+
+/* Domain specific initialization */
+int guest_iommu_init(struct domain* d)
+{
+    struct guest_iommu *iommu;
+    struct hvm_iommu *hd  = domain_hvm_iommu(d);
+
+    if ( !is_hvm_domain(d) )
+        return 0;
+
+    iommu = xzalloc(struct guest_iommu);
+    if ( !iommu )
+    {
+        AMD_IOMMU_DEBUG("Error allocating guest iommu structure.\n");
+        return 1;
+    }
+
+    guest_iommu_reg_init(iommu);
+    iommu->domain = d;
+    hd->g_iommu = iommu;
+
+    tasklet_init(&iommu->cmd_buffer_tasklet,
+                 guest_iommu_process_command, (unsigned long)d);
+
+    spin_lock_init(&iommu->lock);
+
+    INIT_LIST_HEAD(&iommu->dev_table.page_list);
+    INIT_LIST_HEAD(&iommu->cmd_buffer.page_list);
+    INIT_LIST_HEAD(&iommu->event_log.page_list);
+    INIT_LIST_HEAD(&iommu->ppr_log.page_list);
+
+    return 0;
+}
+
+static void guest_iommu_deallocate(struct list_head *page_list)
+{
+    struct guest_pages *cur, *next; 
+
+    list_for_each_entry_safe(cur, next, page_list, list)
+    {
+        list_del(&cur->list);
+        xfree(cur);
+    }
+}
+
+void guest_iommu_destroy(struct domain *d)
+{
+    struct guest_iommu *iommu;
+
+    if ( !is_hvm_domain(d) )
+        return;
+
+    iommu = domain_iommu(d);
+
+    guest_iommu_deallocate(&iommu->dev_table.page_list);
+    guest_iommu_deallocate(&iommu->cmd_buffer.page_list);
+    guest_iommu_deallocate(&iommu->event_log.page_list);
+    guest_iommu_deallocate(&iommu->ppr_log.page_list);
+
+    tasklet_kill(&iommu->cmd_buffer_tasklet);
+}
+
+static int guest_iommu_mmio_range(struct vcpu *v, unsigned long addr)
+{
+    struct guest_iommu *iommu = vcpu_iommu(v);
+
+    return ( addr >= iommu->mmio_base && 
+             addr < (iommu->mmio_base + IOMMU_MMIO_SIZE) );
+}
+
+const struct hvm_mmio_handler iommu_mmio_handler = {
+    .check_handler = guest_iommu_mmio_range,
+    .read_handler = guest_iommu_mmio_read,
+    .write_handler = guest_iommu_mmio_write
+};
diff -r b190e3362524 -r ea52a2b93dff xen/drivers/passthrough/amd/iommu_map.c
--- a/xen/drivers/passthrough/amd/iommu_map.c	Wed Dec 14 12:51:22 2011 +0100
+++ b/xen/drivers/passthrough/amd/iommu_map.c	Wed Dec 14 12:58:17 2011 +0100
@@ -234,6 +234,53 @@ void __init iommu_dte_add_device_entry(u
     dte[3] = entry;
 }
 
+void iommu_dte_set_guest_cr3(u32 *dte, u16 dom_id, u64 gcr3, 
+                             int gv, unsigned int glx)
+{
+    u32 entry, gcr3_1, gcr3_2, gcr3_3;
+
+    gcr3_3 = gcr3 >> 31;
+    gcr3_2 = (gcr3 >> 15) & 0xFFFF;
+    gcr3_1 = (gcr3 >> PAGE_SHIFT) & 0x7;
+
+    /* I bit must be set when gcr3 is enabled */
+    entry = dte[3];
+    set_field_in_reg_u32(IOMMU_CONTROL_ENABLED, entry,
+                         IOMMU_DEV_TABLE_IOTLB_SUPPORT_MASK,
+                         IOMMU_DEV_TABLE_IOTLB_SUPPORT_SHIFT, &entry);
+    /* update gcr3 */
+    set_field_in_reg_u32(gcr3_3, entry,
+                         IOMMU_DEV_TABLE_GCR3_3_MASK,
+                         IOMMU_DEV_TABLE_GCR3_3_SHIFT, &entry);
+    dte[3] = entry;
+
+    set_field_in_reg_u32(dom_id, entry,
+                         IOMMU_DEV_TABLE_DOMAIN_ID_MASK,
+                         IOMMU_DEV_TABLE_DOMAIN_ID_SHIFT, &entry);
+    /* update gcr3 */
+    entry = dte[2];
+    set_field_in_reg_u32(gcr3_2, entry,
+                         IOMMU_DEV_TABLE_GCR3_2_MASK,
+                         IOMMU_DEV_TABLE_GCR3_2_SHIFT, &entry);
+    dte[2] = entry;
+
+    entry = dte[1];
+    /* Enable GV bit */
+    set_field_in_reg_u32(!!gv, entry,
+                         IOMMU_DEV_TABLE_GV_MASK,
+                         IOMMU_DEV_TABLE_GV_SHIFT, &entry);
+
+    /* 1 level guest cr3 table  */
+    set_field_in_reg_u32(glx, entry,
+                         IOMMU_DEV_TABLE_GLX_MASK,
+                         IOMMU_DEV_TABLE_GLX_SHIFT, &entry);
+    /* update gcr3 */
+    set_field_in_reg_u32(gcr3_1, entry,
+                         IOMMU_DEV_TABLE_GCR3_1_MASK,
+                         IOMMU_DEV_TABLE_GCR3_1_SHIFT, &entry);
+    dte[1] = entry;
+}
+
 u64 amd_iommu_get_next_table_from_pte(u32 *entry)
 {
     u64 addr_lo, addr_hi, ptr;
diff -r b190e3362524 -r ea52a2b93dff xen/drivers/passthrough/amd/pci_amd_iommu.c
--- a/xen/drivers/passthrough/amd/pci_amd_iommu.c	Wed Dec 14 12:51:22 2011 +0100
+++ b/xen/drivers/passthrough/amd/pci_amd_iommu.c	Wed Dec 14 12:58:17 2011 +0100
@@ -260,6 +260,8 @@ static int amd_iommu_domain_init(struct 
 
     hd->domain_id = d->domain_id;
 
+    guest_iommu_init(d);
+
     return 0;
 }
 
@@ -443,6 +445,7 @@ static void deallocate_iommu_page_tables
 
 static void amd_iommu_domain_destroy(struct domain *d)
 {
+    guest_iommu_destroy(d);
     deallocate_iommu_page_tables(d);
     amd_iommu_flush_all_pages(d);
 }
diff -r b190e3362524 -r ea52a2b93dff xen/include/asm-x86/amd-iommu.h
--- a/xen/include/asm-x86/amd-iommu.h	Wed Dec 14 12:51:22 2011 +0100
+++ b/xen/include/asm-x86/amd-iommu.h	Wed Dec 14 12:58:17 2011 +0100
@@ -24,6 +24,7 @@
 #include <xen/types.h>
 #include <xen/list.h>
 #include <xen/spinlock.h>
+#include <xen/tasklet.h>
 #include <asm/hvm/svm/amd-iommu-defs.h>
 
 #define iommu_found()           (!list_empty(&amd_iommu_head))
@@ -130,4 +131,62 @@ struct ivrs_mappings *get_ivrs_mappings(
 int iterate_ivrs_mappings(int (*)(u16 seg, struct ivrs_mappings *));
 int iterate_ivrs_entries(int (*)(u16 seg, struct ivrs_mappings *));
 
+/* iommu tables in guest space */
+struct guest_pages {
+    struct list_head list;
+    struct page_info *page;
+};
+
+struct mmio_reg {
+    uint32_t    lo;
+    uint32_t    hi;
+};
+
+struct guest_dev_table {
+    struct list_head        page_list;
+    struct mmio_reg         reg_base;
+    uint32_t                size;
+};
+
+struct guest_buffer {
+    struct list_head        page_list;
+    struct mmio_reg         reg_base;
+    struct mmio_reg         reg_tail;
+    struct mmio_reg         reg_head;
+    uint32_t                entries;
+};
+
+struct guest_iommu_msi {
+    uint8_t                 vector;
+    uint8_t                 dest;
+    uint8_t                 dest_mode;
+    uint8_t                 delivery_mode;
+    uint8_t                 trig_mode;
+};
+
+/* virtual IOMMU structure */
+struct guest_iommu {
+
+    struct domain          *domain;
+    spinlock_t              lock;
+    bool_t                  enabled;
+
+    struct guest_dev_table  dev_table;
+    struct guest_buffer     cmd_buffer;
+    struct guest_buffer     event_log;
+    struct guest_buffer     ppr_log;
+
+    struct tasklet          cmd_buffer_tasklet;
+
+    uint64_t                mmio_base;             /* MMIO base address */
+
+    /* MMIO regs */
+    struct mmio_reg         reg_ctrl;              /* MMIO offset 0018h */
+    struct mmio_reg         reg_status;            /* MMIO offset 2020h */
+    struct mmio_reg         reg_ext_feature;       /* MMIO offset 0030h */
+
+    /* guest interrupt settings */
+    struct guest_iommu_msi  msi;
+};
+
 #endif /* _ASM_X86_64_AMD_IOMMU_H */
diff -r b190e3362524 -r ea52a2b93dff xen/include/asm-x86/hvm/svm/amd-iommu-defs.h
--- a/xen/include/asm-x86/hvm/svm/amd-iommu-defs.h	Wed Dec 14 12:51:22 2011 +0100
+++ b/xen/include/asm-x86/hvm/svm/amd-iommu-defs.h	Wed Dec 14 12:58:17 2011 +0100
@@ -117,6 +117,13 @@
 #define IOMMU_DEV_TABLE_PAGE_TABLE_PTR_LOW_SHIFT	12
 
 /* DeviceTable Entry[63:32] */
+#define IOMMU_DEV_TABLE_GV_SHIFT                    23
+#define IOMMU_DEV_TABLE_GV_MASK                     0x800000
+#define IOMMU_DEV_TABLE_GLX_SHIFT                   24
+#define IOMMU_DEV_TABLE_GLX_MASK                    0x3000000
+#define IOMMU_DEV_TABLE_GCR3_1_SHIFT                26
+#define IOMMU_DEV_TABLE_GCR3_1_MASK                 0x1c000000
+
 #define IOMMU_DEV_TABLE_PAGE_TABLE_PTR_HIGH_MASK	0x000FFFFF
 #define IOMMU_DEV_TABLE_PAGE_TABLE_PTR_HIGH_SHIFT	0
 #define IOMMU_DEV_TABLE_IO_READ_PERMISSION_MASK		0x20000000
@@ -127,6 +134,8 @@
 /* DeviceTable Entry[95:64] */
 #define IOMMU_DEV_TABLE_DOMAIN_ID_MASK	0x0000FFFF
 #define IOMMU_DEV_TABLE_DOMAIN_ID_SHIFT	0
+#define IOMMU_DEV_TABLE_GCR3_2_SHIFT                16
+#define IOMMU_DEV_TABLE_GCR3_2_MASK                 0xFFFF0000
 
 /* DeviceTable Entry[127:96] */
 #define IOMMU_DEV_TABLE_IOTLB_SUPPORT_MASK		0x00000001
@@ -155,6 +164,8 @@
 #define IOMMU_DEV_TABLE_INT_TABLE_IGN_UNMAPPED_SHIFT      5
 #define IOMMU_DEV_TABLE_INT_TABLE_PTR_LOW_MASK      0xFFFFFFC0
 #define IOMMU_DEV_TABLE_INT_TABLE_PTR_LOW_SHIFT     6
+#define IOMMU_DEV_TABLE_GCR3_3_SHIFT                11
+#define IOMMU_DEV_TABLE_GCR3_3_MASK                 0xfffff800
 
 /* DeviceTable Entry[191:160] */
 #define IOMMU_DEV_TABLE_INT_TABLE_PTR_HIGH_MASK     0x000FFFFF
@@ -164,7 +175,6 @@
 #define IOMMU_DEV_TABLE_INT_CONTROL_MASK        0x30000000
 #define IOMMU_DEV_TABLE_INT_CONTROL_SHIFT       28
 
-
 /* Command Buffer */
 #define IOMMU_CMD_BUFFER_BASE_LOW_OFFSET	0x08
 #define IOMMU_CMD_BUFFER_BASE_HIGH_OFFSET	0x0C
@@ -192,6 +202,7 @@
 #define IOMMU_CMD_INVALIDATE_IOMMU_PAGES	0x3
 #define IOMMU_CMD_INVALIDATE_IOTLB_PAGES	0x4
 #define IOMMU_CMD_INVALIDATE_INT_TABLE		0x5
+#define IOMMU_CMD_COMPLETE_PPR_REQUEST      0x7
 #define IOMMU_CMD_INVALIDATE_IOMMU_ALL      0x8
 
 /* COMPLETION_WAIT command */
@@ -282,6 +293,28 @@
 #define IOMMU_EVENT_DEVICE_ID_MASK           0x0000FFFF
 #define IOMMU_EVENT_DEVICE_ID_SHIFT          0
 
+/* PPR Log */
+#define IOMMU_PPR_LOG_ENTRY_SIZE                        16
+#define IOMMU_PPR_LOG_POWER_OF2_ENTRIES_PER_PAGE        8
+#define IOMMU_PPR_LOG_U32_PER_ENTRY   (IOMMU_PPR_LOG_ENTRY_SIZE / 4)
+
+#define IOMMU_PPR_LOG_BASE_LOW_OFFSET                   0x0038
+#define IOMMU_PPR_LOG_BASE_HIGH_OFFSET                  0x003C
+#define IOMMU_PPR_LOG_BASE_LOW_MASK                     0xFFFFF000
+#define IOMMU_PPR_LOG_BASE_LOW_SHIFT                    12
+#define IOMMU_PPR_LOG_BASE_HIGH_MASK                    0x000FFFFF
+#define IOMMU_PPR_LOG_BASE_HIGH_SHIFT                   0
+#define IOMMU_PPR_LOG_LENGTH_MASK                       0x0F000000
+#define IOMMU_PPR_LOG_LENGTH_SHIFT                      24
+#define IOMMU_PPR_LOG_HEAD_MASK                         0x0007FFF0
+#define IOMMU_PPR_LOG_HEAD_SHIFT                        4
+#define IOMMU_PPR_LOG_TAIL_MASK                         0x0007FFF0
+#define IOMMU_PPR_LOG_TAIL_SHIFT                        4
+#define IOMMU_PPR_LOG_HEAD_OFFSET                       0x2030
+#define IOMMU_PPR_LOG_TAIL_OFFSET                       0x2038
+#define IOMMU_PPR_LOG_DEVICE_ID_MASK                    0x0000FFFF
+#define IOMMU_PPR_LOG_DEVICE_ID_SHIFT                   0
+
 /* Control Register */
 #define IOMMU_CONTROL_MMIO_OFFSET			0x18
 #define IOMMU_CONTROL_TRANSLATION_ENABLE_MASK		0x00000001
@@ -309,6 +342,11 @@
 #define IOMMU_CONTROL_RESTART_MASK			0x80000000
 #define IOMMU_CONTROL_RESTART_SHIFT			31
 
+#define IOMMU_CONTROL_PPR_LOG_ENABLE_SHIFT      13
+#define IOMMU_CONTROL_PPR_INT_SHIFT             14
+#define IOMMU_CONTROL_PPR_ENABLE_SHIFT          15
+#define IOMMU_CONTROL_GT_ENABLE_SHIFT           16
+
 /* Exclusion Register */
 #define IOMMU_EXCLUSION_BASE_LOW_OFFSET		0x20
 #define IOMMU_EXCLUSION_BASE_HIGH_OFFSET	0x24
@@ -342,7 +380,8 @@
 #define IOMMU_EXT_FEATURE_HATS_MASK                     0x00000C00
 #define IOMMU_EXT_FEATURE_GATS_SHIFT                    0x12
 #define IOMMU_EXT_FEATURE_GATS_MASK                     0x00003000
-#define IOMMU_EXT_FEATURE_GLXSUP                        0x14
+#define IOMMU_EXT_FEATURE_GLXSUP_SHIFT                  0x14
+#define IOMMU_EXT_FEATURE_GLXSUP_MASK                   0x0000C000
 
 #define IOMMU_EXT_FEATURE_PASMAX_SHIFT                  0x0
 #define IOMMU_EXT_FEATURE_PASMAX_MASK                   0x0000001F
@@ -359,6 +398,9 @@
 #define IOMMU_STATUS_EVENT_LOG_RUN_SHIFT	3
 #define IOMMU_STATUS_CMD_BUFFER_RUN_MASK	0x00000010
 #define IOMMU_STATUS_CMD_BUFFER_RUN_SHIFT	4
+#define IOMMU_STATUS_PPR_LOG_OVERFLOW_SHIFT     5
+#define IOMMU_STATUS_PPR_LOG_INT_SHIFT          6
+#define IOMMU_STATUS_PPR_LOG_RUN_SHIFT          7
 
 /* I/O Page Table */
 #define IOMMU_PAGE_TABLE_ENTRY_SIZE	8
diff -r b190e3362524 -r ea52a2b93dff xen/include/asm-x86/hvm/svm/amd-iommu-proto.h
--- a/xen/include/asm-x86/hvm/svm/amd-iommu-proto.h	Wed Dec 14 12:51:22 2011 +0100
+++ b/xen/include/asm-x86/hvm/svm/amd-iommu-proto.h	Wed Dec 14 12:58:17 2011 +0100
@@ -71,6 +71,8 @@ void amd_iommu_set_root_page_table(
     u32 *dte, u64 root_ptr, u16 domain_id, u8 paging_mode, u8 valid);
 void iommu_dte_set_iotlb(u32 *dte, u8 i);
 void iommu_dte_add_device_entry(u32 *dte, struct ivrs_mappings *ivrs_dev);
+void iommu_dte_set_guest_cr3(u32 *dte, u16 dom_id, u64 gcr3, 
+                             int gv, unsigned int glx);
 
 /* send cmd to iommu */
 void amd_iommu_flush_all_pages(struct domain *d);
@@ -106,6 +108,14 @@ void amd_iommu_resume(void);
 void amd_iommu_suspend(void);
 void amd_iommu_crash_shutdown(void);
 
+/* guest iommu support */
+void amd_iommu_send_guest_cmd(struct amd_iommu *iommu, u32 cmd[]);
+void guest_iommu_add_ppr_log(struct domain *d, u32 entry[]);
+void guest_iommu_add_event_log(struct domain *d, u32 entry[]);
+int guest_iommu_init(struct domain* d);
+void guest_iommu_destroy(struct domain *d);
+int guest_iommu_set_base(struct domain *d, uint64_t base);
+
 static inline u32 get_field_from_reg_u32(u32 reg_value, u32 mask, u32 shift)
 {
     u32 field;
diff -r b190e3362524 -r ea52a2b93dff xen/include/xen/hvm/iommu.h
--- a/xen/include/xen/hvm/iommu.h	Wed Dec 14 12:51:22 2011 +0100
+++ b/xen/include/xen/hvm/iommu.h	Wed Dec 14 12:58:17 2011 +0100
@@ -47,6 +47,7 @@ struct hvm_iommu {
     int domain_id;
     int paging_mode;
     struct page_info *root_table;
+    struct guest_iommu *g_iommu;
 
     /* iommu_ops */
     const struct iommu_ops *platform_ops;


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 15:36:58 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 15:36:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Raqt5-0003W7-U7; Wed, 14 Dec 2011 15:36:55 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Wang2@amd.com>) id 1Raqt4-0003Qz-IM
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 15:36:55 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1323876957!7262277!1
X-Originating-IP: [213.199.154.208]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26788 invoked from network); 14 Dec 2011 15:35:58 -0000
Received: from am1ehsobe005.messaging.microsoft.com (HELO
	AM1EHSOBE005.bigfish.com) (213.199.154.208)
	by server-6.tower-182.messagelabs.com with AES128-SHA encrypted SMTP;
	14 Dec 2011 15:35:58 -0000
Received: from mail10-am1-R.bigfish.com (10.3.201.245) by
	AM1EHSOBE005.bigfish.com (10.3.204.25) with Microsoft SMTP Server id
	14.1.225.23; Wed, 14 Dec 2011 15:35:59 +0000
Received: from mail10-am1 (localhost [127.0.0.1])	by mail10-am1-R.bigfish.com
	(Postfix) with ESMTP id BBF791C03AB;
	Wed, 14 Dec 2011 15:36:00 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzc8kzz1202hzz8275bh5eeeKz2dh668h839h944h)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
X-FB-SS: 0,
Received: from mail10-am1 (localhost.localdomain [127.0.0.1]) by mail10-am1
	(MessageSwitch) id 132387692674002_1808; Wed, 14 Dec 2011 15:35:26 +0000
	(UTC)
Received: from AM1EHSMHS007.bigfish.com (unknown [10.3.201.246])	by
	mail10-am1.bigfish.com (Postfix) with ESMTP id 0C3E63E12B0;
	Wed, 14 Dec 2011 15:35:26 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	AM1EHSMHS007.bigfish.com (10.3.207.107) with Microsoft SMTP Server id
	14.1.225.23; Wed, 14 Dec 2011 15:35:22 +0000
X-WSS-ID: 0LW79YR-02-A9F-02
X-M-MSG: 
Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com
	[163.181.249.73])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp02.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 24E1FC808D;	Wed, 14 Dec 2011 09:35:15 -0600 (CST)
Received: from SAUSEXDAG01.amd.com (163.181.55.1) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Wed, 14 Dec 2011 09:35:29 -0600
Received: from storexhtp01.amd.com (172.24.4.3) by sausexdag01.amd.com
	(163.181.55.1) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Wed, 14 Dec 2011 09:35:17 -0600
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp01.amd.com
	(172.24.4.3) with Microsoft SMTP Server id 8.3.213.0; Wed, 14 Dec 2011
	10:35:12 -0500
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 35D9549C65D; Wed, 14 Dec 2011
	15:35:11 +0000 (GMT)
Received: from gran.amd.com (gran.osrc.amd.com [165.204.15.57])	by
	mail.osrc.amd.com (Postfix) with ESMTP id 21C84594884; Wed, 14 Dec 2011
	16:35:11 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: ea52a2b93dffe708084fdc6ee663bd5eee8c1031
Message-ID: <ea52a2b93dffe708084f.1323876564@gran.amd.com>
In-Reply-To: <patchbomb.1323876561@gran.amd.com>
References: <patchbomb.1323876561@gran.amd.com>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Wed, 14 Dec 2011 16:29:24 +0100
From: Wei Wang <wei.wang2@amd.com>
To: <JBeulich@suse.com>, <keir@xen.org>
X-OriginatorOrg: amd.com
Cc: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 03 of 16] amd iommu: Add iommu emulation for hvm
	guest
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Wei Wang <wei.wang2@amd.com>
# Date 1323863897 -3600
# Node ID ea52a2b93dffe708084fdc6ee663bd5eee8c1031
# Parent  b190e3362524a0e160e9892cd600447cee2a022e
amd iommu: Add iommu emulation for hvm guest
ATS device driver that support PASID [1] and PRI [2] capabilites needs to work with iommu driver
in OS. If we want passthru ATS device to hvm guests using unmodified OS, we have to expose iommu
functionality to HVM guest.

Signed-off-by: Wei Wang <wei.wang2@amd.com>


[1] http://www.pcisig.com/specifications/pciexpress/specifications/ECN-PASID-ATS-2011-03-31.pdf
[2] http://www.pcisig.com/members/downloads/specifications/iov/ats_r1.1_26Jan09.pdf

diff -r b190e3362524 -r ea52a2b93dff xen/drivers/passthrough/amd/Makefile
--- a/xen/drivers/passthrough/amd/Makefile	Wed Dec 14 12:51:22 2011 +0100
+++ b/xen/drivers/passthrough/amd/Makefile	Wed Dec 14 12:58:17 2011 +0100
@@ -5,3 +5,4 @@ obj-y += pci_amd_iommu.o
 obj-bin-y += iommu_acpi.init.o
 obj-y += iommu_intr.o
 obj-y += iommu_cmd.o
+obj-y += iommu_guest.o
diff -r b190e3362524 -r ea52a2b93dff xen/drivers/passthrough/amd/iommu_cmd.c
--- a/xen/drivers/passthrough/amd/iommu_cmd.c	Wed Dec 14 12:51:22 2011 +0100
+++ b/xen/drivers/passthrough/amd/iommu_cmd.c	Wed Dec 14 12:58:17 2011 +0100
@@ -398,3 +398,15 @@ void amd_iommu_flush_all_caches(struct a
     invalidate_iommu_all(iommu);
     flush_command_buffer(iommu);
 }
+
+void amd_iommu_send_guest_cmd(struct amd_iommu *iommu, u32 cmd[])
+{
+    unsigned long flags;
+
+    spin_lock_irqsave(&iommu->lock, flags);
+
+    send_iommu_command(iommu, cmd);
+    flush_command_buffer(iommu);
+
+    spin_unlock_irqrestore(&iommu->lock, flags);
+}
diff -r b190e3362524 -r ea52a2b93dff xen/drivers/passthrough/amd/iommu_guest.c
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/drivers/passthrough/amd/iommu_guest.c	Wed Dec 14 12:58:17 2011 +0100
@@ -0,0 +1,953 @@
+/*
+ * Copyright (C) 2011 Advanced Micro Devices, Inc.
+ * Author: Wei Wang <wei.wang2@amd.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307 USA
+ */
+
+#include <xen/sched.h>
+#include <asm/p2m.h>
+#include <asm/hvm/iommu.h>
+#include <asm/amd-iommu.h>
+#include <asm/hvm/svm/amd-iommu-proto.h>
+
+
+#define IOMMU_MMIO_SIZE                         0x8000
+#define IOMMU_MMIO_PAGE_NR                      0x8
+#define RING_BF_LENGTH_MASK                     0x0F000000
+#define RING_BF_LENGTH_SHIFT                    24
+
+#define PASMAX_9_bit                            0x8
+#define GUEST_CR3_1_LEVEL                       0x0
+#define GUEST_ADDRESS_SIZE_6_LEVEL              0x2
+#define HOST_ADDRESS_SIZE_6_LEVEL               0x2
+
+#define guest_iommu_set_status(iommu, bit) \
+        iommu_set_bit(&((iommu)->reg_status.lo), bit)
+
+#define guest_iommu_clear_status(iommu, bit) \
+        iommu_clear_bit(&((iommu)->reg_status.lo), bit)
+
+#define reg_to_u64(reg) (((uint64_t)reg.hi << 32) | reg.lo )
+#define u64_to_reg(reg, val) \
+    do  \
+    {   \
+        (reg)->lo = val & 0xFFFFFFFF; \
+        (reg)->hi = (val >> 32) & 0xFFFFFFFF; \
+    } while(0)
+
+static unsigned int machine_bdf(struct domain *d, uint16_t guest_bdf)
+{
+    return guest_bdf;
+}
+
+static uint16_t guest_bdf(struct domain *d, uint16_t machine_bdf)
+{
+    return machine_bdf;
+}
+
+static inline struct guest_iommu *domain_iommu(struct domain *d)
+{
+    return domain_hvm_iommu(d)->g_iommu;
+}
+
+static inline struct guest_iommu *vcpu_iommu(struct vcpu *v)
+{
+    return domain_hvm_iommu(v->domain)->g_iommu;
+}
+
+static void guest_iommu_enable(struct guest_iommu *iommu)
+{
+    iommu->enabled = 1;
+}
+
+static void guest_iommu_disable(struct guest_iommu *iommu)
+{
+    iommu->enabled = 0;
+}
+
+static uint64_t get_guest_cr3_from_dte(dev_entry_t *dte)
+{
+    uint64_t gcr3_1, gcr3_2, gcr3_3;
+
+    gcr3_1 = get_field_from_reg_u32(dte->data[1],
+                                    IOMMU_DEV_TABLE_GCR3_1_MASK,
+                                    IOMMU_DEV_TABLE_GCR3_1_SHIFT);
+    gcr3_2 = get_field_from_reg_u32(dte->data[2],
+                                    IOMMU_DEV_TABLE_GCR3_2_MASK,
+                                    IOMMU_DEV_TABLE_GCR3_2_SHIFT);
+    gcr3_3 = get_field_from_reg_u32(dte->data[3],
+                                    IOMMU_DEV_TABLE_GCR3_3_MASK,
+                                    IOMMU_DEV_TABLE_GCR3_3_SHIFT);
+
+    return ((gcr3_3 << 31) | (gcr3_2 << 15 ) | (gcr3_1 << 12)) >> PAGE_SHIFT;
+}
+
+static uint16_t get_domid_from_dte(dev_entry_t *dte)
+{
+    return get_field_from_reg_u32(dte->data[2], IOMMU_DEV_TABLE_DOMAIN_ID_MASK, 
+                                  IOMMU_DEV_TABLE_DOMAIN_ID_SHIFT);
+}
+
+static uint16_t get_glx_from_dte(dev_entry_t *dte)
+{
+    return get_field_from_reg_u32(dte->data[1], IOMMU_DEV_TABLE_GLX_MASK,
+                                  IOMMU_DEV_TABLE_GLX_SHIFT);
+}
+
+static uint16_t get_gv_from_dte(dev_entry_t *dte)
+{
+    return get_field_from_reg_u32(dte->data[1],IOMMU_DEV_TABLE_GV_MASK,
+                                  IOMMU_DEV_TABLE_GV_SHIFT);
+}
+
+static unsigned int host_domid(struct domain *d, uint64_t g_domid)
+{
+    /* Only support one PPR device in guest for now */
+    return d->domain_id;
+}
+
+static void guest_iommu_deliver_msi(struct domain *d)
+{
+    uint8_t vector, dest, dest_mode, delivery_mode, trig_mode;
+    struct guest_iommu *iommu = domain_iommu(d);
+
+    vector = iommu->msi.vector;
+    dest = iommu->msi.dest;
+    dest_mode = iommu->msi.dest_mode;
+    delivery_mode = iommu->msi.delivery_mode;
+    trig_mode = iommu->msi.trig_mode;
+
+    vmsi_deliver(d, vector, dest, dest_mode, delivery_mode, trig_mode);
+}
+
+static struct page_info* guest_iommu_get_page(struct list_head *pglist,
+                                              unsigned int entry_size,
+                                              unsigned int pos)
+{
+    int idx;
+    struct list_head *head;
+    struct guest_pages *gpage = NULL;
+
+    idx = (pos * entry_size) >> PAGE_SHIFT;
+    list_for_each( head, pglist )
+    {
+        gpage = list_entry(head, struct guest_pages, list);
+        if ( (--idx) < 0 )
+            break;
+    }
+    return (gpage) ? gpage->page : NULL;
+}
+
+static void guest_iommu_map_table(uint64_t base_raw, struct list_head *head,
+                                  struct domain *d, unsigned long npages)
+{
+    struct guest_pages * gpage;
+    uint64_t addr_lo, addr_hi, addr64;
+    unsigned long gfn;
+    p2m_type_t p2mt;
+
+    addr_lo = iommu_get_addr_lo_from_reg(base_raw & DMA_32BIT_MASK);
+    addr_hi = iommu_get_addr_hi_from_reg(base_raw >> 32);
+    addr64 = (addr_hi << 32) | (addr_lo << PAGE_SHIFT);
+
+    ASSERT ( addr64 != 0 && head != NULL );
+
+    gfn = addr64 >> PAGE_SHIFT;
+
+    /*
+     * map guest table pages into Xen 
+     * Assuming guest table contiguous in guest space 
+     */
+    for ( int i = 0; i < npages; i++ )
+    {
+        gpage = (struct guest_pages *) xzalloc(struct guest_pages);
+        if ( unlikely(gpage == NULL) )
+        {
+            AMD_IOMMU_DEBUG("Cannot allocate guest_pages struct\n");
+            return;
+        }
+
+        gpage->page = mfn_to_page(mfn_x(get_gfn(d, gfn, &p2mt)));
+        list_add_tail(&gpage->list, head);
+        put_gfn(d,gfn);
+        gfn ++;
+    }
+}
+
+static void guest_iommu_enable_dev_table(struct guest_iommu *iommu)
+{
+    unsigned int npages;
+    uint32_t length_raw = get_field_from_reg_u32(iommu->dev_table.reg_base.lo,
+                                                 IOMMU_DEV_TABLE_SIZE_MASK,
+                                                 IOMMU_DEV_TABLE_SIZE_SHIFT);
+
+    iommu->dev_table.size = (length_raw + 1) * PAGE_SIZE;
+    npages = PAGE_ALIGN(iommu->dev_table.size) >> PAGE_SHIFT;
+
+    guest_iommu_map_table(reg_to_u64(iommu->dev_table.reg_base),
+                          &iommu->dev_table.page_list, iommu->domain, npages);
+}
+
+static void guest_iommu_enable_ring_buffer(struct guest_iommu *iommu,
+                                          struct guest_buffer *buffer,
+                                          uint32_t entry_size)
+{
+    unsigned npages;
+    uint32_t length_raw = get_field_from_reg_u32(buffer->reg_base.hi,
+                                                 RING_BF_LENGTH_MASK,
+                                                 RING_BF_LENGTH_SHIFT);
+    buffer->entries = 1 << length_raw;
+    npages = PAGE_ALIGN(buffer->entries * entry_size) >> PAGE_SHIFT;
+
+    guest_iommu_map_table(reg_to_u64(buffer->reg_base),
+                          &buffer->page_list, iommu->domain, npages);
+}
+
+void guest_iommu_add_ppr_log(struct domain *d, u32 entry[])
+{
+    uint16_t gdev_id;
+    ppr_entry_t *log, *log_base;
+    unsigned int tail;
+    struct guest_iommu *iommu;
+    struct page_info *page = NULL;
+
+    iommu = domain_iommu(d);
+    tail = iommu_get_rb_pointer(iommu->ppr_log.reg_tail.lo);
+
+    page = guest_iommu_get_page(&iommu->ppr_log.page_list, 
+                                sizeof(ppr_entry_t), tail);
+    if ( unlikely(page == NULL) )
+    {
+        AMD_IOMMU_DEBUG("Error: Cannot access guest event log pages\n");
+        return;
+    }
+
+    log_base = __map_domain_page(page);
+    log = log_base + tail % (PAGE_SIZE / sizeof(ppr_entry_t));
+
+    /* Convert physical device id back into virtual device id */
+    gdev_id = guest_bdf(d, iommu_get_devid_from_cmd(entry[0]));
+    iommu_set_devid_to_cmd(&entry[0], gdev_id);
+
+    memcpy(log, entry, sizeof(ppr_entry_t));
+
+    /* Now shift ppr log tail pointer */
+    tail++;
+    iommu_set_rb_pointer(&iommu->ppr_log.reg_tail.lo, tail);
+    unmap_domain_page(log_base);
+
+    guest_iommu_deliver_msi(d);
+}
+
+void guest_iommu_add_event_log(struct domain *d, u32 entry[])
+{
+    uint16_t dev_id;
+    struct event_entry *log, *log_base;
+    unsigned int tail;
+    struct guest_iommu *iommu;
+    struct page_info *page = NULL;
+
+    iommu = domain_iommu(d);
+    tail = iommu_get_rb_pointer(iommu->event_log.reg_tail.lo);
+
+    page = guest_iommu_get_page(&iommu->event_log.page_list, 
+                                sizeof(event_entry_t), tail);
+    if ( unlikely(page == NULL) )
+    {
+        AMD_IOMMU_DEBUG("Error: Cannot access guest event log pages\n");
+        return;
+    }
+
+    log_base = __map_domain_page(page);
+    log = log_base + tail % (PAGE_SIZE / sizeof(event_entry_t));
+
+    /* re-write physical device id into virtual device id */
+    dev_id = guest_bdf(d, iommu_get_devid_from_cmd(entry[0]));
+    iommu_set_devid_to_cmd(&entry[0], dev_id);
+    memcpy(log, entry, sizeof(event_entry_t));
+
+    /* Now shift event log tail pointer */
+    tail++;
+    iommu_set_rb_pointer(&iommu->event_log.reg_tail.lo, tail);
+    unmap_domain_page(log_base);
+
+    guest_iommu_deliver_msi(d);
+}
+
+static int do_complete_ppr_request(struct domain *d, cmd_entry_t *cmd)
+{
+    uint16_t dev_id;
+    struct amd_iommu *iommu;
+
+    dev_id = machine_bdf(d, iommu_get_devid_from_cmd(cmd->data[0]));
+    iommu = find_iommu_for_device(0, dev_id);
+
+    if ( !iommu )
+    {
+        AMD_IOMMU_DEBUG("%s Fail to find iommu for bdf %x\n", 
+                        __func__, dev_id);
+        return -ENODEV;
+    }
+
+    /* replace virtual device id into physical */
+    iommu_set_devid_to_cmd(&cmd->data[0], dev_id);
+    amd_iommu_send_guest_cmd(iommu, cmd->data);
+
+    return 0;
+}
+
+static int do_invalidate_pages(struct domain *d, cmd_entry_t *cmd)
+{
+    uint16_t gdom_id, hdom_id;
+    struct amd_iommu *iommu = NULL;
+
+    gdom_id = get_field_from_reg_u32(cmd->data[1],
+                                    IOMMU_INV_IOMMU_PAGES_DOMAIN_ID_MASK,
+                                    IOMMU_INV_IOMMU_PAGES_DOMAIN_ID_SHIFT);
+
+    hdom_id = host_domid(d, gdom_id);
+    set_field_in_reg_u32(hdom_id, cmd->data[1],
+                         IOMMU_INV_IOMMU_PAGES_DOMAIN_ID_MASK,
+                         IOMMU_INV_IOMMU_PAGES_DOMAIN_ID_SHIFT, &cmd->data[1]);
+
+    for_each_amd_iommu ( iommu )
+        amd_iommu_send_guest_cmd(iommu, cmd->data);
+
+    return 0;
+}
+
+static int do_invalidate_all(struct domain *d, cmd_entry_t *cmd)
+{
+    struct amd_iommu *iommu = NULL;
+
+    for_each_amd_iommu ( iommu )
+        amd_iommu_flush_all_pages(d);
+
+    return 0;
+}
+
+static int do_invalidate_iotlb_pages(struct domain *d, cmd_entry_t *cmd)
+{
+    struct amd_iommu *iommu;
+    uint16_t dev_id;
+
+    dev_id = machine_bdf(d, iommu_get_devid_from_cmd(cmd->data[0]));
+
+    iommu = find_iommu_for_device(0, dev_id);
+    if ( !iommu )
+    {
+        AMD_IOMMU_DEBUG("%s Fail to find iommu for bdf %x\n", 
+                         __func__, dev_id);
+        return -ENODEV;
+    }
+
+    iommu_set_devid_to_cmd(&cmd->data[0], dev_id);
+    amd_iommu_send_guest_cmd(iommu, cmd->data);
+
+    return 0;
+}
+
+static int do_completion_wait(struct domain *d, cmd_entry_t *cmd)
+{
+    bool_t com_wait_int_en, com_wait_int, i, s;
+    struct guest_iommu *iommu;
+    unsigned long gfn;
+    p2m_type_t p2mt;
+
+    iommu = domain_iommu(d);
+
+    i = iommu_get_bit(cmd->data[0], IOMMU_COMP_WAIT_I_FLAG_SHIFT);
+    s = iommu_get_bit(cmd->data[0], IOMMU_COMP_WAIT_S_FLAG_SHIFT);
+
+    if ( i )
+        guest_iommu_set_status(iommu, IOMMU_STATUS_COMP_WAIT_INT_SHIFT);
+
+    if ( s )
+    {
+        uint64_t gaddr_lo, gaddr_hi, gaddr_64, data;
+        void *vaddr;
+
+        data = (uint64_t) cmd->data[3] << 32 | cmd->data[2];
+        gaddr_lo = get_field_from_reg_u32(cmd->data[0],
+                                          IOMMU_COMP_WAIT_ADDR_LOW_MASK,
+                                          IOMMU_COMP_WAIT_ADDR_LOW_SHIFT);
+        gaddr_hi = get_field_from_reg_u32(cmd->data[1],
+                                          IOMMU_COMP_WAIT_ADDR_HIGH_MASK,
+                                          IOMMU_COMP_WAIT_ADDR_HIGH_SHIFT);
+
+        gaddr_64 = (gaddr_hi << 32) | (gaddr_lo << 3);
+
+        gfn = gaddr_64 >> PAGE_SHIFT;
+        vaddr = map_domain_page(mfn_x(get_gfn(d, gfn ,&p2mt)));
+        put_gfn(d, gfn);
+
+        write_u64_atomic((uint64_t*)(vaddr + (gaddr_64 & (PAGE_SIZE-1))), data);
+        unmap_domain_page(vaddr);
+    }
+
+    com_wait_int_en = iommu_get_bit(iommu->reg_ctrl.lo,
+                                    IOMMU_CONTROL_COMP_WAIT_INT_SHIFT);
+    com_wait_int = iommu_get_bit(iommu->reg_status.lo,
+                                 IOMMU_STATUS_COMP_WAIT_INT_SHIFT);
+
+    if ( com_wait_int_en && com_wait_int )
+        guest_iommu_deliver_msi(d);
+
+    return 0;
+}
+
+static int do_invalidate_dte(struct domain *d, cmd_entry_t *cmd)
+{
+    uint16_t gbdf, mbdf, req_id, gdom_id, hdom_id;
+    dev_entry_t *gdte, *mdte, *dte_base;
+    struct amd_iommu *iommu = NULL;
+    struct page_info *dte_page = NULL;
+    struct guest_iommu *g_iommu;
+    uint64_t gcr3_gfn, gcr3_mfn;
+    uint8_t glx, gv;
+    unsigned long flags;
+    p2m_type_t p2mt;
+
+    g_iommu = domain_iommu(d);
+    gbdf = iommu_get_devid_from_cmd(cmd->data[0]);
+    mbdf = machine_bdf(d, gbdf);
+
+    /* Guest can only update DTEs for its passthru devices */
+    if ( mbdf == 0 || gbdf == 0 )
+        return 0;
+
+    /* Sometimes guest invalidates devices from non-exists dtes */
+    if ( (gbdf * sizeof(dev_entry_t)) > g_iommu->dev_table.size )
+        return 0;
+
+    dte_page = guest_iommu_get_page(&g_iommu->dev_table.page_list,
+                                    sizeof(dev_entry_t), gbdf);
+    if ( unlikely(dte_page == NULL) )
+    {
+        AMD_IOMMU_DEBUG("Error: Cannot access guest device table\n");
+        return -ENOMEM ;
+    }
+
+    dte_base = __map_domain_page(dte_page);
+
+    gdte = dte_base + gbdf % (PAGE_SIZE / sizeof(dev_entry_t));
+
+    gdom_id  = get_domid_from_dte(gdte);
+    gcr3_gfn = get_guest_cr3_from_dte(gdte);
+
+    /* Do not update host dte before gcr3 has been set */
+    if ( gcr3_gfn == 0 )
+        return 0;
+
+    gcr3_mfn = mfn_x(get_gfn(d, gcr3_gfn, &p2mt));
+    put_gfn(d, gcr3_gfn);
+
+    ASSERT(mfn_valid(gcr3_mfn));
+
+    /* Read guest dte information */
+    iommu = find_iommu_for_device(0, mbdf);
+    if ( !iommu )
+    {
+        AMD_IOMMU_DEBUG("%s Fail to find iommu!\n",__func__);
+        return -ENODEV;
+    }
+
+    glx = get_glx_from_dte(gdte);
+    gv = get_gv_from_dte(gdte);
+
+    unmap_domain_page(dte_base);
+
+    /* Setup host device entry */
+    hdom_id = host_domid(d, gdom_id);
+    req_id = get_dma_requestor_id(iommu->seg, mbdf);
+    mdte = iommu->dev_table.buffer + (req_id * sizeof(dev_entry_t));
+
+    spin_lock_irqsave(&iommu->lock, flags);
+    iommu_dte_set_guest_cr3((u32*)mdte, hdom_id, 
+                            gcr3_mfn << PAGE_SHIFT, gv, glx);
+
+    amd_iommu_flush_device(iommu, req_id);
+    spin_unlock_irqrestore(&iommu->lock, flags);
+
+    return 0;
+}
+
+static void guest_iommu_process_command(unsigned long _d)
+{
+    unsigned int opcode, tail, head, entries_per_page;
+    cmd_entry_t *cmd, *cmd_base;
+    struct domain *d;
+    struct guest_iommu *iommu;
+    struct page_info *cmd_page = NULL;
+
+    d = (struct domain*) _d;
+    iommu = domain_iommu(d);
+
+    if ( !iommu->enabled )
+        return;
+
+    head = iommu_get_rb_pointer(iommu->cmd_buffer.reg_head.lo);
+    tail = iommu_get_rb_pointer(iommu->cmd_buffer.reg_tail.lo);
+
+    /* Tail pointer is rolled over by guest driver, value outside
+     * cmd_buffer_entries cause iommu disabled 
+     */
+    entries_per_page = PAGE_SIZE / sizeof(cmd_entry_t);
+
+    while ( head != tail )
+    {
+        int ret = 0;
+        cmd_page = guest_iommu_get_page(&iommu->cmd_buffer.page_list, 
+                                        sizeof(cmd_entry_t), head);
+        if ( unlikely(cmd_page == NULL) )
+        {
+            AMD_IOMMU_DEBUG("Error: cannot access guest cmd buffer head = %d\n",
+                            head);
+            return;
+        }
+
+        cmd_base = __map_domain_page(cmd_page);
+        cmd = cmd_base + head % entries_per_page;
+
+        opcode = get_field_from_reg_u32(cmd->data[1], 
+                                        IOMMU_CMD_OPCODE_MASK,
+                                        IOMMU_CMD_OPCODE_SHIFT);
+        switch ( opcode )
+        {
+            case IOMMU_CMD_COMPLETION_WAIT:
+                ret = do_completion_wait(d, cmd);
+                break;
+            case IOMMU_CMD_INVALIDATE_DEVTAB_ENTRY:
+                ret = do_invalidate_dte(d, cmd);
+                break;
+            case IOMMU_CMD_INVALIDATE_IOMMU_PAGES:
+                ret = do_invalidate_pages(d, cmd);
+                break;
+            case IOMMU_CMD_INVALIDATE_IOTLB_PAGES:
+                ret = do_invalidate_iotlb_pages(d, cmd);
+                break;
+            case IOMMU_CMD_INVALIDATE_INT_TABLE:
+                break;
+            case IOMMU_CMD_COMPLETE_PPR_REQUEST:
+                ret = do_complete_ppr_request(d, cmd);
+                break;
+            case IOMMU_CMD_INVALIDATE_IOMMU_ALL:
+                ret = do_invalidate_all(d, cmd);
+                break;
+            default:
+                AMD_IOMMU_DEBUG("CMD: Unknown command cmd_type = %x "
+                                "head = %d\n", opcode, head);
+                break;
+        }
+
+        unmap_domain_page(cmd_base);
+        if ( (++head) >= iommu->cmd_buffer.entries )
+            head = 0;
+        if ( ret )
+            guest_iommu_disable(iommu);
+    }
+
+    /* Now shift cmd buffer head pointer */ 
+    iommu_set_rb_pointer(&iommu->cmd_buffer.reg_head.lo, head);
+    return;
+}
+
+static int guest_iommu_write_ctrl(struct guest_iommu *iommu, uint64_t newctrl)
+{
+    bool_t cmd_en, event_en, iommu_en, ppr_en, ppr_log_en;
+    bool_t cmd_en_old, event_en_old, iommu_en_old;
+    bool_t cmd_run;
+
+    iommu_en = iommu_get_bit(newctrl, 
+                             IOMMU_CONTROL_TRANSLATION_ENABLE_SHIFT);
+    iommu_en_old = iommu_get_bit(iommu->reg_ctrl.lo,
+                                 IOMMU_CONTROL_TRANSLATION_ENABLE_SHIFT);
+
+    cmd_en = iommu_get_bit(newctrl, 
+                           IOMMU_CONTROL_COMMAND_BUFFER_ENABLE_SHIFT);
+    cmd_en_old = iommu_get_bit(iommu->reg_ctrl.lo,
+                               IOMMU_CONTROL_COMMAND_BUFFER_ENABLE_SHIFT);
+    cmd_run = iommu_get_bit(iommu->reg_status.lo, 
+
+                            IOMMU_STATUS_CMD_BUFFER_RUN_SHIFT);
+    event_en = iommu_get_bit(newctrl,
+                             IOMMU_CONTROL_EVENT_LOG_ENABLE_SHIFT);
+    event_en_old = iommu_get_bit(iommu->reg_ctrl.lo,
+                                 IOMMU_CONTROL_EVENT_LOG_ENABLE_SHIFT);
+
+    ppr_en = iommu_get_bit(newctrl, 
+                           IOMMU_CONTROL_PPR_ENABLE_SHIFT);
+    ppr_log_en = iommu_get_bit(newctrl,
+                               IOMMU_CONTROL_PPR_LOG_ENABLE_SHIFT);
+
+    if ( iommu_en )
+    {
+        guest_iommu_enable(iommu);
+        guest_iommu_enable_dev_table(iommu);
+    }
+
+    if ( iommu_en && cmd_en )
+    {
+        guest_iommu_enable_ring_buffer(iommu, &iommu->cmd_buffer,
+                                       sizeof(cmd_entry_t));
+        /* Enable iommu command processing */
+        tasklet_schedule(&iommu->cmd_buffer_tasklet);
+    }
+
+    if ( iommu_en && event_en )
+    {
+        guest_iommu_enable_ring_buffer(iommu, &iommu->event_log,
+                                       sizeof(event_entry_t));
+        guest_iommu_set_status(iommu, IOMMU_STATUS_EVENT_LOG_RUN_SHIFT);
+        guest_iommu_clear_status(iommu, IOMMU_STATUS_EVENT_OVERFLOW_SHIFT);
+    }
+
+    if ( iommu_en && ppr_en && ppr_log_en )
+    {
+        guest_iommu_enable_ring_buffer(iommu, &iommu->ppr_log,
+                                       sizeof(ppr_entry_t));
+        guest_iommu_set_status(iommu, IOMMU_STATUS_PPR_LOG_RUN_SHIFT);
+        guest_iommu_clear_status(iommu, IOMMU_STATUS_PPR_LOG_OVERFLOW_SHIFT);
+    }
+
+    if ( iommu_en && cmd_en_old && !cmd_en )
+    {
+        /* Disable iommu command processing */
+        tasklet_kill(&iommu->cmd_buffer_tasklet);
+    }
+
+    if ( event_en_old && !event_en )
+    {
+        guest_iommu_clear_status(iommu, IOMMU_STATUS_EVENT_LOG_RUN_SHIFT);
+    }
+
+    if ( !iommu_en && iommu_en_old )
+    {
+        guest_iommu_disable(iommu);
+    }
+
+    iommu->reg_ctrl.lo = newctrl & 0xffffffff;
+    iommu->reg_ctrl.hi = newctrl >> 32;
+    return 0;
+}
+
+static uint64_t iommu_mmio_read64(struct guest_iommu *iommu, 
+                                  unsigned long offset)
+{
+    uint64_t val;
+
+    switch ( offset )
+    {
+        case IOMMU_DEV_TABLE_BASE_LOW_OFFSET:
+            val = reg_to_u64(iommu->dev_table.reg_base);
+            break;
+        case IOMMU_CMD_BUFFER_BASE_LOW_OFFSET:
+            val = reg_to_u64(iommu->cmd_buffer.reg_base);
+            break;
+        case IOMMU_EVENT_LOG_BASE_LOW_OFFSET:
+            val = reg_to_u64(iommu->event_log.reg_base);
+            break;
+        case IOMMU_PPR_LOG_BASE_LOW_OFFSET:
+            val = reg_to_u64(iommu->ppr_log.reg_base);
+            break;
+        case IOMMU_CMD_BUFFER_HEAD_OFFSET:
+            val = reg_to_u64(iommu->cmd_buffer.reg_head);
+            break;
+        case IOMMU_CMD_BUFFER_TAIL_OFFSET:
+            val = reg_to_u64(iommu->cmd_buffer.reg_tail);
+            break;
+        case IOMMU_EVENT_LOG_HEAD_OFFSET:;
+            val = reg_to_u64(iommu->event_log.reg_head);
+            break;
+        case IOMMU_EVENT_LOG_TAIL_OFFSET:
+            val = reg_to_u64(iommu->event_log.reg_tail);
+            break;
+        case IOMMU_PPR_LOG_HEAD_OFFSET:
+            val = reg_to_u64(iommu->ppr_log.reg_head);
+            break;
+        case IOMMU_PPR_LOG_TAIL_OFFSET:
+            val = reg_to_u64(iommu->ppr_log.reg_tail);
+            break;
+        case IOMMU_CONTROL_MMIO_OFFSET:
+            val = reg_to_u64(iommu->reg_ctrl);
+            break;
+        case IOMMU_STATUS_MMIO_OFFSET:
+            val = reg_to_u64(iommu->reg_status);
+            break;
+        case IOMMU_EXT_FEATURE_MMIO_OFFSET:
+            val = reg_to_u64(iommu->reg_ext_feature);
+            break;
+
+        default:
+            AMD_IOMMU_DEBUG("Guest reads unknown mmio offset = %lx\n", 
+                             offset);
+            val = 0;
+            break;
+    }
+
+    return val;
+}
+
+static int guest_iommu_mmio_read(struct vcpu *v, unsigned long addr,
+                                 unsigned long len, unsigned long *pval)
+{
+    struct guest_iommu *iommu = vcpu_iommu(v);
+    unsigned long offset;
+    uint64_t val;
+    uint32_t mmio, shift;
+    uint64_t mask = 0;
+
+    offset = addr - iommu->mmio_base;
+
+    if ( unlikely((offset & (len - 1 )) || (len > 8)) )
+    {
+        AMD_IOMMU_DEBUG("iommu mmio write access is not aligned." 
+                        "offset = %lx, len = %lx \n", offset, len);
+        return X86EMUL_UNHANDLEABLE;
+    }
+
+    mask = (len == 8) ? (~0ULL) : (1ULL << (len * 8)) - 1;
+    shift = (offset & 7u) * 8;
+
+    /* mmio access is always aligned on 8-byte boundary */
+    mmio = offset & (~7u);
+
+    spin_lock(&iommu->lock);
+    val = iommu_mmio_read64(iommu, mmio);
+    spin_unlock(&iommu->lock);
+
+    *pval = (val >> shift ) & mask;
+
+    return X86EMUL_OKAY;
+}
+
+static void guest_iommu_mmio_write64(struct guest_iommu *iommu, 
+                                    unsigned long offset, uint64_t val)
+{
+    switch ( offset )
+    {
+        case IOMMU_DEV_TABLE_BASE_LOW_OFFSET:
+            u64_to_reg(&iommu->dev_table.reg_base, val);
+            break;
+        case IOMMU_CMD_BUFFER_BASE_LOW_OFFSET: 
+            u64_to_reg(&iommu->cmd_buffer.reg_base, val);
+            break;
+        case IOMMU_EVENT_LOG_BASE_LOW_OFFSET:
+            u64_to_reg(&iommu->event_log.reg_base, val);
+        case IOMMU_PPR_LOG_BASE_LOW_OFFSET:
+            u64_to_reg(&iommu->ppr_log.reg_base, val);
+            break;
+        case IOMMU_CONTROL_MMIO_OFFSET:
+            guest_iommu_write_ctrl(iommu, val);
+            break;
+        case IOMMU_CMD_BUFFER_HEAD_OFFSET:
+            u64_to_reg(&iommu->cmd_buffer.reg_head, val);
+            break;
+        case IOMMU_CMD_BUFFER_TAIL_OFFSET:
+            u64_to_reg(&iommu->cmd_buffer.reg_tail, val);
+            tasklet_schedule(&iommu->cmd_buffer_tasklet);
+            break;
+        case IOMMU_EVENT_LOG_HEAD_OFFSET:
+            u64_to_reg(&iommu->event_log.reg_head, val);
+            break;
+        case IOMMU_EVENT_LOG_TAIL_OFFSET:
+            u64_to_reg(&iommu->event_log.reg_tail, val);
+            break;
+        case IOMMU_PPR_LOG_HEAD_OFFSET:
+            u64_to_reg(&iommu->ppr_log.reg_head, val);
+            break;
+        case IOMMU_PPR_LOG_TAIL_OFFSET:
+            u64_to_reg(&iommu->ppr_log.reg_tail, val);
+            break;
+        case IOMMU_STATUS_MMIO_OFFSET:
+            u64_to_reg(&iommu->reg_status, val);
+            break;
+
+        default:
+            AMD_IOMMU_DEBUG("guest writes unknown mmio offset = %lx, "
+                            "val = %lx\n", offset, val);
+            break;
+    }
+}
+
+static int guest_iommu_mmio_write(struct vcpu *v, unsigned long addr,
+                                  unsigned long len, unsigned long val)
+{
+    struct guest_iommu *iommu = vcpu_iommu(v);
+    unsigned long offset;
+    uint64_t reg_old, mmio;
+    uint32_t shift;
+    uint64_t mask = 0;
+
+    offset = addr - iommu->mmio_base;
+
+    if ( unlikely((offset & (len - 1 )) || (len > 8)) )
+    {
+        AMD_IOMMU_DEBUG("iommu mmio write access is not aligned." 
+                        "offset = %lx, len = %lx \n", offset, len);
+        return X86EMUL_UNHANDLEABLE;
+    }
+
+    mask = (len == 8) ? (~0ULL): (1ULL << (len * 8)) - 1;
+    shift = (offset & 7u) * 8;
+
+    /* mmio access is always aligned on 8-byte boundary */
+    mmio = offset & (~7u);
+
+    spin_lock(&iommu->lock);
+
+    reg_old = iommu_mmio_read64(iommu, mmio);
+    reg_old &= ~( mask << shift );
+    val = reg_old | ((val & mask) << shift );
+    guest_iommu_mmio_write64(iommu, mmio, val);
+
+    spin_unlock(&iommu->lock);
+
+    return X86EMUL_OKAY;
+}
+
+int guest_iommu_set_base(struct domain *d, uint64_t base)
+{
+    p2m_type_t t;
+    struct guest_iommu *iommu = domain_iommu(d);
+
+    iommu->mmio_base = base;
+    base >>= PAGE_SHIFT;
+
+    for ( int i = 0; i < IOMMU_MMIO_PAGE_NR; i++ )
+    {
+        unsigned long gfn = base + i;
+
+        get_gfn_query(d, gfn, &t);
+        p2m_change_type(d, gfn, t, p2m_mmio_dm);
+        put_gfn(d, gfn);
+    }
+
+    return 0;
+}
+
+/* Initialize mmio read only bits */
+static void guest_iommu_reg_init(struct guest_iommu *iommu)
+{
+    uint32_t lower, upper;
+
+    lower = upper = 0;
+    /* Support prefetch */
+    iommu_set_bit(&lower,IOMMU_EXT_FEATURE_PREFSUP_SHIFT);
+    /* Support PPR log */
+    iommu_set_bit(&lower,IOMMU_EXT_FEATURE_PPRSUP_SHIFT);
+    /* Support guest translation */
+    iommu_set_bit(&lower,IOMMU_EXT_FEATURE_GTSUP_SHIFT);
+    /* Support invalidate all command */
+    iommu_set_bit(&lower,IOMMU_EXT_FEATURE_IASUP_SHIFT);
+
+    /* Host translation size has 6 levels */
+    set_field_in_reg_u32(HOST_ADDRESS_SIZE_6_LEVEL, lower,
+                         IOMMU_EXT_FEATURE_HATS_MASK,
+                         IOMMU_EXT_FEATURE_HATS_SHIFT,
+                         &lower);
+    /* Guest translation size has 6 levels */
+    set_field_in_reg_u32(GUEST_ADDRESS_SIZE_6_LEVEL, lower,
+                         IOMMU_EXT_FEATURE_GATS_MASK,
+                         IOMMU_EXT_FEATURE_GATS_SHIFT,
+                         &lower);
+    /* Single level gCR3 */
+    set_field_in_reg_u32(GUEST_CR3_1_LEVEL, lower, 
+                         IOMMU_EXT_FEATURE_GLXSUP_MASK,
+                         IOMMU_EXT_FEATURE_GLXSUP_SHIFT, &lower);
+    /* 9 bit PASID */
+    set_field_in_reg_u32(PASMAX_9_bit, upper, 
+                         IOMMU_EXT_FEATURE_PASMAX_MASK,
+                         IOMMU_EXT_FEATURE_PASMAX_SHIFT, &upper);
+
+    iommu->reg_ext_feature.lo = lower;
+    iommu->reg_ext_feature.hi = upper;
+}
+
+/* Domain specific initialization */
+int guest_iommu_init(struct domain* d)
+{
+    struct guest_iommu *iommu;
+    struct hvm_iommu *hd  = domain_hvm_iommu(d);
+
+    if ( !is_hvm_domain(d) )
+        return 0;
+
+    iommu = xzalloc(struct guest_iommu);
+    if ( !iommu )
+    {
+        AMD_IOMMU_DEBUG("Error allocating guest iommu structure.\n");
+        return 1;
+    }
+
+    guest_iommu_reg_init(iommu);
+    iommu->domain = d;
+    hd->g_iommu = iommu;
+
+    tasklet_init(&iommu->cmd_buffer_tasklet,
+                 guest_iommu_process_command, (unsigned long)d);
+
+    spin_lock_init(&iommu->lock);
+
+    INIT_LIST_HEAD(&iommu->dev_table.page_list);
+    INIT_LIST_HEAD(&iommu->cmd_buffer.page_list);
+    INIT_LIST_HEAD(&iommu->event_log.page_list);
+    INIT_LIST_HEAD(&iommu->ppr_log.page_list);
+
+    return 0;
+}
+
+static void guest_iommu_deallocate(struct list_head *page_list)
+{
+    struct guest_pages *cur, *next; 
+
+    list_for_each_entry_safe(cur, next, page_list, list)
+    {
+        list_del(&cur->list);
+        xfree(cur);
+    }
+}
+
+void guest_iommu_destroy(struct domain *d)
+{
+    struct guest_iommu *iommu;
+
+    if ( !is_hvm_domain(d) )
+        return;
+
+    iommu = domain_iommu(d);
+
+    guest_iommu_deallocate(&iommu->dev_table.page_list);
+    guest_iommu_deallocate(&iommu->cmd_buffer.page_list);
+    guest_iommu_deallocate(&iommu->event_log.page_list);
+    guest_iommu_deallocate(&iommu->ppr_log.page_list);
+
+    tasklet_kill(&iommu->cmd_buffer_tasklet);
+}
+
+static int guest_iommu_mmio_range(struct vcpu *v, unsigned long addr)
+{
+    struct guest_iommu *iommu = vcpu_iommu(v);
+
+    return ( addr >= iommu->mmio_base && 
+             addr < (iommu->mmio_base + IOMMU_MMIO_SIZE) );
+}
+
+const struct hvm_mmio_handler iommu_mmio_handler = {
+    .check_handler = guest_iommu_mmio_range,
+    .read_handler = guest_iommu_mmio_read,
+    .write_handler = guest_iommu_mmio_write
+};
diff -r b190e3362524 -r ea52a2b93dff xen/drivers/passthrough/amd/iommu_map.c
--- a/xen/drivers/passthrough/amd/iommu_map.c	Wed Dec 14 12:51:22 2011 +0100
+++ b/xen/drivers/passthrough/amd/iommu_map.c	Wed Dec 14 12:58:17 2011 +0100
@@ -234,6 +234,53 @@ void __init iommu_dte_add_device_entry(u
     dte[3] = entry;
 }
 
+void iommu_dte_set_guest_cr3(u32 *dte, u16 dom_id, u64 gcr3, 
+                             int gv, unsigned int glx)
+{
+    u32 entry, gcr3_1, gcr3_2, gcr3_3;
+
+    gcr3_3 = gcr3 >> 31;
+    gcr3_2 = (gcr3 >> 15) & 0xFFFF;
+    gcr3_1 = (gcr3 >> PAGE_SHIFT) & 0x7;
+
+    /* I bit must be set when gcr3 is enabled */
+    entry = dte[3];
+    set_field_in_reg_u32(IOMMU_CONTROL_ENABLED, entry,
+                         IOMMU_DEV_TABLE_IOTLB_SUPPORT_MASK,
+                         IOMMU_DEV_TABLE_IOTLB_SUPPORT_SHIFT, &entry);
+    /* update gcr3 */
+    set_field_in_reg_u32(gcr3_3, entry,
+                         IOMMU_DEV_TABLE_GCR3_3_MASK,
+                         IOMMU_DEV_TABLE_GCR3_3_SHIFT, &entry);
+    dte[3] = entry;
+
+    set_field_in_reg_u32(dom_id, entry,
+                         IOMMU_DEV_TABLE_DOMAIN_ID_MASK,
+                         IOMMU_DEV_TABLE_DOMAIN_ID_SHIFT, &entry);
+    /* update gcr3 */
+    entry = dte[2];
+    set_field_in_reg_u32(gcr3_2, entry,
+                         IOMMU_DEV_TABLE_GCR3_2_MASK,
+                         IOMMU_DEV_TABLE_GCR3_2_SHIFT, &entry);
+    dte[2] = entry;
+
+    entry = dte[1];
+    /* Enable GV bit */
+    set_field_in_reg_u32(!!gv, entry,
+                         IOMMU_DEV_TABLE_GV_MASK,
+                         IOMMU_DEV_TABLE_GV_SHIFT, &entry);
+
+    /* 1 level guest cr3 table  */
+    set_field_in_reg_u32(glx, entry,
+                         IOMMU_DEV_TABLE_GLX_MASK,
+                         IOMMU_DEV_TABLE_GLX_SHIFT, &entry);
+    /* update gcr3 */
+    set_field_in_reg_u32(gcr3_1, entry,
+                         IOMMU_DEV_TABLE_GCR3_1_MASK,
+                         IOMMU_DEV_TABLE_GCR3_1_SHIFT, &entry);
+    dte[1] = entry;
+}
+
 u64 amd_iommu_get_next_table_from_pte(u32 *entry)
 {
     u64 addr_lo, addr_hi, ptr;
diff -r b190e3362524 -r ea52a2b93dff xen/drivers/passthrough/amd/pci_amd_iommu.c
--- a/xen/drivers/passthrough/amd/pci_amd_iommu.c	Wed Dec 14 12:51:22 2011 +0100
+++ b/xen/drivers/passthrough/amd/pci_amd_iommu.c	Wed Dec 14 12:58:17 2011 +0100
@@ -260,6 +260,8 @@ static int amd_iommu_domain_init(struct 
 
     hd->domain_id = d->domain_id;
 
+    guest_iommu_init(d);
+
     return 0;
 }
 
@@ -443,6 +445,7 @@ static void deallocate_iommu_page_tables
 
 static void amd_iommu_domain_destroy(struct domain *d)
 {
+    guest_iommu_destroy(d);
     deallocate_iommu_page_tables(d);
     amd_iommu_flush_all_pages(d);
 }
diff -r b190e3362524 -r ea52a2b93dff xen/include/asm-x86/amd-iommu.h
--- a/xen/include/asm-x86/amd-iommu.h	Wed Dec 14 12:51:22 2011 +0100
+++ b/xen/include/asm-x86/amd-iommu.h	Wed Dec 14 12:58:17 2011 +0100
@@ -24,6 +24,7 @@
 #include <xen/types.h>
 #include <xen/list.h>
 #include <xen/spinlock.h>
+#include <xen/tasklet.h>
 #include <asm/hvm/svm/amd-iommu-defs.h>
 
 #define iommu_found()           (!list_empty(&amd_iommu_head))
@@ -130,4 +131,62 @@ struct ivrs_mappings *get_ivrs_mappings(
 int iterate_ivrs_mappings(int (*)(u16 seg, struct ivrs_mappings *));
 int iterate_ivrs_entries(int (*)(u16 seg, struct ivrs_mappings *));
 
+/* iommu tables in guest space */
+struct guest_pages {
+    struct list_head list;
+    struct page_info *page;
+};
+
+struct mmio_reg {
+    uint32_t    lo;
+    uint32_t    hi;
+};
+
+struct guest_dev_table {
+    struct list_head        page_list;
+    struct mmio_reg         reg_base;
+    uint32_t                size;
+};
+
+struct guest_buffer {
+    struct list_head        page_list;
+    struct mmio_reg         reg_base;
+    struct mmio_reg         reg_tail;
+    struct mmio_reg         reg_head;
+    uint32_t                entries;
+};
+
+struct guest_iommu_msi {
+    uint8_t                 vector;
+    uint8_t                 dest;
+    uint8_t                 dest_mode;
+    uint8_t                 delivery_mode;
+    uint8_t                 trig_mode;
+};
+
+/* virtual IOMMU structure */
+struct guest_iommu {
+
+    struct domain          *domain;
+    spinlock_t              lock;
+    bool_t                  enabled;
+
+    struct guest_dev_table  dev_table;
+    struct guest_buffer     cmd_buffer;
+    struct guest_buffer     event_log;
+    struct guest_buffer     ppr_log;
+
+    struct tasklet          cmd_buffer_tasklet;
+
+    uint64_t                mmio_base;             /* MMIO base address */
+
+    /* MMIO regs */
+    struct mmio_reg         reg_ctrl;              /* MMIO offset 0018h */
+    struct mmio_reg         reg_status;            /* MMIO offset 2020h */
+    struct mmio_reg         reg_ext_feature;       /* MMIO offset 0030h */
+
+    /* guest interrupt settings */
+    struct guest_iommu_msi  msi;
+};
+
 #endif /* _ASM_X86_64_AMD_IOMMU_H */
diff -r b190e3362524 -r ea52a2b93dff xen/include/asm-x86/hvm/svm/amd-iommu-defs.h
--- a/xen/include/asm-x86/hvm/svm/amd-iommu-defs.h	Wed Dec 14 12:51:22 2011 +0100
+++ b/xen/include/asm-x86/hvm/svm/amd-iommu-defs.h	Wed Dec 14 12:58:17 2011 +0100
@@ -117,6 +117,13 @@
 #define IOMMU_DEV_TABLE_PAGE_TABLE_PTR_LOW_SHIFT	12
 
 /* DeviceTable Entry[63:32] */
+#define IOMMU_DEV_TABLE_GV_SHIFT                    23
+#define IOMMU_DEV_TABLE_GV_MASK                     0x800000
+#define IOMMU_DEV_TABLE_GLX_SHIFT                   24
+#define IOMMU_DEV_TABLE_GLX_MASK                    0x3000000
+#define IOMMU_DEV_TABLE_GCR3_1_SHIFT                26
+#define IOMMU_DEV_TABLE_GCR3_1_MASK                 0x1c000000
+
 #define IOMMU_DEV_TABLE_PAGE_TABLE_PTR_HIGH_MASK	0x000FFFFF
 #define IOMMU_DEV_TABLE_PAGE_TABLE_PTR_HIGH_SHIFT	0
 #define IOMMU_DEV_TABLE_IO_READ_PERMISSION_MASK		0x20000000
@@ -127,6 +134,8 @@
 /* DeviceTable Entry[95:64] */
 #define IOMMU_DEV_TABLE_DOMAIN_ID_MASK	0x0000FFFF
 #define IOMMU_DEV_TABLE_DOMAIN_ID_SHIFT	0
+#define IOMMU_DEV_TABLE_GCR3_2_SHIFT                16
+#define IOMMU_DEV_TABLE_GCR3_2_MASK                 0xFFFF0000
 
 /* DeviceTable Entry[127:96] */
 #define IOMMU_DEV_TABLE_IOTLB_SUPPORT_MASK		0x00000001
@@ -155,6 +164,8 @@
 #define IOMMU_DEV_TABLE_INT_TABLE_IGN_UNMAPPED_SHIFT      5
 #define IOMMU_DEV_TABLE_INT_TABLE_PTR_LOW_MASK      0xFFFFFFC0
 #define IOMMU_DEV_TABLE_INT_TABLE_PTR_LOW_SHIFT     6
+#define IOMMU_DEV_TABLE_GCR3_3_SHIFT                11
+#define IOMMU_DEV_TABLE_GCR3_3_MASK                 0xfffff800
 
 /* DeviceTable Entry[191:160] */
 #define IOMMU_DEV_TABLE_INT_TABLE_PTR_HIGH_MASK     0x000FFFFF
@@ -164,7 +175,6 @@
 #define IOMMU_DEV_TABLE_INT_CONTROL_MASK        0x30000000
 #define IOMMU_DEV_TABLE_INT_CONTROL_SHIFT       28
 
-
 /* Command Buffer */
 #define IOMMU_CMD_BUFFER_BASE_LOW_OFFSET	0x08
 #define IOMMU_CMD_BUFFER_BASE_HIGH_OFFSET	0x0C
@@ -192,6 +202,7 @@
 #define IOMMU_CMD_INVALIDATE_IOMMU_PAGES	0x3
 #define IOMMU_CMD_INVALIDATE_IOTLB_PAGES	0x4
 #define IOMMU_CMD_INVALIDATE_INT_TABLE		0x5
+#define IOMMU_CMD_COMPLETE_PPR_REQUEST      0x7
 #define IOMMU_CMD_INVALIDATE_IOMMU_ALL      0x8
 
 /* COMPLETION_WAIT command */
@@ -282,6 +293,28 @@
 #define IOMMU_EVENT_DEVICE_ID_MASK           0x0000FFFF
 #define IOMMU_EVENT_DEVICE_ID_SHIFT          0
 
+/* PPR Log */
+#define IOMMU_PPR_LOG_ENTRY_SIZE                        16
+#define IOMMU_PPR_LOG_POWER_OF2_ENTRIES_PER_PAGE        8
+#define IOMMU_PPR_LOG_U32_PER_ENTRY   (IOMMU_PPR_LOG_ENTRY_SIZE / 4)
+
+#define IOMMU_PPR_LOG_BASE_LOW_OFFSET                   0x0038
+#define IOMMU_PPR_LOG_BASE_HIGH_OFFSET                  0x003C
+#define IOMMU_PPR_LOG_BASE_LOW_MASK                     0xFFFFF000
+#define IOMMU_PPR_LOG_BASE_LOW_SHIFT                    12
+#define IOMMU_PPR_LOG_BASE_HIGH_MASK                    0x000FFFFF
+#define IOMMU_PPR_LOG_BASE_HIGH_SHIFT                   0
+#define IOMMU_PPR_LOG_LENGTH_MASK                       0x0F000000
+#define IOMMU_PPR_LOG_LENGTH_SHIFT                      24
+#define IOMMU_PPR_LOG_HEAD_MASK                         0x0007FFF0
+#define IOMMU_PPR_LOG_HEAD_SHIFT                        4
+#define IOMMU_PPR_LOG_TAIL_MASK                         0x0007FFF0
+#define IOMMU_PPR_LOG_TAIL_SHIFT                        4
+#define IOMMU_PPR_LOG_HEAD_OFFSET                       0x2030
+#define IOMMU_PPR_LOG_TAIL_OFFSET                       0x2038
+#define IOMMU_PPR_LOG_DEVICE_ID_MASK                    0x0000FFFF
+#define IOMMU_PPR_LOG_DEVICE_ID_SHIFT                   0
+
 /* Control Register */
 #define IOMMU_CONTROL_MMIO_OFFSET			0x18
 #define IOMMU_CONTROL_TRANSLATION_ENABLE_MASK		0x00000001
@@ -309,6 +342,11 @@
 #define IOMMU_CONTROL_RESTART_MASK			0x80000000
 #define IOMMU_CONTROL_RESTART_SHIFT			31
 
+#define IOMMU_CONTROL_PPR_LOG_ENABLE_SHIFT      13
+#define IOMMU_CONTROL_PPR_INT_SHIFT             14
+#define IOMMU_CONTROL_PPR_ENABLE_SHIFT          15
+#define IOMMU_CONTROL_GT_ENABLE_SHIFT           16
+
 /* Exclusion Register */
 #define IOMMU_EXCLUSION_BASE_LOW_OFFSET		0x20
 #define IOMMU_EXCLUSION_BASE_HIGH_OFFSET	0x24
@@ -342,7 +380,8 @@
 #define IOMMU_EXT_FEATURE_HATS_MASK                     0x00000C00
 #define IOMMU_EXT_FEATURE_GATS_SHIFT                    0x12
 #define IOMMU_EXT_FEATURE_GATS_MASK                     0x00003000
-#define IOMMU_EXT_FEATURE_GLXSUP                        0x14
+#define IOMMU_EXT_FEATURE_GLXSUP_SHIFT                  0x14
+#define IOMMU_EXT_FEATURE_GLXSUP_MASK                   0x0000C000
 
 #define IOMMU_EXT_FEATURE_PASMAX_SHIFT                  0x0
 #define IOMMU_EXT_FEATURE_PASMAX_MASK                   0x0000001F
@@ -359,6 +398,9 @@
 #define IOMMU_STATUS_EVENT_LOG_RUN_SHIFT	3
 #define IOMMU_STATUS_CMD_BUFFER_RUN_MASK	0x00000010
 #define IOMMU_STATUS_CMD_BUFFER_RUN_SHIFT	4
+#define IOMMU_STATUS_PPR_LOG_OVERFLOW_SHIFT     5
+#define IOMMU_STATUS_PPR_LOG_INT_SHIFT          6
+#define IOMMU_STATUS_PPR_LOG_RUN_SHIFT          7
 
 /* I/O Page Table */
 #define IOMMU_PAGE_TABLE_ENTRY_SIZE	8
diff -r b190e3362524 -r ea52a2b93dff xen/include/asm-x86/hvm/svm/amd-iommu-proto.h
--- a/xen/include/asm-x86/hvm/svm/amd-iommu-proto.h	Wed Dec 14 12:51:22 2011 +0100
+++ b/xen/include/asm-x86/hvm/svm/amd-iommu-proto.h	Wed Dec 14 12:58:17 2011 +0100
@@ -71,6 +71,8 @@ void amd_iommu_set_root_page_table(
     u32 *dte, u64 root_ptr, u16 domain_id, u8 paging_mode, u8 valid);
 void iommu_dte_set_iotlb(u32 *dte, u8 i);
 void iommu_dte_add_device_entry(u32 *dte, struct ivrs_mappings *ivrs_dev);
+void iommu_dte_set_guest_cr3(u32 *dte, u16 dom_id, u64 gcr3, 
+                             int gv, unsigned int glx);
 
 /* send cmd to iommu */
 void amd_iommu_flush_all_pages(struct domain *d);
@@ -106,6 +108,14 @@ void amd_iommu_resume(void);
 void amd_iommu_suspend(void);
 void amd_iommu_crash_shutdown(void);
 
+/* guest iommu support */
+void amd_iommu_send_guest_cmd(struct amd_iommu *iommu, u32 cmd[]);
+void guest_iommu_add_ppr_log(struct domain *d, u32 entry[]);
+void guest_iommu_add_event_log(struct domain *d, u32 entry[]);
+int guest_iommu_init(struct domain* d);
+void guest_iommu_destroy(struct domain *d);
+int guest_iommu_set_base(struct domain *d, uint64_t base);
+
 static inline u32 get_field_from_reg_u32(u32 reg_value, u32 mask, u32 shift)
 {
     u32 field;
diff -r b190e3362524 -r ea52a2b93dff xen/include/xen/hvm/iommu.h
--- a/xen/include/xen/hvm/iommu.h	Wed Dec 14 12:51:22 2011 +0100
+++ b/xen/include/xen/hvm/iommu.h	Wed Dec 14 12:58:17 2011 +0100
@@ -47,6 +47,7 @@ struct hvm_iommu {
     int domain_id;
     int paging_mode;
     struct page_info *root_table;
+    struct guest_iommu *g_iommu;
 
     /* iommu_ops */
     const struct iommu_ops *platform_ops;


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 15:38:19 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 15:38:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaquN-0004OO-SI; Wed, 14 Dec 2011 15:38:15 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Wang2@amd.com>) id 1RaquM-0004Kw-9V
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 15:38:14 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1323877036!6728710!1
X-Originating-IP: [65.55.88.14]
X-SpamReason: No, hits=3.0 required=7.0 tests=ML_RADAR_551,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14432 invoked from network); 14 Dec 2011 15:37:18 -0000
Received: from tx2ehsobe004.messaging.microsoft.com (HELO
	TX2EHSOBE007.bigfish.com) (65.55.88.14)
	by server-13.tower-182.messagelabs.com with AES128-SHA encrypted SMTP;
	14 Dec 2011 15:37:18 -0000
Received: from mail113-tx2-R.bigfish.com (10.9.14.249) by
	TX2EHSOBE007.bigfish.com (10.9.40.27) with Microsoft SMTP Server id
	14.1.225.23; Wed, 14 Dec 2011 15:37:19 +0000
Received: from mail113-tx2 (localhost [127.0.0.1])	by
	mail113-tx2-R.bigfish.com (Postfix) with ESMTP id C522E1800CF;
	Wed, 14 Dec 2011 15:37:19 +0000 (UTC)
X-SpamScore: -4
X-BigFish: VPS-4(zzc85fh4015Lzz1202hzz8275bhz2dh668h839h34h61h)
X-Spam-TCS-SCL: 0:0
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
Received: from mail113-tx2 (localhost.localdomain [127.0.0.1]) by mail113-tx2
	(MessageSwitch) id 1323877030735784_19804;
	Wed, 14 Dec 2011 15:37:10 +0000 (UTC)
Received: from TX2EHSMHS017.bigfish.com (unknown [10.9.14.236])	by
	mail113-tx2.bigfish.com (Postfix) with ESMTP id 57264580064;
	Wed, 14 Dec 2011 15:37:10 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	TX2EHSMHS017.bigfish.com (10.9.99.117) with Microsoft SMTP Server id
	14.1.225.23; Wed, 14 Dec 2011 15:36:05 +0000
X-WSS-ID: 0LW79ZZ-02-ADA-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp02.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 29D88C807C;	Wed, 14 Dec 2011 09:35:58 -0600 (CST)
Received: from SAUSEXDAG01.amd.com (163.181.55.1) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Wed, 14 Dec 2011 09:36:12 -0600
Received: from storexhtp01.amd.com (172.24.4.3) by sausexdag01.amd.com
	(163.181.55.1) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Wed, 14 Dec 2011 09:36:00 -0600
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp01.amd.com
	(172.24.4.3) with Microsoft SMTP Server id 8.3.213.0; Wed, 14 Dec 2011
	10:35:22 -0500
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id C386949C1FF; Wed, 14 Dec 2011
	15:35:21 +0000 (GMT)
Received: from gran.osrc.amd.com (gran.osrc.amd.com [165.204.15.57])	by
	mail.osrc.amd.com (Postfix) with ESMTP id BD8775940FF; Wed, 14 Dec 2011
	16:35:21 +0100 (CET)
From: Wei Wang2 <wei.wang2@amd.com>
To: <xen-devel@lists.xensource.com>
Date: Wed, 14 Dec 2011 16:38:04 +0100
User-Agent: KMail/1.9.6 (enterprise 20070904.708012)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="Boundary-00=_dLM6OQaNecaPwVj"
Message-ID: <201112141638.05345.wei.wang2@amd.com>
X-OriginatorOrg: amd.com
Cc: Keir Fraser <keir@xen.org>, Jan Beulich <JBeulich@suse.com>
Subject: [Xen-devel] [PATCH] xen-qemu: register virtual iommu device on qemu
	pci bus
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--Boundary-00=_dLM6OQaNecaPwVj
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Attached patch is for qemu to register iommu device on pci bus. Guest OS 
requires this to access iommu pci config space in some cases.
Thanks,
Wei

Signed-off-by: Wei Wang <wei.wang2@amd.com>

--Boundary-00=_dLM6OQaNecaPwVj
Content-Type: text/x-diff; charset="us-ascii"; name="qemu-iommuv2.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="qemu-iommuv2.diff"
Content-Description: qemu-iommuv2.diff

diff --git a/hw/pass-through.c b/hw/pass-through.c
index 919937f..d6f35d8 100644
--- a/hw/pass-through.c
+++ b/hw/pass-through.c
@@ -4402,5 +4414,94 @@ int pt_init(PCIBus *e_bus)
     memset(&dpci_infos, 0, sizeof(struct dpci_infos));
     dpci_infos.e_bus      = e_bus;
 
+    amd_iommu_init(e_bus);
     return 0;
 }
+
+static void amd_iommu_pci_write_config(PCIDevice *d, uint32_t address,
+                                       uint32_t val, int len)
+{
+    struct amd_iommu_config *iommu_config;
+    uint64_t msi_addr;
+    uint32_t msi_data;
+    uint8_t offset_msi_data, vector, en;
+    uint8_t dest_mode, dest, delivery_mode, trig_mode;
+
+    pci_default_write_config(d, address, val, len);
+
+    iommu_config = (struct amd_iommu_config *)d->config;
+
+    offset_msi_data = iommu_config->cap.next_ptr + sizeof(uint32_t) +
+                      sizeof(uint64_t);
+
+    if ( address == offset_msi_data )
+    {
+        msi_addr = (uint64_t)iommu_config->msi.addr_high << 32 | 
+                   iommu_config->msi.addr_low;
+        msi_data = val;
+        vector = msi_data & 0xFF;
+        en = iommu_config->msi.msg_ctrl & 0x1;
+
+        if ( !vector || !en )
+            return;
+
+        dest_mode = (msi_addr >> MSI_ADDR_DESTMODE_SHIFT) & 0x1;
+        dest = (msi_addr >> MSI_TARGET_CPU_SHIFT) & 0xff;
+        delivery_mode = (msi_data >> MSI_DATA_DELIVERY_SHIFT) & 0x7;
+        trig_mode = (msi_data >> MSI_DATA_TRIGGER_SHIFT) & 0x1;
+
+        xc_domain_update_iommu_msi(xc_handle, domid, vector, dest, 
+                                   dest_mode, delivery_mode, trig_mode);
+    }
+}
+
+#ifndef PCI_CAP_ID_SEC
+#define PCI_CAP_ID_SEC                  0x0F
+#endif
+#define PCI_CLASS_SYSTEM_AMD_IOMMU      0x0806
+#define PCI_DEVICE_AMD_IOMMU_V2         0xFFFF
+#define IOMMU_CAP_FLAGS_IOTLB           0
+#define IOMMU_CAP_FLAGS_EFRSUP          3
+#define IOMMU_CAP_TYPE                  0x3
+#define IOMMU_CAP_REV                   0x1
+
+extern int guest_iommu;
+void amd_iommu_init(PCIBus *bus)
+{
+    PCIDevice *amd_iommu;
+    struct amd_iommu_config *cfg;
+    struct pt_dev *assigned_device = NULL;
+
+    if ( !guest_iommu )
+        return;
+
+    amd_iommu = pci_register_device(bus, "AMD IOMMU v2", 
+                                    sizeof(struct PCIDevice), -1,
+                                    NULL, amd_iommu_pci_write_config);
+    if ( amd_iommu == NULL )
+    {
+        PT_LOG("Error: couldn't register amd iommu device\n");
+        return;
+    }
+
+    cfg = (struct amd_iommu_config *)amd_iommu->config;
+
+    pci_config_set_vendor_id((uint8_t *)cfg, PCI_VENDOR_ID_AMD);
+    pci_config_set_device_id((uint8_t *)cfg, PCI_DEVICE_AMD_IOMMU_V2);
+    pci_config_set_class((uint8_t *)cfg, PCI_CLASS_SYSTEM_AMD_IOMMU);
+
+    cfg->status       =   PCI_STATUS_CAPABILITIES;
+    cfg->cap_ptr      =   sizeof(struct amd_iommu_config) - 
+                          sizeof(iommu_capability_t)- sizeof(msi_capability_t);
+
+    cfg->cap.id       = PCI_CAP_ID_SEC;
+    cfg->cap.cap_info = IOMMU_CAP_REV << 3 | IOMMU_CAP_TYPE;
+
+    cfg->cap.flags   |= 1 << IOMMU_CAP_FLAGS_IOTLB;
+    cfg->cap.flags   |= 1 << IOMMU_CAP_FLAGS_EFRSUP;
+
+    cfg->cap.next_ptr = cfg->cap_ptr + sizeof(iommu_capability_t);
+    cfg->msi.id       = PCI_CAP_ID_MSI;
+    cfg->msi.msg_ctrl = PCI_MSI_FLAGS_64BIT;
+}
+
diff --git a/hw/pass-through.h b/hw/pass-through.h
index 884139c..c089987 100644
--- a/hw/pass-through.h
+++ b/hw/pass-through.h
@@ -402,6 +402,58 @@ struct pt_reg_info_tbl {
     } u;
 };
 
+#pragma pack(1)
+/* AMD IOMMU v2 support */
+typedef struct iommu_capability_block {
+    uint8_t     id;
+    uint8_t     next_ptr;
+    uint8_t     cap_info;
+    uint8_t     flags;
+    uint32_t    base_low;
+    uint32_t    base_high;
+    uint32_t    range;
+    uint32_t    misc;
+} iommu_capability_t;
+
+typedef struct msi_capability_block {
+    uint8_t     id;
+    uint8_t     next_ptr;
+    uint16_t    msg_ctrl;
+    uint32_t    addr_low;
+    uint32_t    addr_high;
+    uint32_t    msi_data;
+} msi_capability_t;
+
+struct amd_iommu_config {
+    uint16_t    vendor_id;
+    uint16_t    device_id;
+    uint16_t    command;
+    uint16_t    status;
+    uint8_t     revision;
+    uint8_t     api;
+    uint8_t     subclass;
+    uint8_t     class;
+    uint8_t     cache_line_size;
+    uint8_t     latency_timer;
+    uint8_t     header_type;
+    uint8_t     bist;
+    uint32_t    base_address_regs[6];
+    uint32_t    reserved1;
+    uint16_t    subsystem_vendor_id;
+    uint16_t    subsystem_id;
+    uint32_t    rom_addr;
+    uint8_t     cap_ptr;
+    uint8_t     reserved3[3];
+    uint32_t    reserved4;
+    uint8_t     interrupt_line;
+    uint8_t     interrupt_pin;
+    uint8_t     min_gnt;
+    uint8_t     max_lat;
+    iommu_capability_t cap;
+    msi_capability_t   msi;
+};
+#pragma pack()
+
 static inline pciaddr_t pt_pci_base_addr(pciaddr_t base)
 {
     if ( base & PCI_ADDRESS_SPACE_IO )
@@ -422,6 +474,6 @@ PCIBus *intel_pci_bridge_init(PCIBus *bus, int devfn, uint16_t vid,
            uint16_t did, const char *name, uint16_t revision);
 void igd_pci_write(PCIDevice *pci_dev, uint32_t config_addr, uint32_t val, int len);
 uint32_t igd_pci_read(PCIDevice *pci_dev, uint32_t config_addr, int len);
-
+void amd_iommu_init(PCIBus *bus);
 #endif /* __PASSTHROUGH_H__ */
 
diff --git a/vl.c b/vl.c
index be8587a..43a0111 100644
--- a/vl.c
+++ b/vl.c
@@ -217,6 +217,7 @@ int cirrus_vga_enabled = 1;
 int std_vga_enabled = 0;
 int vmsvga_enabled = 0;
 int gfx_passthru = 0;
+int guest_iommu = 0;
 #ifdef TARGET_SPARC
 int graphic_width = 1024;
 int graphic_height = 768;
@@ -4295,6 +4296,7 @@ enum {
     QEMU_OPTION_acpi,
     QEMU_OPTION_vcpus,
     QEMU_OPTION_vcpu_avail,
+    QEMU_OPTION_guest_iommu,
 
     /* Debug/Expert options: */
     QEMU_OPTION_serial,
@@ -4468,6 +4470,7 @@ static const QEMUOption qemu_options[] = {
     { "vncunused", 0, QEMU_OPTION_vncunused },
     { "vcpus", HAS_ARG, QEMU_OPTION_vcpus },
     { "vcpu_avail", HAS_ARG, QEMU_OPTION_vcpu_avail },
+    { "iommu", 0, QEMU_OPTION_guest_iommu},
 #if defined(CONFIG_XEN) && !defined(CONFIG_DM)
     { "xen-domid", HAS_ARG, QEMU_OPTION_xen_domid },
     { "xen-create", 0, QEMU_OPTION_xen_create },
@@ -5595,6 +5598,9 @@ int main(int argc, char **argv, char **envp)
             case QEMU_OPTION_gfx_passthru:
                 select_vgahw("passthrough");
                 break;
+            case QEMU_OPTION_guest_iommu:
+                guest_iommu = 1;
+                break;
             }
         }
     }

--Boundary-00=_dLM6OQaNecaPwVj
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--Boundary-00=_dLM6OQaNecaPwVj--


From xen-devel-bounces@lists.xensource.com Wed Dec 14 15:38:19 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 15:38:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaquN-0004OO-SI; Wed, 14 Dec 2011 15:38:15 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Wang2@amd.com>) id 1RaquM-0004Kw-9V
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 15:38:14 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1323877036!6728710!1
X-Originating-IP: [65.55.88.14]
X-SpamReason: No, hits=3.0 required=7.0 tests=ML_RADAR_551,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14432 invoked from network); 14 Dec 2011 15:37:18 -0000
Received: from tx2ehsobe004.messaging.microsoft.com (HELO
	TX2EHSOBE007.bigfish.com) (65.55.88.14)
	by server-13.tower-182.messagelabs.com with AES128-SHA encrypted SMTP;
	14 Dec 2011 15:37:18 -0000
Received: from mail113-tx2-R.bigfish.com (10.9.14.249) by
	TX2EHSOBE007.bigfish.com (10.9.40.27) with Microsoft SMTP Server id
	14.1.225.23; Wed, 14 Dec 2011 15:37:19 +0000
Received: from mail113-tx2 (localhost [127.0.0.1])	by
	mail113-tx2-R.bigfish.com (Postfix) with ESMTP id C522E1800CF;
	Wed, 14 Dec 2011 15:37:19 +0000 (UTC)
X-SpamScore: -4
X-BigFish: VPS-4(zzc85fh4015Lzz1202hzz8275bhz2dh668h839h34h61h)
X-Spam-TCS-SCL: 0:0
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
Received: from mail113-tx2 (localhost.localdomain [127.0.0.1]) by mail113-tx2
	(MessageSwitch) id 1323877030735784_19804;
	Wed, 14 Dec 2011 15:37:10 +0000 (UTC)
Received: from TX2EHSMHS017.bigfish.com (unknown [10.9.14.236])	by
	mail113-tx2.bigfish.com (Postfix) with ESMTP id 57264580064;
	Wed, 14 Dec 2011 15:37:10 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	TX2EHSMHS017.bigfish.com (10.9.99.117) with Microsoft SMTP Server id
	14.1.225.23; Wed, 14 Dec 2011 15:36:05 +0000
X-WSS-ID: 0LW79ZZ-02-ADA-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp02.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 29D88C807C;	Wed, 14 Dec 2011 09:35:58 -0600 (CST)
Received: from SAUSEXDAG01.amd.com (163.181.55.1) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Wed, 14 Dec 2011 09:36:12 -0600
Received: from storexhtp01.amd.com (172.24.4.3) by sausexdag01.amd.com
	(163.181.55.1) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Wed, 14 Dec 2011 09:36:00 -0600
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp01.amd.com
	(172.24.4.3) with Microsoft SMTP Server id 8.3.213.0; Wed, 14 Dec 2011
	10:35:22 -0500
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id C386949C1FF; Wed, 14 Dec 2011
	15:35:21 +0000 (GMT)
Received: from gran.osrc.amd.com (gran.osrc.amd.com [165.204.15.57])	by
	mail.osrc.amd.com (Postfix) with ESMTP id BD8775940FF; Wed, 14 Dec 2011
	16:35:21 +0100 (CET)
From: Wei Wang2 <wei.wang2@amd.com>
To: <xen-devel@lists.xensource.com>
Date: Wed, 14 Dec 2011 16:38:04 +0100
User-Agent: KMail/1.9.6 (enterprise 20070904.708012)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="Boundary-00=_dLM6OQaNecaPwVj"
Message-ID: <201112141638.05345.wei.wang2@amd.com>
X-OriginatorOrg: amd.com
Cc: Keir Fraser <keir@xen.org>, Jan Beulich <JBeulich@suse.com>
Subject: [Xen-devel] [PATCH] xen-qemu: register virtual iommu device on qemu
	pci bus
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--Boundary-00=_dLM6OQaNecaPwVj
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Attached patch is for qemu to register iommu device on pci bus. Guest OS 
requires this to access iommu pci config space in some cases.
Thanks,
Wei

Signed-off-by: Wei Wang <wei.wang2@amd.com>

--Boundary-00=_dLM6OQaNecaPwVj
Content-Type: text/x-diff; charset="us-ascii"; name="qemu-iommuv2.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="qemu-iommuv2.diff"
Content-Description: qemu-iommuv2.diff

diff --git a/hw/pass-through.c b/hw/pass-through.c
index 919937f..d6f35d8 100644
--- a/hw/pass-through.c
+++ b/hw/pass-through.c
@@ -4402,5 +4414,94 @@ int pt_init(PCIBus *e_bus)
     memset(&dpci_infos, 0, sizeof(struct dpci_infos));
     dpci_infos.e_bus      = e_bus;
 
+    amd_iommu_init(e_bus);
     return 0;
 }
+
+static void amd_iommu_pci_write_config(PCIDevice *d, uint32_t address,
+                                       uint32_t val, int len)
+{
+    struct amd_iommu_config *iommu_config;
+    uint64_t msi_addr;
+    uint32_t msi_data;
+    uint8_t offset_msi_data, vector, en;
+    uint8_t dest_mode, dest, delivery_mode, trig_mode;
+
+    pci_default_write_config(d, address, val, len);
+
+    iommu_config = (struct amd_iommu_config *)d->config;
+
+    offset_msi_data = iommu_config->cap.next_ptr + sizeof(uint32_t) +
+                      sizeof(uint64_t);
+
+    if ( address == offset_msi_data )
+    {
+        msi_addr = (uint64_t)iommu_config->msi.addr_high << 32 | 
+                   iommu_config->msi.addr_low;
+        msi_data = val;
+        vector = msi_data & 0xFF;
+        en = iommu_config->msi.msg_ctrl & 0x1;
+
+        if ( !vector || !en )
+            return;
+
+        dest_mode = (msi_addr >> MSI_ADDR_DESTMODE_SHIFT) & 0x1;
+        dest = (msi_addr >> MSI_TARGET_CPU_SHIFT) & 0xff;
+        delivery_mode = (msi_data >> MSI_DATA_DELIVERY_SHIFT) & 0x7;
+        trig_mode = (msi_data >> MSI_DATA_TRIGGER_SHIFT) & 0x1;
+
+        xc_domain_update_iommu_msi(xc_handle, domid, vector, dest, 
+                                   dest_mode, delivery_mode, trig_mode);
+    }
+}
+
+#ifndef PCI_CAP_ID_SEC
+#define PCI_CAP_ID_SEC                  0x0F
+#endif
+#define PCI_CLASS_SYSTEM_AMD_IOMMU      0x0806
+#define PCI_DEVICE_AMD_IOMMU_V2         0xFFFF
+#define IOMMU_CAP_FLAGS_IOTLB           0
+#define IOMMU_CAP_FLAGS_EFRSUP          3
+#define IOMMU_CAP_TYPE                  0x3
+#define IOMMU_CAP_REV                   0x1
+
+extern int guest_iommu;
+void amd_iommu_init(PCIBus *bus)
+{
+    PCIDevice *amd_iommu;
+    struct amd_iommu_config *cfg;
+    struct pt_dev *assigned_device = NULL;
+
+    if ( !guest_iommu )
+        return;
+
+    amd_iommu = pci_register_device(bus, "AMD IOMMU v2", 
+                                    sizeof(struct PCIDevice), -1,
+                                    NULL, amd_iommu_pci_write_config);
+    if ( amd_iommu == NULL )
+    {
+        PT_LOG("Error: couldn't register amd iommu device\n");
+        return;
+    }
+
+    cfg = (struct amd_iommu_config *)amd_iommu->config;
+
+    pci_config_set_vendor_id((uint8_t *)cfg, PCI_VENDOR_ID_AMD);
+    pci_config_set_device_id((uint8_t *)cfg, PCI_DEVICE_AMD_IOMMU_V2);
+    pci_config_set_class((uint8_t *)cfg, PCI_CLASS_SYSTEM_AMD_IOMMU);
+
+    cfg->status       =   PCI_STATUS_CAPABILITIES;
+    cfg->cap_ptr      =   sizeof(struct amd_iommu_config) - 
+                          sizeof(iommu_capability_t)- sizeof(msi_capability_t);
+
+    cfg->cap.id       = PCI_CAP_ID_SEC;
+    cfg->cap.cap_info = IOMMU_CAP_REV << 3 | IOMMU_CAP_TYPE;
+
+    cfg->cap.flags   |= 1 << IOMMU_CAP_FLAGS_IOTLB;
+    cfg->cap.flags   |= 1 << IOMMU_CAP_FLAGS_EFRSUP;
+
+    cfg->cap.next_ptr = cfg->cap_ptr + sizeof(iommu_capability_t);
+    cfg->msi.id       = PCI_CAP_ID_MSI;
+    cfg->msi.msg_ctrl = PCI_MSI_FLAGS_64BIT;
+}
+
diff --git a/hw/pass-through.h b/hw/pass-through.h
index 884139c..c089987 100644
--- a/hw/pass-through.h
+++ b/hw/pass-through.h
@@ -402,6 +402,58 @@ struct pt_reg_info_tbl {
     } u;
 };
 
+#pragma pack(1)
+/* AMD IOMMU v2 support */
+typedef struct iommu_capability_block {
+    uint8_t     id;
+    uint8_t     next_ptr;
+    uint8_t     cap_info;
+    uint8_t     flags;
+    uint32_t    base_low;
+    uint32_t    base_high;
+    uint32_t    range;
+    uint32_t    misc;
+} iommu_capability_t;
+
+typedef struct msi_capability_block {
+    uint8_t     id;
+    uint8_t     next_ptr;
+    uint16_t    msg_ctrl;
+    uint32_t    addr_low;
+    uint32_t    addr_high;
+    uint32_t    msi_data;
+} msi_capability_t;
+
+struct amd_iommu_config {
+    uint16_t    vendor_id;
+    uint16_t    device_id;
+    uint16_t    command;
+    uint16_t    status;
+    uint8_t     revision;
+    uint8_t     api;
+    uint8_t     subclass;
+    uint8_t     class;
+    uint8_t     cache_line_size;
+    uint8_t     latency_timer;
+    uint8_t     header_type;
+    uint8_t     bist;
+    uint32_t    base_address_regs[6];
+    uint32_t    reserved1;
+    uint16_t    subsystem_vendor_id;
+    uint16_t    subsystem_id;
+    uint32_t    rom_addr;
+    uint8_t     cap_ptr;
+    uint8_t     reserved3[3];
+    uint32_t    reserved4;
+    uint8_t     interrupt_line;
+    uint8_t     interrupt_pin;
+    uint8_t     min_gnt;
+    uint8_t     max_lat;
+    iommu_capability_t cap;
+    msi_capability_t   msi;
+};
+#pragma pack()
+
 static inline pciaddr_t pt_pci_base_addr(pciaddr_t base)
 {
     if ( base & PCI_ADDRESS_SPACE_IO )
@@ -422,6 +474,6 @@ PCIBus *intel_pci_bridge_init(PCIBus *bus, int devfn, uint16_t vid,
            uint16_t did, const char *name, uint16_t revision);
 void igd_pci_write(PCIDevice *pci_dev, uint32_t config_addr, uint32_t val, int len);
 uint32_t igd_pci_read(PCIDevice *pci_dev, uint32_t config_addr, int len);
-
+void amd_iommu_init(PCIBus *bus);
 #endif /* __PASSTHROUGH_H__ */
 
diff --git a/vl.c b/vl.c
index be8587a..43a0111 100644
--- a/vl.c
+++ b/vl.c
@@ -217,6 +217,7 @@ int cirrus_vga_enabled = 1;
 int std_vga_enabled = 0;
 int vmsvga_enabled = 0;
 int gfx_passthru = 0;
+int guest_iommu = 0;
 #ifdef TARGET_SPARC
 int graphic_width = 1024;
 int graphic_height = 768;
@@ -4295,6 +4296,7 @@ enum {
     QEMU_OPTION_acpi,
     QEMU_OPTION_vcpus,
     QEMU_OPTION_vcpu_avail,
+    QEMU_OPTION_guest_iommu,
 
     /* Debug/Expert options: */
     QEMU_OPTION_serial,
@@ -4468,6 +4470,7 @@ static const QEMUOption qemu_options[] = {
     { "vncunused", 0, QEMU_OPTION_vncunused },
     { "vcpus", HAS_ARG, QEMU_OPTION_vcpus },
     { "vcpu_avail", HAS_ARG, QEMU_OPTION_vcpu_avail },
+    { "iommu", 0, QEMU_OPTION_guest_iommu},
 #if defined(CONFIG_XEN) && !defined(CONFIG_DM)
     { "xen-domid", HAS_ARG, QEMU_OPTION_xen_domid },
     { "xen-create", 0, QEMU_OPTION_xen_create },
@@ -5595,6 +5598,9 @@ int main(int argc, char **argv, char **envp)
             case QEMU_OPTION_gfx_passthru:
                 select_vgahw("passthrough");
                 break;
+            case QEMU_OPTION_guest_iommu:
+                guest_iommu = 1;
+                break;
             }
         }
     }

--Boundary-00=_dLM6OQaNecaPwVj
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--Boundary-00=_dLM6OQaNecaPwVj--


From xen-devel-bounces@lists.xensource.com Wed Dec 14 15:58:48 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 15:58:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RarE4-000637-Ez; Wed, 14 Dec 2011 15:58:36 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xieliwei@gmail.com>) id 1RarE2-000632-Uu
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 15:58:35 +0000
X-Env-Sender: xieliwei@gmail.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1323878258!7463270!1
X-Originating-IP: [209.85.213.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27872 invoked from network); 14 Dec 2011 15:57:39 -0000
Received: from mail-yw0-f43.google.com (HELO mail-yw0-f43.google.com)
	(209.85.213.43)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Dec 2011 15:57:39 -0000
Received: by yhr49 with SMTP id 49so27076749yhr.30
	for <xen-devel@lists.xensource.com>;
	Wed, 14 Dec 2011 07:57:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type;
	bh=JjBe56X/qQZAQzUUWEeREbe56CxrKXAFVyPrah/NBXo=;
	b=ICwjEdtvls42hXLU4uwCkbsyz+s+9shmeOZd1Bp+NGPM4d7ztSeA0WupWHRQHN3eud
	7M003rqzW/JtNT5NNaaF35cRCA2TVQLxOleh1pJBpUgsDSdQBVlGpDRUElcmmXKNCg3W
	EvP3uT9qI3pAC2/9yC3q6fAlbeuG4va3qJtqk=
Received: by 10.236.165.98 with SMTP id d62mr12649890yhl.15.1323878258130;
	Wed, 14 Dec 2011 07:57:38 -0800 (PST)
MIME-Version: 1.0
Received: by 10.100.10.4 with HTTP; Wed, 14 Dec 2011 07:57:17 -0800 (PST)
In-Reply-To: <4EE8CBC60200007800067C78@nat28.tlf.novell.com>
References: <CAPE0SYwsqRKDuPTz66r0nTVPYcsFx0Dk2j0pWpCiHELuU5W2iA@mail.gmail.com>
	<4EE881270200007800067A65@nat28.tlf.novell.com>
	<20111214125833.GA51060@ocelot.phlegethon.org>
	<CAPE0SYzJLCjO_9Nt5v7jxuMvbv=DFbGGs41=XANRXujbhAW5Vw@mail.gmail.com>
	<4EE8C6460200007800067C32@nat28.tlf.novell.com>
	<CAPE0SYyYELhSPE4WP7mhUZ409Vj6S-sTNYNx0FCiK6AMYOc5yg@mail.gmail.com>
	<4EE8CBC60200007800067C78@nat28.tlf.novell.com>
From: Liwei <xieliwei@gmail.com>
Date: Wed, 14 Dec 2011 23:57:17 +0800
Message-ID: <CAPE0SYz5D0pZWBEOu=cFMYc1tMfsZFFR4pAgYv-PrKfKGMLkBA@mail.gmail.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: Tim Deegan <tim@xen.org>, xen-devel <xen-devel@lists.xensource.com>,
	keir@xen.org, Ian.Campbell@citrix.com
Subject: Re: [Xen-devel] PTE Write access is not set
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 14 December 2011 23:16, Jan Beulich <JBeulich@suse.com> wrote:
>
> "earlyprintk=xen" is completely irrelevant here. For the others, as
> I see them commonly misplaced, I'll take the risk of embarrassing you
> by asking whether they are on the Xen command line (and not the
> kernel one).
>
>
> "hvm_debug=" comes to mind (grep for the various DBG_LEVEL_*
> defines and uses to see which one might provide greatest benefit,
> and be prepared to go through a lot of data afterwards, though
> presumably just the tail is going to be interesting if you make the
> guest not immediately restart after death).
>
> Jan
>

Would this be okay? I enabled all levels except for the VLAPIC related ones.

GRUB_CMDLINE_LINUX_DEFAULT="quiet console=tty0 console=hvc0
earlyprintk=xen nomodeset xen-pciback.permissive
xen-pciback.hide=[snip] pci=resource_alignment=[snip] loglevel=10
debug initcall_debug hvm_debug=3647"
GRUB_CMDLINE_XEN="dom0_mem=1024M loglvl=all guest_loglvl=all
console_to_ring com1=115200,8n1,0xdc00,0 console=com1"

I'll report back as soon as the crash occurs again.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 15:58:48 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 15:58:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RarE4-000637-Ez; Wed, 14 Dec 2011 15:58:36 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xieliwei@gmail.com>) id 1RarE2-000632-Uu
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 15:58:35 +0000
X-Env-Sender: xieliwei@gmail.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1323878258!7463270!1
X-Originating-IP: [209.85.213.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27872 invoked from network); 14 Dec 2011 15:57:39 -0000
Received: from mail-yw0-f43.google.com (HELO mail-yw0-f43.google.com)
	(209.85.213.43)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Dec 2011 15:57:39 -0000
Received: by yhr49 with SMTP id 49so27076749yhr.30
	for <xen-devel@lists.xensource.com>;
	Wed, 14 Dec 2011 07:57:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type;
	bh=JjBe56X/qQZAQzUUWEeREbe56CxrKXAFVyPrah/NBXo=;
	b=ICwjEdtvls42hXLU4uwCkbsyz+s+9shmeOZd1Bp+NGPM4d7ztSeA0WupWHRQHN3eud
	7M003rqzW/JtNT5NNaaF35cRCA2TVQLxOleh1pJBpUgsDSdQBVlGpDRUElcmmXKNCg3W
	EvP3uT9qI3pAC2/9yC3q6fAlbeuG4va3qJtqk=
Received: by 10.236.165.98 with SMTP id d62mr12649890yhl.15.1323878258130;
	Wed, 14 Dec 2011 07:57:38 -0800 (PST)
MIME-Version: 1.0
Received: by 10.100.10.4 with HTTP; Wed, 14 Dec 2011 07:57:17 -0800 (PST)
In-Reply-To: <4EE8CBC60200007800067C78@nat28.tlf.novell.com>
References: <CAPE0SYwsqRKDuPTz66r0nTVPYcsFx0Dk2j0pWpCiHELuU5W2iA@mail.gmail.com>
	<4EE881270200007800067A65@nat28.tlf.novell.com>
	<20111214125833.GA51060@ocelot.phlegethon.org>
	<CAPE0SYzJLCjO_9Nt5v7jxuMvbv=DFbGGs41=XANRXujbhAW5Vw@mail.gmail.com>
	<4EE8C6460200007800067C32@nat28.tlf.novell.com>
	<CAPE0SYyYELhSPE4WP7mhUZ409Vj6S-sTNYNx0FCiK6AMYOc5yg@mail.gmail.com>
	<4EE8CBC60200007800067C78@nat28.tlf.novell.com>
From: Liwei <xieliwei@gmail.com>
Date: Wed, 14 Dec 2011 23:57:17 +0800
Message-ID: <CAPE0SYz5D0pZWBEOu=cFMYc1tMfsZFFR4pAgYv-PrKfKGMLkBA@mail.gmail.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: Tim Deegan <tim@xen.org>, xen-devel <xen-devel@lists.xensource.com>,
	keir@xen.org, Ian.Campbell@citrix.com
Subject: Re: [Xen-devel] PTE Write access is not set
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 14 December 2011 23:16, Jan Beulich <JBeulich@suse.com> wrote:
>
> "earlyprintk=xen" is completely irrelevant here. For the others, as
> I see them commonly misplaced, I'll take the risk of embarrassing you
> by asking whether they are on the Xen command line (and not the
> kernel one).
>
>
> "hvm_debug=" comes to mind (grep for the various DBG_LEVEL_*
> defines and uses to see which one might provide greatest benefit,
> and be prepared to go through a lot of data afterwards, though
> presumably just the tail is going to be interesting if you make the
> guest not immediately restart after death).
>
> Jan
>

Would this be okay? I enabled all levels except for the VLAPIC related ones.

GRUB_CMDLINE_LINUX_DEFAULT="quiet console=tty0 console=hvc0
earlyprintk=xen nomodeset xen-pciback.permissive
xen-pciback.hide=[snip] pci=resource_alignment=[snip] loglevel=10
debug initcall_debug hvm_debug=3647"
GRUB_CMDLINE_XEN="dom0_mem=1024M loglvl=all guest_loglvl=all
console_to_ring com1=115200,8n1,0xdc00,0 console=com1"

I'll report back as soon as the crash occurs again.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 15:59:27 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 15:59:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RarEh-00065O-TB; Wed, 14 Dec 2011 15:59:15 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1RarEg-00064x-LP
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 15:59:14 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1323878297!1949205!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1779 invoked from network); 14 Dec 2011 15:58:19 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Dec 2011 15:58:19 -0000
Received: by iaen33 with SMTP id n33so3804244iae.30
	for <xen-devel@lists.xensource.com>;
	Wed, 14 Dec 2011 07:58:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=5rLKA2wB40jyNAVdhVE2YBuqKBLvO4+SwKE39Rb+chg=;
	b=aCbO6SzTU66EuGm2cgVFGc4jnSe1/5c7DbQXi1Th8NrwwX1mYQUlybM+qtGC2JCa9L
	ZfdJMTcQTSjiMe4mftWULd8LuFY2qAZtMeIhBLbwH8PwfVLzW7q2oEONombHL+xZlwOv
	KN2fO9zGKVJZw2gv5c4cu1Bk9FTF8viOn4sF0=
MIME-Version: 1.0
Received: by 10.42.168.202 with SMTP id x10mr19446657icy.4.1323878297672; Wed,
	14 Dec 2011 07:58:17 -0800 (PST)
Received: by 10.231.146.21 with HTTP; Wed, 14 Dec 2011 07:58:17 -0800 (PST)
In-Reply-To: <CAKpvNa2tp7Ha=8kOsYyTjnWyo46YPQU678iS9aq=CfbzDOf17A@mail.gmail.com>
References: <CAKpvNa2tp7Ha=8kOsYyTjnWyo46YPQU678iS9aq=CfbzDOf17A@mail.gmail.com>
Date: Wed, 14 Dec 2011 15:58:17 +0000
X-Google-Sender-Auth: 0Jv9ETteCGt8puJ9LNbRGO266mQ
Message-ID: <CAFLBxZbZbwU=8=gcWa74oQN2QVamZYG_=zc-pKKzotXZKW2Qtw@mail.gmail.com>
From: George Dunlap <dunlapg@umich.edu>
To: Gianluca Guida <glguida@gmail.com>
Cc: Tim Deegan <tim@xen.org>, xen-devel@lists.xensource.com,
	Keir Fraser <keir@xen.org>, Jan Beulich <JBeulich@suse.com>,
	Gianluca Guida <gianluca.guida@citrix.com>
Subject: Re: [Xen-devel] [PATCH] [shadow] Disable higher level pagetables
 early unshadow only when the "process dying" hypercall is used.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Nov 16, 2011 at 1:44 PM, Gianluca Guida <glguida@gmail.com> wrote:
> This patch fixes a performance problem in fully virtualized guests.

What performance problem, and how does it fix it?  The c/s doesn't
have any information about either, so it's hard for me to evaluate
whether I should pull it into the XenServer patchqueue...

>
> Should be backported to xen-4.0 and xen-4.1. This patch applies (with
> slightly different offsets) to all three versions.
>
> Signed-off-by: Gianluca Guida <gianluca.guida@citrix.com>
> Tested-by: Jan Beulich <jbeulich@suse.com>
>
> diff -r 068d3d55ce6e xen/arch/x86/mm/shadow/multi.c
> --- a/xen/arch/x86/mm/shadow/multi.c =A0 =A0Tue Nov 01 19:03:38 2011 +0000
> +++ b/xen/arch/x86/mm/shadow/multi.c =A0 =A0Wed Nov 16 14:30:57 2011 -0800
> @@ -2723,8 +2723,9 @@
> =A0 =A0 =A0 =A0 =A0 =A0|| ( !v->domain->arch.paging.shadow.pagetable_dyin=
g_op
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 &&
> v->arch.paging.shadow.last_emulated_mfn_for_unshadow =3D=3D mfn_x(gmfn) )
> )
> =A0 =A0 =A0 =A0 =A0&& sh_mfn_is_a_page_table(gmfn)
> - =A0 =A0 =A0 =A0 && !(mfn_to_page(gmfn)->shadow_flags
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0& (SHF_L2_32|SHF_L2_PAE|SHF_L2H_PAE|SHF_L4_6=
4)) )
> + =A0 =A0 =A0 =A0 && (!v->domain->arch.paging.shadow.pagetable_dying_op ||
> + =A0 =A0 =A0 =A0 =A0 =A0 !(mfn_to_page(gmfn)->shadow_flags
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 & (SHF_L2_32|SHF_L2_PAE|SHF_L2H_PAE|SHF_L4_=
64))) )
> =A0 =A0 {
> =A0 =A0 =A0 =A0 perfc_incr(shadow_early_unshadow);
> =A0 =A0 =A0 =A0 sh_remove_shadows(v, gmfn, 1, 0 /* Fast, can fail to unsh=
adow */ );
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 15:59:27 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 15:59:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RarEh-00065O-TB; Wed, 14 Dec 2011 15:59:15 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1RarEg-00064x-LP
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 15:59:14 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1323878297!1949205!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1779 invoked from network); 14 Dec 2011 15:58:19 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Dec 2011 15:58:19 -0000
Received: by iaen33 with SMTP id n33so3804244iae.30
	for <xen-devel@lists.xensource.com>;
	Wed, 14 Dec 2011 07:58:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=5rLKA2wB40jyNAVdhVE2YBuqKBLvO4+SwKE39Rb+chg=;
	b=aCbO6SzTU66EuGm2cgVFGc4jnSe1/5c7DbQXi1Th8NrwwX1mYQUlybM+qtGC2JCa9L
	ZfdJMTcQTSjiMe4mftWULd8LuFY2qAZtMeIhBLbwH8PwfVLzW7q2oEONombHL+xZlwOv
	KN2fO9zGKVJZw2gv5c4cu1Bk9FTF8viOn4sF0=
MIME-Version: 1.0
Received: by 10.42.168.202 with SMTP id x10mr19446657icy.4.1323878297672; Wed,
	14 Dec 2011 07:58:17 -0800 (PST)
Received: by 10.231.146.21 with HTTP; Wed, 14 Dec 2011 07:58:17 -0800 (PST)
In-Reply-To: <CAKpvNa2tp7Ha=8kOsYyTjnWyo46YPQU678iS9aq=CfbzDOf17A@mail.gmail.com>
References: <CAKpvNa2tp7Ha=8kOsYyTjnWyo46YPQU678iS9aq=CfbzDOf17A@mail.gmail.com>
Date: Wed, 14 Dec 2011 15:58:17 +0000
X-Google-Sender-Auth: 0Jv9ETteCGt8puJ9LNbRGO266mQ
Message-ID: <CAFLBxZbZbwU=8=gcWa74oQN2QVamZYG_=zc-pKKzotXZKW2Qtw@mail.gmail.com>
From: George Dunlap <dunlapg@umich.edu>
To: Gianluca Guida <glguida@gmail.com>
Cc: Tim Deegan <tim@xen.org>, xen-devel@lists.xensource.com,
	Keir Fraser <keir@xen.org>, Jan Beulich <JBeulich@suse.com>,
	Gianluca Guida <gianluca.guida@citrix.com>
Subject: Re: [Xen-devel] [PATCH] [shadow] Disable higher level pagetables
 early unshadow only when the "process dying" hypercall is used.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Nov 16, 2011 at 1:44 PM, Gianluca Guida <glguida@gmail.com> wrote:
> This patch fixes a performance problem in fully virtualized guests.

What performance problem, and how does it fix it?  The c/s doesn't
have any information about either, so it's hard for me to evaluate
whether I should pull it into the XenServer patchqueue...

>
> Should be backported to xen-4.0 and xen-4.1. This patch applies (with
> slightly different offsets) to all three versions.
>
> Signed-off-by: Gianluca Guida <gianluca.guida@citrix.com>
> Tested-by: Jan Beulich <jbeulich@suse.com>
>
> diff -r 068d3d55ce6e xen/arch/x86/mm/shadow/multi.c
> --- a/xen/arch/x86/mm/shadow/multi.c =A0 =A0Tue Nov 01 19:03:38 2011 +0000
> +++ b/xen/arch/x86/mm/shadow/multi.c =A0 =A0Wed Nov 16 14:30:57 2011 -0800
> @@ -2723,8 +2723,9 @@
> =A0 =A0 =A0 =A0 =A0 =A0|| ( !v->domain->arch.paging.shadow.pagetable_dyin=
g_op
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 &&
> v->arch.paging.shadow.last_emulated_mfn_for_unshadow =3D=3D mfn_x(gmfn) )
> )
> =A0 =A0 =A0 =A0 =A0&& sh_mfn_is_a_page_table(gmfn)
> - =A0 =A0 =A0 =A0 && !(mfn_to_page(gmfn)->shadow_flags
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0& (SHF_L2_32|SHF_L2_PAE|SHF_L2H_PAE|SHF_L4_6=
4)) )
> + =A0 =A0 =A0 =A0 && (!v->domain->arch.paging.shadow.pagetable_dying_op ||
> + =A0 =A0 =A0 =A0 =A0 =A0 !(mfn_to_page(gmfn)->shadow_flags
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 & (SHF_L2_32|SHF_L2_PAE|SHF_L2H_PAE|SHF_L4_=
64))) )
> =A0 =A0 {
> =A0 =A0 =A0 =A0 perfc_incr(shadow_early_unshadow);
> =A0 =A0 =A0 =A0 sh_remove_shadows(v, gmfn, 1, 0 /* Fast, can fail to unsh=
adow */ );
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 16:13:58 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 16: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.xensource.com>)
	id 1RarSb-0006x2-En; Wed, 14 Dec 2011 16:13:37 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1RarSZ-0006ws-Bq
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 16:13:35 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1323879158!5549596!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6196 invoked from network); 14 Dec 2011 16:12:39 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Dec 2011 16:12:39 -0000
Received: by iaen33 with SMTP id n33so3835807iae.30
	for <xen-devel@lists.xensource.com>;
	Wed, 14 Dec 2011 08:12:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=2gbuo0IiEKUAa/8u+glN2hWYH1fQxVfia9NtIJSKT08=;
	b=m4tN4Zfj+hV/FGoJn/8Ud6GaVIS4Qx4jWLDoqUJi7Z8V868BdeLTOP1btdNBqMhnnl
	nC7KcZsts0Lxa7PweIQ6JzZUsCWM6WImzCruo2nZUVaPC+bSbuI8mHC+QMrepLTc444j
	Z7J0I00gUfm7zZwf6sjHEN0Adm3wm34Mhlx6o=
MIME-Version: 1.0
Received: by 10.50.242.1 with SMTP id wm1mr25109875igc.30.1323879158036; Wed,
	14 Dec 2011 08:12:38 -0800 (PST)
Received: by 10.231.146.21 with HTTP; Wed, 14 Dec 2011 08:12:37 -0800 (PST)
In-Reply-To: <CAFQ2Z+d_Oq+6L9x=V9mPJ2jTSOa5k5k2Cpgyd9rYBsrOcMeFQw@mail.gmail.com>
References: <4EBA58F2020000780005FCCC@nat28.tlf.novell.com>
	<CAFQ2Z+d_Oq+6L9x=V9mPJ2jTSOa5k5k2Cpgyd9rYBsrOcMeFQw@mail.gmail.com>
Date: Wed, 14 Dec 2011 16:12:37 +0000
X-Google-Sender-Auth: BUeXu1Yhnw0LkdhouDPua6fxsho
Message-ID: <CAFLBxZah=GegCYJf4TCc5awEyHwRU9hz0xzyAqokaDLs5i7Xfg@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Haitao Shan <maillists.shan@gmail.com>
Cc: Yang Z Zhang <yang.z.zhang@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Haitao Shan <haitao.shan@intel.com>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH] x86/cpuidle: add Westmere-EX support to hw
 residencies reading logic
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Should this be back-ported to 4.1?
 -George

On Wed, Nov 30, 2011 at 6:13 AM, Haitao Shan <maillists.shan@gmail.com> wro=
te:
> ACK!
> Thanks Jan for making the cpu model list more complete.
>
> Shan Haitao
>
> 2011/11/9 Jan Beulich <JBeulich@suse.com>:
>> This is in accordance with
>> http://software.intel.com/en-us/articles/intel-processor-identification-=
with-cpuid-model-and-family-numbers/
>>
>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>>
>> --- a/xen/arch/x86/acpi/cpu_idle.c
>> +++ b/xen/arch/x86/acpi/cpu_idle.c
>> @@ -120,6 +120,7 @@ static void do_get_hw_residencies(void *
>> =A0 =A0 /* Westmere */
>> =A0 =A0 case 0x25:
>> =A0 =A0 case 0x2C:
>> + =A0 =A0case 0x2F:
>> =A0 =A0 =A0 =A0 GET_PC3_RES(hw_res->pc3);
>> =A0 =A0 =A0 =A0 GET_PC6_RES(hw_res->pc6);
>> =A0 =A0 =A0 =A0 GET_PC7_RES(hw_res->pc7);
>>
>>
>>
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel
>>
>>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 16:13:58 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 16: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.xensource.com>)
	id 1RarSb-0006x2-En; Wed, 14 Dec 2011 16:13:37 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1RarSZ-0006ws-Bq
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 16:13:35 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1323879158!5549596!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6196 invoked from network); 14 Dec 2011 16:12:39 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Dec 2011 16:12:39 -0000
Received: by iaen33 with SMTP id n33so3835807iae.30
	for <xen-devel@lists.xensource.com>;
	Wed, 14 Dec 2011 08:12:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=2gbuo0IiEKUAa/8u+glN2hWYH1fQxVfia9NtIJSKT08=;
	b=m4tN4Zfj+hV/FGoJn/8Ud6GaVIS4Qx4jWLDoqUJi7Z8V868BdeLTOP1btdNBqMhnnl
	nC7KcZsts0Lxa7PweIQ6JzZUsCWM6WImzCruo2nZUVaPC+bSbuI8mHC+QMrepLTc444j
	Z7J0I00gUfm7zZwf6sjHEN0Adm3wm34Mhlx6o=
MIME-Version: 1.0
Received: by 10.50.242.1 with SMTP id wm1mr25109875igc.30.1323879158036; Wed,
	14 Dec 2011 08:12:38 -0800 (PST)
Received: by 10.231.146.21 with HTTP; Wed, 14 Dec 2011 08:12:37 -0800 (PST)
In-Reply-To: <CAFQ2Z+d_Oq+6L9x=V9mPJ2jTSOa5k5k2Cpgyd9rYBsrOcMeFQw@mail.gmail.com>
References: <4EBA58F2020000780005FCCC@nat28.tlf.novell.com>
	<CAFQ2Z+d_Oq+6L9x=V9mPJ2jTSOa5k5k2Cpgyd9rYBsrOcMeFQw@mail.gmail.com>
Date: Wed, 14 Dec 2011 16:12:37 +0000
X-Google-Sender-Auth: BUeXu1Yhnw0LkdhouDPua6fxsho
Message-ID: <CAFLBxZah=GegCYJf4TCc5awEyHwRU9hz0xzyAqokaDLs5i7Xfg@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Haitao Shan <maillists.shan@gmail.com>
Cc: Yang Z Zhang <yang.z.zhang@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Haitao Shan <haitao.shan@intel.com>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH] x86/cpuidle: add Westmere-EX support to hw
 residencies reading logic
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Should this be back-ported to 4.1?
 -George

On Wed, Nov 30, 2011 at 6:13 AM, Haitao Shan <maillists.shan@gmail.com> wro=
te:
> ACK!
> Thanks Jan for making the cpu model list more complete.
>
> Shan Haitao
>
> 2011/11/9 Jan Beulich <JBeulich@suse.com>:
>> This is in accordance with
>> http://software.intel.com/en-us/articles/intel-processor-identification-=
with-cpuid-model-and-family-numbers/
>>
>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>>
>> --- a/xen/arch/x86/acpi/cpu_idle.c
>> +++ b/xen/arch/x86/acpi/cpu_idle.c
>> @@ -120,6 +120,7 @@ static void do_get_hw_residencies(void *
>> =A0 =A0 /* Westmere */
>> =A0 =A0 case 0x25:
>> =A0 =A0 case 0x2C:
>> + =A0 =A0case 0x2F:
>> =A0 =A0 =A0 =A0 GET_PC3_RES(hw_res->pc3);
>> =A0 =A0 =A0 =A0 GET_PC6_RES(hw_res->pc6);
>> =A0 =A0 =A0 =A0 GET_PC7_RES(hw_res->pc7);
>>
>>
>>
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel
>>
>>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 16:21:10 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 16: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.xensource.com>)
	id 1RarZa-00078v-CD; Wed, 14 Dec 2011 16:20:50 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <glguida@gmail.com>) id 1RarZY-00078j-5S
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 16:20:48 +0000
X-Env-Sender: glguida@gmail.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1323879591!5552109!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16883 invoked from network); 14 Dec 2011 16:19:52 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Dec 2011 16:19:52 -0000
Received: by iaen33 with SMTP id n33so3852003iae.30
	for <xen-devel@lists.xensource.com>;
	Wed, 14 Dec 2011 08:19:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	bh=X7DRoGcPVGl9C+QNvtrOWCwisJ/lJtoRfzKM4cOdspA=;
	b=Lx4AElbKWRZn1srg3QKdVmoCEsU3kE1pPSIpMPM80P3Gkz7wNBbUDYLrB75Z2uVec6
	q5X+bvdPffUzUl6w69qAgRQ9mKRYPZe+R6ue39NIiL0W15CB/f8opigkrS7Hv7C4AOqg
	JZiJp43sabNhHQFsyhSqVih4wev3Wnzlobgfo=
MIME-Version: 1.0
Received: by 10.43.51.69 with SMTP id vh5mr20883571icb.32.1323879590757; Wed,
	14 Dec 2011 08:19:50 -0800 (PST)
Received: by 10.50.111.6 with HTTP; Wed, 14 Dec 2011 08:19:50 -0800 (PST)
In-Reply-To: <CAFLBxZbZbwU=8=gcWa74oQN2QVamZYG_=zc-pKKzotXZKW2Qtw@mail.gmail.com>
References: <CAKpvNa2tp7Ha=8kOsYyTjnWyo46YPQU678iS9aq=CfbzDOf17A@mail.gmail.com>
	<CAFLBxZbZbwU=8=gcWa74oQN2QVamZYG_=zc-pKKzotXZKW2Qtw@mail.gmail.com>
Date: Wed, 14 Dec 2011 08:19:50 -0800
Message-ID: <CAKpvNa2Lbie+i-vFJoxfkAXKPVYEZuuZKk5ZJecYg5xFeBmZ+A@mail.gmail.com>
From: Gianluca Guida <glguida@gmail.com>
To: George Dunlap <dunlapg@umich.edu>
Cc: Tim Deegan <tim@xen.org>, xen-devel@lists.xensource.com,
	Keir Fraser <keir@xen.org>, Jan Beulich <JBeulich@suse.com>,
	Gianluca Guida <gianluca.guida@citrix.com>
Subject: Re: [Xen-devel] [PATCH] [shadow] Disable higher level pagetables
 early unshadow only when the "process dying" hypercall is used.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi George,

On Wed, Dec 14, 2011 at 7:58 AM, George Dunlap <dunlapg@umich.edu> wrote:
> On Wed, Nov 16, 2011 at 1:44 PM, Gianluca Guida <glguida@gmail.com> wrote:
>> This patch fixes a performance problem in fully virtualized guests.
>
> What performance problem, and how does it fix it? =A0The c/s doesn't
> have any information about either, so it's hard for me to evaluate
> whether I should pull it into the XenServer patchqueue...

Have a look at this:

http://old-list-archives.xen.org/archives/html/xen-devel/2011-11/msg00650.h=
tml

A good question is whether the performance improvement that brought
Stefano to implement the hypercall in Linux was due to the original
patch creating a regression or if it really helps even after the
performance regression is fixed.

I wasn't here on the Xen world while the patch was tested on unstable,
so i have no idea about it.

Gianluca

-- =

It was a type of people I did not know, I found them very strange and
they did not inspire confidence at all. Later I learned that I had been
introduced to electronic engineers.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 =A0 =A0 E. W. Dijkstra

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 16:21:10 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 16: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.xensource.com>)
	id 1RarZa-00078v-CD; Wed, 14 Dec 2011 16:20:50 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <glguida@gmail.com>) id 1RarZY-00078j-5S
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 16:20:48 +0000
X-Env-Sender: glguida@gmail.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1323879591!5552109!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16883 invoked from network); 14 Dec 2011 16:19:52 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Dec 2011 16:19:52 -0000
Received: by iaen33 with SMTP id n33so3852003iae.30
	for <xen-devel@lists.xensource.com>;
	Wed, 14 Dec 2011 08:19:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	bh=X7DRoGcPVGl9C+QNvtrOWCwisJ/lJtoRfzKM4cOdspA=;
	b=Lx4AElbKWRZn1srg3QKdVmoCEsU3kE1pPSIpMPM80P3Gkz7wNBbUDYLrB75Z2uVec6
	q5X+bvdPffUzUl6w69qAgRQ9mKRYPZe+R6ue39NIiL0W15CB/f8opigkrS7Hv7C4AOqg
	JZiJp43sabNhHQFsyhSqVih4wev3Wnzlobgfo=
MIME-Version: 1.0
Received: by 10.43.51.69 with SMTP id vh5mr20883571icb.32.1323879590757; Wed,
	14 Dec 2011 08:19:50 -0800 (PST)
Received: by 10.50.111.6 with HTTP; Wed, 14 Dec 2011 08:19:50 -0800 (PST)
In-Reply-To: <CAFLBxZbZbwU=8=gcWa74oQN2QVamZYG_=zc-pKKzotXZKW2Qtw@mail.gmail.com>
References: <CAKpvNa2tp7Ha=8kOsYyTjnWyo46YPQU678iS9aq=CfbzDOf17A@mail.gmail.com>
	<CAFLBxZbZbwU=8=gcWa74oQN2QVamZYG_=zc-pKKzotXZKW2Qtw@mail.gmail.com>
Date: Wed, 14 Dec 2011 08:19:50 -0800
Message-ID: <CAKpvNa2Lbie+i-vFJoxfkAXKPVYEZuuZKk5ZJecYg5xFeBmZ+A@mail.gmail.com>
From: Gianluca Guida <glguida@gmail.com>
To: George Dunlap <dunlapg@umich.edu>
Cc: Tim Deegan <tim@xen.org>, xen-devel@lists.xensource.com,
	Keir Fraser <keir@xen.org>, Jan Beulich <JBeulich@suse.com>,
	Gianluca Guida <gianluca.guida@citrix.com>
Subject: Re: [Xen-devel] [PATCH] [shadow] Disable higher level pagetables
 early unshadow only when the "process dying" hypercall is used.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi George,

On Wed, Dec 14, 2011 at 7:58 AM, George Dunlap <dunlapg@umich.edu> wrote:
> On Wed, Nov 16, 2011 at 1:44 PM, Gianluca Guida <glguida@gmail.com> wrote:
>> This patch fixes a performance problem in fully virtualized guests.
>
> What performance problem, and how does it fix it? =A0The c/s doesn't
> have any information about either, so it's hard for me to evaluate
> whether I should pull it into the XenServer patchqueue...

Have a look at this:

http://old-list-archives.xen.org/archives/html/xen-devel/2011-11/msg00650.h=
tml

A good question is whether the performance improvement that brought
Stefano to implement the hypercall in Linux was due to the original
patch creating a regression or if it really helps even after the
performance regression is fixed.

I wasn't here on the Xen world while the patch was tested on unstable,
so i have no idea about it.

Gianluca

-- =

It was a type of people I did not know, I found them very strange and
they did not inspire confidence at all. Later I learned that I had been
introduced to electronic engineers.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 =A0 =A0 E. W. Dijkstra

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 16:39:51 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 16:39:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rarra-0007rx-Cv; Wed, 14 Dec 2011 16:39:26 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RarrY-0007rf-Fx
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 16:39:24 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1323880708!7861348!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTc4Ng==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22365 invoked from network); 14 Dec 2011 16:38:28 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Dec 2011 16:38:28 -0000
X-IronPort-AV: E=Sophos;i="4.71,353,1320624000"; 
   d="scan'208";a="9470474"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Dec 2011 16:37:25 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 14 Dec 2011 16:37:25 +0000
Date: Wed, 14 Dec 2011 16:39:30 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Jan Beulich <JBeulich@suse.com>
In-Reply-To: <4EE8968D0200007800067AB0@nat28.tlf.novell.com>
Message-ID: <alpine.DEB.2.00.1112141639070.3517@kaball-desktop>
References: <4EE7672902000078000674D4@nat28.tlf.novell.com>
	<alpine.DEB.2.00.1112131646150.3517@kaball-desktop>
	<4EE8968D0200007800067AB0@nat28.tlf.novell.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] map_domain_emuirq_pirq() imbalance with
 unmap_domain_pirq_emuirq()?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 14 Dec 2011, Jan Beulich wrote:
> >>> On 13.12.11 at 18:16, Stefano Stabellini <stefano.stabellini@eu.citrix.com> wrote:
> > --- a/xen/arch/x86/physdev.c
> > +++ b/xen/arch/x86/physdev.c
> > @@ -216,14 +216,16 @@ int physdev_unmap_pirq(domid_t domid, int pirq)
> >      if ( ret )
> >          return ret;
> >  
> > -    if ( is_hvm_domain(d) )
> > +    if ( is_hvm_domain(d) && domain_pirq_to_emuirq(d, pirq) != IRQ_UNBOUND)
> >      {
> >          spin_lock(&d->event_lock);
> >          ret = unmap_domain_pirq_emuirq(d, pirq);
> >          spin_unlock(&d->event_lock);
> > -        if ( domid == DOMID_SELF || ret )
> > +        if ( ret )
> >              goto free_domain;
> >      }
> > +    if ( domid == DOMID_SELF )
> > +        goto free_domain;
> >  
> >      ret = -EPERM;
> >      if ( !IS_PRIV_FOR(current->domain, d) )
> 
> I think this is the correct change (untested so far):
> 
> @@ -228,7 +228,8 @@ static int physdev_unmap_pirq(struct phy
>      if ( is_hvm_domain(d) )
>      {
>          spin_lock(&d->event_lock);
> -        ret = unmap_domain_pirq_emuirq(d, pirq);
> +        if ( domain_pirq_to_emuirq(d, pirq) != IRQ_UNBOUND )
> +            ret = unmap_domain_pirq_emuirq(d, pirq);
>          spin_unlock(&d->event_lock);
>          if ( unmap->domid == DOMID_SELF || ret )
>              goto free_domain;
> 
> i.e. do the lookup with the lock held (and taking advantage of 'ret'
> being zero when reaching the enclosing if()).
 
ack

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 16:39:51 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 16:39:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rarra-0007rx-Cv; Wed, 14 Dec 2011 16:39:26 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RarrY-0007rf-Fx
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 16:39:24 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1323880708!7861348!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTc4Ng==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22365 invoked from network); 14 Dec 2011 16:38:28 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Dec 2011 16:38:28 -0000
X-IronPort-AV: E=Sophos;i="4.71,353,1320624000"; 
   d="scan'208";a="9470474"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Dec 2011 16:37:25 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 14 Dec 2011 16:37:25 +0000
Date: Wed, 14 Dec 2011 16:39:30 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Jan Beulich <JBeulich@suse.com>
In-Reply-To: <4EE8968D0200007800067AB0@nat28.tlf.novell.com>
Message-ID: <alpine.DEB.2.00.1112141639070.3517@kaball-desktop>
References: <4EE7672902000078000674D4@nat28.tlf.novell.com>
	<alpine.DEB.2.00.1112131646150.3517@kaball-desktop>
	<4EE8968D0200007800067AB0@nat28.tlf.novell.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] map_domain_emuirq_pirq() imbalance with
 unmap_domain_pirq_emuirq()?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 14 Dec 2011, Jan Beulich wrote:
> >>> On 13.12.11 at 18:16, Stefano Stabellini <stefano.stabellini@eu.citrix.com> wrote:
> > --- a/xen/arch/x86/physdev.c
> > +++ b/xen/arch/x86/physdev.c
> > @@ -216,14 +216,16 @@ int physdev_unmap_pirq(domid_t domid, int pirq)
> >      if ( ret )
> >          return ret;
> >  
> > -    if ( is_hvm_domain(d) )
> > +    if ( is_hvm_domain(d) && domain_pirq_to_emuirq(d, pirq) != IRQ_UNBOUND)
> >      {
> >          spin_lock(&d->event_lock);
> >          ret = unmap_domain_pirq_emuirq(d, pirq);
> >          spin_unlock(&d->event_lock);
> > -        if ( domid == DOMID_SELF || ret )
> > +        if ( ret )
> >              goto free_domain;
> >      }
> > +    if ( domid == DOMID_SELF )
> > +        goto free_domain;
> >  
> >      ret = -EPERM;
> >      if ( !IS_PRIV_FOR(current->domain, d) )
> 
> I think this is the correct change (untested so far):
> 
> @@ -228,7 +228,8 @@ static int physdev_unmap_pirq(struct phy
>      if ( is_hvm_domain(d) )
>      {
>          spin_lock(&d->event_lock);
> -        ret = unmap_domain_pirq_emuirq(d, pirq);
> +        if ( domain_pirq_to_emuirq(d, pirq) != IRQ_UNBOUND )
> +            ret = unmap_domain_pirq_emuirq(d, pirq);
>          spin_unlock(&d->event_lock);
>          if ( unmap->domid == DOMID_SELF || ret )
>              goto free_domain;
> 
> i.e. do the lookup with the lock held (and taking advantage of 'ret'
> being zero when reaching the enclosing if()).
 
ack

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 16:43:43 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 16:43:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RarvP-00082q-8C; Wed, 14 Dec 2011 16:43:23 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Neal.Taylor@ca.com>) id 1RarvM-00082W-TC
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 16:43:21 +0000
X-Env-Sender: Neal.Taylor@ca.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1323880942!5553580!1
X-Originating-IP: [74.125.149.205]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15296 invoked from network); 14 Dec 2011 16:42:24 -0000
Received: from na3sys009aog111.obsmtp.com (HELO na3sys009aog111.obsmtp.com)
	(74.125.149.205)
	by server-4.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Dec 2011 16:42:24 -0000
Received: from USILMS191.ca.com ([141.202.246.45]) (using TLSv1) by
	na3sys009aob111.postini.com ([74.125.148.12]) with SMTP
	ID DSNKTujR7c8dO1cIZE5GB9ra1vVqf7m4weD2@postini.com;
	Wed, 14 Dec 2011 08:42:24 PST
Received: from USILMS173.ca.com (141.202.6.23) by USILMS191.ca.com
	(141.202.246.45) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Wed, 14 Dec 2011 11:42:20 -0500
Received: from USILMS110A.ca.com ([169.254.1.109]) by usilms173.ca.com
	([141.202.6.23]) with mapi id 14.01.0289.001;
	Wed, 14 Dec 2011 11:42:20 -0500
From: "Taylor, Neal E" <Neal.Taylor@ca.com>
To: Jan Beulich <JBeulich@suse.com>
Thread-Topic: [Xen-devel] Buffers not reachable by PCI
Thread-Index: Acy2r+Ulg1PsfbmtTl6QVj0jZAx7mwAK1xcAAIXl/sAAGPmvgAAhEiCwAA9ukQAACILlsAAMK30AAALQl/A=
Date: Wed, 14 Dec 2011 16:42:19 +0000
Message-ID: <3E243B26F475504B9BB0BCC9728B0DA629E18A6B@USILMS110A.ca.com>
References: <3E243B26F475504B9BB0BCC9728B0DA629E16E01@USILMS110A.ca.com>
	<20111209203010.GA14412@andromeda.dapyr.net>
	<3E243B26F475504B9BB0BCC9728B0DA629E17AEA@USILMS110A.ca.com>
	<20111213001912.GA2730@konrad-lan>
	<3E243B26F475504B9BB0BCC9728B0DA629E184FA@USILMS110A.ca.com>
	<20111213232759.GA8702@konrad-lan>
	<3E243B26F475504B9BB0BCC9728B0DA629E18564@USILMS110A.ca.com>
	<4EE8785A0200007800067A16@nat28.tlf.novell.com>
In-Reply-To: <4EE8785A0200007800067A16@nat28.tlf.novell.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [138.42.46.105]
MIME-Version: 1.0
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>,
	xen-devel <xen-devel@lists.xensource.com>, "Kalev,
	Leonid" <Leonid.Kalev@ca.com>, Tushar N Dave <tushar.n.dave@intel.com>
Subject: Re: [Xen-devel] Buffers not reachable by PCI
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

The last quoted printout is calculated the same way as the test that fails which leads me to question the computation's validity.

The test that fails is (from drivers/xen/swiotlb-xen.c):
xen_swiotlb_dma_supported(struct device *hwdev, u64 mask)
{
        return xen_virt_to_bus(xen_io_tlb_end - 1) <= mask;
}


"xen_virt_to_bus" in turn:
static dma_addr_t xen_virt_to_bus(void *address)
{
        return xen_phys_to_bus(virt_to_phys(address));
}


Now, "virt_to_phys" (out of arch/x86/include/asm/io.h) is defined as follows but carries a comment bothersome to this usage of it as we're, basically, dealing with a dma "transfer" and calling from a device driver:
/**
 *      virt_to_phys    -       map virtual addresses to physical
 *      @address: address to remap
 *
 *      The returned physical address is the physical (CPU) mapping for
 *      the memory address given. It is only valid to use this function on
 *      addresses directly mapped or allocated via kmalloc.
 *
 *      This function does not give bus mappings for DMA transfers. In
 *      almost all conceivable cases a device driver should not be using
 *      this function
 */ 
static inline phys_addr_t virt_to_phys(volatile void *address)
{
        return __pa(address);
}


Going a couple of steps further, "__pa" is defined (in arch/x86/include/asm/page.h) as:
#define __pa(x)         __phys_addr((unsigned long)(x))


and "__phys_addr" (in arch/x86/mm/physaddr.c) as:
unsigned long __phys_addr(unsigned long x)
{
        if (x >= __START_KERNEL_map) {
                x -= __START_KERNEL_map;
                VIRTUAL_BUG_ON(x >= KERNEL_IMAGE_SIZE);
                x += phys_base;
        } else {
                VIRTUAL_BUG_ON(x < PAGE_OFFSET);
                x -= PAGE_OFFSET;
                VIRTUAL_BUG_ON(!phys_addr_valid(x));
        }
        return x;
}
EXPORT_SYMBOL(__phys_addr);


So, if "virt_to_phys" isn't yielding a valid test of whether addresses will be reachable from a PCI device, what's the correct way to test it and should xen_swiotlb_dma_supported be updated to the correct way (I think so) or a new function be created?

Neal


-----Original Message-----
From: Jan Beulich [mailto:JBeulich@suse.com] 
Sent: Wednesday, December 14, 2011 1:20 AM
To: Taylor, Neal E
Cc: Kalev, Leonid; Konrad Rzeszutek Wilk; Tushar N Dave; xen-devel
Subject: Re: [Xen-devel] Buffers not reachable by PCI

>>> On 14.12.11 at 01:38, "Taylor, Neal E" <Neal.Taylor@ca.com> wrote:
> [    0.000000] MFN 0x7f7f->0x7f00

This is clearly indicating the last chunk ends well below the 4G boundary.

> [    0.000000] Placing 64MB software IO TLB between d832cf00 - dc32cf00
> [    0.000000] software IO TLB at phys 0x1832cf00 - 0x1c32cf00
> [    0.000000] software IO TLB at bus 0x1c0f00 - 0x120fdff00

Consequently, the question is how you got to this value, or what
changed between the first and last quoted printouts.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 16:43:43 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 16:43:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RarvP-00082q-8C; Wed, 14 Dec 2011 16:43:23 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Neal.Taylor@ca.com>) id 1RarvM-00082W-TC
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 16:43:21 +0000
X-Env-Sender: Neal.Taylor@ca.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1323880942!5553580!1
X-Originating-IP: [74.125.149.205]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15296 invoked from network); 14 Dec 2011 16:42:24 -0000
Received: from na3sys009aog111.obsmtp.com (HELO na3sys009aog111.obsmtp.com)
	(74.125.149.205)
	by server-4.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Dec 2011 16:42:24 -0000
Received: from USILMS191.ca.com ([141.202.246.45]) (using TLSv1) by
	na3sys009aob111.postini.com ([74.125.148.12]) with SMTP
	ID DSNKTujR7c8dO1cIZE5GB9ra1vVqf7m4weD2@postini.com;
	Wed, 14 Dec 2011 08:42:24 PST
Received: from USILMS173.ca.com (141.202.6.23) by USILMS191.ca.com
	(141.202.246.45) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Wed, 14 Dec 2011 11:42:20 -0500
Received: from USILMS110A.ca.com ([169.254.1.109]) by usilms173.ca.com
	([141.202.6.23]) with mapi id 14.01.0289.001;
	Wed, 14 Dec 2011 11:42:20 -0500
From: "Taylor, Neal E" <Neal.Taylor@ca.com>
To: Jan Beulich <JBeulich@suse.com>
Thread-Topic: [Xen-devel] Buffers not reachable by PCI
Thread-Index: Acy2r+Ulg1PsfbmtTl6QVj0jZAx7mwAK1xcAAIXl/sAAGPmvgAAhEiCwAA9ukQAACILlsAAMK30AAALQl/A=
Date: Wed, 14 Dec 2011 16:42:19 +0000
Message-ID: <3E243B26F475504B9BB0BCC9728B0DA629E18A6B@USILMS110A.ca.com>
References: <3E243B26F475504B9BB0BCC9728B0DA629E16E01@USILMS110A.ca.com>
	<20111209203010.GA14412@andromeda.dapyr.net>
	<3E243B26F475504B9BB0BCC9728B0DA629E17AEA@USILMS110A.ca.com>
	<20111213001912.GA2730@konrad-lan>
	<3E243B26F475504B9BB0BCC9728B0DA629E184FA@USILMS110A.ca.com>
	<20111213232759.GA8702@konrad-lan>
	<3E243B26F475504B9BB0BCC9728B0DA629E18564@USILMS110A.ca.com>
	<4EE8785A0200007800067A16@nat28.tlf.novell.com>
In-Reply-To: <4EE8785A0200007800067A16@nat28.tlf.novell.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [138.42.46.105]
MIME-Version: 1.0
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>,
	xen-devel <xen-devel@lists.xensource.com>, "Kalev,
	Leonid" <Leonid.Kalev@ca.com>, Tushar N Dave <tushar.n.dave@intel.com>
Subject: Re: [Xen-devel] Buffers not reachable by PCI
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

The last quoted printout is calculated the same way as the test that fails which leads me to question the computation's validity.

The test that fails is (from drivers/xen/swiotlb-xen.c):
xen_swiotlb_dma_supported(struct device *hwdev, u64 mask)
{
        return xen_virt_to_bus(xen_io_tlb_end - 1) <= mask;
}


"xen_virt_to_bus" in turn:
static dma_addr_t xen_virt_to_bus(void *address)
{
        return xen_phys_to_bus(virt_to_phys(address));
}


Now, "virt_to_phys" (out of arch/x86/include/asm/io.h) is defined as follows but carries a comment bothersome to this usage of it as we're, basically, dealing with a dma "transfer" and calling from a device driver:
/**
 *      virt_to_phys    -       map virtual addresses to physical
 *      @address: address to remap
 *
 *      The returned physical address is the physical (CPU) mapping for
 *      the memory address given. It is only valid to use this function on
 *      addresses directly mapped or allocated via kmalloc.
 *
 *      This function does not give bus mappings for DMA transfers. In
 *      almost all conceivable cases a device driver should not be using
 *      this function
 */ 
static inline phys_addr_t virt_to_phys(volatile void *address)
{
        return __pa(address);
}


Going a couple of steps further, "__pa" is defined (in arch/x86/include/asm/page.h) as:
#define __pa(x)         __phys_addr((unsigned long)(x))


and "__phys_addr" (in arch/x86/mm/physaddr.c) as:
unsigned long __phys_addr(unsigned long x)
{
        if (x >= __START_KERNEL_map) {
                x -= __START_KERNEL_map;
                VIRTUAL_BUG_ON(x >= KERNEL_IMAGE_SIZE);
                x += phys_base;
        } else {
                VIRTUAL_BUG_ON(x < PAGE_OFFSET);
                x -= PAGE_OFFSET;
                VIRTUAL_BUG_ON(!phys_addr_valid(x));
        }
        return x;
}
EXPORT_SYMBOL(__phys_addr);


So, if "virt_to_phys" isn't yielding a valid test of whether addresses will be reachable from a PCI device, what's the correct way to test it and should xen_swiotlb_dma_supported be updated to the correct way (I think so) or a new function be created?

Neal


-----Original Message-----
From: Jan Beulich [mailto:JBeulich@suse.com] 
Sent: Wednesday, December 14, 2011 1:20 AM
To: Taylor, Neal E
Cc: Kalev, Leonid; Konrad Rzeszutek Wilk; Tushar N Dave; xen-devel
Subject: Re: [Xen-devel] Buffers not reachable by PCI

>>> On 14.12.11 at 01:38, "Taylor, Neal E" <Neal.Taylor@ca.com> wrote:
> [    0.000000] MFN 0x7f7f->0x7f00

This is clearly indicating the last chunk ends well below the 4G boundary.

> [    0.000000] Placing 64MB software IO TLB between d832cf00 - dc32cf00
> [    0.000000] software IO TLB at phys 0x1832cf00 - 0x1c32cf00
> [    0.000000] software IO TLB at bus 0x1c0f00 - 0x120fdff00

Consequently, the question is how you got to this value, or what
changed between the first and last quoted printouts.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 16:45:35 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 16:45:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RarxF-0008Ba-Os; Wed, 14 Dec 2011 16:45:17 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RarxE-0008BG-VY
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 16:45:17 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1323881060!5506909!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28657 invoked from network); 14 Dec 2011 16:44:20 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-3.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Dec 2011 16:44:20 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 14 Dec 2011 16:44:19 +0000
Message-Id: <4EE8E0720200007800067DDD@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 14 Dec 2011 16:44:18 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Wang" <wei.wang2@amd.com>
References: <patchbomb.1323876561@gran.amd.com>
	<ef5698887d044ad58293.1323876568@gran.amd.com>
In-Reply-To: <ef5698887d044ad58293.1323876568@gran.amd.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com, keir@xen.org
Subject: Re: [Xen-devel] [PATCH 07 of 16] amd iommu: Add 2 hypercalls for
	libxc
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 14.12.11 at 16:29, Wei Wang <wei.wang2@amd.com> wrote:
> # HG changeset patch
> # User Wei Wang <wei.wang2@amd.com>
> # Date 1323875772 -3600
> # Node ID ef5698887d044ad58293bee3549eaa20310c2b17
> # Parent  fbed4e6011fce13d3a521bbc339f4959bf32a06c
> amd iommu: Add 2 hypercalls for libxc
> 
> iommu_set_msi: used by qemu to inform hypervisor iommu vector number in 
> guest
> space. Hypervisor needs this vector to inject msi into guest when PPR 
> logging
> happens.

And this cannot be done with the existing MSI emulation?

> iommu_bind_bdf: used by xl to bind guest bdf number to machine bdf number.
> IOMMU emulations codes receives commands from guest iommu driver and 
> forwards
> them to host iommu. But virtual device id from guest should be converted 
> into
> physical before sending to real hardware.

The whole logic here needs to take the segment into account. No new
code should again ignore the segment numbers.

> --- a/xen/include/public/domctl.h	Wed Dec 14 16:16:11 2011 +0100
> +++ b/xen/include/public/domctl.h	Wed Dec 14 16:16:12 2011 +0100
> @@ -848,6 +848,31 @@ struct xen_domctl_set_access_required {
>  typedef struct xen_domctl_set_access_required 
> xen_domctl_set_access_required_t;
>  DEFINE_XEN_GUEST_HANDLE(xen_domctl_set_access_required_t);
>  
> +#if defined(__i386__) || defined(__x86_64__)

What is x86-specific about these?

Jan

> +/* Support for guest iommu emulation */
> +struct xen_domctl_guest_iommu_op {
> +    /* XEN_DOMCTL_GUEST_IOMMU_OP_* */
> +#define XEN_DOMCTL_GUEST_IOMMU_OP_SET_MSI               0
> +#define XEN_DOMCTL_GUEST_IOMMU_OP_BIND_BDF              1
> +    uint8_t op;
> +    union {
> +        struct iommu_msi {
> +        uint8_t  vector;
> +        uint8_t  dest;
> +        uint8_t  dest_mode;
> +        uint8_t  delivery_mode;
> +        uint8_t  trig_mode;
> +        } msi;
> +        struct bdf_bind { 
> +            uint32_t            g_bdf;
> +            uint32_t            m_bdf;
> +        } bdf_bind;
> +    } u;
> +};
> +typedef struct xen_domctl_guest_iommu_op xen_domctl_guest_iommu_op_t;
> +DEFINE_XEN_GUEST_HANDLE(xen_domctl_guest_iommu_op_t);
> +#endif
> +
>  struct xen_domctl {
>      uint32_t cmd;
>  #define XEN_DOMCTL_createdomain                   1



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 16:45:35 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 16:45:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RarxF-0008Ba-Os; Wed, 14 Dec 2011 16:45:17 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RarxE-0008BG-VY
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 16:45:17 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1323881060!5506909!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28657 invoked from network); 14 Dec 2011 16:44:20 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-3.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Dec 2011 16:44:20 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 14 Dec 2011 16:44:19 +0000
Message-Id: <4EE8E0720200007800067DDD@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 14 Dec 2011 16:44:18 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Wang" <wei.wang2@amd.com>
References: <patchbomb.1323876561@gran.amd.com>
	<ef5698887d044ad58293.1323876568@gran.amd.com>
In-Reply-To: <ef5698887d044ad58293.1323876568@gran.amd.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com, keir@xen.org
Subject: Re: [Xen-devel] [PATCH 07 of 16] amd iommu: Add 2 hypercalls for
	libxc
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 14.12.11 at 16:29, Wei Wang <wei.wang2@amd.com> wrote:
> # HG changeset patch
> # User Wei Wang <wei.wang2@amd.com>
> # Date 1323875772 -3600
> # Node ID ef5698887d044ad58293bee3549eaa20310c2b17
> # Parent  fbed4e6011fce13d3a521bbc339f4959bf32a06c
> amd iommu: Add 2 hypercalls for libxc
> 
> iommu_set_msi: used by qemu to inform hypervisor iommu vector number in 
> guest
> space. Hypervisor needs this vector to inject msi into guest when PPR 
> logging
> happens.

And this cannot be done with the existing MSI emulation?

> iommu_bind_bdf: used by xl to bind guest bdf number to machine bdf number.
> IOMMU emulations codes receives commands from guest iommu driver and 
> forwards
> them to host iommu. But virtual device id from guest should be converted 
> into
> physical before sending to real hardware.

The whole logic here needs to take the segment into account. No new
code should again ignore the segment numbers.

> --- a/xen/include/public/domctl.h	Wed Dec 14 16:16:11 2011 +0100
> +++ b/xen/include/public/domctl.h	Wed Dec 14 16:16:12 2011 +0100
> @@ -848,6 +848,31 @@ struct xen_domctl_set_access_required {
>  typedef struct xen_domctl_set_access_required 
> xen_domctl_set_access_required_t;
>  DEFINE_XEN_GUEST_HANDLE(xen_domctl_set_access_required_t);
>  
> +#if defined(__i386__) || defined(__x86_64__)

What is x86-specific about these?

Jan

> +/* Support for guest iommu emulation */
> +struct xen_domctl_guest_iommu_op {
> +    /* XEN_DOMCTL_GUEST_IOMMU_OP_* */
> +#define XEN_DOMCTL_GUEST_IOMMU_OP_SET_MSI               0
> +#define XEN_DOMCTL_GUEST_IOMMU_OP_BIND_BDF              1
> +    uint8_t op;
> +    union {
> +        struct iommu_msi {
> +        uint8_t  vector;
> +        uint8_t  dest;
> +        uint8_t  dest_mode;
> +        uint8_t  delivery_mode;
> +        uint8_t  trig_mode;
> +        } msi;
> +        struct bdf_bind { 
> +            uint32_t            g_bdf;
> +            uint32_t            m_bdf;
> +        } bdf_bind;
> +    } u;
> +};
> +typedef struct xen_domctl_guest_iommu_op xen_domctl_guest_iommu_op_t;
> +DEFINE_XEN_GUEST_HANDLE(xen_domctl_guest_iommu_op_t);
> +#endif
> +
>  struct xen_domctl {
>      uint32_t cmd;
>  #define XEN_DOMCTL_createdomain                   1



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 16:57:28 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 16:57:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ras8j-00008s-Nd; Wed, 14 Dec 2011 16:57:09 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Wang2@amd.com>) id 1Ras8j-00008i-5f
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 16:57:09 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1323881773!8255532!1
X-Originating-IP: [213.199.154.205]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26592 invoked from network); 14 Dec 2011 16:56:13 -0000
Received: from am1ehsobe002.messaging.microsoft.com (HELO
	AM1EHSOBE002.bigfish.com) (213.199.154.205)
	by server-3.tower-21.messagelabs.com with AES128-SHA encrypted SMTP;
	14 Dec 2011 16:56:13 -0000
Received: from mail21-am1-R.bigfish.com (10.3.201.241) by
	AM1EHSOBE002.bigfish.com (10.3.204.22) with Microsoft SMTP Server id
	14.1.225.23; Wed, 14 Dec 2011 16:56:15 +0000
Received: from mail21-am1 (localhost [127.0.0.1])	by mail21-am1-R.bigfish.com
	(Postfix) with ESMTP id 4A23A1602AC;
	Wed, 14 Dec 2011 16:56:16 +0000 (UTC)
X-SpamScore: -13
X-BigFish: VPS-13(zz1432N98dK4015Lzz1202hzz8275bhz2dh668h839h)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
X-FB-SS: 0,13,
Received: from mail21-am1 (localhost.localdomain [127.0.0.1]) by mail21-am1
	(MessageSwitch) id 1323881751124207_7840;
	Wed, 14 Dec 2011 16:55:51 +0000 (UTC)
Received: from AM1EHSMHS015.bigfish.com (unknown [10.3.201.252])	by
	mail21-am1.bigfish.com (Postfix) with ESMTP id 156BBE0047;
	Wed, 14 Dec 2011 16:55:51 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	AM1EHSMHS015.bigfish.com (10.3.207.153) with Microsoft SMTP Server id
	14.1.225.23; Wed, 14 Dec 2011 16:55:49 +0000
X-WSS-ID: 0LW7DOV-01-LW4-02
X-M-MSG: 
Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com
	[163.181.249.73])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2BDFA1028056;	Wed, 14 Dec 2011 10:55:42 -0600 (CST)
Received: from SAUSEXDAG01.amd.com (163.181.55.1) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Wed, 14 Dec 2011 10:55:53 -0600
Received: from storexhtp01.amd.com (172.24.4.3) by sausexdag01.amd.com
	(163.181.55.1) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Wed, 14 Dec 2011 10:55:39 -0600
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp01.amd.com
	(172.24.4.3) with Microsoft SMTP Server id 8.3.213.0; Wed, 14 Dec 2011
	11:54:51 -0500
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id EB78049C1FF; Wed, 14 Dec 2011
	16:54:49 +0000 (GMT)
Received: from gran.osrc.amd.com (gran.osrc.amd.com [165.204.15.57])	by
	mail.osrc.amd.com (Postfix) with ESMTP id CDABC5940FF; Wed, 14 Dec 2011
	17:54:49 +0100 (CET)
From: Wei Wang2 <wei.wang2@amd.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Wed, 14 Dec 2011 17:57:33 +0100
User-Agent: KMail/1.9.6 (enterprise 20070904.708012)
References: <patchbomb.1323876561@gran.amd.com>
	<ef5698887d044ad58293.1323876568@gran.amd.com>
	<4EE8E0720200007800067DDD@nat28.tlf.novell.com>
In-Reply-To: <4EE8E0720200007800067DDD@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
Message-ID: <201112141757.33690.wei.wang2@amd.com>
X-OriginatorOrg: amd.com
Cc: xen-devel@lists.xensource.com, keir@xen.org
Subject: Re: [Xen-devel] [PATCH 07 of 16] amd iommu: Add 2 hypercalls for
	libxc
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wednesday 14 December 2011 17:44:18 Jan Beulich wrote:
> >>> On 14.12.11 at 16:29, Wei Wang <wei.wang2@amd.com> wrote:
> >
> > # HG changeset patch
> > # User Wei Wang <wei.wang2@amd.com>
> > # Date 1323875772 -3600
> > # Node ID ef5698887d044ad58293bee3549eaa20310c2b17
> > # Parent  fbed4e6011fce13d3a521bbc339f4959bf32a06c
> > amd iommu: Add 2 hypercalls for libxc
> >
> > iommu_set_msi: used by qemu to inform hypervisor iommu vector number in
> > guest
> > space. Hypervisor needs this vector to inject msi into guest when PPR
> > logging
> > happens.
>
> And this cannot be done with the existing MSI emulation?
It looks like MSI emulation are used for passthru devices. I only add
virtual amd iommu device and do not passthru amd iommu device. So no physcal 
msi are required and therefore complicate msi emulation might not be very 
necessary?

> > iommu_bind_bdf: used by xl to bind guest bdf number to machine bdf
> > number. IOMMU emulations codes receives commands from guest iommu driver
> > and forwards
> > them to host iommu. But virtual device id from guest should be converted
> > into
> > physical before sending to real hardware.
>
> The whole logic here needs to take the segment into account. No new
> code should again ignore the segment numbers.
Sure, I will fix that.

> > --- a/xen/include/public/domctl.h	Wed Dec 14 16:16:11 2011 +0100
> > +++ b/xen/include/public/domctl.h	Wed Dec 14 16:16:12 2011 +0100
> > @@ -848,6 +848,31 @@ struct xen_domctl_set_access_required {
> >  typedef struct xen_domctl_set_access_required
> > xen_domctl_set_access_required_t;
> >  DEFINE_XEN_GUEST_HANDLE(xen_domctl_set_access_required_t);
> >
> > +#if defined(__i386__) || defined(__x86_64__)
>
> What is x86-specific about these?
These hypercalls are only used by AMD. so ia64 should be avoided

Thanks,
Wei

> Jan
>
> > +/* Support for guest iommu emulation */
> > +struct xen_domctl_guest_iommu_op {
> > +    /* XEN_DOMCTL_GUEST_IOMMU_OP_* */
> > +#define XEN_DOMCTL_GUEST_IOMMU_OP_SET_MSI               0
> > +#define XEN_DOMCTL_GUEST_IOMMU_OP_BIND_BDF              1
> > +    uint8_t op;
> > +    union {
> > +        struct iommu_msi {
> > +        uint8_t  vector;
> > +        uint8_t  dest;
> > +        uint8_t  dest_mode;
> > +        uint8_t  delivery_mode;
> > +        uint8_t  trig_mode;
> > +        } msi;
> > +        struct bdf_bind {
> > +            uint32_t            g_bdf;
> > +            uint32_t            m_bdf;
> > +        } bdf_bind;
> > +    } u;
> > +};
> > +typedef struct xen_domctl_guest_iommu_op xen_domctl_guest_iommu_op_t;
> > +DEFINE_XEN_GUEST_HANDLE(xen_domctl_guest_iommu_op_t);
> > +#endif
> > +
> >  struct xen_domctl {
> >      uint32_t cmd;
> >  #define XEN_DOMCTL_createdomain                   1




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 16:57:28 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 16:57:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ras8j-00008s-Nd; Wed, 14 Dec 2011 16:57:09 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Wang2@amd.com>) id 1Ras8j-00008i-5f
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 16:57:09 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1323881773!8255532!1
X-Originating-IP: [213.199.154.205]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26592 invoked from network); 14 Dec 2011 16:56:13 -0000
Received: from am1ehsobe002.messaging.microsoft.com (HELO
	AM1EHSOBE002.bigfish.com) (213.199.154.205)
	by server-3.tower-21.messagelabs.com with AES128-SHA encrypted SMTP;
	14 Dec 2011 16:56:13 -0000
Received: from mail21-am1-R.bigfish.com (10.3.201.241) by
	AM1EHSOBE002.bigfish.com (10.3.204.22) with Microsoft SMTP Server id
	14.1.225.23; Wed, 14 Dec 2011 16:56:15 +0000
Received: from mail21-am1 (localhost [127.0.0.1])	by mail21-am1-R.bigfish.com
	(Postfix) with ESMTP id 4A23A1602AC;
	Wed, 14 Dec 2011 16:56:16 +0000 (UTC)
X-SpamScore: -13
X-BigFish: VPS-13(zz1432N98dK4015Lzz1202hzz8275bhz2dh668h839h)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
X-FB-SS: 0,13,
Received: from mail21-am1 (localhost.localdomain [127.0.0.1]) by mail21-am1
	(MessageSwitch) id 1323881751124207_7840;
	Wed, 14 Dec 2011 16:55:51 +0000 (UTC)
Received: from AM1EHSMHS015.bigfish.com (unknown [10.3.201.252])	by
	mail21-am1.bigfish.com (Postfix) with ESMTP id 156BBE0047;
	Wed, 14 Dec 2011 16:55:51 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	AM1EHSMHS015.bigfish.com (10.3.207.153) with Microsoft SMTP Server id
	14.1.225.23; Wed, 14 Dec 2011 16:55:49 +0000
X-WSS-ID: 0LW7DOV-01-LW4-02
X-M-MSG: 
Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com
	[163.181.249.73])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2BDFA1028056;	Wed, 14 Dec 2011 10:55:42 -0600 (CST)
Received: from SAUSEXDAG01.amd.com (163.181.55.1) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Wed, 14 Dec 2011 10:55:53 -0600
Received: from storexhtp01.amd.com (172.24.4.3) by sausexdag01.amd.com
	(163.181.55.1) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Wed, 14 Dec 2011 10:55:39 -0600
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp01.amd.com
	(172.24.4.3) with Microsoft SMTP Server id 8.3.213.0; Wed, 14 Dec 2011
	11:54:51 -0500
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id EB78049C1FF; Wed, 14 Dec 2011
	16:54:49 +0000 (GMT)
Received: from gran.osrc.amd.com (gran.osrc.amd.com [165.204.15.57])	by
	mail.osrc.amd.com (Postfix) with ESMTP id CDABC5940FF; Wed, 14 Dec 2011
	17:54:49 +0100 (CET)
From: Wei Wang2 <wei.wang2@amd.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Wed, 14 Dec 2011 17:57:33 +0100
User-Agent: KMail/1.9.6 (enterprise 20070904.708012)
References: <patchbomb.1323876561@gran.amd.com>
	<ef5698887d044ad58293.1323876568@gran.amd.com>
	<4EE8E0720200007800067DDD@nat28.tlf.novell.com>
In-Reply-To: <4EE8E0720200007800067DDD@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
Message-ID: <201112141757.33690.wei.wang2@amd.com>
X-OriginatorOrg: amd.com
Cc: xen-devel@lists.xensource.com, keir@xen.org
Subject: Re: [Xen-devel] [PATCH 07 of 16] amd iommu: Add 2 hypercalls for
	libxc
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wednesday 14 December 2011 17:44:18 Jan Beulich wrote:
> >>> On 14.12.11 at 16:29, Wei Wang <wei.wang2@amd.com> wrote:
> >
> > # HG changeset patch
> > # User Wei Wang <wei.wang2@amd.com>
> > # Date 1323875772 -3600
> > # Node ID ef5698887d044ad58293bee3549eaa20310c2b17
> > # Parent  fbed4e6011fce13d3a521bbc339f4959bf32a06c
> > amd iommu: Add 2 hypercalls for libxc
> >
> > iommu_set_msi: used by qemu to inform hypervisor iommu vector number in
> > guest
> > space. Hypervisor needs this vector to inject msi into guest when PPR
> > logging
> > happens.
>
> And this cannot be done with the existing MSI emulation?
It looks like MSI emulation are used for passthru devices. I only add
virtual amd iommu device and do not passthru amd iommu device. So no physcal 
msi are required and therefore complicate msi emulation might not be very 
necessary?

> > iommu_bind_bdf: used by xl to bind guest bdf number to machine bdf
> > number. IOMMU emulations codes receives commands from guest iommu driver
> > and forwards
> > them to host iommu. But virtual device id from guest should be converted
> > into
> > physical before sending to real hardware.
>
> The whole logic here needs to take the segment into account. No new
> code should again ignore the segment numbers.
Sure, I will fix that.

> > --- a/xen/include/public/domctl.h	Wed Dec 14 16:16:11 2011 +0100
> > +++ b/xen/include/public/domctl.h	Wed Dec 14 16:16:12 2011 +0100
> > @@ -848,6 +848,31 @@ struct xen_domctl_set_access_required {
> >  typedef struct xen_domctl_set_access_required
> > xen_domctl_set_access_required_t;
> >  DEFINE_XEN_GUEST_HANDLE(xen_domctl_set_access_required_t);
> >
> > +#if defined(__i386__) || defined(__x86_64__)
>
> What is x86-specific about these?
These hypercalls are only used by AMD. so ia64 should be avoided

Thanks,
Wei

> Jan
>
> > +/* Support for guest iommu emulation */
> > +struct xen_domctl_guest_iommu_op {
> > +    /* XEN_DOMCTL_GUEST_IOMMU_OP_* */
> > +#define XEN_DOMCTL_GUEST_IOMMU_OP_SET_MSI               0
> > +#define XEN_DOMCTL_GUEST_IOMMU_OP_BIND_BDF              1
> > +    uint8_t op;
> > +    union {
> > +        struct iommu_msi {
> > +        uint8_t  vector;
> > +        uint8_t  dest;
> > +        uint8_t  dest_mode;
> > +        uint8_t  delivery_mode;
> > +        uint8_t  trig_mode;
> > +        } msi;
> > +        struct bdf_bind {
> > +            uint32_t            g_bdf;
> > +            uint32_t            m_bdf;
> > +        } bdf_bind;
> > +    } u;
> > +};
> > +typedef struct xen_domctl_guest_iommu_op xen_domctl_guest_iommu_op_t;
> > +DEFINE_XEN_GUEST_HANDLE(xen_domctl_guest_iommu_op_t);
> > +#endif
> > +
> >  struct xen_domctl {
> >      uint32_t cmd;
> >  #define XEN_DOMCTL_createdomain                   1




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 16:58:30 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 16: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.xensource.com>)
	id 1Ras9o-0000FD-7D; Wed, 14 Dec 2011 16:58:16 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Ras9n-0000Ez-29
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 16:58:15 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1323881800!49012396!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTc4Ng==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11941 invoked from network); 14 Dec 2011 16:56:40 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Dec 2011 16:56:40 -0000
X-IronPort-AV: E=Sophos;i="4.71,353,1320624000"; 
   d="scan'208";a="9471117"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Dec 2011 16:57:24 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 14 Dec 2011 16:57:24 +0000
Date: Wed, 14 Dec 2011 16:59:29 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
In-Reply-To: <20200.36536.187256.61611@mariner.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1112141641280.3517@kaball-desktop>
References: <alpine.DEB.2.00.1111221551510.31179@kaball-desktop>
	<1322056320-5826-5-git-send-email-stefano.stabellini@eu.citrix.com>
	<20198.15417.932169.223332@mariner.uk.xensource.com>
	<1323712001.20077.234.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1112121924520.3517@kaball-desktop>
	<20199.24118.465585.933183@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1112131720250.3517@kaball-desktop>
	<20199.37117.779165.894809@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1112131817300.3517@kaball-desktop>
	<1323855739.20077.365.camel@zakaz.uk.xensource.com>
	<20200.36536.187256.61611@mariner.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v9 5/6] Clone and build Seabios by default
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 14 Dec 2011, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [PATCH v9 5/6] Clone and build Seabios by default"):
> > Unfortunately I expect that distros will want to package qemu once (from
> > upstream) with support for all the various options, including Xen,
> > enabled and depend on that in their Xen packaging rather than packaging
> > a slightly different qemu a second time.
> 
> Quite.

Considering that Qemu releases are not in sync with our releases, I
think that we should point xen-unstable to one of our own Qemu trees
rather than just a mirror of the Qemu stable branch on xenbits.
Otherwise we risk loosing important features, for example if there are
not going to be any new Qemu releases before Xen 4.2 is out, we are
going to miss pci passthrough and save/restore, while if we had our own
branch we would have them.
Of course it is still very important to keep Qemu stable branches stable
and functional, so that if distros decide to package a single upstream
Qemu, it still going to work fine, even though it is going to have fewer
features.


> > > I don't have an opinion on seabios because I am nore sure how many
> > > changes are we going to make to it. However I recall that you and/or
> > > IanC were in favor of having or own branch of seabios as well.
> > 
> > I think that even if we never diverge from upstream and irrespective of
> > whether we stick in lockstep or not we should host a tree to point our
> > users (and default build) at. This gives us flexibility if we ever do
> > need to diverge and also isolates our users from issues with 3rd party
> > servers.
> 
> Indeed so.  But should it be one tree for each Xen branch, and does it
> need a push gate ?
 
I think we might do without a tree for each Xen branch because we need
to support building upstream Qemu against Xen 4.2+ anyway.
Let's say that we have released Xen 4.2, we are now in the Xen 4.3
release cycle and we want to introduce an incompatible change in Qemu:
we would need to add a compatibility layer to allow it to build and run
on Xen 4.2 anyway.
The difficulty having a single tree would be keeping track of the
changes only present in our own tree, and possibly revert them before
pulling new commits from upstream that implement the same features in a
different way.

Regarding the push-gate, I am OK with it.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 16:58:30 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 16: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.xensource.com>)
	id 1Ras9o-0000FD-7D; Wed, 14 Dec 2011 16:58:16 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Ras9n-0000Ez-29
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 16:58:15 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1323881800!49012396!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTc4Ng==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11941 invoked from network); 14 Dec 2011 16:56:40 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Dec 2011 16:56:40 -0000
X-IronPort-AV: E=Sophos;i="4.71,353,1320624000"; 
   d="scan'208";a="9471117"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Dec 2011 16:57:24 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 14 Dec 2011 16:57:24 +0000
Date: Wed, 14 Dec 2011 16:59:29 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
In-Reply-To: <20200.36536.187256.61611@mariner.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1112141641280.3517@kaball-desktop>
References: <alpine.DEB.2.00.1111221551510.31179@kaball-desktop>
	<1322056320-5826-5-git-send-email-stefano.stabellini@eu.citrix.com>
	<20198.15417.932169.223332@mariner.uk.xensource.com>
	<1323712001.20077.234.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1112121924520.3517@kaball-desktop>
	<20199.24118.465585.933183@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1112131720250.3517@kaball-desktop>
	<20199.37117.779165.894809@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1112131817300.3517@kaball-desktop>
	<1323855739.20077.365.camel@zakaz.uk.xensource.com>
	<20200.36536.187256.61611@mariner.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v9 5/6] Clone and build Seabios by default
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 14 Dec 2011, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [PATCH v9 5/6] Clone and build Seabios by default"):
> > Unfortunately I expect that distros will want to package qemu once (from
> > upstream) with support for all the various options, including Xen,
> > enabled and depend on that in their Xen packaging rather than packaging
> > a slightly different qemu a second time.
> 
> Quite.

Considering that Qemu releases are not in sync with our releases, I
think that we should point xen-unstable to one of our own Qemu trees
rather than just a mirror of the Qemu stable branch on xenbits.
Otherwise we risk loosing important features, for example if there are
not going to be any new Qemu releases before Xen 4.2 is out, we are
going to miss pci passthrough and save/restore, while if we had our own
branch we would have them.
Of course it is still very important to keep Qemu stable branches stable
and functional, so that if distros decide to package a single upstream
Qemu, it still going to work fine, even though it is going to have fewer
features.


> > > I don't have an opinion on seabios because I am nore sure how many
> > > changes are we going to make to it. However I recall that you and/or
> > > IanC were in favor of having or own branch of seabios as well.
> > 
> > I think that even if we never diverge from upstream and irrespective of
> > whether we stick in lockstep or not we should host a tree to point our
> > users (and default build) at. This gives us flexibility if we ever do
> > need to diverge and also isolates our users from issues with 3rd party
> > servers.
> 
> Indeed so.  But should it be one tree for each Xen branch, and does it
> need a push gate ?
 
I think we might do without a tree for each Xen branch because we need
to support building upstream Qemu against Xen 4.2+ anyway.
Let's say that we have released Xen 4.2, we are now in the Xen 4.3
release cycle and we want to introduce an incompatible change in Qemu:
we would need to add a compatibility layer to allow it to build and run
on Xen 4.2 anyway.
The difficulty having a single tree would be keeping track of the
changes only present in our own tree, and possibly revert them before
pulling new commits from upstream that implement the same features in a
different way.

Regarding the push-gate, I am OK with it.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 16:58:41 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 16:58:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ras9z-0000Gz-Kf; Wed, 14 Dec 2011 16:58:27 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1Ras9y-0000G0-D6
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 16:58:26 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-2.tower-182.messagelabs.com!1323881849!7273733!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17745 invoked from network); 14 Dec 2011 16:57:30 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-2.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Dec 2011 16:57:30 -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
	pBEGvIQr012071
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Wed, 14 Dec 2011 11:57:18 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pBEGvIXa012069;
	Wed, 14 Dec 2011 11:57:18 -0500
Date: Wed, 14 Dec 2011 12:57:18 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: David Vrabel <david.vrabel@citrix.com>
Message-ID: <20111214165718.GA10763@andromeda.dapyr.net>
References: <4EE675A8.3030609@niemail.de> <4EE71663.5040308@gmail.com>
	<CAJeBh4sxdNTxM_oLFAuA6Mw75=LaYysrpS5b8NsZMbkf_swNVw@mail.gmail.com>
	<4EE72A94.6040904@gmail.com> <4EE75080.1000909@citrix.com>
	<4EE7BE1B.6070509@gmail.com>
	<20111213214522.GB29005@andromeda.dapyr.net>
	<4EE89654.5040905@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4EE89654.5040905@citrix.com>
User-Agent: Mutt/1.5.9i
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	George Shuklin <george.shuklin@gmail.com>,
	"sandr8@gmail.com" <sandr8@gmail.com>
Subject: Re: [Xen-devel] a ton of kernel issues
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Dec 14, 2011 at 12:28:04PM +0000, David Vrabel wrote:
> On 13/12/11 21:45, Konrad Rzeszutek Wilk wrote:
> > On Wed, Dec 14, 2011 at 01:05:31AM +0400, George Shuklin wrote:
> >>
> >> On 13.12.2011 17:17, David Vrabel wrote:
> >>>>>> pv_ops is still have some issues with memory limits, but any
> >>>>>> new kernel (3.0+) will boot normal and operates with very
> >>>>>> minor glitches. Older pv_ops (f.e. debian 2.6.32) have some
> >>>>>> more major issues.
> >>>>> what glitches should one expect with 3.0+, and having the choice,
> >>>>> would it be better to go with 3.1 or even 3.2?
> >>>> Right now I know about two of them:
> >>>> When you set up memory for virtual machine using xenballon, value in
> >>>> dom0 differ from value in domU. The issue is that -xen kernels 'hide'
> >>>> some memory in 'used' memory, and pv-ops just reducing TotalMem to value
> >>>> without that memory. Practically that means if you set up memory for
> >>>> domain to 2GiB client will saw only 1.95GiB and so on.
> >>> This really makes no practical difference.  The memory is "used" is
> >>> either case and the different reporting is a side-effect of the change
> >>> in how certain memory allocations are done.
> > 
> > David,
> > 
> > You are thinking that this is the vmalloc vs kmalloc memory for the
> > frontends?
> 
> That wasn't what I was thinking.  When I looked (not very hard) at this
> in dom0 I thought most of it was the swiotlb buffer.

Ok, that is dom0, but for domU the swiotlb buffer should not be enabled.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 16:58:41 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 16:58:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ras9z-0000Gz-Kf; Wed, 14 Dec 2011 16:58:27 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1Ras9y-0000G0-D6
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 16:58:26 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-2.tower-182.messagelabs.com!1323881849!7273733!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17745 invoked from network); 14 Dec 2011 16:57:30 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-2.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Dec 2011 16:57:30 -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
	pBEGvIQr012071
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Wed, 14 Dec 2011 11:57:18 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pBEGvIXa012069;
	Wed, 14 Dec 2011 11:57:18 -0500
Date: Wed, 14 Dec 2011 12:57:18 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: David Vrabel <david.vrabel@citrix.com>
Message-ID: <20111214165718.GA10763@andromeda.dapyr.net>
References: <4EE675A8.3030609@niemail.de> <4EE71663.5040308@gmail.com>
	<CAJeBh4sxdNTxM_oLFAuA6Mw75=LaYysrpS5b8NsZMbkf_swNVw@mail.gmail.com>
	<4EE72A94.6040904@gmail.com> <4EE75080.1000909@citrix.com>
	<4EE7BE1B.6070509@gmail.com>
	<20111213214522.GB29005@andromeda.dapyr.net>
	<4EE89654.5040905@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4EE89654.5040905@citrix.com>
User-Agent: Mutt/1.5.9i
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	George Shuklin <george.shuklin@gmail.com>,
	"sandr8@gmail.com" <sandr8@gmail.com>
Subject: Re: [Xen-devel] a ton of kernel issues
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Dec 14, 2011 at 12:28:04PM +0000, David Vrabel wrote:
> On 13/12/11 21:45, Konrad Rzeszutek Wilk wrote:
> > On Wed, Dec 14, 2011 at 01:05:31AM +0400, George Shuklin wrote:
> >>
> >> On 13.12.2011 17:17, David Vrabel wrote:
> >>>>>> pv_ops is still have some issues with memory limits, but any
> >>>>>> new kernel (3.0+) will boot normal and operates with very
> >>>>>> minor glitches. Older pv_ops (f.e. debian 2.6.32) have some
> >>>>>> more major issues.
> >>>>> what glitches should one expect with 3.0+, and having the choice,
> >>>>> would it be better to go with 3.1 or even 3.2?
> >>>> Right now I know about two of them:
> >>>> When you set up memory for virtual machine using xenballon, value in
> >>>> dom0 differ from value in domU. The issue is that -xen kernels 'hide'
> >>>> some memory in 'used' memory, and pv-ops just reducing TotalMem to value
> >>>> without that memory. Practically that means if you set up memory for
> >>>> domain to 2GiB client will saw only 1.95GiB and so on.
> >>> This really makes no practical difference.  The memory is "used" is
> >>> either case and the different reporting is a side-effect of the change
> >>> in how certain memory allocations are done.
> > 
> > David,
> > 
> > You are thinking that this is the vmalloc vs kmalloc memory for the
> > frontends?
> 
> That wasn't what I was thinking.  When I looked (not very hard) at this
> in dom0 I thought most of it was the swiotlb buffer.

Ok, that is dom0, but for domU the swiotlb buffer should not be enabled.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 17:05:10 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 17: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.xensource.com>)
	id 1RasGE-0000tr-Ft; Wed, 14 Dec 2011 17:04:54 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RasGD-0000tb-55
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 17:04:53 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1323882236!5364342!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7731 invoked from network); 14 Dec 2011 17:03:57 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-14.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Dec 2011 17:03:57 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 14 Dec 2011 17:03:56 +0000
Message-Id: <4EE8E50A0200007800067E44@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 14 Dec 2011 17:03:54 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Wang2" <wei.wang2@amd.com>
References: <patchbomb.1323876561@gran.amd.com>
	<ef5698887d044ad58293.1323876568@gran.amd.com>
	<4EE8E0720200007800067DDD@nat28.tlf.novell.com>
	<201112141757.33690.wei.wang2@amd.com>
In-Reply-To: <201112141757.33690.wei.wang2@amd.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com, keir@xen.org
Subject: Re: [Xen-devel] [PATCH 07 of 16] amd iommu: Add 2 hypercalls for
	libxc
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 14.12.11 at 17:57, Wei Wang2 <wei.wang2@amd.com> wrote:
> On Wednesday 14 December 2011 17:44:18 Jan Beulich wrote:
>> >>> On 14.12.11 at 16:29, Wei Wang <wei.wang2@amd.com> wrote:
>> >
>> > # HG changeset patch
>> > # User Wei Wang <wei.wang2@amd.com>
>> > # Date 1323875772 -3600
>> > # Node ID ef5698887d044ad58293bee3549eaa20310c2b17
>> > # Parent  fbed4e6011fce13d3a521bbc339f4959bf32a06c
>> > amd iommu: Add 2 hypercalls for libxc
>> >
>> > iommu_set_msi: used by qemu to inform hypervisor iommu vector number in
>> > guest
>> > space. Hypervisor needs this vector to inject msi into guest when PPR
>> > logging
>> > happens.
>>
>> And this cannot be done with the existing MSI emulation?
> It looks like MSI emulation are used for passthru devices. I only add
> virtual amd iommu device and do not passthru amd iommu device. So no physcal 
> msi are required and therefore complicate msi emulation might not be very 
> necessary?

Makes sense.

>> > --- a/xen/include/public/domctl.h	Wed Dec 14 16:16:11 2011 +0100
>> > +++ b/xen/include/public/domctl.h	Wed Dec 14 16:16:12 2011 +0100
>> > @@ -848,6 +848,31 @@ struct xen_domctl_set_access_required {
>> >  typedef struct xen_domctl_set_access_required
>> > xen_domctl_set_access_required_t;
>> >  DEFINE_XEN_GUEST_HANDLE(xen_domctl_set_access_required_t);
>> >
>> > +#if defined(__i386__) || defined(__x86_64__)
>>
>> What is x86-specific about these?
> These hypercalls are only used by AMD. so ia64 should be avoided

Currently. But is there anything in them that makes them unusable
for other IOMMUs in the future (from what I can tell only PCI and MSI
are fundamentally required, which are certainly present on other
platforms)? After all, this is just a type definition and a few manifest
constants - I'm not asking that their implementation should be done
for other than the case you care about right now.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 17:05:10 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 17: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.xensource.com>)
	id 1RasGE-0000tr-Ft; Wed, 14 Dec 2011 17:04:54 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RasGD-0000tb-55
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 17:04:53 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1323882236!5364342!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7731 invoked from network); 14 Dec 2011 17:03:57 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-14.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Dec 2011 17:03:57 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 14 Dec 2011 17:03:56 +0000
Message-Id: <4EE8E50A0200007800067E44@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 14 Dec 2011 17:03:54 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Wang2" <wei.wang2@amd.com>
References: <patchbomb.1323876561@gran.amd.com>
	<ef5698887d044ad58293.1323876568@gran.amd.com>
	<4EE8E0720200007800067DDD@nat28.tlf.novell.com>
	<201112141757.33690.wei.wang2@amd.com>
In-Reply-To: <201112141757.33690.wei.wang2@amd.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com, keir@xen.org
Subject: Re: [Xen-devel] [PATCH 07 of 16] amd iommu: Add 2 hypercalls for
	libxc
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 14.12.11 at 17:57, Wei Wang2 <wei.wang2@amd.com> wrote:
> On Wednesday 14 December 2011 17:44:18 Jan Beulich wrote:
>> >>> On 14.12.11 at 16:29, Wei Wang <wei.wang2@amd.com> wrote:
>> >
>> > # HG changeset patch
>> > # User Wei Wang <wei.wang2@amd.com>
>> > # Date 1323875772 -3600
>> > # Node ID ef5698887d044ad58293bee3549eaa20310c2b17
>> > # Parent  fbed4e6011fce13d3a521bbc339f4959bf32a06c
>> > amd iommu: Add 2 hypercalls for libxc
>> >
>> > iommu_set_msi: used by qemu to inform hypervisor iommu vector number in
>> > guest
>> > space. Hypervisor needs this vector to inject msi into guest when PPR
>> > logging
>> > happens.
>>
>> And this cannot be done with the existing MSI emulation?
> It looks like MSI emulation are used for passthru devices. I only add
> virtual amd iommu device and do not passthru amd iommu device. So no physcal 
> msi are required and therefore complicate msi emulation might not be very 
> necessary?

Makes sense.

>> > --- a/xen/include/public/domctl.h	Wed Dec 14 16:16:11 2011 +0100
>> > +++ b/xen/include/public/domctl.h	Wed Dec 14 16:16:12 2011 +0100
>> > @@ -848,6 +848,31 @@ struct xen_domctl_set_access_required {
>> >  typedef struct xen_domctl_set_access_required
>> > xen_domctl_set_access_required_t;
>> >  DEFINE_XEN_GUEST_HANDLE(xen_domctl_set_access_required_t);
>> >
>> > +#if defined(__i386__) || defined(__x86_64__)
>>
>> What is x86-specific about these?
> These hypercalls are only used by AMD. so ia64 should be avoided

Currently. But is there anything in them that makes them unusable
for other IOMMUs in the future (from what I can tell only PCI and MSI
are fundamentally required, which are certainly present on other
platforms)? After all, this is just a type definition and a few manifest
constants - I'm not asking that their implementation should be done
for other than the case you care about right now.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 17:46:10 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 17:46:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rastj-00029B-40; Wed, 14 Dec 2011 17:45:43 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1Rasti-000291-6D
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 17:45:42 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-3.tower-174.messagelabs.com!1323884682!5514500!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29738 invoked from network); 14 Dec 2011 17:44:44 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-3.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Dec 2011 17:44:44 -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
	pBEHiach015162
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Wed, 14 Dec 2011 12:44:36 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pBEHiZ78015160;
	Wed, 14 Dec 2011 12:44:35 -0500
Date: Wed, 14 Dec 2011 13:44:35 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20111214174435.GB10763@andromeda.dapyr.net>
References: <4EE71663.5040308@gmail.com>
	<CAJeBh4sxdNTxM_oLFAuA6Mw75=LaYysrpS5b8NsZMbkf_swNVw@mail.gmail.com>
	<4EE72A94.6040904@gmail.com> <4EE75080.1000909@citrix.com>
	<1323783428.20077.298.camel@zakaz.uk.xensource.com>
	<4EE7BC9B.6040003@gmail.com>
	<1323815427.20936.96.camel@dagon.hellion.org.uk>
	<4EE7D75B.6080209@gmail.com>
	<1323847523.20936.110.camel@dagon.hellion.org.uk>
	<1323864969.20077.405.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1323864969.20077.405.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.9i
Cc: "sandr8@gmail.com" <sandr8@gmail.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	George Shuklin <george.shuklin@gmail.com>,
	David Vrabel <david.vrabel@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] a ton of kernel issues
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Dec 14, 2011 at 12:16:08PM +0000, Ian Campbell wrote:
> On Wed, 2011-12-14 at 07:25 +0000, Ian Campbell wrote:
> > 
> > It controls precisely the behaviour you need! Try "maxmem=2048" and
> > "memory=1024" in your guest configuration, it should boot with 1G of
> > RAM and allow you to balloon to 2G and back. 
> 
> I take it back, there is indeed a bug in the PV ops kernel in this
> regard.
> 
> It works with xm/xend because they set the maximum reservation for
> guests to static-max on boot. xl (and, I think, xapi) instead set the
> maximum reservation to the current balloon target and change it
> dynamically as the target is changed (as a method of enforcing the
> targets). However the pvops kernel incorrectly uses the maximum
> reservation at boot to size the physical address space for guests.
> 
> The patch below fixes this.

Yup. It fixes it when using 'xl'. Thx
> 
> Ian.
> 
> 8<-------------------------------------------------------------
> 
> >From 649ca3b7ddca1cdda85c27e34f806f30484172ec Mon Sep 17 00:00:00 2001
> From: Ian Campbell <ian.campbell@citrix.com>
> Date: Wed, 14 Dec 2011 12:00:38 +0000
> Subject: [PATCH] xen: only limit memory map to maximum reservation for domain 0.
> 
> d312ae878b6a "xen: use maximum reservation to limit amount of usable RAM"
> clamped the total amount of RAM to the current maximum reservation. This is
> correct for dom0 but is not correct for guest domains. In order to boot a guest
> "pre-ballooned" (e.g. with memory=1G but maxmem=2G) in order to allow for
> future memory expansion the guest must derive max_pfn from the e820 provided by
> the toolstack and not the current maximum reservation (which can reflect only
> the current maximum, not the guest lifetime max). The existing algorithm
> already behaves this correctly if we do not artificially limit the maximum
> number of pages for the guest case.
> 
> For a guest booted with maxmem=512, memory=128 this results in:
>  [    0.000000] BIOS-provided physical RAM map:
>  [    0.000000]  Xen: 0000000000000000 - 00000000000a0000 (usable)
>  [    0.000000]  Xen: 00000000000a0000 - 0000000000100000 (reserved)
> -[    0.000000]  Xen: 0000000000100000 - 0000000008100000 (usable)
> -[    0.000000]  Xen: 0000000008100000 - 0000000020800000 (unusable)
> +[    0.000000]  Xen: 0000000000100000 - 0000000020800000 (usable)
> ...
>  [    0.000000] NX (Execute Disable) protection: active
>  [    0.000000] DMI not present or invalid.
>  [    0.000000] e820 update range: 0000000000000000 - 0000000000010000 (usable) ==> (reserved)
>  [    0.000000] e820 remove range: 00000000000a0000 - 0000000000100000 (usable)
> -[    0.000000] last_pfn = 0x8100 max_arch_pfn = 0x1000000
> +[    0.000000] last_pfn = 0x20800 max_arch_pfn = 0x1000000
>  [    0.000000] initial memory mapped : 0 - 027ff000
>  [    0.000000] Base memory trampoline at [c009f000] 9f000 size 4096
> -[    0.000000] init_memory_mapping: 0000000000000000-0000000008100000
> -[    0.000000]  0000000000 - 0008100000 page 4k
> -[    0.000000] kernel direct mapping tables up to 8100000 @ 27bb000-27ff000
> +[    0.000000] init_memory_mapping: 0000000000000000-0000000020800000
> +[    0.000000]  0000000000 - 0020800000 page 4k
> +[    0.000000] kernel direct mapping tables up to 20800000 @ 26f8000-27ff000
>  [    0.000000] xen: setting RW the range 27e8000 - 27ff000
>  [    0.000000] 0MB HIGHMEM available.
> -[    0.000000] 129MB LOWMEM available.
> -[    0.000000]   mapped low ram: 0 - 08100000
> -[    0.000000]   low ram: 0 - 08100000
> +[    0.000000] 520MB LOWMEM available.
> +[    0.000000]   mapped low ram: 0 - 20800000
> +[    0.000000]   low ram: 0 - 20800000
> 
> With this change "xl mem-set <domain> 512M" will successfully increase the
> guest RAM (by reducing the balloon).
> 
> There is no change for dom0.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> Cc: stable@kernel.org
> Cc: David Vrabel <david.vrabel@citrix.com>
> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> ---
>  arch/x86/xen/setup.c |   18 +++++++++++++++---
>  1 files changed, 15 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
> index 38d0af4..a54ff1a 100644
> --- a/arch/x86/xen/setup.c
> +++ b/arch/x86/xen/setup.c
> @@ -173,9 +173,21 @@ static unsigned long __init xen_get_max_pages(void)
>  	domid_t domid = DOMID_SELF;
>  	int ret;
>  
> -	ret = HYPERVISOR_memory_op(XENMEM_maximum_reservation, &domid);
> -	if (ret > 0)
> -		max_pages = ret;
> +	/*
> +	 * For the initial domain we use the maximum reservation as
> +	 * the maximum page.
> +	 *
> +	 * For guest domains the current maximum reservation reflects
> +	 * the current maximum rather than the static maximum. In this
> +	 * case the e820 map provided to us will cover the static
> +	 * maximum region.
> +	 */
> +	if (xen_initial_domain()) {
> +		ret = HYPERVISOR_memory_op(XENMEM_maximum_reservation, &domid);
> +		if (ret > 0)
> +			max_pages = ret;
> +	}
> +
>  	return min(max_pages, MAX_DOMAIN_PAGES);
>  }
>  
> -- 
> 1.7.2.5
> 
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 17:46:10 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 17:46:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rastj-00029B-40; Wed, 14 Dec 2011 17:45:43 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1Rasti-000291-6D
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 17:45:42 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-3.tower-174.messagelabs.com!1323884682!5514500!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29738 invoked from network); 14 Dec 2011 17:44:44 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-3.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Dec 2011 17:44:44 -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
	pBEHiach015162
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Wed, 14 Dec 2011 12:44:36 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pBEHiZ78015160;
	Wed, 14 Dec 2011 12:44:35 -0500
Date: Wed, 14 Dec 2011 13:44:35 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20111214174435.GB10763@andromeda.dapyr.net>
References: <4EE71663.5040308@gmail.com>
	<CAJeBh4sxdNTxM_oLFAuA6Mw75=LaYysrpS5b8NsZMbkf_swNVw@mail.gmail.com>
	<4EE72A94.6040904@gmail.com> <4EE75080.1000909@citrix.com>
	<1323783428.20077.298.camel@zakaz.uk.xensource.com>
	<4EE7BC9B.6040003@gmail.com>
	<1323815427.20936.96.camel@dagon.hellion.org.uk>
	<4EE7D75B.6080209@gmail.com>
	<1323847523.20936.110.camel@dagon.hellion.org.uk>
	<1323864969.20077.405.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1323864969.20077.405.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.9i
Cc: "sandr8@gmail.com" <sandr8@gmail.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	George Shuklin <george.shuklin@gmail.com>,
	David Vrabel <david.vrabel@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] a ton of kernel issues
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Dec 14, 2011 at 12:16:08PM +0000, Ian Campbell wrote:
> On Wed, 2011-12-14 at 07:25 +0000, Ian Campbell wrote:
> > 
> > It controls precisely the behaviour you need! Try "maxmem=2048" and
> > "memory=1024" in your guest configuration, it should boot with 1G of
> > RAM and allow you to balloon to 2G and back. 
> 
> I take it back, there is indeed a bug in the PV ops kernel in this
> regard.
> 
> It works with xm/xend because they set the maximum reservation for
> guests to static-max on boot. xl (and, I think, xapi) instead set the
> maximum reservation to the current balloon target and change it
> dynamically as the target is changed (as a method of enforcing the
> targets). However the pvops kernel incorrectly uses the maximum
> reservation at boot to size the physical address space for guests.
> 
> The patch below fixes this.

Yup. It fixes it when using 'xl'. Thx
> 
> Ian.
> 
> 8<-------------------------------------------------------------
> 
> >From 649ca3b7ddca1cdda85c27e34f806f30484172ec Mon Sep 17 00:00:00 2001
> From: Ian Campbell <ian.campbell@citrix.com>
> Date: Wed, 14 Dec 2011 12:00:38 +0000
> Subject: [PATCH] xen: only limit memory map to maximum reservation for domain 0.
> 
> d312ae878b6a "xen: use maximum reservation to limit amount of usable RAM"
> clamped the total amount of RAM to the current maximum reservation. This is
> correct for dom0 but is not correct for guest domains. In order to boot a guest
> "pre-ballooned" (e.g. with memory=1G but maxmem=2G) in order to allow for
> future memory expansion the guest must derive max_pfn from the e820 provided by
> the toolstack and not the current maximum reservation (which can reflect only
> the current maximum, not the guest lifetime max). The existing algorithm
> already behaves this correctly if we do not artificially limit the maximum
> number of pages for the guest case.
> 
> For a guest booted with maxmem=512, memory=128 this results in:
>  [    0.000000] BIOS-provided physical RAM map:
>  [    0.000000]  Xen: 0000000000000000 - 00000000000a0000 (usable)
>  [    0.000000]  Xen: 00000000000a0000 - 0000000000100000 (reserved)
> -[    0.000000]  Xen: 0000000000100000 - 0000000008100000 (usable)
> -[    0.000000]  Xen: 0000000008100000 - 0000000020800000 (unusable)
> +[    0.000000]  Xen: 0000000000100000 - 0000000020800000 (usable)
> ...
>  [    0.000000] NX (Execute Disable) protection: active
>  [    0.000000] DMI not present or invalid.
>  [    0.000000] e820 update range: 0000000000000000 - 0000000000010000 (usable) ==> (reserved)
>  [    0.000000] e820 remove range: 00000000000a0000 - 0000000000100000 (usable)
> -[    0.000000] last_pfn = 0x8100 max_arch_pfn = 0x1000000
> +[    0.000000] last_pfn = 0x20800 max_arch_pfn = 0x1000000
>  [    0.000000] initial memory mapped : 0 - 027ff000
>  [    0.000000] Base memory trampoline at [c009f000] 9f000 size 4096
> -[    0.000000] init_memory_mapping: 0000000000000000-0000000008100000
> -[    0.000000]  0000000000 - 0008100000 page 4k
> -[    0.000000] kernel direct mapping tables up to 8100000 @ 27bb000-27ff000
> +[    0.000000] init_memory_mapping: 0000000000000000-0000000020800000
> +[    0.000000]  0000000000 - 0020800000 page 4k
> +[    0.000000] kernel direct mapping tables up to 20800000 @ 26f8000-27ff000
>  [    0.000000] xen: setting RW the range 27e8000 - 27ff000
>  [    0.000000] 0MB HIGHMEM available.
> -[    0.000000] 129MB LOWMEM available.
> -[    0.000000]   mapped low ram: 0 - 08100000
> -[    0.000000]   low ram: 0 - 08100000
> +[    0.000000] 520MB LOWMEM available.
> +[    0.000000]   mapped low ram: 0 - 20800000
> +[    0.000000]   low ram: 0 - 20800000
> 
> With this change "xl mem-set <domain> 512M" will successfully increase the
> guest RAM (by reducing the balloon).
> 
> There is no change for dom0.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> Cc: stable@kernel.org
> Cc: David Vrabel <david.vrabel@citrix.com>
> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> ---
>  arch/x86/xen/setup.c |   18 +++++++++++++++---
>  1 files changed, 15 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
> index 38d0af4..a54ff1a 100644
> --- a/arch/x86/xen/setup.c
> +++ b/arch/x86/xen/setup.c
> @@ -173,9 +173,21 @@ static unsigned long __init xen_get_max_pages(void)
>  	domid_t domid = DOMID_SELF;
>  	int ret;
>  
> -	ret = HYPERVISOR_memory_op(XENMEM_maximum_reservation, &domid);
> -	if (ret > 0)
> -		max_pages = ret;
> +	/*
> +	 * For the initial domain we use the maximum reservation as
> +	 * the maximum page.
> +	 *
> +	 * For guest domains the current maximum reservation reflects
> +	 * the current maximum rather than the static maximum. In this
> +	 * case the e820 map provided to us will cover the static
> +	 * maximum region.
> +	 */
> +	if (xen_initial_domain()) {
> +		ret = HYPERVISOR_memory_op(XENMEM_maximum_reservation, &domid);
> +		if (ret > 0)
> +			max_pages = ret;
> +	}
> +
>  	return min(max_pages, MAX_DOMAIN_PAGES);
>  }
>  
> -- 
> 1.7.2.5
> 
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 18:33:11 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 18:33:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RatdC-0003yP-Of; Wed, 14 Dec 2011 18:32:42 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <quartex73@gmail.com>) id 1RatdA-0003w5-BH
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 18:32:41 +0000
X-Env-Sender: quartex73@gmail.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1323887498!7225023!1
X-Originating-IP: [209.85.213.171]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19161 invoked from network); 14 Dec 2011 18:31:39 -0000
Received: from mail-yx0-f171.google.com (HELO mail-yx0-f171.google.com)
	(209.85.213.171)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Dec 2011 18:31:39 -0000
Received: by yenr9 with SMTP id r9so15679992yen.30
	for <xen-devel@lists.xensource.com>;
	Wed, 14 Dec 2011 10:31:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	bh=GKbQdTdSv4i+Bpr7t920Hr4qle/cbnzhIPIVpnI28+E=;
	b=WynrLPOl6SuXtdUTjlqjMa5jlelPJ438mDPKdIy+Y6WUk2nUSFUsC5g61nJIvcbtk2
	Ox8hFO/B+MmPwa1NHzFszlI1sNe9UjKNMUszQfUhenpHY4irfy2RkSgk5+YflCwgFxmo
	ZE/GXQyLsyQKuq+/hBsjklKVEnc4+mpbulkmw=
MIME-Version: 1.0
Received: by 10.236.176.2 with SMTP id a2mr13811338yhm.12.1323887498320; Wed,
	14 Dec 2011 10:31:38 -0800 (PST)
Received: by 10.146.58.7 with HTTP; Wed, 14 Dec 2011 10:31:38 -0800 (PST)
In-Reply-To: <20111202195727.GA18758@andromeda.dapyr.net>
References: <CAMhBqqiLc1994GUKtA7UY52pR29nktmFy+XiwTwpZb_E+fwFRQ@mail.gmail.com>
	<CAMhBqqgu6v8NB-X0dNdfrzd12=Y2i==fYCCC2Z+MkDupqqKAOg@mail.gmail.com>
	<20111202195727.GA18758@andromeda.dapyr.net>
Date: Wed, 14 Dec 2011 19:31:38 +0100
Message-ID: <CAMhBqqgJ0Q3BZDuK3KEEGuDS2eGBZq89E7_Kbv+VNTYxZJLAAA@mail.gmail.com>
From: Quartexx <quartex73@gmail.com>
To: xen-devel@lists.xensource.com
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>
Subject: Re: [Xen-devel] xen 4.0.1 w/2.6.32.47 hangs at boot
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

2011/12/2 Konrad Rzeszutek Wilk <konrad@darnok.org>:
> On Fri, Dec 02, 2011 at 08:22:46PM +0100, Quartexx wrote:
>> ### lspci
>
> <sigh> You seem to be missing the most important - that is the serial
> console output with 'sync_console' enabled.


here it is:

 __  __            _  _    ___   _
 \ \/ /___ _ __   | || |  / _ \ / |
  \  // _ \ '_ \  | || |_| | | || |
  /  \  __/ | | | |__   _| |_| || |
 /_/\_\___|_| |_|    |_|(_)___(_)_|

(XEN) Xen version 4.0.1 (root@foo-net.private) (gcc version 4.4.5
(Debian 4.4.5-8) ) Fri Dec  2 16:56:12 CET 2011
(XEN) Latest ChangeSet: unavailable
(XEN) Console output is synchronous.
(XEN) Bootloader: GNU GRUB 0.97
(XEN) Command line: dom0_mem=3D1024M max_cstate=3D1 loglvl=3Dall
guest_loglvl=3Dall sync_console console_to_ring com1=3D38400,8n1
console=3Dcom1
(XEN) Video information:
(XEN)  VGA is text mode 80x25, font 8x16
(XEN)  VBE/DDC methods: V2; EDID transfer time: 1 seconds
(XEN) Disc information:
(XEN)  Found 1 MBR signatures
(XEN)  Found 1 EDD information structures
(XEN) Xen-e820 RAM map:
(XEN)  0000000000000000 - 000000000009b800 (usable)
(XEN)  000000000009b800 - 00000000000a0000 (reserved)
(XEN)  00000000000e0000 - 0000000000100000 (reserved)
(XEN)  0000000000100000 - 000000009d8e9000 (usable)
(XEN)  000000009d8e9000 - 000000009d9bb000 (ACPI NVS)
(XEN)  000000009d9bb000 - 000000009f6a4000 (ACPI data)
(XEN)  000000009f6a4000 - 000000009f6df000 (reserved)
(XEN)  000000009f6df000 - 000000009f78a000 (ACPI data)
(XEN)  000000009f78a000 - 000000009f7df000 (ACPI NVS)
(XEN)  000000009f7df000 - 000000009f800000 (ACPI data)
(XEN)  000000009f800000 - 00000000b0000000 (reserved)
(XEN)  00000000fed1c000 - 00000000fed20000 (reserved)
(XEN)  00000000ff800000 - 0000000100000000 (reserved)
(XEN)  0000000100000000 - 0000000460000000 (usable)
(XEN) ACPI: RSDP 000F0410, 0024 (r2 INTEL )
(XEN) ACPI: XSDT 9F7FD120, 008C (r1 INTEL  S3420GPC        0       1000013)
(XEN) ACPI: FACP 9F7FB000, 00F4 (r4 INTEL  S3420GPC        0 MSFT  100000D)
(XEN) ACPI: DSDT 9F7F6000, 4E22 (r2 INTEL  S3420GPC        3 MSFT  100000D)
(XEN) ACPI: FACS 9F78A000, 0040
(XEN) ACPI: APIC 9F7F5000, 00BC (r2 INTEL  S3420GPC        0 MSFT  100000D)
(XEN) ACPI: MCFG 9F7F4000, 003C (r1 INTEL  S3420GPC        1 MSFT  100000D)
(XEN) ACPI: HPET 9F7F3000, 0038 (r1 INTEL  S3420GPC        1 MSFT  100000D)
(XEN) ACPI: SLIT 9F7F2000, 0030 (r1 INTEL  S3420GPC        1 MSFT  100000D)
(XEN) ACPI: SPCR 9F7F1000, 0050 (r1 INTEL  S3420GPC        0 MSFT  100000D)
(XEN) ACPI: WDDT 9F7F0000, 0040 (r1 INTEL  S3420GPC        0 MSFT  100000D)
(XEN) ACPI: SSDT 9F7E5000, AEF4 (r2  INTEL SSDT  PM     4000 INTL 20061109)
(XEN) ACPI: SSDT 9F7E4000, 01D8 (r2  INTEL IPMI         4000 INTL 20061109)
(XEN) ACPI: HEST 9F7E3000, 00A8 (r1 INTEL  S3420GPC        1 INTL        1)
(XEN) ACPI: BERT 9F7E2000, 0030 (r1 INTEL  S3420GPC        1 INTL        1)
(XEN) ACPI: ERST 9F7E1000, 0230 (r1 INTEL  S3420GPC        1 INTL        1)
(XEN) ACPI: EINJ 9F7E0000, 0130 (r1 INTEL  S3420GPC        1 INTL        1)
(XEN) System RAM: 16344MB (16736784kB)
(XEN) No NUMA configuration found
(XEN) Faking a node at 0000000000000000-0000000460000000
(XEN) Domain heap initialised
(XEN) found SMP MP-table at 000fd9a0
(XEN) DMI 2.5 present.
(XEN) Using APIC driver default
(XEN) ACPI: PM-Timer IO Port: 0x408
(XEN) ACPI: ACPI SLEEP INFO: pm1x_cnt[404,0], pm1x_evt[400,0]
(XEN) ACPI:                  wakeup_vec[9f78a00c], vec_size[20]
(XEN) ACPI: Local APIC address 0xfee00000
(XEN) ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
(XEN) Processor #0 7:14 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x02] enabled)
(XEN) Processor #2 7:14 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x02] lapic_id[0x04] enabled)
(XEN) Processor #4 7:14 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x03] lapic_id[0x06] enabled)
(XEN) Processor #6 7:14 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x04] lapic_id[0x01] disabled)
(XEN) ACPI: LAPIC (acpi_id[0x05] lapic_id[0x03] disabled)
(XEN) ACPI: LAPIC (acpi_id[0x06] lapic_id[0x05] disabled)
(XEN) ACPI: LAPIC (acpi_id[0x07] lapic_id[0x07] disabled)
(XEN) ACPI: LAPIC_NMI (acpi_id[0x00] high level lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x01] high level lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x02] high level lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x03] high level lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x04] high level lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x05] high level lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x06] high level lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x07] high level 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: 0x8086a801 base: 0xfed00000
(XEN) PCI: MCFG configuration 0: base a0000000 segment 0 buses 0 - 255
(XEN) PCI: MCFG area at a0000000 reserved in E820
(XEN) Using ACPI (MADT) for SMP configuration information
(XEN) Using scheduler: SMP Credit Scheduler (credit)
(XEN) Detected 2400.027 MHz processor.
(XEN) Initing memory sharing.
(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) EPT supports 2MB super page.
(XEN) HVM: ASIDs enabled.
(XEN) HVM: VMX enabled
(XEN) HVM: Hardware Assisted Paging detected.
(XEN) Intel machine check reporting enabled
(XEN) I/O virtualisation disabled
(XEN) Total of 4 processors activated.
(XEN) ENABLING IO-APIC IRQs
(XEN)  -> Using new ACK method
(XEN) ..TIMER: vector=3D0xF0 apic1=3D0 pin1=3D2 apic2=3D-1 pin2=3D-1
(XEN) TSC is reliable, synchronization unnecessary
(XEN) Platform timer appears to have unexpectedly wrapped 1 times.
(XEN) Platform timer is 14.318MHz HPET
=FF(XEN) Allocated console ring of 32 KiB.
(XEN) microcode.c:73:d32767 microcode: CPU1 resumed
(XEN) microcode.c:73:d32767 microcode: CPU3 resumed
(XEN) microcode.c:73:d32767 microcode: CPU2 resumed
(XEN) Brought up 4 CPUs
(XEN) Turbo Mode detected!
(XEN) HPET: 8 timers in total, 8 timers will be used for broadcast
(XEN) ACPI sleep modes: S3
(XEN) mcheck_poll: Machine check polling timer started.
(XEN) *** LOADING DOMAIN 0 ***
(XEN)  Xen  kernel: 64-bit, lsb, compat32
(XEN)  Dom0 kernel: 64-bit, PAE, lsb, paddr 0x1000000 -> 0x1bfc000
(XEN) PHYSICAL MEMORY ARRANGEMENT:
(XEN)  Dom0 alloc.:   0000000450000000->0000000454000000 (245760 pages
to be allocated)
(XEN) VIRTUAL MEMORY ARRANGEMENT:
(XEN)  Loaded kernel: ffffffff81000000->ffffffff81bfc000
(XEN)  Init. ramdisk: ffffffff81bfc000->ffffffff820c7c00
(XEN)  Phys-Mach map: ffffffff820c8000->ffffffff822c8000
(XEN)  Start info:    ffffffff822c8000->ffffffff822c84b4
(XEN)  Page tables:   ffffffff822c9000->ffffffff822de000
(XEN)  Boot stack:    ffffffff822de000->ffffffff822df000
(XEN)  TOTAL:         ffffffff80000000->ffffffff82400000
(XEN)  ENTRY ADDRESS: ffffffff81976200
(XEN) Dom0 has maximum 4 VCPUs
(XEN) Scrubbing Free RAM:
...........................................................................=
...........................................................................=
..done.
(XEN) trace.c:89:d32767 calc_tinfo_first_offset: NR_CPUs 128,
offset_in_bytes 258, t_info_first_offset 65
(XEN) Xen trace buffers: disabled
(XEN) Std. Loglevel: All
(XEN) Guest Loglevel: All
(XEN) **********************************************
(XEN) ******* WARNING: CONSOLE OUTPUT IS SYNCHRONOUS
(XEN) ******* This option is intended to aid debugging of Xen by ensuring
(XEN) ******* that all output is synchronously delivered on the serial line.
(XEN) ******* However it can introduce SIGNIFICANT latencies and affect
(XEN) ******* timekeeping. It is NOT recommended for production use!
(XEN) **********************************************
(XEN) 3... 2... 1...
(XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch
input to Xen)
(XEN) Freed 176kB init memory.
mapping kernel into physical memory
Xen: setup ISA identity maps
about to get started...
[    0.000000] Initializing cgroup subsys cpuset
[    0.000000] Initializing cgroup subsys cpu
[    0.000000] Linux version 2.6.32.47 (root@xenhost-rack2) (gcc
version 4.4.5 (Debian 4.4.5-8) ) #1 SMP Fri Dec 2 13:05:28 CET 2011
[    0.000000] Command line:
root=3DUUID=3D5563bc26-6e98-4768-abee-5ca053e2795c ro nomodeset
max_loop=3D255 console=3Dhvc0 earlyprintk=3Dxen
[    0.000000] KERNEL supported cpus:
[    0.000000]   Intel GenuineIntel
[    0.000000]   AMD AuthenticAMD
[    0.000000]   Centaur CentaurHauls
[    0.000000] released 0 pages of unused memory
[    0.000000] BIOS-provided physical RAM map:
[    0.000000]  Xen: 0000000000000000 - 000000000009b000 (usable)
[    0.000000]  Xen: 000000000009b800 - 0000000000100000 (reserved)
[    0.000000]  Xen: 0000000000100000 - 0000000040000000 (usable)
[    0.000000]  Xen: 0000000040000000 - 000000009d8e9000 (unusable)
[    0.000000]  Xen: 000000009d8e9000 - 000000009d9bb000 (ACPI NVS)
[    0.000000]  Xen: 000000009d9bb000 - 000000009f6a4000 (ACPI data)
[    0.000000]  Xen: 000000009f6a4000 - 000000009f6df000 (reserved)
[    0.000000]  Xen: 000000009f6df000 - 000000009f78a000 (ACPI data)
[    0.000000]  Xen: 000000009f78a000 - 000000009f7df000 (ACPI NVS)
[    0.000000]  Xen: 000000009f7df000 - 000000009f800000 (ACPI data)
[    0.000000]  Xen: 000000009f800000 - 00000000b0000000 (reserved)
[    0.000000]  Xen: 00000000fec00000 - 00000000fec01000 (reserved)
[    0.000000]  Xen: 00000000fed1c000 - 00000000fed20000 (reserved)
[    0.000000]  Xen: 00000000fee00000 - 00000000fee01000 (reserved)
[    0.000000]  Xen: 00000000ff800000 - 0000000100000000 (reserved)
[    0.000000]  Xen: 0000000100000000 - 0000000340000000 (usable)
[    0.000000] bootconsole [xenboot0] enabled
[    0.000000] DMI 2.5 present.
[    0.000000] last_pfn =3D 0x340000 max_arch_pfn =3D 0x400000000
[    0.000000] x86 PAT enabled: cpu 0, old 0x50100070406, new 0x70106000701=
06
[    0.000000] last_pfn =3D 0x40000 max_arch_pfn =3D 0x400000000
[    0.000000] Scanning 1 areas for low memory corruption
[    0.000000] modified physical RAM map:
[    0.000000]  modified: 0000000000000000 - 0000000000001000 (usable)
[    0.000000]  modified: 0000000000001000 - 0000000000006000 (reserved)
[    0.000000]  modified: 0000000000006000 - 000000000009b000 (usable)
[    0.000000]  modified: 000000000009b800 - 0000000000100000 (reserved)
[    0.000000]  modified: 0000000000100000 - 0000000040000000 (usable)
[    0.000000]  modified: 0000000040000000 - 000000009d8e9000 (unusable)
[    0.000000]  modified: 000000009d8e9000 - 000000009d9bb000 (ACPI NVS)
[    0.000000]  modified: 000000009d9bb000 - 000000009f6a4000 (ACPI data)
[    0.000000]  modified: 000000009f6a4000 - 000000009f6df000 (reserved)
[    0.000000]  modified: 000000009f6df000 - 000000009f78a000 (ACPI data)
[    0.000000]  modified: 000000009f78a000 - 000000009f7df000 (ACPI NVS)
[    0.000000]  modified: 000000009f7df000 - 000000009f800000 (ACPI data)
[    0.000000]  modified: 000000009f800000 - 00000000b0000000 (reserved)
[    0.000000]  modified: 00000000fec00000 - 00000000fec01000 (reserved)
[    0.000000]  modified: 00000000fed1c000 - 00000000fed20000 (reserved)
[    0.000000]  modified: 00000000fee00000 - 00000000fee01000 (reserved)
[    0.000000]  modified: 00000000ff800000 - 0000000100000000 (reserved)
[    0.000000]  modified: 0000000100000000 - 0000000340000000 (usable)
[    0.000000] init_memory_mapping: 0000000000000000-0000000040000000
[    0.000000] init_memory_mapping: 0000000100000000-0000000340000000
[    0.000000] RAMDISK: 01bfc000 - 020c7c00
[    0.000000] ACPI: RSDP 00000000000f0410 00024 (v02 INTEL )
[    0.000000] ACPI: XSDT 000000009f7fd120 0008C (v01 INTEL  S3420GPC
00000000      01000013)
[    0.000000] ACPI: FACP 000000009f7fb000 000F4 (v04 INTEL  S3420GPC
00000000 MSFT 0100000D)
[    0.000000] ACPI: DSDT 000000009f7f6000 04E22 (v02 INTEL  S3420GPC
00000003 MSFT 0100000D)
[    0.000000] ACPI: FACS 000000009f78a000 00040
[    0.000000] ACPI: APIC 000000009f7f5000 000BC (v02 INTEL  S3420GPC
00000000 MSFT 0100000D)
[    0.000000] ACPI: MCFG 000000009f7f4000 0003C (v01 INTEL  S3420GPC
00000001 MSFT 0100000D)
[    0.000000] ACPI: HPET 000000009f7f3000 00038 (v01 INTEL  S3420GPC
00000001 MSFT 0100000D)
[    0.000000] ACPI: SLIT 000000009f7f2000 00030 (v01 INTEL  S3420GPC
00000001 MSFT 0100000D)
[    0.000000] ACPI: SPCR 000000009f7f1000 00050 (v01 INTEL  S3420GPC
00000000 MSFT 0100000D)
[    0.000000] ACPI: WDDT 000000009f7f0000 00040 (v01 INTEL  S3420GPC
00000000 MSFT 0100000D)
[    0.000000] ACPI: SSDT 000000009f7e5000 0AEF4 (v02  INTEL SSDT  PM
00004000 INTL 20061109)
[    0.000000] ACPI: SSDT 000000009f7e4000 001D8 (v02  INTEL IPMI
00004000 INTL 20061109)
[    0.000000] ACPI: HEST 000000009f7e3000 000A8 (v01 INTEL  S3420GPC
00000001 INTL 00000001)
[    0.000000] ACPI: BERT 000000009f7e2000 00030 (v01 INTEL  S3420GPC
00000001 INTL 00000001)
[    0.000000] ACPI: ERST 000000009f7e1000 00230 (v01 INTEL  S3420GPC
00000001 INTL 00000001)
[    0.000000] ACPI: EINJ 000000009f7e0000 00130 (v01 INTEL  S3420GPC
00000001 INTL 00000001)
[    0.000000] (10 early reservations) =3D=3D> bootmem [0000000000 - 034000=
0000]
[    0.000000]   #0 [0000000000 - 0000001000]   BIOS data page =3D=3D>
[0000000000 - 0000001000]
[    0.000000]   #1 [00022c9000 - 00022de000]   XEN PAGETABLES =3D=3D>
[00022c9000 - 00022de000]
[    0.000000]   #2 [0000006000 - 0000008000]       TRAMPOLINE =3D=3D>
[0000006000 - 0000008000]
[    0.000000]   #3 [0001000000 - 0001ad1474]    TEXT DATA BSS =3D=3D>
[0001000000 - 0001ad1474]
[    0.000000]   #4 [0001bfc000 - 00020c7c00]          RAMDISK =3D=3D>
[0001bfc000 - 00020c7c00]
[    0.000000]   #5 [00020c8000 - 00022c9000]   XEN START INFO =3D=3D>
[00020c8000 - 00022c9000]
[    0.000000]   #6 [0100000000 - 0340000000]        XEN EXTRA =3D=3D>
[0100000000 - 0340000000]
[    0.000000]   #7 [0001ad2000 - 0001ade36c]              BRK =3D=3D>
[0001ad2000 - 0001ade36c]
[    0.000000]   #8 [0000100000 - 00002ea000]          PGTABLE =3D=3D>
[0000100000 - 00002ea000]
[    0.000000]   #9 [00022de000 - 00034e7000]          PGTABLE =3D=3D>
[00022de000 - 00034e7000]
[    0.000000] found SMP MP-table at [ffff8800000fd9a0] fd9a0
[    0.000000] Zone PFN ranges:
[    0.000000]   DMA      0x00000000 -> 0x00001000
[    0.000000]   DMA32    0x00001000 -> 0x00100000
[    0.000000]   Normal   0x00100000 -> 0x00340000
[    0.000000] Movable zone start PFN for each node
[    0.000000] early_node_map[4] active PFN ranges
[    0.000000]     0: 0x00000000 -> 0x00000001
[    0.000000]     0: 0x00000006 -> 0x0000009b
[    0.000000]     0: 0x00000100 -> 0x00040000
[    0.000000]     0: 0x00100000 -> 0x00340000
[    0.000000] ACPI: PM-Timer IO Port: 0x408
[    0.000000] ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x02] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x04] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x03] lapic_id[0x06] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x04] lapic_id[0x01] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x05] lapic_id[0x03] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x06] lapic_id[0x05] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x07] lapic_id[0x07] disabled)
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x00] high level lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x01] high level lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x02] high level lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x03] high level lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x04] high level lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x05] high level lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x06] high level lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x07] high level lint[0x1])
[    0.000000] ACPI: IOAPIC (id[0x08] address[0xfec00000] gsi_base[0])
[    0.000000] IOAPIC[0]: apic_id 8, version 0, address 0xfec00000, GSI 0-0
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
[    0.000000] ERROR: Unable to locate IOAPIC for GSI 2
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
[    0.000000] ERROR: Unable to locate IOAPIC for GSI 9
[    0.000000] Using ACPI (MADT) for SMP configuration information
[    0.000000] ACPI: HPET id: 0x8086a801 base: 0xfed00000
[    0.000000] SMP: Allowing 4 CPUs, 0 hotplug CPUs
[    0.000000] PM: Registered nosave memory: 0000000000001000 - 00000000000=
06000
[    0.000000] PM: Registered nosave memory: 000000000009b000 - 00000000000=
9c000
[    0.000000] PM: Registered nosave memory: 000000000009c000 - 00000000001=
00000
[    0.000000] PM: Registered nosave memory: 0000000040000000 - 000000009d8=
e9000
[    0.000000] PM: Registered nosave memory: 000000009d8e9000 - 000000009d9=
bb000
[    0.000000] PM: Registered nosave memory: 000000009d9bb000 - 000000009f6=
a4000
[    0.000000] PM: Registered nosave memory: 000000009f6a4000 - 000000009f6=
df000
[    0.000000] PM: Registered nosave memory: 000000009f6df000 - 000000009f7=
8a000
[    0.000000] PM: Registered nosave memory: 000000009f78a000 - 000000009f7=
df000
[    0.000000] PM: Registered nosave memory: 000000009f7df000 - 000000009f8=
00000
[    0.000000] PM: Registered nosave memory: 000000009f800000 - 00000000b00=
00000
[    0.000000] PM: Registered nosave memory: 00000000b0000000 - 00000000fec=
00000
[    0.000000] PM: Registered nosave memory: 00000000fec00000 - 00000000fec=
01000
[    0.000000] PM: Registered nosave memory: 00000000fec01000 - 00000000fed=
1c000
[    0.000000] PM: Registered nosave memory: 00000000fed1c000 - 00000000fed=
20000
[    0.000000] PM: Registered nosave memory: 00000000fed20000 - 00000000fee=
00000
[    0.000000] PM: Registered nosave memory: 00000000fee00000 - 00000000fee=
01000
[    0.000000] PM: Registered nosave memory: 00000000fee01000 - 00000000ff8=
00000
[    0.000000] PM: Registered nosave memory: 00000000ff800000 - 00000001000=
00000
[    0.000000] Allocating PCI resources starting at b0000000 (gap:
b0000000:4ec00000)
[    0.000000] Booting paravirtualized kernel on Xen
[    0.000000] Xen version: 4.0.1 (preserve-AD) (dom0)
[    0.000000] NR_CPUS:8 nr_cpumask_bits:8 nr_cpu_ids:4 nr_node_ids:1
[    0.000000] PERCPU: Embedded 29 pages/cpu @ffff880028038000 s88536
r8192 d22056 u118784
[    0.000000] pcpu-alloc: s88536 r8192 d22056 u118784 alloc=3D29*4096
[    0.000000] pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3
[    9.839051] Built 1 zonelists in Zone order, mobility grouping on.
Total pages: 2574249
[    9.865636] Kernel command line:
root=3DUUID=3D5563bc26-6e98-4768-abee-5ca053e2795c ro nomodeset
max_loop=3D255 console=3Dhvc0 earlyprintk=3Dxen
[    9.905431] PID hash table entries: 4096 (order: 3, 32768 bytes)
[    9.926753] Dentry cache hash table entries: 2097152 (order: 12,
16777216 bytes)
[    9.954316] Inode-cache hash table entries: 1048576 (order: 11,
8388608 bytes)
[    9.979372] Initializing CPU#0
[    9.995611] DMA: Placing 64MB software IO TLB between
ffff880020000000 - ffff880024000000
[   10.021944] DMA: software IO TLB at phys 0x20000000 - 0x24000000
[   10.041672] xen_swiotlb_fixup: buf=3Dffff880020000000 size=3D67108864
[   10.079409] xen_swiotlb_fixup: buf=3Dffff880024060000 size=3D32768
[   10.101542] Memory: 774160k/13631488k available (5877k kernel code,
3146152k absent, 9710440k reserved, 3717k data, 568k init)
[   10.138468] SLUB: Genslabs=3D13, HWalign=3D64, Order=3D0-3, MinObjects=
=3D0,
CPUs=3D4, Nodes=3D1
[   10.163634] Hierarchical RCU implementation.
[   10.177636] NR_IRQS:4352 nr_irqs:1280
[   10.189792] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
[   10.210523] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
[   10.232257] xen: sci override: source_irq=3D9 global_irq=3D9 trigger=3Dc=
 polarity=3D1
[   10.255712] xen_allocate_pirq: returning irq 9 for gsi 9
[   10.273159] xen: acpi sci 9
[   10.293028] Console: colour VGA+ 80x25
[   10.304769] console [hvc0] enabled, bootconsole disabled
[   10.304769] console [hvc0] enabled, bootconsole disabled
[   10.339957] installing Xen timer for CPU 0
[   10.353698] Detected 2400.026 MHz processor.
[   10.367971] Calibrating delay loop (skipped), value calculated
using timer frequency.. 4800.05 BogoMIPS (lpj=3D2400026)
[   10.403157] Security Framework initialized
[   10.416878] SELinux:  Initializing.
[   10.428608] Mount-cache hash table entries: 256
[   10.443892] Initializing cgroup subsys ns
[   10.457205] Initializing cgroup subsys cpuacct
[   10.472071] Initializing cgroup subsys freezer
[   10.486973] CPU: L1 I cache: 32K, L1 D cache: 32K
[   10.502669] CPU: L2 cache: 256K
[   10.513252] CPU: L3 cache: 8192K
[   10.524125] CPU: Unsupported number of siblings 16
[   10.539282] mce: CPU supports 9 MCE banks
[   10.553603] Performance Events: unsupported p6 CPU model 30 no PMU
driver, software events only.
[   10.582756] SMP alternatives: switching to UP code
[   10.635796] ACPI: Core revision 20090903
[   10.668729] installing Xen timer for CPU 1
[   10.681928] SMP alternatives: switching to SMP code
[   10.734120] Initializing CPU#1
[   10.734156] CPU: L1 I cache: 32K, L1 D cache: 32K
[   10.734158] CPU: L2 cache: 256K
[   10.734159] CPU: L3 cache: 8192K
[   10.734163] CPU: Unsupported number of siblings 16
[   10.734239] installing Xen timer for CPU 2
[   10.810958] Initializing CPU#2
[   10.810992] CPU: L1 I cache: 32K, L1 D cache: 32K
[   10.810994] CPU: L2 cache: 256K
[   10.810995] CPU: L3 cache: 8192K
[   10.810999] CPU: Unsupported number of siblings 16
[   10.811070] installing Xen timer for CPU 3
[   10.888173] Initializing CPU#3
[   10.888207] CPU: L1 I cache: 32K, L1 D cache: 32K
[   10.888209] CPU: L2 cache: 256K
[   10.888211] CPU: L3 cache: 8192K
[   10.888214] CPU: Unsupported number of siblings 16
[   10.888248] Brought up 4 CPUs
[   10.962416] Grant table initialized
[   10.973608] Time: 15:24:53  Date: 12/14/11
[   10.987357] NET: Registered protocol family 16
[   11.002765] ACPI FADT declares the system doesn't support PCIe
ASPM, so disable it
[   11.027370] ACPI: bus type pci registered
[   11.041225] PCI: MCFG configuration 0: base a0000000 segment 0 buses 0 -=
 255
[   11.064263] PCI: MCFG area at a0000000 reserved in E820
[   11.105483] PCI: Using MMCONFIG at a0000000 - afffffff
[   11.122083] PCI: Using configuration type 1 for base access
[   11.152342] bio: create slab <bio-0> at 0
[   11.166715] ERROR: Unable to locate IOAPIC for GSI 9
[   11.184378] ACPI Error: Field [CPB3] at 96 exceeds Buffer [NULL]
size 64 (bits) (20090903/dsopcode-596)
[   11.214992] ACPI Error (psparse-0537): Method parse/execution
failed [\_SB_._OSC] (Node ffff88003fc187c0), AE_AML_BUFFER_LIMIT
[   11.275785] ACPI: Interpreter enabled
[   11.287525] ACPI: (supports S0 S1 S5)
[   11.299822] ACPI: Using IOAPIC for interrupt routing
[   11.329279] ACPI: No dock devices found.
[   11.342638] ACPI: PCI Root Bridge [PCI0] (0000:00)
[   11.358366] pci 0000:00:05.0: PME# supported from D0 D3hot D3cold
[   11.378399] pci 0000:00:05.0: PME# disabled
[   11.393065] pci 0000:00:19.0: PME# supported from D0 D3hot D3cold
[   11.412812] pci 0000:00:19.0: PME# disabled
[   11.427012] pci 0000:00:1a.0: PME# supported from D0 D3hot D3cold
[   11.447131] pci 0000:00:1a.0: PME# disabled
[   11.461256] pci 0000:00:1c.0: PME# supported from D0 D3hot D3cold
[   11.481449] pci 0000:00:1c.0: PME# disabled
[   11.495578] pci 0000:00:1c.4: PME# supported from D0 D3hot D3cold
[   11.515769] pci 0000:00:1c.4: PME# disabled
[   11.529893] pci 0000:00:1c.6: PME# supported from D0 D3hot D3cold
[   11.550087] pci 0000:00:1c.6: PME# disabled
[   11.564212] pci 0000:00:1c.7: PME# supported from D0 D3hot D3cold
[   11.584407] pci 0000:00:1c.7: PME# disabled
[   11.598597] pci 0000:00:1d.0: PME# supported from D0 D3hot D3cold
[   11.618728] pci 0000:00:1d.0: PME# disabled
[   11.633590] pci 0000:03:00.0: PME# supported from D0 D3hot D3cold
[   11.653337] pci 0000:03:00.0: PME# disabled
[   11.667914] pci 0000:00:1e.0: transparent bridge
(XEN) PCI add device 00:00.0
(XEN) PCI add device 00:05.0
(XEN) PCI add device 00:08.0
(XEN) PCI add device 00:08.1
(XEN) PCI add device 00:08.2
(XEN) PCI add device 00:08.3
(XEN) PCI add device 00:10.0
(XEN) PCI add device 00:10.1
(XEN) PCI add device 00:19.0
(XEN) PCI add device 00:1a.0
(XEN) PCI add device 00:1c.0
(XEN) PCI add device 00:1c.4
(XEN) PCI add device 00:1c.6
(XEN) PCI add device 00:1c.7
(XEN) PCI add device 00:1d.0
(XEN) PCI add device 00:1e.0
(XEN) PCI add device 00:1f.0
(XEN) PCI add device 00:1f.3
(XEN) PCI add device 01:00.0
(XEN) PCI add device 03:00.0
(XEN) PCI add device 04:00.0
[   11.864475] ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 9 *10
11 12 14 15)
[   11.888232] ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 9 10
*11 12 14 15)
[   11.912254] ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 *5 6 7 9 10
11 12 14 15)
[   11.936300] ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 7 9 10
*11 12 14 15)
[   11.960301] ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 7 9 10 11
12 14 15) *0, disabled.
[   11.988037] ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 6 7 *9 10
11 12 14 15)
[   12.012064] ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 6 7 9 10 11
12 14 15) *0, disabled.
[   12.039801] ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 6 7 9 *10
11 12 14 15)
[   12.063966] xen_balloon: Initialising balloon driver with page order 0.
[   12.085852] last_pfn =3D 0x340000 max_arch_pfn =3D 0x400000000
[   12.134092] vgaarb: device added:
PCI:0000:04:00.0,decodes=3Dio+mem,owns=3Dio+mem,locks=3Dnone
[   12.160419] vgaarb: loaded
[   12.169810] SCSI subsystem initialized
[   12.182634] usbcore: registered new interface driver usbfs
[   12.200513] usbcore: registered new interface driver hub
[   12.218271] usbcore: registered new device driver usb
[   12.235434] PCI: Using ACPI for IRQ routing
[   12.249456] cfg80211: Using static regulatory domain info
[   12.267093] cfg80211: Regulatory domain: US
[   12.281108] 	(start_freq - end_freq @ bandwidth),
(max_antenna_gain, max_eirp)
[   12.305128] 	(2402000 KHz - 2472000 KHz @ 40000 KHz), (600 mBi, 2700 mBm)
[   12.327725] 	(5170000 KHz - 5190000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
[   12.350318] 	(5190000 KHz - 5210000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
[   12.372912] 	(5210000 KHz - 5230000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
[   12.395505] 	(5230000 KHz - 5330000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
[   12.418099] 	(5735000 KHz - 5835000 KHz @ 40000 KHz), (600 mBi, 3000 mBm)
[   12.440703] cfg80211: Calling CRDA for country: US
[   12.456754] NetLabel: Initializing
[   12.468144] NetLabel:  domain hash size =3D 128
[   12.482728] NetLabel:  protocols =3D UNLABELED CIPSOv4
[   12.499325] NetLabel:  unlabeled traffic allowed by default
[   12.518090] Switching to clocksource xen
[   12.533142] pnp: PnP ACPI init
[   12.542896] ACPI: bus type pnp registered
[   12.557733] xen_allocate_pirq: returning irq 8 for gsi 8
[   12.575024] xen_allocate_pirq: returning irq 13 for gsi 13
[   12.594078] xen_allocate_pirq: returning irq 4 for gsi 4
[   12.611257] Already setup the GSI :4
[   12.623748] xen_allocate_pirq: returning irq 3 for gsi 3
[   12.641472] pnp: PnP ACPI: found 11 devices
[   12.655004] ACPI: ACPI bus type pnp unregistered
[   12.670480] system 00:07: ioport range 0x500-0x57f has been reserved
[   12.691635] system 00:07: ioport range 0x600-0x61f has been reserved
[   12.712799] system 00:07: ioport range 0x880-0x883 has been reserved
[   12.733963] system 00:07: ioport range 0xca4-0xca5 has been reserved
[   12.755125] system 00:07: ioport range 0x400-0x47f has been reserved
[   12.776290] system 00:07: ioport range 0x800-0x81f has been reserved
[   12.797453] system 00:07: ioport range 0xca2-0xca3 has been reserved
[   12.818617] system 00:07: iomem range 0xfed1c000-0xfed3fffe could
not be reserved
[   12.843499] system 00:07: iomem range 0xff000000-0xffffffff could
not be reserved
[   12.868380] system 00:07: iomem range 0xfee00000-0xfeefffff could
not be reserved
[   12.893260] system 00:07: iomem range 0xfe900000-0xfe90001f has been res=
erved
[   12.916999] system 00:07: iomem range 0xfea00000-0xfea0001f has been res=
erved
[   12.940735] system 00:07: iomem range 0xfed1b000-0xfed1bfff has been res=
erved
[   12.964474] system 00:07: iomem range 0xfed14000-0xfed17ffe has been res=
erved
[   12.988211] system 00:07: iomem range 0xfed18000-0xfed18ffe has been res=
erved
[   13.011948] system 00:07: iomem range 0xfed19000-0xfed19ffe has been res=
erved
[   13.040791] PM-Timer failed consistency check  (0x0xffffff) - aborting.
[   13.062258] pci 0000:01:00.0: BAR 6: no parent found for of device
[0xfffe0000-0xffffffff]
[   13.089706] pci 0000:04:00.0: BAR 6: no parent found for of device
[0xffff0000-0xffffffff]
[   13.117229] pci 0000:00:05.0: PCI bridge, secondary bus 0000:01
[   13.136896] pci 0000:00:05.0:   IO window: 0x2000-0x2fff
[   13.154630] pci 0000:00:05.0:   MEM window: 0xb3a00000-0xb3afffff
[   13.174934] pci 0000:00:05.0:   PREFETCH window:
0x000000b0000000-0x000000b1ffffff
[   13.200105] pci 0000:00:1c.0: PCI bridge, secondary bus 0000:02
[   13.219833] pci 0000:00:1c.0:   IO window: disabled
[   13.236139] pci 0000:00:1c.0:   MEM window: disabled
[   13.252725] pci 0000:00:1c.0:   PREFETCH window: disabled
[   13.270747] pci 0000:00:1c.4: PCI bridge, secondary bus 0000:03
[   13.290474] pci 0000:00:1c.4:   IO window: 0x1000-0x1fff
[   13.308211] pci 0000:00:1c.4:   MEM window: 0xb3900000-0xb39fffff
[   13.328512] pci 0000:00:1c.4:   PREFETCH window: disabled
[   13.346535] pci 0000:00:1c.6: PCI bridge, secondary bus 0000:04
[   13.366260] pci 0000:00:1c.6:   IO window: disabled
[   13.382568] pci 0000:00:1c.6:   MEM window: 0xb3000000-0xb38fffff
[   13.402871] pci 0000:00:1c.6:   PREFETCH window:
0x000000b2000000-0x000000b2ffffff
[   13.428042] pci 0000:00:1c.7: PCI bridge, secondary bus 0000:05
[   13.447768] pci 0000:00:1c.7:   IO window: disabled
[   13.464075] pci 0000:00:1c.7:   MEM window: disabled
[   13.480662] pci 0000:00:1c.7:   PREFETCH window: disabled
[   13.498683] pci 0000:00:1e.0: PCI bridge, secondary bus 0000:06
[   13.518410] pci 0000:00:1e.0:   IO window: disabled
[   13.534715] pci 0000:00:1e.0:   MEM window: disabled
[   13.551301] pci 0000:00:1e.0:   PREFETCH window: disabled
[   13.569362] pci 0000:00:05.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
[   13.591642] xen_allocate_pirq: returning irq 16 for gsi 16
[   13.609934] Already setup the GSI :16
[   13.622226] pci 0000:00:1c.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
[   13.644549] xen_allocate_pirq: returning irq 16 for gsi 16
[   13.662868] Already setup the GSI :16
[   13.675158] pci 0000:00:1c.4: PCI INT B -> GSI 16 (level, low) -> IRQ 16
[   13.697497] pci 0000:00:1c.6: PCI INT C -> GSI 18 (level, low) -> IRQ 18
[   13.719804] pci 0000:00:1c.7: PCI INT D -> GSI 19 (level, low) -> IRQ 19
[   13.742154] NET: Registered protocol family 2
[   13.756744] IP route cache hash table entries: 524288 (order: 10,
4194304 bytes)
[   13.781907] TCP established hash table entries: 262144 (order: 10,
4194304 bytes)
[   13.807468] TCP bind hash table entries: 65536 (order: 8, 1048576 bytes)
[   13.829520] TCP: Hash tables configured (established 262144 bind 65536)
[   13.851233] TCP reno registered
[   13.861877] NET: Registered protocol family 1
[   13.876613] RPC: Registered udp transport module.
[   13.892130] RPC: Registered tcp transport module.
[   13.907860] RPC: Registered tcp NFSv4.1 backchannel transport module.
[   13.929669] Trying to unpack rootfs image as initramfs...
[   13.951302] Freeing initrd memory: 4911k freed
[   13.966207] PCI-DMA: Using software bounce buffering for IO (SWIOTLB)
[   13.987093] DMA: Placing 64MB software IO TLB between
ffff880020000000 - ffff880024000000
[   14.014263] DMA: software IO TLB at phys 0x20000000 - 0x24000000
[   14.034354] kvm: no hardware support
[   14.046297] has_svm: not amd
[   14.056017] kvm: no hardware support
[   14.070606] Microcode Update Driver: v2.00
<tigran@aivazian.fsnet.co.uk>, Peter Oruba
[   14.096071] Scanning for low memory corruption every 60 seconds
[   14.116238] audit: initializing netlink socket (disabled)
[   14.133839] type=3D2000 audit(1323876295.119:1): initialized
[   14.166146] HugeTLB registered 2 MB page size, pre-allocated 0 pages
[   14.190435] VFS: Disk quotas dquot_6.5.2
[   14.203141] Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
[   14.225580] msgmni has been set to 1523
[   14.238220] alg: No test for cipher_null (cipher_null-generic)
[   14.257375] alg: No test for ecb(cipher_null) (ecb-cipher_null)
[   14.277104] alg: No test for digest_null (digest_null-generic)
[   14.296552] alg: No test for compress_null (compress_null-generic)
[   14.318199] alg: No test for stdrng (krng)
[   14.331510] Block layer SCSI generic (bsg) driver version 0.4
loaded (major 252)
[   14.355960] io scheduler noop registered
[   14.369119] io scheduler anticipatory registered
[   14.384558] io scheduler deadline registered
[   14.399011] io scheduler cfq registered (default)
[   14.416324] pci_hotplug: PCI Hot Plug PCI Core version: 0.5
[   14.434795] input: Sleep Button as
/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0E:00/input/input0
[   14.462101] ACPI: Sleep Button [SLPB]
[   14.474475] input: Power Button as
/devices/LNXSYSTM:00/LNXPWRBN:00/input/input1
[   14.498985] ACPI: Power Button [PWRF]
[   14.517284] Event-channel device installed.
[   14.532898] blktap_device_init: blktap device major 253
[   14.549785] blktap_ring_init: blktap ring major: 251
[   14.569119] registering netback
[   14.583933] hpet_acpi_add: no address or irqs in _CRS
[   14.600423] Non-volatile memory driver v1.3
[   14.614307] Linux agpgart interface v0.103
[   14.628106] [drm] Initialized drm 1.1.0 20060810
[   14.643467] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
(XEN) irq.c:1139:d0 Cannot bind IRQ 4 to guest. In use by 'ns16550'.
(XEN) irq.c:1139:d0 Cannot bind IRQ 2 to guest. In use by 'cascade'.
(XEN) irq.c:1139:d0 Cannot bind IRQ 4 to guest. In use by 'ns16550'.
(XEN) irq.c:1139:d0 Cannot bind IRQ 2 to guest. In use by 'cascade'.
(XEN) irq.c:1139:d0 Cannot bind IRQ 4 to guest. In use by 'ns16550'.
(XEN) irq.c:1139:d0 Cannot bind IRQ 2 to guest. In use by 'cascade'.
(XEN) irq.c:1139:d0 Cannot bind IRQ 4 to guest. In use by 'ns16550'.
(XEN) irq.c:1139:d0 Cannot bind IRQ 2 to guest. In use by 'cascade'.
[   15.065371] serial8250: ttyS1 at I/O 0x2f8 (irq =3D 3) is a 16550A
[   15.086004] 00:09: ttyS1 at I/O 0x2f8 (irq =3D 3) is a 16550A
[   15.106511] brd: module loaded
[   15.166239] loop: module loaded
[   15.176421] input: Macintosh mouse button emulation as
/devices/virtual/input/input2
[   15.202110] 3ware 9000 Storage Controller device driver for Linux
v2.26.02.012.
[   15.226331] xen_allocate_pirq: returning irq 16 for gsi 16
[   15.244631] Already setup the GSI :16
[   15.256909] 3w-9xxx 0000:01:00.0: PCI INT A -> GSI 16 (level, low) -> IR=
Q 16
[   15.535246] 3w-9xxx: scsi0: AEN: INFO (0x04:0x0053): Battery
capacity test is overdue:.
[   15.662242] scsi0 : 3ware 9000 Storage Controller
[   15.677727] 3w-9xxx: scsi0: Found a 3ware 9000 Storage Controller
at 0xb3a00000, IRQ: 16.
[   16.010243] 3w-9xxx: scsi0: Firmware FH9X 4.10.00.021, BIOS BE9X
4.08.00.003, Ports: 128.
[   16.037272] scsi 0:0:0:0: Direct-Access     AMCC     9690SA-4I
DISK  4.10 PQ: 0 ANSI: 5
[   16.073169] sd 0:0:0:0: [sda] 2929666048 512-byte logical blocks:
(1.49 TB/1.36 TiB)
[   16.077572] sd 0:0:0:0: Attached scsi generic sg0 type 0
[   16.077953] Intel(R) PRO/1000 Network Driver - version 7.3.21-k5-NAPI
[   16.077955] Copyright (c) 1999-2006 Intel Corporation.
[   16.078011] e1000e: Intel(R) PRO/1000 Network Driver - 1.0.2-k2
[   16.078012] e1000e: Copyright (c) 1999-2008 Intel Corporation.
[   16.078055] xen_allocate_pirq: returning irq 16 for gsi 16
[   16.078058] Already setup the GSI :16
[   16.078061] e1000e 0000:00:19.0: PCI INT A -> GSI 16 (level, low) -> IRQ=
 16
[   16.248299] sd 0:0:0:0: [sda] Write Protect is off
[   16.264315] sd 0:0:0:0: [sda] Write cache: enabled, read cache:
enabled, supports DPO and FUA
[   16.293627]  sda: sda1 sda2 < sda5 sda6 sda7 sda8 sda9 >
[   16.362257] sd 0:0:0:0: [sda] Attached SCSI disk
[1032482.485795] IPT FORWARD [NEW INVALID] IN=3Deth0 OUT=3Deth0
PHYSIN=3Dvif2.0 PHYSOUT=3Dpeth0 SRC=3D192.168.40.18 DST=3D80.74.180.217
LEN=3D644 TOS=3D0x00 PREC=3D0x00 TTL=3D64 ID=3D9056 DF PROTO=3DTCP SPT=3D80=
 DPT=3D7629
WINDOW=3D82 RES=3D0x00 ACK PSH URGP=3D0
 __  __            _  _    ___   _
 \ \/ /___ _ __   | || |  / _ \ / |
  \  // _ \ '_ \  | || |_| | | || |
  /  \  __/ | | | |__   _| |_| || |
 /_/\_\___|_| |_|    |_|(_)___(_)_|

(XEN) Xen version 4.0.1 (root@mens-net.private) (gcc version 4.4.5
(Debian 4.4.5-8) ) Fri Dec  2 16:56:12 CET 2011
(XEN) Latest ChangeSet: unavailable
(XEN) Console output is synchronous.
(XEN) Bootloader: GNU GRUB 0.97
(XEN) Command line: dom0_mem=3D2048M max_cstate=3D1 loglvl=3Dall
guest_loglvl=3Dall sync_console com1=3D38400,8n1 console=3Dcom1
(XEN) Video information:
(XEN)  VGA is text mode 80x25, font 8x16
(XEN)  VBE/DDC methods: V2; EDID transfer time: 1 seconds
(XEN) Disc information:
(XEN)  Found 1 MBR signatures
(XEN)  Found 1 EDD information structures
(XEN) Xen-e820 RAM map:
(XEN)  0000000000000000 - 000000000009b800 (usable)
(XEN)  000000000009b800 - 00000000000a0000 (reserved)
(XEN)  00000000000e0000 - 0000000000100000 (reserved)
(XEN)  0000000000100000 - 000000009d8e9000 (usable)
(XEN)  000000009d8e9000 - 000000009d9bb000 (ACPI NVS)
(XEN)  000000009d9bb000 - 000000009f6a4000 (ACPI data)
(XEN)  000000009f6a4000 - 000000009f6df000 (reserved)
(XEN)  000000009f6df000 - 000000009f78a000 (ACPI data)
(XEN)  000000009f78a000 - 000000009f7df000 (ACPI NVS)
(XEN)  000000009f7df000 - 000000009f800000 (ACPI data)
(XEN)  000000009f800000 - 00000000b0000000 (reserved)
(XEN)  00000000fed1c000 - 00000000fed20000 (reserved)
(XEN)  00000000ff800000 - 0000000100000000 (reserved)
(XEN)  0000000100000000 - 0000000460000000 (usable)
(XEN) ACPI: RSDP 000F0410, 0024 (r2 INTEL )
(XEN) ACPI: XSDT 9F7FD120, 008C (r1 INTEL  S3420GPC        0       1000013)
(XEN) ACPI: FACP 9F7FB000, 00F4 (r4 INTEL  S3420GPC        0 MSFT  100000D)
(XEN) ACPI: DSDT 9F7F6000, 4E22 (r2 INTEL  S3420GPC        3 MSFT  100000D)
(XEN) ACPI: FACS 9F78A000, 0040
(XEN) ACPI: APIC 9F7F5000, 00BC (r2 INTEL  S3420GPC        0 MSFT  100000D)
(XEN) ACPI: MCFG 9F7F4000, 003C (r1 INTEL  S3420GPC        1 MSFT  100000D)
(XEN) ACPI: HPET 9F7F3000, 0038 (r1 INTEL  S3420GPC        1 MSFT  100000D)
(XEN) ACPI: SLIT 9F7F2000, 0030 (r1 INTEL  S3420GPC        1 MSFT  100000D)
(XEN) ACPI: SPCR 9F7F1000, 0050 (r1 INTEL  S3420GPC        0 MSFT  100000D)
(XEN) ACPI: WDDT 9F7F0000, 0040 (r1 INTEL  S3420GPC        0 MSFT  100000D)
(XEN) ACPI: SSDT 9F7E5000, AEF4 (r2  INTEL SSDT  PM     4000 INTL 20061109)
(XEN) ACPI: SSDT 9F7E4000, 01D8 (r2  INTEL IPMI         4000 INTL 20061109)
(XEN) ACPI: HEST 9F7E3000, 00A8 (r1 INTEL  S3420GPC        1 INTL        1)
(XEN) ACPI: BERT 9F7E2000, 0030 (r1 INTEL  S3420GPC        1 INTL        1)
(XEN) ACPI: ERST 9F7E1000, 0230 (r1 INTEL  S3420GPC        1 INTL        1)
(XEN) ACPI: EINJ 9F7E0000, 0130 (r1 INTEL  S3420GPC        1 INTL        1)
(XEN) System RAM: 16344MB (16736784kB)
(XEN) No NUMA configuration found
(XEN) Faking a node at 0000000000000000-0000000460000000
(XEN) Domain heap initialised
(XEN) found SMP MP-table at 000fd9a0
(XEN) DMI 2.5 present.
(XEN) Using APIC driver default
(XEN) ACPI: PM-Timer IO Port: 0x408
(XEN) ACPI: ACPI SLEEP INFO: pm1x_cnt[404,0], pm1x_evt[400,0]
(XEN) ACPI:                  wakeup_vec[9f78a00c], vec_size[20]
(XEN) ACPI: Local APIC address 0xfee00000
(XEN) ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
(XEN) Processor #0 7:14 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x02] enabled)
(XEN) Processor #2 7:14 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x02] lapic_id[0x04] enabled)
(XEN) Processor #4 7:14 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x03] lapic_id[0x06] enabled)
(XEN) Processor #6 7:14 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x04] lapic_id[0x01] disabled)
(XEN) ACPI: LAPIC (acpi_id[0x05] lapic_id[0x03] disabled)
(XEN) ACPI: LAPIC (acpi_id[0x06] lapic_id[0x05] disabled)
(XEN) ACPI: LAPIC (acpi_id[0x07] lapic_id[0x07] disabled)
(XEN) ACPI: LAPIC_NMI (acpi_id[0x00] high level lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x01] high level lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x02] high level lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x03] high level lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x04] high level lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x05] high level lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x06] high level lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x07] high level 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: 0x8086a801 base: 0xfed00000
(XEN) PCI: MCFG configuration 0: base a0000000 segment 0 buses 0 - 255
(XEN) PCI: MCFG area at a0000000 reserved in E820
(XEN) Using ACPI (MADT) for SMP configuration information
(XEN) Using scheduler: SMP Credit Scheduler (credit)
(XEN) Detected 2400.040 MHz processor.
(XEN) Initing memory sharing.
(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) EPT supports 2MB super page.
(XEN) HVM: ASIDs enabled.
(XEN) HVM: VMX enabled
(XEN) HVM: Hardware Assisted Paging detected.
(XEN) Intel machine check reporting enabled
(XEN) I/O virtualisation disabled
(XEN) Total of 4 processors activated.
(XEN) ENABLING IO-APIC IRQs
(XEN)  -> Using new ACK method
(XEN) ..TIMER: vector=3D0xF0 apic1=3D0 pin1=3D2 apic2=3D-1 pin2=3D-1
(XEN) TSC is reliable, synchronization unnecessary
(XEN) Platform timer appears to have unexpectedly wrapped 1 times.
(XEN) Platform timer is 14.318MHz HPET
=FF(XEN) Allocated console ring of 32 KiB.
(XEN) microcode.c:73:d32767 microcode: CPU1 resumed
(XEN) microcode.c:73:d32767 microcode: CPU3 resumed
(XEN) Brought up 4 CPUs
(XEN) microcode.c:73:d32767 microcode: CPU2 resumed
(XEN) Turbo Mode detected!
(XEN) HPET: 8 timers in total, 8 timers will be used for broadcast
(XEN) ACPI sleep modes: S3
(XEN) mcheck_poll: Machine check polling timer started.
(XEN) *** LOADING DOMAIN 0 ***
(XEN)  Xen  kernel: 64-bit, lsb, compat32
(XEN)  Dom0 kernel: 64-bit, PAE, lsb, paddr 0x1000000 -> 0x1bfc000
(XEN) PHYSICAL MEMORY ARRANGEMENT:
(XEN)  Dom0 alloc.:   0000000450000000->0000000454000000 (507904 pages
to be allocated)
(XEN) VIRTUAL MEMORY ARRANGEMENT:
(XEN)  Loaded kernel: ffffffff81000000->ffffffff81bfc000
(XEN)  Init. ramdisk: ffffffff81bfc000->ffffffff820c7c00
(XEN)  Phys-Mach map: ffffffff820c8000->ffffffff824c8000
(XEN)  Start info:    ffffffff824c8000->ffffffff824c84b4
(XEN)  Page tables:   ffffffff824c9000->ffffffff824e0000
(XEN)  Boot stack:    ffffffff824e0000->ffffffff824e1000
(XEN)  TOTAL:         ffffffff80000000->ffffffff82800000
(XEN)  ENTRY ADDRESS: ffffffff81976200
(XEN) Dom0 has maximum 4 VCPUs
(XEN) Scrubbing Free RAM:
...........................................................................=
..................................................................done.
(XEN) trace.c:89:d32767 calc_tinfo_first_offset: NR_CPUs 128,
offset_in_bytes 258, t_info_first_offset 65
(XEN) Xen trace buffers: disabled
(XEN) Std. Loglevel: All
(XEN) Guest Loglevel: All
(XEN) **********************************************
(XEN) ******* WARNING: CONSOLE OUTPUT IS SYNCHRONOUS
(XEN) ******* This option is intended to aid debugging of Xen by ensuring
(XEN) ******* that all output is synchronously delivered on the serial line.
(XEN) ******* However it can introduce SIGNIFICANT latencies and affect
(XEN) ******* timekeeping. It is NOT recommended for production use!
(XEN) **********************************************
(XEN) 3... 2... 1...
(XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch
input to Xen)
(XEN) Freed 176kB init memory.
mapping kernel into physical memory
Xen: setup ISA identity maps
about to get started...
[    0.000000] Initializing cgroup subsys cpuset
[    0.000000] Initializing cgroup subsys cpu
[    0.000000] Linux version 2.6.32.47 (root@xenhost-rack2) (gcc
version 4.4.5 (Debian 4.4.5-8) ) #1 SMP Fri Dec 2 13:05:28 CET 2011
[    0.000000] Command line:
root=3DUUID=3D5563bc26-6e98-4768-abee-5ca053e2795c ro nomodeset
max_loop=3D255 console=3Dhvc0 earlyprintk=3Dxen nomodeset initcall_debug
debug loglevel=3D10
[    0.000000] KERNEL supported cpus:
[    0.000000]   Intel GenuineIntel
[    0.000000]   AMD AuthenticAMD
[    0.000000]   Centaur CentaurHauls
[    0.000000] released 0 pages of unused memory
[    0.000000] BIOS-provided physical RAM map:
[    0.000000]  Xen: 0000000000000000 - 000000000009b000 (usable)
[    0.000000]  Xen: 000000000009b800 - 0000000000100000 (reserved)
[    0.000000]  Xen: 0000000000100000 - 0000000080000000 (usable)
[    0.000000]  Xen: 0000000080000000 - 000000009d8e9000 (unusable)
[    0.000000]  Xen: 000000009d8e9000 - 000000009d9bb000 (ACPI NVS)
[    0.000000]  Xen: 000000009d9bb000 - 000000009f6a4000 (ACPI data)
[    0.000000]  Xen: 000000009f6a4000 - 000000009f6df000 (reserved)
[    0.000000]  Xen: 000000009f6df000 - 000000009f78a000 (ACPI data)
[    0.000000]  Xen: 000000009f78a000 - 000000009f7df000 (ACPI NVS)
[    0.000000]  Xen: 000000009f7df000 - 000000009f800000 (ACPI data)
[    0.000000]  Xen: 000000009f800000 - 00000000b0000000 (reserved)
[    0.000000]  Xen: 00000000fec00000 - 00000000fec01000 (reserved)
[    0.000000]  Xen: 00000000fed1c000 - 00000000fed20000 (reserved)
[    0.000000]  Xen: 00000000fee00000 - 00000000fee01000 (reserved)
[    0.000000]  Xen: 00000000ff800000 - 0000000100000000 (reserved)
[    0.000000]  Xen: 0000000100000000 - 000000047d8e9000 (usable)
[    0.000000] bootconsole [xenboot0] enabled
[    0.000000] DMI 2.5 present.
[    0.000000] last_pfn =3D 0x47d8e9 max_arch_pfn =3D 0x400000000
[    0.000000] x86 PAT enabled: cpu 0, old 0x50100070406, new 0x70106000701=
06
[    0.000000] last_pfn =3D 0x80000 max_arch_pfn =3D 0x400000000
[    0.000000] e820 update range: 0000000000001000 - 0000000000006000
(usable) =3D=3D> (reserved)
[    0.000000] Scanning 1 areas for low memory corruption
[    0.000000] modified physical RAM map:
[    0.000000]  modified: 0000000000000000 - 0000000000001000 (usable)
[    0.000000]  modified: 0000000000001000 - 0000000000006000 (reserved)
[    0.000000]  modified: 0000000000006000 - 000000000009b000 (usable)
[    0.000000]  modified: 000000000009b800 - 0000000000100000 (reserved)
[    0.000000]  modified: 0000000000100000 - 0000000080000000 (usable)
[    0.000000]  modified: 0000000080000000 - 000000009d8e9000 (unusable)
[    0.000000]  modified: 000000009d8e9000 - 000000009d9bb000 (ACPI NVS)
[    0.000000]  modified: 000000009d9bb000 - 000000009f6a4000 (ACPI data)
[    0.000000]  modified: 000000009f6a4000 - 000000009f6df000 (reserved)
[    0.000000]  modified: 000000009f6df000 - 000000009f78a000 (ACPI data)
[    0.000000]  modified: 000000009f78a000 - 000000009f7df000 (ACPI NVS)
[    0.000000]  modified: 000000009f7df000 - 000000009f800000 (ACPI data)
[    0.000000]  modified: 000000009f800000 - 00000000b0000000 (reserved)
[    0.000000]  modified: 00000000fec00000 - 00000000fec01000 (reserved)
[    0.000000]  modified: 00000000fed1c000 - 00000000fed20000 (reserved)
[    0.000000]  modified: 00000000fee00000 - 00000000fee01000 (reserved)
[    0.000000]  modified: 00000000ff800000 - 0000000100000000 (reserved)
[    0.000000]  modified: 0000000100000000 - 000000047d8e9000 (usable)
[    0.000000] initial memory mapped : 0 - 020c8000
[    0.000000] init_memory_mapping: 0000000000000000-0000000080000000
[    0.000000]  0000000000 - 0080000000 page 4k
[    0.000000] kernel direct mapping tables up to 80000000 @ 100000-503000
[    0.000000] init_memory_mapping: 0000000100000000-000000047d8e9000
[    0.000000]  0100000000 - 047d8e9000 page 4k
[    0.000000] kernel direct mapping tables up to 47d8e9000 @ 24e0000-48e00=
00
[    0.000000] RAMDISK: 01bfc000 - 020c7c00
[    0.000000] ACPI: RSDP 00000000000f0410 00024 (v02 INTEL )
[    0.000000] ACPI: XSDT 000000009f7fd120 0008C (v01 INTEL  S3420GPC
00000000      01000013)
[    0.000000] ACPI: FACP 000000009f7fb000 000F4 (v04 INTEL  S3420GPC
00000000 MSFT 0100000D)
[    0.000000] ACPI: DSDT 000000009f7f6000 04E22 (v02 INTEL  S3420GPC
00000003 MSFT 0100000D)
[    0.000000] ACPI: FACS 000000009f78a000 00040
[    0.000000] ACPI: APIC 000000009f7f5000 000BC (v02 INTEL  S3420GPC
00000000 MSFT 0100000D)
[    0.000000] ACPI: MCFG 000000009f7f4000 0003C (v01 INTEL  S3420GPC
00000001 MSFT 0100000D)
[    0.000000] ACPI: HPET 000000009f7f3000 00038 (v01 INTEL  S3420GPC
00000001 MSFT 0100000D)
[    0.000000] ACPI: SLIT 000000009f7f2000 00030 (v01 INTEL  S3420GPC
00000001 MSFT 0100000D)
[    0.000000] ACPI: SPCR 000000009f7f1000 00050 (v01 INTEL  S3420GPC
00000000 MSFT 0100000D)
[    0.000000] ACPI: WDDT 000000009f7f0000 00040 (v01 INTEL  S3420GPC
00000000 MSFT 0100000D)
[    0.000000] ACPI: SSDT 000000009f7e5000 0AEF4 (v02  INTEL SSDT  PM
00004000 INTL 20061109)
[    0.000000] ACPI: SSDT 000000009f7e4000 001D8 (v02  INTEL IPMI
00004000 INTL 20061109)
[    0.000000] ACPI: HEST 000000009f7e3000 000A8 (v01 INTEL  S3420GPC
00000001 INTL 00000001)
[    0.000000] ACPI: BERT 000000009f7e2000 00030 (v01 INTEL  S3420GPC
00000001 INTL 00000001)
[    0.000000] ACPI: ERST 000000009f7e1000 00230 (v01 INTEL  S3420GPC
00000001 INTL 00000001)
[    0.000000] ACPI: EINJ 000000009f7e0000 00130 (v01 INTEL  S3420GPC
00000001 INTL 00000001)
[    0.000000] ACPI: Local APIC address 0xfee00000
[    0.000000] (10 early reservations) =3D=3D> bootmem [0000000000 - 047d8e=
9000]
[    0.000000]   #0 [0000000000 - 0000001000]   BIOS data page =3D=3D>
[0000000000 - 0000001000]
[    0.000000]   #1 [00024c9000 - 00024e0000]   XEN PAGETABLES =3D=3D>
[00024c9000 - 00024e0000]
[    0.000000]   #2 [0000006000 - 0000008000]       TRAMPOLINE =3D=3D>
[0000006000 - 0000008000]
[    0.000000]   #3 [0001000000 - 0001ad1474]    TEXT DATA BSS =3D=3D>
[0001000000 - 0001ad1474]
[    0.000000]   #4 [0001bfc000 - 00020c7c00]          RAMDISK =3D=3D>
[0001bfc000 - 00020c7c00]
[    0.000000]   #5 [00020c8000 - 00024c9000]   XEN START INFO =3D=3D>
[00020c8000 - 00024c9000]
[    0.000000]   #6 [0100000000 - 047d8e9000]        XEN EXTRA =3D=3D>
[0100000000 - 047d8e9000]
[    0.000000]   #7 [0001ad2000 - 0001ae036c]              BRK =3D=3D>
[0001ad2000 - 0001ae036c]
[    0.000000]   #8 [0000100000 - 00004e9000]          PGTABLE =3D=3D>
[0000100000 - 00004e9000]
[    0.000000]   #9 [00024e0000 - 00040db000]          PGTABLE =3D=3D>
[00024e0000 - 00040db000]
[    0.000000] found SMP MP-table at [ffff8800000fd9a0] fd9a0
[    0.000000] Zone PFN ranges:
[    0.000000]   DMA      0x00000000 -> 0x00001000
[    0.000000]   DMA32    0x00001000 -> 0x00100000
[    0.000000]   Normal   0x00100000 -> 0x0047d8e9
[    0.000000] Movable zone start PFN for each node
[    0.000000] early_node_map[4] active PFN ranges
[    0.000000]     0: 0x00000000 -> 0x00000001
[    0.000000]     0: 0x00000006 -> 0x0000009b
[    0.000000]     0: 0x00000100 -> 0x00080000
[    0.000000]     0: 0x00100000 -> 0x0047d8e9
[    0.000000] On node 0 totalpages: 4184191
[    0.000000]   DMA zone: 56 pages used for memmap
[    0.000000]   DMA zone: 1004 pages reserved
[    0.000000]   DMA zone: 2930 pages, LIFO batch:0
[    0.000000]   DMA32 zone: 14280 pages used for memmap
[    0.000000]   DMA32 zone: 505912 pages, LIFO batch:31
[    0.000000]   Normal zone: 50040 pages used for memmap
[    0.000000]   Normal zone: 3609969 pages, LIFO batch:31
[    0.000000] ACPI: PM-Timer IO Port: 0x408
[    0.000000] ACPI: Local APIC address 0xfee00000
[    0.000000] ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x02] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x04] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x03] lapic_id[0x06] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x04] lapic_id[0x01] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x05] lapic_id[0x03] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x06] lapic_id[0x05] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x07] lapic_id[0x07] disabled)
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x00] high level lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x01] high level lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x02] high level lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x03] high level lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x04] high level lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x05] high level lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x06] high level lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x07] high level lint[0x1])
[    0.000000] ACPI: IOAPIC (id[0x08] address[0xfec00000] gsi_base[0])
[    0.000000] IOAPIC[0]: apic_id 8, version 0, address 0xfec00000, GSI 0-0
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
[    0.000000] ERROR: Unable to locate IOAPIC for GSI 2
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
[    0.000000] ERROR: Unable to locate IOAPIC for GSI 9
[    0.000000] Using ACPI (MADT) for SMP configuration information
[    0.000000] ACPI: HPET id: 0x8086a801 base: 0xfed00000
[    0.000000] SMP: Allowing 4 CPUs, 0 hotplug CPUs
[    0.000000] nr_irqs_gsi: 256
[    0.000000] PM: Registered nosave memory: 0000000000001000 - 00000000000=
06000
[    0.000000] PM: Registered nosave memory: 000000000009b000 - 00000000000=
9c000
[    0.000000] PM: Registered nosave memory: 000000000009c000 - 00000000001=
00000
[    0.000000] PM: Registered nosave memory: 0000000080000000 - 000000009d8=
e9000
[    0.000000] PM: Registered nosave memory: 000000009d8e9000 - 000000009d9=
bb000
[    0.000000] PM: Registered nosave memory: 000000009d9bb000 - 000000009f6=
a4000
[    0.000000] PM: Registered nosave memory: 000000009f6a4000 - 000000009f6=
df000
[    0.000000] PM: Registered nosave memory: 000000009f6df000 - 000000009f7=
8a000
[    0.000000] PM: Registered nosave memory: 000000009f78a000 - 000000009f7=
df000
[    0.000000] PM: Registered nosave memory: 000000009f7df000 - 000000009f8=
00000
[    0.000000] PM: Registered nosave memory: 000000009f800000 - 00000000b00=
00000
[    0.000000] PM: Registered nosave memory: 00000000b0000000 - 00000000fec=
00000
[    0.000000] PM: Registered nosave memory: 00000000fec00000 - 00000000fec=
01000
[    0.000000] PM: Registered nosave memory: 00000000fec01000 - 00000000fed=
1c000
[    0.000000] PM: Registered nosave memory: 00000000fed1c000 - 00000000fed=
20000
[    0.000000] PM: Registered nosave memory: 00000000fed20000 - 00000000fee=
00000
[    0.000000] PM: Registered nosave memory: 00000000fee00000 - 00000000fee=
01000
[    0.000000] PM: Registered nosave memory: 00000000fee01000 - 00000000ff8=
00000
[    0.000000] PM: Registered nosave memory: 00000000ff800000 - 00000001000=
00000
[    0.000000] Allocating PCI resources starting at b0000000 (gap:
b0000000:4ec00000)
[    0.000000] Booting paravirtualized kernel on Xen
[    0.000000] Xen version: 4.0.1 (preserve-AD) (dom0)
[    0.000000] NR_CPUS:8 nr_cpumask_bits:8 nr_cpu_ids:4 nr_node_ids:1
[    0.000000] PERCPU: Embedded 29 pages/cpu @ffff880028038000 s88536
r8192 d22056 u118784
[    0.000000] pcpu-alloc: s88536 r8192 d22056 u118784 alloc=3D29*4096
[    0.000000] pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3
[   10.311419] Built 1 zonelists in Zone order, mobility grouping on.
Total pages: 4118811
[   10.338004] Kernel command line:
root=3DUUID=3D5563bc26-6e98-4768-abee-5ca053e2795c ro nomodeset
max_loop=3D255 console=3Dhvc0 earlyprintk=3Dxen nomodeset initcall_debug
debug loglevel=3D10
[   10.390120] PID hash table entries: 4096 (order: 3, 32768 bytes)
[   10.411419] Dentry cache hash table entries: 2097152 (order: 12,
16777216 bytes)
[   10.438973] Inode-cache hash table entries: 1048576 (order: 11,
8388608 bytes)
[   10.464013] Initializing CPU#0
[   10.480240] DMA: Placing 64MB software IO TLB between
ffff880020000000 - ffff880024000000
[   10.506573] DMA: software IO TLB at phys 0x20000000 - 0x24000000
[   10.526301] xen_swiotlb_fixup: buf=3Dffff880020000000 size=3D67108864
[   10.564039] xen_swiotlb_fixup: buf=3Dffff880024060000 size=3D32768
[   10.590216] Memory: 1722512k/18834340k available (5877k kernel
code, 2097576k absent, 15013600k reserved, 3717k data, 568k init)
[   10.627713] SLUB: Genslabs=3D13, HWalign=3D64, Order=3D0-3, MinObjects=
=3D0,
CPUs=3D4, Nodes=3D1
[   10.652877] Hierarchical RCU implementation.
[   10.666880] NR_IRQS:4352 nr_irqs:1280
[   10.678959] xen: --> irq=3D0
[   10.687790] xen: --> irq=3D1
[   10.696651] xen: --> irq=3D2
[   10.705516] xen: --> irq=3D3
[   10.714382] xen: --> irq=3D4
[   10.723247] xen: --> irq=3D5
[   10.732113] xen: --> irq=3D6
[   10.740979] xen: --> irq=3D7
[   10.749844] xen: --> irq=3D8
[   10.758711] xen: --> irq=3D9
[   10.767577] xen: --> irq=3D10
[   10.776728] xen: --> irq=3D11
[   10.785880] xen: --> irq=3D12
[   10.795031] xen: --> irq=3D13
[   10.804183] xen: --> irq=3D14
[   10.813336] xen: --> irq=3D15
[   10.822497] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
[   10.843363] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
[   10.865097] xen: sci override: source_irq=3D9 global_irq=3D9 trigger=3Dc=
 polarity=3D1
[   10.888550] xen: registering gsi 9 triggering 0 polarity 0
[   10.906566] xen_allocate_pirq: returning irq 9 for gsi 9
[   10.924012] xen: --> irq=3D9
[   10.932880] xen: acpi sci 9
[   10.952809] Console: colour VGA+ 80x25
[   10.964550] console [hvc0] enabled, bootconsole disabled
[   10.964550] console [hvc0] enabled, bootconsole disabled
[   10.999734] Xen: using vcpuop timer interface
[   11.014307] installing Xen timer for CPU 0
[   11.028044]   alloc irq_desc for 1279 on node -1
[   11.043477]   alloc kstat_irqs on node -1
[   11.056938] Detected 2400.040 MHz processor.
[   11.071222] Calibrating delay loop (skipped), value calculated
using timer frequency.. 4800.08 BogoMIPS (lpj=3D2400040)
[   11.106407] Security Framework initialized
[   11.120129] SELinux:  Initializing.
[   11.131853] SELinux:  Starting in permissive mode
[   11.147581] Mount-cache hash table entries: 256
[   11.162872] Initializing cgroup subsys ns
[   11.176183] Initializing cgroup subsys cpuacct
[   11.191051] Initializing cgroup subsys freezer
[   11.205950] CPU: L1 I cache: 32K, L1 D cache: 32K
[   11.221649] CPU: L2 cache: 256K
[   11.232231] CPU: L3 cache: 8192K
[   11.243104] CPU: Unsupported number of siblings 16
[   11.258262] mce: CPU supports 9 MCE banks
[   11.272583] Performance Events: unsupported p6 CPU model 30 no PMU
driver, software events only.
[   11.301735] SMP alternatives: switching to UP code
[   11.354691] ACPI: Core revision 20090903
[   11.387437]   alloc irq_desc for 1278 on node -1
[   11.402317]   alloc kstat_irqs on node -1
[   11.415771]   alloc irq_desc for 1277 on node -1
[   11.431203]   alloc kstat_irqs on node -1
[   11.444653]   alloc irq_desc for 1276 on node -1
[   11.460086]   alloc kstat_irqs on node -1
[   11.473539]   alloc irq_desc for 1275 on node -1
[   11.488972]   alloc kstat_irqs on node -1
[   11.502443] calling  migration_init+0x0/0x5a @ 1
[   11.517890] initcall migration_init+0x0/0x5a returned 0 after 976 usecs
[   11.539884] calling  spawn_ksoftirqd+0x0/0x59 @ 1
[   11.555630] initcall spawn_ksoftirqd+0x0/0x59 returned 0 after 976 usecs
[   11.577922] calling  init_call_single_data+0x0/0x89 @ 1
[   11.595367] initcall init_call_single_data+0x0/0x89 returned 0 after 0 u=
secs
[   11.618815] calling  relay_init+0x0/0x14 @ 1
[   11.633112] initcall relay_init+0x0/0x14 returned 0 after 0 usecs
[   11.653418] calling  tracer_alloc_buffers+0x0/0x173 @ 1
[   11.670885] initcall tracer_alloc_buffers+0x0/0x173 returned 0 after 0 u=
secs
[   11.694344] calling  init_trace_printk+0x0/0x12 @ 1
[   11.710647] initcall init_trace_printk+0x0/0x12 returned 0 after 0 usecs
[   11.732958] calling  mce_amd_init+0x0/0x33 @ 1
[   11.747824] initcall mce_amd_init+0x0/0x33 returned 0 after 0 usecs
[   11.768745] installing Xen timer for CPU 1
[   11.782435]   alloc irq_desc for 1274 on node -1
[   11.797872]   alloc kstat_irqs on node -1
[   11.811342] SMP alternatives: switching to SMP code
[   11.863556]   alloc irq_desc for 1273 on node -1
[   11.878435]   alloc kstat_irqs on node -1
[   11.891891]   alloc irq_desc for 1272 on node -1
[   11.907322]   alloc kstat_irqs on node -1
[   11.920773]   alloc irq_desc for 1271 on node -1
[   11.936207]   alloc kstat_irqs on node -1
[   11.949657]   alloc irq_desc for 1270 on node -1
[   11.965092]   alloc kstat_irqs on node -1
[   11.978549] Initializing CPU#1
[   11.978585] CPU: L1 I cache: 32K, L1 D cache: 32K
[   11.978587] CPU: L2 cache: 256K
[   11.978589] CPU: L3 cache: 8192K
[   11.978592] CPU: Unsupported number of siblings 16
[   11.978669] installing Xen timer for CPU 2
[   12.055756]   alloc irq_desc for 1269 on node -1
[   12.071195]   alloc kstat_irqs on node -1
[   12.084662]   alloc irq_desc for 1268 on node -1
[   12.100080]   alloc kstat_irqs on node -1
[   12.113533]   alloc irq_desc for 1267 on node -1
[   12.128965]   alloc kstat_irqs on node -1
[   12.142416]   alloc irq_desc for 1266 on node -1
[   12.157851]   alloc kstat_irqs on node -1
[   12.171305]   alloc irq_desc for 1265 on node -1
[   12.186735]   alloc kstat_irqs on node -1
[   12.200192] Initializing CPU#2
[   12.200226] CPU: L1 I cache: 32K, L1 D cache: 32K
[   12.200228] CPU: L2 cache: 256K
[   12.200229] CPU: L3 cache: 8192K
[   12.200233] CPU: Unsupported number of siblings 16
[   12.200303] installing Xen timer for CPU 3
[   12.277400]   alloc irq_desc for 1264 on node -1
[   12.292839]   alloc kstat_irqs on node -1
[   12.306306]   alloc irq_desc for 1263 on node -1
[   12.321723]   alloc kstat_irqs on node -1
[   12.335176]   alloc irq_desc for 1262 on node -1
[   12.350609]   alloc kstat_irqs on node -1
[   12.364060]   alloc irq_desc for 1261 on node -1
[   12.379495]   alloc kstat_irqs on node -1
[   12.392945]   alloc irq_desc for 1260 on node -1
[   12.408378]   alloc kstat_irqs on node -1
[   12.421836] Initializing CPU#3
[   12.421869] CPU: L1 I cache: 32K, L1 D cache: 32K
[   12.421871] CPU: L2 cache: 256K
[   12.421873] CPU: L3 cache: 8192K
[   12.421876] CPU: Unsupported number of siblings 16
[   12.421909] Brought up 4 CPUs
[   12.495792] calling  init_mmap_min_addr+0x0/0x26 @ 1
[   12.511910] initcall init_mmap_min_addr+0x0/0x26 returned 0 after 0 usecs
[   12.534507] calling  init_cpufreq_transition_notifier_list+0x0/0x1b @ 1
[   12.556528] initcall init_cpufreq_transition_notifier_list+0x0/0x1b
returned 0 after 0 usecs
[   12.584552] calling  net_ns_init+0x0/0xed @ 1
[   12.599178] initcall net_ns_init+0x0/0xed returned 0 after 976 usecs
[   12.620301] calling  e820_mark_nvs_memory+0x0/0x40 @ 1
[   12.637520] initcall e820_mark_nvs_memory+0x0/0x40 returned 0 after 976 =
usecs
[   12.661198] calling  cpufreq_tsc+0x0/0x28 @ 1
[   12.675782] initcall cpufreq_tsc+0x0/0x28 returned 0 after 0 usecs
[   12.696404] calling  pci_reboot_init+0x0/0x14 @ 1
[   12.712134] initcall pci_reboot_init+0x0/0x14 returned 0 after 0 usecs
[   12.733873] calling  init_lapic_sysfs+0x0/0x2d @ 1
[   12.749974] initcall init_lapic_sysfs+0x0/0x2d returned 0 after 976 usecs
[   12.772483] calling  alloc_frozen_cpus+0x0/0x8 @ 1
[   12.788492] initcall alloc_frozen_cpus+0x0/0x8 returned 0 after 0 usecs
[   12.810517] calling  sysctl_init+0x0/0x32 @ 1
[   12.825200] initcall sysctl_init+0x0/0x32 returned 0 after 0 usecs
[   12.845691] calling  ksysfs_init+0x0/0x94 @ 1
[   12.860281] initcall ksysfs_init+0x0/0x94 returned 0 after 0 usecs
[   12.880867] calling  async_init+0x0/0x60 @ 1
[   12.895198] initcall async_init+0x0/0x60 returned 0 after 976 usecs
[   12.916045] calling  init_jiffies_clocksource+0x0/0x12 @ 1
[   12.934353] initcall init_jiffies_clocksource+0x0/0x12 returned 0
after 0 usecs
[   12.958658] calling  pm_init+0x0/0x34 @ 1
[   12.972106] initcall pm_init+0x0/0x34 returned 0 after 0 usecs
[   12.991545] calling  pm_disk_init+0x0/0x19 @ 1
[   13.006420] initcall pm_disk_init+0x0/0x19 returned 0 after 0 usecs
[   13.027297] calling  swsusp_header_init+0x0/0x2c @ 1
[   13.043884] initcall swsusp_header_init+0x0/0x2c returned 0 after 0 usecs
[   13.066480] calling  init_zero_pfn+0x0/0x68 @ 1
[   13.081635] initcall init_zero_pfn+0x0/0x68 returned 0 after 0 usecs
[   13.102796] calling  filelock_init+0x0/0x2e @ 1
[   13.117956] initcall filelock_init+0x0/0x2e returned 0 after 0 usecs
[   13.139118] calling  init_misc_binfmt+0x0/0x44 @ 1
[   13.155134] initcall init_misc_binfmt+0x0/0x44 returned 0 after 0 usecs
[   13.177159] calling  init_script_binfmt+0x0/0x14 @ 1
[   13.193742] initcall init_script_binfmt+0x0/0x14 returned 0 after 0 usecs
[   13.216340] calling  init_elf_binfmt+0x0/0x14 @ 1
[   13.232066] initcall init_elf_binfmt+0x0/0x14 returned 0 after 0 usecs
[   13.253804] calling  init_compat_elf_binfmt+0x0/0x14 @ 1
[   13.271536] initcall init_compat_elf_binfmt+0x0/0x14 returned 0 after 0 =
usecs
[   13.295271] calling  debugfs_init+0x0/0x5c @ 1
[   13.310142] initcall debugfs_init+0x0/0x5c returned 0 after 0 usecs
[   13.331018] calling  random32_init+0x0/0xd8 @ 1
[   13.346177] initcall random32_init+0x0/0xd8 returned 0 after 0 usecs
[   13.367341] calling  __gnttab_init+0x0/0x21 @ 1
[   13.382510] Grant table initialized
[   13.394222] initcall __gnttab_init+0x0/0x21 returned 0 after 976 usecs
[   13.415964] calling  early_resume_init+0x0/0x19e @ 1
[   13.432573] Time: 16:33:26  Date: 12/14/11
[   13.446278] initcall early_resume_init+0x0/0x19e returned 0 after 0 usecs
[   13.468870] calling  cpufreq_core_init+0x0/0x9b @ 1
[   13.485170] initcall cpufreq_core_init+0x0/0x9b returned 0 after 0 usecs
[   13.507478] calling  cpuidle_init+0x0/0x40 @ 1
[   13.522348] initcall cpuidle_init+0x0/0x40 returned 0 after 0 usecs
[   13.543225] calling  sock_init+0x0/0x5e @ 1
[   13.557277] initcall sock_init+0x0/0x5e returned 0 after 976 usecs
[   13.577829] calling  net_inuse_init+0x0/0x26 @ 1
[   13.593274] initcall net_inuse_init+0x0/0x26 returned 0 after 0 usecs
[   13.614725] calling  netpoll_init+0x0/0x31 @ 1
[   13.629595] initcall netpoll_init+0x0/0x31 returned 0 after 0 usecs
[   13.650471] calling  netlink_proto_init+0x0/0x143 @ 1
[   13.667352] NET: Registered protocol family 16
[   13.682228] initcall netlink_proto_init+0x0/0x143 returned 0 after 976 u=
secs
[   13.705696] calling  bdi_class_init+0x0/0x41 @ 1
[   13.721200] initcall bdi_class_init+0x0/0x41 returned 0 after 976 usecs
[   13.743167] calling  kobject_uevent_init+0x0/0x54 @ 1
[   13.760046] initcall kobject_uevent_init+0x0/0x54 returned 0 after 976 u=
secs
[   13.783487] calling  pcibus_class_init+0x0/0x19 @ 1
[   13.799837] initcall pcibus_class_init+0x0/0x19 returned 0 after 976 use=
cs
[   13.822672] calling  pci_driver_init+0x0/0x12 @ 1
[   13.838455] initcall pci_driver_init+0x0/0x12 returned 0 after 976 usecs
[   13.860709] calling  backlight_class_init+0x0/0x5d @ 1
[   13.877914] initcall backlight_class_init+0x0/0x5d returned 0 after 976 =
usecs
[   13.901601] calling  video_output_class_init+0x0/0x19 @ 1
[   13.919669] initcall video_output_class_init+0x0/0x19 returned 0
after 976 usecs
[   13.944214] calling  xenbus_init+0x0/0x2c7 @ 1
[   13.959092]   alloc irq_desc for 1259 on node -1
[   13.974528]   alloc kstat_irqs on node -1
[   13.988039] initcall xenbus_init+0x0/0x2c7 returned 0 after 1952 usecs
[   14.009710] calling  tty_class_init+0x0/0x38 @ 1
[   14.025196] initcall tty_class_init+0x0/0x38 returned 0 after 976 usecs
[   14.047175] calling  vtconsole_class_init+0x0/0xc2 @ 1
[   14.064437] initcall vtconsole_class_init+0x0/0xc2 returned 0 after 976 =
usecs
[   14.088067] calling  i2c_init+0x0/0x6a @ 1
[   14.101898] initcall i2c_init+0x0/0x6a returned 0 after 976 usecs
[   14.122102] calling  amd_postcore_init+0x0/0x77 @ 1
[   14.138403] initcall amd_postcore_init+0x0/0x77 returned 0 after 0 usecs
[   14.160713] calling  arch_kdebugfs_init+0x0/0x235 @ 1
[   14.177595] initcall arch_kdebugfs_init+0x0/0x235 returned 0 after 0 use=
cs
[   14.200467] calling  mtrr_if_init+0x0/0x61 @ 1
[   14.215336] initcall mtrr_if_init+0x0/0x61 returned 0 after 0 usecs
[   14.236213] calling  ffh_cstate_init+0x0/0x2a @ 1
[   14.251943] initcall ffh_cstate_init+0x0/0x2a returned 0 after 0 usecs
[   14.273681] calling  acpi_pci_init+0x0/0x57 @ 1
[   14.288832] ACPI FADT declares the system doesn't support PCIe
ASPM, so disable it
[   14.314001] ACPI: bus type pci registered
[   14.327447] initcall acpi_pci_init+0x0/0x57 returned 0 after 0 usecs
[   14.348607] calling  xen_pcpu_init+0x0/0xa8 @ 1
[   14.363859] sync cpu 0 get result 1 max_id 3
[   14.378115] sync cpu 1 get result 1 max_id 3
[   14.392415] sync cpu 2 get result 1 max_id 3
[   14.406714] sync cpu 3 get result 1 max_id 3
[   14.420961]   alloc irq_desc for 1258 on node -1
[   14.436404]   alloc kstat_irqs on node -1
[   14.449863] initcall xen_pcpu_init+0x0/0xa8 returned 1258 after 4882 use=
cs
[   14.472731] initcall xen_pcpu_init+0x0/0xa8 returned with error code 1258
[   14.495610] calling  register_xen_pci_notifier+0x0/0x24 @ 1
[   14.514200] initcall register_xen_pci_notifier+0x0/0x24 returned 0
after 0 usecs
[   14.538789] calling  setup_vcpu_hotplug_event+0x0/0x22 @ 1
[   14.557098] initcall setup_vcpu_hotplug_event+0x0/0x22 returned 0
after 0 usecs
[   14.581402] calling  dmi_id_init+0x0/0x319 @ 1
[   14.596397] initcall dmi_id_init+0x0/0x319 returned 0 after 976 usecs
[   14.617729] calling  pci_arch_init+0x0/0x60 @ 1
[   14.632913] PCI: MCFG configuration 0: base a0000000 segment 0 buses 0 -=
 255
[   14.656332] PCI: MCFG area at a0000000 reserved in E820
[   14.697586] PCI: Using MMCONFIG at a0000000 - afffffff
[   14.714186] PCI: Using configuration type 1 for base access
[   14.732781] initcall pci_arch_init+0x0/0x60 returned 0 after 21481 usecs
[   14.755084] calling  topology_init+0x0/0x40 @ 1
[   14.770429] initcall topology_init+0x0/0x40 returned 0 after 976 usecs
[   14.791977] calling  mtrr_init_finialize+0x0/0x3d @ 1
[   14.808851] initcall mtrr_init_finialize+0x0/0x3d returned 0 after 0 use=
cs
[   14.831730] calling  param_sysfs_init+0x0/0x224 @ 1
[   14.859267] initcall param_sysfs_init+0x0/0x224 returned 0 after 11716 u=
secs
[   14.882156] calling  pm_sysrq_init+0x0/0x19 @ 1
[   14.897314] initcall pm_sysrq_init+0x0/0x19 returned 0 after 0 usecs
[   14.918478] calling  audit_watch_init+0x0/0x2f @ 1
[   14.934494] initcall audit_watch_init+0x0/0x2f returned 0 after 0 usecs
[   14.956518] calling  init_slow_work+0x0/0x3e @ 1
[   14.971958] initcall init_slow_work+0x0/0x3e returned 0 after 0 usecs
[   14.993411] calling  default_bdi_init+0x0/0xb1 @ 1
[   15.009543] initcall default_bdi_init+0x0/0xb1 returned 0 after 976 usecs
[   15.032019] calling  init_bio+0x0/0xda @ 1
[   15.045750] bio: create slab <bio-0> at 0
[   15.059189] initcall init_bio+0x0/0xda returned 0 after 0 usecs
[   15.078917] calling  fsnotify_init+0x0/0x12 @ 1
[   15.094076] initcall fsnotify_init+0x0/0x12 returned 0 after 0 usecs
[   15.115239] calling  fsnotify_notification_init+0x0/0xf0 @ 1
[   15.134117] initcall fsnotify_notification_init+0x0/0xf0 returned 0
after 0 usecs
[   15.158995] calling  cryptomgr_init+0x0/0x12 @ 1
[   15.174440] initcall cryptomgr_init+0x0/0x12 returned 0 after 0 usecs
[   15.195894] calling  blk_settings_init+0x0/0x2a @ 1
[   15.212191] initcall blk_settings_init+0x0/0x2a returned 0 after 0 usecs
[   15.234502] calling  blk_ioc_init+0x0/0x2a @ 1
[   15.249370] initcall blk_ioc_init+0x0/0x2a returned 0 after 0 usecs
[   15.270246] calling  blk_softirq_init+0x0/0x6e @ 1
[   15.286263] initcall blk_softirq_init+0x0/0x6e returned 0 after 0 usecs
[   15.308287] calling  blk_iopoll_setup+0x0/0x6e @ 1
[   15.324301] initcall blk_iopoll_setup+0x0/0x6e returned 0 after 0 usecs
[   15.346324] calling  genhd_device_init+0x0/0x7b @ 1
[   15.362769] initcall genhd_device_init+0x0/0x7b returned 0 after 976 use=
cs
[   15.385507] calling  pci_slot_init+0x0/0x46 @ 1
[   15.400661] initcall pci_slot_init+0x0/0x46 returned 0 after 0 usecs
[   15.421822] calling  fbmem_init+0x0/0x98 @ 1
[   15.436175] initcall fbmem_init+0x0/0x98 returned 0 after 976 usecs
[   15.457000] calling  acpi_init+0x0/0x130 @ 1
[   15.472585] ERROR: Unable to locate IOAPIC for GSI 9
[   15.488638] ACPI: EC: Look up EC in DSDT
[   15.502971] ACPI Error: Field [CPB3] at 96 exceeds Buffer [NULL]
size 64 (bits) (20090903/dsopcode-596)
[   15.533587] ACPI Error (psparse-0537): Method parse/execution
failed [\_SB_._OSC] (Node ffff88007fc187c0), AE_AML_BUFFER_LIMIT
[   15.594403] ACPI: Interpreter enabled
[   15.606143] ACPI: (supports S0 S1 S5)
[   15.618442] ACPI: Using IOAPIC for interrupt routing
[   15.647695] initcall acpi_init+0x0/0x130 returned 0 after 38080 usecs
[   15.668586] calling  dock_init+0x0/0x8d @ 1
[   15.682694] ACPI: No dock devices found.
[   15.695785] initcall dock_init+0x0/0x8d returned 0 after 0 usecs
[   15.715799] calling  acpi_pci_root_init+0x0/0x28 @ 1
[   15.733153] ACPI: PCI Root Bridge [PCI0] (0000:00)
[   15.748882] pci 0000:00:05.0: PME# supported from D0 D3hot D3cold
[   15.768915] pci 0000:00:05.0: PME# disabled
[   15.783492] pci 0000:00:19.0: reg 10 32bit mmio: [0xb3b00000-0xb3b1ffff]
[   15.805249] pci 0000:00:19.0: reg 14 32bit mmio: [0xb3b24000-0xb3b24fff]
[   15.827556] pci 0000:00:19.0: reg 18 io port: [0x3020-0x303f]
[   15.846775] pci 0000:00:19.0: PME# supported from D0 D3hot D3cold
[   15.867015] pci 0000:00:19.0: PME# disabled
[   15.881118] pci 0000:00:1a.0: reg 10 32bit mmio: [0xb3b21000-0xb3b213ff]
[   15.903426] pci 0000:00:1a.0: PME# supported from D0 D3hot D3cold
[   15.923642] pci 0000:00:1a.0: PME# disabled
[   15.937766] pci 0000:00:1c.0: PME# supported from D0 D3hot D3cold
[   15.957960] pci 0000:00:1c.0: PME# disabled
[   15.972088] pci 0000:00:1c.4: PME# supported from D0 D3hot D3cold
[   15.992278] pci 0000:00:1c.4: PME# disabled
[   16.006403] pci 0000:00:1c.6: PME# supported from D0 D3hot D3cold
[   16.026599] pci 0000:00:1c.6: PME# disabled
[   16.040723] pci 0000:00:1c.7: PME# supported from D0 D3hot D3cold
[   16.060917] pci 0000:00:1c.7: PME# disabled
[   16.075015] pci 0000:00:1d.0: reg 10 32bit mmio: [0xb3b20000-0xb3b203ff]
[   16.097329] pci 0000:00:1d.0: PME# supported from D0 D3hot D3cold
[   16.117544] pci 0000:00:1d.0: PME# disabled
[   16.131828] pci 0000:00:1f.3: reg 10 64bit mmio: [0xb3b22000-0xb3b220ff]
[   16.153885] pci 0000:00:1f.3: reg 20 io port: [0x3000-0x301f]
[   16.173110] pci 0000:01:00.0: reg 10 64bit mmio pref: [0xb0000000-0xb1ff=
ffff]
[   16.196774] pci 0000:01:00.0: reg 18 64bit mmio: [0xb3a00000-0xb3a00fff]
[   16.219078] pci 0000:01:00.0: reg 20 io port: [0x2000-0x20ff]
[   16.238242] pci 0000:01:00.0: reg 30 32bit mmio pref: [0xfffe0000-0xffff=
ffff]
[   16.262001] pci 0000:01:00.0: supports D1 D2
[   16.276323] pci 0000:00:05.0: bridge io port: [0x2000-0x2fff]
[   16.295430] pci 0000:00:05.0: bridge 32bit mmio: [0xb3a00000-0xb3afffff]
[   16.317745] pci 0000:00:05.0: bridge 64bit mmio pref: [0xb0000000-0xb1ff=
ffff]
[   16.341634] pci 0000:03:00.0: reg 10 32bit mmio: [0xb3900000-0xb391ffff]
[   16.363808] pci 0000:03:00.0: reg 18 io port: [0x1000-0x101f]
[   16.382952] pci 0000:03:00.0: reg 1c 32bit mmio: [0xb3920000-0xb3923fff]
[   16.405360] pci 0000:03:00.0: PME# supported from D0 D3hot D3cold
[   16.425559] pci 0000:03:00.0: PME# disabled
[   16.439662] pci 0000:00:1c.4: bridge io port: [0x1000-0x1fff]
[   16.458732] pci 0000:00:1c.4: bridge 32bit mmio: [0xb3900000-0xb39fffff]
[   16.481112] pci 0000:04:00.0: reg 10 32bit mmio pref: [0xb2000000-0xb2ff=
ffff]
[   16.504785] pci 0000:04:00.0: reg 14 32bit mmio: [0xb3800000-0xb3803fff]
[   16.527095] pci 0000:04:00.0: reg 18 32bit mmio: [0xb3000000-0xb37fffff]
[   16.549435] pci 0000:04:00.0: reg 30 32bit mmio pref: [0xffff0000-0xffff=
ffff]
[   16.573258] pci 0000:00:1c.6: bridge 32bit mmio: [0xb3000000-0xb38fffff]
[   16.595443] pci 0000:00:1c.6: bridge 64bit mmio pref: [0xb2000000-0xb2ff=
ffff]
[   16.619320] pci 0000:00:1e.0: transparent bridge
[   16.634669] pci_bus 0000:00: on NUMA node 0
[   16.648633] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
[   16.668734] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.MRP3._PRT]
[   16.689623] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PEX0._PRT]
[   16.710806] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PEX4._PRT]
[   16.731922] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PEX6._PRT]
[   16.753123] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.IP2P._PRT]
(XEN) PCI add device 00:00.0
(XEN) PCI add device 00:05.0
(XEN) PCI add device 00:08.0
(XEN) PCI add device 00:08.1
(XEN) PCI add device 00:08.2
(XEN) PCI add device 00:08.3
(XEN) PCI add device 00:10.0
(XEN) PCI add device 00:10.1
(XEN) PCI add device 00:19.0
(XEN) PCI add device 00:1a.0
(XEN) PCI add device 00:1c.0
(XEN) PCI add device 00:1c.4
(XEN) PCI add device 00:1c.6
(XEN) PCI add device 00:1c.7
(XEN) PCI add device 00:1d.0
(XEN) PCI add device 00:1e.0
(XEN) PCI add device 00:1f.0
(XEN) PCI add device 00:1f.3
(XEN) PCI add device 01:00.0
(XEN) PCI add device 03:00.0
(XEN) PCI add device 04:00.0
[   16.954739] initcall acpi_pci_root_init+0x0/0x28 returned 0 after 25386 =
usecs
[   16.978208] calling  acpi_pci_link_init+0x0/0x43 @ 1
[   16.994873] ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 9 *10
11 12 14 15)
[   17.018917] ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 9 10
*11 12 14 15)
[   17.042938] ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 *5 6 7 9 10
11 12 14 15)
[   17.066986] ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 7 9 10
*11 12 14 15)
[   17.090987] ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 7 9 10 11
12 14 15) *0, disabled.
[   17.118722] ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 6 7 *9 10
11 12 14 15)
[   17.142750] ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 6 7 9 10 11
12 14 15) *0, disabled.
[   17.170486] ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 6 7 9 *10
11 12 14 15)
[   17.194505] initcall acpi_pci_link_init+0x0/0x43 returned 0 after 1952 u=
secs
[   17.217868] calling  pnp_init+0x0/0x12 @ 1
[   17.231652] initcall pnp_init+0x0/0x12 returned 0 after 976 usecs
[   17.251902] calling  xen_setup_shutdown_event+0x0/0x22 @ 1
[   17.270209] initcall xen_setup_shutdown_event+0x0/0x22 returned 0
after 0 usecs
[   17.294515] calling  xenbus_probe_backend_init+0x0/0x2d @ 1
[   17.313159] initcall xenbus_probe_backend_init+0x0/0x2d returned 0
after 976 usecs
[   17.338271] calling  xenbus_probe_frontend_init+0x0/0x2d @ 1
[   17.357196] initcall xenbus_probe_frontend_init+0x0/0x2d returned 0
after 976 usecs
[   17.382600] calling  balloon_init+0x0/0x279 @ 1
[   17.397757] xen_balloon: Initialising balloon driver with page order 0.
[   17.419876] last_pfn =3D 0x47d8e9 max_arch_pfn =3D 0x400000000
[   17.484316] initcall balloon_init+0x0/0x279 returned 0 after 41985 usecs
[   17.506067] calling  xen_acpi_processor_extcntl_init+0x0/0x4f @ 1
[   17.526369] initcall xen_acpi_processor_extcntl_init+0x0/0x4f
returned 0 after 0 usecs
[   17.552683] calling  misc_init+0x0/0xb7 @ 1
[   17.566811] initcall misc_init+0x0/0xb7 returned 0 after 976 usecs
[   17.587284] calling  vga_arb_device_init+0x0/0x80 @ 1
[   17.604246] vgaarb: device added:
PCI:0000:04:00.0,decodes=3Dio+mem,owns=3Dio+mem,locks=3Dnone
[   17.631044] vgaarb: loaded
[   17.640197] initcall vga_arb_device_init+0x0/0x80 returned 0 after 976 u=
secs
[   17.663645] calling  cn_init+0x0/0x9e @ 1
[   17.677103] initcall cn_init+0x0/0x9e returned 0 after 976 usecs
[   17.697134] calling  init_scsi+0x0/0x8c @ 1
[   17.711359] SCSI subsystem initialized
[   17.723736] initcall init_scsi+0x0/0x8c returned 0 after 976 usecs
[   17.744322] calling  ata_init+0x0/0x351 @ 1
[   17.758476] libata version 3.00 loaded.
[   17.771209] initcall ata_init+0x0/0x351 returned 0 after 976 usecs
[   17.791796] calling  phy_init+0x0/0x2e @ 1
[   17.805682] initcall phy_init+0x0/0x2e returned 0 after 976 usecs
[   17.825831] calling  init_pcmcia_cs+0x0/0x36 @ 1
[   17.841321] initcall init_pcmcia_cs+0x0/0x36 returned 0 after 976 usecs
[   17.863299] calling  usb_init+0x0/0x1a9 @ 1
[   17.877459] usbcore: registered new interface driver usbfs
[   17.895670] usbcore: registered new interface driver hub
[   17.913426] usbcore: registered new device driver usb
[   17.930222] initcall usb_init+0x0/0x1a9 returned 0 after 2929 usecs
[   17.951094] calling  serio_init+0x0/0x86 @ 1
[   17.965470] initcall serio_init+0x0/0x86 returned 0 after 976 usecs
[   17.986271] calling  input_init+0x0/0x13c @ 1
[   18.000910] initcall input_init+0x0/0x13c returned 0 after 976 usecs
[   18.022019] calling  rtc_init+0x0/0x71 @ 1
[   18.035799] initcall rtc_init+0x0/0x71 returned 0 after 976 usecs
[   18.056053] calling  power_supply_class_init+0x0/0x38 @ 1
[   18.074122] initcall power_supply_class_init+0x0/0x38 returned 0
after 976 usecs
[   18.098665] calling  hwmon_init+0x0/0x106 @ 1
[   18.113300] initcall hwmon_init+0x0/0x106 returned 0 after 976 usecs
[   18.134415] calling  thermal_init+0x0/0x3f @ 1
[   18.149333] initcall thermal_init+0x0/0x3f returned 0 after 976 usecs
[   18.170740] calling  md_init+0x0/0xd0 @ 1
[   18.184189] initcall md_init+0x0/0xd0 returned 0 after 0 usecs
[   18.203625] calling  leds_init+0x0/0x40 @ 1
[   18.217690] initcall leds_init+0x0/0x40 returned 0 after 976 usecs
[   18.238230] calling  pci_subsys_init+0x0/0x107 @ 1
[   18.254244] PCI: Using ACPI for IRQ routing
[   18.268366] initcall pci_subsys_init+0x0/0x107 returned 0 after 0 usecs
[   18.290284] calling  proto_init+0x0/0x12 @ 1
[   18.304581] initcall proto_init+0x0/0x12 returned 0 after 0 usecs
[   18.324885] calling  net_dev_init+0x0/0x175 @ 1
[   18.340189] initcall net_dev_init+0x0/0x175 returned 0 after 976 usecs
[   18.361781] calling  neigh_init+0x0/0x71 @ 1
[   18.376078] initcall neigh_init+0x0/0x71 returned 0 after 0 usecs
[   18.396383] calling  fib_rules_init+0x0/0xa6 @ 1
[   18.411828] initcall fib_rules_init+0x0/0xa6 returned 0 after 0 usecs
[   18.433281] calling  pktsched_init+0x0/0xd0 @ 1
[   18.448435] initcall pktsched_init+0x0/0xd0 returned 0 after 0 usecs
[   18.469597] calling  tc_filter_init+0x0/0x4c @ 1
[   18.485041] initcall tc_filter_init+0x0/0x4c returned 0 after 0 usecs
[   18.506494] calling  tc_action_init+0x0/0x4c @ 1
[   18.521934] initcall tc_action_init+0x0/0x4c returned 0 after 0 usecs
[   18.543388] calling  genl_init+0x0/0x8f @ 1
[   18.557415] initcall genl_init+0x0/0x8f returned 0 after 976 usecs
[   18.577989] calling  cipso_v4_init+0x0/0x61 @ 1
[   18.593148] initcall cipso_v4_init+0x0/0x61 returned 0 after 0 usecs
[   18.614308] calling  wireless_nlevent_init+0x0/0x12 @ 1
[   18.631759] initcall wireless_nlevent_init+0x0/0x12 returned 0 after 0 u=
secs
[   18.655205] calling  cfg80211_init+0x0/0x92 @ 1
[   18.670486] cfg80211: Using static regulatory domain info
[   18.688383] cfg80211: Regulatory domain: US
[   18.702426] 	(start_freq - end_freq @ bandwidth),
(max_antenna_gain, max_eirp)
[   18.726447] 	(2402000 KHz - 2472000 KHz @ 40000 KHz), (600 mBi, 2700 mBm)
[   18.749043] 	(5170000 KHz - 5190000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
[   18.771637] 	(5190000 KHz - 5210000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
[   18.794230] 	(5210000 KHz - 5230000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
[   18.816824] 	(5230000 KHz - 5330000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
[   18.839417] 	(5735000 KHz - 5835000 KHz @ 40000 KHz), (600 mBi, 3000 mBm)
[   18.862022] cfg80211: Calling CRDA for country: US
[   18.878072] initcall cfg80211_init+0x0/0x92 returned 0 after 2929 usecs
[   18.900048] calling  ieee80211_init+0x0/0xb @ 1
[   18.915202] initcall ieee80211_init+0x0/0xb returned 0 after 0 usecs
[   18.936364] calling  netlbl_init+0x0/0x81 @ 1
[   18.950948] NetLabel: Initializing
[   18.962389] NetLabel:  domain hash size =3D 128
[   18.976975] NetLabel:  protocols =3D UNLABELED CIPSOv4
[   18.993570] NetLabel:  unlabeled traffic allowed by default
[   19.012157] initcall netlbl_init+0x0/0x81 returned 0 after 0 usecs
[   19.032744] calling  rfkill_init+0x0/0x79 @ 1
[   19.047431] initcall rfkill_init+0x0/0x79 returned 0 after 976 usecs
[   19.068492] calling  sysctl_init+0x0/0x48 @ 1
[   19.083079] initcall sysctl_init+0x0/0x48 returned 0 after 0 usecs
[   19.103670] calling  xen_mc_debugfs+0x0/0x118 @ 1
[   19.119420] initcall xen_mc_debugfs+0x0/0x118 returned 0 after 976 usecs
[   19.141710] calling  xen_mmu_debugfs+0x0/0x2be @ 1
[   19.157760] initcall xen_mmu_debugfs+0x0/0x2be returned 0 after 976 usecs
[   19.180320] calling  print_all_ICs+0x0/0x51b @ 1
[   19.195771] initcall print_all_ICs+0x0/0x51b returned 0 after 976 usecs
[   19.217785] calling  hpet_late_init+0x0/0xec @ 1
[   19.233224] initcall hpet_late_init+0x0/0xec returned -19 after 0 usecs
[   19.255249] calling  init_k8_nbs+0x0/0x28 @ 1
[   19.269840] initcall init_k8_nbs+0x0/0x28 returned 0 after 0 usecs
[   19.290423] calling  clocksource_done_booting+0x0/0x5a @ 1
[   19.308730] Switching to clocksource xen
[   19.322088] initcall clocksource_done_booting+0x0/0x5a returned 0
after 1046 usecs
[   19.347049] calling  rb_init_debugfs+0x0/0x2f @ 1
[   19.362805] initcall rb_init_debugfs+0x0/0x2f returned 0 after 26 usecs
[   19.384800] calling  tracer_init_debugfs+0x0/0x2d2 @ 1
[   19.402038] initcall tracer_init_debugfs+0x0/0x2d2 returned 0 after 76 u=
secs
[   19.425410] calling  init_trace_printk_function_export+0x0/0x2f @ 1
[   19.446291] initcall init_trace_printk_function_export+0x0/0x2f
returned 0 after 1 usecs
[   19.473171] calling  event_trace_init+0x0/0x1f7 @ 1
[   19.491236] initcall event_trace_init+0x0/0x1f7 returned 0 after 1721 us=
ecs
[   19.513843] calling  init_pipe_fs+0x0/0x4c @ 1
[   19.528731] initcall init_pipe_fs+0x0/0x4c returned 0 after 19 usecs
[   19.549877] calling  eventpoll_init+0x0/0xd9 @ 1
[   19.565321] initcall eventpoll_init+0x0/0xd9 returned 0 after 2 usecs
[   19.586769] calling  anon_inode_init+0x0/0x125 @ 1
[   19.602797] initcall anon_inode_init+0x0/0x125 returned 0 after 13 usecs
[   19.625094] calling  blk_scsi_ioctl_init+0x0/0x289 @ 1
[   19.642252] initcall blk_scsi_ioctl_init+0x0/0x289 returned 0 after 0 us=
ecs
[   19.665417] calling  acpi_event_init+0x0/0x81 @ 1
[   19.681160] initcall acpi_event_init+0x0/0x81 returned 0 after 13 usecs
[   19.703196] calling  pnpacpi_init+0x0/0x8c @ 1
[   19.718066] pnp: PnP ACPI init
[   19.728375] ACPI: bus type pnp registered
[   19.743206] xen: registering gsi 8 triggering 1 polarity 0
[   19.760946] xen_allocate_pirq: returning irq 8 for gsi 8
[   19.778678] xen: --> irq=3D8
[   19.787951] xen: registering gsi 13 triggering 1 polarity 0
[   19.806420] xen_allocate_pirq: returning irq 13 for gsi 13
[   19.824721] xen: --> irq=3D13
[   19.835027] xen: registering gsi 4 triggering 1 polarity 0
[   19.852768] xen_allocate_pirq: returning irq 4 for gsi 4
[   19.870501] xen: --> irq=3D4
[   19.879663] Already setup the GSI :4
[   19.892142] xen: registering gsi 3 triggering 1 polarity 0
[   19.909968] xen_allocate_pirq: returning irq 3 for gsi 3
[   19.927699] xen: --> irq=3D3
[   19.937319] pnp: PnP ACPI: found 11 devices
[   19.950864] ACPI: ACPI bus type pnp unregistered
[   19.966310] initcall pnpacpi_init+0x0/0x8c returned 0 after 242423 usecs
[   19.988615] calling  pnp_system_init+0x0/0x12 @ 1
[   20.004353] system 00:07: ioport range 0x500-0x57f has been reserved
[   20.025508] system 00:07: ioport range 0x600-0x61f has been reserved
[   20.046672] system 00:07: ioport range 0x880-0x883 has been reserved
[   20.067836] system 00:07: ioport range 0xca4-0xca5 has been reserved
[   20.088999] system 00:07: ioport range 0x400-0x47f has been reserved
[   20.110162] system 00:07: ioport range 0x800-0x81f has been reserved
[   20.131327] system 00:07: ioport range 0xca2-0xca3 has been reserved
[   20.152489] system 00:07: iomem range 0xfed1c000-0xfed3fffe could
not be reserved
[   20.177370] system 00:07: iomem range 0xff000000-0xffffffff could
not be reserved
[   20.202252] system 00:07: iomem range 0xfee00000-0xfeefffff could
not be reserved
[   20.227134] system 00:07: iomem range 0xfe900000-0xfe90001f has been res=
erved
[   20.250869] system 00:07: iomem range 0xfea00000-0xfea0001f has been res=
erved
[   20.274607] system 00:07: iomem range 0xfed1b000-0xfed1bfff has been res=
erved
[   20.298344] system 00:07: iomem range 0xfed14000-0xfed17ffe has been res=
erved
[   20.322081] system 00:07: iomem range 0xfed18000-0xfed18ffe has been res=
erved
[   20.345819] system 00:07: iomem range 0xfed19000-0xfed19ffe has been res=
erved
[   20.369608] initcall pnp_system_init+0x0/0x12 returned 0 after 356699 us=
ecs
[   20.392722] calling  pcistub_init+0x0/0x1d7 @ 1
[   20.408017] initcall pcistub_init+0x0/0x1d7 returned 0 after 133 usecs
[   20.429615] calling  chr_dev_init+0x0/0xc3 @ 1
[   20.445116] initcall chr_dev_init+0x0/0xc3 returned 0 after 613 usecs
[   20.466003] calling  firmware_class_init+0x0/0x79 @ 1
[   20.482929] initcall firmware_class_init+0x0/0x79 returned 0 after 51 us=
ecs
[   20.506042] calling  init_pcmcia_bus+0x0/0x74 @ 1
[   20.521832] initcall init_pcmcia_bus+0x0/0x74 returned 0 after 59 usecs
[   20.543793] calling  cpufreq_gov_performance_init+0x0/0x12 @ 1
[   20.563241] initcall cpufreq_gov_performance_init+0x0/0x12 returned
0 after 0 usecs
[   20.588694] calling  cpufreq_gov_userspace_init+0x0/0x12 @ 1
[   20.607569] initcall cpufreq_gov_userspace_init+0x0/0x12 returned 0
after 0 usecs
[   20.632449] calling  init_acpi_pm_clocksource+0x0/0xf6 @ 1
[   20.654920] PM-Timer failed consistency check  (0x0xffffff) - aborting.
[   20.676380] initcall init_acpi_pm_clocksource+0x0/0xf6 returned -19
after 25024 usecs
[   20.702436] calling  pcibios_assign_resources+0x0/0x74 @ 1
[   20.720745] pci 0000:01:00.0: BAR 6: no parent found for of device
[0xfffe0000-0xffffffff]
[   20.748192] pci 0000:04:00.0: BAR 6: no parent found for of device
[0xffff0000-0xffffffff]
[   20.775715] pci 0000:00:05.0: PCI bridge, secondary bus 0000:01
[   20.795382] pci 0000:00:05.0:   IO window: 0x2000-0x2fff
[   20.813115] pci 0000:00:05.0:   MEM window: 0xb3a00000-0xb3afffff
[   20.833420] pci 0000:00:05.0:   PREFETCH window:
0x000000b0000000-0x000000b1ffffff
[   20.858590] pci 0000:00:1c.0: PCI bridge, secondary bus 0000:02
[   20.878316] pci 0000:00:1c.0:   IO window: disabled
[   20.894624] pci 0000:00:1c.0:   MEM window: disabled
[   20.911209] pci 0000:00:1c.0:   PREFETCH window: disabled
[   20.929230] pci 0000:00:1c.4: PCI bridge, secondary bus 0000:03
[   20.948958] pci 0000:00:1c.4:   IO window: 0x1000-0x1fff
[   20.966693] pci 0000:00:1c.4:   MEM window: 0xb3900000-0xb39fffff
[   20.986997] pci 0000:00:1c.4:   PREFETCH window: disabled
[   21.005020] pci 0000:00:1c.6: PCI bridge, secondary bus 0000:04
[   21.024745] pci 0000:00:1c.6:   IO window: disabled
[   21.041051] pci 0000:00:1c.6:   MEM window: 0xb3000000-0xb38fffff
[   21.061355] pci 0000:00:1c.6:   PREFETCH window:
0x000000b2000000-0x000000b2ffffff
[   21.086525] pci 0000:00:1c.7: PCI bridge, secondary bus 0000:05
[   21.106253] pci 0000:00:1c.7:   IO window: disabled
[   21.122559] pci 0000:00:1c.7:   MEM window: disabled
[   21.139145] pci 0000:00:1c.7:   PREFETCH window: disabled
[   21.157166] pci 0000:00:1e.0: PCI bridge, secondary bus 0000:06
[   21.176893] pci 0000:00:1e.0:   IO window: disabled
[   21.193200] pci 0000:00:1e.0:   MEM window: disabled
[   21.209785] pci 0000:00:1e.0:   PREFETCH window: disabled
[   21.227816] xen: registering gsi 16 triggering 0 polarity 1
[   21.246394]   alloc irq_desc for 16 on node 0
[   21.260974]   alloc kstat_irqs on node 0
[   21.274144] xen: --> irq=3D16
[   21.283576] pci 0000:00:05.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
[   21.305878] pci 0000:00:05.0: setting latency timer to 64
[   21.323904] xen: registering gsi 16 triggering 0 polarity 1
[   21.342482] xen_allocate_pirq: returning irq 16 for gsi 16
[   21.360785] xen: --> irq=3D16
[   21.370228] Already setup the GSI :16
[   21.382521] pci 0000:00:1c.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
[   21.404832] pci 0000:00:1c.0: setting latency timer to 64
[   21.422854] xen: registering gsi 16 triggering 0 polarity 1
[   21.441435] xen_allocate_pirq: returning irq 16 for gsi 16
[   21.459738] xen: --> irq=3D16
[   21.469180] Already setup the GSI :16
[   21.481475] pci 0000:00:1c.4: PCI INT B -> GSI 16 (level, low) -> IRQ 16
[   21.503785] pci 0000:00:1c.4: setting latency timer to 64
[   21.521807] xen: registering gsi 18 triggering 0 polarity 1
[   21.540390]   alloc irq_desc for 18 on node 0
[   21.554973]   alloc kstat_irqs on node 0
[   21.568136] xen: --> irq=3D18
[   21.577575] pci 0000:00:1c.6: PCI INT C -> GSI 18 (level, low) -> IRQ 18
[   21.599877] pci 0000:00:1c.6: setting latency timer to 64
[   21.617902] xen: registering gsi 19 triggering 0 polarity 1
[   21.636483]   alloc irq_desc for 19 on node 0
[   21.651066]   alloc kstat_irqs on node 0
[   21.664228] xen: --> irq=3D19
[   21.673666] pci 0000:00:1c.7: PCI INT D -> GSI 19 (level, low) -> IRQ 19
[   21.695972] pci 0000:00:1c.7: setting latency timer to 64
[   21.714022] pci 0000:00:1e.0: setting latency timer to 64
[   21.732034] pci_bus 0000:00: resource 0 io:  [0x00-0xffff]
[   21.750337] pci_bus 0000:00: resource 1 mem: [0x000000-0xfffffffffffffff=
f]
[   21.773215] pci_bus 0000:01: resource 0 io:  [0x2000-0x2fff]
[   21.792090] pci_bus 0000:01: resource 1 mem: [0xb3a00000-0xb3afffff]
[   21.813253] pci_bus 0000:01: resource 2 pref mem [0xb0000000-0xb1ffffff]
[   21.835561] pci_bus 0000:03: resource 0 io:  [0x1000-0x1fff]
[   21.854437] pci_bus 0000:03: resource 1 mem: [0xb3900000-0xb39fffff]
[   21.875599] pci_bus 0000:04: resource 1 mem: [0xb3000000-0xb38fffff]
[   21.896765] pci_bus 0000:04: resource 2 pref mem [0xb2000000-0xb2ffffff]
[   21.919070] pci_bus 0000:06: resource 3 io:  [0x00-0xffff]
[   21.937375] pci_bus 0000:06: resource 4 mem: [0x000000-0xfffffffffffffff=
f]
[   21.960256] initcall pcibios_assign_resources+0x0/0x74 returned 0
after 1210466 usecs
[   21.986279] calling  sysctl_core_init+0x0/0x38 @ 1
[   22.002312] initcall sysctl_core_init+0x0/0x38 returned 0 after 15 usecs
[   22.024602] calling  inet_init+0x0/0x20a @ 1
[   22.038919] NET: Registered protocol family 2
[   22.053569] IP route cache hash table entries: 524288 (order: 10,
4194304 bytes)
[   22.078712] TCP established hash table entries: 262144 (order: 10,
4194304 bytes)
[   22.104272] TCP bind hash table entries: 65536 (order: 8, 1048576 bytes)
[   22.126325] TCP: Hash tables configured (established 262144 bind 65536)
[   22.148037] TCP reno registered
[   22.158685] initcall inet_init+0x0/0x20a returned 0 after 116972 usecs
[   22.180356] calling  af_unix_init+0x0/0x55 @ 1
[   22.195227] NET: Registered protocol family 1
[   22.209819] initcall af_unix_init+0x0/0x55 returned 0 after 14249 usecs
[   22.231834] calling  init_sunrpc+0x0/0x5d @ 1
[   22.246619] RPC: Registered udp transport module.
[   22.262149] RPC: Registered tcp transport module.
[   22.277878] RPC: Registered tcp NFSv4.1 backchannel transport module.
[   22.299330] initcall init_sunrpc+0x0/0x5d returned 0 after 51669 usecs
[   22.321065] calling  pci_apply_final_quirks+0x0/0x36 @ 1
[   22.339105] pci 0000:04:00.0: Boot video device
[   22.353954] initcall pci_apply_final_quirks+0x0/0x36 returned 0
after 14801 usecs
[   22.378835] calling  populate_rootfs+0x0/0xd7 @ 1
[   22.394616] Trying to unpack rootfs image as initramfs...
[   22.416540] Freeing initrd memory: 4911k freed
[   22.431447] initcall populate_rootfs+0x0/0xd7 returned 0 after 36015 use=
cs
[   22.453765] calling  pci_iommu_init+0x0/0x3a @ 1
[   22.469206] PCI-DMA: Using software bounce buffering for IO (SWIOTLB)
[   22.490657] DMA: Placing 64MB software IO TLB between
ffff880020000000 - ffff880024000000
[   22.517825] DMA: software IO TLB at phys 0x20000000 - 0x24000000
[   22.537847] initcall pci_iommu_init+0x0/0x3a returned 0 after 67031 usecs
[   22.560438] calling  irqfd_module_init+0x0/0x31 @ 1
[   22.576804] initcall irqfd_module_init+0x0/0x31 returned 0 after 61 usecs
[   22.599334] calling  vmx_init+0x0/0x1ff @ 1
[   22.613359] kvm: no hardware support
[   22.625362] initcall vmx_init+0x0/0x1ff returned -95 after 11733 usecs
[   22.647094] initcall vmx_init+0x0/0x1ff returned with error code -95
[   22.668544] calling  svm_init+0x0/0x19 @ 1
[   22.682272] has_svm: not amd
[   22.691993] kvm: no hardware support
[   22.704007] initcall svm_init+0x0/0x19 returned -95 after 21225 usecs
[   22.725485] initcall svm_init+0x0/0x19 returned with error code -95
[   22.746649] calling  i8259A_init_sysfs+0x0/0x22 @ 1
[   22.763076] initcall i8259A_init_sysfs+0x0/0x22 returned 0 after 123 use=
cs
[   22.785830] calling  vsyscall_init+0x0/0x6c @ 1
[   22.801087] initcall vsyscall_init+0x0/0x6c returned 0 after 97 usecs
[   22.822436] calling  sbf_init+0x0/0xe9 @ 1
[   22.836165] initcall sbf_init+0x0/0xe9 returned 0 after 0 usecs
[   22.855897] calling  i8237A_init_sysfs+0x0/0x22 @ 1
[   22.872306] initcall i8237A_init_sysfs+0x0/0x22 returned 0 after 103 use=
cs
[   22.895078] calling  add_rtc_cmos+0x0/0xa9 @ 1
[   22.909952] initcall add_rtc_cmos+0x0/0xa9 returned 0 after 2 usecs
[   22.930829] calling  cache_sysfs_init+0x0/0x64 @ 1
[   22.947960] initcall cache_sysfs_init+0x0/0x64 returned 0 after 1089 use=
cs
[   22.970278] calling  mce_init_device+0x0/0xff @ 1
[   22.986385] initcall mce_init_device+0x0/0xff returned 0 after 366 usecs
[   23.008315] calling  msr_init+0x0/0x14a @ 1
[   23.022628] initcall msr_init+0x0/0x14a returned 0 after 291 usecs
[   23.042919] calling  cpuid_init+0x0/0x14a @ 1
[   23.057793] initcall cpuid_init+0x0/0x14a returned 0 after 279 usecs
[   23.078668] calling  ioapic_init_sysfs+0x0/0xb3 @ 1
[   23.095073] initcall ioapic_init_sysfs+0x0/0xb3 returned 0 after 101 use=
cs
[   23.117850] calling  add_pcspkr+0x0/0x28 @ 1
[   23.132208] initcall add_pcspkr+0x0/0x28 returned 0 after 57 usecs
[   23.152741] calling  microcode_init+0x0/0x132 @ 1
[   23.168613] Microcode Update Driver: v2.00
<tigran@aivazian.fsnet.co.uk>, Peter Oruba
[   23.194495] initcall microcode_init+0x0/0x132 returned 0 after 25414 use=
cs
[   23.217378] calling  start_periodic_check_for_corruption+0x0/0x37 @ 1
[   23.238822] Scanning for low memory corruption every 60 seconds
[   23.258559] initcall start_periodic_check_for_corruption+0x0/0x37
returned 0 after 19272 usecs
[   23.287156] calling  audit_classes_init+0x0/0xaf @ 1
[   23.303769] initcall audit_classes_init+0x0/0xaf returned 0 after 20 use=
cs
[   23.326628] calling  init_vdso_vars+0x0/0x241 @ 1
[   23.342370] initcall init_vdso_vars+0x0/0x241 returned 0 after 15 usecs
[   23.364378] calling  ia32_binfmt_init+0x0/0x14 @ 1
[   23.380395] initcall ia32_binfmt_init+0x0/0x14 returned 0 after 4 usecs
[   23.402416] calling  sysenter_setup+0x0/0x2f1 @ 1
[   23.418143] initcall sysenter_setup+0x0/0x2f1 returned 0 after 1 usecs
[   23.439880] calling  proc_schedstat_init+0x0/0x22 @ 1
[   23.456757] initcall proc_schedstat_init+0x0/0x22 returned 0 after 3 use=
cs
[   23.479634] calling  proc_execdomains_init+0x0/0x22 @ 1
[   23.497080] initcall proc_execdomains_init+0x0/0x22 returned 0 after 1 u=
secs
[   23.520526] calling  ioresources_init+0x0/0x3c @ 1
[   23.536544] initcall ioresources_init+0x0/0x3c returned 0 after 1 usecs
[   23.558566] calling  uid_cache_init+0x0/0x9b @ 1
[   23.574020] initcall uid_cache_init+0x0/0x9b returned 0 after 12 usecs
[   23.595746] calling  init_posix_timers+0x0/0x17a @ 1
[   23.612331] initcall init_posix_timers+0x0/0x17a returned 0 after 1 usecs
[   23.634927] calling  init_posix_cpu_timers+0x0/0xe5 @ 1
[   23.652373] initcall init_posix_cpu_timers+0x0/0xe5 returned 0 after 0 u=
secs
[   23.675819] calling  nsproxy_cache_init+0x0/0x2d @ 1
[   23.692409] initcall nsproxy_cache_init+0x0/0x2d returned 0 after 0 usecs
[   23.715035] calling  create_proc_profile+0x0/0x283 @ 1
[   23.732194] initcall create_proc_profile+0x0/0x283 returned 0 after 0 us=
ecs
[   23.755359] calling  timekeeping_init_device+0x0/0x22 @ 1
[   23.773480] initcall timekeeping_init_device+0x0/0x22 returned 0
after 101 usecs
[   23.797967] calling  init_clocksource_sysfs+0x0/0x50 @ 1
[   23.815801] initcall init_clocksource_sysfs+0x0/0x50 returned 0
after 95 usecs
[   23.839721] calling  init_timer_list_procfs+0x0/0x2c @ 1
[   23.857460] initcall init_timer_list_procfs+0x0/0x2c returned 0 after 1 =
usecs
[   23.881191] calling  init_tstats_procfs+0x0/0x2c @ 1
[   23.897779] initcall init_tstats_procfs+0x0/0x2c returned 0 after 0 usecs
[   23.920376] calling  futex_init+0x0/0x68 @ 1
[   23.934684] initcall futex_init+0x0/0x68 returned 0 after 12 usecs
[   23.955262] calling  proc_dma_init+0x0/0x22 @ 1
[   23.970422] initcall proc_dma_init+0x0/0x22 returned 0 after 1 usecs
[   23.991583] calling  proc_modules_init+0x0/0x22 @ 1
[   24.007887] initcall proc_modules_init+0x0/0x22 returned 0 after 0 usecs
[   24.030197] calling  kallsyms_init+0x0/0x25 @ 1
[   24.045351] initcall kallsyms_init+0x0/0x25 returned 0 after 0 usecs
[   24.066514] calling  snapshot_device_init+0x0/0x12 @ 1
[   24.083738] initcall snapshot_device_init+0x0/0x12 returned 0 after 57 u=
secs
[   24.107125] calling  crash_save_vmcoreinfo_init+0x0/0x4a5 @ 1
[   24.126305] initcall crash_save_vmcoreinfo_init+0x0/0x4a5 returned
0 after 19 usecs
[   24.151739] calling  crash_notes_memory_init+0x0/0x37 @ 1
[   24.169762] initcall crash_notes_memory_init+0x0/0x37 returned 0
after 1 usecs
[   24.193780] calling  pid_namespaces_init+0x0/0x2d @ 1
[   24.210660] initcall pid_namespaces_init+0x0/0x2d returned 0 after 2 use=
cs
[   24.233536] calling  audit_init+0x0/0x133 @ 1
[   24.248118] audit: initializing netlink socket (disabled)
[   24.266155] type=3D2000 audit(1323880410.207:1): initialized
[   24.284444] initcall audit_init+0x0/0x133 returned 0 after 35472 usecs
[   24.306178] calling  audit_tree_init+0x0/0x49 @ 1
[   24.321904] initcall audit_tree_init+0x0/0x49 returned 0 after 0 usecs
[   24.343644] calling  init_kprobes+0x0/0x148 @ 1
[   24.372692] initcall init_kprobes+0x0/0x148 returned 0 after 13569 usecs
[   24.394441] calling  utsname_sysctl_init+0x0/0x14 @ 1
[   24.411326] initcall utsname_sysctl_init+0x0/0x14 returned 0 after 11 us=
ecs
[   24.434480] calling  init_tracepoints+0x0/0x12 @ 1
[   24.450491] initcall init_tracepoints+0x0/0x12 returned 0 after 0 usecs
[   24.472516] calling  init_events+0x0/0x64 @ 1
[   24.487100] initcall init_events+0x0/0x64 returned 0 after 1 usecs
[   24.507690] calling  init_sched_switch_trace+0x0/0x12 @ 1
[   24.525712] initcall init_sched_switch_trace+0x0/0x12 returned 0
after 0 usecs
[   24.549730] calling  init_blk_tracer+0x0/0x55 @ 1
[   24.565461] initcall init_blk_tracer+0x0/0x55 returned 0 after 0 usecs
[   24.587199] calling  perf_event_sysfs_init+0x0/0x19 @ 1
[   24.604650] initcall perf_event_sysfs_init+0x0/0x19 returned 0 after 3 u=
secs
[   24.628091] calling  init_per_zone_wmark_min+0x0/0x67 @ 1
[   24.646545] initcall init_per_zone_wmark_min+0x0/0x67 returned 0
after 420 usecs
[   24.670705] calling  kswapd_init+0x0/0x20 @ 1
[   24.685337] initcall kswapd_init+0x0/0x20 returned 0 after 43 usecs
[   24.706168] calling  setup_vmstat+0x0/0xc5 @ 1
[   24.721077] initcall setup_vmstat+0x0/0xc5 returned 0 after 8 usecs
[   24.741946] calling  mm_sysfs_init+0x0/0x29 @ 1
[   24.757106] initcall mm_sysfs_init+0x0/0x29 returned 0 after 3 usecs
[   24.778268] calling  proc_vmalloc_init+0x0/0x25 @ 1
[   24.794569] initcall proc_vmalloc_init+0x0/0x25 returned 0 after 1 usecs
[   24.816880] calling  procswaps_init+0x0/0x22 @ 1
[   24.832321] initcall procswaps_init+0x0/0x22 returned 0 after 0 usecs
[   24.853772] calling  hugetlb_init+0x0/0x3c8 @ 1
[   24.868926] HugeTLB registered 2 MB page size, pre-allocated 0 pages
[   24.890096] initcall hugetlb_init+0x0/0x3c8 returned 0 after 20674 usecs
[   24.912401] calling  slab_proc_init+0x0/0x25 @ 1
[   24.927842] initcall slab_proc_init+0x0/0x25 returned 0 after 1 usecs
[   24.949293] calling  slab_sysfs_init+0x0/0xee @ 1
[   24.968295] initcall slab_sysfs_init+0x0/0xee returned 0 after 3197 usecs
[   24.990331] calling  fasync_init+0x0/0x2a @ 1
[   25.004915] initcall fasync_init+0x0/0x2a returned 0 after 3 usecs
[   25.025504] calling  proc_filesystems_init+0x0/0x22 @ 1
[   25.042956] initcall proc_filesystems_init+0x0/0x22 returned 0 after 2 u=
secs
[   25.066399] calling  dnotify_init+0x0/0x80 @ 1
[   25.081278] initcall dnotify_init+0x0/0x80 returned 0 after 6 usecs
[   25.102150] calling  inotify_setup+0x0/0x12 @ 1
[   25.117306] initcall inotify_setup+0x0/0x12 returned 0 after 0 usecs
[   25.138470] calling  inotify_user_setup+0x0/0xbe @ 1
[   25.155074] initcall inotify_user_setup+0x0/0xbe returned 0 after 15 use=
cs
[   25.177942] calling  aio_setup+0x0/0x71 @ 1
[   25.192070] initcall aio_setup+0x0/0x71 returned 0 after 110 usecs
[   25.212541] calling  proc_locks_init+0x0/0x22 @ 1
[   25.228274] initcall proc_locks_init+0x0/0x22 returned 0 after 2 usecs
[   25.250010] calling  init_sys32_ioctl+0x0/0x83 @ 1
[   25.266036] initcall init_sys32_ioctl+0x0/0x83 returned 0 after 12 usecs
[   25.288334] calling  init_mbcache+0x0/0x14 @ 1
[   25.303203] initcall init_mbcache+0x0/0x14 returned 0 after 0 usecs
[   25.324079] calling  dquot_init+0x0/0xf9 @ 1
[   25.338377] VFS: Disk quotas dquot_6.5.2
[   25.351639] Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
[   25.372992] initcall dquot_init+0x0/0xf9 returned 0 after 33801 usecs
[   25.394438] calling  init_v2_quota_format+0x0/0x12 @ 1
[   25.411597] initcall init_v2_quota_format+0x0/0x12 returned 0 after 0 us=
ecs
[   25.434762] calling  proc_cmdline_init+0x0/0x22 @ 1
[   25.451061] initcall proc_cmdline_init+0x0/0x22 returned 0 after 1 usecs
[   25.473371] calling  proc_cpuinfo_init+0x0/0x22 @ 1
[   25.489668] initcall proc_cpuinfo_init+0x0/0x22 returned 0 after 0 usecs
[   25.511979] calling  proc_devices_init+0x0/0x22 @ 1
[   25.528279] initcall proc_devices_init+0x0/0x22 returned 0 after 1 usecs
[   25.550588] calling  proc_interrupts_init+0x0/0x22 @ 1
[   25.567748] initcall proc_interrupts_init+0x0/0x22 returned 0 after 0 us=
ecs
[   25.590914] calling  proc_loadavg_init+0x0/0x22 @ 1
[   25.607212] initcall proc_loadavg_init+0x0/0x22 returned 0 after 0 usecs
[   25.629523] calling  proc_meminfo_init+0x0/0x22 @ 1
[   25.645820] initcall proc_meminfo_init+0x0/0x22 returned 0 after 0 usecs
[   25.668132] calling  proc_stat_init+0x0/0x22 @ 1
[   25.683571] initcall proc_stat_init+0x0/0x22 returned 0 after 0 usecs
[   25.705025] calling  proc_uptime_init+0x0/0x22 @ 1
[   25.721065] initcall proc_uptime_init+0x0/0x22 returned 0 after 0 usecs
[   25.743091] calling  proc_version_init+0x0/0x22 @ 1
[   25.759388] initcall proc_version_init+0x0/0x22 returned 0 after 0 usecs
[   25.781699] calling  proc_softirqs_init+0x0/0x22 @ 1
[   25.798284] initcall proc_softirqs_init+0x0/0x22 returned 0 after 1 usecs
[   25.820879] calling  proc_kcore_init+0x0/0xa9 @ 1
[   25.836609] initcall proc_kcore_init+0x0/0xa9 returned 0 after 4 usecs
[   25.858344] calling  vmcore_init+0x0/0x333 @ 1
[   25.873213] initcall vmcore_init+0x0/0x333 returned 0 after 0 usecs
[   25.894090] calling  proc_kmsg_init+0x0/0x25 @ 1
[   25.909534] initcall proc_kmsg_init+0x0/0x25 returned 0 after 0 usecs
[   25.930986] calling  proc_page_init+0x0/0x42 @ 1
[   25.946428] initcall proc_page_init+0x0/0x42 returned 0 after 1 usecs
[   25.967880] calling  init_devpts_fs+0x0/0x4c @ 1
[   25.983326] initcall init_devpts_fs+0x0/0x4c returned 0 after 6 usecs
[   26.004772] calling  init_ext3_fs+0x0/0x71 @ 1
[   26.019806] initcall init_ext3_fs+0x0/0x71 returned 0 after 162 usecs
[   26.041095] calling  journal_init+0x0/0x99 @ 1
[   26.056248] initcall journal_init+0x0/0x99 returned 0 after 279 usecs
[   26.077414] calling  init_ramfs_fs+0x0/0x12 @ 1
[   26.092570] initcall init_ramfs_fs+0x0/0x12 returned 0 after 1 usecs
[   26.113731] calling  init_hugetlbfs_fs+0x0/0x98 @ 1
[   26.130114] initcall init_hugetlbfs_fs+0x0/0x98 returned 0 after 77 usecs
[   26.152631] calling  init_fat_fs+0x0/0x4f @ 1
[   26.167355] initcall init_fat_fs+0x0/0x4f returned 0 after 138 usecs
[   26.188376] calling  init_vfat_fs+0x0/0x12 @ 1
[   26.203248] initcall init_vfat_fs+0x0/0x12 returned 0 after 1 usecs
[   26.224124] calling  init_msdos_fs+0x0/0x12 @ 1
[   26.239282] initcall init_msdos_fs+0x0/0x12 returned 0 after 0 usecs
[   26.260446] calling  init_iso9660_fs+0x0/0x71 @ 1
[   26.276263] initcall init_iso9660_fs+0x0/0x71 returned 0 after 85 usecs
[   26.298200] calling  init_nfs_fs+0x0/0x148 @ 1
[   26.313328] initcall init_nfs_fs+0x0/0x148 returned 0 after 253 usecs
[   26.334521] calling  init_nlm+0x0/0x22 @ 1
[   26.348260] initcall init_nlm+0x0/0x22 returned 0 after 10 usecs
[   26.368263] calling  init_nls_cp437+0x0/0x12 @ 1
[   26.383708] initcall init_nls_cp437+0x0/0x12 returned 0 after 0 usecs
[   26.405160] calling  init_nls_ascii+0x0/0x12 @ 1
[   26.420601] initcall init_nls_ascii+0x0/0x12 returned 0 after 0 usecs
[   26.442053] calling  init_nls_iso8859_1+0x0/0x12 @ 1
[   26.458638] initcall init_nls_iso8859_1+0x0/0x12 returned 0 after 0 usecs
[   26.481234] calling  init_nls_utf8+0x0/0x29 @ 1
[   26.496390] initcall init_nls_utf8+0x0/0x29 returned 0 after 0 usecs
[   26.517550] calling  init_autofs4_fs+0x0/0x26 @ 1
[   26.533342] initcall init_autofs4_fs+0x0/0x26 returned 0 after 57 usecs
[   26.555306] calling  ipc_init+0x0/0x23 @ 1
[   26.569036] msgmni has been set to 3375
[   26.581906] initcall ipc_init+0x0/0x23 returned 0 after 12571 usecs
[   26.602777] calling  ipc_sysctl_init+0x0/0x14 @ 1
[   26.618527] initcall ipc_sysctl_init+0x0/0x14 returned 0 after 20 usecs
[   26.640532] calling  init_mqueue_fs+0x0/0xb4 @ 1
[   26.656077] initcall init_mqueue_fs+0x0/0xb4 returned 0 after 101 usecs
[   26.677997] calling  key_proc_init+0x0/0x59 @ 1
[   26.693154] initcall key_proc_init+0x0/0x59 returned 0 after 3 usecs
[   26.714346] calling  selinux_nf_ip_init+0x0/0x62 @ 1
[   26.730929] SELinux:  Registering netfilter hooks
[   26.746662] initcall selinux_nf_ip_init+0x0/0x62 returned 0 after 15363 =
usecs
[   26.770398] calling  init_sel_fs+0x0/0x68 @ 1
[   26.785061] initcall init_sel_fs+0x0/0x68 returned 0 after 75 usecs
[   26.805860] calling  selnl_init+0x0/0x4d @ 1
[   26.820171] initcall selnl_init+0x0/0x4d returned 0 after 9 usecs
[   26.840465] calling  sel_netif_init+0x0/0x66 @ 1
[   26.855912] initcall sel_netif_init+0x0/0x66 returned 0 after 2 usecs
[   26.877362] calling  sel_netnode_init+0x0/0x74 @ 1
[   26.893375] initcall sel_netnode_init+0x0/0x74 returned 0 after 0 usecs
[   26.915399] calling  sel_netport_init+0x0/0x74 @ 1
[   26.931412] initcall sel_netport_init+0x0/0x74 returned 0 after 0 usecs
[   26.953436] calling  aurule_init+0x0/0x37 @ 1
[   26.968019] initcall aurule_init+0x0/0x37 returned 0 after 0 usecs
[   26.988609] calling  crypto_wq_init+0x0/0x2e @ 1
[   27.004152] initcall crypto_wq_init+0x0/0x2e returned 0 after 95 usecs
[   27.025793] calling  crypto_algapi_init+0x0/0xd @ 1
[   27.042093] initcall crypto_algapi_init+0x0/0xd returned 0 after 2 usecs
[   27.064400] calling  skcipher_module_init+0x0/0x39 @ 1
[   27.081562] initcall skcipher_module_init+0x0/0x39 returned 0 after 0 us=
ecs
[   27.104725] calling  chainiv_module_init+0x0/0x12 @ 1
[   27.121600] initcall chainiv_module_init+0x0/0x12 returned 0 after 0 use=
cs
[   27.144479] calling  eseqiv_module_init+0x0/0x12 @ 1
[   27.161063] initcall eseqiv_module_init+0x0/0x12 returned 0 after 0 usecs
[   27.183658] calling  hmac_module_init+0x0/0x12 @ 1
[   27.199672] initcall hmac_module_init+0x0/0x12 returned 0 after 0 usecs
[   27.221697] calling  crypto_null_mod_init+0x0/0x7d @ 1
[   27.238894] alg: No test for cipher_null (cipher_null-generic)
[   27.258337] alg: No test for ecb(cipher_null) (ecb-cipher_null)
[   27.278068] alg: No test for digest_null (digest_null-generic)
[   27.297515] alg: No test for compress_null (compress_null-generic)
[   27.318083] initcall crypto_null_mod_init+0x0/0x7d returned 0 after
77368 usecs
[   27.342381] calling  md5_mod_init+0x0/0x12 @ 1
[   27.357314] initcall md5_mod_init+0x0/0x12 returned 0 after 57 usecs
[   27.378416] calling  sha1_generic_mod_init+0x0/0x12 @ 1
[   27.395917] initcall sha1_generic_mod_init+0x0/0x12 returned 0 after 49 =
usecs
[   27.419600] calling  crypto_ecb_module_init+0x0/0x12 @ 1
[   27.437334] initcall crypto_ecb_module_init+0x0/0x12 returned 0 after 0 =
usecs
[   27.461067] calling  crypto_cbc_module_init+0x0/0x12 @ 1
[   27.478803] initcall crypto_cbc_module_init+0x0/0x12 returned 0 after 0 =
usecs
[   27.502536] calling  des_generic_mod_init+0x0/0x3f @ 1
[   27.519818] initcall des_generic_mod_init+0x0/0x3f returned 0 after 114 =
usecs
[   27.543434] calling  aes_init+0x0/0x12 @ 1
[   27.557225] initcall aes_init+0x0/0x12 returned 0 after 58 usecs
[   27.577180] calling  arc4_init+0x0/0x12 @ 1
[   27.591274] initcall arc4_init+0x0/0x12 returned 0 after 73 usecs
[   27.611499] calling  deflate_mod_init+0x0/0x12 @ 1
[   27.627762] initcall deflate_mod_init+0x0/0x12 returned 0 after 239 usecs
[   27.650111] calling  zlib_mod_init+0x0/0x12 @ 1
[   27.665600] initcall zlib_mod_init+0x0/0x12 returned 0 after 326 usecs
[   27.687006] calling  crc32c_mod_init+0x0/0x12 @ 1
[   27.702798] initcall crc32c_mod_init+0x0/0x12 returned 0 after 65 usecs
[   27.724786] calling  crypto_authenc_module_init+0x0/0x12 @ 1
[   27.743657] initcall crypto_authenc_module_init+0x0/0x12 returned 0
after 0 usecs
[   27.768537] calling  lzo_mod_init+0x0/0x12 @ 1
[   27.783508] initcall lzo_mod_init+0x0/0x12 returned 0 after 94 usecs
[   27.804573] calling  krng_mod_init+0x0/0x12 @ 1
[   27.819767] alg: No test for stdrng (krng)
[   27.833468] initcall krng_mod_init+0x0/0x12 returned 0 after 13413 usecs
[   27.855769] calling  proc_genhd_init+0x0/0x3c @ 1
[   27.871498] initcall proc_genhd_init+0x0/0x3c returned 0 after 3 usecs
[   27.893234] calling  bsg_init+0x0/0x12e @ 1
[   27.907379] Block layer SCSI generic (bsg) driver version 0.4
loaded (major 252)
[   27.931840] initcall bsg_init+0x0/0x12e returned 0 after 24015 usecs
[   27.953003] calling  noop_init+0x0/0x14 @ 1
[   27.967019] io scheduler noop registered
[   27.980176] initcall noop_init+0x0/0x14 returned 0 after 12848 usecs
[   28.001335] calling  as_init+0x0/0x14 @ 1
[   28.014779] io scheduler anticipatory registered
[   28.030220] initcall as_init+0x0/0x14 returned 0 after 15078 usecs
[   28.050811] calling  deadline_init+0x0/0x14 @ 1
[   28.065968] io scheduler deadline registered
[   28.080270] initcall deadline_init+0x0/0x14 returned 0 after 13965 usecs
[   28.102580] calling  cfq_init+0x0/0x94 @ 1
[   28.116461] io scheduler cfq registered (default)
[   28.132033] initcall cfq_init+0x0/0x94 returned 0 after 15355 usecs
[   28.152911] calling  init_kmp+0x0/0x12 @ 1
[   28.166643] initcall init_kmp+0x0/0x12 returned 0 after 0 usecs
[   28.186372] calling  init_bm+0x0/0x12 @ 1
[   28.199818] initcall init_bm+0x0/0x12 returned 0 after 0 usecs
[   28.219260] calling  init_fsm+0x0/0x12 @ 1
[   28.232993] initcall init_fsm+0x0/0x12 returned 0 after 0 usecs
[   28.252721] calling  percpu_counter_startup+0x0/0x3c @ 1
[   28.270459] initcall percpu_counter_startup+0x0/0x3c returned 0 after 0 =
usecs
[   28.294190] calling  pci_proc_init+0x0/0x6a @ 1
[   28.309384] initcall pci_proc_init+0x0/0x6a returned 0 after 34 usecs
[   28.330801] calling  pcie_portdrv_init+0x0/0x4c @ 1
[   28.347261]   alloc irq_desc for 1257 on node -1
[   28.362542]   alloc kstat_irqs on node -1
[   28.376024] pcieport 0000:00:05.0: setting latency timer to 64
[   28.395693]   alloc irq_desc for 1256 on node -1
[   28.410874]   alloc kstat_irqs on node -1
[   28.424352] pcieport 0000:00:1c.0: setting latency timer to 64
[   28.443971]   alloc irq_desc for 1255 on node -1
[   28.459207]   alloc kstat_irqs on node -1
[   28.472684] pcieport 0000:00:1c.4: setting latency timer to 64
[   28.492303]   alloc irq_desc for 1254 on node -1
[   28.507540]   alloc kstat_irqs on node -1
[   28.521018] pcieport 0000:00:1c.6: setting latency timer to 64
[   28.540641]   alloc irq_desc for 1253 on node -1
[   28.555872]   alloc kstat_irqs on node -1
[   28.569350] pcieport 0000:00:1c.7: setting latency timer to 64
[   28.588957] initcall pcie_portdrv_init+0x0/0x4c returned 0 after 236188 =
usecs
[   28.612500] calling  aer_service_init+0x0/0x2b @ 1
[   28.628701] aer 0000:00:05.0:pcie02: service driver aer loaded
[   28.648018] initcall aer_service_init+0x0/0x2b returned 0 after 19045 us=
ecs
[   28.671131] calling  pci_hotplug_init+0x0/0x1d @ 1
[   28.687144] pci_hotplug: PCI Hot Plug PCI Core version: 0.5
[   28.705737] initcall pci_hotplug_init+0x0/0x1d returned 0 after 18156 us=
ecs
[   28.728932] calling  pcifront_init+0x0/0x4f @ 1
[   28.744144] initcall pcifront_init+0x0/0x4f returned 0 after 57 usecs
[   28.765538] calling  fb_console_init+0x0/0x11d @ 1
[   28.781610] initcall fb_console_init+0x0/0x11d returned 0 after 59 usecs
[   28.803861] calling  genericbl_init+0x0/0x12 @ 1
[   28.819353] initcall genericbl_init+0x0/0x12 returned 0 after 52 usecs
[   28.841040] calling  xenfb_init+0x0/0x5d @ 1
[   28.855335] initcall xenfb_init+0x0/0x5d returned -19 after 0 usecs
[   28.876213] calling  efifb_init+0x0/0x1f5 @ 1
[   28.890803] initcall efifb_init+0x0/0x1f5 returned -19 after 3 usecs
[   28.911963] calling  acpi_reserve_resources+0x0/0xeb @ 1
[   28.929699] initcall acpi_reserve_resources+0x0/0xeb returned 0 after 2 =
usecs
[   28.953430] calling  irqrouter_init_sysfs+0x0/0x38 @ 1
[   28.970696] initcall irqrouter_init_sysfs+0x0/0x38 returned 0 after 99 u=
secs
[   28.994042] calling  acpi_ac_init+0x0/0x45 @ 1
[   29.008989] initcall acpi_ac_init+0x0/0x45 returned 0 after 73 usecs
[   29.030077] calling  acpi_button_init+0x0/0x56 @ 1
[   29.046201] input: Sleep Button as
/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0E:00/input/input0
[   29.073842] ACPI: Sleep Button [SLPB]
[   29.086229] input: Power Button as
/devices/LNXSYSTM:00/LNXPWRBN:00/input/input1
[   29.110725] ACPI: Power Button [PWRF]
[   29.123098] initcall acpi_button_init+0x0/0x56 returned 0 after 75200 us=
ecs
[   29.146193] calling  acpi_fan_init+0x0/0x56 @ 1
[   29.161409] initcall acpi_fan_init+0x0/0x56 returned 0 after 60 usecs
[   29.182800] calling  acpi_video_init+0x0/0x76 @ 1
[   29.198598] initcall acpi_video_init+0x0/0x76 returned 0 after 70 usecs
[   29.220551] calling  acpi_processor_init+0x0/0x136 @ 1
[   29.241016] initcall acpi_processor_init+0x0/0x136 returned 0 after
3226 usecs
[   29.264479] calling  acpi_container_init+0x0/0x42 @ 1
[   29.283573] initcall acpi_container_init+0x0/0x42 returned 0 after 2163 =
usecs
[   29.306749] calling  acpi_thermal_init+0x0/0x7b @ 1
[   29.323119] initcall acpi_thermal_init+0x0/0x7b returned 0 after 66 usecs
[   29.345647] calling  acpi_battery_init+0x0/0x16 @ 1
[   29.361949] initcall acpi_battery_init+0x0/0x16 returned 0 after 2 usecs
[   29.361988] calling  1_acpi_battery_init_async+0x0/0x3c @ 683
[   29.362066] initcall 1_acpi_battery_init_async+0x0/0x3c returned 0
after 72 usecs
[   29.428296] calling  xenbus_probe_initcall+0x0/0x37 @ 1
[   29.445744] initcall xenbus_probe_initcall+0x0/0x37 returned 0 after 0 u=
secs
[   29.469193] calling  evtchn_init+0x0/0x6e @ 1
[   29.483853] Event-channel device installed.
[   29.497796] initcall evtchn_init+0x0/0x6e returned 0 after 13689 usecs
[   29.519531] calling  gntdev_init+0x0/0x3d @ 1
[   29.534179] initcall gntdev_init+0x0/0x3d returned 0 after 64 usecs
[   29.554990] calling  pciback_init+0x0/0x151 @ 1
[   29.570311] initcall pciback_init+0x0/0x151 returned 0 after 159 usecs
[   29.591887] calling  blkif_init+0x0/0x17b @ 1
[   29.608285] initcall blkif_init+0x0/0x17b returned 0 after 1772 usecs
[   29.629177] calling  blktap_init+0x0/0xf1 @ 1
[   29.643759] blktap_device_init: blktap device major 253
[   29.661208] blktap_ring_init: blktap ring major: 251
[   29.678142] initcall blktap_init+0x0/0xf1 returned 0 after 33576 usecs
[   29.699531] calling  netback_init+0x0/0x3d7 @ 1
[   29.717007] registering netback
[   29.727151] initcall netback_init+0x0/0x3d7 returned 0 after 12172 usecs
[   29.749365] calling  xenfs_init+0x0/0x6a @ 1
[   29.763673] initcall xenfs_init+0x0/0x6a returned 0 after 10 usecs
[   29.784255] calling  hypervisor_subsys_init+0x0/0x25 @ 1
[   29.801986] initcall hypervisor_subsys_init+0x0/0x25 returned 0 after 0 =
usecs
[   29.825724] calling  hyper_sysfs_init+0x0/0xfb @ 1
[   29.841747] initcall hyper_sysfs_init+0x0/0xfb returned 0 after 7 usecs
[   29.863763] calling  rand_initialize+0x0/0x2c @ 1
[   29.879498] initcall rand_initialize+0x0/0x2c returned 0 after 9 usecs
[   29.901226] calling  tty_init+0x0/0xf5 @ 1
[   29.919028] initcall tty_init+0x0/0xf5 returned 0 after 3978 usecs
[   29.939058] calling  pty_init+0x0/0x336 @ 1
[   29.953154] initcall pty_init+0x0/0x336 returned 0 after 78 usecs
[   29.973376] calling  sysrq_init+0x0/0x25 @ 1
[   29.987681] initcall sysrq_init+0x0/0x25 returned 0 after 5 usecs
[   30.007981] calling  xen_hvc_init+0x0/0xf0 @ 1
[   30.022853]   alloc irq_desc for 1252 on node -1
[   30.038296]   alloc kstat_irqs on node -1
[   30.052237] initcall xen_hvc_init+0x0/0xf0 returned 0 after 28695 usecs
[   30.073760] calling  hpet_init+0x0/0x6a @ 1
[   30.087961] hpet_acpi_add: no address or irqs in _CRS
[   30.104710] initcall hpet_init+0x0/0x6a returned 0 after 16539 usecs
[   30.125810] calling  nvram_init+0x0/0x82 @ 1
[   30.140169] Non-volatile memory driver v1.3
[   30.154123] initcall nvram_init+0x0/0x82 returned 0 after 13684 usecs
[   30.175572] calling  mod_init+0x0/0x220 @ 1
[   30.189624] initcall mod_init+0x0/0x220 returned -19 after 37 usecs
[   30.210463] calling  mod_init+0x0/0xba @ 1
[   30.224200] initcall mod_init+0x0/0xba returned -19 after 8 usecs
[   30.244496] calling  mod_init+0x0/0x4d @ 1
[   30.258223] initcall mod_init+0x0/0x4d returned -19 after 0 usecs
[   30.278528] calling  agp_init+0x0/0x26 @ 1
[   30.292255] Linux agpgart interface v0.103
[   30.305985] initcall agp_init+0x0/0x26 returned 0 after 13406 usecs
[   30.326862] calling  agp_intel_init+0x0/0x29 @ 1
[   30.342379] initcall agp_intel_init+0x0/0x29 returned 0 after 71 usecs
[   30.364042] calling  drm_core_init+0x0/0x12d @ 1
[   30.379552] [drm] Initialized drm 1.1.0 20060810
[   30.394929] initcall drm_core_init+0x0/0x12d returned 0 after 15082 usecs
[   30.417520] calling  i915_init+0x0/0x52 @ 1
[   30.431570] initcall i915_init+0x0/0x52 returned 0 after 34 usecs
[   30.451841] calling  cn_proc_init+0x0/0x3d @ 1
[   30.466712] initcall cn_proc_init+0x0/0x3d returned 0 after 1 usecs
[   30.487590] calling  serial8250_init+0x0/0x143 @ 1
[   30.503603] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
[   30.524729] async_waiting @ 1
[   30.534493] async_continuing @ 1 after 0 usec
(XEN) irq.c:1139:d0 Cannot bind IRQ 4 to guest. In use by 'ns16550'.
(XEN) irq.c:1139:d0 Cannot bind IRQ 2 to guest. In use by 'cascade'.
(XEN) irq.c:1139:d0 Cannot bind IRQ 4 to guest. In use by 'ns16550'.
(XEN) irq.c:1139:d0 Cannot bind IRQ 2 to guest. In use by 'cascade'.
[   30.750139] async_waiting @ 1
[   30.759588] async_continuing @ 1 after 0 usec
(XEN) irq.c:1139:d0 Cannot bind IRQ 4 to guest. In use by 'ns16550'.
(XEN) irq.c:1139:d0 Cannot bind IRQ 2 to guest. In use by 'cascade'.
(XEN) irq.c:1139:d0 Cannot bind IRQ 4 to guest. In use by 'ns16550'.
(XEN) irq.c:1139:d0 Cannot bind IRQ 2 to guest. In use by 'cascade'.
[   30.975191] serial8250: ttyS1 at I/O 0x2f8 (irq =3D 3) is a 16550A
[   30.995161] initcall serial8250_init+0x0/0x143 returned 0 after 480031 u=
secs
[   31.018101] calling  serial8250_pnp_init+0x0/0x12 @ 1
[   31.035357] 00:09: ttyS1 at I/O 0x2f8 (irq =3D 3) is a 16550A
[   31.053682] initcall serial8250_pnp_init+0x0/0x12 returned 0 after
18267 usecs
[   31.077589] calling  serial8250_pci_init+0x0/0x1b @ 1
[   31.094540] initcall serial8250_pci_init+0x0/0x1b returned 0 after 74 us=
ecs
[   31.117630] calling  topology_sysfs_init+0x0/0x50 @ 1
[   31.134514] initcall topology_sysfs_init+0x0/0x50 returned 0 after 13 us=
ecs
[   31.157666] calling  brd_init+0x0/0x1c8 @ 1
[   31.173904] brd: module loaded
[   31.183638] initcall brd_init+0x0/0x1c8 returned 0 after 11677 usecs
[   31.204802] calling  loop_init+0x0/0x1d5 @ 1
[   31.270200] loop: module loaded
[   31.280224] initcall loop_init+0x0/0x1d5 returned 0 after 59689 usecs
[   31.301672] calling  xlblk_init+0x0/0x7a @ 1
[   31.316024] initcall xlblk_init+0x0/0x7a returned 0 after 52 usecs
[   31.336560] calling  mac_hid_init+0x0/0x8e @ 1
[   31.351525] input: Macintosh mouse button emulation as
/devices/virtual/input/input2
[   31.377185] initcall mac_hid_init+0x0/0x8e returned 0 after 25148 usecs
[   31.399192] calling  spi_transport_init+0x0/0x79 @ 1
[   31.415880] initcall spi_transport_init+0x0/0x79 returned 0 after 96 use=
cs
[   31.438659] calling  twa_init+0x0/0x30 @ 1
[   31.452385] 3ware 9000 Storage Controller device driver for Linux
v2.26.02.012.
[   31.476716] xen: registering gsi 16 triggering 0 polarity 1
[   31.495286] xen_allocate_pirq: returning irq 16 for gsi 16
[   31.513589] xen: --> irq=3D16
[   31.523039] Already setup the GSI :16
[   31.535324] 3w-9xxx 0000:01:00.0: PCI INT A -> GSI 16 (level, low) -> IR=
Q 16
[   31.558779] 3w-9xxx 0000:01:00.0: setting latency timer to 64
[   31.832075] 3w-9xxx: scsi0: AEN: INFO (0x04:0x0053): Battery
capacity test is overdue:.
[   31.934073] 3w-9xxx: scsi0: AEN: INFO (0x04:0x0053): Battery
capacity test is overdue:.
[   32.036072] scsi0 : 3ware 9000 Storage Controller
[   32.051530] 3w-9xxx: scsi0: Found a 3ware 9000 Storage Controller
at 0xb3a00000, IRQ: 16.
[   32.384072] 3w-9xxx: scsi0: Firmware FH9X 4.10.00.021, BIOS BE9X
4.08.00.003, Ports: 128.
[   32.411054] scsi 0:0:0:0: Direct-Access     AMCC     9690SA-4I
DISK  4.10 PQ: 0 ANSI: 5
[   32.446653] initcall twa_init+0x0/0x30 returned 0 after 970962 usecs
[   32.467256] calling  init_sd+0x0/0x142 @ 1
[   32.481169] calling  2_sd_probe_async+0x0/0x1dc @ 1352
[   32.481210] initcall init_sd+0x0/0x142 returned 0 after 215 usecs
[   32.481212] calling  init_sr+0x0/0x46 @ 1
[   32.481266] initcall init_sr+0x0/0x46 returned 0 after 49 usecs
[   32.481269] calling  init_sg+0x0/0x125 @ 1
[   32.481394] sd 0:0:0:0: Attached scsi generic sg0 type 0
[   32.481408] initcall init_sg+0x0/0x125 returned 0 after 133 usecs
[   32.481411] calling  ahci_init+0x0/0x1b @ 1
[   32.481476] initcall ahci_init+0x0/0x1b returned 0 after 60 usecs
[   32.481479] calling  piix_init+0x0/0x29 @ 1
[   32.481537] initcall piix_init+0x0/0x29 returned 0 after 53 usecs
[   32.481539] calling  amd_init+0x0/0x1b @ 1
[   32.481596] initcall amd_init+0x0/0x1b returned 0 after 52 usecs
[   32.481598] calling  mpiix_init+0x0/0x1b @ 1
[   32.481653] initcall mpiix_init+0x0/0x1b returned 0 after 50 usecs
[   32.481656] calling  oldpiix_init+0x0/0x1b @ 1
[   32.481710] initcall oldpiix_init+0x0/0x1b returned 0 after 50 usecs
[   32.481713] calling  sch_init+0x0/0x1b @ 1
[   32.481767] initcall sch_init+0x0/0x1b returned 0 after 49 usecs
[   32.481769] calling  ata_generic_init+0x0/0x1b @ 1
[   32.481824] initcall ata_generic_init+0x0/0x1b returned 0 after 50 usecs
[   32.481827] calling  e1000_init_module+0x0/0x87 @ 1
[   32.481829] Intel(R) PRO/1000 Network Driver - version 7.3.21-k5-NAPI
[   32.481830] Copyright (c) 1999-2006 Intel Corporation.
[   32.481889] initcall e1000_init_module+0x0/0x87 returned 0 after 57 usecs
[   32.481892] calling  e1000_init_module+0x0/0x6b @ 1
[   32.481894] e1000e: Intel(R) PRO/1000 Network Driver - 1.0.2-k2
[   32.481895] e1000e: Copyright (c) 1999-2008 Intel Corporation.
[   32.481936] xen: registering gsi 16 triggering 0 polarity 1
[   32.481937] xen_allocate_pirq: returning irq 16 for gsi 16
[   32.481939] xen: --> irq=3D16
[   32.481941] Already setup the GSI :16
[   32.481943] e1000e 0000:00:19.0: PCI INT A -> GSI 16 (level, low) -> IRQ=
 16
[   32.481951] e1000e 0000:00:19.0: setting latency timer to 64
[   32.482075]   alloc irq_desc for 1251 on node -1
[   32.482076]   alloc kstat_irqs on node -1
[   33.111523] sd 0:0:0:0: [sda] 2929666048 512-byte logical blocks:
(1.49 TB/1.36 TiB)
[   33.137722] sd 0:0:0:0: [sda] Write Protect is off
[   33.153176] sd 0:0:0:0: [sda] Mode Sense: 23 00 10 00
[   33.172013] sd 0:0:0:0: [sda] Write cache: enabled, read cache:
enabled, supports DPO and FUA
[   33.201332]  sda: sda1 sda2 < sda5 sda6 sda7 sda8 sda9 >
[   33.266171] sd 0:0:0:0: [sda] Attached SCSI disk
[   33.281064] initcall 2_sd_probe_async+0x0/0x1dc returned 0 after 165744 =
usecs

then it hangs
thanks for your help

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 18:33:11 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 18:33:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RatdC-0003yP-Of; Wed, 14 Dec 2011 18:32:42 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <quartex73@gmail.com>) id 1RatdA-0003w5-BH
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 18:32:41 +0000
X-Env-Sender: quartex73@gmail.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1323887498!7225023!1
X-Originating-IP: [209.85.213.171]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19161 invoked from network); 14 Dec 2011 18:31:39 -0000
Received: from mail-yx0-f171.google.com (HELO mail-yx0-f171.google.com)
	(209.85.213.171)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Dec 2011 18:31:39 -0000
Received: by yenr9 with SMTP id r9so15679992yen.30
	for <xen-devel@lists.xensource.com>;
	Wed, 14 Dec 2011 10:31:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	bh=GKbQdTdSv4i+Bpr7t920Hr4qle/cbnzhIPIVpnI28+E=;
	b=WynrLPOl6SuXtdUTjlqjMa5jlelPJ438mDPKdIy+Y6WUk2nUSFUsC5g61nJIvcbtk2
	Ox8hFO/B+MmPwa1NHzFszlI1sNe9UjKNMUszQfUhenpHY4irfy2RkSgk5+YflCwgFxmo
	ZE/GXQyLsyQKuq+/hBsjklKVEnc4+mpbulkmw=
MIME-Version: 1.0
Received: by 10.236.176.2 with SMTP id a2mr13811338yhm.12.1323887498320; Wed,
	14 Dec 2011 10:31:38 -0800 (PST)
Received: by 10.146.58.7 with HTTP; Wed, 14 Dec 2011 10:31:38 -0800 (PST)
In-Reply-To: <20111202195727.GA18758@andromeda.dapyr.net>
References: <CAMhBqqiLc1994GUKtA7UY52pR29nktmFy+XiwTwpZb_E+fwFRQ@mail.gmail.com>
	<CAMhBqqgu6v8NB-X0dNdfrzd12=Y2i==fYCCC2Z+MkDupqqKAOg@mail.gmail.com>
	<20111202195727.GA18758@andromeda.dapyr.net>
Date: Wed, 14 Dec 2011 19:31:38 +0100
Message-ID: <CAMhBqqgJ0Q3BZDuK3KEEGuDS2eGBZq89E7_Kbv+VNTYxZJLAAA@mail.gmail.com>
From: Quartexx <quartex73@gmail.com>
To: xen-devel@lists.xensource.com
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>
Subject: Re: [Xen-devel] xen 4.0.1 w/2.6.32.47 hangs at boot
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

2011/12/2 Konrad Rzeszutek Wilk <konrad@darnok.org>:
> On Fri, Dec 02, 2011 at 08:22:46PM +0100, Quartexx wrote:
>> ### lspci
>
> <sigh> You seem to be missing the most important - that is the serial
> console output with 'sync_console' enabled.


here it is:

 __  __            _  _    ___   _
 \ \/ /___ _ __   | || |  / _ \ / |
  \  // _ \ '_ \  | || |_| | | || |
  /  \  __/ | | | |__   _| |_| || |
 /_/\_\___|_| |_|    |_|(_)___(_)_|

(XEN) Xen version 4.0.1 (root@foo-net.private) (gcc version 4.4.5
(Debian 4.4.5-8) ) Fri Dec  2 16:56:12 CET 2011
(XEN) Latest ChangeSet: unavailable
(XEN) Console output is synchronous.
(XEN) Bootloader: GNU GRUB 0.97
(XEN) Command line: dom0_mem=3D1024M max_cstate=3D1 loglvl=3Dall
guest_loglvl=3Dall sync_console console_to_ring com1=3D38400,8n1
console=3Dcom1
(XEN) Video information:
(XEN)  VGA is text mode 80x25, font 8x16
(XEN)  VBE/DDC methods: V2; EDID transfer time: 1 seconds
(XEN) Disc information:
(XEN)  Found 1 MBR signatures
(XEN)  Found 1 EDD information structures
(XEN) Xen-e820 RAM map:
(XEN)  0000000000000000 - 000000000009b800 (usable)
(XEN)  000000000009b800 - 00000000000a0000 (reserved)
(XEN)  00000000000e0000 - 0000000000100000 (reserved)
(XEN)  0000000000100000 - 000000009d8e9000 (usable)
(XEN)  000000009d8e9000 - 000000009d9bb000 (ACPI NVS)
(XEN)  000000009d9bb000 - 000000009f6a4000 (ACPI data)
(XEN)  000000009f6a4000 - 000000009f6df000 (reserved)
(XEN)  000000009f6df000 - 000000009f78a000 (ACPI data)
(XEN)  000000009f78a000 - 000000009f7df000 (ACPI NVS)
(XEN)  000000009f7df000 - 000000009f800000 (ACPI data)
(XEN)  000000009f800000 - 00000000b0000000 (reserved)
(XEN)  00000000fed1c000 - 00000000fed20000 (reserved)
(XEN)  00000000ff800000 - 0000000100000000 (reserved)
(XEN)  0000000100000000 - 0000000460000000 (usable)
(XEN) ACPI: RSDP 000F0410, 0024 (r2 INTEL )
(XEN) ACPI: XSDT 9F7FD120, 008C (r1 INTEL  S3420GPC        0       1000013)
(XEN) ACPI: FACP 9F7FB000, 00F4 (r4 INTEL  S3420GPC        0 MSFT  100000D)
(XEN) ACPI: DSDT 9F7F6000, 4E22 (r2 INTEL  S3420GPC        3 MSFT  100000D)
(XEN) ACPI: FACS 9F78A000, 0040
(XEN) ACPI: APIC 9F7F5000, 00BC (r2 INTEL  S3420GPC        0 MSFT  100000D)
(XEN) ACPI: MCFG 9F7F4000, 003C (r1 INTEL  S3420GPC        1 MSFT  100000D)
(XEN) ACPI: HPET 9F7F3000, 0038 (r1 INTEL  S3420GPC        1 MSFT  100000D)
(XEN) ACPI: SLIT 9F7F2000, 0030 (r1 INTEL  S3420GPC        1 MSFT  100000D)
(XEN) ACPI: SPCR 9F7F1000, 0050 (r1 INTEL  S3420GPC        0 MSFT  100000D)
(XEN) ACPI: WDDT 9F7F0000, 0040 (r1 INTEL  S3420GPC        0 MSFT  100000D)
(XEN) ACPI: SSDT 9F7E5000, AEF4 (r2  INTEL SSDT  PM     4000 INTL 20061109)
(XEN) ACPI: SSDT 9F7E4000, 01D8 (r2  INTEL IPMI         4000 INTL 20061109)
(XEN) ACPI: HEST 9F7E3000, 00A8 (r1 INTEL  S3420GPC        1 INTL        1)
(XEN) ACPI: BERT 9F7E2000, 0030 (r1 INTEL  S3420GPC        1 INTL        1)
(XEN) ACPI: ERST 9F7E1000, 0230 (r1 INTEL  S3420GPC        1 INTL        1)
(XEN) ACPI: EINJ 9F7E0000, 0130 (r1 INTEL  S3420GPC        1 INTL        1)
(XEN) System RAM: 16344MB (16736784kB)
(XEN) No NUMA configuration found
(XEN) Faking a node at 0000000000000000-0000000460000000
(XEN) Domain heap initialised
(XEN) found SMP MP-table at 000fd9a0
(XEN) DMI 2.5 present.
(XEN) Using APIC driver default
(XEN) ACPI: PM-Timer IO Port: 0x408
(XEN) ACPI: ACPI SLEEP INFO: pm1x_cnt[404,0], pm1x_evt[400,0]
(XEN) ACPI:                  wakeup_vec[9f78a00c], vec_size[20]
(XEN) ACPI: Local APIC address 0xfee00000
(XEN) ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
(XEN) Processor #0 7:14 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x02] enabled)
(XEN) Processor #2 7:14 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x02] lapic_id[0x04] enabled)
(XEN) Processor #4 7:14 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x03] lapic_id[0x06] enabled)
(XEN) Processor #6 7:14 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x04] lapic_id[0x01] disabled)
(XEN) ACPI: LAPIC (acpi_id[0x05] lapic_id[0x03] disabled)
(XEN) ACPI: LAPIC (acpi_id[0x06] lapic_id[0x05] disabled)
(XEN) ACPI: LAPIC (acpi_id[0x07] lapic_id[0x07] disabled)
(XEN) ACPI: LAPIC_NMI (acpi_id[0x00] high level lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x01] high level lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x02] high level lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x03] high level lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x04] high level lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x05] high level lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x06] high level lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x07] high level 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: 0x8086a801 base: 0xfed00000
(XEN) PCI: MCFG configuration 0: base a0000000 segment 0 buses 0 - 255
(XEN) PCI: MCFG area at a0000000 reserved in E820
(XEN) Using ACPI (MADT) for SMP configuration information
(XEN) Using scheduler: SMP Credit Scheduler (credit)
(XEN) Detected 2400.027 MHz processor.
(XEN) Initing memory sharing.
(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) EPT supports 2MB super page.
(XEN) HVM: ASIDs enabled.
(XEN) HVM: VMX enabled
(XEN) HVM: Hardware Assisted Paging detected.
(XEN) Intel machine check reporting enabled
(XEN) I/O virtualisation disabled
(XEN) Total of 4 processors activated.
(XEN) ENABLING IO-APIC IRQs
(XEN)  -> Using new ACK method
(XEN) ..TIMER: vector=3D0xF0 apic1=3D0 pin1=3D2 apic2=3D-1 pin2=3D-1
(XEN) TSC is reliable, synchronization unnecessary
(XEN) Platform timer appears to have unexpectedly wrapped 1 times.
(XEN) Platform timer is 14.318MHz HPET
=FF(XEN) Allocated console ring of 32 KiB.
(XEN) microcode.c:73:d32767 microcode: CPU1 resumed
(XEN) microcode.c:73:d32767 microcode: CPU3 resumed
(XEN) microcode.c:73:d32767 microcode: CPU2 resumed
(XEN) Brought up 4 CPUs
(XEN) Turbo Mode detected!
(XEN) HPET: 8 timers in total, 8 timers will be used for broadcast
(XEN) ACPI sleep modes: S3
(XEN) mcheck_poll: Machine check polling timer started.
(XEN) *** LOADING DOMAIN 0 ***
(XEN)  Xen  kernel: 64-bit, lsb, compat32
(XEN)  Dom0 kernel: 64-bit, PAE, lsb, paddr 0x1000000 -> 0x1bfc000
(XEN) PHYSICAL MEMORY ARRANGEMENT:
(XEN)  Dom0 alloc.:   0000000450000000->0000000454000000 (245760 pages
to be allocated)
(XEN) VIRTUAL MEMORY ARRANGEMENT:
(XEN)  Loaded kernel: ffffffff81000000->ffffffff81bfc000
(XEN)  Init. ramdisk: ffffffff81bfc000->ffffffff820c7c00
(XEN)  Phys-Mach map: ffffffff820c8000->ffffffff822c8000
(XEN)  Start info:    ffffffff822c8000->ffffffff822c84b4
(XEN)  Page tables:   ffffffff822c9000->ffffffff822de000
(XEN)  Boot stack:    ffffffff822de000->ffffffff822df000
(XEN)  TOTAL:         ffffffff80000000->ffffffff82400000
(XEN)  ENTRY ADDRESS: ffffffff81976200
(XEN) Dom0 has maximum 4 VCPUs
(XEN) Scrubbing Free RAM:
...........................................................................=
...........................................................................=
..done.
(XEN) trace.c:89:d32767 calc_tinfo_first_offset: NR_CPUs 128,
offset_in_bytes 258, t_info_first_offset 65
(XEN) Xen trace buffers: disabled
(XEN) Std. Loglevel: All
(XEN) Guest Loglevel: All
(XEN) **********************************************
(XEN) ******* WARNING: CONSOLE OUTPUT IS SYNCHRONOUS
(XEN) ******* This option is intended to aid debugging of Xen by ensuring
(XEN) ******* that all output is synchronously delivered on the serial line.
(XEN) ******* However it can introduce SIGNIFICANT latencies and affect
(XEN) ******* timekeeping. It is NOT recommended for production use!
(XEN) **********************************************
(XEN) 3... 2... 1...
(XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch
input to Xen)
(XEN) Freed 176kB init memory.
mapping kernel into physical memory
Xen: setup ISA identity maps
about to get started...
[    0.000000] Initializing cgroup subsys cpuset
[    0.000000] Initializing cgroup subsys cpu
[    0.000000] Linux version 2.6.32.47 (root@xenhost-rack2) (gcc
version 4.4.5 (Debian 4.4.5-8) ) #1 SMP Fri Dec 2 13:05:28 CET 2011
[    0.000000] Command line:
root=3DUUID=3D5563bc26-6e98-4768-abee-5ca053e2795c ro nomodeset
max_loop=3D255 console=3Dhvc0 earlyprintk=3Dxen
[    0.000000] KERNEL supported cpus:
[    0.000000]   Intel GenuineIntel
[    0.000000]   AMD AuthenticAMD
[    0.000000]   Centaur CentaurHauls
[    0.000000] released 0 pages of unused memory
[    0.000000] BIOS-provided physical RAM map:
[    0.000000]  Xen: 0000000000000000 - 000000000009b000 (usable)
[    0.000000]  Xen: 000000000009b800 - 0000000000100000 (reserved)
[    0.000000]  Xen: 0000000000100000 - 0000000040000000 (usable)
[    0.000000]  Xen: 0000000040000000 - 000000009d8e9000 (unusable)
[    0.000000]  Xen: 000000009d8e9000 - 000000009d9bb000 (ACPI NVS)
[    0.000000]  Xen: 000000009d9bb000 - 000000009f6a4000 (ACPI data)
[    0.000000]  Xen: 000000009f6a4000 - 000000009f6df000 (reserved)
[    0.000000]  Xen: 000000009f6df000 - 000000009f78a000 (ACPI data)
[    0.000000]  Xen: 000000009f78a000 - 000000009f7df000 (ACPI NVS)
[    0.000000]  Xen: 000000009f7df000 - 000000009f800000 (ACPI data)
[    0.000000]  Xen: 000000009f800000 - 00000000b0000000 (reserved)
[    0.000000]  Xen: 00000000fec00000 - 00000000fec01000 (reserved)
[    0.000000]  Xen: 00000000fed1c000 - 00000000fed20000 (reserved)
[    0.000000]  Xen: 00000000fee00000 - 00000000fee01000 (reserved)
[    0.000000]  Xen: 00000000ff800000 - 0000000100000000 (reserved)
[    0.000000]  Xen: 0000000100000000 - 0000000340000000 (usable)
[    0.000000] bootconsole [xenboot0] enabled
[    0.000000] DMI 2.5 present.
[    0.000000] last_pfn =3D 0x340000 max_arch_pfn =3D 0x400000000
[    0.000000] x86 PAT enabled: cpu 0, old 0x50100070406, new 0x70106000701=
06
[    0.000000] last_pfn =3D 0x40000 max_arch_pfn =3D 0x400000000
[    0.000000] Scanning 1 areas for low memory corruption
[    0.000000] modified physical RAM map:
[    0.000000]  modified: 0000000000000000 - 0000000000001000 (usable)
[    0.000000]  modified: 0000000000001000 - 0000000000006000 (reserved)
[    0.000000]  modified: 0000000000006000 - 000000000009b000 (usable)
[    0.000000]  modified: 000000000009b800 - 0000000000100000 (reserved)
[    0.000000]  modified: 0000000000100000 - 0000000040000000 (usable)
[    0.000000]  modified: 0000000040000000 - 000000009d8e9000 (unusable)
[    0.000000]  modified: 000000009d8e9000 - 000000009d9bb000 (ACPI NVS)
[    0.000000]  modified: 000000009d9bb000 - 000000009f6a4000 (ACPI data)
[    0.000000]  modified: 000000009f6a4000 - 000000009f6df000 (reserved)
[    0.000000]  modified: 000000009f6df000 - 000000009f78a000 (ACPI data)
[    0.000000]  modified: 000000009f78a000 - 000000009f7df000 (ACPI NVS)
[    0.000000]  modified: 000000009f7df000 - 000000009f800000 (ACPI data)
[    0.000000]  modified: 000000009f800000 - 00000000b0000000 (reserved)
[    0.000000]  modified: 00000000fec00000 - 00000000fec01000 (reserved)
[    0.000000]  modified: 00000000fed1c000 - 00000000fed20000 (reserved)
[    0.000000]  modified: 00000000fee00000 - 00000000fee01000 (reserved)
[    0.000000]  modified: 00000000ff800000 - 0000000100000000 (reserved)
[    0.000000]  modified: 0000000100000000 - 0000000340000000 (usable)
[    0.000000] init_memory_mapping: 0000000000000000-0000000040000000
[    0.000000] init_memory_mapping: 0000000100000000-0000000340000000
[    0.000000] RAMDISK: 01bfc000 - 020c7c00
[    0.000000] ACPI: RSDP 00000000000f0410 00024 (v02 INTEL )
[    0.000000] ACPI: XSDT 000000009f7fd120 0008C (v01 INTEL  S3420GPC
00000000      01000013)
[    0.000000] ACPI: FACP 000000009f7fb000 000F4 (v04 INTEL  S3420GPC
00000000 MSFT 0100000D)
[    0.000000] ACPI: DSDT 000000009f7f6000 04E22 (v02 INTEL  S3420GPC
00000003 MSFT 0100000D)
[    0.000000] ACPI: FACS 000000009f78a000 00040
[    0.000000] ACPI: APIC 000000009f7f5000 000BC (v02 INTEL  S3420GPC
00000000 MSFT 0100000D)
[    0.000000] ACPI: MCFG 000000009f7f4000 0003C (v01 INTEL  S3420GPC
00000001 MSFT 0100000D)
[    0.000000] ACPI: HPET 000000009f7f3000 00038 (v01 INTEL  S3420GPC
00000001 MSFT 0100000D)
[    0.000000] ACPI: SLIT 000000009f7f2000 00030 (v01 INTEL  S3420GPC
00000001 MSFT 0100000D)
[    0.000000] ACPI: SPCR 000000009f7f1000 00050 (v01 INTEL  S3420GPC
00000000 MSFT 0100000D)
[    0.000000] ACPI: WDDT 000000009f7f0000 00040 (v01 INTEL  S3420GPC
00000000 MSFT 0100000D)
[    0.000000] ACPI: SSDT 000000009f7e5000 0AEF4 (v02  INTEL SSDT  PM
00004000 INTL 20061109)
[    0.000000] ACPI: SSDT 000000009f7e4000 001D8 (v02  INTEL IPMI
00004000 INTL 20061109)
[    0.000000] ACPI: HEST 000000009f7e3000 000A8 (v01 INTEL  S3420GPC
00000001 INTL 00000001)
[    0.000000] ACPI: BERT 000000009f7e2000 00030 (v01 INTEL  S3420GPC
00000001 INTL 00000001)
[    0.000000] ACPI: ERST 000000009f7e1000 00230 (v01 INTEL  S3420GPC
00000001 INTL 00000001)
[    0.000000] ACPI: EINJ 000000009f7e0000 00130 (v01 INTEL  S3420GPC
00000001 INTL 00000001)
[    0.000000] (10 early reservations) =3D=3D> bootmem [0000000000 - 034000=
0000]
[    0.000000]   #0 [0000000000 - 0000001000]   BIOS data page =3D=3D>
[0000000000 - 0000001000]
[    0.000000]   #1 [00022c9000 - 00022de000]   XEN PAGETABLES =3D=3D>
[00022c9000 - 00022de000]
[    0.000000]   #2 [0000006000 - 0000008000]       TRAMPOLINE =3D=3D>
[0000006000 - 0000008000]
[    0.000000]   #3 [0001000000 - 0001ad1474]    TEXT DATA BSS =3D=3D>
[0001000000 - 0001ad1474]
[    0.000000]   #4 [0001bfc000 - 00020c7c00]          RAMDISK =3D=3D>
[0001bfc000 - 00020c7c00]
[    0.000000]   #5 [00020c8000 - 00022c9000]   XEN START INFO =3D=3D>
[00020c8000 - 00022c9000]
[    0.000000]   #6 [0100000000 - 0340000000]        XEN EXTRA =3D=3D>
[0100000000 - 0340000000]
[    0.000000]   #7 [0001ad2000 - 0001ade36c]              BRK =3D=3D>
[0001ad2000 - 0001ade36c]
[    0.000000]   #8 [0000100000 - 00002ea000]          PGTABLE =3D=3D>
[0000100000 - 00002ea000]
[    0.000000]   #9 [00022de000 - 00034e7000]          PGTABLE =3D=3D>
[00022de000 - 00034e7000]
[    0.000000] found SMP MP-table at [ffff8800000fd9a0] fd9a0
[    0.000000] Zone PFN ranges:
[    0.000000]   DMA      0x00000000 -> 0x00001000
[    0.000000]   DMA32    0x00001000 -> 0x00100000
[    0.000000]   Normal   0x00100000 -> 0x00340000
[    0.000000] Movable zone start PFN for each node
[    0.000000] early_node_map[4] active PFN ranges
[    0.000000]     0: 0x00000000 -> 0x00000001
[    0.000000]     0: 0x00000006 -> 0x0000009b
[    0.000000]     0: 0x00000100 -> 0x00040000
[    0.000000]     0: 0x00100000 -> 0x00340000
[    0.000000] ACPI: PM-Timer IO Port: 0x408
[    0.000000] ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x02] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x04] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x03] lapic_id[0x06] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x04] lapic_id[0x01] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x05] lapic_id[0x03] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x06] lapic_id[0x05] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x07] lapic_id[0x07] disabled)
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x00] high level lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x01] high level lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x02] high level lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x03] high level lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x04] high level lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x05] high level lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x06] high level lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x07] high level lint[0x1])
[    0.000000] ACPI: IOAPIC (id[0x08] address[0xfec00000] gsi_base[0])
[    0.000000] IOAPIC[0]: apic_id 8, version 0, address 0xfec00000, GSI 0-0
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
[    0.000000] ERROR: Unable to locate IOAPIC for GSI 2
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
[    0.000000] ERROR: Unable to locate IOAPIC for GSI 9
[    0.000000] Using ACPI (MADT) for SMP configuration information
[    0.000000] ACPI: HPET id: 0x8086a801 base: 0xfed00000
[    0.000000] SMP: Allowing 4 CPUs, 0 hotplug CPUs
[    0.000000] PM: Registered nosave memory: 0000000000001000 - 00000000000=
06000
[    0.000000] PM: Registered nosave memory: 000000000009b000 - 00000000000=
9c000
[    0.000000] PM: Registered nosave memory: 000000000009c000 - 00000000001=
00000
[    0.000000] PM: Registered nosave memory: 0000000040000000 - 000000009d8=
e9000
[    0.000000] PM: Registered nosave memory: 000000009d8e9000 - 000000009d9=
bb000
[    0.000000] PM: Registered nosave memory: 000000009d9bb000 - 000000009f6=
a4000
[    0.000000] PM: Registered nosave memory: 000000009f6a4000 - 000000009f6=
df000
[    0.000000] PM: Registered nosave memory: 000000009f6df000 - 000000009f7=
8a000
[    0.000000] PM: Registered nosave memory: 000000009f78a000 - 000000009f7=
df000
[    0.000000] PM: Registered nosave memory: 000000009f7df000 - 000000009f8=
00000
[    0.000000] PM: Registered nosave memory: 000000009f800000 - 00000000b00=
00000
[    0.000000] PM: Registered nosave memory: 00000000b0000000 - 00000000fec=
00000
[    0.000000] PM: Registered nosave memory: 00000000fec00000 - 00000000fec=
01000
[    0.000000] PM: Registered nosave memory: 00000000fec01000 - 00000000fed=
1c000
[    0.000000] PM: Registered nosave memory: 00000000fed1c000 - 00000000fed=
20000
[    0.000000] PM: Registered nosave memory: 00000000fed20000 - 00000000fee=
00000
[    0.000000] PM: Registered nosave memory: 00000000fee00000 - 00000000fee=
01000
[    0.000000] PM: Registered nosave memory: 00000000fee01000 - 00000000ff8=
00000
[    0.000000] PM: Registered nosave memory: 00000000ff800000 - 00000001000=
00000
[    0.000000] Allocating PCI resources starting at b0000000 (gap:
b0000000:4ec00000)
[    0.000000] Booting paravirtualized kernel on Xen
[    0.000000] Xen version: 4.0.1 (preserve-AD) (dom0)
[    0.000000] NR_CPUS:8 nr_cpumask_bits:8 nr_cpu_ids:4 nr_node_ids:1
[    0.000000] PERCPU: Embedded 29 pages/cpu @ffff880028038000 s88536
r8192 d22056 u118784
[    0.000000] pcpu-alloc: s88536 r8192 d22056 u118784 alloc=3D29*4096
[    0.000000] pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3
[    9.839051] Built 1 zonelists in Zone order, mobility grouping on.
Total pages: 2574249
[    9.865636] Kernel command line:
root=3DUUID=3D5563bc26-6e98-4768-abee-5ca053e2795c ro nomodeset
max_loop=3D255 console=3Dhvc0 earlyprintk=3Dxen
[    9.905431] PID hash table entries: 4096 (order: 3, 32768 bytes)
[    9.926753] Dentry cache hash table entries: 2097152 (order: 12,
16777216 bytes)
[    9.954316] Inode-cache hash table entries: 1048576 (order: 11,
8388608 bytes)
[    9.979372] Initializing CPU#0
[    9.995611] DMA: Placing 64MB software IO TLB between
ffff880020000000 - ffff880024000000
[   10.021944] DMA: software IO TLB at phys 0x20000000 - 0x24000000
[   10.041672] xen_swiotlb_fixup: buf=3Dffff880020000000 size=3D67108864
[   10.079409] xen_swiotlb_fixup: buf=3Dffff880024060000 size=3D32768
[   10.101542] Memory: 774160k/13631488k available (5877k kernel code,
3146152k absent, 9710440k reserved, 3717k data, 568k init)
[   10.138468] SLUB: Genslabs=3D13, HWalign=3D64, Order=3D0-3, MinObjects=
=3D0,
CPUs=3D4, Nodes=3D1
[   10.163634] Hierarchical RCU implementation.
[   10.177636] NR_IRQS:4352 nr_irqs:1280
[   10.189792] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
[   10.210523] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
[   10.232257] xen: sci override: source_irq=3D9 global_irq=3D9 trigger=3Dc=
 polarity=3D1
[   10.255712] xen_allocate_pirq: returning irq 9 for gsi 9
[   10.273159] xen: acpi sci 9
[   10.293028] Console: colour VGA+ 80x25
[   10.304769] console [hvc0] enabled, bootconsole disabled
[   10.304769] console [hvc0] enabled, bootconsole disabled
[   10.339957] installing Xen timer for CPU 0
[   10.353698] Detected 2400.026 MHz processor.
[   10.367971] Calibrating delay loop (skipped), value calculated
using timer frequency.. 4800.05 BogoMIPS (lpj=3D2400026)
[   10.403157] Security Framework initialized
[   10.416878] SELinux:  Initializing.
[   10.428608] Mount-cache hash table entries: 256
[   10.443892] Initializing cgroup subsys ns
[   10.457205] Initializing cgroup subsys cpuacct
[   10.472071] Initializing cgroup subsys freezer
[   10.486973] CPU: L1 I cache: 32K, L1 D cache: 32K
[   10.502669] CPU: L2 cache: 256K
[   10.513252] CPU: L3 cache: 8192K
[   10.524125] CPU: Unsupported number of siblings 16
[   10.539282] mce: CPU supports 9 MCE banks
[   10.553603] Performance Events: unsupported p6 CPU model 30 no PMU
driver, software events only.
[   10.582756] SMP alternatives: switching to UP code
[   10.635796] ACPI: Core revision 20090903
[   10.668729] installing Xen timer for CPU 1
[   10.681928] SMP alternatives: switching to SMP code
[   10.734120] Initializing CPU#1
[   10.734156] CPU: L1 I cache: 32K, L1 D cache: 32K
[   10.734158] CPU: L2 cache: 256K
[   10.734159] CPU: L3 cache: 8192K
[   10.734163] CPU: Unsupported number of siblings 16
[   10.734239] installing Xen timer for CPU 2
[   10.810958] Initializing CPU#2
[   10.810992] CPU: L1 I cache: 32K, L1 D cache: 32K
[   10.810994] CPU: L2 cache: 256K
[   10.810995] CPU: L3 cache: 8192K
[   10.810999] CPU: Unsupported number of siblings 16
[   10.811070] installing Xen timer for CPU 3
[   10.888173] Initializing CPU#3
[   10.888207] CPU: L1 I cache: 32K, L1 D cache: 32K
[   10.888209] CPU: L2 cache: 256K
[   10.888211] CPU: L3 cache: 8192K
[   10.888214] CPU: Unsupported number of siblings 16
[   10.888248] Brought up 4 CPUs
[   10.962416] Grant table initialized
[   10.973608] Time: 15:24:53  Date: 12/14/11
[   10.987357] NET: Registered protocol family 16
[   11.002765] ACPI FADT declares the system doesn't support PCIe
ASPM, so disable it
[   11.027370] ACPI: bus type pci registered
[   11.041225] PCI: MCFG configuration 0: base a0000000 segment 0 buses 0 -=
 255
[   11.064263] PCI: MCFG area at a0000000 reserved in E820
[   11.105483] PCI: Using MMCONFIG at a0000000 - afffffff
[   11.122083] PCI: Using configuration type 1 for base access
[   11.152342] bio: create slab <bio-0> at 0
[   11.166715] ERROR: Unable to locate IOAPIC for GSI 9
[   11.184378] ACPI Error: Field [CPB3] at 96 exceeds Buffer [NULL]
size 64 (bits) (20090903/dsopcode-596)
[   11.214992] ACPI Error (psparse-0537): Method parse/execution
failed [\_SB_._OSC] (Node ffff88003fc187c0), AE_AML_BUFFER_LIMIT
[   11.275785] ACPI: Interpreter enabled
[   11.287525] ACPI: (supports S0 S1 S5)
[   11.299822] ACPI: Using IOAPIC for interrupt routing
[   11.329279] ACPI: No dock devices found.
[   11.342638] ACPI: PCI Root Bridge [PCI0] (0000:00)
[   11.358366] pci 0000:00:05.0: PME# supported from D0 D3hot D3cold
[   11.378399] pci 0000:00:05.0: PME# disabled
[   11.393065] pci 0000:00:19.0: PME# supported from D0 D3hot D3cold
[   11.412812] pci 0000:00:19.0: PME# disabled
[   11.427012] pci 0000:00:1a.0: PME# supported from D0 D3hot D3cold
[   11.447131] pci 0000:00:1a.0: PME# disabled
[   11.461256] pci 0000:00:1c.0: PME# supported from D0 D3hot D3cold
[   11.481449] pci 0000:00:1c.0: PME# disabled
[   11.495578] pci 0000:00:1c.4: PME# supported from D0 D3hot D3cold
[   11.515769] pci 0000:00:1c.4: PME# disabled
[   11.529893] pci 0000:00:1c.6: PME# supported from D0 D3hot D3cold
[   11.550087] pci 0000:00:1c.6: PME# disabled
[   11.564212] pci 0000:00:1c.7: PME# supported from D0 D3hot D3cold
[   11.584407] pci 0000:00:1c.7: PME# disabled
[   11.598597] pci 0000:00:1d.0: PME# supported from D0 D3hot D3cold
[   11.618728] pci 0000:00:1d.0: PME# disabled
[   11.633590] pci 0000:03:00.0: PME# supported from D0 D3hot D3cold
[   11.653337] pci 0000:03:00.0: PME# disabled
[   11.667914] pci 0000:00:1e.0: transparent bridge
(XEN) PCI add device 00:00.0
(XEN) PCI add device 00:05.0
(XEN) PCI add device 00:08.0
(XEN) PCI add device 00:08.1
(XEN) PCI add device 00:08.2
(XEN) PCI add device 00:08.3
(XEN) PCI add device 00:10.0
(XEN) PCI add device 00:10.1
(XEN) PCI add device 00:19.0
(XEN) PCI add device 00:1a.0
(XEN) PCI add device 00:1c.0
(XEN) PCI add device 00:1c.4
(XEN) PCI add device 00:1c.6
(XEN) PCI add device 00:1c.7
(XEN) PCI add device 00:1d.0
(XEN) PCI add device 00:1e.0
(XEN) PCI add device 00:1f.0
(XEN) PCI add device 00:1f.3
(XEN) PCI add device 01:00.0
(XEN) PCI add device 03:00.0
(XEN) PCI add device 04:00.0
[   11.864475] ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 9 *10
11 12 14 15)
[   11.888232] ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 9 10
*11 12 14 15)
[   11.912254] ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 *5 6 7 9 10
11 12 14 15)
[   11.936300] ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 7 9 10
*11 12 14 15)
[   11.960301] ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 7 9 10 11
12 14 15) *0, disabled.
[   11.988037] ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 6 7 *9 10
11 12 14 15)
[   12.012064] ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 6 7 9 10 11
12 14 15) *0, disabled.
[   12.039801] ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 6 7 9 *10
11 12 14 15)
[   12.063966] xen_balloon: Initialising balloon driver with page order 0.
[   12.085852] last_pfn =3D 0x340000 max_arch_pfn =3D 0x400000000
[   12.134092] vgaarb: device added:
PCI:0000:04:00.0,decodes=3Dio+mem,owns=3Dio+mem,locks=3Dnone
[   12.160419] vgaarb: loaded
[   12.169810] SCSI subsystem initialized
[   12.182634] usbcore: registered new interface driver usbfs
[   12.200513] usbcore: registered new interface driver hub
[   12.218271] usbcore: registered new device driver usb
[   12.235434] PCI: Using ACPI for IRQ routing
[   12.249456] cfg80211: Using static regulatory domain info
[   12.267093] cfg80211: Regulatory domain: US
[   12.281108] 	(start_freq - end_freq @ bandwidth),
(max_antenna_gain, max_eirp)
[   12.305128] 	(2402000 KHz - 2472000 KHz @ 40000 KHz), (600 mBi, 2700 mBm)
[   12.327725] 	(5170000 KHz - 5190000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
[   12.350318] 	(5190000 KHz - 5210000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
[   12.372912] 	(5210000 KHz - 5230000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
[   12.395505] 	(5230000 KHz - 5330000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
[   12.418099] 	(5735000 KHz - 5835000 KHz @ 40000 KHz), (600 mBi, 3000 mBm)
[   12.440703] cfg80211: Calling CRDA for country: US
[   12.456754] NetLabel: Initializing
[   12.468144] NetLabel:  domain hash size =3D 128
[   12.482728] NetLabel:  protocols =3D UNLABELED CIPSOv4
[   12.499325] NetLabel:  unlabeled traffic allowed by default
[   12.518090] Switching to clocksource xen
[   12.533142] pnp: PnP ACPI init
[   12.542896] ACPI: bus type pnp registered
[   12.557733] xen_allocate_pirq: returning irq 8 for gsi 8
[   12.575024] xen_allocate_pirq: returning irq 13 for gsi 13
[   12.594078] xen_allocate_pirq: returning irq 4 for gsi 4
[   12.611257] Already setup the GSI :4
[   12.623748] xen_allocate_pirq: returning irq 3 for gsi 3
[   12.641472] pnp: PnP ACPI: found 11 devices
[   12.655004] ACPI: ACPI bus type pnp unregistered
[   12.670480] system 00:07: ioport range 0x500-0x57f has been reserved
[   12.691635] system 00:07: ioport range 0x600-0x61f has been reserved
[   12.712799] system 00:07: ioport range 0x880-0x883 has been reserved
[   12.733963] system 00:07: ioport range 0xca4-0xca5 has been reserved
[   12.755125] system 00:07: ioport range 0x400-0x47f has been reserved
[   12.776290] system 00:07: ioport range 0x800-0x81f has been reserved
[   12.797453] system 00:07: ioport range 0xca2-0xca3 has been reserved
[   12.818617] system 00:07: iomem range 0xfed1c000-0xfed3fffe could
not be reserved
[   12.843499] system 00:07: iomem range 0xff000000-0xffffffff could
not be reserved
[   12.868380] system 00:07: iomem range 0xfee00000-0xfeefffff could
not be reserved
[   12.893260] system 00:07: iomem range 0xfe900000-0xfe90001f has been res=
erved
[   12.916999] system 00:07: iomem range 0xfea00000-0xfea0001f has been res=
erved
[   12.940735] system 00:07: iomem range 0xfed1b000-0xfed1bfff has been res=
erved
[   12.964474] system 00:07: iomem range 0xfed14000-0xfed17ffe has been res=
erved
[   12.988211] system 00:07: iomem range 0xfed18000-0xfed18ffe has been res=
erved
[   13.011948] system 00:07: iomem range 0xfed19000-0xfed19ffe has been res=
erved
[   13.040791] PM-Timer failed consistency check  (0x0xffffff) - aborting.
[   13.062258] pci 0000:01:00.0: BAR 6: no parent found for of device
[0xfffe0000-0xffffffff]
[   13.089706] pci 0000:04:00.0: BAR 6: no parent found for of device
[0xffff0000-0xffffffff]
[   13.117229] pci 0000:00:05.0: PCI bridge, secondary bus 0000:01
[   13.136896] pci 0000:00:05.0:   IO window: 0x2000-0x2fff
[   13.154630] pci 0000:00:05.0:   MEM window: 0xb3a00000-0xb3afffff
[   13.174934] pci 0000:00:05.0:   PREFETCH window:
0x000000b0000000-0x000000b1ffffff
[   13.200105] pci 0000:00:1c.0: PCI bridge, secondary bus 0000:02
[   13.219833] pci 0000:00:1c.0:   IO window: disabled
[   13.236139] pci 0000:00:1c.0:   MEM window: disabled
[   13.252725] pci 0000:00:1c.0:   PREFETCH window: disabled
[   13.270747] pci 0000:00:1c.4: PCI bridge, secondary bus 0000:03
[   13.290474] pci 0000:00:1c.4:   IO window: 0x1000-0x1fff
[   13.308211] pci 0000:00:1c.4:   MEM window: 0xb3900000-0xb39fffff
[   13.328512] pci 0000:00:1c.4:   PREFETCH window: disabled
[   13.346535] pci 0000:00:1c.6: PCI bridge, secondary bus 0000:04
[   13.366260] pci 0000:00:1c.6:   IO window: disabled
[   13.382568] pci 0000:00:1c.6:   MEM window: 0xb3000000-0xb38fffff
[   13.402871] pci 0000:00:1c.6:   PREFETCH window:
0x000000b2000000-0x000000b2ffffff
[   13.428042] pci 0000:00:1c.7: PCI bridge, secondary bus 0000:05
[   13.447768] pci 0000:00:1c.7:   IO window: disabled
[   13.464075] pci 0000:00:1c.7:   MEM window: disabled
[   13.480662] pci 0000:00:1c.7:   PREFETCH window: disabled
[   13.498683] pci 0000:00:1e.0: PCI bridge, secondary bus 0000:06
[   13.518410] pci 0000:00:1e.0:   IO window: disabled
[   13.534715] pci 0000:00:1e.0:   MEM window: disabled
[   13.551301] pci 0000:00:1e.0:   PREFETCH window: disabled
[   13.569362] pci 0000:00:05.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
[   13.591642] xen_allocate_pirq: returning irq 16 for gsi 16
[   13.609934] Already setup the GSI :16
[   13.622226] pci 0000:00:1c.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
[   13.644549] xen_allocate_pirq: returning irq 16 for gsi 16
[   13.662868] Already setup the GSI :16
[   13.675158] pci 0000:00:1c.4: PCI INT B -> GSI 16 (level, low) -> IRQ 16
[   13.697497] pci 0000:00:1c.6: PCI INT C -> GSI 18 (level, low) -> IRQ 18
[   13.719804] pci 0000:00:1c.7: PCI INT D -> GSI 19 (level, low) -> IRQ 19
[   13.742154] NET: Registered protocol family 2
[   13.756744] IP route cache hash table entries: 524288 (order: 10,
4194304 bytes)
[   13.781907] TCP established hash table entries: 262144 (order: 10,
4194304 bytes)
[   13.807468] TCP bind hash table entries: 65536 (order: 8, 1048576 bytes)
[   13.829520] TCP: Hash tables configured (established 262144 bind 65536)
[   13.851233] TCP reno registered
[   13.861877] NET: Registered protocol family 1
[   13.876613] RPC: Registered udp transport module.
[   13.892130] RPC: Registered tcp transport module.
[   13.907860] RPC: Registered tcp NFSv4.1 backchannel transport module.
[   13.929669] Trying to unpack rootfs image as initramfs...
[   13.951302] Freeing initrd memory: 4911k freed
[   13.966207] PCI-DMA: Using software bounce buffering for IO (SWIOTLB)
[   13.987093] DMA: Placing 64MB software IO TLB between
ffff880020000000 - ffff880024000000
[   14.014263] DMA: software IO TLB at phys 0x20000000 - 0x24000000
[   14.034354] kvm: no hardware support
[   14.046297] has_svm: not amd
[   14.056017] kvm: no hardware support
[   14.070606] Microcode Update Driver: v2.00
<tigran@aivazian.fsnet.co.uk>, Peter Oruba
[   14.096071] Scanning for low memory corruption every 60 seconds
[   14.116238] audit: initializing netlink socket (disabled)
[   14.133839] type=3D2000 audit(1323876295.119:1): initialized
[   14.166146] HugeTLB registered 2 MB page size, pre-allocated 0 pages
[   14.190435] VFS: Disk quotas dquot_6.5.2
[   14.203141] Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
[   14.225580] msgmni has been set to 1523
[   14.238220] alg: No test for cipher_null (cipher_null-generic)
[   14.257375] alg: No test for ecb(cipher_null) (ecb-cipher_null)
[   14.277104] alg: No test for digest_null (digest_null-generic)
[   14.296552] alg: No test for compress_null (compress_null-generic)
[   14.318199] alg: No test for stdrng (krng)
[   14.331510] Block layer SCSI generic (bsg) driver version 0.4
loaded (major 252)
[   14.355960] io scheduler noop registered
[   14.369119] io scheduler anticipatory registered
[   14.384558] io scheduler deadline registered
[   14.399011] io scheduler cfq registered (default)
[   14.416324] pci_hotplug: PCI Hot Plug PCI Core version: 0.5
[   14.434795] input: Sleep Button as
/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0E:00/input/input0
[   14.462101] ACPI: Sleep Button [SLPB]
[   14.474475] input: Power Button as
/devices/LNXSYSTM:00/LNXPWRBN:00/input/input1
[   14.498985] ACPI: Power Button [PWRF]
[   14.517284] Event-channel device installed.
[   14.532898] blktap_device_init: blktap device major 253
[   14.549785] blktap_ring_init: blktap ring major: 251
[   14.569119] registering netback
[   14.583933] hpet_acpi_add: no address or irqs in _CRS
[   14.600423] Non-volatile memory driver v1.3
[   14.614307] Linux agpgart interface v0.103
[   14.628106] [drm] Initialized drm 1.1.0 20060810
[   14.643467] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
(XEN) irq.c:1139:d0 Cannot bind IRQ 4 to guest. In use by 'ns16550'.
(XEN) irq.c:1139:d0 Cannot bind IRQ 2 to guest. In use by 'cascade'.
(XEN) irq.c:1139:d0 Cannot bind IRQ 4 to guest. In use by 'ns16550'.
(XEN) irq.c:1139:d0 Cannot bind IRQ 2 to guest. In use by 'cascade'.
(XEN) irq.c:1139:d0 Cannot bind IRQ 4 to guest. In use by 'ns16550'.
(XEN) irq.c:1139:d0 Cannot bind IRQ 2 to guest. In use by 'cascade'.
(XEN) irq.c:1139:d0 Cannot bind IRQ 4 to guest. In use by 'ns16550'.
(XEN) irq.c:1139:d0 Cannot bind IRQ 2 to guest. In use by 'cascade'.
[   15.065371] serial8250: ttyS1 at I/O 0x2f8 (irq =3D 3) is a 16550A
[   15.086004] 00:09: ttyS1 at I/O 0x2f8 (irq =3D 3) is a 16550A
[   15.106511] brd: module loaded
[   15.166239] loop: module loaded
[   15.176421] input: Macintosh mouse button emulation as
/devices/virtual/input/input2
[   15.202110] 3ware 9000 Storage Controller device driver for Linux
v2.26.02.012.
[   15.226331] xen_allocate_pirq: returning irq 16 for gsi 16
[   15.244631] Already setup the GSI :16
[   15.256909] 3w-9xxx 0000:01:00.0: PCI INT A -> GSI 16 (level, low) -> IR=
Q 16
[   15.535246] 3w-9xxx: scsi0: AEN: INFO (0x04:0x0053): Battery
capacity test is overdue:.
[   15.662242] scsi0 : 3ware 9000 Storage Controller
[   15.677727] 3w-9xxx: scsi0: Found a 3ware 9000 Storage Controller
at 0xb3a00000, IRQ: 16.
[   16.010243] 3w-9xxx: scsi0: Firmware FH9X 4.10.00.021, BIOS BE9X
4.08.00.003, Ports: 128.
[   16.037272] scsi 0:0:0:0: Direct-Access     AMCC     9690SA-4I
DISK  4.10 PQ: 0 ANSI: 5
[   16.073169] sd 0:0:0:0: [sda] 2929666048 512-byte logical blocks:
(1.49 TB/1.36 TiB)
[   16.077572] sd 0:0:0:0: Attached scsi generic sg0 type 0
[   16.077953] Intel(R) PRO/1000 Network Driver - version 7.3.21-k5-NAPI
[   16.077955] Copyright (c) 1999-2006 Intel Corporation.
[   16.078011] e1000e: Intel(R) PRO/1000 Network Driver - 1.0.2-k2
[   16.078012] e1000e: Copyright (c) 1999-2008 Intel Corporation.
[   16.078055] xen_allocate_pirq: returning irq 16 for gsi 16
[   16.078058] Already setup the GSI :16
[   16.078061] e1000e 0000:00:19.0: PCI INT A -> GSI 16 (level, low) -> IRQ=
 16
[   16.248299] sd 0:0:0:0: [sda] Write Protect is off
[   16.264315] sd 0:0:0:0: [sda] Write cache: enabled, read cache:
enabled, supports DPO and FUA
[   16.293627]  sda: sda1 sda2 < sda5 sda6 sda7 sda8 sda9 >
[   16.362257] sd 0:0:0:0: [sda] Attached SCSI disk
[1032482.485795] IPT FORWARD [NEW INVALID] IN=3Deth0 OUT=3Deth0
PHYSIN=3Dvif2.0 PHYSOUT=3Dpeth0 SRC=3D192.168.40.18 DST=3D80.74.180.217
LEN=3D644 TOS=3D0x00 PREC=3D0x00 TTL=3D64 ID=3D9056 DF PROTO=3DTCP SPT=3D80=
 DPT=3D7629
WINDOW=3D82 RES=3D0x00 ACK PSH URGP=3D0
 __  __            _  _    ___   _
 \ \/ /___ _ __   | || |  / _ \ / |
  \  // _ \ '_ \  | || |_| | | || |
  /  \  __/ | | | |__   _| |_| || |
 /_/\_\___|_| |_|    |_|(_)___(_)_|

(XEN) Xen version 4.0.1 (root@mens-net.private) (gcc version 4.4.5
(Debian 4.4.5-8) ) Fri Dec  2 16:56:12 CET 2011
(XEN) Latest ChangeSet: unavailable
(XEN) Console output is synchronous.
(XEN) Bootloader: GNU GRUB 0.97
(XEN) Command line: dom0_mem=3D2048M max_cstate=3D1 loglvl=3Dall
guest_loglvl=3Dall sync_console com1=3D38400,8n1 console=3Dcom1
(XEN) Video information:
(XEN)  VGA is text mode 80x25, font 8x16
(XEN)  VBE/DDC methods: V2; EDID transfer time: 1 seconds
(XEN) Disc information:
(XEN)  Found 1 MBR signatures
(XEN)  Found 1 EDD information structures
(XEN) Xen-e820 RAM map:
(XEN)  0000000000000000 - 000000000009b800 (usable)
(XEN)  000000000009b800 - 00000000000a0000 (reserved)
(XEN)  00000000000e0000 - 0000000000100000 (reserved)
(XEN)  0000000000100000 - 000000009d8e9000 (usable)
(XEN)  000000009d8e9000 - 000000009d9bb000 (ACPI NVS)
(XEN)  000000009d9bb000 - 000000009f6a4000 (ACPI data)
(XEN)  000000009f6a4000 - 000000009f6df000 (reserved)
(XEN)  000000009f6df000 - 000000009f78a000 (ACPI data)
(XEN)  000000009f78a000 - 000000009f7df000 (ACPI NVS)
(XEN)  000000009f7df000 - 000000009f800000 (ACPI data)
(XEN)  000000009f800000 - 00000000b0000000 (reserved)
(XEN)  00000000fed1c000 - 00000000fed20000 (reserved)
(XEN)  00000000ff800000 - 0000000100000000 (reserved)
(XEN)  0000000100000000 - 0000000460000000 (usable)
(XEN) ACPI: RSDP 000F0410, 0024 (r2 INTEL )
(XEN) ACPI: XSDT 9F7FD120, 008C (r1 INTEL  S3420GPC        0       1000013)
(XEN) ACPI: FACP 9F7FB000, 00F4 (r4 INTEL  S3420GPC        0 MSFT  100000D)
(XEN) ACPI: DSDT 9F7F6000, 4E22 (r2 INTEL  S3420GPC        3 MSFT  100000D)
(XEN) ACPI: FACS 9F78A000, 0040
(XEN) ACPI: APIC 9F7F5000, 00BC (r2 INTEL  S3420GPC        0 MSFT  100000D)
(XEN) ACPI: MCFG 9F7F4000, 003C (r1 INTEL  S3420GPC        1 MSFT  100000D)
(XEN) ACPI: HPET 9F7F3000, 0038 (r1 INTEL  S3420GPC        1 MSFT  100000D)
(XEN) ACPI: SLIT 9F7F2000, 0030 (r1 INTEL  S3420GPC        1 MSFT  100000D)
(XEN) ACPI: SPCR 9F7F1000, 0050 (r1 INTEL  S3420GPC        0 MSFT  100000D)
(XEN) ACPI: WDDT 9F7F0000, 0040 (r1 INTEL  S3420GPC        0 MSFT  100000D)
(XEN) ACPI: SSDT 9F7E5000, AEF4 (r2  INTEL SSDT  PM     4000 INTL 20061109)
(XEN) ACPI: SSDT 9F7E4000, 01D8 (r2  INTEL IPMI         4000 INTL 20061109)
(XEN) ACPI: HEST 9F7E3000, 00A8 (r1 INTEL  S3420GPC        1 INTL        1)
(XEN) ACPI: BERT 9F7E2000, 0030 (r1 INTEL  S3420GPC        1 INTL        1)
(XEN) ACPI: ERST 9F7E1000, 0230 (r1 INTEL  S3420GPC        1 INTL        1)
(XEN) ACPI: EINJ 9F7E0000, 0130 (r1 INTEL  S3420GPC        1 INTL        1)
(XEN) System RAM: 16344MB (16736784kB)
(XEN) No NUMA configuration found
(XEN) Faking a node at 0000000000000000-0000000460000000
(XEN) Domain heap initialised
(XEN) found SMP MP-table at 000fd9a0
(XEN) DMI 2.5 present.
(XEN) Using APIC driver default
(XEN) ACPI: PM-Timer IO Port: 0x408
(XEN) ACPI: ACPI SLEEP INFO: pm1x_cnt[404,0], pm1x_evt[400,0]
(XEN) ACPI:                  wakeup_vec[9f78a00c], vec_size[20]
(XEN) ACPI: Local APIC address 0xfee00000
(XEN) ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
(XEN) Processor #0 7:14 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x02] enabled)
(XEN) Processor #2 7:14 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x02] lapic_id[0x04] enabled)
(XEN) Processor #4 7:14 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x03] lapic_id[0x06] enabled)
(XEN) Processor #6 7:14 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x04] lapic_id[0x01] disabled)
(XEN) ACPI: LAPIC (acpi_id[0x05] lapic_id[0x03] disabled)
(XEN) ACPI: LAPIC (acpi_id[0x06] lapic_id[0x05] disabled)
(XEN) ACPI: LAPIC (acpi_id[0x07] lapic_id[0x07] disabled)
(XEN) ACPI: LAPIC_NMI (acpi_id[0x00] high level lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x01] high level lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x02] high level lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x03] high level lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x04] high level lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x05] high level lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x06] high level lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x07] high level 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: 0x8086a801 base: 0xfed00000
(XEN) PCI: MCFG configuration 0: base a0000000 segment 0 buses 0 - 255
(XEN) PCI: MCFG area at a0000000 reserved in E820
(XEN) Using ACPI (MADT) for SMP configuration information
(XEN) Using scheduler: SMP Credit Scheduler (credit)
(XEN) Detected 2400.040 MHz processor.
(XEN) Initing memory sharing.
(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) EPT supports 2MB super page.
(XEN) HVM: ASIDs enabled.
(XEN) HVM: VMX enabled
(XEN) HVM: Hardware Assisted Paging detected.
(XEN) Intel machine check reporting enabled
(XEN) I/O virtualisation disabled
(XEN) Total of 4 processors activated.
(XEN) ENABLING IO-APIC IRQs
(XEN)  -> Using new ACK method
(XEN) ..TIMER: vector=3D0xF0 apic1=3D0 pin1=3D2 apic2=3D-1 pin2=3D-1
(XEN) TSC is reliable, synchronization unnecessary
(XEN) Platform timer appears to have unexpectedly wrapped 1 times.
(XEN) Platform timer is 14.318MHz HPET
=FF(XEN) Allocated console ring of 32 KiB.
(XEN) microcode.c:73:d32767 microcode: CPU1 resumed
(XEN) microcode.c:73:d32767 microcode: CPU3 resumed
(XEN) Brought up 4 CPUs
(XEN) microcode.c:73:d32767 microcode: CPU2 resumed
(XEN) Turbo Mode detected!
(XEN) HPET: 8 timers in total, 8 timers will be used for broadcast
(XEN) ACPI sleep modes: S3
(XEN) mcheck_poll: Machine check polling timer started.
(XEN) *** LOADING DOMAIN 0 ***
(XEN)  Xen  kernel: 64-bit, lsb, compat32
(XEN)  Dom0 kernel: 64-bit, PAE, lsb, paddr 0x1000000 -> 0x1bfc000
(XEN) PHYSICAL MEMORY ARRANGEMENT:
(XEN)  Dom0 alloc.:   0000000450000000->0000000454000000 (507904 pages
to be allocated)
(XEN) VIRTUAL MEMORY ARRANGEMENT:
(XEN)  Loaded kernel: ffffffff81000000->ffffffff81bfc000
(XEN)  Init. ramdisk: ffffffff81bfc000->ffffffff820c7c00
(XEN)  Phys-Mach map: ffffffff820c8000->ffffffff824c8000
(XEN)  Start info:    ffffffff824c8000->ffffffff824c84b4
(XEN)  Page tables:   ffffffff824c9000->ffffffff824e0000
(XEN)  Boot stack:    ffffffff824e0000->ffffffff824e1000
(XEN)  TOTAL:         ffffffff80000000->ffffffff82800000
(XEN)  ENTRY ADDRESS: ffffffff81976200
(XEN) Dom0 has maximum 4 VCPUs
(XEN) Scrubbing Free RAM:
...........................................................................=
..................................................................done.
(XEN) trace.c:89:d32767 calc_tinfo_first_offset: NR_CPUs 128,
offset_in_bytes 258, t_info_first_offset 65
(XEN) Xen trace buffers: disabled
(XEN) Std. Loglevel: All
(XEN) Guest Loglevel: All
(XEN) **********************************************
(XEN) ******* WARNING: CONSOLE OUTPUT IS SYNCHRONOUS
(XEN) ******* This option is intended to aid debugging of Xen by ensuring
(XEN) ******* that all output is synchronously delivered on the serial line.
(XEN) ******* However it can introduce SIGNIFICANT latencies and affect
(XEN) ******* timekeeping. It is NOT recommended for production use!
(XEN) **********************************************
(XEN) 3... 2... 1...
(XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch
input to Xen)
(XEN) Freed 176kB init memory.
mapping kernel into physical memory
Xen: setup ISA identity maps
about to get started...
[    0.000000] Initializing cgroup subsys cpuset
[    0.000000] Initializing cgroup subsys cpu
[    0.000000] Linux version 2.6.32.47 (root@xenhost-rack2) (gcc
version 4.4.5 (Debian 4.4.5-8) ) #1 SMP Fri Dec 2 13:05:28 CET 2011
[    0.000000] Command line:
root=3DUUID=3D5563bc26-6e98-4768-abee-5ca053e2795c ro nomodeset
max_loop=3D255 console=3Dhvc0 earlyprintk=3Dxen nomodeset initcall_debug
debug loglevel=3D10
[    0.000000] KERNEL supported cpus:
[    0.000000]   Intel GenuineIntel
[    0.000000]   AMD AuthenticAMD
[    0.000000]   Centaur CentaurHauls
[    0.000000] released 0 pages of unused memory
[    0.000000] BIOS-provided physical RAM map:
[    0.000000]  Xen: 0000000000000000 - 000000000009b000 (usable)
[    0.000000]  Xen: 000000000009b800 - 0000000000100000 (reserved)
[    0.000000]  Xen: 0000000000100000 - 0000000080000000 (usable)
[    0.000000]  Xen: 0000000080000000 - 000000009d8e9000 (unusable)
[    0.000000]  Xen: 000000009d8e9000 - 000000009d9bb000 (ACPI NVS)
[    0.000000]  Xen: 000000009d9bb000 - 000000009f6a4000 (ACPI data)
[    0.000000]  Xen: 000000009f6a4000 - 000000009f6df000 (reserved)
[    0.000000]  Xen: 000000009f6df000 - 000000009f78a000 (ACPI data)
[    0.000000]  Xen: 000000009f78a000 - 000000009f7df000 (ACPI NVS)
[    0.000000]  Xen: 000000009f7df000 - 000000009f800000 (ACPI data)
[    0.000000]  Xen: 000000009f800000 - 00000000b0000000 (reserved)
[    0.000000]  Xen: 00000000fec00000 - 00000000fec01000 (reserved)
[    0.000000]  Xen: 00000000fed1c000 - 00000000fed20000 (reserved)
[    0.000000]  Xen: 00000000fee00000 - 00000000fee01000 (reserved)
[    0.000000]  Xen: 00000000ff800000 - 0000000100000000 (reserved)
[    0.000000]  Xen: 0000000100000000 - 000000047d8e9000 (usable)
[    0.000000] bootconsole [xenboot0] enabled
[    0.000000] DMI 2.5 present.
[    0.000000] last_pfn =3D 0x47d8e9 max_arch_pfn =3D 0x400000000
[    0.000000] x86 PAT enabled: cpu 0, old 0x50100070406, new 0x70106000701=
06
[    0.000000] last_pfn =3D 0x80000 max_arch_pfn =3D 0x400000000
[    0.000000] e820 update range: 0000000000001000 - 0000000000006000
(usable) =3D=3D> (reserved)
[    0.000000] Scanning 1 areas for low memory corruption
[    0.000000] modified physical RAM map:
[    0.000000]  modified: 0000000000000000 - 0000000000001000 (usable)
[    0.000000]  modified: 0000000000001000 - 0000000000006000 (reserved)
[    0.000000]  modified: 0000000000006000 - 000000000009b000 (usable)
[    0.000000]  modified: 000000000009b800 - 0000000000100000 (reserved)
[    0.000000]  modified: 0000000000100000 - 0000000080000000 (usable)
[    0.000000]  modified: 0000000080000000 - 000000009d8e9000 (unusable)
[    0.000000]  modified: 000000009d8e9000 - 000000009d9bb000 (ACPI NVS)
[    0.000000]  modified: 000000009d9bb000 - 000000009f6a4000 (ACPI data)
[    0.000000]  modified: 000000009f6a4000 - 000000009f6df000 (reserved)
[    0.000000]  modified: 000000009f6df000 - 000000009f78a000 (ACPI data)
[    0.000000]  modified: 000000009f78a000 - 000000009f7df000 (ACPI NVS)
[    0.000000]  modified: 000000009f7df000 - 000000009f800000 (ACPI data)
[    0.000000]  modified: 000000009f800000 - 00000000b0000000 (reserved)
[    0.000000]  modified: 00000000fec00000 - 00000000fec01000 (reserved)
[    0.000000]  modified: 00000000fed1c000 - 00000000fed20000 (reserved)
[    0.000000]  modified: 00000000fee00000 - 00000000fee01000 (reserved)
[    0.000000]  modified: 00000000ff800000 - 0000000100000000 (reserved)
[    0.000000]  modified: 0000000100000000 - 000000047d8e9000 (usable)
[    0.000000] initial memory mapped : 0 - 020c8000
[    0.000000] init_memory_mapping: 0000000000000000-0000000080000000
[    0.000000]  0000000000 - 0080000000 page 4k
[    0.000000] kernel direct mapping tables up to 80000000 @ 100000-503000
[    0.000000] init_memory_mapping: 0000000100000000-000000047d8e9000
[    0.000000]  0100000000 - 047d8e9000 page 4k
[    0.000000] kernel direct mapping tables up to 47d8e9000 @ 24e0000-48e00=
00
[    0.000000] RAMDISK: 01bfc000 - 020c7c00
[    0.000000] ACPI: RSDP 00000000000f0410 00024 (v02 INTEL )
[    0.000000] ACPI: XSDT 000000009f7fd120 0008C (v01 INTEL  S3420GPC
00000000      01000013)
[    0.000000] ACPI: FACP 000000009f7fb000 000F4 (v04 INTEL  S3420GPC
00000000 MSFT 0100000D)
[    0.000000] ACPI: DSDT 000000009f7f6000 04E22 (v02 INTEL  S3420GPC
00000003 MSFT 0100000D)
[    0.000000] ACPI: FACS 000000009f78a000 00040
[    0.000000] ACPI: APIC 000000009f7f5000 000BC (v02 INTEL  S3420GPC
00000000 MSFT 0100000D)
[    0.000000] ACPI: MCFG 000000009f7f4000 0003C (v01 INTEL  S3420GPC
00000001 MSFT 0100000D)
[    0.000000] ACPI: HPET 000000009f7f3000 00038 (v01 INTEL  S3420GPC
00000001 MSFT 0100000D)
[    0.000000] ACPI: SLIT 000000009f7f2000 00030 (v01 INTEL  S3420GPC
00000001 MSFT 0100000D)
[    0.000000] ACPI: SPCR 000000009f7f1000 00050 (v01 INTEL  S3420GPC
00000000 MSFT 0100000D)
[    0.000000] ACPI: WDDT 000000009f7f0000 00040 (v01 INTEL  S3420GPC
00000000 MSFT 0100000D)
[    0.000000] ACPI: SSDT 000000009f7e5000 0AEF4 (v02  INTEL SSDT  PM
00004000 INTL 20061109)
[    0.000000] ACPI: SSDT 000000009f7e4000 001D8 (v02  INTEL IPMI
00004000 INTL 20061109)
[    0.000000] ACPI: HEST 000000009f7e3000 000A8 (v01 INTEL  S3420GPC
00000001 INTL 00000001)
[    0.000000] ACPI: BERT 000000009f7e2000 00030 (v01 INTEL  S3420GPC
00000001 INTL 00000001)
[    0.000000] ACPI: ERST 000000009f7e1000 00230 (v01 INTEL  S3420GPC
00000001 INTL 00000001)
[    0.000000] ACPI: EINJ 000000009f7e0000 00130 (v01 INTEL  S3420GPC
00000001 INTL 00000001)
[    0.000000] ACPI: Local APIC address 0xfee00000
[    0.000000] (10 early reservations) =3D=3D> bootmem [0000000000 - 047d8e=
9000]
[    0.000000]   #0 [0000000000 - 0000001000]   BIOS data page =3D=3D>
[0000000000 - 0000001000]
[    0.000000]   #1 [00024c9000 - 00024e0000]   XEN PAGETABLES =3D=3D>
[00024c9000 - 00024e0000]
[    0.000000]   #2 [0000006000 - 0000008000]       TRAMPOLINE =3D=3D>
[0000006000 - 0000008000]
[    0.000000]   #3 [0001000000 - 0001ad1474]    TEXT DATA BSS =3D=3D>
[0001000000 - 0001ad1474]
[    0.000000]   #4 [0001bfc000 - 00020c7c00]          RAMDISK =3D=3D>
[0001bfc000 - 00020c7c00]
[    0.000000]   #5 [00020c8000 - 00024c9000]   XEN START INFO =3D=3D>
[00020c8000 - 00024c9000]
[    0.000000]   #6 [0100000000 - 047d8e9000]        XEN EXTRA =3D=3D>
[0100000000 - 047d8e9000]
[    0.000000]   #7 [0001ad2000 - 0001ae036c]              BRK =3D=3D>
[0001ad2000 - 0001ae036c]
[    0.000000]   #8 [0000100000 - 00004e9000]          PGTABLE =3D=3D>
[0000100000 - 00004e9000]
[    0.000000]   #9 [00024e0000 - 00040db000]          PGTABLE =3D=3D>
[00024e0000 - 00040db000]
[    0.000000] found SMP MP-table at [ffff8800000fd9a0] fd9a0
[    0.000000] Zone PFN ranges:
[    0.000000]   DMA      0x00000000 -> 0x00001000
[    0.000000]   DMA32    0x00001000 -> 0x00100000
[    0.000000]   Normal   0x00100000 -> 0x0047d8e9
[    0.000000] Movable zone start PFN for each node
[    0.000000] early_node_map[4] active PFN ranges
[    0.000000]     0: 0x00000000 -> 0x00000001
[    0.000000]     0: 0x00000006 -> 0x0000009b
[    0.000000]     0: 0x00000100 -> 0x00080000
[    0.000000]     0: 0x00100000 -> 0x0047d8e9
[    0.000000] On node 0 totalpages: 4184191
[    0.000000]   DMA zone: 56 pages used for memmap
[    0.000000]   DMA zone: 1004 pages reserved
[    0.000000]   DMA zone: 2930 pages, LIFO batch:0
[    0.000000]   DMA32 zone: 14280 pages used for memmap
[    0.000000]   DMA32 zone: 505912 pages, LIFO batch:31
[    0.000000]   Normal zone: 50040 pages used for memmap
[    0.000000]   Normal zone: 3609969 pages, LIFO batch:31
[    0.000000] ACPI: PM-Timer IO Port: 0x408
[    0.000000] ACPI: Local APIC address 0xfee00000
[    0.000000] ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x02] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x04] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x03] lapic_id[0x06] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x04] lapic_id[0x01] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x05] lapic_id[0x03] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x06] lapic_id[0x05] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x07] lapic_id[0x07] disabled)
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x00] high level lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x01] high level lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x02] high level lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x03] high level lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x04] high level lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x05] high level lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x06] high level lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x07] high level lint[0x1])
[    0.000000] ACPI: IOAPIC (id[0x08] address[0xfec00000] gsi_base[0])
[    0.000000] IOAPIC[0]: apic_id 8, version 0, address 0xfec00000, GSI 0-0
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
[    0.000000] ERROR: Unable to locate IOAPIC for GSI 2
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
[    0.000000] ERROR: Unable to locate IOAPIC for GSI 9
[    0.000000] Using ACPI (MADT) for SMP configuration information
[    0.000000] ACPI: HPET id: 0x8086a801 base: 0xfed00000
[    0.000000] SMP: Allowing 4 CPUs, 0 hotplug CPUs
[    0.000000] nr_irqs_gsi: 256
[    0.000000] PM: Registered nosave memory: 0000000000001000 - 00000000000=
06000
[    0.000000] PM: Registered nosave memory: 000000000009b000 - 00000000000=
9c000
[    0.000000] PM: Registered nosave memory: 000000000009c000 - 00000000001=
00000
[    0.000000] PM: Registered nosave memory: 0000000080000000 - 000000009d8=
e9000
[    0.000000] PM: Registered nosave memory: 000000009d8e9000 - 000000009d9=
bb000
[    0.000000] PM: Registered nosave memory: 000000009d9bb000 - 000000009f6=
a4000
[    0.000000] PM: Registered nosave memory: 000000009f6a4000 - 000000009f6=
df000
[    0.000000] PM: Registered nosave memory: 000000009f6df000 - 000000009f7=
8a000
[    0.000000] PM: Registered nosave memory: 000000009f78a000 - 000000009f7=
df000
[    0.000000] PM: Registered nosave memory: 000000009f7df000 - 000000009f8=
00000
[    0.000000] PM: Registered nosave memory: 000000009f800000 - 00000000b00=
00000
[    0.000000] PM: Registered nosave memory: 00000000b0000000 - 00000000fec=
00000
[    0.000000] PM: Registered nosave memory: 00000000fec00000 - 00000000fec=
01000
[    0.000000] PM: Registered nosave memory: 00000000fec01000 - 00000000fed=
1c000
[    0.000000] PM: Registered nosave memory: 00000000fed1c000 - 00000000fed=
20000
[    0.000000] PM: Registered nosave memory: 00000000fed20000 - 00000000fee=
00000
[    0.000000] PM: Registered nosave memory: 00000000fee00000 - 00000000fee=
01000
[    0.000000] PM: Registered nosave memory: 00000000fee01000 - 00000000ff8=
00000
[    0.000000] PM: Registered nosave memory: 00000000ff800000 - 00000001000=
00000
[    0.000000] Allocating PCI resources starting at b0000000 (gap:
b0000000:4ec00000)
[    0.000000] Booting paravirtualized kernel on Xen
[    0.000000] Xen version: 4.0.1 (preserve-AD) (dom0)
[    0.000000] NR_CPUS:8 nr_cpumask_bits:8 nr_cpu_ids:4 nr_node_ids:1
[    0.000000] PERCPU: Embedded 29 pages/cpu @ffff880028038000 s88536
r8192 d22056 u118784
[    0.000000] pcpu-alloc: s88536 r8192 d22056 u118784 alloc=3D29*4096
[    0.000000] pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3
[   10.311419] Built 1 zonelists in Zone order, mobility grouping on.
Total pages: 4118811
[   10.338004] Kernel command line:
root=3DUUID=3D5563bc26-6e98-4768-abee-5ca053e2795c ro nomodeset
max_loop=3D255 console=3Dhvc0 earlyprintk=3Dxen nomodeset initcall_debug
debug loglevel=3D10
[   10.390120] PID hash table entries: 4096 (order: 3, 32768 bytes)
[   10.411419] Dentry cache hash table entries: 2097152 (order: 12,
16777216 bytes)
[   10.438973] Inode-cache hash table entries: 1048576 (order: 11,
8388608 bytes)
[   10.464013] Initializing CPU#0
[   10.480240] DMA: Placing 64MB software IO TLB between
ffff880020000000 - ffff880024000000
[   10.506573] DMA: software IO TLB at phys 0x20000000 - 0x24000000
[   10.526301] xen_swiotlb_fixup: buf=3Dffff880020000000 size=3D67108864
[   10.564039] xen_swiotlb_fixup: buf=3Dffff880024060000 size=3D32768
[   10.590216] Memory: 1722512k/18834340k available (5877k kernel
code, 2097576k absent, 15013600k reserved, 3717k data, 568k init)
[   10.627713] SLUB: Genslabs=3D13, HWalign=3D64, Order=3D0-3, MinObjects=
=3D0,
CPUs=3D4, Nodes=3D1
[   10.652877] Hierarchical RCU implementation.
[   10.666880] NR_IRQS:4352 nr_irqs:1280
[   10.678959] xen: --> irq=3D0
[   10.687790] xen: --> irq=3D1
[   10.696651] xen: --> irq=3D2
[   10.705516] xen: --> irq=3D3
[   10.714382] xen: --> irq=3D4
[   10.723247] xen: --> irq=3D5
[   10.732113] xen: --> irq=3D6
[   10.740979] xen: --> irq=3D7
[   10.749844] xen: --> irq=3D8
[   10.758711] xen: --> irq=3D9
[   10.767577] xen: --> irq=3D10
[   10.776728] xen: --> irq=3D11
[   10.785880] xen: --> irq=3D12
[   10.795031] xen: --> irq=3D13
[   10.804183] xen: --> irq=3D14
[   10.813336] xen: --> irq=3D15
[   10.822497] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
[   10.843363] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
[   10.865097] xen: sci override: source_irq=3D9 global_irq=3D9 trigger=3Dc=
 polarity=3D1
[   10.888550] xen: registering gsi 9 triggering 0 polarity 0
[   10.906566] xen_allocate_pirq: returning irq 9 for gsi 9
[   10.924012] xen: --> irq=3D9
[   10.932880] xen: acpi sci 9
[   10.952809] Console: colour VGA+ 80x25
[   10.964550] console [hvc0] enabled, bootconsole disabled
[   10.964550] console [hvc0] enabled, bootconsole disabled
[   10.999734] Xen: using vcpuop timer interface
[   11.014307] installing Xen timer for CPU 0
[   11.028044]   alloc irq_desc for 1279 on node -1
[   11.043477]   alloc kstat_irqs on node -1
[   11.056938] Detected 2400.040 MHz processor.
[   11.071222] Calibrating delay loop (skipped), value calculated
using timer frequency.. 4800.08 BogoMIPS (lpj=3D2400040)
[   11.106407] Security Framework initialized
[   11.120129] SELinux:  Initializing.
[   11.131853] SELinux:  Starting in permissive mode
[   11.147581] Mount-cache hash table entries: 256
[   11.162872] Initializing cgroup subsys ns
[   11.176183] Initializing cgroup subsys cpuacct
[   11.191051] Initializing cgroup subsys freezer
[   11.205950] CPU: L1 I cache: 32K, L1 D cache: 32K
[   11.221649] CPU: L2 cache: 256K
[   11.232231] CPU: L3 cache: 8192K
[   11.243104] CPU: Unsupported number of siblings 16
[   11.258262] mce: CPU supports 9 MCE banks
[   11.272583] Performance Events: unsupported p6 CPU model 30 no PMU
driver, software events only.
[   11.301735] SMP alternatives: switching to UP code
[   11.354691] ACPI: Core revision 20090903
[   11.387437]   alloc irq_desc for 1278 on node -1
[   11.402317]   alloc kstat_irqs on node -1
[   11.415771]   alloc irq_desc for 1277 on node -1
[   11.431203]   alloc kstat_irqs on node -1
[   11.444653]   alloc irq_desc for 1276 on node -1
[   11.460086]   alloc kstat_irqs on node -1
[   11.473539]   alloc irq_desc for 1275 on node -1
[   11.488972]   alloc kstat_irqs on node -1
[   11.502443] calling  migration_init+0x0/0x5a @ 1
[   11.517890] initcall migration_init+0x0/0x5a returned 0 after 976 usecs
[   11.539884] calling  spawn_ksoftirqd+0x0/0x59 @ 1
[   11.555630] initcall spawn_ksoftirqd+0x0/0x59 returned 0 after 976 usecs
[   11.577922] calling  init_call_single_data+0x0/0x89 @ 1
[   11.595367] initcall init_call_single_data+0x0/0x89 returned 0 after 0 u=
secs
[   11.618815] calling  relay_init+0x0/0x14 @ 1
[   11.633112] initcall relay_init+0x0/0x14 returned 0 after 0 usecs
[   11.653418] calling  tracer_alloc_buffers+0x0/0x173 @ 1
[   11.670885] initcall tracer_alloc_buffers+0x0/0x173 returned 0 after 0 u=
secs
[   11.694344] calling  init_trace_printk+0x0/0x12 @ 1
[   11.710647] initcall init_trace_printk+0x0/0x12 returned 0 after 0 usecs
[   11.732958] calling  mce_amd_init+0x0/0x33 @ 1
[   11.747824] initcall mce_amd_init+0x0/0x33 returned 0 after 0 usecs
[   11.768745] installing Xen timer for CPU 1
[   11.782435]   alloc irq_desc for 1274 on node -1
[   11.797872]   alloc kstat_irqs on node -1
[   11.811342] SMP alternatives: switching to SMP code
[   11.863556]   alloc irq_desc for 1273 on node -1
[   11.878435]   alloc kstat_irqs on node -1
[   11.891891]   alloc irq_desc for 1272 on node -1
[   11.907322]   alloc kstat_irqs on node -1
[   11.920773]   alloc irq_desc for 1271 on node -1
[   11.936207]   alloc kstat_irqs on node -1
[   11.949657]   alloc irq_desc for 1270 on node -1
[   11.965092]   alloc kstat_irqs on node -1
[   11.978549] Initializing CPU#1
[   11.978585] CPU: L1 I cache: 32K, L1 D cache: 32K
[   11.978587] CPU: L2 cache: 256K
[   11.978589] CPU: L3 cache: 8192K
[   11.978592] CPU: Unsupported number of siblings 16
[   11.978669] installing Xen timer for CPU 2
[   12.055756]   alloc irq_desc for 1269 on node -1
[   12.071195]   alloc kstat_irqs on node -1
[   12.084662]   alloc irq_desc for 1268 on node -1
[   12.100080]   alloc kstat_irqs on node -1
[   12.113533]   alloc irq_desc for 1267 on node -1
[   12.128965]   alloc kstat_irqs on node -1
[   12.142416]   alloc irq_desc for 1266 on node -1
[   12.157851]   alloc kstat_irqs on node -1
[   12.171305]   alloc irq_desc for 1265 on node -1
[   12.186735]   alloc kstat_irqs on node -1
[   12.200192] Initializing CPU#2
[   12.200226] CPU: L1 I cache: 32K, L1 D cache: 32K
[   12.200228] CPU: L2 cache: 256K
[   12.200229] CPU: L3 cache: 8192K
[   12.200233] CPU: Unsupported number of siblings 16
[   12.200303] installing Xen timer for CPU 3
[   12.277400]   alloc irq_desc for 1264 on node -1
[   12.292839]   alloc kstat_irqs on node -1
[   12.306306]   alloc irq_desc for 1263 on node -1
[   12.321723]   alloc kstat_irqs on node -1
[   12.335176]   alloc irq_desc for 1262 on node -1
[   12.350609]   alloc kstat_irqs on node -1
[   12.364060]   alloc irq_desc for 1261 on node -1
[   12.379495]   alloc kstat_irqs on node -1
[   12.392945]   alloc irq_desc for 1260 on node -1
[   12.408378]   alloc kstat_irqs on node -1
[   12.421836] Initializing CPU#3
[   12.421869] CPU: L1 I cache: 32K, L1 D cache: 32K
[   12.421871] CPU: L2 cache: 256K
[   12.421873] CPU: L3 cache: 8192K
[   12.421876] CPU: Unsupported number of siblings 16
[   12.421909] Brought up 4 CPUs
[   12.495792] calling  init_mmap_min_addr+0x0/0x26 @ 1
[   12.511910] initcall init_mmap_min_addr+0x0/0x26 returned 0 after 0 usecs
[   12.534507] calling  init_cpufreq_transition_notifier_list+0x0/0x1b @ 1
[   12.556528] initcall init_cpufreq_transition_notifier_list+0x0/0x1b
returned 0 after 0 usecs
[   12.584552] calling  net_ns_init+0x0/0xed @ 1
[   12.599178] initcall net_ns_init+0x0/0xed returned 0 after 976 usecs
[   12.620301] calling  e820_mark_nvs_memory+0x0/0x40 @ 1
[   12.637520] initcall e820_mark_nvs_memory+0x0/0x40 returned 0 after 976 =
usecs
[   12.661198] calling  cpufreq_tsc+0x0/0x28 @ 1
[   12.675782] initcall cpufreq_tsc+0x0/0x28 returned 0 after 0 usecs
[   12.696404] calling  pci_reboot_init+0x0/0x14 @ 1
[   12.712134] initcall pci_reboot_init+0x0/0x14 returned 0 after 0 usecs
[   12.733873] calling  init_lapic_sysfs+0x0/0x2d @ 1
[   12.749974] initcall init_lapic_sysfs+0x0/0x2d returned 0 after 976 usecs
[   12.772483] calling  alloc_frozen_cpus+0x0/0x8 @ 1
[   12.788492] initcall alloc_frozen_cpus+0x0/0x8 returned 0 after 0 usecs
[   12.810517] calling  sysctl_init+0x0/0x32 @ 1
[   12.825200] initcall sysctl_init+0x0/0x32 returned 0 after 0 usecs
[   12.845691] calling  ksysfs_init+0x0/0x94 @ 1
[   12.860281] initcall ksysfs_init+0x0/0x94 returned 0 after 0 usecs
[   12.880867] calling  async_init+0x0/0x60 @ 1
[   12.895198] initcall async_init+0x0/0x60 returned 0 after 976 usecs
[   12.916045] calling  init_jiffies_clocksource+0x0/0x12 @ 1
[   12.934353] initcall init_jiffies_clocksource+0x0/0x12 returned 0
after 0 usecs
[   12.958658] calling  pm_init+0x0/0x34 @ 1
[   12.972106] initcall pm_init+0x0/0x34 returned 0 after 0 usecs
[   12.991545] calling  pm_disk_init+0x0/0x19 @ 1
[   13.006420] initcall pm_disk_init+0x0/0x19 returned 0 after 0 usecs
[   13.027297] calling  swsusp_header_init+0x0/0x2c @ 1
[   13.043884] initcall swsusp_header_init+0x0/0x2c returned 0 after 0 usecs
[   13.066480] calling  init_zero_pfn+0x0/0x68 @ 1
[   13.081635] initcall init_zero_pfn+0x0/0x68 returned 0 after 0 usecs
[   13.102796] calling  filelock_init+0x0/0x2e @ 1
[   13.117956] initcall filelock_init+0x0/0x2e returned 0 after 0 usecs
[   13.139118] calling  init_misc_binfmt+0x0/0x44 @ 1
[   13.155134] initcall init_misc_binfmt+0x0/0x44 returned 0 after 0 usecs
[   13.177159] calling  init_script_binfmt+0x0/0x14 @ 1
[   13.193742] initcall init_script_binfmt+0x0/0x14 returned 0 after 0 usecs
[   13.216340] calling  init_elf_binfmt+0x0/0x14 @ 1
[   13.232066] initcall init_elf_binfmt+0x0/0x14 returned 0 after 0 usecs
[   13.253804] calling  init_compat_elf_binfmt+0x0/0x14 @ 1
[   13.271536] initcall init_compat_elf_binfmt+0x0/0x14 returned 0 after 0 =
usecs
[   13.295271] calling  debugfs_init+0x0/0x5c @ 1
[   13.310142] initcall debugfs_init+0x0/0x5c returned 0 after 0 usecs
[   13.331018] calling  random32_init+0x0/0xd8 @ 1
[   13.346177] initcall random32_init+0x0/0xd8 returned 0 after 0 usecs
[   13.367341] calling  __gnttab_init+0x0/0x21 @ 1
[   13.382510] Grant table initialized
[   13.394222] initcall __gnttab_init+0x0/0x21 returned 0 after 976 usecs
[   13.415964] calling  early_resume_init+0x0/0x19e @ 1
[   13.432573] Time: 16:33:26  Date: 12/14/11
[   13.446278] initcall early_resume_init+0x0/0x19e returned 0 after 0 usecs
[   13.468870] calling  cpufreq_core_init+0x0/0x9b @ 1
[   13.485170] initcall cpufreq_core_init+0x0/0x9b returned 0 after 0 usecs
[   13.507478] calling  cpuidle_init+0x0/0x40 @ 1
[   13.522348] initcall cpuidle_init+0x0/0x40 returned 0 after 0 usecs
[   13.543225] calling  sock_init+0x0/0x5e @ 1
[   13.557277] initcall sock_init+0x0/0x5e returned 0 after 976 usecs
[   13.577829] calling  net_inuse_init+0x0/0x26 @ 1
[   13.593274] initcall net_inuse_init+0x0/0x26 returned 0 after 0 usecs
[   13.614725] calling  netpoll_init+0x0/0x31 @ 1
[   13.629595] initcall netpoll_init+0x0/0x31 returned 0 after 0 usecs
[   13.650471] calling  netlink_proto_init+0x0/0x143 @ 1
[   13.667352] NET: Registered protocol family 16
[   13.682228] initcall netlink_proto_init+0x0/0x143 returned 0 after 976 u=
secs
[   13.705696] calling  bdi_class_init+0x0/0x41 @ 1
[   13.721200] initcall bdi_class_init+0x0/0x41 returned 0 after 976 usecs
[   13.743167] calling  kobject_uevent_init+0x0/0x54 @ 1
[   13.760046] initcall kobject_uevent_init+0x0/0x54 returned 0 after 976 u=
secs
[   13.783487] calling  pcibus_class_init+0x0/0x19 @ 1
[   13.799837] initcall pcibus_class_init+0x0/0x19 returned 0 after 976 use=
cs
[   13.822672] calling  pci_driver_init+0x0/0x12 @ 1
[   13.838455] initcall pci_driver_init+0x0/0x12 returned 0 after 976 usecs
[   13.860709] calling  backlight_class_init+0x0/0x5d @ 1
[   13.877914] initcall backlight_class_init+0x0/0x5d returned 0 after 976 =
usecs
[   13.901601] calling  video_output_class_init+0x0/0x19 @ 1
[   13.919669] initcall video_output_class_init+0x0/0x19 returned 0
after 976 usecs
[   13.944214] calling  xenbus_init+0x0/0x2c7 @ 1
[   13.959092]   alloc irq_desc for 1259 on node -1
[   13.974528]   alloc kstat_irqs on node -1
[   13.988039] initcall xenbus_init+0x0/0x2c7 returned 0 after 1952 usecs
[   14.009710] calling  tty_class_init+0x0/0x38 @ 1
[   14.025196] initcall tty_class_init+0x0/0x38 returned 0 after 976 usecs
[   14.047175] calling  vtconsole_class_init+0x0/0xc2 @ 1
[   14.064437] initcall vtconsole_class_init+0x0/0xc2 returned 0 after 976 =
usecs
[   14.088067] calling  i2c_init+0x0/0x6a @ 1
[   14.101898] initcall i2c_init+0x0/0x6a returned 0 after 976 usecs
[   14.122102] calling  amd_postcore_init+0x0/0x77 @ 1
[   14.138403] initcall amd_postcore_init+0x0/0x77 returned 0 after 0 usecs
[   14.160713] calling  arch_kdebugfs_init+0x0/0x235 @ 1
[   14.177595] initcall arch_kdebugfs_init+0x0/0x235 returned 0 after 0 use=
cs
[   14.200467] calling  mtrr_if_init+0x0/0x61 @ 1
[   14.215336] initcall mtrr_if_init+0x0/0x61 returned 0 after 0 usecs
[   14.236213] calling  ffh_cstate_init+0x0/0x2a @ 1
[   14.251943] initcall ffh_cstate_init+0x0/0x2a returned 0 after 0 usecs
[   14.273681] calling  acpi_pci_init+0x0/0x57 @ 1
[   14.288832] ACPI FADT declares the system doesn't support PCIe
ASPM, so disable it
[   14.314001] ACPI: bus type pci registered
[   14.327447] initcall acpi_pci_init+0x0/0x57 returned 0 after 0 usecs
[   14.348607] calling  xen_pcpu_init+0x0/0xa8 @ 1
[   14.363859] sync cpu 0 get result 1 max_id 3
[   14.378115] sync cpu 1 get result 1 max_id 3
[   14.392415] sync cpu 2 get result 1 max_id 3
[   14.406714] sync cpu 3 get result 1 max_id 3
[   14.420961]   alloc irq_desc for 1258 on node -1
[   14.436404]   alloc kstat_irqs on node -1
[   14.449863] initcall xen_pcpu_init+0x0/0xa8 returned 1258 after 4882 use=
cs
[   14.472731] initcall xen_pcpu_init+0x0/0xa8 returned with error code 1258
[   14.495610] calling  register_xen_pci_notifier+0x0/0x24 @ 1
[   14.514200] initcall register_xen_pci_notifier+0x0/0x24 returned 0
after 0 usecs
[   14.538789] calling  setup_vcpu_hotplug_event+0x0/0x22 @ 1
[   14.557098] initcall setup_vcpu_hotplug_event+0x0/0x22 returned 0
after 0 usecs
[   14.581402] calling  dmi_id_init+0x0/0x319 @ 1
[   14.596397] initcall dmi_id_init+0x0/0x319 returned 0 after 976 usecs
[   14.617729] calling  pci_arch_init+0x0/0x60 @ 1
[   14.632913] PCI: MCFG configuration 0: base a0000000 segment 0 buses 0 -=
 255
[   14.656332] PCI: MCFG area at a0000000 reserved in E820
[   14.697586] PCI: Using MMCONFIG at a0000000 - afffffff
[   14.714186] PCI: Using configuration type 1 for base access
[   14.732781] initcall pci_arch_init+0x0/0x60 returned 0 after 21481 usecs
[   14.755084] calling  topology_init+0x0/0x40 @ 1
[   14.770429] initcall topology_init+0x0/0x40 returned 0 after 976 usecs
[   14.791977] calling  mtrr_init_finialize+0x0/0x3d @ 1
[   14.808851] initcall mtrr_init_finialize+0x0/0x3d returned 0 after 0 use=
cs
[   14.831730] calling  param_sysfs_init+0x0/0x224 @ 1
[   14.859267] initcall param_sysfs_init+0x0/0x224 returned 0 after 11716 u=
secs
[   14.882156] calling  pm_sysrq_init+0x0/0x19 @ 1
[   14.897314] initcall pm_sysrq_init+0x0/0x19 returned 0 after 0 usecs
[   14.918478] calling  audit_watch_init+0x0/0x2f @ 1
[   14.934494] initcall audit_watch_init+0x0/0x2f returned 0 after 0 usecs
[   14.956518] calling  init_slow_work+0x0/0x3e @ 1
[   14.971958] initcall init_slow_work+0x0/0x3e returned 0 after 0 usecs
[   14.993411] calling  default_bdi_init+0x0/0xb1 @ 1
[   15.009543] initcall default_bdi_init+0x0/0xb1 returned 0 after 976 usecs
[   15.032019] calling  init_bio+0x0/0xda @ 1
[   15.045750] bio: create slab <bio-0> at 0
[   15.059189] initcall init_bio+0x0/0xda returned 0 after 0 usecs
[   15.078917] calling  fsnotify_init+0x0/0x12 @ 1
[   15.094076] initcall fsnotify_init+0x0/0x12 returned 0 after 0 usecs
[   15.115239] calling  fsnotify_notification_init+0x0/0xf0 @ 1
[   15.134117] initcall fsnotify_notification_init+0x0/0xf0 returned 0
after 0 usecs
[   15.158995] calling  cryptomgr_init+0x0/0x12 @ 1
[   15.174440] initcall cryptomgr_init+0x0/0x12 returned 0 after 0 usecs
[   15.195894] calling  blk_settings_init+0x0/0x2a @ 1
[   15.212191] initcall blk_settings_init+0x0/0x2a returned 0 after 0 usecs
[   15.234502] calling  blk_ioc_init+0x0/0x2a @ 1
[   15.249370] initcall blk_ioc_init+0x0/0x2a returned 0 after 0 usecs
[   15.270246] calling  blk_softirq_init+0x0/0x6e @ 1
[   15.286263] initcall blk_softirq_init+0x0/0x6e returned 0 after 0 usecs
[   15.308287] calling  blk_iopoll_setup+0x0/0x6e @ 1
[   15.324301] initcall blk_iopoll_setup+0x0/0x6e returned 0 after 0 usecs
[   15.346324] calling  genhd_device_init+0x0/0x7b @ 1
[   15.362769] initcall genhd_device_init+0x0/0x7b returned 0 after 976 use=
cs
[   15.385507] calling  pci_slot_init+0x0/0x46 @ 1
[   15.400661] initcall pci_slot_init+0x0/0x46 returned 0 after 0 usecs
[   15.421822] calling  fbmem_init+0x0/0x98 @ 1
[   15.436175] initcall fbmem_init+0x0/0x98 returned 0 after 976 usecs
[   15.457000] calling  acpi_init+0x0/0x130 @ 1
[   15.472585] ERROR: Unable to locate IOAPIC for GSI 9
[   15.488638] ACPI: EC: Look up EC in DSDT
[   15.502971] ACPI Error: Field [CPB3] at 96 exceeds Buffer [NULL]
size 64 (bits) (20090903/dsopcode-596)
[   15.533587] ACPI Error (psparse-0537): Method parse/execution
failed [\_SB_._OSC] (Node ffff88007fc187c0), AE_AML_BUFFER_LIMIT
[   15.594403] ACPI: Interpreter enabled
[   15.606143] ACPI: (supports S0 S1 S5)
[   15.618442] ACPI: Using IOAPIC for interrupt routing
[   15.647695] initcall acpi_init+0x0/0x130 returned 0 after 38080 usecs
[   15.668586] calling  dock_init+0x0/0x8d @ 1
[   15.682694] ACPI: No dock devices found.
[   15.695785] initcall dock_init+0x0/0x8d returned 0 after 0 usecs
[   15.715799] calling  acpi_pci_root_init+0x0/0x28 @ 1
[   15.733153] ACPI: PCI Root Bridge [PCI0] (0000:00)
[   15.748882] pci 0000:00:05.0: PME# supported from D0 D3hot D3cold
[   15.768915] pci 0000:00:05.0: PME# disabled
[   15.783492] pci 0000:00:19.0: reg 10 32bit mmio: [0xb3b00000-0xb3b1ffff]
[   15.805249] pci 0000:00:19.0: reg 14 32bit mmio: [0xb3b24000-0xb3b24fff]
[   15.827556] pci 0000:00:19.0: reg 18 io port: [0x3020-0x303f]
[   15.846775] pci 0000:00:19.0: PME# supported from D0 D3hot D3cold
[   15.867015] pci 0000:00:19.0: PME# disabled
[   15.881118] pci 0000:00:1a.0: reg 10 32bit mmio: [0xb3b21000-0xb3b213ff]
[   15.903426] pci 0000:00:1a.0: PME# supported from D0 D3hot D3cold
[   15.923642] pci 0000:00:1a.0: PME# disabled
[   15.937766] pci 0000:00:1c.0: PME# supported from D0 D3hot D3cold
[   15.957960] pci 0000:00:1c.0: PME# disabled
[   15.972088] pci 0000:00:1c.4: PME# supported from D0 D3hot D3cold
[   15.992278] pci 0000:00:1c.4: PME# disabled
[   16.006403] pci 0000:00:1c.6: PME# supported from D0 D3hot D3cold
[   16.026599] pci 0000:00:1c.6: PME# disabled
[   16.040723] pci 0000:00:1c.7: PME# supported from D0 D3hot D3cold
[   16.060917] pci 0000:00:1c.7: PME# disabled
[   16.075015] pci 0000:00:1d.0: reg 10 32bit mmio: [0xb3b20000-0xb3b203ff]
[   16.097329] pci 0000:00:1d.0: PME# supported from D0 D3hot D3cold
[   16.117544] pci 0000:00:1d.0: PME# disabled
[   16.131828] pci 0000:00:1f.3: reg 10 64bit mmio: [0xb3b22000-0xb3b220ff]
[   16.153885] pci 0000:00:1f.3: reg 20 io port: [0x3000-0x301f]
[   16.173110] pci 0000:01:00.0: reg 10 64bit mmio pref: [0xb0000000-0xb1ff=
ffff]
[   16.196774] pci 0000:01:00.0: reg 18 64bit mmio: [0xb3a00000-0xb3a00fff]
[   16.219078] pci 0000:01:00.0: reg 20 io port: [0x2000-0x20ff]
[   16.238242] pci 0000:01:00.0: reg 30 32bit mmio pref: [0xfffe0000-0xffff=
ffff]
[   16.262001] pci 0000:01:00.0: supports D1 D2
[   16.276323] pci 0000:00:05.0: bridge io port: [0x2000-0x2fff]
[   16.295430] pci 0000:00:05.0: bridge 32bit mmio: [0xb3a00000-0xb3afffff]
[   16.317745] pci 0000:00:05.0: bridge 64bit mmio pref: [0xb0000000-0xb1ff=
ffff]
[   16.341634] pci 0000:03:00.0: reg 10 32bit mmio: [0xb3900000-0xb391ffff]
[   16.363808] pci 0000:03:00.0: reg 18 io port: [0x1000-0x101f]
[   16.382952] pci 0000:03:00.0: reg 1c 32bit mmio: [0xb3920000-0xb3923fff]
[   16.405360] pci 0000:03:00.0: PME# supported from D0 D3hot D3cold
[   16.425559] pci 0000:03:00.0: PME# disabled
[   16.439662] pci 0000:00:1c.4: bridge io port: [0x1000-0x1fff]
[   16.458732] pci 0000:00:1c.4: bridge 32bit mmio: [0xb3900000-0xb39fffff]
[   16.481112] pci 0000:04:00.0: reg 10 32bit mmio pref: [0xb2000000-0xb2ff=
ffff]
[   16.504785] pci 0000:04:00.0: reg 14 32bit mmio: [0xb3800000-0xb3803fff]
[   16.527095] pci 0000:04:00.0: reg 18 32bit mmio: [0xb3000000-0xb37fffff]
[   16.549435] pci 0000:04:00.0: reg 30 32bit mmio pref: [0xffff0000-0xffff=
ffff]
[   16.573258] pci 0000:00:1c.6: bridge 32bit mmio: [0xb3000000-0xb38fffff]
[   16.595443] pci 0000:00:1c.6: bridge 64bit mmio pref: [0xb2000000-0xb2ff=
ffff]
[   16.619320] pci 0000:00:1e.0: transparent bridge
[   16.634669] pci_bus 0000:00: on NUMA node 0
[   16.648633] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
[   16.668734] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.MRP3._PRT]
[   16.689623] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PEX0._PRT]
[   16.710806] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PEX4._PRT]
[   16.731922] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PEX6._PRT]
[   16.753123] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.IP2P._PRT]
(XEN) PCI add device 00:00.0
(XEN) PCI add device 00:05.0
(XEN) PCI add device 00:08.0
(XEN) PCI add device 00:08.1
(XEN) PCI add device 00:08.2
(XEN) PCI add device 00:08.3
(XEN) PCI add device 00:10.0
(XEN) PCI add device 00:10.1
(XEN) PCI add device 00:19.0
(XEN) PCI add device 00:1a.0
(XEN) PCI add device 00:1c.0
(XEN) PCI add device 00:1c.4
(XEN) PCI add device 00:1c.6
(XEN) PCI add device 00:1c.7
(XEN) PCI add device 00:1d.0
(XEN) PCI add device 00:1e.0
(XEN) PCI add device 00:1f.0
(XEN) PCI add device 00:1f.3
(XEN) PCI add device 01:00.0
(XEN) PCI add device 03:00.0
(XEN) PCI add device 04:00.0
[   16.954739] initcall acpi_pci_root_init+0x0/0x28 returned 0 after 25386 =
usecs
[   16.978208] calling  acpi_pci_link_init+0x0/0x43 @ 1
[   16.994873] ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 9 *10
11 12 14 15)
[   17.018917] ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 9 10
*11 12 14 15)
[   17.042938] ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 *5 6 7 9 10
11 12 14 15)
[   17.066986] ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 7 9 10
*11 12 14 15)
[   17.090987] ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 7 9 10 11
12 14 15) *0, disabled.
[   17.118722] ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 6 7 *9 10
11 12 14 15)
[   17.142750] ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 6 7 9 10 11
12 14 15) *0, disabled.
[   17.170486] ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 6 7 9 *10
11 12 14 15)
[   17.194505] initcall acpi_pci_link_init+0x0/0x43 returned 0 after 1952 u=
secs
[   17.217868] calling  pnp_init+0x0/0x12 @ 1
[   17.231652] initcall pnp_init+0x0/0x12 returned 0 after 976 usecs
[   17.251902] calling  xen_setup_shutdown_event+0x0/0x22 @ 1
[   17.270209] initcall xen_setup_shutdown_event+0x0/0x22 returned 0
after 0 usecs
[   17.294515] calling  xenbus_probe_backend_init+0x0/0x2d @ 1
[   17.313159] initcall xenbus_probe_backend_init+0x0/0x2d returned 0
after 976 usecs
[   17.338271] calling  xenbus_probe_frontend_init+0x0/0x2d @ 1
[   17.357196] initcall xenbus_probe_frontend_init+0x0/0x2d returned 0
after 976 usecs
[   17.382600] calling  balloon_init+0x0/0x279 @ 1
[   17.397757] xen_balloon: Initialising balloon driver with page order 0.
[   17.419876] last_pfn =3D 0x47d8e9 max_arch_pfn =3D 0x400000000
[   17.484316] initcall balloon_init+0x0/0x279 returned 0 after 41985 usecs
[   17.506067] calling  xen_acpi_processor_extcntl_init+0x0/0x4f @ 1
[   17.526369] initcall xen_acpi_processor_extcntl_init+0x0/0x4f
returned 0 after 0 usecs
[   17.552683] calling  misc_init+0x0/0xb7 @ 1
[   17.566811] initcall misc_init+0x0/0xb7 returned 0 after 976 usecs
[   17.587284] calling  vga_arb_device_init+0x0/0x80 @ 1
[   17.604246] vgaarb: device added:
PCI:0000:04:00.0,decodes=3Dio+mem,owns=3Dio+mem,locks=3Dnone
[   17.631044] vgaarb: loaded
[   17.640197] initcall vga_arb_device_init+0x0/0x80 returned 0 after 976 u=
secs
[   17.663645] calling  cn_init+0x0/0x9e @ 1
[   17.677103] initcall cn_init+0x0/0x9e returned 0 after 976 usecs
[   17.697134] calling  init_scsi+0x0/0x8c @ 1
[   17.711359] SCSI subsystem initialized
[   17.723736] initcall init_scsi+0x0/0x8c returned 0 after 976 usecs
[   17.744322] calling  ata_init+0x0/0x351 @ 1
[   17.758476] libata version 3.00 loaded.
[   17.771209] initcall ata_init+0x0/0x351 returned 0 after 976 usecs
[   17.791796] calling  phy_init+0x0/0x2e @ 1
[   17.805682] initcall phy_init+0x0/0x2e returned 0 after 976 usecs
[   17.825831] calling  init_pcmcia_cs+0x0/0x36 @ 1
[   17.841321] initcall init_pcmcia_cs+0x0/0x36 returned 0 after 976 usecs
[   17.863299] calling  usb_init+0x0/0x1a9 @ 1
[   17.877459] usbcore: registered new interface driver usbfs
[   17.895670] usbcore: registered new interface driver hub
[   17.913426] usbcore: registered new device driver usb
[   17.930222] initcall usb_init+0x0/0x1a9 returned 0 after 2929 usecs
[   17.951094] calling  serio_init+0x0/0x86 @ 1
[   17.965470] initcall serio_init+0x0/0x86 returned 0 after 976 usecs
[   17.986271] calling  input_init+0x0/0x13c @ 1
[   18.000910] initcall input_init+0x0/0x13c returned 0 after 976 usecs
[   18.022019] calling  rtc_init+0x0/0x71 @ 1
[   18.035799] initcall rtc_init+0x0/0x71 returned 0 after 976 usecs
[   18.056053] calling  power_supply_class_init+0x0/0x38 @ 1
[   18.074122] initcall power_supply_class_init+0x0/0x38 returned 0
after 976 usecs
[   18.098665] calling  hwmon_init+0x0/0x106 @ 1
[   18.113300] initcall hwmon_init+0x0/0x106 returned 0 after 976 usecs
[   18.134415] calling  thermal_init+0x0/0x3f @ 1
[   18.149333] initcall thermal_init+0x0/0x3f returned 0 after 976 usecs
[   18.170740] calling  md_init+0x0/0xd0 @ 1
[   18.184189] initcall md_init+0x0/0xd0 returned 0 after 0 usecs
[   18.203625] calling  leds_init+0x0/0x40 @ 1
[   18.217690] initcall leds_init+0x0/0x40 returned 0 after 976 usecs
[   18.238230] calling  pci_subsys_init+0x0/0x107 @ 1
[   18.254244] PCI: Using ACPI for IRQ routing
[   18.268366] initcall pci_subsys_init+0x0/0x107 returned 0 after 0 usecs
[   18.290284] calling  proto_init+0x0/0x12 @ 1
[   18.304581] initcall proto_init+0x0/0x12 returned 0 after 0 usecs
[   18.324885] calling  net_dev_init+0x0/0x175 @ 1
[   18.340189] initcall net_dev_init+0x0/0x175 returned 0 after 976 usecs
[   18.361781] calling  neigh_init+0x0/0x71 @ 1
[   18.376078] initcall neigh_init+0x0/0x71 returned 0 after 0 usecs
[   18.396383] calling  fib_rules_init+0x0/0xa6 @ 1
[   18.411828] initcall fib_rules_init+0x0/0xa6 returned 0 after 0 usecs
[   18.433281] calling  pktsched_init+0x0/0xd0 @ 1
[   18.448435] initcall pktsched_init+0x0/0xd0 returned 0 after 0 usecs
[   18.469597] calling  tc_filter_init+0x0/0x4c @ 1
[   18.485041] initcall tc_filter_init+0x0/0x4c returned 0 after 0 usecs
[   18.506494] calling  tc_action_init+0x0/0x4c @ 1
[   18.521934] initcall tc_action_init+0x0/0x4c returned 0 after 0 usecs
[   18.543388] calling  genl_init+0x0/0x8f @ 1
[   18.557415] initcall genl_init+0x0/0x8f returned 0 after 976 usecs
[   18.577989] calling  cipso_v4_init+0x0/0x61 @ 1
[   18.593148] initcall cipso_v4_init+0x0/0x61 returned 0 after 0 usecs
[   18.614308] calling  wireless_nlevent_init+0x0/0x12 @ 1
[   18.631759] initcall wireless_nlevent_init+0x0/0x12 returned 0 after 0 u=
secs
[   18.655205] calling  cfg80211_init+0x0/0x92 @ 1
[   18.670486] cfg80211: Using static regulatory domain info
[   18.688383] cfg80211: Regulatory domain: US
[   18.702426] 	(start_freq - end_freq @ bandwidth),
(max_antenna_gain, max_eirp)
[   18.726447] 	(2402000 KHz - 2472000 KHz @ 40000 KHz), (600 mBi, 2700 mBm)
[   18.749043] 	(5170000 KHz - 5190000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
[   18.771637] 	(5190000 KHz - 5210000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
[   18.794230] 	(5210000 KHz - 5230000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
[   18.816824] 	(5230000 KHz - 5330000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
[   18.839417] 	(5735000 KHz - 5835000 KHz @ 40000 KHz), (600 mBi, 3000 mBm)
[   18.862022] cfg80211: Calling CRDA for country: US
[   18.878072] initcall cfg80211_init+0x0/0x92 returned 0 after 2929 usecs
[   18.900048] calling  ieee80211_init+0x0/0xb @ 1
[   18.915202] initcall ieee80211_init+0x0/0xb returned 0 after 0 usecs
[   18.936364] calling  netlbl_init+0x0/0x81 @ 1
[   18.950948] NetLabel: Initializing
[   18.962389] NetLabel:  domain hash size =3D 128
[   18.976975] NetLabel:  protocols =3D UNLABELED CIPSOv4
[   18.993570] NetLabel:  unlabeled traffic allowed by default
[   19.012157] initcall netlbl_init+0x0/0x81 returned 0 after 0 usecs
[   19.032744] calling  rfkill_init+0x0/0x79 @ 1
[   19.047431] initcall rfkill_init+0x0/0x79 returned 0 after 976 usecs
[   19.068492] calling  sysctl_init+0x0/0x48 @ 1
[   19.083079] initcall sysctl_init+0x0/0x48 returned 0 after 0 usecs
[   19.103670] calling  xen_mc_debugfs+0x0/0x118 @ 1
[   19.119420] initcall xen_mc_debugfs+0x0/0x118 returned 0 after 976 usecs
[   19.141710] calling  xen_mmu_debugfs+0x0/0x2be @ 1
[   19.157760] initcall xen_mmu_debugfs+0x0/0x2be returned 0 after 976 usecs
[   19.180320] calling  print_all_ICs+0x0/0x51b @ 1
[   19.195771] initcall print_all_ICs+0x0/0x51b returned 0 after 976 usecs
[   19.217785] calling  hpet_late_init+0x0/0xec @ 1
[   19.233224] initcall hpet_late_init+0x0/0xec returned -19 after 0 usecs
[   19.255249] calling  init_k8_nbs+0x0/0x28 @ 1
[   19.269840] initcall init_k8_nbs+0x0/0x28 returned 0 after 0 usecs
[   19.290423] calling  clocksource_done_booting+0x0/0x5a @ 1
[   19.308730] Switching to clocksource xen
[   19.322088] initcall clocksource_done_booting+0x0/0x5a returned 0
after 1046 usecs
[   19.347049] calling  rb_init_debugfs+0x0/0x2f @ 1
[   19.362805] initcall rb_init_debugfs+0x0/0x2f returned 0 after 26 usecs
[   19.384800] calling  tracer_init_debugfs+0x0/0x2d2 @ 1
[   19.402038] initcall tracer_init_debugfs+0x0/0x2d2 returned 0 after 76 u=
secs
[   19.425410] calling  init_trace_printk_function_export+0x0/0x2f @ 1
[   19.446291] initcall init_trace_printk_function_export+0x0/0x2f
returned 0 after 1 usecs
[   19.473171] calling  event_trace_init+0x0/0x1f7 @ 1
[   19.491236] initcall event_trace_init+0x0/0x1f7 returned 0 after 1721 us=
ecs
[   19.513843] calling  init_pipe_fs+0x0/0x4c @ 1
[   19.528731] initcall init_pipe_fs+0x0/0x4c returned 0 after 19 usecs
[   19.549877] calling  eventpoll_init+0x0/0xd9 @ 1
[   19.565321] initcall eventpoll_init+0x0/0xd9 returned 0 after 2 usecs
[   19.586769] calling  anon_inode_init+0x0/0x125 @ 1
[   19.602797] initcall anon_inode_init+0x0/0x125 returned 0 after 13 usecs
[   19.625094] calling  blk_scsi_ioctl_init+0x0/0x289 @ 1
[   19.642252] initcall blk_scsi_ioctl_init+0x0/0x289 returned 0 after 0 us=
ecs
[   19.665417] calling  acpi_event_init+0x0/0x81 @ 1
[   19.681160] initcall acpi_event_init+0x0/0x81 returned 0 after 13 usecs
[   19.703196] calling  pnpacpi_init+0x0/0x8c @ 1
[   19.718066] pnp: PnP ACPI init
[   19.728375] ACPI: bus type pnp registered
[   19.743206] xen: registering gsi 8 triggering 1 polarity 0
[   19.760946] xen_allocate_pirq: returning irq 8 for gsi 8
[   19.778678] xen: --> irq=3D8
[   19.787951] xen: registering gsi 13 triggering 1 polarity 0
[   19.806420] xen_allocate_pirq: returning irq 13 for gsi 13
[   19.824721] xen: --> irq=3D13
[   19.835027] xen: registering gsi 4 triggering 1 polarity 0
[   19.852768] xen_allocate_pirq: returning irq 4 for gsi 4
[   19.870501] xen: --> irq=3D4
[   19.879663] Already setup the GSI :4
[   19.892142] xen: registering gsi 3 triggering 1 polarity 0
[   19.909968] xen_allocate_pirq: returning irq 3 for gsi 3
[   19.927699] xen: --> irq=3D3
[   19.937319] pnp: PnP ACPI: found 11 devices
[   19.950864] ACPI: ACPI bus type pnp unregistered
[   19.966310] initcall pnpacpi_init+0x0/0x8c returned 0 after 242423 usecs
[   19.988615] calling  pnp_system_init+0x0/0x12 @ 1
[   20.004353] system 00:07: ioport range 0x500-0x57f has been reserved
[   20.025508] system 00:07: ioport range 0x600-0x61f has been reserved
[   20.046672] system 00:07: ioport range 0x880-0x883 has been reserved
[   20.067836] system 00:07: ioport range 0xca4-0xca5 has been reserved
[   20.088999] system 00:07: ioport range 0x400-0x47f has been reserved
[   20.110162] system 00:07: ioport range 0x800-0x81f has been reserved
[   20.131327] system 00:07: ioport range 0xca2-0xca3 has been reserved
[   20.152489] system 00:07: iomem range 0xfed1c000-0xfed3fffe could
not be reserved
[   20.177370] system 00:07: iomem range 0xff000000-0xffffffff could
not be reserved
[   20.202252] system 00:07: iomem range 0xfee00000-0xfeefffff could
not be reserved
[   20.227134] system 00:07: iomem range 0xfe900000-0xfe90001f has been res=
erved
[   20.250869] system 00:07: iomem range 0xfea00000-0xfea0001f has been res=
erved
[   20.274607] system 00:07: iomem range 0xfed1b000-0xfed1bfff has been res=
erved
[   20.298344] system 00:07: iomem range 0xfed14000-0xfed17ffe has been res=
erved
[   20.322081] system 00:07: iomem range 0xfed18000-0xfed18ffe has been res=
erved
[   20.345819] system 00:07: iomem range 0xfed19000-0xfed19ffe has been res=
erved
[   20.369608] initcall pnp_system_init+0x0/0x12 returned 0 after 356699 us=
ecs
[   20.392722] calling  pcistub_init+0x0/0x1d7 @ 1
[   20.408017] initcall pcistub_init+0x0/0x1d7 returned 0 after 133 usecs
[   20.429615] calling  chr_dev_init+0x0/0xc3 @ 1
[   20.445116] initcall chr_dev_init+0x0/0xc3 returned 0 after 613 usecs
[   20.466003] calling  firmware_class_init+0x0/0x79 @ 1
[   20.482929] initcall firmware_class_init+0x0/0x79 returned 0 after 51 us=
ecs
[   20.506042] calling  init_pcmcia_bus+0x0/0x74 @ 1
[   20.521832] initcall init_pcmcia_bus+0x0/0x74 returned 0 after 59 usecs
[   20.543793] calling  cpufreq_gov_performance_init+0x0/0x12 @ 1
[   20.563241] initcall cpufreq_gov_performance_init+0x0/0x12 returned
0 after 0 usecs
[   20.588694] calling  cpufreq_gov_userspace_init+0x0/0x12 @ 1
[   20.607569] initcall cpufreq_gov_userspace_init+0x0/0x12 returned 0
after 0 usecs
[   20.632449] calling  init_acpi_pm_clocksource+0x0/0xf6 @ 1
[   20.654920] PM-Timer failed consistency check  (0x0xffffff) - aborting.
[   20.676380] initcall init_acpi_pm_clocksource+0x0/0xf6 returned -19
after 25024 usecs
[   20.702436] calling  pcibios_assign_resources+0x0/0x74 @ 1
[   20.720745] pci 0000:01:00.0: BAR 6: no parent found for of device
[0xfffe0000-0xffffffff]
[   20.748192] pci 0000:04:00.0: BAR 6: no parent found for of device
[0xffff0000-0xffffffff]
[   20.775715] pci 0000:00:05.0: PCI bridge, secondary bus 0000:01
[   20.795382] pci 0000:00:05.0:   IO window: 0x2000-0x2fff
[   20.813115] pci 0000:00:05.0:   MEM window: 0xb3a00000-0xb3afffff
[   20.833420] pci 0000:00:05.0:   PREFETCH window:
0x000000b0000000-0x000000b1ffffff
[   20.858590] pci 0000:00:1c.0: PCI bridge, secondary bus 0000:02
[   20.878316] pci 0000:00:1c.0:   IO window: disabled
[   20.894624] pci 0000:00:1c.0:   MEM window: disabled
[   20.911209] pci 0000:00:1c.0:   PREFETCH window: disabled
[   20.929230] pci 0000:00:1c.4: PCI bridge, secondary bus 0000:03
[   20.948958] pci 0000:00:1c.4:   IO window: 0x1000-0x1fff
[   20.966693] pci 0000:00:1c.4:   MEM window: 0xb3900000-0xb39fffff
[   20.986997] pci 0000:00:1c.4:   PREFETCH window: disabled
[   21.005020] pci 0000:00:1c.6: PCI bridge, secondary bus 0000:04
[   21.024745] pci 0000:00:1c.6:   IO window: disabled
[   21.041051] pci 0000:00:1c.6:   MEM window: 0xb3000000-0xb38fffff
[   21.061355] pci 0000:00:1c.6:   PREFETCH window:
0x000000b2000000-0x000000b2ffffff
[   21.086525] pci 0000:00:1c.7: PCI bridge, secondary bus 0000:05
[   21.106253] pci 0000:00:1c.7:   IO window: disabled
[   21.122559] pci 0000:00:1c.7:   MEM window: disabled
[   21.139145] pci 0000:00:1c.7:   PREFETCH window: disabled
[   21.157166] pci 0000:00:1e.0: PCI bridge, secondary bus 0000:06
[   21.176893] pci 0000:00:1e.0:   IO window: disabled
[   21.193200] pci 0000:00:1e.0:   MEM window: disabled
[   21.209785] pci 0000:00:1e.0:   PREFETCH window: disabled
[   21.227816] xen: registering gsi 16 triggering 0 polarity 1
[   21.246394]   alloc irq_desc for 16 on node 0
[   21.260974]   alloc kstat_irqs on node 0
[   21.274144] xen: --> irq=3D16
[   21.283576] pci 0000:00:05.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
[   21.305878] pci 0000:00:05.0: setting latency timer to 64
[   21.323904] xen: registering gsi 16 triggering 0 polarity 1
[   21.342482] xen_allocate_pirq: returning irq 16 for gsi 16
[   21.360785] xen: --> irq=3D16
[   21.370228] Already setup the GSI :16
[   21.382521] pci 0000:00:1c.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
[   21.404832] pci 0000:00:1c.0: setting latency timer to 64
[   21.422854] xen: registering gsi 16 triggering 0 polarity 1
[   21.441435] xen_allocate_pirq: returning irq 16 for gsi 16
[   21.459738] xen: --> irq=3D16
[   21.469180] Already setup the GSI :16
[   21.481475] pci 0000:00:1c.4: PCI INT B -> GSI 16 (level, low) -> IRQ 16
[   21.503785] pci 0000:00:1c.4: setting latency timer to 64
[   21.521807] xen: registering gsi 18 triggering 0 polarity 1
[   21.540390]   alloc irq_desc for 18 on node 0
[   21.554973]   alloc kstat_irqs on node 0
[   21.568136] xen: --> irq=3D18
[   21.577575] pci 0000:00:1c.6: PCI INT C -> GSI 18 (level, low) -> IRQ 18
[   21.599877] pci 0000:00:1c.6: setting latency timer to 64
[   21.617902] xen: registering gsi 19 triggering 0 polarity 1
[   21.636483]   alloc irq_desc for 19 on node 0
[   21.651066]   alloc kstat_irqs on node 0
[   21.664228] xen: --> irq=3D19
[   21.673666] pci 0000:00:1c.7: PCI INT D -> GSI 19 (level, low) -> IRQ 19
[   21.695972] pci 0000:00:1c.7: setting latency timer to 64
[   21.714022] pci 0000:00:1e.0: setting latency timer to 64
[   21.732034] pci_bus 0000:00: resource 0 io:  [0x00-0xffff]
[   21.750337] pci_bus 0000:00: resource 1 mem: [0x000000-0xfffffffffffffff=
f]
[   21.773215] pci_bus 0000:01: resource 0 io:  [0x2000-0x2fff]
[   21.792090] pci_bus 0000:01: resource 1 mem: [0xb3a00000-0xb3afffff]
[   21.813253] pci_bus 0000:01: resource 2 pref mem [0xb0000000-0xb1ffffff]
[   21.835561] pci_bus 0000:03: resource 0 io:  [0x1000-0x1fff]
[   21.854437] pci_bus 0000:03: resource 1 mem: [0xb3900000-0xb39fffff]
[   21.875599] pci_bus 0000:04: resource 1 mem: [0xb3000000-0xb38fffff]
[   21.896765] pci_bus 0000:04: resource 2 pref mem [0xb2000000-0xb2ffffff]
[   21.919070] pci_bus 0000:06: resource 3 io:  [0x00-0xffff]
[   21.937375] pci_bus 0000:06: resource 4 mem: [0x000000-0xfffffffffffffff=
f]
[   21.960256] initcall pcibios_assign_resources+0x0/0x74 returned 0
after 1210466 usecs
[   21.986279] calling  sysctl_core_init+0x0/0x38 @ 1
[   22.002312] initcall sysctl_core_init+0x0/0x38 returned 0 after 15 usecs
[   22.024602] calling  inet_init+0x0/0x20a @ 1
[   22.038919] NET: Registered protocol family 2
[   22.053569] IP route cache hash table entries: 524288 (order: 10,
4194304 bytes)
[   22.078712] TCP established hash table entries: 262144 (order: 10,
4194304 bytes)
[   22.104272] TCP bind hash table entries: 65536 (order: 8, 1048576 bytes)
[   22.126325] TCP: Hash tables configured (established 262144 bind 65536)
[   22.148037] TCP reno registered
[   22.158685] initcall inet_init+0x0/0x20a returned 0 after 116972 usecs
[   22.180356] calling  af_unix_init+0x0/0x55 @ 1
[   22.195227] NET: Registered protocol family 1
[   22.209819] initcall af_unix_init+0x0/0x55 returned 0 after 14249 usecs
[   22.231834] calling  init_sunrpc+0x0/0x5d @ 1
[   22.246619] RPC: Registered udp transport module.
[   22.262149] RPC: Registered tcp transport module.
[   22.277878] RPC: Registered tcp NFSv4.1 backchannel transport module.
[   22.299330] initcall init_sunrpc+0x0/0x5d returned 0 after 51669 usecs
[   22.321065] calling  pci_apply_final_quirks+0x0/0x36 @ 1
[   22.339105] pci 0000:04:00.0: Boot video device
[   22.353954] initcall pci_apply_final_quirks+0x0/0x36 returned 0
after 14801 usecs
[   22.378835] calling  populate_rootfs+0x0/0xd7 @ 1
[   22.394616] Trying to unpack rootfs image as initramfs...
[   22.416540] Freeing initrd memory: 4911k freed
[   22.431447] initcall populate_rootfs+0x0/0xd7 returned 0 after 36015 use=
cs
[   22.453765] calling  pci_iommu_init+0x0/0x3a @ 1
[   22.469206] PCI-DMA: Using software bounce buffering for IO (SWIOTLB)
[   22.490657] DMA: Placing 64MB software IO TLB between
ffff880020000000 - ffff880024000000
[   22.517825] DMA: software IO TLB at phys 0x20000000 - 0x24000000
[   22.537847] initcall pci_iommu_init+0x0/0x3a returned 0 after 67031 usecs
[   22.560438] calling  irqfd_module_init+0x0/0x31 @ 1
[   22.576804] initcall irqfd_module_init+0x0/0x31 returned 0 after 61 usecs
[   22.599334] calling  vmx_init+0x0/0x1ff @ 1
[   22.613359] kvm: no hardware support
[   22.625362] initcall vmx_init+0x0/0x1ff returned -95 after 11733 usecs
[   22.647094] initcall vmx_init+0x0/0x1ff returned with error code -95
[   22.668544] calling  svm_init+0x0/0x19 @ 1
[   22.682272] has_svm: not amd
[   22.691993] kvm: no hardware support
[   22.704007] initcall svm_init+0x0/0x19 returned -95 after 21225 usecs
[   22.725485] initcall svm_init+0x0/0x19 returned with error code -95
[   22.746649] calling  i8259A_init_sysfs+0x0/0x22 @ 1
[   22.763076] initcall i8259A_init_sysfs+0x0/0x22 returned 0 after 123 use=
cs
[   22.785830] calling  vsyscall_init+0x0/0x6c @ 1
[   22.801087] initcall vsyscall_init+0x0/0x6c returned 0 after 97 usecs
[   22.822436] calling  sbf_init+0x0/0xe9 @ 1
[   22.836165] initcall sbf_init+0x0/0xe9 returned 0 after 0 usecs
[   22.855897] calling  i8237A_init_sysfs+0x0/0x22 @ 1
[   22.872306] initcall i8237A_init_sysfs+0x0/0x22 returned 0 after 103 use=
cs
[   22.895078] calling  add_rtc_cmos+0x0/0xa9 @ 1
[   22.909952] initcall add_rtc_cmos+0x0/0xa9 returned 0 after 2 usecs
[   22.930829] calling  cache_sysfs_init+0x0/0x64 @ 1
[   22.947960] initcall cache_sysfs_init+0x0/0x64 returned 0 after 1089 use=
cs
[   22.970278] calling  mce_init_device+0x0/0xff @ 1
[   22.986385] initcall mce_init_device+0x0/0xff returned 0 after 366 usecs
[   23.008315] calling  msr_init+0x0/0x14a @ 1
[   23.022628] initcall msr_init+0x0/0x14a returned 0 after 291 usecs
[   23.042919] calling  cpuid_init+0x0/0x14a @ 1
[   23.057793] initcall cpuid_init+0x0/0x14a returned 0 after 279 usecs
[   23.078668] calling  ioapic_init_sysfs+0x0/0xb3 @ 1
[   23.095073] initcall ioapic_init_sysfs+0x0/0xb3 returned 0 after 101 use=
cs
[   23.117850] calling  add_pcspkr+0x0/0x28 @ 1
[   23.132208] initcall add_pcspkr+0x0/0x28 returned 0 after 57 usecs
[   23.152741] calling  microcode_init+0x0/0x132 @ 1
[   23.168613] Microcode Update Driver: v2.00
<tigran@aivazian.fsnet.co.uk>, Peter Oruba
[   23.194495] initcall microcode_init+0x0/0x132 returned 0 after 25414 use=
cs
[   23.217378] calling  start_periodic_check_for_corruption+0x0/0x37 @ 1
[   23.238822] Scanning for low memory corruption every 60 seconds
[   23.258559] initcall start_periodic_check_for_corruption+0x0/0x37
returned 0 after 19272 usecs
[   23.287156] calling  audit_classes_init+0x0/0xaf @ 1
[   23.303769] initcall audit_classes_init+0x0/0xaf returned 0 after 20 use=
cs
[   23.326628] calling  init_vdso_vars+0x0/0x241 @ 1
[   23.342370] initcall init_vdso_vars+0x0/0x241 returned 0 after 15 usecs
[   23.364378] calling  ia32_binfmt_init+0x0/0x14 @ 1
[   23.380395] initcall ia32_binfmt_init+0x0/0x14 returned 0 after 4 usecs
[   23.402416] calling  sysenter_setup+0x0/0x2f1 @ 1
[   23.418143] initcall sysenter_setup+0x0/0x2f1 returned 0 after 1 usecs
[   23.439880] calling  proc_schedstat_init+0x0/0x22 @ 1
[   23.456757] initcall proc_schedstat_init+0x0/0x22 returned 0 after 3 use=
cs
[   23.479634] calling  proc_execdomains_init+0x0/0x22 @ 1
[   23.497080] initcall proc_execdomains_init+0x0/0x22 returned 0 after 1 u=
secs
[   23.520526] calling  ioresources_init+0x0/0x3c @ 1
[   23.536544] initcall ioresources_init+0x0/0x3c returned 0 after 1 usecs
[   23.558566] calling  uid_cache_init+0x0/0x9b @ 1
[   23.574020] initcall uid_cache_init+0x0/0x9b returned 0 after 12 usecs
[   23.595746] calling  init_posix_timers+0x0/0x17a @ 1
[   23.612331] initcall init_posix_timers+0x0/0x17a returned 0 after 1 usecs
[   23.634927] calling  init_posix_cpu_timers+0x0/0xe5 @ 1
[   23.652373] initcall init_posix_cpu_timers+0x0/0xe5 returned 0 after 0 u=
secs
[   23.675819] calling  nsproxy_cache_init+0x0/0x2d @ 1
[   23.692409] initcall nsproxy_cache_init+0x0/0x2d returned 0 after 0 usecs
[   23.715035] calling  create_proc_profile+0x0/0x283 @ 1
[   23.732194] initcall create_proc_profile+0x0/0x283 returned 0 after 0 us=
ecs
[   23.755359] calling  timekeeping_init_device+0x0/0x22 @ 1
[   23.773480] initcall timekeeping_init_device+0x0/0x22 returned 0
after 101 usecs
[   23.797967] calling  init_clocksource_sysfs+0x0/0x50 @ 1
[   23.815801] initcall init_clocksource_sysfs+0x0/0x50 returned 0
after 95 usecs
[   23.839721] calling  init_timer_list_procfs+0x0/0x2c @ 1
[   23.857460] initcall init_timer_list_procfs+0x0/0x2c returned 0 after 1 =
usecs
[   23.881191] calling  init_tstats_procfs+0x0/0x2c @ 1
[   23.897779] initcall init_tstats_procfs+0x0/0x2c returned 0 after 0 usecs
[   23.920376] calling  futex_init+0x0/0x68 @ 1
[   23.934684] initcall futex_init+0x0/0x68 returned 0 after 12 usecs
[   23.955262] calling  proc_dma_init+0x0/0x22 @ 1
[   23.970422] initcall proc_dma_init+0x0/0x22 returned 0 after 1 usecs
[   23.991583] calling  proc_modules_init+0x0/0x22 @ 1
[   24.007887] initcall proc_modules_init+0x0/0x22 returned 0 after 0 usecs
[   24.030197] calling  kallsyms_init+0x0/0x25 @ 1
[   24.045351] initcall kallsyms_init+0x0/0x25 returned 0 after 0 usecs
[   24.066514] calling  snapshot_device_init+0x0/0x12 @ 1
[   24.083738] initcall snapshot_device_init+0x0/0x12 returned 0 after 57 u=
secs
[   24.107125] calling  crash_save_vmcoreinfo_init+0x0/0x4a5 @ 1
[   24.126305] initcall crash_save_vmcoreinfo_init+0x0/0x4a5 returned
0 after 19 usecs
[   24.151739] calling  crash_notes_memory_init+0x0/0x37 @ 1
[   24.169762] initcall crash_notes_memory_init+0x0/0x37 returned 0
after 1 usecs
[   24.193780] calling  pid_namespaces_init+0x0/0x2d @ 1
[   24.210660] initcall pid_namespaces_init+0x0/0x2d returned 0 after 2 use=
cs
[   24.233536] calling  audit_init+0x0/0x133 @ 1
[   24.248118] audit: initializing netlink socket (disabled)
[   24.266155] type=3D2000 audit(1323880410.207:1): initialized
[   24.284444] initcall audit_init+0x0/0x133 returned 0 after 35472 usecs
[   24.306178] calling  audit_tree_init+0x0/0x49 @ 1
[   24.321904] initcall audit_tree_init+0x0/0x49 returned 0 after 0 usecs
[   24.343644] calling  init_kprobes+0x0/0x148 @ 1
[   24.372692] initcall init_kprobes+0x0/0x148 returned 0 after 13569 usecs
[   24.394441] calling  utsname_sysctl_init+0x0/0x14 @ 1
[   24.411326] initcall utsname_sysctl_init+0x0/0x14 returned 0 after 11 us=
ecs
[   24.434480] calling  init_tracepoints+0x0/0x12 @ 1
[   24.450491] initcall init_tracepoints+0x0/0x12 returned 0 after 0 usecs
[   24.472516] calling  init_events+0x0/0x64 @ 1
[   24.487100] initcall init_events+0x0/0x64 returned 0 after 1 usecs
[   24.507690] calling  init_sched_switch_trace+0x0/0x12 @ 1
[   24.525712] initcall init_sched_switch_trace+0x0/0x12 returned 0
after 0 usecs
[   24.549730] calling  init_blk_tracer+0x0/0x55 @ 1
[   24.565461] initcall init_blk_tracer+0x0/0x55 returned 0 after 0 usecs
[   24.587199] calling  perf_event_sysfs_init+0x0/0x19 @ 1
[   24.604650] initcall perf_event_sysfs_init+0x0/0x19 returned 0 after 3 u=
secs
[   24.628091] calling  init_per_zone_wmark_min+0x0/0x67 @ 1
[   24.646545] initcall init_per_zone_wmark_min+0x0/0x67 returned 0
after 420 usecs
[   24.670705] calling  kswapd_init+0x0/0x20 @ 1
[   24.685337] initcall kswapd_init+0x0/0x20 returned 0 after 43 usecs
[   24.706168] calling  setup_vmstat+0x0/0xc5 @ 1
[   24.721077] initcall setup_vmstat+0x0/0xc5 returned 0 after 8 usecs
[   24.741946] calling  mm_sysfs_init+0x0/0x29 @ 1
[   24.757106] initcall mm_sysfs_init+0x0/0x29 returned 0 after 3 usecs
[   24.778268] calling  proc_vmalloc_init+0x0/0x25 @ 1
[   24.794569] initcall proc_vmalloc_init+0x0/0x25 returned 0 after 1 usecs
[   24.816880] calling  procswaps_init+0x0/0x22 @ 1
[   24.832321] initcall procswaps_init+0x0/0x22 returned 0 after 0 usecs
[   24.853772] calling  hugetlb_init+0x0/0x3c8 @ 1
[   24.868926] HugeTLB registered 2 MB page size, pre-allocated 0 pages
[   24.890096] initcall hugetlb_init+0x0/0x3c8 returned 0 after 20674 usecs
[   24.912401] calling  slab_proc_init+0x0/0x25 @ 1
[   24.927842] initcall slab_proc_init+0x0/0x25 returned 0 after 1 usecs
[   24.949293] calling  slab_sysfs_init+0x0/0xee @ 1
[   24.968295] initcall slab_sysfs_init+0x0/0xee returned 0 after 3197 usecs
[   24.990331] calling  fasync_init+0x0/0x2a @ 1
[   25.004915] initcall fasync_init+0x0/0x2a returned 0 after 3 usecs
[   25.025504] calling  proc_filesystems_init+0x0/0x22 @ 1
[   25.042956] initcall proc_filesystems_init+0x0/0x22 returned 0 after 2 u=
secs
[   25.066399] calling  dnotify_init+0x0/0x80 @ 1
[   25.081278] initcall dnotify_init+0x0/0x80 returned 0 after 6 usecs
[   25.102150] calling  inotify_setup+0x0/0x12 @ 1
[   25.117306] initcall inotify_setup+0x0/0x12 returned 0 after 0 usecs
[   25.138470] calling  inotify_user_setup+0x0/0xbe @ 1
[   25.155074] initcall inotify_user_setup+0x0/0xbe returned 0 after 15 use=
cs
[   25.177942] calling  aio_setup+0x0/0x71 @ 1
[   25.192070] initcall aio_setup+0x0/0x71 returned 0 after 110 usecs
[   25.212541] calling  proc_locks_init+0x0/0x22 @ 1
[   25.228274] initcall proc_locks_init+0x0/0x22 returned 0 after 2 usecs
[   25.250010] calling  init_sys32_ioctl+0x0/0x83 @ 1
[   25.266036] initcall init_sys32_ioctl+0x0/0x83 returned 0 after 12 usecs
[   25.288334] calling  init_mbcache+0x0/0x14 @ 1
[   25.303203] initcall init_mbcache+0x0/0x14 returned 0 after 0 usecs
[   25.324079] calling  dquot_init+0x0/0xf9 @ 1
[   25.338377] VFS: Disk quotas dquot_6.5.2
[   25.351639] Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
[   25.372992] initcall dquot_init+0x0/0xf9 returned 0 after 33801 usecs
[   25.394438] calling  init_v2_quota_format+0x0/0x12 @ 1
[   25.411597] initcall init_v2_quota_format+0x0/0x12 returned 0 after 0 us=
ecs
[   25.434762] calling  proc_cmdline_init+0x0/0x22 @ 1
[   25.451061] initcall proc_cmdline_init+0x0/0x22 returned 0 after 1 usecs
[   25.473371] calling  proc_cpuinfo_init+0x0/0x22 @ 1
[   25.489668] initcall proc_cpuinfo_init+0x0/0x22 returned 0 after 0 usecs
[   25.511979] calling  proc_devices_init+0x0/0x22 @ 1
[   25.528279] initcall proc_devices_init+0x0/0x22 returned 0 after 1 usecs
[   25.550588] calling  proc_interrupts_init+0x0/0x22 @ 1
[   25.567748] initcall proc_interrupts_init+0x0/0x22 returned 0 after 0 us=
ecs
[   25.590914] calling  proc_loadavg_init+0x0/0x22 @ 1
[   25.607212] initcall proc_loadavg_init+0x0/0x22 returned 0 after 0 usecs
[   25.629523] calling  proc_meminfo_init+0x0/0x22 @ 1
[   25.645820] initcall proc_meminfo_init+0x0/0x22 returned 0 after 0 usecs
[   25.668132] calling  proc_stat_init+0x0/0x22 @ 1
[   25.683571] initcall proc_stat_init+0x0/0x22 returned 0 after 0 usecs
[   25.705025] calling  proc_uptime_init+0x0/0x22 @ 1
[   25.721065] initcall proc_uptime_init+0x0/0x22 returned 0 after 0 usecs
[   25.743091] calling  proc_version_init+0x0/0x22 @ 1
[   25.759388] initcall proc_version_init+0x0/0x22 returned 0 after 0 usecs
[   25.781699] calling  proc_softirqs_init+0x0/0x22 @ 1
[   25.798284] initcall proc_softirqs_init+0x0/0x22 returned 0 after 1 usecs
[   25.820879] calling  proc_kcore_init+0x0/0xa9 @ 1
[   25.836609] initcall proc_kcore_init+0x0/0xa9 returned 0 after 4 usecs
[   25.858344] calling  vmcore_init+0x0/0x333 @ 1
[   25.873213] initcall vmcore_init+0x0/0x333 returned 0 after 0 usecs
[   25.894090] calling  proc_kmsg_init+0x0/0x25 @ 1
[   25.909534] initcall proc_kmsg_init+0x0/0x25 returned 0 after 0 usecs
[   25.930986] calling  proc_page_init+0x0/0x42 @ 1
[   25.946428] initcall proc_page_init+0x0/0x42 returned 0 after 1 usecs
[   25.967880] calling  init_devpts_fs+0x0/0x4c @ 1
[   25.983326] initcall init_devpts_fs+0x0/0x4c returned 0 after 6 usecs
[   26.004772] calling  init_ext3_fs+0x0/0x71 @ 1
[   26.019806] initcall init_ext3_fs+0x0/0x71 returned 0 after 162 usecs
[   26.041095] calling  journal_init+0x0/0x99 @ 1
[   26.056248] initcall journal_init+0x0/0x99 returned 0 after 279 usecs
[   26.077414] calling  init_ramfs_fs+0x0/0x12 @ 1
[   26.092570] initcall init_ramfs_fs+0x0/0x12 returned 0 after 1 usecs
[   26.113731] calling  init_hugetlbfs_fs+0x0/0x98 @ 1
[   26.130114] initcall init_hugetlbfs_fs+0x0/0x98 returned 0 after 77 usecs
[   26.152631] calling  init_fat_fs+0x0/0x4f @ 1
[   26.167355] initcall init_fat_fs+0x0/0x4f returned 0 after 138 usecs
[   26.188376] calling  init_vfat_fs+0x0/0x12 @ 1
[   26.203248] initcall init_vfat_fs+0x0/0x12 returned 0 after 1 usecs
[   26.224124] calling  init_msdos_fs+0x0/0x12 @ 1
[   26.239282] initcall init_msdos_fs+0x0/0x12 returned 0 after 0 usecs
[   26.260446] calling  init_iso9660_fs+0x0/0x71 @ 1
[   26.276263] initcall init_iso9660_fs+0x0/0x71 returned 0 after 85 usecs
[   26.298200] calling  init_nfs_fs+0x0/0x148 @ 1
[   26.313328] initcall init_nfs_fs+0x0/0x148 returned 0 after 253 usecs
[   26.334521] calling  init_nlm+0x0/0x22 @ 1
[   26.348260] initcall init_nlm+0x0/0x22 returned 0 after 10 usecs
[   26.368263] calling  init_nls_cp437+0x0/0x12 @ 1
[   26.383708] initcall init_nls_cp437+0x0/0x12 returned 0 after 0 usecs
[   26.405160] calling  init_nls_ascii+0x0/0x12 @ 1
[   26.420601] initcall init_nls_ascii+0x0/0x12 returned 0 after 0 usecs
[   26.442053] calling  init_nls_iso8859_1+0x0/0x12 @ 1
[   26.458638] initcall init_nls_iso8859_1+0x0/0x12 returned 0 after 0 usecs
[   26.481234] calling  init_nls_utf8+0x0/0x29 @ 1
[   26.496390] initcall init_nls_utf8+0x0/0x29 returned 0 after 0 usecs
[   26.517550] calling  init_autofs4_fs+0x0/0x26 @ 1
[   26.533342] initcall init_autofs4_fs+0x0/0x26 returned 0 after 57 usecs
[   26.555306] calling  ipc_init+0x0/0x23 @ 1
[   26.569036] msgmni has been set to 3375
[   26.581906] initcall ipc_init+0x0/0x23 returned 0 after 12571 usecs
[   26.602777] calling  ipc_sysctl_init+0x0/0x14 @ 1
[   26.618527] initcall ipc_sysctl_init+0x0/0x14 returned 0 after 20 usecs
[   26.640532] calling  init_mqueue_fs+0x0/0xb4 @ 1
[   26.656077] initcall init_mqueue_fs+0x0/0xb4 returned 0 after 101 usecs
[   26.677997] calling  key_proc_init+0x0/0x59 @ 1
[   26.693154] initcall key_proc_init+0x0/0x59 returned 0 after 3 usecs
[   26.714346] calling  selinux_nf_ip_init+0x0/0x62 @ 1
[   26.730929] SELinux:  Registering netfilter hooks
[   26.746662] initcall selinux_nf_ip_init+0x0/0x62 returned 0 after 15363 =
usecs
[   26.770398] calling  init_sel_fs+0x0/0x68 @ 1
[   26.785061] initcall init_sel_fs+0x0/0x68 returned 0 after 75 usecs
[   26.805860] calling  selnl_init+0x0/0x4d @ 1
[   26.820171] initcall selnl_init+0x0/0x4d returned 0 after 9 usecs
[   26.840465] calling  sel_netif_init+0x0/0x66 @ 1
[   26.855912] initcall sel_netif_init+0x0/0x66 returned 0 after 2 usecs
[   26.877362] calling  sel_netnode_init+0x0/0x74 @ 1
[   26.893375] initcall sel_netnode_init+0x0/0x74 returned 0 after 0 usecs
[   26.915399] calling  sel_netport_init+0x0/0x74 @ 1
[   26.931412] initcall sel_netport_init+0x0/0x74 returned 0 after 0 usecs
[   26.953436] calling  aurule_init+0x0/0x37 @ 1
[   26.968019] initcall aurule_init+0x0/0x37 returned 0 after 0 usecs
[   26.988609] calling  crypto_wq_init+0x0/0x2e @ 1
[   27.004152] initcall crypto_wq_init+0x0/0x2e returned 0 after 95 usecs
[   27.025793] calling  crypto_algapi_init+0x0/0xd @ 1
[   27.042093] initcall crypto_algapi_init+0x0/0xd returned 0 after 2 usecs
[   27.064400] calling  skcipher_module_init+0x0/0x39 @ 1
[   27.081562] initcall skcipher_module_init+0x0/0x39 returned 0 after 0 us=
ecs
[   27.104725] calling  chainiv_module_init+0x0/0x12 @ 1
[   27.121600] initcall chainiv_module_init+0x0/0x12 returned 0 after 0 use=
cs
[   27.144479] calling  eseqiv_module_init+0x0/0x12 @ 1
[   27.161063] initcall eseqiv_module_init+0x0/0x12 returned 0 after 0 usecs
[   27.183658] calling  hmac_module_init+0x0/0x12 @ 1
[   27.199672] initcall hmac_module_init+0x0/0x12 returned 0 after 0 usecs
[   27.221697] calling  crypto_null_mod_init+0x0/0x7d @ 1
[   27.238894] alg: No test for cipher_null (cipher_null-generic)
[   27.258337] alg: No test for ecb(cipher_null) (ecb-cipher_null)
[   27.278068] alg: No test for digest_null (digest_null-generic)
[   27.297515] alg: No test for compress_null (compress_null-generic)
[   27.318083] initcall crypto_null_mod_init+0x0/0x7d returned 0 after
77368 usecs
[   27.342381] calling  md5_mod_init+0x0/0x12 @ 1
[   27.357314] initcall md5_mod_init+0x0/0x12 returned 0 after 57 usecs
[   27.378416] calling  sha1_generic_mod_init+0x0/0x12 @ 1
[   27.395917] initcall sha1_generic_mod_init+0x0/0x12 returned 0 after 49 =
usecs
[   27.419600] calling  crypto_ecb_module_init+0x0/0x12 @ 1
[   27.437334] initcall crypto_ecb_module_init+0x0/0x12 returned 0 after 0 =
usecs
[   27.461067] calling  crypto_cbc_module_init+0x0/0x12 @ 1
[   27.478803] initcall crypto_cbc_module_init+0x0/0x12 returned 0 after 0 =
usecs
[   27.502536] calling  des_generic_mod_init+0x0/0x3f @ 1
[   27.519818] initcall des_generic_mod_init+0x0/0x3f returned 0 after 114 =
usecs
[   27.543434] calling  aes_init+0x0/0x12 @ 1
[   27.557225] initcall aes_init+0x0/0x12 returned 0 after 58 usecs
[   27.577180] calling  arc4_init+0x0/0x12 @ 1
[   27.591274] initcall arc4_init+0x0/0x12 returned 0 after 73 usecs
[   27.611499] calling  deflate_mod_init+0x0/0x12 @ 1
[   27.627762] initcall deflate_mod_init+0x0/0x12 returned 0 after 239 usecs
[   27.650111] calling  zlib_mod_init+0x0/0x12 @ 1
[   27.665600] initcall zlib_mod_init+0x0/0x12 returned 0 after 326 usecs
[   27.687006] calling  crc32c_mod_init+0x0/0x12 @ 1
[   27.702798] initcall crc32c_mod_init+0x0/0x12 returned 0 after 65 usecs
[   27.724786] calling  crypto_authenc_module_init+0x0/0x12 @ 1
[   27.743657] initcall crypto_authenc_module_init+0x0/0x12 returned 0
after 0 usecs
[   27.768537] calling  lzo_mod_init+0x0/0x12 @ 1
[   27.783508] initcall lzo_mod_init+0x0/0x12 returned 0 after 94 usecs
[   27.804573] calling  krng_mod_init+0x0/0x12 @ 1
[   27.819767] alg: No test for stdrng (krng)
[   27.833468] initcall krng_mod_init+0x0/0x12 returned 0 after 13413 usecs
[   27.855769] calling  proc_genhd_init+0x0/0x3c @ 1
[   27.871498] initcall proc_genhd_init+0x0/0x3c returned 0 after 3 usecs
[   27.893234] calling  bsg_init+0x0/0x12e @ 1
[   27.907379] Block layer SCSI generic (bsg) driver version 0.4
loaded (major 252)
[   27.931840] initcall bsg_init+0x0/0x12e returned 0 after 24015 usecs
[   27.953003] calling  noop_init+0x0/0x14 @ 1
[   27.967019] io scheduler noop registered
[   27.980176] initcall noop_init+0x0/0x14 returned 0 after 12848 usecs
[   28.001335] calling  as_init+0x0/0x14 @ 1
[   28.014779] io scheduler anticipatory registered
[   28.030220] initcall as_init+0x0/0x14 returned 0 after 15078 usecs
[   28.050811] calling  deadline_init+0x0/0x14 @ 1
[   28.065968] io scheduler deadline registered
[   28.080270] initcall deadline_init+0x0/0x14 returned 0 after 13965 usecs
[   28.102580] calling  cfq_init+0x0/0x94 @ 1
[   28.116461] io scheduler cfq registered (default)
[   28.132033] initcall cfq_init+0x0/0x94 returned 0 after 15355 usecs
[   28.152911] calling  init_kmp+0x0/0x12 @ 1
[   28.166643] initcall init_kmp+0x0/0x12 returned 0 after 0 usecs
[   28.186372] calling  init_bm+0x0/0x12 @ 1
[   28.199818] initcall init_bm+0x0/0x12 returned 0 after 0 usecs
[   28.219260] calling  init_fsm+0x0/0x12 @ 1
[   28.232993] initcall init_fsm+0x0/0x12 returned 0 after 0 usecs
[   28.252721] calling  percpu_counter_startup+0x0/0x3c @ 1
[   28.270459] initcall percpu_counter_startup+0x0/0x3c returned 0 after 0 =
usecs
[   28.294190] calling  pci_proc_init+0x0/0x6a @ 1
[   28.309384] initcall pci_proc_init+0x0/0x6a returned 0 after 34 usecs
[   28.330801] calling  pcie_portdrv_init+0x0/0x4c @ 1
[   28.347261]   alloc irq_desc for 1257 on node -1
[   28.362542]   alloc kstat_irqs on node -1
[   28.376024] pcieport 0000:00:05.0: setting latency timer to 64
[   28.395693]   alloc irq_desc for 1256 on node -1
[   28.410874]   alloc kstat_irqs on node -1
[   28.424352] pcieport 0000:00:1c.0: setting latency timer to 64
[   28.443971]   alloc irq_desc for 1255 on node -1
[   28.459207]   alloc kstat_irqs on node -1
[   28.472684] pcieport 0000:00:1c.4: setting latency timer to 64
[   28.492303]   alloc irq_desc for 1254 on node -1
[   28.507540]   alloc kstat_irqs on node -1
[   28.521018] pcieport 0000:00:1c.6: setting latency timer to 64
[   28.540641]   alloc irq_desc for 1253 on node -1
[   28.555872]   alloc kstat_irqs on node -1
[   28.569350] pcieport 0000:00:1c.7: setting latency timer to 64
[   28.588957] initcall pcie_portdrv_init+0x0/0x4c returned 0 after 236188 =
usecs
[   28.612500] calling  aer_service_init+0x0/0x2b @ 1
[   28.628701] aer 0000:00:05.0:pcie02: service driver aer loaded
[   28.648018] initcall aer_service_init+0x0/0x2b returned 0 after 19045 us=
ecs
[   28.671131] calling  pci_hotplug_init+0x0/0x1d @ 1
[   28.687144] pci_hotplug: PCI Hot Plug PCI Core version: 0.5
[   28.705737] initcall pci_hotplug_init+0x0/0x1d returned 0 after 18156 us=
ecs
[   28.728932] calling  pcifront_init+0x0/0x4f @ 1
[   28.744144] initcall pcifront_init+0x0/0x4f returned 0 after 57 usecs
[   28.765538] calling  fb_console_init+0x0/0x11d @ 1
[   28.781610] initcall fb_console_init+0x0/0x11d returned 0 after 59 usecs
[   28.803861] calling  genericbl_init+0x0/0x12 @ 1
[   28.819353] initcall genericbl_init+0x0/0x12 returned 0 after 52 usecs
[   28.841040] calling  xenfb_init+0x0/0x5d @ 1
[   28.855335] initcall xenfb_init+0x0/0x5d returned -19 after 0 usecs
[   28.876213] calling  efifb_init+0x0/0x1f5 @ 1
[   28.890803] initcall efifb_init+0x0/0x1f5 returned -19 after 3 usecs
[   28.911963] calling  acpi_reserve_resources+0x0/0xeb @ 1
[   28.929699] initcall acpi_reserve_resources+0x0/0xeb returned 0 after 2 =
usecs
[   28.953430] calling  irqrouter_init_sysfs+0x0/0x38 @ 1
[   28.970696] initcall irqrouter_init_sysfs+0x0/0x38 returned 0 after 99 u=
secs
[   28.994042] calling  acpi_ac_init+0x0/0x45 @ 1
[   29.008989] initcall acpi_ac_init+0x0/0x45 returned 0 after 73 usecs
[   29.030077] calling  acpi_button_init+0x0/0x56 @ 1
[   29.046201] input: Sleep Button as
/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0E:00/input/input0
[   29.073842] ACPI: Sleep Button [SLPB]
[   29.086229] input: Power Button as
/devices/LNXSYSTM:00/LNXPWRBN:00/input/input1
[   29.110725] ACPI: Power Button [PWRF]
[   29.123098] initcall acpi_button_init+0x0/0x56 returned 0 after 75200 us=
ecs
[   29.146193] calling  acpi_fan_init+0x0/0x56 @ 1
[   29.161409] initcall acpi_fan_init+0x0/0x56 returned 0 after 60 usecs
[   29.182800] calling  acpi_video_init+0x0/0x76 @ 1
[   29.198598] initcall acpi_video_init+0x0/0x76 returned 0 after 70 usecs
[   29.220551] calling  acpi_processor_init+0x0/0x136 @ 1
[   29.241016] initcall acpi_processor_init+0x0/0x136 returned 0 after
3226 usecs
[   29.264479] calling  acpi_container_init+0x0/0x42 @ 1
[   29.283573] initcall acpi_container_init+0x0/0x42 returned 0 after 2163 =
usecs
[   29.306749] calling  acpi_thermal_init+0x0/0x7b @ 1
[   29.323119] initcall acpi_thermal_init+0x0/0x7b returned 0 after 66 usecs
[   29.345647] calling  acpi_battery_init+0x0/0x16 @ 1
[   29.361949] initcall acpi_battery_init+0x0/0x16 returned 0 after 2 usecs
[   29.361988] calling  1_acpi_battery_init_async+0x0/0x3c @ 683
[   29.362066] initcall 1_acpi_battery_init_async+0x0/0x3c returned 0
after 72 usecs
[   29.428296] calling  xenbus_probe_initcall+0x0/0x37 @ 1
[   29.445744] initcall xenbus_probe_initcall+0x0/0x37 returned 0 after 0 u=
secs
[   29.469193] calling  evtchn_init+0x0/0x6e @ 1
[   29.483853] Event-channel device installed.
[   29.497796] initcall evtchn_init+0x0/0x6e returned 0 after 13689 usecs
[   29.519531] calling  gntdev_init+0x0/0x3d @ 1
[   29.534179] initcall gntdev_init+0x0/0x3d returned 0 after 64 usecs
[   29.554990] calling  pciback_init+0x0/0x151 @ 1
[   29.570311] initcall pciback_init+0x0/0x151 returned 0 after 159 usecs
[   29.591887] calling  blkif_init+0x0/0x17b @ 1
[   29.608285] initcall blkif_init+0x0/0x17b returned 0 after 1772 usecs
[   29.629177] calling  blktap_init+0x0/0xf1 @ 1
[   29.643759] blktap_device_init: blktap device major 253
[   29.661208] blktap_ring_init: blktap ring major: 251
[   29.678142] initcall blktap_init+0x0/0xf1 returned 0 after 33576 usecs
[   29.699531] calling  netback_init+0x0/0x3d7 @ 1
[   29.717007] registering netback
[   29.727151] initcall netback_init+0x0/0x3d7 returned 0 after 12172 usecs
[   29.749365] calling  xenfs_init+0x0/0x6a @ 1
[   29.763673] initcall xenfs_init+0x0/0x6a returned 0 after 10 usecs
[   29.784255] calling  hypervisor_subsys_init+0x0/0x25 @ 1
[   29.801986] initcall hypervisor_subsys_init+0x0/0x25 returned 0 after 0 =
usecs
[   29.825724] calling  hyper_sysfs_init+0x0/0xfb @ 1
[   29.841747] initcall hyper_sysfs_init+0x0/0xfb returned 0 after 7 usecs
[   29.863763] calling  rand_initialize+0x0/0x2c @ 1
[   29.879498] initcall rand_initialize+0x0/0x2c returned 0 after 9 usecs
[   29.901226] calling  tty_init+0x0/0xf5 @ 1
[   29.919028] initcall tty_init+0x0/0xf5 returned 0 after 3978 usecs
[   29.939058] calling  pty_init+0x0/0x336 @ 1
[   29.953154] initcall pty_init+0x0/0x336 returned 0 after 78 usecs
[   29.973376] calling  sysrq_init+0x0/0x25 @ 1
[   29.987681] initcall sysrq_init+0x0/0x25 returned 0 after 5 usecs
[   30.007981] calling  xen_hvc_init+0x0/0xf0 @ 1
[   30.022853]   alloc irq_desc for 1252 on node -1
[   30.038296]   alloc kstat_irqs on node -1
[   30.052237] initcall xen_hvc_init+0x0/0xf0 returned 0 after 28695 usecs
[   30.073760] calling  hpet_init+0x0/0x6a @ 1
[   30.087961] hpet_acpi_add: no address or irqs in _CRS
[   30.104710] initcall hpet_init+0x0/0x6a returned 0 after 16539 usecs
[   30.125810] calling  nvram_init+0x0/0x82 @ 1
[   30.140169] Non-volatile memory driver v1.3
[   30.154123] initcall nvram_init+0x0/0x82 returned 0 after 13684 usecs
[   30.175572] calling  mod_init+0x0/0x220 @ 1
[   30.189624] initcall mod_init+0x0/0x220 returned -19 after 37 usecs
[   30.210463] calling  mod_init+0x0/0xba @ 1
[   30.224200] initcall mod_init+0x0/0xba returned -19 after 8 usecs
[   30.244496] calling  mod_init+0x0/0x4d @ 1
[   30.258223] initcall mod_init+0x0/0x4d returned -19 after 0 usecs
[   30.278528] calling  agp_init+0x0/0x26 @ 1
[   30.292255] Linux agpgart interface v0.103
[   30.305985] initcall agp_init+0x0/0x26 returned 0 after 13406 usecs
[   30.326862] calling  agp_intel_init+0x0/0x29 @ 1
[   30.342379] initcall agp_intel_init+0x0/0x29 returned 0 after 71 usecs
[   30.364042] calling  drm_core_init+0x0/0x12d @ 1
[   30.379552] [drm] Initialized drm 1.1.0 20060810
[   30.394929] initcall drm_core_init+0x0/0x12d returned 0 after 15082 usecs
[   30.417520] calling  i915_init+0x0/0x52 @ 1
[   30.431570] initcall i915_init+0x0/0x52 returned 0 after 34 usecs
[   30.451841] calling  cn_proc_init+0x0/0x3d @ 1
[   30.466712] initcall cn_proc_init+0x0/0x3d returned 0 after 1 usecs
[   30.487590] calling  serial8250_init+0x0/0x143 @ 1
[   30.503603] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
[   30.524729] async_waiting @ 1
[   30.534493] async_continuing @ 1 after 0 usec
(XEN) irq.c:1139:d0 Cannot bind IRQ 4 to guest. In use by 'ns16550'.
(XEN) irq.c:1139:d0 Cannot bind IRQ 2 to guest. In use by 'cascade'.
(XEN) irq.c:1139:d0 Cannot bind IRQ 4 to guest. In use by 'ns16550'.
(XEN) irq.c:1139:d0 Cannot bind IRQ 2 to guest. In use by 'cascade'.
[   30.750139] async_waiting @ 1
[   30.759588] async_continuing @ 1 after 0 usec
(XEN) irq.c:1139:d0 Cannot bind IRQ 4 to guest. In use by 'ns16550'.
(XEN) irq.c:1139:d0 Cannot bind IRQ 2 to guest. In use by 'cascade'.
(XEN) irq.c:1139:d0 Cannot bind IRQ 4 to guest. In use by 'ns16550'.
(XEN) irq.c:1139:d0 Cannot bind IRQ 2 to guest. In use by 'cascade'.
[   30.975191] serial8250: ttyS1 at I/O 0x2f8 (irq =3D 3) is a 16550A
[   30.995161] initcall serial8250_init+0x0/0x143 returned 0 after 480031 u=
secs
[   31.018101] calling  serial8250_pnp_init+0x0/0x12 @ 1
[   31.035357] 00:09: ttyS1 at I/O 0x2f8 (irq =3D 3) is a 16550A
[   31.053682] initcall serial8250_pnp_init+0x0/0x12 returned 0 after
18267 usecs
[   31.077589] calling  serial8250_pci_init+0x0/0x1b @ 1
[   31.094540] initcall serial8250_pci_init+0x0/0x1b returned 0 after 74 us=
ecs
[   31.117630] calling  topology_sysfs_init+0x0/0x50 @ 1
[   31.134514] initcall topology_sysfs_init+0x0/0x50 returned 0 after 13 us=
ecs
[   31.157666] calling  brd_init+0x0/0x1c8 @ 1
[   31.173904] brd: module loaded
[   31.183638] initcall brd_init+0x0/0x1c8 returned 0 after 11677 usecs
[   31.204802] calling  loop_init+0x0/0x1d5 @ 1
[   31.270200] loop: module loaded
[   31.280224] initcall loop_init+0x0/0x1d5 returned 0 after 59689 usecs
[   31.301672] calling  xlblk_init+0x0/0x7a @ 1
[   31.316024] initcall xlblk_init+0x0/0x7a returned 0 after 52 usecs
[   31.336560] calling  mac_hid_init+0x0/0x8e @ 1
[   31.351525] input: Macintosh mouse button emulation as
/devices/virtual/input/input2
[   31.377185] initcall mac_hid_init+0x0/0x8e returned 0 after 25148 usecs
[   31.399192] calling  spi_transport_init+0x0/0x79 @ 1
[   31.415880] initcall spi_transport_init+0x0/0x79 returned 0 after 96 use=
cs
[   31.438659] calling  twa_init+0x0/0x30 @ 1
[   31.452385] 3ware 9000 Storage Controller device driver for Linux
v2.26.02.012.
[   31.476716] xen: registering gsi 16 triggering 0 polarity 1
[   31.495286] xen_allocate_pirq: returning irq 16 for gsi 16
[   31.513589] xen: --> irq=3D16
[   31.523039] Already setup the GSI :16
[   31.535324] 3w-9xxx 0000:01:00.0: PCI INT A -> GSI 16 (level, low) -> IR=
Q 16
[   31.558779] 3w-9xxx 0000:01:00.0: setting latency timer to 64
[   31.832075] 3w-9xxx: scsi0: AEN: INFO (0x04:0x0053): Battery
capacity test is overdue:.
[   31.934073] 3w-9xxx: scsi0: AEN: INFO (0x04:0x0053): Battery
capacity test is overdue:.
[   32.036072] scsi0 : 3ware 9000 Storage Controller
[   32.051530] 3w-9xxx: scsi0: Found a 3ware 9000 Storage Controller
at 0xb3a00000, IRQ: 16.
[   32.384072] 3w-9xxx: scsi0: Firmware FH9X 4.10.00.021, BIOS BE9X
4.08.00.003, Ports: 128.
[   32.411054] scsi 0:0:0:0: Direct-Access     AMCC     9690SA-4I
DISK  4.10 PQ: 0 ANSI: 5
[   32.446653] initcall twa_init+0x0/0x30 returned 0 after 970962 usecs
[   32.467256] calling  init_sd+0x0/0x142 @ 1
[   32.481169] calling  2_sd_probe_async+0x0/0x1dc @ 1352
[   32.481210] initcall init_sd+0x0/0x142 returned 0 after 215 usecs
[   32.481212] calling  init_sr+0x0/0x46 @ 1
[   32.481266] initcall init_sr+0x0/0x46 returned 0 after 49 usecs
[   32.481269] calling  init_sg+0x0/0x125 @ 1
[   32.481394] sd 0:0:0:0: Attached scsi generic sg0 type 0
[   32.481408] initcall init_sg+0x0/0x125 returned 0 after 133 usecs
[   32.481411] calling  ahci_init+0x0/0x1b @ 1
[   32.481476] initcall ahci_init+0x0/0x1b returned 0 after 60 usecs
[   32.481479] calling  piix_init+0x0/0x29 @ 1
[   32.481537] initcall piix_init+0x0/0x29 returned 0 after 53 usecs
[   32.481539] calling  amd_init+0x0/0x1b @ 1
[   32.481596] initcall amd_init+0x0/0x1b returned 0 after 52 usecs
[   32.481598] calling  mpiix_init+0x0/0x1b @ 1
[   32.481653] initcall mpiix_init+0x0/0x1b returned 0 after 50 usecs
[   32.481656] calling  oldpiix_init+0x0/0x1b @ 1
[   32.481710] initcall oldpiix_init+0x0/0x1b returned 0 after 50 usecs
[   32.481713] calling  sch_init+0x0/0x1b @ 1
[   32.481767] initcall sch_init+0x0/0x1b returned 0 after 49 usecs
[   32.481769] calling  ata_generic_init+0x0/0x1b @ 1
[   32.481824] initcall ata_generic_init+0x0/0x1b returned 0 after 50 usecs
[   32.481827] calling  e1000_init_module+0x0/0x87 @ 1
[   32.481829] Intel(R) PRO/1000 Network Driver - version 7.3.21-k5-NAPI
[   32.481830] Copyright (c) 1999-2006 Intel Corporation.
[   32.481889] initcall e1000_init_module+0x0/0x87 returned 0 after 57 usecs
[   32.481892] calling  e1000_init_module+0x0/0x6b @ 1
[   32.481894] e1000e: Intel(R) PRO/1000 Network Driver - 1.0.2-k2
[   32.481895] e1000e: Copyright (c) 1999-2008 Intel Corporation.
[   32.481936] xen: registering gsi 16 triggering 0 polarity 1
[   32.481937] xen_allocate_pirq: returning irq 16 for gsi 16
[   32.481939] xen: --> irq=3D16
[   32.481941] Already setup the GSI :16
[   32.481943] e1000e 0000:00:19.0: PCI INT A -> GSI 16 (level, low) -> IRQ=
 16
[   32.481951] e1000e 0000:00:19.0: setting latency timer to 64
[   32.482075]   alloc irq_desc for 1251 on node -1
[   32.482076]   alloc kstat_irqs on node -1
[   33.111523] sd 0:0:0:0: [sda] 2929666048 512-byte logical blocks:
(1.49 TB/1.36 TiB)
[   33.137722] sd 0:0:0:0: [sda] Write Protect is off
[   33.153176] sd 0:0:0:0: [sda] Mode Sense: 23 00 10 00
[   33.172013] sd 0:0:0:0: [sda] Write cache: enabled, read cache:
enabled, supports DPO and FUA
[   33.201332]  sda: sda1 sda2 < sda5 sda6 sda7 sda8 sda9 >
[   33.266171] sd 0:0:0:0: [sda] Attached SCSI disk
[   33.281064] initcall 2_sd_probe_async+0x0/0x1dc returned 0 after 165744 =
usecs

then it hangs
thanks for your help

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 18:41:37 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 18:41:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RatlO-0004L9-F6; Wed, 14 Dec 2011 18:41:10 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <george.shuklin@gmail.com>) id 1RatlN-0004Kw-28
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 18:41:09 +0000
X-Env-Sender: george.shuklin@gmail.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1323888012!5558004!1
X-Originating-IP: [209.85.215.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12420 invoked from network); 14 Dec 2011 18:40:12 -0000
Received: from mail-ey0-f171.google.com (HELO mail-ey0-f171.google.com)
	(209.85.215.171)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Dec 2011 18:40:12 -0000
Received: by eaa1 with SMTP id 1so3518264eaa.30
	for <xen-devel@lists.xensource.com>;
	Wed, 14 Dec 2011 10:40:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=message-id:date:from:user-agent:mime-version:to:cc:subject
	:references:in-reply-to:content-type:content-transfer-encoding;
	bh=JC5G6wbTVwcqZhlAms+uyRzP0XvWH3H2sqt7UYwkW40=;
	b=DDKiESRkERd9WIa5sETAl1af22DJfkddRq2q3RH5rEDeVZXx3GsFY6NtvC9wawAtSs
	LL7KOgNUdSus6eSc2RIIeb+W56H6+z3s9E5LD2EDhv2n9dA89rRhTQ7sLeLYvdf7Fq8z
	X4leO2DjWXqC470qr1K/BS6InzLSYHLkxijXU=
Received: by 10.204.34.148 with SMTP id l20mr1784556bkd.55.1323888011328;
	Wed, 14 Dec 2011 10:40:11 -0800 (PST)
Received: from [192.168.40.44] (officecvt.selectel.ru. [188.93.16.50])
	by mx.google.com with ESMTPS id t6sm8044079bka.12.2011.12.14.10.40.09
	(version=SSLv3 cipher=OTHER); Wed, 14 Dec 2011 10:40:10 -0800 (PST)
Message-ID: <4EE8ED88.8060107@gmail.com>
Date: Wed, 14 Dec 2011 22:40:08 +0400
From: George Shuklin <george.shuklin@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:9.0) Gecko/20111209 Thunderbird/9.0
MIME-Version: 1.0
To: "Fajar A. Nugraha" <list@fajar.net>
References: <4EE675A8.3030609@niemail.de> <4EE71663.5040308@gmail.com>
	<CAJeBh4sxdNTxM_oLFAuA6Mw75=LaYysrpS5b8NsZMbkf_swNVw@mail.gmail.com>
	<4EE72A94.6040904@gmail.com> <4EE75080.1000909@citrix.com>
	<4EE7BE1B.6070509@gmail.com>
	<CAG1y0sfbgrCsgLgF5-PZ24vzznwTjrPHkWMwAJO7qKYnVT+ODg@mail.gmail.com>
In-Reply-To: <CAG1y0sfbgrCsgLgF5-PZ24vzznwTjrPHkWMwAJO7qKYnVT+ODg@mail.gmail.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] a ton of kernel issues
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 14.12.2011 11:47, Fajar A. Nugraha wrote:
>> Well... For us it make HUGE difference. We running cloud with very precise
>> accounting of  fast automaric memory allocation for customer's domains and
>> we account them for ... em... KiB*hr value, so if we account domains based
>> on xc.get_domain_memkb value and customers saw difference between TotalMem
>> and our values this will make them feel like we cheating. We not greedy and
>> ready to 'cut' our mem_kb value to their TotalMem, but I hasn't found any
>> formula for that (calculate TotalMem from static-max and dom_kb values) and
>> I can't trust any data from customer's domains (except request for memory we
>> accept, serve and happily take money for 'more memory').
>>
>> It sounds ridiculous, but we avoiding pv_ops kernels usage due that little
>> ~50Mb steal. We stuck with -xen kernels (forward porting from SUSE and
>> native CentOS 2.6.18-xen). I don't know what we will do in the future, but
>> right now PV-ops is not good...
> Why not just explain what really happened in a noob-friendly language?
>
> For example, when buying a computer with built-in graphic card,
> MemTotal is always lower than the ammount of memory actually
> installed. Yet a simple explanation "some of the memory is used by the
> built-in graphic card" is enough, without having to go into details of
> what is the formula to calculate how much memory actualy used.
>
Well, this is fine if we provide customers normal 'VDS-like' virtual 
machines. You getting 256MiB, some of it is used by kernel and not 
displayed as TotalMem. But we provide vm with ellastic memory (like 
256MiB - 8GiB) with promise 'we will serve you enough memory to your 
applications and you will pay only for allocated memory for your VM'. 
User expects we give him + 2GiB for 2 min and we charge him for 
2*2/60=0.066 GiB*hr. With -xen kernels they got exactly they paid (at 
least, with TotalMem value). If we saying them 'here something you don't 
understand' this will cause some doubts.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 18:41:37 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 18:41:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RatlO-0004L9-F6; Wed, 14 Dec 2011 18:41:10 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <george.shuklin@gmail.com>) id 1RatlN-0004Kw-28
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 18:41:09 +0000
X-Env-Sender: george.shuklin@gmail.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1323888012!5558004!1
X-Originating-IP: [209.85.215.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12420 invoked from network); 14 Dec 2011 18:40:12 -0000
Received: from mail-ey0-f171.google.com (HELO mail-ey0-f171.google.com)
	(209.85.215.171)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Dec 2011 18:40:12 -0000
Received: by eaa1 with SMTP id 1so3518264eaa.30
	for <xen-devel@lists.xensource.com>;
	Wed, 14 Dec 2011 10:40:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=message-id:date:from:user-agent:mime-version:to:cc:subject
	:references:in-reply-to:content-type:content-transfer-encoding;
	bh=JC5G6wbTVwcqZhlAms+uyRzP0XvWH3H2sqt7UYwkW40=;
	b=DDKiESRkERd9WIa5sETAl1af22DJfkddRq2q3RH5rEDeVZXx3GsFY6NtvC9wawAtSs
	LL7KOgNUdSus6eSc2RIIeb+W56H6+z3s9E5LD2EDhv2n9dA89rRhTQ7sLeLYvdf7Fq8z
	X4leO2DjWXqC470qr1K/BS6InzLSYHLkxijXU=
Received: by 10.204.34.148 with SMTP id l20mr1784556bkd.55.1323888011328;
	Wed, 14 Dec 2011 10:40:11 -0800 (PST)
Received: from [192.168.40.44] (officecvt.selectel.ru. [188.93.16.50])
	by mx.google.com with ESMTPS id t6sm8044079bka.12.2011.12.14.10.40.09
	(version=SSLv3 cipher=OTHER); Wed, 14 Dec 2011 10:40:10 -0800 (PST)
Message-ID: <4EE8ED88.8060107@gmail.com>
Date: Wed, 14 Dec 2011 22:40:08 +0400
From: George Shuklin <george.shuklin@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:9.0) Gecko/20111209 Thunderbird/9.0
MIME-Version: 1.0
To: "Fajar A. Nugraha" <list@fajar.net>
References: <4EE675A8.3030609@niemail.de> <4EE71663.5040308@gmail.com>
	<CAJeBh4sxdNTxM_oLFAuA6Mw75=LaYysrpS5b8NsZMbkf_swNVw@mail.gmail.com>
	<4EE72A94.6040904@gmail.com> <4EE75080.1000909@citrix.com>
	<4EE7BE1B.6070509@gmail.com>
	<CAG1y0sfbgrCsgLgF5-PZ24vzznwTjrPHkWMwAJO7qKYnVT+ODg@mail.gmail.com>
In-Reply-To: <CAG1y0sfbgrCsgLgF5-PZ24vzznwTjrPHkWMwAJO7qKYnVT+ODg@mail.gmail.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] a ton of kernel issues
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 14.12.2011 11:47, Fajar A. Nugraha wrote:
>> Well... For us it make HUGE difference. We running cloud with very precise
>> accounting of  fast automaric memory allocation for customer's domains and
>> we account them for ... em... KiB*hr value, so if we account domains based
>> on xc.get_domain_memkb value and customers saw difference between TotalMem
>> and our values this will make them feel like we cheating. We not greedy and
>> ready to 'cut' our mem_kb value to their TotalMem, but I hasn't found any
>> formula for that (calculate TotalMem from static-max and dom_kb values) and
>> I can't trust any data from customer's domains (except request for memory we
>> accept, serve and happily take money for 'more memory').
>>
>> It sounds ridiculous, but we avoiding pv_ops kernels usage due that little
>> ~50Mb steal. We stuck with -xen kernels (forward porting from SUSE and
>> native CentOS 2.6.18-xen). I don't know what we will do in the future, but
>> right now PV-ops is not good...
> Why not just explain what really happened in a noob-friendly language?
>
> For example, when buying a computer with built-in graphic card,
> MemTotal is always lower than the ammount of memory actually
> installed. Yet a simple explanation "some of the memory is used by the
> built-in graphic card" is enough, without having to go into details of
> what is the formula to calculate how much memory actualy used.
>
Well, this is fine if we provide customers normal 'VDS-like' virtual 
machines. You getting 256MiB, some of it is used by kernel and not 
displayed as TotalMem. But we provide vm with ellastic memory (like 
256MiB - 8GiB) with promise 'we will serve you enough memory to your 
applications and you will pay only for allocated memory for your VM'. 
User expects we give him + 2GiB for 2 min and we charge him for 
2*2/60=0.066 GiB*hr. With -xen kernels they got exactly they paid (at 
least, with TotalMem value). If we saying them 'here something you don't 
understand' this will cause some doubts.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 18:57:08 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 18:57:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rau0T-0005Db-Di; Wed, 14 Dec 2011 18:56:45 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Rau0R-0005DJ-Hr
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 18:56:43 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1323888908!47892214!1
X-Originating-IP: [141.146.126.236]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG,
	UNPARSEABLE_RELAY
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16451 invoked from network); 14 Dec 2011 18:55:09 -0000
Received: from acsinet14.oracle.com (HELO acsinet14.oracle.com)
	(141.146.126.236)
	by server-10.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Dec 2011 18:55:09 -0000
Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227])
	by acsinet14.oracle.com (Switch-3.4.4/Switch-3.4.1) with ESMTP id
	pBEItlE7011754
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK)
	for <xen-devel@lists.xensource.com>; Wed, 14 Dec 2011 18:55:48 GMT
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pBEItbRh001295
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 14 Dec 2011 18:55:38 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pBEItYf5024651
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 14 Dec 2011 18:55:34 GMT
Received: from abhmt106.oracle.com (abhmt106.oracle.com [141.146.116.58])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pBEItVYp024988; Wed, 14 Dec 2011 12:55:32 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 14 Dec 2011 10:55:31 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 787E241C13; Wed, 14 Dec 2011 13:54:40 -0500 (EST)
Date: Wed, 14 Dec 2011 13:54:40 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: annie.li@oracle.com
Message-ID: <20111214185440.GB24598@phenom.dumpdata.com>
References: <1323684792-5101-1-git-send-email-annie.li@oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1323684792-5101-1-git-send-email-annie.li@oracle.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090204.4EE8F12A.007B,ss=1,re=0.000,fgs=0
Cc: jeremy@goop.org, xen-devel@lists.xensource.com, Ian.Campbell@citrix.com,
	kurt.hackel@oracle.com, linux-kernel@vger.kernel.org,
	paul.durrant@citrix.com
Subject: Re: [Xen-devel] [PATCH V4 0/3] xen: patches for supporting sub-page
 and transitive grants
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Dec 12, 2011 at 06:13:12PM +0800, annie.li@oracle.com wrote:
> Hi
> 
> Following patches introduce and implement interfaces for sub-page and transitive grants, and they are based on linux-next branch of linux/kernel/git/konrad/xen.git(3.2.0-rc2+). Sub-page and transitive grants are new types of grant table V2.
> 
> Descriptions for those patches:
> 
> Through sub-page grant table interfaces, a domain can grant another domain access to a range of bytes within a page, and Xen will then prevent the grantee domain accessing outside that range.  For obvious reasons, it isn't possible to map these grant references, and domains are expected to use the grant copy hypercall instead.
> 
> Through transitive grant interfaces,  a domain can create grant reference which redirects to another grant reference, so that any attempt to access the first grant reference will be redirected to the second one.  This is used to implement receiver-side copy on inter-domain traffic: rather than copying the packet in dom0, dom0 creates a transitive grant referencing the original transmit buffer, and passes that to the receiving domain.
> 

Applied.

> Annie Li (3):
>   xen/granttable: Improve comments for function pointers
>   xen/granttable: Support sub-page grants
>   xen/granttable: Support transitive grants
> 
>  drivers/xen/grant-table.c |  190 +++++++++++++++++++++++++++++++++++++++------
>  include/xen/grant_table.h |   25 ++++++
>  2 files changed, 191 insertions(+), 24 deletions(-)
> 
> Thanks,
> Annie.
> -- 
> 1.7.6.4

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 18:57:08 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 18:57:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rau0T-0005Db-Di; Wed, 14 Dec 2011 18:56:45 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Rau0R-0005DJ-Hr
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 18:56:43 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1323888908!47892214!1
X-Originating-IP: [141.146.126.236]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG,
	UNPARSEABLE_RELAY
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16451 invoked from network); 14 Dec 2011 18:55:09 -0000
Received: from acsinet14.oracle.com (HELO acsinet14.oracle.com)
	(141.146.126.236)
	by server-10.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Dec 2011 18:55:09 -0000
Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227])
	by acsinet14.oracle.com (Switch-3.4.4/Switch-3.4.1) with ESMTP id
	pBEItlE7011754
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK)
	for <xen-devel@lists.xensource.com>; Wed, 14 Dec 2011 18:55:48 GMT
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pBEItbRh001295
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 14 Dec 2011 18:55:38 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pBEItYf5024651
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 14 Dec 2011 18:55:34 GMT
Received: from abhmt106.oracle.com (abhmt106.oracle.com [141.146.116.58])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pBEItVYp024988; Wed, 14 Dec 2011 12:55:32 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 14 Dec 2011 10:55:31 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 787E241C13; Wed, 14 Dec 2011 13:54:40 -0500 (EST)
Date: Wed, 14 Dec 2011 13:54:40 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: annie.li@oracle.com
Message-ID: <20111214185440.GB24598@phenom.dumpdata.com>
References: <1323684792-5101-1-git-send-email-annie.li@oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1323684792-5101-1-git-send-email-annie.li@oracle.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090204.4EE8F12A.007B,ss=1,re=0.000,fgs=0
Cc: jeremy@goop.org, xen-devel@lists.xensource.com, Ian.Campbell@citrix.com,
	kurt.hackel@oracle.com, linux-kernel@vger.kernel.org,
	paul.durrant@citrix.com
Subject: Re: [Xen-devel] [PATCH V4 0/3] xen: patches for supporting sub-page
 and transitive grants
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Dec 12, 2011 at 06:13:12PM +0800, annie.li@oracle.com wrote:
> Hi
> 
> Following patches introduce and implement interfaces for sub-page and transitive grants, and they are based on linux-next branch of linux/kernel/git/konrad/xen.git(3.2.0-rc2+). Sub-page and transitive grants are new types of grant table V2.
> 
> Descriptions for those patches:
> 
> Through sub-page grant table interfaces, a domain can grant another domain access to a range of bytes within a page, and Xen will then prevent the grantee domain accessing outside that range.  For obvious reasons, it isn't possible to map these grant references, and domains are expected to use the grant copy hypercall instead.
> 
> Through transitive grant interfaces,  a domain can create grant reference which redirects to another grant reference, so that any attempt to access the first grant reference will be redirected to the second one.  This is used to implement receiver-side copy on inter-domain traffic: rather than copying the packet in dom0, dom0 creates a transitive grant referencing the original transmit buffer, and passes that to the receiving domain.
> 

Applied.

> Annie Li (3):
>   xen/granttable: Improve comments for function pointers
>   xen/granttable: Support sub-page grants
>   xen/granttable: Support transitive grants
> 
>  drivers/xen/grant-table.c |  190 +++++++++++++++++++++++++++++++++++++++------
>  include/xen/grant_table.h |   25 ++++++
>  2 files changed, 191 insertions(+), 24 deletions(-)
> 
> Thanks,
> Annie.
> -- 
> 1.7.6.4

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 18:58:33 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 18:58:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rau1q-0005JE-UA; Wed, 14 Dec 2011 18:58:10 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Rau1o-0005Io-SQ
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 18:58:09 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1323888998!56710333!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQzNjE5Mw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7868 invoked from network); 14 Dec 2011 18:56:39 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-9.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Dec 2011 18:56:39 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pBEIvBF7003379
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 14 Dec 2011 18:57:11 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pBEIvAvO003899
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 14 Dec 2011 18:57:10 GMT
Received: from abhmt112.oracle.com (abhmt112.oracle.com [141.146.116.64])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pBEIv9kQ026131; Wed, 14 Dec 2011 12:57:09 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 14 Dec 2011 10:57:09 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 5FB5341C13; Wed, 14 Dec 2011 13:56:18 -0500 (EST)
Date: Wed, 14 Dec 2011 13:56:18 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Message-ID: <20111214185618.GC24598@phenom.dumpdata.com>
References: <20111128152031.GB9655@andromeda.dapyr.net>
	<1322498951-4392-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1322498951-4392-8-git-send-email-dgdegra@tycho.nsa.gov>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1322498951-4392-8-git-send-email-dgdegra@tycho.nsa.gov>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090208.4EE8F188.0058,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com, david.vrabel@citrix.com, JBeulich@suse.com,
	Ian.Campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH 07/12] xen/event: Add reference counting to
	event channels
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Nov 28, 2011 at 11:49:06AM -0500, Daniel De Graaf wrote:
> Event channels exposed to userspace by the evtchn module may be used by
> other modules in an asynchronous manner, which requires that reference
> counting be used to prevent the event channel from being closed before
> the signals are delivered.
> 
> The reference count on new event channels defaults to -1 which indicates
> the event channel is not referenced outside the kernel; evtchn_get fails
> if called on such an event channel. The event channels made visible to
> userspace by evtchn have a normal reference count.

So I've 7 through 12 in my branch now. (7,8 and 9 are in the #linux-next
and the 10-12 are in the #testing).

The other 1-6 you have might need to be parceled out (especially the netback
one which usually goes through David Miller). Also I have to double-check -
but did somebody review those 1-6 patches?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 18:58:33 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 18:58:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rau1q-0005JE-UA; Wed, 14 Dec 2011 18:58:10 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Rau1o-0005Io-SQ
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 18:58:09 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1323888998!56710333!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQzNjE5Mw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7868 invoked from network); 14 Dec 2011 18:56:39 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-9.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Dec 2011 18:56:39 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pBEIvBF7003379
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 14 Dec 2011 18:57:11 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pBEIvAvO003899
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 14 Dec 2011 18:57:10 GMT
Received: from abhmt112.oracle.com (abhmt112.oracle.com [141.146.116.64])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pBEIv9kQ026131; Wed, 14 Dec 2011 12:57:09 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 14 Dec 2011 10:57:09 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 5FB5341C13; Wed, 14 Dec 2011 13:56:18 -0500 (EST)
Date: Wed, 14 Dec 2011 13:56:18 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Message-ID: <20111214185618.GC24598@phenom.dumpdata.com>
References: <20111128152031.GB9655@andromeda.dapyr.net>
	<1322498951-4392-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1322498951-4392-8-git-send-email-dgdegra@tycho.nsa.gov>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1322498951-4392-8-git-send-email-dgdegra@tycho.nsa.gov>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090208.4EE8F188.0058,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com, david.vrabel@citrix.com, JBeulich@suse.com,
	Ian.Campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH 07/12] xen/event: Add reference counting to
	event channels
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Nov 28, 2011 at 11:49:06AM -0500, Daniel De Graaf wrote:
> Event channels exposed to userspace by the evtchn module may be used by
> other modules in an asynchronous manner, which requires that reference
> counting be used to prevent the event channel from being closed before
> the signals are delivered.
> 
> The reference count on new event channels defaults to -1 which indicates
> the event channel is not referenced outside the kernel; evtchn_get fails
> if called on such an event channel. The event channels made visible to
> userspace by evtchn have a normal reference count.

So I've 7 through 12 in my branch now. (7,8 and 9 are in the #linux-next
and the 10-12 are in the #testing).

The other 1-6 you have might need to be parceled out (especially the netback
one which usually goes through David Miller). Also I have to double-check -
but did somebody review those 1-6 patches?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 18:58:42 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 18: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.xensource.com>)
	id 1Rau25-0005Kr-BD; Wed, 14 Dec 2011 18:58:25 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Rau23-0005K3-T1
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 18:58:24 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1323889046!8243595!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDM5MDM1\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6287 invoked from network); 14 Dec 2011 18:57:28 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-15.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Dec 2011 18:57:28 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pBEItTDD021089
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 14 Dec 2011 18:55:32 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pBEItRje015834
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 14 Dec 2011 18:55:28 GMT
Received: from abhmt108.oracle.com (abhmt108.oracle.com [141.146.116.60])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pBEItR7n024931; Wed, 14 Dec 2011 12:55:27 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 14 Dec 2011 10:55:27 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 3E5C441C13; Wed, 14 Dec 2011 13:54:36 -0500 (EST)
Date: Wed, 14 Dec 2011 13:54:36 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Bastian Blank <waldi@debian.org>
Message-ID: <20111214185436.GA24598@phenom.dumpdata.com>
References: <1323541791-18006-1-git-send-email-waldi@debian.org>
	<1323541791-18006-2-git-send-email-waldi@debian.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1323541791-18006-2-git-send-email-waldi@debian.org>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090204.4EE8F177.00F0,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH 1/6] xen: Add privcmd device driver
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Sat, Dec 10, 2011 at 07:29:46PM +0100, Bastian Blank wrote:
> Access to arbitrary hypercalls is currently provided via xenfs. This
> adds a standard character device to handle this. The support in xenfs
> remains for backward compatibility and uses the device driver code.

Bastian Blank (5):
      xen: Add privcmd device driver
      xen: Add xenbus device driver
      xen: Add xenbus_backend device
      xen/privcmd: Remove unused support for arch specific privcmp mmap
      xen/xenbus-frontend: Make error message more clear

Will wait for the re-worked sixth patch from you.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 18:58:42 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 18: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.xensource.com>)
	id 1Rau25-0005Kr-BD; Wed, 14 Dec 2011 18:58:25 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Rau23-0005K3-T1
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 18:58:24 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1323889046!8243595!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDM5MDM1\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6287 invoked from network); 14 Dec 2011 18:57:28 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-15.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Dec 2011 18:57:28 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pBEItTDD021089
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 14 Dec 2011 18:55:32 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pBEItRje015834
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 14 Dec 2011 18:55:28 GMT
Received: from abhmt108.oracle.com (abhmt108.oracle.com [141.146.116.60])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pBEItR7n024931; Wed, 14 Dec 2011 12:55:27 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 14 Dec 2011 10:55:27 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 3E5C441C13; Wed, 14 Dec 2011 13:54:36 -0500 (EST)
Date: Wed, 14 Dec 2011 13:54:36 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Bastian Blank <waldi@debian.org>
Message-ID: <20111214185436.GA24598@phenom.dumpdata.com>
References: <1323541791-18006-1-git-send-email-waldi@debian.org>
	<1323541791-18006-2-git-send-email-waldi@debian.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1323541791-18006-2-git-send-email-waldi@debian.org>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090204.4EE8F177.00F0,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH 1/6] xen: Add privcmd device driver
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Sat, Dec 10, 2011 at 07:29:46PM +0100, Bastian Blank wrote:
> Access to arbitrary hypercalls is currently provided via xenfs. This
> adds a standard character device to handle this. The support in xenfs
> remains for backward compatibility and uses the device driver code.

Bastian Blank (5):
      xen: Add privcmd device driver
      xen: Add xenbus device driver
      xen: Add xenbus_backend device
      xen/privcmd: Remove unused support for arch specific privcmp mmap
      xen/xenbus-frontend: Make error message more clear

Will wait for the re-worked sixth patch from you.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 18:58:49 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 18: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.xensource.com>)
	id 1Rau2G-0005NC-QC; Wed, 14 Dec 2011 18:58:36 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Rau2F-0005Lv-4B
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 18:58:35 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1323889058!8268253!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQzNjE5Mw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4249 invoked from network); 14 Dec 2011 18:57:39 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-3.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Dec 2011 18:57:39 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pBEIvYxk003835
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 14 Dec 2011 18:57:35 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pBEIvWWl019071
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 14 Dec 2011 18:57:33 GMT
Received: from abhmt106.oracle.com (abhmt106.oracle.com [141.146.116.58])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pBEIvWwj011210; Wed, 14 Dec 2011 12:57:32 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 14 Dec 2011 10:57:32 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id BD0BC41C13; Wed, 14 Dec 2011 13:56:41 -0500 (EST)
Date: Wed, 14 Dec 2011 13:56:41 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Thomas Meyer <thomas@m3y3r.de>
Message-ID: <20111214185641.GD24598@phenom.dumpdata.com>
References: <1322600880.1534.293.camel@localhost.localdomain>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1322600880.1534.293.camel@localhost.localdomain>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090202.4EE8F19F.00DA,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org,
	virtualization@lists.linux-foundation.org
Subject: Re: [Xen-devel] [PATCH] xen-blkfront: Use kcalloc instead of
 kzalloc to allocate array
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Nov 29, 2011 at 10:08:00PM +0100, Thomas Meyer wrote:
> The advantage of kcalloc is, that will prevent integer overflows which could
> result from the multiplication of number of elements and size and it is also
> a bit nicer to read.
> 
> The semantic patch that makes this change is available
> in https://lkml.org/lkml/2011/11/25/107
> 

Thomas,

I put the xen-blkfront part of the patch in my tree and dropped the cciss_scsi one.

> Signed-off-by: Thomas Meyer <thomas@m3y3r.de>
> ---
> 
> diff -u -p a/drivers/block/cciss_scsi.c b/drivers/block/cciss_scsi.c
> --- a/drivers/block/cciss_scsi.c 2011-11-28 19:36:47.343430551 +0100
> +++ b/drivers/block/cciss_scsi.c 2011-11-28 19:49:24.922716381 +0100
> @@ -534,10 +534,10 @@ adjust_cciss_scsi_table(ctlr_info_t *h,
>  	int nadded, nremoved;
>  	struct Scsi_Host *sh = NULL;
>  
> -	added = kzalloc(sizeof(*added) * CCISS_MAX_SCSI_DEVS_PER_HBA,
> -			GFP_KERNEL);
> -	removed = kzalloc(sizeof(*removed) * CCISS_MAX_SCSI_DEVS_PER_HBA,
> +	added = kcalloc(CCISS_MAX_SCSI_DEVS_PER_HBA, sizeof(*added),
>  			GFP_KERNEL);
> +	removed = kcalloc(CCISS_MAX_SCSI_DEVS_PER_HBA, sizeof(*removed),
> +			  GFP_KERNEL);
>  
>  	if (!added || !removed) {
>  		dev_warn(&h->pdev->dev,
> @@ -1191,8 +1191,8 @@ cciss_update_non_disk_devices(ctlr_info_
>  
>  	ld_buff = kzalloc(reportlunsize, GFP_KERNEL);
>  	inq_buff = kmalloc(OBDR_TAPE_INQ_SIZE, GFP_KERNEL);
> -	currentsd = kzalloc(sizeof(*currentsd) *
> -			(CCISS_MAX_SCSI_DEVS_PER_HBA+1), GFP_KERNEL);
> +	currentsd = kcalloc(CCISS_MAX_SCSI_DEVS_PER_HBA + 1,
> +			    sizeof(*currentsd), GFP_KERNEL);
>  	if (ld_buff == NULL || inq_buff == NULL || currentsd == NULL) {
>  		printk(KERN_ERR "cciss: out of memory\n");
>  		goto out;
> diff -u -p a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
> --- a/drivers/block/xen-blkfront.c 2011-11-13 11:07:22.680095573 +0100
> +++ b/drivers/block/xen-blkfront.c 2011-11-28 19:49:29.109460410 +0100
> @@ -156,7 +156,7 @@ static int xlbd_reserve_minors(unsigned
>  	if (end > nr_minors) {
>  		unsigned long *bitmap, *old;
>  
> -		bitmap = kzalloc(BITS_TO_LONGS(end) * sizeof(*bitmap),
> +		bitmap = kcalloc(BITS_TO_LONGS(end), sizeof(*bitmap),
>  				 GFP_KERNEL);
>  		if (bitmap == NULL)
>  			return -ENOMEM;
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 18:58:49 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 18: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.xensource.com>)
	id 1Rau2G-0005NC-QC; Wed, 14 Dec 2011 18:58:36 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Rau2F-0005Lv-4B
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 18:58:35 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1323889058!8268253!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQzNjE5Mw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4249 invoked from network); 14 Dec 2011 18:57:39 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-3.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Dec 2011 18:57:39 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pBEIvYxk003835
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 14 Dec 2011 18:57:35 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pBEIvWWl019071
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 14 Dec 2011 18:57:33 GMT
Received: from abhmt106.oracle.com (abhmt106.oracle.com [141.146.116.58])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pBEIvWwj011210; Wed, 14 Dec 2011 12:57:32 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 14 Dec 2011 10:57:32 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id BD0BC41C13; Wed, 14 Dec 2011 13:56:41 -0500 (EST)
Date: Wed, 14 Dec 2011 13:56:41 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Thomas Meyer <thomas@m3y3r.de>
Message-ID: <20111214185641.GD24598@phenom.dumpdata.com>
References: <1322600880.1534.293.camel@localhost.localdomain>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1322600880.1534.293.camel@localhost.localdomain>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090202.4EE8F19F.00DA,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org,
	virtualization@lists.linux-foundation.org
Subject: Re: [Xen-devel] [PATCH] xen-blkfront: Use kcalloc instead of
 kzalloc to allocate array
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Nov 29, 2011 at 10:08:00PM +0100, Thomas Meyer wrote:
> The advantage of kcalloc is, that will prevent integer overflows which could
> result from the multiplication of number of elements and size and it is also
> a bit nicer to read.
> 
> The semantic patch that makes this change is available
> in https://lkml.org/lkml/2011/11/25/107
> 

Thomas,

I put the xen-blkfront part of the patch in my tree and dropped the cciss_scsi one.

> Signed-off-by: Thomas Meyer <thomas@m3y3r.de>
> ---
> 
> diff -u -p a/drivers/block/cciss_scsi.c b/drivers/block/cciss_scsi.c
> --- a/drivers/block/cciss_scsi.c 2011-11-28 19:36:47.343430551 +0100
> +++ b/drivers/block/cciss_scsi.c 2011-11-28 19:49:24.922716381 +0100
> @@ -534,10 +534,10 @@ adjust_cciss_scsi_table(ctlr_info_t *h,
>  	int nadded, nremoved;
>  	struct Scsi_Host *sh = NULL;
>  
> -	added = kzalloc(sizeof(*added) * CCISS_MAX_SCSI_DEVS_PER_HBA,
> -			GFP_KERNEL);
> -	removed = kzalloc(sizeof(*removed) * CCISS_MAX_SCSI_DEVS_PER_HBA,
> +	added = kcalloc(CCISS_MAX_SCSI_DEVS_PER_HBA, sizeof(*added),
>  			GFP_KERNEL);
> +	removed = kcalloc(CCISS_MAX_SCSI_DEVS_PER_HBA, sizeof(*removed),
> +			  GFP_KERNEL);
>  
>  	if (!added || !removed) {
>  		dev_warn(&h->pdev->dev,
> @@ -1191,8 +1191,8 @@ cciss_update_non_disk_devices(ctlr_info_
>  
>  	ld_buff = kzalloc(reportlunsize, GFP_KERNEL);
>  	inq_buff = kmalloc(OBDR_TAPE_INQ_SIZE, GFP_KERNEL);
> -	currentsd = kzalloc(sizeof(*currentsd) *
> -			(CCISS_MAX_SCSI_DEVS_PER_HBA+1), GFP_KERNEL);
> +	currentsd = kcalloc(CCISS_MAX_SCSI_DEVS_PER_HBA + 1,
> +			    sizeof(*currentsd), GFP_KERNEL);
>  	if (ld_buff == NULL || inq_buff == NULL || currentsd == NULL) {
>  		printk(KERN_ERR "cciss: out of memory\n");
>  		goto out;
> diff -u -p a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
> --- a/drivers/block/xen-blkfront.c 2011-11-13 11:07:22.680095573 +0100
> +++ b/drivers/block/xen-blkfront.c 2011-11-28 19:49:29.109460410 +0100
> @@ -156,7 +156,7 @@ static int xlbd_reserve_minors(unsigned
>  	if (end > nr_minors) {
>  		unsigned long *bitmap, *old;
>  
> -		bitmap = kzalloc(BITS_TO_LONGS(end) * sizeof(*bitmap),
> +		bitmap = kcalloc(BITS_TO_LONGS(end), sizeof(*bitmap),
>  				 GFP_KERNEL);
>  		if (bitmap == NULL)
>  			return -ENOMEM;
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 19:05:21 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 19:05:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rau8Z-0005xf-Na; Wed, 14 Dec 2011 19:05:07 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Rau8X-0005xa-Uy
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 19:05:06 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1323889448!5560063!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDM5MDM1\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32669 invoked from network); 14 Dec 2011 19:04:09 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-8.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Dec 2011 19:04:09 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pBEJ41Nt001032
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 14 Dec 2011 19:04:04 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pBEJ40u7016654
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 14 Dec 2011 19:04:00 GMT
Received: from abhmt101.oracle.com (abhmt101.oracle.com [141.146.116.53])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pBEJ3xi3016001; Wed, 14 Dec 2011 13:03:59 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 14 Dec 2011 11:03:59 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 5262E41C13; Wed, 14 Dec 2011 14:03:08 -0500 (EST)
Date: Wed, 14 Dec 2011 14:03:08 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Message-ID: <20111214190308.GE24598@phenom.dumpdata.com>
References: <20111128152031.GB9655@andromeda.dapyr.net>
	<1322498951-4392-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1322498951-4392-2-git-send-email-dgdegra@tycho.nsa.gov>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1322498951-4392-2-git-send-email-dgdegra@tycho.nsa.gov>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090207.4EE8F325.0028,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com, david.vrabel@citrix.com, JBeulich@suse.com,
	Ian.Campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH 01/12] xenbus: Support HVM backends
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Nov 28, 2011 at 11:49:00AM -0500, Daniel De Graaf wrote:
> Add HVM implementations of xenbus_(map,unmap)_ring_v(alloc,free) so
> that ring mappings can be done without using GNTMAP_contains_pte which
> is not supported on HVM.


So what else besides these patches should I do to load the blkback/netback
drivers in a HVM domain? There are some xen toolstack patches patches I presume?
Can you tell me what the c/s are (if any?)

Thanks!
> 
> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
> ---
>  drivers/xen/xenbus/xenbus_client.c |  155 +++++++++++++++++++++++++++++-------
>  1 files changed, 125 insertions(+), 30 deletions(-)
> 
> diff --git a/drivers/xen/xenbus/xenbus_client.c b/drivers/xen/xenbus/xenbus_client.c
> index 1906125..688c4b4 100644
> --- a/drivers/xen/xenbus/xenbus_client.c
> +++ b/drivers/xen/xenbus/xenbus_client.c
> @@ -32,16 +32,27 @@
>  
>  #include <linux/slab.h>
>  #include <linux/types.h>
> +#include <linux/spinlock.h>
>  #include <linux/vmalloc.h>
>  #include <linux/export.h>
>  #include <asm/xen/hypervisor.h>
>  #include <asm/xen/page.h>
>  #include <xen/interface/xen.h>
>  #include <xen/interface/event_channel.h>
> +#include <xen/balloon.h>
>  #include <xen/events.h>
>  #include <xen/grant_table.h>
>  #include <xen/xenbus.h>
>  
> +struct xenbus_map_node {
> +	struct list_head next;
> +	struct page *page;
> +	grant_handle_t handle;
> +};
> +
> +static DEFINE_SPINLOCK(xenbus_valloc_lock);
> +static LIST_HEAD(xenbus_valloc_pages);
> +
>  const char *xenbus_strstate(enum xenbus_state state)
>  {
>  	static const char *const name[] = {
> @@ -420,21 +431,8 @@ int xenbus_free_evtchn(struct xenbus_device *dev, int port)
>  EXPORT_SYMBOL_GPL(xenbus_free_evtchn);
>  
>  
> -/**
> - * xenbus_map_ring_valloc
> - * @dev: xenbus device
> - * @gnt_ref: grant reference
> - * @vaddr: pointer to address to be filled out by mapping
> - *
> - * Based on Rusty Russell's skeleton driver's map_page.
> - * Map a page of memory into this domain from another domain's grant table.
> - * xenbus_map_ring_valloc allocates a page of virtual address space, maps the
> - * page to that address, and sets *vaddr to that address.
> - * Returns 0 on success, and GNTST_* (see xen/include/interface/grant_table.h)
> - * or -ENOMEM on error. If an error is returned, device will switch to
> - * XenbusStateClosing and the error message will be saved in XenStore.
> - */
> -int xenbus_map_ring_valloc(struct xenbus_device *dev, int gnt_ref, void **vaddr)
> +static int xenbus_map_ring_valloc_pv(struct xenbus_device *dev,
> +                                     int gnt_ref, void **vaddr)
>  {
>  	struct gnttab_map_grant_ref op = {
>  		.flags = GNTMAP_host_map | GNTMAP_contains_pte,
> @@ -469,6 +467,64 @@ int xenbus_map_ring_valloc(struct xenbus_device *dev, int gnt_ref, void **vaddr)
>  	*vaddr = area->addr;
>  	return 0;
>  }
> +
> +static int xenbus_map_ring_valloc_hvm(struct xenbus_device *dev,
> +                                     int gnt_ref, void **vaddr)
> +{
> +	struct xenbus_map_node *node;
> +	int err;
> +	void *addr;
> +
> +	*vaddr = NULL;
> +
> +	node = kzalloc(sizeof(*node), GFP_KERNEL);
> +	if (!node)
> +		return -ENOMEM;
> +
> +	err = alloc_xenballooned_pages(1, &node->page, false);
> +	if (err)
> +		goto out_err;
> +
> +	addr = pfn_to_kaddr(page_to_pfn(node->page));
> +
> +	err = xenbus_map_ring(dev, gnt_ref, &node->handle, addr);
> +	if (err)
> +		goto out_err;
> +
> +	spin_lock(&xenbus_valloc_lock);
> +	list_add(&node->next, &xenbus_valloc_pages);
> +	spin_unlock(&xenbus_valloc_lock);
> +
> +	*vaddr = addr;
> +	return 0;
> +
> + out_err:
> +	free_xenballooned_pages(1, &node->page);
> +	kfree(node);
> +	return err;
> +}
> +
> +/**
> + * xenbus_map_ring_valloc
> + * @dev: xenbus device
> + * @gnt_ref: grant reference
> + * @vaddr: pointer to address to be filled out by mapping
> + *
> + * Based on Rusty Russell's skeleton driver's map_page.
> + * Map a page of memory into this domain from another domain's grant table.
> + * xenbus_map_ring_valloc allocates a page of virtual address space, maps the
> + * page to that address, and sets *vaddr to that address.
> + * Returns 0 on success, and GNTST_* (see xen/include/interface/grant_table.h)
> + * or -ENOMEM on error. If an error is returned, device will switch to
> + * XenbusStateClosing and the error message will be saved in XenStore.
> + */
> +int xenbus_map_ring_valloc(struct xenbus_device *dev, int gnt_ref, void **vaddr)
> +{
> +	if (xen_pv_domain())
> +		return xenbus_map_ring_valloc_pv(dev, gnt_ref, vaddr);
> +	else
> +		return xenbus_map_ring_valloc_hvm(dev, gnt_ref, vaddr);
> +}
>  EXPORT_SYMBOL_GPL(xenbus_map_ring_valloc);
>  
>  
> @@ -510,20 +566,7 @@ int xenbus_map_ring(struct xenbus_device *dev, int gnt_ref,
>  }
>  EXPORT_SYMBOL_GPL(xenbus_map_ring);
>  
> -
> -/**
> - * xenbus_unmap_ring_vfree
> - * @dev: xenbus device
> - * @vaddr: addr to unmap
> - *
> - * Based on Rusty Russell's skeleton driver's unmap_page.
> - * Unmap a page of memory in this domain that was imported from another domain.
> - * Use xenbus_unmap_ring_vfree if you mapped in your memory with
> - * xenbus_map_ring_valloc (it will free the virtual address space).
> - * Returns 0 on success and returns GNTST_* on error
> - * (see xen/include/interface/grant_table.h).
> - */
> -int xenbus_unmap_ring_vfree(struct xenbus_device *dev, void *vaddr)
> +static int xenbus_unmap_ring_vfree_pv(struct xenbus_device *dev, void *vaddr)
>  {
>  	struct vm_struct *area;
>  	struct gnttab_unmap_grant_ref op = {
> @@ -566,8 +609,60 @@ int xenbus_unmap_ring_vfree(struct xenbus_device *dev, void *vaddr)
>  
>  	return op.status;
>  }
> -EXPORT_SYMBOL_GPL(xenbus_unmap_ring_vfree);
>  
> +static int xenbus_unmap_ring_vfree_hvm(struct xenbus_device *dev, void *vaddr)
> +{
> +	int rv;
> +	struct xenbus_map_node *node;
> +	void *addr;
> +
> +	spin_lock(&xenbus_valloc_lock);
> +	list_for_each_entry(node, &xenbus_valloc_pages, next) {
> +		addr = pfn_to_kaddr(page_to_pfn(node->page));
> +		if (addr == vaddr) {
> +			list_del(&node->next);
> +			goto found;
> +		}
> +	}
> +	node = NULL;
> + found:
> +	spin_unlock(&xenbus_valloc_lock);
> +
> +	if (!node) {
> +		xenbus_dev_error(dev, -ENOENT,
> +				 "can't find mapped virtual address %p", vaddr);
> +		return -ENOENT;
> +	}
> +
> +	rv = xenbus_unmap_ring(dev, node->handle, addr);
> +
> +	if (!rv)
> +		free_xenballooned_pages(1, &node->page);
> +
> +	kfree(node);
> +	return rv;
> +}
> +
> +/**
> + * xenbus_unmap_ring_vfree
> + * @dev: xenbus device
> + * @vaddr: addr to unmap
> + *
> + * Based on Rusty Russell's skeleton driver's unmap_page.
> + * Unmap a page of memory in this domain that was imported from another domain.
> + * Use xenbus_unmap_ring_vfree if you mapped in your memory with
> + * xenbus_map_ring_valloc (it will free the virtual address space).
> + * Returns 0 on success and returns GNTST_* on error
> + * (see xen/include/interface/grant_table.h).
> + */
> +int xenbus_unmap_ring_vfree(struct xenbus_device *dev, void *vaddr)
> +{
> +	if (xen_pv_domain())
> +		return xenbus_unmap_ring_vfree_pv(dev, vaddr);
> +	else
> +		return xenbus_unmap_ring_vfree_hvm(dev, vaddr);
> +}
> +EXPORT_SYMBOL_GPL(xenbus_unmap_ring_vfree);
>  
>  /**
>   * xenbus_unmap_ring
> -- 
> 1.7.7.3

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 19:05:21 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 19:05:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rau8Z-0005xf-Na; Wed, 14 Dec 2011 19:05:07 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Rau8X-0005xa-Uy
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 19:05:06 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1323889448!5560063!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDM5MDM1\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32669 invoked from network); 14 Dec 2011 19:04:09 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-8.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Dec 2011 19:04:09 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pBEJ41Nt001032
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 14 Dec 2011 19:04:04 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pBEJ40u7016654
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 14 Dec 2011 19:04:00 GMT
Received: from abhmt101.oracle.com (abhmt101.oracle.com [141.146.116.53])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pBEJ3xi3016001; Wed, 14 Dec 2011 13:03:59 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 14 Dec 2011 11:03:59 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 5262E41C13; Wed, 14 Dec 2011 14:03:08 -0500 (EST)
Date: Wed, 14 Dec 2011 14:03:08 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Message-ID: <20111214190308.GE24598@phenom.dumpdata.com>
References: <20111128152031.GB9655@andromeda.dapyr.net>
	<1322498951-4392-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1322498951-4392-2-git-send-email-dgdegra@tycho.nsa.gov>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1322498951-4392-2-git-send-email-dgdegra@tycho.nsa.gov>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090207.4EE8F325.0028,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com, david.vrabel@citrix.com, JBeulich@suse.com,
	Ian.Campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH 01/12] xenbus: Support HVM backends
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Nov 28, 2011 at 11:49:00AM -0500, Daniel De Graaf wrote:
> Add HVM implementations of xenbus_(map,unmap)_ring_v(alloc,free) so
> that ring mappings can be done without using GNTMAP_contains_pte which
> is not supported on HVM.


So what else besides these patches should I do to load the blkback/netback
drivers in a HVM domain? There are some xen toolstack patches patches I presume?
Can you tell me what the c/s are (if any?)

Thanks!
> 
> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
> ---
>  drivers/xen/xenbus/xenbus_client.c |  155 +++++++++++++++++++++++++++++-------
>  1 files changed, 125 insertions(+), 30 deletions(-)
> 
> diff --git a/drivers/xen/xenbus/xenbus_client.c b/drivers/xen/xenbus/xenbus_client.c
> index 1906125..688c4b4 100644
> --- a/drivers/xen/xenbus/xenbus_client.c
> +++ b/drivers/xen/xenbus/xenbus_client.c
> @@ -32,16 +32,27 @@
>  
>  #include <linux/slab.h>
>  #include <linux/types.h>
> +#include <linux/spinlock.h>
>  #include <linux/vmalloc.h>
>  #include <linux/export.h>
>  #include <asm/xen/hypervisor.h>
>  #include <asm/xen/page.h>
>  #include <xen/interface/xen.h>
>  #include <xen/interface/event_channel.h>
> +#include <xen/balloon.h>
>  #include <xen/events.h>
>  #include <xen/grant_table.h>
>  #include <xen/xenbus.h>
>  
> +struct xenbus_map_node {
> +	struct list_head next;
> +	struct page *page;
> +	grant_handle_t handle;
> +};
> +
> +static DEFINE_SPINLOCK(xenbus_valloc_lock);
> +static LIST_HEAD(xenbus_valloc_pages);
> +
>  const char *xenbus_strstate(enum xenbus_state state)
>  {
>  	static const char *const name[] = {
> @@ -420,21 +431,8 @@ int xenbus_free_evtchn(struct xenbus_device *dev, int port)
>  EXPORT_SYMBOL_GPL(xenbus_free_evtchn);
>  
>  
> -/**
> - * xenbus_map_ring_valloc
> - * @dev: xenbus device
> - * @gnt_ref: grant reference
> - * @vaddr: pointer to address to be filled out by mapping
> - *
> - * Based on Rusty Russell's skeleton driver's map_page.
> - * Map a page of memory into this domain from another domain's grant table.
> - * xenbus_map_ring_valloc allocates a page of virtual address space, maps the
> - * page to that address, and sets *vaddr to that address.
> - * Returns 0 on success, and GNTST_* (see xen/include/interface/grant_table.h)
> - * or -ENOMEM on error. If an error is returned, device will switch to
> - * XenbusStateClosing and the error message will be saved in XenStore.
> - */
> -int xenbus_map_ring_valloc(struct xenbus_device *dev, int gnt_ref, void **vaddr)
> +static int xenbus_map_ring_valloc_pv(struct xenbus_device *dev,
> +                                     int gnt_ref, void **vaddr)
>  {
>  	struct gnttab_map_grant_ref op = {
>  		.flags = GNTMAP_host_map | GNTMAP_contains_pte,
> @@ -469,6 +467,64 @@ int xenbus_map_ring_valloc(struct xenbus_device *dev, int gnt_ref, void **vaddr)
>  	*vaddr = area->addr;
>  	return 0;
>  }
> +
> +static int xenbus_map_ring_valloc_hvm(struct xenbus_device *dev,
> +                                     int gnt_ref, void **vaddr)
> +{
> +	struct xenbus_map_node *node;
> +	int err;
> +	void *addr;
> +
> +	*vaddr = NULL;
> +
> +	node = kzalloc(sizeof(*node), GFP_KERNEL);
> +	if (!node)
> +		return -ENOMEM;
> +
> +	err = alloc_xenballooned_pages(1, &node->page, false);
> +	if (err)
> +		goto out_err;
> +
> +	addr = pfn_to_kaddr(page_to_pfn(node->page));
> +
> +	err = xenbus_map_ring(dev, gnt_ref, &node->handle, addr);
> +	if (err)
> +		goto out_err;
> +
> +	spin_lock(&xenbus_valloc_lock);
> +	list_add(&node->next, &xenbus_valloc_pages);
> +	spin_unlock(&xenbus_valloc_lock);
> +
> +	*vaddr = addr;
> +	return 0;
> +
> + out_err:
> +	free_xenballooned_pages(1, &node->page);
> +	kfree(node);
> +	return err;
> +}
> +
> +/**
> + * xenbus_map_ring_valloc
> + * @dev: xenbus device
> + * @gnt_ref: grant reference
> + * @vaddr: pointer to address to be filled out by mapping
> + *
> + * Based on Rusty Russell's skeleton driver's map_page.
> + * Map a page of memory into this domain from another domain's grant table.
> + * xenbus_map_ring_valloc allocates a page of virtual address space, maps the
> + * page to that address, and sets *vaddr to that address.
> + * Returns 0 on success, and GNTST_* (see xen/include/interface/grant_table.h)
> + * or -ENOMEM on error. If an error is returned, device will switch to
> + * XenbusStateClosing and the error message will be saved in XenStore.
> + */
> +int xenbus_map_ring_valloc(struct xenbus_device *dev, int gnt_ref, void **vaddr)
> +{
> +	if (xen_pv_domain())
> +		return xenbus_map_ring_valloc_pv(dev, gnt_ref, vaddr);
> +	else
> +		return xenbus_map_ring_valloc_hvm(dev, gnt_ref, vaddr);
> +}
>  EXPORT_SYMBOL_GPL(xenbus_map_ring_valloc);
>  
>  
> @@ -510,20 +566,7 @@ int xenbus_map_ring(struct xenbus_device *dev, int gnt_ref,
>  }
>  EXPORT_SYMBOL_GPL(xenbus_map_ring);
>  
> -
> -/**
> - * xenbus_unmap_ring_vfree
> - * @dev: xenbus device
> - * @vaddr: addr to unmap
> - *
> - * Based on Rusty Russell's skeleton driver's unmap_page.
> - * Unmap a page of memory in this domain that was imported from another domain.
> - * Use xenbus_unmap_ring_vfree if you mapped in your memory with
> - * xenbus_map_ring_valloc (it will free the virtual address space).
> - * Returns 0 on success and returns GNTST_* on error
> - * (see xen/include/interface/grant_table.h).
> - */
> -int xenbus_unmap_ring_vfree(struct xenbus_device *dev, void *vaddr)
> +static int xenbus_unmap_ring_vfree_pv(struct xenbus_device *dev, void *vaddr)
>  {
>  	struct vm_struct *area;
>  	struct gnttab_unmap_grant_ref op = {
> @@ -566,8 +609,60 @@ int xenbus_unmap_ring_vfree(struct xenbus_device *dev, void *vaddr)
>  
>  	return op.status;
>  }
> -EXPORT_SYMBOL_GPL(xenbus_unmap_ring_vfree);
>  
> +static int xenbus_unmap_ring_vfree_hvm(struct xenbus_device *dev, void *vaddr)
> +{
> +	int rv;
> +	struct xenbus_map_node *node;
> +	void *addr;
> +
> +	spin_lock(&xenbus_valloc_lock);
> +	list_for_each_entry(node, &xenbus_valloc_pages, next) {
> +		addr = pfn_to_kaddr(page_to_pfn(node->page));
> +		if (addr == vaddr) {
> +			list_del(&node->next);
> +			goto found;
> +		}
> +	}
> +	node = NULL;
> + found:
> +	spin_unlock(&xenbus_valloc_lock);
> +
> +	if (!node) {
> +		xenbus_dev_error(dev, -ENOENT,
> +				 "can't find mapped virtual address %p", vaddr);
> +		return -ENOENT;
> +	}
> +
> +	rv = xenbus_unmap_ring(dev, node->handle, addr);
> +
> +	if (!rv)
> +		free_xenballooned_pages(1, &node->page);
> +
> +	kfree(node);
> +	return rv;
> +}
> +
> +/**
> + * xenbus_unmap_ring_vfree
> + * @dev: xenbus device
> + * @vaddr: addr to unmap
> + *
> + * Based on Rusty Russell's skeleton driver's unmap_page.
> + * Unmap a page of memory in this domain that was imported from another domain.
> + * Use xenbus_unmap_ring_vfree if you mapped in your memory with
> + * xenbus_map_ring_valloc (it will free the virtual address space).
> + * Returns 0 on success and returns GNTST_* on error
> + * (see xen/include/interface/grant_table.h).
> + */
> +int xenbus_unmap_ring_vfree(struct xenbus_device *dev, void *vaddr)
> +{
> +	if (xen_pv_domain())
> +		return xenbus_unmap_ring_vfree_pv(dev, vaddr);
> +	else
> +		return xenbus_unmap_ring_vfree_hvm(dev, vaddr);
> +}
> +EXPORT_SYMBOL_GPL(xenbus_unmap_ring_vfree);
>  
>  /**
>   * xenbus_unmap_ring
> -- 
> 1.7.7.3

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 19:13:06 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 19:13:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RauG4-0006L7-Rg; Wed, 14 Dec 2011 19:12:52 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1RauG3-0006L2-Oc
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 19:12:51 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-16.tower-216.messagelabs.com!1323889914!7357520!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19092 invoked from network); 14 Dec 2011 19:11:55 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-16.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Dec 2011 19:11:55 -0000
Received: from andromeda.dapyr.net (darnok@localhost [127.0.0.1])
	by andromeda.dapyr.net (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id
	pBEJBnfw021789
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Wed, 14 Dec 2011 14:11:49 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pBEJBmO8021787;
	Wed, 14 Dec 2011 14:11:48 -0500
Date: Wed, 14 Dec 2011 15:11:48 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20111214191148.GA17432@andromeda.dapyr.net>
References: <3E243B26F475504B9BB0BCC9728B0DA629E16E01@USILMS110A.ca.com>
	<20111209203010.GA14412@andromeda.dapyr.net>
	<3E243B26F475504B9BB0BCC9728B0DA629E17AEA@USILMS110A.ca.com>
	<20111213001912.GA2730@konrad-lan>
	<3E243B26F475504B9BB0BCC9728B0DA629E184FA@USILMS110A.ca.com>
	<20111213232759.GA8702@konrad-lan>
	<3E243B26F475504B9BB0BCC9728B0DA629E18564@USILMS110A.ca.com>
	<4EE8785A0200007800067A16@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4EE8785A0200007800067A16@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.9i
Cc: xen-devel <xen-devel@lists.xensource.com>,
	Leonid Kalev <Leonid.Kalev@ca.com>, Tushar N Dave <tushar.n.dave@intel.com>
Subject: Re: [Xen-devel] Buffers not reachable by PCI
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Dec 14, 2011 at 09:20:10AM +0000, Jan Beulich wrote:
> >>> On 14.12.11 at 01:38, "Taylor, Neal E" <Neal.Taylor@ca.com> wrote:
> > [    0.000000] MFN 0x7f7f->0x7f00
> 
> This is clearly indicating the last chunk ends well below the 4G boundary.
> 
> > [    0.000000] Placing 64MB software IO TLB between d832cf00 - dc32cf00
> > [    0.000000] software IO TLB at phys 0x1832cf00 - 0x1c32cf00
> > [    0.000000] software IO TLB at bus 0x1c0f00 - 0x120fdff00
> 
> Consequently, the question is how you got to this value, or what
> changed between the first and last quoted printouts.

<nods>

Neal, I would also strongly recommend you try v3.0.6 - as there are a
couple of important fixes in it:

310fef9 xen/e820: if there is no dom0_mem=, don't tweak extra_pages.
0208b80 xen: use maximum reservation to limit amount of usable RAM
d63c8a0 mm: sync vmalloc address space page tables in alloc_vm_area()
0b129e1 xen/smp: Warn user why they keel over - nosmp or noapic and what
to use instead.
1f51b5d xen: x86_32: do not enable iterrupts when returning from
exception in interrupt context

Especially the dom0_mem - which I think you are using but the values are not
latching on. This is seperate from the issue you are hitting but I do
wonder if they might have an impact.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 19:13:06 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 19:13:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RauG4-0006L7-Rg; Wed, 14 Dec 2011 19:12:52 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1RauG3-0006L2-Oc
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 19:12:51 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-16.tower-216.messagelabs.com!1323889914!7357520!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19092 invoked from network); 14 Dec 2011 19:11:55 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-16.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Dec 2011 19:11:55 -0000
Received: from andromeda.dapyr.net (darnok@localhost [127.0.0.1])
	by andromeda.dapyr.net (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id
	pBEJBnfw021789
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Wed, 14 Dec 2011 14:11:49 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pBEJBmO8021787;
	Wed, 14 Dec 2011 14:11:48 -0500
Date: Wed, 14 Dec 2011 15:11:48 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20111214191148.GA17432@andromeda.dapyr.net>
References: <3E243B26F475504B9BB0BCC9728B0DA629E16E01@USILMS110A.ca.com>
	<20111209203010.GA14412@andromeda.dapyr.net>
	<3E243B26F475504B9BB0BCC9728B0DA629E17AEA@USILMS110A.ca.com>
	<20111213001912.GA2730@konrad-lan>
	<3E243B26F475504B9BB0BCC9728B0DA629E184FA@USILMS110A.ca.com>
	<20111213232759.GA8702@konrad-lan>
	<3E243B26F475504B9BB0BCC9728B0DA629E18564@USILMS110A.ca.com>
	<4EE8785A0200007800067A16@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4EE8785A0200007800067A16@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.9i
Cc: xen-devel <xen-devel@lists.xensource.com>,
	Leonid Kalev <Leonid.Kalev@ca.com>, Tushar N Dave <tushar.n.dave@intel.com>
Subject: Re: [Xen-devel] Buffers not reachable by PCI
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Dec 14, 2011 at 09:20:10AM +0000, Jan Beulich wrote:
> >>> On 14.12.11 at 01:38, "Taylor, Neal E" <Neal.Taylor@ca.com> wrote:
> > [    0.000000] MFN 0x7f7f->0x7f00
> 
> This is clearly indicating the last chunk ends well below the 4G boundary.
> 
> > [    0.000000] Placing 64MB software IO TLB between d832cf00 - dc32cf00
> > [    0.000000] software IO TLB at phys 0x1832cf00 - 0x1c32cf00
> > [    0.000000] software IO TLB at bus 0x1c0f00 - 0x120fdff00
> 
> Consequently, the question is how you got to this value, or what
> changed between the first and last quoted printouts.

<nods>

Neal, I would also strongly recommend you try v3.0.6 - as there are a
couple of important fixes in it:

310fef9 xen/e820: if there is no dom0_mem=, don't tweak extra_pages.
0208b80 xen: use maximum reservation to limit amount of usable RAM
d63c8a0 mm: sync vmalloc address space page tables in alloc_vm_area()
0b129e1 xen/smp: Warn user why they keel over - nosmp or noapic and what
to use instead.
1f51b5d xen: x86_32: do not enable iterrupts when returning from
exception in interrupt context

Especially the dom0_mem - which I think you are using but the values are not
latching on. This is seperate from the issue you are hitting but I do
wonder if they might have an impact.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 19:24:50 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 19:24:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RauRP-0006WN-C3; Wed, 14 Dec 2011 19:24:35 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RauRN-0006WI-IV
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 19:24:33 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1323890615!7382358!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDM5MDM1\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5539 invoked from network); 14 Dec 2011 19:23:37 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-10.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Dec 2011 19:23:37 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pBEJNXQK026399
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 14 Dec 2011 19:23:35 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pBEJNWbF018997
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 14 Dec 2011 19:23:32 GMT
Received: from abhmt115.oracle.com (abhmt115.oracle.com [141.146.116.67])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pBEJNSgD020781; Wed, 14 Dec 2011 13:23:32 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 14 Dec 2011 11:23:28 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id EF83941C13; Wed, 14 Dec 2011 14:22:37 -0500 (EST)
Date: Wed, 14 Dec 2011 14:22:37 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Bastian Blank <bastian@waldi.eu.org>, xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org
Message-ID: <20111214192237.GA1156@phenom.dumpdata.com>
References: <1323541791-18006-1-git-send-email-waldi@debian.org>
	<1323541791-18006-7-git-send-email-waldi@debian.org>
	<20111212154227.GB21558@phenom.dumpdata.com>
	<20111212182807.GB14966@wavehammer.waldi.eu.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20111212182807.GB14966@wavehammer.waldi.eu.org>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090209.4EE8F7B7.00B5,ss=1,re=0.000,fgs=0
Subject: Re: [Xen-devel] [PATCH 6/6] xen/xenbus-backend: Only register
 device if communication ring is local
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Dec 12, 2011 at 07:28:07PM +0100, Bastian Blank wrote:
> On Mon, Dec 12, 2011 at 10:42:27AM -0500, Konrad Rzeszutek Wilk wrote:
> > On Sat, Dec 10, 2011 at 07:29:51PM +0100, Bastian Blank wrote:
> > > -module_init(xenbus_backend_init);
> > > -module_exit(xenbus_backend_exit);
> > 
> > Why are we removing the module functionality?
> > Can't this [the purpose of this patch] be done while still maintaining the module functionality?
> 
> Not really. The purpose is to register the device only if the ring is
> local. This information is not available to modules.
> 
> However we could just move the whole xenbus ring setup into a "module".
> Or is there any reason for this to be in a postcore_initcall, even if it
> is only operational after a userspace process works?

My thinking is that we do not want to use memory space if the kernel
is booted as baremetal (as there is no point of having Xen pieces around).
Modules work great for that.

But then part of this code is __init so some does get evicted, but not sure
how much. Could you measure this on baremetal please?

> 
> > >  int xenstored_ready;
> > >  
> > > +/* A flag to determine if xenstored is 'local' */
> > > +#ifdef CONFIG_XEN_BACKEND
> > > +static int xenstored_local;
> > 
> > bool?
> 
> Well. The other flags are int also.

Sure.. and they ought to be modified to bool too now that I think of it.

> 
> > > +			BUG();
> > No way. A WARN, sure - but BUG() is way too intense for this.
> 
> Okay.
> 
> Bastian
> 
> -- 
> The sight of death frightens them [Earthers].
> 		-- Kras the Klingon, "Friday's Child", stardate 3497.2

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 19:24:50 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 19:24:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RauRP-0006WN-C3; Wed, 14 Dec 2011 19:24:35 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RauRN-0006WI-IV
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 19:24:33 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1323890615!7382358!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDM5MDM1\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5539 invoked from network); 14 Dec 2011 19:23:37 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-10.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Dec 2011 19:23:37 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pBEJNXQK026399
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 14 Dec 2011 19:23:35 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pBEJNWbF018997
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 14 Dec 2011 19:23:32 GMT
Received: from abhmt115.oracle.com (abhmt115.oracle.com [141.146.116.67])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pBEJNSgD020781; Wed, 14 Dec 2011 13:23:32 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 14 Dec 2011 11:23:28 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id EF83941C13; Wed, 14 Dec 2011 14:22:37 -0500 (EST)
Date: Wed, 14 Dec 2011 14:22:37 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Bastian Blank <bastian@waldi.eu.org>, xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org
Message-ID: <20111214192237.GA1156@phenom.dumpdata.com>
References: <1323541791-18006-1-git-send-email-waldi@debian.org>
	<1323541791-18006-7-git-send-email-waldi@debian.org>
	<20111212154227.GB21558@phenom.dumpdata.com>
	<20111212182807.GB14966@wavehammer.waldi.eu.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20111212182807.GB14966@wavehammer.waldi.eu.org>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090209.4EE8F7B7.00B5,ss=1,re=0.000,fgs=0
Subject: Re: [Xen-devel] [PATCH 6/6] xen/xenbus-backend: Only register
 device if communication ring is local
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Dec 12, 2011 at 07:28:07PM +0100, Bastian Blank wrote:
> On Mon, Dec 12, 2011 at 10:42:27AM -0500, Konrad Rzeszutek Wilk wrote:
> > On Sat, Dec 10, 2011 at 07:29:51PM +0100, Bastian Blank wrote:
> > > -module_init(xenbus_backend_init);
> > > -module_exit(xenbus_backend_exit);
> > 
> > Why are we removing the module functionality?
> > Can't this [the purpose of this patch] be done while still maintaining the module functionality?
> 
> Not really. The purpose is to register the device only if the ring is
> local. This information is not available to modules.
> 
> However we could just move the whole xenbus ring setup into a "module".
> Or is there any reason for this to be in a postcore_initcall, even if it
> is only operational after a userspace process works?

My thinking is that we do not want to use memory space if the kernel
is booted as baremetal (as there is no point of having Xen pieces around).
Modules work great for that.

But then part of this code is __init so some does get evicted, but not sure
how much. Could you measure this on baremetal please?

> 
> > >  int xenstored_ready;
> > >  
> > > +/* A flag to determine if xenstored is 'local' */
> > > +#ifdef CONFIG_XEN_BACKEND
> > > +static int xenstored_local;
> > 
> > bool?
> 
> Well. The other flags are int also.

Sure.. and they ought to be modified to bool too now that I think of it.

> 
> > > +			BUG();
> > No way. A WARN, sure - but BUG() is way too intense for this.
> 
> Okay.
> 
> Bastian
> 
> -- 
> The sight of death frightens them [Earthers].
> 		-- Kras the Klingon, "Friday's Child", stardate 3497.2

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 19:41:53 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 19:41:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rauhm-0007a1-EP; Wed, 14 Dec 2011 19:41:30 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1Rauhk-0007Zk-Nb
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 19:41:28 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-7.tower-182.messagelabs.com!1323891630!7229151!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8355 invoked from network); 14 Dec 2011 19:40:32 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-7.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Dec 2011 19:40:32 -0000
Received: from andromeda.dapyr.net (darnok@localhost [127.0.0.1])
	by andromeda.dapyr.net (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id
	pBEJeTP7023211
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Wed, 14 Dec 2011 14:40:29 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pBEJeTYl023209;
	Wed, 14 Dec 2011 14:40:29 -0500
Date: Wed, 14 Dec 2011 15:40:29 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Quartexx <quartex73@gmail.com>
Message-ID: <20111214194029.GB17432@andromeda.dapyr.net>
References: <CAMhBqqiLc1994GUKtA7UY52pR29nktmFy+XiwTwpZb_E+fwFRQ@mail.gmail.com>
	<CAMhBqqgu6v8NB-X0dNdfrzd12=Y2i==fYCCC2Z+MkDupqqKAOg@mail.gmail.com>
	<20111202195727.GA18758@andromeda.dapyr.net>
	<CAMhBqqgJ0Q3BZDuK3KEEGuDS2eGBZq89E7_Kbv+VNTYxZJLAAA@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAMhBqqgJ0Q3BZDuK3KEEGuDS2eGBZq89E7_Kbv+VNTYxZJLAAA@mail.gmail.com>
User-Agent: Mutt/1.5.9i
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] xen 4.0.1 w/2.6.32.47 hangs at boot
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Dec 14, 2011 at 07:31:38PM +0100, Quartexx wrote:
> 2011/12/2 Konrad Rzeszutek Wilk <konrad@darnok.org>:
> > On Fri, Dec 02, 2011 at 08:22:46PM +0100, Quartexx wrote:
> >> ### lspci
> >
> > <sigh> You seem to be missing the most important - that is the serial
> > console output with 'sync_console' enabled.
> 
> [   15.202110] 3ware 9000 Storage Controller device driver for Linux
> v2.26.02.012.
> [   15.226331] xen_allocate_pirq: returning irq 16 for gsi 16
> [   15.244631] Already setup the GSI :16
> [   15.256909] 3w-9xxx 0000:01:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
> [   15.535246] 3w-9xxx: scsi0: AEN: INFO (0x04:0x0053): Battery
> capacity test is overdue:.
> [   15.662242] scsi0 : 3ware 9000 Storage Controller
> [   15.677727] 3w-9xxx: scsi0: Found a 3ware 9000 Storage Controller
> at 0xb3a00000, IRQ: 16.
> [   16.010243] 3w-9xxx: scsi0: Firmware FH9X 4.10.00.021, BIOS BE9X
> 4.08.00.003, Ports: 128.
> [   16.037272] scsi 0:0:0:0: Direct-Access     AMCC     9690SA-4I
> DISK  4.10 PQ: 0 ANSI: 5
> [   16.073169] sd 0:0:0:0: [sda] 2929666048 512-byte logical blocks:
> (1.49 TB/1.36 TiB)

.. snip..
> [   16.077572] sd 0:0:0:0: Attached scsi generic sg0 type 0
> [   16.077953] Intel(R) PRO/1000 Network Driver - version 7.3.21-k5-NAPI
> [   16.077955] Copyright (c) 1999-2006 Intel Corporation.
> [   16.078011] e1000e: Intel(R) PRO/1000 Network Driver - 1.0.2-k2
> [   16.078012] e1000e: Copyright (c) 1999-2008 Intel Corporation.
> [   16.078055] xen_allocate_pirq: returning irq 16 for gsi 16
> [   16.078058] Already setup the GSI :16
> [   16.078061] e1000e 0000:00:19.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
> [   16.248299] sd 0:0:0:0: [sda] Write Protect is off
> [   16.264315] sd 0:0:0:0: [sda] Write cache: enabled, read cache:
> enabled, supports DPO and FUA
> [   16.293627]  sda: sda1 sda2 < sda5 sda6 sda7 sda8 sda9 >
> [   16.362257] sd 0:0:0:0: [sda] Attached SCSI disk

I would hazzard a guess that it is something with the 3ware driver.
Can you configure Alt-SysRq so that you can see the stack trace of
dom0 and where it hanged? And also do Ctrl-Ax3 and press 'q' to see
where dom0 is stuck? It should print out a bunch of 0xff.. and I can
help you debug what that is in the dom0 kernel so we can figure out
what is happening.

Or you can also try the latest kernel - 3.0.x and see if the problem
appears there as well - which is much easier for us to fix and has
some other important fixes that won't be back-ported to 2.6.32.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 19:41:53 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 19:41:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rauhm-0007a1-EP; Wed, 14 Dec 2011 19:41:30 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1Rauhk-0007Zk-Nb
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 19:41:28 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-7.tower-182.messagelabs.com!1323891630!7229151!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8355 invoked from network); 14 Dec 2011 19:40:32 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-7.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Dec 2011 19:40:32 -0000
Received: from andromeda.dapyr.net (darnok@localhost [127.0.0.1])
	by andromeda.dapyr.net (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id
	pBEJeTP7023211
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Wed, 14 Dec 2011 14:40:29 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pBEJeTYl023209;
	Wed, 14 Dec 2011 14:40:29 -0500
Date: Wed, 14 Dec 2011 15:40:29 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Quartexx <quartex73@gmail.com>
Message-ID: <20111214194029.GB17432@andromeda.dapyr.net>
References: <CAMhBqqiLc1994GUKtA7UY52pR29nktmFy+XiwTwpZb_E+fwFRQ@mail.gmail.com>
	<CAMhBqqgu6v8NB-X0dNdfrzd12=Y2i==fYCCC2Z+MkDupqqKAOg@mail.gmail.com>
	<20111202195727.GA18758@andromeda.dapyr.net>
	<CAMhBqqgJ0Q3BZDuK3KEEGuDS2eGBZq89E7_Kbv+VNTYxZJLAAA@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAMhBqqgJ0Q3BZDuK3KEEGuDS2eGBZq89E7_Kbv+VNTYxZJLAAA@mail.gmail.com>
User-Agent: Mutt/1.5.9i
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] xen 4.0.1 w/2.6.32.47 hangs at boot
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Dec 14, 2011 at 07:31:38PM +0100, Quartexx wrote:
> 2011/12/2 Konrad Rzeszutek Wilk <konrad@darnok.org>:
> > On Fri, Dec 02, 2011 at 08:22:46PM +0100, Quartexx wrote:
> >> ### lspci
> >
> > <sigh> You seem to be missing the most important - that is the serial
> > console output with 'sync_console' enabled.
> 
> [   15.202110] 3ware 9000 Storage Controller device driver for Linux
> v2.26.02.012.
> [   15.226331] xen_allocate_pirq: returning irq 16 for gsi 16
> [   15.244631] Already setup the GSI :16
> [   15.256909] 3w-9xxx 0000:01:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
> [   15.535246] 3w-9xxx: scsi0: AEN: INFO (0x04:0x0053): Battery
> capacity test is overdue:.
> [   15.662242] scsi0 : 3ware 9000 Storage Controller
> [   15.677727] 3w-9xxx: scsi0: Found a 3ware 9000 Storage Controller
> at 0xb3a00000, IRQ: 16.
> [   16.010243] 3w-9xxx: scsi0: Firmware FH9X 4.10.00.021, BIOS BE9X
> 4.08.00.003, Ports: 128.
> [   16.037272] scsi 0:0:0:0: Direct-Access     AMCC     9690SA-4I
> DISK  4.10 PQ: 0 ANSI: 5
> [   16.073169] sd 0:0:0:0: [sda] 2929666048 512-byte logical blocks:
> (1.49 TB/1.36 TiB)

.. snip..
> [   16.077572] sd 0:0:0:0: Attached scsi generic sg0 type 0
> [   16.077953] Intel(R) PRO/1000 Network Driver - version 7.3.21-k5-NAPI
> [   16.077955] Copyright (c) 1999-2006 Intel Corporation.
> [   16.078011] e1000e: Intel(R) PRO/1000 Network Driver - 1.0.2-k2
> [   16.078012] e1000e: Copyright (c) 1999-2008 Intel Corporation.
> [   16.078055] xen_allocate_pirq: returning irq 16 for gsi 16
> [   16.078058] Already setup the GSI :16
> [   16.078061] e1000e 0000:00:19.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
> [   16.248299] sd 0:0:0:0: [sda] Write Protect is off
> [   16.264315] sd 0:0:0:0: [sda] Write cache: enabled, read cache:
> enabled, supports DPO and FUA
> [   16.293627]  sda: sda1 sda2 < sda5 sda6 sda7 sda8 sda9 >
> [   16.362257] sd 0:0:0:0: [sda] Attached SCSI disk

I would hazzard a guess that it is something with the 3ware driver.
Can you configure Alt-SysRq so that you can see the stack trace of
dom0 and where it hanged? And also do Ctrl-Ax3 and press 'q' to see
where dom0 is stuck? It should print out a bunch of 0xff.. and I can
help you debug what that is in the dom0 kernel so we can figure out
what is happening.

Or you can also try the latest kernel - 3.0.x and see if the problem
appears there as well - which is much easier for us to fix and has
some other important fixes that won't be back-ported to 2.6.32.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 19:52:59 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 19:52:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RausY-00086b-8K; Wed, 14 Dec 2011 19:52:38 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RausX-00086M-5T
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 19:52:37 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-6.tower-174.messagelabs.com!1323892300!5586095!1
X-Originating-IP: [63.239.65.40]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27576 invoked from network); 14 Dec 2011 19:51:41 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-6.tower-174.messagelabs.com with SMTP;
	14 Dec 2011 19:51:41 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea02.nsa.gov (8.12.10/8.12.10) with ESMTP id
	pBEJpc2Y016634; Wed, 14 Dec 2011 19:51:38 GMT
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id pBEJpc3j009284; 
	Wed, 14 Dec 2011 14:51:38 -0500
Message-ID: <4EE8FE60.30602@tycho.nsa.gov>
Date: Wed, 14 Dec 2011 14:52:00 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:7.0.1) Gecko/20110930 Thunderbird/7.0.1
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <20111128152031.GB9655@andromeda.dapyr.net>
	<1322498951-4392-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1322498951-4392-8-git-send-email-dgdegra@tycho.nsa.gov>
	<20111214185618.GC24598@phenom.dumpdata.com>
In-Reply-To: <20111214185618.GC24598@phenom.dumpdata.com>
X-Enigmail-Version: 1.3.2
Cc: xen-devel@lists.xensource.com, david.vrabel@citrix.com, JBeulich@suse.com,
	Ian.Campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH 07/12] xen/event: Add reference counting to
	event channels
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 12/14/2011 01:56 PM, Konrad Rzeszutek Wilk wrote:
> On Mon, Nov 28, 2011 at 11:49:06AM -0500, Daniel De Graaf wrote:
>> Event channels exposed to userspace by the evtchn module may be used by
>> other modules in an asynchronous manner, which requires that reference
>> counting be used to prevent the event channel from being closed before
>> the signals are delivered.
>>
>> The reference count on new event channels defaults to -1 which indicates
>> the event channel is not referenced outside the kernel; evtchn_get fails
>> if called on such an event channel. The event channels made visible to
>> userspace by evtchn have a normal reference count.
> 
> So I've 7 through 12 in my branch now. (7,8 and 9 are in the #linux-next
> and the 10-12 are in the #testing).
> 
> The other 1-6 you have might need to be parceled out (especially the netback
> one which usually goes through David Miller). Also I have to double-check -
> but did somebody review those 1-6 patches?
> 

The last review I've seen of these patches is this thread:

http://lists.xen.org/archives/html/xen-devel/2011-10/threads.html#01484

I'll post a v3 for those in a bit incorporating the comments in that
thread; the netback one was (unofficially?) acked by David Miller. I don't
see which of the other patches need to be parceled out as the files they
touch look like they are still being committed with only Xen developer
sign-offs.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 19:52:59 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 19:52:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RausY-00086b-8K; Wed, 14 Dec 2011 19:52:38 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RausX-00086M-5T
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 19:52:37 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-6.tower-174.messagelabs.com!1323892300!5586095!1
X-Originating-IP: [63.239.65.40]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27576 invoked from network); 14 Dec 2011 19:51:41 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-6.tower-174.messagelabs.com with SMTP;
	14 Dec 2011 19:51:41 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea02.nsa.gov (8.12.10/8.12.10) with ESMTP id
	pBEJpc2Y016634; Wed, 14 Dec 2011 19:51:38 GMT
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id pBEJpc3j009284; 
	Wed, 14 Dec 2011 14:51:38 -0500
Message-ID: <4EE8FE60.30602@tycho.nsa.gov>
Date: Wed, 14 Dec 2011 14:52:00 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:7.0.1) Gecko/20110930 Thunderbird/7.0.1
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <20111128152031.GB9655@andromeda.dapyr.net>
	<1322498951-4392-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1322498951-4392-8-git-send-email-dgdegra@tycho.nsa.gov>
	<20111214185618.GC24598@phenom.dumpdata.com>
In-Reply-To: <20111214185618.GC24598@phenom.dumpdata.com>
X-Enigmail-Version: 1.3.2
Cc: xen-devel@lists.xensource.com, david.vrabel@citrix.com, JBeulich@suse.com,
	Ian.Campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH 07/12] xen/event: Add reference counting to
	event channels
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 12/14/2011 01:56 PM, Konrad Rzeszutek Wilk wrote:
> On Mon, Nov 28, 2011 at 11:49:06AM -0500, Daniel De Graaf wrote:
>> Event channels exposed to userspace by the evtchn module may be used by
>> other modules in an asynchronous manner, which requires that reference
>> counting be used to prevent the event channel from being closed before
>> the signals are delivered.
>>
>> The reference count on new event channels defaults to -1 which indicates
>> the event channel is not referenced outside the kernel; evtchn_get fails
>> if called on such an event channel. The event channels made visible to
>> userspace by evtchn have a normal reference count.
> 
> So I've 7 through 12 in my branch now. (7,8 and 9 are in the #linux-next
> and the 10-12 are in the #testing).
> 
> The other 1-6 you have might need to be parceled out (especially the netback
> one which usually goes through David Miller). Also I have to double-check -
> but did somebody review those 1-6 patches?
> 

The last review I've seen of these patches is this thread:

http://lists.xen.org/archives/html/xen-devel/2011-10/threads.html#01484

I'll post a v3 for those in a bit incorporating the comments in that
thread; the netback one was (unofficially?) acked by David Miller. I don't
see which of the other patches need to be parceled out as the files they
touch look like they are still being committed with only Xen developer
sign-offs.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 19:54:27 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 19:54:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rauu2-0008B7-OX; Wed, 14 Dec 2011 19:54:10 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1Rauu1-0008Am-CP
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 19:54:09 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-11.tower-216.messagelabs.com!1323892393!7423187!1
X-Originating-IP: [63.239.65.40]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27099 invoked from network); 14 Dec 2011 19:53:13 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-11.tower-216.messagelabs.com with SMTP;
	14 Dec 2011 19:53:13 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea02.nsa.gov (8.12.10/8.12.10) with ESMTP id
	pBEJrC2Y017058; Wed, 14 Dec 2011 19:53:12 GMT
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id pBEJrCZN009378; 
	Wed, 14 Dec 2011 14:53:12 -0500
Message-ID: <4EE8FEBF.4010001@tycho.nsa.gov>
Date: Wed, 14 Dec 2011 14:53:35 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:7.0.1) Gecko/20110930 Thunderbird/7.0.1
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <20111128152031.GB9655@andromeda.dapyr.net>
	<1322498951-4392-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1322498951-4392-2-git-send-email-dgdegra@tycho.nsa.gov>
	<20111214190308.GE24598@phenom.dumpdata.com>
In-Reply-To: <20111214190308.GE24598@phenom.dumpdata.com>
X-Enigmail-Version: 1.3.2
Cc: xen-devel@lists.xensource.com, david.vrabel@citrix.com, JBeulich@suse.com,
	Ian.Campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH 01/12] xenbus: Support HVM backends
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 12/14/2011 02:03 PM, Konrad Rzeszutek Wilk wrote:
> On Mon, Nov 28, 2011 at 11:49:00AM -0500, Daniel De Graaf wrote:
>> Add HVM implementations of xenbus_(map,unmap)_ring_v(alloc,free) so
>> that ring mappings can be done without using GNTMAP_contains_pte which
>> is not supported on HVM.
> 
> 
> So what else besides these patches should I do to load the blkback/netback
> drivers in a HVM domain? There are some xen toolstack patches patches I presume?
> Can you tell me what the c/s are (if any?)
> 
> Thanks!

No toolstack changes are required for netback; the interface simply shows
up in the guest the same as it does in a PV domain. The same is true for
blkback, but the toolstack does not currently support specifying backend
domains (PV or HVM) for block devices. I posted a patch earlier [1] adding
this support, but the conversion from block device name to major/minor
number is done in the toolstack's domain, not the domain exporting the
block device.

[1] http://lists.xen.org/archives/html/xen-devel/2011-10/threads.html#00818

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 19:54:27 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 19:54:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rauu2-0008B7-OX; Wed, 14 Dec 2011 19:54:10 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1Rauu1-0008Am-CP
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 19:54:09 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-11.tower-216.messagelabs.com!1323892393!7423187!1
X-Originating-IP: [63.239.65.40]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27099 invoked from network); 14 Dec 2011 19:53:13 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-11.tower-216.messagelabs.com with SMTP;
	14 Dec 2011 19:53:13 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea02.nsa.gov (8.12.10/8.12.10) with ESMTP id
	pBEJrC2Y017058; Wed, 14 Dec 2011 19:53:12 GMT
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id pBEJrCZN009378; 
	Wed, 14 Dec 2011 14:53:12 -0500
Message-ID: <4EE8FEBF.4010001@tycho.nsa.gov>
Date: Wed, 14 Dec 2011 14:53:35 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:7.0.1) Gecko/20110930 Thunderbird/7.0.1
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <20111128152031.GB9655@andromeda.dapyr.net>
	<1322498951-4392-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1322498951-4392-2-git-send-email-dgdegra@tycho.nsa.gov>
	<20111214190308.GE24598@phenom.dumpdata.com>
In-Reply-To: <20111214190308.GE24598@phenom.dumpdata.com>
X-Enigmail-Version: 1.3.2
Cc: xen-devel@lists.xensource.com, david.vrabel@citrix.com, JBeulich@suse.com,
	Ian.Campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH 01/12] xenbus: Support HVM backends
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 12/14/2011 02:03 PM, Konrad Rzeszutek Wilk wrote:
> On Mon, Nov 28, 2011 at 11:49:00AM -0500, Daniel De Graaf wrote:
>> Add HVM implementations of xenbus_(map,unmap)_ring_v(alloc,free) so
>> that ring mappings can be done without using GNTMAP_contains_pte which
>> is not supported on HVM.
> 
> 
> So what else besides these patches should I do to load the blkback/netback
> drivers in a HVM domain? There are some xen toolstack patches patches I presume?
> Can you tell me what the c/s are (if any?)
> 
> Thanks!

No toolstack changes are required for netback; the interface simply shows
up in the guest the same as it does in a PV domain. The same is true for
blkback, but the toolstack does not currently support specifying backend
domains (PV or HVM) for block devices. I posted a patch earlier [1] adding
this support, but the conversion from block device name to major/minor
number is done in the toolstack's domain, not the domain exporting the
block device.

[1] http://lists.xen.org/archives/html/xen-devel/2011-10/threads.html#00818

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 20:13:26 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 20:13:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RavCN-0000h5-5o; Wed, 14 Dec 2011 20:13:07 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RavCL-0000gt-AO
	for Xen-devel@lists.xensource.com; Wed, 14 Dec 2011 20:13:05 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-7.tower-27.messagelabs.com!1323893477!60766032!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25038 invoked from network); 14 Dec 2011 20:11:18 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-7.tower-27.messagelabs.com with SMTP;
	14 Dec 2011 20:11:18 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea01.nsa.gov (8.12.10/8.12.10) with ESMTP id
	pBEKCALN002962; Wed, 14 Dec 2011 20:12:10 GMT
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id pBEKC9Mr010588; 
	Wed, 14 Dec 2011 15:12:10 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: konrad.wilk@oracle.com
Date: Wed, 14 Dec 2011 15:12:12 -0500
Message-Id: <1323893534-436-5-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.4
In-Reply-To: <1323893534-436-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1323893534-436-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>, Xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 4/6] xen/blkback: use grant-table.c hypercall
	wrappers
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Now that the grant table hypercall wrappers support mappings without
GNTMAP_contains_pte, they should be used instead of invoking the
hypercalls manually.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 drivers/block/xen-blkback/blkback.c |   29 ++++-------------------------
 1 files changed, 4 insertions(+), 25 deletions(-)

diff --git a/drivers/block/xen-blkback/blkback.c b/drivers/block/xen-blkback/blkback.c
index 15ec4db..1e256dc 100644
--- a/drivers/block/xen-blkback/blkback.c
+++ b/drivers/block/xen-blkback/blkback.c
@@ -324,6 +324,7 @@ struct seg_buf {
 static void xen_blkbk_unmap(struct pending_req *req)
 {
 	struct gnttab_unmap_grant_ref unmap[BLKIF_MAX_SEGMENTS_PER_REQUEST];
+	struct page *pages[BLKIF_MAX_SEGMENTS_PER_REQUEST];
 	unsigned int i, invcount = 0;
 	grant_handle_t handle;
 	int ret;
@@ -335,25 +336,12 @@ static void xen_blkbk_unmap(struct pending_req *req)
 		gnttab_set_unmap_op(&unmap[invcount], vaddr(req, i),
 				    GNTMAP_host_map, handle);
 		pending_handle(req, i) = BLKBACK_INVALID_HANDLE;
+		pages[invcount] = virt_to_page(vaddr(req, i));
 		invcount++;
 	}
 
-	ret = HYPERVISOR_grant_table_op(
-		GNTTABOP_unmap_grant_ref, unmap, invcount);
+	ret = gnttab_unmap_refs(unmap, pages, invcount, false);
 	BUG_ON(ret);
-	/*
-	 * Note, we use invcount, so nr->pages, so we can't index
-	 * using vaddr(req, i).
-	 */
-	for (i = 0; i < invcount; i++) {
-		ret = m2p_remove_override(
-			virt_to_page(unmap[i].host_addr), false);
-		if (ret) {
-			pr_alert(DRV_PFX "Failed to remove M2P override for %lx\n",
-				 (unsigned long)unmap[i].host_addr);
-			continue;
-		}
-	}
 }
 
 static int xen_blkbk_map(struct blkif_request *req,
@@ -381,7 +369,7 @@ static int xen_blkbk_map(struct blkif_request *req,
 				  pending_req->blkif->domid);
 	}
 
-	ret = HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, map, nseg);
+	ret = gnttab_map_refs(map, NULL, &blkbk->pending_page(pending_req, 0), nseg);
 	BUG_ON(ret);
 
 	/*
@@ -401,15 +389,6 @@ static int xen_blkbk_map(struct blkif_request *req,
 		if (ret)
 			continue;
 
-		ret = m2p_add_override(PFN_DOWN(map[i].dev_bus_addr),
-			blkbk->pending_page(pending_req, i), NULL);
-		if (ret) {
-			pr_alert(DRV_PFX "Failed to install M2P override for %lx (ret: %d)\n",
-				 (unsigned long)map[i].dev_bus_addr, ret);
-			/* We could switch over to GNTTABOP_copy */
-			continue;
-		}
-
 		seg[i].buf  = map[i].dev_bus_addr |
 			(req->u.rw.seg[i].first_sect << 9);
 	}
-- 
1.7.7.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 20:13:26 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 20:13:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RavCN-0000h5-5o; Wed, 14 Dec 2011 20:13:07 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RavCL-0000gt-AO
	for Xen-devel@lists.xensource.com; Wed, 14 Dec 2011 20:13:05 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-7.tower-27.messagelabs.com!1323893477!60766032!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25038 invoked from network); 14 Dec 2011 20:11:18 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-7.tower-27.messagelabs.com with SMTP;
	14 Dec 2011 20:11:18 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea01.nsa.gov (8.12.10/8.12.10) with ESMTP id
	pBEKCALN002962; Wed, 14 Dec 2011 20:12:10 GMT
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id pBEKC9Mr010588; 
	Wed, 14 Dec 2011 15:12:10 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: konrad.wilk@oracle.com
Date: Wed, 14 Dec 2011 15:12:12 -0500
Message-Id: <1323893534-436-5-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.4
In-Reply-To: <1323893534-436-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1323893534-436-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>, Xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 4/6] xen/blkback: use grant-table.c hypercall
	wrappers
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Now that the grant table hypercall wrappers support mappings without
GNTMAP_contains_pte, they should be used instead of invoking the
hypercalls manually.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 drivers/block/xen-blkback/blkback.c |   29 ++++-------------------------
 1 files changed, 4 insertions(+), 25 deletions(-)

diff --git a/drivers/block/xen-blkback/blkback.c b/drivers/block/xen-blkback/blkback.c
index 15ec4db..1e256dc 100644
--- a/drivers/block/xen-blkback/blkback.c
+++ b/drivers/block/xen-blkback/blkback.c
@@ -324,6 +324,7 @@ struct seg_buf {
 static void xen_blkbk_unmap(struct pending_req *req)
 {
 	struct gnttab_unmap_grant_ref unmap[BLKIF_MAX_SEGMENTS_PER_REQUEST];
+	struct page *pages[BLKIF_MAX_SEGMENTS_PER_REQUEST];
 	unsigned int i, invcount = 0;
 	grant_handle_t handle;
 	int ret;
@@ -335,25 +336,12 @@ static void xen_blkbk_unmap(struct pending_req *req)
 		gnttab_set_unmap_op(&unmap[invcount], vaddr(req, i),
 				    GNTMAP_host_map, handle);
 		pending_handle(req, i) = BLKBACK_INVALID_HANDLE;
+		pages[invcount] = virt_to_page(vaddr(req, i));
 		invcount++;
 	}
 
-	ret = HYPERVISOR_grant_table_op(
-		GNTTABOP_unmap_grant_ref, unmap, invcount);
+	ret = gnttab_unmap_refs(unmap, pages, invcount, false);
 	BUG_ON(ret);
-	/*
-	 * Note, we use invcount, so nr->pages, so we can't index
-	 * using vaddr(req, i).
-	 */
-	for (i = 0; i < invcount; i++) {
-		ret = m2p_remove_override(
-			virt_to_page(unmap[i].host_addr), false);
-		if (ret) {
-			pr_alert(DRV_PFX "Failed to remove M2P override for %lx\n",
-				 (unsigned long)unmap[i].host_addr);
-			continue;
-		}
-	}
 }
 
 static int xen_blkbk_map(struct blkif_request *req,
@@ -381,7 +369,7 @@ static int xen_blkbk_map(struct blkif_request *req,
 				  pending_req->blkif->domid);
 	}
 
-	ret = HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, map, nseg);
+	ret = gnttab_map_refs(map, NULL, &blkbk->pending_page(pending_req, 0), nseg);
 	BUG_ON(ret);
 
 	/*
@@ -401,15 +389,6 @@ static int xen_blkbk_map(struct blkif_request *req,
 		if (ret)
 			continue;
 
-		ret = m2p_add_override(PFN_DOWN(map[i].dev_bus_addr),
-			blkbk->pending_page(pending_req, i), NULL);
-		if (ret) {
-			pr_alert(DRV_PFX "Failed to install M2P override for %lx (ret: %d)\n",
-				 (unsigned long)map[i].dev_bus_addr, ret);
-			/* We could switch over to GNTTABOP_copy */
-			continue;
-		}
-
 		seg[i].buf  = map[i].dev_bus_addr |
 			(req->u.rw.seg[i].first_sect << 9);
 	}
-- 
1.7.7.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 20:13:26 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 20:13:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RavCR-0000iG-HC; Wed, 14 Dec 2011 20:13:11 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RavCN-0000gw-VF
	for Xen-devel@lists.xensource.com; Wed, 14 Dec 2011 20:13:08 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-3.tower-174.messagelabs.com!1323893531!5526414!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29503 invoked from network); 14 Dec 2011 20:12:11 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-3.tower-174.messagelabs.com with SMTP;
	14 Dec 2011 20:12:11 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea01.nsa.gov (8.12.10/8.12.10) with ESMTP id
	pBEKCALN002963; Wed, 14 Dec 2011 20:12:10 GMT
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id pBEKC9Mo010588; 
	Wed, 14 Dec 2011 15:12:09 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: konrad.wilk@oracle.com
Date: Wed, 14 Dec 2011 15:12:09 -0500
Message-Id: <1323893534-436-2-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.4
In-Reply-To: <1323893534-436-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1323893534-436-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>, Xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 1/6] xenbus: Support HVM backends
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Add HVM implementations of xenbus_(map,unmap)_ring_v(alloc,free) so
that ring mappings can be done without using GNTMAP_contains_pte which
is not supported on HVM.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 drivers/xen/xenbus/xenbus_client.c |  155 +++++++++++++++++++++++++++++-------
 1 files changed, 125 insertions(+), 30 deletions(-)

diff --git a/drivers/xen/xenbus/xenbus_client.c b/drivers/xen/xenbus/xenbus_client.c
index 1906125..ecd695d 100644
--- a/drivers/xen/xenbus/xenbus_client.c
+++ b/drivers/xen/xenbus/xenbus_client.c
@@ -32,16 +32,27 @@
 
 #include <linux/slab.h>
 #include <linux/types.h>
+#include <linux/spinlock.h>
 #include <linux/vmalloc.h>
 #include <linux/export.h>
 #include <asm/xen/hypervisor.h>
 #include <asm/xen/page.h>
 #include <xen/interface/xen.h>
 #include <xen/interface/event_channel.h>
+#include <xen/balloon.h>
 #include <xen/events.h>
 #include <xen/grant_table.h>
 #include <xen/xenbus.h>
 
+struct xenbus_map_node {
+	struct list_head next;
+	struct page *page;
+	grant_handle_t handle;
+};
+
+static DEFINE_SPINLOCK(xenbus_valloc_lock);
+static LIST_HEAD(xenbus_valloc_pages);
+
 const char *xenbus_strstate(enum xenbus_state state)
 {
 	static const char *const name[] = {
@@ -420,21 +431,8 @@ int xenbus_free_evtchn(struct xenbus_device *dev, int port)
 EXPORT_SYMBOL_GPL(xenbus_free_evtchn);
 
 
-/**
- * xenbus_map_ring_valloc
- * @dev: xenbus device
- * @gnt_ref: grant reference
- * @vaddr: pointer to address to be filled out by mapping
- *
- * Based on Rusty Russell's skeleton driver's map_page.
- * Map a page of memory into this domain from another domain's grant table.
- * xenbus_map_ring_valloc allocates a page of virtual address space, maps the
- * page to that address, and sets *vaddr to that address.
- * Returns 0 on success, and GNTST_* (see xen/include/interface/grant_table.h)
- * or -ENOMEM on error. If an error is returned, device will switch to
- * XenbusStateClosing and the error message will be saved in XenStore.
- */
-int xenbus_map_ring_valloc(struct xenbus_device *dev, int gnt_ref, void **vaddr)
+static int xenbus_map_ring_valloc_pv(struct xenbus_device *dev,
+                                     int gnt_ref, void **vaddr)
 {
 	struct gnttab_map_grant_ref op = {
 		.flags = GNTMAP_host_map | GNTMAP_contains_pte,
@@ -469,6 +467,64 @@ int xenbus_map_ring_valloc(struct xenbus_device *dev, int gnt_ref, void **vaddr)
 	*vaddr = area->addr;
 	return 0;
 }
+
+static int xenbus_map_ring_valloc_hvm(struct xenbus_device *dev,
+                                     int gnt_ref, void **vaddr)
+{
+	struct xenbus_map_node *node;
+	int err;
+	void *addr;
+
+	*vaddr = NULL;
+
+	node = kzalloc(sizeof(*node), GFP_KERNEL);
+	if (!node)
+		return -ENOMEM;
+
+	err = alloc_xenballooned_pages(1, &node->page, false /* lowmem */);
+	if (err)
+		goto out_err;
+
+	addr = pfn_to_kaddr(page_to_pfn(node->page));
+
+	err = xenbus_map_ring(dev, gnt_ref, &node->handle, addr);
+	if (err)
+		goto out_err;
+
+	spin_lock(&xenbus_valloc_lock);
+	list_add(&node->next, &xenbus_valloc_pages);
+	spin_unlock(&xenbus_valloc_lock);
+
+	*vaddr = addr;
+	return 0;
+
+ out_err:
+	free_xenballooned_pages(1, &node->page);
+	kfree(node);
+	return err;
+}
+
+/**
+ * xenbus_map_ring_valloc
+ * @dev: xenbus device
+ * @gnt_ref: grant reference
+ * @vaddr: pointer to address to be filled out by mapping
+ *
+ * Based on Rusty Russell's skeleton driver's map_page.
+ * Map a page of memory into this domain from another domain's grant table.
+ * xenbus_map_ring_valloc allocates a page of virtual address space, maps the
+ * page to that address, and sets *vaddr to that address.
+ * Returns 0 on success, and GNTST_* (see xen/include/interface/grant_table.h)
+ * or -ENOMEM on error. If an error is returned, device will switch to
+ * XenbusStateClosing and the error message will be saved in XenStore.
+ */
+int xenbus_map_ring_valloc(struct xenbus_device *dev, int gnt_ref, void **vaddr)
+{
+	if (xen_pv_domain())
+		return xenbus_map_ring_valloc_pv(dev, gnt_ref, vaddr);
+	else
+		return xenbus_map_ring_valloc_hvm(dev, gnt_ref, vaddr);
+}
 EXPORT_SYMBOL_GPL(xenbus_map_ring_valloc);
 
 
@@ -510,20 +566,7 @@ int xenbus_map_ring(struct xenbus_device *dev, int gnt_ref,
 }
 EXPORT_SYMBOL_GPL(xenbus_map_ring);
 
-
-/**
- * xenbus_unmap_ring_vfree
- * @dev: xenbus device
- * @vaddr: addr to unmap
- *
- * Based on Rusty Russell's skeleton driver's unmap_page.
- * Unmap a page of memory in this domain that was imported from another domain.
- * Use xenbus_unmap_ring_vfree if you mapped in your memory with
- * xenbus_map_ring_valloc (it will free the virtual address space).
- * Returns 0 on success and returns GNTST_* on error
- * (see xen/include/interface/grant_table.h).
- */
-int xenbus_unmap_ring_vfree(struct xenbus_device *dev, void *vaddr)
+static int xenbus_unmap_ring_vfree_pv(struct xenbus_device *dev, void *vaddr)
 {
 	struct vm_struct *area;
 	struct gnttab_unmap_grant_ref op = {
@@ -566,8 +609,60 @@ int xenbus_unmap_ring_vfree(struct xenbus_device *dev, void *vaddr)
 
 	return op.status;
 }
-EXPORT_SYMBOL_GPL(xenbus_unmap_ring_vfree);
 
+static int xenbus_unmap_ring_vfree_hvm(struct xenbus_device *dev, void *vaddr)
+{
+	int rv;
+	struct xenbus_map_node *node;
+	void *addr;
+
+	spin_lock(&xenbus_valloc_lock);
+	list_for_each_entry(node, &xenbus_valloc_pages, next) {
+		addr = pfn_to_kaddr(page_to_pfn(node->page));
+		if (addr == vaddr) {
+			list_del(&node->next);
+			goto found;
+		}
+	}
+	node = NULL;
+ found:
+	spin_unlock(&xenbus_valloc_lock);
+
+	if (!node) {
+		xenbus_dev_error(dev, -ENOENT,
+				 "can't find mapped virtual address %p", vaddr);
+		return -ENOENT;
+	}
+
+	rv = xenbus_unmap_ring(dev, node->handle, addr);
+
+	if (!rv)
+		free_xenballooned_pages(1, &node->page);
+
+	kfree(node);
+	return rv;
+}
+
+/**
+ * xenbus_unmap_ring_vfree
+ * @dev: xenbus device
+ * @vaddr: addr to unmap
+ *
+ * Based on Rusty Russell's skeleton driver's unmap_page.
+ * Unmap a page of memory in this domain that was imported from another domain.
+ * Use xenbus_unmap_ring_vfree if you mapped in your memory with
+ * xenbus_map_ring_valloc (it will free the virtual address space).
+ * Returns 0 on success and returns GNTST_* on error
+ * (see xen/include/interface/grant_table.h).
+ */
+int xenbus_unmap_ring_vfree(struct xenbus_device *dev, void *vaddr)
+{
+	if (xen_pv_domain())
+		return xenbus_unmap_ring_vfree_pv(dev, vaddr);
+	else
+		return xenbus_unmap_ring_vfree_hvm(dev, vaddr);
+}
+EXPORT_SYMBOL_GPL(xenbus_unmap_ring_vfree);
 
 /**
  * xenbus_unmap_ring
-- 
1.7.7.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 20:13:26 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 20:13:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RavCR-0000iG-HC; Wed, 14 Dec 2011 20:13:11 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RavCN-0000gw-VF
	for Xen-devel@lists.xensource.com; Wed, 14 Dec 2011 20:13:08 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-3.tower-174.messagelabs.com!1323893531!5526414!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29503 invoked from network); 14 Dec 2011 20:12:11 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-3.tower-174.messagelabs.com with SMTP;
	14 Dec 2011 20:12:11 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea01.nsa.gov (8.12.10/8.12.10) with ESMTP id
	pBEKCALN002963; Wed, 14 Dec 2011 20:12:10 GMT
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id pBEKC9Mo010588; 
	Wed, 14 Dec 2011 15:12:09 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: konrad.wilk@oracle.com
Date: Wed, 14 Dec 2011 15:12:09 -0500
Message-Id: <1323893534-436-2-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.4
In-Reply-To: <1323893534-436-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1323893534-436-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>, Xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 1/6] xenbus: Support HVM backends
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Add HVM implementations of xenbus_(map,unmap)_ring_v(alloc,free) so
that ring mappings can be done without using GNTMAP_contains_pte which
is not supported on HVM.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 drivers/xen/xenbus/xenbus_client.c |  155 +++++++++++++++++++++++++++++-------
 1 files changed, 125 insertions(+), 30 deletions(-)

diff --git a/drivers/xen/xenbus/xenbus_client.c b/drivers/xen/xenbus/xenbus_client.c
index 1906125..ecd695d 100644
--- a/drivers/xen/xenbus/xenbus_client.c
+++ b/drivers/xen/xenbus/xenbus_client.c
@@ -32,16 +32,27 @@
 
 #include <linux/slab.h>
 #include <linux/types.h>
+#include <linux/spinlock.h>
 #include <linux/vmalloc.h>
 #include <linux/export.h>
 #include <asm/xen/hypervisor.h>
 #include <asm/xen/page.h>
 #include <xen/interface/xen.h>
 #include <xen/interface/event_channel.h>
+#include <xen/balloon.h>
 #include <xen/events.h>
 #include <xen/grant_table.h>
 #include <xen/xenbus.h>
 
+struct xenbus_map_node {
+	struct list_head next;
+	struct page *page;
+	grant_handle_t handle;
+};
+
+static DEFINE_SPINLOCK(xenbus_valloc_lock);
+static LIST_HEAD(xenbus_valloc_pages);
+
 const char *xenbus_strstate(enum xenbus_state state)
 {
 	static const char *const name[] = {
@@ -420,21 +431,8 @@ int xenbus_free_evtchn(struct xenbus_device *dev, int port)
 EXPORT_SYMBOL_GPL(xenbus_free_evtchn);
 
 
-/**
- * xenbus_map_ring_valloc
- * @dev: xenbus device
- * @gnt_ref: grant reference
- * @vaddr: pointer to address to be filled out by mapping
- *
- * Based on Rusty Russell's skeleton driver's map_page.
- * Map a page of memory into this domain from another domain's grant table.
- * xenbus_map_ring_valloc allocates a page of virtual address space, maps the
- * page to that address, and sets *vaddr to that address.
- * Returns 0 on success, and GNTST_* (see xen/include/interface/grant_table.h)
- * or -ENOMEM on error. If an error is returned, device will switch to
- * XenbusStateClosing and the error message will be saved in XenStore.
- */
-int xenbus_map_ring_valloc(struct xenbus_device *dev, int gnt_ref, void **vaddr)
+static int xenbus_map_ring_valloc_pv(struct xenbus_device *dev,
+                                     int gnt_ref, void **vaddr)
 {
 	struct gnttab_map_grant_ref op = {
 		.flags = GNTMAP_host_map | GNTMAP_contains_pte,
@@ -469,6 +467,64 @@ int xenbus_map_ring_valloc(struct xenbus_device *dev, int gnt_ref, void **vaddr)
 	*vaddr = area->addr;
 	return 0;
 }
+
+static int xenbus_map_ring_valloc_hvm(struct xenbus_device *dev,
+                                     int gnt_ref, void **vaddr)
+{
+	struct xenbus_map_node *node;
+	int err;
+	void *addr;
+
+	*vaddr = NULL;
+
+	node = kzalloc(sizeof(*node), GFP_KERNEL);
+	if (!node)
+		return -ENOMEM;
+
+	err = alloc_xenballooned_pages(1, &node->page, false /* lowmem */);
+	if (err)
+		goto out_err;
+
+	addr = pfn_to_kaddr(page_to_pfn(node->page));
+
+	err = xenbus_map_ring(dev, gnt_ref, &node->handle, addr);
+	if (err)
+		goto out_err;
+
+	spin_lock(&xenbus_valloc_lock);
+	list_add(&node->next, &xenbus_valloc_pages);
+	spin_unlock(&xenbus_valloc_lock);
+
+	*vaddr = addr;
+	return 0;
+
+ out_err:
+	free_xenballooned_pages(1, &node->page);
+	kfree(node);
+	return err;
+}
+
+/**
+ * xenbus_map_ring_valloc
+ * @dev: xenbus device
+ * @gnt_ref: grant reference
+ * @vaddr: pointer to address to be filled out by mapping
+ *
+ * Based on Rusty Russell's skeleton driver's map_page.
+ * Map a page of memory into this domain from another domain's grant table.
+ * xenbus_map_ring_valloc allocates a page of virtual address space, maps the
+ * page to that address, and sets *vaddr to that address.
+ * Returns 0 on success, and GNTST_* (see xen/include/interface/grant_table.h)
+ * or -ENOMEM on error. If an error is returned, device will switch to
+ * XenbusStateClosing and the error message will be saved in XenStore.
+ */
+int xenbus_map_ring_valloc(struct xenbus_device *dev, int gnt_ref, void **vaddr)
+{
+	if (xen_pv_domain())
+		return xenbus_map_ring_valloc_pv(dev, gnt_ref, vaddr);
+	else
+		return xenbus_map_ring_valloc_hvm(dev, gnt_ref, vaddr);
+}
 EXPORT_SYMBOL_GPL(xenbus_map_ring_valloc);
 
 
@@ -510,20 +566,7 @@ int xenbus_map_ring(struct xenbus_device *dev, int gnt_ref,
 }
 EXPORT_SYMBOL_GPL(xenbus_map_ring);
 
-
-/**
- * xenbus_unmap_ring_vfree
- * @dev: xenbus device
- * @vaddr: addr to unmap
- *
- * Based on Rusty Russell's skeleton driver's unmap_page.
- * Unmap a page of memory in this domain that was imported from another domain.
- * Use xenbus_unmap_ring_vfree if you mapped in your memory with
- * xenbus_map_ring_valloc (it will free the virtual address space).
- * Returns 0 on success and returns GNTST_* on error
- * (see xen/include/interface/grant_table.h).
- */
-int xenbus_unmap_ring_vfree(struct xenbus_device *dev, void *vaddr)
+static int xenbus_unmap_ring_vfree_pv(struct xenbus_device *dev, void *vaddr)
 {
 	struct vm_struct *area;
 	struct gnttab_unmap_grant_ref op = {
@@ -566,8 +609,60 @@ int xenbus_unmap_ring_vfree(struct xenbus_device *dev, void *vaddr)
 
 	return op.status;
 }
-EXPORT_SYMBOL_GPL(xenbus_unmap_ring_vfree);
 
+static int xenbus_unmap_ring_vfree_hvm(struct xenbus_device *dev, void *vaddr)
+{
+	int rv;
+	struct xenbus_map_node *node;
+	void *addr;
+
+	spin_lock(&xenbus_valloc_lock);
+	list_for_each_entry(node, &xenbus_valloc_pages, next) {
+		addr = pfn_to_kaddr(page_to_pfn(node->page));
+		if (addr == vaddr) {
+			list_del(&node->next);
+			goto found;
+		}
+	}
+	node = NULL;
+ found:
+	spin_unlock(&xenbus_valloc_lock);
+
+	if (!node) {
+		xenbus_dev_error(dev, -ENOENT,
+				 "can't find mapped virtual address %p", vaddr);
+		return -ENOENT;
+	}
+
+	rv = xenbus_unmap_ring(dev, node->handle, addr);
+
+	if (!rv)
+		free_xenballooned_pages(1, &node->page);
+
+	kfree(node);
+	return rv;
+}
+
+/**
+ * xenbus_unmap_ring_vfree
+ * @dev: xenbus device
+ * @vaddr: addr to unmap
+ *
+ * Based on Rusty Russell's skeleton driver's unmap_page.
+ * Unmap a page of memory in this domain that was imported from another domain.
+ * Use xenbus_unmap_ring_vfree if you mapped in your memory with
+ * xenbus_map_ring_valloc (it will free the virtual address space).
+ * Returns 0 on success and returns GNTST_* on error
+ * (see xen/include/interface/grant_table.h).
+ */
+int xenbus_unmap_ring_vfree(struct xenbus_device *dev, void *vaddr)
+{
+	if (xen_pv_domain())
+		return xenbus_unmap_ring_vfree_pv(dev, vaddr);
+	else
+		return xenbus_unmap_ring_vfree_hvm(dev, vaddr);
+}
+EXPORT_SYMBOL_GPL(xenbus_unmap_ring_vfree);
 
 /**
  * xenbus_unmap_ring
-- 
1.7.7.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 20:13:27 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 20:13:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RavCP-0000hk-Th; Wed, 14 Dec 2011 20:13:09 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RavCN-0000gu-Co
	for Xen-devel@lists.xensource.com; Wed, 14 Dec 2011 20:13:07 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-16.tower-21.messagelabs.com!1323893531!1543525!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18256 invoked from network); 14 Dec 2011 20:12:11 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-16.tower-21.messagelabs.com with SMTP;
	14 Dec 2011 20:12:11 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea01.nsa.gov (8.12.10/8.12.10) with ESMTP id
	pBEKCALN002965; Wed, 14 Dec 2011 20:12:10 GMT
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id pBEKC9Mt010588; 
	Wed, 14 Dec 2011 15:12:10 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: konrad.wilk@oracle.com
Date: Wed, 14 Dec 2011 15:12:14 -0500
Message-Id: <1323893534-436-7-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.4
In-Reply-To: <1323893534-436-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1323893534-436-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>, Xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 6/6] xen/blkback: Enable blkback on HVM guests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 drivers/block/xen-blkback/blkback.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/block/xen-blkback/blkback.c b/drivers/block/xen-blkback/blkback.c
index 1e256dc..fbffdf0 100644
--- a/drivers/block/xen-blkback/blkback.c
+++ b/drivers/block/xen-blkback/blkback.c
@@ -823,7 +823,7 @@ static int __init xen_blkif_init(void)
 	int i, mmap_pages;
 	int rc = 0;
 
-	if (!xen_pv_domain())
+	if (!xen_domain())
 		return -ENODEV;
 
 	blkbk = kzalloc(sizeof(struct xen_blkbk), GFP_KERNEL);
-- 
1.7.7.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 20:13:27 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 20:13:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RavCP-0000hk-Th; Wed, 14 Dec 2011 20:13:09 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RavCN-0000gu-Co
	for Xen-devel@lists.xensource.com; Wed, 14 Dec 2011 20:13:07 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-16.tower-21.messagelabs.com!1323893531!1543525!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18256 invoked from network); 14 Dec 2011 20:12:11 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-16.tower-21.messagelabs.com with SMTP;
	14 Dec 2011 20:12:11 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea01.nsa.gov (8.12.10/8.12.10) with ESMTP id
	pBEKCALN002965; Wed, 14 Dec 2011 20:12:10 GMT
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id pBEKC9Mt010588; 
	Wed, 14 Dec 2011 15:12:10 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: konrad.wilk@oracle.com
Date: Wed, 14 Dec 2011 15:12:14 -0500
Message-Id: <1323893534-436-7-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.4
In-Reply-To: <1323893534-436-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1323893534-436-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>, Xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 6/6] xen/blkback: Enable blkback on HVM guests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 drivers/block/xen-blkback/blkback.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/block/xen-blkback/blkback.c b/drivers/block/xen-blkback/blkback.c
index 1e256dc..fbffdf0 100644
--- a/drivers/block/xen-blkback/blkback.c
+++ b/drivers/block/xen-blkback/blkback.c
@@ -823,7 +823,7 @@ static int __init xen_blkif_init(void)
 	int i, mmap_pages;
 	int rc = 0;
 
-	if (!xen_pv_domain())
+	if (!xen_domain())
 		return -ENODEV;
 
 	blkbk = kzalloc(sizeof(struct xen_blkbk), GFP_KERNEL);
-- 
1.7.7.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 20:13:27 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 20:13:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RavCP-0000hb-IA; Wed, 14 Dec 2011 20:13:09 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RavCN-0000gs-70
	for Xen-devel@lists.xensource.com; Wed, 14 Dec 2011 20:13:07 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-10.tower-174.messagelabs.com!1323893530!5590972!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25077 invoked from network); 14 Dec 2011 20:12:11 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-10.tower-174.messagelabs.com with SMTP;
	14 Dec 2011 20:12:11 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea01.nsa.gov (8.12.10/8.12.10) with ESMTP id
	pBEKC9LN002959; Wed, 14 Dec 2011 20:12:10 GMT
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id pBEKC9Mn010588; 
	Wed, 14 Dec 2011 15:12:09 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: konrad.wilk@oracle.com
Date: Wed, 14 Dec 2011 15:12:08 -0500
Message-Id: <1323893534-436-1-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.4
Cc: Xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH v3 0/6] xen/{net,
	blk}back support for running in HVM
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Changes from v2:
 - Clarified comments and commit messages
 - Based on v3.2-rc3

Changes from v1:
 - Rebased on top of David's patches
 - Grant table wrapper functions used where appropriate

[PATCH 1/6] xenbus: Support HVM backends
[PATCH 2/6] xenbus: Use grant-table wrapper functions
[PATCH 3/6] xen/grant-table: Support mappings required by blkback
[PATCH 4/6] xen/blkback: use grant-table.c hypercall wrappers
[PATCH 5/6] xen/netback: Enable netback on HVM guests
[PATCH 6/6] xen/blkback: Enable blkback on HVM guests

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 20:13:27 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 20:13:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RavCR-0000i8-4I; Wed, 14 Dec 2011 20:13:11 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RavCN-0000gy-SL
	for Xen-devel@lists.xensource.com; Wed, 14 Dec 2011 20:13:08 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-2.tower-216.messagelabs.com!1323893531!8830156!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2118 invoked from network); 14 Dec 2011 20:12:11 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-2.tower-216.messagelabs.com with SMTP;
	14 Dec 2011 20:12:11 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea01.nsa.gov (8.12.10/8.12.10) with ESMTP id
	pBEKCALN002964; Wed, 14 Dec 2011 20:12:10 GMT
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id pBEKC9Ms010588; 
	Wed, 14 Dec 2011 15:12:10 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: konrad.wilk@oracle.com
Date: Wed, 14 Dec 2011 15:12:13 -0500
Message-Id: <1323893534-436-6-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.4
In-Reply-To: <1323893534-436-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1323893534-436-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>, Xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 5/6] xen/netback: Enable netback on HVM guests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 drivers/net/xen-netback/netback.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
index 0cb594c..951c713 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -1638,7 +1638,7 @@ static int __init netback_init(void)
 	int rc = 0;
 	int group;
 
-	if (!xen_pv_domain())
+	if (!xen_domain())
 		return -ENODEV;
 
 	xen_netbk_group_nr = num_online_cpus();
-- 
1.7.7.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 20:13:27 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 20:13:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RavCP-0000hb-IA; Wed, 14 Dec 2011 20:13:09 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RavCN-0000gs-70
	for Xen-devel@lists.xensource.com; Wed, 14 Dec 2011 20:13:07 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-10.tower-174.messagelabs.com!1323893530!5590972!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25077 invoked from network); 14 Dec 2011 20:12:11 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-10.tower-174.messagelabs.com with SMTP;
	14 Dec 2011 20:12:11 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea01.nsa.gov (8.12.10/8.12.10) with ESMTP id
	pBEKC9LN002959; Wed, 14 Dec 2011 20:12:10 GMT
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id pBEKC9Mn010588; 
	Wed, 14 Dec 2011 15:12:09 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: konrad.wilk@oracle.com
Date: Wed, 14 Dec 2011 15:12:08 -0500
Message-Id: <1323893534-436-1-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.4
Cc: Xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH v3 0/6] xen/{net,
	blk}back support for running in HVM
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Changes from v2:
 - Clarified comments and commit messages
 - Based on v3.2-rc3

Changes from v1:
 - Rebased on top of David's patches
 - Grant table wrapper functions used where appropriate

[PATCH 1/6] xenbus: Support HVM backends
[PATCH 2/6] xenbus: Use grant-table wrapper functions
[PATCH 3/6] xen/grant-table: Support mappings required by blkback
[PATCH 4/6] xen/blkback: use grant-table.c hypercall wrappers
[PATCH 5/6] xen/netback: Enable netback on HVM guests
[PATCH 6/6] xen/blkback: Enable blkback on HVM guests

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 20:13:27 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 20:13:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RavCR-0000i8-4I; Wed, 14 Dec 2011 20:13:11 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RavCN-0000gy-SL
	for Xen-devel@lists.xensource.com; Wed, 14 Dec 2011 20:13:08 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-2.tower-216.messagelabs.com!1323893531!8830156!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2118 invoked from network); 14 Dec 2011 20:12:11 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-2.tower-216.messagelabs.com with SMTP;
	14 Dec 2011 20:12:11 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea01.nsa.gov (8.12.10/8.12.10) with ESMTP id
	pBEKCALN002964; Wed, 14 Dec 2011 20:12:10 GMT
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id pBEKC9Ms010588; 
	Wed, 14 Dec 2011 15:12:10 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: konrad.wilk@oracle.com
Date: Wed, 14 Dec 2011 15:12:13 -0500
Message-Id: <1323893534-436-6-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.4
In-Reply-To: <1323893534-436-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1323893534-436-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>, Xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 5/6] xen/netback: Enable netback on HVM guests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 drivers/net/xen-netback/netback.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
index 0cb594c..951c713 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -1638,7 +1638,7 @@ static int __init netback_init(void)
 	int rc = 0;
 	int group;
 
-	if (!xen_pv_domain())
+	if (!xen_domain())
 		return -ENODEV;
 
 	xen_netbk_group_nr = num_online_cpus();
-- 
1.7.7.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 20:13:27 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 20:13:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RavCQ-0000hr-A2; Wed, 14 Dec 2011 20:13:10 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RavCN-0000gv-Pi
	for Xen-devel@lists.xensource.com; Wed, 14 Dec 2011 20:13:08 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-12.tower-182.messagelabs.com!1323893531!7300444!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26959 invoked from network); 14 Dec 2011 20:12:11 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-12.tower-182.messagelabs.com with SMTP;
	14 Dec 2011 20:12:11 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea01.nsa.gov (8.12.10/8.12.10) with ESMTP id
	pBEKCALN002961; Wed, 14 Dec 2011 20:12:10 GMT
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id pBEKC9Mq010588; 
	Wed, 14 Dec 2011 15:12:10 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: konrad.wilk@oracle.com
Date: Wed, 14 Dec 2011 15:12:11 -0500
Message-Id: <1323893534-436-4-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.4
In-Reply-To: <1323893534-436-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1323893534-436-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>, Xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 3/6] xen/grant-table: Support mappings required
	by blkback
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Add support for mappings without GNTMAP_contains_pte. This was not
supported because the unmap operation assumed that this flag was being
used; adding a parameter to the unmap operation to allow the PTE
clearing to be disabled is sufficient to make unmap capable of
supporting either mapping type.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 drivers/xen/gntdev.c      |    3 ++-
 drivers/xen/grant-table.c |   23 ++++-------------------
 include/xen/grant_table.h |    2 +-
 3 files changed, 7 insertions(+), 21 deletions(-)

diff --git a/drivers/xen/gntdev.c b/drivers/xen/gntdev.c
index afca14d..65bff07 100644
--- a/drivers/xen/gntdev.c
+++ b/drivers/xen/gntdev.c
@@ -312,7 +312,8 @@ static int __unmap_grant_pages(struct grant_map *map, int offset, int pages)
 		}
 	}
 
-	err = gnttab_unmap_refs(map->unmap_ops + offset, map->pages + offset, pages);
+	err = gnttab_unmap_refs(map->unmap_ops + offset, map->pages + offset,
+	                        pages, true);
 	if (err)
 		return err;
 
diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
index bf1c094..a02d139 100644
--- a/drivers/xen/grant-table.c
+++ b/drivers/xen/grant-table.c
@@ -472,24 +472,9 @@ int gnttab_map_refs(struct gnttab_map_grant_ref *map_ops,
 				(map_ops[i].host_addr & ~PAGE_MASK));
 			mfn = pte_mfn(*pte);
 		} else {
-			/* If you really wanted to do this:
-			 * mfn = PFN_DOWN(map_ops[i].dev_bus_addr);
-			 *
-			 * The reason we do not implement it is b/c on the
-			 * unmap path (gnttab_unmap_refs) we have no means of
-			 * checking whether the page is !GNTMAP_contains_pte.
-			 *
-			 * That is without some extra data-structure to carry
-			 * the struct page, bool clear_pte, and list_head next
-			 * tuples and deal with allocation/delallocation, etc.
-			 *
-			 * The users of this API set the GNTMAP_contains_pte
-			 * flag so lets just return not supported until it
-			 * becomes neccessary to implement.
-			 */
-			return -EOPNOTSUPP;
+			mfn = PFN_DOWN(map_ops[i].dev_bus_addr);
 		}
-		ret = m2p_add_override(mfn, pages[i], &kmap_ops[i]);
+		ret = m2p_add_override(mfn, pages[i], kmap_ops ? &kmap_ops[i] : NULL);
 		if (ret)
 			return ret;
 	}
@@ -499,7 +484,7 @@ int gnttab_map_refs(struct gnttab_map_grant_ref *map_ops,
 EXPORT_SYMBOL_GPL(gnttab_map_refs);
 
 int gnttab_unmap_refs(struct gnttab_unmap_grant_ref *unmap_ops,
-		struct page **pages, unsigned int count)
+		struct page **pages, unsigned int count, bool clear_pte)
 {
 	int i, ret;
 
@@ -511,7 +496,7 @@ int gnttab_unmap_refs(struct gnttab_unmap_grant_ref *unmap_ops,
 		return ret;
 
 	for (i = 0; i < count; i++) {
-		ret = m2p_remove_override(pages[i], true /* clear the PTE */);
+		ret = m2p_remove_override(pages[i], clear_pte);
 		if (ret)
 			return ret;
 	}
diff --git a/include/xen/grant_table.h b/include/xen/grant_table.h
index 11e2dfc..37da54d 100644
--- a/include/xen/grant_table.h
+++ b/include/xen/grant_table.h
@@ -158,6 +158,6 @@ int gnttab_map_refs(struct gnttab_map_grant_ref *map_ops,
 			struct gnttab_map_grant_ref *kmap_ops,
 		    struct page **pages, unsigned int count);
 int gnttab_unmap_refs(struct gnttab_unmap_grant_ref *unmap_ops,
-		      struct page **pages, unsigned int count);
+		      struct page **pages, unsigned int count, bool clear_pte);
 
 #endif /* __ASM_GNTTAB_H__ */
-- 
1.7.7.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 20:13:27 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 20:13:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RavCQ-0000hz-MS; Wed, 14 Dec 2011 20:13:10 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RavCN-0000gx-Sa
	for Xen-devel@lists.xensource.com; Wed, 14 Dec 2011 20:13:08 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-13.tower-216.messagelabs.com!1323893531!6893614!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26150 invoked from network); 14 Dec 2011 20:12:11 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-13.tower-216.messagelabs.com with SMTP;
	14 Dec 2011 20:12:11 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea01.nsa.gov (8.12.10/8.12.10) with ESMTP id
	pBEKCALN002960; Wed, 14 Dec 2011 20:12:10 GMT
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id pBEKC9Mp010588; 
	Wed, 14 Dec 2011 15:12:09 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: konrad.wilk@oracle.com
Date: Wed, 14 Dec 2011 15:12:10 -0500
Message-Id: <1323893534-436-3-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.4
In-Reply-To: <1323893534-436-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1323893534-436-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>, Xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 2/6] xenbus: Use grant-table wrapper functions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

For xenbus_{map,unmap}_ring to work on HVM, the grant table operations
must be set up using the gnttab_set_{map,unmap}_op functions instead of
directly populating the fields of gnttab_map_grant_ref. These functions
simply populate the structure on paravirtualized Xen; however, on HVM
they must call __pa() on vaddr when populating op->host_addr because the
hypervisor cannot directly interpret guest-virtual addresses.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 drivers/xen/xenbus/xenbus_client.c |   17 +++++++----------
 1 files changed, 7 insertions(+), 10 deletions(-)

diff --git a/drivers/xen/xenbus/xenbus_client.c b/drivers/xen/xenbus/xenbus_client.c
index ecd695d..8a23f1a 100644
--- a/drivers/xen/xenbus/xenbus_client.c
+++ b/drivers/xen/xenbus/xenbus_client.c
@@ -545,12 +545,10 @@ EXPORT_SYMBOL_GPL(xenbus_map_ring_valloc);
 int xenbus_map_ring(struct xenbus_device *dev, int gnt_ref,
 		    grant_handle_t *handle, void *vaddr)
 {
-	struct gnttab_map_grant_ref op = {
-		.host_addr = (unsigned long)vaddr,
-		.flags     = GNTMAP_host_map,
-		.ref       = gnt_ref,
-		.dom       = dev->otherend_id,
-	};
+	struct gnttab_map_grant_ref op;
+
+	gnttab_set_map_op(&op, (phys_addr_t)vaddr, GNTMAP_host_map, gnt_ref,
+	                  dev->otherend_id);
 
 	if (HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, &op, 1))
 		BUG();
@@ -677,10 +675,9 @@ EXPORT_SYMBOL_GPL(xenbus_unmap_ring_vfree);
 int xenbus_unmap_ring(struct xenbus_device *dev,
 		      grant_handle_t handle, void *vaddr)
 {
-	struct gnttab_unmap_grant_ref op = {
-		.host_addr = (unsigned long)vaddr,
-		.handle    = handle,
-	};
+	struct gnttab_unmap_grant_ref op;
+
+	gnttab_set_unmap_op(&op, (phys_addr_t)vaddr, GNTMAP_host_map, handle);
 
 	if (HYPERVISOR_grant_table_op(GNTTABOP_unmap_grant_ref, &op, 1))
 		BUG();
-- 
1.7.7.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 20:13:27 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 20:13:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RavCQ-0000hr-A2; Wed, 14 Dec 2011 20:13:10 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RavCN-0000gv-Pi
	for Xen-devel@lists.xensource.com; Wed, 14 Dec 2011 20:13:08 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-12.tower-182.messagelabs.com!1323893531!7300444!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26959 invoked from network); 14 Dec 2011 20:12:11 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-12.tower-182.messagelabs.com with SMTP;
	14 Dec 2011 20:12:11 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea01.nsa.gov (8.12.10/8.12.10) with ESMTP id
	pBEKCALN002961; Wed, 14 Dec 2011 20:12:10 GMT
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id pBEKC9Mq010588; 
	Wed, 14 Dec 2011 15:12:10 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: konrad.wilk@oracle.com
Date: Wed, 14 Dec 2011 15:12:11 -0500
Message-Id: <1323893534-436-4-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.4
In-Reply-To: <1323893534-436-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1323893534-436-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>, Xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 3/6] xen/grant-table: Support mappings required
	by blkback
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Add support for mappings without GNTMAP_contains_pte. This was not
supported because the unmap operation assumed that this flag was being
used; adding a parameter to the unmap operation to allow the PTE
clearing to be disabled is sufficient to make unmap capable of
supporting either mapping type.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 drivers/xen/gntdev.c      |    3 ++-
 drivers/xen/grant-table.c |   23 ++++-------------------
 include/xen/grant_table.h |    2 +-
 3 files changed, 7 insertions(+), 21 deletions(-)

diff --git a/drivers/xen/gntdev.c b/drivers/xen/gntdev.c
index afca14d..65bff07 100644
--- a/drivers/xen/gntdev.c
+++ b/drivers/xen/gntdev.c
@@ -312,7 +312,8 @@ static int __unmap_grant_pages(struct grant_map *map, int offset, int pages)
 		}
 	}
 
-	err = gnttab_unmap_refs(map->unmap_ops + offset, map->pages + offset, pages);
+	err = gnttab_unmap_refs(map->unmap_ops + offset, map->pages + offset,
+	                        pages, true);
 	if (err)
 		return err;
 
diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
index bf1c094..a02d139 100644
--- a/drivers/xen/grant-table.c
+++ b/drivers/xen/grant-table.c
@@ -472,24 +472,9 @@ int gnttab_map_refs(struct gnttab_map_grant_ref *map_ops,
 				(map_ops[i].host_addr & ~PAGE_MASK));
 			mfn = pte_mfn(*pte);
 		} else {
-			/* If you really wanted to do this:
-			 * mfn = PFN_DOWN(map_ops[i].dev_bus_addr);
-			 *
-			 * The reason we do not implement it is b/c on the
-			 * unmap path (gnttab_unmap_refs) we have no means of
-			 * checking whether the page is !GNTMAP_contains_pte.
-			 *
-			 * That is without some extra data-structure to carry
-			 * the struct page, bool clear_pte, and list_head next
-			 * tuples and deal with allocation/delallocation, etc.
-			 *
-			 * The users of this API set the GNTMAP_contains_pte
-			 * flag so lets just return not supported until it
-			 * becomes neccessary to implement.
-			 */
-			return -EOPNOTSUPP;
+			mfn = PFN_DOWN(map_ops[i].dev_bus_addr);
 		}
-		ret = m2p_add_override(mfn, pages[i], &kmap_ops[i]);
+		ret = m2p_add_override(mfn, pages[i], kmap_ops ? &kmap_ops[i] : NULL);
 		if (ret)
 			return ret;
 	}
@@ -499,7 +484,7 @@ int gnttab_map_refs(struct gnttab_map_grant_ref *map_ops,
 EXPORT_SYMBOL_GPL(gnttab_map_refs);
 
 int gnttab_unmap_refs(struct gnttab_unmap_grant_ref *unmap_ops,
-		struct page **pages, unsigned int count)
+		struct page **pages, unsigned int count, bool clear_pte)
 {
 	int i, ret;
 
@@ -511,7 +496,7 @@ int gnttab_unmap_refs(struct gnttab_unmap_grant_ref *unmap_ops,
 		return ret;
 
 	for (i = 0; i < count; i++) {
-		ret = m2p_remove_override(pages[i], true /* clear the PTE */);
+		ret = m2p_remove_override(pages[i], clear_pte);
 		if (ret)
 			return ret;
 	}
diff --git a/include/xen/grant_table.h b/include/xen/grant_table.h
index 11e2dfc..37da54d 100644
--- a/include/xen/grant_table.h
+++ b/include/xen/grant_table.h
@@ -158,6 +158,6 @@ int gnttab_map_refs(struct gnttab_map_grant_ref *map_ops,
 			struct gnttab_map_grant_ref *kmap_ops,
 		    struct page **pages, unsigned int count);
 int gnttab_unmap_refs(struct gnttab_unmap_grant_ref *unmap_ops,
-		      struct page **pages, unsigned int count);
+		      struct page **pages, unsigned int count, bool clear_pte);
 
 #endif /* __ASM_GNTTAB_H__ */
-- 
1.7.7.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 20:13:27 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 20:13:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RavCQ-0000hz-MS; Wed, 14 Dec 2011 20:13:10 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RavCN-0000gx-Sa
	for Xen-devel@lists.xensource.com; Wed, 14 Dec 2011 20:13:08 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-13.tower-216.messagelabs.com!1323893531!6893614!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26150 invoked from network); 14 Dec 2011 20:12:11 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-13.tower-216.messagelabs.com with SMTP;
	14 Dec 2011 20:12:11 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea01.nsa.gov (8.12.10/8.12.10) with ESMTP id
	pBEKCALN002960; Wed, 14 Dec 2011 20:12:10 GMT
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id pBEKC9Mp010588; 
	Wed, 14 Dec 2011 15:12:09 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: konrad.wilk@oracle.com
Date: Wed, 14 Dec 2011 15:12:10 -0500
Message-Id: <1323893534-436-3-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.4
In-Reply-To: <1323893534-436-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1323893534-436-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>, Xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 2/6] xenbus: Use grant-table wrapper functions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

For xenbus_{map,unmap}_ring to work on HVM, the grant table operations
must be set up using the gnttab_set_{map,unmap}_op functions instead of
directly populating the fields of gnttab_map_grant_ref. These functions
simply populate the structure on paravirtualized Xen; however, on HVM
they must call __pa() on vaddr when populating op->host_addr because the
hypervisor cannot directly interpret guest-virtual addresses.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 drivers/xen/xenbus/xenbus_client.c |   17 +++++++----------
 1 files changed, 7 insertions(+), 10 deletions(-)

diff --git a/drivers/xen/xenbus/xenbus_client.c b/drivers/xen/xenbus/xenbus_client.c
index ecd695d..8a23f1a 100644
--- a/drivers/xen/xenbus/xenbus_client.c
+++ b/drivers/xen/xenbus/xenbus_client.c
@@ -545,12 +545,10 @@ EXPORT_SYMBOL_GPL(xenbus_map_ring_valloc);
 int xenbus_map_ring(struct xenbus_device *dev, int gnt_ref,
 		    grant_handle_t *handle, void *vaddr)
 {
-	struct gnttab_map_grant_ref op = {
-		.host_addr = (unsigned long)vaddr,
-		.flags     = GNTMAP_host_map,
-		.ref       = gnt_ref,
-		.dom       = dev->otherend_id,
-	};
+	struct gnttab_map_grant_ref op;
+
+	gnttab_set_map_op(&op, (phys_addr_t)vaddr, GNTMAP_host_map, gnt_ref,
+	                  dev->otherend_id);
 
 	if (HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, &op, 1))
 		BUG();
@@ -677,10 +675,9 @@ EXPORT_SYMBOL_GPL(xenbus_unmap_ring_vfree);
 int xenbus_unmap_ring(struct xenbus_device *dev,
 		      grant_handle_t handle, void *vaddr)
 {
-	struct gnttab_unmap_grant_ref op = {
-		.host_addr = (unsigned long)vaddr,
-		.handle    = handle,
-	};
+	struct gnttab_unmap_grant_ref op;
+
+	gnttab_set_unmap_op(&op, (phys_addr_t)vaddr, GNTMAP_host_map, handle);
 
 	if (HYPERVISOR_grant_table_op(GNTTABOP_unmap_grant_ref, &op, 1))
 		BUG();
-- 
1.7.7.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 20:25:10 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 20:25:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RavNo-0002SV-0P; Wed, 14 Dec 2011 20:24:56 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1RavNm-0002SB-Tj
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 20:24:55 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-11.tower-27.messagelabs.com!1323894220!49316837!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3238 invoked from network); 14 Dec 2011 20:23:42 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-11.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Dec 2011 20:23:42 -0000
Received: from andromeda.dapyr.net (darnok@localhost [127.0.0.1])
	by andromeda.dapyr.net (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id
	pBEKNqRx025980
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Wed, 14 Dec 2011 15:23:52 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pBEKNpFO025978;
	Wed, 14 Dec 2011 15:23:51 -0500
Date: Wed, 14 Dec 2011 16:23:51 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <20111214202351.GA25896@andromeda.dapyr.net>
References: <zarafa.4ece387c.6e85.6aa0c9ca21e63bd9@uhura.space.zz>
	<zarafa.4edb62f8.6417.1a54a5c25b8f0fd7@uhura.space.zz>
	<20111206032621.GA6568@phenom.dumpdata.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20111206032621.GA6568@phenom.dumpdata.com>
User-Agent: Mutt/1.5.9i
Cc: "lersek@redhat.com" <lersek@redhat.com>,
	xen-devel <xen-devel@lists.xensource.com>,
	Carsten Schiers <carsten@schiers.de>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"zhenzhong.duan@oracle.com" <zhenzhong.duan@oracle.com>
Subject: Re: [Xen-devel] Load increase after memory upgrade (part2)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Dec 05, 2011 at 10:26:21PM -0500, Konrad Rzeszutek Wilk wrote:
> On Sun, Dec 04, 2011 at 01:09:28PM +0100, Carsten Schiers wrote:
> > Here with two cards enabled and creating a bit "work" by watching TV with one oft hem:
> > 
> > [   23.842720] Starting SWIOTLB debug thread.
> > [   23.842750] swiotlb_start_thread: Go!
> > [   23.842838] xen_swiotlb_start_thread: Go!
> > [   28.841451] 0 [budget_av 0000:00:01.0] bounce: from:435596(slow:0)to:0 map:658 unmap:0 sync:435596
> > [   28.841592] SWIOTLB is 4% full
> > [   33.840147] 0 [budget_av 0000:00:01.0] bounce: from:127652(slow:0)to:0 map:0 unmap:0 sync:127652
> > [   33.840283] SWIOTLB is 4% full
> > [   33.844222] 0 budget_av 0000:00:01.0 alloc coherent: 8, free: 0
> > [   38.840227] 0 [budget_av 0000:00:01.0] bounce: from:128310(slow:0)to:0 map:0 unmap:0 sync:128310
> 
> Whoa. Yes. You are definitly using the bounce buffer :-)
> 
> Now it is time to look at why the drive is not using those coherent ones - it
> looks to allocate just eight of them but does not use them.. Unless it is
> using them _and_ bouncing them (which would be odd).
> 
> And BTW, you can lower your 'swiotlb=XX' value.  The 4% is how much you
> are using of the default size.

So I able to see this with an atl1c ethernet driver on my SandyBridge i3
box. It looks as if the card is truly 32-bit so on a box with 8GB it
bounces the data. If I booted the Xen hypervisor with 'mem=4GB' I get no
bounces (no surprise there).

In other words - I see the same behavior you are seeing. Now off to:
> 
> I should find out_why_ the old Xen kernels do not use the bounce buffer
> so much...

which will require some fiddling around.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 20:25:10 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 20:25:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RavNo-0002SV-0P; Wed, 14 Dec 2011 20:24:56 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1RavNm-0002SB-Tj
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 20:24:55 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-11.tower-27.messagelabs.com!1323894220!49316837!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3238 invoked from network); 14 Dec 2011 20:23:42 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-11.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Dec 2011 20:23:42 -0000
Received: from andromeda.dapyr.net (darnok@localhost [127.0.0.1])
	by andromeda.dapyr.net (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id
	pBEKNqRx025980
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Wed, 14 Dec 2011 15:23:52 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pBEKNpFO025978;
	Wed, 14 Dec 2011 15:23:51 -0500
Date: Wed, 14 Dec 2011 16:23:51 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <20111214202351.GA25896@andromeda.dapyr.net>
References: <zarafa.4ece387c.6e85.6aa0c9ca21e63bd9@uhura.space.zz>
	<zarafa.4edb62f8.6417.1a54a5c25b8f0fd7@uhura.space.zz>
	<20111206032621.GA6568@phenom.dumpdata.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20111206032621.GA6568@phenom.dumpdata.com>
User-Agent: Mutt/1.5.9i
Cc: "lersek@redhat.com" <lersek@redhat.com>,
	xen-devel <xen-devel@lists.xensource.com>,
	Carsten Schiers <carsten@schiers.de>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"zhenzhong.duan@oracle.com" <zhenzhong.duan@oracle.com>
Subject: Re: [Xen-devel] Load increase after memory upgrade (part2)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Dec 05, 2011 at 10:26:21PM -0500, Konrad Rzeszutek Wilk wrote:
> On Sun, Dec 04, 2011 at 01:09:28PM +0100, Carsten Schiers wrote:
> > Here with two cards enabled and creating a bit "work" by watching TV with one oft hem:
> > 
> > [   23.842720] Starting SWIOTLB debug thread.
> > [   23.842750] swiotlb_start_thread: Go!
> > [   23.842838] xen_swiotlb_start_thread: Go!
> > [   28.841451] 0 [budget_av 0000:00:01.0] bounce: from:435596(slow:0)to:0 map:658 unmap:0 sync:435596
> > [   28.841592] SWIOTLB is 4% full
> > [   33.840147] 0 [budget_av 0000:00:01.0] bounce: from:127652(slow:0)to:0 map:0 unmap:0 sync:127652
> > [   33.840283] SWIOTLB is 4% full
> > [   33.844222] 0 budget_av 0000:00:01.0 alloc coherent: 8, free: 0
> > [   38.840227] 0 [budget_av 0000:00:01.0] bounce: from:128310(slow:0)to:0 map:0 unmap:0 sync:128310
> 
> Whoa. Yes. You are definitly using the bounce buffer :-)
> 
> Now it is time to look at why the drive is not using those coherent ones - it
> looks to allocate just eight of them but does not use them.. Unless it is
> using them _and_ bouncing them (which would be odd).
> 
> And BTW, you can lower your 'swiotlb=XX' value.  The 4% is how much you
> are using of the default size.

So I able to see this with an atl1c ethernet driver on my SandyBridge i3
box. It looks as if the card is truly 32-bit so on a box with 8GB it
bounces the data. If I booted the Xen hypervisor with 'mem=4GB' I get no
bounces (no surprise there).

In other words - I see the same behavior you are seeing. Now off to:
> 
> I should find out_why_ the old Xen kernels do not use the bounce buffer
> so much...

which will require some fiddling around.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 21:08:56 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 21: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.xensource.com>)
	id 1Raw41-0003iL-DE; Wed, 14 Dec 2011 21:08:33 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <quartex73@gmail.com>) id 1Raw3z-0003iF-Gu
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 21:08:31 +0000
X-Env-Sender: quartex73@gmail.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1323896853!5412389!1
X-Originating-IP: [209.85.160.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22666 invoked from network); 14 Dec 2011 21:07:34 -0000
Received: from mail-gy0-f171.google.com (HELO mail-gy0-f171.google.com)
	(209.85.160.171)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Dec 2011 21:07:34 -0000
Received: by ghrr17 with SMTP id r17so15352872ghr.30
	for <xen-devel@lists.xensource.com>;
	Wed, 14 Dec 2011 13:07:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=nVISxXdjjy9nNlt50/Gl5RnhC/r9PDfj/JhK6F+OwfY=;
	b=guLGVi8aPSBXNpDNVTIh7OB84tqDtzQeQYPd+9YBVEkRprRIqIqSPqlVkPuFG1j/q5
	74WxvCyAiebyzmMZtjwZdmQLQG1CmU1OaCbTztbeAsZuGs84RivLed6CCkvGSuWWEhPQ
	jcJoOgEQLa5LlkfsqrzyWGCKik6RKx+7mFVIw=
MIME-Version: 1.0
Received: by 10.236.176.2 with SMTP id a2mr772138yhm.12.1323896736915; Wed, 14
	Dec 2011 13:05:36 -0800 (PST)
Received: by 10.146.58.7 with HTTP; Wed, 14 Dec 2011 13:05:36 -0800 (PST)
In-Reply-To: <20111214194029.GB17432@andromeda.dapyr.net>
References: <CAMhBqqiLc1994GUKtA7UY52pR29nktmFy+XiwTwpZb_E+fwFRQ@mail.gmail.com>
	<CAMhBqqgu6v8NB-X0dNdfrzd12=Y2i==fYCCC2Z+MkDupqqKAOg@mail.gmail.com>
	<20111202195727.GA18758@andromeda.dapyr.net>
	<CAMhBqqgJ0Q3BZDuK3KEEGuDS2eGBZq89E7_Kbv+VNTYxZJLAAA@mail.gmail.com>
	<20111214194029.GB17432@andromeda.dapyr.net>
Date: Wed, 14 Dec 2011 22:05:36 +0100
Message-ID: <CAMhBqqj-3cjgiQsahL8BJHyJbCfYu+8dQx546XLf8Ht+6LiF0w@mail.gmail.com>
From: Quartexx <quartex73@gmail.com>
To: xen-devel@lists.xensource.com
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>
Subject: Re: [Xen-devel] xen 4.0.1 w/2.6.32.47 hangs at boot
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

2011/12/14 Konrad Rzeszutek Wilk <konrad@darnok.org>:
> I would hazzard a guess that it is something with the 3ware driver.
> Can you configure Alt-SysRq so that you can see the stack trace of
> dom0 and where it hanged? And also do Ctrl-Ax3 and press 'q' to see
> where dom0 is stuck? It should print out a bunch of 0xff.. and I can
> help you debug what that is in the dom0 kernel so we can figure out
> what is happening.


Thanks, I would try that as soon as possible (unfortunately this box
is in a remote datacenter)
Googling I found this
https://bugzilla.redhat.com/show_bug.cgi?id=429937
They suggest to rebuild initrd including scsi_wait_scan module.
Another workaround could be to use rootdelay in the kernel command line
Worth a try or a waste of time?


> Or you can also try the latest kernel - 3.0.x and see if the problem
> appears there as well - which is much easier for us to fix and has
> some other important fixes that won't be back-ported to 2.6.32.

Since I'm using blktap2 I'm concerned about upgrading to 3.0.x.  I
have read bad feedback about blktap-dkms.  Are my concerns unfounded?
 Are there any alternative to blktap2 (excluding LVM)?
Thanks

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 21:08:56 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 21: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.xensource.com>)
	id 1Raw41-0003iL-DE; Wed, 14 Dec 2011 21:08:33 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <quartex73@gmail.com>) id 1Raw3z-0003iF-Gu
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 21:08:31 +0000
X-Env-Sender: quartex73@gmail.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1323896853!5412389!1
X-Originating-IP: [209.85.160.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22666 invoked from network); 14 Dec 2011 21:07:34 -0000
Received: from mail-gy0-f171.google.com (HELO mail-gy0-f171.google.com)
	(209.85.160.171)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Dec 2011 21:07:34 -0000
Received: by ghrr17 with SMTP id r17so15352872ghr.30
	for <xen-devel@lists.xensource.com>;
	Wed, 14 Dec 2011 13:07:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=nVISxXdjjy9nNlt50/Gl5RnhC/r9PDfj/JhK6F+OwfY=;
	b=guLGVi8aPSBXNpDNVTIh7OB84tqDtzQeQYPd+9YBVEkRprRIqIqSPqlVkPuFG1j/q5
	74WxvCyAiebyzmMZtjwZdmQLQG1CmU1OaCbTztbeAsZuGs84RivLed6CCkvGSuWWEhPQ
	jcJoOgEQLa5LlkfsqrzyWGCKik6RKx+7mFVIw=
MIME-Version: 1.0
Received: by 10.236.176.2 with SMTP id a2mr772138yhm.12.1323896736915; Wed, 14
	Dec 2011 13:05:36 -0800 (PST)
Received: by 10.146.58.7 with HTTP; Wed, 14 Dec 2011 13:05:36 -0800 (PST)
In-Reply-To: <20111214194029.GB17432@andromeda.dapyr.net>
References: <CAMhBqqiLc1994GUKtA7UY52pR29nktmFy+XiwTwpZb_E+fwFRQ@mail.gmail.com>
	<CAMhBqqgu6v8NB-X0dNdfrzd12=Y2i==fYCCC2Z+MkDupqqKAOg@mail.gmail.com>
	<20111202195727.GA18758@andromeda.dapyr.net>
	<CAMhBqqgJ0Q3BZDuK3KEEGuDS2eGBZq89E7_Kbv+VNTYxZJLAAA@mail.gmail.com>
	<20111214194029.GB17432@andromeda.dapyr.net>
Date: Wed, 14 Dec 2011 22:05:36 +0100
Message-ID: <CAMhBqqj-3cjgiQsahL8BJHyJbCfYu+8dQx546XLf8Ht+6LiF0w@mail.gmail.com>
From: Quartexx <quartex73@gmail.com>
To: xen-devel@lists.xensource.com
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>
Subject: Re: [Xen-devel] xen 4.0.1 w/2.6.32.47 hangs at boot
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

2011/12/14 Konrad Rzeszutek Wilk <konrad@darnok.org>:
> I would hazzard a guess that it is something with the 3ware driver.
> Can you configure Alt-SysRq so that you can see the stack trace of
> dom0 and where it hanged? And also do Ctrl-Ax3 and press 'q' to see
> where dom0 is stuck? It should print out a bunch of 0xff.. and I can
> help you debug what that is in the dom0 kernel so we can figure out
> what is happening.


Thanks, I would try that as soon as possible (unfortunately this box
is in a remote datacenter)
Googling I found this
https://bugzilla.redhat.com/show_bug.cgi?id=429937
They suggest to rebuild initrd including scsi_wait_scan module.
Another workaround could be to use rootdelay in the kernel command line
Worth a try or a waste of time?


> Or you can also try the latest kernel - 3.0.x and see if the problem
> appears there as well - which is much easier for us to fix and has
> some other important fixes that won't be back-ported to 2.6.32.

Since I'm using blktap2 I'm concerned about upgrading to 3.0.x.  I
have read bad feedback about blktap-dkms.  Are my concerns unfounded?
 Are there any alternative to blktap2 (excluding LVM)?
Thanks

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 21:32:23 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 21:32:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RawQa-0004OZ-PG; Wed, 14 Dec 2011 21:31:52 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1RawQY-0004OA-H8
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 21:31:50 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-6.tower-21.messagelabs.com!1323898252!8095704!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13944 invoked from network); 14 Dec 2011 21:30:54 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-6.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Dec 2011 21:30:54 -0000
Received: from andromeda.dapyr.net (darnok@localhost [127.0.0.1])
	by andromeda.dapyr.net (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id
	pBELUnXo031501
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Wed, 14 Dec 2011 16:30:49 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pBELUnGW031499;
	Wed, 14 Dec 2011 16:30:49 -0500
Date: Wed, 14 Dec 2011 17:30:49 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: DcMichael <dcmichael1256@gmail.com>
Message-ID: <20111214213049.GB25896@andromeda.dapyr.net>
References: <1323282732.2750.6.camel@dcmichael-pc>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1323282732.2750.6.camel@dcmichael-pc>
User-Agent: Mutt/1.5.9i
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] How to share memory with kernel and hypervisor?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Dec 08, 2011 at 03:32:12AM +0900, DcMichael wrote:
> Hi!
> I'm first in here.
> anyway I want to make kernel and hypervisor share there memory.
> which the kernal write memory, then hypervisor can read it.
> without any function like copy_from_user.
> 
> I'll use this memory very many time, so I want share memory like shmget.
> but using ring use push function every time.

Why would you want to do this? Maybe a better question is - what
is your goal.
> 
> can I share memory like this way?

Sure.. You would have to setup the hypervisor to have a pagetable entry
for the physical page.
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 21:32:23 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 21:32:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RawQa-0004OZ-PG; Wed, 14 Dec 2011 21:31:52 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1RawQY-0004OA-H8
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 21:31:50 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-6.tower-21.messagelabs.com!1323898252!8095704!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13944 invoked from network); 14 Dec 2011 21:30:54 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-6.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Dec 2011 21:30:54 -0000
Received: from andromeda.dapyr.net (darnok@localhost [127.0.0.1])
	by andromeda.dapyr.net (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id
	pBELUnXo031501
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Wed, 14 Dec 2011 16:30:49 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pBELUnGW031499;
	Wed, 14 Dec 2011 16:30:49 -0500
Date: Wed, 14 Dec 2011 17:30:49 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: DcMichael <dcmichael1256@gmail.com>
Message-ID: <20111214213049.GB25896@andromeda.dapyr.net>
References: <1323282732.2750.6.camel@dcmichael-pc>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1323282732.2750.6.camel@dcmichael-pc>
User-Agent: Mutt/1.5.9i
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] How to share memory with kernel and hypervisor?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Dec 08, 2011 at 03:32:12AM +0900, DcMichael wrote:
> Hi!
> I'm first in here.
> anyway I want to make kernel and hypervisor share there memory.
> which the kernal write memory, then hypervisor can read it.
> without any function like copy_from_user.
> 
> I'll use this memory very many time, so I want share memory like shmget.
> but using ring use push function every time.

Why would you want to do this? Maybe a better question is - what
is your goal.
> 
> can I share memory like this way?

Sure.. You would have to setup the hypervisor to have a pagetable entry
for the physical page.
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 21:36:20 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 21:36:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RawUV-0004YQ-KR; Wed, 14 Dec 2011 21:35:55 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1RawUU-0004Y9-BQ
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 21:35:54 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-10.tower-216.messagelabs.com!1323898496!7391587!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25817 invoked from network); 14 Dec 2011 21:34:58 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-10.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Dec 2011 21:34:58 -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
	pBELYhhk031866
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Wed, 14 Dec 2011 16:34:43 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pBELYhHR031864;
	Wed, 14 Dec 2011 16:34:43 -0500
Date: Wed, 14 Dec 2011 17:34:43 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20111214213443.GC25896@andromeda.dapyr.net>
References: <4EDFDF0D.2020104@hp.com>
	<4EE628D80200007800066F9E@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4EE628D80200007800066F9E@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.9i
Cc: xen-devel@lists.xensource.com, dbrace <dab@hp.com>
Subject: Re: [Xen-devel] kmap_atomic issue with SLES11SP1 32bit XEN driver
	code
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Dec 12, 2011 at 03:16:24PM +0000, Jan Beulich wrote:
> >>> On 07.12.11 at 22:47, dbrace <dab@hp.com> wrote:
> > kernel: Linux 360 2.6.32.12-0.7-xen #1 SMP 2010-05-20 11:14:20 +0200 
> > i686 i686 i386 GNU/Linux
> 
> Pretty outdated.
> 
> > I am having issues with some code that uses kmap_atomic(). I am getting:
> > 
> > BUG: unable to handle kernel paging request at 23a1a000 (which is the 
> > address returned from kmap_atomic().)
> 
> For a valid high memory page this is surely not being returned by
> kmap_atomic(), so we have to assume that what you started with is
> the address of a low memory one.
> 
> > The same code works when running on non-XEN 32bit kernels so I am  
> > wondering why this does not work under
> > XEN kernels. Is there a different approach that I need to take for 32bit 
> > XEN kernels?
> 
> No, but ...
> 
> > I really only need to do this code segment if the memory address is a 
> > high memory address. Is there a MACRO or function
> > that can help me determine this?
> 
> PageHighMem().
> 
> > Here is a code snippet:
> > 
> >                  void *linux_vaddr = NULL;       /* kmapped temporary 
> > virtual address */
> >                  int linux_page_offset = 0;      /* offset in page */
> >                  int count = 0;                  /* bytes left to 
> > transfer */
> >                  int left = byte_count;          /* number of bytes left 
> > to transfer */
> >                  int memcpysize = 0;             /* current size to 
> > transfer */
> >                  struct page *linux_page = NULL; /* calculated page */
> >                  int kmap_flags = 0;
> > 
> >                  linux_page = __pfn_to_page(physical_address >> PAGE_SHIFT);
> 
> ... without knowing where you got physical_address from it's impossible
> to tell whether your problem is that under Xen physical and machine
> (sometimes called "bus") addresses being distinct (end hence you're
> possibly lacking a translation between the two).

I don't know much about the SLES kernels, but if it uses lazy page
updating it might be hitting:

2cd1c8d x86/paravirt: PTE updates in k(un)map_atomic need to be
synchronous, regardless of lazy_mmu mode

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 21:36:20 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 21:36:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RawUV-0004YQ-KR; Wed, 14 Dec 2011 21:35:55 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1RawUU-0004Y9-BQ
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 21:35:54 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-10.tower-216.messagelabs.com!1323898496!7391587!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25817 invoked from network); 14 Dec 2011 21:34:58 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-10.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Dec 2011 21:34:58 -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
	pBELYhhk031866
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Wed, 14 Dec 2011 16:34:43 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pBELYhHR031864;
	Wed, 14 Dec 2011 16:34:43 -0500
Date: Wed, 14 Dec 2011 17:34:43 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20111214213443.GC25896@andromeda.dapyr.net>
References: <4EDFDF0D.2020104@hp.com>
	<4EE628D80200007800066F9E@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4EE628D80200007800066F9E@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.9i
Cc: xen-devel@lists.xensource.com, dbrace <dab@hp.com>
Subject: Re: [Xen-devel] kmap_atomic issue with SLES11SP1 32bit XEN driver
	code
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Dec 12, 2011 at 03:16:24PM +0000, Jan Beulich wrote:
> >>> On 07.12.11 at 22:47, dbrace <dab@hp.com> wrote:
> > kernel: Linux 360 2.6.32.12-0.7-xen #1 SMP 2010-05-20 11:14:20 +0200 
> > i686 i686 i386 GNU/Linux
> 
> Pretty outdated.
> 
> > I am having issues with some code that uses kmap_atomic(). I am getting:
> > 
> > BUG: unable to handle kernel paging request at 23a1a000 (which is the 
> > address returned from kmap_atomic().)
> 
> For a valid high memory page this is surely not being returned by
> kmap_atomic(), so we have to assume that what you started with is
> the address of a low memory one.
> 
> > The same code works when running on non-XEN 32bit kernels so I am  
> > wondering why this does not work under
> > XEN kernels. Is there a different approach that I need to take for 32bit 
> > XEN kernels?
> 
> No, but ...
> 
> > I really only need to do this code segment if the memory address is a 
> > high memory address. Is there a MACRO or function
> > that can help me determine this?
> 
> PageHighMem().
> 
> > Here is a code snippet:
> > 
> >                  void *linux_vaddr = NULL;       /* kmapped temporary 
> > virtual address */
> >                  int linux_page_offset = 0;      /* offset in page */
> >                  int count = 0;                  /* bytes left to 
> > transfer */
> >                  int left = byte_count;          /* number of bytes left 
> > to transfer */
> >                  int memcpysize = 0;             /* current size to 
> > transfer */
> >                  struct page *linux_page = NULL; /* calculated page */
> >                  int kmap_flags = 0;
> > 
> >                  linux_page = __pfn_to_page(physical_address >> PAGE_SHIFT);
> 
> ... without knowing where you got physical_address from it's impossible
> to tell whether your problem is that under Xen physical and machine
> (sometimes called "bus") addresses being distinct (end hence you're
> possibly lacking a translation between the two).

I don't know much about the SLES kernels, but if it uses lazy page
updating it might be hitting:

2cd1c8d x86/paravirt: PTE updates in k(un)map_atomic need to be
synchronous, regardless of lazy_mmu mode

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 21:39:34 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 21:39:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RawXi-0004of-8F; Wed, 14 Dec 2011 21:39:14 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1RawXh-0004oW-60
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 21:39:13 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-8.tower-27.messagelabs.com!1323898590!56198836!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18859 invoked from network); 14 Dec 2011 21:36:32 -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; 14 Dec 2011 21:36:32 -0000
Received: from andromeda.dapyr.net (darnok@localhost [127.0.0.1])
	by andromeda.dapyr.net (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id
	pBELcKY6032041
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Wed, 14 Dec 2011 16:38:20 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pBELcKr2032039;
	Wed, 14 Dec 2011 16:38:20 -0500
Date: Wed, 14 Dec 2011 17:38:19 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Anthony Wright <anthony@overnetdata.com>
Message-ID: <20111214213819.GD25896@andromeda.dapyr.net>
References: <4EE0A6C7.9080603@overnetdata.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4EE0A6C7.9080603@overnetdata.com>
User-Agent: Mutt/1.5.9i
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] VGA Passthrough crashes machine
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Dec 08, 2011 at 12:00:07PM +0000, Anthony Wright wrote:
> I've just had my first attempt at getting VGA passthrough to work, and
> it crashed the machine. I'm trying to understand whether this is a
> problem with my hardware, configuration or a software problem.
> 
> I'm running Xen 4.1.2 with Linux 3.1.2
> 
> 
> The CPU is an Intel Core i5-650
> http://ark.intel.com/products/43546/Intel-Core-i5-650-Processor-%284M-Cache-3_20-GHz%29

And what is your motherboard? Does it have VT-d?

> 
> The Video Card is and Intel Core Processor Integrated Graphics Controller
> PCI ID: 8086 0042
> 
> 
> I have hidden the vga device with xen-pciback.hide=(00:02.0) on the
> kernel command line
> 
> The xen config file is:
> name        = '11-1'
> kernel            = '/usr/lib/xen/boot/hvmloader'
> builder           = 'hvm'
> device_model      = '/usr/lib/xen/bin/qemu-dm'
> boot              = 'c'
> serial            = 'pty'
> usbdevice         = 'tablet'
> disk        = [ 'phy:/dev/Master/Root-11-0001,hda,w' ]
> memory      = 1000
> vif         = [
> 'bridge=br-internal,mac=04:fb:7a:22:e8:4a','bridge=br-dmz,mac=04:fb:7a:22:e8:4b','bridge=br-local,mac=04:fb:7a:22:e8:4c'
> ]
> vcpus       = 1
> on_poweroff = 'destroy'
> on_reboot   = 'destroy'
> on_crash    = 'destroy'
> 
> gfx_passthru=1
> pci=['00:02.0']
> 
> When I try to start the DomU I get the following output, I get the
> prompt back and then the system reboots.
> 
> Parsing config file xen-config
> xc: info: VIRTUAL MEMORY ARRANGEMENT:
>   Loader:        0000000000100000->00000000001795d0
>   TOTAL:         0000000000000000->000000003e000000
>   ENTRY ADDRESS: 0000000000100000
> xc: info: PHYSICAL MEMORY ALLOCATION:
>   4KB PAGES: 0x0000000000000200
>   2MB PAGES: 0x00000000000001ef
>   1GB PAGES: 0x0000000000000000
> libxl: error: libxl_pci.c:712:do_pci_add xc_assign_device failed
> Daemon running with PID 2050
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 21:39:34 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 21:39:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RawXi-0004of-8F; Wed, 14 Dec 2011 21:39:14 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1RawXh-0004oW-60
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 21:39:13 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-8.tower-27.messagelabs.com!1323898590!56198836!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18859 invoked from network); 14 Dec 2011 21:36:32 -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; 14 Dec 2011 21:36:32 -0000
Received: from andromeda.dapyr.net (darnok@localhost [127.0.0.1])
	by andromeda.dapyr.net (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id
	pBELcKY6032041
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Wed, 14 Dec 2011 16:38:20 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pBELcKr2032039;
	Wed, 14 Dec 2011 16:38:20 -0500
Date: Wed, 14 Dec 2011 17:38:19 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Anthony Wright <anthony@overnetdata.com>
Message-ID: <20111214213819.GD25896@andromeda.dapyr.net>
References: <4EE0A6C7.9080603@overnetdata.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4EE0A6C7.9080603@overnetdata.com>
User-Agent: Mutt/1.5.9i
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] VGA Passthrough crashes machine
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Dec 08, 2011 at 12:00:07PM +0000, Anthony Wright wrote:
> I've just had my first attempt at getting VGA passthrough to work, and
> it crashed the machine. I'm trying to understand whether this is a
> problem with my hardware, configuration or a software problem.
> 
> I'm running Xen 4.1.2 with Linux 3.1.2
> 
> 
> The CPU is an Intel Core i5-650
> http://ark.intel.com/products/43546/Intel-Core-i5-650-Processor-%284M-Cache-3_20-GHz%29

And what is your motherboard? Does it have VT-d?

> 
> The Video Card is and Intel Core Processor Integrated Graphics Controller
> PCI ID: 8086 0042
> 
> 
> I have hidden the vga device with xen-pciback.hide=(00:02.0) on the
> kernel command line
> 
> The xen config file is:
> name        = '11-1'
> kernel            = '/usr/lib/xen/boot/hvmloader'
> builder           = 'hvm'
> device_model      = '/usr/lib/xen/bin/qemu-dm'
> boot              = 'c'
> serial            = 'pty'
> usbdevice         = 'tablet'
> disk        = [ 'phy:/dev/Master/Root-11-0001,hda,w' ]
> memory      = 1000
> vif         = [
> 'bridge=br-internal,mac=04:fb:7a:22:e8:4a','bridge=br-dmz,mac=04:fb:7a:22:e8:4b','bridge=br-local,mac=04:fb:7a:22:e8:4c'
> ]
> vcpus       = 1
> on_poweroff = 'destroy'
> on_reboot   = 'destroy'
> on_crash    = 'destroy'
> 
> gfx_passthru=1
> pci=['00:02.0']
> 
> When I try to start the DomU I get the following output, I get the
> prompt back and then the system reboots.
> 
> Parsing config file xen-config
> xc: info: VIRTUAL MEMORY ARRANGEMENT:
>   Loader:        0000000000100000->00000000001795d0
>   TOTAL:         0000000000000000->000000003e000000
>   ENTRY ADDRESS: 0000000000100000
> xc: info: PHYSICAL MEMORY ALLOCATION:
>   4KB PAGES: 0x0000000000000200
>   2MB PAGES: 0x00000000000001ef
>   1GB PAGES: 0x0000000000000000
> libxl: error: libxl_pci.c:712:do_pci_add xc_assign_device failed
> Daemon running with PID 2050
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 21:55:02 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 21:55:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rawmc-000598-Po; Wed, 14 Dec 2011 21:54:38 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1Rawmb-000593-OB
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 21:54:37 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-10.tower-216.messagelabs.com!1323899619!7392867!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28942 invoked from network); 14 Dec 2011 21:53:41 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-10.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Dec 2011 21:53:41 -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
	pBELrcWv032698
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Wed, 14 Dec 2011 16:53:38 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pBELrc5M032696;
	Wed, 14 Dec 2011 16:53:38 -0500
Date: Wed, 14 Dec 2011 17:53:37 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Message-ID: <20111214215337.GE25896@andromeda.dapyr.net>
References: <4EE0CC19.8040905@tycho.nsa.gov>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4EE0CC19.8040905@tycho.nsa.gov>
User-Agent: Mutt/1.5.9i
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] memory map issues with PV PCI passthrough
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Dec 08, 2011 at 09:39:21AM -0500, Daniel De Graaf wrote:
> I have a system with several reserved ranges low in the e820 map which
> cause problems when starting PV domains with PCI devices. The machine
> memory map looks like:
> 
> (XEN)  0000000000000000 - 0000000000060000 (usable)
> (XEN)  0000000000060000 - 0000000000068000 (reserved)
> (XEN)  0000000000068000 - 000000000009ac00 (usable)
> (XEN)  000000000009ac00 - 00000000000a0000 (reserved)
> (XEN)  00000000000e0000 - 0000000000100000 (reserved)
> (XEN)  0000000000100000 - 0000000000800000 (usable)
> (XEN)  0000000000800000 - 000000000087d000 (unusable)
> (XEN)  000000000087d000 - 0000000000f00000 (usable)
> (XEN)  0000000000f00000 - 0000000001000000 (reserved)
> (XEN)  0000000001000000 - 0000000020000000 (usable)
> (XEN)  0000000020000000 - 0000000020200000 (reserved)
> (XEN)  0000000020200000 - 0000000040000000 (usable)
> (XEN)  0000000040000000 - 0000000040200000 (reserved)
> (XEN)  0000000040200000 - 00000000c95d6000 (usable)
> (XEN)  00000000c95d6000 - 00000000c961a000 (reserved)
> (XEN)  00000000c961a000 - 00000000c99b7000 (usable)
> (XEN)  00000000c99b7000 - 00000000c99e7000 (reserved)
> (XEN)  00000000c99e7000 - 00000000c9be7000 (ACPI NVS)
> (XEN)  00000000c9be7000 - 00000000c9bff000 (ACPI data)
> (XEN)  00000000c9bff000 - 00000000c9c00000 (usable)
> (XEN)  00000000c9f00000 - 00000000ca000000 (reserved)
> (XEN)  00000000cb000000 - 00000000cf200000 (reserved)
> (XEN)  00000000fed1c000 - 00000000fed30000 (reserved)
> (XEN)  00000000ffc00000 - 00000000ffc20000 (reserved)
> (XEN)  0000000100000000 - 000000042e000000 (usable)
> 
> When e820_sanitize is called on this memory map to create a PV domain, the
> resulting map has only one usable region (0-0xf00000) below 4GB, and Linux
> will not boot with this memory map.

OK, that looks like a bug. WE could modify e820_santizie in the libxl
to use the hosts E820 and fill in the (usuable) regions with the memory
that is allocated for it. Instead of allocating a big chunk at the start
and then working out the other regions.

> 
> I have a patch that reworks e820_sanitize to include later RAM regions as
> valid RAM, which works as long as the domain being booted has permission
> to map the PFNs from 0x20000-0x20200 and 0x40000-0x40200. If the domain is
> not given this permission (the default, since these regions are not part of
> the PCI device being passed to the guest) then the hypervisor crashes the
> domain when it attempts to map these regions (during init_memory_mapping).

Hmm, so it tries to map (reserved) regions? That seems rather odd.
I am pretty sure it worked for me. What Linux kernel did you use and
can you send the guest config file as well please?
> 
> The domain will boot when these regions are not marked as reserved in the
> e820 map or when the PFNs 0x20200-0x40000 and 0x40200-0xc95d6 are marked
> as unusable. However, it is difficult to make this happen in any general
> case without knowing what reserved regions actually need to be marked as
> reserved in the guest.
> 
> If PCI hot-add is not needed, the problem becomes simpler: the PCI regions
> for assigned devices can be included in the e820 map and other regions can
> be ignored (marking as RAM so that the guest does not attempt direct map).
> 
> Any suggestions on the best way to resolve this?

I think reworking the e820_allocate to just use the E820 from the host
and just convert the RAM regions that are above the map_limitkb to
(unsuable). And then apply the other logic in the e820_allocate to
convert gaps to (unusuable).

But I would think that "libxl: Convert E820_UNUSABLE and E820_RAM to
E820_UNUSABLE as appropriate" already takes care of this?
> 
> -- 
> Daniel De Graaf
> National Security Agency
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 21:55:02 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 21:55:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rawmc-000598-Po; Wed, 14 Dec 2011 21:54:38 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1Rawmb-000593-OB
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 21:54:37 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-10.tower-216.messagelabs.com!1323899619!7392867!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28942 invoked from network); 14 Dec 2011 21:53:41 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-10.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Dec 2011 21:53:41 -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
	pBELrcWv032698
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Wed, 14 Dec 2011 16:53:38 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pBELrc5M032696;
	Wed, 14 Dec 2011 16:53:38 -0500
Date: Wed, 14 Dec 2011 17:53:37 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Message-ID: <20111214215337.GE25896@andromeda.dapyr.net>
References: <4EE0CC19.8040905@tycho.nsa.gov>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4EE0CC19.8040905@tycho.nsa.gov>
User-Agent: Mutt/1.5.9i
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] memory map issues with PV PCI passthrough
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Dec 08, 2011 at 09:39:21AM -0500, Daniel De Graaf wrote:
> I have a system with several reserved ranges low in the e820 map which
> cause problems when starting PV domains with PCI devices. The machine
> memory map looks like:
> 
> (XEN)  0000000000000000 - 0000000000060000 (usable)
> (XEN)  0000000000060000 - 0000000000068000 (reserved)
> (XEN)  0000000000068000 - 000000000009ac00 (usable)
> (XEN)  000000000009ac00 - 00000000000a0000 (reserved)
> (XEN)  00000000000e0000 - 0000000000100000 (reserved)
> (XEN)  0000000000100000 - 0000000000800000 (usable)
> (XEN)  0000000000800000 - 000000000087d000 (unusable)
> (XEN)  000000000087d000 - 0000000000f00000 (usable)
> (XEN)  0000000000f00000 - 0000000001000000 (reserved)
> (XEN)  0000000001000000 - 0000000020000000 (usable)
> (XEN)  0000000020000000 - 0000000020200000 (reserved)
> (XEN)  0000000020200000 - 0000000040000000 (usable)
> (XEN)  0000000040000000 - 0000000040200000 (reserved)
> (XEN)  0000000040200000 - 00000000c95d6000 (usable)
> (XEN)  00000000c95d6000 - 00000000c961a000 (reserved)
> (XEN)  00000000c961a000 - 00000000c99b7000 (usable)
> (XEN)  00000000c99b7000 - 00000000c99e7000 (reserved)
> (XEN)  00000000c99e7000 - 00000000c9be7000 (ACPI NVS)
> (XEN)  00000000c9be7000 - 00000000c9bff000 (ACPI data)
> (XEN)  00000000c9bff000 - 00000000c9c00000 (usable)
> (XEN)  00000000c9f00000 - 00000000ca000000 (reserved)
> (XEN)  00000000cb000000 - 00000000cf200000 (reserved)
> (XEN)  00000000fed1c000 - 00000000fed30000 (reserved)
> (XEN)  00000000ffc00000 - 00000000ffc20000 (reserved)
> (XEN)  0000000100000000 - 000000042e000000 (usable)
> 
> When e820_sanitize is called on this memory map to create a PV domain, the
> resulting map has only one usable region (0-0xf00000) below 4GB, and Linux
> will not boot with this memory map.

OK, that looks like a bug. WE could modify e820_santizie in the libxl
to use the hosts E820 and fill in the (usuable) regions with the memory
that is allocated for it. Instead of allocating a big chunk at the start
and then working out the other regions.

> 
> I have a patch that reworks e820_sanitize to include later RAM regions as
> valid RAM, which works as long as the domain being booted has permission
> to map the PFNs from 0x20000-0x20200 and 0x40000-0x40200. If the domain is
> not given this permission (the default, since these regions are not part of
> the PCI device being passed to the guest) then the hypervisor crashes the
> domain when it attempts to map these regions (during init_memory_mapping).

Hmm, so it tries to map (reserved) regions? That seems rather odd.
I am pretty sure it worked for me. What Linux kernel did you use and
can you send the guest config file as well please?
> 
> The domain will boot when these regions are not marked as reserved in the
> e820 map or when the PFNs 0x20200-0x40000 and 0x40200-0xc95d6 are marked
> as unusable. However, it is difficult to make this happen in any general
> case without knowing what reserved regions actually need to be marked as
> reserved in the guest.
> 
> If PCI hot-add is not needed, the problem becomes simpler: the PCI regions
> for assigned devices can be included in the e820 map and other regions can
> be ignored (marking as RAM so that the guest does not attempt direct map).
> 
> Any suggestions on the best way to resolve this?

I think reworking the e820_allocate to just use the E820 from the host
and just convert the RAM regions that are above the map_limitkb to
(unsuable). And then apply the other logic in the e820_allocate to
convert gaps to (unusuable).

But I would think that "libxl: Convert E820_UNUSABLE and E820_RAM to
E820_UNUSABLE as appropriate" already takes care of this?
> 
> -- 
> Daniel De Graaf
> National Security Agency
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 22:01:44 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 22:01:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rawt2-0005Ki-Lk; Wed, 14 Dec 2011 22:01:16 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1Rawt1-0005KU-55
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 22:01:15 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-9.tower-216.messagelabs.com!1323900017!7509703!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31398 invoked from network); 14 Dec 2011 22:00:18 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-9.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Dec 2011 22:00:18 -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
	pBEM0FEv000626
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Wed, 14 Dec 2011 17:00:15 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pBEM0Fji000624;
	Wed, 14 Dec 2011 17:00:15 -0500
Date: Wed, 14 Dec 2011 18:00:15 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Quartexx <quartex73@gmail.com>
Message-ID: <20111214220015.GF25896@andromeda.dapyr.net>
References: <CAMhBqqiLc1994GUKtA7UY52pR29nktmFy+XiwTwpZb_E+fwFRQ@mail.gmail.com>
	<CAMhBqqgu6v8NB-X0dNdfrzd12=Y2i==fYCCC2Z+MkDupqqKAOg@mail.gmail.com>
	<20111202195727.GA18758@andromeda.dapyr.net>
	<CAMhBqqgJ0Q3BZDuK3KEEGuDS2eGBZq89E7_Kbv+VNTYxZJLAAA@mail.gmail.com>
	<20111214194029.GB17432@andromeda.dapyr.net>
	<CAMhBqqj-3cjgiQsahL8BJHyJbCfYu+8dQx546XLf8Ht+6LiF0w@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAMhBqqj-3cjgiQsahL8BJHyJbCfYu+8dQx546XLf8Ht+6LiF0w@mail.gmail.com>
User-Agent: Mutt/1.5.9i
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] xen 4.0.1 w/2.6.32.47 hangs at boot
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Dec 14, 2011 at 10:05:36PM +0100, Quartexx wrote:
> 2011/12/14 Konrad Rzeszutek Wilk <konrad@darnok.org>:
> > I would hazzard a guess that it is something with the 3ware driver.
> > Can you configure Alt-SysRq so that you can see the stack trace of
> > dom0 and where it hanged? And also do Ctrl-Ax3 and press 'q' to see
> > where dom0 is stuck? It should print out a bunch of 0xff.. and I can
> > help you debug what that is in the dom0 kernel so we can figure out
> > what is happening.
> 
> 
> Thanks, I would try that as soon as possible (unfortunately this box
> is in a remote datacenter)

Ok, but you have a serial console, so you should be able to trigger
Alt-SysRQ using the serial console. I think it is something like 'send
break'. You should Google for it thought.

> Googling I found this
> https://bugzilla.redhat.com/show_bug.cgi?id=429937
> They suggest to rebuild initrd including scsi_wait_scan module.

Well, you are not even seeing the "Booting has failed" and I did not see
anything in your serial log saying that it had gone further in the boot
to start the initrd process.

You could expand the boot process by adding 'initcall_debug' to give a
better idea where it is in the boot process.
> Another workaround could be to use rootdelay in the kernel command line
> Worth a try or a waste of time?
> 
> 
> > Or you can also try the latest kernel - 3.0.x and see if the problem
> > appears there as well - which is much easier for us to fix and has
> > some other important fixes that won't be back-ported to 2.6.32.
> 
> Since I'm using blktap2 I'm concerned about upgrading to 3.0.x.  I
> have read bad feedback about blktap-dkms.  Are my concerns unfounded?

No idea. I have never used blktap*.

>  Are there any alternative to blktap2 (excluding LVM)?

qdisk can do some of it. It is not as fast, but it can deal with
'tap:aio' and such. Or even a normal disk image 'file://'
> Thanks
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 22:01:44 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 22:01:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rawt2-0005Ki-Lk; Wed, 14 Dec 2011 22:01:16 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1Rawt1-0005KU-55
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 22:01:15 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-9.tower-216.messagelabs.com!1323900017!7509703!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31398 invoked from network); 14 Dec 2011 22:00:18 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-9.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Dec 2011 22:00:18 -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
	pBEM0FEv000626
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Wed, 14 Dec 2011 17:00:15 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pBEM0Fji000624;
	Wed, 14 Dec 2011 17:00:15 -0500
Date: Wed, 14 Dec 2011 18:00:15 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Quartexx <quartex73@gmail.com>
Message-ID: <20111214220015.GF25896@andromeda.dapyr.net>
References: <CAMhBqqiLc1994GUKtA7UY52pR29nktmFy+XiwTwpZb_E+fwFRQ@mail.gmail.com>
	<CAMhBqqgu6v8NB-X0dNdfrzd12=Y2i==fYCCC2Z+MkDupqqKAOg@mail.gmail.com>
	<20111202195727.GA18758@andromeda.dapyr.net>
	<CAMhBqqgJ0Q3BZDuK3KEEGuDS2eGBZq89E7_Kbv+VNTYxZJLAAA@mail.gmail.com>
	<20111214194029.GB17432@andromeda.dapyr.net>
	<CAMhBqqj-3cjgiQsahL8BJHyJbCfYu+8dQx546XLf8Ht+6LiF0w@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAMhBqqj-3cjgiQsahL8BJHyJbCfYu+8dQx546XLf8Ht+6LiF0w@mail.gmail.com>
User-Agent: Mutt/1.5.9i
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] xen 4.0.1 w/2.6.32.47 hangs at boot
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Dec 14, 2011 at 10:05:36PM +0100, Quartexx wrote:
> 2011/12/14 Konrad Rzeszutek Wilk <konrad@darnok.org>:
> > I would hazzard a guess that it is something with the 3ware driver.
> > Can you configure Alt-SysRq so that you can see the stack trace of
> > dom0 and where it hanged? And also do Ctrl-Ax3 and press 'q' to see
> > where dom0 is stuck? It should print out a bunch of 0xff.. and I can
> > help you debug what that is in the dom0 kernel so we can figure out
> > what is happening.
> 
> 
> Thanks, I would try that as soon as possible (unfortunately this box
> is in a remote datacenter)

Ok, but you have a serial console, so you should be able to trigger
Alt-SysRQ using the serial console. I think it is something like 'send
break'. You should Google for it thought.

> Googling I found this
> https://bugzilla.redhat.com/show_bug.cgi?id=429937
> They suggest to rebuild initrd including scsi_wait_scan module.

Well, you are not even seeing the "Booting has failed" and I did not see
anything in your serial log saying that it had gone further in the boot
to start the initrd process.

You could expand the boot process by adding 'initcall_debug' to give a
better idea where it is in the boot process.
> Another workaround could be to use rootdelay in the kernel command line
> Worth a try or a waste of time?
> 
> 
> > Or you can also try the latest kernel - 3.0.x and see if the problem
> > appears there as well - which is much easier for us to fix and has
> > some other important fixes that won't be back-ported to 2.6.32.
> 
> Since I'm using blktap2 I'm concerned about upgrading to 3.0.x.  I
> have read bad feedback about blktap-dkms.  Are my concerns unfounded?

No idea. I have never used blktap*.

>  Are there any alternative to blktap2 (excluding LVM)?

qdisk can do some of it. It is not as fast, but it can deal with
'tap:aio' and such. Or even a normal disk image 'file://'
> Thanks
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 22:03:39 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 22:03:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rawv1-0005Pk-6V; Wed, 14 Dec 2011 22:03:19 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Rawuz-0005PP-Lk
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 22:03:18 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1323900141!5584052!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTc4Ng==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30263 invoked from network); 14 Dec 2011 22:02:21 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Dec 2011 22:02:21 -0000
X-IronPort-AV: E=Sophos;i="4.71,355,1320624000"; 
   d="scan'208";a="9477028"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Dec 2011 22:02:21 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 14 Dec 2011 22:02:21 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1Rawu5-0000uS-5n;
	Wed, 14 Dec 2011 22:02:21 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Rawu4-0004Vp-Nn;
	Wed, 14 Dec 2011 22:02:20 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10492-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 14 Dec 2011 22:02:20 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10492: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10492 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10492/

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-i386-xl-win7-amd64  7 windows-install          fail REGR. vs. 10491
 test-amd64-amd64-xl-win7-amd64  7 windows-install         fail REGR. vs. 10491
 test-amd64-amd64-xl-sedf-pin 14 guest-localmigrate/x10    fail REGR. vs. 10491

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3    7 windows-install              fail   like 10491
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3  7 windows-install              fail  like 10491
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install          fail like 10491

version targeted for testing:
 xen                  5d2dd48bce21
baseline version:
 xen                  03138a08366b

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   24408:5d2dd48bce21
tag:         tip
user:        Andrew Cooper <andrew.cooper3@citrix.com>
date:        Wed Dec 14 17:53:54 2011 +0100
    
    XLAT.lst whitespace fix.
    
    Replace spaces with tabs to be in line with file format.
    
    Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
    Committed-by: Jan Beulich <jbeulich@suse.com>
    
    
changeset:   24407:03138a08366b
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Fri Dec 09 16:19:36 2011 +0000
    
    oxenstored: log Errors and Warnings by default.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Acked-by: Ian Jackson <ian.jackson.citrix.com>
    Committed-by: Ian Jackson <ian.jackson.citrix.com>
    
    
========================================
commit 54e24021005458ad0a361c1d83011b751726a94b
Author: Ian Jackson <ian.jackson@eu.citrix.com>
Date:   Thu Dec 8 16:38:06 2011 +0000

    qemu_get_timer: Provide a comment about the behaviour on ts==NULL
    
    Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 22:03:39 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 22:03:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rawv1-0005Pk-6V; Wed, 14 Dec 2011 22:03:19 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Rawuz-0005PP-Lk
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 22:03:18 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1323900141!5584052!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTc4Ng==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30263 invoked from network); 14 Dec 2011 22:02:21 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Dec 2011 22:02:21 -0000
X-IronPort-AV: E=Sophos;i="4.71,355,1320624000"; 
   d="scan'208";a="9477028"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Dec 2011 22:02:21 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 14 Dec 2011 22:02:21 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1Rawu5-0000uS-5n;
	Wed, 14 Dec 2011 22:02:21 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Rawu4-0004Vp-Nn;
	Wed, 14 Dec 2011 22:02:20 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10492-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 14 Dec 2011 22:02:20 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10492: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10492 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10492/

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-i386-xl-win7-amd64  7 windows-install          fail REGR. vs. 10491
 test-amd64-amd64-xl-win7-amd64  7 windows-install         fail REGR. vs. 10491
 test-amd64-amd64-xl-sedf-pin 14 guest-localmigrate/x10    fail REGR. vs. 10491

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3    7 windows-install              fail   like 10491
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3  7 windows-install              fail  like 10491
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install          fail like 10491

version targeted for testing:
 xen                  5d2dd48bce21
baseline version:
 xen                  03138a08366b

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   24408:5d2dd48bce21
tag:         tip
user:        Andrew Cooper <andrew.cooper3@citrix.com>
date:        Wed Dec 14 17:53:54 2011 +0100
    
    XLAT.lst whitespace fix.
    
    Replace spaces with tabs to be in line with file format.
    
    Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
    Committed-by: Jan Beulich <jbeulich@suse.com>
    
    
changeset:   24407:03138a08366b
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Fri Dec 09 16:19:36 2011 +0000
    
    oxenstored: log Errors and Warnings by default.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Acked-by: Ian Jackson <ian.jackson.citrix.com>
    Committed-by: Ian Jackson <ian.jackson.citrix.com>
    
    
========================================
commit 54e24021005458ad0a361c1d83011b751726a94b
Author: Ian Jackson <ian.jackson@eu.citrix.com>
Date:   Thu Dec 8 16:38:06 2011 +0000

    qemu_get_timer: Provide a comment about the behaviour on ts==NULL
    
    Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 22:10:07 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 22:10:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rax1H-00067Y-UG; Wed, 14 Dec 2011 22:09:47 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Rax1H-00067F-3d
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 22:09:47 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1323900529!8258462!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDQwNjMy\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3334 invoked from network); 14 Dec 2011 22:08:51 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-15.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Dec 2011 22:08:51 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pBEM7u3T002800
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 14 Dec 2011 22:07:57 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pBEM7sBI011623
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 14 Dec 2011 22:07:54 GMT
Received: from abhmt117.oracle.com (abhmt117.oracle.com [141.146.116.69])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pBEM7qwq027060; Wed, 14 Dec 2011 16:07:53 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 14 Dec 2011 14:07:52 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 4CD6840102; Wed, 14 Dec 2011 17:07:00 -0500 (EST)
Date: Wed, 14 Dec 2011 17:07:00 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
Message-ID: <20111214220700.GA9926@phenom.dumpdata.com>
References: <zarafa.4ece387c.6e85.6aa0c9ca21e63bd9@uhura.space.zz>
	<zarafa.4edb62f8.6417.1a54a5c25b8f0fd7@uhura.space.zz>
	<20111206032621.GA6568@phenom.dumpdata.com>
	<20111214202351.GA25896@andromeda.dapyr.net>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="45Z9DzgjV8m4Oswq"
Content-Disposition: inline
In-Reply-To: <20111214202351.GA25896@andromeda.dapyr.net>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090208.4EE91E3E.00D1,ss=1,re=-2.300,fgs=0
Cc: xen-devel <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Carsten Schiers <carsten@schiers.de>,
	"zhenzhong.duan@oracle.com" <zhenzhong.duan@oracle.com>,
	linux@eikelenboom.it, "lersek@redhat.com" <lersek@redhat.com>
Subject: Re: [Xen-devel] Load increase after memory upgrade (part2)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--45Z9DzgjV8m4Oswq
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Wed, Dec 14, 2011 at 04:23:51PM -0400, Konrad Rzeszutek Wilk wrote:
> On Mon, Dec 05, 2011 at 10:26:21PM -0500, Konrad Rzeszutek Wilk wrote:
> > On Sun, Dec 04, 2011 at 01:09:28PM +0100, Carsten Schiers wrote:
> > > Here with two cards enabled and creating a bit "work" by watching TV with one oft hem:
> > > 
> > > [   23.842720] Starting SWIOTLB debug thread.
> > > [   23.842750] swiotlb_start_thread: Go!
> > > [   23.842838] xen_swiotlb_start_thread: Go!
> > > [   28.841451] 0 [budget_av 0000:00:01.0] bounce: from:435596(slow:0)to:0 map:658 unmap:0 sync:435596
> > > [   28.841592] SWIOTLB is 4% full
> > > [   33.840147] 0 [budget_av 0000:00:01.0] bounce: from:127652(slow:0)to:0 map:0 unmap:0 sync:127652
> > > [   33.840283] SWIOTLB is 4% full
> > > [   33.844222] 0 budget_av 0000:00:01.0 alloc coherent: 8, free: 0
> > > [   38.840227] 0 [budget_av 0000:00:01.0] bounce: from:128310(slow:0)to:0 map:0 unmap:0 sync:128310
> > 
> > Whoa. Yes. You are definitly using the bounce buffer :-)
> > 
> > Now it is time to look at why the drive is not using those coherent ones - it
> > looks to allocate just eight of them but does not use them.. Unless it is
> > using them _and_ bouncing them (which would be odd).
> > 
> > And BTW, you can lower your 'swiotlb=XX' value.  The 4% is how much you
> > are using of the default size.
> 
> So I able to see this with an atl1c ethernet driver on my SandyBridge i3
> box. It looks as if the card is truly 32-bit so on a box with 8GB it
> bounces the data. If I booted the Xen hypervisor with 'mem=4GB' I get no
> bounces (no surprise there).
> 
> In other words - I see the same behavior you are seeing. Now off to:
> > 
> > I should find out_why_ the old Xen kernels do not use the bounce buffer
> > so much...
> 
> which will require some fiddling around.

And I am not seeing any difference - the swiotlb is used with the same usage when
booting a classic (old style XEnoLinux) 2.6.32 vs using a brand new pvops (3.2).
Obviously if I limit the physical amount of memory (so 'mem=4GB' on Xen hypervisor
line), the bounce usage disappears. Hmm, I wonder if there is a nice way to 
tell the hypervisor - hey, please stuff dom0 under 4GB.

Here is the patch I used against classic XenLinux. Any chance you could run
it with your classis guests and see what numbers you get?



--45Z9DzgjV8m4Oswq
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="swiotlb-against-old-type.patch"

diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
index ab0bb23..17faefd 100644
--- a/drivers/xen/Kconfig
+++ b/drivers/xen/Kconfig
@@ -469,3 +469,10 @@ config XEN_SYS_HYPERVISOR
 	 hypervisor environment.  When running native or in another
 	 virtual environment, /sys/hypervisor will still be present,
 	 but will have no xen contents.
+
+config SWIOTLB_DEBUG
+	tristate "swiotlb debug facility."
+	default m
+	help
+	  Do not enable it.
+
diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
index 28fb50a..df84614 100644
--- a/drivers/xen/Makefile
+++ b/drivers/xen/Makefile
@@ -42,3 +42,4 @@ obj-$(CONFIG_XEN_GRANT_DEV)	+= gntdev/
 obj-$(CONFIG_XEN_NETDEV_ACCEL_SFC_UTIL)		+= sfc_netutil/
 obj-$(CONFIG_XEN_NETDEV_ACCEL_SFC_FRONTEND)	+= sfc_netfront/
 obj-$(CONFIG_XEN_NETDEV_ACCEL_SFC_BACKEND)	+= sfc_netback/
+obj-$(CONFIG_SWIOTLB_DEBUG)			+= dump_swiotlb.o
diff --git a/drivers/xen/dump_swiotlb.c b/drivers/xen/dump_swiotlb.c
new file mode 100644
index 0000000..7168eed
--- /dev/null
+++ b/drivers/xen/dump_swiotlb.c
@@ -0,0 +1,72 @@
+/*
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License v2.0 as published by
+ * the Free Software Foundation
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include <linux/module.h>
+#include <linux/string.h>
+#include <linux/types.h>
+#include <linux/init.h>
+#include <linux/stat.h>
+#include <linux/err.h>
+#include <linux/ctype.h>
+#include <linux/slab.h>
+#include <linux/limits.h>
+#include <linux/device.h>
+#include <linux/pci.h>
+#include <linux/blkdev.h>
+#include <linux/device.h>
+
+#include <linux/init.h>
+#include <linux/mm.h>
+#include <linux/fcntl.h>
+#include <linux/slab.h>
+#include <linux/kmod.h>
+#include <linux/major.h>
+#include <linux/highmem.h>
+#include <linux/blkdev.h>
+#include <linux/module.h>
+#include <linux/blkpg.h>
+#include <linux/buffer_head.h>
+#include <linux/mpage.h>
+#include <linux/mount.h>
+#include <linux/uio.h>
+#include <linux/namei.h>
+#include <asm/uaccess.h>
+
+#include <linux/pagemap.h>
+#include <linux/pagevec.h>
+
+#include <linux/swiotlb.h>
+#define DUMP_SWIOTLB_FUN  "0.1"
+
+MODULE_AUTHOR("Konrad Rzeszutek Wilk <konrad@darnok.org>");
+MODULE_DESCRIPTION("dump swiotlb");
+MODULE_LICENSE("GPL");
+MODULE_VERSION(DUMP_SWIOTLB_FUN);
+/*
+extern int xen_swiotlb_start_thread(void);
+extern void xen_swiotlb_stop_thread(void);*/
+static int __init dump_swiotlb_init(void)
+{
+	printk(KERN_INFO "Starting SWIOTLB debug thread.\n");
+	swiotlb_start_thread();
+	//xen_swiotlb_start_thread();
+	return 0;
+}
+
+static void __exit dump_swiotlb_exit(void)
+{
+	swiotlb_stop_thread();
+	//xen_swiotlb_stop_thread();
+}
+
+module_init(dump_swiotlb_init);
+module_exit(dump_swiotlb_exit);
diff --git a/include/linux/swiotlb.h b/include/linux/swiotlb.h
index 73b1f1c..81f5a1e 100644
--- a/include/linux/swiotlb.h
+++ b/include/linux/swiotlb.h
@@ -7,6 +7,9 @@ struct device;
 struct dma_attrs;
 struct scatterlist;
 
+ 
+extern int swiotlb_start_thread(void);
+extern void swiotlb_stop_thread(void);
 /*
  * Maximum allowable number of contiguous slabs to map,
  * must be a power of 2.  What is the appropriate value ?
diff --git a/lib/swiotlb-xen.c b/lib/swiotlb-xen.c
index 152696c..d1df462 100644
--- a/lib/swiotlb-xen.c
+++ b/lib/swiotlb-xen.c
@@ -118,6 +118,78 @@ setup_io_tlb_npages(char *str)
 }
 __setup("swiotlb=", setup_io_tlb_npages);
 /* make io_tlb_overflow tunable too? */
+ 
+#include <linux/percpu.h>
+struct swiotlb_debug {
+	unsigned long bounce_to;
+	unsigned long bounce_from;
+	unsigned long bounce_slow;
+	unsigned long map;
+	unsigned long unmap;
+	unsigned long sync;
+	char dev_name[64];
+};
+
+;
+static DEFINE_PER_CPU(struct swiotlb_debug, tlb_debug);
+#include <linux/kthread.h>
+static int swiotlb_debug_thread(void *arg)
+{
+	int cpu;
+	int size = io_tlb_nslabs;
+	do {
+		int i;
+		unsigned long filled = 0;
+		set_current_state(TASK_INTERRUPTIBLE);
+		schedule_timeout_interruptible(HZ*5);
+
+		for_each_online_cpu(cpu) {
+			struct swiotlb_debug *d = &per_cpu(tlb_debug, cpu);
+			/* Can't really happend.*/
+			if (!d)
+				continue;
+			if (d->dev_name[0] == 0)
+				continue;
+
+			printk(KERN_INFO "%d [%s] bounce: from:%ld(slow:%ld)to:%ld map:%ld unmap:%ld sync:%ld\n",
+				cpu,
+				d->dev_name ? d->dev_name : "?",
+				d->bounce_from,
+				d->bounce_slow,
+				d->bounce_to,
+				d->map, d->unmap, d->sync);
+			memset(d, 0, sizeof(struct swiotlb_debug));
+		}
+		/* Very crude calculation. */
+		for (i = 0; i < size; i++) {
+			if (io_tlb_list[i] == 0)
+				filled++;
+		}
+		printk(KERN_INFO "SWIOTLB is %ld%% full\n", (filled * 100) / size);
+
+	} while (!kthread_should_stop());
+	return 0;
+}
+static struct task_struct *debug_thread = NULL;
+
+
+int swiotlb_start_thread(void) {
+
+	if (debug_thread)
+		return -EINVAL;
+	printk(KERN_INFO "%s: Go!\n",__func__);
+	debug_thread =  kthread_run(swiotlb_debug_thread, NULL, "swiotlb_debug");
+}
+EXPORT_SYMBOL_GPL(swiotlb_start_thread);
+void swiotlb_stop_thread(void) {
+
+	printk(KERN_INFO "%s: Stop!\n",__func__);
+	if (debug_thread)
+		kthread_stop(debug_thread);
+	debug_thread = NULL;
+}
+EXPORT_SYMBOL_GPL(swiotlb_stop_thread);
+
 
 /* Note that this doesn't work with highmem page */
 static dma_addr_t swiotlb_virt_to_bus(struct device *hwdev,
@@ -270,6 +342,11 @@ static void swiotlb_bounce(phys_addr_t phys, char *dma_addr, size_t size,
 			   enum dma_data_direction dir)
 {
 	unsigned long pfn = PFN_DOWN(phys);
+	struct swiotlb_debug *d;
+
+	preempt_disable();
+	d = &__get_cpu_var(tlb_debug);
+	preempt_enable();
 
 	if (PageHighMem(pfn_to_page(pfn))) {
 		/* The buffer does not have a mapping.  Map it in and copy */
@@ -297,12 +374,18 @@ static void swiotlb_bounce(phys_addr_t phys, char *dma_addr, size_t size,
 			dma_addr += sz;
 			offset = 0;
 		}
+		d->bounce_slow++;
 	} else {
-		if (dir == DMA_TO_DEVICE)
+		if (dir == DMA_TO_DEVICE) {
 			memcpy(dma_addr, phys_to_virt(phys), size);
-		else if (__copy_to_user_inatomic(phys_to_virt(phys),
+			d->bounce_to++;
+		}
+		else {
+			if (__copy_to_user_inatomic(phys_to_virt(phys),
 						 dma_addr, size))
 			/* inaccessible */;
+			d->bounce_from++;
+		}
 	}
 }
 
@@ -406,6 +489,16 @@ found:
 	if (dir == DMA_TO_DEVICE || dir == DMA_BIDIRECTIONAL)
 		swiotlb_bounce(phys, dma_addr, size, DMA_TO_DEVICE);
 
+	{
+		struct swiotlb_debug *d;
+		preempt_disable();
+		d = &__get_cpu_var(tlb_debug);
+		preempt_enable();
+		d->map++;
+		snprintf(d->dev_name, sizeof(d->dev_name), "%s %s",
+                	dev_driver_string(hwdev), dev_name(hwdev));
+	}
+
 	return dma_addr;
 }
 
@@ -453,6 +546,17 @@ do_unmap_single(struct device *hwdev, char *dma_addr, size_t size, int dir)
 			io_tlb_list[i] = ++count;
 	}
 	spin_unlock_irqrestore(&io_tlb_lock, flags);
+
+	{
+		struct swiotlb_debug *d;
+		preempt_disable();
+		d = &__get_cpu_var(tlb_debug);
+		preempt_enable();
+		d->unmap++;
+		snprintf(d->dev_name, sizeof(d->dev_name), "%s %s",
+                	dev_driver_string(hwdev), dev_name(hwdev));
+	}
+
 }
 
 static void
@@ -462,6 +566,14 @@ sync_single(struct device *hwdev, char *dma_addr, size_t size,
 	int index = (dma_addr - io_tlb_start) >> IO_TLB_SHIFT;
 	phys_addr_t phys = io_tlb_orig_addr[index];
 
+	struct swiotlb_debug *d;
+	preempt_disable();
+	d = &__get_cpu_var(tlb_debug);
+	preempt_enable();
+	d->sync++;
+	snprintf(d->dev_name, sizeof(d->dev_name), "%s %s",
+               	dev_driver_string(hwdev), dev_name(hwdev));
+
 	phys += ((unsigned long)dma_addr & ((1 << IO_TLB_SHIFT) - 1));
 
 	switch (target) {

--45Z9DzgjV8m4Oswq
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--45Z9DzgjV8m4Oswq--


From xen-devel-bounces@lists.xensource.com Wed Dec 14 22:10:07 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 22:10:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rax1H-00067Y-UG; Wed, 14 Dec 2011 22:09:47 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Rax1H-00067F-3d
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 22:09:47 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1323900529!8258462!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDQwNjMy\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3334 invoked from network); 14 Dec 2011 22:08:51 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-15.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Dec 2011 22:08:51 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pBEM7u3T002800
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 14 Dec 2011 22:07:57 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pBEM7sBI011623
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 14 Dec 2011 22:07:54 GMT
Received: from abhmt117.oracle.com (abhmt117.oracle.com [141.146.116.69])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pBEM7qwq027060; Wed, 14 Dec 2011 16:07:53 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 14 Dec 2011 14:07:52 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 4CD6840102; Wed, 14 Dec 2011 17:07:00 -0500 (EST)
Date: Wed, 14 Dec 2011 17:07:00 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
Message-ID: <20111214220700.GA9926@phenom.dumpdata.com>
References: <zarafa.4ece387c.6e85.6aa0c9ca21e63bd9@uhura.space.zz>
	<zarafa.4edb62f8.6417.1a54a5c25b8f0fd7@uhura.space.zz>
	<20111206032621.GA6568@phenom.dumpdata.com>
	<20111214202351.GA25896@andromeda.dapyr.net>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="45Z9DzgjV8m4Oswq"
Content-Disposition: inline
In-Reply-To: <20111214202351.GA25896@andromeda.dapyr.net>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090208.4EE91E3E.00D1,ss=1,re=-2.300,fgs=0
Cc: xen-devel <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Carsten Schiers <carsten@schiers.de>,
	"zhenzhong.duan@oracle.com" <zhenzhong.duan@oracle.com>,
	linux@eikelenboom.it, "lersek@redhat.com" <lersek@redhat.com>
Subject: Re: [Xen-devel] Load increase after memory upgrade (part2)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--45Z9DzgjV8m4Oswq
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Wed, Dec 14, 2011 at 04:23:51PM -0400, Konrad Rzeszutek Wilk wrote:
> On Mon, Dec 05, 2011 at 10:26:21PM -0500, Konrad Rzeszutek Wilk wrote:
> > On Sun, Dec 04, 2011 at 01:09:28PM +0100, Carsten Schiers wrote:
> > > Here with two cards enabled and creating a bit "work" by watching TV with one oft hem:
> > > 
> > > [   23.842720] Starting SWIOTLB debug thread.
> > > [   23.842750] swiotlb_start_thread: Go!
> > > [   23.842838] xen_swiotlb_start_thread: Go!
> > > [   28.841451] 0 [budget_av 0000:00:01.0] bounce: from:435596(slow:0)to:0 map:658 unmap:0 sync:435596
> > > [   28.841592] SWIOTLB is 4% full
> > > [   33.840147] 0 [budget_av 0000:00:01.0] bounce: from:127652(slow:0)to:0 map:0 unmap:0 sync:127652
> > > [   33.840283] SWIOTLB is 4% full
> > > [   33.844222] 0 budget_av 0000:00:01.0 alloc coherent: 8, free: 0
> > > [   38.840227] 0 [budget_av 0000:00:01.0] bounce: from:128310(slow:0)to:0 map:0 unmap:0 sync:128310
> > 
> > Whoa. Yes. You are definitly using the bounce buffer :-)
> > 
> > Now it is time to look at why the drive is not using those coherent ones - it
> > looks to allocate just eight of them but does not use them.. Unless it is
> > using them _and_ bouncing them (which would be odd).
> > 
> > And BTW, you can lower your 'swiotlb=XX' value.  The 4% is how much you
> > are using of the default size.
> 
> So I able to see this with an atl1c ethernet driver on my SandyBridge i3
> box. It looks as if the card is truly 32-bit so on a box with 8GB it
> bounces the data. If I booted the Xen hypervisor with 'mem=4GB' I get no
> bounces (no surprise there).
> 
> In other words - I see the same behavior you are seeing. Now off to:
> > 
> > I should find out_why_ the old Xen kernels do not use the bounce buffer
> > so much...
> 
> which will require some fiddling around.

And I am not seeing any difference - the swiotlb is used with the same usage when
booting a classic (old style XEnoLinux) 2.6.32 vs using a brand new pvops (3.2).
Obviously if I limit the physical amount of memory (so 'mem=4GB' on Xen hypervisor
line), the bounce usage disappears. Hmm, I wonder if there is a nice way to 
tell the hypervisor - hey, please stuff dom0 under 4GB.

Here is the patch I used against classic XenLinux. Any chance you could run
it with your classis guests and see what numbers you get?



--45Z9DzgjV8m4Oswq
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="swiotlb-against-old-type.patch"

diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
index ab0bb23..17faefd 100644
--- a/drivers/xen/Kconfig
+++ b/drivers/xen/Kconfig
@@ -469,3 +469,10 @@ config XEN_SYS_HYPERVISOR
 	 hypervisor environment.  When running native or in another
 	 virtual environment, /sys/hypervisor will still be present,
 	 but will have no xen contents.
+
+config SWIOTLB_DEBUG
+	tristate "swiotlb debug facility."
+	default m
+	help
+	  Do not enable it.
+
diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
index 28fb50a..df84614 100644
--- a/drivers/xen/Makefile
+++ b/drivers/xen/Makefile
@@ -42,3 +42,4 @@ obj-$(CONFIG_XEN_GRANT_DEV)	+= gntdev/
 obj-$(CONFIG_XEN_NETDEV_ACCEL_SFC_UTIL)		+= sfc_netutil/
 obj-$(CONFIG_XEN_NETDEV_ACCEL_SFC_FRONTEND)	+= sfc_netfront/
 obj-$(CONFIG_XEN_NETDEV_ACCEL_SFC_BACKEND)	+= sfc_netback/
+obj-$(CONFIG_SWIOTLB_DEBUG)			+= dump_swiotlb.o
diff --git a/drivers/xen/dump_swiotlb.c b/drivers/xen/dump_swiotlb.c
new file mode 100644
index 0000000..7168eed
--- /dev/null
+++ b/drivers/xen/dump_swiotlb.c
@@ -0,0 +1,72 @@
+/*
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License v2.0 as published by
+ * the Free Software Foundation
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include <linux/module.h>
+#include <linux/string.h>
+#include <linux/types.h>
+#include <linux/init.h>
+#include <linux/stat.h>
+#include <linux/err.h>
+#include <linux/ctype.h>
+#include <linux/slab.h>
+#include <linux/limits.h>
+#include <linux/device.h>
+#include <linux/pci.h>
+#include <linux/blkdev.h>
+#include <linux/device.h>
+
+#include <linux/init.h>
+#include <linux/mm.h>
+#include <linux/fcntl.h>
+#include <linux/slab.h>
+#include <linux/kmod.h>
+#include <linux/major.h>
+#include <linux/highmem.h>
+#include <linux/blkdev.h>
+#include <linux/module.h>
+#include <linux/blkpg.h>
+#include <linux/buffer_head.h>
+#include <linux/mpage.h>
+#include <linux/mount.h>
+#include <linux/uio.h>
+#include <linux/namei.h>
+#include <asm/uaccess.h>
+
+#include <linux/pagemap.h>
+#include <linux/pagevec.h>
+
+#include <linux/swiotlb.h>
+#define DUMP_SWIOTLB_FUN  "0.1"
+
+MODULE_AUTHOR("Konrad Rzeszutek Wilk <konrad@darnok.org>");
+MODULE_DESCRIPTION("dump swiotlb");
+MODULE_LICENSE("GPL");
+MODULE_VERSION(DUMP_SWIOTLB_FUN);
+/*
+extern int xen_swiotlb_start_thread(void);
+extern void xen_swiotlb_stop_thread(void);*/
+static int __init dump_swiotlb_init(void)
+{
+	printk(KERN_INFO "Starting SWIOTLB debug thread.\n");
+	swiotlb_start_thread();
+	//xen_swiotlb_start_thread();
+	return 0;
+}
+
+static void __exit dump_swiotlb_exit(void)
+{
+	swiotlb_stop_thread();
+	//xen_swiotlb_stop_thread();
+}
+
+module_init(dump_swiotlb_init);
+module_exit(dump_swiotlb_exit);
diff --git a/include/linux/swiotlb.h b/include/linux/swiotlb.h
index 73b1f1c..81f5a1e 100644
--- a/include/linux/swiotlb.h
+++ b/include/linux/swiotlb.h
@@ -7,6 +7,9 @@ struct device;
 struct dma_attrs;
 struct scatterlist;
 
+ 
+extern int swiotlb_start_thread(void);
+extern void swiotlb_stop_thread(void);
 /*
  * Maximum allowable number of contiguous slabs to map,
  * must be a power of 2.  What is the appropriate value ?
diff --git a/lib/swiotlb-xen.c b/lib/swiotlb-xen.c
index 152696c..d1df462 100644
--- a/lib/swiotlb-xen.c
+++ b/lib/swiotlb-xen.c
@@ -118,6 +118,78 @@ setup_io_tlb_npages(char *str)
 }
 __setup("swiotlb=", setup_io_tlb_npages);
 /* make io_tlb_overflow tunable too? */
+ 
+#include <linux/percpu.h>
+struct swiotlb_debug {
+	unsigned long bounce_to;
+	unsigned long bounce_from;
+	unsigned long bounce_slow;
+	unsigned long map;
+	unsigned long unmap;
+	unsigned long sync;
+	char dev_name[64];
+};
+
+;
+static DEFINE_PER_CPU(struct swiotlb_debug, tlb_debug);
+#include <linux/kthread.h>
+static int swiotlb_debug_thread(void *arg)
+{
+	int cpu;
+	int size = io_tlb_nslabs;
+	do {
+		int i;
+		unsigned long filled = 0;
+		set_current_state(TASK_INTERRUPTIBLE);
+		schedule_timeout_interruptible(HZ*5);
+
+		for_each_online_cpu(cpu) {
+			struct swiotlb_debug *d = &per_cpu(tlb_debug, cpu);
+			/* Can't really happend.*/
+			if (!d)
+				continue;
+			if (d->dev_name[0] == 0)
+				continue;
+
+			printk(KERN_INFO "%d [%s] bounce: from:%ld(slow:%ld)to:%ld map:%ld unmap:%ld sync:%ld\n",
+				cpu,
+				d->dev_name ? d->dev_name : "?",
+				d->bounce_from,
+				d->bounce_slow,
+				d->bounce_to,
+				d->map, d->unmap, d->sync);
+			memset(d, 0, sizeof(struct swiotlb_debug));
+		}
+		/* Very crude calculation. */
+		for (i = 0; i < size; i++) {
+			if (io_tlb_list[i] == 0)
+				filled++;
+		}
+		printk(KERN_INFO "SWIOTLB is %ld%% full\n", (filled * 100) / size);
+
+	} while (!kthread_should_stop());
+	return 0;
+}
+static struct task_struct *debug_thread = NULL;
+
+
+int swiotlb_start_thread(void) {
+
+	if (debug_thread)
+		return -EINVAL;
+	printk(KERN_INFO "%s: Go!\n",__func__);
+	debug_thread =  kthread_run(swiotlb_debug_thread, NULL, "swiotlb_debug");
+}
+EXPORT_SYMBOL_GPL(swiotlb_start_thread);
+void swiotlb_stop_thread(void) {
+
+	printk(KERN_INFO "%s: Stop!\n",__func__);
+	if (debug_thread)
+		kthread_stop(debug_thread);
+	debug_thread = NULL;
+}
+EXPORT_SYMBOL_GPL(swiotlb_stop_thread);
+
 
 /* Note that this doesn't work with highmem page */
 static dma_addr_t swiotlb_virt_to_bus(struct device *hwdev,
@@ -270,6 +342,11 @@ static void swiotlb_bounce(phys_addr_t phys, char *dma_addr, size_t size,
 			   enum dma_data_direction dir)
 {
 	unsigned long pfn = PFN_DOWN(phys);
+	struct swiotlb_debug *d;
+
+	preempt_disable();
+	d = &__get_cpu_var(tlb_debug);
+	preempt_enable();
 
 	if (PageHighMem(pfn_to_page(pfn))) {
 		/* The buffer does not have a mapping.  Map it in and copy */
@@ -297,12 +374,18 @@ static void swiotlb_bounce(phys_addr_t phys, char *dma_addr, size_t size,
 			dma_addr += sz;
 			offset = 0;
 		}
+		d->bounce_slow++;
 	} else {
-		if (dir == DMA_TO_DEVICE)
+		if (dir == DMA_TO_DEVICE) {
 			memcpy(dma_addr, phys_to_virt(phys), size);
-		else if (__copy_to_user_inatomic(phys_to_virt(phys),
+			d->bounce_to++;
+		}
+		else {
+			if (__copy_to_user_inatomic(phys_to_virt(phys),
 						 dma_addr, size))
 			/* inaccessible */;
+			d->bounce_from++;
+		}
 	}
 }
 
@@ -406,6 +489,16 @@ found:
 	if (dir == DMA_TO_DEVICE || dir == DMA_BIDIRECTIONAL)
 		swiotlb_bounce(phys, dma_addr, size, DMA_TO_DEVICE);
 
+	{
+		struct swiotlb_debug *d;
+		preempt_disable();
+		d = &__get_cpu_var(tlb_debug);
+		preempt_enable();
+		d->map++;
+		snprintf(d->dev_name, sizeof(d->dev_name), "%s %s",
+                	dev_driver_string(hwdev), dev_name(hwdev));
+	}
+
 	return dma_addr;
 }
 
@@ -453,6 +546,17 @@ do_unmap_single(struct device *hwdev, char *dma_addr, size_t size, int dir)
 			io_tlb_list[i] = ++count;
 	}
 	spin_unlock_irqrestore(&io_tlb_lock, flags);
+
+	{
+		struct swiotlb_debug *d;
+		preempt_disable();
+		d = &__get_cpu_var(tlb_debug);
+		preempt_enable();
+		d->unmap++;
+		snprintf(d->dev_name, sizeof(d->dev_name), "%s %s",
+                	dev_driver_string(hwdev), dev_name(hwdev));
+	}
+
 }
 
 static void
@@ -462,6 +566,14 @@ sync_single(struct device *hwdev, char *dma_addr, size_t size,
 	int index = (dma_addr - io_tlb_start) >> IO_TLB_SHIFT;
 	phys_addr_t phys = io_tlb_orig_addr[index];
 
+	struct swiotlb_debug *d;
+	preempt_disable();
+	d = &__get_cpu_var(tlb_debug);
+	preempt_enable();
+	d->sync++;
+	snprintf(d->dev_name, sizeof(d->dev_name), "%s %s",
+               	dev_driver_string(hwdev), dev_name(hwdev));
+
 	phys += ((unsigned long)dma_addr & ((1 << IO_TLB_SHIFT) - 1));
 
 	switch (target) {

--45Z9DzgjV8m4Oswq
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--45Z9DzgjV8m4Oswq--


From xen-devel-bounces@lists.xensource.com Wed Dec 14 22:38:24 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 22:38:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaxSW-000796-Ce; Wed, 14 Dec 2011 22:37:56 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RaxSV-000791-CS
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 22:37:55 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-6.tower-216.messagelabs.com!1323902218!7480741!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16791 invoked from network); 14 Dec 2011 22:36:58 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-6.tower-216.messagelabs.com with SMTP;
	14 Dec 2011 22:36:58 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea01.nsa.gov (8.12.10/8.12.10) with ESMTP id
	pBEMa2LN019445; Wed, 14 Dec 2011 22:36:02 GMT
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id pBEMa1RV018064; 
	Wed, 14 Dec 2011 17:36:01 -0500
Message-ID: <4EE924E8.4070701@tycho.nsa.gov>
Date: Wed, 14 Dec 2011 17:36:24 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:7.0.1) Gecko/20110930 Thunderbird/7.0.1
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
References: <4EE0CC19.8040905@tycho.nsa.gov>
	<20111214215337.GE25896@andromeda.dapyr.net>
In-Reply-To: <20111214215337.GE25896@andromeda.dapyr.net>
X-Enigmail-Version: 1.3.2
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] memory map issues with PV PCI passthrough
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 12/14/2011 04:53 PM, Konrad Rzeszutek Wilk wrote:
> On Thu, Dec 08, 2011 at 09:39:21AM -0500, Daniel De Graaf wrote:
>> I have a system with several reserved ranges low in the e820 map which
>> cause problems when starting PV domains with PCI devices. The machine
>> memory map looks like:
>>
>> (XEN)  0000000000000000 - 0000000000060000 (usable)
>> (XEN)  0000000000060000 - 0000000000068000 (reserved)
>> (XEN)  0000000000068000 - 000000000009ac00 (usable)
>> (XEN)  000000000009ac00 - 00000000000a0000 (reserved)
>> (XEN)  00000000000e0000 - 0000000000100000 (reserved)
>> (XEN)  0000000000100000 - 0000000000800000 (usable)
>> (XEN)  0000000000800000 - 000000000087d000 (unusable)
>> (XEN)  000000000087d000 - 0000000000f00000 (usable)
>> (XEN)  0000000000f00000 - 0000000001000000 (reserved)
>> (XEN)  0000000001000000 - 0000000020000000 (usable)
>> (XEN)  0000000020000000 - 0000000020200000 (reserved)
>> (XEN)  0000000020200000 - 0000000040000000 (usable)
>> (XEN)  0000000040000000 - 0000000040200000 (reserved)
>> (XEN)  0000000040200000 - 00000000c95d6000 (usable)
>> (XEN)  00000000c95d6000 - 00000000c961a000 (reserved)
>> (XEN)  00000000c961a000 - 00000000c99b7000 (usable)
>> (XEN)  00000000c99b7000 - 00000000c99e7000 (reserved)
>> (XEN)  00000000c99e7000 - 00000000c9be7000 (ACPI NVS)
>> (XEN)  00000000c9be7000 - 00000000c9bff000 (ACPI data)
>> (XEN)  00000000c9bff000 - 00000000c9c00000 (usable)
>> (XEN)  00000000c9f00000 - 00000000ca000000 (reserved)
>> (XEN)  00000000cb000000 - 00000000cf200000 (reserved)
>> (XEN)  00000000fed1c000 - 00000000fed30000 (reserved)
>> (XEN)  00000000ffc00000 - 00000000ffc20000 (reserved)
>> (XEN)  0000000100000000 - 000000042e000000 (usable)
>>
>> When e820_sanitize is called on this memory map to create a PV domain, the
>> resulting map has only one usable region (0-0xf00000) below 4GB, and Linux
>> will not boot with this memory map.
> 
> OK, that looks like a bug. WE could modify e820_santizie in the libxl
> to use the hosts E820 and fill in the (usuable) regions with the memory
> that is allocated for it. Instead of allocating a big chunk at the start
> and then working out the other regions.
> 
>>
>> I have a patch that reworks e820_sanitize to include later RAM regions as
>> valid RAM, which works as long as the domain being booted has permission
>> to map the PFNs from 0x20000-0x20200 and 0x40000-0x40200. If the domain is
>> not given this permission (the default, since these regions are not part of
>> the PCI device being passed to the guest) then the hypervisor crashes the
>> domain when it attempts to map these regions (during init_memory_mapping).
> 
> Hmm, so it tries to map (reserved) regions? That seems rather odd.
> I am pretty sure it worked for me. What Linux kernel did you use and
> can you send the guest config file as well please?

Kernel 3.2-rc3; the code doing the mapping is init_memory_mapping in
arch/x86/mm/init.c which maps all memory up to the highest usable region
below 4G. On this system with my e820 patch, that may be as high as 0xc9c00000
depending on how much memory you give the guest.

Guest config:

kernel='/home/daniel/linux/build/drdom/arch/x86/boot/bzImage'
ramdisk='/boot/initramfs-generic.img'
root='/dev/xvda1'
extra='earlyprintk=xen console=hvc0'
memory=2500
name='vm-2'
vcpus=2
vif = [ 'mac=00:fe:64:01:01:01,bridge=vmbr' ]
disk = [ 'backendtype=phy,vdev=xvda,access=w,target=/dev/clam/vm2' ]
seclabel='v:vm:domPV'
pci=['0000:03:02.0']

PCI device 03:02.0 is an extra NIC that I'm using to test.

>>
>> The domain will boot when these regions are not marked as reserved in the
>> e820 map or when the PFNs 0x20200-0x40000 and 0x40200-0xc95d6 are marked
>> as unusable. However, it is difficult to make this happen in any general
>> case without knowing what reserved regions actually need to be marked as
>> reserved in the guest.
>>
>> If PCI hot-add is not needed, the problem becomes simpler: the PCI regions
>> for assigned devices can be included in the e820 map and other regions can
>> be ignored (marking as RAM so that the guest does not attempt direct map).
>>
>> Any suggestions on the best way to resolve this?
> 
> I think reworking the e820_allocate to just use the E820 from the host
> and just convert the RAM regions that are above the map_limitkb to
> (unsuable). And then apply the other logic in the e820_allocate to
> convert gaps to (unusuable).
> 
> But I would think that "libxl: Convert E820_UNUSABLE and E820_RAM to
> E820_UNUSABLE as appropriate" already takes care of this?

It does in part. The issues is that my memory map has a reserved region
(0xf00000 - 0x1000000) that is too low in the memory map, so almost all
of the RAM below 4G is marked as unusable. I'm pretty sure this includes
the address where the kernel itself is loaded.


Boot with my e820 patch adding usable regions where possible:

libxl: debug: libxl_pci.c:237:libxl__create_pci_backend: Creating pci backend
libxl: debug: libxl_pci.c:1240:e820_sanitize: Memory: 2560000kB Balloon: 8192kB Contiguous PFN: 0xf00 PCI region PFNs: 0xf00-0x100000
libxl: debug: libxl_pci.c:1326:e820_sanitize: : [0 -> f00] RAM
libxl: debug: libxl_pci.c:1326:e820_sanitize: : [1000 -> 20000] RAM
libxl: debug: libxl_pci.c:1326:e820_sanitize: : [20200 -> 40000] RAM
libxl: debug: libxl_pci.c:1326:e820_sanitize: : [40200 -> 9c900] RAM
libxl: debug: libxl_pci.c:1326:e820_sanitize: : [f00 -> f00] Unusable
libxl: debug: libxl_pci.c:1326:e820_sanitize: : [f00 -> 1000] Reserved
libxl: debug: libxl_pci.c:1326:e820_sanitize: : [20000 -> 20200] Reserved
libxl: debug: libxl_pci.c:1326:e820_sanitize: : [40000 -> 40200] Reserved
libxl: debug: libxl_pci.c:1326:e820_sanitize: : [9c900 -> c95d6] Unusable
libxl: debug: libxl_pci.c:1326:e820_sanitize: : [c95d6 -> c961a] Reserved
libxl: debug: libxl_pci.c:1326:e820_sanitize: : [c961a -> c99b7] Unusable
libxl: debug: libxl_pci.c:1326:e820_sanitize: : [c99b7 -> c99e7] Reserved
libxl: debug: libxl_pci.c:1326:e820_sanitize: : [c99e7 -> c9be7] ACPI NVS
libxl: debug: libxl_pci.c:1326:e820_sanitize: : [c9be7 -> c9bff] ACPI
libxl: debug: libxl_pci.c:1326:e820_sanitize: : [c9bff -> c9c00] Unusable
libxl: debug: libxl_pci.c:1326:e820_sanitize: : [cb000 -> cf200] Reserved
libxl: debug: libxl_pci.c:1326:e820_sanitize: : [fed1c -> fed20] Reserved
libxl: debug: libxl_pci.c:1326:e820_sanitize: : [ffc00 -> ffc20] Reserved
libxl: debug: libxl_pci.c:1326:e820_sanitize: : [100000 -> 100800] RAM
Daemon running with PID 11104
(early) [    0.000000] Initializing cgroup subsys cpuset
(early) [    0.000000] Initializing cgroup subsys cpu
(early) [    0.000000] Linux version 3.2.0-rc3-00022-g8462101 (daniel@moss-clam.epoch.ncsc.mil) (gcc version 4.6.1 20110908 (Red Hat 4.6.1-9) (GCC) ) #35 SMP Wed Dec 7 10:00:40 EST 2011
(early) [    0.000000] Command line: root=/dev/xvda1 earlyprintk=xen console=hvc0
(early) [    0.000000] ACPI in unprivileged domain disabled
(early) [    0.000000] Freeing  f00-1000 pfn range: 256 pages freed
(early) [    0.000000] Freeing  20000-20200 pfn range: 512 pages freed
(early) [    0.000000] Freeing  40000-40200 pfn range: 512 pages freed
(early) [    0.000000] Released 1280 pages of unused memory
(early) [    0.000000] Set 408576 page(s) to 1-1 mapping
(early) [    0.000000] BIOS-provided physical RAM map:
(early) [    0.000000]  Xen: 0000000000000000 - 00000000000a0000 (usable)
(early) [    0.000000]  Xen: 00000000000a0000 - 0000000000100000 (reserved)
(early) [    0.000000]  Xen: 0000000000100000 - 0000000000f00000 (usable)
(early) [    0.000000]  Xen: 0000000000f00000 - 0000000001000000 (reserved)
(early) [    0.000000]  Xen: 0000000001000000 - 0000000020000000 (usable)
(early) [    0.000000]  Xen: 0000000020000000 - 0000000020200000 (reserved)
(early) [    0.000000]  Xen: 0000000020200000 - 0000000040000000 (usable)
(early) [    0.000000]  Xen: 0000000040000000 - 0000000040200000 (reserved)
(early) [    0.000000]  Xen: 0000000040200000 - 000000009c900000 (usable)
(early) [    0.000000]  Xen: 000000009c900000 - 00000000c95d6000 (unusable)
(early) [    0.000000]  Xen: 00000000c95d6000 - 00000000c961a000 (reserved)
(early) [    0.000000]  Xen: 00000000c961a000 - 00000000c99b7000 (unusable)
(early) [    0.000000]  Xen: 00000000c99b7000 - 00000000c99e7000 (reserved)
(early) [    0.000000]  Xen: 00000000c99e7000 - 00000000c9be7000 (ACPI NVS)
(early) [    0.000000]  Xen: 00000000c9be7000 - 00000000c9bff000 (ACPI data)
(early) [    0.000000]  Xen: 00000000c9bff000 - 00000000c9c00000 (unusable)
(early) [    0.000000]  Xen: 00000000cb000000 - 00000000cf200000 (reserved)
(early) [    0.000000]  Xen: 00000000fed1c000 - 00000000fed20000 (reserved)
(early) [    0.000000]  Xen: 00000000ffc00000 - 00000000ffc20000 (reserved)
(early) [    0.000000]  Xen: 0000000100000000 - 0000000100100000 (usable)
(early) [    0.000000]  Xen: 0000000100100000 - 0000000100800000 (unusable)
(early) [    0.000000] bootconsole [xenboot0] enabled
(early) [    0.000000] NX (Execute Disable) protection: active
(early) [    0.000000] DMI not present or invalid.
(early) [    0.000000] No AGP bridge found
(early) [    0.000000] last_pfn = 0x100100 max_arch_pfn = 0x400000000
(early) [    0.000000] last_pfn = 0x9c900 max_arch_pfn = 0x400000000
(early) [    0.000000] init_memory_mapping: 0000000000000000-000000009c900000
(XEN) mm.c:866:d7 Non-privileged (7) attempt to map I/O space 00020000
(XEN) mm.c:1270:d7 Failure in alloc_l1_table: entry 0
(XEN) mm.c:2239:d7 Error while validating mfn 2fabf8 (pfn af3) for type 1000000000000000: caf=8000000000000003 taf=1000000000000001
(XEN) mm.c:3049:d7 Error while pinning mfn 2fabf8
(XEN) traps.c:486:d7 Unhandled invalid opcode fault/trap [#6] on VCPU 0 [ec=0000]
(XEN) domain_crash_sync called from entry.S


Boot without my patch adjusting the e820 map:

libxl: debug: libxl_pci.c:1326:e820_sanitize: : [0 -> f00] RAM
libxl: debug: libxl_pci.c:1326:e820_sanitize: : [f00 -> f00] Unusable
libxl: debug: libxl_pci.c:1326:e820_sanitize: : [f00 -> 1000] Reserved
libxl: debug: libxl_pci.c:1326:e820_sanitize: : [1000 -> 20000] Unusable
libxl: debug: libxl_pci.c:1326:e820_sanitize: : [20000 -> 20200] Reserved
libxl: debug: libxl_pci.c:1326:e820_sanitize: : [20200 -> 40000] Unusable
libxl: debug: libxl_pci.c:1326:e820_sanitize: : [40000 -> 40200] Reserved
libxl: debug: libxl_pci.c:1326:e820_sanitize: : [40200 -> c95d6] Unusable
libxl: debug: libxl_pci.c:1326:e820_sanitize: : [c95d6 -> c961a] Reserved
libxl: debug: libxl_pci.c:1326:e820_sanitize: : [c961a -> c99b7] Unusable
libxl: debug: libxl_pci.c:1326:e820_sanitize: : [c99b7 -> c99e7] Reserved
libxl: debug: libxl_pci.c:1326:e820_sanitize: : [c99e7 -> c9be7] ACPI NVS
libxl: debug: libxl_pci.c:1326:e820_sanitize: : [c9be7 -> c9bff] ACPI
libxl: debug: libxl_pci.c:1326:e820_sanitize: : [c9bff -> c9c00] Unusable
libxl: debug: libxl_pci.c:1326:e820_sanitize: : [cb000 -> cf200] Reserved
libxl: debug: libxl_pci.c:1326:e820_sanitize: : [fed1c -> fed20] Reserved
libxl: debug: libxl_pci.c:1326:e820_sanitize: : [ffc00 -> ffc20] Reserved
libxl: debug: libxl_pci.c:1326:e820_sanitize: : [100000 -> 19bd00] RAM
Daemon running with PID 18113
--- xl dies at this point due to domain crashing ---

Serial console from that boot:

(XEN) [VT-D]iommu.c:1464: d8:PCI: map 0000:03:02.0
mapping kernel into physical memory
[ 5770.151645] xabout to get started...
en-pciback: vpci: 0000:03:02.0: assign to virtual slot 0
[ 5770.153834] ADDRCONF(NETDEV_UP): vif8.0: link is not ready
[ 5770.168648] pciback 0000:03:02.0: device has been assigned to another domain! Over-writting the ownership, but beware.
[ 5770.240228] device vif8.0 entered promiscuous mode
[ 5770.248595] ADDRCONF(NETDEV_UP): vif8.0: link is not ready
[    0.000000] Initializing cgroup subsys cpuset
(XEN) [VT-D]iommu.c:1594: d8:PCI: unmap 0000:03:02.0

(Ignore the pciback message, the result is the same if I reboot to get rid of that).


Working boot with hard-coded lower-RAM limit PFN=0x20000:

libxl: debug: libxl_pci.c:237:libxl__create_pci_backend: Creating pci backend
libxl: debug: libxl_pci.c:1240:e820_sanitize: Memory: 2560000kB Balloon: 8192kB Contiguous PFN: 0xf00 PCI region PFNs: 0xf00-0x100000
libxl: debug: libxl_pci.c:1326:e820_sanitize: : [0 -> f00] RAM
libxl: debug: libxl_pci.c:1326:e820_sanitize: : [1000 -> 20000] RAM
libxl: debug: libxl_pci.c:1326:e820_sanitize: : [f00 -> f00] Unusable
libxl: debug: libxl_pci.c:1326:e820_sanitize: : [f00 -> 1000] Reserved
libxl: debug: libxl_pci.c:1326:e820_sanitize: : [20000 -> 20200] Reserved
libxl: debug: libxl_pci.c:1326:e820_sanitize: : [20200 -> 40000] Unusable
libxl: debug: libxl_pci.c:1326:e820_sanitize: : [40000 -> 40200] Reserved
libxl: debug: libxl_pci.c:1326:e820_sanitize: : [40200 -> c95d6] Unusable
libxl: debug: libxl_pci.c:1326:e820_sanitize: : [c95d6 -> c961a] Reserved
libxl: debug: libxl_pci.c:1326:e820_sanitize: : [c961a -> c99b7] Unusable
libxl: debug: libxl_pci.c:1326:e820_sanitize: : [c99b7 -> c99e7] Reserved
libxl: debug: libxl_pci.c:1326:e820_sanitize: : [c99e7 -> c9be7] ACPI NVS
libxl: debug: libxl_pci.c:1326:e820_sanitize: : [c9be7 -> c9bff] ACPI
libxl: debug: libxl_pci.c:1326:e820_sanitize: : [c9bff -> c9c00] Unusable
libxl: debug: libxl_pci.c:1326:e820_sanitize: : [cb000 -> cf200] Reserved
libxl: debug: libxl_pci.c:1326:e820_sanitize: : [fed1c -> fed20] Reserved
libxl: debug: libxl_pci.c:1326:e820_sanitize: : [ffc00 -> ffc20] Reserved
libxl: debug: libxl_pci.c:1326:e820_sanitize: : [100000 -> 17cd00] RAM
Daemon running with PID 24900
(early) [    0.000000] Initializing cgroup subsys cpuset
(early) [    0.000000] Initializing cgroup subsys cpu
(early) [    0.000000] Linux version 3.2.0-rc3-00022-g8462101 (daniel@moss-clam.epoch.ncsc.mil) (gcc version 4.6.1 20110908 (Red Hat 4.6.1-9) (GCC) ) #35 SMP Wed Dec 7 10:00:40 EST 2011
(early) [    0.000000] Command line: root=/dev/xvda1 earlyprintk=xen console=hvc0
(early) [    0.000000] ACPI in unprivileged domain disabled
(early) [    0.000000] Freeing  f00-1000 pfn range: 256 pages freed
(early) [    0.000000] Freeing  20000-9c400 pfn range: 508928 pages freed
(early) [    0.000000] Released 509184 pages of unused memory
(early) [    0.000000] Set 917760 page(s) to 1-1 mapping
(early) [    0.000000] BIOS-provided physical RAM map:
(early) [    0.000000]  Xen: 0000000000000000 - 00000000000a0000 (usable)
(early) [    0.000000]  Xen: 00000000000a0000 - 0000000000100000 (reserved)
(early) [    0.000000]  Xen: 0000000000100000 - 0000000000f00000 (usable)
(early) [    0.000000]  Xen: 0000000000f00000 - 0000000001000000 (reserved)
(early) [    0.000000]  Xen: 0000000001000000 - 0000000020000000 (usable)
(early) [    0.000000]  Xen: 0000000020000000 - 0000000020200000 (reserved)
(early) [    0.000000]  Xen: 0000000020200000 - 0000000040000000 (unusable)
(early) [    0.000000]  Xen: 0000000040000000 - 0000000040200000 (reserved)
(early) [    0.000000]  Xen: 0000000040200000 - 00000000c95d6000 (unusable)
(early) [    0.000000]  Xen: 00000000c95d6000 - 00000000c961a000 (reserved)
(early) [    0.000000]  Xen: 00000000c961a000 - 00000000c99b7000 (unusable)
(early) [    0.000000]  Xen: 00000000c99b7000 - 00000000c99e7000 (reserved)
(early) [    0.000000]  Xen: 00000000c99e7000 - 00000000c9be7000 (ACPI NVS)
(early) [    0.000000]  Xen: 00000000c9be7000 - 00000000c9bff000 (ACPI data)
(early) [    0.000000]  Xen: 00000000c9bff000 - 00000000c9c00000 (unusable)
(early) [    0.000000]  Xen: 00000000cb000000 - 00000000cf200000 (reserved)
(early) [    0.000000]  Xen: 00000000fed1c000 - 00000000fed20000 (reserved)
(early) [    0.000000]  Xen: 00000000ffc00000 - 00000000ffc20000 (reserved)
(early) [    0.000000]  Xen: 0000000100000000 - 000000017c600000 (usable)
(early) [    0.000000]  Xen: 000000017c600000 - 000000017cd00000 (unusable)
(early) [    0.000000] bootconsole [xenboot0] enabled
(early) [    0.000000] NX (Execute Disable) protection: active
(early) [    0.000000] DMI not present or invalid.
(early) [    0.000000] No AGP bridge found
(early) [    0.000000] last_pfn = 0x17c600 max_arch_pfn = 0x400000000
(early) [    0.000000] last_pfn = 0x20000 max_arch_pfn = 0x400000000
(early) [    0.000000] init_memory_mapping: 0000000000000000-0000000020000000
(early) [    0.000000] init_memory_mapping: 0000000100000000-000000017c600000
(early) [    0.000000] RAMDISK: 02a5a000 - 03a62000
...

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 14 22:38:24 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 Dec 2011 22:38:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RaxSW-000796-Ce; Wed, 14 Dec 2011 22:37:56 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RaxSV-000791-CS
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 22:37:55 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-6.tower-216.messagelabs.com!1323902218!7480741!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16791 invoked from network); 14 Dec 2011 22:36:58 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-6.tower-216.messagelabs.com with SMTP;
	14 Dec 2011 22:36:58 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea01.nsa.gov (8.12.10/8.12.10) with ESMTP id
	pBEMa2LN019445; Wed, 14 Dec 2011 22:36:02 GMT
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id pBEMa1RV018064; 
	Wed, 14 Dec 2011 17:36:01 -0500
Message-ID: <4EE924E8.4070701@tycho.nsa.gov>
Date: Wed, 14 Dec 2011 17:36:24 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:7.0.1) Gecko/20110930 Thunderbird/7.0.1
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
References: <4EE0CC19.8040905@tycho.nsa.gov>
	<20111214215337.GE25896@andromeda.dapyr.net>
In-Reply-To: <20111214215337.GE25896@andromeda.dapyr.net>
X-Enigmail-Version: 1.3.2
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] memory map issues with PV PCI passthrough
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 12/14/2011 04:53 PM, Konrad Rzeszutek Wilk wrote:
> On Thu, Dec 08, 2011 at 09:39:21AM -0500, Daniel De Graaf wrote:
>> I have a system with several reserved ranges low in the e820 map which
>> cause problems when starting PV domains with PCI devices. The machine
>> memory map looks like:
>>
>> (XEN)  0000000000000000 - 0000000000060000 (usable)
>> (XEN)  0000000000060000 - 0000000000068000 (reserved)
>> (XEN)  0000000000068000 - 000000000009ac00 (usable)
>> (XEN)  000000000009ac00 - 00000000000a0000 (reserved)
>> (XEN)  00000000000e0000 - 0000000000100000 (reserved)
>> (XEN)  0000000000100000 - 0000000000800000 (usable)
>> (XEN)  0000000000800000 - 000000000087d000 (unusable)
>> (XEN)  000000000087d000 - 0000000000f00000 (usable)
>> (XEN)  0000000000f00000 - 0000000001000000 (reserved)
>> (XEN)  0000000001000000 - 0000000020000000 (usable)
>> (XEN)  0000000020000000 - 0000000020200000 (reserved)
>> (XEN)  0000000020200000 - 0000000040000000 (usable)
>> (XEN)  0000000040000000 - 0000000040200000 (reserved)
>> (XEN)  0000000040200000 - 00000000c95d6000 (usable)
>> (XEN)  00000000c95d6000 - 00000000c961a000 (reserved)
>> (XEN)  00000000c961a000 - 00000000c99b7000 (usable)
>> (XEN)  00000000c99b7000 - 00000000c99e7000 (reserved)
>> (XEN)  00000000c99e7000 - 00000000c9be7000 (ACPI NVS)
>> (XEN)  00000000c9be7000 - 00000000c9bff000 (ACPI data)
>> (XEN)  00000000c9bff000 - 00000000c9c00000 (usable)
>> (XEN)  00000000c9f00000 - 00000000ca000000 (reserved)
>> (XEN)  00000000cb000000 - 00000000cf200000 (reserved)
>> (XEN)  00000000fed1c000 - 00000000fed30000 (reserved)
>> (XEN)  00000000ffc00000 - 00000000ffc20000 (reserved)
>> (XEN)  0000000100000000 - 000000042e000000 (usable)
>>
>> When e820_sanitize is called on this memory map to create a PV domain, the
>> resulting map has only one usable region (0-0xf00000) below 4GB, and Linux
>> will not boot with this memory map.
> 
> OK, that looks like a bug. WE could modify e820_santizie in the libxl
> to use the hosts E820 and fill in the (usuable) regions with the memory
> that is allocated for it. Instead of allocating a big chunk at the start
> and then working out the other regions.
> 
>>
>> I have a patch that reworks e820_sanitize to include later RAM regions as
>> valid RAM, which works as long as the domain being booted has permission
>> to map the PFNs from 0x20000-0x20200 and 0x40000-0x40200. If the domain is
>> not given this permission (the default, since these regions are not part of
>> the PCI device being passed to the guest) then the hypervisor crashes the
>> domain when it attempts to map these regions (during init_memory_mapping).
> 
> Hmm, so it tries to map (reserved) regions? That seems rather odd.
> I am pretty sure it worked for me. What Linux kernel did you use and
> can you send the guest config file as well please?

Kernel 3.2-rc3; the code doing the mapping is init_memory_mapping in
arch/x86/mm/init.c which maps all memory up to the highest usable region
below 4G. On this system with my e820 patch, that may be as high as 0xc9c00000
depending on how much memory you give the guest.

Guest config:

kernel='/home/daniel/linux/build/drdom/arch/x86/boot/bzImage'
ramdisk='/boot/initramfs-generic.img'
root='/dev/xvda1'
extra='earlyprintk=xen console=hvc0'
memory=2500
name='vm-2'
vcpus=2
vif = [ 'mac=00:fe:64:01:01:01,bridge=vmbr' ]
disk = [ 'backendtype=phy,vdev=xvda,access=w,target=/dev/clam/vm2' ]
seclabel='v:vm:domPV'
pci=['0000:03:02.0']

PCI device 03:02.0 is an extra NIC that I'm using to test.

>>
>> The domain will boot when these regions are not marked as reserved in the
>> e820 map or when the PFNs 0x20200-0x40000 and 0x40200-0xc95d6 are marked
>> as unusable. However, it is difficult to make this happen in any general
>> case without knowing what reserved regions actually need to be marked as
>> reserved in the guest.
>>
>> If PCI hot-add is not needed, the problem becomes simpler: the PCI regions
>> for assigned devices can be included in the e820 map and other regions can
>> be ignored (marking as RAM so that the guest does not attempt direct map).
>>
>> Any suggestions on the best way to resolve this?
> 
> I think reworking the e820_allocate to just use the E820 from the host
> and just convert the RAM regions that are above the map_limitkb to
> (unsuable). And then apply the other logic in the e820_allocate to
> convert gaps to (unusuable).
> 
> But I would think that "libxl: Convert E820_UNUSABLE and E820_RAM to
> E820_UNUSABLE as appropriate" already takes care of this?

It does in part. The issues is that my memory map has a reserved region
(0xf00000 - 0x1000000) that is too low in the memory map, so almost all
of the RAM below 4G is marked as unusable. I'm pretty sure this includes
the address where the kernel itself is loaded.


Boot with my e820 patch adding usable regions where possible:

libxl: debug: libxl_pci.c:237:libxl__create_pci_backend: Creating pci backend
libxl: debug: libxl_pci.c:1240:e820_sanitize: Memory: 2560000kB Balloon: 8192kB Contiguous PFN: 0xf00 PCI region PFNs: 0xf00-0x100000
libxl: debug: libxl_pci.c:1326:e820_sanitize: : [0 -> f00] RAM
libxl: debug: libxl_pci.c:1326:e820_sanitize: : [1000 -> 20000] RAM
libxl: debug: libxl_pci.c:1326:e820_sanitize: : [20200 -> 40000] RAM
libxl: debug: libxl_pci.c:1326:e820_sanitize: : [40200 -> 9c900] RAM
libxl: debug: libxl_pci.c:1326:e820_sanitize: : [f00 -> f00] Unusable
libxl: debug: libxl_pci.c:1326:e820_sanitize: : [f00 -> 1000] Reserved
libxl: debug: libxl_pci.c:1326:e820_sanitize: : [20000 -> 20200] Reserved
libxl: debug: libxl_pci.c:1326:e820_sanitize: : [40000 -> 40200] Reserved
libxl: debug: libxl_pci.c:1326:e820_sanitize: : [9c900 -> c95d6] Unusable
libxl: debug: libxl_pci.c:1326:e820_sanitize: : [c95d6 -> c961a] Reserved
libxl: debug: libxl_pci.c:1326:e820_sanitize: : [c961a -> c99b7] Unusable
libxl: debug: libxl_pci.c:1326:e820_sanitize: : [c99b7 -> c99e7] Reserved
libxl: debug: libxl_pci.c:1326:e820_sanitize: : [c99e7 -> c9be7] ACPI NVS
libxl: debug: libxl_pci.c:1326:e820_sanitize: : [c9be7 -> c9bff] ACPI
libxl: debug: libxl_pci.c:1326:e820_sanitize: : [c9bff -> c9c00] Unusable
libxl: debug: libxl_pci.c:1326:e820_sanitize: : [cb000 -> cf200] Reserved
libxl: debug: libxl_pci.c:1326:e820_sanitize: : [fed1c -> fed20] Reserved
libxl: debug: libxl_pci.c:1326:e820_sanitize: : [ffc00 -> ffc20] Reserved
libxl: debug: libxl_pci.c:1326:e820_sanitize: : [100000 -> 100800] RAM
Daemon running with PID 11104
(early) [    0.000000] Initializing cgroup subsys cpuset
(early) [    0.000000] Initializing cgroup subsys cpu
(early) [    0.000000] Linux version 3.2.0-rc3-00022-g8462101 (daniel@moss-clam.epoch.ncsc.mil) (gcc version 4.6.1 20110908 (Red Hat 4.6.1-9) (GCC) ) #35 SMP Wed Dec 7 10:00:40 EST 2011
(early) [    0.000000] Command line: root=/dev/xvda1 earlyprintk=xen console=hvc0
(early) [    0.000000] ACPI in unprivileged domain disabled
(early) [    0.000000] Freeing  f00-1000 pfn range: 256 pages freed
(early) [    0.000000] Freeing  20000-20200 pfn range: 512 pages freed
(early) [    0.000000] Freeing  40000-40200 pfn range: 512 pages freed
(early) [    0.000000] Released 1280 pages of unused memory
(early) [    0.000000] Set 408576 page(s) to 1-1 mapping
(early) [    0.000000] BIOS-provided physical RAM map:
(early) [    0.000000]  Xen: 0000000000000000 - 00000000000a0000 (usable)
(early) [    0.000000]  Xen: 00000000000a0000 - 0000000000100000 (reserved)
(early) [    0.000000]  Xen: 0000000000100000 - 0000000000f00000 (usable)
(early) [    0.000000]  Xen: 0000000000f00000 - 0000000001000000 (reserved)
(early) [    0.000000]  Xen: 0000000001000000 - 0000000020000000 (usable)
(early) [    0.000000]  Xen: 0000000020000000 - 0000000020200000 (reserved)
(early) [    0.000000]  Xen: 0000000020200000 - 0000000040000000 (usable)
(early) [    0.000000]  Xen: 0000000040000000 - 0000000040200000 (reserved)
(early) [    0.000000]  Xen: 0000000040200000 - 000000009c900000 (usable)
(early) [    0.000000]  Xen: 000000009c900000 - 00000000c95d6000 (unusable)
(early) [    0.000000]  Xen: 00000000c95d6000 - 00000000c961a000 (reserved)
(early) [    0.000000]  Xen: 00000000c961a000 - 00000000c99b7000 (unusable)
(early) [    0.000000]  Xen: 00000000c99b7000 - 00000000c99e7000 (reserved)
(early) [    0.000000]  Xen: 00000000c99e7000 - 00000000c9be7000 (ACPI NVS)
(early) [    0.000000]  Xen: 00000000c9be7000 - 00000000c9bff000 (ACPI data)
(early) [    0.000000]  Xen: 00000000c9bff000 - 00000000c9c00000 (unusable)
(early) [    0.000000]  Xen: 00000000cb000000 - 00000000cf200000 (reserved)
(early) [    0.000000]  Xen: 00000000fed1c000 - 00000000fed20000 (reserved)
(early) [    0.000000]  Xen: 00000000ffc00000 - 00000000ffc20000 (reserved)
(early) [    0.000000]  Xen: 0000000100000000 - 0000000100100000 (usable)
(early) [    0.000000]  Xen: 0000000100100000 - 0000000100800000 (unusable)
(early) [    0.000000] bootconsole [xenboot0] enabled
(early) [    0.000000] NX (Execute Disable) protection: active
(early) [    0.000000] DMI not present or invalid.
(early) [    0.000000] No AGP bridge found
(early) [    0.000000] last_pfn = 0x100100 max_arch_pfn = 0x400000000
(early) [    0.000000] last_pfn = 0x9c900 max_arch_pfn = 0x400000000
(early) [    0.000000] init_memory_mapping: 0000000000000000-000000009c900000
(XEN) mm.c:866:d7 Non-privileged (7) attempt to map I/O space 00020000
(XEN) mm.c:1270:d7 Failure in alloc_l1_table: entry 0
(XEN) mm.c:2239:d7 Error while validating mfn 2fabf8 (pfn af3) for type 1000000000000000: caf=8000000000000003 taf=1000000000000001
(XEN) mm.c:3049:d7 Error while pinning mfn 2fabf8
(XEN) traps.c:486:d7 Unhandled invalid opcode fault/trap [#6] on VCPU 0 [ec=0000]
(XEN) domain_crash_sync called from entry.S


Boot without my patch adjusting the e820 map:

libxl: debug: libxl_pci.c:1326:e820_sanitize: : [0 -> f00] RAM
libxl: debug: libxl_pci.c:1326:e820_sanitize: : [f00 -> f00] Unusable
libxl: debug: libxl_pci.c:1326:e820_sanitize: : [f00 -> 1000] Reserved
libxl: debug: libxl_pci.c:1326:e820_sanitize: : [1000 -> 20000] Unusable
libxl: debug: libxl_pci.c:1326:e820_sanitize: : [20000 -> 20200] Reserved
libxl: debug: libxl_pci.c:1326:e820_sanitize: : [20200 -> 40000] Unusable
libxl: debug: libxl_pci.c:1326:e820_sanitize: : [40000 -> 40200] Reserved
libxl: debug: libxl_pci.c:1326:e820_sanitize: : [40200 -> c95d6] Unusable
libxl: debug: libxl_pci.c:1326:e820_sanitize: : [c95d6 -> c961a] Reserved
libxl: debug: libxl_pci.c:1326:e820_sanitize: : [c961a -> c99b7] Unusable
libxl: debug: libxl_pci.c:1326:e820_sanitize: : [c99b7 -> c99e7] Reserved
libxl: debug: libxl_pci.c:1326:e820_sanitize: : [c99e7 -> c9be7] ACPI NVS
libxl: debug: libxl_pci.c:1326:e820_sanitize: : [c9be7 -> c9bff] ACPI
libxl: debug: libxl_pci.c:1326:e820_sanitize: : [c9bff -> c9c00] Unusable
libxl: debug: libxl_pci.c:1326:e820_sanitize: : [cb000 -> cf200] Reserved
libxl: debug: libxl_pci.c:1326:e820_sanitize: : [fed1c -> fed20] Reserved
libxl: debug: libxl_pci.c:1326:e820_sanitize: : [ffc00 -> ffc20] Reserved
libxl: debug: libxl_pci.c:1326:e820_sanitize: : [100000 -> 19bd00] RAM
Daemon running with PID 18113
--- xl dies at this point due to domain crashing ---

Serial console from that boot:

(XEN) [VT-D]iommu.c:1464: d8:PCI: map 0000:03:02.0
mapping kernel into physical memory
[ 5770.151645] xabout to get started...
en-pciback: vpci: 0000:03:02.0: assign to virtual slot 0
[ 5770.153834] ADDRCONF(NETDEV_UP): vif8.0: link is not ready
[ 5770.168648] pciback 0000:03:02.0: device has been assigned to another domain! Over-writting the ownership, but beware.
[ 5770.240228] device vif8.0 entered promiscuous mode
[ 5770.248595] ADDRCONF(NETDEV_UP): vif8.0: link is not ready
[    0.000000] Initializing cgroup subsys cpuset
(XEN) [VT-D]iommu.c:1594: d8:PCI: unmap 0000:03:02.0

(Ignore the pciback message, the result is the same if I reboot to get rid of that).


Working boot with hard-coded lower-RAM limit PFN=0x20000:

libxl: debug: libxl_pci.c:237:libxl__create_pci_backend: Creating pci backend
libxl: debug: libxl_pci.c:1240:e820_sanitize: Memory: 2560000kB Balloon: 8192kB Contiguous PFN: 0xf00 PCI region PFNs: 0xf00-0x100000
libxl: debug: libxl_pci.c:1326:e820_sanitize: : [0 -> f00] RAM
libxl: debug: libxl_pci.c:1326:e820_sanitize: : [1000 -> 20000] RAM
libxl: debug: libxl_pci.c:1326:e820_sanitize: : [f00 -> f00] Unusable
libxl: debug: libxl_pci.c:1326:e820_sanitize: : [f00 -> 1000] Reserved
libxl: debug: libxl_pci.c:1326:e820_sanitize: : [20000 -> 20200] Reserved
libxl: debug: libxl_pci.c:1326:e820_sanitize: : [20200 -> 40000] Unusable
libxl: debug: libxl_pci.c:1326:e820_sanitize: : [40000 -> 40200] Reserved
libxl: debug: libxl_pci.c:1326:e820_sanitize: : [40200 -> c95d6] Unusable
libxl: debug: libxl_pci.c:1326:e820_sanitize: : [c95d6 -> c961a] Reserved
libxl: debug: libxl_pci.c:1326:e820_sanitize: : [c961a -> c99b7] Unusable
libxl: debug: libxl_pci.c:1326:e820_sanitize: : [c99b7 -> c99e7] Reserved
libxl: debug: libxl_pci.c:1326:e820_sanitize: : [c99e7 -> c9be7] ACPI NVS
libxl: debug: libxl_pci.c:1326:e820_sanitize: : [c9be7 -> c9bff] ACPI
libxl: debug: libxl_pci.c:1326:e820_sanitize: : [c9bff -> c9c00] Unusable
libxl: debug: libxl_pci.c:1326:e820_sanitize: : [cb000 -> cf200] Reserved
libxl: debug: libxl_pci.c:1326:e820_sanitize: : [fed1c -> fed20] Reserved
libxl: debug: libxl_pci.c:1326:e820_sanitize: : [ffc00 -> ffc20] Reserved
libxl: debug: libxl_pci.c:1326:e820_sanitize: : [100000 -> 17cd00] RAM
Daemon running with PID 24900
(early) [    0.000000] Initializing cgroup subsys cpuset
(early) [    0.000000] Initializing cgroup subsys cpu
(early) [    0.000000] Linux version 3.2.0-rc3-00022-g8462101 (daniel@moss-clam.epoch.ncsc.mil) (gcc version 4.6.1 20110908 (Red Hat 4.6.1-9) (GCC) ) #35 SMP Wed Dec 7 10:00:40 EST 2011
(early) [    0.000000] Command line: root=/dev/xvda1 earlyprintk=xen console=hvc0
(early) [    0.000000] ACPI in unprivileged domain disabled
(early) [    0.000000] Freeing  f00-1000 pfn range: 256 pages freed
(early) [    0.000000] Freeing  20000-9c400 pfn range: 508928 pages freed
(early) [    0.000000] Released 509184 pages of unused memory
(early) [    0.000000] Set 917760 page(s) to 1-1 mapping
(early) [    0.000000] BIOS-provided physical RAM map:
(early) [    0.000000]  Xen: 0000000000000000 - 00000000000a0000 (usable)
(early) [    0.000000]  Xen: 00000000000a0000 - 0000000000100000 (reserved)
(early) [    0.000000]  Xen: 0000000000100000 - 0000000000f00000 (usable)
(early) [    0.000000]  Xen: 0000000000f00000 - 0000000001000000 (reserved)
(early) [    0.000000]  Xen: 0000000001000000 - 0000000020000000 (usable)
(early) [    0.000000]  Xen: 0000000020000000 - 0000000020200000 (reserved)
(early) [    0.000000]  Xen: 0000000020200000 - 0000000040000000 (unusable)
(early) [    0.000000]  Xen: 0000000040000000 - 0000000040200000 (reserved)
(early) [    0.000000]  Xen: 0000000040200000 - 00000000c95d6000 (unusable)
(early) [    0.000000]  Xen: 00000000c95d6000 - 00000000c961a000 (reserved)
(early) [    0.000000]  Xen: 00000000c961a000 - 00000000c99b7000 (unusable)
(early) [    0.000000]  Xen: 00000000c99b7000 - 00000000c99e7000 (reserved)
(early) [    0.000000]  Xen: 00000000c99e7000 - 00000000c9be7000 (ACPI NVS)
(early) [    0.000000]  Xen: 00000000c9be7000 - 00000000c9bff000 (ACPI data)
(early) [    0.000000]  Xen: 00000000c9bff000 - 00000000c9c00000 (unusable)
(early) [    0.000000]  Xen: 00000000cb000000 - 00000000cf200000 (reserved)
(early) [    0.000000]  Xen: 00000000fed1c000 - 00000000fed20000 (reserved)
(early) [    0.000000]  Xen: 00000000ffc00000 - 00000000ffc20000 (reserved)
(early) [    0.000000]  Xen: 0000000100000000 - 000000017c600000 (usable)
(early) [    0.000000]  Xen: 000000017c600000 - 000000017cd00000 (unusable)
(early) [    0.000000] bootconsole [xenboot0] enabled
(early) [    0.000000] NX (Execute Disable) protection: active
(early) [    0.000000] DMI not present or invalid.
(early) [    0.000000] No AGP bridge found
(early) [    0.000000] last_pfn = 0x17c600 max_arch_pfn = 0x400000000
(early) [    0.000000] last_pfn = 0x20000 max_arch_pfn = 0x400000000
(early) [    0.000000] init_memory_mapping: 0000000000000000-0000000020000000
(early) [    0.000000] init_memory_mapping: 0000000100000000-000000017c600000
(early) [    0.000000] RAMDISK: 02a5a000 - 03a62000
...

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 01:27:00 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 01:27:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rb05P-0004XU-QT; Thu, 15 Dec 2011 01:26:15 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.r.wilk@gmail.com>) id 1Rb05N-0004XP-SY
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 01:26:14 +0000
X-Env-Sender: konrad.r.wilk@gmail.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1323912316!7312529!1
X-Originating-IP: [209.85.216.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29347 invoked from network); 15 Dec 2011 01:25:17 -0000
Received: from mail-qy0-f171.google.com (HELO mail-qy0-f171.google.com)
	(209.85.216.171)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 01:25:17 -0000
Received: by qcsc20 with SMTP id c20so9458352qcs.30
	for <xen-devel@lists.xensource.com>;
	Wed, 14 Dec 2011 17:25:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:date:from:to:cc:subject:message-id:references:mime-version
	:content-type:content-disposition:in-reply-to:user-agent;
	bh=nxK6nXfE4f+zUTAxGZQHmtCM5D0TQzlD/kTCioV/tfo=;
	b=OqNome+hze3AUB8iTQFYMt6P+UCxoNi5VoD0AEmo+Lc0W+L2di2HB5vtsNnhKrrvqf
	VqbW0KVGx+iP18rrgEB6oT/nbh916DFjaJZcyZChOcf2RZNsxTvVUbsGRPqn0r3m6reV
	k+du9/XoObb8mVQZUOj3LrXdibr+UE3WH6LRA=
Received: by 10.224.42.134 with SMTP id s6mr1859696qae.78.1323912316016;
	Wed, 14 Dec 2011 17:25:16 -0800 (PST)
Received: from konrad-lan (209-6-85-33.c3-0.smr-ubr2.sbo-smr.ma.cable.rcn.com.
	[209.6.85.33])
	by mx.google.com with ESMTPS id cd3sm9412004qab.5.2011.12.14.17.25.14
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 14 Dec 2011 17:25:15 -0800 (PST)
Date: Wed, 14 Dec 2011 20:25:12 -0500
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Tim Evers <it@niemail.de>
Message-ID: <20111215012511.GC10268@konrad-lan>
References: <4EE675A8.3030609@niemail.de>
	<20111212215652.GA12106@andromeda.dapyr.net>
	<4EE86598.2060905@niemail.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4EE86598.2060905@niemail.de>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] a ton of kernel issues
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> > Looking at your BUG, did you look in the .config to see if you
> > had MAXSMP or NR_CPUS defined? If you had MAXSMP, there was a bug
> > for that fixed in 2.6.39 time-frame (I think). And if you look
> > at the NR_CPUS, do you see the NR_CPUs > 0 virtual_cpus?

Any progress on the question above?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 01:27:00 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 01:27:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rb05P-0004XU-QT; Thu, 15 Dec 2011 01:26:15 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.r.wilk@gmail.com>) id 1Rb05N-0004XP-SY
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 01:26:14 +0000
X-Env-Sender: konrad.r.wilk@gmail.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1323912316!7312529!1
X-Originating-IP: [209.85.216.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29347 invoked from network); 15 Dec 2011 01:25:17 -0000
Received: from mail-qy0-f171.google.com (HELO mail-qy0-f171.google.com)
	(209.85.216.171)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 01:25:17 -0000
Received: by qcsc20 with SMTP id c20so9458352qcs.30
	for <xen-devel@lists.xensource.com>;
	Wed, 14 Dec 2011 17:25:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:date:from:to:cc:subject:message-id:references:mime-version
	:content-type:content-disposition:in-reply-to:user-agent;
	bh=nxK6nXfE4f+zUTAxGZQHmtCM5D0TQzlD/kTCioV/tfo=;
	b=OqNome+hze3AUB8iTQFYMt6P+UCxoNi5VoD0AEmo+Lc0W+L2di2HB5vtsNnhKrrvqf
	VqbW0KVGx+iP18rrgEB6oT/nbh916DFjaJZcyZChOcf2RZNsxTvVUbsGRPqn0r3m6reV
	k+du9/XoObb8mVQZUOj3LrXdibr+UE3WH6LRA=
Received: by 10.224.42.134 with SMTP id s6mr1859696qae.78.1323912316016;
	Wed, 14 Dec 2011 17:25:16 -0800 (PST)
Received: from konrad-lan (209-6-85-33.c3-0.smr-ubr2.sbo-smr.ma.cable.rcn.com.
	[209.6.85.33])
	by mx.google.com with ESMTPS id cd3sm9412004qab.5.2011.12.14.17.25.14
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 14 Dec 2011 17:25:15 -0800 (PST)
Date: Wed, 14 Dec 2011 20:25:12 -0500
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Tim Evers <it@niemail.de>
Message-ID: <20111215012511.GC10268@konrad-lan>
References: <4EE675A8.3030609@niemail.de>
	<20111212215652.GA12106@andromeda.dapyr.net>
	<4EE86598.2060905@niemail.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4EE86598.2060905@niemail.de>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] a ton of kernel issues
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> > Looking at your BUG, did you look in the .config to see if you
> > had MAXSMP or NR_CPUS defined? If you had MAXSMP, there was a bug
> > for that fixed in 2.6.39 time-frame (I think). And if you look
> > at the NR_CPUS, do you see the NR_CPUs > 0 virtual_cpus?

Any progress on the question above?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 02:01:26 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 02:01:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rb0cq-0005Lm-Py; Thu, 15 Dec 2011 02:00:48 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.r.wilk@gmail.com>) id 1Rb0co-0005Ku-W9
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 02:00:47 +0000
X-Env-Sender: konrad.r.wilk@gmail.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1323914389!7496300!1
X-Originating-IP: [209.85.216.50]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18563 invoked from network); 15 Dec 2011 01:59:50 -0000
Received: from mail-qw0-f50.google.com (HELO mail-qw0-f50.google.com)
	(209.85.216.50)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 01:59:50 -0000
Received: by qaea17 with SMTP id a17so4387795qae.9
	for <xen-devel@lists.xensource.com>;
	Wed, 14 Dec 2011 17:59:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:date:from:to:cc:subject:message-id:references:mime-version
	:content-type:content-disposition:in-reply-to:user-agent;
	bh=QNaYqLXWFNHBFGEOJ42ZsMnA7xgILqRYg4JjqUXNdEY=;
	b=FXH0ClYanLPP6eY+dkF/IIVPhYHwlHrQSbr6ew1wH8AwUd429mLMCmhLru2rR8p7vo
	hqrr7+qTVZiOFvR25PebyDMfWsZm+8WIN/d78lU2WckDneUF8uHdceKx8Ef6lEAMxXdu
	xjtcIJp+MjRmsbcGskHgEFnPkeAiXO49d54hM=
Received: by 10.224.186.72 with SMTP id cr8mr1765314qab.95.1323914389409;
	Wed, 14 Dec 2011 17:59:49 -0800 (PST)
Received: from konrad-lan (209-6-85-33.c3-0.smr-ubr2.sbo-smr.ma.cable.rcn.com.
	[209.6.85.33])
	by mx.google.com with ESMTPS id el7sm9548783qab.16.2011.12.14.17.59.48
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 14 Dec 2011 17:59:48 -0800 (PST)
Date: Wed, 14 Dec 2011 20:59:45 -0500
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: "Kalev, Leonid" <Leonid.Kalev@ca.com>, konrad.wilk@oracle.com
Message-ID: <20111215015944.GD10268@konrad-lan>
References: <3E243B26F475504B9BB0BCC9728B0DA629E16E01@USILMS110A.ca.com>
	<20111209203010.GA14412@andromeda.dapyr.net>
	<3E243B26F475504B9BB0BCC9728B0DA629E17AEA@USILMS110A.ca.com>
	<20111213001912.GA2730@konrad-lan>
	<3E243B26F475504B9BB0BCC9728B0DA629E184FA@USILMS110A.ca.com>
	<20111213232759.GA8702@konrad-lan>
	<3E243B26F475504B9BB0BCC9728B0DA629E18564@USILMS110A.ca.com>
	<4EE8785A0200007800067A16@nat28.tlf.novell.com>
	<3E243B26F475504B9BB0BCC9728B0DA629E18A6B@USILMS110A.ca.com>
	<4EE8EDF5.5070800@ca.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4EE8EDF5.5070800@ca.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: xen-devel <xen-devel@lists.xensource.com>, Jan Beulich <JBeulich@suse.com>,
	Tushar N Dave <tushar.n.dave@intel.com>
Subject: Re: [Xen-devel] Buffers not reachable by PCI
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Dec 14, 2011 at 06:42:07PM +0000, Kalev, Leonid wrote:
> On 12/14/2011 06:42 PM, Taylor, Neal E wrote:
> > The last quoted printout is calculated the same way as the test that fails which leads me to question the computation's validity.
> 
> The computation validity seems OK to me (the 'phys' address is, as correctly stated 
> in the comments, not suitable for DMA, but it is first translated via 
> xen_phys_to_bus, which gives the machine address - and on x86 that is also the bus 
> address)
> 
> I have a STUPID question, though: why are the start and end addresses of the swiotlb 
> memory area not page-aligned???

That is not a stupid question.
> 
> The io_tlb_end address is one byte PAST the valid area, which is why the 
> xen_swiotlb_dma_supported function uses (xen_io_tlb_end-1). However, this will work 
> properly only if the value is page-aligned. If it isn't, then decrementing it by one 
> will keep the value in the same page (which is one page past the last valid one).
> 
> The function that allocates the memory uses alloc_bootmem(), which provides just 
> cache-aligned memory (not page-aligned).

Yup.

It is actually funny (sad?), b/c I am the committer for the
e79f86b2ef9c0a8c47225217c1018b7d3d90101c which adds something like this:

 alloc_bootmem_pages(PAGE_ALIGN(io_tlb_nslabs * sizeof(int)

in the swiotlb code but I completly missed doing it for the Xen SWIOTLB.

<sigh>

I think this patch:

>From 47409eecc08effe20fc4aa0da899dd6ac475cb0b Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Wed, 14 Dec 2011 20:48:01 -0500
Subject: [PATCH] xen/swiotlb: Use page alignment for early buffer allocation.

This piggybacks on git commit e79f86b2ef9c0a8c47225217c1018b7d3d90101c
"swiotlb: Use page alignment for early buffer allocation" which:

"We could call free_bootmem_late() if swiotlb is not used, and
it will shrink to page alignment.

So alloc them with page alignment at first, to avoid lose two pages"

Reported-by: "Kalev, Leonid" <Leonid.Kalev@ca.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 drivers/xen/swiotlb-xen.c |    5 +++--
 1 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index 8e964b9..5c8e445 100644
--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -166,7 +166,8 @@ retry:
 	/*
 	 * Get IO TLB memory from any location.
 	 */
-	xen_io_tlb_start = alloc_bootmem(bytes);
+	xen_io_tlb_start = alloc_bootmem_pages(PAGE_ALIGN(bytes));
+
 	if (!xen_io_tlb_start) {
 		m = "Cannot allocate Xen-SWIOTLB buffer!\n";
 		goto error;
@@ -179,7 +180,7 @@ retry:
 			       bytes,
 			       xen_io_tlb_nslabs);
 	if (rc) {
-		free_bootmem(__pa(xen_io_tlb_start), bytes);
+		free_bootmem(__pa(xen_io_tlb_start), PAGE_ALIGN(bytes));
 		m = "Failed to get contiguous memory for DMA from Xen!\n"\
 		    "You either: don't have the permissions, do not have"\
 		    " enough free memory under 4GB, or the hypervisor memory"\
-- 
1.7.1

is in order.
> 
> If it is OK for the swiotlb area not to be page-aligned, then the 
> xen_swiotlb_dma_supported should use (xen_io_tlb_end - (PAGE_SIZE-1))

Lets make it page aligned.

> 
> If the memory should be in fact aligned, then the allocation must be changed to 
> alloc_bootmem_pages() (which is the same as alloc_bootmem, but page-aligned).

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 02:01:26 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 02:01:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rb0cq-0005Lm-Py; Thu, 15 Dec 2011 02:00:48 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.r.wilk@gmail.com>) id 1Rb0co-0005Ku-W9
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 02:00:47 +0000
X-Env-Sender: konrad.r.wilk@gmail.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1323914389!7496300!1
X-Originating-IP: [209.85.216.50]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18563 invoked from network); 15 Dec 2011 01:59:50 -0000
Received: from mail-qw0-f50.google.com (HELO mail-qw0-f50.google.com)
	(209.85.216.50)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 01:59:50 -0000
Received: by qaea17 with SMTP id a17so4387795qae.9
	for <xen-devel@lists.xensource.com>;
	Wed, 14 Dec 2011 17:59:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:date:from:to:cc:subject:message-id:references:mime-version
	:content-type:content-disposition:in-reply-to:user-agent;
	bh=QNaYqLXWFNHBFGEOJ42ZsMnA7xgILqRYg4JjqUXNdEY=;
	b=FXH0ClYanLPP6eY+dkF/IIVPhYHwlHrQSbr6ew1wH8AwUd429mLMCmhLru2rR8p7vo
	hqrr7+qTVZiOFvR25PebyDMfWsZm+8WIN/d78lU2WckDneUF8uHdceKx8Ef6lEAMxXdu
	xjtcIJp+MjRmsbcGskHgEFnPkeAiXO49d54hM=
Received: by 10.224.186.72 with SMTP id cr8mr1765314qab.95.1323914389409;
	Wed, 14 Dec 2011 17:59:49 -0800 (PST)
Received: from konrad-lan (209-6-85-33.c3-0.smr-ubr2.sbo-smr.ma.cable.rcn.com.
	[209.6.85.33])
	by mx.google.com with ESMTPS id el7sm9548783qab.16.2011.12.14.17.59.48
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 14 Dec 2011 17:59:48 -0800 (PST)
Date: Wed, 14 Dec 2011 20:59:45 -0500
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: "Kalev, Leonid" <Leonid.Kalev@ca.com>, konrad.wilk@oracle.com
Message-ID: <20111215015944.GD10268@konrad-lan>
References: <3E243B26F475504B9BB0BCC9728B0DA629E16E01@USILMS110A.ca.com>
	<20111209203010.GA14412@andromeda.dapyr.net>
	<3E243B26F475504B9BB0BCC9728B0DA629E17AEA@USILMS110A.ca.com>
	<20111213001912.GA2730@konrad-lan>
	<3E243B26F475504B9BB0BCC9728B0DA629E184FA@USILMS110A.ca.com>
	<20111213232759.GA8702@konrad-lan>
	<3E243B26F475504B9BB0BCC9728B0DA629E18564@USILMS110A.ca.com>
	<4EE8785A0200007800067A16@nat28.tlf.novell.com>
	<3E243B26F475504B9BB0BCC9728B0DA629E18A6B@USILMS110A.ca.com>
	<4EE8EDF5.5070800@ca.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4EE8EDF5.5070800@ca.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: xen-devel <xen-devel@lists.xensource.com>, Jan Beulich <JBeulich@suse.com>,
	Tushar N Dave <tushar.n.dave@intel.com>
Subject: Re: [Xen-devel] Buffers not reachable by PCI
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Dec 14, 2011 at 06:42:07PM +0000, Kalev, Leonid wrote:
> On 12/14/2011 06:42 PM, Taylor, Neal E wrote:
> > The last quoted printout is calculated the same way as the test that fails which leads me to question the computation's validity.
> 
> The computation validity seems OK to me (the 'phys' address is, as correctly stated 
> in the comments, not suitable for DMA, but it is first translated via 
> xen_phys_to_bus, which gives the machine address - and on x86 that is also the bus 
> address)
> 
> I have a STUPID question, though: why are the start and end addresses of the swiotlb 
> memory area not page-aligned???

That is not a stupid question.
> 
> The io_tlb_end address is one byte PAST the valid area, which is why the 
> xen_swiotlb_dma_supported function uses (xen_io_tlb_end-1). However, this will work 
> properly only if the value is page-aligned. If it isn't, then decrementing it by one 
> will keep the value in the same page (which is one page past the last valid one).
> 
> The function that allocates the memory uses alloc_bootmem(), which provides just 
> cache-aligned memory (not page-aligned).

Yup.

It is actually funny (sad?), b/c I am the committer for the
e79f86b2ef9c0a8c47225217c1018b7d3d90101c which adds something like this:

 alloc_bootmem_pages(PAGE_ALIGN(io_tlb_nslabs * sizeof(int)

in the swiotlb code but I completly missed doing it for the Xen SWIOTLB.

<sigh>

I think this patch:

>From 47409eecc08effe20fc4aa0da899dd6ac475cb0b Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Wed, 14 Dec 2011 20:48:01 -0500
Subject: [PATCH] xen/swiotlb: Use page alignment for early buffer allocation.

This piggybacks on git commit e79f86b2ef9c0a8c47225217c1018b7d3d90101c
"swiotlb: Use page alignment for early buffer allocation" which:

"We could call free_bootmem_late() if swiotlb is not used, and
it will shrink to page alignment.

So alloc them with page alignment at first, to avoid lose two pages"

Reported-by: "Kalev, Leonid" <Leonid.Kalev@ca.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 drivers/xen/swiotlb-xen.c |    5 +++--
 1 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index 8e964b9..5c8e445 100644
--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -166,7 +166,8 @@ retry:
 	/*
 	 * Get IO TLB memory from any location.
 	 */
-	xen_io_tlb_start = alloc_bootmem(bytes);
+	xen_io_tlb_start = alloc_bootmem_pages(PAGE_ALIGN(bytes));
+
 	if (!xen_io_tlb_start) {
 		m = "Cannot allocate Xen-SWIOTLB buffer!\n";
 		goto error;
@@ -179,7 +180,7 @@ retry:
 			       bytes,
 			       xen_io_tlb_nslabs);
 	if (rc) {
-		free_bootmem(__pa(xen_io_tlb_start), bytes);
+		free_bootmem(__pa(xen_io_tlb_start), PAGE_ALIGN(bytes));
 		m = "Failed to get contiguous memory for DMA from Xen!\n"\
 		    "You either: don't have the permissions, do not have"\
 		    " enough free memory under 4GB, or the hypervisor memory"\
-- 
1.7.1

is in order.
> 
> If it is OK for the swiotlb area not to be page-aligned, then the 
> xen_swiotlb_dma_supported should use (xen_io_tlb_end - (PAGE_SIZE-1))

Lets make it page aligned.

> 
> If the memory should be in fact aligned, then the allocation must be changed to 
> alloc_bootmem_pages() (which is the same as alloc_bootmem, but page-aligned).

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 02:17:54 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 02: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.xensource.com>)
	id 1Rb0sr-0005hp-FD; Thu, 15 Dec 2011 02:17:21 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Neal.Taylor@ca.com>) id 1Rb0sp-0005hk-IV
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 02:17:19 +0000
X-Env-Sender: Neal.Taylor@ca.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1323915343!50665901!1
X-Originating-IP: [74.125.149.246]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30269 invoked from network); 15 Dec 2011 02:15:45 -0000
Received: from na3sys009aog119.obsmtp.com (HELO na3sys009aog119.obsmtp.com)
	(74.125.149.246)
	by server-6.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 15 Dec 2011 02:15:45 -0000
Received: from USILMS190.ca.com ([141.202.246.44]) (using TLSv1) by
	na3sys009aob119.postini.com ([74.125.148.12]) with SMTP
	ID DSNKTulYdlALLhBbfOpw4GsYvYutQ14B3mtj@postini.com;
	Wed, 14 Dec 2011 18:16:24 PST
Received: from USILMS172.ca.com (141.202.6.22) by USILMS190.ca.com
	(141.202.246.44) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Wed, 14 Dec 2011 21:16:21 -0500
Received: from USILMS110A.ca.com ([169.254.1.109]) by USILMS172.ca.com
	([141.202.6.22]) with mapi id 14.01.0289.001;
	Wed, 14 Dec 2011 21:16:21 -0500
From: "Taylor, Neal E" <Neal.Taylor@ca.com>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>, Jan Beulich <JBeulich@suse.com>
Thread-Topic: [Xen-devel] Buffers not reachable by PCI
Thread-Index: Acy2r+Ulg1PsfbmtTl6QVj0jZAx7mwAK1xcAAIXl/sAAGPmvgAAhEiCwAA9ukQAACILlsAAMK30AAALQl/AAEM4lgAAEj1pg
Date: Thu, 15 Dec 2011 02:16:20 +0000
Message-ID: <3E243B26F475504B9BB0BCC9728B0DA629E18EB1@USILMS110A.ca.com>
References: <3E243B26F475504B9BB0BCC9728B0DA629E16E01@USILMS110A.ca.com>
	<20111209203010.GA14412@andromeda.dapyr.net>
	<3E243B26F475504B9BB0BCC9728B0DA629E17AEA@USILMS110A.ca.com>
	<20111213001912.GA2730@konrad-lan>
	<3E243B26F475504B9BB0BCC9728B0DA629E184FA@USILMS110A.ca.com>
	<20111213232759.GA8702@konrad-lan>
	<3E243B26F475504B9BB0BCC9728B0DA629E18564@USILMS110A.ca.com>
	<4EE8785A0200007800067A16@nat28.tlf.novell.com>
	<3E243B26F475504B9BB0BCC9728B0DA629E18A6B@USILMS110A.ca.com>
	<4EE8EDF5.5070800@ca.com>
In-Reply-To: <4EE8EDF5.5070800@ca.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [138.42.46.105]
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>, "Kalev,
	Leonid" <Leonid.Kalev@ca.com>, Tushar N Dave <tushar.n.dave@intel.com>
Subject: Re: [Xen-devel] Buffers not reachable by PCI
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At Leonid's suggestion (and provision of a patch) I tried it with page aligned memory and it works. Is this "the" real solution or just a change that happens to make things work for the case I have?  The patch I used is:

--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -162,7 +162,7 @@
        /*
         * Get IO TLB memory from any location.
         */
-       xen_io_tlb_start = alloc_bootmem(bytes);
+       xen_io_tlb_start = alloc_bootmem_pages(bytes);
        if (!xen_io_tlb_start)
                panic("Cannot allocate SWIOTLB buffer");

The test that was failing now passes: finding the "bus" address of 7f3ffff to be within a 32-bit mask and the last few MFN entries are:
[    0.000000] MFN 0x20ff->0x2080
[    0.000000] MFN 0x20bf->0x2040
[    0.000000] MFN 0x207f->0x2000
[    0.000000] MFN 0x203f->0x7fc0
[    0.000000] MFN 0x7fff->0x7f80
[    0.000000] MFN 0x7fbf->0x7f40
[    0.000000] MFN 0x7f7f->0x7f00
[    0.000000] Placing 64MB software IO TLB between d832c000 - dc32c000
[    0.000000] software IO TLB at phys 0x1832c000 - 0x1c32c000
[    0.000000] software IO TLB at bus 0x1c0000 - 0x120fdf000

(This last address, 0x120fdf000, hasn't been through the final "phys_to_machine" translation. My error. Sorry.)

Neal


-----Original Message-----
From: Kalev, Leonid 
Sent: Wednesday, December 14, 2011 10:42 AM
To: Taylor, Neal E
Cc: Jan Beulich; Konrad Rzeszutek Wilk; Tushar N Dave; xen-devel
Subject: Re: [Xen-devel] Buffers not reachable by PCI

On 12/14/2011 06:42 PM, Taylor, Neal E wrote:
> The last quoted printout is calculated the same way as the test that fails which leads me to question the computation's validity.

The computation validity seems OK to me (the 'phys' address is, as correctly stated 
in the comments, not suitable for DMA, but it is first translated via 
xen_phys_to_bus, which gives the machine address - and on x86 that is also the bus 
address)

I have a STUPID question, though: why are the start and end addresses of the swiotlb 
memory area not page-aligned???

The io_tlb_end address is one byte PAST the valid area, which is why the 
xen_swiotlb_dma_supported function uses (xen_io_tlb_end-1). However, this will work 
properly only if the value is page-aligned. If it isn't, then decrementing it by one 
will keep the value in the same page (which is one page past the last valid one).

The function that allocates the memory uses alloc_bootmem(), which provides just 
cache-aligned memory (not page-aligned).

If it is OK for the swiotlb area not to be page-aligned, then the 
xen_swiotlb_dma_supported should use (xen_io_tlb_end - (PAGE_SIZE-1))

If the memory should be in fact aligned, then the allocation must be changed to 
alloc_bootmem_pages() (which is the same as alloc_bootmem, but page-aligned).


>
> The test that fails is (from drivers/xen/swiotlb-xen.c):
> xen_swiotlb_dma_supported(struct device *hwdev, u64 mask)
> {
>          return xen_virt_to_bus(xen_io_tlb_end - 1)<= mask;
> }
>
>
> "xen_virt_to_bus" in turn:
> static dma_addr_t xen_virt_to_bus(void *address)
> {
>          return xen_phys_to_bus(virt_to_phys(address));
> }
>
>
> Now, "virt_to_phys" (out of arch/x86/include/asm/io.h) is defined as follows but carries a comment bothersome to this usage of it as we're, basically, dealing with a dma "transfer" and calling from a device driver:
> /**
>   *      virt_to_phys    -       map virtual addresses to physical
>   *      @address: address to remap
>   *
>   *      The returned physical address is the physical (CPU) mapping for
>   *      the memory address given. It is only valid to use this function on
>   *      addresses directly mapped or allocated via kmalloc.
>   *
>   *      This function does not give bus mappings for DMA transfers. In
>   *      almost all conceivable cases a device driver should not be using
>   *      this function
>   */
> static inline phys_addr_t virt_to_phys(volatile void *address)
> {
>          return __pa(address);
> }
>
>
> Going a couple of steps further, "__pa" is defined (in arch/x86/include/asm/page.h) as:
> #define __pa(x)         __phys_addr((unsigned long)(x))
>
>
> and "__phys_addr" (in arch/x86/mm/physaddr.c) as:
> unsigned long __phys_addr(unsigned long x)
> {
>          if (x>= __START_KERNEL_map) {
>                  x -= __START_KERNEL_map;
>                  VIRTUAL_BUG_ON(x>= KERNEL_IMAGE_SIZE);
>                  x += phys_base;
>          } else {
>                  VIRTUAL_BUG_ON(x<  PAGE_OFFSET);
>                  x -= PAGE_OFFSET;
>                  VIRTUAL_BUG_ON(!phys_addr_valid(x));
>          }
>          return x;
> }
> EXPORT_SYMBOL(__phys_addr);
>
>
> So, if "virt_to_phys" isn't yielding a valid test of whether addresses will be reachable from a PCI device, what's the correct way to test it and should xen_swiotlb_dma_supported be updated to the correct way (I think so) or a new function be created?
>
> Neal
>
>
> -----Original Message-----
> From: Jan Beulich [mailto:JBeulich@suse.com]
> Sent: Wednesday, December 14, 2011 1:20 AM
> To: Taylor, Neal E
> Cc: Kalev, Leonid; Konrad Rzeszutek Wilk; Tushar N Dave; xen-devel
> Subject: Re: [Xen-devel] Buffers not reachable by PCI
>
>>>> On 14.12.11 at 01:38, "Taylor, Neal E"<Neal.Taylor@ca.com>  wrote:
>> [    0.000000] MFN 0x7f7f->0x7f00
>
> This is clearly indicating the last chunk ends well below the 4G boundary.
>
>> [    0.000000] Placing 64MB software IO TLB between d832cf00 - dc32cf00
>> [    0.000000] software IO TLB at phys 0x1832cf00 - 0x1c32cf00
>> [    0.000000] software IO TLB at bus 0x1c0f00 - 0x120fdff00
>
> Consequently, the question is how you got to this value, or what
> changed between the first and last quoted printouts.
>
> Jan
>


-- 
Leonid Kalev
CA Technologies
Principal Software Engineer
Tel:     +972 4 825 3952
Mobile:  +972 54 4631508
Leonid.Kalev@ca.com

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 02:17:54 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 02: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.xensource.com>)
	id 1Rb0sr-0005hp-FD; Thu, 15 Dec 2011 02:17:21 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Neal.Taylor@ca.com>) id 1Rb0sp-0005hk-IV
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 02:17:19 +0000
X-Env-Sender: Neal.Taylor@ca.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1323915343!50665901!1
X-Originating-IP: [74.125.149.246]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30269 invoked from network); 15 Dec 2011 02:15:45 -0000
Received: from na3sys009aog119.obsmtp.com (HELO na3sys009aog119.obsmtp.com)
	(74.125.149.246)
	by server-6.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 15 Dec 2011 02:15:45 -0000
Received: from USILMS190.ca.com ([141.202.246.44]) (using TLSv1) by
	na3sys009aob119.postini.com ([74.125.148.12]) with SMTP
	ID DSNKTulYdlALLhBbfOpw4GsYvYutQ14B3mtj@postini.com;
	Wed, 14 Dec 2011 18:16:24 PST
Received: from USILMS172.ca.com (141.202.6.22) by USILMS190.ca.com
	(141.202.246.44) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Wed, 14 Dec 2011 21:16:21 -0500
Received: from USILMS110A.ca.com ([169.254.1.109]) by USILMS172.ca.com
	([141.202.6.22]) with mapi id 14.01.0289.001;
	Wed, 14 Dec 2011 21:16:21 -0500
From: "Taylor, Neal E" <Neal.Taylor@ca.com>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>, Jan Beulich <JBeulich@suse.com>
Thread-Topic: [Xen-devel] Buffers not reachable by PCI
Thread-Index: Acy2r+Ulg1PsfbmtTl6QVj0jZAx7mwAK1xcAAIXl/sAAGPmvgAAhEiCwAA9ukQAACILlsAAMK30AAALQl/AAEM4lgAAEj1pg
Date: Thu, 15 Dec 2011 02:16:20 +0000
Message-ID: <3E243B26F475504B9BB0BCC9728B0DA629E18EB1@USILMS110A.ca.com>
References: <3E243B26F475504B9BB0BCC9728B0DA629E16E01@USILMS110A.ca.com>
	<20111209203010.GA14412@andromeda.dapyr.net>
	<3E243B26F475504B9BB0BCC9728B0DA629E17AEA@USILMS110A.ca.com>
	<20111213001912.GA2730@konrad-lan>
	<3E243B26F475504B9BB0BCC9728B0DA629E184FA@USILMS110A.ca.com>
	<20111213232759.GA8702@konrad-lan>
	<3E243B26F475504B9BB0BCC9728B0DA629E18564@USILMS110A.ca.com>
	<4EE8785A0200007800067A16@nat28.tlf.novell.com>
	<3E243B26F475504B9BB0BCC9728B0DA629E18A6B@USILMS110A.ca.com>
	<4EE8EDF5.5070800@ca.com>
In-Reply-To: <4EE8EDF5.5070800@ca.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [138.42.46.105]
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>, "Kalev,
	Leonid" <Leonid.Kalev@ca.com>, Tushar N Dave <tushar.n.dave@intel.com>
Subject: Re: [Xen-devel] Buffers not reachable by PCI
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At Leonid's suggestion (and provision of a patch) I tried it with page aligned memory and it works. Is this "the" real solution or just a change that happens to make things work for the case I have?  The patch I used is:

--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -162,7 +162,7 @@
        /*
         * Get IO TLB memory from any location.
         */
-       xen_io_tlb_start = alloc_bootmem(bytes);
+       xen_io_tlb_start = alloc_bootmem_pages(bytes);
        if (!xen_io_tlb_start)
                panic("Cannot allocate SWIOTLB buffer");

The test that was failing now passes: finding the "bus" address of 7f3ffff to be within a 32-bit mask and the last few MFN entries are:
[    0.000000] MFN 0x20ff->0x2080
[    0.000000] MFN 0x20bf->0x2040
[    0.000000] MFN 0x207f->0x2000
[    0.000000] MFN 0x203f->0x7fc0
[    0.000000] MFN 0x7fff->0x7f80
[    0.000000] MFN 0x7fbf->0x7f40
[    0.000000] MFN 0x7f7f->0x7f00
[    0.000000] Placing 64MB software IO TLB between d832c000 - dc32c000
[    0.000000] software IO TLB at phys 0x1832c000 - 0x1c32c000
[    0.000000] software IO TLB at bus 0x1c0000 - 0x120fdf000

(This last address, 0x120fdf000, hasn't been through the final "phys_to_machine" translation. My error. Sorry.)

Neal


-----Original Message-----
From: Kalev, Leonid 
Sent: Wednesday, December 14, 2011 10:42 AM
To: Taylor, Neal E
Cc: Jan Beulich; Konrad Rzeszutek Wilk; Tushar N Dave; xen-devel
Subject: Re: [Xen-devel] Buffers not reachable by PCI

On 12/14/2011 06:42 PM, Taylor, Neal E wrote:
> The last quoted printout is calculated the same way as the test that fails which leads me to question the computation's validity.

The computation validity seems OK to me (the 'phys' address is, as correctly stated 
in the comments, not suitable for DMA, but it is first translated via 
xen_phys_to_bus, which gives the machine address - and on x86 that is also the bus 
address)

I have a STUPID question, though: why are the start and end addresses of the swiotlb 
memory area not page-aligned???

The io_tlb_end address is one byte PAST the valid area, which is why the 
xen_swiotlb_dma_supported function uses (xen_io_tlb_end-1). However, this will work 
properly only if the value is page-aligned. If it isn't, then decrementing it by one 
will keep the value in the same page (which is one page past the last valid one).

The function that allocates the memory uses alloc_bootmem(), which provides just 
cache-aligned memory (not page-aligned).

If it is OK for the swiotlb area not to be page-aligned, then the 
xen_swiotlb_dma_supported should use (xen_io_tlb_end - (PAGE_SIZE-1))

If the memory should be in fact aligned, then the allocation must be changed to 
alloc_bootmem_pages() (which is the same as alloc_bootmem, but page-aligned).


>
> The test that fails is (from drivers/xen/swiotlb-xen.c):
> xen_swiotlb_dma_supported(struct device *hwdev, u64 mask)
> {
>          return xen_virt_to_bus(xen_io_tlb_end - 1)<= mask;
> }
>
>
> "xen_virt_to_bus" in turn:
> static dma_addr_t xen_virt_to_bus(void *address)
> {
>          return xen_phys_to_bus(virt_to_phys(address));
> }
>
>
> Now, "virt_to_phys" (out of arch/x86/include/asm/io.h) is defined as follows but carries a comment bothersome to this usage of it as we're, basically, dealing with a dma "transfer" and calling from a device driver:
> /**
>   *      virt_to_phys    -       map virtual addresses to physical
>   *      @address: address to remap
>   *
>   *      The returned physical address is the physical (CPU) mapping for
>   *      the memory address given. It is only valid to use this function on
>   *      addresses directly mapped or allocated via kmalloc.
>   *
>   *      This function does not give bus mappings for DMA transfers. In
>   *      almost all conceivable cases a device driver should not be using
>   *      this function
>   */
> static inline phys_addr_t virt_to_phys(volatile void *address)
> {
>          return __pa(address);
> }
>
>
> Going a couple of steps further, "__pa" is defined (in arch/x86/include/asm/page.h) as:
> #define __pa(x)         __phys_addr((unsigned long)(x))
>
>
> and "__phys_addr" (in arch/x86/mm/physaddr.c) as:
> unsigned long __phys_addr(unsigned long x)
> {
>          if (x>= __START_KERNEL_map) {
>                  x -= __START_KERNEL_map;
>                  VIRTUAL_BUG_ON(x>= KERNEL_IMAGE_SIZE);
>                  x += phys_base;
>          } else {
>                  VIRTUAL_BUG_ON(x<  PAGE_OFFSET);
>                  x -= PAGE_OFFSET;
>                  VIRTUAL_BUG_ON(!phys_addr_valid(x));
>          }
>          return x;
> }
> EXPORT_SYMBOL(__phys_addr);
>
>
> So, if "virt_to_phys" isn't yielding a valid test of whether addresses will be reachable from a PCI device, what's the correct way to test it and should xen_swiotlb_dma_supported be updated to the correct way (I think so) or a new function be created?
>
> Neal
>
>
> -----Original Message-----
> From: Jan Beulich [mailto:JBeulich@suse.com]
> Sent: Wednesday, December 14, 2011 1:20 AM
> To: Taylor, Neal E
> Cc: Kalev, Leonid; Konrad Rzeszutek Wilk; Tushar N Dave; xen-devel
> Subject: Re: [Xen-devel] Buffers not reachable by PCI
>
>>>> On 14.12.11 at 01:38, "Taylor, Neal E"<Neal.Taylor@ca.com>  wrote:
>> [    0.000000] MFN 0x7f7f->0x7f00
>
> This is clearly indicating the last chunk ends well below the 4G boundary.
>
>> [    0.000000] Placing 64MB software IO TLB between d832cf00 - dc32cf00
>> [    0.000000] software IO TLB at phys 0x1832cf00 - 0x1c32cf00
>> [    0.000000] software IO TLB at bus 0x1c0f00 - 0x120fdff00
>
> Consequently, the question is how you got to this value, or what
> changed between the first and last quoted printouts.
>
> Jan
>


-- 
Leonid Kalev
CA Technologies
Principal Software Engineer
Tel:     +972 4 825 3952
Mobile:  +972 54 4631508
Leonid.Kalev@ca.com

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 02:21:45 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 02: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.xensource.com>)
	id 1Rb0wM-0005qI-9n; Thu, 15 Dec 2011 02:20:58 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Neal.Taylor@ca.com>) id 1Rb0wK-0005q7-SF
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 02:20:57 +0000
X-Env-Sender: Neal.Taylor@ca.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1323915597!5610666!1
X-Originating-IP: [74.125.149.151]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18181 invoked from network); 15 Dec 2011 02:20:00 -0000
Received: from na3sys009aog124.obsmtp.com (HELO na3sys009aog124.obsmtp.com)
	(74.125.149.151)
	by server-6.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 15 Dec 2011 02:20:00 -0000
Received: from USILMS191.ca.com ([141.202.246.45]) (using TLSv1) by
	na3sys009aob124.postini.com ([74.125.148.12]) with SMTP
	ID DSNKTulZTWPulQmT0QP0tB55ihIO5Nv/xJ4K@postini.com;
	Wed, 14 Dec 2011 18:19:59 PST
Received: from USILMS175.ca.com (141.202.6.25) by USILMS191.ca.com
	(141.202.246.45) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Wed, 14 Dec 2011 21:19:56 -0500
Received: from USILMS110A.ca.com ([169.254.1.109]) by usilms175.ca.com
	([141.202.6.25]) with mapi id 14.01.0289.001;
	Wed, 14 Dec 2011 21:19:56 -0500
From: "Taylor, Neal E" <Neal.Taylor@ca.com>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>, "Kalev, Leonid"
	<Leonid.Kalev@ca.com>, "konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
Thread-Topic: [Xen-devel] Buffers not reachable by PCI
Thread-Index: Acy2r+Ulg1PsfbmtTl6QVj0jZAx7mwAK1xcAAIXl/sAAGPmvgAAhEiCwAA9ukQAACILlsAAMK30AAALQl/AAEM4lgAAPSjyAAAnO0KA=
Date: Thu, 15 Dec 2011 02:19:55 +0000
Message-ID: <3E243B26F475504B9BB0BCC9728B0DA629E18EBF@USILMS110A.ca.com>
References: <3E243B26F475504B9BB0BCC9728B0DA629E16E01@USILMS110A.ca.com>
	<20111209203010.GA14412@andromeda.dapyr.net>
	<3E243B26F475504B9BB0BCC9728B0DA629E17AEA@USILMS110A.ca.com>
	<20111213001912.GA2730@konrad-lan>
	<3E243B26F475504B9BB0BCC9728B0DA629E184FA@USILMS110A.ca.com>
	<20111213232759.GA8702@konrad-lan>
	<3E243B26F475504B9BB0BCC9728B0DA629E18564@USILMS110A.ca.com>
	<4EE8785A0200007800067A16@nat28.tlf.novell.com>
	<3E243B26F475504B9BB0BCC9728B0DA629E18A6B@USILMS110A.ca.com>
	<4EE8EDF5.5070800@ca.com> <20111215015944.GD10268@konrad-lan>
In-Reply-To: <20111215015944.GD10268@konrad-lan>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [138.42.46.105]
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>,
	Tushar N Dave <tushar.n.dave@intel.com>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] Buffers not reachable by PCI
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Missed this when I was composing the previous e-mail. Your answer is here. Thank you.

Neal

-----Original Message-----
From: Konrad Rzeszutek Wilk [mailto:konrad.r.wilk@gmail.com] On Behalf Of Konrad Rzeszutek Wilk
Sent: Wednesday, December 14, 2011 6:00 PM
To: Kalev, Leonid; konrad.wilk@oracle.com
Cc: Taylor, Neal E; Jan Beulich; Tushar N Dave; xen-devel
Subject: Re: [Xen-devel] Buffers not reachable by PCI

On Wed, Dec 14, 2011 at 06:42:07PM +0000, Kalev, Leonid wrote:
> On 12/14/2011 06:42 PM, Taylor, Neal E wrote:
> > The last quoted printout is calculated the same way as the test that fails which leads me to question the computation's validity.
> 
> The computation validity seems OK to me (the 'phys' address is, as correctly stated 
> in the comments, not suitable for DMA, but it is first translated via 
> xen_phys_to_bus, which gives the machine address - and on x86 that is also the bus 
> address)
> 
> I have a STUPID question, though: why are the start and end addresses of the swiotlb 
> memory area not page-aligned???

That is not a stupid question.
> 
> The io_tlb_end address is one byte PAST the valid area, which is why the 
> xen_swiotlb_dma_supported function uses (xen_io_tlb_end-1). However, this will work 
> properly only if the value is page-aligned. If it isn't, then decrementing it by one 
> will keep the value in the same page (which is one page past the last valid one).
> 
> The function that allocates the memory uses alloc_bootmem(), which provides just 
> cache-aligned memory (not page-aligned).

Yup.

It is actually funny (sad?), b/c I am the committer for the
e79f86b2ef9c0a8c47225217c1018b7d3d90101c which adds something like this:

 alloc_bootmem_pages(PAGE_ALIGN(io_tlb_nslabs * sizeof(int)

in the swiotlb code but I completly missed doing it for the Xen SWIOTLB.

<sigh>

I think this patch:

>From 47409eecc08effe20fc4aa0da899dd6ac475cb0b Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Wed, 14 Dec 2011 20:48:01 -0500
Subject: [PATCH] xen/swiotlb: Use page alignment for early buffer allocation.

This piggybacks on git commit e79f86b2ef9c0a8c47225217c1018b7d3d90101c
"swiotlb: Use page alignment for early buffer allocation" which:

"We could call free_bootmem_late() if swiotlb is not used, and
it will shrink to page alignment.

So alloc them with page alignment at first, to avoid lose two pages"

Reported-by: "Kalev, Leonid" <Leonid.Kalev@ca.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 drivers/xen/swiotlb-xen.c |    5 +++--
 1 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index 8e964b9..5c8e445 100644
--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -166,7 +166,8 @@ retry:
 	/*
 	 * Get IO TLB memory from any location.
 	 */
-	xen_io_tlb_start = alloc_bootmem(bytes);
+	xen_io_tlb_start = alloc_bootmem_pages(PAGE_ALIGN(bytes));
+
 	if (!xen_io_tlb_start) {
 		m = "Cannot allocate Xen-SWIOTLB buffer!\n";
 		goto error;
@@ -179,7 +180,7 @@ retry:
 			       bytes,
 			       xen_io_tlb_nslabs);
 	if (rc) {
-		free_bootmem(__pa(xen_io_tlb_start), bytes);
+		free_bootmem(__pa(xen_io_tlb_start), PAGE_ALIGN(bytes));
 		m = "Failed to get contiguous memory for DMA from Xen!\n"\
 		    "You either: don't have the permissions, do not have"\
 		    " enough free memory under 4GB, or the hypervisor memory"\
-- 
1.7.1

is in order.
> 
> If it is OK for the swiotlb area not to be page-aligned, then the 
> xen_swiotlb_dma_supported should use (xen_io_tlb_end - (PAGE_SIZE-1))

Lets make it page aligned.

> 
> If the memory should be in fact aligned, then the allocation must be changed to 
> alloc_bootmem_pages() (which is the same as alloc_bootmem, but page-aligned).

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 02:21:45 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 02: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.xensource.com>)
	id 1Rb0wM-0005qI-9n; Thu, 15 Dec 2011 02:20:58 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Neal.Taylor@ca.com>) id 1Rb0wK-0005q7-SF
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 02:20:57 +0000
X-Env-Sender: Neal.Taylor@ca.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1323915597!5610666!1
X-Originating-IP: [74.125.149.151]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18181 invoked from network); 15 Dec 2011 02:20:00 -0000
Received: from na3sys009aog124.obsmtp.com (HELO na3sys009aog124.obsmtp.com)
	(74.125.149.151)
	by server-6.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 15 Dec 2011 02:20:00 -0000
Received: from USILMS191.ca.com ([141.202.246.45]) (using TLSv1) by
	na3sys009aob124.postini.com ([74.125.148.12]) with SMTP
	ID DSNKTulZTWPulQmT0QP0tB55ihIO5Nv/xJ4K@postini.com;
	Wed, 14 Dec 2011 18:19:59 PST
Received: from USILMS175.ca.com (141.202.6.25) by USILMS191.ca.com
	(141.202.246.45) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Wed, 14 Dec 2011 21:19:56 -0500
Received: from USILMS110A.ca.com ([169.254.1.109]) by usilms175.ca.com
	([141.202.6.25]) with mapi id 14.01.0289.001;
	Wed, 14 Dec 2011 21:19:56 -0500
From: "Taylor, Neal E" <Neal.Taylor@ca.com>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>, "Kalev, Leonid"
	<Leonid.Kalev@ca.com>, "konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
Thread-Topic: [Xen-devel] Buffers not reachable by PCI
Thread-Index: Acy2r+Ulg1PsfbmtTl6QVj0jZAx7mwAK1xcAAIXl/sAAGPmvgAAhEiCwAA9ukQAACILlsAAMK30AAALQl/AAEM4lgAAPSjyAAAnO0KA=
Date: Thu, 15 Dec 2011 02:19:55 +0000
Message-ID: <3E243B26F475504B9BB0BCC9728B0DA629E18EBF@USILMS110A.ca.com>
References: <3E243B26F475504B9BB0BCC9728B0DA629E16E01@USILMS110A.ca.com>
	<20111209203010.GA14412@andromeda.dapyr.net>
	<3E243B26F475504B9BB0BCC9728B0DA629E17AEA@USILMS110A.ca.com>
	<20111213001912.GA2730@konrad-lan>
	<3E243B26F475504B9BB0BCC9728B0DA629E184FA@USILMS110A.ca.com>
	<20111213232759.GA8702@konrad-lan>
	<3E243B26F475504B9BB0BCC9728B0DA629E18564@USILMS110A.ca.com>
	<4EE8785A0200007800067A16@nat28.tlf.novell.com>
	<3E243B26F475504B9BB0BCC9728B0DA629E18A6B@USILMS110A.ca.com>
	<4EE8EDF5.5070800@ca.com> <20111215015944.GD10268@konrad-lan>
In-Reply-To: <20111215015944.GD10268@konrad-lan>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [138.42.46.105]
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>,
	Tushar N Dave <tushar.n.dave@intel.com>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] Buffers not reachable by PCI
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Missed this when I was composing the previous e-mail. Your answer is here. Thank you.

Neal

-----Original Message-----
From: Konrad Rzeszutek Wilk [mailto:konrad.r.wilk@gmail.com] On Behalf Of Konrad Rzeszutek Wilk
Sent: Wednesday, December 14, 2011 6:00 PM
To: Kalev, Leonid; konrad.wilk@oracle.com
Cc: Taylor, Neal E; Jan Beulich; Tushar N Dave; xen-devel
Subject: Re: [Xen-devel] Buffers not reachable by PCI

On Wed, Dec 14, 2011 at 06:42:07PM +0000, Kalev, Leonid wrote:
> On 12/14/2011 06:42 PM, Taylor, Neal E wrote:
> > The last quoted printout is calculated the same way as the test that fails which leads me to question the computation's validity.
> 
> The computation validity seems OK to me (the 'phys' address is, as correctly stated 
> in the comments, not suitable for DMA, but it is first translated via 
> xen_phys_to_bus, which gives the machine address - and on x86 that is also the bus 
> address)
> 
> I have a STUPID question, though: why are the start and end addresses of the swiotlb 
> memory area not page-aligned???

That is not a stupid question.
> 
> The io_tlb_end address is one byte PAST the valid area, which is why the 
> xen_swiotlb_dma_supported function uses (xen_io_tlb_end-1). However, this will work 
> properly only if the value is page-aligned. If it isn't, then decrementing it by one 
> will keep the value in the same page (which is one page past the last valid one).
> 
> The function that allocates the memory uses alloc_bootmem(), which provides just 
> cache-aligned memory (not page-aligned).

Yup.

It is actually funny (sad?), b/c I am the committer for the
e79f86b2ef9c0a8c47225217c1018b7d3d90101c which adds something like this:

 alloc_bootmem_pages(PAGE_ALIGN(io_tlb_nslabs * sizeof(int)

in the swiotlb code but I completly missed doing it for the Xen SWIOTLB.

<sigh>

I think this patch:

>From 47409eecc08effe20fc4aa0da899dd6ac475cb0b Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Wed, 14 Dec 2011 20:48:01 -0500
Subject: [PATCH] xen/swiotlb: Use page alignment for early buffer allocation.

This piggybacks on git commit e79f86b2ef9c0a8c47225217c1018b7d3d90101c
"swiotlb: Use page alignment for early buffer allocation" which:

"We could call free_bootmem_late() if swiotlb is not used, and
it will shrink to page alignment.

So alloc them with page alignment at first, to avoid lose two pages"

Reported-by: "Kalev, Leonid" <Leonid.Kalev@ca.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 drivers/xen/swiotlb-xen.c |    5 +++--
 1 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index 8e964b9..5c8e445 100644
--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -166,7 +166,8 @@ retry:
 	/*
 	 * Get IO TLB memory from any location.
 	 */
-	xen_io_tlb_start = alloc_bootmem(bytes);
+	xen_io_tlb_start = alloc_bootmem_pages(PAGE_ALIGN(bytes));
+
 	if (!xen_io_tlb_start) {
 		m = "Cannot allocate Xen-SWIOTLB buffer!\n";
 		goto error;
@@ -179,7 +180,7 @@ retry:
 			       bytes,
 			       xen_io_tlb_nslabs);
 	if (rc) {
-		free_bootmem(__pa(xen_io_tlb_start), bytes);
+		free_bootmem(__pa(xen_io_tlb_start), PAGE_ALIGN(bytes));
 		m = "Failed to get contiguous memory for DMA from Xen!\n"\
 		    "You either: don't have the permissions, do not have"\
 		    " enough free memory under 4GB, or the hypervisor memory"\
-- 
1.7.1

is in order.
> 
> If it is OK for the swiotlb area not to be page-aligned, then the 
> xen_swiotlb_dma_supported should use (xen_io_tlb_end - (PAGE_SIZE-1))

Lets make it page aligned.

> 
> If the memory should be in fact aligned, then the allocation must be changed to 
> alloc_bootmem_pages() (which is the same as alloc_bootmem, but page-aligned).

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 02:31:53 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 02: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.xensource.com>)
	id 1Rb169-0006Gj-Ih; Thu, 15 Dec 2011 02:31:05 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1Rb168-0006E3-JV
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 02:31:04 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-10.tower-21.messagelabs.com!1323916205!8005732!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19112 invoked from network); 15 Dec 2011 02:30:07 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-10.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 15 Dec 2011 02:30:07 -0000
Received: from andromeda.dapyr.net (darnok@localhost [127.0.0.1])
	by andromeda.dapyr.net (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id
	pBF2TclK016115
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Wed, 14 Dec 2011 21:29:39 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pBF2Tc0f016113;
	Wed, 14 Dec 2011 21:29:38 -0500
Date: Wed, 14 Dec 2011 22:29:38 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: "Taylor, Neal E" <Neal.Taylor@ca.com>
Message-ID: <20111215022938.GA16031@andromeda.dapyr.net>
References: <3E243B26F475504B9BB0BCC9728B0DA629E17AEA@USILMS110A.ca.com>
	<20111213001912.GA2730@konrad-lan>
	<3E243B26F475504B9BB0BCC9728B0DA629E184FA@USILMS110A.ca.com>
	<20111213232759.GA8702@konrad-lan>
	<3E243B26F475504B9BB0BCC9728B0DA629E18564@USILMS110A.ca.com>
	<4EE8785A0200007800067A16@nat28.tlf.novell.com>
	<3E243B26F475504B9BB0BCC9728B0DA629E18A6B@USILMS110A.ca.com>
	<4EE8EDF5.5070800@ca.com> <20111215015944.GD10268@konrad-lan>
	<3E243B26F475504B9BB0BCC9728B0DA629E18EBF@USILMS110A.ca.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <3E243B26F475504B9BB0BCC9728B0DA629E18EBF@USILMS110A.ca.com>
User-Agent: Mutt/1.5.9i
Cc: xen-devel <xen-devel@lists.xensource.com>, "Kalev,
	Leonid" <Leonid.Kalev@ca.com>, Tushar N Dave <tushar.n.dave@intel.com>,
	Jan Beulich <JBeulich@suse.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] Buffers not reachable by PCI
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Dec 15, 2011 at 02:19:55AM +0000, Taylor, Neal E wrote:
> Missed this when I was composing the previous e-mail. Your answer is here. Thank you.
> 

Can I put 'Tested-by: Neal ..' on this patch:

> >From 47409eecc08effe20fc4aa0da899dd6ac475cb0b Mon Sep 17 00:00:00 2001
> From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> Date: Wed, 14 Dec 2011 20:48:01 -0500
> Subject: [PATCH] xen/swiotlb: Use page alignment for early buffer allocation.
> 
> This piggybacks on git commit e79f86b2ef9c0a8c47225217c1018b7d3d90101c
> "swiotlb: Use page alignment for early buffer allocation" which:
> 
> "We could call free_bootmem_late() if swiotlb is not used, and
> it will shrink to page alignment.
> 
> So alloc them with page alignment at first, to avoid lose two pages"
> 
> Reported-by: "Kalev, Leonid" <Leonid.Kalev@ca.com>
> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> ---
>  drivers/xen/swiotlb-xen.c |    5 +++--
>  1 files changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
> index 8e964b9..5c8e445 100644
> --- a/drivers/xen/swiotlb-xen.c
> +++ b/drivers/xen/swiotlb-xen.c
> @@ -166,7 +166,8 @@ retry:
>  	/*
>  	 * Get IO TLB memory from any location.
>  	 */
> -	xen_io_tlb_start = alloc_bootmem(bytes);
> +	xen_io_tlb_start = alloc_bootmem_pages(PAGE_ALIGN(bytes));
> +
>  	if (!xen_io_tlb_start) {
>  		m = "Cannot allocate Xen-SWIOTLB buffer!\n";
>  		goto error;
> @@ -179,7 +180,7 @@ retry:
>  			       bytes,
>  			       xen_io_tlb_nslabs);
>  	if (rc) {
> -		free_bootmem(__pa(xen_io_tlb_start), bytes);
> +		free_bootmem(__pa(xen_io_tlb_start), PAGE_ALIGN(bytes));
>  		m = "Failed to get contiguous memory for DMA from Xen!\n"\
>  		    "You either: don't have the permissions, do not have"\
>  		    " enough free memory under 4GB, or the hypervisor memory"\
> -- 
> 1.7.1

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 02:31:53 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 02: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.xensource.com>)
	id 1Rb169-0006Gj-Ih; Thu, 15 Dec 2011 02:31:05 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1Rb168-0006E3-JV
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 02:31:04 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-10.tower-21.messagelabs.com!1323916205!8005732!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19112 invoked from network); 15 Dec 2011 02:30:07 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-10.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 15 Dec 2011 02:30:07 -0000
Received: from andromeda.dapyr.net (darnok@localhost [127.0.0.1])
	by andromeda.dapyr.net (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id
	pBF2TclK016115
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Wed, 14 Dec 2011 21:29:39 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pBF2Tc0f016113;
	Wed, 14 Dec 2011 21:29:38 -0500
Date: Wed, 14 Dec 2011 22:29:38 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: "Taylor, Neal E" <Neal.Taylor@ca.com>
Message-ID: <20111215022938.GA16031@andromeda.dapyr.net>
References: <3E243B26F475504B9BB0BCC9728B0DA629E17AEA@USILMS110A.ca.com>
	<20111213001912.GA2730@konrad-lan>
	<3E243B26F475504B9BB0BCC9728B0DA629E184FA@USILMS110A.ca.com>
	<20111213232759.GA8702@konrad-lan>
	<3E243B26F475504B9BB0BCC9728B0DA629E18564@USILMS110A.ca.com>
	<4EE8785A0200007800067A16@nat28.tlf.novell.com>
	<3E243B26F475504B9BB0BCC9728B0DA629E18A6B@USILMS110A.ca.com>
	<4EE8EDF5.5070800@ca.com> <20111215015944.GD10268@konrad-lan>
	<3E243B26F475504B9BB0BCC9728B0DA629E18EBF@USILMS110A.ca.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <3E243B26F475504B9BB0BCC9728B0DA629E18EBF@USILMS110A.ca.com>
User-Agent: Mutt/1.5.9i
Cc: xen-devel <xen-devel@lists.xensource.com>, "Kalev,
	Leonid" <Leonid.Kalev@ca.com>, Tushar N Dave <tushar.n.dave@intel.com>,
	Jan Beulich <JBeulich@suse.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] Buffers not reachable by PCI
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Dec 15, 2011 at 02:19:55AM +0000, Taylor, Neal E wrote:
> Missed this when I was composing the previous e-mail. Your answer is here. Thank you.
> 

Can I put 'Tested-by: Neal ..' on this patch:

> >From 47409eecc08effe20fc4aa0da899dd6ac475cb0b Mon Sep 17 00:00:00 2001
> From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> Date: Wed, 14 Dec 2011 20:48:01 -0500
> Subject: [PATCH] xen/swiotlb: Use page alignment for early buffer allocation.
> 
> This piggybacks on git commit e79f86b2ef9c0a8c47225217c1018b7d3d90101c
> "swiotlb: Use page alignment for early buffer allocation" which:
> 
> "We could call free_bootmem_late() if swiotlb is not used, and
> it will shrink to page alignment.
> 
> So alloc them with page alignment at first, to avoid lose two pages"
> 
> Reported-by: "Kalev, Leonid" <Leonid.Kalev@ca.com>
> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> ---
>  drivers/xen/swiotlb-xen.c |    5 +++--
>  1 files changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
> index 8e964b9..5c8e445 100644
> --- a/drivers/xen/swiotlb-xen.c
> +++ b/drivers/xen/swiotlb-xen.c
> @@ -166,7 +166,8 @@ retry:
>  	/*
>  	 * Get IO TLB memory from any location.
>  	 */
> -	xen_io_tlb_start = alloc_bootmem(bytes);
> +	xen_io_tlb_start = alloc_bootmem_pages(PAGE_ALIGN(bytes));
> +
>  	if (!xen_io_tlb_start) {
>  		m = "Cannot allocate Xen-SWIOTLB buffer!\n";
>  		goto error;
> @@ -179,7 +180,7 @@ retry:
>  			       bytes,
>  			       xen_io_tlb_nslabs);
>  	if (rc) {
> -		free_bootmem(__pa(xen_io_tlb_start), bytes);
> +		free_bootmem(__pa(xen_io_tlb_start), PAGE_ALIGN(bytes));
>  		m = "Failed to get contiguous memory for DMA from Xen!\n"\
>  		    "You either: don't have the permissions, do not have"\
>  		    " enough free memory under 4GB, or the hypervisor memory"\
> -- 
> 1.7.1

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 02:42:02 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 02:42:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rb1GH-0006T8-Mk; Thu, 15 Dec 2011 02:41:33 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Neal.Taylor@ca.com>) id 1Rb1GG-0006T3-Dy
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 02:41:32 +0000
X-Env-Sender: Neal.Taylor@ca.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1323916834!7408747!1
X-Originating-IP: [74.125.149.151]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4608 invoked from network); 15 Dec 2011 02:40:35 -0000
Received: from na3sys009aog124.obsmtp.com (HELO na3sys009aog124.obsmtp.com)
	(74.125.149.151)
	by server-10.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 15 Dec 2011 02:40:35 -0000
Received: from USILMS191.ca.com ([141.202.246.45]) (using TLSv1) by
	na3sys009aob124.postini.com ([74.125.148.12]) with SMTP
	ID DSNKTuleISdSWmSPPO5cxgwE268t9I/wv8qX@postini.com;
	Wed, 14 Dec 2011 18:40:35 PST
Received: from USILMS173.ca.com (141.202.6.23) by USILMS191.ca.com
	(141.202.246.45) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Wed, 14 Dec 2011 21:40:32 -0500
Received: from USILMS110A.ca.com ([169.254.1.109]) by usilms173.ca.com
	([141.202.6.23]) with mapi id 14.01.0289.001;
	Wed, 14 Dec 2011 21:40:32 -0500
From: "Taylor, Neal E" <Neal.Taylor@ca.com>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
Thread-Topic: [Xen-devel] Buffers not reachable by PCI
Thread-Index: Acy2r+Ulg1PsfbmtTl6QVj0jZAx7mwAK1xcAAIXl/sAAGPmvgAAhEiCwAA9ukQAACILlsAAMK30AAALQl/AAEM4lgAAPSjyAAAnO0KD//7niAIAAUk5w
Date: Thu, 15 Dec 2011 02:40:32 +0000
Message-ID: <3E243B26F475504B9BB0BCC9728B0DA629E18ED1@USILMS110A.ca.com>
References: <3E243B26F475504B9BB0BCC9728B0DA629E17AEA@USILMS110A.ca.com>
	<20111213001912.GA2730@konrad-lan>
	<3E243B26F475504B9BB0BCC9728B0DA629E184FA@USILMS110A.ca.com>
	<20111213232759.GA8702@konrad-lan>
	<3E243B26F475504B9BB0BCC9728B0DA629E18564@USILMS110A.ca.com>
	<4EE8785A0200007800067A16@nat28.tlf.novell.com>
	<3E243B26F475504B9BB0BCC9728B0DA629E18A6B@USILMS110A.ca.com>
	<4EE8EDF5.5070800@ca.com> <20111215015944.GD10268@konrad-lan>
	<3E243B26F475504B9BB0BCC9728B0DA629E18EBF@USILMS110A.ca.com>
	<20111215022938.GA16031@andromeda.dapyr.net>
In-Reply-To: <20111215022938.GA16031@andromeda.dapyr.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [138.42.46.105]
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>, "Kalev,
	Leonid" <Leonid.Kalev@ca.com>, Tushar N Dave <tushar.n.dave@intel.com>,
	Jan Beulich <JBeulich@suse.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] Buffers not reachable by PCI
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Sure! But only if 3.0.4 is recent enough. However, that version does not have the code for the "free_bootmem" section of this patch so only the first line was actually tested. (Not that I could test the negative case if the code existed.)

I'll test on a more recent version (your pick) tomorrow, should you prefer.

Neal

-----Original Message-----
From: Konrad Rzeszutek Wilk [mailto:konrad@darnok.org] 
Sent: Wednesday, December 14, 2011 6:30 PM
To: Taylor, Neal E
Cc: Kalev, Leonid; konrad.wilk@oracle.com; xen-devel; Tushar N Dave; Jan Beulich
Subject: Re: [Xen-devel] Buffers not reachable by PCI

On Thu, Dec 15, 2011 at 02:19:55AM +0000, Taylor, Neal E wrote:
> Missed this when I was composing the previous e-mail. Your answer is here. Thank you.
> 

Can I put 'Tested-by: Neal ..' on this patch:

> >From 47409eecc08effe20fc4aa0da899dd6ac475cb0b Mon Sep 17 00:00:00 2001
> From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> Date: Wed, 14 Dec 2011 20:48:01 -0500
> Subject: [PATCH] xen/swiotlb: Use page alignment for early buffer allocation.
> 
> This piggybacks on git commit e79f86b2ef9c0a8c47225217c1018b7d3d90101c
> "swiotlb: Use page alignment for early buffer allocation" which:
> 
> "We could call free_bootmem_late() if swiotlb is not used, and
> it will shrink to page alignment.
> 
> So alloc them with page alignment at first, to avoid lose two pages"
> 
> Reported-by: "Kalev, Leonid" <Leonid.Kalev@ca.com>
> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> ---
>  drivers/xen/swiotlb-xen.c |    5 +++--
>  1 files changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
> index 8e964b9..5c8e445 100644
> --- a/drivers/xen/swiotlb-xen.c
> +++ b/drivers/xen/swiotlb-xen.c
> @@ -166,7 +166,8 @@ retry:
>  	/*
>  	 * Get IO TLB memory from any location.
>  	 */
> -	xen_io_tlb_start = alloc_bootmem(bytes);
> +	xen_io_tlb_start = alloc_bootmem_pages(PAGE_ALIGN(bytes));
> +
>  	if (!xen_io_tlb_start) {
>  		m = "Cannot allocate Xen-SWIOTLB buffer!\n";
>  		goto error;
> @@ -179,7 +180,7 @@ retry:
>  			       bytes,
>  			       xen_io_tlb_nslabs);
>  	if (rc) {
> -		free_bootmem(__pa(xen_io_tlb_start), bytes);
> +		free_bootmem(__pa(xen_io_tlb_start), PAGE_ALIGN(bytes));
>  		m = "Failed to get contiguous memory for DMA from Xen!\n"\
>  		    "You either: don't have the permissions, do not have"\
>  		    " enough free memory under 4GB, or the hypervisor memory"\
> -- 
> 1.7.1

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 02:42:02 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 02:42:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rb1GH-0006T8-Mk; Thu, 15 Dec 2011 02:41:33 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Neal.Taylor@ca.com>) id 1Rb1GG-0006T3-Dy
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 02:41:32 +0000
X-Env-Sender: Neal.Taylor@ca.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1323916834!7408747!1
X-Originating-IP: [74.125.149.151]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4608 invoked from network); 15 Dec 2011 02:40:35 -0000
Received: from na3sys009aog124.obsmtp.com (HELO na3sys009aog124.obsmtp.com)
	(74.125.149.151)
	by server-10.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 15 Dec 2011 02:40:35 -0000
Received: from USILMS191.ca.com ([141.202.246.45]) (using TLSv1) by
	na3sys009aob124.postini.com ([74.125.148.12]) with SMTP
	ID DSNKTuleISdSWmSPPO5cxgwE268t9I/wv8qX@postini.com;
	Wed, 14 Dec 2011 18:40:35 PST
Received: from USILMS173.ca.com (141.202.6.23) by USILMS191.ca.com
	(141.202.246.45) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Wed, 14 Dec 2011 21:40:32 -0500
Received: from USILMS110A.ca.com ([169.254.1.109]) by usilms173.ca.com
	([141.202.6.23]) with mapi id 14.01.0289.001;
	Wed, 14 Dec 2011 21:40:32 -0500
From: "Taylor, Neal E" <Neal.Taylor@ca.com>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
Thread-Topic: [Xen-devel] Buffers not reachable by PCI
Thread-Index: Acy2r+Ulg1PsfbmtTl6QVj0jZAx7mwAK1xcAAIXl/sAAGPmvgAAhEiCwAA9ukQAACILlsAAMK30AAALQl/AAEM4lgAAPSjyAAAnO0KD//7niAIAAUk5w
Date: Thu, 15 Dec 2011 02:40:32 +0000
Message-ID: <3E243B26F475504B9BB0BCC9728B0DA629E18ED1@USILMS110A.ca.com>
References: <3E243B26F475504B9BB0BCC9728B0DA629E17AEA@USILMS110A.ca.com>
	<20111213001912.GA2730@konrad-lan>
	<3E243B26F475504B9BB0BCC9728B0DA629E184FA@USILMS110A.ca.com>
	<20111213232759.GA8702@konrad-lan>
	<3E243B26F475504B9BB0BCC9728B0DA629E18564@USILMS110A.ca.com>
	<4EE8785A0200007800067A16@nat28.tlf.novell.com>
	<3E243B26F475504B9BB0BCC9728B0DA629E18A6B@USILMS110A.ca.com>
	<4EE8EDF5.5070800@ca.com> <20111215015944.GD10268@konrad-lan>
	<3E243B26F475504B9BB0BCC9728B0DA629E18EBF@USILMS110A.ca.com>
	<20111215022938.GA16031@andromeda.dapyr.net>
In-Reply-To: <20111215022938.GA16031@andromeda.dapyr.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [138.42.46.105]
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>, "Kalev,
	Leonid" <Leonid.Kalev@ca.com>, Tushar N Dave <tushar.n.dave@intel.com>,
	Jan Beulich <JBeulich@suse.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] Buffers not reachable by PCI
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Sure! But only if 3.0.4 is recent enough. However, that version does not have the code for the "free_bootmem" section of this patch so only the first line was actually tested. (Not that I could test the negative case if the code existed.)

I'll test on a more recent version (your pick) tomorrow, should you prefer.

Neal

-----Original Message-----
From: Konrad Rzeszutek Wilk [mailto:konrad@darnok.org] 
Sent: Wednesday, December 14, 2011 6:30 PM
To: Taylor, Neal E
Cc: Kalev, Leonid; konrad.wilk@oracle.com; xen-devel; Tushar N Dave; Jan Beulich
Subject: Re: [Xen-devel] Buffers not reachable by PCI

On Thu, Dec 15, 2011 at 02:19:55AM +0000, Taylor, Neal E wrote:
> Missed this when I was composing the previous e-mail. Your answer is here. Thank you.
> 

Can I put 'Tested-by: Neal ..' on this patch:

> >From 47409eecc08effe20fc4aa0da899dd6ac475cb0b Mon Sep 17 00:00:00 2001
> From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> Date: Wed, 14 Dec 2011 20:48:01 -0500
> Subject: [PATCH] xen/swiotlb: Use page alignment for early buffer allocation.
> 
> This piggybacks on git commit e79f86b2ef9c0a8c47225217c1018b7d3d90101c
> "swiotlb: Use page alignment for early buffer allocation" which:
> 
> "We could call free_bootmem_late() if swiotlb is not used, and
> it will shrink to page alignment.
> 
> So alloc them with page alignment at first, to avoid lose two pages"
> 
> Reported-by: "Kalev, Leonid" <Leonid.Kalev@ca.com>
> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> ---
>  drivers/xen/swiotlb-xen.c |    5 +++--
>  1 files changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
> index 8e964b9..5c8e445 100644
> --- a/drivers/xen/swiotlb-xen.c
> +++ b/drivers/xen/swiotlb-xen.c
> @@ -166,7 +166,8 @@ retry:
>  	/*
>  	 * Get IO TLB memory from any location.
>  	 */
> -	xen_io_tlb_start = alloc_bootmem(bytes);
> +	xen_io_tlb_start = alloc_bootmem_pages(PAGE_ALIGN(bytes));
> +
>  	if (!xen_io_tlb_start) {
>  		m = "Cannot allocate Xen-SWIOTLB buffer!\n";
>  		goto error;
> @@ -179,7 +180,7 @@ retry:
>  			       bytes,
>  			       xen_io_tlb_nslabs);
>  	if (rc) {
> -		free_bootmem(__pa(xen_io_tlb_start), bytes);
> +		free_bootmem(__pa(xen_io_tlb_start), PAGE_ALIGN(bytes));
>  		m = "Failed to get contiguous memory for DMA from Xen!\n"\
>  		    "You either: don't have the permissions, do not have"\
>  		    " enough free memory under 4GB, or the hypervisor memory"\
> -- 
> 1.7.1

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 03:26:54 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 03: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.xensource.com>)
	id 1Rb1xf-0006xk-EZ; Thu, 15 Dec 2011 03:26:23 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Rb1xd-0006xf-Db
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 03:26:21 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1323919490!56743980!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTkyOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6625 invoked from network); 15 Dec 2011 03:24:50 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 03:24:50 -0000
X-IronPort-AV: E=Sophos;i="4.71,356,1320624000"; 
   d="scan'208";a="9478810"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Dec 2011 03:25:24 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 15 Dec 2011 03:25:24 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1Rb1wi-0002hu-E1;
	Thu, 15 Dec 2011 03:25:24 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Rb1wi-0007K7-DZ;
	Thu, 15 Dec 2011 03:25:24 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10493-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 15 Dec 2011 03:25:24 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10493: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10493 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10493/

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-amd64-xl-sedf-pin 14 guest-localmigrate/x10    fail REGR. vs. 10491
 test-amd64-amd64-xl-win7-amd64  7 windows-install         fail REGR. vs. 10491

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf     14 guest-localmigrate/x10      fail pass in 10492
 test-i386-i386-win            7 windows-install             fail pass in 10492
 test-amd64-i386-xl-win7-amd64  7 windows-install   fail in 10492 pass in 10493

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3    7 windows-install              fail   like 10491
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xend-winxpsp3  7 windows-install      fail in 10492 like 10491
 test-i386-i386-win           16 leak-check/check      fail in 10492 never pass
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install fail in 10492 like 10491

version targeted for testing:
 xen                  5d2dd48bce21
baseline version:
 xen                  03138a08366b

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   24408:5d2dd48bce21
tag:         tip
user:        Andrew Cooper <andrew.cooper3@citrix.com>
date:        Wed Dec 14 17:53:54 2011 +0100
    
    XLAT.lst whitespace fix.
    
    Replace spaces with tabs to be in line with file format.
    
    Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
    Committed-by: Jan Beulich <jbeulich@suse.com>
    
    
changeset:   24407:03138a08366b
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Fri Dec 09 16:19:36 2011 +0000
    
    oxenstored: log Errors and Warnings by default.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Acked-by: Ian Jackson <ian.jackson.citrix.com>
    Committed-by: Ian Jackson <ian.jackson.citrix.com>
    
    
========================================
commit 54e24021005458ad0a361c1d83011b751726a94b
Author: Ian Jackson <ian.jackson@eu.citrix.com>
Date:   Thu Dec 8 16:38:06 2011 +0000

    qemu_get_timer: Provide a comment about the behaviour on ts==NULL
    
    Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 03:26:54 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 03: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.xensource.com>)
	id 1Rb1xf-0006xk-EZ; Thu, 15 Dec 2011 03:26:23 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Rb1xd-0006xf-Db
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 03:26:21 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1323919490!56743980!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTkyOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6625 invoked from network); 15 Dec 2011 03:24:50 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 03:24:50 -0000
X-IronPort-AV: E=Sophos;i="4.71,356,1320624000"; 
   d="scan'208";a="9478810"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Dec 2011 03:25:24 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 15 Dec 2011 03:25:24 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1Rb1wi-0002hu-E1;
	Thu, 15 Dec 2011 03:25:24 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Rb1wi-0007K7-DZ;
	Thu, 15 Dec 2011 03:25:24 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10493-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 15 Dec 2011 03:25:24 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10493: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10493 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10493/

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-amd64-xl-sedf-pin 14 guest-localmigrate/x10    fail REGR. vs. 10491
 test-amd64-amd64-xl-win7-amd64  7 windows-install         fail REGR. vs. 10491

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf     14 guest-localmigrate/x10      fail pass in 10492
 test-i386-i386-win            7 windows-install             fail pass in 10492
 test-amd64-i386-xl-win7-amd64  7 windows-install   fail in 10492 pass in 10493

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3    7 windows-install              fail   like 10491
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xend-winxpsp3  7 windows-install      fail in 10492 like 10491
 test-i386-i386-win           16 leak-check/check      fail in 10492 never pass
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install fail in 10492 like 10491

version targeted for testing:
 xen                  5d2dd48bce21
baseline version:
 xen                  03138a08366b

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   24408:5d2dd48bce21
tag:         tip
user:        Andrew Cooper <andrew.cooper3@citrix.com>
date:        Wed Dec 14 17:53:54 2011 +0100
    
    XLAT.lst whitespace fix.
    
    Replace spaces with tabs to be in line with file format.
    
    Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
    Committed-by: Jan Beulich <jbeulich@suse.com>
    
    
changeset:   24407:03138a08366b
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Fri Dec 09 16:19:36 2011 +0000
    
    oxenstored: log Errors and Warnings by default.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Acked-by: Ian Jackson <ian.jackson.citrix.com>
    Committed-by: Ian Jackson <ian.jackson.citrix.com>
    
    
========================================
commit 54e24021005458ad0a361c1d83011b751726a94b
Author: Ian Jackson <ian.jackson@eu.citrix.com>
Date:   Thu Dec 8 16:38:06 2011 +0000

    qemu_get_timer: Provide a comment about the behaviour on ts==NULL
    
    Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 06:41:35 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 06:41:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rb4zl-0001fY-Lv; Thu, 15 Dec 2011 06:40:45 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rb4zk-0001fT-8T
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 06:40:44 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1323931188!8313484!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTkyOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22300 invoked from network); 15 Dec 2011 06:39:48 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 06:39:48 -0000
X-IronPort-AV: E=Sophos;i="4.71,356,1320624000"; 
   d="scan'208";a="9479797"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Dec 2011 06:39:47 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 15 Dec 2011 06:39:47 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: DcMichael <dcmichael1256@gmail.com>
In-Reply-To: <1323282732.2750.6.camel@dcmichael-pc>
References: <1323282732.2750.6.camel@dcmichael-pc>
Organization: Citrix Systems, Inc.
Date: Thu, 15 Dec 2011 06:39:46 +0000
Message-ID: <1323931186.20936.113.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
X-Mailer: Evolution 2.32.3 
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] How to share memory with kernel and hypervisor?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2011-12-07 at 18:32 +0000, DcMichael wrote:
> Hi!
> I'm first in here.
> anyway I want to make kernel and hypervisor share there memory.
> which the kernal write memory, then hypervisor can read it.
> without any function like copy_from_user.
> 
> I'll use this memory very many time, so I want share memory like shmget.
> but using ring use push function every time.
> 
> can I share memory like this way?

Using share_xen_page_with_guest() might be one way.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 06:41:35 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 06:41:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rb4zl-0001fY-Lv; Thu, 15 Dec 2011 06:40:45 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rb4zk-0001fT-8T
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 06:40:44 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1323931188!8313484!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTkyOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22300 invoked from network); 15 Dec 2011 06:39:48 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 06:39:48 -0000
X-IronPort-AV: E=Sophos;i="4.71,356,1320624000"; 
   d="scan'208";a="9479797"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Dec 2011 06:39:47 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 15 Dec 2011 06:39:47 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: DcMichael <dcmichael1256@gmail.com>
In-Reply-To: <1323282732.2750.6.camel@dcmichael-pc>
References: <1323282732.2750.6.camel@dcmichael-pc>
Organization: Citrix Systems, Inc.
Date: Thu, 15 Dec 2011 06:39:46 +0000
Message-ID: <1323931186.20936.113.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
X-Mailer: Evolution 2.32.3 
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] How to share memory with kernel and hypervisor?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2011-12-07 at 18:32 +0000, DcMichael wrote:
> Hi!
> I'm first in here.
> anyway I want to make kernel and hypervisor share there memory.
> which the kernal write memory, then hypervisor can read it.
> without any function like copy_from_user.
> 
> I'll use this memory very many time, so I want share memory like shmget.
> but using ring use push function every time.
> 
> can I share memory like this way?

Using share_xen_page_with_guest() might be one way.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 06:53:04 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 06: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.xensource.com>)
	id 1Rb5B4-0001pw-SV; Thu, 15 Dec 2011 06:52:26 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rb5B4-0001pr-7O
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 06:52:26 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1323931879!7333036!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTkyOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2041 invoked from network); 15 Dec 2011 06:51:30 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 06:51:30 -0000
X-IronPort-AV: E=Sophos;i="4.71,356,1320624000"; 
   d="scan'208";a="9479877"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Dec 2011 06:51:19 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 15 Dec 2011 06:51:19 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Quartexx <quartex73@gmail.com>
In-Reply-To: <CAMhBqqj-3cjgiQsahL8BJHyJbCfYu+8dQx546XLf8Ht+6LiF0w@mail.gmail.com>
References: <CAMhBqqiLc1994GUKtA7UY52pR29nktmFy+XiwTwpZb_E+fwFRQ@mail.gmail.com>
	<CAMhBqqgu6v8NB-X0dNdfrzd12=Y2i==fYCCC2Z+MkDupqqKAOg@mail.gmail.com>
	<20111202195727.GA18758@andromeda.dapyr.net>
	<CAMhBqqgJ0Q3BZDuK3KEEGuDS2eGBZq89E7_Kbv+VNTYxZJLAAA@mail.gmail.com>
	<20111214194029.GB17432@andromeda.dapyr.net>
	<CAMhBqqj-3cjgiQsahL8BJHyJbCfYu+8dQx546XLf8Ht+6LiF0w@mail.gmail.com>
Organization: Citrix Systems, Inc.
Date: Thu, 15 Dec 2011 06:51:18 +0000
Message-ID: <1323931878.20936.120.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
X-Mailer: Evolution 2.32.3 
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] xen 4.0.1 w/2.6.32.47 hangs at boot
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2011-12-14 at 21:05 +0000, Quartexx wrote:
> Since I'm using blktap2 I'm concerned about upgrading to 3.0.x.  I
> have read bad feedback about blktap-dkms.  Are my concerns unfounded?

It's the same code base as was in 2.6.32 forward ported and packaged as
an external module. Do you have references to the feedback?

If you are in need of blktap2 functionality then you should try it for
yourself and report the bugs, otherwise your concerns can never go
away...

> Are there any alternative to blktap2 (excluding LVM)?

qemu can provide a disk backend but it is not very performant. xl will
use this by default if blktap2 is not available.

The future of blktap2 has been discussed on list several times (in short
someone needs to bolt a disk frontend onto the userspace part and remove
the need for the kernel component) but unless/until someone with a
requirement for blktap2 steps up to the plate we can't promise when that
will happen... I think it should be reasonably straight forward, it's
certainly not as deep voodoo kernel stuff as you might expect.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 06:53:04 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 06: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.xensource.com>)
	id 1Rb5B4-0001pw-SV; Thu, 15 Dec 2011 06:52:26 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rb5B4-0001pr-7O
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 06:52:26 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1323931879!7333036!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTkyOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2041 invoked from network); 15 Dec 2011 06:51:30 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 06:51:30 -0000
X-IronPort-AV: E=Sophos;i="4.71,356,1320624000"; 
   d="scan'208";a="9479877"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Dec 2011 06:51:19 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 15 Dec 2011 06:51:19 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Quartexx <quartex73@gmail.com>
In-Reply-To: <CAMhBqqj-3cjgiQsahL8BJHyJbCfYu+8dQx546XLf8Ht+6LiF0w@mail.gmail.com>
References: <CAMhBqqiLc1994GUKtA7UY52pR29nktmFy+XiwTwpZb_E+fwFRQ@mail.gmail.com>
	<CAMhBqqgu6v8NB-X0dNdfrzd12=Y2i==fYCCC2Z+MkDupqqKAOg@mail.gmail.com>
	<20111202195727.GA18758@andromeda.dapyr.net>
	<CAMhBqqgJ0Q3BZDuK3KEEGuDS2eGBZq89E7_Kbv+VNTYxZJLAAA@mail.gmail.com>
	<20111214194029.GB17432@andromeda.dapyr.net>
	<CAMhBqqj-3cjgiQsahL8BJHyJbCfYu+8dQx546XLf8Ht+6LiF0w@mail.gmail.com>
Organization: Citrix Systems, Inc.
Date: Thu, 15 Dec 2011 06:51:18 +0000
Message-ID: <1323931878.20936.120.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
X-Mailer: Evolution 2.32.3 
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] xen 4.0.1 w/2.6.32.47 hangs at boot
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2011-12-14 at 21:05 +0000, Quartexx wrote:
> Since I'm using blktap2 I'm concerned about upgrading to 3.0.x.  I
> have read bad feedback about blktap-dkms.  Are my concerns unfounded?

It's the same code base as was in 2.6.32 forward ported and packaged as
an external module. Do you have references to the feedback?

If you are in need of blktap2 functionality then you should try it for
yourself and report the bugs, otherwise your concerns can never go
away...

> Are there any alternative to blktap2 (excluding LVM)?

qemu can provide a disk backend but it is not very performant. xl will
use this by default if blktap2 is not available.

The future of blktap2 has been discussed on list several times (in short
someone needs to bolt a disk frontend onto the userspace part and remove
the need for the kernel component) but unless/until someone with a
requirement for blktap2 steps up to the plate we can't promise when that
will happen... I think it should be reasonably straight forward, it's
certainly not as deep voodoo kernel stuff as you might expect.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 07:16:23 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 07: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.xensource.com>)
	id 1Rb5XV-0002QB-4j; Thu, 15 Dec 2011 07:15:37 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Rb5XT-0002Q6-AD
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 07:15:35 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1323933264!49357694!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTkyOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13188 invoked from network); 15 Dec 2011 07:14:24 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 07:14:24 -0000
X-IronPort-AV: E=Sophos;i="4.71,356,1320624000"; 
   d="scan'208";a="9480138"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Dec 2011 07:14:43 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 15 Dec 2011 07:14:42 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1Rb5Wc-00040I-Hc;
	Thu, 15 Dec 2011 07:14:42 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Rb5Wc-0000LP-FV;
	Thu, 15 Dec 2011 07:14:42 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10498-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 15 Dec 2011 07:14:42 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10498: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10498 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10498/

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-amd64-xl-sedf-pin 14 guest-localmigrate/x10    fail REGR. vs. 10491

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf      7 debian-install              fail pass in 10493
 test-amd64-amd64-xl-sedf 14 guest-localmigrate/x10 fail in 10493 pass in 10492
 test-amd64-amd64-xl-win7-amd64  7 windows-install  fail in 10493 pass in 10498
 test-i386-i386-win            7 windows-install    fail in 10493 pass in 10498
 test-amd64-i386-xl-win7-amd64  7 windows-install   fail in 10492 pass in 10498

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-i386-i386-xl-winxpsp3    7 windows-install       fail in 10493 like 10491
 test-amd64-i386-xend-winxpsp3  7 windows-install      fail in 10492 like 10491
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install fail in 10492 like 10491

version targeted for testing:
 xen                  5d2dd48bce21
baseline version:
 xen                  03138a08366b

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   24408:5d2dd48bce21
tag:         tip
user:        Andrew Cooper <andrew.cooper3@citrix.com>
date:        Wed Dec 14 17:53:54 2011 +0100
    
    XLAT.lst whitespace fix.
    
    Replace spaces with tabs to be in line with file format.
    
    Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
    Committed-by: Jan Beulich <jbeulich@suse.com>
    
    
changeset:   24407:03138a08366b
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Fri Dec 09 16:19:36 2011 +0000
    
    oxenstored: log Errors and Warnings by default.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Acked-by: Ian Jackson <ian.jackson.citrix.com>
    Committed-by: Ian Jackson <ian.jackson.citrix.com>
    
    
========================================
commit 54e24021005458ad0a361c1d83011b751726a94b
Author: Ian Jackson <ian.jackson@eu.citrix.com>
Date:   Thu Dec 8 16:38:06 2011 +0000

    qemu_get_timer: Provide a comment about the behaviour on ts==NULL
    
    Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 07:16:23 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 07: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.xensource.com>)
	id 1Rb5XV-0002QB-4j; Thu, 15 Dec 2011 07:15:37 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Rb5XT-0002Q6-AD
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 07:15:35 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1323933264!49357694!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTkyOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13188 invoked from network); 15 Dec 2011 07:14:24 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 07:14:24 -0000
X-IronPort-AV: E=Sophos;i="4.71,356,1320624000"; 
   d="scan'208";a="9480138"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Dec 2011 07:14:43 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 15 Dec 2011 07:14:42 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1Rb5Wc-00040I-Hc;
	Thu, 15 Dec 2011 07:14:42 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Rb5Wc-0000LP-FV;
	Thu, 15 Dec 2011 07:14:42 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10498-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 15 Dec 2011 07:14:42 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10498: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10498 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10498/

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-amd64-xl-sedf-pin 14 guest-localmigrate/x10    fail REGR. vs. 10491

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf      7 debian-install              fail pass in 10493
 test-amd64-amd64-xl-sedf 14 guest-localmigrate/x10 fail in 10493 pass in 10492
 test-amd64-amd64-xl-win7-amd64  7 windows-install  fail in 10493 pass in 10498
 test-i386-i386-win            7 windows-install    fail in 10493 pass in 10498
 test-amd64-i386-xl-win7-amd64  7 windows-install   fail in 10492 pass in 10498

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-i386-i386-xl-winxpsp3    7 windows-install       fail in 10493 like 10491
 test-amd64-i386-xend-winxpsp3  7 windows-install      fail in 10492 like 10491
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install fail in 10492 like 10491

version targeted for testing:
 xen                  5d2dd48bce21
baseline version:
 xen                  03138a08366b

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   24408:5d2dd48bce21
tag:         tip
user:        Andrew Cooper <andrew.cooper3@citrix.com>
date:        Wed Dec 14 17:53:54 2011 +0100
    
    XLAT.lst whitespace fix.
    
    Replace spaces with tabs to be in line with file format.
    
    Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
    Committed-by: Jan Beulich <jbeulich@suse.com>
    
    
changeset:   24407:03138a08366b
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Fri Dec 09 16:19:36 2011 +0000
    
    oxenstored: log Errors and Warnings by default.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Acked-by: Ian Jackson <ian.jackson.citrix.com>
    Committed-by: Ian Jackson <ian.jackson.citrix.com>
    
    
========================================
commit 54e24021005458ad0a361c1d83011b751726a94b
Author: Ian Jackson <ian.jackson@eu.citrix.com>
Date:   Thu Dec 8 16:38:06 2011 +0000

    qemu_get_timer: Provide a comment about the behaviour on ts==NULL
    
    Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 08:40:17 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 08:40:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rb6qg-0003um-0z; Thu, 15 Dec 2011 08:39:30 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Rb6qe-0003uh-KU
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 08:39:28 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1323938267!57381926!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16806 invoked from network); 15 Dec 2011 08:37:47 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-2.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 15 Dec 2011 08:37:47 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 15 Dec 2011 08:38:36 +0000
Message-Id: <4EE9C01902000078000680CD@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 15 Dec 2011 08:38:33 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Boris Ostrovsky" <boris.ostrovsky@amd.com>,
	<christoph.egger@amd.com>,"Keir Fraser" <keir@xen.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: [Xen-devel] fsincos emulation on AMD CPUs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

All,

in the light of erratum #573 I'm wondering if we need to tweak or
conditionally suppress fsincos emulation. The question is whether there
is any possibility for getting the emulator to hit this instruction on AMD
(as no real mode emulation ought to be taking place there), i.e.
whether there are places where emulation gets continued eagerly
in anticipation of the need for emulation on a nearby instruction. I
don't think that's happening, but I'd like to be certain.

Even in the absence of any present possibility I would question
whether it wouldn't make sense to filter this situation so that there's
no latent potential for running into problems here (read: opening a
security hole) in the future.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 08:40:17 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 08:40:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rb6qg-0003um-0z; Thu, 15 Dec 2011 08:39:30 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Rb6qe-0003uh-KU
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 08:39:28 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1323938267!57381926!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16806 invoked from network); 15 Dec 2011 08:37:47 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-2.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 15 Dec 2011 08:37:47 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 15 Dec 2011 08:38:36 +0000
Message-Id: <4EE9C01902000078000680CD@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 15 Dec 2011 08:38:33 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Boris Ostrovsky" <boris.ostrovsky@amd.com>,
	<christoph.egger@amd.com>,"Keir Fraser" <keir@xen.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: [Xen-devel] fsincos emulation on AMD CPUs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

All,

in the light of erratum #573 I'm wondering if we need to tweak or
conditionally suppress fsincos emulation. The question is whether there
is any possibility for getting the emulator to hit this instruction on AMD
(as no real mode emulation ought to be taking place there), i.e.
whether there are places where emulation gets continued eagerly
in anticipation of the need for emulation on a nearby instruction. I
don't think that's happening, but I'd like to be certain.

Even in the absence of any present possibility I would question
whether it wouldn't make sense to filter this situation so that there's
no latent potential for running into problems here (read: opening a
security hole) in the future.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 08:45:21 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 08:45:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rb6vs-00042z-Ra; Thu, 15 Dec 2011 08:44:52 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Rb6vq-00042k-Kg
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 08:44:50 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1323938634!8199462!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24272 invoked from network); 15 Dec 2011 08:43:54 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-12.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 15 Dec 2011 08:43:54 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 15 Dec 2011 08:43:53 +0000
Message-Id: <4EE9C15602000078000680D3@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 15 Dec 2011 08:43:50 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad@darnok.org>
References: <4EDFDF0D.2020104@hp.com>
	<4EE628D80200007800066F9E@nat28.tlf.novell.com>
	<20111214213443.GC25896@andromeda.dapyr.net>
In-Reply-To: <20111214213443.GC25896@andromeda.dapyr.net>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com, dbrace <dab@hp.com>
Subject: Re: [Xen-devel] kmap_atomic issue with SLES11SP1 32bit XEN driver
 code
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 14.12.11 at 22:34, Konrad Rzeszutek Wilk <konrad@darnok.org> wrote:
> I don't know much about the SLES kernels, but if it uses lazy page
> updating it might be hitting:
> 
> 2cd1c8d x86/paravirt: PTE updates in k(un)map_atomic need to be
> synchronous, regardless of lazy_mmu mode

We use lazy mode, but only in non-IRQ (and theoretically
preemption-enabled; theoretically because PREEMPT isn't a
permitted config option in the forward ported kernels) context.
That is, we'd be susceptible to this problem only if within a
lazy-mode enabled section k{,un}map_atomic were used
synchronously (which I'd consider a coding mistake).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 08:45:21 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 08:45:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rb6vs-00042z-Ra; Thu, 15 Dec 2011 08:44:52 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Rb6vq-00042k-Kg
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 08:44:50 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1323938634!8199462!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24272 invoked from network); 15 Dec 2011 08:43:54 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-12.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 15 Dec 2011 08:43:54 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 15 Dec 2011 08:43:53 +0000
Message-Id: <4EE9C15602000078000680D3@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 15 Dec 2011 08:43:50 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad@darnok.org>
References: <4EDFDF0D.2020104@hp.com>
	<4EE628D80200007800066F9E@nat28.tlf.novell.com>
	<20111214213443.GC25896@andromeda.dapyr.net>
In-Reply-To: <20111214213443.GC25896@andromeda.dapyr.net>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com, dbrace <dab@hp.com>
Subject: Re: [Xen-devel] kmap_atomic issue with SLES11SP1 32bit XEN driver
 code
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 14.12.11 at 22:34, Konrad Rzeszutek Wilk <konrad@darnok.org> wrote:
> I don't know much about the SLES kernels, but if it uses lazy page
> updating it might be hitting:
> 
> 2cd1c8d x86/paravirt: PTE updates in k(un)map_atomic need to be
> synchronous, regardless of lazy_mmu mode

We use lazy mode, but only in non-IRQ (and theoretically
preemption-enabled; theoretically because PREEMPT isn't a
permitted config option in the forward ported kernels) context.
That is, we'd be susceptible to this problem only if within a
lazy-mode enabled section k{,un}map_atomic were used
synchronously (which I'd consider a coding mistake).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 08:46:43 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 08: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.xensource.com>)
	id 1Rb6x9-00046i-Al; Thu, 15 Dec 2011 08:46:11 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Rb6x7-00046V-Q3
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 08:46:10 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1323938664!60821720!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2995 invoked from network); 15 Dec 2011 08:44:25 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-7.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 15 Dec 2011 08:44:25 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 15 Dec 2011 08:45:17 +0000
Message-Id: <4EE9C1AA02000078000680D6@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 15 Dec 2011 08:45:14 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "dbrace" <dab@hp.com>
References: <4EDFDF0D.2020104@hp.com>
	<4EE628D80200007800066F9E@nat28.tlf.novell.com>
	<4EE943BA.6010202@hp.com>
In-Reply-To: <4EE943BA.6010202@hp.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com,
	"scameron@beardog.cce.hp.com" <scameron@beardog.cce.hp.com>
Subject: Re: [Xen-devel] kmap_atomic issue with SLES11SP1 32bit XEN driver
 code
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 15.12.11 at 01:47, dbrace <dab@hp.com> wrote:
>> >... without knowing where you got physical_address from it's impossible
>>>to tell whether your problem is that under Xen physical and machine
>>>(sometimes called "bus") addresses being distinct (end hence you're
> ??possibly lacking a translation between the two).
> 
> 
> Is there a way to tell from the address is this is happening?

It's likely, but as said in my earlier reply - "without knowing where you
got physical_address from it's impossible to tell".

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 08:46:43 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 08: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.xensource.com>)
	id 1Rb6x9-00046i-Al; Thu, 15 Dec 2011 08:46:11 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Rb6x7-00046V-Q3
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 08:46:10 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1323938664!60821720!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2995 invoked from network); 15 Dec 2011 08:44:25 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-7.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 15 Dec 2011 08:44:25 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 15 Dec 2011 08:45:17 +0000
Message-Id: <4EE9C1AA02000078000680D6@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 15 Dec 2011 08:45:14 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "dbrace" <dab@hp.com>
References: <4EDFDF0D.2020104@hp.com>
	<4EE628D80200007800066F9E@nat28.tlf.novell.com>
	<4EE943BA.6010202@hp.com>
In-Reply-To: <4EE943BA.6010202@hp.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com,
	"scameron@beardog.cce.hp.com" <scameron@beardog.cce.hp.com>
Subject: Re: [Xen-devel] kmap_atomic issue with SLES11SP1 32bit XEN driver
 code
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 15.12.11 at 01:47, dbrace <dab@hp.com> wrote:
>> >... without knowing where you got physical_address from it's impossible
>>>to tell whether your problem is that under Xen physical and machine
>>>(sometimes called "bus") addresses being distinct (end hence you're
> ??possibly lacking a translation between the two).
> 
> 
> Is there a way to tell from the address is this is happening?

It's likely, but as said in my earlier reply - "without knowing where you
got physical_address from it's impossible to tell".

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 08:56:01 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 08:56:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rb76K-0004fH-1y; Thu, 15 Dec 2011 08:55:40 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <gcvxd-xen-devel@m.gmane.org>) id 1Rb76I-0004f6-Eg
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 08:55:38 +0000
X-Env-Sender: gcvxd-xen-devel@m.gmane.org
X-Msg-Ref: server-10.tower-174.messagelabs.com!1323939281!5646579!1
X-Originating-IP: [80.91.229.12]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6057 invoked from network); 15 Dec 2011 08:54:41 -0000
Received: from lo.gmane.org (HELO lo.gmane.org) (80.91.229.12)
	by server-10.tower-174.messagelabs.com with SMTP;
	15 Dec 2011 08:54:41 -0000
Received: from list by lo.gmane.org with local (Exim 4.69)
	(envelope-from <gcvxd-xen-devel@m.gmane.org>) id 1Rb75H-00078a-SA
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 09:54:35 +0100
Received: from 93-34-178-147.ip50.fastwebnet.it ([93.34.178.147])
	by main.gmane.org with esmtp (Gmexim 0.1 (Debian))
	id 1AlnuQ-0007hv-00
	for <xen-devel@lists.xensource.com>; Thu, 15 Dec 2011 09:54:35 +0100
Received: from pbonzini by 93-34-178-147.ip50.fastwebnet.it with local (Gmexim
	0.1 (Debian)) id 1AlnuQ-0007hv-00
	for <xen-devel@lists.xensource.com>; Thu, 15 Dec 2011 09:54:35 +0100
X-Injected-Via-Gmane: http://gmane.org/
To: xen-devel@lists.xensource.com
From: Paolo Bonzini <pbonzini@redhat.com>
Date: Thu, 15 Dec 2011 09:54:22 +0100
Lines: 27
Message-ID: <jcccjv$5jf$1@dough.gmane.org>
References: <4EE9C01902000078000680CD@nat28.tlf.novell.com>
Mime-Version: 1.0
X-Complaints-To: usenet@dough.gmane.org
X-Gmane-NNTP-Posting-Host: 93-34-178-147.ip50.fastwebnet.it
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:7.0.1) Gecko/20110930 Thunderbird/7.0.1
In-Reply-To: <4EE9C01902000078000680CD@nat28.tlf.novell.com>
Subject: Re: [Xen-devel] fsincos emulation on AMD CPUs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 12/15/2011 09:38 AM, Jan Beulich wrote:
> All,
>
> in the light of erratum #573 I'm wondering if we need to tweak or
> conditionally suppress fsincos emulation. The question is whether there
> is any possibility for getting the emulator to hit this instruction on AMD
> (as no real mode emulation ought to be taking place there), i.e.
> whether there are places where emulation gets continued eagerly
> in anticipation of the need for emulation on a nearby instruction.

This can happen with PAE + shadow pagetables.

There's also the case when a user process issues an instruction to an 
MMIO region, and another thread replaces the instruction with another 
(fsincos in this case), racing with the emulator until the emulator sees 
fsincos instead of the MMIO instruction.

If you really cared, perhaps fsincos can be replaced by this sequence in 
the emulator:

                     ; x
     fld   %st       ; x x
     fsin            ; x sin(x)
     fxch  %st(1)    ; sin(x) x
     fcos            ; sin(x) cos(x)

Paolo


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 08:56:01 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 08:56:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rb76K-0004fH-1y; Thu, 15 Dec 2011 08:55:40 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <gcvxd-xen-devel@m.gmane.org>) id 1Rb76I-0004f6-Eg
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 08:55:38 +0000
X-Env-Sender: gcvxd-xen-devel@m.gmane.org
X-Msg-Ref: server-10.tower-174.messagelabs.com!1323939281!5646579!1
X-Originating-IP: [80.91.229.12]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6057 invoked from network); 15 Dec 2011 08:54:41 -0000
Received: from lo.gmane.org (HELO lo.gmane.org) (80.91.229.12)
	by server-10.tower-174.messagelabs.com with SMTP;
	15 Dec 2011 08:54:41 -0000
Received: from list by lo.gmane.org with local (Exim 4.69)
	(envelope-from <gcvxd-xen-devel@m.gmane.org>) id 1Rb75H-00078a-SA
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 09:54:35 +0100
Received: from 93-34-178-147.ip50.fastwebnet.it ([93.34.178.147])
	by main.gmane.org with esmtp (Gmexim 0.1 (Debian))
	id 1AlnuQ-0007hv-00
	for <xen-devel@lists.xensource.com>; Thu, 15 Dec 2011 09:54:35 +0100
Received: from pbonzini by 93-34-178-147.ip50.fastwebnet.it with local (Gmexim
	0.1 (Debian)) id 1AlnuQ-0007hv-00
	for <xen-devel@lists.xensource.com>; Thu, 15 Dec 2011 09:54:35 +0100
X-Injected-Via-Gmane: http://gmane.org/
To: xen-devel@lists.xensource.com
From: Paolo Bonzini <pbonzini@redhat.com>
Date: Thu, 15 Dec 2011 09:54:22 +0100
Lines: 27
Message-ID: <jcccjv$5jf$1@dough.gmane.org>
References: <4EE9C01902000078000680CD@nat28.tlf.novell.com>
Mime-Version: 1.0
X-Complaints-To: usenet@dough.gmane.org
X-Gmane-NNTP-Posting-Host: 93-34-178-147.ip50.fastwebnet.it
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:7.0.1) Gecko/20110930 Thunderbird/7.0.1
In-Reply-To: <4EE9C01902000078000680CD@nat28.tlf.novell.com>
Subject: Re: [Xen-devel] fsincos emulation on AMD CPUs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 12/15/2011 09:38 AM, Jan Beulich wrote:
> All,
>
> in the light of erratum #573 I'm wondering if we need to tweak or
> conditionally suppress fsincos emulation. The question is whether there
> is any possibility for getting the emulator to hit this instruction on AMD
> (as no real mode emulation ought to be taking place there), i.e.
> whether there are places where emulation gets continued eagerly
> in anticipation of the need for emulation on a nearby instruction.

This can happen with PAE + shadow pagetables.

There's also the case when a user process issues an instruction to an 
MMIO region, and another thread replaces the instruction with another 
(fsincos in this case), racing with the emulator until the emulator sees 
fsincos instead of the MMIO instruction.

If you really cared, perhaps fsincos can be replaced by this sequence in 
the emulator:

                     ; x
     fld   %st       ; x x
     fsin            ; x sin(x)
     fxch  %st(1)    ; sin(x) x
     fcos            ; sin(x) cos(x)

Paolo


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 09:26:45 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 09:26:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rb7Zw-0005RI-C9; Thu, 15 Dec 2011 09:26:16 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rb7Zu-0005Qs-MK
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 09:26:14 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1323941118!6980991!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjI2MA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26598 invoked from network); 15 Dec 2011 09:25:18 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 09:25:18 -0000
X-IronPort-AV: E=Sophos;i="4.71,356,1320624000"; 
   d="scan'208";a="9482649"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Dec 2011 09:24:15 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 15 Dec 2011 09:24:15 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Date: Thu, 15 Dec 2011 09:24:15 +0000
In-Reply-To: <alpine.DEB.2.00.1112141641280.3517@kaball-desktop>
References: <alpine.DEB.2.00.1111221551510.31179@kaball-desktop>
	<1322056320-5826-5-git-send-email-stefano.stabellini@eu.citrix.com>
	<20198.15417.932169.223332@mariner.uk.xensource.com>
	<1323712001.20077.234.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1112121924520.3517@kaball-desktop>
	<20199.24118.465585.933183@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1112131720250.3517@kaball-desktop>
	<20199.37117.779165.894809@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1112131817300.3517@kaball-desktop>
	<1323855739.20077.365.camel@zakaz.uk.xensource.com>
	<20200.36536.187256.61611@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1112141641280.3517@kaball-desktop>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323941055.20077.443.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "Keir \(Xen.org\)" <keir@xen.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v9 5/6] Clone and build Seabios by default
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2011-12-14 at 16:59 +0000, Stefano Stabellini wrote:
> On Wed, 14 Dec 2011, Ian Jackson wrote:
> > Ian Campbell writes ("Re: [Xen-devel] [PATCH v9 5/6] Clone and build Seabios by default"):
> > > Unfortunately I expect that distros will want to package qemu once (from
> > > upstream) with support for all the various options, including Xen,
> > > enabled and depend on that in their Xen packaging rather than packaging
> > > a slightly different qemu a second time.
> > 
> > Quite.
> 
> Considering that Qemu releases are not in sync with our releases, I
> think that we should point xen-unstable to one of our own Qemu trees
> rather than just a mirror of the Qemu stable branch on xenbits.
> Otherwise we risk loosing important features, for example if there are
> not going to be any new Qemu releases before Xen 4.2 is out, we are
> going to miss pci passthrough and save/restore, while if we had our own
> branch we would have them.
> Of course it is still very important to keep Qemu stable branches stable
> and functional, so that if distros decide to package a single upstream
> Qemu, it still going to work fine, even though it is going to have fewer
> features.

Agreed, all these trees are very important and therefore we must test
all of them, although perhaps not in the same way as we currently test
things.

How about this:

We host a qemu tree including a staging branch and associated push gate.
This tree tracks the current qemu stable branch and contains backports
of patches which have been applied to the current qemu development
branch (using a policy similar to the Linux stable series policy, in
order to prevent accidental forking). We point xen-devel at this and it
is used by the regular testing machinery and forms part of the Xen
releases.

Then as a separate independent test we periodically (e.g. weekly or
twice-weekly) test the upstream qemu development branch against some
baseline version of Xen (e.g. the most recent pass of either unstable or
current stable branch). This test doesn't gate anything but is just to
keep tabs on the development branch and spot regressions earlier etc.

Lastly we also test any releases (rc and final, perhaps beta) on both
the qemu stable and development branches against current latest unstable
and stable Xen branches. Again this doesn't gate anything but just keeps
tabs on things.

BTW I think periodic test + rc&releases is how we should handle Linux
upstream too and indeed any other external dependency which runs on a
disconnected schedule.

Ian.

> 
> 
> > > > I don't have an opinion on seabios because I am nore sure how many
> > > > changes are we going to make to it. However I recall that you and/or
> > > > IanC were in favor of having or own branch of seabios as well.
> > > 
> > > I think that even if we never diverge from upstream and irrespective of
> > > whether we stick in lockstep or not we should host a tree to point our
> > > users (and default build) at. This gives us flexibility if we ever do
> > > need to diverge and also isolates our users from issues with 3rd party
> > > servers.
> > 
> > Indeed so.  But should it be one tree for each Xen branch, and does it
> > need a push gate ?
>  
> I think we might do without a tree for each Xen branch because we need
> to support building upstream Qemu against Xen 4.2+ anyway.
> Let's say that we have released Xen 4.2, we are now in the Xen 4.3
> release cycle and we want to introduce an incompatible change in Qemu:
> we would need to add a compatibility layer to allow it to build and run
> on Xen 4.2 anyway.
> The difficulty having a single tree would be keeping track of the
> changes only present in our own tree, and possibly revert them before
> pulling new commits from upstream that implement the same features in a
> different way.
> 
> Regarding the push-gate, I am OK with it.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 09:26:45 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 09:26:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rb7Zw-0005RI-C9; Thu, 15 Dec 2011 09:26:16 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rb7Zu-0005Qs-MK
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 09:26:14 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1323941118!6980991!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjI2MA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26598 invoked from network); 15 Dec 2011 09:25:18 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 09:25:18 -0000
X-IronPort-AV: E=Sophos;i="4.71,356,1320624000"; 
   d="scan'208";a="9482649"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Dec 2011 09:24:15 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 15 Dec 2011 09:24:15 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Date: Thu, 15 Dec 2011 09:24:15 +0000
In-Reply-To: <alpine.DEB.2.00.1112141641280.3517@kaball-desktop>
References: <alpine.DEB.2.00.1111221551510.31179@kaball-desktop>
	<1322056320-5826-5-git-send-email-stefano.stabellini@eu.citrix.com>
	<20198.15417.932169.223332@mariner.uk.xensource.com>
	<1323712001.20077.234.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1112121924520.3517@kaball-desktop>
	<20199.24118.465585.933183@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1112131720250.3517@kaball-desktop>
	<20199.37117.779165.894809@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1112131817300.3517@kaball-desktop>
	<1323855739.20077.365.camel@zakaz.uk.xensource.com>
	<20200.36536.187256.61611@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1112141641280.3517@kaball-desktop>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323941055.20077.443.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "Keir \(Xen.org\)" <keir@xen.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v9 5/6] Clone and build Seabios by default
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2011-12-14 at 16:59 +0000, Stefano Stabellini wrote:
> On Wed, 14 Dec 2011, Ian Jackson wrote:
> > Ian Campbell writes ("Re: [Xen-devel] [PATCH v9 5/6] Clone and build Seabios by default"):
> > > Unfortunately I expect that distros will want to package qemu once (from
> > > upstream) with support for all the various options, including Xen,
> > > enabled and depend on that in their Xen packaging rather than packaging
> > > a slightly different qemu a second time.
> > 
> > Quite.
> 
> Considering that Qemu releases are not in sync with our releases, I
> think that we should point xen-unstable to one of our own Qemu trees
> rather than just a mirror of the Qemu stable branch on xenbits.
> Otherwise we risk loosing important features, for example if there are
> not going to be any new Qemu releases before Xen 4.2 is out, we are
> going to miss pci passthrough and save/restore, while if we had our own
> branch we would have them.
> Of course it is still very important to keep Qemu stable branches stable
> and functional, so that if distros decide to package a single upstream
> Qemu, it still going to work fine, even though it is going to have fewer
> features.

Agreed, all these trees are very important and therefore we must test
all of them, although perhaps not in the same way as we currently test
things.

How about this:

We host a qemu tree including a staging branch and associated push gate.
This tree tracks the current qemu stable branch and contains backports
of patches which have been applied to the current qemu development
branch (using a policy similar to the Linux stable series policy, in
order to prevent accidental forking). We point xen-devel at this and it
is used by the regular testing machinery and forms part of the Xen
releases.

Then as a separate independent test we periodically (e.g. weekly or
twice-weekly) test the upstream qemu development branch against some
baseline version of Xen (e.g. the most recent pass of either unstable or
current stable branch). This test doesn't gate anything but is just to
keep tabs on the development branch and spot regressions earlier etc.

Lastly we also test any releases (rc and final, perhaps beta) on both
the qemu stable and development branches against current latest unstable
and stable Xen branches. Again this doesn't gate anything but just keeps
tabs on things.

BTW I think periodic test + rc&releases is how we should handle Linux
upstream too and indeed any other external dependency which runs on a
disconnected schedule.

Ian.

> 
> 
> > > > I don't have an opinion on seabios because I am nore sure how many
> > > > changes are we going to make to it. However I recall that you and/or
> > > > IanC were in favor of having or own branch of seabios as well.
> > > 
> > > I think that even if we never diverge from upstream and irrespective of
> > > whether we stick in lockstep or not we should host a tree to point our
> > > users (and default build) at. This gives us flexibility if we ever do
> > > need to diverge and also isolates our users from issues with 3rd party
> > > servers.
> > 
> > Indeed so.  But should it be one tree for each Xen branch, and does it
> > need a push gate ?
>  
> I think we might do without a tree for each Xen branch because we need
> to support building upstream Qemu against Xen 4.2+ anyway.
> Let's say that we have released Xen 4.2, we are now in the Xen 4.3
> release cycle and we want to introduce an incompatible change in Qemu:
> we would need to add a compatibility layer to allow it to build and run
> on Xen 4.2 anyway.
> The difficulty having a single tree would be keeping track of the
> changes only present in our own tree, and possibly revert them before
> pulling new commits from upstream that implement the same features in a
> different way.
> 
> Regarding the push-gate, I am OK with it.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 09:35:56 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 09: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.xensource.com>)
	id 1Rb7iu-0005kq-Ds; Thu, 15 Dec 2011 09:35:32 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Rb7is-0005kY-Sf
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 09:35:31 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1323941674!5658057!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20028 invoked from network); 15 Dec 2011 09:34:34 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-9.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 15 Dec 2011 09:34:34 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 15 Dec 2011 09:34:33 +0000
Message-Id: <4EE9CD3602000078000680F3@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 15 Dec 2011 09:34:30 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tim Deegan" <tim@xen.org>
References: <3ab01c6cd13fcaaa0d25.1322744193@elijah>
In-Reply-To: <3ab01c6cd13fcaaa0d25.1322744193@elijah>
Mime-Version: 1.0
Content-Disposition: inline
Cc: george.dunlap@eu.citrix.com, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] Backport fixes to PoD codepaths related to
 1GiB pages
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Should this get applied?

>>> On 01.12.11 at 13:56, George Dunlap <george.dunlap@eu.citrix.com> wrote:
> Backport of xen-unstable.hg c/s 24189:7da681c490e0 to xen-4.1-testing
> 
> The codepaths in p2m_gfn_to_mfn() and p2m_gfn_to_mfn_current() should
> call p2m_pod_check_and_popualte(), as the 2MiB and 4k codepaths do.
> This properly grabs the p2m lock.
> 
> Also, p2m_pod_demand_populate() shouldn't call p2m_unlock(), as it
> didn't grab the lock in the first place.
> 
> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
> Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
> 
> diff -r c613d436ca09 -r 3ab01c6cd13f xen/arch/x86/mm/p2m.c
> --- a/xen/arch/x86/mm/p2m.c	Tue Nov 22 19:03:04 2011 +0000
> +++ b/xen/arch/x86/mm/p2m.c	Thu Dec 01 12:56:18 2011 +0000
> @@ -1244,7 +1244,6 @@ p2m_pod_demand_populate(struct p2m_domai
>          set_p2m_entry(p2m, gfn_aligned, _mfn(POPULATE_ON_DEMAND_MFN), 9,
>                        p2m_populate_on_demand, p2m->default_access);
>          audit_p2m(p2m, 1);
> -        p2m_unlock(p2m);
>          return 0;
>      }
>  
> @@ -1602,7 +1601,8 @@ pod_retry_l3:
>              {
>                  if ( q != p2m_query )
>                  {
> -                    if ( !p2m_pod_demand_populate(p2m, gfn, 18, q) )
> +                    if ( !p2m_pod_check_and_populate(p2m, gfn,
> +                              (l1_pgentry_t *) &l3e, 18, q) )
>                          goto pod_retry_l3;
>                  }
>                  else
> @@ -1733,7 +1733,8 @@ static mfn_t p2m_gfn_to_mfn_current(stru
>                  /* The read has succeeded, so we know that mapping exists 
> */
>                  if ( q != p2m_query )
>                  {
> -                    if ( !p2m_pod_demand_populate(p2m, gfn, 18, q) )
> +                    if ( !p2m_pod_check_and_populate(p2m, gfn,
> +                              (l1_pgentry_t *) &l3e, 18, q) )
>                          goto pod_retry_l3;
>                      p2mt = p2m_invalid;
>                      printk("%s: Allocate 1GB failed!\n", __func__);
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com 
> http://lists.xensource.com/xen-devel 




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 09:35:56 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 09: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.xensource.com>)
	id 1Rb7iu-0005kq-Ds; Thu, 15 Dec 2011 09:35:32 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Rb7is-0005kY-Sf
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 09:35:31 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1323941674!5658057!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20028 invoked from network); 15 Dec 2011 09:34:34 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-9.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 15 Dec 2011 09:34:34 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 15 Dec 2011 09:34:33 +0000
Message-Id: <4EE9CD3602000078000680F3@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 15 Dec 2011 09:34:30 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tim Deegan" <tim@xen.org>
References: <3ab01c6cd13fcaaa0d25.1322744193@elijah>
In-Reply-To: <3ab01c6cd13fcaaa0d25.1322744193@elijah>
Mime-Version: 1.0
Content-Disposition: inline
Cc: george.dunlap@eu.citrix.com, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] Backport fixes to PoD codepaths related to
 1GiB pages
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Should this get applied?

>>> On 01.12.11 at 13:56, George Dunlap <george.dunlap@eu.citrix.com> wrote:
> Backport of xen-unstable.hg c/s 24189:7da681c490e0 to xen-4.1-testing
> 
> The codepaths in p2m_gfn_to_mfn() and p2m_gfn_to_mfn_current() should
> call p2m_pod_check_and_popualte(), as the 2MiB and 4k codepaths do.
> This properly grabs the p2m lock.
> 
> Also, p2m_pod_demand_populate() shouldn't call p2m_unlock(), as it
> didn't grab the lock in the first place.
> 
> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
> Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
> 
> diff -r c613d436ca09 -r 3ab01c6cd13f xen/arch/x86/mm/p2m.c
> --- a/xen/arch/x86/mm/p2m.c	Tue Nov 22 19:03:04 2011 +0000
> +++ b/xen/arch/x86/mm/p2m.c	Thu Dec 01 12:56:18 2011 +0000
> @@ -1244,7 +1244,6 @@ p2m_pod_demand_populate(struct p2m_domai
>          set_p2m_entry(p2m, gfn_aligned, _mfn(POPULATE_ON_DEMAND_MFN), 9,
>                        p2m_populate_on_demand, p2m->default_access);
>          audit_p2m(p2m, 1);
> -        p2m_unlock(p2m);
>          return 0;
>      }
>  
> @@ -1602,7 +1601,8 @@ pod_retry_l3:
>              {
>                  if ( q != p2m_query )
>                  {
> -                    if ( !p2m_pod_demand_populate(p2m, gfn, 18, q) )
> +                    if ( !p2m_pod_check_and_populate(p2m, gfn,
> +                              (l1_pgentry_t *) &l3e, 18, q) )
>                          goto pod_retry_l3;
>                  }
>                  else
> @@ -1733,7 +1733,8 @@ static mfn_t p2m_gfn_to_mfn_current(stru
>                  /* The read has succeeded, so we know that mapping exists 
> */
>                  if ( q != p2m_query )
>                  {
> -                    if ( !p2m_pod_demand_populate(p2m, gfn, 18, q) )
> +                    if ( !p2m_pod_check_and_populate(p2m, gfn,
> +                              (l1_pgentry_t *) &l3e, 18, q) )
>                          goto pod_retry_l3;
>                      p2mt = p2m_invalid;
>                      printk("%s: Allocate 1GB failed!\n", __func__);
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com 
> http://lists.xensource.com/xen-devel 




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 09:37:45 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 09:37:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rb7ki-00066D-3R; Thu, 15 Dec 2011 09:37:24 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rb7kg-00065t-Jo
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 09:37:22 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1323941786!5587351!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjI2MA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8653 invoked from network); 15 Dec 2011 09:36:26 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 09:36:26 -0000
X-IronPort-AV: E=Sophos;i="4.71,356,1320624000"; 
   d="scan'208";a="9483003"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Dec 2011 09:36:25 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 15 Dec 2011 09:36:25 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Thu, 15 Dec 2011 09:36:25 +0000
In-Reply-To: <patchbomb.1323792779@cosworth.uk.xensource.com>
References: <patchbomb.1323792779@cosworth.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323941785.20077.447.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Vincent Hanquez <Vincent.Hanquez@eu.citrix.com>,
	Olaf Hering <olaf@aepfle.de>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Jonathan Ludlam <Jonathan.Ludlam@eu.citrix.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH 0 of 4 V2] oxenstored fixes -- fixes recent
 pvops kernel hang
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian,

On Tue, 2011-12-13 at 16:12 +0000, Ian Campbell wrote:
> I also include a patch which I've been using for some time to enable
> the use of oxenstored in preference to C xenstored when available.

Can you also arrange for the test system to
collect /etc/xen/oxenstored.conf, /var/log/xenstored.conf*
and /var/log/xenstored-access.log* please.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 09:37:45 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 09:37:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rb7ki-00066D-3R; Thu, 15 Dec 2011 09:37:24 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rb7kg-00065t-Jo
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 09:37:22 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1323941786!5587351!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjI2MA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8653 invoked from network); 15 Dec 2011 09:36:26 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 09:36:26 -0000
X-IronPort-AV: E=Sophos;i="4.71,356,1320624000"; 
   d="scan'208";a="9483003"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Dec 2011 09:36:25 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 15 Dec 2011 09:36:25 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Thu, 15 Dec 2011 09:36:25 +0000
In-Reply-To: <patchbomb.1323792779@cosworth.uk.xensource.com>
References: <patchbomb.1323792779@cosworth.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323941785.20077.447.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Vincent Hanquez <Vincent.Hanquez@eu.citrix.com>,
	Olaf Hering <olaf@aepfle.de>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Jonathan Ludlam <Jonathan.Ludlam@eu.citrix.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH 0 of 4 V2] oxenstored fixes -- fixes recent
 pvops kernel hang
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian,

On Tue, 2011-12-13 at 16:12 +0000, Ian Campbell wrote:
> I also include a patch which I've been using for some time to enable
> the use of oxenstored in preference to C xenstored when available.

Can you also arrange for the test system to
collect /etc/xen/oxenstored.conf, /var/log/xenstored.conf*
and /var/log/xenstored-access.log* please.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 10:02:03 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 10: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.xensource.com>)
	id 1Rb87x-0006nC-Sd; Thu, 15 Dec 2011 10:01:25 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Wang2@amd.com>) id 1Rb87v-0006n3-N6
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 10:01:23 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1323943225!8211214!1
X-Originating-IP: [216.32.180.16]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13651 invoked from network); 15 Dec 2011 10:00:26 -0000
Received: from va3ehsobe006.messaging.microsoft.com (HELO
	VA3EHSOBE007.bigfish.com) (216.32.180.16)
	by server-12.tower-21.messagelabs.com with AES128-SHA encrypted SMTP;
	15 Dec 2011 10:00:26 -0000
Received: from mail54-va3-R.bigfish.com (10.7.14.240) by
	VA3EHSOBE007.bigfish.com (10.7.40.11) with Microsoft SMTP Server id
	14.1.225.23; Thu, 15 Dec 2011 10:00:25 +0000
Received: from mail54-va3 (localhost [127.0.0.1])	by mail54-va3-R.bigfish.com
	(Postfix) with ESMTP id 3135D80226;
	Thu, 15 Dec 2011 10:00:30 +0000 (UTC)
X-SpamScore: -13
X-BigFish: VPS-13(zz1432N98dK4015Lzz1202hzz8275bhz2dh668h839h61h)
X-Spam-TCS-SCL: 0:0
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
Received: from mail54-va3 (localhost.localdomain [127.0.0.1]) by mail54-va3
	(MessageSwitch) id 1323943229862182_29517;
	Thu, 15 Dec 2011 10:00:29 +0000 (UTC)
Received: from VA3EHSMHS029.bigfish.com (unknown [10.7.14.240])	by
	mail54-va3.bigfish.com (Postfix) with ESMTP id C1D80280045;
	Thu, 15 Dec 2011 10:00:29 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	VA3EHSMHS029.bigfish.com (10.7.99.39) with Microsoft SMTP Server id
	14.1.225.23; Thu, 15 Dec 2011 10:00:24 +0000
X-WSS-ID: 0LW8P4K-01-13E-02
X-M-MSG: 
Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com
	[163.181.249.73])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2A23C102805C;	Thu, 15 Dec 2011 04:00:20 -0600 (CST)
Received: from SAUSEXDAG01.amd.com (163.181.55.1) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Thu, 15 Dec 2011 04:00:34 -0600
Received: from storexhtp01.amd.com (172.24.4.3) by sausexdag01.amd.com
	(163.181.55.1) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Thu, 15 Dec 2011 04:00:20 -0600
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp01.amd.com
	(172.24.4.3) with Microsoft SMTP Server id 8.3.213.0; Thu, 15 Dec 2011
	04:59:34 -0500
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 58F2749C34C; Thu, 15 Dec 2011
	09:59:33 +0000 (GMT)
Received: from gran.osrc.amd.com (gran.osrc.amd.com [165.204.15.57])	by
	mail.osrc.amd.com (Postfix) with ESMTP id 367F75940FF; Thu, 15 Dec 2011
	10:59:33 +0100 (CET)
From: Wei Wang2 <wei.wang2@amd.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Thu, 15 Dec 2011 11:02:16 +0100
User-Agent: KMail/1.9.6 (enterprise 20070904.708012)
References: <patchbomb.1323876561@gran.amd.com>
	<201112141757.33690.wei.wang2@amd.com>
	<4EE8E50A0200007800067E44@nat28.tlf.novell.com>
In-Reply-To: <4EE8E50A0200007800067E44@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
Message-ID: <201112151102.16609.wei.wang2@amd.com>
X-OriginatorOrg: amd.com
Cc: xen-devel@lists.xensource.com, keir@xen.org
Subject: Re: [Xen-devel] [PATCH 07 of 16] amd iommu: Add 2 hypercalls for
	libxc
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wednesday 14 December 2011 18:03:54 Jan Beulich wrote:
> >>> On 14.12.11 at 17:57, Wei Wang2 <wei.wang2@amd.com> wrote:
> >
> > On Wednesday 14 December 2011 17:44:18 Jan Beulich wrote:
> >> >>> On 14.12.11 at 16:29, Wei Wang <wei.wang2@amd.com> wrote:
> >> >
> >> > # HG changeset patch
> >> > # User Wei Wang <wei.wang2@amd.com>
> >> > # Date 1323875772 -3600
> >> > # Node ID ef5698887d044ad58293bee3549eaa20310c2b17
> >> > # Parent  fbed4e6011fce13d3a521bbc339f4959bf32a06c
> >> > amd iommu: Add 2 hypercalls for libxc
> >> >
> >> > iommu_set_msi: used by qemu to inform hypervisor iommu vector number
> >> > in guest
> >> > space. Hypervisor needs this vector to inject msi into guest when PPR
> >> > logging
> >> > happens.
> >>
> >> And this cannot be done with the existing MSI emulation?
> >
> > It looks like MSI emulation are used for passthru devices. I only add
> > virtual amd iommu device and do not passthru amd iommu device. So no
> > physcal msi are required and therefore complicate msi emulation might not
> > be very necessary?
>
> Makes sense.
>
> >> > --- a/xen/include/public/domctl.h	Wed Dec 14 16:16:11 2011 +0100
> >> > +++ b/xen/include/public/domctl.h	Wed Dec 14 16:16:12 2011 +0100
> >> > @@ -848,6 +848,31 @@ struct xen_domctl_set_access_required {
> >> >  typedef struct xen_domctl_set_access_required
> >> > xen_domctl_set_access_required_t;
> >> >  DEFINE_XEN_GUEST_HANDLE(xen_domctl_set_access_required_t);
> >> >
> >> > +#if defined(__i386__) || defined(__x86_64__)
> >>
> >> What is x86-specific about these?
> >
> > These hypercalls are only used by AMD. so ia64 should be avoided
>
> Currently. But is there anything in them that makes them unusable
> for other IOMMUs in the future (from what I can tell only PCI and MSI
> are fundamentally required, which are certainly present on other
> platforms)? After all, this is just a type definition and a few manifest
> constants - I'm not asking that their implementation should be done
> for other than the case you care about right now.

Ok, I will change this in the next version. Indeed there is nothing special 
for x86 in these two hcalls. 
Thanks,
Wei 

> Jan




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 10:02:03 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 10: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.xensource.com>)
	id 1Rb87x-0006nC-Sd; Thu, 15 Dec 2011 10:01:25 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Wang2@amd.com>) id 1Rb87v-0006n3-N6
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 10:01:23 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1323943225!8211214!1
X-Originating-IP: [216.32.180.16]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13651 invoked from network); 15 Dec 2011 10:00:26 -0000
Received: from va3ehsobe006.messaging.microsoft.com (HELO
	VA3EHSOBE007.bigfish.com) (216.32.180.16)
	by server-12.tower-21.messagelabs.com with AES128-SHA encrypted SMTP;
	15 Dec 2011 10:00:26 -0000
Received: from mail54-va3-R.bigfish.com (10.7.14.240) by
	VA3EHSOBE007.bigfish.com (10.7.40.11) with Microsoft SMTP Server id
	14.1.225.23; Thu, 15 Dec 2011 10:00:25 +0000
Received: from mail54-va3 (localhost [127.0.0.1])	by mail54-va3-R.bigfish.com
	(Postfix) with ESMTP id 3135D80226;
	Thu, 15 Dec 2011 10:00:30 +0000 (UTC)
X-SpamScore: -13
X-BigFish: VPS-13(zz1432N98dK4015Lzz1202hzz8275bhz2dh668h839h61h)
X-Spam-TCS-SCL: 0:0
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
Received: from mail54-va3 (localhost.localdomain [127.0.0.1]) by mail54-va3
	(MessageSwitch) id 1323943229862182_29517;
	Thu, 15 Dec 2011 10:00:29 +0000 (UTC)
Received: from VA3EHSMHS029.bigfish.com (unknown [10.7.14.240])	by
	mail54-va3.bigfish.com (Postfix) with ESMTP id C1D80280045;
	Thu, 15 Dec 2011 10:00:29 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	VA3EHSMHS029.bigfish.com (10.7.99.39) with Microsoft SMTP Server id
	14.1.225.23; Thu, 15 Dec 2011 10:00:24 +0000
X-WSS-ID: 0LW8P4K-01-13E-02
X-M-MSG: 
Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com
	[163.181.249.73])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2A23C102805C;	Thu, 15 Dec 2011 04:00:20 -0600 (CST)
Received: from SAUSEXDAG01.amd.com (163.181.55.1) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Thu, 15 Dec 2011 04:00:34 -0600
Received: from storexhtp01.amd.com (172.24.4.3) by sausexdag01.amd.com
	(163.181.55.1) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Thu, 15 Dec 2011 04:00:20 -0600
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp01.amd.com
	(172.24.4.3) with Microsoft SMTP Server id 8.3.213.0; Thu, 15 Dec 2011
	04:59:34 -0500
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 58F2749C34C; Thu, 15 Dec 2011
	09:59:33 +0000 (GMT)
Received: from gran.osrc.amd.com (gran.osrc.amd.com [165.204.15.57])	by
	mail.osrc.amd.com (Postfix) with ESMTP id 367F75940FF; Thu, 15 Dec 2011
	10:59:33 +0100 (CET)
From: Wei Wang2 <wei.wang2@amd.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Thu, 15 Dec 2011 11:02:16 +0100
User-Agent: KMail/1.9.6 (enterprise 20070904.708012)
References: <patchbomb.1323876561@gran.amd.com>
	<201112141757.33690.wei.wang2@amd.com>
	<4EE8E50A0200007800067E44@nat28.tlf.novell.com>
In-Reply-To: <4EE8E50A0200007800067E44@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
Message-ID: <201112151102.16609.wei.wang2@amd.com>
X-OriginatorOrg: amd.com
Cc: xen-devel@lists.xensource.com, keir@xen.org
Subject: Re: [Xen-devel] [PATCH 07 of 16] amd iommu: Add 2 hypercalls for
	libxc
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wednesday 14 December 2011 18:03:54 Jan Beulich wrote:
> >>> On 14.12.11 at 17:57, Wei Wang2 <wei.wang2@amd.com> wrote:
> >
> > On Wednesday 14 December 2011 17:44:18 Jan Beulich wrote:
> >> >>> On 14.12.11 at 16:29, Wei Wang <wei.wang2@amd.com> wrote:
> >> >
> >> > # HG changeset patch
> >> > # User Wei Wang <wei.wang2@amd.com>
> >> > # Date 1323875772 -3600
> >> > # Node ID ef5698887d044ad58293bee3549eaa20310c2b17
> >> > # Parent  fbed4e6011fce13d3a521bbc339f4959bf32a06c
> >> > amd iommu: Add 2 hypercalls for libxc
> >> >
> >> > iommu_set_msi: used by qemu to inform hypervisor iommu vector number
> >> > in guest
> >> > space. Hypervisor needs this vector to inject msi into guest when PPR
> >> > logging
> >> > happens.
> >>
> >> And this cannot be done with the existing MSI emulation?
> >
> > It looks like MSI emulation are used for passthru devices. I only add
> > virtual amd iommu device and do not passthru amd iommu device. So no
> > physcal msi are required and therefore complicate msi emulation might not
> > be very necessary?
>
> Makes sense.
>
> >> > --- a/xen/include/public/domctl.h	Wed Dec 14 16:16:11 2011 +0100
> >> > +++ b/xen/include/public/domctl.h	Wed Dec 14 16:16:12 2011 +0100
> >> > @@ -848,6 +848,31 @@ struct xen_domctl_set_access_required {
> >> >  typedef struct xen_domctl_set_access_required
> >> > xen_domctl_set_access_required_t;
> >> >  DEFINE_XEN_GUEST_HANDLE(xen_domctl_set_access_required_t);
> >> >
> >> > +#if defined(__i386__) || defined(__x86_64__)
> >>
> >> What is x86-specific about these?
> >
> > These hypercalls are only used by AMD. so ia64 should be avoided
>
> Currently. But is there anything in them that makes them unusable
> for other IOMMUs in the future (from what I can tell only PCI and MSI
> are fundamentally required, which are certainly present on other
> platforms)? After all, this is just a type definition and a few manifest
> constants - I'm not asking that their implementation should be done
> for other than the case you care about right now.

Ok, I will change this in the next version. Indeed there is nothing special 
for x86 in these two hcalls. 
Thanks,
Wei 

> Jan




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 10:17:20 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 10:17:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rb8Ms-0007JB-Kn; Thu, 15 Dec 2011 10:16:50 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Rb8Mr-0007J0-8B
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 10:16:49 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1323944152!7557053!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28043 invoked from network); 15 Dec 2011 10:15:52 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-7.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 15 Dec 2011 10:15:52 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 15 Dec 2011 10:15:52 +0000
Message-Id: <4EE9D6E40200007800068120@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 15 Dec 2011 10:15:48 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Paolo Bonzini" <pbonzini@redhat.com>
References: <4EE9C01902000078000680CD@nat28.tlf.novell.com>
	<jcccjv$5jf$1@dough.gmane.org>
In-Reply-To: <jcccjv$5jf$1@dough.gmane.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] fsincos emulation on AMD CPUs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 15.12.11 at 09:54, Paolo Bonzini <pbonzini@redhat.com> wrote:
> On 12/15/2011 09:38 AM, Jan Beulich wrote:
>> in the light of erratum #573 I'm wondering if we need to tweak or
>> conditionally suppress fsincos emulation. The question is whether there
>> is any possibility for getting the emulator to hit this instruction on AMD
>> (as no real mode emulation ought to be taking place there), i.e.
>> whether there are places where emulation gets continued eagerly
>> in anticipation of the need for emulation on a nearby instruction.
> 
> This can happen with PAE + shadow pagetables.

Ah okay. In that case we ought to add some workaround here.

> There's also the case when a user process issues an instruction to an 
> MMIO region, and another thread replaces the instruction with another 
> (fsincos in this case), racing with the emulator until the emulator sees 
> fsincos instead of the MMIO instruction.

Indeed, didn't think of this possibility.

> If you really cared, perhaps fsincos can be replaced by this sequence in 
> the emulator:
> 
>                      ; x
>      fld   %st       ; x x
>      fsin            ; x sin(x)
>      fxch  %st(1)    ; sin(x) x
>      fcos            ; sin(x) cos(x)

I had thought of this at first too, but this is problematic in terms of
exception handling: fpu_handle_exception() expects to see an
exception only on the very first instruction (as it's assumed to be
the only one), and aborts the rest of the sequence if the exception
doesn't happen on the last instruction.

All of this can be fixed of course, but I wonder whether it's worth
it when we really could just bail from the emulator without causing
any harm.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 10:17:20 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 10:17:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rb8Ms-0007JB-Kn; Thu, 15 Dec 2011 10:16:50 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Rb8Mr-0007J0-8B
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 10:16:49 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1323944152!7557053!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28043 invoked from network); 15 Dec 2011 10:15:52 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-7.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 15 Dec 2011 10:15:52 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 15 Dec 2011 10:15:52 +0000
Message-Id: <4EE9D6E40200007800068120@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 15 Dec 2011 10:15:48 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Paolo Bonzini" <pbonzini@redhat.com>
References: <4EE9C01902000078000680CD@nat28.tlf.novell.com>
	<jcccjv$5jf$1@dough.gmane.org>
In-Reply-To: <jcccjv$5jf$1@dough.gmane.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] fsincos emulation on AMD CPUs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 15.12.11 at 09:54, Paolo Bonzini <pbonzini@redhat.com> wrote:
> On 12/15/2011 09:38 AM, Jan Beulich wrote:
>> in the light of erratum #573 I'm wondering if we need to tweak or
>> conditionally suppress fsincos emulation. The question is whether there
>> is any possibility for getting the emulator to hit this instruction on AMD
>> (as no real mode emulation ought to be taking place there), i.e.
>> whether there are places where emulation gets continued eagerly
>> in anticipation of the need for emulation on a nearby instruction.
> 
> This can happen with PAE + shadow pagetables.

Ah okay. In that case we ought to add some workaround here.

> There's also the case when a user process issues an instruction to an 
> MMIO region, and another thread replaces the instruction with another 
> (fsincos in this case), racing with the emulator until the emulator sees 
> fsincos instead of the MMIO instruction.

Indeed, didn't think of this possibility.

> If you really cared, perhaps fsincos can be replaced by this sequence in 
> the emulator:
> 
>                      ; x
>      fld   %st       ; x x
>      fsin            ; x sin(x)
>      fxch  %st(1)    ; sin(x) x
>      fcos            ; sin(x) cos(x)

I had thought of this at first too, but this is problematic in terms of
exception handling: fpu_handle_exception() expects to see an
exception only on the very first instruction (as it's assumed to be
the only one), and aborts the rest of the sequence if the exception
doesn't happen on the last instruction.

All of this can be fixed of course, but I wonder whether it's worth
it when we really could just bail from the emulator without causing
any harm.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 10:25:28 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 10:25:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rb8Un-0007Ws-SZ; Thu, 15 Dec 2011 10:25:01 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Rb8Ul-0007Wi-Uc
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 10:25:00 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1323944643!5479249!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18411 invoked from network); 15 Dec 2011 10:24:03 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-16.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 15 Dec 2011 10:24:03 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 15 Dec 2011 10:24:03 +0000
Message-Id: <4EE9D8CE020000780006812F@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 15 Dec 2011 10:23:58 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Wang" <wei.wang2@amd.com>
References: <patchbomb.1323876561@gran.amd.com>
In-Reply-To: <patchbomb.1323876561@gran.amd.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com, keir@xen.org
Subject: Re: [Xen-devel] [PATCH 00 of 16] [RFC] amd iommu: support ATS
 device passthru on IOMMUv2 systems
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 14.12.11 at 16:29, Wei Wang <wei.wang2@amd.com> wrote:
> ATS devices with PRI and PASID capabilities can communicate with iommuv2 to 
> do 2 level (nested) DMA translation and IO demand paging. To do that, both 
> iommu driver and ats device have to been enabled in guest OS. This patch set 
> 
> adds initial iommu emulation for hvm guests to support ATS device passthru. 

I could take care of the first 6 patches in this series, as they're only
touching AMD IOMMU code and look sensible to me. I'm not sure
though whether this is a good idea without knowing the disposition
of the other 10 patches (particularly the relative large 3rd patch
doesn't seem to make sense without it later getting hooked up).

Please let me know,
Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 10:25:28 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 10:25:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rb8Un-0007Ws-SZ; Thu, 15 Dec 2011 10:25:01 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Rb8Ul-0007Wi-Uc
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 10:25:00 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1323944643!5479249!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18411 invoked from network); 15 Dec 2011 10:24:03 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-16.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 15 Dec 2011 10:24:03 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 15 Dec 2011 10:24:03 +0000
Message-Id: <4EE9D8CE020000780006812F@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 15 Dec 2011 10:23:58 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Wang" <wei.wang2@amd.com>
References: <patchbomb.1323876561@gran.amd.com>
In-Reply-To: <patchbomb.1323876561@gran.amd.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com, keir@xen.org
Subject: Re: [Xen-devel] [PATCH 00 of 16] [RFC] amd iommu: support ATS
 device passthru on IOMMUv2 systems
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 14.12.11 at 16:29, Wei Wang <wei.wang2@amd.com> wrote:
> ATS devices with PRI and PASID capabilities can communicate with iommuv2 to 
> do 2 level (nested) DMA translation and IO demand paging. To do that, both 
> iommu driver and ats device have to been enabled in guest OS. This patch set 
> 
> adds initial iommu emulation for hvm guests to support ATS device passthru. 

I could take care of the first 6 patches in this series, as they're only
touching AMD IOMMU code and look sensible to me. I'm not sure
though whether this is a good idea without knowing the disposition
of the other 10 patches (particularly the relative large 3rd patch
doesn't seem to make sense without it later getting hooked up).

Please let me know,
Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 10:26:54 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 10: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.xensource.com>)
	id 1Rb8WG-0007ah-C2; Thu, 15 Dec 2011 10:26:32 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Rb8WE-0007aN-VD
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 10:26:31 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1323944733!5629366!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10346 invoked from network); 15 Dec 2011 10:25:34 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-2.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 15 Dec 2011 10:25:34 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 15 Dec 2011 10:25:33 +0000
Message-Id: <4EE9D92A020000780006813A@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 15 Dec 2011 10:25:30 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part0E21A40A.0__="
Subject: [Xen-devel] [PATCH] x86: convert BUG_ON()s to WARN_ON()s in
 read_descriptor()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__Part0E21A40A.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

In the light of AMD erratum #700, and given that these checks happen
for debugging purposes only and also only in debug builds of the
hypervisor, make the failures non-fatal.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -1544,11 +1544,11 @@ static int read_descriptor(unsigned int=20
             asm volatile (
                 "larl %2,%0 ; setz %1"
                 : "=3Dr" (a), "=3Dqm" (valid) : "rm" (sel));
-            BUG_ON(valid && ((a & 0x00f0ff00) !=3D *ar));
+            WARN_ON(valid && ((a & 0x00f0ff00) !=3D *ar));
             asm volatile (
                 "lsll %2,%0 ; setz %1"
                 : "=3Dr" (l), "=3Dqm" (valid) : "rm" (sel));
-            BUG_ON(valid && (l !=3D *limit));
+            WARN_ON(valid && (l !=3D *limit));
         }
 #endif
     }




--=__Part0E21A40A.0__=
Content-Type: text/plain; name="amd-erratum-700.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="amd-erratum-700.patch"

x86: convert BUG_ON()s to WARN_ON()s in read_descriptor()=0A=0AIn the =
light of AMD erratum #700, and given that these checks happen=0Afor =
debugging purposes only and also only in debug builds of the=0Ahypervisor, =
make the failures non-fatal.=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@@ =
-1544,11 +1544,11 @@ static int read_descriptor(unsigned int =0A           =
  asm volatile (=0A                 "larl %2,%0 ; setz %1"=0A              =
   : "=3Dr" (a), "=3Dqm" (valid) : "rm" (sel));=0A-            BUG_ON(valid=
 && ((a & 0x00f0ff00) !=3D *ar));=0A+            WARN_ON(valid && ((a & =
0x00f0ff00) !=3D *ar));=0A             asm volatile (=0A                 =
"lsll %2,%0 ; setz %1"=0A                 : "=3Dr" (l), "=3Dqm" (valid) : =
"rm" (sel));=0A-            BUG_ON(valid && (l !=3D *limit));=0A+          =
  WARN_ON(valid && (l !=3D *limit));=0A         }=0A #endif=0A     }=0A
--=__Part0E21A40A.0__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--=__Part0E21A40A.0__=--


From xen-devel-bounces@lists.xensource.com Thu Dec 15 10:26:54 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 10: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.xensource.com>)
	id 1Rb8WG-0007ah-C2; Thu, 15 Dec 2011 10:26:32 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Rb8WE-0007aN-VD
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 10:26:31 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1323944733!5629366!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10346 invoked from network); 15 Dec 2011 10:25:34 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-2.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 15 Dec 2011 10:25:34 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 15 Dec 2011 10:25:33 +0000
Message-Id: <4EE9D92A020000780006813A@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 15 Dec 2011 10:25:30 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part0E21A40A.0__="
Subject: [Xen-devel] [PATCH] x86: convert BUG_ON()s to WARN_ON()s in
 read_descriptor()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__Part0E21A40A.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

In the light of AMD erratum #700, and given that these checks happen
for debugging purposes only and also only in debug builds of the
hypervisor, make the failures non-fatal.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -1544,11 +1544,11 @@ static int read_descriptor(unsigned int=20
             asm volatile (
                 "larl %2,%0 ; setz %1"
                 : "=3Dr" (a), "=3Dqm" (valid) : "rm" (sel));
-            BUG_ON(valid && ((a & 0x00f0ff00) !=3D *ar));
+            WARN_ON(valid && ((a & 0x00f0ff00) !=3D *ar));
             asm volatile (
                 "lsll %2,%0 ; setz %1"
                 : "=3Dr" (l), "=3Dqm" (valid) : "rm" (sel));
-            BUG_ON(valid && (l !=3D *limit));
+            WARN_ON(valid && (l !=3D *limit));
         }
 #endif
     }




--=__Part0E21A40A.0__=
Content-Type: text/plain; name="amd-erratum-700.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="amd-erratum-700.patch"

x86: convert BUG_ON()s to WARN_ON()s in read_descriptor()=0A=0AIn the =
light of AMD erratum #700, and given that these checks happen=0Afor =
debugging purposes only and also only in debug builds of the=0Ahypervisor, =
make the failures non-fatal.=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@@ =
-1544,11 +1544,11 @@ static int read_descriptor(unsigned int =0A           =
  asm volatile (=0A                 "larl %2,%0 ; setz %1"=0A              =
   : "=3Dr" (a), "=3Dqm" (valid) : "rm" (sel));=0A-            BUG_ON(valid=
 && ((a & 0x00f0ff00) !=3D *ar));=0A+            WARN_ON(valid && ((a & =
0x00f0ff00) !=3D *ar));=0A             asm volatile (=0A                 =
"lsll %2,%0 ; setz %1"=0A                 : "=3Dr" (l), "=3Dqm" (valid) : =
"rm" (sel));=0A-            BUG_ON(valid && (l !=3D *limit));=0A+          =
  WARN_ON(valid && (l !=3D *limit));=0A         }=0A #endif=0A     }=0A
--=__Part0E21A40A.0__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--=__Part0E21A40A.0__=--


From xen-devel-bounces@lists.xensource.com Thu Dec 15 10:35:28 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 10:35:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rb8eb-00085c-CZ; Thu, 15 Dec 2011 10:35:09 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <pbonzini@redhat.com>) id 1Rb8ea-00085X-0L
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 10:35:08 +0000
X-Env-Sender: pbonzini@redhat.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1323945201!57405935!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDYzNzk=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10457 invoked from network); 15 Dec 2011 10:33:21 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-2.tower-27.messagelabs.com with SMTP;
	15 Dec 2011 10:33:21 -0000
Received: from int-mx01.intmail.prod.int.phx2.redhat.com
	(int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id pBFAY9MN008802
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 15 Dec 2011 05:34:10 -0500
Received: from yakj.usersys.redhat.com (ovpn-112-19.ams2.redhat.com
	[10.36.112.19])
	by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP
	id pBFAY8rW006749; Thu, 15 Dec 2011 05:34:08 -0500
Message-ID: <4EE9CD1F.1020406@redhat.com>
Date: Thu, 15 Dec 2011 11:34:07 +0100
From: Paolo Bonzini <pbonzini@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:7.0.1) Gecko/20110930 Thunderbird/7.0.1
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <4EE9C01902000078000680CD@nat28.tlf.novell.com>
	<jcccjv$5jf$1@dough.gmane.org>
	<4EE9D6E40200007800068120@nat28.tlf.novell.com>
In-Reply-To: <4EE9D6E40200007800068120@nat28.tlf.novell.com>
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.11
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] fsincos emulation on AMD CPUs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 12/15/2011 11:15 AM, Jan Beulich wrote:
>> >  If you really cared, perhaps fsincos can be replaced by this sequence in
>> >  the emulator:
>> >
>> >                        ; x
>> >        fld   %st       ; x x
>> >        fsin            ; x sin(x)
>> >        fxch  %st(1)    ; sin(x) x
>> >        fcos            ; sin(x) cos(x)
> I had thought of this at first too, but this is problematic in terms of
> exception handling: fpu_handle_exception() expects to see an
> exception only on the very first instruction (as it's assumed to be
> the only one), and aborts the rest of the sequence if the exception
> doesn't happen on the last instruction.

Can it just be (%0 is fic.insn_bytes):

             movb $4f-1f,%0  ; do nothing on exception here
1:          fld  %st        ; x x
             movb $3f-1f,%0  ; pop on exception here
1:          fsin            ; x sin(x)
             fxch %st(1)     ; sin(x) x
             movb $2f-1f,%0  ; xch+pop on exception here
1:          fcos            ; sin(x) cos(x)
             jmp  2f
4:          fxch %st(1)     ; x sin(x)
3:          fstp %st        ; x
2:

Paolo

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 10:35:28 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 10:35:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rb8eb-00085c-CZ; Thu, 15 Dec 2011 10:35:09 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <pbonzini@redhat.com>) id 1Rb8ea-00085X-0L
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 10:35:08 +0000
X-Env-Sender: pbonzini@redhat.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1323945201!57405935!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDYzNzk=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10457 invoked from network); 15 Dec 2011 10:33:21 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-2.tower-27.messagelabs.com with SMTP;
	15 Dec 2011 10:33:21 -0000
Received: from int-mx01.intmail.prod.int.phx2.redhat.com
	(int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id pBFAY9MN008802
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 15 Dec 2011 05:34:10 -0500
Received: from yakj.usersys.redhat.com (ovpn-112-19.ams2.redhat.com
	[10.36.112.19])
	by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP
	id pBFAY8rW006749; Thu, 15 Dec 2011 05:34:08 -0500
Message-ID: <4EE9CD1F.1020406@redhat.com>
Date: Thu, 15 Dec 2011 11:34:07 +0100
From: Paolo Bonzini <pbonzini@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:7.0.1) Gecko/20110930 Thunderbird/7.0.1
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <4EE9C01902000078000680CD@nat28.tlf.novell.com>
	<jcccjv$5jf$1@dough.gmane.org>
	<4EE9D6E40200007800068120@nat28.tlf.novell.com>
In-Reply-To: <4EE9D6E40200007800068120@nat28.tlf.novell.com>
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.11
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] fsincos emulation on AMD CPUs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 12/15/2011 11:15 AM, Jan Beulich wrote:
>> >  If you really cared, perhaps fsincos can be replaced by this sequence in
>> >  the emulator:
>> >
>> >                        ; x
>> >        fld   %st       ; x x
>> >        fsin            ; x sin(x)
>> >        fxch  %st(1)    ; sin(x) x
>> >        fcos            ; sin(x) cos(x)
> I had thought of this at first too, but this is problematic in terms of
> exception handling: fpu_handle_exception() expects to see an
> exception only on the very first instruction (as it's assumed to be
> the only one), and aborts the rest of the sequence if the exception
> doesn't happen on the last instruction.

Can it just be (%0 is fic.insn_bytes):

             movb $4f-1f,%0  ; do nothing on exception here
1:          fld  %st        ; x x
             movb $3f-1f,%0  ; pop on exception here
1:          fsin            ; x sin(x)
             fxch %st(1)     ; sin(x) x
             movb $2f-1f,%0  ; xch+pop on exception here
1:          fcos            ; sin(x) cos(x)
             jmp  2f
4:          fxch %st(1)     ; x sin(x)
3:          fstp %st        ; x
2:

Paolo

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 10:36:33 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 10: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.xensource.com>)
	id 1Rb8fb-00088W-Rn; Thu, 15 Dec 2011 10:36:11 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1Rb8fa-000888-QC
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 10:36:11 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-8.tower-216.messagelabs.com!1323945313!7575262!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5718 invoked from network); 15 Dec 2011 10:35:13 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-8.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 15 Dec 2011 10:35:13 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1Rb8eb-00018L-AG; Thu, 15 Dec 2011 10:35:09 +0000
Date: Thu, 15 Dec 2011 10:35:08 +0000
From: Tim Deegan <tim@xen.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20111215103508.GA4274@ocelot.phlegethon.org>
References: <3ab01c6cd13fcaaa0d25.1322744193@elijah>
	<4EE9CD3602000078000680F3@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4EE9CD3602000078000680F3@nat28.tlf.novell.com>
User-Agent: Mutt/1.4.2.1i
Cc: george.dunlap@eu.citrix.com, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] Backport fixes to PoD codepaths related to
	1GiB pages
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 09:34 +0000 on 15 Dec (1323941670), Jan Beulich wrote:
> Should this get applied?

Yes.  I thought it already had my Ack, but if not: Ack.

Tim

> >>> On 01.12.11 at 13:56, George Dunlap <george.dunlap@eu.citrix.com> wrote:
> > Backport of xen-unstable.hg c/s 24189:7da681c490e0 to xen-4.1-testing
> > 
> > The codepaths in p2m_gfn_to_mfn() and p2m_gfn_to_mfn_current() should
> > call p2m_pod_check_and_popualte(), as the 2MiB and 4k codepaths do.
> > This properly grabs the p2m lock.
> > 
> > Also, p2m_pod_demand_populate() shouldn't call p2m_unlock(), as it
> > didn't grab the lock in the first place.
> > 
> > Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
> > Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
> > 
> > diff -r c613d436ca09 -r 3ab01c6cd13f xen/arch/x86/mm/p2m.c
> > --- a/xen/arch/x86/mm/p2m.c	Tue Nov 22 19:03:04 2011 +0000
> > +++ b/xen/arch/x86/mm/p2m.c	Thu Dec 01 12:56:18 2011 +0000
> > @@ -1244,7 +1244,6 @@ p2m_pod_demand_populate(struct p2m_domai
> >          set_p2m_entry(p2m, gfn_aligned, _mfn(POPULATE_ON_DEMAND_MFN), 9,
> >                        p2m_populate_on_demand, p2m->default_access);
> >          audit_p2m(p2m, 1);
> > -        p2m_unlock(p2m);
> >          return 0;
> >      }
> >  
> > @@ -1602,7 +1601,8 @@ pod_retry_l3:
> >              {
> >                  if ( q != p2m_query )
> >                  {
> > -                    if ( !p2m_pod_demand_populate(p2m, gfn, 18, q) )
> > +                    if ( !p2m_pod_check_and_populate(p2m, gfn,
> > +                              (l1_pgentry_t *) &l3e, 18, q) )
> >                          goto pod_retry_l3;
> >                  }
> >                  else
> > @@ -1733,7 +1733,8 @@ static mfn_t p2m_gfn_to_mfn_current(stru
> >                  /* The read has succeeded, so we know that mapping exists 
> > */
> >                  if ( q != p2m_query )
> >                  {
> > -                    if ( !p2m_pod_demand_populate(p2m, gfn, 18, q) )
> > +                    if ( !p2m_pod_check_and_populate(p2m, gfn,
> > +                              (l1_pgentry_t *) &l3e, 18, q) )
> >                          goto pod_retry_l3;
> >                      p2mt = p2m_invalid;
> >                      printk("%s: Allocate 1GB failed!\n", __func__);
> > 
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xensource.com 
> > http://lists.xensource.com/xen-devel 
> 
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 10:36:33 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 10: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.xensource.com>)
	id 1Rb8fb-00088W-Rn; Thu, 15 Dec 2011 10:36:11 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1Rb8fa-000888-QC
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 10:36:11 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-8.tower-216.messagelabs.com!1323945313!7575262!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5718 invoked from network); 15 Dec 2011 10:35:13 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-8.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 15 Dec 2011 10:35:13 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1Rb8eb-00018L-AG; Thu, 15 Dec 2011 10:35:09 +0000
Date: Thu, 15 Dec 2011 10:35:08 +0000
From: Tim Deegan <tim@xen.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20111215103508.GA4274@ocelot.phlegethon.org>
References: <3ab01c6cd13fcaaa0d25.1322744193@elijah>
	<4EE9CD3602000078000680F3@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4EE9CD3602000078000680F3@nat28.tlf.novell.com>
User-Agent: Mutt/1.4.2.1i
Cc: george.dunlap@eu.citrix.com, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] Backport fixes to PoD codepaths related to
	1GiB pages
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 09:34 +0000 on 15 Dec (1323941670), Jan Beulich wrote:
> Should this get applied?

Yes.  I thought it already had my Ack, but if not: Ack.

Tim

> >>> On 01.12.11 at 13:56, George Dunlap <george.dunlap@eu.citrix.com> wrote:
> > Backport of xen-unstable.hg c/s 24189:7da681c490e0 to xen-4.1-testing
> > 
> > The codepaths in p2m_gfn_to_mfn() and p2m_gfn_to_mfn_current() should
> > call p2m_pod_check_and_popualte(), as the 2MiB and 4k codepaths do.
> > This properly grabs the p2m lock.
> > 
> > Also, p2m_pod_demand_populate() shouldn't call p2m_unlock(), as it
> > didn't grab the lock in the first place.
> > 
> > Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
> > Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
> > 
> > diff -r c613d436ca09 -r 3ab01c6cd13f xen/arch/x86/mm/p2m.c
> > --- a/xen/arch/x86/mm/p2m.c	Tue Nov 22 19:03:04 2011 +0000
> > +++ b/xen/arch/x86/mm/p2m.c	Thu Dec 01 12:56:18 2011 +0000
> > @@ -1244,7 +1244,6 @@ p2m_pod_demand_populate(struct p2m_domai
> >          set_p2m_entry(p2m, gfn_aligned, _mfn(POPULATE_ON_DEMAND_MFN), 9,
> >                        p2m_populate_on_demand, p2m->default_access);
> >          audit_p2m(p2m, 1);
> > -        p2m_unlock(p2m);
> >          return 0;
> >      }
> >  
> > @@ -1602,7 +1601,8 @@ pod_retry_l3:
> >              {
> >                  if ( q != p2m_query )
> >                  {
> > -                    if ( !p2m_pod_demand_populate(p2m, gfn, 18, q) )
> > +                    if ( !p2m_pod_check_and_populate(p2m, gfn,
> > +                              (l1_pgentry_t *) &l3e, 18, q) )
> >                          goto pod_retry_l3;
> >                  }
> >                  else
> > @@ -1733,7 +1733,8 @@ static mfn_t p2m_gfn_to_mfn_current(stru
> >                  /* The read has succeeded, so we know that mapping exists 
> > */
> >                  if ( q != p2m_query )
> >                  {
> > -                    if ( !p2m_pod_demand_populate(p2m, gfn, 18, q) )
> > +                    if ( !p2m_pod_check_and_populate(p2m, gfn,
> > +                              (l1_pgentry_t *) &l3e, 18, q) )
> >                          goto pod_retry_l3;
> >                      p2mt = p2m_invalid;
> >                      printk("%s: Allocate 1GB failed!\n", __func__);
> > 
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xensource.com 
> > http://lists.xensource.com/xen-devel 
> 
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 10:42:35 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 10:42:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rb8lT-0008Pd-Vl; Thu, 15 Dec 2011 10:42:15 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <bastian@waldi.eu.org>) id 1Rb8lS-0008PW-Io
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 10:42:14 +0000
X-Env-Sender: bastian@waldi.eu.org
X-Msg-Ref: server-2.tower-27.messagelabs.com!1323945632!57407695!1
X-Originating-IP: [82.139.201.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=UPPERCASE_25_50
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20952 invoked from network); 15 Dec 2011 10:40:33 -0000
Received: from wavehammer.waldi.eu.org (HELO wavehammer.waldi.eu.org)
	(82.139.201.20)
	by server-2.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 15 Dec 2011 10:40:33 -0000
Received: by wavehammer.waldi.eu.org (Postfix, from userid 1000)
	id E70525415D; Thu, 15 Dec 2011 11:41:19 +0100 (CET)
Date: Thu, 15 Dec 2011 11:41:19 +0100
From: Bastian Blank <bastian@waldi.eu.org>
To: xen-devel@lists.xensource.com
Message-ID: <20111215104119.GC18042@wavehammer.waldi.eu.org>
Mail-Followup-To: Bastian Blank <bastian@waldi.eu.org>,
	xen-devel@lists.xensource.com
MIME-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.5.20 (2009-06-14)
Subject: [Xen-devel] [PATCH 1/2] xenstored: Use xenbus_backend device on
	Linux
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

xenstored: Use xenbus_backend device on Linux

This patch is done on top of 4.1 for now. The kernel part is already
merged.

diff -r 1c89f7d29fbb tools/include/xen-sys/Linux/xenbus_dev.h
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/tools/include/xen-sys/Linux/xenbus_dev.h	Sat Dec 10 19:38:54 2011 +0100
@@ -0,0 +1,41 @@
+/******************************************************************************
+ * evtchn.h
+ *
+ * Interface to /dev/xen/xenbus_backend.
+ *
+ * Copyright (c) 2011 Bastian Blank <waldi@debian.org>
+ *
+ * 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 __LINUX_XEN_XENBUS_DEV_H__
+#define __LINUX_XEN_XENBUS_DEV_H__
+
+#include <linux/ioctl.h>
+
+#define IOCTL_XENBUS_BACKEND_EVTCHN			\
+	_IOC(_IOC_NONE, 'B', 0, 0)
+
+#endif /* __LINUX_XEN_XENBUS_DEV_H__ */
diff -r 1c89f7d29fbb tools/xenstore/xenstored_linux.c
--- a/tools/xenstore/xenstored_linux.c	Thu Dec 08 16:50:28 2011 +0000
+++ b/tools/xenstore/xenstored_linux.c	Sat Dec 10 19:38:54 2011 +0100
@@ -11,17 +11,22 @@
  * License.
  */
 
+#include <errno.h>
 #include <fcntl.h>
 #include <unistd.h>
 #include <stdlib.h>
+#include <sys/ioctl.h>
 #include <sys/mman.h>
 
+#include <xen/sys/xenbus_dev.h>
+
 #include "xenstored_core.h"
 
+#define XENSTORED_DEV "/dev/xen/xenbus_backend"
 #define XENSTORED_PROC_KVA  "/proc/xen/xsd_kva"
 #define XENSTORED_PROC_PORT "/proc/xen/xsd_port"
 
-evtchn_port_t xenbus_evtchn(void)
+static evtchn_port_t xenbus_proc_evtchn(void)
 {
 	int fd;
 	int rc;
@@ -48,12 +53,35 @@
 	return port;
 }
 
+evtchn_port_t xenbus_evtchn(void)
+{
+	int fd;
+	long ret;
+
+	fd = open(XENSTORED_DEV, O_RDONLY);
+	if (fd == -1)
+	{
+		if (errno == ENOENT)
+			return xenbus_proc_evtchn();
+		return -1;
+	}
+
+	ret = ioctl(fd, IOCTL_XENBUS_BACKEND_EVTCHN);
+	if (ret == -1)
+		return -1;
+
+	close(fd); 
+	return ret;
+}
+
 void *xenbus_map(void)
 {
 	int fd;
 	void *addr;
 
-	fd = open(XENSTORED_PROC_KVA, O_RDWR);
+	fd = open(XENSTORED_DEV, O_RDWR);
+	if (fd == -1 && errno == ENOENT)
+		fd = open(XENSTORED_PROC_KVA, O_RDWR);
 	if (fd == -1)
 		return NULL;
 
-- 
Killing is wrong.
		-- Losira, "That Which Survives", stardate unknown

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 10:42:35 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 10:42:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rb8lT-0008Pd-Vl; Thu, 15 Dec 2011 10:42:15 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <bastian@waldi.eu.org>) id 1Rb8lS-0008PW-Io
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 10:42:14 +0000
X-Env-Sender: bastian@waldi.eu.org
X-Msg-Ref: server-2.tower-27.messagelabs.com!1323945632!57407695!1
X-Originating-IP: [82.139.201.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=UPPERCASE_25_50
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20952 invoked from network); 15 Dec 2011 10:40:33 -0000
Received: from wavehammer.waldi.eu.org (HELO wavehammer.waldi.eu.org)
	(82.139.201.20)
	by server-2.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 15 Dec 2011 10:40:33 -0000
Received: by wavehammer.waldi.eu.org (Postfix, from userid 1000)
	id E70525415D; Thu, 15 Dec 2011 11:41:19 +0100 (CET)
Date: Thu, 15 Dec 2011 11:41:19 +0100
From: Bastian Blank <bastian@waldi.eu.org>
To: xen-devel@lists.xensource.com
Message-ID: <20111215104119.GC18042@wavehammer.waldi.eu.org>
Mail-Followup-To: Bastian Blank <bastian@waldi.eu.org>,
	xen-devel@lists.xensource.com
MIME-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.5.20 (2009-06-14)
Subject: [Xen-devel] [PATCH 1/2] xenstored: Use xenbus_backend device on
	Linux
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

xenstored: Use xenbus_backend device on Linux

This patch is done on top of 4.1 for now. The kernel part is already
merged.

diff -r 1c89f7d29fbb tools/include/xen-sys/Linux/xenbus_dev.h
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/tools/include/xen-sys/Linux/xenbus_dev.h	Sat Dec 10 19:38:54 2011 +0100
@@ -0,0 +1,41 @@
+/******************************************************************************
+ * evtchn.h
+ *
+ * Interface to /dev/xen/xenbus_backend.
+ *
+ * Copyright (c) 2011 Bastian Blank <waldi@debian.org>
+ *
+ * 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 __LINUX_XEN_XENBUS_DEV_H__
+#define __LINUX_XEN_XENBUS_DEV_H__
+
+#include <linux/ioctl.h>
+
+#define IOCTL_XENBUS_BACKEND_EVTCHN			\
+	_IOC(_IOC_NONE, 'B', 0, 0)
+
+#endif /* __LINUX_XEN_XENBUS_DEV_H__ */
diff -r 1c89f7d29fbb tools/xenstore/xenstored_linux.c
--- a/tools/xenstore/xenstored_linux.c	Thu Dec 08 16:50:28 2011 +0000
+++ b/tools/xenstore/xenstored_linux.c	Sat Dec 10 19:38:54 2011 +0100
@@ -11,17 +11,22 @@
  * License.
  */
 
+#include <errno.h>
 #include <fcntl.h>
 #include <unistd.h>
 #include <stdlib.h>
+#include <sys/ioctl.h>
 #include <sys/mman.h>
 
+#include <xen/sys/xenbus_dev.h>
+
 #include "xenstored_core.h"
 
+#define XENSTORED_DEV "/dev/xen/xenbus_backend"
 #define XENSTORED_PROC_KVA  "/proc/xen/xsd_kva"
 #define XENSTORED_PROC_PORT "/proc/xen/xsd_port"
 
-evtchn_port_t xenbus_evtchn(void)
+static evtchn_port_t xenbus_proc_evtchn(void)
 {
 	int fd;
 	int rc;
@@ -48,12 +53,35 @@
 	return port;
 }
 
+evtchn_port_t xenbus_evtchn(void)
+{
+	int fd;
+	long ret;
+
+	fd = open(XENSTORED_DEV, O_RDONLY);
+	if (fd == -1)
+	{
+		if (errno == ENOENT)
+			return xenbus_proc_evtchn();
+		return -1;
+	}
+
+	ret = ioctl(fd, IOCTL_XENBUS_BACKEND_EVTCHN);
+	if (ret == -1)
+		return -1;
+
+	close(fd); 
+	return ret;
+}
+
 void *xenbus_map(void)
 {
 	int fd;
 	void *addr;
 
-	fd = open(XENSTORED_PROC_KVA, O_RDWR);
+	fd = open(XENSTORED_DEV, O_RDWR);
+	if (fd == -1 && errno == ENOENT)
+		fd = open(XENSTORED_PROC_KVA, O_RDWR);
 	if (fd == -1)
 		return NULL;
 
-- 
Killing is wrong.
		-- Losira, "That Which Survives", stardate unknown

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 10:43:12 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 10:43:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rb8m9-0008Sl-K6; Thu, 15 Dec 2011 10:42:57 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <bastian@waldi.eu.org>) id 1Rb8m8-0008SK-8i
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 10:42:56 +0000
X-Env-Sender: bastian@waldi.eu.org
X-Msg-Ref: server-5.tower-216.messagelabs.com!1323945718!7570785!1
X-Originating-IP: [82.139.201.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18486 invoked from network); 15 Dec 2011 10:41:59 -0000
Received: from wavehammer.waldi.eu.org (HELO wavehammer.waldi.eu.org)
	(82.139.201.20)
	by server-5.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 15 Dec 2011 10:41:59 -0000
Received: by wavehammer.waldi.eu.org (Postfix, from userid 1000)
	id 7EA645415D; Thu, 15 Dec 2011 11:41:58 +0100 (CET)
Date: Thu, 15 Dec 2011 11:41:58 +0100
From: Bastian Blank <bastian@waldi.eu.org>
To: xen-devel@lists.xensource.com
Message-ID: <20111215104158.GD18042@wavehammer.waldi.eu.org>
Mail-Followup-To: Bastian Blank <bastian@waldi.eu.org>,
	xen-devel@lists.xensource.com
MIME-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.5.20 (2009-06-14)
Subject: [Xen-devel] [PATCH 2/2] libxc: Use privcmd device on Linux
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

libxc: Use privcmd device on Linux

diff -r fd8e02fbcbfa -r ecf68e8d92f7 tools/libxc/xc_linux_osdep.c
--- a/tools/libxc/xc_linux_osdep.c	Sat Dec 10 16:40:31 2011 +0100
+++ b/tools/libxc/xc_linux_osdep.c	Sat Dec 10 16:40:51 2011 +0100
@@ -45,7 +45,11 @@
 static xc_osdep_handle linux_privcmd_open(xc_interface *xch)
 {
     int flags, saved_errno;
-    int fd = open("/proc/xen/privcmd", O_RDWR);
+    int fd;
+
+    fd = open("/dev/xen/privcmd", O_RDWR);
+    if ( fd == -1 && errno == ENOENT )
+        fd = open("/proc/xen/privcmd", O_RDWR);
 
     if ( fd == -1 )
     {
-- 
Murder is contrary to the laws of man and God.
		-- M-5 Computer, "The Ultimate Computer", stardate 4731.3

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 10:43:12 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 10:43:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rb8m9-0008Sl-K6; Thu, 15 Dec 2011 10:42:57 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <bastian@waldi.eu.org>) id 1Rb8m8-0008SK-8i
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 10:42:56 +0000
X-Env-Sender: bastian@waldi.eu.org
X-Msg-Ref: server-5.tower-216.messagelabs.com!1323945718!7570785!1
X-Originating-IP: [82.139.201.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18486 invoked from network); 15 Dec 2011 10:41:59 -0000
Received: from wavehammer.waldi.eu.org (HELO wavehammer.waldi.eu.org)
	(82.139.201.20)
	by server-5.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 15 Dec 2011 10:41:59 -0000
Received: by wavehammer.waldi.eu.org (Postfix, from userid 1000)
	id 7EA645415D; Thu, 15 Dec 2011 11:41:58 +0100 (CET)
Date: Thu, 15 Dec 2011 11:41:58 +0100
From: Bastian Blank <bastian@waldi.eu.org>
To: xen-devel@lists.xensource.com
Message-ID: <20111215104158.GD18042@wavehammer.waldi.eu.org>
Mail-Followup-To: Bastian Blank <bastian@waldi.eu.org>,
	xen-devel@lists.xensource.com
MIME-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.5.20 (2009-06-14)
Subject: [Xen-devel] [PATCH 2/2] libxc: Use privcmd device on Linux
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

libxc: Use privcmd device on Linux

diff -r fd8e02fbcbfa -r ecf68e8d92f7 tools/libxc/xc_linux_osdep.c
--- a/tools/libxc/xc_linux_osdep.c	Sat Dec 10 16:40:31 2011 +0100
+++ b/tools/libxc/xc_linux_osdep.c	Sat Dec 10 16:40:51 2011 +0100
@@ -45,7 +45,11 @@
 static xc_osdep_handle linux_privcmd_open(xc_interface *xch)
 {
     int flags, saved_errno;
-    int fd = open("/proc/xen/privcmd", O_RDWR);
+    int fd;
+
+    fd = open("/dev/xen/privcmd", O_RDWR);
+    if ( fd == -1 && errno == ENOENT )
+        fd = open("/proc/xen/privcmd", O_RDWR);
 
     if ( fd == -1 )
     {
-- 
Murder is contrary to the laws of man and God.
		-- M-5 Computer, "The Ultimate Computer", stardate 4731.3

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 11:12:36 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 11:12:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rb9EN-0000ew-6c; Thu, 15 Dec 2011 11:12:07 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Rb9EL-0000eo-VM
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 11:12:06 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1323947431!50728377!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjI2MA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32595 invoked from network); 15 Dec 2011 11:10:31 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 11:10:31 -0000
X-IronPort-AV: E=Sophos;i="4.71,356,1320624000"; 
   d="scan'208";a="9485958"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Dec 2011 11:11:11 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 15 Dec 2011 11:11:11 +0000
Date: Thu, 15 Dec 2011 11:13:31 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1323941055.20077.443.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1112151108230.3517@kaball-desktop>
References: <alpine.DEB.2.00.1111221551510.31179@kaball-desktop>
	<1322056320-5826-5-git-send-email-stefano.stabellini@eu.citrix.com>
	<20198.15417.932169.223332@mariner.uk.xensource.com>
	<1323712001.20077.234.camel@zakaz.uk.xensource.com> 
	<alpine.DEB.2.00.1112121924520.3517@kaball-desktop>
	<20199.24118.465585.933183@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1112131720250.3517@kaball-desktop>
	<20199.37117.779165.894809@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1112131817300.3517@kaball-desktop>
	<1323855739.20077.365.camel@zakaz.uk.xensource.com>
	<20200.36536.187256.61611@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1112141641280.3517@kaball-desktop>
	<1323941055.20077.443.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "Keir \(Xen.org\)" <keir@xen.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v9 5/6] Clone and build Seabios by default
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 15 Dec 2011, Ian Campbell wrote:
> > Considering that Qemu releases are not in sync with our releases, I
> > think that we should point xen-unstable to one of our own Qemu trees
> > rather than just a mirror of the Qemu stable branch on xenbits.
> > Otherwise we risk loosing important features, for example if there are
> > not going to be any new Qemu releases before Xen 4.2 is out, we are
> > going to miss pci passthrough and save/restore, while if we had our own
> > branch we would have them.
> > Of course it is still very important to keep Qemu stable branches stable
> > and functional, so that if distros decide to package a single upstream
> > Qemu, it still going to work fine, even though it is going to have fewer
> > features.
> 
> Agreed, all these trees are very important and therefore we must test
> all of them, although perhaps not in the same way as we currently test
> things.
> 
> How about this:
> 
> We host a qemu tree including a staging branch and associated push gate.
> This tree tracks the current qemu stable branch and contains backports
> of patches which have been applied to the current qemu development
> branch (using a policy similar to the Linux stable series policy, in
> order to prevent accidental forking). We point xen-devel at this and it
> is used by the regular testing machinery and forms part of the Xen
> releases.

I am OK with this, if everything goes well we shouldn't need anything
else. It might happen that because of time constraints we have to apply
patches to this tree before they are applied upstream, but it should
only be the exception, not the rule.


> Then as a separate independent test we periodically (e.g. weekly or
> twice-weekly) test the upstream qemu development branch against some
> baseline version of Xen (e.g. the most recent pass of either unstable or
> current stable branch). This test doesn't gate anything but is just to
> keep tabs on the development branch and spot regressions earlier etc.

twice-weekly would be good


> Lastly we also test any releases (rc and final, perhaps beta) on both
> the qemu stable and development branches against current latest unstable
> and stable Xen branches. Again this doesn't gate anything but just keeps
> tabs on things.
> 
> BTW I think periodic test + rc&releases is how we should handle Linux
> upstream too and indeed any other external dependency which runs on a
> disconnected schedule.

indeed

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 11:12:36 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 11:12:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rb9EN-0000ew-6c; Thu, 15 Dec 2011 11:12:07 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Rb9EL-0000eo-VM
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 11:12:06 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1323947431!50728377!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjI2MA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32595 invoked from network); 15 Dec 2011 11:10:31 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 11:10:31 -0000
X-IronPort-AV: E=Sophos;i="4.71,356,1320624000"; 
   d="scan'208";a="9485958"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Dec 2011 11:11:11 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 15 Dec 2011 11:11:11 +0000
Date: Thu, 15 Dec 2011 11:13:31 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1323941055.20077.443.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1112151108230.3517@kaball-desktop>
References: <alpine.DEB.2.00.1111221551510.31179@kaball-desktop>
	<1322056320-5826-5-git-send-email-stefano.stabellini@eu.citrix.com>
	<20198.15417.932169.223332@mariner.uk.xensource.com>
	<1323712001.20077.234.camel@zakaz.uk.xensource.com> 
	<alpine.DEB.2.00.1112121924520.3517@kaball-desktop>
	<20199.24118.465585.933183@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1112131720250.3517@kaball-desktop>
	<20199.37117.779165.894809@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1112131817300.3517@kaball-desktop>
	<1323855739.20077.365.camel@zakaz.uk.xensource.com>
	<20200.36536.187256.61611@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1112141641280.3517@kaball-desktop>
	<1323941055.20077.443.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "Keir \(Xen.org\)" <keir@xen.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v9 5/6] Clone and build Seabios by default
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 15 Dec 2011, Ian Campbell wrote:
> > Considering that Qemu releases are not in sync with our releases, I
> > think that we should point xen-unstable to one of our own Qemu trees
> > rather than just a mirror of the Qemu stable branch on xenbits.
> > Otherwise we risk loosing important features, for example if there are
> > not going to be any new Qemu releases before Xen 4.2 is out, we are
> > going to miss pci passthrough and save/restore, while if we had our own
> > branch we would have them.
> > Of course it is still very important to keep Qemu stable branches stable
> > and functional, so that if distros decide to package a single upstream
> > Qemu, it still going to work fine, even though it is going to have fewer
> > features.
> 
> Agreed, all these trees are very important and therefore we must test
> all of them, although perhaps not in the same way as we currently test
> things.
> 
> How about this:
> 
> We host a qemu tree including a staging branch and associated push gate.
> This tree tracks the current qemu stable branch and contains backports
> of patches which have been applied to the current qemu development
> branch (using a policy similar to the Linux stable series policy, in
> order to prevent accidental forking). We point xen-devel at this and it
> is used by the regular testing machinery and forms part of the Xen
> releases.

I am OK with this, if everything goes well we shouldn't need anything
else. It might happen that because of time constraints we have to apply
patches to this tree before they are applied upstream, but it should
only be the exception, not the rule.


> Then as a separate independent test we periodically (e.g. weekly or
> twice-weekly) test the upstream qemu development branch against some
> baseline version of Xen (e.g. the most recent pass of either unstable or
> current stable branch). This test doesn't gate anything but is just to
> keep tabs on the development branch and spot regressions earlier etc.

twice-weekly would be good


> Lastly we also test any releases (rc and final, perhaps beta) on both
> the qemu stable and development branches against current latest unstable
> and stable Xen branches. Again this doesn't gate anything but just keeps
> tabs on things.
> 
> BTW I think periodic test + rc&releases is how we should handle Linux
> upstream too and indeed any other external dependency which runs on a
> disconnected schedule.

indeed

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 11:16:57 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 11:16:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rb9Ij-0000mW-Tp; Thu, 15 Dec 2011 11:16:37 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Rb9Ii-0000m6-7Z
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 11:16:36 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1323947738!7959622!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17435 invoked from network); 15 Dec 2011 11:15:39 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-11.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 15 Dec 2011 11:15:39 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 15 Dec 2011 11:15:38 +0000
Message-Id: <4EE9E4E80200007800068173@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 15 Dec 2011 11:15:36 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Paolo Bonzini" <pbonzini@redhat.com>,"Keir Fraser" <keir@xen.org>
References: <4EE9C01902000078000680CD@nat28.tlf.novell.com>
	<jcccjv$5jf$1@dough.gmane.org>
	<4EE9D6E40200007800068120@nat28.tlf.novell.com>
	<4EE9CD1F.1020406@redhat.com>
In-Reply-To: <4EE9CD1F.1020406@redhat.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] fsincos emulation on AMD CPUs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 15.12.11 at 11:34, Paolo Bonzini <pbonzini@redhat.com> wrote:
> On 12/15/2011 11:15 AM, Jan Beulich wrote:
>>> >  If you really cared, perhaps fsincos can be replaced by this sequence in
>>> >  the emulator:
>>> >
>>> >                        ; x
>>> >        fld   %st       ; x x
>>> >        fsin            ; x sin(x)
>>> >        fxch  %st(1)    ; sin(x) x
>>> >        fcos            ; sin(x) cos(x)
>> I had thought of this at first too, but this is problematic in terms of
>> exception handling: fpu_handle_exception() expects to see an
>> exception only on the very first instruction (as it's assumed to be
>> the only one), and aborts the rest of the sequence if the exception
>> doesn't happen on the last instruction.
> 
> Can it just be (%0 is fic.insn_bytes):
> 
>              movb $4f-1f,%0  ; do nothing on exception here
> 1:          fld  %st        ; x x
>              movb $3f-1f,%0  ; pop on exception here
> 1:          fsin            ; x sin(x)
>              fxch %st(1)     ; sin(x) x
>              movb $2f-1f,%0  ; xch+pop on exception here
> 1:          fcos            ; sin(x) cos(x)
>              jmp  2f
> 4:          fxch %st(1)     ; x sin(x)
> 3:          fstp %st        ; x
> 2:

Ugly, but possible (with some further corrections). I'd still prefer to
just suppress the emulation:

--- atools/tests/x86_emulator/x86_emulate.c
+++ b/tools/tests/x86_emulator/x86_emulate.c
@@ -9,5 +9,7 @@ typedef bool bool_t;
 
 #define BUG() abort()
 
+#define cpu_has_amd_erratum(nr) 0
+
 #include "x86_emulate/x86_emulate.h"
 #include "x86_emulate/x86_emulate.c"
--- a/xen/arch/x86/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate.c
@@ -10,8 +10,14 @@
  */
 
 #include <asm/x86_emulate.h>
+#include <asm/processor.h> /* current_cpu_info */
+#include <asm/amd.h> /* cpu_has_amd_erratum() */
 
 /* Avoid namespace pollution. */
 #undef cmpxchg
+#undef cpuid
+
+#define cpu_has_amd_erratum(nr) \
+        cpu_has_amd_erratum(&current_cpu_data, AMD_ERRATUM_##nr)
 
 #include "x86_emulate/x86_emulate.c"
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -2761,6 +2761,9 @@ x86_emulate(
     case 0xd9: /* FPU 0xd9 */
         switch ( modrm )
         {
+        case 0xfb: /* fsincos */
+            fail_if(cpu_has_amd_erratum(573));
+            /* fall through */
         case 0xc0 ... 0xc7: /* fld %stN */
         case 0xc8 ... 0xcf: /* fxch %stN */
         case 0xd0: /* fnop */
@@ -2786,7 +2789,6 @@ x86_emulate(
         case 0xf8: /* fprem */
         case 0xf9: /* fyl2xp1 */
         case 0xfa: /* fsqrt */
-        case 0xfb: /* fsincos */
         case 0xfc: /* frndint */
         case 0xfd: /* fscale */
         case 0xfe: /* fsin */
--- a/xen/include/asm-x86/amd.h
+++ b/xen/include/asm-x86/amd.h
@@ -134,6 +134,12 @@
     AMD_OSVW_ERRATUM(3, AMD_MODEL_RANGE(0x10, 0x2, 0x1, 0xff, 0xf),	\
 		        AMD_MODEL_RANGE(0x12, 0x0, 0x0, 0x1, 0x0))
 
+#define AMD_ERRATUM_573							\
+    AMD_LEGACY_ERRATUM(AMD_MODEL_RANGE(0x0f, 0x0, 0x0, 0xff, 0xf),	\
+                       AMD_MODEL_RANGE(0x10, 0x0, 0x0, 0xff, 0xf),	\
+                       AMD_MODEL_RANGE(0x11, 0x0, 0x0, 0xff, 0xf),	\
+                       AMD_MODEL_RANGE(0x12, 0x0, 0x0, 0xff, 0xf))
+
 struct cpuinfo_x86;
 int cpu_has_amd_erratum(const struct cpuinfo_x86 *, int, ...);
 
Keir, what's your opinion here?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 11:16:57 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 11:16:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rb9Ij-0000mW-Tp; Thu, 15 Dec 2011 11:16:37 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Rb9Ii-0000m6-7Z
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 11:16:36 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1323947738!7959622!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17435 invoked from network); 15 Dec 2011 11:15:39 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-11.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 15 Dec 2011 11:15:39 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 15 Dec 2011 11:15:38 +0000
Message-Id: <4EE9E4E80200007800068173@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 15 Dec 2011 11:15:36 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Paolo Bonzini" <pbonzini@redhat.com>,"Keir Fraser" <keir@xen.org>
References: <4EE9C01902000078000680CD@nat28.tlf.novell.com>
	<jcccjv$5jf$1@dough.gmane.org>
	<4EE9D6E40200007800068120@nat28.tlf.novell.com>
	<4EE9CD1F.1020406@redhat.com>
In-Reply-To: <4EE9CD1F.1020406@redhat.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] fsincos emulation on AMD CPUs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 15.12.11 at 11:34, Paolo Bonzini <pbonzini@redhat.com> wrote:
> On 12/15/2011 11:15 AM, Jan Beulich wrote:
>>> >  If you really cared, perhaps fsincos can be replaced by this sequence in
>>> >  the emulator:
>>> >
>>> >                        ; x
>>> >        fld   %st       ; x x
>>> >        fsin            ; x sin(x)
>>> >        fxch  %st(1)    ; sin(x) x
>>> >        fcos            ; sin(x) cos(x)
>> I had thought of this at first too, but this is problematic in terms of
>> exception handling: fpu_handle_exception() expects to see an
>> exception only on the very first instruction (as it's assumed to be
>> the only one), and aborts the rest of the sequence if the exception
>> doesn't happen on the last instruction.
> 
> Can it just be (%0 is fic.insn_bytes):
> 
>              movb $4f-1f,%0  ; do nothing on exception here
> 1:          fld  %st        ; x x
>              movb $3f-1f,%0  ; pop on exception here
> 1:          fsin            ; x sin(x)
>              fxch %st(1)     ; sin(x) x
>              movb $2f-1f,%0  ; xch+pop on exception here
> 1:          fcos            ; sin(x) cos(x)
>              jmp  2f
> 4:          fxch %st(1)     ; x sin(x)
> 3:          fstp %st        ; x
> 2:

Ugly, but possible (with some further corrections). I'd still prefer to
just suppress the emulation:

--- atools/tests/x86_emulator/x86_emulate.c
+++ b/tools/tests/x86_emulator/x86_emulate.c
@@ -9,5 +9,7 @@ typedef bool bool_t;
 
 #define BUG() abort()
 
+#define cpu_has_amd_erratum(nr) 0
+
 #include "x86_emulate/x86_emulate.h"
 #include "x86_emulate/x86_emulate.c"
--- a/xen/arch/x86/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate.c
@@ -10,8 +10,14 @@
  */
 
 #include <asm/x86_emulate.h>
+#include <asm/processor.h> /* current_cpu_info */
+#include <asm/amd.h> /* cpu_has_amd_erratum() */
 
 /* Avoid namespace pollution. */
 #undef cmpxchg
+#undef cpuid
+
+#define cpu_has_amd_erratum(nr) \
+        cpu_has_amd_erratum(&current_cpu_data, AMD_ERRATUM_##nr)
 
 #include "x86_emulate/x86_emulate.c"
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -2761,6 +2761,9 @@ x86_emulate(
     case 0xd9: /* FPU 0xd9 */
         switch ( modrm )
         {
+        case 0xfb: /* fsincos */
+            fail_if(cpu_has_amd_erratum(573));
+            /* fall through */
         case 0xc0 ... 0xc7: /* fld %stN */
         case 0xc8 ... 0xcf: /* fxch %stN */
         case 0xd0: /* fnop */
@@ -2786,7 +2789,6 @@ x86_emulate(
         case 0xf8: /* fprem */
         case 0xf9: /* fyl2xp1 */
         case 0xfa: /* fsqrt */
-        case 0xfb: /* fsincos */
         case 0xfc: /* frndint */
         case 0xfd: /* fscale */
         case 0xfe: /* fsin */
--- a/xen/include/asm-x86/amd.h
+++ b/xen/include/asm-x86/amd.h
@@ -134,6 +134,12 @@
     AMD_OSVW_ERRATUM(3, AMD_MODEL_RANGE(0x10, 0x2, 0x1, 0xff, 0xf),	\
 		        AMD_MODEL_RANGE(0x12, 0x0, 0x0, 0x1, 0x0))
 
+#define AMD_ERRATUM_573							\
+    AMD_LEGACY_ERRATUM(AMD_MODEL_RANGE(0x0f, 0x0, 0x0, 0xff, 0xf),	\
+                       AMD_MODEL_RANGE(0x10, 0x0, 0x0, 0xff, 0xf),	\
+                       AMD_MODEL_RANGE(0x11, 0x0, 0x0, 0xff, 0xf),	\
+                       AMD_MODEL_RANGE(0x12, 0x0, 0x0, 0xff, 0xf))
+
 struct cpuinfo_x86;
 int cpu_has_amd_erratum(const struct cpuinfo_x86 *, int, ...);
 
Keir, what's your opinion here?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 11:17:35 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 11:17:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rb9JK-0000ou-BH; Thu, 15 Dec 2011 11:17:14 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Wang2@amd.com>) id 1Rb9JI-0000od-N6
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 11:17:12 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1323947731!49116515!1
X-Originating-IP: [213.199.154.144]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16561 invoked from network); 15 Dec 2011 11:15:32 -0000
Received: from db3ehsobe006.messaging.microsoft.com (HELO
	DB3EHSOBE006.bigfish.com) (213.199.154.144)
	by server-3.tower-27.messagelabs.com with AES128-SHA encrypted SMTP;
	15 Dec 2011 11:15:32 -0000
Received: from mail16-db3-R.bigfish.com (10.3.81.251) by
	DB3EHSOBE006.bigfish.com (10.3.84.26) with Microsoft SMTP Server id
	14.1.225.23; Thu, 15 Dec 2011 11:16:16 +0000
Received: from mail16-db3 (localhost [127.0.0.1])	by mail16-db3-R.bigfish.com
	(Postfix) with ESMTP id 28148202F9;
	Thu, 15 Dec 2011 11:16:21 +0000 (UTC)
X-SpamScore: -22
X-BigFish: VPS-22(zz15bfK148cM1102K1432N1a09J98dKzz1202hzz8275bhz2dh668h839h)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
Received: from mail16-db3 (localhost.localdomain [127.0.0.1]) by mail16-db3
	(MessageSwitch) id 1323947780848232_29684;
	Thu, 15 Dec 2011 11:16:20 +0000 (UTC)
Received: from DB3EHSMHS004.bigfish.com (unknown [10.3.81.248])	by
	mail16-db3.bigfish.com (Postfix) with ESMTP id C01BE480043;
	Thu, 15 Dec 2011 11:16:20 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	DB3EHSMHS004.bigfish.com (10.3.87.104) with Microsoft SMTP Server id
	14.1.225.23; Thu, 15 Dec 2011 11:16:15 +0000
X-WSS-ID: 0LW8SN0-01-4R1-02
X-M-MSG: 
Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com
	[163.181.249.73])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 264401028057;	Thu, 15 Dec 2011 05:16:11 -0600 (CST)
Received: from sausexhtp01.amd.com (163.181.3.165) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Thu, 15 Dec 2011 05:16:26 -0600
Received: from storexhtp02.amd.com (172.24.4.4) by sausexhtp01.amd.com
	(163.181.3.165) with Microsoft SMTP Server (TLS) id 8.3.213.0;
	Thu, 15 Dec 2011 05:16:11 -0600
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Thu, 15 Dec 2011
	06:16:10 -0500
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id DDE1D49C34C; Thu, 15 Dec 2011
	11:16:09 +0000 (GMT)
Received: from gran.osrc.amd.com (gran.osrc.amd.com [165.204.15.57])	by
	mail.osrc.amd.com (Postfix) with ESMTP id C0E405940FF; Thu, 15 Dec 2011
	12:16:09 +0100 (CET)
From: Wei Wang2 <wei.wang2@amd.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Thu, 15 Dec 2011 12:18:52 +0100
User-Agent: KMail/1.9.6 (enterprise 20070904.708012)
References: <patchbomb.1323876561@gran.amd.com>
	<4EE9D8CE020000780006812F@nat28.tlf.novell.com>
In-Reply-To: <4EE9D8CE020000780006812F@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
Message-ID: <201112151218.53363.wei.wang2@amd.com>
X-OriginatorOrg: amd.com
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, xen-devel@lists.xensource.com,
	keir@xen.org
Subject: Re: [Xen-devel] [PATCH 00 of 16] [RFC] amd iommu: support ATS
	device passthru on IOMMUv2 systems
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thursday 15 December 2011 11:23:58 Jan Beulich wrote:
> >>> On 14.12.11 at 16:29, Wei Wang <wei.wang2@amd.com> wrote:
> >
> > ATS devices with PRI and PASID capabilities can communicate with iommuv2
> > to do 2 level (nested) DMA translation and IO demand paging. To do that,
> > both iommu driver and ats device have to been enabled in guest OS. This
> > patch set
> >
> > adds initial iommu emulation for hvm guests to support ATS device
> > passthru.
>
> I could take care of the first 6 patches in this series, as they're only
> touching AMD IOMMU code and look sensible to me. I'm not sure
> though whether this is a good idea without knowing the disposition
> of the other 10 patches (particularly the relative large 3rd patch
> doesn't seem to make sense without it later getting hooked up).
>
> Please let me know,
> Jan
 
Actually, the amd specific patches implement the most IOMMUv2 support. Thanks 
for looking at this. We had thought about how to integrate IOMMUv2 for ATS 
device passthru. Since guest OS requires iommu to be presented in this case, 
we could go for either PV interface or full emulation.  The iommuv2 driver 
has just been submitted to Linux mailing list, so this might be too early for 
pv iommu drivers... Using mmio handler in xen, we can avoid any guest OS 
changes and can get better performance than using qemu-dm. So this might be 
the only approach we intend to use at the moment.

But yes, eventually, the iommu emulation is driven by hypercalls. It would be 
great that tools maintainers could check this in the meantime. so, Ian, could 
I invite you to take a look at this?

Many thanks,
Wei


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 11:17:35 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 11:17:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rb9JK-0000ou-BH; Thu, 15 Dec 2011 11:17:14 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Wang2@amd.com>) id 1Rb9JI-0000od-N6
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 11:17:12 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1323947731!49116515!1
X-Originating-IP: [213.199.154.144]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16561 invoked from network); 15 Dec 2011 11:15:32 -0000
Received: from db3ehsobe006.messaging.microsoft.com (HELO
	DB3EHSOBE006.bigfish.com) (213.199.154.144)
	by server-3.tower-27.messagelabs.com with AES128-SHA encrypted SMTP;
	15 Dec 2011 11:15:32 -0000
Received: from mail16-db3-R.bigfish.com (10.3.81.251) by
	DB3EHSOBE006.bigfish.com (10.3.84.26) with Microsoft SMTP Server id
	14.1.225.23; Thu, 15 Dec 2011 11:16:16 +0000
Received: from mail16-db3 (localhost [127.0.0.1])	by mail16-db3-R.bigfish.com
	(Postfix) with ESMTP id 28148202F9;
	Thu, 15 Dec 2011 11:16:21 +0000 (UTC)
X-SpamScore: -22
X-BigFish: VPS-22(zz15bfK148cM1102K1432N1a09J98dKzz1202hzz8275bhz2dh668h839h)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
Received: from mail16-db3 (localhost.localdomain [127.0.0.1]) by mail16-db3
	(MessageSwitch) id 1323947780848232_29684;
	Thu, 15 Dec 2011 11:16:20 +0000 (UTC)
Received: from DB3EHSMHS004.bigfish.com (unknown [10.3.81.248])	by
	mail16-db3.bigfish.com (Postfix) with ESMTP id C01BE480043;
	Thu, 15 Dec 2011 11:16:20 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	DB3EHSMHS004.bigfish.com (10.3.87.104) with Microsoft SMTP Server id
	14.1.225.23; Thu, 15 Dec 2011 11:16:15 +0000
X-WSS-ID: 0LW8SN0-01-4R1-02
X-M-MSG: 
Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com
	[163.181.249.73])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 264401028057;	Thu, 15 Dec 2011 05:16:11 -0600 (CST)
Received: from sausexhtp01.amd.com (163.181.3.165) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Thu, 15 Dec 2011 05:16:26 -0600
Received: from storexhtp02.amd.com (172.24.4.4) by sausexhtp01.amd.com
	(163.181.3.165) with Microsoft SMTP Server (TLS) id 8.3.213.0;
	Thu, 15 Dec 2011 05:16:11 -0600
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Thu, 15 Dec 2011
	06:16:10 -0500
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id DDE1D49C34C; Thu, 15 Dec 2011
	11:16:09 +0000 (GMT)
Received: from gran.osrc.amd.com (gran.osrc.amd.com [165.204.15.57])	by
	mail.osrc.amd.com (Postfix) with ESMTP id C0E405940FF; Thu, 15 Dec 2011
	12:16:09 +0100 (CET)
From: Wei Wang2 <wei.wang2@amd.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Thu, 15 Dec 2011 12:18:52 +0100
User-Agent: KMail/1.9.6 (enterprise 20070904.708012)
References: <patchbomb.1323876561@gran.amd.com>
	<4EE9D8CE020000780006812F@nat28.tlf.novell.com>
In-Reply-To: <4EE9D8CE020000780006812F@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
Message-ID: <201112151218.53363.wei.wang2@amd.com>
X-OriginatorOrg: amd.com
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, xen-devel@lists.xensource.com,
	keir@xen.org
Subject: Re: [Xen-devel] [PATCH 00 of 16] [RFC] amd iommu: support ATS
	device passthru on IOMMUv2 systems
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thursday 15 December 2011 11:23:58 Jan Beulich wrote:
> >>> On 14.12.11 at 16:29, Wei Wang <wei.wang2@amd.com> wrote:
> >
> > ATS devices with PRI and PASID capabilities can communicate with iommuv2
> > to do 2 level (nested) DMA translation and IO demand paging. To do that,
> > both iommu driver and ats device have to been enabled in guest OS. This
> > patch set
> >
> > adds initial iommu emulation for hvm guests to support ATS device
> > passthru.
>
> I could take care of the first 6 patches in this series, as they're only
> touching AMD IOMMU code and look sensible to me. I'm not sure
> though whether this is a good idea without knowing the disposition
> of the other 10 patches (particularly the relative large 3rd patch
> doesn't seem to make sense without it later getting hooked up).
>
> Please let me know,
> Jan
 
Actually, the amd specific patches implement the most IOMMUv2 support. Thanks 
for looking at this. We had thought about how to integrate IOMMUv2 for ATS 
device passthru. Since guest OS requires iommu to be presented in this case, 
we could go for either PV interface or full emulation.  The iommuv2 driver 
has just been submitted to Linux mailing list, so this might be too early for 
pv iommu drivers... Using mmio handler in xen, we can avoid any guest OS 
changes and can get better performance than using qemu-dm. So this might be 
the only approach we intend to use at the moment.

But yes, eventually, the iommu emulation is driven by hypercalls. It would be 
great that tools maintainers could check this in the meantime. so, Ian, could 
I invite you to take a look at this?

Many thanks,
Wei


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 11:23:08 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 11: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.xensource.com>)
	id 1Rb9Oi-00016C-3Q; Thu, 15 Dec 2011 11:22:48 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Rb9Og-000163-T5
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 11:22:47 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1323948109!7504615!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29275 invoked from network); 15 Dec 2011 11:21:50 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-14.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 15 Dec 2011 11:21:50 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 15 Dec 2011 11:21:49 +0000
Message-Id: <4EE9E65B0200007800068188@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 15 Dec 2011 11:21:47 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part4C63E65B.1__="
Cc: Boris Ostrovsky <boris.ostrovsky@amd.com>, wei.huang2@amd.com
Subject: [Xen-devel] [PATCH] x86/AMD: use correct shift count when merging
 model and stepping
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__Part4C63E65B.1__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

... for legacy errata matching.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/cpu/amd.c
+++ b/xen/arch/x86/cpu/amd.c
@@ -216,7 +216,7 @@ int cpu_has_amd_erratum(const struct cpu
 	}
=20
 	/* OSVW unavailable or ID unknown, match family-model-stepping =
range */
-	ms =3D (cpu->x86_model << 8) | cpu->x86_mask;
+	ms =3D (cpu->x86_model << 4) | cpu->x86_mask;
 	while ((range =3D va_arg(ap, int))) {
 		if ((cpu->x86 =3D=3D AMD_MODEL_RANGE_FAMILY(range)) &&
 		    (ms >=3D AMD_MODEL_RANGE_START(range)) &&




--=__Part4C63E65B.1__=
Content-Type: text/plain; name="amd-errata-model-shift.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="amd-errata-model-shift.patch"

x86/AMD: use correct shift count when merging model and stepping=0A=0A... =
for legacy errata matching.=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.=
com>=0A=0A--- a/xen/arch/x86/cpu/amd.c=0A+++ b/xen/arch/x86/cpu/amd.c=0A@@ =
-216,7 +216,7 @@ int cpu_has_amd_erratum(const struct cpu=0A 	}=0A =0A 	=
/* OSVW unavailable or ID unknown, match family-model-stepping range =
*/=0A-	ms =3D (cpu->x86_model << 8) | cpu->x86_mask;=0A+	ms =3D =
(cpu->x86_model << 4) | cpu->x86_mask;=0A 	while ((range =3D =
va_arg(ap, int))) {=0A 		if ((cpu->x86 =3D=3D AMD_MODEL_RANGE_FAMILY=
(range)) &&=0A 		    (ms >=3D AMD_MODEL_RANGE_START(range)) &&=0A
--=__Part4C63E65B.1__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--=__Part4C63E65B.1__=--


From xen-devel-bounces@lists.xensource.com Thu Dec 15 11:23:08 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 11: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.xensource.com>)
	id 1Rb9Oi-00016C-3Q; Thu, 15 Dec 2011 11:22:48 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Rb9Og-000163-T5
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 11:22:47 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1323948109!7504615!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29275 invoked from network); 15 Dec 2011 11:21:50 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-14.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 15 Dec 2011 11:21:50 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 15 Dec 2011 11:21:49 +0000
Message-Id: <4EE9E65B0200007800068188@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 15 Dec 2011 11:21:47 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part4C63E65B.1__="
Cc: Boris Ostrovsky <boris.ostrovsky@amd.com>, wei.huang2@amd.com
Subject: [Xen-devel] [PATCH] x86/AMD: use correct shift count when merging
 model and stepping
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__Part4C63E65B.1__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

... for legacy errata matching.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/cpu/amd.c
+++ b/xen/arch/x86/cpu/amd.c
@@ -216,7 +216,7 @@ int cpu_has_amd_erratum(const struct cpu
 	}
=20
 	/* OSVW unavailable or ID unknown, match family-model-stepping =
range */
-	ms =3D (cpu->x86_model << 8) | cpu->x86_mask;
+	ms =3D (cpu->x86_model << 4) | cpu->x86_mask;
 	while ((range =3D va_arg(ap, int))) {
 		if ((cpu->x86 =3D=3D AMD_MODEL_RANGE_FAMILY(range)) &&
 		    (ms >=3D AMD_MODEL_RANGE_START(range)) &&




--=__Part4C63E65B.1__=
Content-Type: text/plain; name="amd-errata-model-shift.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="amd-errata-model-shift.patch"

x86/AMD: use correct shift count when merging model and stepping=0A=0A... =
for legacy errata matching.=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.=
com>=0A=0A--- a/xen/arch/x86/cpu/amd.c=0A+++ b/xen/arch/x86/cpu/amd.c=0A@@ =
-216,7 +216,7 @@ int cpu_has_amd_erratum(const struct cpu=0A 	}=0A =0A 	=
/* OSVW unavailable or ID unknown, match family-model-stepping range =
*/=0A-	ms =3D (cpu->x86_model << 8) | cpu->x86_mask;=0A+	ms =3D =
(cpu->x86_model << 4) | cpu->x86_mask;=0A 	while ((range =3D =
va_arg(ap, int))) {=0A 		if ((cpu->x86 =3D=3D AMD_MODEL_RANGE_FAMILY=
(range)) &&=0A 		    (ms >=3D AMD_MODEL_RANGE_START(range)) &&=0A
--=__Part4C63E65B.1__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--=__Part4C63E65B.1__=--


From xen-devel-bounces@lists.xensource.com Thu Dec 15 11:25:44 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 11:25:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rb9RI-0001De-Mf; Thu, 15 Dec 2011 11:25:28 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1Rb9RH-0001DU-BR
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 11:25:27 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1323948269!5640605!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjE2NDg=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15868 invoked from network); 15 Dec 2011 11:24:30 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 11:24:30 -0000
X-IronPort-AV: E=Sophos;i="4.71,356,1320642000"; d="scan'208";a="174258567"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Dec 2011 06:24:28 -0500
Received: from cosworth.uk.xensource.com (10.80.16.52) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 15 Dec 2011 06:24:28 -0500
MIME-Version: 1.0
X-Mercurial-Node: cc984d786b1f57b22830ac767413564011ffa837
Message-ID: <cc984d786b1f57b22830.1323948248@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Thu, 15 Dec 2011 11:24:08 +0000
From: Paul Durrant <paul.durrant@citrix.com>
To: xen-devel@lists.xensource.com
Cc: paul.durrant@citrix.com
Subject: [Xen-devel] [PATCH] [mq]: fix_gnttab2
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Paul Durrant <paul.durrant@citrix.com>
# Date 1323948142 0
# Node ID cc984d786b1f57b22830ac767413564011ffa837
# Parent  03138a08366b895d79e143119d4c9c72833cdbcd
[mq]: fix_gnttab2

diff -r 03138a08366b -r cc984d786b1f xen/arch/x86/mm.c
--- a/xen/arch/x86/mm.c	Fri Dec 09 16:19:36 2011 +0000
+++ b/xen/arch/x86/mm.c	Thu Dec 15 11:22:22 2011 +0000
@@ -4699,7 +4699,7 @@ static int xenmem_add_to_physmap_once(
                  (xatp->idx & XENMAPIDX_grant_table_status) )
             {
                 idx &= ~XENMAPIDX_grant_table_status;
-                if ( xatp->idx < nr_status_frames(d->grant_table) )
+                if ( idx < nr_status_frames(d->grant_table) )
                     mfn = virt_to_mfn(d->grant_table->status[idx]);
             }
             else

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 11:25:44 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 11:25:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rb9RI-0001De-Mf; Thu, 15 Dec 2011 11:25:28 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1Rb9RH-0001DU-BR
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 11:25:27 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1323948269!5640605!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjE2NDg=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15868 invoked from network); 15 Dec 2011 11:24:30 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 11:24:30 -0000
X-IronPort-AV: E=Sophos;i="4.71,356,1320642000"; d="scan'208";a="174258567"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Dec 2011 06:24:28 -0500
Received: from cosworth.uk.xensource.com (10.80.16.52) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 15 Dec 2011 06:24:28 -0500
MIME-Version: 1.0
X-Mercurial-Node: cc984d786b1f57b22830ac767413564011ffa837
Message-ID: <cc984d786b1f57b22830.1323948248@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Thu, 15 Dec 2011 11:24:08 +0000
From: Paul Durrant <paul.durrant@citrix.com>
To: xen-devel@lists.xensource.com
Cc: paul.durrant@citrix.com
Subject: [Xen-devel] [PATCH] [mq]: fix_gnttab2
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Paul Durrant <paul.durrant@citrix.com>
# Date 1323948142 0
# Node ID cc984d786b1f57b22830ac767413564011ffa837
# Parent  03138a08366b895d79e143119d4c9c72833cdbcd
[mq]: fix_gnttab2

diff -r 03138a08366b -r cc984d786b1f xen/arch/x86/mm.c
--- a/xen/arch/x86/mm.c	Fri Dec 09 16:19:36 2011 +0000
+++ b/xen/arch/x86/mm.c	Thu Dec 15 11:22:22 2011 +0000
@@ -4699,7 +4699,7 @@ static int xenmem_add_to_physmap_once(
                  (xatp->idx & XENMAPIDX_grant_table_status) )
             {
                 idx &= ~XENMAPIDX_grant_table_status;
-                if ( xatp->idx < nr_status_frames(d->grant_table) )
+                if ( idx < nr_status_frames(d->grant_table) )
                     mfn = virt_to_mfn(d->grant_table->status[idx]);
             }
             else

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 11:26:11 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 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.xensource.com>)
	id 1Rb9Rn-0001Fm-3s; Thu, 15 Dec 2011 11:25:59 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1Rb9Rl-0001FS-4d
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 11:25:57 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1323948299!7376179!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDY5Mjg=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2803 invoked from network); 15 Dec 2011 11:25:00 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 11:25:00 -0000
X-IronPort-AV: E=Sophos;i="4.71,356,1320642000"; d="scan'208";a="19989158"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Dec 2011 06:24:58 -0500
Received: from cosworth.uk.xensource.com (10.80.16.52) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 15 Dec 2011 06:24:58 -0500
MIME-Version: 1.0
X-Mercurial-Node: 8c9916e8d01ada87d5494c22c763cbdf259e2e6f
Message-ID: <8c9916e8d01ada87d549.1323948283@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Thu, 15 Dec 2011 11:24:43 +0000
From: Paul Durrant <paul.durrant@citrix.com>
To: xen-devel@lists.xensource.com
Cc: paul.durrant@citrix.com
Subject: [Xen-devel] [PATCH] Fix grant_table v2 status mapping
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Paul Durrant <paul.durrant@citrix.com>
# Date 1323948278 0
# Node ID 8c9916e8d01ada87d5494c22c763cbdf259e2e6f
# Parent  03138a08366b895d79e143119d4c9c72833cdbcd
Fix grant_table v2 status mapping.

Signed-off-by: Paul Durrant <paul.durrant@citrix.com>

diff -r 03138a08366b -r 8c9916e8d01a xen/arch/x86/mm.c
--- a/xen/arch/x86/mm.c	Fri Dec 09 16:19:36 2011 +0000
+++ b/xen/arch/x86/mm.c	Thu Dec 15 11:24:38 2011 +0000
@@ -4699,7 +4699,7 @@ static int xenmem_add_to_physmap_once(
                  (xatp->idx & XENMAPIDX_grant_table_status) )
             {
                 idx &= ~XENMAPIDX_grant_table_status;
-                if ( xatp->idx < nr_status_frames(d->grant_table) )
+                if ( idx < nr_status_frames(d->grant_table) )
                     mfn = virt_to_mfn(d->grant_table->status[idx]);
             }
             else

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 11:26:11 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 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.xensource.com>)
	id 1Rb9Rn-0001Fm-3s; Thu, 15 Dec 2011 11:25:59 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1Rb9Rl-0001FS-4d
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 11:25:57 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1323948299!7376179!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDY5Mjg=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2803 invoked from network); 15 Dec 2011 11:25:00 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 11:25:00 -0000
X-IronPort-AV: E=Sophos;i="4.71,356,1320642000"; d="scan'208";a="19989158"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Dec 2011 06:24:58 -0500
Received: from cosworth.uk.xensource.com (10.80.16.52) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 15 Dec 2011 06:24:58 -0500
MIME-Version: 1.0
X-Mercurial-Node: 8c9916e8d01ada87d5494c22c763cbdf259e2e6f
Message-ID: <8c9916e8d01ada87d549.1323948283@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Thu, 15 Dec 2011 11:24:43 +0000
From: Paul Durrant <paul.durrant@citrix.com>
To: xen-devel@lists.xensource.com
Cc: paul.durrant@citrix.com
Subject: [Xen-devel] [PATCH] Fix grant_table v2 status mapping
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Paul Durrant <paul.durrant@citrix.com>
# Date 1323948278 0
# Node ID 8c9916e8d01ada87d5494c22c763cbdf259e2e6f
# Parent  03138a08366b895d79e143119d4c9c72833cdbcd
Fix grant_table v2 status mapping.

Signed-off-by: Paul Durrant <paul.durrant@citrix.com>

diff -r 03138a08366b -r 8c9916e8d01a xen/arch/x86/mm.c
--- a/xen/arch/x86/mm.c	Fri Dec 09 16:19:36 2011 +0000
+++ b/xen/arch/x86/mm.c	Thu Dec 15 11:24:38 2011 +0000
@@ -4699,7 +4699,7 @@ static int xenmem_add_to_physmap_once(
                  (xatp->idx & XENMAPIDX_grant_table_status) )
             {
                 idx &= ~XENMAPIDX_grant_table_status;
-                if ( xatp->idx < nr_status_frames(d->grant_table) )
+                if ( idx < nr_status_frames(d->grant_table) )
                     mfn = virt_to_mfn(d->grant_table->status[idx]);
             }
             else

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 11:27:00 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 11:27:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rb9SX-0001LA-Ip; Thu, 15 Dec 2011 11:26:45 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1Rb9SV-0001KF-9g
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 11:26:43 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1323948345!7505332!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjI2MA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20128 invoked from network); 15 Dec 2011 11:25:45 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 11:25:45 -0000
X-IronPort-AV: E=Sophos;i="4.71,356,1320624000"; 
   d="scan'208";a="9486486"
Received: from lonpmailmx02.citrite.net ([10.30.203.163])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Dec 2011 11:25:45 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.161]) by
	LONPMAILMX02.citrite.net ([10.30.203.163]) with mapi; Thu, 15 Dec 2011
	11:25:45 +0000
From: Paul Durrant <Paul.Durrant@citrix.com>
To: Paul Durrant <Paul.Durrant@citrix.com>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>
Date: Thu, 15 Dec 2011 11:25:43 +0000
Thread-Topic: [PATCH] [mq]: fix_gnttab2
Thread-Index: Acy7HBzOg0XpgQCrQYSbk7mzSkBaHAAABNTA
Message-ID: <291EDFCB1E9E224A99088639C4762022B598ED0E9B@LONPMAILBOX01.citrite.net>
References: <cc984d786b1f57b22830.1323948248@cosworth.uk.xensource.com>
In-Reply-To: <cc984d786b1f57b22830.1323948248@cosworth.uk.xensource.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Subject: Re: [Xen-devel] [PATCH] [mq]: fix_gnttab2
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Sorry for the stupid comment. Another one coming up after a qpop/qpush...

> -----Original Message-----
> From: Paul Durrant [mailto:paul.durrant@citrix.com]
> Sent: 15 December 2011 11:24
> To: xen-devel@lists.xensource.com
> Cc: Paul Durrant
> Subject: [PATCH] [mq]: fix_gnttab2
> 
> # HG changeset patch
> # User Paul Durrant <paul.durrant@citrix.com> # Date 1323948142 0 #
> Node ID cc984d786b1f57b22830ac767413564011ffa837
> # Parent  03138a08366b895d79e143119d4c9c72833cdbcd
> [mq]: fix_gnttab2
> 
> diff -r 03138a08366b -r cc984d786b1f xen/arch/x86/mm.c
> --- a/xen/arch/x86/mm.c	Fri Dec 09 16:19:36 2011 +0000
> +++ b/xen/arch/x86/mm.c	Thu Dec 15 11:22:22 2011 +0000
> @@ -4699,7 +4699,7 @@ static int xenmem_add_to_physmap_once(
>                   (xatp->idx & XENMAPIDX_grant_table_status) )
>              {
>                  idx &= ~XENMAPIDX_grant_table_status;
> -                if ( xatp->idx < nr_status_frames(d->grant_table) )
> +                if ( idx < nr_status_frames(d->grant_table) )
>                      mfn = virt_to_mfn(d->grant_table->status[idx]);
>              }
>              else

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 11:27:00 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 11:27:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rb9SX-0001LA-Ip; Thu, 15 Dec 2011 11:26:45 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1Rb9SV-0001KF-9g
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 11:26:43 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1323948345!7505332!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjI2MA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20128 invoked from network); 15 Dec 2011 11:25:45 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 11:25:45 -0000
X-IronPort-AV: E=Sophos;i="4.71,356,1320624000"; 
   d="scan'208";a="9486486"
Received: from lonpmailmx02.citrite.net ([10.30.203.163])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Dec 2011 11:25:45 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.161]) by
	LONPMAILMX02.citrite.net ([10.30.203.163]) with mapi; Thu, 15 Dec 2011
	11:25:45 +0000
From: Paul Durrant <Paul.Durrant@citrix.com>
To: Paul Durrant <Paul.Durrant@citrix.com>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>
Date: Thu, 15 Dec 2011 11:25:43 +0000
Thread-Topic: [PATCH] [mq]: fix_gnttab2
Thread-Index: Acy7HBzOg0XpgQCrQYSbk7mzSkBaHAAABNTA
Message-ID: <291EDFCB1E9E224A99088639C4762022B598ED0E9B@LONPMAILBOX01.citrite.net>
References: <cc984d786b1f57b22830.1323948248@cosworth.uk.xensource.com>
In-Reply-To: <cc984d786b1f57b22830.1323948248@cosworth.uk.xensource.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Subject: Re: [Xen-devel] [PATCH] [mq]: fix_gnttab2
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Sorry for the stupid comment. Another one coming up after a qpop/qpush...

> -----Original Message-----
> From: Paul Durrant [mailto:paul.durrant@citrix.com]
> Sent: 15 December 2011 11:24
> To: xen-devel@lists.xensource.com
> Cc: Paul Durrant
> Subject: [PATCH] [mq]: fix_gnttab2
> 
> # HG changeset patch
> # User Paul Durrant <paul.durrant@citrix.com> # Date 1323948142 0 #
> Node ID cc984d786b1f57b22830ac767413564011ffa837
> # Parent  03138a08366b895d79e143119d4c9c72833cdbcd
> [mq]: fix_gnttab2
> 
> diff -r 03138a08366b -r cc984d786b1f xen/arch/x86/mm.c
> --- a/xen/arch/x86/mm.c	Fri Dec 09 16:19:36 2011 +0000
> +++ b/xen/arch/x86/mm.c	Thu Dec 15 11:22:22 2011 +0000
> @@ -4699,7 +4699,7 @@ static int xenmem_add_to_physmap_once(
>                   (xatp->idx & XENMAPIDX_grant_table_status) )
>              {
>                  idx &= ~XENMAPIDX_grant_table_status;
> -                if ( xatp->idx < nr_status_frames(d->grant_table) )
> +                if ( idx < nr_status_frames(d->grant_table) )
>                      mfn = virt_to_mfn(d->grant_table->status[idx]);
>              }
>              else

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 12:28:08 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 12:28:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbAPT-0002yg-20; Thu, 15 Dec 2011 12:27:39 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RbAPQ-0002yb-TF
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 12:27:37 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1323951999!5669027!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjI2MA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16083 invoked from network); 15 Dec 2011 12:26:40 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 12:26:40 -0000
X-IronPort-AV: E=Sophos;i="4.71,356,1320624000"; 
   d="scan'208";a="9487999"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Dec 2011 12:25:36 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 15 Dec 2011 12:25:36 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Thu, 15 Dec 2011 12:25:36 +0000
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323951936.20077.471.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Subject: [Xen-devel] [RFC] xl: support configuration of encrypted VNC
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Someone pointed out that it's not possible to configure encrypted vnc
via xl, while it is possible via xm. This is obviously quite nice to
have if you are logging in as root...

The following is my initial attempt but TBH I'm not sure if this is
presenting the correct interface at either the libxl or xl level. Since
I don't actually use this stuff myself I'm finding it a bit hard to
judge how much flexibility is needed or even what the right names/terms
for things are. Opinions?

Enabling basic TLS is simple enough but the x509 auth stuff is more
complicated and I expect a bit of a docs tarpit (references below).

I didn't do upstream qemu, stub qemu or vfb yet (there's a bunch of
yacks in this regard, not least factoring out the duplication). Upstream
qemu supports a few more options (e.g. sasl, see qemu(1)). SASL adds
more complexity since it can be used with or without the x509 options
depending on your needs and the specific SASL config you have in place
for qemu which complexifies all the interfaces.

Notes to be turned into docs in the final version:

Clients seem thin on the ground, neither xtightvncviewer nor vnc4viewer
support TLS. gvncviewer does seem to support all options.

http://virt-manager.org/page/RemoteTLS has a bit of stuff and some
useful links. In particular to http://libvirt.org/remote.html which has
a reasonable description of how to generate appropriate certs.  On the
server I ended up with:

/etc/xen/vnc/server-cert.pem
/etc/xen/vnc/ca-cert.pem
/etc/xen/vnc/server-key.pem

while on the client:

.pki/CA/cacert.pem
.pki/gvncviewer/clientcert.pem
.pki/gvncviewer/private/clientkey.pem

diff -r 3a9f9ba40be2 tools/libxl/libxl.h
--- a/tools/libxl/libxl.h	Tue Dec 13 17:21:46 2011 +0000
+++ b/tools/libxl/libxl.h	Thu Dec 15 11:59:28 2011 +0000
@@ -644,6 +644,7 @@ const char *libxl_xen_script_dir_path(vo
 const char *libxl_lock_dir_path(void);
 const char *libxl_run_dir_path(void);
 const char *libxl_xenpaging_dir_path(void);
+const char *libxl_vnc_cert_dir_path(void);
 
 /* misc */
 int libxl_fd_set_cloexec(int fd);
diff -r 3a9f9ba40be2 tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Tue Dec 13 17:21:46 2011 +0000
+++ b/tools/libxl/libxl_dm.c	Thu Dec 15 11:59:28 2011 +0000
@@ -121,6 +121,29 @@ static char ** libxl__build_device_model
         }
         if (info->vncpasswd && (info->vncpasswd[0] != '\0'))
             vncarg = libxl__sprintf(gc, "%s,password", vncarg);
+        switch (info->vnctls) {
+        case LIBXL_VNC_TLSMODE_NONE:
+            fprintf(stderr, "no vnc tls\n");
+            break;
+        case LIBXL_VNC_TLSMODE_TLS:
+            vncarg = libxl__sprintf(gc, "%s,tls", vncarg);
+            break;
+        case LIBXL_VNC_TLSMODE_X509:
+            vncarg = libxl__sprintf(gc, "%s,tls,x509=%s",
+                                    vncarg,
+                                    info->vnccert
+                                    ? info->vnccert
+                                    : libxl_vnc_cert_dir_path());
+            break;
+        case LIBXL_VNC_TLSMODE_X509VERIFY:
+            vncarg = libxl__sprintf(gc, "%s,tls,x509verify=%s",
+                                    vncarg,
+                                    info->vnccert
+                                    ? info->vnccert
+                                    : libxl_vnc_cert_dir_path());
+            break;
+        }
+
         flexarray_append(dm_args, "-vnc");
         flexarray_append(dm_args, vncarg);
 
@@ -990,6 +1013,8 @@ static int libxl__build_xenpv_qemu_args(
             info->vnclisten = libxl__strdup(gc, vfb->vnclisten);
         info->vncdisplay = vfb->vncdisplay;
         info->vncunused = vfb->vncunused;
+        //info->vnctls = vfb->vnctls;
+        //info->vnccert = vfb->vnccert;
         if (vfb->vncpasswd)
             info->vncpasswd = vfb->vncpasswd;
         if (vfb->keymap)
diff -r 3a9f9ba40be2 tools/libxl/libxl_paths.c
--- a/tools/libxl/libxl_paths.c	Tue Dec 13 17:21:46 2011 +0000
+++ b/tools/libxl/libxl_paths.c	Thu Dec 15 11:59:28 2011 +0000
@@ -75,6 +75,11 @@ const char *libxl_xenpaging_dir_path(voi
     return XEN_PAGING_DIR;
 }
 
+const char *libxl_vnc_cert_dir_path(void)
+{
+    return XEN_CONFIG_DIR "/vnc";
+}
+
 /*
  * Local variables:
  * mode: C
diff -r 3a9f9ba40be2 tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Tue Dec 13 17:21:46 2011 +0000
+++ b/tools/libxl/libxl_types.idl	Thu Dec 15 11:59:28 2011 +0000
@@ -92,6 +92,13 @@ libxl_tsc_mode = Enumeration("tsc_mode",
     (3, "native_paravirt"),
     ])
 
+libxl_vnc_tlsmode = Enumeration("vnc_tlsmode", [
+    (0, "none"),
+    (1, "tls"),
+    (2, "x509"),
+    (3, "x509verify"),
+    ])
+
 #
 # Complex libxl types
 #
@@ -220,6 +227,8 @@ libxl_device_model_info = Struct("device
     ("vncpasswd",        string,            False, "the VNC password"),
     ("vncdisplay",       integer,           False, "set VNC display number"),
     ("vncunused",        bool,              False, "try to find an unused port for the VNC server"),
+    ("vnctls",           libxl_vnc_tlsmode),
+    ("vnccert",          string,            False, "Path to VNC TLS certificates"),
     ("keymap",           string,            False, "set keyboard layout, default is en-us keyboard"),
     ("sdl",              bool,              False, "sdl enabled or disabled"),
     ("opengl",           bool,              False, "opengl enabled or disabled (if enabled requires sdl enabled)"),
diff -r 3a9f9ba40be2 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Tue Dec 13 17:21:46 2011 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Thu Dec 15 11:59:28 2011 +0000
@@ -1183,6 +1183,18 @@ skip_vfb:
             dm_info->vncdisplay = l;
         if (!xlu_cfg_get_long (config, "vncunused", &l, 0))
             dm_info->vncunused = l;
+        if (!xlu_cfg_get_string (config, "vnctls", &buf, 0)) {
+            fprintf(stderr, "VNC: %s\n", buf);
+            if (libxl_vnc_tlsmode_from_string(buf, &dm_info->vnctls)) {
+                fprintf(stderr, "ERROR: invalid value \"%s\" for \"vnctls\"\n",
+                        buf);
+                exit (1);
+            }
+        } else {
+            fprintf(stderr, "!VNC: %s\n", buf);
+            exit(1);
+        }
+        xlu_cfg_replace_string (config, "vnccert", &dm_info->vnccert, 0);
         xlu_cfg_replace_string (config, "keymap", &dm_info->keymap, 0);
         if (!xlu_cfg_get_long (config, "sdl", &l, 0))
             dm_info->sdl = l;



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 12:28:08 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 12:28:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbAPT-0002yg-20; Thu, 15 Dec 2011 12:27:39 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RbAPQ-0002yb-TF
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 12:27:37 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1323951999!5669027!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjI2MA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16083 invoked from network); 15 Dec 2011 12:26:40 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 12:26:40 -0000
X-IronPort-AV: E=Sophos;i="4.71,356,1320624000"; 
   d="scan'208";a="9487999"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Dec 2011 12:25:36 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 15 Dec 2011 12:25:36 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Thu, 15 Dec 2011 12:25:36 +0000
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323951936.20077.471.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Subject: [Xen-devel] [RFC] xl: support configuration of encrypted VNC
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Someone pointed out that it's not possible to configure encrypted vnc
via xl, while it is possible via xm. This is obviously quite nice to
have if you are logging in as root...

The following is my initial attempt but TBH I'm not sure if this is
presenting the correct interface at either the libxl or xl level. Since
I don't actually use this stuff myself I'm finding it a bit hard to
judge how much flexibility is needed or even what the right names/terms
for things are. Opinions?

Enabling basic TLS is simple enough but the x509 auth stuff is more
complicated and I expect a bit of a docs tarpit (references below).

I didn't do upstream qemu, stub qemu or vfb yet (there's a bunch of
yacks in this regard, not least factoring out the duplication). Upstream
qemu supports a few more options (e.g. sasl, see qemu(1)). SASL adds
more complexity since it can be used with or without the x509 options
depending on your needs and the specific SASL config you have in place
for qemu which complexifies all the interfaces.

Notes to be turned into docs in the final version:

Clients seem thin on the ground, neither xtightvncviewer nor vnc4viewer
support TLS. gvncviewer does seem to support all options.

http://virt-manager.org/page/RemoteTLS has a bit of stuff and some
useful links. In particular to http://libvirt.org/remote.html which has
a reasonable description of how to generate appropriate certs.  On the
server I ended up with:

/etc/xen/vnc/server-cert.pem
/etc/xen/vnc/ca-cert.pem
/etc/xen/vnc/server-key.pem

while on the client:

.pki/CA/cacert.pem
.pki/gvncviewer/clientcert.pem
.pki/gvncviewer/private/clientkey.pem

diff -r 3a9f9ba40be2 tools/libxl/libxl.h
--- a/tools/libxl/libxl.h	Tue Dec 13 17:21:46 2011 +0000
+++ b/tools/libxl/libxl.h	Thu Dec 15 11:59:28 2011 +0000
@@ -644,6 +644,7 @@ const char *libxl_xen_script_dir_path(vo
 const char *libxl_lock_dir_path(void);
 const char *libxl_run_dir_path(void);
 const char *libxl_xenpaging_dir_path(void);
+const char *libxl_vnc_cert_dir_path(void);
 
 /* misc */
 int libxl_fd_set_cloexec(int fd);
diff -r 3a9f9ba40be2 tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Tue Dec 13 17:21:46 2011 +0000
+++ b/tools/libxl/libxl_dm.c	Thu Dec 15 11:59:28 2011 +0000
@@ -121,6 +121,29 @@ static char ** libxl__build_device_model
         }
         if (info->vncpasswd && (info->vncpasswd[0] != '\0'))
             vncarg = libxl__sprintf(gc, "%s,password", vncarg);
+        switch (info->vnctls) {
+        case LIBXL_VNC_TLSMODE_NONE:
+            fprintf(stderr, "no vnc tls\n");
+            break;
+        case LIBXL_VNC_TLSMODE_TLS:
+            vncarg = libxl__sprintf(gc, "%s,tls", vncarg);
+            break;
+        case LIBXL_VNC_TLSMODE_X509:
+            vncarg = libxl__sprintf(gc, "%s,tls,x509=%s",
+                                    vncarg,
+                                    info->vnccert
+                                    ? info->vnccert
+                                    : libxl_vnc_cert_dir_path());
+            break;
+        case LIBXL_VNC_TLSMODE_X509VERIFY:
+            vncarg = libxl__sprintf(gc, "%s,tls,x509verify=%s",
+                                    vncarg,
+                                    info->vnccert
+                                    ? info->vnccert
+                                    : libxl_vnc_cert_dir_path());
+            break;
+        }
+
         flexarray_append(dm_args, "-vnc");
         flexarray_append(dm_args, vncarg);
 
@@ -990,6 +1013,8 @@ static int libxl__build_xenpv_qemu_args(
             info->vnclisten = libxl__strdup(gc, vfb->vnclisten);
         info->vncdisplay = vfb->vncdisplay;
         info->vncunused = vfb->vncunused;
+        //info->vnctls = vfb->vnctls;
+        //info->vnccert = vfb->vnccert;
         if (vfb->vncpasswd)
             info->vncpasswd = vfb->vncpasswd;
         if (vfb->keymap)
diff -r 3a9f9ba40be2 tools/libxl/libxl_paths.c
--- a/tools/libxl/libxl_paths.c	Tue Dec 13 17:21:46 2011 +0000
+++ b/tools/libxl/libxl_paths.c	Thu Dec 15 11:59:28 2011 +0000
@@ -75,6 +75,11 @@ const char *libxl_xenpaging_dir_path(voi
     return XEN_PAGING_DIR;
 }
 
+const char *libxl_vnc_cert_dir_path(void)
+{
+    return XEN_CONFIG_DIR "/vnc";
+}
+
 /*
  * Local variables:
  * mode: C
diff -r 3a9f9ba40be2 tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Tue Dec 13 17:21:46 2011 +0000
+++ b/tools/libxl/libxl_types.idl	Thu Dec 15 11:59:28 2011 +0000
@@ -92,6 +92,13 @@ libxl_tsc_mode = Enumeration("tsc_mode",
     (3, "native_paravirt"),
     ])
 
+libxl_vnc_tlsmode = Enumeration("vnc_tlsmode", [
+    (0, "none"),
+    (1, "tls"),
+    (2, "x509"),
+    (3, "x509verify"),
+    ])
+
 #
 # Complex libxl types
 #
@@ -220,6 +227,8 @@ libxl_device_model_info = Struct("device
     ("vncpasswd",        string,            False, "the VNC password"),
     ("vncdisplay",       integer,           False, "set VNC display number"),
     ("vncunused",        bool,              False, "try to find an unused port for the VNC server"),
+    ("vnctls",           libxl_vnc_tlsmode),
+    ("vnccert",          string,            False, "Path to VNC TLS certificates"),
     ("keymap",           string,            False, "set keyboard layout, default is en-us keyboard"),
     ("sdl",              bool,              False, "sdl enabled or disabled"),
     ("opengl",           bool,              False, "opengl enabled or disabled (if enabled requires sdl enabled)"),
diff -r 3a9f9ba40be2 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Tue Dec 13 17:21:46 2011 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Thu Dec 15 11:59:28 2011 +0000
@@ -1183,6 +1183,18 @@ skip_vfb:
             dm_info->vncdisplay = l;
         if (!xlu_cfg_get_long (config, "vncunused", &l, 0))
             dm_info->vncunused = l;
+        if (!xlu_cfg_get_string (config, "vnctls", &buf, 0)) {
+            fprintf(stderr, "VNC: %s\n", buf);
+            if (libxl_vnc_tlsmode_from_string(buf, &dm_info->vnctls)) {
+                fprintf(stderr, "ERROR: invalid value \"%s\" for \"vnctls\"\n",
+                        buf);
+                exit (1);
+            }
+        } else {
+            fprintf(stderr, "!VNC: %s\n", buf);
+            exit(1);
+        }
+        xlu_cfg_replace_string (config, "vnccert", &dm_info->vnccert, 0);
         xlu_cfg_replace_string (config, "keymap", &dm_info->keymap, 0);
         if (!xlu_cfg_get_long (config, "sdl", &l, 0))
             dm_info->sdl = l;



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 12:28:27 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 12: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.xensource.com>)
	id 1RbAPn-0002zN-Fg; Thu, 15 Dec 2011 12:27:59 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RbAPm-0002z5-7q
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 12:27:58 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1323952021!5491760!1
X-Originating-IP: [209.85.161.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP,UPPERCASE_25_50
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24610 invoked from network); 15 Dec 2011 12:27:01 -0000
Received: from mail-fx0-f43.google.com (HELO mail-fx0-f43.google.com)
	(209.85.161.43)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 12:27:01 -0000
Received: by faap21 with SMTP id p21so4719329faa.30
	for <xen-devel@lists.xensource.com>;
	Thu, 15 Dec 2011 04:27:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=m4ZmV2sgB9cM8zPJTB26+EEqrM1JijOoRahNHFk8EbQ=;
	b=F6b3R95JmyQpgBApMdh+qSnUNjFKcpzLJMXICYbTfKm8ef6vBxiYeRWEVp9fQOfk/8
	v3NmPlRC9M9WrIWWMT39rPuuKJDYFeSbKuNPiT+XxQX0SAsjDeUigacxoLpV4aXWI8rL
	1k3rh7NcL9OmsndehPMb8r2Sklc+N3arzmpOs=
Received: by 10.180.105.131 with SMTP id gm3mr4381088wib.50.1323952020573;
	Thu, 15 Dec 2011 04:27:00 -0800 (PST)
Received: from [192.168.1.3] (host81-152-17-11.range81-152.btcentralplus.com.
	[81.152.17.11])
	by mx.google.com with ESMTPS id 28sm9033367wby.3.2011.12.15.04.26.59
	(version=SSLv3 cipher=OTHER); Thu, 15 Dec 2011 04:27:00 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Thu, 15 Dec 2011 12:27:00 +0000
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>,
	Paolo Bonzini <pbonzini@redhat.com>
Message-ID: <CB0F9814.35F61%keir@xen.org>
Thread-Topic: [Xen-devel] fsincos emulation on AMD CPUs
Thread-Index: Acy7JNfDbvmN+o0+SEiHUO9W3UAuNw==
In-Reply-To: <4EE9E4E80200007800068173@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] fsincos emulation on AMD CPUs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 15/12/2011 11:15, "Jan Beulich" <JBeulich@suse.com> wrote:

> +#define AMD_ERRATUM_573       \
> +    AMD_LEGACY_ERRATUM(AMD_MODEL_RANGE(0x0f, 0x0, 0x0, 0xff, 0xf), \
> +                       AMD_MODEL_RANGE(0x10, 0x0, 0x0, 0xff, 0xf), \
> +                       AMD_MODEL_RANGE(0x11, 0x0, 0x0, 0xff, 0xf), \
> +                       AMD_MODEL_RANGE(0x12, 0x0, 0x0, 0xff, 0xf))
> +
>  struct cpuinfo_x86;
>  int cpu_has_amd_erratum(const struct cpuinfo_x86 *, int, ...);
>  
> Keir, what's your opinion here?

Bail. :-)

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 12:28:27 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 12: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.xensource.com>)
	id 1RbAPn-0002zN-Fg; Thu, 15 Dec 2011 12:27:59 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RbAPm-0002z5-7q
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 12:27:58 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1323952021!5491760!1
X-Originating-IP: [209.85.161.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP,UPPERCASE_25_50
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24610 invoked from network); 15 Dec 2011 12:27:01 -0000
Received: from mail-fx0-f43.google.com (HELO mail-fx0-f43.google.com)
	(209.85.161.43)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 12:27:01 -0000
Received: by faap21 with SMTP id p21so4719329faa.30
	for <xen-devel@lists.xensource.com>;
	Thu, 15 Dec 2011 04:27:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=m4ZmV2sgB9cM8zPJTB26+EEqrM1JijOoRahNHFk8EbQ=;
	b=F6b3R95JmyQpgBApMdh+qSnUNjFKcpzLJMXICYbTfKm8ef6vBxiYeRWEVp9fQOfk/8
	v3NmPlRC9M9WrIWWMT39rPuuKJDYFeSbKuNPiT+XxQX0SAsjDeUigacxoLpV4aXWI8rL
	1k3rh7NcL9OmsndehPMb8r2Sklc+N3arzmpOs=
Received: by 10.180.105.131 with SMTP id gm3mr4381088wib.50.1323952020573;
	Thu, 15 Dec 2011 04:27:00 -0800 (PST)
Received: from [192.168.1.3] (host81-152-17-11.range81-152.btcentralplus.com.
	[81.152.17.11])
	by mx.google.com with ESMTPS id 28sm9033367wby.3.2011.12.15.04.26.59
	(version=SSLv3 cipher=OTHER); Thu, 15 Dec 2011 04:27:00 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Thu, 15 Dec 2011 12:27:00 +0000
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>,
	Paolo Bonzini <pbonzini@redhat.com>
Message-ID: <CB0F9814.35F61%keir@xen.org>
Thread-Topic: [Xen-devel] fsincos emulation on AMD CPUs
Thread-Index: Acy7JNfDbvmN+o0+SEiHUO9W3UAuNw==
In-Reply-To: <4EE9E4E80200007800068173@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] fsincos emulation on AMD CPUs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 15/12/2011 11:15, "Jan Beulich" <JBeulich@suse.com> wrote:

> +#define AMD_ERRATUM_573       \
> +    AMD_LEGACY_ERRATUM(AMD_MODEL_RANGE(0x0f, 0x0, 0x0, 0xff, 0xf), \
> +                       AMD_MODEL_RANGE(0x10, 0x0, 0x0, 0xff, 0xf), \
> +                       AMD_MODEL_RANGE(0x11, 0x0, 0x0, 0xff, 0xf), \
> +                       AMD_MODEL_RANGE(0x12, 0x0, 0x0, 0xff, 0xf))
> +
>  struct cpuinfo_x86;
>  int cpu_has_amd_erratum(const struct cpuinfo_x86 *, int, ...);
>  
> Keir, what's your opinion here?

Bail. :-)

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 12:29:47 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 12:29:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbARB-00035j-Vm; Thu, 15 Dec 2011 12:29:25 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RbARA-00035P-MA
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 12:29:24 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-16.tower-174.messagelabs.com!1323952107!5502395!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5083 invoked from network); 15 Dec 2011 12:28:28 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-16.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 15 Dec 2011 12:28:28 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RbAQD-0001Zb-R4; Thu, 15 Dec 2011 12:28:25 +0000
Date: Thu, 15 Dec 2011 12:28:25 +0000
From: Tim Deegan <tim@xen.org>
To: Olaf Hering <olaf@aepfle.de>
Message-ID: <20111215122825.GC4274@ocelot.phlegethon.org>
References: <patchbomb.1322737756@probook.site>
	<8147822efdee65d1f5b9.1322737758@probook.site>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <8147822efdee65d1f5b9.1322737758@probook.site>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 2 of 4] xenpaging: use wait queues
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi, 

Is there a more recent version of this patch?  I see a newer version of
the wait-queues-for-mem-events one but not of this.

At 12:09 +0100 on 01 Dec (1322741358), Olaf Hering wrote:
> # HG changeset patch
> # User Olaf Hering <olaf@aepfle.de>
> # Date 1322737507 -3600
> # Node ID 8147822efdee65d1f5b94656ab2032aedb76979f
> # Parent  612f69531fd15cf59c58404f6e4762733a9a268c
> xenpaging: use wait queues
> 
> Use a wait queue to put a guest vcpu to sleep while the requested gfn is
> in paging state. This adds missing p2m_mem_paging_populate() calls to
> some callers of the new get_gfn* variants, which would crash now
> because they get an invalid mfn. It also fixes guest crashes due to
> unexpected returns from do_memory_op because copy_to/from_guest ran into
> a paged gfn. Now those places will always get a valid mfn.
> 
> Since each gfn could be requested by several guest vcpus at the same
> time a queue of paged gfns is maintained. Each vcpu will be attached to
> that queue. Once p2m_mem_paging_resume restored the gfn the waiting
> vcpus will resume execution.
> 
> There is untested code in p2m_mem_paging_init_queue() to allow cpu
> hotplug. Since each vcpu may wait on a different gfn there have to be as
> many queues as vcpus. But xl vcpu-set does not seem to work right now,
> so this code path cant be excercised right now.
> 
> 
> Signed-off-by: Olaf Hering <olaf@aepfle.de>
> 
> diff -r 612f69531fd1 -r 8147822efdee xen/arch/x86/hvm/hvm.c
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -454,6 +454,8 @@ int hvm_domain_initialise(struct domain 
>      spin_lock_init(&d->arch.hvm_domain.irq_lock);
>      spin_lock_init(&d->arch.hvm_domain.uc_lock);
>  
> +    spin_lock_init(&d->arch.hvm_domain.gfn_lock);
> +

I agree with Andres's comments on this lock, and will go futher: please
 - add it to the mm-locks.h system so we see any ordering vioations
   in future patches. 
 - add a detailed comment there explaining what exactly this lock protects.

Cheers,

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 12:29:47 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 12:29:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbARB-00035j-Vm; Thu, 15 Dec 2011 12:29:25 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RbARA-00035P-MA
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 12:29:24 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-16.tower-174.messagelabs.com!1323952107!5502395!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5083 invoked from network); 15 Dec 2011 12:28:28 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-16.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 15 Dec 2011 12:28:28 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RbAQD-0001Zb-R4; Thu, 15 Dec 2011 12:28:25 +0000
Date: Thu, 15 Dec 2011 12:28:25 +0000
From: Tim Deegan <tim@xen.org>
To: Olaf Hering <olaf@aepfle.de>
Message-ID: <20111215122825.GC4274@ocelot.phlegethon.org>
References: <patchbomb.1322737756@probook.site>
	<8147822efdee65d1f5b9.1322737758@probook.site>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <8147822efdee65d1f5b9.1322737758@probook.site>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 2 of 4] xenpaging: use wait queues
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi, 

Is there a more recent version of this patch?  I see a newer version of
the wait-queues-for-mem-events one but not of this.

At 12:09 +0100 on 01 Dec (1322741358), Olaf Hering wrote:
> # HG changeset patch
> # User Olaf Hering <olaf@aepfle.de>
> # Date 1322737507 -3600
> # Node ID 8147822efdee65d1f5b94656ab2032aedb76979f
> # Parent  612f69531fd15cf59c58404f6e4762733a9a268c
> xenpaging: use wait queues
> 
> Use a wait queue to put a guest vcpu to sleep while the requested gfn is
> in paging state. This adds missing p2m_mem_paging_populate() calls to
> some callers of the new get_gfn* variants, which would crash now
> because they get an invalid mfn. It also fixes guest crashes due to
> unexpected returns from do_memory_op because copy_to/from_guest ran into
> a paged gfn. Now those places will always get a valid mfn.
> 
> Since each gfn could be requested by several guest vcpus at the same
> time a queue of paged gfns is maintained. Each vcpu will be attached to
> that queue. Once p2m_mem_paging_resume restored the gfn the waiting
> vcpus will resume execution.
> 
> There is untested code in p2m_mem_paging_init_queue() to allow cpu
> hotplug. Since each vcpu may wait on a different gfn there have to be as
> many queues as vcpus. But xl vcpu-set does not seem to work right now,
> so this code path cant be excercised right now.
> 
> 
> Signed-off-by: Olaf Hering <olaf@aepfle.de>
> 
> diff -r 612f69531fd1 -r 8147822efdee xen/arch/x86/hvm/hvm.c
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -454,6 +454,8 @@ int hvm_domain_initialise(struct domain 
>      spin_lock_init(&d->arch.hvm_domain.irq_lock);
>      spin_lock_init(&d->arch.hvm_domain.uc_lock);
>  
> +    spin_lock_init(&d->arch.hvm_domain.gfn_lock);
> +

I agree with Andres's comments on this lock, and will go futher: please
 - add it to the mm-locks.h system so we see any ordering vioations
   in future patches. 
 - add a detailed comment there explaining what exactly this lock protects.

Cheers,

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 12:30:52 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 12: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.xensource.com>)
	id 1RbASF-0003Cd-Ev; Thu, 15 Dec 2011 12:30:31 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RbASD-0003Bd-OQ
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 12:30:29 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1323952166!5659163!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjI2MA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19959 invoked from network); 15 Dec 2011 12:29:27 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 12:29:27 -0000
X-IronPort-AV: E=Sophos;i="4.71,357,1320624000"; 
   d="scan'208";a="9488191"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Dec 2011 12:29:24 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 15 Dec 2011 12:29:24 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Wei Wang <wei.wang2@amd.com>
Date: Thu, 15 Dec 2011 12:29:23 +0000
In-Reply-To: <42ecb2ba593c2827b2dc.1323876573@gran.amd.com>
References: <patchbomb.1323876561@gran.amd.com>
	<42ecb2ba593c2827b2dc.1323876573@gran.amd.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323952163.20077.473.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, "JBeulich@suse.com" <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 12 of 16] hvmloader: Build IVRS table
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2011-12-14 at 15:29 +0000, Wei Wang wrote:
> hvmloader: Build IVRS table.

Is there a good reference for what is in this table?

> diff -r 9a93e064dd3c -r 42ecb2ba593c
> xen/include/public/hvm/hvm_info_table.h
> --- a/xen/include/public/hvm/hvm_info_table.h   Wed Dec 14 16:16:16
> 2011 +0100
> +++ b/xen/include/public/hvm/hvm_info_table.h   Wed Dec 14 16:22:20
> 2011 +0100
> @@ -67,6 +67,9 @@ struct hvm_info_table {
> 
>      /* Bitmap of which CPUs are online at boot time. */
>      uint8_t     vcpu_online[(HVM_MAX_VCPUS + 7)/8];
> +
> +    /* guest iommu enabled */
> +    uint8_t     iommu_enabled;
>  };
> 
>  #endif /* __XEN_PUBLIC_HVM_HVM_INFO_TABLE_H__ */

We would like to remove the hvm info table. Please could you do this via
xenstore (like Paul Durrant recently did for acpi s3 support) .

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 12:30:52 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 12: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.xensource.com>)
	id 1RbASF-0003Cd-Ev; Thu, 15 Dec 2011 12:30:31 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RbASD-0003Bd-OQ
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 12:30:29 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1323952166!5659163!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjI2MA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19959 invoked from network); 15 Dec 2011 12:29:27 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 12:29:27 -0000
X-IronPort-AV: E=Sophos;i="4.71,357,1320624000"; 
   d="scan'208";a="9488191"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Dec 2011 12:29:24 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 15 Dec 2011 12:29:24 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Wei Wang <wei.wang2@amd.com>
Date: Thu, 15 Dec 2011 12:29:23 +0000
In-Reply-To: <42ecb2ba593c2827b2dc.1323876573@gran.amd.com>
References: <patchbomb.1323876561@gran.amd.com>
	<42ecb2ba593c2827b2dc.1323876573@gran.amd.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323952163.20077.473.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, "JBeulich@suse.com" <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 12 of 16] hvmloader: Build IVRS table
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2011-12-14 at 15:29 +0000, Wei Wang wrote:
> hvmloader: Build IVRS table.

Is there a good reference for what is in this table?

> diff -r 9a93e064dd3c -r 42ecb2ba593c
> xen/include/public/hvm/hvm_info_table.h
> --- a/xen/include/public/hvm/hvm_info_table.h   Wed Dec 14 16:16:16
> 2011 +0100
> +++ b/xen/include/public/hvm/hvm_info_table.h   Wed Dec 14 16:22:20
> 2011 +0100
> @@ -67,6 +67,9 @@ struct hvm_info_table {
> 
>      /* Bitmap of which CPUs are online at boot time. */
>      uint8_t     vcpu_online[(HVM_MAX_VCPUS + 7)/8];
> +
> +    /* guest iommu enabled */
> +    uint8_t     iommu_enabled;
>  };
> 
>  #endif /* __XEN_PUBLIC_HVM_HVM_INFO_TABLE_H__ */

We would like to remove the hvm info table. Please could you do this via
xenstore (like Paul Durrant recently did for acpi s3 support) .

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 12:34:38 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 12: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.xensource.com>)
	id 1RbAVv-0004Zz-3k; Thu, 15 Dec 2011 12:34:19 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RbAVu-0004Zh-Im
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 12:34:18 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1323952401!5693296!1
X-Originating-IP: [209.85.161.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24505 invoked from network); 15 Dec 2011 12:33:21 -0000
Received: from mail-fx0-f43.google.com (HELO mail-fx0-f43.google.com)
	(209.85.161.43)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 12:33:21 -0000
Received: by faap21 with SMTP id p21so4737400faa.30
	for <xen-devel@lists.xensource.com>;
	Thu, 15 Dec 2011 04:33:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=kgPlAHSBX4J/W1wKy426XyhF+iKb8TQtAnFF5NNmEBU=;
	b=tcp/tWMTsweZzVRDM+tj1C653YTfGollHJ5b+O9d+gv7NYqbA1UHgSNvM/bge6V+qW
	NwWamOi0la5LazH1st1eWuewDKNFKcgAkos3D/pt1RxNuMd7me7ILfyGsc+U+HH0Sw7z
	hcuaZsiTk1Y76207ppdFSdJvx/RiEo5mSz41c=
Received: by 10.180.92.195 with SMTP id co3mr4494450wib.38.1323952401525;
	Thu, 15 Dec 2011 04:33:21 -0800 (PST)
Received: from [192.168.1.3] (host81-152-17-11.range81-152.btcentralplus.com.
	[81.152.17.11])
	by mx.google.com with ESMTPS id ei9sm8073277wid.0.2011.12.15.04.33.20
	(version=SSLv3 cipher=OTHER); Thu, 15 Dec 2011 04:33:21 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Thu, 15 Dec 2011 12:33:13 +0000
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>,
	Paolo Bonzini <pbonzini@redhat.com>
Message-ID: <CB0F9989.35F66%keir@xen.org>
Thread-Topic: [Xen-devel] fsincos emulation on AMD CPUs
Thread-Index: Acy7JNfDbvmN+o0+SEiHUO9W3UAuNwAAN5SI
In-Reply-To: <CB0F9814.35F61%keir@xen.org>
Mime-version: 1.0
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] fsincos emulation on AMD CPUs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 15/12/2011 12:27, "Keir Fraser" <keir@xen.org> wrote:

> On 15/12/2011 11:15, "Jan Beulich" <JBeulich@suse.com> wrote:
> 
>> +#define AMD_ERRATUM_573       \
>> +    AMD_LEGACY_ERRATUM(AMD_MODEL_RANGE(0x0f, 0x0, 0x0, 0xff, 0xf), \
>> +                       AMD_MODEL_RANGE(0x10, 0x0, 0x0, 0xff, 0xf), \
>> +                       AMD_MODEL_RANGE(0x11, 0x0, 0x0, 0xff, 0xf), \
>> +                       AMD_MODEL_RANGE(0x12, 0x0, 0x0, 0xff, 0xf))
>> +
>>  struct cpuinfo_x86;
>>  int cpu_has_amd_erratum(const struct cpuinfo_x86 *, int, ...);
>>  
>> Keir, what's your opinion here?
> 
> Bail. :-)

More detail: the full patch is ugly and hard to test all cases. And there's
no practical scenario where we want to emulate FSINCOS on AMD -- we don't
emulate realmode on AMD, FSINCOS on a shadowed page certainly indicates that
we should unshadow the page, FSINCOS on MMIO is mad or malicious.

Pretty much the whole x87 emulation thing is for realmode on Intel.

 -- Keir

>  -- Keir
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 12:34:38 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 12: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.xensource.com>)
	id 1RbAVv-0004Zz-3k; Thu, 15 Dec 2011 12:34:19 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RbAVu-0004Zh-Im
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 12:34:18 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1323952401!5693296!1
X-Originating-IP: [209.85.161.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24505 invoked from network); 15 Dec 2011 12:33:21 -0000
Received: from mail-fx0-f43.google.com (HELO mail-fx0-f43.google.com)
	(209.85.161.43)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 12:33:21 -0000
Received: by faap21 with SMTP id p21so4737400faa.30
	for <xen-devel@lists.xensource.com>;
	Thu, 15 Dec 2011 04:33:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=kgPlAHSBX4J/W1wKy426XyhF+iKb8TQtAnFF5NNmEBU=;
	b=tcp/tWMTsweZzVRDM+tj1C653YTfGollHJ5b+O9d+gv7NYqbA1UHgSNvM/bge6V+qW
	NwWamOi0la5LazH1st1eWuewDKNFKcgAkos3D/pt1RxNuMd7me7ILfyGsc+U+HH0Sw7z
	hcuaZsiTk1Y76207ppdFSdJvx/RiEo5mSz41c=
Received: by 10.180.92.195 with SMTP id co3mr4494450wib.38.1323952401525;
	Thu, 15 Dec 2011 04:33:21 -0800 (PST)
Received: from [192.168.1.3] (host81-152-17-11.range81-152.btcentralplus.com.
	[81.152.17.11])
	by mx.google.com with ESMTPS id ei9sm8073277wid.0.2011.12.15.04.33.20
	(version=SSLv3 cipher=OTHER); Thu, 15 Dec 2011 04:33:21 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Thu, 15 Dec 2011 12:33:13 +0000
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>,
	Paolo Bonzini <pbonzini@redhat.com>
Message-ID: <CB0F9989.35F66%keir@xen.org>
Thread-Topic: [Xen-devel] fsincos emulation on AMD CPUs
Thread-Index: Acy7JNfDbvmN+o0+SEiHUO9W3UAuNwAAN5SI
In-Reply-To: <CB0F9814.35F61%keir@xen.org>
Mime-version: 1.0
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] fsincos emulation on AMD CPUs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 15/12/2011 12:27, "Keir Fraser" <keir@xen.org> wrote:

> On 15/12/2011 11:15, "Jan Beulich" <JBeulich@suse.com> wrote:
> 
>> +#define AMD_ERRATUM_573       \
>> +    AMD_LEGACY_ERRATUM(AMD_MODEL_RANGE(0x0f, 0x0, 0x0, 0xff, 0xf), \
>> +                       AMD_MODEL_RANGE(0x10, 0x0, 0x0, 0xff, 0xf), \
>> +                       AMD_MODEL_RANGE(0x11, 0x0, 0x0, 0xff, 0xf), \
>> +                       AMD_MODEL_RANGE(0x12, 0x0, 0x0, 0xff, 0xf))
>> +
>>  struct cpuinfo_x86;
>>  int cpu_has_amd_erratum(const struct cpuinfo_x86 *, int, ...);
>>  
>> Keir, what's your opinion here?
> 
> Bail. :-)

More detail: the full patch is ugly and hard to test all cases. And there's
no practical scenario where we want to emulate FSINCOS on AMD -- we don't
emulate realmode on AMD, FSINCOS on a shadowed page certainly indicates that
we should unshadow the page, FSINCOS on MMIO is mad or malicious.

Pretty much the whole x87 emulation thing is for realmode on Intel.

 -- Keir

>  -- Keir
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 12:37:47 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 12:37:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbAYz-0004qj-No; Thu, 15 Dec 2011 12:37:29 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RbAYy-0004qT-24
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 12:37:28 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1323952588!2093214!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11824 invoked from network); 15 Dec 2011 12:36:28 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-9.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 15 Dec 2011 12:36:28 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 12 Dec 2011 16:10:36 +0000
Message-Id: <4EE635C20200007800067068@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 12 Dec 2011 16:11:30 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part456AE0A2.0__="
Subject: [Xen-devel] [PATCH 4/4] ACPI: eliminate duplicate IVRS definitions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__Part456AE0A2.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Use their proper counterparts in include/acpi/actbl*.h instead.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/drivers/passthrough/amd/iommu_acpi.c
+++ b/xen/drivers/passthrough/amd/iommu_acpi.c
@@ -20,10 +20,38 @@
=20
 #include <xen/config.h>
 #include <xen/errno.h>
+#include <xen/acpi.h>
 #include <asm/apicdef.h>
 #include <asm/amd-iommu.h>
 #include <asm/hvm/svm/amd-iommu-proto.h>
-#include <asm/hvm/svm/amd-iommu-acpi.h>
+
+/* Some helper structures, particularly to deal with ranges. */
+
+struct acpi_ivhd_device_range {
+   struct acpi_ivrs_device4 start;
+   struct acpi_ivrs_device4 end;
+};
+
+struct acpi_ivhd_device_alias_range {
+   struct acpi_ivrs_device8a alias;
+   struct acpi_ivrs_device4 end;
+};
+
+struct acpi_ivhd_device_extended_range {
+   struct acpi_ivrs_device8b extended;
+   struct acpi_ivrs_device4 end;
+};
+
+union acpi_ivhd_device {
+   struct acpi_ivrs_de_header header;
+   struct acpi_ivrs_device4 select;
+   struct acpi_ivhd_device_range range;
+   struct acpi_ivrs_device8a alias;
+   struct acpi_ivhd_device_alias_range alias_range;
+   struct acpi_ivrs_device8b extended;
+   struct acpi_ivhd_device_extended_range extended_range;
+   struct acpi_ivrs_device8c special;
+};
=20
 static unsigned short __initdata last_bdf;
=20
@@ -242,12 +270,12 @@ static int __init register_exclusion_ran
 }
=20
 static int __init parse_ivmd_device_select(
-    struct acpi_ivmd_block_header *ivmd_block,
+    const struct acpi_ivrs_memory *ivmd_block,
     unsigned long base, unsigned long limit, u8 iw, u8 ir)
 {
     u16 bdf;
=20
-    bdf =3D ivmd_block->header.dev_id;
+    bdf =3D ivmd_block->header.device_id;
     if ( bdf >=3D ivrs_bdf_entries )
     {
         AMD_IOMMU_DEBUG("IVMD Error: Invalid Dev_Id 0x%x\n", bdf);
@@ -258,13 +286,13 @@ static int __init parse_ivmd_device_sele
 }
=20
 static int __init parse_ivmd_device_range(
-    struct acpi_ivmd_block_header *ivmd_block,
+    const struct acpi_ivrs_memory *ivmd_block,
     unsigned long base, unsigned long limit, u8 iw, u8 ir)
 {
     u16 first_bdf, last_bdf, bdf;
     int error;
=20
-    first_bdf =3D ivmd_block->header.dev_id;
+    first_bdf =3D ivmd_block->header.device_id;
     if ( first_bdf >=3D ivrs_bdf_entries )
     {
         AMD_IOMMU_DEBUG("IVMD Error: "
@@ -272,7 +300,7 @@ static int __init parse_ivmd_device_rang
         return -ENODEV;
     }
=20
-    last_bdf =3D ivmd_block->last_dev_id;
+    last_bdf =3D ivmd_block->aux_data;
     if ( (last_bdf >=3D ivrs_bdf_entries) || (last_bdf <=3D first_bdf) )
     {
         AMD_IOMMU_DEBUG("IVMD Error: "
@@ -288,18 +316,18 @@ static int __init parse_ivmd_device_rang
 }
=20
 static int __init parse_ivmd_device_iommu(
-    struct acpi_ivmd_block_header *ivmd_block,
+    const struct acpi_ivrs_memory *ivmd_block,
     unsigned long base, unsigned long limit, u8 iw, u8 ir)
 {
     struct amd_iommu *iommu;
=20
     /* find target IOMMU */
-    iommu =3D find_iommu_from_bdf_cap(ivmd_block->header.dev_id,
-                                    ivmd_block->cap_offset);
+    iommu =3D find_iommu_from_bdf_cap(ivmd_block->header.device_id,
+                                    ivmd_block->aux_data);
     if ( !iommu )
     {
         AMD_IOMMU_DEBUG("IVMD Error: No IOMMU for Dev_Id 0x%x  Cap =
0x%x\n",
-                        ivmd_block->header.dev_id, ivmd_block->cap_offset)=
;
+                        ivmd_block->header.device_id, ivmd_block->aux_data=
);
         return -ENODEV;
     }
=20
@@ -307,20 +335,19 @@ static int __init parse_ivmd_device_iomm
         iommu, base, limit, iw, ir);
 }
=20
-static int __init parse_ivmd_block(struct acpi_ivmd_block_header =
*ivmd_block)
+static int __init parse_ivmd_block(const struct acpi_ivrs_memory =
*ivmd_block)
 {
     unsigned long start_addr, mem_length, base, limit;
     u8 iw, ir;
=20
-    if ( ivmd_block->header.length <
-         sizeof(struct acpi_ivmd_block_header) )
+    if ( ivmd_block->header.length < sizeof(*ivmd_block) )
     {
         AMD_IOMMU_DEBUG("IVMD Error: Invalid Block Length!\n");
         return -ENODEV;
     }
=20
-    start_addr =3D (unsigned long)ivmd_block->start_addr;
-    mem_length =3D (unsigned long)ivmd_block->mem_length;
+    start_addr =3D (unsigned long)ivmd_block->start_address;
+    mem_length =3D (unsigned long)ivmd_block->memory_length;
     base =3D start_addr & PAGE_MASK;
     limit =3D (start_addr + mem_length - 1) & PAGE_MASK;
=20
@@ -328,20 +355,14 @@ static int __init parse_ivmd_block(struc
     AMD_IOMMU_DEBUG(" Start_Addr_Phys 0x%lx\n", start_addr);
     AMD_IOMMU_DEBUG(" Mem_Length 0x%lx\n", mem_length);
=20
-    if ( get_field_from_byte(ivmd_block->header.flags,
-                             AMD_IOMMU_ACPI_EXCLUSION_RANGE_MASK,
-                             AMD_IOMMU_ACPI_EXCLUSION_RANGE_SHIFT) )
+    if ( ivmd_block->header.flags & ACPI_IVMD_EXCLUSION_RANGE )
         iw =3D ir =3D IOMMU_CONTROL_ENABLED;
-    else if ( get_field_from_byte(ivmd_block->header.flags,
-                                  AMD_IOMMU_ACPI_UNITY_MAPPING_MASK,
-                                  AMD_IOMMU_ACPI_UNITY_MAPPING_SHIFT) )
-    {
-        iw =3D get_field_from_byte(ivmd_block->header.flags,
-                                 AMD_IOMMU_ACPI_IW_PERMISSION_MASK,
-                                 AMD_IOMMU_ACPI_IW_PERMISSION_SHIFT);
-        ir =3D get_field_from_byte(ivmd_block->header.flags,
-                                 AMD_IOMMU_ACPI_IR_PERMISSION_MASK,
-                                 AMD_IOMMU_ACPI_IR_PERMISSION_SHIFT);
+    else if ( ivmd_block->header.flags & ACPI_IVMD_UNITY )
+    {
+        iw =3D ivmd_block->header.flags & ACPI_IVMD_READ ?
+            IOMMU_CONTROL_ENABLED : IOMMU_CONTROL_DISABLED;
+        ir =3D ivmd_block->header.flags & ACPI_IVMD_WRITE ?
+            IOMMU_CONTROL_ENABLED : IOMMU_CONTROL_DISABLED;
     }
     else
     {
@@ -351,19 +372,19 @@ static int __init parse_ivmd_block(struc
=20
     switch( ivmd_block->header.type )
     {
-    case AMD_IOMMU_ACPI_IVMD_ALL_TYPE:
+    case ACPI_IVRS_TYPE_MEMORY_ALL:
         return register_exclusion_range_for_all_devices(
             base, limit, iw, ir);
=20
-    case AMD_IOMMU_ACPI_IVMD_ONE_TYPE:
+    case ACPI_IVRS_TYPE_MEMORY_ONE:
         return parse_ivmd_device_select(ivmd_block,
                                         base, limit, iw, ir);
=20
-    case AMD_IOMMU_ACPI_IVMD_RANGE_TYPE:
+    case ACPI_IVRS_TYPE_MEMORY_RANGE:
         return parse_ivmd_device_range(ivmd_block,
                                        base, limit, iw, ir);
=20
-    case AMD_IOMMU_ACPI_IVMD_IOMMU_TYPE:
+    case ACPI_IVRS_TYPE_MEMORY_IOMMU:
         return parse_ivmd_device_iommu(ivmd_block,
                                        base, limit, iw, ir);
=20
@@ -386,45 +407,44 @@ static u16 __init parse_ivhd_device_padd
 }
=20
 static u16 __init parse_ivhd_device_select(
-    union acpi_ivhd_device *ivhd_device, struct amd_iommu *iommu)
+    const struct acpi_ivrs_device4 *select, struct amd_iommu *iommu)
 {
     u16 bdf;
=20
-    bdf =3D ivhd_device->header.dev_id;
+    bdf =3D select->header.id;
     if ( bdf >=3D ivrs_bdf_entries )
     {
         AMD_IOMMU_DEBUG("IVHD Error: Invalid Device_Entry Dev_Id 0x%x\n", =
bdf);
         return 0;
     }
=20
-    add_ivrs_mapping_entry(bdf, bdf, ivhd_device->header.flags, iommu);
+    add_ivrs_mapping_entry(bdf, bdf, select->header.data_setting, iommu);
=20
-    return sizeof(struct acpi_ivhd_device_header);
+    return sizeof(*select);
 }
=20
 static u16 __init parse_ivhd_device_range(
-    union acpi_ivhd_device *ivhd_device,
+    const struct acpi_ivhd_device_range *range,
     u16 header_length, u16 block_length, struct amd_iommu *iommu)
 {
     u16 dev_length, first_bdf, last_bdf, bdf;
=20
-    dev_length =3D sizeof(struct acpi_ivhd_device_range);
+    dev_length =3D sizeof(*range);
     if ( header_length < (block_length + dev_length) )
     {
         AMD_IOMMU_DEBUG("IVHD Error: Invalid Device_Entry Length!\n");
         return 0;
     }
=20
-    if ( ivhd_device->range.trailer.type !=3D
-         AMD_IOMMU_ACPI_IVHD_DEV_RANGE_END )
+    if ( range->end.header.type !=3D ACPI_IVRS_TYPE_END )
     {
         AMD_IOMMU_DEBUG("IVHD Error: "
                         "Invalid Range: End_Type 0x%x\n",
-                        ivhd_device->range.trailer.type);
+                        range->end.header.type);
         return 0;
     }
=20
-    first_bdf =3D ivhd_device->header.dev_id;
+    first_bdf =3D range->start.header.id;
     if ( first_bdf >=3D ivrs_bdf_entries )
     {
         AMD_IOMMU_DEBUG("IVHD Error: "
@@ -432,7 +452,7 @@ static u16 __init parse_ivhd_device_rang
         return 0;
     }
=20
-    last_bdf =3D ivhd_device->range.trailer.dev_id;
+    last_bdf =3D range->end.header.id;
     if ( (last_bdf >=3D ivrs_bdf_entries) || (last_bdf <=3D first_bdf) )
     {
         AMD_IOMMU_DEBUG("IVHD Error: "
@@ -443,32 +463,33 @@ static u16 __init parse_ivhd_device_rang
     AMD_IOMMU_DEBUG(" Dev_Id Range: 0x%x -> 0x%x\n", first_bdf, last_bdf);=

=20
     for ( bdf =3D first_bdf; bdf <=3D last_bdf; bdf++ )
-        add_ivrs_mapping_entry(bdf, bdf, ivhd_device->header.flags, =
iommu);
+        add_ivrs_mapping_entry(bdf, bdf, range->start.header.data_setting,=

+                               iommu);
=20
     return dev_length;
 }
=20
 static u16 __init parse_ivhd_device_alias(
-    union acpi_ivhd_device *ivhd_device,
+    const struct acpi_ivrs_device8a *alias,
     u16 header_length, u16 block_length, struct amd_iommu *iommu)
 {
     u16 dev_length, alias_id, bdf;
=20
-    dev_length =3D sizeof(struct acpi_ivhd_device_alias);
+    dev_length =3D sizeof(*alias);
     if ( header_length < (block_length + dev_length) )
     {
         AMD_IOMMU_DEBUG("IVHD Error: Invalid Device_Entry Length!\n");
         return 0;
     }
=20
-    bdf =3D ivhd_device->header.dev_id;
+    bdf =3D alias->header.id;
     if ( bdf >=3D ivrs_bdf_entries )
     {
         AMD_IOMMU_DEBUG("IVHD Error: Invalid Device_Entry Dev_Id 0x%x\n", =
bdf);
         return 0;
     }
=20
-    alias_id =3D ivhd_device->alias.dev_id;
+    alias_id =3D alias->used_id;
     if ( alias_id >=3D ivrs_bdf_entries )
     {
         AMD_IOMMU_DEBUG("IVHD Error: Invalid Alias Dev_Id 0x%x\n", =
alias_id);
@@ -477,35 +498,34 @@ static u16 __init parse_ivhd_device_alia
=20
     AMD_IOMMU_DEBUG(" Dev_Id Alias: 0x%x\n", alias_id);
=20
-    add_ivrs_mapping_entry(bdf, alias_id, ivhd_device->header.flags, =
iommu);
+    add_ivrs_mapping_entry(bdf, alias_id, alias->header.data_setting, =
iommu);
=20
     return dev_length;
 }
=20
 static u16 __init parse_ivhd_device_alias_range(
-    union acpi_ivhd_device *ivhd_device,
+    const struct acpi_ivhd_device_alias_range *range,
     u16 header_length, u16 block_length, struct amd_iommu *iommu)
 {
=20
     u16 dev_length, first_bdf, last_bdf, alias_id, bdf;
=20
-    dev_length =3D sizeof(struct acpi_ivhd_device_alias_range);
+    dev_length =3D sizeof(*range);
     if ( header_length < (block_length + dev_length) )
     {
         AMD_IOMMU_DEBUG("IVHD Error: Invalid Device_Entry Length!\n");
         return 0;
     }
=20
-    if ( ivhd_device->alias_range.trailer.type !=3D
-         AMD_IOMMU_ACPI_IVHD_DEV_RANGE_END )
+    if ( range->end.header.type !=3D ACPI_IVRS_TYPE_END )
     {
         AMD_IOMMU_DEBUG("IVHD Error: "
                         "Invalid Range: End_Type 0x%x\n",
-                        ivhd_device->alias_range.trailer.type);
+                        range->end.header.type);
         return 0;
     }
=20
-    first_bdf =3D ivhd_device->header.dev_id;
+    first_bdf =3D range->alias.header.id;
     if ( first_bdf >=3D ivrs_bdf_entries )
     {
         AMD_IOMMU_DEBUG("IVHD Error: "
@@ -513,7 +533,7 @@ static u16 __init parse_ivhd_device_alia
         return 0;
     }
=20
-    last_bdf =3D ivhd_device->alias_range.trailer.dev_id;
+    last_bdf =3D range->end.header.id;
     if ( last_bdf >=3D ivrs_bdf_entries || last_bdf <=3D first_bdf )
     {
         AMD_IOMMU_DEBUG(
@@ -521,7 +541,7 @@ static u16 __init parse_ivhd_device_alia
         return 0;
     }
=20
-    alias_id =3D ivhd_device->alias_range.alias.dev_id;
+    alias_id =3D range->alias.used_id;
     if ( alias_id >=3D ivrs_bdf_entries )
     {
         AMD_IOMMU_DEBUG("IVHD Error: Invalid Alias Dev_Id 0x%x\n", =
alias_id);
@@ -532,59 +552,59 @@ static u16 __init parse_ivhd_device_alia
     AMD_IOMMU_DEBUG(" Dev_Id Alias: 0x%x\n", alias_id);
=20
     for ( bdf =3D first_bdf; bdf <=3D last_bdf; bdf++ )
-        add_ivrs_mapping_entry(bdf, alias_id, ivhd_device->header.flags, =
iommu);
+        add_ivrs_mapping_entry(bdf, alias_id, range->alias.header.data_set=
ting,
+                               iommu);
=20
     return dev_length;
 }
=20
 static u16 __init parse_ivhd_device_extended(
-    union acpi_ivhd_device *ivhd_device,
+    const struct acpi_ivrs_device8b *ext,
     u16 header_length, u16 block_length, struct amd_iommu *iommu)
 {
     u16 dev_length, bdf;
=20
-    dev_length =3D sizeof(struct acpi_ivhd_device_extended);
+    dev_length =3D sizeof(*ext);
     if ( header_length < (block_length + dev_length) )
     {
         AMD_IOMMU_DEBUG("IVHD Error: Invalid Device_Entry Length!\n");
         return 0;
     }
=20
-    bdf =3D ivhd_device->header.dev_id;
+    bdf =3D ext->header.id;
     if ( bdf >=3D ivrs_bdf_entries )
     {
         AMD_IOMMU_DEBUG("IVHD Error: Invalid Device_Entry Dev_Id 0x%x\n", =
bdf);
         return 0;
     }
=20
-    add_ivrs_mapping_entry(bdf, bdf, ivhd_device->header.flags, iommu);
+    add_ivrs_mapping_entry(bdf, bdf, ext->header.data_setting, iommu);
=20
     return dev_length;
 }
=20
 static u16 __init parse_ivhd_device_extended_range(
-    union acpi_ivhd_device *ivhd_device,
+    const struct acpi_ivhd_device_extended_range *range,
     u16 header_length, u16 block_length, struct amd_iommu *iommu)
 {
     u16 dev_length, first_bdf, last_bdf, bdf;
=20
-    dev_length =3D sizeof(struct acpi_ivhd_device_extended_range);
+    dev_length =3D sizeof(*range);
     if ( header_length < (block_length + dev_length) )
     {
         AMD_IOMMU_DEBUG("IVHD Error: Invalid Device_Entry Length!\n");
         return 0;
     }
=20
-    if ( ivhd_device->extended_range.trailer.type !=3D
-         AMD_IOMMU_ACPI_IVHD_DEV_RANGE_END )
+    if ( range->end.header.type !=3D ACPI_IVRS_TYPE_END )
     {
         AMD_IOMMU_DEBUG("IVHD Error: "
                         "Invalid Range: End_Type 0x%x\n",
-                        ivhd_device->extended_range.trailer.type);
+                        range->end.header.type);
         return 0;
     }
=20
-    first_bdf =3D ivhd_device->header.dev_id;
+    first_bdf =3D range->extended.header.id;
     if ( first_bdf >=3D ivrs_bdf_entries )
     {
         AMD_IOMMU_DEBUG("IVHD Error: "
@@ -592,7 +612,7 @@ static u16 __init parse_ivhd_device_exte
         return 0;
     }
=20
-    last_bdf =3D ivhd_device->extended_range.trailer.dev_id;
+    last_bdf =3D range->end.header.id;
     if ( (last_bdf >=3D ivrs_bdf_entries) || (last_bdf <=3D first_bdf) )
     {
         AMD_IOMMU_DEBUG("IVHD Error: "
@@ -604,116 +624,116 @@ static u16 __init parse_ivhd_device_exte
                     first_bdf, last_bdf);
=20
     for ( bdf =3D first_bdf; bdf <=3D last_bdf; bdf++ )
-        add_ivrs_mapping_entry(bdf, bdf, ivhd_device->header.flags, =
iommu);
+        add_ivrs_mapping_entry(bdf, bdf, range->extended.header.data_setti=
ng,
+                               iommu);
=20
     return dev_length;
 }
=20
 static u16 __init parse_ivhd_device_special(
-    union acpi_ivhd_device *ivhd_device, u16 seg,
+    const struct acpi_ivrs_device8c *special, u16 seg,
     u16 header_length, u16 block_length, struct amd_iommu *iommu)
 {
     u16 dev_length, bdf;
=20
-    dev_length =3D sizeof(struct acpi_ivhd_device_special);
+    dev_length =3D sizeof(*special);
     if ( header_length < (block_length + dev_length) )
     {
         AMD_IOMMU_DEBUG("IVHD Error: Invalid Device_Entry Length!\n");
         return 0;
     }
=20
-    bdf =3D ivhd_device->special.dev_id;
+    bdf =3D special->used_id;
     if ( bdf >=3D ivrs_bdf_entries )
     {
         AMD_IOMMU_DEBUG("IVHD Error: Invalid Device_Entry Dev_Id 0x%x\n", =
bdf);
         return 0;
     }
=20
-    add_ivrs_mapping_entry(bdf, bdf, ivhd_device->header.flags, iommu);
+    add_ivrs_mapping_entry(bdf, bdf, special->header.data_setting, =
iommu);
     /* set device id of ioapic */
-    ioapic_sbdf[ivhd_device->special.handle].bdf =3D bdf;
-    ioapic_sbdf[ivhd_device->special.handle].seg =3D seg;
+    ioapic_sbdf[special->handle].bdf =3D bdf;
+    ioapic_sbdf[special->handle].seg =3D seg;
     return dev_length;
 }
=20
-static int __init parse_ivhd_block(struct acpi_ivhd_block_header =
*ivhd_block)
+static int __init parse_ivhd_block(const struct acpi_ivrs_hardware =
*ivhd_block)
 {
-    union acpi_ivhd_device *ivhd_device;
+    const union acpi_ivhd_device *ivhd_device;
     u16 block_length, dev_length;
     struct amd_iommu *iommu;
=20
-    if ( ivhd_block->header.length <
-         sizeof(struct acpi_ivhd_block_header) )
+    if ( ivhd_block->header.length < sizeof(*ivhd_block) )
     {
         AMD_IOMMU_DEBUG("IVHD Error: Invalid Block Length!\n");
         return -ENODEV;
     }
=20
-    iommu =3D find_iommu_from_bdf_cap(ivhd_block->header.dev_id,
-                                    ivhd_block->cap_offset);
+    iommu =3D find_iommu_from_bdf_cap(ivhd_block->header.device_id,
+                                    ivhd_block->capability_offset);
     if ( !iommu )
     {
         AMD_IOMMU_DEBUG("IVHD Error: No IOMMU for Dev_Id 0x%x  Cap =
0x%x\n",
-                        ivhd_block->header.dev_id, ivhd_block->cap_offset)=
;
+                        ivhd_block->header.device_id,
+                        ivhd_block->capability_offset);
         return -ENODEV;
     }
=20
     /* parse Device Entries */
-    block_length =3D sizeof(struct acpi_ivhd_block_header);
+    block_length =3D sizeof(*ivhd_block);
     while ( ivhd_block->header.length >=3D
-            (block_length + sizeof(struct acpi_ivhd_device_header)) )
+            (block_length + sizeof(struct acpi_ivrs_de_header)) )
     {
-        ivhd_device =3D (union acpi_ivhd_device *)
-            ((u8 *)ivhd_block + block_length);
+        ivhd_device =3D (const void *)((const u8 *)ivhd_block + block_leng=
th);
=20
         AMD_IOMMU_DEBUG( "IVHD Device Entry:\n");
         AMD_IOMMU_DEBUG( " Type 0x%x\n", ivhd_device->header.type);
-        AMD_IOMMU_DEBUG( " Dev_Id 0x%x\n", ivhd_device->header.dev_id);
-        AMD_IOMMU_DEBUG( " Flags 0x%x\n", ivhd_device->header.flags);
+        AMD_IOMMU_DEBUG( " Dev_Id 0x%x\n", ivhd_device->header.id);
+        AMD_IOMMU_DEBUG( " Flags 0x%x\n", ivhd_device->header.data_setting=
);
=20
         switch ( ivhd_device->header.type )
         {
-        case AMD_IOMMU_ACPI_IVHD_DEV_U32_PAD:
+        case ACPI_IVRS_TYPE_PAD4:
             dev_length =3D parse_ivhd_device_padding(
                 sizeof(u32),
                 ivhd_block->header.length, block_length);
             break;
-        case AMD_IOMMU_ACPI_IVHD_DEV_U64_PAD:
+        case ACPI_IVRS_TYPE_PAD8:
             dev_length =3D parse_ivhd_device_padding(
                 sizeof(u64),
                 ivhd_block->header.length, block_length);
             break;
-        case AMD_IOMMU_ACPI_IVHD_DEV_SELECT:
-            dev_length =3D parse_ivhd_device_select(ivhd_device, iommu);
+        case ACPI_IVRS_TYPE_SELECT:
+            dev_length =3D parse_ivhd_device_select(&ivhd_device->select, =
iommu);
             break;
-        case AMD_IOMMU_ACPI_IVHD_DEV_RANGE_START:
+        case ACPI_IVRS_TYPE_START:
             dev_length =3D parse_ivhd_device_range(
-                ivhd_device,
+                &ivhd_device->range,
                 ivhd_block->header.length, block_length, iommu);
             break;
-        case AMD_IOMMU_ACPI_IVHD_DEV_ALIAS_SELECT:
+        case ACPI_IVRS_TYPE_ALIAS_SELECT:
             dev_length =3D parse_ivhd_device_alias(
-                ivhd_device,
+                &ivhd_device->alias,
                 ivhd_block->header.length, block_length, iommu);
             break;
-        case AMD_IOMMU_ACPI_IVHD_DEV_ALIAS_RANGE:
+        case ACPI_IVRS_TYPE_ALIAS_START:
             dev_length =3D parse_ivhd_device_alias_range(
-                ivhd_device,
+                &ivhd_device->alias_range,
                 ivhd_block->header.length, block_length, iommu);
             break;
-        case AMD_IOMMU_ACPI_IVHD_DEV_EXT_SELECT:
+        case ACPI_IVRS_TYPE_EXT_SELECT:
             dev_length =3D parse_ivhd_device_extended(
-                ivhd_device,
+                &ivhd_device->extended,
                 ivhd_block->header.length, block_length, iommu);
             break;
-        case AMD_IOMMU_ACPI_IVHD_DEV_EXT_RANGE:
+        case ACPI_IVRS_TYPE_EXT_START:
             dev_length =3D parse_ivhd_device_extended_range(
-                ivhd_device,
+                &ivhd_device->extended_range,
                 ivhd_block->header.length, block_length, iommu);
             break;
-        case AMD_IOMMU_ACPI_IVHD_DEV_SPECIAL:
+        case ACPI_IVRS_TYPE_SPECIAL:
             dev_length =3D parse_ivhd_device_special(
-                ivhd_device, ivhd_block->pci_segment,
+                &ivhd_device->special, ivhd_block->pci_segment_group,
                 ivhd_block->header.length, block_length, iommu);
             break;
         default:
@@ -730,22 +750,24 @@ static int __init parse_ivhd_block(struc
     return 0;
 }
=20
-static int __init parse_ivrs_block(struct acpi_ivrs_block_header =
*ivrs_block)
+static int __init parse_ivrs_block(const struct acpi_ivrs_header =
*ivrs_block)
 {
-    struct acpi_ivhd_block_header *ivhd_block;
-    struct acpi_ivmd_block_header *ivmd_block;
+    const struct acpi_ivrs_hardware *ivhd_block;
+    const struct acpi_ivrs_memory *ivmd_block;
=20
     switch ( ivrs_block->type )
     {
-    case AMD_IOMMU_ACPI_IVHD_TYPE:
-        ivhd_block =3D (struct acpi_ivhd_block_header *)ivrs_block;
+    case ACPI_IVRS_TYPE_HARDWARE:
+        ivhd_block =3D container_of(ivrs_block, const struct acpi_ivrs_har=
dware,
+                                  header);
         return parse_ivhd_block(ivhd_block);
=20
-    case AMD_IOMMU_ACPI_IVMD_ALL_TYPE:
-    case AMD_IOMMU_ACPI_IVMD_ONE_TYPE:
-    case AMD_IOMMU_ACPI_IVMD_RANGE_TYPE:
-    case AMD_IOMMU_ACPI_IVMD_IOMMU_TYPE:
-        ivmd_block =3D (struct acpi_ivmd_block_header *)ivrs_block;
+    case ACPI_IVRS_TYPE_MEMORY_ALL:
+    case ACPI_IVRS_TYPE_MEMORY_ONE:
+    case ACPI_IVRS_TYPE_MEMORY_RANGE:
+    case ACPI_IVRS_TYPE_MEMORY_IOMMU:
+        ivmd_block =3D container_of(ivrs_block, const struct acpi_ivrs_mem=
ory,
+                                  header);
         return parse_ivmd_block(ivmd_block);
=20
     default:
@@ -792,12 +814,11 @@ static void __init dump_acpi_table_heade
=20
 }
=20
-static int __init parse_ivrs_table(struct acpi_table_header *_table)
+static int __init parse_ivrs_table(struct acpi_table_header *table)
 {
-    struct acpi_ivrs_block_header *ivrs_block;
+    const struct acpi_ivrs_header *ivrs_block;
     unsigned long length;
     int error =3D 0;
-    struct acpi_table_header *table =3D (struct acpi_table_header =
*)_table;
=20
     BUG_ON(!table);
=20
@@ -805,17 +826,16 @@ static int __init parse_ivrs_table(struc
         dump_acpi_table_header(table);
=20
     /* parse IVRS blocks */
-    length =3D sizeof(struct acpi_ivrs_table_header);
+    length =3D sizeof(struct acpi_table_ivrs);
     while ( (error =3D=3D 0) && (table->length > (length + sizeof(*ivrs_bl=
ock))) )
     {
-        ivrs_block =3D (struct acpi_ivrs_block_header *)
-            ((u8 *)table + length);
+        ivrs_block =3D (struct acpi_ivrs_header *)((u8 *)table + length);
=20
         AMD_IOMMU_DEBUG("IVRS Block:\n");
         AMD_IOMMU_DEBUG(" Type 0x%x\n", ivrs_block->type);
         AMD_IOMMU_DEBUG(" Flags 0x%x\n", ivrs_block->flags);
         AMD_IOMMU_DEBUG(" Length 0x%x\n", ivrs_block->length);
-        AMD_IOMMU_DEBUG(" Dev_Id 0x%x\n", ivrs_block->dev_id);
+        AMD_IOMMU_DEBUG(" Dev_Id 0x%x\n", ivrs_block->device_id);
=20
         if ( table->length < (length + ivrs_block->length) )
         {
@@ -833,12 +853,11 @@ static int __init parse_ivrs_table(struc
     return error;
 }
=20
-static int __init detect_iommu_acpi(struct acpi_table_header *_table)
+static int __init detect_iommu_acpi(struct acpi_table_header *table)
 {
-    struct acpi_ivrs_block_header *ivrs_block;
-    struct acpi_table_header *table =3D (struct acpi_table_header =
*)_table;
+    const struct acpi_ivrs_header *ivrs_block;
     unsigned long i;
-    unsigned long length =3D sizeof(struct acpi_ivrs_table_header);
+    unsigned long length =3D sizeof(struct acpi_table_ivrs);
     u8 checksum, *raw_table;
=20
     /* validate checksum: sum of entire table =3D=3D 0 */
@@ -854,12 +873,14 @@ static int __init detect_iommu_acpi(stru
=20
     while ( table->length > (length + sizeof(*ivrs_block)) )
     {
-        ivrs_block =3D (struct acpi_ivrs_block_header *) ((u8 *)table + =
length);
+        ivrs_block =3D (struct acpi_ivrs_header *)((u8 *)table + length);
         if ( table->length < (length + ivrs_block->length) )
             return -ENODEV;
-        if ( ivrs_block->type =3D=3D AMD_IOMMU_ACPI_IVHD_TYPE )
-            if ( amd_iommu_detect_one_acpi((void*)ivrs_block) !=3D 0 )
-                return -ENODEV;
+        if ( ivrs_block->type =3D=3D ACPI_IVRS_TYPE_HARDWARE &&
+             amd_iommu_detect_one_acpi(
+                 container_of(ivrs_block, const struct acpi_ivrs_hardware,=

+                              header)) !=3D 0 )
+            return -ENODEV;
         length +=3D ivrs_block->length;
     }
     return 0;
@@ -870,63 +891,59 @@ static int __init detect_iommu_acpi(stru
        last_bdf =3D (x); \
    } while(0);
=20
-static int __init get_last_bdf_ivhd(void *ivhd)
+static int __init get_last_bdf_ivhd(
+    const struct acpi_ivrs_hardware *ivhd_block)
 {
-    union acpi_ivhd_device *ivhd_device;
+    const union acpi_ivhd_device *ivhd_device;
     u16 block_length, dev_length;
-    struct acpi_ivhd_block_header *ivhd_block;
-
-    ivhd_block =3D (struct acpi_ivhd_block_header *)ivhd;
=20
-    if ( ivhd_block->header.length <
-         sizeof(struct acpi_ivhd_block_header) )
+    if ( ivhd_block->header.length < sizeof(*ivhd_block) )
     {
         AMD_IOMMU_DEBUG("IVHD Error: Invalid Block Length!\n");
         return -ENODEV;
     }
=20
-    block_length =3D sizeof(struct acpi_ivhd_block_header);
+    block_length =3D sizeof(*ivhd_block);
     while ( ivhd_block->header.length >=3D
-            (block_length + sizeof(struct acpi_ivhd_device_header)) )
+            (block_length + sizeof(struct acpi_ivrs_de_header)) )
     {
-        ivhd_device =3D (union acpi_ivhd_device *)
-            ((u8 *)ivhd_block + block_length);
+        ivhd_device =3D (const void *)((u8 *)ivhd_block + block_length);
=20
         switch ( ivhd_device->header.type )
         {
-        case AMD_IOMMU_ACPI_IVHD_DEV_U32_PAD:
+        case ACPI_IVRS_TYPE_PAD4:
             dev_length =3D sizeof(u32);
             break;
-        case AMD_IOMMU_ACPI_IVHD_DEV_U64_PAD:
+        case ACPI_IVRS_TYPE_PAD8:
             dev_length =3D sizeof(u64);
             break;
-        case AMD_IOMMU_ACPI_IVHD_DEV_SELECT:
-            UPDATE_LAST_BDF(ivhd_device->header.dev_id);
-            dev_length =3D sizeof(struct acpi_ivhd_device_header);
-            break;
-        case AMD_IOMMU_ACPI_IVHD_DEV_ALIAS_SELECT:
-            UPDATE_LAST_BDF(ivhd_device->header.dev_id);
-            dev_length =3D sizeof(struct acpi_ivhd_device_alias);
-            break;
-        case AMD_IOMMU_ACPI_IVHD_DEV_EXT_SELECT:
-            UPDATE_LAST_BDF(ivhd_device->header.dev_id);
-            dev_length =3D sizeof(struct acpi_ivhd_device_extended);
-            break;
-        case AMD_IOMMU_ACPI_IVHD_DEV_RANGE_START:
-            UPDATE_LAST_BDF(ivhd_device->range.trailer.dev_id);
-            dev_length =3D sizeof(struct acpi_ivhd_device_range);
-            break;
-        case AMD_IOMMU_ACPI_IVHD_DEV_ALIAS_RANGE:
-            UPDATE_LAST_BDF(ivhd_device->alias_range.trailer.dev_id)
-            dev_length =3D sizeof(struct acpi_ivhd_device_alias_range);
-            break;
-        case AMD_IOMMU_ACPI_IVHD_DEV_EXT_RANGE:
-            UPDATE_LAST_BDF(ivhd_device->extended_range.trailer.dev_id)
-            dev_length =3D sizeof(struct acpi_ivhd_device_extended_range);=

-            break;
-        case AMD_IOMMU_ACPI_IVHD_DEV_SPECIAL:
-            UPDATE_LAST_BDF(ivhd_device->special.dev_id)
-            dev_length =3D sizeof(struct acpi_ivhd_device_special);
+        case ACPI_IVRS_TYPE_SELECT:
+            UPDATE_LAST_BDF(ivhd_device->select.header.id);
+            dev_length =3D sizeof(ivhd_device->header);
+            break;
+        case ACPI_IVRS_TYPE_ALIAS_SELECT:
+            UPDATE_LAST_BDF(ivhd_device->alias.header.id);
+            dev_length =3D sizeof(ivhd_device->alias);
+            break;
+        case ACPI_IVRS_TYPE_EXT_SELECT:
+            UPDATE_LAST_BDF(ivhd_device->extended.header.id);
+            dev_length =3D sizeof(ivhd_device->extended);
+            break;
+        case ACPI_IVRS_TYPE_START:
+            UPDATE_LAST_BDF(ivhd_device->range.end.header.id);
+            dev_length =3D sizeof(ivhd_device->range);
+            break;
+        case ACPI_IVRS_TYPE_ALIAS_START:
+            UPDATE_LAST_BDF(ivhd_device->alias_range.end.header.id)
+            dev_length =3D sizeof(ivhd_device->alias_range);
+            break;
+        case ACPI_IVRS_TYPE_EXT_START:
+            UPDATE_LAST_BDF(ivhd_device->extended_range.end.header.id)
+            dev_length =3D sizeof(ivhd_device->extended_range);
+            break;
+        case ACPI_IVRS_TYPE_SPECIAL:
+            UPDATE_LAST_BDF(ivhd_device->special.used_id)
+            dev_length =3D sizeof(ivhd_device->special);
             break;
         default:
             AMD_IOMMU_DEBUG("IVHD Error: Invalid Device Type!\n");
@@ -942,20 +959,21 @@ static int __init get_last_bdf_ivhd(void
     return 0;
 }
=20
-static int __init get_last_bdf_acpi(struct acpi_table_header *_table)
+static int __init get_last_bdf_acpi(struct acpi_table_header *table)
 {
-    struct acpi_ivrs_block_header *ivrs_block;
-    struct acpi_table_header *table =3D (struct acpi_table_header =
*)_table;
-    unsigned long length =3D sizeof(struct acpi_ivrs_table_header);
+    const struct acpi_ivrs_header *ivrs_block;
+    unsigned long length =3D sizeof(struct acpi_table_ivrs);
=20
     while ( table->length > (length + sizeof(*ivrs_block)) )
     {
-        ivrs_block =3D (struct acpi_ivrs_block_header *) ((u8 *)table + =
length);
+        ivrs_block =3D (struct acpi_ivrs_header *)((u8 *)table + length);
         if ( table->length < (length + ivrs_block->length) )
             return -ENODEV;
-        if ( ivrs_block->type =3D=3D AMD_IOMMU_ACPI_IVHD_TYPE )
-            if ( get_last_bdf_ivhd((void*)ivrs_block) !=3D 0 )
-                return -ENODEV;
+        if ( ivrs_block->type =3D=3D ACPI_IVRS_TYPE_HARDWARE &&
+             get_last_bdf_ivhd(
+                 container_of(ivrs_block, const struct acpi_ivrs_hardware,=

+                              header)) !=3D 0 )
+            return -ENODEV;
         length +=3D ivrs_block->length;
     }
    return 0;
@@ -963,16 +981,16 @@ static int __init get_last_bdf_acpi(stru
=20
 int __init amd_iommu_detect_acpi(void)
 {
-    return acpi_table_parse(AMD_IOMMU_ACPI_IVRS_SIG, detect_iommu_acpi);
+    return acpi_table_parse(ACPI_SIG_IVRS, detect_iommu_acpi);
 }
=20
 int __init amd_iommu_get_ivrs_dev_entries(void)
 {
-    acpi_table_parse(AMD_IOMMU_ACPI_IVRS_SIG, get_last_bdf_acpi);
+    acpi_table_parse(ACPI_SIG_IVRS, get_last_bdf_acpi);
     return last_bdf + 1;
 }
=20
 int __init amd_iommu_update_ivrs_mapping_acpi(void)
 {
-    return acpi_table_parse(AMD_IOMMU_ACPI_IVRS_SIG, parse_ivrs_table);
+    return acpi_table_parse(ACPI_SIG_IVRS, parse_ivrs_table);
 }
--- a/xen/drivers/passthrough/amd/iommu_detect.c
+++ b/xen/drivers/passthrough/amd/iommu_detect.c
@@ -20,12 +20,12 @@
=20
 #include <xen/config.h>
 #include <xen/errno.h>
+#include <xen/acpi.h>
 #include <xen/iommu.h>
 #include <xen/pci.h>
 #include <xen/pci_regs.h>
 #include <asm/amd-iommu.h>
 #include <asm/hvm/svm/amd-iommu-proto.h>
-#include <asm/hvm/svm/amd-iommu-acpi.h>
=20
 static int __init get_iommu_msi_capabilities(
     u16 seg, u8 bus, u8 dev, u8 func, struct amd_iommu *iommu)
@@ -103,23 +103,21 @@ void __init get_iommu_features(struct am
     }
 }
=20
-int __init amd_iommu_detect_one_acpi(void *ivhd)
+int __init amd_iommu_detect_one_acpi(
+    const struct acpi_ivrs_hardware *ivhd_block)
 {
     struct amd_iommu *iommu;
     u8 bus, dev, func;
-    struct acpi_ivhd_block_header *ivhd_block;
     int rt =3D 0;
=20
-    ivhd_block =3D (struct acpi_ivhd_block_header *)ivhd;
-
-    if ( ivhd_block->header.length < sizeof(struct acpi_ivhd_block_header)=
 )
+    if ( ivhd_block->header.length < sizeof(*ivhd_block) )
     {
         AMD_IOMMU_DEBUG("Invalid IVHD Block Length!\n");
         return -ENODEV;
     }
=20
-    if ( !ivhd_block->header.dev_id ||
-        !ivhd_block->cap_offset || !ivhd_block->mmio_base)
+    if ( !ivhd_block->header.device_id ||
+        !ivhd_block->capability_offset || !ivhd_block->base_address)
     {
         AMD_IOMMU_DEBUG("Invalid IVHD Block!\n");
         return -ENODEV;
@@ -134,10 +132,10 @@ int __init amd_iommu_detect_one_acpi(voi
=20
     spin_lock_init(&iommu->lock);
=20
-    iommu->seg =3D ivhd_block->pci_segment;
-    iommu->bdf =3D ivhd_block->header.dev_id;
-    iommu->cap_offset =3D ivhd_block->cap_offset;
-    iommu->mmio_base_phys =3D ivhd_block->mmio_base;
+    iommu->seg =3D ivhd_block->pci_segment_group;
+    iommu->bdf =3D ivhd_block->header.device_id;
+    iommu->cap_offset =3D ivhd_block->capability_offset;
+    iommu->mmio_base_phys =3D ivhd_block->base_address;
=20
     /* override IOMMU HT flags */
     iommu->ht_flags =3D ivhd_block->header.flags;
--- a/xen/drivers/passthrough/amd/iommu_init.c
+++ b/xen/drivers/passthrough/amd/iommu_init.c
@@ -20,6 +20,7 @@
=20
 #include <xen/config.h>
 #include <xen/errno.h>
+#include <xen/acpi.h>
 #include <xen/pci.h>
 #include <xen/pci_regs.h>
 #include <xen/irq.h>
@@ -28,7 +29,6 @@
 #include <asm/hvm/svm/amd-iommu-proto.h>
 #include <asm-x86/fixmap.h>
 #include <mach_apic.h>
-#include <asm/hvm/svm/amd-iommu-acpi.h>
=20
 static int __initdata nr_amd_iommus;
=20
@@ -37,9 +37,8 @@ static struct radix_tree_root ivrs_maps;
 struct list_head amd_iommu_head;
 struct table_struct device_table;
=20
-static int iommu_has_ht_flag(struct amd_iommu *iommu, uint8_t bit)
+static int iommu_has_ht_flag(struct amd_iommu *iommu, u8 mask)
 {
-    u8 mask =3D 1U << bit;
     return iommu->ht_flags & mask;
 }
=20
@@ -80,19 +79,19 @@ static void set_iommu_ht_flags(struct am
=20
     /* Setup HT flags */
     if ( iommu_has_cap(iommu, PCI_CAP_HT_TUNNEL_SHIFT) )
-        iommu_has_ht_flag(iommu, AMD_IOMMU_ACPI_HT_TUN_ENB_SHIFT) ?
+        iommu_has_ht_flag(iommu, ACPI_IVHD_TT_ENABLE) ?
             iommu_set_bit(&entry, IOMMU_CONTROL_HT_TUNNEL_TRANSLATION_SHIF=
T) :
             iommu_clear_bit(&entry, IOMMU_CONTROL_HT_TUNNEL_TRANSLATION_SH=
IFT);
=20
-    iommu_has_ht_flag(iommu, AMD_IOMMU_ACPI_RES_PASS_PW_SHIFT) ?
+    iommu_has_ht_flag(iommu, ACPI_IVHD_RES_PASS_PW) ?
         iommu_set_bit(&entry, IOMMU_CONTROL_RESP_PASS_POSTED_WRITE_SHIFT):=

         iommu_clear_bit(&entry, IOMMU_CONTROL_RESP_PASS_POSTED_WRITE_SHIFT=
);
=20
-    iommu_has_ht_flag(iommu, AMD_IOMMU_ACPI_ISOC_SHIFT) ?
+    iommu_has_ht_flag(iommu, ACPI_IVHD_ISOC) ?
         iommu_set_bit(&entry, IOMMU_CONTROL_ISOCHRONOUS_SHIFT):
         iommu_clear_bit(&entry, IOMMU_CONTROL_ISOCHRONOUS_SHIFT);
=20
-    iommu_has_ht_flag(iommu, AMD_IOMMU_ACPI_PASS_PW_SHIFT) ?
+    iommu_has_ht_flag(iommu, ACPI_IVHD_PASS_PW) ?
         iommu_set_bit(&entry, IOMMU_CONTROL_PASS_POSTED_WRITE_SHIFT):
         iommu_clear_bit(&entry, IOMMU_CONTROL_PASS_POSTED_WRITE_SHIFT);
=20
--- a/xen/drivers/passthrough/amd/iommu_map.c
+++ b/xen/drivers/passthrough/amd/iommu_map.c
@@ -18,12 +18,13 @@
  * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307 =
USA
  */
=20
+#include <xen/config.h>
+#include <xen/acpi.h>
 #include <xen/sched.h>
 #include <asm/p2m.h>
 #include <xen/hvm/iommu.h>
 #include <asm/amd-iommu.h>
 #include <asm/hvm/svm/amd-iommu-proto.h>
-#include <asm/hvm/svm/amd-iommu-acpi.h>
 #include "../ats.h"
 #include <xen/pci.h>
=20
@@ -215,8 +216,7 @@ void __init iommu_dte_add_device_entry(u
     dte[7] =3D dte[6] =3D dte[4] =3D dte[2] =3D dte[1] =3D dte[0] =3D 0;
=20
     flags =3D ivrs_dev->device_flags;
-    sys_mgt =3D get_field_from_byte(flags, AMD_IOMMU_ACPI_SYS_MGT_MASK,
-                                  AMD_IOMMU_ACPI_SYS_MGT_SHIFT);
+    sys_mgt =3D get_field_from_byte(flags, ACPI_IVHD_SYSTEM_MGMT);
     dev_ex =3D ivrs_dev->dte_allow_exclusion;
=20
     flags &=3D mask;
--- a/xen/include/asm-x86/hvm/svm/amd-iommu-acpi.h
+++ /dev/null
@@ -1,185 +0,0 @@
-/*
- * Copyright (C) 2007 Advanced Micro Devices, Inc.
- * Author: Leo Duran <leo.duran@amd.com>
- * Author: Wei Wang <wei.wang2@amd.com> - adapted to xen
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307 =
USA
- */
-
-#ifndef _ASM_X86_64_AMD_IOMMU_ACPI_H
-#define _ASM_X86_64_AMD_IOMMU_ACPI_H
-
-#include <xen/acpi.h>
-
-/* I/O Virtualization Reporting Structure */
-#define AMD_IOMMU_ACPI_IVRS_SIG            "IVRS"
-#define AMD_IOMMU_ACPI_IVHD_TYPE       0x10
-#define AMD_IOMMU_ACPI_IVMD_ALL_TYPE       0x20
-#define AMD_IOMMU_ACPI_IVMD_ONE_TYPE       0x21
-#define AMD_IOMMU_ACPI_IVMD_RANGE_TYPE     0x22
-#define AMD_IOMMU_ACPI_IVMD_IOMMU_TYPE     0x23
-
-/* 4-byte Device Entries */
-#define AMD_IOMMU_ACPI_IVHD_DEV_U32_PAD        0
-#define AMD_IOMMU_ACPI_IVHD_DEV_SELECT     2
-#define AMD_IOMMU_ACPI_IVHD_DEV_RANGE_START    3
-#define AMD_IOMMU_ACPI_IVHD_DEV_RANGE_END  4
-
-/* 8-byte Device Entries */
-#define AMD_IOMMU_ACPI_IVHD_DEV_U64_PAD        64
-#define AMD_IOMMU_ACPI_IVHD_DEV_ALIAS_SELECT   66
-#define AMD_IOMMU_ACPI_IVHD_DEV_ALIAS_RANGE    67
-#define AMD_IOMMU_ACPI_IVHD_DEV_EXT_SELECT 70
-#define AMD_IOMMU_ACPI_IVHD_DEV_EXT_RANGE  71
-#define AMD_IOMMU_ACPI_IVHD_DEV_SPECIAL    72
-
-/* IVHD IOMMU Flags */
-#define AMD_IOMMU_ACPI_COHERENT_MASK       0x20
-#define AMD_IOMMU_ACPI_COHERENT_SHIFT      5
-#define AMD_IOMMU_ACPI_IOTLB_SUP_MASK      0x10
-#define AMD_IOMMU_ACPI_IOTLB_SUP_SHIFT     4
-#define AMD_IOMMU_ACPI_ISOC_MASK       0x08
-#define AMD_IOMMU_ACPI_ISOC_SHIFT      3
-#define AMD_IOMMU_ACPI_RES_PASS_PW_MASK        0x04
-#define AMD_IOMMU_ACPI_RES_PASS_PW_SHIFT   2
-#define AMD_IOMMU_ACPI_PASS_PW_MASK        0x02
-#define AMD_IOMMU_ACPI_PASS_PW_SHIFT       1
-#define AMD_IOMMU_ACPI_HT_TUN_ENB_MASK     0x01
-#define AMD_IOMMU_ACPI_HT_TUN_ENB_SHIFT        0
-
-/* IVHD Device Flags */
-#define AMD_IOMMU_ACPI_LINT1_PASS_MASK     0x80
-#define AMD_IOMMU_ACPI_LINT1_PASS_SHIFT        7
-#define AMD_IOMMU_ACPI_LINT0_PASS_MASK     0x40
-#define AMD_IOMMU_ACPI_LINT0_PASS_SHIFT        6
-#define AMD_IOMMU_ACPI_SYS_MGT_MASK        0x30
-#define AMD_IOMMU_ACPI_SYS_MGT_SHIFT       4
-#define AMD_IOMMU_ACPI_NMI_PASS_MASK       0x04
-#define AMD_IOMMU_ACPI_NMI_PASS_SHIFT      2
-#define AMD_IOMMU_ACPI_EINT_PASS_MASK      0x02
-#define AMD_IOMMU_ACPI_EINT_PASS_SHIFT     1
-#define AMD_IOMMU_ACPI_INIT_PASS_MASK      0x01
-#define AMD_IOMMU_ACPI_INIT_PASS_SHIFT     0
-
-/* IVHD Device Extended Flags */
-#define AMD_IOMMU_ACPI_ATS_DISABLED_MASK   0x80000000
-#define AMD_IOMMU_ACPI_ATS_DISABLED_SHIFT  31
-
-/* IVMD Device Flags */
-#define AMD_IOMMU_ACPI_EXCLUSION_RANGE_MASK    0x08
-#define AMD_IOMMU_ACPI_EXCLUSION_RANGE_SHIFT   3
-#define AMD_IOMMU_ACPI_IW_PERMISSION_MASK  0x04
-#define AMD_IOMMU_ACPI_IW_PERMISSION_SHIFT 2
-#define AMD_IOMMU_ACPI_IR_PERMISSION_MASK  0x02
-#define AMD_IOMMU_ACPI_IR_PERMISSION_SHIFT 1
-#define AMD_IOMMU_ACPI_UNITY_MAPPING_MASK  0x01
-#define AMD_IOMMU_ACPI_UNITY_MAPPING_SHIFT 0
-
-#define ACPI_OEM_ID_SIZE                6
-#define ACPI_OEM_TABLE_ID_SIZE          8
-
-#pragma pack(1)
-struct acpi_ivrs_table_header {
-   struct acpi_table_header acpi_header;
-   u32 io_info;
-   u8  reserved[8];
-};
-
-struct acpi_ivrs_block_header {
-   u8  type;
-   u8  flags;
-   u16 length;
-   u16 dev_id;
-};
-
-struct acpi_ivhd_block_header {
-   struct acpi_ivrs_block_header header;
-   u16 cap_offset;
-   u64 mmio_base;
-   u16 pci_segment;
-   u16 iommu_info;
-   u8 reserved[4];
-};
-
-struct acpi_ivhd_device_header {
-   u8  type;
-   u16 dev_id;
-   u8  flags;
-};
-
-struct acpi_ivhd_device_trailer {
-   u8  type;
-   u16 dev_id;
-   u8  reserved;
-};
-
-struct acpi_ivhd_device_range {
-   struct acpi_ivhd_device_header header;
-   struct acpi_ivhd_device_trailer trailer;
-};
-
-struct acpi_ivhd_device_alias {
-   struct acpi_ivhd_device_header header;
-   u8  reserved1;
-   u16 dev_id;
-   u8  reserved2;
-};
-
-struct acpi_ivhd_device_alias_range {
-   struct acpi_ivhd_device_alias alias;
-   struct acpi_ivhd_device_trailer trailer;
-};
-
-struct acpi_ivhd_device_extended {
-   struct acpi_ivhd_device_header header;
-   u32 ext_flags;
-};
-
-struct acpi_ivhd_device_extended_range {
-   struct acpi_ivhd_device_extended extended;
-   struct acpi_ivhd_device_trailer trailer;
-};
-
-struct acpi_ivhd_device_special {
-   struct acpi_ivhd_device_header header;
-   u8  handle;
-   u16 dev_id;
-   u8  variety;
-};
-
-union acpi_ivhd_device {
-   struct acpi_ivhd_device_header header;
-   struct acpi_ivhd_device_range range;
-   struct acpi_ivhd_device_alias alias;
-   struct acpi_ivhd_device_alias_range alias_range;
-   struct acpi_ivhd_device_extended extended;
-   struct acpi_ivhd_device_extended_range extended_range;
-   struct acpi_ivhd_device_special special;
-};
-
-struct acpi_ivmd_block_header {
-   struct acpi_ivrs_block_header header;
-   union {
-       u16 last_dev_id;
-       u16 cap_offset;
-       u16 reserved1;
-   };
-   u64 reserved2;
-   u64 start_addr;
-   u64 mem_length;
-};
-#pragma pack()
-
-#endif /* _ASM_X86_64_AMD_IOMMU_ACPI_H */
--- a/xen/include/asm-x86/hvm/svm/amd-iommu-proto.h
+++ b/xen/include/asm-x86/hvm/svm/amd-iommu-proto.h
@@ -26,6 +26,8 @@
 #include <asm/apicdef.h>
 #include <xen/domain_page.h>
=20
+struct acpi_ivrs_hardware;
+
 #define for_each_amd_iommu(amd_iommu) \
     list_for_each_entry(amd_iommu, \
         &amd_iommu_head, list)
@@ -41,7 +43,7 @@
=20
 /* amd-iommu-detect functions */
 int amd_iommu_get_ivrs_dev_entries(void);
-int amd_iommu_detect_one_acpi(void *ivhd);
+int amd_iommu_detect_one_acpi(const struct acpi_ivrs_hardware *);
 int amd_iommu_detect_acpi(void);
 void get_iommu_features(struct amd_iommu *iommu);
=20
@@ -121,11 +123,9 @@ static inline u32 set_field_in_reg_u32(u
     return reg_value;
 }
=20
-static inline u8 get_field_from_byte(u8 value, u8 mask, u8 shift)
+static inline u8 get_field_from_byte(u8 value, u8 mask)
 {
-    u8 field;
-    field =3D (value & mask) >> shift;
-    return field;
+    return (value & mask) / (mask & -mask);
 }
=20
 static inline unsigned long region_to_pages(unsigned long addr, unsigned =
long size)



--=__Part456AE0A2.0__=
Content-Type: text/plain; name="acpi-duplicate-ivrs-structs.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="acpi-duplicate-ivrs-structs.patch"

ACPI: eliminate duplicate IVRS definitions=0A=0AUse their proper counterpar=
ts in include/acpi/actbl*.h instead.=0A=0ASigned-off-by: Jan Beulich =
<jbeulich@suse.com>=0A=0A--- a/xen/drivers/passthrough/amd/iommu_acpi.c=0A+=
++ b/xen/drivers/passthrough/amd/iommu_acpi.c=0A@@ -20,10 +20,38 @@=0A =0A =
#include <xen/config.h>=0A #include <xen/errno.h>=0A+#include <xen/acpi.h>=
=0A #include <asm/apicdef.h>=0A #include <asm/amd-iommu.h>=0A #include =
<asm/hvm/svm/amd-iommu-proto.h>=0A-#include <asm/hvm/svm/amd-iommu-acpi.h>=
=0A+=0A+/* Some helper structures, particularly to deal with ranges. =
*/=0A+=0A+struct acpi_ivhd_device_range {=0A+   struct acpi_ivrs_device4 =
start;=0A+   struct acpi_ivrs_device4 end;=0A+};=0A+=0A+struct acpi_ivhd_de=
vice_alias_range {=0A+   struct acpi_ivrs_device8a alias;=0A+   struct =
acpi_ivrs_device4 end;=0A+};=0A+=0A+struct acpi_ivhd_device_extended_range =
{=0A+   struct acpi_ivrs_device8b extended;=0A+   struct acpi_ivrs_device4 =
end;=0A+};=0A+=0A+union acpi_ivhd_device {=0A+   struct acpi_ivrs_de_header=
 header;=0A+   struct acpi_ivrs_device4 select;=0A+   struct acpi_ivhd_devi=
ce_range range;=0A+   struct acpi_ivrs_device8a alias;=0A+   struct =
acpi_ivhd_device_alias_range alias_range;=0A+   struct acpi_ivrs_device8b =
extended;=0A+   struct acpi_ivhd_device_extended_range extended_range;=0A+ =
  struct acpi_ivrs_device8c special;=0A+};=0A =0A static unsigned short =
__initdata last_bdf;=0A =0A@@ -242,12 +270,12 @@ static int __init =
register_exclusion_ran=0A }=0A =0A static int __init parse_ivmd_device_sele=
ct(=0A-    struct acpi_ivmd_block_header *ivmd_block,=0A+    const struct =
acpi_ivrs_memory *ivmd_block,=0A     unsigned long base, unsigned long =
limit, u8 iw, u8 ir)=0A {=0A     u16 bdf;=0A =0A-    bdf =3D ivmd_block->he=
ader.dev_id;=0A+    bdf =3D ivmd_block->header.device_id;=0A     if ( bdf =
>=3D ivrs_bdf_entries )=0A     {=0A         AMD_IOMMU_DEBUG("IVMD Error: =
Invalid Dev_Id 0x%x\n", bdf);=0A@@ -258,13 +286,13 @@ static int __init =
parse_ivmd_device_sele=0A }=0A =0A static int __init parse_ivmd_device_rang=
e(=0A-    struct acpi_ivmd_block_header *ivmd_block,=0A+    const struct =
acpi_ivrs_memory *ivmd_block,=0A     unsigned long base, unsigned long =
limit, u8 iw, u8 ir)=0A {=0A     u16 first_bdf, last_bdf, bdf;=0A     int =
error;=0A =0A-    first_bdf =3D ivmd_block->header.dev_id;=0A+    =
first_bdf =3D ivmd_block->header.device_id;=0A     if ( first_bdf >=3D =
ivrs_bdf_entries )=0A     {=0A         AMD_IOMMU_DEBUG("IVMD Error: "=0A@@ =
-272,7 +300,7 @@ static int __init parse_ivmd_device_rang=0A         =
return -ENODEV;=0A     }=0A =0A-    last_bdf =3D ivmd_block->last_dev_id;=
=0A+    last_bdf =3D ivmd_block->aux_data;=0A     if ( (last_bdf >=3D =
ivrs_bdf_entries) || (last_bdf <=3D first_bdf) )=0A     {=0A         =
AMD_IOMMU_DEBUG("IVMD Error: "=0A@@ -288,18 +316,18 @@ static int __init =
parse_ivmd_device_rang=0A }=0A =0A static int __init parse_ivmd_device_iomm=
u(=0A-    struct acpi_ivmd_block_header *ivmd_block,=0A+    const struct =
acpi_ivrs_memory *ivmd_block,=0A     unsigned long base, unsigned long =
limit, u8 iw, u8 ir)=0A {=0A     struct amd_iommu *iommu;=0A =0A     /* =
find target IOMMU */=0A-    iommu =3D find_iommu_from_bdf_cap(ivmd_block->h=
eader.dev_id,=0A-                                    ivmd_block->cap_offset=
);=0A+    iommu =3D find_iommu_from_bdf_cap(ivmd_block->header.device_id,=
=0A+                                    ivmd_block->aux_data);=0A     if ( =
!iommu )=0A     {=0A         AMD_IOMMU_DEBUG("IVMD Error: No IOMMU for =
Dev_Id 0x%x  Cap 0x%x\n",=0A-                        ivmd_block->header.dev=
_id, ivmd_block->cap_offset);=0A+                        ivmd_block->header=
.device_id, ivmd_block->aux_data);=0A         return -ENODEV;=0A     }=0A =
=0A@@ -307,20 +335,19 @@ static int __init parse_ivmd_device_iomm=0A       =
  iommu, base, limit, iw, ir);=0A }=0A =0A-static int __init parse_ivmd_blo=
ck(struct acpi_ivmd_block_header *ivmd_block)=0A+static int __init =
parse_ivmd_block(const struct acpi_ivrs_memory *ivmd_block)=0A {=0A     =
unsigned long start_addr, mem_length, base, limit;=0A     u8 iw, ir;=0A =
=0A-    if ( ivmd_block->header.length <=0A-         sizeof(struct =
acpi_ivmd_block_header) )=0A+    if ( ivmd_block->header.length < =
sizeof(*ivmd_block) )=0A     {=0A         AMD_IOMMU_DEBUG("IVMD Error: =
Invalid Block Length!\n");=0A         return -ENODEV;=0A     }=0A =0A-    =
start_addr =3D (unsigned long)ivmd_block->start_addr;=0A-    mem_length =
=3D (unsigned long)ivmd_block->mem_length;=0A+    start_addr =3D (unsigned =
long)ivmd_block->start_address;=0A+    mem_length =3D (unsigned long)ivmd_b=
lock->memory_length;=0A     base =3D start_addr & PAGE_MASK;=0A     limit =
=3D (start_addr + mem_length - 1) & PAGE_MASK;=0A =0A@@ -328,20 +355,14 @@ =
static int __init parse_ivmd_block(struc=0A     AMD_IOMMU_DEBUG(" =
Start_Addr_Phys 0x%lx\n", start_addr);=0A     AMD_IOMMU_DEBUG(" Mem_Length =
0x%lx\n", mem_length);=0A =0A-    if ( get_field_from_byte(ivmd_block->head=
er.flags,=0A-                             AMD_IOMMU_ACPI_EXCLUSION_RANGE_MA=
SK,=0A-                             AMD_IOMMU_ACPI_EXCLUSION_RANGE_SHIFT) =
)=0A+    if ( ivmd_block->header.flags & ACPI_IVMD_EXCLUSION_RANGE )=0A    =
     iw =3D ir =3D IOMMU_CONTROL_ENABLED;=0A-    else if ( get_field_from_b=
yte(ivmd_block->header.flags,=0A-                                  =
AMD_IOMMU_ACPI_UNITY_MAPPING_MASK,=0A-                                  =
AMD_IOMMU_ACPI_UNITY_MAPPING_SHIFT) )=0A-    {=0A-        iw =3D get_field_=
from_byte(ivmd_block->header.flags,=0A-                                 =
AMD_IOMMU_ACPI_IW_PERMISSION_MASK,=0A-                                 =
AMD_IOMMU_ACPI_IW_PERMISSION_SHIFT);=0A-        ir =3D get_field_from_byte(=
ivmd_block->header.flags,=0A-                                 AMD_IOMMU_ACP=
I_IR_PERMISSION_MASK,=0A-                                 AMD_IOMMU_ACPI_IR=
_PERMISSION_SHIFT);=0A+    else if ( ivmd_block->header.flags & ACPI_IVMD_U=
NITY )=0A+    {=0A+        iw =3D ivmd_block->header.flags & ACPI_IVMD_READ=
 ?=0A+            IOMMU_CONTROL_ENABLED : IOMMU_CONTROL_DISABLED;=0A+      =
  ir =3D ivmd_block->header.flags & ACPI_IVMD_WRITE ?=0A+            =
IOMMU_CONTROL_ENABLED : IOMMU_CONTROL_DISABLED;=0A     }=0A     else=0A    =
 {=0A@@ -351,19 +372,19 @@ static int __init parse_ivmd_block(struc=0A =0A =
    switch( ivmd_block->header.type )=0A     {=0A-    case AMD_IOMMU_ACPI_I=
VMD_ALL_TYPE:=0A+    case ACPI_IVRS_TYPE_MEMORY_ALL:=0A         return =
register_exclusion_range_for_all_devices(=0A             base, limit, iw, =
ir);=0A =0A-    case AMD_IOMMU_ACPI_IVMD_ONE_TYPE:=0A+    case ACPI_IVRS_TY=
PE_MEMORY_ONE:=0A         return parse_ivmd_device_select(ivmd_block,=0A   =
                                      base, limit, iw, ir);=0A =0A-    =
case AMD_IOMMU_ACPI_IVMD_RANGE_TYPE:=0A+    case ACPI_IVRS_TYPE_MEMORY_RANG=
E:=0A         return parse_ivmd_device_range(ivmd_block,=0A                =
                        base, limit, iw, ir);=0A =0A-    case AMD_IOMMU_ACP=
I_IVMD_IOMMU_TYPE:=0A+    case ACPI_IVRS_TYPE_MEMORY_IOMMU:=0A         =
return parse_ivmd_device_iommu(ivmd_block,=0A                              =
          base, limit, iw, ir);=0A =0A@@ -386,45 +407,44 @@ static u16 =
__init parse_ivhd_device_padd=0A }=0A =0A static u16 __init parse_ivhd_devi=
ce_select(=0A-    union acpi_ivhd_device *ivhd_device, struct amd_iommu =
*iommu)=0A+    const struct acpi_ivrs_device4 *select, struct amd_iommu =
*iommu)=0A {=0A     u16 bdf;=0A =0A-    bdf =3D ivhd_device->header.dev_id;=
=0A+    bdf =3D select->header.id;=0A     if ( bdf >=3D ivrs_bdf_entries =
)=0A     {=0A         AMD_IOMMU_DEBUG("IVHD Error: Invalid Device_Entry =
Dev_Id 0x%x\n", bdf);=0A         return 0;=0A     }=0A =0A-    add_ivrs_map=
ping_entry(bdf, bdf, ivhd_device->header.flags, iommu);=0A+    add_ivrs_map=
ping_entry(bdf, bdf, select->header.data_setting, iommu);=0A =0A-    =
return sizeof(struct acpi_ivhd_device_header);=0A+    return sizeof(*select=
);=0A }=0A =0A static u16 __init parse_ivhd_device_range(=0A-    union =
acpi_ivhd_device *ivhd_device,=0A+    const struct acpi_ivhd_device_range =
*range,=0A     u16 header_length, u16 block_length, struct amd_iommu =
*iommu)=0A {=0A     u16 dev_length, first_bdf, last_bdf, bdf;=0A =0A-    =
dev_length =3D sizeof(struct acpi_ivhd_device_range);=0A+    dev_length =
=3D sizeof(*range);=0A     if ( header_length < (block_length + dev_length)=
 )=0A     {=0A         AMD_IOMMU_DEBUG("IVHD Error: Invalid Device_Entry =
Length!\n");=0A         return 0;=0A     }=0A =0A-    if ( ivhd_device->ran=
ge.trailer.type !=3D=0A-         AMD_IOMMU_ACPI_IVHD_DEV_RANGE_END )=0A+   =
 if ( range->end.header.type !=3D ACPI_IVRS_TYPE_END )=0A     {=0A         =
AMD_IOMMU_DEBUG("IVHD Error: "=0A                         "Invalid Range: =
End_Type 0x%x\n",=0A-                        ivhd_device->range.trailer.typ=
e);=0A+                        range->end.header.type);=0A         return =
0;=0A     }=0A =0A-    first_bdf =3D ivhd_device->header.dev_id;=0A+    =
first_bdf =3D range->start.header.id;=0A     if ( first_bdf >=3D ivrs_bdf_e=
ntries )=0A     {=0A         AMD_IOMMU_DEBUG("IVHD Error: "=0A@@ -432,7 =
+452,7 @@ static u16 __init parse_ivhd_device_rang=0A         return 0;=0A =
    }=0A =0A-    last_bdf =3D ivhd_device->range.trailer.dev_id;=0A+    =
last_bdf =3D range->end.header.id;=0A     if ( (last_bdf >=3D ivrs_bdf_entr=
ies) || (last_bdf <=3D first_bdf) )=0A     {=0A         AMD_IOMMU_DEBUG("IV=
HD Error: "=0A@@ -443,32 +463,33 @@ static u16 __init parse_ivhd_device_ran=
g=0A     AMD_IOMMU_DEBUG(" Dev_Id Range: 0x%x -> 0x%x\n", first_bdf, =
last_bdf);=0A =0A     for ( bdf =3D first_bdf; bdf <=3D last_bdf; bdf++ =
)=0A-        add_ivrs_mapping_entry(bdf, bdf, ivhd_device->header.flags, =
iommu);=0A+        add_ivrs_mapping_entry(bdf, bdf, range->start.header.dat=
a_setting,=0A+                               iommu);=0A =0A     return =
dev_length;=0A }=0A =0A static u16 __init parse_ivhd_device_alias(=0A-    =
union acpi_ivhd_device *ivhd_device,=0A+    const struct acpi_ivrs_device8a=
 *alias,=0A     u16 header_length, u16 block_length, struct amd_iommu =
*iommu)=0A {=0A     u16 dev_length, alias_id, bdf;=0A =0A-    dev_length =
=3D sizeof(struct acpi_ivhd_device_alias);=0A+    dev_length =3D sizeof(*al=
ias);=0A     if ( header_length < (block_length + dev_length) )=0A     =
{=0A         AMD_IOMMU_DEBUG("IVHD Error: Invalid Device_Entry Length!\n");=
=0A         return 0;=0A     }=0A =0A-    bdf =3D ivhd_device->header.dev_i=
d;=0A+    bdf =3D alias->header.id;=0A     if ( bdf >=3D ivrs_bdf_entries =
)=0A     {=0A         AMD_IOMMU_DEBUG("IVHD Error: Invalid Device_Entry =
Dev_Id 0x%x\n", bdf);=0A         return 0;=0A     }=0A =0A-    alias_id =
=3D ivhd_device->alias.dev_id;=0A+    alias_id =3D alias->used_id;=0A     =
if ( alias_id >=3D ivrs_bdf_entries )=0A     {=0A         AMD_IOMMU_DEBUG("=
IVHD Error: Invalid Alias Dev_Id 0x%x\n", alias_id);=0A@@ -477,35 +498,34 =
@@ static u16 __init parse_ivhd_device_alia=0A =0A     AMD_IOMMU_DEBUG(" =
Dev_Id Alias: 0x%x\n", alias_id);=0A =0A-    add_ivrs_mapping_entry(bdf, =
alias_id, ivhd_device->header.flags, iommu);=0A+    add_ivrs_mapping_entry(=
bdf, alias_id, alias->header.data_setting, iommu);=0A =0A     return =
dev_length;=0A }=0A =0A static u16 __init parse_ivhd_device_alias_range(=0A=
-    union acpi_ivhd_device *ivhd_device,=0A+    const struct acpi_ivhd_dev=
ice_alias_range *range,=0A     u16 header_length, u16 block_length, struct =
amd_iommu *iommu)=0A {=0A =0A     u16 dev_length, first_bdf, last_bdf, =
alias_id, bdf;=0A =0A-    dev_length =3D sizeof(struct acpi_ivhd_device_ali=
as_range);=0A+    dev_length =3D sizeof(*range);=0A     if ( header_length =
< (block_length + dev_length) )=0A     {=0A         AMD_IOMMU_DEBUG("IVHD =
Error: Invalid Device_Entry Length!\n");=0A         return 0;=0A     }=0A =
=0A-    if ( ivhd_device->alias_range.trailer.type !=3D=0A-         =
AMD_IOMMU_ACPI_IVHD_DEV_RANGE_END )=0A+    if ( range->end.header.type =
!=3D ACPI_IVRS_TYPE_END )=0A     {=0A         AMD_IOMMU_DEBUG("IVHD Error: =
"=0A                         "Invalid Range: End_Type 0x%x\n",=0A-         =
               ivhd_device->alias_range.trailer.type);=0A+                 =
       range->end.header.type);=0A         return 0;=0A     }=0A =0A-    =
first_bdf =3D ivhd_device->header.dev_id;=0A+    first_bdf =3D range->alias=
.header.id;=0A     if ( first_bdf >=3D ivrs_bdf_entries )=0A     {=0A      =
   AMD_IOMMU_DEBUG("IVHD Error: "=0A@@ -513,7 +533,7 @@ static u16 __init =
parse_ivhd_device_alia=0A         return 0;=0A     }=0A =0A-    last_bdf =
=3D ivhd_device->alias_range.trailer.dev_id;=0A+    last_bdf =3D range->end=
.header.id;=0A     if ( last_bdf >=3D ivrs_bdf_entries || last_bdf <=3D =
first_bdf )=0A     {=0A         AMD_IOMMU_DEBUG(=0A@@ -521,7 +541,7 @@ =
static u16 __init parse_ivhd_device_alia=0A         return 0;=0A     }=0A =
=0A-    alias_id =3D ivhd_device->alias_range.alias.dev_id;=0A+    =
alias_id =3D range->alias.used_id;=0A     if ( alias_id >=3D ivrs_bdf_entri=
es )=0A     {=0A         AMD_IOMMU_DEBUG("IVHD Error: Invalid Alias Dev_Id =
0x%x\n", alias_id);=0A@@ -532,59 +552,59 @@ static u16 __init parse_ivhd_de=
vice_alia=0A     AMD_IOMMU_DEBUG(" Dev_Id Alias: 0x%x\n", alias_id);=0A =
=0A     for ( bdf =3D first_bdf; bdf <=3D last_bdf; bdf++ )=0A-        =
add_ivrs_mapping_entry(bdf, alias_id, ivhd_device->header.flags, iommu);=0A=
+        add_ivrs_mapping_entry(bdf, alias_id, range->alias.header.data_set=
ting,=0A+                               iommu);=0A =0A     return =
dev_length;=0A }=0A =0A static u16 __init parse_ivhd_device_extended(=0A-  =
  union acpi_ivhd_device *ivhd_device,=0A+    const struct acpi_ivrs_device=
8b *ext,=0A     u16 header_length, u16 block_length, struct amd_iommu =
*iommu)=0A {=0A     u16 dev_length, bdf;=0A =0A-    dev_length =3D =
sizeof(struct acpi_ivhd_device_extended);=0A+    dev_length =3D sizeof(*ext=
);=0A     if ( header_length < (block_length + dev_length) )=0A     {=0A   =
      AMD_IOMMU_DEBUG("IVHD Error: Invalid Device_Entry Length!\n");=0A    =
     return 0;=0A     }=0A =0A-    bdf =3D ivhd_device->header.dev_id;=0A+ =
   bdf =3D ext->header.id;=0A     if ( bdf >=3D ivrs_bdf_entries )=0A     =
{=0A         AMD_IOMMU_DEBUG("IVHD Error: Invalid Device_Entry Dev_Id =
0x%x\n", bdf);=0A         return 0;=0A     }=0A =0A-    add_ivrs_mapping_en=
try(bdf, bdf, ivhd_device->header.flags, iommu);=0A+    add_ivrs_mapping_en=
try(bdf, bdf, ext->header.data_setting, iommu);=0A =0A     return =
dev_length;=0A }=0A =0A static u16 __init parse_ivhd_device_extended_range(=
=0A-    union acpi_ivhd_device *ivhd_device,=0A+    const struct acpi_ivhd_=
device_extended_range *range,=0A     u16 header_length, u16 block_length, =
struct amd_iommu *iommu)=0A {=0A     u16 dev_length, first_bdf, last_bdf, =
bdf;=0A =0A-    dev_length =3D sizeof(struct acpi_ivhd_device_extended_rang=
e);=0A+    dev_length =3D sizeof(*range);=0A     if ( header_length < =
(block_length + dev_length) )=0A     {=0A         AMD_IOMMU_DEBUG("IVHD =
Error: Invalid Device_Entry Length!\n");=0A         return 0;=0A     }=0A =
=0A-    if ( ivhd_device->extended_range.trailer.type !=3D=0A-         =
AMD_IOMMU_ACPI_IVHD_DEV_RANGE_END )=0A+    if ( range->end.header.type =
!=3D ACPI_IVRS_TYPE_END )=0A     {=0A         AMD_IOMMU_DEBUG("IVHD Error: =
"=0A                         "Invalid Range: End_Type 0x%x\n",=0A-         =
               ivhd_device->extended_range.trailer.type);=0A+              =
          range->end.header.type);=0A         return 0;=0A     }=0A =0A-   =
 first_bdf =3D ivhd_device->header.dev_id;=0A+    first_bdf =3D range->exte=
nded.header.id;=0A     if ( first_bdf >=3D ivrs_bdf_entries )=0A     {=0A  =
       AMD_IOMMU_DEBUG("IVHD Error: "=0A@@ -592,7 +612,7 @@ static u16 =
__init parse_ivhd_device_exte=0A         return 0;=0A     }=0A =0A-    =
last_bdf =3D ivhd_device->extended_range.trailer.dev_id;=0A+    last_bdf =
=3D range->end.header.id;=0A     if ( (last_bdf >=3D ivrs_bdf_entries) || =
(last_bdf <=3D first_bdf) )=0A     {=0A         AMD_IOMMU_DEBUG("IVHD =
Error: "=0A@@ -604,116 +624,116 @@ static u16 __init parse_ivhd_device_exte=
=0A                     first_bdf, last_bdf);=0A =0A     for ( bdf =3D =
first_bdf; bdf <=3D last_bdf; bdf++ )=0A-        add_ivrs_mapping_entry(bdf=
, bdf, ivhd_device->header.flags, iommu);=0A+        add_ivrs_mapping_entry=
(bdf, bdf, range->extended.header.data_setting,=0A+                        =
       iommu);=0A =0A     return dev_length;=0A }=0A =0A static u16 __init =
parse_ivhd_device_special(=0A-    union acpi_ivhd_device *ivhd_device, u16 =
seg,=0A+    const struct acpi_ivrs_device8c *special, u16 seg,=0A     u16 =
header_length, u16 block_length, struct amd_iommu *iommu)=0A {=0A     u16 =
dev_length, bdf;=0A =0A-    dev_length =3D sizeof(struct acpi_ivhd_device_s=
pecial);=0A+    dev_length =3D sizeof(*special);=0A     if ( header_length =
< (block_length + dev_length) )=0A     {=0A         AMD_IOMMU_DEBUG("IVHD =
Error: Invalid Device_Entry Length!\n");=0A         return 0;=0A     }=0A =
=0A-    bdf =3D ivhd_device->special.dev_id;=0A+    bdf =3D special->used_i=
d;=0A     if ( bdf >=3D ivrs_bdf_entries )=0A     {=0A         AMD_IOMMU_DE=
BUG("IVHD Error: Invalid Device_Entry Dev_Id 0x%x\n", bdf);=0A         =
return 0;=0A     }=0A =0A-    add_ivrs_mapping_entry(bdf, bdf, ivhd_device-=
>header.flags, iommu);=0A+    add_ivrs_mapping_entry(bdf, bdf, special->hea=
der.data_setting, iommu);=0A     /* set device id of ioapic */=0A-    =
ioapic_sbdf[ivhd_device->special.handle].bdf =3D bdf;=0A-    ioapic_sbdf[iv=
hd_device->special.handle].seg =3D seg;=0A+    ioapic_sbdf[special->handle]=
.bdf =3D bdf;=0A+    ioapic_sbdf[special->handle].seg =3D seg;=0A     =
return dev_length;=0A }=0A =0A-static int __init parse_ivhd_block(struct =
acpi_ivhd_block_header *ivhd_block)=0A+static int __init parse_ivhd_block(c=
onst struct acpi_ivrs_hardware *ivhd_block)=0A {=0A-    union acpi_ivhd_dev=
ice *ivhd_device;=0A+    const union acpi_ivhd_device *ivhd_device;=0A     =
u16 block_length, dev_length;=0A     struct amd_iommu *iommu;=0A =0A-    =
if ( ivhd_block->header.length <=0A-         sizeof(struct acpi_ivhd_block_=
header) )=0A+    if ( ivhd_block->header.length < sizeof(*ivhd_block) )=0A =
    {=0A         AMD_IOMMU_DEBUG("IVHD Error: Invalid Block Length!\n");=0A=
         return -ENODEV;=0A     }=0A =0A-    iommu =3D find_iommu_from_bdf_=
cap(ivhd_block->header.dev_id,=0A-                                    =
ivhd_block->cap_offset);=0A+    iommu =3D find_iommu_from_bdf_cap(ivhd_bloc=
k->header.device_id,=0A+                                    ivhd_block->cap=
ability_offset);=0A     if ( !iommu )=0A     {=0A         AMD_IOMMU_DEBUG("=
IVHD Error: No IOMMU for Dev_Id 0x%x  Cap 0x%x\n",=0A-                     =
   ivhd_block->header.dev_id, ivhd_block->cap_offset);=0A+                 =
       ivhd_block->header.device_id,=0A+                        ivhd_block-=
>capability_offset);=0A         return -ENODEV;=0A     }=0A =0A     /* =
parse Device Entries */=0A-    block_length =3D sizeof(struct acpi_ivhd_blo=
ck_header);=0A+    block_length =3D sizeof(*ivhd_block);=0A     while ( =
ivhd_block->header.length >=3D=0A-            (block_length + sizeof(struct=
 acpi_ivhd_device_header)) )=0A+            (block_length + sizeof(struct =
acpi_ivrs_de_header)) )=0A     {=0A-        ivhd_device =3D (union =
acpi_ivhd_device *)=0A-            ((u8 *)ivhd_block + block_length);=0A+  =
      ivhd_device =3D (const void *)((const u8 *)ivhd_block + block_length)=
;=0A =0A         AMD_IOMMU_DEBUG( "IVHD Device Entry:\n");=0A         =
AMD_IOMMU_DEBUG( " Type 0x%x\n", ivhd_device->header.type);=0A-        =
AMD_IOMMU_DEBUG( " Dev_Id 0x%x\n", ivhd_device->header.dev_id);=0A-        =
AMD_IOMMU_DEBUG( " Flags 0x%x\n", ivhd_device->header.flags);=0A+        =
AMD_IOMMU_DEBUG( " Dev_Id 0x%x\n", ivhd_device->header.id);=0A+        =
AMD_IOMMU_DEBUG( " Flags 0x%x\n", ivhd_device->header.data_setting);=0A =
=0A         switch ( ivhd_device->header.type )=0A         {=0A-        =
case AMD_IOMMU_ACPI_IVHD_DEV_U32_PAD:=0A+        case ACPI_IVRS_TYPE_PAD4:=
=0A             dev_length =3D parse_ivhd_device_padding(=0A               =
  sizeof(u32),=0A                 ivhd_block->header.length, block_length);=
=0A             break;=0A-        case AMD_IOMMU_ACPI_IVHD_DEV_U64_PAD:=0A+=
        case ACPI_IVRS_TYPE_PAD8:=0A             dev_length =3D parse_ivhd_=
device_padding(=0A                 sizeof(u64),=0A                 =
ivhd_block->header.length, block_length);=0A             break;=0A-        =
case AMD_IOMMU_ACPI_IVHD_DEV_SELECT:=0A-            dev_length =3D =
parse_ivhd_device_select(ivhd_device, iommu);=0A+        case ACPI_IVRS_TYP=
E_SELECT:=0A+            dev_length =3D parse_ivhd_device_select(&ivhd_devi=
ce->select, iommu);=0A             break;=0A-        case AMD_IOMMU_ACPI_IV=
HD_DEV_RANGE_START:=0A+        case ACPI_IVRS_TYPE_START:=0A             =
dev_length =3D parse_ivhd_device_range(=0A-                ivhd_device,=0A+=
                &ivhd_device->range,=0A                 ivhd_block->header.=
length, block_length, iommu);=0A             break;=0A-        case =
AMD_IOMMU_ACPI_IVHD_DEV_ALIAS_SELECT:=0A+        case ACPI_IVRS_TYPE_ALIAS_=
SELECT:=0A             dev_length =3D parse_ivhd_device_alias(=0A-         =
       ivhd_device,=0A+                &ivhd_device->alias,=0A             =
    ivhd_block->header.length, block_length, iommu);=0A             =
break;=0A-        case AMD_IOMMU_ACPI_IVHD_DEV_ALIAS_RANGE:=0A+        =
case ACPI_IVRS_TYPE_ALIAS_START:=0A             dev_length =3D parse_ivhd_d=
evice_alias_range(=0A-                ivhd_device,=0A+                =
&ivhd_device->alias_range,=0A                 ivhd_block->header.length, =
block_length, iommu);=0A             break;=0A-        case AMD_IOMMU_ACPI_=
IVHD_DEV_EXT_SELECT:=0A+        case ACPI_IVRS_TYPE_EXT_SELECT:=0A         =
    dev_length =3D parse_ivhd_device_extended(=0A-                =
ivhd_device,=0A+                &ivhd_device->extended,=0A                 =
ivhd_block->header.length, block_length, iommu);=0A             break;=0A- =
       case AMD_IOMMU_ACPI_IVHD_DEV_EXT_RANGE:=0A+        case ACPI_IVRS_TY=
PE_EXT_START:=0A             dev_length =3D parse_ivhd_device_extended_rang=
e(=0A-                ivhd_device,=0A+                &ivhd_device->extende=
d_range,=0A                 ivhd_block->header.length, block_length, =
iommu);=0A             break;=0A-        case AMD_IOMMU_ACPI_IVHD_DEV_SPECI=
AL:=0A+        case ACPI_IVRS_TYPE_SPECIAL:=0A             dev_length =3D =
parse_ivhd_device_special(=0A-                ivhd_device, ivhd_block->pci_=
segment,=0A+                &ivhd_device->special, ivhd_block->pci_segment_=
group,=0A                 ivhd_block->header.length, block_length, =
iommu);=0A             break;=0A         default:=0A@@ -730,22 +750,24 @@ =
static int __init parse_ivhd_block(struc=0A     return 0;=0A }=0A =
=0A-static int __init parse_ivrs_block(struct acpi_ivrs_block_header =
*ivrs_block)=0A+static int __init parse_ivrs_block(const struct acpi_ivrs_h=
eader *ivrs_block)=0A {=0A-    struct acpi_ivhd_block_header *ivhd_block;=
=0A-    struct acpi_ivmd_block_header *ivmd_block;=0A+    const struct =
acpi_ivrs_hardware *ivhd_block;=0A+    const struct acpi_ivrs_memory =
*ivmd_block;=0A =0A     switch ( ivrs_block->type )=0A     {=0A-    case =
AMD_IOMMU_ACPI_IVHD_TYPE:=0A-        ivhd_block =3D (struct acpi_ivhd_block=
_header *)ivrs_block;=0A+    case ACPI_IVRS_TYPE_HARDWARE:=0A+        =
ivhd_block =3D container_of(ivrs_block, const struct acpi_ivrs_hardware,=0A=
+                                  header);=0A         return parse_ivhd_bl=
ock(ivhd_block);=0A =0A-    case AMD_IOMMU_ACPI_IVMD_ALL_TYPE:=0A-    case =
AMD_IOMMU_ACPI_IVMD_ONE_TYPE:=0A-    case AMD_IOMMU_ACPI_IVMD_RANGE_TYPE:=
=0A-    case AMD_IOMMU_ACPI_IVMD_IOMMU_TYPE:=0A-        ivmd_block =3D =
(struct acpi_ivmd_block_header *)ivrs_block;=0A+    case ACPI_IVRS_TYPE_MEM=
ORY_ALL:=0A+    case ACPI_IVRS_TYPE_MEMORY_ONE:=0A+    case ACPI_IVRS_TYPE_=
MEMORY_RANGE:=0A+    case ACPI_IVRS_TYPE_MEMORY_IOMMU:=0A+        =
ivmd_block =3D container_of(ivrs_block, const struct acpi_ivrs_memory,=0A+ =
                                 header);=0A         return parse_ivmd_bloc=
k(ivmd_block);=0A =0A     default:=0A@@ -792,12 +814,11 @@ static void =
__init dump_acpi_table_heade=0A =0A }=0A =0A-static int __init parse_ivrs_t=
able(struct acpi_table_header *_table)=0A+static int __init parse_ivrs_tabl=
e(struct acpi_table_header *table)=0A {=0A-    struct acpi_ivrs_block_heade=
r *ivrs_block;=0A+    const struct acpi_ivrs_header *ivrs_block;=0A     =
unsigned long length;=0A     int error =3D 0;=0A-    struct acpi_table_head=
er *table =3D (struct acpi_table_header *)_table;=0A =0A     BUG_ON(!table)=
;=0A =0A@@ -805,17 +826,16 @@ static int __init parse_ivrs_table(struc=0A  =
       dump_acpi_table_header(table);=0A =0A     /* parse IVRS blocks =
*/=0A-    length =3D sizeof(struct acpi_ivrs_table_header);=0A+    length =
=3D sizeof(struct acpi_table_ivrs);=0A     while ( (error =3D=3D 0) && =
(table->length > (length + sizeof(*ivrs_block))) )=0A     {=0A-        =
ivrs_block =3D (struct acpi_ivrs_block_header *)=0A-            ((u8 =
*)table + length);=0A+        ivrs_block =3D (struct acpi_ivrs_header =
*)((u8 *)table + length);=0A =0A         AMD_IOMMU_DEBUG("IVRS Block:\n");=
=0A         AMD_IOMMU_DEBUG(" Type 0x%x\n", ivrs_block->type);=0A         =
AMD_IOMMU_DEBUG(" Flags 0x%x\n", ivrs_block->flags);=0A         AMD_IOMMU_D=
EBUG(" Length 0x%x\n", ivrs_block->length);=0A-        AMD_IOMMU_DEBUG(" =
Dev_Id 0x%x\n", ivrs_block->dev_id);=0A+        AMD_IOMMU_DEBUG(" Dev_Id =
0x%x\n", ivrs_block->device_id);=0A =0A         if ( table->length < =
(length + ivrs_block->length) )=0A         {=0A@@ -833,12 +853,11 @@ =
static int __init parse_ivrs_table(struc=0A     return error;=0A }=0A =
=0A-static int __init detect_iommu_acpi(struct acpi_table_header =
*_table)=0A+static int __init detect_iommu_acpi(struct acpi_table_header =
*table)=0A {=0A-    struct acpi_ivrs_block_header *ivrs_block;=0A-    =
struct acpi_table_header *table =3D (struct acpi_table_header *)_table;=0A+=
    const struct acpi_ivrs_header *ivrs_block;=0A     unsigned long i;=0A- =
   unsigned long length =3D sizeof(struct acpi_ivrs_table_header);=0A+    =
unsigned long length =3D sizeof(struct acpi_table_ivrs);=0A     u8 =
checksum, *raw_table;=0A =0A     /* validate checksum: sum of entire table =
=3D=3D 0 */=0A@@ -854,12 +873,14 @@ static int __init detect_iommu_acpi(str=
u=0A =0A     while ( table->length > (length + sizeof(*ivrs_block)) )=0A   =
  {=0A-        ivrs_block =3D (struct acpi_ivrs_block_header *) ((u8 =
*)table + length);=0A+        ivrs_block =3D (struct acpi_ivrs_header =
*)((u8 *)table + length);=0A         if ( table->length < (length + =
ivrs_block->length) )=0A             return -ENODEV;=0A-        if ( =
ivrs_block->type =3D=3D AMD_IOMMU_ACPI_IVHD_TYPE )=0A-            if ( =
amd_iommu_detect_one_acpi((void*)ivrs_block) !=3D 0 )=0A-                =
return -ENODEV;=0A+        if ( ivrs_block->type =3D=3D ACPI_IVRS_TYPE_HARD=
WARE &&=0A+             amd_iommu_detect_one_acpi(=0A+                 =
container_of(ivrs_block, const struct acpi_ivrs_hardware,=0A+              =
                header)) !=3D 0 )=0A+            return -ENODEV;=0A        =
 length +=3D ivrs_block->length;=0A     }=0A     return 0;=0A@@ -870,63 =
+891,59 @@ static int __init detect_iommu_acpi(stru=0A        last_bdf =3D =
(x); \=0A    } while(0);=0A =0A-static int __init get_last_bdf_ivhd(void =
*ivhd)=0A+static int __init get_last_bdf_ivhd(=0A+    const struct =
acpi_ivrs_hardware *ivhd_block)=0A {=0A-    union acpi_ivhd_device =
*ivhd_device;=0A+    const union acpi_ivhd_device *ivhd_device;=0A     u16 =
block_length, dev_length;=0A-    struct acpi_ivhd_block_header *ivhd_block;=
=0A-=0A-    ivhd_block =3D (struct acpi_ivhd_block_header *)ivhd;=0A =0A-  =
  if ( ivhd_block->header.length <=0A-         sizeof(struct acpi_ivhd_bloc=
k_header) )=0A+    if ( ivhd_block->header.length < sizeof(*ivhd_block) =
)=0A     {=0A         AMD_IOMMU_DEBUG("IVHD Error: Invalid Block Length!\n"=
);=0A         return -ENODEV;=0A     }=0A =0A-    block_length =3D =
sizeof(struct acpi_ivhd_block_header);=0A+    block_length =3D sizeof(*ivhd=
_block);=0A     while ( ivhd_block->header.length >=3D=0A-            =
(block_length + sizeof(struct acpi_ivhd_device_header)) )=0A+            =
(block_length + sizeof(struct acpi_ivrs_de_header)) )=0A     {=0A-        =
ivhd_device =3D (union acpi_ivhd_device *)=0A-            ((u8 *)ivhd_block=
 + block_length);=0A+        ivhd_device =3D (const void *)((u8 *)ivhd_bloc=
k + block_length);=0A =0A         switch ( ivhd_device->header.type )=0A   =
      {=0A-        case AMD_IOMMU_ACPI_IVHD_DEV_U32_PAD:=0A+        case =
ACPI_IVRS_TYPE_PAD4:=0A             dev_length =3D sizeof(u32);=0A         =
    break;=0A-        case AMD_IOMMU_ACPI_IVHD_DEV_U64_PAD:=0A+        =
case ACPI_IVRS_TYPE_PAD8:=0A             dev_length =3D sizeof(u64);=0A    =
         break;=0A-        case AMD_IOMMU_ACPI_IVHD_DEV_SELECT:=0A-        =
    UPDATE_LAST_BDF(ivhd_device->header.dev_id);=0A-            dev_length =
=3D sizeof(struct acpi_ivhd_device_header);=0A-            break;=0A-      =
  case AMD_IOMMU_ACPI_IVHD_DEV_ALIAS_SELECT:=0A-            UPDATE_LAST_BDF=
(ivhd_device->header.dev_id);=0A-            dev_length =3D sizeof(struct =
acpi_ivhd_device_alias);=0A-            break;=0A-        case AMD_IOMMU_AC=
PI_IVHD_DEV_EXT_SELECT:=0A-            UPDATE_LAST_BDF(ivhd_device->header.=
dev_id);=0A-            dev_length =3D sizeof(struct acpi_ivhd_device_exten=
ded);=0A-            break;=0A-        case AMD_IOMMU_ACPI_IVHD_DEV_RANGE_S=
TART:=0A-            UPDATE_LAST_BDF(ivhd_device->range.trailer.dev_id);=0A=
-            dev_length =3D sizeof(struct acpi_ivhd_device_range);=0A-     =
       break;=0A-        case AMD_IOMMU_ACPI_IVHD_DEV_ALIAS_RANGE:=0A-     =
       UPDATE_LAST_BDF(ivhd_device->alias_range.trailer.dev_id)=0A-        =
    dev_length =3D sizeof(struct acpi_ivhd_device_alias_range);=0A-        =
    break;=0A-        case AMD_IOMMU_ACPI_IVHD_DEV_EXT_RANGE:=0A-          =
  UPDATE_LAST_BDF(ivhd_device->extended_range.trailer.dev_id)=0A-          =
  dev_length =3D sizeof(struct acpi_ivhd_device_extended_range);=0A-       =
     break;=0A-        case AMD_IOMMU_ACPI_IVHD_DEV_SPECIAL:=0A-           =
 UPDATE_LAST_BDF(ivhd_device->special.dev_id)=0A-            dev_length =
=3D sizeof(struct acpi_ivhd_device_special);=0A+        case ACPI_IVRS_TYPE=
_SELECT:=0A+            UPDATE_LAST_BDF(ivhd_device->select.header.id);=0A+=
            dev_length =3D sizeof(ivhd_device->header);=0A+            =
break;=0A+        case ACPI_IVRS_TYPE_ALIAS_SELECT:=0A+            =
UPDATE_LAST_BDF(ivhd_device->alias.header.id);=0A+            dev_length =
=3D sizeof(ivhd_device->alias);=0A+            break;=0A+        case =
ACPI_IVRS_TYPE_EXT_SELECT:=0A+            UPDATE_LAST_BDF(ivhd_device->exte=
nded.header.id);=0A+            dev_length =3D sizeof(ivhd_device->extended=
);=0A+            break;=0A+        case ACPI_IVRS_TYPE_START:=0A+         =
   UPDATE_LAST_BDF(ivhd_device->range.end.header.id);=0A+            =
dev_length =3D sizeof(ivhd_device->range);=0A+            break;=0A+       =
 case ACPI_IVRS_TYPE_ALIAS_START:=0A+            UPDATE_LAST_BDF(ivhd_devic=
e->alias_range.end.header.id)=0A+            dev_length =3D sizeof(ivhd_dev=
ice->alias_range);=0A+            break;=0A+        case ACPI_IVRS_TYPE_EXT=
_START:=0A+            UPDATE_LAST_BDF(ivhd_device->extended_range.end.head=
er.id)=0A+            dev_length =3D sizeof(ivhd_device->extended_range);=
=0A+            break;=0A+        case ACPI_IVRS_TYPE_SPECIAL:=0A+         =
   UPDATE_LAST_BDF(ivhd_device->special.used_id)=0A+            dev_length =
=3D sizeof(ivhd_device->special);=0A             break;=0A         =
default:=0A             AMD_IOMMU_DEBUG("IVHD Error: Invalid Device =
Type!\n");=0A@@ -942,20 +959,21 @@ static int __init get_last_bdf_ivhd(void=
=0A     return 0;=0A }=0A =0A-static int __init get_last_bdf_acpi(struct =
acpi_table_header *_table)=0A+static int __init get_last_bdf_acpi(struct =
acpi_table_header *table)=0A {=0A-    struct acpi_ivrs_block_header =
*ivrs_block;=0A-    struct acpi_table_header *table =3D (struct acpi_table_=
header *)_table;=0A-    unsigned long length =3D sizeof(struct acpi_ivrs_ta=
ble_header);=0A+    const struct acpi_ivrs_header *ivrs_block;=0A+    =
unsigned long length =3D sizeof(struct acpi_table_ivrs);=0A =0A     while =
( table->length > (length + sizeof(*ivrs_block)) )=0A     {=0A-        =
ivrs_block =3D (struct acpi_ivrs_block_header *) ((u8 *)table + length);=0A=
+        ivrs_block =3D (struct acpi_ivrs_header *)((u8 *)table + =
length);=0A         if ( table->length < (length + ivrs_block->length) =
)=0A             return -ENODEV;=0A-        if ( ivrs_block->type =3D=3D =
AMD_IOMMU_ACPI_IVHD_TYPE )=0A-            if ( get_last_bdf_ivhd((void*)ivr=
s_block) !=3D 0 )=0A-                return -ENODEV;=0A+        if ( =
ivrs_block->type =3D=3D ACPI_IVRS_TYPE_HARDWARE &&=0A+             =
get_last_bdf_ivhd(=0A+                 container_of(ivrs_block, const =
struct acpi_ivrs_hardware,=0A+                              header)) !=3D =
0 )=0A+            return -ENODEV;=0A         length +=3D ivrs_block->lengt=
h;=0A     }=0A    return 0;=0A@@ -963,16 +981,16 @@ static int __init =
get_last_bdf_acpi(stru=0A =0A int __init amd_iommu_detect_acpi(void)=0A =
{=0A-    return acpi_table_parse(AMD_IOMMU_ACPI_IVRS_SIG, detect_iommu_acpi=
);=0A+    return acpi_table_parse(ACPI_SIG_IVRS, detect_iommu_acpi);=0A =
}=0A =0A int __init amd_iommu_get_ivrs_dev_entries(void)=0A {=0A-    =
acpi_table_parse(AMD_IOMMU_ACPI_IVRS_SIG, get_last_bdf_acpi);=0A+    =
acpi_table_parse(ACPI_SIG_IVRS, get_last_bdf_acpi);=0A     return last_bdf =
+ 1;=0A }=0A =0A int __init amd_iommu_update_ivrs_mapping_acpi(void)=0A =
{=0A-    return acpi_table_parse(AMD_IOMMU_ACPI_IVRS_SIG, parse_ivrs_table)=
;=0A+    return acpi_table_parse(ACPI_SIG_IVRS, parse_ivrs_table);=0A =
}=0A--- a/xen/drivers/passthrough/amd/iommu_detect.c=0A+++ b/xen/drivers/pa=
ssthrough/amd/iommu_detect.c=0A@@ -20,12 +20,12 @@=0A =0A #include =
<xen/config.h>=0A #include <xen/errno.h>=0A+#include <xen/acpi.h>=0A =
#include <xen/iommu.h>=0A #include <xen/pci.h>=0A #include <xen/pci_regs.h>=
=0A #include <asm/amd-iommu.h>=0A #include <asm/hvm/svm/amd-iommu-proto.h>=
=0A-#include <asm/hvm/svm/amd-iommu-acpi.h>=0A =0A static int __init =
get_iommu_msi_capabilities(=0A     u16 seg, u8 bus, u8 dev, u8 func, =
struct amd_iommu *iommu)=0A@@ -103,23 +103,21 @@ void __init get_iommu_feat=
ures(struct am=0A     }=0A }=0A =0A-int __init amd_iommu_detect_one_acpi(vo=
id *ivhd)=0A+int __init amd_iommu_detect_one_acpi(=0A+    const struct =
acpi_ivrs_hardware *ivhd_block)=0A {=0A     struct amd_iommu *iommu;=0A    =
 u8 bus, dev, func;=0A-    struct acpi_ivhd_block_header *ivhd_block;=0A   =
  int rt =3D 0;=0A =0A-    ivhd_block =3D (struct acpi_ivhd_block_header =
*)ivhd;=0A-=0A-    if ( ivhd_block->header.length < sizeof(struct =
acpi_ivhd_block_header) )=0A+    if ( ivhd_block->header.length < =
sizeof(*ivhd_block) )=0A     {=0A         AMD_IOMMU_DEBUG("Invalid IVHD =
Block Length!\n");=0A         return -ENODEV;=0A     }=0A =0A-    if ( =
!ivhd_block->header.dev_id ||=0A-        !ivhd_block->cap_offset || =
!ivhd_block->mmio_base)=0A+    if ( !ivhd_block->header.device_id ||=0A+   =
     !ivhd_block->capability_offset || !ivhd_block->base_address)=0A     =
{=0A         AMD_IOMMU_DEBUG("Invalid IVHD Block!\n");=0A         return =
-ENODEV;=0A@@ -134,10 +132,10 @@ int __init amd_iommu_detect_one_acpi(voi=
=0A =0A     spin_lock_init(&iommu->lock);=0A =0A-    iommu->seg =3D =
ivhd_block->pci_segment;=0A-    iommu->bdf =3D ivhd_block->header.dev_id;=
=0A-    iommu->cap_offset =3D ivhd_block->cap_offset;=0A-    iommu->mmio_ba=
se_phys =3D ivhd_block->mmio_base;=0A+    iommu->seg =3D ivhd_block->pci_se=
gment_group;=0A+    iommu->bdf =3D ivhd_block->header.device_id;=0A+    =
iommu->cap_offset =3D ivhd_block->capability_offset;=0A+    iommu->mmio_bas=
e_phys =3D ivhd_block->base_address;=0A =0A     /* override IOMMU HT flags =
*/=0A     iommu->ht_flags =3D ivhd_block->header.flags;=0A--- a/xen/drivers=
/passthrough/amd/iommu_init.c=0A+++ b/xen/drivers/passthrough/amd/iommu_ini=
t.c=0A@@ -20,6 +20,7 @@=0A =0A #include <xen/config.h>=0A #include =
<xen/errno.h>=0A+#include <xen/acpi.h>=0A #include <xen/pci.h>=0A #include =
<xen/pci_regs.h>=0A #include <xen/irq.h>=0A@@ -28,7 +29,6 @@=0A #include =
<asm/hvm/svm/amd-iommu-proto.h>=0A #include <asm-x86/fixmap.h>=0A #include =
<mach_apic.h>=0A-#include <asm/hvm/svm/amd-iommu-acpi.h>=0A =0A static int =
__initdata nr_amd_iommus;=0A =0A@@ -37,9 +37,8 @@ static struct radix_tree_=
root ivrs_maps;=0A struct list_head amd_iommu_head;=0A struct table_struct =
device_table;=0A =0A-static int iommu_has_ht_flag(struct amd_iommu *iommu, =
uint8_t bit)=0A+static int iommu_has_ht_flag(struct amd_iommu *iommu, u8 =
mask)=0A {=0A-    u8 mask =3D 1U << bit;=0A     return iommu->ht_flags & =
mask;=0A }=0A =0A@@ -80,19 +79,19 @@ static void set_iommu_ht_flags(struct =
am=0A =0A     /* Setup HT flags */=0A     if ( iommu_has_cap(iommu, =
PCI_CAP_HT_TUNNEL_SHIFT) )=0A-        iommu_has_ht_flag(iommu, AMD_IOMMU_AC=
PI_HT_TUN_ENB_SHIFT) ?=0A+        iommu_has_ht_flag(iommu, ACPI_IVHD_TT_ENA=
BLE) ?=0A             iommu_set_bit(&entry, IOMMU_CONTROL_HT_TUNNEL_TRANSLA=
TION_SHIFT) :=0A             iommu_clear_bit(&entry, IOMMU_CONTROL_HT_TUNNE=
L_TRANSLATION_SHIFT);=0A =0A-    iommu_has_ht_flag(iommu, AMD_IOMMU_ACPI_RE=
S_PASS_PW_SHIFT) ?=0A+    iommu_has_ht_flag(iommu, ACPI_IVHD_RES_PASS_PW) =
?=0A         iommu_set_bit(&entry, IOMMU_CONTROL_RESP_PASS_POSTED_WRITE_SHI=
FT):=0A         iommu_clear_bit(&entry, IOMMU_CONTROL_RESP_PASS_POSTED_WRIT=
E_SHIFT);=0A =0A-    iommu_has_ht_flag(iommu, AMD_IOMMU_ACPI_ISOC_SHIFT) =
?=0A+    iommu_has_ht_flag(iommu, ACPI_IVHD_ISOC) ?=0A         iommu_set_bi=
t(&entry, IOMMU_CONTROL_ISOCHRONOUS_SHIFT):=0A         iommu_clear_bit(&ent=
ry, IOMMU_CONTROL_ISOCHRONOUS_SHIFT);=0A =0A-    iommu_has_ht_flag(iommu, =
AMD_IOMMU_ACPI_PASS_PW_SHIFT) ?=0A+    iommu_has_ht_flag(iommu, ACPI_IVHD_P=
ASS_PW) ?=0A         iommu_set_bit(&entry, IOMMU_CONTROL_PASS_POSTED_WRITE_=
SHIFT):=0A         iommu_clear_bit(&entry, IOMMU_CONTROL_PASS_POSTED_WRITE_=
SHIFT);=0A =0A--- a/xen/drivers/passthrough/amd/iommu_map.c=0A+++ =
b/xen/drivers/passthrough/amd/iommu_map.c=0A@@ -18,12 +18,13 @@=0A  * =
Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307 =
USA=0A  */=0A =0A+#include <xen/config.h>=0A+#include <xen/acpi.h>=0A =
#include <xen/sched.h>=0A #include <asm/p2m.h>=0A #include <xen/hvm/iommu.h=
>=0A #include <asm/amd-iommu.h>=0A #include <asm/hvm/svm/amd-iommu-proto.h>=
=0A-#include <asm/hvm/svm/amd-iommu-acpi.h>=0A #include "../ats.h"=0A =
#include <xen/pci.h>=0A =0A@@ -215,8 +216,7 @@ void __init iommu_dte_add_de=
vice_entry(u=0A     dte[7] =3D dte[6] =3D dte[4] =3D dte[2] =3D dte[1] =3D =
dte[0] =3D 0;=0A =0A     flags =3D ivrs_dev->device_flags;=0A-    sys_mgt =
=3D get_field_from_byte(flags, AMD_IOMMU_ACPI_SYS_MGT_MASK,=0A-            =
                      AMD_IOMMU_ACPI_SYS_MGT_SHIFT);=0A+    sys_mgt =3D =
get_field_from_byte(flags, ACPI_IVHD_SYSTEM_MGMT);=0A     dev_ex =3D =
ivrs_dev->dte_allow_exclusion;=0A =0A     flags &=3D mask;=0A--- a/xen/incl=
ude/asm-x86/hvm/svm/amd-iommu-acpi.h=0A+++ /dev/null=0A@@ -1,185 +0,0 =
@@=0A-/*=0A- * Copyright (C) 2007 Advanced Micro Devices, Inc.=0A- * =
Author: Leo Duran <leo.duran@amd.com>=0A- * Author: Wei Wang <wei.wang2@amd=
.com> - adapted to xen=0A- *=0A- * This program is free software; you can =
redistribute it and/or modify=0A- * it under the terms of the GNU General =
Public License as published by=0A- * the Free Software Foundation; either =
version 2 of the License, or=0A- * (at your option) any later version.=0A- =
*=0A- * This program is distributed in the hope that it will be useful,=0A-=
 * but WITHOUT ANY WARRANTY; without even the implied warranty of=0A- * =
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the=0A- * GNU =
General Public License for more details.=0A- *=0A- * You should have =
received a copy of the GNU General Public License=0A- * along with this =
program; if not, write to the Free Software=0A- * Foundation, Inc., 59 =
Temple Place, Suite 330, Boston, MA  02111-1307 USA=0A- */=0A-=0A-#ifndef =
_ASM_X86_64_AMD_IOMMU_ACPI_H=0A-#define _ASM_X86_64_AMD_IOMMU_ACPI_H=0A-=0A=
-#include <xen/acpi.h>=0A-=0A-/* I/O Virtualization Reporting Structure =
*/=0A-#define AMD_IOMMU_ACPI_IVRS_SIG            "IVRS"=0A-#define =
AMD_IOMMU_ACPI_IVHD_TYPE       0x10=0A-#define AMD_IOMMU_ACPI_IVMD_ALL_TYPE=
       0x20=0A-#define AMD_IOMMU_ACPI_IVMD_ONE_TYPE       0x21=0A-#define =
AMD_IOMMU_ACPI_IVMD_RANGE_TYPE     0x22=0A-#define AMD_IOMMU_ACPI_IVMD_IOMM=
U_TYPE     0x23=0A-=0A-/* 4-byte Device Entries */=0A-#define AMD_IOMMU_ACP=
I_IVHD_DEV_U32_PAD        0=0A-#define AMD_IOMMU_ACPI_IVHD_DEV_SELECT     =
2=0A-#define AMD_IOMMU_ACPI_IVHD_DEV_RANGE_START    3=0A-#define AMD_IOMMU_=
ACPI_IVHD_DEV_RANGE_END  4=0A-=0A-/* 8-byte Device Entries */=0A-#define =
AMD_IOMMU_ACPI_IVHD_DEV_U64_PAD        64=0A-#define AMD_IOMMU_ACPI_IVHD_DE=
V_ALIAS_SELECT   66=0A-#define AMD_IOMMU_ACPI_IVHD_DEV_ALIAS_RANGE    =
67=0A-#define AMD_IOMMU_ACPI_IVHD_DEV_EXT_SELECT 70=0A-#define AMD_IOMMU_AC=
PI_IVHD_DEV_EXT_RANGE  71=0A-#define AMD_IOMMU_ACPI_IVHD_DEV_SPECIAL    =
72=0A-=0A-/* IVHD IOMMU Flags */=0A-#define AMD_IOMMU_ACPI_COHERENT_MASK   =
    0x20=0A-#define AMD_IOMMU_ACPI_COHERENT_SHIFT      5=0A-#define =
AMD_IOMMU_ACPI_IOTLB_SUP_MASK      0x10=0A-#define AMD_IOMMU_ACPI_IOTLB_SUP=
_SHIFT     4=0A-#define AMD_IOMMU_ACPI_ISOC_MASK       0x08=0A-#define =
AMD_IOMMU_ACPI_ISOC_SHIFT      3=0A-#define AMD_IOMMU_ACPI_RES_PASS_PW_MASK=
        0x04=0A-#define AMD_IOMMU_ACPI_RES_PASS_PW_SHIFT   2=0A-#define =
AMD_IOMMU_ACPI_PASS_PW_MASK        0x02=0A-#define AMD_IOMMU_ACPI_PASS_PW_S=
HIFT       1=0A-#define AMD_IOMMU_ACPI_HT_TUN_ENB_MASK     0x01=0A-#define =
AMD_IOMMU_ACPI_HT_TUN_ENB_SHIFT        0=0A-=0A-/* IVHD Device Flags =
*/=0A-#define AMD_IOMMU_ACPI_LINT1_PASS_MASK     0x80=0A-#define AMD_IOMMU_=
ACPI_LINT1_PASS_SHIFT        7=0A-#define AMD_IOMMU_ACPI_LINT0_PASS_MASK   =
  0x40=0A-#define AMD_IOMMU_ACPI_LINT0_PASS_SHIFT        6=0A-#define =
AMD_IOMMU_ACPI_SYS_MGT_MASK        0x30=0A-#define AMD_IOMMU_ACPI_SYS_MGT_S=
HIFT       4=0A-#define AMD_IOMMU_ACPI_NMI_PASS_MASK       0x04=0A-#define =
AMD_IOMMU_ACPI_NMI_PASS_SHIFT      2=0A-#define AMD_IOMMU_ACPI_EINT_PASS_MA=
SK      0x02=0A-#define AMD_IOMMU_ACPI_EINT_PASS_SHIFT     1=0A-#define =
AMD_IOMMU_ACPI_INIT_PASS_MASK      0x01=0A-#define AMD_IOMMU_ACPI_INIT_PASS=
_SHIFT     0=0A-=0A-/* IVHD Device Extended Flags */=0A-#define AMD_IOMMU_A=
CPI_ATS_DISABLED_MASK   0x80000000=0A-#define AMD_IOMMU_ACPI_ATS_DISABLED_S=
HIFT  31=0A-=0A-/* IVMD Device Flags */=0A-#define AMD_IOMMU_ACPI_EXCLUSION=
_RANGE_MASK    0x08=0A-#define AMD_IOMMU_ACPI_EXCLUSION_RANGE_SHIFT   =
3=0A-#define AMD_IOMMU_ACPI_IW_PERMISSION_MASK  0x04=0A-#define AMD_IOMMU_A=
CPI_IW_PERMISSION_SHIFT 2=0A-#define AMD_IOMMU_ACPI_IR_PERMISSION_MASK  =
0x02=0A-#define AMD_IOMMU_ACPI_IR_PERMISSION_SHIFT 1=0A-#define AMD_IOMMU_A=
CPI_UNITY_MAPPING_MASK  0x01=0A-#define AMD_IOMMU_ACPI_UNITY_MAPPING_SHIFT =
0=0A-=0A-#define ACPI_OEM_ID_SIZE                6=0A-#define ACPI_OEM_TABL=
E_ID_SIZE          8=0A-=0A-#pragma pack(1)=0A-struct acpi_ivrs_table_heade=
r {=0A-   struct acpi_table_header acpi_header;=0A-   u32 io_info;=0A-   =
u8  reserved[8];=0A-};=0A-=0A-struct acpi_ivrs_block_header {=0A-   u8  =
type;=0A-   u8  flags;=0A-   u16 length;=0A-   u16 dev_id;=0A-};=0A-=0A-str=
uct acpi_ivhd_block_header {=0A-   struct acpi_ivrs_block_header header;=0A=
-   u16 cap_offset;=0A-   u64 mmio_base;=0A-   u16 pci_segment;=0A-   u16 =
iommu_info;=0A-   u8 reserved[4];=0A-};=0A-=0A-struct acpi_ivhd_device_head=
er {=0A-   u8  type;=0A-   u16 dev_id;=0A-   u8  flags;=0A-};=0A-=0A-struct=
 acpi_ivhd_device_trailer {=0A-   u8  type;=0A-   u16 dev_id;=0A-   u8  =
reserved;=0A-};=0A-=0A-struct acpi_ivhd_device_range {=0A-   struct =
acpi_ivhd_device_header header;=0A-   struct acpi_ivhd_device_trailer =
trailer;=0A-};=0A-=0A-struct acpi_ivhd_device_alias {=0A-   struct =
acpi_ivhd_device_header header;=0A-   u8  reserved1;=0A-   u16 dev_id;=0A- =
  u8  reserved2;=0A-};=0A-=0A-struct acpi_ivhd_device_alias_range {=0A-   =
struct acpi_ivhd_device_alias alias;=0A-   struct acpi_ivhd_device_trailer =
trailer;=0A-};=0A-=0A-struct acpi_ivhd_device_extended {=0A-   struct =
acpi_ivhd_device_header header;=0A-   u32 ext_flags;=0A-};=0A-=0A-struct =
acpi_ivhd_device_extended_range {=0A-   struct acpi_ivhd_device_extended =
extended;=0A-   struct acpi_ivhd_device_trailer trailer;=0A-};=0A-=0A-struc=
t acpi_ivhd_device_special {=0A-   struct acpi_ivhd_device_header =
header;=0A-   u8  handle;=0A-   u16 dev_id;=0A-   u8  variety;=0A-};=0A-=0A=
-union acpi_ivhd_device {=0A-   struct acpi_ivhd_device_header header;=0A- =
  struct acpi_ivhd_device_range range;=0A-   struct acpi_ivhd_device_alias =
alias;=0A-   struct acpi_ivhd_device_alias_range alias_range;=0A-   struct =
acpi_ivhd_device_extended extended;=0A-   struct acpi_ivhd_device_extended_=
range extended_range;=0A-   struct acpi_ivhd_device_special special;=0A-};=
=0A-=0A-struct acpi_ivmd_block_header {=0A-   struct acpi_ivrs_block_header=
 header;=0A-   union {=0A-       u16 last_dev_id;=0A-       u16 cap_offset;=
=0A-       u16 reserved1;=0A-   };=0A-   u64 reserved2;=0A-   u64 =
start_addr;=0A-   u64 mem_length;=0A-};=0A-#pragma pack()=0A-=0A-#endif /* =
_ASM_X86_64_AMD_IOMMU_ACPI_H */=0A--- a/xen/include/asm-x86/hvm/svm/amd-iom=
mu-proto.h=0A+++ b/xen/include/asm-x86/hvm/svm/amd-iommu-proto.h=0A@@ =
-26,6 +26,8 @@=0A #include <asm/apicdef.h>=0A #include <xen/domain_page.h>=
=0A =0A+struct acpi_ivrs_hardware;=0A+=0A #define for_each_amd_iommu(amd_io=
mmu) \=0A     list_for_each_entry(amd_iommu, \=0A         &amd_iommu_head, =
list)=0A@@ -41,7 +43,7 @@=0A =0A /* amd-iommu-detect functions */=0A int =
amd_iommu_get_ivrs_dev_entries(void);=0A-int amd_iommu_detect_one_acpi(void=
 *ivhd);=0A+int amd_iommu_detect_one_acpi(const struct acpi_ivrs_hardware =
*);=0A int amd_iommu_detect_acpi(void);=0A void get_iommu_features(struct =
amd_iommu *iommu);=0A =0A@@ -121,11 +123,9 @@ static inline u32 set_field_i=
n_reg_u32(u=0A     return reg_value;=0A }=0A =0A-static inline u8 =
get_field_from_byte(u8 value, u8 mask, u8 shift)=0A+static inline u8 =
get_field_from_byte(u8 value, u8 mask)=0A {=0A-    u8 field;=0A-    field =
=3D (value & mask) >> shift;=0A-    return field;=0A+    return (value & =
mask) / (mask & -mask);=0A }=0A =0A static inline unsigned long region_to_p=
ages(unsigned long addr, unsigned long size)=0A
--=__Part456AE0A2.0__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--=__Part456AE0A2.0__=--


From xen-devel-bounces@lists.xensource.com Thu Dec 15 12:37:47 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 12:37:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbAYz-0004qj-No; Thu, 15 Dec 2011 12:37:29 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RbAYy-0004qT-24
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 12:37:28 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1323952588!2093214!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11824 invoked from network); 15 Dec 2011 12:36:28 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-9.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 15 Dec 2011 12:36:28 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 12 Dec 2011 16:10:36 +0000
Message-Id: <4EE635C20200007800067068@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 12 Dec 2011 16:11:30 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part456AE0A2.0__="
Subject: [Xen-devel] [PATCH 4/4] ACPI: eliminate duplicate IVRS definitions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__Part456AE0A2.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Use their proper counterparts in include/acpi/actbl*.h instead.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/drivers/passthrough/amd/iommu_acpi.c
+++ b/xen/drivers/passthrough/amd/iommu_acpi.c
@@ -20,10 +20,38 @@
=20
 #include <xen/config.h>
 #include <xen/errno.h>
+#include <xen/acpi.h>
 #include <asm/apicdef.h>
 #include <asm/amd-iommu.h>
 #include <asm/hvm/svm/amd-iommu-proto.h>
-#include <asm/hvm/svm/amd-iommu-acpi.h>
+
+/* Some helper structures, particularly to deal with ranges. */
+
+struct acpi_ivhd_device_range {
+   struct acpi_ivrs_device4 start;
+   struct acpi_ivrs_device4 end;
+};
+
+struct acpi_ivhd_device_alias_range {
+   struct acpi_ivrs_device8a alias;
+   struct acpi_ivrs_device4 end;
+};
+
+struct acpi_ivhd_device_extended_range {
+   struct acpi_ivrs_device8b extended;
+   struct acpi_ivrs_device4 end;
+};
+
+union acpi_ivhd_device {
+   struct acpi_ivrs_de_header header;
+   struct acpi_ivrs_device4 select;
+   struct acpi_ivhd_device_range range;
+   struct acpi_ivrs_device8a alias;
+   struct acpi_ivhd_device_alias_range alias_range;
+   struct acpi_ivrs_device8b extended;
+   struct acpi_ivhd_device_extended_range extended_range;
+   struct acpi_ivrs_device8c special;
+};
=20
 static unsigned short __initdata last_bdf;
=20
@@ -242,12 +270,12 @@ static int __init register_exclusion_ran
 }
=20
 static int __init parse_ivmd_device_select(
-    struct acpi_ivmd_block_header *ivmd_block,
+    const struct acpi_ivrs_memory *ivmd_block,
     unsigned long base, unsigned long limit, u8 iw, u8 ir)
 {
     u16 bdf;
=20
-    bdf =3D ivmd_block->header.dev_id;
+    bdf =3D ivmd_block->header.device_id;
     if ( bdf >=3D ivrs_bdf_entries )
     {
         AMD_IOMMU_DEBUG("IVMD Error: Invalid Dev_Id 0x%x\n", bdf);
@@ -258,13 +286,13 @@ static int __init parse_ivmd_device_sele
 }
=20
 static int __init parse_ivmd_device_range(
-    struct acpi_ivmd_block_header *ivmd_block,
+    const struct acpi_ivrs_memory *ivmd_block,
     unsigned long base, unsigned long limit, u8 iw, u8 ir)
 {
     u16 first_bdf, last_bdf, bdf;
     int error;
=20
-    first_bdf =3D ivmd_block->header.dev_id;
+    first_bdf =3D ivmd_block->header.device_id;
     if ( first_bdf >=3D ivrs_bdf_entries )
     {
         AMD_IOMMU_DEBUG("IVMD Error: "
@@ -272,7 +300,7 @@ static int __init parse_ivmd_device_rang
         return -ENODEV;
     }
=20
-    last_bdf =3D ivmd_block->last_dev_id;
+    last_bdf =3D ivmd_block->aux_data;
     if ( (last_bdf >=3D ivrs_bdf_entries) || (last_bdf <=3D first_bdf) )
     {
         AMD_IOMMU_DEBUG("IVMD Error: "
@@ -288,18 +316,18 @@ static int __init parse_ivmd_device_rang
 }
=20
 static int __init parse_ivmd_device_iommu(
-    struct acpi_ivmd_block_header *ivmd_block,
+    const struct acpi_ivrs_memory *ivmd_block,
     unsigned long base, unsigned long limit, u8 iw, u8 ir)
 {
     struct amd_iommu *iommu;
=20
     /* find target IOMMU */
-    iommu =3D find_iommu_from_bdf_cap(ivmd_block->header.dev_id,
-                                    ivmd_block->cap_offset);
+    iommu =3D find_iommu_from_bdf_cap(ivmd_block->header.device_id,
+                                    ivmd_block->aux_data);
     if ( !iommu )
     {
         AMD_IOMMU_DEBUG("IVMD Error: No IOMMU for Dev_Id 0x%x  Cap =
0x%x\n",
-                        ivmd_block->header.dev_id, ivmd_block->cap_offset)=
;
+                        ivmd_block->header.device_id, ivmd_block->aux_data=
);
         return -ENODEV;
     }
=20
@@ -307,20 +335,19 @@ static int __init parse_ivmd_device_iomm
         iommu, base, limit, iw, ir);
 }
=20
-static int __init parse_ivmd_block(struct acpi_ivmd_block_header =
*ivmd_block)
+static int __init parse_ivmd_block(const struct acpi_ivrs_memory =
*ivmd_block)
 {
     unsigned long start_addr, mem_length, base, limit;
     u8 iw, ir;
=20
-    if ( ivmd_block->header.length <
-         sizeof(struct acpi_ivmd_block_header) )
+    if ( ivmd_block->header.length < sizeof(*ivmd_block) )
     {
         AMD_IOMMU_DEBUG("IVMD Error: Invalid Block Length!\n");
         return -ENODEV;
     }
=20
-    start_addr =3D (unsigned long)ivmd_block->start_addr;
-    mem_length =3D (unsigned long)ivmd_block->mem_length;
+    start_addr =3D (unsigned long)ivmd_block->start_address;
+    mem_length =3D (unsigned long)ivmd_block->memory_length;
     base =3D start_addr & PAGE_MASK;
     limit =3D (start_addr + mem_length - 1) & PAGE_MASK;
=20
@@ -328,20 +355,14 @@ static int __init parse_ivmd_block(struc
     AMD_IOMMU_DEBUG(" Start_Addr_Phys 0x%lx\n", start_addr);
     AMD_IOMMU_DEBUG(" Mem_Length 0x%lx\n", mem_length);
=20
-    if ( get_field_from_byte(ivmd_block->header.flags,
-                             AMD_IOMMU_ACPI_EXCLUSION_RANGE_MASK,
-                             AMD_IOMMU_ACPI_EXCLUSION_RANGE_SHIFT) )
+    if ( ivmd_block->header.flags & ACPI_IVMD_EXCLUSION_RANGE )
         iw =3D ir =3D IOMMU_CONTROL_ENABLED;
-    else if ( get_field_from_byte(ivmd_block->header.flags,
-                                  AMD_IOMMU_ACPI_UNITY_MAPPING_MASK,
-                                  AMD_IOMMU_ACPI_UNITY_MAPPING_SHIFT) )
-    {
-        iw =3D get_field_from_byte(ivmd_block->header.flags,
-                                 AMD_IOMMU_ACPI_IW_PERMISSION_MASK,
-                                 AMD_IOMMU_ACPI_IW_PERMISSION_SHIFT);
-        ir =3D get_field_from_byte(ivmd_block->header.flags,
-                                 AMD_IOMMU_ACPI_IR_PERMISSION_MASK,
-                                 AMD_IOMMU_ACPI_IR_PERMISSION_SHIFT);
+    else if ( ivmd_block->header.flags & ACPI_IVMD_UNITY )
+    {
+        iw =3D ivmd_block->header.flags & ACPI_IVMD_READ ?
+            IOMMU_CONTROL_ENABLED : IOMMU_CONTROL_DISABLED;
+        ir =3D ivmd_block->header.flags & ACPI_IVMD_WRITE ?
+            IOMMU_CONTROL_ENABLED : IOMMU_CONTROL_DISABLED;
     }
     else
     {
@@ -351,19 +372,19 @@ static int __init parse_ivmd_block(struc
=20
     switch( ivmd_block->header.type )
     {
-    case AMD_IOMMU_ACPI_IVMD_ALL_TYPE:
+    case ACPI_IVRS_TYPE_MEMORY_ALL:
         return register_exclusion_range_for_all_devices(
             base, limit, iw, ir);
=20
-    case AMD_IOMMU_ACPI_IVMD_ONE_TYPE:
+    case ACPI_IVRS_TYPE_MEMORY_ONE:
         return parse_ivmd_device_select(ivmd_block,
                                         base, limit, iw, ir);
=20
-    case AMD_IOMMU_ACPI_IVMD_RANGE_TYPE:
+    case ACPI_IVRS_TYPE_MEMORY_RANGE:
         return parse_ivmd_device_range(ivmd_block,
                                        base, limit, iw, ir);
=20
-    case AMD_IOMMU_ACPI_IVMD_IOMMU_TYPE:
+    case ACPI_IVRS_TYPE_MEMORY_IOMMU:
         return parse_ivmd_device_iommu(ivmd_block,
                                        base, limit, iw, ir);
=20
@@ -386,45 +407,44 @@ static u16 __init parse_ivhd_device_padd
 }
=20
 static u16 __init parse_ivhd_device_select(
-    union acpi_ivhd_device *ivhd_device, struct amd_iommu *iommu)
+    const struct acpi_ivrs_device4 *select, struct amd_iommu *iommu)
 {
     u16 bdf;
=20
-    bdf =3D ivhd_device->header.dev_id;
+    bdf =3D select->header.id;
     if ( bdf >=3D ivrs_bdf_entries )
     {
         AMD_IOMMU_DEBUG("IVHD Error: Invalid Device_Entry Dev_Id 0x%x\n", =
bdf);
         return 0;
     }
=20
-    add_ivrs_mapping_entry(bdf, bdf, ivhd_device->header.flags, iommu);
+    add_ivrs_mapping_entry(bdf, bdf, select->header.data_setting, iommu);
=20
-    return sizeof(struct acpi_ivhd_device_header);
+    return sizeof(*select);
 }
=20
 static u16 __init parse_ivhd_device_range(
-    union acpi_ivhd_device *ivhd_device,
+    const struct acpi_ivhd_device_range *range,
     u16 header_length, u16 block_length, struct amd_iommu *iommu)
 {
     u16 dev_length, first_bdf, last_bdf, bdf;
=20
-    dev_length =3D sizeof(struct acpi_ivhd_device_range);
+    dev_length =3D sizeof(*range);
     if ( header_length < (block_length + dev_length) )
     {
         AMD_IOMMU_DEBUG("IVHD Error: Invalid Device_Entry Length!\n");
         return 0;
     }
=20
-    if ( ivhd_device->range.trailer.type !=3D
-         AMD_IOMMU_ACPI_IVHD_DEV_RANGE_END )
+    if ( range->end.header.type !=3D ACPI_IVRS_TYPE_END )
     {
         AMD_IOMMU_DEBUG("IVHD Error: "
                         "Invalid Range: End_Type 0x%x\n",
-                        ivhd_device->range.trailer.type);
+                        range->end.header.type);
         return 0;
     }
=20
-    first_bdf =3D ivhd_device->header.dev_id;
+    first_bdf =3D range->start.header.id;
     if ( first_bdf >=3D ivrs_bdf_entries )
     {
         AMD_IOMMU_DEBUG("IVHD Error: "
@@ -432,7 +452,7 @@ static u16 __init parse_ivhd_device_rang
         return 0;
     }
=20
-    last_bdf =3D ivhd_device->range.trailer.dev_id;
+    last_bdf =3D range->end.header.id;
     if ( (last_bdf >=3D ivrs_bdf_entries) || (last_bdf <=3D first_bdf) )
     {
         AMD_IOMMU_DEBUG("IVHD Error: "
@@ -443,32 +463,33 @@ static u16 __init parse_ivhd_device_rang
     AMD_IOMMU_DEBUG(" Dev_Id Range: 0x%x -> 0x%x\n", first_bdf, last_bdf);=

=20
     for ( bdf =3D first_bdf; bdf <=3D last_bdf; bdf++ )
-        add_ivrs_mapping_entry(bdf, bdf, ivhd_device->header.flags, =
iommu);
+        add_ivrs_mapping_entry(bdf, bdf, range->start.header.data_setting,=

+                               iommu);
=20
     return dev_length;
 }
=20
 static u16 __init parse_ivhd_device_alias(
-    union acpi_ivhd_device *ivhd_device,
+    const struct acpi_ivrs_device8a *alias,
     u16 header_length, u16 block_length, struct amd_iommu *iommu)
 {
     u16 dev_length, alias_id, bdf;
=20
-    dev_length =3D sizeof(struct acpi_ivhd_device_alias);
+    dev_length =3D sizeof(*alias);
     if ( header_length < (block_length + dev_length) )
     {
         AMD_IOMMU_DEBUG("IVHD Error: Invalid Device_Entry Length!\n");
         return 0;
     }
=20
-    bdf =3D ivhd_device->header.dev_id;
+    bdf =3D alias->header.id;
     if ( bdf >=3D ivrs_bdf_entries )
     {
         AMD_IOMMU_DEBUG("IVHD Error: Invalid Device_Entry Dev_Id 0x%x\n", =
bdf);
         return 0;
     }
=20
-    alias_id =3D ivhd_device->alias.dev_id;
+    alias_id =3D alias->used_id;
     if ( alias_id >=3D ivrs_bdf_entries )
     {
         AMD_IOMMU_DEBUG("IVHD Error: Invalid Alias Dev_Id 0x%x\n", =
alias_id);
@@ -477,35 +498,34 @@ static u16 __init parse_ivhd_device_alia
=20
     AMD_IOMMU_DEBUG(" Dev_Id Alias: 0x%x\n", alias_id);
=20
-    add_ivrs_mapping_entry(bdf, alias_id, ivhd_device->header.flags, =
iommu);
+    add_ivrs_mapping_entry(bdf, alias_id, alias->header.data_setting, =
iommu);
=20
     return dev_length;
 }
=20
 static u16 __init parse_ivhd_device_alias_range(
-    union acpi_ivhd_device *ivhd_device,
+    const struct acpi_ivhd_device_alias_range *range,
     u16 header_length, u16 block_length, struct amd_iommu *iommu)
 {
=20
     u16 dev_length, first_bdf, last_bdf, alias_id, bdf;
=20
-    dev_length =3D sizeof(struct acpi_ivhd_device_alias_range);
+    dev_length =3D sizeof(*range);
     if ( header_length < (block_length + dev_length) )
     {
         AMD_IOMMU_DEBUG("IVHD Error: Invalid Device_Entry Length!\n");
         return 0;
     }
=20
-    if ( ivhd_device->alias_range.trailer.type !=3D
-         AMD_IOMMU_ACPI_IVHD_DEV_RANGE_END )
+    if ( range->end.header.type !=3D ACPI_IVRS_TYPE_END )
     {
         AMD_IOMMU_DEBUG("IVHD Error: "
                         "Invalid Range: End_Type 0x%x\n",
-                        ivhd_device->alias_range.trailer.type);
+                        range->end.header.type);
         return 0;
     }
=20
-    first_bdf =3D ivhd_device->header.dev_id;
+    first_bdf =3D range->alias.header.id;
     if ( first_bdf >=3D ivrs_bdf_entries )
     {
         AMD_IOMMU_DEBUG("IVHD Error: "
@@ -513,7 +533,7 @@ static u16 __init parse_ivhd_device_alia
         return 0;
     }
=20
-    last_bdf =3D ivhd_device->alias_range.trailer.dev_id;
+    last_bdf =3D range->end.header.id;
     if ( last_bdf >=3D ivrs_bdf_entries || last_bdf <=3D first_bdf )
     {
         AMD_IOMMU_DEBUG(
@@ -521,7 +541,7 @@ static u16 __init parse_ivhd_device_alia
         return 0;
     }
=20
-    alias_id =3D ivhd_device->alias_range.alias.dev_id;
+    alias_id =3D range->alias.used_id;
     if ( alias_id >=3D ivrs_bdf_entries )
     {
         AMD_IOMMU_DEBUG("IVHD Error: Invalid Alias Dev_Id 0x%x\n", =
alias_id);
@@ -532,59 +552,59 @@ static u16 __init parse_ivhd_device_alia
     AMD_IOMMU_DEBUG(" Dev_Id Alias: 0x%x\n", alias_id);
=20
     for ( bdf =3D first_bdf; bdf <=3D last_bdf; bdf++ )
-        add_ivrs_mapping_entry(bdf, alias_id, ivhd_device->header.flags, =
iommu);
+        add_ivrs_mapping_entry(bdf, alias_id, range->alias.header.data_set=
ting,
+                               iommu);
=20
     return dev_length;
 }
=20
 static u16 __init parse_ivhd_device_extended(
-    union acpi_ivhd_device *ivhd_device,
+    const struct acpi_ivrs_device8b *ext,
     u16 header_length, u16 block_length, struct amd_iommu *iommu)
 {
     u16 dev_length, bdf;
=20
-    dev_length =3D sizeof(struct acpi_ivhd_device_extended);
+    dev_length =3D sizeof(*ext);
     if ( header_length < (block_length + dev_length) )
     {
         AMD_IOMMU_DEBUG("IVHD Error: Invalid Device_Entry Length!\n");
         return 0;
     }
=20
-    bdf =3D ivhd_device->header.dev_id;
+    bdf =3D ext->header.id;
     if ( bdf >=3D ivrs_bdf_entries )
     {
         AMD_IOMMU_DEBUG("IVHD Error: Invalid Device_Entry Dev_Id 0x%x\n", =
bdf);
         return 0;
     }
=20
-    add_ivrs_mapping_entry(bdf, bdf, ivhd_device->header.flags, iommu);
+    add_ivrs_mapping_entry(bdf, bdf, ext->header.data_setting, iommu);
=20
     return dev_length;
 }
=20
 static u16 __init parse_ivhd_device_extended_range(
-    union acpi_ivhd_device *ivhd_device,
+    const struct acpi_ivhd_device_extended_range *range,
     u16 header_length, u16 block_length, struct amd_iommu *iommu)
 {
     u16 dev_length, first_bdf, last_bdf, bdf;
=20
-    dev_length =3D sizeof(struct acpi_ivhd_device_extended_range);
+    dev_length =3D sizeof(*range);
     if ( header_length < (block_length + dev_length) )
     {
         AMD_IOMMU_DEBUG("IVHD Error: Invalid Device_Entry Length!\n");
         return 0;
     }
=20
-    if ( ivhd_device->extended_range.trailer.type !=3D
-         AMD_IOMMU_ACPI_IVHD_DEV_RANGE_END )
+    if ( range->end.header.type !=3D ACPI_IVRS_TYPE_END )
     {
         AMD_IOMMU_DEBUG("IVHD Error: "
                         "Invalid Range: End_Type 0x%x\n",
-                        ivhd_device->extended_range.trailer.type);
+                        range->end.header.type);
         return 0;
     }
=20
-    first_bdf =3D ivhd_device->header.dev_id;
+    first_bdf =3D range->extended.header.id;
     if ( first_bdf >=3D ivrs_bdf_entries )
     {
         AMD_IOMMU_DEBUG("IVHD Error: "
@@ -592,7 +612,7 @@ static u16 __init parse_ivhd_device_exte
         return 0;
     }
=20
-    last_bdf =3D ivhd_device->extended_range.trailer.dev_id;
+    last_bdf =3D range->end.header.id;
     if ( (last_bdf >=3D ivrs_bdf_entries) || (last_bdf <=3D first_bdf) )
     {
         AMD_IOMMU_DEBUG("IVHD Error: "
@@ -604,116 +624,116 @@ static u16 __init parse_ivhd_device_exte
                     first_bdf, last_bdf);
=20
     for ( bdf =3D first_bdf; bdf <=3D last_bdf; bdf++ )
-        add_ivrs_mapping_entry(bdf, bdf, ivhd_device->header.flags, =
iommu);
+        add_ivrs_mapping_entry(bdf, bdf, range->extended.header.data_setti=
ng,
+                               iommu);
=20
     return dev_length;
 }
=20
 static u16 __init parse_ivhd_device_special(
-    union acpi_ivhd_device *ivhd_device, u16 seg,
+    const struct acpi_ivrs_device8c *special, u16 seg,
     u16 header_length, u16 block_length, struct amd_iommu *iommu)
 {
     u16 dev_length, bdf;
=20
-    dev_length =3D sizeof(struct acpi_ivhd_device_special);
+    dev_length =3D sizeof(*special);
     if ( header_length < (block_length + dev_length) )
     {
         AMD_IOMMU_DEBUG("IVHD Error: Invalid Device_Entry Length!\n");
         return 0;
     }
=20
-    bdf =3D ivhd_device->special.dev_id;
+    bdf =3D special->used_id;
     if ( bdf >=3D ivrs_bdf_entries )
     {
         AMD_IOMMU_DEBUG("IVHD Error: Invalid Device_Entry Dev_Id 0x%x\n", =
bdf);
         return 0;
     }
=20
-    add_ivrs_mapping_entry(bdf, bdf, ivhd_device->header.flags, iommu);
+    add_ivrs_mapping_entry(bdf, bdf, special->header.data_setting, =
iommu);
     /* set device id of ioapic */
-    ioapic_sbdf[ivhd_device->special.handle].bdf =3D bdf;
-    ioapic_sbdf[ivhd_device->special.handle].seg =3D seg;
+    ioapic_sbdf[special->handle].bdf =3D bdf;
+    ioapic_sbdf[special->handle].seg =3D seg;
     return dev_length;
 }
=20
-static int __init parse_ivhd_block(struct acpi_ivhd_block_header =
*ivhd_block)
+static int __init parse_ivhd_block(const struct acpi_ivrs_hardware =
*ivhd_block)
 {
-    union acpi_ivhd_device *ivhd_device;
+    const union acpi_ivhd_device *ivhd_device;
     u16 block_length, dev_length;
     struct amd_iommu *iommu;
=20
-    if ( ivhd_block->header.length <
-         sizeof(struct acpi_ivhd_block_header) )
+    if ( ivhd_block->header.length < sizeof(*ivhd_block) )
     {
         AMD_IOMMU_DEBUG("IVHD Error: Invalid Block Length!\n");
         return -ENODEV;
     }
=20
-    iommu =3D find_iommu_from_bdf_cap(ivhd_block->header.dev_id,
-                                    ivhd_block->cap_offset);
+    iommu =3D find_iommu_from_bdf_cap(ivhd_block->header.device_id,
+                                    ivhd_block->capability_offset);
     if ( !iommu )
     {
         AMD_IOMMU_DEBUG("IVHD Error: No IOMMU for Dev_Id 0x%x  Cap =
0x%x\n",
-                        ivhd_block->header.dev_id, ivhd_block->cap_offset)=
;
+                        ivhd_block->header.device_id,
+                        ivhd_block->capability_offset);
         return -ENODEV;
     }
=20
     /* parse Device Entries */
-    block_length =3D sizeof(struct acpi_ivhd_block_header);
+    block_length =3D sizeof(*ivhd_block);
     while ( ivhd_block->header.length >=3D
-            (block_length + sizeof(struct acpi_ivhd_device_header)) )
+            (block_length + sizeof(struct acpi_ivrs_de_header)) )
     {
-        ivhd_device =3D (union acpi_ivhd_device *)
-            ((u8 *)ivhd_block + block_length);
+        ivhd_device =3D (const void *)((const u8 *)ivhd_block + block_leng=
th);
=20
         AMD_IOMMU_DEBUG( "IVHD Device Entry:\n");
         AMD_IOMMU_DEBUG( " Type 0x%x\n", ivhd_device->header.type);
-        AMD_IOMMU_DEBUG( " Dev_Id 0x%x\n", ivhd_device->header.dev_id);
-        AMD_IOMMU_DEBUG( " Flags 0x%x\n", ivhd_device->header.flags);
+        AMD_IOMMU_DEBUG( " Dev_Id 0x%x\n", ivhd_device->header.id);
+        AMD_IOMMU_DEBUG( " Flags 0x%x\n", ivhd_device->header.data_setting=
);
=20
         switch ( ivhd_device->header.type )
         {
-        case AMD_IOMMU_ACPI_IVHD_DEV_U32_PAD:
+        case ACPI_IVRS_TYPE_PAD4:
             dev_length =3D parse_ivhd_device_padding(
                 sizeof(u32),
                 ivhd_block->header.length, block_length);
             break;
-        case AMD_IOMMU_ACPI_IVHD_DEV_U64_PAD:
+        case ACPI_IVRS_TYPE_PAD8:
             dev_length =3D parse_ivhd_device_padding(
                 sizeof(u64),
                 ivhd_block->header.length, block_length);
             break;
-        case AMD_IOMMU_ACPI_IVHD_DEV_SELECT:
-            dev_length =3D parse_ivhd_device_select(ivhd_device, iommu);
+        case ACPI_IVRS_TYPE_SELECT:
+            dev_length =3D parse_ivhd_device_select(&ivhd_device->select, =
iommu);
             break;
-        case AMD_IOMMU_ACPI_IVHD_DEV_RANGE_START:
+        case ACPI_IVRS_TYPE_START:
             dev_length =3D parse_ivhd_device_range(
-                ivhd_device,
+                &ivhd_device->range,
                 ivhd_block->header.length, block_length, iommu);
             break;
-        case AMD_IOMMU_ACPI_IVHD_DEV_ALIAS_SELECT:
+        case ACPI_IVRS_TYPE_ALIAS_SELECT:
             dev_length =3D parse_ivhd_device_alias(
-                ivhd_device,
+                &ivhd_device->alias,
                 ivhd_block->header.length, block_length, iommu);
             break;
-        case AMD_IOMMU_ACPI_IVHD_DEV_ALIAS_RANGE:
+        case ACPI_IVRS_TYPE_ALIAS_START:
             dev_length =3D parse_ivhd_device_alias_range(
-                ivhd_device,
+                &ivhd_device->alias_range,
                 ivhd_block->header.length, block_length, iommu);
             break;
-        case AMD_IOMMU_ACPI_IVHD_DEV_EXT_SELECT:
+        case ACPI_IVRS_TYPE_EXT_SELECT:
             dev_length =3D parse_ivhd_device_extended(
-                ivhd_device,
+                &ivhd_device->extended,
                 ivhd_block->header.length, block_length, iommu);
             break;
-        case AMD_IOMMU_ACPI_IVHD_DEV_EXT_RANGE:
+        case ACPI_IVRS_TYPE_EXT_START:
             dev_length =3D parse_ivhd_device_extended_range(
-                ivhd_device,
+                &ivhd_device->extended_range,
                 ivhd_block->header.length, block_length, iommu);
             break;
-        case AMD_IOMMU_ACPI_IVHD_DEV_SPECIAL:
+        case ACPI_IVRS_TYPE_SPECIAL:
             dev_length =3D parse_ivhd_device_special(
-                ivhd_device, ivhd_block->pci_segment,
+                &ivhd_device->special, ivhd_block->pci_segment_group,
                 ivhd_block->header.length, block_length, iommu);
             break;
         default:
@@ -730,22 +750,24 @@ static int __init parse_ivhd_block(struc
     return 0;
 }
=20
-static int __init parse_ivrs_block(struct acpi_ivrs_block_header =
*ivrs_block)
+static int __init parse_ivrs_block(const struct acpi_ivrs_header =
*ivrs_block)
 {
-    struct acpi_ivhd_block_header *ivhd_block;
-    struct acpi_ivmd_block_header *ivmd_block;
+    const struct acpi_ivrs_hardware *ivhd_block;
+    const struct acpi_ivrs_memory *ivmd_block;
=20
     switch ( ivrs_block->type )
     {
-    case AMD_IOMMU_ACPI_IVHD_TYPE:
-        ivhd_block =3D (struct acpi_ivhd_block_header *)ivrs_block;
+    case ACPI_IVRS_TYPE_HARDWARE:
+        ivhd_block =3D container_of(ivrs_block, const struct acpi_ivrs_har=
dware,
+                                  header);
         return parse_ivhd_block(ivhd_block);
=20
-    case AMD_IOMMU_ACPI_IVMD_ALL_TYPE:
-    case AMD_IOMMU_ACPI_IVMD_ONE_TYPE:
-    case AMD_IOMMU_ACPI_IVMD_RANGE_TYPE:
-    case AMD_IOMMU_ACPI_IVMD_IOMMU_TYPE:
-        ivmd_block =3D (struct acpi_ivmd_block_header *)ivrs_block;
+    case ACPI_IVRS_TYPE_MEMORY_ALL:
+    case ACPI_IVRS_TYPE_MEMORY_ONE:
+    case ACPI_IVRS_TYPE_MEMORY_RANGE:
+    case ACPI_IVRS_TYPE_MEMORY_IOMMU:
+        ivmd_block =3D container_of(ivrs_block, const struct acpi_ivrs_mem=
ory,
+                                  header);
         return parse_ivmd_block(ivmd_block);
=20
     default:
@@ -792,12 +814,11 @@ static void __init dump_acpi_table_heade
=20
 }
=20
-static int __init parse_ivrs_table(struct acpi_table_header *_table)
+static int __init parse_ivrs_table(struct acpi_table_header *table)
 {
-    struct acpi_ivrs_block_header *ivrs_block;
+    const struct acpi_ivrs_header *ivrs_block;
     unsigned long length;
     int error =3D 0;
-    struct acpi_table_header *table =3D (struct acpi_table_header =
*)_table;
=20
     BUG_ON(!table);
=20
@@ -805,17 +826,16 @@ static int __init parse_ivrs_table(struc
         dump_acpi_table_header(table);
=20
     /* parse IVRS blocks */
-    length =3D sizeof(struct acpi_ivrs_table_header);
+    length =3D sizeof(struct acpi_table_ivrs);
     while ( (error =3D=3D 0) && (table->length > (length + sizeof(*ivrs_bl=
ock))) )
     {
-        ivrs_block =3D (struct acpi_ivrs_block_header *)
-            ((u8 *)table + length);
+        ivrs_block =3D (struct acpi_ivrs_header *)((u8 *)table + length);
=20
         AMD_IOMMU_DEBUG("IVRS Block:\n");
         AMD_IOMMU_DEBUG(" Type 0x%x\n", ivrs_block->type);
         AMD_IOMMU_DEBUG(" Flags 0x%x\n", ivrs_block->flags);
         AMD_IOMMU_DEBUG(" Length 0x%x\n", ivrs_block->length);
-        AMD_IOMMU_DEBUG(" Dev_Id 0x%x\n", ivrs_block->dev_id);
+        AMD_IOMMU_DEBUG(" Dev_Id 0x%x\n", ivrs_block->device_id);
=20
         if ( table->length < (length + ivrs_block->length) )
         {
@@ -833,12 +853,11 @@ static int __init parse_ivrs_table(struc
     return error;
 }
=20
-static int __init detect_iommu_acpi(struct acpi_table_header *_table)
+static int __init detect_iommu_acpi(struct acpi_table_header *table)
 {
-    struct acpi_ivrs_block_header *ivrs_block;
-    struct acpi_table_header *table =3D (struct acpi_table_header =
*)_table;
+    const struct acpi_ivrs_header *ivrs_block;
     unsigned long i;
-    unsigned long length =3D sizeof(struct acpi_ivrs_table_header);
+    unsigned long length =3D sizeof(struct acpi_table_ivrs);
     u8 checksum, *raw_table;
=20
     /* validate checksum: sum of entire table =3D=3D 0 */
@@ -854,12 +873,14 @@ static int __init detect_iommu_acpi(stru
=20
     while ( table->length > (length + sizeof(*ivrs_block)) )
     {
-        ivrs_block =3D (struct acpi_ivrs_block_header *) ((u8 *)table + =
length);
+        ivrs_block =3D (struct acpi_ivrs_header *)((u8 *)table + length);
         if ( table->length < (length + ivrs_block->length) )
             return -ENODEV;
-        if ( ivrs_block->type =3D=3D AMD_IOMMU_ACPI_IVHD_TYPE )
-            if ( amd_iommu_detect_one_acpi((void*)ivrs_block) !=3D 0 )
-                return -ENODEV;
+        if ( ivrs_block->type =3D=3D ACPI_IVRS_TYPE_HARDWARE &&
+             amd_iommu_detect_one_acpi(
+                 container_of(ivrs_block, const struct acpi_ivrs_hardware,=

+                              header)) !=3D 0 )
+            return -ENODEV;
         length +=3D ivrs_block->length;
     }
     return 0;
@@ -870,63 +891,59 @@ static int __init detect_iommu_acpi(stru
        last_bdf =3D (x); \
    } while(0);
=20
-static int __init get_last_bdf_ivhd(void *ivhd)
+static int __init get_last_bdf_ivhd(
+    const struct acpi_ivrs_hardware *ivhd_block)
 {
-    union acpi_ivhd_device *ivhd_device;
+    const union acpi_ivhd_device *ivhd_device;
     u16 block_length, dev_length;
-    struct acpi_ivhd_block_header *ivhd_block;
-
-    ivhd_block =3D (struct acpi_ivhd_block_header *)ivhd;
=20
-    if ( ivhd_block->header.length <
-         sizeof(struct acpi_ivhd_block_header) )
+    if ( ivhd_block->header.length < sizeof(*ivhd_block) )
     {
         AMD_IOMMU_DEBUG("IVHD Error: Invalid Block Length!\n");
         return -ENODEV;
     }
=20
-    block_length =3D sizeof(struct acpi_ivhd_block_header);
+    block_length =3D sizeof(*ivhd_block);
     while ( ivhd_block->header.length >=3D
-            (block_length + sizeof(struct acpi_ivhd_device_header)) )
+            (block_length + sizeof(struct acpi_ivrs_de_header)) )
     {
-        ivhd_device =3D (union acpi_ivhd_device *)
-            ((u8 *)ivhd_block + block_length);
+        ivhd_device =3D (const void *)((u8 *)ivhd_block + block_length);
=20
         switch ( ivhd_device->header.type )
         {
-        case AMD_IOMMU_ACPI_IVHD_DEV_U32_PAD:
+        case ACPI_IVRS_TYPE_PAD4:
             dev_length =3D sizeof(u32);
             break;
-        case AMD_IOMMU_ACPI_IVHD_DEV_U64_PAD:
+        case ACPI_IVRS_TYPE_PAD8:
             dev_length =3D sizeof(u64);
             break;
-        case AMD_IOMMU_ACPI_IVHD_DEV_SELECT:
-            UPDATE_LAST_BDF(ivhd_device->header.dev_id);
-            dev_length =3D sizeof(struct acpi_ivhd_device_header);
-            break;
-        case AMD_IOMMU_ACPI_IVHD_DEV_ALIAS_SELECT:
-            UPDATE_LAST_BDF(ivhd_device->header.dev_id);
-            dev_length =3D sizeof(struct acpi_ivhd_device_alias);
-            break;
-        case AMD_IOMMU_ACPI_IVHD_DEV_EXT_SELECT:
-            UPDATE_LAST_BDF(ivhd_device->header.dev_id);
-            dev_length =3D sizeof(struct acpi_ivhd_device_extended);
-            break;
-        case AMD_IOMMU_ACPI_IVHD_DEV_RANGE_START:
-            UPDATE_LAST_BDF(ivhd_device->range.trailer.dev_id);
-            dev_length =3D sizeof(struct acpi_ivhd_device_range);
-            break;
-        case AMD_IOMMU_ACPI_IVHD_DEV_ALIAS_RANGE:
-            UPDATE_LAST_BDF(ivhd_device->alias_range.trailer.dev_id)
-            dev_length =3D sizeof(struct acpi_ivhd_device_alias_range);
-            break;
-        case AMD_IOMMU_ACPI_IVHD_DEV_EXT_RANGE:
-            UPDATE_LAST_BDF(ivhd_device->extended_range.trailer.dev_id)
-            dev_length =3D sizeof(struct acpi_ivhd_device_extended_range);=

-            break;
-        case AMD_IOMMU_ACPI_IVHD_DEV_SPECIAL:
-            UPDATE_LAST_BDF(ivhd_device->special.dev_id)
-            dev_length =3D sizeof(struct acpi_ivhd_device_special);
+        case ACPI_IVRS_TYPE_SELECT:
+            UPDATE_LAST_BDF(ivhd_device->select.header.id);
+            dev_length =3D sizeof(ivhd_device->header);
+            break;
+        case ACPI_IVRS_TYPE_ALIAS_SELECT:
+            UPDATE_LAST_BDF(ivhd_device->alias.header.id);
+            dev_length =3D sizeof(ivhd_device->alias);
+            break;
+        case ACPI_IVRS_TYPE_EXT_SELECT:
+            UPDATE_LAST_BDF(ivhd_device->extended.header.id);
+            dev_length =3D sizeof(ivhd_device->extended);
+            break;
+        case ACPI_IVRS_TYPE_START:
+            UPDATE_LAST_BDF(ivhd_device->range.end.header.id);
+            dev_length =3D sizeof(ivhd_device->range);
+            break;
+        case ACPI_IVRS_TYPE_ALIAS_START:
+            UPDATE_LAST_BDF(ivhd_device->alias_range.end.header.id)
+            dev_length =3D sizeof(ivhd_device->alias_range);
+            break;
+        case ACPI_IVRS_TYPE_EXT_START:
+            UPDATE_LAST_BDF(ivhd_device->extended_range.end.header.id)
+            dev_length =3D sizeof(ivhd_device->extended_range);
+            break;
+        case ACPI_IVRS_TYPE_SPECIAL:
+            UPDATE_LAST_BDF(ivhd_device->special.used_id)
+            dev_length =3D sizeof(ivhd_device->special);
             break;
         default:
             AMD_IOMMU_DEBUG("IVHD Error: Invalid Device Type!\n");
@@ -942,20 +959,21 @@ static int __init get_last_bdf_ivhd(void
     return 0;
 }
=20
-static int __init get_last_bdf_acpi(struct acpi_table_header *_table)
+static int __init get_last_bdf_acpi(struct acpi_table_header *table)
 {
-    struct acpi_ivrs_block_header *ivrs_block;
-    struct acpi_table_header *table =3D (struct acpi_table_header =
*)_table;
-    unsigned long length =3D sizeof(struct acpi_ivrs_table_header);
+    const struct acpi_ivrs_header *ivrs_block;
+    unsigned long length =3D sizeof(struct acpi_table_ivrs);
=20
     while ( table->length > (length + sizeof(*ivrs_block)) )
     {
-        ivrs_block =3D (struct acpi_ivrs_block_header *) ((u8 *)table + =
length);
+        ivrs_block =3D (struct acpi_ivrs_header *)((u8 *)table + length);
         if ( table->length < (length + ivrs_block->length) )
             return -ENODEV;
-        if ( ivrs_block->type =3D=3D AMD_IOMMU_ACPI_IVHD_TYPE )
-            if ( get_last_bdf_ivhd((void*)ivrs_block) !=3D 0 )
-                return -ENODEV;
+        if ( ivrs_block->type =3D=3D ACPI_IVRS_TYPE_HARDWARE &&
+             get_last_bdf_ivhd(
+                 container_of(ivrs_block, const struct acpi_ivrs_hardware,=

+                              header)) !=3D 0 )
+            return -ENODEV;
         length +=3D ivrs_block->length;
     }
    return 0;
@@ -963,16 +981,16 @@ static int __init get_last_bdf_acpi(stru
=20
 int __init amd_iommu_detect_acpi(void)
 {
-    return acpi_table_parse(AMD_IOMMU_ACPI_IVRS_SIG, detect_iommu_acpi);
+    return acpi_table_parse(ACPI_SIG_IVRS, detect_iommu_acpi);
 }
=20
 int __init amd_iommu_get_ivrs_dev_entries(void)
 {
-    acpi_table_parse(AMD_IOMMU_ACPI_IVRS_SIG, get_last_bdf_acpi);
+    acpi_table_parse(ACPI_SIG_IVRS, get_last_bdf_acpi);
     return last_bdf + 1;
 }
=20
 int __init amd_iommu_update_ivrs_mapping_acpi(void)
 {
-    return acpi_table_parse(AMD_IOMMU_ACPI_IVRS_SIG, parse_ivrs_table);
+    return acpi_table_parse(ACPI_SIG_IVRS, parse_ivrs_table);
 }
--- a/xen/drivers/passthrough/amd/iommu_detect.c
+++ b/xen/drivers/passthrough/amd/iommu_detect.c
@@ -20,12 +20,12 @@
=20
 #include <xen/config.h>
 #include <xen/errno.h>
+#include <xen/acpi.h>
 #include <xen/iommu.h>
 #include <xen/pci.h>
 #include <xen/pci_regs.h>
 #include <asm/amd-iommu.h>
 #include <asm/hvm/svm/amd-iommu-proto.h>
-#include <asm/hvm/svm/amd-iommu-acpi.h>
=20
 static int __init get_iommu_msi_capabilities(
     u16 seg, u8 bus, u8 dev, u8 func, struct amd_iommu *iommu)
@@ -103,23 +103,21 @@ void __init get_iommu_features(struct am
     }
 }
=20
-int __init amd_iommu_detect_one_acpi(void *ivhd)
+int __init amd_iommu_detect_one_acpi(
+    const struct acpi_ivrs_hardware *ivhd_block)
 {
     struct amd_iommu *iommu;
     u8 bus, dev, func;
-    struct acpi_ivhd_block_header *ivhd_block;
     int rt =3D 0;
=20
-    ivhd_block =3D (struct acpi_ivhd_block_header *)ivhd;
-
-    if ( ivhd_block->header.length < sizeof(struct acpi_ivhd_block_header)=
 )
+    if ( ivhd_block->header.length < sizeof(*ivhd_block) )
     {
         AMD_IOMMU_DEBUG("Invalid IVHD Block Length!\n");
         return -ENODEV;
     }
=20
-    if ( !ivhd_block->header.dev_id ||
-        !ivhd_block->cap_offset || !ivhd_block->mmio_base)
+    if ( !ivhd_block->header.device_id ||
+        !ivhd_block->capability_offset || !ivhd_block->base_address)
     {
         AMD_IOMMU_DEBUG("Invalid IVHD Block!\n");
         return -ENODEV;
@@ -134,10 +132,10 @@ int __init amd_iommu_detect_one_acpi(voi
=20
     spin_lock_init(&iommu->lock);
=20
-    iommu->seg =3D ivhd_block->pci_segment;
-    iommu->bdf =3D ivhd_block->header.dev_id;
-    iommu->cap_offset =3D ivhd_block->cap_offset;
-    iommu->mmio_base_phys =3D ivhd_block->mmio_base;
+    iommu->seg =3D ivhd_block->pci_segment_group;
+    iommu->bdf =3D ivhd_block->header.device_id;
+    iommu->cap_offset =3D ivhd_block->capability_offset;
+    iommu->mmio_base_phys =3D ivhd_block->base_address;
=20
     /* override IOMMU HT flags */
     iommu->ht_flags =3D ivhd_block->header.flags;
--- a/xen/drivers/passthrough/amd/iommu_init.c
+++ b/xen/drivers/passthrough/amd/iommu_init.c
@@ -20,6 +20,7 @@
=20
 #include <xen/config.h>
 #include <xen/errno.h>
+#include <xen/acpi.h>
 #include <xen/pci.h>
 #include <xen/pci_regs.h>
 #include <xen/irq.h>
@@ -28,7 +29,6 @@
 #include <asm/hvm/svm/amd-iommu-proto.h>
 #include <asm-x86/fixmap.h>
 #include <mach_apic.h>
-#include <asm/hvm/svm/amd-iommu-acpi.h>
=20
 static int __initdata nr_amd_iommus;
=20
@@ -37,9 +37,8 @@ static struct radix_tree_root ivrs_maps;
 struct list_head amd_iommu_head;
 struct table_struct device_table;
=20
-static int iommu_has_ht_flag(struct amd_iommu *iommu, uint8_t bit)
+static int iommu_has_ht_flag(struct amd_iommu *iommu, u8 mask)
 {
-    u8 mask =3D 1U << bit;
     return iommu->ht_flags & mask;
 }
=20
@@ -80,19 +79,19 @@ static void set_iommu_ht_flags(struct am
=20
     /* Setup HT flags */
     if ( iommu_has_cap(iommu, PCI_CAP_HT_TUNNEL_SHIFT) )
-        iommu_has_ht_flag(iommu, AMD_IOMMU_ACPI_HT_TUN_ENB_SHIFT) ?
+        iommu_has_ht_flag(iommu, ACPI_IVHD_TT_ENABLE) ?
             iommu_set_bit(&entry, IOMMU_CONTROL_HT_TUNNEL_TRANSLATION_SHIF=
T) :
             iommu_clear_bit(&entry, IOMMU_CONTROL_HT_TUNNEL_TRANSLATION_SH=
IFT);
=20
-    iommu_has_ht_flag(iommu, AMD_IOMMU_ACPI_RES_PASS_PW_SHIFT) ?
+    iommu_has_ht_flag(iommu, ACPI_IVHD_RES_PASS_PW) ?
         iommu_set_bit(&entry, IOMMU_CONTROL_RESP_PASS_POSTED_WRITE_SHIFT):=

         iommu_clear_bit(&entry, IOMMU_CONTROL_RESP_PASS_POSTED_WRITE_SHIFT=
);
=20
-    iommu_has_ht_flag(iommu, AMD_IOMMU_ACPI_ISOC_SHIFT) ?
+    iommu_has_ht_flag(iommu, ACPI_IVHD_ISOC) ?
         iommu_set_bit(&entry, IOMMU_CONTROL_ISOCHRONOUS_SHIFT):
         iommu_clear_bit(&entry, IOMMU_CONTROL_ISOCHRONOUS_SHIFT);
=20
-    iommu_has_ht_flag(iommu, AMD_IOMMU_ACPI_PASS_PW_SHIFT) ?
+    iommu_has_ht_flag(iommu, ACPI_IVHD_PASS_PW) ?
         iommu_set_bit(&entry, IOMMU_CONTROL_PASS_POSTED_WRITE_SHIFT):
         iommu_clear_bit(&entry, IOMMU_CONTROL_PASS_POSTED_WRITE_SHIFT);
=20
--- a/xen/drivers/passthrough/amd/iommu_map.c
+++ b/xen/drivers/passthrough/amd/iommu_map.c
@@ -18,12 +18,13 @@
  * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307 =
USA
  */
=20
+#include <xen/config.h>
+#include <xen/acpi.h>
 #include <xen/sched.h>
 #include <asm/p2m.h>
 #include <xen/hvm/iommu.h>
 #include <asm/amd-iommu.h>
 #include <asm/hvm/svm/amd-iommu-proto.h>
-#include <asm/hvm/svm/amd-iommu-acpi.h>
 #include "../ats.h"
 #include <xen/pci.h>
=20
@@ -215,8 +216,7 @@ void __init iommu_dte_add_device_entry(u
     dte[7] =3D dte[6] =3D dte[4] =3D dte[2] =3D dte[1] =3D dte[0] =3D 0;
=20
     flags =3D ivrs_dev->device_flags;
-    sys_mgt =3D get_field_from_byte(flags, AMD_IOMMU_ACPI_SYS_MGT_MASK,
-                                  AMD_IOMMU_ACPI_SYS_MGT_SHIFT);
+    sys_mgt =3D get_field_from_byte(flags, ACPI_IVHD_SYSTEM_MGMT);
     dev_ex =3D ivrs_dev->dte_allow_exclusion;
=20
     flags &=3D mask;
--- a/xen/include/asm-x86/hvm/svm/amd-iommu-acpi.h
+++ /dev/null
@@ -1,185 +0,0 @@
-/*
- * Copyright (C) 2007 Advanced Micro Devices, Inc.
- * Author: Leo Duran <leo.duran@amd.com>
- * Author: Wei Wang <wei.wang2@amd.com> - adapted to xen
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307 =
USA
- */
-
-#ifndef _ASM_X86_64_AMD_IOMMU_ACPI_H
-#define _ASM_X86_64_AMD_IOMMU_ACPI_H
-
-#include <xen/acpi.h>
-
-/* I/O Virtualization Reporting Structure */
-#define AMD_IOMMU_ACPI_IVRS_SIG            "IVRS"
-#define AMD_IOMMU_ACPI_IVHD_TYPE       0x10
-#define AMD_IOMMU_ACPI_IVMD_ALL_TYPE       0x20
-#define AMD_IOMMU_ACPI_IVMD_ONE_TYPE       0x21
-#define AMD_IOMMU_ACPI_IVMD_RANGE_TYPE     0x22
-#define AMD_IOMMU_ACPI_IVMD_IOMMU_TYPE     0x23
-
-/* 4-byte Device Entries */
-#define AMD_IOMMU_ACPI_IVHD_DEV_U32_PAD        0
-#define AMD_IOMMU_ACPI_IVHD_DEV_SELECT     2
-#define AMD_IOMMU_ACPI_IVHD_DEV_RANGE_START    3
-#define AMD_IOMMU_ACPI_IVHD_DEV_RANGE_END  4
-
-/* 8-byte Device Entries */
-#define AMD_IOMMU_ACPI_IVHD_DEV_U64_PAD        64
-#define AMD_IOMMU_ACPI_IVHD_DEV_ALIAS_SELECT   66
-#define AMD_IOMMU_ACPI_IVHD_DEV_ALIAS_RANGE    67
-#define AMD_IOMMU_ACPI_IVHD_DEV_EXT_SELECT 70
-#define AMD_IOMMU_ACPI_IVHD_DEV_EXT_RANGE  71
-#define AMD_IOMMU_ACPI_IVHD_DEV_SPECIAL    72
-
-/* IVHD IOMMU Flags */
-#define AMD_IOMMU_ACPI_COHERENT_MASK       0x20
-#define AMD_IOMMU_ACPI_COHERENT_SHIFT      5
-#define AMD_IOMMU_ACPI_IOTLB_SUP_MASK      0x10
-#define AMD_IOMMU_ACPI_IOTLB_SUP_SHIFT     4
-#define AMD_IOMMU_ACPI_ISOC_MASK       0x08
-#define AMD_IOMMU_ACPI_ISOC_SHIFT      3
-#define AMD_IOMMU_ACPI_RES_PASS_PW_MASK        0x04
-#define AMD_IOMMU_ACPI_RES_PASS_PW_SHIFT   2
-#define AMD_IOMMU_ACPI_PASS_PW_MASK        0x02
-#define AMD_IOMMU_ACPI_PASS_PW_SHIFT       1
-#define AMD_IOMMU_ACPI_HT_TUN_ENB_MASK     0x01
-#define AMD_IOMMU_ACPI_HT_TUN_ENB_SHIFT        0
-
-/* IVHD Device Flags */
-#define AMD_IOMMU_ACPI_LINT1_PASS_MASK     0x80
-#define AMD_IOMMU_ACPI_LINT1_PASS_SHIFT        7
-#define AMD_IOMMU_ACPI_LINT0_PASS_MASK     0x40
-#define AMD_IOMMU_ACPI_LINT0_PASS_SHIFT        6
-#define AMD_IOMMU_ACPI_SYS_MGT_MASK        0x30
-#define AMD_IOMMU_ACPI_SYS_MGT_SHIFT       4
-#define AMD_IOMMU_ACPI_NMI_PASS_MASK       0x04
-#define AMD_IOMMU_ACPI_NMI_PASS_SHIFT      2
-#define AMD_IOMMU_ACPI_EINT_PASS_MASK      0x02
-#define AMD_IOMMU_ACPI_EINT_PASS_SHIFT     1
-#define AMD_IOMMU_ACPI_INIT_PASS_MASK      0x01
-#define AMD_IOMMU_ACPI_INIT_PASS_SHIFT     0
-
-/* IVHD Device Extended Flags */
-#define AMD_IOMMU_ACPI_ATS_DISABLED_MASK   0x80000000
-#define AMD_IOMMU_ACPI_ATS_DISABLED_SHIFT  31
-
-/* IVMD Device Flags */
-#define AMD_IOMMU_ACPI_EXCLUSION_RANGE_MASK    0x08
-#define AMD_IOMMU_ACPI_EXCLUSION_RANGE_SHIFT   3
-#define AMD_IOMMU_ACPI_IW_PERMISSION_MASK  0x04
-#define AMD_IOMMU_ACPI_IW_PERMISSION_SHIFT 2
-#define AMD_IOMMU_ACPI_IR_PERMISSION_MASK  0x02
-#define AMD_IOMMU_ACPI_IR_PERMISSION_SHIFT 1
-#define AMD_IOMMU_ACPI_UNITY_MAPPING_MASK  0x01
-#define AMD_IOMMU_ACPI_UNITY_MAPPING_SHIFT 0
-
-#define ACPI_OEM_ID_SIZE                6
-#define ACPI_OEM_TABLE_ID_SIZE          8
-
-#pragma pack(1)
-struct acpi_ivrs_table_header {
-   struct acpi_table_header acpi_header;
-   u32 io_info;
-   u8  reserved[8];
-};
-
-struct acpi_ivrs_block_header {
-   u8  type;
-   u8  flags;
-   u16 length;
-   u16 dev_id;
-};
-
-struct acpi_ivhd_block_header {
-   struct acpi_ivrs_block_header header;
-   u16 cap_offset;
-   u64 mmio_base;
-   u16 pci_segment;
-   u16 iommu_info;
-   u8 reserved[4];
-};
-
-struct acpi_ivhd_device_header {
-   u8  type;
-   u16 dev_id;
-   u8  flags;
-};
-
-struct acpi_ivhd_device_trailer {
-   u8  type;
-   u16 dev_id;
-   u8  reserved;
-};
-
-struct acpi_ivhd_device_range {
-   struct acpi_ivhd_device_header header;
-   struct acpi_ivhd_device_trailer trailer;
-};
-
-struct acpi_ivhd_device_alias {
-   struct acpi_ivhd_device_header header;
-   u8  reserved1;
-   u16 dev_id;
-   u8  reserved2;
-};
-
-struct acpi_ivhd_device_alias_range {
-   struct acpi_ivhd_device_alias alias;
-   struct acpi_ivhd_device_trailer trailer;
-};
-
-struct acpi_ivhd_device_extended {
-   struct acpi_ivhd_device_header header;
-   u32 ext_flags;
-};
-
-struct acpi_ivhd_device_extended_range {
-   struct acpi_ivhd_device_extended extended;
-   struct acpi_ivhd_device_trailer trailer;
-};
-
-struct acpi_ivhd_device_special {
-   struct acpi_ivhd_device_header header;
-   u8  handle;
-   u16 dev_id;
-   u8  variety;
-};
-
-union acpi_ivhd_device {
-   struct acpi_ivhd_device_header header;
-   struct acpi_ivhd_device_range range;
-   struct acpi_ivhd_device_alias alias;
-   struct acpi_ivhd_device_alias_range alias_range;
-   struct acpi_ivhd_device_extended extended;
-   struct acpi_ivhd_device_extended_range extended_range;
-   struct acpi_ivhd_device_special special;
-};
-
-struct acpi_ivmd_block_header {
-   struct acpi_ivrs_block_header header;
-   union {
-       u16 last_dev_id;
-       u16 cap_offset;
-       u16 reserved1;
-   };
-   u64 reserved2;
-   u64 start_addr;
-   u64 mem_length;
-};
-#pragma pack()
-
-#endif /* _ASM_X86_64_AMD_IOMMU_ACPI_H */
--- a/xen/include/asm-x86/hvm/svm/amd-iommu-proto.h
+++ b/xen/include/asm-x86/hvm/svm/amd-iommu-proto.h
@@ -26,6 +26,8 @@
 #include <asm/apicdef.h>
 #include <xen/domain_page.h>
=20
+struct acpi_ivrs_hardware;
+
 #define for_each_amd_iommu(amd_iommu) \
     list_for_each_entry(amd_iommu, \
         &amd_iommu_head, list)
@@ -41,7 +43,7 @@
=20
 /* amd-iommu-detect functions */
 int amd_iommu_get_ivrs_dev_entries(void);
-int amd_iommu_detect_one_acpi(void *ivhd);
+int amd_iommu_detect_one_acpi(const struct acpi_ivrs_hardware *);
 int amd_iommu_detect_acpi(void);
 void get_iommu_features(struct amd_iommu *iommu);
=20
@@ -121,11 +123,9 @@ static inline u32 set_field_in_reg_u32(u
     return reg_value;
 }
=20
-static inline u8 get_field_from_byte(u8 value, u8 mask, u8 shift)
+static inline u8 get_field_from_byte(u8 value, u8 mask)
 {
-    u8 field;
-    field =3D (value & mask) >> shift;
-    return field;
+    return (value & mask) / (mask & -mask);
 }
=20
 static inline unsigned long region_to_pages(unsigned long addr, unsigned =
long size)



--=__Part456AE0A2.0__=
Content-Type: text/plain; name="acpi-duplicate-ivrs-structs.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="acpi-duplicate-ivrs-structs.patch"

ACPI: eliminate duplicate IVRS definitions=0A=0AUse their proper counterpar=
ts in include/acpi/actbl*.h instead.=0A=0ASigned-off-by: Jan Beulich =
<jbeulich@suse.com>=0A=0A--- a/xen/drivers/passthrough/amd/iommu_acpi.c=0A+=
++ b/xen/drivers/passthrough/amd/iommu_acpi.c=0A@@ -20,10 +20,38 @@=0A =0A =
#include <xen/config.h>=0A #include <xen/errno.h>=0A+#include <xen/acpi.h>=
=0A #include <asm/apicdef.h>=0A #include <asm/amd-iommu.h>=0A #include =
<asm/hvm/svm/amd-iommu-proto.h>=0A-#include <asm/hvm/svm/amd-iommu-acpi.h>=
=0A+=0A+/* Some helper structures, particularly to deal with ranges. =
*/=0A+=0A+struct acpi_ivhd_device_range {=0A+   struct acpi_ivrs_device4 =
start;=0A+   struct acpi_ivrs_device4 end;=0A+};=0A+=0A+struct acpi_ivhd_de=
vice_alias_range {=0A+   struct acpi_ivrs_device8a alias;=0A+   struct =
acpi_ivrs_device4 end;=0A+};=0A+=0A+struct acpi_ivhd_device_extended_range =
{=0A+   struct acpi_ivrs_device8b extended;=0A+   struct acpi_ivrs_device4 =
end;=0A+};=0A+=0A+union acpi_ivhd_device {=0A+   struct acpi_ivrs_de_header=
 header;=0A+   struct acpi_ivrs_device4 select;=0A+   struct acpi_ivhd_devi=
ce_range range;=0A+   struct acpi_ivrs_device8a alias;=0A+   struct =
acpi_ivhd_device_alias_range alias_range;=0A+   struct acpi_ivrs_device8b =
extended;=0A+   struct acpi_ivhd_device_extended_range extended_range;=0A+ =
  struct acpi_ivrs_device8c special;=0A+};=0A =0A static unsigned short =
__initdata last_bdf;=0A =0A@@ -242,12 +270,12 @@ static int __init =
register_exclusion_ran=0A }=0A =0A static int __init parse_ivmd_device_sele=
ct(=0A-    struct acpi_ivmd_block_header *ivmd_block,=0A+    const struct =
acpi_ivrs_memory *ivmd_block,=0A     unsigned long base, unsigned long =
limit, u8 iw, u8 ir)=0A {=0A     u16 bdf;=0A =0A-    bdf =3D ivmd_block->he=
ader.dev_id;=0A+    bdf =3D ivmd_block->header.device_id;=0A     if ( bdf =
>=3D ivrs_bdf_entries )=0A     {=0A         AMD_IOMMU_DEBUG("IVMD Error: =
Invalid Dev_Id 0x%x\n", bdf);=0A@@ -258,13 +286,13 @@ static int __init =
parse_ivmd_device_sele=0A }=0A =0A static int __init parse_ivmd_device_rang=
e(=0A-    struct acpi_ivmd_block_header *ivmd_block,=0A+    const struct =
acpi_ivrs_memory *ivmd_block,=0A     unsigned long base, unsigned long =
limit, u8 iw, u8 ir)=0A {=0A     u16 first_bdf, last_bdf, bdf;=0A     int =
error;=0A =0A-    first_bdf =3D ivmd_block->header.dev_id;=0A+    =
first_bdf =3D ivmd_block->header.device_id;=0A     if ( first_bdf >=3D =
ivrs_bdf_entries )=0A     {=0A         AMD_IOMMU_DEBUG("IVMD Error: "=0A@@ =
-272,7 +300,7 @@ static int __init parse_ivmd_device_rang=0A         =
return -ENODEV;=0A     }=0A =0A-    last_bdf =3D ivmd_block->last_dev_id;=
=0A+    last_bdf =3D ivmd_block->aux_data;=0A     if ( (last_bdf >=3D =
ivrs_bdf_entries) || (last_bdf <=3D first_bdf) )=0A     {=0A         =
AMD_IOMMU_DEBUG("IVMD Error: "=0A@@ -288,18 +316,18 @@ static int __init =
parse_ivmd_device_rang=0A }=0A =0A static int __init parse_ivmd_device_iomm=
u(=0A-    struct acpi_ivmd_block_header *ivmd_block,=0A+    const struct =
acpi_ivrs_memory *ivmd_block,=0A     unsigned long base, unsigned long =
limit, u8 iw, u8 ir)=0A {=0A     struct amd_iommu *iommu;=0A =0A     /* =
find target IOMMU */=0A-    iommu =3D find_iommu_from_bdf_cap(ivmd_block->h=
eader.dev_id,=0A-                                    ivmd_block->cap_offset=
);=0A+    iommu =3D find_iommu_from_bdf_cap(ivmd_block->header.device_id,=
=0A+                                    ivmd_block->aux_data);=0A     if ( =
!iommu )=0A     {=0A         AMD_IOMMU_DEBUG("IVMD Error: No IOMMU for =
Dev_Id 0x%x  Cap 0x%x\n",=0A-                        ivmd_block->header.dev=
_id, ivmd_block->cap_offset);=0A+                        ivmd_block->header=
.device_id, ivmd_block->aux_data);=0A         return -ENODEV;=0A     }=0A =
=0A@@ -307,20 +335,19 @@ static int __init parse_ivmd_device_iomm=0A       =
  iommu, base, limit, iw, ir);=0A }=0A =0A-static int __init parse_ivmd_blo=
ck(struct acpi_ivmd_block_header *ivmd_block)=0A+static int __init =
parse_ivmd_block(const struct acpi_ivrs_memory *ivmd_block)=0A {=0A     =
unsigned long start_addr, mem_length, base, limit;=0A     u8 iw, ir;=0A =
=0A-    if ( ivmd_block->header.length <=0A-         sizeof(struct =
acpi_ivmd_block_header) )=0A+    if ( ivmd_block->header.length < =
sizeof(*ivmd_block) )=0A     {=0A         AMD_IOMMU_DEBUG("IVMD Error: =
Invalid Block Length!\n");=0A         return -ENODEV;=0A     }=0A =0A-    =
start_addr =3D (unsigned long)ivmd_block->start_addr;=0A-    mem_length =
=3D (unsigned long)ivmd_block->mem_length;=0A+    start_addr =3D (unsigned =
long)ivmd_block->start_address;=0A+    mem_length =3D (unsigned long)ivmd_b=
lock->memory_length;=0A     base =3D start_addr & PAGE_MASK;=0A     limit =
=3D (start_addr + mem_length - 1) & PAGE_MASK;=0A =0A@@ -328,20 +355,14 @@ =
static int __init parse_ivmd_block(struc=0A     AMD_IOMMU_DEBUG(" =
Start_Addr_Phys 0x%lx\n", start_addr);=0A     AMD_IOMMU_DEBUG(" Mem_Length =
0x%lx\n", mem_length);=0A =0A-    if ( get_field_from_byte(ivmd_block->head=
er.flags,=0A-                             AMD_IOMMU_ACPI_EXCLUSION_RANGE_MA=
SK,=0A-                             AMD_IOMMU_ACPI_EXCLUSION_RANGE_SHIFT) =
)=0A+    if ( ivmd_block->header.flags & ACPI_IVMD_EXCLUSION_RANGE )=0A    =
     iw =3D ir =3D IOMMU_CONTROL_ENABLED;=0A-    else if ( get_field_from_b=
yte(ivmd_block->header.flags,=0A-                                  =
AMD_IOMMU_ACPI_UNITY_MAPPING_MASK,=0A-                                  =
AMD_IOMMU_ACPI_UNITY_MAPPING_SHIFT) )=0A-    {=0A-        iw =3D get_field_=
from_byte(ivmd_block->header.flags,=0A-                                 =
AMD_IOMMU_ACPI_IW_PERMISSION_MASK,=0A-                                 =
AMD_IOMMU_ACPI_IW_PERMISSION_SHIFT);=0A-        ir =3D get_field_from_byte(=
ivmd_block->header.flags,=0A-                                 AMD_IOMMU_ACP=
I_IR_PERMISSION_MASK,=0A-                                 AMD_IOMMU_ACPI_IR=
_PERMISSION_SHIFT);=0A+    else if ( ivmd_block->header.flags & ACPI_IVMD_U=
NITY )=0A+    {=0A+        iw =3D ivmd_block->header.flags & ACPI_IVMD_READ=
 ?=0A+            IOMMU_CONTROL_ENABLED : IOMMU_CONTROL_DISABLED;=0A+      =
  ir =3D ivmd_block->header.flags & ACPI_IVMD_WRITE ?=0A+            =
IOMMU_CONTROL_ENABLED : IOMMU_CONTROL_DISABLED;=0A     }=0A     else=0A    =
 {=0A@@ -351,19 +372,19 @@ static int __init parse_ivmd_block(struc=0A =0A =
    switch( ivmd_block->header.type )=0A     {=0A-    case AMD_IOMMU_ACPI_I=
VMD_ALL_TYPE:=0A+    case ACPI_IVRS_TYPE_MEMORY_ALL:=0A         return =
register_exclusion_range_for_all_devices(=0A             base, limit, iw, =
ir);=0A =0A-    case AMD_IOMMU_ACPI_IVMD_ONE_TYPE:=0A+    case ACPI_IVRS_TY=
PE_MEMORY_ONE:=0A         return parse_ivmd_device_select(ivmd_block,=0A   =
                                      base, limit, iw, ir);=0A =0A-    =
case AMD_IOMMU_ACPI_IVMD_RANGE_TYPE:=0A+    case ACPI_IVRS_TYPE_MEMORY_RANG=
E:=0A         return parse_ivmd_device_range(ivmd_block,=0A                =
                        base, limit, iw, ir);=0A =0A-    case AMD_IOMMU_ACP=
I_IVMD_IOMMU_TYPE:=0A+    case ACPI_IVRS_TYPE_MEMORY_IOMMU:=0A         =
return parse_ivmd_device_iommu(ivmd_block,=0A                              =
          base, limit, iw, ir);=0A =0A@@ -386,45 +407,44 @@ static u16 =
__init parse_ivhd_device_padd=0A }=0A =0A static u16 __init parse_ivhd_devi=
ce_select(=0A-    union acpi_ivhd_device *ivhd_device, struct amd_iommu =
*iommu)=0A+    const struct acpi_ivrs_device4 *select, struct amd_iommu =
*iommu)=0A {=0A     u16 bdf;=0A =0A-    bdf =3D ivhd_device->header.dev_id;=
=0A+    bdf =3D select->header.id;=0A     if ( bdf >=3D ivrs_bdf_entries =
)=0A     {=0A         AMD_IOMMU_DEBUG("IVHD Error: Invalid Device_Entry =
Dev_Id 0x%x\n", bdf);=0A         return 0;=0A     }=0A =0A-    add_ivrs_map=
ping_entry(bdf, bdf, ivhd_device->header.flags, iommu);=0A+    add_ivrs_map=
ping_entry(bdf, bdf, select->header.data_setting, iommu);=0A =0A-    =
return sizeof(struct acpi_ivhd_device_header);=0A+    return sizeof(*select=
);=0A }=0A =0A static u16 __init parse_ivhd_device_range(=0A-    union =
acpi_ivhd_device *ivhd_device,=0A+    const struct acpi_ivhd_device_range =
*range,=0A     u16 header_length, u16 block_length, struct amd_iommu =
*iommu)=0A {=0A     u16 dev_length, first_bdf, last_bdf, bdf;=0A =0A-    =
dev_length =3D sizeof(struct acpi_ivhd_device_range);=0A+    dev_length =
=3D sizeof(*range);=0A     if ( header_length < (block_length + dev_length)=
 )=0A     {=0A         AMD_IOMMU_DEBUG("IVHD Error: Invalid Device_Entry =
Length!\n");=0A         return 0;=0A     }=0A =0A-    if ( ivhd_device->ran=
ge.trailer.type !=3D=0A-         AMD_IOMMU_ACPI_IVHD_DEV_RANGE_END )=0A+   =
 if ( range->end.header.type !=3D ACPI_IVRS_TYPE_END )=0A     {=0A         =
AMD_IOMMU_DEBUG("IVHD Error: "=0A                         "Invalid Range: =
End_Type 0x%x\n",=0A-                        ivhd_device->range.trailer.typ=
e);=0A+                        range->end.header.type);=0A         return =
0;=0A     }=0A =0A-    first_bdf =3D ivhd_device->header.dev_id;=0A+    =
first_bdf =3D range->start.header.id;=0A     if ( first_bdf >=3D ivrs_bdf_e=
ntries )=0A     {=0A         AMD_IOMMU_DEBUG("IVHD Error: "=0A@@ -432,7 =
+452,7 @@ static u16 __init parse_ivhd_device_rang=0A         return 0;=0A =
    }=0A =0A-    last_bdf =3D ivhd_device->range.trailer.dev_id;=0A+    =
last_bdf =3D range->end.header.id;=0A     if ( (last_bdf >=3D ivrs_bdf_entr=
ies) || (last_bdf <=3D first_bdf) )=0A     {=0A         AMD_IOMMU_DEBUG("IV=
HD Error: "=0A@@ -443,32 +463,33 @@ static u16 __init parse_ivhd_device_ran=
g=0A     AMD_IOMMU_DEBUG(" Dev_Id Range: 0x%x -> 0x%x\n", first_bdf, =
last_bdf);=0A =0A     for ( bdf =3D first_bdf; bdf <=3D last_bdf; bdf++ =
)=0A-        add_ivrs_mapping_entry(bdf, bdf, ivhd_device->header.flags, =
iommu);=0A+        add_ivrs_mapping_entry(bdf, bdf, range->start.header.dat=
a_setting,=0A+                               iommu);=0A =0A     return =
dev_length;=0A }=0A =0A static u16 __init parse_ivhd_device_alias(=0A-    =
union acpi_ivhd_device *ivhd_device,=0A+    const struct acpi_ivrs_device8a=
 *alias,=0A     u16 header_length, u16 block_length, struct amd_iommu =
*iommu)=0A {=0A     u16 dev_length, alias_id, bdf;=0A =0A-    dev_length =
=3D sizeof(struct acpi_ivhd_device_alias);=0A+    dev_length =3D sizeof(*al=
ias);=0A     if ( header_length < (block_length + dev_length) )=0A     =
{=0A         AMD_IOMMU_DEBUG("IVHD Error: Invalid Device_Entry Length!\n");=
=0A         return 0;=0A     }=0A =0A-    bdf =3D ivhd_device->header.dev_i=
d;=0A+    bdf =3D alias->header.id;=0A     if ( bdf >=3D ivrs_bdf_entries =
)=0A     {=0A         AMD_IOMMU_DEBUG("IVHD Error: Invalid Device_Entry =
Dev_Id 0x%x\n", bdf);=0A         return 0;=0A     }=0A =0A-    alias_id =
=3D ivhd_device->alias.dev_id;=0A+    alias_id =3D alias->used_id;=0A     =
if ( alias_id >=3D ivrs_bdf_entries )=0A     {=0A         AMD_IOMMU_DEBUG("=
IVHD Error: Invalid Alias Dev_Id 0x%x\n", alias_id);=0A@@ -477,35 +498,34 =
@@ static u16 __init parse_ivhd_device_alia=0A =0A     AMD_IOMMU_DEBUG(" =
Dev_Id Alias: 0x%x\n", alias_id);=0A =0A-    add_ivrs_mapping_entry(bdf, =
alias_id, ivhd_device->header.flags, iommu);=0A+    add_ivrs_mapping_entry(=
bdf, alias_id, alias->header.data_setting, iommu);=0A =0A     return =
dev_length;=0A }=0A =0A static u16 __init parse_ivhd_device_alias_range(=0A=
-    union acpi_ivhd_device *ivhd_device,=0A+    const struct acpi_ivhd_dev=
ice_alias_range *range,=0A     u16 header_length, u16 block_length, struct =
amd_iommu *iommu)=0A {=0A =0A     u16 dev_length, first_bdf, last_bdf, =
alias_id, bdf;=0A =0A-    dev_length =3D sizeof(struct acpi_ivhd_device_ali=
as_range);=0A+    dev_length =3D sizeof(*range);=0A     if ( header_length =
< (block_length + dev_length) )=0A     {=0A         AMD_IOMMU_DEBUG("IVHD =
Error: Invalid Device_Entry Length!\n");=0A         return 0;=0A     }=0A =
=0A-    if ( ivhd_device->alias_range.trailer.type !=3D=0A-         =
AMD_IOMMU_ACPI_IVHD_DEV_RANGE_END )=0A+    if ( range->end.header.type =
!=3D ACPI_IVRS_TYPE_END )=0A     {=0A         AMD_IOMMU_DEBUG("IVHD Error: =
"=0A                         "Invalid Range: End_Type 0x%x\n",=0A-         =
               ivhd_device->alias_range.trailer.type);=0A+                 =
       range->end.header.type);=0A         return 0;=0A     }=0A =0A-    =
first_bdf =3D ivhd_device->header.dev_id;=0A+    first_bdf =3D range->alias=
.header.id;=0A     if ( first_bdf >=3D ivrs_bdf_entries )=0A     {=0A      =
   AMD_IOMMU_DEBUG("IVHD Error: "=0A@@ -513,7 +533,7 @@ static u16 __init =
parse_ivhd_device_alia=0A         return 0;=0A     }=0A =0A-    last_bdf =
=3D ivhd_device->alias_range.trailer.dev_id;=0A+    last_bdf =3D range->end=
.header.id;=0A     if ( last_bdf >=3D ivrs_bdf_entries || last_bdf <=3D =
first_bdf )=0A     {=0A         AMD_IOMMU_DEBUG(=0A@@ -521,7 +541,7 @@ =
static u16 __init parse_ivhd_device_alia=0A         return 0;=0A     }=0A =
=0A-    alias_id =3D ivhd_device->alias_range.alias.dev_id;=0A+    =
alias_id =3D range->alias.used_id;=0A     if ( alias_id >=3D ivrs_bdf_entri=
es )=0A     {=0A         AMD_IOMMU_DEBUG("IVHD Error: Invalid Alias Dev_Id =
0x%x\n", alias_id);=0A@@ -532,59 +552,59 @@ static u16 __init parse_ivhd_de=
vice_alia=0A     AMD_IOMMU_DEBUG(" Dev_Id Alias: 0x%x\n", alias_id);=0A =
=0A     for ( bdf =3D first_bdf; bdf <=3D last_bdf; bdf++ )=0A-        =
add_ivrs_mapping_entry(bdf, alias_id, ivhd_device->header.flags, iommu);=0A=
+        add_ivrs_mapping_entry(bdf, alias_id, range->alias.header.data_set=
ting,=0A+                               iommu);=0A =0A     return =
dev_length;=0A }=0A =0A static u16 __init parse_ivhd_device_extended(=0A-  =
  union acpi_ivhd_device *ivhd_device,=0A+    const struct acpi_ivrs_device=
8b *ext,=0A     u16 header_length, u16 block_length, struct amd_iommu =
*iommu)=0A {=0A     u16 dev_length, bdf;=0A =0A-    dev_length =3D =
sizeof(struct acpi_ivhd_device_extended);=0A+    dev_length =3D sizeof(*ext=
);=0A     if ( header_length < (block_length + dev_length) )=0A     {=0A   =
      AMD_IOMMU_DEBUG("IVHD Error: Invalid Device_Entry Length!\n");=0A    =
     return 0;=0A     }=0A =0A-    bdf =3D ivhd_device->header.dev_id;=0A+ =
   bdf =3D ext->header.id;=0A     if ( bdf >=3D ivrs_bdf_entries )=0A     =
{=0A         AMD_IOMMU_DEBUG("IVHD Error: Invalid Device_Entry Dev_Id =
0x%x\n", bdf);=0A         return 0;=0A     }=0A =0A-    add_ivrs_mapping_en=
try(bdf, bdf, ivhd_device->header.flags, iommu);=0A+    add_ivrs_mapping_en=
try(bdf, bdf, ext->header.data_setting, iommu);=0A =0A     return =
dev_length;=0A }=0A =0A static u16 __init parse_ivhd_device_extended_range(=
=0A-    union acpi_ivhd_device *ivhd_device,=0A+    const struct acpi_ivhd_=
device_extended_range *range,=0A     u16 header_length, u16 block_length, =
struct amd_iommu *iommu)=0A {=0A     u16 dev_length, first_bdf, last_bdf, =
bdf;=0A =0A-    dev_length =3D sizeof(struct acpi_ivhd_device_extended_rang=
e);=0A+    dev_length =3D sizeof(*range);=0A     if ( header_length < =
(block_length + dev_length) )=0A     {=0A         AMD_IOMMU_DEBUG("IVHD =
Error: Invalid Device_Entry Length!\n");=0A         return 0;=0A     }=0A =
=0A-    if ( ivhd_device->extended_range.trailer.type !=3D=0A-         =
AMD_IOMMU_ACPI_IVHD_DEV_RANGE_END )=0A+    if ( range->end.header.type =
!=3D ACPI_IVRS_TYPE_END )=0A     {=0A         AMD_IOMMU_DEBUG("IVHD Error: =
"=0A                         "Invalid Range: End_Type 0x%x\n",=0A-         =
               ivhd_device->extended_range.trailer.type);=0A+              =
          range->end.header.type);=0A         return 0;=0A     }=0A =0A-   =
 first_bdf =3D ivhd_device->header.dev_id;=0A+    first_bdf =3D range->exte=
nded.header.id;=0A     if ( first_bdf >=3D ivrs_bdf_entries )=0A     {=0A  =
       AMD_IOMMU_DEBUG("IVHD Error: "=0A@@ -592,7 +612,7 @@ static u16 =
__init parse_ivhd_device_exte=0A         return 0;=0A     }=0A =0A-    =
last_bdf =3D ivhd_device->extended_range.trailer.dev_id;=0A+    last_bdf =
=3D range->end.header.id;=0A     if ( (last_bdf >=3D ivrs_bdf_entries) || =
(last_bdf <=3D first_bdf) )=0A     {=0A         AMD_IOMMU_DEBUG("IVHD =
Error: "=0A@@ -604,116 +624,116 @@ static u16 __init parse_ivhd_device_exte=
=0A                     first_bdf, last_bdf);=0A =0A     for ( bdf =3D =
first_bdf; bdf <=3D last_bdf; bdf++ )=0A-        add_ivrs_mapping_entry(bdf=
, bdf, ivhd_device->header.flags, iommu);=0A+        add_ivrs_mapping_entry=
(bdf, bdf, range->extended.header.data_setting,=0A+                        =
       iommu);=0A =0A     return dev_length;=0A }=0A =0A static u16 __init =
parse_ivhd_device_special(=0A-    union acpi_ivhd_device *ivhd_device, u16 =
seg,=0A+    const struct acpi_ivrs_device8c *special, u16 seg,=0A     u16 =
header_length, u16 block_length, struct amd_iommu *iommu)=0A {=0A     u16 =
dev_length, bdf;=0A =0A-    dev_length =3D sizeof(struct acpi_ivhd_device_s=
pecial);=0A+    dev_length =3D sizeof(*special);=0A     if ( header_length =
< (block_length + dev_length) )=0A     {=0A         AMD_IOMMU_DEBUG("IVHD =
Error: Invalid Device_Entry Length!\n");=0A         return 0;=0A     }=0A =
=0A-    bdf =3D ivhd_device->special.dev_id;=0A+    bdf =3D special->used_i=
d;=0A     if ( bdf >=3D ivrs_bdf_entries )=0A     {=0A         AMD_IOMMU_DE=
BUG("IVHD Error: Invalid Device_Entry Dev_Id 0x%x\n", bdf);=0A         =
return 0;=0A     }=0A =0A-    add_ivrs_mapping_entry(bdf, bdf, ivhd_device-=
>header.flags, iommu);=0A+    add_ivrs_mapping_entry(bdf, bdf, special->hea=
der.data_setting, iommu);=0A     /* set device id of ioapic */=0A-    =
ioapic_sbdf[ivhd_device->special.handle].bdf =3D bdf;=0A-    ioapic_sbdf[iv=
hd_device->special.handle].seg =3D seg;=0A+    ioapic_sbdf[special->handle]=
.bdf =3D bdf;=0A+    ioapic_sbdf[special->handle].seg =3D seg;=0A     =
return dev_length;=0A }=0A =0A-static int __init parse_ivhd_block(struct =
acpi_ivhd_block_header *ivhd_block)=0A+static int __init parse_ivhd_block(c=
onst struct acpi_ivrs_hardware *ivhd_block)=0A {=0A-    union acpi_ivhd_dev=
ice *ivhd_device;=0A+    const union acpi_ivhd_device *ivhd_device;=0A     =
u16 block_length, dev_length;=0A     struct amd_iommu *iommu;=0A =0A-    =
if ( ivhd_block->header.length <=0A-         sizeof(struct acpi_ivhd_block_=
header) )=0A+    if ( ivhd_block->header.length < sizeof(*ivhd_block) )=0A =
    {=0A         AMD_IOMMU_DEBUG("IVHD Error: Invalid Block Length!\n");=0A=
         return -ENODEV;=0A     }=0A =0A-    iommu =3D find_iommu_from_bdf_=
cap(ivhd_block->header.dev_id,=0A-                                    =
ivhd_block->cap_offset);=0A+    iommu =3D find_iommu_from_bdf_cap(ivhd_bloc=
k->header.device_id,=0A+                                    ivhd_block->cap=
ability_offset);=0A     if ( !iommu )=0A     {=0A         AMD_IOMMU_DEBUG("=
IVHD Error: No IOMMU for Dev_Id 0x%x  Cap 0x%x\n",=0A-                     =
   ivhd_block->header.dev_id, ivhd_block->cap_offset);=0A+                 =
       ivhd_block->header.device_id,=0A+                        ivhd_block-=
>capability_offset);=0A         return -ENODEV;=0A     }=0A =0A     /* =
parse Device Entries */=0A-    block_length =3D sizeof(struct acpi_ivhd_blo=
ck_header);=0A+    block_length =3D sizeof(*ivhd_block);=0A     while ( =
ivhd_block->header.length >=3D=0A-            (block_length + sizeof(struct=
 acpi_ivhd_device_header)) )=0A+            (block_length + sizeof(struct =
acpi_ivrs_de_header)) )=0A     {=0A-        ivhd_device =3D (union =
acpi_ivhd_device *)=0A-            ((u8 *)ivhd_block + block_length);=0A+  =
      ivhd_device =3D (const void *)((const u8 *)ivhd_block + block_length)=
;=0A =0A         AMD_IOMMU_DEBUG( "IVHD Device Entry:\n");=0A         =
AMD_IOMMU_DEBUG( " Type 0x%x\n", ivhd_device->header.type);=0A-        =
AMD_IOMMU_DEBUG( " Dev_Id 0x%x\n", ivhd_device->header.dev_id);=0A-        =
AMD_IOMMU_DEBUG( " Flags 0x%x\n", ivhd_device->header.flags);=0A+        =
AMD_IOMMU_DEBUG( " Dev_Id 0x%x\n", ivhd_device->header.id);=0A+        =
AMD_IOMMU_DEBUG( " Flags 0x%x\n", ivhd_device->header.data_setting);=0A =
=0A         switch ( ivhd_device->header.type )=0A         {=0A-        =
case AMD_IOMMU_ACPI_IVHD_DEV_U32_PAD:=0A+        case ACPI_IVRS_TYPE_PAD4:=
=0A             dev_length =3D parse_ivhd_device_padding(=0A               =
  sizeof(u32),=0A                 ivhd_block->header.length, block_length);=
=0A             break;=0A-        case AMD_IOMMU_ACPI_IVHD_DEV_U64_PAD:=0A+=
        case ACPI_IVRS_TYPE_PAD8:=0A             dev_length =3D parse_ivhd_=
device_padding(=0A                 sizeof(u64),=0A                 =
ivhd_block->header.length, block_length);=0A             break;=0A-        =
case AMD_IOMMU_ACPI_IVHD_DEV_SELECT:=0A-            dev_length =3D =
parse_ivhd_device_select(ivhd_device, iommu);=0A+        case ACPI_IVRS_TYP=
E_SELECT:=0A+            dev_length =3D parse_ivhd_device_select(&ivhd_devi=
ce->select, iommu);=0A             break;=0A-        case AMD_IOMMU_ACPI_IV=
HD_DEV_RANGE_START:=0A+        case ACPI_IVRS_TYPE_START:=0A             =
dev_length =3D parse_ivhd_device_range(=0A-                ivhd_device,=0A+=
                &ivhd_device->range,=0A                 ivhd_block->header.=
length, block_length, iommu);=0A             break;=0A-        case =
AMD_IOMMU_ACPI_IVHD_DEV_ALIAS_SELECT:=0A+        case ACPI_IVRS_TYPE_ALIAS_=
SELECT:=0A             dev_length =3D parse_ivhd_device_alias(=0A-         =
       ivhd_device,=0A+                &ivhd_device->alias,=0A             =
    ivhd_block->header.length, block_length, iommu);=0A             =
break;=0A-        case AMD_IOMMU_ACPI_IVHD_DEV_ALIAS_RANGE:=0A+        =
case ACPI_IVRS_TYPE_ALIAS_START:=0A             dev_length =3D parse_ivhd_d=
evice_alias_range(=0A-                ivhd_device,=0A+                =
&ivhd_device->alias_range,=0A                 ivhd_block->header.length, =
block_length, iommu);=0A             break;=0A-        case AMD_IOMMU_ACPI_=
IVHD_DEV_EXT_SELECT:=0A+        case ACPI_IVRS_TYPE_EXT_SELECT:=0A         =
    dev_length =3D parse_ivhd_device_extended(=0A-                =
ivhd_device,=0A+                &ivhd_device->extended,=0A                 =
ivhd_block->header.length, block_length, iommu);=0A             break;=0A- =
       case AMD_IOMMU_ACPI_IVHD_DEV_EXT_RANGE:=0A+        case ACPI_IVRS_TY=
PE_EXT_START:=0A             dev_length =3D parse_ivhd_device_extended_rang=
e(=0A-                ivhd_device,=0A+                &ivhd_device->extende=
d_range,=0A                 ivhd_block->header.length, block_length, =
iommu);=0A             break;=0A-        case AMD_IOMMU_ACPI_IVHD_DEV_SPECI=
AL:=0A+        case ACPI_IVRS_TYPE_SPECIAL:=0A             dev_length =3D =
parse_ivhd_device_special(=0A-                ivhd_device, ivhd_block->pci_=
segment,=0A+                &ivhd_device->special, ivhd_block->pci_segment_=
group,=0A                 ivhd_block->header.length, block_length, =
iommu);=0A             break;=0A         default:=0A@@ -730,22 +750,24 @@ =
static int __init parse_ivhd_block(struc=0A     return 0;=0A }=0A =
=0A-static int __init parse_ivrs_block(struct acpi_ivrs_block_header =
*ivrs_block)=0A+static int __init parse_ivrs_block(const struct acpi_ivrs_h=
eader *ivrs_block)=0A {=0A-    struct acpi_ivhd_block_header *ivhd_block;=
=0A-    struct acpi_ivmd_block_header *ivmd_block;=0A+    const struct =
acpi_ivrs_hardware *ivhd_block;=0A+    const struct acpi_ivrs_memory =
*ivmd_block;=0A =0A     switch ( ivrs_block->type )=0A     {=0A-    case =
AMD_IOMMU_ACPI_IVHD_TYPE:=0A-        ivhd_block =3D (struct acpi_ivhd_block=
_header *)ivrs_block;=0A+    case ACPI_IVRS_TYPE_HARDWARE:=0A+        =
ivhd_block =3D container_of(ivrs_block, const struct acpi_ivrs_hardware,=0A=
+                                  header);=0A         return parse_ivhd_bl=
ock(ivhd_block);=0A =0A-    case AMD_IOMMU_ACPI_IVMD_ALL_TYPE:=0A-    case =
AMD_IOMMU_ACPI_IVMD_ONE_TYPE:=0A-    case AMD_IOMMU_ACPI_IVMD_RANGE_TYPE:=
=0A-    case AMD_IOMMU_ACPI_IVMD_IOMMU_TYPE:=0A-        ivmd_block =3D =
(struct acpi_ivmd_block_header *)ivrs_block;=0A+    case ACPI_IVRS_TYPE_MEM=
ORY_ALL:=0A+    case ACPI_IVRS_TYPE_MEMORY_ONE:=0A+    case ACPI_IVRS_TYPE_=
MEMORY_RANGE:=0A+    case ACPI_IVRS_TYPE_MEMORY_IOMMU:=0A+        =
ivmd_block =3D container_of(ivrs_block, const struct acpi_ivrs_memory,=0A+ =
                                 header);=0A         return parse_ivmd_bloc=
k(ivmd_block);=0A =0A     default:=0A@@ -792,12 +814,11 @@ static void =
__init dump_acpi_table_heade=0A =0A }=0A =0A-static int __init parse_ivrs_t=
able(struct acpi_table_header *_table)=0A+static int __init parse_ivrs_tabl=
e(struct acpi_table_header *table)=0A {=0A-    struct acpi_ivrs_block_heade=
r *ivrs_block;=0A+    const struct acpi_ivrs_header *ivrs_block;=0A     =
unsigned long length;=0A     int error =3D 0;=0A-    struct acpi_table_head=
er *table =3D (struct acpi_table_header *)_table;=0A =0A     BUG_ON(!table)=
;=0A =0A@@ -805,17 +826,16 @@ static int __init parse_ivrs_table(struc=0A  =
       dump_acpi_table_header(table);=0A =0A     /* parse IVRS blocks =
*/=0A-    length =3D sizeof(struct acpi_ivrs_table_header);=0A+    length =
=3D sizeof(struct acpi_table_ivrs);=0A     while ( (error =3D=3D 0) && =
(table->length > (length + sizeof(*ivrs_block))) )=0A     {=0A-        =
ivrs_block =3D (struct acpi_ivrs_block_header *)=0A-            ((u8 =
*)table + length);=0A+        ivrs_block =3D (struct acpi_ivrs_header =
*)((u8 *)table + length);=0A =0A         AMD_IOMMU_DEBUG("IVRS Block:\n");=
=0A         AMD_IOMMU_DEBUG(" Type 0x%x\n", ivrs_block->type);=0A         =
AMD_IOMMU_DEBUG(" Flags 0x%x\n", ivrs_block->flags);=0A         AMD_IOMMU_D=
EBUG(" Length 0x%x\n", ivrs_block->length);=0A-        AMD_IOMMU_DEBUG(" =
Dev_Id 0x%x\n", ivrs_block->dev_id);=0A+        AMD_IOMMU_DEBUG(" Dev_Id =
0x%x\n", ivrs_block->device_id);=0A =0A         if ( table->length < =
(length + ivrs_block->length) )=0A         {=0A@@ -833,12 +853,11 @@ =
static int __init parse_ivrs_table(struc=0A     return error;=0A }=0A =
=0A-static int __init detect_iommu_acpi(struct acpi_table_header =
*_table)=0A+static int __init detect_iommu_acpi(struct acpi_table_header =
*table)=0A {=0A-    struct acpi_ivrs_block_header *ivrs_block;=0A-    =
struct acpi_table_header *table =3D (struct acpi_table_header *)_table;=0A+=
    const struct acpi_ivrs_header *ivrs_block;=0A     unsigned long i;=0A- =
   unsigned long length =3D sizeof(struct acpi_ivrs_table_header);=0A+    =
unsigned long length =3D sizeof(struct acpi_table_ivrs);=0A     u8 =
checksum, *raw_table;=0A =0A     /* validate checksum: sum of entire table =
=3D=3D 0 */=0A@@ -854,12 +873,14 @@ static int __init detect_iommu_acpi(str=
u=0A =0A     while ( table->length > (length + sizeof(*ivrs_block)) )=0A   =
  {=0A-        ivrs_block =3D (struct acpi_ivrs_block_header *) ((u8 =
*)table + length);=0A+        ivrs_block =3D (struct acpi_ivrs_header =
*)((u8 *)table + length);=0A         if ( table->length < (length + =
ivrs_block->length) )=0A             return -ENODEV;=0A-        if ( =
ivrs_block->type =3D=3D AMD_IOMMU_ACPI_IVHD_TYPE )=0A-            if ( =
amd_iommu_detect_one_acpi((void*)ivrs_block) !=3D 0 )=0A-                =
return -ENODEV;=0A+        if ( ivrs_block->type =3D=3D ACPI_IVRS_TYPE_HARD=
WARE &&=0A+             amd_iommu_detect_one_acpi(=0A+                 =
container_of(ivrs_block, const struct acpi_ivrs_hardware,=0A+              =
                header)) !=3D 0 )=0A+            return -ENODEV;=0A        =
 length +=3D ivrs_block->length;=0A     }=0A     return 0;=0A@@ -870,63 =
+891,59 @@ static int __init detect_iommu_acpi(stru=0A        last_bdf =3D =
(x); \=0A    } while(0);=0A =0A-static int __init get_last_bdf_ivhd(void =
*ivhd)=0A+static int __init get_last_bdf_ivhd(=0A+    const struct =
acpi_ivrs_hardware *ivhd_block)=0A {=0A-    union acpi_ivhd_device =
*ivhd_device;=0A+    const union acpi_ivhd_device *ivhd_device;=0A     u16 =
block_length, dev_length;=0A-    struct acpi_ivhd_block_header *ivhd_block;=
=0A-=0A-    ivhd_block =3D (struct acpi_ivhd_block_header *)ivhd;=0A =0A-  =
  if ( ivhd_block->header.length <=0A-         sizeof(struct acpi_ivhd_bloc=
k_header) )=0A+    if ( ivhd_block->header.length < sizeof(*ivhd_block) =
)=0A     {=0A         AMD_IOMMU_DEBUG("IVHD Error: Invalid Block Length!\n"=
);=0A         return -ENODEV;=0A     }=0A =0A-    block_length =3D =
sizeof(struct acpi_ivhd_block_header);=0A+    block_length =3D sizeof(*ivhd=
_block);=0A     while ( ivhd_block->header.length >=3D=0A-            =
(block_length + sizeof(struct acpi_ivhd_device_header)) )=0A+            =
(block_length + sizeof(struct acpi_ivrs_de_header)) )=0A     {=0A-        =
ivhd_device =3D (union acpi_ivhd_device *)=0A-            ((u8 *)ivhd_block=
 + block_length);=0A+        ivhd_device =3D (const void *)((u8 *)ivhd_bloc=
k + block_length);=0A =0A         switch ( ivhd_device->header.type )=0A   =
      {=0A-        case AMD_IOMMU_ACPI_IVHD_DEV_U32_PAD:=0A+        case =
ACPI_IVRS_TYPE_PAD4:=0A             dev_length =3D sizeof(u32);=0A         =
    break;=0A-        case AMD_IOMMU_ACPI_IVHD_DEV_U64_PAD:=0A+        =
case ACPI_IVRS_TYPE_PAD8:=0A             dev_length =3D sizeof(u64);=0A    =
         break;=0A-        case AMD_IOMMU_ACPI_IVHD_DEV_SELECT:=0A-        =
    UPDATE_LAST_BDF(ivhd_device->header.dev_id);=0A-            dev_length =
=3D sizeof(struct acpi_ivhd_device_header);=0A-            break;=0A-      =
  case AMD_IOMMU_ACPI_IVHD_DEV_ALIAS_SELECT:=0A-            UPDATE_LAST_BDF=
(ivhd_device->header.dev_id);=0A-            dev_length =3D sizeof(struct =
acpi_ivhd_device_alias);=0A-            break;=0A-        case AMD_IOMMU_AC=
PI_IVHD_DEV_EXT_SELECT:=0A-            UPDATE_LAST_BDF(ivhd_device->header.=
dev_id);=0A-            dev_length =3D sizeof(struct acpi_ivhd_device_exten=
ded);=0A-            break;=0A-        case AMD_IOMMU_ACPI_IVHD_DEV_RANGE_S=
TART:=0A-            UPDATE_LAST_BDF(ivhd_device->range.trailer.dev_id);=0A=
-            dev_length =3D sizeof(struct acpi_ivhd_device_range);=0A-     =
       break;=0A-        case AMD_IOMMU_ACPI_IVHD_DEV_ALIAS_RANGE:=0A-     =
       UPDATE_LAST_BDF(ivhd_device->alias_range.trailer.dev_id)=0A-        =
    dev_length =3D sizeof(struct acpi_ivhd_device_alias_range);=0A-        =
    break;=0A-        case AMD_IOMMU_ACPI_IVHD_DEV_EXT_RANGE:=0A-          =
  UPDATE_LAST_BDF(ivhd_device->extended_range.trailer.dev_id)=0A-          =
  dev_length =3D sizeof(struct acpi_ivhd_device_extended_range);=0A-       =
     break;=0A-        case AMD_IOMMU_ACPI_IVHD_DEV_SPECIAL:=0A-           =
 UPDATE_LAST_BDF(ivhd_device->special.dev_id)=0A-            dev_length =
=3D sizeof(struct acpi_ivhd_device_special);=0A+        case ACPI_IVRS_TYPE=
_SELECT:=0A+            UPDATE_LAST_BDF(ivhd_device->select.header.id);=0A+=
            dev_length =3D sizeof(ivhd_device->header);=0A+            =
break;=0A+        case ACPI_IVRS_TYPE_ALIAS_SELECT:=0A+            =
UPDATE_LAST_BDF(ivhd_device->alias.header.id);=0A+            dev_length =
=3D sizeof(ivhd_device->alias);=0A+            break;=0A+        case =
ACPI_IVRS_TYPE_EXT_SELECT:=0A+            UPDATE_LAST_BDF(ivhd_device->exte=
nded.header.id);=0A+            dev_length =3D sizeof(ivhd_device->extended=
);=0A+            break;=0A+        case ACPI_IVRS_TYPE_START:=0A+         =
   UPDATE_LAST_BDF(ivhd_device->range.end.header.id);=0A+            =
dev_length =3D sizeof(ivhd_device->range);=0A+            break;=0A+       =
 case ACPI_IVRS_TYPE_ALIAS_START:=0A+            UPDATE_LAST_BDF(ivhd_devic=
e->alias_range.end.header.id)=0A+            dev_length =3D sizeof(ivhd_dev=
ice->alias_range);=0A+            break;=0A+        case ACPI_IVRS_TYPE_EXT=
_START:=0A+            UPDATE_LAST_BDF(ivhd_device->extended_range.end.head=
er.id)=0A+            dev_length =3D sizeof(ivhd_device->extended_range);=
=0A+            break;=0A+        case ACPI_IVRS_TYPE_SPECIAL:=0A+         =
   UPDATE_LAST_BDF(ivhd_device->special.used_id)=0A+            dev_length =
=3D sizeof(ivhd_device->special);=0A             break;=0A         =
default:=0A             AMD_IOMMU_DEBUG("IVHD Error: Invalid Device =
Type!\n");=0A@@ -942,20 +959,21 @@ static int __init get_last_bdf_ivhd(void=
=0A     return 0;=0A }=0A =0A-static int __init get_last_bdf_acpi(struct =
acpi_table_header *_table)=0A+static int __init get_last_bdf_acpi(struct =
acpi_table_header *table)=0A {=0A-    struct acpi_ivrs_block_header =
*ivrs_block;=0A-    struct acpi_table_header *table =3D (struct acpi_table_=
header *)_table;=0A-    unsigned long length =3D sizeof(struct acpi_ivrs_ta=
ble_header);=0A+    const struct acpi_ivrs_header *ivrs_block;=0A+    =
unsigned long length =3D sizeof(struct acpi_table_ivrs);=0A =0A     while =
( table->length > (length + sizeof(*ivrs_block)) )=0A     {=0A-        =
ivrs_block =3D (struct acpi_ivrs_block_header *) ((u8 *)table + length);=0A=
+        ivrs_block =3D (struct acpi_ivrs_header *)((u8 *)table + =
length);=0A         if ( table->length < (length + ivrs_block->length) =
)=0A             return -ENODEV;=0A-        if ( ivrs_block->type =3D=3D =
AMD_IOMMU_ACPI_IVHD_TYPE )=0A-            if ( get_last_bdf_ivhd((void*)ivr=
s_block) !=3D 0 )=0A-                return -ENODEV;=0A+        if ( =
ivrs_block->type =3D=3D ACPI_IVRS_TYPE_HARDWARE &&=0A+             =
get_last_bdf_ivhd(=0A+                 container_of(ivrs_block, const =
struct acpi_ivrs_hardware,=0A+                              header)) !=3D =
0 )=0A+            return -ENODEV;=0A         length +=3D ivrs_block->lengt=
h;=0A     }=0A    return 0;=0A@@ -963,16 +981,16 @@ static int __init =
get_last_bdf_acpi(stru=0A =0A int __init amd_iommu_detect_acpi(void)=0A =
{=0A-    return acpi_table_parse(AMD_IOMMU_ACPI_IVRS_SIG, detect_iommu_acpi=
);=0A+    return acpi_table_parse(ACPI_SIG_IVRS, detect_iommu_acpi);=0A =
}=0A =0A int __init amd_iommu_get_ivrs_dev_entries(void)=0A {=0A-    =
acpi_table_parse(AMD_IOMMU_ACPI_IVRS_SIG, get_last_bdf_acpi);=0A+    =
acpi_table_parse(ACPI_SIG_IVRS, get_last_bdf_acpi);=0A     return last_bdf =
+ 1;=0A }=0A =0A int __init amd_iommu_update_ivrs_mapping_acpi(void)=0A =
{=0A-    return acpi_table_parse(AMD_IOMMU_ACPI_IVRS_SIG, parse_ivrs_table)=
;=0A+    return acpi_table_parse(ACPI_SIG_IVRS, parse_ivrs_table);=0A =
}=0A--- a/xen/drivers/passthrough/amd/iommu_detect.c=0A+++ b/xen/drivers/pa=
ssthrough/amd/iommu_detect.c=0A@@ -20,12 +20,12 @@=0A =0A #include =
<xen/config.h>=0A #include <xen/errno.h>=0A+#include <xen/acpi.h>=0A =
#include <xen/iommu.h>=0A #include <xen/pci.h>=0A #include <xen/pci_regs.h>=
=0A #include <asm/amd-iommu.h>=0A #include <asm/hvm/svm/amd-iommu-proto.h>=
=0A-#include <asm/hvm/svm/amd-iommu-acpi.h>=0A =0A static int __init =
get_iommu_msi_capabilities(=0A     u16 seg, u8 bus, u8 dev, u8 func, =
struct amd_iommu *iommu)=0A@@ -103,23 +103,21 @@ void __init get_iommu_feat=
ures(struct am=0A     }=0A }=0A =0A-int __init amd_iommu_detect_one_acpi(vo=
id *ivhd)=0A+int __init amd_iommu_detect_one_acpi(=0A+    const struct =
acpi_ivrs_hardware *ivhd_block)=0A {=0A     struct amd_iommu *iommu;=0A    =
 u8 bus, dev, func;=0A-    struct acpi_ivhd_block_header *ivhd_block;=0A   =
  int rt =3D 0;=0A =0A-    ivhd_block =3D (struct acpi_ivhd_block_header =
*)ivhd;=0A-=0A-    if ( ivhd_block->header.length < sizeof(struct =
acpi_ivhd_block_header) )=0A+    if ( ivhd_block->header.length < =
sizeof(*ivhd_block) )=0A     {=0A         AMD_IOMMU_DEBUG("Invalid IVHD =
Block Length!\n");=0A         return -ENODEV;=0A     }=0A =0A-    if ( =
!ivhd_block->header.dev_id ||=0A-        !ivhd_block->cap_offset || =
!ivhd_block->mmio_base)=0A+    if ( !ivhd_block->header.device_id ||=0A+   =
     !ivhd_block->capability_offset || !ivhd_block->base_address)=0A     =
{=0A         AMD_IOMMU_DEBUG("Invalid IVHD Block!\n");=0A         return =
-ENODEV;=0A@@ -134,10 +132,10 @@ int __init amd_iommu_detect_one_acpi(voi=
=0A =0A     spin_lock_init(&iommu->lock);=0A =0A-    iommu->seg =3D =
ivhd_block->pci_segment;=0A-    iommu->bdf =3D ivhd_block->header.dev_id;=
=0A-    iommu->cap_offset =3D ivhd_block->cap_offset;=0A-    iommu->mmio_ba=
se_phys =3D ivhd_block->mmio_base;=0A+    iommu->seg =3D ivhd_block->pci_se=
gment_group;=0A+    iommu->bdf =3D ivhd_block->header.device_id;=0A+    =
iommu->cap_offset =3D ivhd_block->capability_offset;=0A+    iommu->mmio_bas=
e_phys =3D ivhd_block->base_address;=0A =0A     /* override IOMMU HT flags =
*/=0A     iommu->ht_flags =3D ivhd_block->header.flags;=0A--- a/xen/drivers=
/passthrough/amd/iommu_init.c=0A+++ b/xen/drivers/passthrough/amd/iommu_ini=
t.c=0A@@ -20,6 +20,7 @@=0A =0A #include <xen/config.h>=0A #include =
<xen/errno.h>=0A+#include <xen/acpi.h>=0A #include <xen/pci.h>=0A #include =
<xen/pci_regs.h>=0A #include <xen/irq.h>=0A@@ -28,7 +29,6 @@=0A #include =
<asm/hvm/svm/amd-iommu-proto.h>=0A #include <asm-x86/fixmap.h>=0A #include =
<mach_apic.h>=0A-#include <asm/hvm/svm/amd-iommu-acpi.h>=0A =0A static int =
__initdata nr_amd_iommus;=0A =0A@@ -37,9 +37,8 @@ static struct radix_tree_=
root ivrs_maps;=0A struct list_head amd_iommu_head;=0A struct table_struct =
device_table;=0A =0A-static int iommu_has_ht_flag(struct amd_iommu *iommu, =
uint8_t bit)=0A+static int iommu_has_ht_flag(struct amd_iommu *iommu, u8 =
mask)=0A {=0A-    u8 mask =3D 1U << bit;=0A     return iommu->ht_flags & =
mask;=0A }=0A =0A@@ -80,19 +79,19 @@ static void set_iommu_ht_flags(struct =
am=0A =0A     /* Setup HT flags */=0A     if ( iommu_has_cap(iommu, =
PCI_CAP_HT_TUNNEL_SHIFT) )=0A-        iommu_has_ht_flag(iommu, AMD_IOMMU_AC=
PI_HT_TUN_ENB_SHIFT) ?=0A+        iommu_has_ht_flag(iommu, ACPI_IVHD_TT_ENA=
BLE) ?=0A             iommu_set_bit(&entry, IOMMU_CONTROL_HT_TUNNEL_TRANSLA=
TION_SHIFT) :=0A             iommu_clear_bit(&entry, IOMMU_CONTROL_HT_TUNNE=
L_TRANSLATION_SHIFT);=0A =0A-    iommu_has_ht_flag(iommu, AMD_IOMMU_ACPI_RE=
S_PASS_PW_SHIFT) ?=0A+    iommu_has_ht_flag(iommu, ACPI_IVHD_RES_PASS_PW) =
?=0A         iommu_set_bit(&entry, IOMMU_CONTROL_RESP_PASS_POSTED_WRITE_SHI=
FT):=0A         iommu_clear_bit(&entry, IOMMU_CONTROL_RESP_PASS_POSTED_WRIT=
E_SHIFT);=0A =0A-    iommu_has_ht_flag(iommu, AMD_IOMMU_ACPI_ISOC_SHIFT) =
?=0A+    iommu_has_ht_flag(iommu, ACPI_IVHD_ISOC) ?=0A         iommu_set_bi=
t(&entry, IOMMU_CONTROL_ISOCHRONOUS_SHIFT):=0A         iommu_clear_bit(&ent=
ry, IOMMU_CONTROL_ISOCHRONOUS_SHIFT);=0A =0A-    iommu_has_ht_flag(iommu, =
AMD_IOMMU_ACPI_PASS_PW_SHIFT) ?=0A+    iommu_has_ht_flag(iommu, ACPI_IVHD_P=
ASS_PW) ?=0A         iommu_set_bit(&entry, IOMMU_CONTROL_PASS_POSTED_WRITE_=
SHIFT):=0A         iommu_clear_bit(&entry, IOMMU_CONTROL_PASS_POSTED_WRITE_=
SHIFT);=0A =0A--- a/xen/drivers/passthrough/amd/iommu_map.c=0A+++ =
b/xen/drivers/passthrough/amd/iommu_map.c=0A@@ -18,12 +18,13 @@=0A  * =
Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307 =
USA=0A  */=0A =0A+#include <xen/config.h>=0A+#include <xen/acpi.h>=0A =
#include <xen/sched.h>=0A #include <asm/p2m.h>=0A #include <xen/hvm/iommu.h=
>=0A #include <asm/amd-iommu.h>=0A #include <asm/hvm/svm/amd-iommu-proto.h>=
=0A-#include <asm/hvm/svm/amd-iommu-acpi.h>=0A #include "../ats.h"=0A =
#include <xen/pci.h>=0A =0A@@ -215,8 +216,7 @@ void __init iommu_dte_add_de=
vice_entry(u=0A     dte[7] =3D dte[6] =3D dte[4] =3D dte[2] =3D dte[1] =3D =
dte[0] =3D 0;=0A =0A     flags =3D ivrs_dev->device_flags;=0A-    sys_mgt =
=3D get_field_from_byte(flags, AMD_IOMMU_ACPI_SYS_MGT_MASK,=0A-            =
                      AMD_IOMMU_ACPI_SYS_MGT_SHIFT);=0A+    sys_mgt =3D =
get_field_from_byte(flags, ACPI_IVHD_SYSTEM_MGMT);=0A     dev_ex =3D =
ivrs_dev->dte_allow_exclusion;=0A =0A     flags &=3D mask;=0A--- a/xen/incl=
ude/asm-x86/hvm/svm/amd-iommu-acpi.h=0A+++ /dev/null=0A@@ -1,185 +0,0 =
@@=0A-/*=0A- * Copyright (C) 2007 Advanced Micro Devices, Inc.=0A- * =
Author: Leo Duran <leo.duran@amd.com>=0A- * Author: Wei Wang <wei.wang2@amd=
.com> - adapted to xen=0A- *=0A- * This program is free software; you can =
redistribute it and/or modify=0A- * it under the terms of the GNU General =
Public License as published by=0A- * the Free Software Foundation; either =
version 2 of the License, or=0A- * (at your option) any later version.=0A- =
*=0A- * This program is distributed in the hope that it will be useful,=0A-=
 * but WITHOUT ANY WARRANTY; without even the implied warranty of=0A- * =
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the=0A- * GNU =
General Public License for more details.=0A- *=0A- * You should have =
received a copy of the GNU General Public License=0A- * along with this =
program; if not, write to the Free Software=0A- * Foundation, Inc., 59 =
Temple Place, Suite 330, Boston, MA  02111-1307 USA=0A- */=0A-=0A-#ifndef =
_ASM_X86_64_AMD_IOMMU_ACPI_H=0A-#define _ASM_X86_64_AMD_IOMMU_ACPI_H=0A-=0A=
-#include <xen/acpi.h>=0A-=0A-/* I/O Virtualization Reporting Structure =
*/=0A-#define AMD_IOMMU_ACPI_IVRS_SIG            "IVRS"=0A-#define =
AMD_IOMMU_ACPI_IVHD_TYPE       0x10=0A-#define AMD_IOMMU_ACPI_IVMD_ALL_TYPE=
       0x20=0A-#define AMD_IOMMU_ACPI_IVMD_ONE_TYPE       0x21=0A-#define =
AMD_IOMMU_ACPI_IVMD_RANGE_TYPE     0x22=0A-#define AMD_IOMMU_ACPI_IVMD_IOMM=
U_TYPE     0x23=0A-=0A-/* 4-byte Device Entries */=0A-#define AMD_IOMMU_ACP=
I_IVHD_DEV_U32_PAD        0=0A-#define AMD_IOMMU_ACPI_IVHD_DEV_SELECT     =
2=0A-#define AMD_IOMMU_ACPI_IVHD_DEV_RANGE_START    3=0A-#define AMD_IOMMU_=
ACPI_IVHD_DEV_RANGE_END  4=0A-=0A-/* 8-byte Device Entries */=0A-#define =
AMD_IOMMU_ACPI_IVHD_DEV_U64_PAD        64=0A-#define AMD_IOMMU_ACPI_IVHD_DE=
V_ALIAS_SELECT   66=0A-#define AMD_IOMMU_ACPI_IVHD_DEV_ALIAS_RANGE    =
67=0A-#define AMD_IOMMU_ACPI_IVHD_DEV_EXT_SELECT 70=0A-#define AMD_IOMMU_AC=
PI_IVHD_DEV_EXT_RANGE  71=0A-#define AMD_IOMMU_ACPI_IVHD_DEV_SPECIAL    =
72=0A-=0A-/* IVHD IOMMU Flags */=0A-#define AMD_IOMMU_ACPI_COHERENT_MASK   =
    0x20=0A-#define AMD_IOMMU_ACPI_COHERENT_SHIFT      5=0A-#define =
AMD_IOMMU_ACPI_IOTLB_SUP_MASK      0x10=0A-#define AMD_IOMMU_ACPI_IOTLB_SUP=
_SHIFT     4=0A-#define AMD_IOMMU_ACPI_ISOC_MASK       0x08=0A-#define =
AMD_IOMMU_ACPI_ISOC_SHIFT      3=0A-#define AMD_IOMMU_ACPI_RES_PASS_PW_MASK=
        0x04=0A-#define AMD_IOMMU_ACPI_RES_PASS_PW_SHIFT   2=0A-#define =
AMD_IOMMU_ACPI_PASS_PW_MASK        0x02=0A-#define AMD_IOMMU_ACPI_PASS_PW_S=
HIFT       1=0A-#define AMD_IOMMU_ACPI_HT_TUN_ENB_MASK     0x01=0A-#define =
AMD_IOMMU_ACPI_HT_TUN_ENB_SHIFT        0=0A-=0A-/* IVHD Device Flags =
*/=0A-#define AMD_IOMMU_ACPI_LINT1_PASS_MASK     0x80=0A-#define AMD_IOMMU_=
ACPI_LINT1_PASS_SHIFT        7=0A-#define AMD_IOMMU_ACPI_LINT0_PASS_MASK   =
  0x40=0A-#define AMD_IOMMU_ACPI_LINT0_PASS_SHIFT        6=0A-#define =
AMD_IOMMU_ACPI_SYS_MGT_MASK        0x30=0A-#define AMD_IOMMU_ACPI_SYS_MGT_S=
HIFT       4=0A-#define AMD_IOMMU_ACPI_NMI_PASS_MASK       0x04=0A-#define =
AMD_IOMMU_ACPI_NMI_PASS_SHIFT      2=0A-#define AMD_IOMMU_ACPI_EINT_PASS_MA=
SK      0x02=0A-#define AMD_IOMMU_ACPI_EINT_PASS_SHIFT     1=0A-#define =
AMD_IOMMU_ACPI_INIT_PASS_MASK      0x01=0A-#define AMD_IOMMU_ACPI_INIT_PASS=
_SHIFT     0=0A-=0A-/* IVHD Device Extended Flags */=0A-#define AMD_IOMMU_A=
CPI_ATS_DISABLED_MASK   0x80000000=0A-#define AMD_IOMMU_ACPI_ATS_DISABLED_S=
HIFT  31=0A-=0A-/* IVMD Device Flags */=0A-#define AMD_IOMMU_ACPI_EXCLUSION=
_RANGE_MASK    0x08=0A-#define AMD_IOMMU_ACPI_EXCLUSION_RANGE_SHIFT   =
3=0A-#define AMD_IOMMU_ACPI_IW_PERMISSION_MASK  0x04=0A-#define AMD_IOMMU_A=
CPI_IW_PERMISSION_SHIFT 2=0A-#define AMD_IOMMU_ACPI_IR_PERMISSION_MASK  =
0x02=0A-#define AMD_IOMMU_ACPI_IR_PERMISSION_SHIFT 1=0A-#define AMD_IOMMU_A=
CPI_UNITY_MAPPING_MASK  0x01=0A-#define AMD_IOMMU_ACPI_UNITY_MAPPING_SHIFT =
0=0A-=0A-#define ACPI_OEM_ID_SIZE                6=0A-#define ACPI_OEM_TABL=
E_ID_SIZE          8=0A-=0A-#pragma pack(1)=0A-struct acpi_ivrs_table_heade=
r {=0A-   struct acpi_table_header acpi_header;=0A-   u32 io_info;=0A-   =
u8  reserved[8];=0A-};=0A-=0A-struct acpi_ivrs_block_header {=0A-   u8  =
type;=0A-   u8  flags;=0A-   u16 length;=0A-   u16 dev_id;=0A-};=0A-=0A-str=
uct acpi_ivhd_block_header {=0A-   struct acpi_ivrs_block_header header;=0A=
-   u16 cap_offset;=0A-   u64 mmio_base;=0A-   u16 pci_segment;=0A-   u16 =
iommu_info;=0A-   u8 reserved[4];=0A-};=0A-=0A-struct acpi_ivhd_device_head=
er {=0A-   u8  type;=0A-   u16 dev_id;=0A-   u8  flags;=0A-};=0A-=0A-struct=
 acpi_ivhd_device_trailer {=0A-   u8  type;=0A-   u16 dev_id;=0A-   u8  =
reserved;=0A-};=0A-=0A-struct acpi_ivhd_device_range {=0A-   struct =
acpi_ivhd_device_header header;=0A-   struct acpi_ivhd_device_trailer =
trailer;=0A-};=0A-=0A-struct acpi_ivhd_device_alias {=0A-   struct =
acpi_ivhd_device_header header;=0A-   u8  reserved1;=0A-   u16 dev_id;=0A- =
  u8  reserved2;=0A-};=0A-=0A-struct acpi_ivhd_device_alias_range {=0A-   =
struct acpi_ivhd_device_alias alias;=0A-   struct acpi_ivhd_device_trailer =
trailer;=0A-};=0A-=0A-struct acpi_ivhd_device_extended {=0A-   struct =
acpi_ivhd_device_header header;=0A-   u32 ext_flags;=0A-};=0A-=0A-struct =
acpi_ivhd_device_extended_range {=0A-   struct acpi_ivhd_device_extended =
extended;=0A-   struct acpi_ivhd_device_trailer trailer;=0A-};=0A-=0A-struc=
t acpi_ivhd_device_special {=0A-   struct acpi_ivhd_device_header =
header;=0A-   u8  handle;=0A-   u16 dev_id;=0A-   u8  variety;=0A-};=0A-=0A=
-union acpi_ivhd_device {=0A-   struct acpi_ivhd_device_header header;=0A- =
  struct acpi_ivhd_device_range range;=0A-   struct acpi_ivhd_device_alias =
alias;=0A-   struct acpi_ivhd_device_alias_range alias_range;=0A-   struct =
acpi_ivhd_device_extended extended;=0A-   struct acpi_ivhd_device_extended_=
range extended_range;=0A-   struct acpi_ivhd_device_special special;=0A-};=
=0A-=0A-struct acpi_ivmd_block_header {=0A-   struct acpi_ivrs_block_header=
 header;=0A-   union {=0A-       u16 last_dev_id;=0A-       u16 cap_offset;=
=0A-       u16 reserved1;=0A-   };=0A-   u64 reserved2;=0A-   u64 =
start_addr;=0A-   u64 mem_length;=0A-};=0A-#pragma pack()=0A-=0A-#endif /* =
_ASM_X86_64_AMD_IOMMU_ACPI_H */=0A--- a/xen/include/asm-x86/hvm/svm/amd-iom=
mu-proto.h=0A+++ b/xen/include/asm-x86/hvm/svm/amd-iommu-proto.h=0A@@ =
-26,6 +26,8 @@=0A #include <asm/apicdef.h>=0A #include <xen/domain_page.h>=
=0A =0A+struct acpi_ivrs_hardware;=0A+=0A #define for_each_amd_iommu(amd_io=
mmu) \=0A     list_for_each_entry(amd_iommu, \=0A         &amd_iommu_head, =
list)=0A@@ -41,7 +43,7 @@=0A =0A /* amd-iommu-detect functions */=0A int =
amd_iommu_get_ivrs_dev_entries(void);=0A-int amd_iommu_detect_one_acpi(void=
 *ivhd);=0A+int amd_iommu_detect_one_acpi(const struct acpi_ivrs_hardware =
*);=0A int amd_iommu_detect_acpi(void);=0A void get_iommu_features(struct =
amd_iommu *iommu);=0A =0A@@ -121,11 +123,9 @@ static inline u32 set_field_i=
n_reg_u32(u=0A     return reg_value;=0A }=0A =0A-static inline u8 =
get_field_from_byte(u8 value, u8 mask, u8 shift)=0A+static inline u8 =
get_field_from_byte(u8 value, u8 mask)=0A {=0A-    u8 field;=0A-    field =
=3D (value & mask) >> shift;=0A-    return field;=0A+    return (value & =
mask) / (mask & -mask);=0A }=0A =0A static inline unsigned long region_to_p=
ages(unsigned long addr, unsigned long size)=0A
--=__Part456AE0A2.0__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--=__Part456AE0A2.0__=--


From xen-devel-bounces@lists.xensource.com Thu Dec 15 12:40:01 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 12:40:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbAbA-0004z1-Is; Thu, 15 Dec 2011 12:39:44 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RbAb9-0004ye-06
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 12:39:43 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1323952726!7402470!1
X-Originating-IP: [209.85.161.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22999 invoked from network); 15 Dec 2011 12:38:46 -0000
Received: from mail-fx0-f43.google.com (HELO mail-fx0-f43.google.com)
	(209.85.161.43)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 12:38:46 -0000
Received: by faap21 with SMTP id p21so4755279faa.30
	for <xen-devel@lists.xensource.com>;
	Thu, 15 Dec 2011 04:38:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=7zsIQi1//GUTwegEQHOix3FVOELD2UBGO9TDXEhS5YM=;
	b=oEwckoW3ofud3SLkNTTHRbaJS6hUVTVj7u9lXA/DDp7n4HLxsoIcoQlDhVW5VzlNZb
	pbGcjsApJvPpSYBjn5MIoBEQf5ocNI6pQJ2IytIoow2cG228KdNuN+okXDGmWjNWHG1L
	EvMHRG7loJ9bcxftiz9f33K2ZwH5VsnSQPvEM=
Received: by 10.180.107.229 with SMTP id hf5mr4376066wib.35.1323952726226;
	Thu, 15 Dec 2011 04:38:46 -0800 (PST)
Received: from [192.168.1.3] (host81-152-17-11.range81-152.btcentralplus.com.
	[81.152.17.11])
	by mx.google.com with ESMTPS id fw16sm9051297wbb.13.2011.12.15.04.38.45
	(version=SSLv3 cipher=OTHER); Thu, 15 Dec 2011 04:38:45 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Thu, 15 Dec 2011 12:38:46 +0000
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Message-ID: <CB0F9AD6.35FE9%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH] x86/AMD: use correct shift count when
	merging model and stepping
Thread-Index: Acy7JnySKE7XbIrbrUKPQAwvNTnyAQ==
In-Reply-To: <4EE9E65B0200007800068188@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: Boris Ostrovsky <boris.ostrovsky@amd.com>, wei.huang2@amd.com
Subject: Re: [Xen-devel] [PATCH] x86/AMD: use correct shift count when
 merging model and stepping
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 15/12/2011 11:21, "Jan Beulich" <JBeulich@suse.com> wrote:

> ... for legacy errata matching.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Keir Fraser <keir@xen.org>

> --- a/xen/arch/x86/cpu/amd.c
> +++ b/xen/arch/x86/cpu/amd.c
> @@ -216,7 +216,7 @@ int cpu_has_amd_erratum(const struct cpu
> }
>  
> /* OSVW unavailable or ID unknown, match family-model-stepping range */
> - ms = (cpu->x86_model << 8) | cpu->x86_mask;
> + ms = (cpu->x86_model << 4) | cpu->x86_mask;
> while ((range = va_arg(ap, int))) {
> if ((cpu->x86 == AMD_MODEL_RANGE_FAMILY(range)) &&
>    (ms >= AMD_MODEL_RANGE_START(range)) &&
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 12:40:01 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 12:40:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbAbA-0004z1-Is; Thu, 15 Dec 2011 12:39:44 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RbAb9-0004ye-06
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 12:39:43 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1323952726!7402470!1
X-Originating-IP: [209.85.161.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22999 invoked from network); 15 Dec 2011 12:38:46 -0000
Received: from mail-fx0-f43.google.com (HELO mail-fx0-f43.google.com)
	(209.85.161.43)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 12:38:46 -0000
Received: by faap21 with SMTP id p21so4755279faa.30
	for <xen-devel@lists.xensource.com>;
	Thu, 15 Dec 2011 04:38:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=7zsIQi1//GUTwegEQHOix3FVOELD2UBGO9TDXEhS5YM=;
	b=oEwckoW3ofud3SLkNTTHRbaJS6hUVTVj7u9lXA/DDp7n4HLxsoIcoQlDhVW5VzlNZb
	pbGcjsApJvPpSYBjn5MIoBEQf5ocNI6pQJ2IytIoow2cG228KdNuN+okXDGmWjNWHG1L
	EvMHRG7loJ9bcxftiz9f33K2ZwH5VsnSQPvEM=
Received: by 10.180.107.229 with SMTP id hf5mr4376066wib.35.1323952726226;
	Thu, 15 Dec 2011 04:38:46 -0800 (PST)
Received: from [192.168.1.3] (host81-152-17-11.range81-152.btcentralplus.com.
	[81.152.17.11])
	by mx.google.com with ESMTPS id fw16sm9051297wbb.13.2011.12.15.04.38.45
	(version=SSLv3 cipher=OTHER); Thu, 15 Dec 2011 04:38:45 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Thu, 15 Dec 2011 12:38:46 +0000
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Message-ID: <CB0F9AD6.35FE9%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH] x86/AMD: use correct shift count when
	merging model and stepping
Thread-Index: Acy7JnySKE7XbIrbrUKPQAwvNTnyAQ==
In-Reply-To: <4EE9E65B0200007800068188@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: Boris Ostrovsky <boris.ostrovsky@amd.com>, wei.huang2@amd.com
Subject: Re: [Xen-devel] [PATCH] x86/AMD: use correct shift count when
 merging model and stepping
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 15/12/2011 11:21, "Jan Beulich" <JBeulich@suse.com> wrote:

> ... for legacy errata matching.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Keir Fraser <keir@xen.org>

> --- a/xen/arch/x86/cpu/amd.c
> +++ b/xen/arch/x86/cpu/amd.c
> @@ -216,7 +216,7 @@ int cpu_has_amd_erratum(const struct cpu
> }
>  
> /* OSVW unavailable or ID unknown, match family-model-stepping range */
> - ms = (cpu->x86_model << 8) | cpu->x86_mask;
> + ms = (cpu->x86_model << 4) | cpu->x86_mask;
> while ((range = va_arg(ap, int))) {
> if ((cpu->x86 == AMD_MODEL_RANGE_FAMILY(range)) &&
>    (ms >= AMD_MODEL_RANGE_START(range)) &&
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 12:42:12 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 12:42:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbAdL-00057i-4f; Thu, 15 Dec 2011 12:41:59 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RbAdJ-00057H-Ve
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 12:41:58 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-9.tower-182.messagelabs.com!1323952860!7379475!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMTA3ODk=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMTA3ODk=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16758 invoked from network); 15 Dec 2011 12:41:01 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-9.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 15 Dec 2011 12:41:01 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1323952860; l=324;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=z7PyDYalnu3hWpuBJMB9DItJaCs=;
	b=lU5rH5wpb4LEAPFAjeyaMVV64xyzs9DcUYM1AoUyxytpsoeKheEOSpwEV+ikJbVxvc0
	VNT3DTEMDqcagEpt88O7VtOsmbQRpQ5PG/xZzqiM80rFQbE6f6RWNz6L3syJ2BCx5syY1
	sgoPIr4+0z81Nxw3BQWAEruyhp8upQgiWBY=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lr3s7jGzY=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-067-089.pools.arcor-ip.net [84.57.67.89])
	by smtp.strato.de (jimi mo37) (RZmta 26.15 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id 4057bcnBFBFqIG ;
	Thu, 15 Dec 2011 13:40:51 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 4446018637; Thu, 15 Dec 2011 13:40:51 +0100 (CET)
Date: Thu, 15 Dec 2011 13:40:51 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Tim Deegan <tim@xen.org>
Message-ID: <20111215124050.GA14456@aepfle.de>
References: <patchbomb.1322737756@probook.site>
	<8147822efdee65d1f5b9.1322737758@probook.site>
	<20111215122825.GC4274@ocelot.phlegethon.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20111215122825.GC4274@ocelot.phlegethon.org>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 2 of 4] xenpaging: use wait queues
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Dec 15, Tim Deegan wrote:

> Is there a more recent version of this patch?  I see a newer version of
> the wait-queues-for-mem-events one but not of this.

The version I sent is not final, pv guests wont start for example.
I will adress the comments from Andres and you and send out a better
version.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 12:42:12 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 12:42:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbAdL-00057i-4f; Thu, 15 Dec 2011 12:41:59 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RbAdJ-00057H-Ve
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 12:41:58 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-9.tower-182.messagelabs.com!1323952860!7379475!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMTA3ODk=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMTA3ODk=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16758 invoked from network); 15 Dec 2011 12:41:01 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-9.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 15 Dec 2011 12:41:01 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1323952860; l=324;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=z7PyDYalnu3hWpuBJMB9DItJaCs=;
	b=lU5rH5wpb4LEAPFAjeyaMVV64xyzs9DcUYM1AoUyxytpsoeKheEOSpwEV+ikJbVxvc0
	VNT3DTEMDqcagEpt88O7VtOsmbQRpQ5PG/xZzqiM80rFQbE6f6RWNz6L3syJ2BCx5syY1
	sgoPIr4+0z81Nxw3BQWAEruyhp8upQgiWBY=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lr3s7jGzY=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-067-089.pools.arcor-ip.net [84.57.67.89])
	by smtp.strato.de (jimi mo37) (RZmta 26.15 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id 4057bcnBFBFqIG ;
	Thu, 15 Dec 2011 13:40:51 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 4446018637; Thu, 15 Dec 2011 13:40:51 +0100 (CET)
Date: Thu, 15 Dec 2011 13:40:51 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Tim Deegan <tim@xen.org>
Message-ID: <20111215124050.GA14456@aepfle.de>
References: <patchbomb.1322737756@probook.site>
	<8147822efdee65d1f5b9.1322737758@probook.site>
	<20111215122825.GC4274@ocelot.phlegethon.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20111215122825.GC4274@ocelot.phlegethon.org>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 2 of 4] xenpaging: use wait queues
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Dec 15, Tim Deegan wrote:

> Is there a more recent version of this patch?  I see a newer version of
> the wait-queues-for-mem-events one but not of this.

The version I sent is not final, pv guests wont start for example.
I will adress the comments from Andres and you and send out a better
version.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 12:43:54 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 12:43:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbAez-0005Fc-Tk; Thu, 15 Dec 2011 12:43:41 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <lars.kurth.xen@gmail.com>)
	id 1RbAew-0005Eq-Nw; Thu, 15 Dec 2011 12:43:38 +0000
X-Env-Sender: lars.kurth.xen@gmail.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1323952928!52567005!1
X-Originating-IP: [209.85.161.43]
X-SpamReason: No, hits=3.1 required=7.0 tests=HTML_40_50,HTML_MESSAGE,
	RCVD_BY_IP,SUSPICIOUS_RECIPS
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19285 invoked from network); 15 Dec 2011 12:42:09 -0000
Received: from mail-fx0-f43.google.com (HELO mail-fx0-f43.google.com)
	(209.85.161.43)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 12:42:09 -0000
Received: by faap21 with SMTP id p21so4767467faa.30
	for <multiple recipients>; Thu, 15 Dec 2011 04:42:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:message-id:date:from:user-agent:mime-version:to:subject
	:content-type; bh=0g2R4jqg6PIeMO08F81ZFQuzWB11DlQfDpA87fKXQwI=;
	b=J4ReF3l1hIRRgiThWrL1rTcBnOXMFHWdvVKbxjkfD/HRTJAnMQVHvcqjno/n6vxblz
	nz+xDyEutTj1D2l1QI5KwAfMaIQY+hoLcTUMuJpoMSp+CyzRuy5Tbc8gtEGSpMHn0r4r
	jXpkB9YKff/4gcC6PCPUmv6UhpZZi6nYdYfdU=
Received: by 10.180.94.71 with SMTP id da7mr4543758wib.29.1323952963360;
	Thu, 15 Dec 2011 04:42:43 -0800 (PST)
Received: from [172.16.25.10] (5e0518fc.bb.sky.com. [94.5.24.252])
	by mx.google.com with ESMTPS id bl10sm8072795wib.15.2011.12.15.04.42.41
	(version=SSLv3 cipher=OTHER); Thu, 15 Dec 2011 04:42:42 -0800 (PST)
Message-ID: <4EE9EB3E.4020707@xen.org>
Date: Thu, 15 Dec 2011 12:42:38 +0000
From: Lars Kurth <lars.kurth@xen.org>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, 
	"xen-api@lists.xensource.com" <xen-api@lists.xensource.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, 
	xen-arm@lists.xensource.com, xen-announce@lists.xensource.com
Subject: [Xen-devel] Xen Hackathon hosted by Oracle Confirmed
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1744291998484681551=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a multi-part message in MIME format.
--===============1744291998484681551==
Content-Type: multipart/alternative;
 boundary="------------050006080906080302060101"

This is a multi-part message in MIME format.
--------------050006080906080302060101
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi everybody,

I wanted to conform the date and location of the next Xen Hackathon and 
wanted to thank Oracle for hosting the Event.

Date: March 6-8
Location: Oracle campus in Santa Clara, CA, USA (*4030 George Sellon 
Circle, Santa Clara, CA 95054*)

I created a wiki page to help with the planning and preparation 
http://wiki.xen.org/wiki/Hackathon/March2012 - I am just about to go on 
vacation. More detail will follow early in January.

Best Regards
Lars

--------------050006080906080302060101
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Hi everybody,<br>
    <br>
    I wanted to conform the date and location of the next Xen Hackathon
    and wanted to thank Oracle for hosting the Event.<br>
    <br>
    Date: March 6-8 <br>
    Location: Oracle campus in Santa Clara, CA, USA (<b>4030 George
      Sellon Circle, Santa Clara, CA 95054</b>)<br>
    <br>
    I created a wiki page to help with the planning and preparation
    <a class="moz-txt-link-freetext" href="http://wiki.xen.org/wiki/Hackathon/March2012">http://wiki.xen.org/wiki/Hackathon/March2012</a> - I am just about to go
    on vacation. More detail will follow early in January.<br>
    <br>
    Best Regards<br>
    Lars<br>
  </body>
</html>

--------------050006080906080302060101--


--===============1744291998484681551==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============1744291998484681551==--


From xen-devel-bounces@lists.xensource.com Thu Dec 15 12:43:54 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 12:43:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbAez-0005Fc-Tk; Thu, 15 Dec 2011 12:43:41 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <lars.kurth.xen@gmail.com>)
	id 1RbAew-0005Eq-Nw; Thu, 15 Dec 2011 12:43:38 +0000
X-Env-Sender: lars.kurth.xen@gmail.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1323952928!52567005!1
X-Originating-IP: [209.85.161.43]
X-SpamReason: No, hits=3.1 required=7.0 tests=HTML_40_50,HTML_MESSAGE,
	RCVD_BY_IP,SUSPICIOUS_RECIPS
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19285 invoked from network); 15 Dec 2011 12:42:09 -0000
Received: from mail-fx0-f43.google.com (HELO mail-fx0-f43.google.com)
	(209.85.161.43)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 12:42:09 -0000
Received: by faap21 with SMTP id p21so4767467faa.30
	for <multiple recipients>; Thu, 15 Dec 2011 04:42:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:message-id:date:from:user-agent:mime-version:to:subject
	:content-type; bh=0g2R4jqg6PIeMO08F81ZFQuzWB11DlQfDpA87fKXQwI=;
	b=J4ReF3l1hIRRgiThWrL1rTcBnOXMFHWdvVKbxjkfD/HRTJAnMQVHvcqjno/n6vxblz
	nz+xDyEutTj1D2l1QI5KwAfMaIQY+hoLcTUMuJpoMSp+CyzRuy5Tbc8gtEGSpMHn0r4r
	jXpkB9YKff/4gcC6PCPUmv6UhpZZi6nYdYfdU=
Received: by 10.180.94.71 with SMTP id da7mr4543758wib.29.1323952963360;
	Thu, 15 Dec 2011 04:42:43 -0800 (PST)
Received: from [172.16.25.10] (5e0518fc.bb.sky.com. [94.5.24.252])
	by mx.google.com with ESMTPS id bl10sm8072795wib.15.2011.12.15.04.42.41
	(version=SSLv3 cipher=OTHER); Thu, 15 Dec 2011 04:42:42 -0800 (PST)
Message-ID: <4EE9EB3E.4020707@xen.org>
Date: Thu, 15 Dec 2011 12:42:38 +0000
From: Lars Kurth <lars.kurth@xen.org>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, 
	"xen-api@lists.xensource.com" <xen-api@lists.xensource.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, 
	xen-arm@lists.xensource.com, xen-announce@lists.xensource.com
Subject: [Xen-devel] Xen Hackathon hosted by Oracle Confirmed
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1744291998484681551=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a multi-part message in MIME format.
--===============1744291998484681551==
Content-Type: multipart/alternative;
 boundary="------------050006080906080302060101"

This is a multi-part message in MIME format.
--------------050006080906080302060101
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi everybody,

I wanted to conform the date and location of the next Xen Hackathon and 
wanted to thank Oracle for hosting the Event.

Date: March 6-8
Location: Oracle campus in Santa Clara, CA, USA (*4030 George Sellon 
Circle, Santa Clara, CA 95054*)

I created a wiki page to help with the planning and preparation 
http://wiki.xen.org/wiki/Hackathon/March2012 - I am just about to go on 
vacation. More detail will follow early in January.

Best Regards
Lars

--------------050006080906080302060101
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Hi everybody,<br>
    <br>
    I wanted to conform the date and location of the next Xen Hackathon
    and wanted to thank Oracle for hosting the Event.<br>
    <br>
    Date: March 6-8 <br>
    Location: Oracle campus in Santa Clara, CA, USA (<b>4030 George
      Sellon Circle, Santa Clara, CA 95054</b>)<br>
    <br>
    I created a wiki page to help with the planning and preparation
    <a class="moz-txt-link-freetext" href="http://wiki.xen.org/wiki/Hackathon/March2012">http://wiki.xen.org/wiki/Hackathon/March2012</a> - I am just about to go
    on vacation. More detail will follow early in January.<br>
    <br>
    Best Regards<br>
    Lars<br>
  </body>
</html>

--------------050006080906080302060101--


--===============1744291998484681551==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============1744291998484681551==--


From xen-devel-bounces@lists.xensource.com Thu Dec 15 12:44:42 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 12:44:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbAfl-0005NW-FH; Thu, 15 Dec 2011 12:44:29 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RbAfj-0005Mt-QG
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 12:44:28 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-6.tower-174.messagelabs.com!1323953010!5684461!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 392 invoked from network); 15 Dec 2011 12:43:30 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-6.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 15 Dec 2011 12:43:30 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RbAen-0001ck-L0; Thu, 15 Dec 2011 12:43:29 +0000
Date: Thu, 15 Dec 2011 12:43:29 +0000
From: Tim Deegan <tim@xen.org>
To: Olaf Hering <olaf@aepfle.de>
Message-ID: <20111215124329.GD4274@ocelot.phlegethon.org>
References: <b25b2bcc2c6a987086bf.1323458635@probook.site>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <b25b2bcc2c6a987086bf.1323458635@probook.site>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] mem_event: use wait queue when ring is full
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi, 

At 20:23 +0100 on 09 Dec (1323462235), Olaf Hering wrote:
> mem_event: use wait queue when ring is full
> 
> This change is based on an idea/patch from Adin Scannell.
> 
> If the ring is full, put the current vcpu to sleep if it belongs to the
> target domain. The wakeup happens in the p2m_*_resume functions. Wakeup
> will take the number of free slots into account.
> 
> A request from foreign domain has to succeed once a slot was claimed
> because such vcpus can not sleep.
> 
> This change fixes also a bug in p2m_mem_paging_drop_page(). Up to now a
> full ring will lead to harmless inconsistency in the pager.
[...] 
> Signed-off-by: Olaf Hering <olaf@aepfle.de>

This patch is OK by me as it stands, so
Acked-by: Tim Deegan <tim@xen.org>

but I'll wait for an explicit ack from Andres or Adin before applying
it. 

Cheers,

Tim.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 12:44:42 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 12:44:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbAfl-0005NW-FH; Thu, 15 Dec 2011 12:44:29 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RbAfj-0005Mt-QG
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 12:44:28 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-6.tower-174.messagelabs.com!1323953010!5684461!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 392 invoked from network); 15 Dec 2011 12:43:30 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-6.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 15 Dec 2011 12:43:30 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RbAen-0001ck-L0; Thu, 15 Dec 2011 12:43:29 +0000
Date: Thu, 15 Dec 2011 12:43:29 +0000
From: Tim Deegan <tim@xen.org>
To: Olaf Hering <olaf@aepfle.de>
Message-ID: <20111215124329.GD4274@ocelot.phlegethon.org>
References: <b25b2bcc2c6a987086bf.1323458635@probook.site>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <b25b2bcc2c6a987086bf.1323458635@probook.site>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] mem_event: use wait queue when ring is full
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi, 

At 20:23 +0100 on 09 Dec (1323462235), Olaf Hering wrote:
> mem_event: use wait queue when ring is full
> 
> This change is based on an idea/patch from Adin Scannell.
> 
> If the ring is full, put the current vcpu to sleep if it belongs to the
> target domain. The wakeup happens in the p2m_*_resume functions. Wakeup
> will take the number of free slots into account.
> 
> A request from foreign domain has to succeed once a slot was claimed
> because such vcpus can not sleep.
> 
> This change fixes also a bug in p2m_mem_paging_drop_page(). Up to now a
> full ring will lead to harmless inconsistency in the pager.
[...] 
> Signed-off-by: Olaf Hering <olaf@aepfle.de>

This patch is OK by me as it stands, so
Acked-by: Tim Deegan <tim@xen.org>

but I'll wait for an explicit ack from Andres or Adin before applying
it. 

Cheers,

Tim.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 12:45:44 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 12:45:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbAgm-0005YE-V7; Thu, 15 Dec 2011 12:45:32 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RbAgl-0005XG-Ff
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 12:45:31 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1323953074!1637215!1
X-Originating-IP: [209.85.161.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30617 invoked from network); 15 Dec 2011 12:44:34 -0000
Received: from mail-fx0-f43.google.com (HELO mail-fx0-f43.google.com)
	(209.85.161.43)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 12:44:34 -0000
Received: by faap21 with SMTP id p21so4773104faa.30
	for <xen-devel@lists.xensource.com>;
	Thu, 15 Dec 2011 04:44:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=r+D+oMnw4cbpoyeixuF0sStQddpPQvmqBV5yfdWdBWM=;
	b=tPWDLjgN1+1ODzkxLPSzE6UpRDIHNGdL9NPBlYgwuPr3LnskS8BJ+V7VoVWFonCeGX
	7sYhSmvUk+kPSiM8Te8bOwaIZHAhnJa8msoz/olyD6lewV0HQfOzj360ZnSsvgoBCbm9
	ZopPDdcu6MHq0+bkZDvZJVQcxaVxDqi6oo0g8=
Received: by 10.180.75.204 with SMTP id e12mr4246349wiw.61.1323952589368;
	Thu, 15 Dec 2011 04:36:29 -0800 (PST)
Received: from [192.168.1.3] (host81-152-17-11.range81-152.btcentralplus.com.
	[81.152.17.11])
	by mx.google.com with ESMTPS id gd6sm9076941wbb.1.2011.12.15.04.36.28
	(version=SSLv3 cipher=OTHER); Thu, 15 Dec 2011 04:36:28 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Thu, 15 Dec 2011 12:36:27 +0000
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Message-ID: <CB0F9A4B.35FE7%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH] x86: convert BUG_ON()s to WARN_ON()s in
	read_descriptor()
Thread-Index: Acy7Jim4Az6hvr1LvUmes36CgkaAtA==
In-Reply-To: <4EE9D92A020000780006813A@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH] x86: convert BUG_ON()s to WARN_ON()s in
 read_descriptor()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 15/12/2011 10:25, "Jan Beulich" <JBeulich@suse.com> wrote:

> In the light of AMD erratum #700, and given that these checks happen
> for debugging purposes only and also only in debug builds of the
> hypervisor, make the failures non-fatal.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Is this erratum published?

> --- a/xen/arch/x86/traps.c
> +++ b/xen/arch/x86/traps.c
> @@ -1544,11 +1544,11 @@ static int read_descriptor(unsigned int
>              asm volatile (
>                  "larl %2,%0 ; setz %1"
>                  : "=r" (a), "=qm" (valid) : "rm" (sel));
> -            BUG_ON(valid && ((a & 0x00f0ff00) != *ar));
> +            WARN_ON(valid && ((a & 0x00f0ff00) != *ar));
>              asm volatile (
>                  "lsll %2,%0 ; setz %1"
>                  : "=r" (l), "=qm" (valid) : "rm" (sel));
> -            BUG_ON(valid && (l != *limit));
> +            WARN_ON(valid && (l != *limit));
>          }
>  #endif
>      }
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 12:45:44 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 12:45:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbAgm-0005YE-V7; Thu, 15 Dec 2011 12:45:32 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RbAgl-0005XG-Ff
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 12:45:31 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1323953074!1637215!1
X-Originating-IP: [209.85.161.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30617 invoked from network); 15 Dec 2011 12:44:34 -0000
Received: from mail-fx0-f43.google.com (HELO mail-fx0-f43.google.com)
	(209.85.161.43)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 12:44:34 -0000
Received: by faap21 with SMTP id p21so4773104faa.30
	for <xen-devel@lists.xensource.com>;
	Thu, 15 Dec 2011 04:44:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=r+D+oMnw4cbpoyeixuF0sStQddpPQvmqBV5yfdWdBWM=;
	b=tPWDLjgN1+1ODzkxLPSzE6UpRDIHNGdL9NPBlYgwuPr3LnskS8BJ+V7VoVWFonCeGX
	7sYhSmvUk+kPSiM8Te8bOwaIZHAhnJa8msoz/olyD6lewV0HQfOzj360ZnSsvgoBCbm9
	ZopPDdcu6MHq0+bkZDvZJVQcxaVxDqi6oo0g8=
Received: by 10.180.75.204 with SMTP id e12mr4246349wiw.61.1323952589368;
	Thu, 15 Dec 2011 04:36:29 -0800 (PST)
Received: from [192.168.1.3] (host81-152-17-11.range81-152.btcentralplus.com.
	[81.152.17.11])
	by mx.google.com with ESMTPS id gd6sm9076941wbb.1.2011.12.15.04.36.28
	(version=SSLv3 cipher=OTHER); Thu, 15 Dec 2011 04:36:28 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Thu, 15 Dec 2011 12:36:27 +0000
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Message-ID: <CB0F9A4B.35FE7%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH] x86: convert BUG_ON()s to WARN_ON()s in
	read_descriptor()
Thread-Index: Acy7Jim4Az6hvr1LvUmes36CgkaAtA==
In-Reply-To: <4EE9D92A020000780006813A@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH] x86: convert BUG_ON()s to WARN_ON()s in
 read_descriptor()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 15/12/2011 10:25, "Jan Beulich" <JBeulich@suse.com> wrote:

> In the light of AMD erratum #700, and given that these checks happen
> for debugging purposes only and also only in debug builds of the
> hypervisor, make the failures non-fatal.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Is this erratum published?

> --- a/xen/arch/x86/traps.c
> +++ b/xen/arch/x86/traps.c
> @@ -1544,11 +1544,11 @@ static int read_descriptor(unsigned int
>              asm volatile (
>                  "larl %2,%0 ; setz %1"
>                  : "=r" (a), "=qm" (valid) : "rm" (sel));
> -            BUG_ON(valid && ((a & 0x00f0ff00) != *ar));
> +            WARN_ON(valid && ((a & 0x00f0ff00) != *ar));
>              asm volatile (
>                  "lsll %2,%0 ; setz %1"
>                  : "=r" (l), "=qm" (valid) : "rm" (sel));
> -            BUG_ON(valid && (l != *limit));
> +            WARN_ON(valid && (l != *limit));
>          }
>  #endif
>      }
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 12:55:06 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 12:55:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbApp-0005wq-34; Thu, 15 Dec 2011 12:54:53 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <george.shuklin@gmail.com>) id 1RbApn-0005wl-SO
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 12:54:52 +0000
X-Env-Sender: george.shuklin@gmail.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1323953635!77975!1
X-Originating-IP: [209.85.215.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4071 invoked from network); 15 Dec 2011 12:53:55 -0000
Received: from mail-ey0-f171.google.com (HELO mail-ey0-f171.google.com)
	(209.85.215.171)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 12:53:55 -0000
Received: by eaad11 with SMTP id d11so371060eaa.30
	for <xen-devel@lists.xensource.com>;
	Thu, 15 Dec 2011 04:53:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=message-id:date:from:user-agent:mime-version:to:cc:subject
	:references:in-reply-to:content-type:content-transfer-encoding;
	bh=aH70KD01MskeeVSVTPDqyLaq10pkfxCtAuIgrRGrAGs=;
	b=s5JgKSy22C9Q6Fr8tjAl+BkbfixMLeknQ26gqgoRiKM3sR1YaoedfTvsTRwzJicYPk
	YKX67Rgl6lIW2oj3gM8aEMHpwzH5+eOeDBaL7ijH7Hl7L62U2MHNokU+TX+/uiwtXYqN
	vXtsHzhMpNNiKlVSdpo2eP35ARfuz8xPAgOps=
Received: by 10.204.129.24 with SMTP id m24mr786037bks.89.1323953145555;
	Thu, 15 Dec 2011 04:45:45 -0800 (PST)
Received: from [192.168.40.44] (officecvt.selectel.ru. [188.93.16.50])
	by mx.google.com with ESMTPS id q16sm14023522bky.10.2011.12.15.04.45.42
	(version=SSLv3 cipher=OTHER); Thu, 15 Dec 2011 04:45:44 -0800 (PST)
Message-ID: <4EE9EBF5.8000402@gmail.com>
Date: Thu, 15 Dec 2011 16:45:41 +0400
From: George Shuklin <george.shuklin@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:9.0) Gecko/20111209 Thunderbird/9.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <4EE675A8.3030609@niemail.de>	<4EE71663.5040308@gmail.com>
	<CAJeBh4sxdNTxM_oLFAuA6Mw75=LaYysrpS5b8NsZMbkf_swNVw@mail.gmail.com>
	<4EE72A94.6040904@gmail.com> <4EE75080.1000909@citrix.com>
	<1323783428.20077.298.camel@zakaz.uk.xensource.com>
	<4EE7BC9B.6040003@gmail.com>
	<1323815427.20936.96.camel@dagon.hellion.org.uk>
	<4EE7D75B.6080209@gmail.com>
	<1323847523.20936.110.camel@dagon.hellion.org.uk>
	<1323864969.20077.405.camel@zakaz.uk.xensource.com>
In-Reply-To: <1323864969.20077.405.camel@zakaz.uk.xensource.com>
Cc: "sandr8@gmail.com" <sandr8@gmail.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	David Vrabel <david.vrabel@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] a ton of kernel issues
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 14.12.2011 16:16, Ian Campbell wrote:
> I take it back, there is indeed a bug in the PV ops kernel in this
> regard.
>
> It works with xm/xend because they set the maximum reservation for
> guests to static-max on boot. xl (and, I think, xapi) instead set the
> maximum reservation to the current balloon target and change it
> dynamically as the target is changed (as a method of enforcing the
> targets). However the pvops kernel incorrectly uses the maximum
> reservation at boot to size the physical address space for guests.
>
> The patch below fixes this.
>
>
(skip)

I've checked this patch against current vanilla v3.2-rc5 - it fix 
problem I wrote about.

Is any chance that fix will go to release of 3.2?



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 12:55:06 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 12:55:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbApp-0005wq-34; Thu, 15 Dec 2011 12:54:53 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <george.shuklin@gmail.com>) id 1RbApn-0005wl-SO
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 12:54:52 +0000
X-Env-Sender: george.shuklin@gmail.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1323953635!77975!1
X-Originating-IP: [209.85.215.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4071 invoked from network); 15 Dec 2011 12:53:55 -0000
Received: from mail-ey0-f171.google.com (HELO mail-ey0-f171.google.com)
	(209.85.215.171)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 12:53:55 -0000
Received: by eaad11 with SMTP id d11so371060eaa.30
	for <xen-devel@lists.xensource.com>;
	Thu, 15 Dec 2011 04:53:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=message-id:date:from:user-agent:mime-version:to:cc:subject
	:references:in-reply-to:content-type:content-transfer-encoding;
	bh=aH70KD01MskeeVSVTPDqyLaq10pkfxCtAuIgrRGrAGs=;
	b=s5JgKSy22C9Q6Fr8tjAl+BkbfixMLeknQ26gqgoRiKM3sR1YaoedfTvsTRwzJicYPk
	YKX67Rgl6lIW2oj3gM8aEMHpwzH5+eOeDBaL7ijH7Hl7L62U2MHNokU+TX+/uiwtXYqN
	vXtsHzhMpNNiKlVSdpo2eP35ARfuz8xPAgOps=
Received: by 10.204.129.24 with SMTP id m24mr786037bks.89.1323953145555;
	Thu, 15 Dec 2011 04:45:45 -0800 (PST)
Received: from [192.168.40.44] (officecvt.selectel.ru. [188.93.16.50])
	by mx.google.com with ESMTPS id q16sm14023522bky.10.2011.12.15.04.45.42
	(version=SSLv3 cipher=OTHER); Thu, 15 Dec 2011 04:45:44 -0800 (PST)
Message-ID: <4EE9EBF5.8000402@gmail.com>
Date: Thu, 15 Dec 2011 16:45:41 +0400
From: George Shuklin <george.shuklin@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:9.0) Gecko/20111209 Thunderbird/9.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <4EE675A8.3030609@niemail.de>	<4EE71663.5040308@gmail.com>
	<CAJeBh4sxdNTxM_oLFAuA6Mw75=LaYysrpS5b8NsZMbkf_swNVw@mail.gmail.com>
	<4EE72A94.6040904@gmail.com> <4EE75080.1000909@citrix.com>
	<1323783428.20077.298.camel@zakaz.uk.xensource.com>
	<4EE7BC9B.6040003@gmail.com>
	<1323815427.20936.96.camel@dagon.hellion.org.uk>
	<4EE7D75B.6080209@gmail.com>
	<1323847523.20936.110.camel@dagon.hellion.org.uk>
	<1323864969.20077.405.camel@zakaz.uk.xensource.com>
In-Reply-To: <1323864969.20077.405.camel@zakaz.uk.xensource.com>
Cc: "sandr8@gmail.com" <sandr8@gmail.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	David Vrabel <david.vrabel@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] a ton of kernel issues
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 14.12.2011 16:16, Ian Campbell wrote:
> I take it back, there is indeed a bug in the PV ops kernel in this
> regard.
>
> It works with xm/xend because they set the maximum reservation for
> guests to static-max on boot. xl (and, I think, xapi) instead set the
> maximum reservation to the current balloon target and change it
> dynamically as the target is changed (as a method of enforcing the
> targets). However the pvops kernel incorrectly uses the maximum
> reservation at boot to size the physical address space for guests.
>
> The patch below fixes this.
>
>
(skip)

I've checked this patch against current vanilla v3.2-rc5 - it fix 
problem I wrote about.

Is any chance that fix will go to release of 3.2?



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 13:06:28 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 13:06:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbB0m-0006Qv-Vu; Thu, 15 Dec 2011 13:06:12 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RbB0m-0006Qq-0Y
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 13:06:12 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1323954365!7485818!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16209 invoked from network); 15 Dec 2011 13:06:05 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-10.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 15 Dec 2011 13:06:05 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 15 Dec 2011 13:06:05 +0000
Message-Id: <4EE9FECA020000780006821A@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 15 Dec 2011 13:06:02 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Keir Fraser" <keir@xen.org>
References: <4EE9D92A020000780006813A@nat28.tlf.novell.com>
	<CB0F9A4B.35FE7%keir@xen.org>
In-Reply-To: <CB0F9A4B.35FE7%keir@xen.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] x86: convert BUG_ON()s to WARN_ON()s in
 read_descriptor()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 15.12.11 at 13:36, Keir Fraser <keir@xen.org> wrote:
> On 15/12/2011 10:25, "Jan Beulich" <JBeulich@suse.com> wrote:
> 
>> In the light of AMD erratum #700, and given that these checks happen
>> for debugging purposes only and also only in debug builds of the
>> hypervisor, make the failures non-fatal.
>> 
>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> Is this erratum published?

Yes, it is in their most recent public revision guide.

Jan

>> --- a/xen/arch/x86/traps.c
>> +++ b/xen/arch/x86/traps.c
>> @@ -1544,11 +1544,11 @@ static int read_descriptor(unsigned int
>>              asm volatile (
>>                  "larl %2,%0 ; setz %1"
>>                  : "=r" (a), "=qm" (valid) : "rm" (sel));
>> -            BUG_ON(valid && ((a & 0x00f0ff00) != *ar));
>> +            WARN_ON(valid && ((a & 0x00f0ff00) != *ar));
>>              asm volatile (
>>                  "lsll %2,%0 ; setz %1"
>>                  : "=r" (l), "=qm" (valid) : "rm" (sel));
>> -            BUG_ON(valid && (l != *limit));
>> +            WARN_ON(valid && (l != *limit));
>>          }
>>  #endif
>>      }
>> 
>> 
>> 
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com 
>> http://lists.xensource.com/xen-devel 




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 13:06:28 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 13:06:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbB0m-0006Qv-Vu; Thu, 15 Dec 2011 13:06:12 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RbB0m-0006Qq-0Y
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 13:06:12 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1323954365!7485818!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16209 invoked from network); 15 Dec 2011 13:06:05 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-10.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 15 Dec 2011 13:06:05 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 15 Dec 2011 13:06:05 +0000
Message-Id: <4EE9FECA020000780006821A@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 15 Dec 2011 13:06:02 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Keir Fraser" <keir@xen.org>
References: <4EE9D92A020000780006813A@nat28.tlf.novell.com>
	<CB0F9A4B.35FE7%keir@xen.org>
In-Reply-To: <CB0F9A4B.35FE7%keir@xen.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] x86: convert BUG_ON()s to WARN_ON()s in
 read_descriptor()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 15.12.11 at 13:36, Keir Fraser <keir@xen.org> wrote:
> On 15/12/2011 10:25, "Jan Beulich" <JBeulich@suse.com> wrote:
> 
>> In the light of AMD erratum #700, and given that these checks happen
>> for debugging purposes only and also only in debug builds of the
>> hypervisor, make the failures non-fatal.
>> 
>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> Is this erratum published?

Yes, it is in their most recent public revision guide.

Jan

>> --- a/xen/arch/x86/traps.c
>> +++ b/xen/arch/x86/traps.c
>> @@ -1544,11 +1544,11 @@ static int read_descriptor(unsigned int
>>              asm volatile (
>>                  "larl %2,%0 ; setz %1"
>>                  : "=r" (a), "=qm" (valid) : "rm" (sel));
>> -            BUG_ON(valid && ((a & 0x00f0ff00) != *ar));
>> +            WARN_ON(valid && ((a & 0x00f0ff00) != *ar));
>>              asm volatile (
>>                  "lsll %2,%0 ; setz %1"
>>                  : "=r" (l), "=qm" (valid) : "rm" (sel));
>> -            BUG_ON(valid && (l != *limit));
>> +            WARN_ON(valid && (l != *limit));
>>          }
>>  #endif
>>      }
>> 
>> 
>> 
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com 
>> http://lists.xensource.com/xen-devel 




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 13:08:40 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 13:08:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbB2v-0006Wf-Gn; Thu, 15 Dec 2011 13:08:25 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RbB2t-0006WN-Fp
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 13:08:23 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1323954497!5688871!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16250 invoked from network); 15 Dec 2011 13:08:17 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-6.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 15 Dec 2011 13:08:17 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 15 Dec 2011 13:08:16 +0000
Message-Id: <4EE9FF4D020000780006821D@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 15 Dec 2011 13:08:13 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Keir Fraser" <keir@xen.org>
References: <CB0F9814.35F61%keir@xen.org> <CB0F9989.35F66%keir@xen.org>
In-Reply-To: <CB0F9989.35F66%keir@xen.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Paolo Bonzini <pbonzini@redhat.com>, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] fsincos emulation on AMD CPUs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 15.12.11 at 13:33, Keir Fraser <keir@xen.org> wrote:
> More detail: the full patch is ugly and hard to test all cases. And there's
> no practical scenario where we want to emulate FSINCOS on AMD -- we don't
> emulate realmode on AMD, FSINCOS on a shadowed page certainly indicates that
> we should unshadow the page, FSINCOS on MMIO is mad or malicious.

Those latter two cases can't really happen, as fsincos has no memory
operand.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 13:08:40 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 13:08:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbB2v-0006Wf-Gn; Thu, 15 Dec 2011 13:08:25 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RbB2t-0006WN-Fp
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 13:08:23 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1323954497!5688871!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16250 invoked from network); 15 Dec 2011 13:08:17 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-6.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 15 Dec 2011 13:08:17 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 15 Dec 2011 13:08:16 +0000
Message-Id: <4EE9FF4D020000780006821D@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 15 Dec 2011 13:08:13 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Keir Fraser" <keir@xen.org>
References: <CB0F9814.35F61%keir@xen.org> <CB0F9989.35F66%keir@xen.org>
In-Reply-To: <CB0F9989.35F66%keir@xen.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Paolo Bonzini <pbonzini@redhat.com>, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] fsincos emulation on AMD CPUs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 15.12.11 at 13:33, Keir Fraser <keir@xen.org> wrote:
> More detail: the full patch is ugly and hard to test all cases. And there's
> no practical scenario where we want to emulate FSINCOS on AMD -- we don't
> emulate realmode on AMD, FSINCOS on a shadowed page certainly indicates that
> we should unshadow the page, FSINCOS on MMIO is mad or malicious.

Those latter two cases can't really happen, as fsincos has no memory
operand.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 13:10:52 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 13:10:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbB57-0006mS-UN; Thu, 15 Dec 2011 13:10:41 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RbB56-0006ld-T2
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 13:10:41 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1323954595!50754237!1
X-Originating-IP: [209.85.161.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16101 invoked from network); 15 Dec 2011 13:09:55 -0000
Received: from mail-fx0-f43.google.com (HELO mail-fx0-f43.google.com)
	(209.85.161.43)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 13:09:55 -0000
Received: by faap21 with SMTP id p21so4860683faa.30
	for <xen-devel@lists.xensource.com>;
	Thu, 15 Dec 2011 05:10:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=ihitbHiTsgXJEgMZnFUy1XygvkfFkACmnAJTPPjYZdU=;
	b=LTbY4MV6BD+ab+/FU27CQok0KfLdu+Udyl5iJbEcV26Cxgi6L1eJ5jqWn3FgMbP7/R
	WJiEE9o84DHKQdQ/HbMS25y81wRIWDrM0eo7TNJ5Thxm65gA3D1b+BC2yP8x9qfzlF3w
	e3AdkLgkqFvTgv1PvyyMNUpS5Zjii7y2dF2yI=
Received: by 10.180.19.138 with SMTP id f10mr4677825wie.53.1323954634593;
	Thu, 15 Dec 2011 05:10:34 -0800 (PST)
Received: from [192.168.1.3] (host81-152-17-11.range81-152.btcentralplus.com.
	[81.152.17.11])
	by mx.google.com with ESMTPS id dd4sm8216970wib.1.2011.12.15.05.10.32
	(version=SSLv3 cipher=OTHER); Thu, 15 Dec 2011 05:10:34 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Thu, 15 Dec 2011 13:10:30 +0000
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <CB0FA246.35FFD%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH] x86: convert BUG_ON()s to WARN_ON()s in
	read_descriptor()
Thread-Index: Acy7KutxMDXE5/tSzUqgKjxrK7UtTQ==
In-Reply-To: <4EE9FECA020000780006821A@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] x86: convert BUG_ON()s to WARN_ON()s in
 read_descriptor()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 15/12/2011 13:06, "Jan Beulich" <JBeulich@suse.com> wrote:

>>>> On 15.12.11 at 13:36, Keir Fraser <keir@xen.org> wrote:
>> On 15/12/2011 10:25, "Jan Beulich" <JBeulich@suse.com> wrote:
>> 
>>> In the light of AMD erratum #700, and given that these checks happen
>>> for debugging purposes only and also only in debug builds of the
>>> hypervisor, make the failures non-fatal.
>>> 
>>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>> 
>> Is this erratum published?
> 
> Yes, it is in their most recent public revision guide.

Do you have a link? I can't find a published erratum > #686.

 -- Keir

> Jan
> 
>>> --- a/xen/arch/x86/traps.c
>>> +++ b/xen/arch/x86/traps.c
>>> @@ -1544,11 +1544,11 @@ static int read_descriptor(unsigned int
>>>              asm volatile (
>>>                  "larl %2,%0 ; setz %1"
>>>                  : "=r" (a), "=qm" (valid) : "rm" (sel));
>>> -            BUG_ON(valid && ((a & 0x00f0ff00) != *ar));
>>> +            WARN_ON(valid && ((a & 0x00f0ff00) != *ar));
>>>              asm volatile (
>>>                  "lsll %2,%0 ; setz %1"
>>>                  : "=r" (l), "=qm" (valid) : "rm" (sel));
>>> -            BUG_ON(valid && (l != *limit));
>>> +            WARN_ON(valid && (l != *limit));
>>>          }
>>>  #endif
>>>      }
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> Xen-devel mailing list
>>> Xen-devel@lists.xensource.com
>>> http://lists.xensource.com/xen-devel
> 
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 13:10:52 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 13:10:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbB57-0006mS-UN; Thu, 15 Dec 2011 13:10:41 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RbB56-0006ld-T2
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 13:10:41 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1323954595!50754237!1
X-Originating-IP: [209.85.161.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16101 invoked from network); 15 Dec 2011 13:09:55 -0000
Received: from mail-fx0-f43.google.com (HELO mail-fx0-f43.google.com)
	(209.85.161.43)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 13:09:55 -0000
Received: by faap21 with SMTP id p21so4860683faa.30
	for <xen-devel@lists.xensource.com>;
	Thu, 15 Dec 2011 05:10:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=ihitbHiTsgXJEgMZnFUy1XygvkfFkACmnAJTPPjYZdU=;
	b=LTbY4MV6BD+ab+/FU27CQok0KfLdu+Udyl5iJbEcV26Cxgi6L1eJ5jqWn3FgMbP7/R
	WJiEE9o84DHKQdQ/HbMS25y81wRIWDrM0eo7TNJ5Thxm65gA3D1b+BC2yP8x9qfzlF3w
	e3AdkLgkqFvTgv1PvyyMNUpS5Zjii7y2dF2yI=
Received: by 10.180.19.138 with SMTP id f10mr4677825wie.53.1323954634593;
	Thu, 15 Dec 2011 05:10:34 -0800 (PST)
Received: from [192.168.1.3] (host81-152-17-11.range81-152.btcentralplus.com.
	[81.152.17.11])
	by mx.google.com with ESMTPS id dd4sm8216970wib.1.2011.12.15.05.10.32
	(version=SSLv3 cipher=OTHER); Thu, 15 Dec 2011 05:10:34 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Thu, 15 Dec 2011 13:10:30 +0000
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <CB0FA246.35FFD%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH] x86: convert BUG_ON()s to WARN_ON()s in
	read_descriptor()
Thread-Index: Acy7KutxMDXE5/tSzUqgKjxrK7UtTQ==
In-Reply-To: <4EE9FECA020000780006821A@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] x86: convert BUG_ON()s to WARN_ON()s in
 read_descriptor()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 15/12/2011 13:06, "Jan Beulich" <JBeulich@suse.com> wrote:

>>>> On 15.12.11 at 13:36, Keir Fraser <keir@xen.org> wrote:
>> On 15/12/2011 10:25, "Jan Beulich" <JBeulich@suse.com> wrote:
>> 
>>> In the light of AMD erratum #700, and given that these checks happen
>>> for debugging purposes only and also only in debug builds of the
>>> hypervisor, make the failures non-fatal.
>>> 
>>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>> 
>> Is this erratum published?
> 
> Yes, it is in their most recent public revision guide.

Do you have a link? I can't find a published erratum > #686.

 -- Keir

> Jan
> 
>>> --- a/xen/arch/x86/traps.c
>>> +++ b/xen/arch/x86/traps.c
>>> @@ -1544,11 +1544,11 @@ static int read_descriptor(unsigned int
>>>              asm volatile (
>>>                  "larl %2,%0 ; setz %1"
>>>                  : "=r" (a), "=qm" (valid) : "rm" (sel));
>>> -            BUG_ON(valid && ((a & 0x00f0ff00) != *ar));
>>> +            WARN_ON(valid && ((a & 0x00f0ff00) != *ar));
>>>              asm volatile (
>>>                  "lsll %2,%0 ; setz %1"
>>>                  : "=r" (l), "=qm" (valid) : "rm" (sel));
>>> -            BUG_ON(valid && (l != *limit));
>>> +            WARN_ON(valid && (l != *limit));
>>>          }
>>>  #endif
>>>      }
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> Xen-devel mailing list
>>> Xen-devel@lists.xensource.com
>>> http://lists.xensource.com/xen-devel
> 
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 13:14:27 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 13:14:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbB8X-0007BB-OO; Thu, 15 Dec 2011 13:14:13 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RbB8V-0007Ah-FG
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 13:14:12 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1323954844!7524754!1
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26190 invoked from network); 15 Dec 2011 13:14:05 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 13:14:05 -0000
Received: by wgbds11 with SMTP id ds11so3411014wgb.24
	for <xen-devel@lists.xensource.com>;
	Thu, 15 Dec 2011 05:14:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=T49FpIMgaQR4uwBv8Hr6Hp9KccUOe7ysHMlPk712ckQ=;
	b=gk0RevH2EN5adThA8aBPjnS08XTo64W3+ln78xV3TXsV2vqELWGZEyYNp6wRBNpHYh
	cuEqj7oMenXNhhwcdjT8iBtc/mQSL6A7PRgaPtnL3zco7fV2Igv80WswaDlrS+tZoy0f
	gDCHegZ+qVNzJIZDs+K+UD/eYf7WP9lEIlTxA=
Received: by 10.227.57.141 with SMTP id c13mr2166338wbh.25.1323954844023;
	Thu, 15 Dec 2011 05:14:04 -0800 (PST)
Received: from [192.168.1.3] (host81-152-17-11.range81-152.btcentralplus.com.
	[81.152.17.11])
	by mx.google.com with ESMTPS id bl10sm8194834wib.15.2011.12.15.05.14.02
	(version=SSLv3 cipher=OTHER); Thu, 15 Dec 2011 05:14:03 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Thu, 15 Dec 2011 13:13:58 +0000
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <CB0FA316.36001%keir@xen.org>
Thread-Topic: [Xen-devel] fsincos emulation on AMD CPUs
Thread-Index: Acy7K2dr1qaUWoglu0O9DDUjmy0qpA==
In-Reply-To: <4EE9FF4D020000780006821D@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: Paolo Bonzini <pbonzini@redhat.com>, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] fsincos emulation on AMD CPUs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 15/12/2011 13:08, "Jan Beulich" <JBeulich@suse.com> wrote:

>>>> On 15.12.11 at 13:33, Keir Fraser <keir@xen.org> wrote:
>> More detail: the full patch is ugly and hard to test all cases. And there's
>> no practical scenario where we want to emulate FSINCOS on AMD -- we don't
>> emulate realmode on AMD, FSINCOS on a shadowed page certainly indicates that
>> we should unshadow the page, FSINCOS on MMIO is mad or malicious.
> 
> Those latter two cases can't really happen, as fsincos has no memory
> operand.

Possibly if the instruction itself was in a recycled page-table page? Or in
an MMIO page, or the malicious race that Paolo described --- definitely
malicious either way.

Anyhow the short answer is we never want to emulate it on AMD. :-)

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 13:14:27 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 13:14:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbB8X-0007BB-OO; Thu, 15 Dec 2011 13:14:13 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RbB8V-0007Ah-FG
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 13:14:12 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1323954844!7524754!1
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26190 invoked from network); 15 Dec 2011 13:14:05 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 13:14:05 -0000
Received: by wgbds11 with SMTP id ds11so3411014wgb.24
	for <xen-devel@lists.xensource.com>;
	Thu, 15 Dec 2011 05:14:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=T49FpIMgaQR4uwBv8Hr6Hp9KccUOe7ysHMlPk712ckQ=;
	b=gk0RevH2EN5adThA8aBPjnS08XTo64W3+ln78xV3TXsV2vqELWGZEyYNp6wRBNpHYh
	cuEqj7oMenXNhhwcdjT8iBtc/mQSL6A7PRgaPtnL3zco7fV2Igv80WswaDlrS+tZoy0f
	gDCHegZ+qVNzJIZDs+K+UD/eYf7WP9lEIlTxA=
Received: by 10.227.57.141 with SMTP id c13mr2166338wbh.25.1323954844023;
	Thu, 15 Dec 2011 05:14:04 -0800 (PST)
Received: from [192.168.1.3] (host81-152-17-11.range81-152.btcentralplus.com.
	[81.152.17.11])
	by mx.google.com with ESMTPS id bl10sm8194834wib.15.2011.12.15.05.14.02
	(version=SSLv3 cipher=OTHER); Thu, 15 Dec 2011 05:14:03 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Thu, 15 Dec 2011 13:13:58 +0000
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <CB0FA316.36001%keir@xen.org>
Thread-Topic: [Xen-devel] fsincos emulation on AMD CPUs
Thread-Index: Acy7K2dr1qaUWoglu0O9DDUjmy0qpA==
In-Reply-To: <4EE9FF4D020000780006821D@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: Paolo Bonzini <pbonzini@redhat.com>, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] fsincos emulation on AMD CPUs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 15/12/2011 13:08, "Jan Beulich" <JBeulich@suse.com> wrote:

>>>> On 15.12.11 at 13:33, Keir Fraser <keir@xen.org> wrote:
>> More detail: the full patch is ugly and hard to test all cases. And there's
>> no practical scenario where we want to emulate FSINCOS on AMD -- we don't
>> emulate realmode on AMD, FSINCOS on a shadowed page certainly indicates that
>> we should unshadow the page, FSINCOS on MMIO is mad or malicious.
> 
> Those latter two cases can't really happen, as fsincos has no memory
> operand.

Possibly if the instruction itself was in a recycled page-table page? Or in
an MMIO page, or the malicious race that Paolo described --- definitely
malicious either way.

Anyhow the short answer is we never want to emulate it on AMD. :-)

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 13:16:30 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 13: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.xensource.com>)
	id 1RbBAX-0007Je-96; Thu, 15 Dec 2011 13:16:17 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RbBAV-0007J2-QN
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 13:16:16 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-14.tower-216.messagelabs.com!1323954968!7022250!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMTA3ODk=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMTA3ODk=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17371 invoked from network); 15 Dec 2011 13:16:09 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-14.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 15 Dec 2011 13:16:09 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1323954968; l=401;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=HbcsidKVXWt6sIuD3JJsPbhF9J4=;
	b=e04CeNf300xUjz/C/FYdLpdMxlvLfK/GcO0u/pivvaVE/wUjmuD2axZkUzU+kNUDrKa
	KCrs8iWDCj7quB/gKRXbi3h4j1blgK+l2UxbeKAAOB3L4Sz91fMMfyRtT4Tga3TpotqDa
	tfqyWBcpuAlKnV56JQkAvY6Qcq1hBZP6KW8=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lr3s7jGzY=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-067-089.pools.arcor-ip.net [84.57.67.89])
	by smtp.strato.de (jimi mo1) (RZmta 26.15 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id e043c7nBFBxoJY ;
	Thu, 15 Dec 2011 14:15:59 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id CF98A18637; Thu, 15 Dec 2011 14:15:58 +0100 (CET)
Date: Thu, 15 Dec 2011 14:15:58 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Tim Deegan <tim@xen.org>
Message-ID: <20111215131558.GA15903@aepfle.de>
References: <b25b2bcc2c6a987086bf.1323458635@probook.site>
	<20111215124329.GD4274@ocelot.phlegethon.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20111215124329.GD4274@ocelot.phlegethon.org>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] mem_event: use wait queue when ring is full
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Dec 15, Tim Deegan wrote:

> This patch is OK by me as it stands, so
> Acked-by: Tim Deegan <tim@xen.org>
> 
> but I'll wait for an explicit ack from Andres or Adin before applying
> it. 

Thanks.

I will add some sort of accounting as it is done in the version from
Andres, so that each vcpu can place at least one request.
Hopefully I will send v7 of my change out today.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 13:16:30 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 13: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.xensource.com>)
	id 1RbBAX-0007Je-96; Thu, 15 Dec 2011 13:16:17 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RbBAV-0007J2-QN
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 13:16:16 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-14.tower-216.messagelabs.com!1323954968!7022250!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMTA3ODk=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMTA3ODk=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17371 invoked from network); 15 Dec 2011 13:16:09 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-14.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 15 Dec 2011 13:16:09 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1323954968; l=401;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=HbcsidKVXWt6sIuD3JJsPbhF9J4=;
	b=e04CeNf300xUjz/C/FYdLpdMxlvLfK/GcO0u/pivvaVE/wUjmuD2axZkUzU+kNUDrKa
	KCrs8iWDCj7quB/gKRXbi3h4j1blgK+l2UxbeKAAOB3L4Sz91fMMfyRtT4Tga3TpotqDa
	tfqyWBcpuAlKnV56JQkAvY6Qcq1hBZP6KW8=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lr3s7jGzY=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-067-089.pools.arcor-ip.net [84.57.67.89])
	by smtp.strato.de (jimi mo1) (RZmta 26.15 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id e043c7nBFBxoJY ;
	Thu, 15 Dec 2011 14:15:59 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id CF98A18637; Thu, 15 Dec 2011 14:15:58 +0100 (CET)
Date: Thu, 15 Dec 2011 14:15:58 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Tim Deegan <tim@xen.org>
Message-ID: <20111215131558.GA15903@aepfle.de>
References: <b25b2bcc2c6a987086bf.1323458635@probook.site>
	<20111215124329.GD4274@ocelot.phlegethon.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20111215124329.GD4274@ocelot.phlegethon.org>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] mem_event: use wait queue when ring is full
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Dec 15, Tim Deegan wrote:

> This patch is OK by me as it stands, so
> Acked-by: Tim Deegan <tim@xen.org>
> 
> but I'll wait for an explicit ack from Andres or Adin before applying
> it. 

Thanks.

I will add some sort of accounting as it is done in the version from
Andres, so that each vcpu can place at least one request.
Hopefully I will send v7 of my change out today.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 13:16:45 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 13: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.xensource.com>)
	id 1RbBAm-0007Lk-Mz; Thu, 15 Dec 2011 13:16:32 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RbBAk-0007Kf-MY
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 13:16:31 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1323954983!5690199!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29468 invoked from network); 15 Dec 2011 13:16:23 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-11.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 15 Dec 2011 13:16:23 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 15 Dec 2011 13:16:23 +0000
Message-Id: <4EEA01350200007800068241@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 15 Dec 2011 13:16:21 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part0926A335.0__="
Subject: [Xen-devel] [PATCH] x86/emulator: workaround for AMD erratum 573
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__Part0926A335.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

The only cases where we might end up emulating fsincos (as any other
x87 operations without memory operands) are
- when a HVM guest is in real mode (not applicable on AMD)
- between two half page table updates in PAE mode (unlikely, and not
  doing the emulation here does affect only performance, not
  correctness)
- when a guest maliciously (or erroneously) modifies an (MMIO or page
  table update) instruction under emulation (unspecified behavior)

Hence, in order to avoid the erratum to cause harm to the entire host,
don't emulate fsincos on the affected AMD CPU families.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/tools/tests/x86_emulator/x86_emulate.c
+++ b/tools/tests/x86_emulator/x86_emulate.c
@@ -9,5 +9,7 @@ typedef bool bool_t;
=20
 #define BUG() abort()
=20
+#define cpu_has_amd_erratum(nr) 0
+
 #include "x86_emulate/x86_emulate.h"
 #include "x86_emulate/x86_emulate.c"
--- a/xen/arch/x86/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate.c
@@ -10,8 +10,14 @@
  */
=20
 #include <asm/x86_emulate.h>
+#include <asm/processor.h> /* current_cpu_info */
+#include <asm/amd.h> /* cpu_has_amd_erratum() */
=20
 /* Avoid namespace pollution. */
 #undef cmpxchg
+#undef cpuid
+
+#define cpu_has_amd_erratum(nr) \
+        cpu_has_amd_erratum(&current_cpu_data, AMD_ERRATUM_##nr)
=20
 #include "x86_emulate/x86_emulate.c"
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -2761,6 +2761,9 @@ x86_emulate(
     case 0xd9: /* FPU 0xd9 */
         switch ( modrm )
         {
+        case 0xfb: /* fsincos */
+            fail_if(cpu_has_amd_erratum(573));
+            /* fall through */
         case 0xc0 ... 0xc7: /* fld %stN */
         case 0xc8 ... 0xcf: /* fxch %stN */
         case 0xd0: /* fnop */
@@ -2786,7 +2789,6 @@ x86_emulate(
         case 0xf8: /* fprem */
         case 0xf9: /* fyl2xp1 */
         case 0xfa: /* fsqrt */
-        case 0xfb: /* fsincos */
         case 0xfc: /* frndint */
         case 0xfd: /* fscale */
         case 0xfe: /* fsin */
--- a/xen/include/asm-x86/amd.h
+++ b/xen/include/asm-x86/amd.h
@@ -134,6 +134,12 @@
     AMD_OSVW_ERRATUM(3, AMD_MODEL_RANGE(0x10, 0x2, 0x1, 0xff, 0xf),	\
 		        AMD_MODEL_RANGE(0x12, 0x0, 0x0, 0x1, 0x0))
=20
+#define AMD_ERRATUM_573							=
\
+    AMD_LEGACY_ERRATUM(AMD_MODEL_RANGE(0x0f, 0x0, 0x0, 0xff, 0xf),	\
+                       AMD_MODEL_RANGE(0x10, 0x0, 0x0, 0xff, 0xf),	\
+                       AMD_MODEL_RANGE(0x11, 0x0, 0x0, 0xff, 0xf),	\
+                       AMD_MODEL_RANGE(0x12, 0x0, 0x0, 0xff, 0xf))
+
 struct cpuinfo_x86;
 int cpu_has_amd_erratum(const struct cpuinfo_x86 *, int, ...);
=20




--=__Part0926A335.0__=
Content-Type: text/plain; name="amd-erratum-573.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="amd-erratum-573.patch"

x86/emulator: workaround for AMD erratum 573=0A=0AThe only cases where we =
might end up emulating fsincos (as any other=0Ax87 operations without =
memory operands) are=0A- when a HVM guest is in real mode (not applicable =
on AMD)=0A- between two half page table updates in PAE mode (unlikely, and =
not=0A  doing the emulation here does affect only performance, not=0A  =
correctness)=0A- when a guest maliciously (or erroneously) modifies an =
(MMIO or page=0A  table update) instruction under emulation (unspecified =
behavior)=0A=0AHence, in order to avoid the erratum to cause harm to the =
entire host,=0Adon't emulate fsincos on the affected AMD CPU families.=0A=
=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=0A=0A--- a/tools/tests/x8=
6_emulator/x86_emulate.c=0A+++ b/tools/tests/x86_emulator/x86_emulate.c=0A@=
@ -9,5 +9,7 @@ typedef bool bool_t;=0A =0A #define BUG() abort()=0A =
=0A+#define cpu_has_amd_erratum(nr) 0=0A+=0A #include "x86_emulate/x86_emul=
ate.h"=0A #include "x86_emulate/x86_emulate.c"=0A--- a/xen/arch/x86/x86_emu=
late.c=0A+++ b/xen/arch/x86/x86_emulate.c=0A@@ -10,8 +10,14 @@=0A  */=0A =
=0A #include <asm/x86_emulate.h>=0A+#include <asm/processor.h> /* =
current_cpu_info */=0A+#include <asm/amd.h> /* cpu_has_amd_erratum() */=0A =
=0A /* Avoid namespace pollution. */=0A #undef cmpxchg=0A+#undef =
cpuid=0A+=0A+#define cpu_has_amd_erratum(nr) \=0A+        cpu_has_amd_errat=
um(&current_cpu_data, AMD_ERRATUM_##nr)=0A =0A #include "x86_emulate/x86_em=
ulate.c"=0A--- a/xen/arch/x86/x86_emulate/x86_emulate.c=0A+++ b/xen/arch/x8=
6/x86_emulate/x86_emulate.c=0A@@ -2761,6 +2761,9 @@ x86_emulate(=0A     =
case 0xd9: /* FPU 0xd9 */=0A         switch ( modrm )=0A         {=0A+     =
   case 0xfb: /* fsincos */=0A+            fail_if(cpu_has_amd_erratum(573)=
);=0A+            /* fall through */=0A         case 0xc0 ... 0xc7: /* fld =
%stN */=0A         case 0xc8 ... 0xcf: /* fxch %stN */=0A         case =
0xd0: /* fnop */=0A@@ -2786,7 +2789,6 @@ x86_emulate(=0A         case =
0xf8: /* fprem */=0A         case 0xf9: /* fyl2xp1 */=0A         case =
0xfa: /* fsqrt */=0A-        case 0xfb: /* fsincos */=0A         case =
0xfc: /* frndint */=0A         case 0xfd: /* fscale */=0A         case =
0xfe: /* fsin */=0A--- a/xen/include/asm-x86/amd.h=0A+++ b/xen/include/asm-=
x86/amd.h=0A@@ -134,6 +134,12 @@=0A     AMD_OSVW_ERRATUM(3, AMD_MODEL_RANGE=
(0x10, 0x2, 0x1, 0xff, 0xf),	\=0A 		        AMD_MODEL_RANGE(0x1=
2, 0x0, 0x0, 0x1, 0x0))=0A =0A+#define AMD_ERRATUM_573				=
			\=0A+    AMD_LEGACY_ERRATUM(AMD_MODEL_RANGE(0x0f, =
0x0, 0x0, 0xff, 0xf),	\=0A+                       AMD_MODEL_RANGE(0x10, =
0x0, 0x0, 0xff, 0xf),	\=0A+                       AMD_MODEL_RANGE(0x11, =
0x0, 0x0, 0xff, 0xf),	\=0A+                       AMD_MODEL_RANGE(0x12, =
0x0, 0x0, 0xff, 0xf))=0A+=0A struct cpuinfo_x86;=0A int cpu_has_amd_erratum=
(const struct cpuinfo_x86 *, int, ...);=0A =0A
--=__Part0926A335.0__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--=__Part0926A335.0__=--


From xen-devel-bounces@lists.xensource.com Thu Dec 15 13:16:45 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 13: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.xensource.com>)
	id 1RbBAm-0007Lk-Mz; Thu, 15 Dec 2011 13:16:32 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RbBAk-0007Kf-MY
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 13:16:31 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1323954983!5690199!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29468 invoked from network); 15 Dec 2011 13:16:23 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-11.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 15 Dec 2011 13:16:23 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 15 Dec 2011 13:16:23 +0000
Message-Id: <4EEA01350200007800068241@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 15 Dec 2011 13:16:21 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part0926A335.0__="
Subject: [Xen-devel] [PATCH] x86/emulator: workaround for AMD erratum 573
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__Part0926A335.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

The only cases where we might end up emulating fsincos (as any other
x87 operations without memory operands) are
- when a HVM guest is in real mode (not applicable on AMD)
- between two half page table updates in PAE mode (unlikely, and not
  doing the emulation here does affect only performance, not
  correctness)
- when a guest maliciously (or erroneously) modifies an (MMIO or page
  table update) instruction under emulation (unspecified behavior)

Hence, in order to avoid the erratum to cause harm to the entire host,
don't emulate fsincos on the affected AMD CPU families.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/tools/tests/x86_emulator/x86_emulate.c
+++ b/tools/tests/x86_emulator/x86_emulate.c
@@ -9,5 +9,7 @@ typedef bool bool_t;
=20
 #define BUG() abort()
=20
+#define cpu_has_amd_erratum(nr) 0
+
 #include "x86_emulate/x86_emulate.h"
 #include "x86_emulate/x86_emulate.c"
--- a/xen/arch/x86/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate.c
@@ -10,8 +10,14 @@
  */
=20
 #include <asm/x86_emulate.h>
+#include <asm/processor.h> /* current_cpu_info */
+#include <asm/amd.h> /* cpu_has_amd_erratum() */
=20
 /* Avoid namespace pollution. */
 #undef cmpxchg
+#undef cpuid
+
+#define cpu_has_amd_erratum(nr) \
+        cpu_has_amd_erratum(&current_cpu_data, AMD_ERRATUM_##nr)
=20
 #include "x86_emulate/x86_emulate.c"
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -2761,6 +2761,9 @@ x86_emulate(
     case 0xd9: /* FPU 0xd9 */
         switch ( modrm )
         {
+        case 0xfb: /* fsincos */
+            fail_if(cpu_has_amd_erratum(573));
+            /* fall through */
         case 0xc0 ... 0xc7: /* fld %stN */
         case 0xc8 ... 0xcf: /* fxch %stN */
         case 0xd0: /* fnop */
@@ -2786,7 +2789,6 @@ x86_emulate(
         case 0xf8: /* fprem */
         case 0xf9: /* fyl2xp1 */
         case 0xfa: /* fsqrt */
-        case 0xfb: /* fsincos */
         case 0xfc: /* frndint */
         case 0xfd: /* fscale */
         case 0xfe: /* fsin */
--- a/xen/include/asm-x86/amd.h
+++ b/xen/include/asm-x86/amd.h
@@ -134,6 +134,12 @@
     AMD_OSVW_ERRATUM(3, AMD_MODEL_RANGE(0x10, 0x2, 0x1, 0xff, 0xf),	\
 		        AMD_MODEL_RANGE(0x12, 0x0, 0x0, 0x1, 0x0))
=20
+#define AMD_ERRATUM_573							=
\
+    AMD_LEGACY_ERRATUM(AMD_MODEL_RANGE(0x0f, 0x0, 0x0, 0xff, 0xf),	\
+                       AMD_MODEL_RANGE(0x10, 0x0, 0x0, 0xff, 0xf),	\
+                       AMD_MODEL_RANGE(0x11, 0x0, 0x0, 0xff, 0xf),	\
+                       AMD_MODEL_RANGE(0x12, 0x0, 0x0, 0xff, 0xf))
+
 struct cpuinfo_x86;
 int cpu_has_amd_erratum(const struct cpuinfo_x86 *, int, ...);
=20




--=__Part0926A335.0__=
Content-Type: text/plain; name="amd-erratum-573.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="amd-erratum-573.patch"

x86/emulator: workaround for AMD erratum 573=0A=0AThe only cases where we =
might end up emulating fsincos (as any other=0Ax87 operations without =
memory operands) are=0A- when a HVM guest is in real mode (not applicable =
on AMD)=0A- between two half page table updates in PAE mode (unlikely, and =
not=0A  doing the emulation here does affect only performance, not=0A  =
correctness)=0A- when a guest maliciously (or erroneously) modifies an =
(MMIO or page=0A  table update) instruction under emulation (unspecified =
behavior)=0A=0AHence, in order to avoid the erratum to cause harm to the =
entire host,=0Adon't emulate fsincos on the affected AMD CPU families.=0A=
=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=0A=0A--- a/tools/tests/x8=
6_emulator/x86_emulate.c=0A+++ b/tools/tests/x86_emulator/x86_emulate.c=0A@=
@ -9,5 +9,7 @@ typedef bool bool_t;=0A =0A #define BUG() abort()=0A =
=0A+#define cpu_has_amd_erratum(nr) 0=0A+=0A #include "x86_emulate/x86_emul=
ate.h"=0A #include "x86_emulate/x86_emulate.c"=0A--- a/xen/arch/x86/x86_emu=
late.c=0A+++ b/xen/arch/x86/x86_emulate.c=0A@@ -10,8 +10,14 @@=0A  */=0A =
=0A #include <asm/x86_emulate.h>=0A+#include <asm/processor.h> /* =
current_cpu_info */=0A+#include <asm/amd.h> /* cpu_has_amd_erratum() */=0A =
=0A /* Avoid namespace pollution. */=0A #undef cmpxchg=0A+#undef =
cpuid=0A+=0A+#define cpu_has_amd_erratum(nr) \=0A+        cpu_has_amd_errat=
um(&current_cpu_data, AMD_ERRATUM_##nr)=0A =0A #include "x86_emulate/x86_em=
ulate.c"=0A--- a/xen/arch/x86/x86_emulate/x86_emulate.c=0A+++ b/xen/arch/x8=
6/x86_emulate/x86_emulate.c=0A@@ -2761,6 +2761,9 @@ x86_emulate(=0A     =
case 0xd9: /* FPU 0xd9 */=0A         switch ( modrm )=0A         {=0A+     =
   case 0xfb: /* fsincos */=0A+            fail_if(cpu_has_amd_erratum(573)=
);=0A+            /* fall through */=0A         case 0xc0 ... 0xc7: /* fld =
%stN */=0A         case 0xc8 ... 0xcf: /* fxch %stN */=0A         case =
0xd0: /* fnop */=0A@@ -2786,7 +2789,6 @@ x86_emulate(=0A         case =
0xf8: /* fprem */=0A         case 0xf9: /* fyl2xp1 */=0A         case =
0xfa: /* fsqrt */=0A-        case 0xfb: /* fsincos */=0A         case =
0xfc: /* frndint */=0A         case 0xfd: /* fscale */=0A         case =
0xfe: /* fsin */=0A--- a/xen/include/asm-x86/amd.h=0A+++ b/xen/include/asm-=
x86/amd.h=0A@@ -134,6 +134,12 @@=0A     AMD_OSVW_ERRATUM(3, AMD_MODEL_RANGE=
(0x10, 0x2, 0x1, 0xff, 0xf),	\=0A 		        AMD_MODEL_RANGE(0x1=
2, 0x0, 0x0, 0x1, 0x0))=0A =0A+#define AMD_ERRATUM_573				=
			\=0A+    AMD_LEGACY_ERRATUM(AMD_MODEL_RANGE(0x0f, =
0x0, 0x0, 0xff, 0xf),	\=0A+                       AMD_MODEL_RANGE(0x10, =
0x0, 0x0, 0xff, 0xf),	\=0A+                       AMD_MODEL_RANGE(0x11, =
0x0, 0x0, 0xff, 0xf),	\=0A+                       AMD_MODEL_RANGE(0x12, =
0x0, 0x0, 0xff, 0xf))=0A+=0A struct cpuinfo_x86;=0A int cpu_has_amd_erratum=
(const struct cpuinfo_x86 *, int, ...);=0A =0A
--=__Part0926A335.0__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--=__Part0926A335.0__=--


From xen-devel-bounces@lists.xensource.com Thu Dec 15 13:30:15 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 13: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.xensource.com>)
	id 1RbBNk-0007xf-39; Thu, 15 Dec 2011 13:29:56 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pasik@iki.fi>) id 1RbBNi-0007xW-Jh
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 13:29:54 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-5.tower-182.messagelabs.com!1323955788!7421263!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiAzOTU3MzU=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12786 invoked from network); 15 Dec 2011 13:29:48 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-5.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 15 Dec 2011 13:29:48 -0000
X-Originating-Ip: [194.89.68.22]
Received: from ydin.reaktio.net (reaktio.net [194.89.68.22])
	by smtp.tele.fi (Postfix) with ESMTP id C1CF51701;
	Thu, 15 Dec 2011 15:29:47 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 64F5D20054; Thu, 15 Dec 2011 15:29:47 +0200 (EET)
Date: Thu, 15 Dec 2011 15:29:47 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20111215132947.GX12984@reaktio.net>
References: <1323951936.20077.471.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1323951936.20077.471.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.18 (2008-05-17)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [RFC] xl: support configuration of encrypted VNC
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Dec 15, 2011 at 12:25:36PM +0000, Ian Campbell wrote:
> Someone pointed out that it's not possible to configure encrypted vnc
> via xl, while it is possible via xm. This is obviously quite nice to
> have if you are logging in as root...
> 
> The following is my initial attempt but TBH I'm not sure if this is
> presenting the correct interface at either the libxl or xl level. Since
> I don't actually use this stuff myself I'm finding it a bit hard to
> judge how much flexibility is needed or even what the right names/terms
> for things are. Opinions?
> 
> Enabling basic TLS is simple enough but the x509 auth stuff is more
> complicated and I expect a bit of a docs tarpit (references below).
> 
> I didn't do upstream qemu, stub qemu or vfb yet (there's a bunch of
> yacks in this regard, not least factoring out the duplication). Upstream
> qemu supports a few more options (e.g. sasl, see qemu(1)). SASL adds
> more complexity since it can be used with or without the x509 options
> depending on your needs and the specific SASL config you have in place
> for qemu which complexifies all the interfaces.
> 
> Notes to be turned into docs in the final version:
> 
> Clients seem thin on the ground, neither xtightvncviewer nor vnc4viewer
> support TLS. gvncviewer does seem to support all options.
> 

I guess it makes sense to mention 'virt-viewer' in this list aswell..

-- Pasi

> http://virt-manager.org/page/RemoteTLS has a bit of stuff and some
> useful links. In particular to http://libvirt.org/remote.html which has
> a reasonable description of how to generate appropriate certs.  On the
> server I ended up with:
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 13:30:15 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 13: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.xensource.com>)
	id 1RbBNk-0007xf-39; Thu, 15 Dec 2011 13:29:56 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pasik@iki.fi>) id 1RbBNi-0007xW-Jh
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 13:29:54 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-5.tower-182.messagelabs.com!1323955788!7421263!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiAzOTU3MzU=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12786 invoked from network); 15 Dec 2011 13:29:48 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-5.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 15 Dec 2011 13:29:48 -0000
X-Originating-Ip: [194.89.68.22]
Received: from ydin.reaktio.net (reaktio.net [194.89.68.22])
	by smtp.tele.fi (Postfix) with ESMTP id C1CF51701;
	Thu, 15 Dec 2011 15:29:47 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 64F5D20054; Thu, 15 Dec 2011 15:29:47 +0200 (EET)
Date: Thu, 15 Dec 2011 15:29:47 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20111215132947.GX12984@reaktio.net>
References: <1323951936.20077.471.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1323951936.20077.471.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.18 (2008-05-17)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [RFC] xl: support configuration of encrypted VNC
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Dec 15, 2011 at 12:25:36PM +0000, Ian Campbell wrote:
> Someone pointed out that it's not possible to configure encrypted vnc
> via xl, while it is possible via xm. This is obviously quite nice to
> have if you are logging in as root...
> 
> The following is my initial attempt but TBH I'm not sure if this is
> presenting the correct interface at either the libxl or xl level. Since
> I don't actually use this stuff myself I'm finding it a bit hard to
> judge how much flexibility is needed or even what the right names/terms
> for things are. Opinions?
> 
> Enabling basic TLS is simple enough but the x509 auth stuff is more
> complicated and I expect a bit of a docs tarpit (references below).
> 
> I didn't do upstream qemu, stub qemu or vfb yet (there's a bunch of
> yacks in this regard, not least factoring out the duplication). Upstream
> qemu supports a few more options (e.g. sasl, see qemu(1)). SASL adds
> more complexity since it can be used with or without the x509 options
> depending on your needs and the specific SASL config you have in place
> for qemu which complexifies all the interfaces.
> 
> Notes to be turned into docs in the final version:
> 
> Clients seem thin on the ground, neither xtightvncviewer nor vnc4viewer
> support TLS. gvncviewer does seem to support all options.
> 

I guess it makes sense to mention 'virt-viewer' in this list aswell..

-- Pasi

> http://virt-manager.org/page/RemoteTLS has a bit of stuff and some
> useful links. In particular to http://libvirt.org/remote.html which has
> a reasonable description of how to generate appropriate certs.  On the
> server I ended up with:
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 13:32:41 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 13: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.xensource.com>)
	id 1RbBQ6-00082l-Km; Thu, 15 Dec 2011 13:32:22 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RbBQ5-00082Q-I3
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 13:32:21 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1323955825!56309418!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjI2MA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11916 invoked from network); 15 Dec 2011 13:30:25 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 13:30:25 -0000
X-IronPort-AV: E=Sophos;i="4.71,357,1320624000"; 
   d="scan'208";a="9490072"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Dec 2011 13:32:15 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 15 Dec 2011 13:32:15 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Pasi =?ISO-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
Date: Thu, 15 Dec 2011 13:32:14 +0000
In-Reply-To: <20111215132947.GX12984@reaktio.net>
References: <1323951936.20077.471.camel@zakaz.uk.xensource.com>
	<20111215132947.GX12984@reaktio.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323955934.20077.483.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [RFC] xl: support configuration of encrypted VNC
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gVGh1LCAyMDExLTEyLTE1IGF0IDEzOjI5ICswMDAwLCBQYXNpIEvDpHJra8OkaW5lbiB3cm90
ZToKPiBPbiBUaHUsIERlYyAxNSwgMjAxMSBhdCAxMjoyNTozNlBNICswMDAwLCBJYW4gQ2FtcGJl
bGwgd3JvdGU6Cj4gPiBTb21lb25lIHBvaW50ZWQgb3V0IHRoYXQgaXQncyBub3QgcG9zc2libGUg
dG8gY29uZmlndXJlIGVuY3J5cHRlZCB2bmMKPiA+IHZpYSB4bCwgd2hpbGUgaXQgaXMgcG9zc2li
bGUgdmlhIHhtLiBUaGlzIGlzIG9idmlvdXNseSBxdWl0ZSBuaWNlIHRvCj4gPiBoYXZlIGlmIHlv
dSBhcmUgbG9nZ2luZyBpbiBhcyByb290Li4uCj4gPiAKPiA+IFRoZSBmb2xsb3dpbmcgaXMgbXkg
aW5pdGlhbCBhdHRlbXB0IGJ1dCBUQkggSSdtIG5vdCBzdXJlIGlmIHRoaXMgaXMKPiA+IHByZXNl
bnRpbmcgdGhlIGNvcnJlY3QgaW50ZXJmYWNlIGF0IGVpdGhlciB0aGUgbGlieGwgb3IgeGwgbGV2
ZWwuIFNpbmNlCj4gPiBJIGRvbid0IGFjdHVhbGx5IHVzZSB0aGlzIHN0dWZmIG15c2VsZiBJJ20g
ZmluZGluZyBpdCBhIGJpdCBoYXJkIHRvCj4gPiBqdWRnZSBob3cgbXVjaCBmbGV4aWJpbGl0eSBp
cyBuZWVkZWQgb3IgZXZlbiB3aGF0IHRoZSByaWdodCBuYW1lcy90ZXJtcwo+ID4gZm9yIHRoaW5n
cyBhcmUuIE9waW5pb25zPwo+ID4gCj4gPiBFbmFibGluZyBiYXNpYyBUTFMgaXMgc2ltcGxlIGVu
b3VnaCBidXQgdGhlIHg1MDkgYXV0aCBzdHVmZiBpcyBtb3JlCj4gPiBjb21wbGljYXRlZCBhbmQg
SSBleHBlY3QgYSBiaXQgb2YgYSBkb2NzIHRhcnBpdCAocmVmZXJlbmNlcyBiZWxvdykuCj4gPiAK
PiA+IEkgZGlkbid0IGRvIHVwc3RyZWFtIHFlbXUsIHN0dWIgcWVtdSBvciB2ZmIgeWV0ICh0aGVy
ZSdzIGEgYnVuY2ggb2YKPiA+IHlhY2tzIGluIHRoaXMgcmVnYXJkLCBub3QgbGVhc3QgZmFjdG9y
aW5nIG91dCB0aGUgZHVwbGljYXRpb24pLiBVcHN0cmVhbQo+ID4gcWVtdSBzdXBwb3J0cyBhIGZl
dyBtb3JlIG9wdGlvbnMgKGUuZy4gc2FzbCwgc2VlIHFlbXUoMSkpLiBTQVNMIGFkZHMKPiA+IG1v
cmUgY29tcGxleGl0eSBzaW5jZSBpdCBjYW4gYmUgdXNlZCB3aXRoIG9yIHdpdGhvdXQgdGhlIHg1
MDkgb3B0aW9ucwo+ID4gZGVwZW5kaW5nIG9uIHlvdXIgbmVlZHMgYW5kIHRoZSBzcGVjaWZpYyBT
QVNMIGNvbmZpZyB5b3UgaGF2ZSBpbiBwbGFjZQo+ID4gZm9yIHFlbXUgd2hpY2ggY29tcGxleGlm
aWVzIGFsbCB0aGUgaW50ZXJmYWNlcy4KPiA+IAo+ID4gTm90ZXMgdG8gYmUgdHVybmVkIGludG8g
ZG9jcyBpbiB0aGUgZmluYWwgdmVyc2lvbjoKPiA+IAo+ID4gQ2xpZW50cyBzZWVtIHRoaW4gb24g
dGhlIGdyb3VuZCwgbmVpdGhlciB4dGlnaHR2bmN2aWV3ZXIgbm9yIHZuYzR2aWV3ZXIKPiA+IHN1
cHBvcnQgVExTLiBndm5jdmlld2VyIGRvZXMgc2VlbSB0byBzdXBwb3J0IGFsbCBvcHRpb25zLgo+
ID4gCj4gCj4gSSBndWVzcyBpdCBtYWtlcyBzZW5zZSB0byBtZW50aW9uICd2aXJ0LXZpZXdlcicg
aW4gdGhpcyBsaXN0IGFzd2VsbC4uCgpJIGNvdWxkbid0IGZpZ3VyZSBvdXQgaG93IHRvIG1ha2Ug
aXQgc3BlYWsgZGlyZWN0IHRvIGEgdm5jIHBvcnQgYXMKb3Bwb3NlZCB0byBuZWVkaW5nIGxpYnZp
cnQgYW5kIGFsbCB0aGF0LgoKPiAKPiAtLSBQYXNpCj4gCj4gPiBodHRwOi8vdmlydC1tYW5hZ2Vy
Lm9yZy9wYWdlL1JlbW90ZVRMUyBoYXMgYSBiaXQgb2Ygc3R1ZmYgYW5kIHNvbWUKPiA+IHVzZWZ1
bCBsaW5rcy4gSW4gcGFydGljdWxhciB0byBodHRwOi8vbGlidmlydC5vcmcvcmVtb3RlLmh0bWwg
d2hpY2ggaGFzCj4gPiBhIHJlYXNvbmFibGUgZGVzY3JpcHRpb24gb2YgaG93IHRvIGdlbmVyYXRl
IGFwcHJvcHJpYXRlIGNlcnRzLiAgT24gdGhlCj4gPiBzZXJ2ZXIgSSBlbmRlZCB1cCB3aXRoOgo+
ID4gCj4gCgoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
Clhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbnNvdXJjZS5jb20KaHR0
cDovL2xpc3RzLnhlbnNvdXJjZS5jb20veGVuLWRldmVsCg==

From xen-devel-bounces@lists.xensource.com Thu Dec 15 13:32:41 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 13: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.xensource.com>)
	id 1RbBQ6-00082l-Km; Thu, 15 Dec 2011 13:32:22 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RbBQ5-00082Q-I3
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 13:32:21 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1323955825!56309418!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjI2MA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11916 invoked from network); 15 Dec 2011 13:30:25 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 13:30:25 -0000
X-IronPort-AV: E=Sophos;i="4.71,357,1320624000"; 
   d="scan'208";a="9490072"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Dec 2011 13:32:15 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 15 Dec 2011 13:32:15 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Pasi =?ISO-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
Date: Thu, 15 Dec 2011 13:32:14 +0000
In-Reply-To: <20111215132947.GX12984@reaktio.net>
References: <1323951936.20077.471.camel@zakaz.uk.xensource.com>
	<20111215132947.GX12984@reaktio.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323955934.20077.483.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [RFC] xl: support configuration of encrypted VNC
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gVGh1LCAyMDExLTEyLTE1IGF0IDEzOjI5ICswMDAwLCBQYXNpIEvDpHJra8OkaW5lbiB3cm90
ZToKPiBPbiBUaHUsIERlYyAxNSwgMjAxMSBhdCAxMjoyNTozNlBNICswMDAwLCBJYW4gQ2FtcGJl
bGwgd3JvdGU6Cj4gPiBTb21lb25lIHBvaW50ZWQgb3V0IHRoYXQgaXQncyBub3QgcG9zc2libGUg
dG8gY29uZmlndXJlIGVuY3J5cHRlZCB2bmMKPiA+IHZpYSB4bCwgd2hpbGUgaXQgaXMgcG9zc2li
bGUgdmlhIHhtLiBUaGlzIGlzIG9idmlvdXNseSBxdWl0ZSBuaWNlIHRvCj4gPiBoYXZlIGlmIHlv
dSBhcmUgbG9nZ2luZyBpbiBhcyByb290Li4uCj4gPiAKPiA+IFRoZSBmb2xsb3dpbmcgaXMgbXkg
aW5pdGlhbCBhdHRlbXB0IGJ1dCBUQkggSSdtIG5vdCBzdXJlIGlmIHRoaXMgaXMKPiA+IHByZXNl
bnRpbmcgdGhlIGNvcnJlY3QgaW50ZXJmYWNlIGF0IGVpdGhlciB0aGUgbGlieGwgb3IgeGwgbGV2
ZWwuIFNpbmNlCj4gPiBJIGRvbid0IGFjdHVhbGx5IHVzZSB0aGlzIHN0dWZmIG15c2VsZiBJJ20g
ZmluZGluZyBpdCBhIGJpdCBoYXJkIHRvCj4gPiBqdWRnZSBob3cgbXVjaCBmbGV4aWJpbGl0eSBp
cyBuZWVkZWQgb3IgZXZlbiB3aGF0IHRoZSByaWdodCBuYW1lcy90ZXJtcwo+ID4gZm9yIHRoaW5n
cyBhcmUuIE9waW5pb25zPwo+ID4gCj4gPiBFbmFibGluZyBiYXNpYyBUTFMgaXMgc2ltcGxlIGVu
b3VnaCBidXQgdGhlIHg1MDkgYXV0aCBzdHVmZiBpcyBtb3JlCj4gPiBjb21wbGljYXRlZCBhbmQg
SSBleHBlY3QgYSBiaXQgb2YgYSBkb2NzIHRhcnBpdCAocmVmZXJlbmNlcyBiZWxvdykuCj4gPiAK
PiA+IEkgZGlkbid0IGRvIHVwc3RyZWFtIHFlbXUsIHN0dWIgcWVtdSBvciB2ZmIgeWV0ICh0aGVy
ZSdzIGEgYnVuY2ggb2YKPiA+IHlhY2tzIGluIHRoaXMgcmVnYXJkLCBub3QgbGVhc3QgZmFjdG9y
aW5nIG91dCB0aGUgZHVwbGljYXRpb24pLiBVcHN0cmVhbQo+ID4gcWVtdSBzdXBwb3J0cyBhIGZl
dyBtb3JlIG9wdGlvbnMgKGUuZy4gc2FzbCwgc2VlIHFlbXUoMSkpLiBTQVNMIGFkZHMKPiA+IG1v
cmUgY29tcGxleGl0eSBzaW5jZSBpdCBjYW4gYmUgdXNlZCB3aXRoIG9yIHdpdGhvdXQgdGhlIHg1
MDkgb3B0aW9ucwo+ID4gZGVwZW5kaW5nIG9uIHlvdXIgbmVlZHMgYW5kIHRoZSBzcGVjaWZpYyBT
QVNMIGNvbmZpZyB5b3UgaGF2ZSBpbiBwbGFjZQo+ID4gZm9yIHFlbXUgd2hpY2ggY29tcGxleGlm
aWVzIGFsbCB0aGUgaW50ZXJmYWNlcy4KPiA+IAo+ID4gTm90ZXMgdG8gYmUgdHVybmVkIGludG8g
ZG9jcyBpbiB0aGUgZmluYWwgdmVyc2lvbjoKPiA+IAo+ID4gQ2xpZW50cyBzZWVtIHRoaW4gb24g
dGhlIGdyb3VuZCwgbmVpdGhlciB4dGlnaHR2bmN2aWV3ZXIgbm9yIHZuYzR2aWV3ZXIKPiA+IHN1
cHBvcnQgVExTLiBndm5jdmlld2VyIGRvZXMgc2VlbSB0byBzdXBwb3J0IGFsbCBvcHRpb25zLgo+
ID4gCj4gCj4gSSBndWVzcyBpdCBtYWtlcyBzZW5zZSB0byBtZW50aW9uICd2aXJ0LXZpZXdlcicg
aW4gdGhpcyBsaXN0IGFzd2VsbC4uCgpJIGNvdWxkbid0IGZpZ3VyZSBvdXQgaG93IHRvIG1ha2Ug
aXQgc3BlYWsgZGlyZWN0IHRvIGEgdm5jIHBvcnQgYXMKb3Bwb3NlZCB0byBuZWVkaW5nIGxpYnZp
cnQgYW5kIGFsbCB0aGF0LgoKPiAKPiAtLSBQYXNpCj4gCj4gPiBodHRwOi8vdmlydC1tYW5hZ2Vy
Lm9yZy9wYWdlL1JlbW90ZVRMUyBoYXMgYSBiaXQgb2Ygc3R1ZmYgYW5kIHNvbWUKPiA+IHVzZWZ1
bCBsaW5rcy4gSW4gcGFydGljdWxhciB0byBodHRwOi8vbGlidmlydC5vcmcvcmVtb3RlLmh0bWwg
d2hpY2ggaGFzCj4gPiBhIHJlYXNvbmFibGUgZGVzY3JpcHRpb24gb2YgaG93IHRvIGdlbmVyYXRl
IGFwcHJvcHJpYXRlIGNlcnRzLiAgT24gdGhlCj4gPiBzZXJ2ZXIgSSBlbmRlZCB1cCB3aXRoOgo+
ID4gCj4gCgoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
Clhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbnNvdXJjZS5jb20KaHR0
cDovL2xpc3RzLnhlbnNvdXJjZS5jb20veGVuLWRldmVsCg==

From xen-devel-bounces@lists.xensource.com Thu Dec 15 13:36:26 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 13:36:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbBTi-0008EH-BW; Thu, 15 Dec 2011 13:36:06 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RbBTg-0008Dt-MC
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 13:36:04 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-13.tower-27.messagelabs.com!1323956134!52311990!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4577 invoked from network); 15 Dec 2011 13:35:34 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-13.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 15 Dec 2011 13:35:34 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RbBTX-0001mb-9H; Thu, 15 Dec 2011 13:35:55 +0000
Date: Thu, 15 Dec 2011 13:35:55 +0000
From: Tim Deegan <tim@xen.org>
To: Wei Wang <wei.wang2@amd.com>
Message-ID: <20111215133555.GE4274@ocelot.phlegethon.org>
References: <patchbomb.1323876561@gran.amd.com>
	<ea52a2b93dffe708084f.1323876564@gran.amd.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <ea52a2b93dffe708084f.1323876564@gran.amd.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com, keir@xen.org, JBeulich@suse.com
Subject: Re: [Xen-devel] [PATCH 03 of 16] amd iommu: Add iommu emulation for
	hvm guest
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi, 

At 16:29 +0100 on 14 Dec (1323880164), Wei Wang wrote:
> +static struct page_info* guest_iommu_get_page(struct list_head *pglist,
> +                                              unsigned int entry_size,
> +                                              unsigned int pos)
> +{
> +    int idx;
> +    struct list_head *head;
> +    struct guest_pages *gpage = NULL;
> +
> +    idx = (pos * entry_size) >> PAGE_SHIFT;
> +    list_for_each( head, pglist )
> +    {
> +        gpage = list_entry(head, struct guest_pages, list);
> +        if ( (--idx) < 0 )
> +            break;
> +    }

Given that you allocate all these elements together, and free them, all
together, why not just use an array instead of a linked list?

Cheers,

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 13:36:26 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 13:36:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbBTi-0008EH-BW; Thu, 15 Dec 2011 13:36:06 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RbBTg-0008Dt-MC
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 13:36:04 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-13.tower-27.messagelabs.com!1323956134!52311990!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4577 invoked from network); 15 Dec 2011 13:35:34 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-13.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 15 Dec 2011 13:35:34 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RbBTX-0001mb-9H; Thu, 15 Dec 2011 13:35:55 +0000
Date: Thu, 15 Dec 2011 13:35:55 +0000
From: Tim Deegan <tim@xen.org>
To: Wei Wang <wei.wang2@amd.com>
Message-ID: <20111215133555.GE4274@ocelot.phlegethon.org>
References: <patchbomb.1323876561@gran.amd.com>
	<ea52a2b93dffe708084f.1323876564@gran.amd.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <ea52a2b93dffe708084f.1323876564@gran.amd.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com, keir@xen.org, JBeulich@suse.com
Subject: Re: [Xen-devel] [PATCH 03 of 16] amd iommu: Add iommu emulation for
	hvm guest
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi, 

At 16:29 +0100 on 14 Dec (1323880164), Wei Wang wrote:
> +static struct page_info* guest_iommu_get_page(struct list_head *pglist,
> +                                              unsigned int entry_size,
> +                                              unsigned int pos)
> +{
> +    int idx;
> +    struct list_head *head;
> +    struct guest_pages *gpage = NULL;
> +
> +    idx = (pos * entry_size) >> PAGE_SHIFT;
> +    list_for_each( head, pglist )
> +    {
> +        gpage = list_entry(head, struct guest_pages, list);
> +        if ( (--idx) < 0 )
> +            break;
> +    }

Given that you allocate all these elements together, and free them, all
together, why not just use an array instead of a linked list?

Cheers,

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 13:39:39 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 13: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.xensource.com>)
	id 1RbBWu-0008Nw-Uz; Thu, 15 Dec 2011 13:39:24 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RbBWt-0008Nd-25
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 13:39:23 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-12.tower-182.messagelabs.com!1323956356!7409556!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8656 invoked from network); 15 Dec 2011 13:39:16 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-12.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 15 Dec 2011 13:39:16 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RbBWl-0001nN-5M; Thu, 15 Dec 2011 13:39:15 +0000
Date: Thu, 15 Dec 2011 13:39:15 +0000
From: Tim Deegan <tim@xen.org>
To: Wei Wang <wei.wang2@amd.com>
Message-ID: <20111215133915.GF4274@ocelot.phlegethon.org>
References: <patchbomb.1323876561@gran.amd.com>
	<9a93e064dd3c467ce4b8.1323876572@gran.amd.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <9a93e064dd3c467ce4b8.1323876572@gran.amd.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com, keir@xen.org, JBeulich@suse.com
Subject: Re: [Xen-devel] [PATCH 11 of 16] amd iommu: Add a new flag to
	indication iommuv2 feature enabled or not
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 16:29 +0100 on 14 Dec (1323880172), Wei Wang wrote:
> # HG changeset patch
> # User Wei Wang <wei.wang2@amd.com>
> # Date 1323875776 -3600
> # Node ID 9a93e064dd3c467ce4b87ddef8739a3573ef547c
> # Parent  001681ff1a0c09c4d04fd8bd45e8d26805686246
> amd iommu: Add a new flag to indication iommuv2 feature enabled or not.
> Hypercalls should return early on non-iommuv2 systems.
> 
> Signed-off-by: Wei Wang <wei.wang2@amd.com>
> 
> diff -r 001681ff1a0c -r 9a93e064dd3c xen/drivers/passthrough/amd/iommu_guest.c
> --- a/xen/drivers/passthrough/amd/iommu_guest.c	Wed Dec 14 16:16:15 2011 +0100
> +++ b/xen/drivers/passthrough/amd/iommu_guest.c	Wed Dec 14 16:16:16 2011 +0100
> @@ -48,6 +48,8 @@
>          (reg)->hi = (val >> 32) & 0xFFFFFFFF; \
>      } while(0)
>  
> +extern bool_t iommuv2_enabled;
> +
>  static unsigned int machine_bdf(struct domain *d, uint16_t guest_bdf)
>  {
>      struct pci_dev *pdev;
> @@ -839,6 +841,9 @@ int guest_iommu_set_base(struct domain *
>      p2m_type_t t;
>      struct guest_iommu *iommu = domain_iommu(d);
>  
> +    if ( !is_hvm_domain(d) && !iommuv2_enabled )
> +        return 1;

Shouldn't that that be || ? (And likewise below) 

Cheers,

Tim.

> +
>      iommu->mmio_base = base;
>      base >>= PAGE_SHIFT;
>  
> @@ -898,7 +903,7 @@ int guest_iommu_init(struct domain* d)
>      struct guest_iommu *iommu;
>      struct hvm_iommu *hd  = domain_hvm_iommu(d);
>  
> -    if ( !is_hvm_domain(d) )
> +    if ( !is_hvm_domain(d) && !iommuv2_enabled )
>          return 0;
>  
>      iommu = xzalloc(struct guest_iommu);
> @@ -940,7 +945,7 @@ void guest_iommu_destroy(struct domain *
>  {
>      struct guest_iommu *iommu;
>  
> -    if ( !is_hvm_domain(d) )
> +    if ( !is_hvm_domain(d) && !iommuv2_enabled )
>          return;
>  
>      iommu = domain_iommu(d);
> @@ -973,7 +978,7 @@ int iommu_bind_bdf(struct domain* d, uin
>      struct pci_dev *pdev;
>      int ret = -ENODEV;
>  
> -    if ( !iommu_found() )
> +    if ( !iommu_found() || !iommuv2_enabled )
>          return 0;
>  
>      spin_lock(&pcidevs_lock);
> @@ -998,7 +1003,7 @@ void iommu_set_msi(struct domain* d, uin
>  {
>      struct guest_iommu *iommu = domain_iommu(d);
>  
> -    if ( !iommu_found() )
> +    if ( !iommu_found() || !iommuv2_enabled )
>          return;
>  
>      iommu->msi.vector = vector;
> diff -r 001681ff1a0c -r 9a93e064dd3c xen/drivers/passthrough/amd/iommu_init.c
> --- a/xen/drivers/passthrough/amd/iommu_init.c	Wed Dec 14 16:16:15 2011 +0100
> +++ b/xen/drivers/passthrough/amd/iommu_init.c	Wed Dec 14 16:16:16 2011 +0100
> @@ -36,6 +36,7 @@ unsigned short ivrs_bdf_entries;
>  static struct radix_tree_root ivrs_maps;
>  struct list_head amd_iommu_head;
>  struct table_struct device_table;
> +bool_t iommuv2_enabled;
>  
>  static int iommu_has_ht_flag(struct amd_iommu *iommu, u8 mask)
>  {
> @@ -759,6 +760,10 @@ static void enable_iommu(struct amd_iomm
>          amd_iommu_flush_all_caches(iommu);
>  
>      iommu->enabled = 1;
> +
> +    if ( iommu->features )
> +        iommuv2_enabled = 1;
> +
>      spin_unlock_irqrestore(&iommu->lock, flags);
>  
>  }
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 13:39:39 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 13: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.xensource.com>)
	id 1RbBWu-0008Nw-Uz; Thu, 15 Dec 2011 13:39:24 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RbBWt-0008Nd-25
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 13:39:23 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-12.tower-182.messagelabs.com!1323956356!7409556!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8656 invoked from network); 15 Dec 2011 13:39:16 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-12.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 15 Dec 2011 13:39:16 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RbBWl-0001nN-5M; Thu, 15 Dec 2011 13:39:15 +0000
Date: Thu, 15 Dec 2011 13:39:15 +0000
From: Tim Deegan <tim@xen.org>
To: Wei Wang <wei.wang2@amd.com>
Message-ID: <20111215133915.GF4274@ocelot.phlegethon.org>
References: <patchbomb.1323876561@gran.amd.com>
	<9a93e064dd3c467ce4b8.1323876572@gran.amd.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <9a93e064dd3c467ce4b8.1323876572@gran.amd.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com, keir@xen.org, JBeulich@suse.com
Subject: Re: [Xen-devel] [PATCH 11 of 16] amd iommu: Add a new flag to
	indication iommuv2 feature enabled or not
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 16:29 +0100 on 14 Dec (1323880172), Wei Wang wrote:
> # HG changeset patch
> # User Wei Wang <wei.wang2@amd.com>
> # Date 1323875776 -3600
> # Node ID 9a93e064dd3c467ce4b87ddef8739a3573ef547c
> # Parent  001681ff1a0c09c4d04fd8bd45e8d26805686246
> amd iommu: Add a new flag to indication iommuv2 feature enabled or not.
> Hypercalls should return early on non-iommuv2 systems.
> 
> Signed-off-by: Wei Wang <wei.wang2@amd.com>
> 
> diff -r 001681ff1a0c -r 9a93e064dd3c xen/drivers/passthrough/amd/iommu_guest.c
> --- a/xen/drivers/passthrough/amd/iommu_guest.c	Wed Dec 14 16:16:15 2011 +0100
> +++ b/xen/drivers/passthrough/amd/iommu_guest.c	Wed Dec 14 16:16:16 2011 +0100
> @@ -48,6 +48,8 @@
>          (reg)->hi = (val >> 32) & 0xFFFFFFFF; \
>      } while(0)
>  
> +extern bool_t iommuv2_enabled;
> +
>  static unsigned int machine_bdf(struct domain *d, uint16_t guest_bdf)
>  {
>      struct pci_dev *pdev;
> @@ -839,6 +841,9 @@ int guest_iommu_set_base(struct domain *
>      p2m_type_t t;
>      struct guest_iommu *iommu = domain_iommu(d);
>  
> +    if ( !is_hvm_domain(d) && !iommuv2_enabled )
> +        return 1;

Shouldn't that that be || ? (And likewise below) 

Cheers,

Tim.

> +
>      iommu->mmio_base = base;
>      base >>= PAGE_SHIFT;
>  
> @@ -898,7 +903,7 @@ int guest_iommu_init(struct domain* d)
>      struct guest_iommu *iommu;
>      struct hvm_iommu *hd  = domain_hvm_iommu(d);
>  
> -    if ( !is_hvm_domain(d) )
> +    if ( !is_hvm_domain(d) && !iommuv2_enabled )
>          return 0;
>  
>      iommu = xzalloc(struct guest_iommu);
> @@ -940,7 +945,7 @@ void guest_iommu_destroy(struct domain *
>  {
>      struct guest_iommu *iommu;
>  
> -    if ( !is_hvm_domain(d) )
> +    if ( !is_hvm_domain(d) && !iommuv2_enabled )
>          return;
>  
>      iommu = domain_iommu(d);
> @@ -973,7 +978,7 @@ int iommu_bind_bdf(struct domain* d, uin
>      struct pci_dev *pdev;
>      int ret = -ENODEV;
>  
> -    if ( !iommu_found() )
> +    if ( !iommu_found() || !iommuv2_enabled )
>          return 0;
>  
>      spin_lock(&pcidevs_lock);
> @@ -998,7 +1003,7 @@ void iommu_set_msi(struct domain* d, uin
>  {
>      struct guest_iommu *iommu = domain_iommu(d);
>  
> -    if ( !iommu_found() )
> +    if ( !iommu_found() || !iommuv2_enabled )
>          return;
>  
>      iommu->msi.vector = vector;
> diff -r 001681ff1a0c -r 9a93e064dd3c xen/drivers/passthrough/amd/iommu_init.c
> --- a/xen/drivers/passthrough/amd/iommu_init.c	Wed Dec 14 16:16:15 2011 +0100
> +++ b/xen/drivers/passthrough/amd/iommu_init.c	Wed Dec 14 16:16:16 2011 +0100
> @@ -36,6 +36,7 @@ unsigned short ivrs_bdf_entries;
>  static struct radix_tree_root ivrs_maps;
>  struct list_head amd_iommu_head;
>  struct table_struct device_table;
> +bool_t iommuv2_enabled;
>  
>  static int iommu_has_ht_flag(struct amd_iommu *iommu, u8 mask)
>  {
> @@ -759,6 +760,10 @@ static void enable_iommu(struct amd_iomm
>          amd_iommu_flush_all_caches(iommu);
>  
>      iommu->enabled = 1;
> +
> +    if ( iommu->features )
> +        iommuv2_enabled = 1;
> +
>      spin_unlock_irqrestore(&iommu->lock, flags);
>  
>  }
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 13:40:46 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 13: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.xensource.com>)
	id 1RbBXy-0008V2-J9; Thu, 15 Dec 2011 13:40:30 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RbBXx-0008UD-77
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 13:40:29 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1323956422!7409730!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13169 invoked from network); 15 Dec 2011 13:40:22 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-12.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 15 Dec 2011 13:40:22 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 15 Dec 2011 13:20:01 +0000
Message-Id: <4EEA020F0200007800068244@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 15 Dec 2011 13:19:59 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Keir Fraser" <keir@xen.org>
References: <4EE9FF4D020000780006821D@nat28.tlf.novell.com>
	<CB0FA316.36001%keir@xen.org>
In-Reply-To: <CB0FA316.36001%keir@xen.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Paolo Bonzini <pbonzini@redhat.com>, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] fsincos emulation on AMD CPUs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 15.12.11 at 14:13, Keir Fraser <keir@xen.org> wrote:
> On 15/12/2011 13:08, "Jan Beulich" <JBeulich@suse.com> wrote:
> 
>>>>> On 15.12.11 at 13:33, Keir Fraser <keir@xen.org> wrote:
>>> More detail: the full patch is ugly and hard to test all cases. And there's
>>> no practical scenario where we want to emulate FSINCOS on AMD -- we don't
>>> emulate realmode on AMD, FSINCOS on a shadowed page certainly indicates that
>>> we should unshadow the page, FSINCOS on MMIO is mad or malicious.
>> 
>> Those latter two cases can't really happen, as fsincos has no memory
>> operand.
> 
> Possibly if the instruction itself was in a recycled page-table page? Or in
> an MMIO page, or the malicious race that Paolo described --- definitely
> malicious either way.
> 
> Anyhow the short answer is we never want to emulate it on AMD. :-)

I just sent out the patch as quoted in the reply to Paolo, but you're
suggesting to be even more drastic and ignore the CPU family. If
you really want it done that way, I wonder whether we should bail on
AMD for *all* x87 operations not having memory operands.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 13:40:46 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 13: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.xensource.com>)
	id 1RbBXy-0008V2-J9; Thu, 15 Dec 2011 13:40:30 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RbBXx-0008UD-77
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 13:40:29 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1323956422!7409730!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13169 invoked from network); 15 Dec 2011 13:40:22 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-12.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 15 Dec 2011 13:40:22 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 15 Dec 2011 13:20:01 +0000
Message-Id: <4EEA020F0200007800068244@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 15 Dec 2011 13:19:59 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Keir Fraser" <keir@xen.org>
References: <4EE9FF4D020000780006821D@nat28.tlf.novell.com>
	<CB0FA316.36001%keir@xen.org>
In-Reply-To: <CB0FA316.36001%keir@xen.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Paolo Bonzini <pbonzini@redhat.com>, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] fsincos emulation on AMD CPUs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 15.12.11 at 14:13, Keir Fraser <keir@xen.org> wrote:
> On 15/12/2011 13:08, "Jan Beulich" <JBeulich@suse.com> wrote:
> 
>>>>> On 15.12.11 at 13:33, Keir Fraser <keir@xen.org> wrote:
>>> More detail: the full patch is ugly and hard to test all cases. And there's
>>> no practical scenario where we want to emulate FSINCOS on AMD -- we don't
>>> emulate realmode on AMD, FSINCOS on a shadowed page certainly indicates that
>>> we should unshadow the page, FSINCOS on MMIO is mad or malicious.
>> 
>> Those latter two cases can't really happen, as fsincos has no memory
>> operand.
> 
> Possibly if the instruction itself was in a recycled page-table page? Or in
> an MMIO page, or the malicious race that Paolo described --- definitely
> malicious either way.
> 
> Anyhow the short answer is we never want to emulate it on AMD. :-)

I just sent out the patch as quoted in the reply to Paolo, but you're
suggesting to be even more drastic and ignore the CPU family. If
you really want it done that way, I wonder whether we should bail on
AMD for *all* x87 operations not having memory operands.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 14:03:19 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 14:03:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbBtj-0000u7-DX; Thu, 15 Dec 2011 14:02:59 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Wang2@amd.com>) id 1RbBtg-0000tz-Li
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 14:02:56 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1323957754!49439446!1
X-Originating-IP: [216.32.181.185]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26951 invoked from network); 15 Dec 2011 14:02:36 -0000
Received: from ch1ehsobe005.messaging.microsoft.com (HELO
	ch1outboundpool.messaging.microsoft.com) (216.32.181.185)
	by server-11.tower-27.messagelabs.com with AES128-SHA encrypted SMTP;
	15 Dec 2011 14:02:36 -0000
Received: from mail218-ch1-R.bigfish.com (10.43.68.242) by
	CH1EHSOBE010.bigfish.com (10.43.70.60) with Microsoft SMTP Server id
	14.1.225.23; Thu, 15 Dec 2011 14:02:54 +0000
Received: from mail218-ch1 (localhost [127.0.0.1])	by
	mail218-ch1-R.bigfish.com (Postfix) with ESMTP id 92E243A03BE;
	Thu, 15 Dec 2011 14:02:59 +0000 (UTC)
X-SpamScore: -9
X-BigFish: VPS-9(zz1432N98dKzz1202hzz8275bhz2dh668h839h)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
Received: from mail218-ch1 (localhost.localdomain [127.0.0.1]) by mail218-ch1
	(MessageSwitch) id 1323957776235318_8090;
	Thu, 15 Dec 2011 14:02:56 +0000 (UTC)
Received: from CH1EHSMHS006.bigfish.com (snatpool1.int.messaging.microsoft.com
	[10.43.68.252])	by mail218-ch1.bigfish.com (Postfix) with ESMTP id
	3455C2C0042;	Thu, 15 Dec 2011 14:02:56 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	CH1EHSMHS006.bigfish.com (10.43.70.6) with Microsoft SMTP Server id
	14.1.225.23; Thu, 15 Dec 2011 14:02:49 +0000
X-WSS-ID: 0LW90CK-02-47G-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp02.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2987BC8083;	Thu, 15 Dec 2011 08:02:44 -0600 (CST)
Received: from SAUSEXDAG03.amd.com (163.181.55.3) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Thu, 15 Dec 2011 08:03:00 -0600
Received: from storexhtp01.amd.com (172.24.4.3) by sausexdag03.amd.com
	(163.181.55.3) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Thu, 15 Dec 2011 08:02:45 -0600
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp01.amd.com
	(172.24.4.3) with Microsoft SMTP Server id 8.3.213.0; Thu, 15 Dec 2011
	09:02:44 -0500
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 063C549C34C; Thu, 15 Dec 2011
	14:02:43 +0000 (GMT)
Received: from gran.osrc.amd.com (gran.osrc.amd.com [165.204.15.57])	by
	mail.osrc.amd.com (Postfix) with ESMTP id DC9455940FF; Thu, 15 Dec 2011
	15:02:42 +0100 (CET)
From: Wei Wang2 <wei.wang2@amd.com>
To: Tim Deegan <tim@xen.org>
Date: Thu, 15 Dec 2011 15:05:25 +0100
User-Agent: KMail/1.9.6 (enterprise 20070904.708012)
References: <patchbomb.1323876561@gran.amd.com>
	<9a93e064dd3c467ce4b8.1323876572@gran.amd.com>
	<20111215133915.GF4274@ocelot.phlegethon.org>
In-Reply-To: <20111215133915.GF4274@ocelot.phlegethon.org>
MIME-Version: 1.0
Content-Disposition: inline
Message-ID: <201112151505.26272.wei.wang2@amd.com>
X-OriginatorOrg: amd.com
Cc: xen-devel@lists.xensource.com, keir@xen.org, JBeulich@suse.com
Subject: Re: [Xen-devel] [PATCH 11 of 16] amd iommu: Add a new flag to
	indication iommuv2 feature enabled or not
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thursday 15 December 2011 14:39:15 Tim Deegan wrote:
> At 16:29 +0100 on 14 Dec (1323880172), Wei Wang wrote:
> > # HG changeset patch
> > # User Wei Wang <wei.wang2@amd.com>
> > # Date 1323875776 -3600
> > # Node ID 9a93e064dd3c467ce4b87ddef8739a3573ef547c
> > # Parent  001681ff1a0c09c4d04fd8bd45e8d26805686246
> > amd iommu: Add a new flag to indication iommuv2 feature enabled or not.
> > Hypercalls should return early on non-iommuv2 systems.
> >
> > Signed-off-by: Wei Wang <wei.wang2@amd.com>
> >
> > diff -r 001681ff1a0c -r 9a93e064dd3c
> > xen/drivers/passthrough/amd/iommu_guest.c ---
> > a/xen/drivers/passthrough/amd/iommu_guest.c	Wed Dec 14 16:16:15 2011
> > +0100 +++ b/xen/drivers/passthrough/amd/iommu_guest.c	Wed Dec 14 16:16:16
> > 2011 +0100 @@ -48,6 +48,8 @@
> >          (reg)->hi = (val >> 32) & 0xFFFFFFFF; \
> >      } while(0)
> >
> > +extern bool_t iommuv2_enabled;
> > +
> >  static unsigned int machine_bdf(struct domain *d, uint16_t guest_bdf)
> >  {
> >      struct pci_dev *pdev;
> > @@ -839,6 +841,9 @@ int guest_iommu_set_base(struct domain *
> >      p2m_type_t t;
> >      struct guest_iommu *iommu = domain_iommu(d);
> >
> > +    if ( !is_hvm_domain(d) && !iommuv2_enabled )
> > +        return 1;
>
> Shouldn't that that be || ? (And likewise below)
Oops... I will fix that.

Thanks.
Wei

> Cheers,
>
> Tim.
>
> > +
> >      iommu->mmio_base = base;
> >      base >>= PAGE_SHIFT;
> >
> > @@ -898,7 +903,7 @@ int guest_iommu_init(struct domain* d)
> >      struct guest_iommu *iommu;
> >      struct hvm_iommu *hd  = domain_hvm_iommu(d);
> >
> > -    if ( !is_hvm_domain(d) )
> > +    if ( !is_hvm_domain(d) && !iommuv2_enabled )
> >          return 0;
> >
> >      iommu = xzalloc(struct guest_iommu);
> > @@ -940,7 +945,7 @@ void guest_iommu_destroy(struct domain *
> >  {
> >      struct guest_iommu *iommu;
> >
> > -    if ( !is_hvm_domain(d) )
> > +    if ( !is_hvm_domain(d) && !iommuv2_enabled )
> >          return;
> >
> >      iommu = domain_iommu(d);
> > @@ -973,7 +978,7 @@ int iommu_bind_bdf(struct domain* d, uin
> >      struct pci_dev *pdev;
> >      int ret = -ENODEV;
> >
> > -    if ( !iommu_found() )
> > +    if ( !iommu_found() || !iommuv2_enabled )
> >          return 0;
> >
> >      spin_lock(&pcidevs_lock);
> > @@ -998,7 +1003,7 @@ void iommu_set_msi(struct domain* d, uin
> >  {
> >      struct guest_iommu *iommu = domain_iommu(d);
> >
> > -    if ( !iommu_found() )
> > +    if ( !iommu_found() || !iommuv2_enabled )
> >          return;
> >
> >      iommu->msi.vector = vector;
> > diff -r 001681ff1a0c -r 9a93e064dd3c
> > xen/drivers/passthrough/amd/iommu_init.c ---
> > a/xen/drivers/passthrough/amd/iommu_init.c	Wed Dec 14 16:16:15 2011 +0100
> > +++ b/xen/drivers/passthrough/amd/iommu_init.c	Wed Dec 14 16:16:16 2011
> > +0100 @@ -36,6 +36,7 @@ unsigned short ivrs_bdf_entries;
> >  static struct radix_tree_root ivrs_maps;
> >  struct list_head amd_iommu_head;
> >  struct table_struct device_table;
> > +bool_t iommuv2_enabled;
> >
> >  static int iommu_has_ht_flag(struct amd_iommu *iommu, u8 mask)
> >  {
> > @@ -759,6 +760,10 @@ static void enable_iommu(struct amd_iomm
> >          amd_iommu_flush_all_caches(iommu);
> >
> >      iommu->enabled = 1;
> > +
> > +    if ( iommu->features )
> > +        iommuv2_enabled = 1;
> > +
> >      spin_unlock_irqrestore(&iommu->lock, flags);
> >
> >  }
> >
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xensource.com
> > http://lists.xensource.com/xen-devel




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 14:03:19 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 14:03:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbBtj-0000u7-DX; Thu, 15 Dec 2011 14:02:59 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Wang2@amd.com>) id 1RbBtg-0000tz-Li
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 14:02:56 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1323957754!49439446!1
X-Originating-IP: [216.32.181.185]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26951 invoked from network); 15 Dec 2011 14:02:36 -0000
Received: from ch1ehsobe005.messaging.microsoft.com (HELO
	ch1outboundpool.messaging.microsoft.com) (216.32.181.185)
	by server-11.tower-27.messagelabs.com with AES128-SHA encrypted SMTP;
	15 Dec 2011 14:02:36 -0000
Received: from mail218-ch1-R.bigfish.com (10.43.68.242) by
	CH1EHSOBE010.bigfish.com (10.43.70.60) with Microsoft SMTP Server id
	14.1.225.23; Thu, 15 Dec 2011 14:02:54 +0000
Received: from mail218-ch1 (localhost [127.0.0.1])	by
	mail218-ch1-R.bigfish.com (Postfix) with ESMTP id 92E243A03BE;
	Thu, 15 Dec 2011 14:02:59 +0000 (UTC)
X-SpamScore: -9
X-BigFish: VPS-9(zz1432N98dKzz1202hzz8275bhz2dh668h839h)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
Received: from mail218-ch1 (localhost.localdomain [127.0.0.1]) by mail218-ch1
	(MessageSwitch) id 1323957776235318_8090;
	Thu, 15 Dec 2011 14:02:56 +0000 (UTC)
Received: from CH1EHSMHS006.bigfish.com (snatpool1.int.messaging.microsoft.com
	[10.43.68.252])	by mail218-ch1.bigfish.com (Postfix) with ESMTP id
	3455C2C0042;	Thu, 15 Dec 2011 14:02:56 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	CH1EHSMHS006.bigfish.com (10.43.70.6) with Microsoft SMTP Server id
	14.1.225.23; Thu, 15 Dec 2011 14:02:49 +0000
X-WSS-ID: 0LW90CK-02-47G-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp02.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2987BC8083;	Thu, 15 Dec 2011 08:02:44 -0600 (CST)
Received: from SAUSEXDAG03.amd.com (163.181.55.3) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Thu, 15 Dec 2011 08:03:00 -0600
Received: from storexhtp01.amd.com (172.24.4.3) by sausexdag03.amd.com
	(163.181.55.3) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Thu, 15 Dec 2011 08:02:45 -0600
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp01.amd.com
	(172.24.4.3) with Microsoft SMTP Server id 8.3.213.0; Thu, 15 Dec 2011
	09:02:44 -0500
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 063C549C34C; Thu, 15 Dec 2011
	14:02:43 +0000 (GMT)
Received: from gran.osrc.amd.com (gran.osrc.amd.com [165.204.15.57])	by
	mail.osrc.amd.com (Postfix) with ESMTP id DC9455940FF; Thu, 15 Dec 2011
	15:02:42 +0100 (CET)
From: Wei Wang2 <wei.wang2@amd.com>
To: Tim Deegan <tim@xen.org>
Date: Thu, 15 Dec 2011 15:05:25 +0100
User-Agent: KMail/1.9.6 (enterprise 20070904.708012)
References: <patchbomb.1323876561@gran.amd.com>
	<9a93e064dd3c467ce4b8.1323876572@gran.amd.com>
	<20111215133915.GF4274@ocelot.phlegethon.org>
In-Reply-To: <20111215133915.GF4274@ocelot.phlegethon.org>
MIME-Version: 1.0
Content-Disposition: inline
Message-ID: <201112151505.26272.wei.wang2@amd.com>
X-OriginatorOrg: amd.com
Cc: xen-devel@lists.xensource.com, keir@xen.org, JBeulich@suse.com
Subject: Re: [Xen-devel] [PATCH 11 of 16] amd iommu: Add a new flag to
	indication iommuv2 feature enabled or not
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thursday 15 December 2011 14:39:15 Tim Deegan wrote:
> At 16:29 +0100 on 14 Dec (1323880172), Wei Wang wrote:
> > # HG changeset patch
> > # User Wei Wang <wei.wang2@amd.com>
> > # Date 1323875776 -3600
> > # Node ID 9a93e064dd3c467ce4b87ddef8739a3573ef547c
> > # Parent  001681ff1a0c09c4d04fd8bd45e8d26805686246
> > amd iommu: Add a new flag to indication iommuv2 feature enabled or not.
> > Hypercalls should return early on non-iommuv2 systems.
> >
> > Signed-off-by: Wei Wang <wei.wang2@amd.com>
> >
> > diff -r 001681ff1a0c -r 9a93e064dd3c
> > xen/drivers/passthrough/amd/iommu_guest.c ---
> > a/xen/drivers/passthrough/amd/iommu_guest.c	Wed Dec 14 16:16:15 2011
> > +0100 +++ b/xen/drivers/passthrough/amd/iommu_guest.c	Wed Dec 14 16:16:16
> > 2011 +0100 @@ -48,6 +48,8 @@
> >          (reg)->hi = (val >> 32) & 0xFFFFFFFF; \
> >      } while(0)
> >
> > +extern bool_t iommuv2_enabled;
> > +
> >  static unsigned int machine_bdf(struct domain *d, uint16_t guest_bdf)
> >  {
> >      struct pci_dev *pdev;
> > @@ -839,6 +841,9 @@ int guest_iommu_set_base(struct domain *
> >      p2m_type_t t;
> >      struct guest_iommu *iommu = domain_iommu(d);
> >
> > +    if ( !is_hvm_domain(d) && !iommuv2_enabled )
> > +        return 1;
>
> Shouldn't that that be || ? (And likewise below)
Oops... I will fix that.

Thanks.
Wei

> Cheers,
>
> Tim.
>
> > +
> >      iommu->mmio_base = base;
> >      base >>= PAGE_SHIFT;
> >
> > @@ -898,7 +903,7 @@ int guest_iommu_init(struct domain* d)
> >      struct guest_iommu *iommu;
> >      struct hvm_iommu *hd  = domain_hvm_iommu(d);
> >
> > -    if ( !is_hvm_domain(d) )
> > +    if ( !is_hvm_domain(d) && !iommuv2_enabled )
> >          return 0;
> >
> >      iommu = xzalloc(struct guest_iommu);
> > @@ -940,7 +945,7 @@ void guest_iommu_destroy(struct domain *
> >  {
> >      struct guest_iommu *iommu;
> >
> > -    if ( !is_hvm_domain(d) )
> > +    if ( !is_hvm_domain(d) && !iommuv2_enabled )
> >          return;
> >
> >      iommu = domain_iommu(d);
> > @@ -973,7 +978,7 @@ int iommu_bind_bdf(struct domain* d, uin
> >      struct pci_dev *pdev;
> >      int ret = -ENODEV;
> >
> > -    if ( !iommu_found() )
> > +    if ( !iommu_found() || !iommuv2_enabled )
> >          return 0;
> >
> >      spin_lock(&pcidevs_lock);
> > @@ -998,7 +1003,7 @@ void iommu_set_msi(struct domain* d, uin
> >  {
> >      struct guest_iommu *iommu = domain_iommu(d);
> >
> > -    if ( !iommu_found() )
> > +    if ( !iommu_found() || !iommuv2_enabled )
> >          return;
> >
> >      iommu->msi.vector = vector;
> > diff -r 001681ff1a0c -r 9a93e064dd3c
> > xen/drivers/passthrough/amd/iommu_init.c ---
> > a/xen/drivers/passthrough/amd/iommu_init.c	Wed Dec 14 16:16:15 2011 +0100
> > +++ b/xen/drivers/passthrough/amd/iommu_init.c	Wed Dec 14 16:16:16 2011
> > +0100 @@ -36,6 +36,7 @@ unsigned short ivrs_bdf_entries;
> >  static struct radix_tree_root ivrs_maps;
> >  struct list_head amd_iommu_head;
> >  struct table_struct device_table;
> > +bool_t iommuv2_enabled;
> >
> >  static int iommu_has_ht_flag(struct amd_iommu *iommu, u8 mask)
> >  {
> > @@ -759,6 +760,10 @@ static void enable_iommu(struct amd_iomm
> >          amd_iommu_flush_all_caches(iommu);
> >
> >      iommu->enabled = 1;
> > +
> > +    if ( iommu->features )
> > +        iommuv2_enabled = 1;
> > +
> >      spin_unlock_irqrestore(&iommu->lock, flags);
> >
> >  }
> >
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xensource.com
> > http://lists.xensource.com/xen-devel




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 14:07:17 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 14:07:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbBxZ-00015b-36; Thu, 15 Dec 2011 14:06:57 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Wang2@amd.com>) id 1RbBxY-00015T-3X
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 14:06:56 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1323957973!50763698!1
X-Originating-IP: [216.32.181.184]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21393 invoked from network); 15 Dec 2011 14:06:14 -0000
Received: from ch1ehsobe004.messaging.microsoft.com (HELO
	ch1outboundpool.messaging.microsoft.com) (216.32.181.184)
	by server-6.tower-27.messagelabs.com with AES128-SHA encrypted SMTP;
	15 Dec 2011 14:06:14 -0000
Received: from mail30-ch1-R.bigfish.com (10.43.68.240) by
	CH1EHSOBE008.bigfish.com (10.43.70.58) with Microsoft SMTP Server id
	14.1.225.23; Thu, 15 Dec 2011 14:06:54 +0000
Received: from mail30-ch1 (localhost [127.0.0.1])	by mail30-ch1-R.bigfish.com
	(Postfix) with ESMTP id 16D552A0373;
	Thu, 15 Dec 2011 14:06:59 +0000 (UTC)
X-SpamScore: -13
X-BigFish: VPS-13(zz1432N98dK4015Lzz1202hzzz2dh668h839h)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
Received: from mail30-ch1 (localhost.localdomain [127.0.0.1]) by mail30-ch1
	(MessageSwitch) id 1323958016746158_28834;
	Thu, 15 Dec 2011 14:06:56 +0000 (UTC)
Received: from CH1EHSMHS026.bigfish.com (snatpool1.int.messaging.microsoft.com
	[10.43.68.242])	by mail30-ch1.bigfish.com (Postfix) with ESMTP id
	96D29280048;	Thu, 15 Dec 2011 14:06:56 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	CH1EHSMHS026.bigfish.com (10.43.70.26) with Microsoft SMTP Server id
	14.1.225.23; Thu, 15 Dec 2011 14:06:49 +0000
X-WSS-ID: 0LW90JA-02-4J7-02
X-M-MSG: 
Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com
	[163.181.249.73])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp02.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2D4EFFCC010;	Thu, 15 Dec 2011 08:06:46 -0600 (CST)
Received: from sausexhtp01.amd.com (163.181.3.165) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Thu, 15 Dec 2011 08:07:02 -0600
Received: from storexhtp02.amd.com (172.24.4.4) by sausexhtp01.amd.com
	(163.181.3.165) with Microsoft SMTP Server (TLS) id 8.3.213.0;
	Thu, 15 Dec 2011 08:06:47 -0600
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Thu, 15 Dec 2011
	09:06:46 -0500
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id BD26549C34C; Thu, 15 Dec 2011
	14:06:45 +0000 (GMT)
Received: from gran.osrc.amd.com (gran.osrc.amd.com [165.204.15.57])	by
	mail.osrc.amd.com (Postfix) with ESMTP id A30515940FF; Thu, 15 Dec 2011
	15:06:45 +0100 (CET)
From: Wei Wang2 <wei.wang2@amd.com>
To: Tim Deegan <tim@xen.org>
Date: Thu, 15 Dec 2011 15:09:28 +0100
User-Agent: KMail/1.9.6 (enterprise 20070904.708012)
References: <patchbomb.1323876561@gran.amd.com>
	<ea52a2b93dffe708084f.1323876564@gran.amd.com>
	<20111215133555.GE4274@ocelot.phlegethon.org>
In-Reply-To: <20111215133555.GE4274@ocelot.phlegethon.org>
MIME-Version: 1.0
Content-Disposition: inline
Message-ID: <201112151509.29366.wei.wang2@amd.com>
X-OriginatorOrg: amd.com
Cc: xen-devel@lists.xensource.com, keir@xen.org, JBeulich@suse.com
Subject: Re: [Xen-devel] [PATCH 03 of 16] amd iommu: Add iommu emulation for
	hvm guest
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thursday 15 December 2011 14:35:55 Tim Deegan wrote:
> Hi,
>
> At 16:29 +0100 on 14 Dec (1323880164), Wei Wang wrote:
> > +static struct page_info* guest_iommu_get_page(struct list_head *pglist,
> > +                                              unsigned int entry_size,
> > +                                              unsigned int pos)
> > +{
> > +    int idx;
> > +    struct list_head *head;
> > +    struct guest_pages *gpage = NULL;
> > +
> > +    idx = (pos * entry_size) >> PAGE_SHIFT;
> > +    list_for_each( head, pglist )
> > +    {
> > +        gpage = list_entry(head, struct guest_pages, list);
> > +        if ( (--idx) < 0 )
> > +            break;
> > +    }
>
> Given that you allocate all these elements together, and free them, all
> together, why not just use an array instead of a linked list?
>
> Cheers,
>
> Tim.
The numbers of element might be variant. But array should also work, 
considering iommu tables has max. length of 2MB, the array length is small.

Thanks,
Wei


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 14:07:17 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 14:07:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbBxZ-00015b-36; Thu, 15 Dec 2011 14:06:57 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Wang2@amd.com>) id 1RbBxY-00015T-3X
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 14:06:56 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1323957973!50763698!1
X-Originating-IP: [216.32.181.184]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21393 invoked from network); 15 Dec 2011 14:06:14 -0000
Received: from ch1ehsobe004.messaging.microsoft.com (HELO
	ch1outboundpool.messaging.microsoft.com) (216.32.181.184)
	by server-6.tower-27.messagelabs.com with AES128-SHA encrypted SMTP;
	15 Dec 2011 14:06:14 -0000
Received: from mail30-ch1-R.bigfish.com (10.43.68.240) by
	CH1EHSOBE008.bigfish.com (10.43.70.58) with Microsoft SMTP Server id
	14.1.225.23; Thu, 15 Dec 2011 14:06:54 +0000
Received: from mail30-ch1 (localhost [127.0.0.1])	by mail30-ch1-R.bigfish.com
	(Postfix) with ESMTP id 16D552A0373;
	Thu, 15 Dec 2011 14:06:59 +0000 (UTC)
X-SpamScore: -13
X-BigFish: VPS-13(zz1432N98dK4015Lzz1202hzzz2dh668h839h)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
Received: from mail30-ch1 (localhost.localdomain [127.0.0.1]) by mail30-ch1
	(MessageSwitch) id 1323958016746158_28834;
	Thu, 15 Dec 2011 14:06:56 +0000 (UTC)
Received: from CH1EHSMHS026.bigfish.com (snatpool1.int.messaging.microsoft.com
	[10.43.68.242])	by mail30-ch1.bigfish.com (Postfix) with ESMTP id
	96D29280048;	Thu, 15 Dec 2011 14:06:56 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	CH1EHSMHS026.bigfish.com (10.43.70.26) with Microsoft SMTP Server id
	14.1.225.23; Thu, 15 Dec 2011 14:06:49 +0000
X-WSS-ID: 0LW90JA-02-4J7-02
X-M-MSG: 
Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com
	[163.181.249.73])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp02.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2D4EFFCC010;	Thu, 15 Dec 2011 08:06:46 -0600 (CST)
Received: from sausexhtp01.amd.com (163.181.3.165) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Thu, 15 Dec 2011 08:07:02 -0600
Received: from storexhtp02.amd.com (172.24.4.4) by sausexhtp01.amd.com
	(163.181.3.165) with Microsoft SMTP Server (TLS) id 8.3.213.0;
	Thu, 15 Dec 2011 08:06:47 -0600
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Thu, 15 Dec 2011
	09:06:46 -0500
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id BD26549C34C; Thu, 15 Dec 2011
	14:06:45 +0000 (GMT)
Received: from gran.osrc.amd.com (gran.osrc.amd.com [165.204.15.57])	by
	mail.osrc.amd.com (Postfix) with ESMTP id A30515940FF; Thu, 15 Dec 2011
	15:06:45 +0100 (CET)
From: Wei Wang2 <wei.wang2@amd.com>
To: Tim Deegan <tim@xen.org>
Date: Thu, 15 Dec 2011 15:09:28 +0100
User-Agent: KMail/1.9.6 (enterprise 20070904.708012)
References: <patchbomb.1323876561@gran.amd.com>
	<ea52a2b93dffe708084f.1323876564@gran.amd.com>
	<20111215133555.GE4274@ocelot.phlegethon.org>
In-Reply-To: <20111215133555.GE4274@ocelot.phlegethon.org>
MIME-Version: 1.0
Content-Disposition: inline
Message-ID: <201112151509.29366.wei.wang2@amd.com>
X-OriginatorOrg: amd.com
Cc: xen-devel@lists.xensource.com, keir@xen.org, JBeulich@suse.com
Subject: Re: [Xen-devel] [PATCH 03 of 16] amd iommu: Add iommu emulation for
	hvm guest
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thursday 15 December 2011 14:35:55 Tim Deegan wrote:
> Hi,
>
> At 16:29 +0100 on 14 Dec (1323880164), Wei Wang wrote:
> > +static struct page_info* guest_iommu_get_page(struct list_head *pglist,
> > +                                              unsigned int entry_size,
> > +                                              unsigned int pos)
> > +{
> > +    int idx;
> > +    struct list_head *head;
> > +    struct guest_pages *gpage = NULL;
> > +
> > +    idx = (pos * entry_size) >> PAGE_SHIFT;
> > +    list_for_each( head, pglist )
> > +    {
> > +        gpage = list_entry(head, struct guest_pages, list);
> > +        if ( (--idx) < 0 )
> > +            break;
> > +    }
>
> Given that you allocate all these elements together, and free them, all
> together, why not just use an array instead of a linked list?
>
> Cheers,
>
> Tim.
The numbers of element might be variant. But array should also work, 
considering iommu tables has max. length of 2MB, the array length is small.

Thanks,
Wei


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 14:14:06 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 14: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.xensource.com>)
	id 1RbC4C-0001MB-02; Thu, 15 Dec 2011 14:13:48 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1RbC4A-0001M5-3J
	for Xen-devel@lists.xensource.com; Thu, 15 Dec 2011 14:13:46 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1323958418!92049!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDY5Mjg=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11648 invoked from network); 15 Dec 2011 14:13:39 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 14:13:39 -0000
X-IronPort-AV: E=Sophos;i="4.71,357,1320642000"; d="scan'208";a="19993991"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Dec 2011 09:13:37 -0500
Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX02.citrite.net
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Thu, 15 Dec 2011
	09:13:37 -0500
Message-ID: <4EEA008E.5050002@citrix.com>
Date: Thu, 15 Dec 2011 14:13:34 +0000
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20111110 Icedove/3.0.11
MIME-Version: 1.0
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
References: <1323893534-436-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1323893534-436-2-git-send-email-dgdegra@tycho.nsa.gov>
In-Reply-To: <1323893534-436-2-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Xen-devel@lists.xensource.com, konrad.wilk@oracle.com
Subject: Re: [Xen-devel] [PATCH 1/6] xenbus: Support HVM backends
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 14/12/11 20:12, Daniel De Graaf wrote:
> Add HVM implementations of xenbus_(map,unmap)_ring_v(alloc,free) so
> that ring mappings can be done without using GNTMAP_contains_pte which
> is not supported on HVM.

Perhaps rename the functions to xenbus_map_ring() and
xenbus_unmap_ring()?  I wouldn't respin the series just for this though.

Is there merit in having the pv and hvm variants, instead of just the
hvm variant?

David



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 14:14:06 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 14: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.xensource.com>)
	id 1RbC4C-0001MB-02; Thu, 15 Dec 2011 14:13:48 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1RbC4A-0001M5-3J
	for Xen-devel@lists.xensource.com; Thu, 15 Dec 2011 14:13:46 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1323958418!92049!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDY5Mjg=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11648 invoked from network); 15 Dec 2011 14:13:39 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 14:13:39 -0000
X-IronPort-AV: E=Sophos;i="4.71,357,1320642000"; d="scan'208";a="19993991"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Dec 2011 09:13:37 -0500
Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX02.citrite.net
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Thu, 15 Dec 2011
	09:13:37 -0500
Message-ID: <4EEA008E.5050002@citrix.com>
Date: Thu, 15 Dec 2011 14:13:34 +0000
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20111110 Icedove/3.0.11
MIME-Version: 1.0
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
References: <1323893534-436-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1323893534-436-2-git-send-email-dgdegra@tycho.nsa.gov>
In-Reply-To: <1323893534-436-2-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Xen-devel@lists.xensource.com, konrad.wilk@oracle.com
Subject: Re: [Xen-devel] [PATCH 1/6] xenbus: Support HVM backends
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 14/12/11 20:12, Daniel De Graaf wrote:
> Add HVM implementations of xenbus_(map,unmap)_ring_v(alloc,free) so
> that ring mappings can be done without using GNTMAP_contains_pte which
> is not supported on HVM.

Perhaps rename the functions to xenbus_map_ring() and
xenbus_unmap_ring()?  I wouldn't respin the series just for this though.

Is there merit in having the pv and hvm variants, instead of just the
hvm variant?

David



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 14:14:26 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 14:14:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbC4X-0001Nb-DU; Thu, 15 Dec 2011 14:14:09 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RbC4V-0001Mr-85
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 14:14:07 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1323958440!5686841!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30354 invoked from network); 15 Dec 2011 14:14:00 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-13.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 15 Dec 2011 14:14:00 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 15 Dec 2011 14:14:00 +0000
Message-Id: <4EEA0EB502000078000682EA@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 15 Dec 2011 14:13:57 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Wang2" <wei.wang2@amd.com>
References: <patchbomb.1323876561@gran.amd.com>
	<ea52a2b93dffe708084f.1323876564@gran.amd.com>
	<20111215133555.GE4274@ocelot.phlegethon.org>
	<201112151509.29366.wei.wang2@amd.com>
In-Reply-To: <201112151509.29366.wei.wang2@amd.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Tim Deegan <tim@xen.org>, xen-devel@lists.xensource.com, keir@xen.org
Subject: Re: [Xen-devel] [PATCH 03 of 16] amd iommu: Add iommu emulation for
 hvm guest
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 15.12.11 at 15:09, Wei Wang2 <wei.wang2@amd.com> wrote:
> On Thursday 15 December 2011 14:35:55 Tim Deegan wrote:
>> Hi,
>>
>> At 16:29 +0100 on 14 Dec (1323880164), Wei Wang wrote:
>> > +static struct page_info* guest_iommu_get_page(struct list_head *pglist,
>> > +                                              unsigned int entry_size,
>> > +                                              unsigned int pos)
>> > +{
>> > +    int idx;
>> > +    struct list_head *head;
>> > +    struct guest_pages *gpage = NULL;
>> > +
>> > +    idx = (pos * entry_size) >> PAGE_SHIFT;
>> > +    list_for_each( head, pglist )
>> > +    {
>> > +        gpage = list_entry(head, struct guest_pages, list);
>> > +        if ( (--idx) < 0 )
>> > +            break;
>> > +    }
>>
>> Given that you allocate all these elements together, and free them, all
>> together, why not just use an array instead of a linked list?
>>
>> Cheers,
>>
>> Tim.
> The numbers of element might be variant. But array should also work, 
> considering iommu tables has max. length of 2MB, the array length is small.

Small enough so the array would fit in a single page?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 14:14:26 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 14:14:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbC4X-0001Nb-DU; Thu, 15 Dec 2011 14:14:09 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RbC4V-0001Mr-85
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 14:14:07 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1323958440!5686841!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30354 invoked from network); 15 Dec 2011 14:14:00 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-13.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 15 Dec 2011 14:14:00 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 15 Dec 2011 14:14:00 +0000
Message-Id: <4EEA0EB502000078000682EA@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 15 Dec 2011 14:13:57 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Wang2" <wei.wang2@amd.com>
References: <patchbomb.1323876561@gran.amd.com>
	<ea52a2b93dffe708084f.1323876564@gran.amd.com>
	<20111215133555.GE4274@ocelot.phlegethon.org>
	<201112151509.29366.wei.wang2@amd.com>
In-Reply-To: <201112151509.29366.wei.wang2@amd.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Tim Deegan <tim@xen.org>, xen-devel@lists.xensource.com, keir@xen.org
Subject: Re: [Xen-devel] [PATCH 03 of 16] amd iommu: Add iommu emulation for
 hvm guest
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 15.12.11 at 15:09, Wei Wang2 <wei.wang2@amd.com> wrote:
> On Thursday 15 December 2011 14:35:55 Tim Deegan wrote:
>> Hi,
>>
>> At 16:29 +0100 on 14 Dec (1323880164), Wei Wang wrote:
>> > +static struct page_info* guest_iommu_get_page(struct list_head *pglist,
>> > +                                              unsigned int entry_size,
>> > +                                              unsigned int pos)
>> > +{
>> > +    int idx;
>> > +    struct list_head *head;
>> > +    struct guest_pages *gpage = NULL;
>> > +
>> > +    idx = (pos * entry_size) >> PAGE_SHIFT;
>> > +    list_for_each( head, pglist )
>> > +    {
>> > +        gpage = list_entry(head, struct guest_pages, list);
>> > +        if ( (--idx) < 0 )
>> > +            break;
>> > +    }
>>
>> Given that you allocate all these elements together, and free them, all
>> together, why not just use an array instead of a linked list?
>>
>> Cheers,
>>
>> Tim.
> The numbers of element might be variant. But array should also work, 
> considering iommu tables has max. length of 2MB, the array length is small.

Small enough so the array would fit in a single page?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 14:26:40 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 14: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.xensource.com>)
	id 1RbCGP-0001h3-MZ; Thu, 15 Dec 2011 14:26:25 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RbCGO-0001gy-NF
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 14:26:24 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1323959178!7430947!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjI2MA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16146 invoked from network); 15 Dec 2011 14:26:18 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 14:26:18 -0000
X-IronPort-AV: E=Sophos;i="4.71,357,1320624000"; 
   d="scan'208";a="9491655"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Dec 2011 14:26:18 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 15 Dec 2011 14:26:17 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Wei Wang <wei.wang2@amd.com>
Date: Thu, 15 Dec 2011 14:26:17 +0000
In-Reply-To: <f9575683f10a08a86a9c.1323876575@gran.amd.com>
References: <patchbomb.1323876561@gran.amd.com>
	<f9575683f10a08a86a9c.1323876575@gran.amd.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323959177.20077.486.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, "JBeulich@suse.com" <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 14 of 16] libxl: bind virtual bdf to
 physical bdf after device assignment
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2011-12-14 at 15:29 +0000, Wei Wang wrote:
> # HG changeset patch
> # User Wei Wang <wei.wang2@amd.com>
> # Date 1323876142 -3600
> # Node ID f9575683f10a08a86a9c73226581610fa3f7be4b
> # Parent  04573463beff7fc9696f5ecdb940920dcc2ec0ca
> libxl: bind virtual bdf to physical bdf after device assignment
> 
> Signed-off-by: Wei Wang <wei.wang2@amd.com>
> 
> diff -r 04573463beff -r f9575683f10a tools/libxl/libxl_pci.c
> --- a/tools/libxl/libxl_pci.c	Wed Dec 14 16:22:21 2011 +0100
> +++ b/tools/libxl/libxl_pci.c	Wed Dec 14 16:22:22 2011 +0100
> @@ -735,6 +735,13 @@ out:
>              LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, rc, "xc_assign_device failed");
>              return ERROR_FAIL;
>          }
> +        if (LIBXL__DOMAIN_IS_TYPE(gc,  domid, HVM)) {
> +            rc = xc_domain_bind_pt_bdf(ctx->xch, domid, pcidev->vdevfn, pcidev_encode_bdf(pcidev));
> +            if ( rc ) {
> +            LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, rc, "xc_domain_bind_pt_bdf failed");
> +            return ERROR_FAIL;

Indentation here is off.

> +            }
> +        }
>      }
>  
>      if (!starting)
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 14:26:40 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 14: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.xensource.com>)
	id 1RbCGP-0001h3-MZ; Thu, 15 Dec 2011 14:26:25 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RbCGO-0001gy-NF
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 14:26:24 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1323959178!7430947!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjI2MA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16146 invoked from network); 15 Dec 2011 14:26:18 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 14:26:18 -0000
X-IronPort-AV: E=Sophos;i="4.71,357,1320624000"; 
   d="scan'208";a="9491655"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Dec 2011 14:26:18 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 15 Dec 2011 14:26:17 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Wei Wang <wei.wang2@amd.com>
Date: Thu, 15 Dec 2011 14:26:17 +0000
In-Reply-To: <f9575683f10a08a86a9c.1323876575@gran.amd.com>
References: <patchbomb.1323876561@gran.amd.com>
	<f9575683f10a08a86a9c.1323876575@gran.amd.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323959177.20077.486.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, "JBeulich@suse.com" <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 14 of 16] libxl: bind virtual bdf to
 physical bdf after device assignment
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2011-12-14 at 15:29 +0000, Wei Wang wrote:
> # HG changeset patch
> # User Wei Wang <wei.wang2@amd.com>
> # Date 1323876142 -3600
> # Node ID f9575683f10a08a86a9c73226581610fa3f7be4b
> # Parent  04573463beff7fc9696f5ecdb940920dcc2ec0ca
> libxl: bind virtual bdf to physical bdf after device assignment
> 
> Signed-off-by: Wei Wang <wei.wang2@amd.com>
> 
> diff -r 04573463beff -r f9575683f10a tools/libxl/libxl_pci.c
> --- a/tools/libxl/libxl_pci.c	Wed Dec 14 16:22:21 2011 +0100
> +++ b/tools/libxl/libxl_pci.c	Wed Dec 14 16:22:22 2011 +0100
> @@ -735,6 +735,13 @@ out:
>              LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, rc, "xc_assign_device failed");
>              return ERROR_FAIL;
>          }
> +        if (LIBXL__DOMAIN_IS_TYPE(gc,  domid, HVM)) {
> +            rc = xc_domain_bind_pt_bdf(ctx->xch, domid, pcidev->vdevfn, pcidev_encode_bdf(pcidev));
> +            if ( rc ) {
> +            LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, rc, "xc_domain_bind_pt_bdf failed");
> +            return ERROR_FAIL;

Indentation here is off.

> +            }
> +        }
>      }
>  
>      if (!starting)
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 14:31:08 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 14:31:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbCKi-0001qt-Cj; Thu, 15 Dec 2011 14:30:52 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RbCKh-0001qg-Dp
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 14:30:51 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1323959445!8202447!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjI2MA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31910 invoked from network); 15 Dec 2011 14:30:45 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 14:30:45 -0000
X-IronPort-AV: E=Sophos;i="4.71,357,1320624000"; 
   d="scan'208";a="9491788"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Dec 2011 14:30:45 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 15 Dec 2011 14:30:45 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Wei Wang <wei.wang2@amd.com>
Date: Thu, 15 Dec 2011 14:30:44 +0000
In-Reply-To: <24f4a0a23da71c58f457.1323876577@gran.amd.com>
References: <patchbomb.1323876561@gran.amd.com>
	<24f4a0a23da71c58f457.1323876577@gran.amd.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323959445.20077.490.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, "JBeulich@suse.com" <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 16 of 16] libxl: add iommu parameter to
 qemu-dm
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2011-12-14 at 15:29 +0000, Wei Wang wrote:
> # HG changeset patch
> # User Wei Wang <wei.wang2@amd.com>
> # Date 1323876144 -3600
> # Node ID 24f4a0a23da71c58f457f0bf98aa8238dd45332d
> # Parent  93658ca85035d6a4e56e2e6602c02859974d30a4
> libxl: add iommu parameter to qemu-dm.
> When iomm = 0, virtual iommu device will be disabled.
> 
> Signed-off-by: Wei Wang <wei.wang2@amd.com>
> 
> diff -r 93658ca85035 -r 24f4a0a23da7 tools/libxl/libxl_dm.c
> --- a/tools/libxl/libxl_dm.c	Wed Dec 14 16:22:23 2011 +0100
> +++ b/tools/libxl/libxl_dm.c	Wed Dec 14 16:22:24 2011 +0100
> @@ -194,6 +194,9 @@ static char ** libxl__build_device_model
>          if (info->gfx_passthru) {
>              flexarray_append(dm_args, "-gfx_passthru");
>          }
> +        if (info->iommu) {
> +            flexarray_append(dm_args, "-iommu");
> +        }
>      }
>      if (info->saved_state) {
>          flexarray_vappend(dm_args, "-loadvm", info->saved_state, NULL);
> @@ -404,6 +407,9 @@ static char ** libxl__build_device_model
>          if (info->gfx_passthru) {
>              flexarray_append(dm_args, "-gfx_passthru");
>          }
> +        if (info->iommu) {
> +            flexarray_append(dm_args, "-iommu");
> +        }
>      }
>      if (info->saved_state) {
>          /* This file descriptor is meant to be used by QEMU */
> diff -r 93658ca85035 -r 24f4a0a23da7 tools/libxl/libxl_types.idl
> --- a/tools/libxl/libxl_types.idl	Wed Dec 14 16:22:23 2011 +0100
> +++ b/tools/libxl/libxl_types.idl	Wed Dec 14 16:22:24 2011 +0100
> @@ -254,6 +254,7 @@ The password never expires"""),
>      ("extra",            libxl_string_list, False, "extra parameters pass directly to qemu, NULL terminated"),
>      ("extra_pv",         libxl_string_list, False, "extra parameters pass directly to qemu for PV guest, NULL terminated"),
>      ("extra_hvm",        libxl_string_list, False, "extra parameters pass directly to qemu for HVM guest, NULL terminated"),
> +    ("iommu",            bool,              False, "guest iommu enabled or disabled"),
>      ],
>      comment=
>  """Device Model information.
> diff -r 93658ca85035 -r 24f4a0a23da7 tools/libxl/xl_cmdimpl.c
> --- a/tools/libxl/xl_cmdimpl.c	Wed Dec 14 16:22:23 2011 +0100
> +++ b/tools/libxl/xl_cmdimpl.c	Wed Dec 14 16:22:24 2011 +0100
> @@ -386,6 +386,7 @@ static void printf_info(int domid,
>          printf("\t\t\t(spicedisable_ticketing %d)\n",
>                      dm_info->spicedisable_ticketing);
>          printf("\t\t\t(spiceagent_mouse %d)\n", dm_info->spiceagent_mouse);
> +        printf("\t\t\t(iommu %d)\n", dm_info->iommu);
>          printf("\t\t)\n");
>          break;
>      case LIBXL_DOMAIN_TYPE_PV:
> @@ -1217,6 +1218,8 @@ skip_vfb:
>          xlu_cfg_replace_string (config, "soundhw", &dm_info->soundhw, 0);
>          if (!xlu_cfg_get_long (config, "xen_platform_pci", &l, 0))
>              dm_info->xen_platform_pci = l;
> +        if (!xlu_cfg_get_long (config, "iommu", &l, 0))
> +            dm_info->iommu = l;

Didn't you already parse this same key into the build_info? Is there
ever a possibility of the dm_info and build_info versions of this field
differing?

Assuming not I think this setting ought to only live in one place and I
think build_info should be that place rather than the dm info. That
might need some refactoring in libxl to pass the right struct down.

Also you have only CC'd the hypervisor maintainers on this (and the
other?) tool stack patch. Please check MAINTAINERS to see who ought to
be CC'd.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 14:31:08 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 14:31:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbCKi-0001qt-Cj; Thu, 15 Dec 2011 14:30:52 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RbCKh-0001qg-Dp
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 14:30:51 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1323959445!8202447!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjI2MA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31910 invoked from network); 15 Dec 2011 14:30:45 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 14:30:45 -0000
X-IronPort-AV: E=Sophos;i="4.71,357,1320624000"; 
   d="scan'208";a="9491788"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Dec 2011 14:30:45 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 15 Dec 2011 14:30:45 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Wei Wang <wei.wang2@amd.com>
Date: Thu, 15 Dec 2011 14:30:44 +0000
In-Reply-To: <24f4a0a23da71c58f457.1323876577@gran.amd.com>
References: <patchbomb.1323876561@gran.amd.com>
	<24f4a0a23da71c58f457.1323876577@gran.amd.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323959445.20077.490.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, "JBeulich@suse.com" <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 16 of 16] libxl: add iommu parameter to
 qemu-dm
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2011-12-14 at 15:29 +0000, Wei Wang wrote:
> # HG changeset patch
> # User Wei Wang <wei.wang2@amd.com>
> # Date 1323876144 -3600
> # Node ID 24f4a0a23da71c58f457f0bf98aa8238dd45332d
> # Parent  93658ca85035d6a4e56e2e6602c02859974d30a4
> libxl: add iommu parameter to qemu-dm.
> When iomm = 0, virtual iommu device will be disabled.
> 
> Signed-off-by: Wei Wang <wei.wang2@amd.com>
> 
> diff -r 93658ca85035 -r 24f4a0a23da7 tools/libxl/libxl_dm.c
> --- a/tools/libxl/libxl_dm.c	Wed Dec 14 16:22:23 2011 +0100
> +++ b/tools/libxl/libxl_dm.c	Wed Dec 14 16:22:24 2011 +0100
> @@ -194,6 +194,9 @@ static char ** libxl__build_device_model
>          if (info->gfx_passthru) {
>              flexarray_append(dm_args, "-gfx_passthru");
>          }
> +        if (info->iommu) {
> +            flexarray_append(dm_args, "-iommu");
> +        }
>      }
>      if (info->saved_state) {
>          flexarray_vappend(dm_args, "-loadvm", info->saved_state, NULL);
> @@ -404,6 +407,9 @@ static char ** libxl__build_device_model
>          if (info->gfx_passthru) {
>              flexarray_append(dm_args, "-gfx_passthru");
>          }
> +        if (info->iommu) {
> +            flexarray_append(dm_args, "-iommu");
> +        }
>      }
>      if (info->saved_state) {
>          /* This file descriptor is meant to be used by QEMU */
> diff -r 93658ca85035 -r 24f4a0a23da7 tools/libxl/libxl_types.idl
> --- a/tools/libxl/libxl_types.idl	Wed Dec 14 16:22:23 2011 +0100
> +++ b/tools/libxl/libxl_types.idl	Wed Dec 14 16:22:24 2011 +0100
> @@ -254,6 +254,7 @@ The password never expires"""),
>      ("extra",            libxl_string_list, False, "extra parameters pass directly to qemu, NULL terminated"),
>      ("extra_pv",         libxl_string_list, False, "extra parameters pass directly to qemu for PV guest, NULL terminated"),
>      ("extra_hvm",        libxl_string_list, False, "extra parameters pass directly to qemu for HVM guest, NULL terminated"),
> +    ("iommu",            bool,              False, "guest iommu enabled or disabled"),
>      ],
>      comment=
>  """Device Model information.
> diff -r 93658ca85035 -r 24f4a0a23da7 tools/libxl/xl_cmdimpl.c
> --- a/tools/libxl/xl_cmdimpl.c	Wed Dec 14 16:22:23 2011 +0100
> +++ b/tools/libxl/xl_cmdimpl.c	Wed Dec 14 16:22:24 2011 +0100
> @@ -386,6 +386,7 @@ static void printf_info(int domid,
>          printf("\t\t\t(spicedisable_ticketing %d)\n",
>                      dm_info->spicedisable_ticketing);
>          printf("\t\t\t(spiceagent_mouse %d)\n", dm_info->spiceagent_mouse);
> +        printf("\t\t\t(iommu %d)\n", dm_info->iommu);
>          printf("\t\t)\n");
>          break;
>      case LIBXL_DOMAIN_TYPE_PV:
> @@ -1217,6 +1218,8 @@ skip_vfb:
>          xlu_cfg_replace_string (config, "soundhw", &dm_info->soundhw, 0);
>          if (!xlu_cfg_get_long (config, "xen_platform_pci", &l, 0))
>              dm_info->xen_platform_pci = l;
> +        if (!xlu_cfg_get_long (config, "iommu", &l, 0))
> +            dm_info->iommu = l;

Didn't you already parse this same key into the build_info? Is there
ever a possibility of the dm_info and build_info versions of this field
differing?

Assuming not I think this setting ought to only live in one place and I
think build_info should be that place rather than the dm info. That
might need some refactoring in libxl to pass the right struct down.

Also you have only CC'd the hypervisor maintainers on this (and the
other?) tool stack patch. Please check MAINTAINERS to see who ought to
be CC'd.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 14:32:24 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 14:32:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbCLu-000236-2I; Thu, 15 Dec 2011 14:32:06 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Wang2@amd.com>) id 1RbCLs-00021c-K2
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 14:32:04 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1323959516!5513512!1
X-Originating-IP: [65.55.88.12]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15677 invoked from network); 15 Dec 2011 14:31:58 -0000
Received: from tx2ehsobe002.messaging.microsoft.com (HELO
	TX2EHSOBE003.bigfish.com) (65.55.88.12)
	by server-15.tower-174.messagelabs.com with AES128-SHA encrypted SMTP;
	15 Dec 2011 14:31:58 -0000
Received: from mail153-tx2-R.bigfish.com (10.9.14.246) by
	TX2EHSOBE003.bigfish.com (10.9.40.23) with Microsoft SMTP Server id
	14.1.225.23; Thu, 15 Dec 2011 14:31:57 +0000
Received: from mail153-tx2 (localhost [127.0.0.1])	by
	mail153-tx2-R.bigfish.com (Postfix) with ESMTP id 254F94802A4;
	Thu, 15 Dec 2011 14:32:02 +0000 (UTC)
X-SpamScore: -13
X-BigFish: VPS-13(zz1432N98dK4015Lzz1202hzz8275bhz2dh668h839h61h)
X-Spam-TCS-SCL: 0:0
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
X-FB-SS: 0,
Received: from mail153-tx2 (localhost.localdomain [127.0.0.1]) by mail153-tx2
	(MessageSwitch) id 1323959480285225_25210;
	Thu, 15 Dec 2011 14:31:20 +0000 (UTC)
Received: from TX2EHSMHS023.bigfish.com (unknown [10.9.14.244])	by
	mail153-tx2.bigfish.com (Postfix) with ESMTP id 34945340048;
	Thu, 15 Dec 2011 14:31:20 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	TX2EHSMHS023.bigfish.com (10.9.99.123) with Microsoft SMTP Server id
	14.1.225.23; Thu, 15 Dec 2011 14:29:01 +0000
X-WSS-ID: 0LW91K9-01-GJQ-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2DC51102805A;	Thu, 15 Dec 2011 08:28:57 -0600 (CST)
Received: from SAUSEXDAG01.amd.com (163.181.55.1) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Thu, 15 Dec 2011 08:29:13 -0600
Received: from storexhtp01.amd.com (172.24.4.3) by sausexdag01.amd.com
	(163.181.55.1) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Thu, 15 Dec 2011 08:28:58 -0600
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp01.amd.com
	(172.24.4.3) with Microsoft SMTP Server id 8.3.213.0; Thu, 15 Dec 2011
	09:27:56 -0500
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id A93B849C34C; Thu, 15 Dec 2011
	14:27:53 +0000 (GMT)
Received: from gran.osrc.amd.com (gran.osrc.amd.com [165.204.15.57])	by
	mail.osrc.amd.com (Postfix) with ESMTP id 91EE95940FF; Thu, 15 Dec 2011
	15:27:53 +0100 (CET)
From: Wei Wang2 <wei.wang2@amd.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Thu, 15 Dec 2011 15:30:36 +0100
User-Agent: KMail/1.9.6 (enterprise 20070904.708012)
References: <patchbomb.1323876561@gran.amd.com>
	<201112151509.29366.wei.wang2@amd.com>
	<4EEA0EB502000078000682EA@nat28.tlf.novell.com>
In-Reply-To: <4EEA0EB502000078000682EA@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
Message-ID: <201112151530.36889.wei.wang2@amd.com>
X-OriginatorOrg: amd.com
Cc: Tim Deegan <tim@xen.org>, xen-devel@lists.xensource.com, keir@xen.org
Subject: Re: [Xen-devel] [PATCH 03 of 16] amd iommu: Add iommu emulation for
	hvm guest
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thursday 15 December 2011 15:13:57 Jan Beulich wrote:
> >>> On 15.12.11 at 15:09, Wei Wang2 <wei.wang2@amd.com> wrote:
> >
> > On Thursday 15 December 2011 14:35:55 Tim Deegan wrote:
> >> Hi,
> >>
> >> At 16:29 +0100 on 14 Dec (1323880164), Wei Wang wrote:
> >> > +static struct page_info* guest_iommu_get_page(struct list_head
> >> > *pglist, +                                              unsigned int
> >> > entry_size, +                                              unsigned
> >> > int pos) +{
> >> > +    int idx;
> >> > +    struct list_head *head;
> >> > +    struct guest_pages *gpage = NULL;
> >> > +
> >> > +    idx = (pos * entry_size) >> PAGE_SHIFT;
> >> > +    list_for_each( head, pglist )
> >> > +    {
> >> > +        gpage = list_entry(head, struct guest_pages, list);
> >> > +        if ( (--idx) < 0 )
> >> > +            break;
> >> > +    }
> >>
> >> Given that you allocate all these elements together, and free them, all
> >> together, why not just use an array instead of a linked list?
> >>
> >> Cheers,
> >>
> >> Tim.
> >
> > The numbers of element might be variant. But array should also work,
> > considering iommu tables has max. length of 2MB, the array length is
> > small.
>
> Small enough so the array would fit in a single page?
>
> Jan

Well...then, How about that I just save the first gfn of the table base 
address and mapping gfn + n dynamically? Since all gfns for iommu tables must 
be contiguous guest space..

Thanks,
Wei


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 14:32:24 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 14:32:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbCLu-000236-2I; Thu, 15 Dec 2011 14:32:06 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Wang2@amd.com>) id 1RbCLs-00021c-K2
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 14:32:04 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1323959516!5513512!1
X-Originating-IP: [65.55.88.12]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15677 invoked from network); 15 Dec 2011 14:31:58 -0000
Received: from tx2ehsobe002.messaging.microsoft.com (HELO
	TX2EHSOBE003.bigfish.com) (65.55.88.12)
	by server-15.tower-174.messagelabs.com with AES128-SHA encrypted SMTP;
	15 Dec 2011 14:31:58 -0000
Received: from mail153-tx2-R.bigfish.com (10.9.14.246) by
	TX2EHSOBE003.bigfish.com (10.9.40.23) with Microsoft SMTP Server id
	14.1.225.23; Thu, 15 Dec 2011 14:31:57 +0000
Received: from mail153-tx2 (localhost [127.0.0.1])	by
	mail153-tx2-R.bigfish.com (Postfix) with ESMTP id 254F94802A4;
	Thu, 15 Dec 2011 14:32:02 +0000 (UTC)
X-SpamScore: -13
X-BigFish: VPS-13(zz1432N98dK4015Lzz1202hzz8275bhz2dh668h839h61h)
X-Spam-TCS-SCL: 0:0
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
X-FB-SS: 0,
Received: from mail153-tx2 (localhost.localdomain [127.0.0.1]) by mail153-tx2
	(MessageSwitch) id 1323959480285225_25210;
	Thu, 15 Dec 2011 14:31:20 +0000 (UTC)
Received: from TX2EHSMHS023.bigfish.com (unknown [10.9.14.244])	by
	mail153-tx2.bigfish.com (Postfix) with ESMTP id 34945340048;
	Thu, 15 Dec 2011 14:31:20 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	TX2EHSMHS023.bigfish.com (10.9.99.123) with Microsoft SMTP Server id
	14.1.225.23; Thu, 15 Dec 2011 14:29:01 +0000
X-WSS-ID: 0LW91K9-01-GJQ-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2DC51102805A;	Thu, 15 Dec 2011 08:28:57 -0600 (CST)
Received: from SAUSEXDAG01.amd.com (163.181.55.1) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Thu, 15 Dec 2011 08:29:13 -0600
Received: from storexhtp01.amd.com (172.24.4.3) by sausexdag01.amd.com
	(163.181.55.1) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Thu, 15 Dec 2011 08:28:58 -0600
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp01.amd.com
	(172.24.4.3) with Microsoft SMTP Server id 8.3.213.0; Thu, 15 Dec 2011
	09:27:56 -0500
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id A93B849C34C; Thu, 15 Dec 2011
	14:27:53 +0000 (GMT)
Received: from gran.osrc.amd.com (gran.osrc.amd.com [165.204.15.57])	by
	mail.osrc.amd.com (Postfix) with ESMTP id 91EE95940FF; Thu, 15 Dec 2011
	15:27:53 +0100 (CET)
From: Wei Wang2 <wei.wang2@amd.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Thu, 15 Dec 2011 15:30:36 +0100
User-Agent: KMail/1.9.6 (enterprise 20070904.708012)
References: <patchbomb.1323876561@gran.amd.com>
	<201112151509.29366.wei.wang2@amd.com>
	<4EEA0EB502000078000682EA@nat28.tlf.novell.com>
In-Reply-To: <4EEA0EB502000078000682EA@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
Message-ID: <201112151530.36889.wei.wang2@amd.com>
X-OriginatorOrg: amd.com
Cc: Tim Deegan <tim@xen.org>, xen-devel@lists.xensource.com, keir@xen.org
Subject: Re: [Xen-devel] [PATCH 03 of 16] amd iommu: Add iommu emulation for
	hvm guest
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thursday 15 December 2011 15:13:57 Jan Beulich wrote:
> >>> On 15.12.11 at 15:09, Wei Wang2 <wei.wang2@amd.com> wrote:
> >
> > On Thursday 15 December 2011 14:35:55 Tim Deegan wrote:
> >> Hi,
> >>
> >> At 16:29 +0100 on 14 Dec (1323880164), Wei Wang wrote:
> >> > +static struct page_info* guest_iommu_get_page(struct list_head
> >> > *pglist, +                                              unsigned int
> >> > entry_size, +                                              unsigned
> >> > int pos) +{
> >> > +    int idx;
> >> > +    struct list_head *head;
> >> > +    struct guest_pages *gpage = NULL;
> >> > +
> >> > +    idx = (pos * entry_size) >> PAGE_SHIFT;
> >> > +    list_for_each( head, pglist )
> >> > +    {
> >> > +        gpage = list_entry(head, struct guest_pages, list);
> >> > +        if ( (--idx) < 0 )
> >> > +            break;
> >> > +    }
> >>
> >> Given that you allocate all these elements together, and free them, all
> >> together, why not just use an array instead of a linked list?
> >>
> >> Cheers,
> >>
> >> Tim.
> >
> > The numbers of element might be variant. But array should also work,
> > considering iommu tables has max. length of 2MB, the array length is
> > small.
>
> Small enough so the array would fit in a single page?
>
> Jan

Well...then, How about that I just save the first gfn of the table base 
address and mapping gfn + n dynamically? Since all gfns for iommu tables must 
be contiguous guest space..

Thanks,
Wei


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 14:38:51 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 14:38:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbCS9-0002MU-VZ; Thu, 15 Dec 2011 14:38:33 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RbCS8-0002MN-QQ
	for Xen-devel@lists.xensource.com; Thu, 15 Dec 2011 14:38:33 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-5.tower-21.messagelabs.com!1323959906!2091291!1
X-Originating-IP: [63.239.65.40]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31580 invoked from network); 15 Dec 2011 14:38:26 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-5.tower-21.messagelabs.com with SMTP;
	15 Dec 2011 14:38:26 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea02.nsa.gov (8.12.10/8.12.10) with ESMTP id
	pBFEcOtO003905; Thu, 15 Dec 2011 14:38:24 GMT
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id pBFEcOKR024305; 
	Thu, 15 Dec 2011 09:38:24 -0500
Message-ID: <4EEA0677.5060100@tycho.nsa.gov>
Date: Thu, 15 Dec 2011 09:38:47 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:7.0.1) Gecko/20110930 Thunderbird/7.0.1
MIME-Version: 1.0
To: David Vrabel <david.vrabel@citrix.com>
References: <1323893534-436-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1323893534-436-2-git-send-email-dgdegra@tycho.nsa.gov>
	<4EEA008E.5050002@citrix.com>
In-Reply-To: <4EEA008E.5050002@citrix.com>
X-Enigmail-Version: 1.3.2
Cc: Xen-devel@lists.xensource.com, konrad.wilk@oracle.com
Subject: Re: [Xen-devel] [PATCH 1/6] xenbus: Support HVM backends
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 12/15/2011 09:13 AM, David Vrabel wrote:
> On 14/12/11 20:12, Daniel De Graaf wrote:
>> Add HVM implementations of xenbus_(map,unmap)_ring_v(alloc,free) so
>> that ring mappings can be done without using GNTMAP_contains_pte which
>> is not supported on HVM.
> 
> Perhaps rename the functions to xenbus_map_ring() and
> xenbus_unmap_ring()?  I wouldn't respin the series just for this though.
> 
> Is there merit in having the pv and hvm variants, instead of just the
> hvm variant?
> 
> David
> 

There are already functions called xenbus_{map,unmap}_ring - they do the
actual mapping in the HVM case, with the _valloc versions just adding in
memory alloc/free.

The PV versions are slightly faster because they won't require additional
page table updates. Otherwise, I believe that the HVM variant should work
on both PV&HVM.

-- 
Daniel De Graaf
National Security Agency

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 14:38:51 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 14:38:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbCS9-0002MU-VZ; Thu, 15 Dec 2011 14:38:33 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RbCS8-0002MN-QQ
	for Xen-devel@lists.xensource.com; Thu, 15 Dec 2011 14:38:33 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-5.tower-21.messagelabs.com!1323959906!2091291!1
X-Originating-IP: [63.239.65.40]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31580 invoked from network); 15 Dec 2011 14:38:26 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-5.tower-21.messagelabs.com with SMTP;
	15 Dec 2011 14:38:26 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea02.nsa.gov (8.12.10/8.12.10) with ESMTP id
	pBFEcOtO003905; Thu, 15 Dec 2011 14:38:24 GMT
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id pBFEcOKR024305; 
	Thu, 15 Dec 2011 09:38:24 -0500
Message-ID: <4EEA0677.5060100@tycho.nsa.gov>
Date: Thu, 15 Dec 2011 09:38:47 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:7.0.1) Gecko/20110930 Thunderbird/7.0.1
MIME-Version: 1.0
To: David Vrabel <david.vrabel@citrix.com>
References: <1323893534-436-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1323893534-436-2-git-send-email-dgdegra@tycho.nsa.gov>
	<4EEA008E.5050002@citrix.com>
In-Reply-To: <4EEA008E.5050002@citrix.com>
X-Enigmail-Version: 1.3.2
Cc: Xen-devel@lists.xensource.com, konrad.wilk@oracle.com
Subject: Re: [Xen-devel] [PATCH 1/6] xenbus: Support HVM backends
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 12/15/2011 09:13 AM, David Vrabel wrote:
> On 14/12/11 20:12, Daniel De Graaf wrote:
>> Add HVM implementations of xenbus_(map,unmap)_ring_v(alloc,free) so
>> that ring mappings can be done without using GNTMAP_contains_pte which
>> is not supported on HVM.
> 
> Perhaps rename the functions to xenbus_map_ring() and
> xenbus_unmap_ring()?  I wouldn't respin the series just for this though.
> 
> Is there merit in having the pv and hvm variants, instead of just the
> hvm variant?
> 
> David
> 

There are already functions called xenbus_{map,unmap}_ring - they do the
actual mapping in the HVM case, with the _valloc versions just adding in
memory alloc/free.

The PV versions are slightly faster because they won't require additional
page table updates. Otherwise, I believe that the HVM variant should work
on both PV&HVM.

-- 
Daniel De Graaf
National Security Agency

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 14:45:17 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 14:45:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbCYK-0002WK-Rd; Thu, 15 Dec 2011 14:44:56 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RbCYJ-0002W8-Io
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 14:44:55 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1323960289!5712822!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjI2MA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20983 invoked from network); 15 Dec 2011 14:44:49 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 14:44:49 -0000
X-IronPort-AV: E=Sophos;i="4.71,357,1320624000"; 
   d="scan'208";a="9492133"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Dec 2011 14:44:49 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 15 Dec 2011 14:44:49 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RbCYC-0006aB-SL; Thu, 15 Dec 2011 14:44:48 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RbCYC-0002QQ-Py;
	Thu, 15 Dec 2011 14:44:48 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20202.2016.788485.260971@mariner.uk.xensource.com>
Date: Thu, 15 Dec 2011 14:44:48 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1323941785.20077.447.camel@zakaz.uk.xensource.com>
References: <patchbomb.1323792779@cosworth.uk.xensource.com>
	<1323941785.20077.447.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Olaf Hering <olaf@aepfle.de>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Vincent Hanquez <Vincent.Hanquez@eu.citrix.com>,
	Jonathan Ludlam <Jonathan.Ludlam@eu.citrix.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH 0 of 4 V2] oxenstored fixes -- fixes recent
 pvops kernel hang
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("Re: [Xen-devel] [PATCH 0 of 4 V2] oxenstored fixes -- fixes recent pvops kernel hang"):
> On Tue, 2011-12-13 at 16:12 +0000, Ian Campbell wrote:
> > I also include a patch which I've been using for some time to enable
> > the use of oxenstored in preference to C xenstored when available.
> 
> Can you also arrange for the test system to
> collect /etc/xen/oxenstored.conf, /var/log/xenstored.conf*
> and /var/log/xenstored-access.log* please.

I hadn't spotted these filenames in the source for oxenstored.
"/var/log/xenstored.conf*" ?!  omg wtf bbq

Surely these should all be in /var/log/xen.

But I have added them to the list of files to be collected.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 14:45:17 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 14:45:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbCYK-0002WK-Rd; Thu, 15 Dec 2011 14:44:56 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RbCYJ-0002W8-Io
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 14:44:55 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1323960289!5712822!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjI2MA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20983 invoked from network); 15 Dec 2011 14:44:49 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 14:44:49 -0000
X-IronPort-AV: E=Sophos;i="4.71,357,1320624000"; 
   d="scan'208";a="9492133"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Dec 2011 14:44:49 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 15 Dec 2011 14:44:49 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RbCYC-0006aB-SL; Thu, 15 Dec 2011 14:44:48 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RbCYC-0002QQ-Py;
	Thu, 15 Dec 2011 14:44:48 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20202.2016.788485.260971@mariner.uk.xensource.com>
Date: Thu, 15 Dec 2011 14:44:48 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1323941785.20077.447.camel@zakaz.uk.xensource.com>
References: <patchbomb.1323792779@cosworth.uk.xensource.com>
	<1323941785.20077.447.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Olaf Hering <olaf@aepfle.de>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Vincent Hanquez <Vincent.Hanquez@eu.citrix.com>,
	Jonathan Ludlam <Jonathan.Ludlam@eu.citrix.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH 0 of 4 V2] oxenstored fixes -- fixes recent
 pvops kernel hang
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("Re: [Xen-devel] [PATCH 0 of 4 V2] oxenstored fixes -- fixes recent pvops kernel hang"):
> On Tue, 2011-12-13 at 16:12 +0000, Ian Campbell wrote:
> > I also include a patch which I've been using for some time to enable
> > the use of oxenstored in preference to C xenstored when available.
> 
> Can you also arrange for the test system to
> collect /etc/xen/oxenstored.conf, /var/log/xenstored.conf*
> and /var/log/xenstored-access.log* please.

I hadn't spotted these filenames in the source for oxenstored.
"/var/log/xenstored.conf*" ?!  omg wtf bbq

Surely these should all be in /var/log/xen.

But I have added them to the list of files to be collected.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 14:52:00 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 14:52:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbCep-0002gW-Mz; Thu, 15 Dec 2011 14:51:39 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Wang2@amd.com>) id 1RbCen-0002gJ-Qw
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 14:51:38 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1323960689!5655613!1
X-Originating-IP: [65.55.88.14]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8806 invoked from network); 15 Dec 2011 14:51:31 -0000
Received: from tx2ehsobe004.messaging.microsoft.com (HELO
	TX2EHSOBE009.bigfish.com) (65.55.88.14)
	by server-12.tower-174.messagelabs.com with AES128-SHA encrypted SMTP;
	15 Dec 2011 14:51:31 -0000
Received: from mail45-tx2-R.bigfish.com (10.9.14.243) by
	TX2EHSOBE009.bigfish.com (10.9.40.29) with Microsoft SMTP Server id
	14.1.225.23; Thu, 15 Dec 2011 14:51:30 +0000
Received: from mail45-tx2 (localhost [127.0.0.1])	by mail45-tx2-R.bigfish.com
	(Postfix) with ESMTP id 0B0C71403DD;
	Thu, 15 Dec 2011 14:51:35 +0000 (UTC)
X-SpamScore: -16
X-BigFish: VPS-16(zz936eK1432N98dK4015Lzz1202hzz8275bhz2dh668h839h93fh61h)
X-Spam-TCS-SCL: 0:0
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
X-FB-SS: 0,
Received: from mail45-tx2 (localhost.localdomain [127.0.0.1]) by mail45-tx2
	(MessageSwitch) id 1323960648712598_20099;
	Thu, 15 Dec 2011 14:50:48 +0000 (UTC)
Received: from TX2EHSMHS017.bigfish.com (unknown [10.9.14.239])	by
	mail45-tx2.bigfish.com (Postfix) with ESMTP id 15C4822004E;
	Thu, 15 Dec 2011 14:50:48 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	TX2EHSMHS017.bigfish.com (10.9.99.117) with Microsoft SMTP Server id
	14.1.225.23; Thu, 15 Dec 2011 14:50:33 +0000
X-WSS-ID: 0LW92K5-01-0SC-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 224B81028053;	Thu, 15 Dec 2011 08:50:28 -0600 (CST)
Received: from SAUSEXDAG04.amd.com (163.181.55.4) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Thu, 15 Dec 2011 08:50:44 -0600
Received: from storexhtp01.amd.com (172.24.4.3) by sausexdag04.amd.com
	(163.181.55.4) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Thu, 15 Dec 2011 08:50:29 -0600
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp01.amd.com
	(172.24.4.3) with Microsoft SMTP Server id 8.3.213.0; Thu, 15 Dec 2011
	09:49:27 -0500
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id C0DB549C34C; Thu, 15 Dec 2011
	14:49:25 +0000 (GMT)
Received: from gran.osrc.amd.com (gran.osrc.amd.com [165.204.15.57])	by
	mail.osrc.amd.com (Postfix) with ESMTP id A7F895940FF; Thu, 15 Dec 2011
	15:49:25 +0100 (CET)
From: Wei Wang2 <wei.wang2@amd.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Thu, 15 Dec 2011 15:52:08 +0100
User-Agent: KMail/1.9.6 (enterprise 20070904.708012)
References: <patchbomb.1323876561@gran.amd.com>
	<24f4a0a23da71c58f457.1323876577@gran.amd.com>
	<1323959445.20077.490.camel@zakaz.uk.xensource.com>
In-Reply-To: <1323959445.20077.490.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
Message-ID: <201112151552.09037.wei.wang2@amd.com>
X-OriginatorOrg: amd.com
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, "JBeulich@suse.com" <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 16 of 16] libxl: add iommu parameter to
	qemu-dm
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thursday 15 December 2011 15:30:44 Ian Campbell wrote:
> On Wed, 2011-12-14 at 15:29 +0000, Wei Wang wrote:
> > # HG changeset patch
> > # User Wei Wang <wei.wang2@amd.com>
> > # Date 1323876144 -3600
> > # Node ID 24f4a0a23da71c58f457f0bf98aa8238dd45332d
> > # Parent  93658ca85035d6a4e56e2e6602c02859974d30a4
> > libxl: add iommu parameter to qemu-dm.
> > When iomm = 0, virtual iommu device will be disabled.
> >
> > Signed-off-by: Wei Wang <wei.wang2@amd.com>
> >
> > diff -r 93658ca85035 -r 24f4a0a23da7 tools/libxl/libxl_dm.c
> > --- a/tools/libxl/libxl_dm.c	Wed Dec 14 16:22:23 2011 +0100
> > +++ b/tools/libxl/libxl_dm.c	Wed Dec 14 16:22:24 2011 +0100
> > @@ -194,6 +194,9 @@ static char ** libxl__build_device_model
> >          if (info->gfx_passthru) {
> >              flexarray_append(dm_args, "-gfx_passthru");
> >          }
> > +        if (info->iommu) {
> > +            flexarray_append(dm_args, "-iommu");
> > +        }
> >      }
> >      if (info->saved_state) {
> >          flexarray_vappend(dm_args, "-loadvm", info->saved_state, NULL);
> > @@ -404,6 +407,9 @@ static char ** libxl__build_device_model
> >          if (info->gfx_passthru) {
> >              flexarray_append(dm_args, "-gfx_passthru");
> >          }
> > +        if (info->iommu) {
> > +            flexarray_append(dm_args, "-iommu");
> > +        }
> >      }
> >      if (info->saved_state) {
> >          /* This file descriptor is meant to be used by QEMU */
> > diff -r 93658ca85035 -r 24f4a0a23da7 tools/libxl/libxl_types.idl
> > --- a/tools/libxl/libxl_types.idl	Wed Dec 14 16:22:23 2011 +0100
> > +++ b/tools/libxl/libxl_types.idl	Wed Dec 14 16:22:24 2011 +0100
> > @@ -254,6 +254,7 @@ The password never expires"""),
> >      ("extra",            libxl_string_list, False, "extra parameters
> > pass directly to qemu, NULL terminated"), ("extra_pv",        
> > libxl_string_list, False, "extra parameters pass directly to qemu for PV
> > guest, NULL terminated"), ("extra_hvm",        libxl_string_list, False,
> > "extra parameters pass directly to qemu for HVM guest, NULL terminated"),
> > +    ("iommu",            bool,              False, "guest iommu enabled
> > or disabled"), ],
> >      comment=
> >  """Device Model information.
> > diff -r 93658ca85035 -r 24f4a0a23da7 tools/libxl/xl_cmdimpl.c
> > --- a/tools/libxl/xl_cmdimpl.c	Wed Dec 14 16:22:23 2011 +0100
> > +++ b/tools/libxl/xl_cmdimpl.c	Wed Dec 14 16:22:24 2011 +0100
> > @@ -386,6 +386,7 @@ static void printf_info(int domid,
> >          printf("\t\t\t(spicedisable_ticketing %d)\n",
> >                      dm_info->spicedisable_ticketing);
> >          printf("\t\t\t(spiceagent_mouse %d)\n",
> > dm_info->spiceagent_mouse); +        printf("\t\t\t(iommu %d)\n",
> > dm_info->iommu);
> >          printf("\t\t)\n");
> >          break;
> >      case LIBXL_DOMAIN_TYPE_PV:
> > @@ -1217,6 +1218,8 @@ skip_vfb:
> >          xlu_cfg_replace_string (config, "soundhw", &dm_info->soundhw,
> > 0); if (!xlu_cfg_get_long (config, "xen_platform_pci", &l, 0))
> > dm_info->xen_platform_pci = l;
> > +        if (!xlu_cfg_get_long (config, "iommu", &l, 0))
> > +            dm_info->iommu = l;
>
> Didn't you already parse this same key into the build_info? Is there
> ever a possibility of the dm_info and build_info versions of this field
> differing?

> Assuming not I think this setting ought to only live in one place and I
> think build_info should be that place rather than the dm info. That
> might need some refactoring in libxl to pass the right struct down.

Yes, I added a new flag in build_info, which will control hvmloader to build 
IVRS table. And I also need a flag for qemu-dm to decide if virtual iommu 
device should be registered or not.  I just saw other parameters like 
gfx-passthu are attached to dm_info, so I do the same thing for iommu. 
Also I cannot make a reference of libxl_domain_build_info in 
libxl__build_device_model_args.

> Also you have only CC'd the hypervisor maintainers on this (and the
> other?) tool stack patch. Please check MAINTAINERS to see who ought to
> be CC'd.
Thanks, I cc'd them to Ian Jackson.

> Ian.

Wei


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 14:52:00 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 14:52:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbCep-0002gW-Mz; Thu, 15 Dec 2011 14:51:39 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Wang2@amd.com>) id 1RbCen-0002gJ-Qw
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 14:51:38 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1323960689!5655613!1
X-Originating-IP: [65.55.88.14]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8806 invoked from network); 15 Dec 2011 14:51:31 -0000
Received: from tx2ehsobe004.messaging.microsoft.com (HELO
	TX2EHSOBE009.bigfish.com) (65.55.88.14)
	by server-12.tower-174.messagelabs.com with AES128-SHA encrypted SMTP;
	15 Dec 2011 14:51:31 -0000
Received: from mail45-tx2-R.bigfish.com (10.9.14.243) by
	TX2EHSOBE009.bigfish.com (10.9.40.29) with Microsoft SMTP Server id
	14.1.225.23; Thu, 15 Dec 2011 14:51:30 +0000
Received: from mail45-tx2 (localhost [127.0.0.1])	by mail45-tx2-R.bigfish.com
	(Postfix) with ESMTP id 0B0C71403DD;
	Thu, 15 Dec 2011 14:51:35 +0000 (UTC)
X-SpamScore: -16
X-BigFish: VPS-16(zz936eK1432N98dK4015Lzz1202hzz8275bhz2dh668h839h93fh61h)
X-Spam-TCS-SCL: 0:0
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
X-FB-SS: 0,
Received: from mail45-tx2 (localhost.localdomain [127.0.0.1]) by mail45-tx2
	(MessageSwitch) id 1323960648712598_20099;
	Thu, 15 Dec 2011 14:50:48 +0000 (UTC)
Received: from TX2EHSMHS017.bigfish.com (unknown [10.9.14.239])	by
	mail45-tx2.bigfish.com (Postfix) with ESMTP id 15C4822004E;
	Thu, 15 Dec 2011 14:50:48 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	TX2EHSMHS017.bigfish.com (10.9.99.117) with Microsoft SMTP Server id
	14.1.225.23; Thu, 15 Dec 2011 14:50:33 +0000
X-WSS-ID: 0LW92K5-01-0SC-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 224B81028053;	Thu, 15 Dec 2011 08:50:28 -0600 (CST)
Received: from SAUSEXDAG04.amd.com (163.181.55.4) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Thu, 15 Dec 2011 08:50:44 -0600
Received: from storexhtp01.amd.com (172.24.4.3) by sausexdag04.amd.com
	(163.181.55.4) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Thu, 15 Dec 2011 08:50:29 -0600
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp01.amd.com
	(172.24.4.3) with Microsoft SMTP Server id 8.3.213.0; Thu, 15 Dec 2011
	09:49:27 -0500
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id C0DB549C34C; Thu, 15 Dec 2011
	14:49:25 +0000 (GMT)
Received: from gran.osrc.amd.com (gran.osrc.amd.com [165.204.15.57])	by
	mail.osrc.amd.com (Postfix) with ESMTP id A7F895940FF; Thu, 15 Dec 2011
	15:49:25 +0100 (CET)
From: Wei Wang2 <wei.wang2@amd.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Thu, 15 Dec 2011 15:52:08 +0100
User-Agent: KMail/1.9.6 (enterprise 20070904.708012)
References: <patchbomb.1323876561@gran.amd.com>
	<24f4a0a23da71c58f457.1323876577@gran.amd.com>
	<1323959445.20077.490.camel@zakaz.uk.xensource.com>
In-Reply-To: <1323959445.20077.490.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
Message-ID: <201112151552.09037.wei.wang2@amd.com>
X-OriginatorOrg: amd.com
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, "JBeulich@suse.com" <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 16 of 16] libxl: add iommu parameter to
	qemu-dm
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thursday 15 December 2011 15:30:44 Ian Campbell wrote:
> On Wed, 2011-12-14 at 15:29 +0000, Wei Wang wrote:
> > # HG changeset patch
> > # User Wei Wang <wei.wang2@amd.com>
> > # Date 1323876144 -3600
> > # Node ID 24f4a0a23da71c58f457f0bf98aa8238dd45332d
> > # Parent  93658ca85035d6a4e56e2e6602c02859974d30a4
> > libxl: add iommu parameter to qemu-dm.
> > When iomm = 0, virtual iommu device will be disabled.
> >
> > Signed-off-by: Wei Wang <wei.wang2@amd.com>
> >
> > diff -r 93658ca85035 -r 24f4a0a23da7 tools/libxl/libxl_dm.c
> > --- a/tools/libxl/libxl_dm.c	Wed Dec 14 16:22:23 2011 +0100
> > +++ b/tools/libxl/libxl_dm.c	Wed Dec 14 16:22:24 2011 +0100
> > @@ -194,6 +194,9 @@ static char ** libxl__build_device_model
> >          if (info->gfx_passthru) {
> >              flexarray_append(dm_args, "-gfx_passthru");
> >          }
> > +        if (info->iommu) {
> > +            flexarray_append(dm_args, "-iommu");
> > +        }
> >      }
> >      if (info->saved_state) {
> >          flexarray_vappend(dm_args, "-loadvm", info->saved_state, NULL);
> > @@ -404,6 +407,9 @@ static char ** libxl__build_device_model
> >          if (info->gfx_passthru) {
> >              flexarray_append(dm_args, "-gfx_passthru");
> >          }
> > +        if (info->iommu) {
> > +            flexarray_append(dm_args, "-iommu");
> > +        }
> >      }
> >      if (info->saved_state) {
> >          /* This file descriptor is meant to be used by QEMU */
> > diff -r 93658ca85035 -r 24f4a0a23da7 tools/libxl/libxl_types.idl
> > --- a/tools/libxl/libxl_types.idl	Wed Dec 14 16:22:23 2011 +0100
> > +++ b/tools/libxl/libxl_types.idl	Wed Dec 14 16:22:24 2011 +0100
> > @@ -254,6 +254,7 @@ The password never expires"""),
> >      ("extra",            libxl_string_list, False, "extra parameters
> > pass directly to qemu, NULL terminated"), ("extra_pv",        
> > libxl_string_list, False, "extra parameters pass directly to qemu for PV
> > guest, NULL terminated"), ("extra_hvm",        libxl_string_list, False,
> > "extra parameters pass directly to qemu for HVM guest, NULL terminated"),
> > +    ("iommu",            bool,              False, "guest iommu enabled
> > or disabled"), ],
> >      comment=
> >  """Device Model information.
> > diff -r 93658ca85035 -r 24f4a0a23da7 tools/libxl/xl_cmdimpl.c
> > --- a/tools/libxl/xl_cmdimpl.c	Wed Dec 14 16:22:23 2011 +0100
> > +++ b/tools/libxl/xl_cmdimpl.c	Wed Dec 14 16:22:24 2011 +0100
> > @@ -386,6 +386,7 @@ static void printf_info(int domid,
> >          printf("\t\t\t(spicedisable_ticketing %d)\n",
> >                      dm_info->spicedisable_ticketing);
> >          printf("\t\t\t(spiceagent_mouse %d)\n",
> > dm_info->spiceagent_mouse); +        printf("\t\t\t(iommu %d)\n",
> > dm_info->iommu);
> >          printf("\t\t)\n");
> >          break;
> >      case LIBXL_DOMAIN_TYPE_PV:
> > @@ -1217,6 +1218,8 @@ skip_vfb:
> >          xlu_cfg_replace_string (config, "soundhw", &dm_info->soundhw,
> > 0); if (!xlu_cfg_get_long (config, "xen_platform_pci", &l, 0))
> > dm_info->xen_platform_pci = l;
> > +        if (!xlu_cfg_get_long (config, "iommu", &l, 0))
> > +            dm_info->iommu = l;
>
> Didn't you already parse this same key into the build_info? Is there
> ever a possibility of the dm_info and build_info versions of this field
> differing?

> Assuming not I think this setting ought to only live in one place and I
> think build_info should be that place rather than the dm info. That
> might need some refactoring in libxl to pass the right struct down.

Yes, I added a new flag in build_info, which will control hvmloader to build 
IVRS table. And I also need a flag for qemu-dm to decide if virtual iommu 
device should be registered or not.  I just saw other parameters like 
gfx-passthu are attached to dm_info, so I do the same thing for iommu. 
Also I cannot make a reference of libxl_domain_build_info in 
libxl__build_device_model_args.

> Also you have only CC'd the hypervisor maintainers on this (and the
> other?) tool stack patch. Please check MAINTAINERS to see who ought to
> be CC'd.
Thanks, I cc'd them to Ian Jackson.

> Ian.

Wei


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 14:53:25 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 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.xensource.com>)
	id 1RbCgH-0002k9-7Q; Thu, 15 Dec 2011 14:53:09 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <carsten@schiers.de>) id 1RbCgF-0002jz-SM
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 14:53:08 +0000
X-Env-Sender: carsten@schiers.de
X-Msg-Ref: server-13.tower-216.messagelabs.com!1323960781!7010042!1
X-Originating-IP: [194.117.254.36]
X-SpamReason: No, hits=0.3 required=7.0 tests=FROM_EXCESS_QP,HTML_60_70,
	HTML_MESSAGE
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15196 invoked from network); 15 Dec 2011 14:53:01 -0000
Received: from www.zeus06.de (HELO mail.zeus06.de) (194.117.254.36)
	by server-13.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 15 Dec 2011 14:53:01 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=mail.zeus06.de; h=subject
	:from:to:cc:date:mime-version:content-type:in-reply-to
	:references:message-id; s=beta; bh=3jjuyvIUR6EaW4fpNQG0DPqJ0zkmD
	ikopUlDN6lMROU=; b=PPW2PbGqeaXb+dj4RHYXmnApGBkW22DRpeMRr6zEZLr7Y
	3pO2gU+VQPCC59tSVmheNfn528aDKG+3EX0PdtHyOrwxMbtNI9i5G0gB5tmXoo6X
	qKL4GREelCQr2kTSpjWW5CEL5t6xWrsTIjIjYZkZhS4/GvfJtZMJNuU0GDvna0=
Received: (qmail 26697 invoked from network); 15 Dec 2011 15:53:00 +0100
Received: from unknown (HELO uhura.zz) (l3s6271p1@84.46.65.140)
	by mail.zeus06.de with ESMTPA; 15 Dec 2011 15:53:00 +0100
Received: from localhost (localhost [127.0.0.1])
	by uhura.zz (Postfix) with ESMTP id 1B6102C527;
	Thu, 15 Dec 2011 15:53:00 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at schiers.de
Received: from uhura.zz ([127.0.0.1])
	by localhost (uhura.space.zz [127.0.0.1]) (amavisd-new, port 10024)
	with LMTP id OwJc7ohfXG2V; Thu, 15 Dec 2011 15:52:57 +0100 (CET)
Received: from uhura.space.zz (localhost [127.0.0.1])
	by uhura.zz (Postfix) with ESMTP id BC0902C526;
	Thu, 15 Dec 2011 15:52:57 +0100 (CET)
From: =?utf-8?Q?Carsten_Schiers?= <carsten@schiers.de>
To: =?utf-8?Q?Konrad_Rzeszutek_Wilk?= <konrad@darnok.org>, 
	=?utf-8?Q?Konrad_Rzeszutek_Wilk?= <konrad.wilk@oracle.com>
Date: Thu, 15 Dec 2011 15:52:57 +0100
Mime-Version: 1.0
In-Reply-To: <20111214220700.GA9926@phenom.dumpdata.com>
References: <20111214220700.GA9926@phenom.dumpdata.com>
X-Priority: 3 (Normal)
X-Mailer: Zarafa 7.0.2-29470
Message-Id: <zarafa.4eea09c9.1595.52c7693c14a2b903@uhura.space.zz>
Cc: =?utf-8?Q?linux=40eikelenboom=2Eit?= <linux@eikelenboom.it>,
	=?utf-8?Q?xen-devel?= <xen-devel@lists.xensource.com>,
	=?utf-8?Q?lersek=40redhat=2Ecom?= <lersek@redhat.com>,
	=?utf-8?Q?zhenzhong=2Eduan=40oracle=2Ecom?= <zhenzhong.duan@oracle.com>,
	=?utf-8?Q?Ian_Campbell?= <ian.campbell@citrix.com>
Subject: Re: [Xen-devel] Load increase after memory upgrade (part2)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============7247085704404214916=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a multi-part message in MIME format. Your mail reader does not
understand MIME message format.
--===============7247085704404214916==
Content-Type: multipart/alternative; 
 boundary="=_9DwWwI6ax7gA7HB4hXr1oJEcEVzmpTNJg692Nj8zUE-q9awT"

This is a multi-part message in MIME format. Your mail reader does not
understand MIME message format.
--=_9DwWwI6ax7gA7HB4hXr1oJEcEVzmpTNJg692Nj8zUE-q9awT
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

=2E..=0D=0A=0D=0A> which will require some fiddling around.=0D=0A=0D=0AHe=
re is the patch I used against classic XenLinux. Any chance you could run=
=0D=0Ait with your classis guests and see what numbers you get=3F=0D=0A=0D=
=0ASure, it might take a bit, but I'll try it with my 2.6.34 classic kern=
el.=0D=0A=0D=0A=C2=A0=0D=0ACarsten.=0D=0A=0D=0A
--=_9DwWwI6ax7gA7HB4hXr1oJEcEVzmpTNJg692Nj8zUE-q9awT
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://ww=
w.w3.org/TR/html4/loose.dtd"><html>=0A<head>=0A  <meta name=3D"Generator"=
 content=3D"Zarafa WebAccess v7.0.2-29470">=0A  <meta http-equiv=3D"Conte=
nt-Type" content=3D"text/html; charset=3Dutf-8">=0A  <title>AW: [Xen-deve=
l] Load increase after memory upgrade (part2)</title>=0A  <style type=3D"=
text/css">=0A      body=0D=0A      {=0D=0A        font-family: Arial, Ver=
dana, Sans-Serif ! important;=0D=0A        font-size: 12px;=0D=0A        =
padding: 5px 5px 5px 5px;=0D=0A        margin: 0px;=0D=0A        border-s=
tyle: none;=0D=0A        background-color: #ffffff;=0D=0A      }=0D=0A=0D=
=0A      p, ul, li=0D=0A      {=0D=0A        margin-top: 0px;=0D=0A      =
  margin-bottom: 0px;=0D=0A      }=0D=0A  </style>=0A</head>=0A<body>=0A<=
p>...</p><p>&gt; which will require some fiddling around.</p><blockquote =
style=3D"border-left: 2px solid #325FBA; padding-left: 5px;margin-left:5p=
x;">Here is the patch I used against classic XenLinux. Any chance you cou=
ld run<br />it with your classis guests and see what numbers you get=3F</=
blockquote><p>Sure, it might take a bit, but I&#39;ll try it with my 2.6.=
34 classic kernel.</p><p>&nbsp;</p><p>Carsten.</p>=0A</body>=0A</html>
--=_9DwWwI6ax7gA7HB4hXr1oJEcEVzmpTNJg692Nj8zUE-q9awT--



--===============7247085704404214916==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============7247085704404214916==--



From xen-devel-bounces@lists.xensource.com Thu Dec 15 14:53:25 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 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.xensource.com>)
	id 1RbCgH-0002k9-7Q; Thu, 15 Dec 2011 14:53:09 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <carsten@schiers.de>) id 1RbCgF-0002jz-SM
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 14:53:08 +0000
X-Env-Sender: carsten@schiers.de
X-Msg-Ref: server-13.tower-216.messagelabs.com!1323960781!7010042!1
X-Originating-IP: [194.117.254.36]
X-SpamReason: No, hits=0.3 required=7.0 tests=FROM_EXCESS_QP,HTML_60_70,
	HTML_MESSAGE
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15196 invoked from network); 15 Dec 2011 14:53:01 -0000
Received: from www.zeus06.de (HELO mail.zeus06.de) (194.117.254.36)
	by server-13.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 15 Dec 2011 14:53:01 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=mail.zeus06.de; h=subject
	:from:to:cc:date:mime-version:content-type:in-reply-to
	:references:message-id; s=beta; bh=3jjuyvIUR6EaW4fpNQG0DPqJ0zkmD
	ikopUlDN6lMROU=; b=PPW2PbGqeaXb+dj4RHYXmnApGBkW22DRpeMRr6zEZLr7Y
	3pO2gU+VQPCC59tSVmheNfn528aDKG+3EX0PdtHyOrwxMbtNI9i5G0gB5tmXoo6X
	qKL4GREelCQr2kTSpjWW5CEL5t6xWrsTIjIjYZkZhS4/GvfJtZMJNuU0GDvna0=
Received: (qmail 26697 invoked from network); 15 Dec 2011 15:53:00 +0100
Received: from unknown (HELO uhura.zz) (l3s6271p1@84.46.65.140)
	by mail.zeus06.de with ESMTPA; 15 Dec 2011 15:53:00 +0100
Received: from localhost (localhost [127.0.0.1])
	by uhura.zz (Postfix) with ESMTP id 1B6102C527;
	Thu, 15 Dec 2011 15:53:00 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at schiers.de
Received: from uhura.zz ([127.0.0.1])
	by localhost (uhura.space.zz [127.0.0.1]) (amavisd-new, port 10024)
	with LMTP id OwJc7ohfXG2V; Thu, 15 Dec 2011 15:52:57 +0100 (CET)
Received: from uhura.space.zz (localhost [127.0.0.1])
	by uhura.zz (Postfix) with ESMTP id BC0902C526;
	Thu, 15 Dec 2011 15:52:57 +0100 (CET)
From: =?utf-8?Q?Carsten_Schiers?= <carsten@schiers.de>
To: =?utf-8?Q?Konrad_Rzeszutek_Wilk?= <konrad@darnok.org>, 
	=?utf-8?Q?Konrad_Rzeszutek_Wilk?= <konrad.wilk@oracle.com>
Date: Thu, 15 Dec 2011 15:52:57 +0100
Mime-Version: 1.0
In-Reply-To: <20111214220700.GA9926@phenom.dumpdata.com>
References: <20111214220700.GA9926@phenom.dumpdata.com>
X-Priority: 3 (Normal)
X-Mailer: Zarafa 7.0.2-29470
Message-Id: <zarafa.4eea09c9.1595.52c7693c14a2b903@uhura.space.zz>
Cc: =?utf-8?Q?linux=40eikelenboom=2Eit?= <linux@eikelenboom.it>,
	=?utf-8?Q?xen-devel?= <xen-devel@lists.xensource.com>,
	=?utf-8?Q?lersek=40redhat=2Ecom?= <lersek@redhat.com>,
	=?utf-8?Q?zhenzhong=2Eduan=40oracle=2Ecom?= <zhenzhong.duan@oracle.com>,
	=?utf-8?Q?Ian_Campbell?= <ian.campbell@citrix.com>
Subject: Re: [Xen-devel] Load increase after memory upgrade (part2)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============7247085704404214916=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a multi-part message in MIME format. Your mail reader does not
understand MIME message format.
--===============7247085704404214916==
Content-Type: multipart/alternative; 
 boundary="=_9DwWwI6ax7gA7HB4hXr1oJEcEVzmpTNJg692Nj8zUE-q9awT"

This is a multi-part message in MIME format. Your mail reader does not
understand MIME message format.
--=_9DwWwI6ax7gA7HB4hXr1oJEcEVzmpTNJg692Nj8zUE-q9awT
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

=2E..=0D=0A=0D=0A> which will require some fiddling around.=0D=0A=0D=0AHe=
re is the patch I used against classic XenLinux. Any chance you could run=
=0D=0Ait with your classis guests and see what numbers you get=3F=0D=0A=0D=
=0ASure, it might take a bit, but I'll try it with my 2.6.34 classic kern=
el.=0D=0A=0D=0A=C2=A0=0D=0ACarsten.=0D=0A=0D=0A
--=_9DwWwI6ax7gA7HB4hXr1oJEcEVzmpTNJg692Nj8zUE-q9awT
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://ww=
w.w3.org/TR/html4/loose.dtd"><html>=0A<head>=0A  <meta name=3D"Generator"=
 content=3D"Zarafa WebAccess v7.0.2-29470">=0A  <meta http-equiv=3D"Conte=
nt-Type" content=3D"text/html; charset=3Dutf-8">=0A  <title>AW: [Xen-deve=
l] Load increase after memory upgrade (part2)</title>=0A  <style type=3D"=
text/css">=0A      body=0D=0A      {=0D=0A        font-family: Arial, Ver=
dana, Sans-Serif ! important;=0D=0A        font-size: 12px;=0D=0A        =
padding: 5px 5px 5px 5px;=0D=0A        margin: 0px;=0D=0A        border-s=
tyle: none;=0D=0A        background-color: #ffffff;=0D=0A      }=0D=0A=0D=
=0A      p, ul, li=0D=0A      {=0D=0A        margin-top: 0px;=0D=0A      =
  margin-bottom: 0px;=0D=0A      }=0D=0A  </style>=0A</head>=0A<body>=0A<=
p>...</p><p>&gt; which will require some fiddling around.</p><blockquote =
style=3D"border-left: 2px solid #325FBA; padding-left: 5px;margin-left:5p=
x;">Here is the patch I used against classic XenLinux. Any chance you cou=
ld run<br />it with your classis guests and see what numbers you get=3F</=
blockquote><p>Sure, it might take a bit, but I&#39;ll try it with my 2.6.=
34 classic kernel.</p><p>&nbsp;</p><p>Carsten.</p>=0A</body>=0A</html>
--=_9DwWwI6ax7gA7HB4hXr1oJEcEVzmpTNJg692Nj8zUE-q9awT--



--===============7247085704404214916==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============7247085704404214916==--



From xen-devel-bounces@lists.xensource.com Thu Dec 15 14:56:27 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 14:56:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbCjD-0002uf-RQ; Thu, 15 Dec 2011 14:56:11 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RbCjC-0002uG-NU
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 14:56:11 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-15.tower-216.messagelabs.com!1323960963!7587908!1
X-Originating-IP: [208.97.132.145]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNDUgPT4gMTczMTA=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26649 invoked from network); 15 Dec 2011 14:56:04 -0000
Received: from caiajhbdcbef.dreamhost.com (HELO homiemail-a15.g.dreamhost.com)
	(208.97.132.145) by server-15.tower-216.messagelabs.com with SMTP;
	15 Dec 2011 14:56:04 -0000
Received: from homiemail-a15.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a15.g.dreamhost.com (Postfix) with ESMTP id 1932A76C073;
	Thu, 15 Dec 2011 06:56:03 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=dkrGNhqu0FgxqJqwCWanUTsmW1mmOe37kNbOnP7AIR9q
	b6jbDidRCZSipvgOO8mM0PCFCGtDk45yHUTmkAH9VW9W3VQjDm58on7jK207qjNP
	bZDD1hGxexxBgKqCHJRBhASB+mu5cIJ/1WJ3fUOqRt9gNWi6+jZihi0Ffrfq96k=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=CS8w1kD7R6FPnk1M+OYsqi40Ptg=; b=EAvnD5B2
	ZVtO44bW9CNyTXNItlriICyEAjloNRlT8fDKltzMZwVSko4gnT/b8KQ4cBD9UMWt
	EedWzI2lMWy+grsCTYogOPIb0DSLjFpZgG05P0Z+6Bg9EvQEOcjJwtuxpYBeanfY
	UPhgqkFX8PXlMCwBaYkrp/Nbf1iZqs962yU=
Received: from webmail.lagarcavilla.org (ahfbbjcaiaae.dreamhost.com
	[75.119.208.4]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a15.g.dreamhost.com (Postfix) with ESMTPA id BDE6C76C079; 
	Thu, 15 Dec 2011 06:56:02 -0800 (PST)
Received: from 190.18.220.100 (proxying for 190.18.220.100)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Thu, 15 Dec 2011 06:56:03 -0800
Message-ID: <3d5947b7ee3b2fdda393744f59d55b76.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <mailman.4227.1323785898.12970.xen-devel@lists.xensource.com>
References: <mailman.4227.1323785898.12970.xen-devel@lists.xensource.com>
Date: Thu, 15 Dec 2011 06:56:03 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: olaf@aepfle.de, tim@xen.org
Subject: Re: [Xen-devel] [PATCH] mem_event: use wait queue when ring is full
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> Date: Tue, 13 Dec 2011 14:40:16 +0100
> From: Olaf Hering <olaf@aepfle.de>
> To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
> Cc: xen-devel@lists.xensource.com, tim@xen.org
> Subject: Re: [Xen-devel] [PATCH] mem_event: use wait queue when ring
> 	is full
> Message-ID: <20111213134016.GA20700@aepfle.de>
> Content-Type: text/plain; charset=utf-8
>
> On Fri, Dec 09, Andres Lagar-Cavilla wrote:
>
>> Olaf,
>> Tim pointed out we need both solutions to ring management in the
>> hypervisor. With our patch ("Improve ring management for memory events.
>> Do
>> not lose guest events."), we can handle the common case quickly, without
>> preempting VMs. With your patch, we can handle extreme situations of
>> ring
>> congestion with the big hammer called wait queue.
>
> With my patch the requests get processed as they come in, both foreign
> and target requests get handled equally. There is no special accounting.
>
> A few questions about your requirements:
> - Is the goal is that each guest vcpu can always put at least one request?
Yes

> - How many requests should foreign vcpus place in the ring if the guest
>   has more vcpus than available slots in the ring? Just a single one so
>   that foreigners can also make some progress?
The idea is that foreign vcpus can place as many events as they want as
long as each guest vcpu that is not blocked on a men event has room to
send one men event. When we reach that border condition, no more foreign
men events.

The case for which there are way too many guest vcpus needs to be handled,
either by capping the max number of vcpus for domains using a men event,
or by growing the ring size.

> - Should access and paging have the same rules for accounting?
Absolutely.

And both should use wait queues in extreme cases in which a guest vcpu
with a single action generates multiple memory events. Given that when we
hit a border condition the guest vcpu will place one event and be flagged
VPF_mem_event_paused (or whatever that flag is named), if a guest vcpu
generates another event when flagged, that's our queue for putting the
vcpu on a wait queue.

Thanks
Andres
>
> Olaf
>
>
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 14:56:27 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 14:56:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbCjD-0002uf-RQ; Thu, 15 Dec 2011 14:56:11 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RbCjC-0002uG-NU
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 14:56:11 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-15.tower-216.messagelabs.com!1323960963!7587908!1
X-Originating-IP: [208.97.132.145]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNDUgPT4gMTczMTA=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26649 invoked from network); 15 Dec 2011 14:56:04 -0000
Received: from caiajhbdcbef.dreamhost.com (HELO homiemail-a15.g.dreamhost.com)
	(208.97.132.145) by server-15.tower-216.messagelabs.com with SMTP;
	15 Dec 2011 14:56:04 -0000
Received: from homiemail-a15.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a15.g.dreamhost.com (Postfix) with ESMTP id 1932A76C073;
	Thu, 15 Dec 2011 06:56:03 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=dkrGNhqu0FgxqJqwCWanUTsmW1mmOe37kNbOnP7AIR9q
	b6jbDidRCZSipvgOO8mM0PCFCGtDk45yHUTmkAH9VW9W3VQjDm58on7jK207qjNP
	bZDD1hGxexxBgKqCHJRBhASB+mu5cIJ/1WJ3fUOqRt9gNWi6+jZihi0Ffrfq96k=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=CS8w1kD7R6FPnk1M+OYsqi40Ptg=; b=EAvnD5B2
	ZVtO44bW9CNyTXNItlriICyEAjloNRlT8fDKltzMZwVSko4gnT/b8KQ4cBD9UMWt
	EedWzI2lMWy+grsCTYogOPIb0DSLjFpZgG05P0Z+6Bg9EvQEOcjJwtuxpYBeanfY
	UPhgqkFX8PXlMCwBaYkrp/Nbf1iZqs962yU=
Received: from webmail.lagarcavilla.org (ahfbbjcaiaae.dreamhost.com
	[75.119.208.4]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a15.g.dreamhost.com (Postfix) with ESMTPA id BDE6C76C079; 
	Thu, 15 Dec 2011 06:56:02 -0800 (PST)
Received: from 190.18.220.100 (proxying for 190.18.220.100)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Thu, 15 Dec 2011 06:56:03 -0800
Message-ID: <3d5947b7ee3b2fdda393744f59d55b76.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <mailman.4227.1323785898.12970.xen-devel@lists.xensource.com>
References: <mailman.4227.1323785898.12970.xen-devel@lists.xensource.com>
Date: Thu, 15 Dec 2011 06:56:03 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: olaf@aepfle.de, tim@xen.org
Subject: Re: [Xen-devel] [PATCH] mem_event: use wait queue when ring is full
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> Date: Tue, 13 Dec 2011 14:40:16 +0100
> From: Olaf Hering <olaf@aepfle.de>
> To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
> Cc: xen-devel@lists.xensource.com, tim@xen.org
> Subject: Re: [Xen-devel] [PATCH] mem_event: use wait queue when ring
> 	is full
> Message-ID: <20111213134016.GA20700@aepfle.de>
> Content-Type: text/plain; charset=utf-8
>
> On Fri, Dec 09, Andres Lagar-Cavilla wrote:
>
>> Olaf,
>> Tim pointed out we need both solutions to ring management in the
>> hypervisor. With our patch ("Improve ring management for memory events.
>> Do
>> not lose guest events."), we can handle the common case quickly, without
>> preempting VMs. With your patch, we can handle extreme situations of
>> ring
>> congestion with the big hammer called wait queue.
>
> With my patch the requests get processed as they come in, both foreign
> and target requests get handled equally. There is no special accounting.
>
> A few questions about your requirements:
> - Is the goal is that each guest vcpu can always put at least one request?
Yes

> - How many requests should foreign vcpus place in the ring if the guest
>   has more vcpus than available slots in the ring? Just a single one so
>   that foreigners can also make some progress?
The idea is that foreign vcpus can place as many events as they want as
long as each guest vcpu that is not blocked on a men event has room to
send one men event. When we reach that border condition, no more foreign
men events.

The case for which there are way too many guest vcpus needs to be handled,
either by capping the max number of vcpus for domains using a men event,
or by growing the ring size.

> - Should access and paging have the same rules for accounting?
Absolutely.

And both should use wait queues in extreme cases in which a guest vcpu
with a single action generates multiple memory events. Given that when we
hit a border condition the guest vcpu will place one event and be flagged
VPF_mem_event_paused (or whatever that flag is named), if a guest vcpu
generates another event when flagged, that's our queue for putting the
vcpu on a wait queue.

Thanks
Andres
>
> Olaf
>
>
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 15:13:26 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 15:13:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbCzY-0003Pg-Mq; Thu, 15 Dec 2011 15:13:04 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony@codemonkey.ws>) id 1RbCzW-0003PZ-Pm
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 15:13:02 +0000
X-Env-Sender: anthony@codemonkey.ws
X-Msg-Ref: server-15.tower-216.messagelabs.com!1323961975!7590973!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29305 invoked from network); 15 Dec 2011 15:12:56 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 15:12:56 -0000
Received: by iagw33 with SMTP id w33so5197244iag.30
	for <xen-devel@lists.xensource.com>;
	Thu, 15 Dec 2011 07:12:55 -0800 (PST)
Received: by 10.43.47.135 with SMTP id us7mr2678586icb.31.1323961975088;
	Thu, 15 Dec 2011 07:12:55 -0800 (PST)
Received: from [192.168.0.103] (cpe-70-123-132-139.austin.res.rr.com.
	[70.123.132.139])
	by mx.google.com with ESMTPS id r18sm22078099ibh.4.2011.12.15.07.12.52
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 15 Dec 2011 07:12:53 -0800 (PST)
Message-ID: <4EEA0E72.20105@codemonkey.ws>
Date: Thu, 15 Dec 2011 09:12:50 -0600
From: Anthony Liguori <anthony@codemonkey.ws>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.21) Gecko/20110831 Lightning/1.0b2 Thunderbird/3.1.13
MIME-Version: 1.0
To: Anthony PERARD <anthony.perard@citrix.com>
References: <1323467645-24271-1-git-send-email-anthony.perard@citrix.com>
	<1323467645-24271-2-git-send-email-anthony.perard@citrix.com>
In-Reply-To: <1323467645-24271-2-git-send-email-anthony.perard@citrix.com>
Cc: Xen Devel <xen-devel@lists.xensource.com>,
	QEMU-devel <qemu-devel@nongnu.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH V2 1/5] vl.c: Do not save RAM
 state when Xen is used.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 12/09/2011 03:54 PM, Anthony PERARD wrote:
> In Xen case, the guest RAM is not handle by QEMU, and it is saved by Xen tools.
> So, we just avoid to register the RAM save state handler.
>
> Signed-off-by: Anthony PERARD<anthony.perard@citrix.com>
> ---
>   vl.c |    6 ++++--
>   1 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/vl.c b/vl.c
> index f5afed4..e7dced2 100644
> --- a/vl.c
> +++ b/vl.c
> @@ -3273,8 +3273,10 @@ int main(int argc, char **argv, char **envp)
>       default_drive(default_sdcard, snapshot, machine->use_scsi,
>                     IF_SD, 0, SD_OPTS);
>
> -    register_savevm_live(NULL, "ram", 0, 4, NULL, ram_save_live, NULL,
> -                         ram_load, NULL);
> +    if (!xen_enabled()) {
> +        register_savevm_live(NULL, "ram", 0, 4, NULL, ram_save_live, NULL,
> +                             ram_load, NULL);
> +    }

Why don't you just unregister the section in the xen initialization code?  That 
way we don't have xen_enabled()'s sprinkled all over the place.

Regards,

Anthony Liguori

>
>       if (nb_numa_nodes>  0) {
>           int i;


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 15:13:26 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 15:13:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbCzY-0003Pg-Mq; Thu, 15 Dec 2011 15:13:04 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony@codemonkey.ws>) id 1RbCzW-0003PZ-Pm
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 15:13:02 +0000
X-Env-Sender: anthony@codemonkey.ws
X-Msg-Ref: server-15.tower-216.messagelabs.com!1323961975!7590973!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29305 invoked from network); 15 Dec 2011 15:12:56 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 15:12:56 -0000
Received: by iagw33 with SMTP id w33so5197244iag.30
	for <xen-devel@lists.xensource.com>;
	Thu, 15 Dec 2011 07:12:55 -0800 (PST)
Received: by 10.43.47.135 with SMTP id us7mr2678586icb.31.1323961975088;
	Thu, 15 Dec 2011 07:12:55 -0800 (PST)
Received: from [192.168.0.103] (cpe-70-123-132-139.austin.res.rr.com.
	[70.123.132.139])
	by mx.google.com with ESMTPS id r18sm22078099ibh.4.2011.12.15.07.12.52
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 15 Dec 2011 07:12:53 -0800 (PST)
Message-ID: <4EEA0E72.20105@codemonkey.ws>
Date: Thu, 15 Dec 2011 09:12:50 -0600
From: Anthony Liguori <anthony@codemonkey.ws>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.21) Gecko/20110831 Lightning/1.0b2 Thunderbird/3.1.13
MIME-Version: 1.0
To: Anthony PERARD <anthony.perard@citrix.com>
References: <1323467645-24271-1-git-send-email-anthony.perard@citrix.com>
	<1323467645-24271-2-git-send-email-anthony.perard@citrix.com>
In-Reply-To: <1323467645-24271-2-git-send-email-anthony.perard@citrix.com>
Cc: Xen Devel <xen-devel@lists.xensource.com>,
	QEMU-devel <qemu-devel@nongnu.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH V2 1/5] vl.c: Do not save RAM
 state when Xen is used.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 12/09/2011 03:54 PM, Anthony PERARD wrote:
> In Xen case, the guest RAM is not handle by QEMU, and it is saved by Xen tools.
> So, we just avoid to register the RAM save state handler.
>
> Signed-off-by: Anthony PERARD<anthony.perard@citrix.com>
> ---
>   vl.c |    6 ++++--
>   1 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/vl.c b/vl.c
> index f5afed4..e7dced2 100644
> --- a/vl.c
> +++ b/vl.c
> @@ -3273,8 +3273,10 @@ int main(int argc, char **argv, char **envp)
>       default_drive(default_sdcard, snapshot, machine->use_scsi,
>                     IF_SD, 0, SD_OPTS);
>
> -    register_savevm_live(NULL, "ram", 0, 4, NULL, ram_save_live, NULL,
> -                         ram_load, NULL);
> +    if (!xen_enabled()) {
> +        register_savevm_live(NULL, "ram", 0, 4, NULL, ram_save_live, NULL,
> +                             ram_load, NULL);
> +    }

Why don't you just unregister the section in the xen initialization code?  That 
way we don't have xen_enabled()'s sprinkled all over the place.

Regards,

Anthony Liguori

>
>       if (nb_numa_nodes>  0) {
>           int i;


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 15:14:33 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 15: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.xensource.com>)
	id 1RbD0g-0003SC-5W; Thu, 15 Dec 2011 15:14:14 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony@codemonkey.ws>) id 1RbD0e-0003Rq-W8
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 15:14:13 +0000
X-Env-Sender: anthony@codemonkey.ws
X-Msg-Ref: server-3.tower-21.messagelabs.com!1323962045!8395240!1
X-Originating-IP: [209.85.160.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP,UPPERCASE_25_50
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15512 invoked from network); 15 Dec 2011 15:14:06 -0000
Received: from mail-gy0-f171.google.com (HELO mail-gy0-f171.google.com)
	(209.85.160.171)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 15:14:06 -0000
Received: by ghy10 with SMTP id 10so11279666ghy.30
	for <xen-devel@lists.xensource.com>;
	Thu, 15 Dec 2011 07:14:05 -0800 (PST)
Received: by 10.50.181.161 with SMTP id dx1mr3264182igc.90.1323962045075;
	Thu, 15 Dec 2011 07:14:05 -0800 (PST)
Received: from [192.168.0.103] (cpe-70-123-132-139.austin.res.rr.com.
	[70.123.132.139])
	by mx.google.com with ESMTPS id a2sm11077305igj.7.2011.12.15.07.14.02
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 15 Dec 2011 07:14:04 -0800 (PST)
Message-ID: <4EEA0EB8.4020203@codemonkey.ws>
Date: Thu, 15 Dec 2011 09:14:00 -0600
From: Anthony Liguori <anthony@codemonkey.ws>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.21) Gecko/20110831 Lightning/1.0b2 Thunderbird/3.1.13
MIME-Version: 1.0
To: Anthony PERARD <anthony.perard@citrix.com>
References: <1323467645-24271-1-git-send-email-anthony.perard@citrix.com>
	<1323467645-24271-4-git-send-email-anthony.perard@citrix.com>
In-Reply-To: <1323467645-24271-4-git-send-email-anthony.perard@citrix.com>
Cc: Luiz Capitulino <lcapitulino@redhat.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	QEMU-devel <qemu-devel@nongnu.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH V2 3/5] Introduce premigrate
	RunState.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 12/09/2011 03:54 PM, Anthony PERARD wrote:
> This new state will be used by Xen functions to know QEMU will wait for a
> migration. This is important to know for memory related function because the
> memory is already allocated and reallocated them will not works.
>
> Signed-off-by: Anthony PERARD<anthony.perard@citrix.com>

Luiz, please Ack.  In the future, when you make QMP changes, please CC the 
appropriate maintainer.

Regards,

Anthony Liguori

> ---
>   qapi-schema.json |    2 +-
>   vl.c             |    4 ++++
>   2 files changed, 5 insertions(+), 1 deletions(-)
>
> diff --git a/qapi-schema.json b/qapi-schema.json
> index cb1ba77..bd77444 100644
> --- a/qapi-schema.json
> +++ b/qapi-schema.json
> @@ -121,7 +121,7 @@
>   { 'enum': 'RunState',
>     'data': [ 'debug', 'inmigrate', 'internal-error', 'io-error', 'paused',
>               'postmigrate', 'prelaunch', 'finish-migrate', 'restore-vm',
> -            'running', 'save-vm', 'shutdown', 'watchdog' ] }
> +            'running', 'save-vm', 'shutdown', 'watchdog', 'premigrate' ] }
>
>   ##
>   # @StatusInfo:
> diff --git a/vl.c b/vl.c
> index e7dced2..a291416 100644
> --- a/vl.c
> +++ b/vl.c
> @@ -351,8 +351,11 @@ static const RunStateTransition runstate_transitions_def[] = {
>
>       { RUN_STATE_PRELAUNCH, RUN_STATE_RUNNING },
>       { RUN_STATE_PRELAUNCH, RUN_STATE_FINISH_MIGRATE },
> +    { RUN_STATE_PRELAUNCH, RUN_STATE_PREMIGRATE },
>       { RUN_STATE_PRELAUNCH, RUN_STATE_INMIGRATE },
>
> +    { RUN_STATE_PREMIGRATE, RUN_STATE_INMIGRATE },
> +
>       { RUN_STATE_FINISH_MIGRATE, RUN_STATE_RUNNING },
>       { RUN_STATE_FINISH_MIGRATE, RUN_STATE_POSTMIGRATE },
>
> @@ -2975,6 +2978,7 @@ int main(int argc, char **argv, char **envp)
>                   break;
>               case QEMU_OPTION_incoming:
>                   incoming = optarg;
> +                runstate_set(RUN_STATE_PREMIGRATE);
>                   break;
>               case QEMU_OPTION_nodefaults:
>                   default_serial = 0;


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 15:14:33 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 15: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.xensource.com>)
	id 1RbD0g-0003SC-5W; Thu, 15 Dec 2011 15:14:14 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony@codemonkey.ws>) id 1RbD0e-0003Rq-W8
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 15:14:13 +0000
X-Env-Sender: anthony@codemonkey.ws
X-Msg-Ref: server-3.tower-21.messagelabs.com!1323962045!8395240!1
X-Originating-IP: [209.85.160.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP,UPPERCASE_25_50
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15512 invoked from network); 15 Dec 2011 15:14:06 -0000
Received: from mail-gy0-f171.google.com (HELO mail-gy0-f171.google.com)
	(209.85.160.171)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 15:14:06 -0000
Received: by ghy10 with SMTP id 10so11279666ghy.30
	for <xen-devel@lists.xensource.com>;
	Thu, 15 Dec 2011 07:14:05 -0800 (PST)
Received: by 10.50.181.161 with SMTP id dx1mr3264182igc.90.1323962045075;
	Thu, 15 Dec 2011 07:14:05 -0800 (PST)
Received: from [192.168.0.103] (cpe-70-123-132-139.austin.res.rr.com.
	[70.123.132.139])
	by mx.google.com with ESMTPS id a2sm11077305igj.7.2011.12.15.07.14.02
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 15 Dec 2011 07:14:04 -0800 (PST)
Message-ID: <4EEA0EB8.4020203@codemonkey.ws>
Date: Thu, 15 Dec 2011 09:14:00 -0600
From: Anthony Liguori <anthony@codemonkey.ws>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.21) Gecko/20110831 Lightning/1.0b2 Thunderbird/3.1.13
MIME-Version: 1.0
To: Anthony PERARD <anthony.perard@citrix.com>
References: <1323467645-24271-1-git-send-email-anthony.perard@citrix.com>
	<1323467645-24271-4-git-send-email-anthony.perard@citrix.com>
In-Reply-To: <1323467645-24271-4-git-send-email-anthony.perard@citrix.com>
Cc: Luiz Capitulino <lcapitulino@redhat.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	QEMU-devel <qemu-devel@nongnu.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH V2 3/5] Introduce premigrate
	RunState.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 12/09/2011 03:54 PM, Anthony PERARD wrote:
> This new state will be used by Xen functions to know QEMU will wait for a
> migration. This is important to know for memory related function because the
> memory is already allocated and reallocated them will not works.
>
> Signed-off-by: Anthony PERARD<anthony.perard@citrix.com>

Luiz, please Ack.  In the future, when you make QMP changes, please CC the 
appropriate maintainer.

Regards,

Anthony Liguori

> ---
>   qapi-schema.json |    2 +-
>   vl.c             |    4 ++++
>   2 files changed, 5 insertions(+), 1 deletions(-)
>
> diff --git a/qapi-schema.json b/qapi-schema.json
> index cb1ba77..bd77444 100644
> --- a/qapi-schema.json
> +++ b/qapi-schema.json
> @@ -121,7 +121,7 @@
>   { 'enum': 'RunState',
>     'data': [ 'debug', 'inmigrate', 'internal-error', 'io-error', 'paused',
>               'postmigrate', 'prelaunch', 'finish-migrate', 'restore-vm',
> -            'running', 'save-vm', 'shutdown', 'watchdog' ] }
> +            'running', 'save-vm', 'shutdown', 'watchdog', 'premigrate' ] }
>
>   ##
>   # @StatusInfo:
> diff --git a/vl.c b/vl.c
> index e7dced2..a291416 100644
> --- a/vl.c
> +++ b/vl.c
> @@ -351,8 +351,11 @@ static const RunStateTransition runstate_transitions_def[] = {
>
>       { RUN_STATE_PRELAUNCH, RUN_STATE_RUNNING },
>       { RUN_STATE_PRELAUNCH, RUN_STATE_FINISH_MIGRATE },
> +    { RUN_STATE_PRELAUNCH, RUN_STATE_PREMIGRATE },
>       { RUN_STATE_PRELAUNCH, RUN_STATE_INMIGRATE },
>
> +    { RUN_STATE_PREMIGRATE, RUN_STATE_INMIGRATE },
> +
>       { RUN_STATE_FINISH_MIGRATE, RUN_STATE_RUNNING },
>       { RUN_STATE_FINISH_MIGRATE, RUN_STATE_POSTMIGRATE },
>
> @@ -2975,6 +2978,7 @@ int main(int argc, char **argv, char **envp)
>                   break;
>               case QEMU_OPTION_incoming:
>                   incoming = optarg;
> +                runstate_set(RUN_STATE_PREMIGRATE);
>                   break;
>               case QEMU_OPTION_nodefaults:
>                   default_serial = 0;


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 15:17:28 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 15:17:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbD3Y-0003en-Pa; Thu, 15 Dec 2011 15:17:12 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RbD3X-0003eJ-Id
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 15:17:11 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1323962225!7409341!1
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6454 invoked from network); 15 Dec 2011 15:17:05 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 15:17:05 -0000
Received: by wgbds11 with SMTP id ds11so3581748wgb.24
	for <xen-devel@lists.xensource.com>;
	Thu, 15 Dec 2011 07:17:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:message-id:user-agent:date:from:to;
	bh=LwFOwAGT10/ib9CUEm+OR9pcFsJ40fbaGvche3QO610=;
	b=GhanWDR6MqOQ1AguExF/VUO7ISnPrkqWg6EKpRFw/tsDIqwvvPGgA/AUohOLm29zY4
	i8RXzwtT3J7qcoBZWMv/S24KFYiOHUYhUioNb06j0JuraftiYgO2Lsn6VROWPX4grCvr
	nM/Co1MljIwzT1ZMWOOAZLPdrrGWUIu35MczY=
Received: by 10.227.59.204 with SMTP id m12mr2624007wbh.10.1323962225050;
	Thu, 15 Dec 2011 07:17:05 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id hb10sm8693212wib.16.2011.12.15.07.17.02
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 15 Dec 2011 07:17:03 -0800 (PST)
MIME-Version: 1.0
Message-Id: <patchbomb.1323961634@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Thu, 15 Dec 2011 16:07:14 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 00 of 15 v5] libxl: add support for hotplug
 script calling from libxl
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This patch series adds support for hotplug script calling directly
from libxl, instead of relying on xenbackendd. Also some patches
contain general bug fixes.

Currently Linux hotplug script call functions are empty, so Linux
continues to use udev rules to call hotplug scripts.

Patches 1, 6, 8, 9, 10 are NetBSD specific, and basicaly pave the way
for the application of the bigger changes present in this series.

Patch 11 is a trivial update for an error message.

Patch 2 adds support for mounting raw image files using the vnd
device. Since NetBSD doesn't have qdisk or blktap support, the only
way to use raw images with guests is to mount the image and pass the
block device as a "PHY" backend. To check wheter an OS supports raw
images as "PHY" backends two new files are added to the project, to
avoid using #ifdefs, that contain a helper function. The file
to be included is decided during the compilation process.

Patch 3 adds a generic function to fork the current process and
execute a given file, which will be later used to execute hotplug
scripts synchronously.

Patches 4 and 5 add a new function to wait for a device to reach a
certain state, and replace wait_for_dev_destroy with this more generic
implementation. This function is also used to wait for device
initialization before calling hotplug scripts. The added function will
benefit from a rework after event support is added to libxl.

Patch 7 adds the calling of hotplug scripts when devices are
initializated and removed. Two new files are also added to support
hotplug scripts, since Linux and NetBSD hotplug scripts have different
call parameters. The path of the script to execute is retrieved
from xenstore. The file to include is also decided at compile
time.

Patches 12, 13, 14 sets frontend status to 6 when a domain is
destroyed, so devices are disconnected and then execute hotplug
scripts. Also the syntax of the libxl_domain_destroy and
libxl__devices_destroy has been changed to always force the 
destruction.

Finally patch 15 changes the mutex initialization, because NetBSD 
doesn't have the macro PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP.

Changes since v4:

 * Guess if vbd is an image file or a block device inside hotplug 
   scripts instead of passing it as a parameter.

 * Merged patches 7 and 8 to avoid breaking bisectability.

 * Changed libxl__forkexec according Ian Jackson suggestions.

 * Changed libxl__device_destroy to not modify frontend state and 
   remove frontend instead.

 * Call libxl__device_remove in libxl__device_destroy to wait for the 
   device to be disconnected.

 * Changed the initialization of the mutex, because NetBSD doesn't 
   have the used macro.

 * Merged nic and disk hotplug scripts caller functions, since they 
   take the same parameters now.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 15:17:28 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 15:17:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbD3Y-0003en-Pa; Thu, 15 Dec 2011 15:17:12 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RbD3X-0003eJ-Id
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 15:17:11 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1323962225!7409341!1
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6454 invoked from network); 15 Dec 2011 15:17:05 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 15:17:05 -0000
Received: by wgbds11 with SMTP id ds11so3581748wgb.24
	for <xen-devel@lists.xensource.com>;
	Thu, 15 Dec 2011 07:17:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:message-id:user-agent:date:from:to;
	bh=LwFOwAGT10/ib9CUEm+OR9pcFsJ40fbaGvche3QO610=;
	b=GhanWDR6MqOQ1AguExF/VUO7ISnPrkqWg6EKpRFw/tsDIqwvvPGgA/AUohOLm29zY4
	i8RXzwtT3J7qcoBZWMv/S24KFYiOHUYhUioNb06j0JuraftiYgO2Lsn6VROWPX4grCvr
	nM/Co1MljIwzT1ZMWOOAZLPdrrGWUIu35MczY=
Received: by 10.227.59.204 with SMTP id m12mr2624007wbh.10.1323962225050;
	Thu, 15 Dec 2011 07:17:05 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id hb10sm8693212wib.16.2011.12.15.07.17.02
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 15 Dec 2011 07:17:03 -0800 (PST)
MIME-Version: 1.0
Message-Id: <patchbomb.1323961634@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Thu, 15 Dec 2011 16:07:14 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 00 of 15 v5] libxl: add support for hotplug
 script calling from libxl
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This patch series adds support for hotplug script calling directly
from libxl, instead of relying on xenbackendd. Also some patches
contain general bug fixes.

Currently Linux hotplug script call functions are empty, so Linux
continues to use udev rules to call hotplug scripts.

Patches 1, 6, 8, 9, 10 are NetBSD specific, and basicaly pave the way
for the application of the bigger changes present in this series.

Patch 11 is a trivial update for an error message.

Patch 2 adds support for mounting raw image files using the vnd
device. Since NetBSD doesn't have qdisk or blktap support, the only
way to use raw images with guests is to mount the image and pass the
block device as a "PHY" backend. To check wheter an OS supports raw
images as "PHY" backends two new files are added to the project, to
avoid using #ifdefs, that contain a helper function. The file
to be included is decided during the compilation process.

Patch 3 adds a generic function to fork the current process and
execute a given file, which will be later used to execute hotplug
scripts synchronously.

Patches 4 and 5 add a new function to wait for a device to reach a
certain state, and replace wait_for_dev_destroy with this more generic
implementation. This function is also used to wait for device
initialization before calling hotplug scripts. The added function will
benefit from a rework after event support is added to libxl.

Patch 7 adds the calling of hotplug scripts when devices are
initializated and removed. Two new files are also added to support
hotplug scripts, since Linux and NetBSD hotplug scripts have different
call parameters. The path of the script to execute is retrieved
from xenstore. The file to include is also decided at compile
time.

Patches 12, 13, 14 sets frontend status to 6 when a domain is
destroyed, so devices are disconnected and then execute hotplug
scripts. Also the syntax of the libxl_domain_destroy and
libxl__devices_destroy has been changed to always force the 
destruction.

Finally patch 15 changes the mutex initialization, because NetBSD 
doesn't have the macro PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP.

Changes since v4:

 * Guess if vbd is an image file or a block device inside hotplug 
   scripts instead of passing it as a parameter.

 * Merged patches 7 and 8 to avoid breaking bisectability.

 * Changed libxl__forkexec according Ian Jackson suggestions.

 * Changed libxl__device_destroy to not modify frontend state and 
   remove frontend instead.

 * Call libxl__device_remove in libxl__device_destroy to wait for the 
   device to be disconnected.

 * Changed the initialization of the mutex, because NetBSD doesn't 
   have the used macro.

 * Merged nic and disk hotplug scripts caller functions, since they 
   take the same parameters now.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 15:17:29 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 15:17:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbD3i-0003hZ-Kj; Thu, 15 Dec 2011 15:17:22 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RbD3g-0003fI-U9
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 15:17:21 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1323962229!7357491!2
X-Originating-IP: [209.85.161.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8579 invoked from network); 15 Dec 2011 15:17:14 -0000
Received: from mail-fx0-f43.google.com (HELO mail-fx0-f43.google.com)
	(209.85.161.43)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 15:17:14 -0000
Received: by mail-fx0-f43.google.com with SMTP id p21so5275311faa.30
	for <xen-devel@lists.xensource.com>;
	Thu, 15 Dec 2011 07:17:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=+YdwVudKm6CtaaHqT9vEklNsYJPI51nlvOG9MFYyab0=;
	b=U7upVLWiEUU5tQexOkdMXL1Tspyll1vbPk/l4wjlorJwZPnAritfy53XTPqk5UIvRy
	VQ/XYJLAtOVBk4sHpjYP2HGRkFycSmMwrslM5NyQreVcz157vrOLdmviQk+2Yol9GRNt
	q2/nSheXHfskEV/OVSHjDnerWNhBDnT9+UFNA=
Received: by 10.180.77.42 with SMTP id p10mr5612466wiw.66.1323962234349;
	Thu, 15 Dec 2011 07:17:14 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id hb10sm8693212wib.16.2011.12.15.07.17.11
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 15 Dec 2011 07:17:12 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 873942d7eb6462984202e82d428e28fe9522924f
Message-Id: <873942d7eb6462984202.1323961638@loki.upc.es>
In-Reply-To: <patchbomb.1323961634@loki.upc.es>
References: <patchbomb.1323961634@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Thu, 15 Dec 2011 16:07:18 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 04 of 15 v5] libxl: introduce
	libxl__wait_for_device_state
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1323864490 -3600
# Node ID 873942d7eb6462984202e82d428e28fe9522924f
# Parent  912b900aa74f6ce2083a48b42de19abdd6c76337
libxl: introduce libxl__wait_for_device_state

This is a generic function, that waits for xs watches to reach a
certain state and then executes the passed helper function. Removed
wait_for_dev_destroy and used this new function instead. This
function will also be used by future patches that need to wait for
the initialization of devices before executing hotplug scripts.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 912b900aa74f -r 873942d7eb64 tools/libxl/libxl_device.c
--- a/tools/libxl/libxl_device.c	Wed Dec 14 13:08:10 2011 +0100
+++ b/tools/libxl/libxl_device.c	Wed Dec 14 13:08:10 2011 +0100
@@ -369,7 +369,9 @@ int libxl__device_disk_dev_number(const 
  * Returns 0 if a device is removed, ERROR_* if an error
  * or timeout occurred.
  */
-static int wait_for_dev_destroy(libxl__gc *gc, struct timeval *tv)
+int libxl__wait_for_device_state(libxl__gc *gc, struct timeval *tv,
+                                 XenbusState state,
+                                 libxl__device_state_handler handler)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
     int nfds, rc;
@@ -394,17 +396,14 @@ start:
         default:
             l1 = xs_read_watch(ctx->xsh, &n);
             if (l1 != NULL) {
-                char *state = libxl__xs_read(gc, XBT_NULL,
+                char *sstate = libxl__xs_read(gc, XBT_NULL,
                                              l1[XS_WATCH_PATH]);
-                if (!state || atoi(state) == 6) {
-                    xs_unwatch(ctx->xsh, l1[0], l1[1]);
-                    xs_rm(ctx->xsh, XBT_NULL, l1[XS_WATCH_TOKEN]);
-                    LIBXL__LOG(ctx, LIBXL__LOG_DEBUG,
-                               "Destroyed device backend at %s",
-                               l1[XS_WATCH_TOKEN]);
-                    rc = 0;
+                if (!sstate || atoi(sstate) == state) {
+                    /* Call handler function if present */
+                    if (handler)
+                        rc = handler(gc, l1, sstate);
                 } else {
-                    /* State is not "disconnected", continue waiting... */
+                    /* State is different than expected, continue waiting... */
                     goto start;
                 }
                 free(l1);
@@ -417,6 +416,23 @@ start:
 }
 
 /*
+ * Handler function for device destruction to be passed to
+ * libxl__wait_for_device_state
+ */
+static int destroy_device(libxl__gc *gc, char **l1, char *state)
+{
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+
+    xs_unwatch(ctx->xsh, l1[0], l1[1]);
+    xs_rm(ctx->xsh, XBT_NULL, l1[XS_WATCH_TOKEN]);
+    LIBXL__LOG(ctx, LIBXL__LOG_DEBUG,
+               "Destroyed device backend at %s",
+               l1[XS_WATCH_TOKEN]);
+
+    return 0;
+}
+
+/*
  * Returns 0 (device already destroyed) or 1 (caller must
  * wait_for_dev_destroy) on success, ERROR_* on fail.
  */
@@ -457,7 +473,8 @@ retry_transaction:
         struct timeval tv;
         tv.tv_sec = LIBXL_DESTROY_TIMEOUT;
         tv.tv_usec = 0;
-        rc = wait_for_dev_destroy(gc, &tv);
+        rc = libxl__wait_for_device_state(gc, &tv, XenbusStateClosed,
+                                          destroy_device);
         if (rc < 0) /* an error or timeout occurred, clear watches */
             xs_unwatch(ctx->xsh, state_path, be_path);
         xs_rm(ctx->xsh, XBT_NULL, libxl__device_frontend_path(gc, dev));
@@ -565,7 +582,8 @@ int libxl__devices_destroy(libxl__gc *gc
         tv.tv_sec = LIBXL_DESTROY_TIMEOUT;
         tv.tv_usec = 0;
         while (n_watches > 0) {
-            if (wait_for_dev_destroy(gc, &tv) < 0) {
+            if (libxl__wait_for_device_state(gc, &tv, XenbusStateClosed,
+                                             destroy_device) < 0) {
                 /* function returned ERROR_* */
                 break;
             } else {
diff -r 912b900aa74f -r 873942d7eb64 tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Wed Dec 14 13:08:10 2011 +0100
+++ b/tools/libxl/libxl_internal.h	Wed Dec 14 13:08:10 2011 +0100
@@ -24,11 +24,14 @@
 #include <stdlib.h>
 #include <string.h>
 #include <pthread.h>
+#include <sys/time.h>
 
 #include <xs.h>
 #include <xenctrl.h>
 #include "xentoollog.h"
 
+#include <xen/io/xenbus.h>
+
 #include "libxl.h"
 
 #if __GNUC__ > 3 || (__GNUC__ == 3 && __GNUC_MINOR__ >= 1)
@@ -271,6 +274,31 @@ _hidden int libxl__device_destroy(libxl_
 _hidden int libxl__devices_destroy(libxl__gc *gc, uint32_t domid, int force);
 _hidden int libxl__wait_for_backend(libxl__gc *gc, char *be_path, char *state);
 
+/* Handler for the libxl__wait_for_device_state callback */
+/*
+ * libxl__device_state_handler - Handler for the libxl__wait_for_device_state
+ * gc: allocation pool
+ * l1: array containing the path and token
+ * state: string that contains the state of the device
+ *
+ * Returns 0 on success, and < 0 on error.
+ */
+typedef int libxl__device_state_handler(libxl__gc *gc, char **l1, char *state);
+
+/*
+ * libxl__wait_for_device_state - waits a given time for a device to
+ * reach a given state
+ * gc: allocation pool
+ * tv: timeval struct containing the maximum time to wait
+ * state: state to wait for (check xen/io/xenbus.h)
+ * handler: callback function to execute when state is reached
+ *
+ * Returns 0 on success, and < 0 on error.
+ */
+_hidden int libxl__wait_for_device_state(libxl__gc *gc, struct timeval *tv,
+                                         XenbusState state,
+                                         libxl__device_state_handler handler);
+
 /*
  * libxl__try_phy_backend - Check if there's support for the passed
  * type of file using the PHY backend

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 15:17:29 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 15:17:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbD3i-0003hZ-Kj; Thu, 15 Dec 2011 15:17:22 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RbD3g-0003fI-U9
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 15:17:21 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1323962229!7357491!2
X-Originating-IP: [209.85.161.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8579 invoked from network); 15 Dec 2011 15:17:14 -0000
Received: from mail-fx0-f43.google.com (HELO mail-fx0-f43.google.com)
	(209.85.161.43)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 15:17:14 -0000
Received: by mail-fx0-f43.google.com with SMTP id p21so5275311faa.30
	for <xen-devel@lists.xensource.com>;
	Thu, 15 Dec 2011 07:17:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=+YdwVudKm6CtaaHqT9vEklNsYJPI51nlvOG9MFYyab0=;
	b=U7upVLWiEUU5tQexOkdMXL1Tspyll1vbPk/l4wjlorJwZPnAritfy53XTPqk5UIvRy
	VQ/XYJLAtOVBk4sHpjYP2HGRkFycSmMwrslM5NyQreVcz157vrOLdmviQk+2Yol9GRNt
	q2/nSheXHfskEV/OVSHjDnerWNhBDnT9+UFNA=
Received: by 10.180.77.42 with SMTP id p10mr5612466wiw.66.1323962234349;
	Thu, 15 Dec 2011 07:17:14 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id hb10sm8693212wib.16.2011.12.15.07.17.11
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 15 Dec 2011 07:17:12 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 873942d7eb6462984202e82d428e28fe9522924f
Message-Id: <873942d7eb6462984202.1323961638@loki.upc.es>
In-Reply-To: <patchbomb.1323961634@loki.upc.es>
References: <patchbomb.1323961634@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Thu, 15 Dec 2011 16:07:18 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 04 of 15 v5] libxl: introduce
	libxl__wait_for_device_state
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1323864490 -3600
# Node ID 873942d7eb6462984202e82d428e28fe9522924f
# Parent  912b900aa74f6ce2083a48b42de19abdd6c76337
libxl: introduce libxl__wait_for_device_state

This is a generic function, that waits for xs watches to reach a
certain state and then executes the passed helper function. Removed
wait_for_dev_destroy and used this new function instead. This
function will also be used by future patches that need to wait for
the initialization of devices before executing hotplug scripts.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 912b900aa74f -r 873942d7eb64 tools/libxl/libxl_device.c
--- a/tools/libxl/libxl_device.c	Wed Dec 14 13:08:10 2011 +0100
+++ b/tools/libxl/libxl_device.c	Wed Dec 14 13:08:10 2011 +0100
@@ -369,7 +369,9 @@ int libxl__device_disk_dev_number(const 
  * Returns 0 if a device is removed, ERROR_* if an error
  * or timeout occurred.
  */
-static int wait_for_dev_destroy(libxl__gc *gc, struct timeval *tv)
+int libxl__wait_for_device_state(libxl__gc *gc, struct timeval *tv,
+                                 XenbusState state,
+                                 libxl__device_state_handler handler)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
     int nfds, rc;
@@ -394,17 +396,14 @@ start:
         default:
             l1 = xs_read_watch(ctx->xsh, &n);
             if (l1 != NULL) {
-                char *state = libxl__xs_read(gc, XBT_NULL,
+                char *sstate = libxl__xs_read(gc, XBT_NULL,
                                              l1[XS_WATCH_PATH]);
-                if (!state || atoi(state) == 6) {
-                    xs_unwatch(ctx->xsh, l1[0], l1[1]);
-                    xs_rm(ctx->xsh, XBT_NULL, l1[XS_WATCH_TOKEN]);
-                    LIBXL__LOG(ctx, LIBXL__LOG_DEBUG,
-                               "Destroyed device backend at %s",
-                               l1[XS_WATCH_TOKEN]);
-                    rc = 0;
+                if (!sstate || atoi(sstate) == state) {
+                    /* Call handler function if present */
+                    if (handler)
+                        rc = handler(gc, l1, sstate);
                 } else {
-                    /* State is not "disconnected", continue waiting... */
+                    /* State is different than expected, continue waiting... */
                     goto start;
                 }
                 free(l1);
@@ -417,6 +416,23 @@ start:
 }
 
 /*
+ * Handler function for device destruction to be passed to
+ * libxl__wait_for_device_state
+ */
+static int destroy_device(libxl__gc *gc, char **l1, char *state)
+{
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+
+    xs_unwatch(ctx->xsh, l1[0], l1[1]);
+    xs_rm(ctx->xsh, XBT_NULL, l1[XS_WATCH_TOKEN]);
+    LIBXL__LOG(ctx, LIBXL__LOG_DEBUG,
+               "Destroyed device backend at %s",
+               l1[XS_WATCH_TOKEN]);
+
+    return 0;
+}
+
+/*
  * Returns 0 (device already destroyed) or 1 (caller must
  * wait_for_dev_destroy) on success, ERROR_* on fail.
  */
@@ -457,7 +473,8 @@ retry_transaction:
         struct timeval tv;
         tv.tv_sec = LIBXL_DESTROY_TIMEOUT;
         tv.tv_usec = 0;
-        rc = wait_for_dev_destroy(gc, &tv);
+        rc = libxl__wait_for_device_state(gc, &tv, XenbusStateClosed,
+                                          destroy_device);
         if (rc < 0) /* an error or timeout occurred, clear watches */
             xs_unwatch(ctx->xsh, state_path, be_path);
         xs_rm(ctx->xsh, XBT_NULL, libxl__device_frontend_path(gc, dev));
@@ -565,7 +582,8 @@ int libxl__devices_destroy(libxl__gc *gc
         tv.tv_sec = LIBXL_DESTROY_TIMEOUT;
         tv.tv_usec = 0;
         while (n_watches > 0) {
-            if (wait_for_dev_destroy(gc, &tv) < 0) {
+            if (libxl__wait_for_device_state(gc, &tv, XenbusStateClosed,
+                                             destroy_device) < 0) {
                 /* function returned ERROR_* */
                 break;
             } else {
diff -r 912b900aa74f -r 873942d7eb64 tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Wed Dec 14 13:08:10 2011 +0100
+++ b/tools/libxl/libxl_internal.h	Wed Dec 14 13:08:10 2011 +0100
@@ -24,11 +24,14 @@
 #include <stdlib.h>
 #include <string.h>
 #include <pthread.h>
+#include <sys/time.h>
 
 #include <xs.h>
 #include <xenctrl.h>
 #include "xentoollog.h"
 
+#include <xen/io/xenbus.h>
+
 #include "libxl.h"
 
 #if __GNUC__ > 3 || (__GNUC__ == 3 && __GNUC_MINOR__ >= 1)
@@ -271,6 +274,31 @@ _hidden int libxl__device_destroy(libxl_
 _hidden int libxl__devices_destroy(libxl__gc *gc, uint32_t domid, int force);
 _hidden int libxl__wait_for_backend(libxl__gc *gc, char *be_path, char *state);
 
+/* Handler for the libxl__wait_for_device_state callback */
+/*
+ * libxl__device_state_handler - Handler for the libxl__wait_for_device_state
+ * gc: allocation pool
+ * l1: array containing the path and token
+ * state: string that contains the state of the device
+ *
+ * Returns 0 on success, and < 0 on error.
+ */
+typedef int libxl__device_state_handler(libxl__gc *gc, char **l1, char *state);
+
+/*
+ * libxl__wait_for_device_state - waits a given time for a device to
+ * reach a given state
+ * gc: allocation pool
+ * tv: timeval struct containing the maximum time to wait
+ * state: state to wait for (check xen/io/xenbus.h)
+ * handler: callback function to execute when state is reached
+ *
+ * Returns 0 on success, and < 0 on error.
+ */
+_hidden int libxl__wait_for_device_state(libxl__gc *gc, struct timeval *tv,
+                                         XenbusState state,
+                                         libxl__device_state_handler handler);
+
 /*
  * libxl__try_phy_backend - Check if there's support for the passed
  * type of file using the PHY backend

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 15:17:30 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 15:17:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbD3b-0003fD-6a; Thu, 15 Dec 2011 15:17:15 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RbD3Z-0003eP-61
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 15:17:13 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1323962225!7409341!2
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6521 invoked from network); 15 Dec 2011 15:17:07 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 15:17:07 -0000
Received: by mail-ww0-f43.google.com with SMTP id ds11so3581748wgb.24
	for <xen-devel@lists.xensource.com>;
	Thu, 15 Dec 2011 07:17:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=fDWiIN8JwMf1dy7r1Zm9KxHpseDLSgC8AvXD1Q+mp4I=;
	b=gRNP6bEMUzi605qkXSKo7XuJF7JAcSn/wt2YMAU5oWkPnh4/yBWMd/C+xNxiWWSgU9
	Ruy/CMmVw/kpfNMWym0AAcl/EcjB5URHfE8wjaHHTvnixMbOs6eQTtke5sSyuzUnH97n
	d7t+7hm+I3YDJ3uMgHQ6ZLVyHUgwQj2+/zrv0=
Received: by 10.216.139.132 with SMTP id c4mr1054351wej.2.1323962226966;
	Thu, 15 Dec 2011 07:17:06 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id hb10sm8693212wib.16.2011.12.15.07.17.05
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 15 Dec 2011 07:17:05 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 8e129474fc0ac87623ba814ea865326d45cb8436
Message-Id: <8e129474fc0ac87623ba.1323961635@loki.upc.es>
In-Reply-To: <patchbomb.1323961634@loki.upc.es>
References: <patchbomb.1323961634@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Thu, 15 Dec 2011 16:07:15 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 01 of 15 v5] hotplug/block: get the type of
 block device from file path (NetBSD)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1317386335 -7200
# Node ID 8e129474fc0ac87623ba814ea865326d45cb8436
# Parent  7ca56cca09ade16645fb4806be2c5b2b0bc3332b
hotplug/block: get the type of block device from file path (NetBSD)

Guess the type of block device to attach based on the file name
present in xenstore, since new Xen versions don't make a difference
between a block device or an image.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 7ca56cca09ad -r 8e129474fc0a tools/hotplug/NetBSD/block
--- a/tools/hotplug/NetBSD/block	Mon Dec 12 17:59:43 2011 +0000
+++ b/tools/hotplug/NetBSD/block	Fri Sep 30 14:38:55 2011 +0200
@@ -19,9 +19,14 @@ error() {
 
 xpath=$1
 xstatus=$2
-xtype=$(xenstore-read "$xpath/type")
 xparams=$(xenstore-read "$xpath/params")
 
+if [ -f $xparams ]; then
+	xtype="file"
+else
+	xtype="phy"
+fi
+
 case $xstatus in
 6)
 	# device removed

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 15:17:30 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 15:17:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbD3b-0003fD-6a; Thu, 15 Dec 2011 15:17:15 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RbD3Z-0003eP-61
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 15:17:13 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1323962225!7409341!2
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6521 invoked from network); 15 Dec 2011 15:17:07 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 15:17:07 -0000
Received: by mail-ww0-f43.google.com with SMTP id ds11so3581748wgb.24
	for <xen-devel@lists.xensource.com>;
	Thu, 15 Dec 2011 07:17:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=fDWiIN8JwMf1dy7r1Zm9KxHpseDLSgC8AvXD1Q+mp4I=;
	b=gRNP6bEMUzi605qkXSKo7XuJF7JAcSn/wt2YMAU5oWkPnh4/yBWMd/C+xNxiWWSgU9
	Ruy/CMmVw/kpfNMWym0AAcl/EcjB5URHfE8wjaHHTvnixMbOs6eQTtke5sSyuzUnH97n
	d7t+7hm+I3YDJ3uMgHQ6ZLVyHUgwQj2+/zrv0=
Received: by 10.216.139.132 with SMTP id c4mr1054351wej.2.1323962226966;
	Thu, 15 Dec 2011 07:17:06 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id hb10sm8693212wib.16.2011.12.15.07.17.05
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 15 Dec 2011 07:17:05 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 8e129474fc0ac87623ba814ea865326d45cb8436
Message-Id: <8e129474fc0ac87623ba.1323961635@loki.upc.es>
In-Reply-To: <patchbomb.1323961634@loki.upc.es>
References: <patchbomb.1323961634@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Thu, 15 Dec 2011 16:07:15 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 01 of 15 v5] hotplug/block: get the type of
 block device from file path (NetBSD)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1317386335 -7200
# Node ID 8e129474fc0ac87623ba814ea865326d45cb8436
# Parent  7ca56cca09ade16645fb4806be2c5b2b0bc3332b
hotplug/block: get the type of block device from file path (NetBSD)

Guess the type of block device to attach based on the file name
present in xenstore, since new Xen versions don't make a difference
between a block device or an image.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 7ca56cca09ad -r 8e129474fc0a tools/hotplug/NetBSD/block
--- a/tools/hotplug/NetBSD/block	Mon Dec 12 17:59:43 2011 +0000
+++ b/tools/hotplug/NetBSD/block	Fri Sep 30 14:38:55 2011 +0200
@@ -19,9 +19,14 @@ error() {
 
 xpath=$1
 xstatus=$2
-xtype=$(xenstore-read "$xpath/type")
 xparams=$(xenstore-read "$xpath/params")
 
+if [ -f $xparams ]; then
+	xtype="file"
+else
+	xtype="phy"
+fi
+
 case $xstatus in
 6)
 	# device removed

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 15:17:30 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 15:17:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbD3e-0003fy-0C; Thu, 15 Dec 2011 15:17:18 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RbD3c-0003em-6V
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 15:17:16 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1323962182!57450280!1
X-Originating-IP: [74.125.83.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29354 invoked from network); 15 Dec 2011 15:16:22 -0000
Received: from mail-ee0-f43.google.com (HELO mail-ee0-f43.google.com)
	(74.125.83.43)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 15:16:22 -0000
Received: by eekd4 with SMTP id d4so4599524eek.30
	for <xen-devel@lists.xensource.com>;
	Thu, 15 Dec 2011 07:17:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=rAHrov5dUJ+lZ9hyD3sxHKx52vK54r2PW131dZYVOCI=;
	b=cAFpoXph8BmuVq6JF93JYClq/iGrHA+fdLzsLZl/0n7m2/YUNhEvquaM9qS7UEb6R3
	rnvQ+UqRIK28PLsOB8hlMne7J5QIJGoGxMFD0MalYzO5UvlQXjecmzMuNaEZK1eibpss
	yVNUROBMKle94httFKfH/Ho8QghlNl1F8fOXs=
Received: by 10.180.105.232 with SMTP id gp8mr5606232wib.65.1323962231476;
	Thu, 15 Dec 2011 07:17:11 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id hb10sm8693212wib.16.2011.12.15.07.17.09
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 15 Dec 2011 07:17:10 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 912b900aa74f6ce2083a48b42de19abdd6c76337
Message-Id: <912b900aa74f6ce2083a.1323961637@loki.upc.es>
In-Reply-To: <patchbomb.1323961634@loki.upc.es>
References: <patchbomb.1323961634@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Thu, 15 Dec 2011 16:07:17 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 03 of 15 v5] libxl: add libxl__forkexec function
	to libxl_exec
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1323864490 -3600
# Node ID 912b900aa74f6ce2083a48b42de19abdd6c76337
# Parent  1d1fc97535c2790731e7afbc4c891f7ef6167983
libxl: add libxl__forkexec function to libxl_exec

Add a new function to libxl_exec that performs a fork and executes
the passed arguments using libxl__exec.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 1d1fc97535c2 -r 912b900aa74f tools/libxl/libxl_exec.c
--- a/tools/libxl/libxl_exec.c	Fri Sep 30 14:38:55 2011 +0200
+++ b/tools/libxl/libxl_exec.c	Wed Dec 14 13:08:10 2011 +0100
@@ -449,6 +449,42 @@ int libxl__spawn_check(libxl__gc *gc, li
     return ERROR_FAIL;
 }
 
+int libxl__forkexec(libxl__gc *gc, int stdinfd, int stdoutfd,
+                    int stderrfd, const char *arg0, char **args,
+                    const char *what)
+{
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+    int status;
+    int rc = 0;
+    pid_t pid = fork();
+
+    switch (pid) {
+    case -1:
+        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "fork failed\n");
+        rc = -1;
+        break;
+    case 0:
+        libxl__exec(stdinfd, stdoutfd, stderrfd, arg0, args);
+        /* libxl__exec never returns */
+    default:
+        while (waitpid(pid, &status, 0) < 0) {
+            if (errno != EINTR) {
+                LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, 
+                                 "waitpid failed for %s\n",
+                                 what);
+                rc = -1;
+                break;
+            }
+        }
+        if (status)
+            libxl_report_child_exitstatus(ctx, LIBXL__LOG_ERROR,
+                                          what, pid, status);
+        rc = status;
+        break;
+    }
+    return rc;
+}
+
 /*
  * Local variables:
  * mode: C
diff -r 1d1fc97535c2 -r 912b900aa74f tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Fri Sep 30 14:38:55 2011 +0200
+++ b/tools/libxl/libxl_internal.h	Wed Dec 14 13:08:10 2011 +0100
@@ -419,6 +419,20 @@ _hidden int libxl__spawn_check(libxl__gc
 _hidden void libxl__exec(int stdinfd, int stdoutfd, int stderrfd,
                const char *arg0, char **args); // logs errors, never returns
 
+/*
+ * libxl__forkexec - Executes a file synchronously
+ * argv0: file name associated with the file being executed.
+ * args: list of arguments. See execvp(3) man page for more info.
+ *
+ * Returns -1 if the execution fails or the exit status, as reported
+ * by waitpid, on success.
+ *
+ * Logs errors.
+ */
+_hidden int libxl__forkexec(libxl__gc *gc, int stdinfd, int stdoutfd,
+                            int stderrfd, const char *arg0, char **args,
+                            const char *what);
+
 /* from xl_create */
 _hidden int libxl__domain_make(libxl__gc *gc, libxl_domain_create_info *info, uint32_t *domid);
 _hidden int libxl__domain_build(libxl__gc *gc,

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 15:17:30 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 15:17:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbD3e-0003fy-0C; Thu, 15 Dec 2011 15:17:18 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RbD3c-0003em-6V
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 15:17:16 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1323962182!57450280!1
X-Originating-IP: [74.125.83.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29354 invoked from network); 15 Dec 2011 15:16:22 -0000
Received: from mail-ee0-f43.google.com (HELO mail-ee0-f43.google.com)
	(74.125.83.43)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 15:16:22 -0000
Received: by eekd4 with SMTP id d4so4599524eek.30
	for <xen-devel@lists.xensource.com>;
	Thu, 15 Dec 2011 07:17:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=rAHrov5dUJ+lZ9hyD3sxHKx52vK54r2PW131dZYVOCI=;
	b=cAFpoXph8BmuVq6JF93JYClq/iGrHA+fdLzsLZl/0n7m2/YUNhEvquaM9qS7UEb6R3
	rnvQ+UqRIK28PLsOB8hlMne7J5QIJGoGxMFD0MalYzO5UvlQXjecmzMuNaEZK1eibpss
	yVNUROBMKle94httFKfH/Ho8QghlNl1F8fOXs=
Received: by 10.180.105.232 with SMTP id gp8mr5606232wib.65.1323962231476;
	Thu, 15 Dec 2011 07:17:11 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id hb10sm8693212wib.16.2011.12.15.07.17.09
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 15 Dec 2011 07:17:10 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 912b900aa74f6ce2083a48b42de19abdd6c76337
Message-Id: <912b900aa74f6ce2083a.1323961637@loki.upc.es>
In-Reply-To: <patchbomb.1323961634@loki.upc.es>
References: <patchbomb.1323961634@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Thu, 15 Dec 2011 16:07:17 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 03 of 15 v5] libxl: add libxl__forkexec function
	to libxl_exec
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1323864490 -3600
# Node ID 912b900aa74f6ce2083a48b42de19abdd6c76337
# Parent  1d1fc97535c2790731e7afbc4c891f7ef6167983
libxl: add libxl__forkexec function to libxl_exec

Add a new function to libxl_exec that performs a fork and executes
the passed arguments using libxl__exec.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 1d1fc97535c2 -r 912b900aa74f tools/libxl/libxl_exec.c
--- a/tools/libxl/libxl_exec.c	Fri Sep 30 14:38:55 2011 +0200
+++ b/tools/libxl/libxl_exec.c	Wed Dec 14 13:08:10 2011 +0100
@@ -449,6 +449,42 @@ int libxl__spawn_check(libxl__gc *gc, li
     return ERROR_FAIL;
 }
 
+int libxl__forkexec(libxl__gc *gc, int stdinfd, int stdoutfd,
+                    int stderrfd, const char *arg0, char **args,
+                    const char *what)
+{
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+    int status;
+    int rc = 0;
+    pid_t pid = fork();
+
+    switch (pid) {
+    case -1:
+        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "fork failed\n");
+        rc = -1;
+        break;
+    case 0:
+        libxl__exec(stdinfd, stdoutfd, stderrfd, arg0, args);
+        /* libxl__exec never returns */
+    default:
+        while (waitpid(pid, &status, 0) < 0) {
+            if (errno != EINTR) {
+                LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, 
+                                 "waitpid failed for %s\n",
+                                 what);
+                rc = -1;
+                break;
+            }
+        }
+        if (status)
+            libxl_report_child_exitstatus(ctx, LIBXL__LOG_ERROR,
+                                          what, pid, status);
+        rc = status;
+        break;
+    }
+    return rc;
+}
+
 /*
  * Local variables:
  * mode: C
diff -r 1d1fc97535c2 -r 912b900aa74f tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Fri Sep 30 14:38:55 2011 +0200
+++ b/tools/libxl/libxl_internal.h	Wed Dec 14 13:08:10 2011 +0100
@@ -419,6 +419,20 @@ _hidden int libxl__spawn_check(libxl__gc
 _hidden void libxl__exec(int stdinfd, int stdoutfd, int stderrfd,
                const char *arg0, char **args); // logs errors, never returns
 
+/*
+ * libxl__forkexec - Executes a file synchronously
+ * argv0: file name associated with the file being executed.
+ * args: list of arguments. See execvp(3) man page for more info.
+ *
+ * Returns -1 if the execution fails or the exit status, as reported
+ * by waitpid, on success.
+ *
+ * Logs errors.
+ */
+_hidden int libxl__forkexec(libxl__gc *gc, int stdinfd, int stdoutfd,
+                            int stderrfd, const char *arg0, char **args,
+                            const char *what);
+
 /* from xl_create */
 _hidden int libxl__domain_make(libxl__gc *gc, libxl_domain_create_info *info, uint32_t *domid);
 _hidden int libxl__domain_build(libxl__gc *gc,

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 15:17:30 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 15:17:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbD3k-0003iA-1k; Thu, 15 Dec 2011 15:17:24 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RbD3i-0003fe-LY
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 15:17:22 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1323962225!7409341!3
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7108 invoked from network); 15 Dec 2011 15:17:16 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 15:17:16 -0000
Received: by mail-ww0-f43.google.com with SMTP id ds11so3581748wgb.24
	for <xen-devel@lists.xensource.com>;
	Thu, 15 Dec 2011 07:17:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=dhDQWYVnNyiy2hRDrLBl354DU2y7yHOa3yztzEWi360=;
	b=tkRsMRtMB8oTR4cQJT4cKAhogHNZrNHnrynMWfHxiLSvuXoKLZJUUTCG3uXNrjWQxq
	iIJXVoTRQJ1ymW//zGplJjFfKNDoyLtmnKNokwGd7scs0CGIe0DXUM+s9Js4FnZqRIUn
	9g3HBgqVTKQd3gj7y6Fo/ZITYaYpB90M1B+/0=
Received: by 10.216.136.152 with SMTP id w24mr1442293wei.43.1323962236417;
	Thu, 15 Dec 2011 07:17:16 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id hb10sm8693212wib.16.2011.12.15.07.17.14
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 15 Dec 2011 07:17:15 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 08a9f86b79dfe5db150392c916a72bafc3f05137
Message-Id: <08a9f86b79dfe5db1503.1323961639@loki.upc.es>
In-Reply-To: <patchbomb.1323961634@loki.upc.es>
References: <patchbomb.1323961634@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Thu, 15 Dec 2011 16:07:19 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 05 of 15 v5] libxl: wait for devices to
 initialize upon addition to the domain
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1323864490 -3600
# Node ID 08a9f86b79dfe5db150392c916a72bafc3f05137
# Parent  873942d7eb6462984202e82d428e28fe9522924f
libxl: wait for devices to initialize upon addition to the domain.

Block waiting for devices to initialize (switch to state 2). This is
necessary because we need to call the hotplug scripts when state is
2, otherwise the execution fails. Make use of the newly introduced
function libxl__wait_for_device_state.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 873942d7eb64 -r 08a9f86b79df tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Wed Dec 14 13:08:10 2011 +0100
+++ b/tools/libxl/libxl.c	Wed Dec 14 13:08:10 2011 +0100
@@ -976,6 +976,8 @@ int libxl_device_disk_add(libxl_ctx *ctx
     flexarray_t *front;
     flexarray_t *back;
     char *dev;
+    char *be_path, *state_path, *state;
+    struct timeval tv;
     libxl__device device;
     int major, minor, rc;
 
@@ -1080,6 +1082,23 @@ int libxl_device_disk_add(libxl_ctx *ctx
                              libxl__xs_kvs_of_flexarray(gc, back, back->count),
                              libxl__xs_kvs_of_flexarray(gc, front, front->count));
 
+    be_path = libxl__device_backend_path(gc, &device);
+    state_path = libxl__sprintf(gc, "%s/state", be_path);
+    state = libxl__xs_read(gc, XBT_NULL, state_path);
+
+    if (atoi(state) != XenbusStateInitWait) {
+        xs_watch(ctx->xsh, state_path, be_path);
+        tv.tv_sec = LIBXL_DESTROY_TIMEOUT;
+        tv.tv_usec = 0;
+        rc = libxl__wait_for_device_state(gc, &tv, XenbusStateInitWait, NULL);
+        xs_unwatch(ctx->xsh, state_path, be_path);
+        if (rc < 0) {
+            LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
+                       "unable to initialize disk device: %s\n",
+                       disk->pdev_path);
+            goto out_free;
+        }
+    }
     rc = 0;
 
 out_free:
@@ -1455,6 +1474,8 @@ int libxl_device_nic_add(libxl_ctx *ctx,
     flexarray_t *back;
     libxl__device device;
     char *dompath, **l;
+    char *be_path, *state_path, *state;
+    struct timeval tv;
     unsigned int nb, rc;
 
     front = flexarray_make(16, 1);
@@ -1523,8 +1544,25 @@ int libxl_device_nic_add(libxl_ctx *ctx,
                              libxl__xs_kvs_of_flexarray(gc, back, back->count),
                              libxl__xs_kvs_of_flexarray(gc, front, front->count));
 
-    /* FIXME: wait for plug */
+    be_path = libxl__device_backend_path(gc, &device);
+    state_path = libxl__sprintf(gc, "%s/state", be_path);
+    state = libxl__xs_read(gc, XBT_NULL, state_path);
+
+    if (atoi(state) != XenbusStateInitWait) {
+        xs_watch(ctx->xsh, state_path, be_path);
+        tv.tv_sec = LIBXL_DESTROY_TIMEOUT;
+        tv.tv_usec = 0;
+        rc = libxl__wait_for_device_state(gc, &tv, XenbusStateInitWait, NULL);
+        xs_unwatch(ctx->xsh, state_path, be_path);
+        if (rc < 0) {
+            LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
+                       "unable to initialize nic device: %s\n",
+                       nic->ifname);
+            goto out_free;
+        }
+    }
     rc = 0;
+
 out_free:
     flexarray_free(back);
     flexarray_free(front);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 15:17:30 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 15:17:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbD3k-0003iA-1k; Thu, 15 Dec 2011 15:17:24 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RbD3i-0003fe-LY
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 15:17:22 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1323962225!7409341!3
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7108 invoked from network); 15 Dec 2011 15:17:16 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 15:17:16 -0000
Received: by mail-ww0-f43.google.com with SMTP id ds11so3581748wgb.24
	for <xen-devel@lists.xensource.com>;
	Thu, 15 Dec 2011 07:17:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=dhDQWYVnNyiy2hRDrLBl354DU2y7yHOa3yztzEWi360=;
	b=tkRsMRtMB8oTR4cQJT4cKAhogHNZrNHnrynMWfHxiLSvuXoKLZJUUTCG3uXNrjWQxq
	iIJXVoTRQJ1ymW//zGplJjFfKNDoyLtmnKNokwGd7scs0CGIe0DXUM+s9Js4FnZqRIUn
	9g3HBgqVTKQd3gj7y6Fo/ZITYaYpB90M1B+/0=
Received: by 10.216.136.152 with SMTP id w24mr1442293wei.43.1323962236417;
	Thu, 15 Dec 2011 07:17:16 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id hb10sm8693212wib.16.2011.12.15.07.17.14
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 15 Dec 2011 07:17:15 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 08a9f86b79dfe5db150392c916a72bafc3f05137
Message-Id: <08a9f86b79dfe5db1503.1323961639@loki.upc.es>
In-Reply-To: <patchbomb.1323961634@loki.upc.es>
References: <patchbomb.1323961634@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Thu, 15 Dec 2011 16:07:19 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 05 of 15 v5] libxl: wait for devices to
 initialize upon addition to the domain
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1323864490 -3600
# Node ID 08a9f86b79dfe5db150392c916a72bafc3f05137
# Parent  873942d7eb6462984202e82d428e28fe9522924f
libxl: wait for devices to initialize upon addition to the domain.

Block waiting for devices to initialize (switch to state 2). This is
necessary because we need to call the hotplug scripts when state is
2, otherwise the execution fails. Make use of the newly introduced
function libxl__wait_for_device_state.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 873942d7eb64 -r 08a9f86b79df tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Wed Dec 14 13:08:10 2011 +0100
+++ b/tools/libxl/libxl.c	Wed Dec 14 13:08:10 2011 +0100
@@ -976,6 +976,8 @@ int libxl_device_disk_add(libxl_ctx *ctx
     flexarray_t *front;
     flexarray_t *back;
     char *dev;
+    char *be_path, *state_path, *state;
+    struct timeval tv;
     libxl__device device;
     int major, minor, rc;
 
@@ -1080,6 +1082,23 @@ int libxl_device_disk_add(libxl_ctx *ctx
                              libxl__xs_kvs_of_flexarray(gc, back, back->count),
                              libxl__xs_kvs_of_flexarray(gc, front, front->count));
 
+    be_path = libxl__device_backend_path(gc, &device);
+    state_path = libxl__sprintf(gc, "%s/state", be_path);
+    state = libxl__xs_read(gc, XBT_NULL, state_path);
+
+    if (atoi(state) != XenbusStateInitWait) {
+        xs_watch(ctx->xsh, state_path, be_path);
+        tv.tv_sec = LIBXL_DESTROY_TIMEOUT;
+        tv.tv_usec = 0;
+        rc = libxl__wait_for_device_state(gc, &tv, XenbusStateInitWait, NULL);
+        xs_unwatch(ctx->xsh, state_path, be_path);
+        if (rc < 0) {
+            LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
+                       "unable to initialize disk device: %s\n",
+                       disk->pdev_path);
+            goto out_free;
+        }
+    }
     rc = 0;
 
 out_free:
@@ -1455,6 +1474,8 @@ int libxl_device_nic_add(libxl_ctx *ctx,
     flexarray_t *back;
     libxl__device device;
     char *dompath, **l;
+    char *be_path, *state_path, *state;
+    struct timeval tv;
     unsigned int nb, rc;
 
     front = flexarray_make(16, 1);
@@ -1523,8 +1544,25 @@ int libxl_device_nic_add(libxl_ctx *ctx,
                              libxl__xs_kvs_of_flexarray(gc, back, back->count),
                              libxl__xs_kvs_of_flexarray(gc, front, front->count));
 
-    /* FIXME: wait for plug */
+    be_path = libxl__device_backend_path(gc, &device);
+    state_path = libxl__sprintf(gc, "%s/state", be_path);
+    state = libxl__xs_read(gc, XBT_NULL, state_path);
+
+    if (atoi(state) != XenbusStateInitWait) {
+        xs_watch(ctx->xsh, state_path, be_path);
+        tv.tv_sec = LIBXL_DESTROY_TIMEOUT;
+        tv.tv_usec = 0;
+        rc = libxl__wait_for_device_state(gc, &tv, XenbusStateInitWait, NULL);
+        xs_unwatch(ctx->xsh, state_path, be_path);
+        if (rc < 0) {
+            LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
+                       "unable to initialize nic device: %s\n",
+                       nic->ifname);
+            goto out_free;
+        }
+    }
     rc = 0;
+
 out_free:
     flexarray_free(back);
     flexarray_free(front);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 15:17:32 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 15:17:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbD3d-0003fl-K0; Thu, 15 Dec 2011 15:17:17 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RbD3c-0003eZ-1N
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 15:17:16 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1323962229!7357491!1
X-Originating-IP: [209.85.161.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8426 invoked from network); 15 Dec 2011 15:17:09 -0000
Received: from mail-fx0-f43.google.com (HELO mail-fx0-f43.google.com)
	(209.85.161.43)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 15:17:09 -0000
Received: by faap21 with SMTP id p21so5275311faa.30
	for <xen-devel@lists.xensource.com>;
	Thu, 15 Dec 2011 07:17:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=IQBkexYFG6AWbSP8RRO0WRhxHe/NTU2e1ejh/NoqXWM=;
	b=qQBjq6gh3Dg31PXtX7JjzqDiMR1qYi5kfzkxr0ZvYkjLC71NTl2TWc9VugjkScq5Eo
	z1ZlpMaWe+rgHSmYuMQahEVfeMcOfGYvjvrm4FvIwcypZ28NRDsoGvcdfVjJ6I2DLOis
	OnCeZhTr2GpPo4shgDr20nxecQ2UWMShb4Wds=
Received: by 10.180.91.137 with SMTP id ce9mr6092887wib.5.1323962229164;
	Thu, 15 Dec 2011 07:17:09 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id hb10sm8693212wib.16.2011.12.15.07.17.07
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 15 Dec 2011 07:17:07 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 1d1fc97535c2790731e7afbc4c891f7ef6167983
Message-Id: <1d1fc97535c2790731e7.1323961636@loki.upc.es>
In-Reply-To: <patchbomb.1323961634@loki.upc.es>
References: <patchbomb.1323961634@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Thu, 15 Dec 2011 16:07:16 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 02 of 15 v5] libxl: add support for image files
	for NetBSD
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1317386335 -7200
# Node ID 1d1fc97535c2790731e7afbc4c891f7ef6167983
# Parent  8e129474fc0ac87623ba814ea865326d45cb8436
libxl: add support for image files for NetBSD

Created a helper function to detect if the OS is capable of using
image files as phy backends. Create two OS specific files, and
changed the Makefile to choose the correct one at compile time.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 8e129474fc0a -r 1d1fc97535c2 tools/libxl/Makefile
--- a/tools/libxl/Makefile	Fri Sep 30 14:38:55 2011 +0200
+++ b/tools/libxl/Makefile	Fri Sep 30 14:38:55 2011 +0200
@@ -33,6 +33,15 @@ endif
 LIBXL_OBJS-$(CONFIG_X86) += libxl_cpuid.o
 LIBXL_OBJS-$(CONFIG_IA64) += libxl_nocpuid.o
 
+ifeq ($(CONFIG_NetBSD),y)
+LIBXL_OBJS-y += libxl_netbsd.o
+else ifeq ($(CONFIG_Linux),y)
+LIBXL_OBJS-y += libxl_linux.o
+else
+$(error Your Operating System is not supported by libxenlight, \
+please check libxl_linux.c and libxl_netbsd.c to see how to get it ported)
+endif
+
 LIBXL_LIBS += -lyajl
 
 LIBXL_OBJS = flexarray.o libxl.o libxl_create.o libxl_dm.o libxl_pci.o \
diff -r 8e129474fc0a -r 1d1fc97535c2 tools/libxl/libxl_device.c
--- a/tools/libxl/libxl_device.c	Fri Sep 30 14:38:55 2011 +0200
+++ b/tools/libxl/libxl_device.c	Fri Sep 30 14:38:55 2011 +0200
@@ -137,15 +137,14 @@ static int disk_try_backend(disk_try_bac
               a->disk->format == LIBXL_DISK_FORMAT_EMPTY)) {
             goto bad_format;
         }
-        if (a->disk->format != LIBXL_DISK_FORMAT_EMPTY &&
-            !S_ISBLK(a->stab.st_mode)) {
-            LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Disk vdev=%s, backend phy"
-                       " unsuitable as phys path not a block device",
-                       a->disk->vdev);
-            return 0;
-        }
 
-        return backend;
+        if (libxl__try_phy_backend(a->stab.st_mode))
+            return backend;
+
+        LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Disk vdev=%s, backend phy"
+                   " unsuitable as phys path not a block device",
+                   a->disk->vdev);
+        return 0;
 
     case LIBXL_DISK_BACKEND_TAP:
         if (!libxl__blktap_enabled(a->gc)) {
diff -r 8e129474fc0a -r 1d1fc97535c2 tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Fri Sep 30 14:38:55 2011 +0200
+++ b/tools/libxl/libxl_internal.h	Fri Sep 30 14:38:55 2011 +0200
@@ -271,6 +271,15 @@ _hidden int libxl__device_destroy(libxl_
 _hidden int libxl__devices_destroy(libxl__gc *gc, uint32_t domid, int force);
 _hidden int libxl__wait_for_backend(libxl__gc *gc, char *be_path, char *state);
 
+/*
+ * libxl__try_phy_backend - Check if there's support for the passed
+ * type of file using the PHY backend
+ * st_mode: mode_t of the file, as returned by stat function
+ *
+ * Returns 0 on success, and < 0 on error.
+ */
+_hidden int libxl__try_phy_backend(mode_t st_mode);
+
 /* from libxl_pci */
 
 _hidden int libxl__device_pci_add(libxl__gc *gc, uint32_t domid, libxl_device_pci *pcidev, int starting);
diff -r 8e129474fc0a -r 1d1fc97535c2 tools/libxl/libxl_linux.c
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/tools/libxl/libxl_linux.c	Fri Sep 30 14:38:55 2011 +0200
@@ -0,0 +1,27 @@
+/*
+ * Copyright (C) 2011
+ * Author Roger Pau Monne <roger.pau@entel.upc.edu>
+ *
+ * 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 <sys/stat.h>
+
+#include "libxl_internal.h"
+ 
+int libxl__try_phy_backend(mode_t st_mode)
+{
+    if (!S_ISBLK(st_mode)) {
+        return 0;
+    }
+
+    return 1;
+}
diff -r 8e129474fc0a -r 1d1fc97535c2 tools/libxl/libxl_netbsd.c
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/tools/libxl/libxl_netbsd.c	Fri Sep 30 14:38:55 2011 +0200
@@ -0,0 +1,26 @@
+/*
+ * Copyright (C) 2011
+ * Author Roger Pau Monne <roger.pau@entel.upc.edu>
+ *
+ * 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 <sys/stat.h>
+
+#include "libxl_internal.h"
+
+int libxl__try_phy_backend(mode_t st_mode)
+{
+    if (S_ISREG(st_mode) || S_ISBLK(st_mode))
+        return 1;
+
+    return 0;
+}

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 15:17:32 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 15:17:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbD3d-0003fl-K0; Thu, 15 Dec 2011 15:17:17 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RbD3c-0003eZ-1N
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 15:17:16 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1323962229!7357491!1
X-Originating-IP: [209.85.161.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8426 invoked from network); 15 Dec 2011 15:17:09 -0000
Received: from mail-fx0-f43.google.com (HELO mail-fx0-f43.google.com)
	(209.85.161.43)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 15:17:09 -0000
Received: by faap21 with SMTP id p21so5275311faa.30
	for <xen-devel@lists.xensource.com>;
	Thu, 15 Dec 2011 07:17:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=IQBkexYFG6AWbSP8RRO0WRhxHe/NTU2e1ejh/NoqXWM=;
	b=qQBjq6gh3Dg31PXtX7JjzqDiMR1qYi5kfzkxr0ZvYkjLC71NTl2TWc9VugjkScq5Eo
	z1ZlpMaWe+rgHSmYuMQahEVfeMcOfGYvjvrm4FvIwcypZ28NRDsoGvcdfVjJ6I2DLOis
	OnCeZhTr2GpPo4shgDr20nxecQ2UWMShb4Wds=
Received: by 10.180.91.137 with SMTP id ce9mr6092887wib.5.1323962229164;
	Thu, 15 Dec 2011 07:17:09 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id hb10sm8693212wib.16.2011.12.15.07.17.07
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 15 Dec 2011 07:17:07 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 1d1fc97535c2790731e7afbc4c891f7ef6167983
Message-Id: <1d1fc97535c2790731e7.1323961636@loki.upc.es>
In-Reply-To: <patchbomb.1323961634@loki.upc.es>
References: <patchbomb.1323961634@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Thu, 15 Dec 2011 16:07:16 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 02 of 15 v5] libxl: add support for image files
	for NetBSD
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1317386335 -7200
# Node ID 1d1fc97535c2790731e7afbc4c891f7ef6167983
# Parent  8e129474fc0ac87623ba814ea865326d45cb8436
libxl: add support for image files for NetBSD

Created a helper function to detect if the OS is capable of using
image files as phy backends. Create two OS specific files, and
changed the Makefile to choose the correct one at compile time.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 8e129474fc0a -r 1d1fc97535c2 tools/libxl/Makefile
--- a/tools/libxl/Makefile	Fri Sep 30 14:38:55 2011 +0200
+++ b/tools/libxl/Makefile	Fri Sep 30 14:38:55 2011 +0200
@@ -33,6 +33,15 @@ endif
 LIBXL_OBJS-$(CONFIG_X86) += libxl_cpuid.o
 LIBXL_OBJS-$(CONFIG_IA64) += libxl_nocpuid.o
 
+ifeq ($(CONFIG_NetBSD),y)
+LIBXL_OBJS-y += libxl_netbsd.o
+else ifeq ($(CONFIG_Linux),y)
+LIBXL_OBJS-y += libxl_linux.o
+else
+$(error Your Operating System is not supported by libxenlight, \
+please check libxl_linux.c and libxl_netbsd.c to see how to get it ported)
+endif
+
 LIBXL_LIBS += -lyajl
 
 LIBXL_OBJS = flexarray.o libxl.o libxl_create.o libxl_dm.o libxl_pci.o \
diff -r 8e129474fc0a -r 1d1fc97535c2 tools/libxl/libxl_device.c
--- a/tools/libxl/libxl_device.c	Fri Sep 30 14:38:55 2011 +0200
+++ b/tools/libxl/libxl_device.c	Fri Sep 30 14:38:55 2011 +0200
@@ -137,15 +137,14 @@ static int disk_try_backend(disk_try_bac
               a->disk->format == LIBXL_DISK_FORMAT_EMPTY)) {
             goto bad_format;
         }
-        if (a->disk->format != LIBXL_DISK_FORMAT_EMPTY &&
-            !S_ISBLK(a->stab.st_mode)) {
-            LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Disk vdev=%s, backend phy"
-                       " unsuitable as phys path not a block device",
-                       a->disk->vdev);
-            return 0;
-        }
 
-        return backend;
+        if (libxl__try_phy_backend(a->stab.st_mode))
+            return backend;
+
+        LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Disk vdev=%s, backend phy"
+                   " unsuitable as phys path not a block device",
+                   a->disk->vdev);
+        return 0;
 
     case LIBXL_DISK_BACKEND_TAP:
         if (!libxl__blktap_enabled(a->gc)) {
diff -r 8e129474fc0a -r 1d1fc97535c2 tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Fri Sep 30 14:38:55 2011 +0200
+++ b/tools/libxl/libxl_internal.h	Fri Sep 30 14:38:55 2011 +0200
@@ -271,6 +271,15 @@ _hidden int libxl__device_destroy(libxl_
 _hidden int libxl__devices_destroy(libxl__gc *gc, uint32_t domid, int force);
 _hidden int libxl__wait_for_backend(libxl__gc *gc, char *be_path, char *state);
 
+/*
+ * libxl__try_phy_backend - Check if there's support for the passed
+ * type of file using the PHY backend
+ * st_mode: mode_t of the file, as returned by stat function
+ *
+ * Returns 0 on success, and < 0 on error.
+ */
+_hidden int libxl__try_phy_backend(mode_t st_mode);
+
 /* from libxl_pci */
 
 _hidden int libxl__device_pci_add(libxl__gc *gc, uint32_t domid, libxl_device_pci *pcidev, int starting);
diff -r 8e129474fc0a -r 1d1fc97535c2 tools/libxl/libxl_linux.c
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/tools/libxl/libxl_linux.c	Fri Sep 30 14:38:55 2011 +0200
@@ -0,0 +1,27 @@
+/*
+ * Copyright (C) 2011
+ * Author Roger Pau Monne <roger.pau@entel.upc.edu>
+ *
+ * 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 <sys/stat.h>
+
+#include "libxl_internal.h"
+ 
+int libxl__try_phy_backend(mode_t st_mode)
+{
+    if (!S_ISBLK(st_mode)) {
+        return 0;
+    }
+
+    return 1;
+}
diff -r 8e129474fc0a -r 1d1fc97535c2 tools/libxl/libxl_netbsd.c
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/tools/libxl/libxl_netbsd.c	Fri Sep 30 14:38:55 2011 +0200
@@ -0,0 +1,26 @@
+/*
+ * Copyright (C) 2011
+ * Author Roger Pau Monne <roger.pau@entel.upc.edu>
+ *
+ * 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 <sys/stat.h>
+
+#include "libxl_internal.h"
+
+int libxl__try_phy_backend(mode_t st_mode)
+{
+    if (S_ISREG(st_mode) || S_ISBLK(st_mode))
+        return 1;
+
+    return 0;
+}

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 15:17:34 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 15:17:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbD3o-0003kR-FP; Thu, 15 Dec 2011 15:17:28 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RbD3n-0003gt-30
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 15:17:27 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1323962239!5660032!1
X-Originating-IP: [74.125.82.41]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24655 invoked from network); 15 Dec 2011 15:17:19 -0000
Received: from mail-ww0-f41.google.com (HELO mail-ww0-f41.google.com)
	(74.125.82.41)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 15:17:19 -0000
Received: by wgbdt12 with SMTP id dt12so1448524wgb.0
	for <xen-devel@lists.xensource.com>;
	Thu, 15 Dec 2011 07:17:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=zVsdRBd3IvT/t1ziUMlakGwOm5LzG0HPjMUAMKtPzDo=;
	b=AKScrX2gcIesOuk3IqN82x8THZ+Q7aztktk+xglxkbibEzpC9W1dn9g1A7D68rg15r
	n6JW37kfxusYu66weGQQvf4s0zhk7MrmJsrLcWR5bdw4H1wQU4dub5tWiXJfC/PTRS4j
	sb2YYWFroYEYBiACI+59ZkqBnc2KzuzXADacY=
Received: by 10.216.134.149 with SMTP id s21mr1451668wei.41.1323962238784;
	Thu, 15 Dec 2011 07:17:18 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id hb10sm8693212wib.16.2011.12.15.07.17.16
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 15 Dec 2011 07:17:17 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 7b68b9415745c8bff5d0148bbf3953f6f083e655
Message-Id: <7b68b9415745c8bff5d0.1323961640@loki.upc.es>
In-Reply-To: <patchbomb.1323961634@loki.upc.es>
References: <patchbomb.1323961634@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Thu, 15 Dec 2011 16:07:20 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 06 of 15 v5] hotplug NetBSD: pass an action
 instead of a state to hotplug scripts
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1323864490 -3600
# Node ID 7b68b9415745c8bff5d0148bbf3953f6f083e655
# Parent  08a9f86b79dfe5db150392c916a72bafc3f05137
hotplug NetBSD: pass an action instead of a state to hotplug scripts

change second parameter of NetBSD hotplug scripts to take an action
(CONNECT/DISCONNECT) instead of a xenbus state. This patch also
changes the behaviour of xenbackend to pass an action instead of a
state.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 08a9f86b79df -r 7b68b9415745 tools/hotplug/NetBSD/block
--- a/tools/hotplug/NetBSD/block	Wed Dec 14 13:08:10 2011 +0100
+++ b/tools/hotplug/NetBSD/block	Wed Dec 14 13:08:10 2011 +0100
@@ -18,7 +18,7 @@ error() {
 	
 
 xpath=$1
-xstatus=$2
+xaction=$2
 xparams=$(xenstore-read "$xpath/params")
 
 if [ -f $xparams ]; then
@@ -27,8 +27,8 @@ else
 	xtype="phy"
 fi
 
-case $xstatus in
-6)
+case $xaction in
+2)
 	# device removed
 	case $xtype in
 	file)
@@ -46,7 +46,7 @@ 6)
 	xenstore-rm $xpath
 	exit 0
 	;;
-2)
+1)
 	case $xtype in
 	file)
 		# Store the list of available vnd(4) devices in
diff -r 08a9f86b79df -r 7b68b9415745 tools/hotplug/NetBSD/vif-bridge
--- a/tools/hotplug/NetBSD/vif-bridge	Wed Dec 14 13:08:10 2011 +0100
+++ b/tools/hotplug/NetBSD/vif-bridge	Wed Dec 14 13:08:10 2011 +0100
@@ -11,15 +11,15 @@ PATH=${BINDIR}:${SBINDIR}:${LIBEXEC}:${P
 export PATH
 
 xpath=$1
-xstatus=$2
+xaction=$2
 
-case $xstatus in
-6)
+case $xaction in
+2)
 	# device removed
 	xenstore-rm $xpath
 	exit 0
 	;;
-2)
+1)
 	xbridge=$(xenstore-read "$xpath/bridge")
 	xfid=$(xenstore-read "$xpath/frontend-id")
 	xhandle=$(xenstore-read "$xpath/handle")
diff -r 08a9f86b79df -r 7b68b9415745 tools/hotplug/NetBSD/vif-ip
--- a/tools/hotplug/NetBSD/vif-ip	Wed Dec 14 13:08:10 2011 +0100
+++ b/tools/hotplug/NetBSD/vif-ip	Wed Dec 14 13:08:10 2011 +0100
@@ -11,15 +11,15 @@ PATH=${BINDIR}:${SBINDIR}:${LIBEXEC}:${P
 export PATH
 
 xpath=$1
-xstatus=$2
+xaction=$2
 
-case $xstatus in
-6)
+case $xaction in
+2)
 	# device removed
 	xenstore-rm $xpath
 	exit 0
 	;;
-2)
+1)
 	xip=$(xenstore-read "$xpath/ip")
 	xfid=$(xenstore-read "$xpath/frontend-id")
 	xhandle=$(xenstore-read "$xpath/handle")
diff -r 08a9f86b79df -r 7b68b9415745 tools/xenbackendd/xenbackendd.c
--- a/tools/xenbackendd/xenbackendd.c	Wed Dec 14 13:08:10 2011 +0100
+++ b/tools/xenbackendd/xenbackendd.c	Wed Dec 14 13:08:10 2011 +0100
@@ -34,6 +34,9 @@
 #define DEVTYPE_VIF 1
 #define DEVTYPE_VBD 2
 
+#define CONNECT "1"
+#define DISCONNECT "2"
+
 #define DOMAIN_PATH "/local/domain/0"
 
 #ifndef XEN_SCRIPT_DIR
@@ -149,6 +152,7 @@ main(int argc, char * const argv[])
 	unsigned int num;
 	char *s;
 	int state;
+	char *action;
 	char *sstate;
 	char *p;
 	char buf[80];
@@ -297,11 +301,13 @@ main(int argc, char * const argv[])
 				    strerror(errno));
 				goto next2;
 			}
-			doexec(s, vec[XS_WATCH_PATH], sstate);
+			action = (state == 6 ? DISCONNECT : CONNECT);
+			doexec(s, vec[XS_WATCH_PATH], action);
 			break;
 
 		case DEVTYPE_VBD:
-			doexec(vbd_script, vec[XS_WATCH_PATH], sstate);
+			action = (state == 6 ? DISCONNECT : CONNECT);
+			doexec(vbd_script, vec[XS_WATCH_PATH], action);
 			break;
 
 		default:

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 15:17:34 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 15:17:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbD3o-0003kR-FP; Thu, 15 Dec 2011 15:17:28 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RbD3n-0003gt-30
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 15:17:27 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1323962239!5660032!1
X-Originating-IP: [74.125.82.41]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24655 invoked from network); 15 Dec 2011 15:17:19 -0000
Received: from mail-ww0-f41.google.com (HELO mail-ww0-f41.google.com)
	(74.125.82.41)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 15:17:19 -0000
Received: by wgbdt12 with SMTP id dt12so1448524wgb.0
	for <xen-devel@lists.xensource.com>;
	Thu, 15 Dec 2011 07:17:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=zVsdRBd3IvT/t1ziUMlakGwOm5LzG0HPjMUAMKtPzDo=;
	b=AKScrX2gcIesOuk3IqN82x8THZ+Q7aztktk+xglxkbibEzpC9W1dn9g1A7D68rg15r
	n6JW37kfxusYu66weGQQvf4s0zhk7MrmJsrLcWR5bdw4H1wQU4dub5tWiXJfC/PTRS4j
	sb2YYWFroYEYBiACI+59ZkqBnc2KzuzXADacY=
Received: by 10.216.134.149 with SMTP id s21mr1451668wei.41.1323962238784;
	Thu, 15 Dec 2011 07:17:18 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id hb10sm8693212wib.16.2011.12.15.07.17.16
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 15 Dec 2011 07:17:17 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 7b68b9415745c8bff5d0148bbf3953f6f083e655
Message-Id: <7b68b9415745c8bff5d0.1323961640@loki.upc.es>
In-Reply-To: <patchbomb.1323961634@loki.upc.es>
References: <patchbomb.1323961634@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Thu, 15 Dec 2011 16:07:20 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 06 of 15 v5] hotplug NetBSD: pass an action
 instead of a state to hotplug scripts
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1323864490 -3600
# Node ID 7b68b9415745c8bff5d0148bbf3953f6f083e655
# Parent  08a9f86b79dfe5db150392c916a72bafc3f05137
hotplug NetBSD: pass an action instead of a state to hotplug scripts

change second parameter of NetBSD hotplug scripts to take an action
(CONNECT/DISCONNECT) instead of a xenbus state. This patch also
changes the behaviour of xenbackend to pass an action instead of a
state.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 08a9f86b79df -r 7b68b9415745 tools/hotplug/NetBSD/block
--- a/tools/hotplug/NetBSD/block	Wed Dec 14 13:08:10 2011 +0100
+++ b/tools/hotplug/NetBSD/block	Wed Dec 14 13:08:10 2011 +0100
@@ -18,7 +18,7 @@ error() {
 	
 
 xpath=$1
-xstatus=$2
+xaction=$2
 xparams=$(xenstore-read "$xpath/params")
 
 if [ -f $xparams ]; then
@@ -27,8 +27,8 @@ else
 	xtype="phy"
 fi
 
-case $xstatus in
-6)
+case $xaction in
+2)
 	# device removed
 	case $xtype in
 	file)
@@ -46,7 +46,7 @@ 6)
 	xenstore-rm $xpath
 	exit 0
 	;;
-2)
+1)
 	case $xtype in
 	file)
 		# Store the list of available vnd(4) devices in
diff -r 08a9f86b79df -r 7b68b9415745 tools/hotplug/NetBSD/vif-bridge
--- a/tools/hotplug/NetBSD/vif-bridge	Wed Dec 14 13:08:10 2011 +0100
+++ b/tools/hotplug/NetBSD/vif-bridge	Wed Dec 14 13:08:10 2011 +0100
@@ -11,15 +11,15 @@ PATH=${BINDIR}:${SBINDIR}:${LIBEXEC}:${P
 export PATH
 
 xpath=$1
-xstatus=$2
+xaction=$2
 
-case $xstatus in
-6)
+case $xaction in
+2)
 	# device removed
 	xenstore-rm $xpath
 	exit 0
 	;;
-2)
+1)
 	xbridge=$(xenstore-read "$xpath/bridge")
 	xfid=$(xenstore-read "$xpath/frontend-id")
 	xhandle=$(xenstore-read "$xpath/handle")
diff -r 08a9f86b79df -r 7b68b9415745 tools/hotplug/NetBSD/vif-ip
--- a/tools/hotplug/NetBSD/vif-ip	Wed Dec 14 13:08:10 2011 +0100
+++ b/tools/hotplug/NetBSD/vif-ip	Wed Dec 14 13:08:10 2011 +0100
@@ -11,15 +11,15 @@ PATH=${BINDIR}:${SBINDIR}:${LIBEXEC}:${P
 export PATH
 
 xpath=$1
-xstatus=$2
+xaction=$2
 
-case $xstatus in
-6)
+case $xaction in
+2)
 	# device removed
 	xenstore-rm $xpath
 	exit 0
 	;;
-2)
+1)
 	xip=$(xenstore-read "$xpath/ip")
 	xfid=$(xenstore-read "$xpath/frontend-id")
 	xhandle=$(xenstore-read "$xpath/handle")
diff -r 08a9f86b79df -r 7b68b9415745 tools/xenbackendd/xenbackendd.c
--- a/tools/xenbackendd/xenbackendd.c	Wed Dec 14 13:08:10 2011 +0100
+++ b/tools/xenbackendd/xenbackendd.c	Wed Dec 14 13:08:10 2011 +0100
@@ -34,6 +34,9 @@
 #define DEVTYPE_VIF 1
 #define DEVTYPE_VBD 2
 
+#define CONNECT "1"
+#define DISCONNECT "2"
+
 #define DOMAIN_PATH "/local/domain/0"
 
 #ifndef XEN_SCRIPT_DIR
@@ -149,6 +152,7 @@ main(int argc, char * const argv[])
 	unsigned int num;
 	char *s;
 	int state;
+	char *action;
 	char *sstate;
 	char *p;
 	char buf[80];
@@ -297,11 +301,13 @@ main(int argc, char * const argv[])
 				    strerror(errno));
 				goto next2;
 			}
-			doexec(s, vec[XS_WATCH_PATH], sstate);
+			action = (state == 6 ? DISCONNECT : CONNECT);
+			doexec(s, vec[XS_WATCH_PATH], action);
 			break;
 
 		case DEVTYPE_VBD:
-			doexec(vbd_script, vec[XS_WATCH_PATH], sstate);
+			action = (state == 6 ? DISCONNECT : CONNECT);
+			doexec(vbd_script, vec[XS_WATCH_PATH], action);
 			break;
 
 		default:

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 15:17:35 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 15:17:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbD3r-0003nd-U9; Thu, 15 Dec 2011 15:17:31 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RbD3p-0003iX-Ra
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 15:17:30 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1323962225!7409341!4
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7358 invoked from network); 15 Dec 2011 15:17:23 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 15:17:23 -0000
Received: by mail-ww0-f43.google.com with SMTP id ds11so3581748wgb.24
	for <xen-devel@lists.xensource.com>;
	Thu, 15 Dec 2011 07:17:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=7BrHMgoEUkucWjD+oyEhr3p1e6Lmf07PdH3dPFxCmeA=;
	b=IL5GzZ02fzDjdjy/wCyXg3WxSy2ivgvgOzMHHA+pYAIdh03pIipL5v2zx0TFX8Fv1s
	AAiuSaCa3BrneCYf4DrQ2pLcdEvhnLqvwuipYUiF/3XckxbTYTMW/9IRcJ6J/IhmP/cs
	UPdqJpPigTyvCELCYSwWLSzfkgR/rbJQbBhhw=
Received: by 10.227.198.142 with SMTP id eo14mr2567350wbb.28.1323962243462;
	Thu, 15 Dec 2011 07:17:23 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id hb10sm8693212wib.16.2011.12.15.07.17.18
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 15 Dec 2011 07:17:19 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 1cdbc9b053598abd01cdd039118c07609deeff1a
Message-Id: <1cdbc9b053598abd01cd.1323961641@loki.upc.es>
In-Reply-To: <patchbomb.1323961634@loki.upc.es>
References: <patchbomb.1323961634@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Thu, 15 Dec 2011 16:07:21 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 07 of 15 v5] libxl: execute hotplug scripts
	directly from libxl
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1317386335 -7200
# Node ID 1cdbc9b053598abd01cdd039118c07609deeff1a
# Parent  7b68b9415745c8bff5d0148bbf3953f6f083e655
libxl: execute hotplug scripts directly from libxl.

Added the necessary handlers to execute hotplug scripts when necessary
from libxl. Split NetBSD and Linux hotplug calls into two separate
files, because parameters for hotplug scripts are different. Linux
has empty functions, since the calling of hotplug scripts is still
done using udev.

Hotplug scripts in NetBSD are in charge of adding the virtual DomU
network interface to the desired bridge and also mount the vnd device
to use virtual images as block devices. The following scripts are
currently implemented:

 * block: executed when a vbd is used, is in charge mounting the
   virtual image to the vnd device and setting the state of xenstore
   to 4 (connected). When using a physical partition, the script only
   sets the state to 4.

 * vif-bridge: adds the virtual DomU interface to the desired bridge.

 * vif-ip: configures the physical network interface assigned to the
   DomU.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 7b68b9415745 -r 1cdbc9b05359 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Wed Dec 14 13:08:10 2011 +0100
+++ b/tools/libxl/libxl.c	Fri Sep 30 14:38:55 2011 +0200
@@ -1023,6 +1023,11 @@ int libxl_device_disk_add(libxl_ctx *ctx
             flexarray_append(back, "params");
             flexarray_append(back, dev);
 
+            flexarray_append(back, "script");
+            flexarray_append(back, libxl__sprintf(gc, "%s/%s",
+                                                  libxl_xen_script_dir_path(),
+                                                  "block"));
+
             assert(device.backend_kind == LIBXL__DEVICE_KIND_VBD);
             break;
         case LIBXL_DISK_BACKEND_TAP:
@@ -1099,6 +1104,16 @@ int libxl_device_disk_add(libxl_ctx *ctx
             goto out_free;
         }
     }
+
+    /* Call hotplug scripts to attach device */
+    if (libxl__device_hotplug(gc, &device, CONNECT) < 0) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
+                   "unable to execute hotplug script for disk: %s\n",
+                   disk->pdev_path);
+        rc = -1;
+        goto out_free;
+    }
+
     rc = 0;
 
 out_free:
@@ -1561,6 +1576,16 @@ int libxl_device_nic_add(libxl_ctx *ctx,
             goto out_free;
         }
     }
+
+    /* Call hotplug scripts to attach device */
+    if (libxl__device_hotplug(gc, &device, CONNECT) < 0) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
+                   "unable to execute hotplug script for nic: %s\n",
+                   nic->ifname);
+        rc = -1;
+        goto out_free;
+    }
+
     rc = 0;
 
 out_free:
diff -r 7b68b9415745 -r 1cdbc9b05359 tools/libxl/libxl_device.c
--- a/tools/libxl/libxl_device.c	Wed Dec 14 13:08:10 2011 +0100
+++ b/tools/libxl/libxl_device.c	Fri Sep 30 14:38:55 2011 +0200
@@ -448,6 +448,7 @@ int libxl__device_remove(libxl__gc *gc, 
     if (!state)
         goto out;
     if (atoi(state) != 4) {
+        libxl__device_hotplug(gc, dev, DISCONNECT);
         libxl__device_destroy_tapdisk(gc, be_path);
         xs_rm(ctx->xsh, XBT_NULL, be_path);
         goto out;
@@ -492,6 +493,12 @@ int libxl__device_destroy(libxl__gc *gc,
     char *be_path = libxl__device_backend_path(gc, dev);
     char *fe_path = libxl__device_frontend_path(gc, dev);
 
+    /* 
+     * Run hotplug scripts, which will probably not be able to
+     * execute successfully since the device may still be plugged
+     */
+    libxl__device_hotplug(gc, dev, DISCONNECT);
+
     xs_rm(ctx->xsh, XBT_NULL, be_path);
     xs_rm(ctx->xsh, XBT_NULL, fe_path);
 
diff -r 7b68b9415745 -r 1cdbc9b05359 tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Wed Dec 14 13:08:10 2011 +0100
+++ b/tools/libxl/libxl_internal.h	Fri Sep 30 14:38:55 2011 +0200
@@ -308,6 +308,25 @@ _hidden int libxl__wait_for_device_state
  */
 _hidden int libxl__try_phy_backend(mode_t st_mode);
 
+/* hotplug functions */
+
+/* Action to pass to hotplug caller functions */
+typedef enum {
+    CONNECT = 1,
+    DISCONNECT = 2
+} libxl__hotplug_action;
+
+/*
+ * libxl__device_hotplug - generic function to execute hotplug scripts
+ * gc: allocation pool
+ * dev: reference to the device that executes the hotplug scripts
+ * action: action to execute
+ *
+ * Returns 0 on success, and < 0 on error.
+ */
+_hidden int libxl__device_hotplug(libxl__gc *gc, libxl__device *dev,
+                                  libxl__hotplug_action action);
+
 /* from libxl_pci */
 
 _hidden int libxl__device_pci_add(libxl__gc *gc, uint32_t domid, libxl_device_pci *pcidev, int starting);
diff -r 7b68b9415745 -r 1cdbc9b05359 tools/libxl/libxl_linux.c
--- a/tools/libxl/libxl_linux.c	Wed Dec 14 13:08:10 2011 +0100
+++ b/tools/libxl/libxl_linux.c	Fri Sep 30 14:38:55 2011 +0200
@@ -25,3 +25,11 @@ int libxl__try_phy_backend(mode_t st_mod
 
     return 1;
 }
+
+/* Hotplug scripts caller functions */
+
+int libxl_device_hotplug(libxl__gc *gc, libxl__device *dev,
+                         libxl__hotplug_action action)
+{
+    return 0;
+}
diff -r 7b68b9415745 -r 1cdbc9b05359 tools/libxl/libxl_netbsd.c
--- a/tools/libxl/libxl_netbsd.c	Wed Dec 14 13:08:10 2011 +0100
+++ b/tools/libxl/libxl_netbsd.c	Fri Sep 30 14:38:55 2011 +0200
@@ -14,6 +14,7 @@
  */
  
 #include <sys/stat.h>
+#include <sys/wait.h>
 
 #include "libxl_internal.h"
 
@@ -24,3 +25,56 @@ int libxl__try_phy_backend(mode_t st_mod
 
     return 0;
 }
+
+/* Hotplug scripts call function */
+
+int libxl__device_hotplug(libxl__gc *gc, libxl__device *dev,
+                          libxl__hotplug_action action)
+{
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+    char *be_path = libxl__device_backend_path(gc, dev);
+    char *script, *what;
+    char **args;
+    int status, nr = 0;
+    int rc = -1;
+    flexarray_t *f_args;
+
+    if (dev->kind != LIBXL__DEVICE_KIND_VIF &&
+        dev->kind != LIBXL__DEVICE_KIND_VBD)
+        return 0;
+
+    script = libxl__xs_read(gc, XBT_NULL,
+                            libxl__sprintf(gc, "%s/%s", be_path, "script"));
+    if (!script) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Unable to read script from %s",
+                                          be_path);
+        return -1;
+    }
+
+    f_args = flexarray_make(4, 1);
+    if (!f_args)
+        return -1;
+
+    flexarray_set(f_args, nr++, script);
+    flexarray_set(f_args, nr++, be_path);
+    flexarray_set(f_args, nr++, libxl__sprintf(gc, "%d", action));
+    flexarray_set(f_args, nr++, NULL);
+
+    args = (char **) flexarray_contents(f_args);
+
+    what = libxl__sprintf(gc, "%s %s", args[0],
+                          action == CONNECT ? "connect" : "disconnect");
+    LIBXL__LOG(ctx, LIBXL__LOG_DEBUG,
+               "Calling hotplug script: %s %s %s",
+               args[0], args[1], args[2]);
+    status = libxl__forkexec(gc, -1, -1, -1, args[0], args, what);
+    if (status) {
+        rc = -1;
+        goto out;
+    }
+    rc = 0;
+
+out:
+    free(args);
+    return rc;
+}

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 15:17:35 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 15:17:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbD3r-0003nd-U9; Thu, 15 Dec 2011 15:17:31 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RbD3p-0003iX-Ra
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 15:17:30 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1323962225!7409341!4
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7358 invoked from network); 15 Dec 2011 15:17:23 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 15:17:23 -0000
Received: by mail-ww0-f43.google.com with SMTP id ds11so3581748wgb.24
	for <xen-devel@lists.xensource.com>;
	Thu, 15 Dec 2011 07:17:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=7BrHMgoEUkucWjD+oyEhr3p1e6Lmf07PdH3dPFxCmeA=;
	b=IL5GzZ02fzDjdjy/wCyXg3WxSy2ivgvgOzMHHA+pYAIdh03pIipL5v2zx0TFX8Fv1s
	AAiuSaCa3BrneCYf4DrQ2pLcdEvhnLqvwuipYUiF/3XckxbTYTMW/9IRcJ6J/IhmP/cs
	UPdqJpPigTyvCELCYSwWLSzfkgR/rbJQbBhhw=
Received: by 10.227.198.142 with SMTP id eo14mr2567350wbb.28.1323962243462;
	Thu, 15 Dec 2011 07:17:23 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id hb10sm8693212wib.16.2011.12.15.07.17.18
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 15 Dec 2011 07:17:19 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 1cdbc9b053598abd01cdd039118c07609deeff1a
Message-Id: <1cdbc9b053598abd01cd.1323961641@loki.upc.es>
In-Reply-To: <patchbomb.1323961634@loki.upc.es>
References: <patchbomb.1323961634@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Thu, 15 Dec 2011 16:07:21 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 07 of 15 v5] libxl: execute hotplug scripts
	directly from libxl
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1317386335 -7200
# Node ID 1cdbc9b053598abd01cdd039118c07609deeff1a
# Parent  7b68b9415745c8bff5d0148bbf3953f6f083e655
libxl: execute hotplug scripts directly from libxl.

Added the necessary handlers to execute hotplug scripts when necessary
from libxl. Split NetBSD and Linux hotplug calls into two separate
files, because parameters for hotplug scripts are different. Linux
has empty functions, since the calling of hotplug scripts is still
done using udev.

Hotplug scripts in NetBSD are in charge of adding the virtual DomU
network interface to the desired bridge and also mount the vnd device
to use virtual images as block devices. The following scripts are
currently implemented:

 * block: executed when a vbd is used, is in charge mounting the
   virtual image to the vnd device and setting the state of xenstore
   to 4 (connected). When using a physical partition, the script only
   sets the state to 4.

 * vif-bridge: adds the virtual DomU interface to the desired bridge.

 * vif-ip: configures the physical network interface assigned to the
   DomU.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 7b68b9415745 -r 1cdbc9b05359 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Wed Dec 14 13:08:10 2011 +0100
+++ b/tools/libxl/libxl.c	Fri Sep 30 14:38:55 2011 +0200
@@ -1023,6 +1023,11 @@ int libxl_device_disk_add(libxl_ctx *ctx
             flexarray_append(back, "params");
             flexarray_append(back, dev);
 
+            flexarray_append(back, "script");
+            flexarray_append(back, libxl__sprintf(gc, "%s/%s",
+                                                  libxl_xen_script_dir_path(),
+                                                  "block"));
+
             assert(device.backend_kind == LIBXL__DEVICE_KIND_VBD);
             break;
         case LIBXL_DISK_BACKEND_TAP:
@@ -1099,6 +1104,16 @@ int libxl_device_disk_add(libxl_ctx *ctx
             goto out_free;
         }
     }
+
+    /* Call hotplug scripts to attach device */
+    if (libxl__device_hotplug(gc, &device, CONNECT) < 0) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
+                   "unable to execute hotplug script for disk: %s\n",
+                   disk->pdev_path);
+        rc = -1;
+        goto out_free;
+    }
+
     rc = 0;
 
 out_free:
@@ -1561,6 +1576,16 @@ int libxl_device_nic_add(libxl_ctx *ctx,
             goto out_free;
         }
     }
+
+    /* Call hotplug scripts to attach device */
+    if (libxl__device_hotplug(gc, &device, CONNECT) < 0) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
+                   "unable to execute hotplug script for nic: %s\n",
+                   nic->ifname);
+        rc = -1;
+        goto out_free;
+    }
+
     rc = 0;
 
 out_free:
diff -r 7b68b9415745 -r 1cdbc9b05359 tools/libxl/libxl_device.c
--- a/tools/libxl/libxl_device.c	Wed Dec 14 13:08:10 2011 +0100
+++ b/tools/libxl/libxl_device.c	Fri Sep 30 14:38:55 2011 +0200
@@ -448,6 +448,7 @@ int libxl__device_remove(libxl__gc *gc, 
     if (!state)
         goto out;
     if (atoi(state) != 4) {
+        libxl__device_hotplug(gc, dev, DISCONNECT);
         libxl__device_destroy_tapdisk(gc, be_path);
         xs_rm(ctx->xsh, XBT_NULL, be_path);
         goto out;
@@ -492,6 +493,12 @@ int libxl__device_destroy(libxl__gc *gc,
     char *be_path = libxl__device_backend_path(gc, dev);
     char *fe_path = libxl__device_frontend_path(gc, dev);
 
+    /* 
+     * Run hotplug scripts, which will probably not be able to
+     * execute successfully since the device may still be plugged
+     */
+    libxl__device_hotplug(gc, dev, DISCONNECT);
+
     xs_rm(ctx->xsh, XBT_NULL, be_path);
     xs_rm(ctx->xsh, XBT_NULL, fe_path);
 
diff -r 7b68b9415745 -r 1cdbc9b05359 tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Wed Dec 14 13:08:10 2011 +0100
+++ b/tools/libxl/libxl_internal.h	Fri Sep 30 14:38:55 2011 +0200
@@ -308,6 +308,25 @@ _hidden int libxl__wait_for_device_state
  */
 _hidden int libxl__try_phy_backend(mode_t st_mode);
 
+/* hotplug functions */
+
+/* Action to pass to hotplug caller functions */
+typedef enum {
+    CONNECT = 1,
+    DISCONNECT = 2
+} libxl__hotplug_action;
+
+/*
+ * libxl__device_hotplug - generic function to execute hotplug scripts
+ * gc: allocation pool
+ * dev: reference to the device that executes the hotplug scripts
+ * action: action to execute
+ *
+ * Returns 0 on success, and < 0 on error.
+ */
+_hidden int libxl__device_hotplug(libxl__gc *gc, libxl__device *dev,
+                                  libxl__hotplug_action action);
+
 /* from libxl_pci */
 
 _hidden int libxl__device_pci_add(libxl__gc *gc, uint32_t domid, libxl_device_pci *pcidev, int starting);
diff -r 7b68b9415745 -r 1cdbc9b05359 tools/libxl/libxl_linux.c
--- a/tools/libxl/libxl_linux.c	Wed Dec 14 13:08:10 2011 +0100
+++ b/tools/libxl/libxl_linux.c	Fri Sep 30 14:38:55 2011 +0200
@@ -25,3 +25,11 @@ int libxl__try_phy_backend(mode_t st_mod
 
     return 1;
 }
+
+/* Hotplug scripts caller functions */
+
+int libxl_device_hotplug(libxl__gc *gc, libxl__device *dev,
+                         libxl__hotplug_action action)
+{
+    return 0;
+}
diff -r 7b68b9415745 -r 1cdbc9b05359 tools/libxl/libxl_netbsd.c
--- a/tools/libxl/libxl_netbsd.c	Wed Dec 14 13:08:10 2011 +0100
+++ b/tools/libxl/libxl_netbsd.c	Fri Sep 30 14:38:55 2011 +0200
@@ -14,6 +14,7 @@
  */
  
 #include <sys/stat.h>
+#include <sys/wait.h>
 
 #include "libxl_internal.h"
 
@@ -24,3 +25,56 @@ int libxl__try_phy_backend(mode_t st_mod
 
     return 0;
 }
+
+/* Hotplug scripts call function */
+
+int libxl__device_hotplug(libxl__gc *gc, libxl__device *dev,
+                          libxl__hotplug_action action)
+{
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+    char *be_path = libxl__device_backend_path(gc, dev);
+    char *script, *what;
+    char **args;
+    int status, nr = 0;
+    int rc = -1;
+    flexarray_t *f_args;
+
+    if (dev->kind != LIBXL__DEVICE_KIND_VIF &&
+        dev->kind != LIBXL__DEVICE_KIND_VBD)
+        return 0;
+
+    script = libxl__xs_read(gc, XBT_NULL,
+                            libxl__sprintf(gc, "%s/%s", be_path, "script"));
+    if (!script) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Unable to read script from %s",
+                                          be_path);
+        return -1;
+    }
+
+    f_args = flexarray_make(4, 1);
+    if (!f_args)
+        return -1;
+
+    flexarray_set(f_args, nr++, script);
+    flexarray_set(f_args, nr++, be_path);
+    flexarray_set(f_args, nr++, libxl__sprintf(gc, "%d", action));
+    flexarray_set(f_args, nr++, NULL);
+
+    args = (char **) flexarray_contents(f_args);
+
+    what = libxl__sprintf(gc, "%s %s", args[0],
+                          action == CONNECT ? "connect" : "disconnect");
+    LIBXL__LOG(ctx, LIBXL__LOG_DEBUG,
+               "Calling hotplug script: %s %s %s",
+               args[0], args[1], args[2]);
+    status = libxl__forkexec(gc, -1, -1, -1, args[0], args, what);
+    if (status) {
+        rc = -1;
+        goto out;
+    }
+    rc = 0;
+
+out:
+    free(args);
+    return rc;
+}

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 15:17:40 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 15:17:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbD3u-0003q1-Ik; Thu, 15 Dec 2011 15:17:34 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RbD3t-0003kH-K1
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 15:17:33 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1323962239!5660032!2
X-Originating-IP: [74.125.82.41]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24995 invoked from network); 15 Dec 2011 15:17:26 -0000
Received: from mail-ww0-f41.google.com (HELO mail-ww0-f41.google.com)
	(74.125.82.41)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 15:17:26 -0000
Received: by mail-ww0-f41.google.com with SMTP id dt12so1448524wgb.0
	for <xen-devel@lists.xensource.com>;
	Thu, 15 Dec 2011 07:17:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=RWh5r+/X/VY+HMmLCPXmbu6uThXBvyH5wg3OjCBt9c8=;
	b=PYVF3GXQxOxlaNabEFGEEh6tpky4CmrpcnrwQcA+hvDNzYTTkyWxVuUX329XBJjARW
	5vPMwlrEojTQJIqdiA/Q/bHU49lgSfHIhZfdQTiMiA8aa7O2rOaEyK8wFMWCPWN8H8+T
	LNoN5k2S5dG5DPjyOX21gACgGb/YthKN4fCis=
Received: by 10.216.137.155 with SMTP id y27mr998688wei.53.1323962246856;
	Thu, 15 Dec 2011 07:17:26 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id hb10sm8693212wib.16.2011.12.15.07.17.23
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 15 Dec 2011 07:17:24 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: a7e8713ee43f09b969e43fff0717c2e61e9c0213
Message-Id: <a7e8713ee43f09b969e4.1323961642@loki.upc.es>
In-Reply-To: <patchbomb.1323961634@loki.upc.es>
References: <patchbomb.1323961634@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Thu, 15 Dec 2011 16:07:22 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 08 of 15 v5] hotplug: remove debug messages from
 NetBSD hotplug scripts
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1323865415 -3600
# Node ID a7e8713ee43f09b969e43fff0717c2e61e9c0213
# Parent  1cdbc9b053598abd01cdd039118c07609deeff1a
hotplug: remove debug messages from NetBSD hotplug scripts

Remove unecessary debug messages from NetBSD hotplug scripts, left
error messages only.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 1cdbc9b05359 -r a7e8713ee43f tools/hotplug/NetBSD/block
--- a/tools/hotplug/NetBSD/block	Fri Sep 30 14:38:55 2011 +0200
+++ b/tools/hotplug/NetBSD/block	Wed Dec 14 13:23:35 2011 +0100
@@ -69,14 +69,12 @@ 1)
 			if [ "$status" = "free" ] && \
 			    vnconfig /dev/${disk}d $xparams >/dev/null; then
 				device=/dev/${disk}d
-				echo vnconfig /dev/${disk}d $xparams
 				break	
 			fi
 		done
 		if [ x$device = x ] ; then
 			error "no available vnd device"
 		fi
-		echo xenstore-write $xpath/vnd $device
 		xenstore-write $xpath/vnd $device
 		;;
 	phy)
@@ -84,9 +82,7 @@ 1)
 		;;
 	esac
 	physical_device=$(stat -f '%r' "$device")
-	echo xenstore-write $xpath/physical-device $physical_device
 	xenstore-write $xpath/physical-device $physical_device
-	echo xenstore-write $xpath/hotplug-status connected
 	xenstore-write $xpath/hotplug-status connected
 	exit 0
 	;;
diff -r 1cdbc9b05359 -r a7e8713ee43f tools/hotplug/NetBSD/vif-bridge
--- a/tools/hotplug/NetBSD/vif-bridge	Fri Sep 30 14:38:55 2011 +0200
+++ b/tools/hotplug/NetBSD/vif-bridge	Wed Dec 14 13:23:35 2011 +0100
@@ -24,12 +24,9 @@ 1)
 	xfid=$(xenstore-read "$xpath/frontend-id")
 	xhandle=$(xenstore-read "$xpath/handle")
 	iface=$(xenstore-read "$xpath/vifname")
-	echo ifconfig $iface up
 	ifconfig $iface up
 	brconfig $xbridge add $iface
-	echo brconfig $xbridge add $iface
 	xenstore-write $xpath/hotplug-status connected
-	echo xenstore-write $xpath/hotplug-status connected
 	exit 0
 	;;
 *)
diff -r 1cdbc9b05359 -r a7e8713ee43f tools/hotplug/NetBSD/vif-ip
--- a/tools/hotplug/NetBSD/vif-ip	Fri Sep 30 14:38:55 2011 +0200
+++ b/tools/hotplug/NetBSD/vif-ip	Wed Dec 14 13:23:35 2011 +0100
@@ -24,10 +24,8 @@ 1)
 	xfid=$(xenstore-read "$xpath/frontend-id")
 	xhandle=$(xenstore-read "$xpath/handle")
 	iface=$(xenstore-read "$xpath/vifname")
-	echo ifconfig $iface $xip up
 	ifconfig $iface $xip up
 	xenstore-write $xpath/hotplug-status connected
-	echo xenstore-write $xpath/hotplug-status connected
 	exit 0
 	;;
 *)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 15:17:40 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 15:17:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbD3u-0003q1-Ik; Thu, 15 Dec 2011 15:17:34 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RbD3t-0003kH-K1
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 15:17:33 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1323962239!5660032!2
X-Originating-IP: [74.125.82.41]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24995 invoked from network); 15 Dec 2011 15:17:26 -0000
Received: from mail-ww0-f41.google.com (HELO mail-ww0-f41.google.com)
	(74.125.82.41)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 15:17:26 -0000
Received: by mail-ww0-f41.google.com with SMTP id dt12so1448524wgb.0
	for <xen-devel@lists.xensource.com>;
	Thu, 15 Dec 2011 07:17:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=RWh5r+/X/VY+HMmLCPXmbu6uThXBvyH5wg3OjCBt9c8=;
	b=PYVF3GXQxOxlaNabEFGEEh6tpky4CmrpcnrwQcA+hvDNzYTTkyWxVuUX329XBJjARW
	5vPMwlrEojTQJIqdiA/Q/bHU49lgSfHIhZfdQTiMiA8aa7O2rOaEyK8wFMWCPWN8H8+T
	LNoN5k2S5dG5DPjyOX21gACgGb/YthKN4fCis=
Received: by 10.216.137.155 with SMTP id y27mr998688wei.53.1323962246856;
	Thu, 15 Dec 2011 07:17:26 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id hb10sm8693212wib.16.2011.12.15.07.17.23
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 15 Dec 2011 07:17:24 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: a7e8713ee43f09b969e43fff0717c2e61e9c0213
Message-Id: <a7e8713ee43f09b969e4.1323961642@loki.upc.es>
In-Reply-To: <patchbomb.1323961634@loki.upc.es>
References: <patchbomb.1323961634@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Thu, 15 Dec 2011 16:07:22 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 08 of 15 v5] hotplug: remove debug messages from
 NetBSD hotplug scripts
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1323865415 -3600
# Node ID a7e8713ee43f09b969e43fff0717c2e61e9c0213
# Parent  1cdbc9b053598abd01cdd039118c07609deeff1a
hotplug: remove debug messages from NetBSD hotplug scripts

Remove unecessary debug messages from NetBSD hotplug scripts, left
error messages only.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 1cdbc9b05359 -r a7e8713ee43f tools/hotplug/NetBSD/block
--- a/tools/hotplug/NetBSD/block	Fri Sep 30 14:38:55 2011 +0200
+++ b/tools/hotplug/NetBSD/block	Wed Dec 14 13:23:35 2011 +0100
@@ -69,14 +69,12 @@ 1)
 			if [ "$status" = "free" ] && \
 			    vnconfig /dev/${disk}d $xparams >/dev/null; then
 				device=/dev/${disk}d
-				echo vnconfig /dev/${disk}d $xparams
 				break	
 			fi
 		done
 		if [ x$device = x ] ; then
 			error "no available vnd device"
 		fi
-		echo xenstore-write $xpath/vnd $device
 		xenstore-write $xpath/vnd $device
 		;;
 	phy)
@@ -84,9 +82,7 @@ 1)
 		;;
 	esac
 	physical_device=$(stat -f '%r' "$device")
-	echo xenstore-write $xpath/physical-device $physical_device
 	xenstore-write $xpath/physical-device $physical_device
-	echo xenstore-write $xpath/hotplug-status connected
 	xenstore-write $xpath/hotplug-status connected
 	exit 0
 	;;
diff -r 1cdbc9b05359 -r a7e8713ee43f tools/hotplug/NetBSD/vif-bridge
--- a/tools/hotplug/NetBSD/vif-bridge	Fri Sep 30 14:38:55 2011 +0200
+++ b/tools/hotplug/NetBSD/vif-bridge	Wed Dec 14 13:23:35 2011 +0100
@@ -24,12 +24,9 @@ 1)
 	xfid=$(xenstore-read "$xpath/frontend-id")
 	xhandle=$(xenstore-read "$xpath/handle")
 	iface=$(xenstore-read "$xpath/vifname")
-	echo ifconfig $iface up
 	ifconfig $iface up
 	brconfig $xbridge add $iface
-	echo brconfig $xbridge add $iface
 	xenstore-write $xpath/hotplug-status connected
-	echo xenstore-write $xpath/hotplug-status connected
 	exit 0
 	;;
 *)
diff -r 1cdbc9b05359 -r a7e8713ee43f tools/hotplug/NetBSD/vif-ip
--- a/tools/hotplug/NetBSD/vif-ip	Fri Sep 30 14:38:55 2011 +0200
+++ b/tools/hotplug/NetBSD/vif-ip	Wed Dec 14 13:23:35 2011 +0100
@@ -24,10 +24,8 @@ 1)
 	xfid=$(xenstore-read "$xpath/frontend-id")
 	xhandle=$(xenstore-read "$xpath/handle")
 	iface=$(xenstore-read "$xpath/vifname")
-	echo ifconfig $iface $xip up
 	ifconfig $iface $xip up
 	xenstore-write $xpath/hotplug-status connected
-	echo xenstore-write $xpath/hotplug-status connected
 	exit 0
 	;;
 *)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 15:17:46 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 15: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.xensource.com>)
	id 1RbD3z-0003tK-1C; Thu, 15 Dec 2011 15:17:39 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RbD3x-0003nt-G3
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 15:17:37 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1323962229!7357491!3
X-Originating-IP: [209.85.161.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9470 invoked from network); 15 Dec 2011 15:17:31 -0000
Received: from mail-fx0-f43.google.com (HELO mail-fx0-f43.google.com)
	(209.85.161.43)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 15:17:31 -0000
Received: by mail-fx0-f43.google.com with SMTP id p21so5275311faa.30
	for <xen-devel@lists.xensource.com>;
	Thu, 15 Dec 2011 07:17:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=AC7sJ00DUzhiRSuXxC11oEuSRkMF8NMAQAw63B9omfY=;
	b=XPWNTBSNi8HEtQ4MBuv+3fFX2YFcYp1m7R3DJQH4p9UF+kgqnE3aoj5G0l8VY3unPM
	Jaq3IWGTecprTTPC6VgctXew5i3C0uEkC8xfzTA8VGfPvu5Gv1PP7Reg0DVBVgGkySqP
	KX6kQNwBgNmb2nXedYNentgqzEN8hv4yF1ikU=
Received: by 10.180.14.193 with SMTP id r1mr2358395wic.2.1323962250886;
	Thu, 15 Dec 2011 07:17:30 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id hb10sm8693212wib.16.2011.12.15.07.17.26
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 15 Dec 2011 07:17:28 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 663e02a5360ce3d48ce732f9c40087e5ca4323d3
Message-Id: <663e02a5360ce3d48ce7.1323961643@loki.upc.es>
In-Reply-To: <patchbomb.1323961634@loki.upc.es>
References: <patchbomb.1323961634@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Thu, 15 Dec 2011 16:07:23 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 09 of 15 v5] rc.d NetBSD: don't start
 xenbackendd by default, only when xend needs it
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1317386335 -7200
# Node ID 663e02a5360ce3d48ce732f9c40087e5ca4323d3
# Parent  a7e8713ee43f09b969e43fff0717c2e61e9c0213
rc.d NetBSD: don't start xenbackendd by default, only when xend needs it.

With the move of hotplug scripts from xenbackendd to libxl
xenbackendd is no longer needed by libxl, only start it when xend is
started.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r a7e8713ee43f -r 663e02a5360c tools/hotplug/NetBSD/rc.d/xenbackendd
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/tools/hotplug/NetBSD/rc.d/xenbackendd	Fri Sep 30 14:38:55 2011 +0200
@@ -0,0 +1,27 @@
+#!/bin/sh
+#
+# PROVIDE: xenbackendd
+# REQUIRE: xencommons
+
+. /etc/rc.subr
+
+DIR=$(dirname "$0")
+. "${DIR}/xen-hotplugpath.sh"
+
+LD_LIBRARY_PATH="${LIBDIR}"
+export LD_LIBRARY_PATH PYTHONPATH
+PATH="${PATH}:${SBINDIR}"
+export PATH
+
+name="xenbackendd"
+rcvar=$name
+command="${SBINDIR}/xenbackendd"
+if [ -n "${XENBACKENDD_DEBUG}" ]; then
+	command_args="${XENBACKENDD_ARGS} -d"
+else
+	command_args="${XENBACKENDD_ARGS}"
+fi
+
+load_rc_config $name
+run_rc_command "$1"
+
diff -r a7e8713ee43f -r 663e02a5360c tools/hotplug/NetBSD/rc.d/xencommons
--- a/tools/hotplug/NetBSD/rc.d/xencommons	Wed Dec 14 13:23:35 2011 +0100
+++ b/tools/hotplug/NetBSD/rc.d/xencommons	Fri Sep 30 14:38:55 2011 +0200
@@ -22,8 +22,6 @@ required_files="/kern/xen/privcmd"
 
 XENSTORED_PIDFILE="/var/run/xenstored.pid"
 XENCONSOLED_PIDFILE="/var/run/xenconsoled.pid"
-XENBACKENDD_PIDFILE="/var/run/xenbackendd.pid"
-#XENBACKENDD_DEBUG=1
 #XENCONSOLED_TRACE="/var/log/xen/xenconsole-trace.log"
 #XENSTORED_TRACE="/var/log/xen/xenstore-trace.log"
 
@@ -46,7 +44,7 @@ xen_startcmd()
 			XENSTORED_ROOTDIR="/var/lib/xenstored"
 		fi
 		rm -f ${XENSTORED_ROOTDIR}/tdb* >/dev/null 2>&1
-		printf "Starting xenservices: xenstored, xenconsoled, xenbackendd."
+		printf "Starting xenservices: xenstored, xenconsoled."
 		XENSTORED_ARGS=" --pid-file ${XENSTORED_PIDFILE}"
 		if [ -n "${XENSTORED_TRACE}" ]; then
 			XENSTORED_ARGS="${XENSTORED_ARGS} -T /var/log/xen/xenstored-trace.log"
@@ -58,7 +56,7 @@ xen_startcmd()
 			sleep 1
 		done
 	else
-		printf "Starting xenservices: xenconsoled, xenbackendd."
+		printf "Starting xenservices: xenconsoled."
 	fi
 
 	XENCONSOLED_ARGS=""
@@ -68,13 +66,6 @@ xen_startcmd()
 
 	${SBINDIR}/xenconsoled ${XENCONSOLED_ARGS}
 
-	XENBACKENDD_ARGS=""
-	if [ -n "${XENBACKENDD_DEBUG}" ]; then
-		XENBACKENDD_ARGS="${XENBACKENDD_ARGS} -d"
-	fi
-
-	${SBINDIR}/xenbackendd ${XENBACKENDD_ARGS}
-
 	printf "\n"
 
 	printf "Setting domain 0 name.\n"
@@ -87,8 +78,6 @@ xen_stop()
 	printf "Stopping xencommons.\n"
 	printf "WARNING: Not stopping xenstored, as it cannot be restarted.\n"
 
-	rc_pid=$(check_pidfile ${XENBACKENDD_PIDFILE} ${SBINDIR}/xenbackendd)
-	pids="$pids $rc_pid"
 	rc_pid=$(check_pidfile ${XENCONSOLED_PIDFILE} ${SBINDIR}/xenconsoled)
 	pids="$pids $rc_pid"
 
@@ -108,17 +97,12 @@ xen_status()
 		pids="$pids $xenconsoled_pid"
 	fi
 
-	xenbackend_pid=$(check_pidfile ${XENBACKENDD_PIDFILE} ${SBINDIR}/xenbackendd)
-	if test -n ${xenbackend_pid}; then
-		pids="$pids $xenbackend_pid"
-	fi
-
-	if test -n "$xenbackend_pid" -a -n "$xenconsoled_pid" -a -n "$xenstored_pid";
+	if test -n "$xenconsoled_pid" -a -n "$xenstored_pid";
 	then
 		echo "xencommons are running as pids $pids."
 		return 0
 	fi
-	if test -z "$xenbackend_pid" -a -z "$xenconsoled_pid" -a -z "$xenstored_pid";
+	if test -z "$xenconsoled_pid" -a -z "$xenstored_pid";
 	then
 		echo "xencommons are not running."
 		return 0
@@ -134,11 +118,6 @@ xen_status()
 	else
 		echo "xenconsoled is not running."
 	fi
-	if test -n $xenbackend_pid; then
-		echo "xenbackendd is running as pid $xenbackend_pid."
-	else
-		echo "xenbackendd is not running."
-	fi
 }
 
 load_rc_config $name
diff -r a7e8713ee43f -r 663e02a5360c tools/hotplug/NetBSD/rc.d/xend
--- a/tools/hotplug/NetBSD/rc.d/xend	Wed Dec 14 13:23:35 2011 +0100
+++ b/tools/hotplug/NetBSD/rc.d/xend	Fri Sep 30 14:38:55 2011 +0200
@@ -1,7 +1,7 @@
 #!/bin/sh
 #
 # PROVIDE: xend
-# REQUIRE: xencommons
+# REQUIRE: xencommons xenbackendd
 
 . /etc/rc.subr
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 15:17:46 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 15: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.xensource.com>)
	id 1RbD3z-0003tK-1C; Thu, 15 Dec 2011 15:17:39 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RbD3x-0003nt-G3
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 15:17:37 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1323962229!7357491!3
X-Originating-IP: [209.85.161.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9470 invoked from network); 15 Dec 2011 15:17:31 -0000
Received: from mail-fx0-f43.google.com (HELO mail-fx0-f43.google.com)
	(209.85.161.43)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 15:17:31 -0000
Received: by mail-fx0-f43.google.com with SMTP id p21so5275311faa.30
	for <xen-devel@lists.xensource.com>;
	Thu, 15 Dec 2011 07:17:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=AC7sJ00DUzhiRSuXxC11oEuSRkMF8NMAQAw63B9omfY=;
	b=XPWNTBSNi8HEtQ4MBuv+3fFX2YFcYp1m7R3DJQH4p9UF+kgqnE3aoj5G0l8VY3unPM
	Jaq3IWGTecprTTPC6VgctXew5i3C0uEkC8xfzTA8VGfPvu5Gv1PP7Reg0DVBVgGkySqP
	KX6kQNwBgNmb2nXedYNentgqzEN8hv4yF1ikU=
Received: by 10.180.14.193 with SMTP id r1mr2358395wic.2.1323962250886;
	Thu, 15 Dec 2011 07:17:30 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id hb10sm8693212wib.16.2011.12.15.07.17.26
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 15 Dec 2011 07:17:28 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 663e02a5360ce3d48ce732f9c40087e5ca4323d3
Message-Id: <663e02a5360ce3d48ce7.1323961643@loki.upc.es>
In-Reply-To: <patchbomb.1323961634@loki.upc.es>
References: <patchbomb.1323961634@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Thu, 15 Dec 2011 16:07:23 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 09 of 15 v5] rc.d NetBSD: don't start
 xenbackendd by default, only when xend needs it
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1317386335 -7200
# Node ID 663e02a5360ce3d48ce732f9c40087e5ca4323d3
# Parent  a7e8713ee43f09b969e43fff0717c2e61e9c0213
rc.d NetBSD: don't start xenbackendd by default, only when xend needs it.

With the move of hotplug scripts from xenbackendd to libxl
xenbackendd is no longer needed by libxl, only start it when xend is
started.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r a7e8713ee43f -r 663e02a5360c tools/hotplug/NetBSD/rc.d/xenbackendd
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/tools/hotplug/NetBSD/rc.d/xenbackendd	Fri Sep 30 14:38:55 2011 +0200
@@ -0,0 +1,27 @@
+#!/bin/sh
+#
+# PROVIDE: xenbackendd
+# REQUIRE: xencommons
+
+. /etc/rc.subr
+
+DIR=$(dirname "$0")
+. "${DIR}/xen-hotplugpath.sh"
+
+LD_LIBRARY_PATH="${LIBDIR}"
+export LD_LIBRARY_PATH PYTHONPATH
+PATH="${PATH}:${SBINDIR}"
+export PATH
+
+name="xenbackendd"
+rcvar=$name
+command="${SBINDIR}/xenbackendd"
+if [ -n "${XENBACKENDD_DEBUG}" ]; then
+	command_args="${XENBACKENDD_ARGS} -d"
+else
+	command_args="${XENBACKENDD_ARGS}"
+fi
+
+load_rc_config $name
+run_rc_command "$1"
+
diff -r a7e8713ee43f -r 663e02a5360c tools/hotplug/NetBSD/rc.d/xencommons
--- a/tools/hotplug/NetBSD/rc.d/xencommons	Wed Dec 14 13:23:35 2011 +0100
+++ b/tools/hotplug/NetBSD/rc.d/xencommons	Fri Sep 30 14:38:55 2011 +0200
@@ -22,8 +22,6 @@ required_files="/kern/xen/privcmd"
 
 XENSTORED_PIDFILE="/var/run/xenstored.pid"
 XENCONSOLED_PIDFILE="/var/run/xenconsoled.pid"
-XENBACKENDD_PIDFILE="/var/run/xenbackendd.pid"
-#XENBACKENDD_DEBUG=1
 #XENCONSOLED_TRACE="/var/log/xen/xenconsole-trace.log"
 #XENSTORED_TRACE="/var/log/xen/xenstore-trace.log"
 
@@ -46,7 +44,7 @@ xen_startcmd()
 			XENSTORED_ROOTDIR="/var/lib/xenstored"
 		fi
 		rm -f ${XENSTORED_ROOTDIR}/tdb* >/dev/null 2>&1
-		printf "Starting xenservices: xenstored, xenconsoled, xenbackendd."
+		printf "Starting xenservices: xenstored, xenconsoled."
 		XENSTORED_ARGS=" --pid-file ${XENSTORED_PIDFILE}"
 		if [ -n "${XENSTORED_TRACE}" ]; then
 			XENSTORED_ARGS="${XENSTORED_ARGS} -T /var/log/xen/xenstored-trace.log"
@@ -58,7 +56,7 @@ xen_startcmd()
 			sleep 1
 		done
 	else
-		printf "Starting xenservices: xenconsoled, xenbackendd."
+		printf "Starting xenservices: xenconsoled."
 	fi
 
 	XENCONSOLED_ARGS=""
@@ -68,13 +66,6 @@ xen_startcmd()
 
 	${SBINDIR}/xenconsoled ${XENCONSOLED_ARGS}
 
-	XENBACKENDD_ARGS=""
-	if [ -n "${XENBACKENDD_DEBUG}" ]; then
-		XENBACKENDD_ARGS="${XENBACKENDD_ARGS} -d"
-	fi
-
-	${SBINDIR}/xenbackendd ${XENBACKENDD_ARGS}
-
 	printf "\n"
 
 	printf "Setting domain 0 name.\n"
@@ -87,8 +78,6 @@ xen_stop()
 	printf "Stopping xencommons.\n"
 	printf "WARNING: Not stopping xenstored, as it cannot be restarted.\n"
 
-	rc_pid=$(check_pidfile ${XENBACKENDD_PIDFILE} ${SBINDIR}/xenbackendd)
-	pids="$pids $rc_pid"
 	rc_pid=$(check_pidfile ${XENCONSOLED_PIDFILE} ${SBINDIR}/xenconsoled)
 	pids="$pids $rc_pid"
 
@@ -108,17 +97,12 @@ xen_status()
 		pids="$pids $xenconsoled_pid"
 	fi
 
-	xenbackend_pid=$(check_pidfile ${XENBACKENDD_PIDFILE} ${SBINDIR}/xenbackendd)
-	if test -n ${xenbackend_pid}; then
-		pids="$pids $xenbackend_pid"
-	fi
-
-	if test -n "$xenbackend_pid" -a -n "$xenconsoled_pid" -a -n "$xenstored_pid";
+	if test -n "$xenconsoled_pid" -a -n "$xenstored_pid";
 	then
 		echo "xencommons are running as pids $pids."
 		return 0
 	fi
-	if test -z "$xenbackend_pid" -a -z "$xenconsoled_pid" -a -z "$xenstored_pid";
+	if test -z "$xenconsoled_pid" -a -z "$xenstored_pid";
 	then
 		echo "xencommons are not running."
 		return 0
@@ -134,11 +118,6 @@ xen_status()
 	else
 		echo "xenconsoled is not running."
 	fi
-	if test -n $xenbackend_pid; then
-		echo "xenbackendd is running as pid $xenbackend_pid."
-	else
-		echo "xenbackendd is not running."
-	fi
 }
 
 load_rc_config $name
diff -r a7e8713ee43f -r 663e02a5360c tools/hotplug/NetBSD/rc.d/xend
--- a/tools/hotplug/NetBSD/rc.d/xend	Wed Dec 14 13:23:35 2011 +0100
+++ b/tools/hotplug/NetBSD/rc.d/xend	Fri Sep 30 14:38:55 2011 +0200
@@ -1,7 +1,7 @@
 #!/bin/sh
 #
 # PROVIDE: xend
-# REQUIRE: xencommons
+# REQUIRE: xencommons xenbackendd
 
 . /etc/rc.subr
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 15:17:49 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 15:17:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbD45-0003y0-S7; Thu, 15 Dec 2011 15:17:45 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RbD44-0003th-OU
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 15:17:44 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1323962182!57450280!2
X-Originating-IP: [74.125.83.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30900 invoked from network); 15 Dec 2011 15:16:49 -0000
Received: from mail-ee0-f43.google.com (HELO mail-ee0-f43.google.com)
	(74.125.83.43)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 15:16:49 -0000
Received: by mail-ee0-f43.google.com with SMTP id d4so4599524eek.30
	for <xen-devel@lists.xensource.com>;
	Thu, 15 Dec 2011 07:17:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=GFrLmKvKX0+Cnb2+jPDR6ShjFeNRGwp2MQQ1OozIGsI=;
	b=qEgA+iuehFiLvt79t7fs4RD1+GMwFazguxPhtgWdjLacTgkDqhpuuUclxZI3fgQ/NS
	HnuK63jptpDCwlIppDbvjsxlN7qGAWbCkbZNrB1HKrJdQ+CrL24HpmIhjUE0b5YEnylI
	f9mr72lNaAgzmSdWjJhi2FebEsxnC0dijhPt4=
Received: by 10.180.96.166 with SMTP id dt6mr5679158wib.47.1323962258718;
	Thu, 15 Dec 2011 07:17:38 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id hb10sm8693212wib.16.2011.12.15.07.17.35
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 15 Dec 2011 07:17:36 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: f3d3a0a74f55f07616abc4bac95f82868b91fe9f
Message-Id: <f3d3a0a74f55f07616ab.1323961645@loki.upc.es>
In-Reply-To: <patchbomb.1323961634@loki.upc.es>
References: <patchbomb.1323961634@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Thu, 15 Dec 2011 16:07:25 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 11 of 15 v5] libxl: fix incorrect log message in
 libxl_domain_destroy
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1323939609 -3600
# Node ID f3d3a0a74f55f07616abc4bac95f82868b91fe9f
# Parent  6a05eb37ecdd7122eb7ad7d0bea1879a7f1a3c6c
libxl: fix incorrect log message in libxl_domain_destroy

Fix a log message that was referring to libxl_devices_dispose instead
of libxl__devices_destroy.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 6a05eb37ecdd -r f3d3a0a74f55 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Thu Dec 15 09:59:58 2011 +0100
+++ b/tools/libxl/libxl.c	Thu Dec 15 10:00:09 2011 +0100
@@ -773,7 +773,8 @@ int libxl_domain_destroy(libxl_ctx *ctx,
         libxl__qmp_cleanup(gc, domid);
     }
     if (libxl__devices_destroy(gc, domid, force) < 0)
-        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "libxl_devices_dispose failed for %d", domid);
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, 
+                   "libxl__devices_destroy failed for %d", domid);
 
     vm_path = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/vm", dom_path));
     if (vm_path)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 15:17:49 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 15:17:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbD45-0003y0-S7; Thu, 15 Dec 2011 15:17:45 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RbD44-0003th-OU
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 15:17:44 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1323962182!57450280!2
X-Originating-IP: [74.125.83.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30900 invoked from network); 15 Dec 2011 15:16:49 -0000
Received: from mail-ee0-f43.google.com (HELO mail-ee0-f43.google.com)
	(74.125.83.43)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 15:16:49 -0000
Received: by mail-ee0-f43.google.com with SMTP id d4so4599524eek.30
	for <xen-devel@lists.xensource.com>;
	Thu, 15 Dec 2011 07:17:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=GFrLmKvKX0+Cnb2+jPDR6ShjFeNRGwp2MQQ1OozIGsI=;
	b=qEgA+iuehFiLvt79t7fs4RD1+GMwFazguxPhtgWdjLacTgkDqhpuuUclxZI3fgQ/NS
	HnuK63jptpDCwlIppDbvjsxlN7qGAWbCkbZNrB1HKrJdQ+CrL24HpmIhjUE0b5YEnylI
	f9mr72lNaAgzmSdWjJhi2FebEsxnC0dijhPt4=
Received: by 10.180.96.166 with SMTP id dt6mr5679158wib.47.1323962258718;
	Thu, 15 Dec 2011 07:17:38 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id hb10sm8693212wib.16.2011.12.15.07.17.35
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 15 Dec 2011 07:17:36 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: f3d3a0a74f55f07616abc4bac95f82868b91fe9f
Message-Id: <f3d3a0a74f55f07616ab.1323961645@loki.upc.es>
In-Reply-To: <patchbomb.1323961634@loki.upc.es>
References: <patchbomb.1323961634@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Thu, 15 Dec 2011 16:07:25 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 11 of 15 v5] libxl: fix incorrect log message in
 libxl_domain_destroy
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1323939609 -3600
# Node ID f3d3a0a74f55f07616abc4bac95f82868b91fe9f
# Parent  6a05eb37ecdd7122eb7ad7d0bea1879a7f1a3c6c
libxl: fix incorrect log message in libxl_domain_destroy

Fix a log message that was referring to libxl_devices_dispose instead
of libxl__devices_destroy.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 6a05eb37ecdd -r f3d3a0a74f55 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Thu Dec 15 09:59:58 2011 +0100
+++ b/tools/libxl/libxl.c	Thu Dec 15 10:00:09 2011 +0100
@@ -773,7 +773,8 @@ int libxl_domain_destroy(libxl_ctx *ctx,
         libxl__qmp_cleanup(gc, domid);
     }
     if (libxl__devices_destroy(gc, domid, force) < 0)
-        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "libxl_devices_dispose failed for %d", domid);
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, 
+                   "libxl__devices_destroy failed for %d", domid);
 
     vm_path = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/vm", dom_path));
     if (vm_path)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 15:17:49 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 15:17:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbD45-0003xk-F9; Thu, 15 Dec 2011 15:17:45 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RbD44-0003wf-7X
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 15:17:44 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1323962182!57450280!3
X-Originating-IP: [74.125.83.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31147 invoked from network); 15 Dec 2011 15:16:53 -0000
Received: from mail-ee0-f43.google.com (HELO mail-ee0-f43.google.com)
	(74.125.83.43)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 15:16:53 -0000
Received: by mail-ee0-f43.google.com with SMTP id d4so4599524eek.30
	for <xen-devel@lists.xensource.com>;
	Thu, 15 Dec 2011 07:17:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=Ol+lV6G++7tfoWerJvo1tGGMl8ZrprU2CYgARt3RS5M=;
	b=I70l0DiUbVpk+hcSSgD/bMWKfuSpi6MioslOIhKXHk/x2ui2+h8TvyT6KYac9kinWv
	mX7MJpNSIW977vHQl6kso5GL1Q+FluU2T8t/BNGdDAeOddSGFBCDY+SfY/8Ckqq4gqu6
	VIA0Qwiz560tC8vOXsufR7PE+yMoeStFjXm6E=
Received: by 10.180.106.105 with SMTP id gt9mr7026071wib.39.1323962262809;
	Thu, 15 Dec 2011 07:17:42 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id hb10sm8693212wib.16.2011.12.15.07.17.40
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 15 Dec 2011 07:17:41 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 1beeb56e336aef8f95bd3dcead953feb6d383544
Message-Id: <1beeb56e336aef8f95bd.1323961647@loki.upc.es>
In-Reply-To: <patchbomb.1323961634@loki.upc.es>
References: <patchbomb.1323961634@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Thu, 15 Dec 2011 16:07:27 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 13 of 15 v5] libxl: remove force parameter from
 libxl_domain_destroy
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1323939609 -3600
# Node ID 1beeb56e336aef8f95bd3dcead953feb6d383544
# Parent  7dbba8f9706d3a1ea777df23f1d40b2da951ef4a
libxl: remove force parameter from libxl_domain_destroy

Since a destroy is considered a forced shutdown, there's no point in
passing a force parameter. All the occurences of this function have
been replaced with the proper syntax.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 7dbba8f9706d -r 1beeb56e336a tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Thu Dec 15 10:00:09 2011 +0100
+++ b/tools/libxl/libxl.c	Thu Dec 15 10:00:09 2011 +0100
@@ -723,7 +723,7 @@ int libxl_event_get_disk_eject_info(libx
     return 1;
 }
 
-int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid, int force)
+int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid)
 {
     GC_INIT(ctx);
     libxl_dominfo dominfo;
@@ -772,7 +772,7 @@ int libxl_domain_destroy(libxl_ctx *ctx,
 
         libxl__qmp_cleanup(gc, domid);
     }
-    if (libxl__devices_destroy(gc, domid, force) < 0)
+    if (libxl__devices_destroy(gc, domid, 1) < 0)
         LIBXL__LOG(ctx, LIBXL__LOG_ERROR, 
                    "libxl__devices_destroy failed for %d", domid);
 
diff -r 7dbba8f9706d -r 1beeb56e336a tools/libxl/libxl.h
--- a/tools/libxl/libxl.h	Thu Dec 15 10:00:09 2011 +0100
+++ b/tools/libxl/libxl.h	Thu Dec 15 10:00:09 2011 +0100
@@ -269,7 +269,7 @@ int libxl_domain_suspend(libxl_ctx *ctx,
                           uint32_t domid, int fd);
 int libxl_domain_resume(libxl_ctx *ctx, uint32_t domid);
 int libxl_domain_shutdown(libxl_ctx *ctx, uint32_t domid, int req);
-int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid, int force);
+int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid);
 int libxl_domain_preserve(libxl_ctx *ctx, uint32_t domid, libxl_domain_create_info *info, const char *name_suffix, libxl_uuid new_uuid);
 
 /* get max. number of cpus supported by hypervisor */
diff -r 7dbba8f9706d -r 1beeb56e336a tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Thu Dec 15 10:00:09 2011 +0100
+++ b/tools/libxl/libxl_create.c	Thu Dec 15 10:00:09 2011 +0100
@@ -662,7 +662,7 @@ static int do_domain_create(libxl__gc *g
 
 error_out:
     if (domid)
-        libxl_domain_destroy(ctx, domid, 0);
+        libxl_domain_destroy(ctx, domid);
 
     return ret;
 }
diff -r 7dbba8f9706d -r 1beeb56e336a tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Thu Dec 15 10:00:09 2011 +0100
+++ b/tools/libxl/libxl_dm.c	Thu Dec 15 10:00:09 2011 +0100
@@ -917,7 +917,7 @@ int libxl__destroy_device_model(libxl__g
             goto out;
         }
         LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Device model is a stubdom, domid=%d", stubdomid);
-        ret = libxl_domain_destroy(ctx, stubdomid, 0);
+        ret = libxl_domain_destroy(ctx, stubdomid);
         if (ret)
             goto out;
     } else {
diff -r 7dbba8f9706d -r 1beeb56e336a tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Thu Dec 15 10:00:09 2011 +0100
+++ b/tools/libxl/xl_cmdimpl.c	Thu Dec 15 10:00:09 2011 +0100
@@ -1283,7 +1283,7 @@ static int handle_domain_death(libxl_ctx
         /* fall-through */
     case LIBXL_ACTION_ON_SHUTDOWN_DESTROY:
         LOG("Domain %d needs to be cleaned up: destroying the domain", domid);
-        libxl_domain_destroy(ctx, domid, 0);
+        libxl_domain_destroy(ctx, domid);
         break;
 
     case LIBXL_ACTION_ON_SHUTDOWN_COREDUMP_DESTROY:
@@ -1786,7 +1786,7 @@ start:
 error_out:
     release_lock();
     if (libxl_domid_valid_guest(domid))
-        libxl_domain_destroy(ctx, domid, 0);
+        libxl_domain_destroy(ctx, domid);
 
 out:
     if (logfile != 2)
@@ -2256,7 +2256,7 @@ static void destroy_domain(const char *p
         fprintf(stderr, "Cannot destroy privileged domain 0.\n\n");
         exit(-1);
     }
-    rc = libxl_domain_destroy(ctx, domid, 0);
+    rc = libxl_domain_destroy(ctx, domid);
     if (rc) { fprintf(stderr,"destroy failed (rc=%d)\n",rc); exit(-1); }
 }
 
@@ -2502,7 +2502,7 @@ static int save_domain(const char *p, co
     if (checkpoint)
         libxl_domain_unpause(ctx, domid);
     else
-        libxl_domain_destroy(ctx, domid, 0);
+        libxl_domain_destroy(ctx, domid);
 
     exit(0);
 }
@@ -2735,7 +2735,7 @@ static void migrate_domain(const char *d
     }
 
     fprintf(stderr, "migration sender: Target reports successful startup.\n");
-    libxl_domain_destroy(ctx, domid, 1); /* bang! */
+    libxl_domain_destroy(ctx, domid); /* bang! */
     fprintf(stderr, "Migration successful.\n");
     exit(0);
 
@@ -2852,7 +2852,7 @@ static void migrate_receive(int debug, i
     if (rc) {
         fprintf(stderr, "migration target: Failure, destroying our copy.\n");
 
-        rc2 = libxl_domain_destroy(ctx, domid, 1);
+        rc2 = libxl_domain_destroy(ctx, domid);
         if (rc2) {
             fprintf(stderr, "migration target: Failed to destroy our copy"
                     " (code %d).\n", rc2);
diff -r 7dbba8f9706d -r 1beeb56e336a tools/python/xen/lowlevel/xl/xl.c
--- a/tools/python/xen/lowlevel/xl/xl.c	Thu Dec 15 10:00:09 2011 +0100
+++ b/tools/python/xen/lowlevel/xl/xl.c	Thu Dec 15 10:00:09 2011 +0100
@@ -437,10 +437,10 @@ static PyObject *pyxl_domain_shutdown(Xl
 
 static PyObject *pyxl_domain_destroy(XlObject *self, PyObject *args)
 {
-    int domid, force = 1;
-    if ( !PyArg_ParseTuple(args, "i|i", &domid, &force) )
+    int domid;
+    if ( !PyArg_ParseTuple(args, "i", &domid) )
         return NULL;
-    if ( libxl_domain_destroy(self->ctx, domid, force) ) {
+    if ( libxl_domain_destroy(self->ctx, domid) ) {
         PyErr_SetString(xl_error_obj, "cannot destroy domain");
         return NULL;
     }

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 15:17:49 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 15:17:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbD45-0003xk-F9; Thu, 15 Dec 2011 15:17:45 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RbD44-0003wf-7X
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 15:17:44 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1323962182!57450280!3
X-Originating-IP: [74.125.83.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31147 invoked from network); 15 Dec 2011 15:16:53 -0000
Received: from mail-ee0-f43.google.com (HELO mail-ee0-f43.google.com)
	(74.125.83.43)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 15:16:53 -0000
Received: by mail-ee0-f43.google.com with SMTP id d4so4599524eek.30
	for <xen-devel@lists.xensource.com>;
	Thu, 15 Dec 2011 07:17:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=Ol+lV6G++7tfoWerJvo1tGGMl8ZrprU2CYgARt3RS5M=;
	b=I70l0DiUbVpk+hcSSgD/bMWKfuSpi6MioslOIhKXHk/x2ui2+h8TvyT6KYac9kinWv
	mX7MJpNSIW977vHQl6kso5GL1Q+FluU2T8t/BNGdDAeOddSGFBCDY+SfY/8Ckqq4gqu6
	VIA0Qwiz560tC8vOXsufR7PE+yMoeStFjXm6E=
Received: by 10.180.106.105 with SMTP id gt9mr7026071wib.39.1323962262809;
	Thu, 15 Dec 2011 07:17:42 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id hb10sm8693212wib.16.2011.12.15.07.17.40
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 15 Dec 2011 07:17:41 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 1beeb56e336aef8f95bd3dcead953feb6d383544
Message-Id: <1beeb56e336aef8f95bd.1323961647@loki.upc.es>
In-Reply-To: <patchbomb.1323961634@loki.upc.es>
References: <patchbomb.1323961634@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Thu, 15 Dec 2011 16:07:27 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 13 of 15 v5] libxl: remove force parameter from
 libxl_domain_destroy
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1323939609 -3600
# Node ID 1beeb56e336aef8f95bd3dcead953feb6d383544
# Parent  7dbba8f9706d3a1ea777df23f1d40b2da951ef4a
libxl: remove force parameter from libxl_domain_destroy

Since a destroy is considered a forced shutdown, there's no point in
passing a force parameter. All the occurences of this function have
been replaced with the proper syntax.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 7dbba8f9706d -r 1beeb56e336a tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Thu Dec 15 10:00:09 2011 +0100
+++ b/tools/libxl/libxl.c	Thu Dec 15 10:00:09 2011 +0100
@@ -723,7 +723,7 @@ int libxl_event_get_disk_eject_info(libx
     return 1;
 }
 
-int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid, int force)
+int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid)
 {
     GC_INIT(ctx);
     libxl_dominfo dominfo;
@@ -772,7 +772,7 @@ int libxl_domain_destroy(libxl_ctx *ctx,
 
         libxl__qmp_cleanup(gc, domid);
     }
-    if (libxl__devices_destroy(gc, domid, force) < 0)
+    if (libxl__devices_destroy(gc, domid, 1) < 0)
         LIBXL__LOG(ctx, LIBXL__LOG_ERROR, 
                    "libxl__devices_destroy failed for %d", domid);
 
diff -r 7dbba8f9706d -r 1beeb56e336a tools/libxl/libxl.h
--- a/tools/libxl/libxl.h	Thu Dec 15 10:00:09 2011 +0100
+++ b/tools/libxl/libxl.h	Thu Dec 15 10:00:09 2011 +0100
@@ -269,7 +269,7 @@ int libxl_domain_suspend(libxl_ctx *ctx,
                           uint32_t domid, int fd);
 int libxl_domain_resume(libxl_ctx *ctx, uint32_t domid);
 int libxl_domain_shutdown(libxl_ctx *ctx, uint32_t domid, int req);
-int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid, int force);
+int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid);
 int libxl_domain_preserve(libxl_ctx *ctx, uint32_t domid, libxl_domain_create_info *info, const char *name_suffix, libxl_uuid new_uuid);
 
 /* get max. number of cpus supported by hypervisor */
diff -r 7dbba8f9706d -r 1beeb56e336a tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Thu Dec 15 10:00:09 2011 +0100
+++ b/tools/libxl/libxl_create.c	Thu Dec 15 10:00:09 2011 +0100
@@ -662,7 +662,7 @@ static int do_domain_create(libxl__gc *g
 
 error_out:
     if (domid)
-        libxl_domain_destroy(ctx, domid, 0);
+        libxl_domain_destroy(ctx, domid);
 
     return ret;
 }
diff -r 7dbba8f9706d -r 1beeb56e336a tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Thu Dec 15 10:00:09 2011 +0100
+++ b/tools/libxl/libxl_dm.c	Thu Dec 15 10:00:09 2011 +0100
@@ -917,7 +917,7 @@ int libxl__destroy_device_model(libxl__g
             goto out;
         }
         LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Device model is a stubdom, domid=%d", stubdomid);
-        ret = libxl_domain_destroy(ctx, stubdomid, 0);
+        ret = libxl_domain_destroy(ctx, stubdomid);
         if (ret)
             goto out;
     } else {
diff -r 7dbba8f9706d -r 1beeb56e336a tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Thu Dec 15 10:00:09 2011 +0100
+++ b/tools/libxl/xl_cmdimpl.c	Thu Dec 15 10:00:09 2011 +0100
@@ -1283,7 +1283,7 @@ static int handle_domain_death(libxl_ctx
         /* fall-through */
     case LIBXL_ACTION_ON_SHUTDOWN_DESTROY:
         LOG("Domain %d needs to be cleaned up: destroying the domain", domid);
-        libxl_domain_destroy(ctx, domid, 0);
+        libxl_domain_destroy(ctx, domid);
         break;
 
     case LIBXL_ACTION_ON_SHUTDOWN_COREDUMP_DESTROY:
@@ -1786,7 +1786,7 @@ start:
 error_out:
     release_lock();
     if (libxl_domid_valid_guest(domid))
-        libxl_domain_destroy(ctx, domid, 0);
+        libxl_domain_destroy(ctx, domid);
 
 out:
     if (logfile != 2)
@@ -2256,7 +2256,7 @@ static void destroy_domain(const char *p
         fprintf(stderr, "Cannot destroy privileged domain 0.\n\n");
         exit(-1);
     }
-    rc = libxl_domain_destroy(ctx, domid, 0);
+    rc = libxl_domain_destroy(ctx, domid);
     if (rc) { fprintf(stderr,"destroy failed (rc=%d)\n",rc); exit(-1); }
 }
 
@@ -2502,7 +2502,7 @@ static int save_domain(const char *p, co
     if (checkpoint)
         libxl_domain_unpause(ctx, domid);
     else
-        libxl_domain_destroy(ctx, domid, 0);
+        libxl_domain_destroy(ctx, domid);
 
     exit(0);
 }
@@ -2735,7 +2735,7 @@ static void migrate_domain(const char *d
     }
 
     fprintf(stderr, "migration sender: Target reports successful startup.\n");
-    libxl_domain_destroy(ctx, domid, 1); /* bang! */
+    libxl_domain_destroy(ctx, domid); /* bang! */
     fprintf(stderr, "Migration successful.\n");
     exit(0);
 
@@ -2852,7 +2852,7 @@ static void migrate_receive(int debug, i
     if (rc) {
         fprintf(stderr, "migration target: Failure, destroying our copy.\n");
 
-        rc2 = libxl_domain_destroy(ctx, domid, 1);
+        rc2 = libxl_domain_destroy(ctx, domid);
         if (rc2) {
             fprintf(stderr, "migration target: Failed to destroy our copy"
                     " (code %d).\n", rc2);
diff -r 7dbba8f9706d -r 1beeb56e336a tools/python/xen/lowlevel/xl/xl.c
--- a/tools/python/xen/lowlevel/xl/xl.c	Thu Dec 15 10:00:09 2011 +0100
+++ b/tools/python/xen/lowlevel/xl/xl.c	Thu Dec 15 10:00:09 2011 +0100
@@ -437,10 +437,10 @@ static PyObject *pyxl_domain_shutdown(Xl
 
 static PyObject *pyxl_domain_destroy(XlObject *self, PyObject *args)
 {
-    int domid, force = 1;
-    if ( !PyArg_ParseTuple(args, "i|i", &domid, &force) )
+    int domid;
+    if ( !PyArg_ParseTuple(args, "i", &domid) )
         return NULL;
-    if ( libxl_domain_destroy(self->ctx, domid, force) ) {
+    if ( libxl_domain_destroy(self->ctx, domid) ) {
         PyErr_SetString(xl_error_obj, "cannot destroy domain");
         return NULL;
     }

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 15:17:53 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 15:17:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbD48-0003zt-AO; Thu, 15 Dec 2011 15:17:48 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RbD47-0003vH-37
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 15:17:47 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1323962225!7409341!5
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8287 invoked from network); 15 Dec 2011 15:17:40 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 15:17:40 -0000
Received: by mail-ww0-f43.google.com with SMTP id ds11so3581748wgb.24
	for <xen-devel@lists.xensource.com>;
	Thu, 15 Dec 2011 07:17:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=2gcwv8sanw6E/xMLowGA1yGI9J+E9nqhXF8PLX2AvmY=;
	b=jxzeVQhOGf87IuImcWnuUcWqDlzN4IiIETZPeUsY3HRbDL7R/VGyixX+6/OnwN5te0
	LlMimXVR0vaxx1DazTPws842bWMMdAr1vnz/e3ESw3t7SySwsGsE5C7cnyx6+SvHfQw4
	fk+sn66KnpCfvQZUzvfkz/i4jz6nnVdeVSzsE=
Received: by 10.227.208.81 with SMTP id gb17mr2624398wbb.26.1323962260700;
	Thu, 15 Dec 2011 07:17:40 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id hb10sm8693212wib.16.2011.12.15.07.17.38
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 15 Dec 2011 07:17:39 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 7dbba8f9706d3a1ea777df23f1d40b2da951ef4a
Message-Id: <7dbba8f9706d3a1ea777.1323961646@loki.upc.es>
In-Reply-To: <patchbomb.1323961634@loki.upc.es>
References: <patchbomb.1323961634@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Thu, 15 Dec 2011 16:07:26 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 12 of 15 v5] libxl: remove frontend and execute
 hotplug scripts on domain destroy
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1323939609 -3600
# Node ID 7dbba8f9706d3a1ea777df23f1d40b2da951ef4a
# Parent  f3d3a0a74f55f07616abc4bac95f82868b91fe9f
libxl: remove frontend and execute hotplug scripts on domain destroy

Removes frontend path on domain destruction and waits for devices to
be disconnected before executing hotplug scripts (call
libxl__device_remove to wait for detaching).

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r f3d3a0a74f55 -r 7dbba8f9706d tools/libxl/libxl_device.c
--- a/tools/libxl/libxl_device.c	Thu Dec 15 10:00:09 2011 +0100
+++ b/tools/libxl/libxl_device.c	Thu Dec 15 10:00:09 2011 +0100
@@ -492,19 +492,17 @@ int libxl__device_destroy(libxl__gc *gc,
     libxl_ctx *ctx = libxl__gc_owner(gc);
     char *be_path = libxl__device_backend_path(gc, dev);
     char *fe_path = libxl__device_frontend_path(gc, dev);
+    int rc;
 
-    /* 
-     * Run hotplug scripts, which will probably not be able to
-     * execute successfully since the device may still be plugged
-     */
-    libxl__device_hotplug(gc, dev, DISCONNECT);
+    xs_rm(ctx->xsh, XBT_NULL, fe_path);
+    /* Wait for backend status to disconnect */
+    rc = libxl__device_remove(gc, dev, 1);
 
     xs_rm(ctx->xsh, XBT_NULL, be_path);
-    xs_rm(ctx->xsh, XBT_NULL, fe_path);
 
     libxl__device_destroy_tapdisk(gc, be_path);
 
-    return 0;
+    return rc;
 }
 
 int libxl__devices_destroy(libxl__gc *gc, uint32_t domid, int force)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 15:17:53 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 15:17:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbD48-0003zt-AO; Thu, 15 Dec 2011 15:17:48 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RbD47-0003vH-37
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 15:17:47 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1323962225!7409341!5
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8287 invoked from network); 15 Dec 2011 15:17:40 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 15:17:40 -0000
Received: by mail-ww0-f43.google.com with SMTP id ds11so3581748wgb.24
	for <xen-devel@lists.xensource.com>;
	Thu, 15 Dec 2011 07:17:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=2gcwv8sanw6E/xMLowGA1yGI9J+E9nqhXF8PLX2AvmY=;
	b=jxzeVQhOGf87IuImcWnuUcWqDlzN4IiIETZPeUsY3HRbDL7R/VGyixX+6/OnwN5te0
	LlMimXVR0vaxx1DazTPws842bWMMdAr1vnz/e3ESw3t7SySwsGsE5C7cnyx6+SvHfQw4
	fk+sn66KnpCfvQZUzvfkz/i4jz6nnVdeVSzsE=
Received: by 10.227.208.81 with SMTP id gb17mr2624398wbb.26.1323962260700;
	Thu, 15 Dec 2011 07:17:40 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id hb10sm8693212wib.16.2011.12.15.07.17.38
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 15 Dec 2011 07:17:39 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 7dbba8f9706d3a1ea777df23f1d40b2da951ef4a
Message-Id: <7dbba8f9706d3a1ea777.1323961646@loki.upc.es>
In-Reply-To: <patchbomb.1323961634@loki.upc.es>
References: <patchbomb.1323961634@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Thu, 15 Dec 2011 16:07:26 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 12 of 15 v5] libxl: remove frontend and execute
 hotplug scripts on domain destroy
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1323939609 -3600
# Node ID 7dbba8f9706d3a1ea777df23f1d40b2da951ef4a
# Parent  f3d3a0a74f55f07616abc4bac95f82868b91fe9f
libxl: remove frontend and execute hotplug scripts on domain destroy

Removes frontend path on domain destruction and waits for devices to
be disconnected before executing hotplug scripts (call
libxl__device_remove to wait for detaching).

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r f3d3a0a74f55 -r 7dbba8f9706d tools/libxl/libxl_device.c
--- a/tools/libxl/libxl_device.c	Thu Dec 15 10:00:09 2011 +0100
+++ b/tools/libxl/libxl_device.c	Thu Dec 15 10:00:09 2011 +0100
@@ -492,19 +492,17 @@ int libxl__device_destroy(libxl__gc *gc,
     libxl_ctx *ctx = libxl__gc_owner(gc);
     char *be_path = libxl__device_backend_path(gc, dev);
     char *fe_path = libxl__device_frontend_path(gc, dev);
+    int rc;
 
-    /* 
-     * Run hotplug scripts, which will probably not be able to
-     * execute successfully since the device may still be plugged
-     */
-    libxl__device_hotplug(gc, dev, DISCONNECT);
+    xs_rm(ctx->xsh, XBT_NULL, fe_path);
+    /* Wait for backend status to disconnect */
+    rc = libxl__device_remove(gc, dev, 1);
 
     xs_rm(ctx->xsh, XBT_NULL, be_path);
-    xs_rm(ctx->xsh, XBT_NULL, fe_path);
 
     libxl__device_destroy_tapdisk(gc, be_path);
 
-    return 0;
+    return rc;
 }
 
 int libxl__devices_destroy(libxl__gc *gc, uint32_t domid, int force)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 15:17:54 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 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.xensource.com>)
	id 1RbD4B-00043X-OY; Thu, 15 Dec 2011 15:17:51 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RbD4B-0003xn-1b
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 15:17:51 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1323962229!7357491!4
X-Originating-IP: [209.85.161.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10380 invoked from network); 15 Dec 2011 15:17:44 -0000
Received: from mail-fx0-f43.google.com (HELO mail-fx0-f43.google.com)
	(209.85.161.43)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 15:17:44 -0000
Received: by mail-fx0-f43.google.com with SMTP id p21so5275311faa.30
	for <xen-devel@lists.xensource.com>;
	Thu, 15 Dec 2011 07:17:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=MpR2yP+iCv1qJWNktx+ZghTl/RGUJXAvIQ48kedY6rI=;
	b=cq3Rr2bJJd0Q/Nuzy696N8xnXjq14Kjtce9oElTvXGyJ0qCfYLGW791CepYV7htBkg
	wFzO7TpL0Jv6QdzPqpuNbkxQBw1iQePPou83OWtSR4UaD4BHJc1LuKQBZinasAWBExwX
	5vMGYAVV3+5/a0lxbeKS8CwOTGidj1TIftd+M=
Received: by 10.180.92.164 with SMTP id cn4mr5964627wib.12.1323962264700;
	Thu, 15 Dec 2011 07:17:44 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id hb10sm8693212wib.16.2011.12.15.07.17.42
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 15 Dec 2011 07:17:43 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 97d3104a544c067400c17e252641694790b6cf16
Message-Id: <97d3104a544c067400c1.1323961648@loki.upc.es>
In-Reply-To: <patchbomb.1323961634@loki.upc.es>
References: <patchbomb.1323961634@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Thu, 15 Dec 2011 16:07:28 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 14 of 15 v5] libxl: remove force parameter from
 libxl__devices_destroy
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1323939609 -3600
# Node ID 97d3104a544c067400c17e252641694790b6cf16
# Parent  1beeb56e336aef8f95bd3dcead953feb6d383544
libxl: remove force parameter from libxl__devices_destroy

Remove the force flag, and always use forced destruction.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 1beeb56e336a -r 97d3104a544c tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Thu Dec 15 10:00:09 2011 +0100
+++ b/tools/libxl/libxl.c	Thu Dec 15 10:00:09 2011 +0100
@@ -772,7 +772,7 @@ int libxl_domain_destroy(libxl_ctx *ctx,
 
         libxl__qmp_cleanup(gc, domid);
     }
-    if (libxl__devices_destroy(gc, domid, 1) < 0)
+    if (libxl__devices_destroy(gc, domid) < 0)
         LIBXL__LOG(ctx, LIBXL__LOG_ERROR, 
                    "libxl__devices_destroy failed for %d", domid);
 
diff -r 1beeb56e336a -r 97d3104a544c tools/libxl/libxl_device.c
--- a/tools/libxl/libxl_device.c	Thu Dec 15 10:00:09 2011 +0100
+++ b/tools/libxl/libxl_device.c	Thu Dec 15 10:00:09 2011 +0100
@@ -505,13 +505,13 @@ int libxl__device_destroy(libxl__gc *gc,
     return rc;
 }
 
-int libxl__devices_destroy(libxl__gc *gc, uint32_t domid, int force)
+int libxl__devices_destroy(libxl__gc *gc, uint32_t domid)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
     char *path;
     unsigned int num_kinds, num_devs;
     char **kinds = NULL, **devs = NULL;
-    int i, j, n_watches = 0;
+    int i, j;
     libxl__device dev;
     libxl__device_kind kind;
 
@@ -542,16 +542,7 @@ int libxl__devices_destroy(libxl__gc *gc
                 dev.kind = kind;
                 dev.devid = atoi(devs[j]);
 
-                if (force) {
-                    libxl__device_destroy(gc, &dev);
-                } else {
-                    int rc = libxl__device_remove(gc, &dev, 0);
-                    if (rc < 0)
-                        LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
-                                   "cannot remove device %s\n", path);
-                    else
-                        n_watches += rc;
-                }
+                libxl__device_destroy(gc, &dev);
             }
         }
     }
@@ -565,37 +556,9 @@ int libxl__devices_destroy(libxl__gc *gc
         dev.kind = LIBXL__DEVICE_KIND_CONSOLE;
         dev.devid = 0;
 
-        if (force) {
-            libxl__device_destroy(gc, &dev);
-        } else {
-            int rc = libxl__device_remove(gc, &dev, 0);
-            if (rc < 0)
-                LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
-                           "cannot remove device %s\n", path);
-            else
-                n_watches += rc;
-        }
+        libxl__device_destroy(gc, &dev);
     }
 
-    if (!force) {
-        /* Linux-ism. Most implementations leave the timeout
-         * untouched after select. Linux, however, will chip
-         * away the elapsed time from it, which is what we
-         * need to enforce a single time span waiting for
-         * device destruction. */
-        struct timeval tv;
-        tv.tv_sec = LIBXL_DESTROY_TIMEOUT;
-        tv.tv_usec = 0;
-        while (n_watches > 0) {
-            if (libxl__wait_for_device_state(gc, &tv, XenbusStateClosed,
-                                             destroy_device) < 0) {
-                /* function returned ERROR_* */
-                break;
-            } else {
-                n_watches--;
-            }
-        }
-    }
 out:
     return 0;
 }
diff -r 1beeb56e336a -r 97d3104a544c tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Thu Dec 15 10:00:09 2011 +0100
+++ b/tools/libxl/libxl_internal.h	Thu Dec 15 10:00:09 2011 +0100
@@ -271,7 +271,7 @@ _hidden int libxl__parse_backend_path(li
                                       libxl__device *dev);
 _hidden int libxl__device_remove(libxl__gc *gc, libxl__device *dev, int wait);
 _hidden int libxl__device_destroy(libxl__gc *gc, libxl__device *dev);
-_hidden int libxl__devices_destroy(libxl__gc *gc, uint32_t domid, int force);
+_hidden int libxl__devices_destroy(libxl__gc *gc, uint32_t domid);
 _hidden int libxl__wait_for_backend(libxl__gc *gc, char *be_path, char *state);
 
 /* Handler for the libxl__wait_for_device_state callback */

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 15:17:54 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 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.xensource.com>)
	id 1RbD4B-00043X-OY; Thu, 15 Dec 2011 15:17:51 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RbD4B-0003xn-1b
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 15:17:51 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1323962229!7357491!4
X-Originating-IP: [209.85.161.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10380 invoked from network); 15 Dec 2011 15:17:44 -0000
Received: from mail-fx0-f43.google.com (HELO mail-fx0-f43.google.com)
	(209.85.161.43)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 15:17:44 -0000
Received: by mail-fx0-f43.google.com with SMTP id p21so5275311faa.30
	for <xen-devel@lists.xensource.com>;
	Thu, 15 Dec 2011 07:17:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=MpR2yP+iCv1qJWNktx+ZghTl/RGUJXAvIQ48kedY6rI=;
	b=cq3Rr2bJJd0Q/Nuzy696N8xnXjq14Kjtce9oElTvXGyJ0qCfYLGW791CepYV7htBkg
	wFzO7TpL0Jv6QdzPqpuNbkxQBw1iQePPou83OWtSR4UaD4BHJc1LuKQBZinasAWBExwX
	5vMGYAVV3+5/a0lxbeKS8CwOTGidj1TIftd+M=
Received: by 10.180.92.164 with SMTP id cn4mr5964627wib.12.1323962264700;
	Thu, 15 Dec 2011 07:17:44 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id hb10sm8693212wib.16.2011.12.15.07.17.42
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 15 Dec 2011 07:17:43 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 97d3104a544c067400c17e252641694790b6cf16
Message-Id: <97d3104a544c067400c1.1323961648@loki.upc.es>
In-Reply-To: <patchbomb.1323961634@loki.upc.es>
References: <patchbomb.1323961634@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Thu, 15 Dec 2011 16:07:28 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 14 of 15 v5] libxl: remove force parameter from
 libxl__devices_destroy
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1323939609 -3600
# Node ID 97d3104a544c067400c17e252641694790b6cf16
# Parent  1beeb56e336aef8f95bd3dcead953feb6d383544
libxl: remove force parameter from libxl__devices_destroy

Remove the force flag, and always use forced destruction.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 1beeb56e336a -r 97d3104a544c tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Thu Dec 15 10:00:09 2011 +0100
+++ b/tools/libxl/libxl.c	Thu Dec 15 10:00:09 2011 +0100
@@ -772,7 +772,7 @@ int libxl_domain_destroy(libxl_ctx *ctx,
 
         libxl__qmp_cleanup(gc, domid);
     }
-    if (libxl__devices_destroy(gc, domid, 1) < 0)
+    if (libxl__devices_destroy(gc, domid) < 0)
         LIBXL__LOG(ctx, LIBXL__LOG_ERROR, 
                    "libxl__devices_destroy failed for %d", domid);
 
diff -r 1beeb56e336a -r 97d3104a544c tools/libxl/libxl_device.c
--- a/tools/libxl/libxl_device.c	Thu Dec 15 10:00:09 2011 +0100
+++ b/tools/libxl/libxl_device.c	Thu Dec 15 10:00:09 2011 +0100
@@ -505,13 +505,13 @@ int libxl__device_destroy(libxl__gc *gc,
     return rc;
 }
 
-int libxl__devices_destroy(libxl__gc *gc, uint32_t domid, int force)
+int libxl__devices_destroy(libxl__gc *gc, uint32_t domid)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
     char *path;
     unsigned int num_kinds, num_devs;
     char **kinds = NULL, **devs = NULL;
-    int i, j, n_watches = 0;
+    int i, j;
     libxl__device dev;
     libxl__device_kind kind;
 
@@ -542,16 +542,7 @@ int libxl__devices_destroy(libxl__gc *gc
                 dev.kind = kind;
                 dev.devid = atoi(devs[j]);
 
-                if (force) {
-                    libxl__device_destroy(gc, &dev);
-                } else {
-                    int rc = libxl__device_remove(gc, &dev, 0);
-                    if (rc < 0)
-                        LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
-                                   "cannot remove device %s\n", path);
-                    else
-                        n_watches += rc;
-                }
+                libxl__device_destroy(gc, &dev);
             }
         }
     }
@@ -565,37 +556,9 @@ int libxl__devices_destroy(libxl__gc *gc
         dev.kind = LIBXL__DEVICE_KIND_CONSOLE;
         dev.devid = 0;
 
-        if (force) {
-            libxl__device_destroy(gc, &dev);
-        } else {
-            int rc = libxl__device_remove(gc, &dev, 0);
-            if (rc < 0)
-                LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
-                           "cannot remove device %s\n", path);
-            else
-                n_watches += rc;
-        }
+        libxl__device_destroy(gc, &dev);
     }
 
-    if (!force) {
-        /* Linux-ism. Most implementations leave the timeout
-         * untouched after select. Linux, however, will chip
-         * away the elapsed time from it, which is what we
-         * need to enforce a single time span waiting for
-         * device destruction. */
-        struct timeval tv;
-        tv.tv_sec = LIBXL_DESTROY_TIMEOUT;
-        tv.tv_usec = 0;
-        while (n_watches > 0) {
-            if (libxl__wait_for_device_state(gc, &tv, XenbusStateClosed,
-                                             destroy_device) < 0) {
-                /* function returned ERROR_* */
-                break;
-            } else {
-                n_watches--;
-            }
-        }
-    }
 out:
     return 0;
 }
diff -r 1beeb56e336a -r 97d3104a544c tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Thu Dec 15 10:00:09 2011 +0100
+++ b/tools/libxl/libxl_internal.h	Thu Dec 15 10:00:09 2011 +0100
@@ -271,7 +271,7 @@ _hidden int libxl__parse_backend_path(li
                                       libxl__device *dev);
 _hidden int libxl__device_remove(libxl__gc *gc, libxl__device *dev, int wait);
 _hidden int libxl__device_destroy(libxl__gc *gc, libxl__device *dev);
-_hidden int libxl__devices_destroy(libxl__gc *gc, uint32_t domid, int force);
+_hidden int libxl__devices_destroy(libxl__gc *gc, uint32_t domid);
 _hidden int libxl__wait_for_backend(libxl__gc *gc, char *be_path, char *state);
 
 /* Handler for the libxl__wait_for_device_state callback */

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 15:17:57 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 15:17:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbD4E-00046t-HA; Thu, 15 Dec 2011 15:17:54 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RbD4C-0003zL-Vo
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 15:17:53 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1323962266!7013918!1
X-Originating-IP: [209.85.212.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21870 invoked from network); 15 Dec 2011 15:17:46 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 15:17:46 -0000
Received: by wics10 with SMTP id s10so209444wic.30
	for <xen-devel@lists.xensource.com>;
	Thu, 15 Dec 2011 07:17:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=L+eolYFDIJwbnFQDUzdMzGMySogrXYUmYMtLbjJQnPU=;
	b=a3YJX7edTnfZnxgVkFliuY8oltugQoJlufbZxTK3ZqMxAWv2X1SHz+Zoid+RE50Jiq
	nkFxzxDuGdnHF5fSCB3oa92+OUG2K9Oavn7xDlsTc5/cdViNxZEUkWGyT3fnQDrmbrFk
	CtSsYW4e6KLRwQdaalIj791C5Fwcxf/tX/duQ=
Received: by 10.180.77.42 with SMTP id p10mr5616602wiw.66.1323962266632;
	Thu, 15 Dec 2011 07:17:46 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id hb10sm8693212wib.16.2011.12.15.07.17.44
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 15 Dec 2011 07:17:45 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 759f27054f543cd57e008db4031fb7353c88fc20
Message-Id: <759f27054f543cd57e00.1323961649@loki.upc.es>
In-Reply-To: <patchbomb.1323961634@loki.upc.es>
References: <patchbomb.1323961634@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Thu, 15 Dec 2011 16:07:29 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 15 of 15 v5] libxl: fix mutex initialization
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1323939609 -3600
# Node ID 759f27054f543cd57e008db4031fb7353c88fc20
# Parent  97d3104a544c067400c17e252641694790b6cf16
libxl: fix mutex initialization

The macro PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP is not defined on
NetBSD, so define mutex attributes manually.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 97d3104a544c -r 759f27054f54 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Thu Dec 15 10:00:09 2011 +0100
+++ b/tools/libxl/libxl.c	Thu Dec 15 10:00:09 2011 +0100
@@ -41,7 +41,7 @@ int libxl_ctx_alloc(libxl_ctx **pctx, in
 {
     libxl_ctx *ctx;
     struct stat stat_buf;
-    const pthread_mutex_t mutex_value = PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP;
+    pthread_mutexattr_t attr;
 
     if (version != LIBXL_VERSION)
         return ERROR_VERSION;
@@ -55,10 +55,21 @@ int libxl_ctx_alloc(libxl_ctx **pctx, in
     memset(ctx, 0, sizeof(libxl_ctx));
     ctx->lg = lg;
 
-    /* This somewhat convoluted approach is needed because
-     * PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP is defined to be valid
-     * only as an initialiser, not as an expression. */
-    memcpy(&ctx->lock, &mutex_value, sizeof(ctx->lock));
+    if (pthread_mutexattr_init(&attr) != 0) {
+        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, 
+                         "Failed to init mutex attributes\n");
+        return ERROR_FAIL;
+    }
+    if (pthread_mutexattr_settype(&attr, PTHREAD_MUTEX_RECURSIVE) != 0) {
+        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, 
+                         "Failed to set mutex attributes\n");
+        return ERROR_FAIL;
+    }
+    if (pthread_mutex_init(&ctx->lock, &attr) != 0) {
+        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, 
+                         "Failed to init mutex\n");
+        return ERROR_FAIL;
+    }
 
     if ( stat(XENSTORE_PID_FILE, &stat_buf) != 0 ) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "Is xenstore daemon running?\n"

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 15:17:57 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 15:17:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbD4E-00046t-HA; Thu, 15 Dec 2011 15:17:54 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RbD4C-0003zL-Vo
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 15:17:53 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1323962266!7013918!1
X-Originating-IP: [209.85.212.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21870 invoked from network); 15 Dec 2011 15:17:46 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 15:17:46 -0000
Received: by wics10 with SMTP id s10so209444wic.30
	for <xen-devel@lists.xensource.com>;
	Thu, 15 Dec 2011 07:17:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=L+eolYFDIJwbnFQDUzdMzGMySogrXYUmYMtLbjJQnPU=;
	b=a3YJX7edTnfZnxgVkFliuY8oltugQoJlufbZxTK3ZqMxAWv2X1SHz+Zoid+RE50Jiq
	nkFxzxDuGdnHF5fSCB3oa92+OUG2K9Oavn7xDlsTc5/cdViNxZEUkWGyT3fnQDrmbrFk
	CtSsYW4e6KLRwQdaalIj791C5Fwcxf/tX/duQ=
Received: by 10.180.77.42 with SMTP id p10mr5616602wiw.66.1323962266632;
	Thu, 15 Dec 2011 07:17:46 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id hb10sm8693212wib.16.2011.12.15.07.17.44
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 15 Dec 2011 07:17:45 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 759f27054f543cd57e008db4031fb7353c88fc20
Message-Id: <759f27054f543cd57e00.1323961649@loki.upc.es>
In-Reply-To: <patchbomb.1323961634@loki.upc.es>
References: <patchbomb.1323961634@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Thu, 15 Dec 2011 16:07:29 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 15 of 15 v5] libxl: fix mutex initialization
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1323939609 -3600
# Node ID 759f27054f543cd57e008db4031fb7353c88fc20
# Parent  97d3104a544c067400c17e252641694790b6cf16
libxl: fix mutex initialization

The macro PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP is not defined on
NetBSD, so define mutex attributes manually.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 97d3104a544c -r 759f27054f54 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Thu Dec 15 10:00:09 2011 +0100
+++ b/tools/libxl/libxl.c	Thu Dec 15 10:00:09 2011 +0100
@@ -41,7 +41,7 @@ int libxl_ctx_alloc(libxl_ctx **pctx, in
 {
     libxl_ctx *ctx;
     struct stat stat_buf;
-    const pthread_mutex_t mutex_value = PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP;
+    pthread_mutexattr_t attr;
 
     if (version != LIBXL_VERSION)
         return ERROR_VERSION;
@@ -55,10 +55,21 @@ int libxl_ctx_alloc(libxl_ctx **pctx, in
     memset(ctx, 0, sizeof(libxl_ctx));
     ctx->lg = lg;
 
-    /* This somewhat convoluted approach is needed because
-     * PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP is defined to be valid
-     * only as an initialiser, not as an expression. */
-    memcpy(&ctx->lock, &mutex_value, sizeof(ctx->lock));
+    if (pthread_mutexattr_init(&attr) != 0) {
+        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, 
+                         "Failed to init mutex attributes\n");
+        return ERROR_FAIL;
+    }
+    if (pthread_mutexattr_settype(&attr, PTHREAD_MUTEX_RECURSIVE) != 0) {
+        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, 
+                         "Failed to set mutex attributes\n");
+        return ERROR_FAIL;
+    }
+    if (pthread_mutex_init(&ctx->lock, &attr) != 0) {
+        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, 
+                         "Failed to init mutex\n");
+        return ERROR_FAIL;
+    }
 
     if ( stat(XENSTORE_PID_FILE, &stat_buf) != 0 ) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "Is xenstore daemon running?\n"

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 15:19:34 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 15:19:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbD5m-0004vA-7F; Thu, 15 Dec 2011 15:19:30 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RbD5k-0004sS-Vs
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 15:19:29 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1323962362!7546291!1
X-Originating-IP: [209.85.161.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25297 invoked from network); 15 Dec 2011 15:19:22 -0000
Received: from mail-fx0-f43.google.com (HELO mail-fx0-f43.google.com)
	(209.85.161.43)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 15:19:22 -0000
Received: by faap21 with SMTP id p21so5282562faa.30
	for <xen-devel@lists.xensource.com>;
	Thu, 15 Dec 2011 07:19:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=nFr70GUTEyqix1Z7T1GVADk2wmV/ZaSIeMSZIC+M3+g=;
	b=W68Y2bwdGQ0vD24ayj7WhFJXvDqfRTB+i2Pt/NBO9UNnYvWp97/HMRMQ54Z4wvSGrT
	wnyU15V6TKcRjLEQLkawMp9B3xtmGVD+gFVInaldm+jFH7JcSlDuwRn4g7Dr3dvJamHI
	LyHauiY8e258O9BGC89sgFivaPTIljCLHLdCA=
Received: by 10.180.103.170 with SMTP id fx10mr5479055wib.56.1323962255082;
	Thu, 15 Dec 2011 07:17:35 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id hb10sm8693212wib.16.2011.12.15.07.17.30
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 15 Dec 2011 07:17:32 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 6a05eb37ecdd7122eb7ad7d0bea1879a7f1a3c6c
Message-Id: <6a05eb37ecdd7122eb7a.1323961644@loki.upc.es>
In-Reply-To: <patchbomb.1323961634@loki.upc.es>
References: <patchbomb.1323961634@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Thu, 15 Dec 2011 16:07:24 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 10 of 15 v5] NetBSD/xencommons: remove xend
 precmd folder creation
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1323939598 -3600
# Node ID 6a05eb37ecdd7122eb7ad7d0bea1879a7f1a3c6c
# Parent  663e02a5360ce3d48ce732f9c40087e5ca4323d3
NetBSD/xencommons: remove xend precmd folder creation

Since xend is not started by xencommons move the creation of the
necessary xend folders to xend init script.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 663e02a5360c -r 6a05eb37ecdd tools/hotplug/NetBSD/rc.d/xencommons
--- a/tools/hotplug/NetBSD/rc.d/xencommons	Fri Sep 30 14:38:55 2011 +0200
+++ b/tools/hotplug/NetBSD/rc.d/xencommons	Thu Dec 15 09:59:58 2011 +0100
@@ -27,8 +27,6 @@ XENCONSOLED_PIDFILE="/var/run/xenconsole
 
 xen_precmd()
 {
-	mkdir -p /var/run/xend || exit 1
-	mkdir -p /var/run/xend/boot || exit 1
 	mkdir -p /var/run/xenstored || exit 1
 }
 
diff -r 663e02a5360c -r 6a05eb37ecdd tools/hotplug/NetBSD/rc.d/xend
--- a/tools/hotplug/NetBSD/rc.d/xend	Fri Sep 30 14:38:55 2011 +0200
+++ b/tools/hotplug/NetBSD/rc.d/xend	Thu Dec 15 09:59:58 2011 +0100
@@ -15,10 +15,17 @@ export PATH
 
 name="xend"
 rcvar=$name
+start_precmd="xen_precmd"
 command="${SBINDIR}/xend"
 command_args="start"
 command_interpreter=`head -n 1 ${command} | awk '{ print substr($0,3) }'`
 sig_stop="SIGKILL"
 
+xen_precmd()
+{
+	mkdir -p /var/run/xend || exit 1
+	mkdir -p /var/run/xend/boot || exit 1
+}
+
 load_rc_config $name
 run_rc_command "$1"

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 15:19:34 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 15:19:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbD5m-0004vA-7F; Thu, 15 Dec 2011 15:19:30 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RbD5k-0004sS-Vs
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 15:19:29 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1323962362!7546291!1
X-Originating-IP: [209.85.161.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25297 invoked from network); 15 Dec 2011 15:19:22 -0000
Received: from mail-fx0-f43.google.com (HELO mail-fx0-f43.google.com)
	(209.85.161.43)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 15:19:22 -0000
Received: by faap21 with SMTP id p21so5282562faa.30
	for <xen-devel@lists.xensource.com>;
	Thu, 15 Dec 2011 07:19:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=nFr70GUTEyqix1Z7T1GVADk2wmV/ZaSIeMSZIC+M3+g=;
	b=W68Y2bwdGQ0vD24ayj7WhFJXvDqfRTB+i2Pt/NBO9UNnYvWp97/HMRMQ54Z4wvSGrT
	wnyU15V6TKcRjLEQLkawMp9B3xtmGVD+gFVInaldm+jFH7JcSlDuwRn4g7Dr3dvJamHI
	LyHauiY8e258O9BGC89sgFivaPTIljCLHLdCA=
Received: by 10.180.103.170 with SMTP id fx10mr5479055wib.56.1323962255082;
	Thu, 15 Dec 2011 07:17:35 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id hb10sm8693212wib.16.2011.12.15.07.17.30
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 15 Dec 2011 07:17:32 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 6a05eb37ecdd7122eb7ad7d0bea1879a7f1a3c6c
Message-Id: <6a05eb37ecdd7122eb7a.1323961644@loki.upc.es>
In-Reply-To: <patchbomb.1323961634@loki.upc.es>
References: <patchbomb.1323961634@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Thu, 15 Dec 2011 16:07:24 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 10 of 15 v5] NetBSD/xencommons: remove xend
 precmd folder creation
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1323939598 -3600
# Node ID 6a05eb37ecdd7122eb7ad7d0bea1879a7f1a3c6c
# Parent  663e02a5360ce3d48ce732f9c40087e5ca4323d3
NetBSD/xencommons: remove xend precmd folder creation

Since xend is not started by xencommons move the creation of the
necessary xend folders to xend init script.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 663e02a5360c -r 6a05eb37ecdd tools/hotplug/NetBSD/rc.d/xencommons
--- a/tools/hotplug/NetBSD/rc.d/xencommons	Fri Sep 30 14:38:55 2011 +0200
+++ b/tools/hotplug/NetBSD/rc.d/xencommons	Thu Dec 15 09:59:58 2011 +0100
@@ -27,8 +27,6 @@ XENCONSOLED_PIDFILE="/var/run/xenconsole
 
 xen_precmd()
 {
-	mkdir -p /var/run/xend || exit 1
-	mkdir -p /var/run/xend/boot || exit 1
 	mkdir -p /var/run/xenstored || exit 1
 }
 
diff -r 663e02a5360c -r 6a05eb37ecdd tools/hotplug/NetBSD/rc.d/xend
--- a/tools/hotplug/NetBSD/rc.d/xend	Fri Sep 30 14:38:55 2011 +0200
+++ b/tools/hotplug/NetBSD/rc.d/xend	Thu Dec 15 09:59:58 2011 +0100
@@ -15,10 +15,17 @@ export PATH
 
 name="xend"
 rcvar=$name
+start_precmd="xen_precmd"
 command="${SBINDIR}/xend"
 command_args="start"
 command_interpreter=`head -n 1 ${command} | awk '{ print substr($0,3) }'`
 sig_stop="SIGKILL"
 
+xen_precmd()
+{
+	mkdir -p /var/run/xend || exit 1
+	mkdir -p /var/run/xend/boot || exit 1
+}
+
 load_rc_config $name
 run_rc_command "$1"

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 15:36:07 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 15: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.xensource.com>)
	id 1RbDLf-0006ke-KZ; Thu, 15 Dec 2011 15:35:55 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RbDLd-0006kW-SR
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 15:35:54 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1323963239!56332499!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjI2MA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25104 invoked from network); 15 Dec 2011 15:33:59 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 15:33:59 -0000
X-IronPort-AV: E=Sophos;i="4.71,357,1320624000"; 
   d="scan'208";a="9494183"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Dec 2011 15:35:49 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 15 Dec 2011 15:35:49 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Thu, 15 Dec 2011 15:35:49 +0000
In-Reply-To: <20202.2016.788485.260971@mariner.uk.xensource.com>
References: <patchbomb.1323792779@cosworth.uk.xensource.com>
	<1323941785.20077.447.camel@zakaz.uk.xensource.com>
	<20202.2016.788485.260971@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323963349.20077.494.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Olaf Hering <olaf@aepfle.de>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Vincent Hanquez <Vincent.Hanquez@eu.citrix.com>,
	Jonathan Ludlam <Jonathan.Ludlam@eu.citrix.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH 0 of 4 V2] oxenstored fixes -- fixes recent
 pvops kernel hang
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2011-12-15 at 14:44 +0000, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [PATCH 0 of 4 V2] oxenstored fixes -- fixes recent pvops kernel hang"):
> > On Tue, 2011-12-13 at 16:12 +0000, Ian Campbell wrote:
> > > I also include a patch which I've been using for some time to enable
> > > the use of oxenstored in preference to C xenstored when available.
> > 
> > Can you also arrange for the test system to
> > collect /etc/xen/oxenstored.conf, /var/log/xenstored.conf*
> > and /var/log/xenstored-access.log* please.
> 
> I hadn't spotted these filenames in the source for oxenstored.
> "/var/log/xenstored.conf*" ?!  omg wtf bbq

Sorry, that's my typo, I meant /var/log/xenstored.log*. The .conf name
under /etc/xen is correct.

> Surely these should all be in /var/log/xen.

Could move them I guess. I'd like to hear from Jon and the XCP chaps
though. Patch would be the following, I think.

Ian.

diff -r 0ddea44c2a7f tools/ocaml/xenstored/logging.ml
--- a/tools/ocaml/xenstored/logging.ml	Thu Dec 15 11:52:48 2011 +0000
+++ b/tools/ocaml/xenstored/logging.ml	Thu Dec 15 15:35:39 2011 +0000
@@ -104,7 +104,7 @@ let string_of_date () =
 		tm.Unix.tm_hour tm.Unix.tm_min tm.Unix.tm_sec
 		(int_of_float (1000.0 *. msec))
 
-let xenstored_log_file = ref "/var/log/xenstored.log"
+let xenstored_log_file = ref "/var/log/xen/xenstored.log"
 let xenstored_log_level = ref Warn
 let xenstored_log_nb_files = ref 10
 let xenstored_log_nb_lines = ref 13215
@@ -200,7 +200,7 @@ let sanitize_data data =
 	String.escaped data
 
 let activate_access_log = ref true
-let access_log_file = ref "/var/log/xenstored-access.log"
+let access_log_file = ref "/var/log/xen/xenstored-access.log"
 let access_log_nb_files = ref 20
 let access_log_nb_lines = ref 13215
 let access_log_nb_chars = ref 180
diff -r 0ddea44c2a7f tools/ocaml/xenstored/oxenstored.conf
--- a/tools/ocaml/xenstored/oxenstored.conf	Thu Dec 15 11:52:48 2011 +0000
+++ b/tools/ocaml/xenstored/oxenstored.conf	Thu Dec 15 15:35:39 2011 +0000
@@ -23,12 +23,12 @@ quota-transaction = 10
 persistant = false
 
 # Xenstored logs
-# xenstored-log-file = /var/log/xenstored.log
+# xenstored-log-file = /var/log/xen/xenstored.log
 # xenstored-log-level = null
 # xenstored-log-nb-files = 10
 
 # Xenstored access logs
-# access-log-file = /var/log/xenstored-access.log
+# access-log-file = /var/log/xen/xenstored-access.log
 # access-log-nb-lines = 13215
 # acesss-log-nb-chars = 180
 # access-log-special-ops = false



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 15:36:07 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 15: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.xensource.com>)
	id 1RbDLf-0006ke-KZ; Thu, 15 Dec 2011 15:35:55 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RbDLd-0006kW-SR
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 15:35:54 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1323963239!56332499!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjI2MA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25104 invoked from network); 15 Dec 2011 15:33:59 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 15:33:59 -0000
X-IronPort-AV: E=Sophos;i="4.71,357,1320624000"; 
   d="scan'208";a="9494183"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Dec 2011 15:35:49 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 15 Dec 2011 15:35:49 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Thu, 15 Dec 2011 15:35:49 +0000
In-Reply-To: <20202.2016.788485.260971@mariner.uk.xensource.com>
References: <patchbomb.1323792779@cosworth.uk.xensource.com>
	<1323941785.20077.447.camel@zakaz.uk.xensource.com>
	<20202.2016.788485.260971@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323963349.20077.494.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Olaf Hering <olaf@aepfle.de>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Vincent Hanquez <Vincent.Hanquez@eu.citrix.com>,
	Jonathan Ludlam <Jonathan.Ludlam@eu.citrix.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH 0 of 4 V2] oxenstored fixes -- fixes recent
 pvops kernel hang
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2011-12-15 at 14:44 +0000, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [PATCH 0 of 4 V2] oxenstored fixes -- fixes recent pvops kernel hang"):
> > On Tue, 2011-12-13 at 16:12 +0000, Ian Campbell wrote:
> > > I also include a patch which I've been using for some time to enable
> > > the use of oxenstored in preference to C xenstored when available.
> > 
> > Can you also arrange for the test system to
> > collect /etc/xen/oxenstored.conf, /var/log/xenstored.conf*
> > and /var/log/xenstored-access.log* please.
> 
> I hadn't spotted these filenames in the source for oxenstored.
> "/var/log/xenstored.conf*" ?!  omg wtf bbq

Sorry, that's my typo, I meant /var/log/xenstored.log*. The .conf name
under /etc/xen is correct.

> Surely these should all be in /var/log/xen.

Could move them I guess. I'd like to hear from Jon and the XCP chaps
though. Patch would be the following, I think.

Ian.

diff -r 0ddea44c2a7f tools/ocaml/xenstored/logging.ml
--- a/tools/ocaml/xenstored/logging.ml	Thu Dec 15 11:52:48 2011 +0000
+++ b/tools/ocaml/xenstored/logging.ml	Thu Dec 15 15:35:39 2011 +0000
@@ -104,7 +104,7 @@ let string_of_date () =
 		tm.Unix.tm_hour tm.Unix.tm_min tm.Unix.tm_sec
 		(int_of_float (1000.0 *. msec))
 
-let xenstored_log_file = ref "/var/log/xenstored.log"
+let xenstored_log_file = ref "/var/log/xen/xenstored.log"
 let xenstored_log_level = ref Warn
 let xenstored_log_nb_files = ref 10
 let xenstored_log_nb_lines = ref 13215
@@ -200,7 +200,7 @@ let sanitize_data data =
 	String.escaped data
 
 let activate_access_log = ref true
-let access_log_file = ref "/var/log/xenstored-access.log"
+let access_log_file = ref "/var/log/xen/xenstored-access.log"
 let access_log_nb_files = ref 20
 let access_log_nb_lines = ref 13215
 let access_log_nb_chars = ref 180
diff -r 0ddea44c2a7f tools/ocaml/xenstored/oxenstored.conf
--- a/tools/ocaml/xenstored/oxenstored.conf	Thu Dec 15 11:52:48 2011 +0000
+++ b/tools/ocaml/xenstored/oxenstored.conf	Thu Dec 15 15:35:39 2011 +0000
@@ -23,12 +23,12 @@ quota-transaction = 10
 persistant = false
 
 # Xenstored logs
-# xenstored-log-file = /var/log/xenstored.log
+# xenstored-log-file = /var/log/xen/xenstored.log
 # xenstored-log-level = null
 # xenstored-log-nb-files = 10
 
 # Xenstored access logs
-# access-log-file = /var/log/xenstored-access.log
+# access-log-file = /var/log/xen/xenstored-access.log
 # access-log-nb-lines = 13215
 # acesss-log-nb-chars = 180
 # access-log-special-ops = false



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 15:51:25 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 15:51:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbDaQ-0007Qs-Re; Thu, 15 Dec 2011 15:51:10 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RbDaP-0007Qd-2l
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 15:51:09 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1323964262!7597276!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjI2MA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16285 invoked from network); 15 Dec 2011 15:51:03 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 15:51:03 -0000
X-IronPort-AV: E=Sophos;i="4.71,357,1320624000"; 
   d="scan'208";a="9494930"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Dec 2011 15:51:02 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 15 Dec 2011 15:51:02 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RbDaI-00073l-Ki;
	Thu, 15 Dec 2011 15:51:02 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RbDaI-00064G-6d;
	Thu, 15 Dec 2011 15:51:02 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10501-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 15 Dec 2011 15:51:02 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing test] 10501: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10501 xen-4.1-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10501/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 10450
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  bb365e21314d
baseline version:
 xen                  1c89f7d29fbb

------------------------------------------------------------
People who touched revisions under test:
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  George Dunlap <george.dunlap@eu.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Olaf Hering <olaf@aepfle.de>
  Tim Deegan <tim@xen.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-4.1-testing
+ revision=bb365e21314d
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-4.1-testing bb365e21314d
+ branch=xen-4.1-testing
+ revision=bb365e21314d
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ : xen@xenbits.xensource.com
+ : xen@xenbits.xensource.com:git/linux-pvops
+ : master
+ : tested/2.6.39.x
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-4.1-testing.hg
+ hg push -r bb365e21314d ssh://xen@xenbits.xensource.com/HG/xen-4.1-testing.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-4.1-testing.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 1 changesets with 1 changes to 1 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 15:51:25 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 15:51:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbDaQ-0007Qs-Re; Thu, 15 Dec 2011 15:51:10 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RbDaP-0007Qd-2l
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 15:51:09 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1323964262!7597276!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjI2MA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16285 invoked from network); 15 Dec 2011 15:51:03 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 15:51:03 -0000
X-IronPort-AV: E=Sophos;i="4.71,357,1320624000"; 
   d="scan'208";a="9494930"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Dec 2011 15:51:02 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 15 Dec 2011 15:51:02 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RbDaI-00073l-Ki;
	Thu, 15 Dec 2011 15:51:02 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RbDaI-00064G-6d;
	Thu, 15 Dec 2011 15:51:02 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10501-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 15 Dec 2011 15:51:02 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing test] 10501: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10501 xen-4.1-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10501/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 10450
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  bb365e21314d
baseline version:
 xen                  1c89f7d29fbb

------------------------------------------------------------
People who touched revisions under test:
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  George Dunlap <george.dunlap@eu.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Olaf Hering <olaf@aepfle.de>
  Tim Deegan <tim@xen.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-4.1-testing
+ revision=bb365e21314d
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-4.1-testing bb365e21314d
+ branch=xen-4.1-testing
+ revision=bb365e21314d
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ : xen@xenbits.xensource.com
+ : xen@xenbits.xensource.com:git/linux-pvops
+ : master
+ : tested/2.6.39.x
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-4.1-testing.hg
+ hg push -r bb365e21314d ssh://xen@xenbits.xensource.com/HG/xen-4.1-testing.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-4.1-testing.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 1 changesets with 1 changes to 1 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 15:53:44 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 15:53:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbDce-0007Xy-DF; Thu, 15 Dec 2011 15:53:28 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RbDcc-0007Xg-Lb
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 15:53:27 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1323964396!7614857!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2050 invoked from network); 15 Dec 2011 15:53:19 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-7.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 15 Dec 2011 15:53:19 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 15 Dec 2011 15:53:15 +0000
Message-Id: <4EEA25F902000078000683AA@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 15 Dec 2011 15:53:13 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part220D8BF9.0__="
Subject: [Xen-devel] [PATCH] linux-2.6.18: consolidate and simplify struct
 xenbus_driver instantiation
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__Part220D8BF9.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

The 'name' and 'owner' members are redundant with the identically named
fields in the 'driver' sub-structure. Rather than switching each
instance to specify these fields explicitly, introduce a macro to
simplify this (and at once to abstract out - for the unmodified drivers
build - the absence of the 'owner' field in Linux prior to 2.6.10).

Also add a module alias for the vtpm frontend driver (overlooked in
141:5e294e29a43e).

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/drivers/char/tpm/tpm_xen.c
+++ b/drivers/char/tpm/tpm_xen.c
@@ -475,26 +475,24 @@ static int tpmif_connect(struct xenbus_d
 	return 0;
 }
=20
-static struct xenbus_device_id tpmfront_ids[] =3D {
+static const struct xenbus_device_id tpmfront_ids[] =3D {
 	{ "vtpm" },
 	{ "" }
 };
+MODULE_ALIAS("xen:vtpm");
=20
-static struct xenbus_driver tpmfront =3D {
-	.name =3D "vtpm",
-	.owner =3D THIS_MODULE,
-	.ids =3D tpmfront_ids,
+static DEFINE_XENBUS_DRIVER(tpmfront, "vtpm",
 	.probe =3D tpmfront_probe,
 	.remove =3D  tpmfront_remove,
 	.resume =3D tpmfront_resume,
 	.otherend_changed =3D backend_changed,
 	.suspend =3D tpmfront_suspend,
 	.suspend_cancel =3D tpmfront_suspend_cancel,
-};
+);
=20
 static void __init init_tpm_xenbus(void)
 {
-	xenbus_register_frontend(&tpmfront);
+	xenbus_register_frontend(&tpmfront_driver);
 }
=20
 static int tpmif_allocate_tx_buffers(struct tpm_private *tp)
--- a/drivers/xen/blkback/xenbus.c
+++ b/drivers/xen/blkback/xenbus.c
@@ -542,18 +542,14 @@ static const struct xenbus_device_id blk
 	{ "" }
 };
=20
-
-static struct xenbus_driver blkback =3D {
-	.name =3D "vbd",
-	.owner =3D THIS_MODULE,
-	.ids =3D blkback_ids,
+static DEFINE_XENBUS_DRIVER(blkback, "vbd",
 	.probe =3D blkback_probe,
 	.remove =3D blkback_remove,
 	.otherend_changed =3D frontend_changed
-};
+);
=20
=20
 void blkif_xenbus_init(void)
 {
-	xenbus_register_backend(&blkback);
+	xenbus_register_backend(&blkback_driver);
 }
--- a/drivers/xen/blkfront/blkfront.c
+++ b/drivers/xen/blkfront/blkfront.c
@@ -934,16 +934,13 @@ static const struct xenbus_device_id blk
 };
 MODULE_ALIAS("xen:vbd");
=20
-static struct xenbus_driver blkfront =3D {
-	.name =3D "vbd",
-	.owner =3D THIS_MODULE,
-	.ids =3D blkfront_ids,
+static DEFINE_XENBUS_DRIVER(blkfront, "vbd",
 	.probe =3D blkfront_probe,
 	.remove =3D blkfront_remove,
 	.resume =3D blkfront_resume,
 	.otherend_changed =3D backend_changed,
 	.is_ready =3D blkfront_is_ready,
-};
+);
=20
=20
 static int __init xlblk_init(void)
@@ -951,14 +948,14 @@ static int __init xlblk_init(void)
 	if (!is_running_on_xen())
 		return -ENODEV;
=20
-	return xenbus_register_frontend(&blkfront);
+	return xenbus_register_frontend(&blkfront_driver);
 }
 module_init(xlblk_init);
=20
=20
 static void __exit xlblk_exit(void)
 {
-	return xenbus_unregister_driver(&blkfront);
+	return xenbus_unregister_driver(&blkfront_driver);
 }
 module_exit(xlblk_exit);
=20
--- a/drivers/xen/blktap/xenbus.c
+++ b/drivers/xen/blktap/xenbus.c
@@ -490,18 +490,14 @@ static const struct xenbus_device_id blk
 	{ "" }
 };
=20
-
-static struct xenbus_driver blktap =3D {
-	.name =3D "tap",
-	.owner =3D THIS_MODULE,
-	.ids =3D blktap_ids,
+static DEFINE_XENBUS_DRIVER(blktap, "tap",
 	.probe =3D blktap_probe,
 	.remove =3D blktap_remove,
 	.otherend_changed =3D tap_frontend_changed
-};
+);
=20
=20
 void tap_blkif_xenbus_init(void)
 {
-	xenbus_register_backend(&blktap);
+	xenbus_register_backend(&blktap_driver);
 }
--- a/drivers/xen/fbfront/xenfb.c
+++ b/drivers/xen/fbfront/xenfb.c
@@ -857,15 +857,12 @@ static const struct xenbus_device_id xen
 };
 MODULE_ALIAS("xen:vfb");
=20
-static struct xenbus_driver xenfb_driver =3D {
-	.name =3D "vfb",
-	.owner =3D THIS_MODULE,
-	.ids =3D xenfb_ids,
+static DEFINE_XENBUS_DRIVER(xenfb, "vfb",
 	.probe =3D xenfb_probe,
 	.remove =3D xenfb_remove,
 	.resume =3D xenfb_resume,
 	.otherend_changed =3D xenfb_backend_changed,
-};
+);
=20
 static int __init xenfb_init(void)
 {
--- a/drivers/xen/fbfront/xenkbd.c
+++ b/drivers/xen/fbfront/xenkbd.c
@@ -335,15 +335,12 @@ static const struct xenbus_device_id xen
 };
 MODULE_ALIAS("xen:vkbd");
=20
-static struct xenbus_driver xenkbd_driver =3D {
-	.name =3D "vkbd",
-	.owner =3D THIS_MODULE,
-	.ids =3D xenkbd_ids,
+static DEFINE_XENBUS_DRIVER(xenkbd, "vkbd",
 	.probe =3D xenkbd_probe,
 	.remove =3D xenkbd_remove,
 	.resume =3D xenkbd_resume,
 	.otherend_changed =3D xenkbd_backend_changed,
-};
+);
=20
 static int __init xenkbd_init(void)
 {
--- a/drivers/xen/netback/xenbus.c
+++ b/drivers/xen/netback/xenbus.c
@@ -437,19 +437,15 @@ static const struct xenbus_device_id net
 	{ "" }
 };
=20
-
-static struct xenbus_driver netback =3D {
-	.name =3D "vif",
-	.owner =3D THIS_MODULE,
-	.ids =3D netback_ids,
+static DEFINE_XENBUS_DRIVER(netback, "vif",
 	.probe =3D netback_probe,
 	.remove =3D netback_remove,
 	.uevent =3D netback_uevent,
 	.otherend_changed =3D frontend_changed,
-};
+);
=20
=20
 void netif_xenbus_init(void)
 {
-	xenbus_register_backend(&netback);
+	xenbus_register_backend(&netback_driver);
 }
--- a/drivers/xen/netfront/netfront.c
+++ b/drivers/xen/netfront/netfront.c
@@ -2197,18 +2197,14 @@ static const struct xenbus_device_id net
 };
 MODULE_ALIAS("xen:vif");
=20
-
-static struct xenbus_driver netfront_driver =3D {
-	.name =3D "vif",
-	.owner =3D THIS_MODULE,
-	.ids =3D netfront_ids,
+static DEFINE_XENBUS_DRIVER(netfront, "vif",
 	.probe =3D netfront_probe,
 	.remove =3D __devexit_p(netfront_remove),
 	.suspend =3D netfront_suspend,
 	.suspend_cancel =3D netfront_suspend_cancel,
 	.resume =3D netfront_resume,
 	.otherend_changed =3D backend_changed,
-};
+);
=20
=20
 static int __init netif_init(void)
--- a/drivers/xen/pciback/xenbus.c
+++ b/drivers/xen/pciback/xenbus.c
@@ -676,19 +676,16 @@ static int pciback_xenbus_remove(struct=20
 	return 0;
 }
=20
-static const struct xenbus_device_id xenpci_ids[] =3D {
+static const struct xenbus_device_id pciback_ids[] =3D {
 	{"pci"},
 	{{0}},
 };
=20
-static struct xenbus_driver xenbus_pciback_driver =3D {
-	.name 			=3D "pciback",
-	.owner 			=3D THIS_MODULE,
-	.ids 			=3D xenpci_ids,
+static DEFINE_XENBUS_DRIVER(pciback, "pciback",
 	.probe 			=3D pciback_xenbus_probe,
 	.remove 		=3D pciback_xenbus_remove,
 	.otherend_changed 	=3D pciback_frontend_changed,
-};
+);
=20
 int __init pciback_xenbus_register(void)
 {
@@ -700,11 +697,11 @@ int __init pciback_xenbus_register(void)
 			"pciback_workqueue failed\n");
 		return -EFAULT;
 	}
-	return xenbus_register_backend(&xenbus_pciback_driver);
+	return xenbus_register_backend(&pciback_driver);
 }
=20
 void __exit pciback_xenbus_unregister(void)
 {
 	destroy_workqueue(pciback_wq);
-	xenbus_unregister_driver(&xenbus_pciback_driver);
+	xenbus_unregister_driver(&pciback_driver);
 }
--- a/drivers/xen/pcifront/xenbus.c
+++ b/drivers/xen/pcifront/xenbus.c
@@ -456,27 +456,24 @@ static int pcifront_xenbus_remove(struct
 	return 0;
 }
=20
-static const struct xenbus_device_id xenpci_ids[] =3D {
+static const struct xenbus_device_id pcifront_ids[] =3D {
 	{"pci"},
 	{{0}},
 };
 MODULE_ALIAS("xen:pci");
=20
-static struct xenbus_driver xenbus_pcifront_driver =3D {
-	.name 			=3D "pcifront",
-	.owner 			=3D THIS_MODULE,
-	.ids 			=3D xenpci_ids,
+static DEFINE_XENBUS_DRIVER(pcifront, "pcifront",
 	.probe 			=3D pcifront_xenbus_probe,
 	.remove 		=3D pcifront_xenbus_remove,
 	.otherend_changed 	=3D pcifront_backend_changed,
-};
+);
=20
 static int __init pcifront_init(void)
 {
 	if (!is_running_on_xen())
 		return -ENODEV;
=20
-	return xenbus_register_frontend(&xenbus_pcifront_driver);
+	return xenbus_register_frontend(&pcifront_driver);
 }
=20
 /* Initialize after the Xen PCI Frontend Stub is initialized */
--- a/drivers/xen/scsiback/xenbus.c
+++ b/drivers/xen/scsiback/xenbus.c
@@ -352,26 +352,23 @@ fail:
 }
=20
=20
-static struct xenbus_device_id scsiback_ids[] =3D {
+static const struct xenbus_device_id scsiback_ids[] =3D {
 	{ "vscsi" },
 	{ "" }
 };
=20
-static struct xenbus_driver scsiback =3D {
-	.name			=3D "vscsi",
-	.owner			=3D THIS_MODULE,
-	.ids			=3D scsiback_ids,
+static DEFINE_XENBUS_DRIVER(scsiback, "vscsi",
 	.probe			=3D scsiback_probe,
 	.remove			=3D scsiback_remove,
 	.otherend_changed	=3D scsiback_frontend_changed
-};
+);
=20
 int scsiback_xenbus_init(void)
 {
-	return xenbus_register_backend(&scsiback);
+	return xenbus_register_backend(&scsiback_driver);
 }
=20
 void scsiback_xenbus_unregister(void)
 {
-	xenbus_unregister_driver(&scsiback);
+	xenbus_unregister_driver(&scsiback_driver);
 }
--- a/drivers/xen/scsifront/xenbus.c
+++ b/drivers/xen/scsifront/xenbus.c
@@ -398,21 +398,18 @@ static void scsifront_backend_changed(st
 }
=20
=20
-static struct xenbus_device_id scsifront_ids[] =3D {
+static const struct xenbus_device_id scsifront_ids[] =3D {
 	{ "vscsi" },
 	{ "" }
 };
 MODULE_ALIAS("xen:vscsi");
=20
-static struct xenbus_driver scsifront_driver =3D {
-	.name			=3D "vscsi",
-	.owner			=3D THIS_MODULE,
-	.ids			=3D scsifront_ids,
+static DEFINE_XENBUS_DRIVER(scsifront, "vscsi",
 	.probe			=3D scsifront_probe,
 	.remove			=3D scsifront_remove,
 /* 	.resume			=3D scsifront_resume, */
 	.otherend_changed	=3D scsifront_backend_changed,
-};
+);
=20
 int scsifront_xenbus_init(void)
 {
--- a/drivers/xen/tpmback/xenbus.c
+++ b/drivers/xen/tpmback/xenbus.c
@@ -251,23 +251,19 @@ static const struct xenbus_device_id tpm
 	{ "" }
 };
=20
-
-static struct xenbus_driver tpmback =3D {
-	.name =3D "vtpm",
-	.owner =3D THIS_MODULE,
-	.ids =3D tpmback_ids,
+static DEFINE_XENBUS_DRIVER(tpmback, "vtpm",
 	.probe =3D tpmback_probe,
 	.remove =3D tpmback_remove,
 	.otherend_changed =3D frontend_changed,
-};
+);
=20
=20
 void tpmif_xenbus_init(void)
 {
-	xenbus_register_backend(&tpmback);
+	xenbus_register_backend(&tpmback_driver);
 }
=20
 void tpmif_xenbus_exit(void)
 {
-	xenbus_unregister_driver(&tpmback);
+	xenbus_unregister_driver(&tpmback_driver);
 }
--- a/drivers/xen/usbback/xenbus.c
+++ b/drivers/xen/usbback/xenbus.c
@@ -317,14 +317,11 @@ static const struct xenbus_device_id usb
 	{ "" },
 };
=20
-static struct xenbus_driver usbback_driver =3D {
-	.name =3D "vusb",
-	.owner =3D THIS_MODULE,
-	.ids =3D usbback_ids,
+static DEFINE_XENBUS_DRIVER(usbback, "vusb",
 	.probe =3D usbback_probe,
 	.otherend_changed =3D frontend_changed,
 	.remove =3D usbback_remove,
-};
+);
=20
 int __init usbback_xenbus_init(void)
 {
--- a/drivers/xen/usbfront/xenbus.c
+++ b/drivers/xen/usbfront/xenbus.c
@@ -379,14 +379,11 @@ static const struct xenbus_device_id usb
 };
 MODULE_ALIAS("xen:vusb");
=20
-static struct xenbus_driver usbfront_driver =3D {
-	.name =3D "vusb",
-	.owner =3D THIS_MODULE,
-	.ids =3D usbfront_ids,
+static DEFINE_XENBUS_DRIVER(usbfront, "vusb",
 	.probe =3D usbfront_probe,
 	.otherend_changed =3D backend_changed,
 	.remove =3D usbfront_remove,
-};
+);
=20
 static int __init usbfront_init(void)
 {
--- a/drivers/xen/xenbus/xenbus_probe.c
+++ b/drivers/xen/xenbus/xenbus_probe.c
@@ -382,11 +382,7 @@ int xenbus_register_driver_common(struct
 	if (bus->error)
 		return bus->error;
=20
-	drv->driver.name =3D drv->name;
 	drv->driver.bus =3D &bus->bus;
-#if LINUX_VERSION_CODE >=3D KERNEL_VERSION(2,6,10)
-	drv->driver.owner =3D drv->owner;
-#endif
 #if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,16)
 	drv->driver.probe =3D xenbus_dev_probe;
 	drv->driver.remove =3D xenbus_dev_remove;
--- a/include/xen/xenbus.h
+++ b/include/xen/xenbus.h
@@ -40,6 +40,7 @@
 #include <linux/completion.h>
 #include <linux/init.h>
 #include <linux/err.h>
+#include <linux/version.h>
 #include <xen/interface/xen.h>
 #include <xen/interface/grant_table.h>
 #include <xen/interface/io/xenbus.h>
@@ -93,8 +94,6 @@ struct xenbus_device_id
=20
 /* A xenbus driver. */
 struct xenbus_driver {
-	char *name;
-	struct module *owner;
 	const struct xenbus_device_id *ids;
 	int (*probe)(struct xenbus_device *dev,
 		     const struct xenbus_device_id *id);
@@ -110,6 +109,19 @@ struct xenbus_driver {
 	int (*is_ready)(struct xenbus_device *dev);
 };
=20
+#if LINUX_VERSION_CODE >=3D KERNEL_VERSION(2,6,10)
+# define XENBUS_DRIVER_SET_OWNER(mod) .driver.owner =3D mod,
+#else
+# define XENBUS_DRIVER_SET_OWNER(mod)
+#endif
+
+#define DEFINE_XENBUS_DRIVER(var, drvname, methods...)	\
+struct xenbus_driver var ## _driver =3D {			\
+	.driver.name =3D drvname,				\
+	XENBUS_DRIVER_SET_OWNER(THIS_MODULE)		\
+	.ids =3D var ## _ids, ## methods			\
+}
+
 static inline struct xenbus_driver *to_xenbus_driver(struct device_driver =
*drv)
 {
 	return container_of(drv, struct xenbus_driver, driver);



--=__Part220D8BF9.0__=
Content-Type: text/plain; name="xen-xenbus-driver-cleanup.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="xen-xenbus-driver-cleanup.patch"

consolidate and simplify struct xenbus_driver instantiation=0A=0AThe =
'name' and 'owner' members are redundant with the identically named=0Afield=
s in the 'driver' sub-structure. Rather than switching each=0Ainstance to =
specify these fields explicitly, introduce a macro to=0Asimplify this (and =
at once to abstract out - for the unmodified drivers=0Abuild - the absence =
of the 'owner' field in Linux prior to 2.6.10).=0A=0AAlso add a module =
alias for the vtpm frontend driver (overlooked in=0A141:5e294e29a43e).=0A=
=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=0A=0A--- a/drivers/char/t=
pm/tpm_xen.c=0A+++ b/drivers/char/tpm/tpm_xen.c=0A@@ -475,26 +475,24 @@ =
static int tpmif_connect(struct xenbus_d=0A 	return 0;=0A }=0A =
=0A-static struct xenbus_device_id tpmfront_ids[] =3D {=0A+static const =
struct xenbus_device_id tpmfront_ids[] =3D {=0A 	{ "vtpm" },=0A 	{ =
"" }=0A };=0A+MODULE_ALIAS("xen:vtpm");=0A =0A-static struct xenbus_driver =
tpmfront =3D {=0A-	.name =3D "vtpm",=0A-	.owner =3D THIS_MODULE,=0A-=
	.ids =3D tpmfront_ids,=0A+static DEFINE_XENBUS_DRIVER(tpmfront, =
"vtpm",=0A 	.probe =3D tpmfront_probe,=0A 	.remove =3D  tpmfront_remov=
e,=0A 	.resume =3D tpmfront_resume,=0A 	.otherend_changed =3D =
backend_changed,=0A 	.suspend =3D tpmfront_suspend,=0A 	.suspend_ca=
ncel =3D tpmfront_suspend_cancel,=0A-};=0A+);=0A =0A static void __init =
init_tpm_xenbus(void)=0A {=0A-	xenbus_register_frontend(&tpmfront);=0A+	=
xenbus_register_frontend(&tpmfront_driver);=0A }=0A =0A static int =
tpmif_allocate_tx_buffers(struct tpm_private *tp)=0A--- a/drivers/xen/blkba=
ck/xenbus.c=0A+++ b/drivers/xen/blkback/xenbus.c=0A@@ -542,18 +542,14 @@ =
static const struct xenbus_device_id blk=0A 	{ "" }=0A };=0A =0A-=0A-sta=
tic struct xenbus_driver blkback =3D {=0A-	.name =3D "vbd",=0A-	=
.owner =3D THIS_MODULE,=0A-	.ids =3D blkback_ids,=0A+static DEFINE_XENB=
US_DRIVER(blkback, "vbd",=0A 	.probe =3D blkback_probe,=0A 	.remove =
=3D blkback_remove,=0A 	.otherend_changed =3D frontend_changed=0A-};=0A+);=
=0A =0A =0A void blkif_xenbus_init(void)=0A {=0A-	xenbus_register_bac=
kend(&blkback);=0A+	xenbus_register_backend(&blkback_driver);=0A =
}=0A--- a/drivers/xen/blkfront/blkfront.c=0A+++ b/drivers/xen/blkfront/blkf=
ront.c=0A@@ -934,16 +934,13 @@ static const struct xenbus_device_id blk=0A =
};=0A MODULE_ALIAS("xen:vbd");=0A =0A-static struct xenbus_driver blkfront =
=3D {=0A-	.name =3D "vbd",=0A-	.owner =3D THIS_MODULE,=0A-	=
.ids =3D blkfront_ids,=0A+static DEFINE_XENBUS_DRIVER(blkfront, "vbd",=0A 	=
.probe =3D blkfront_probe,=0A 	.remove =3D blkfront_remove,=0A 	=
.resume =3D blkfront_resume,=0A 	.otherend_changed =3D backend_chang=
ed,=0A 	.is_ready =3D blkfront_is_ready,=0A-};=0A+);=0A =0A =0A static int =
__init xlblk_init(void)=0A@@ -951,14 +948,14 @@ static int __init =
xlblk_init(void)=0A 	if (!is_running_on_xen())=0A 		return =
-ENODEV;=0A =0A-	return xenbus_register_frontend(&blkfront);=0A+	=
return xenbus_register_frontend(&blkfront_driver);=0A }=0A module_init(xlbl=
k_init);=0A =0A =0A static void __exit xlblk_exit(void)=0A {=0A-	=
return xenbus_unregister_driver(&blkfront);=0A+	return xenbus_unregister_dr=
iver(&blkfront_driver);=0A }=0A module_exit(xlblk_exit);=0A =0A--- =
a/drivers/xen/blktap/xenbus.c=0A+++ b/drivers/xen/blktap/xenbus.c=0A@@ =
-490,18 +490,14 @@ static const struct xenbus_device_id blk=0A 	{ "" }=0A =
};=0A =0A-=0A-static struct xenbus_driver blktap =3D {=0A-	.name =3D =
"tap",=0A-	.owner =3D THIS_MODULE,=0A-	.ids =3D blktap_ids,=0A+sta=
tic DEFINE_XENBUS_DRIVER(blktap, "tap",=0A 	.probe =3D blktap_probe,=0A=
 	.remove =3D blktap_remove,=0A 	.otherend_changed =3D tap_frontend_=
changed=0A-};=0A+);=0A =0A =0A void tap_blkif_xenbus_init(void)=0A {=0A-	=
xenbus_register_backend(&blktap);=0A+	xenbus_register_backend(&blktap_dri=
ver);=0A }=0A--- a/drivers/xen/fbfront/xenfb.c=0A+++ b/drivers/xen/fbfront/=
xenfb.c=0A@@ -857,15 +857,12 @@ static const struct xenbus_device_id =
xen=0A };=0A MODULE_ALIAS("xen:vfb");=0A =0A-static struct xenbus_driver =
xenfb_driver =3D {=0A-	.name =3D "vfb",=0A-	.owner =3D THIS_MODULE,=0A-=
	.ids =3D xenfb_ids,=0A+static DEFINE_XENBUS_DRIVER(xenfb, =
"vfb",=0A 	.probe =3D xenfb_probe,=0A 	.remove =3D xenfb_remove,=
=0A 	.resume =3D xenfb_resume,=0A 	.otherend_changed =3D xenfb_backend=
_changed,=0A-};=0A+);=0A =0A static int __init xenfb_init(void)=0A {=0A--- =
a/drivers/xen/fbfront/xenkbd.c=0A+++ b/drivers/xen/fbfront/xenkbd.c=0A@@ =
-335,15 +335,12 @@ static const struct xenbus_device_id xen=0A };=0A =
MODULE_ALIAS("xen:vkbd");=0A =0A-static struct xenbus_driver xenkbd_driver =
=3D {=0A-	.name =3D "vkbd",=0A-	.owner =3D THIS_MODULE,=0A-	=
.ids =3D xenkbd_ids,=0A+static DEFINE_XENBUS_DRIVER(xenkbd, "vkbd",=0A 	=
.probe =3D xenkbd_probe,=0A 	.remove =3D xenkbd_remove,=0A 	.resume =
=3D xenkbd_resume,=0A 	.otherend_changed =3D xenkbd_backend_changed,=0A-};=
=0A+);=0A =0A static int __init xenkbd_init(void)=0A {=0A--- a/drivers/xen/=
netback/xenbus.c=0A+++ b/drivers/xen/netback/xenbus.c=0A@@ -437,19 +437,15 =
@@ static const struct xenbus_device_id net=0A 	{ "" }=0A };=0A =0A-=0A-sta=
tic struct xenbus_driver netback =3D {=0A-	.name =3D "vif",=0A-	=
.owner =3D THIS_MODULE,=0A-	.ids =3D netback_ids,=0A+static DEFINE_XENB=
US_DRIVER(netback, "vif",=0A 	.probe =3D netback_probe,=0A 	.remove =
=3D netback_remove,=0A 	.uevent =3D netback_uevent,=0A 	.otherend_changed =
=3D frontend_changed,=0A-};=0A+);=0A =0A =0A void netif_xenbus_init(void)=
=0A {=0A-	xenbus_register_backend(&netback);=0A+	xenbus_register_bac=
kend(&netback_driver);=0A }=0A--- a/drivers/xen/netfront/netfront.c=0A+++ =
b/drivers/xen/netfront/netfront.c=0A@@ -2197,18 +2197,14 @@ static const =
struct xenbus_device_id net=0A };=0A MODULE_ALIAS("xen:vif");=0A =0A-=0A-st=
atic struct xenbus_driver netfront_driver =3D {=0A-	.name =3D =
"vif",=0A-	.owner =3D THIS_MODULE,=0A-	.ids =3D netfront_ids,=0A+s=
tatic DEFINE_XENBUS_DRIVER(netfront, "vif",=0A 	.probe =3D netfront_probe,=
=0A 	.remove =3D __devexit_p(netfront_remove),=0A 	.suspend =3D =
netfront_suspend,=0A 	.suspend_cancel =3D netfront_suspend_cancel,=0A 	=
.resume =3D netfront_resume,=0A 	.otherend_changed =3D backend_chang=
ed,=0A-};=0A+);=0A =0A =0A static int __init netif_init(void)=0A--- =
a/drivers/xen/pciback/xenbus.c=0A+++ b/drivers/xen/pciback/xenbus.c=0A@@ =
-676,19 +676,16 @@ static int pciback_xenbus_remove(struct =0A 	return =
0;=0A }=0A =0A-static const struct xenbus_device_id xenpci_ids[] =3D =
{=0A+static const struct xenbus_device_id pciback_ids[] =3D {=0A 	=
{"pci"},=0A 	{{0}},=0A };=0A =0A-static struct xenbus_driver xenbus_pcib=
ack_driver =3D {=0A-	.name 			=3D "pciback",=0A-	=
.owner 			=3D THIS_MODULE,=0A-	.ids 			=
=3D xenpci_ids,=0A+static DEFINE_XENBUS_DRIVER(pciback, "pciback",=0A 	=
.probe 			=3D pciback_xenbus_probe,=0A 	.remove 		=
=3D pciback_xenbus_remove,=0A 	.otherend_changed 	=3D pciback_fronten=
d_changed,=0A-};=0A+);=0A =0A int __init pciback_xenbus_register(void)=0A =
{=0A@@ -700,11 +697,11 @@ int __init pciback_xenbus_register(void)=0A 		=
	"pciback_workqueue failed\n");=0A 		return -EFAULT;=0A =
	}=0A-	return xenbus_register_backend(&xenbus_pciback_driver);=0A+=
	return xenbus_register_backend(&pciback_driver);=0A }=0A =0A void =
__exit pciback_xenbus_unregister(void)=0A {=0A 	destroy_workqueue(pciback_w=
q);=0A-	xenbus_unregister_driver(&xenbus_pciback_driver);=0A+	xenbus_unre=
gister_driver(&pciback_driver);=0A }=0A--- a/drivers/xen/pcifront/xenbus.c=
=0A+++ b/drivers/xen/pcifront/xenbus.c=0A@@ -456,27 +456,24 @@ static int =
pcifront_xenbus_remove(struct=0A 	return 0;=0A }=0A =0A-static const =
struct xenbus_device_id xenpci_ids[] =3D {=0A+static const struct =
xenbus_device_id pcifront_ids[] =3D {=0A 	{"pci"},=0A 	{{0}},=0A =
};=0A MODULE_ALIAS("xen:pci");=0A =0A-static struct xenbus_driver =
xenbus_pcifront_driver =3D {=0A-	.name 			=3D =
"pcifront",=0A-	.owner 			=3D THIS_MODULE,=0A-	.ids 		=
	=3D xenpci_ids,=0A+static DEFINE_XENBUS_DRIVER(pcifront, "pcifront"=
,=0A 	.probe 			=3D pcifront_xenbus_probe,=0A 	.remove 	=
	=3D pcifront_xenbus_remove,=0A 	.otherend_changed 	=3D =
pcifront_backend_changed,=0A-};=0A+);=0A =0A static int __init pcifront_ini=
t(void)=0A {=0A 	if (!is_running_on_xen())=0A 		return =
-ENODEV;=0A =0A-	return xenbus_register_frontend(&xenbus_pcifront_dr=
iver);=0A+	return xenbus_register_frontend(&pcifront_driver);=0A }=0A =
=0A /* Initialize after the Xen PCI Frontend Stub is initialized */=0A--- =
a/drivers/xen/scsiback/xenbus.c=0A+++ b/drivers/xen/scsiback/xenbus.c=0A@@ =
-352,26 +352,23 @@ fail:=0A }=0A =0A =0A-static struct xenbus_device_id =
scsiback_ids[] =3D {=0A+static const struct xenbus_device_id scsiback_ids[]=
 =3D {=0A 	{ "vscsi" },=0A 	{ "" }=0A };=0A =0A-static struct =
xenbus_driver scsiback =3D {=0A-	.name			=3D =
"vscsi",=0A-	.owner			=3D THIS_MODULE,=0A-	.ids		=
	=3D scsiback_ids,=0A+static DEFINE_XENBUS_DRIVER(scsiback, =
"vscsi",=0A 	.probe			=3D scsiback_probe,=0A 	.remove		=
	=3D scsiback_remove,=0A 	.otherend_changed	=3D =
scsiback_frontend_changed=0A-};=0A+);=0A =0A int scsiback_xenbus_init(void)=
=0A {=0A-	return xenbus_register_backend(&scsiback);=0A+	return =
xenbus_register_backend(&scsiback_driver);=0A }=0A =0A void scsiback_xenbus=
_unregister(void)=0A {=0A-	xenbus_unregister_driver(&scsiback);=0A+	=
xenbus_unregister_driver(&scsiback_driver);=0A }=0A--- a/drivers/xen/scsifr=
ont/xenbus.c=0A+++ b/drivers/xen/scsifront/xenbus.c=0A@@ -398,21 +398,18 =
@@ static void scsifront_backend_changed(st=0A }=0A =0A =0A-static struct =
xenbus_device_id scsifront_ids[] =3D {=0A+static const struct xenbus_device=
_id scsifront_ids[] =3D {=0A 	{ "vscsi" },=0A 	{ "" }=0A };=0A =
MODULE_ALIAS("xen:vscsi");=0A =0A-static struct xenbus_driver scsifront_dri=
ver =3D {=0A-	.name			=3D "vscsi",=0A-	.owner		=
	=3D THIS_MODULE,=0A-	.ids			=3D scsifront_ids,=
=0A+static DEFINE_XENBUS_DRIVER(scsifront, "vscsi",=0A 	.probe			=
=3D scsifront_probe,=0A 	.remove			=3D scsifront_remov=
e,=0A /* 	.resume			=3D scsifront_resume, */=0A 	=
.otherend_changed	=3D scsifront_backend_changed,=0A-};=0A+);=0A =0A =
int scsifront_xenbus_init(void)=0A {=0A--- a/drivers/xen/tpmback/xenbus.c=
=0A+++ b/drivers/xen/tpmback/xenbus.c=0A@@ -251,23 +251,19 @@ static const =
struct xenbus_device_id tpm=0A 	{ "" }=0A };=0A =0A-=0A-static struct =
xenbus_driver tpmback =3D {=0A-	.name =3D "vtpm",=0A-	.owner =3D =
THIS_MODULE,=0A-	.ids =3D tpmback_ids,=0A+static DEFINE_XENBUS_DRIVE=
R(tpmback, "vtpm",=0A 	.probe =3D tpmback_probe,=0A 	.remove =3D =
tpmback_remove,=0A 	.otherend_changed =3D frontend_changed,=0A-};=0A+);=
=0A =0A =0A void tpmif_xenbus_init(void)=0A {=0A-	xenbus_register_bac=
kend(&tpmback);=0A+	xenbus_register_backend(&tpmback_driver);=0A }=0A =
=0A void tpmif_xenbus_exit(void)=0A {=0A-	xenbus_unregister_driver(&t=
pmback);=0A+	xenbus_unregister_driver(&tpmback_driver);=0A }=0A--- =
a/drivers/xen/usbback/xenbus.c=0A+++ b/drivers/xen/usbback/xenbus.c=0A@@ =
-317,14 +317,11 @@ static const struct xenbus_device_id usb=0A 	{ "" },=0A =
};=0A =0A-static struct xenbus_driver usbback_driver =3D {=0A-	.name =3D =
"vusb",=0A-	.owner =3D THIS_MODULE,=0A-	.ids =3D usbback_ids,=0A+st=
atic DEFINE_XENBUS_DRIVER(usbback, "vusb",=0A 	.probe =3D usbback_probe,=
=0A 	.otherend_changed =3D frontend_changed,=0A 	.remove =3D =
usbback_remove,=0A-};=0A+);=0A =0A int __init usbback_xenbus_init(void)=0A =
{=0A--- a/drivers/xen/usbfront/xenbus.c=0A+++ b/drivers/xen/usbfront/xenbus=
.c=0A@@ -379,14 +379,11 @@ static const struct xenbus_device_id usb=0A =
};=0A MODULE_ALIAS("xen:vusb");=0A =0A-static struct xenbus_driver =
usbfront_driver =3D {=0A-	.name =3D "vusb",=0A-	.owner =3D =
THIS_MODULE,=0A-	.ids =3D usbfront_ids,=0A+static DEFINE_XENBUS_DRIV=
ER(usbfront, "vusb",=0A 	.probe =3D usbfront_probe,=0A 	.otherend_c=
hanged =3D backend_changed,=0A 	.remove =3D usbfront_remove,=0A-};=0A+);=0A=
 =0A static int __init usbfront_init(void)=0A {=0A--- a/drivers/xen/xenbus/=
xenbus_probe.c=0A+++ b/drivers/xen/xenbus/xenbus_probe.c=0A@@ -382,11 =
+382,7 @@ int xenbus_register_driver_common(struct=0A 	if (bus->error)=0A =
		return bus->error;=0A =0A-	drv->driver.name =3D =
drv->name;=0A 	drv->driver.bus =3D &bus->bus;=0A-#if LINUX_VERSION_CODE =
>=3D KERNEL_VERSION(2,6,10)=0A-	drv->driver.owner =3D drv->owner;=0A-#endif=
=0A #if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,16)=0A 	drv->driver.probe =
=3D xenbus_dev_probe;=0A 	drv->driver.remove =3D xenbus_dev_remove;=
=0A--- a/include/xen/xenbus.h=0A+++ b/include/xen/xenbus.h=0A@@ -40,6 =
+40,7 @@=0A #include <linux/completion.h>=0A #include <linux/init.h>=0A =
#include <linux/err.h>=0A+#include <linux/version.h>=0A #include <xen/inter=
face/xen.h>=0A #include <xen/interface/grant_table.h>=0A #include =
<xen/interface/io/xenbus.h>=0A@@ -93,8 +94,6 @@ struct xenbus_device_id=0A =
=0A /* A xenbus driver. */=0A struct xenbus_driver {=0A-	char =
*name;=0A-	struct module *owner;=0A 	const struct xenbus_device_=
id *ids;=0A 	int (*probe)(struct xenbus_device *dev,=0A 		   =
  const struct xenbus_device_id *id);=0A@@ -110,6 +109,19 @@ struct =
xenbus_driver {=0A 	int (*is_ready)(struct xenbus_device *dev);=0A =
};=0A =0A+#if LINUX_VERSION_CODE >=3D KERNEL_VERSION(2,6,10)=0A+# define =
XENBUS_DRIVER_SET_OWNER(mod) .driver.owner =3D mod,=0A+#else=0A+# define =
XENBUS_DRIVER_SET_OWNER(mod)=0A+#endif=0A+=0A+#define DEFINE_XENBUS_DRIVER(=
var, drvname, methods...)	\=0A+struct xenbus_driver var ## _driver =
=3D {			\=0A+	.driver.name =3D drvname,			=
	\=0A+	XENBUS_DRIVER_SET_OWNER(THIS_MODULE)		\=0A+	=
.ids =3D var ## _ids, ## methods			\=0A+}=0A+=0A =
static inline struct xenbus_driver *to_xenbus_driver(struct device_driver =
*drv)=0A {=0A 	return container_of(drv, struct xenbus_driver, driver);=0A
--=__Part220D8BF9.0__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--=__Part220D8BF9.0__=--


From xen-devel-bounces@lists.xensource.com Thu Dec 15 15:53:44 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 15:53:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbDce-0007Xy-DF; Thu, 15 Dec 2011 15:53:28 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RbDcc-0007Xg-Lb
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 15:53:27 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1323964396!7614857!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2050 invoked from network); 15 Dec 2011 15:53:19 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-7.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 15 Dec 2011 15:53:19 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 15 Dec 2011 15:53:15 +0000
Message-Id: <4EEA25F902000078000683AA@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 15 Dec 2011 15:53:13 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part220D8BF9.0__="
Subject: [Xen-devel] [PATCH] linux-2.6.18: consolidate and simplify struct
 xenbus_driver instantiation
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__Part220D8BF9.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

The 'name' and 'owner' members are redundant with the identically named
fields in the 'driver' sub-structure. Rather than switching each
instance to specify these fields explicitly, introduce a macro to
simplify this (and at once to abstract out - for the unmodified drivers
build - the absence of the 'owner' field in Linux prior to 2.6.10).

Also add a module alias for the vtpm frontend driver (overlooked in
141:5e294e29a43e).

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/drivers/char/tpm/tpm_xen.c
+++ b/drivers/char/tpm/tpm_xen.c
@@ -475,26 +475,24 @@ static int tpmif_connect(struct xenbus_d
 	return 0;
 }
=20
-static struct xenbus_device_id tpmfront_ids[] =3D {
+static const struct xenbus_device_id tpmfront_ids[] =3D {
 	{ "vtpm" },
 	{ "" }
 };
+MODULE_ALIAS("xen:vtpm");
=20
-static struct xenbus_driver tpmfront =3D {
-	.name =3D "vtpm",
-	.owner =3D THIS_MODULE,
-	.ids =3D tpmfront_ids,
+static DEFINE_XENBUS_DRIVER(tpmfront, "vtpm",
 	.probe =3D tpmfront_probe,
 	.remove =3D  tpmfront_remove,
 	.resume =3D tpmfront_resume,
 	.otherend_changed =3D backend_changed,
 	.suspend =3D tpmfront_suspend,
 	.suspend_cancel =3D tpmfront_suspend_cancel,
-};
+);
=20
 static void __init init_tpm_xenbus(void)
 {
-	xenbus_register_frontend(&tpmfront);
+	xenbus_register_frontend(&tpmfront_driver);
 }
=20
 static int tpmif_allocate_tx_buffers(struct tpm_private *tp)
--- a/drivers/xen/blkback/xenbus.c
+++ b/drivers/xen/blkback/xenbus.c
@@ -542,18 +542,14 @@ static const struct xenbus_device_id blk
 	{ "" }
 };
=20
-
-static struct xenbus_driver blkback =3D {
-	.name =3D "vbd",
-	.owner =3D THIS_MODULE,
-	.ids =3D blkback_ids,
+static DEFINE_XENBUS_DRIVER(blkback, "vbd",
 	.probe =3D blkback_probe,
 	.remove =3D blkback_remove,
 	.otherend_changed =3D frontend_changed
-};
+);
=20
=20
 void blkif_xenbus_init(void)
 {
-	xenbus_register_backend(&blkback);
+	xenbus_register_backend(&blkback_driver);
 }
--- a/drivers/xen/blkfront/blkfront.c
+++ b/drivers/xen/blkfront/blkfront.c
@@ -934,16 +934,13 @@ static const struct xenbus_device_id blk
 };
 MODULE_ALIAS("xen:vbd");
=20
-static struct xenbus_driver blkfront =3D {
-	.name =3D "vbd",
-	.owner =3D THIS_MODULE,
-	.ids =3D blkfront_ids,
+static DEFINE_XENBUS_DRIVER(blkfront, "vbd",
 	.probe =3D blkfront_probe,
 	.remove =3D blkfront_remove,
 	.resume =3D blkfront_resume,
 	.otherend_changed =3D backend_changed,
 	.is_ready =3D blkfront_is_ready,
-};
+);
=20
=20
 static int __init xlblk_init(void)
@@ -951,14 +948,14 @@ static int __init xlblk_init(void)
 	if (!is_running_on_xen())
 		return -ENODEV;
=20
-	return xenbus_register_frontend(&blkfront);
+	return xenbus_register_frontend(&blkfront_driver);
 }
 module_init(xlblk_init);
=20
=20
 static void __exit xlblk_exit(void)
 {
-	return xenbus_unregister_driver(&blkfront);
+	return xenbus_unregister_driver(&blkfront_driver);
 }
 module_exit(xlblk_exit);
=20
--- a/drivers/xen/blktap/xenbus.c
+++ b/drivers/xen/blktap/xenbus.c
@@ -490,18 +490,14 @@ static const struct xenbus_device_id blk
 	{ "" }
 };
=20
-
-static struct xenbus_driver blktap =3D {
-	.name =3D "tap",
-	.owner =3D THIS_MODULE,
-	.ids =3D blktap_ids,
+static DEFINE_XENBUS_DRIVER(blktap, "tap",
 	.probe =3D blktap_probe,
 	.remove =3D blktap_remove,
 	.otherend_changed =3D tap_frontend_changed
-};
+);
=20
=20
 void tap_blkif_xenbus_init(void)
 {
-	xenbus_register_backend(&blktap);
+	xenbus_register_backend(&blktap_driver);
 }
--- a/drivers/xen/fbfront/xenfb.c
+++ b/drivers/xen/fbfront/xenfb.c
@@ -857,15 +857,12 @@ static const struct xenbus_device_id xen
 };
 MODULE_ALIAS("xen:vfb");
=20
-static struct xenbus_driver xenfb_driver =3D {
-	.name =3D "vfb",
-	.owner =3D THIS_MODULE,
-	.ids =3D xenfb_ids,
+static DEFINE_XENBUS_DRIVER(xenfb, "vfb",
 	.probe =3D xenfb_probe,
 	.remove =3D xenfb_remove,
 	.resume =3D xenfb_resume,
 	.otherend_changed =3D xenfb_backend_changed,
-};
+);
=20
 static int __init xenfb_init(void)
 {
--- a/drivers/xen/fbfront/xenkbd.c
+++ b/drivers/xen/fbfront/xenkbd.c
@@ -335,15 +335,12 @@ static const struct xenbus_device_id xen
 };
 MODULE_ALIAS("xen:vkbd");
=20
-static struct xenbus_driver xenkbd_driver =3D {
-	.name =3D "vkbd",
-	.owner =3D THIS_MODULE,
-	.ids =3D xenkbd_ids,
+static DEFINE_XENBUS_DRIVER(xenkbd, "vkbd",
 	.probe =3D xenkbd_probe,
 	.remove =3D xenkbd_remove,
 	.resume =3D xenkbd_resume,
 	.otherend_changed =3D xenkbd_backend_changed,
-};
+);
=20
 static int __init xenkbd_init(void)
 {
--- a/drivers/xen/netback/xenbus.c
+++ b/drivers/xen/netback/xenbus.c
@@ -437,19 +437,15 @@ static const struct xenbus_device_id net
 	{ "" }
 };
=20
-
-static struct xenbus_driver netback =3D {
-	.name =3D "vif",
-	.owner =3D THIS_MODULE,
-	.ids =3D netback_ids,
+static DEFINE_XENBUS_DRIVER(netback, "vif",
 	.probe =3D netback_probe,
 	.remove =3D netback_remove,
 	.uevent =3D netback_uevent,
 	.otherend_changed =3D frontend_changed,
-};
+);
=20
=20
 void netif_xenbus_init(void)
 {
-	xenbus_register_backend(&netback);
+	xenbus_register_backend(&netback_driver);
 }
--- a/drivers/xen/netfront/netfront.c
+++ b/drivers/xen/netfront/netfront.c
@@ -2197,18 +2197,14 @@ static const struct xenbus_device_id net
 };
 MODULE_ALIAS("xen:vif");
=20
-
-static struct xenbus_driver netfront_driver =3D {
-	.name =3D "vif",
-	.owner =3D THIS_MODULE,
-	.ids =3D netfront_ids,
+static DEFINE_XENBUS_DRIVER(netfront, "vif",
 	.probe =3D netfront_probe,
 	.remove =3D __devexit_p(netfront_remove),
 	.suspend =3D netfront_suspend,
 	.suspend_cancel =3D netfront_suspend_cancel,
 	.resume =3D netfront_resume,
 	.otherend_changed =3D backend_changed,
-};
+);
=20
=20
 static int __init netif_init(void)
--- a/drivers/xen/pciback/xenbus.c
+++ b/drivers/xen/pciback/xenbus.c
@@ -676,19 +676,16 @@ static int pciback_xenbus_remove(struct=20
 	return 0;
 }
=20
-static const struct xenbus_device_id xenpci_ids[] =3D {
+static const struct xenbus_device_id pciback_ids[] =3D {
 	{"pci"},
 	{{0}},
 };
=20
-static struct xenbus_driver xenbus_pciback_driver =3D {
-	.name 			=3D "pciback",
-	.owner 			=3D THIS_MODULE,
-	.ids 			=3D xenpci_ids,
+static DEFINE_XENBUS_DRIVER(pciback, "pciback",
 	.probe 			=3D pciback_xenbus_probe,
 	.remove 		=3D pciback_xenbus_remove,
 	.otherend_changed 	=3D pciback_frontend_changed,
-};
+);
=20
 int __init pciback_xenbus_register(void)
 {
@@ -700,11 +697,11 @@ int __init pciback_xenbus_register(void)
 			"pciback_workqueue failed\n");
 		return -EFAULT;
 	}
-	return xenbus_register_backend(&xenbus_pciback_driver);
+	return xenbus_register_backend(&pciback_driver);
 }
=20
 void __exit pciback_xenbus_unregister(void)
 {
 	destroy_workqueue(pciback_wq);
-	xenbus_unregister_driver(&xenbus_pciback_driver);
+	xenbus_unregister_driver(&pciback_driver);
 }
--- a/drivers/xen/pcifront/xenbus.c
+++ b/drivers/xen/pcifront/xenbus.c
@@ -456,27 +456,24 @@ static int pcifront_xenbus_remove(struct
 	return 0;
 }
=20
-static const struct xenbus_device_id xenpci_ids[] =3D {
+static const struct xenbus_device_id pcifront_ids[] =3D {
 	{"pci"},
 	{{0}},
 };
 MODULE_ALIAS("xen:pci");
=20
-static struct xenbus_driver xenbus_pcifront_driver =3D {
-	.name 			=3D "pcifront",
-	.owner 			=3D THIS_MODULE,
-	.ids 			=3D xenpci_ids,
+static DEFINE_XENBUS_DRIVER(pcifront, "pcifront",
 	.probe 			=3D pcifront_xenbus_probe,
 	.remove 		=3D pcifront_xenbus_remove,
 	.otherend_changed 	=3D pcifront_backend_changed,
-};
+);
=20
 static int __init pcifront_init(void)
 {
 	if (!is_running_on_xen())
 		return -ENODEV;
=20
-	return xenbus_register_frontend(&xenbus_pcifront_driver);
+	return xenbus_register_frontend(&pcifront_driver);
 }
=20
 /* Initialize after the Xen PCI Frontend Stub is initialized */
--- a/drivers/xen/scsiback/xenbus.c
+++ b/drivers/xen/scsiback/xenbus.c
@@ -352,26 +352,23 @@ fail:
 }
=20
=20
-static struct xenbus_device_id scsiback_ids[] =3D {
+static const struct xenbus_device_id scsiback_ids[] =3D {
 	{ "vscsi" },
 	{ "" }
 };
=20
-static struct xenbus_driver scsiback =3D {
-	.name			=3D "vscsi",
-	.owner			=3D THIS_MODULE,
-	.ids			=3D scsiback_ids,
+static DEFINE_XENBUS_DRIVER(scsiback, "vscsi",
 	.probe			=3D scsiback_probe,
 	.remove			=3D scsiback_remove,
 	.otherend_changed	=3D scsiback_frontend_changed
-};
+);
=20
 int scsiback_xenbus_init(void)
 {
-	return xenbus_register_backend(&scsiback);
+	return xenbus_register_backend(&scsiback_driver);
 }
=20
 void scsiback_xenbus_unregister(void)
 {
-	xenbus_unregister_driver(&scsiback);
+	xenbus_unregister_driver(&scsiback_driver);
 }
--- a/drivers/xen/scsifront/xenbus.c
+++ b/drivers/xen/scsifront/xenbus.c
@@ -398,21 +398,18 @@ static void scsifront_backend_changed(st
 }
=20
=20
-static struct xenbus_device_id scsifront_ids[] =3D {
+static const struct xenbus_device_id scsifront_ids[] =3D {
 	{ "vscsi" },
 	{ "" }
 };
 MODULE_ALIAS("xen:vscsi");
=20
-static struct xenbus_driver scsifront_driver =3D {
-	.name			=3D "vscsi",
-	.owner			=3D THIS_MODULE,
-	.ids			=3D scsifront_ids,
+static DEFINE_XENBUS_DRIVER(scsifront, "vscsi",
 	.probe			=3D scsifront_probe,
 	.remove			=3D scsifront_remove,
 /* 	.resume			=3D scsifront_resume, */
 	.otherend_changed	=3D scsifront_backend_changed,
-};
+);
=20
 int scsifront_xenbus_init(void)
 {
--- a/drivers/xen/tpmback/xenbus.c
+++ b/drivers/xen/tpmback/xenbus.c
@@ -251,23 +251,19 @@ static const struct xenbus_device_id tpm
 	{ "" }
 };
=20
-
-static struct xenbus_driver tpmback =3D {
-	.name =3D "vtpm",
-	.owner =3D THIS_MODULE,
-	.ids =3D tpmback_ids,
+static DEFINE_XENBUS_DRIVER(tpmback, "vtpm",
 	.probe =3D tpmback_probe,
 	.remove =3D tpmback_remove,
 	.otherend_changed =3D frontend_changed,
-};
+);
=20
=20
 void tpmif_xenbus_init(void)
 {
-	xenbus_register_backend(&tpmback);
+	xenbus_register_backend(&tpmback_driver);
 }
=20
 void tpmif_xenbus_exit(void)
 {
-	xenbus_unregister_driver(&tpmback);
+	xenbus_unregister_driver(&tpmback_driver);
 }
--- a/drivers/xen/usbback/xenbus.c
+++ b/drivers/xen/usbback/xenbus.c
@@ -317,14 +317,11 @@ static const struct xenbus_device_id usb
 	{ "" },
 };
=20
-static struct xenbus_driver usbback_driver =3D {
-	.name =3D "vusb",
-	.owner =3D THIS_MODULE,
-	.ids =3D usbback_ids,
+static DEFINE_XENBUS_DRIVER(usbback, "vusb",
 	.probe =3D usbback_probe,
 	.otherend_changed =3D frontend_changed,
 	.remove =3D usbback_remove,
-};
+);
=20
 int __init usbback_xenbus_init(void)
 {
--- a/drivers/xen/usbfront/xenbus.c
+++ b/drivers/xen/usbfront/xenbus.c
@@ -379,14 +379,11 @@ static const struct xenbus_device_id usb
 };
 MODULE_ALIAS("xen:vusb");
=20
-static struct xenbus_driver usbfront_driver =3D {
-	.name =3D "vusb",
-	.owner =3D THIS_MODULE,
-	.ids =3D usbfront_ids,
+static DEFINE_XENBUS_DRIVER(usbfront, "vusb",
 	.probe =3D usbfront_probe,
 	.otherend_changed =3D backend_changed,
 	.remove =3D usbfront_remove,
-};
+);
=20
 static int __init usbfront_init(void)
 {
--- a/drivers/xen/xenbus/xenbus_probe.c
+++ b/drivers/xen/xenbus/xenbus_probe.c
@@ -382,11 +382,7 @@ int xenbus_register_driver_common(struct
 	if (bus->error)
 		return bus->error;
=20
-	drv->driver.name =3D drv->name;
 	drv->driver.bus =3D &bus->bus;
-#if LINUX_VERSION_CODE >=3D KERNEL_VERSION(2,6,10)
-	drv->driver.owner =3D drv->owner;
-#endif
 #if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,16)
 	drv->driver.probe =3D xenbus_dev_probe;
 	drv->driver.remove =3D xenbus_dev_remove;
--- a/include/xen/xenbus.h
+++ b/include/xen/xenbus.h
@@ -40,6 +40,7 @@
 #include <linux/completion.h>
 #include <linux/init.h>
 #include <linux/err.h>
+#include <linux/version.h>
 #include <xen/interface/xen.h>
 #include <xen/interface/grant_table.h>
 #include <xen/interface/io/xenbus.h>
@@ -93,8 +94,6 @@ struct xenbus_device_id
=20
 /* A xenbus driver. */
 struct xenbus_driver {
-	char *name;
-	struct module *owner;
 	const struct xenbus_device_id *ids;
 	int (*probe)(struct xenbus_device *dev,
 		     const struct xenbus_device_id *id);
@@ -110,6 +109,19 @@ struct xenbus_driver {
 	int (*is_ready)(struct xenbus_device *dev);
 };
=20
+#if LINUX_VERSION_CODE >=3D KERNEL_VERSION(2,6,10)
+# define XENBUS_DRIVER_SET_OWNER(mod) .driver.owner =3D mod,
+#else
+# define XENBUS_DRIVER_SET_OWNER(mod)
+#endif
+
+#define DEFINE_XENBUS_DRIVER(var, drvname, methods...)	\
+struct xenbus_driver var ## _driver =3D {			\
+	.driver.name =3D drvname,				\
+	XENBUS_DRIVER_SET_OWNER(THIS_MODULE)		\
+	.ids =3D var ## _ids, ## methods			\
+}
+
 static inline struct xenbus_driver *to_xenbus_driver(struct device_driver =
*drv)
 {
 	return container_of(drv, struct xenbus_driver, driver);



--=__Part220D8BF9.0__=
Content-Type: text/plain; name="xen-xenbus-driver-cleanup.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="xen-xenbus-driver-cleanup.patch"

consolidate and simplify struct xenbus_driver instantiation=0A=0AThe =
'name' and 'owner' members are redundant with the identically named=0Afield=
s in the 'driver' sub-structure. Rather than switching each=0Ainstance to =
specify these fields explicitly, introduce a macro to=0Asimplify this (and =
at once to abstract out - for the unmodified drivers=0Abuild - the absence =
of the 'owner' field in Linux prior to 2.6.10).=0A=0AAlso add a module =
alias for the vtpm frontend driver (overlooked in=0A141:5e294e29a43e).=0A=
=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=0A=0A--- a/drivers/char/t=
pm/tpm_xen.c=0A+++ b/drivers/char/tpm/tpm_xen.c=0A@@ -475,26 +475,24 @@ =
static int tpmif_connect(struct xenbus_d=0A 	return 0;=0A }=0A =
=0A-static struct xenbus_device_id tpmfront_ids[] =3D {=0A+static const =
struct xenbus_device_id tpmfront_ids[] =3D {=0A 	{ "vtpm" },=0A 	{ =
"" }=0A };=0A+MODULE_ALIAS("xen:vtpm");=0A =0A-static struct xenbus_driver =
tpmfront =3D {=0A-	.name =3D "vtpm",=0A-	.owner =3D THIS_MODULE,=0A-=
	.ids =3D tpmfront_ids,=0A+static DEFINE_XENBUS_DRIVER(tpmfront, =
"vtpm",=0A 	.probe =3D tpmfront_probe,=0A 	.remove =3D  tpmfront_remov=
e,=0A 	.resume =3D tpmfront_resume,=0A 	.otherend_changed =3D =
backend_changed,=0A 	.suspend =3D tpmfront_suspend,=0A 	.suspend_ca=
ncel =3D tpmfront_suspend_cancel,=0A-};=0A+);=0A =0A static void __init =
init_tpm_xenbus(void)=0A {=0A-	xenbus_register_frontend(&tpmfront);=0A+	=
xenbus_register_frontend(&tpmfront_driver);=0A }=0A =0A static int =
tpmif_allocate_tx_buffers(struct tpm_private *tp)=0A--- a/drivers/xen/blkba=
ck/xenbus.c=0A+++ b/drivers/xen/blkback/xenbus.c=0A@@ -542,18 +542,14 @@ =
static const struct xenbus_device_id blk=0A 	{ "" }=0A };=0A =0A-=0A-sta=
tic struct xenbus_driver blkback =3D {=0A-	.name =3D "vbd",=0A-	=
.owner =3D THIS_MODULE,=0A-	.ids =3D blkback_ids,=0A+static DEFINE_XENB=
US_DRIVER(blkback, "vbd",=0A 	.probe =3D blkback_probe,=0A 	.remove =
=3D blkback_remove,=0A 	.otherend_changed =3D frontend_changed=0A-};=0A+);=
=0A =0A =0A void blkif_xenbus_init(void)=0A {=0A-	xenbus_register_bac=
kend(&blkback);=0A+	xenbus_register_backend(&blkback_driver);=0A =
}=0A--- a/drivers/xen/blkfront/blkfront.c=0A+++ b/drivers/xen/blkfront/blkf=
ront.c=0A@@ -934,16 +934,13 @@ static const struct xenbus_device_id blk=0A =
};=0A MODULE_ALIAS("xen:vbd");=0A =0A-static struct xenbus_driver blkfront =
=3D {=0A-	.name =3D "vbd",=0A-	.owner =3D THIS_MODULE,=0A-	=
.ids =3D blkfront_ids,=0A+static DEFINE_XENBUS_DRIVER(blkfront, "vbd",=0A 	=
.probe =3D blkfront_probe,=0A 	.remove =3D blkfront_remove,=0A 	=
.resume =3D blkfront_resume,=0A 	.otherend_changed =3D backend_chang=
ed,=0A 	.is_ready =3D blkfront_is_ready,=0A-};=0A+);=0A =0A =0A static int =
__init xlblk_init(void)=0A@@ -951,14 +948,14 @@ static int __init =
xlblk_init(void)=0A 	if (!is_running_on_xen())=0A 		return =
-ENODEV;=0A =0A-	return xenbus_register_frontend(&blkfront);=0A+	=
return xenbus_register_frontend(&blkfront_driver);=0A }=0A module_init(xlbl=
k_init);=0A =0A =0A static void __exit xlblk_exit(void)=0A {=0A-	=
return xenbus_unregister_driver(&blkfront);=0A+	return xenbus_unregister_dr=
iver(&blkfront_driver);=0A }=0A module_exit(xlblk_exit);=0A =0A--- =
a/drivers/xen/blktap/xenbus.c=0A+++ b/drivers/xen/blktap/xenbus.c=0A@@ =
-490,18 +490,14 @@ static const struct xenbus_device_id blk=0A 	{ "" }=0A =
};=0A =0A-=0A-static struct xenbus_driver blktap =3D {=0A-	.name =3D =
"tap",=0A-	.owner =3D THIS_MODULE,=0A-	.ids =3D blktap_ids,=0A+sta=
tic DEFINE_XENBUS_DRIVER(blktap, "tap",=0A 	.probe =3D blktap_probe,=0A=
 	.remove =3D blktap_remove,=0A 	.otherend_changed =3D tap_frontend_=
changed=0A-};=0A+);=0A =0A =0A void tap_blkif_xenbus_init(void)=0A {=0A-	=
xenbus_register_backend(&blktap);=0A+	xenbus_register_backend(&blktap_dri=
ver);=0A }=0A--- a/drivers/xen/fbfront/xenfb.c=0A+++ b/drivers/xen/fbfront/=
xenfb.c=0A@@ -857,15 +857,12 @@ static const struct xenbus_device_id =
xen=0A };=0A MODULE_ALIAS("xen:vfb");=0A =0A-static struct xenbus_driver =
xenfb_driver =3D {=0A-	.name =3D "vfb",=0A-	.owner =3D THIS_MODULE,=0A-=
	.ids =3D xenfb_ids,=0A+static DEFINE_XENBUS_DRIVER(xenfb, =
"vfb",=0A 	.probe =3D xenfb_probe,=0A 	.remove =3D xenfb_remove,=
=0A 	.resume =3D xenfb_resume,=0A 	.otherend_changed =3D xenfb_backend=
_changed,=0A-};=0A+);=0A =0A static int __init xenfb_init(void)=0A {=0A--- =
a/drivers/xen/fbfront/xenkbd.c=0A+++ b/drivers/xen/fbfront/xenkbd.c=0A@@ =
-335,15 +335,12 @@ static const struct xenbus_device_id xen=0A };=0A =
MODULE_ALIAS("xen:vkbd");=0A =0A-static struct xenbus_driver xenkbd_driver =
=3D {=0A-	.name =3D "vkbd",=0A-	.owner =3D THIS_MODULE,=0A-	=
.ids =3D xenkbd_ids,=0A+static DEFINE_XENBUS_DRIVER(xenkbd, "vkbd",=0A 	=
.probe =3D xenkbd_probe,=0A 	.remove =3D xenkbd_remove,=0A 	.resume =
=3D xenkbd_resume,=0A 	.otherend_changed =3D xenkbd_backend_changed,=0A-};=
=0A+);=0A =0A static int __init xenkbd_init(void)=0A {=0A--- a/drivers/xen/=
netback/xenbus.c=0A+++ b/drivers/xen/netback/xenbus.c=0A@@ -437,19 +437,15 =
@@ static const struct xenbus_device_id net=0A 	{ "" }=0A };=0A =0A-=0A-sta=
tic struct xenbus_driver netback =3D {=0A-	.name =3D "vif",=0A-	=
.owner =3D THIS_MODULE,=0A-	.ids =3D netback_ids,=0A+static DEFINE_XENB=
US_DRIVER(netback, "vif",=0A 	.probe =3D netback_probe,=0A 	.remove =
=3D netback_remove,=0A 	.uevent =3D netback_uevent,=0A 	.otherend_changed =
=3D frontend_changed,=0A-};=0A+);=0A =0A =0A void netif_xenbus_init(void)=
=0A {=0A-	xenbus_register_backend(&netback);=0A+	xenbus_register_bac=
kend(&netback_driver);=0A }=0A--- a/drivers/xen/netfront/netfront.c=0A+++ =
b/drivers/xen/netfront/netfront.c=0A@@ -2197,18 +2197,14 @@ static const =
struct xenbus_device_id net=0A };=0A MODULE_ALIAS("xen:vif");=0A =0A-=0A-st=
atic struct xenbus_driver netfront_driver =3D {=0A-	.name =3D =
"vif",=0A-	.owner =3D THIS_MODULE,=0A-	.ids =3D netfront_ids,=0A+s=
tatic DEFINE_XENBUS_DRIVER(netfront, "vif",=0A 	.probe =3D netfront_probe,=
=0A 	.remove =3D __devexit_p(netfront_remove),=0A 	.suspend =3D =
netfront_suspend,=0A 	.suspend_cancel =3D netfront_suspend_cancel,=0A 	=
.resume =3D netfront_resume,=0A 	.otherend_changed =3D backend_chang=
ed,=0A-};=0A+);=0A =0A =0A static int __init netif_init(void)=0A--- =
a/drivers/xen/pciback/xenbus.c=0A+++ b/drivers/xen/pciback/xenbus.c=0A@@ =
-676,19 +676,16 @@ static int pciback_xenbus_remove(struct =0A 	return =
0;=0A }=0A =0A-static const struct xenbus_device_id xenpci_ids[] =3D =
{=0A+static const struct xenbus_device_id pciback_ids[] =3D {=0A 	=
{"pci"},=0A 	{{0}},=0A };=0A =0A-static struct xenbus_driver xenbus_pcib=
ack_driver =3D {=0A-	.name 			=3D "pciback",=0A-	=
.owner 			=3D THIS_MODULE,=0A-	.ids 			=
=3D xenpci_ids,=0A+static DEFINE_XENBUS_DRIVER(pciback, "pciback",=0A 	=
.probe 			=3D pciback_xenbus_probe,=0A 	.remove 		=
=3D pciback_xenbus_remove,=0A 	.otherend_changed 	=3D pciback_fronten=
d_changed,=0A-};=0A+);=0A =0A int __init pciback_xenbus_register(void)=0A =
{=0A@@ -700,11 +697,11 @@ int __init pciback_xenbus_register(void)=0A 		=
	"pciback_workqueue failed\n");=0A 		return -EFAULT;=0A =
	}=0A-	return xenbus_register_backend(&xenbus_pciback_driver);=0A+=
	return xenbus_register_backend(&pciback_driver);=0A }=0A =0A void =
__exit pciback_xenbus_unregister(void)=0A {=0A 	destroy_workqueue(pciback_w=
q);=0A-	xenbus_unregister_driver(&xenbus_pciback_driver);=0A+	xenbus_unre=
gister_driver(&pciback_driver);=0A }=0A--- a/drivers/xen/pcifront/xenbus.c=
=0A+++ b/drivers/xen/pcifront/xenbus.c=0A@@ -456,27 +456,24 @@ static int =
pcifront_xenbus_remove(struct=0A 	return 0;=0A }=0A =0A-static const =
struct xenbus_device_id xenpci_ids[] =3D {=0A+static const struct =
xenbus_device_id pcifront_ids[] =3D {=0A 	{"pci"},=0A 	{{0}},=0A =
};=0A MODULE_ALIAS("xen:pci");=0A =0A-static struct xenbus_driver =
xenbus_pcifront_driver =3D {=0A-	.name 			=3D =
"pcifront",=0A-	.owner 			=3D THIS_MODULE,=0A-	.ids 		=
	=3D xenpci_ids,=0A+static DEFINE_XENBUS_DRIVER(pcifront, "pcifront"=
,=0A 	.probe 			=3D pcifront_xenbus_probe,=0A 	.remove 	=
	=3D pcifront_xenbus_remove,=0A 	.otherend_changed 	=3D =
pcifront_backend_changed,=0A-};=0A+);=0A =0A static int __init pcifront_ini=
t(void)=0A {=0A 	if (!is_running_on_xen())=0A 		return =
-ENODEV;=0A =0A-	return xenbus_register_frontend(&xenbus_pcifront_dr=
iver);=0A+	return xenbus_register_frontend(&pcifront_driver);=0A }=0A =
=0A /* Initialize after the Xen PCI Frontend Stub is initialized */=0A--- =
a/drivers/xen/scsiback/xenbus.c=0A+++ b/drivers/xen/scsiback/xenbus.c=0A@@ =
-352,26 +352,23 @@ fail:=0A }=0A =0A =0A-static struct xenbus_device_id =
scsiback_ids[] =3D {=0A+static const struct xenbus_device_id scsiback_ids[]=
 =3D {=0A 	{ "vscsi" },=0A 	{ "" }=0A };=0A =0A-static struct =
xenbus_driver scsiback =3D {=0A-	.name			=3D =
"vscsi",=0A-	.owner			=3D THIS_MODULE,=0A-	.ids		=
	=3D scsiback_ids,=0A+static DEFINE_XENBUS_DRIVER(scsiback, =
"vscsi",=0A 	.probe			=3D scsiback_probe,=0A 	.remove		=
	=3D scsiback_remove,=0A 	.otherend_changed	=3D =
scsiback_frontend_changed=0A-};=0A+);=0A =0A int scsiback_xenbus_init(void)=
=0A {=0A-	return xenbus_register_backend(&scsiback);=0A+	return =
xenbus_register_backend(&scsiback_driver);=0A }=0A =0A void scsiback_xenbus=
_unregister(void)=0A {=0A-	xenbus_unregister_driver(&scsiback);=0A+	=
xenbus_unregister_driver(&scsiback_driver);=0A }=0A--- a/drivers/xen/scsifr=
ont/xenbus.c=0A+++ b/drivers/xen/scsifront/xenbus.c=0A@@ -398,21 +398,18 =
@@ static void scsifront_backend_changed(st=0A }=0A =0A =0A-static struct =
xenbus_device_id scsifront_ids[] =3D {=0A+static const struct xenbus_device=
_id scsifront_ids[] =3D {=0A 	{ "vscsi" },=0A 	{ "" }=0A };=0A =
MODULE_ALIAS("xen:vscsi");=0A =0A-static struct xenbus_driver scsifront_dri=
ver =3D {=0A-	.name			=3D "vscsi",=0A-	.owner		=
	=3D THIS_MODULE,=0A-	.ids			=3D scsifront_ids,=
=0A+static DEFINE_XENBUS_DRIVER(scsifront, "vscsi",=0A 	.probe			=
=3D scsifront_probe,=0A 	.remove			=3D scsifront_remov=
e,=0A /* 	.resume			=3D scsifront_resume, */=0A 	=
.otherend_changed	=3D scsifront_backend_changed,=0A-};=0A+);=0A =0A =
int scsifront_xenbus_init(void)=0A {=0A--- a/drivers/xen/tpmback/xenbus.c=
=0A+++ b/drivers/xen/tpmback/xenbus.c=0A@@ -251,23 +251,19 @@ static const =
struct xenbus_device_id tpm=0A 	{ "" }=0A };=0A =0A-=0A-static struct =
xenbus_driver tpmback =3D {=0A-	.name =3D "vtpm",=0A-	.owner =3D =
THIS_MODULE,=0A-	.ids =3D tpmback_ids,=0A+static DEFINE_XENBUS_DRIVE=
R(tpmback, "vtpm",=0A 	.probe =3D tpmback_probe,=0A 	.remove =3D =
tpmback_remove,=0A 	.otherend_changed =3D frontend_changed,=0A-};=0A+);=
=0A =0A =0A void tpmif_xenbus_init(void)=0A {=0A-	xenbus_register_bac=
kend(&tpmback);=0A+	xenbus_register_backend(&tpmback_driver);=0A }=0A =
=0A void tpmif_xenbus_exit(void)=0A {=0A-	xenbus_unregister_driver(&t=
pmback);=0A+	xenbus_unregister_driver(&tpmback_driver);=0A }=0A--- =
a/drivers/xen/usbback/xenbus.c=0A+++ b/drivers/xen/usbback/xenbus.c=0A@@ =
-317,14 +317,11 @@ static const struct xenbus_device_id usb=0A 	{ "" },=0A =
};=0A =0A-static struct xenbus_driver usbback_driver =3D {=0A-	.name =3D =
"vusb",=0A-	.owner =3D THIS_MODULE,=0A-	.ids =3D usbback_ids,=0A+st=
atic DEFINE_XENBUS_DRIVER(usbback, "vusb",=0A 	.probe =3D usbback_probe,=
=0A 	.otherend_changed =3D frontend_changed,=0A 	.remove =3D =
usbback_remove,=0A-};=0A+);=0A =0A int __init usbback_xenbus_init(void)=0A =
{=0A--- a/drivers/xen/usbfront/xenbus.c=0A+++ b/drivers/xen/usbfront/xenbus=
.c=0A@@ -379,14 +379,11 @@ static const struct xenbus_device_id usb=0A =
};=0A MODULE_ALIAS("xen:vusb");=0A =0A-static struct xenbus_driver =
usbfront_driver =3D {=0A-	.name =3D "vusb",=0A-	.owner =3D =
THIS_MODULE,=0A-	.ids =3D usbfront_ids,=0A+static DEFINE_XENBUS_DRIV=
ER(usbfront, "vusb",=0A 	.probe =3D usbfront_probe,=0A 	.otherend_c=
hanged =3D backend_changed,=0A 	.remove =3D usbfront_remove,=0A-};=0A+);=0A=
 =0A static int __init usbfront_init(void)=0A {=0A--- a/drivers/xen/xenbus/=
xenbus_probe.c=0A+++ b/drivers/xen/xenbus/xenbus_probe.c=0A@@ -382,11 =
+382,7 @@ int xenbus_register_driver_common(struct=0A 	if (bus->error)=0A =
		return bus->error;=0A =0A-	drv->driver.name =3D =
drv->name;=0A 	drv->driver.bus =3D &bus->bus;=0A-#if LINUX_VERSION_CODE =
>=3D KERNEL_VERSION(2,6,10)=0A-	drv->driver.owner =3D drv->owner;=0A-#endif=
=0A #if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,16)=0A 	drv->driver.probe =
=3D xenbus_dev_probe;=0A 	drv->driver.remove =3D xenbus_dev_remove;=
=0A--- a/include/xen/xenbus.h=0A+++ b/include/xen/xenbus.h=0A@@ -40,6 =
+40,7 @@=0A #include <linux/completion.h>=0A #include <linux/init.h>=0A =
#include <linux/err.h>=0A+#include <linux/version.h>=0A #include <xen/inter=
face/xen.h>=0A #include <xen/interface/grant_table.h>=0A #include =
<xen/interface/io/xenbus.h>=0A@@ -93,8 +94,6 @@ struct xenbus_device_id=0A =
=0A /* A xenbus driver. */=0A struct xenbus_driver {=0A-	char =
*name;=0A-	struct module *owner;=0A 	const struct xenbus_device_=
id *ids;=0A 	int (*probe)(struct xenbus_device *dev,=0A 		   =
  const struct xenbus_device_id *id);=0A@@ -110,6 +109,19 @@ struct =
xenbus_driver {=0A 	int (*is_ready)(struct xenbus_device *dev);=0A =
};=0A =0A+#if LINUX_VERSION_CODE >=3D KERNEL_VERSION(2,6,10)=0A+# define =
XENBUS_DRIVER_SET_OWNER(mod) .driver.owner =3D mod,=0A+#else=0A+# define =
XENBUS_DRIVER_SET_OWNER(mod)=0A+#endif=0A+=0A+#define DEFINE_XENBUS_DRIVER(=
var, drvname, methods...)	\=0A+struct xenbus_driver var ## _driver =
=3D {			\=0A+	.driver.name =3D drvname,			=
	\=0A+	XENBUS_DRIVER_SET_OWNER(THIS_MODULE)		\=0A+	=
.ids =3D var ## _ids, ## methods			\=0A+}=0A+=0A =
static inline struct xenbus_driver *to_xenbus_driver(struct device_driver =
*drv)=0A {=0A 	return container_of(drv, struct xenbus_driver, driver);=0A
--=__Part220D8BF9.0__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--=__Part220D8BF9.0__=--


From xen-devel-bounces@lists.xensource.com Thu Dec 15 15:54:41 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 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.xensource.com>)
	id 1RbDda-0007dY-1x; Thu, 15 Dec 2011 15:54:26 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <anthony@overnetdata.com>) id 1RbDdZ-0007cu-7H
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 15:54:25 +0000
X-Env-Sender: anthony@overnetdata.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1323964458!8106305!1
X-Originating-IP: [81.137.131.225]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24044 invoked from network); 15 Dec 2011 15:54:19 -0000
Received: from host81-137-131-225.in-addr.btopenworld.com (HELO
	zimbra.overnetdata.com) (81.137.131.225)
	by server-10.tower-21.messagelabs.com with SMTP;
	15 Dec 2011 15:54:19 -0000
Received: from localhost (localhost.localdomain [127.0.0.1])
	by zimbra.overnetdata.com (Postfix) with ESMTP id 77808160CA8;
	Thu, 15 Dec 2011 15:54:06 +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 u8T8TVdhg0zI; Thu, 15 Dec 2011 15:54:00 +0000 (GMT)
Received: from [192.168.1.51] (unknown [192.168.1.51])
	by zimbra.overnetdata.com (Postfix) with ESMTPSA id 3F6F8160CB6;
	Thu, 15 Dec 2011 15:54:00 +0000 (GMT)
Message-ID: <4EEA1818.6060106@overnetdata.com>
Date: Thu, 15 Dec 2011 15:54:00 +0000
From: Anthony Wright <anthony@overnetdata.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
References: <4EE0A6C7.9080603@overnetdata.com>
	<20111214213819.GD25896@andromeda.dapyr.net>
In-Reply-To: <20111214213819.GD25896@andromeda.dapyr.net>
X-Enigmail-Version: 1.3.4
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] VGA Passthrough crashes machine
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 14/12/2011 21:38, Konrad Rzeszutek Wilk wrote:
> On Thu, Dec 08, 2011 at 12:00:07PM +0000, Anthony Wright wrote:
>> I've just had my first attempt at getting VGA passthrough to work, and
>> it crashed the machine. I'm trying to understand whether this is a
>> problem with my hardware, configuration or a software problem.
>>
>> I'm running Xen 4.1.2 with Linux 3.1.2
>>
>>
>> The CPU is an Intel Core i5-650
>> http://ark.intel.com/products/43546/Intel-Core-i5-650-Processor-%284M-Cache-3_20-GHz%29
> And what is your motherboard? Does it have VT-d?
That was the important question... I'd missed the BIOS option to enable
VT-d which was disabled by default. I enabled the BIOS option and
everything worked, and it's very cool. :-)

This does beg a couple of other questions though....

Shouldn't I get a nice(ish) error message if I try to start a VGA
passthrough VM on hardware that doesn't support it rather than crashing
the machine?

Can I tell whether hardware will support VGA passthrough without trying
to start a VM that uses it?

Also when I shut down the VM I have to use 'xl destroy' as I'm testing
with Windows. After issuing the 'xl destroy' there is a long pause and
then the error:

    libxl: error: libxl_device.c:470:libxl__wait_for_device_model Device
Model not ready
    libxl: error: libxl_pci.c:892:do_pci_remove Device Model didn't
respond in time

If I pass through more than one device, I get the pause and the message
for each device.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 15:54:41 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 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.xensource.com>)
	id 1RbDda-0007dY-1x; Thu, 15 Dec 2011 15:54:26 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <anthony@overnetdata.com>) id 1RbDdZ-0007cu-7H
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 15:54:25 +0000
X-Env-Sender: anthony@overnetdata.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1323964458!8106305!1
X-Originating-IP: [81.137.131.225]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24044 invoked from network); 15 Dec 2011 15:54:19 -0000
Received: from host81-137-131-225.in-addr.btopenworld.com (HELO
	zimbra.overnetdata.com) (81.137.131.225)
	by server-10.tower-21.messagelabs.com with SMTP;
	15 Dec 2011 15:54:19 -0000
Received: from localhost (localhost.localdomain [127.0.0.1])
	by zimbra.overnetdata.com (Postfix) with ESMTP id 77808160CA8;
	Thu, 15 Dec 2011 15:54:06 +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 u8T8TVdhg0zI; Thu, 15 Dec 2011 15:54:00 +0000 (GMT)
Received: from [192.168.1.51] (unknown [192.168.1.51])
	by zimbra.overnetdata.com (Postfix) with ESMTPSA id 3F6F8160CB6;
	Thu, 15 Dec 2011 15:54:00 +0000 (GMT)
Message-ID: <4EEA1818.6060106@overnetdata.com>
Date: Thu, 15 Dec 2011 15:54:00 +0000
From: Anthony Wright <anthony@overnetdata.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
References: <4EE0A6C7.9080603@overnetdata.com>
	<20111214213819.GD25896@andromeda.dapyr.net>
In-Reply-To: <20111214213819.GD25896@andromeda.dapyr.net>
X-Enigmail-Version: 1.3.4
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] VGA Passthrough crashes machine
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 14/12/2011 21:38, Konrad Rzeszutek Wilk wrote:
> On Thu, Dec 08, 2011 at 12:00:07PM +0000, Anthony Wright wrote:
>> I've just had my first attempt at getting VGA passthrough to work, and
>> it crashed the machine. I'm trying to understand whether this is a
>> problem with my hardware, configuration or a software problem.
>>
>> I'm running Xen 4.1.2 with Linux 3.1.2
>>
>>
>> The CPU is an Intel Core i5-650
>> http://ark.intel.com/products/43546/Intel-Core-i5-650-Processor-%284M-Cache-3_20-GHz%29
> And what is your motherboard? Does it have VT-d?
That was the important question... I'd missed the BIOS option to enable
VT-d which was disabled by default. I enabled the BIOS option and
everything worked, and it's very cool. :-)

This does beg a couple of other questions though....

Shouldn't I get a nice(ish) error message if I try to start a VGA
passthrough VM on hardware that doesn't support it rather than crashing
the machine?

Can I tell whether hardware will support VGA passthrough without trying
to start a VM that uses it?

Also when I shut down the VM I have to use 'xl destroy' as I'm testing
with Windows. After issuing the 'xl destroy' there is a long pause and
then the error:

    libxl: error: libxl_device.c:470:libxl__wait_for_device_model Device
Model not ready
    libxl: error: libxl_pci.c:892:do_pci_remove Device Model didn't
respond in time

If I pass through more than one device, I get the pause and the message
for each device.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 15:56:30 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 15: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.xensource.com>)
	id 1RbDfM-0007qw-Lc; Thu, 15 Dec 2011 15:56:16 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Huang2@amd.com>) id 1RbDfK-0007qG-OX
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 15:56:14 +0000
X-Env-Sender: Wei.Huang2@amd.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1323964567!7423850!1
X-Originating-IP: [65.55.88.14]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28972 invoked from network); 15 Dec 2011 15:56:08 -0000
Received: from tx2ehsobe004.messaging.microsoft.com (HELO
	TX2EHSOBE009.bigfish.com) (65.55.88.14)
	by server-4.tower-182.messagelabs.com with AES128-SHA encrypted SMTP;
	15 Dec 2011 15:56:08 -0000
Received: from mail94-tx2-R.bigfish.com (10.9.14.237) by
	TX2EHSOBE009.bigfish.com (10.9.40.29) with Microsoft SMTP Server id
	14.1.225.23; Thu, 15 Dec 2011 15:56:07 +0000
Received: from mail94-tx2 (localhost [127.0.0.1])	by mail94-tx2-R.bigfish.com
	(Postfix) with ESMTP id 5DABD540424;
	Thu, 15 Dec 2011 15:56:13 +0000 (UTC)
X-SpamScore: -11
X-BigFish: VPS-11(zzbb2dI9371I1432N98dKzz1202hzz8275bh8275dhz2dh668h839h)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
Received: from mail94-tx2 (localhost.localdomain [127.0.0.1]) by mail94-tx2
	(MessageSwitch) id 1323964570144978_31018;
	Thu, 15 Dec 2011 15:56:10 +0000 (UTC)
Received: from TX2EHSMHS021.bigfish.com (unknown [10.9.14.250])	by
	mail94-tx2.bigfish.com (Postfix) with ESMTP id 1F194580042;
	Thu, 15 Dec 2011 15:56:10 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	TX2EHSMHS021.bigfish.com (10.9.99.121) with Microsoft SMTP Server id
	14.1.225.23; Thu, 15 Dec 2011 15:50:44 +0000
X-WSS-ID: 0LW95CG-01-0Q9-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 25C381028054;	Thu, 15 Dec 2011 09:50:39 -0600 (CST)
Received: from sausexhtp01.amd.com (163.181.3.165) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Thu, 15 Dec 2011 09:50:55 -0600
Received: from [10.236.49.124] (10.236.49.124) by sausexhtp01.amd.com
	(163.181.3.165) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 15 Dec 2011 09:50:40 -0600
Message-ID: <4EEA1750.5040608@amd.com>
Date: Thu, 15 Dec 2011 09:50:40 -0600
From: Wei Huang <wei.huang2@amd.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:8.0) Gecko/20111124 Thunderbird/8.0
MIME-Version: 1.0
To: Keir Fraser <keir@xen.org>
References: <CB0F9AD6.35FE9%keir@xen.org>
In-Reply-To: <CB0F9AD6.35FE9%keir@xen.org>
X-OriginatorOrg: amd.com
Cc: Boris Ostrovsky <boris.ostrovsky@amd.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH] x86/AMD: use correct shift count when
 merging model and stepping
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Good catch. Could you please apply it to xen-4.0 and xen-4.1 trees too?

Acked-by: Wei Huang <wei.huang2@amd.com>

-Wei

On 12/15/2011 06:38 AM, Keir Fraser wrote:
> On 15/12/2011 11:21, "Jan Beulich"<JBeulich@suse.com>  wrote:
>
>> ... for legacy errata matching.
>>
>> Signed-off-by: Jan Beulich<jbeulich@suse.com>
> Acked-by: Keir Fraser<keir@xen.org>
>
>> --- a/xen/arch/x86/cpu/amd.c
>> +++ b/xen/arch/x86/cpu/amd.c
>> @@ -216,7 +216,7 @@ int cpu_has_amd_erratum(const struct cpu
>> }
>>
>> /* OSVW unavailable or ID unknown, match family-model-stepping range */
>> - ms = (cpu->x86_model<<  8) | cpu->x86_mask;
>> + ms = (cpu->x86_model<<  4) | cpu->x86_mask;
>> while ((range = va_arg(ap, int))) {
>> if ((cpu->x86 == AMD_MODEL_RANGE_FAMILY(range))&&
>>     (ms>= AMD_MODEL_RANGE_START(range))&&
>>
>>
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel
>
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 15:56:30 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 15: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.xensource.com>)
	id 1RbDfM-0007qw-Lc; Thu, 15 Dec 2011 15:56:16 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Huang2@amd.com>) id 1RbDfK-0007qG-OX
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 15:56:14 +0000
X-Env-Sender: Wei.Huang2@amd.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1323964567!7423850!1
X-Originating-IP: [65.55.88.14]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28972 invoked from network); 15 Dec 2011 15:56:08 -0000
Received: from tx2ehsobe004.messaging.microsoft.com (HELO
	TX2EHSOBE009.bigfish.com) (65.55.88.14)
	by server-4.tower-182.messagelabs.com with AES128-SHA encrypted SMTP;
	15 Dec 2011 15:56:08 -0000
Received: from mail94-tx2-R.bigfish.com (10.9.14.237) by
	TX2EHSOBE009.bigfish.com (10.9.40.29) with Microsoft SMTP Server id
	14.1.225.23; Thu, 15 Dec 2011 15:56:07 +0000
Received: from mail94-tx2 (localhost [127.0.0.1])	by mail94-tx2-R.bigfish.com
	(Postfix) with ESMTP id 5DABD540424;
	Thu, 15 Dec 2011 15:56:13 +0000 (UTC)
X-SpamScore: -11
X-BigFish: VPS-11(zzbb2dI9371I1432N98dKzz1202hzz8275bh8275dhz2dh668h839h)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
Received: from mail94-tx2 (localhost.localdomain [127.0.0.1]) by mail94-tx2
	(MessageSwitch) id 1323964570144978_31018;
	Thu, 15 Dec 2011 15:56:10 +0000 (UTC)
Received: from TX2EHSMHS021.bigfish.com (unknown [10.9.14.250])	by
	mail94-tx2.bigfish.com (Postfix) with ESMTP id 1F194580042;
	Thu, 15 Dec 2011 15:56:10 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	TX2EHSMHS021.bigfish.com (10.9.99.121) with Microsoft SMTP Server id
	14.1.225.23; Thu, 15 Dec 2011 15:50:44 +0000
X-WSS-ID: 0LW95CG-01-0Q9-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 25C381028054;	Thu, 15 Dec 2011 09:50:39 -0600 (CST)
Received: from sausexhtp01.amd.com (163.181.3.165) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Thu, 15 Dec 2011 09:50:55 -0600
Received: from [10.236.49.124] (10.236.49.124) by sausexhtp01.amd.com
	(163.181.3.165) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 15 Dec 2011 09:50:40 -0600
Message-ID: <4EEA1750.5040608@amd.com>
Date: Thu, 15 Dec 2011 09:50:40 -0600
From: Wei Huang <wei.huang2@amd.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:8.0) Gecko/20111124 Thunderbird/8.0
MIME-Version: 1.0
To: Keir Fraser <keir@xen.org>
References: <CB0F9AD6.35FE9%keir@xen.org>
In-Reply-To: <CB0F9AD6.35FE9%keir@xen.org>
X-OriginatorOrg: amd.com
Cc: Boris Ostrovsky <boris.ostrovsky@amd.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH] x86/AMD: use correct shift count when
 merging model and stepping
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Good catch. Could you please apply it to xen-4.0 and xen-4.1 trees too?

Acked-by: Wei Huang <wei.huang2@amd.com>

-Wei

On 12/15/2011 06:38 AM, Keir Fraser wrote:
> On 15/12/2011 11:21, "Jan Beulich"<JBeulich@suse.com>  wrote:
>
>> ... for legacy errata matching.
>>
>> Signed-off-by: Jan Beulich<jbeulich@suse.com>
> Acked-by: Keir Fraser<keir@xen.org>
>
>> --- a/xen/arch/x86/cpu/amd.c
>> +++ b/xen/arch/x86/cpu/amd.c
>> @@ -216,7 +216,7 @@ int cpu_has_amd_erratum(const struct cpu
>> }
>>
>> /* OSVW unavailable or ID unknown, match family-model-stepping range */
>> - ms = (cpu->x86_model<<  8) | cpu->x86_mask;
>> + ms = (cpu->x86_model<<  4) | cpu->x86_mask;
>> while ((range = va_arg(ap, int))) {
>> if ((cpu->x86 == AMD_MODEL_RANGE_FAMILY(range))&&
>>     (ms>= AMD_MODEL_RANGE_START(range))&&
>>
>>
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel
>
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 16:14:41 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 16:14:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbDwu-0000bo-7q; Thu, 15 Dec 2011 16:14:24 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RbDws-0000b9-J5
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 16:14:22 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1323965655!7427741!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDQyNjA4\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26774 invoked from network); 15 Dec 2011 16:14:16 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-2.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 15 Dec 2011 16:14:16 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pBFGDJ1b011519
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 15 Dec 2011 16:13:20 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pBFGDHK5022454
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 15 Dec 2011 16:13:18 GMT
Received: from abhmt102.oracle.com (abhmt102.oracle.com [141.146.116.54])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pBFGDG2Z030251; Thu, 15 Dec 2011 10:13:17 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 15 Dec 2011 08:13:16 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 37D40416F3; Thu, 15 Dec 2011 11:12:24 -0500 (EST)
Date: Thu, 15 Dec 2011 11:12:24 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "Taylor, Neal E" <Neal.Taylor@ca.com>
Message-ID: <20111215161224.GB7272@phenom.dumpdata.com>
References: <3E243B26F475504B9BB0BCC9728B0DA629E184FA@USILMS110A.ca.com>
	<20111213232759.GA8702@konrad-lan>
	<3E243B26F475504B9BB0BCC9728B0DA629E18564@USILMS110A.ca.com>
	<4EE8785A0200007800067A16@nat28.tlf.novell.com>
	<3E243B26F475504B9BB0BCC9728B0DA629E18A6B@USILMS110A.ca.com>
	<4EE8EDF5.5070800@ca.com> <20111215015944.GD10268@konrad-lan>
	<3E243B26F475504B9BB0BCC9728B0DA629E18EBF@USILMS110A.ca.com>
	<20111215022938.GA16031@andromeda.dapyr.net>
	<3E243B26F475504B9BB0BCC9728B0DA629E18ED1@USILMS110A.ca.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <3E243B26F475504B9BB0BCC9728B0DA629E18ED1@USILMS110A.ca.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090209.4EEA1CA0.00CF,ss=1,re=0.000,fgs=0
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>,
	xen-devel <xen-devel@lists.xensource.com>, "Kalev,
	Leonid" <Leonid.Kalev@ca.com>, Tushar N Dave <tushar.n.dave@intel.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] Buffers not reachable by PCI
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Dec 15, 2011 at 02:40:32AM +0000, Taylor, Neal E wrote:
> Sure! But only if 3.0.4 is recent enough. However, that version does not have the code for the "free_bootmem" section of this patch so only the first line was actually tested. (Not that I could test the negative case if the code existed.)
> 
> I'll test on a more recent version (your pick) tomorrow, should you prefer.

Just as long as your modified code has this:

  alloc_bootmem_pages(PAGE_ALIGN(bytes));

then that is great!

(The free_bootmem we can ignore for the 3.0.4 kernel).

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 16:14:41 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 16:14:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbDwu-0000bo-7q; Thu, 15 Dec 2011 16:14:24 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RbDws-0000b9-J5
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 16:14:22 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1323965655!7427741!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDQyNjA4\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26774 invoked from network); 15 Dec 2011 16:14:16 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-2.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 15 Dec 2011 16:14:16 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pBFGDJ1b011519
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 15 Dec 2011 16:13:20 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pBFGDHK5022454
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 15 Dec 2011 16:13:18 GMT
Received: from abhmt102.oracle.com (abhmt102.oracle.com [141.146.116.54])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pBFGDG2Z030251; Thu, 15 Dec 2011 10:13:17 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 15 Dec 2011 08:13:16 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 37D40416F3; Thu, 15 Dec 2011 11:12:24 -0500 (EST)
Date: Thu, 15 Dec 2011 11:12:24 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "Taylor, Neal E" <Neal.Taylor@ca.com>
Message-ID: <20111215161224.GB7272@phenom.dumpdata.com>
References: <3E243B26F475504B9BB0BCC9728B0DA629E184FA@USILMS110A.ca.com>
	<20111213232759.GA8702@konrad-lan>
	<3E243B26F475504B9BB0BCC9728B0DA629E18564@USILMS110A.ca.com>
	<4EE8785A0200007800067A16@nat28.tlf.novell.com>
	<3E243B26F475504B9BB0BCC9728B0DA629E18A6B@USILMS110A.ca.com>
	<4EE8EDF5.5070800@ca.com> <20111215015944.GD10268@konrad-lan>
	<3E243B26F475504B9BB0BCC9728B0DA629E18EBF@USILMS110A.ca.com>
	<20111215022938.GA16031@andromeda.dapyr.net>
	<3E243B26F475504B9BB0BCC9728B0DA629E18ED1@USILMS110A.ca.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <3E243B26F475504B9BB0BCC9728B0DA629E18ED1@USILMS110A.ca.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090209.4EEA1CA0.00CF,ss=1,re=0.000,fgs=0
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>,
	xen-devel <xen-devel@lists.xensource.com>, "Kalev,
	Leonid" <Leonid.Kalev@ca.com>, Tushar N Dave <tushar.n.dave@intel.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] Buffers not reachable by PCI
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Dec 15, 2011 at 02:40:32AM +0000, Taylor, Neal E wrote:
> Sure! But only if 3.0.4 is recent enough. However, that version does not have the code for the "free_bootmem" section of this patch so only the first line was actually tested. (Not that I could test the negative case if the code existed.)
> 
> I'll test on a more recent version (your pick) tomorrow, should you prefer.

Just as long as your modified code has this:

  alloc_bootmem_pages(PAGE_ALIGN(bytes));

then that is great!

(The free_bootmem we can ignore for the 3.0.4 kernel).

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 16:15:38 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 16:15:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbDxt-0000hA-NB; Thu, 15 Dec 2011 16:15:25 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Neal.Taylor@ca.com>) id 1RbDxs-0000gw-5L
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 16:15:24 +0000
X-Env-Sender: Neal.Taylor@ca.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1323965595!48469175!1
X-Originating-IP: [74.125.149.203]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21779 invoked from network); 15 Dec 2011 16:13:17 -0000
Received: from na3sys009aog110.obsmtp.com (HELO na3sys009aog110.obsmtp.com)
	(74.125.149.203)
	by server-14.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 15 Dec 2011 16:13:17 -0000
Received: from USILMS191.ca.com ([141.202.246.45]) (using TLSv1) by
	na3sys009aob110.postini.com ([74.125.148.12]) with SMTP
	ID DSNKTuodGFKRckXlBVCzYGSB2Eg5OxEGk6Sc@postini.com;
	Thu, 15 Dec 2011 08:15:22 PST
Received: from USILMS173.ca.com (141.202.6.23) by USILMS191.ca.com
	(141.202.246.45) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Thu, 15 Dec 2011 11:14:16 -0500
Received: from USILMS110A.ca.com ([169.254.1.109]) by usilms173.ca.com
	([141.202.6.23]) with mapi id 14.01.0289.001;
	Thu, 15 Dec 2011 11:14:16 -0500
From: "Taylor, Neal E" <Neal.Taylor@ca.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Thread-Topic: [Xen-devel] Buffers not reachable by PCI
Thread-Index: Acy2r+Ulg1PsfbmtTl6QVj0jZAx7mwAK1xcAAIXl/sAAGPmvgAAhEiCwAA9ukQAACILlsAAMK30AAALQl/AAEM4lgAAPSjyAAAnO0KD//7niAIAAUk5wgACTkwCAAFNT0A==
Date: Thu, 15 Dec 2011 16:14:15 +0000
Message-ID: <3E243B26F475504B9BB0BCC9728B0DA629E1A5C5@USILMS110A.ca.com>
References: <3E243B26F475504B9BB0BCC9728B0DA629E184FA@USILMS110A.ca.com>
	<20111213232759.GA8702@konrad-lan>
	<3E243B26F475504B9BB0BCC9728B0DA629E18564@USILMS110A.ca.com>
	<4EE8785A0200007800067A16@nat28.tlf.novell.com>
	<3E243B26F475504B9BB0BCC9728B0DA629E18A6B@USILMS110A.ca.com>
	<4EE8EDF5.5070800@ca.com> <20111215015944.GD10268@konrad-lan>
	<3E243B26F475504B9BB0BCC9728B0DA629E18EBF@USILMS110A.ca.com>
	<20111215022938.GA16031@andromeda.dapyr.net>
	<3E243B26F475504B9BB0BCC9728B0DA629E18ED1@USILMS110A.ca.com>
	<20111215161224.GB7272@phenom.dumpdata.com>
In-Reply-To: <20111215161224.GB7272@phenom.dumpdata.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [138.42.46.105]
MIME-Version: 1.0
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>,
	xen-devel <xen-devel@lists.xensource.com>, "Kalev,
	Leonid" <Leonid.Kalev@ca.com>, Tushar N Dave <tushar.n.dave@intel.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] Buffers not reachable by PCI
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

The modified code has that. It's tested. It works.

Neal


-----Original Message-----
From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@oracle.com] 
Sent: Thursday, December 15, 2011 8:12 AM
To: Taylor, Neal E
Cc: Konrad Rzeszutek Wilk; Kalev, Leonid; xen-devel; Tushar N Dave; Jan Beulich
Subject: Re: [Xen-devel] Buffers not reachable by PCI

On Thu, Dec 15, 2011 at 02:40:32AM +0000, Taylor, Neal E wrote:
> Sure! But only if 3.0.4 is recent enough. However, that version does not have the code for the "free_bootmem" section of this patch so only the first line was actually tested. (Not that I could test the negative case if the code existed.)
> 
> I'll test on a more recent version (your pick) tomorrow, should you prefer.

Just as long as your modified code has this:

  alloc_bootmem_pages(PAGE_ALIGN(bytes));

then that is great!

(The free_bootmem we can ignore for the 3.0.4 kernel).

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 16:15:38 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 16:15:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbDxt-0000hA-NB; Thu, 15 Dec 2011 16:15:25 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Neal.Taylor@ca.com>) id 1RbDxs-0000gw-5L
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 16:15:24 +0000
X-Env-Sender: Neal.Taylor@ca.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1323965595!48469175!1
X-Originating-IP: [74.125.149.203]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21779 invoked from network); 15 Dec 2011 16:13:17 -0000
Received: from na3sys009aog110.obsmtp.com (HELO na3sys009aog110.obsmtp.com)
	(74.125.149.203)
	by server-14.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 15 Dec 2011 16:13:17 -0000
Received: from USILMS191.ca.com ([141.202.246.45]) (using TLSv1) by
	na3sys009aob110.postini.com ([74.125.148.12]) with SMTP
	ID DSNKTuodGFKRckXlBVCzYGSB2Eg5OxEGk6Sc@postini.com;
	Thu, 15 Dec 2011 08:15:22 PST
Received: from USILMS173.ca.com (141.202.6.23) by USILMS191.ca.com
	(141.202.246.45) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Thu, 15 Dec 2011 11:14:16 -0500
Received: from USILMS110A.ca.com ([169.254.1.109]) by usilms173.ca.com
	([141.202.6.23]) with mapi id 14.01.0289.001;
	Thu, 15 Dec 2011 11:14:16 -0500
From: "Taylor, Neal E" <Neal.Taylor@ca.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Thread-Topic: [Xen-devel] Buffers not reachable by PCI
Thread-Index: Acy2r+Ulg1PsfbmtTl6QVj0jZAx7mwAK1xcAAIXl/sAAGPmvgAAhEiCwAA9ukQAACILlsAAMK30AAALQl/AAEM4lgAAPSjyAAAnO0KD//7niAIAAUk5wgACTkwCAAFNT0A==
Date: Thu, 15 Dec 2011 16:14:15 +0000
Message-ID: <3E243B26F475504B9BB0BCC9728B0DA629E1A5C5@USILMS110A.ca.com>
References: <3E243B26F475504B9BB0BCC9728B0DA629E184FA@USILMS110A.ca.com>
	<20111213232759.GA8702@konrad-lan>
	<3E243B26F475504B9BB0BCC9728B0DA629E18564@USILMS110A.ca.com>
	<4EE8785A0200007800067A16@nat28.tlf.novell.com>
	<3E243B26F475504B9BB0BCC9728B0DA629E18A6B@USILMS110A.ca.com>
	<4EE8EDF5.5070800@ca.com> <20111215015944.GD10268@konrad-lan>
	<3E243B26F475504B9BB0BCC9728B0DA629E18EBF@USILMS110A.ca.com>
	<20111215022938.GA16031@andromeda.dapyr.net>
	<3E243B26F475504B9BB0BCC9728B0DA629E18ED1@USILMS110A.ca.com>
	<20111215161224.GB7272@phenom.dumpdata.com>
In-Reply-To: <20111215161224.GB7272@phenom.dumpdata.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [138.42.46.105]
MIME-Version: 1.0
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>,
	xen-devel <xen-devel@lists.xensource.com>, "Kalev,
	Leonid" <Leonid.Kalev@ca.com>, Tushar N Dave <tushar.n.dave@intel.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] Buffers not reachable by PCI
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

The modified code has that. It's tested. It works.

Neal


-----Original Message-----
From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@oracle.com] 
Sent: Thursday, December 15, 2011 8:12 AM
To: Taylor, Neal E
Cc: Konrad Rzeszutek Wilk; Kalev, Leonid; xen-devel; Tushar N Dave; Jan Beulich
Subject: Re: [Xen-devel] Buffers not reachable by PCI

On Thu, Dec 15, 2011 at 02:40:32AM +0000, Taylor, Neal E wrote:
> Sure! But only if 3.0.4 is recent enough. However, that version does not have the code for the "free_bootmem" section of this patch so only the first line was actually tested. (Not that I could test the negative case if the code existed.)
> 
> I'll test on a more recent version (your pick) tomorrow, should you prefer.

Just as long as your modified code has this:

  alloc_bootmem_pages(PAGE_ALIGN(bytes));

then that is great!

(The free_bootmem we can ignore for the 3.0.4 kernel).

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 16:25:43 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 16:25:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbE7V-0001SR-F8; Thu, 15 Dec 2011 16:25:21 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RbE7U-0001S8-3H
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 16:25:20 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1323966313!7553995!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjI2MA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6985 invoked from network); 15 Dec 2011 16:25:13 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 16:25:13 -0000
X-IronPort-AV: E=Sophos;i="4.71,357,1320624000"; 
   d="scan'208";a="9496322"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Dec 2011 16:25:13 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 15 Dec 2011 16:25:13 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RbE7M-0007G5-Po; Thu, 15 Dec 2011 16:25:12 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RbE7M-0002WV-OL;
	Thu, 15 Dec 2011 16:25:12 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20202.8040.720939.17273@mariner.uk.xensource.com>
Date: Thu, 15 Dec 2011 16:25:12 +0000
To: Paul Durrant <paul.durrant@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <9618ee3b6896eb8202e7.1323873461@cosworth.uk.xensource.com>
References: <patchbomb.1323873459@cosworth.uk.xensource.com>
	<9618ee3b6896eb8202e7.1323873461@cosworth.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 2 of 3] Re-name xenstore key used to save VM
 generation ID buffer address
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Paul Durrant writes ("[Xen-devel] [PATCH 2 of 3] Re-name xenstore key used to save VM generation ID buffer address"):
> Re-name xenstore key used to save VM generation ID buffer address.
> 
> Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
> 
> diff -r a4a569729741 -r 9618ee3b6896 tools/firmware/hvmloader/acpi/build.c
> --- a/tools/firmware/hvmloader/acpi/build.c	Wed Dec 14 14:34:45 2011 +0000
> +++ b/tools/firmware/hvmloader/acpi/build.c	Wed Dec 14 14:34:47 2011 +0000
> @@ -309,7 +309,7 @@ unsigned long new_vm_gid(void)
>      if ( snprintf(addr, sizeof(addr), "0x%lx", virt_to_phys(buf))
>           >= sizeof(addr) )
>          return 0;
> -    xenstore_write("data/generation-id", addr);
> +    xenstore_write("hvmloader/generation-id-address", addr);

Will just making just this change to hvmloader not cause failures
without the corresponding patch to the toolstack to make that path
writeable ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 16:25:43 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 16:25:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbE7V-0001SR-F8; Thu, 15 Dec 2011 16:25:21 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RbE7U-0001S8-3H
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 16:25:20 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1323966313!7553995!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjI2MA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6985 invoked from network); 15 Dec 2011 16:25:13 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 16:25:13 -0000
X-IronPort-AV: E=Sophos;i="4.71,357,1320624000"; 
   d="scan'208";a="9496322"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Dec 2011 16:25:13 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 15 Dec 2011 16:25:13 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RbE7M-0007G5-Po; Thu, 15 Dec 2011 16:25:12 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RbE7M-0002WV-OL;
	Thu, 15 Dec 2011 16:25:12 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20202.8040.720939.17273@mariner.uk.xensource.com>
Date: Thu, 15 Dec 2011 16:25:12 +0000
To: Paul Durrant <paul.durrant@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <9618ee3b6896eb8202e7.1323873461@cosworth.uk.xensource.com>
References: <patchbomb.1323873459@cosworth.uk.xensource.com>
	<9618ee3b6896eb8202e7.1323873461@cosworth.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 2 of 3] Re-name xenstore key used to save VM
 generation ID buffer address
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Paul Durrant writes ("[Xen-devel] [PATCH 2 of 3] Re-name xenstore key used to save VM generation ID buffer address"):
> Re-name xenstore key used to save VM generation ID buffer address.
> 
> Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
> 
> diff -r a4a569729741 -r 9618ee3b6896 tools/firmware/hvmloader/acpi/build.c
> --- a/tools/firmware/hvmloader/acpi/build.c	Wed Dec 14 14:34:45 2011 +0000
> +++ b/tools/firmware/hvmloader/acpi/build.c	Wed Dec 14 14:34:47 2011 +0000
> @@ -309,7 +309,7 @@ unsigned long new_vm_gid(void)
>      if ( snprintf(addr, sizeof(addr), "0x%lx", virt_to_phys(buf))
>           >= sizeof(addr) )
>          return 0;
> -    xenstore_write("data/generation-id", addr);
> +    xenstore_write("hvmloader/generation-id-address", addr);

Will just making just this change to hvmloader not cause failures
without the corresponding patch to the toolstack to make that path
writeable ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 16:27:41 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 16:27:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbE9V-0001Z8-2y; Thu, 15 Dec 2011 16:27:25 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RbE9T-0001Yi-Pm
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 16:27:24 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1323966437!2100811!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjI2MA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9830 invoked from network); 15 Dec 2011 16:27:17 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 16:27:17 -0000
X-IronPort-AV: E=Sophos;i="4.71,357,1320624000"; 
   d="scan'208";a="9496428"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Dec 2011 16:27:16 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 15 Dec 2011 16:27:16 +0000
Date: Thu, 15 Dec 2011 16:29:51 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Message-ID: <alpine.DEB.2.00.1112131831560.3517@kaball-desktop>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"Tim Deegan \(3P\)" <Tim.Deegan@citrix.com>
Subject: [Xen-devel] [PATCH v3 00/25] xen: ARMv7 with virtualization
	extensions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hello everyone,
this is the third version of the patch series that introduces ARMv7
with virtualization extensions support in Xen.
The series allows Xen and Dom0 to boot on a Cortex-A15 based Versatile
Express simulator.
See the following announce email for more informations about what we
are trying to achieve, as well as the original git history:

See http://marc.info/?l=xen-devel&m=132257857628098&w=2


The first 7 patches affect generic Xen code and are not ARM specific;
often they fix real issues, hidden in the default X86 configuration.

The following 18 patches introduce ARMv7 with virtualization extensions
support: makefiles first, then the asm-arm header files and finally
everything else, ordered in a way that should make the patches easier
to read.


Changes in v3:

- introduce clear_guest for x86 and ia64 (I kept ia64 version of
  clear_user for symmetry but it is not actually used anywhere);

- rename the current ARM *_user functions to *_guest;

- use raw_clear_guest and raw_copy_to_guest in elf_load_image.


Changes in v2:

- introduce CONFIG_XENOPROF;

- make _srodata and  _erodata const char[];

- do not include p2m.h ifdef __ia64__;

- remove wrong comment about pfn.h;

- introduce HAS_KEXEC and CONFIG_KEXEC;

- use long in __do_clear_user;

- remove the div64 patch, implement __aeabi_ldivmod and __aeabi_uldivmod
instead;

- move "arm: makefiles" at the end of the series.



Stefano Stabellini (25):
      Move cpufreq option parsing to cpufreq.c
      Include some header files that are not automatically included on all archs
      A collection of fixes to Xen common files
      xen: implement an signed 64 bit division helper function
      Introduce clear_user and clear_guest
      libelf-loader: introduce elf_load_image
      xen/common/Makefile: introduce HAS_CPUFREQ, HAS_PCI, HAS_PASSTHROUGH, HAS_NS16550, HAS_KEXEC
      arm: compile tmem
      arm: header files
      arm: bit manipulation, copy and division libraries
      arm: entry.S and head.S
      arm: domain
      arm: domain_build
      arm: driver for CoreLink GIC-400 Generic Interrupt Controller
      arm: mmio handlers
      arm: irq
      arm: mm and p2m
      arm: pl011 UART driver
      arm: early setup code
      arm: shutdown, smp and smpboot
      arm: driver for the generic timer for ARMv7
      arm: trap handlers
      arm: vgic emulation
      arm: vtimer
      arm: makefiles

 config/arm.mk                          |   18 +
 xen/arch/arm/Makefile                  |   76 ++++
 xen/arch/arm/Rules.mk                  |   29 ++
 xen/arch/arm/asm-offsets.c             |   76 ++++
 xen/arch/arm/domain.c                  |  269 ++++++++++++++
 xen/arch/arm/domain_build.c            |  212 +++++++++++
 xen/arch/arm/dummy.S                   |   72 ++++
 xen/arch/arm/entry.S                   |  107 ++++++
 xen/arch/arm/gic.c                     |  473 +++++++++++++++++++++++++
 xen/arch/arm/gic.h                     |  154 ++++++++
 xen/arch/arm/guestcopy.c               |   81 +++++
 xen/arch/arm/head.S                    |  298 ++++++++++++++++
 xen/arch/arm/io.c                      |   51 +++
 xen/arch/arm/io.h                      |   55 +++
 xen/arch/arm/irq.c                     |  180 ++++++++++
 xen/arch/arm/lib/Makefile              |    5 +
 xen/arch/arm/lib/assembler.h           |   49 +++
 xen/arch/arm/lib/bitops.h              |   36 ++
 xen/arch/arm/lib/changebit.S           |   18 +
 xen/arch/arm/lib/clearbit.S            |   19 +
 xen/arch/arm/lib/copy_template.S       |  266 ++++++++++++++
 xen/arch/arm/lib/div64.S               |  149 ++++++++
 xen/arch/arm/lib/findbit.S             |  115 ++++++
 xen/arch/arm/lib/lib1funcs.S           |  302 ++++++++++++++++
 xen/arch/arm/lib/memcpy.S              |   64 ++++
 xen/arch/arm/lib/memmove.S             |  200 +++++++++++
 xen/arch/arm/lib/memset.S              |  129 +++++++
 xen/arch/arm/lib/memzero.S             |  127 +++++++
 xen/arch/arm/lib/setbit.S              |   18 +
 xen/arch/arm/lib/testchangebit.S       |   18 +
 xen/arch/arm/lib/testclearbit.S        |   18 +
 xen/arch/arm/lib/testsetbit.S          |   18 +
 xen/arch/arm/mm.c                      |  321 +++++++++++++++++
 xen/arch/arm/p2m.c                     |  214 +++++++++++
 xen/arch/arm/setup.c                   |  206 +++++++++++
 xen/arch/arm/shutdown.c                |   23 ++
 xen/arch/arm/smp.c                     |   29 ++
 xen/arch/arm/smpboot.c                 |   50 +++
 xen/arch/arm/time.c                    |  181 ++++++++++
 xen/arch/arm/traps.c                   |  609 ++++++++++++++++++++++++++++++++
 xen/arch/arm/vgic.c                    |  605 +++++++++++++++++++++++++++++++
 xen/arch/arm/vtimer.c                  |  148 ++++++++
 xen/arch/arm/vtimer.h                  |   35 ++
 xen/arch/arm/xen.lds.S                 |  141 ++++++++
 xen/arch/ia64/Rules.mk                 |    5 +
 xen/arch/ia64/linux/memcpy_mck.S       |  177 +++++++++
 xen/arch/x86/Rules.mk                  |    5 +
 xen/arch/x86/hvm/hvm.c                 |  107 ++++++
 xen/arch/x86/usercopy.c                |   36 ++
 xen/common/Makefile                    |    2 +-
 xen/common/domain.c                    |   37 +--
 xen/common/domctl.c                    |    1 +
 xen/common/grant_table.c               |    1 +
 xen/common/irq.c                       |    1 +
 xen/common/kernel.c                    |    2 +-
 xen/common/keyhandler.c                |    1 +
 xen/common/lib.c                       |   19 +
 xen/common/libelf/libelf-dominfo.c     |    6 +
 xen/common/libelf/libelf-loader.c      |   17 +-
 xen/common/memory.c                    |    4 +-
 xen/common/sched_credit2.c             |    6 -
 xen/common/shutdown.c                  |    4 +
 xen/common/spinlock.c                  |    1 +
 xen/common/tmem.c                      |    3 +-
 xen/common/tmem_xen.c                  |    6 +-
 xen/common/wait.c                      |    1 +
 xen/common/xencomm.c                   |  111 ++++++
 xen/drivers/Makefile                   |    6 +-
 xen/drivers/char/Makefile              |    3 +-
 xen/drivers/char/console.c             |    5 +
 xen/drivers/char/pl011.c               |  266 ++++++++++++++
 xen/drivers/cpufreq/cpufreq.c          |   31 ++
 xen/include/asm-arm/asm_defns.h        |   18 +
 xen/include/asm-arm/atomic.h           |  212 +++++++++++
 xen/include/asm-arm/bitops.h           |  195 ++++++++++
 xen/include/asm-arm/bug.h              |   15 +
 xen/include/asm-arm/byteorder.h        |   16 +
 xen/include/asm-arm/cache.h            |   20 +
 xen/include/asm-arm/config.h           |  122 +++++++
 xen/include/asm-arm/cpregs.h           |  207 +++++++++++
 xen/include/asm-arm/current.h          |   60 ++++
 xen/include/asm-arm/debugger.h         |   15 +
 xen/include/asm-arm/delay.h            |   15 +
 xen/include/asm-arm/desc.h             |   12 +
 xen/include/asm-arm/div64.h            |  235 ++++++++++++
 xen/include/asm-arm/domain.h           |   82 +++++
 xen/include/asm-arm/elf.h              |   33 ++
 xen/include/asm-arm/event.h            |   41 +++
 xen/include/asm-arm/flushtlb.h         |   31 ++
 xen/include/asm-arm/grant_table.h      |   35 ++
 xen/include/asm-arm/guest_access.h     |  131 +++++++
 xen/include/asm-arm/hardirq.h          |   28 ++
 xen/include/asm-arm/hypercall.h        |   24 ++
 xen/include/asm-arm/init.h             |   12 +
 xen/include/asm-arm/io.h               |   12 +
 xen/include/asm-arm/iocap.h            |   20 +
 xen/include/asm-arm/irq.h              |   30 ++
 xen/include/asm-arm/mm.h               |  315 +++++++++++++++++
 xen/include/asm-arm/multicall.h        |   23 ++
 xen/include/asm-arm/nmi.h              |   15 +
 xen/include/asm-arm/numa.h             |   21 ++
 xen/include/asm-arm/p2m.h              |   88 +++++
 xen/include/asm-arm/page.h             |  335 ++++++++++++++++++
 xen/include/asm-arm/paging.h           |   13 +
 xen/include/asm-arm/percpu.h           |   28 ++
 xen/include/asm-arm/processor.h        |  269 ++++++++++++++
 xen/include/asm-arm/regs.h             |   43 +++
 xen/include/asm-arm/setup.h            |   20 +
 xen/include/asm-arm/smp.h              |   25 ++
 xen/include/asm-arm/softirq.h          |   15 +
 xen/include/asm-arm/spinlock.h         |  144 ++++++++
 xen/include/asm-arm/string.h           |   38 ++
 xen/include/asm-arm/system.h           |  202 +++++++++++
 xen/include/asm-arm/time.h             |   26 ++
 xen/include/asm-arm/trace.h            |   12 +
 xen/include/asm-arm/types.h            |   57 +++
 xen/include/asm-arm/xenoprof.h         |   12 +
 xen/include/asm-ia64/config.h          |    2 +
 xen/include/asm-ia64/uaccess.h         |   12 +
 xen/include/asm-x86/config.h           |    3 +
 xen/include/asm-x86/guest_access.h     |   18 +
 xen/include/asm-x86/hvm/guest_access.h |    1 +
 xen/include/asm-x86/uaccess.h          |    1 +
 xen/include/public/arch-arm.h          |  125 +++++++
 xen/include/public/xen.h               |    2 +
 xen/include/xen/domain.h               |    2 +
 xen/include/xen/grant_table.h          |    1 +
 xen/include/xen/guest_access.h         |    6 +
 xen/include/xen/irq.h                  |   13 +
 xen/include/xen/kernel.h               |   12 +-
 xen/include/xen/libelf.h               |    2 +-
 xen/include/xen/list.h                 |    1 +
 xen/include/xen/sched.h                |    4 +
 xen/include/xen/serial.h               |    2 +
 xen/include/xen/time.h                 |    1 +
 xen/include/xen/timer.h                |    1 +
 xen/include/xen/tmem_xen.h             |    1 +
 xen/include/xen/xencomm.h              |   24 ++
 138 files changed, 10628 insertions(+), 56 deletions(-)


A git branch is available here, based on xen-unstable (git CS
367ababd691a023944d648a6d980ccf866b01169):

git://xenbits.xen.org/people/sstabellini/xen-unstable.git arm-v3


Cheers,

Stefano

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 16:27:41 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 16:27:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbE9V-0001Z8-2y; Thu, 15 Dec 2011 16:27:25 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RbE9T-0001Yi-Pm
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 16:27:24 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1323966437!2100811!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjI2MA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9830 invoked from network); 15 Dec 2011 16:27:17 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 16:27:17 -0000
X-IronPort-AV: E=Sophos;i="4.71,357,1320624000"; 
   d="scan'208";a="9496428"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Dec 2011 16:27:16 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 15 Dec 2011 16:27:16 +0000
Date: Thu, 15 Dec 2011 16:29:51 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Message-ID: <alpine.DEB.2.00.1112131831560.3517@kaball-desktop>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"Tim Deegan \(3P\)" <Tim.Deegan@citrix.com>
Subject: [Xen-devel] [PATCH v3 00/25] xen: ARMv7 with virtualization
	extensions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hello everyone,
this is the third version of the patch series that introduces ARMv7
with virtualization extensions support in Xen.
The series allows Xen and Dom0 to boot on a Cortex-A15 based Versatile
Express simulator.
See the following announce email for more informations about what we
are trying to achieve, as well as the original git history:

See http://marc.info/?l=xen-devel&m=132257857628098&w=2


The first 7 patches affect generic Xen code and are not ARM specific;
often they fix real issues, hidden in the default X86 configuration.

The following 18 patches introduce ARMv7 with virtualization extensions
support: makefiles first, then the asm-arm header files and finally
everything else, ordered in a way that should make the patches easier
to read.


Changes in v3:

- introduce clear_guest for x86 and ia64 (I kept ia64 version of
  clear_user for symmetry but it is not actually used anywhere);

- rename the current ARM *_user functions to *_guest;

- use raw_clear_guest and raw_copy_to_guest in elf_load_image.


Changes in v2:

- introduce CONFIG_XENOPROF;

- make _srodata and  _erodata const char[];

- do not include p2m.h ifdef __ia64__;

- remove wrong comment about pfn.h;

- introduce HAS_KEXEC and CONFIG_KEXEC;

- use long in __do_clear_user;

- remove the div64 patch, implement __aeabi_ldivmod and __aeabi_uldivmod
instead;

- move "arm: makefiles" at the end of the series.



Stefano Stabellini (25):
      Move cpufreq option parsing to cpufreq.c
      Include some header files that are not automatically included on all archs
      A collection of fixes to Xen common files
      xen: implement an signed 64 bit division helper function
      Introduce clear_user and clear_guest
      libelf-loader: introduce elf_load_image
      xen/common/Makefile: introduce HAS_CPUFREQ, HAS_PCI, HAS_PASSTHROUGH, HAS_NS16550, HAS_KEXEC
      arm: compile tmem
      arm: header files
      arm: bit manipulation, copy and division libraries
      arm: entry.S and head.S
      arm: domain
      arm: domain_build
      arm: driver for CoreLink GIC-400 Generic Interrupt Controller
      arm: mmio handlers
      arm: irq
      arm: mm and p2m
      arm: pl011 UART driver
      arm: early setup code
      arm: shutdown, smp and smpboot
      arm: driver for the generic timer for ARMv7
      arm: trap handlers
      arm: vgic emulation
      arm: vtimer
      arm: makefiles

 config/arm.mk                          |   18 +
 xen/arch/arm/Makefile                  |   76 ++++
 xen/arch/arm/Rules.mk                  |   29 ++
 xen/arch/arm/asm-offsets.c             |   76 ++++
 xen/arch/arm/domain.c                  |  269 ++++++++++++++
 xen/arch/arm/domain_build.c            |  212 +++++++++++
 xen/arch/arm/dummy.S                   |   72 ++++
 xen/arch/arm/entry.S                   |  107 ++++++
 xen/arch/arm/gic.c                     |  473 +++++++++++++++++++++++++
 xen/arch/arm/gic.h                     |  154 ++++++++
 xen/arch/arm/guestcopy.c               |   81 +++++
 xen/arch/arm/head.S                    |  298 ++++++++++++++++
 xen/arch/arm/io.c                      |   51 +++
 xen/arch/arm/io.h                      |   55 +++
 xen/arch/arm/irq.c                     |  180 ++++++++++
 xen/arch/arm/lib/Makefile              |    5 +
 xen/arch/arm/lib/assembler.h           |   49 +++
 xen/arch/arm/lib/bitops.h              |   36 ++
 xen/arch/arm/lib/changebit.S           |   18 +
 xen/arch/arm/lib/clearbit.S            |   19 +
 xen/arch/arm/lib/copy_template.S       |  266 ++++++++++++++
 xen/arch/arm/lib/div64.S               |  149 ++++++++
 xen/arch/arm/lib/findbit.S             |  115 ++++++
 xen/arch/arm/lib/lib1funcs.S           |  302 ++++++++++++++++
 xen/arch/arm/lib/memcpy.S              |   64 ++++
 xen/arch/arm/lib/memmove.S             |  200 +++++++++++
 xen/arch/arm/lib/memset.S              |  129 +++++++
 xen/arch/arm/lib/memzero.S             |  127 +++++++
 xen/arch/arm/lib/setbit.S              |   18 +
 xen/arch/arm/lib/testchangebit.S       |   18 +
 xen/arch/arm/lib/testclearbit.S        |   18 +
 xen/arch/arm/lib/testsetbit.S          |   18 +
 xen/arch/arm/mm.c                      |  321 +++++++++++++++++
 xen/arch/arm/p2m.c                     |  214 +++++++++++
 xen/arch/arm/setup.c                   |  206 +++++++++++
 xen/arch/arm/shutdown.c                |   23 ++
 xen/arch/arm/smp.c                     |   29 ++
 xen/arch/arm/smpboot.c                 |   50 +++
 xen/arch/arm/time.c                    |  181 ++++++++++
 xen/arch/arm/traps.c                   |  609 ++++++++++++++++++++++++++++++++
 xen/arch/arm/vgic.c                    |  605 +++++++++++++++++++++++++++++++
 xen/arch/arm/vtimer.c                  |  148 ++++++++
 xen/arch/arm/vtimer.h                  |   35 ++
 xen/arch/arm/xen.lds.S                 |  141 ++++++++
 xen/arch/ia64/Rules.mk                 |    5 +
 xen/arch/ia64/linux/memcpy_mck.S       |  177 +++++++++
 xen/arch/x86/Rules.mk                  |    5 +
 xen/arch/x86/hvm/hvm.c                 |  107 ++++++
 xen/arch/x86/usercopy.c                |   36 ++
 xen/common/Makefile                    |    2 +-
 xen/common/domain.c                    |   37 +--
 xen/common/domctl.c                    |    1 +
 xen/common/grant_table.c               |    1 +
 xen/common/irq.c                       |    1 +
 xen/common/kernel.c                    |    2 +-
 xen/common/keyhandler.c                |    1 +
 xen/common/lib.c                       |   19 +
 xen/common/libelf/libelf-dominfo.c     |    6 +
 xen/common/libelf/libelf-loader.c      |   17 +-
 xen/common/memory.c                    |    4 +-
 xen/common/sched_credit2.c             |    6 -
 xen/common/shutdown.c                  |    4 +
 xen/common/spinlock.c                  |    1 +
 xen/common/tmem.c                      |    3 +-
 xen/common/tmem_xen.c                  |    6 +-
 xen/common/wait.c                      |    1 +
 xen/common/xencomm.c                   |  111 ++++++
 xen/drivers/Makefile                   |    6 +-
 xen/drivers/char/Makefile              |    3 +-
 xen/drivers/char/console.c             |    5 +
 xen/drivers/char/pl011.c               |  266 ++++++++++++++
 xen/drivers/cpufreq/cpufreq.c          |   31 ++
 xen/include/asm-arm/asm_defns.h        |   18 +
 xen/include/asm-arm/atomic.h           |  212 +++++++++++
 xen/include/asm-arm/bitops.h           |  195 ++++++++++
 xen/include/asm-arm/bug.h              |   15 +
 xen/include/asm-arm/byteorder.h        |   16 +
 xen/include/asm-arm/cache.h            |   20 +
 xen/include/asm-arm/config.h           |  122 +++++++
 xen/include/asm-arm/cpregs.h           |  207 +++++++++++
 xen/include/asm-arm/current.h          |   60 ++++
 xen/include/asm-arm/debugger.h         |   15 +
 xen/include/asm-arm/delay.h            |   15 +
 xen/include/asm-arm/desc.h             |   12 +
 xen/include/asm-arm/div64.h            |  235 ++++++++++++
 xen/include/asm-arm/domain.h           |   82 +++++
 xen/include/asm-arm/elf.h              |   33 ++
 xen/include/asm-arm/event.h            |   41 +++
 xen/include/asm-arm/flushtlb.h         |   31 ++
 xen/include/asm-arm/grant_table.h      |   35 ++
 xen/include/asm-arm/guest_access.h     |  131 +++++++
 xen/include/asm-arm/hardirq.h          |   28 ++
 xen/include/asm-arm/hypercall.h        |   24 ++
 xen/include/asm-arm/init.h             |   12 +
 xen/include/asm-arm/io.h               |   12 +
 xen/include/asm-arm/iocap.h            |   20 +
 xen/include/asm-arm/irq.h              |   30 ++
 xen/include/asm-arm/mm.h               |  315 +++++++++++++++++
 xen/include/asm-arm/multicall.h        |   23 ++
 xen/include/asm-arm/nmi.h              |   15 +
 xen/include/asm-arm/numa.h             |   21 ++
 xen/include/asm-arm/p2m.h              |   88 +++++
 xen/include/asm-arm/page.h             |  335 ++++++++++++++++++
 xen/include/asm-arm/paging.h           |   13 +
 xen/include/asm-arm/percpu.h           |   28 ++
 xen/include/asm-arm/processor.h        |  269 ++++++++++++++
 xen/include/asm-arm/regs.h             |   43 +++
 xen/include/asm-arm/setup.h            |   20 +
 xen/include/asm-arm/smp.h              |   25 ++
 xen/include/asm-arm/softirq.h          |   15 +
 xen/include/asm-arm/spinlock.h         |  144 ++++++++
 xen/include/asm-arm/string.h           |   38 ++
 xen/include/asm-arm/system.h           |  202 +++++++++++
 xen/include/asm-arm/time.h             |   26 ++
 xen/include/asm-arm/trace.h            |   12 +
 xen/include/asm-arm/types.h            |   57 +++
 xen/include/asm-arm/xenoprof.h         |   12 +
 xen/include/asm-ia64/config.h          |    2 +
 xen/include/asm-ia64/uaccess.h         |   12 +
 xen/include/asm-x86/config.h           |    3 +
 xen/include/asm-x86/guest_access.h     |   18 +
 xen/include/asm-x86/hvm/guest_access.h |    1 +
 xen/include/asm-x86/uaccess.h          |    1 +
 xen/include/public/arch-arm.h          |  125 +++++++
 xen/include/public/xen.h               |    2 +
 xen/include/xen/domain.h               |    2 +
 xen/include/xen/grant_table.h          |    1 +
 xen/include/xen/guest_access.h         |    6 +
 xen/include/xen/irq.h                  |   13 +
 xen/include/xen/kernel.h               |   12 +-
 xen/include/xen/libelf.h               |    2 +-
 xen/include/xen/list.h                 |    1 +
 xen/include/xen/sched.h                |    4 +
 xen/include/xen/serial.h               |    2 +
 xen/include/xen/time.h                 |    1 +
 xen/include/xen/timer.h                |    1 +
 xen/include/xen/tmem_xen.h             |    1 +
 xen/include/xen/xencomm.h              |   24 ++
 138 files changed, 10628 insertions(+), 56 deletions(-)


A git branch is available here, based on xen-unstable (git CS
367ababd691a023944d648a6d980ccf866b01169):

git://xenbits.xen.org/people/sstabellini/xen-unstable.git arm-v3


Cheers,

Stefano

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 16:27:46 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 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.xensource.com>)
	id 1RbE9d-0001aZ-M3; Thu, 15 Dec 2011 16:27:33 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RbE9c-0001ZZ-7b
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 16:27:32 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1323966445!5705584!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjI2MA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1570 invoked from network); 15 Dec 2011 16:27:26 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 16:27:26 -0000
X-IronPort-AV: E=Sophos;i="4.71,357,1320624000"; 
   d="scan'208";a="9496471"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Dec 2011 16:27:25 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 15 Dec 2011 16:27:25 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RbE9V-0007Go-Ar; Thu, 15 Dec 2011 16:27:25 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RbE9V-0002Wp-97;
	Thu, 15 Dec 2011 16:27:25 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20202.8173.110262.812143@mariner.uk.xensource.com>
Date: Thu, 15 Dec 2011 16:27:25 +0000
To: Wei Wang <wei.wang2@amd.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <93658ca85035d6a4e56e.1323876576@gran.amd.com>
References: <patchbomb.1323876561@gran.amd.com>
	<93658ca85035d6a4e56e.1323876576@gran.amd.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com, keir@xen.org, JBeulich@suse.com
Subject: Re: [Xen-devel] [PATCH 15 of 16] libxl: Introduce a new guest
	config	file parameter
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Wei Wang writes ("[Xen-devel] [PATCH 15 of 16] libxl: Introduce a new guest config file parameter"):
> libxl: Introduce a new guest config file parameter
> Use iommu = {1,0} to enable or disable guest iommu emulation.
> Default value is 0.

This needs documenting.  And that means you need to explain why a user
might want to turn this off, or on - not just say "it enables or
disables guest iommu emulation".

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 16:27:46 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 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.xensource.com>)
	id 1RbE9d-0001aZ-M3; Thu, 15 Dec 2011 16:27:33 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RbE9c-0001ZZ-7b
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 16:27:32 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1323966445!5705584!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjI2MA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1570 invoked from network); 15 Dec 2011 16:27:26 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 16:27:26 -0000
X-IronPort-AV: E=Sophos;i="4.71,357,1320624000"; 
   d="scan'208";a="9496471"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Dec 2011 16:27:25 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 15 Dec 2011 16:27:25 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RbE9V-0007Go-Ar; Thu, 15 Dec 2011 16:27:25 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RbE9V-0002Wp-97;
	Thu, 15 Dec 2011 16:27:25 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20202.8173.110262.812143@mariner.uk.xensource.com>
Date: Thu, 15 Dec 2011 16:27:25 +0000
To: Wei Wang <wei.wang2@amd.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <93658ca85035d6a4e56e.1323876576@gran.amd.com>
References: <patchbomb.1323876561@gran.amd.com>
	<93658ca85035d6a4e56e.1323876576@gran.amd.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com, keir@xen.org, JBeulich@suse.com
Subject: Re: [Xen-devel] [PATCH 15 of 16] libxl: Introduce a new guest
	config	file parameter
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Wei Wang writes ("[Xen-devel] [PATCH 15 of 16] libxl: Introduce a new guest config file parameter"):
> libxl: Introduce a new guest config file parameter
> Use iommu = {1,0} to enable or disable guest iommu emulation.
> Default value is 0.

This needs documenting.  And that means you need to explain why a user
might want to turn this off, or on - not just say "it enables or
disables guest iommu emulation".

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 16:28:15 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 16:28:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbEA6-0001ef-4K; Thu, 15 Dec 2011 16:28:02 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RbEA5-0001eQ-5I
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 16:28:01 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1323966438!46896287!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDQyNjA4\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12808 invoked from network); 15 Dec 2011 16:27:19 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-5.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 15 Dec 2011 16:27:19 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pBFGRq2q032382
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 15 Dec 2011 16:27:54 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pBFGRpaX003181
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 15 Dec 2011 16:27:52 GMT
Received: from abhmt103.oracle.com (abhmt103.oracle.com [141.146.116.55])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pBFGRpNq016623; Thu, 15 Dec 2011 10:27:51 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 15 Dec 2011 08:27:51 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 1879E416F4; Thu, 15 Dec 2011 11:26:59 -0500 (EST)
Date: Thu, 15 Dec 2011 11:26:59 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: George Shuklin <george.shuklin@gmail.com>
Message-ID: <20111215162659.GC7272@phenom.dumpdata.com>
References: <CAJeBh4sxdNTxM_oLFAuA6Mw75=LaYysrpS5b8NsZMbkf_swNVw@mail.gmail.com>
	<4EE72A94.6040904@gmail.com> <4EE75080.1000909@citrix.com>
	<1323783428.20077.298.camel@zakaz.uk.xensource.com>
	<4EE7BC9B.6040003@gmail.com>
	<1323815427.20936.96.camel@dagon.hellion.org.uk>
	<4EE7D75B.6080209@gmail.com>
	<1323847523.20936.110.camel@dagon.hellion.org.uk>
	<1323864969.20077.405.camel@zakaz.uk.xensource.com>
	<4EE9EBF5.8000402@gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4EE9EBF5.8000402@gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090204.4EEA200B.0022,ss=1,re=0.000,fgs=0
Cc: "sandr8@gmail.com" <sandr8@gmail.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>
Subject: Re: [Xen-devel] a ton of kernel issues
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Dec 15, 2011 at 04:45:41PM +0400, George Shuklin wrote:
> On 14.12.2011 16:16, Ian Campbell wrote:
> >I take it back, there is indeed a bug in the PV ops kernel in this
> >regard.
> >
> >It works with xm/xend because they set the maximum reservation for
> >guests to static-max on boot. xl (and, I think, xapi) instead set the
> >maximum reservation to the current balloon target and change it
> >dynamically as the target is changed (as a method of enforcing the
> >targets). However the pvops kernel incorrectly uses the maximum
> >reservation at boot to size the physical address space for guests.
> >
> >The patch below fixes this.
> >
> >
> (skip)
> 
> I've checked this patch against current vanilla v3.2-rc5 - it fix
> problem I wrote about.

Excellent. I added a 'Reported-and-Tested-by' with your name.
> 
> Is any chance that fix will go to release of 3.2?

That is the plan.
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 16:28:15 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 16:28:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbEA6-0001ef-4K; Thu, 15 Dec 2011 16:28:02 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RbEA5-0001eQ-5I
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 16:28:01 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1323966438!46896287!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDQyNjA4\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12808 invoked from network); 15 Dec 2011 16:27:19 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-5.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 15 Dec 2011 16:27:19 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pBFGRq2q032382
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 15 Dec 2011 16:27:54 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pBFGRpaX003181
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 15 Dec 2011 16:27:52 GMT
Received: from abhmt103.oracle.com (abhmt103.oracle.com [141.146.116.55])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pBFGRpNq016623; Thu, 15 Dec 2011 10:27:51 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 15 Dec 2011 08:27:51 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 1879E416F4; Thu, 15 Dec 2011 11:26:59 -0500 (EST)
Date: Thu, 15 Dec 2011 11:26:59 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: George Shuklin <george.shuklin@gmail.com>
Message-ID: <20111215162659.GC7272@phenom.dumpdata.com>
References: <CAJeBh4sxdNTxM_oLFAuA6Mw75=LaYysrpS5b8NsZMbkf_swNVw@mail.gmail.com>
	<4EE72A94.6040904@gmail.com> <4EE75080.1000909@citrix.com>
	<1323783428.20077.298.camel@zakaz.uk.xensource.com>
	<4EE7BC9B.6040003@gmail.com>
	<1323815427.20936.96.camel@dagon.hellion.org.uk>
	<4EE7D75B.6080209@gmail.com>
	<1323847523.20936.110.camel@dagon.hellion.org.uk>
	<1323864969.20077.405.camel@zakaz.uk.xensource.com>
	<4EE9EBF5.8000402@gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4EE9EBF5.8000402@gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090204.4EEA200B.0022,ss=1,re=0.000,fgs=0
Cc: "sandr8@gmail.com" <sandr8@gmail.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>
Subject: Re: [Xen-devel] a ton of kernel issues
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Dec 15, 2011 at 04:45:41PM +0400, George Shuklin wrote:
> On 14.12.2011 16:16, Ian Campbell wrote:
> >I take it back, there is indeed a bug in the PV ops kernel in this
> >regard.
> >
> >It works with xm/xend because they set the maximum reservation for
> >guests to static-max on boot. xl (and, I think, xapi) instead set the
> >maximum reservation to the current balloon target and change it
> >dynamically as the target is changed (as a method of enforcing the
> >targets). However the pvops kernel incorrectly uses the maximum
> >reservation at boot to size the physical address space for guests.
> >
> >The patch below fixes this.
> >
> >
> (skip)
> 
> I've checked this patch against current vanilla v3.2-rc5 - it fix
> problem I wrote about.

Excellent. I added a 'Reported-and-Tested-by' with your name.
> 
> Is any chance that fix will go to release of 3.2?

That is the plan.
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 16:29:03 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 16:29:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbEAx-0001ng-21; Thu, 15 Dec 2011 16:28:55 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RbEAv-0001mx-EW
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 16:28:53 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1323966511!59095035!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDY5Mjg=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12886 invoked from network); 15 Dec 2011 16:28: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;
	15 Dec 2011 16:28:33 -0000
X-IronPort-AV: E=Sophos;i="4.71,357,1320642000"; d="scan'208";a="20001831"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Dec 2011 11:28:51 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Thu, 15 Dec 2011 11:28:50 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pBFGSMtT003330;
	Thu, 15 Dec 2011 08:28:38 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Thu, 15 Dec 2011 16:30:37 +0000
Message-ID: <1323966657-19790-5-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1112131831560.3517@kaball-desktop>
References: <alpine.DEB.2.00.1112131831560.3517@kaball-desktop>
MIME-Version: 1.0
Cc: keir.xen@gmail.com, Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian.Campbell@citrix.com, JBeulich@suse.com, Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v3 05/25] Introduce clear_user and clear_guest
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Introduce clear_user for x86 and ia64, shamelessly taken from Linux.
The x86 version is the 32 bit clear_user implementation.
Introduce clear_guest for x86 and ia64. The x86 implementation is based
on clear_user and a new clear_user_hvm function.
The ia64 implementation is actually in xencomm and it is based on
xencomm_copy_to_guest.


Changes in v3:

- introduce clear_guest.


Changes in v2:

- change d0 to be a long;

- cast addr to long.


Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen/arch/ia64/linux/memcpy_mck.S       |  177 ++++++++++++++++++++++++++++++++
 xen/arch/x86/hvm/hvm.c                 |  107 +++++++++++++++++++
 xen/arch/x86/usercopy.c                |   36 +++++++
 xen/common/xencomm.c                   |  111 ++++++++++++++++++++
 xen/include/asm-ia64/uaccess.h         |   12 ++
 xen/include/asm-x86/guest_access.h     |   18 +++
 xen/include/asm-x86/hvm/guest_access.h |    1 +
 xen/include/asm-x86/uaccess.h          |    1 +
 xen/include/xen/guest_access.h         |    6 +
 xen/include/xen/xencomm.h              |   24 +++++
 10 files changed, 493 insertions(+), 0 deletions(-)

diff --git a/xen/arch/ia64/linux/memcpy_mck.S b/xen/arch/ia64/linux/memcpy_mck.S
index 6f308e6..8b07006 100644
--- a/xen/arch/ia64/linux/memcpy_mck.S
+++ b/xen/arch/ia64/linux/memcpy_mck.S
@@ -659,3 +659,180 @@ EK(.ex_handler,  (p17)	st8	[dst1]=r39,8);						\
 
 /* end of McKinley specific optimization */
 END(__copy_user)
+
+/*
+ * Theory of operations:
+ *	- we check whether or not the buffer is small, i.e., less than 17
+ *	  in which case we do the byte by byte loop.
+ *
+ *	- Otherwise we go progressively from 1 byte store to 8byte store in
+ *	  the head part, the body is a 16byte store loop and we finish we the
+ *	  tail for the last 15 bytes.
+ *	  The good point about this breakdown is that the long buffer handling
+ *	  contains only 2 branches.
+ *
+ *	The reason for not using shifting & masking for both the head and the
+ *	tail is to stay semantically correct. This routine is not supposed
+ *	to write bytes outside of the buffer. While most of the time this would
+ *	be ok, we can't tolerate a mistake. A classical example is the case
+ *	of multithreaded code were to the extra bytes touched is actually owned
+ *	by another thread which runs concurrently to ours. Another, less likely,
+ *	example is with device drivers where reading an I/O mapped location may
+ *	have side effects (same thing for writing).
+ */
+GLOBAL_ENTRY(__do_clear_user)
+	.prologue
+	.save ar.pfs, saved_pfs
+	alloc	saved_pfs=ar.pfs,2,0,0,0
+	cmp.eq p6,p0=r0,len		// check for zero length
+	.save ar.lc, saved_lc
+	mov saved_lc=ar.lc		// preserve ar.lc (slow)
+	.body
+	;;				// avoid WAW on CFM
+	adds tmp=-1,len			// br.ctop is repeat/until
+	mov ret0=len			// return value is length at this point
+(p6)	br.ret.spnt.many rp
+	;;
+	cmp.lt p6,p0=16,len		// if len > 16 then long memset
+	mov ar.lc=tmp			// initialize lc for small count
+(p6)	br.cond.dptk .long_do_clear
+	;;				// WAR on ar.lc
+	//
+	// worst case 16 iterations, avg 8 iterations
+	//
+	// We could have played with the predicates to use the extra
+	// M slot for 2 stores/iteration but the cost the initialization
+	// the various counters compared to how long the loop is supposed
+	// to last on average does not make this solution viable.
+	//
+1:
+	EX( .Lexit1, st1 [buf]=r0,1 )
+	adds len=-1,len			// countdown length using len
+	br.cloop.dptk 1b
+	;;				// avoid RAW on ar.lc
+	//
+	// .Lexit4: comes from byte by byte loop
+	//	    len contains bytes left
+.Lexit1:
+	mov ret0=len			// faster than using ar.lc
+	mov ar.lc=saved_lc
+	br.ret.sptk.many rp		// end of short clear_user
+
+
+	//
+	// At this point we know we have more than 16 bytes to copy
+	// so we focus on alignment (no branches required)
+	//
+	// The use of len/len2 for countdown of the number of bytes left
+	// instead of ret0 is due to the fact that the exception code
+	// changes the values of r8.
+	//
+.long_do_clear:
+	tbit.nz p6,p0=buf,0		// odd alignment (for long_do_clear)
+	;;
+	EX( .Lexit3, (p6) st1 [buf]=r0,1 )	// 1-byte aligned
+(p6)	adds len=-1,len;;		// sync because buf is modified
+	tbit.nz p6,p0=buf,1
+	;;
+	EX( .Lexit3, (p6) st2 [buf]=r0,2 )	// 2-byte aligned
+(p6)	adds len=-2,len;;
+	tbit.nz p6,p0=buf,2
+	;;
+	EX( .Lexit3, (p6) st4 [buf]=r0,4 )	// 4-byte aligned
+(p6)	adds len=-4,len;;
+	tbit.nz p6,p0=buf,3
+	;;
+	EX( .Lexit3, (p6) st8 [buf]=r0,8 )	// 8-byte aligned
+(p6)	adds len=-8,len;;
+	shr.u cnt=len,4		// number of 128-bit (2x64bit) words
+	;;
+	cmp.eq p6,p0=r0,cnt
+	adds tmp=-1,cnt
+(p6)	br.cond.dpnt .dotail		// we have less than 16 bytes left
+	;;
+	adds buf2=8,buf			// setup second base pointer
+	mov ar.lc=tmp
+	;;
+
+	//
+	// 16bytes/iteration core loop
+	//
+	// The second store can never generate a fault because
+	// we come into the loop only when we are 16-byte aligned.
+	// This means that if we cross a page then it will always be
+	// in the first store and never in the second.
+	//
+	//
+	// We need to keep track of the remaining length. A possible (optimistic)
+	// way would be to use ar.lc and derive how many byte were left by
+	// doing : left= 16*ar.lc + 16.  this would avoid the addition at
+	// every iteration.
+	// However we need to keep the synchronization point. A template
+	// M;;MB does not exist and thus we can keep the addition at no
+	// extra cycle cost (use a nop slot anyway). It also simplifies the
+	// (unlikely)  error recovery code
+	//
+
+2:	EX(.Lexit3, st8 [buf]=r0,16 )
+	;;				// needed to get len correct when error
+	st8 [buf2]=r0,16
+	adds len=-16,len
+	br.cloop.dptk 2b
+	;;
+	mov ar.lc=saved_lc
+	//
+	// tail correction based on len only
+	//
+	// We alternate the use of len3,len2 to allow parallelism and correct
+	// error handling. We also reuse p6/p7 to return correct value.
+	// The addition of len2/len3 does not cost anything more compared to
+	// the regular memset as we had empty slots.
+	//
+.dotail:
+	mov len2=len			// for parallelization of error handling
+	mov len3=len
+	tbit.nz p6,p0=len,3
+	;;
+	EX( .Lexit2, (p6) st8 [buf]=r0,8 )	// at least 8 bytes
+(p6)	adds len3=-8,len2
+	tbit.nz p7,p6=len,2
+	;;
+	EX( .Lexit2, (p7) st4 [buf]=r0,4 )	// at least 4 bytes
+(p7)	adds len2=-4,len3
+	tbit.nz p6,p7=len,1
+	;;
+	EX( .Lexit2, (p6) st2 [buf]=r0,2 )	// at least 2 bytes
+(p6)	adds len3=-2,len2
+	tbit.nz p7,p6=len,0
+	;;
+	EX( .Lexit2, (p7) st1 [buf]=r0 )	// only 1 byte left
+	mov ret0=r0				// success
+	br.ret.sptk.many rp			// end of most likely path
+
+	//
+	// Outlined error handling code
+	//
+
+	//
+	// .Lexit3: comes from core loop, need restore pr/lc
+	//	    len contains bytes left
+	//
+	//
+	// .Lexit2:
+	//	if p6 -> coming from st8 or st2 : len2 contains what's left
+	//	if p7 -> coming from st4 or st1 : len3 contains what's left
+	// We must restore lc/pr even though might not have been used.
+.Lexit2:
+	.pred.rel "mutex", p6, p7
+(p6)	mov len=len2
+(p7)	mov len=len3
+	;;
+	//
+	// .Lexit4: comes from head, need not restore pr/lc
+	//	    len contains bytes left
+	//
+.Lexit3:
+	mov ret0=len
+	mov ar.lc=saved_lc
+	br.ret.sptk.many rp
+END(__do_clear_user)
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 29452a2..04f8d00 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -2333,6 +2333,96 @@ static enum hvm_copy_result __hvm_copy(
     return HVMCOPY_okay;
 }
 
+static enum hvm_copy_result __hvm_clear(paddr_t addr, int size)
+{
+    struct vcpu *curr = current;
+    unsigned long gfn, mfn;
+    p2m_type_t p2mt;
+    char *p;
+    int count, todo = size;
+    uint32_t pfec = PFEC_page_present | PFEC_write_access;
+
+    /*
+     * XXX Disable for 4.1.0: PV-on-HVM drivers will do grant-table ops
+     * such as query_size. Grant-table code currently does copy_to/from_guest
+     * accesses under the big per-domain lock, which this test would disallow.
+     * The test is not needed until we implement sleeping-on-waitqueue when
+     * we access a paged-out frame, and that's post 4.1.0 now.
+     */
+#if 0
+    /*
+     * If the required guest memory is paged out, this function may sleep.
+     * Hence we bail immediately if called from atomic context.
+     */
+    if ( in_atomic() )
+        return HVMCOPY_unhandleable;
+#endif
+
+    while ( todo > 0 )
+    {
+        count = min_t(int, PAGE_SIZE - (addr & ~PAGE_MASK), todo);
+
+        gfn = paging_gva_to_gfn(curr, addr, &pfec);
+        if ( gfn == INVALID_GFN )
+        {
+            if ( pfec == PFEC_page_paged )
+                return HVMCOPY_gfn_paged_out;
+            if ( pfec == PFEC_page_shared )
+                return HVMCOPY_gfn_shared;
+            return HVMCOPY_bad_gva_to_gfn;
+        }
+
+        mfn = mfn_x(get_gfn_unshare(curr->domain, gfn, &p2mt));
+
+        if ( p2m_is_paging(p2mt) )
+        {
+            p2m_mem_paging_populate(curr->domain, gfn);
+            put_gfn(curr->domain, gfn);
+            return HVMCOPY_gfn_paged_out;
+        }
+        if ( p2m_is_shared(p2mt) )
+        {
+            put_gfn(curr->domain, gfn);
+            return HVMCOPY_gfn_shared;
+        }
+        if ( p2m_is_grant(p2mt) )
+        {
+            put_gfn(curr->domain, gfn);
+            return HVMCOPY_unhandleable;
+        }
+        if ( !p2m_is_ram(p2mt) )
+        {
+            put_gfn(curr->domain, gfn);
+            return HVMCOPY_bad_gfn_to_mfn;
+        }
+        ASSERT(mfn_valid(mfn));
+
+        p = (char *)map_domain_page(mfn) + (addr & ~PAGE_MASK);
+
+        if ( p2mt == p2m_ram_ro )
+        {
+            static unsigned long lastpage;
+            if ( xchg(&lastpage, gfn) != gfn )
+                gdprintk(XENLOG_DEBUG, "guest attempted write to read-only"
+                        " memory page. gfn=%#lx, mfn=%#lx\n",
+                        gfn, mfn);
+        }
+        else
+        {
+            memset(p, 0x00, count);
+            paging_mark_dirty(curr->domain, mfn);
+        }
+
+        unmap_domain_page(p);
+
+        addr += count;
+        todo -= count;
+        put_gfn(curr->domain, gfn);
+    }
+
+    return HVMCOPY_okay;
+}
+
 enum hvm_copy_result hvm_copy_to_guest_phys(
     paddr_t paddr, void *buf, int size)
 {
@@ -2419,6 +2509,23 @@ unsigned long copy_to_user_hvm(void *to, const void *from, unsigned int len)
     return rc ? len : 0; /* fake a copy_to_user() return code */
 }
 
+unsigned long clear_user_hvm(void *to, unsigned int len)
+{
+    int rc;
+
+#ifdef __x86_64__
+    if ( !current->arch.hvm_vcpu.hcall_64bit &&
+         is_compat_arg_xlat_range(to, len) )
+    {
+        memset(to, 0x00, len);
+        return 0;
+    }
+#endif
+
+    rc = __hvm_clear((unsigned long)to, len);
+    return rc ? len : 0; /* fake a copy_to_user() return code */
+}
+
 unsigned long copy_from_user_hvm(void *to, const void *from, unsigned len)
 {
     int rc;
diff --git a/xen/arch/x86/usercopy.c b/xen/arch/x86/usercopy.c
index d88e635..47dadae 100644
--- a/xen/arch/x86/usercopy.c
+++ b/xen/arch/x86/usercopy.c
@@ -110,6 +110,42 @@ copy_to_user(void __user *to, const void *from, unsigned n)
     return n;
 }
 
+#define __do_clear_user(addr,size)					\
+do {									\
+	long __d0;							\
+	__asm__ __volatile__(						\
+		"0:	rep; stosl\n"					\
+		"	movl %2,%0\n"					\
+		"1:	rep; stosb\n"					\
+		"2:\n"							\
+		".section .fixup,\"ax\"\n"				\
+		"3:	lea 0(%2,%0,4),%0\n"				\
+		"	jmp 2b\n"					\
+		".previous\n"						\
+		_ASM_EXTABLE(0b,3b)					\
+		_ASM_EXTABLE(1b,2b)					\
+		: "=&c"(size), "=&D" (__d0)				\
+		: "r"(size & 3), "0"(size / 4), "1"((long)addr), "a"(0));	\
+} while (0)
+
+/**
+ * clear_user: - Zero a block of memory in user space.
+ * @to:   Destination address, in user space.
+ * @n:    Number of bytes to zero.
+ *
+ * Zero a block of memory in user space.
+ *
+ * Returns number of bytes that could not be cleared.
+ * On success, this will be zero.
+ */
+unsigned long
+clear_user(void __user *to, unsigned n)
+{
+	if ( access_ok(to, n) )
+		__do_clear_user(to, n);
+	return n;
+}
+
 /**
  * copy_from_user: - Copy a block of data from user space.
  * @to:   Destination address, in kernel space.
diff --git a/xen/common/xencomm.c b/xen/common/xencomm.c
index 2475454..9f6c1c5 100644
--- a/xen/common/xencomm.c
+++ b/xen/common/xencomm.c
@@ -414,6 +414,117 @@ out:
     return n - from_pos;
 }
 
+static int
+xencomm_clear_chunk(
+    unsigned long paddr, unsigned int  len)
+{
+    struct page_info *page;
+    int res;
+
+    do {
+        res = xencomm_get_page(paddr, &page);
+    } while ( res == -EAGAIN );
+
+    if ( res )
+        return res;
+
+    memset(xencomm_vaddr(paddr, page), 0x00, len);
+    xencomm_mark_dirty((unsigned long)xencomm_vaddr(paddr, page), len);
+    put_page(page);
+
+    return 0;
+}
+
+static unsigned long
+xencomm_inline_clear_guest(
+    void *to, unsigned int n, unsigned int skip)
+{
+    unsigned long dest_paddr = xencomm_inline_addr(to) + skip;
+
+    while ( n > 0 )
+    {
+        unsigned int chunksz, bytes;
+
+        chunksz = PAGE_SIZE - (dest_paddr % PAGE_SIZE);
+        bytes   = min(chunksz, n);
+
+        if ( xencomm_clear_chunk(dest_paddr, bytes) )
+            return n;
+        dest_paddr += bytes;
+        n -= bytes;
+    }
+
+    /* Always successful. */
+    return 0;
+}
+
+/**
+ * xencomm_clear_guest: Clear a block of data in domain space.
+ * @to:     Physical address to xencomm buffer descriptor.
+ * @n:      Number of bytes to copy.
+ * @skip: Number of bytes from the start to skip.
+ *
+ * Clear domain data
+ *
+ * Returns number of bytes that could not be cleared
+ * On success, this will be zero.
+ */
+unsigned long
+xencomm_clear_guest(
+    void *to, unsigned int n, unsigned int skip)
+{
+    struct xencomm_ctxt ctxt;
+    unsigned int from_pos = 0;
+    unsigned int to_pos = 0;
+    unsigned int i = 0;
+
+    if ( xencomm_is_inline(to) )
+        return xencomm_inline_clear_guest(to, n, skip);
+
+    if ( xencomm_ctxt_init(to, &ctxt) )
+        return n;
+
+    /* Iterate through the descriptor, copying up to a page at a time */
+    while ( (from_pos < n) && (i < xencomm_ctxt_nr_addrs(&ctxt)) )
+    {
+        unsigned long dest_paddr;
+        unsigned int pgoffset, chunksz, chunk_skip;
+
+        if ( xencomm_ctxt_next(&ctxt, i) )
+            goto out;
+        dest_paddr = *xencomm_ctxt_address(&ctxt);
+        if ( dest_paddr == XENCOMM_INVALID )
+        {
+            i++;
+            continue;
+        }
+
+        pgoffset = dest_paddr % PAGE_SIZE;
+        chunksz = PAGE_SIZE - pgoffset;
+
+        chunk_skip = min(chunksz, skip);
+        to_pos += chunk_skip;
+        chunksz -= chunk_skip;
+        skip -= chunk_skip;
+
+        if ( skip == 0 && chunksz > 0 )
+        {
+            unsigned int bytes = min(chunksz, n - from_pos);
+
+            if ( xencomm_clear_chunk(dest_paddr + chunk_skip, bytes) )
+                goto out;
+            from_pos += bytes;
+            to_pos += bytes;
+        }
+
+        i++;
+    }
+
+out:
+    xencomm_ctxt_done(&ctxt);
+    return n - from_pos;
+}
+
 static int xencomm_inline_add_offset(void **handle, unsigned int bytes)
 {
     *handle += bytes;
diff --git a/xen/include/asm-ia64/uaccess.h b/xen/include/asm-ia64/uaccess.h
index 32ef415..2ececb1 100644
--- a/xen/include/asm-ia64/uaccess.h
+++ b/xen/include/asm-ia64/uaccess.h
@@ -236,6 +236,18 @@ __copy_from_user (void *to, const void __user *from, unsigned long count)
 	__cu_len;									\
 })
 
+extern unsigned long __do_clear_user (void __user * to, unsigned long count);
+
+#define clear_user(to, n)					\
+({								\
+	void __user *__cu_to = (to);							\
+	long __cu_len = (n);								\
+											\
+	if (__access_ok(__cu_to))							\
+		__cu_len = __do_clear_user(__cu_to, __cu_len);	\
+	__cu_len;						\
+})
+
 #define copy_from_user(to, from, n)							\
 ({											\
 	void *__cu_to = (to);								\
diff --git a/xen/include/asm-x86/guest_access.h b/xen/include/asm-x86/guest_access.h
index 99ea64d..2b429c2 100644
--- a/xen/include/asm-x86/guest_access.h
+++ b/xen/include/asm-x86/guest_access.h
@@ -21,6 +21,10 @@
     (is_hvm_vcpu(current) ?                     \
      copy_from_user_hvm((dst), (src), (len)) :  \
      copy_from_user((dst), (src), (len)))
+#define raw_clear_guest(dst,  len)              \
+    (is_hvm_vcpu(current) ?                     \
+     clear_user_hvm((dst), (len)) :             \
+     clear_user((dst), (len)))
 #define __raw_copy_to_guest(dst, src, len)      \
     (is_hvm_vcpu(current) ?                     \
      copy_to_user_hvm((dst), (src), (len)) :    \
@@ -29,6 +33,10 @@
     (is_hvm_vcpu(current) ?                     \
      copy_from_user_hvm((dst), (src), (len)) :  \
      __copy_from_user((dst), (src), (len)))
+#define __raw_clear_guest(dst,  len)            \
+    (is_hvm_vcpu(current) ?                     \
+     clear_user_hvm((dst), (len)) :             \
+     clear_user((dst), (len)))
 
 /* Is the guest handle a NULL reference? */
 #define guest_handle_is_null(hnd)        ((hnd).p == NULL)
@@ -69,6 +77,11 @@
     raw_copy_from_guest(_d, _s+(off), sizeof(*_d)*(nr));\
 })
 
+#define clear_guest_offset(hnd, off, nr) ({    \
+    void *_d = (hnd).p;                        \
+    raw_clear_guest(_d+(off), nr);             \
+})
+
 /* Copy sub-field of a structure to guest context via a guest handle. */
 #define copy_field_to_guest(hnd, ptr, field) ({         \
     const typeof(&(ptr)->field) _s = &(ptr)->field;     \
@@ -110,6 +123,11 @@
     __raw_copy_from_guest(_d, _s+(off), sizeof(*_d)*(nr));\
 })
 
+#define __clear_guest_offset(hnd, off, nr) ({    \
+    void *_d = (hnd).p;                          \
+    __raw_clear_guest(_d+(off), nr);             \
+})
+
 #define __copy_field_to_guest(hnd, ptr, field) ({       \
     const typeof(&(ptr)->field) _s = &(ptr)->field;     \
     void *_d = &(hnd).p->field;                         \
diff --git a/xen/include/asm-x86/hvm/guest_access.h b/xen/include/asm-x86/hvm/guest_access.h
index 7a89e81..b92dbe9 100644
--- a/xen/include/asm-x86/hvm/guest_access.h
+++ b/xen/include/asm-x86/hvm/guest_access.h
@@ -2,6 +2,7 @@
 #define __ASM_X86_HVM_GUEST_ACCESS_H__
 
 unsigned long copy_to_user_hvm(void *to, const void *from, unsigned len);
+unsigned long clear_user_hvm(void *to, unsigned int len);
 unsigned long copy_from_user_hvm(void *to, const void *from, unsigned len);
 
 #endif /* __ASM_X86_HVM_GUEST_ACCESS_H__ */
diff --git a/xen/include/asm-x86/uaccess.h b/xen/include/asm-x86/uaccess.h
index e3e541b..d6f4458 100644
--- a/xen/include/asm-x86/uaccess.h
+++ b/xen/include/asm-x86/uaccess.h
@@ -16,6 +16,7 @@
 #endif
 
 unsigned long copy_to_user(void *to, const void *from, unsigned len);
+unsigned long clear_user(void *to, unsigned len);
 unsigned long copy_from_user(void *to, const void *from, unsigned len);
 /* Handles exceptions in both to and from, but doesn't do access_ok */
 unsigned long __copy_to_user_ll(void *to, const void *from, unsigned n);
diff --git a/xen/include/xen/guest_access.h b/xen/include/xen/guest_access.h
index 0b9fb07..373454e 100644
--- a/xen/include/xen/guest_access.h
+++ b/xen/include/xen/guest_access.h
@@ -15,10 +15,16 @@
 #define copy_from_guest(ptr, hnd, nr)                   \
     copy_from_guest_offset(ptr, hnd, 0, nr)
 
+#define clear_guest(hnd, nr)                            \
+    clear_guest_offset(hnd, 0, nr)
+
 #define __copy_to_guest(hnd, ptr, nr)                   \
     __copy_to_guest_offset(hnd, 0, ptr, nr)
 
 #define __copy_from_guest(ptr, hnd, nr)                 \
     __copy_from_guest_offset(ptr, hnd, 0, nr)
 
+#define __clear_guest(hnd, nr)                          \
+    __clear_guest_offset(hnd, 0, nr)
+
 #endif /* __XEN_GUEST_ACCESS_H__ */
diff --git a/xen/include/xen/xencomm.h b/xen/include/xen/xencomm.h
index bce2ca7..730da7c 100644
--- a/xen/include/xen/xencomm.h
+++ b/xen/include/xen/xencomm.h
@@ -27,6 +27,8 @@ unsigned long xencomm_copy_to_guest(
     void *to, const void *from, unsigned int len, unsigned int skip); 
 unsigned long xencomm_copy_from_guest(
     void *to, const void *from, unsigned int len, unsigned int skip); 
+unsigned long xencomm_clear_guest(
+    void *to, unsigned int n, unsigned int skip);
 int xencomm_add_offset(void **handle, unsigned int bytes);
 int xencomm_handle_is_null(void *ptr);
 
@@ -41,6 +43,16 @@ static inline unsigned long xencomm_inline_addr(const void *handle)
     return (unsigned long)handle & ~XENCOMM_INLINE_FLAG;
 }
 
+#define raw_copy_to_guest(dst, src, len)       \
+    xencomm_copy_to_guest(dst, src, len, 0)
+#define raw_copy_from_guest(dst, src, len)     \
+    xencomm_copy_from_guest(dst, src, nr, 0)
+#define raw_clear_guest(dst, len)              \
+    xencomm_clear_guest(dst, len, 0)
+#define __raw_copy_to_guest raw_copy_to_guest
+#define __raw_copy_from_guest raw_copy_from_guest
+#define __raw_clear_guest raw_clear_guest
+
 /* Is the guest handle a NULL reference? */
 #define guest_handle_is_null(hnd) \
     ((hnd).p == NULL || xencomm_handle_is_null((hnd).p))
@@ -82,6 +94,13 @@ static inline unsigned long xencomm_inline_addr(const void *handle)
 #define copy_from_guest_offset(ptr, hnd, idx, nr) \
     __copy_from_guest_offset(ptr, hnd, idx, nr)
 
+/*
+ * Clear an array of objects in guest context via a guest handle.
+ * Optionally specify an offset into the guest array.
+ */
+#define clear_guest_offset(hnd, idx, nr) \
+    __clear_guest_offset(hnd, idx, nr)
+
 /* Copy sub-field of a structure from guest context via a guest handle. */
 #define copy_field_from_guest(ptr, hnd, field) \
     __copy_field_from_guest(ptr, hnd, field)
@@ -115,6 +134,11 @@ static inline unsigned long xencomm_inline_addr(const void *handle)
     xencomm_copy_from_guest(_d, _s, sizeof(*_d), _off);             \
 })
 
+#define __clear_guest_offset(hnd, idx, nr) ({                \
+    void *_d = (hnd).p;                                             \
+    xencomm_clear_guest(_d, nr, idx); \
+})
+
 #ifdef CONFIG_XENCOMM_MARK_DIRTY
 extern void xencomm_mark_dirty(unsigned long addr, unsigned int len);
 #else
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 16:29:03 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 16:29:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbEAx-0001ng-21; Thu, 15 Dec 2011 16:28:55 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RbEAv-0001mx-EW
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 16:28:53 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1323966511!59095035!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDY5Mjg=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12886 invoked from network); 15 Dec 2011 16:28: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;
	15 Dec 2011 16:28:33 -0000
X-IronPort-AV: E=Sophos;i="4.71,357,1320642000"; d="scan'208";a="20001831"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Dec 2011 11:28:51 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Thu, 15 Dec 2011 11:28:50 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pBFGSMtT003330;
	Thu, 15 Dec 2011 08:28:38 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Thu, 15 Dec 2011 16:30:37 +0000
Message-ID: <1323966657-19790-5-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1112131831560.3517@kaball-desktop>
References: <alpine.DEB.2.00.1112131831560.3517@kaball-desktop>
MIME-Version: 1.0
Cc: keir.xen@gmail.com, Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian.Campbell@citrix.com, JBeulich@suse.com, Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v3 05/25] Introduce clear_user and clear_guest
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Introduce clear_user for x86 and ia64, shamelessly taken from Linux.
The x86 version is the 32 bit clear_user implementation.
Introduce clear_guest for x86 and ia64. The x86 implementation is based
on clear_user and a new clear_user_hvm function.
The ia64 implementation is actually in xencomm and it is based on
xencomm_copy_to_guest.


Changes in v3:

- introduce clear_guest.


Changes in v2:

- change d0 to be a long;

- cast addr to long.


Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen/arch/ia64/linux/memcpy_mck.S       |  177 ++++++++++++++++++++++++++++++++
 xen/arch/x86/hvm/hvm.c                 |  107 +++++++++++++++++++
 xen/arch/x86/usercopy.c                |   36 +++++++
 xen/common/xencomm.c                   |  111 ++++++++++++++++++++
 xen/include/asm-ia64/uaccess.h         |   12 ++
 xen/include/asm-x86/guest_access.h     |   18 +++
 xen/include/asm-x86/hvm/guest_access.h |    1 +
 xen/include/asm-x86/uaccess.h          |    1 +
 xen/include/xen/guest_access.h         |    6 +
 xen/include/xen/xencomm.h              |   24 +++++
 10 files changed, 493 insertions(+), 0 deletions(-)

diff --git a/xen/arch/ia64/linux/memcpy_mck.S b/xen/arch/ia64/linux/memcpy_mck.S
index 6f308e6..8b07006 100644
--- a/xen/arch/ia64/linux/memcpy_mck.S
+++ b/xen/arch/ia64/linux/memcpy_mck.S
@@ -659,3 +659,180 @@ EK(.ex_handler,  (p17)	st8	[dst1]=r39,8);						\
 
 /* end of McKinley specific optimization */
 END(__copy_user)
+
+/*
+ * Theory of operations:
+ *	- we check whether or not the buffer is small, i.e., less than 17
+ *	  in which case we do the byte by byte loop.
+ *
+ *	- Otherwise we go progressively from 1 byte store to 8byte store in
+ *	  the head part, the body is a 16byte store loop and we finish we the
+ *	  tail for the last 15 bytes.
+ *	  The good point about this breakdown is that the long buffer handling
+ *	  contains only 2 branches.
+ *
+ *	The reason for not using shifting & masking for both the head and the
+ *	tail is to stay semantically correct. This routine is not supposed
+ *	to write bytes outside of the buffer. While most of the time this would
+ *	be ok, we can't tolerate a mistake. A classical example is the case
+ *	of multithreaded code were to the extra bytes touched is actually owned
+ *	by another thread which runs concurrently to ours. Another, less likely,
+ *	example is with device drivers where reading an I/O mapped location may
+ *	have side effects (same thing for writing).
+ */
+GLOBAL_ENTRY(__do_clear_user)
+	.prologue
+	.save ar.pfs, saved_pfs
+	alloc	saved_pfs=ar.pfs,2,0,0,0
+	cmp.eq p6,p0=r0,len		// check for zero length
+	.save ar.lc, saved_lc
+	mov saved_lc=ar.lc		// preserve ar.lc (slow)
+	.body
+	;;				// avoid WAW on CFM
+	adds tmp=-1,len			// br.ctop is repeat/until
+	mov ret0=len			// return value is length at this point
+(p6)	br.ret.spnt.many rp
+	;;
+	cmp.lt p6,p0=16,len		// if len > 16 then long memset
+	mov ar.lc=tmp			// initialize lc for small count
+(p6)	br.cond.dptk .long_do_clear
+	;;				// WAR on ar.lc
+	//
+	// worst case 16 iterations, avg 8 iterations
+	//
+	// We could have played with the predicates to use the extra
+	// M slot for 2 stores/iteration but the cost the initialization
+	// the various counters compared to how long the loop is supposed
+	// to last on average does not make this solution viable.
+	//
+1:
+	EX( .Lexit1, st1 [buf]=r0,1 )
+	adds len=-1,len			// countdown length using len
+	br.cloop.dptk 1b
+	;;				// avoid RAW on ar.lc
+	//
+	// .Lexit4: comes from byte by byte loop
+	//	    len contains bytes left
+.Lexit1:
+	mov ret0=len			// faster than using ar.lc
+	mov ar.lc=saved_lc
+	br.ret.sptk.many rp		// end of short clear_user
+
+
+	//
+	// At this point we know we have more than 16 bytes to copy
+	// so we focus on alignment (no branches required)
+	//
+	// The use of len/len2 for countdown of the number of bytes left
+	// instead of ret0 is due to the fact that the exception code
+	// changes the values of r8.
+	//
+.long_do_clear:
+	tbit.nz p6,p0=buf,0		// odd alignment (for long_do_clear)
+	;;
+	EX( .Lexit3, (p6) st1 [buf]=r0,1 )	// 1-byte aligned
+(p6)	adds len=-1,len;;		// sync because buf is modified
+	tbit.nz p6,p0=buf,1
+	;;
+	EX( .Lexit3, (p6) st2 [buf]=r0,2 )	// 2-byte aligned
+(p6)	adds len=-2,len;;
+	tbit.nz p6,p0=buf,2
+	;;
+	EX( .Lexit3, (p6) st4 [buf]=r0,4 )	// 4-byte aligned
+(p6)	adds len=-4,len;;
+	tbit.nz p6,p0=buf,3
+	;;
+	EX( .Lexit3, (p6) st8 [buf]=r0,8 )	// 8-byte aligned
+(p6)	adds len=-8,len;;
+	shr.u cnt=len,4		// number of 128-bit (2x64bit) words
+	;;
+	cmp.eq p6,p0=r0,cnt
+	adds tmp=-1,cnt
+(p6)	br.cond.dpnt .dotail		// we have less than 16 bytes left
+	;;
+	adds buf2=8,buf			// setup second base pointer
+	mov ar.lc=tmp
+	;;
+
+	//
+	// 16bytes/iteration core loop
+	//
+	// The second store can never generate a fault because
+	// we come into the loop only when we are 16-byte aligned.
+	// This means that if we cross a page then it will always be
+	// in the first store and never in the second.
+	//
+	//
+	// We need to keep track of the remaining length. A possible (optimistic)
+	// way would be to use ar.lc and derive how many byte were left by
+	// doing : left= 16*ar.lc + 16.  this would avoid the addition at
+	// every iteration.
+	// However we need to keep the synchronization point. A template
+	// M;;MB does not exist and thus we can keep the addition at no
+	// extra cycle cost (use a nop slot anyway). It also simplifies the
+	// (unlikely)  error recovery code
+	//
+
+2:	EX(.Lexit3, st8 [buf]=r0,16 )
+	;;				// needed to get len correct when error
+	st8 [buf2]=r0,16
+	adds len=-16,len
+	br.cloop.dptk 2b
+	;;
+	mov ar.lc=saved_lc
+	//
+	// tail correction based on len only
+	//
+	// We alternate the use of len3,len2 to allow parallelism and correct
+	// error handling. We also reuse p6/p7 to return correct value.
+	// The addition of len2/len3 does not cost anything more compared to
+	// the regular memset as we had empty slots.
+	//
+.dotail:
+	mov len2=len			// for parallelization of error handling
+	mov len3=len
+	tbit.nz p6,p0=len,3
+	;;
+	EX( .Lexit2, (p6) st8 [buf]=r0,8 )	// at least 8 bytes
+(p6)	adds len3=-8,len2
+	tbit.nz p7,p6=len,2
+	;;
+	EX( .Lexit2, (p7) st4 [buf]=r0,4 )	// at least 4 bytes
+(p7)	adds len2=-4,len3
+	tbit.nz p6,p7=len,1
+	;;
+	EX( .Lexit2, (p6) st2 [buf]=r0,2 )	// at least 2 bytes
+(p6)	adds len3=-2,len2
+	tbit.nz p7,p6=len,0
+	;;
+	EX( .Lexit2, (p7) st1 [buf]=r0 )	// only 1 byte left
+	mov ret0=r0				// success
+	br.ret.sptk.many rp			// end of most likely path
+
+	//
+	// Outlined error handling code
+	//
+
+	//
+	// .Lexit3: comes from core loop, need restore pr/lc
+	//	    len contains bytes left
+	//
+	//
+	// .Lexit2:
+	//	if p6 -> coming from st8 or st2 : len2 contains what's left
+	//	if p7 -> coming from st4 or st1 : len3 contains what's left
+	// We must restore lc/pr even though might not have been used.
+.Lexit2:
+	.pred.rel "mutex", p6, p7
+(p6)	mov len=len2
+(p7)	mov len=len3
+	;;
+	//
+	// .Lexit4: comes from head, need not restore pr/lc
+	//	    len contains bytes left
+	//
+.Lexit3:
+	mov ret0=len
+	mov ar.lc=saved_lc
+	br.ret.sptk.many rp
+END(__do_clear_user)
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 29452a2..04f8d00 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -2333,6 +2333,96 @@ static enum hvm_copy_result __hvm_copy(
     return HVMCOPY_okay;
 }
 
+static enum hvm_copy_result __hvm_clear(paddr_t addr, int size)
+{
+    struct vcpu *curr = current;
+    unsigned long gfn, mfn;
+    p2m_type_t p2mt;
+    char *p;
+    int count, todo = size;
+    uint32_t pfec = PFEC_page_present | PFEC_write_access;
+
+    /*
+     * XXX Disable for 4.1.0: PV-on-HVM drivers will do grant-table ops
+     * such as query_size. Grant-table code currently does copy_to/from_guest
+     * accesses under the big per-domain lock, which this test would disallow.
+     * The test is not needed until we implement sleeping-on-waitqueue when
+     * we access a paged-out frame, and that's post 4.1.0 now.
+     */
+#if 0
+    /*
+     * If the required guest memory is paged out, this function may sleep.
+     * Hence we bail immediately if called from atomic context.
+     */
+    if ( in_atomic() )
+        return HVMCOPY_unhandleable;
+#endif
+
+    while ( todo > 0 )
+    {
+        count = min_t(int, PAGE_SIZE - (addr & ~PAGE_MASK), todo);
+
+        gfn = paging_gva_to_gfn(curr, addr, &pfec);
+        if ( gfn == INVALID_GFN )
+        {
+            if ( pfec == PFEC_page_paged )
+                return HVMCOPY_gfn_paged_out;
+            if ( pfec == PFEC_page_shared )
+                return HVMCOPY_gfn_shared;
+            return HVMCOPY_bad_gva_to_gfn;
+        }
+
+        mfn = mfn_x(get_gfn_unshare(curr->domain, gfn, &p2mt));
+
+        if ( p2m_is_paging(p2mt) )
+        {
+            p2m_mem_paging_populate(curr->domain, gfn);
+            put_gfn(curr->domain, gfn);
+            return HVMCOPY_gfn_paged_out;
+        }
+        if ( p2m_is_shared(p2mt) )
+        {
+            put_gfn(curr->domain, gfn);
+            return HVMCOPY_gfn_shared;
+        }
+        if ( p2m_is_grant(p2mt) )
+        {
+            put_gfn(curr->domain, gfn);
+            return HVMCOPY_unhandleable;
+        }
+        if ( !p2m_is_ram(p2mt) )
+        {
+            put_gfn(curr->domain, gfn);
+            return HVMCOPY_bad_gfn_to_mfn;
+        }
+        ASSERT(mfn_valid(mfn));
+
+        p = (char *)map_domain_page(mfn) + (addr & ~PAGE_MASK);
+
+        if ( p2mt == p2m_ram_ro )
+        {
+            static unsigned long lastpage;
+            if ( xchg(&lastpage, gfn) != gfn )
+                gdprintk(XENLOG_DEBUG, "guest attempted write to read-only"
+                        " memory page. gfn=%#lx, mfn=%#lx\n",
+                        gfn, mfn);
+        }
+        else
+        {
+            memset(p, 0x00, count);
+            paging_mark_dirty(curr->domain, mfn);
+        }
+
+        unmap_domain_page(p);
+
+        addr += count;
+        todo -= count;
+        put_gfn(curr->domain, gfn);
+    }
+
+    return HVMCOPY_okay;
+}
+
 enum hvm_copy_result hvm_copy_to_guest_phys(
     paddr_t paddr, void *buf, int size)
 {
@@ -2419,6 +2509,23 @@ unsigned long copy_to_user_hvm(void *to, const void *from, unsigned int len)
     return rc ? len : 0; /* fake a copy_to_user() return code */
 }
 
+unsigned long clear_user_hvm(void *to, unsigned int len)
+{
+    int rc;
+
+#ifdef __x86_64__
+    if ( !current->arch.hvm_vcpu.hcall_64bit &&
+         is_compat_arg_xlat_range(to, len) )
+    {
+        memset(to, 0x00, len);
+        return 0;
+    }
+#endif
+
+    rc = __hvm_clear((unsigned long)to, len);
+    return rc ? len : 0; /* fake a copy_to_user() return code */
+}
+
 unsigned long copy_from_user_hvm(void *to, const void *from, unsigned len)
 {
     int rc;
diff --git a/xen/arch/x86/usercopy.c b/xen/arch/x86/usercopy.c
index d88e635..47dadae 100644
--- a/xen/arch/x86/usercopy.c
+++ b/xen/arch/x86/usercopy.c
@@ -110,6 +110,42 @@ copy_to_user(void __user *to, const void *from, unsigned n)
     return n;
 }
 
+#define __do_clear_user(addr,size)					\
+do {									\
+	long __d0;							\
+	__asm__ __volatile__(						\
+		"0:	rep; stosl\n"					\
+		"	movl %2,%0\n"					\
+		"1:	rep; stosb\n"					\
+		"2:\n"							\
+		".section .fixup,\"ax\"\n"				\
+		"3:	lea 0(%2,%0,4),%0\n"				\
+		"	jmp 2b\n"					\
+		".previous\n"						\
+		_ASM_EXTABLE(0b,3b)					\
+		_ASM_EXTABLE(1b,2b)					\
+		: "=&c"(size), "=&D" (__d0)				\
+		: "r"(size & 3), "0"(size / 4), "1"((long)addr), "a"(0));	\
+} while (0)
+
+/**
+ * clear_user: - Zero a block of memory in user space.
+ * @to:   Destination address, in user space.
+ * @n:    Number of bytes to zero.
+ *
+ * Zero a block of memory in user space.
+ *
+ * Returns number of bytes that could not be cleared.
+ * On success, this will be zero.
+ */
+unsigned long
+clear_user(void __user *to, unsigned n)
+{
+	if ( access_ok(to, n) )
+		__do_clear_user(to, n);
+	return n;
+}
+
 /**
  * copy_from_user: - Copy a block of data from user space.
  * @to:   Destination address, in kernel space.
diff --git a/xen/common/xencomm.c b/xen/common/xencomm.c
index 2475454..9f6c1c5 100644
--- a/xen/common/xencomm.c
+++ b/xen/common/xencomm.c
@@ -414,6 +414,117 @@ out:
     return n - from_pos;
 }
 
+static int
+xencomm_clear_chunk(
+    unsigned long paddr, unsigned int  len)
+{
+    struct page_info *page;
+    int res;
+
+    do {
+        res = xencomm_get_page(paddr, &page);
+    } while ( res == -EAGAIN );
+
+    if ( res )
+        return res;
+
+    memset(xencomm_vaddr(paddr, page), 0x00, len);
+    xencomm_mark_dirty((unsigned long)xencomm_vaddr(paddr, page), len);
+    put_page(page);
+
+    return 0;
+}
+
+static unsigned long
+xencomm_inline_clear_guest(
+    void *to, unsigned int n, unsigned int skip)
+{
+    unsigned long dest_paddr = xencomm_inline_addr(to) + skip;
+
+    while ( n > 0 )
+    {
+        unsigned int chunksz, bytes;
+
+        chunksz = PAGE_SIZE - (dest_paddr % PAGE_SIZE);
+        bytes   = min(chunksz, n);
+
+        if ( xencomm_clear_chunk(dest_paddr, bytes) )
+            return n;
+        dest_paddr += bytes;
+        n -= bytes;
+    }
+
+    /* Always successful. */
+    return 0;
+}
+
+/**
+ * xencomm_clear_guest: Clear a block of data in domain space.
+ * @to:     Physical address to xencomm buffer descriptor.
+ * @n:      Number of bytes to copy.
+ * @skip: Number of bytes from the start to skip.
+ *
+ * Clear domain data
+ *
+ * Returns number of bytes that could not be cleared
+ * On success, this will be zero.
+ */
+unsigned long
+xencomm_clear_guest(
+    void *to, unsigned int n, unsigned int skip)
+{
+    struct xencomm_ctxt ctxt;
+    unsigned int from_pos = 0;
+    unsigned int to_pos = 0;
+    unsigned int i = 0;
+
+    if ( xencomm_is_inline(to) )
+        return xencomm_inline_clear_guest(to, n, skip);
+
+    if ( xencomm_ctxt_init(to, &ctxt) )
+        return n;
+
+    /* Iterate through the descriptor, copying up to a page at a time */
+    while ( (from_pos < n) && (i < xencomm_ctxt_nr_addrs(&ctxt)) )
+    {
+        unsigned long dest_paddr;
+        unsigned int pgoffset, chunksz, chunk_skip;
+
+        if ( xencomm_ctxt_next(&ctxt, i) )
+            goto out;
+        dest_paddr = *xencomm_ctxt_address(&ctxt);
+        if ( dest_paddr == XENCOMM_INVALID )
+        {
+            i++;
+            continue;
+        }
+
+        pgoffset = dest_paddr % PAGE_SIZE;
+        chunksz = PAGE_SIZE - pgoffset;
+
+        chunk_skip = min(chunksz, skip);
+        to_pos += chunk_skip;
+        chunksz -= chunk_skip;
+        skip -= chunk_skip;
+
+        if ( skip == 0 && chunksz > 0 )
+        {
+            unsigned int bytes = min(chunksz, n - from_pos);
+
+            if ( xencomm_clear_chunk(dest_paddr + chunk_skip, bytes) )
+                goto out;
+            from_pos += bytes;
+            to_pos += bytes;
+        }
+
+        i++;
+    }
+
+out:
+    xencomm_ctxt_done(&ctxt);
+    return n - from_pos;
+}
+
 static int xencomm_inline_add_offset(void **handle, unsigned int bytes)
 {
     *handle += bytes;
diff --git a/xen/include/asm-ia64/uaccess.h b/xen/include/asm-ia64/uaccess.h
index 32ef415..2ececb1 100644
--- a/xen/include/asm-ia64/uaccess.h
+++ b/xen/include/asm-ia64/uaccess.h
@@ -236,6 +236,18 @@ __copy_from_user (void *to, const void __user *from, unsigned long count)
 	__cu_len;									\
 })
 
+extern unsigned long __do_clear_user (void __user * to, unsigned long count);
+
+#define clear_user(to, n)					\
+({								\
+	void __user *__cu_to = (to);							\
+	long __cu_len = (n);								\
+											\
+	if (__access_ok(__cu_to))							\
+		__cu_len = __do_clear_user(__cu_to, __cu_len);	\
+	__cu_len;						\
+})
+
 #define copy_from_user(to, from, n)							\
 ({											\
 	void *__cu_to = (to);								\
diff --git a/xen/include/asm-x86/guest_access.h b/xen/include/asm-x86/guest_access.h
index 99ea64d..2b429c2 100644
--- a/xen/include/asm-x86/guest_access.h
+++ b/xen/include/asm-x86/guest_access.h
@@ -21,6 +21,10 @@
     (is_hvm_vcpu(current) ?                     \
      copy_from_user_hvm((dst), (src), (len)) :  \
      copy_from_user((dst), (src), (len)))
+#define raw_clear_guest(dst,  len)              \
+    (is_hvm_vcpu(current) ?                     \
+     clear_user_hvm((dst), (len)) :             \
+     clear_user((dst), (len)))
 #define __raw_copy_to_guest(dst, src, len)      \
     (is_hvm_vcpu(current) ?                     \
      copy_to_user_hvm((dst), (src), (len)) :    \
@@ -29,6 +33,10 @@
     (is_hvm_vcpu(current) ?                     \
      copy_from_user_hvm((dst), (src), (len)) :  \
      __copy_from_user((dst), (src), (len)))
+#define __raw_clear_guest(dst,  len)            \
+    (is_hvm_vcpu(current) ?                     \
+     clear_user_hvm((dst), (len)) :             \
+     clear_user((dst), (len)))
 
 /* Is the guest handle a NULL reference? */
 #define guest_handle_is_null(hnd)        ((hnd).p == NULL)
@@ -69,6 +77,11 @@
     raw_copy_from_guest(_d, _s+(off), sizeof(*_d)*(nr));\
 })
 
+#define clear_guest_offset(hnd, off, nr) ({    \
+    void *_d = (hnd).p;                        \
+    raw_clear_guest(_d+(off), nr);             \
+})
+
 /* Copy sub-field of a structure to guest context via a guest handle. */
 #define copy_field_to_guest(hnd, ptr, field) ({         \
     const typeof(&(ptr)->field) _s = &(ptr)->field;     \
@@ -110,6 +123,11 @@
     __raw_copy_from_guest(_d, _s+(off), sizeof(*_d)*(nr));\
 })
 
+#define __clear_guest_offset(hnd, off, nr) ({    \
+    void *_d = (hnd).p;                          \
+    __raw_clear_guest(_d+(off), nr);             \
+})
+
 #define __copy_field_to_guest(hnd, ptr, field) ({       \
     const typeof(&(ptr)->field) _s = &(ptr)->field;     \
     void *_d = &(hnd).p->field;                         \
diff --git a/xen/include/asm-x86/hvm/guest_access.h b/xen/include/asm-x86/hvm/guest_access.h
index 7a89e81..b92dbe9 100644
--- a/xen/include/asm-x86/hvm/guest_access.h
+++ b/xen/include/asm-x86/hvm/guest_access.h
@@ -2,6 +2,7 @@
 #define __ASM_X86_HVM_GUEST_ACCESS_H__
 
 unsigned long copy_to_user_hvm(void *to, const void *from, unsigned len);
+unsigned long clear_user_hvm(void *to, unsigned int len);
 unsigned long copy_from_user_hvm(void *to, const void *from, unsigned len);
 
 #endif /* __ASM_X86_HVM_GUEST_ACCESS_H__ */
diff --git a/xen/include/asm-x86/uaccess.h b/xen/include/asm-x86/uaccess.h
index e3e541b..d6f4458 100644
--- a/xen/include/asm-x86/uaccess.h
+++ b/xen/include/asm-x86/uaccess.h
@@ -16,6 +16,7 @@
 #endif
 
 unsigned long copy_to_user(void *to, const void *from, unsigned len);
+unsigned long clear_user(void *to, unsigned len);
 unsigned long copy_from_user(void *to, const void *from, unsigned len);
 /* Handles exceptions in both to and from, but doesn't do access_ok */
 unsigned long __copy_to_user_ll(void *to, const void *from, unsigned n);
diff --git a/xen/include/xen/guest_access.h b/xen/include/xen/guest_access.h
index 0b9fb07..373454e 100644
--- a/xen/include/xen/guest_access.h
+++ b/xen/include/xen/guest_access.h
@@ -15,10 +15,16 @@
 #define copy_from_guest(ptr, hnd, nr)                   \
     copy_from_guest_offset(ptr, hnd, 0, nr)
 
+#define clear_guest(hnd, nr)                            \
+    clear_guest_offset(hnd, 0, nr)
+
 #define __copy_to_guest(hnd, ptr, nr)                   \
     __copy_to_guest_offset(hnd, 0, ptr, nr)
 
 #define __copy_from_guest(ptr, hnd, nr)                 \
     __copy_from_guest_offset(ptr, hnd, 0, nr)
 
+#define __clear_guest(hnd, nr)                          \
+    __clear_guest_offset(hnd, 0, nr)
+
 #endif /* __XEN_GUEST_ACCESS_H__ */
diff --git a/xen/include/xen/xencomm.h b/xen/include/xen/xencomm.h
index bce2ca7..730da7c 100644
--- a/xen/include/xen/xencomm.h
+++ b/xen/include/xen/xencomm.h
@@ -27,6 +27,8 @@ unsigned long xencomm_copy_to_guest(
     void *to, const void *from, unsigned int len, unsigned int skip); 
 unsigned long xencomm_copy_from_guest(
     void *to, const void *from, unsigned int len, unsigned int skip); 
+unsigned long xencomm_clear_guest(
+    void *to, unsigned int n, unsigned int skip);
 int xencomm_add_offset(void **handle, unsigned int bytes);
 int xencomm_handle_is_null(void *ptr);
 
@@ -41,6 +43,16 @@ static inline unsigned long xencomm_inline_addr(const void *handle)
     return (unsigned long)handle & ~XENCOMM_INLINE_FLAG;
 }
 
+#define raw_copy_to_guest(dst, src, len)       \
+    xencomm_copy_to_guest(dst, src, len, 0)
+#define raw_copy_from_guest(dst, src, len)     \
+    xencomm_copy_from_guest(dst, src, nr, 0)
+#define raw_clear_guest(dst, len)              \
+    xencomm_clear_guest(dst, len, 0)
+#define __raw_copy_to_guest raw_copy_to_guest
+#define __raw_copy_from_guest raw_copy_from_guest
+#define __raw_clear_guest raw_clear_guest
+
 /* Is the guest handle a NULL reference? */
 #define guest_handle_is_null(hnd) \
     ((hnd).p == NULL || xencomm_handle_is_null((hnd).p))
@@ -82,6 +94,13 @@ static inline unsigned long xencomm_inline_addr(const void *handle)
 #define copy_from_guest_offset(ptr, hnd, idx, nr) \
     __copy_from_guest_offset(ptr, hnd, idx, nr)
 
+/*
+ * Clear an array of objects in guest context via a guest handle.
+ * Optionally specify an offset into the guest array.
+ */
+#define clear_guest_offset(hnd, idx, nr) \
+    __clear_guest_offset(hnd, idx, nr)
+
 /* Copy sub-field of a structure from guest context via a guest handle. */
 #define copy_field_from_guest(ptr, hnd, field) \
     __copy_field_from_guest(ptr, hnd, field)
@@ -115,6 +134,11 @@ static inline unsigned long xencomm_inline_addr(const void *handle)
     xencomm_copy_from_guest(_d, _s, sizeof(*_d), _off);             \
 })
 
+#define __clear_guest_offset(hnd, idx, nr) ({                \
+    void *_d = (hnd).p;                                             \
+    xencomm_clear_guest(_d, nr, idx); \
+})
+
 #ifdef CONFIG_XENCOMM_MARK_DIRTY
 extern void xencomm_mark_dirty(unsigned long addr, unsigned int len);
 #else
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 16:29:06 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 16:29:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbEAw-0001nR-KA; Thu, 15 Dec 2011 16:28:54 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RbEAv-0001mG-31
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 16:28:53 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1323966525!7427055!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjE2NDg=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25820 invoked from network); 15 Dec 2011 16:28:46 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 16:28:46 -0000
X-IronPort-AV: E=Sophos;i="4.71,357,1320642000"; d="scan'208";a="174308087"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Dec 2011 11:28:45 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Thu, 15 Dec 2011 11:28:44 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pBFGSMtP003330;
	Thu, 15 Dec 2011 08:28:31 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Thu, 15 Dec 2011 16:30:33 +0000
Message-ID: <1323966657-19790-1-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1112131831560.3517@kaball-desktop>
References: <alpine.DEB.2.00.1112131831560.3517@kaball-desktop>
MIME-Version: 1.0
Cc: keir.xen@gmail.com, Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, JBeulich@suse.com,
	Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v3 01/25] Move cpufreq option parsing to
	cpufreq.c
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
---
 xen/common/domain.c           |   35 ++---------------------------------
 xen/drivers/cpufreq/cpufreq.c |   31 +++++++++++++++++++++++++++++++
 xen/include/xen/domain.h      |    2 ++
 3 files changed, 35 insertions(+), 33 deletions(-)

diff --git a/xen/common/domain.c b/xen/common/domain.c
index 9e355c8..6505572 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -31,8 +31,8 @@
 #include <xen/grant_table.h>
 #include <xen/xenoprof.h>
 #include <xen/irq.h>
-#include <acpi/cpufreq/cpufreq.h>
 #include <asm/debugger.h>
+#include <asm/processor.h>
 #include <public/sched.h>
 #include <public/sysctl.h>
 #include <public/vcpu.h>
@@ -45,40 +45,9 @@
 unsigned int xen_processor_pmbits = XEN_PROCESSOR_PM_PX;
 
 /* opt_dom0_vcpus_pin: If true, dom0 VCPUs are pinned. */
-static bool_t opt_dom0_vcpus_pin;
+bool_t opt_dom0_vcpus_pin;
 boolean_param("dom0_vcpus_pin", opt_dom0_vcpus_pin);
 
-/* set xen as default cpufreq */
-enum cpufreq_controller cpufreq_controller = FREQCTL_xen;
-
-static void __init setup_cpufreq_option(char *str)
-{
-    char *arg;
-
-    if ( !strcmp(str, "dom0-kernel") )
-    {
-        xen_processor_pmbits &= ~XEN_PROCESSOR_PM_PX;
-        cpufreq_controller = FREQCTL_dom0_kernel;
-        opt_dom0_vcpus_pin = 1;
-        return;
-    }
-
-    if ( !strcmp(str, "none") )
-    {
-        xen_processor_pmbits &= ~XEN_PROCESSOR_PM_PX;
-        cpufreq_controller = FREQCTL_none;
-        return;
-    }
-
-    if ( (arg = strpbrk(str, ",:")) != NULL )
-        *arg++ = '\0';
-
-    if ( !strcmp(str, "xen") )
-        if ( arg && *arg )
-            cpufreq_cmdline_parse(arg);
-}
-custom_param("cpufreq", setup_cpufreq_option);
-
 /* Protect updates/reads (resp.) of domain_list and domain_hash. */
 DEFINE_SPINLOCK(domlist_update_lock);
 DEFINE_RCU_READ_LOCK(domlist_read_lock);
diff --git a/xen/drivers/cpufreq/cpufreq.c b/xen/drivers/cpufreq/cpufreq.c
index f49ea1c..34ea2a9 100644
--- a/xen/drivers/cpufreq/cpufreq.c
+++ b/xen/drivers/cpufreq/cpufreq.c
@@ -61,6 +61,37 @@ static LIST_HEAD_READ_MOSTLY(cpufreq_dom_list_head);
 struct cpufreq_governor *__read_mostly cpufreq_opt_governor;
 LIST_HEAD_READ_MOSTLY(cpufreq_governor_list);
 
+/* set xen as default cpufreq */
+enum cpufreq_controller cpufreq_controller = FREQCTL_xen;
+
+static void __init setup_cpufreq_option(char *str)
+{
+    char *arg;
+
+    if ( !strcmp(str, "dom0-kernel") )
+    {
+        xen_processor_pmbits &= ~XEN_PROCESSOR_PM_PX;
+        cpufreq_controller = FREQCTL_dom0_kernel;
+        opt_dom0_vcpus_pin = 1;
+        return;
+    }
+
+    if ( !strcmp(str, "none") )
+    {
+        xen_processor_pmbits &= ~XEN_PROCESSOR_PM_PX;
+        cpufreq_controller = FREQCTL_none;
+        return;
+    }
+
+    if ( (arg = strpbrk(str, ",:")) != NULL )
+        *arg++ = '\0';
+
+    if ( !strcmp(str, "xen") )
+        if ( arg && *arg )
+            cpufreq_cmdline_parse(arg);
+}
+custom_param("cpufreq", setup_cpufreq_option);
+
 bool_t __read_mostly cpufreq_verbose;
 
 struct cpufreq_governor *__find_governor(const char *governor)
diff --git a/xen/include/xen/domain.h b/xen/include/xen/domain.h
index 765e132..de3e8db 100644
--- a/xen/include/xen/domain.h
+++ b/xen/include/xen/domain.h
@@ -85,4 +85,6 @@ int continue_hypercall_on_cpu(
 
 extern unsigned int xen_processor_pmbits;
 
+extern bool_t opt_dom0_vcpus_pin;
+
 #endif /* __XEN_DOMAIN_H__ */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 16:29:06 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 16:29:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbEAw-0001nR-KA; Thu, 15 Dec 2011 16:28:54 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RbEAv-0001mG-31
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 16:28:53 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1323966525!7427055!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjE2NDg=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25820 invoked from network); 15 Dec 2011 16:28:46 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 16:28:46 -0000
X-IronPort-AV: E=Sophos;i="4.71,357,1320642000"; d="scan'208";a="174308087"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Dec 2011 11:28:45 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Thu, 15 Dec 2011 11:28:44 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pBFGSMtP003330;
	Thu, 15 Dec 2011 08:28:31 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Thu, 15 Dec 2011 16:30:33 +0000
Message-ID: <1323966657-19790-1-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1112131831560.3517@kaball-desktop>
References: <alpine.DEB.2.00.1112131831560.3517@kaball-desktop>
MIME-Version: 1.0
Cc: keir.xen@gmail.com, Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, JBeulich@suse.com,
	Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v3 01/25] Move cpufreq option parsing to
	cpufreq.c
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
---
 xen/common/domain.c           |   35 ++---------------------------------
 xen/drivers/cpufreq/cpufreq.c |   31 +++++++++++++++++++++++++++++++
 xen/include/xen/domain.h      |    2 ++
 3 files changed, 35 insertions(+), 33 deletions(-)

diff --git a/xen/common/domain.c b/xen/common/domain.c
index 9e355c8..6505572 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -31,8 +31,8 @@
 #include <xen/grant_table.h>
 #include <xen/xenoprof.h>
 #include <xen/irq.h>
-#include <acpi/cpufreq/cpufreq.h>
 #include <asm/debugger.h>
+#include <asm/processor.h>
 #include <public/sched.h>
 #include <public/sysctl.h>
 #include <public/vcpu.h>
@@ -45,40 +45,9 @@
 unsigned int xen_processor_pmbits = XEN_PROCESSOR_PM_PX;
 
 /* opt_dom0_vcpus_pin: If true, dom0 VCPUs are pinned. */
-static bool_t opt_dom0_vcpus_pin;
+bool_t opt_dom0_vcpus_pin;
 boolean_param("dom0_vcpus_pin", opt_dom0_vcpus_pin);
 
-/* set xen as default cpufreq */
-enum cpufreq_controller cpufreq_controller = FREQCTL_xen;
-
-static void __init setup_cpufreq_option(char *str)
-{
-    char *arg;
-
-    if ( !strcmp(str, "dom0-kernel") )
-    {
-        xen_processor_pmbits &= ~XEN_PROCESSOR_PM_PX;
-        cpufreq_controller = FREQCTL_dom0_kernel;
-        opt_dom0_vcpus_pin = 1;
-        return;
-    }
-
-    if ( !strcmp(str, "none") )
-    {
-        xen_processor_pmbits &= ~XEN_PROCESSOR_PM_PX;
-        cpufreq_controller = FREQCTL_none;
-        return;
-    }
-
-    if ( (arg = strpbrk(str, ",:")) != NULL )
-        *arg++ = '\0';
-
-    if ( !strcmp(str, "xen") )
-        if ( arg && *arg )
-            cpufreq_cmdline_parse(arg);
-}
-custom_param("cpufreq", setup_cpufreq_option);
-
 /* Protect updates/reads (resp.) of domain_list and domain_hash. */
 DEFINE_SPINLOCK(domlist_update_lock);
 DEFINE_RCU_READ_LOCK(domlist_read_lock);
diff --git a/xen/drivers/cpufreq/cpufreq.c b/xen/drivers/cpufreq/cpufreq.c
index f49ea1c..34ea2a9 100644
--- a/xen/drivers/cpufreq/cpufreq.c
+++ b/xen/drivers/cpufreq/cpufreq.c
@@ -61,6 +61,37 @@ static LIST_HEAD_READ_MOSTLY(cpufreq_dom_list_head);
 struct cpufreq_governor *__read_mostly cpufreq_opt_governor;
 LIST_HEAD_READ_MOSTLY(cpufreq_governor_list);
 
+/* set xen as default cpufreq */
+enum cpufreq_controller cpufreq_controller = FREQCTL_xen;
+
+static void __init setup_cpufreq_option(char *str)
+{
+    char *arg;
+
+    if ( !strcmp(str, "dom0-kernel") )
+    {
+        xen_processor_pmbits &= ~XEN_PROCESSOR_PM_PX;
+        cpufreq_controller = FREQCTL_dom0_kernel;
+        opt_dom0_vcpus_pin = 1;
+        return;
+    }
+
+    if ( !strcmp(str, "none") )
+    {
+        xen_processor_pmbits &= ~XEN_PROCESSOR_PM_PX;
+        cpufreq_controller = FREQCTL_none;
+        return;
+    }
+
+    if ( (arg = strpbrk(str, ",:")) != NULL )
+        *arg++ = '\0';
+
+    if ( !strcmp(str, "xen") )
+        if ( arg && *arg )
+            cpufreq_cmdline_parse(arg);
+}
+custom_param("cpufreq", setup_cpufreq_option);
+
 bool_t __read_mostly cpufreq_verbose;
 
 struct cpufreq_governor *__find_governor(const char *governor)
diff --git a/xen/include/xen/domain.h b/xen/include/xen/domain.h
index 765e132..de3e8db 100644
--- a/xen/include/xen/domain.h
+++ b/xen/include/xen/domain.h
@@ -85,4 +85,6 @@ int continue_hypercall_on_cpu(
 
 extern unsigned int xen_processor_pmbits;
 
+extern bool_t opt_dom0_vcpus_pin;
+
 #endif /* __XEN_DOMAIN_H__ */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 16:29:06 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 16:29:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbEB0-0001ou-Ml; Thu, 15 Dec 2011 16:28:58 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RbEAz-0001mm-02
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 16:28:57 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1323966511!59095035!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDY5Mjg=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12844 invoked from network); 15 Dec 2011 16:28:32 -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;
	15 Dec 2011 16:28:32 -0000
X-IronPort-AV: E=Sophos;i="4.71,357,1320642000"; d="scan'208";a="20001830"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Dec 2011 11:28:49 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Thu, 15 Dec 2011 11:28:49 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pBFGSMtS003330;
	Thu, 15 Dec 2011 08:28:37 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Thu, 15 Dec 2011 16:30:36 +0000
Message-ID: <1323966657-19790-4-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1112131831560.3517@kaball-desktop>
References: <alpine.DEB.2.00.1112131831560.3517@kaball-desktop>
MIME-Version: 1.0
Cc: keir.xen@gmail.com, Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian.Campbell@citrix.com, JBeulich@suse.com, Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v3 04/25] xen: implement an signed 64 bit
	division helper function
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Implement a C function to perform 64 bit signed division and return both
quotient and remainder.
Useful as an helper function to implement __aeabi_ldivmod.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen/common/lib.c |   19 +++++++++++++++++++
 1 files changed, 19 insertions(+), 0 deletions(-)

diff --git a/xen/common/lib.c b/xen/common/lib.c
index 4ae637c..fe831a3 100644
--- a/xen/common/lib.c
+++ b/xen/common/lib.c
@@ -399,6 +399,25 @@ s64 __moddi3(s64 a, s64 b)
     return (neg ? -urem : urem);
 }
 
+/*
+ * Quotient and remainder of unsigned long long division
+ */
+s64 __ldivmod_helper(s64 a, s64 b, s64 *r)
+{
+    u64 ua, ub, rem, quot;
+
+    ua = (a < 0) ? -(u64)a : a;
+    ub = (b < 0) ? -(u64)b : b;
+    quot = __qdivrem(ua, ub, &rem);
+    if ( a < 0 )
+        *r = -rem;
+    else
+        *r = rem;
+    if ( (a < 0) ^ (b < 0) )
+        return -quot;
+    else
+        return quot;
+}
 #endif /* BITS_PER_LONG == 32 */
 
 /* Compute with 96 bit intermediate result: (a*b)/c */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 16:29:06 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 16:29:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbEB0-0001ou-Ml; Thu, 15 Dec 2011 16:28:58 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RbEAz-0001mm-02
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 16:28:57 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1323966511!59095035!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDY5Mjg=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12844 invoked from network); 15 Dec 2011 16:28:32 -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;
	15 Dec 2011 16:28:32 -0000
X-IronPort-AV: E=Sophos;i="4.71,357,1320642000"; d="scan'208";a="20001830"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Dec 2011 11:28:49 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Thu, 15 Dec 2011 11:28:49 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pBFGSMtS003330;
	Thu, 15 Dec 2011 08:28:37 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Thu, 15 Dec 2011 16:30:36 +0000
Message-ID: <1323966657-19790-4-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1112131831560.3517@kaball-desktop>
References: <alpine.DEB.2.00.1112131831560.3517@kaball-desktop>
MIME-Version: 1.0
Cc: keir.xen@gmail.com, Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian.Campbell@citrix.com, JBeulich@suse.com, Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v3 04/25] xen: implement an signed 64 bit
	division helper function
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Implement a C function to perform 64 bit signed division and return both
quotient and remainder.
Useful as an helper function to implement __aeabi_ldivmod.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen/common/lib.c |   19 +++++++++++++++++++
 1 files changed, 19 insertions(+), 0 deletions(-)

diff --git a/xen/common/lib.c b/xen/common/lib.c
index 4ae637c..fe831a3 100644
--- a/xen/common/lib.c
+++ b/xen/common/lib.c
@@ -399,6 +399,25 @@ s64 __moddi3(s64 a, s64 b)
     return (neg ? -urem : urem);
 }
 
+/*
+ * Quotient and remainder of unsigned long long division
+ */
+s64 __ldivmod_helper(s64 a, s64 b, s64 *r)
+{
+    u64 ua, ub, rem, quot;
+
+    ua = (a < 0) ? -(u64)a : a;
+    ub = (b < 0) ? -(u64)b : b;
+    quot = __qdivrem(ua, ub, &rem);
+    if ( a < 0 )
+        *r = -rem;
+    else
+        *r = rem;
+    if ( (a < 0) ^ (b < 0) )
+        return -quot;
+    else
+        return quot;
+}
 #endif /* BITS_PER_LONG == 32 */
 
 /* Compute with 96 bit intermediate result: (a*b)/c */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 16:29:08 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 16:29:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbEB3-0001pz-5M; Thu, 15 Dec 2011 16:29:01 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RbEB2-0001nY-5r
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 16:29:00 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1323966511!59095035!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDY5Mjg=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13042 invoked from network); 15 Dec 2011 16:28:35 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 16:28:35 -0000
X-IronPort-AV: E=Sophos;i="4.71,357,1320642000"; d="scan'208";a="20001833"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Dec 2011 11:28:53 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Thu, 15 Dec 2011 11:28:52 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pBFGSMtR003330;
	Thu, 15 Dec 2011 08:28:35 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Thu, 15 Dec 2011 16:30:35 +0000
Message-ID: <1323966657-19790-3-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1112131831560.3517@kaball-desktop>
References: <alpine.DEB.2.00.1112131831560.3517@kaball-desktop>
MIME-Version: 1.0
Cc: keir.xen@gmail.com, Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, JBeulich@suse.com,
	Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v3 03/25] A collection of fixes to Xen common
	files
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

- call free_xenoprof_pages only ifdef CONFIG_XENOPROF;

- define PRI_stime as PRId64 in an header file;

- respect boundaries in is_kernel_*;

- implement is_kernel_rodata.


Changes in v2:

- introduce CONFIG_XENOPROF;

- define _srodata and _erodata as const char*.


Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
---
 xen/common/domain.c           |    2 ++
 xen/common/sched_credit2.c    |    6 ------
 xen/include/asm-ia64/config.h |    1 +
 xen/include/asm-x86/config.h  |    2 ++
 xen/include/xen/kernel.h      |   12 +++++++++---
 xen/include/xen/time.h        |    1 +
 6 files changed, 15 insertions(+), 9 deletions(-)

diff --git a/xen/common/domain.c b/xen/common/domain.c
index 6505572..e5dc88f 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -630,7 +630,9 @@ static void complete_domain_destroy(struct rcu_head *head)
     sched_destroy_domain(d);
 
     /* Free page used by xen oprofile buffer. */
+#ifdef CONFIG_XENOPROF
     free_xenoprof_pages(d);
+#endif
 
     for ( i = d->max_vcpus - 1; i >= 0; i-- )
         if ( (v = d->vcpu[i]) != NULL )
diff --git a/xen/common/sched_credit2.c b/xen/common/sched_credit2.c
index 86c4439..73f7138 100644
--- a/xen/common/sched_credit2.c
+++ b/xen/common/sched_credit2.c
@@ -26,12 +26,6 @@
 #include <xen/trace.h>
 #include <xen/cpu.h>
 
-#if __i386__
-#define PRI_stime "lld"
-#else
-#define PRI_stime "ld"
-#endif
-
 #define d2printk(x...)
 //#define d2printk printk
 
diff --git a/xen/include/asm-ia64/config.h b/xen/include/asm-ia64/config.h
index be94b48..0173487 100644
--- a/xen/include/asm-ia64/config.h
+++ b/xen/include/asm-ia64/config.h
@@ -20,6 +20,7 @@
 #define CONFIG_EFI
 #define CONFIG_EFI_PCDP
 #define CONFIG_SERIAL_SGI_L1_CONSOLE
+#define CONFIG_XENOPROF 1
 
 #define CONFIG_XEN_SMP
 
diff --git a/xen/include/asm-x86/config.h b/xen/include/asm-x86/config.h
index 40a7b8c..905c0f8 100644
--- a/xen/include/asm-x86/config.h
+++ b/xen/include/asm-x86/config.h
@@ -43,6 +43,8 @@
 #define CONFIG_HOTPLUG 1
 #define CONFIG_HOTPLUG_CPU 1
 
+#define CONFIG_XENOPROF 1
+
 #define HZ 100
 
 #define OPT_CONSOLE_STR "vga"
diff --git a/xen/include/xen/kernel.h b/xen/include/xen/kernel.h
index fd03f74..92de428 100644
--- a/xen/include/xen/kernel.h
+++ b/xen/include/xen/kernel.h
@@ -66,19 +66,25 @@
 extern char _start[], _end[];
 #define is_kernel(p) ({                         \
     char *__p = (char *)(unsigned long)(p);     \
-    (__p >= _start) && (__p <= _end);           \
+    (__p >= _start) && (__p < _end);            \
 })
 
 extern char _stext[], _etext[];
 #define is_kernel_text(p) ({                    \
     char *__p = (char *)(unsigned long)(p);     \
-    (__p >= _stext) && (__p <= _etext);         \
+    (__p >= _stext) && (__p < _etext);          \
+})
+
+extern const char _srodata[], _erodata[];
+#define is_kernel_rodata(p) ({                  \
+    const char *__p = (const char *)(unsigned long)(p);     \
+    (__p >= _srodata) && (__p < _erodata);      \
 })
 
 extern char _sinittext[], _einittext[];
 #define is_kernel_inittext(p) ({                \
     char *__p = (char *)(unsigned long)(p);     \
-    (__p >= _sinittext) && (__p <= _einittext); \
+    (__p >= _sinittext) && (__p < _einittext);  \
 })
 
 #endif /* _LINUX_KERNEL_H */
diff --git a/xen/include/xen/time.h b/xen/include/xen/time.h
index a194340..31c9ce5 100644
--- a/xen/include/xen/time.h
+++ b/xen/include/xen/time.h
@@ -30,6 +30,7 @@ struct vcpu;
  */
 
 typedef s64 s_time_t;
+#define PRI_stime PRId64
 
 s_time_t get_s_time(void);
 unsigned long get_localtime(struct domain *d);
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 16:29:08 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 16:29:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbEB3-0001pz-5M; Thu, 15 Dec 2011 16:29:01 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RbEB2-0001nY-5r
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 16:29:00 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1323966511!59095035!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDY5Mjg=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13042 invoked from network); 15 Dec 2011 16:28:35 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 16:28:35 -0000
X-IronPort-AV: E=Sophos;i="4.71,357,1320642000"; d="scan'208";a="20001833"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Dec 2011 11:28:53 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Thu, 15 Dec 2011 11:28:52 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pBFGSMtR003330;
	Thu, 15 Dec 2011 08:28:35 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Thu, 15 Dec 2011 16:30:35 +0000
Message-ID: <1323966657-19790-3-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1112131831560.3517@kaball-desktop>
References: <alpine.DEB.2.00.1112131831560.3517@kaball-desktop>
MIME-Version: 1.0
Cc: keir.xen@gmail.com, Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, JBeulich@suse.com,
	Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v3 03/25] A collection of fixes to Xen common
	files
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

- call free_xenoprof_pages only ifdef CONFIG_XENOPROF;

- define PRI_stime as PRId64 in an header file;

- respect boundaries in is_kernel_*;

- implement is_kernel_rodata.


Changes in v2:

- introduce CONFIG_XENOPROF;

- define _srodata and _erodata as const char*.


Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
---
 xen/common/domain.c           |    2 ++
 xen/common/sched_credit2.c    |    6 ------
 xen/include/asm-ia64/config.h |    1 +
 xen/include/asm-x86/config.h  |    2 ++
 xen/include/xen/kernel.h      |   12 +++++++++---
 xen/include/xen/time.h        |    1 +
 6 files changed, 15 insertions(+), 9 deletions(-)

diff --git a/xen/common/domain.c b/xen/common/domain.c
index 6505572..e5dc88f 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -630,7 +630,9 @@ static void complete_domain_destroy(struct rcu_head *head)
     sched_destroy_domain(d);
 
     /* Free page used by xen oprofile buffer. */
+#ifdef CONFIG_XENOPROF
     free_xenoprof_pages(d);
+#endif
 
     for ( i = d->max_vcpus - 1; i >= 0; i-- )
         if ( (v = d->vcpu[i]) != NULL )
diff --git a/xen/common/sched_credit2.c b/xen/common/sched_credit2.c
index 86c4439..73f7138 100644
--- a/xen/common/sched_credit2.c
+++ b/xen/common/sched_credit2.c
@@ -26,12 +26,6 @@
 #include <xen/trace.h>
 #include <xen/cpu.h>
 
-#if __i386__
-#define PRI_stime "lld"
-#else
-#define PRI_stime "ld"
-#endif
-
 #define d2printk(x...)
 //#define d2printk printk
 
diff --git a/xen/include/asm-ia64/config.h b/xen/include/asm-ia64/config.h
index be94b48..0173487 100644
--- a/xen/include/asm-ia64/config.h
+++ b/xen/include/asm-ia64/config.h
@@ -20,6 +20,7 @@
 #define CONFIG_EFI
 #define CONFIG_EFI_PCDP
 #define CONFIG_SERIAL_SGI_L1_CONSOLE
+#define CONFIG_XENOPROF 1
 
 #define CONFIG_XEN_SMP
 
diff --git a/xen/include/asm-x86/config.h b/xen/include/asm-x86/config.h
index 40a7b8c..905c0f8 100644
--- a/xen/include/asm-x86/config.h
+++ b/xen/include/asm-x86/config.h
@@ -43,6 +43,8 @@
 #define CONFIG_HOTPLUG 1
 #define CONFIG_HOTPLUG_CPU 1
 
+#define CONFIG_XENOPROF 1
+
 #define HZ 100
 
 #define OPT_CONSOLE_STR "vga"
diff --git a/xen/include/xen/kernel.h b/xen/include/xen/kernel.h
index fd03f74..92de428 100644
--- a/xen/include/xen/kernel.h
+++ b/xen/include/xen/kernel.h
@@ -66,19 +66,25 @@
 extern char _start[], _end[];
 #define is_kernel(p) ({                         \
     char *__p = (char *)(unsigned long)(p);     \
-    (__p >= _start) && (__p <= _end);           \
+    (__p >= _start) && (__p < _end);            \
 })
 
 extern char _stext[], _etext[];
 #define is_kernel_text(p) ({                    \
     char *__p = (char *)(unsigned long)(p);     \
-    (__p >= _stext) && (__p <= _etext);         \
+    (__p >= _stext) && (__p < _etext);          \
+})
+
+extern const char _srodata[], _erodata[];
+#define is_kernel_rodata(p) ({                  \
+    const char *__p = (const char *)(unsigned long)(p);     \
+    (__p >= _srodata) && (__p < _erodata);      \
 })
 
 extern char _sinittext[], _einittext[];
 #define is_kernel_inittext(p) ({                \
     char *__p = (char *)(unsigned long)(p);     \
-    (__p >= _sinittext) && (__p <= _einittext); \
+    (__p >= _sinittext) && (__p < _einittext);  \
 })
 
 #endif /* _LINUX_KERNEL_H */
diff --git a/xen/include/xen/time.h b/xen/include/xen/time.h
index a194340..31c9ce5 100644
--- a/xen/include/xen/time.h
+++ b/xen/include/xen/time.h
@@ -30,6 +30,7 @@ struct vcpu;
  */
 
 typedef s64 s_time_t;
+#define PRI_stime PRId64
 
 s_time_t get_s_time(void);
 unsigned long get_localtime(struct domain *d);
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 16:29:10 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 16:29:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbEB5-0001rU-S0; Thu, 15 Dec 2011 16:29:03 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RbEB3-0001o6-7g
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 16:29:01 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1323966533!7554554!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjE2NDg=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19251 invoked from network); 15 Dec 2011 16:28:55 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 16:28:55 -0000
X-IronPort-AV: E=Sophos;i="4.71,357,1320642000"; d="scan'208";a="174308130"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Dec 2011 11:28:52 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Thu, 15 Dec 2011 11:28:52 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pBFGSMtU003330;
	Thu, 15 Dec 2011 08:28:40 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Thu, 15 Dec 2011 16:30:38 +0000
Message-ID: <1323966657-19790-6-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1112131831560.3517@kaball-desktop>
References: <alpine.DEB.2.00.1112131831560.3517@kaball-desktop>
MIME-Version: 1.0
Cc: keir.xen@gmail.com, Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, JBeulich@suse.com,
	Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v3 06/25] libelf-loader: introduce elf_load_image
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Implement a new function, called elf_load_image, to perform the actually
copy of the elf image and clearing the padding.
The function is implemented as memcpy and memset when the library is
built as part of the tools, but it is implemented as raw_copy_to_guest and
raw_clear_guest when built as part of Xen, so that it can be safely called
with an HVM style dom0.


Changes in v3:

- switch to raw_copy_to_guest and raw_clear_guest.


Changes in v2:

- remove CONFIG_KERNEL_NO_RELOC.


Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
---
 xen/common/libelf/libelf-loader.c |   17 +++++++++++++++--
 1 files changed, 15 insertions(+), 2 deletions(-)

diff --git a/xen/common/libelf/libelf-loader.c b/xen/common/libelf/libelf-loader.c
index 1ccf7d3..d2cb5b3 100644
--- a/xen/common/libelf/libelf-loader.c
+++ b/xen/common/libelf/libelf-loader.c
@@ -107,11 +107,25 @@ void elf_set_log(struct elf_binary *elf, elf_log_callback *log_callback,
     elf->log_caller_data = log_caller_data;
     elf->verbose = verbose;
 }
+
+static void elf_load_image(void *dst, const void *src, uint64_t filesz, uint64_t memsz)
+{
+    memcpy(dst, src, filesz);
+    memset(dst + filesz, 0, memsz - filesz);
+}
 #else
+#include <asm/guest_access.h>
+
 void elf_set_verbose(struct elf_binary *elf)
 {
     elf->verbose = 1;
 }
+
+static void elf_load_image(void *dst, const void *src, uint64_t filesz, uint64_t memsz)
+{
+    raw_copy_to_guest(dst, src, filesz);
+    raw_clear_guest(dst + filesz, memsz - filesz);
+}
 #endif
 
 /* Calculate the required additional kernel space for the elf image */
@@ -256,8 +270,7 @@ void elf_load_binary(struct elf_binary *elf)
         dest = elf_get_ptr(elf, paddr);
         elf_msg(elf, "%s: phdr %" PRIu64 " at 0x%p -> 0x%p\n",
                 __func__, i, dest, dest + filesz);
-        memcpy(dest, elf->image + offset, filesz);
-        memset(dest + filesz, 0, memsz - filesz);
+        elf_load_image(dest, elf->image + offset, filesz, memsz);
     }
 
     elf_load_bsdsyms(elf);
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 16:29:10 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 16:29:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbEB5-0001rU-S0; Thu, 15 Dec 2011 16:29:03 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RbEB3-0001o6-7g
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 16:29:01 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1323966533!7554554!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjE2NDg=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19251 invoked from network); 15 Dec 2011 16:28:55 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 16:28:55 -0000
X-IronPort-AV: E=Sophos;i="4.71,357,1320642000"; d="scan'208";a="174308130"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Dec 2011 11:28:52 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Thu, 15 Dec 2011 11:28:52 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pBFGSMtU003330;
	Thu, 15 Dec 2011 08:28:40 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Thu, 15 Dec 2011 16:30:38 +0000
Message-ID: <1323966657-19790-6-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1112131831560.3517@kaball-desktop>
References: <alpine.DEB.2.00.1112131831560.3517@kaball-desktop>
MIME-Version: 1.0
Cc: keir.xen@gmail.com, Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, JBeulich@suse.com,
	Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v3 06/25] libelf-loader: introduce elf_load_image
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Implement a new function, called elf_load_image, to perform the actually
copy of the elf image and clearing the padding.
The function is implemented as memcpy and memset when the library is
built as part of the tools, but it is implemented as raw_copy_to_guest and
raw_clear_guest when built as part of Xen, so that it can be safely called
with an HVM style dom0.


Changes in v3:

- switch to raw_copy_to_guest and raw_clear_guest.


Changes in v2:

- remove CONFIG_KERNEL_NO_RELOC.


Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
---
 xen/common/libelf/libelf-loader.c |   17 +++++++++++++++--
 1 files changed, 15 insertions(+), 2 deletions(-)

diff --git a/xen/common/libelf/libelf-loader.c b/xen/common/libelf/libelf-loader.c
index 1ccf7d3..d2cb5b3 100644
--- a/xen/common/libelf/libelf-loader.c
+++ b/xen/common/libelf/libelf-loader.c
@@ -107,11 +107,25 @@ void elf_set_log(struct elf_binary *elf, elf_log_callback *log_callback,
     elf->log_caller_data = log_caller_data;
     elf->verbose = verbose;
 }
+
+static void elf_load_image(void *dst, const void *src, uint64_t filesz, uint64_t memsz)
+{
+    memcpy(dst, src, filesz);
+    memset(dst + filesz, 0, memsz - filesz);
+}
 #else
+#include <asm/guest_access.h>
+
 void elf_set_verbose(struct elf_binary *elf)
 {
     elf->verbose = 1;
 }
+
+static void elf_load_image(void *dst, const void *src, uint64_t filesz, uint64_t memsz)
+{
+    raw_copy_to_guest(dst, src, filesz);
+    raw_clear_guest(dst + filesz, memsz - filesz);
+}
 #endif
 
 /* Calculate the required additional kernel space for the elf image */
@@ -256,8 +270,7 @@ void elf_load_binary(struct elf_binary *elf)
         dest = elf_get_ptr(elf, paddr);
         elf_msg(elf, "%s: phdr %" PRIu64 " at 0x%p -> 0x%p\n",
                 __func__, i, dest, dest + filesz);
-        memcpy(dest, elf->image + offset, filesz);
-        memset(dest + filesz, 0, memsz - filesz);
+        elf_load_image(dest, elf->image + offset, filesz, memsz);
     }
 
     elf_load_bsdsyms(elf);
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 16:29:10 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 16:29:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbEB5-0001rD-Ey; Thu, 15 Dec 2011 16:29:03 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RbEB3-0001on-MF
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 16:29:01 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1323966511!59095035!4
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDY5Mjg=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13231 invoked from network); 15 Dec 2011 16:28:38 -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;
	15 Dec 2011 16:28:38 -0000
X-IronPort-AV: E=Sophos;i="4.71,357,1320642000"; d="scan'208";a="20001837"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Dec 2011 11:28:57 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Thu, 15 Dec 2011 11:28:56 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pBFGSMtW003330;
	Thu, 15 Dec 2011 08:28:44 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Thu, 15 Dec 2011 16:30:40 +0000
Message-ID: <1323966657-19790-8-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1112131831560.3517@kaball-desktop>
References: <alpine.DEB.2.00.1112131831560.3517@kaball-desktop>
MIME-Version: 1.0
Cc: keir.xen@gmail.com, Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian.Campbell@citrix.com, JBeulich@suse.com, Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v3 08/25] arm: compile tmem
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Include few missing header files; fix the definition of cli_put_page;
introduce defined(CONFIG_ARM) where required.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen/common/tmem.c     |    3 ++-
 xen/common/tmem_xen.c |    6 ++++--
 2 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/xen/common/tmem.c b/xen/common/tmem.c
index 115465b..dd276df 100644
--- a/xen/common/tmem.c
+++ b/xen/common/tmem.c
@@ -22,6 +22,7 @@
 #include <xen/rbtree.h>
 #include <xen/radix-tree.h>
 #include <xen/list.h>
+#include <xen/init.h>
 
 #define EXPORT /* indicates code other modules are dependent upon */
 #define FORWARD
@@ -49,7 +50,7 @@
 #define INVERT_SENTINEL(_x,_y) _x->sentinel = ~_y##_SENTINEL
 #define ASSERT_SENTINEL(_x,_y) \
     ASSERT(_x->sentinel != ~_y##_SENTINEL);ASSERT(_x->sentinel == _y##_SENTINEL)
-#ifdef __i386__
+#if defined(__i386__) || defined(CONFIG_ARM)
 #define POOL_SENTINEL 0x87658765
 #define OBJ_SENTINEL 0x12345678
 #define OBJNODE_SENTINEL 0xfedcba09
diff --git a/xen/common/tmem_xen.c b/xen/common/tmem_xen.c
index c094095..9b2a22c 100644
--- a/xen/common/tmem_xen.c
+++ b/xen/common/tmem_xen.c
@@ -12,6 +12,8 @@
 #include <xen/paging.h>
 #include <xen/domain_page.h>
 #include <xen/cpu.h>
+#include <xen/init.h>
+#include <asm/p2m.h>
 
 #define EXPORT /* indicates code other modules are dependent upon */
 
@@ -87,7 +89,7 @@ void tmh_copy_page(char *to, char*from)
 #endif
 }
 
-#ifdef __ia64__
+#if defined(__ia64__) || defined (CONFIG_ARM)
 static inline void *cli_get_page(tmem_cli_mfn_t cmfn, unsigned long *pcli_mfn,
                                  pfp_t **pcli_pfp, bool_t cli_write)
 {
@@ -95,7 +97,7 @@ static inline void *cli_get_page(tmem_cli_mfn_t cmfn, unsigned long *pcli_mfn,
     return NULL;
 }
 
-static inline void cli_put_page(void *cli_va, pfp_t *cli_pfp,
+static inline void cli_put_page(tmem_cli_mfn_t cmfn, void *cli_va, pfp_t *cli_pfp,
                                 unsigned long cli_mfn, bool_t mark_dirty)
 {
     ASSERT(0);
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 16:29:10 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 16:29:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbEB5-0001rD-Ey; Thu, 15 Dec 2011 16:29:03 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RbEB3-0001on-MF
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 16:29:01 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1323966511!59095035!4
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDY5Mjg=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13231 invoked from network); 15 Dec 2011 16:28:38 -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;
	15 Dec 2011 16:28:38 -0000
X-IronPort-AV: E=Sophos;i="4.71,357,1320642000"; d="scan'208";a="20001837"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Dec 2011 11:28:57 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Thu, 15 Dec 2011 11:28:56 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pBFGSMtW003330;
	Thu, 15 Dec 2011 08:28:44 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Thu, 15 Dec 2011 16:30:40 +0000
Message-ID: <1323966657-19790-8-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1112131831560.3517@kaball-desktop>
References: <alpine.DEB.2.00.1112131831560.3517@kaball-desktop>
MIME-Version: 1.0
Cc: keir.xen@gmail.com, Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian.Campbell@citrix.com, JBeulich@suse.com, Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v3 08/25] arm: compile tmem
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Include few missing header files; fix the definition of cli_put_page;
introduce defined(CONFIG_ARM) where required.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen/common/tmem.c     |    3 ++-
 xen/common/tmem_xen.c |    6 ++++--
 2 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/xen/common/tmem.c b/xen/common/tmem.c
index 115465b..dd276df 100644
--- a/xen/common/tmem.c
+++ b/xen/common/tmem.c
@@ -22,6 +22,7 @@
 #include <xen/rbtree.h>
 #include <xen/radix-tree.h>
 #include <xen/list.h>
+#include <xen/init.h>
 
 #define EXPORT /* indicates code other modules are dependent upon */
 #define FORWARD
@@ -49,7 +50,7 @@
 #define INVERT_SENTINEL(_x,_y) _x->sentinel = ~_y##_SENTINEL
 #define ASSERT_SENTINEL(_x,_y) \
     ASSERT(_x->sentinel != ~_y##_SENTINEL);ASSERT(_x->sentinel == _y##_SENTINEL)
-#ifdef __i386__
+#if defined(__i386__) || defined(CONFIG_ARM)
 #define POOL_SENTINEL 0x87658765
 #define OBJ_SENTINEL 0x12345678
 #define OBJNODE_SENTINEL 0xfedcba09
diff --git a/xen/common/tmem_xen.c b/xen/common/tmem_xen.c
index c094095..9b2a22c 100644
--- a/xen/common/tmem_xen.c
+++ b/xen/common/tmem_xen.c
@@ -12,6 +12,8 @@
 #include <xen/paging.h>
 #include <xen/domain_page.h>
 #include <xen/cpu.h>
+#include <xen/init.h>
+#include <asm/p2m.h>
 
 #define EXPORT /* indicates code other modules are dependent upon */
 
@@ -87,7 +89,7 @@ void tmh_copy_page(char *to, char*from)
 #endif
 }
 
-#ifdef __ia64__
+#if defined(__ia64__) || defined (CONFIG_ARM)
 static inline void *cli_get_page(tmem_cli_mfn_t cmfn, unsigned long *pcli_mfn,
                                  pfp_t **pcli_pfp, bool_t cli_write)
 {
@@ -95,7 +97,7 @@ static inline void *cli_get_page(tmem_cli_mfn_t cmfn, unsigned long *pcli_mfn,
     return NULL;
 }
 
-static inline void cli_put_page(void *cli_va, pfp_t *cli_pfp,
+static inline void cli_put_page(tmem_cli_mfn_t cmfn, void *cli_va, pfp_t *cli_pfp,
                                 unsigned long cli_mfn, bool_t mark_dirty)
 {
     ASSERT(0);
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 16:29:10 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 16:29:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbEB8-0001tu-Nq; Thu, 15 Dec 2011 16:29:06 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RbEB7-0001sO-77
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 16:29:05 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1323966511!59095035!6
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDY5Mjg=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13631 invoked from network); 15 Dec 2011 16:28:45 -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;
	15 Dec 2011 16:28:45 -0000
X-IronPort-AV: E=Sophos;i="4.71,357,1320642000"; d="scan'208";a="20001851"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Dec 2011 11:29:03 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Thu, 15 Dec 2011 11:29:03 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pBFGSMta003330;
	Thu, 15 Dec 2011 08:28:51 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Thu, 15 Dec 2011 16:30:44 +0000
Message-ID: <1323966657-19790-12-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1112131831560.3517@kaball-desktop>
References: <alpine.DEB.2.00.1112131831560.3517@kaball-desktop>
MIME-Version: 1.0
Cc: keir.xen@gmail.com, Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, JBeulich@suse.com,
	Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v3 12/25] arm: domain
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Domain creation and destruction, vcpu initialization and destruction,
arch specific scheduling functions called by common code.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
---
 xen/arch/arm/domain.c        |  253 ++++++++++++++++++++++++++++++++++++++++++
 xen/include/asm-arm/domain.h |   43 +++++++
 2 files changed, 296 insertions(+), 0 deletions(-)
 create mode 100644 xen/arch/arm/domain.c
 create mode 100644 xen/include/asm-arm/domain.h

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
new file mode 100644
index 0000000..d706b5f
--- /dev/null
+++ b/xen/arch/arm/domain.c
@@ -0,0 +1,253 @@
+#include <xen/config.h>
+#include <xen/init.h>
+#include <xen/lib.h>
+#include <xen/sched.h>
+#include <xen/softirq.h>
+#include <xen/wait.h>
+#include <xen/errno.h>
+
+#include <asm/current.h>
+#include <asm/regs.h>
+#include <asm/p2m.h>
+#include <asm/irq.h>
+
+DEFINE_PER_CPU(struct vcpu *, curr_vcpu);
+
+static void continue_idle_domain(struct vcpu *v)
+{
+    reset_stack_and_jump(idle_loop);
+}
+
+static void continue_nonidle_domain(struct vcpu *v)
+{
+    /* check_wakeup_from_wait(); */
+    reset_stack_and_jump(return_from_trap);
+}
+
+void idle_loop(void)
+{
+    for ( ; ; )
+    {
+		/* TODO
+		   if ( cpu_is_offline(smp_processor_id()) )
+		   play_dead();
+		   (*pm_idle)();
+		   BUG();
+		*/
+        do_tasklet();
+        do_softirq();
+    }
+}
+
+static void ctxt_switch_from(struct vcpu *p)
+{
+
+}
+
+static void ctxt_switch_to(struct vcpu *n)
+{
+    p2m_load_VTTBR(n->domain);
+}
+
+static void __context_switch(void)
+{
+    struct cpu_user_regs *stack_regs = guest_cpu_user_regs();
+    unsigned int          cpu = smp_processor_id();
+    struct vcpu          *p = per_cpu(curr_vcpu, cpu);
+    struct vcpu          *n = current;
+
+    ASSERT(p != n);
+    ASSERT(cpumask_empty(n->vcpu_dirty_cpumask));
+
+    if ( !is_idle_vcpu(p) )
+    {
+        memcpy(&p->arch.user_regs, stack_regs, CTXT_SWITCH_STACK_BYTES);
+        ctxt_switch_from(p);
+    }
+
+    if ( !is_idle_vcpu(n) )
+    {
+        memcpy(stack_regs, &n->arch.user_regs, CTXT_SWITCH_STACK_BYTES);
+        ctxt_switch_to(n);
+    }
+
+    per_cpu(curr_vcpu, cpu) = n;
+
+}
+
+static void schedule_tail(struct vcpu *v)
+{
+    if ( is_idle_vcpu(v) )
+        continue_idle_domain(v);
+    else
+        continue_nonidle_domain(v);
+}
+
+void context_switch(struct vcpu *prev, struct vcpu *next)
+{
+    unsigned int cpu = smp_processor_id();
+
+    ASSERT(local_irq_is_enabled());
+
+    printk("context switch %d:%d%s -> %d:%d%s\n",
+           prev->domain->domain_id, prev->vcpu_id, is_idle_vcpu(prev) ? " (idle)" : "",
+           next->domain->domain_id, next->vcpu_id, is_idle_vcpu(next) ? " (idle)" : "");
+
+	/* TODO
+	   if (prev != next)
+	   update_runstate_area(prev);
+	*/
+
+    local_irq_disable();
+
+    set_current(next);
+
+    if ( (per_cpu(curr_vcpu, cpu) == next) ||
+         (is_idle_vcpu(next) && cpu_online(cpu)) )
+    {
+        local_irq_enable();
+    }
+    else
+    {
+        __context_switch();
+
+        /* Re-enable interrupts before restoring state which may fault. */
+        local_irq_enable();
+    }
+
+    context_saved(prev);
+
+	/* TODO
+	   if (prev != next)
+	   update_runstate_area(next);
+	*/
+
+    schedule_tail(next);
+    BUG();
+
+}
+
+void continue_running(struct vcpu *same)
+{
+    schedule_tail(same);
+    BUG();
+}
+
+int __sync_local_execstate(void)
+{
+    unsigned long flags;
+    int switch_required;
+
+    local_irq_save(flags);
+
+    switch_required = (this_cpu(curr_vcpu) != current);
+
+    if ( switch_required )
+    {
+        ASSERT(current == idle_vcpu[smp_processor_id()]);
+        __context_switch();
+    }
+
+    local_irq_restore(flags);
+
+    return switch_required;
+}
+
+void sync_local_execstate(void)
+{
+    (void)__sync_local_execstate();
+}
+
+void startup_cpu_idle_loop(void)
+{
+        struct vcpu *v = current;
+
+        ASSERT(is_idle_vcpu(v));
+		/* TODO
+		   cpumask_set_cpu(v->processor, v->domain->domain_dirty_cpumask);
+		   cpumask_set_cpu(v->processor, v->vcpu_dirty_cpumask);
+		*/
+
+        reset_stack_and_jump(idle_loop);
+}
+
+struct domain *alloc_domain_struct(void)
+{
+    struct domain *d;
+    BUILD_BUG_ON(sizeof(*d) > PAGE_SIZE);
+    d = alloc_xenheap_pages(0, 0);
+    if ( d != NULL )
+        clear_page(d);
+    return d;
+}
+
+void free_domain_struct(struct domain *d)
+{
+    free_xenheap_page(d);
+}
+
+void dump_pageframe_info(struct domain *d)
+{
+
+}
+
+struct vcpu *alloc_vcpu_struct(void)
+{
+    struct vcpu *v;
+    BUILD_BUG_ON(sizeof(*v) > PAGE_SIZE);
+    v = alloc_xenheap_pages(0, 0);
+    if ( v != NULL )
+        clear_page(v);
+    return v;
+}
+
+void free_vcpu_struct(struct vcpu *v)
+{
+    free_xenheap_page(v);
+}
+
+int vcpu_initialise(struct vcpu *v)
+{
+    int rc = 0;
+
+    return rc;
+}
+
+void vcpu_destroy(struct vcpu *v)
+{
+
+}
+
+int arch_domain_create(struct domain *d, unsigned int domcr_flags)
+{
+    int rc;
+
+    d->max_vcpus = 8;
+
+    rc = 0;
+fail:
+    return rc;
+}
+
+void arch_domain_destroy(struct domain *d)
+{
+    /* p2m_destroy */
+    /* domain_vgic_destroy */
+}
+
+void arch_dump_domain_info(struct domain *d)
+{
+}
+
+void arch_dump_vcpu_info(struct vcpu *v)
+{
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
new file mode 100644
index 0000000..c226bdf
--- /dev/null
+++ b/xen/include/asm-arm/domain.h
@@ -0,0 +1,43 @@
+#ifndef __ASM_DOMAIN_H__
+#define __ASM_DOMAIN_H__
+
+#include <xen/config.h>
+#include <xen/cache.h>
+#include <asm/page.h>
+#include <asm/p2m.h>
+
+struct pending_irq
+{
+    int irq;
+    struct irq_desc *desc; /* only set it the irq corresponds to a physical irq */
+    uint8_t priority;
+    struct list_head link;
+};
+
+struct arch_domain
+{
+}  __cacheline_aligned;
+
+struct arch_vcpu
+{
+    struct cpu_user_regs user_regs;
+
+    uint32_t sctlr;
+    uint32_t ttbr0, ttbr1, ttbcr;
+
+}  __cacheline_aligned;
+
+void vcpu_show_execution_state(struct vcpu *);
+void vcpu_show_registers(const struct vcpu *);
+
+#endif /* __ASM_DOMAIN_H__ */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 16:29:10 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 16:29:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbEB8-0001tu-Nq; Thu, 15 Dec 2011 16:29:06 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RbEB7-0001sO-77
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 16:29:05 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1323966511!59095035!6
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDY5Mjg=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13631 invoked from network); 15 Dec 2011 16:28:45 -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;
	15 Dec 2011 16:28:45 -0000
X-IronPort-AV: E=Sophos;i="4.71,357,1320642000"; d="scan'208";a="20001851"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Dec 2011 11:29:03 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Thu, 15 Dec 2011 11:29:03 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pBFGSMta003330;
	Thu, 15 Dec 2011 08:28:51 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Thu, 15 Dec 2011 16:30:44 +0000
Message-ID: <1323966657-19790-12-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1112131831560.3517@kaball-desktop>
References: <alpine.DEB.2.00.1112131831560.3517@kaball-desktop>
MIME-Version: 1.0
Cc: keir.xen@gmail.com, Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, JBeulich@suse.com,
	Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v3 12/25] arm: domain
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Domain creation and destruction, vcpu initialization and destruction,
arch specific scheduling functions called by common code.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
---
 xen/arch/arm/domain.c        |  253 ++++++++++++++++++++++++++++++++++++++++++
 xen/include/asm-arm/domain.h |   43 +++++++
 2 files changed, 296 insertions(+), 0 deletions(-)
 create mode 100644 xen/arch/arm/domain.c
 create mode 100644 xen/include/asm-arm/domain.h

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
new file mode 100644
index 0000000..d706b5f
--- /dev/null
+++ b/xen/arch/arm/domain.c
@@ -0,0 +1,253 @@
+#include <xen/config.h>
+#include <xen/init.h>
+#include <xen/lib.h>
+#include <xen/sched.h>
+#include <xen/softirq.h>
+#include <xen/wait.h>
+#include <xen/errno.h>
+
+#include <asm/current.h>
+#include <asm/regs.h>
+#include <asm/p2m.h>
+#include <asm/irq.h>
+
+DEFINE_PER_CPU(struct vcpu *, curr_vcpu);
+
+static void continue_idle_domain(struct vcpu *v)
+{
+    reset_stack_and_jump(idle_loop);
+}
+
+static void continue_nonidle_domain(struct vcpu *v)
+{
+    /* check_wakeup_from_wait(); */
+    reset_stack_and_jump(return_from_trap);
+}
+
+void idle_loop(void)
+{
+    for ( ; ; )
+    {
+		/* TODO
+		   if ( cpu_is_offline(smp_processor_id()) )
+		   play_dead();
+		   (*pm_idle)();
+		   BUG();
+		*/
+        do_tasklet();
+        do_softirq();
+    }
+}
+
+static void ctxt_switch_from(struct vcpu *p)
+{
+
+}
+
+static void ctxt_switch_to(struct vcpu *n)
+{
+    p2m_load_VTTBR(n->domain);
+}
+
+static void __context_switch(void)
+{
+    struct cpu_user_regs *stack_regs = guest_cpu_user_regs();
+    unsigned int          cpu = smp_processor_id();
+    struct vcpu          *p = per_cpu(curr_vcpu, cpu);
+    struct vcpu          *n = current;
+
+    ASSERT(p != n);
+    ASSERT(cpumask_empty(n->vcpu_dirty_cpumask));
+
+    if ( !is_idle_vcpu(p) )
+    {
+        memcpy(&p->arch.user_regs, stack_regs, CTXT_SWITCH_STACK_BYTES);
+        ctxt_switch_from(p);
+    }
+
+    if ( !is_idle_vcpu(n) )
+    {
+        memcpy(stack_regs, &n->arch.user_regs, CTXT_SWITCH_STACK_BYTES);
+        ctxt_switch_to(n);
+    }
+
+    per_cpu(curr_vcpu, cpu) = n;
+
+}
+
+static void schedule_tail(struct vcpu *v)
+{
+    if ( is_idle_vcpu(v) )
+        continue_idle_domain(v);
+    else
+        continue_nonidle_domain(v);
+}
+
+void context_switch(struct vcpu *prev, struct vcpu *next)
+{
+    unsigned int cpu = smp_processor_id();
+
+    ASSERT(local_irq_is_enabled());
+
+    printk("context switch %d:%d%s -> %d:%d%s\n",
+           prev->domain->domain_id, prev->vcpu_id, is_idle_vcpu(prev) ? " (idle)" : "",
+           next->domain->domain_id, next->vcpu_id, is_idle_vcpu(next) ? " (idle)" : "");
+
+	/* TODO
+	   if (prev != next)
+	   update_runstate_area(prev);
+	*/
+
+    local_irq_disable();
+
+    set_current(next);
+
+    if ( (per_cpu(curr_vcpu, cpu) == next) ||
+         (is_idle_vcpu(next) && cpu_online(cpu)) )
+    {
+        local_irq_enable();
+    }
+    else
+    {
+        __context_switch();
+
+        /* Re-enable interrupts before restoring state which may fault. */
+        local_irq_enable();
+    }
+
+    context_saved(prev);
+
+	/* TODO
+	   if (prev != next)
+	   update_runstate_area(next);
+	*/
+
+    schedule_tail(next);
+    BUG();
+
+}
+
+void continue_running(struct vcpu *same)
+{
+    schedule_tail(same);
+    BUG();
+}
+
+int __sync_local_execstate(void)
+{
+    unsigned long flags;
+    int switch_required;
+
+    local_irq_save(flags);
+
+    switch_required = (this_cpu(curr_vcpu) != current);
+
+    if ( switch_required )
+    {
+        ASSERT(current == idle_vcpu[smp_processor_id()]);
+        __context_switch();
+    }
+
+    local_irq_restore(flags);
+
+    return switch_required;
+}
+
+void sync_local_execstate(void)
+{
+    (void)__sync_local_execstate();
+}
+
+void startup_cpu_idle_loop(void)
+{
+        struct vcpu *v = current;
+
+        ASSERT(is_idle_vcpu(v));
+		/* TODO
+		   cpumask_set_cpu(v->processor, v->domain->domain_dirty_cpumask);
+		   cpumask_set_cpu(v->processor, v->vcpu_dirty_cpumask);
+		*/
+
+        reset_stack_and_jump(idle_loop);
+}
+
+struct domain *alloc_domain_struct(void)
+{
+    struct domain *d;
+    BUILD_BUG_ON(sizeof(*d) > PAGE_SIZE);
+    d = alloc_xenheap_pages(0, 0);
+    if ( d != NULL )
+        clear_page(d);
+    return d;
+}
+
+void free_domain_struct(struct domain *d)
+{
+    free_xenheap_page(d);
+}
+
+void dump_pageframe_info(struct domain *d)
+{
+
+}
+
+struct vcpu *alloc_vcpu_struct(void)
+{
+    struct vcpu *v;
+    BUILD_BUG_ON(sizeof(*v) > PAGE_SIZE);
+    v = alloc_xenheap_pages(0, 0);
+    if ( v != NULL )
+        clear_page(v);
+    return v;
+}
+
+void free_vcpu_struct(struct vcpu *v)
+{
+    free_xenheap_page(v);
+}
+
+int vcpu_initialise(struct vcpu *v)
+{
+    int rc = 0;
+
+    return rc;
+}
+
+void vcpu_destroy(struct vcpu *v)
+{
+
+}
+
+int arch_domain_create(struct domain *d, unsigned int domcr_flags)
+{
+    int rc;
+
+    d->max_vcpus = 8;
+
+    rc = 0;
+fail:
+    return rc;
+}
+
+void arch_domain_destroy(struct domain *d)
+{
+    /* p2m_destroy */
+    /* domain_vgic_destroy */
+}
+
+void arch_dump_domain_info(struct domain *d)
+{
+}
+
+void arch_dump_vcpu_info(struct vcpu *v)
+{
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
new file mode 100644
index 0000000..c226bdf
--- /dev/null
+++ b/xen/include/asm-arm/domain.h
@@ -0,0 +1,43 @@
+#ifndef __ASM_DOMAIN_H__
+#define __ASM_DOMAIN_H__
+
+#include <xen/config.h>
+#include <xen/cache.h>
+#include <asm/page.h>
+#include <asm/p2m.h>
+
+struct pending_irq
+{
+    int irq;
+    struct irq_desc *desc; /* only set it the irq corresponds to a physical irq */
+    uint8_t priority;
+    struct list_head link;
+};
+
+struct arch_domain
+{
+}  __cacheline_aligned;
+
+struct arch_vcpu
+{
+    struct cpu_user_regs user_regs;
+
+    uint32_t sctlr;
+    uint32_t ttbr0, ttbr1, ttbcr;
+
+}  __cacheline_aligned;
+
+void vcpu_show_execution_state(struct vcpu *);
+void vcpu_show_registers(const struct vcpu *);
+
+#endif /* __ASM_DOMAIN_H__ */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 16:29:10 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 16:29:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbEB6-0001rz-9H; Thu, 15 Dec 2011 16:29:04 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RbEB3-0001oI-UL
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 16:29:02 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1323966533!7554554!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjE2NDg=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19297 invoked from network); 15 Dec 2011 16:28:55 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 16:28:55 -0000
X-IronPort-AV: E=Sophos;i="4.71,357,1320642000"; d="scan'208";a="174308139"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Dec 2011 11:28:54 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Thu, 15 Dec 2011 11:28:54 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pBFGSMtV003330;
	Thu, 15 Dec 2011 08:28:42 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Thu, 15 Dec 2011 16:30:39 +0000
Message-ID: <1323966657-19790-7-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1112131831560.3517@kaball-desktop>
References: <alpine.DEB.2.00.1112131831560.3517@kaball-desktop>
MIME-Version: 1.0
Cc: keir.xen@gmail.com, Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, JBeulich@suse.com,
	Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v3 07/25] xen/common/Makefile: introduce
	HAS_CPUFREQ, HAS_PCI, HAS_PASSTHROUGH, HAS_NS16550, HAS_KEXEC
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

- make the compilation of ns16550.c depend upon HAS_NS16550;

- make the compilation of cpufreq depend upon HAS_CPUFREQ;

- make the compilation of pci depend upon HAS_PCI;

- make the compilation of passthrough depend upon HAS_PASSTHROUGH;

- make the compilation of kexec depend upon HAS_KEXEC.


Changes in v2:

- introduce HAS_KEXEC and CONFIG_KEXEC kexec.


Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
---
 xen/arch/ia64/Rules.mk        |    5 +++++
 xen/arch/x86/Rules.mk         |    5 +++++
 xen/common/Makefile           |    2 +-
 xen/common/shutdown.c         |    4 ++++
 xen/drivers/Makefile          |    6 +++---
 xen/drivers/char/Makefile     |    2 +-
 xen/drivers/char/console.c    |    4 ++++
 xen/include/asm-ia64/config.h |    1 +
 xen/include/asm-x86/config.h  |    1 +
 9 files changed, 25 insertions(+), 5 deletions(-)

diff --git a/xen/arch/ia64/Rules.mk b/xen/arch/ia64/Rules.mk
index bef11c3..054b4de 100644
--- a/xen/arch/ia64/Rules.mk
+++ b/xen/arch/ia64/Rules.mk
@@ -4,6 +4,11 @@
 ia64 := y
 HAS_ACPI := y
 HAS_VGA  := y
+HAS_CPUFREQ := y
+HAS_PCI := y
+HAS_PASSTHROUGH := y
+HAS_NS16550 := y
+HAS_KEXEC := y
 xenoprof := y
 no_warns ?= n
 vti_debug ?= n
diff --git a/xen/arch/x86/Rules.mk b/xen/arch/x86/Rules.mk
index bf77aef..1e48877 100644
--- a/xen/arch/x86/Rules.mk
+++ b/xen/arch/x86/Rules.mk
@@ -3,6 +3,11 @@
 
 HAS_ACPI := y
 HAS_VGA  := y
+HAS_CPUFREQ := y
+HAS_PCI := y
+HAS_PASSTHROUGH := y
+HAS_NS16550 := y
+HAS_KEXEC := y
 xenoprof := y
 
 #
diff --git a/xen/common/Makefile b/xen/common/Makefile
index 1d85e65..9249845 100644
--- a/xen/common/Makefile
+++ b/xen/common/Makefile
@@ -8,7 +8,7 @@ obj-y += grant_table.o
 obj-y += irq.o
 obj-y += kernel.o
 obj-y += keyhandler.o
-obj-y += kexec.o
+obj-$(HAS_KEXEC) += kexec.o
 obj-y += lib.o
 obj-y += memory.o
 obj-y += multicall.o
diff --git a/xen/common/shutdown.c b/xen/common/shutdown.c
index e356e86..b18ef5d 100644
--- a/xen/common/shutdown.c
+++ b/xen/common/shutdown.c
@@ -6,7 +6,9 @@
 #include <xen/delay.h>
 #include <xen/shutdown.h>
 #include <xen/console.h>
+#ifdef CONFIG_KEXEC
 #include <xen/kexec.h>
+#endif
 #include <asm/debugger.h>
 #include <public/sched.h>
 
@@ -58,7 +60,9 @@ void dom0_shutdown(u8 reason)
     case SHUTDOWN_watchdog:
     {
         printk("Domain 0 shutdown: watchdog rebooting machine.\n");
+#ifdef CONFIG_KEXEC
         kexec_crash();
+#endif
         machine_restart(0);
         break; /* not reached */
     }
diff --git a/xen/drivers/Makefile b/xen/drivers/Makefile
index eb4fb61..7239375 100644
--- a/xen/drivers/Makefile
+++ b/xen/drivers/Makefile
@@ -1,6 +1,6 @@
 subdir-y += char
-subdir-y += cpufreq
-subdir-y += pci
-subdir-y += passthrough
+subdir-$(HAS_CPUFREQ) += cpufreq
+subdir-$(HAS_PCI) += pci
+subdir-$(HAS_PASSTHROUGH) += passthrough
 subdir-$(HAS_ACPI) += acpi
 subdir-$(HAS_VGA) += video
diff --git a/xen/drivers/char/Makefile b/xen/drivers/char/Makefile
index ded9a94..19250c8 100644
--- a/xen/drivers/char/Makefile
+++ b/xen/drivers/char/Makefile
@@ -1,3 +1,3 @@
 obj-y += console.o
-obj-y += ns16550.o
+obj-$(HAS_NS16550) += ns16550.o
 obj-y += serial.o
diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
index 89cf4f8..19f021c 100644
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -22,7 +22,9 @@
 #include <xen/guest_access.h>
 #include <xen/shutdown.h>
 #include <xen/vga.h>
+#ifdef CONFIG_KEXEC
 #include <xen/kexec.h>
+#endif
 #include <asm/debugger.h>
 #include <asm/div64.h>
 #include <xen/hypercall.h> /* for do_console_io */
@@ -961,7 +963,9 @@ void panic(const char *fmt, ...)
 
     debugger_trap_immediate();
 
+#ifdef CONFIG_KEXEC
     kexec_crash();
+#endif
 
     if ( opt_noreboot )
     {
diff --git a/xen/include/asm-ia64/config.h b/xen/include/asm-ia64/config.h
index 0173487..6e9fc98 100644
--- a/xen/include/asm-ia64/config.h
+++ b/xen/include/asm-ia64/config.h
@@ -20,6 +20,7 @@
 #define CONFIG_EFI
 #define CONFIG_EFI_PCDP
 #define CONFIG_SERIAL_SGI_L1_CONSOLE
+#define CONFIG_KEXEC 1
 #define CONFIG_XENOPROF 1
 
 #define CONFIG_XEN_SMP
diff --git a/xen/include/asm-x86/config.h b/xen/include/asm-x86/config.h
index 905c0f8..cf6a4cc 100644
--- a/xen/include/asm-x86/config.h
+++ b/xen/include/asm-x86/config.h
@@ -44,6 +44,7 @@
 #define CONFIG_HOTPLUG_CPU 1
 
 #define CONFIG_XENOPROF 1
+#define CONFIG_KEXEC 1
 
 #define HZ 100
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 16:29:10 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 16:29:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbEB6-0001rz-9H; Thu, 15 Dec 2011 16:29:04 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RbEB3-0001oI-UL
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 16:29:02 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1323966533!7554554!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjE2NDg=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19297 invoked from network); 15 Dec 2011 16:28:55 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 16:28:55 -0000
X-IronPort-AV: E=Sophos;i="4.71,357,1320642000"; d="scan'208";a="174308139"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Dec 2011 11:28:54 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Thu, 15 Dec 2011 11:28:54 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pBFGSMtV003330;
	Thu, 15 Dec 2011 08:28:42 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Thu, 15 Dec 2011 16:30:39 +0000
Message-ID: <1323966657-19790-7-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1112131831560.3517@kaball-desktop>
References: <alpine.DEB.2.00.1112131831560.3517@kaball-desktop>
MIME-Version: 1.0
Cc: keir.xen@gmail.com, Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, JBeulich@suse.com,
	Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v3 07/25] xen/common/Makefile: introduce
	HAS_CPUFREQ, HAS_PCI, HAS_PASSTHROUGH, HAS_NS16550, HAS_KEXEC
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

- make the compilation of ns16550.c depend upon HAS_NS16550;

- make the compilation of cpufreq depend upon HAS_CPUFREQ;

- make the compilation of pci depend upon HAS_PCI;

- make the compilation of passthrough depend upon HAS_PASSTHROUGH;

- make the compilation of kexec depend upon HAS_KEXEC.


Changes in v2:

- introduce HAS_KEXEC and CONFIG_KEXEC kexec.


Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
---
 xen/arch/ia64/Rules.mk        |    5 +++++
 xen/arch/x86/Rules.mk         |    5 +++++
 xen/common/Makefile           |    2 +-
 xen/common/shutdown.c         |    4 ++++
 xen/drivers/Makefile          |    6 +++---
 xen/drivers/char/Makefile     |    2 +-
 xen/drivers/char/console.c    |    4 ++++
 xen/include/asm-ia64/config.h |    1 +
 xen/include/asm-x86/config.h  |    1 +
 9 files changed, 25 insertions(+), 5 deletions(-)

diff --git a/xen/arch/ia64/Rules.mk b/xen/arch/ia64/Rules.mk
index bef11c3..054b4de 100644
--- a/xen/arch/ia64/Rules.mk
+++ b/xen/arch/ia64/Rules.mk
@@ -4,6 +4,11 @@
 ia64 := y
 HAS_ACPI := y
 HAS_VGA  := y
+HAS_CPUFREQ := y
+HAS_PCI := y
+HAS_PASSTHROUGH := y
+HAS_NS16550 := y
+HAS_KEXEC := y
 xenoprof := y
 no_warns ?= n
 vti_debug ?= n
diff --git a/xen/arch/x86/Rules.mk b/xen/arch/x86/Rules.mk
index bf77aef..1e48877 100644
--- a/xen/arch/x86/Rules.mk
+++ b/xen/arch/x86/Rules.mk
@@ -3,6 +3,11 @@
 
 HAS_ACPI := y
 HAS_VGA  := y
+HAS_CPUFREQ := y
+HAS_PCI := y
+HAS_PASSTHROUGH := y
+HAS_NS16550 := y
+HAS_KEXEC := y
 xenoprof := y
 
 #
diff --git a/xen/common/Makefile b/xen/common/Makefile
index 1d85e65..9249845 100644
--- a/xen/common/Makefile
+++ b/xen/common/Makefile
@@ -8,7 +8,7 @@ obj-y += grant_table.o
 obj-y += irq.o
 obj-y += kernel.o
 obj-y += keyhandler.o
-obj-y += kexec.o
+obj-$(HAS_KEXEC) += kexec.o
 obj-y += lib.o
 obj-y += memory.o
 obj-y += multicall.o
diff --git a/xen/common/shutdown.c b/xen/common/shutdown.c
index e356e86..b18ef5d 100644
--- a/xen/common/shutdown.c
+++ b/xen/common/shutdown.c
@@ -6,7 +6,9 @@
 #include <xen/delay.h>
 #include <xen/shutdown.h>
 #include <xen/console.h>
+#ifdef CONFIG_KEXEC
 #include <xen/kexec.h>
+#endif
 #include <asm/debugger.h>
 #include <public/sched.h>
 
@@ -58,7 +60,9 @@ void dom0_shutdown(u8 reason)
     case SHUTDOWN_watchdog:
     {
         printk("Domain 0 shutdown: watchdog rebooting machine.\n");
+#ifdef CONFIG_KEXEC
         kexec_crash();
+#endif
         machine_restart(0);
         break; /* not reached */
     }
diff --git a/xen/drivers/Makefile b/xen/drivers/Makefile
index eb4fb61..7239375 100644
--- a/xen/drivers/Makefile
+++ b/xen/drivers/Makefile
@@ -1,6 +1,6 @@
 subdir-y += char
-subdir-y += cpufreq
-subdir-y += pci
-subdir-y += passthrough
+subdir-$(HAS_CPUFREQ) += cpufreq
+subdir-$(HAS_PCI) += pci
+subdir-$(HAS_PASSTHROUGH) += passthrough
 subdir-$(HAS_ACPI) += acpi
 subdir-$(HAS_VGA) += video
diff --git a/xen/drivers/char/Makefile b/xen/drivers/char/Makefile
index ded9a94..19250c8 100644
--- a/xen/drivers/char/Makefile
+++ b/xen/drivers/char/Makefile
@@ -1,3 +1,3 @@
 obj-y += console.o
-obj-y += ns16550.o
+obj-$(HAS_NS16550) += ns16550.o
 obj-y += serial.o
diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
index 89cf4f8..19f021c 100644
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -22,7 +22,9 @@
 #include <xen/guest_access.h>
 #include <xen/shutdown.h>
 #include <xen/vga.h>
+#ifdef CONFIG_KEXEC
 #include <xen/kexec.h>
+#endif
 #include <asm/debugger.h>
 #include <asm/div64.h>
 #include <xen/hypercall.h> /* for do_console_io */
@@ -961,7 +963,9 @@ void panic(const char *fmt, ...)
 
     debugger_trap_immediate();
 
+#ifdef CONFIG_KEXEC
     kexec_crash();
+#endif
 
     if ( opt_noreboot )
     {
diff --git a/xen/include/asm-ia64/config.h b/xen/include/asm-ia64/config.h
index 0173487..6e9fc98 100644
--- a/xen/include/asm-ia64/config.h
+++ b/xen/include/asm-ia64/config.h
@@ -20,6 +20,7 @@
 #define CONFIG_EFI
 #define CONFIG_EFI_PCDP
 #define CONFIG_SERIAL_SGI_L1_CONSOLE
+#define CONFIG_KEXEC 1
 #define CONFIG_XENOPROF 1
 
 #define CONFIG_XEN_SMP
diff --git a/xen/include/asm-x86/config.h b/xen/include/asm-x86/config.h
index 905c0f8..cf6a4cc 100644
--- a/xen/include/asm-x86/config.h
+++ b/xen/include/asm-x86/config.h
@@ -44,6 +44,7 @@
 #define CONFIG_HOTPLUG_CPU 1
 
 #define CONFIG_XENOPROF 1
+#define CONFIG_KEXEC 1
 
 #define HZ 100
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 16:29:12 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 16:29:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbEBB-0001wd-DE; Thu, 15 Dec 2011 16:29:09 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RbEB9-0001rI-1A
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 16:29:07 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1323966511!59095035!5
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDY5Mjg=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13511 invoked from network); 15 Dec 2011 16:28:43 -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;
	15 Dec 2011 16:28:43 -0000
X-IronPort-AV: E=Sophos;i="4.71,357,1320642000"; d="scan'208";a="20001846"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Dec 2011 11:29:01 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Thu, 15 Dec 2011 11:29:01 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pBFGSMtZ003330;
	Thu, 15 Dec 2011 08:28:49 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Thu, 15 Dec 2011 16:30:43 +0000
Message-ID: <1323966657-19790-11-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1112131831560.3517@kaball-desktop>
References: <alpine.DEB.2.00.1112131831560.3517@kaball-desktop>
MIME-Version: 1.0
Cc: keir.xen@gmail.com, Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, JBeulich@suse.com,
	Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v3 11/25] arm: entry.S and head.S
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Low level assembly routines, including entry.S and head.S.
Also the linker script and a collection of dummy functions that we plan
to reduce to zero as soon as possible.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
---
 xen/arch/arm/asm-offsets.c      |   76 ++++++++++
 xen/arch/arm/dummy.S            |   72 ++++++++++
 xen/arch/arm/entry.S            |  107 ++++++++++++++
 xen/arch/arm/head.S             |  298 +++++++++++++++++++++++++++++++++++++++
 xen/arch/arm/xen.lds.S          |  141 ++++++++++++++++++
 xen/include/asm-arm/asm_defns.h |   18 +++
 6 files changed, 712 insertions(+), 0 deletions(-)
 create mode 100644 xen/arch/arm/asm-offsets.c
 create mode 100644 xen/arch/arm/dummy.S
 create mode 100644 xen/arch/arm/entry.S
 create mode 100644 xen/arch/arm/head.S
 create mode 100644 xen/arch/arm/xen.lds.S
 create mode 100644 xen/include/asm-arm/asm_defns.h

diff --git a/xen/arch/arm/asm-offsets.c b/xen/arch/arm/asm-offsets.c
new file mode 100644
index 0000000..ee5d5d4
--- /dev/null
+++ b/xen/arch/arm/asm-offsets.c
@@ -0,0 +1,76 @@
+/*
+ * Generate definitions needed by assembly language modules.
+ * This code generates raw asm output which is post-processed
+ * to extract and format the required data.
+ */
+#define COMPILE_OFFSETS
+
+#include <xen/config.h>
+#include <xen/types.h>
+#include <public/xen.h>
+#include <asm/current.h>
+
+#define DEFINE(_sym, _val) \
+    __asm__ __volatile__ ( "\n->" #_sym " %0 " #_val : : "i" (_val) )
+#define BLANK() \
+    __asm__ __volatile__ ( "\n->" : : )
+#define OFFSET(_sym, _str, _mem) \
+    DEFINE(_sym, offsetof(_str, _mem));
+
+/* base-2 logarithm */
+#define __L2(_x)  (((_x) & 0x00000002) ?   1 : 0)
+#define __L4(_x)  (((_x) & 0x0000000c) ? ( 2 + __L2( (_x)>> 2)) : __L2( _x))
+#define __L8(_x)  (((_x) & 0x000000f0) ? ( 4 + __L4( (_x)>> 4)) : __L4( _x))
+#define __L16(_x) (((_x) & 0x0000ff00) ? ( 8 + __L8( (_x)>> 8)) : __L8( _x))
+#define LOG_2(_x) (((_x) & 0xffff0000) ? (16 + __L16((_x)>>16)) : __L16(_x))
+
+void __dummy__(void)
+{
+   OFFSET(UREGS_sp, struct cpu_user_regs, sp);
+   OFFSET(UREGS_lr, struct cpu_user_regs, lr);
+   OFFSET(UREGS_pc, struct cpu_user_regs, pc);
+   OFFSET(UREGS_cpsr, struct cpu_user_regs, cpsr);
+
+   OFFSET(UREGS_LR_usr, struct cpu_user_regs, lr_usr);
+   OFFSET(UREGS_SP_usr, struct cpu_user_regs, sp_usr);
+
+   OFFSET(UREGS_SP_svc, struct cpu_user_regs, sp_svc);
+   OFFSET(UREGS_LR_svc, struct cpu_user_regs, lr_svc);
+   OFFSET(UREGS_SPSR_svc, struct cpu_user_regs, spsr_svc);
+
+   OFFSET(UREGS_SP_abt, struct cpu_user_regs, sp_abt);
+   OFFSET(UREGS_LR_abt, struct cpu_user_regs, lr_abt);
+   OFFSET(UREGS_SPSR_abt, struct cpu_user_regs, spsr_abt);
+
+   OFFSET(UREGS_SP_und, struct cpu_user_regs, sp_und);
+   OFFSET(UREGS_LR_und, struct cpu_user_regs, lr_und);
+   OFFSET(UREGS_SPSR_und, struct cpu_user_regs, spsr_und);
+
+   OFFSET(UREGS_SP_irq, struct cpu_user_regs, sp_irq);
+   OFFSET(UREGS_LR_irq, struct cpu_user_regs, lr_irq);
+   OFFSET(UREGS_SPSR_irq, struct cpu_user_regs, spsr_irq);
+
+   OFFSET(UREGS_SP_fiq, struct cpu_user_regs, sp_fiq);
+   OFFSET(UREGS_LR_fiq, struct cpu_user_regs, lr_fiq);
+   OFFSET(UREGS_SPSR_fiq, struct cpu_user_regs, spsr_fiq);
+
+   OFFSET(UREGS_R8_fiq, struct cpu_user_regs, r8_fiq);
+   OFFSET(UREGS_R9_fiq, struct cpu_user_regs, r9_fiq);
+   OFFSET(UREGS_R10_fiq, struct cpu_user_regs, r10_fiq);
+   OFFSET(UREGS_R11_fiq, struct cpu_user_regs, r11_fiq);
+   OFFSET(UREGS_R12_fiq, struct cpu_user_regs, r12_fiq);
+
+   OFFSET(UREGS_kernel_sizeof, struct cpu_user_regs, cpsr);
+   DEFINE(UREGS_user_sizeof, sizeof(struct cpu_user_regs));
+   BLANK();
+
+   DEFINE(CPUINFO_sizeof, sizeof(struct cpu_info));
+}
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/arch/arm/dummy.S b/xen/arch/arm/dummy.S
new file mode 100644
index 0000000..5bc4f21
--- /dev/null
+++ b/xen/arch/arm/dummy.S
@@ -0,0 +1,72 @@
+/* Nothing is mapped at 1G, for the moment */
+#define DUMMY(x) \
+	.globl x; \
+x:	.word 0xe7f000f0
+/* x:	mov r0, #0x40000000 ; str r0, [r0]; b x */
+
+#define  NOP(x) \
+	.globl x; \
+x:	mov pc, lr
+	
+DUMMY(alloc_pirq_struct);
+DUMMY(alloc_vcpu_guest_context);
+DUMMY(arch_do_domctl);
+DUMMY(arch_do_sysctl);
+DUMMY(arch_do_vcpu_op);
+DUMMY(arch_get_info_guest);
+DUMMY(arch_get_xen_caps);
+DUMMY(arch_memory_op);
+DUMMY(arch_set_info_guest);
+DUMMY(arch_vcpu_reset);
+DUMMY(create_grant_host_mapping);
+DUMMY(__cpu_die);
+DUMMY(__cpu_disable);
+DUMMY(__cpu_up);
+DUMMY(do_get_pm_info);
+DUMMY(domain_get_maximum_gpfn);
+DUMMY(domain_relinquish_resources);
+DUMMY(domain_set_time_offset);
+DUMMY(dom_cow);
+DUMMY(donate_page);
+DUMMY(do_pm_op);
+DUMMY(flush_tlb_mask);
+DUMMY(free_vcpu_guest_context);
+DUMMY(get_page);
+DUMMY(get_page_type);
+DUMMY(gmfn_to_mfn);
+DUMMY(gnttab_clear_flag);
+DUMMY(gnttab_host_mapping_get_page_type);
+DUMMY(gnttab_mark_dirty);
+DUMMY(hypercall_create_continuation);
+DUMMY(iommu_map_page);
+DUMMY(iommu_unmap_page);
+DUMMY(is_iomem_page);
+DUMMY(local_event_delivery_enable);
+DUMMY(local_events_need_delivery);
+DUMMY(machine_to_phys_mapping_valid);
+DUMMY(max_page);
+DUMMY(node_online_map);
+DUMMY(nr_irqs_gsi);
+DUMMY(p2m_pod_decrease_reservation);
+DUMMY(guest_physmap_mark_populate_on_demand);
+DUMMY(page_get_owner_and_reference);
+DUMMY(page_is_ram_type);
+DUMMY(per_cpu__cpu_core_mask);
+DUMMY(per_cpu__cpu_sibling_mask);
+DUMMY(__per_cpu_offset);
+DUMMY(pirq_guest_bind);
+DUMMY(pirq_guest_unbind);
+DUMMY(pirq_set_affinity);
+DUMMY(put_page);
+DUMMY(put_page_type);
+DUMMY(replace_grant_host_mapping);
+DUMMY(send_timer_event);
+DUMMY(share_xen_page_with_privileged_guests);
+DUMMY(smp_send_state_dump);
+DUMMY(steal_page);
+DUMMY(sync_vcpu_execstate);
+DUMMY(__udelay);
+NOP(update_vcpu_system_time);
+DUMMY(vcpu_mark_events_pending);
+DUMMY(vcpu_show_execution_state);
+DUMMY(wallclock_time);
diff --git a/xen/arch/arm/entry.S b/xen/arch/arm/entry.S
new file mode 100644
index 0000000..16a8f36
--- /dev/null
+++ b/xen/arch/arm/entry.S
@@ -0,0 +1,107 @@
+#include <xen/config.h>
+#include <asm/asm_defns.h>
+
+#define SAVE_ONE_BANKED(reg)	mrs r11, reg; str r11, [sp, #UREGS_##reg]
+#define RESTORE_ONE_BANKED(reg)	ldr r11, [sp, #UREGS_##reg]; msr reg, r11
+
+#define SAVE_BANKED(mode) \
+	SAVE_ONE_BANKED(SP_##mode) ; SAVE_ONE_BANKED(LR_##mode) ; SAVE_ONE_BANKED(SPSR_##mode)
+
+#define RESTORE_BANKED(mode) \
+	RESTORE_ONE_BANKED(SP_##mode) ; RESTORE_ONE_BANKED(LR_##mode) ; RESTORE_ONE_BANKED(SPSR_##mode)
+
+#define SAVE_ALL											\
+	sub sp, #(UREGS_R8_fiq - UREGS_sp); /* SP, LR, SPSR, PC */					\
+	push {r0-r12}; /* Save R0-R12 */								\
+													\
+	mrs r11, ELR_hyp;		/* ELR_hyp is return address. */				\
+	str r11, [sp, #UREGS_pc];									\
+													\
+	str lr, [sp, #UREGS_lr];									\
+													\
+	add r11, sp, #UREGS_kernel_sizeof+4;								\
+	str r11, [sp, #UREGS_sp];									\
+													\
+	mrs r11, SPSR_hyp;										\
+	str r11, [sp, #UREGS_cpsr];									\
+	and r11, #PSR_MODE_MASK;									\
+	cmp r11, #PSR_MODE_HYP;										\
+	blne save_guest_regs
+
+save_guest_regs:
+	ldr r11, [sp, #UREGS_lr]
+	str r11, [sp, #UREGS_LR_usr]
+	ldr r11, =0xffffffff  /* Clobber SP which is only valid for hypervisor frames. */
+	str r11, [sp, #UREGS_sp]
+	SAVE_ONE_BANKED(SP_usr)
+	SAVE_BANKED(svc)
+	SAVE_BANKED(abt)
+	SAVE_BANKED(und)
+	SAVE_BANKED(irq)
+	SAVE_BANKED(fiq)
+	SAVE_ONE_BANKED(R8_fiq); SAVE_ONE_BANKED(R9_fiq); SAVE_ONE_BANKED(R10_fiq)
+	SAVE_ONE_BANKED(R11_fiq); SAVE_ONE_BANKED(R12_fiq);
+	mov pc, lr
+
+#define DEFINE_TRAP_ENTRY(trap)										\
+	ALIGN;												\
+trap_##trap:												\
+	SAVE_ALL;											\
+	adr lr, return_from_trap;									\
+	mov r0, sp;											\
+	mov r11, sp;											\
+	bic sp, #7; /* Align the stack pointer (noop on guest trap) */					\
+	b do_trap_##trap
+
+.globl hyp_traps_vector
+	.align 5
+hyp_traps_vector:
+	.word 0				/* 0x00 - Reset */
+	b trap_undefined_instruction	/* 0x04 - Undefined Instruction */
+	b trap_supervisor_call		/* 0x08 - Supervisor Call */
+	b trap_prefetch_abort		/* 0x0c - Prefetch Abort */
+	b trap_data_abort		/* 0x10 - Data Abort */
+	b trap_hypervisor		/* 0x14 - Hypervisor */
+	b trap_irq			/* 0x18 - IRQ */
+	b trap_fiq			/* 0x1c - FIQ */
+
+DEFINE_TRAP_ENTRY(undefined_instruction)
+DEFINE_TRAP_ENTRY(supervisor_call)
+DEFINE_TRAP_ENTRY(prefetch_abort)
+DEFINE_TRAP_ENTRY(data_abort)
+DEFINE_TRAP_ENTRY(hypervisor)
+DEFINE_TRAP_ENTRY(irq)
+DEFINE_TRAP_ENTRY(fiq)
+
+ENTRY(return_from_trap)
+	ldr r11, [sp, #UREGS_cpsr]
+	and r11, #PSR_MODE_MASK
+	cmp r11, #PSR_MODE_HYP
+	beq return_to_hypervisor
+
+ENTRY(return_to_guest)
+	mov r11, sp
+	bic sp, #7 /* Align the stack pointer */
+	bl leave_hypervisor_tail
+	ldr r11, [sp, #UREGS_pc]
+	msr ELR_hyp, r11
+	ldr r11, [sp, #UREGS_cpsr]
+	msr SPSR_hyp, r11
+	RESTORE_ONE_BANKED(SP_usr)
+	RESTORE_BANKED(svc)
+	RESTORE_BANKED(abt)
+	RESTORE_BANKED(und)
+	RESTORE_BANKED(irq)
+	RESTORE_BANKED(fiq)
+	RESTORE_ONE_BANKED(R8_fiq); RESTORE_ONE_BANKED(R9_fiq); RESTORE_ONE_BANKED(R10_fiq)
+	RESTORE_ONE_BANKED(R11_fiq); RESTORE_ONE_BANKED(R12_fiq);
+	ldr lr, [sp, #UREGS_LR_usr]
+	pop {r0-r12}
+	add sp, #(UREGS_R8_fiq - UREGS_sp); /* SP, LR, SPSR, PC */
+	eret
+
+ENTRY(return_to_hypervisor)
+	ldr lr, [sp, #UREGS_lr]
+	pop {r0-r12}
+	add sp, #(UREGS_R8_fiq - UREGS_sp); /* SP, LR, SPSR, PC */
+	eret
diff --git a/xen/arch/arm/head.S b/xen/arch/arm/head.S
new file mode 100644
index 0000000..b98c921
--- /dev/null
+++ b/xen/arch/arm/head.S
@@ -0,0 +1,298 @@
+/*
+ * xen/arch/arm/head.S
+ *
+ * Start-of-day code for an ARMv7-A with virt extensions.
+ *
+ * Tim Deegan <tim@xen.org>
+ * Copyright (c) 2011 Citrix Systems.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include <asm/config.h>
+#include <asm/page.h>
+#include <asm/asm_defns.h>
+
+
+/* Macro to print a string to the UART, if there is one.
+ * Clobbers r0-r3. */
+#ifdef EARLY_UART_ADDRESS
+#define PRINT(_s)       \
+	adr   r0, 98f ; \
+	bl    puts    ; \
+	b     99f     ; \
+98:	.asciz _s     ; \
+	.align 2      ; \
+99:
+#else
+#define PRINT(s)
+#endif
+
+	.arm
+
+	/* This must be the very first address in the loaded image.
+	 * It should be linked at XEN_VIRT_START, and loaded at any
+	 * 2MB-aligned address.  All of text+data+bss must fit in 2MB,
+	 * or the initial pagetable code below will need adjustment. */
+	.global start
+start:
+	cpsid aif                    /* Disable all interrupts */
+
+	/* Save the bootloader arguments in less-clobberable registers */
+	mov   r7, r1                 /* r7 := ARM-linux machine type */
+	mov   r8, r2                 /* r8 := ATAG base address */
+
+	/* Find out where we are */
+	ldr   r0, =start
+	adr   r9, start              /* r9  := paddr (start) */
+	sub   r10, r9, r0            /* r10 := phys-offset */
+
+#ifdef EARLY_UART_ADDRESS
+	/* Say hello */
+	ldr   r11, =EARLY_UART_ADDRESS  /* r11 := UART base address */
+	bl    init_uart
+#endif
+
+	/* Check that this CPU has Hyp mode */
+	mrc   CP32(r0, ID_PFR1)
+	and   r0, r0, #0xf000        /* Bits 12-15 define virt extensions */
+	teq   r0, #0x1000            /* Must == 0x1 or may be incompatible */
+	beq   1f
+	bl    putn
+	PRINT("- CPU doesn't support the virtualization extensions -\r\n")
+	b     fail
+1:
+	/* Check if we're already in it */
+	mrs   r0, cpsr
+	and   r0, r0, #0x1f          /* Mode is in the low 5 bits of CPSR */
+	teq   r0, #0x1a              /* Hyp Mode? */
+	bne   1f
+	PRINT("- Started in Hyp mode -\r\n")
+	b     hyp
+1:
+	/* Otherwise, it must have been Secure Supervisor mode */
+	mrc   CP32(r0, SCR)
+	tst   r0, #0x1               /* Not-Secure bit set? */
+	beq   1f
+	PRINT("- CPU is not in Hyp mode or Secure state -\r\n")
+	b     fail
+1:
+	/* OK, we're in Secure state. */
+	PRINT("- Started in Secure state -\r\n- Entering Hyp mode -\r\n")
+
+	/* Dance into Hyp mode */
+	cpsid aif, #0x16             /* Enter Monitor mode */
+	mrc   CP32(r0, SCR)
+	orr   r0, r0, #0x100         /* Set HCE */
+	orr   r0, r0, #0xb1          /* Set SCD, AW, FW and NS */
+	bic   r0, r0, #0xe           /* Clear EA, FIQ and IRQ */
+	mcr   CP32(r0, SCR)
+	/* Ugly: the system timer's frequency register is only
+	 * programmable in Secure state.  Since we don't know where its
+	 * memory-mapped control registers live, we can't find out the
+	 * right frequency.  Use the VE model's default frequency here. */
+	ldr   r0, =0x5f5e100         /* 100 MHz */
+	mcr   CP32(r0, CNTFRQ)
+	ldr   r0, =0x40c00           /* SMP, c11, c10 in non-secure mode */
+	mcr   CP32(r0, NSACR)
+	/* Continuing ugliness: Set up the GIC so NS state owns interrupts */
+	mov   r0, #GIC_BASE_ADDRESS
+	add   r0, r0, #GIC_DR_OFFSET
+	mov   r1, #0
+	str   r1, [r0]               /* Disable delivery in the distributor */
+	add   r0, r0, #0x80          /* GICD_IGROUP0 */
+	mov   r2, #0xffffffff        /* All interrupts to group 1 */
+	str   r2, [r0]
+	str   r2, [r0, #4]
+	str   r2, [r0, #8]
+	/* Must drop priority mask below 0x80 before entering NS state */
+	mov   r0, #GIC_BASE_ADDRESS
+	add   r0, r0, #GIC_CR_OFFSET
+	ldr   r1, =0xff
+	str   r1, [r0, #0x4]         /* -> GICC_PMR */
+	/* Reset a few config registers */
+	mov   r0, #0
+	mcr   CP32(r0, FCSEIDR)
+	mcr   CP32(r0, CONTEXTIDR)
+	/* FIXME: ought to reset some other NS control regs here */
+	adr   r1, 1f
+	adr   r0, hyp                /* Store paddr (hyp entry point) */
+	str   r0, [r1]               /* where we can use it for RFE */
+	isb                          /* Ensure we see the stored target address */
+	rfeia r1                     /* Enter Hyp mode */
+
+1:	.word 0                      /* PC to enter Hyp mode at */
+	.word 0x000001da             /* CPSR: LE, Abort/IRQ/FIQ off, Hyp */
+
+hyp:
+	PRINT("- Setting up control registers -\r\n")
+
+	/* Set up memory attribute type tables */
+	ldr   r0, =MAIR0VAL
+	ldr   r1, =MAIR1VAL
+	mcr   CP32(r0, MAIR0)
+	mcr   CP32(r1, MAIR1)
+	mcr   CP32(r0, HMAIR0)
+	mcr   CP32(r1, HMAIR1)
+
+	/* Set up the HTCR:
+	 * PT walks use Outer-Shareable accesses,
+	 * PT walks are write-back, no-write-allocate in both cache levels,
+	 * Full 32-bit address space goes through this table. */
+	ldr   r0, =0x80002500
+	mcr   CP32(r0, HTCR)
+
+	/* Set up the HSCTLR:
+	 * Exceptions in LE ARM,
+	 * Low-latency IRQs disabled,
+	 * Write-implies-XN disabled (for now),
+	 * I-cache and d-cache enabled,
+	 * Alignment checking enabled,
+	 * MMU translation disabled (for now). */
+	ldr   r0, =(HSCTLR_BASE|SCTLR_A|SCTLR_C)
+	mcr   CP32(r0, HSCTLR)
+
+	/* Write Xen's PT's paddr into the HTTBR */
+	ldr   r4, =xen_pgtable
+	add   r4, r4, r10            /* r4 := paddr (xen_pagetable) */
+	mov   r5, #0                 /* r4:r5 is paddr (xen_pagetable) */
+	mcrr  CP64(r4, r5, HTTBR)
+
+	/* Build the baseline idle pagetable's first-level entries */
+	ldr   r1, =xen_second
+	add   r1, r1, r10            /* r1 := paddr (xen_second) */
+	mov   r3, #0x0
+	orr   r2, r1, #0xe00         /* r2:r3 := table map of xen_second */
+	orr   r2, r2, #0x07f         /* (+ rights for linear PT) */
+	strd  r2, r3, [r4, #0]       /* Map it in slot 0 */
+	add   r2, r2, #0x1000
+	strd  r2, r3, [r4, #8]       /* Map 2nd page in slot 1 */
+	add   r2, r2, #0x1000
+	strd  r2, r3, [r4, #16]      /* Map 3rd page in slot 2 */
+	add   r2, r2, #0x1000
+	strd  r2, r3, [r4, #24]      /* Map 4th page in slot 3 */
+
+	/* Now set up the second-level entries */
+	orr   r2, r9, #0xe00
+	orr   r2, r2, #0x07d         /* r2:r3 := 2MB normal map of Xen */
+	mov   r4, r9, lsr #18        /* Slot for paddr(start) */
+	strd  r2, r3, [r1, r4]       /* Map Xen there */
+	ldr   r4, =start
+	lsr   r4, #18                /* Slot for vaddr(start) */
+	strd  r2, r3, [r1, r4]       /* Map Xen there too */
+#ifdef EARLY_UART_ADDRESS
+	ldr   r3, =(1<<(54-32))      /* NS for device mapping */
+	lsr   r2, r11, #21
+	lsl   r2, r2, #21            /* 2MB-aligned paddr of UART */
+	orr   r2, r2, #0xe00
+	orr   r2, r2, #0x071         /* r2:r3 := 2MB dev map including UART */
+	add   r4, r4, #8
+	strd  r2, r3, [r1, r4]       /* Map it in the fixmap's slot */
+#endif
+
+	PRINT("- Turning on paging -\r\n")
+
+	ldr   r1, =paging            /* Explicit vaddr, not RIP-relative */
+	mrc   CP32(r0, HSCTLR)
+	orr   r0, r0, #0x1           /* Add in the MMU enable bit */
+	dsb                          /* Flush PTE writes and finish reads */
+	mcr   CP32(r0, HSCTLR)       /* now paging is enabled */
+	isb                          /* Now, flush the icache */
+	mov   pc, r1                 /* Get a proper vaddr into PC */
+paging:
+
+#ifdef EARLY_UART_ADDRESS
+	/* Recover the UART address in the new address space */
+	lsl   r11, #11
+	lsr   r11, #11               /* UART base's offset from 2MB base */
+	adr   r0, start
+	add   r0, r0, #0x200000      /* vaddr of the fixmap's 2MB slot */
+	add   r11, r11, r0           /* r11 := vaddr (UART base address) */
+#endif
+
+	PRINT("- Entering C -\r\n")
+
+	ldr   sp, =init_stack        /* Supply a stack */
+	add   sp, #STACK_SIZE        /* (which grows down from the top). */
+	sub   sp, #CPUINFO_sizeof    /* Make room for CPU save record */
+	mov   r0, r10                /* Marshal args: - phys_offset */
+	mov   r1, r7                 /*               - machine type */
+	mov   r2, r8                 /*               - ATAG address */
+	b     start_xen              /* and disappear into the land of C */
+
+/* Fail-stop
+ * r0: string explaining why */
+fail:	PRINT("- Boot failed -\r\n")
+1:	wfe
+	b     1b
+
+#ifdef EARLY_UART_ADDRESS
+
+/* Bring up the UART. Specific to the PL011 UART.
+ * Clobbers r0-r2 */
+init_uart:
+	mov   r1, #0x0
+	str   r1, [r11, #0x24]       /* -> UARTIBRD (Baud divisor fraction) */
+	mov   r1, #0x4               /* 7.3728MHz / 0x4 == 16 * 115200 */
+	str   r1, [r11, #0x24]       /* -> UARTIBRD (Baud divisor integer) */
+	mov   r1, #0x60              /* 8n1 */
+	str   r1, [r11, #0x24]       /* -> UARTLCR_H (Line control) */
+	ldr   r1, =0x00000301        /* RXE | TXE | UARTEN */
+	str   r1, [r11, #0x30]       /* -> UARTCR (Control Register) */
+	adr   r0, 1f
+	b     puts
+1:	.asciz "- UART enabled -\r\n"
+	.align 4
+
+/* Print early debug messages.  Specific to the PL011 UART.
+ * r0: Nul-terminated string to print.
+ * Clobbers r0-r2 */
+puts:
+	ldr   r2, [r11, #0x18]       /* <- UARTFR (Flag register) */
+	tst   r2, #0x8               /* Check BUSY bit */
+	bne   puts                   /* Wait for the UART to be ready */
+	ldrb  r2, [r0], #1           /* Load next char */
+	teq   r2, #0                 /* Exit on nul*/
+	moveq pc, lr
+	str   r2, [r11]              /* -> UARTDR (Data Register) */
+	b     puts
+
+/* Print a 32-bit number in hex.  Specific to the PL011 UART.
+ * r0: Number to print.
+ * clobbers r0-r3 */
+putn:
+	adr   r1, hex
+	mov   r3, #8
+1:	ldr   r2, [r11, #0x18]       /* <- UARTFR (Flag register) */
+	tst   r2, #0x8               /* Check BUSY bit */
+	bne   1b                     /* Wait for the UART to be ready */
+	and   r2, r0, #0xf0000000    /* Mask off the top nybble */
+	ldrb  r2, [r1, r2, lsr #28]  /* Convert to a char */
+	str   r2, [r11]              /* -> UARTDR (Data Register) */
+	lsl   r0, #4                 /* Roll it through one nybble at a time */
+	subs  r3, r3, #1
+	bne   1b
+	adr   r0, crlf               /* Finish with a newline */
+	b     puts
+
+crlf:	.asciz "\r\n"
+hex:	.ascii "0123456789abcdef"
+	.align 2
+
+#else  /* EARLY_UART_ADDRESS */
+
+init_uart:
+.global early_puts
+early_puts:
+puts:
+putn:	mov   pc, lr
+
+#endif /* EARLY_UART_ADDRESS */
diff --git a/xen/arch/arm/xen.lds.S b/xen/arch/arm/xen.lds.S
new file mode 100644
index 0000000..5a62e2c
--- /dev/null
+++ b/xen/arch/arm/xen.lds.S
@@ -0,0 +1,141 @@
+/* Excerpts written by Martin Mares <mj@atrey.karlin.mff.cuni.cz> */
+/* Modified for i386/x86-64 Xen by Keir Fraser */
+/* Modified for ARM Xen by Ian Campbell */
+
+#include <xen/config.h>
+#include <xen/cache.h>
+#include <asm/page.h>
+#include <asm/percpu.h>
+#undef ENTRY
+#undef ALIGN
+
+ENTRY(start)
+
+OUTPUT_ARCH(arm)
+
+PHDRS
+{
+  text PT_LOAD /* XXX should be AT ( XEN_PHYS_START ) */ ;
+}
+SECTIONS
+{
+  . = XEN_VIRT_START;
+  _start = .;
+  .text : /* XXX should be AT ( XEN_PHYS_START ) */ {
+        _stext = .;            /* Text section */
+       *(.text)
+       *(.fixup)
+       *(.gnu.warning)
+       _etext = .;             /* End of text section */
+  } :text = 0x9090
+
+  . = ALIGN(PAGE_SIZE);
+  .rodata : {
+        _srodata = .;          /* Read-only data */
+       *(.rodata)
+       *(.rodata.*)
+        _erodata = .;          /* End of read-only data */
+  } :text
+
+  .data : {                    /* Data */
+       . = ALIGN(PAGE_SIZE);
+       *(.data.page_aligned)
+       *(.data)
+       *(.data.rel)
+       *(.data.rel.*)
+       CONSTRUCTORS
+  } :text
+
+  . = ALIGN(SMP_CACHE_BYTES);
+  .data.read_mostly : {
+       /* Exception table */
+       __start___ex_table = .;
+       *(.ex_table)
+       __stop___ex_table = .;
+
+       /* Pre-exception table */
+       __start___pre_ex_table = .;
+       *(.ex_table.pre)
+       __stop___pre_ex_table = .;
+
+       *(.data.read_mostly)
+       *(.data.rel.ro)
+       *(.data.rel.ro.*)
+  } :text
+
+#ifdef LOCK_PROFILE
+  . = ALIGN(32);
+  __lock_profile_start = .;
+  .lockprofile.data : { *(.lockprofile.data) } :text
+  __lock_profile_end = .;
+#endif
+
+  . = ALIGN(PAGE_SIZE);             /* Init code and data */
+  __init_begin = .;
+  .init.text : {
+       _sinittext = .;
+       *(.init.text)
+       _einittext = .;
+  } :text
+  . = ALIGN(PAGE_SIZE);
+  .init.data : {
+       *(.init.rodata)
+       *(.init.rodata.str*)
+       *(.init.data)
+       *(.init.data.rel)
+       *(.init.data.rel.*)
+  } :text
+  . = ALIGN(32);
+  .init.setup : {
+       __setup_start = .;
+       *(.init.setup)
+       __setup_end = .;
+  } :text
+  .initcall.init : {
+       __initcall_start = .;
+       *(.initcallpresmp.init)
+       __presmp_initcall_end = .;
+       *(.initcall1.init)
+       __initcall_end = .;
+  } :text
+  .xsm_initcall.init : {
+       __xsm_initcall_start = .;
+       *(.xsm_initcall.init)
+       __xsm_initcall_end = .;
+  } :text
+  . = ALIGN(STACK_SIZE);
+  __init_end = .;
+
+  .bss : {                     /* BSS */
+       __bss_start = .;
+       *(.bss.stack_aligned)
+       . = ALIGN(PAGE_SIZE);
+       *(.bss.page_aligned)
+       *(.bss)
+       . = ALIGN(SMP_CACHE_BYTES);
+       __per_cpu_start = .;
+       *(.bss.percpu)
+       . = ALIGN(SMP_CACHE_BYTES);
+       *(.bss.percpu.read_mostly)
+       . = ALIGN(SMP_CACHE_BYTES);
+       __per_cpu_data_end = .;
+  } :text
+  _end = . ;
+
+  /* Sections to be discarded */
+  /DISCARD/ : {
+       *(.exit.text)
+       *(.exit.data)
+       *(.exitcall.exit)
+       *(.eh_frame)
+  }
+
+  /* Stabs debugging sections.  */
+  .stab 0 : { *(.stab) }
+  .stabstr 0 : { *(.stabstr) }
+  .stab.excl 0 : { *(.stab.excl) }
+  .stab.exclstr 0 : { *(.stab.exclstr) }
+  .stab.index 0 : { *(.stab.index) }
+  .stab.indexstr 0 : { *(.stab.indexstr) }
+  .comment 0 : { *(.comment) }
+}
diff --git a/xen/include/asm-arm/asm_defns.h b/xen/include/asm-arm/asm_defns.h
new file mode 100644
index 0000000..c59fb6c
--- /dev/null
+++ b/xen/include/asm-arm/asm_defns.h
@@ -0,0 +1,18 @@
+#ifndef __ARM_ASM_DEFNS_H__
+#define __ARM_ASM_DEFNS_H__
+
+#ifndef COMPILE_OFFSETS
+/* NB. Auto-generated from arch/.../asm-offsets.c */
+#include <asm/asm-offsets.h>
+#endif
+#include <asm/processor.h>
+
+#endif /* __ARM_ASM_DEFNS_H__ */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 16:29:12 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 16:29:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbEBB-0001wd-DE; Thu, 15 Dec 2011 16:29:09 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RbEB9-0001rI-1A
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 16:29:07 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1323966511!59095035!5
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDY5Mjg=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13511 invoked from network); 15 Dec 2011 16:28:43 -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;
	15 Dec 2011 16:28:43 -0000
X-IronPort-AV: E=Sophos;i="4.71,357,1320642000"; d="scan'208";a="20001846"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Dec 2011 11:29:01 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Thu, 15 Dec 2011 11:29:01 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pBFGSMtZ003330;
	Thu, 15 Dec 2011 08:28:49 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Thu, 15 Dec 2011 16:30:43 +0000
Message-ID: <1323966657-19790-11-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1112131831560.3517@kaball-desktop>
References: <alpine.DEB.2.00.1112131831560.3517@kaball-desktop>
MIME-Version: 1.0
Cc: keir.xen@gmail.com, Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, JBeulich@suse.com,
	Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v3 11/25] arm: entry.S and head.S
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Low level assembly routines, including entry.S and head.S.
Also the linker script and a collection of dummy functions that we plan
to reduce to zero as soon as possible.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
---
 xen/arch/arm/asm-offsets.c      |   76 ++++++++++
 xen/arch/arm/dummy.S            |   72 ++++++++++
 xen/arch/arm/entry.S            |  107 ++++++++++++++
 xen/arch/arm/head.S             |  298 +++++++++++++++++++++++++++++++++++++++
 xen/arch/arm/xen.lds.S          |  141 ++++++++++++++++++
 xen/include/asm-arm/asm_defns.h |   18 +++
 6 files changed, 712 insertions(+), 0 deletions(-)
 create mode 100644 xen/arch/arm/asm-offsets.c
 create mode 100644 xen/arch/arm/dummy.S
 create mode 100644 xen/arch/arm/entry.S
 create mode 100644 xen/arch/arm/head.S
 create mode 100644 xen/arch/arm/xen.lds.S
 create mode 100644 xen/include/asm-arm/asm_defns.h

diff --git a/xen/arch/arm/asm-offsets.c b/xen/arch/arm/asm-offsets.c
new file mode 100644
index 0000000..ee5d5d4
--- /dev/null
+++ b/xen/arch/arm/asm-offsets.c
@@ -0,0 +1,76 @@
+/*
+ * Generate definitions needed by assembly language modules.
+ * This code generates raw asm output which is post-processed
+ * to extract and format the required data.
+ */
+#define COMPILE_OFFSETS
+
+#include <xen/config.h>
+#include <xen/types.h>
+#include <public/xen.h>
+#include <asm/current.h>
+
+#define DEFINE(_sym, _val) \
+    __asm__ __volatile__ ( "\n->" #_sym " %0 " #_val : : "i" (_val) )
+#define BLANK() \
+    __asm__ __volatile__ ( "\n->" : : )
+#define OFFSET(_sym, _str, _mem) \
+    DEFINE(_sym, offsetof(_str, _mem));
+
+/* base-2 logarithm */
+#define __L2(_x)  (((_x) & 0x00000002) ?   1 : 0)
+#define __L4(_x)  (((_x) & 0x0000000c) ? ( 2 + __L2( (_x)>> 2)) : __L2( _x))
+#define __L8(_x)  (((_x) & 0x000000f0) ? ( 4 + __L4( (_x)>> 4)) : __L4( _x))
+#define __L16(_x) (((_x) & 0x0000ff00) ? ( 8 + __L8( (_x)>> 8)) : __L8( _x))
+#define LOG_2(_x) (((_x) & 0xffff0000) ? (16 + __L16((_x)>>16)) : __L16(_x))
+
+void __dummy__(void)
+{
+   OFFSET(UREGS_sp, struct cpu_user_regs, sp);
+   OFFSET(UREGS_lr, struct cpu_user_regs, lr);
+   OFFSET(UREGS_pc, struct cpu_user_regs, pc);
+   OFFSET(UREGS_cpsr, struct cpu_user_regs, cpsr);
+
+   OFFSET(UREGS_LR_usr, struct cpu_user_regs, lr_usr);
+   OFFSET(UREGS_SP_usr, struct cpu_user_regs, sp_usr);
+
+   OFFSET(UREGS_SP_svc, struct cpu_user_regs, sp_svc);
+   OFFSET(UREGS_LR_svc, struct cpu_user_regs, lr_svc);
+   OFFSET(UREGS_SPSR_svc, struct cpu_user_regs, spsr_svc);
+
+   OFFSET(UREGS_SP_abt, struct cpu_user_regs, sp_abt);
+   OFFSET(UREGS_LR_abt, struct cpu_user_regs, lr_abt);
+   OFFSET(UREGS_SPSR_abt, struct cpu_user_regs, spsr_abt);
+
+   OFFSET(UREGS_SP_und, struct cpu_user_regs, sp_und);
+   OFFSET(UREGS_LR_und, struct cpu_user_regs, lr_und);
+   OFFSET(UREGS_SPSR_und, struct cpu_user_regs, spsr_und);
+
+   OFFSET(UREGS_SP_irq, struct cpu_user_regs, sp_irq);
+   OFFSET(UREGS_LR_irq, struct cpu_user_regs, lr_irq);
+   OFFSET(UREGS_SPSR_irq, struct cpu_user_regs, spsr_irq);
+
+   OFFSET(UREGS_SP_fiq, struct cpu_user_regs, sp_fiq);
+   OFFSET(UREGS_LR_fiq, struct cpu_user_regs, lr_fiq);
+   OFFSET(UREGS_SPSR_fiq, struct cpu_user_regs, spsr_fiq);
+
+   OFFSET(UREGS_R8_fiq, struct cpu_user_regs, r8_fiq);
+   OFFSET(UREGS_R9_fiq, struct cpu_user_regs, r9_fiq);
+   OFFSET(UREGS_R10_fiq, struct cpu_user_regs, r10_fiq);
+   OFFSET(UREGS_R11_fiq, struct cpu_user_regs, r11_fiq);
+   OFFSET(UREGS_R12_fiq, struct cpu_user_regs, r12_fiq);
+
+   OFFSET(UREGS_kernel_sizeof, struct cpu_user_regs, cpsr);
+   DEFINE(UREGS_user_sizeof, sizeof(struct cpu_user_regs));
+   BLANK();
+
+   DEFINE(CPUINFO_sizeof, sizeof(struct cpu_info));
+}
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/arch/arm/dummy.S b/xen/arch/arm/dummy.S
new file mode 100644
index 0000000..5bc4f21
--- /dev/null
+++ b/xen/arch/arm/dummy.S
@@ -0,0 +1,72 @@
+/* Nothing is mapped at 1G, for the moment */
+#define DUMMY(x) \
+	.globl x; \
+x:	.word 0xe7f000f0
+/* x:	mov r0, #0x40000000 ; str r0, [r0]; b x */
+
+#define  NOP(x) \
+	.globl x; \
+x:	mov pc, lr
+	
+DUMMY(alloc_pirq_struct);
+DUMMY(alloc_vcpu_guest_context);
+DUMMY(arch_do_domctl);
+DUMMY(arch_do_sysctl);
+DUMMY(arch_do_vcpu_op);
+DUMMY(arch_get_info_guest);
+DUMMY(arch_get_xen_caps);
+DUMMY(arch_memory_op);
+DUMMY(arch_set_info_guest);
+DUMMY(arch_vcpu_reset);
+DUMMY(create_grant_host_mapping);
+DUMMY(__cpu_die);
+DUMMY(__cpu_disable);
+DUMMY(__cpu_up);
+DUMMY(do_get_pm_info);
+DUMMY(domain_get_maximum_gpfn);
+DUMMY(domain_relinquish_resources);
+DUMMY(domain_set_time_offset);
+DUMMY(dom_cow);
+DUMMY(donate_page);
+DUMMY(do_pm_op);
+DUMMY(flush_tlb_mask);
+DUMMY(free_vcpu_guest_context);
+DUMMY(get_page);
+DUMMY(get_page_type);
+DUMMY(gmfn_to_mfn);
+DUMMY(gnttab_clear_flag);
+DUMMY(gnttab_host_mapping_get_page_type);
+DUMMY(gnttab_mark_dirty);
+DUMMY(hypercall_create_continuation);
+DUMMY(iommu_map_page);
+DUMMY(iommu_unmap_page);
+DUMMY(is_iomem_page);
+DUMMY(local_event_delivery_enable);
+DUMMY(local_events_need_delivery);
+DUMMY(machine_to_phys_mapping_valid);
+DUMMY(max_page);
+DUMMY(node_online_map);
+DUMMY(nr_irqs_gsi);
+DUMMY(p2m_pod_decrease_reservation);
+DUMMY(guest_physmap_mark_populate_on_demand);
+DUMMY(page_get_owner_and_reference);
+DUMMY(page_is_ram_type);
+DUMMY(per_cpu__cpu_core_mask);
+DUMMY(per_cpu__cpu_sibling_mask);
+DUMMY(__per_cpu_offset);
+DUMMY(pirq_guest_bind);
+DUMMY(pirq_guest_unbind);
+DUMMY(pirq_set_affinity);
+DUMMY(put_page);
+DUMMY(put_page_type);
+DUMMY(replace_grant_host_mapping);
+DUMMY(send_timer_event);
+DUMMY(share_xen_page_with_privileged_guests);
+DUMMY(smp_send_state_dump);
+DUMMY(steal_page);
+DUMMY(sync_vcpu_execstate);
+DUMMY(__udelay);
+NOP(update_vcpu_system_time);
+DUMMY(vcpu_mark_events_pending);
+DUMMY(vcpu_show_execution_state);
+DUMMY(wallclock_time);
diff --git a/xen/arch/arm/entry.S b/xen/arch/arm/entry.S
new file mode 100644
index 0000000..16a8f36
--- /dev/null
+++ b/xen/arch/arm/entry.S
@@ -0,0 +1,107 @@
+#include <xen/config.h>
+#include <asm/asm_defns.h>
+
+#define SAVE_ONE_BANKED(reg)	mrs r11, reg; str r11, [sp, #UREGS_##reg]
+#define RESTORE_ONE_BANKED(reg)	ldr r11, [sp, #UREGS_##reg]; msr reg, r11
+
+#define SAVE_BANKED(mode) \
+	SAVE_ONE_BANKED(SP_##mode) ; SAVE_ONE_BANKED(LR_##mode) ; SAVE_ONE_BANKED(SPSR_##mode)
+
+#define RESTORE_BANKED(mode) \
+	RESTORE_ONE_BANKED(SP_##mode) ; RESTORE_ONE_BANKED(LR_##mode) ; RESTORE_ONE_BANKED(SPSR_##mode)
+
+#define SAVE_ALL											\
+	sub sp, #(UREGS_R8_fiq - UREGS_sp); /* SP, LR, SPSR, PC */					\
+	push {r0-r12}; /* Save R0-R12 */								\
+													\
+	mrs r11, ELR_hyp;		/* ELR_hyp is return address. */				\
+	str r11, [sp, #UREGS_pc];									\
+													\
+	str lr, [sp, #UREGS_lr];									\
+													\
+	add r11, sp, #UREGS_kernel_sizeof+4;								\
+	str r11, [sp, #UREGS_sp];									\
+													\
+	mrs r11, SPSR_hyp;										\
+	str r11, [sp, #UREGS_cpsr];									\
+	and r11, #PSR_MODE_MASK;									\
+	cmp r11, #PSR_MODE_HYP;										\
+	blne save_guest_regs
+
+save_guest_regs:
+	ldr r11, [sp, #UREGS_lr]
+	str r11, [sp, #UREGS_LR_usr]
+	ldr r11, =0xffffffff  /* Clobber SP which is only valid for hypervisor frames. */
+	str r11, [sp, #UREGS_sp]
+	SAVE_ONE_BANKED(SP_usr)
+	SAVE_BANKED(svc)
+	SAVE_BANKED(abt)
+	SAVE_BANKED(und)
+	SAVE_BANKED(irq)
+	SAVE_BANKED(fiq)
+	SAVE_ONE_BANKED(R8_fiq); SAVE_ONE_BANKED(R9_fiq); SAVE_ONE_BANKED(R10_fiq)
+	SAVE_ONE_BANKED(R11_fiq); SAVE_ONE_BANKED(R12_fiq);
+	mov pc, lr
+
+#define DEFINE_TRAP_ENTRY(trap)										\
+	ALIGN;												\
+trap_##trap:												\
+	SAVE_ALL;											\
+	adr lr, return_from_trap;									\
+	mov r0, sp;											\
+	mov r11, sp;											\
+	bic sp, #7; /* Align the stack pointer (noop on guest trap) */					\
+	b do_trap_##trap
+
+.globl hyp_traps_vector
+	.align 5
+hyp_traps_vector:
+	.word 0				/* 0x00 - Reset */
+	b trap_undefined_instruction	/* 0x04 - Undefined Instruction */
+	b trap_supervisor_call		/* 0x08 - Supervisor Call */
+	b trap_prefetch_abort		/* 0x0c - Prefetch Abort */
+	b trap_data_abort		/* 0x10 - Data Abort */
+	b trap_hypervisor		/* 0x14 - Hypervisor */
+	b trap_irq			/* 0x18 - IRQ */
+	b trap_fiq			/* 0x1c - FIQ */
+
+DEFINE_TRAP_ENTRY(undefined_instruction)
+DEFINE_TRAP_ENTRY(supervisor_call)
+DEFINE_TRAP_ENTRY(prefetch_abort)
+DEFINE_TRAP_ENTRY(data_abort)
+DEFINE_TRAP_ENTRY(hypervisor)
+DEFINE_TRAP_ENTRY(irq)
+DEFINE_TRAP_ENTRY(fiq)
+
+ENTRY(return_from_trap)
+	ldr r11, [sp, #UREGS_cpsr]
+	and r11, #PSR_MODE_MASK
+	cmp r11, #PSR_MODE_HYP
+	beq return_to_hypervisor
+
+ENTRY(return_to_guest)
+	mov r11, sp
+	bic sp, #7 /* Align the stack pointer */
+	bl leave_hypervisor_tail
+	ldr r11, [sp, #UREGS_pc]
+	msr ELR_hyp, r11
+	ldr r11, [sp, #UREGS_cpsr]
+	msr SPSR_hyp, r11
+	RESTORE_ONE_BANKED(SP_usr)
+	RESTORE_BANKED(svc)
+	RESTORE_BANKED(abt)
+	RESTORE_BANKED(und)
+	RESTORE_BANKED(irq)
+	RESTORE_BANKED(fiq)
+	RESTORE_ONE_BANKED(R8_fiq); RESTORE_ONE_BANKED(R9_fiq); RESTORE_ONE_BANKED(R10_fiq)
+	RESTORE_ONE_BANKED(R11_fiq); RESTORE_ONE_BANKED(R12_fiq);
+	ldr lr, [sp, #UREGS_LR_usr]
+	pop {r0-r12}
+	add sp, #(UREGS_R8_fiq - UREGS_sp); /* SP, LR, SPSR, PC */
+	eret
+
+ENTRY(return_to_hypervisor)
+	ldr lr, [sp, #UREGS_lr]
+	pop {r0-r12}
+	add sp, #(UREGS_R8_fiq - UREGS_sp); /* SP, LR, SPSR, PC */
+	eret
diff --git a/xen/arch/arm/head.S b/xen/arch/arm/head.S
new file mode 100644
index 0000000..b98c921
--- /dev/null
+++ b/xen/arch/arm/head.S
@@ -0,0 +1,298 @@
+/*
+ * xen/arch/arm/head.S
+ *
+ * Start-of-day code for an ARMv7-A with virt extensions.
+ *
+ * Tim Deegan <tim@xen.org>
+ * Copyright (c) 2011 Citrix Systems.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include <asm/config.h>
+#include <asm/page.h>
+#include <asm/asm_defns.h>
+
+
+/* Macro to print a string to the UART, if there is one.
+ * Clobbers r0-r3. */
+#ifdef EARLY_UART_ADDRESS
+#define PRINT(_s)       \
+	adr   r0, 98f ; \
+	bl    puts    ; \
+	b     99f     ; \
+98:	.asciz _s     ; \
+	.align 2      ; \
+99:
+#else
+#define PRINT(s)
+#endif
+
+	.arm
+
+	/* This must be the very first address in the loaded image.
+	 * It should be linked at XEN_VIRT_START, and loaded at any
+	 * 2MB-aligned address.  All of text+data+bss must fit in 2MB,
+	 * or the initial pagetable code below will need adjustment. */
+	.global start
+start:
+	cpsid aif                    /* Disable all interrupts */
+
+	/* Save the bootloader arguments in less-clobberable registers */
+	mov   r7, r1                 /* r7 := ARM-linux machine type */
+	mov   r8, r2                 /* r8 := ATAG base address */
+
+	/* Find out where we are */
+	ldr   r0, =start
+	adr   r9, start              /* r9  := paddr (start) */
+	sub   r10, r9, r0            /* r10 := phys-offset */
+
+#ifdef EARLY_UART_ADDRESS
+	/* Say hello */
+	ldr   r11, =EARLY_UART_ADDRESS  /* r11 := UART base address */
+	bl    init_uart
+#endif
+
+	/* Check that this CPU has Hyp mode */
+	mrc   CP32(r0, ID_PFR1)
+	and   r0, r0, #0xf000        /* Bits 12-15 define virt extensions */
+	teq   r0, #0x1000            /* Must == 0x1 or may be incompatible */
+	beq   1f
+	bl    putn
+	PRINT("- CPU doesn't support the virtualization extensions -\r\n")
+	b     fail
+1:
+	/* Check if we're already in it */
+	mrs   r0, cpsr
+	and   r0, r0, #0x1f          /* Mode is in the low 5 bits of CPSR */
+	teq   r0, #0x1a              /* Hyp Mode? */
+	bne   1f
+	PRINT("- Started in Hyp mode -\r\n")
+	b     hyp
+1:
+	/* Otherwise, it must have been Secure Supervisor mode */
+	mrc   CP32(r0, SCR)
+	tst   r0, #0x1               /* Not-Secure bit set? */
+	beq   1f
+	PRINT("- CPU is not in Hyp mode or Secure state -\r\n")
+	b     fail
+1:
+	/* OK, we're in Secure state. */
+	PRINT("- Started in Secure state -\r\n- Entering Hyp mode -\r\n")
+
+	/* Dance into Hyp mode */
+	cpsid aif, #0x16             /* Enter Monitor mode */
+	mrc   CP32(r0, SCR)
+	orr   r0, r0, #0x100         /* Set HCE */
+	orr   r0, r0, #0xb1          /* Set SCD, AW, FW and NS */
+	bic   r0, r0, #0xe           /* Clear EA, FIQ and IRQ */
+	mcr   CP32(r0, SCR)
+	/* Ugly: the system timer's frequency register is only
+	 * programmable in Secure state.  Since we don't know where its
+	 * memory-mapped control registers live, we can't find out the
+	 * right frequency.  Use the VE model's default frequency here. */
+	ldr   r0, =0x5f5e100         /* 100 MHz */
+	mcr   CP32(r0, CNTFRQ)
+	ldr   r0, =0x40c00           /* SMP, c11, c10 in non-secure mode */
+	mcr   CP32(r0, NSACR)
+	/* Continuing ugliness: Set up the GIC so NS state owns interrupts */
+	mov   r0, #GIC_BASE_ADDRESS
+	add   r0, r0, #GIC_DR_OFFSET
+	mov   r1, #0
+	str   r1, [r0]               /* Disable delivery in the distributor */
+	add   r0, r0, #0x80          /* GICD_IGROUP0 */
+	mov   r2, #0xffffffff        /* All interrupts to group 1 */
+	str   r2, [r0]
+	str   r2, [r0, #4]
+	str   r2, [r0, #8]
+	/* Must drop priority mask below 0x80 before entering NS state */
+	mov   r0, #GIC_BASE_ADDRESS
+	add   r0, r0, #GIC_CR_OFFSET
+	ldr   r1, =0xff
+	str   r1, [r0, #0x4]         /* -> GICC_PMR */
+	/* Reset a few config registers */
+	mov   r0, #0
+	mcr   CP32(r0, FCSEIDR)
+	mcr   CP32(r0, CONTEXTIDR)
+	/* FIXME: ought to reset some other NS control regs here */
+	adr   r1, 1f
+	adr   r0, hyp                /* Store paddr (hyp entry point) */
+	str   r0, [r1]               /* where we can use it for RFE */
+	isb                          /* Ensure we see the stored target address */
+	rfeia r1                     /* Enter Hyp mode */
+
+1:	.word 0                      /* PC to enter Hyp mode at */
+	.word 0x000001da             /* CPSR: LE, Abort/IRQ/FIQ off, Hyp */
+
+hyp:
+	PRINT("- Setting up control registers -\r\n")
+
+	/* Set up memory attribute type tables */
+	ldr   r0, =MAIR0VAL
+	ldr   r1, =MAIR1VAL
+	mcr   CP32(r0, MAIR0)
+	mcr   CP32(r1, MAIR1)
+	mcr   CP32(r0, HMAIR0)
+	mcr   CP32(r1, HMAIR1)
+
+	/* Set up the HTCR:
+	 * PT walks use Outer-Shareable accesses,
+	 * PT walks are write-back, no-write-allocate in both cache levels,
+	 * Full 32-bit address space goes through this table. */
+	ldr   r0, =0x80002500
+	mcr   CP32(r0, HTCR)
+
+	/* Set up the HSCTLR:
+	 * Exceptions in LE ARM,
+	 * Low-latency IRQs disabled,
+	 * Write-implies-XN disabled (for now),
+	 * I-cache and d-cache enabled,
+	 * Alignment checking enabled,
+	 * MMU translation disabled (for now). */
+	ldr   r0, =(HSCTLR_BASE|SCTLR_A|SCTLR_C)
+	mcr   CP32(r0, HSCTLR)
+
+	/* Write Xen's PT's paddr into the HTTBR */
+	ldr   r4, =xen_pgtable
+	add   r4, r4, r10            /* r4 := paddr (xen_pagetable) */
+	mov   r5, #0                 /* r4:r5 is paddr (xen_pagetable) */
+	mcrr  CP64(r4, r5, HTTBR)
+
+	/* Build the baseline idle pagetable's first-level entries */
+	ldr   r1, =xen_second
+	add   r1, r1, r10            /* r1 := paddr (xen_second) */
+	mov   r3, #0x0
+	orr   r2, r1, #0xe00         /* r2:r3 := table map of xen_second */
+	orr   r2, r2, #0x07f         /* (+ rights for linear PT) */
+	strd  r2, r3, [r4, #0]       /* Map it in slot 0 */
+	add   r2, r2, #0x1000
+	strd  r2, r3, [r4, #8]       /* Map 2nd page in slot 1 */
+	add   r2, r2, #0x1000
+	strd  r2, r3, [r4, #16]      /* Map 3rd page in slot 2 */
+	add   r2, r2, #0x1000
+	strd  r2, r3, [r4, #24]      /* Map 4th page in slot 3 */
+
+	/* Now set up the second-level entries */
+	orr   r2, r9, #0xe00
+	orr   r2, r2, #0x07d         /* r2:r3 := 2MB normal map of Xen */
+	mov   r4, r9, lsr #18        /* Slot for paddr(start) */
+	strd  r2, r3, [r1, r4]       /* Map Xen there */
+	ldr   r4, =start
+	lsr   r4, #18                /* Slot for vaddr(start) */
+	strd  r2, r3, [r1, r4]       /* Map Xen there too */
+#ifdef EARLY_UART_ADDRESS
+	ldr   r3, =(1<<(54-32))      /* NS for device mapping */
+	lsr   r2, r11, #21
+	lsl   r2, r2, #21            /* 2MB-aligned paddr of UART */
+	orr   r2, r2, #0xe00
+	orr   r2, r2, #0x071         /* r2:r3 := 2MB dev map including UART */
+	add   r4, r4, #8
+	strd  r2, r3, [r1, r4]       /* Map it in the fixmap's slot */
+#endif
+
+	PRINT("- Turning on paging -\r\n")
+
+	ldr   r1, =paging            /* Explicit vaddr, not RIP-relative */
+	mrc   CP32(r0, HSCTLR)
+	orr   r0, r0, #0x1           /* Add in the MMU enable bit */
+	dsb                          /* Flush PTE writes and finish reads */
+	mcr   CP32(r0, HSCTLR)       /* now paging is enabled */
+	isb                          /* Now, flush the icache */
+	mov   pc, r1                 /* Get a proper vaddr into PC */
+paging:
+
+#ifdef EARLY_UART_ADDRESS
+	/* Recover the UART address in the new address space */
+	lsl   r11, #11
+	lsr   r11, #11               /* UART base's offset from 2MB base */
+	adr   r0, start
+	add   r0, r0, #0x200000      /* vaddr of the fixmap's 2MB slot */
+	add   r11, r11, r0           /* r11 := vaddr (UART base address) */
+#endif
+
+	PRINT("- Entering C -\r\n")
+
+	ldr   sp, =init_stack        /* Supply a stack */
+	add   sp, #STACK_SIZE        /* (which grows down from the top). */
+	sub   sp, #CPUINFO_sizeof    /* Make room for CPU save record */
+	mov   r0, r10                /* Marshal args: - phys_offset */
+	mov   r1, r7                 /*               - machine type */
+	mov   r2, r8                 /*               - ATAG address */
+	b     start_xen              /* and disappear into the land of C */
+
+/* Fail-stop
+ * r0: string explaining why */
+fail:	PRINT("- Boot failed -\r\n")
+1:	wfe
+	b     1b
+
+#ifdef EARLY_UART_ADDRESS
+
+/* Bring up the UART. Specific to the PL011 UART.
+ * Clobbers r0-r2 */
+init_uart:
+	mov   r1, #0x0
+	str   r1, [r11, #0x24]       /* -> UARTIBRD (Baud divisor fraction) */
+	mov   r1, #0x4               /* 7.3728MHz / 0x4 == 16 * 115200 */
+	str   r1, [r11, #0x24]       /* -> UARTIBRD (Baud divisor integer) */
+	mov   r1, #0x60              /* 8n1 */
+	str   r1, [r11, #0x24]       /* -> UARTLCR_H (Line control) */
+	ldr   r1, =0x00000301        /* RXE | TXE | UARTEN */
+	str   r1, [r11, #0x30]       /* -> UARTCR (Control Register) */
+	adr   r0, 1f
+	b     puts
+1:	.asciz "- UART enabled -\r\n"
+	.align 4
+
+/* Print early debug messages.  Specific to the PL011 UART.
+ * r0: Nul-terminated string to print.
+ * Clobbers r0-r2 */
+puts:
+	ldr   r2, [r11, #0x18]       /* <- UARTFR (Flag register) */
+	tst   r2, #0x8               /* Check BUSY bit */
+	bne   puts                   /* Wait for the UART to be ready */
+	ldrb  r2, [r0], #1           /* Load next char */
+	teq   r2, #0                 /* Exit on nul*/
+	moveq pc, lr
+	str   r2, [r11]              /* -> UARTDR (Data Register) */
+	b     puts
+
+/* Print a 32-bit number in hex.  Specific to the PL011 UART.
+ * r0: Number to print.
+ * clobbers r0-r3 */
+putn:
+	adr   r1, hex
+	mov   r3, #8
+1:	ldr   r2, [r11, #0x18]       /* <- UARTFR (Flag register) */
+	tst   r2, #0x8               /* Check BUSY bit */
+	bne   1b                     /* Wait for the UART to be ready */
+	and   r2, r0, #0xf0000000    /* Mask off the top nybble */
+	ldrb  r2, [r1, r2, lsr #28]  /* Convert to a char */
+	str   r2, [r11]              /* -> UARTDR (Data Register) */
+	lsl   r0, #4                 /* Roll it through one nybble at a time */
+	subs  r3, r3, #1
+	bne   1b
+	adr   r0, crlf               /* Finish with a newline */
+	b     puts
+
+crlf:	.asciz "\r\n"
+hex:	.ascii "0123456789abcdef"
+	.align 2
+
+#else  /* EARLY_UART_ADDRESS */
+
+init_uart:
+.global early_puts
+early_puts:
+puts:
+putn:	mov   pc, lr
+
+#endif /* EARLY_UART_ADDRESS */
diff --git a/xen/arch/arm/xen.lds.S b/xen/arch/arm/xen.lds.S
new file mode 100644
index 0000000..5a62e2c
--- /dev/null
+++ b/xen/arch/arm/xen.lds.S
@@ -0,0 +1,141 @@
+/* Excerpts written by Martin Mares <mj@atrey.karlin.mff.cuni.cz> */
+/* Modified for i386/x86-64 Xen by Keir Fraser */
+/* Modified for ARM Xen by Ian Campbell */
+
+#include <xen/config.h>
+#include <xen/cache.h>
+#include <asm/page.h>
+#include <asm/percpu.h>
+#undef ENTRY
+#undef ALIGN
+
+ENTRY(start)
+
+OUTPUT_ARCH(arm)
+
+PHDRS
+{
+  text PT_LOAD /* XXX should be AT ( XEN_PHYS_START ) */ ;
+}
+SECTIONS
+{
+  . = XEN_VIRT_START;
+  _start = .;
+  .text : /* XXX should be AT ( XEN_PHYS_START ) */ {
+        _stext = .;            /* Text section */
+       *(.text)
+       *(.fixup)
+       *(.gnu.warning)
+       _etext = .;             /* End of text section */
+  } :text = 0x9090
+
+  . = ALIGN(PAGE_SIZE);
+  .rodata : {
+        _srodata = .;          /* Read-only data */
+       *(.rodata)
+       *(.rodata.*)
+        _erodata = .;          /* End of read-only data */
+  } :text
+
+  .data : {                    /* Data */
+       . = ALIGN(PAGE_SIZE);
+       *(.data.page_aligned)
+       *(.data)
+       *(.data.rel)
+       *(.data.rel.*)
+       CONSTRUCTORS
+  } :text
+
+  . = ALIGN(SMP_CACHE_BYTES);
+  .data.read_mostly : {
+       /* Exception table */
+       __start___ex_table = .;
+       *(.ex_table)
+       __stop___ex_table = .;
+
+       /* Pre-exception table */
+       __start___pre_ex_table = .;
+       *(.ex_table.pre)
+       __stop___pre_ex_table = .;
+
+       *(.data.read_mostly)
+       *(.data.rel.ro)
+       *(.data.rel.ro.*)
+  } :text
+
+#ifdef LOCK_PROFILE
+  . = ALIGN(32);
+  __lock_profile_start = .;
+  .lockprofile.data : { *(.lockprofile.data) } :text
+  __lock_profile_end = .;
+#endif
+
+  . = ALIGN(PAGE_SIZE);             /* Init code and data */
+  __init_begin = .;
+  .init.text : {
+       _sinittext = .;
+       *(.init.text)
+       _einittext = .;
+  } :text
+  . = ALIGN(PAGE_SIZE);
+  .init.data : {
+       *(.init.rodata)
+       *(.init.rodata.str*)
+       *(.init.data)
+       *(.init.data.rel)
+       *(.init.data.rel.*)
+  } :text
+  . = ALIGN(32);
+  .init.setup : {
+       __setup_start = .;
+       *(.init.setup)
+       __setup_end = .;
+  } :text
+  .initcall.init : {
+       __initcall_start = .;
+       *(.initcallpresmp.init)
+       __presmp_initcall_end = .;
+       *(.initcall1.init)
+       __initcall_end = .;
+  } :text
+  .xsm_initcall.init : {
+       __xsm_initcall_start = .;
+       *(.xsm_initcall.init)
+       __xsm_initcall_end = .;
+  } :text
+  . = ALIGN(STACK_SIZE);
+  __init_end = .;
+
+  .bss : {                     /* BSS */
+       __bss_start = .;
+       *(.bss.stack_aligned)
+       . = ALIGN(PAGE_SIZE);
+       *(.bss.page_aligned)
+       *(.bss)
+       . = ALIGN(SMP_CACHE_BYTES);
+       __per_cpu_start = .;
+       *(.bss.percpu)
+       . = ALIGN(SMP_CACHE_BYTES);
+       *(.bss.percpu.read_mostly)
+       . = ALIGN(SMP_CACHE_BYTES);
+       __per_cpu_data_end = .;
+  } :text
+  _end = . ;
+
+  /* Sections to be discarded */
+  /DISCARD/ : {
+       *(.exit.text)
+       *(.exit.data)
+       *(.exitcall.exit)
+       *(.eh_frame)
+  }
+
+  /* Stabs debugging sections.  */
+  .stab 0 : { *(.stab) }
+  .stabstr 0 : { *(.stabstr) }
+  .stab.excl 0 : { *(.stab.excl) }
+  .stab.exclstr 0 : { *(.stab.exclstr) }
+  .stab.index 0 : { *(.stab.index) }
+  .stab.indexstr 0 : { *(.stab.indexstr) }
+  .comment 0 : { *(.comment) }
+}
diff --git a/xen/include/asm-arm/asm_defns.h b/xen/include/asm-arm/asm_defns.h
new file mode 100644
index 0000000..c59fb6c
--- /dev/null
+++ b/xen/include/asm-arm/asm_defns.h
@@ -0,0 +1,18 @@
+#ifndef __ARM_ASM_DEFNS_H__
+#define __ARM_ASM_DEFNS_H__
+
+#ifndef COMPILE_OFFSETS
+/* NB. Auto-generated from arch/.../asm-offsets.c */
+#include <asm/asm-offsets.h>
+#endif
+#include <asm/processor.h>
+
+#endif /* __ARM_ASM_DEFNS_H__ */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 16:29:18 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 16:29:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbEBG-000223-Qc; Thu, 15 Dec 2011 16:29:14 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RbEBF-0001vg-QN
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 16:29:14 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1323966546!8963027!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjE2NDg=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13330 invoked from network); 15 Dec 2011 16:29:07 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 16:29:07 -0000
X-IronPort-AV: E=Sophos;i="4.71,357,1320642000"; d="scan'208";a="174308194"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Dec 2011 11:29:06 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Thu, 15 Dec 2011 11:29:05 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pBFGSMtb003330;
	Thu, 15 Dec 2011 08:28:52 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Thu, 15 Dec 2011 16:30:45 +0000
Message-ID: <1323966657-19790-13-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1112131831560.3517@kaball-desktop>
References: <alpine.DEB.2.00.1112131831560.3517@kaball-desktop>
MIME-Version: 1.0
Cc: keir.xen@gmail.com, Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, JBeulich@suse.com,
	Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v3 13/25] arm: domain_build
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Functions to build dom0: memory allocation, p2m construction, mappings
of the MMIO regions, ATAG setup.


Changes in v2:

- set elf.dest.


Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
---
 xen/arch/arm/domain_build.c        |  212 ++++++++++++++++++++++++++++++++++++
 xen/common/libelf/libelf-dominfo.c |    6 +
 xen/include/asm-arm/setup.h        |    2 +
 xen/include/xen/libelf.h           |    2 +-
 4 files changed, 221 insertions(+), 1 deletions(-)
 create mode 100644 xen/arch/arm/domain_build.c

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
new file mode 100644
index 0000000..b4e0aaa
--- /dev/null
+++ b/xen/arch/arm/domain_build.c
@@ -0,0 +1,212 @@
+#include <xen/config.h>
+#include <xen/init.h>
+#include <xen/lib.h>
+#include <xen/mm.h>
+#include <xen/domain_page.h>
+#include <xen/sched.h>
+#include <xen/libelf.h>
+#include <asm/irq.h>
+
+#include "gic.h"
+
+static unsigned int __initdata opt_dom0_max_vcpus;
+integer_param("dom0_max_vcpus", opt_dom0_max_vcpus);
+
+struct vcpu *__init alloc_dom0_vcpu0(void)
+{
+    dom0->vcpu = xmalloc_array(struct vcpu *, opt_dom0_max_vcpus);
+    if ( !dom0->vcpu )
+    {
+            printk("failed to alloc dom0->vccpu\n");
+        return NULL;
+    }
+    memset(dom0->vcpu, 0, opt_dom0_max_vcpus * sizeof(*dom0->vcpu));
+    dom0->max_vcpus = opt_dom0_max_vcpus;
+
+    return alloc_vcpu(dom0, 0, 0);
+}
+
+extern void guest_mode_entry(void);
+
+static void copy_from_flash(void *dst, paddr_t flash, unsigned long len)
+{
+    void *src = (void *)FIXMAP_ADDR(FIXMAP_MISC);
+    unsigned long offs;
+
+    printk("Copying %#lx bytes from flash %"PRIpaddr" to %p-%p: [",
+           len, flash, dst, dst+(1<<23));
+    for ( offs = 0; offs < len ; offs += PAGE_SIZE )
+    {
+        if ( ( offs % (1<<20) ) == 0 )
+            printk(".");
+        set_fixmap(FIXMAP_MISC, (flash+offs) >> PAGE_SHIFT, DEV_SHARED);
+        memcpy(dst+offs, src, PAGE_SIZE);
+    }
+    printk("]\n");
+
+    clear_fixmap(FIXMAP_MISC);
+}
+
+static void setup_linux_atag(paddr_t tags, paddr_t ram_s, paddr_t ram_e)
+{
+    paddr_t ma = gvirt_to_maddr(tags);
+    void *map = map_domain_page(ma>>PAGE_SHIFT);
+    void *p = map + (tags & (PAGE_SIZE - 1));
+    char cmdline[] = "earlyprintk=xenboot console=ttyAMA1 root=/dev/mmcblk0 debug rw";
+
+    /* not enough room on this page for all the tags */
+    BUG_ON(PAGE_SIZE - (tags & (PAGE_SIZE - 1)) < 8 * sizeof(uint32_t));
+
+#define TAG(type, val) *(type*)p = val; p+= sizeof(type)
+
+    /* ATAG_CORE */
+    TAG(uint32_t, 2);
+    TAG(uint32_t, 0x54410001);
+
+    /* ATAG_MEM */
+    TAG(uint32_t, 4);
+    TAG(uint32_t, 0x54410002);
+    TAG(uint32_t, (ram_e - ram_s) & 0xFFFFFFFF);
+    TAG(uint32_t, ram_s & 0xFFFFFFFF);
+
+    /* ATAG_CMDLINE */
+    TAG(uint32_t, 2 + ((strlen(cmdline) + 4) >> 2));
+    TAG(uint32_t, 0x54410009);
+    memcpy(p, cmdline, strlen(cmdline) + 1);
+    p += ((strlen(cmdline) + 4) >> 2) << 2;
+
+    /* ATAG_NONE */
+    TAG(uint32_t, 0);
+    TAG(uint32_t, 0);
+
+#undef TAG
+
+    unmap_domain_page(map);
+}
+
+/* Store kernel in first 8M of flash */
+#define KERNEL_FLASH_ADDRESS 0x00000000UL
+#define KERNEL_FLASH_SIZE    0x00800000UL
+
+int construct_dom0(struct domain *d)
+{
+    int rc, kernel_order;
+    void *kernel_img;
+
+    struct vcpu *v = d->vcpu[0];
+    struct cpu_user_regs *regs = &v->arch.user_regs;
+
+    struct elf_binary elf;
+    struct elf_dom_parms parms;
+
+    /* Sanity! */
+    BUG_ON(d->domain_id != 0);
+    BUG_ON(d->vcpu[0] == NULL);
+    BUG_ON(v->is_initialised);
+
+    printk("*** LOADING DOMAIN 0 ***\n");
+
+    kernel_order = get_order_from_bytes(KERNEL_FLASH_SIZE);
+    kernel_img = alloc_xenheap_pages(kernel_order, 0);
+    if ( kernel_img == NULL )
+        panic("Cannot allocate temporary buffer for kernel.\n");
+
+    copy_from_flash(kernel_img, KERNEL_FLASH_ADDRESS, KERNEL_FLASH_SIZE);
+
+    d->max_pages = ~0U;
+
+    if ( (rc = elf_init(&elf, kernel_img, KERNEL_FLASH_SIZE )) != 0 )
+        return rc;  memset(regs, 0, sizeof(*regs));
+#ifdef VERBOSE
+    elf_set_verbose(&elf);
+#endif
+    elf_parse_binary(&elf);
+    if ( (rc = elf_xen_parse(&elf, &parms)) != 0 )
+        return rc;
+
+    if ( (rc = p2m_alloc_table(d)) != 0 )
+        return rc;
+
+    /* 128M at 3G physical */
+    /* TODO size and location according to platform info */
+    printk("Populate P2M %#llx->%#llx\n", 0xc0000000ULL, 0xc8000000ULL);
+    p2m_populate_ram(d, 0xc0000000ULL, 0xc8000000ULL);
+
+    printk("Map CS2 MMIO regions 1:1 in the P2M %#llx->%#llx\n", 0x18000000ULL, 0x1BFFFFFFULL);
+    map_mmio_regions(d, 0x18000000, 0x1BFFFFFF, 0x18000000);
+    printk("Map CS3 MMIO regions 1:1 in the P2M %#llx->%#llx\n", 0x1C000000ULL, 0x1FFFFFFFULL);
+    map_mmio_regions(d, 0x1C000000, 0x1FFFFFFF, 0x1C000000);
+    printk("Map VGIC MMIO regions 1:1 in the P2M %#llx->%#llx\n", 0x2C008000ULL, 0x2DFFFFFFULL);
+    map_mmio_regions(d, 0x2C008000, 0x2DFFFFFF, 0x2C008000);
+
+    gicv_setup(d);
+
+    printk("Routing peripheral interrupts to guest\n");
+    /* TODO Get from device tree */
+    /*gic_route_irq_to_guest(d, 37, "uart0"); -- XXX used by Xen*/
+    gic_route_irq_to_guest(d, 38, "uart1");
+    gic_route_irq_to_guest(d, 39, "uart2");
+    gic_route_irq_to_guest(d, 40, "uart3");
+    gic_route_irq_to_guest(d, 41, "mmc0-1");
+    gic_route_irq_to_guest(d, 42, "mmc0-2");
+    gic_route_irq_to_guest(d, 44, "keyboard");
+    gic_route_irq_to_guest(d, 45, "mouse");
+    gic_route_irq_to_guest(d, 46, "lcd");
+    gic_route_irq_to_guest(d, 47, "eth");
+
+    /* Enable second stage translation */
+    WRITE_CP32(READ_CP32(HCR) | HCR_VM, HCR); isb();
+
+    /* The following load uses domain's p2m */
+    p2m_load_VTTBR(d);
+
+    printk("Loading ELF image into guest memory\n");
+    elf.dest = (void*)(unsigned long)parms.virt_kstart;
+    elf_load_binary(&elf);
+
+    printk("Free temporary kernel buffer\n");
+    free_xenheap_pages(kernel_img, kernel_order);
+
+    setup_linux_atag(0xc0000100ULL, 0xc0000000ULL, 0xc8000000ULL);
+
+    clear_bit(_VPF_down, &v->pause_flags);
+
+    memset(regs, 0, sizeof(*regs));
+
+    regs->pc = (uint32_t)parms.virt_entry;
+
+    regs->cpsr = PSR_ABT_MASK|PSR_FIQ_MASK|PSR_IRQ_MASK|PSR_MODE_SVC;
+
+/* FROM LINUX head.S
+
+ * Kernel startup entry point.
+ * ---------------------------
+ *
+ * This is normally called from the decompressor code.  The requirements
+ * are: MMU = off, D-cache = off, I-cache = dont care, r0 = 0,
+ * r1 = machine nr, r2 = atags or dtb pointer.
+ *...
+ */
+
+    regs->r0 = 0; /* SBZ */
+    regs->r1 = 2272; /* Machine NR: Versatile Express */
+    regs->r2 = 0xc0000100; /* ATAGS */
+
+    WRITE_CP32(SCTLR_BASE, SCTLR);
+
+    WRITE_CP32(HCR_AMO|HCR_IMO|HCR_VM, HCR);
+    isb();
+
+    local_abort_enable();
+
+    return 0;
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/common/libelf/libelf-dominfo.c b/xen/common/libelf/libelf-dominfo.c
index c569a48..523837f 100644
--- a/xen/common/libelf/libelf-dominfo.c
+++ b/xen/common/libelf/libelf-dominfo.c
@@ -341,6 +341,12 @@ static int elf_xen_note_check(struct elf_binary *elf,
         return 0;
     }
 
+    if ( elf_uval(elf, elf->ehdr, e_machine) == EM_ARM )
+    {
+         elf_msg(elf, "%s: Not bothering with notes on ARM\n", __FUNCTION__);
+         return 0;
+    }
+
     /* Check the contents of the Xen notes or guest string. */
     if ( ((strlen(parms->loader) == 0) ||
           strncmp(parms->loader, "generic", 7)) &&
diff --git a/xen/include/asm-arm/setup.h b/xen/include/asm-arm/setup.h
index c27d438..1dc3f97 100644
--- a/xen/include/asm-arm/setup.h
+++ b/xen/include/asm-arm/setup.h
@@ -5,6 +5,8 @@
 
 void arch_get_xen_caps(xen_capabilities_info_t *info);
 
+int construct_dom0(struct domain *d);
+
 #endif
 /*
  * Local variables:
diff --git a/xen/include/xen/libelf.h b/xen/include/xen/libelf.h
index 9de84eb..d799a80 100644
--- a/xen/include/xen/libelf.h
+++ b/xen/include/xen/libelf.h
@@ -23,7 +23,7 @@
 #ifndef __XEN_LIBELF_H__
 #define __XEN_LIBELF_H__
 
-#if defined(__i386__) || defined(__x86_64__) || defined(__ia64__)
+#if defined(__i386__) || defined(__x86_64__) || defined(__ia64__) || defined(__arm__)
 #define XEN_ELF_LITTLE_ENDIAN
 #else
 #error define architectural endianness
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 16:29:18 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 16:29:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbEBG-000223-Qc; Thu, 15 Dec 2011 16:29:14 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RbEBF-0001vg-QN
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 16:29:14 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1323966546!8963027!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjE2NDg=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13330 invoked from network); 15 Dec 2011 16:29:07 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 16:29:07 -0000
X-IronPort-AV: E=Sophos;i="4.71,357,1320642000"; d="scan'208";a="174308194"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Dec 2011 11:29:06 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Thu, 15 Dec 2011 11:29:05 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pBFGSMtb003330;
	Thu, 15 Dec 2011 08:28:52 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Thu, 15 Dec 2011 16:30:45 +0000
Message-ID: <1323966657-19790-13-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1112131831560.3517@kaball-desktop>
References: <alpine.DEB.2.00.1112131831560.3517@kaball-desktop>
MIME-Version: 1.0
Cc: keir.xen@gmail.com, Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, JBeulich@suse.com,
	Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v3 13/25] arm: domain_build
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Functions to build dom0: memory allocation, p2m construction, mappings
of the MMIO regions, ATAG setup.


Changes in v2:

- set elf.dest.


Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
---
 xen/arch/arm/domain_build.c        |  212 ++++++++++++++++++++++++++++++++++++
 xen/common/libelf/libelf-dominfo.c |    6 +
 xen/include/asm-arm/setup.h        |    2 +
 xen/include/xen/libelf.h           |    2 +-
 4 files changed, 221 insertions(+), 1 deletions(-)
 create mode 100644 xen/arch/arm/domain_build.c

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
new file mode 100644
index 0000000..b4e0aaa
--- /dev/null
+++ b/xen/arch/arm/domain_build.c
@@ -0,0 +1,212 @@
+#include <xen/config.h>
+#include <xen/init.h>
+#include <xen/lib.h>
+#include <xen/mm.h>
+#include <xen/domain_page.h>
+#include <xen/sched.h>
+#include <xen/libelf.h>
+#include <asm/irq.h>
+
+#include "gic.h"
+
+static unsigned int __initdata opt_dom0_max_vcpus;
+integer_param("dom0_max_vcpus", opt_dom0_max_vcpus);
+
+struct vcpu *__init alloc_dom0_vcpu0(void)
+{
+    dom0->vcpu = xmalloc_array(struct vcpu *, opt_dom0_max_vcpus);
+    if ( !dom0->vcpu )
+    {
+            printk("failed to alloc dom0->vccpu\n");
+        return NULL;
+    }
+    memset(dom0->vcpu, 0, opt_dom0_max_vcpus * sizeof(*dom0->vcpu));
+    dom0->max_vcpus = opt_dom0_max_vcpus;
+
+    return alloc_vcpu(dom0, 0, 0);
+}
+
+extern void guest_mode_entry(void);
+
+static void copy_from_flash(void *dst, paddr_t flash, unsigned long len)
+{
+    void *src = (void *)FIXMAP_ADDR(FIXMAP_MISC);
+    unsigned long offs;
+
+    printk("Copying %#lx bytes from flash %"PRIpaddr" to %p-%p: [",
+           len, flash, dst, dst+(1<<23));
+    for ( offs = 0; offs < len ; offs += PAGE_SIZE )
+    {
+        if ( ( offs % (1<<20) ) == 0 )
+            printk(".");
+        set_fixmap(FIXMAP_MISC, (flash+offs) >> PAGE_SHIFT, DEV_SHARED);
+        memcpy(dst+offs, src, PAGE_SIZE);
+    }
+    printk("]\n");
+
+    clear_fixmap(FIXMAP_MISC);
+}
+
+static void setup_linux_atag(paddr_t tags, paddr_t ram_s, paddr_t ram_e)
+{
+    paddr_t ma = gvirt_to_maddr(tags);
+    void *map = map_domain_page(ma>>PAGE_SHIFT);
+    void *p = map + (tags & (PAGE_SIZE - 1));
+    char cmdline[] = "earlyprintk=xenboot console=ttyAMA1 root=/dev/mmcblk0 debug rw";
+
+    /* not enough room on this page for all the tags */
+    BUG_ON(PAGE_SIZE - (tags & (PAGE_SIZE - 1)) < 8 * sizeof(uint32_t));
+
+#define TAG(type, val) *(type*)p = val; p+= sizeof(type)
+
+    /* ATAG_CORE */
+    TAG(uint32_t, 2);
+    TAG(uint32_t, 0x54410001);
+
+    /* ATAG_MEM */
+    TAG(uint32_t, 4);
+    TAG(uint32_t, 0x54410002);
+    TAG(uint32_t, (ram_e - ram_s) & 0xFFFFFFFF);
+    TAG(uint32_t, ram_s & 0xFFFFFFFF);
+
+    /* ATAG_CMDLINE */
+    TAG(uint32_t, 2 + ((strlen(cmdline) + 4) >> 2));
+    TAG(uint32_t, 0x54410009);
+    memcpy(p, cmdline, strlen(cmdline) + 1);
+    p += ((strlen(cmdline) + 4) >> 2) << 2;
+
+    /* ATAG_NONE */
+    TAG(uint32_t, 0);
+    TAG(uint32_t, 0);
+
+#undef TAG
+
+    unmap_domain_page(map);
+}
+
+/* Store kernel in first 8M of flash */
+#define KERNEL_FLASH_ADDRESS 0x00000000UL
+#define KERNEL_FLASH_SIZE    0x00800000UL
+
+int construct_dom0(struct domain *d)
+{
+    int rc, kernel_order;
+    void *kernel_img;
+
+    struct vcpu *v = d->vcpu[0];
+    struct cpu_user_regs *regs = &v->arch.user_regs;
+
+    struct elf_binary elf;
+    struct elf_dom_parms parms;
+
+    /* Sanity! */
+    BUG_ON(d->domain_id != 0);
+    BUG_ON(d->vcpu[0] == NULL);
+    BUG_ON(v->is_initialised);
+
+    printk("*** LOADING DOMAIN 0 ***\n");
+
+    kernel_order = get_order_from_bytes(KERNEL_FLASH_SIZE);
+    kernel_img = alloc_xenheap_pages(kernel_order, 0);
+    if ( kernel_img == NULL )
+        panic("Cannot allocate temporary buffer for kernel.\n");
+
+    copy_from_flash(kernel_img, KERNEL_FLASH_ADDRESS, KERNEL_FLASH_SIZE);
+
+    d->max_pages = ~0U;
+
+    if ( (rc = elf_init(&elf, kernel_img, KERNEL_FLASH_SIZE )) != 0 )
+        return rc;  memset(regs, 0, sizeof(*regs));
+#ifdef VERBOSE
+    elf_set_verbose(&elf);
+#endif
+    elf_parse_binary(&elf);
+    if ( (rc = elf_xen_parse(&elf, &parms)) != 0 )
+        return rc;
+
+    if ( (rc = p2m_alloc_table(d)) != 0 )
+        return rc;
+
+    /* 128M at 3G physical */
+    /* TODO size and location according to platform info */
+    printk("Populate P2M %#llx->%#llx\n", 0xc0000000ULL, 0xc8000000ULL);
+    p2m_populate_ram(d, 0xc0000000ULL, 0xc8000000ULL);
+
+    printk("Map CS2 MMIO regions 1:1 in the P2M %#llx->%#llx\n", 0x18000000ULL, 0x1BFFFFFFULL);
+    map_mmio_regions(d, 0x18000000, 0x1BFFFFFF, 0x18000000);
+    printk("Map CS3 MMIO regions 1:1 in the P2M %#llx->%#llx\n", 0x1C000000ULL, 0x1FFFFFFFULL);
+    map_mmio_regions(d, 0x1C000000, 0x1FFFFFFF, 0x1C000000);
+    printk("Map VGIC MMIO regions 1:1 in the P2M %#llx->%#llx\n", 0x2C008000ULL, 0x2DFFFFFFULL);
+    map_mmio_regions(d, 0x2C008000, 0x2DFFFFFF, 0x2C008000);
+
+    gicv_setup(d);
+
+    printk("Routing peripheral interrupts to guest\n");
+    /* TODO Get from device tree */
+    /*gic_route_irq_to_guest(d, 37, "uart0"); -- XXX used by Xen*/
+    gic_route_irq_to_guest(d, 38, "uart1");
+    gic_route_irq_to_guest(d, 39, "uart2");
+    gic_route_irq_to_guest(d, 40, "uart3");
+    gic_route_irq_to_guest(d, 41, "mmc0-1");
+    gic_route_irq_to_guest(d, 42, "mmc0-2");
+    gic_route_irq_to_guest(d, 44, "keyboard");
+    gic_route_irq_to_guest(d, 45, "mouse");
+    gic_route_irq_to_guest(d, 46, "lcd");
+    gic_route_irq_to_guest(d, 47, "eth");
+
+    /* Enable second stage translation */
+    WRITE_CP32(READ_CP32(HCR) | HCR_VM, HCR); isb();
+
+    /* The following load uses domain's p2m */
+    p2m_load_VTTBR(d);
+
+    printk("Loading ELF image into guest memory\n");
+    elf.dest = (void*)(unsigned long)parms.virt_kstart;
+    elf_load_binary(&elf);
+
+    printk("Free temporary kernel buffer\n");
+    free_xenheap_pages(kernel_img, kernel_order);
+
+    setup_linux_atag(0xc0000100ULL, 0xc0000000ULL, 0xc8000000ULL);
+
+    clear_bit(_VPF_down, &v->pause_flags);
+
+    memset(regs, 0, sizeof(*regs));
+
+    regs->pc = (uint32_t)parms.virt_entry;
+
+    regs->cpsr = PSR_ABT_MASK|PSR_FIQ_MASK|PSR_IRQ_MASK|PSR_MODE_SVC;
+
+/* FROM LINUX head.S
+
+ * Kernel startup entry point.
+ * ---------------------------
+ *
+ * This is normally called from the decompressor code.  The requirements
+ * are: MMU = off, D-cache = off, I-cache = dont care, r0 = 0,
+ * r1 = machine nr, r2 = atags or dtb pointer.
+ *...
+ */
+
+    regs->r0 = 0; /* SBZ */
+    regs->r1 = 2272; /* Machine NR: Versatile Express */
+    regs->r2 = 0xc0000100; /* ATAGS */
+
+    WRITE_CP32(SCTLR_BASE, SCTLR);
+
+    WRITE_CP32(HCR_AMO|HCR_IMO|HCR_VM, HCR);
+    isb();
+
+    local_abort_enable();
+
+    return 0;
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/common/libelf/libelf-dominfo.c b/xen/common/libelf/libelf-dominfo.c
index c569a48..523837f 100644
--- a/xen/common/libelf/libelf-dominfo.c
+++ b/xen/common/libelf/libelf-dominfo.c
@@ -341,6 +341,12 @@ static int elf_xen_note_check(struct elf_binary *elf,
         return 0;
     }
 
+    if ( elf_uval(elf, elf->ehdr, e_machine) == EM_ARM )
+    {
+         elf_msg(elf, "%s: Not bothering with notes on ARM\n", __FUNCTION__);
+         return 0;
+    }
+
     /* Check the contents of the Xen notes or guest string. */
     if ( ((strlen(parms->loader) == 0) ||
           strncmp(parms->loader, "generic", 7)) &&
diff --git a/xen/include/asm-arm/setup.h b/xen/include/asm-arm/setup.h
index c27d438..1dc3f97 100644
--- a/xen/include/asm-arm/setup.h
+++ b/xen/include/asm-arm/setup.h
@@ -5,6 +5,8 @@
 
 void arch_get_xen_caps(xen_capabilities_info_t *info);
 
+int construct_dom0(struct domain *d);
+
 #endif
 /*
  * Local variables:
diff --git a/xen/include/xen/libelf.h b/xen/include/xen/libelf.h
index 9de84eb..d799a80 100644
--- a/xen/include/xen/libelf.h
+++ b/xen/include/xen/libelf.h
@@ -23,7 +23,7 @@
 #ifndef __XEN_LIBELF_H__
 #define __XEN_LIBELF_H__
 
-#if defined(__i386__) || defined(__x86_64__) || defined(__ia64__)
+#if defined(__i386__) || defined(__x86_64__) || defined(__ia64__) || defined(__arm__)
 #define XEN_ELF_LITTLE_ENDIAN
 #else
 #error define architectural endianness
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 16:29:20 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 16:29:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbEBJ-00024M-GO; Thu, 15 Dec 2011 16:29:17 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RbEBI-00022w-9N
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 16:29:16 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1323966500!60916191!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDY5Mjg=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17484 invoked from network); 15 Dec 2011 16:28: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;
	15 Dec 2011 16:28:21 -0000
X-IronPort-AV: E=Sophos;i="4.71,357,1320642000"; d="scan'208";a="20001866"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Dec 2011 11:29:13 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Thu, 15 Dec 2011 11:29:13 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pBFGSMtd003330;
	Thu, 15 Dec 2011 08:28:56 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Thu, 15 Dec 2011 16:30:47 +0000
Message-ID: <1323966657-19790-15-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1112131831560.3517@kaball-desktop>
References: <alpine.DEB.2.00.1112131831560.3517@kaball-desktop>
MIME-Version: 1.0
Cc: keir.xen@gmail.com, Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, JBeulich@suse.com,
	Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v3 15/25] arm: mmio handlers
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Basic infrastructure to emulate mmio reads and writes.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
---
 xen/arch/arm/io.c |   50 ++++++++++++++++++++++++++++++++++++++++++++++++++
 xen/arch/arm/io.h |   53 +++++++++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 103 insertions(+), 0 deletions(-)
 create mode 100644 xen/arch/arm/io.c
 create mode 100644 xen/arch/arm/io.h

diff --git a/xen/arch/arm/io.c b/xen/arch/arm/io.c
new file mode 100644
index 0000000..8789705
--- /dev/null
+++ b/xen/arch/arm/io.c
@@ -0,0 +1,50 @@
+/*
+ * xen/arch/arm/io.h
+ *
+ * ARM I/O handlers
+ *
+ * Copyright (c) 2011 Citrix Systems.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include <xen/config.h>
+#include <xen/lib.h>
+#include <asm/current.h>
+
+#include "io.h"
+
+static const struct mmio_handler *const mmio_handlers[] =
+{
+};
+#define MMIO_HANDLER_NR ARRAY_SIZE(mmio_handlers)
+
+int handle_mmio(mmio_info_t *info)
+{
+    struct vcpu *v = current;
+    int i;
+
+    for ( i = 0; i < MMIO_HANDLER_NR; i++ )
+        if ( mmio_handlers[i]->check_handler(v, info->gpa) )
+            return info->dabt.write ?
+                mmio_handlers[i]->write_handler(v, info) :
+                mmio_handlers[i]->read_handler(v, info);
+
+    return 0;
+}
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/arch/arm/io.h b/xen/arch/arm/io.h
new file mode 100644
index 0000000..d7847e3
--- /dev/null
+++ b/xen/arch/arm/io.h
@@ -0,0 +1,53 @@
+/*
+ * xen/arch/arm/io.h
+ *
+ * ARM I/O handlers
+ *
+ * Copyright (c) 2011 Citrix Systems.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#ifndef __ARCH_ARM_IO_H__
+#define __ARCH_ARM_IO_H__
+
+#include <xen/lib.h>
+#include <asm/processor.h>
+
+typedef struct
+{
+    struct hsr_dabt dabt;
+    uint32_t gva;
+    paddr_t gpa;
+} mmio_info_t;
+
+typedef int (*mmio_read_t)(struct vcpu *v, mmio_info_t *info);
+typedef int (*mmio_write_t)(struct vcpu *v, mmio_info_t *info);
+typedef int (*mmio_check_t)(struct vcpu *v, paddr_t addr);
+
+struct mmio_handler {
+    mmio_check_t check_handler;
+    mmio_read_t read_handler;
+    mmio_write_t write_handler;
+};
+
+extern int handle_mmio(mmio_info_t *info);
+
+#endif
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 16:29:20 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 16:29:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbEBJ-00024M-GO; Thu, 15 Dec 2011 16:29:17 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RbEBI-00022w-9N
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 16:29:16 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1323966500!60916191!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDY5Mjg=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17484 invoked from network); 15 Dec 2011 16:28: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;
	15 Dec 2011 16:28:21 -0000
X-IronPort-AV: E=Sophos;i="4.71,357,1320642000"; d="scan'208";a="20001866"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Dec 2011 11:29:13 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Thu, 15 Dec 2011 11:29:13 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pBFGSMtd003330;
	Thu, 15 Dec 2011 08:28:56 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Thu, 15 Dec 2011 16:30:47 +0000
Message-ID: <1323966657-19790-15-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1112131831560.3517@kaball-desktop>
References: <alpine.DEB.2.00.1112131831560.3517@kaball-desktop>
MIME-Version: 1.0
Cc: keir.xen@gmail.com, Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, JBeulich@suse.com,
	Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v3 15/25] arm: mmio handlers
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Basic infrastructure to emulate mmio reads and writes.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
---
 xen/arch/arm/io.c |   50 ++++++++++++++++++++++++++++++++++++++++++++++++++
 xen/arch/arm/io.h |   53 +++++++++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 103 insertions(+), 0 deletions(-)
 create mode 100644 xen/arch/arm/io.c
 create mode 100644 xen/arch/arm/io.h

diff --git a/xen/arch/arm/io.c b/xen/arch/arm/io.c
new file mode 100644
index 0000000..8789705
--- /dev/null
+++ b/xen/arch/arm/io.c
@@ -0,0 +1,50 @@
+/*
+ * xen/arch/arm/io.h
+ *
+ * ARM I/O handlers
+ *
+ * Copyright (c) 2011 Citrix Systems.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include <xen/config.h>
+#include <xen/lib.h>
+#include <asm/current.h>
+
+#include "io.h"
+
+static const struct mmio_handler *const mmio_handlers[] =
+{
+};
+#define MMIO_HANDLER_NR ARRAY_SIZE(mmio_handlers)
+
+int handle_mmio(mmio_info_t *info)
+{
+    struct vcpu *v = current;
+    int i;
+
+    for ( i = 0; i < MMIO_HANDLER_NR; i++ )
+        if ( mmio_handlers[i]->check_handler(v, info->gpa) )
+            return info->dabt.write ?
+                mmio_handlers[i]->write_handler(v, info) :
+                mmio_handlers[i]->read_handler(v, info);
+
+    return 0;
+}
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/arch/arm/io.h b/xen/arch/arm/io.h
new file mode 100644
index 0000000..d7847e3
--- /dev/null
+++ b/xen/arch/arm/io.h
@@ -0,0 +1,53 @@
+/*
+ * xen/arch/arm/io.h
+ *
+ * ARM I/O handlers
+ *
+ * Copyright (c) 2011 Citrix Systems.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#ifndef __ARCH_ARM_IO_H__
+#define __ARCH_ARM_IO_H__
+
+#include <xen/lib.h>
+#include <asm/processor.h>
+
+typedef struct
+{
+    struct hsr_dabt dabt;
+    uint32_t gva;
+    paddr_t gpa;
+} mmio_info_t;
+
+typedef int (*mmio_read_t)(struct vcpu *v, mmio_info_t *info);
+typedef int (*mmio_write_t)(struct vcpu *v, mmio_info_t *info);
+typedef int (*mmio_check_t)(struct vcpu *v, paddr_t addr);
+
+struct mmio_handler {
+    mmio_check_t check_handler;
+    mmio_read_t read_handler;
+    mmio_write_t write_handler;
+};
+
+extern int handle_mmio(mmio_info_t *info);
+
+#endif
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 16:29:25 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 16:29:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbEBO-00029x-TO; Thu, 15 Dec 2011 16:29:22 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RbEBN-00022v-7r
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 16:29:21 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1323966553!7437895!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjE2NDg=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9216 invoked from network); 15 Dec 2011 16:29:14 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 16:29:14 -0000
X-IronPort-AV: E=Sophos;i="4.71,357,1320642000"; d="scan'208";a="174308217"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Dec 2011 11:29:13 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Thu, 15 Dec 2011 11:29:11 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pBFGSMtc003330;
	Thu, 15 Dec 2011 08:28:54 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Thu, 15 Dec 2011 16:30:46 +0000
Message-ID: <1323966657-19790-14-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1112131831560.3517@kaball-desktop>
References: <alpine.DEB.2.00.1112131831560.3517@kaball-desktop>
MIME-Version: 1.0
Cc: keir.xen@gmail.com, Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, JBeulich@suse.com,
	Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v3 14/25] arm: driver for CoreLink GIC-400
	Generic Interrupt Controller
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

- GICC, GICD and GICH initialization;

- interrupts routing, acking and EOI;

- interrupt injection into guests;

- maintenance interrupt handler, that takes care of EOI physical
  interrupts on behalf of the guest;

- a function to remap the virtual cpu interface into the guest address
  space, where the guest expect the GICC to be.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
---
 xen/arch/arm/domain.c |    2 +
 xen/arch/arm/gic.c    |  473 +++++++++++++++++++++++++++++++++++++++++++++++++
 xen/arch/arm/gic.h    |  151 ++++++++++++++++
 3 files changed, 626 insertions(+), 0 deletions(-)
 create mode 100644 xen/arch/arm/gic.c
 create mode 100644 xen/arch/arm/gic.h

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index d706b5f..ecbc5b7 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -11,6 +11,8 @@
 #include <asm/p2m.h>
 #include <asm/irq.h>
 
+#include "gic.h"
+
 DEFINE_PER_CPU(struct vcpu *, curr_vcpu);
 
 static void continue_idle_domain(struct vcpu *v)
diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
new file mode 100644
index 0000000..9643a7d
--- /dev/null
+++ b/xen/arch/arm/gic.c
@@ -0,0 +1,473 @@
+/*
+ * xen/arch/arm/gic.c
+ *
+ * ARM Generic Interrupt Controller support
+ *
+ * Tim Deegan <tim@xen.org>
+ * Copyright (c) 2011 Citrix Systems.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include <xen/config.h>
+#include <xen/lib.h>
+#include <xen/init.h>
+#include <xen/mm.h>
+#include <xen/irq.h>
+#include <xen/sched.h>
+#include <xen/errno.h>
+#include <xen/softirq.h>
+#include <asm/p2m.h>
+#include <asm/domain.h>
+
+#include "gic.h"
+
+/* Access to the GIC Distributor registers through the fixmap */
+#define GICD ((volatile uint32_t *) FIXMAP_ADDR(FIXMAP_GICD))
+#define GICC ((volatile uint32_t *) (FIXMAP_ADDR(FIXMAP_GICC1)  \
+                                     + (GIC_CR_OFFSET & 0xfff)))
+#define GICH ((volatile uint32_t *) (FIXMAP_ADDR(FIXMAP_GICH)  \
+                                     + (GIC_HR_OFFSET & 0xfff)))
+
+/* Global state */
+static struct {
+    paddr_t dbase;       /* Address of distributor registers */
+    paddr_t cbase;       /* Address of CPU interface registers */
+    paddr_t hbase;       /* Address of virtual interface registers */
+    unsigned int lines;
+    unsigned int cpus;
+    spinlock_t lock;
+} gic;
+
+irq_desc_t irq_desc[NR_IRQS];
+unsigned nr_lrs;
+
+static unsigned int gic_irq_startup(struct irq_desc *desc)
+{
+    uint32_t enabler;
+	int irq = desc->irq;
+
+    /* Enable routing */
+    enabler = GICD[GICD_ISENABLER + irq / 32];
+    GICD[GICD_ISENABLER + irq / 32] = enabler | (1u << (irq % 32));
+
+    return 0;
+}
+
+static void gic_irq_shutdown(struct irq_desc *desc)
+{
+    uint32_t enabler;
+	int irq = desc->irq;
+
+    /* Disable routing */
+    enabler = GICD[GICD_ICENABLER + irq / 32];
+    GICD[GICD_ICENABLER + irq / 32] = enabler | (1u << (irq % 32));
+}
+
+static void gic_irq_enable(struct irq_desc *desc)
+{
+
+}
+
+static void gic_irq_disable(struct irq_desc *desc)
+{
+
+}
+
+static void gic_irq_ack(struct irq_desc *desc)
+{
+    /* No ACK -- reading IAR has done this for us */
+}
+
+static void gic_host_irq_end(struct irq_desc *desc)
+{
+	int irq = desc->irq;
+    /* Lower the priority */
+    GICC[GICC_EOIR] = irq;
+    /* Deactivate */
+    GICC[GICC_DIR] = irq;
+}
+
+static void gic_guest_irq_end(struct irq_desc *desc)
+{
+	int irq = desc->irq;
+    /* Lower the priority of the IRQ */
+    GICC[GICC_EOIR] = irq;
+    /* Deactivation happens in maintenance interrupt / via GICV */
+}
+
+static void gic_irq_set_affinity(struct irq_desc *desc, const cpumask_t *mask)
+{
+    BUG();
+}
+
+/* XXX different for level vs edge */
+static hw_irq_controller gic_host_irq_type = {
+    .typename = "gic",
+    .startup = gic_irq_startup,
+    .shutdown = gic_irq_shutdown,
+    .enable = gic_irq_enable,
+    .disable = gic_irq_disable,
+    .ack = gic_irq_ack,
+    .end = gic_host_irq_end,
+    .set_affinity = gic_irq_set_affinity,
+};
+static hw_irq_controller gic_guest_irq_type = {
+    .typename = "gic",
+    .startup = gic_irq_startup,
+    .shutdown = gic_irq_shutdown,
+    .enable = gic_irq_enable,
+    .disable = gic_irq_disable,
+    .ack = gic_irq_ack,
+    .end = gic_guest_irq_end,
+    .set_affinity = gic_irq_set_affinity,
+};
+
+/* Program the GIC to route an interrupt */
+static int gic_route_irq(unsigned int irq, bool_t level,
+                         unsigned int cpu_mask, unsigned int priority)
+{
+    volatile unsigned char *bytereg;
+    uint32_t cfg, edgebit;
+    struct irq_desc *desc = irq_to_desc(irq);
+    unsigned long flags;
+
+    ASSERT(!(cpu_mask & ~0xff));  /* Targets bitmap only supports 8 CPUs */
+    ASSERT(priority <= 0xff);     /* Only 8 bits of priority */
+    ASSERT(irq < gic.lines + 32); /* Can't route interrupts that don't exist */
+
+    spin_lock_irqsave(&desc->lock, flags);
+    spin_lock(&gic.lock);
+
+    if ( desc->action != NULL )
+    {
+        spin_unlock(&desc->lock);
+        return -EBUSY;
+    }
+
+    desc->handler = &gic_host_irq_type;
+
+    /* Disable interrupt */
+    desc->handler->shutdown(desc);
+
+    /* Set edge / level */
+    cfg = GICD[GICD_ICFGR + irq / 16];
+    edgebit = 2u << (2 * (irq % 16));
+    if ( level )
+        cfg &= ~edgebit;
+    else
+        cfg |= edgebit;
+    GICD[GICD_ICFGR + irq / 16] = cfg;
+
+    /* Set target CPU mask (RAZ/WI on uniprocessor) */
+    bytereg = (unsigned char *) (GICD + GICD_ITARGETSR);
+    bytereg[irq] = cpu_mask;
+
+    /* Set priority */
+    bytereg = (unsigned char *) (GICD + GICD_IPRIORITYR);
+    bytereg[irq] = priority;
+
+    spin_unlock(&gic.lock);
+    spin_unlock_irqrestore(&desc->lock, flags);
+    return 0;
+}
+
+static void __init gic_dist_init(void)
+{
+    uint32_t type;
+    uint32_t cpumask = 1 << smp_processor_id();
+    int i;
+
+    cpumask |= cpumask << 8;
+    cpumask |= cpumask << 16;
+
+    /* Disable the distributor */
+    GICD[GICD_CTLR] = 0;
+
+    type = GICD[GICD_TYPER];
+    gic.lines = 32 * (type & GICD_TYPE_LINES);
+    gic.cpus = 1 + ((type & GICD_TYPE_CPUS) >> 5);
+    printk("GIC: %d lines, %d cpu%s%s (IID %8.8x).\n",
+           gic.lines, gic.cpus, (gic.cpus == 1) ? "" : "s",
+           (type & GICD_TYPE_SEC) ? ", secure" : "",
+           GICD[GICD_IIDR]);
+
+    /* Default all global IRQs to level, active low */
+    for ( i = 32; i < gic.lines; i += 16 )
+        GICD[GICD_ICFGR + i / 16] = 0x0;
+
+    /* Route all global IRQs to this CPU */
+    for ( i = 32; i < gic.lines; i += 4 )
+        GICD[GICD_ICFGR + i / 4] = cpumask;
+
+    /* Default priority for global interrupts */
+    for ( i = 32; i < gic.lines; i += 4 )
+        GICD[GICD_IPRIORITYR + i / 4] = 0xa0a0a0a0;
+
+    /* Disable all global interrupts */
+    for ( i = 32; i < gic.lines; i += 32 )
+        GICD[GICD_ICENABLER + i / 32] = ~0ul;
+
+    /* Turn on the distributor */
+    GICD[GICD_CTLR] = GICD_CTL_ENABLE;
+}
+
+static void __cpuinit gic_cpu_init(void)
+{
+    int i;
+
+    /* Disable all PPI and enable all SGI */
+    GICD[GICD_ICENABLER] = 0xffff0000; /* Disable all PPI */
+    GICD[GICD_ISENABLER] = 0x0000ffff; /* Enable all SGI */
+    /* Set PPI and SGI priorities */
+    for (i = 0; i < 32; i += 4)
+        GICD[GICD_IPRIORITYR + i / 4] = 0xa0a0a0a0;
+
+    /* Local settings: interface controller */
+    GICC[GICC_PMR] = 0xff;                /* Don't mask by priority */
+    GICC[GICC_BPR] = 0;                   /* Finest granularity of priority */
+    GICC[GICC_CTLR] = GICC_CTL_ENABLE|GICC_CTL_EOI;    /* Turn on delivery */
+}
+
+static void __cpuinit gic_hyp_init(void)
+{
+    uint32_t vtr;
+
+    vtr = GICH[GICH_VTR];
+    nr_lrs  = (vtr & GICH_VTR_NRLRGS) + 1;
+    printk("GICH: %d list registers available\n", nr_lrs);
+
+    GICH[GICH_HCR] = GICH_HCR_EN;
+    GICH[GICH_MISR] = GICH_MISR_EOI;
+}
+
+/* Set up the GIC */
+void gic_init(void)
+{
+    /* XXX FIXME get this from devicetree */
+    gic.dbase = GIC_BASE_ADDRESS + GIC_DR_OFFSET;
+    gic.cbase = GIC_BASE_ADDRESS + GIC_CR_OFFSET;
+    gic.hbase = GIC_BASE_ADDRESS + GIC_HR_OFFSET;
+    set_fixmap(FIXMAP_GICD, gic.dbase >> PAGE_SHIFT, DEV_SHARED);
+    BUILD_BUG_ON(FIXMAP_ADDR(FIXMAP_GICC1) !=
+                 FIXMAP_ADDR(FIXMAP_GICC2)-PAGE_SIZE);
+    set_fixmap(FIXMAP_GICC1, gic.cbase >> PAGE_SHIFT, DEV_SHARED);
+    set_fixmap(FIXMAP_GICC2, (gic.cbase >> PAGE_SHIFT) + 1, DEV_SHARED);
+    set_fixmap(FIXMAP_GICH, gic.hbase >> PAGE_SHIFT, DEV_SHARED);
+
+    /* Global settings: interrupt distributor */
+    spin_lock_init(&gic.lock);
+    spin_lock(&gic.lock);
+
+    gic_dist_init();
+    gic_cpu_init();
+    gic_hyp_init();
+
+    spin_unlock(&gic.lock);
+}
+
+void gic_route_irqs(void)
+{
+    /* XXX should get these from DT */
+    /* GIC maintenance */
+    gic_route_irq(25, 1, 1u << smp_processor_id(), 0xa0);
+    /* Hypervisor Timer */
+    gic_route_irq(26, 1, 1u << smp_processor_id(), 0xa0);
+    /* Timer */
+    gic_route_irq(30, 1, 1u << smp_processor_id(), 0xa0);
+    /* UART */
+    gic_route_irq(37, 0, 1u << smp_processor_id(), 0xa0);
+}
+
+void __init release_irq(unsigned int irq)
+{
+    struct irq_desc *desc;
+    unsigned long flags;
+   struct irqaction *action;
+
+    desc = irq_to_desc(irq);
+
+    spin_lock_irqsave(&desc->lock,flags);
+    action = desc->action;
+    desc->action  = NULL;
+    desc->status |= IRQ_DISABLED;
+
+    spin_lock(&gic.lock);
+    desc->handler->shutdown(desc);
+    spin_unlock(&gic.lock);
+
+    spin_unlock_irqrestore(&desc->lock,flags);
+
+    /* Wait to make sure it's not being used on another CPU */
+    do { smp_mb(); } while ( desc->status & IRQ_INPROGRESS );
+
+    if (action && action->free_on_release)
+        xfree(action);
+}
+
+static int __setup_irq(struct irq_desc *desc, unsigned int irq,
+                       struct irqaction *new)
+{
+    if ( desc->action != NULL )
+        return -EBUSY;
+
+    desc->action  = new;
+    desc->status &= ~IRQ_DISABLED;
+    dsb();
+
+    desc->handler->startup(desc);
+
+    return 0;
+}
+
+int __init setup_irq(unsigned int irq, struct irqaction *new)
+{
+    int rc;
+    unsigned long flags;
+    struct irq_desc *desc;
+
+    desc = irq_to_desc(irq);
+
+    spin_lock_irqsave(&desc->lock, flags);
+
+    rc = __setup_irq(desc, irq, new);
+
+    spin_unlock_irqrestore(&desc->lock,flags);
+
+    return rc;
+}
+
+void gic_set_guest_irq(unsigned int virtual_irq,
+        unsigned int state, unsigned int priority)
+{
+    BUG_ON(virtual_irq > nr_lrs);
+    GICH[GICH_LR + virtual_irq] = state |
+        GICH_LR_MAINTENANCE_IRQ |
+        ((priority >> 3) << GICH_LR_PRIORITY_SHIFT) |
+        ((virtual_irq & GICH_LR_VIRTUAL_MASK) << GICH_LR_VIRTUAL_SHIFT);
+}
+
+void gic_inject_irq_start(void)
+{
+    uint32_t hcr;
+    hcr = READ_CP32(HCR);
+    WRITE_CP32(hcr | HCR_VI, HCR);
+    isb();
+}
+
+void gic_inject_irq_stop(void)
+{
+    uint32_t hcr;
+    hcr = READ_CP32(HCR);
+    if (hcr & HCR_VI) {
+        WRITE_CP32(hcr & ~HCR_VI, HCR);
+        isb();
+    }
+}
+
+int gic_route_irq_to_guest(struct domain *d, unsigned int irq,
+                           const char * devname)
+{
+    struct irqaction *action;
+    struct irq_desc *desc = irq_to_desc(irq);
+    unsigned long flags;
+    int retval;
+
+    action = xmalloc(struct irqaction);
+    if (!action)
+        return -ENOMEM;
+
+    action->dev_id = d;
+    action->name = devname;
+
+    spin_lock_irqsave(&desc->lock, flags);
+
+    desc->handler = &gic_guest_irq_type;
+    desc->status |= IRQ_GUEST;
+
+    retval = __setup_irq(desc, irq, action);
+    if (retval) {
+        xfree(action);
+        goto out;
+    }
+
+out:
+    spin_unlock_irqrestore(&desc->lock, flags);
+    return retval;
+}
+
+/* Accept an interrupt from the GIC and dispatch its handler */
+void gic_interrupt(struct cpu_user_regs *regs, int is_fiq)
+{
+    uint32_t intack = GICC[GICC_IAR];
+    unsigned int irq = intack & GICC_IA_IRQ;
+
+    if ( irq == 1023 )
+        /* Spurious interrupt */
+        return;
+
+    do_IRQ(regs, irq, is_fiq);
+}
+
+void gicv_setup(struct domain *d)
+{
+    /* map the gic virtual cpu interface in the gic cpu interface region of
+     * the guest */
+    printk("mapping GICC at %#"PRIx32" to %#"PRIx32"\n",
+           GIC_BASE_ADDRESS + GIC_CR_OFFSET,
+           GIC_BASE_ADDRESS + GIC_VR_OFFSET);
+    map_mmio_regions(d, GIC_BASE_ADDRESS + GIC_CR_OFFSET,
+                        GIC_BASE_ADDRESS + GIC_CR_OFFSET + (2 * PAGE_SIZE) - 1,
+                        GIC_BASE_ADDRESS + GIC_VR_OFFSET);
+}
+
+static void maintenance_interrupt(int irq, void *dev_id, struct cpu_user_regs *regs)
+{
+    int i, virq;
+    uint32_t lr;
+    uint64_t eisr = GICH[GICH_EISR0] | (((uint64_t) GICH[GICH_EISR1]) << 32);
+
+    for ( i = 0; i < 64; i++ ) {
+        if ( eisr & ((uint64_t)1 << i) ) {
+            struct pending_irq *p;
+
+            lr = GICH[GICH_LR + i];
+            virq = lr & GICH_LR_VIRTUAL_MASK;
+            GICH[GICH_LR + i] = 0;
+
+            spin_lock(&current->arch.vgic.lock);
+            p = irq_to_pending(current, virq);
+            if ( p->desc != NULL ) {
+                p->desc->status &= ~IRQ_INPROGRESS;
+                GICC[GICC_DIR] = virq;
+            }
+            gic_inject_irq_stop();
+            list_del(&p->link);
+            INIT_LIST_HEAD(&p->link);
+            cpu_raise_softirq(current->processor, VGIC_SOFTIRQ);
+            spin_unlock(&current->arch.vgic.lock);
+        }
+    }
+}
+
+void __cpuinit init_maintenance_interrupt(void)
+{
+    request_irq(25, maintenance_interrupt, 0, "irq-maintenance", NULL);
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/arch/arm/gic.h b/xen/arch/arm/gic.h
new file mode 100644
index 0000000..63b6648
--- /dev/null
+++ b/xen/arch/arm/gic.h
@@ -0,0 +1,151 @@
+/*
+ * xen/arch/arm/gic.h
+ *
+ * ARM Generic Interrupt Controller support
+ *
+ * Tim Deegan <tim@xen.org>
+ * Copyright (c) 2011 Citrix Systems.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#ifndef __ARCH_ARM_GIC_H__
+#define __ARCH_ARM_GIC_H__
+
+#define GICD_CTLR       (0x000/4)
+#define GICD_TYPER      (0x004/4)
+#define GICD_IIDR       (0x008/4)
+#define GICD_IGROUPR    (0x080/4)
+#define GICD_IGROUPRN   (0x0FC/4)
+#define GICD_ISENABLER  (0x100/4)
+#define GICD_ISENABLERN (0x17C/4)
+#define GICD_ICENABLER  (0x180/4)
+#define GICD_ICENABLERN (0x1fC/4)
+#define GICD_ISPENDR    (0x200/4)
+#define GICD_ISPENDRN   (0x27C/4)
+#define GICD_ICPENDR    (0x280/4)
+#define GICD_ICPENDRN   (0x2FC/4)
+#define GICD_ISACTIVER  (0x300/4)
+#define GICD_ISACTIVERN (0x37C/4)
+#define GICD_ICACTIVER  (0x380/4)
+#define GICD_ICACTIVERN (0x3FC/4)
+#define GICD_IPRIORITYR (0x400/4)
+#define GICD_IPRIORITYRN (0x7F8/4)
+#define GICD_ITARGETSR  (0x800/4)
+#define GICD_ITARGETSRN (0xBF8/4)
+#define GICD_ICFGR      (0xC00/4)
+#define GICD_ICFGRN     (0xCFC/4)
+#define GICD_NSACR      (0xE00/4)
+#define GICD_NSACRN     (0xEFC/4)
+#define GICD_ICPIDR2    (0xFE8/4)
+#define GICD_SGIR       (0xF00/4)
+#define GICD_CPENDSGIR  (0xF10/4)
+#define GICD_CPENDSGIRN (0xF1C/4)
+#define GICD_SPENDSGIR  (0xF20/4)
+#define GICD_SPENDSGIRN (0xF2C/4)
+#define GICD_ICPIDR2    (0xFE8/4)
+
+#define GICC_CTLR       (0x0000/4)
+#define GICC_PMR        (0x0004/4)
+#define GICC_BPR        (0x0008/4)
+#define GICC_IAR        (0x000C/4)
+#define GICC_EOIR       (0x0010/4)
+#define GICC_RPR        (0x0014/4)
+#define GICC_HPPIR      (0x0018/4)
+#define GICC_APR        (0x00D0/4)
+#define GICC_NSAPR      (0x00E0/4)
+#define GICC_DIR        (0x1000/4)
+
+#define GICH_HCR        (0x00/4)
+#define GICH_VTR        (0x04/4)
+#define GICH_VMCR       (0x08/4)
+#define GICH_MISR       (0x10/4)
+#define GICH_EISR0      (0x20/4)
+#define GICH_EISR1      (0x24/4)
+#define GICH_ELRSR0     (0x30/4)
+#define GICH_ELRSR1     (0x34/4)
+#define GICH_APR        (0xF0/4)
+#define GICH_LR         (0x100/4)
+
+/* Register bits */
+#define GICD_CTL_ENABLE 0x1
+
+#define GICD_TYPE_LINES 0x01f
+#define GICD_TYPE_CPUS  0x0e0
+#define GICD_TYPE_SEC   0x400
+
+#define GICC_CTL_ENABLE 0x1
+#define GICC_CTL_EOI    (0x1 << 9)
+
+#define GICC_IA_IRQ     0x03ff
+#define GICC_IA_CPU     0x1c00
+
+#define GICH_HCR_EN       (1 << 0)
+#define GICH_HCR_UIE      (1 << 1)
+#define GICH_HCR_LRENPIE  (1 << 2)
+#define GICH_HCR_NPIE     (1 << 3)
+#define GICH_HCR_VGRP0EIE (1 << 4)
+#define GICH_HCR_VGRP0DIE (1 << 5)
+#define GICH_HCR_VGRP1EIE (1 << 6)
+#define GICH_HCR_VGRP1DIE (1 << 7)
+
+#define GICH_MISR_EOI     (1 << 0)
+#define GICH_MISR_U       (1 << 1)
+#define GICH_MISR_LRENP   (1 << 2)
+#define GICH_MISR_NP      (1 << 3)
+#define GICH_MISR_VGRP0E  (1 << 4)
+#define GICH_MISR_VGRP0D  (1 << 5)
+#define GICH_MISR_VGRP1E  (1 << 6)
+#define GICH_MISR_VGRP1D  (1 << 7)
+
+#define GICH_LR_VIRTUAL_MASK    0x3ff
+#define GICH_LR_VIRTUAL_SHIFT   0
+#define GICH_LR_PHYSICAL_MASK   0x3ff
+#define GICH_LR_PHYSICAL_SHIFT  10
+#define GICH_LR_STATE_MASK      0x3
+#define GICH_LR_STATE_SHIFT     28
+#define GICH_LR_PRIORITY_SHIFT  23
+#define GICH_LR_MAINTENANCE_IRQ (1<<19)
+#define GICH_LR_PENDING         (1<<28)
+#define GICH_LR_ACTIVE          (1<<29)
+#define GICH_LR_GRP1            (1<<30)
+#define GICH_LR_HW              (1<<31)
+#define GICH_LR_CPUID_SHIFT     9
+#define GICH_VTR_NRLRGS         0x3f
+
+extern struct pending_irq *irq_to_pending(struct vcpu *v, unsigned int irq);
+
+extern void gic_route_irqs(void);
+
+extern void __cpuinit init_maintenance_interrupt(void);
+extern void gic_set_guest_irq(unsigned int irq,
+        unsigned int state, unsigned int priority);
+extern void gic_inject_irq_start(void);
+extern void gic_inject_irq_stop(void);
+extern int gic_route_irq_to_guest(struct domain *d, unsigned int irq,
+                                  const char * devname);
+
+/* Accept an interrupt from the GIC and dispatch its handler */
+extern void gic_interrupt(struct cpu_user_regs *regs, int is_fiq);
+/* Bring up the interrupt controller */
+extern void gic_init(void);
+/* setup the gic virtual interface for a guest */
+extern void gicv_setup(struct domain *d);
+#endif
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 16:29:25 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 16:29:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbEBO-00029x-TO; Thu, 15 Dec 2011 16:29:22 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RbEBN-00022v-7r
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 16:29:21 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1323966553!7437895!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjE2NDg=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9216 invoked from network); 15 Dec 2011 16:29:14 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 16:29:14 -0000
X-IronPort-AV: E=Sophos;i="4.71,357,1320642000"; d="scan'208";a="174308217"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Dec 2011 11:29:13 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Thu, 15 Dec 2011 11:29:11 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pBFGSMtc003330;
	Thu, 15 Dec 2011 08:28:54 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Thu, 15 Dec 2011 16:30:46 +0000
Message-ID: <1323966657-19790-14-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1112131831560.3517@kaball-desktop>
References: <alpine.DEB.2.00.1112131831560.3517@kaball-desktop>
MIME-Version: 1.0
Cc: keir.xen@gmail.com, Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, JBeulich@suse.com,
	Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v3 14/25] arm: driver for CoreLink GIC-400
	Generic Interrupt Controller
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

- GICC, GICD and GICH initialization;

- interrupts routing, acking and EOI;

- interrupt injection into guests;

- maintenance interrupt handler, that takes care of EOI physical
  interrupts on behalf of the guest;

- a function to remap the virtual cpu interface into the guest address
  space, where the guest expect the GICC to be.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
---
 xen/arch/arm/domain.c |    2 +
 xen/arch/arm/gic.c    |  473 +++++++++++++++++++++++++++++++++++++++++++++++++
 xen/arch/arm/gic.h    |  151 ++++++++++++++++
 3 files changed, 626 insertions(+), 0 deletions(-)
 create mode 100644 xen/arch/arm/gic.c
 create mode 100644 xen/arch/arm/gic.h

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index d706b5f..ecbc5b7 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -11,6 +11,8 @@
 #include <asm/p2m.h>
 #include <asm/irq.h>
 
+#include "gic.h"
+
 DEFINE_PER_CPU(struct vcpu *, curr_vcpu);
 
 static void continue_idle_domain(struct vcpu *v)
diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
new file mode 100644
index 0000000..9643a7d
--- /dev/null
+++ b/xen/arch/arm/gic.c
@@ -0,0 +1,473 @@
+/*
+ * xen/arch/arm/gic.c
+ *
+ * ARM Generic Interrupt Controller support
+ *
+ * Tim Deegan <tim@xen.org>
+ * Copyright (c) 2011 Citrix Systems.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include <xen/config.h>
+#include <xen/lib.h>
+#include <xen/init.h>
+#include <xen/mm.h>
+#include <xen/irq.h>
+#include <xen/sched.h>
+#include <xen/errno.h>
+#include <xen/softirq.h>
+#include <asm/p2m.h>
+#include <asm/domain.h>
+
+#include "gic.h"
+
+/* Access to the GIC Distributor registers through the fixmap */
+#define GICD ((volatile uint32_t *) FIXMAP_ADDR(FIXMAP_GICD))
+#define GICC ((volatile uint32_t *) (FIXMAP_ADDR(FIXMAP_GICC1)  \
+                                     + (GIC_CR_OFFSET & 0xfff)))
+#define GICH ((volatile uint32_t *) (FIXMAP_ADDR(FIXMAP_GICH)  \
+                                     + (GIC_HR_OFFSET & 0xfff)))
+
+/* Global state */
+static struct {
+    paddr_t dbase;       /* Address of distributor registers */
+    paddr_t cbase;       /* Address of CPU interface registers */
+    paddr_t hbase;       /* Address of virtual interface registers */
+    unsigned int lines;
+    unsigned int cpus;
+    spinlock_t lock;
+} gic;
+
+irq_desc_t irq_desc[NR_IRQS];
+unsigned nr_lrs;
+
+static unsigned int gic_irq_startup(struct irq_desc *desc)
+{
+    uint32_t enabler;
+	int irq = desc->irq;
+
+    /* Enable routing */
+    enabler = GICD[GICD_ISENABLER + irq / 32];
+    GICD[GICD_ISENABLER + irq / 32] = enabler | (1u << (irq % 32));
+
+    return 0;
+}
+
+static void gic_irq_shutdown(struct irq_desc *desc)
+{
+    uint32_t enabler;
+	int irq = desc->irq;
+
+    /* Disable routing */
+    enabler = GICD[GICD_ICENABLER + irq / 32];
+    GICD[GICD_ICENABLER + irq / 32] = enabler | (1u << (irq % 32));
+}
+
+static void gic_irq_enable(struct irq_desc *desc)
+{
+
+}
+
+static void gic_irq_disable(struct irq_desc *desc)
+{
+
+}
+
+static void gic_irq_ack(struct irq_desc *desc)
+{
+    /* No ACK -- reading IAR has done this for us */
+}
+
+static void gic_host_irq_end(struct irq_desc *desc)
+{
+	int irq = desc->irq;
+    /* Lower the priority */
+    GICC[GICC_EOIR] = irq;
+    /* Deactivate */
+    GICC[GICC_DIR] = irq;
+}
+
+static void gic_guest_irq_end(struct irq_desc *desc)
+{
+	int irq = desc->irq;
+    /* Lower the priority of the IRQ */
+    GICC[GICC_EOIR] = irq;
+    /* Deactivation happens in maintenance interrupt / via GICV */
+}
+
+static void gic_irq_set_affinity(struct irq_desc *desc, const cpumask_t *mask)
+{
+    BUG();
+}
+
+/* XXX different for level vs edge */
+static hw_irq_controller gic_host_irq_type = {
+    .typename = "gic",
+    .startup = gic_irq_startup,
+    .shutdown = gic_irq_shutdown,
+    .enable = gic_irq_enable,
+    .disable = gic_irq_disable,
+    .ack = gic_irq_ack,
+    .end = gic_host_irq_end,
+    .set_affinity = gic_irq_set_affinity,
+};
+static hw_irq_controller gic_guest_irq_type = {
+    .typename = "gic",
+    .startup = gic_irq_startup,
+    .shutdown = gic_irq_shutdown,
+    .enable = gic_irq_enable,
+    .disable = gic_irq_disable,
+    .ack = gic_irq_ack,
+    .end = gic_guest_irq_end,
+    .set_affinity = gic_irq_set_affinity,
+};
+
+/* Program the GIC to route an interrupt */
+static int gic_route_irq(unsigned int irq, bool_t level,
+                         unsigned int cpu_mask, unsigned int priority)
+{
+    volatile unsigned char *bytereg;
+    uint32_t cfg, edgebit;
+    struct irq_desc *desc = irq_to_desc(irq);
+    unsigned long flags;
+
+    ASSERT(!(cpu_mask & ~0xff));  /* Targets bitmap only supports 8 CPUs */
+    ASSERT(priority <= 0xff);     /* Only 8 bits of priority */
+    ASSERT(irq < gic.lines + 32); /* Can't route interrupts that don't exist */
+
+    spin_lock_irqsave(&desc->lock, flags);
+    spin_lock(&gic.lock);
+
+    if ( desc->action != NULL )
+    {
+        spin_unlock(&desc->lock);
+        return -EBUSY;
+    }
+
+    desc->handler = &gic_host_irq_type;
+
+    /* Disable interrupt */
+    desc->handler->shutdown(desc);
+
+    /* Set edge / level */
+    cfg = GICD[GICD_ICFGR + irq / 16];
+    edgebit = 2u << (2 * (irq % 16));
+    if ( level )
+        cfg &= ~edgebit;
+    else
+        cfg |= edgebit;
+    GICD[GICD_ICFGR + irq / 16] = cfg;
+
+    /* Set target CPU mask (RAZ/WI on uniprocessor) */
+    bytereg = (unsigned char *) (GICD + GICD_ITARGETSR);
+    bytereg[irq] = cpu_mask;
+
+    /* Set priority */
+    bytereg = (unsigned char *) (GICD + GICD_IPRIORITYR);
+    bytereg[irq] = priority;
+
+    spin_unlock(&gic.lock);
+    spin_unlock_irqrestore(&desc->lock, flags);
+    return 0;
+}
+
+static void __init gic_dist_init(void)
+{
+    uint32_t type;
+    uint32_t cpumask = 1 << smp_processor_id();
+    int i;
+
+    cpumask |= cpumask << 8;
+    cpumask |= cpumask << 16;
+
+    /* Disable the distributor */
+    GICD[GICD_CTLR] = 0;
+
+    type = GICD[GICD_TYPER];
+    gic.lines = 32 * (type & GICD_TYPE_LINES);
+    gic.cpus = 1 + ((type & GICD_TYPE_CPUS) >> 5);
+    printk("GIC: %d lines, %d cpu%s%s (IID %8.8x).\n",
+           gic.lines, gic.cpus, (gic.cpus == 1) ? "" : "s",
+           (type & GICD_TYPE_SEC) ? ", secure" : "",
+           GICD[GICD_IIDR]);
+
+    /* Default all global IRQs to level, active low */
+    for ( i = 32; i < gic.lines; i += 16 )
+        GICD[GICD_ICFGR + i / 16] = 0x0;
+
+    /* Route all global IRQs to this CPU */
+    for ( i = 32; i < gic.lines; i += 4 )
+        GICD[GICD_ICFGR + i / 4] = cpumask;
+
+    /* Default priority for global interrupts */
+    for ( i = 32; i < gic.lines; i += 4 )
+        GICD[GICD_IPRIORITYR + i / 4] = 0xa0a0a0a0;
+
+    /* Disable all global interrupts */
+    for ( i = 32; i < gic.lines; i += 32 )
+        GICD[GICD_ICENABLER + i / 32] = ~0ul;
+
+    /* Turn on the distributor */
+    GICD[GICD_CTLR] = GICD_CTL_ENABLE;
+}
+
+static void __cpuinit gic_cpu_init(void)
+{
+    int i;
+
+    /* Disable all PPI and enable all SGI */
+    GICD[GICD_ICENABLER] = 0xffff0000; /* Disable all PPI */
+    GICD[GICD_ISENABLER] = 0x0000ffff; /* Enable all SGI */
+    /* Set PPI and SGI priorities */
+    for (i = 0; i < 32; i += 4)
+        GICD[GICD_IPRIORITYR + i / 4] = 0xa0a0a0a0;
+
+    /* Local settings: interface controller */
+    GICC[GICC_PMR] = 0xff;                /* Don't mask by priority */
+    GICC[GICC_BPR] = 0;                   /* Finest granularity of priority */
+    GICC[GICC_CTLR] = GICC_CTL_ENABLE|GICC_CTL_EOI;    /* Turn on delivery */
+}
+
+static void __cpuinit gic_hyp_init(void)
+{
+    uint32_t vtr;
+
+    vtr = GICH[GICH_VTR];
+    nr_lrs  = (vtr & GICH_VTR_NRLRGS) + 1;
+    printk("GICH: %d list registers available\n", nr_lrs);
+
+    GICH[GICH_HCR] = GICH_HCR_EN;
+    GICH[GICH_MISR] = GICH_MISR_EOI;
+}
+
+/* Set up the GIC */
+void gic_init(void)
+{
+    /* XXX FIXME get this from devicetree */
+    gic.dbase = GIC_BASE_ADDRESS + GIC_DR_OFFSET;
+    gic.cbase = GIC_BASE_ADDRESS + GIC_CR_OFFSET;
+    gic.hbase = GIC_BASE_ADDRESS + GIC_HR_OFFSET;
+    set_fixmap(FIXMAP_GICD, gic.dbase >> PAGE_SHIFT, DEV_SHARED);
+    BUILD_BUG_ON(FIXMAP_ADDR(FIXMAP_GICC1) !=
+                 FIXMAP_ADDR(FIXMAP_GICC2)-PAGE_SIZE);
+    set_fixmap(FIXMAP_GICC1, gic.cbase >> PAGE_SHIFT, DEV_SHARED);
+    set_fixmap(FIXMAP_GICC2, (gic.cbase >> PAGE_SHIFT) + 1, DEV_SHARED);
+    set_fixmap(FIXMAP_GICH, gic.hbase >> PAGE_SHIFT, DEV_SHARED);
+
+    /* Global settings: interrupt distributor */
+    spin_lock_init(&gic.lock);
+    spin_lock(&gic.lock);
+
+    gic_dist_init();
+    gic_cpu_init();
+    gic_hyp_init();
+
+    spin_unlock(&gic.lock);
+}
+
+void gic_route_irqs(void)
+{
+    /* XXX should get these from DT */
+    /* GIC maintenance */
+    gic_route_irq(25, 1, 1u << smp_processor_id(), 0xa0);
+    /* Hypervisor Timer */
+    gic_route_irq(26, 1, 1u << smp_processor_id(), 0xa0);
+    /* Timer */
+    gic_route_irq(30, 1, 1u << smp_processor_id(), 0xa0);
+    /* UART */
+    gic_route_irq(37, 0, 1u << smp_processor_id(), 0xa0);
+}
+
+void __init release_irq(unsigned int irq)
+{
+    struct irq_desc *desc;
+    unsigned long flags;
+   struct irqaction *action;
+
+    desc = irq_to_desc(irq);
+
+    spin_lock_irqsave(&desc->lock,flags);
+    action = desc->action;
+    desc->action  = NULL;
+    desc->status |= IRQ_DISABLED;
+
+    spin_lock(&gic.lock);
+    desc->handler->shutdown(desc);
+    spin_unlock(&gic.lock);
+
+    spin_unlock_irqrestore(&desc->lock,flags);
+
+    /* Wait to make sure it's not being used on another CPU */
+    do { smp_mb(); } while ( desc->status & IRQ_INPROGRESS );
+
+    if (action && action->free_on_release)
+        xfree(action);
+}
+
+static int __setup_irq(struct irq_desc *desc, unsigned int irq,
+                       struct irqaction *new)
+{
+    if ( desc->action != NULL )
+        return -EBUSY;
+
+    desc->action  = new;
+    desc->status &= ~IRQ_DISABLED;
+    dsb();
+
+    desc->handler->startup(desc);
+
+    return 0;
+}
+
+int __init setup_irq(unsigned int irq, struct irqaction *new)
+{
+    int rc;
+    unsigned long flags;
+    struct irq_desc *desc;
+
+    desc = irq_to_desc(irq);
+
+    spin_lock_irqsave(&desc->lock, flags);
+
+    rc = __setup_irq(desc, irq, new);
+
+    spin_unlock_irqrestore(&desc->lock,flags);
+
+    return rc;
+}
+
+void gic_set_guest_irq(unsigned int virtual_irq,
+        unsigned int state, unsigned int priority)
+{
+    BUG_ON(virtual_irq > nr_lrs);
+    GICH[GICH_LR + virtual_irq] = state |
+        GICH_LR_MAINTENANCE_IRQ |
+        ((priority >> 3) << GICH_LR_PRIORITY_SHIFT) |
+        ((virtual_irq & GICH_LR_VIRTUAL_MASK) << GICH_LR_VIRTUAL_SHIFT);
+}
+
+void gic_inject_irq_start(void)
+{
+    uint32_t hcr;
+    hcr = READ_CP32(HCR);
+    WRITE_CP32(hcr | HCR_VI, HCR);
+    isb();
+}
+
+void gic_inject_irq_stop(void)
+{
+    uint32_t hcr;
+    hcr = READ_CP32(HCR);
+    if (hcr & HCR_VI) {
+        WRITE_CP32(hcr & ~HCR_VI, HCR);
+        isb();
+    }
+}
+
+int gic_route_irq_to_guest(struct domain *d, unsigned int irq,
+                           const char * devname)
+{
+    struct irqaction *action;
+    struct irq_desc *desc = irq_to_desc(irq);
+    unsigned long flags;
+    int retval;
+
+    action = xmalloc(struct irqaction);
+    if (!action)
+        return -ENOMEM;
+
+    action->dev_id = d;
+    action->name = devname;
+
+    spin_lock_irqsave(&desc->lock, flags);
+
+    desc->handler = &gic_guest_irq_type;
+    desc->status |= IRQ_GUEST;
+
+    retval = __setup_irq(desc, irq, action);
+    if (retval) {
+        xfree(action);
+        goto out;
+    }
+
+out:
+    spin_unlock_irqrestore(&desc->lock, flags);
+    return retval;
+}
+
+/* Accept an interrupt from the GIC and dispatch its handler */
+void gic_interrupt(struct cpu_user_regs *regs, int is_fiq)
+{
+    uint32_t intack = GICC[GICC_IAR];
+    unsigned int irq = intack & GICC_IA_IRQ;
+
+    if ( irq == 1023 )
+        /* Spurious interrupt */
+        return;
+
+    do_IRQ(regs, irq, is_fiq);
+}
+
+void gicv_setup(struct domain *d)
+{
+    /* map the gic virtual cpu interface in the gic cpu interface region of
+     * the guest */
+    printk("mapping GICC at %#"PRIx32" to %#"PRIx32"\n",
+           GIC_BASE_ADDRESS + GIC_CR_OFFSET,
+           GIC_BASE_ADDRESS + GIC_VR_OFFSET);
+    map_mmio_regions(d, GIC_BASE_ADDRESS + GIC_CR_OFFSET,
+                        GIC_BASE_ADDRESS + GIC_CR_OFFSET + (2 * PAGE_SIZE) - 1,
+                        GIC_BASE_ADDRESS + GIC_VR_OFFSET);
+}
+
+static void maintenance_interrupt(int irq, void *dev_id, struct cpu_user_regs *regs)
+{
+    int i, virq;
+    uint32_t lr;
+    uint64_t eisr = GICH[GICH_EISR0] | (((uint64_t) GICH[GICH_EISR1]) << 32);
+
+    for ( i = 0; i < 64; i++ ) {
+        if ( eisr & ((uint64_t)1 << i) ) {
+            struct pending_irq *p;
+
+            lr = GICH[GICH_LR + i];
+            virq = lr & GICH_LR_VIRTUAL_MASK;
+            GICH[GICH_LR + i] = 0;
+
+            spin_lock(&current->arch.vgic.lock);
+            p = irq_to_pending(current, virq);
+            if ( p->desc != NULL ) {
+                p->desc->status &= ~IRQ_INPROGRESS;
+                GICC[GICC_DIR] = virq;
+            }
+            gic_inject_irq_stop();
+            list_del(&p->link);
+            INIT_LIST_HEAD(&p->link);
+            cpu_raise_softirq(current->processor, VGIC_SOFTIRQ);
+            spin_unlock(&current->arch.vgic.lock);
+        }
+    }
+}
+
+void __cpuinit init_maintenance_interrupt(void)
+{
+    request_irq(25, maintenance_interrupt, 0, "irq-maintenance", NULL);
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/arch/arm/gic.h b/xen/arch/arm/gic.h
new file mode 100644
index 0000000..63b6648
--- /dev/null
+++ b/xen/arch/arm/gic.h
@@ -0,0 +1,151 @@
+/*
+ * xen/arch/arm/gic.h
+ *
+ * ARM Generic Interrupt Controller support
+ *
+ * Tim Deegan <tim@xen.org>
+ * Copyright (c) 2011 Citrix Systems.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#ifndef __ARCH_ARM_GIC_H__
+#define __ARCH_ARM_GIC_H__
+
+#define GICD_CTLR       (0x000/4)
+#define GICD_TYPER      (0x004/4)
+#define GICD_IIDR       (0x008/4)
+#define GICD_IGROUPR    (0x080/4)
+#define GICD_IGROUPRN   (0x0FC/4)
+#define GICD_ISENABLER  (0x100/4)
+#define GICD_ISENABLERN (0x17C/4)
+#define GICD_ICENABLER  (0x180/4)
+#define GICD_ICENABLERN (0x1fC/4)
+#define GICD_ISPENDR    (0x200/4)
+#define GICD_ISPENDRN   (0x27C/4)
+#define GICD_ICPENDR    (0x280/4)
+#define GICD_ICPENDRN   (0x2FC/4)
+#define GICD_ISACTIVER  (0x300/4)
+#define GICD_ISACTIVERN (0x37C/4)
+#define GICD_ICACTIVER  (0x380/4)
+#define GICD_ICACTIVERN (0x3FC/4)
+#define GICD_IPRIORITYR (0x400/4)
+#define GICD_IPRIORITYRN (0x7F8/4)
+#define GICD_ITARGETSR  (0x800/4)
+#define GICD_ITARGETSRN (0xBF8/4)
+#define GICD_ICFGR      (0xC00/4)
+#define GICD_ICFGRN     (0xCFC/4)
+#define GICD_NSACR      (0xE00/4)
+#define GICD_NSACRN     (0xEFC/4)
+#define GICD_ICPIDR2    (0xFE8/4)
+#define GICD_SGIR       (0xF00/4)
+#define GICD_CPENDSGIR  (0xF10/4)
+#define GICD_CPENDSGIRN (0xF1C/4)
+#define GICD_SPENDSGIR  (0xF20/4)
+#define GICD_SPENDSGIRN (0xF2C/4)
+#define GICD_ICPIDR2    (0xFE8/4)
+
+#define GICC_CTLR       (0x0000/4)
+#define GICC_PMR        (0x0004/4)
+#define GICC_BPR        (0x0008/4)
+#define GICC_IAR        (0x000C/4)
+#define GICC_EOIR       (0x0010/4)
+#define GICC_RPR        (0x0014/4)
+#define GICC_HPPIR      (0x0018/4)
+#define GICC_APR        (0x00D0/4)
+#define GICC_NSAPR      (0x00E0/4)
+#define GICC_DIR        (0x1000/4)
+
+#define GICH_HCR        (0x00/4)
+#define GICH_VTR        (0x04/4)
+#define GICH_VMCR       (0x08/4)
+#define GICH_MISR       (0x10/4)
+#define GICH_EISR0      (0x20/4)
+#define GICH_EISR1      (0x24/4)
+#define GICH_ELRSR0     (0x30/4)
+#define GICH_ELRSR1     (0x34/4)
+#define GICH_APR        (0xF0/4)
+#define GICH_LR         (0x100/4)
+
+/* Register bits */
+#define GICD_CTL_ENABLE 0x1
+
+#define GICD_TYPE_LINES 0x01f
+#define GICD_TYPE_CPUS  0x0e0
+#define GICD_TYPE_SEC   0x400
+
+#define GICC_CTL_ENABLE 0x1
+#define GICC_CTL_EOI    (0x1 << 9)
+
+#define GICC_IA_IRQ     0x03ff
+#define GICC_IA_CPU     0x1c00
+
+#define GICH_HCR_EN       (1 << 0)
+#define GICH_HCR_UIE      (1 << 1)
+#define GICH_HCR_LRENPIE  (1 << 2)
+#define GICH_HCR_NPIE     (1 << 3)
+#define GICH_HCR_VGRP0EIE (1 << 4)
+#define GICH_HCR_VGRP0DIE (1 << 5)
+#define GICH_HCR_VGRP1EIE (1 << 6)
+#define GICH_HCR_VGRP1DIE (1 << 7)
+
+#define GICH_MISR_EOI     (1 << 0)
+#define GICH_MISR_U       (1 << 1)
+#define GICH_MISR_LRENP   (1 << 2)
+#define GICH_MISR_NP      (1 << 3)
+#define GICH_MISR_VGRP0E  (1 << 4)
+#define GICH_MISR_VGRP0D  (1 << 5)
+#define GICH_MISR_VGRP1E  (1 << 6)
+#define GICH_MISR_VGRP1D  (1 << 7)
+
+#define GICH_LR_VIRTUAL_MASK    0x3ff
+#define GICH_LR_VIRTUAL_SHIFT   0
+#define GICH_LR_PHYSICAL_MASK   0x3ff
+#define GICH_LR_PHYSICAL_SHIFT  10
+#define GICH_LR_STATE_MASK      0x3
+#define GICH_LR_STATE_SHIFT     28
+#define GICH_LR_PRIORITY_SHIFT  23
+#define GICH_LR_MAINTENANCE_IRQ (1<<19)
+#define GICH_LR_PENDING         (1<<28)
+#define GICH_LR_ACTIVE          (1<<29)
+#define GICH_LR_GRP1            (1<<30)
+#define GICH_LR_HW              (1<<31)
+#define GICH_LR_CPUID_SHIFT     9
+#define GICH_VTR_NRLRGS         0x3f
+
+extern struct pending_irq *irq_to_pending(struct vcpu *v, unsigned int irq);
+
+extern void gic_route_irqs(void);
+
+extern void __cpuinit init_maintenance_interrupt(void);
+extern void gic_set_guest_irq(unsigned int irq,
+        unsigned int state, unsigned int priority);
+extern void gic_inject_irq_start(void);
+extern void gic_inject_irq_stop(void);
+extern int gic_route_irq_to_guest(struct domain *d, unsigned int irq,
+                                  const char * devname);
+
+/* Accept an interrupt from the GIC and dispatch its handler */
+extern void gic_interrupt(struct cpu_user_regs *regs, int is_fiq);
+/* Bring up the interrupt controller */
+extern void gic_init(void);
+/* setup the gic virtual interface for a guest */
+extern void gicv_setup(struct domain *d);
+#endif
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 16:29:27 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 16:29:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbEBR-0002Ch-9L; Thu, 15 Dec 2011 16:29:25 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RbEBP-000253-Fr
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 16:29:23 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1323966553!7437895!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjE2NDg=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9484 invoked from network); 15 Dec 2011 16:29:17 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 16:29:17 -0000
X-IronPort-AV: E=Sophos;i="4.71,357,1320642000"; d="scan'208";a="174308232"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Dec 2011 11:29:16 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Thu, 15 Dec 2011 11:29:15 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pBFGSMth003330;
	Thu, 15 Dec 2011 08:29:03 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Thu, 15 Dec 2011 16:30:51 +0000
Message-ID: <1323966657-19790-19-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1112131831560.3517@kaball-desktop>
References: <alpine.DEB.2.00.1112131831560.3517@kaball-desktop>
MIME-Version: 1.0
Cc: keir.xen@gmail.com, Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, JBeulich@suse.com,
	Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v3 19/25] arm: early setup code
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
---
 xen/arch/arm/setup.c |  206 ++++++++++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 206 insertions(+), 0 deletions(-)
 create mode 100644 xen/arch/arm/setup.c

diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
new file mode 100644
index 0000000..33c880e
--- /dev/null
+++ b/xen/arch/arm/setup.c
@@ -0,0 +1,206 @@
+/*
+ * xen/arch/arm/setup.c
+ *
+ * Early bringup code for an ARMv7-A with virt extensions.
+ *
+ * Tim Deegan <tim@xen.org>
+ * Copyright (c) 2011 Citrix Systems.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include <xen/config.h>
+#include <xen/compile.h>
+#include <xen/domain_page.h>
+#include <xen/types.h>
+#include <xen/string.h>
+#include <xen/serial.h>
+#include <xen/sched.h>
+#include <xen/console.h>
+#include <xen/init.h>
+#include <xen/irq.h>
+#include <xen/mm.h>
+#include <xen/softirq.h>
+#include <xen/keyhandler.h>
+#include <xen/cpu.h>
+#include <asm/page.h>
+#include <asm/current.h>
+#include <asm/setup.h>
+#include "gic.h"
+
+/* maxcpus: maximum number of CPUs to activate. */
+static unsigned int __initdata max_cpus = NR_CPUS;
+
+/* Xen stack for bringing up the first CPU. */
+unsigned char init_stack[STACK_SIZE] __attribute__((__aligned__(STACK_SIZE)));
+
+extern char __init_begin[], __init_end[], __bss_start[];
+
+static __attribute_used__ void init_done(void)
+{
+	/* TODO: free (or page-protect) the init areas.
+	   memset(__init_begin, 0xcc, __init_end - __init_begin);
+	   free_xen_data(__init_begin, __init_end);
+	*/
+    printk("Freed %ldkB init memory.\n", (long)(__init_end-__init_begin)>>10);
+
+    startup_cpu_idle_loop();
+}
+
+static void __init init_idle_domain(void)
+{
+        scheduler_init();
+        set_current(idle_vcpu[0]);
+        this_cpu(curr_vcpu) = current;
+        /* TODO: setup_idle_pagetable(); */
+}
+
+void __init start_xen(unsigned long boot_phys_offset,
+                      unsigned long arm_type,
+                      unsigned long atag_paddr)
+
+{
+    int i;
+
+    setup_pagetables(boot_phys_offset);
+
+#ifdef EARLY_UART_ADDRESS
+    /* Map the UART */
+    /* TODO Need to get device tree or command line for UART address */
+    set_fixmap(FIXMAP_CONSOLE, EARLY_UART_ADDRESS >> PAGE_SHIFT, DEV_SHARED);
+    pl011_init(0, FIXMAP_ADDR(FIXMAP_CONSOLE));
+    console_init_preirq();
+#endif
+
+    set_current((struct vcpu *)0xfffff000); /* debug sanity */
+    idle_vcpu[0] = current;
+    set_processor_id(0); /* needed early, for smp_processor_id() */
+
+    /* TODO: smp_prepare_boot_cpu(void) */
+    cpumask_set_cpu(smp_processor_id(), &cpu_online_map);
+    cpumask_set_cpu(smp_processor_id(), &cpu_present_map);
+
+    smp_prepare_cpus(max_cpus);
+
+    init_xen_time();
+
+    /* TODO: This needs some thought, as well as device-tree mapping.
+     * For testing, assume that the whole xenheap is contiguous in RAM */
+    setup_xenheap_mappings(0x8000000, 0x40000); /* 1 GB @ 512GB */
+    /* Must pass a single mapped page for populating bootmem_region_list. */
+    init_boot_pages(pfn_to_paddr(xenheap_mfn_start),
+                    pfn_to_paddr(xenheap_mfn_start+1));
+
+    /* Add non-xenheap memory */
+    init_boot_pages(0x8040000000, 0x80c0000000); /* 2 GB @513GB */
+
+    /* TODO Make sure Xen's own pages aren't added
+     *     -- the memory above doesn't include our relocation target.  */
+    /* TODO Handle payloads too */
+
+    /* TODO Need to find actual memory, for now use 4GB at 512GB */
+    setup_frametable_mappings(0x8000000000ULL, 0x8100000000UL);
+
+    /* Add xenheap memory */
+    init_xenheap_pages(pfn_to_paddr(xenheap_mfn_start+1),
+                       pfn_to_paddr(xenheap_mfn_end));
+
+    end_boot_allocator();
+
+    /* Setup Hyp vector base */
+    WRITE_CP32((uint32_t) hyp_traps_vector, HVBAR);
+    printk("Set hyp vector base to %"PRIx32" (expected %p)\n",
+           READ_CP32(HVBAR), hyp_traps_vector);
+
+    /* Setup Stage 2 address translation */
+    /* SH0=00, ORGN0=IRGN0=01
+     * SL0=01 (Level-1)
+     * T0SZ=(1)1000 = -8 (40 bit physical addresses)
+     */
+    WRITE_CP32(0x80002558, VTCR); isb();
+
+    softirq_init();
+    tasklet_subsys_init();
+
+    init_IRQ();
+
+    gic_init();
+
+    gic_route_irqs();
+
+    init_maintenance_interrupt();
+    init_timer_interrupt();
+
+    timer_init();
+
+    init_idle_domain();
+
+    rcu_init();
+
+    local_irq_enable();
+
+    initialize_keytable();
+
+    console_init_postirq();
+
+    do_presmp_initcalls();
+
+    for_each_present_cpu ( i )
+    {
+        if ( (num_online_cpus() < max_cpus) && !cpu_online(i) )
+        {
+            int ret = cpu_up(i);
+            if ( ret != 0 )
+                printk("Failed to bring up CPU %u (error %d)\n", i, ret);
+        }
+    }
+
+    printk("Brought up %ld CPUs\n", (long)num_online_cpus());
+    /* TODO: smp_cpus_done(); */
+
+    do_initcalls();
+
+    /* Create initial domain 0. */
+    dom0 = domain_create(0, 0, 0);
+    if ( dom0 == NULL )
+            printk("domain_create failed\n");
+    if ( (dom0 == NULL) || (alloc_dom0_vcpu0() == NULL) )
+            panic("Error creating domain 0\n");
+
+    dom0->is_privileged = 1;
+    dom0->target = NULL;
+
+    if ( construct_dom0(dom0) != 0)
+            panic("Could not set up DOM0 guest OS\n");
+
+    /* Scrub RAM that is still free and so may go to an unprivileged domain.
+       XXX too slow in simulator
+       scrub_heap_pages();
+    */
+
+    console_endboot();
+
+    /* Hide UART from DOM0 if we're using it */
+    serial_endboot();
+
+    domain_unpause_by_systemcontroller(dom0);
+
+    reset_stack_and_jump(init_done);
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 16:29:27 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 16:29:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbEBR-0002Ch-9L; Thu, 15 Dec 2011 16:29:25 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RbEBP-000253-Fr
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 16:29:23 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1323966553!7437895!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjE2NDg=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9484 invoked from network); 15 Dec 2011 16:29:17 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 16:29:17 -0000
X-IronPort-AV: E=Sophos;i="4.71,357,1320642000"; d="scan'208";a="174308232"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Dec 2011 11:29:16 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Thu, 15 Dec 2011 11:29:15 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pBFGSMth003330;
	Thu, 15 Dec 2011 08:29:03 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Thu, 15 Dec 2011 16:30:51 +0000
Message-ID: <1323966657-19790-19-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1112131831560.3517@kaball-desktop>
References: <alpine.DEB.2.00.1112131831560.3517@kaball-desktop>
MIME-Version: 1.0
Cc: keir.xen@gmail.com, Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, JBeulich@suse.com,
	Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v3 19/25] arm: early setup code
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
---
 xen/arch/arm/setup.c |  206 ++++++++++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 206 insertions(+), 0 deletions(-)
 create mode 100644 xen/arch/arm/setup.c

diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
new file mode 100644
index 0000000..33c880e
--- /dev/null
+++ b/xen/arch/arm/setup.c
@@ -0,0 +1,206 @@
+/*
+ * xen/arch/arm/setup.c
+ *
+ * Early bringup code for an ARMv7-A with virt extensions.
+ *
+ * Tim Deegan <tim@xen.org>
+ * Copyright (c) 2011 Citrix Systems.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include <xen/config.h>
+#include <xen/compile.h>
+#include <xen/domain_page.h>
+#include <xen/types.h>
+#include <xen/string.h>
+#include <xen/serial.h>
+#include <xen/sched.h>
+#include <xen/console.h>
+#include <xen/init.h>
+#include <xen/irq.h>
+#include <xen/mm.h>
+#include <xen/softirq.h>
+#include <xen/keyhandler.h>
+#include <xen/cpu.h>
+#include <asm/page.h>
+#include <asm/current.h>
+#include <asm/setup.h>
+#include "gic.h"
+
+/* maxcpus: maximum number of CPUs to activate. */
+static unsigned int __initdata max_cpus = NR_CPUS;
+
+/* Xen stack for bringing up the first CPU. */
+unsigned char init_stack[STACK_SIZE] __attribute__((__aligned__(STACK_SIZE)));
+
+extern char __init_begin[], __init_end[], __bss_start[];
+
+static __attribute_used__ void init_done(void)
+{
+	/* TODO: free (or page-protect) the init areas.
+	   memset(__init_begin, 0xcc, __init_end - __init_begin);
+	   free_xen_data(__init_begin, __init_end);
+	*/
+    printk("Freed %ldkB init memory.\n", (long)(__init_end-__init_begin)>>10);
+
+    startup_cpu_idle_loop();
+}
+
+static void __init init_idle_domain(void)
+{
+        scheduler_init();
+        set_current(idle_vcpu[0]);
+        this_cpu(curr_vcpu) = current;
+        /* TODO: setup_idle_pagetable(); */
+}
+
+void __init start_xen(unsigned long boot_phys_offset,
+                      unsigned long arm_type,
+                      unsigned long atag_paddr)
+
+{
+    int i;
+
+    setup_pagetables(boot_phys_offset);
+
+#ifdef EARLY_UART_ADDRESS
+    /* Map the UART */
+    /* TODO Need to get device tree or command line for UART address */
+    set_fixmap(FIXMAP_CONSOLE, EARLY_UART_ADDRESS >> PAGE_SHIFT, DEV_SHARED);
+    pl011_init(0, FIXMAP_ADDR(FIXMAP_CONSOLE));
+    console_init_preirq();
+#endif
+
+    set_current((struct vcpu *)0xfffff000); /* debug sanity */
+    idle_vcpu[0] = current;
+    set_processor_id(0); /* needed early, for smp_processor_id() */
+
+    /* TODO: smp_prepare_boot_cpu(void) */
+    cpumask_set_cpu(smp_processor_id(), &cpu_online_map);
+    cpumask_set_cpu(smp_processor_id(), &cpu_present_map);
+
+    smp_prepare_cpus(max_cpus);
+
+    init_xen_time();
+
+    /* TODO: This needs some thought, as well as device-tree mapping.
+     * For testing, assume that the whole xenheap is contiguous in RAM */
+    setup_xenheap_mappings(0x8000000, 0x40000); /* 1 GB @ 512GB */
+    /* Must pass a single mapped page for populating bootmem_region_list. */
+    init_boot_pages(pfn_to_paddr(xenheap_mfn_start),
+                    pfn_to_paddr(xenheap_mfn_start+1));
+
+    /* Add non-xenheap memory */
+    init_boot_pages(0x8040000000, 0x80c0000000); /* 2 GB @513GB */
+
+    /* TODO Make sure Xen's own pages aren't added
+     *     -- the memory above doesn't include our relocation target.  */
+    /* TODO Handle payloads too */
+
+    /* TODO Need to find actual memory, for now use 4GB at 512GB */
+    setup_frametable_mappings(0x8000000000ULL, 0x8100000000UL);
+
+    /* Add xenheap memory */
+    init_xenheap_pages(pfn_to_paddr(xenheap_mfn_start+1),
+                       pfn_to_paddr(xenheap_mfn_end));
+
+    end_boot_allocator();
+
+    /* Setup Hyp vector base */
+    WRITE_CP32((uint32_t) hyp_traps_vector, HVBAR);
+    printk("Set hyp vector base to %"PRIx32" (expected %p)\n",
+           READ_CP32(HVBAR), hyp_traps_vector);
+
+    /* Setup Stage 2 address translation */
+    /* SH0=00, ORGN0=IRGN0=01
+     * SL0=01 (Level-1)
+     * T0SZ=(1)1000 = -8 (40 bit physical addresses)
+     */
+    WRITE_CP32(0x80002558, VTCR); isb();
+
+    softirq_init();
+    tasklet_subsys_init();
+
+    init_IRQ();
+
+    gic_init();
+
+    gic_route_irqs();
+
+    init_maintenance_interrupt();
+    init_timer_interrupt();
+
+    timer_init();
+
+    init_idle_domain();
+
+    rcu_init();
+
+    local_irq_enable();
+
+    initialize_keytable();
+
+    console_init_postirq();
+
+    do_presmp_initcalls();
+
+    for_each_present_cpu ( i )
+    {
+        if ( (num_online_cpus() < max_cpus) && !cpu_online(i) )
+        {
+            int ret = cpu_up(i);
+            if ( ret != 0 )
+                printk("Failed to bring up CPU %u (error %d)\n", i, ret);
+        }
+    }
+
+    printk("Brought up %ld CPUs\n", (long)num_online_cpus());
+    /* TODO: smp_cpus_done(); */
+
+    do_initcalls();
+
+    /* Create initial domain 0. */
+    dom0 = domain_create(0, 0, 0);
+    if ( dom0 == NULL )
+            printk("domain_create failed\n");
+    if ( (dom0 == NULL) || (alloc_dom0_vcpu0() == NULL) )
+            panic("Error creating domain 0\n");
+
+    dom0->is_privileged = 1;
+    dom0->target = NULL;
+
+    if ( construct_dom0(dom0) != 0)
+            panic("Could not set up DOM0 guest OS\n");
+
+    /* Scrub RAM that is still free and so may go to an unprivileged domain.
+       XXX too slow in simulator
+       scrub_heap_pages();
+    */
+
+    console_endboot();
+
+    /* Hide UART from DOM0 if we're using it */
+    serial_endboot();
+
+    domain_unpause_by_systemcontroller(dom0);
+
+    reset_stack_and_jump(init_done);
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 16:29:28 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 16: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.xensource.com>)
	id 1RbEBT-0002G1-71; Thu, 15 Dec 2011 16:29:27 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RbEBQ-000263-LU
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 16:29:25 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1323966500!60916191!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDY5Mjg=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17608 invoked from network); 15 Dec 2011 16:28:23 -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;
	15 Dec 2011 16:28:23 -0000
X-IronPort-AV: E=Sophos;i="4.71,357,1320642000"; d="scan'208";a="20001868"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Dec 2011 11:29:16 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Thu, 15 Dec 2011 11:29:02 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pBFGSMtX003330;
	Thu, 15 Dec 2011 08:28:45 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Thu, 15 Dec 2011 16:30:41 +0000
Message-ID: <1323966657-19790-9-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1112131831560.3517@kaball-desktop>
References: <alpine.DEB.2.00.1112131831560.3517@kaball-desktop>
MIME-Version: 1.0
Cc: keir.xen@gmail.com, Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, JBeulich@suse.com,
	Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v3 09/25] arm: header files
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

A simple implementation of everything under asm-arm and arch-arm.h; some
of these files are shamelessly taken from Linux.


Changes in v2:

- remove div64.


Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
---
 xen/include/asm-arm/atomic.h      |  212 +++++++++++++++++++++++++++++
 xen/include/asm-arm/bitops.h      |  195 +++++++++++++++++++++++++++
 xen/include/asm-arm/bug.h         |   15 ++
 xen/include/asm-arm/byteorder.h   |   16 +++
 xen/include/asm-arm/cache.h       |   20 +++
 xen/include/asm-arm/config.h      |  122 +++++++++++++++++
 xen/include/asm-arm/cpregs.h      |  207 ++++++++++++++++++++++++++++
 xen/include/asm-arm/current.h     |   60 ++++++++
 xen/include/asm-arm/debugger.h    |   15 ++
 xen/include/asm-arm/delay.h       |   15 ++
 xen/include/asm-arm/desc.h        |   12 ++
 xen/include/asm-arm/div64.h       |  235 ++++++++++++++++++++++++++++++++
 xen/include/asm-arm/elf.h         |   33 +++++
 xen/include/asm-arm/event.h       |   41 ++++++
 xen/include/asm-arm/flushtlb.h    |   31 +++++
 xen/include/asm-arm/grant_table.h |   35 +++++
 xen/include/asm-arm/hardirq.h     |   28 ++++
 xen/include/asm-arm/hypercall.h   |   24 ++++
 xen/include/asm-arm/init.h        |   12 ++
 xen/include/asm-arm/io.h          |   12 ++
 xen/include/asm-arm/iocap.h       |   20 +++
 xen/include/asm-arm/multicall.h   |   23 +++
 xen/include/asm-arm/nmi.h         |   15 ++
 xen/include/asm-arm/numa.h        |   21 +++
 xen/include/asm-arm/paging.h      |   13 ++
 xen/include/asm-arm/percpu.h      |   28 ++++
 xen/include/asm-arm/processor.h   |  269 +++++++++++++++++++++++++++++++++++++
 xen/include/asm-arm/regs.h        |   43 ++++++
 xen/include/asm-arm/setup.h       |   16 +++
 xen/include/asm-arm/smp.h         |   25 ++++
 xen/include/asm-arm/softirq.h     |   15 ++
 xen/include/asm-arm/spinlock.h    |  144 ++++++++++++++++++++
 xen/include/asm-arm/string.h      |   38 +++++
 xen/include/asm-arm/system.h      |  202 ++++++++++++++++++++++++++++
 xen/include/asm-arm/trace.h       |   12 ++
 xen/include/asm-arm/types.h       |   57 ++++++++
 xen/include/asm-arm/xenoprof.h    |   12 ++
 xen/include/public/arch-arm.h     |  125 +++++++++++++++++
 xen/include/public/xen.h          |    2 +
 39 files changed, 2420 insertions(+), 0 deletions(-)
 create mode 100644 xen/include/asm-arm/atomic.h
 create mode 100644 xen/include/asm-arm/bitops.h
 create mode 100644 xen/include/asm-arm/bug.h
 create mode 100644 xen/include/asm-arm/byteorder.h
 create mode 100644 xen/include/asm-arm/cache.h
 create mode 100644 xen/include/asm-arm/config.h
 create mode 100644 xen/include/asm-arm/cpregs.h
 create mode 100644 xen/include/asm-arm/current.h
 create mode 100644 xen/include/asm-arm/debugger.h
 create mode 100644 xen/include/asm-arm/delay.h
 create mode 100644 xen/include/asm-arm/desc.h
 create mode 100644 xen/include/asm-arm/div64.h
 create mode 100644 xen/include/asm-arm/elf.h
 create mode 100644 xen/include/asm-arm/event.h
 create mode 100644 xen/include/asm-arm/flushtlb.h
 create mode 100644 xen/include/asm-arm/grant_table.h
 create mode 100644 xen/include/asm-arm/hardirq.h
 create mode 100644 xen/include/asm-arm/hypercall.h
 create mode 100644 xen/include/asm-arm/init.h
 create mode 100644 xen/include/asm-arm/io.h
 create mode 100644 xen/include/asm-arm/iocap.h
 create mode 100644 xen/include/asm-arm/multicall.h
 create mode 100644 xen/include/asm-arm/nmi.h
 create mode 100644 xen/include/asm-arm/numa.h
 create mode 100644 xen/include/asm-arm/paging.h
 create mode 100644 xen/include/asm-arm/percpu.h
 create mode 100644 xen/include/asm-arm/processor.h
 create mode 100644 xen/include/asm-arm/regs.h
 create mode 100644 xen/include/asm-arm/setup.h
 create mode 100644 xen/include/asm-arm/smp.h
 create mode 100644 xen/include/asm-arm/softirq.h
 create mode 100644 xen/include/asm-arm/spinlock.h
 create mode 100644 xen/include/asm-arm/string.h
 create mode 100644 xen/include/asm-arm/system.h
 create mode 100644 xen/include/asm-arm/trace.h
 create mode 100644 xen/include/asm-arm/types.h
 create mode 100644 xen/include/asm-arm/xenoprof.h
 create mode 100644 xen/include/public/arch-arm.h

diff --git a/xen/include/asm-arm/atomic.h b/xen/include/asm-arm/atomic.h
new file mode 100644
index 0000000..2b9ce0e
--- /dev/null
+++ b/xen/include/asm-arm/atomic.h
@@ -0,0 +1,212 @@
+/*
+ *  arch/arm/include/asm/atomic.h
+ *
+ *  Copyright (C) 1996 Russell King.
+ *  Copyright (C) 2002 Deep Blue Solutions Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#ifndef __ARCH_ARM_ATOMIC__
+#define __ARCH_ARM_ATOMIC__
+
+#include <xen/config.h>
+#include <asm/system.h>
+
+#define build_atomic_read(name, size, type, reg)   \
+static inline type name(const volatile type *addr) \
+{                                                  \
+    type ret;                                      \
+    asm volatile("ldr" size " %0,%1"               \
+                 : reg (ret)                       \
+                 : "m" (*(volatile type *)addr));  \
+    return ret;                                    \
+}
+
+#define build_atomic_write(name, size, type, reg)      \
+static inline void name(volatile type *addr, type val) \
+{                                                      \
+    asm volatile("str" size " %1,%0"                   \
+                 : "=m" (*(volatile type *)addr)       \
+                 : reg (val));                         \
+}
+
+build_atomic_read(atomic_read8, "b", uint8_t, "=q")
+build_atomic_read(atomic_read16, "h", uint16_t, "=r")
+build_atomic_read(atomic_read32, "", uint32_t, "=r")
+//build_atomic_read(atomic_read64, "d", uint64_t, "=r")
+build_atomic_read(atomic_read_int, "", int, "=r")
+
+build_atomic_write(atomic_write8, "b", uint8_t, "q")
+build_atomic_write(atomic_write16, "h", uint16_t, "r")
+build_atomic_write(atomic_write32, "", uint32_t, "r")
+//build_atomic_write(atomic_write64, "d", uint64_t, "r")
+build_atomic_write(atomic_write_int, "", int, "r")
+
+/*
+ * NB. I've pushed the volatile qualifier into the operations. This allows
+ * fast accessors such as _atomic_read() and _atomic_set() which don't give
+ * the compiler a fit.
+ */
+typedef struct { int counter; } atomic_t;
+
+#define ATOMIC_INIT(i) { (i) }
+
+/*
+ * On ARM, ordinary assignment (str instruction) doesn't clear the local
+ * strex/ldrex monitor on some implementations. The reason we can use it for
+ * atomic_set() is the clrex or dummy strex done on every exception return.
+ */
+#define _atomic_read(v) ((v).counter)
+#define atomic_read(v)  (*(volatile int *)&(v)->counter)
+
+#define _atomic_set(v,i) (((v).counter) = (i))
+#define atomic_set(v,i) (((v)->counter) = (i))
+
+/*
+ * ARMv6 UP and SMP safe atomic ops.  We use load exclusive and
+ * store exclusive to ensure that these are atomic.  We may loop
+ * to ensure that the update happens.
+ */
+static inline void atomic_add(int i, atomic_t *v)
+{
+        unsigned long tmp;
+        int result;
+
+        __asm__ __volatile__("@ atomic_add\n"
+"1:     ldrex   %0, [%3]\n"
+"       add     %0, %0, %4\n"
+"       strex   %1, %0, [%3]\n"
+"       teq     %1, #0\n"
+"       bne     1b"
+        : "=&r" (result), "=&r" (tmp), "+Qo" (v->counter)
+        : "r" (&v->counter), "Ir" (i)
+        : "cc");
+}
+
+static inline int atomic_add_return(int i, atomic_t *v)
+{
+        unsigned long tmp;
+        int result;
+
+        smp_mb();
+
+        __asm__ __volatile__("@ atomic_add_return\n"
+"1:     ldrex   %0, [%3]\n"
+"       add     %0, %0, %4\n"
+"       strex   %1, %0, [%3]\n"
+"       teq     %1, #0\n"
+"       bne     1b"
+        : "=&r" (result), "=&r" (tmp), "+Qo" (v->counter)
+        : "r" (&v->counter), "Ir" (i)
+        : "cc");
+
+        smp_mb();
+
+        return result;
+}
+
+static inline void atomic_sub(int i, atomic_t *v)
+{
+        unsigned long tmp;
+        int result;
+
+        __asm__ __volatile__("@ atomic_sub\n"
+"1:     ldrex   %0, [%3]\n"
+"       sub     %0, %0, %4\n"
+"       strex   %1, %0, [%3]\n"
+"       teq     %1, #0\n"
+"       bne     1b"
+        : "=&r" (result), "=&r" (tmp), "+Qo" (v->counter)
+        : "r" (&v->counter), "Ir" (i)
+        : "cc");
+}
+
+static inline int atomic_sub_return(int i, atomic_t *v)
+{
+        unsigned long tmp;
+        int result;
+
+        smp_mb();
+
+        __asm__ __volatile__("@ atomic_sub_return\n"
+"1:     ldrex   %0, [%3]\n"
+"       sub     %0, %0, %4\n"
+"       strex   %1, %0, [%3]\n"
+"       teq     %1, #0\n"
+"       bne     1b"
+        : "=&r" (result), "=&r" (tmp), "+Qo" (v->counter)
+        : "r" (&v->counter), "Ir" (i)
+        : "cc");
+
+        smp_mb();
+
+        return result;
+}
+
+static inline int atomic_cmpxchg(atomic_t *ptr, int old, int new)
+{
+        unsigned long oldval, res;
+
+        smp_mb();
+
+        do {
+                __asm__ __volatile__("@ atomic_cmpxchg\n"
+                "ldrex  %1, [%3]\n"
+                "mov    %0, #0\n"
+                "teq    %1, %4\n"
+                "strexeq %0, %5, [%3]\n"
+                    : "=&r" (res), "=&r" (oldval), "+Qo" (ptr->counter)
+                    : "r" (&ptr->counter), "Ir" (old), "r" (new)
+                    : "cc");
+        } while (res);
+
+        smp_mb();
+
+        return oldval;
+}
+
+static inline void atomic_clear_mask(unsigned long mask, unsigned long *addr)
+{
+        unsigned long tmp, tmp2;
+
+        __asm__ __volatile__("@ atomic_clear_mask\n"
+"1:     ldrex   %0, [%3]\n"
+"       bic     %0, %0, %4\n"
+"       strex   %1, %0, [%3]\n"
+"       teq     %1, #0\n"
+"       bne     1b"
+        : "=&r" (tmp), "=&r" (tmp2), "+Qo" (*addr)
+        : "r" (addr), "Ir" (mask)
+        : "cc");
+}
+
+#define atomic_inc(v)           atomic_add(1, v)
+#define atomic_dec(v)           atomic_sub(1, v)
+
+#define atomic_inc_and_test(v)  (atomic_add_return(1, v) == 0)
+#define atomic_dec_and_test(v)  (atomic_sub_return(1, v) == 0)
+#define atomic_inc_return(v)    (atomic_add_return(1, v))
+#define atomic_dec_return(v)    (atomic_sub_return(1, v))
+#define atomic_sub_and_test(i, v) (atomic_sub_return(i, v) == 0)
+
+#define atomic_add_negative(i,v) (atomic_add_return(i, v) < 0)
+
+static inline atomic_t atomic_compareandswap(
+    atomic_t old, atomic_t new, atomic_t *v)
+{
+    atomic_t rc;
+    rc.counter = __cmpxchg(&v->counter, old.counter, new.counter, sizeof(int));
+    return rc;
+}
+
+#endif /* __ARCH_ARM_ATOMIC__ */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/bitops.h b/xen/include/asm-arm/bitops.h
new file mode 100644
index 0000000..3d6b30b
--- /dev/null
+++ b/xen/include/asm-arm/bitops.h
@@ -0,0 +1,195 @@
+/*
+ * Copyright 1995, Russell King.
+ * Various bits and pieces copyrights include:
+ *  Linus Torvalds (test_bit).
+ * Big endian support: Copyright 2001, Nicolas Pitre
+ *  reworked by rmk.
+ */
+
+#ifndef _ARM_BITOPS_H
+#define _ARM_BITOPS_H
+
+extern void _set_bit(int nr, volatile void * p);
+extern void _clear_bit(int nr, volatile void * p);
+extern void _change_bit(int nr, volatile void * p);
+extern int _test_and_set_bit(int nr, volatile void * p);
+extern int _test_and_clear_bit(int nr, volatile void * p);
+extern int _test_and_change_bit(int nr, volatile void * p);
+
+#define set_bit(n,p)              _set_bit(n,p)
+#define clear_bit(n,p)            _clear_bit(n,p)
+#define change_bit(n,p)           _change_bit(n,p)
+#define test_and_set_bit(n,p)     _test_and_set_bit(n,p)
+#define test_and_clear_bit(n,p)   _test_and_clear_bit(n,p)
+#define test_and_change_bit(n,p)  _test_and_change_bit(n,p)
+
+#define BIT(nr)                 (1UL << (nr))
+#define BIT_MASK(nr)            (1UL << ((nr) % BITS_PER_LONG))
+#define BIT_WORD(nr)            ((nr) / BITS_PER_LONG)
+#define BITS_PER_BYTE           8
+
+#define ADDR (*(volatile long *) addr)
+#define CONST_ADDR (*(const volatile long *) addr)
+
+/**
+ * __test_and_set_bit - Set a bit and return its old value
+ * @nr: Bit to set
+ * @addr: Address to count from
+ *
+ * This operation is non-atomic and can be reordered.
+ * If two examples of this operation race, one can appear to succeed
+ * but actually fail.  You must protect multiple accesses with a lock.
+ */
+static inline int __test_and_set_bit(int nr, volatile void *addr)
+{
+        unsigned long mask = BIT_MASK(nr);
+        volatile unsigned long *p =
+                ((volatile unsigned long *)addr) + BIT_WORD(nr);
+        unsigned long old = *p;
+
+        *p = old | mask;
+        return (old & mask) != 0;
+}
+
+/**
+ * __test_and_clear_bit - Clear a bit and return its old value
+ * @nr: Bit to clear
+ * @addr: Address to count from
+ *
+ * This operation is non-atomic and can be reordered.
+ * If two examples of this operation race, one can appear to succeed
+ * but actually fail.  You must protect multiple accesses with a lock.
+ */
+static inline int __test_and_clear_bit(int nr, volatile void *addr)
+{
+        unsigned long mask = BIT_MASK(nr);
+        volatile unsigned long *p =
+                ((volatile unsigned long *)addr) + BIT_WORD(nr);
+        unsigned long old = *p;
+
+        *p = old & ~mask;
+        return (old & mask) != 0;
+}
+
+/* WARNING: non atomic and it can be reordered! */
+static inline int __test_and_change_bit(int nr,
+                                            volatile void *addr)
+{
+        unsigned long mask = BIT_MASK(nr);
+        volatile unsigned long *p =
+                ((volatile unsigned long *)addr) + BIT_WORD(nr);
+        unsigned long old = *p;
+
+        *p = old ^ mask;
+        return (old & mask) != 0;
+}
+
+/**
+ * test_bit - Determine whether a bit is set
+ * @nr: bit number to test
+ * @addr: Address to start counting from
+ */
+static inline int test_bit(int nr, const volatile void *addr)
+{
+        const volatile unsigned long *p = (const volatile unsigned long *)addr;
+        return 1UL & (p[BIT_WORD(nr)] >> (nr & (BITS_PER_LONG-1)));
+}
+
+
+extern unsigned int _find_first_bit(
+    const unsigned long *addr, unsigned int size);
+extern unsigned int _find_next_bit(
+    const unsigned long *addr, unsigned int size, unsigned int offset);
+extern unsigned int _find_first_zero_bit(
+    const unsigned long *addr, unsigned int size);
+extern unsigned int _find_next_zero_bit(
+    const unsigned long *addr, unsigned int size, unsigned int offset);
+
+/*
+ * These are the little endian, atomic definitions.
+ */
+#define find_first_zero_bit(p,sz)       _find_first_zero_bit(p,sz)
+#define find_next_zero_bit(p,sz,off)    _find_next_zero_bit(p,sz,off)
+#define find_first_bit(p,sz)            _find_first_bit(p,sz)
+#define find_next_bit(p,sz,off)         _find_next_bit(p,sz,off)
+
+static inline int constant_fls(int x)
+{
+        int r = 32;
+
+        if (!x)
+                return 0;
+        if (!(x & 0xffff0000u)) {
+                x <<= 16;
+                r -= 16;
+        }
+        if (!(x & 0xff000000u)) {
+                x <<= 8;
+                r -= 8;
+        }
+        if (!(x & 0xf0000000u)) {
+                x <<= 4;
+                r -= 4;
+        }
+        if (!(x & 0xc0000000u)) {
+                x <<= 2;
+                r -= 2;
+        }
+        if (!(x & 0x80000000u)) {
+                x <<= 1;
+                r -= 1;
+        }
+        return r;
+}
+
+/*
+ * On ARMv5 and above those functions can be implemented around
+ * the clz instruction for much better code efficiency.
+ */
+
+static inline int fls(int x)
+{
+        int ret;
+
+        if (__builtin_constant_p(x))
+               return constant_fls(x);
+
+        asm("clz\t%0, %1" : "=r" (ret) : "r" (x));
+        ret = 32 - ret;
+        return ret;
+}
+
+#define ffs(x) ({ unsigned long __t = (x); fls(__t & -__t); })
+
+/**
+ * find_first_set_bit - find the first set bit in @word
+ * @word: the word to search
+ *
+ * Returns the bit-number of the first set bit (first bit being 0).
+ * The input must *not* be zero.
+ */
+static inline unsigned int find_first_set_bit(unsigned long word)
+{
+        return ffs(word) - 1;
+}
+
+/**
+ * hweightN - returns the hamming weight of a N-bit word
+ * @x: the word to weigh
+ *
+ * The Hamming Weight of a number is the total number of bits set in it.
+ */
+#define hweight64(x) generic_hweight64(x)
+#define hweight32(x) generic_hweight32(x)
+#define hweight16(x) generic_hweight16(x)
+#define hweight8(x) generic_hweight8(x)
+
+#endif /* _ARM_BITOPS_H */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/bug.h b/xen/include/asm-arm/bug.h
new file mode 100644
index 0000000..bc2532c
--- /dev/null
+++ b/xen/include/asm-arm/bug.h
@@ -0,0 +1,15 @@
+#ifndef __ARM_BUG_H__
+#define __ARM_BUG_H__
+
+#define BUG() __bug(__FILE__, __LINE__)
+#define WARN() __warn(__FILE__, __LINE__)
+
+#endif /* __X86_BUG_H__ */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/byteorder.h b/xen/include/asm-arm/byteorder.h
new file mode 100644
index 0000000..f6ad883
--- /dev/null
+++ b/xen/include/asm-arm/byteorder.h
@@ -0,0 +1,16 @@
+#ifndef __ASM_ARM_BYTEORDER_H__
+#define __ASM_ARM_BYTEORDER_H__
+
+#define __BYTEORDER_HAS_U64__
+
+#include <xen/byteorder/little_endian.h>
+
+#endif /* __ASM_ARM_BYTEORDER_H__ */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/cache.h b/xen/include/asm-arm/cache.h
new file mode 100644
index 0000000..41b6291
--- /dev/null
+++ b/xen/include/asm-arm/cache.h
@@ -0,0 +1,20 @@
+#ifndef __ARCH_ARM_CACHE_H
+#define __ARCH_ARM_CACHE_H
+
+#include <xen/config.h>
+
+/* L1 cache line size */
+#define L1_CACHE_SHIFT  (CONFIG_ARM_L1_CACHE_SHIFT)
+#define L1_CACHE_BYTES  (1 << L1_CACHE_SHIFT)
+
+#define __read_mostly __attribute__((__section__(".data.read_mostly")))
+
+#endif
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/config.h b/xen/include/asm-arm/config.h
new file mode 100644
index 0000000..12285dd
--- /dev/null
+++ b/xen/include/asm-arm/config.h
@@ -0,0 +1,122 @@
+/******************************************************************************
+ * config.h
+ *
+ * A Linux-style configuration list.
+ */
+
+#ifndef __ARM_CONFIG_H__
+#define __ARM_CONFIG_H__
+
+#define CONFIG_PAGING_LEVELS 3
+
+#define CONFIG_ARM 1
+
+#define CONFIG_ARM_L1_CACHE_SHIFT 7 /* XXX */
+
+#define CONFIG_SMP 1
+
+#define CONFIG_DOMAIN_PAGE 1
+
+#define OPT_CONSOLE_STR "com1"
+
+#ifdef MAX_PHYS_CPUS
+#define NR_CPUS MAX_PHYS_CPUS
+#else
+#define NR_CPUS 128
+#endif
+
+#define MAX_VIRT_CPUS 128 /* XXX */
+#define MAX_HVM_VCPUS MAX_VIRT_CPUS
+
+#define asmlinkage /* Nothing needed */
+
+/* Linkage for ARM */
+#define __ALIGN .align 2
+#define __ALIGN_STR ".align 2"
+#ifdef __ASSEMBLY__
+#define ALIGN __ALIGN
+#define ALIGN_STR __ALIGN_STR
+#define ENTRY(name)                             \
+  .globl name;                                  \
+  ALIGN;                                        \
+  name:
+#define END(name) \
+  .size name, .-name
+#define ENDPROC(name) \
+  .type name, %function; \
+  END(name)
+#endif
+
+/*
+ * Memory layout:
+ *  0  -   2M   Unmapped
+ *  2M -   4M   Xen text, data, bss
+ *  4M -   6M   Fixmap: special-purpose 4K mapping slots
+ *
+ * 32M - 128M   Frametable: 24 bytes per page for 16GB of RAM
+ *
+ *  1G -   2G   Xenheap: always-mapped memory
+ *  2G -   4G   Domheap: on-demand-mapped
+ */
+
+#define XEN_VIRT_START         0x00200000
+#define FIXMAP_ADDR(n)        (0x00400000 + (n) * PAGE_SIZE)
+#define FRAMETABLE_VIRT_START  0x02000000
+#define XENHEAP_VIRT_START     0x40000000
+#define DOMHEAP_VIRT_START     0x80000000
+
+#define HYPERVISOR_VIRT_START mk_unsigned_long(XEN_VIRT_START)
+
+#define DOMHEAP_ENTRIES        1024  /* 1024 2MB mapping slots */
+
+/* Fixmap slots */
+#define FIXMAP_CONSOLE  0  /* The primary UART */
+#define FIXMAP_PT       1  /* Temporary mappings of pagetable pages */
+#define FIXMAP_MISC     2  /* Ephemeral mappings of hardware */
+#define FIXMAP_GICD     3  /* Interrupt controller: distributor registers */
+#define FIXMAP_GICC1    4  /* Interrupt controller: CPU registers (first page) */
+#define FIXMAP_GICC2    5  /* Interrupt controller: CPU registers (second page) */
+#define FIXMAP_GICH     6  /* Interrupt controller: virtual interface control registers */
+
+#define PAGE_SHIFT              12
+
+#ifndef __ASSEMBLY__
+#define PAGE_SIZE           (1L << PAGE_SHIFT)
+#else
+#define PAGE_SIZE           (1 << PAGE_SHIFT)
+#endif
+#define PAGE_MASK           (~(PAGE_SIZE-1))
+#define PAGE_FLAG_MASK      (~0)
+
+#define STACK_ORDER 3
+#define STACK_SIZE  (PAGE_SIZE << STACK_ORDER)
+
+#ifndef __ASSEMBLY__
+extern unsigned long xen_phys_start;
+extern unsigned long xenheap_phys_end;
+extern unsigned long frametable_virt_end;
+#endif
+
+#define supervisor_mode_kernel (0)
+
+#define watchdog_disable() ((void)0)
+#define watchdog_enable()  ((void)0)
+
+/* Board-specific: base address of PL011 UART */
+#define EARLY_UART_ADDRESS 0x1c090000
+/* Board-specific: base address of GIC + its regs */
+#define GIC_BASE_ADDRESS 0x2c000000
+#define GIC_DR_OFFSET 0x1000
+#define GIC_CR_OFFSET 0x2000
+#define GIC_HR_OFFSET 0x4000 /* Guess work http://lists.infradead.org/pipermail/linux-arm-kernel/2011-September/064219.html */
+#define GIC_VR_OFFSET 0x6000 /* Virtual Machine CPU interface) */
+
+#endif /* __ARM_CONFIG_H__ */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/cpregs.h b/xen/include/asm-arm/cpregs.h
new file mode 100644
index 0000000..3a4028d
--- /dev/null
+++ b/xen/include/asm-arm/cpregs.h
@@ -0,0 +1,207 @@
+#ifndef __ASM_ARM_CPREGS_H
+#define __ASM_ARM_CPREGS_H
+
+#include <xen/stringify.h>
+
+/* Co-processor registers */
+
+/* Layout as used in assembly, with src/dest registers mixed in */
+#define __CP32(r, coproc, opc1, crn, crm, opc2) coproc, opc1, r, crn, crm, opc2
+#define __CP64(r1, r2, coproc, opc, crm) coproc, opc, r1, r2, crm
+#define CP32(r, name...) __CP32(r, name)
+#define CP64(r, name...) __CP64(r, name)
+
+/* Stringified for inline assembly */
+#define LOAD_CP32(r, name...)  "mrc " __stringify(CP32(%r, name)) ";"
+#define STORE_CP32(r, name...) "mcr " __stringify(CP32(%r, name)) ";"
+#define LOAD_CP64(r, name...)  "mrrc " __stringify(CP64(%r, %H##r, name)) ";"
+#define STORE_CP64(r, name...) "mcrr " __stringify(CP64(%r, %H##r, name)) ";"
+
+/* C wrappers */
+#define READ_CP32(name...) ({                                   \
+    register uint32_t _r;                                       \
+    asm volatile(LOAD_CP32(0, name) : "=r" (_r));               \
+    _r; })
+
+#define WRITE_CP32(v, name...) do {                             \
+    register uint32_t _r = (v);                                 \
+    asm volatile(STORE_CP32(0, name) : : "r" (_r));             \
+} while (0)
+
+#define READ_CP64(name...) ({                                   \
+    register uint64_t _r;                                       \
+    asm volatile(LOAD_CP64(0, name) : "=r" (_r));               \
+    _r; })
+
+#define WRITE_CP64(v, name...) do {                             \
+    register uint64_t _r = (v);                                 \
+    asm volatile(STORE_CP64(0, name) : : "r" (_r));             \
+} while (0)
+
+#define __HSR_CPREG_c0  0
+#define __HSR_CPREG_c1  1
+#define __HSR_CPREG_c2  2
+#define __HSR_CPREG_c3  3
+#define __HSR_CPREG_c4  4
+#define __HSR_CPREG_c5  5
+#define __HSR_CPREG_c6  6
+#define __HSR_CPREG_c7  7
+#define __HSR_CPREG_c8  8
+#define __HSR_CPREG_c9  9
+#define __HSR_CPREG_c10 10
+#define __HSR_CPREG_c11 11
+#define __HSR_CPREG_c12 12
+#define __HSR_CPREG_c13 13
+#define __HSR_CPREG_c14 14
+#define __HSR_CPREG_c15 15
+
+#define __HSR_CPREG_0   0
+#define __HSR_CPREG_1   1
+#define __HSR_CPREG_2   2
+#define __HSR_CPREG_3   3
+#define __HSR_CPREG_4   4
+#define __HSR_CPREG_5   5
+#define __HSR_CPREG_6   6
+#define __HSR_CPREG_7   7
+
+#define _HSR_CPREG32(cp,op1,crn,crm,op2) \
+    ((__HSR_CPREG_##crn) << HSR_CP32_CRN_SHIFT) | \
+    ((__HSR_CPREG_##crm) << HSR_CP32_CRM_SHIFT) | \
+    ((__HSR_CPREG_##op1) << HSR_CP32_OP1_SHIFT) | \
+    ((__HSR_CPREG_##op2) << HSR_CP32_OP2_SHIFT)
+
+#define _HSR_CPREG64(cp,op1,crm) \
+    ((__HSR_CPREG_##crm) << HSR_CP64_CRM_SHIFT) | \
+    ((__HSR_CPREG_##op1) << HSR_CP64_OP1_SHIFT)
+
+/* Encode a register as per HSR ISS pattern */
+#define HSR_CPREG32(X) _HSR_CPREG32(X)
+#define HSR_CPREG64(X) _HSR_CPREG64(X)
+
+/*
+ * Order registers by Coprocessor-> CRn-> Opcode 1-> CRm-> Opcode 2
+ *
+ * This matches the ordering used in the ARM as well as the groupings
+ * which the CP registers are allocated in.
+ *
+ * This is slightly different to the form of the instruction
+ * arguments, which are cp,opc1,crn,crm,opc2.
+ */
+
+/* Coprocessor 15 */
+
+/* CP15 CR0: CPUID and Cache Type Registers */
+#define ID_PFR0         p15,0,c0,c1,0   /* Processor Feature Register 0 */
+#define ID_PFR1         p15,0,c0,c1,1   /* Processor Feature Register 1 */
+#define CCSIDR          p15,1,c0,c0,0   /* Cache Size ID Registers */
+#define CLIDR           p15,1,c0,c0,1   /* Cache Level ID Register */
+#define CSSELR          p15,2,c0,c0,0   /* Cache Size Selection Register */
+
+/* CP15 CR1: System Control Registers */
+#define SCTLR           p15,0,c1,c0,0   /* System Control Register */
+#define SCR             p15,0,c1,c1,0   /* Secure Configuration Register */
+#define NSACR           p15,0,c1,c1,2   /* Non-Secure Access Control Register */
+#define HSCTLR          p15,4,c1,c0,0   /* Hyp. System Control Register */
+#define HCR             p15,4,c1,c1,0   /* Hyp. Configuration Register */
+
+/* CP15 CR2: Translation Table Base and Control Registers */
+#define TTBR0           p15,0,c2,c0,0   /* Translation Table Base Reg. 0 */
+#define TTBR1           p15,0,c2,c0,1   /* Translation Table Base Reg. 1 */
+#define TTBCR           p15,0,c2,c0,2   /* Translatation Table Base Control Register */
+#define HTTBR           p15,4,c2        /* Hyp. Translation Table Base Register */
+#define HTCR            p15,4,c2,c0,2   /* Hyp. Translation Control Register */
+#define VTCR            p15,4,c2,c1,2   /* Virtualization Translation Control Register */
+#define VTTBR           p15,6,c2        /* Virtualization Translation Table Base Register */
+
+/* CP15 CR3: Domain Access Control Register */
+
+/* CP15 CR4: */
+
+/* CP15 CR5: Fault Status Registers */
+#define DFSR            p15,0,c5,c0,0   /* Data Fault Status Register */
+#define IFSR            p15,0,c5,c0,1   /* Instruction Fault Status Register */
+#define HSR             p15,4,c5,c2,0   /* Hyp. Syndrome Register */
+
+/* CP15 CR6: Fault Address Registers */
+#define DFAR            p15,0,c6,c0,0   /* Data Fault Address Register  */
+#define IFAR            p15,0,c6,c0,2   /* Instruction Fault Address Register */
+#define HDFAR           p15,4,c6,c0,0   /* Hyp. Data Fault Address Register */
+#define HIFAR           p15,4,c6,c0,2   /* Hyp. Instruction Fault Address Register */
+#define HPFAR           p15,4,c6,c0,4   /* Hyp. IPA Fault Address Register */
+
+/* CP15 CR7: Cache and address translation operations */
+#define PAR             p15,0,c7        /* Physical Address Register */
+#define ICIALLUIS       p15,0,c7,c1,0   /* Invalidate all instruction caches to PoU inner shareable */
+#define BPIALLIS        p15,0,c7,c1,6   /* Invalidate entire branch predictor array inner shareable */
+#define ICIALLU         p15,0,c7,c5,0   /* Invalidate all instruction caches to PoU */
+#define BPIALL          p15,0,c7,c5,6   /* Invalidate entire branch predictor array */
+#define ATS1CPR         p15,0,c7,c8,0   /* Address Translation Stage 1. Non-Secure Kernel Read */
+#define ATS1CPW         p15,0,c7,c8,1   /* Address Translation Stage 1. Non-Secure Kernel Write */
+#define ATS1CUR         p15,0,c7,c8,2   /* Address Translation Stage 1. Non-Secure User Read */
+#define ATS1CUW         p15,0,c7,c8,3   /* Address Translation Stage 1. Non-Secure User Write */
+#define ATS12NSOPR      p15,0,c7,c8,4   /* Address Translation Stage 1+2 Non-Secure Kernel Read */
+#define ATS12NSOPW      p15,0,c7,c8,5   /* Address Translation Stage 1+2 Non-Secure Kernel Write */
+#define ATS12NSOUR      p15,0,c7,c8,6   /* Address Translation Stage 1+2 Non-Secure User Read */
+#define ATS12NSOUW      p15,0,c7,c8,7   /* Address Translation Stage 1+2 Non-Secure User Write */
+#define DCCMVAC         p15,0,c7,c10,1  /* Clean data or unified cache line by MVA to PoC */
+#define DCCISW          p15,0,c7,c14,2  /* Clean and invalidate data cache line by set/way */
+#define ATS1HR          p15,4,c7,c8,0   /* Address Translation Stage 1 Hyp. Read */
+#define ATS1HW          p15,4,c7,c8,1   /* Address Translation Stage 1 Hyp. Write */
+
+/* CP15 CR8: TLB maintenance operations */
+#define TLBIALLIS       p15,0,c8,c3,0   /* Invalidate entire TLB innrer shareable */
+#define TLBIMVAIS       p15,0,c8,c3,1   /* Invalidate unified TLB entry by MVA inner shareable */
+#define TLBIASIDIS      p15,0,c8,c3,2   /* Invalidate unified TLB by ASID match inner shareable */
+#define TLBIMVAAIS      p15,0,c8,c3,3   /* Invalidate unified TLB entry by MVA all ASID inner shareable */
+#define DTLBIALL        p15,0,c8,c6,0   /* Invalidate data TLB */
+#define DTLBIMVA        p15,0,c8,c6,1   /* Invalidate data TLB entry by MVA */
+#define DTLBIASID       p15,0,c8,c6,2   /* Invalidate data TLB by ASID match */
+#define TLBILLHIS       p15,4,c8,c3,0   /* Invalidate Entire Hyp. Unified TLB inner shareable */
+#define TLBIMVAHIS      p15,4,c8,c3,1   /* Invalidate Unified Hyp. TLB by MVA inner shareable */
+#define TLBIALLNSNHIS   p15,4,c8,c7,4   /* Invalidate Entire Non-Secure Non-Hyp. Unified TLB inner shareable */
+#define TLBIALLH        p15,4,c8,c7,0   /* Invalidate Entire Hyp. Unified TLB */
+#define TLBIMVAH        p15,4,c8,c7,1   /* Invalidate Unified Hyp. TLB by MVA */
+#define TLBIALLNSNH     p15,4,c8,c7,4   /* Invalidate Entire Non-Secure Non-Hyp. Unified TLB */
+
+/* CP15 CR9: */
+
+/* CP15 CR10: */
+#define MAIR0           p15,0,c10,c2,0  /* Memory Attribute Indirection Register 0 */
+#define MAIR1           p15,0,c10,c2,1  /* Memory Attribute Indirection Register 1 */
+#define HMAIR0          p15,4,c10,c2,0  /* Hyp. Memory Attribute Indirection Register 0 */
+#define HMAIR1          p15,4,c10,c2,1  /* Hyp. Memory Attribute Indirection Register 1 */
+
+/* CP15 CR11: DMA Operations for TCM Access */
+
+/* CP15 CR12:  */
+#define HVBAR           p15,4,c12,c0,0  /* Hyp. Vector Base Address Register */
+
+/* CP15 CR13:  */
+#define FCSEIDR         p15,0,c13,c0,0  /* FCSE Process ID Register */
+#define CONTEXTIDR      p15,0,c13,c0,1  /* Context ID Register */
+
+/* CP15 CR14:  */
+#define CNTPCT          p15,0,c14       /* Time counter value */
+#define CNTFRQ          p15,0,c14,c0,0  /* Time counter frequency */
+#define CNTKCTL         p15,0,c14,c1,0  /* Time counter kernel control */
+#define CNTP_TVAL       p15,0,c14,c2,0  /* Physical Timer value */
+#define CNTP_CTL        p15,0,c14,c2,1  /* Physical Timer control register */
+#define CNTVCT          p15,1,c14       /* Time counter value + offset */
+#define CNTP_CVAL       p15,2,c14       /* Physical Timer comparator */
+#define CNTVOFF         p15,4,c14       /* Time counter offset */
+#define CNTHCTL         p15,4,c14,c1,0  /* Time counter hyp. control */
+#define CNTHP_TVAL      p15,4,c14,c2,0  /* Hyp. Timer value */
+#define CNTHP_CTL       p15,4,c14,c2,1  /* Hyp. Timer control register */
+#define CNTHP_CVAL      p15,6,c14       /* Hyp. Timer comparator */
+
+/* CP15 CR15: Implementation Defined Registers */
+
+#endif
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/current.h b/xen/include/asm-arm/current.h
new file mode 100644
index 0000000..826efa5
--- /dev/null
+++ b/xen/include/asm-arm/current.h
@@ -0,0 +1,60 @@
+#ifndef __ARM_CURRENT_H__
+#define __ARM_CURRENT_H__
+
+#include <xen/config.h>
+#include <xen/percpu.h>
+#include <public/xen.h>
+
+#ifndef __ASSEMBLY__
+
+struct vcpu;
+
+struct cpu_info {
+    struct cpu_user_regs guest_cpu_user_regs;
+    unsigned long elr;
+    unsigned int processor_id;
+    struct vcpu *current_vcpu;
+    unsigned long per_cpu_offset;
+};
+
+static inline struct cpu_info *get_cpu_info(void)
+{
+        register unsigned long sp asm ("sp");
+        return (struct cpu_info *)((sp & ~(STACK_SIZE - 1)) + STACK_SIZE - sizeof(struct cpu_info));
+}
+
+#define get_current()         (get_cpu_info()->current_vcpu)
+#define set_current(vcpu)     (get_cpu_info()->current_vcpu = (vcpu))
+#define current               (get_current())
+
+#define get_processor_id()    (get_cpu_info()->processor_id)
+#define set_processor_id(id)  do {                                      \
+    struct cpu_info *ci__ = get_cpu_info();                             \
+    ci__->per_cpu_offset = __per_cpu_offset[ci__->processor_id = (id)]; \
+} while (0)
+
+#define guest_cpu_user_regs() (&get_cpu_info()->guest_cpu_user_regs)
+
+#define reset_stack_and_jump(__fn)              \
+    __asm__ __volatile__ (                      \
+        "mov sp,%0; b "STR(__fn)      \
+        : : "r" (guest_cpu_user_regs()) : "memory" )
+#endif
+
+
+/*
+ * Which VCPU's state is currently running on each CPU?
+ * This is not necesasrily the same as 'current' as a CPU may be
+ * executing a lazy state switch.
+ */
+DECLARE_PER_CPU(struct vcpu *, curr_vcpu);
+
+#endif /* __ARM_CURRENT_H__ */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/debugger.h b/xen/include/asm-arm/debugger.h
new file mode 100644
index 0000000..84b2eec
--- /dev/null
+++ b/xen/include/asm-arm/debugger.h
@@ -0,0 +1,15 @@
+#ifndef __ARM_DEBUGGER_H__
+#define __ARM_DEBUGGER_H__
+
+#define debugger_trap_fatal(v, r) (0)
+#define debugger_trap_immediate() (0)
+
+#endif /* __ARM_DEBUGGER_H__ */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/delay.h b/xen/include/asm-arm/delay.h
new file mode 100644
index 0000000..6250774
--- /dev/null
+++ b/xen/include/asm-arm/delay.h
@@ -0,0 +1,15 @@
+#ifndef _ARM_DELAY_H
+#define _ARM_DELAY_H
+
+extern void __udelay(unsigned long usecs);
+#define udelay(n) __udelay(n)
+
+#endif /* defined(_ARM_DELAY_H) */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/desc.h b/xen/include/asm-arm/desc.h
new file mode 100644
index 0000000..3989e8a
--- /dev/null
+++ b/xen/include/asm-arm/desc.h
@@ -0,0 +1,12 @@
+#ifndef __ARCH_DESC_H
+#define __ARCH_DESC_H
+
+#endif /* __ARCH_DESC_H */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/div64.h b/xen/include/asm-arm/div64.h
new file mode 100644
index 0000000..7b00808
--- /dev/null
+++ b/xen/include/asm-arm/div64.h
@@ -0,0 +1,235 @@
+/* Taken from Linux arch/arm */
+#ifndef __ASM_ARM_DIV64
+#define __ASM_ARM_DIV64
+
+#include <asm/system.h>
+#include <xen/types.h>
+
+/*
+ * The semantics of do_div() are:
+ *
+ * uint32_t do_div(uint64_t *n, uint32_t base)
+ * {
+ * 	uint32_t remainder = *n % base;
+ * 	*n = *n / base;
+ * 	return remainder;
+ * }
+ *
+ * In other words, a 64-bit dividend with a 32-bit divisor producing
+ * a 64-bit result and a 32-bit remainder.  To accomplish this optimally
+ * we call a special __do_div64 helper with completely non standard
+ * calling convention for arguments and results (beware).
+ */
+
+#ifdef __ARMEB__
+#define __xh "r0"
+#define __xl "r1"
+#else
+#define __xl "r0"
+#define __xh "r1"
+#endif
+
+#define __do_div_asm(n, base)					\
+({								\
+	register unsigned int __base      asm("r4") = base;	\
+	register unsigned long long __n   asm("r0") = n;	\
+	register unsigned long long __res asm("r2");		\
+	register unsigned int __rem       asm(__xh);		\
+	asm(	__asmeq("%0", __xh)				\
+		__asmeq("%1", "r2")				\
+		__asmeq("%2", "r0")				\
+		__asmeq("%3", "r4")				\
+		"bl	__do_div64"				\
+		: "=r" (__rem), "=r" (__res)			\
+		: "r" (__n), "r" (__base)			\
+		: "ip", "lr", "cc");				\
+	n = __res;						\
+	__rem;							\
+})
+
+#if __GNUC__ < 4
+
+/*
+ * gcc versions earlier than 4.0 are simply too problematic for the
+ * optimized implementation below. First there is gcc PR 15089 that
+ * tend to trig on more complex constructs, spurious .global __udivsi3
+ * are inserted even if none of those symbols are referenced in the
+ * generated code, and those gcc versions are not able to do constant
+ * propagation on long long values anyway.
+ */
+#define do_div(n, base) __do_div_asm(n, base)
+
+#elif __GNUC__ >= 4
+
+#include <asm/bug.h>
+
+/*
+ * If the divisor happens to be constant, we determine the appropriate
+ * inverse at compile time to turn the division into a few inline
+ * multiplications instead which is much faster. And yet only if compiling
+ * for ARMv4 or higher (we need umull/umlal) and if the gcc version is
+ * sufficiently recent to perform proper long long constant propagation.
+ * (It is unfortunate that gcc doesn't perform all this internally.)
+ */
+#define do_div(n, base)							\
+({									\
+	unsigned int __r, __b = (base);					\
+	if (!__builtin_constant_p(__b) || __b == 0) {			\
+		/* non-constant divisor (or zero): slow path */		\
+		__r = __do_div_asm(n, __b);				\
+	} else if ((__b & (__b - 1)) == 0) {				\
+		/* Trivial: __b is constant and a power of 2 */		\
+		/* gcc does the right thing with this code.  */		\
+		__r = n;						\
+		__r &= (__b - 1);					\
+		n /= __b;						\
+	} else {							\
+		/* Multiply by inverse of __b: n/b = n*(p/b)/p       */	\
+		/* We rely on the fact that most of this code gets   */	\
+		/* optimized away at compile time due to constant    */	\
+		/* propagation and only a couple inline assembly     */	\
+		/* instructions should remain. Better avoid any      */	\
+		/* code construct that might prevent that.           */	\
+		unsigned long long __res, __x, __t, __m, __n = n;	\
+		unsigned int __c, __p, __z = 0;				\
+		/* preserve low part of n for reminder computation */	\
+		__r = __n;						\
+		/* determine number of bits to represent __b */		\
+		__p = 1 << __div64_fls(__b);				\
+		/* compute __m = ((__p << 64) + __b - 1) / __b */	\
+		__m = (~0ULL / __b) * __p;				\
+		__m += (((~0ULL % __b + 1) * __p) + __b - 1) / __b;	\
+		/* compute __res = __m*(~0ULL/__b*__b-1)/(__p << 64) */	\
+		__x = ~0ULL / __b * __b - 1;				\
+		__res = (__m & 0xffffffff) * (__x & 0xffffffff);	\
+		__res >>= 32;						\
+		__res += (__m & 0xffffffff) * (__x >> 32);		\
+		__t = __res;						\
+		__res += (__x & 0xffffffff) * (__m >> 32);		\
+		__t = (__res < __t) ? (1ULL << 32) : 0;			\
+		__res = (__res >> 32) + __t;				\
+		__res += (__m >> 32) * (__x >> 32);			\
+		__res /= __p;						\
+		/* Now sanitize and optimize what we've got. */		\
+		if (~0ULL % (__b / (__b & -__b)) == 0) {		\
+			/* those cases can be simplified with: */	\
+			__n /= (__b & -__b);				\
+			__m = ~0ULL / (__b / (__b & -__b));		\
+			__p = 1;					\
+			__c = 1;					\
+		} else if (__res != __x / __b) {			\
+			/* We can't get away without a correction    */	\
+			/* to compensate for bit truncation errors.  */	\
+			/* To avoid it we'd need an additional bit   */	\
+			/* to represent __m which would overflow it. */	\
+			/* Instead we do m=p/b and n/b=(n*m+m)/p.    */	\
+			__c = 1;					\
+			/* Compute __m = (__p << 64) / __b */		\
+			__m = (~0ULL / __b) * __p;			\
+			__m += ((~0ULL % __b + 1) * __p) / __b;		\
+		} else {						\
+			/* Reduce __m/__p, and try to clear bit 31   */	\
+			/* of __m when possible otherwise that'll    */	\
+			/* need extra overflow handling later.       */	\
+			unsigned int __bits = -(__m & -__m);		\
+			__bits |= __m >> 32;				\
+			__bits = (~__bits) << 1;			\
+			/* If __bits == 0 then setting bit 31 is     */	\
+			/* unavoidable.  Simply apply the maximum    */	\
+			/* possible reduction in that case.          */	\
+			/* Otherwise the MSB of __bits indicates the */	\
+			/* best reduction we should apply.           */	\
+			if (!__bits) {					\
+				__p /= (__m & -__m);			\
+				__m /= (__m & -__m);			\
+			} else {					\
+				__p >>= __div64_fls(__bits);		\
+				__m >>= __div64_fls(__bits);		\
+			}						\
+			/* No correction needed. */			\
+			__c = 0;					\
+		}							\
+		/* Now we have a combination of 2 conditions:        */	\
+		/* 1) whether or not we need a correction (__c), and */	\
+		/* 2) whether or not there might be an overflow in   */	\
+		/*    the cross product (__m & ((1<<63) | (1<<31)))  */	\
+		/* Select the best insn combination to perform the   */	\
+		/* actual __m * __n / (__p << 64) operation.         */	\
+		if (!__c) {						\
+			asm (	"umull	%Q0, %R0, %1, %Q2\n\t"		\
+				"mov	%Q0, #0"			\
+				: "=&r" (__res)				\
+				: "r" (__m), "r" (__n)			\
+				: "cc" );				\
+		} else if (!(__m & ((1ULL << 63) | (1ULL << 31)))) {	\
+			__res = __m;					\
+			asm (	"umlal	%Q0, %R0, %Q1, %Q2\n\t"		\
+				"mov	%Q0, #0"			\
+				: "+&r" (__res)				\
+				: "r" (__m), "r" (__n)			\
+				: "cc" );				\
+		} else {						\
+			asm (	"umull	%Q0, %R0, %Q1, %Q2\n\t"		\
+				"cmn	%Q0, %Q1\n\t"			\
+				"adcs	%R0, %R0, %R1\n\t"		\
+				"adc	%Q0, %3, #0"			\
+				: "=&r" (__res)				\
+				: "r" (__m), "r" (__n), "r" (__z)	\
+				: "cc" );				\
+		}							\
+		if (!(__m & ((1ULL << 63) | (1ULL << 31)))) {		\
+			asm (	"umlal	%R0, %Q0, %R1, %Q2\n\t"		\
+				"umlal	%R0, %Q0, %Q1, %R2\n\t"		\
+				"mov	%R0, #0\n\t"			\
+				"umlal	%Q0, %R0, %R1, %R2"		\
+				: "+&r" (__res)				\
+				: "r" (__m), "r" (__n)			\
+				: "cc" );				\
+		} else {						\
+			asm (	"umlal	%R0, %Q0, %R2, %Q3\n\t"		\
+				"umlal	%R0, %1, %Q2, %R3\n\t"		\
+				"mov	%R0, #0\n\t"			\
+				"adds	%Q0, %1, %Q0\n\t"		\
+				"adc	%R0, %R0, #0\n\t"		\
+				"umlal	%Q0, %R0, %R2, %R3"		\
+				: "+&r" (__res), "+&r" (__z)		\
+				: "r" (__m), "r" (__n)			\
+				: "cc" );				\
+		}							\
+		__res /= __p;						\
+		/* The reminder can be computed with 32-bit regs     */	\
+		/* only, and gcc is good at that.                    */	\
+		{							\
+			unsigned int __res0 = __res;			\
+			unsigned int __b0 = __b;			\
+			__r -= __res0 * __b0;				\
+		}							\
+		/* BUG_ON(__r >= __b || __res * __b + __r != n); */	\
+		n = __res;						\
+	}								\
+	__r;								\
+})
+
+/* our own fls implementation to make sure constant propagation is fine */
+#define __div64_fls(bits)						\
+({									\
+	unsigned int __left = (bits), __nr = 0;				\
+	if (__left & 0xffff0000) __nr += 16, __left >>= 16;		\
+	if (__left & 0x0000ff00) __nr +=  8, __left >>=  8;		\
+	if (__left & 0x000000f0) __nr +=  4, __left >>=  4;		\
+	if (__left & 0x0000000c) __nr +=  2, __left >>=  2;		\
+	if (__left & 0x00000002) __nr +=  1;				\
+	__nr;								\
+})
+
+#endif
+
+#endif
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/elf.h b/xen/include/asm-arm/elf.h
new file mode 100644
index 0000000..12d487c
--- /dev/null
+++ b/xen/include/asm-arm/elf.h
@@ -0,0 +1,33 @@
+#ifndef __ARM_ELF_H__
+#define __ARM_ELF_H__
+
+typedef struct {
+    unsigned long r0;
+    unsigned long r1;
+    unsigned long r2;
+    unsigned long r3;
+    unsigned long r4;
+    unsigned long r5;
+    unsigned long r6;
+    unsigned long r7;
+    unsigned long r8;
+    unsigned long r9;
+    unsigned long r10;
+    unsigned long r11;
+    unsigned long r12;
+    unsigned long sp;
+    unsigned long lr;
+    unsigned long pc;
+} ELF_Gregset;
+
+#endif /* __ARM_ELF_H__ */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/event.h b/xen/include/asm-arm/event.h
new file mode 100644
index 0000000..6b2fb7c
--- /dev/null
+++ b/xen/include/asm-arm/event.h
@@ -0,0 +1,41 @@
+#ifndef __ASM_EVENT_H__
+#define __ASM_EVENT_H__
+
+void vcpu_kick(struct vcpu *v);
+void vcpu_mark_events_pending(struct vcpu *v);
+
+static inline int local_events_need_delivery(void)
+{
+    /* TODO
+     * return (vcpu_info(v, evtchn_upcall_pending) &&
+                        !vcpu_info(v, evtchn_upcall_mask)); */
+        return 0;
+}
+
+int local_event_delivery_is_enabled(void);
+
+static inline void local_event_delivery_disable(void)
+{
+    /* TODO current->vcpu_info->evtchn_upcall_mask = 1; */
+}
+
+static inline void local_event_delivery_enable(void)
+{
+    /* TODO current->vcpu_info->evtchn_upcall_mask = 0; */
+}
+
+/* No arch specific virq definition now. Default to global. */
+static inline int arch_virq_is_global(int virq)
+{
+    return 1;
+}
+
+#endif
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/flushtlb.h b/xen/include/asm-arm/flushtlb.h
new file mode 100644
index 0000000..c8486fc
--- /dev/null
+++ b/xen/include/asm-arm/flushtlb.h
@@ -0,0 +1,31 @@
+#ifndef __FLUSHTLB_H__
+#define __FLUSHTLB_H__
+
+#include <xen/cpumask.h>
+
+/*
+ * Filter the given set of CPUs, removing those that definitely flushed their
+ * TLB since @page_timestamp.
+ */
+/* XXX lazy implementation just doesn't clear anything.... */
+#define tlbflush_filter(mask, page_timestamp)                           \
+do {                                                                    \
+} while ( 0 )
+
+#define tlbflush_current_time()                 (0)
+
+/* Flush local TLBs */
+void flush_tlb_local(void);
+
+/* Flush specified CPUs' TLBs */
+void flush_tlb_mask(const cpumask_t *mask);
+
+#endif /* __FLUSHTLB_H__ */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/grant_table.h b/xen/include/asm-arm/grant_table.h
new file mode 100644
index 0000000..8f6ffd8
--- /dev/null
+++ b/xen/include/asm-arm/grant_table.h
@@ -0,0 +1,35 @@
+#ifndef __ASM_GRANT_TABLE_H__
+#define __ASM_GRANT_TABLE_H__
+
+#include <xen/grant_table.h>
+
+#define INVALID_GFN (-1UL)
+#define INITIAL_NR_GRANT_FRAMES 1
+
+void gnttab_clear_flag(unsigned long nr, uint16_t *addr);
+int create_grant_host_mapping(unsigned long gpaddr,
+		unsigned long mfn, unsigned int flags, unsigned int
+		cache_flags);
+#define gnttab_host_mapping_get_page_type(op, d, rd) (0)
+int replace_grant_host_mapping(unsigned long gpaddr, unsigned long mfn,
+		unsigned long new_gpaddr, unsigned int flags);
+void gnttab_mark_dirty(struct domain *d, unsigned long l);
+#define gnttab_create_status_page(d, t, i) (0)
+#define gnttab_create_shared_page(d, t, i) (0)
+#define gnttab_shared_gmfn(d, t, i) (0)
+#define gnttab_status_gmfn(d, t, i) (0)
+#define gnttab_release_host_mappings(domain) 1
+static inline int replace_grant_supported(void)
+{
+    return 1;
+}
+
+#endif /* __ASM_GRANT_TABLE_H__ */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/hardirq.h b/xen/include/asm-arm/hardirq.h
new file mode 100644
index 0000000..9c031a8
--- /dev/null
+++ b/xen/include/asm-arm/hardirq.h
@@ -0,0 +1,28 @@
+#ifndef __ASM_HARDIRQ_H
+#define __ASM_HARDIRQ_H
+
+#include <xen/config.h>
+#include <xen/cache.h>
+#include <xen/smp.h>
+
+typedef struct {
+        unsigned long __softirq_pending;
+        unsigned int __local_irq_count;
+} __cacheline_aligned irq_cpustat_t;
+
+#include <xen/irq_cpustat.h>    /* Standard mappings for irq_cpustat_t above */
+
+#define in_irq() (local_irq_count(smp_processor_id()) != 0)
+
+#define irq_enter()     (local_irq_count(smp_processor_id())++)
+#define irq_exit()      (local_irq_count(smp_processor_id())--)
+
+#endif /* __ASM_HARDIRQ_H */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/hypercall.h b/xen/include/asm-arm/hypercall.h
new file mode 100644
index 0000000..90a87ef
--- /dev/null
+++ b/xen/include/asm-arm/hypercall.h
@@ -0,0 +1,24 @@
+#ifndef __ASM_ARM_HYPERCALL_H__
+#define __ASM_ARM_HYPERCALL_H__
+
+#include <public/domctl.h> /* for arch_do_domctl */
+
+struct vcpu;
+extern long
+arch_do_vcpu_op(
+    int cmd, struct vcpu *v, XEN_GUEST_HANDLE(void) arg);
+
+extern long
+arch_do_sysctl(
+    struct xen_sysctl *op,
+    XEN_GUEST_HANDLE(xen_sysctl_t) u_sysctl);
+
+#endif /* __ASM_ARM_HYPERCALL_H__ */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/init.h b/xen/include/asm-arm/init.h
new file mode 100644
index 0000000..5f44929
--- /dev/null
+++ b/xen/include/asm-arm/init.h
@@ -0,0 +1,12 @@
+#ifndef _XEN_ASM_INIT_H
+#define _XEN_ASM_INIT_H
+
+#endif /* _XEN_ASM_INIT_H */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/io.h b/xen/include/asm-arm/io.h
new file mode 100644
index 0000000..1babbab
--- /dev/null
+++ b/xen/include/asm-arm/io.h
@@ -0,0 +1,12 @@
+#ifndef _ASM_IO_H
+#define _ASM_IO_H
+
+#endif
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/iocap.h b/xen/include/asm-arm/iocap.h
new file mode 100644
index 0000000..f647f30
--- /dev/null
+++ b/xen/include/asm-arm/iocap.h
@@ -0,0 +1,20 @@
+#ifndef __X86_IOCAP_H__
+#define __X86_IOCAP_H__
+
+#define cache_flush_permitted(d)                        \
+    (!rangeset_is_empty((d)->iomem_caps))
+
+#define multipage_allocation_permitted(d, order)        \
+    (((order) <= 9) || /* allow 2MB superpages */       \
+     !rangeset_is_empty((d)->iomem_caps))
+
+#endif
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/multicall.h b/xen/include/asm-arm/multicall.h
new file mode 100644
index 0000000..c800940
--- /dev/null
+++ b/xen/include/asm-arm/multicall.h
@@ -0,0 +1,23 @@
+#ifndef __ASM_ARM_MULTICALL_H__
+#define __ASM_ARM_MULTICALL_H__
+
+#define do_multicall_call(_call)                             \
+    do {                                                     \
+        __asm__ __volatile__ (                               \
+            ".word 0xe7f000f0@; do_multicall_call\n"         \
+            "    mov r0,#0; @ do_multicall_call\n"           \
+            "    str r0, [r0];\n"                            \
+            :                                                \
+            :                                                \
+            : );                                             \
+    } while ( 0 )
+
+#endif /* __ASM_ARM_MULTICALL_H__ */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/nmi.h b/xen/include/asm-arm/nmi.h
new file mode 100644
index 0000000..e0f19f9
--- /dev/null
+++ b/xen/include/asm-arm/nmi.h
@@ -0,0 +1,15 @@
+#ifndef ASM_NMI_H
+#define ASM_NMI_H
+
+#define register_guest_nmi_callback(a)  (-ENOSYS)
+#define unregister_guest_nmi_callback() (-ENOSYS)
+
+#endif /* ASM_NMI_H */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/numa.h b/xen/include/asm-arm/numa.h
new file mode 100644
index 0000000..cffee5c
--- /dev/null
+++ b/xen/include/asm-arm/numa.h
@@ -0,0 +1,21 @@
+#ifndef __ARCH_ARM_NUMA_H
+#define __ARCH_ARM_NUMA_H
+
+/* Fake one node for now... */
+#define cpu_to_node(cpu) 0
+#define node_to_cpumask(node)	(cpu_online_map)
+
+static inline __attribute__((pure)) int phys_to_nid(paddr_t addr)
+{
+        return 0;
+}
+
+#endif /* __ARCH_ARM_NUMA_H */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/paging.h b/xen/include/asm-arm/paging.h
new file mode 100644
index 0000000..4dc340f
--- /dev/null
+++ b/xen/include/asm-arm/paging.h
@@ -0,0 +1,13 @@
+#ifndef _XEN_PAGING_H
+#define _XEN_PAGING_H
+
+#endif /* XEN_PAGING_H */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/percpu.h b/xen/include/asm-arm/percpu.h
new file mode 100644
index 0000000..9d369eb
--- /dev/null
+++ b/xen/include/asm-arm/percpu.h
@@ -0,0 +1,28 @@
+#ifndef __ARM_PERCPU_H__
+#define __ARM_PERCPU_H__
+
+#ifndef __ASSEMBLY__
+extern char __per_cpu_start[], __per_cpu_data_end[];
+extern unsigned long __per_cpu_offset[NR_CPUS];
+void percpu_init_areas(void);
+#endif
+
+/* Separate out the type, so (int[3], foo) works. */
+#define __DEFINE_PER_CPU(type, name, suffix)                    \
+    __attribute__((__section__(".bss.percpu" #suffix)))         \
+    __typeof__(type) per_cpu_##name
+
+#define per_cpu(var, cpu) ((&per_cpu__##var)[cpu?0:0])
+#define __get_cpu_var(var) per_cpu__##var
+
+#define DECLARE_PER_CPU(type, name) extern __typeof__(type) per_cpu__##name
+
+#endif /* __ARM_PERCPU_H__ */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/processor.h b/xen/include/asm-arm/processor.h
new file mode 100644
index 0000000..1f85d31
--- /dev/null
+++ b/xen/include/asm-arm/processor.h
@@ -0,0 +1,269 @@
+#ifndef __ASM_ARM_PROCESSOR_H
+#define __ASM_ARM_PROCESSOR_H
+
+#include <asm/cpregs.h>
+
+/* PSR bits (CPSR, SPSR)*/
+
+/* 0-4: Mode */
+#define PSR_MODE_MASK 0x1f
+#define PSR_MODE_USR 0x10
+#define PSR_MODE_FIQ 0x11
+#define PSR_MODE_IRQ 0x12
+#define PSR_MODE_SVC 0x13
+#define PSR_MODE_MON 0x16
+#define PSR_MODE_ABT 0x17
+#define PSR_MODE_HYP 0x1a
+#define PSR_MODE_UND 0x1b
+#define PSR_MODE_SYS 0x1f
+
+#define PSR_THUMB        (1<<5)        /* Thumb Mode enable */
+#define PSR_FIQ_MASK        (1<<6)        /* Fast Interrupt mask */
+#define PSR_IRQ_MASK        (1<<7)        /* Interrupt mask */
+#define PSR_ABT_MASK         (1<<8)        /* Asynchronous Abort mask */
+#define PSR_BIG_ENDIAN        (1<<9)        /* Big Endian Mode */
+#define PSR_JAZELLE        (1<<24)        /* Jazelle Mode */
+
+/* TTBCR Translation Table Base Control Register */
+#define TTBCR_N_MASK 0x07
+#define TTBCR_N_16KB 0x00
+#define TTBCR_N_8KB  0x01
+#define TTBCR_N_4KB  0x02
+#define TTBCR_N_2KB  0x03
+#define TTBCR_N_1KB  0x04
+
+/* SCTLR System Control Register. */
+/* HSCTLR is a subset of this. */
+#define SCTLR_TE        (1<<30)
+#define SCTLR_AFE        (1<<29)
+#define SCTLR_TRE        (1<<28)
+#define SCTLR_NMFI        (1<<27)
+#define SCTLR_EE        (1<<25)
+#define SCTLR_VE        (1<<24)
+#define SCTLR_U                (1<<22)
+#define SCTLR_FI        (1<<21)
+#define SCTLR_WXN        (1<<19)
+#define SCTLR_HA        (1<<17)
+#define SCTLR_RR        (1<<14)
+#define SCTLR_V                (1<<13)
+#define SCTLR_I                (1<<12)
+#define SCTLR_Z                (1<<11)
+#define SCTLR_SW        (1<<10)
+#define SCTLR_B                (1<<7)
+#define SCTLR_C                (1<<2)
+#define SCTLR_A                (1<<1)
+#define SCTLR_M                (1<<0)
+
+#define SCTLR_BASE        0x00c50078
+#define HSCTLR_BASE        0x30c51878
+
+/* HCR Hyp Configuration Register */
+#define HCR_TGE                (1<<27)
+#define HCR_TVM                (1<<26)
+#define HCR_TTLB        (1<<25)
+#define HCR_TPU                (1<<24)
+#define HCR_TPC                (1<<23)
+#define HCR_TSW                (1<<22)
+#define HCR_TAC                (1<<21)
+#define HCR_TIDCP        (1<<20)
+#define HCR_TSC                (1<<19)
+#define HCR_TID3        (1<<18)
+#define HCR_TID2        (1<<17)
+#define HCR_TID1        (1<<16)
+#define HCR_TID0        (1<<15)
+#define HCR_TWE                (1<<14)
+#define HCR_TWI                (1<<13)
+#define HCR_DC                (1<<12)
+#define HCR_BSU_MASK        (3<<10)
+#define HCR_FB                (1<<9)
+#define HCR_VA                (1<<8)
+#define HCR_VI                (1<<7)
+#define HCR_VF                (1<<6)
+#define HCR_AMO                (1<<5)
+#define HCR_IMO                (1<<4)
+#define HCR_FMO                (1<<3)
+#define HCR_PTW                (1<<2)
+#define HCR_SWIO        (1<<1)
+#define HCR_VM                (1<<0)
+
+#define HSR_EC_WFI_WFE              0x01
+#define HSR_EC_CP15_32              0x03
+#define HSR_EC_CP15_64              0x04
+#define HSR_EC_CP14_32              0x05
+#define HSR_EC_CP14_DBG             0x06
+#define HSR_EC_CP                   0x07
+#define HSR_EC_CP10                 0x08
+#define HSR_EC_JAZELLE              0x09
+#define HSR_EC_BXJ                  0x0a
+#define HSR_EC_CP14_64              0x0c
+#define HSR_EC_SVC                  0x11
+#define HSR_EC_HVC                  0x12
+#define HSR_EC_INSTR_ABORT_GUEST    0x20
+#define HSR_EC_INSTR_ABORT_HYP      0x21
+#define HSR_EC_DATA_ABORT_GUEST     0x24
+#define HSR_EC_DATA_ABORT_HYP       0x25
+
+#ifndef __ASSEMBLY__
+union hsr {
+    uint32_t bits;
+    struct {
+        unsigned long iss:25;  /* Instruction Specific Syndrome */
+        unsigned long len:1;   /* Instruction length */
+        unsigned long ec:6;    /* Exception Class */
+    };
+
+    struct hsr_cp32 {
+        unsigned long read:1;  /* Direction */
+        unsigned long crm:4;   /* CRm */
+        unsigned long reg:4;   /* Rt */
+        unsigned long sbzp:1;
+        unsigned long crn:4;   /* CRn */
+        unsigned long op1:3;   /* Op1 */
+        unsigned long op2:3;   /* Op2 */
+        unsigned long cc:4;    /* Condition Code */
+        unsigned long ccvalid:1;/* CC Valid */
+        unsigned long len:1;   /* Instruction length */
+        unsigned long ec:6;    /* Exception Class */
+    } cp32; /* HSR_EC_CP15_32, CP14_32, CP10 */
+
+    struct hsr_cp64 {
+        unsigned long read:1;   /* Direction */
+        unsigned long crm:4;    /* CRm */
+        unsigned long reg1:4;   /* Rt1 */
+        unsigned long sbzp1:1;
+        unsigned long reg2:4;   /* Rt2 */
+        unsigned long sbzp2:2;
+        unsigned long op1:4;   /* Op1 */
+        unsigned long cc:4;    /* Condition Code */
+        unsigned long ccvalid:1;/* CC Valid */
+        unsigned long len:1;   /* Instruction length */
+        unsigned long ec:6;    /* Exception Class */
+    } cp64; /* HSR_EC_CP15_64, HSR_EC_CP14_64 */
+
+    struct hsr_dabt {
+        unsigned long dfsc:6;  /* Data Fault Status Code */
+        unsigned long write:1; /* Write / not Read */
+        unsigned long s1ptw:1; /* */
+        unsigned long cache:1; /* Cache Maintenance */
+        unsigned long eat:1;   /* External Abort Type */
+        unsigned long sbzp0:6;
+        unsigned long reg:4;   /* Register */
+        unsigned long sbzp1:1;
+        unsigned long sign:1;  /* Sign extend */
+        unsigned long size:2;  /* Access Size */
+        unsigned long valid:1; /* Syndrome Valid */
+        unsigned long len:1;   /* Instruction length */
+        unsigned long ec:6;    /* Exception Class */
+    } dabt; /* HSR_EC_DATA_ABORT_* */
+};
+#endif
+
+/* HSR.EC == HSR_CP{15,14,10}_32 */
+#define HSR_CP32_OP2_MASK (0x000e0000)
+#define HSR_CP32_OP2_SHIFT (17)
+#define HSR_CP32_OP1_MASK (0x0001c000)
+#define HSR_CP32_OP1_SHIFT (14)
+#define HSR_CP32_CRN_MASK (0x00003c00)
+#define HSR_CP32_CRN_SHIFT (10)
+#define HSR_CP32_CRM_MASK (0x0000001e)
+#define HSR_CP32_CRM_SHIFT (1)
+#define HSR_CP32_REGS_MASK (HSR_CP32_OP1_MASK|HSR_CP32_OP2_MASK|\
+                            HSR_CP32_CRN_MASK|HSR_CP32_CRM_MASK)
+
+/* HSR.EC == HSR_CP{15,14}_64 */
+#define HSR_CP64_OP1_MASK (0x000f0000)
+#define HSR_CP64_OP1_SHIFT (16)
+#define HSR_CP64_CRM_MASK (0x0000001e)
+#define HSR_CP64_CRM_SHIFT (1)
+#define HSR_CP64_REGS_MASK (HSR_CP64_OP1_MASK|HSR_CP64_CRM_MASK)
+
+/* Physical Address Register */
+#define PAR_F           (1<<0)
+
+/* .... If F == 1 */
+#define PAR_FSC_SHIFT   (1)
+#define PAR_FSC_MASK    (0x3f<<PAR_FSC_SHIFT)
+#define PAR_STAGE21     (1<<8)     /* Stage 2 Fault During Stage 1 Walk */
+#define PAR_STAGE2      (1<<9)     /* Stage 2 Fault */
+
+/* If F == 0 */
+#define PAR_MAIR_SHIFT  56                       /* Memory Attributes */
+#define PAR_MAIR_MASK   (0xffLL<<PAR_MAIR_SHIFT)
+#define PAR_NS          (1<<9)                   /* Non-Secure */
+#define PAR_SH_SHIFT    7                        /* Shareability */
+#define PAR_SH_MASK     (3<<PAR_SH_SHIFT)
+
+/* Fault Status Register */
+/*
+ * 543210 BIT
+ * 00XXLL -- XX Fault Level LL
+ * ..01LL -- Translation Fault LL
+ * ..10LL -- Access Fault LL
+ * ..11LL -- Permission Fault LL
+ * 01xxxx -- Abort/Parity
+ * 10xxxx -- Other
+ * 11xxxx -- Implementation Defined
+ */
+#define FSC_TYPE_MASK (0x3<<4)
+#define FSC_TYPE_FAULT (0x00<<4)
+#define FSC_TYPE_ABT   (0x01<<4)
+#define FSC_TYPE_OTH   (0x02<<4)
+#define FSC_TYPE_IMPL  (0x03<<4)
+
+#define FSC_FLT_TRANS  (0x04)
+#define FSC_FLT_ACCESS (0x08)
+#define FSC_FLT_PERM   (0x0c)
+#define FSC_SEA        (0x10) /* Synchronous External Abort */
+#define FSC_SPE        (0x18) /* Memory Access Synchronous Parity Error */
+#define FSC_APE        (0x11) /* Memory Access Asynchronous Parity Error */
+#define FSC_SEATT      (0x14) /* Sync. Ext. Abort Translation Table */
+#define FSC_SPETT      (0x1c) /* Sync. Parity. Error Translation Table */
+#define FSC_AF         (0x21) /* Alignment Fault */
+#define FSC_DE         (0x22) /* Debug Event */
+#define FSC_LKD        (0x34) /* Lockdown Abort */
+#define FSC_CPR        (0x3a) /* Coprocossor Abort */
+
+#define FSC_LL_MASK    (0x03<<0)
+
+/* Time counter hypervisor control register */
+#define CNTHCTL_PA      (1u<<0)  /* Kernel/user access to physical counter */
+#define CNTHCTL_TA      (1u<<1)  /* Kernel/user access to CNTP timer */
+
+/* Timer control registers */
+#define CNTx_CTL_ENABLE   (1u<<0)  /* Enable timer */
+#define CNTx_CTL_MASK     (1u<<1)  /* Mask IRQ */
+#define CNTx_CTL_PENDING  (1u<<2)  /* IRQ pending */
+
+/* CPUID bits */
+#define ID_PFR1_GT_MASK  0x000F0000  /* Generic Timer interface support */
+#define ID_PFR1_GT_v1    0x00010000
+
+#define MSR(reg,val)        asm volatile ("msr "#reg", %0\n" : : "r" (val))
+#define MRS(val,reg)        asm volatile ("mrs %0,"#reg"\n" : "=r" (v))
+
+#ifndef __ASSEMBLY__
+extern uint32_t hyp_traps_vector[8];
+
+void panic_PAR(uint64_t par, const char *when);
+
+void show_execution_state(struct cpu_user_regs *regs);
+void show_registers(struct cpu_user_regs *regs);
+//#define dump_execution_state() run_in_exception_handler(show_execution_state)
+#define dump_execution_state() asm volatile (".word 0xe7f000f0\n"); /* XXX */
+
+#define cpu_relax() barrier() /* Could yield? */
+
+/* All a bit UP for the moment */
+#define cpu_to_core(_cpu)   (0)
+#define cpu_to_socket(_cpu) (0)
+
+#endif /* __ASSEMBLY__ */
+#endif /* __ASM_ARM_PROCESSOR_H */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/regs.h b/xen/include/asm-arm/regs.h
new file mode 100644
index 0000000..ee095bf
--- /dev/null
+++ b/xen/include/asm-arm/regs.h
@@ -0,0 +1,43 @@
+#ifndef __ARM_REGS_H__
+#define __ARM_REGS_H__
+
+#include <xen/types.h>
+#include <public/xen.h>
+#include <asm/processor.h>
+
+#define psr_mode(psr,m) (((psr) & PSR_MODE_MASK) == m)
+
+#define usr_mode(r)     psr_mode((r)->cpsr,PSR_MODE_USR)
+#define fiq_mode(r)     psr_mode((r)->cpsr,PSR_MODE_FIQ)
+#define irq_mode(r)     psr_mode((r)->cpsr,PSR_MODE_IRQ)
+#define svc_mode(r)     psr_mode((r)->cpsr,PSR_MODE_SVC)
+#define mon_mode(r)     psr_mode((r)->cpsr,PSR_MODE_MON)
+#define abt_mode(r)     psr_mode((r)->cpsr,PSR_MODE_ABT)
+#define hyp_mode(r)     psr_mode((r)->cpsr,PSR_MODE_HYP)
+#define und_mode(r)     psr_mode((r)->cpsr,PSR_MODE_UND)
+#define sys_mode(r)     psr_mode((r)->cpsr,PSR_MODE_SYS)
+
+#define guest_mode(r)                                                         \
+({                                                                            \
+    unsigned long diff = (char *)guest_cpu_user_regs() - (char *)(r);         \
+    /* Frame pointer must point into current CPU stack. */                    \
+    ASSERT(diff < STACK_SIZE);                                                \
+    /* If not a guest frame, it must be a hypervisor frame. */                \
+    ASSERT((diff == 0) || hyp_mode(r));                                       \
+    /* Return TRUE if it's a guest frame. */                                  \
+    (diff == 0);                                                              \
+})
+
+#define return_reg(v) ((v)->arch.user_regs.r0)
+
+#define CTXT_SWITCH_STACK_BYTES (sizeof(struct cpu_user_regs))
+
+#endif /* __ARM_REGS_H__ */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/setup.h b/xen/include/asm-arm/setup.h
new file mode 100644
index 0000000..c27d438
--- /dev/null
+++ b/xen/include/asm-arm/setup.h
@@ -0,0 +1,16 @@
+#ifndef __ARM_SETUP_H_
+#define __ARM_SETUP_H_
+
+#include <public/version.h>
+
+void arch_get_xen_caps(xen_capabilities_info_t *info);
+
+#endif
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/smp.h b/xen/include/asm-arm/smp.h
new file mode 100644
index 0000000..9cdd87f
--- /dev/null
+++ b/xen/include/asm-arm/smp.h
@@ -0,0 +1,25 @@
+#ifndef __ASM_SMP_H
+#define __ASM_SMP_H
+
+#ifndef __ASSEMBLY__
+#include <xen/config.h>
+#include <xen/cpumask.h>
+#include <asm/current.h>
+#endif
+
+DECLARE_PER_CPU(cpumask_var_t, cpu_sibling_mask);
+DECLARE_PER_CPU(cpumask_var_t, cpu_core_mask);
+
+#define cpu_is_offline(cpu) unlikely(!cpu_online(cpu))
+
+#define raw_smp_processor_id() (get_processor_id())
+
+#endif
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/softirq.h b/xen/include/asm-arm/softirq.h
new file mode 100644
index 0000000..536af38
--- /dev/null
+++ b/xen/include/asm-arm/softirq.h
@@ -0,0 +1,15 @@
+#ifndef __ASM_SOFTIRQ_H__
+#define __ASM_SOFTIRQ_H__
+
+#define VGIC_SOFTIRQ        (NR_COMMON_SOFTIRQS + 0)
+#define NR_ARCH_SOFTIRQS       1
+
+#endif /* __ASM_SOFTIRQ_H__ */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/spinlock.h b/xen/include/asm-arm/spinlock.h
new file mode 100644
index 0000000..b1825c9
--- /dev/null
+++ b/xen/include/asm-arm/spinlock.h
@@ -0,0 +1,144 @@
+#ifndef __ASM_SPINLOCK_H
+#define __ASM_SPINLOCK_H
+
+#include <xen/config.h>
+#include <xen/lib.h>
+
+static inline void dsb_sev(void)
+{
+    __asm__ __volatile__ (
+        "dsb\n"
+        "sev\n"
+        );
+}
+
+typedef struct {
+    volatile unsigned int lock;
+} raw_spinlock_t;
+
+#define _RAW_SPIN_LOCK_UNLOCKED { 0 }
+
+#define _raw_spin_is_locked(x)          ((x)->lock != 0)
+
+static always_inline void _raw_spin_unlock(raw_spinlock_t *lock)
+{
+    ASSERT(_raw_spin_is_locked(lock));
+
+    smp_mb();
+
+    __asm__ __volatile__(
+"   str     %1, [%0]\n"
+    :
+    : "r" (&lock->lock), "r" (0)
+    : "cc");
+
+    dsb_sev();
+}
+
+static always_inline int _raw_spin_trylock(raw_spinlock_t *lock)
+{
+    unsigned long tmp;
+
+    __asm__ __volatile__(
+"   ldrex   %0, [%1]\n"
+"   teq     %0, #0\n"
+"   strexeq %0, %2, [%1]"
+    : "=&r" (tmp)
+    : "r" (&lock->lock), "r" (1)
+    : "cc");
+
+    if (tmp == 0) {
+        smp_mb();
+        return 1;
+    } else {
+        return 0;
+    }
+}
+
+typedef struct {
+    volatile unsigned int lock;
+} raw_rwlock_t;
+
+#define _RAW_RW_LOCK_UNLOCKED { 0 }
+
+static always_inline int _raw_read_trylock(raw_rwlock_t *rw)
+{
+    unsigned long tmp, tmp2 = 1;
+
+    __asm__ __volatile__(
+"1: ldrex   %0, [%2]\n"
+"   adds    %0, %0, #1\n"
+"   strexpl %1, %0, [%2]\n"
+    : "=&r" (tmp), "+r" (tmp2)
+    : "r" (&rw->lock)
+    : "cc");
+
+    smp_mb();
+    return tmp2 == 0;
+}
+
+static always_inline int _raw_write_trylock(raw_rwlock_t *rw)
+{
+    unsigned long tmp;
+
+    __asm__ __volatile__(
+"1: ldrex   %0, [%1]\n"
+"   teq     %0, #0\n"
+"   strexeq %0, %2, [%1]"
+    : "=&r" (tmp)
+    : "r" (&rw->lock), "r" (0x80000000)
+    : "cc");
+
+    if (tmp == 0) {
+        smp_mb();
+        return 1;
+    } else {
+        return 0;
+    }
+}
+
+static inline void _raw_read_unlock(raw_rwlock_t *rw)
+{
+    unsigned long tmp, tmp2;
+
+    smp_mb();
+
+    __asm__ __volatile__(
+"1: ldrex   %0, [%2]\n"
+"   sub     %0, %0, #1\n"
+"   strex   %1, %0, [%2]\n"
+"   teq     %1, #0\n"
+"   bne     1b"
+    : "=&r" (tmp), "=&r" (tmp2)
+    : "r" (&rw->lock)
+    : "cc");
+
+    if (tmp == 0)
+        dsb_sev();
+}
+
+static inline void _raw_write_unlock(raw_rwlock_t *rw)
+{
+    smp_mb();
+
+    __asm__ __volatile__(
+    "str    %1, [%0]\n"
+    :
+    : "r" (&rw->lock), "r" (0)
+    : "cc");
+
+    dsb_sev();
+}
+
+#define _raw_rw_is_locked(x) ((x)->lock != 0)
+#define _raw_rw_is_write_locked(x) ((x)->lock == 0x80000000)
+
+#endif /* __ASM_SPINLOCK_H */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/string.h b/xen/include/asm-arm/string.h
new file mode 100644
index 0000000..f2d643d
--- /dev/null
+++ b/xen/include/asm-arm/string.h
@@ -0,0 +1,38 @@
+#ifndef __ARM_STRING_H__
+#define __ARM_STRING_H__
+
+#include <xen/config.h>
+
+#define __HAVE_ARCH_MEMCPY
+extern void * memcpy(void *, const void *, __kernel_size_t);
+
+/* Some versions of gcc don't have this builtin. It's non-critical anyway. */
+#define __HAVE_ARCH_MEMMOVE
+extern void *memmove(void *dest, const void *src, size_t n);
+
+#define __HAVE_ARCH_MEMSET
+extern void * memset(void *, int, __kernel_size_t);
+
+extern void __memzero(void *ptr, __kernel_size_t n);
+
+#define memset(p,v,n)                                                   \
+        ({                                                              \
+                void *__p = (p); size_t __n = n;                        \
+                if ((__n) != 0) {                                       \
+                        if (__builtin_constant_p((v)) && (v) == 0)      \
+                                __memzero((__p),(__n));                 \
+                        else                                            \
+                                memset((__p),(v),(__n));                \
+                }                                                       \
+                (__p);                                                  \
+        })
+
+#endif /* __ARM_STRING_H__ */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/system.h b/xen/include/asm-arm/system.h
new file mode 100644
index 0000000..731d89f
--- /dev/null
+++ b/xen/include/asm-arm/system.h
@@ -0,0 +1,202 @@
+/* Portions taken from Linux arch arm */
+#ifndef __ASM_SYSTEM_H
+#define __ASM_SYSTEM_H
+
+#include <xen/lib.h>
+#include <asm/processor.h>
+
+#define nop() \
+    asm volatile ( "nop" )
+
+#define xchg(ptr,x) \
+        ((__typeof__(*(ptr)))__xchg((unsigned long)(x),(ptr),sizeof(*(ptr))))
+
+#define isb() __asm__ __volatile__ ("isb" : : : "memory")
+#define dsb() __asm__ __volatile__ ("dsb" : : : "memory")
+#define dmb() __asm__ __volatile__ ("dmb" : : : "memory")
+
+#define mb()            dsb()
+#define rmb()           dsb()
+#define wmb()           mb()
+
+#define smp_mb()        dmb()
+#define smp_rmb()       dmb()
+#define smp_wmb()       dmb()
+
+/*
+ * This is used to ensure the compiler did actually allocate the register we
+ * asked it for some inline assembly sequences.  Apparently we can't trust
+ * the compiler from one version to another so a bit of paranoia won't hurt.
+ * This string is meant to be concatenated with the inline asm string and
+ * will cause compilation to stop on mismatch.
+ * (for details, see gcc PR 15089)
+ */
+#define __asmeq(x, y)  ".ifnc " x "," y " ; .err ; .endif\n\t"
+
+extern void __bad_xchg(volatile void *, int);
+
+static inline unsigned long __xchg(unsigned long x, volatile void *ptr, int size)
+{
+        unsigned long ret;
+        unsigned int tmp;
+
+        smp_mb();
+
+        switch (size) {
+        case 1:
+                asm volatile("@ __xchg1\n"
+                "1:     ldrexb  %0, [%3]\n"
+                "       strexb  %1, %2, [%3]\n"
+                "       teq     %1, #0\n"
+                "       bne     1b"
+                        : "=&r" (ret), "=&r" (tmp)
+                        : "r" (x), "r" (ptr)
+                        : "memory", "cc");
+                break;
+        case 4:
+                asm volatile("@ __xchg4\n"
+                "1:     ldrex   %0, [%3]\n"
+                "       strex   %1, %2, [%3]\n"
+                "       teq     %1, #0\n"
+                "       bne     1b"
+                        : "=&r" (ret), "=&r" (tmp)
+                        : "r" (x), "r" (ptr)
+                        : "memory", "cc");
+                break;
+        default:
+                __bad_xchg(ptr, size), ret = 0;
+                break;
+        }
+        smp_mb();
+
+        return ret;
+}
+
+/*
+ * Atomic compare and exchange.  Compare OLD with MEM, if identical,
+ * store NEW in MEM.  Return the initial value in MEM.  Success is
+ * indicated by comparing RETURN with OLD.
+ */
+
+extern void __bad_cmpxchg(volatile void *ptr, int size);
+
+static always_inline unsigned long __cmpxchg(
+    volatile void *ptr, unsigned long old, unsigned long new, int size)
+{
+    unsigned long /*long*/ oldval, res;
+
+    switch (size) {
+    case 1:
+        do {
+            asm volatile("@ __cmpxchg1\n"
+                         "       ldrexb  %1, [%2]\n"
+                         "       mov     %0, #0\n"
+                         "       teq     %1, %3\n"
+                         "       strexbeq %0, %4, [%2]\n"
+                         : "=&r" (res), "=&r" (oldval)
+                         : "r" (ptr), "Ir" (old), "r" (new)
+                         : "memory", "cc");
+        } while (res);
+        break;
+    case 2:
+        do {
+            asm volatile("@ __cmpxchg2\n"
+                         "       ldrexh  %1, [%2]\n"
+                         "       mov     %0, #0\n"
+                         "       teq     %1, %3\n"
+                         "       strexheq %0, %4, [%2]\n"
+                         : "=&r" (res), "=&r" (oldval)
+                         : "r" (ptr), "Ir" (old), "r" (new)
+                         : "memory", "cc");
+        } while (res);
+        break;
+    case 4:
+        do {
+            asm volatile("@ __cmpxchg4\n"
+                         "       ldrex   %1, [%2]\n"
+                         "       mov     %0, #0\n"
+                         "       teq     %1, %3\n"
+                         "       strexeq %0, %4, [%2]\n"
+                         : "=&r" (res), "=&r" (oldval)
+                         : "r" (ptr), "Ir" (old), "r" (new)
+                         : "memory", "cc");
+        } while (res);
+        break;
+#if 0
+    case 8:
+        do {
+            asm volatile("@ __cmpxchg8\n"
+                         "       ldrexd   %1, [%2]\n"
+                         "       mov      %0, #0\n"
+                         "       teq      %1, %3\n"
+                         "       strexdeq %0, %4, [%2]\n"
+                         : "=&r" (res), "=&r" (oldval)
+                         : "r" (ptr), "Ir" (old), "r" (new)
+                         : "memory", "cc");
+        } while (res);
+        break;
+#endif
+    default:
+        __bad_cmpxchg(ptr, size);
+        oldval = 0;
+    }
+
+    return oldval;
+}
+#define cmpxchg(ptr,o,n)                                                \
+    ((__typeof__(*(ptr)))__cmpxchg((ptr),(unsigned long)(o),            \
+                                   (unsigned long)(n),sizeof(*(ptr))))
+
+#define local_irq_disable() asm volatile ( "cpsid i @ local_irq_disable\n" : : : "cc" )
+#define local_irq_enable()  asm volatile ( "cpsie i @ local_irq_enable\n" : : : "cc" )
+
+#define local_save_flags(x)                                      \
+({                                                               \
+    BUILD_BUG_ON(sizeof(x) != sizeof(long));                     \
+    asm volatile ( "mrs %0, cpsr     @ local_save_flags\n"       \
+                  : "=r" (x) :: "memory", "cc" );                \
+})
+#define local_irq_save(x)                                        \
+({                                                               \
+    local_save_flags(x);                                         \
+    local_irq_disable();                                         \
+})
+#define local_irq_restore(x)                                     \
+({                                                               \
+    BUILD_BUG_ON(sizeof(x) != sizeof(long));                     \
+    asm volatile (                                               \
+            "msr     cpsr_c, %0      @ local_irq_restore\n"      \
+            :                                                    \
+            : "r" (flags)                                        \
+            : "memory", "cc");                                   \
+})
+
+static inline int local_irq_is_enabled(void)
+{
+    unsigned long flags;
+    local_save_flags(flags);
+    return !(flags & PSR_IRQ_MASK);
+}
+
+#define local_fiq_enable()  __asm__("cpsie f   @ __stf\n" : : : "memory", "cc")
+#define local_fiq_disable() __asm__("cpsid f   @ __clf\n" : : : "memory", "cc")
+
+#define local_abort_enable() __asm__("cpsie a  @ __sta\n" : : : "memory", "cc")
+#define local_abort_disable() __asm__("cpsid a @ __sta\n" : : : "memory", "cc")
+
+static inline int local_fiq_is_enabled(void)
+{
+    unsigned long flags;
+    local_save_flags(flags);
+    return !!(flags & PSR_FIQ_MASK);
+}
+
+#endif
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/trace.h b/xen/include/asm-arm/trace.h
new file mode 100644
index 0000000..db84541
--- /dev/null
+++ b/xen/include/asm-arm/trace.h
@@ -0,0 +1,12 @@
+#ifndef __ASM_TRACE_H__
+#define __ASM_TRACE_H__
+
+#endif /* __ASM_TRACE_H__ */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/types.h b/xen/include/asm-arm/types.h
new file mode 100644
index 0000000..48864f9
--- /dev/null
+++ b/xen/include/asm-arm/types.h
@@ -0,0 +1,57 @@
+#ifndef __ARM_TYPES_H__
+#define __ARM_TYPES_H__
+
+#ifndef __ASSEMBLY__
+
+#include <xen/config.h>
+
+typedef __signed__ char __s8;
+typedef unsigned char __u8;
+
+typedef __signed__ short __s16;
+typedef unsigned short __u16;
+
+typedef __signed__ int __s32;
+typedef unsigned int __u32;
+
+#if defined(__GNUC__) && !defined(__STRICT_ANSI__)
+typedef __signed__ long long __s64;
+typedef unsigned long long __u64;
+#endif
+
+typedef signed char s8;
+typedef unsigned char u8;
+
+typedef signed short s16;
+typedef unsigned short u16;
+
+typedef signed int s32;
+typedef unsigned int u32;
+
+typedef signed long long s64;
+typedef unsigned long long u64;
+typedef u64 paddr_t;
+#define INVALID_PADDR (~0ULL)
+#define PRIpaddr "016llx"
+
+typedef unsigned long size_t;
+
+typedef char bool_t;
+#define test_and_set_bool(b)   xchg(&(b), 1)
+#define test_and_clear_bool(b) xchg(&(b), 0)
+
+#endif /* __ASSEMBLY__ */
+
+#define BITS_PER_LONG 32
+#define BYTES_PER_LONG 4
+#define LONG_BYTEORDER 2
+
+#endif /* __ARM_TYPES_H__ */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/xenoprof.h b/xen/include/asm-arm/xenoprof.h
new file mode 100644
index 0000000..131ac13
--- /dev/null
+++ b/xen/include/asm-arm/xenoprof.h
@@ -0,0 +1,12 @@
+#ifndef __ASM_XENOPROF_H__
+#define __ASM_XENOPROF_H__
+
+#endif /* __ASM_XENOPROF_H__ */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
new file mode 100644
index 0000000..4d1daa9
--- /dev/null
+++ b/xen/include/public/arch-arm.h
@@ -0,0 +1,125 @@
+/******************************************************************************
+ * arch-arm.h
+ *
+ * Guest OS interface to ARM 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 2011 (C) Citrix Systems
+ */
+
+#ifndef __XEN_PUBLIC_ARCH_ARM_H__
+#define __XEN_PUBLIC_ARCH_ARM_H__
+
+#ifndef __ASSEMBLY__
+#define ___DEFINE_XEN_GUEST_HANDLE(name, type) \
+    typedef struct { type *p; } __guest_handle_ ## name
+
+#define __DEFINE_XEN_GUEST_HANDLE(name, type) \
+    ___DEFINE_XEN_GUEST_HANDLE(name, type);   \
+    ___DEFINE_XEN_GUEST_HANDLE(const_##name, const type)
+#define DEFINE_XEN_GUEST_HANDLE(name)   __DEFINE_XEN_GUEST_HANDLE(name, name)
+#define __XEN_GUEST_HANDLE(name)        __guest_handle_ ## name
+#define XEN_GUEST_HANDLE(name)          __XEN_GUEST_HANDLE(name)
+#define set_xen_guest_handle_raw(hnd, val)  do { (hnd).p = val; } while (0)
+#ifdef __XEN_TOOLS__
+#define get_xen_guest_handle(val, hnd)  do { val = (hnd).p; } while (0)
+#endif
+#define set_xen_guest_handle(hnd, val) set_xen_guest_handle_raw(hnd, val)
+
+struct cpu_user_regs
+{
+    uint32_t r0;
+    uint32_t r1;
+    uint32_t r2;
+    uint32_t r3;
+    uint32_t r4;
+    uint32_t r5;
+    uint32_t r6;
+    uint32_t r7;
+    uint32_t r8;
+    uint32_t r9;
+    uint32_t r10;
+    union {
+	uint32_t r11;
+	uint32_t fp;
+    };
+    uint32_t r12;
+
+    uint32_t sp; /* r13 - SP: Valid for Hyp. frames only, o/w banked (see below) */
+    uint32_t lr; /* r14 - LR: Valid for Hyp. Same physical register as lr_usr. */
+
+    uint32_t pc; /* Return IP */
+    uint32_t cpsr; /* Return mode */
+    uint32_t pad0; /* Doubleword-align the kernel half of the frame */
+
+    /* Outer guest frame only from here on... */
+
+    uint32_t r8_fiq, r9_fiq, r10_fiq, r11_fiq, r12_fiq;
+
+    uint32_t sp_usr, sp_svc, sp_abt, sp_und, sp_irq, sp_fiq;
+    uint32_t lr_usr, lr_svc, lr_abt, lr_und, lr_irq, lr_fiq;
+
+    uint32_t spsr_svc, spsr_abt, spsr_und, spsr_irq, spsr_fiq;
+};
+typedef struct cpu_user_regs cpu_user_regs_t;
+DEFINE_XEN_GUEST_HANDLE(cpu_user_regs_t);
+
+typedef uint64_t xen_pfn_t;
+#define PRI_xen_pfn PRIx64
+
+/* Maximum number of virtual CPUs in legacy multi-processor guests. */
+/* Only one. All other VCPUS must use VCPUOP_register_vcpu_info */
+#define XEN_LEGACY_MAX_VCPUS 1
+
+typedef uint32_t xen_ulong_t;
+
+struct vcpu_guest_context {
+    struct cpu_user_regs user_regs;         /* User-level CPU registers     */
+    union {
+	uint32_t reg[16];
+	struct {
+	    uint32_t __pad[12];
+	    uint32_t sp; /* r13 */
+	    uint32_t lr; /* r14 */
+	    uint32_t pc; /* r15 */
+	};
+    };
+};
+typedef struct vcpu_guest_context vcpu_guest_context_t;
+DEFINE_XEN_GUEST_HANDLE(vcpu_guest_context_t);
+
+struct arch_vcpu_info { };
+typedef struct arch_vcpu_info arch_vcpu_info_t;
+
+struct arch_shared_info { };
+typedef struct arch_shared_info arch_shared_info_t;
+#endif
+
+#endif /*  __XEN_PUBLIC_ARCH_ARM_H__ */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
index fde9fa5..7196400 100644
--- a/xen/include/public/xen.h
+++ b/xen/include/public/xen.h
@@ -33,6 +33,8 @@
 #include "arch-x86/xen.h"
 #elif defined(__ia64__)
 #include "arch-ia64.h"
+#elif defined(__arm__)
+#include "arch-arm.h"
 #else
 #error "Unsupported architecture"
 #endif
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 16:29:28 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 16: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.xensource.com>)
	id 1RbEBQ-0002BT-BK; Thu, 15 Dec 2011 16:29:24 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RbEBO-00024T-Tp
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 16:29:23 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1323966553!7437895!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjE2NDg=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9394 invoked from network); 15 Dec 2011 16:29:16 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 16:29:16 -0000
X-IronPort-AV: E=Sophos;i="4.71,357,1320642000"; d="scan'208";a="174308231"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Dec 2011 11:29:16 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Thu, 15 Dec 2011 11:29:15 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pBFGSMte003330;
	Thu, 15 Dec 2011 08:28:58 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Thu, 15 Dec 2011 16:30:48 +0000
Message-ID: <1323966657-19790-16-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1112131831560.3517@kaball-desktop>
References: <alpine.DEB.2.00.1112131831560.3517@kaball-desktop>
MIME-Version: 1.0
Cc: keir.xen@gmail.com, Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, JBeulich@suse.com,
	Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v3 16/25] arm: irq
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

A simple do_IRQ and request_irq implementation for ARM.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
---
 xen/arch/arm/irq.c          |  179 +++++++++++++++++++++++++++++++++++++++++++
 xen/include/asm-arm/irq.h   |   30 +++++++
 xen/include/asm-arm/setup.h |    2 +
 xen/include/xen/irq.h       |   13 +++
 4 files changed, 224 insertions(+), 0 deletions(-)
 create mode 100644 xen/arch/arm/irq.c
 create mode 100644 xen/include/asm-arm/irq.h

diff --git a/xen/arch/arm/irq.c b/xen/arch/arm/irq.c
new file mode 100644
index 0000000..5663762
--- /dev/null
+++ b/xen/arch/arm/irq.c
@@ -0,0 +1,179 @@
+/*
+ * xen/arch/arm/irq.c
+ *
+ * ARM Interrupt support
+ *
+ * Ian Campbell <ian.campbell@citrix.com>
+ * Copyright (c) 2011 Citrix Systems.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include <xen/config.h>
+#include <xen/lib.h>
+#include <xen/spinlock.h>
+#include <xen/irq.h>
+#include <xen/init.h>
+#include <xen/errno.h>
+#include <xen/sched.h>
+
+#include "gic.h"
+
+static void enable_none(struct irq_desc *irq) { }
+static unsigned int startup_none(struct irq_desc *irq) { return 0; }
+static void disable_none(struct irq_desc *irq) { }
+static void ack_none(struct irq_desc *irq)
+{
+    printk("unexpected IRQ trap at irq %02x\n", irq->irq);
+}
+
+#define shutdown_none   disable_none
+#define end_none        enable_none
+
+hw_irq_controller no_irq_type = {
+    .typename = "none",
+    .startup = startup_none,
+    .shutdown = shutdown_none,
+    .enable = enable_none,
+    .disable = disable_none,
+    .ack = ack_none,
+    .end = end_none
+};
+
+int __init arch_init_one_irq_desc(struct irq_desc *desc)
+{
+	return 0;
+}
+
+
+static int __init init_irq_data(void)
+{
+    int irq;
+
+    for (irq = 0; irq < NR_IRQS; irq++) {
+        struct irq_desc *desc = irq_to_desc(irq);
+        init_one_irq_desc(desc);
+        desc->irq = irq;
+        desc->action  = NULL;
+    }
+    return 0;
+}
+
+void __init init_IRQ(void)
+{
+    BUG_ON(init_irq_data() < 0);
+}
+
+int __init request_irq(unsigned int irq,
+        void (*handler)(int, void *, struct cpu_user_regs *),
+        unsigned long irqflags, const char * devname, void *dev_id)
+{
+    struct irqaction *action;
+    int retval;
+
+    /*
+     * Sanity-check: shared interrupts must pass in a real dev-ID,
+     * otherwise we'll have trouble later trying to figure out
+     * which interrupt is which (messes up the interrupt freeing
+     * logic etc).
+     */
+    if (irq >= nr_irqs)
+        return -EINVAL;
+    if (!handler)
+        return -EINVAL;
+
+    action = xmalloc(struct irqaction);
+    if (!action)
+        return -ENOMEM;
+
+    action->handler = handler;
+    action->name = devname;
+    action->dev_id = dev_id;
+    action->free_on_release = 1;
+
+    retval = setup_irq(irq, action);
+    if (retval)
+        xfree(action);
+
+    return retval;
+}
+
+/* Dispatch an interrupt */
+void do_IRQ(struct cpu_user_regs *regs, unsigned int irq, int is_fiq)
+{
+    struct irq_desc *desc = irq_to_desc(irq);
+    struct irqaction *action = desc->action;
+
+    /* TODO: perfc_incr(irqs); */
+
+    /* TODO: this_cpu(irq_count)++; */
+
+    irq_enter();
+
+    spin_lock(&desc->lock);
+    desc->handler->ack(desc);
+
+    if ( action == NULL )
+    {
+        printk("Unknown %s %#3.3x\n",
+               is_fiq ? "FIQ" : "IRQ", irq);
+        goto out;
+    }
+
+    if ( desc->status & IRQ_GUEST )
+    {
+        struct domain *d = action->dev_id;
+
+        desc->handler->end(desc);
+
+        desc->status |= IRQ_INPROGRESS;
+
+        /* XXX: inject irq into the guest */
+        goto out_no_end;
+    }
+
+    desc->status |= IRQ_PENDING;
+
+    /*
+     * Since we set PENDING, if another processor is handling a different
+     * instance of this same irq, the other processor will take care of it.
+     */
+    if ( desc->status & (IRQ_DISABLED | IRQ_INPROGRESS) )
+        goto out;
+
+    desc->status |= IRQ_INPROGRESS;
+
+    action = desc->action;
+    while ( desc->status & IRQ_PENDING )
+    {
+        desc->status &= ~IRQ_PENDING;
+        spin_unlock_irq(&desc->lock);
+        action->handler(irq, action->dev_id, regs);
+        spin_lock_irq(&desc->lock);
+    }
+
+    desc->status &= ~IRQ_INPROGRESS;
+
+out:
+    desc->handler->end(desc);
+out_no_end:
+    spin_unlock(&desc->lock);
+    irq_exit();
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/irq.h b/xen/include/asm-arm/irq.h
new file mode 100644
index 0000000..8e65a2e
--- /dev/null
+++ b/xen/include/asm-arm/irq.h
@@ -0,0 +1,30 @@
+#ifndef _ASM_HW_IRQ_H
+#define _ASM_HW_IRQ_H
+
+#include <xen/config.h>
+
+#define NR_VECTORS 256 /* XXX */
+
+typedef struct {
+    DECLARE_BITMAP(_bits,NR_VECTORS);
+} vmask_t;
+
+struct arch_pirq
+{
+};
+
+struct irq_cfg {
+#define arch_irq_desc irq_cfg
+};
+
+void do_IRQ(struct cpu_user_regs *regs, unsigned int irq, int is_fiq);
+
+#endif /* _ASM_HW_IRQ_H */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/setup.h b/xen/include/asm-arm/setup.h
index 1dc3f97..2041f06 100644
--- a/xen/include/asm-arm/setup.h
+++ b/xen/include/asm-arm/setup.h
@@ -7,6 +7,8 @@ void arch_get_xen_caps(xen_capabilities_info_t *info);
 
 int construct_dom0(struct domain *d);
 
+void init_IRQ(void);
+
 #endif
 /*
  * Local variables:
diff --git a/xen/include/xen/irq.h b/xen/include/xen/irq.h
index a2a90e1..5a711cc 100644
--- a/xen/include/xen/irq.h
+++ b/xen/include/xen/irq.h
@@ -107,6 +107,19 @@ extern irq_desc_t irq_desc[NR_VECTORS];
 
 #define request_irq(irq, handler, irqflags, devname, devid) \
     request_irq_vector(irq_to_vector(irq), handler, irqflags, devname, devid)
+
+#elif defined(__arm__)
+
+#define NR_IRQS		1024
+#define nr_irqs NR_IRQS
+extern irq_desc_t irq_desc[NR_IRQS];
+
+extern int setup_irq(unsigned int irq, struct irqaction *);
+extern void release_irq(unsigned int irq);
+extern int request_irq(unsigned int irq,
+               void (*handler)(int, void *, struct cpu_user_regs *),
+               unsigned long irqflags, const char * devname, void *dev_id);
+
 #else
 extern int setup_irq(unsigned int irq, struct irqaction *);
 extern void release_irq(unsigned int irq);
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 16:29:28 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 16: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.xensource.com>)
	id 1RbEBT-0002G1-71; Thu, 15 Dec 2011 16:29:27 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RbEBQ-000263-LU
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 16:29:25 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1323966500!60916191!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDY5Mjg=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17608 invoked from network); 15 Dec 2011 16:28:23 -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;
	15 Dec 2011 16:28:23 -0000
X-IronPort-AV: E=Sophos;i="4.71,357,1320642000"; d="scan'208";a="20001868"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Dec 2011 11:29:16 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Thu, 15 Dec 2011 11:29:02 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pBFGSMtX003330;
	Thu, 15 Dec 2011 08:28:45 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Thu, 15 Dec 2011 16:30:41 +0000
Message-ID: <1323966657-19790-9-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1112131831560.3517@kaball-desktop>
References: <alpine.DEB.2.00.1112131831560.3517@kaball-desktop>
MIME-Version: 1.0
Cc: keir.xen@gmail.com, Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, JBeulich@suse.com,
	Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v3 09/25] arm: header files
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

A simple implementation of everything under asm-arm and arch-arm.h; some
of these files are shamelessly taken from Linux.


Changes in v2:

- remove div64.


Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
---
 xen/include/asm-arm/atomic.h      |  212 +++++++++++++++++++++++++++++
 xen/include/asm-arm/bitops.h      |  195 +++++++++++++++++++++++++++
 xen/include/asm-arm/bug.h         |   15 ++
 xen/include/asm-arm/byteorder.h   |   16 +++
 xen/include/asm-arm/cache.h       |   20 +++
 xen/include/asm-arm/config.h      |  122 +++++++++++++++++
 xen/include/asm-arm/cpregs.h      |  207 ++++++++++++++++++++++++++++
 xen/include/asm-arm/current.h     |   60 ++++++++
 xen/include/asm-arm/debugger.h    |   15 ++
 xen/include/asm-arm/delay.h       |   15 ++
 xen/include/asm-arm/desc.h        |   12 ++
 xen/include/asm-arm/div64.h       |  235 ++++++++++++++++++++++++++++++++
 xen/include/asm-arm/elf.h         |   33 +++++
 xen/include/asm-arm/event.h       |   41 ++++++
 xen/include/asm-arm/flushtlb.h    |   31 +++++
 xen/include/asm-arm/grant_table.h |   35 +++++
 xen/include/asm-arm/hardirq.h     |   28 ++++
 xen/include/asm-arm/hypercall.h   |   24 ++++
 xen/include/asm-arm/init.h        |   12 ++
 xen/include/asm-arm/io.h          |   12 ++
 xen/include/asm-arm/iocap.h       |   20 +++
 xen/include/asm-arm/multicall.h   |   23 +++
 xen/include/asm-arm/nmi.h         |   15 ++
 xen/include/asm-arm/numa.h        |   21 +++
 xen/include/asm-arm/paging.h      |   13 ++
 xen/include/asm-arm/percpu.h      |   28 ++++
 xen/include/asm-arm/processor.h   |  269 +++++++++++++++++++++++++++++++++++++
 xen/include/asm-arm/regs.h        |   43 ++++++
 xen/include/asm-arm/setup.h       |   16 +++
 xen/include/asm-arm/smp.h         |   25 ++++
 xen/include/asm-arm/softirq.h     |   15 ++
 xen/include/asm-arm/spinlock.h    |  144 ++++++++++++++++++++
 xen/include/asm-arm/string.h      |   38 +++++
 xen/include/asm-arm/system.h      |  202 ++++++++++++++++++++++++++++
 xen/include/asm-arm/trace.h       |   12 ++
 xen/include/asm-arm/types.h       |   57 ++++++++
 xen/include/asm-arm/xenoprof.h    |   12 ++
 xen/include/public/arch-arm.h     |  125 +++++++++++++++++
 xen/include/public/xen.h          |    2 +
 39 files changed, 2420 insertions(+), 0 deletions(-)
 create mode 100644 xen/include/asm-arm/atomic.h
 create mode 100644 xen/include/asm-arm/bitops.h
 create mode 100644 xen/include/asm-arm/bug.h
 create mode 100644 xen/include/asm-arm/byteorder.h
 create mode 100644 xen/include/asm-arm/cache.h
 create mode 100644 xen/include/asm-arm/config.h
 create mode 100644 xen/include/asm-arm/cpregs.h
 create mode 100644 xen/include/asm-arm/current.h
 create mode 100644 xen/include/asm-arm/debugger.h
 create mode 100644 xen/include/asm-arm/delay.h
 create mode 100644 xen/include/asm-arm/desc.h
 create mode 100644 xen/include/asm-arm/div64.h
 create mode 100644 xen/include/asm-arm/elf.h
 create mode 100644 xen/include/asm-arm/event.h
 create mode 100644 xen/include/asm-arm/flushtlb.h
 create mode 100644 xen/include/asm-arm/grant_table.h
 create mode 100644 xen/include/asm-arm/hardirq.h
 create mode 100644 xen/include/asm-arm/hypercall.h
 create mode 100644 xen/include/asm-arm/init.h
 create mode 100644 xen/include/asm-arm/io.h
 create mode 100644 xen/include/asm-arm/iocap.h
 create mode 100644 xen/include/asm-arm/multicall.h
 create mode 100644 xen/include/asm-arm/nmi.h
 create mode 100644 xen/include/asm-arm/numa.h
 create mode 100644 xen/include/asm-arm/paging.h
 create mode 100644 xen/include/asm-arm/percpu.h
 create mode 100644 xen/include/asm-arm/processor.h
 create mode 100644 xen/include/asm-arm/regs.h
 create mode 100644 xen/include/asm-arm/setup.h
 create mode 100644 xen/include/asm-arm/smp.h
 create mode 100644 xen/include/asm-arm/softirq.h
 create mode 100644 xen/include/asm-arm/spinlock.h
 create mode 100644 xen/include/asm-arm/string.h
 create mode 100644 xen/include/asm-arm/system.h
 create mode 100644 xen/include/asm-arm/trace.h
 create mode 100644 xen/include/asm-arm/types.h
 create mode 100644 xen/include/asm-arm/xenoprof.h
 create mode 100644 xen/include/public/arch-arm.h

diff --git a/xen/include/asm-arm/atomic.h b/xen/include/asm-arm/atomic.h
new file mode 100644
index 0000000..2b9ce0e
--- /dev/null
+++ b/xen/include/asm-arm/atomic.h
@@ -0,0 +1,212 @@
+/*
+ *  arch/arm/include/asm/atomic.h
+ *
+ *  Copyright (C) 1996 Russell King.
+ *  Copyright (C) 2002 Deep Blue Solutions Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#ifndef __ARCH_ARM_ATOMIC__
+#define __ARCH_ARM_ATOMIC__
+
+#include <xen/config.h>
+#include <asm/system.h>
+
+#define build_atomic_read(name, size, type, reg)   \
+static inline type name(const volatile type *addr) \
+{                                                  \
+    type ret;                                      \
+    asm volatile("ldr" size " %0,%1"               \
+                 : reg (ret)                       \
+                 : "m" (*(volatile type *)addr));  \
+    return ret;                                    \
+}
+
+#define build_atomic_write(name, size, type, reg)      \
+static inline void name(volatile type *addr, type val) \
+{                                                      \
+    asm volatile("str" size " %1,%0"                   \
+                 : "=m" (*(volatile type *)addr)       \
+                 : reg (val));                         \
+}
+
+build_atomic_read(atomic_read8, "b", uint8_t, "=q")
+build_atomic_read(atomic_read16, "h", uint16_t, "=r")
+build_atomic_read(atomic_read32, "", uint32_t, "=r")
+//build_atomic_read(atomic_read64, "d", uint64_t, "=r")
+build_atomic_read(atomic_read_int, "", int, "=r")
+
+build_atomic_write(atomic_write8, "b", uint8_t, "q")
+build_atomic_write(atomic_write16, "h", uint16_t, "r")
+build_atomic_write(atomic_write32, "", uint32_t, "r")
+//build_atomic_write(atomic_write64, "d", uint64_t, "r")
+build_atomic_write(atomic_write_int, "", int, "r")
+
+/*
+ * NB. I've pushed the volatile qualifier into the operations. This allows
+ * fast accessors such as _atomic_read() and _atomic_set() which don't give
+ * the compiler a fit.
+ */
+typedef struct { int counter; } atomic_t;
+
+#define ATOMIC_INIT(i) { (i) }
+
+/*
+ * On ARM, ordinary assignment (str instruction) doesn't clear the local
+ * strex/ldrex monitor on some implementations. The reason we can use it for
+ * atomic_set() is the clrex or dummy strex done on every exception return.
+ */
+#define _atomic_read(v) ((v).counter)
+#define atomic_read(v)  (*(volatile int *)&(v)->counter)
+
+#define _atomic_set(v,i) (((v).counter) = (i))
+#define atomic_set(v,i) (((v)->counter) = (i))
+
+/*
+ * ARMv6 UP and SMP safe atomic ops.  We use load exclusive and
+ * store exclusive to ensure that these are atomic.  We may loop
+ * to ensure that the update happens.
+ */
+static inline void atomic_add(int i, atomic_t *v)
+{
+        unsigned long tmp;
+        int result;
+
+        __asm__ __volatile__("@ atomic_add\n"
+"1:     ldrex   %0, [%3]\n"
+"       add     %0, %0, %4\n"
+"       strex   %1, %0, [%3]\n"
+"       teq     %1, #0\n"
+"       bne     1b"
+        : "=&r" (result), "=&r" (tmp), "+Qo" (v->counter)
+        : "r" (&v->counter), "Ir" (i)
+        : "cc");
+}
+
+static inline int atomic_add_return(int i, atomic_t *v)
+{
+        unsigned long tmp;
+        int result;
+
+        smp_mb();
+
+        __asm__ __volatile__("@ atomic_add_return\n"
+"1:     ldrex   %0, [%3]\n"
+"       add     %0, %0, %4\n"
+"       strex   %1, %0, [%3]\n"
+"       teq     %1, #0\n"
+"       bne     1b"
+        : "=&r" (result), "=&r" (tmp), "+Qo" (v->counter)
+        : "r" (&v->counter), "Ir" (i)
+        : "cc");
+
+        smp_mb();
+
+        return result;
+}
+
+static inline void atomic_sub(int i, atomic_t *v)
+{
+        unsigned long tmp;
+        int result;
+
+        __asm__ __volatile__("@ atomic_sub\n"
+"1:     ldrex   %0, [%3]\n"
+"       sub     %0, %0, %4\n"
+"       strex   %1, %0, [%3]\n"
+"       teq     %1, #0\n"
+"       bne     1b"
+        : "=&r" (result), "=&r" (tmp), "+Qo" (v->counter)
+        : "r" (&v->counter), "Ir" (i)
+        : "cc");
+}
+
+static inline int atomic_sub_return(int i, atomic_t *v)
+{
+        unsigned long tmp;
+        int result;
+
+        smp_mb();
+
+        __asm__ __volatile__("@ atomic_sub_return\n"
+"1:     ldrex   %0, [%3]\n"
+"       sub     %0, %0, %4\n"
+"       strex   %1, %0, [%3]\n"
+"       teq     %1, #0\n"
+"       bne     1b"
+        : "=&r" (result), "=&r" (tmp), "+Qo" (v->counter)
+        : "r" (&v->counter), "Ir" (i)
+        : "cc");
+
+        smp_mb();
+
+        return result;
+}
+
+static inline int atomic_cmpxchg(atomic_t *ptr, int old, int new)
+{
+        unsigned long oldval, res;
+
+        smp_mb();
+
+        do {
+                __asm__ __volatile__("@ atomic_cmpxchg\n"
+                "ldrex  %1, [%3]\n"
+                "mov    %0, #0\n"
+                "teq    %1, %4\n"
+                "strexeq %0, %5, [%3]\n"
+                    : "=&r" (res), "=&r" (oldval), "+Qo" (ptr->counter)
+                    : "r" (&ptr->counter), "Ir" (old), "r" (new)
+                    : "cc");
+        } while (res);
+
+        smp_mb();
+
+        return oldval;
+}
+
+static inline void atomic_clear_mask(unsigned long mask, unsigned long *addr)
+{
+        unsigned long tmp, tmp2;
+
+        __asm__ __volatile__("@ atomic_clear_mask\n"
+"1:     ldrex   %0, [%3]\n"
+"       bic     %0, %0, %4\n"
+"       strex   %1, %0, [%3]\n"
+"       teq     %1, #0\n"
+"       bne     1b"
+        : "=&r" (tmp), "=&r" (tmp2), "+Qo" (*addr)
+        : "r" (addr), "Ir" (mask)
+        : "cc");
+}
+
+#define atomic_inc(v)           atomic_add(1, v)
+#define atomic_dec(v)           atomic_sub(1, v)
+
+#define atomic_inc_and_test(v)  (atomic_add_return(1, v) == 0)
+#define atomic_dec_and_test(v)  (atomic_sub_return(1, v) == 0)
+#define atomic_inc_return(v)    (atomic_add_return(1, v))
+#define atomic_dec_return(v)    (atomic_sub_return(1, v))
+#define atomic_sub_and_test(i, v) (atomic_sub_return(i, v) == 0)
+
+#define atomic_add_negative(i,v) (atomic_add_return(i, v) < 0)
+
+static inline atomic_t atomic_compareandswap(
+    atomic_t old, atomic_t new, atomic_t *v)
+{
+    atomic_t rc;
+    rc.counter = __cmpxchg(&v->counter, old.counter, new.counter, sizeof(int));
+    return rc;
+}
+
+#endif /* __ARCH_ARM_ATOMIC__ */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/bitops.h b/xen/include/asm-arm/bitops.h
new file mode 100644
index 0000000..3d6b30b
--- /dev/null
+++ b/xen/include/asm-arm/bitops.h
@@ -0,0 +1,195 @@
+/*
+ * Copyright 1995, Russell King.
+ * Various bits and pieces copyrights include:
+ *  Linus Torvalds (test_bit).
+ * Big endian support: Copyright 2001, Nicolas Pitre
+ *  reworked by rmk.
+ */
+
+#ifndef _ARM_BITOPS_H
+#define _ARM_BITOPS_H
+
+extern void _set_bit(int nr, volatile void * p);
+extern void _clear_bit(int nr, volatile void * p);
+extern void _change_bit(int nr, volatile void * p);
+extern int _test_and_set_bit(int nr, volatile void * p);
+extern int _test_and_clear_bit(int nr, volatile void * p);
+extern int _test_and_change_bit(int nr, volatile void * p);
+
+#define set_bit(n,p)              _set_bit(n,p)
+#define clear_bit(n,p)            _clear_bit(n,p)
+#define change_bit(n,p)           _change_bit(n,p)
+#define test_and_set_bit(n,p)     _test_and_set_bit(n,p)
+#define test_and_clear_bit(n,p)   _test_and_clear_bit(n,p)
+#define test_and_change_bit(n,p)  _test_and_change_bit(n,p)
+
+#define BIT(nr)                 (1UL << (nr))
+#define BIT_MASK(nr)            (1UL << ((nr) % BITS_PER_LONG))
+#define BIT_WORD(nr)            ((nr) / BITS_PER_LONG)
+#define BITS_PER_BYTE           8
+
+#define ADDR (*(volatile long *) addr)
+#define CONST_ADDR (*(const volatile long *) addr)
+
+/**
+ * __test_and_set_bit - Set a bit and return its old value
+ * @nr: Bit to set
+ * @addr: Address to count from
+ *
+ * This operation is non-atomic and can be reordered.
+ * If two examples of this operation race, one can appear to succeed
+ * but actually fail.  You must protect multiple accesses with a lock.
+ */
+static inline int __test_and_set_bit(int nr, volatile void *addr)
+{
+        unsigned long mask = BIT_MASK(nr);
+        volatile unsigned long *p =
+                ((volatile unsigned long *)addr) + BIT_WORD(nr);
+        unsigned long old = *p;
+
+        *p = old | mask;
+        return (old & mask) != 0;
+}
+
+/**
+ * __test_and_clear_bit - Clear a bit and return its old value
+ * @nr: Bit to clear
+ * @addr: Address to count from
+ *
+ * This operation is non-atomic and can be reordered.
+ * If two examples of this operation race, one can appear to succeed
+ * but actually fail.  You must protect multiple accesses with a lock.
+ */
+static inline int __test_and_clear_bit(int nr, volatile void *addr)
+{
+        unsigned long mask = BIT_MASK(nr);
+        volatile unsigned long *p =
+                ((volatile unsigned long *)addr) + BIT_WORD(nr);
+        unsigned long old = *p;
+
+        *p = old & ~mask;
+        return (old & mask) != 0;
+}
+
+/* WARNING: non atomic and it can be reordered! */
+static inline int __test_and_change_bit(int nr,
+                                            volatile void *addr)
+{
+        unsigned long mask = BIT_MASK(nr);
+        volatile unsigned long *p =
+                ((volatile unsigned long *)addr) + BIT_WORD(nr);
+        unsigned long old = *p;
+
+        *p = old ^ mask;
+        return (old & mask) != 0;
+}
+
+/**
+ * test_bit - Determine whether a bit is set
+ * @nr: bit number to test
+ * @addr: Address to start counting from
+ */
+static inline int test_bit(int nr, const volatile void *addr)
+{
+        const volatile unsigned long *p = (const volatile unsigned long *)addr;
+        return 1UL & (p[BIT_WORD(nr)] >> (nr & (BITS_PER_LONG-1)));
+}
+
+
+extern unsigned int _find_first_bit(
+    const unsigned long *addr, unsigned int size);
+extern unsigned int _find_next_bit(
+    const unsigned long *addr, unsigned int size, unsigned int offset);
+extern unsigned int _find_first_zero_bit(
+    const unsigned long *addr, unsigned int size);
+extern unsigned int _find_next_zero_bit(
+    const unsigned long *addr, unsigned int size, unsigned int offset);
+
+/*
+ * These are the little endian, atomic definitions.
+ */
+#define find_first_zero_bit(p,sz)       _find_first_zero_bit(p,sz)
+#define find_next_zero_bit(p,sz,off)    _find_next_zero_bit(p,sz,off)
+#define find_first_bit(p,sz)            _find_first_bit(p,sz)
+#define find_next_bit(p,sz,off)         _find_next_bit(p,sz,off)
+
+static inline int constant_fls(int x)
+{
+        int r = 32;
+
+        if (!x)
+                return 0;
+        if (!(x & 0xffff0000u)) {
+                x <<= 16;
+                r -= 16;
+        }
+        if (!(x & 0xff000000u)) {
+                x <<= 8;
+                r -= 8;
+        }
+        if (!(x & 0xf0000000u)) {
+                x <<= 4;
+                r -= 4;
+        }
+        if (!(x & 0xc0000000u)) {
+                x <<= 2;
+                r -= 2;
+        }
+        if (!(x & 0x80000000u)) {
+                x <<= 1;
+                r -= 1;
+        }
+        return r;
+}
+
+/*
+ * On ARMv5 and above those functions can be implemented around
+ * the clz instruction for much better code efficiency.
+ */
+
+static inline int fls(int x)
+{
+        int ret;
+
+        if (__builtin_constant_p(x))
+               return constant_fls(x);
+
+        asm("clz\t%0, %1" : "=r" (ret) : "r" (x));
+        ret = 32 - ret;
+        return ret;
+}
+
+#define ffs(x) ({ unsigned long __t = (x); fls(__t & -__t); })
+
+/**
+ * find_first_set_bit - find the first set bit in @word
+ * @word: the word to search
+ *
+ * Returns the bit-number of the first set bit (first bit being 0).
+ * The input must *not* be zero.
+ */
+static inline unsigned int find_first_set_bit(unsigned long word)
+{
+        return ffs(word) - 1;
+}
+
+/**
+ * hweightN - returns the hamming weight of a N-bit word
+ * @x: the word to weigh
+ *
+ * The Hamming Weight of a number is the total number of bits set in it.
+ */
+#define hweight64(x) generic_hweight64(x)
+#define hweight32(x) generic_hweight32(x)
+#define hweight16(x) generic_hweight16(x)
+#define hweight8(x) generic_hweight8(x)
+
+#endif /* _ARM_BITOPS_H */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/bug.h b/xen/include/asm-arm/bug.h
new file mode 100644
index 0000000..bc2532c
--- /dev/null
+++ b/xen/include/asm-arm/bug.h
@@ -0,0 +1,15 @@
+#ifndef __ARM_BUG_H__
+#define __ARM_BUG_H__
+
+#define BUG() __bug(__FILE__, __LINE__)
+#define WARN() __warn(__FILE__, __LINE__)
+
+#endif /* __X86_BUG_H__ */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/byteorder.h b/xen/include/asm-arm/byteorder.h
new file mode 100644
index 0000000..f6ad883
--- /dev/null
+++ b/xen/include/asm-arm/byteorder.h
@@ -0,0 +1,16 @@
+#ifndef __ASM_ARM_BYTEORDER_H__
+#define __ASM_ARM_BYTEORDER_H__
+
+#define __BYTEORDER_HAS_U64__
+
+#include <xen/byteorder/little_endian.h>
+
+#endif /* __ASM_ARM_BYTEORDER_H__ */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/cache.h b/xen/include/asm-arm/cache.h
new file mode 100644
index 0000000..41b6291
--- /dev/null
+++ b/xen/include/asm-arm/cache.h
@@ -0,0 +1,20 @@
+#ifndef __ARCH_ARM_CACHE_H
+#define __ARCH_ARM_CACHE_H
+
+#include <xen/config.h>
+
+/* L1 cache line size */
+#define L1_CACHE_SHIFT  (CONFIG_ARM_L1_CACHE_SHIFT)
+#define L1_CACHE_BYTES  (1 << L1_CACHE_SHIFT)
+
+#define __read_mostly __attribute__((__section__(".data.read_mostly")))
+
+#endif
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/config.h b/xen/include/asm-arm/config.h
new file mode 100644
index 0000000..12285dd
--- /dev/null
+++ b/xen/include/asm-arm/config.h
@@ -0,0 +1,122 @@
+/******************************************************************************
+ * config.h
+ *
+ * A Linux-style configuration list.
+ */
+
+#ifndef __ARM_CONFIG_H__
+#define __ARM_CONFIG_H__
+
+#define CONFIG_PAGING_LEVELS 3
+
+#define CONFIG_ARM 1
+
+#define CONFIG_ARM_L1_CACHE_SHIFT 7 /* XXX */
+
+#define CONFIG_SMP 1
+
+#define CONFIG_DOMAIN_PAGE 1
+
+#define OPT_CONSOLE_STR "com1"
+
+#ifdef MAX_PHYS_CPUS
+#define NR_CPUS MAX_PHYS_CPUS
+#else
+#define NR_CPUS 128
+#endif
+
+#define MAX_VIRT_CPUS 128 /* XXX */
+#define MAX_HVM_VCPUS MAX_VIRT_CPUS
+
+#define asmlinkage /* Nothing needed */
+
+/* Linkage for ARM */
+#define __ALIGN .align 2
+#define __ALIGN_STR ".align 2"
+#ifdef __ASSEMBLY__
+#define ALIGN __ALIGN
+#define ALIGN_STR __ALIGN_STR
+#define ENTRY(name)                             \
+  .globl name;                                  \
+  ALIGN;                                        \
+  name:
+#define END(name) \
+  .size name, .-name
+#define ENDPROC(name) \
+  .type name, %function; \
+  END(name)
+#endif
+
+/*
+ * Memory layout:
+ *  0  -   2M   Unmapped
+ *  2M -   4M   Xen text, data, bss
+ *  4M -   6M   Fixmap: special-purpose 4K mapping slots
+ *
+ * 32M - 128M   Frametable: 24 bytes per page for 16GB of RAM
+ *
+ *  1G -   2G   Xenheap: always-mapped memory
+ *  2G -   4G   Domheap: on-demand-mapped
+ */
+
+#define XEN_VIRT_START         0x00200000
+#define FIXMAP_ADDR(n)        (0x00400000 + (n) * PAGE_SIZE)
+#define FRAMETABLE_VIRT_START  0x02000000
+#define XENHEAP_VIRT_START     0x40000000
+#define DOMHEAP_VIRT_START     0x80000000
+
+#define HYPERVISOR_VIRT_START mk_unsigned_long(XEN_VIRT_START)
+
+#define DOMHEAP_ENTRIES        1024  /* 1024 2MB mapping slots */
+
+/* Fixmap slots */
+#define FIXMAP_CONSOLE  0  /* The primary UART */
+#define FIXMAP_PT       1  /* Temporary mappings of pagetable pages */
+#define FIXMAP_MISC     2  /* Ephemeral mappings of hardware */
+#define FIXMAP_GICD     3  /* Interrupt controller: distributor registers */
+#define FIXMAP_GICC1    4  /* Interrupt controller: CPU registers (first page) */
+#define FIXMAP_GICC2    5  /* Interrupt controller: CPU registers (second page) */
+#define FIXMAP_GICH     6  /* Interrupt controller: virtual interface control registers */
+
+#define PAGE_SHIFT              12
+
+#ifndef __ASSEMBLY__
+#define PAGE_SIZE           (1L << PAGE_SHIFT)
+#else
+#define PAGE_SIZE           (1 << PAGE_SHIFT)
+#endif
+#define PAGE_MASK           (~(PAGE_SIZE-1))
+#define PAGE_FLAG_MASK      (~0)
+
+#define STACK_ORDER 3
+#define STACK_SIZE  (PAGE_SIZE << STACK_ORDER)
+
+#ifndef __ASSEMBLY__
+extern unsigned long xen_phys_start;
+extern unsigned long xenheap_phys_end;
+extern unsigned long frametable_virt_end;
+#endif
+
+#define supervisor_mode_kernel (0)
+
+#define watchdog_disable() ((void)0)
+#define watchdog_enable()  ((void)0)
+
+/* Board-specific: base address of PL011 UART */
+#define EARLY_UART_ADDRESS 0x1c090000
+/* Board-specific: base address of GIC + its regs */
+#define GIC_BASE_ADDRESS 0x2c000000
+#define GIC_DR_OFFSET 0x1000
+#define GIC_CR_OFFSET 0x2000
+#define GIC_HR_OFFSET 0x4000 /* Guess work http://lists.infradead.org/pipermail/linux-arm-kernel/2011-September/064219.html */
+#define GIC_VR_OFFSET 0x6000 /* Virtual Machine CPU interface) */
+
+#endif /* __ARM_CONFIG_H__ */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/cpregs.h b/xen/include/asm-arm/cpregs.h
new file mode 100644
index 0000000..3a4028d
--- /dev/null
+++ b/xen/include/asm-arm/cpregs.h
@@ -0,0 +1,207 @@
+#ifndef __ASM_ARM_CPREGS_H
+#define __ASM_ARM_CPREGS_H
+
+#include <xen/stringify.h>
+
+/* Co-processor registers */
+
+/* Layout as used in assembly, with src/dest registers mixed in */
+#define __CP32(r, coproc, opc1, crn, crm, opc2) coproc, opc1, r, crn, crm, opc2
+#define __CP64(r1, r2, coproc, opc, crm) coproc, opc, r1, r2, crm
+#define CP32(r, name...) __CP32(r, name)
+#define CP64(r, name...) __CP64(r, name)
+
+/* Stringified for inline assembly */
+#define LOAD_CP32(r, name...)  "mrc " __stringify(CP32(%r, name)) ";"
+#define STORE_CP32(r, name...) "mcr " __stringify(CP32(%r, name)) ";"
+#define LOAD_CP64(r, name...)  "mrrc " __stringify(CP64(%r, %H##r, name)) ";"
+#define STORE_CP64(r, name...) "mcrr " __stringify(CP64(%r, %H##r, name)) ";"
+
+/* C wrappers */
+#define READ_CP32(name...) ({                                   \
+    register uint32_t _r;                                       \
+    asm volatile(LOAD_CP32(0, name) : "=r" (_r));               \
+    _r; })
+
+#define WRITE_CP32(v, name...) do {                             \
+    register uint32_t _r = (v);                                 \
+    asm volatile(STORE_CP32(0, name) : : "r" (_r));             \
+} while (0)
+
+#define READ_CP64(name...) ({                                   \
+    register uint64_t _r;                                       \
+    asm volatile(LOAD_CP64(0, name) : "=r" (_r));               \
+    _r; })
+
+#define WRITE_CP64(v, name...) do {                             \
+    register uint64_t _r = (v);                                 \
+    asm volatile(STORE_CP64(0, name) : : "r" (_r));             \
+} while (0)
+
+#define __HSR_CPREG_c0  0
+#define __HSR_CPREG_c1  1
+#define __HSR_CPREG_c2  2
+#define __HSR_CPREG_c3  3
+#define __HSR_CPREG_c4  4
+#define __HSR_CPREG_c5  5
+#define __HSR_CPREG_c6  6
+#define __HSR_CPREG_c7  7
+#define __HSR_CPREG_c8  8
+#define __HSR_CPREG_c9  9
+#define __HSR_CPREG_c10 10
+#define __HSR_CPREG_c11 11
+#define __HSR_CPREG_c12 12
+#define __HSR_CPREG_c13 13
+#define __HSR_CPREG_c14 14
+#define __HSR_CPREG_c15 15
+
+#define __HSR_CPREG_0   0
+#define __HSR_CPREG_1   1
+#define __HSR_CPREG_2   2
+#define __HSR_CPREG_3   3
+#define __HSR_CPREG_4   4
+#define __HSR_CPREG_5   5
+#define __HSR_CPREG_6   6
+#define __HSR_CPREG_7   7
+
+#define _HSR_CPREG32(cp,op1,crn,crm,op2) \
+    ((__HSR_CPREG_##crn) << HSR_CP32_CRN_SHIFT) | \
+    ((__HSR_CPREG_##crm) << HSR_CP32_CRM_SHIFT) | \
+    ((__HSR_CPREG_##op1) << HSR_CP32_OP1_SHIFT) | \
+    ((__HSR_CPREG_##op2) << HSR_CP32_OP2_SHIFT)
+
+#define _HSR_CPREG64(cp,op1,crm) \
+    ((__HSR_CPREG_##crm) << HSR_CP64_CRM_SHIFT) | \
+    ((__HSR_CPREG_##op1) << HSR_CP64_OP1_SHIFT)
+
+/* Encode a register as per HSR ISS pattern */
+#define HSR_CPREG32(X) _HSR_CPREG32(X)
+#define HSR_CPREG64(X) _HSR_CPREG64(X)
+
+/*
+ * Order registers by Coprocessor-> CRn-> Opcode 1-> CRm-> Opcode 2
+ *
+ * This matches the ordering used in the ARM as well as the groupings
+ * which the CP registers are allocated in.
+ *
+ * This is slightly different to the form of the instruction
+ * arguments, which are cp,opc1,crn,crm,opc2.
+ */
+
+/* Coprocessor 15 */
+
+/* CP15 CR0: CPUID and Cache Type Registers */
+#define ID_PFR0         p15,0,c0,c1,0   /* Processor Feature Register 0 */
+#define ID_PFR1         p15,0,c0,c1,1   /* Processor Feature Register 1 */
+#define CCSIDR          p15,1,c0,c0,0   /* Cache Size ID Registers */
+#define CLIDR           p15,1,c0,c0,1   /* Cache Level ID Register */
+#define CSSELR          p15,2,c0,c0,0   /* Cache Size Selection Register */
+
+/* CP15 CR1: System Control Registers */
+#define SCTLR           p15,0,c1,c0,0   /* System Control Register */
+#define SCR             p15,0,c1,c1,0   /* Secure Configuration Register */
+#define NSACR           p15,0,c1,c1,2   /* Non-Secure Access Control Register */
+#define HSCTLR          p15,4,c1,c0,0   /* Hyp. System Control Register */
+#define HCR             p15,4,c1,c1,0   /* Hyp. Configuration Register */
+
+/* CP15 CR2: Translation Table Base and Control Registers */
+#define TTBR0           p15,0,c2,c0,0   /* Translation Table Base Reg. 0 */
+#define TTBR1           p15,0,c2,c0,1   /* Translation Table Base Reg. 1 */
+#define TTBCR           p15,0,c2,c0,2   /* Translatation Table Base Control Register */
+#define HTTBR           p15,4,c2        /* Hyp. Translation Table Base Register */
+#define HTCR            p15,4,c2,c0,2   /* Hyp. Translation Control Register */
+#define VTCR            p15,4,c2,c1,2   /* Virtualization Translation Control Register */
+#define VTTBR           p15,6,c2        /* Virtualization Translation Table Base Register */
+
+/* CP15 CR3: Domain Access Control Register */
+
+/* CP15 CR4: */
+
+/* CP15 CR5: Fault Status Registers */
+#define DFSR            p15,0,c5,c0,0   /* Data Fault Status Register */
+#define IFSR            p15,0,c5,c0,1   /* Instruction Fault Status Register */
+#define HSR             p15,4,c5,c2,0   /* Hyp. Syndrome Register */
+
+/* CP15 CR6: Fault Address Registers */
+#define DFAR            p15,0,c6,c0,0   /* Data Fault Address Register  */
+#define IFAR            p15,0,c6,c0,2   /* Instruction Fault Address Register */
+#define HDFAR           p15,4,c6,c0,0   /* Hyp. Data Fault Address Register */
+#define HIFAR           p15,4,c6,c0,2   /* Hyp. Instruction Fault Address Register */
+#define HPFAR           p15,4,c6,c0,4   /* Hyp. IPA Fault Address Register */
+
+/* CP15 CR7: Cache and address translation operations */
+#define PAR             p15,0,c7        /* Physical Address Register */
+#define ICIALLUIS       p15,0,c7,c1,0   /* Invalidate all instruction caches to PoU inner shareable */
+#define BPIALLIS        p15,0,c7,c1,6   /* Invalidate entire branch predictor array inner shareable */
+#define ICIALLU         p15,0,c7,c5,0   /* Invalidate all instruction caches to PoU */
+#define BPIALL          p15,0,c7,c5,6   /* Invalidate entire branch predictor array */
+#define ATS1CPR         p15,0,c7,c8,0   /* Address Translation Stage 1. Non-Secure Kernel Read */
+#define ATS1CPW         p15,0,c7,c8,1   /* Address Translation Stage 1. Non-Secure Kernel Write */
+#define ATS1CUR         p15,0,c7,c8,2   /* Address Translation Stage 1. Non-Secure User Read */
+#define ATS1CUW         p15,0,c7,c8,3   /* Address Translation Stage 1. Non-Secure User Write */
+#define ATS12NSOPR      p15,0,c7,c8,4   /* Address Translation Stage 1+2 Non-Secure Kernel Read */
+#define ATS12NSOPW      p15,0,c7,c8,5   /* Address Translation Stage 1+2 Non-Secure Kernel Write */
+#define ATS12NSOUR      p15,0,c7,c8,6   /* Address Translation Stage 1+2 Non-Secure User Read */
+#define ATS12NSOUW      p15,0,c7,c8,7   /* Address Translation Stage 1+2 Non-Secure User Write */
+#define DCCMVAC         p15,0,c7,c10,1  /* Clean data or unified cache line by MVA to PoC */
+#define DCCISW          p15,0,c7,c14,2  /* Clean and invalidate data cache line by set/way */
+#define ATS1HR          p15,4,c7,c8,0   /* Address Translation Stage 1 Hyp. Read */
+#define ATS1HW          p15,4,c7,c8,1   /* Address Translation Stage 1 Hyp. Write */
+
+/* CP15 CR8: TLB maintenance operations */
+#define TLBIALLIS       p15,0,c8,c3,0   /* Invalidate entire TLB innrer shareable */
+#define TLBIMVAIS       p15,0,c8,c3,1   /* Invalidate unified TLB entry by MVA inner shareable */
+#define TLBIASIDIS      p15,0,c8,c3,2   /* Invalidate unified TLB by ASID match inner shareable */
+#define TLBIMVAAIS      p15,0,c8,c3,3   /* Invalidate unified TLB entry by MVA all ASID inner shareable */
+#define DTLBIALL        p15,0,c8,c6,0   /* Invalidate data TLB */
+#define DTLBIMVA        p15,0,c8,c6,1   /* Invalidate data TLB entry by MVA */
+#define DTLBIASID       p15,0,c8,c6,2   /* Invalidate data TLB by ASID match */
+#define TLBILLHIS       p15,4,c8,c3,0   /* Invalidate Entire Hyp. Unified TLB inner shareable */
+#define TLBIMVAHIS      p15,4,c8,c3,1   /* Invalidate Unified Hyp. TLB by MVA inner shareable */
+#define TLBIALLNSNHIS   p15,4,c8,c7,4   /* Invalidate Entire Non-Secure Non-Hyp. Unified TLB inner shareable */
+#define TLBIALLH        p15,4,c8,c7,0   /* Invalidate Entire Hyp. Unified TLB */
+#define TLBIMVAH        p15,4,c8,c7,1   /* Invalidate Unified Hyp. TLB by MVA */
+#define TLBIALLNSNH     p15,4,c8,c7,4   /* Invalidate Entire Non-Secure Non-Hyp. Unified TLB */
+
+/* CP15 CR9: */
+
+/* CP15 CR10: */
+#define MAIR0           p15,0,c10,c2,0  /* Memory Attribute Indirection Register 0 */
+#define MAIR1           p15,0,c10,c2,1  /* Memory Attribute Indirection Register 1 */
+#define HMAIR0          p15,4,c10,c2,0  /* Hyp. Memory Attribute Indirection Register 0 */
+#define HMAIR1          p15,4,c10,c2,1  /* Hyp. Memory Attribute Indirection Register 1 */
+
+/* CP15 CR11: DMA Operations for TCM Access */
+
+/* CP15 CR12:  */
+#define HVBAR           p15,4,c12,c0,0  /* Hyp. Vector Base Address Register */
+
+/* CP15 CR13:  */
+#define FCSEIDR         p15,0,c13,c0,0  /* FCSE Process ID Register */
+#define CONTEXTIDR      p15,0,c13,c0,1  /* Context ID Register */
+
+/* CP15 CR14:  */
+#define CNTPCT          p15,0,c14       /* Time counter value */
+#define CNTFRQ          p15,0,c14,c0,0  /* Time counter frequency */
+#define CNTKCTL         p15,0,c14,c1,0  /* Time counter kernel control */
+#define CNTP_TVAL       p15,0,c14,c2,0  /* Physical Timer value */
+#define CNTP_CTL        p15,0,c14,c2,1  /* Physical Timer control register */
+#define CNTVCT          p15,1,c14       /* Time counter value + offset */
+#define CNTP_CVAL       p15,2,c14       /* Physical Timer comparator */
+#define CNTVOFF         p15,4,c14       /* Time counter offset */
+#define CNTHCTL         p15,4,c14,c1,0  /* Time counter hyp. control */
+#define CNTHP_TVAL      p15,4,c14,c2,0  /* Hyp. Timer value */
+#define CNTHP_CTL       p15,4,c14,c2,1  /* Hyp. Timer control register */
+#define CNTHP_CVAL      p15,6,c14       /* Hyp. Timer comparator */
+
+/* CP15 CR15: Implementation Defined Registers */
+
+#endif
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/current.h b/xen/include/asm-arm/current.h
new file mode 100644
index 0000000..826efa5
--- /dev/null
+++ b/xen/include/asm-arm/current.h
@@ -0,0 +1,60 @@
+#ifndef __ARM_CURRENT_H__
+#define __ARM_CURRENT_H__
+
+#include <xen/config.h>
+#include <xen/percpu.h>
+#include <public/xen.h>
+
+#ifndef __ASSEMBLY__
+
+struct vcpu;
+
+struct cpu_info {
+    struct cpu_user_regs guest_cpu_user_regs;
+    unsigned long elr;
+    unsigned int processor_id;
+    struct vcpu *current_vcpu;
+    unsigned long per_cpu_offset;
+};
+
+static inline struct cpu_info *get_cpu_info(void)
+{
+        register unsigned long sp asm ("sp");
+        return (struct cpu_info *)((sp & ~(STACK_SIZE - 1)) + STACK_SIZE - sizeof(struct cpu_info));
+}
+
+#define get_current()         (get_cpu_info()->current_vcpu)
+#define set_current(vcpu)     (get_cpu_info()->current_vcpu = (vcpu))
+#define current               (get_current())
+
+#define get_processor_id()    (get_cpu_info()->processor_id)
+#define set_processor_id(id)  do {                                      \
+    struct cpu_info *ci__ = get_cpu_info();                             \
+    ci__->per_cpu_offset = __per_cpu_offset[ci__->processor_id = (id)]; \
+} while (0)
+
+#define guest_cpu_user_regs() (&get_cpu_info()->guest_cpu_user_regs)
+
+#define reset_stack_and_jump(__fn)              \
+    __asm__ __volatile__ (                      \
+        "mov sp,%0; b "STR(__fn)      \
+        : : "r" (guest_cpu_user_regs()) : "memory" )
+#endif
+
+
+/*
+ * Which VCPU's state is currently running on each CPU?
+ * This is not necesasrily the same as 'current' as a CPU may be
+ * executing a lazy state switch.
+ */
+DECLARE_PER_CPU(struct vcpu *, curr_vcpu);
+
+#endif /* __ARM_CURRENT_H__ */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/debugger.h b/xen/include/asm-arm/debugger.h
new file mode 100644
index 0000000..84b2eec
--- /dev/null
+++ b/xen/include/asm-arm/debugger.h
@@ -0,0 +1,15 @@
+#ifndef __ARM_DEBUGGER_H__
+#define __ARM_DEBUGGER_H__
+
+#define debugger_trap_fatal(v, r) (0)
+#define debugger_trap_immediate() (0)
+
+#endif /* __ARM_DEBUGGER_H__ */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/delay.h b/xen/include/asm-arm/delay.h
new file mode 100644
index 0000000..6250774
--- /dev/null
+++ b/xen/include/asm-arm/delay.h
@@ -0,0 +1,15 @@
+#ifndef _ARM_DELAY_H
+#define _ARM_DELAY_H
+
+extern void __udelay(unsigned long usecs);
+#define udelay(n) __udelay(n)
+
+#endif /* defined(_ARM_DELAY_H) */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/desc.h b/xen/include/asm-arm/desc.h
new file mode 100644
index 0000000..3989e8a
--- /dev/null
+++ b/xen/include/asm-arm/desc.h
@@ -0,0 +1,12 @@
+#ifndef __ARCH_DESC_H
+#define __ARCH_DESC_H
+
+#endif /* __ARCH_DESC_H */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/div64.h b/xen/include/asm-arm/div64.h
new file mode 100644
index 0000000..7b00808
--- /dev/null
+++ b/xen/include/asm-arm/div64.h
@@ -0,0 +1,235 @@
+/* Taken from Linux arch/arm */
+#ifndef __ASM_ARM_DIV64
+#define __ASM_ARM_DIV64
+
+#include <asm/system.h>
+#include <xen/types.h>
+
+/*
+ * The semantics of do_div() are:
+ *
+ * uint32_t do_div(uint64_t *n, uint32_t base)
+ * {
+ * 	uint32_t remainder = *n % base;
+ * 	*n = *n / base;
+ * 	return remainder;
+ * }
+ *
+ * In other words, a 64-bit dividend with a 32-bit divisor producing
+ * a 64-bit result and a 32-bit remainder.  To accomplish this optimally
+ * we call a special __do_div64 helper with completely non standard
+ * calling convention for arguments and results (beware).
+ */
+
+#ifdef __ARMEB__
+#define __xh "r0"
+#define __xl "r1"
+#else
+#define __xl "r0"
+#define __xh "r1"
+#endif
+
+#define __do_div_asm(n, base)					\
+({								\
+	register unsigned int __base      asm("r4") = base;	\
+	register unsigned long long __n   asm("r0") = n;	\
+	register unsigned long long __res asm("r2");		\
+	register unsigned int __rem       asm(__xh);		\
+	asm(	__asmeq("%0", __xh)				\
+		__asmeq("%1", "r2")				\
+		__asmeq("%2", "r0")				\
+		__asmeq("%3", "r4")				\
+		"bl	__do_div64"				\
+		: "=r" (__rem), "=r" (__res)			\
+		: "r" (__n), "r" (__base)			\
+		: "ip", "lr", "cc");				\
+	n = __res;						\
+	__rem;							\
+})
+
+#if __GNUC__ < 4
+
+/*
+ * gcc versions earlier than 4.0 are simply too problematic for the
+ * optimized implementation below. First there is gcc PR 15089 that
+ * tend to trig on more complex constructs, spurious .global __udivsi3
+ * are inserted even if none of those symbols are referenced in the
+ * generated code, and those gcc versions are not able to do constant
+ * propagation on long long values anyway.
+ */
+#define do_div(n, base) __do_div_asm(n, base)
+
+#elif __GNUC__ >= 4
+
+#include <asm/bug.h>
+
+/*
+ * If the divisor happens to be constant, we determine the appropriate
+ * inverse at compile time to turn the division into a few inline
+ * multiplications instead which is much faster. And yet only if compiling
+ * for ARMv4 or higher (we need umull/umlal) and if the gcc version is
+ * sufficiently recent to perform proper long long constant propagation.
+ * (It is unfortunate that gcc doesn't perform all this internally.)
+ */
+#define do_div(n, base)							\
+({									\
+	unsigned int __r, __b = (base);					\
+	if (!__builtin_constant_p(__b) || __b == 0) {			\
+		/* non-constant divisor (or zero): slow path */		\
+		__r = __do_div_asm(n, __b);				\
+	} else if ((__b & (__b - 1)) == 0) {				\
+		/* Trivial: __b is constant and a power of 2 */		\
+		/* gcc does the right thing with this code.  */		\
+		__r = n;						\
+		__r &= (__b - 1);					\
+		n /= __b;						\
+	} else {							\
+		/* Multiply by inverse of __b: n/b = n*(p/b)/p       */	\
+		/* We rely on the fact that most of this code gets   */	\
+		/* optimized away at compile time due to constant    */	\
+		/* propagation and only a couple inline assembly     */	\
+		/* instructions should remain. Better avoid any      */	\
+		/* code construct that might prevent that.           */	\
+		unsigned long long __res, __x, __t, __m, __n = n;	\
+		unsigned int __c, __p, __z = 0;				\
+		/* preserve low part of n for reminder computation */	\
+		__r = __n;						\
+		/* determine number of bits to represent __b */		\
+		__p = 1 << __div64_fls(__b);				\
+		/* compute __m = ((__p << 64) + __b - 1) / __b */	\
+		__m = (~0ULL / __b) * __p;				\
+		__m += (((~0ULL % __b + 1) * __p) + __b - 1) / __b;	\
+		/* compute __res = __m*(~0ULL/__b*__b-1)/(__p << 64) */	\
+		__x = ~0ULL / __b * __b - 1;				\
+		__res = (__m & 0xffffffff) * (__x & 0xffffffff);	\
+		__res >>= 32;						\
+		__res += (__m & 0xffffffff) * (__x >> 32);		\
+		__t = __res;						\
+		__res += (__x & 0xffffffff) * (__m >> 32);		\
+		__t = (__res < __t) ? (1ULL << 32) : 0;			\
+		__res = (__res >> 32) + __t;				\
+		__res += (__m >> 32) * (__x >> 32);			\
+		__res /= __p;						\
+		/* Now sanitize and optimize what we've got. */		\
+		if (~0ULL % (__b / (__b & -__b)) == 0) {		\
+			/* those cases can be simplified with: */	\
+			__n /= (__b & -__b);				\
+			__m = ~0ULL / (__b / (__b & -__b));		\
+			__p = 1;					\
+			__c = 1;					\
+		} else if (__res != __x / __b) {			\
+			/* We can't get away without a correction    */	\
+			/* to compensate for bit truncation errors.  */	\
+			/* To avoid it we'd need an additional bit   */	\
+			/* to represent __m which would overflow it. */	\
+			/* Instead we do m=p/b and n/b=(n*m+m)/p.    */	\
+			__c = 1;					\
+			/* Compute __m = (__p << 64) / __b */		\
+			__m = (~0ULL / __b) * __p;			\
+			__m += ((~0ULL % __b + 1) * __p) / __b;		\
+		} else {						\
+			/* Reduce __m/__p, and try to clear bit 31   */	\
+			/* of __m when possible otherwise that'll    */	\
+			/* need extra overflow handling later.       */	\
+			unsigned int __bits = -(__m & -__m);		\
+			__bits |= __m >> 32;				\
+			__bits = (~__bits) << 1;			\
+			/* If __bits == 0 then setting bit 31 is     */	\
+			/* unavoidable.  Simply apply the maximum    */	\
+			/* possible reduction in that case.          */	\
+			/* Otherwise the MSB of __bits indicates the */	\
+			/* best reduction we should apply.           */	\
+			if (!__bits) {					\
+				__p /= (__m & -__m);			\
+				__m /= (__m & -__m);			\
+			} else {					\
+				__p >>= __div64_fls(__bits);		\
+				__m >>= __div64_fls(__bits);		\
+			}						\
+			/* No correction needed. */			\
+			__c = 0;					\
+		}							\
+		/* Now we have a combination of 2 conditions:        */	\
+		/* 1) whether or not we need a correction (__c), and */	\
+		/* 2) whether or not there might be an overflow in   */	\
+		/*    the cross product (__m & ((1<<63) | (1<<31)))  */	\
+		/* Select the best insn combination to perform the   */	\
+		/* actual __m * __n / (__p << 64) operation.         */	\
+		if (!__c) {						\
+			asm (	"umull	%Q0, %R0, %1, %Q2\n\t"		\
+				"mov	%Q0, #0"			\
+				: "=&r" (__res)				\
+				: "r" (__m), "r" (__n)			\
+				: "cc" );				\
+		} else if (!(__m & ((1ULL << 63) | (1ULL << 31)))) {	\
+			__res = __m;					\
+			asm (	"umlal	%Q0, %R0, %Q1, %Q2\n\t"		\
+				"mov	%Q0, #0"			\
+				: "+&r" (__res)				\
+				: "r" (__m), "r" (__n)			\
+				: "cc" );				\
+		} else {						\
+			asm (	"umull	%Q0, %R0, %Q1, %Q2\n\t"		\
+				"cmn	%Q0, %Q1\n\t"			\
+				"adcs	%R0, %R0, %R1\n\t"		\
+				"adc	%Q0, %3, #0"			\
+				: "=&r" (__res)				\
+				: "r" (__m), "r" (__n), "r" (__z)	\
+				: "cc" );				\
+		}							\
+		if (!(__m & ((1ULL << 63) | (1ULL << 31)))) {		\
+			asm (	"umlal	%R0, %Q0, %R1, %Q2\n\t"		\
+				"umlal	%R0, %Q0, %Q1, %R2\n\t"		\
+				"mov	%R0, #0\n\t"			\
+				"umlal	%Q0, %R0, %R1, %R2"		\
+				: "+&r" (__res)				\
+				: "r" (__m), "r" (__n)			\
+				: "cc" );				\
+		} else {						\
+			asm (	"umlal	%R0, %Q0, %R2, %Q3\n\t"		\
+				"umlal	%R0, %1, %Q2, %R3\n\t"		\
+				"mov	%R0, #0\n\t"			\
+				"adds	%Q0, %1, %Q0\n\t"		\
+				"adc	%R0, %R0, #0\n\t"		\
+				"umlal	%Q0, %R0, %R2, %R3"		\
+				: "+&r" (__res), "+&r" (__z)		\
+				: "r" (__m), "r" (__n)			\
+				: "cc" );				\
+		}							\
+		__res /= __p;						\
+		/* The reminder can be computed with 32-bit regs     */	\
+		/* only, and gcc is good at that.                    */	\
+		{							\
+			unsigned int __res0 = __res;			\
+			unsigned int __b0 = __b;			\
+			__r -= __res0 * __b0;				\
+		}							\
+		/* BUG_ON(__r >= __b || __res * __b + __r != n); */	\
+		n = __res;						\
+	}								\
+	__r;								\
+})
+
+/* our own fls implementation to make sure constant propagation is fine */
+#define __div64_fls(bits)						\
+({									\
+	unsigned int __left = (bits), __nr = 0;				\
+	if (__left & 0xffff0000) __nr += 16, __left >>= 16;		\
+	if (__left & 0x0000ff00) __nr +=  8, __left >>=  8;		\
+	if (__left & 0x000000f0) __nr +=  4, __left >>=  4;		\
+	if (__left & 0x0000000c) __nr +=  2, __left >>=  2;		\
+	if (__left & 0x00000002) __nr +=  1;				\
+	__nr;								\
+})
+
+#endif
+
+#endif
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/elf.h b/xen/include/asm-arm/elf.h
new file mode 100644
index 0000000..12d487c
--- /dev/null
+++ b/xen/include/asm-arm/elf.h
@@ -0,0 +1,33 @@
+#ifndef __ARM_ELF_H__
+#define __ARM_ELF_H__
+
+typedef struct {
+    unsigned long r0;
+    unsigned long r1;
+    unsigned long r2;
+    unsigned long r3;
+    unsigned long r4;
+    unsigned long r5;
+    unsigned long r6;
+    unsigned long r7;
+    unsigned long r8;
+    unsigned long r9;
+    unsigned long r10;
+    unsigned long r11;
+    unsigned long r12;
+    unsigned long sp;
+    unsigned long lr;
+    unsigned long pc;
+} ELF_Gregset;
+
+#endif /* __ARM_ELF_H__ */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/event.h b/xen/include/asm-arm/event.h
new file mode 100644
index 0000000..6b2fb7c
--- /dev/null
+++ b/xen/include/asm-arm/event.h
@@ -0,0 +1,41 @@
+#ifndef __ASM_EVENT_H__
+#define __ASM_EVENT_H__
+
+void vcpu_kick(struct vcpu *v);
+void vcpu_mark_events_pending(struct vcpu *v);
+
+static inline int local_events_need_delivery(void)
+{
+    /* TODO
+     * return (vcpu_info(v, evtchn_upcall_pending) &&
+                        !vcpu_info(v, evtchn_upcall_mask)); */
+        return 0;
+}
+
+int local_event_delivery_is_enabled(void);
+
+static inline void local_event_delivery_disable(void)
+{
+    /* TODO current->vcpu_info->evtchn_upcall_mask = 1; */
+}
+
+static inline void local_event_delivery_enable(void)
+{
+    /* TODO current->vcpu_info->evtchn_upcall_mask = 0; */
+}
+
+/* No arch specific virq definition now. Default to global. */
+static inline int arch_virq_is_global(int virq)
+{
+    return 1;
+}
+
+#endif
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/flushtlb.h b/xen/include/asm-arm/flushtlb.h
new file mode 100644
index 0000000..c8486fc
--- /dev/null
+++ b/xen/include/asm-arm/flushtlb.h
@@ -0,0 +1,31 @@
+#ifndef __FLUSHTLB_H__
+#define __FLUSHTLB_H__
+
+#include <xen/cpumask.h>
+
+/*
+ * Filter the given set of CPUs, removing those that definitely flushed their
+ * TLB since @page_timestamp.
+ */
+/* XXX lazy implementation just doesn't clear anything.... */
+#define tlbflush_filter(mask, page_timestamp)                           \
+do {                                                                    \
+} while ( 0 )
+
+#define tlbflush_current_time()                 (0)
+
+/* Flush local TLBs */
+void flush_tlb_local(void);
+
+/* Flush specified CPUs' TLBs */
+void flush_tlb_mask(const cpumask_t *mask);
+
+#endif /* __FLUSHTLB_H__ */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/grant_table.h b/xen/include/asm-arm/grant_table.h
new file mode 100644
index 0000000..8f6ffd8
--- /dev/null
+++ b/xen/include/asm-arm/grant_table.h
@@ -0,0 +1,35 @@
+#ifndef __ASM_GRANT_TABLE_H__
+#define __ASM_GRANT_TABLE_H__
+
+#include <xen/grant_table.h>
+
+#define INVALID_GFN (-1UL)
+#define INITIAL_NR_GRANT_FRAMES 1
+
+void gnttab_clear_flag(unsigned long nr, uint16_t *addr);
+int create_grant_host_mapping(unsigned long gpaddr,
+		unsigned long mfn, unsigned int flags, unsigned int
+		cache_flags);
+#define gnttab_host_mapping_get_page_type(op, d, rd) (0)
+int replace_grant_host_mapping(unsigned long gpaddr, unsigned long mfn,
+		unsigned long new_gpaddr, unsigned int flags);
+void gnttab_mark_dirty(struct domain *d, unsigned long l);
+#define gnttab_create_status_page(d, t, i) (0)
+#define gnttab_create_shared_page(d, t, i) (0)
+#define gnttab_shared_gmfn(d, t, i) (0)
+#define gnttab_status_gmfn(d, t, i) (0)
+#define gnttab_release_host_mappings(domain) 1
+static inline int replace_grant_supported(void)
+{
+    return 1;
+}
+
+#endif /* __ASM_GRANT_TABLE_H__ */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/hardirq.h b/xen/include/asm-arm/hardirq.h
new file mode 100644
index 0000000..9c031a8
--- /dev/null
+++ b/xen/include/asm-arm/hardirq.h
@@ -0,0 +1,28 @@
+#ifndef __ASM_HARDIRQ_H
+#define __ASM_HARDIRQ_H
+
+#include <xen/config.h>
+#include <xen/cache.h>
+#include <xen/smp.h>
+
+typedef struct {
+        unsigned long __softirq_pending;
+        unsigned int __local_irq_count;
+} __cacheline_aligned irq_cpustat_t;
+
+#include <xen/irq_cpustat.h>    /* Standard mappings for irq_cpustat_t above */
+
+#define in_irq() (local_irq_count(smp_processor_id()) != 0)
+
+#define irq_enter()     (local_irq_count(smp_processor_id())++)
+#define irq_exit()      (local_irq_count(smp_processor_id())--)
+
+#endif /* __ASM_HARDIRQ_H */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/hypercall.h b/xen/include/asm-arm/hypercall.h
new file mode 100644
index 0000000..90a87ef
--- /dev/null
+++ b/xen/include/asm-arm/hypercall.h
@@ -0,0 +1,24 @@
+#ifndef __ASM_ARM_HYPERCALL_H__
+#define __ASM_ARM_HYPERCALL_H__
+
+#include <public/domctl.h> /* for arch_do_domctl */
+
+struct vcpu;
+extern long
+arch_do_vcpu_op(
+    int cmd, struct vcpu *v, XEN_GUEST_HANDLE(void) arg);
+
+extern long
+arch_do_sysctl(
+    struct xen_sysctl *op,
+    XEN_GUEST_HANDLE(xen_sysctl_t) u_sysctl);
+
+#endif /* __ASM_ARM_HYPERCALL_H__ */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/init.h b/xen/include/asm-arm/init.h
new file mode 100644
index 0000000..5f44929
--- /dev/null
+++ b/xen/include/asm-arm/init.h
@@ -0,0 +1,12 @@
+#ifndef _XEN_ASM_INIT_H
+#define _XEN_ASM_INIT_H
+
+#endif /* _XEN_ASM_INIT_H */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/io.h b/xen/include/asm-arm/io.h
new file mode 100644
index 0000000..1babbab
--- /dev/null
+++ b/xen/include/asm-arm/io.h
@@ -0,0 +1,12 @@
+#ifndef _ASM_IO_H
+#define _ASM_IO_H
+
+#endif
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/iocap.h b/xen/include/asm-arm/iocap.h
new file mode 100644
index 0000000..f647f30
--- /dev/null
+++ b/xen/include/asm-arm/iocap.h
@@ -0,0 +1,20 @@
+#ifndef __X86_IOCAP_H__
+#define __X86_IOCAP_H__
+
+#define cache_flush_permitted(d)                        \
+    (!rangeset_is_empty((d)->iomem_caps))
+
+#define multipage_allocation_permitted(d, order)        \
+    (((order) <= 9) || /* allow 2MB superpages */       \
+     !rangeset_is_empty((d)->iomem_caps))
+
+#endif
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/multicall.h b/xen/include/asm-arm/multicall.h
new file mode 100644
index 0000000..c800940
--- /dev/null
+++ b/xen/include/asm-arm/multicall.h
@@ -0,0 +1,23 @@
+#ifndef __ASM_ARM_MULTICALL_H__
+#define __ASM_ARM_MULTICALL_H__
+
+#define do_multicall_call(_call)                             \
+    do {                                                     \
+        __asm__ __volatile__ (                               \
+            ".word 0xe7f000f0@; do_multicall_call\n"         \
+            "    mov r0,#0; @ do_multicall_call\n"           \
+            "    str r0, [r0];\n"                            \
+            :                                                \
+            :                                                \
+            : );                                             \
+    } while ( 0 )
+
+#endif /* __ASM_ARM_MULTICALL_H__ */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/nmi.h b/xen/include/asm-arm/nmi.h
new file mode 100644
index 0000000..e0f19f9
--- /dev/null
+++ b/xen/include/asm-arm/nmi.h
@@ -0,0 +1,15 @@
+#ifndef ASM_NMI_H
+#define ASM_NMI_H
+
+#define register_guest_nmi_callback(a)  (-ENOSYS)
+#define unregister_guest_nmi_callback() (-ENOSYS)
+
+#endif /* ASM_NMI_H */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/numa.h b/xen/include/asm-arm/numa.h
new file mode 100644
index 0000000..cffee5c
--- /dev/null
+++ b/xen/include/asm-arm/numa.h
@@ -0,0 +1,21 @@
+#ifndef __ARCH_ARM_NUMA_H
+#define __ARCH_ARM_NUMA_H
+
+/* Fake one node for now... */
+#define cpu_to_node(cpu) 0
+#define node_to_cpumask(node)	(cpu_online_map)
+
+static inline __attribute__((pure)) int phys_to_nid(paddr_t addr)
+{
+        return 0;
+}
+
+#endif /* __ARCH_ARM_NUMA_H */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/paging.h b/xen/include/asm-arm/paging.h
new file mode 100644
index 0000000..4dc340f
--- /dev/null
+++ b/xen/include/asm-arm/paging.h
@@ -0,0 +1,13 @@
+#ifndef _XEN_PAGING_H
+#define _XEN_PAGING_H
+
+#endif /* XEN_PAGING_H */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/percpu.h b/xen/include/asm-arm/percpu.h
new file mode 100644
index 0000000..9d369eb
--- /dev/null
+++ b/xen/include/asm-arm/percpu.h
@@ -0,0 +1,28 @@
+#ifndef __ARM_PERCPU_H__
+#define __ARM_PERCPU_H__
+
+#ifndef __ASSEMBLY__
+extern char __per_cpu_start[], __per_cpu_data_end[];
+extern unsigned long __per_cpu_offset[NR_CPUS];
+void percpu_init_areas(void);
+#endif
+
+/* Separate out the type, so (int[3], foo) works. */
+#define __DEFINE_PER_CPU(type, name, suffix)                    \
+    __attribute__((__section__(".bss.percpu" #suffix)))         \
+    __typeof__(type) per_cpu_##name
+
+#define per_cpu(var, cpu) ((&per_cpu__##var)[cpu?0:0])
+#define __get_cpu_var(var) per_cpu__##var
+
+#define DECLARE_PER_CPU(type, name) extern __typeof__(type) per_cpu__##name
+
+#endif /* __ARM_PERCPU_H__ */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/processor.h b/xen/include/asm-arm/processor.h
new file mode 100644
index 0000000..1f85d31
--- /dev/null
+++ b/xen/include/asm-arm/processor.h
@@ -0,0 +1,269 @@
+#ifndef __ASM_ARM_PROCESSOR_H
+#define __ASM_ARM_PROCESSOR_H
+
+#include <asm/cpregs.h>
+
+/* PSR bits (CPSR, SPSR)*/
+
+/* 0-4: Mode */
+#define PSR_MODE_MASK 0x1f
+#define PSR_MODE_USR 0x10
+#define PSR_MODE_FIQ 0x11
+#define PSR_MODE_IRQ 0x12
+#define PSR_MODE_SVC 0x13
+#define PSR_MODE_MON 0x16
+#define PSR_MODE_ABT 0x17
+#define PSR_MODE_HYP 0x1a
+#define PSR_MODE_UND 0x1b
+#define PSR_MODE_SYS 0x1f
+
+#define PSR_THUMB        (1<<5)        /* Thumb Mode enable */
+#define PSR_FIQ_MASK        (1<<6)        /* Fast Interrupt mask */
+#define PSR_IRQ_MASK        (1<<7)        /* Interrupt mask */
+#define PSR_ABT_MASK         (1<<8)        /* Asynchronous Abort mask */
+#define PSR_BIG_ENDIAN        (1<<9)        /* Big Endian Mode */
+#define PSR_JAZELLE        (1<<24)        /* Jazelle Mode */
+
+/* TTBCR Translation Table Base Control Register */
+#define TTBCR_N_MASK 0x07
+#define TTBCR_N_16KB 0x00
+#define TTBCR_N_8KB  0x01
+#define TTBCR_N_4KB  0x02
+#define TTBCR_N_2KB  0x03
+#define TTBCR_N_1KB  0x04
+
+/* SCTLR System Control Register. */
+/* HSCTLR is a subset of this. */
+#define SCTLR_TE        (1<<30)
+#define SCTLR_AFE        (1<<29)
+#define SCTLR_TRE        (1<<28)
+#define SCTLR_NMFI        (1<<27)
+#define SCTLR_EE        (1<<25)
+#define SCTLR_VE        (1<<24)
+#define SCTLR_U                (1<<22)
+#define SCTLR_FI        (1<<21)
+#define SCTLR_WXN        (1<<19)
+#define SCTLR_HA        (1<<17)
+#define SCTLR_RR        (1<<14)
+#define SCTLR_V                (1<<13)
+#define SCTLR_I                (1<<12)
+#define SCTLR_Z                (1<<11)
+#define SCTLR_SW        (1<<10)
+#define SCTLR_B                (1<<7)
+#define SCTLR_C                (1<<2)
+#define SCTLR_A                (1<<1)
+#define SCTLR_M                (1<<0)
+
+#define SCTLR_BASE        0x00c50078
+#define HSCTLR_BASE        0x30c51878
+
+/* HCR Hyp Configuration Register */
+#define HCR_TGE                (1<<27)
+#define HCR_TVM                (1<<26)
+#define HCR_TTLB        (1<<25)
+#define HCR_TPU                (1<<24)
+#define HCR_TPC                (1<<23)
+#define HCR_TSW                (1<<22)
+#define HCR_TAC                (1<<21)
+#define HCR_TIDCP        (1<<20)
+#define HCR_TSC                (1<<19)
+#define HCR_TID3        (1<<18)
+#define HCR_TID2        (1<<17)
+#define HCR_TID1        (1<<16)
+#define HCR_TID0        (1<<15)
+#define HCR_TWE                (1<<14)
+#define HCR_TWI                (1<<13)
+#define HCR_DC                (1<<12)
+#define HCR_BSU_MASK        (3<<10)
+#define HCR_FB                (1<<9)
+#define HCR_VA                (1<<8)
+#define HCR_VI                (1<<7)
+#define HCR_VF                (1<<6)
+#define HCR_AMO                (1<<5)
+#define HCR_IMO                (1<<4)
+#define HCR_FMO                (1<<3)
+#define HCR_PTW                (1<<2)
+#define HCR_SWIO        (1<<1)
+#define HCR_VM                (1<<0)
+
+#define HSR_EC_WFI_WFE              0x01
+#define HSR_EC_CP15_32              0x03
+#define HSR_EC_CP15_64              0x04
+#define HSR_EC_CP14_32              0x05
+#define HSR_EC_CP14_DBG             0x06
+#define HSR_EC_CP                   0x07
+#define HSR_EC_CP10                 0x08
+#define HSR_EC_JAZELLE              0x09
+#define HSR_EC_BXJ                  0x0a
+#define HSR_EC_CP14_64              0x0c
+#define HSR_EC_SVC                  0x11
+#define HSR_EC_HVC                  0x12
+#define HSR_EC_INSTR_ABORT_GUEST    0x20
+#define HSR_EC_INSTR_ABORT_HYP      0x21
+#define HSR_EC_DATA_ABORT_GUEST     0x24
+#define HSR_EC_DATA_ABORT_HYP       0x25
+
+#ifndef __ASSEMBLY__
+union hsr {
+    uint32_t bits;
+    struct {
+        unsigned long iss:25;  /* Instruction Specific Syndrome */
+        unsigned long len:1;   /* Instruction length */
+        unsigned long ec:6;    /* Exception Class */
+    };
+
+    struct hsr_cp32 {
+        unsigned long read:1;  /* Direction */
+        unsigned long crm:4;   /* CRm */
+        unsigned long reg:4;   /* Rt */
+        unsigned long sbzp:1;
+        unsigned long crn:4;   /* CRn */
+        unsigned long op1:3;   /* Op1 */
+        unsigned long op2:3;   /* Op2 */
+        unsigned long cc:4;    /* Condition Code */
+        unsigned long ccvalid:1;/* CC Valid */
+        unsigned long len:1;   /* Instruction length */
+        unsigned long ec:6;    /* Exception Class */
+    } cp32; /* HSR_EC_CP15_32, CP14_32, CP10 */
+
+    struct hsr_cp64 {
+        unsigned long read:1;   /* Direction */
+        unsigned long crm:4;    /* CRm */
+        unsigned long reg1:4;   /* Rt1 */
+        unsigned long sbzp1:1;
+        unsigned long reg2:4;   /* Rt2 */
+        unsigned long sbzp2:2;
+        unsigned long op1:4;   /* Op1 */
+        unsigned long cc:4;    /* Condition Code */
+        unsigned long ccvalid:1;/* CC Valid */
+        unsigned long len:1;   /* Instruction length */
+        unsigned long ec:6;    /* Exception Class */
+    } cp64; /* HSR_EC_CP15_64, HSR_EC_CP14_64 */
+
+    struct hsr_dabt {
+        unsigned long dfsc:6;  /* Data Fault Status Code */
+        unsigned long write:1; /* Write / not Read */
+        unsigned long s1ptw:1; /* */
+        unsigned long cache:1; /* Cache Maintenance */
+        unsigned long eat:1;   /* External Abort Type */
+        unsigned long sbzp0:6;
+        unsigned long reg:4;   /* Register */
+        unsigned long sbzp1:1;
+        unsigned long sign:1;  /* Sign extend */
+        unsigned long size:2;  /* Access Size */
+        unsigned long valid:1; /* Syndrome Valid */
+        unsigned long len:1;   /* Instruction length */
+        unsigned long ec:6;    /* Exception Class */
+    } dabt; /* HSR_EC_DATA_ABORT_* */
+};
+#endif
+
+/* HSR.EC == HSR_CP{15,14,10}_32 */
+#define HSR_CP32_OP2_MASK (0x000e0000)
+#define HSR_CP32_OP2_SHIFT (17)
+#define HSR_CP32_OP1_MASK (0x0001c000)
+#define HSR_CP32_OP1_SHIFT (14)
+#define HSR_CP32_CRN_MASK (0x00003c00)
+#define HSR_CP32_CRN_SHIFT (10)
+#define HSR_CP32_CRM_MASK (0x0000001e)
+#define HSR_CP32_CRM_SHIFT (1)
+#define HSR_CP32_REGS_MASK (HSR_CP32_OP1_MASK|HSR_CP32_OP2_MASK|\
+                            HSR_CP32_CRN_MASK|HSR_CP32_CRM_MASK)
+
+/* HSR.EC == HSR_CP{15,14}_64 */
+#define HSR_CP64_OP1_MASK (0x000f0000)
+#define HSR_CP64_OP1_SHIFT (16)
+#define HSR_CP64_CRM_MASK (0x0000001e)
+#define HSR_CP64_CRM_SHIFT (1)
+#define HSR_CP64_REGS_MASK (HSR_CP64_OP1_MASK|HSR_CP64_CRM_MASK)
+
+/* Physical Address Register */
+#define PAR_F           (1<<0)
+
+/* .... If F == 1 */
+#define PAR_FSC_SHIFT   (1)
+#define PAR_FSC_MASK    (0x3f<<PAR_FSC_SHIFT)
+#define PAR_STAGE21     (1<<8)     /* Stage 2 Fault During Stage 1 Walk */
+#define PAR_STAGE2      (1<<9)     /* Stage 2 Fault */
+
+/* If F == 0 */
+#define PAR_MAIR_SHIFT  56                       /* Memory Attributes */
+#define PAR_MAIR_MASK   (0xffLL<<PAR_MAIR_SHIFT)
+#define PAR_NS          (1<<9)                   /* Non-Secure */
+#define PAR_SH_SHIFT    7                        /* Shareability */
+#define PAR_SH_MASK     (3<<PAR_SH_SHIFT)
+
+/* Fault Status Register */
+/*
+ * 543210 BIT
+ * 00XXLL -- XX Fault Level LL
+ * ..01LL -- Translation Fault LL
+ * ..10LL -- Access Fault LL
+ * ..11LL -- Permission Fault LL
+ * 01xxxx -- Abort/Parity
+ * 10xxxx -- Other
+ * 11xxxx -- Implementation Defined
+ */
+#define FSC_TYPE_MASK (0x3<<4)
+#define FSC_TYPE_FAULT (0x00<<4)
+#define FSC_TYPE_ABT   (0x01<<4)
+#define FSC_TYPE_OTH   (0x02<<4)
+#define FSC_TYPE_IMPL  (0x03<<4)
+
+#define FSC_FLT_TRANS  (0x04)
+#define FSC_FLT_ACCESS (0x08)
+#define FSC_FLT_PERM   (0x0c)
+#define FSC_SEA        (0x10) /* Synchronous External Abort */
+#define FSC_SPE        (0x18) /* Memory Access Synchronous Parity Error */
+#define FSC_APE        (0x11) /* Memory Access Asynchronous Parity Error */
+#define FSC_SEATT      (0x14) /* Sync. Ext. Abort Translation Table */
+#define FSC_SPETT      (0x1c) /* Sync. Parity. Error Translation Table */
+#define FSC_AF         (0x21) /* Alignment Fault */
+#define FSC_DE         (0x22) /* Debug Event */
+#define FSC_LKD        (0x34) /* Lockdown Abort */
+#define FSC_CPR        (0x3a) /* Coprocossor Abort */
+
+#define FSC_LL_MASK    (0x03<<0)
+
+/* Time counter hypervisor control register */
+#define CNTHCTL_PA      (1u<<0)  /* Kernel/user access to physical counter */
+#define CNTHCTL_TA      (1u<<1)  /* Kernel/user access to CNTP timer */
+
+/* Timer control registers */
+#define CNTx_CTL_ENABLE   (1u<<0)  /* Enable timer */
+#define CNTx_CTL_MASK     (1u<<1)  /* Mask IRQ */
+#define CNTx_CTL_PENDING  (1u<<2)  /* IRQ pending */
+
+/* CPUID bits */
+#define ID_PFR1_GT_MASK  0x000F0000  /* Generic Timer interface support */
+#define ID_PFR1_GT_v1    0x00010000
+
+#define MSR(reg,val)        asm volatile ("msr "#reg", %0\n" : : "r" (val))
+#define MRS(val,reg)        asm volatile ("mrs %0,"#reg"\n" : "=r" (v))
+
+#ifndef __ASSEMBLY__
+extern uint32_t hyp_traps_vector[8];
+
+void panic_PAR(uint64_t par, const char *when);
+
+void show_execution_state(struct cpu_user_regs *regs);
+void show_registers(struct cpu_user_regs *regs);
+//#define dump_execution_state() run_in_exception_handler(show_execution_state)
+#define dump_execution_state() asm volatile (".word 0xe7f000f0\n"); /* XXX */
+
+#define cpu_relax() barrier() /* Could yield? */
+
+/* All a bit UP for the moment */
+#define cpu_to_core(_cpu)   (0)
+#define cpu_to_socket(_cpu) (0)
+
+#endif /* __ASSEMBLY__ */
+#endif /* __ASM_ARM_PROCESSOR_H */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/regs.h b/xen/include/asm-arm/regs.h
new file mode 100644
index 0000000..ee095bf
--- /dev/null
+++ b/xen/include/asm-arm/regs.h
@@ -0,0 +1,43 @@
+#ifndef __ARM_REGS_H__
+#define __ARM_REGS_H__
+
+#include <xen/types.h>
+#include <public/xen.h>
+#include <asm/processor.h>
+
+#define psr_mode(psr,m) (((psr) & PSR_MODE_MASK) == m)
+
+#define usr_mode(r)     psr_mode((r)->cpsr,PSR_MODE_USR)
+#define fiq_mode(r)     psr_mode((r)->cpsr,PSR_MODE_FIQ)
+#define irq_mode(r)     psr_mode((r)->cpsr,PSR_MODE_IRQ)
+#define svc_mode(r)     psr_mode((r)->cpsr,PSR_MODE_SVC)
+#define mon_mode(r)     psr_mode((r)->cpsr,PSR_MODE_MON)
+#define abt_mode(r)     psr_mode((r)->cpsr,PSR_MODE_ABT)
+#define hyp_mode(r)     psr_mode((r)->cpsr,PSR_MODE_HYP)
+#define und_mode(r)     psr_mode((r)->cpsr,PSR_MODE_UND)
+#define sys_mode(r)     psr_mode((r)->cpsr,PSR_MODE_SYS)
+
+#define guest_mode(r)                                                         \
+({                                                                            \
+    unsigned long diff = (char *)guest_cpu_user_regs() - (char *)(r);         \
+    /* Frame pointer must point into current CPU stack. */                    \
+    ASSERT(diff < STACK_SIZE);                                                \
+    /* If not a guest frame, it must be a hypervisor frame. */                \
+    ASSERT((diff == 0) || hyp_mode(r));                                       \
+    /* Return TRUE if it's a guest frame. */                                  \
+    (diff == 0);                                                              \
+})
+
+#define return_reg(v) ((v)->arch.user_regs.r0)
+
+#define CTXT_SWITCH_STACK_BYTES (sizeof(struct cpu_user_regs))
+
+#endif /* __ARM_REGS_H__ */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/setup.h b/xen/include/asm-arm/setup.h
new file mode 100644
index 0000000..c27d438
--- /dev/null
+++ b/xen/include/asm-arm/setup.h
@@ -0,0 +1,16 @@
+#ifndef __ARM_SETUP_H_
+#define __ARM_SETUP_H_
+
+#include <public/version.h>
+
+void arch_get_xen_caps(xen_capabilities_info_t *info);
+
+#endif
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/smp.h b/xen/include/asm-arm/smp.h
new file mode 100644
index 0000000..9cdd87f
--- /dev/null
+++ b/xen/include/asm-arm/smp.h
@@ -0,0 +1,25 @@
+#ifndef __ASM_SMP_H
+#define __ASM_SMP_H
+
+#ifndef __ASSEMBLY__
+#include <xen/config.h>
+#include <xen/cpumask.h>
+#include <asm/current.h>
+#endif
+
+DECLARE_PER_CPU(cpumask_var_t, cpu_sibling_mask);
+DECLARE_PER_CPU(cpumask_var_t, cpu_core_mask);
+
+#define cpu_is_offline(cpu) unlikely(!cpu_online(cpu))
+
+#define raw_smp_processor_id() (get_processor_id())
+
+#endif
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/softirq.h b/xen/include/asm-arm/softirq.h
new file mode 100644
index 0000000..536af38
--- /dev/null
+++ b/xen/include/asm-arm/softirq.h
@@ -0,0 +1,15 @@
+#ifndef __ASM_SOFTIRQ_H__
+#define __ASM_SOFTIRQ_H__
+
+#define VGIC_SOFTIRQ        (NR_COMMON_SOFTIRQS + 0)
+#define NR_ARCH_SOFTIRQS       1
+
+#endif /* __ASM_SOFTIRQ_H__ */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/spinlock.h b/xen/include/asm-arm/spinlock.h
new file mode 100644
index 0000000..b1825c9
--- /dev/null
+++ b/xen/include/asm-arm/spinlock.h
@@ -0,0 +1,144 @@
+#ifndef __ASM_SPINLOCK_H
+#define __ASM_SPINLOCK_H
+
+#include <xen/config.h>
+#include <xen/lib.h>
+
+static inline void dsb_sev(void)
+{
+    __asm__ __volatile__ (
+        "dsb\n"
+        "sev\n"
+        );
+}
+
+typedef struct {
+    volatile unsigned int lock;
+} raw_spinlock_t;
+
+#define _RAW_SPIN_LOCK_UNLOCKED { 0 }
+
+#define _raw_spin_is_locked(x)          ((x)->lock != 0)
+
+static always_inline void _raw_spin_unlock(raw_spinlock_t *lock)
+{
+    ASSERT(_raw_spin_is_locked(lock));
+
+    smp_mb();
+
+    __asm__ __volatile__(
+"   str     %1, [%0]\n"
+    :
+    : "r" (&lock->lock), "r" (0)
+    : "cc");
+
+    dsb_sev();
+}
+
+static always_inline int _raw_spin_trylock(raw_spinlock_t *lock)
+{
+    unsigned long tmp;
+
+    __asm__ __volatile__(
+"   ldrex   %0, [%1]\n"
+"   teq     %0, #0\n"
+"   strexeq %0, %2, [%1]"
+    : "=&r" (tmp)
+    : "r" (&lock->lock), "r" (1)
+    : "cc");
+
+    if (tmp == 0) {
+        smp_mb();
+        return 1;
+    } else {
+        return 0;
+    }
+}
+
+typedef struct {
+    volatile unsigned int lock;
+} raw_rwlock_t;
+
+#define _RAW_RW_LOCK_UNLOCKED { 0 }
+
+static always_inline int _raw_read_trylock(raw_rwlock_t *rw)
+{
+    unsigned long tmp, tmp2 = 1;
+
+    __asm__ __volatile__(
+"1: ldrex   %0, [%2]\n"
+"   adds    %0, %0, #1\n"
+"   strexpl %1, %0, [%2]\n"
+    : "=&r" (tmp), "+r" (tmp2)
+    : "r" (&rw->lock)
+    : "cc");
+
+    smp_mb();
+    return tmp2 == 0;
+}
+
+static always_inline int _raw_write_trylock(raw_rwlock_t *rw)
+{
+    unsigned long tmp;
+
+    __asm__ __volatile__(
+"1: ldrex   %0, [%1]\n"
+"   teq     %0, #0\n"
+"   strexeq %0, %2, [%1]"
+    : "=&r" (tmp)
+    : "r" (&rw->lock), "r" (0x80000000)
+    : "cc");
+
+    if (tmp == 0) {
+        smp_mb();
+        return 1;
+    } else {
+        return 0;
+    }
+}
+
+static inline void _raw_read_unlock(raw_rwlock_t *rw)
+{
+    unsigned long tmp, tmp2;
+
+    smp_mb();
+
+    __asm__ __volatile__(
+"1: ldrex   %0, [%2]\n"
+"   sub     %0, %0, #1\n"
+"   strex   %1, %0, [%2]\n"
+"   teq     %1, #0\n"
+"   bne     1b"
+    : "=&r" (tmp), "=&r" (tmp2)
+    : "r" (&rw->lock)
+    : "cc");
+
+    if (tmp == 0)
+        dsb_sev();
+}
+
+static inline void _raw_write_unlock(raw_rwlock_t *rw)
+{
+    smp_mb();
+
+    __asm__ __volatile__(
+    "str    %1, [%0]\n"
+    :
+    : "r" (&rw->lock), "r" (0)
+    : "cc");
+
+    dsb_sev();
+}
+
+#define _raw_rw_is_locked(x) ((x)->lock != 0)
+#define _raw_rw_is_write_locked(x) ((x)->lock == 0x80000000)
+
+#endif /* __ASM_SPINLOCK_H */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/string.h b/xen/include/asm-arm/string.h
new file mode 100644
index 0000000..f2d643d
--- /dev/null
+++ b/xen/include/asm-arm/string.h
@@ -0,0 +1,38 @@
+#ifndef __ARM_STRING_H__
+#define __ARM_STRING_H__
+
+#include <xen/config.h>
+
+#define __HAVE_ARCH_MEMCPY
+extern void * memcpy(void *, const void *, __kernel_size_t);
+
+/* Some versions of gcc don't have this builtin. It's non-critical anyway. */
+#define __HAVE_ARCH_MEMMOVE
+extern void *memmove(void *dest, const void *src, size_t n);
+
+#define __HAVE_ARCH_MEMSET
+extern void * memset(void *, int, __kernel_size_t);
+
+extern void __memzero(void *ptr, __kernel_size_t n);
+
+#define memset(p,v,n)                                                   \
+        ({                                                              \
+                void *__p = (p); size_t __n = n;                        \
+                if ((__n) != 0) {                                       \
+                        if (__builtin_constant_p((v)) && (v) == 0)      \
+                                __memzero((__p),(__n));                 \
+                        else                                            \
+                                memset((__p),(v),(__n));                \
+                }                                                       \
+                (__p);                                                  \
+        })
+
+#endif /* __ARM_STRING_H__ */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/system.h b/xen/include/asm-arm/system.h
new file mode 100644
index 0000000..731d89f
--- /dev/null
+++ b/xen/include/asm-arm/system.h
@@ -0,0 +1,202 @@
+/* Portions taken from Linux arch arm */
+#ifndef __ASM_SYSTEM_H
+#define __ASM_SYSTEM_H
+
+#include <xen/lib.h>
+#include <asm/processor.h>
+
+#define nop() \
+    asm volatile ( "nop" )
+
+#define xchg(ptr,x) \
+        ((__typeof__(*(ptr)))__xchg((unsigned long)(x),(ptr),sizeof(*(ptr))))
+
+#define isb() __asm__ __volatile__ ("isb" : : : "memory")
+#define dsb() __asm__ __volatile__ ("dsb" : : : "memory")
+#define dmb() __asm__ __volatile__ ("dmb" : : : "memory")
+
+#define mb()            dsb()
+#define rmb()           dsb()
+#define wmb()           mb()
+
+#define smp_mb()        dmb()
+#define smp_rmb()       dmb()
+#define smp_wmb()       dmb()
+
+/*
+ * This is used to ensure the compiler did actually allocate the register we
+ * asked it for some inline assembly sequences.  Apparently we can't trust
+ * the compiler from one version to another so a bit of paranoia won't hurt.
+ * This string is meant to be concatenated with the inline asm string and
+ * will cause compilation to stop on mismatch.
+ * (for details, see gcc PR 15089)
+ */
+#define __asmeq(x, y)  ".ifnc " x "," y " ; .err ; .endif\n\t"
+
+extern void __bad_xchg(volatile void *, int);
+
+static inline unsigned long __xchg(unsigned long x, volatile void *ptr, int size)
+{
+        unsigned long ret;
+        unsigned int tmp;
+
+        smp_mb();
+
+        switch (size) {
+        case 1:
+                asm volatile("@ __xchg1\n"
+                "1:     ldrexb  %0, [%3]\n"
+                "       strexb  %1, %2, [%3]\n"
+                "       teq     %1, #0\n"
+                "       bne     1b"
+                        : "=&r" (ret), "=&r" (tmp)
+                        : "r" (x), "r" (ptr)
+                        : "memory", "cc");
+                break;
+        case 4:
+                asm volatile("@ __xchg4\n"
+                "1:     ldrex   %0, [%3]\n"
+                "       strex   %1, %2, [%3]\n"
+                "       teq     %1, #0\n"
+                "       bne     1b"
+                        : "=&r" (ret), "=&r" (tmp)
+                        : "r" (x), "r" (ptr)
+                        : "memory", "cc");
+                break;
+        default:
+                __bad_xchg(ptr, size), ret = 0;
+                break;
+        }
+        smp_mb();
+
+        return ret;
+}
+
+/*
+ * Atomic compare and exchange.  Compare OLD with MEM, if identical,
+ * store NEW in MEM.  Return the initial value in MEM.  Success is
+ * indicated by comparing RETURN with OLD.
+ */
+
+extern void __bad_cmpxchg(volatile void *ptr, int size);
+
+static always_inline unsigned long __cmpxchg(
+    volatile void *ptr, unsigned long old, unsigned long new, int size)
+{
+    unsigned long /*long*/ oldval, res;
+
+    switch (size) {
+    case 1:
+        do {
+            asm volatile("@ __cmpxchg1\n"
+                         "       ldrexb  %1, [%2]\n"
+                         "       mov     %0, #0\n"
+                         "       teq     %1, %3\n"
+                         "       strexbeq %0, %4, [%2]\n"
+                         : "=&r" (res), "=&r" (oldval)
+                         : "r" (ptr), "Ir" (old), "r" (new)
+                         : "memory", "cc");
+        } while (res);
+        break;
+    case 2:
+        do {
+            asm volatile("@ __cmpxchg2\n"
+                         "       ldrexh  %1, [%2]\n"
+                         "       mov     %0, #0\n"
+                         "       teq     %1, %3\n"
+                         "       strexheq %0, %4, [%2]\n"
+                         : "=&r" (res), "=&r" (oldval)
+                         : "r" (ptr), "Ir" (old), "r" (new)
+                         : "memory", "cc");
+        } while (res);
+        break;
+    case 4:
+        do {
+            asm volatile("@ __cmpxchg4\n"
+                         "       ldrex   %1, [%2]\n"
+                         "       mov     %0, #0\n"
+                         "       teq     %1, %3\n"
+                         "       strexeq %0, %4, [%2]\n"
+                         : "=&r" (res), "=&r" (oldval)
+                         : "r" (ptr), "Ir" (old), "r" (new)
+                         : "memory", "cc");
+        } while (res);
+        break;
+#if 0
+    case 8:
+        do {
+            asm volatile("@ __cmpxchg8\n"
+                         "       ldrexd   %1, [%2]\n"
+                         "       mov      %0, #0\n"
+                         "       teq      %1, %3\n"
+                         "       strexdeq %0, %4, [%2]\n"
+                         : "=&r" (res), "=&r" (oldval)
+                         : "r" (ptr), "Ir" (old), "r" (new)
+                         : "memory", "cc");
+        } while (res);
+        break;
+#endif
+    default:
+        __bad_cmpxchg(ptr, size);
+        oldval = 0;
+    }
+
+    return oldval;
+}
+#define cmpxchg(ptr,o,n)                                                \
+    ((__typeof__(*(ptr)))__cmpxchg((ptr),(unsigned long)(o),            \
+                                   (unsigned long)(n),sizeof(*(ptr))))
+
+#define local_irq_disable() asm volatile ( "cpsid i @ local_irq_disable\n" : : : "cc" )
+#define local_irq_enable()  asm volatile ( "cpsie i @ local_irq_enable\n" : : : "cc" )
+
+#define local_save_flags(x)                                      \
+({                                                               \
+    BUILD_BUG_ON(sizeof(x) != sizeof(long));                     \
+    asm volatile ( "mrs %0, cpsr     @ local_save_flags\n"       \
+                  : "=r" (x) :: "memory", "cc" );                \
+})
+#define local_irq_save(x)                                        \
+({                                                               \
+    local_save_flags(x);                                         \
+    local_irq_disable();                                         \
+})
+#define local_irq_restore(x)                                     \
+({                                                               \
+    BUILD_BUG_ON(sizeof(x) != sizeof(long));                     \
+    asm volatile (                                               \
+            "msr     cpsr_c, %0      @ local_irq_restore\n"      \
+            :                                                    \
+            : "r" (flags)                                        \
+            : "memory", "cc");                                   \
+})
+
+static inline int local_irq_is_enabled(void)
+{
+    unsigned long flags;
+    local_save_flags(flags);
+    return !(flags & PSR_IRQ_MASK);
+}
+
+#define local_fiq_enable()  __asm__("cpsie f   @ __stf\n" : : : "memory", "cc")
+#define local_fiq_disable() __asm__("cpsid f   @ __clf\n" : : : "memory", "cc")
+
+#define local_abort_enable() __asm__("cpsie a  @ __sta\n" : : : "memory", "cc")
+#define local_abort_disable() __asm__("cpsid a @ __sta\n" : : : "memory", "cc")
+
+static inline int local_fiq_is_enabled(void)
+{
+    unsigned long flags;
+    local_save_flags(flags);
+    return !!(flags & PSR_FIQ_MASK);
+}
+
+#endif
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/trace.h b/xen/include/asm-arm/trace.h
new file mode 100644
index 0000000..db84541
--- /dev/null
+++ b/xen/include/asm-arm/trace.h
@@ -0,0 +1,12 @@
+#ifndef __ASM_TRACE_H__
+#define __ASM_TRACE_H__
+
+#endif /* __ASM_TRACE_H__ */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/types.h b/xen/include/asm-arm/types.h
new file mode 100644
index 0000000..48864f9
--- /dev/null
+++ b/xen/include/asm-arm/types.h
@@ -0,0 +1,57 @@
+#ifndef __ARM_TYPES_H__
+#define __ARM_TYPES_H__
+
+#ifndef __ASSEMBLY__
+
+#include <xen/config.h>
+
+typedef __signed__ char __s8;
+typedef unsigned char __u8;
+
+typedef __signed__ short __s16;
+typedef unsigned short __u16;
+
+typedef __signed__ int __s32;
+typedef unsigned int __u32;
+
+#if defined(__GNUC__) && !defined(__STRICT_ANSI__)
+typedef __signed__ long long __s64;
+typedef unsigned long long __u64;
+#endif
+
+typedef signed char s8;
+typedef unsigned char u8;
+
+typedef signed short s16;
+typedef unsigned short u16;
+
+typedef signed int s32;
+typedef unsigned int u32;
+
+typedef signed long long s64;
+typedef unsigned long long u64;
+typedef u64 paddr_t;
+#define INVALID_PADDR (~0ULL)
+#define PRIpaddr "016llx"
+
+typedef unsigned long size_t;
+
+typedef char bool_t;
+#define test_and_set_bool(b)   xchg(&(b), 1)
+#define test_and_clear_bool(b) xchg(&(b), 0)
+
+#endif /* __ASSEMBLY__ */
+
+#define BITS_PER_LONG 32
+#define BYTES_PER_LONG 4
+#define LONG_BYTEORDER 2
+
+#endif /* __ARM_TYPES_H__ */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/xenoprof.h b/xen/include/asm-arm/xenoprof.h
new file mode 100644
index 0000000..131ac13
--- /dev/null
+++ b/xen/include/asm-arm/xenoprof.h
@@ -0,0 +1,12 @@
+#ifndef __ASM_XENOPROF_H__
+#define __ASM_XENOPROF_H__
+
+#endif /* __ASM_XENOPROF_H__ */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
new file mode 100644
index 0000000..4d1daa9
--- /dev/null
+++ b/xen/include/public/arch-arm.h
@@ -0,0 +1,125 @@
+/******************************************************************************
+ * arch-arm.h
+ *
+ * Guest OS interface to ARM 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 2011 (C) Citrix Systems
+ */
+
+#ifndef __XEN_PUBLIC_ARCH_ARM_H__
+#define __XEN_PUBLIC_ARCH_ARM_H__
+
+#ifndef __ASSEMBLY__
+#define ___DEFINE_XEN_GUEST_HANDLE(name, type) \
+    typedef struct { type *p; } __guest_handle_ ## name
+
+#define __DEFINE_XEN_GUEST_HANDLE(name, type) \
+    ___DEFINE_XEN_GUEST_HANDLE(name, type);   \
+    ___DEFINE_XEN_GUEST_HANDLE(const_##name, const type)
+#define DEFINE_XEN_GUEST_HANDLE(name)   __DEFINE_XEN_GUEST_HANDLE(name, name)
+#define __XEN_GUEST_HANDLE(name)        __guest_handle_ ## name
+#define XEN_GUEST_HANDLE(name)          __XEN_GUEST_HANDLE(name)
+#define set_xen_guest_handle_raw(hnd, val)  do { (hnd).p = val; } while (0)
+#ifdef __XEN_TOOLS__
+#define get_xen_guest_handle(val, hnd)  do { val = (hnd).p; } while (0)
+#endif
+#define set_xen_guest_handle(hnd, val) set_xen_guest_handle_raw(hnd, val)
+
+struct cpu_user_regs
+{
+    uint32_t r0;
+    uint32_t r1;
+    uint32_t r2;
+    uint32_t r3;
+    uint32_t r4;
+    uint32_t r5;
+    uint32_t r6;
+    uint32_t r7;
+    uint32_t r8;
+    uint32_t r9;
+    uint32_t r10;
+    union {
+	uint32_t r11;
+	uint32_t fp;
+    };
+    uint32_t r12;
+
+    uint32_t sp; /* r13 - SP: Valid for Hyp. frames only, o/w banked (see below) */
+    uint32_t lr; /* r14 - LR: Valid for Hyp. Same physical register as lr_usr. */
+
+    uint32_t pc; /* Return IP */
+    uint32_t cpsr; /* Return mode */
+    uint32_t pad0; /* Doubleword-align the kernel half of the frame */
+
+    /* Outer guest frame only from here on... */
+
+    uint32_t r8_fiq, r9_fiq, r10_fiq, r11_fiq, r12_fiq;
+
+    uint32_t sp_usr, sp_svc, sp_abt, sp_und, sp_irq, sp_fiq;
+    uint32_t lr_usr, lr_svc, lr_abt, lr_und, lr_irq, lr_fiq;
+
+    uint32_t spsr_svc, spsr_abt, spsr_und, spsr_irq, spsr_fiq;
+};
+typedef struct cpu_user_regs cpu_user_regs_t;
+DEFINE_XEN_GUEST_HANDLE(cpu_user_regs_t);
+
+typedef uint64_t xen_pfn_t;
+#define PRI_xen_pfn PRIx64
+
+/* Maximum number of virtual CPUs in legacy multi-processor guests. */
+/* Only one. All other VCPUS must use VCPUOP_register_vcpu_info */
+#define XEN_LEGACY_MAX_VCPUS 1
+
+typedef uint32_t xen_ulong_t;
+
+struct vcpu_guest_context {
+    struct cpu_user_regs user_regs;         /* User-level CPU registers     */
+    union {
+	uint32_t reg[16];
+	struct {
+	    uint32_t __pad[12];
+	    uint32_t sp; /* r13 */
+	    uint32_t lr; /* r14 */
+	    uint32_t pc; /* r15 */
+	};
+    };
+};
+typedef struct vcpu_guest_context vcpu_guest_context_t;
+DEFINE_XEN_GUEST_HANDLE(vcpu_guest_context_t);
+
+struct arch_vcpu_info { };
+typedef struct arch_vcpu_info arch_vcpu_info_t;
+
+struct arch_shared_info { };
+typedef struct arch_shared_info arch_shared_info_t;
+#endif
+
+#endif /*  __XEN_PUBLIC_ARCH_ARM_H__ */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
index fde9fa5..7196400 100644
--- a/xen/include/public/xen.h
+++ b/xen/include/public/xen.h
@@ -33,6 +33,8 @@
 #include "arch-x86/xen.h"
 #elif defined(__ia64__)
 #include "arch-ia64.h"
+#elif defined(__arm__)
+#include "arch-arm.h"
 #else
 #error "Unsupported architecture"
 #endif
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 16:29:28 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 16: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.xensource.com>)
	id 1RbEBQ-0002BT-BK; Thu, 15 Dec 2011 16:29:24 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RbEBO-00024T-Tp
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 16:29:23 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1323966553!7437895!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjE2NDg=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9394 invoked from network); 15 Dec 2011 16:29:16 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 16:29:16 -0000
X-IronPort-AV: E=Sophos;i="4.71,357,1320642000"; d="scan'208";a="174308231"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Dec 2011 11:29:16 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Thu, 15 Dec 2011 11:29:15 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pBFGSMte003330;
	Thu, 15 Dec 2011 08:28:58 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Thu, 15 Dec 2011 16:30:48 +0000
Message-ID: <1323966657-19790-16-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1112131831560.3517@kaball-desktop>
References: <alpine.DEB.2.00.1112131831560.3517@kaball-desktop>
MIME-Version: 1.0
Cc: keir.xen@gmail.com, Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, JBeulich@suse.com,
	Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v3 16/25] arm: irq
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

A simple do_IRQ and request_irq implementation for ARM.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
---
 xen/arch/arm/irq.c          |  179 +++++++++++++++++++++++++++++++++++++++++++
 xen/include/asm-arm/irq.h   |   30 +++++++
 xen/include/asm-arm/setup.h |    2 +
 xen/include/xen/irq.h       |   13 +++
 4 files changed, 224 insertions(+), 0 deletions(-)
 create mode 100644 xen/arch/arm/irq.c
 create mode 100644 xen/include/asm-arm/irq.h

diff --git a/xen/arch/arm/irq.c b/xen/arch/arm/irq.c
new file mode 100644
index 0000000..5663762
--- /dev/null
+++ b/xen/arch/arm/irq.c
@@ -0,0 +1,179 @@
+/*
+ * xen/arch/arm/irq.c
+ *
+ * ARM Interrupt support
+ *
+ * Ian Campbell <ian.campbell@citrix.com>
+ * Copyright (c) 2011 Citrix Systems.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include <xen/config.h>
+#include <xen/lib.h>
+#include <xen/spinlock.h>
+#include <xen/irq.h>
+#include <xen/init.h>
+#include <xen/errno.h>
+#include <xen/sched.h>
+
+#include "gic.h"
+
+static void enable_none(struct irq_desc *irq) { }
+static unsigned int startup_none(struct irq_desc *irq) { return 0; }
+static void disable_none(struct irq_desc *irq) { }
+static void ack_none(struct irq_desc *irq)
+{
+    printk("unexpected IRQ trap at irq %02x\n", irq->irq);
+}
+
+#define shutdown_none   disable_none
+#define end_none        enable_none
+
+hw_irq_controller no_irq_type = {
+    .typename = "none",
+    .startup = startup_none,
+    .shutdown = shutdown_none,
+    .enable = enable_none,
+    .disable = disable_none,
+    .ack = ack_none,
+    .end = end_none
+};
+
+int __init arch_init_one_irq_desc(struct irq_desc *desc)
+{
+	return 0;
+}
+
+
+static int __init init_irq_data(void)
+{
+    int irq;
+
+    for (irq = 0; irq < NR_IRQS; irq++) {
+        struct irq_desc *desc = irq_to_desc(irq);
+        init_one_irq_desc(desc);
+        desc->irq = irq;
+        desc->action  = NULL;
+    }
+    return 0;
+}
+
+void __init init_IRQ(void)
+{
+    BUG_ON(init_irq_data() < 0);
+}
+
+int __init request_irq(unsigned int irq,
+        void (*handler)(int, void *, struct cpu_user_regs *),
+        unsigned long irqflags, const char * devname, void *dev_id)
+{
+    struct irqaction *action;
+    int retval;
+
+    /*
+     * Sanity-check: shared interrupts must pass in a real dev-ID,
+     * otherwise we'll have trouble later trying to figure out
+     * which interrupt is which (messes up the interrupt freeing
+     * logic etc).
+     */
+    if (irq >= nr_irqs)
+        return -EINVAL;
+    if (!handler)
+        return -EINVAL;
+
+    action = xmalloc(struct irqaction);
+    if (!action)
+        return -ENOMEM;
+
+    action->handler = handler;
+    action->name = devname;
+    action->dev_id = dev_id;
+    action->free_on_release = 1;
+
+    retval = setup_irq(irq, action);
+    if (retval)
+        xfree(action);
+
+    return retval;
+}
+
+/* Dispatch an interrupt */
+void do_IRQ(struct cpu_user_regs *regs, unsigned int irq, int is_fiq)
+{
+    struct irq_desc *desc = irq_to_desc(irq);
+    struct irqaction *action = desc->action;
+
+    /* TODO: perfc_incr(irqs); */
+
+    /* TODO: this_cpu(irq_count)++; */
+
+    irq_enter();
+
+    spin_lock(&desc->lock);
+    desc->handler->ack(desc);
+
+    if ( action == NULL )
+    {
+        printk("Unknown %s %#3.3x\n",
+               is_fiq ? "FIQ" : "IRQ", irq);
+        goto out;
+    }
+
+    if ( desc->status & IRQ_GUEST )
+    {
+        struct domain *d = action->dev_id;
+
+        desc->handler->end(desc);
+
+        desc->status |= IRQ_INPROGRESS;
+
+        /* XXX: inject irq into the guest */
+        goto out_no_end;
+    }
+
+    desc->status |= IRQ_PENDING;
+
+    /*
+     * Since we set PENDING, if another processor is handling a different
+     * instance of this same irq, the other processor will take care of it.
+     */
+    if ( desc->status & (IRQ_DISABLED | IRQ_INPROGRESS) )
+        goto out;
+
+    desc->status |= IRQ_INPROGRESS;
+
+    action = desc->action;
+    while ( desc->status & IRQ_PENDING )
+    {
+        desc->status &= ~IRQ_PENDING;
+        spin_unlock_irq(&desc->lock);
+        action->handler(irq, action->dev_id, regs);
+        spin_lock_irq(&desc->lock);
+    }
+
+    desc->status &= ~IRQ_INPROGRESS;
+
+out:
+    desc->handler->end(desc);
+out_no_end:
+    spin_unlock(&desc->lock);
+    irq_exit();
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/irq.h b/xen/include/asm-arm/irq.h
new file mode 100644
index 0000000..8e65a2e
--- /dev/null
+++ b/xen/include/asm-arm/irq.h
@@ -0,0 +1,30 @@
+#ifndef _ASM_HW_IRQ_H
+#define _ASM_HW_IRQ_H
+
+#include <xen/config.h>
+
+#define NR_VECTORS 256 /* XXX */
+
+typedef struct {
+    DECLARE_BITMAP(_bits,NR_VECTORS);
+} vmask_t;
+
+struct arch_pirq
+{
+};
+
+struct irq_cfg {
+#define arch_irq_desc irq_cfg
+};
+
+void do_IRQ(struct cpu_user_regs *regs, unsigned int irq, int is_fiq);
+
+#endif /* _ASM_HW_IRQ_H */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/setup.h b/xen/include/asm-arm/setup.h
index 1dc3f97..2041f06 100644
--- a/xen/include/asm-arm/setup.h
+++ b/xen/include/asm-arm/setup.h
@@ -7,6 +7,8 @@ void arch_get_xen_caps(xen_capabilities_info_t *info);
 
 int construct_dom0(struct domain *d);
 
+void init_IRQ(void);
+
 #endif
 /*
  * Local variables:
diff --git a/xen/include/xen/irq.h b/xen/include/xen/irq.h
index a2a90e1..5a711cc 100644
--- a/xen/include/xen/irq.h
+++ b/xen/include/xen/irq.h
@@ -107,6 +107,19 @@ extern irq_desc_t irq_desc[NR_VECTORS];
 
 #define request_irq(irq, handler, irqflags, devname, devid) \
     request_irq_vector(irq_to_vector(irq), handler, irqflags, devname, devid)
+
+#elif defined(__arm__)
+
+#define NR_IRQS		1024
+#define nr_irqs NR_IRQS
+extern irq_desc_t irq_desc[NR_IRQS];
+
+extern int setup_irq(unsigned int irq, struct irqaction *);
+extern void release_irq(unsigned int irq);
+extern int request_irq(unsigned int irq,
+               void (*handler)(int, void *, struct cpu_user_regs *),
+               unsigned long irqflags, const char * devname, void *dev_id);
+
 #else
 extern int setup_irq(unsigned int irq, struct irqaction *);
 extern void release_irq(unsigned int irq);
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 16:29:28 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 16: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.xensource.com>)
	id 1RbEBS-0002Eg-BF; Thu, 15 Dec 2011 16:29:26 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RbEBP-0002Ac-TO
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 16:29:24 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1323966525!56866011!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDY5Mjg=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17183 invoked from network); 15 Dec 2011 16:28:47 -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 2011 16:28:47 -0000
X-IronPort-AV: E=Sophos;i="4.71,357,1320642000"; d="scan'208";a="20001872"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Dec 2011 11:29:21 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Thu, 15 Dec 2011 11:29:20 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pBFGSMtj003330;
	Thu, 15 Dec 2011 08:29:07 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Thu, 15 Dec 2011 16:30:53 +0000
Message-ID: <1323966657-19790-21-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1112131831560.3517@kaball-desktop>
References: <alpine.DEB.2.00.1112131831560.3517@kaball-desktop>
MIME-Version: 1.0
Cc: keir.xen@gmail.com, Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, JBeulich@suse.com,
	Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v3 21/25] arm: driver for the generic timer for
	ARMv7
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Driver for the generic timer for ARMv7 with virtualization extensions.
Currently it is based on the kernel timer rather than the hypervisor timer
because the latter does not work correctly on our test environment.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
---
 xen/arch/arm/time.c        |  181 ++++++++++++++++++++++++++++++++++++++++++++
 xen/include/asm-arm/time.h |   26 ++++++
 2 files changed, 207 insertions(+), 0 deletions(-)
 create mode 100644 xen/arch/arm/time.c
 create mode 100644 xen/include/asm-arm/time.h

diff --git a/xen/arch/arm/time.c b/xen/arch/arm/time.c
new file mode 100644
index 0000000..13c1254
--- /dev/null
+++ b/xen/arch/arm/time.c
@@ -0,0 +1,181 @@
+/*
+ * xen/arch/arm/time.c
+ *
+ * Time and timer support, using the ARM Generic Timer interfaces
+ *
+ * Tim Deegan <tim@xen.org>
+ * Copyright (c) 2011 Citrix Systems.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include <xen/config.h>
+#include <xen/console.h>
+#include <xen/init.h>
+#include <xen/irq.h>
+#include <xen/lib.h>
+#include <xen/mm.h>
+#include <xen/softirq.h>
+#include <xen/time.h>
+#include <asm/system.h>
+
+/* Unfortunately the hypervisor timer interrupt appears to be buggy */
+#define USE_HYP_TIMER 0
+
+/* For fine-grained timekeeping, we use the ARM "Generic Timer", a
+ * register-mapped time source in the SoC. */
+static uint32_t __read_mostly cntfrq;      /* Ticks per second */
+static uint64_t __read_mostly boot_count;  /* Counter value at boot time */
+
+/*static inline*/ s_time_t ticks_to_ns(uint64_t ticks)
+{
+    return muldiv64(ticks, SECONDS(1), cntfrq);
+}
+
+/*static inline*/ uint64_t ns_to_ticks(s_time_t ns)
+{
+    return muldiv64(ns, cntfrq, SECONDS(1));
+}
+
+/* TODO: On a real system the firmware would have set the frequency in
+   the CNTFRQ register.  Also we'd need to use devicetree to find
+   the RTC.  When we've seen some real systems, we can delete this.
+static uint32_t calibrate_timer(void)
+{
+    uint32_t sec;
+    uint64_t start, end;
+    paddr_t rtc_base = 0x1C170000ull;
+    volatile uint32_t *rtc;
+
+    ASSERT(!local_irq_is_enabled());
+    set_fixmap(FIXMAP_MISC, rtc_base >> PAGE_SHIFT, DEV_SHARED);
+    rtc = (uint32_t *) FIXMAP_ADDR(FIXMAP_MISC);
+
+    printk("Calibrating timer against RTC...");
+    // Turn on the RTC
+    rtc[3] = 1;
+    // Wait for an edge
+    sec = rtc[0] + 1;
+    do {} while ( rtc[0] != sec );
+    // Now time a few seconds
+    start = READ_CP64(CNTPCT);
+    do {} while ( rtc[0] < sec + 32 );
+    end = READ_CP64(CNTPCT);
+    printk("done.\n");
+
+    clear_fixmap(FIXMAP_MISC);
+    return (end - start) / 32;
+}
+*/
+
+/* Set up the timer on the boot CPU */
+int __init init_xen_time(void)
+{
+    /* Check that this CPU supports the Generic Timer interface */
+    if ( (READ_CP32(ID_PFR1) & ID_PFR1_GT_MASK) != ID_PFR1_GT_v1 )
+        panic("CPU does not support the Generic Timer v1 interface.\n");
+
+    cntfrq = READ_CP32(CNTFRQ);
+    boot_count = READ_CP64(CNTPCT);
+    printk("Using generic timer at %"PRIu32" Hz\n", cntfrq);
+
+    return 0;
+}
+
+/* Return number of nanoseconds since boot */
+s_time_t get_s_time(void)
+{
+    uint64_t ticks = READ_CP64(CNTPCT) - boot_count;
+    return ticks_to_ns(ticks);
+}
+
+/* Set the timer to wake us up at a particular time.
+ * Timeout is a Xen system time (nanoseconds since boot); 0 disables the timer.
+ * Returns 1 on success; 0 if the timeout is too soon or is in the past. */
+int reprogram_timer(s_time_t timeout)
+{
+    uint64_t deadline;
+
+    if ( timeout == 0 )
+    {
+#if USE_HYP_TIMER
+        WRITE_CP32(0, CNTHP_CTL);
+#else
+        WRITE_CP32(0, CNTP_CTL);
+#endif
+        return 1;
+    }
+
+    deadline = ns_to_ticks(timeout) + boot_count;
+#if USE_HYP_TIMER
+    WRITE_CP64(deadline, CNTHP_CVAL);
+    WRITE_CP32(CNTx_CTL_ENABLE, CNTHP_CTL);
+#else
+    WRITE_CP64(deadline, CNTP_CVAL);
+    WRITE_CP32(CNTx_CTL_ENABLE, CNTP_CTL);
+#endif
+    isb();
+
+    /* No need to check for timers in the past; the Generic Timer fires
+     * on a signed 63-bit comparison. */
+    return 1;
+}
+
+/* Handle the firing timer */
+static void timer_interrupt(int irq, void *dev_id, struct cpu_user_regs *regs)
+{
+    if ( irq == 26 && READ_CP32(CNTHP_CTL) & CNTx_CTL_PENDING )
+    {
+        /* Signal the generic timer code to do its work */
+        raise_softirq(TIMER_SOFTIRQ);
+        /* Disable the timer to avoid more interrupts */
+        WRITE_CP32(0, CNTHP_CTL);
+    }
+
+    if (irq == 30 && READ_CP32(CNTP_CTL) & CNTx_CTL_PENDING )
+    {
+        /* Signal the generic timer code to do its work */
+        raise_softirq(TIMER_SOFTIRQ);
+        /* Disable the timer to avoid more interrupts */
+        WRITE_CP32(0, CNTP_CTL);
+    }
+}
+
+/* Set up the timer interrupt on this CPU */
+void __cpuinit init_timer_interrupt(void)
+{
+    /* Sensible defaults */
+    WRITE_CP64(0, CNTVOFF);     /* No VM-specific offset */
+    WRITE_CP32(0, CNTKCTL);     /* No user-mode access */
+#if USE_HYP_TIMER
+    /* Let the VMs read the physical counter and timer so they can tell time */
+    WRITE_CP32(CNTHCTL_PA|CNTHCTL_TA, CNTHCTL);
+#else
+    /* Cannot let VMs access physical counter if we are using it */
+    WRITE_CP32(0, CNTHCTL);
+#endif
+    WRITE_CP32(0, CNTP_CTL);    /* Physical timer disabled */
+    WRITE_CP32(0, CNTHP_CTL);   /* Hypervisor's timer disabled */
+    isb();
+
+    /* XXX Need to find this IRQ number from devicetree? */
+    request_irq(26, timer_interrupt, 0, "hyptimer", NULL);
+    request_irq(30, timer_interrupt, 0, "phytimer", NULL);
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/time.h b/xen/include/asm-arm/time.h
new file mode 100644
index 0000000..8cc9e78
--- /dev/null
+++ b/xen/include/asm-arm/time.h
@@ -0,0 +1,26 @@
+#ifndef __ARM_TIME_H__
+#define __ARM_TIME_H__
+
+typedef unsigned long cycles_t;
+
+static inline cycles_t get_cycles (void)
+{
+        return 0;
+}
+
+struct tm;
+struct tm wallclock_time(void);
+
+
+/* Set up the timer interrupt on this CPU */
+extern void __cpuinit init_timer_interrupt(void);
+
+#endif /* __ARM_TIME_H__ */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 16:29:28 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 16: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.xensource.com>)
	id 1RbEBS-0002FG-Pa; Thu, 15 Dec 2011 16:29:26 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RbEBQ-0002BC-FT
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 16:29:24 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1323966525!56866011!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDY5Mjg=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17221 invoked from network); 15 Dec 2011 16:28:47 -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 2011 16:28:47 -0000
X-IronPort-AV: E=Sophos;i="4.71,357,1320642000"; d="scan'208";a="20001873"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Dec 2011 11:29:22 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Thu, 15 Dec 2011 11:29:22 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pBFGSMti003330;
	Thu, 15 Dec 2011 08:29:05 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Thu, 15 Dec 2011 16:30:52 +0000
Message-ID: <1323966657-19790-20-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1112131831560.3517@kaball-desktop>
References: <alpine.DEB.2.00.1112131831560.3517@kaball-desktop>
MIME-Version: 1.0
Cc: keir.xen@gmail.com, Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, JBeulich@suse.com,
	Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v3 20/25] arm: shutdown, smp and smpboot
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Dummy implementation of machine_* and smp_*

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
---
 xen/arch/arm/shutdown.c |   23 +++++++++++++++++++++
 xen/arch/arm/smp.c      |   29 +++++++++++++++++++++++++++
 xen/arch/arm/smpboot.c  |   50 +++++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 102 insertions(+), 0 deletions(-)
 create mode 100644 xen/arch/arm/shutdown.c
 create mode 100644 xen/arch/arm/smp.c
 create mode 100644 xen/arch/arm/smpboot.c

diff --git a/xen/arch/arm/shutdown.c b/xen/arch/arm/shutdown.c
new file mode 100644
index 0000000..2e35d2d
--- /dev/null
+++ b/xen/arch/arm/shutdown.c
@@ -0,0 +1,23 @@
+#include <xen/config.h>
+#include <xen/lib.h>
+
+void machine_halt(void)
+{
+        /* TODO: halt */
+        while(1) ;
+}
+
+void machine_restart(unsigned int delay_millisecs)
+{
+        /* TODO: restart */
+        printk("Cannot restart yet\n");
+        while(1);
+}
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/arch/arm/smp.c b/xen/arch/arm/smp.c
new file mode 100644
index 0000000..677c71a
--- /dev/null
+++ b/xen/arch/arm/smp.c
@@ -0,0 +1,29 @@
+#include <xen/config.h>
+#include <asm/smp.h>
+
+void smp_call_function(
+    void (*func) (void *info),
+    void *info,
+    int wait)
+{
+	/* TODO: No SMP just now, does not include self so nothing to do.
+	   cpumask_t allbutself = cpu_online_map;
+	   cpu_clear(smp_processor_id(), allbutself);
+	   on_selected_cpus(&allbutself, func, info, wait);
+	*/
+}
+void smp_send_event_check_mask(const cpumask_t *mask)
+{
+    /* TODO: No SMP just now, does not include self so nothing to do.
+	   send_IPI_mask(mask, EVENT_CHECK_VECTOR);
+	*/
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c
new file mode 100644
index 0000000..8287473
--- /dev/null
+++ b/xen/arch/arm/smpboot.c
@@ -0,0 +1,50 @@
+/*
+ * xen/arch/arm/smpboot.c
+ *
+ * Dummy smpboot support
+ *
+ * Copyright (c) 2011 Citrix Systems.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include <xen/cpumask.h>
+#include <xen/smp.h>
+#include <xen/init.h>
+
+cpumask_t cpu_online_map;
+EXPORT_SYMBOL(cpu_online_map);
+cpumask_t cpu_present_map;
+EXPORT_SYMBOL(cpu_online_map);
+cpumask_t cpu_possible_map;
+EXPORT_SYMBOL(cpu_possible_map);
+
+void __init
+smp_prepare_cpus (unsigned int max_cpus)
+{
+        set_processor_id(0); /* needed early, for smp_processor_id() */
+
+        cpumask_clear(&cpu_online_map);
+        cpumask_clear(&cpu_present_map);
+        cpumask_clear(&cpu_possible_map);
+        cpumask_set_cpu(0, &cpu_online_map);
+        cpumask_set_cpu(0, &cpu_present_map);
+        cpumask_set_cpu(0, &cpu_possible_map);
+        return;
+}
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 16:29:28 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 16: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.xensource.com>)
	id 1RbEBS-0002FG-Pa; Thu, 15 Dec 2011 16:29:26 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RbEBQ-0002BC-FT
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 16:29:24 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1323966525!56866011!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDY5Mjg=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17221 invoked from network); 15 Dec 2011 16:28:47 -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 2011 16:28:47 -0000
X-IronPort-AV: E=Sophos;i="4.71,357,1320642000"; d="scan'208";a="20001873"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Dec 2011 11:29:22 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Thu, 15 Dec 2011 11:29:22 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pBFGSMti003330;
	Thu, 15 Dec 2011 08:29:05 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Thu, 15 Dec 2011 16:30:52 +0000
Message-ID: <1323966657-19790-20-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1112131831560.3517@kaball-desktop>
References: <alpine.DEB.2.00.1112131831560.3517@kaball-desktop>
MIME-Version: 1.0
Cc: keir.xen@gmail.com, Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, JBeulich@suse.com,
	Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v3 20/25] arm: shutdown, smp and smpboot
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Dummy implementation of machine_* and smp_*

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
---
 xen/arch/arm/shutdown.c |   23 +++++++++++++++++++++
 xen/arch/arm/smp.c      |   29 +++++++++++++++++++++++++++
 xen/arch/arm/smpboot.c  |   50 +++++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 102 insertions(+), 0 deletions(-)
 create mode 100644 xen/arch/arm/shutdown.c
 create mode 100644 xen/arch/arm/smp.c
 create mode 100644 xen/arch/arm/smpboot.c

diff --git a/xen/arch/arm/shutdown.c b/xen/arch/arm/shutdown.c
new file mode 100644
index 0000000..2e35d2d
--- /dev/null
+++ b/xen/arch/arm/shutdown.c
@@ -0,0 +1,23 @@
+#include <xen/config.h>
+#include <xen/lib.h>
+
+void machine_halt(void)
+{
+        /* TODO: halt */
+        while(1) ;
+}
+
+void machine_restart(unsigned int delay_millisecs)
+{
+        /* TODO: restart */
+        printk("Cannot restart yet\n");
+        while(1);
+}
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/arch/arm/smp.c b/xen/arch/arm/smp.c
new file mode 100644
index 0000000..677c71a
--- /dev/null
+++ b/xen/arch/arm/smp.c
@@ -0,0 +1,29 @@
+#include <xen/config.h>
+#include <asm/smp.h>
+
+void smp_call_function(
+    void (*func) (void *info),
+    void *info,
+    int wait)
+{
+	/* TODO: No SMP just now, does not include self so nothing to do.
+	   cpumask_t allbutself = cpu_online_map;
+	   cpu_clear(smp_processor_id(), allbutself);
+	   on_selected_cpus(&allbutself, func, info, wait);
+	*/
+}
+void smp_send_event_check_mask(const cpumask_t *mask)
+{
+    /* TODO: No SMP just now, does not include self so nothing to do.
+	   send_IPI_mask(mask, EVENT_CHECK_VECTOR);
+	*/
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c
new file mode 100644
index 0000000..8287473
--- /dev/null
+++ b/xen/arch/arm/smpboot.c
@@ -0,0 +1,50 @@
+/*
+ * xen/arch/arm/smpboot.c
+ *
+ * Dummy smpboot support
+ *
+ * Copyright (c) 2011 Citrix Systems.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include <xen/cpumask.h>
+#include <xen/smp.h>
+#include <xen/init.h>
+
+cpumask_t cpu_online_map;
+EXPORT_SYMBOL(cpu_online_map);
+cpumask_t cpu_present_map;
+EXPORT_SYMBOL(cpu_online_map);
+cpumask_t cpu_possible_map;
+EXPORT_SYMBOL(cpu_possible_map);
+
+void __init
+smp_prepare_cpus (unsigned int max_cpus)
+{
+        set_processor_id(0); /* needed early, for smp_processor_id() */
+
+        cpumask_clear(&cpu_online_map);
+        cpumask_clear(&cpu_present_map);
+        cpumask_clear(&cpu_possible_map);
+        cpumask_set_cpu(0, &cpu_online_map);
+        cpumask_set_cpu(0, &cpu_present_map);
+        cpumask_set_cpu(0, &cpu_possible_map);
+        return;
+}
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 16:29:28 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 16: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.xensource.com>)
	id 1RbEBS-0002Eg-BF; Thu, 15 Dec 2011 16:29:26 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RbEBP-0002Ac-TO
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 16:29:24 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1323966525!56866011!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDY5Mjg=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17183 invoked from network); 15 Dec 2011 16:28:47 -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 2011 16:28:47 -0000
X-IronPort-AV: E=Sophos;i="4.71,357,1320642000"; d="scan'208";a="20001872"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Dec 2011 11:29:21 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Thu, 15 Dec 2011 11:29:20 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pBFGSMtj003330;
	Thu, 15 Dec 2011 08:29:07 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Thu, 15 Dec 2011 16:30:53 +0000
Message-ID: <1323966657-19790-21-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1112131831560.3517@kaball-desktop>
References: <alpine.DEB.2.00.1112131831560.3517@kaball-desktop>
MIME-Version: 1.0
Cc: keir.xen@gmail.com, Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, JBeulich@suse.com,
	Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v3 21/25] arm: driver for the generic timer for
	ARMv7
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Driver for the generic timer for ARMv7 with virtualization extensions.
Currently it is based on the kernel timer rather than the hypervisor timer
because the latter does not work correctly on our test environment.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
---
 xen/arch/arm/time.c        |  181 ++++++++++++++++++++++++++++++++++++++++++++
 xen/include/asm-arm/time.h |   26 ++++++
 2 files changed, 207 insertions(+), 0 deletions(-)
 create mode 100644 xen/arch/arm/time.c
 create mode 100644 xen/include/asm-arm/time.h

diff --git a/xen/arch/arm/time.c b/xen/arch/arm/time.c
new file mode 100644
index 0000000..13c1254
--- /dev/null
+++ b/xen/arch/arm/time.c
@@ -0,0 +1,181 @@
+/*
+ * xen/arch/arm/time.c
+ *
+ * Time and timer support, using the ARM Generic Timer interfaces
+ *
+ * Tim Deegan <tim@xen.org>
+ * Copyright (c) 2011 Citrix Systems.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include <xen/config.h>
+#include <xen/console.h>
+#include <xen/init.h>
+#include <xen/irq.h>
+#include <xen/lib.h>
+#include <xen/mm.h>
+#include <xen/softirq.h>
+#include <xen/time.h>
+#include <asm/system.h>
+
+/* Unfortunately the hypervisor timer interrupt appears to be buggy */
+#define USE_HYP_TIMER 0
+
+/* For fine-grained timekeeping, we use the ARM "Generic Timer", a
+ * register-mapped time source in the SoC. */
+static uint32_t __read_mostly cntfrq;      /* Ticks per second */
+static uint64_t __read_mostly boot_count;  /* Counter value at boot time */
+
+/*static inline*/ s_time_t ticks_to_ns(uint64_t ticks)
+{
+    return muldiv64(ticks, SECONDS(1), cntfrq);
+}
+
+/*static inline*/ uint64_t ns_to_ticks(s_time_t ns)
+{
+    return muldiv64(ns, cntfrq, SECONDS(1));
+}
+
+/* TODO: On a real system the firmware would have set the frequency in
+   the CNTFRQ register.  Also we'd need to use devicetree to find
+   the RTC.  When we've seen some real systems, we can delete this.
+static uint32_t calibrate_timer(void)
+{
+    uint32_t sec;
+    uint64_t start, end;
+    paddr_t rtc_base = 0x1C170000ull;
+    volatile uint32_t *rtc;
+
+    ASSERT(!local_irq_is_enabled());
+    set_fixmap(FIXMAP_MISC, rtc_base >> PAGE_SHIFT, DEV_SHARED);
+    rtc = (uint32_t *) FIXMAP_ADDR(FIXMAP_MISC);
+
+    printk("Calibrating timer against RTC...");
+    // Turn on the RTC
+    rtc[3] = 1;
+    // Wait for an edge
+    sec = rtc[0] + 1;
+    do {} while ( rtc[0] != sec );
+    // Now time a few seconds
+    start = READ_CP64(CNTPCT);
+    do {} while ( rtc[0] < sec + 32 );
+    end = READ_CP64(CNTPCT);
+    printk("done.\n");
+
+    clear_fixmap(FIXMAP_MISC);
+    return (end - start) / 32;
+}
+*/
+
+/* Set up the timer on the boot CPU */
+int __init init_xen_time(void)
+{
+    /* Check that this CPU supports the Generic Timer interface */
+    if ( (READ_CP32(ID_PFR1) & ID_PFR1_GT_MASK) != ID_PFR1_GT_v1 )
+        panic("CPU does not support the Generic Timer v1 interface.\n");
+
+    cntfrq = READ_CP32(CNTFRQ);
+    boot_count = READ_CP64(CNTPCT);
+    printk("Using generic timer at %"PRIu32" Hz\n", cntfrq);
+
+    return 0;
+}
+
+/* Return number of nanoseconds since boot */
+s_time_t get_s_time(void)
+{
+    uint64_t ticks = READ_CP64(CNTPCT) - boot_count;
+    return ticks_to_ns(ticks);
+}
+
+/* Set the timer to wake us up at a particular time.
+ * Timeout is a Xen system time (nanoseconds since boot); 0 disables the timer.
+ * Returns 1 on success; 0 if the timeout is too soon or is in the past. */
+int reprogram_timer(s_time_t timeout)
+{
+    uint64_t deadline;
+
+    if ( timeout == 0 )
+    {
+#if USE_HYP_TIMER
+        WRITE_CP32(0, CNTHP_CTL);
+#else
+        WRITE_CP32(0, CNTP_CTL);
+#endif
+        return 1;
+    }
+
+    deadline = ns_to_ticks(timeout) + boot_count;
+#if USE_HYP_TIMER
+    WRITE_CP64(deadline, CNTHP_CVAL);
+    WRITE_CP32(CNTx_CTL_ENABLE, CNTHP_CTL);
+#else
+    WRITE_CP64(deadline, CNTP_CVAL);
+    WRITE_CP32(CNTx_CTL_ENABLE, CNTP_CTL);
+#endif
+    isb();
+
+    /* No need to check for timers in the past; the Generic Timer fires
+     * on a signed 63-bit comparison. */
+    return 1;
+}
+
+/* Handle the firing timer */
+static void timer_interrupt(int irq, void *dev_id, struct cpu_user_regs *regs)
+{
+    if ( irq == 26 && READ_CP32(CNTHP_CTL) & CNTx_CTL_PENDING )
+    {
+        /* Signal the generic timer code to do its work */
+        raise_softirq(TIMER_SOFTIRQ);
+        /* Disable the timer to avoid more interrupts */
+        WRITE_CP32(0, CNTHP_CTL);
+    }
+
+    if (irq == 30 && READ_CP32(CNTP_CTL) & CNTx_CTL_PENDING )
+    {
+        /* Signal the generic timer code to do its work */
+        raise_softirq(TIMER_SOFTIRQ);
+        /* Disable the timer to avoid more interrupts */
+        WRITE_CP32(0, CNTP_CTL);
+    }
+}
+
+/* Set up the timer interrupt on this CPU */
+void __cpuinit init_timer_interrupt(void)
+{
+    /* Sensible defaults */
+    WRITE_CP64(0, CNTVOFF);     /* No VM-specific offset */
+    WRITE_CP32(0, CNTKCTL);     /* No user-mode access */
+#if USE_HYP_TIMER
+    /* Let the VMs read the physical counter and timer so they can tell time */
+    WRITE_CP32(CNTHCTL_PA|CNTHCTL_TA, CNTHCTL);
+#else
+    /* Cannot let VMs access physical counter if we are using it */
+    WRITE_CP32(0, CNTHCTL);
+#endif
+    WRITE_CP32(0, CNTP_CTL);    /* Physical timer disabled */
+    WRITE_CP32(0, CNTHP_CTL);   /* Hypervisor's timer disabled */
+    isb();
+
+    /* XXX Need to find this IRQ number from devicetree? */
+    request_irq(26, timer_interrupt, 0, "hyptimer", NULL);
+    request_irq(30, timer_interrupt, 0, "phytimer", NULL);
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/time.h b/xen/include/asm-arm/time.h
new file mode 100644
index 0000000..8cc9e78
--- /dev/null
+++ b/xen/include/asm-arm/time.h
@@ -0,0 +1,26 @@
+#ifndef __ARM_TIME_H__
+#define __ARM_TIME_H__
+
+typedef unsigned long cycles_t;
+
+static inline cycles_t get_cycles (void)
+{
+        return 0;
+}
+
+struct tm;
+struct tm wallclock_time(void);
+
+
+/* Set up the timer interrupt on this CPU */
+extern void __cpuinit init_timer_interrupt(void);
+
+#endif /* __ARM_TIME_H__ */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 16:29:28 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 16: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.xensource.com>)
	id 1RbEBQ-0002Bw-PS; Thu, 15 Dec 2011 16:29:24 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RbEBO-00029P-JI
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 16:29:23 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1323966500!60916191!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDY5Mjg=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17698 invoked from network); 15 Dec 2011 16:28:25 -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;
	15 Dec 2011 16:28:25 -0000
X-IronPort-AV: E=Sophos;i="4.71,357,1320642000"; d="scan'208";a="20001870"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Dec 2011 11:29:17 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Thu, 15 Dec 2011 11:29:16 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pBFGSMtf003330;
	Thu, 15 Dec 2011 08:28:59 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Thu, 15 Dec 2011 16:30:49 +0000
Message-ID: <1323966657-19790-17-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1112131831560.3517@kaball-desktop>
References: <alpine.DEB.2.00.1112131831560.3517@kaball-desktop>
MIME-Version: 1.0
Cc: keir.xen@gmail.com, Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, JBeulich@suse.com,
	Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v3 17/25] arm: mm and p2m
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Functions to setup pagetables, handle the p2m, map and unmap domain
pages, copy data to/from guest addresses.
The implementation is based on the LPAE extension for ARMv7 and makes
use of the two level transtion mechanism.


Changes in v3:

- rename copy_to_user and copy_from_user to raw_copy_to_guest and
raw_copy_from_guest.


Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
---
 xen/arch/arm/domain.c              |    4 +
 xen/arch/arm/guestcopy.c           |   81 +++++++++
 xen/arch/arm/mm.c                  |  321 ++++++++++++++++++++++++++++++++++
 xen/arch/arm/p2m.c                 |  214 +++++++++++++++++++++++
 xen/include/asm-arm/domain.h       |    2 +
 xen/include/asm-arm/guest_access.h |  131 ++++++++++++++
 xen/include/asm-arm/mm.h           |  315 +++++++++++++++++++++++++++++++++
 xen/include/asm-arm/p2m.h          |   88 ++++++++++
 xen/include/asm-arm/page.h         |  335 ++++++++++++++++++++++++++++++++++++
 9 files changed, 1491 insertions(+), 0 deletions(-)
 create mode 100644 xen/arch/arm/guestcopy.c
 create mode 100644 xen/arch/arm/mm.c
 create mode 100644 xen/arch/arm/p2m.c
 create mode 100644 xen/include/asm-arm/guest_access.h
 create mode 100644 xen/include/asm-arm/mm.h
 create mode 100644 xen/include/asm-arm/p2m.h
 create mode 100644 xen/include/asm-arm/page.h

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index ecbc5b7..0844b37 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -224,6 +224,10 @@ int arch_domain_create(struct domain *d, unsigned int domcr_flags)
 {
     int rc;
 
+    rc = -ENOMEM;
+    if ( (rc = p2m_init(d)) != 0 )
+        goto fail;
+
     d->max_vcpus = 8;
 
     rc = 0;
diff --git a/xen/arch/arm/guestcopy.c b/xen/arch/arm/guestcopy.c
new file mode 100644
index 0000000..d9eb7ac
--- /dev/null
+++ b/xen/arch/arm/guestcopy.c
@@ -0,0 +1,81 @@
+#include <xen/config.h>
+#include <xen/lib.h>
+#include <xen/domain_page.h>
+
+#include <asm/mm.h>
+#include <asm/guest_access.h>
+
+unsigned long raw_copy_to_guest(void *to, const void *from, unsigned len)
+{
+    /* XXX needs to handle faults */
+    unsigned offset = ((unsigned long)to & ~PAGE_MASK);
+
+    while ( len )
+    {
+        paddr_t g = gvirt_to_maddr((uint32_t) to);
+        void *p = map_domain_page(g>>PAGE_SHIFT);
+        unsigned size = min(len, (unsigned)PAGE_SIZE - offset);
+
+        p += offset;
+        memcpy(p, from, size);
+
+        unmap_domain_page(p - offset);
+        len -= size;
+        from += size;
+        to += size;
+        offset = 0;
+    }
+
+    return 0;
+}
+
+unsigned long raw_clear_guest(void *to, unsigned len)
+{
+    /* XXX needs to handle faults */
+    unsigned offset = ((unsigned long)to & ~PAGE_MASK);
+
+    while ( len )
+    {
+        paddr_t g = gvirt_to_maddr((uint32_t) to);
+        void *p = map_domain_page(g>>PAGE_SHIFT);
+        unsigned size = min(len, (unsigned)PAGE_SIZE - offset);
+
+        p += offset;
+        memset(p, 0x00, size);
+
+        unmap_domain_page(p - offset);
+        len -= size;
+        to += size;
+        offset = 0;
+    }
+
+    return 0;
+}
+
+unsigned long raw_copy_from_guest(void *to, const void __user *from, unsigned len)
+{
+    while ( len )
+    {
+        paddr_t g = gvirt_to_maddr((uint32_t) from & PAGE_MASK);
+        void *p = map_domain_page(g>>PAGE_SHIFT);
+        unsigned size = min(len, (unsigned)(PAGE_SIZE - ((unsigned)from & (~PAGE_MASK))));
+
+        p += ((unsigned long)from & (~PAGE_MASK));
+
+        memcpy(to, p, size);
+
+        unmap_domain_page(p);
+        len -= size;
+        from += size;
+        to += size;
+    }
+    return 0;
+}
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
new file mode 100644
index 0000000..613d084
--- /dev/null
+++ b/xen/arch/arm/mm.c
@@ -0,0 +1,321 @@
+/*
+ * xen/arch/arm/mm.c
+ *
+ * MMU code for an ARMv7-A with virt extensions.
+ *
+ * Tim Deegan <tim@xen.org>
+ * Copyright (c) 2011 Citrix Systems.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include <xen/config.h>
+#include <xen/compile.h>
+#include <xen/types.h>
+#include <xen/init.h>
+#include <xen/mm.h>
+#include <xen/preempt.h>
+#include <asm/page.h>
+#include <asm/current.h>
+
+struct domain *dom_xen, *dom_io;
+
+/* Static start-of-day pagetables that we use before the allocators are up */
+lpae_t xen_pgtable[LPAE_ENTRIES] __attribute__((__aligned__(4096)));
+lpae_t xen_second[LPAE_ENTRIES*4] __attribute__((__aligned__(4096*4)));
+static lpae_t xen_fixmap[LPAE_ENTRIES] __attribute__((__aligned__(4096)));
+static lpae_t xen_xenmap[LPAE_ENTRIES] __attribute__((__aligned__(4096)));
+
+/* Limits of the Xen heap */
+unsigned long xenheap_mfn_start, xenheap_mfn_end;
+unsigned long xenheap_virt_end;
+
+unsigned long frametable_virt_end;
+
+/* Map a 4k page in a fixmap entry */
+void set_fixmap(unsigned map, unsigned long mfn, unsigned attributes)
+{
+    lpae_t pte = mfn_to_xen_entry(mfn);
+    pte.pt.table = 1; /* 4k mappings always have this bit set */
+    pte.pt.ai = attributes;
+    write_pte(xen_fixmap + third_table_offset(FIXMAP_ADDR(map)), pte);
+    flush_xen_data_tlb_va(FIXMAP_ADDR(map));
+}
+
+/* Remove a mapping from a fixmap entry */
+void clear_fixmap(unsigned map)
+{
+    lpae_t pte = {0};
+    write_pte(xen_fixmap + third_table_offset(FIXMAP_ADDR(map)), pte);
+    flush_xen_data_tlb_va(FIXMAP_ADDR(map));
+}
+
+/* Map a page of domheap memory */
+void *map_domain_page(unsigned long mfn)
+{
+    unsigned long flags;
+    lpae_t *map = xen_second + second_linear_offset(DOMHEAP_VIRT_START);
+    unsigned long slot_mfn = mfn & ~LPAE_ENTRY_MASK;
+    uint32_t va;
+    lpae_t pte;
+    int i, slot;
+
+    local_irq_save(flags);
+
+    /* The map is laid out as an open-addressed hash table where each
+     * entry is a 2MB superpage pte.  We use the available bits of each
+     * PTE as a reference count; when the refcount is zero the slot can
+     * be reused. */
+    for ( slot = (slot_mfn >> LPAE_SHIFT) % DOMHEAP_ENTRIES, i = 0;
+          i < DOMHEAP_ENTRIES;
+          slot = (slot + 1) % DOMHEAP_ENTRIES, i++ )
+    {
+        if ( map[slot].pt.avail == 0 )
+        {
+            /* Commandeer this 2MB slot */
+            pte = mfn_to_xen_entry(slot_mfn);
+            pte.pt.avail = 1;
+            write_pte(map + slot, pte);
+            break;
+        }
+        else if ( map[slot].pt.avail < 0xf && map[slot].pt.base == slot_mfn )
+        {
+            /* This slot already points to the right place; reuse it */
+            map[slot].pt.avail++;
+            break;
+        }
+    }
+    /* If the map fills up, the callers have misbehaved. */
+    BUG_ON(i == DOMHEAP_ENTRIES);
+
+#ifndef NDEBUG
+    /* Searching the hash could get slow if the map starts filling up.
+     * Cross that bridge when we come to it */
+    {
+        static int max_tries = 32;
+        if ( i >= max_tries )
+        {
+            dprintk(XENLOG_WARNING, "Domheap map is filling: %i tries\n", i);
+            max_tries *= 2;
+        }
+    }
+#endif
+
+    local_irq_restore(flags);
+
+    va = (DOMHEAP_VIRT_START
+          + (slot << SECOND_SHIFT)
+          + ((mfn & LPAE_ENTRY_MASK) << THIRD_SHIFT));
+
+    /*
+     * We may not have flushed this specific subpage at map time,
+     * since we only flush the 4k page not the superpage
+     */
+    flush_xen_data_tlb_va(va);
+
+    return (void *)va;
+}
+
+/* Release a mapping taken with map_domain_page() */
+void unmap_domain_page(const void *va)
+{
+    unsigned long flags;
+    lpae_t *map = xen_second + second_linear_offset(DOMHEAP_VIRT_START);
+    int slot = ((unsigned long) va - DOMHEAP_VIRT_START) >> SECOND_SHIFT;
+
+    local_irq_save(flags);
+
+    ASSERT(slot >= 0 && slot < DOMHEAP_ENTRIES);
+    ASSERT(map[slot].pt.avail != 0);
+
+    map[slot].pt.avail--;
+
+    local_irq_restore(flags);
+}
+
+
+/* Boot-time pagetable setup.
+ * Changes here may need matching changes in head.S */
+void __init setup_pagetables(unsigned long boot_phys_offset)
+{
+    paddr_t xen_paddr, phys_offset;
+    unsigned long dest_va;
+    lpae_t pte, *p;
+    int i;
+
+    if ( boot_phys_offset != 0 )
+    {
+        /* Remove the old identity mapping of the boot paddr */
+        pte.bits = 0;
+        dest_va = (unsigned long)_start + boot_phys_offset;
+        write_pte(xen_second + second_linear_offset(dest_va), pte);
+    }
+
+    xen_paddr = XEN_PADDR;
+
+    /* Map the destination in the empty L2 above the fixmap */
+    dest_va = FIXMAP_ADDR(0) + (1u << SECOND_SHIFT);
+    pte = mfn_to_xen_entry(xen_paddr >> PAGE_SHIFT);
+    write_pte(xen_second + second_table_offset(dest_va), pte);
+
+    /* Calculate virt-to-phys offset for the new location */
+    phys_offset = xen_paddr - (unsigned long) _start;
+
+    /* Copy */
+    memcpy((void *) dest_va, _start, _end - _start);
+
+    /* Beware!  Any state we modify between now and the PT switch may be
+     * discarded when we switch over to the copy. */
+
+    /* Update the copy of xen_pgtable to use the new paddrs */
+    p = (void *) xen_pgtable + dest_va - (unsigned long) _start;
+    for ( i = 0; i < 4; i++)
+        p[i].pt.base += (phys_offset - boot_phys_offset) >> PAGE_SHIFT;
+    p = (void *) xen_second + dest_va - (unsigned long) _start;
+    for ( i = 0; i < 4 * LPAE_ENTRIES; i++)
+        if ( p[i].pt.valid )
+                p[i].pt.base += (phys_offset - boot_phys_offset) >> PAGE_SHIFT;
+
+    /* Change pagetables to the copy in the relocated Xen */
+    asm volatile (
+        STORE_CP64(0, HTTBR)          /* Change translation base */
+        "dsb;"                        /* Ensure visibility of HTTBR update */
+        STORE_CP32(0, TLBIALLH)       /* Flush hypervisor TLB */
+        STORE_CP32(0, BPIALL)         /* Flush branch predictor */
+        "dsb;"                        /* Ensure completion of TLB+BP flush */
+        "isb;"
+        : : "r" ((unsigned long) xen_pgtable + phys_offset) : "memory");
+
+    /* Undo the temporary map */
+    pte.bits = 0;
+    write_pte(xen_second + second_table_offset(dest_va), pte);
+    /*
+     * Have removed a mapping previously used for .text. Flush everything
+     * for safety.
+     */
+    asm volatile (
+        "dsb;"                        /* Ensure visibility of PTE write */
+        STORE_CP32(0, TLBIALLH)       /* Flush hypervisor TLB */
+        STORE_CP32(0, BPIALL)         /* Flush branch predictor */
+        "dsb;"                        /* Ensure completion of TLB+BP flush */
+        "isb;"
+        : : "r" (i /*dummy*/) : "memory");
+
+    /* Link in the fixmap pagetable */
+    pte = mfn_to_xen_entry((((unsigned long) xen_fixmap) + phys_offset)
+                           >> PAGE_SHIFT);
+    pte.pt.table = 1;
+    write_pte(xen_second + second_table_offset(FIXMAP_ADDR(0)), pte);
+    /*
+     * No flush required here. Individual flushes are done in
+     * set_fixmap as entries are used.
+     */
+
+    /* Break up the Xen mapping into 4k pages and protect them separately. */
+    for ( i = 0; i < LPAE_ENTRIES; i++ )
+    {
+        unsigned long mfn = paddr_to_pfn(xen_paddr) + i;
+        unsigned long va = XEN_VIRT_START + (i << PAGE_SHIFT);
+        if ( !is_kernel(va) )
+            break;
+        pte = mfn_to_xen_entry(mfn);
+        pte.pt.table = 1; /* 4k mappings always have this bit set */
+        if ( is_kernel_text(va) || is_kernel_inittext(va) )
+        {
+            pte.pt.xn = 0;
+            pte.pt.ro = 1;
+        }
+        if ( is_kernel_rodata(va) )
+            pte.pt.ro = 1;
+        write_pte(xen_xenmap + i, pte);
+        /* No flush required here as page table is not hooked in yet. */
+    }
+    pte = mfn_to_xen_entry((((unsigned long) xen_xenmap) + phys_offset)
+                           >> PAGE_SHIFT);
+    pte.pt.table = 1;
+    write_pte(xen_second + second_linear_offset(XEN_VIRT_START), pte);
+    /* Have changed a mapping used for .text. Flush everything for safety. */
+    asm volatile (
+        "dsb;"                        /* Ensure visibility of PTE write */
+        STORE_CP32(0, TLBIALLH)       /* Flush hypervisor TLB */
+        STORE_CP32(0, BPIALL)         /* Flush branch predictor */
+        "dsb;"                        /* Ensure completion of TLB+BP flush */
+        "isb;"
+        : : "r" (i /*dummy*/) : "memory");
+
+    /* From now on, no mapping may be both writable and executable. */
+    WRITE_CP32(READ_CP32(HSCTLR) | SCTLR_WXN, HSCTLR);
+}
+
+/* Create Xen's mappings of memory.
+ * Base and virt must be 32MB aligned and size a multiple of 32MB. */
+static void __init create_mappings(unsigned long virt,
+                                   unsigned long base_mfn,
+                                   unsigned long nr_mfns)
+{
+    unsigned long i, count;
+    lpae_t pte, *p;
+
+    ASSERT(!((virt >> PAGE_SHIFT) % (16 * LPAE_ENTRIES)));
+    ASSERT(!(base_mfn % (16 * LPAE_ENTRIES)));
+    ASSERT(!(nr_mfns % (16 * LPAE_ENTRIES)));
+
+    count = nr_mfns / LPAE_ENTRIES;
+    p = xen_second + second_linear_offset(virt);
+    pte = mfn_to_xen_entry(base_mfn);
+    pte.pt.hint = 1;  /* These maps are in 16-entry contiguous chunks. */
+    for ( i = 0; i < count; i++ )
+    {
+        write_pte(p + i, pte);
+        pte.pt.base += 1 << LPAE_SHIFT;
+    }
+    flush_xen_data_tlb();
+}
+
+/* Set up the xenheap: up to 1GB of contiguous, always-mapped memory. */
+void __init setup_xenheap_mappings(unsigned long base_mfn,
+                                   unsigned long nr_mfns)
+{
+    create_mappings(XENHEAP_VIRT_START, base_mfn, nr_mfns);
+
+    /* Record where the xenheap is, for translation routines. */
+    xenheap_virt_end = XENHEAP_VIRT_START + nr_mfns * PAGE_SIZE;
+    xenheap_mfn_start = base_mfn;
+    xenheap_mfn_end = base_mfn + nr_mfns;
+}
+
+/* Map a frame table to cover physical addresses ps through pe */
+void __init setup_frametable_mappings(paddr_t ps, paddr_t pe)
+{
+    unsigned long nr_pages = (pe - ps) >> PAGE_SHIFT;
+    unsigned long frametable_size = nr_pages * sizeof(struct page_info);
+    unsigned long base_mfn;
+
+    /* Round up to 32M boundary */
+    frametable_size = (frametable_size + 0x1ffffff) & ~0x1ffffff;
+    base_mfn = alloc_boot_pages(frametable_size >> PAGE_SHIFT, 5);
+    create_mappings(FRAMETABLE_VIRT_START, base_mfn, frametable_size >> PAGE_SHIFT);
+
+    memset(&frame_table[0], 0, nr_pages * sizeof(struct page_info));
+    memset(&frame_table[nr_pages], -1,
+           frametable_size - (nr_pages * sizeof(struct page_info)));
+
+    frametable_virt_end = FRAMETABLE_VIRT_START + (nr_pages * sizeof(struct page_info));
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
new file mode 100644
index 0000000..a1d026d
--- /dev/null
+++ b/xen/arch/arm/p2m.c
@@ -0,0 +1,214 @@
+#include <xen/config.h>
+#include <xen/sched.h>
+#include <xen/lib.h>
+#include <xen/errno.h>
+#include <xen/domain_page.h>
+
+void p2m_load_VTTBR(struct domain *d)
+{
+    struct p2m_domain *p2m = &d->arch.p2m;
+    paddr_t maddr = page_to_maddr(p2m->first_level);
+    uint64_t vttbr = maddr;
+
+    vttbr |= ((uint64_t)p2m->vmid&0xff)<<48;
+
+    printk("VTTBR dom%d = %"PRIx64"\n", d->domain_id, vttbr);
+
+    WRITE_CP64(vttbr, VTTBR);
+    isb(); /* Ensure update is visible */
+}
+
+static int p2m_create_entry(struct domain *d,
+                            lpae_t *entry)
+{
+    struct p2m_domain *p2m = &d->arch.p2m;
+    struct page_info *page;
+    void *p;
+    lpae_t pte;
+
+    BUG_ON(entry->p2m.valid);
+
+    page = alloc_domheap_page(d, 0);
+    if ( page == NULL )
+        return -ENOMEM;
+
+    page_list_add(page, &p2m->pages);
+
+    p = __map_domain_page(page);
+    clear_page(p);
+    unmap_domain_page(p);
+
+    pte = mfn_to_p2m_entry(page_to_mfn(page));
+
+    write_pte(entry, pte);
+
+    return 0;
+}
+
+static int create_p2m_entries(struct domain *d,
+                     int alloc,
+                     paddr_t start_gpaddr,
+                     paddr_t end_gpaddr,
+                     paddr_t maddr)
+{
+    int rc;
+    struct p2m_domain *p2m = &d->arch.p2m;
+    lpae_t *first = NULL, *second = NULL, *third = NULL;
+    paddr_t addr;
+    unsigned long cur_first_offset = ~0, cur_second_offset = ~0;
+
+    /* XXX Don't actually handle 40 bit guest physical addresses */
+    BUG_ON(start_gpaddr & 0x8000000000ULL);
+    BUG_ON(end_gpaddr   & 0x8000000000ULL);
+
+    first = __map_domain_page(p2m->first_level);
+
+    for(addr = start_gpaddr; addr < end_gpaddr; addr += PAGE_SIZE)
+    {
+        if ( !first[first_table_offset(addr)].p2m.valid )
+        {
+            rc = p2m_create_entry(d, &first[first_table_offset(addr)]);
+            if ( rc < 0 ) {
+                printk("p2m_populate_ram: L1 failed\n");
+                goto out;
+            }
+        }
+
+        BUG_ON(!first[first_table_offset(addr)].p2m.valid);
+
+        if ( cur_first_offset != first_table_offset(addr) )
+        {
+            if (second) unmap_domain_page(second);
+            second = map_domain_page(first[first_table_offset(addr)].p2m.base);
+            cur_first_offset = first_table_offset(addr);
+        }
+        /* else: second already valid */
+
+        if ( !second[second_table_offset(addr)].p2m.valid )
+        {
+            rc = p2m_create_entry(d, &second[second_table_offset(addr)]);
+            if ( rc < 0 ) {
+                printk("p2m_populate_ram: L2 failed\n");
+                goto out;
+            }
+        }
+
+        BUG_ON(!second[second_table_offset(addr)].p2m.valid);
+
+        if ( cur_second_offset != second_table_offset(addr) )
+        {
+            /* map third level */
+            if (third) unmap_domain_page(third);
+            third = map_domain_page(second[second_table_offset(addr)].p2m.base);
+            cur_second_offset = second_table_offset(addr);
+        }
+        /* else: third already valid */
+
+        BUG_ON(third[third_table_offset(addr)].p2m.valid);
+
+        /* Allocate a new RAM page and attach */
+        if (alloc)
+        {
+            struct page_info *page;
+            lpae_t pte;
+
+            rc = -ENOMEM;
+            page = alloc_domheap_page(d, 0);
+            if ( page == NULL ) {
+                printk("p2m_populate_ram: failed to allocate page\n");
+                goto out;
+            }
+
+            pte = mfn_to_p2m_entry(page_to_mfn(page));
+
+            write_pte(&third[third_table_offset(addr)], pte);
+        } else {
+            lpae_t pte = mfn_to_p2m_entry(maddr >> PAGE_SHIFT);
+            write_pte(&third[third_table_offset(addr)], pte);
+            maddr += PAGE_SIZE;
+        }
+    }
+
+    rc = 0;
+
+out:
+    spin_lock(&p2m->lock);
+
+    if (third) unmap_domain_page(third);
+    if (second) unmap_domain_page(second);
+    if (first) unmap_domain_page(first);
+
+    spin_unlock(&p2m->lock);
+
+    return rc;
+}
+
+int p2m_populate_ram(struct domain *d,
+                     paddr_t start,
+                     paddr_t end)
+{
+    return create_p2m_entries(d, 1, start, end, 0);
+}
+
+int map_mmio_regions(struct domain *d,
+                     paddr_t start_gaddr,
+                     paddr_t end_gaddr,
+                     paddr_t maddr)
+{
+    return create_p2m_entries(d, 0, start_gaddr, end_gaddr, maddr);
+}
+
+int p2m_alloc_table(struct domain *d)
+{
+    struct p2m_domain *p2m = &d->arch.p2m;
+    struct page_info *page;
+    void *p;
+
+    /* First level P2M is 2 consecutive pages */
+    page = alloc_domheap_pages(d, 1, 0);
+    if ( page == NULL )
+        return -ENOMEM;
+
+    spin_lock(&p2m->lock);
+
+    page_list_add(page, &p2m->pages);
+
+    /* Clear both first level pages */
+    p = __map_domain_page(page);
+    clear_page(p);
+    unmap_domain_page(p);
+
+    p = __map_domain_page(page + 1);
+    clear_page(p);
+    unmap_domain_page(p);
+
+    p2m->first_level = page;
+
+    spin_unlock(&p2m->lock);
+
+    return 0;
+}
+
+int p2m_init(struct domain *d)
+{
+    struct p2m_domain *p2m = &d->arch.p2m;
+
+    spin_lock_init(&p2m->lock);
+    INIT_PAGE_LIST_HEAD(&p2m->pages);
+
+    /* XXX allocate properly */
+    /* Zero is reserved */
+    p2m->vmid = d->domain_id + 1;
+
+    p2m->first_level = NULL;
+
+    return 0;
+}
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
index c226bdf..2226a24 100644
--- a/xen/include/asm-arm/domain.h
+++ b/xen/include/asm-arm/domain.h
@@ -16,6 +16,8 @@ struct pending_irq
 
 struct arch_domain
 {
+    struct p2m_domain p2m;
+
 }  __cacheline_aligned;
 
 struct arch_vcpu
diff --git a/xen/include/asm-arm/guest_access.h b/xen/include/asm-arm/guest_access.h
new file mode 100644
index 0000000..0fceae6
--- /dev/null
+++ b/xen/include/asm-arm/guest_access.h
@@ -0,0 +1,131 @@
+#ifndef __ASM_ARM_GUEST_ACCESS_H__
+#define __ASM_ARM_GUEST_ACCESS_H__
+
+#include <xen/guest_access.h>
+#include <xen/errno.h>
+
+/* Guests have their own comlete address space */
+#define access_ok(addr,size) (1)
+
+#define array_access_ok(addr,count,size) \
+    (likely(count < (~0UL/size)) && access_ok(addr,count*size))
+
+unsigned long raw_copy_to_guest(void *to, const void *from, unsigned len);
+unsigned long raw_copy_from_guest(void *to, const void *from, unsigned len);
+unsigned long raw_clear_guest(void *to, unsigned len);
+
+#define __raw_copy_to_guest raw_copy_to_guest
+#define __raw_copy_from_guest raw_copy_from_guest
+#define __raw_clear_guest raw_clear_guest
+
+/* Remainder copied from x86 -- could be common? */
+
+/* Is the guest handle a NULL reference? */
+#define guest_handle_is_null(hnd)        ((hnd).p == NULL)
+
+/* Offset the given guest handle into the array it refers to. */
+#define guest_handle_add_offset(hnd, nr) ((hnd).p += (nr))
+#define guest_handle_subtract_offset(hnd, nr) ((hnd).p -= (nr))
+
+/* Cast a guest handle to the specified type of handle. */
+#define guest_handle_cast(hnd, type) ({         \
+    type *_x = (hnd).p;                         \
+    (XEN_GUEST_HANDLE(type)) { _x };            \
+})
+
+#define guest_handle_from_ptr(ptr, type)        \
+    ((XEN_GUEST_HANDLE(type)) { (type *)ptr })
+#define const_guest_handle_from_ptr(ptr, type)  \
+    ((XEN_GUEST_HANDLE(const_##type)) { (const type *)ptr })
+
+/*
+ * Copy an array of objects to guest context via a guest handle,
+ * specifying an offset into the guest array.
+ */
+#define copy_to_guest_offset(hnd, off, ptr, nr) ({      \
+    const typeof(*(ptr)) *_s = (ptr);                   \
+    char (*_d)[sizeof(*_s)] = (void *)(hnd).p;          \
+    ((void)((hnd).p == (ptr)));                         \
+    raw_copy_to_guest(_d+(off), _s, sizeof(*_s)*(nr));  \
+})
+
+/*
+ * Clear an array of objects in guest context via a guest handle,
+ * specifying an offset into the guest array.
+ */
+#define clear_guest_offset(hnd, off, ptr, nr) ({      \
+    raw_clear_guest(_d+(off), nr);  \
+})
+
+/*
+ * Copy an array of objects from guest context via a guest handle,
+ * specifying an offset into the guest array.
+ */
+#define copy_from_guest_offset(ptr, hnd, off, nr) ({    \
+    const typeof(*(ptr)) *_s = (hnd).p;                 \
+    typeof(*(ptr)) *_d = (ptr);                         \
+    raw_copy_from_guest(_d, _s+(off), sizeof(*_d)*(nr));\
+})
+
+/* Copy sub-field of a structure to guest context via a guest handle. */
+#define copy_field_to_guest(hnd, ptr, field) ({         \
+    const typeof(&(ptr)->field) _s = &(ptr)->field;     \
+    void *_d = &(hnd).p->field;                         \
+    ((void)(&(hnd).p->field == &(ptr)->field));         \
+    raw_copy_to_guest(_d, _s, sizeof(*_s));             \
+})
+
+/* Copy sub-field of a structure from guest context via a guest handle. */
+#define copy_field_from_guest(ptr, hnd, field) ({       \
+    const typeof(&(ptr)->field) _s = &(hnd).p->field;   \
+    typeof(&(ptr)->field) _d = &(ptr)->field;           \
+    raw_copy_from_guest(_d, _s, sizeof(*_d));           \
+})
+
+/*
+ * Pre-validate a guest handle.
+ * Allows use of faster __copy_* functions.
+ */
+/* All ARM guests are paging mode external and hence safe */
+#define guest_handle_okay(hnd, nr) (1)
+#define guest_handle_subrange_okay(hnd, first, last) (1)
+
+#define __copy_to_guest_offset(hnd, off, ptr, nr) ({    \
+    const typeof(*(ptr)) *_s = (ptr);                   \
+    char (*_d)[sizeof(*_s)] = (void *)(hnd).p;          \
+    ((void)((hnd).p == (ptr)));                         \
+    __raw_copy_to_guest(_d+(off), _s, sizeof(*_s)*(nr));\
+})
+
+#define __clear_guest_offset(hnd, off, ptr, nr) ({      \
+    __raw_clear_guest(_d+(off), nr);  \
+})
+
+#define __copy_from_guest_offset(ptr, hnd, off, nr) ({  \
+    const typeof(*(ptr)) *_s = (hnd).p;                 \
+    typeof(*(ptr)) *_d = (ptr);                         \
+    __raw_copy_from_guest(_d, _s+(off), sizeof(*_d)*(nr));\
+})
+
+#define __copy_field_to_guest(hnd, ptr, field) ({       \
+    const typeof(&(ptr)->field) _s = &(ptr)->field;     \
+    void *_d = &(hnd).p->field;                         \
+    ((void)(&(hnd).p->field == &(ptr)->field));         \
+    __raw_copy_to_guest(_d, _s, sizeof(*_s));           \
+})
+
+#define __copy_field_from_guest(ptr, hnd, field) ({     \
+    const typeof(&(ptr)->field) _s = &(hnd).p->field;   \
+    typeof(&(ptr)->field) _d = &(ptr)->field;           \
+    __raw_copy_from_guest(_d, _s, sizeof(*_d));         \
+})
+
+#endif /* __ASM_ARM_GUEST_ACCESS_H__ */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/mm.h b/xen/include/asm-arm/mm.h
new file mode 100644
index 0000000..ead6e0c
--- /dev/null
+++ b/xen/include/asm-arm/mm.h
@@ -0,0 +1,315 @@
+#ifndef __ARCH_ARM_MM__
+#define __ARCH_ARM_MM__
+
+#include <xen/config.h>
+#include <xen/kernel.h>
+#include <asm/page.h>
+#include <public/xen.h>
+
+/* Find a suitable place at the top of memory for Xen to live */
+/* XXX For now, use the top of the VE's 4GB RAM, at a 40-bit alias */
+#define XEN_PADDR 0x80ffe00000ull
+
+/*
+ * Per-page-frame information.
+ *
+ * Every architecture must ensure the following:
+ *  1. 'struct page_info' contains a 'struct page_list_entry list'.
+ *  2. Provide a PFN_ORDER() macro for accessing the order of a free page.
+ */
+#define PFN_ORDER(_pfn) ((_pfn)->v.free.order)
+
+struct page_info
+{
+    /* Each frame can be threaded onto a doubly-linked list. */
+    struct page_list_entry list;
+
+    /* Reference count and various PGC_xxx flags and fields. */
+    unsigned long count_info;
+
+    /* Context-dependent fields follow... */
+    union {
+        /* Page is in use: ((count_info & PGC_count_mask) != 0). */
+        struct {
+            /* Type reference count and various PGT_xxx flags and fields. */
+            unsigned long type_info;
+        } inuse;
+        /* Page is on a free list: ((count_info & PGC_count_mask) == 0). */
+        struct {
+            /* Do TLBs need flushing for safety before next page use? */
+            bool_t need_tlbflush;
+        } free;
+
+    } u;
+
+    union {
+        /* Page is in use, but not as a shadow. */
+        struct {
+            /* Owner of this page (zero if page is anonymous). */
+            struct domain *domain;
+        } inuse;
+
+        /* Page is on a free list. */
+        struct {
+            /* Order-size of the free chunk this page is the head of. */
+            unsigned int order;
+        } free;
+
+    } v;
+
+    union {
+        /*
+         * Timestamp from 'TLB clock', used to avoid extra safety flushes.
+         * Only valid for: a) free pages, and b) pages with zero type count
+         */
+        u32 tlbflush_timestamp;
+    };
+    u64 pad;
+};
+
+#define PG_shift(idx)   (BITS_PER_LONG - (idx))
+#define PG_mask(x, idx) (x ## UL << PG_shift(idx))
+
+#define PGT_none          PG_mask(0, 4)  /* no special uses of this page   */
+#define PGT_writable_page PG_mask(7, 4)  /* has writable mappings?         */
+#define PGT_shared_page   PG_mask(8, 4)  /* CoW sharable page              */
+#define PGT_type_mask     PG_mask(15, 4) /* Bits 28-31 or 60-63.           */
+
+ /* Owning guest has pinned this page to its current type? */
+#define _PGT_pinned       PG_shift(5)
+#define PGT_pinned        PG_mask(1, 5)
+
+ /* Count of uses of this frame as its current type. */
+#define PGT_count_width   PG_shift(9)
+#define PGT_count_mask    ((1UL<<PGT_count_width)-1)
+
+ /* Cleared when the owning guest 'frees' this page. */
+#define _PGC_allocated    PG_shift(1)
+#define PGC_allocated     PG_mask(1, 1)
+  /* Page is Xen heap? */
+#define _PGC_xen_heap     PG_shift(2)
+#define PGC_xen_heap      PG_mask(1, 2)
+/* ... */
+/* Page is broken? */
+#define _PGC_broken       PG_shift(7)
+#define PGC_broken        PG_mask(1, 7)
+ /* Mutually-exclusive page states: { inuse, offlining, offlined, free }. */
+#define PGC_state         PG_mask(3, 9)
+#define PGC_state_inuse   PG_mask(0, 9)
+#define PGC_state_offlining PG_mask(1, 9)
+#define PGC_state_offlined PG_mask(2, 9)
+#define PGC_state_free    PG_mask(3, 9)
+#define page_state_is(pg, st) (((pg)->count_info&PGC_state) == PGC_state_##st)
+
+/* Count of references to this frame. */
+#define PGC_count_width   PG_shift(9)
+#define PGC_count_mask    ((1UL<<PGC_count_width)-1)
+
+extern unsigned long xenheap_mfn_start, xenheap_mfn_end;
+extern unsigned long xenheap_virt_end;
+
+#define is_xen_heap_page(page) is_xen_heap_mfn(page_to_mfn(page))
+#define is_xen_heap_mfn(mfn) ({                                 \
+    unsigned long _mfn = (mfn);                                 \
+    (_mfn >= xenheap_mfn_start && _mfn < xenheap_mfn_end);      \
+})
+#define is_xen_fixed_mfn(mfn) is_xen_heap_mfn(mfn)
+
+#define page_get_owner(_p)    (_p)->v.inuse.domain
+#define page_set_owner(_p,_d) ((_p)->v.inuse.domain = (_d))
+
+#define maddr_get_owner(ma)   (page_get_owner(maddr_to_page((ma))))
+#define vaddr_get_owner(va)   (page_get_owner(virt_to_page((va))))
+
+#define XENSHARE_writable 0
+#define XENSHARE_readonly 1
+extern void share_xen_page_with_guest(
+    struct page_info *page, struct domain *d, int readonly);
+extern void share_xen_page_with_privileged_guests(
+    struct page_info *page, int readonly);
+
+#define frame_table ((struct page_info *)FRAMETABLE_VIRT_START)
+
+extern unsigned long max_page;
+extern unsigned long total_pages;
+
+/* Boot-time pagetable setup */
+extern void setup_pagetables(unsigned long boot_phys_offset);
+/* Set up the xenheap: up to 1GB of contiguous, always-mapped memory.
+ * Base must be 32MB aligned and size a multiple of 32MB. */
+extern void setup_xenheap_mappings(unsigned long base_mfn, unsigned long nr_mfns);
+/* Map a frame table to cover physical addresses ps through pe */
+extern void setup_frametable_mappings(paddr_t ps, paddr_t pe);
+/* Map a 4k page in a fixmap entry */
+extern void set_fixmap(unsigned map, unsigned long mfn, unsigned attributes);
+/* Remove a mapping from a fixmap entry */
+extern void clear_fixmap(unsigned map);
+
+
+#define mfn_valid(mfn)        ({                                              \
+    unsigned long __m_f_n = (mfn);                                            \
+    likely(__m_f_n < max_page);                                               \
+})
+
+#define max_pdx                 max_page
+/* XXX Assume everything in the 40-bit physical alias 0x8000000000 for now */
+#define pfn_to_pdx(pfn)         ((pfn) - 0x8000000UL)
+#define pdx_to_pfn(pdx)         ((pdx) + 0x8000000UL)
+#define virt_to_pdx(va)         virt_to_mfn(va)
+#define pdx_to_virt(pdx)        mfn_to_virt(pdx)
+
+/* Convert between machine frame numbers and page-info structures. */
+#define mfn_to_page(mfn)  (frame_table + pfn_to_pdx(mfn))
+#define page_to_mfn(pg)   pdx_to_pfn((unsigned long)((pg) - frame_table))
+#define __page_to_mfn(pg)  page_to_mfn(pg)
+#define __mfn_to_page(mfn) mfn_to_page(mfn)
+
+/* Convert between machine addresses and page-info structures. */
+#define maddr_to_page(ma) __mfn_to_page((ma) >> PAGE_SHIFT)
+#define page_to_maddr(pg) ((paddr_t)__page_to_mfn(pg) << PAGE_SHIFT)
+
+/* Convert between frame number and address formats.  */
+#define pfn_to_paddr(pfn) ((paddr_t)(pfn) << PAGE_SHIFT)
+#define paddr_to_pfn(pa)  ((unsigned long)((pa) >> PAGE_SHIFT))
+#define paddr_to_pdx(pa)    pfn_to_pdx(paddr_to_pfn(pa))
+
+
+static inline paddr_t virt_to_maddr(void *va)
+{
+    uint64_t par = va_to_par((uint32_t)va);
+    return (par & PADDR_MASK & PAGE_MASK) | ((unsigned long) va & ~PAGE_MASK);
+}
+
+static inline void *maddr_to_virt(paddr_t ma)
+{
+    ASSERT(is_xen_heap_mfn(ma >> PAGE_SHIFT));
+    ma -= pfn_to_paddr(xenheap_mfn_start);
+    return (void *)(unsigned long) ma + XENHEAP_VIRT_START;
+}
+
+static inline paddr_t gvirt_to_maddr(uint32_t va)
+{
+    uint64_t par = gva_to_par(va);
+    return (par & PADDR_MASK & PAGE_MASK) | ((unsigned long) va & ~PAGE_MASK);
+}
+
+/* Convert between Xen-heap virtual addresses and machine addresses. */
+#define __pa(x)             (virt_to_maddr(x))
+#define __va(x)             (maddr_to_virt(x))
+
+/* Convert between Xen-heap virtual addresses and machine frame numbers. */
+#define virt_to_mfn(va)   (virt_to_maddr(va) >> PAGE_SHIFT)
+#define mfn_to_virt(mfn)  (maddr_to_virt((paddr_t)(mfn) << PAGE_SHIFT))
+
+
+static inline int get_order_from_bytes(paddr_t size)
+{
+    int order;
+    size = (size-1) >> PAGE_SHIFT;
+    for ( order = 0; size; order++ )
+        size >>= 1;
+    return order;
+}
+
+static inline int get_order_from_pages(unsigned long nr_pages)
+{
+    int order;
+    nr_pages--;
+    for ( order = 0; nr_pages; order++ )
+        nr_pages >>= 1;
+    return order;
+}
+
+
+/* Convert between Xen-heap virtual addresses and page-info structures. */
+static inline struct page_info *virt_to_page(const void *v)
+{
+    unsigned long va = (unsigned long)v;
+    ASSERT(va >= XENHEAP_VIRT_START);
+    ASSERT(va < xenheap_virt_end);
+
+    return frame_table + ((va - XENHEAP_VIRT_START) >> PAGE_SHIFT);
+}
+
+static inline void *page_to_virt(const struct page_info *pg)
+{
+    ASSERT((unsigned long)pg - FRAMETABLE_VIRT_START < frametable_virt_end);
+    return (void *)(XENHEAP_VIRT_START +
+                    ((unsigned long)pg - FRAMETABLE_VIRT_START) /
+                    (sizeof(*pg) / (sizeof(*pg) & -sizeof(*pg))) *
+                    (PAGE_SIZE / (sizeof(*pg) & -sizeof(*pg))));
+
+}
+
+struct domain *page_get_owner_and_reference(struct page_info *page);
+void put_page(struct page_info *page);
+int  get_page(struct page_info *page, struct domain *domain);
+
+/*
+ * The MPT (machine->physical mapping table) is an array of word-sized
+ * values, indexed on machine frame number. It is expected that guest OSes
+ * will use it to store a "physical" frame number to give the appearance of
+ * contiguous (or near contiguous) physical memory.
+ */
+#undef  machine_to_phys_mapping
+#define machine_to_phys_mapping  ((unsigned long *)RDWR_MPT_VIRT_START)
+#define INVALID_M2P_ENTRY        (~0UL)
+#define VALID_M2P(_e)            (!((_e) & (1UL<<(BITS_PER_LONG-1))))
+#define SHARED_M2P_ENTRY         (~0UL - 1UL)
+#define SHARED_M2P(_e)           ((_e) == SHARED_M2P_ENTRY)
+
+#define _set_gpfn_from_mfn(mfn, pfn) ({                        \
+    struct domain *d = page_get_owner(__mfn_to_page(mfn));     \
+    if(d && (d == dom_cow))                                    \
+        machine_to_phys_mapping[(mfn)] = SHARED_M2P_ENTRY;     \
+    else                                                       \
+        machine_to_phys_mapping[(mfn)] = (pfn);                \
+    })
+
+#define put_gfn(d, g)   ((void)0)
+
+#define INVALID_MFN             (~0UL)
+
+/* Xen always owns P2M on ARM */
+#define set_gpfn_from_mfn(mfn, pfn) do { (void) (mfn),(pfn); } while (0)
+#define mfn_to_gmfn(_d, mfn)  (mfn)
+
+
+/* Arch-specific portion of memory_op hypercall. */
+long arch_memory_op(int op, XEN_GUEST_HANDLE(void) arg);
+
+int steal_page(
+    struct domain *d, struct page_info *page, unsigned int memflags);
+int donate_page(
+    struct domain *d, struct page_info *page, unsigned int memflags);
+
+#define domain_set_alloc_bitsize(d) ((void)0)
+#define domain_clamp_alloc_bitsize(d, b) (b)
+
+unsigned long domain_get_maximum_gpfn(struct domain *d);
+
+extern struct domain *dom_xen, *dom_io, *dom_cow;
+
+#define memguard_init(_s)              (_s)
+#define memguard_guard_stack(_p)       ((void)0)
+#define memguard_guard_range(_p,_l)    ((void)0)
+#define memguard_unguard_range(_p,_l)  ((void)0)
+int guest_physmap_mark_populate_on_demand(struct domain *d, unsigned long gfn,
+                                          unsigned int order);
+
+extern void put_page_type(struct page_info *page);
+static inline void put_page_and_type(struct page_info *page)
+{
+    put_page_type(page);
+    put_page(page);
+}
+
+#endif /*  __ARCH_ARM_MM__ */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/p2m.h b/xen/include/asm-arm/p2m.h
new file mode 100644
index 0000000..aec52f7
--- /dev/null
+++ b/xen/include/asm-arm/p2m.h
@@ -0,0 +1,88 @@
+#ifndef _XEN_P2M_H
+#define _XEN_P2M_H
+
+#include <xen/mm.h>
+
+struct domain;
+
+/* Per-p2m-table state */
+struct p2m_domain {
+    /* Lock that protects updates to the p2m */
+    spinlock_t lock;
+
+    /* Pages used to construct the p2m */
+    struct page_list_head pages;
+
+    /* Root of p2m page tables, 2 contiguous pages */
+    struct page_info *first_level;
+
+    /* Current VMID in use */
+    uint8_t vmid;
+};
+
+/* Init the datastructures for later use by the p2m code */
+int p2m_init(struct domain *d);
+
+/* Allocate a new p2m table for a domain.
+ *
+ * Returns 0 for success or -errno.
+ */
+int p2m_alloc_table(struct domain *d);
+
+/* */
+void p2m_load_VTTBR(struct domain *d);
+
+/* Setup p2m RAM mapping for domain d from start-end. */
+int p2m_populate_ram(struct domain *d, paddr_t start, paddr_t end);
+/* Map MMIO regions in the p2m: start_gaddr and end_gaddr is the range
+ * in the guest physical address space to map, starting from the machine
+ * address maddr. */
+int map_mmio_regions(struct domain *d, paddr_t start_gaddr,
+                     paddr_t end_gaddr, paddr_t maddr);
+
+unsigned long gmfn_to_mfn(struct domain *d, unsigned long gpfn);
+
+/*
+ * Populate-on-demand
+ */
+
+/* Call when decreasing memory reservation to handle PoD entries properly.
+ * Will return '1' if all entries were handled and nothing more need be done.*/
+int
+p2m_pod_decrease_reservation(struct domain *d,
+                             xen_pfn_t gpfn,
+                             unsigned int order);
+
+/* Compatibility function exporting the old untyped interface */
+static inline unsigned long get_gfn_untyped(struct domain *d, unsigned long gpfn)
+{
+    return gmfn_to_mfn(d, gpfn);
+}
+
+int get_page_type(struct page_info *page, unsigned long type);
+int is_iomem_page(unsigned long mfn);
+static inline int get_page_and_type(struct page_info *page,
+                                    struct domain *domain,
+                                    unsigned long type)
+{
+    int rc = get_page(page, domain);
+
+    if ( likely(rc) && unlikely(!get_page_type(page, type)) )
+    {
+        put_page(page);
+        rc = 0;
+    }
+
+    return rc;
+}
+
+#endif /* _XEN_P2M_H */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/page.h b/xen/include/asm-arm/page.h
new file mode 100644
index 0000000..6dc1659
--- /dev/null
+++ b/xen/include/asm-arm/page.h
@@ -0,0 +1,335 @@
+#ifndef __ARM_PAGE_H__
+#define __ARM_PAGE_H__
+
+#include <xen/config.h>
+
+#define PADDR_BITS              40
+#define PADDR_MASK              ((1ULL << PADDR_BITS)-1)
+
+#define VADDR_BITS              32
+#define VADDR_MASK              (~0UL)
+
+/* Shareability values for the LPAE entries */
+#define LPAE_SH_NON_SHAREABLE 0x0
+#define LPAE_SH_UNPREDICTALE  0x1
+#define LPAE_SH_OUTER         0x2
+#define LPAE_SH_INNER         0x3
+
+/* LPAE Memory region attributes, to match Linux's (non-LPAE) choices.
+ * Indexed by the AttrIndex bits of a LPAE entry;
+ * the 8-bit fields are packed little-endian into MAIR0 and MAIR1
+ *
+ *                 ai    encoding
+ *   UNCACHED      000   0000 0000  -- Strongly Ordered
+ *   BUFFERABLE    001   0100 0100  -- Non-Cacheable
+ *   WRITETHROUGH  010   1010 1010  -- Write-through
+ *   WRITEBACK     011   1110 1110  -- Write-back
+ *   DEV_SHARED    100   0000 0100  -- Device
+ *   ??            101
+ *   reserved      110
+ *   WRITEALLOC    111   1111 1111  -- Write-back write-allocate
+ *
+ *   DEV_NONSHARED 100   (== DEV_SHARED)
+ *   DEV_WC        001   (== BUFFERABLE)
+ *   DEV_CACHED    011   (== WRITEBACK)
+ */
+#define MAIR0VAL 0xeeaa4400
+#define MAIR1VAL 0xff000004
+
+#define UNCACHED      0x0
+#define BUFFERABLE    0x1
+#define WRITETHROUGH  0x2
+#define WRITEBACK     0x3
+#define DEV_SHARED    0x4
+#define WRITEALLOC    0x7
+#define DEV_NONSHARED DEV_SHARED
+#define DEV_WC        BUFFERABLE
+#define DEV_CACHED    WRITEBACK
+
+
+#ifndef __ASSEMBLY__
+
+#include <xen/types.h>
+#include <xen/lib.h>
+
+/* WARNING!  Unlike the Intel pagetable code, where l1 is the lowest
+ * level and l4 is the root of the trie, the ARM pagetables follow ARM's
+ * documentation: the levels are called first, second &c in the order
+ * that the MMU walks them (i.e. "first" is the root of the trie). */
+
+/******************************************************************************
+ * ARMv7-A LPAE pagetables: 3-level trie, mapping 40-bit input to
+ * 40-bit output addresses.  Tables at all levels have 512 64-bit entries
+ * (i.e. are 4Kb long).
+ *
+ * The bit-shuffling that has the permission bits in branch nodes in a
+ * different place from those in leaf nodes seems to be to allow linear
+ * pagetable tricks.  If we're not doing that then the set of permission
+ * bits that's not in use in a given node type can be used as
+ * extra software-defined bits. */
+
+typedef struct {
+    /* These are used in all kinds of entry. */
+    unsigned long valid:1;      /* Valid mapping */
+    unsigned long table:1;      /* == 1 in 4k map entries too */
+
+    /* These ten bits are only used in Block entries and are ignored
+     * in Table entries. */
+    unsigned long ai:3;         /* Attribute Index */
+    unsigned long ns:1;         /* Not-Secure */
+    unsigned long user:1;       /* User-visible */
+    unsigned long ro:1;         /* Read-Only */
+    unsigned long sh:2;         /* Shareability */
+    unsigned long af:1;         /* Access Flag */
+    unsigned long ng:1;         /* Not-Global */
+
+    /* The base address must be approprately aligned for Block entries */
+    unsigned long base:28;      /* Base address of block or next table */
+    unsigned long sbz:12;       /* Must be zero */
+
+    /* These seven bits are only used in Block entries and are ignored
+     * in Table entries. */
+    unsigned long hint:1;       /* In a block of 16 contiguous entries */
+    unsigned long pxn:1;        /* Privileged-XN */
+    unsigned long xn:1;         /* eXecute-Never */
+    unsigned long avail:4;      /* Ignored by hardware */
+
+    /* These 5 bits are only used in Table entries and are ignored in
+     * Block entries */
+    unsigned long pxnt:1;       /* Privileged-XN */
+    unsigned long xnt:1;        /* eXecute-Never */
+    unsigned long apt:2;        /* Access Permissions */
+    unsigned long nst:1;        /* Not-Secure */
+} __attribute__((__packed__)) lpae_pt_t;
+
+/* The p2m tables have almost the same layout, but some of the permission
+ * and cache-control bits are laid out differently (or missing) */
+typedef struct {
+    /* These are used in all kinds of entry. */
+    unsigned long valid:1;      /* Valid mapping */
+    unsigned long table:1;      /* == 1 in 4k map entries too */
+
+    /* These ten bits are only used in Block entries and are ignored
+     * in Table entries. */
+    unsigned long mattr:4;      /* Memory Attributes */
+    unsigned long read:1;       /* Read access */
+    unsigned long write:1;      /* Write access */
+    unsigned long sh:2;         /* Shareability */
+    unsigned long af:1;         /* Access Flag */
+    unsigned long sbz4:1;
+
+    /* The base address must be approprately aligned for Block entries */
+    unsigned long base:28;      /* Base address of block or next table */
+    unsigned long sbz3:12;
+
+    /* These seven bits are only used in Block entries and are ignored
+     * in Table entries. */
+    unsigned long hint:1;       /* In a block of 16 contiguous entries */
+    unsigned long sbz2:1;
+    unsigned long xn:1;         /* eXecute-Never */
+    unsigned long avail:4;      /* Ignored by hardware */
+
+    unsigned long sbz1:5;
+} __attribute__((__packed__)) lpae_p2m_t;
+
+typedef union {
+    uint64_t bits;
+    lpae_pt_t pt;
+    lpae_p2m_t p2m;
+} lpae_t;
+
+/* Standard entry type that we'll use to build Xen's own pagetables.
+ * We put the same permissions at every level, because they're ignored
+ * by the walker in non-leaf entries. */
+static inline lpae_t mfn_to_xen_entry(unsigned long mfn)
+{
+    paddr_t pa = ((paddr_t) mfn) << PAGE_SHIFT;
+    lpae_t e = (lpae_t) {
+        .pt = {
+            .xn = 1,              /* No need to execute outside .text */
+            .ng = 1,              /* Makes TLB flushes easier */
+            .af = 1,              /* No need for access tracking */
+            .sh = LPAE_SH_OUTER,  /* Xen mappings are globally coherent */
+            .ns = 1,              /* Hyp mode is in the non-secure world */
+            .user = 1,            /* See below */
+            .ai = WRITEALLOC,
+            .table = 0,           /* Set to 1 for links and 4k maps */
+            .valid = 1,           /* Mappings are present */
+        }};;
+    /* Setting the User bit is strange, but the ATS1H[RW] instructions
+     * don't seem to work otherwise, and since we never run on Xen
+     * pagetables un User mode it's OK.  If this changes, remember
+     * to update the hard-coded values in head.S too */
+
+    ASSERT(!(pa & ~PAGE_MASK));
+    ASSERT(!(pa & ~PADDR_MASK));
+
+    // XXX shifts
+    e.bits |= pa;
+    return e;
+}
+
+static inline lpae_t mfn_to_p2m_entry(unsigned long mfn)
+{
+    paddr_t pa = ((paddr_t) mfn) << PAGE_SHIFT;
+    lpae_t e = (lpae_t) {
+        .p2m.xn = 0,
+        .p2m.af = 1,
+        .p2m.sh = LPAE_SH_OUTER,
+        .p2m.write = 1,
+        .p2m.read = 1,
+        .p2m.mattr = 0xf,
+        .p2m.table = 1,
+        .p2m.valid = 1,
+    };
+
+    ASSERT(!(pa & ~PAGE_MASK));
+    ASSERT(!(pa & ~PADDR_MASK));
+
+    e.bits |= pa;
+
+    return e;
+}
+
+/* Write a pagetable entry */
+static inline void write_pte(lpae_t *p, lpae_t pte)
+{
+    asm volatile (
+        /* Safely write the entry (STRD is atomic on CPUs that support LPAE) */
+        "strd %0, %H0, [%1];"
+        /* Push this cacheline to the PoC so the rest of the system sees it. */
+        STORE_CP32(1, DCCMVAC)
+        : : "r" (pte.bits), "r" (p) : "memory");
+}
+
+/*
+ * Flush all hypervisor mappings from the data TLB. This is not
+ * sufficient when changing code mappings or for self modifying code.
+ */
+static inline void flush_xen_data_tlb(void)
+{
+    register unsigned long r0 asm ("r0");
+    asm volatile("dsb;" /* Ensure preceding are visible */
+                 STORE_CP32(0, TLBIALLH)
+                 "dsb;" /* Ensure completion of the TLB flush */
+                 "isb;"
+                 : : "r" (r0) /* dummy */: "memory");
+}
+
+/*
+ * Flush one VA's hypervisor mappings from the data TLB. This is not
+ * sufficient when changing code mappings or for self modifying code.
+ */
+static inline void flush_xen_data_tlb_va(unsigned long va)
+{
+    asm volatile("dsb;" /* Ensure preceding are visible */
+                 STORE_CP32(0, TLBIMVAH)
+                 "dsb;" /* Ensure completion of the TLB flush */
+                 "isb;"
+                 : : "r" (va) : "memory");
+}
+
+/* Flush all non-hypervisor mappings from the TLB */
+static inline void flush_guest_tlb(void)
+{
+    register unsigned long r0 asm ("r0");
+    WRITE_CP32(r0 /* dummy */, TLBIALLNSNH);
+}
+
+/* Ask the MMU to translate a VA for us */
+static inline uint64_t __va_to_par(uint32_t va)
+{
+    uint64_t par, tmp;
+    tmp = READ_CP64(PAR);
+    WRITE_CP32(va, ATS1HR);
+    isb(); /* Ensure result is available. */
+    par = READ_CP64(PAR);
+    WRITE_CP64(tmp, PAR);
+    return par;
+}
+
+static inline uint64_t va_to_par(uint32_t va)
+{
+    uint64_t par = __va_to_par(va);
+    /* It is not OK to call this with an invalid VA */
+    if ( par & PAR_F ) panic_PAR(par, "Hypervisor");
+    return par;
+}
+
+/* Ask the MMU to translate a Guest VA for us */
+static inline uint64_t __gva_to_par(uint32_t va)
+{
+    uint64_t par, tmp;
+    tmp = READ_CP64(PAR);
+    WRITE_CP32(va, ATS12NSOPR);
+    isb(); /* Ensure result is available. */
+    par = READ_CP64(PAR);
+    WRITE_CP64(tmp, PAR);
+    return par;
+}
+static inline uint64_t gva_to_par(uint32_t va)
+{
+    uint64_t par = __gva_to_par(va);
+    /* It is not OK to call this with an invalid VA */
+    /* XXX harsh for a guest address... */
+    if ( par & PAR_F ) panic_PAR(par, "Guest");
+    return par;
+}
+static inline uint64_t __gva_to_ipa(uint32_t va)
+{
+    uint64_t par, tmp;
+    tmp = READ_CP64(PAR);
+    WRITE_CP32(va, ATS1CPR);
+    isb(); /* Ensure result is available. */
+    par = READ_CP64(PAR);
+    WRITE_CP64(tmp, PAR);
+    return par;
+}
+static inline uint64_t gva_to_ipa(uint32_t va)
+{
+    uint64_t par = __gva_to_ipa(va);
+    /* It is not OK to call this with an invalid VA */
+    /* XXX harsh for a guest address... */
+    if ( par & PAR_F ) panic_PAR(par, "Guest");
+    return (par & PADDR_MASK & PAGE_MASK) | ((unsigned long) va & ~PAGE_MASK);
+}
+/* Bits in the PAR returned by va_to_par */
+#define PAR_FAULT 0x1
+
+#endif /* __ASSEMBLY__ */
+
+/* These numbers add up to a 39-bit input address space.  The  ARMv7-A
+ * architecture actually specifies a 40-bit input address space for the p2m,
+ * with an 8K (1024-entry) top-level table. */
+
+#define LPAE_SHIFT      9
+#define LPAE_ENTRIES    (1u << LPAE_SHIFT)
+#define LPAE_ENTRY_MASK (LPAE_ENTRIES - 1)
+
+#define THIRD_SHIFT  PAGE_SHIFT
+#define SECOND_SHIFT (THIRD_SHIFT + LPAE_SHIFT)
+#define FIRST_SHIFT  (SECOND_SHIFT + LPAE_SHIFT)
+
+/* Calculate the offsets into the pagetables for a given VA */
+#define first_linear_offset(va) (va >> FIRST_SHIFT)
+#define second_linear_offset(va) (va >> SECOND_SHIFT)
+#define third_linear_offset(va) (va >> THIRD_SHIFT)
+#define first_table_offset(va) (first_linear_offset(va))
+#define second_table_offset(va) (second_linear_offset(va) & LPAE_ENTRY_MASK)
+#define third_table_offset(va) (third_linear_offset(va) & LPAE_ENTRY_MASK)
+
+#define clear_page(page)memset((void *)(page), 0, PAGE_SIZE)
+
+#define PAGE_ALIGN(x) (((x) + PAGE_SIZE - 1) & PAGE_MASK)
+
+#endif /* __ARM_PAGE_H__ */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 16:29:28 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 16: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.xensource.com>)
	id 1RbEBQ-0002Bw-PS; Thu, 15 Dec 2011 16:29:24 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RbEBO-00029P-JI
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 16:29:23 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1323966500!60916191!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDY5Mjg=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17698 invoked from network); 15 Dec 2011 16:28:25 -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;
	15 Dec 2011 16:28:25 -0000
X-IronPort-AV: E=Sophos;i="4.71,357,1320642000"; d="scan'208";a="20001870"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Dec 2011 11:29:17 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Thu, 15 Dec 2011 11:29:16 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pBFGSMtf003330;
	Thu, 15 Dec 2011 08:28:59 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Thu, 15 Dec 2011 16:30:49 +0000
Message-ID: <1323966657-19790-17-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1112131831560.3517@kaball-desktop>
References: <alpine.DEB.2.00.1112131831560.3517@kaball-desktop>
MIME-Version: 1.0
Cc: keir.xen@gmail.com, Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, JBeulich@suse.com,
	Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v3 17/25] arm: mm and p2m
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Functions to setup pagetables, handle the p2m, map and unmap domain
pages, copy data to/from guest addresses.
The implementation is based on the LPAE extension for ARMv7 and makes
use of the two level transtion mechanism.


Changes in v3:

- rename copy_to_user and copy_from_user to raw_copy_to_guest and
raw_copy_from_guest.


Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
---
 xen/arch/arm/domain.c              |    4 +
 xen/arch/arm/guestcopy.c           |   81 +++++++++
 xen/arch/arm/mm.c                  |  321 ++++++++++++++++++++++++++++++++++
 xen/arch/arm/p2m.c                 |  214 +++++++++++++++++++++++
 xen/include/asm-arm/domain.h       |    2 +
 xen/include/asm-arm/guest_access.h |  131 ++++++++++++++
 xen/include/asm-arm/mm.h           |  315 +++++++++++++++++++++++++++++++++
 xen/include/asm-arm/p2m.h          |   88 ++++++++++
 xen/include/asm-arm/page.h         |  335 ++++++++++++++++++++++++++++++++++++
 9 files changed, 1491 insertions(+), 0 deletions(-)
 create mode 100644 xen/arch/arm/guestcopy.c
 create mode 100644 xen/arch/arm/mm.c
 create mode 100644 xen/arch/arm/p2m.c
 create mode 100644 xen/include/asm-arm/guest_access.h
 create mode 100644 xen/include/asm-arm/mm.h
 create mode 100644 xen/include/asm-arm/p2m.h
 create mode 100644 xen/include/asm-arm/page.h

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index ecbc5b7..0844b37 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -224,6 +224,10 @@ int arch_domain_create(struct domain *d, unsigned int domcr_flags)
 {
     int rc;
 
+    rc = -ENOMEM;
+    if ( (rc = p2m_init(d)) != 0 )
+        goto fail;
+
     d->max_vcpus = 8;
 
     rc = 0;
diff --git a/xen/arch/arm/guestcopy.c b/xen/arch/arm/guestcopy.c
new file mode 100644
index 0000000..d9eb7ac
--- /dev/null
+++ b/xen/arch/arm/guestcopy.c
@@ -0,0 +1,81 @@
+#include <xen/config.h>
+#include <xen/lib.h>
+#include <xen/domain_page.h>
+
+#include <asm/mm.h>
+#include <asm/guest_access.h>
+
+unsigned long raw_copy_to_guest(void *to, const void *from, unsigned len)
+{
+    /* XXX needs to handle faults */
+    unsigned offset = ((unsigned long)to & ~PAGE_MASK);
+
+    while ( len )
+    {
+        paddr_t g = gvirt_to_maddr((uint32_t) to);
+        void *p = map_domain_page(g>>PAGE_SHIFT);
+        unsigned size = min(len, (unsigned)PAGE_SIZE - offset);
+
+        p += offset;
+        memcpy(p, from, size);
+
+        unmap_domain_page(p - offset);
+        len -= size;
+        from += size;
+        to += size;
+        offset = 0;
+    }
+
+    return 0;
+}
+
+unsigned long raw_clear_guest(void *to, unsigned len)
+{
+    /* XXX needs to handle faults */
+    unsigned offset = ((unsigned long)to & ~PAGE_MASK);
+
+    while ( len )
+    {
+        paddr_t g = gvirt_to_maddr((uint32_t) to);
+        void *p = map_domain_page(g>>PAGE_SHIFT);
+        unsigned size = min(len, (unsigned)PAGE_SIZE - offset);
+
+        p += offset;
+        memset(p, 0x00, size);
+
+        unmap_domain_page(p - offset);
+        len -= size;
+        to += size;
+        offset = 0;
+    }
+
+    return 0;
+}
+
+unsigned long raw_copy_from_guest(void *to, const void __user *from, unsigned len)
+{
+    while ( len )
+    {
+        paddr_t g = gvirt_to_maddr((uint32_t) from & PAGE_MASK);
+        void *p = map_domain_page(g>>PAGE_SHIFT);
+        unsigned size = min(len, (unsigned)(PAGE_SIZE - ((unsigned)from & (~PAGE_MASK))));
+
+        p += ((unsigned long)from & (~PAGE_MASK));
+
+        memcpy(to, p, size);
+
+        unmap_domain_page(p);
+        len -= size;
+        from += size;
+        to += size;
+    }
+    return 0;
+}
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
new file mode 100644
index 0000000..613d084
--- /dev/null
+++ b/xen/arch/arm/mm.c
@@ -0,0 +1,321 @@
+/*
+ * xen/arch/arm/mm.c
+ *
+ * MMU code for an ARMv7-A with virt extensions.
+ *
+ * Tim Deegan <tim@xen.org>
+ * Copyright (c) 2011 Citrix Systems.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include <xen/config.h>
+#include <xen/compile.h>
+#include <xen/types.h>
+#include <xen/init.h>
+#include <xen/mm.h>
+#include <xen/preempt.h>
+#include <asm/page.h>
+#include <asm/current.h>
+
+struct domain *dom_xen, *dom_io;
+
+/* Static start-of-day pagetables that we use before the allocators are up */
+lpae_t xen_pgtable[LPAE_ENTRIES] __attribute__((__aligned__(4096)));
+lpae_t xen_second[LPAE_ENTRIES*4] __attribute__((__aligned__(4096*4)));
+static lpae_t xen_fixmap[LPAE_ENTRIES] __attribute__((__aligned__(4096)));
+static lpae_t xen_xenmap[LPAE_ENTRIES] __attribute__((__aligned__(4096)));
+
+/* Limits of the Xen heap */
+unsigned long xenheap_mfn_start, xenheap_mfn_end;
+unsigned long xenheap_virt_end;
+
+unsigned long frametable_virt_end;
+
+/* Map a 4k page in a fixmap entry */
+void set_fixmap(unsigned map, unsigned long mfn, unsigned attributes)
+{
+    lpae_t pte = mfn_to_xen_entry(mfn);
+    pte.pt.table = 1; /* 4k mappings always have this bit set */
+    pte.pt.ai = attributes;
+    write_pte(xen_fixmap + third_table_offset(FIXMAP_ADDR(map)), pte);
+    flush_xen_data_tlb_va(FIXMAP_ADDR(map));
+}
+
+/* Remove a mapping from a fixmap entry */
+void clear_fixmap(unsigned map)
+{
+    lpae_t pte = {0};
+    write_pte(xen_fixmap + third_table_offset(FIXMAP_ADDR(map)), pte);
+    flush_xen_data_tlb_va(FIXMAP_ADDR(map));
+}
+
+/* Map a page of domheap memory */
+void *map_domain_page(unsigned long mfn)
+{
+    unsigned long flags;
+    lpae_t *map = xen_second + second_linear_offset(DOMHEAP_VIRT_START);
+    unsigned long slot_mfn = mfn & ~LPAE_ENTRY_MASK;
+    uint32_t va;
+    lpae_t pte;
+    int i, slot;
+
+    local_irq_save(flags);
+
+    /* The map is laid out as an open-addressed hash table where each
+     * entry is a 2MB superpage pte.  We use the available bits of each
+     * PTE as a reference count; when the refcount is zero the slot can
+     * be reused. */
+    for ( slot = (slot_mfn >> LPAE_SHIFT) % DOMHEAP_ENTRIES, i = 0;
+          i < DOMHEAP_ENTRIES;
+          slot = (slot + 1) % DOMHEAP_ENTRIES, i++ )
+    {
+        if ( map[slot].pt.avail == 0 )
+        {
+            /* Commandeer this 2MB slot */
+            pte = mfn_to_xen_entry(slot_mfn);
+            pte.pt.avail = 1;
+            write_pte(map + slot, pte);
+            break;
+        }
+        else if ( map[slot].pt.avail < 0xf && map[slot].pt.base == slot_mfn )
+        {
+            /* This slot already points to the right place; reuse it */
+            map[slot].pt.avail++;
+            break;
+        }
+    }
+    /* If the map fills up, the callers have misbehaved. */
+    BUG_ON(i == DOMHEAP_ENTRIES);
+
+#ifndef NDEBUG
+    /* Searching the hash could get slow if the map starts filling up.
+     * Cross that bridge when we come to it */
+    {
+        static int max_tries = 32;
+        if ( i >= max_tries )
+        {
+            dprintk(XENLOG_WARNING, "Domheap map is filling: %i tries\n", i);
+            max_tries *= 2;
+        }
+    }
+#endif
+
+    local_irq_restore(flags);
+
+    va = (DOMHEAP_VIRT_START
+          + (slot << SECOND_SHIFT)
+          + ((mfn & LPAE_ENTRY_MASK) << THIRD_SHIFT));
+
+    /*
+     * We may not have flushed this specific subpage at map time,
+     * since we only flush the 4k page not the superpage
+     */
+    flush_xen_data_tlb_va(va);
+
+    return (void *)va;
+}
+
+/* Release a mapping taken with map_domain_page() */
+void unmap_domain_page(const void *va)
+{
+    unsigned long flags;
+    lpae_t *map = xen_second + second_linear_offset(DOMHEAP_VIRT_START);
+    int slot = ((unsigned long) va - DOMHEAP_VIRT_START) >> SECOND_SHIFT;
+
+    local_irq_save(flags);
+
+    ASSERT(slot >= 0 && slot < DOMHEAP_ENTRIES);
+    ASSERT(map[slot].pt.avail != 0);
+
+    map[slot].pt.avail--;
+
+    local_irq_restore(flags);
+}
+
+
+/* Boot-time pagetable setup.
+ * Changes here may need matching changes in head.S */
+void __init setup_pagetables(unsigned long boot_phys_offset)
+{
+    paddr_t xen_paddr, phys_offset;
+    unsigned long dest_va;
+    lpae_t pte, *p;
+    int i;
+
+    if ( boot_phys_offset != 0 )
+    {
+        /* Remove the old identity mapping of the boot paddr */
+        pte.bits = 0;
+        dest_va = (unsigned long)_start + boot_phys_offset;
+        write_pte(xen_second + second_linear_offset(dest_va), pte);
+    }
+
+    xen_paddr = XEN_PADDR;
+
+    /* Map the destination in the empty L2 above the fixmap */
+    dest_va = FIXMAP_ADDR(0) + (1u << SECOND_SHIFT);
+    pte = mfn_to_xen_entry(xen_paddr >> PAGE_SHIFT);
+    write_pte(xen_second + second_table_offset(dest_va), pte);
+
+    /* Calculate virt-to-phys offset for the new location */
+    phys_offset = xen_paddr - (unsigned long) _start;
+
+    /* Copy */
+    memcpy((void *) dest_va, _start, _end - _start);
+
+    /* Beware!  Any state we modify between now and the PT switch may be
+     * discarded when we switch over to the copy. */
+
+    /* Update the copy of xen_pgtable to use the new paddrs */
+    p = (void *) xen_pgtable + dest_va - (unsigned long) _start;
+    for ( i = 0; i < 4; i++)
+        p[i].pt.base += (phys_offset - boot_phys_offset) >> PAGE_SHIFT;
+    p = (void *) xen_second + dest_va - (unsigned long) _start;
+    for ( i = 0; i < 4 * LPAE_ENTRIES; i++)
+        if ( p[i].pt.valid )
+                p[i].pt.base += (phys_offset - boot_phys_offset) >> PAGE_SHIFT;
+
+    /* Change pagetables to the copy in the relocated Xen */
+    asm volatile (
+        STORE_CP64(0, HTTBR)          /* Change translation base */
+        "dsb;"                        /* Ensure visibility of HTTBR update */
+        STORE_CP32(0, TLBIALLH)       /* Flush hypervisor TLB */
+        STORE_CP32(0, BPIALL)         /* Flush branch predictor */
+        "dsb;"                        /* Ensure completion of TLB+BP flush */
+        "isb;"
+        : : "r" ((unsigned long) xen_pgtable + phys_offset) : "memory");
+
+    /* Undo the temporary map */
+    pte.bits = 0;
+    write_pte(xen_second + second_table_offset(dest_va), pte);
+    /*
+     * Have removed a mapping previously used for .text. Flush everything
+     * for safety.
+     */
+    asm volatile (
+        "dsb;"                        /* Ensure visibility of PTE write */
+        STORE_CP32(0, TLBIALLH)       /* Flush hypervisor TLB */
+        STORE_CP32(0, BPIALL)         /* Flush branch predictor */
+        "dsb;"                        /* Ensure completion of TLB+BP flush */
+        "isb;"
+        : : "r" (i /*dummy*/) : "memory");
+
+    /* Link in the fixmap pagetable */
+    pte = mfn_to_xen_entry((((unsigned long) xen_fixmap) + phys_offset)
+                           >> PAGE_SHIFT);
+    pte.pt.table = 1;
+    write_pte(xen_second + second_table_offset(FIXMAP_ADDR(0)), pte);
+    /*
+     * No flush required here. Individual flushes are done in
+     * set_fixmap as entries are used.
+     */
+
+    /* Break up the Xen mapping into 4k pages and protect them separately. */
+    for ( i = 0; i < LPAE_ENTRIES; i++ )
+    {
+        unsigned long mfn = paddr_to_pfn(xen_paddr) + i;
+        unsigned long va = XEN_VIRT_START + (i << PAGE_SHIFT);
+        if ( !is_kernel(va) )
+            break;
+        pte = mfn_to_xen_entry(mfn);
+        pte.pt.table = 1; /* 4k mappings always have this bit set */
+        if ( is_kernel_text(va) || is_kernel_inittext(va) )
+        {
+            pte.pt.xn = 0;
+            pte.pt.ro = 1;
+        }
+        if ( is_kernel_rodata(va) )
+            pte.pt.ro = 1;
+        write_pte(xen_xenmap + i, pte);
+        /* No flush required here as page table is not hooked in yet. */
+    }
+    pte = mfn_to_xen_entry((((unsigned long) xen_xenmap) + phys_offset)
+                           >> PAGE_SHIFT);
+    pte.pt.table = 1;
+    write_pte(xen_second + second_linear_offset(XEN_VIRT_START), pte);
+    /* Have changed a mapping used for .text. Flush everything for safety. */
+    asm volatile (
+        "dsb;"                        /* Ensure visibility of PTE write */
+        STORE_CP32(0, TLBIALLH)       /* Flush hypervisor TLB */
+        STORE_CP32(0, BPIALL)         /* Flush branch predictor */
+        "dsb;"                        /* Ensure completion of TLB+BP flush */
+        "isb;"
+        : : "r" (i /*dummy*/) : "memory");
+
+    /* From now on, no mapping may be both writable and executable. */
+    WRITE_CP32(READ_CP32(HSCTLR) | SCTLR_WXN, HSCTLR);
+}
+
+/* Create Xen's mappings of memory.
+ * Base and virt must be 32MB aligned and size a multiple of 32MB. */
+static void __init create_mappings(unsigned long virt,
+                                   unsigned long base_mfn,
+                                   unsigned long nr_mfns)
+{
+    unsigned long i, count;
+    lpae_t pte, *p;
+
+    ASSERT(!((virt >> PAGE_SHIFT) % (16 * LPAE_ENTRIES)));
+    ASSERT(!(base_mfn % (16 * LPAE_ENTRIES)));
+    ASSERT(!(nr_mfns % (16 * LPAE_ENTRIES)));
+
+    count = nr_mfns / LPAE_ENTRIES;
+    p = xen_second + second_linear_offset(virt);
+    pte = mfn_to_xen_entry(base_mfn);
+    pte.pt.hint = 1;  /* These maps are in 16-entry contiguous chunks. */
+    for ( i = 0; i < count; i++ )
+    {
+        write_pte(p + i, pte);
+        pte.pt.base += 1 << LPAE_SHIFT;
+    }
+    flush_xen_data_tlb();
+}
+
+/* Set up the xenheap: up to 1GB of contiguous, always-mapped memory. */
+void __init setup_xenheap_mappings(unsigned long base_mfn,
+                                   unsigned long nr_mfns)
+{
+    create_mappings(XENHEAP_VIRT_START, base_mfn, nr_mfns);
+
+    /* Record where the xenheap is, for translation routines. */
+    xenheap_virt_end = XENHEAP_VIRT_START + nr_mfns * PAGE_SIZE;
+    xenheap_mfn_start = base_mfn;
+    xenheap_mfn_end = base_mfn + nr_mfns;
+}
+
+/* Map a frame table to cover physical addresses ps through pe */
+void __init setup_frametable_mappings(paddr_t ps, paddr_t pe)
+{
+    unsigned long nr_pages = (pe - ps) >> PAGE_SHIFT;
+    unsigned long frametable_size = nr_pages * sizeof(struct page_info);
+    unsigned long base_mfn;
+
+    /* Round up to 32M boundary */
+    frametable_size = (frametable_size + 0x1ffffff) & ~0x1ffffff;
+    base_mfn = alloc_boot_pages(frametable_size >> PAGE_SHIFT, 5);
+    create_mappings(FRAMETABLE_VIRT_START, base_mfn, frametable_size >> PAGE_SHIFT);
+
+    memset(&frame_table[0], 0, nr_pages * sizeof(struct page_info));
+    memset(&frame_table[nr_pages], -1,
+           frametable_size - (nr_pages * sizeof(struct page_info)));
+
+    frametable_virt_end = FRAMETABLE_VIRT_START + (nr_pages * sizeof(struct page_info));
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
new file mode 100644
index 0000000..a1d026d
--- /dev/null
+++ b/xen/arch/arm/p2m.c
@@ -0,0 +1,214 @@
+#include <xen/config.h>
+#include <xen/sched.h>
+#include <xen/lib.h>
+#include <xen/errno.h>
+#include <xen/domain_page.h>
+
+void p2m_load_VTTBR(struct domain *d)
+{
+    struct p2m_domain *p2m = &d->arch.p2m;
+    paddr_t maddr = page_to_maddr(p2m->first_level);
+    uint64_t vttbr = maddr;
+
+    vttbr |= ((uint64_t)p2m->vmid&0xff)<<48;
+
+    printk("VTTBR dom%d = %"PRIx64"\n", d->domain_id, vttbr);
+
+    WRITE_CP64(vttbr, VTTBR);
+    isb(); /* Ensure update is visible */
+}
+
+static int p2m_create_entry(struct domain *d,
+                            lpae_t *entry)
+{
+    struct p2m_domain *p2m = &d->arch.p2m;
+    struct page_info *page;
+    void *p;
+    lpae_t pte;
+
+    BUG_ON(entry->p2m.valid);
+
+    page = alloc_domheap_page(d, 0);
+    if ( page == NULL )
+        return -ENOMEM;
+
+    page_list_add(page, &p2m->pages);
+
+    p = __map_domain_page(page);
+    clear_page(p);
+    unmap_domain_page(p);
+
+    pte = mfn_to_p2m_entry(page_to_mfn(page));
+
+    write_pte(entry, pte);
+
+    return 0;
+}
+
+static int create_p2m_entries(struct domain *d,
+                     int alloc,
+                     paddr_t start_gpaddr,
+                     paddr_t end_gpaddr,
+                     paddr_t maddr)
+{
+    int rc;
+    struct p2m_domain *p2m = &d->arch.p2m;
+    lpae_t *first = NULL, *second = NULL, *third = NULL;
+    paddr_t addr;
+    unsigned long cur_first_offset = ~0, cur_second_offset = ~0;
+
+    /* XXX Don't actually handle 40 bit guest physical addresses */
+    BUG_ON(start_gpaddr & 0x8000000000ULL);
+    BUG_ON(end_gpaddr   & 0x8000000000ULL);
+
+    first = __map_domain_page(p2m->first_level);
+
+    for(addr = start_gpaddr; addr < end_gpaddr; addr += PAGE_SIZE)
+    {
+        if ( !first[first_table_offset(addr)].p2m.valid )
+        {
+            rc = p2m_create_entry(d, &first[first_table_offset(addr)]);
+            if ( rc < 0 ) {
+                printk("p2m_populate_ram: L1 failed\n");
+                goto out;
+            }
+        }
+
+        BUG_ON(!first[first_table_offset(addr)].p2m.valid);
+
+        if ( cur_first_offset != first_table_offset(addr) )
+        {
+            if (second) unmap_domain_page(second);
+            second = map_domain_page(first[first_table_offset(addr)].p2m.base);
+            cur_first_offset = first_table_offset(addr);
+        }
+        /* else: second already valid */
+
+        if ( !second[second_table_offset(addr)].p2m.valid )
+        {
+            rc = p2m_create_entry(d, &second[second_table_offset(addr)]);
+            if ( rc < 0 ) {
+                printk("p2m_populate_ram: L2 failed\n");
+                goto out;
+            }
+        }
+
+        BUG_ON(!second[second_table_offset(addr)].p2m.valid);
+
+        if ( cur_second_offset != second_table_offset(addr) )
+        {
+            /* map third level */
+            if (third) unmap_domain_page(third);
+            third = map_domain_page(second[second_table_offset(addr)].p2m.base);
+            cur_second_offset = second_table_offset(addr);
+        }
+        /* else: third already valid */
+
+        BUG_ON(third[third_table_offset(addr)].p2m.valid);
+
+        /* Allocate a new RAM page and attach */
+        if (alloc)
+        {
+            struct page_info *page;
+            lpae_t pte;
+
+            rc = -ENOMEM;
+            page = alloc_domheap_page(d, 0);
+            if ( page == NULL ) {
+                printk("p2m_populate_ram: failed to allocate page\n");
+                goto out;
+            }
+
+            pte = mfn_to_p2m_entry(page_to_mfn(page));
+
+            write_pte(&third[third_table_offset(addr)], pte);
+        } else {
+            lpae_t pte = mfn_to_p2m_entry(maddr >> PAGE_SHIFT);
+            write_pte(&third[third_table_offset(addr)], pte);
+            maddr += PAGE_SIZE;
+        }
+    }
+
+    rc = 0;
+
+out:
+    spin_lock(&p2m->lock);
+
+    if (third) unmap_domain_page(third);
+    if (second) unmap_domain_page(second);
+    if (first) unmap_domain_page(first);
+
+    spin_unlock(&p2m->lock);
+
+    return rc;
+}
+
+int p2m_populate_ram(struct domain *d,
+                     paddr_t start,
+                     paddr_t end)
+{
+    return create_p2m_entries(d, 1, start, end, 0);
+}
+
+int map_mmio_regions(struct domain *d,
+                     paddr_t start_gaddr,
+                     paddr_t end_gaddr,
+                     paddr_t maddr)
+{
+    return create_p2m_entries(d, 0, start_gaddr, end_gaddr, maddr);
+}
+
+int p2m_alloc_table(struct domain *d)
+{
+    struct p2m_domain *p2m = &d->arch.p2m;
+    struct page_info *page;
+    void *p;
+
+    /* First level P2M is 2 consecutive pages */
+    page = alloc_domheap_pages(d, 1, 0);
+    if ( page == NULL )
+        return -ENOMEM;
+
+    spin_lock(&p2m->lock);
+
+    page_list_add(page, &p2m->pages);
+
+    /* Clear both first level pages */
+    p = __map_domain_page(page);
+    clear_page(p);
+    unmap_domain_page(p);
+
+    p = __map_domain_page(page + 1);
+    clear_page(p);
+    unmap_domain_page(p);
+
+    p2m->first_level = page;
+
+    spin_unlock(&p2m->lock);
+
+    return 0;
+}
+
+int p2m_init(struct domain *d)
+{
+    struct p2m_domain *p2m = &d->arch.p2m;
+
+    spin_lock_init(&p2m->lock);
+    INIT_PAGE_LIST_HEAD(&p2m->pages);
+
+    /* XXX allocate properly */
+    /* Zero is reserved */
+    p2m->vmid = d->domain_id + 1;
+
+    p2m->first_level = NULL;
+
+    return 0;
+}
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
index c226bdf..2226a24 100644
--- a/xen/include/asm-arm/domain.h
+++ b/xen/include/asm-arm/domain.h
@@ -16,6 +16,8 @@ struct pending_irq
 
 struct arch_domain
 {
+    struct p2m_domain p2m;
+
 }  __cacheline_aligned;
 
 struct arch_vcpu
diff --git a/xen/include/asm-arm/guest_access.h b/xen/include/asm-arm/guest_access.h
new file mode 100644
index 0000000..0fceae6
--- /dev/null
+++ b/xen/include/asm-arm/guest_access.h
@@ -0,0 +1,131 @@
+#ifndef __ASM_ARM_GUEST_ACCESS_H__
+#define __ASM_ARM_GUEST_ACCESS_H__
+
+#include <xen/guest_access.h>
+#include <xen/errno.h>
+
+/* Guests have their own comlete address space */
+#define access_ok(addr,size) (1)
+
+#define array_access_ok(addr,count,size) \
+    (likely(count < (~0UL/size)) && access_ok(addr,count*size))
+
+unsigned long raw_copy_to_guest(void *to, const void *from, unsigned len);
+unsigned long raw_copy_from_guest(void *to, const void *from, unsigned len);
+unsigned long raw_clear_guest(void *to, unsigned len);
+
+#define __raw_copy_to_guest raw_copy_to_guest
+#define __raw_copy_from_guest raw_copy_from_guest
+#define __raw_clear_guest raw_clear_guest
+
+/* Remainder copied from x86 -- could be common? */
+
+/* Is the guest handle a NULL reference? */
+#define guest_handle_is_null(hnd)        ((hnd).p == NULL)
+
+/* Offset the given guest handle into the array it refers to. */
+#define guest_handle_add_offset(hnd, nr) ((hnd).p += (nr))
+#define guest_handle_subtract_offset(hnd, nr) ((hnd).p -= (nr))
+
+/* Cast a guest handle to the specified type of handle. */
+#define guest_handle_cast(hnd, type) ({         \
+    type *_x = (hnd).p;                         \
+    (XEN_GUEST_HANDLE(type)) { _x };            \
+})
+
+#define guest_handle_from_ptr(ptr, type)        \
+    ((XEN_GUEST_HANDLE(type)) { (type *)ptr })
+#define const_guest_handle_from_ptr(ptr, type)  \
+    ((XEN_GUEST_HANDLE(const_##type)) { (const type *)ptr })
+
+/*
+ * Copy an array of objects to guest context via a guest handle,
+ * specifying an offset into the guest array.
+ */
+#define copy_to_guest_offset(hnd, off, ptr, nr) ({      \
+    const typeof(*(ptr)) *_s = (ptr);                   \
+    char (*_d)[sizeof(*_s)] = (void *)(hnd).p;          \
+    ((void)((hnd).p == (ptr)));                         \
+    raw_copy_to_guest(_d+(off), _s, sizeof(*_s)*(nr));  \
+})
+
+/*
+ * Clear an array of objects in guest context via a guest handle,
+ * specifying an offset into the guest array.
+ */
+#define clear_guest_offset(hnd, off, ptr, nr) ({      \
+    raw_clear_guest(_d+(off), nr);  \
+})
+
+/*
+ * Copy an array of objects from guest context via a guest handle,
+ * specifying an offset into the guest array.
+ */
+#define copy_from_guest_offset(ptr, hnd, off, nr) ({    \
+    const typeof(*(ptr)) *_s = (hnd).p;                 \
+    typeof(*(ptr)) *_d = (ptr);                         \
+    raw_copy_from_guest(_d, _s+(off), sizeof(*_d)*(nr));\
+})
+
+/* Copy sub-field of a structure to guest context via a guest handle. */
+#define copy_field_to_guest(hnd, ptr, field) ({         \
+    const typeof(&(ptr)->field) _s = &(ptr)->field;     \
+    void *_d = &(hnd).p->field;                         \
+    ((void)(&(hnd).p->field == &(ptr)->field));         \
+    raw_copy_to_guest(_d, _s, sizeof(*_s));             \
+})
+
+/* Copy sub-field of a structure from guest context via a guest handle. */
+#define copy_field_from_guest(ptr, hnd, field) ({       \
+    const typeof(&(ptr)->field) _s = &(hnd).p->field;   \
+    typeof(&(ptr)->field) _d = &(ptr)->field;           \
+    raw_copy_from_guest(_d, _s, sizeof(*_d));           \
+})
+
+/*
+ * Pre-validate a guest handle.
+ * Allows use of faster __copy_* functions.
+ */
+/* All ARM guests are paging mode external and hence safe */
+#define guest_handle_okay(hnd, nr) (1)
+#define guest_handle_subrange_okay(hnd, first, last) (1)
+
+#define __copy_to_guest_offset(hnd, off, ptr, nr) ({    \
+    const typeof(*(ptr)) *_s = (ptr);                   \
+    char (*_d)[sizeof(*_s)] = (void *)(hnd).p;          \
+    ((void)((hnd).p == (ptr)));                         \
+    __raw_copy_to_guest(_d+(off), _s, sizeof(*_s)*(nr));\
+})
+
+#define __clear_guest_offset(hnd, off, ptr, nr) ({      \
+    __raw_clear_guest(_d+(off), nr);  \
+})
+
+#define __copy_from_guest_offset(ptr, hnd, off, nr) ({  \
+    const typeof(*(ptr)) *_s = (hnd).p;                 \
+    typeof(*(ptr)) *_d = (ptr);                         \
+    __raw_copy_from_guest(_d, _s+(off), sizeof(*_d)*(nr));\
+})
+
+#define __copy_field_to_guest(hnd, ptr, field) ({       \
+    const typeof(&(ptr)->field) _s = &(ptr)->field;     \
+    void *_d = &(hnd).p->field;                         \
+    ((void)(&(hnd).p->field == &(ptr)->field));         \
+    __raw_copy_to_guest(_d, _s, sizeof(*_s));           \
+})
+
+#define __copy_field_from_guest(ptr, hnd, field) ({     \
+    const typeof(&(ptr)->field) _s = &(hnd).p->field;   \
+    typeof(&(ptr)->field) _d = &(ptr)->field;           \
+    __raw_copy_from_guest(_d, _s, sizeof(*_d));         \
+})
+
+#endif /* __ASM_ARM_GUEST_ACCESS_H__ */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/mm.h b/xen/include/asm-arm/mm.h
new file mode 100644
index 0000000..ead6e0c
--- /dev/null
+++ b/xen/include/asm-arm/mm.h
@@ -0,0 +1,315 @@
+#ifndef __ARCH_ARM_MM__
+#define __ARCH_ARM_MM__
+
+#include <xen/config.h>
+#include <xen/kernel.h>
+#include <asm/page.h>
+#include <public/xen.h>
+
+/* Find a suitable place at the top of memory for Xen to live */
+/* XXX For now, use the top of the VE's 4GB RAM, at a 40-bit alias */
+#define XEN_PADDR 0x80ffe00000ull
+
+/*
+ * Per-page-frame information.
+ *
+ * Every architecture must ensure the following:
+ *  1. 'struct page_info' contains a 'struct page_list_entry list'.
+ *  2. Provide a PFN_ORDER() macro for accessing the order of a free page.
+ */
+#define PFN_ORDER(_pfn) ((_pfn)->v.free.order)
+
+struct page_info
+{
+    /* Each frame can be threaded onto a doubly-linked list. */
+    struct page_list_entry list;
+
+    /* Reference count and various PGC_xxx flags and fields. */
+    unsigned long count_info;
+
+    /* Context-dependent fields follow... */
+    union {
+        /* Page is in use: ((count_info & PGC_count_mask) != 0). */
+        struct {
+            /* Type reference count and various PGT_xxx flags and fields. */
+            unsigned long type_info;
+        } inuse;
+        /* Page is on a free list: ((count_info & PGC_count_mask) == 0). */
+        struct {
+            /* Do TLBs need flushing for safety before next page use? */
+            bool_t need_tlbflush;
+        } free;
+
+    } u;
+
+    union {
+        /* Page is in use, but not as a shadow. */
+        struct {
+            /* Owner of this page (zero if page is anonymous). */
+            struct domain *domain;
+        } inuse;
+
+        /* Page is on a free list. */
+        struct {
+            /* Order-size of the free chunk this page is the head of. */
+            unsigned int order;
+        } free;
+
+    } v;
+
+    union {
+        /*
+         * Timestamp from 'TLB clock', used to avoid extra safety flushes.
+         * Only valid for: a) free pages, and b) pages with zero type count
+         */
+        u32 tlbflush_timestamp;
+    };
+    u64 pad;
+};
+
+#define PG_shift(idx)   (BITS_PER_LONG - (idx))
+#define PG_mask(x, idx) (x ## UL << PG_shift(idx))
+
+#define PGT_none          PG_mask(0, 4)  /* no special uses of this page   */
+#define PGT_writable_page PG_mask(7, 4)  /* has writable mappings?         */
+#define PGT_shared_page   PG_mask(8, 4)  /* CoW sharable page              */
+#define PGT_type_mask     PG_mask(15, 4) /* Bits 28-31 or 60-63.           */
+
+ /* Owning guest has pinned this page to its current type? */
+#define _PGT_pinned       PG_shift(5)
+#define PGT_pinned        PG_mask(1, 5)
+
+ /* Count of uses of this frame as its current type. */
+#define PGT_count_width   PG_shift(9)
+#define PGT_count_mask    ((1UL<<PGT_count_width)-1)
+
+ /* Cleared when the owning guest 'frees' this page. */
+#define _PGC_allocated    PG_shift(1)
+#define PGC_allocated     PG_mask(1, 1)
+  /* Page is Xen heap? */
+#define _PGC_xen_heap     PG_shift(2)
+#define PGC_xen_heap      PG_mask(1, 2)
+/* ... */
+/* Page is broken? */
+#define _PGC_broken       PG_shift(7)
+#define PGC_broken        PG_mask(1, 7)
+ /* Mutually-exclusive page states: { inuse, offlining, offlined, free }. */
+#define PGC_state         PG_mask(3, 9)
+#define PGC_state_inuse   PG_mask(0, 9)
+#define PGC_state_offlining PG_mask(1, 9)
+#define PGC_state_offlined PG_mask(2, 9)
+#define PGC_state_free    PG_mask(3, 9)
+#define page_state_is(pg, st) (((pg)->count_info&PGC_state) == PGC_state_##st)
+
+/* Count of references to this frame. */
+#define PGC_count_width   PG_shift(9)
+#define PGC_count_mask    ((1UL<<PGC_count_width)-1)
+
+extern unsigned long xenheap_mfn_start, xenheap_mfn_end;
+extern unsigned long xenheap_virt_end;
+
+#define is_xen_heap_page(page) is_xen_heap_mfn(page_to_mfn(page))
+#define is_xen_heap_mfn(mfn) ({                                 \
+    unsigned long _mfn = (mfn);                                 \
+    (_mfn >= xenheap_mfn_start && _mfn < xenheap_mfn_end);      \
+})
+#define is_xen_fixed_mfn(mfn) is_xen_heap_mfn(mfn)
+
+#define page_get_owner(_p)    (_p)->v.inuse.domain
+#define page_set_owner(_p,_d) ((_p)->v.inuse.domain = (_d))
+
+#define maddr_get_owner(ma)   (page_get_owner(maddr_to_page((ma))))
+#define vaddr_get_owner(va)   (page_get_owner(virt_to_page((va))))
+
+#define XENSHARE_writable 0
+#define XENSHARE_readonly 1
+extern void share_xen_page_with_guest(
+    struct page_info *page, struct domain *d, int readonly);
+extern void share_xen_page_with_privileged_guests(
+    struct page_info *page, int readonly);
+
+#define frame_table ((struct page_info *)FRAMETABLE_VIRT_START)
+
+extern unsigned long max_page;
+extern unsigned long total_pages;
+
+/* Boot-time pagetable setup */
+extern void setup_pagetables(unsigned long boot_phys_offset);
+/* Set up the xenheap: up to 1GB of contiguous, always-mapped memory.
+ * Base must be 32MB aligned and size a multiple of 32MB. */
+extern void setup_xenheap_mappings(unsigned long base_mfn, unsigned long nr_mfns);
+/* Map a frame table to cover physical addresses ps through pe */
+extern void setup_frametable_mappings(paddr_t ps, paddr_t pe);
+/* Map a 4k page in a fixmap entry */
+extern void set_fixmap(unsigned map, unsigned long mfn, unsigned attributes);
+/* Remove a mapping from a fixmap entry */
+extern void clear_fixmap(unsigned map);
+
+
+#define mfn_valid(mfn)        ({                                              \
+    unsigned long __m_f_n = (mfn);                                            \
+    likely(__m_f_n < max_page);                                               \
+})
+
+#define max_pdx                 max_page
+/* XXX Assume everything in the 40-bit physical alias 0x8000000000 for now */
+#define pfn_to_pdx(pfn)         ((pfn) - 0x8000000UL)
+#define pdx_to_pfn(pdx)         ((pdx) + 0x8000000UL)
+#define virt_to_pdx(va)         virt_to_mfn(va)
+#define pdx_to_virt(pdx)        mfn_to_virt(pdx)
+
+/* Convert between machine frame numbers and page-info structures. */
+#define mfn_to_page(mfn)  (frame_table + pfn_to_pdx(mfn))
+#define page_to_mfn(pg)   pdx_to_pfn((unsigned long)((pg) - frame_table))
+#define __page_to_mfn(pg)  page_to_mfn(pg)
+#define __mfn_to_page(mfn) mfn_to_page(mfn)
+
+/* Convert between machine addresses and page-info structures. */
+#define maddr_to_page(ma) __mfn_to_page((ma) >> PAGE_SHIFT)
+#define page_to_maddr(pg) ((paddr_t)__page_to_mfn(pg) << PAGE_SHIFT)
+
+/* Convert between frame number and address formats.  */
+#define pfn_to_paddr(pfn) ((paddr_t)(pfn) << PAGE_SHIFT)
+#define paddr_to_pfn(pa)  ((unsigned long)((pa) >> PAGE_SHIFT))
+#define paddr_to_pdx(pa)    pfn_to_pdx(paddr_to_pfn(pa))
+
+
+static inline paddr_t virt_to_maddr(void *va)
+{
+    uint64_t par = va_to_par((uint32_t)va);
+    return (par & PADDR_MASK & PAGE_MASK) | ((unsigned long) va & ~PAGE_MASK);
+}
+
+static inline void *maddr_to_virt(paddr_t ma)
+{
+    ASSERT(is_xen_heap_mfn(ma >> PAGE_SHIFT));
+    ma -= pfn_to_paddr(xenheap_mfn_start);
+    return (void *)(unsigned long) ma + XENHEAP_VIRT_START;
+}
+
+static inline paddr_t gvirt_to_maddr(uint32_t va)
+{
+    uint64_t par = gva_to_par(va);
+    return (par & PADDR_MASK & PAGE_MASK) | ((unsigned long) va & ~PAGE_MASK);
+}
+
+/* Convert between Xen-heap virtual addresses and machine addresses. */
+#define __pa(x)             (virt_to_maddr(x))
+#define __va(x)             (maddr_to_virt(x))
+
+/* Convert between Xen-heap virtual addresses and machine frame numbers. */
+#define virt_to_mfn(va)   (virt_to_maddr(va) >> PAGE_SHIFT)
+#define mfn_to_virt(mfn)  (maddr_to_virt((paddr_t)(mfn) << PAGE_SHIFT))
+
+
+static inline int get_order_from_bytes(paddr_t size)
+{
+    int order;
+    size = (size-1) >> PAGE_SHIFT;
+    for ( order = 0; size; order++ )
+        size >>= 1;
+    return order;
+}
+
+static inline int get_order_from_pages(unsigned long nr_pages)
+{
+    int order;
+    nr_pages--;
+    for ( order = 0; nr_pages; order++ )
+        nr_pages >>= 1;
+    return order;
+}
+
+
+/* Convert between Xen-heap virtual addresses and page-info structures. */
+static inline struct page_info *virt_to_page(const void *v)
+{
+    unsigned long va = (unsigned long)v;
+    ASSERT(va >= XENHEAP_VIRT_START);
+    ASSERT(va < xenheap_virt_end);
+
+    return frame_table + ((va - XENHEAP_VIRT_START) >> PAGE_SHIFT);
+}
+
+static inline void *page_to_virt(const struct page_info *pg)
+{
+    ASSERT((unsigned long)pg - FRAMETABLE_VIRT_START < frametable_virt_end);
+    return (void *)(XENHEAP_VIRT_START +
+                    ((unsigned long)pg - FRAMETABLE_VIRT_START) /
+                    (sizeof(*pg) / (sizeof(*pg) & -sizeof(*pg))) *
+                    (PAGE_SIZE / (sizeof(*pg) & -sizeof(*pg))));
+
+}
+
+struct domain *page_get_owner_and_reference(struct page_info *page);
+void put_page(struct page_info *page);
+int  get_page(struct page_info *page, struct domain *domain);
+
+/*
+ * The MPT (machine->physical mapping table) is an array of word-sized
+ * values, indexed on machine frame number. It is expected that guest OSes
+ * will use it to store a "physical" frame number to give the appearance of
+ * contiguous (or near contiguous) physical memory.
+ */
+#undef  machine_to_phys_mapping
+#define machine_to_phys_mapping  ((unsigned long *)RDWR_MPT_VIRT_START)
+#define INVALID_M2P_ENTRY        (~0UL)
+#define VALID_M2P(_e)            (!((_e) & (1UL<<(BITS_PER_LONG-1))))
+#define SHARED_M2P_ENTRY         (~0UL - 1UL)
+#define SHARED_M2P(_e)           ((_e) == SHARED_M2P_ENTRY)
+
+#define _set_gpfn_from_mfn(mfn, pfn) ({                        \
+    struct domain *d = page_get_owner(__mfn_to_page(mfn));     \
+    if(d && (d == dom_cow))                                    \
+        machine_to_phys_mapping[(mfn)] = SHARED_M2P_ENTRY;     \
+    else                                                       \
+        machine_to_phys_mapping[(mfn)] = (pfn);                \
+    })
+
+#define put_gfn(d, g)   ((void)0)
+
+#define INVALID_MFN             (~0UL)
+
+/* Xen always owns P2M on ARM */
+#define set_gpfn_from_mfn(mfn, pfn) do { (void) (mfn),(pfn); } while (0)
+#define mfn_to_gmfn(_d, mfn)  (mfn)
+
+
+/* Arch-specific portion of memory_op hypercall. */
+long arch_memory_op(int op, XEN_GUEST_HANDLE(void) arg);
+
+int steal_page(
+    struct domain *d, struct page_info *page, unsigned int memflags);
+int donate_page(
+    struct domain *d, struct page_info *page, unsigned int memflags);
+
+#define domain_set_alloc_bitsize(d) ((void)0)
+#define domain_clamp_alloc_bitsize(d, b) (b)
+
+unsigned long domain_get_maximum_gpfn(struct domain *d);
+
+extern struct domain *dom_xen, *dom_io, *dom_cow;
+
+#define memguard_init(_s)              (_s)
+#define memguard_guard_stack(_p)       ((void)0)
+#define memguard_guard_range(_p,_l)    ((void)0)
+#define memguard_unguard_range(_p,_l)  ((void)0)
+int guest_physmap_mark_populate_on_demand(struct domain *d, unsigned long gfn,
+                                          unsigned int order);
+
+extern void put_page_type(struct page_info *page);
+static inline void put_page_and_type(struct page_info *page)
+{
+    put_page_type(page);
+    put_page(page);
+}
+
+#endif /*  __ARCH_ARM_MM__ */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/p2m.h b/xen/include/asm-arm/p2m.h
new file mode 100644
index 0000000..aec52f7
--- /dev/null
+++ b/xen/include/asm-arm/p2m.h
@@ -0,0 +1,88 @@
+#ifndef _XEN_P2M_H
+#define _XEN_P2M_H
+
+#include <xen/mm.h>
+
+struct domain;
+
+/* Per-p2m-table state */
+struct p2m_domain {
+    /* Lock that protects updates to the p2m */
+    spinlock_t lock;
+
+    /* Pages used to construct the p2m */
+    struct page_list_head pages;
+
+    /* Root of p2m page tables, 2 contiguous pages */
+    struct page_info *first_level;
+
+    /* Current VMID in use */
+    uint8_t vmid;
+};
+
+/* Init the datastructures for later use by the p2m code */
+int p2m_init(struct domain *d);
+
+/* Allocate a new p2m table for a domain.
+ *
+ * Returns 0 for success or -errno.
+ */
+int p2m_alloc_table(struct domain *d);
+
+/* */
+void p2m_load_VTTBR(struct domain *d);
+
+/* Setup p2m RAM mapping for domain d from start-end. */
+int p2m_populate_ram(struct domain *d, paddr_t start, paddr_t end);
+/* Map MMIO regions in the p2m: start_gaddr and end_gaddr is the range
+ * in the guest physical address space to map, starting from the machine
+ * address maddr. */
+int map_mmio_regions(struct domain *d, paddr_t start_gaddr,
+                     paddr_t end_gaddr, paddr_t maddr);
+
+unsigned long gmfn_to_mfn(struct domain *d, unsigned long gpfn);
+
+/*
+ * Populate-on-demand
+ */
+
+/* Call when decreasing memory reservation to handle PoD entries properly.
+ * Will return '1' if all entries were handled and nothing more need be done.*/
+int
+p2m_pod_decrease_reservation(struct domain *d,
+                             xen_pfn_t gpfn,
+                             unsigned int order);
+
+/* Compatibility function exporting the old untyped interface */
+static inline unsigned long get_gfn_untyped(struct domain *d, unsigned long gpfn)
+{
+    return gmfn_to_mfn(d, gpfn);
+}
+
+int get_page_type(struct page_info *page, unsigned long type);
+int is_iomem_page(unsigned long mfn);
+static inline int get_page_and_type(struct page_info *page,
+                                    struct domain *domain,
+                                    unsigned long type)
+{
+    int rc = get_page(page, domain);
+
+    if ( likely(rc) && unlikely(!get_page_type(page, type)) )
+    {
+        put_page(page);
+        rc = 0;
+    }
+
+    return rc;
+}
+
+#endif /* _XEN_P2M_H */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/page.h b/xen/include/asm-arm/page.h
new file mode 100644
index 0000000..6dc1659
--- /dev/null
+++ b/xen/include/asm-arm/page.h
@@ -0,0 +1,335 @@
+#ifndef __ARM_PAGE_H__
+#define __ARM_PAGE_H__
+
+#include <xen/config.h>
+
+#define PADDR_BITS              40
+#define PADDR_MASK              ((1ULL << PADDR_BITS)-1)
+
+#define VADDR_BITS              32
+#define VADDR_MASK              (~0UL)
+
+/* Shareability values for the LPAE entries */
+#define LPAE_SH_NON_SHAREABLE 0x0
+#define LPAE_SH_UNPREDICTALE  0x1
+#define LPAE_SH_OUTER         0x2
+#define LPAE_SH_INNER         0x3
+
+/* LPAE Memory region attributes, to match Linux's (non-LPAE) choices.
+ * Indexed by the AttrIndex bits of a LPAE entry;
+ * the 8-bit fields are packed little-endian into MAIR0 and MAIR1
+ *
+ *                 ai    encoding
+ *   UNCACHED      000   0000 0000  -- Strongly Ordered
+ *   BUFFERABLE    001   0100 0100  -- Non-Cacheable
+ *   WRITETHROUGH  010   1010 1010  -- Write-through
+ *   WRITEBACK     011   1110 1110  -- Write-back
+ *   DEV_SHARED    100   0000 0100  -- Device
+ *   ??            101
+ *   reserved      110
+ *   WRITEALLOC    111   1111 1111  -- Write-back write-allocate
+ *
+ *   DEV_NONSHARED 100   (== DEV_SHARED)
+ *   DEV_WC        001   (== BUFFERABLE)
+ *   DEV_CACHED    011   (== WRITEBACK)
+ */
+#define MAIR0VAL 0xeeaa4400
+#define MAIR1VAL 0xff000004
+
+#define UNCACHED      0x0
+#define BUFFERABLE    0x1
+#define WRITETHROUGH  0x2
+#define WRITEBACK     0x3
+#define DEV_SHARED    0x4
+#define WRITEALLOC    0x7
+#define DEV_NONSHARED DEV_SHARED
+#define DEV_WC        BUFFERABLE
+#define DEV_CACHED    WRITEBACK
+
+
+#ifndef __ASSEMBLY__
+
+#include <xen/types.h>
+#include <xen/lib.h>
+
+/* WARNING!  Unlike the Intel pagetable code, where l1 is the lowest
+ * level and l4 is the root of the trie, the ARM pagetables follow ARM's
+ * documentation: the levels are called first, second &c in the order
+ * that the MMU walks them (i.e. "first" is the root of the trie). */
+
+/******************************************************************************
+ * ARMv7-A LPAE pagetables: 3-level trie, mapping 40-bit input to
+ * 40-bit output addresses.  Tables at all levels have 512 64-bit entries
+ * (i.e. are 4Kb long).
+ *
+ * The bit-shuffling that has the permission bits in branch nodes in a
+ * different place from those in leaf nodes seems to be to allow linear
+ * pagetable tricks.  If we're not doing that then the set of permission
+ * bits that's not in use in a given node type can be used as
+ * extra software-defined bits. */
+
+typedef struct {
+    /* These are used in all kinds of entry. */
+    unsigned long valid:1;      /* Valid mapping */
+    unsigned long table:1;      /* == 1 in 4k map entries too */
+
+    /* These ten bits are only used in Block entries and are ignored
+     * in Table entries. */
+    unsigned long ai:3;         /* Attribute Index */
+    unsigned long ns:1;         /* Not-Secure */
+    unsigned long user:1;       /* User-visible */
+    unsigned long ro:1;         /* Read-Only */
+    unsigned long sh:2;         /* Shareability */
+    unsigned long af:1;         /* Access Flag */
+    unsigned long ng:1;         /* Not-Global */
+
+    /* The base address must be approprately aligned for Block entries */
+    unsigned long base:28;      /* Base address of block or next table */
+    unsigned long sbz:12;       /* Must be zero */
+
+    /* These seven bits are only used in Block entries and are ignored
+     * in Table entries. */
+    unsigned long hint:1;       /* In a block of 16 contiguous entries */
+    unsigned long pxn:1;        /* Privileged-XN */
+    unsigned long xn:1;         /* eXecute-Never */
+    unsigned long avail:4;      /* Ignored by hardware */
+
+    /* These 5 bits are only used in Table entries and are ignored in
+     * Block entries */
+    unsigned long pxnt:1;       /* Privileged-XN */
+    unsigned long xnt:1;        /* eXecute-Never */
+    unsigned long apt:2;        /* Access Permissions */
+    unsigned long nst:1;        /* Not-Secure */
+} __attribute__((__packed__)) lpae_pt_t;
+
+/* The p2m tables have almost the same layout, but some of the permission
+ * and cache-control bits are laid out differently (or missing) */
+typedef struct {
+    /* These are used in all kinds of entry. */
+    unsigned long valid:1;      /* Valid mapping */
+    unsigned long table:1;      /* == 1 in 4k map entries too */
+
+    /* These ten bits are only used in Block entries and are ignored
+     * in Table entries. */
+    unsigned long mattr:4;      /* Memory Attributes */
+    unsigned long read:1;       /* Read access */
+    unsigned long write:1;      /* Write access */
+    unsigned long sh:2;         /* Shareability */
+    unsigned long af:1;         /* Access Flag */
+    unsigned long sbz4:1;
+
+    /* The base address must be approprately aligned for Block entries */
+    unsigned long base:28;      /* Base address of block or next table */
+    unsigned long sbz3:12;
+
+    /* These seven bits are only used in Block entries and are ignored
+     * in Table entries. */
+    unsigned long hint:1;       /* In a block of 16 contiguous entries */
+    unsigned long sbz2:1;
+    unsigned long xn:1;         /* eXecute-Never */
+    unsigned long avail:4;      /* Ignored by hardware */
+
+    unsigned long sbz1:5;
+} __attribute__((__packed__)) lpae_p2m_t;
+
+typedef union {
+    uint64_t bits;
+    lpae_pt_t pt;
+    lpae_p2m_t p2m;
+} lpae_t;
+
+/* Standard entry type that we'll use to build Xen's own pagetables.
+ * We put the same permissions at every level, because they're ignored
+ * by the walker in non-leaf entries. */
+static inline lpae_t mfn_to_xen_entry(unsigned long mfn)
+{
+    paddr_t pa = ((paddr_t) mfn) << PAGE_SHIFT;
+    lpae_t e = (lpae_t) {
+        .pt = {
+            .xn = 1,              /* No need to execute outside .text */
+            .ng = 1,              /* Makes TLB flushes easier */
+            .af = 1,              /* No need for access tracking */
+            .sh = LPAE_SH_OUTER,  /* Xen mappings are globally coherent */
+            .ns = 1,              /* Hyp mode is in the non-secure world */
+            .user = 1,            /* See below */
+            .ai = WRITEALLOC,
+            .table = 0,           /* Set to 1 for links and 4k maps */
+            .valid = 1,           /* Mappings are present */
+        }};;
+    /* Setting the User bit is strange, but the ATS1H[RW] instructions
+     * don't seem to work otherwise, and since we never run on Xen
+     * pagetables un User mode it's OK.  If this changes, remember
+     * to update the hard-coded values in head.S too */
+
+    ASSERT(!(pa & ~PAGE_MASK));
+    ASSERT(!(pa & ~PADDR_MASK));
+
+    // XXX shifts
+    e.bits |= pa;
+    return e;
+}
+
+static inline lpae_t mfn_to_p2m_entry(unsigned long mfn)
+{
+    paddr_t pa = ((paddr_t) mfn) << PAGE_SHIFT;
+    lpae_t e = (lpae_t) {
+        .p2m.xn = 0,
+        .p2m.af = 1,
+        .p2m.sh = LPAE_SH_OUTER,
+        .p2m.write = 1,
+        .p2m.read = 1,
+        .p2m.mattr = 0xf,
+        .p2m.table = 1,
+        .p2m.valid = 1,
+    };
+
+    ASSERT(!(pa & ~PAGE_MASK));
+    ASSERT(!(pa & ~PADDR_MASK));
+
+    e.bits |= pa;
+
+    return e;
+}
+
+/* Write a pagetable entry */
+static inline void write_pte(lpae_t *p, lpae_t pte)
+{
+    asm volatile (
+        /* Safely write the entry (STRD is atomic on CPUs that support LPAE) */
+        "strd %0, %H0, [%1];"
+        /* Push this cacheline to the PoC so the rest of the system sees it. */
+        STORE_CP32(1, DCCMVAC)
+        : : "r" (pte.bits), "r" (p) : "memory");
+}
+
+/*
+ * Flush all hypervisor mappings from the data TLB. This is not
+ * sufficient when changing code mappings or for self modifying code.
+ */
+static inline void flush_xen_data_tlb(void)
+{
+    register unsigned long r0 asm ("r0");
+    asm volatile("dsb;" /* Ensure preceding are visible */
+                 STORE_CP32(0, TLBIALLH)
+                 "dsb;" /* Ensure completion of the TLB flush */
+                 "isb;"
+                 : : "r" (r0) /* dummy */: "memory");
+}
+
+/*
+ * Flush one VA's hypervisor mappings from the data TLB. This is not
+ * sufficient when changing code mappings or for self modifying code.
+ */
+static inline void flush_xen_data_tlb_va(unsigned long va)
+{
+    asm volatile("dsb;" /* Ensure preceding are visible */
+                 STORE_CP32(0, TLBIMVAH)
+                 "dsb;" /* Ensure completion of the TLB flush */
+                 "isb;"
+                 : : "r" (va) : "memory");
+}
+
+/* Flush all non-hypervisor mappings from the TLB */
+static inline void flush_guest_tlb(void)
+{
+    register unsigned long r0 asm ("r0");
+    WRITE_CP32(r0 /* dummy */, TLBIALLNSNH);
+}
+
+/* Ask the MMU to translate a VA for us */
+static inline uint64_t __va_to_par(uint32_t va)
+{
+    uint64_t par, tmp;
+    tmp = READ_CP64(PAR);
+    WRITE_CP32(va, ATS1HR);
+    isb(); /* Ensure result is available. */
+    par = READ_CP64(PAR);
+    WRITE_CP64(tmp, PAR);
+    return par;
+}
+
+static inline uint64_t va_to_par(uint32_t va)
+{
+    uint64_t par = __va_to_par(va);
+    /* It is not OK to call this with an invalid VA */
+    if ( par & PAR_F ) panic_PAR(par, "Hypervisor");
+    return par;
+}
+
+/* Ask the MMU to translate a Guest VA for us */
+static inline uint64_t __gva_to_par(uint32_t va)
+{
+    uint64_t par, tmp;
+    tmp = READ_CP64(PAR);
+    WRITE_CP32(va, ATS12NSOPR);
+    isb(); /* Ensure result is available. */
+    par = READ_CP64(PAR);
+    WRITE_CP64(tmp, PAR);
+    return par;
+}
+static inline uint64_t gva_to_par(uint32_t va)
+{
+    uint64_t par = __gva_to_par(va);
+    /* It is not OK to call this with an invalid VA */
+    /* XXX harsh for a guest address... */
+    if ( par & PAR_F ) panic_PAR(par, "Guest");
+    return par;
+}
+static inline uint64_t __gva_to_ipa(uint32_t va)
+{
+    uint64_t par, tmp;
+    tmp = READ_CP64(PAR);
+    WRITE_CP32(va, ATS1CPR);
+    isb(); /* Ensure result is available. */
+    par = READ_CP64(PAR);
+    WRITE_CP64(tmp, PAR);
+    return par;
+}
+static inline uint64_t gva_to_ipa(uint32_t va)
+{
+    uint64_t par = __gva_to_ipa(va);
+    /* It is not OK to call this with an invalid VA */
+    /* XXX harsh for a guest address... */
+    if ( par & PAR_F ) panic_PAR(par, "Guest");
+    return (par & PADDR_MASK & PAGE_MASK) | ((unsigned long) va & ~PAGE_MASK);
+}
+/* Bits in the PAR returned by va_to_par */
+#define PAR_FAULT 0x1
+
+#endif /* __ASSEMBLY__ */
+
+/* These numbers add up to a 39-bit input address space.  The  ARMv7-A
+ * architecture actually specifies a 40-bit input address space for the p2m,
+ * with an 8K (1024-entry) top-level table. */
+
+#define LPAE_SHIFT      9
+#define LPAE_ENTRIES    (1u << LPAE_SHIFT)
+#define LPAE_ENTRY_MASK (LPAE_ENTRIES - 1)
+
+#define THIRD_SHIFT  PAGE_SHIFT
+#define SECOND_SHIFT (THIRD_SHIFT + LPAE_SHIFT)
+#define FIRST_SHIFT  (SECOND_SHIFT + LPAE_SHIFT)
+
+/* Calculate the offsets into the pagetables for a given VA */
+#define first_linear_offset(va) (va >> FIRST_SHIFT)
+#define second_linear_offset(va) (va >> SECOND_SHIFT)
+#define third_linear_offset(va) (va >> THIRD_SHIFT)
+#define first_table_offset(va) (first_linear_offset(va))
+#define second_table_offset(va) (second_linear_offset(va) & LPAE_ENTRY_MASK)
+#define third_table_offset(va) (third_linear_offset(va) & LPAE_ENTRY_MASK)
+
+#define clear_page(page)memset((void *)(page), 0, PAGE_SIZE)
+
+#define PAGE_ALIGN(x) (((x) + PAGE_SIZE - 1) & PAGE_MASK)
+
+#endif /* __ARM_PAGE_H__ */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 16:29:35 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 16:29:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbEBa-0002QL-0H; Thu, 15 Dec 2011 16:29:34 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RbEBY-0002F8-33
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 16:29:32 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1323966525!56866011!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDY5Mjg=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17340 invoked from network); 15 Dec 2011 16: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;
	15 Dec 2011 16:28:50 -0000
X-IronPort-AV: E=Sophos;i="4.71,357,1320642000"; d="scan'208";a="20001875"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Dec 2011 11:29:25 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Thu, 15 Dec 2011 11:29:24 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pBFGSMtm003330;
	Thu, 15 Dec 2011 08:29:12 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Thu, 15 Dec 2011 16:30:56 +0000
Message-ID: <1323966657-19790-24-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1112131831560.3517@kaball-desktop>
References: <alpine.DEB.2.00.1112131831560.3517@kaball-desktop>
MIME-Version: 1.0
Cc: keir.xen@gmail.com, Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, JBeulich@suse.com,
	Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v3 24/25] arm: vtimer
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Emulation of the generic timer kernel registers.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
---
 xen/arch/arm/domain.c        |    4 +
 xen/arch/arm/traps.c         |    4 +-
 xen/arch/arm/vtimer.c        |  148 ++++++++++++++++++++++++++++++++++++++++++
 xen/arch/arm/vtimer.h        |   35 ++++++++++
 xen/include/asm-arm/domain.h |    7 ++
 5 files changed, 196 insertions(+), 2 deletions(-)
 create mode 100644 xen/arch/arm/vtimer.c
 create mode 100644 xen/arch/arm/vtimer.h

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 7e681ab..70f71c3 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -12,6 +12,7 @@
 #include <asm/irq.h>
 
 #include "gic.h"
+#include "vtimer.h"
 
 DEFINE_PER_CPU(struct vcpu *, curr_vcpu);
 
@@ -215,6 +216,9 @@ int vcpu_initialise(struct vcpu *v)
     if ( (rc = vcpu_vgic_init(v)) != 0 )
         return rc;
 
+    if ( (rc = vcpu_vtimer_init(v)) != 0 )
+        return rc;
+
     return rc;
 }
 
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 4346dd7..395d0af 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -468,7 +468,7 @@ static void do_cp15_32(struct cpu_user_regs *regs,
         break;
     case HSR_CPREG32(CNTP_CTL):
     case HSR_CPREG32(CNTP_TVAL):
-        /* emulate timer */
+        BUG_ON(!vtimer_emulate(regs, hsr));
         break;
     default:
         printk("%s p15, %d, r%d, cr%d, cr%d, %d @ %#08x\n",
@@ -498,7 +498,7 @@ static void do_cp15_64(struct cpu_user_regs *regs,
     switch ( hsr.bits & HSR_CP64_REGS_MASK )
     {
     case HSR_CPREG64(CNTPCT):
-        /* emulate timer */
+        BUG_ON(!vtimer_emulate(regs, hsr));
         break;
     default:
         printk("%s p15, %d, r%d, r%d, cr%d @ %#08x\n",
diff --git a/xen/arch/arm/vtimer.c b/xen/arch/arm/vtimer.c
new file mode 100644
index 0000000..3ebf5b1
--- /dev/null
+++ b/xen/arch/arm/vtimer.c
@@ -0,0 +1,148 @@
+/*
+ * xen/arch/arm/vtimer.c
+ *
+ * ARM Virtual Timer emulation support
+ *
+ * Ian Campbell <ian.campbell@citrix.com>
+ * Copyright (c) 2011 Citrix Systems.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include <xen/config.h>
+#include <xen/lib.h>
+#include <xen/timer.h>
+#include <xen/sched.h>
+#include "gic.h"
+
+extern s_time_t ticks_to_ns(uint64_t ticks);
+extern uint64_t ns_to_ticks(s_time_t ns);
+
+static void vtimer_expired(void *data)
+{
+    struct vcpu *v = data;
+    v->arch.vtimer.ctl |= CNTx_CTL_PENDING;
+    v->arch.vtimer.ctl &= ~CNTx_CTL_MASK;
+    vgic_vcpu_inject_irq(v, 30, 1);
+}
+
+int vcpu_vtimer_init(struct vcpu *v)
+{
+    init_timer(&v->arch.vtimer.timer,
+               vtimer_expired, v,
+               smp_processor_id());
+    v->arch.vtimer.ctl = 0;
+    v->arch.vtimer.offset = NOW();
+    v->arch.vtimer.cval = NOW();
+    return 0;
+}
+
+static int vtimer_emulate_32(struct cpu_user_regs *regs, union hsr hsr)
+{
+    struct vcpu *v = current;
+    struct hsr_cp32 cp32 = hsr.cp32;
+    uint32_t *r = &regs->r0 + cp32.reg;
+    s_time_t now;
+
+    switch ( hsr.bits & HSR_CP32_REGS_MASK )
+    {
+    case HSR_CPREG32(CNTP_CTL):
+        if ( cp32.read )
+        {
+            *r = v->arch.vtimer.ctl;
+        }
+        else
+        {
+            v->arch.vtimer.ctl = *r;
+
+            if ( v->arch.vtimer.ctl & CNTx_CTL_ENABLE )
+            {
+                set_timer(&v->arch.vtimer.timer,
+                          v->arch.vtimer.cval + v->arch.vtimer.offset);
+            }
+            else
+                stop_timer(&v->arch.vtimer.timer);
+        }
+
+        return 1;
+
+    case HSR_CPREG32(CNTP_TVAL):
+        now = NOW() - v->arch.vtimer.offset;
+        if ( cp32.read )
+        {
+            *r = (uint32_t)(ns_to_ticks(v->arch.vtimer.cval - now) & 0xffffffffull);
+        }
+        else
+	{
+            v->arch.vtimer.cval = now + ticks_to_ns(*r);
+	    if ( v->arch.vtimer.ctl & CNTx_CTL_ENABLE )
+            {
+                set_timer(&v->arch.vtimer.timer,
+                          v->arch.vtimer.cval + v->arch.vtimer.offset);
+            }
+        }
+
+        return 1;
+
+    default:
+        return 0;
+    }
+}
+
+static int vtimer_emulate_64(struct cpu_user_regs *regs, union hsr hsr)
+{
+    struct vcpu *v = current;
+    struct hsr_cp64 cp64 = hsr.cp64;
+    uint32_t *r1 = &regs->r0 + cp64.reg1;
+    uint32_t *r2 = &regs->r0 + cp64.reg2;
+    s_time_t now;
+
+    switch ( hsr.bits & HSR_CP64_REGS_MASK )
+    {
+    case HSR_CPREG64(CNTPCT):
+        if ( cp64.read )
+        {
+            now = NOW() - v->arch.vtimer.offset;
+            *r1 = (uint32_t)(now & 0xffffffff);
+            *r2 = (uint32_t)(now >> 32);
+            return 1;
+        }
+        else
+        {
+            printk("READ from R/O CNTPCT\n");
+            return 0;
+        }
+
+    default:
+        return 0;
+    }
+}
+
+int vtimer_emulate(struct cpu_user_regs *regs, union hsr hsr)
+{
+    switch (hsr.ec) {
+    case HSR_EC_CP15_32:
+        return vtimer_emulate_32(regs, hsr);
+    case HSR_EC_CP15_64:
+        return vtimer_emulate_64(regs, hsr);
+    default:
+        return 0;
+    }
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/arch/arm/vtimer.h b/xen/arch/arm/vtimer.h
new file mode 100644
index 0000000..d87bb25
--- /dev/null
+++ b/xen/arch/arm/vtimer.h
@@ -0,0 +1,35 @@
+/*
+ * xen/arch/arm/vtimer.h
+ *
+ * ARM Virtual Timer emulation support
+ *
+ * Ian Campbell <ian.campbell@citrix.com>
+ * Copyright (c) 2011 Citrix Systems.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#ifndef __ARCH_ARM_VTIMER_H__
+#define __ARCH_ARM_VTIMER_H__
+
+extern int vcpu_vtimer_init(struct vcpu *v);
+extern int vtimer_emulate(struct cpu_user_regs *regs, union hsr hsr);
+
+#endif
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
index 2cd0bd3..3372d14 100644
--- a/xen/include/asm-arm/domain.h
+++ b/xen/include/asm-arm/domain.h
@@ -57,6 +57,13 @@ struct arch_vcpu
         struct list_head inflight_irqs;
         spinlock_t lock;
     } vgic;
+
+    struct {
+        struct timer timer;
+        uint32_t ctl;
+        s_time_t offset;
+        s_time_t cval;
+    } vtimer;
 }  __cacheline_aligned;
 
 void vcpu_show_execution_state(struct vcpu *);
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 16:29:35 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 16:29:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbEBa-0002QL-0H; Thu, 15 Dec 2011 16:29:34 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RbEBY-0002F8-33
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 16:29:32 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1323966525!56866011!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDY5Mjg=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17340 invoked from network); 15 Dec 2011 16: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;
	15 Dec 2011 16:28:50 -0000
X-IronPort-AV: E=Sophos;i="4.71,357,1320642000"; d="scan'208";a="20001875"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Dec 2011 11:29:25 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Thu, 15 Dec 2011 11:29:24 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pBFGSMtm003330;
	Thu, 15 Dec 2011 08:29:12 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Thu, 15 Dec 2011 16:30:56 +0000
Message-ID: <1323966657-19790-24-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1112131831560.3517@kaball-desktop>
References: <alpine.DEB.2.00.1112131831560.3517@kaball-desktop>
MIME-Version: 1.0
Cc: keir.xen@gmail.com, Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, JBeulich@suse.com,
	Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v3 24/25] arm: vtimer
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Emulation of the generic timer kernel registers.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
---
 xen/arch/arm/domain.c        |    4 +
 xen/arch/arm/traps.c         |    4 +-
 xen/arch/arm/vtimer.c        |  148 ++++++++++++++++++++++++++++++++++++++++++
 xen/arch/arm/vtimer.h        |   35 ++++++++++
 xen/include/asm-arm/domain.h |    7 ++
 5 files changed, 196 insertions(+), 2 deletions(-)
 create mode 100644 xen/arch/arm/vtimer.c
 create mode 100644 xen/arch/arm/vtimer.h

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 7e681ab..70f71c3 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -12,6 +12,7 @@
 #include <asm/irq.h>
 
 #include "gic.h"
+#include "vtimer.h"
 
 DEFINE_PER_CPU(struct vcpu *, curr_vcpu);
 
@@ -215,6 +216,9 @@ int vcpu_initialise(struct vcpu *v)
     if ( (rc = vcpu_vgic_init(v)) != 0 )
         return rc;
 
+    if ( (rc = vcpu_vtimer_init(v)) != 0 )
+        return rc;
+
     return rc;
 }
 
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 4346dd7..395d0af 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -468,7 +468,7 @@ static void do_cp15_32(struct cpu_user_regs *regs,
         break;
     case HSR_CPREG32(CNTP_CTL):
     case HSR_CPREG32(CNTP_TVAL):
-        /* emulate timer */
+        BUG_ON(!vtimer_emulate(regs, hsr));
         break;
     default:
         printk("%s p15, %d, r%d, cr%d, cr%d, %d @ %#08x\n",
@@ -498,7 +498,7 @@ static void do_cp15_64(struct cpu_user_regs *regs,
     switch ( hsr.bits & HSR_CP64_REGS_MASK )
     {
     case HSR_CPREG64(CNTPCT):
-        /* emulate timer */
+        BUG_ON(!vtimer_emulate(regs, hsr));
         break;
     default:
         printk("%s p15, %d, r%d, r%d, cr%d @ %#08x\n",
diff --git a/xen/arch/arm/vtimer.c b/xen/arch/arm/vtimer.c
new file mode 100644
index 0000000..3ebf5b1
--- /dev/null
+++ b/xen/arch/arm/vtimer.c
@@ -0,0 +1,148 @@
+/*
+ * xen/arch/arm/vtimer.c
+ *
+ * ARM Virtual Timer emulation support
+ *
+ * Ian Campbell <ian.campbell@citrix.com>
+ * Copyright (c) 2011 Citrix Systems.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include <xen/config.h>
+#include <xen/lib.h>
+#include <xen/timer.h>
+#include <xen/sched.h>
+#include "gic.h"
+
+extern s_time_t ticks_to_ns(uint64_t ticks);
+extern uint64_t ns_to_ticks(s_time_t ns);
+
+static void vtimer_expired(void *data)
+{
+    struct vcpu *v = data;
+    v->arch.vtimer.ctl |= CNTx_CTL_PENDING;
+    v->arch.vtimer.ctl &= ~CNTx_CTL_MASK;
+    vgic_vcpu_inject_irq(v, 30, 1);
+}
+
+int vcpu_vtimer_init(struct vcpu *v)
+{
+    init_timer(&v->arch.vtimer.timer,
+               vtimer_expired, v,
+               smp_processor_id());
+    v->arch.vtimer.ctl = 0;
+    v->arch.vtimer.offset = NOW();
+    v->arch.vtimer.cval = NOW();
+    return 0;
+}
+
+static int vtimer_emulate_32(struct cpu_user_regs *regs, union hsr hsr)
+{
+    struct vcpu *v = current;
+    struct hsr_cp32 cp32 = hsr.cp32;
+    uint32_t *r = &regs->r0 + cp32.reg;
+    s_time_t now;
+
+    switch ( hsr.bits & HSR_CP32_REGS_MASK )
+    {
+    case HSR_CPREG32(CNTP_CTL):
+        if ( cp32.read )
+        {
+            *r = v->arch.vtimer.ctl;
+        }
+        else
+        {
+            v->arch.vtimer.ctl = *r;
+
+            if ( v->arch.vtimer.ctl & CNTx_CTL_ENABLE )
+            {
+                set_timer(&v->arch.vtimer.timer,
+                          v->arch.vtimer.cval + v->arch.vtimer.offset);
+            }
+            else
+                stop_timer(&v->arch.vtimer.timer);
+        }
+
+        return 1;
+
+    case HSR_CPREG32(CNTP_TVAL):
+        now = NOW() - v->arch.vtimer.offset;
+        if ( cp32.read )
+        {
+            *r = (uint32_t)(ns_to_ticks(v->arch.vtimer.cval - now) & 0xffffffffull);
+        }
+        else
+	{
+            v->arch.vtimer.cval = now + ticks_to_ns(*r);
+	    if ( v->arch.vtimer.ctl & CNTx_CTL_ENABLE )
+            {
+                set_timer(&v->arch.vtimer.timer,
+                          v->arch.vtimer.cval + v->arch.vtimer.offset);
+            }
+        }
+
+        return 1;
+
+    default:
+        return 0;
+    }
+}
+
+static int vtimer_emulate_64(struct cpu_user_regs *regs, union hsr hsr)
+{
+    struct vcpu *v = current;
+    struct hsr_cp64 cp64 = hsr.cp64;
+    uint32_t *r1 = &regs->r0 + cp64.reg1;
+    uint32_t *r2 = &regs->r0 + cp64.reg2;
+    s_time_t now;
+
+    switch ( hsr.bits & HSR_CP64_REGS_MASK )
+    {
+    case HSR_CPREG64(CNTPCT):
+        if ( cp64.read )
+        {
+            now = NOW() - v->arch.vtimer.offset;
+            *r1 = (uint32_t)(now & 0xffffffff);
+            *r2 = (uint32_t)(now >> 32);
+            return 1;
+        }
+        else
+        {
+            printk("READ from R/O CNTPCT\n");
+            return 0;
+        }
+
+    default:
+        return 0;
+    }
+}
+
+int vtimer_emulate(struct cpu_user_regs *regs, union hsr hsr)
+{
+    switch (hsr.ec) {
+    case HSR_EC_CP15_32:
+        return vtimer_emulate_32(regs, hsr);
+    case HSR_EC_CP15_64:
+        return vtimer_emulate_64(regs, hsr);
+    default:
+        return 0;
+    }
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/arch/arm/vtimer.h b/xen/arch/arm/vtimer.h
new file mode 100644
index 0000000..d87bb25
--- /dev/null
+++ b/xen/arch/arm/vtimer.h
@@ -0,0 +1,35 @@
+/*
+ * xen/arch/arm/vtimer.h
+ *
+ * ARM Virtual Timer emulation support
+ *
+ * Ian Campbell <ian.campbell@citrix.com>
+ * Copyright (c) 2011 Citrix Systems.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#ifndef __ARCH_ARM_VTIMER_H__
+#define __ARCH_ARM_VTIMER_H__
+
+extern int vcpu_vtimer_init(struct vcpu *v);
+extern int vtimer_emulate(struct cpu_user_regs *regs, union hsr hsr);
+
+#endif
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
index 2cd0bd3..3372d14 100644
--- a/xen/include/asm-arm/domain.h
+++ b/xen/include/asm-arm/domain.h
@@ -57,6 +57,13 @@ struct arch_vcpu
         struct list_head inflight_irqs;
         spinlock_t lock;
     } vgic;
+
+    struct {
+        struct timer timer;
+        uint32_t ctl;
+        s_time_t offset;
+        s_time_t cval;
+    } vtimer;
 }  __cacheline_aligned;
 
 void vcpu_show_execution_state(struct vcpu *);
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 16:29:37 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 16:29:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbEBa-0002RA-GR; Thu, 15 Dec 2011 16:29:34 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RbEBY-0002G6-JE
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 16:29:33 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1323966564!7053019!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjE2NDg=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22728 invoked from network); 15 Dec 2011 16:29:25 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 16:29:25 -0000
X-IronPort-AV: E=Sophos;i="4.71,357,1320642000"; d="scan'208";a="174308262"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Dec 2011 11:29:23 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Thu, 15 Dec 2011 11:29:22 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pBFGSMtl003330;
	Thu, 15 Dec 2011 08:29:10 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Thu, 15 Dec 2011 16:30:55 +0000
Message-ID: <1323966657-19790-23-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1112131831560.3517@kaball-desktop>
References: <alpine.DEB.2.00.1112131831560.3517@kaball-desktop>
MIME-Version: 1.0
Cc: keir.xen@gmail.com, Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, JBeulich@suse.com,
	Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v3 23/25] arm: vgic emulation
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

- emulation of the GICD interface for the guest;

- interrupt injection into the guest;

- keep track of inflight irqs using a list, ordered by priority.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
---
 xen/arch/arm/domain.c        |    6 +
 xen/arch/arm/gic.h           |    3 +
 xen/arch/arm/io.c            |    1 +
 xen/arch/arm/io.h            |    2 +
 xen/arch/arm/irq.c           |    3 +-
 xen/arch/arm/vgic.c          |  605 ++++++++++++++++++++++++++++++++++++++++++
 xen/include/asm-arm/domain.h |   30 ++
 7 files changed, 649 insertions(+), 1 deletions(-)
 create mode 100644 xen/arch/arm/vgic.c

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 0844b37..7e681ab 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -212,6 +212,9 @@ int vcpu_initialise(struct vcpu *v)
 {
     int rc = 0;
 
+    if ( (rc = vcpu_vgic_init(v)) != 0 )
+        return rc;
+
     return rc;
 }
 
@@ -230,6 +233,9 @@ int arch_domain_create(struct domain *d, unsigned int domcr_flags)
 
     d->max_vcpus = 8;
 
+    if ( (rc = domain_vgic_init(d)) != 0 )
+        goto fail;
+
     rc = 0;
 fail:
     return rc;
diff --git a/xen/arch/arm/gic.h b/xen/arch/arm/gic.h
index 63b6648..81c388d 100644
--- a/xen/arch/arm/gic.h
+++ b/xen/arch/arm/gic.h
@@ -121,6 +121,9 @@
 #define GICH_LR_CPUID_SHIFT     9
 #define GICH_VTR_NRLRGS         0x3f
 
+extern int domain_vgic_init(struct domain *d);
+extern int vcpu_vgic_init(struct vcpu *v);
+extern void vgic_vcpu_inject_irq(struct vcpu *v, unsigned int irq,int virtual);
 extern struct pending_irq *irq_to_pending(struct vcpu *v, unsigned int irq);
 
 extern void gic_route_irqs(void);
diff --git a/xen/arch/arm/io.c b/xen/arch/arm/io.c
index 8789705..4461225 100644
--- a/xen/arch/arm/io.c
+++ b/xen/arch/arm/io.c
@@ -24,6 +24,7 @@
 
 static const struct mmio_handler *const mmio_handlers[] =
 {
+    &vgic_distr_mmio_handler,
 };
 #define MMIO_HANDLER_NR ARRAY_SIZE(mmio_handlers)
 
diff --git a/xen/arch/arm/io.h b/xen/arch/arm/io.h
index d7847e3..8cc5ca7 100644
--- a/xen/arch/arm/io.h
+++ b/xen/arch/arm/io.h
@@ -39,6 +39,8 @@ struct mmio_handler {
     mmio_write_t write_handler;
 };
 
+extern const struct mmio_handler vgic_distr_mmio_handler;
+
 extern int handle_mmio(mmio_info_t *info);
 
 #endif
diff --git a/xen/arch/arm/irq.c b/xen/arch/arm/irq.c
index 5663762..7820310 100644
--- a/xen/arch/arm/irq.c
+++ b/xen/arch/arm/irq.c
@@ -136,7 +136,8 @@ void do_IRQ(struct cpu_user_regs *regs, unsigned int irq, int is_fiq)
 
         desc->status |= IRQ_INPROGRESS;
 
-        /* XXX: inject irq into the guest */
+        /* XXX: inject irq into all guest vcpus */
+        vgic_vcpu_inject_irq(d->vcpu[0], irq, 0);
         goto out_no_end;
     }
 
diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
new file mode 100644
index 0000000..26eae55
--- /dev/null
+++ b/xen/arch/arm/vgic.c
@@ -0,0 +1,605 @@
+/*
+ * xen/arch/arm/vgic.c
+ *
+ * ARM Virtual Generic Interrupt Controller support
+ *
+ * Ian Campbell <ian.campbell@citrix.com>
+ * Copyright (c) 2011 Citrix Systems.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include <xen/config.h>
+#include <xen/lib.h>
+#include <xen/init.h>
+#include <xen/softirq.h>
+#include <xen/irq.h>
+#include <xen/sched.h>
+
+#include <asm/current.h>
+
+#include "io.h"
+#include "gic.h"
+
+#define VGIC_DISTR_BASE_ADDRESS 0x000000002c001000
+
+#define REG(n) (n/4)
+
+/* Number of ranks of interrupt registers for a domain */
+#define DOMAIN_NR_RANKS(d) (((d)->arch.vgic.nr_lines+31)/32)
+
+/*
+ * Rank containing GICD_<FOO><n> for GICD_<FOO> with
+ * <b>-bits-per-interrupt
+ */
+static inline int REG_RANK_NR(int b, uint32_t n)
+{
+    switch ( b )
+    {
+    case 8: return n >> 3;
+    case 4: return n >> 2;
+    case 2: return n >> 1;
+    default: BUG();
+    }
+}
+
+/*
+ * Offset of GICD_<FOO><n> with its rank, for GICD_<FOO> with
+ * <b>-bits-per-interrupt.
+ */
+#define REG_RANK_INDEX(b, n) ((n) & ((b)-1))
+
+/*
+ * Returns rank corresponding to a GICD_<FOO><n> register for
+ * GICD_<FOO> with <b>-bits-per-interrupt.
+ */
+static struct vgic_irq_rank *vgic_irq_rank(struct vcpu *v, int b, int n)
+{
+    int rank = REG_RANK_NR(b, n);
+
+    if ( rank == 0 )
+        return &v->arch.vgic.private_irqs;
+    else if ( rank <= DOMAIN_NR_RANKS(v->domain) )
+        return &v->domain->arch.vgic.shared_irqs[rank - 1];
+    else
+        return NULL;
+}
+
+int domain_vgic_init(struct domain *d)
+{
+    int i;
+
+    d->arch.vgic.ctlr = 0;
+    d->arch.vgic.nr_lines = 32;
+    d->arch.vgic.shared_irqs =
+        xmalloc_array(struct vgic_irq_rank, DOMAIN_NR_RANKS(d));
+    d->arch.vgic.pending_irqs =
+        xmalloc_array(struct pending_irq,
+                d->arch.vgic.nr_lines + (32 * d->max_vcpus));
+    for (i=0; i<d->arch.vgic.nr_lines + (32 * d->max_vcpus); i++)
+        INIT_LIST_HEAD(&d->arch.vgic.pending_irqs[i].link);
+    for (i=0; i<DOMAIN_NR_RANKS(d); i++)
+        spin_lock_init(&d->arch.vgic.shared_irqs[i].lock);
+    return 0;
+}
+
+int vcpu_vgic_init(struct vcpu *v)
+{
+    int i;
+    memset(&v->arch.vgic.private_irqs, 0, sizeof(v->arch.vgic.private_irqs));
+
+    spin_lock_init(&v->arch.vgic.private_irqs.lock);
+
+    /* For SGI and PPI the target is always this CPU */
+    for ( i = 0 ; i < 8 ; i++ )
+        v->arch.vgic.private_irqs.itargets[i] =
+              (1<<(v->vcpu_id+0))
+            | (1<<(v->vcpu_id+8))
+            | (1<<(v->vcpu_id+16))
+            | (1<<(v->vcpu_id+24));
+    INIT_LIST_HEAD(&v->arch.vgic.inflight_irqs);
+    spin_lock_init(&v->arch.vgic.lock);
+
+    return 0;
+}
+
+#define vgic_lock(v)   spin_lock(&(v)->domain->arch.vgic.lock)
+#define vgic_unlock(v) spin_unlock(&(v)->domain->arch.vgic.lock)
+
+#define vgic_lock_rank(v, r) spin_lock(&(r)->lock)
+#define vgic_unlock_rank(v, r) spin_unlock(&(r)->lock)
+
+static uint32_t byte_read(uint32_t val, int sign, int offset)
+{
+    int byte = offset & 0x3;
+
+    val = val >> (8*byte);
+    if ( sign && (val & 0x80) )
+        val |= 0xffffff00;
+    else
+        val &= 0x000000ff;
+    return val;
+}
+
+static void byte_write(uint32_t *reg, uint32_t var, int offset)
+{
+    int byte = offset & 0x3;
+
+    var &= (0xff << (8*byte));
+
+    *reg &= ~(0xff << (8*byte));
+    *reg |= var;
+}
+
+static int vgic_distr_mmio_read(struct vcpu *v, mmio_info_t *info)
+{
+    struct hsr_dabt dabt = info->dabt;
+    struct cpu_user_regs *regs = guest_cpu_user_regs();
+    uint32_t *r = &regs->r0 + dabt.reg;
+    struct vgic_irq_rank *rank;
+    int offset = (int)(info->gpa - VGIC_DISTR_BASE_ADDRESS);
+    int gicd_reg = REG(offset);
+
+    switch ( gicd_reg )
+    {
+    case GICD_CTLR:
+        if ( dabt.size != 2 ) goto bad_width;
+        vgic_lock(v);
+        *r = v->domain->arch.vgic.ctlr;
+        vgic_unlock(v);
+        return 1;
+    case GICD_TYPER:
+        if ( dabt.size != 2 ) goto bad_width;
+        /* 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 );
+        vgic_unlock(v);
+        return 1;
+    case GICD_IIDR:
+        if ( dabt.size != 2 ) goto bad_width;
+        /*
+         * XXX Do we need a JEP106 manufacturer ID?
+         * Just use the physical h/w value for now
+         */
+        *r = 0x0000043b;
+        return 1;
+
+    /* Implementation defined -- read as zero */
+    case REG(0x020) ... REG(0x03c):
+        goto read_as_zero;
+
+    case GICD_IGROUPR ... GICD_IGROUPRN:
+        /* We do not implement security extensions for guests, read zero */
+        goto read_as_zero;
+
+    case GICD_ISENABLER ... GICD_ISENABLERN:
+        if ( dabt.size != 2 ) goto bad_width;
+        rank = vgic_irq_rank(v, 8, gicd_reg - GICD_ISENABLER);
+        if ( rank == NULL) goto read_as_zero;
+        vgic_lock_rank(v, rank);
+        *r = rank->ienable;
+        vgic_unlock_rank(v, rank);
+        return 1;
+
+    case GICD_ICENABLER ... GICD_ICENABLERN:
+        if ( dabt.size != 2 ) goto bad_width;
+        rank = vgic_irq_rank(v, 8, gicd_reg - GICD_ICENABLER);
+        if ( rank == NULL) goto read_as_zero;
+        vgic_lock_rank(v, rank);
+        *r = rank->ienable;
+        vgic_unlock_rank(v, rank);
+        return 1;
+
+    case GICD_ISPENDR ... GICD_ISPENDRN:
+        if ( dabt.size != 0 && dabt.size != 2 ) goto bad_width;
+        rank = vgic_irq_rank(v, 8, gicd_reg - GICD_ISPENDR);
+        if ( rank == NULL) goto read_as_zero;
+        vgic_lock_rank(v, rank);
+        *r = byte_read(rank->ipend, dabt.sign, offset);
+        vgic_unlock_rank(v, rank);
+        return 1;
+
+    case GICD_ICPENDR ... GICD_ICPENDRN:
+        if ( dabt.size != 0 && dabt.size != 2 ) goto bad_width;
+        rank = vgic_irq_rank(v, 8, gicd_reg - GICD_ICPENDR);
+        if ( rank == NULL) goto read_as_zero;
+        vgic_lock_rank(v, rank);
+        *r = byte_read(rank->ipend, dabt.sign, offset);
+        vgic_unlock_rank(v, rank);
+        return 1;
+
+    case GICD_ISACTIVER ... GICD_ISACTIVERN:
+        if ( dabt.size != 2 ) goto bad_width;
+        rank = vgic_irq_rank(v, 8, gicd_reg - GICD_ISACTIVER);
+        if ( rank == NULL) goto read_as_zero;
+        vgic_lock_rank(v, rank);
+        *r = rank->iactive;
+        vgic_unlock_rank(v, rank);
+        return 1;
+
+    case GICD_ICACTIVER ... GICD_ICACTIVERN:
+        if ( dabt.size != 2 ) goto bad_width;
+        rank = vgic_irq_rank(v, 8, gicd_reg - GICD_ICACTIVER);
+        if ( rank == NULL) goto read_as_zero;
+        vgic_lock_rank(v, rank);
+        *r = rank->iactive;
+        vgic_unlock_rank(v, rank);
+        return 1;
+
+    case GICD_ITARGETSR ... GICD_ITARGETSRN:
+        if ( dabt.size != 0 && dabt.size != 2 ) goto bad_width;
+        rank = vgic_irq_rank(v, 8, gicd_reg - GICD_ITARGETSR);
+        if ( rank == NULL) goto read_as_zero;
+
+        vgic_lock_rank(v, rank);
+        *r = rank->itargets[REG_RANK_INDEX(8, gicd_reg - GICD_ITARGETSR)];
+        if ( dabt.size == 0 )
+            *r = byte_read(*r, dabt.sign, offset);
+        vgic_unlock_rank(v, rank);
+        return 1;
+
+    case GICD_IPRIORITYR ... GICD_IPRIORITYRN:
+        if ( dabt.size != 0 && dabt.size != 2 ) goto bad_width;
+        rank = vgic_irq_rank(v, 8, gicd_reg - GICD_IPRIORITYR);
+        if ( rank == NULL) goto read_as_zero;
+
+        vgic_lock_rank(v, rank);
+        *r = rank->ipriority[REG_RANK_INDEX(8, gicd_reg - GICD_IPRIORITYR)];
+        if ( dabt.size == 0 )
+            *r = byte_read(*r, dabt.sign, offset);
+        vgic_unlock_rank(v, rank);
+        return 1;
+
+    case GICD_ICFGR ... GICD_ICFGRN:
+        if ( dabt.size != 2 ) goto bad_width;
+        rank = vgic_irq_rank(v, 2, gicd_reg - GICD_ICFGR);
+        if ( rank == NULL) goto read_as_zero;
+        vgic_lock_rank(v, rank);
+        *r = rank->icfg[REG_RANK_INDEX(2, gicd_reg - GICD_ICFGR)];
+        vgic_unlock_rank(v, rank);
+        return 0;
+
+    case GICD_NSACR ... GICD_NSACRN:
+        /* We do not implement securty extensions for guests, read zero */
+        goto read_as_zero;
+
+    case GICD_SGIR:
+        if ( dabt.size != 2 ) goto bad_width;
+        /* Write only -- read unknown */
+        *r = 0xdeadbeef;
+        return 1;
+
+    case GICD_CPENDSGIR ... GICD_CPENDSGIRN:
+        if ( dabt.size != 0 && dabt.size != 2 ) goto bad_width;
+        rank = vgic_irq_rank(v, 8, gicd_reg - GICD_CPENDSGIR);
+        if ( rank == NULL) goto read_as_zero;
+        vgic_lock_rank(v, rank);
+        *r = byte_read(rank->pendsgi, dabt.sign, offset);
+        vgic_unlock_rank(v, rank);
+        return 1;
+
+    case GICD_SPENDSGIR ... GICD_SPENDSGIRN:
+        if ( dabt.size != 0 && dabt.size != 2 ) goto bad_width;
+        rank = vgic_irq_rank(v, 8, gicd_reg - GICD_SPENDSGIR);
+        if ( rank == NULL) goto read_as_zero;
+        vgic_lock_rank(v, rank);
+        *r = byte_read(rank->pendsgi, dabt.sign, offset);
+        vgic_unlock_rank(v, rank);
+        return 1;
+
+    /* Implementation defined -- read as zero */
+    case REG(0xfd0) ... REG(0xfe4):
+        goto read_as_zero;
+
+    case GICD_ICPIDR2:
+        if ( dabt.size != 2 ) goto bad_width;
+        printk("vGICD: unhandled read from ICPIDR2\n");
+        return 0;
+
+    /* Implementation defined -- read as zero */
+    case REG(0xfec) ... REG(0xffc):
+        goto read_as_zero;
+
+    /* Reserved -- read as zero */
+    case REG(0x00c) ... REG(0x01c):
+    case REG(0x040) ... REG(0x07c):
+    case REG(0x7fc):
+    case REG(0xbfc):
+    case REG(0xf04) ... REG(0xf0c):
+    case REG(0xf30) ... REG(0xfcc):
+        goto read_as_zero;
+
+    default:
+        printk("vGICD: unhandled read r%d offset %#08x\n",
+               dabt.reg, offset);
+        return 0;
+    }
+
+bad_width:
+    printk("vGICD: bad read width %d r%d offset %#08x\n",
+           dabt.size, dabt.reg, offset);
+    domain_crash_synchronous();
+    return 0;
+
+read_as_zero:
+    if ( dabt.size != 2 ) goto bad_width;
+    *r = 0;
+    return 1;
+}
+
+static int vgic_distr_mmio_write(struct vcpu *v, mmio_info_t *info)
+{
+    struct hsr_dabt dabt = info->dabt;
+    struct cpu_user_regs *regs = guest_cpu_user_regs();
+    uint32_t *r = &regs->r0 + dabt.reg;
+    struct vgic_irq_rank *rank;
+    int offset = (int)(info->gpa - VGIC_DISTR_BASE_ADDRESS);
+    int gicd_reg = REG(offset);
+
+    switch ( gicd_reg )
+    {
+    case GICD_CTLR:
+        if ( dabt.size != 2 ) goto bad_width;
+        /* Ignore all but the enable bit */
+        v->domain->arch.vgic.ctlr = (*r) & GICD_CTL_ENABLE;
+        return 1;
+
+    /* R/O -- write ignored */
+    case GICD_TYPER:
+    case GICD_IIDR:
+        goto write_ignore;
+
+    /* Implementation defined -- write ignored */
+    case REG(0x020) ... REG(0x03c):
+        goto write_ignore;
+
+    case GICD_IGROUPR ... GICD_IGROUPRN:
+        /* We do not implement securty extensions for guests, write ignore */
+        goto write_ignore;
+
+    case GICD_ISENABLER ... GICD_ISENABLERN:
+        if ( dabt.size != 2 ) goto bad_width;
+        rank = vgic_irq_rank(v, 8, gicd_reg - GICD_ISENABLER);
+        if ( rank == NULL) goto write_ignore;
+        vgic_lock_rank(v, rank);
+        rank->ienable |= *r;
+        vgic_unlock_rank(v, rank);
+        return 1;
+
+    case GICD_ICENABLER ... GICD_ICENABLERN:
+        if ( dabt.size != 2 ) goto bad_width;
+        rank = vgic_irq_rank(v, 8, gicd_reg - GICD_ICENABLER);
+        if ( rank == NULL) goto write_ignore;
+        vgic_lock_rank(v, rank);
+        rank->ienable &= ~*r;
+        vgic_unlock_rank(v, rank);
+        return 1;
+
+    case GICD_ISPENDR ... GICD_ISPENDRN:
+        if ( dabt.size != 0 && dabt.size != 2 ) goto bad_width;
+        printk("vGICD: unhandled %s write %#"PRIx32" to ISPENDR%d\n",
+               dabt.size ? "word" : "byte", *r, gicd_reg - GICD_ISPENDR);
+        return 0;
+
+    case GICD_ICPENDR ... GICD_ICPENDRN:
+        if ( dabt.size != 0 && dabt.size != 2 ) goto bad_width;
+        printk("vGICD: unhandled %s write %#"PRIx32" to ICPENDR%d\n",
+               dabt.size ? "word" : "byte", *r, gicd_reg - GICD_ICPENDR);
+        return 0;
+
+    case GICD_ISACTIVER ... GICD_ISACTIVERN:
+        if ( dabt.size != 2 ) goto bad_width;
+        rank = vgic_irq_rank(v, 8, gicd_reg - GICD_ISACTIVER);
+        if ( rank == NULL) goto write_ignore;
+        vgic_lock_rank(v, rank);
+        rank->iactive &= ~*r;
+        vgic_unlock_rank(v, rank);
+        return 1;
+
+    case GICD_ICACTIVER ... GICD_ICACTIVERN:
+        if ( dabt.size != 2 ) goto bad_width;
+        rank = vgic_irq_rank(v, 8, gicd_reg - GICD_ICACTIVER);
+        if ( rank == NULL) goto write_ignore;
+        vgic_lock_rank(v, rank);
+        rank->iactive &= ~*r;
+        vgic_unlock_rank(v, rank);
+        return 1;
+
+    case GICD_ITARGETSR ... GICD_ITARGETSR + 7:
+        /* SGI/PPI target is read only */
+        goto write_ignore;
+
+    case GICD_ITARGETSR + 8 ... GICD_ITARGETSRN:
+        if ( dabt.size != 0 && dabt.size != 2 ) goto bad_width;
+        rank = vgic_irq_rank(v, 8, gicd_reg - GICD_ITARGETSR);
+        if ( rank == NULL) goto write_ignore;
+        vgic_lock_rank(v, rank);
+        if ( dabt.size == 2 )
+            rank->itargets[REG_RANK_INDEX(8, gicd_reg - GICD_ITARGETSR)] = *r;
+        else
+            byte_write(&rank->itargets[REG_RANK_INDEX(8, gicd_reg - GICD_ITARGETSR)],
+                       *r, offset);
+        vgic_unlock_rank(v, rank);
+        return 1;
+
+    case GICD_IPRIORITYR ... GICD_IPRIORITYRN:
+        if ( dabt.size != 0 && dabt.size != 2 ) goto bad_width;
+        rank = vgic_irq_rank(v, 8, gicd_reg - GICD_IPRIORITYR);
+        if ( rank == NULL) goto write_ignore;
+        vgic_lock_rank(v, rank);
+        if ( dabt.size == 2 )
+            rank->ipriority[REG_RANK_INDEX(8, gicd_reg - GICD_IPRIORITYR)] = *r;
+        else
+            byte_write(&rank->ipriority[REG_RANK_INDEX(8, gicd_reg - GICD_IPRIORITYR)],
+                       *r, offset);
+        vgic_unlock_rank(v, rank);
+        return 1;
+
+    case GICD_ICFGR: /* SGIs */
+        goto write_ignore;
+    case GICD_ICFGR + 1: /* PPIs */
+        /* It is implementation defined if these are writeable. We chose not */
+        goto write_ignore;
+    case GICD_ICFGR + 2 ... GICD_ICFGRN: /* SPIs */
+        if ( dabt.size != 2 ) goto bad_width;
+        rank = vgic_irq_rank(v, 2, gicd_reg - GICD_ICFGR);
+        vgic_lock_rank(v, rank);
+        if ( rank == NULL) goto write_ignore;
+        rank->icfg[REG_RANK_INDEX(2, gicd_reg - GICD_ICFGR)] = *r;
+        vgic_unlock_rank(v, rank);
+        return 1;
+
+    case GICD_NSACR ... GICD_NSACRN:
+        /* We do not implement securty extensions for guests, write ignore */
+        goto write_ignore;
+
+    case GICD_SGIR:
+        if ( dabt.size != 2 ) goto bad_width;
+        printk("vGICD: unhandled write %#"PRIx32" to ICFGR%d\n",
+               *r, gicd_reg - GICD_ICFGR);
+        return 0;
+
+    case GICD_CPENDSGIR ... GICD_CPENDSGIRN:
+        if ( dabt.size != 0 && dabt.size != 2 ) goto bad_width;
+        printk("vGICD: unhandled %s write %#"PRIx32" to ICPENDSGIR%d\n",
+               dabt.size ? "word" : "byte", *r, gicd_reg - GICD_CPENDSGIR);
+        return 0;
+
+    case GICD_SPENDSGIR ... GICD_SPENDSGIRN:
+        if ( dabt.size != 0 && dabt.size != 2 ) goto bad_width;
+        printk("vGICD: unhandled %s write %#"PRIx32" to ISPENDSGIR%d\n",
+               dabt.size ? "word" : "byte", *r, gicd_reg - GICD_SPENDSGIR);
+        return 0;
+
+    /* Implementation defined -- write ignored */
+    case REG(0xfd0) ... REG(0xfe4):
+        goto write_ignore;
+
+    /* R/O -- write ignore */
+    case GICD_ICPIDR2:
+        goto write_ignore;
+
+    /* Implementation defined -- write ignored */
+    case REG(0xfec) ... REG(0xffc):
+        goto write_ignore;
+
+    /* Reserved -- write ignored */
+    case REG(0x00c) ... REG(0x01c):
+    case REG(0x040) ... REG(0x07c):
+    case REG(0x7fc):
+    case REG(0xbfc):
+    case REG(0xf04) ... REG(0xf0c):
+    case REG(0xf30) ... REG(0xfcc):
+        goto write_ignore;
+
+    default:
+        printk("vGICD: unhandled write r%d=%"PRIx32" offset %#08x\n",
+               dabt.reg, *r, offset);
+        return 0;
+    }
+
+bad_width:
+    printk("vGICD: bad write width %d r%d=%"PRIx32" offset %#08x\n",
+           dabt.size, dabt.reg, *r, offset);
+    domain_crash_synchronous();
+    return 0;
+
+write_ignore:
+    if ( dabt.size != 2 ) goto bad_width;
+    return 0;
+}
+
+static int vgic_distr_mmio_check(struct vcpu *v, paddr_t addr)
+{
+    return addr >= VGIC_DISTR_BASE_ADDRESS && addr < (VGIC_DISTR_BASE_ADDRESS+PAGE_SIZE);
+}
+
+const struct mmio_handler vgic_distr_mmio_handler = {
+    .check_handler = vgic_distr_mmio_check,
+    .read_handler  = vgic_distr_mmio_read,
+    .write_handler = vgic_distr_mmio_write,
+};
+
+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
+     * are used for SPIs; the rests are used for per cpu irqs */
+    if ( irq < 32 )
+        n = &v->domain->arch.vgic.pending_irqs[irq + (v->vcpu_id * 32)
+            + v->domain->arch.vgic.nr_lines];
+    else
+        n = &v->domain->arch.vgic.pending_irqs[irq - 32];
+    return n;
+}
+
+void vgic_vcpu_inject_irq(struct vcpu *v, unsigned int irq, int virtual)
+{
+    int idx = irq >> 2, byte = irq & 0x3;
+    uint8_t priority;
+    struct vgic_irq_rank *rank = vgic_irq_rank(v, 8, idx);
+    struct pending_irq *iter, *n = irq_to_pending(v, irq);
+
+    /* irq still pending */
+    if (!list_empty(&n->link))
+        return;
+
+    priority = byte_read(rank->ipriority[REG_RANK_INDEX(8, idx)], 0, byte);
+
+    n->irq = irq;
+    n->priority = priority;
+    if (!virtual)
+        n->desc = irq_to_desc(irq);
+    else
+        n->desc = NULL;
+
+    gic_set_guest_irq(irq, GICH_LR_PENDING, priority);
+
+    spin_lock(&v->arch.vgic.lock);
+    list_for_each_entry ( iter, &v->arch.vgic.inflight_irqs, link )
+    {
+        if ( iter->priority < priority )
+        {
+            list_add_tail(&n->link, &iter->link);
+            spin_unlock(&v->arch.vgic.lock);
+            return;
+        }
+    }
+    list_add(&n->link, &v->arch.vgic.inflight_irqs);
+    spin_unlock(&v->arch.vgic.lock);
+    /* we have a new higher priority irq, inject it into the guest */
+    cpu_raise_softirq(v->processor, VGIC_SOFTIRQ);
+}
+
+static void vgic_softirq(void)
+{
+    if (list_empty(&current->arch.vgic.inflight_irqs))
+        return;
+
+    gic_inject_irq_start();
+}
+
+static int __init init_vgic_softirq(void)
+{
+    open_softirq(VGIC_SOFTIRQ, vgic_softirq);
+    return 0;
+}
+__initcall(init_vgic_softirq);
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
+
diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
index 2226a24..2cd0bd3 100644
--- a/xen/include/asm-arm/domain.h
+++ b/xen/include/asm-arm/domain.h
@@ -6,6 +6,15 @@
 #include <asm/page.h>
 #include <asm/p2m.h>
 
+/* Represents state corresponding to a block of 32 interrupts */
+struct vgic_irq_rank {
+    spinlock_t lock; /* Covers access to all other members of this struct */
+    uint32_t ienable, iactive, ipend, pendsgi;
+    uint32_t icfg[2];
+    uint32_t ipriority[8];
+    uint32_t itargets[8];
+};
+
 struct pending_irq
 {
     int irq;
@@ -18,6 +27,22 @@ struct arch_domain
 {
     struct p2m_domain p2m;
 
+    struct {
+        /*
+         * Covers access to other members of this struct _except_ for
+         * shared_irqs where each member contains its own locking.
+         *
+         * If both class of lock is required then this lock must be
+         * taken first. If multiple rank locks are required (including
+         * the per-vcpu private_irqs rank) then they must be taken in
+         * rank order.
+         */
+        spinlock_t lock;
+        int ctlr;
+        int nr_lines;
+        struct vgic_irq_rank *shared_irqs;
+        struct pending_irq *pending_irqs;
+    } vgic;
 }  __cacheline_aligned;
 
 struct arch_vcpu
@@ -27,6 +52,11 @@ struct arch_vcpu
     uint32_t sctlr;
     uint32_t ttbr0, ttbr1, ttbcr;
 
+    struct {
+        struct vgic_irq_rank private_irqs;
+        struct list_head inflight_irqs;
+        spinlock_t lock;
+    } vgic;
 }  __cacheline_aligned;
 
 void vcpu_show_execution_state(struct vcpu *);
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 16:29:37 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 16:29:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbEBa-0002RA-GR; Thu, 15 Dec 2011 16:29:34 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RbEBY-0002G6-JE
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 16:29:33 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1323966564!7053019!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjE2NDg=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22728 invoked from network); 15 Dec 2011 16:29:25 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 16:29:25 -0000
X-IronPort-AV: E=Sophos;i="4.71,357,1320642000"; d="scan'208";a="174308262"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Dec 2011 11:29:23 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Thu, 15 Dec 2011 11:29:22 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pBFGSMtl003330;
	Thu, 15 Dec 2011 08:29:10 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Thu, 15 Dec 2011 16:30:55 +0000
Message-ID: <1323966657-19790-23-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1112131831560.3517@kaball-desktop>
References: <alpine.DEB.2.00.1112131831560.3517@kaball-desktop>
MIME-Version: 1.0
Cc: keir.xen@gmail.com, Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, JBeulich@suse.com,
	Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v3 23/25] arm: vgic emulation
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

- emulation of the GICD interface for the guest;

- interrupt injection into the guest;

- keep track of inflight irqs using a list, ordered by priority.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
---
 xen/arch/arm/domain.c        |    6 +
 xen/arch/arm/gic.h           |    3 +
 xen/arch/arm/io.c            |    1 +
 xen/arch/arm/io.h            |    2 +
 xen/arch/arm/irq.c           |    3 +-
 xen/arch/arm/vgic.c          |  605 ++++++++++++++++++++++++++++++++++++++++++
 xen/include/asm-arm/domain.h |   30 ++
 7 files changed, 649 insertions(+), 1 deletions(-)
 create mode 100644 xen/arch/arm/vgic.c

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 0844b37..7e681ab 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -212,6 +212,9 @@ int vcpu_initialise(struct vcpu *v)
 {
     int rc = 0;
 
+    if ( (rc = vcpu_vgic_init(v)) != 0 )
+        return rc;
+
     return rc;
 }
 
@@ -230,6 +233,9 @@ int arch_domain_create(struct domain *d, unsigned int domcr_flags)
 
     d->max_vcpus = 8;
 
+    if ( (rc = domain_vgic_init(d)) != 0 )
+        goto fail;
+
     rc = 0;
 fail:
     return rc;
diff --git a/xen/arch/arm/gic.h b/xen/arch/arm/gic.h
index 63b6648..81c388d 100644
--- a/xen/arch/arm/gic.h
+++ b/xen/arch/arm/gic.h
@@ -121,6 +121,9 @@
 #define GICH_LR_CPUID_SHIFT     9
 #define GICH_VTR_NRLRGS         0x3f
 
+extern int domain_vgic_init(struct domain *d);
+extern int vcpu_vgic_init(struct vcpu *v);
+extern void vgic_vcpu_inject_irq(struct vcpu *v, unsigned int irq,int virtual);
 extern struct pending_irq *irq_to_pending(struct vcpu *v, unsigned int irq);
 
 extern void gic_route_irqs(void);
diff --git a/xen/arch/arm/io.c b/xen/arch/arm/io.c
index 8789705..4461225 100644
--- a/xen/arch/arm/io.c
+++ b/xen/arch/arm/io.c
@@ -24,6 +24,7 @@
 
 static const struct mmio_handler *const mmio_handlers[] =
 {
+    &vgic_distr_mmio_handler,
 };
 #define MMIO_HANDLER_NR ARRAY_SIZE(mmio_handlers)
 
diff --git a/xen/arch/arm/io.h b/xen/arch/arm/io.h
index d7847e3..8cc5ca7 100644
--- a/xen/arch/arm/io.h
+++ b/xen/arch/arm/io.h
@@ -39,6 +39,8 @@ struct mmio_handler {
     mmio_write_t write_handler;
 };
 
+extern const struct mmio_handler vgic_distr_mmio_handler;
+
 extern int handle_mmio(mmio_info_t *info);
 
 #endif
diff --git a/xen/arch/arm/irq.c b/xen/arch/arm/irq.c
index 5663762..7820310 100644
--- a/xen/arch/arm/irq.c
+++ b/xen/arch/arm/irq.c
@@ -136,7 +136,8 @@ void do_IRQ(struct cpu_user_regs *regs, unsigned int irq, int is_fiq)
 
         desc->status |= IRQ_INPROGRESS;
 
-        /* XXX: inject irq into the guest */
+        /* XXX: inject irq into all guest vcpus */
+        vgic_vcpu_inject_irq(d->vcpu[0], irq, 0);
         goto out_no_end;
     }
 
diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
new file mode 100644
index 0000000..26eae55
--- /dev/null
+++ b/xen/arch/arm/vgic.c
@@ -0,0 +1,605 @@
+/*
+ * xen/arch/arm/vgic.c
+ *
+ * ARM Virtual Generic Interrupt Controller support
+ *
+ * Ian Campbell <ian.campbell@citrix.com>
+ * Copyright (c) 2011 Citrix Systems.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include <xen/config.h>
+#include <xen/lib.h>
+#include <xen/init.h>
+#include <xen/softirq.h>
+#include <xen/irq.h>
+#include <xen/sched.h>
+
+#include <asm/current.h>
+
+#include "io.h"
+#include "gic.h"
+
+#define VGIC_DISTR_BASE_ADDRESS 0x000000002c001000
+
+#define REG(n) (n/4)
+
+/* Number of ranks of interrupt registers for a domain */
+#define DOMAIN_NR_RANKS(d) (((d)->arch.vgic.nr_lines+31)/32)
+
+/*
+ * Rank containing GICD_<FOO><n> for GICD_<FOO> with
+ * <b>-bits-per-interrupt
+ */
+static inline int REG_RANK_NR(int b, uint32_t n)
+{
+    switch ( b )
+    {
+    case 8: return n >> 3;
+    case 4: return n >> 2;
+    case 2: return n >> 1;
+    default: BUG();
+    }
+}
+
+/*
+ * Offset of GICD_<FOO><n> with its rank, for GICD_<FOO> with
+ * <b>-bits-per-interrupt.
+ */
+#define REG_RANK_INDEX(b, n) ((n) & ((b)-1))
+
+/*
+ * Returns rank corresponding to a GICD_<FOO><n> register for
+ * GICD_<FOO> with <b>-bits-per-interrupt.
+ */
+static struct vgic_irq_rank *vgic_irq_rank(struct vcpu *v, int b, int n)
+{
+    int rank = REG_RANK_NR(b, n);
+
+    if ( rank == 0 )
+        return &v->arch.vgic.private_irqs;
+    else if ( rank <= DOMAIN_NR_RANKS(v->domain) )
+        return &v->domain->arch.vgic.shared_irqs[rank - 1];
+    else
+        return NULL;
+}
+
+int domain_vgic_init(struct domain *d)
+{
+    int i;
+
+    d->arch.vgic.ctlr = 0;
+    d->arch.vgic.nr_lines = 32;
+    d->arch.vgic.shared_irqs =
+        xmalloc_array(struct vgic_irq_rank, DOMAIN_NR_RANKS(d));
+    d->arch.vgic.pending_irqs =
+        xmalloc_array(struct pending_irq,
+                d->arch.vgic.nr_lines + (32 * d->max_vcpus));
+    for (i=0; i<d->arch.vgic.nr_lines + (32 * d->max_vcpus); i++)
+        INIT_LIST_HEAD(&d->arch.vgic.pending_irqs[i].link);
+    for (i=0; i<DOMAIN_NR_RANKS(d); i++)
+        spin_lock_init(&d->arch.vgic.shared_irqs[i].lock);
+    return 0;
+}
+
+int vcpu_vgic_init(struct vcpu *v)
+{
+    int i;
+    memset(&v->arch.vgic.private_irqs, 0, sizeof(v->arch.vgic.private_irqs));
+
+    spin_lock_init(&v->arch.vgic.private_irqs.lock);
+
+    /* For SGI and PPI the target is always this CPU */
+    for ( i = 0 ; i < 8 ; i++ )
+        v->arch.vgic.private_irqs.itargets[i] =
+              (1<<(v->vcpu_id+0))
+            | (1<<(v->vcpu_id+8))
+            | (1<<(v->vcpu_id+16))
+            | (1<<(v->vcpu_id+24));
+    INIT_LIST_HEAD(&v->arch.vgic.inflight_irqs);
+    spin_lock_init(&v->arch.vgic.lock);
+
+    return 0;
+}
+
+#define vgic_lock(v)   spin_lock(&(v)->domain->arch.vgic.lock)
+#define vgic_unlock(v) spin_unlock(&(v)->domain->arch.vgic.lock)
+
+#define vgic_lock_rank(v, r) spin_lock(&(r)->lock)
+#define vgic_unlock_rank(v, r) spin_unlock(&(r)->lock)
+
+static uint32_t byte_read(uint32_t val, int sign, int offset)
+{
+    int byte = offset & 0x3;
+
+    val = val >> (8*byte);
+    if ( sign && (val & 0x80) )
+        val |= 0xffffff00;
+    else
+        val &= 0x000000ff;
+    return val;
+}
+
+static void byte_write(uint32_t *reg, uint32_t var, int offset)
+{
+    int byte = offset & 0x3;
+
+    var &= (0xff << (8*byte));
+
+    *reg &= ~(0xff << (8*byte));
+    *reg |= var;
+}
+
+static int vgic_distr_mmio_read(struct vcpu *v, mmio_info_t *info)
+{
+    struct hsr_dabt dabt = info->dabt;
+    struct cpu_user_regs *regs = guest_cpu_user_regs();
+    uint32_t *r = &regs->r0 + dabt.reg;
+    struct vgic_irq_rank *rank;
+    int offset = (int)(info->gpa - VGIC_DISTR_BASE_ADDRESS);
+    int gicd_reg = REG(offset);
+
+    switch ( gicd_reg )
+    {
+    case GICD_CTLR:
+        if ( dabt.size != 2 ) goto bad_width;
+        vgic_lock(v);
+        *r = v->domain->arch.vgic.ctlr;
+        vgic_unlock(v);
+        return 1;
+    case GICD_TYPER:
+        if ( dabt.size != 2 ) goto bad_width;
+        /* 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 );
+        vgic_unlock(v);
+        return 1;
+    case GICD_IIDR:
+        if ( dabt.size != 2 ) goto bad_width;
+        /*
+         * XXX Do we need a JEP106 manufacturer ID?
+         * Just use the physical h/w value for now
+         */
+        *r = 0x0000043b;
+        return 1;
+
+    /* Implementation defined -- read as zero */
+    case REG(0x020) ... REG(0x03c):
+        goto read_as_zero;
+
+    case GICD_IGROUPR ... GICD_IGROUPRN:
+        /* We do not implement security extensions for guests, read zero */
+        goto read_as_zero;
+
+    case GICD_ISENABLER ... GICD_ISENABLERN:
+        if ( dabt.size != 2 ) goto bad_width;
+        rank = vgic_irq_rank(v, 8, gicd_reg - GICD_ISENABLER);
+        if ( rank == NULL) goto read_as_zero;
+        vgic_lock_rank(v, rank);
+        *r = rank->ienable;
+        vgic_unlock_rank(v, rank);
+        return 1;
+
+    case GICD_ICENABLER ... GICD_ICENABLERN:
+        if ( dabt.size != 2 ) goto bad_width;
+        rank = vgic_irq_rank(v, 8, gicd_reg - GICD_ICENABLER);
+        if ( rank == NULL) goto read_as_zero;
+        vgic_lock_rank(v, rank);
+        *r = rank->ienable;
+        vgic_unlock_rank(v, rank);
+        return 1;
+
+    case GICD_ISPENDR ... GICD_ISPENDRN:
+        if ( dabt.size != 0 && dabt.size != 2 ) goto bad_width;
+        rank = vgic_irq_rank(v, 8, gicd_reg - GICD_ISPENDR);
+        if ( rank == NULL) goto read_as_zero;
+        vgic_lock_rank(v, rank);
+        *r = byte_read(rank->ipend, dabt.sign, offset);
+        vgic_unlock_rank(v, rank);
+        return 1;
+
+    case GICD_ICPENDR ... GICD_ICPENDRN:
+        if ( dabt.size != 0 && dabt.size != 2 ) goto bad_width;
+        rank = vgic_irq_rank(v, 8, gicd_reg - GICD_ICPENDR);
+        if ( rank == NULL) goto read_as_zero;
+        vgic_lock_rank(v, rank);
+        *r = byte_read(rank->ipend, dabt.sign, offset);
+        vgic_unlock_rank(v, rank);
+        return 1;
+
+    case GICD_ISACTIVER ... GICD_ISACTIVERN:
+        if ( dabt.size != 2 ) goto bad_width;
+        rank = vgic_irq_rank(v, 8, gicd_reg - GICD_ISACTIVER);
+        if ( rank == NULL) goto read_as_zero;
+        vgic_lock_rank(v, rank);
+        *r = rank->iactive;
+        vgic_unlock_rank(v, rank);
+        return 1;
+
+    case GICD_ICACTIVER ... GICD_ICACTIVERN:
+        if ( dabt.size != 2 ) goto bad_width;
+        rank = vgic_irq_rank(v, 8, gicd_reg - GICD_ICACTIVER);
+        if ( rank == NULL) goto read_as_zero;
+        vgic_lock_rank(v, rank);
+        *r = rank->iactive;
+        vgic_unlock_rank(v, rank);
+        return 1;
+
+    case GICD_ITARGETSR ... GICD_ITARGETSRN:
+        if ( dabt.size != 0 && dabt.size != 2 ) goto bad_width;
+        rank = vgic_irq_rank(v, 8, gicd_reg - GICD_ITARGETSR);
+        if ( rank == NULL) goto read_as_zero;
+
+        vgic_lock_rank(v, rank);
+        *r = rank->itargets[REG_RANK_INDEX(8, gicd_reg - GICD_ITARGETSR)];
+        if ( dabt.size == 0 )
+            *r = byte_read(*r, dabt.sign, offset);
+        vgic_unlock_rank(v, rank);
+        return 1;
+
+    case GICD_IPRIORITYR ... GICD_IPRIORITYRN:
+        if ( dabt.size != 0 && dabt.size != 2 ) goto bad_width;
+        rank = vgic_irq_rank(v, 8, gicd_reg - GICD_IPRIORITYR);
+        if ( rank == NULL) goto read_as_zero;
+
+        vgic_lock_rank(v, rank);
+        *r = rank->ipriority[REG_RANK_INDEX(8, gicd_reg - GICD_IPRIORITYR)];
+        if ( dabt.size == 0 )
+            *r = byte_read(*r, dabt.sign, offset);
+        vgic_unlock_rank(v, rank);
+        return 1;
+
+    case GICD_ICFGR ... GICD_ICFGRN:
+        if ( dabt.size != 2 ) goto bad_width;
+        rank = vgic_irq_rank(v, 2, gicd_reg - GICD_ICFGR);
+        if ( rank == NULL) goto read_as_zero;
+        vgic_lock_rank(v, rank);
+        *r = rank->icfg[REG_RANK_INDEX(2, gicd_reg - GICD_ICFGR)];
+        vgic_unlock_rank(v, rank);
+        return 0;
+
+    case GICD_NSACR ... GICD_NSACRN:
+        /* We do not implement securty extensions for guests, read zero */
+        goto read_as_zero;
+
+    case GICD_SGIR:
+        if ( dabt.size != 2 ) goto bad_width;
+        /* Write only -- read unknown */
+        *r = 0xdeadbeef;
+        return 1;
+
+    case GICD_CPENDSGIR ... GICD_CPENDSGIRN:
+        if ( dabt.size != 0 && dabt.size != 2 ) goto bad_width;
+        rank = vgic_irq_rank(v, 8, gicd_reg - GICD_CPENDSGIR);
+        if ( rank == NULL) goto read_as_zero;
+        vgic_lock_rank(v, rank);
+        *r = byte_read(rank->pendsgi, dabt.sign, offset);
+        vgic_unlock_rank(v, rank);
+        return 1;
+
+    case GICD_SPENDSGIR ... GICD_SPENDSGIRN:
+        if ( dabt.size != 0 && dabt.size != 2 ) goto bad_width;
+        rank = vgic_irq_rank(v, 8, gicd_reg - GICD_SPENDSGIR);
+        if ( rank == NULL) goto read_as_zero;
+        vgic_lock_rank(v, rank);
+        *r = byte_read(rank->pendsgi, dabt.sign, offset);
+        vgic_unlock_rank(v, rank);
+        return 1;
+
+    /* Implementation defined -- read as zero */
+    case REG(0xfd0) ... REG(0xfe4):
+        goto read_as_zero;
+
+    case GICD_ICPIDR2:
+        if ( dabt.size != 2 ) goto bad_width;
+        printk("vGICD: unhandled read from ICPIDR2\n");
+        return 0;
+
+    /* Implementation defined -- read as zero */
+    case REG(0xfec) ... REG(0xffc):
+        goto read_as_zero;
+
+    /* Reserved -- read as zero */
+    case REG(0x00c) ... REG(0x01c):
+    case REG(0x040) ... REG(0x07c):
+    case REG(0x7fc):
+    case REG(0xbfc):
+    case REG(0xf04) ... REG(0xf0c):
+    case REG(0xf30) ... REG(0xfcc):
+        goto read_as_zero;
+
+    default:
+        printk("vGICD: unhandled read r%d offset %#08x\n",
+               dabt.reg, offset);
+        return 0;
+    }
+
+bad_width:
+    printk("vGICD: bad read width %d r%d offset %#08x\n",
+           dabt.size, dabt.reg, offset);
+    domain_crash_synchronous();
+    return 0;
+
+read_as_zero:
+    if ( dabt.size != 2 ) goto bad_width;
+    *r = 0;
+    return 1;
+}
+
+static int vgic_distr_mmio_write(struct vcpu *v, mmio_info_t *info)
+{
+    struct hsr_dabt dabt = info->dabt;
+    struct cpu_user_regs *regs = guest_cpu_user_regs();
+    uint32_t *r = &regs->r0 + dabt.reg;
+    struct vgic_irq_rank *rank;
+    int offset = (int)(info->gpa - VGIC_DISTR_BASE_ADDRESS);
+    int gicd_reg = REG(offset);
+
+    switch ( gicd_reg )
+    {
+    case GICD_CTLR:
+        if ( dabt.size != 2 ) goto bad_width;
+        /* Ignore all but the enable bit */
+        v->domain->arch.vgic.ctlr = (*r) & GICD_CTL_ENABLE;
+        return 1;
+
+    /* R/O -- write ignored */
+    case GICD_TYPER:
+    case GICD_IIDR:
+        goto write_ignore;
+
+    /* Implementation defined -- write ignored */
+    case REG(0x020) ... REG(0x03c):
+        goto write_ignore;
+
+    case GICD_IGROUPR ... GICD_IGROUPRN:
+        /* We do not implement securty extensions for guests, write ignore */
+        goto write_ignore;
+
+    case GICD_ISENABLER ... GICD_ISENABLERN:
+        if ( dabt.size != 2 ) goto bad_width;
+        rank = vgic_irq_rank(v, 8, gicd_reg - GICD_ISENABLER);
+        if ( rank == NULL) goto write_ignore;
+        vgic_lock_rank(v, rank);
+        rank->ienable |= *r;
+        vgic_unlock_rank(v, rank);
+        return 1;
+
+    case GICD_ICENABLER ... GICD_ICENABLERN:
+        if ( dabt.size != 2 ) goto bad_width;
+        rank = vgic_irq_rank(v, 8, gicd_reg - GICD_ICENABLER);
+        if ( rank == NULL) goto write_ignore;
+        vgic_lock_rank(v, rank);
+        rank->ienable &= ~*r;
+        vgic_unlock_rank(v, rank);
+        return 1;
+
+    case GICD_ISPENDR ... GICD_ISPENDRN:
+        if ( dabt.size != 0 && dabt.size != 2 ) goto bad_width;
+        printk("vGICD: unhandled %s write %#"PRIx32" to ISPENDR%d\n",
+               dabt.size ? "word" : "byte", *r, gicd_reg - GICD_ISPENDR);
+        return 0;
+
+    case GICD_ICPENDR ... GICD_ICPENDRN:
+        if ( dabt.size != 0 && dabt.size != 2 ) goto bad_width;
+        printk("vGICD: unhandled %s write %#"PRIx32" to ICPENDR%d\n",
+               dabt.size ? "word" : "byte", *r, gicd_reg - GICD_ICPENDR);
+        return 0;
+
+    case GICD_ISACTIVER ... GICD_ISACTIVERN:
+        if ( dabt.size != 2 ) goto bad_width;
+        rank = vgic_irq_rank(v, 8, gicd_reg - GICD_ISACTIVER);
+        if ( rank == NULL) goto write_ignore;
+        vgic_lock_rank(v, rank);
+        rank->iactive &= ~*r;
+        vgic_unlock_rank(v, rank);
+        return 1;
+
+    case GICD_ICACTIVER ... GICD_ICACTIVERN:
+        if ( dabt.size != 2 ) goto bad_width;
+        rank = vgic_irq_rank(v, 8, gicd_reg - GICD_ICACTIVER);
+        if ( rank == NULL) goto write_ignore;
+        vgic_lock_rank(v, rank);
+        rank->iactive &= ~*r;
+        vgic_unlock_rank(v, rank);
+        return 1;
+
+    case GICD_ITARGETSR ... GICD_ITARGETSR + 7:
+        /* SGI/PPI target is read only */
+        goto write_ignore;
+
+    case GICD_ITARGETSR + 8 ... GICD_ITARGETSRN:
+        if ( dabt.size != 0 && dabt.size != 2 ) goto bad_width;
+        rank = vgic_irq_rank(v, 8, gicd_reg - GICD_ITARGETSR);
+        if ( rank == NULL) goto write_ignore;
+        vgic_lock_rank(v, rank);
+        if ( dabt.size == 2 )
+            rank->itargets[REG_RANK_INDEX(8, gicd_reg - GICD_ITARGETSR)] = *r;
+        else
+            byte_write(&rank->itargets[REG_RANK_INDEX(8, gicd_reg - GICD_ITARGETSR)],
+                       *r, offset);
+        vgic_unlock_rank(v, rank);
+        return 1;
+
+    case GICD_IPRIORITYR ... GICD_IPRIORITYRN:
+        if ( dabt.size != 0 && dabt.size != 2 ) goto bad_width;
+        rank = vgic_irq_rank(v, 8, gicd_reg - GICD_IPRIORITYR);
+        if ( rank == NULL) goto write_ignore;
+        vgic_lock_rank(v, rank);
+        if ( dabt.size == 2 )
+            rank->ipriority[REG_RANK_INDEX(8, gicd_reg - GICD_IPRIORITYR)] = *r;
+        else
+            byte_write(&rank->ipriority[REG_RANK_INDEX(8, gicd_reg - GICD_IPRIORITYR)],
+                       *r, offset);
+        vgic_unlock_rank(v, rank);
+        return 1;
+
+    case GICD_ICFGR: /* SGIs */
+        goto write_ignore;
+    case GICD_ICFGR + 1: /* PPIs */
+        /* It is implementation defined if these are writeable. We chose not */
+        goto write_ignore;
+    case GICD_ICFGR + 2 ... GICD_ICFGRN: /* SPIs */
+        if ( dabt.size != 2 ) goto bad_width;
+        rank = vgic_irq_rank(v, 2, gicd_reg - GICD_ICFGR);
+        vgic_lock_rank(v, rank);
+        if ( rank == NULL) goto write_ignore;
+        rank->icfg[REG_RANK_INDEX(2, gicd_reg - GICD_ICFGR)] = *r;
+        vgic_unlock_rank(v, rank);
+        return 1;
+
+    case GICD_NSACR ... GICD_NSACRN:
+        /* We do not implement securty extensions for guests, write ignore */
+        goto write_ignore;
+
+    case GICD_SGIR:
+        if ( dabt.size != 2 ) goto bad_width;
+        printk("vGICD: unhandled write %#"PRIx32" to ICFGR%d\n",
+               *r, gicd_reg - GICD_ICFGR);
+        return 0;
+
+    case GICD_CPENDSGIR ... GICD_CPENDSGIRN:
+        if ( dabt.size != 0 && dabt.size != 2 ) goto bad_width;
+        printk("vGICD: unhandled %s write %#"PRIx32" to ICPENDSGIR%d\n",
+               dabt.size ? "word" : "byte", *r, gicd_reg - GICD_CPENDSGIR);
+        return 0;
+
+    case GICD_SPENDSGIR ... GICD_SPENDSGIRN:
+        if ( dabt.size != 0 && dabt.size != 2 ) goto bad_width;
+        printk("vGICD: unhandled %s write %#"PRIx32" to ISPENDSGIR%d\n",
+               dabt.size ? "word" : "byte", *r, gicd_reg - GICD_SPENDSGIR);
+        return 0;
+
+    /* Implementation defined -- write ignored */
+    case REG(0xfd0) ... REG(0xfe4):
+        goto write_ignore;
+
+    /* R/O -- write ignore */
+    case GICD_ICPIDR2:
+        goto write_ignore;
+
+    /* Implementation defined -- write ignored */
+    case REG(0xfec) ... REG(0xffc):
+        goto write_ignore;
+
+    /* Reserved -- write ignored */
+    case REG(0x00c) ... REG(0x01c):
+    case REG(0x040) ... REG(0x07c):
+    case REG(0x7fc):
+    case REG(0xbfc):
+    case REG(0xf04) ... REG(0xf0c):
+    case REG(0xf30) ... REG(0xfcc):
+        goto write_ignore;
+
+    default:
+        printk("vGICD: unhandled write r%d=%"PRIx32" offset %#08x\n",
+               dabt.reg, *r, offset);
+        return 0;
+    }
+
+bad_width:
+    printk("vGICD: bad write width %d r%d=%"PRIx32" offset %#08x\n",
+           dabt.size, dabt.reg, *r, offset);
+    domain_crash_synchronous();
+    return 0;
+
+write_ignore:
+    if ( dabt.size != 2 ) goto bad_width;
+    return 0;
+}
+
+static int vgic_distr_mmio_check(struct vcpu *v, paddr_t addr)
+{
+    return addr >= VGIC_DISTR_BASE_ADDRESS && addr < (VGIC_DISTR_BASE_ADDRESS+PAGE_SIZE);
+}
+
+const struct mmio_handler vgic_distr_mmio_handler = {
+    .check_handler = vgic_distr_mmio_check,
+    .read_handler  = vgic_distr_mmio_read,
+    .write_handler = vgic_distr_mmio_write,
+};
+
+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
+     * are used for SPIs; the rests are used for per cpu irqs */
+    if ( irq < 32 )
+        n = &v->domain->arch.vgic.pending_irqs[irq + (v->vcpu_id * 32)
+            + v->domain->arch.vgic.nr_lines];
+    else
+        n = &v->domain->arch.vgic.pending_irqs[irq - 32];
+    return n;
+}
+
+void vgic_vcpu_inject_irq(struct vcpu *v, unsigned int irq, int virtual)
+{
+    int idx = irq >> 2, byte = irq & 0x3;
+    uint8_t priority;
+    struct vgic_irq_rank *rank = vgic_irq_rank(v, 8, idx);
+    struct pending_irq *iter, *n = irq_to_pending(v, irq);
+
+    /* irq still pending */
+    if (!list_empty(&n->link))
+        return;
+
+    priority = byte_read(rank->ipriority[REG_RANK_INDEX(8, idx)], 0, byte);
+
+    n->irq = irq;
+    n->priority = priority;
+    if (!virtual)
+        n->desc = irq_to_desc(irq);
+    else
+        n->desc = NULL;
+
+    gic_set_guest_irq(irq, GICH_LR_PENDING, priority);
+
+    spin_lock(&v->arch.vgic.lock);
+    list_for_each_entry ( iter, &v->arch.vgic.inflight_irqs, link )
+    {
+        if ( iter->priority < priority )
+        {
+            list_add_tail(&n->link, &iter->link);
+            spin_unlock(&v->arch.vgic.lock);
+            return;
+        }
+    }
+    list_add(&n->link, &v->arch.vgic.inflight_irqs);
+    spin_unlock(&v->arch.vgic.lock);
+    /* we have a new higher priority irq, inject it into the guest */
+    cpu_raise_softirq(v->processor, VGIC_SOFTIRQ);
+}
+
+static void vgic_softirq(void)
+{
+    if (list_empty(&current->arch.vgic.inflight_irqs))
+        return;
+
+    gic_inject_irq_start();
+}
+
+static int __init init_vgic_softirq(void)
+{
+    open_softirq(VGIC_SOFTIRQ, vgic_softirq);
+    return 0;
+}
+__initcall(init_vgic_softirq);
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
+
diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
index 2226a24..2cd0bd3 100644
--- a/xen/include/asm-arm/domain.h
+++ b/xen/include/asm-arm/domain.h
@@ -6,6 +6,15 @@
 #include <asm/page.h>
 #include <asm/p2m.h>
 
+/* Represents state corresponding to a block of 32 interrupts */
+struct vgic_irq_rank {
+    spinlock_t lock; /* Covers access to all other members of this struct */
+    uint32_t ienable, iactive, ipend, pendsgi;
+    uint32_t icfg[2];
+    uint32_t ipriority[8];
+    uint32_t itargets[8];
+};
+
 struct pending_irq
 {
     int irq;
@@ -18,6 +27,22 @@ struct arch_domain
 {
     struct p2m_domain p2m;
 
+    struct {
+        /*
+         * Covers access to other members of this struct _except_ for
+         * shared_irqs where each member contains its own locking.
+         *
+         * If both class of lock is required then this lock must be
+         * taken first. If multiple rank locks are required (including
+         * the per-vcpu private_irqs rank) then they must be taken in
+         * rank order.
+         */
+        spinlock_t lock;
+        int ctlr;
+        int nr_lines;
+        struct vgic_irq_rank *shared_irqs;
+        struct pending_irq *pending_irqs;
+    } vgic;
 }  __cacheline_aligned;
 
 struct arch_vcpu
@@ -27,6 +52,11 @@ struct arch_vcpu
     uint32_t sctlr;
     uint32_t ttbr0, ttbr1, ttbcr;
 
+    struct {
+        struct vgic_irq_rank private_irqs;
+        struct list_head inflight_irqs;
+        spinlock_t lock;
+    } vgic;
 }  __cacheline_aligned;
 
 void vcpu_show_execution_state(struct vcpu *);
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 16:29:39 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 16: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.xensource.com>)
	id 1RbEBd-0002Vh-Cx; Thu, 15 Dec 2011 16:29:37 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RbEBb-0002Kb-4E
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 16:29:35 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1323966525!56866011!4
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDY5Mjg=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17496 invoked from network); 15 Dec 2011 16:28:53 -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 2011 16:28:53 -0000
X-IronPort-AV: E=Sophos;i="4.71,357,1320642000"; d="scan'208";a="20001876"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Dec 2011 11:29:28 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Thu, 15 Dec 2011 11:29:26 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pBFGSMtk003330;
	Thu, 15 Dec 2011 08:29:08 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Thu, 15 Dec 2011 16:30:54 +0000
Message-ID: <1323966657-19790-22-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1112131831560.3517@kaball-desktop>
References: <alpine.DEB.2.00.1112131831560.3517@kaball-desktop>
MIME-Version: 1.0
Cc: keir.xen@gmail.com, Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, JBeulich@suse.com,
	Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v3 22/25] arm: trap handlers
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Functions executed exiting from the guest and returning to the guest:
trap and hypercall handlers and leave_hypervisor_tail.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
---
 xen/arch/arm/traps.c |  609 ++++++++++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 609 insertions(+), 0 deletions(-)
 create mode 100644 xen/arch/arm/traps.c

diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
new file mode 100644
index 0000000..4346dd7
--- /dev/null
+++ b/xen/arch/arm/traps.c
@@ -0,0 +1,609 @@
+/*
+ * xen/arch/arm/traps.c
+ *
+ * ARM Trap handlers
+ *
+ * Copyright (c) 2011 Citrix Systems.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include <xen/config.h>
+#include <xen/init.h>
+#include <xen/string.h>
+#include <xen/version.h>
+#include <xen/smp.h>
+#include <xen/symbols.h>
+#include <xen/irq.h>
+#include <xen/lib.h>
+#include <xen/mm.h>
+#include <xen/errno.h>
+#include <xen/hypercall.h>
+#include <xen/softirq.h>
+#include <public/xen.h>
+#include <asm/regs.h>
+#include <asm/cpregs.h>
+
+#include "io.h"
+#include "vtimer.h"
+#include "gic.h"
+
+/* The base of the stack must always be double-word aligned, which means
+ * that both the kernel half of struct cpu_user_regs (which is pushed in
+ * entry.S) and struct cpu_info (which lives at the bottom of a Xen
+ * stack) must be doubleword-aligned in size.  */
+static inline void check_stack_alignment_constraints(void) {
+    BUILD_BUG_ON((sizeof (struct cpu_user_regs)) & 0x7);
+    BUILD_BUG_ON((offsetof(struct cpu_user_regs, r8_fiq)) & 0x7);
+    BUILD_BUG_ON((sizeof (struct cpu_info)) & 0x7);
+}
+
+static int debug_stack_lines = 20;
+integer_param("debug_stack_lines", debug_stack_lines);
+
+#define stack_words_per_line 8
+
+asmlinkage void __div0(void)
+{
+    printk("Division by zero in hypervisor.\n");
+    BUG();
+}
+
+/* XXX could/should be common code */
+static void print_xen_info(void)
+{
+    char taint_str[TAINT_STRING_MAX_LEN];
+    char debug = 'n';
+
+#ifndef NDEBUG
+    debug = 'y';
+#endif
+
+    printk("----[ Xen-%d.%d%s  x86_64  debug=%c  %s ]----\n",
+           xen_major_version(), xen_minor_version(), xen_extra_version(),
+           debug, print_tainted(taint_str));
+}
+
+static const char *decode_fsc(uint32_t fsc, int *level)
+{
+    const char *msg = NULL;
+
+    switch ( fsc & 0x3f )
+    {
+    case FSC_FLT_TRANS ... FSC_FLT_TRANS + 3:
+        msg = "Translation fault";
+        *level = fsc & FSC_LL_MASK;
+        break;
+    case FSC_FLT_ACCESS ... FSC_FLT_ACCESS + 3:
+        msg = "Access fault";
+        *level = fsc & FSC_LL_MASK;
+        break;
+    case FSC_FLT_PERM ... FSC_FLT_PERM + 3:
+        msg = "Permission fault";
+        *level = fsc & FSC_LL_MASK;
+        break;
+
+    case FSC_SEA:
+        msg = "Synchronous External Abort";
+        break;
+    case FSC_SPE:
+        msg = "Memory Access Synchronous Parity Error";
+        break;
+    case FSC_APE:
+        msg = "Memory Access Asynchronous Parity Error";
+        break;
+    case FSC_SEATT ... FSC_SEATT + 3:
+        msg = "Sync. Ext. Abort Translation Table";
+        *level = fsc & FSC_LL_MASK;
+        break;
+    case FSC_SPETT ... FSC_SPETT + 3:
+        msg = "Sync. Parity. Error Translation Table";
+        *level = fsc & FSC_LL_MASK;
+        break;
+    case FSC_AF:
+        msg = "Alignment Fault";
+        break;
+    case FSC_DE:
+        msg = "Debug Event";
+        break;
+
+    case FSC_LKD:
+        msg = "Implementation Fault: Lockdown Abort";
+        break;
+    case FSC_CPR:
+        msg = "Implementation Fault: Coprocossor Abort";
+        break;
+
+    default:
+        msg = "Unknown Failure";
+        break;
+    }
+    return msg;
+}
+
+static const char *fsc_level_str(int level)
+{
+    switch ( level )
+    {
+    case -1: return "";
+    case 1:  return " at level 1";
+    case 2:  return " at level 2";
+    case 3:  return " at level 3";
+    default: return " (level invalid)";
+    }
+}
+
+void panic_PAR(uint64_t par, const char *when)
+{
+    if ( par & PAR_F )
+    {
+        const char *msg;
+        int level = -1;
+        int stage = par & PAR_STAGE2 ? 2 : 1;
+        int second_in_first = !!(par & PAR_STAGE21);
+
+        msg = decode_fsc( (par&PAR_FSC_MASK) >> PAR_FSC_SHIFT, &level);
+
+        printk("PAR: %010"PRIx64": %s stage %d%s%s\n",
+               par, msg,
+               stage,
+               second_in_first ? " during second stage lookup" : "",
+               fsc_level_str(level));
+    }
+    else
+    {
+        printk("PAR: %010"PRIx64": paddr:%010"PRIx64
+               " attr %"PRIx64" sh %"PRIx64" %s\n",
+               par, par & PADDR_MASK, par >> PAR_MAIR_SHIFT,
+               (par & PAR_SH_MASK) >> PAR_SH_SHIFT,
+               (par & PAR_NS) ? "Non-Secure" : "Secure");
+    }
+    panic("Error during %s-to-physical address translation\n", when);
+}
+
+void show_registers(struct cpu_user_regs *regs)
+{
+    static const char *mode_strings[] = {
+       [PSR_MODE_USR] = "USR",
+       [PSR_MODE_FIQ] = "FIQ",
+       [PSR_MODE_IRQ] = "IRQ",
+       [PSR_MODE_SVC] = "SVC",
+       [PSR_MODE_MON] = "MON",
+       [PSR_MODE_ABT] = "ABT",
+       [PSR_MODE_HYP] = "HYP",
+       [PSR_MODE_UND] = "UND",
+       [PSR_MODE_SYS] = "SYS"
+    };
+
+    print_xen_info();
+    printk("CPU:    %d\n", smp_processor_id());
+    printk("PC:     %08"PRIx32, regs->pc);
+    if ( !guest_mode(regs) )
+            print_symbol(" %s", regs->pc);
+    printk("\n");
+    printk("CPSR:   %08"PRIx32" MODE:%s\n", regs->cpsr,
+           mode_strings[regs->cpsr & PSR_MODE_MASK]);
+    printk("     R0: %08"PRIx32" R1: %08"PRIx32" R2: %08"PRIx32" R3: %08"PRIx32"\n",
+           regs->r0, regs->r1, regs->r2, regs->r3);
+    printk("     R4: %08"PRIx32" R5: %08"PRIx32" R6: %08"PRIx32" R7: %08"PRIx32"\n",
+           regs->r4, regs->r5, regs->r6, regs->r7);
+    printk("     R8: %08"PRIx32" R9: %08"PRIx32" R10:%08"PRIx32" R11:%08"PRIx32" R12:%08"PRIx32"\n",
+           regs->r8, regs->r9, regs->r10, regs->r11, regs->r12);
+
+    if ( guest_mode(regs) )
+    {
+        printk("USR: SP: %08"PRIx32" LR: %08"PRIx32" CPSR:%08"PRIx32"\n",
+               regs->sp_usr, regs->lr_usr, regs->cpsr);
+        printk("SVC: SP: %08"PRIx32" LR: %08"PRIx32" SPSR:%08"PRIx32"\n",
+               regs->sp_svc, regs->lr_svc, regs->spsr_svc);
+        printk("ABT: SP: %08"PRIx32" LR: %08"PRIx32" SPSR:%08"PRIx32"\n",
+               regs->sp_abt, regs->lr_abt, regs->spsr_abt);
+        printk("UND: SP: %08"PRIx32" LR: %08"PRIx32" SPSR:%08"PRIx32"\n",
+               regs->sp_und, regs->lr_und, regs->spsr_und);
+        printk("IRQ: SP: %08"PRIx32" LR: %08"PRIx32" SPSR:%08"PRIx32"\n",
+               regs->sp_irq, regs->lr_irq, regs->spsr_irq);
+        printk("FIQ: SP: %08"PRIx32" LR: %08"PRIx32" SPSR:%08"PRIx32"\n",
+               regs->sp_fiq, regs->lr_fiq, regs->spsr_fiq);
+        printk("FIQ: R8: %08"PRIx32" R9: %08"PRIx32" R10:%08"PRIx32" R11:%08"PRIx32" R12:%08"PRIx32"\n",
+               regs->r8_fiq, regs->r9_fiq, regs->r10_fiq, regs->r11_fiq, regs->r11_fiq);
+        printk("\n");
+        printk("TTBR0 %08"PRIx32" TTBR1 %08"PRIx32" TTBCR %08"PRIx32"\n",
+               READ_CP32(TTBR0), READ_CP32(TTBR1), READ_CP32(TTBCR));
+        printk("SCTLR %08"PRIx32"\n", READ_CP32(SCTLR));
+        printk("VTTBR %010"PRIx64"\n", READ_CP64(VTTBR));
+        printk("\n");
+    }
+    else
+    {
+        printk("     SP: %08"PRIx32" LR: %08"PRIx32"\n", regs->sp, regs->lr);
+        printk("\n");
+    }
+
+    printk("HTTBR %"PRIx64"\n", READ_CP64(HTTBR));
+    printk("HDFAR %"PRIx32"\n", READ_CP32(HDFAR));
+    printk("HIFAR %"PRIx32"\n", READ_CP32(HIFAR));
+    printk("HPFAR %"PRIx32"\n", READ_CP32(HPFAR));
+    printk("HCR %08"PRIx32"\n", READ_CP32(HCR));
+    printk("HSR   %"PRIx32"\n", READ_CP32(HSR));
+    printk("\n");
+
+    printk("DFSR %"PRIx32" DFAR %"PRIx32"\n", READ_CP32(DFSR), READ_CP32(DFAR));
+    printk("IFSR %"PRIx32" IFAR %"PRIx32"\n", READ_CP32(IFSR), READ_CP32(IFAR));
+    printk("\n");
+}
+
+static void show_guest_stack(struct cpu_user_regs *regs)
+{
+    printk("GUEST STACK GOES HERE\n");
+}
+
+#define STACK_BEFORE_EXCEPTION(regs) ((uint32_t*)(regs)->sp)
+
+static void show_trace(struct cpu_user_regs *regs)
+{
+    uint32_t *frame, next, addr, low, high;
+
+    printk("Xen call trace:\n   ");
+
+    printk("[<%p>]", _p(regs->pc));
+    print_symbol(" %s\n   ", regs->pc);
+
+    /* Bounds for range of valid frame pointer. */
+    low  = (uint32_t)(STACK_BEFORE_EXCEPTION(regs)/* - 2*/);
+    high = (low & ~(STACK_SIZE - 1)) +
+        (STACK_SIZE - sizeof(struct cpu_info));
+
+    /* Frame:
+     * (largest address)
+     * | cpu_info
+     * | [...]                                   |
+     * | return addr      <-----------------,    |
+     * | fp --------------------------------+----'
+     * | [...]                              |
+     * | return addr      <------------,    |
+     * | fp ---------------------------+----'
+     * | [...]                         |
+     * | return addr      <- regs->fp  |
+     * | fp ---------------------------'
+     * |
+     * v (smallest address, sp)
+     */
+
+    /* The initial frame pointer. */
+    next = regs->fp;
+
+    for ( ; ; )
+    {
+        if ( (next < low) || (next >= high) )
+            break;
+        {
+            /* Ordinary stack frame. */
+            frame = (uint32_t *)next;
+            next  = frame[-1];
+            addr  = frame[0];
+        }
+
+        printk("[<%p>]", _p(addr));
+        print_symbol(" %s\n   ", addr);
+
+        low = (uint32_t)&frame[1];
+    }
+
+    printk("\n");
+}
+
+void show_stack(struct cpu_user_regs *regs)
+{
+    uint32_t *stack = STACK_BEFORE_EXCEPTION(regs), addr;
+    int i;
+
+    if ( guest_mode(regs) )
+        return show_guest_stack(regs);
+
+    printk("Xen stack trace from sp=%p:\n  ", stack);
+
+    for ( i = 0; i < (debug_stack_lines*stack_words_per_line); i++ )
+    {
+        if ( ((long)stack & (STACK_SIZE-BYTES_PER_LONG)) == 0 )
+            break;
+        if ( (i != 0) && ((i % stack_words_per_line) == 0) )
+            printk("\n  ");
+
+        addr = *stack++;
+        printk(" %p", _p(addr));
+    }
+    if ( i == 0 )
+        printk("Stack empty.");
+    printk("\n");
+
+    show_trace(regs);
+}
+
+void show_execution_state(struct cpu_user_regs *regs)
+{
+    show_registers(regs);
+    show_stack(regs);
+}
+
+static void do_unexpected_trap(const char *msg, struct cpu_user_regs *regs)
+{
+    printk("Unexpected Trap: %s\n", msg);
+    show_execution_state(regs);
+    while(1);
+}
+
+asmlinkage void do_trap_undefined_instruction(struct cpu_user_regs *regs)
+{
+    do_unexpected_trap("Undefined Instruction", regs);
+}
+
+asmlinkage void do_trap_supervisor_call(struct cpu_user_regs *regs)
+{
+    do_unexpected_trap("Supervisor Call", regs);
+}
+
+asmlinkage void do_trap_prefetch_abort(struct cpu_user_regs *regs)
+{
+    do_unexpected_trap("Prefetch Abort", regs);
+}
+
+asmlinkage void do_trap_data_abort(struct cpu_user_regs *regs)
+{
+    do_unexpected_trap("Data Abort", regs);
+}
+
+unsigned long do_arch_0(unsigned int cmd, unsigned long long value)
+{
+        printk("do_arch_0 cmd=%x arg=%llx\n", cmd, value);
+        return 0;
+}
+
+typedef unsigned long arm_hypercall_t(
+    unsigned int, unsigned int, unsigned int, unsigned int, unsigned int,
+    unsigned int, unsigned int, unsigned int, unsigned int, unsigned int);
+
+#define HYPERCALL(x)                                        \
+    [ __HYPERVISOR_ ## x ] = (arm_hypercall_t *) do_ ## x
+
+static arm_hypercall_t *arm_hypercall_table[] = {
+    HYPERCALL(arch_0),
+    HYPERCALL(sched_op),
+    HYPERCALL(console_io),
+};
+
+static void do_debug_trap(struct cpu_user_regs *regs, unsigned int code)
+{
+    uint32_t reg, *r;
+
+    switch ( code ) {
+    case 0xe0 ... 0xef:
+        reg = code - 0xe0;
+        r = &regs->r0 + reg;
+        printk("R%d = %#010"PRIx32" at %#010"PRIx32"\n", reg, *r, regs->pc);
+        break;
+    case 0xfd:
+        printk("Reached %08"PRIx32"\n", regs->pc);
+        break;
+    case 0xfe:
+        printk("%c", (char)(regs->r0 & 0xff));
+        break;
+    case 0xff:
+        printk("DEBUG\n");
+        show_execution_state(regs);
+        break;
+    default:
+        panic("Unhandled debug trap %#x\n", code);
+        break;
+    }
+}
+
+static void do_trap_hypercall(struct cpu_user_regs *regs, unsigned long iss)
+{
+    local_irq_enable();
+
+    regs->r0 = arm_hypercall_table[iss](regs->r0,
+                             regs->r1,
+                             regs->r2,
+                             regs->r3,
+                             regs->r4,
+                             regs->r5,
+                             regs->r6,
+                             regs->r7,
+                             regs->r8,
+                             regs->r9);
+}
+
+static void do_cp15_32(struct cpu_user_regs *regs,
+                       union hsr hsr)
+{
+    struct hsr_cp32 cp32 = hsr.cp32;
+    uint32_t *r = &regs->r0 + cp32.reg;
+
+    if ( !cp32.ccvalid ) {
+        dprintk(XENLOG_ERR, "cp_15(32): need to handle invalid condition codes\n");
+        domain_crash_synchronous();
+    }
+    if ( cp32.cc != 0xe ) {
+        dprintk(XENLOG_ERR, "cp_15(32): need to handle condition codes %x\n",
+                cp32.cc);
+        domain_crash_synchronous();
+    }
+
+    switch ( hsr.bits & HSR_CP32_REGS_MASK )
+    {
+    case HSR_CPREG32(CLIDR):
+        if ( !cp32.read )
+        {
+            dprintk(XENLOG_ERR,
+                    "attempt to write to read-only register CLIDR\n");
+            domain_crash_synchronous();
+        }
+        *r = READ_CP32(CLIDR);
+        break;
+    case HSR_CPREG32(CCSIDR):
+        if ( !cp32.read )
+        {
+            dprintk(XENLOG_ERR,
+                    "attempt to write to read-only register CSSIDR\n");
+            domain_crash_synchronous();
+        }
+        *r = READ_CP32(CCSIDR);
+        break;
+    case HSR_CPREG32(DCCISW):
+        if ( cp32.read )
+        {
+            dprintk(XENLOG_ERR,
+                    "attempt to read from write-only register DCCISW\n");
+            domain_crash_synchronous();
+        }
+        WRITE_CP32(*r, DCCISW);
+        break;
+    case HSR_CPREG32(CNTP_CTL):
+    case HSR_CPREG32(CNTP_TVAL):
+        /* emulate timer */
+        break;
+    default:
+        printk("%s p15, %d, r%d, cr%d, cr%d, %d @ %#08x\n",
+               cp32.read ? "mrc" : "mcr",
+               cp32.op1, cp32.reg, cp32.crn, cp32.crm, cp32.op2, regs->pc);
+        panic("unhandled 32-bit CP15 access %#x\n", hsr.bits & HSR_CP32_REGS_MASK);
+    }
+    regs->pc += cp32.len ? 4 : 2;
+
+}
+
+static void do_cp15_64(struct cpu_user_regs *regs,
+                       union hsr hsr)
+{
+    struct hsr_cp64 cp64 = hsr.cp64;
+
+    if ( !cp64.ccvalid ) {
+        dprintk(XENLOG_ERR, "cp_15(64): need to handle invalid condition codes\n");
+        domain_crash_synchronous();
+    }
+    if ( cp64.cc != 0xe ) {
+        dprintk(XENLOG_ERR, "cp_15(64): need to handle condition codes %x\n",
+                cp64.cc);
+        domain_crash_synchronous();
+    }
+
+    switch ( hsr.bits & HSR_CP64_REGS_MASK )
+    {
+    case HSR_CPREG64(CNTPCT):
+        /* emulate timer */
+        break;
+    default:
+        printk("%s p15, %d, r%d, r%d, cr%d @ %#08x\n",
+               cp64.read ? "mrrc" : "mcrr",
+               cp64.op1, cp64.reg1, cp64.reg2, cp64.crm, regs->pc);
+        panic("unhandled 64-bit CP15 access %#x\n", hsr.bits & HSR_CP64_REGS_MASK);
+    }
+    regs->pc += cp64.len ? 4 : 2;
+
+}
+
+static void do_trap_data_abort_guest(struct cpu_user_regs *regs,
+                                     struct hsr_dabt dabt)
+{
+    const char *msg;
+    int level = -1;
+    mmio_info_t info;
+
+    if (dabt.s1ptw)
+        goto bad_data_abort;
+
+    info.dabt = dabt;
+    info.gva = READ_CP32(HDFAR);
+    info.gpa = gva_to_ipa(info.gva);
+
+    if (handle_mmio(&info))
+    {
+        regs->pc += dabt.len ? 4 : 2;
+        return;
+    }
+
+bad_data_abort:
+
+    msg = decode_fsc( dabt.dfsc, &level);
+
+    printk("Guest data abort: %s%s%s\n"
+           "    gva=%"PRIx32" gpa=%"PRIpaddr"\n",
+           msg, dabt.s1ptw ? " S2 during S1" : "",
+           fsc_level_str(level),
+           info.gva, info.gpa);
+    if (dabt.valid)
+        printk("    size=%d sign=%d write=%d reg=%d\n",
+               dabt.size, dabt.sign, dabt.write, dabt.reg);
+    else
+        printk("    instruction syndrome invalid\n");
+    printk("    eat=%d cm=%d s1ptw=%d dfsc=%d\n",
+           dabt.eat, dabt.cache, dabt.s1ptw, dabt.dfsc);
+
+    show_execution_state(regs);
+    panic("Unhandled guest data abort\n");
+}
+
+asmlinkage void do_trap_hypervisor(struct cpu_user_regs *regs)
+{
+    union hsr hsr = { .bits = READ_CP32(HSR) };
+
+    switch (hsr.ec) {
+    case HSR_EC_CP15_32:
+        do_cp15_32(regs, hsr);
+        break;
+    case HSR_EC_CP15_64:
+        do_cp15_64(regs, hsr);
+        break;
+    case HSR_EC_HVC:
+        if ( (hsr.iss & 0xff00) == 0xff00 )
+            return do_debug_trap(regs, hsr.iss & 0x00ff);
+        do_trap_hypercall(regs, hsr.iss);
+        break;
+    case HSR_EC_DATA_ABORT_GUEST:
+        do_trap_data_abort_guest(regs, hsr.dabt);
+        break;
+    default:
+        printk("Hypervisor Trap. HSR=0x%x EC=0x%x IL=%x Syndrome=%"PRIx32"\n",
+               hsr.bits, hsr.ec, hsr.len, hsr.iss);
+        do_unexpected_trap("Hypervisor", regs);
+    }
+}
+
+asmlinkage void do_trap_irq(struct cpu_user_regs *regs)
+{
+    gic_interrupt(regs, 0);
+}
+
+asmlinkage void do_trap_fiq(struct cpu_user_regs *regs)
+{
+    gic_interrupt(regs, 1);
+}
+
+asmlinkage void leave_hypervisor_tail(void)
+{
+    while (1)
+    {
+        local_irq_disable();
+        if (!softirq_pending(smp_processor_id()))
+            return;
+        local_irq_enable();
+        do_softirq();
+    }
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 16:29:39 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 16: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.xensource.com>)
	id 1RbEBd-0002Vh-Cx; Thu, 15 Dec 2011 16:29:37 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RbEBb-0002Kb-4E
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 16:29:35 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1323966525!56866011!4
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDY5Mjg=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17496 invoked from network); 15 Dec 2011 16:28:53 -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 2011 16:28:53 -0000
X-IronPort-AV: E=Sophos;i="4.71,357,1320642000"; d="scan'208";a="20001876"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Dec 2011 11:29:28 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Thu, 15 Dec 2011 11:29:26 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pBFGSMtk003330;
	Thu, 15 Dec 2011 08:29:08 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Thu, 15 Dec 2011 16:30:54 +0000
Message-ID: <1323966657-19790-22-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1112131831560.3517@kaball-desktop>
References: <alpine.DEB.2.00.1112131831560.3517@kaball-desktop>
MIME-Version: 1.0
Cc: keir.xen@gmail.com, Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, JBeulich@suse.com,
	Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v3 22/25] arm: trap handlers
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Functions executed exiting from the guest and returning to the guest:
trap and hypercall handlers and leave_hypervisor_tail.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
---
 xen/arch/arm/traps.c |  609 ++++++++++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 609 insertions(+), 0 deletions(-)
 create mode 100644 xen/arch/arm/traps.c

diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
new file mode 100644
index 0000000..4346dd7
--- /dev/null
+++ b/xen/arch/arm/traps.c
@@ -0,0 +1,609 @@
+/*
+ * xen/arch/arm/traps.c
+ *
+ * ARM Trap handlers
+ *
+ * Copyright (c) 2011 Citrix Systems.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include <xen/config.h>
+#include <xen/init.h>
+#include <xen/string.h>
+#include <xen/version.h>
+#include <xen/smp.h>
+#include <xen/symbols.h>
+#include <xen/irq.h>
+#include <xen/lib.h>
+#include <xen/mm.h>
+#include <xen/errno.h>
+#include <xen/hypercall.h>
+#include <xen/softirq.h>
+#include <public/xen.h>
+#include <asm/regs.h>
+#include <asm/cpregs.h>
+
+#include "io.h"
+#include "vtimer.h"
+#include "gic.h"
+
+/* The base of the stack must always be double-word aligned, which means
+ * that both the kernel half of struct cpu_user_regs (which is pushed in
+ * entry.S) and struct cpu_info (which lives at the bottom of a Xen
+ * stack) must be doubleword-aligned in size.  */
+static inline void check_stack_alignment_constraints(void) {
+    BUILD_BUG_ON((sizeof (struct cpu_user_regs)) & 0x7);
+    BUILD_BUG_ON((offsetof(struct cpu_user_regs, r8_fiq)) & 0x7);
+    BUILD_BUG_ON((sizeof (struct cpu_info)) & 0x7);
+}
+
+static int debug_stack_lines = 20;
+integer_param("debug_stack_lines", debug_stack_lines);
+
+#define stack_words_per_line 8
+
+asmlinkage void __div0(void)
+{
+    printk("Division by zero in hypervisor.\n");
+    BUG();
+}
+
+/* XXX could/should be common code */
+static void print_xen_info(void)
+{
+    char taint_str[TAINT_STRING_MAX_LEN];
+    char debug = 'n';
+
+#ifndef NDEBUG
+    debug = 'y';
+#endif
+
+    printk("----[ Xen-%d.%d%s  x86_64  debug=%c  %s ]----\n",
+           xen_major_version(), xen_minor_version(), xen_extra_version(),
+           debug, print_tainted(taint_str));
+}
+
+static const char *decode_fsc(uint32_t fsc, int *level)
+{
+    const char *msg = NULL;
+
+    switch ( fsc & 0x3f )
+    {
+    case FSC_FLT_TRANS ... FSC_FLT_TRANS + 3:
+        msg = "Translation fault";
+        *level = fsc & FSC_LL_MASK;
+        break;
+    case FSC_FLT_ACCESS ... FSC_FLT_ACCESS + 3:
+        msg = "Access fault";
+        *level = fsc & FSC_LL_MASK;
+        break;
+    case FSC_FLT_PERM ... FSC_FLT_PERM + 3:
+        msg = "Permission fault";
+        *level = fsc & FSC_LL_MASK;
+        break;
+
+    case FSC_SEA:
+        msg = "Synchronous External Abort";
+        break;
+    case FSC_SPE:
+        msg = "Memory Access Synchronous Parity Error";
+        break;
+    case FSC_APE:
+        msg = "Memory Access Asynchronous Parity Error";
+        break;
+    case FSC_SEATT ... FSC_SEATT + 3:
+        msg = "Sync. Ext. Abort Translation Table";
+        *level = fsc & FSC_LL_MASK;
+        break;
+    case FSC_SPETT ... FSC_SPETT + 3:
+        msg = "Sync. Parity. Error Translation Table";
+        *level = fsc & FSC_LL_MASK;
+        break;
+    case FSC_AF:
+        msg = "Alignment Fault";
+        break;
+    case FSC_DE:
+        msg = "Debug Event";
+        break;
+
+    case FSC_LKD:
+        msg = "Implementation Fault: Lockdown Abort";
+        break;
+    case FSC_CPR:
+        msg = "Implementation Fault: Coprocossor Abort";
+        break;
+
+    default:
+        msg = "Unknown Failure";
+        break;
+    }
+    return msg;
+}
+
+static const char *fsc_level_str(int level)
+{
+    switch ( level )
+    {
+    case -1: return "";
+    case 1:  return " at level 1";
+    case 2:  return " at level 2";
+    case 3:  return " at level 3";
+    default: return " (level invalid)";
+    }
+}
+
+void panic_PAR(uint64_t par, const char *when)
+{
+    if ( par & PAR_F )
+    {
+        const char *msg;
+        int level = -1;
+        int stage = par & PAR_STAGE2 ? 2 : 1;
+        int second_in_first = !!(par & PAR_STAGE21);
+
+        msg = decode_fsc( (par&PAR_FSC_MASK) >> PAR_FSC_SHIFT, &level);
+
+        printk("PAR: %010"PRIx64": %s stage %d%s%s\n",
+               par, msg,
+               stage,
+               second_in_first ? " during second stage lookup" : "",
+               fsc_level_str(level));
+    }
+    else
+    {
+        printk("PAR: %010"PRIx64": paddr:%010"PRIx64
+               " attr %"PRIx64" sh %"PRIx64" %s\n",
+               par, par & PADDR_MASK, par >> PAR_MAIR_SHIFT,
+               (par & PAR_SH_MASK) >> PAR_SH_SHIFT,
+               (par & PAR_NS) ? "Non-Secure" : "Secure");
+    }
+    panic("Error during %s-to-physical address translation\n", when);
+}
+
+void show_registers(struct cpu_user_regs *regs)
+{
+    static const char *mode_strings[] = {
+       [PSR_MODE_USR] = "USR",
+       [PSR_MODE_FIQ] = "FIQ",
+       [PSR_MODE_IRQ] = "IRQ",
+       [PSR_MODE_SVC] = "SVC",
+       [PSR_MODE_MON] = "MON",
+       [PSR_MODE_ABT] = "ABT",
+       [PSR_MODE_HYP] = "HYP",
+       [PSR_MODE_UND] = "UND",
+       [PSR_MODE_SYS] = "SYS"
+    };
+
+    print_xen_info();
+    printk("CPU:    %d\n", smp_processor_id());
+    printk("PC:     %08"PRIx32, regs->pc);
+    if ( !guest_mode(regs) )
+            print_symbol(" %s", regs->pc);
+    printk("\n");
+    printk("CPSR:   %08"PRIx32" MODE:%s\n", regs->cpsr,
+           mode_strings[regs->cpsr & PSR_MODE_MASK]);
+    printk("     R0: %08"PRIx32" R1: %08"PRIx32" R2: %08"PRIx32" R3: %08"PRIx32"\n",
+           regs->r0, regs->r1, regs->r2, regs->r3);
+    printk("     R4: %08"PRIx32" R5: %08"PRIx32" R6: %08"PRIx32" R7: %08"PRIx32"\n",
+           regs->r4, regs->r5, regs->r6, regs->r7);
+    printk("     R8: %08"PRIx32" R9: %08"PRIx32" R10:%08"PRIx32" R11:%08"PRIx32" R12:%08"PRIx32"\n",
+           regs->r8, regs->r9, regs->r10, regs->r11, regs->r12);
+
+    if ( guest_mode(regs) )
+    {
+        printk("USR: SP: %08"PRIx32" LR: %08"PRIx32" CPSR:%08"PRIx32"\n",
+               regs->sp_usr, regs->lr_usr, regs->cpsr);
+        printk("SVC: SP: %08"PRIx32" LR: %08"PRIx32" SPSR:%08"PRIx32"\n",
+               regs->sp_svc, regs->lr_svc, regs->spsr_svc);
+        printk("ABT: SP: %08"PRIx32" LR: %08"PRIx32" SPSR:%08"PRIx32"\n",
+               regs->sp_abt, regs->lr_abt, regs->spsr_abt);
+        printk("UND: SP: %08"PRIx32" LR: %08"PRIx32" SPSR:%08"PRIx32"\n",
+               regs->sp_und, regs->lr_und, regs->spsr_und);
+        printk("IRQ: SP: %08"PRIx32" LR: %08"PRIx32" SPSR:%08"PRIx32"\n",
+               regs->sp_irq, regs->lr_irq, regs->spsr_irq);
+        printk("FIQ: SP: %08"PRIx32" LR: %08"PRIx32" SPSR:%08"PRIx32"\n",
+               regs->sp_fiq, regs->lr_fiq, regs->spsr_fiq);
+        printk("FIQ: R8: %08"PRIx32" R9: %08"PRIx32" R10:%08"PRIx32" R11:%08"PRIx32" R12:%08"PRIx32"\n",
+               regs->r8_fiq, regs->r9_fiq, regs->r10_fiq, regs->r11_fiq, regs->r11_fiq);
+        printk("\n");
+        printk("TTBR0 %08"PRIx32" TTBR1 %08"PRIx32" TTBCR %08"PRIx32"\n",
+               READ_CP32(TTBR0), READ_CP32(TTBR1), READ_CP32(TTBCR));
+        printk("SCTLR %08"PRIx32"\n", READ_CP32(SCTLR));
+        printk("VTTBR %010"PRIx64"\n", READ_CP64(VTTBR));
+        printk("\n");
+    }
+    else
+    {
+        printk("     SP: %08"PRIx32" LR: %08"PRIx32"\n", regs->sp, regs->lr);
+        printk("\n");
+    }
+
+    printk("HTTBR %"PRIx64"\n", READ_CP64(HTTBR));
+    printk("HDFAR %"PRIx32"\n", READ_CP32(HDFAR));
+    printk("HIFAR %"PRIx32"\n", READ_CP32(HIFAR));
+    printk("HPFAR %"PRIx32"\n", READ_CP32(HPFAR));
+    printk("HCR %08"PRIx32"\n", READ_CP32(HCR));
+    printk("HSR   %"PRIx32"\n", READ_CP32(HSR));
+    printk("\n");
+
+    printk("DFSR %"PRIx32" DFAR %"PRIx32"\n", READ_CP32(DFSR), READ_CP32(DFAR));
+    printk("IFSR %"PRIx32" IFAR %"PRIx32"\n", READ_CP32(IFSR), READ_CP32(IFAR));
+    printk("\n");
+}
+
+static void show_guest_stack(struct cpu_user_regs *regs)
+{
+    printk("GUEST STACK GOES HERE\n");
+}
+
+#define STACK_BEFORE_EXCEPTION(regs) ((uint32_t*)(regs)->sp)
+
+static void show_trace(struct cpu_user_regs *regs)
+{
+    uint32_t *frame, next, addr, low, high;
+
+    printk("Xen call trace:\n   ");
+
+    printk("[<%p>]", _p(regs->pc));
+    print_symbol(" %s\n   ", regs->pc);
+
+    /* Bounds for range of valid frame pointer. */
+    low  = (uint32_t)(STACK_BEFORE_EXCEPTION(regs)/* - 2*/);
+    high = (low & ~(STACK_SIZE - 1)) +
+        (STACK_SIZE - sizeof(struct cpu_info));
+
+    /* Frame:
+     * (largest address)
+     * | cpu_info
+     * | [...]                                   |
+     * | return addr      <-----------------,    |
+     * | fp --------------------------------+----'
+     * | [...]                              |
+     * | return addr      <------------,    |
+     * | fp ---------------------------+----'
+     * | [...]                         |
+     * | return addr      <- regs->fp  |
+     * | fp ---------------------------'
+     * |
+     * v (smallest address, sp)
+     */
+
+    /* The initial frame pointer. */
+    next = regs->fp;
+
+    for ( ; ; )
+    {
+        if ( (next < low) || (next >= high) )
+            break;
+        {
+            /* Ordinary stack frame. */
+            frame = (uint32_t *)next;
+            next  = frame[-1];
+            addr  = frame[0];
+        }
+
+        printk("[<%p>]", _p(addr));
+        print_symbol(" %s\n   ", addr);
+
+        low = (uint32_t)&frame[1];
+    }
+
+    printk("\n");
+}
+
+void show_stack(struct cpu_user_regs *regs)
+{
+    uint32_t *stack = STACK_BEFORE_EXCEPTION(regs), addr;
+    int i;
+
+    if ( guest_mode(regs) )
+        return show_guest_stack(regs);
+
+    printk("Xen stack trace from sp=%p:\n  ", stack);
+
+    for ( i = 0; i < (debug_stack_lines*stack_words_per_line); i++ )
+    {
+        if ( ((long)stack & (STACK_SIZE-BYTES_PER_LONG)) == 0 )
+            break;
+        if ( (i != 0) && ((i % stack_words_per_line) == 0) )
+            printk("\n  ");
+
+        addr = *stack++;
+        printk(" %p", _p(addr));
+    }
+    if ( i == 0 )
+        printk("Stack empty.");
+    printk("\n");
+
+    show_trace(regs);
+}
+
+void show_execution_state(struct cpu_user_regs *regs)
+{
+    show_registers(regs);
+    show_stack(regs);
+}
+
+static void do_unexpected_trap(const char *msg, struct cpu_user_regs *regs)
+{
+    printk("Unexpected Trap: %s\n", msg);
+    show_execution_state(regs);
+    while(1);
+}
+
+asmlinkage void do_trap_undefined_instruction(struct cpu_user_regs *regs)
+{
+    do_unexpected_trap("Undefined Instruction", regs);
+}
+
+asmlinkage void do_trap_supervisor_call(struct cpu_user_regs *regs)
+{
+    do_unexpected_trap("Supervisor Call", regs);
+}
+
+asmlinkage void do_trap_prefetch_abort(struct cpu_user_regs *regs)
+{
+    do_unexpected_trap("Prefetch Abort", regs);
+}
+
+asmlinkage void do_trap_data_abort(struct cpu_user_regs *regs)
+{
+    do_unexpected_trap("Data Abort", regs);
+}
+
+unsigned long do_arch_0(unsigned int cmd, unsigned long long value)
+{
+        printk("do_arch_0 cmd=%x arg=%llx\n", cmd, value);
+        return 0;
+}
+
+typedef unsigned long arm_hypercall_t(
+    unsigned int, unsigned int, unsigned int, unsigned int, unsigned int,
+    unsigned int, unsigned int, unsigned int, unsigned int, unsigned int);
+
+#define HYPERCALL(x)                                        \
+    [ __HYPERVISOR_ ## x ] = (arm_hypercall_t *) do_ ## x
+
+static arm_hypercall_t *arm_hypercall_table[] = {
+    HYPERCALL(arch_0),
+    HYPERCALL(sched_op),
+    HYPERCALL(console_io),
+};
+
+static void do_debug_trap(struct cpu_user_regs *regs, unsigned int code)
+{
+    uint32_t reg, *r;
+
+    switch ( code ) {
+    case 0xe0 ... 0xef:
+        reg = code - 0xe0;
+        r = &regs->r0 + reg;
+        printk("R%d = %#010"PRIx32" at %#010"PRIx32"\n", reg, *r, regs->pc);
+        break;
+    case 0xfd:
+        printk("Reached %08"PRIx32"\n", regs->pc);
+        break;
+    case 0xfe:
+        printk("%c", (char)(regs->r0 & 0xff));
+        break;
+    case 0xff:
+        printk("DEBUG\n");
+        show_execution_state(regs);
+        break;
+    default:
+        panic("Unhandled debug trap %#x\n", code);
+        break;
+    }
+}
+
+static void do_trap_hypercall(struct cpu_user_regs *regs, unsigned long iss)
+{
+    local_irq_enable();
+
+    regs->r0 = arm_hypercall_table[iss](regs->r0,
+                             regs->r1,
+                             regs->r2,
+                             regs->r3,
+                             regs->r4,
+                             regs->r5,
+                             regs->r6,
+                             regs->r7,
+                             regs->r8,
+                             regs->r9);
+}
+
+static void do_cp15_32(struct cpu_user_regs *regs,
+                       union hsr hsr)
+{
+    struct hsr_cp32 cp32 = hsr.cp32;
+    uint32_t *r = &regs->r0 + cp32.reg;
+
+    if ( !cp32.ccvalid ) {
+        dprintk(XENLOG_ERR, "cp_15(32): need to handle invalid condition codes\n");
+        domain_crash_synchronous();
+    }
+    if ( cp32.cc != 0xe ) {
+        dprintk(XENLOG_ERR, "cp_15(32): need to handle condition codes %x\n",
+                cp32.cc);
+        domain_crash_synchronous();
+    }
+
+    switch ( hsr.bits & HSR_CP32_REGS_MASK )
+    {
+    case HSR_CPREG32(CLIDR):
+        if ( !cp32.read )
+        {
+            dprintk(XENLOG_ERR,
+                    "attempt to write to read-only register CLIDR\n");
+            domain_crash_synchronous();
+        }
+        *r = READ_CP32(CLIDR);
+        break;
+    case HSR_CPREG32(CCSIDR):
+        if ( !cp32.read )
+        {
+            dprintk(XENLOG_ERR,
+                    "attempt to write to read-only register CSSIDR\n");
+            domain_crash_synchronous();
+        }
+        *r = READ_CP32(CCSIDR);
+        break;
+    case HSR_CPREG32(DCCISW):
+        if ( cp32.read )
+        {
+            dprintk(XENLOG_ERR,
+                    "attempt to read from write-only register DCCISW\n");
+            domain_crash_synchronous();
+        }
+        WRITE_CP32(*r, DCCISW);
+        break;
+    case HSR_CPREG32(CNTP_CTL):
+    case HSR_CPREG32(CNTP_TVAL):
+        /* emulate timer */
+        break;
+    default:
+        printk("%s p15, %d, r%d, cr%d, cr%d, %d @ %#08x\n",
+               cp32.read ? "mrc" : "mcr",
+               cp32.op1, cp32.reg, cp32.crn, cp32.crm, cp32.op2, regs->pc);
+        panic("unhandled 32-bit CP15 access %#x\n", hsr.bits & HSR_CP32_REGS_MASK);
+    }
+    regs->pc += cp32.len ? 4 : 2;
+
+}
+
+static void do_cp15_64(struct cpu_user_regs *regs,
+                       union hsr hsr)
+{
+    struct hsr_cp64 cp64 = hsr.cp64;
+
+    if ( !cp64.ccvalid ) {
+        dprintk(XENLOG_ERR, "cp_15(64): need to handle invalid condition codes\n");
+        domain_crash_synchronous();
+    }
+    if ( cp64.cc != 0xe ) {
+        dprintk(XENLOG_ERR, "cp_15(64): need to handle condition codes %x\n",
+                cp64.cc);
+        domain_crash_synchronous();
+    }
+
+    switch ( hsr.bits & HSR_CP64_REGS_MASK )
+    {
+    case HSR_CPREG64(CNTPCT):
+        /* emulate timer */
+        break;
+    default:
+        printk("%s p15, %d, r%d, r%d, cr%d @ %#08x\n",
+               cp64.read ? "mrrc" : "mcrr",
+               cp64.op1, cp64.reg1, cp64.reg2, cp64.crm, regs->pc);
+        panic("unhandled 64-bit CP15 access %#x\n", hsr.bits & HSR_CP64_REGS_MASK);
+    }
+    regs->pc += cp64.len ? 4 : 2;
+
+}
+
+static void do_trap_data_abort_guest(struct cpu_user_regs *regs,
+                                     struct hsr_dabt dabt)
+{
+    const char *msg;
+    int level = -1;
+    mmio_info_t info;
+
+    if (dabt.s1ptw)
+        goto bad_data_abort;
+
+    info.dabt = dabt;
+    info.gva = READ_CP32(HDFAR);
+    info.gpa = gva_to_ipa(info.gva);
+
+    if (handle_mmio(&info))
+    {
+        regs->pc += dabt.len ? 4 : 2;
+        return;
+    }
+
+bad_data_abort:
+
+    msg = decode_fsc( dabt.dfsc, &level);
+
+    printk("Guest data abort: %s%s%s\n"
+           "    gva=%"PRIx32" gpa=%"PRIpaddr"\n",
+           msg, dabt.s1ptw ? " S2 during S1" : "",
+           fsc_level_str(level),
+           info.gva, info.gpa);
+    if (dabt.valid)
+        printk("    size=%d sign=%d write=%d reg=%d\n",
+               dabt.size, dabt.sign, dabt.write, dabt.reg);
+    else
+        printk("    instruction syndrome invalid\n");
+    printk("    eat=%d cm=%d s1ptw=%d dfsc=%d\n",
+           dabt.eat, dabt.cache, dabt.s1ptw, dabt.dfsc);
+
+    show_execution_state(regs);
+    panic("Unhandled guest data abort\n");
+}
+
+asmlinkage void do_trap_hypervisor(struct cpu_user_regs *regs)
+{
+    union hsr hsr = { .bits = READ_CP32(HSR) };
+
+    switch (hsr.ec) {
+    case HSR_EC_CP15_32:
+        do_cp15_32(regs, hsr);
+        break;
+    case HSR_EC_CP15_64:
+        do_cp15_64(regs, hsr);
+        break;
+    case HSR_EC_HVC:
+        if ( (hsr.iss & 0xff00) == 0xff00 )
+            return do_debug_trap(regs, hsr.iss & 0x00ff);
+        do_trap_hypercall(regs, hsr.iss);
+        break;
+    case HSR_EC_DATA_ABORT_GUEST:
+        do_trap_data_abort_guest(regs, hsr.dabt);
+        break;
+    default:
+        printk("Hypervisor Trap. HSR=0x%x EC=0x%x IL=%x Syndrome=%"PRIx32"\n",
+               hsr.bits, hsr.ec, hsr.len, hsr.iss);
+        do_unexpected_trap("Hypervisor", regs);
+    }
+}
+
+asmlinkage void do_trap_irq(struct cpu_user_regs *regs)
+{
+    gic_interrupt(regs, 0);
+}
+
+asmlinkage void do_trap_fiq(struct cpu_user_regs *regs)
+{
+    gic_interrupt(regs, 1);
+}
+
+asmlinkage void leave_hypervisor_tail(void)
+{
+    while (1)
+    {
+        local_irq_disable();
+        if (!softirq_pending(smp_processor_id()))
+            return;
+        local_irq_enable();
+        do_softirq();
+    }
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 16:29:40 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 16:29:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbEBe-0002Xq-Uw; Thu, 15 Dec 2011 16:29:38 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RbEBc-0002P2-9X
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 16:29:36 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1323966525!56866011!5
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDY5Mjg=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17642 invoked from network); 15 Dec 2011 16:28:56 -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 2011 16:28:56 -0000
X-IronPort-AV: E=Sophos;i="4.71,357,1320642000"; d="scan'208";a="20001879"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Dec 2011 11:29:31 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Thu, 15 Dec 2011 11:29:30 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pBFGSMtQ003330;
	Thu, 15 Dec 2011 08:28:33 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Thu, 15 Dec 2011 16:30:34 +0000
Message-ID: <1323966657-19790-2-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1112131831560.3517@kaball-desktop>
References: <alpine.DEB.2.00.1112131831560.3517@kaball-desktop>
MIME-Version: 1.0
Cc: keir.xen@gmail.com, Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, JBeulich@suse.com,
	Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v3 02/25] Include some header files that are not
	automatically included on all archs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Changes in v2:

- include asm header files after xen header files;

- remove incorrect comment;

- do not include asm/p2m.h under ia64.


Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
---
 xen/common/domctl.c           |    1 +
 xen/common/grant_table.c      |    1 +
 xen/common/irq.c              |    1 +
 xen/common/kernel.c           |    2 +-
 xen/common/keyhandler.c       |    1 +
 xen/common/memory.c           |    4 ++--
 xen/common/spinlock.c         |    1 +
 xen/common/wait.c             |    1 +
 xen/drivers/char/console.c    |    1 +
 xen/include/xen/grant_table.h |    1 +
 xen/include/xen/list.h        |    1 +
 xen/include/xen/sched.h       |    4 ++++
 xen/include/xen/timer.h       |    1 +
 xen/include/xen/tmem_xen.h    |    1 +
 14 files changed, 18 insertions(+), 3 deletions(-)

diff --git a/xen/common/domctl.c b/xen/common/domctl.c
index 6705a57..397f774 100644
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -24,6 +24,7 @@
 #include <xen/paging.h>
 #include <xen/hypercall.h>
 #include <asm/current.h>
+#include <asm/page.h>
 #include <public/domctl.h>
 #include <xsm/xsm.h>
 
diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c
index c80a359..de3a076 100644
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -38,6 +38,7 @@
 #include <xen/paging.h>
 #include <xen/keyhandler.h>
 #include <xsm/xsm.h>
+#include <asm/flushtlb.h>
 
 #ifndef max_nr_grant_frames
 unsigned int max_nr_grant_frames = DEFAULT_MAX_NR_GRANT_FRAMES;
diff --git a/xen/common/irq.c b/xen/common/irq.c
index 6d37dd4..3e55dfa 100644
--- a/xen/common/irq.c
+++ b/xen/common/irq.c
@@ -1,5 +1,6 @@
 #include <xen/config.h>
 #include <xen/irq.h>
+#include <xen/errno.h>
 
 int init_one_irq_desc(struct irq_desc *desc)
 {
diff --git a/xen/common/kernel.c b/xen/common/kernel.c
index 7decc1d..f51d387 100644
--- a/xen/common/kernel.c
+++ b/xen/common/kernel.c
@@ -18,8 +18,8 @@
 #include <public/version.h>
 #ifdef CONFIG_X86
 #include <asm/shared.h>
-#include <asm/setup.h>
 #endif
+#include <asm/setup.h>
 
 #ifndef COMPAT
 
diff --git a/xen/common/keyhandler.c b/xen/common/keyhandler.c
index a8f256a..6071f09 100644
--- a/xen/common/keyhandler.c
+++ b/xen/common/keyhandler.c
@@ -15,6 +15,7 @@
 #include <xen/compat.h>
 #include <xen/ctype.h>
 #include <xen/perfc.h>
+#include <xen/init.h>
 #include <asm/debugger.h>
 #include <asm/div64.h>
 
diff --git a/xen/common/memory.c b/xen/common/memory.c
index aefb706..52e2466 100644
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -23,8 +23,8 @@
 #include <xen/tmem_xen.h>
 #include <asm/current.h>
 #include <asm/hardirq.h>
-#ifdef CONFIG_X86
-# include <asm/p2m.h>
+#ifndef __ia64__
+#include <asm/p2m.h>
 #endif
 #include <xen/numa.h>
 #include <public/memory.h>
diff --git a/xen/common/spinlock.c b/xen/common/spinlock.c
index ecf5b44..bfb9670 100644
--- a/xen/common/spinlock.c
+++ b/xen/common/spinlock.c
@@ -8,6 +8,7 @@
 #include <xen/preempt.h>
 #include <public/sysctl.h>
 #include <asm/processor.h>
+#include <asm/atomic.h>
 
 #ifndef NDEBUG
 
diff --git a/xen/common/wait.c b/xen/common/wait.c
index a2c7640..0410c98 100644
--- a/xen/common/wait.c
+++ b/xen/common/wait.c
@@ -23,6 +23,7 @@
 #include <xen/config.h>
 #include <xen/sched.h>
 #include <xen/wait.h>
+#include <xen/errno.h>
 
 struct waitqueue_vcpu {
     struct list_head list;
diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
index 8a4c684..89cf4f8 100644
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -12,6 +12,7 @@
 
 #include <xen/version.h>
 #include <xen/lib.h>
+#include <xen/init.h>
 #include <xen/event.h>
 #include <xen/console.h>
 #include <xen/serial.h>
diff --git a/xen/include/xen/grant_table.h b/xen/include/xen/grant_table.h
index c161705..cb0596a 100644
--- a/xen/include/xen/grant_table.h
+++ b/xen/include/xen/grant_table.h
@@ -26,6 +26,7 @@
 
 #include <xen/config.h>
 #include <public/grant_table.h>
+#include <asm/page.h>
 #include <asm/grant_table.h>
 
 /* Active grant entry - used for shadowing GTF_permit_access grants. */
diff --git a/xen/include/xen/list.h b/xen/include/xen/list.h
index b87682f..18443a4 100644
--- a/xen/include/xen/list.h
+++ b/xen/include/xen/list.h
@@ -8,6 +8,7 @@
 #define __XEN_LIST_H__
 
 #include <xen/lib.h>
+#include <xen/prefetch.h>
 #include <asm/system.h>
 
 /* These are non-NULL pointers that will result in page faults
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index e12293c..832ca6f 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -14,6 +14,10 @@
 #include <xen/nodemask.h>
 #include <xen/radix-tree.h>
 #include <xen/multicall.h>
+#include <xen/tasklet.h>
+#include <xen/mm.h>
+#include <xen/smp.h>
+#include <asm/atomic.h>
 #include <public/xen.h>
 #include <public/domctl.h>
 #include <public/sysctl.h>
diff --git a/xen/include/xen/timer.h b/xen/include/xen/timer.h
index d209142..7c465fb 100644
--- a/xen/include/xen/timer.h
+++ b/xen/include/xen/timer.h
@@ -12,6 +12,7 @@
 #include <xen/time.h>
 #include <xen/string.h>
 #include <xen/list.h>
+#include <xen/percpu.h>
 
 struct timer {
     /* System time expiry value (nanoseconds since boot). */
diff --git a/xen/include/xen/tmem_xen.h b/xen/include/xen/tmem_xen.h
index 3dbf6f8..7ce9677 100644
--- a/xen/include/xen/tmem_xen.h
+++ b/xen/include/xen/tmem_xen.h
@@ -11,6 +11,7 @@
 
 #include <xen/config.h>
 #include <xen/mm.h> /* heap alloc/free */
+#include <xen/pfn.h>
 #include <xen/xmalloc.h> /* xmalloc/xfree */
 #include <xen/sched.h>  /* struct domain */
 #include <xen/guest_access.h> /* copy_from_guest */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 16:29:40 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 16:29:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbEBe-0002Xq-Uw; Thu, 15 Dec 2011 16:29:38 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RbEBc-0002P2-9X
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 16:29:36 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1323966525!56866011!5
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDY5Mjg=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17642 invoked from network); 15 Dec 2011 16:28:56 -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 2011 16:28:56 -0000
X-IronPort-AV: E=Sophos;i="4.71,357,1320642000"; d="scan'208";a="20001879"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Dec 2011 11:29:31 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Thu, 15 Dec 2011 11:29:30 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pBFGSMtQ003330;
	Thu, 15 Dec 2011 08:28:33 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Thu, 15 Dec 2011 16:30:34 +0000
Message-ID: <1323966657-19790-2-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1112131831560.3517@kaball-desktop>
References: <alpine.DEB.2.00.1112131831560.3517@kaball-desktop>
MIME-Version: 1.0
Cc: keir.xen@gmail.com, Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, JBeulich@suse.com,
	Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v3 02/25] Include some header files that are not
	automatically included on all archs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Changes in v2:

- include asm header files after xen header files;

- remove incorrect comment;

- do not include asm/p2m.h under ia64.


Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
---
 xen/common/domctl.c           |    1 +
 xen/common/grant_table.c      |    1 +
 xen/common/irq.c              |    1 +
 xen/common/kernel.c           |    2 +-
 xen/common/keyhandler.c       |    1 +
 xen/common/memory.c           |    4 ++--
 xen/common/spinlock.c         |    1 +
 xen/common/wait.c             |    1 +
 xen/drivers/char/console.c    |    1 +
 xen/include/xen/grant_table.h |    1 +
 xen/include/xen/list.h        |    1 +
 xen/include/xen/sched.h       |    4 ++++
 xen/include/xen/timer.h       |    1 +
 xen/include/xen/tmem_xen.h    |    1 +
 14 files changed, 18 insertions(+), 3 deletions(-)

diff --git a/xen/common/domctl.c b/xen/common/domctl.c
index 6705a57..397f774 100644
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -24,6 +24,7 @@
 #include <xen/paging.h>
 #include <xen/hypercall.h>
 #include <asm/current.h>
+#include <asm/page.h>
 #include <public/domctl.h>
 #include <xsm/xsm.h>
 
diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c
index c80a359..de3a076 100644
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -38,6 +38,7 @@
 #include <xen/paging.h>
 #include <xen/keyhandler.h>
 #include <xsm/xsm.h>
+#include <asm/flushtlb.h>
 
 #ifndef max_nr_grant_frames
 unsigned int max_nr_grant_frames = DEFAULT_MAX_NR_GRANT_FRAMES;
diff --git a/xen/common/irq.c b/xen/common/irq.c
index 6d37dd4..3e55dfa 100644
--- a/xen/common/irq.c
+++ b/xen/common/irq.c
@@ -1,5 +1,6 @@
 #include <xen/config.h>
 #include <xen/irq.h>
+#include <xen/errno.h>
 
 int init_one_irq_desc(struct irq_desc *desc)
 {
diff --git a/xen/common/kernel.c b/xen/common/kernel.c
index 7decc1d..f51d387 100644
--- a/xen/common/kernel.c
+++ b/xen/common/kernel.c
@@ -18,8 +18,8 @@
 #include <public/version.h>
 #ifdef CONFIG_X86
 #include <asm/shared.h>
-#include <asm/setup.h>
 #endif
+#include <asm/setup.h>
 
 #ifndef COMPAT
 
diff --git a/xen/common/keyhandler.c b/xen/common/keyhandler.c
index a8f256a..6071f09 100644
--- a/xen/common/keyhandler.c
+++ b/xen/common/keyhandler.c
@@ -15,6 +15,7 @@
 #include <xen/compat.h>
 #include <xen/ctype.h>
 #include <xen/perfc.h>
+#include <xen/init.h>
 #include <asm/debugger.h>
 #include <asm/div64.h>
 
diff --git a/xen/common/memory.c b/xen/common/memory.c
index aefb706..52e2466 100644
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -23,8 +23,8 @@
 #include <xen/tmem_xen.h>
 #include <asm/current.h>
 #include <asm/hardirq.h>
-#ifdef CONFIG_X86
-# include <asm/p2m.h>
+#ifndef __ia64__
+#include <asm/p2m.h>
 #endif
 #include <xen/numa.h>
 #include <public/memory.h>
diff --git a/xen/common/spinlock.c b/xen/common/spinlock.c
index ecf5b44..bfb9670 100644
--- a/xen/common/spinlock.c
+++ b/xen/common/spinlock.c
@@ -8,6 +8,7 @@
 #include <xen/preempt.h>
 #include <public/sysctl.h>
 #include <asm/processor.h>
+#include <asm/atomic.h>
 
 #ifndef NDEBUG
 
diff --git a/xen/common/wait.c b/xen/common/wait.c
index a2c7640..0410c98 100644
--- a/xen/common/wait.c
+++ b/xen/common/wait.c
@@ -23,6 +23,7 @@
 #include <xen/config.h>
 #include <xen/sched.h>
 #include <xen/wait.h>
+#include <xen/errno.h>
 
 struct waitqueue_vcpu {
     struct list_head list;
diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
index 8a4c684..89cf4f8 100644
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -12,6 +12,7 @@
 
 #include <xen/version.h>
 #include <xen/lib.h>
+#include <xen/init.h>
 #include <xen/event.h>
 #include <xen/console.h>
 #include <xen/serial.h>
diff --git a/xen/include/xen/grant_table.h b/xen/include/xen/grant_table.h
index c161705..cb0596a 100644
--- a/xen/include/xen/grant_table.h
+++ b/xen/include/xen/grant_table.h
@@ -26,6 +26,7 @@
 
 #include <xen/config.h>
 #include <public/grant_table.h>
+#include <asm/page.h>
 #include <asm/grant_table.h>
 
 /* Active grant entry - used for shadowing GTF_permit_access grants. */
diff --git a/xen/include/xen/list.h b/xen/include/xen/list.h
index b87682f..18443a4 100644
--- a/xen/include/xen/list.h
+++ b/xen/include/xen/list.h
@@ -8,6 +8,7 @@
 #define __XEN_LIST_H__
 
 #include <xen/lib.h>
+#include <xen/prefetch.h>
 #include <asm/system.h>
 
 /* These are non-NULL pointers that will result in page faults
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index e12293c..832ca6f 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -14,6 +14,10 @@
 #include <xen/nodemask.h>
 #include <xen/radix-tree.h>
 #include <xen/multicall.h>
+#include <xen/tasklet.h>
+#include <xen/mm.h>
+#include <xen/smp.h>
+#include <asm/atomic.h>
 #include <public/xen.h>
 #include <public/domctl.h>
 #include <public/sysctl.h>
diff --git a/xen/include/xen/timer.h b/xen/include/xen/timer.h
index d209142..7c465fb 100644
--- a/xen/include/xen/timer.h
+++ b/xen/include/xen/timer.h
@@ -12,6 +12,7 @@
 #include <xen/time.h>
 #include <xen/string.h>
 #include <xen/list.h>
+#include <xen/percpu.h>
 
 struct timer {
     /* System time expiry value (nanoseconds since boot). */
diff --git a/xen/include/xen/tmem_xen.h b/xen/include/xen/tmem_xen.h
index 3dbf6f8..7ce9677 100644
--- a/xen/include/xen/tmem_xen.h
+++ b/xen/include/xen/tmem_xen.h
@@ -11,6 +11,7 @@
 
 #include <xen/config.h>
 #include <xen/mm.h> /* heap alloc/free */
+#include <xen/pfn.h>
 #include <xen/xmalloc.h> /* xmalloc/xfree */
 #include <xen/sched.h>  /* struct domain */
 #include <xen/guest_access.h> /* copy_from_guest */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 16:29:44 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 16: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.xensource.com>)
	id 1RbEBi-0002e0-IN; Thu, 15 Dec 2011 16:29:42 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RbEBg-0002Sb-OV
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 16:29:40 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1323966525!56866011!6
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDY5Mjg=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17802 invoked from network); 15 Dec 2011 16:28:59 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 16:28:59 -0000
X-IronPort-AV: E=Sophos;i="4.71,357,1320642000"; d="scan'208";a="20001880"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Dec 2011 11:29:34 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Thu, 15 Dec 2011 11:29:33 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pBFGSMtn003330;
	Thu, 15 Dec 2011 08:29:14 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Thu, 15 Dec 2011 16:30:57 +0000
Message-ID: <1323966657-19790-25-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1112131831560.3517@kaball-desktop>
References: <alpine.DEB.2.00.1112131831560.3517@kaball-desktop>
MIME-Version: 1.0
Cc: keir.xen@gmail.com, Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, JBeulich@suse.com,
	Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v3 25/25] arm: makefiles
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Makefile and config options for the ARM architecture.


Changes in v2:

- move patch at the end of the series.


Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
---
 config/arm.mk         |   18 +++++++++++
 xen/arch/arm/Makefile |   76 +++++++++++++++++++++++++++++++++++++++++++++++++
 xen/arch/arm/Rules.mk |   29 ++++++++++++++++++
 3 files changed, 123 insertions(+), 0 deletions(-)
 create mode 100644 config/arm.mk
 create mode 100644 xen/arch/arm/Makefile
 create mode 100644 xen/arch/arm/Rules.mk

diff --git a/config/arm.mk b/config/arm.mk
new file mode 100644
index 0000000..f64f0c1
--- /dev/null
+++ b/config/arm.mk
@@ -0,0 +1,18 @@
+CONFIG_ARM := y
+CONFIG_ARM_32 := y
+CONFIG_ARM_$(XEN_OS) := y
+
+# -march= -mcpu=
+
+# Explicitly specifiy 32-bit ARM ISA since toolchain default can be -mthumb:
+CFLAGS += -marm
+
+HAS_PL011 := y
+
+# Use only if calling $(LD) directly.
+#LDFLAGS_DIRECT_OpenBSD = _obsd
+#LDFLAGS_DIRECT_FreeBSD = _fbsd
+LDFLAGS_DIRECT_Linux = _linux
+LDFLAGS_DIRECT += -marmelf$(LDFLAGS_DIRECT_$(XEN_OS))_eabi
+
+CONFIG_LOAD_ADDRESS ?= 0x80000000
diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
new file mode 100644
index 0000000..5a07ae7
--- /dev/null
+++ b/xen/arch/arm/Makefile
@@ -0,0 +1,76 @@
+subdir-y += lib
+
+obj-y += dummy.o
+obj-y += entry.o
+obj-y += domain.o
+obj-y += domain_build.o
+obj-y += gic.o
+obj-y += io.o
+obj-y += irq.o
+obj-y += mm.o
+obj-y += p2m.o
+obj-y += guestcopy.o
+obj-y += setup.o
+obj-y += time.o
+obj-y += smpboot.o
+obj-y += smp.o
+obj-y += shutdown.o
+obj-y += traps.o
+obj-y += vgic.o
+obj-y += vtimer.o
+
+#obj-bin-y += ....o
+
+ALL_OBJS := head.o $(ALL_OBJS)
+
+$(TARGET): $(TARGET)-syms
+	# XXX: VE model loads by VMA so instead of
+	# making a proper ELF we link with LMA == VMA and adjust crudely
+	$(OBJCOPY) --change-addresses +0x7fe00000 $< $@
+	# XXX strip it
+
+#$(TARGET): $(TARGET)-syms $(efi-y) boot/mkelf32
+#	./boot/mkelf32 $(TARGET)-syms $(TARGET) 0x100000 \
+#	`$(NM) -nr $(TARGET)-syms | head -n 1 | sed -e 's/^\([^ ]*\).*/0x\1/'`
+
+ifeq ($(lto),y)
+# Gather all LTO objects together
+prelink_lto.o: $(ALL_OBJS)
+	$(LD_LTO) -r -o $@ $^
+
+# Link it with all the binary objects
+prelink.o: $(patsubst %/built_in.o,%/built_in_bin.o,$(ALL_OBJS)) prelink_lto.o
+	$(LD) $(LDFLAGS) -r -o $@ $^
+else
+prelink.o: $(ALL_OBJS)
+	$(LD) $(LDFLAGS) -r -o $@ $^
+endif
+
+$(BASEDIR)/common/symbols-dummy.o:
+	$(MAKE) -f $(BASEDIR)/Rules.mk -C $(BASEDIR)/common symbols-dummy.o
+
+$(TARGET)-syms: prelink.o xen.lds $(BASEDIR)/common/symbols-dummy.o
+	$(LD) $(LDFLAGS) -T xen.lds -N prelink.o \
+	    $(BASEDIR)/common/symbols-dummy.o -o $(@D)/.$(@F).0
+	$(NM) -n $(@D)/.$(@F).0 | $(BASEDIR)/tools/symbols >$(@D)/.$(@F).0.S
+	$(MAKE) -f $(BASEDIR)/Rules.mk $(@D)/.$(@F).0.o
+	$(LD) $(LDFLAGS) -T xen.lds -N prelink.o \
+	    $(@D)/.$(@F).0.o -o $(@D)/.$(@F).1
+	$(NM) -n $(@D)/.$(@F).1 | $(BASEDIR)/tools/symbols >$(@D)/.$(@F).1.S
+	$(MAKE) -f $(BASEDIR)/Rules.mk $(@D)/.$(@F).1.o
+	$(LD) $(LDFLAGS) -T xen.lds -N prelink.o \
+	    $(@D)/.$(@F).1.o -o $@
+	rm -f $(@D)/.$(@F).[0-9]*
+
+asm-offsets.s: asm-offsets.c
+	$(CC) $(filter-out -flto,$(CFLAGS)) -S -o $@ $<
+
+xen.lds: xen.lds.S
+	$(CC) -P -E -Ui386 $(AFLAGS) -DXEN_PHYS_START=$(CONFIG_LOAD_ADDRESS) -o $@ $<
+	sed -e 's/xen\.lds\.o:/xen\.lds:/g' <.xen.lds.d >.xen.lds.d.new
+	mv -f .xen.lds.d.new .xen.lds.d
+
+.PHONY: clean
+clean::
+	rm -f asm-offsets.s xen.lds
+	rm -f $(BASEDIR)/.xen-syms.[0-9]*
diff --git a/xen/arch/arm/Rules.mk b/xen/arch/arm/Rules.mk
new file mode 100644
index 0000000..336e209
--- /dev/null
+++ b/xen/arch/arm/Rules.mk
@@ -0,0 +1,29 @@
+########################################
+# arm-specific definitions
+
+#
+# If you change any of these configuration options then you must
+# 'make clean' before rebuilding.
+#
+
+CFLAGS += -fno-builtin -fno-common -Wredundant-decls
+CFLAGS += -iwithprefix include -Werror -Wno-pointer-arith -pipe
+CFLAGS += -I$(BASEDIR)/include
+
+# Prevent floating-point variables from creeping into Xen.
+CFLAGS += -msoft-float
+
+$(call cc-options-add,CFLAGS,CC,$(EMBEDDED_EXTRA_CFLAGS))
+$(call cc-option-add,CFLAGS,CC,-Wnested-externs)
+
+arm := y
+
+ifneq ($(call cc-option,$(CC),-fvisibility=hidden,n),n)
+CFLAGS += -DGCC_HAS_VISIBILITY_ATTRIBUTE
+endif
+
+CFLAGS += -march=armv7-a -mcpu=cortex-a15
+
+# Require GCC v3.4+ (to avoid issues with alignment constraints in Xen headers)
+check-$(gcc) = $(call cc-ver-check,CC,0x030400,"Xen requires at least gcc-3.4")
+$(eval $(check-y))
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 16:29:44 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 16: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.xensource.com>)
	id 1RbEBi-0002e0-IN; Thu, 15 Dec 2011 16:29:42 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RbEBg-0002Sb-OV
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 16:29:40 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1323966525!56866011!6
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDY5Mjg=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17802 invoked from network); 15 Dec 2011 16:28:59 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 16:28:59 -0000
X-IronPort-AV: E=Sophos;i="4.71,357,1320642000"; d="scan'208";a="20001880"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Dec 2011 11:29:34 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Thu, 15 Dec 2011 11:29:33 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pBFGSMtn003330;
	Thu, 15 Dec 2011 08:29:14 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Thu, 15 Dec 2011 16:30:57 +0000
Message-ID: <1323966657-19790-25-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1112131831560.3517@kaball-desktop>
References: <alpine.DEB.2.00.1112131831560.3517@kaball-desktop>
MIME-Version: 1.0
Cc: keir.xen@gmail.com, Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, JBeulich@suse.com,
	Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v3 25/25] arm: makefiles
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Makefile and config options for the ARM architecture.


Changes in v2:

- move patch at the end of the series.


Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
---
 config/arm.mk         |   18 +++++++++++
 xen/arch/arm/Makefile |   76 +++++++++++++++++++++++++++++++++++++++++++++++++
 xen/arch/arm/Rules.mk |   29 ++++++++++++++++++
 3 files changed, 123 insertions(+), 0 deletions(-)
 create mode 100644 config/arm.mk
 create mode 100644 xen/arch/arm/Makefile
 create mode 100644 xen/arch/arm/Rules.mk

diff --git a/config/arm.mk b/config/arm.mk
new file mode 100644
index 0000000..f64f0c1
--- /dev/null
+++ b/config/arm.mk
@@ -0,0 +1,18 @@
+CONFIG_ARM := y
+CONFIG_ARM_32 := y
+CONFIG_ARM_$(XEN_OS) := y
+
+# -march= -mcpu=
+
+# Explicitly specifiy 32-bit ARM ISA since toolchain default can be -mthumb:
+CFLAGS += -marm
+
+HAS_PL011 := y
+
+# Use only if calling $(LD) directly.
+#LDFLAGS_DIRECT_OpenBSD = _obsd
+#LDFLAGS_DIRECT_FreeBSD = _fbsd
+LDFLAGS_DIRECT_Linux = _linux
+LDFLAGS_DIRECT += -marmelf$(LDFLAGS_DIRECT_$(XEN_OS))_eabi
+
+CONFIG_LOAD_ADDRESS ?= 0x80000000
diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
new file mode 100644
index 0000000..5a07ae7
--- /dev/null
+++ b/xen/arch/arm/Makefile
@@ -0,0 +1,76 @@
+subdir-y += lib
+
+obj-y += dummy.o
+obj-y += entry.o
+obj-y += domain.o
+obj-y += domain_build.o
+obj-y += gic.o
+obj-y += io.o
+obj-y += irq.o
+obj-y += mm.o
+obj-y += p2m.o
+obj-y += guestcopy.o
+obj-y += setup.o
+obj-y += time.o
+obj-y += smpboot.o
+obj-y += smp.o
+obj-y += shutdown.o
+obj-y += traps.o
+obj-y += vgic.o
+obj-y += vtimer.o
+
+#obj-bin-y += ....o
+
+ALL_OBJS := head.o $(ALL_OBJS)
+
+$(TARGET): $(TARGET)-syms
+	# XXX: VE model loads by VMA so instead of
+	# making a proper ELF we link with LMA == VMA and adjust crudely
+	$(OBJCOPY) --change-addresses +0x7fe00000 $< $@
+	# XXX strip it
+
+#$(TARGET): $(TARGET)-syms $(efi-y) boot/mkelf32
+#	./boot/mkelf32 $(TARGET)-syms $(TARGET) 0x100000 \
+#	`$(NM) -nr $(TARGET)-syms | head -n 1 | sed -e 's/^\([^ ]*\).*/0x\1/'`
+
+ifeq ($(lto),y)
+# Gather all LTO objects together
+prelink_lto.o: $(ALL_OBJS)
+	$(LD_LTO) -r -o $@ $^
+
+# Link it with all the binary objects
+prelink.o: $(patsubst %/built_in.o,%/built_in_bin.o,$(ALL_OBJS)) prelink_lto.o
+	$(LD) $(LDFLAGS) -r -o $@ $^
+else
+prelink.o: $(ALL_OBJS)
+	$(LD) $(LDFLAGS) -r -o $@ $^
+endif
+
+$(BASEDIR)/common/symbols-dummy.o:
+	$(MAKE) -f $(BASEDIR)/Rules.mk -C $(BASEDIR)/common symbols-dummy.o
+
+$(TARGET)-syms: prelink.o xen.lds $(BASEDIR)/common/symbols-dummy.o
+	$(LD) $(LDFLAGS) -T xen.lds -N prelink.o \
+	    $(BASEDIR)/common/symbols-dummy.o -o $(@D)/.$(@F).0
+	$(NM) -n $(@D)/.$(@F).0 | $(BASEDIR)/tools/symbols >$(@D)/.$(@F).0.S
+	$(MAKE) -f $(BASEDIR)/Rules.mk $(@D)/.$(@F).0.o
+	$(LD) $(LDFLAGS) -T xen.lds -N prelink.o \
+	    $(@D)/.$(@F).0.o -o $(@D)/.$(@F).1
+	$(NM) -n $(@D)/.$(@F).1 | $(BASEDIR)/tools/symbols >$(@D)/.$(@F).1.S
+	$(MAKE) -f $(BASEDIR)/Rules.mk $(@D)/.$(@F).1.o
+	$(LD) $(LDFLAGS) -T xen.lds -N prelink.o \
+	    $(@D)/.$(@F).1.o -o $@
+	rm -f $(@D)/.$(@F).[0-9]*
+
+asm-offsets.s: asm-offsets.c
+	$(CC) $(filter-out -flto,$(CFLAGS)) -S -o $@ $<
+
+xen.lds: xen.lds.S
+	$(CC) -P -E -Ui386 $(AFLAGS) -DXEN_PHYS_START=$(CONFIG_LOAD_ADDRESS) -o $@ $<
+	sed -e 's/xen\.lds\.o:/xen\.lds:/g' <.xen.lds.d >.xen.lds.d.new
+	mv -f .xen.lds.d.new .xen.lds.d
+
+.PHONY: clean
+clean::
+	rm -f asm-offsets.s xen.lds
+	rm -f $(BASEDIR)/.xen-syms.[0-9]*
diff --git a/xen/arch/arm/Rules.mk b/xen/arch/arm/Rules.mk
new file mode 100644
index 0000000..336e209
--- /dev/null
+++ b/xen/arch/arm/Rules.mk
@@ -0,0 +1,29 @@
+########################################
+# arm-specific definitions
+
+#
+# If you change any of these configuration options then you must
+# 'make clean' before rebuilding.
+#
+
+CFLAGS += -fno-builtin -fno-common -Wredundant-decls
+CFLAGS += -iwithprefix include -Werror -Wno-pointer-arith -pipe
+CFLAGS += -I$(BASEDIR)/include
+
+# Prevent floating-point variables from creeping into Xen.
+CFLAGS += -msoft-float
+
+$(call cc-options-add,CFLAGS,CC,$(EMBEDDED_EXTRA_CFLAGS))
+$(call cc-option-add,CFLAGS,CC,-Wnested-externs)
+
+arm := y
+
+ifneq ($(call cc-option,$(CC),-fvisibility=hidden,n),n)
+CFLAGS += -DGCC_HAS_VISIBILITY_ATTRIBUTE
+endif
+
+CFLAGS += -march=armv7-a -mcpu=cortex-a15
+
+# Require GCC v3.4+ (to avoid issues with alignment constraints in Xen headers)
+check-$(gcc) = $(call cc-ver-check,CC,0x030400,"Xen requires at least gcc-3.4")
+$(eval $(check-y))
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 16:37:27 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 16: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.xensource.com>)
	id 1RbEJ5-000642-Ab; Thu, 15 Dec 2011 16:37:19 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RbEJ4-00063u-0l
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 16:37:18 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1323967014!49467975!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31040 invoked from network); 15 Dec 2011 16:36:54 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-11.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 15 Dec 2011 16:36:54 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 15 Dec 2011 16:37:13 +0000
Message-Id: <4EEA304402000078000684C8@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 15 Dec 2011 16:37:08 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Don Brace" <dab@hp.com>
References: <4EDFDF0D.2020104@hp.com>
	<4EE628D80200007800066F9E@nat28.tlf.novell.com>
	<20111214213443.GC25896@andromeda.dapyr.net>
	<4EE9C15602000078000680D3@nat28.tlf.novell.com>
	<6738613108553D49BEFEFDD59230CCDF011BED93@G4W3300.americas.hpqcorp.net>
In-Reply-To: <6738613108553D49BEFEFDD59230CCDF011BED93@G4W3300.americas.hpqcorp.net>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] kmap_atomic issue with SLES11SP1 32bit XEN driver
 code
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 15.12.11 at 17:15, "Brace, Don" <dab@hp.com> wrote:
> I do not understand what this means:
> " That is, we'd be susceptible to this problem only if within a
> lazy-mode enabled section k{,un}map_atomic were used
> synchronously (which I'd consider a coding mistake)."
> 
> Could you elaborate on this?

Not sure what additional explanation is needed. kmap_atomic() is
intended to be used in atomic context, and if you use it elsewhere
that's a mis-use.

> Here is what I am trying to do.
> I am in a LLD I have bus addresses that are DMA-able that I would normally
> DMA to except this driver is emulating hardware in software and so it does
> not need to DMA is needs to transfer the data with the CPU.

So this makes clear that what I told you about a possibly missing
translation is likely the culprit. Quoting from your original mail

                 linux_page = __pfn_to_page(physical_address >> PAGE_SHIFT);

I have to assume that physical_address really isn't a physical address,
but a bus one. Hence you first need to translate it to a physical one
before passing it to __pfn_to_page().

> On non-XEN 32bit kernels I use kmap_atomic() and it handles both highmem 
> addresses and non highmem addresses with no issues.

And so does it on Xen.

> When I am running 32bit XEN kernels I run into issues like this:
>     "BUG: unable to handle kernel paging request at 9822bf40"

Because you pass in a random struct page *.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 16:37:27 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 16: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.xensource.com>)
	id 1RbEJ5-000642-Ab; Thu, 15 Dec 2011 16:37:19 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RbEJ4-00063u-0l
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 16:37:18 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1323967014!49467975!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31040 invoked from network); 15 Dec 2011 16:36:54 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-11.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 15 Dec 2011 16:36:54 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 15 Dec 2011 16:37:13 +0000
Message-Id: <4EEA304402000078000684C8@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 15 Dec 2011 16:37:08 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Don Brace" <dab@hp.com>
References: <4EDFDF0D.2020104@hp.com>
	<4EE628D80200007800066F9E@nat28.tlf.novell.com>
	<20111214213443.GC25896@andromeda.dapyr.net>
	<4EE9C15602000078000680D3@nat28.tlf.novell.com>
	<6738613108553D49BEFEFDD59230CCDF011BED93@G4W3300.americas.hpqcorp.net>
In-Reply-To: <6738613108553D49BEFEFDD59230CCDF011BED93@G4W3300.americas.hpqcorp.net>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] kmap_atomic issue with SLES11SP1 32bit XEN driver
 code
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 15.12.11 at 17:15, "Brace, Don" <dab@hp.com> wrote:
> I do not understand what this means:
> " That is, we'd be susceptible to this problem only if within a
> lazy-mode enabled section k{,un}map_atomic were used
> synchronously (which I'd consider a coding mistake)."
> 
> Could you elaborate on this?

Not sure what additional explanation is needed. kmap_atomic() is
intended to be used in atomic context, and if you use it elsewhere
that's a mis-use.

> Here is what I am trying to do.
> I am in a LLD I have bus addresses that are DMA-able that I would normally
> DMA to except this driver is emulating hardware in software and so it does
> not need to DMA is needs to transfer the data with the CPU.

So this makes clear that what I told you about a possibly missing
translation is likely the culprit. Quoting from your original mail

                 linux_page = __pfn_to_page(physical_address >> PAGE_SHIFT);

I have to assume that physical_address really isn't a physical address,
but a bus one. Hence you first need to translate it to a physical one
before passing it to __pfn_to_page().

> On non-XEN 32bit kernels I use kmap_atomic() and it handles both highmem 
> addresses and non highmem addresses with no issues.

And so does it on Xen.

> When I am running 32bit XEN kernels I run into issues like this:
>     "BUG: unable to handle kernel paging request at 9822bf40"

Because you pass in a random struct page *.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 16:42:57 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 16:42:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbEOO-0006KP-Hk; Thu, 15 Dec 2011 16:42:48 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <anthony@overnetdata.com>) id 1RbEOM-0006Jx-Vo
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 16:42:47 +0000
X-Env-Sender: anthony@overnetdata.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1323967360!7370976!1
X-Originating-IP: [81.137.131.225]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7499 invoked from network); 15 Dec 2011 16:42:40 -0000
Received: from host81-137-131-225.in-addr.btopenworld.com (HELO
	zimbra.overnetdata.com) (81.137.131.225)
	by server-7.tower-182.messagelabs.com with SMTP;
	15 Dec 2011 16:42:40 -0000
Received: from localhost (localhost.localdomain [127.0.0.1])
	by zimbra.overnetdata.com (Postfix) with ESMTP id E2284160CB6
	for <xen-devel@lists.xensource.com>;
	Thu, 15 Dec 2011 16:42:29 +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 ymxQJ+D2v+xa for <xen-devel@lists.xensource.com>;
	Thu, 15 Dec 2011 16:42:21 +0000 (GMT)
Received: from [192.168.1.51] (unknown [192.168.1.51])
	by zimbra.overnetdata.com (Postfix) with ESMTPSA id 3F3AC160CA8
	for <xen-devel@lists.xensource.com>;
	Thu, 15 Dec 2011 16:42:21 +0000 (GMT)
Message-ID: <4EEA236D.3000802@overnetdata.com>
Date: Thu, 15 Dec 2011 16:42:21 +0000
From: Anthony Wright <anthony@overnetdata.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
X-Enigmail-Version: 1.3.4
Subject: [Xen-devel] VGA passthrough on Paravirtualized VMs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

I understand that VGA passthrough isn't officially supported on
paravirtualized VMs, but it will work with certain video cards. Does
anybody have any information about which video cards/chipsets are/are
not supported for paravirtualization, what the criteria for being
supported/unsupported is etc.?

I'm also interested in understanding the technical problems to getting
VGA passthrough working with paravirtualized VMs to see if it's
something we might look at putting some effort into.

thanks,

Anthony.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 16:42:57 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 16:42:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbEOO-0006KP-Hk; Thu, 15 Dec 2011 16:42:48 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <anthony@overnetdata.com>) id 1RbEOM-0006Jx-Vo
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 16:42:47 +0000
X-Env-Sender: anthony@overnetdata.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1323967360!7370976!1
X-Originating-IP: [81.137.131.225]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7499 invoked from network); 15 Dec 2011 16:42:40 -0000
Received: from host81-137-131-225.in-addr.btopenworld.com (HELO
	zimbra.overnetdata.com) (81.137.131.225)
	by server-7.tower-182.messagelabs.com with SMTP;
	15 Dec 2011 16:42:40 -0000
Received: from localhost (localhost.localdomain [127.0.0.1])
	by zimbra.overnetdata.com (Postfix) with ESMTP id E2284160CB6
	for <xen-devel@lists.xensource.com>;
	Thu, 15 Dec 2011 16:42:29 +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 ymxQJ+D2v+xa for <xen-devel@lists.xensource.com>;
	Thu, 15 Dec 2011 16:42:21 +0000 (GMT)
Received: from [192.168.1.51] (unknown [192.168.1.51])
	by zimbra.overnetdata.com (Postfix) with ESMTPSA id 3F3AC160CA8
	for <xen-devel@lists.xensource.com>;
	Thu, 15 Dec 2011 16:42:21 +0000 (GMT)
Message-ID: <4EEA236D.3000802@overnetdata.com>
Date: Thu, 15 Dec 2011 16:42:21 +0000
From: Anthony Wright <anthony@overnetdata.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
X-Enigmail-Version: 1.3.4
Subject: [Xen-devel] VGA passthrough on Paravirtualized VMs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

I understand that VGA passthrough isn't officially supported on
paravirtualized VMs, but it will work with certain video cards. Does
anybody have any information about which video cards/chipsets are/are
not supported for paravirtualization, what the criteria for being
supported/unsupported is etc.?

I'm also interested in understanding the technical problems to getting
VGA passthrough working with paravirtualized VMs to see if it's
something we might look at putting some effort into.

thanks,

Anthony.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 16:44:46 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 16:44:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbEQA-0006QQ-3p; Thu, 15 Dec 2011 16:44:38 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RbEQ9-0006QB-6d
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 16:44:37 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1323967470!7431273!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjI2MA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23466 invoked from network); 15 Dec 2011 16:44:30 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 16:44:30 -0000
X-IronPort-AV: E=Sophos;i="4.71,357,1320624000"; 
   d="scan'208";a="9497174"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Dec 2011 16:44:30 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 15 Dec 2011 16:44:30 +0000
Date: Thu, 15 Dec 2011 16:46:54 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
In-Reply-To: <1323808737-29125-9-git-send-email-dgdegra@tycho.nsa.gov>
Message-ID: <alpine.DEB.2.00.1112151639190.3517@kaball-desktop>
References: <1323808737-29125-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1323808737-29125-9-git-send-email-dgdegra@tycho.nsa.gov>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Keir
	\(Xen.org\)" <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH 8/8] xl.pod.1: improve documentation of
 FLASK commands
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 13 Dec 2011, Daniel De Graaf wrote:
> +=head2 FLASK
> +
> +=over 4
> +
> +=item B<getenforce>
> +
> +Determine if the FLASK security module is loaded and enforcing its policy.
> +
> +=item B<setenforce> I<1|0|Enforcing|Permissive>
> +
> +Enable or disable enforcing of the FLASK access controls. The default is
> +permissive and can be changed using the flask_enforcing option on the
> +hypervisor's command line.
> +
> +=item B<loadpolicy> I<policy-file>
> +
> +Load FLASK policy from the given policy file. The initial policy is provided to
> +the hypervisor as a multiboot module; this command allows runtime updates to the
> +policy. Loading new security policy will reset runtime changes to device labels.

Thanks for the patch!
Since we are trying to improve the documentation for Xl, would you be up
for writing a couple of more lines explaining why people might want to
use XSM?
In case there are some parameters to be used in the VM config
file, could you please write a simple text file, like
docs/misc/xl-network-configuration.markdown, describing which ones they
are?
Finally it would be great if you could submit, as a separate patch, an
example policy file that we can keep under tools/examples/ or docs/misc
for everybody to use.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 16:44:46 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 16:44:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbEQA-0006QQ-3p; Thu, 15 Dec 2011 16:44:38 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RbEQ9-0006QB-6d
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 16:44:37 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1323967470!7431273!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjI2MA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23466 invoked from network); 15 Dec 2011 16:44:30 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 16:44:30 -0000
X-IronPort-AV: E=Sophos;i="4.71,357,1320624000"; 
   d="scan'208";a="9497174"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Dec 2011 16:44:30 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 15 Dec 2011 16:44:30 +0000
Date: Thu, 15 Dec 2011 16:46:54 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
In-Reply-To: <1323808737-29125-9-git-send-email-dgdegra@tycho.nsa.gov>
Message-ID: <alpine.DEB.2.00.1112151639190.3517@kaball-desktop>
References: <1323808737-29125-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1323808737-29125-9-git-send-email-dgdegra@tycho.nsa.gov>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Keir
	\(Xen.org\)" <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH 8/8] xl.pod.1: improve documentation of
 FLASK commands
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 13 Dec 2011, Daniel De Graaf wrote:
> +=head2 FLASK
> +
> +=over 4
> +
> +=item B<getenforce>
> +
> +Determine if the FLASK security module is loaded and enforcing its policy.
> +
> +=item B<setenforce> I<1|0|Enforcing|Permissive>
> +
> +Enable or disable enforcing of the FLASK access controls. The default is
> +permissive and can be changed using the flask_enforcing option on the
> +hypervisor's command line.
> +
> +=item B<loadpolicy> I<policy-file>
> +
> +Load FLASK policy from the given policy file. The initial policy is provided to
> +the hypervisor as a multiboot module; this command allows runtime updates to the
> +policy. Loading new security policy will reset runtime changes to device labels.

Thanks for the patch!
Since we are trying to improve the documentation for Xl, would you be up
for writing a couple of more lines explaining why people might want to
use XSM?
In case there are some parameters to be used in the VM config
file, could you please write a simple text file, like
docs/misc/xl-network-configuration.markdown, describing which ones they
are?
Finally it would be great if you could submit, as a separate patch, an
example policy file that we can keep under tools/examples/ or docs/misc
for everybody to use.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 16:50:07 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 16: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.xensource.com>)
	id 1RbEVJ-0006il-GN; Thu, 15 Dec 2011 16:49:57 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RbEVI-0006iZ-5X
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 16:49:56 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1323967789!5732290!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23779 invoked from network); 15 Dec 2011 16:49:50 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-5.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 15 Dec 2011 16:49:50 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 15 Dec 2011 16:49:49 +0000
Message-Id: <4EEA333802000078000684E5@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 15 Dec 2011 16:49:44 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: <stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1112131831560.3517@kaball-desktop>
	<1323966657-19790-4-git-send-email-stefano.stabellini@eu.citrix.com>
In-Reply-To: <1323966657-19790-4-git-send-email-stefano.stabellini@eu.citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com, keir.xen@gmail.com, Ian.Campbell@citrix.com,
	Tim.Deegan@citrix.com
Subject: Re: [Xen-devel] [PATCH v3 04/25] xen: implement an signed 64 bit
 division helper function
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 15.12.11 at 17:30, <stefano.stabellini@eu.citrix.com> wrote:
> From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> 
> Implement a C function to perform 64 bit signed division and return both
> quotient and remainder.
> Useful as an helper function to implement __aeabi_ldivmod.
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> ---
>  xen/common/lib.c |   19 +++++++++++++++++++
>  1 files changed, 19 insertions(+), 0 deletions(-)
> 
> diff --git a/xen/common/lib.c b/xen/common/lib.c
> index 4ae637c..fe831a3 100644
> --- a/xen/common/lib.c
> +++ b/xen/common/lib.c
> @@ -399,6 +399,25 @@ s64 __moddi3(s64 a, s64 b)
>      return (neg ? -urem : urem);
>  }
>  
> +/*
> + * Quotient and remainder of unsigned long long division
> + */
> +s64 __ldivmod_helper(s64 a, s64 b, s64 *r)
> +{
> +    u64 ua, ub, rem, quot;
> +
> +    ua = (a < 0) ? -(u64)a : a;
> +    ub = (b < 0) ? -(u64)b : b;

ABS() in both cases?

Jan

> +    quot = __qdivrem(ua, ub, &rem);
> +    if ( a < 0 )
> +        *r = -rem;
> +    else
> +        *r = rem;
> +    if ( (a < 0) ^ (b < 0) )
> +        return -quot;
> +    else
> +        return quot;
> +}
>  #endif /* BITS_PER_LONG == 32 */
>  
>  /* Compute with 96 bit intermediate result: (a*b)/c */
> -- 
> 1.7.2.5




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 16:50:07 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 16: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.xensource.com>)
	id 1RbEVJ-0006il-GN; Thu, 15 Dec 2011 16:49:57 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RbEVI-0006iZ-5X
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 16:49:56 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1323967789!5732290!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23779 invoked from network); 15 Dec 2011 16:49:50 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-5.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 15 Dec 2011 16:49:50 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 15 Dec 2011 16:49:49 +0000
Message-Id: <4EEA333802000078000684E5@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 15 Dec 2011 16:49:44 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: <stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1112131831560.3517@kaball-desktop>
	<1323966657-19790-4-git-send-email-stefano.stabellini@eu.citrix.com>
In-Reply-To: <1323966657-19790-4-git-send-email-stefano.stabellini@eu.citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com, keir.xen@gmail.com, Ian.Campbell@citrix.com,
	Tim.Deegan@citrix.com
Subject: Re: [Xen-devel] [PATCH v3 04/25] xen: implement an signed 64 bit
 division helper function
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 15.12.11 at 17:30, <stefano.stabellini@eu.citrix.com> wrote:
> From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> 
> Implement a C function to perform 64 bit signed division and return both
> quotient and remainder.
> Useful as an helper function to implement __aeabi_ldivmod.
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> ---
>  xen/common/lib.c |   19 +++++++++++++++++++
>  1 files changed, 19 insertions(+), 0 deletions(-)
> 
> diff --git a/xen/common/lib.c b/xen/common/lib.c
> index 4ae637c..fe831a3 100644
> --- a/xen/common/lib.c
> +++ b/xen/common/lib.c
> @@ -399,6 +399,25 @@ s64 __moddi3(s64 a, s64 b)
>      return (neg ? -urem : urem);
>  }
>  
> +/*
> + * Quotient and remainder of unsigned long long division
> + */
> +s64 __ldivmod_helper(s64 a, s64 b, s64 *r)
> +{
> +    u64 ua, ub, rem, quot;
> +
> +    ua = (a < 0) ? -(u64)a : a;
> +    ub = (b < 0) ? -(u64)b : b;

ABS() in both cases?

Jan

> +    quot = __qdivrem(ua, ub, &rem);
> +    if ( a < 0 )
> +        *r = -rem;
> +    else
> +        *r = rem;
> +    if ( (a < 0) ^ (b < 0) )
> +        return -quot;
> +    else
> +        return quot;
> +}
>  #endif /* BITS_PER_LONG == 32 */
>  
>  /* Compute with 96 bit intermediate result: (a*b)/c */
> -- 
> 1.7.2.5




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 16:53:21 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 16:53:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbEYT-0006uA-C1; Thu, 15 Dec 2011 16:53:13 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RbEYR-0006tg-DY
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 16:53:11 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1323967984!5701420!1
X-Originating-IP: [74.125.83.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23888 invoked from network); 15 Dec 2011 16:53:04 -0000
Received: from mail-ee0-f43.google.com (HELO mail-ee0-f43.google.com)
	(74.125.83.43)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 16:53:04 -0000
Received: by eekd4 with SMTP id d4so5042957eek.30
	for <xen-devel@lists.xensource.com>;
	Thu, 15 Dec 2011 08:53:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=3R3djZZH4YBKsgZwnTUa+6H9QyMyoeB7d2BlEpJADW8=;
	b=F83LAdm4y5gmbCaM733Y9iyvGoUY29bAa8vWZRwu/XfDsueOjgqvrzC3joEIOBCmfW
	JMzwpKRy4s8/Lc9xi22bhKkrPy6ThwTV7q4QwqkcLRQvcBJT8rE760iB0ImTMOmgJ0Ry
	fVWHBoRrlCvqGmOlpkgQhv07PTxlL+3XR03i0=
Received: by 10.180.105.131 with SMTP id gm3mr6519220wib.50.1323967984180;
	Thu, 15 Dec 2011 08:53:04 -0800 (PST)
Received: from [192.168.1.3] (host81-152-17-11.range81-152.btcentralplus.com.
	[81.152.17.11])
	by mx.google.com with ESMTPS id hb10sm9074369wib.16.2011.12.15.08.53.03
	(version=SSLv3 cipher=OTHER); Thu, 15 Dec 2011 08:53:03 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Thu, 15 Dec 2011 16:53:03 +0000
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Message-ID: <CB0FD66F.36073%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH] x86/emulator: workaround for AMD erratum 573
Thread-Index: Acy7SgJzLDsApI0lDUKPtj6ZNB+jew==
In-Reply-To: <4EEA01350200007800068241@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH] x86/emulator: workaround for AMD erratum 573
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 15/12/2011 13:16, "Jan Beulich" <JBeulich@suse.com> wrote:

> The only cases where we might end up emulating fsincos (as any other
> x87 operations without memory operands) are
> - when a HVM guest is in real mode (not applicable on AMD)
> - between two half page table updates in PAE mode (unlikely, and not
>   doing the emulation here does affect only performance, not
>   correctness)
> - when a guest maliciously (or erroneously) modifies an (MMIO or page
>   table update) instruction under emulation (unspecified behavior)
> 
> Hence, in order to avoid the erratum to cause harm to the entire host,
> don't emulate fsincos on the affected AMD CPU families.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Keir Fraser <keir@xen.org>

> --- a/tools/tests/x86_emulator/x86_emulate.c
> +++ b/tools/tests/x86_emulator/x86_emulate.c
> @@ -9,5 +9,7 @@ typedef bool bool_t;
>  
>  #define BUG() abort()
>  
> +#define cpu_has_amd_erratum(nr) 0
> +
>  #include "x86_emulate/x86_emulate.h"
>  #include "x86_emulate/x86_emulate.c"
> --- a/xen/arch/x86/x86_emulate.c
> +++ b/xen/arch/x86/x86_emulate.c
> @@ -10,8 +10,14 @@
>   */
>  
>  #include <asm/x86_emulate.h>
> +#include <asm/processor.h> /* current_cpu_info */
> +#include <asm/amd.h> /* cpu_has_amd_erratum() */
>  
>  /* Avoid namespace pollution. */
>  #undef cmpxchg
> +#undef cpuid
> +
> +#define cpu_has_amd_erratum(nr) \
> +        cpu_has_amd_erratum(&current_cpu_data, AMD_ERRATUM_##nr)
>  
>  #include "x86_emulate/x86_emulate.c"
> --- a/xen/arch/x86/x86_emulate/x86_emulate.c
> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c
> @@ -2761,6 +2761,9 @@ x86_emulate(
>      case 0xd9: /* FPU 0xd9 */
>          switch ( modrm )
>          {
> +        case 0xfb: /* fsincos */
> +            fail_if(cpu_has_amd_erratum(573));
> +            /* fall through */
>          case 0xc0 ... 0xc7: /* fld %stN */
>          case 0xc8 ... 0xcf: /* fxch %stN */
>          case 0xd0: /* fnop */
> @@ -2786,7 +2789,6 @@ x86_emulate(
>          case 0xf8: /* fprem */
>          case 0xf9: /* fyl2xp1 */
>          case 0xfa: /* fsqrt */
> -        case 0xfb: /* fsincos */
>          case 0xfc: /* frndint */
>          case 0xfd: /* fscale */
>          case 0xfe: /* fsin */
> --- a/xen/include/asm-x86/amd.h
> +++ b/xen/include/asm-x86/amd.h
> @@ -134,6 +134,12 @@
>      AMD_OSVW_ERRATUM(3, AMD_MODEL_RANGE(0x10, 0x2, 0x1, 0xff, 0xf), \
>        AMD_MODEL_RANGE(0x12, 0x0, 0x0, 0x1, 0x0))
>  
> +#define AMD_ERRATUM_573       \
> +    AMD_LEGACY_ERRATUM(AMD_MODEL_RANGE(0x0f, 0x0, 0x0, 0xff, 0xf), \
> +                       AMD_MODEL_RANGE(0x10, 0x0, 0x0, 0xff, 0xf), \
> +                       AMD_MODEL_RANGE(0x11, 0x0, 0x0, 0xff, 0xf), \
> +                       AMD_MODEL_RANGE(0x12, 0x0, 0x0, 0xff, 0xf))
> +
>  struct cpuinfo_x86;
>  int cpu_has_amd_erratum(const struct cpuinfo_x86 *, int, ...);
>  
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 16:53:21 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 16:53:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbEYT-0006uA-C1; Thu, 15 Dec 2011 16:53:13 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RbEYR-0006tg-DY
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 16:53:11 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1323967984!5701420!1
X-Originating-IP: [74.125.83.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23888 invoked from network); 15 Dec 2011 16:53:04 -0000
Received: from mail-ee0-f43.google.com (HELO mail-ee0-f43.google.com)
	(74.125.83.43)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 16:53:04 -0000
Received: by eekd4 with SMTP id d4so5042957eek.30
	for <xen-devel@lists.xensource.com>;
	Thu, 15 Dec 2011 08:53:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=3R3djZZH4YBKsgZwnTUa+6H9QyMyoeB7d2BlEpJADW8=;
	b=F83LAdm4y5gmbCaM733Y9iyvGoUY29bAa8vWZRwu/XfDsueOjgqvrzC3joEIOBCmfW
	JMzwpKRy4s8/Lc9xi22bhKkrPy6ThwTV7q4QwqkcLRQvcBJT8rE760iB0ImTMOmgJ0Ry
	fVWHBoRrlCvqGmOlpkgQhv07PTxlL+3XR03i0=
Received: by 10.180.105.131 with SMTP id gm3mr6519220wib.50.1323967984180;
	Thu, 15 Dec 2011 08:53:04 -0800 (PST)
Received: from [192.168.1.3] (host81-152-17-11.range81-152.btcentralplus.com.
	[81.152.17.11])
	by mx.google.com with ESMTPS id hb10sm9074369wib.16.2011.12.15.08.53.03
	(version=SSLv3 cipher=OTHER); Thu, 15 Dec 2011 08:53:03 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Thu, 15 Dec 2011 16:53:03 +0000
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Message-ID: <CB0FD66F.36073%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH] x86/emulator: workaround for AMD erratum 573
Thread-Index: Acy7SgJzLDsApI0lDUKPtj6ZNB+jew==
In-Reply-To: <4EEA01350200007800068241@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH] x86/emulator: workaround for AMD erratum 573
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 15/12/2011 13:16, "Jan Beulich" <JBeulich@suse.com> wrote:

> The only cases where we might end up emulating fsincos (as any other
> x87 operations without memory operands) are
> - when a HVM guest is in real mode (not applicable on AMD)
> - between two half page table updates in PAE mode (unlikely, and not
>   doing the emulation here does affect only performance, not
>   correctness)
> - when a guest maliciously (or erroneously) modifies an (MMIO or page
>   table update) instruction under emulation (unspecified behavior)
> 
> Hence, in order to avoid the erratum to cause harm to the entire host,
> don't emulate fsincos on the affected AMD CPU families.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Keir Fraser <keir@xen.org>

> --- a/tools/tests/x86_emulator/x86_emulate.c
> +++ b/tools/tests/x86_emulator/x86_emulate.c
> @@ -9,5 +9,7 @@ typedef bool bool_t;
>  
>  #define BUG() abort()
>  
> +#define cpu_has_amd_erratum(nr) 0
> +
>  #include "x86_emulate/x86_emulate.h"
>  #include "x86_emulate/x86_emulate.c"
> --- a/xen/arch/x86/x86_emulate.c
> +++ b/xen/arch/x86/x86_emulate.c
> @@ -10,8 +10,14 @@
>   */
>  
>  #include <asm/x86_emulate.h>
> +#include <asm/processor.h> /* current_cpu_info */
> +#include <asm/amd.h> /* cpu_has_amd_erratum() */
>  
>  /* Avoid namespace pollution. */
>  #undef cmpxchg
> +#undef cpuid
> +
> +#define cpu_has_amd_erratum(nr) \
> +        cpu_has_amd_erratum(&current_cpu_data, AMD_ERRATUM_##nr)
>  
>  #include "x86_emulate/x86_emulate.c"
> --- a/xen/arch/x86/x86_emulate/x86_emulate.c
> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c
> @@ -2761,6 +2761,9 @@ x86_emulate(
>      case 0xd9: /* FPU 0xd9 */
>          switch ( modrm )
>          {
> +        case 0xfb: /* fsincos */
> +            fail_if(cpu_has_amd_erratum(573));
> +            /* fall through */
>          case 0xc0 ... 0xc7: /* fld %stN */
>          case 0xc8 ... 0xcf: /* fxch %stN */
>          case 0xd0: /* fnop */
> @@ -2786,7 +2789,6 @@ x86_emulate(
>          case 0xf8: /* fprem */
>          case 0xf9: /* fyl2xp1 */
>          case 0xfa: /* fsqrt */
> -        case 0xfb: /* fsincos */
>          case 0xfc: /* frndint */
>          case 0xfd: /* fscale */
>          case 0xfe: /* fsin */
> --- a/xen/include/asm-x86/amd.h
> +++ b/xen/include/asm-x86/amd.h
> @@ -134,6 +134,12 @@
>      AMD_OSVW_ERRATUM(3, AMD_MODEL_RANGE(0x10, 0x2, 0x1, 0xff, 0xf), \
>        AMD_MODEL_RANGE(0x12, 0x0, 0x0, 0x1, 0x0))
>  
> +#define AMD_ERRATUM_573       \
> +    AMD_LEGACY_ERRATUM(AMD_MODEL_RANGE(0x0f, 0x0, 0x0, 0xff, 0xf), \
> +                       AMD_MODEL_RANGE(0x10, 0x0, 0x0, 0xff, 0xf), \
> +                       AMD_MODEL_RANGE(0x11, 0x0, 0x0, 0xff, 0xf), \
> +                       AMD_MODEL_RANGE(0x12, 0x0, 0x0, 0xff, 0xf))
> +
>  struct cpuinfo_x86;
>  int cpu_has_amd_erratum(const struct cpuinfo_x86 *, int, ...);
>  
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 16:53:21 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 16:53:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbEYR-0006ts-NJ; Thu, 15 Dec 2011 16:53:11 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RbEYQ-0006tc-9r
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 16:53:10 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1323967983!5724641!1
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11286 invoked from network); 15 Dec 2011 16:53:03 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 16:53:03 -0000
Received: by wgbds11 with SMTP id ds11so3710594wgb.24
	for <xen-devel@lists.xensource.com>;
	Thu, 15 Dec 2011 08:53:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=iXOlUhzebEwsN17aiL1kNqSrQLkc/CvD50F3yxn3fNg=;
	b=QvS07NWStB7SdpjACrBfoolV8ljbTuDSjPtWmsO/gaVP2VfNVT7Fps+YNz9cvJdfjf
	kfACxkOL23dAUuaPPHFYXZu4D8Z2HqcmgnNR6QiU1QAJCFlg5WoeLFFhgg5kGwXvEjGz
	kxw7xyFvTqp3uDkeSHWoFVxSVQb7P5/zaAdAs=
Received: by 10.227.59.203 with SMTP id m11mr2974233wbh.18.1323967982955;
	Thu, 15 Dec 2011 08:53:02 -0800 (PST)
Received: from [192.168.1.3] (host81-152-17-11.range81-152.btcentralplus.com.
	[81.152.17.11])
	by mx.google.com with ESMTPS id hb10sm9074369wib.16.2011.12.15.08.52.59
	(version=SSLv3 cipher=OTHER); Thu, 15 Dec 2011 08:53:02 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Thu, 15 Dec 2011 16:52:50 +0000
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <CB0FD662.36072%keir@xen.org>
Thread-Topic: [Xen-devel] fsincos emulation on AMD CPUs
Thread-Index: Acy7SfqzW+wVJ4SAYEisTdde2oqROQ==
In-Reply-To: <4EEA020F0200007800068244@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: Paolo Bonzini <pbonzini@redhat.com>, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] fsincos emulation on AMD CPUs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 15/12/2011 13:19, "Jan Beulich" <JBeulich@suse.com> wrote:

>>>> On 15.12.11 at 14:13, Keir Fraser <keir@xen.org> wrote:
>> On 15/12/2011 13:08, "Jan Beulich" <JBeulich@suse.com> wrote:
>> 
>>>>>> On 15.12.11 at 13:33, Keir Fraser <keir@xen.org> wrote:
>>>> More detail: the full patch is ugly and hard to test all cases. And there's
>>>> no practical scenario where we want to emulate FSINCOS on AMD -- we don't
>>>> emulate realmode on AMD, FSINCOS on a shadowed page certainly indicates
>>>> that
>>>> we should unshadow the page, FSINCOS on MMIO is mad or malicious.
>>> 
>>> Those latter two cases can't really happen, as fsincos has no memory
>>> operand.
>> 
>> Possibly if the instruction itself was in a recycled page-table page? Or in
>> an MMIO page, or the malicious race that Paolo described --- definitely
>> malicious either way.
>> 
>> Anyhow the short answer is we never want to emulate it on AMD. :-)
> 
> I just sent out the patch as quoted in the reply to Paolo, but you're
> suggesting to be even more drastic and ignore the CPU family. If
> you really want it done that way, I wonder whether we should bail on
> AMD for *all* x87 operations not having memory operands.

Your patch is fine.

 -- Keir

> Jan
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 16:53:21 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 16:53:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbEYR-0006ts-NJ; Thu, 15 Dec 2011 16:53:11 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RbEYQ-0006tc-9r
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 16:53:10 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1323967983!5724641!1
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11286 invoked from network); 15 Dec 2011 16:53:03 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 16:53:03 -0000
Received: by wgbds11 with SMTP id ds11so3710594wgb.24
	for <xen-devel@lists.xensource.com>;
	Thu, 15 Dec 2011 08:53:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=iXOlUhzebEwsN17aiL1kNqSrQLkc/CvD50F3yxn3fNg=;
	b=QvS07NWStB7SdpjACrBfoolV8ljbTuDSjPtWmsO/gaVP2VfNVT7Fps+YNz9cvJdfjf
	kfACxkOL23dAUuaPPHFYXZu4D8Z2HqcmgnNR6QiU1QAJCFlg5WoeLFFhgg5kGwXvEjGz
	kxw7xyFvTqp3uDkeSHWoFVxSVQb7P5/zaAdAs=
Received: by 10.227.59.203 with SMTP id m11mr2974233wbh.18.1323967982955;
	Thu, 15 Dec 2011 08:53:02 -0800 (PST)
Received: from [192.168.1.3] (host81-152-17-11.range81-152.btcentralplus.com.
	[81.152.17.11])
	by mx.google.com with ESMTPS id hb10sm9074369wib.16.2011.12.15.08.52.59
	(version=SSLv3 cipher=OTHER); Thu, 15 Dec 2011 08:53:02 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Thu, 15 Dec 2011 16:52:50 +0000
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <CB0FD662.36072%keir@xen.org>
Thread-Topic: [Xen-devel] fsincos emulation on AMD CPUs
Thread-Index: Acy7SfqzW+wVJ4SAYEisTdde2oqROQ==
In-Reply-To: <4EEA020F0200007800068244@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: Paolo Bonzini <pbonzini@redhat.com>, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] fsincos emulation on AMD CPUs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 15/12/2011 13:19, "Jan Beulich" <JBeulich@suse.com> wrote:

>>>> On 15.12.11 at 14:13, Keir Fraser <keir@xen.org> wrote:
>> On 15/12/2011 13:08, "Jan Beulich" <JBeulich@suse.com> wrote:
>> 
>>>>>> On 15.12.11 at 13:33, Keir Fraser <keir@xen.org> wrote:
>>>> More detail: the full patch is ugly and hard to test all cases. And there's
>>>> no practical scenario where we want to emulate FSINCOS on AMD -- we don't
>>>> emulate realmode on AMD, FSINCOS on a shadowed page certainly indicates
>>>> that
>>>> we should unshadow the page, FSINCOS on MMIO is mad or malicious.
>>> 
>>> Those latter two cases can't really happen, as fsincos has no memory
>>> operand.
>> 
>> Possibly if the instruction itself was in a recycled page-table page? Or in
>> an MMIO page, or the malicious race that Paolo described --- definitely
>> malicious either way.
>> 
>> Anyhow the short answer is we never want to emulate it on AMD. :-)
> 
> I just sent out the patch as quoted in the reply to Paolo, but you're
> suggesting to be even more drastic and ignore the CPU family. If
> you really want it done that way, I wonder whether we should bail on
> AMD for *all* x87 operations not having memory operands.

Your patch is fine.

 -- Keir

> Jan
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 16:54:14 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 16:54:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbEZL-000738-6n; Thu, 15 Dec 2011 16:54:07 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RbEZJ-00072k-9d
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 16:54:05 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1323968003!46900749!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11235 invoked from network); 15 Dec 2011 16:53:23 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-5.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 15 Dec 2011 16:53:23 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 15 Dec 2011 16:54:03 +0000
Message-Id: <4EEA343902000078000684FC@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 15 Dec 2011 16:54:01 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: <stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1112131831560.3517@kaball-desktop>
	<1323966657-19790-6-git-send-email-stefano.stabellini@eu.citrix.com>
In-Reply-To: <1323966657-19790-6-git-send-email-stefano.stabellini@eu.citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com, keir.xen@gmail.com,
	Ian Campbell <ian.campbell@citrix.com>, Tim.Deegan@citrix.com
Subject: Re: [Xen-devel] [PATCH v3 06/25] libelf-loader: introduce
	elf_load_image
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 15.12.11 at 17:30, <stefano.stabellini@eu.citrix.com> wrote:
> From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> 
> Implement a new function, called elf_load_image, to perform the actually
> copy of the elf image and clearing the padding.
> The function is implemented as memcpy and memset when the library is
> built as part of the tools, but it is implemented as raw_copy_to_guest and
> raw_clear_guest when built as part of Xen, so that it can be safely called
> with an HVM style dom0.
> 
> 
> Changes in v3:
> 
> - switch to raw_copy_to_guest and raw_clear_guest.
> 
> 
> Changes in v2:
> 
> - remove CONFIG_KERNEL_NO_RELOC.
> 
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
> ---
>  xen/common/libelf/libelf-loader.c |   17 +++++++++++++++--
>  1 files changed, 15 insertions(+), 2 deletions(-)
> 
> diff --git a/xen/common/libelf/libelf-loader.c 
> b/xen/common/libelf/libelf-loader.c
> index 1ccf7d3..d2cb5b3 100644
> --- a/xen/common/libelf/libelf-loader.c
> +++ b/xen/common/libelf/libelf-loader.c
> @@ -107,11 +107,25 @@ void elf_set_log(struct elf_binary *elf, 
> elf_log_callback *log_callback,
>      elf->log_caller_data = log_caller_data;
>      elf->verbose = verbose;
>  }
> +
> +static void elf_load_image(void *dst, const void *src, uint64_t filesz, 
> uint64_t memsz)
> +{
> +    memcpy(dst, src, filesz);
> +    memset(dst + filesz, 0, memsz - filesz);
> +}
>  #else
> +#include <asm/guest_access.h>
> +
>  void elf_set_verbose(struct elf_binary *elf)
>  {
>      elf->verbose = 1;
>  }
> +
> +static void elf_load_image(void *dst, const void *src, uint64_t filesz, 
> uint64_t memsz)
> +{
> +    raw_copy_to_guest(dst, src, filesz);
> +    raw_clear_guest(dst + filesz, memsz - filesz);

I thought I had mentioned this already - calling user/guest access
functions without checking their return value is bogus.

Jan

> +}
>  #endif
>  
>  /* Calculate the required additional kernel space for the elf image */
> @@ -256,8 +270,7 @@ void elf_load_binary(struct elf_binary *elf)
>          dest = elf_get_ptr(elf, paddr);
>          elf_msg(elf, "%s: phdr %" PRIu64 " at 0x%p -> 0x%p\n",
>                  __func__, i, dest, dest + filesz);
> -        memcpy(dest, elf->image + offset, filesz);
> -        memset(dest + filesz, 0, memsz - filesz);
> +        elf_load_image(dest, elf->image + offset, filesz, memsz);
>      }
>  
>      elf_load_bsdsyms(elf);
> -- 
> 1.7.2.5




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 16:54:14 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 16:54:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbEZL-000738-6n; Thu, 15 Dec 2011 16:54:07 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RbEZJ-00072k-9d
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 16:54:05 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1323968003!46900749!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11235 invoked from network); 15 Dec 2011 16:53:23 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-5.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 15 Dec 2011 16:53:23 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 15 Dec 2011 16:54:03 +0000
Message-Id: <4EEA343902000078000684FC@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 15 Dec 2011 16:54:01 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: <stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1112131831560.3517@kaball-desktop>
	<1323966657-19790-6-git-send-email-stefano.stabellini@eu.citrix.com>
In-Reply-To: <1323966657-19790-6-git-send-email-stefano.stabellini@eu.citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com, keir.xen@gmail.com,
	Ian Campbell <ian.campbell@citrix.com>, Tim.Deegan@citrix.com
Subject: Re: [Xen-devel] [PATCH v3 06/25] libelf-loader: introduce
	elf_load_image
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 15.12.11 at 17:30, <stefano.stabellini@eu.citrix.com> wrote:
> From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> 
> Implement a new function, called elf_load_image, to perform the actually
> copy of the elf image and clearing the padding.
> The function is implemented as memcpy and memset when the library is
> built as part of the tools, but it is implemented as raw_copy_to_guest and
> raw_clear_guest when built as part of Xen, so that it can be safely called
> with an HVM style dom0.
> 
> 
> Changes in v3:
> 
> - switch to raw_copy_to_guest and raw_clear_guest.
> 
> 
> Changes in v2:
> 
> - remove CONFIG_KERNEL_NO_RELOC.
> 
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
> ---
>  xen/common/libelf/libelf-loader.c |   17 +++++++++++++++--
>  1 files changed, 15 insertions(+), 2 deletions(-)
> 
> diff --git a/xen/common/libelf/libelf-loader.c 
> b/xen/common/libelf/libelf-loader.c
> index 1ccf7d3..d2cb5b3 100644
> --- a/xen/common/libelf/libelf-loader.c
> +++ b/xen/common/libelf/libelf-loader.c
> @@ -107,11 +107,25 @@ void elf_set_log(struct elf_binary *elf, 
> elf_log_callback *log_callback,
>      elf->log_caller_data = log_caller_data;
>      elf->verbose = verbose;
>  }
> +
> +static void elf_load_image(void *dst, const void *src, uint64_t filesz, 
> uint64_t memsz)
> +{
> +    memcpy(dst, src, filesz);
> +    memset(dst + filesz, 0, memsz - filesz);
> +}
>  #else
> +#include <asm/guest_access.h>
> +
>  void elf_set_verbose(struct elf_binary *elf)
>  {
>      elf->verbose = 1;
>  }
> +
> +static void elf_load_image(void *dst, const void *src, uint64_t filesz, 
> uint64_t memsz)
> +{
> +    raw_copy_to_guest(dst, src, filesz);
> +    raw_clear_guest(dst + filesz, memsz - filesz);

I thought I had mentioned this already - calling user/guest access
functions without checking their return value is bogus.

Jan

> +}
>  #endif
>  
>  /* Calculate the required additional kernel space for the elf image */
> @@ -256,8 +270,7 @@ void elf_load_binary(struct elf_binary *elf)
>          dest = elf_get_ptr(elf, paddr);
>          elf_msg(elf, "%s: phdr %" PRIu64 " at 0x%p -> 0x%p\n",
>                  __func__, i, dest, dest + filesz);
> -        memcpy(dest, elf->image + offset, filesz);
> -        memset(dest + filesz, 0, memsz - filesz);
> +        elf_load_image(dest, elf->image + offset, filesz, memsz);
>      }
>  
>      elf_load_bsdsyms(elf);
> -- 
> 1.7.2.5




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 16:54:50 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 16:54:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbEZt-0007Bo-O7; Thu, 15 Dec 2011 16:54:41 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RbEZs-0007AW-5e
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 16:54:40 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1323968073!5673850!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjI2MA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27508 invoked from network); 15 Dec 2011 16:54:33 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 16:54:33 -0000
X-IronPort-AV: E=Sophos;i="4.71,357,1320624000"; 
   d="scan'208";a="9497522"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Dec 2011 16:54:32 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 15 Dec 2011 16:54:32 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RbEZk-0007Qc-De; Thu, 15 Dec 2011 16:54:32 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RbEZk-0003Fb-Cj;
	Thu, 15 Dec 2011 16:54:32 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20202.9800.381383.266900@mariner.uk.xensource.com>
Date: Thu, 15 Dec 2011 16:54:32 +0000
To: Ian Campbell <ian.campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <f4586d1a539c869e31fa.1323792781@cosworth.uk.xensource.com>
References: <patchbomb.1323792779@cosworth.uk.xensource.com>
	<f4586d1a539c869e31fa.1323792781@cosworth.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Olaf Hering <olaf@aepfle.de>, xen-devel@lists.xensource.com,
	Vincent Hanquez <Vincent.Hanquez@eu.citrix.com>,
	Jonathan Ludlam <Jonathan.Ludlam@eu.citrix.com>, konrad.wilk@oracle.com
Subject: Re: [Xen-devel] [PATCH 2 of 4 V2] Linux/xencommons: Use oxenstored
 by default when available
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("[Xen-devel] [PATCH 2 of 4 V2] Linux/xencommons: Use oxenstored by default when available"):
> Linux/xencommons: Use oxenstored by default when available

I've applied #1, #3, and #4.  I'll wait with #2 until my test system
gets a pass and push on the change to collect the oxenstored logs.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 16:54:50 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 16:54:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbEZt-0007Bo-O7; Thu, 15 Dec 2011 16:54:41 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RbEZs-0007AW-5e
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 16:54:40 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1323968073!5673850!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjI2MA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27508 invoked from network); 15 Dec 2011 16:54:33 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 16:54:33 -0000
X-IronPort-AV: E=Sophos;i="4.71,357,1320624000"; 
   d="scan'208";a="9497522"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Dec 2011 16:54:32 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 15 Dec 2011 16:54:32 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RbEZk-0007Qc-De; Thu, 15 Dec 2011 16:54:32 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RbEZk-0003Fb-Cj;
	Thu, 15 Dec 2011 16:54:32 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20202.9800.381383.266900@mariner.uk.xensource.com>
Date: Thu, 15 Dec 2011 16:54:32 +0000
To: Ian Campbell <ian.campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <f4586d1a539c869e31fa.1323792781@cosworth.uk.xensource.com>
References: <patchbomb.1323792779@cosworth.uk.xensource.com>
	<f4586d1a539c869e31fa.1323792781@cosworth.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Olaf Hering <olaf@aepfle.de>, xen-devel@lists.xensource.com,
	Vincent Hanquez <Vincent.Hanquez@eu.citrix.com>,
	Jonathan Ludlam <Jonathan.Ludlam@eu.citrix.com>, konrad.wilk@oracle.com
Subject: Re: [Xen-devel] [PATCH 2 of 4 V2] Linux/xencommons: Use oxenstored
 by default when available
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("[Xen-devel] [PATCH 2 of 4 V2] Linux/xencommons: Use oxenstored by default when available"):
> Linux/xencommons: Use oxenstored by default when available

I've applied #1, #3, and #4.  I'll wait with #2 until my test system
gets a pass and push on the change to collect the oxenstored logs.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 16:56:48 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 16:56:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbEbn-0007Vw-Oa; Thu, 15 Dec 2011 16:56:39 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RbEbm-0007V9-Br
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 16:56:38 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1323968142!57467438!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjI2MA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10498 invoked from network); 15 Dec 2011 16:55:43 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 16:55:43 -0000
X-IronPort-AV: E=Sophos;i="4.71,357,1320624000"; 
   d="scan'208";a="9497564"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Dec 2011 16:56:32 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 15 Dec 2011 16:56:32 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RbEbg-0007RP-23; Thu, 15 Dec 2011 16:56:32 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RbEbg-0003Ld-0u;
	Thu, 15 Dec 2011 16:56:32 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20202.9920.12323.174418@mariner.uk.xensource.com>
Date: Thu, 15 Dec 2011 16:56:32 +0000
To: Ian Campbell <ian.campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <738c34b1b0450724c4b9.1323796149@cosworth.uk.xensource.com>
References: <738c34b1b0450724c4b9.1323796149@cosworth.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] libxl: remove stubdom device model save
 file when destroying stubdom
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("[Xen-devel] [PATCH] libxl: remove stubdom device model save file when destroying stubdom"):
> libxl: remove stubdom device model save file when destroying stubdom

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 16:56:48 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 16:56:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbEbn-0007Vw-Oa; Thu, 15 Dec 2011 16:56:39 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RbEbm-0007V9-Br
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 16:56:38 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1323968142!57467438!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjI2MA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10498 invoked from network); 15 Dec 2011 16:55:43 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 16:55:43 -0000
X-IronPort-AV: E=Sophos;i="4.71,357,1320624000"; 
   d="scan'208";a="9497564"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Dec 2011 16:56:32 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 15 Dec 2011 16:56:32 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RbEbg-0007RP-23; Thu, 15 Dec 2011 16:56:32 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RbEbg-0003Ld-0u;
	Thu, 15 Dec 2011 16:56:32 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20202.9920.12323.174418@mariner.uk.xensource.com>
Date: Thu, 15 Dec 2011 16:56:32 +0000
To: Ian Campbell <ian.campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <738c34b1b0450724c4b9.1323796149@cosworth.uk.xensource.com>
References: <738c34b1b0450724c4b9.1323796149@cosworth.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] libxl: remove stubdom device model save
 file when destroying stubdom
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("[Xen-devel] [PATCH] libxl: remove stubdom device model save file when destroying stubdom"):
> libxl: remove stubdom device model save file when destroying stubdom

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 16:57:58 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 16: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.xensource.com>)
	id 1RbEcw-0007fR-7p; Thu, 15 Dec 2011 16:57:50 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RbEcv-0007eg-CW
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 16:57:49 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1323968263!8966900!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjI2MA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20134 invoked from network); 15 Dec 2011 16:57:43 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 16:57:43 -0000
X-IronPort-AV: E=Sophos;i="4.71,357,1320624000"; 
   d="scan'208";a="9497570"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Dec 2011 16:56:42 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 15 Dec 2011 16:56:42 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Thu, 15 Dec 2011 16:56:41 +0000
In-Reply-To: <20202.9800.381383.266900@mariner.uk.xensource.com>
References: <patchbomb.1323792779@cosworth.uk.xensource.com>
	<f4586d1a539c869e31fa.1323792781@cosworth.uk.xensource.com>
	<20202.9800.381383.266900@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323968201.20077.498.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Olaf Hering <olaf@aepfle.de>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Vincent Hanquez <Vincent.Hanquez@eu.citrix.com>,
	Jonathan Ludlam <Jonathan.Ludlam@eu.citrix.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH 2 of 4 V2] Linux/xencommons: Use oxenstored
 by default when available
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2011-12-15 at 16:54 +0000, Ian Jackson wrote:
> Ian Campbell writes ("[Xen-devel] [PATCH 2 of 4 V2] Linux/xencommons: Use oxenstored by default when available"):
> > Linux/xencommons: Use oxenstored by default when available
> 
> I've applied #1, #3, and #4.  I'll wait with #2 until my test system
> gets a pass and push on the change to collect the oxenstored logs.

Sounds good. Thanks.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 16:57:58 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 16: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.xensource.com>)
	id 1RbEcw-0007fR-7p; Thu, 15 Dec 2011 16:57:50 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RbEcv-0007eg-CW
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 16:57:49 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1323968263!8966900!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjI2MA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20134 invoked from network); 15 Dec 2011 16:57:43 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 16:57:43 -0000
X-IronPort-AV: E=Sophos;i="4.71,357,1320624000"; 
   d="scan'208";a="9497570"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Dec 2011 16:56:42 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 15 Dec 2011 16:56:42 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Thu, 15 Dec 2011 16:56:41 +0000
In-Reply-To: <20202.9800.381383.266900@mariner.uk.xensource.com>
References: <patchbomb.1323792779@cosworth.uk.xensource.com>
	<f4586d1a539c869e31fa.1323792781@cosworth.uk.xensource.com>
	<20202.9800.381383.266900@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323968201.20077.498.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Olaf Hering <olaf@aepfle.de>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Vincent Hanquez <Vincent.Hanquez@eu.citrix.com>,
	Jonathan Ludlam <Jonathan.Ludlam@eu.citrix.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH 2 of 4 V2] Linux/xencommons: Use oxenstored
 by default when available
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2011-12-15 at 16:54 +0000, Ian Jackson wrote:
> Ian Campbell writes ("[Xen-devel] [PATCH 2 of 4 V2] Linux/xencommons: Use oxenstored by default when available"):
> > Linux/xencommons: Use oxenstored by default when available
> 
> I've applied #1, #3, and #4.  I'll wait with #2 until my test system
> gets a pass and push on the change to collect the oxenstored logs.

Sounds good. Thanks.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 16:59:37 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 16:59:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbEeV-0007rE-PE; Thu, 15 Dec 2011 16:59:27 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RbEeU-0007q8-4B
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 16:59:26 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1323968360!8375910!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjI2MA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5739 invoked from network); 15 Dec 2011 16:59:20 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 16:59:20 -0000
X-IronPort-AV: E=Sophos;i="4.71,357,1320624000"; 
   d="scan'208";a="9497632"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Dec 2011 16:59:19 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 15 Dec 2011 16:59:19 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Wei Wang2 <wei.wang2@amd.com>
Date: Thu, 15 Dec 2011 16:59:19 +0000
In-Reply-To: <201112151552.09037.wei.wang2@amd.com>
References: <patchbomb.1323876561@gran.amd.com>
	<24f4a0a23da71c58f457.1323876577@gran.amd.com>
	<1323959445.20077.490.camel@zakaz.uk.xensource.com>
	<201112151552.09037.wei.wang2@amd.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323968359.20077.501.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, "JBeulich@suse.com" <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 16 of 16] libxl: add iommu parameter to
 qemu-dm
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2011-12-15 at 14:52 +0000, Wei Wang2 wrote:
> On Thursday 15 December 2011 15:30:44 Ian Campbell wrote:
> > On Wed, 2011-12-14 at 15:29 +0000, Wei Wang wrote:
> > > # HG changeset patch
> > > # User Wei Wang <wei.wang2@amd.com>
> > > # Date 1323876144 -3600
> > > # Node ID 24f4a0a23da71c58f457f0bf98aa8238dd45332d
> > > # Parent  93658ca85035d6a4e56e2e6602c02859974d30a4
> > > libxl: add iommu parameter to qemu-dm.
> > > When iomm = 0, virtual iommu device will be disabled.
> > >
> > > Signed-off-by: Wei Wang <wei.wang2@amd.com>
> > >
> > > diff -r 93658ca85035 -r 24f4a0a23da7 tools/libxl/libxl_dm.c
> > > --- a/tools/libxl/libxl_dm.c	Wed Dec 14 16:22:23 2011 +0100
> > > +++ b/tools/libxl/libxl_dm.c	Wed Dec 14 16:22:24 2011 +0100
> > > @@ -194,6 +194,9 @@ static char ** libxl__build_device_model
> > >          if (info->gfx_passthru) {
> > >              flexarray_append(dm_args, "-gfx_passthru");
> > >          }
> > > +        if (info->iommu) {
> > > +            flexarray_append(dm_args, "-iommu");
> > > +        }
> > >      }
> > >      if (info->saved_state) {
> > >          flexarray_vappend(dm_args, "-loadvm", info->saved_state, NULL);
> > > @@ -404,6 +407,9 @@ static char ** libxl__build_device_model
> > >          if (info->gfx_passthru) {
> > >              flexarray_append(dm_args, "-gfx_passthru");
> > >          }
> > > +        if (info->iommu) {
> > > +            flexarray_append(dm_args, "-iommu");
> > > +        }
> > >      }
> > >      if (info->saved_state) {
> > >          /* This file descriptor is meant to be used by QEMU */
> > > diff -r 93658ca85035 -r 24f4a0a23da7 tools/libxl/libxl_types.idl
> > > --- a/tools/libxl/libxl_types.idl	Wed Dec 14 16:22:23 2011 +0100
> > > +++ b/tools/libxl/libxl_types.idl	Wed Dec 14 16:22:24 2011 +0100
> > > @@ -254,6 +254,7 @@ The password never expires"""),
> > >      ("extra",            libxl_string_list, False, "extra parameters
> > > pass directly to qemu, NULL terminated"), ("extra_pv",        
> > > libxl_string_list, False, "extra parameters pass directly to qemu for PV
> > > guest, NULL terminated"), ("extra_hvm",        libxl_string_list, False,
> > > "extra parameters pass directly to qemu for HVM guest, NULL terminated"),
> > > +    ("iommu",            bool,              False, "guest iommu enabled
> > > or disabled"), ],
> > >      comment=
> > >  """Device Model information.
> > > diff -r 93658ca85035 -r 24f4a0a23da7 tools/libxl/xl_cmdimpl.c
> > > --- a/tools/libxl/xl_cmdimpl.c	Wed Dec 14 16:22:23 2011 +0100
> > > +++ b/tools/libxl/xl_cmdimpl.c	Wed Dec 14 16:22:24 2011 +0100
> > > @@ -386,6 +386,7 @@ static void printf_info(int domid,
> > >          printf("\t\t\t(spicedisable_ticketing %d)\n",
> > >                      dm_info->spicedisable_ticketing);
> > >          printf("\t\t\t(spiceagent_mouse %d)\n",
> > > dm_info->spiceagent_mouse); +        printf("\t\t\t(iommu %d)\n",
> > > dm_info->iommu);
> > >          printf("\t\t)\n");
> > >          break;
> > >      case LIBXL_DOMAIN_TYPE_PV:
> > > @@ -1217,6 +1218,8 @@ skip_vfb:
> > >          xlu_cfg_replace_string (config, "soundhw", &dm_info->soundhw,
> > > 0); if (!xlu_cfg_get_long (config, "xen_platform_pci", &l, 0))
> > > dm_info->xen_platform_pci = l;
> > > +        if (!xlu_cfg_get_long (config, "iommu", &l, 0))
> > > +            dm_info->iommu = l;
> >
> > Didn't you already parse this same key into the build_info? Is there
> > ever a possibility of the dm_info and build_info versions of this field
> > differing?
> 
> > Assuming not I think this setting ought to only live in one place and I
> > think build_info should be that place rather than the dm info. That
> > might need some refactoring in libxl to pass the right struct down.
> 
> Yes, I added a new flag in build_info, which will control hvmloader to build 
> IVRS table. And I also need a flag for qemu-dm to decide if virtual iommu 
> device should be registered or not.  I just saw other parameters like 
> gfx-passthu are attached to dm_info, so I do the same thing for iommu. 

gfx-passthru is only in dm_info

> Also I cannot make a reference of libxl_domain_build_info in 
> libxl__build_device_model_args.

You just need to plumb the variable through. This is apparently just the
first time we have need of it.

> > Also you have only CC'd the hypervisor maintainers on this (and the
> > other?) tool stack patch. Please check MAINTAINERS to see who ought to
> > be CC'd.
> Thanks, I cc'd them to Ian Jackson.
> 
> > Ian.
> 
> Wei
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 16:59:37 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 16:59:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbEeV-0007rE-PE; Thu, 15 Dec 2011 16:59:27 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RbEeU-0007q8-4B
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 16:59:26 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1323968360!8375910!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjI2MA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5739 invoked from network); 15 Dec 2011 16:59:20 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 16:59:20 -0000
X-IronPort-AV: E=Sophos;i="4.71,357,1320624000"; 
   d="scan'208";a="9497632"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Dec 2011 16:59:19 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 15 Dec 2011 16:59:19 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Wei Wang2 <wei.wang2@amd.com>
Date: Thu, 15 Dec 2011 16:59:19 +0000
In-Reply-To: <201112151552.09037.wei.wang2@amd.com>
References: <patchbomb.1323876561@gran.amd.com>
	<24f4a0a23da71c58f457.1323876577@gran.amd.com>
	<1323959445.20077.490.camel@zakaz.uk.xensource.com>
	<201112151552.09037.wei.wang2@amd.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323968359.20077.501.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, "JBeulich@suse.com" <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 16 of 16] libxl: add iommu parameter to
 qemu-dm
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2011-12-15 at 14:52 +0000, Wei Wang2 wrote:
> On Thursday 15 December 2011 15:30:44 Ian Campbell wrote:
> > On Wed, 2011-12-14 at 15:29 +0000, Wei Wang wrote:
> > > # HG changeset patch
> > > # User Wei Wang <wei.wang2@amd.com>
> > > # Date 1323876144 -3600
> > > # Node ID 24f4a0a23da71c58f457f0bf98aa8238dd45332d
> > > # Parent  93658ca85035d6a4e56e2e6602c02859974d30a4
> > > libxl: add iommu parameter to qemu-dm.
> > > When iomm = 0, virtual iommu device will be disabled.
> > >
> > > Signed-off-by: Wei Wang <wei.wang2@amd.com>
> > >
> > > diff -r 93658ca85035 -r 24f4a0a23da7 tools/libxl/libxl_dm.c
> > > --- a/tools/libxl/libxl_dm.c	Wed Dec 14 16:22:23 2011 +0100
> > > +++ b/tools/libxl/libxl_dm.c	Wed Dec 14 16:22:24 2011 +0100
> > > @@ -194,6 +194,9 @@ static char ** libxl__build_device_model
> > >          if (info->gfx_passthru) {
> > >              flexarray_append(dm_args, "-gfx_passthru");
> > >          }
> > > +        if (info->iommu) {
> > > +            flexarray_append(dm_args, "-iommu");
> > > +        }
> > >      }
> > >      if (info->saved_state) {
> > >          flexarray_vappend(dm_args, "-loadvm", info->saved_state, NULL);
> > > @@ -404,6 +407,9 @@ static char ** libxl__build_device_model
> > >          if (info->gfx_passthru) {
> > >              flexarray_append(dm_args, "-gfx_passthru");
> > >          }
> > > +        if (info->iommu) {
> > > +            flexarray_append(dm_args, "-iommu");
> > > +        }
> > >      }
> > >      if (info->saved_state) {
> > >          /* This file descriptor is meant to be used by QEMU */
> > > diff -r 93658ca85035 -r 24f4a0a23da7 tools/libxl/libxl_types.idl
> > > --- a/tools/libxl/libxl_types.idl	Wed Dec 14 16:22:23 2011 +0100
> > > +++ b/tools/libxl/libxl_types.idl	Wed Dec 14 16:22:24 2011 +0100
> > > @@ -254,6 +254,7 @@ The password never expires"""),
> > >      ("extra",            libxl_string_list, False, "extra parameters
> > > pass directly to qemu, NULL terminated"), ("extra_pv",        
> > > libxl_string_list, False, "extra parameters pass directly to qemu for PV
> > > guest, NULL terminated"), ("extra_hvm",        libxl_string_list, False,
> > > "extra parameters pass directly to qemu for HVM guest, NULL terminated"),
> > > +    ("iommu",            bool,              False, "guest iommu enabled
> > > or disabled"), ],
> > >      comment=
> > >  """Device Model information.
> > > diff -r 93658ca85035 -r 24f4a0a23da7 tools/libxl/xl_cmdimpl.c
> > > --- a/tools/libxl/xl_cmdimpl.c	Wed Dec 14 16:22:23 2011 +0100
> > > +++ b/tools/libxl/xl_cmdimpl.c	Wed Dec 14 16:22:24 2011 +0100
> > > @@ -386,6 +386,7 @@ static void printf_info(int domid,
> > >          printf("\t\t\t(spicedisable_ticketing %d)\n",
> > >                      dm_info->spicedisable_ticketing);
> > >          printf("\t\t\t(spiceagent_mouse %d)\n",
> > > dm_info->spiceagent_mouse); +        printf("\t\t\t(iommu %d)\n",
> > > dm_info->iommu);
> > >          printf("\t\t)\n");
> > >          break;
> > >      case LIBXL_DOMAIN_TYPE_PV:
> > > @@ -1217,6 +1218,8 @@ skip_vfb:
> > >          xlu_cfg_replace_string (config, "soundhw", &dm_info->soundhw,
> > > 0); if (!xlu_cfg_get_long (config, "xen_platform_pci", &l, 0))
> > > dm_info->xen_platform_pci = l;
> > > +        if (!xlu_cfg_get_long (config, "iommu", &l, 0))
> > > +            dm_info->iommu = l;
> >
> > Didn't you already parse this same key into the build_info? Is there
> > ever a possibility of the dm_info and build_info versions of this field
> > differing?
> 
> > Assuming not I think this setting ought to only live in one place and I
> > think build_info should be that place rather than the dm info. That
> > might need some refactoring in libxl to pass the right struct down.
> 
> Yes, I added a new flag in build_info, which will control hvmloader to build 
> IVRS table. And I also need a flag for qemu-dm to decide if virtual iommu 
> device should be registered or not.  I just saw other parameters like 
> gfx-passthu are attached to dm_info, so I do the same thing for iommu. 

gfx-passthru is only in dm_info

> Also I cannot make a reference of libxl_domain_build_info in 
> libxl__build_device_model_args.

You just need to plumb the variable through. This is apparently just the
first time we have need of it.

> > Also you have only CC'd the hypervisor maintainers on this (and the
> > other?) tool stack patch. Please check MAINTAINERS to see who ought to
> > be CC'd.
> Thanks, I cc'd them to Ian Jackson.
> 
> > Ian.
> 
> Wei
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 17:00:50 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 17:00:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbEfk-000829-Ah; Thu, 15 Dec 2011 17:00:44 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RbEfi-00081v-Kw
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 17:00:42 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1323968397!49183451!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjI2MA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17661 invoked from network); 15 Dec 2011 16:59:57 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 16:59:57 -0000
X-IronPort-AV: E=Sophos;i="4.71,357,1320624000"; 
   d="scan'208";a="9497673"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Dec 2011 17:00:41 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 15 Dec 2011 17:00:41 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RbEfh-0007Sn-4O; Thu, 15 Dec 2011 17:00:41 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RbEfh-0003Nt-3f;
	Thu, 15 Dec 2011 17:00:41 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20202.10169.101830.45527@mariner.uk.xensource.com>
Date: Thu, 15 Dec 2011 17:00:41 +0000
To: Ian Campbell <ian.campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <64e48ae2ef6760db221f.1323796155@cosworth.uk.xensource.com>
References: <64e48ae2ef6760db221f.1323796155@cosworth.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] libxl: improve error handling when
	saving	device model state
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("[Xen-devel] [PATCH] libxl: improve error handling when saving device model state"):
> libxl: improve error handling when saving device model state.
...
> +out_close_fd2:
>      close(fd2);
> +out_unlink:
>      unlink(filename);

This style of error handling is very prone to errors.

How about:

    int fd2 = -1;

    blah blah maybe goto out blah blah

    if (fd2 >= 0) close(fd2);

And always unlinking the filename is fine, surely ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 17:00:50 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 17:00:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbEfk-000829-Ah; Thu, 15 Dec 2011 17:00:44 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RbEfi-00081v-Kw
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 17:00:42 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1323968397!49183451!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjI2MA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17661 invoked from network); 15 Dec 2011 16:59:57 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 16:59:57 -0000
X-IronPort-AV: E=Sophos;i="4.71,357,1320624000"; 
   d="scan'208";a="9497673"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Dec 2011 17:00:41 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 15 Dec 2011 17:00:41 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RbEfh-0007Sn-4O; Thu, 15 Dec 2011 17:00:41 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RbEfh-0003Nt-3f;
	Thu, 15 Dec 2011 17:00:41 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20202.10169.101830.45527@mariner.uk.xensource.com>
Date: Thu, 15 Dec 2011 17:00:41 +0000
To: Ian Campbell <ian.campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <64e48ae2ef6760db221f.1323796155@cosworth.uk.xensource.com>
References: <64e48ae2ef6760db221f.1323796155@cosworth.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] libxl: improve error handling when
	saving	device model state
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("[Xen-devel] [PATCH] libxl: improve error handling when saving device model state"):
> libxl: improve error handling when saving device model state.
...
> +out_close_fd2:
>      close(fd2);
> +out_unlink:
>      unlink(filename);

This style of error handling is very prone to errors.

How about:

    int fd2 = -1;

    blah blah maybe goto out blah blah

    if (fd2 >= 0) close(fd2);

And always unlinking the filename is fine, surely ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 17:05:24 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 17:05:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbEk5-0008KT-5G; Thu, 15 Dec 2011 17:05:13 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RbEk3-0008KJ-Kn
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 17:05:11 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1323968705!7639207!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjI2MA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10993 invoked from network); 15 Dec 2011 17:05:05 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 17:05:05 -0000
X-IronPort-AV: E=Sophos;i="4.71,357,1320624000"; 
   d="scan'208";a="9497770"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Dec 2011 17:05:04 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 15 Dec 2011 17:05:04 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RbEjw-0007UM-F2; Thu, 15 Dec 2011 17:05:04 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RbEjw-0003OS-DY;
	Thu, 15 Dec 2011 17:05:04 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20202.10428.248647.957239@mariner.uk.xensource.com>
Date: Thu, 15 Dec 2011 17:05:00 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1323796707.20077.346.camel@zakaz.uk.xensource.com>
References: <patchbomb.1323793468@cosworth.uk.xensource.com>
	<e0f020d3d812e00aeb0c.1323793470@cosworth.uk.xensource.com>
	<1323796265.20077.341.camel@zakaz.uk.xensource.com>
	<1323796707.20077.346.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 2 of 3] libxl: split libxl_domain_shutdown
 into libxl_domain_shutdown & libxl_domain_reboot
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("Re: [Xen-devel] [PATCH 2 of 3] libxl: split libxl_domain_shutdown into libxl_domain_shutdown & libxl_domain_reboot"):
> libxl: split libxl_domain_shutdown into libxl_domain_shutdown & libxl_domain_reboot
> 
> The other integer request types which shutdown supported are not useful. Specifically:
> 
>  * "suspend" is not usable via this interface since it requires other
>    scaffolding, libxl_domain_suspend provides this already.
>  * "halt" is the same as "poweroff".
>  * "crash" is unused and at least Linux does not implement it. If a user
>    steps forward then libxl_domain_crash is trivial to add.

The effect of this is to duplicate 25 lines of code.

If you really think we should split these into separate functions,
rather than just sorting out the faux-enum, the separate functions
probably want to turn out to be something like:

    int libxl_domain_reboot(libxl_ctx *ctx, uint32_t domid)
    {
        return libxl__domain_pvcontrol(ctx, domid, "reboot");
    }

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 17:05:24 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 17:05:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbEk5-0008KT-5G; Thu, 15 Dec 2011 17:05:13 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RbEk3-0008KJ-Kn
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 17:05:11 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1323968705!7639207!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjI2MA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10993 invoked from network); 15 Dec 2011 17:05:05 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 17:05:05 -0000
X-IronPort-AV: E=Sophos;i="4.71,357,1320624000"; 
   d="scan'208";a="9497770"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Dec 2011 17:05:04 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 15 Dec 2011 17:05:04 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RbEjw-0007UM-F2; Thu, 15 Dec 2011 17:05:04 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RbEjw-0003OS-DY;
	Thu, 15 Dec 2011 17:05:04 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20202.10428.248647.957239@mariner.uk.xensource.com>
Date: Thu, 15 Dec 2011 17:05:00 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1323796707.20077.346.camel@zakaz.uk.xensource.com>
References: <patchbomb.1323793468@cosworth.uk.xensource.com>
	<e0f020d3d812e00aeb0c.1323793470@cosworth.uk.xensource.com>
	<1323796265.20077.341.camel@zakaz.uk.xensource.com>
	<1323796707.20077.346.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 2 of 3] libxl: split libxl_domain_shutdown
 into libxl_domain_shutdown & libxl_domain_reboot
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("Re: [Xen-devel] [PATCH 2 of 3] libxl: split libxl_domain_shutdown into libxl_domain_shutdown & libxl_domain_reboot"):
> libxl: split libxl_domain_shutdown into libxl_domain_shutdown & libxl_domain_reboot
> 
> The other integer request types which shutdown supported are not useful. Specifically:
> 
>  * "suspend" is not usable via this interface since it requires other
>    scaffolding, libxl_domain_suspend provides this already.
>  * "halt" is the same as "poweroff".
>  * "crash" is unused and at least Linux does not implement it. If a user
>    steps forward then libxl_domain_crash is trivial to add.

The effect of this is to duplicate 25 lines of code.

If you really think we should split these into separate functions,
rather than just sorting out the faux-enum, the separate functions
probably want to turn out to be something like:

    int libxl_domain_reboot(libxl_ctx *ctx, uint32_t domid)
    {
        return libxl__domain_pvcontrol(ctx, domid, "reboot");
    }

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 17:07:51 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 17:07:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbEmU-0008TQ-NI; Thu, 15 Dec 2011 17:07:42 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RbEmS-0008Sb-Tl
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 17:07:41 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1323968854!7432375!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjI2MA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32029 invoked from network); 15 Dec 2011 17:07:34 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 17:07:34 -0000
X-IronPort-AV: E=Sophos;i="4.71,357,1320624000"; 
   d="scan'208";a="9497823"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Dec 2011 17:07:34 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 15 Dec 2011 17:07:34 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Bastian Blank <bastian@waldi.eu.org>
Date: Thu, 15 Dec 2011 17:07:34 +0000
In-Reply-To: <20111215104119.GC18042@wavehammer.waldi.eu.org>
References: <20111215104119.GC18042@wavehammer.waldi.eu.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323968854.20077.507.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 1/2] xenstored: Use xenbus_backend device on
 Linux
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2011-12-15 at 10:41 +0000, Bastian Blank wrote:
> xenstored: Use xenbus_backend device on Linux
> 
> This patch is done on top of 4.1 for now. The kernel part is already
> merged.

It compiles and builds on unstable too. I didn't try it but since this
stuff rarely changes I don't see why it wouldn't work just as well there
too.

> diff -r 1c89f7d29fbb tools/xenstore/xenstored_linux.c
> --- a/tools/xenstore/xenstored_linux.c	Thu Dec 08 16:50:28 2011 +0000
> +++ b/tools/xenstore/xenstored_linux.c	Sat Dec 10 19:38:54 2011 +0100

We need to make a similar change to
tools/ocaml/xenstored/domains.ml:create0 which is tricky since you can't
make an ioctl call from pure ocaml so a C binding is needed.

However we already have a low-level library (libxenctrl) which abstracts
these sorts of low level differences across platforms and which has
existing language bindings so reimplementing this stuff multiple times
in multiple languages seems a bit sub-optimal when we could just write
it once and extend the language bindings to cover the new functionality.

The following doesn't implement non-Linux or the ocaml side yet but it
gives the gist of what I'm thinking.

Ian.

diff -r 0c92f4561443 tools/libxc/xc_linux_osdep.c
--- a/tools/libxc/xc_linux_osdep.c	Thu Dec 15 10:41:58 2011 +0000
+++ b/tools/libxc/xc_linux_osdep.c	Thu Dec 15 17:04:57 2011 +0000
@@ -35,6 +35,7 @@
 #include <xen/sys/evtchn.h>
 #include <xen/sys/gntdev.h>
 #include <xen/sys/gntalloc.h>
+#include <xen/sys/xenbus_dev.h>
 
 #include "xenctrl.h"
 #include "xenctrlosdep.h"
@@ -43,6 +44,10 @@
 #define PERROR(_m, _a...) xc_osdep_log(xch,XTL_ERROR,XC_INTERNAL_ERROR,_m \
                   " (%d = %s)", ## _a , errno, xc_strerror(xch, errno))
 
+#define XENSTORED_DEV "/dev/xen/xenbus_backend"
+#define XENSTORED_PROC_KVA  "/proc/xen/xsd_kva"
+#define XENSTORED_PROC_PORT "/proc/xen/xsd_port"
+
 static xc_osdep_handle linux_privcmd_open(xc_interface *xch)
 {
     int flags, saved_errno;
@@ -367,6 +372,77 @@ static void *linux_privcmd_map_foreign_r
     return ret;
 }
 
+static evtchn_port_t xenbus_proc_evtchn(void)
+{
+        int fd;
+        int rc;
+        evtchn_port_t port;
+        char str[20];
+
+        fd = open(XENSTORED_PROC_PORT, O_RDONLY);
+        if (fd == -1)
+                return -1;
+
+        rc = read(fd, str, sizeof(str));
+        if (rc == -1)
+        {
+                int err = errno;
+                close(fd);
+                errno = err;
+                return -1;
+        }
+
+        str[rc] = '\0';
+        port = strtoul(str, NULL, 0);
+
+        close(fd);
+        return port;
+}
+
+static int linux_xenbus_backend_interface(xc_interface *xch, xc_osdep_handle h, void **map, evtchn_port_t *port)
+{
+    int ret, fd;
+    void *addr;
+
+    fd = open(XENSTORED_DEV, O_RDWR);
+    if (fd == -1)
+    {
+        if ( errno != ENOENT )
+            return -1;
+
+        /* Try /proc interface */
+        ret = xenbus_proc_evtchn();
+        if ( ret < 0 )
+            return -1;
+
+        *port = ret;
+
+        fd = open(XENSTORED_PROC_KVA, O_RDWR);
+        if ( fd == -1 )
+            return -1;
+    } else {
+        ret = ioctl(fd, IOCTL_XENBUS_BACKEND_EVTCHN);
+        if ( ret < 0 )
+        {
+            close(fd);
+            return -1;
+        }
+        *port = ret;
+    }
+
+    addr = mmap(NULL, getpagesize(), PROT_READ|PROT_WRITE,
+                MAP_SHARED, fd, 0);
+    if ( addr == MAP_FAILED )
+    {
+        close(fd);
+        return -1;
+    }
+
+    *map = addr;
+    close(fd);
+    return 0;
+}
+
 static struct xc_osdep_ops linux_privcmd_ops = {
     .open = &linux_privcmd_open,
     .close = &linux_privcmd_close,
@@ -381,6 +457,7 @@ static struct xc_osdep_ops linux_privcmd
         .map_foreign_bulk = &linux_privcmd_map_foreign_bulk,
         .map_foreign_range = &linux_privcmd_map_foreign_range,
         .map_foreign_ranges = &linux_privcmd_map_foreign_ranges,
+        .xenbus_backend_interface = &linux_xenbus_backend_interface,
     },
 };
 
diff -r 0c92f4561443 tools/libxc/xc_misc.c
--- a/tools/libxc/xc_misc.c	Thu Dec 15 10:41:58 2011 +0000
+++ b/tools/libxc/xc_misc.c	Thu Dec 15 17:04:57 2011 +0000
@@ -633,6 +633,14 @@ int xc_hvm_inject_trap(
     return rc;
 }
 
+int xc_xenbus_backend_interface(xc_interface *xch, void **map, evtchn_port_t *port)
+{
+    if ( xch->ops->u.privcmd.xenbus_backend_interface )
+        return xch->ops->u.privcmd.xenbus_backend_interface
+            (xch, xch->ops_handle, map, port);
+    return -ENOSYS;
+}
+
 /*
  * Local variables:
  * mode: C
diff -r 0c92f4561443 tools/libxc/xenctrl.h
--- a/tools/libxc/xenctrl.h	Thu Dec 15 10:41:58 2011 +0000
+++ b/tools/libxc/xenctrl.h	Thu Dec 15 17:04:57 2011 +0000
@@ -324,6 +324,11 @@ int xc_get_cpumap_size(xc_interface *xch
 xc_cpumap_t xc_cpumap_alloc(xc_interface *xch);
 
 /*
+ * Xenbus backend
+ */
+int xc_xenbus_backend_interface(xc_interface *xch, void **map, evtchn_port_t *port);
+
+/*
  * DOMAIN DEBUGGING FUNCTIONS
  */
 
diff -r 0c92f4561443 tools/libxc/xenctrlosdep.h
--- a/tools/libxc/xenctrlosdep.h	Thu Dec 15 10:41:58 2011 +0000
+++ b/tools/libxc/xenctrlosdep.h	Thu Dec 15 17:04:57 2011 +0000
@@ -89,6 +89,7 @@ struct xc_osdep_ops
             void *(*map_foreign_ranges)(xc_interface *xch, xc_osdep_handle h, uint32_t dom, size_t size, int prot,
                                         size_t chunksize, privcmd_mmap_entry_t entries[],
                                         int nentries);
+            int (*xenbus_backend_interface)(xc_interface *xch, xc_osdep_handle h, void **map, evtchn_port_t *port);
         } privcmd;
         struct {
             int (*fd)(xc_evtchn *xce, xc_osdep_handle h);
diff -r 0c92f4561443 tools/xenstore/xenstored_domain.c
--- a/tools/xenstore/xenstored_domain.c	Thu Dec 15 10:41:58 2011 +0000
+++ b/tools/xenstore/xenstored_domain.c	Thu Dec 15 17:04:57 2011 +0000
@@ -565,23 +565,20 @@ void restore_existing_connections(void)
 {
 }
 
-static int dom0_init(void) 
+static int dom0_init(xc_interface *xch) 
 { 
 	evtchn_port_t port;
+	void *intf;
 	struct domain *dom0;
 
-	port = xenbus_evtchn();
-	if (port == -1)
+	if (xc_xenbus_backend_interface(xch, &intf, &port) < 0)
 		return -1;
 
 	dom0 = new_domain(NULL, 0, port); 
 	if (dom0 == NULL)
 		return -1;
 
-	dom0->interface = xenbus_map();
-	if (dom0->interface == NULL)
-		return -1;
-
+	dom0->interface = intf;
 	talloc_steal(dom0->conn, dom0); 
 
 	xc_evtchn_notify(xce_handle, dom0->port); 
@@ -608,7 +605,7 @@ void domain_init(void)
 	if (xce_handle == NULL)
 		barf_perror("Failed to open evtchn device");
 
-	if (dom0_init() != 0) 
+	if (dom0_init(*xc_handle) != 0) 
 		barf_perror("Failed to initialize dom0 state"); 
 
 	if ((rc = xc_evtchn_bind_virq(xce_handle, VIRQ_DOM_EXC)) == -1)
diff -r 0c92f4561443 tools/xenstore/xenstored_linux.c
--- a/tools/xenstore/xenstored_linux.c	Thu Dec 15 10:41:58 2011 +0000
+++ b/tools/xenstore/xenstored_linux.c	Thu Dec 15 17:04:57 2011 +0000
@@ -18,84 +18,8 @@
 #include <sys/ioctl.h>
 #include <sys/mman.h>
 
-#include <xen/sys/xenbus_dev.h>
-
 #include "xenstored_core.h"
 
-#define XENSTORED_DEV "/dev/xen/xenbus_backend"
-#define XENSTORED_PROC_KVA  "/proc/xen/xsd_kva"
-#define XENSTORED_PROC_PORT "/proc/xen/xsd_port"
-
-static evtchn_port_t xenbus_proc_evtchn(void)
-{
-	int fd;
-	int rc;
-	evtchn_port_t port; 
-	char str[20]; 
-
-	fd = open(XENSTORED_PROC_PORT, O_RDONLY); 
-	if (fd == -1)
-		return -1;
-
-	rc = read(fd, str, sizeof(str)); 
-	if (rc == -1)
-	{
-		int err = errno;
-		close(fd);
-		errno = err;
-		return -1;
-	}
-
-	str[rc] = '\0'; 
-	port = strtoul(str, NULL, 0); 
-
-	close(fd); 
-	return port;
-}
-
-evtchn_port_t xenbus_evtchn(void)
-{
-	int fd;
-	long ret;
-
-	fd = open(XENSTORED_DEV, O_RDONLY);
-	if (fd == -1)
-	{
-		if (errno == ENOENT)
-			return xenbus_proc_evtchn();
-		return -1;
-	}
-
-	ret = ioctl(fd, IOCTL_XENBUS_BACKEND_EVTCHN);
-	if (ret == -1)
-		return -1;
-
-	close(fd); 
-	return ret;
-}
-
-void *xenbus_map(void)
-{
-	int fd;
-	void *addr;
-
-	fd = open(XENSTORED_DEV, O_RDWR);
-	if (fd == -1 && errno == ENOENT)
-		fd = open(XENSTORED_PROC_KVA, O_RDWR);
-	if (fd == -1)
-		return NULL;
-
-	addr = mmap(NULL, getpagesize(), PROT_READ|PROT_WRITE,
-		MAP_SHARED, fd, 0);
-
-	if (addr == MAP_FAILED)
-		addr = NULL;
-
-	close(fd);
-
-	return addr;
-}
-
 void xenbus_notify_running(void)
 {
 }



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 17:07:51 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 17:07:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbEmU-0008TQ-NI; Thu, 15 Dec 2011 17:07:42 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RbEmS-0008Sb-Tl
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 17:07:41 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1323968854!7432375!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjI2MA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32029 invoked from network); 15 Dec 2011 17:07:34 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 17:07:34 -0000
X-IronPort-AV: E=Sophos;i="4.71,357,1320624000"; 
   d="scan'208";a="9497823"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Dec 2011 17:07:34 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 15 Dec 2011 17:07:34 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Bastian Blank <bastian@waldi.eu.org>
Date: Thu, 15 Dec 2011 17:07:34 +0000
In-Reply-To: <20111215104119.GC18042@wavehammer.waldi.eu.org>
References: <20111215104119.GC18042@wavehammer.waldi.eu.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323968854.20077.507.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 1/2] xenstored: Use xenbus_backend device on
 Linux
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2011-12-15 at 10:41 +0000, Bastian Blank wrote:
> xenstored: Use xenbus_backend device on Linux
> 
> This patch is done on top of 4.1 for now. The kernel part is already
> merged.

It compiles and builds on unstable too. I didn't try it but since this
stuff rarely changes I don't see why it wouldn't work just as well there
too.

> diff -r 1c89f7d29fbb tools/xenstore/xenstored_linux.c
> --- a/tools/xenstore/xenstored_linux.c	Thu Dec 08 16:50:28 2011 +0000
> +++ b/tools/xenstore/xenstored_linux.c	Sat Dec 10 19:38:54 2011 +0100

We need to make a similar change to
tools/ocaml/xenstored/domains.ml:create0 which is tricky since you can't
make an ioctl call from pure ocaml so a C binding is needed.

However we already have a low-level library (libxenctrl) which abstracts
these sorts of low level differences across platforms and which has
existing language bindings so reimplementing this stuff multiple times
in multiple languages seems a bit sub-optimal when we could just write
it once and extend the language bindings to cover the new functionality.

The following doesn't implement non-Linux or the ocaml side yet but it
gives the gist of what I'm thinking.

Ian.

diff -r 0c92f4561443 tools/libxc/xc_linux_osdep.c
--- a/tools/libxc/xc_linux_osdep.c	Thu Dec 15 10:41:58 2011 +0000
+++ b/tools/libxc/xc_linux_osdep.c	Thu Dec 15 17:04:57 2011 +0000
@@ -35,6 +35,7 @@
 #include <xen/sys/evtchn.h>
 #include <xen/sys/gntdev.h>
 #include <xen/sys/gntalloc.h>
+#include <xen/sys/xenbus_dev.h>
 
 #include "xenctrl.h"
 #include "xenctrlosdep.h"
@@ -43,6 +44,10 @@
 #define PERROR(_m, _a...) xc_osdep_log(xch,XTL_ERROR,XC_INTERNAL_ERROR,_m \
                   " (%d = %s)", ## _a , errno, xc_strerror(xch, errno))
 
+#define XENSTORED_DEV "/dev/xen/xenbus_backend"
+#define XENSTORED_PROC_KVA  "/proc/xen/xsd_kva"
+#define XENSTORED_PROC_PORT "/proc/xen/xsd_port"
+
 static xc_osdep_handle linux_privcmd_open(xc_interface *xch)
 {
     int flags, saved_errno;
@@ -367,6 +372,77 @@ static void *linux_privcmd_map_foreign_r
     return ret;
 }
 
+static evtchn_port_t xenbus_proc_evtchn(void)
+{
+        int fd;
+        int rc;
+        evtchn_port_t port;
+        char str[20];
+
+        fd = open(XENSTORED_PROC_PORT, O_RDONLY);
+        if (fd == -1)
+                return -1;
+
+        rc = read(fd, str, sizeof(str));
+        if (rc == -1)
+        {
+                int err = errno;
+                close(fd);
+                errno = err;
+                return -1;
+        }
+
+        str[rc] = '\0';
+        port = strtoul(str, NULL, 0);
+
+        close(fd);
+        return port;
+}
+
+static int linux_xenbus_backend_interface(xc_interface *xch, xc_osdep_handle h, void **map, evtchn_port_t *port)
+{
+    int ret, fd;
+    void *addr;
+
+    fd = open(XENSTORED_DEV, O_RDWR);
+    if (fd == -1)
+    {
+        if ( errno != ENOENT )
+            return -1;
+
+        /* Try /proc interface */
+        ret = xenbus_proc_evtchn();
+        if ( ret < 0 )
+            return -1;
+
+        *port = ret;
+
+        fd = open(XENSTORED_PROC_KVA, O_RDWR);
+        if ( fd == -1 )
+            return -1;
+    } else {
+        ret = ioctl(fd, IOCTL_XENBUS_BACKEND_EVTCHN);
+        if ( ret < 0 )
+        {
+            close(fd);
+            return -1;
+        }
+        *port = ret;
+    }
+
+    addr = mmap(NULL, getpagesize(), PROT_READ|PROT_WRITE,
+                MAP_SHARED, fd, 0);
+    if ( addr == MAP_FAILED )
+    {
+        close(fd);
+        return -1;
+    }
+
+    *map = addr;
+    close(fd);
+    return 0;
+}
+
 static struct xc_osdep_ops linux_privcmd_ops = {
     .open = &linux_privcmd_open,
     .close = &linux_privcmd_close,
@@ -381,6 +457,7 @@ static struct xc_osdep_ops linux_privcmd
         .map_foreign_bulk = &linux_privcmd_map_foreign_bulk,
         .map_foreign_range = &linux_privcmd_map_foreign_range,
         .map_foreign_ranges = &linux_privcmd_map_foreign_ranges,
+        .xenbus_backend_interface = &linux_xenbus_backend_interface,
     },
 };
 
diff -r 0c92f4561443 tools/libxc/xc_misc.c
--- a/tools/libxc/xc_misc.c	Thu Dec 15 10:41:58 2011 +0000
+++ b/tools/libxc/xc_misc.c	Thu Dec 15 17:04:57 2011 +0000
@@ -633,6 +633,14 @@ int xc_hvm_inject_trap(
     return rc;
 }
 
+int xc_xenbus_backend_interface(xc_interface *xch, void **map, evtchn_port_t *port)
+{
+    if ( xch->ops->u.privcmd.xenbus_backend_interface )
+        return xch->ops->u.privcmd.xenbus_backend_interface
+            (xch, xch->ops_handle, map, port);
+    return -ENOSYS;
+}
+
 /*
  * Local variables:
  * mode: C
diff -r 0c92f4561443 tools/libxc/xenctrl.h
--- a/tools/libxc/xenctrl.h	Thu Dec 15 10:41:58 2011 +0000
+++ b/tools/libxc/xenctrl.h	Thu Dec 15 17:04:57 2011 +0000
@@ -324,6 +324,11 @@ int xc_get_cpumap_size(xc_interface *xch
 xc_cpumap_t xc_cpumap_alloc(xc_interface *xch);
 
 /*
+ * Xenbus backend
+ */
+int xc_xenbus_backend_interface(xc_interface *xch, void **map, evtchn_port_t *port);
+
+/*
  * DOMAIN DEBUGGING FUNCTIONS
  */
 
diff -r 0c92f4561443 tools/libxc/xenctrlosdep.h
--- a/tools/libxc/xenctrlosdep.h	Thu Dec 15 10:41:58 2011 +0000
+++ b/tools/libxc/xenctrlosdep.h	Thu Dec 15 17:04:57 2011 +0000
@@ -89,6 +89,7 @@ struct xc_osdep_ops
             void *(*map_foreign_ranges)(xc_interface *xch, xc_osdep_handle h, uint32_t dom, size_t size, int prot,
                                         size_t chunksize, privcmd_mmap_entry_t entries[],
                                         int nentries);
+            int (*xenbus_backend_interface)(xc_interface *xch, xc_osdep_handle h, void **map, evtchn_port_t *port);
         } privcmd;
         struct {
             int (*fd)(xc_evtchn *xce, xc_osdep_handle h);
diff -r 0c92f4561443 tools/xenstore/xenstored_domain.c
--- a/tools/xenstore/xenstored_domain.c	Thu Dec 15 10:41:58 2011 +0000
+++ b/tools/xenstore/xenstored_domain.c	Thu Dec 15 17:04:57 2011 +0000
@@ -565,23 +565,20 @@ void restore_existing_connections(void)
 {
 }
 
-static int dom0_init(void) 
+static int dom0_init(xc_interface *xch) 
 { 
 	evtchn_port_t port;
+	void *intf;
 	struct domain *dom0;
 
-	port = xenbus_evtchn();
-	if (port == -1)
+	if (xc_xenbus_backend_interface(xch, &intf, &port) < 0)
 		return -1;
 
 	dom0 = new_domain(NULL, 0, port); 
 	if (dom0 == NULL)
 		return -1;
 
-	dom0->interface = xenbus_map();
-	if (dom0->interface == NULL)
-		return -1;
-
+	dom0->interface = intf;
 	talloc_steal(dom0->conn, dom0); 
 
 	xc_evtchn_notify(xce_handle, dom0->port); 
@@ -608,7 +605,7 @@ void domain_init(void)
 	if (xce_handle == NULL)
 		barf_perror("Failed to open evtchn device");
 
-	if (dom0_init() != 0) 
+	if (dom0_init(*xc_handle) != 0) 
 		barf_perror("Failed to initialize dom0 state"); 
 
 	if ((rc = xc_evtchn_bind_virq(xce_handle, VIRQ_DOM_EXC)) == -1)
diff -r 0c92f4561443 tools/xenstore/xenstored_linux.c
--- a/tools/xenstore/xenstored_linux.c	Thu Dec 15 10:41:58 2011 +0000
+++ b/tools/xenstore/xenstored_linux.c	Thu Dec 15 17:04:57 2011 +0000
@@ -18,84 +18,8 @@
 #include <sys/ioctl.h>
 #include <sys/mman.h>
 
-#include <xen/sys/xenbus_dev.h>
-
 #include "xenstored_core.h"
 
-#define XENSTORED_DEV "/dev/xen/xenbus_backend"
-#define XENSTORED_PROC_KVA  "/proc/xen/xsd_kva"
-#define XENSTORED_PROC_PORT "/proc/xen/xsd_port"
-
-static evtchn_port_t xenbus_proc_evtchn(void)
-{
-	int fd;
-	int rc;
-	evtchn_port_t port; 
-	char str[20]; 
-
-	fd = open(XENSTORED_PROC_PORT, O_RDONLY); 
-	if (fd == -1)
-		return -1;
-
-	rc = read(fd, str, sizeof(str)); 
-	if (rc == -1)
-	{
-		int err = errno;
-		close(fd);
-		errno = err;
-		return -1;
-	}
-
-	str[rc] = '\0'; 
-	port = strtoul(str, NULL, 0); 
-
-	close(fd); 
-	return port;
-}
-
-evtchn_port_t xenbus_evtchn(void)
-{
-	int fd;
-	long ret;
-
-	fd = open(XENSTORED_DEV, O_RDONLY);
-	if (fd == -1)
-	{
-		if (errno == ENOENT)
-			return xenbus_proc_evtchn();
-		return -1;
-	}
-
-	ret = ioctl(fd, IOCTL_XENBUS_BACKEND_EVTCHN);
-	if (ret == -1)
-		return -1;
-
-	close(fd); 
-	return ret;
-}
-
-void *xenbus_map(void)
-{
-	int fd;
-	void *addr;
-
-	fd = open(XENSTORED_DEV, O_RDWR);
-	if (fd == -1 && errno == ENOENT)
-		fd = open(XENSTORED_PROC_KVA, O_RDWR);
-	if (fd == -1)
-		return NULL;
-
-	addr = mmap(NULL, getpagesize(), PROT_READ|PROT_WRITE,
-		MAP_SHARED, fd, 0);
-
-	if (addr == MAP_FAILED)
-		addr = NULL;
-
-	close(fd);
-
-	return addr;
-}
-
 void xenbus_notify_running(void)
 {
 }



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 17:08:01 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 17:08:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbEmf-0008VC-BP; Thu, 15 Dec 2011 17:07:53 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Wang2@amd.com>) id 1RbEmd-0008UG-NJ
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 17:07:52 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1323968864!7435855!1
X-Originating-IP: [216.32.181.186]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19835 invoked from network); 15 Dec 2011 17:07:45 -0000
Received: from ch1ehsobe006.messaging.microsoft.com (HELO
	ch1outboundpool.messaging.microsoft.com) (216.32.181.186)
	by server-6.tower-182.messagelabs.com with AES128-SHA encrypted SMTP;
	15 Dec 2011 17:07:45 -0000
Received: from mail182-ch1-R.bigfish.com (10.43.68.245) by
	CH1EHSOBE009.bigfish.com (10.43.70.59) with Microsoft SMTP Server id
	14.1.225.23; Thu, 15 Dec 2011 17:07:44 +0000
Received: from mail182-ch1 (localhost [127.0.0.1])	by
	mail182-ch1-R.bigfish.com (Postfix) with ESMTP id C7FAF5000DD;
	Thu, 15 Dec 2011 17:07:49 +0000 (UTC)
X-SpamScore: -16
X-BigFish: VPS-16(zz936eK1432N98dK4015Lzz1202hzz8275bhz2dh668h839h)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
X-FB-SS: 13,
Received: from mail182-ch1 (localhost.localdomain [127.0.0.1]) by mail182-ch1
	(MessageSwitch) id 1323968869489200_22246;
	Thu, 15 Dec 2011 17:07:49 +0000 (UTC)
Received: from CH1EHSMHS016.bigfish.com (snatpool1.int.messaging.microsoft.com
	[10.43.68.249])	by mail182-ch1.bigfish.com (Postfix) with ESMTP id
	66C7D580049;	Thu, 15 Dec 2011 17:07:49 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	CH1EHSMHS016.bigfish.com (10.43.70.16) with Microsoft SMTP Server id
	14.1.225.23; Thu, 15 Dec 2011 17:07:42 +0000
X-WSS-ID: 0LW98WQ-02-CL6-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp02.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 24576C8081;	Thu, 15 Dec 2011 11:07:37 -0600 (CST)
Received: from SAUSEXDAG03.amd.com (163.181.55.3) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Thu, 15 Dec 2011 11:07:54 -0600
Received: from storexhtp02.amd.com (172.24.4.4) by sausexdag03.amd.com
	(163.181.55.3) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Thu, 15 Dec 2011 11:07:38 -0600
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Thu, 15 Dec 2011
	12:07:37 -0500
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id B1E1B49C34C; Thu, 15 Dec 2011
	17:07:36 +0000 (GMT)
Received: from gran.osrc.amd.com (gran.osrc.amd.com [165.204.15.57])	by
	mail.osrc.amd.com (Postfix) with ESMTP id 9E6195940FF; Thu, 15 Dec 2011
	18:07:36 +0100 (CET)
From: Wei Wang2 <wei.wang2@amd.com>
To: <xen-devel@lists.xensource.com>
Date: Thu, 15 Dec 2011 18:10:19 +0100
User-Agent: KMail/1.9.6 (enterprise 20070904.708012)
References: <patchbomb.1323876561@gran.amd.com>
	<201112151552.09037.wei.wang2@amd.com>
	<1323968359.20077.501.camel@zakaz.uk.xensource.com>
In-Reply-To: <1323968359.20077.501.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
Message-ID: <201112151810.20262.wei.wang2@amd.com>
X-OriginatorOrg: amd.com
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, "Keir \(Xen.org\)" <keir@xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"JBeulich@suse.com" <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 16 of 16] libxl: add iommu parameter to
	qemu-dm
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thursday 15 December 2011 17:59:19 Ian Campbell wrote:
> On Thu, 2011-12-15 at 14:52 +0000, Wei Wang2 wrote:
> > On Thursday 15 December 2011 15:30:44 Ian Campbell wrote:
> > > On Wed, 2011-12-14 at 15:29 +0000, Wei Wang wrote:
> > > > # HG changeset patch
> > > > # User Wei Wang <wei.wang2@amd.com>
> > > > # Date 1323876144 -3600
> > > > # Node ID 24f4a0a23da71c58f457f0bf98aa8238dd45332d
> > > > # Parent  93658ca85035d6a4e56e2e6602c02859974d30a4
> > > > libxl: add iommu parameter to qemu-dm.
> > > > When iomm = 0, virtual iommu device will be disabled.
> > > >
> > > > Signed-off-by: Wei Wang <wei.wang2@amd.com>
> > > >
> > > > diff -r 93658ca85035 -r 24f4a0a23da7 tools/libxl/libxl_dm.c
> > > > --- a/tools/libxl/libxl_dm.c	Wed Dec 14 16:22:23 2011 +0100
> > > > +++ b/tools/libxl/libxl_dm.c	Wed Dec 14 16:22:24 2011 +0100
> > > > @@ -194,6 +194,9 @@ static char ** libxl__build_device_model
> > > >          if (info->gfx_passthru) {
> > > >              flexarray_append(dm_args, "-gfx_passthru");
> > > >          }
> > > > +        if (info->iommu) {
> > > > +            flexarray_append(dm_args, "-iommu");
> > > > +        }
> > > >      }
> > > >      if (info->saved_state) {
> > > >          flexarray_vappend(dm_args, "-loadvm", info->saved_state,
> > > > NULL); @@ -404,6 +407,9 @@ static char ** libxl__build_device_model
> > > > if (info->gfx_passthru) {
> > > >              flexarray_append(dm_args, "-gfx_passthru");
> > > >          }
> > > > +        if (info->iommu) {
> > > > +            flexarray_append(dm_args, "-iommu");
> > > > +        }
> > > >      }
> > > >      if (info->saved_state) {
> > > >          /* This file descriptor is meant to be used by QEMU */
> > > > diff -r 93658ca85035 -r 24f4a0a23da7 tools/libxl/libxl_types.idl
> > > > --- a/tools/libxl/libxl_types.idl	Wed Dec 14 16:22:23 2011 +0100
> > > > +++ b/tools/libxl/libxl_types.idl	Wed Dec 14 16:22:24 2011 +0100
> > > > @@ -254,6 +254,7 @@ The password never expires"""),
> > > >      ("extra",            libxl_string_list, False, "extra parameters
> > > > pass directly to qemu, NULL terminated"), ("extra_pv",
> > > > libxl_string_list, False, "extra parameters pass directly to qemu for
> > > > PV guest, NULL terminated"), ("extra_hvm",        libxl_string_list,
> > > > False, "extra parameters pass directly to qemu for HVM guest, NULL
> > > > terminated"), +    ("iommu",            bool,              False,
> > > > "guest iommu enabled or disabled"), ],
> > > >      comment=
> > > >  """Device Model information.
> > > > diff -r 93658ca85035 -r 24f4a0a23da7 tools/libxl/xl_cmdimpl.c
> > > > --- a/tools/libxl/xl_cmdimpl.c	Wed Dec 14 16:22:23 2011 +0100
> > > > +++ b/tools/libxl/xl_cmdimpl.c	Wed Dec 14 16:22:24 2011 +0100
> > > > @@ -386,6 +386,7 @@ static void printf_info(int domid,
> > > >          printf("\t\t\t(spicedisable_ticketing %d)\n",
> > > >                      dm_info->spicedisable_ticketing);
> > > >          printf("\t\t\t(spiceagent_mouse %d)\n",
> > > > dm_info->spiceagent_mouse); +        printf("\t\t\t(iommu %d)\n",
> > > > dm_info->iommu);
> > > >          printf("\t\t)\n");
> > > >          break;
> > > >      case LIBXL_DOMAIN_TYPE_PV:
> > > > @@ -1217,6 +1218,8 @@ skip_vfb:
> > > >          xlu_cfg_replace_string (config, "soundhw",
> > > > &dm_info->soundhw, 0); if (!xlu_cfg_get_long (config,
> > > > "xen_platform_pci", &l, 0)) dm_info->xen_platform_pci = l;
> > > > +        if (!xlu_cfg_get_long (config, "iommu", &l, 0))
> > > > +            dm_info->iommu = l;
> > >
> > > Didn't you already parse this same key into the build_info? Is there
> > > ever a possibility of the dm_info and build_info versions of this field
> > > differing?
> > >
> > > Assuming not I think this setting ought to only live in one place and I
> > > think build_info should be that place rather than the dm info. That
> > > might need some refactoring in libxl to pass the right struct down.
> >
> > Yes, I added a new flag in build_info, which will control hvmloader to
> > build IVRS table. And I also need a flag for qemu-dm to decide if virtual
> > iommu device should be registered or not.  I just saw other parameters
> > like gfx-passthu are attached to dm_info, so I do the same thing for
> > iommu.
>
> gfx-passthru is only in dm_info
>
> > Also I cannot make a reference of libxl_domain_build_info in
> > libxl__build_device_model_args.
>
> You just need to plumb the variable through. This is apparently just the
> first time we have need of it.
Ok, that sounds doable. I will fix that in the next version.
Thanks,
Wei

>
> > > Also you have only CC'd the hypervisor maintainers on this (and the
> > > other?) tool stack patch. Please check MAINTAINERS to see who ought to
> > > be CC'd.
> >
> > Thanks, I cc'd them to Ian Jackson.
> >
> > > Ian.
> >
> > Wei
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 17:08:01 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 17:08:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbEmf-0008VC-BP; Thu, 15 Dec 2011 17:07:53 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Wang2@amd.com>) id 1RbEmd-0008UG-NJ
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 17:07:52 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1323968864!7435855!1
X-Originating-IP: [216.32.181.186]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19835 invoked from network); 15 Dec 2011 17:07:45 -0000
Received: from ch1ehsobe006.messaging.microsoft.com (HELO
	ch1outboundpool.messaging.microsoft.com) (216.32.181.186)
	by server-6.tower-182.messagelabs.com with AES128-SHA encrypted SMTP;
	15 Dec 2011 17:07:45 -0000
Received: from mail182-ch1-R.bigfish.com (10.43.68.245) by
	CH1EHSOBE009.bigfish.com (10.43.70.59) with Microsoft SMTP Server id
	14.1.225.23; Thu, 15 Dec 2011 17:07:44 +0000
Received: from mail182-ch1 (localhost [127.0.0.1])	by
	mail182-ch1-R.bigfish.com (Postfix) with ESMTP id C7FAF5000DD;
	Thu, 15 Dec 2011 17:07:49 +0000 (UTC)
X-SpamScore: -16
X-BigFish: VPS-16(zz936eK1432N98dK4015Lzz1202hzz8275bhz2dh668h839h)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
X-FB-SS: 13,
Received: from mail182-ch1 (localhost.localdomain [127.0.0.1]) by mail182-ch1
	(MessageSwitch) id 1323968869489200_22246;
	Thu, 15 Dec 2011 17:07:49 +0000 (UTC)
Received: from CH1EHSMHS016.bigfish.com (snatpool1.int.messaging.microsoft.com
	[10.43.68.249])	by mail182-ch1.bigfish.com (Postfix) with ESMTP id
	66C7D580049;	Thu, 15 Dec 2011 17:07:49 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	CH1EHSMHS016.bigfish.com (10.43.70.16) with Microsoft SMTP Server id
	14.1.225.23; Thu, 15 Dec 2011 17:07:42 +0000
X-WSS-ID: 0LW98WQ-02-CL6-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp02.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 24576C8081;	Thu, 15 Dec 2011 11:07:37 -0600 (CST)
Received: from SAUSEXDAG03.amd.com (163.181.55.3) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Thu, 15 Dec 2011 11:07:54 -0600
Received: from storexhtp02.amd.com (172.24.4.4) by sausexdag03.amd.com
	(163.181.55.3) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Thu, 15 Dec 2011 11:07:38 -0600
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Thu, 15 Dec 2011
	12:07:37 -0500
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id B1E1B49C34C; Thu, 15 Dec 2011
	17:07:36 +0000 (GMT)
Received: from gran.osrc.amd.com (gran.osrc.amd.com [165.204.15.57])	by
	mail.osrc.amd.com (Postfix) with ESMTP id 9E6195940FF; Thu, 15 Dec 2011
	18:07:36 +0100 (CET)
From: Wei Wang2 <wei.wang2@amd.com>
To: <xen-devel@lists.xensource.com>
Date: Thu, 15 Dec 2011 18:10:19 +0100
User-Agent: KMail/1.9.6 (enterprise 20070904.708012)
References: <patchbomb.1323876561@gran.amd.com>
	<201112151552.09037.wei.wang2@amd.com>
	<1323968359.20077.501.camel@zakaz.uk.xensource.com>
In-Reply-To: <1323968359.20077.501.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
Message-ID: <201112151810.20262.wei.wang2@amd.com>
X-OriginatorOrg: amd.com
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, "Keir \(Xen.org\)" <keir@xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"JBeulich@suse.com" <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 16 of 16] libxl: add iommu parameter to
	qemu-dm
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thursday 15 December 2011 17:59:19 Ian Campbell wrote:
> On Thu, 2011-12-15 at 14:52 +0000, Wei Wang2 wrote:
> > On Thursday 15 December 2011 15:30:44 Ian Campbell wrote:
> > > On Wed, 2011-12-14 at 15:29 +0000, Wei Wang wrote:
> > > > # HG changeset patch
> > > > # User Wei Wang <wei.wang2@amd.com>
> > > > # Date 1323876144 -3600
> > > > # Node ID 24f4a0a23da71c58f457f0bf98aa8238dd45332d
> > > > # Parent  93658ca85035d6a4e56e2e6602c02859974d30a4
> > > > libxl: add iommu parameter to qemu-dm.
> > > > When iomm = 0, virtual iommu device will be disabled.
> > > >
> > > > Signed-off-by: Wei Wang <wei.wang2@amd.com>
> > > >
> > > > diff -r 93658ca85035 -r 24f4a0a23da7 tools/libxl/libxl_dm.c
> > > > --- a/tools/libxl/libxl_dm.c	Wed Dec 14 16:22:23 2011 +0100
> > > > +++ b/tools/libxl/libxl_dm.c	Wed Dec 14 16:22:24 2011 +0100
> > > > @@ -194,6 +194,9 @@ static char ** libxl__build_device_model
> > > >          if (info->gfx_passthru) {
> > > >              flexarray_append(dm_args, "-gfx_passthru");
> > > >          }
> > > > +        if (info->iommu) {
> > > > +            flexarray_append(dm_args, "-iommu");
> > > > +        }
> > > >      }
> > > >      if (info->saved_state) {
> > > >          flexarray_vappend(dm_args, "-loadvm", info->saved_state,
> > > > NULL); @@ -404,6 +407,9 @@ static char ** libxl__build_device_model
> > > > if (info->gfx_passthru) {
> > > >              flexarray_append(dm_args, "-gfx_passthru");
> > > >          }
> > > > +        if (info->iommu) {
> > > > +            flexarray_append(dm_args, "-iommu");
> > > > +        }
> > > >      }
> > > >      if (info->saved_state) {
> > > >          /* This file descriptor is meant to be used by QEMU */
> > > > diff -r 93658ca85035 -r 24f4a0a23da7 tools/libxl/libxl_types.idl
> > > > --- a/tools/libxl/libxl_types.idl	Wed Dec 14 16:22:23 2011 +0100
> > > > +++ b/tools/libxl/libxl_types.idl	Wed Dec 14 16:22:24 2011 +0100
> > > > @@ -254,6 +254,7 @@ The password never expires"""),
> > > >      ("extra",            libxl_string_list, False, "extra parameters
> > > > pass directly to qemu, NULL terminated"), ("extra_pv",
> > > > libxl_string_list, False, "extra parameters pass directly to qemu for
> > > > PV guest, NULL terminated"), ("extra_hvm",        libxl_string_list,
> > > > False, "extra parameters pass directly to qemu for HVM guest, NULL
> > > > terminated"), +    ("iommu",            bool,              False,
> > > > "guest iommu enabled or disabled"), ],
> > > >      comment=
> > > >  """Device Model information.
> > > > diff -r 93658ca85035 -r 24f4a0a23da7 tools/libxl/xl_cmdimpl.c
> > > > --- a/tools/libxl/xl_cmdimpl.c	Wed Dec 14 16:22:23 2011 +0100
> > > > +++ b/tools/libxl/xl_cmdimpl.c	Wed Dec 14 16:22:24 2011 +0100
> > > > @@ -386,6 +386,7 @@ static void printf_info(int domid,
> > > >          printf("\t\t\t(spicedisable_ticketing %d)\n",
> > > >                      dm_info->spicedisable_ticketing);
> > > >          printf("\t\t\t(spiceagent_mouse %d)\n",
> > > > dm_info->spiceagent_mouse); +        printf("\t\t\t(iommu %d)\n",
> > > > dm_info->iommu);
> > > >          printf("\t\t)\n");
> > > >          break;
> > > >      case LIBXL_DOMAIN_TYPE_PV:
> > > > @@ -1217,6 +1218,8 @@ skip_vfb:
> > > >          xlu_cfg_replace_string (config, "soundhw",
> > > > &dm_info->soundhw, 0); if (!xlu_cfg_get_long (config,
> > > > "xen_platform_pci", &l, 0)) dm_info->xen_platform_pci = l;
> > > > +        if (!xlu_cfg_get_long (config, "iommu", &l, 0))
> > > > +            dm_info->iommu = l;
> > >
> > > Didn't you already parse this same key into the build_info? Is there
> > > ever a possibility of the dm_info and build_info versions of this field
> > > differing?
> > >
> > > Assuming not I think this setting ought to only live in one place and I
> > > think build_info should be that place rather than the dm info. That
> > > might need some refactoring in libxl to pass the right struct down.
> >
> > Yes, I added a new flag in build_info, which will control hvmloader to
> > build IVRS table. And I also need a flag for qemu-dm to decide if virtual
> > iommu device should be registered or not.  I just saw other parameters
> > like gfx-passthu are attached to dm_info, so I do the same thing for
> > iommu.
>
> gfx-passthru is only in dm_info
>
> > Also I cannot make a reference of libxl_domain_build_info in
> > libxl__build_device_model_args.
>
> You just need to plumb the variable through. This is apparently just the
> first time we have need of it.
Ok, that sounds doable. I will fix that in the next version.
Thanks,
Wei

>
> > > Also you have only CC'd the hypervisor maintainers on this (and the
> > > other?) tool stack patch. Please check MAINTAINERS to see who ought to
> > > be CC'd.
> >
> > Thanks, I cc'd them to Ian Jackson.
> >
> > > Ian.
> >
> > Wei
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 17:12:54 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 17:12:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbErM-0000Qt-4X; Thu, 15 Dec 2011 17:12:44 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RbErK-0000Qj-I0
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 17:12:42 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1323969155!5727082!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjI2MA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30979 invoked from network); 15 Dec 2011 17:12:35 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 17:12:35 -0000
X-IronPort-AV: E=Sophos;i="4.71,357,1320624000"; 
   d="scan'208";a="9497927"
Received: from lonpmailmx02.citrite.net ([10.30.203.163])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Dec 2011 17:12:34 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.161]) by
	LONPMAILMX02.citrite.net ([10.30.203.163]) with mapi; Thu, 15 Dec 2011
	17:12:34 +0000
From: Paul Durrant <Paul.Durrant@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Thu, 15 Dec 2011 17:12:32 +0000
Thread-Topic: [Xen-devel] [PATCH 2 of 3] Re-name xenstore key used to save
	VM generation ID buffer address
Thread-Index: Acy7RiFBLBZIi5XgSsi1KvIrH1OxtwABf4UQ
Message-ID: <291EDFCB1E9E224A99088639C4762022B598ED0F0B@LONPMAILBOX01.citrite.net>
References: <patchbomb.1323873459@cosworth.uk.xensource.com>
	<9618ee3b6896eb8202e7.1323873461@cosworth.uk.xensource.com>
	<20202.8040.720939.17273@mariner.uk.xensource.com>
In-Reply-To: <20202.8040.720939.17273@mariner.uk.xensource.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 2 of 3] Re-name xenstore key used to save VM
 generation ID buffer address
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> -----Original Message-----
> From: Ian Jackson [mailto:Ian.Jackson@eu.citrix.com]
> Sent: 15 December 2011 16:25
> To: Paul Durrant
> Cc: xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] [PATCH 2 of 3] Re-name xenstore key used to
> save VM generation ID buffer address
> 
> Paul Durrant writes ("[Xen-devel] [PATCH 2 of 3] Re-name xenstore
> key used to save VM generation ID buffer address"):
> > Re-name xenstore key used to save VM generation ID buffer address.
> >
> > Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
> >
> > diff -r a4a569729741 -r 9618ee3b6896
> tools/firmware/hvmloader/acpi/build.c
> > --- a/tools/firmware/hvmloader/acpi/build.c	Wed Dec 14 14:34:45
> 2011 +0000
> > +++ b/tools/firmware/hvmloader/acpi/build.c	Wed Dec 14 14:34:47
> 2011 +0000
> > @@ -309,7 +309,7 @@ unsigned long new_vm_gid(void)
> >      if ( snprintf(addr, sizeof(addr), "0x%lx", virt_to_phys(buf))
> >           >= sizeof(addr) )
> >          return 0;
> > -    xenstore_write("data/generation-id", addr);
> > +    xenstore_write("hvmloader/generation-id-address", addr);
> 
> Will just making just this change to hvmloader not cause failures
> without the corresponding patch to the toolstack to make that path
> writeable ?
> 

The xenstore-write will fail with EACCES but the failure is ignored so there should be no knock-on failure. Nothing consumes the key until the subsequent tools patch is applied, at which point the xenstore-write will work because the tools will have made the key writable.

  Paul

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 17:12:54 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 17:12:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbErM-0000Qt-4X; Thu, 15 Dec 2011 17:12:44 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RbErK-0000Qj-I0
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 17:12:42 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1323969155!5727082!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjI2MA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30979 invoked from network); 15 Dec 2011 17:12:35 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 17:12:35 -0000
X-IronPort-AV: E=Sophos;i="4.71,357,1320624000"; 
   d="scan'208";a="9497927"
Received: from lonpmailmx02.citrite.net ([10.30.203.163])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Dec 2011 17:12:34 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.161]) by
	LONPMAILMX02.citrite.net ([10.30.203.163]) with mapi; Thu, 15 Dec 2011
	17:12:34 +0000
From: Paul Durrant <Paul.Durrant@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Thu, 15 Dec 2011 17:12:32 +0000
Thread-Topic: [Xen-devel] [PATCH 2 of 3] Re-name xenstore key used to save
	VM generation ID buffer address
Thread-Index: Acy7RiFBLBZIi5XgSsi1KvIrH1OxtwABf4UQ
Message-ID: <291EDFCB1E9E224A99088639C4762022B598ED0F0B@LONPMAILBOX01.citrite.net>
References: <patchbomb.1323873459@cosworth.uk.xensource.com>
	<9618ee3b6896eb8202e7.1323873461@cosworth.uk.xensource.com>
	<20202.8040.720939.17273@mariner.uk.xensource.com>
In-Reply-To: <20202.8040.720939.17273@mariner.uk.xensource.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 2 of 3] Re-name xenstore key used to save VM
 generation ID buffer address
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> -----Original Message-----
> From: Ian Jackson [mailto:Ian.Jackson@eu.citrix.com]
> Sent: 15 December 2011 16:25
> To: Paul Durrant
> Cc: xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] [PATCH 2 of 3] Re-name xenstore key used to
> save VM generation ID buffer address
> 
> Paul Durrant writes ("[Xen-devel] [PATCH 2 of 3] Re-name xenstore
> key used to save VM generation ID buffer address"):
> > Re-name xenstore key used to save VM generation ID buffer address.
> >
> > Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
> >
> > diff -r a4a569729741 -r 9618ee3b6896
> tools/firmware/hvmloader/acpi/build.c
> > --- a/tools/firmware/hvmloader/acpi/build.c	Wed Dec 14 14:34:45
> 2011 +0000
> > +++ b/tools/firmware/hvmloader/acpi/build.c	Wed Dec 14 14:34:47
> 2011 +0000
> > @@ -309,7 +309,7 @@ unsigned long new_vm_gid(void)
> >      if ( snprintf(addr, sizeof(addr), "0x%lx", virt_to_phys(buf))
> >           >= sizeof(addr) )
> >          return 0;
> > -    xenstore_write("data/generation-id", addr);
> > +    xenstore_write("hvmloader/generation-id-address", addr);
> 
> Will just making just this change to hvmloader not cause failures
> without the corresponding patch to the toolstack to make that path
> writeable ?
> 

The xenstore-write will fail with EACCES but the failure is ignored so there should be no knock-on failure. Nothing consumes the key until the subsequent tools patch is applied, at which point the xenstore-write will work because the tools will have made the key writable.

  Paul

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 17:14:14 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 17:14:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbEse-0000XN-KD; Thu, 15 Dec 2011 17:14:04 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RbEsc-0000Wq-Nk
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 17:14:03 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1323969233!5547101!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjE2NDg=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18823 invoked from network); 15 Dec 2011 17:13:55 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 17:13:55 -0000
X-IronPort-AV: E=Sophos;i="4.71,357,1320642000"; d="scan'208";a="174317837"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Dec 2011 12:13:51 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Thu, 15 Dec 2011 12:13:48 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pBFGSMtY003330;
	Thu, 15 Dec 2011 08:28:47 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Thu, 15 Dec 2011 16:30:42 +0000
Message-ID: <1323966657-19790-10-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1112131831560.3517@kaball-desktop>
References: <alpine.DEB.2.00.1112131831560.3517@kaball-desktop>
MIME-Version: 1.0
Cc: keir.xen@gmail.com, Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, JBeulich@suse.com,
	Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v3 10/25] arm: bit manipulation,
	copy and division libraries
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Bit manipulation, division and memcpy & friends implementations for the
ARM architecture, shamelessly taken from Linux.


Changes in v2:

- implement __aeabi_uldivmod and __aeabi_ldivmod.


Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
---
 xen/arch/arm/lib/Makefile        |    5 +
 xen/arch/arm/lib/assembler.h     |   49 ++++++
 xen/arch/arm/lib/bitops.h        |   36 +++++
 xen/arch/arm/lib/changebit.S     |   18 +++
 xen/arch/arm/lib/clearbit.S      |   19 +++
 xen/arch/arm/lib/copy_template.S |  266 +++++++++++++++++++++++++++++++++
 xen/arch/arm/lib/div64.S         |  149 +++++++++++++++++++
 xen/arch/arm/lib/findbit.S       |  115 +++++++++++++++
 xen/arch/arm/lib/lib1funcs.S     |  302 ++++++++++++++++++++++++++++++++++++++
 xen/arch/arm/lib/memcpy.S        |   64 ++++++++
 xen/arch/arm/lib/memmove.S       |  200 +++++++++++++++++++++++++
 xen/arch/arm/lib/memset.S        |  129 ++++++++++++++++
 xen/arch/arm/lib/memzero.S       |  127 ++++++++++++++++
 xen/arch/arm/lib/setbit.S        |   18 +++
 xen/arch/arm/lib/testchangebit.S |   18 +++
 xen/arch/arm/lib/testclearbit.S  |   18 +++
 xen/arch/arm/lib/testsetbit.S    |   18 +++
 17 files changed, 1551 insertions(+), 0 deletions(-)
 create mode 100644 xen/arch/arm/lib/Makefile
 create mode 100644 xen/arch/arm/lib/assembler.h
 create mode 100644 xen/arch/arm/lib/bitops.h
 create mode 100644 xen/arch/arm/lib/changebit.S
 create mode 100644 xen/arch/arm/lib/clearbit.S
 create mode 100644 xen/arch/arm/lib/copy_template.S
 create mode 100644 xen/arch/arm/lib/div64.S
 create mode 100644 xen/arch/arm/lib/findbit.S
 create mode 100644 xen/arch/arm/lib/lib1funcs.S
 create mode 100644 xen/arch/arm/lib/memcpy.S
 create mode 100644 xen/arch/arm/lib/memmove.S
 create mode 100644 xen/arch/arm/lib/memset.S
 create mode 100644 xen/arch/arm/lib/memzero.S
 create mode 100644 xen/arch/arm/lib/setbit.S
 create mode 100644 xen/arch/arm/lib/testchangebit.S
 create mode 100644 xen/arch/arm/lib/testclearbit.S
 create mode 100644 xen/arch/arm/lib/testsetbit.S

diff --git a/xen/arch/arm/lib/Makefile b/xen/arch/arm/lib/Makefile
new file mode 100644
index 0000000..cbbed68
--- /dev/null
+++ b/xen/arch/arm/lib/Makefile
@@ -0,0 +1,5 @@
+obj-y += memcpy.o memmove.o memset.o memzero.o
+obj-y += findbit.o setbit.o
+obj-y += setbit.o clearbit.o changebit.o
+obj-y += testsetbit.o testclearbit.o testchangebit.o
+obj-y += lib1funcs.o div64.o
diff --git a/xen/arch/arm/lib/assembler.h b/xen/arch/arm/lib/assembler.h
new file mode 100644
index 0000000..f8f0961
--- /dev/null
+++ b/xen/arch/arm/lib/assembler.h
@@ -0,0 +1,49 @@
+#ifndef __ARCH_ARM_LIB_ASSEMBLER_H__
+#define __ARCH_ARM_LIB_ASSEMBLER_H__
+
+/* From Linux arch/arm/include/asm/assembler.h */
+/*
+ * Data preload for architectures that support it
+ */
+#define PLD(code...)    code
+
+/*
+ * This can be used to enable code to cacheline align the destination
+ * pointer when bulk writing to memory.  Experiments on StrongARM and
+ * XScale didn't show this a worthwhile thing to do when the cache is not
+ * set to write-allocate (this would need further testing on XScale when WA
+ * is used).
+ *
+ * On Feroceon there is much to gain however, regardless of cache mode.
+ */
+#ifdef CONFIG_CPU_FEROCEON /* Not in Xen... */
+#define CALGN(code...) code
+#else
+#define CALGN(code...)
+#endif
+
+// No Thumb, hence:
+#define W(instr)        instr
+#define ARM(instr...)   instr
+#define THUMB(instr...)
+
+#ifdef CONFIG_ARM_UNWIND
+#define UNWIND(code...)         code
+#else
+#define UNWIND(code...)
+#endif
+
+#define pull            lsl
+#define push            lsr
+#define get_byte_0      lsr #24
+#define get_byte_1      lsr #16
+#define get_byte_2      lsr #8
+#define get_byte_3      lsl #0
+#define put_byte_0      lsl #24
+#define put_byte_1      lsl #16
+#define put_byte_2      lsl #8
+#define put_byte_3      lsl #0
+
+#define smp_dmb dmb
+
+#endif /*  __ARCH_ARM_LIB_ASSEMBLER_H__ */
diff --git a/xen/arch/arm/lib/bitops.h b/xen/arch/arm/lib/bitops.h
new file mode 100644
index 0000000..e56d4e8
--- /dev/null
+++ b/xen/arch/arm/lib/bitops.h
@@ -0,0 +1,36 @@
+	.macro	bitop, instr
+	ands	ip, r1, #3
+	strneb	r1, [ip]		@ assert word-aligned
+	mov	r2, #1
+	and	r3, r0, #31		@ Get bit offset
+	mov	r0, r0, lsr #5
+	add	r1, r1, r0, lsl #2	@ Get word offset
+	mov	r3, r2, lsl r3
+1:	ldrex	r2, [r1]
+	\instr	r2, r2, r3
+	strex	r0, r2, [r1]
+	cmp	r0, #0
+	bne	1b
+	bx	lr
+	.endm
+
+	.macro	testop, instr, store
+	ands	ip, r1, #3
+	strneb	r1, [ip]		@ assert word-aligned
+	mov	r2, #1
+	and	r3, r0, #31		@ Get bit offset
+	mov	r0, r0, lsr #5
+	add	r1, r1, r0, lsl #2	@ Get word offset
+	mov	r3, r2, lsl r3		@ create mask
+	smp_dmb
+1:	ldrex	r2, [r1]
+	ands	r0, r2, r3		@ save old value of bit
+	\instr	r2, r2, r3		@ toggle bit
+	strex	ip, r2, [r1]
+	cmp	ip, #0
+	bne	1b
+	smp_dmb
+	cmp	r0, #0
+	movne	r0, #1
+2:	bx	lr
+	.endm
diff --git a/xen/arch/arm/lib/changebit.S b/xen/arch/arm/lib/changebit.S
new file mode 100644
index 0000000..62954bc
--- /dev/null
+++ b/xen/arch/arm/lib/changebit.S
@@ -0,0 +1,18 @@
+/*
+ *  linux/arch/arm/lib/changebit.S
+ *
+ *  Copyright (C) 1995-1996 Russell King
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#include <xen/config.h>
+
+#include "assembler.h"
+#include "bitops.h"
+                .text
+
+ENTRY(_change_bit)
+	bitop	eor
+ENDPROC(_change_bit)
diff --git a/xen/arch/arm/lib/clearbit.S b/xen/arch/arm/lib/clearbit.S
new file mode 100644
index 0000000..42ce416
--- /dev/null
+++ b/xen/arch/arm/lib/clearbit.S
@@ -0,0 +1,19 @@
+/*
+ *  linux/arch/arm/lib/clearbit.S
+ *
+ *  Copyright (C) 1995-1996 Russell King
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <xen/config.h>
+
+#include "assembler.h"
+#include "bitops.h"
+                .text
+
+ENTRY(_clear_bit)
+	bitop	bic
+ENDPROC(_clear_bit)
diff --git a/xen/arch/arm/lib/copy_template.S b/xen/arch/arm/lib/copy_template.S
new file mode 100644
index 0000000..7f7f4d5
--- /dev/null
+++ b/xen/arch/arm/lib/copy_template.S
@@ -0,0 +1,266 @@
+/*
+ *  linux/arch/arm/lib/copy_template.s
+ *
+ *  Code template for optimized memory copy functions
+ *
+ *  Author:	Nicolas Pitre
+ *  Created:	Sep 28, 2005
+ *  Copyright:	MontaVista Software, Inc.
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License version 2 as
+ *  published by the Free Software Foundation.
+ */
+
+/*
+ * Theory of operation
+ * -------------------
+ *
+ * This file provides the core code for a forward memory copy used in
+ * the implementation of memcopy(), copy_to_user() and copy_from_user().
+ *
+ * The including file must define the following accessor macros
+ * according to the need of the given function:
+ *
+ * ldr1w ptr reg abort
+ *
+ *	This loads one word from 'ptr', stores it in 'reg' and increments
+ *	'ptr' to the next word. The 'abort' argument is used for fixup tables.
+ *
+ * ldr4w ptr reg1 reg2 reg3 reg4 abort
+ * ldr8w ptr, reg1 reg2 reg3 reg4 reg5 reg6 reg7 reg8 abort
+ *
+ *	This loads four or eight words starting from 'ptr', stores them
+ *	in provided registers and increments 'ptr' past those words.
+ *	The'abort' argument is used for fixup tables.
+ *
+ * ldr1b ptr reg cond abort
+ *
+ *	Similar to ldr1w, but it loads a byte and increments 'ptr' one byte.
+ *	It also must apply the condition code if provided, otherwise the
+ *	"al" condition is assumed by default.
+ *
+ * str1w ptr reg abort
+ * str8w ptr reg1 reg2 reg3 reg4 reg5 reg6 reg7 reg8 abort
+ * str1b ptr reg cond abort
+ *
+ *	Same as their ldr* counterparts, but data is stored to 'ptr' location
+ *	rather than being loaded.
+ *
+ * enter reg1 reg2
+ *
+ *	Preserve the provided registers on the stack plus any additional
+ *	data as needed by the implementation including this code. Called
+ *	upon code entry.
+ *
+ * exit reg1 reg2
+ *
+ *	Restore registers with the values previously saved with the
+ *	'preserv' macro. Called upon code termination.
+ *
+ * LDR1W_SHIFT
+ * STR1W_SHIFT
+ *
+ *	Correction to be applied to the "ip" register when branching into
+ *	the ldr1w or str1w instructions (some of these macros may expand to
+ *	than one 32bit instruction in Thumb-2)
+ */
+
+		enter	r4, lr
+
+		subs	r2, r2, #4
+		blt	8f
+		ands	ip, r0, #3
+	PLD(	pld	[r1, #0]		)
+		bne	9f
+		ands	ip, r1, #3
+		bne	10f
+
+1:		subs	r2, r2, #(28)
+		stmfd	sp!, {r5 - r8}
+		blt	5f
+
+	CALGN(	ands	ip, r0, #31		)
+	CALGN(	rsb	r3, ip, #32		)
+	CALGN(	sbcnes	r4, r3, r2		)  @ C is always set here
+	CALGN(	bcs	2f			)
+	CALGN(	adr	r4, 6f			)
+	CALGN(	subs	r2, r2, r3		)  @ C gets set
+	CALGN(	add	pc, r4, ip		)
+
+	PLD(	pld	[r1, #0]		)
+2:	PLD(	subs	r2, r2, #96		)
+	PLD(	pld	[r1, #28]		)
+	PLD(	blt	4f			)
+	PLD(	pld	[r1, #60]		)
+	PLD(	pld	[r1, #92]		)
+
+3:	PLD(	pld	[r1, #124]		)
+4:		ldr8w	r1, r3, r4, r5, r6, r7, r8, ip, lr, abort=20f
+		subs	r2, r2, #32
+		str8w	r0, r3, r4, r5, r6, r7, r8, ip, lr, abort=20f
+		bge	3b
+	PLD(	cmn	r2, #96			)
+	PLD(	bge	4b			)
+
+5:		ands	ip, r2, #28
+		rsb	ip, ip, #32
+#if LDR1W_SHIFT > 0
+		lsl	ip, ip, #LDR1W_SHIFT
+#endif
+		addne	pc, pc, ip		@ C is always clear here
+		b	7f
+6:
+		.rept	(1 << LDR1W_SHIFT)
+		W(nop)
+		.endr
+		ldr1w	r1, r3, abort=20f
+		ldr1w	r1, r4, abort=20f
+		ldr1w	r1, r5, abort=20f
+		ldr1w	r1, r6, abort=20f
+		ldr1w	r1, r7, abort=20f
+		ldr1w	r1, r8, abort=20f
+		ldr1w	r1, lr, abort=20f
+
+#if LDR1W_SHIFT < STR1W_SHIFT
+		lsl	ip, ip, #STR1W_SHIFT - LDR1W_SHIFT
+#elif LDR1W_SHIFT > STR1W_SHIFT
+		lsr	ip, ip, #LDR1W_SHIFT - STR1W_SHIFT
+#endif
+		add	pc, pc, ip
+		nop
+		.rept	(1 << STR1W_SHIFT)
+		W(nop)
+		.endr
+		str1w	r0, r3, abort=20f
+		str1w	r0, r4, abort=20f
+		str1w	r0, r5, abort=20f
+		str1w	r0, r6, abort=20f
+		str1w	r0, r7, abort=20f
+		str1w	r0, r8, abort=20f
+		str1w	r0, lr, abort=20f
+
+	CALGN(	bcs	2b			)
+
+7:		ldmfd	sp!, {r5 - r8}
+
+8:		movs	r2, r2, lsl #31
+		ldr1b	r1, r3, ne, abort=21f
+		ldr1b	r1, r4, cs, abort=21f
+		ldr1b	r1, ip, cs, abort=21f
+		str1b	r0, r3, ne, abort=21f
+		str1b	r0, r4, cs, abort=21f
+		str1b	r0, ip, cs, abort=21f
+
+		exit	r4, pc
+
+9:		rsb	ip, ip, #4
+		cmp	ip, #2
+		ldr1b	r1, r3, gt, abort=21f
+		ldr1b	r1, r4, ge, abort=21f
+		ldr1b	r1, lr, abort=21f
+		str1b	r0, r3, gt, abort=21f
+		str1b	r0, r4, ge, abort=21f
+		subs	r2, r2, ip
+		str1b	r0, lr, abort=21f
+		blt	8b
+		ands	ip, r1, #3
+		beq	1b
+
+10:		bic	r1, r1, #3
+		cmp	ip, #2
+		ldr1w	r1, lr, abort=21f
+		beq	17f
+		bgt	18f
+
+
+		.macro	forward_copy_shift pull push
+
+		subs	r2, r2, #28
+		blt	14f
+
+	CALGN(	ands	ip, r0, #31		)
+	CALGN(	rsb	ip, ip, #32		)
+	CALGN(	sbcnes	r4, ip, r2		)  @ C is always set here
+	CALGN(	subcc	r2, r2, ip		)
+	CALGN(	bcc	15f			)
+
+11:		stmfd	sp!, {r5 - r9}
+
+	PLD(	pld	[r1, #0]		)
+	PLD(	subs	r2, r2, #96		)
+	PLD(	pld	[r1, #28]		)
+	PLD(	blt	13f			)
+	PLD(	pld	[r1, #60]		)
+	PLD(	pld	[r1, #92]		)
+
+12:	PLD(	pld	[r1, #124]		)
+13:		ldr4w	r1, r4, r5, r6, r7, abort=19f
+		mov	r3, lr, pull #\pull
+		subs	r2, r2, #32
+		ldr4w	r1, r8, r9, ip, lr, abort=19f
+		orr	r3, r3, r4, push #\push
+		mov	r4, r4, pull #\pull
+		orr	r4, r4, r5, push #\push
+		mov	r5, r5, pull #\pull
+		orr	r5, r5, r6, push #\push
+		mov	r6, r6, pull #\pull
+		orr	r6, r6, r7, push #\push
+		mov	r7, r7, pull #\pull
+		orr	r7, r7, r8, push #\push
+		mov	r8, r8, pull #\pull
+		orr	r8, r8, r9, push #\push
+		mov	r9, r9, pull #\pull
+		orr	r9, r9, ip, push #\push
+		mov	ip, ip, pull #\pull
+		orr	ip, ip, lr, push #\push
+		str8w	r0, r3, r4, r5, r6, r7, r8, r9, ip, , abort=19f
+		bge	12b
+	PLD(	cmn	r2, #96			)
+	PLD(	bge	13b			)
+
+		ldmfd	sp!, {r5 - r9}
+
+14:		ands	ip, r2, #28
+		beq	16f
+
+15:		mov	r3, lr, pull #\pull
+		ldr1w	r1, lr, abort=21f
+		subs	ip, ip, #4
+		orr	r3, r3, lr, push #\push
+		str1w	r0, r3, abort=21f
+		bgt	15b
+	CALGN(	cmp	r2, #0			)
+	CALGN(	bge	11b			)
+
+16:		sub	r1, r1, #(\push / 8)
+		b	8b
+
+		.endm
+
+
+		forward_copy_shift	pull=8	push=24
+
+17:		forward_copy_shift	pull=16	push=16
+
+18:		forward_copy_shift	pull=24	push=8
+
+
+/*
+ * Abort preamble and completion macros.
+ * If a fixup handler is required then those macros must surround it.
+ * It is assumed that the fixup code will handle the private part of
+ * the exit macro.
+ */
+
+	.macro	copy_abort_preamble
+19:	ldmfd	sp!, {r5 - r9}
+	b	21f
+20:	ldmfd	sp!, {r5 - r8}
+21:
+	.endm
+
+	.macro	copy_abort_end
+	ldmfd	sp!, {r4, pc}
+	.endm
+
diff --git a/xen/arch/arm/lib/div64.S b/xen/arch/arm/lib/div64.S
new file mode 100644
index 0000000..2584772
--- /dev/null
+++ b/xen/arch/arm/lib/div64.S
@@ -0,0 +1,149 @@
+/*
+ *  linux/arch/arm/lib/div64.S
+ *
+ *  Optimized computation of 64-bit dividend / 32-bit divisor
+ *
+ *  Author:	Nicolas Pitre
+ *  Created:	Oct 5, 2003
+ *  Copyright:	Monta Vista Software, Inc.
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License version 2 as
+ *  published by the Free Software Foundation.
+ */
+
+#include <xen/config.h>
+#include "assembler.h"
+	
+#define xl r0
+#define xh r1
+#define yl r2
+#define yh r3
+
+/*
+ * __do_div64: perform a division with 64-bit dividend and 32-bit divisor.
+ *
+ * Note: Calling convention is totally non standard for optimal code.
+ *       This is meant to be used by do_div() from include/asm/div64.h only.
+ *
+ * Input parameters:
+ * 	xh-xl	= dividend (clobbered)
+ * 	r4	= divisor (preserved)
+ *
+ * Output values:
+ * 	yh-yl	= result
+ * 	xh	= remainder
+ *
+ * Clobbered regs: xl, ip
+ */
+
+ENTRY(__do_div64)
+
+	@ Test for easy paths first.
+	subs	ip, r4, #1
+	bls	9f			@ divisor is 0 or 1
+	tst	ip, r4
+	beq	8f			@ divisor is power of 2
+
+	@ See if we need to handle upper 32-bit result.
+	cmp	xh, r4
+	mov	yh, #0
+	blo	3f
+
+	@ Align divisor with upper part of dividend.
+	@ The aligned divisor is stored in yl preserving the original.
+	@ The bit position is stored in ip.
+
+	clz	yl, r4
+	clz	ip, xh
+	sub	yl, yl, ip
+	mov	ip, #1
+	mov	ip, ip, lsl yl
+	mov	yl, r4, lsl yl
+
+	@ The division loop for needed upper bit positions.
+ 	@ Break out early if dividend reaches 0.
+2:	cmp	xh, yl
+	orrcs	yh, yh, ip
+	subcss	xh, xh, yl
+	movnes	ip, ip, lsr #1
+	mov	yl, yl, lsr #1
+	bne	2b
+
+	@ See if we need to handle lower 32-bit result.
+3:	cmp	xh, #0
+	mov	yl, #0
+	cmpeq	xl, r4
+	movlo	xh, xl
+	movlo	pc, lr
+
+	@ The division loop for lower bit positions.
+	@ Here we shift remainer bits leftwards rather than moving the
+	@ divisor for comparisons, considering the carry-out bit as well.
+	mov	ip, #0x80000000
+4:	movs	xl, xl, lsl #1
+	adcs	xh, xh, xh
+	beq	6f
+	cmpcc	xh, r4
+5:	orrcs	yl, yl, ip
+	subcs	xh, xh, r4
+	movs	ip, ip, lsr #1
+	bne	4b
+	mov	pc, lr
+
+	@ The top part of remainder became zero.  If carry is set
+	@ (the 33th bit) this is a false positive so resume the loop.
+	@ Otherwise, if lower part is also null then we are done.
+6:	bcs	5b
+	cmp	xl, #0
+	moveq	pc, lr
+
+	@ We still have remainer bits in the low part.  Bring them up.
+
+	clz	xh, xl			@ we know xh is zero here so...
+	add	xh, xh, #1
+	mov	xl, xl, lsl xh
+	mov	ip, ip, lsr xh
+
+	@ Current remainder is now 1.  It is worthless to compare with
+	@ divisor at this point since divisor can not be smaller than 3 here.
+	@ If possible, branch for another shift in the division loop.
+	@ If no bit position left then we are done.
+	movs	ip, ip, lsr #1
+	mov	xh, #1
+	bne	4b
+	mov	pc, lr
+
+8:	@ Division by a power of 2: determine what that divisor order is
+	@ then simply shift values around
+
+	clz	ip, r4
+	rsb	ip, ip, #31
+
+	mov	yh, xh, lsr ip
+	mov	yl, xl, lsr ip
+	rsb	ip, ip, #32
+ ARM(	orr	yl, yl, xh, lsl ip	)
+ THUMB(	lsl	xh, xh, ip		)
+ THUMB(	orr	yl, yl, xh		)
+	mov	xh, xl, lsl ip
+	mov	xh, xh, lsr ip
+	mov	pc, lr
+
+	@ eq -> division by 1: obvious enough...
+9:	moveq	yl, xl
+	moveq	yh, xh
+	moveq	xh, #0
+	moveq	pc, lr
+
+	@ Division by 0:
+	str	lr, [sp, #-8]!
+	bl	__div0
+
+	@ as wrong as it could be...
+	mov	yl, #0
+	mov	yh, #0
+	mov	xh, #0
+	ldr	pc, [sp], #8
+
+ENDPROC(__do_div64)
diff --git a/xen/arch/arm/lib/findbit.S b/xen/arch/arm/lib/findbit.S
new file mode 100644
index 0000000..5669b91
--- /dev/null
+++ b/xen/arch/arm/lib/findbit.S
@@ -0,0 +1,115 @@
+/*
+ *  linux/arch/arm/lib/findbit.S
+ *
+ *  Copyright (C) 1995-2000 Russell King
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * 16th March 2001 - John Ripley <jripley@sonicblue.com>
+ *   Fixed so that "size" is an exclusive not an inclusive quantity.
+ *   All users of these functions expect exclusive sizes, and may
+ *   also call with zero size.
+ * Reworked by rmk.
+ */
+
+#include <xen/config.h>
+
+#include "assembler.h"
+                .text
+
+/*
+ * Purpose  : Find a 'zero' bit
+ * Prototype: int find_first_zero_bit(void *addr, unsigned int maxbit);
+ */
+ENTRY(_find_first_zero_bit)
+		teq	r1, #0	
+		beq	3f
+		mov	r2, #0
+1:
+ ARM(		ldrb	r3, [r0, r2, lsr #3]	)
+ THUMB(		lsr	r3, r2, #3		)
+ THUMB(		ldrb	r3, [r0, r3]		)
+		eors	r3, r3, #0xff		@ invert bits
+		bne	.L_found		@ any now set - found zero bit
+		add	r2, r2, #8		@ next bit pointer
+2:		cmp	r2, r1			@ any more?
+		blo	1b
+3:		mov	r0, r1			@ no free bits
+		mov	pc, lr
+ENDPROC(_find_first_zero_bit)
+
+/*
+ * Purpose  : Find next 'zero' bit
+ * Prototype: int find_next_zero_bit(void *addr, unsigned int maxbit, int offset)
+ */
+ENTRY(_find_next_zero_bit)
+		teq	r1, #0
+		beq	3b
+		ands	ip, r2, #7
+		beq	1b			@ If new byte, goto old routine
+ ARM(		ldrb	r3, [r0, r2, lsr #3]	)
+ THUMB(		lsr	r3, r2, #3		)
+ THUMB(		ldrb	r3, [r0, r3]		)
+		eor	r3, r3, #0xff		@ now looking for a 1 bit
+		movs	r3, r3, lsr ip		@ shift off unused bits
+		bne	.L_found
+		orr	r2, r2, #7		@ if zero, then no bits here
+		add	r2, r2, #1		@ align bit pointer
+		b	2b			@ loop for next bit
+ENDPROC(_find_next_zero_bit)
+
+/*
+ * Purpose  : Find a 'one' bit
+ * Prototype: int find_first_bit(const unsigned long *addr, unsigned int maxbit);
+ */
+ENTRY(_find_first_bit)
+		teq	r1, #0	
+		beq	3f
+		mov	r2, #0
+1:
+ ARM(		ldrb	r3, [r0, r2, lsr #3]	)
+ THUMB(		lsr	r3, r2, #3		)
+ THUMB(		ldrb	r3, [r0, r3]		)
+		movs	r3, r3
+		bne	.L_found		@ any now set - found zero bit
+		add	r2, r2, #8		@ next bit pointer
+2:		cmp	r2, r1			@ any more?
+		blo	1b
+3:		mov	r0, r1			@ no free bits
+		mov	pc, lr
+ENDPROC(_find_first_bit)
+
+/*
+ * Purpose  : Find next 'one' bit
+ * Prototype: int find_next_zero_bit(void *addr, unsigned int maxbit, int offset)
+ */
+ENTRY(_find_next_bit)
+		teq	r1, #0
+		beq	3b
+		ands	ip, r2, #7
+		beq	1b			@ If new byte, goto old routine
+ ARM(		ldrb	r3, [r0, r2, lsr #3]	)
+ THUMB(		lsr	r3, r2, #3		)
+ THUMB(		ldrb	r3, [r0, r3]		)
+		movs	r3, r3, lsr ip		@ shift off unused bits
+		bne	.L_found
+		orr	r2, r2, #7		@ if zero, then no bits here
+		add	r2, r2, #1		@ align bit pointer
+		b	2b			@ loop for next bit
+ENDPROC(_find_next_bit)
+
+/*
+ * One or more bits in the LSB of r3 are assumed to be set.
+ */
+.L_found:
+		rsb	r0, r3, #0
+		and	r3, r3, r0
+		clz	r3, r3
+		rsb	r3, r3, #31
+		add	r0, r2, r3
+		cmp	r1, r0			@ Clamp to maxbit
+		movlo	r0, r1
+		mov	pc, lr
+
diff --git a/xen/arch/arm/lib/lib1funcs.S b/xen/arch/arm/lib/lib1funcs.S
new file mode 100644
index 0000000..828e688
--- /dev/null
+++ b/xen/arch/arm/lib/lib1funcs.S
@@ -0,0 +1,302 @@
+/*
+ * linux/arch/arm/lib/lib1funcs.S: Optimized ARM division routines
+ *
+ * Author: Nicolas Pitre <nico@fluxnic.net>
+ *   - contributed to gcc-3.4 on Sep 30, 2003
+ *   - adapted for the Linux kernel on Oct 2, 2003
+ */
+
+/* Copyright 1995, 1996, 1998, 1999, 2000, 2003 Free Software Foundation, Inc.
+
+This file 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, or (at your option) any
+later version.
+
+In addition to the permissions in the GNU General Public License, the
+Free Software Foundation gives you unlimited permission to link the
+compiled version of this file into combinations with other programs,
+and to distribute those combinations without any restriction coming
+from the use of this file.  (The General Public License restrictions
+do apply in other respects; for example, they cover modification of
+the file, and distribution when not linked into a combine
+executable.)
+
+This file is distributed in the hope that it will be useful, but
+WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  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; see the file COPYING.  If not, write to
+the Free Software Foundation, 59 Temple Place - Suite 330,
+Boston, MA 02111-1307, USA.  */
+
+
+#include <xen/config.h>
+#include "assembler.h"
+
+.macro ARM_DIV_BODY dividend, divisor, result, curbit
+
+	clz	\curbit, \divisor
+	clz	\result, \dividend
+	sub	\result, \curbit, \result
+	mov	\curbit, #1
+	mov	\divisor, \divisor, lsl \result
+	mov	\curbit, \curbit, lsl \result
+	mov	\result, #0
+	
+	@ Division loop
+1:	cmp	\dividend, \divisor
+	subhs	\dividend, \dividend, \divisor
+	orrhs	\result,   \result,   \curbit
+	cmp	\dividend, \divisor,  lsr #1
+	subhs	\dividend, \dividend, \divisor, lsr #1
+	orrhs	\result,   \result,   \curbit,  lsr #1
+	cmp	\dividend, \divisor,  lsr #2
+	subhs	\dividend, \dividend, \divisor, lsr #2
+	orrhs	\result,   \result,   \curbit,  lsr #2
+	cmp	\dividend, \divisor,  lsr #3
+	subhs	\dividend, \dividend, \divisor, lsr #3
+	orrhs	\result,   \result,   \curbit,  lsr #3
+	cmp	\dividend, #0			@ Early termination?
+	movnes	\curbit,   \curbit,  lsr #4	@ No, any more bits to do?
+	movne	\divisor,  \divisor, lsr #4
+	bne	1b
+
+.endm
+
+
+.macro ARM_DIV2_ORDER divisor, order
+
+	clz	\order, \divisor
+	rsb	\order, \order, #31
+
+.endm
+
+
+.macro ARM_MOD_BODY dividend, divisor, order, spare
+
+	clz	\order, \divisor
+	clz	\spare, \dividend
+	sub	\order, \order, \spare
+	mov	\divisor, \divisor, lsl \order
+
+	@ Perform all needed substractions to keep only the reminder.
+	@ Do comparisons in batch of 4 first.
+	subs	\order, \order, #3		@ yes, 3 is intended here
+	blt	2f
+
+1:	cmp	\dividend, \divisor
+	subhs	\dividend, \dividend, \divisor
+	cmp	\dividend, \divisor,  lsr #1
+	subhs	\dividend, \dividend, \divisor, lsr #1
+	cmp	\dividend, \divisor,  lsr #2
+	subhs	\dividend, \dividend, \divisor, lsr #2
+	cmp	\dividend, \divisor,  lsr #3
+	subhs	\dividend, \dividend, \divisor, lsr #3
+	cmp	\dividend, #1
+	mov	\divisor, \divisor, lsr #4
+	subges	\order, \order, #4
+	bge	1b
+
+	tst	\order, #3
+	teqne	\dividend, #0
+	beq	5f
+
+	@ Either 1, 2 or 3 comparison/substractions are left.
+2:	cmn	\order, #2
+	blt	4f
+	beq	3f
+	cmp	\dividend, \divisor
+	subhs	\dividend, \dividend, \divisor
+	mov	\divisor,  \divisor,  lsr #1
+3:	cmp	\dividend, \divisor
+	subhs	\dividend, \dividend, \divisor
+	mov	\divisor,  \divisor,  lsr #1
+4:	cmp	\dividend, \divisor
+	subhs	\dividend, \dividend, \divisor
+5:
+.endm
+
+
+ENTRY(__udivsi3)
+ENTRY(__aeabi_uidiv)
+UNWIND(.fnstart)
+
+	subs	r2, r1, #1
+	moveq	pc, lr
+	bcc	Ldiv0
+	cmp	r0, r1
+	bls	11f
+	tst	r1, r2
+	beq	12f
+
+	ARM_DIV_BODY r0, r1, r2, r3
+
+	mov	r0, r2
+	mov	pc, lr
+
+11:	moveq	r0, #1
+	movne	r0, #0
+	mov	pc, lr
+
+12:	ARM_DIV2_ORDER r1, r2
+
+	mov	r0, r0, lsr r2
+	mov	pc, lr
+
+UNWIND(.fnend)
+ENDPROC(__udivsi3)
+ENDPROC(__aeabi_uidiv)
+
+ENTRY(__umodsi3)
+UNWIND(.fnstart)
+
+	subs	r2, r1, #1			@ compare divisor with 1
+	bcc	Ldiv0
+	cmpne	r0, r1				@ compare dividend with divisor
+	moveq   r0, #0
+	tsthi	r1, r2				@ see if divisor is power of 2
+	andeq	r0, r0, r2
+	movls	pc, lr
+
+	ARM_MOD_BODY r0, r1, r2, r3
+
+	mov	pc, lr
+
+UNWIND(.fnend)
+ENDPROC(__umodsi3)
+
+ENTRY(__divsi3)
+ENTRY(__aeabi_idiv)
+UNWIND(.fnstart)
+
+	cmp	r1, #0
+	eor	ip, r0, r1			@ save the sign of the result.
+	beq	Ldiv0
+	rsbmi	r1, r1, #0			@ loops below use unsigned.
+	subs	r2, r1, #1			@ division by 1 or -1 ?
+	beq	10f
+	movs	r3, r0
+	rsbmi	r3, r0, #0			@ positive dividend value
+	cmp	r3, r1
+	bls	11f
+	tst	r1, r2				@ divisor is power of 2 ?
+	beq	12f
+
+	ARM_DIV_BODY r3, r1, r0, r2
+
+	cmp	ip, #0
+	rsbmi	r0, r0, #0
+	mov	pc, lr
+
+10:	teq	ip, r0				@ same sign ?
+	rsbmi	r0, r0, #0
+	mov	pc, lr
+
+11:	movlo	r0, #0
+	moveq	r0, ip, asr #31
+	orreq	r0, r0, #1
+	mov	pc, lr
+
+12:	ARM_DIV2_ORDER r1, r2
+
+	cmp	ip, #0
+	mov	r0, r3, lsr r2
+	rsbmi	r0, r0, #0
+	mov	pc, lr
+
+UNWIND(.fnend)
+ENDPROC(__divsi3)
+ENDPROC(__aeabi_idiv)
+
+ENTRY(__modsi3)
+UNWIND(.fnstart)
+
+	cmp	r1, #0
+	beq	Ldiv0
+	rsbmi	r1, r1, #0			@ loops below use unsigned.
+	movs	ip, r0				@ preserve sign of dividend
+	rsbmi	r0, r0, #0			@ if negative make positive
+	subs	r2, r1, #1			@ compare divisor with 1
+	cmpne	r0, r1				@ compare dividend with divisor
+	moveq	r0, #0
+	tsthi	r1, r2				@ see if divisor is power of 2
+	andeq	r0, r0, r2
+	bls	10f
+
+	ARM_MOD_BODY r0, r1, r2, r3
+
+10:	cmp	ip, #0
+	rsbmi	r0, r0, #0
+	mov	pc, lr
+
+UNWIND(.fnend)
+ENDPROC(__modsi3)
+
+ENTRY(__aeabi_uidivmod)
+UNWIND(.fnstart)
+UNWIND(.save {r0, r1, ip, lr}	)
+
+	stmfd	sp!, {r0, r1, ip, lr}
+	bl	__aeabi_uidiv
+	ldmfd	sp!, {r1, r2, ip, lr}
+	mul	r3, r0, r2
+	sub	r1, r1, r3
+	mov	pc, lr
+
+UNWIND(.fnend)
+ENDPROC(__aeabi_uidivmod)
+
+ENTRY(__aeabi_idivmod)
+UNWIND(.fnstart)
+UNWIND(.save {r0, r1, ip, lr}	)
+	stmfd	sp!, {r0, r1, ip, lr}
+	bl	__aeabi_idiv
+	ldmfd	sp!, {r1, r2, ip, lr}
+	mul	r3, r0, r2
+	sub	r1, r1, r3
+	mov	pc, lr
+
+UNWIND(.fnend)
+ENDPROC(__aeabi_idivmod)
+
+ENTRY(__aeabi_uldivmod)
+UNWIND(.fnstart)
+UNWIND(.save {lr}	)
+	sub sp, sp, #8
+	stmfd   sp!, {sp, lr}
+	bl __qdivrem
+	ldr lr, [sp, #4]
+	add sp, sp, #8
+	ldmfd sp!, {r2, r3}
+	mov	pc, lr
+
+UNWIND(.fnend)
+ENDPROC(__aeabi_uldivmod)
+
+ENTRY(__aeabi_ldivmod)
+UNWIND(.fnstart)
+UNWIND(.save {lr}	)
+	sub sp, sp, #16
+	stmfd   sp!, {sp, lr}
+	bl __ldivmod_helper
+	ldr lr, [sp, #4]
+	add sp, sp, #16
+	ldmfd	sp!, {r2, r3}
+	mov	pc, lr
+	
+UNWIND(.fnend)
+ENDPROC(__aeabi_uldivmod)
+
+Ldiv0:
+UNWIND(.fnstart)
+UNWIND(.pad #4)
+UNWIND(.save {lr})
+	str	lr, [sp, #-8]!
+	bl	__div0
+	mov	r0, #0			@ About as wrong as it could be.
+	ldr	pc, [sp], #8
+UNWIND(.fnend)
+ENDPROC(Ldiv0)
diff --git a/xen/arch/arm/lib/memcpy.S b/xen/arch/arm/lib/memcpy.S
new file mode 100644
index 0000000..f4bad5c
--- /dev/null
+++ b/xen/arch/arm/lib/memcpy.S
@@ -0,0 +1,64 @@
+/*
+ *  linux/arch/arm/lib/memcpy.S
+ *
+ *  Author:     Nicolas Pitre
+ *  Created:    Sep 28, 2005
+ *  Copyright:  MontaVista Software, Inc.
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License version 2 as
+ *  published by the Free Software Foundation.
+ */
+
+#include <xen/config.h>
+
+#include "assembler.h"
+
+#define LDR1W_SHIFT     0
+#define STR1W_SHIFT     0
+
+        .macro ldr1w ptr reg abort
+        W(ldr) \reg, [\ptr], #4
+        .endm
+
+        .macro ldr4w ptr reg1 reg2 reg3 reg4 abort
+        ldmia \ptr!, {\reg1, \reg2, \reg3, \reg4}
+        .endm
+
+        .macro ldr8w ptr reg1 reg2 reg3 reg4 reg5 reg6 reg7 reg8 abort
+        ldmia \ptr!, {\reg1, \reg2, \reg3, \reg4, \reg5, \reg6, \reg7, \reg8}
+        .endm
+
+        .macro ldr1b ptr reg cond=al abort
+        ldr\cond\()b \reg, [\ptr], #1
+        .endm
+
+        .macro str1w ptr reg abort
+        W(str) \reg, [\ptr], #4
+        .endm
+
+        .macro str8w ptr reg1 reg2 reg3 reg4 reg5 reg6 reg7 reg8 abort
+        stmia \ptr!, {\reg1, \reg2, \reg3, \reg4, \reg5, \reg6, \reg7, \reg8}
+        .endm
+
+        .macro str1b ptr reg cond=al abort
+        str\cond\()b \reg, [\ptr], #1
+        .endm
+
+        .macro enter reg1 reg2
+        stmdb sp!, {r0, \reg1, \reg2}
+        .endm
+
+        .macro exit reg1 reg2
+        ldmfd sp!, {r0, \reg1, \reg2}
+        .endm
+
+        .text
+
+/* Prototype: void *memcpy(void *dest, const void *src, size_t n); */
+
+ENTRY(memcpy)
+
+#include "copy_template.S"
+
+ENDPROC(memcpy)
diff --git a/xen/arch/arm/lib/memmove.S b/xen/arch/arm/lib/memmove.S
new file mode 100644
index 0000000..4e142b8
--- /dev/null
+++ b/xen/arch/arm/lib/memmove.S
@@ -0,0 +1,200 @@
+/*
+ *  linux/arch/arm/lib/memmove.S
+ *
+ *  Author:	Nicolas Pitre
+ *  Created:	Sep 28, 2005
+ *  Copyright:	(C) MontaVista Software Inc.
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License version 2 as
+ *  published by the Free Software Foundation.
+ */
+
+#include <xen/config.h>
+
+#include "assembler.h"
+
+		.text
+
+/*
+ * Prototype: void *memmove(void *dest, const void *src, size_t n);
+ *
+ * Note:
+ *
+ * If the memory regions don't overlap, we simply branch to memcpy which is
+ * normally a bit faster. Otherwise the copy is done going downwards.  This
+ * is a transposition of the code from copy_template.S but with the copy
+ * occurring in the opposite direction.
+ */
+
+ENTRY(memmove)
+
+		subs	ip, r0, r1
+		cmphi	r2, ip
+		bls	memcpy
+
+		stmfd	sp!, {r0, r4, lr}
+		add	r1, r1, r2
+		add	r0, r0, r2
+		subs	r2, r2, #4
+		blt	8f
+		ands	ip, r0, #3
+	PLD(	pld	[r1, #-4]		)
+		bne	9f
+		ands	ip, r1, #3
+		bne	10f
+
+1:		subs	r2, r2, #(28)
+		stmfd	sp!, {r5 - r8}
+		blt	5f
+
+	CALGN(	ands	ip, r0, #31		)
+	CALGN(	sbcnes	r4, ip, r2		)  @ C is always set here
+	CALGN(	bcs	2f			)
+	CALGN(	adr	r4, 6f			)
+	CALGN(	subs	r2, r2, ip		)  @ C is set here
+	CALGN(	rsb	ip, ip, #32		)
+	CALGN(	add	pc, r4, ip		)
+
+	PLD(	pld	[r1, #-4]		)
+2:	PLD(	subs	r2, r2, #96		)
+	PLD(	pld	[r1, #-32]		)
+	PLD(	blt	4f			)
+	PLD(	pld	[r1, #-64]		)
+	PLD(	pld	[r1, #-96]		)
+
+3:	PLD(	pld	[r1, #-128]		)
+4:		ldmdb	r1!, {r3, r4, r5, r6, r7, r8, ip, lr}
+		subs	r2, r2, #32
+		stmdb	r0!, {r3, r4, r5, r6, r7, r8, ip, lr}
+		bge	3b
+	PLD(	cmn	r2, #96			)
+	PLD(	bge	4b			)
+
+5:		ands	ip, r2, #28
+		rsb	ip, ip, #32
+		addne	pc, pc, ip		@ C is always clear here
+		b	7f
+6:		W(nop)
+		W(ldr)	r3, [r1, #-4]!
+		W(ldr)	r4, [r1, #-4]!
+		W(ldr)	r5, [r1, #-4]!
+		W(ldr)	r6, [r1, #-4]!
+		W(ldr)	r7, [r1, #-4]!
+		W(ldr)	r8, [r1, #-4]!
+		W(ldr)	lr, [r1, #-4]!
+
+		add	pc, pc, ip
+		nop
+		W(nop)
+		W(str)	r3, [r0, #-4]!
+		W(str)	r4, [r0, #-4]!
+		W(str)	r5, [r0, #-4]!
+		W(str)	r6, [r0, #-4]!
+		W(str)	r7, [r0, #-4]!
+		W(str)	r8, [r0, #-4]!
+		W(str)	lr, [r0, #-4]!
+
+	CALGN(	bcs	2b			)
+
+7:		ldmfd	sp!, {r5 - r8}
+
+8:		movs	r2, r2, lsl #31
+		ldrneb	r3, [r1, #-1]!
+		ldrcsb	r4, [r1, #-1]!
+		ldrcsb	ip, [r1, #-1]
+		strneb	r3, [r0, #-1]!
+		strcsb	r4, [r0, #-1]!
+		strcsb	ip, [r0, #-1]
+		ldmfd	sp!, {r0, r4, pc}
+
+9:		cmp	ip, #2
+		ldrgtb	r3, [r1, #-1]!
+		ldrgeb	r4, [r1, #-1]!
+		ldrb	lr, [r1, #-1]!
+		strgtb	r3, [r0, #-1]!
+		strgeb	r4, [r0, #-1]!
+		subs	r2, r2, ip
+		strb	lr, [r0, #-1]!
+		blt	8b
+		ands	ip, r1, #3
+		beq	1b
+
+10:		bic	r1, r1, #3
+		cmp	ip, #2
+		ldr	r3, [r1, #0]
+		beq	17f
+		blt	18f
+
+
+		.macro	backward_copy_shift push pull
+
+		subs	r2, r2, #28
+		blt	14f
+
+	CALGN(	ands	ip, r0, #31		)
+	CALGN(	sbcnes	r4, ip, r2		)  @ C is always set here
+	CALGN(	subcc	r2, r2, ip		)
+	CALGN(	bcc	15f			)
+
+11:		stmfd	sp!, {r5 - r9}
+
+	PLD(	pld	[r1, #-4]		)
+	PLD(	subs	r2, r2, #96		)
+	PLD(	pld	[r1, #-32]		)
+	PLD(	blt	13f			)
+	PLD(	pld	[r1, #-64]		)
+	PLD(	pld	[r1, #-96]		)
+
+12:	PLD(	pld	[r1, #-128]		)
+13:		ldmdb   r1!, {r7, r8, r9, ip}
+		mov     lr, r3, push #\push
+		subs    r2, r2, #32
+		ldmdb   r1!, {r3, r4, r5, r6}
+		orr     lr, lr, ip, pull #\pull
+		mov     ip, ip, push #\push
+		orr     ip, ip, r9, pull #\pull
+		mov     r9, r9, push #\push
+		orr     r9, r9, r8, pull #\pull
+		mov     r8, r8, push #\push
+		orr     r8, r8, r7, pull #\pull
+		mov     r7, r7, push #\push
+		orr     r7, r7, r6, pull #\pull
+		mov     r6, r6, push #\push
+		orr     r6, r6, r5, pull #\pull
+		mov     r5, r5, push #\push
+		orr     r5, r5, r4, pull #\pull
+		mov     r4, r4, push #\push
+		orr     r4, r4, r3, pull #\pull
+		stmdb   r0!, {r4 - r9, ip, lr}
+		bge	12b
+	PLD(	cmn	r2, #96			)
+	PLD(	bge	13b			)
+
+		ldmfd	sp!, {r5 - r9}
+
+14:		ands	ip, r2, #28
+		beq	16f
+
+15:		mov     lr, r3, push #\push
+		ldr	r3, [r1, #-4]!
+		subs	ip, ip, #4
+		orr	lr, lr, r3, pull #\pull
+		str	lr, [r0, #-4]!
+		bgt	15b
+	CALGN(	cmp	r2, #0			)
+	CALGN(	bge	11b			)
+
+16:		add	r1, r1, #(\pull / 8)
+		b	8b
+
+		.endm
+
+
+		backward_copy_shift	push=8	pull=24
+
+17:		backward_copy_shift	push=16	pull=16
+
+18:		backward_copy_shift	push=24	pull=8
+
+ENDPROC(memmove)
diff --git a/xen/arch/arm/lib/memset.S b/xen/arch/arm/lib/memset.S
new file mode 100644
index 0000000..d2937a3
--- /dev/null
+++ b/xen/arch/arm/lib/memset.S
@@ -0,0 +1,129 @@
+/*
+ *  linux/arch/arm/lib/memset.S
+ *
+ *  Copyright (C) 1995-2000 Russell King
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ *  ASM optimised string functions
+ */
+
+#include <xen/config.h>
+
+#include "assembler.h"
+
+	.text
+	.align	5
+	.word	0
+
+1:	subs	r2, r2, #4		@ 1 do we have enough
+	blt	5f			@ 1 bytes to align with?
+	cmp	r3, #2			@ 1
+	strltb	r1, [r0], #1		@ 1
+	strleb	r1, [r0], #1		@ 1
+	strb	r1, [r0], #1		@ 1
+	add	r2, r2, r3		@ 1 (r2 = r2 - (4 - r3))
+/*
+ * The pointer is now aligned and the length is adjusted.  Try doing the
+ * memset again.
+ */
+
+ENTRY(memset)
+	ands	r3, r0, #3		@ 1 unaligned?
+	bne	1b			@ 1
+/*
+ * we know that the pointer in r0 is aligned to a word boundary.
+ */
+	orr	r1, r1, r1, lsl #8
+	orr	r1, r1, r1, lsl #16
+	mov	r3, r1
+	cmp	r2, #16
+	blt	4f
+
+#if ! CALGN(1)+0
+
+/*
+ * We need an extra register for this loop - save the return address and
+ * use the LR
+ */
+	str	lr, [sp, #-4]!
+	mov	ip, r1
+	mov	lr, r1
+
+2:	subs	r2, r2, #64
+	stmgeia	r0!, {r1, r3, ip, lr}	@ 64 bytes at a time.
+	stmgeia	r0!, {r1, r3, ip, lr}
+	stmgeia	r0!, {r1, r3, ip, lr}
+	stmgeia	r0!, {r1, r3, ip, lr}
+	bgt	2b
+	ldmeqfd	sp!, {pc}		@ Now <64 bytes to go.
+/*
+ * No need to correct the count; we're only testing bits from now on
+ */
+	tst	r2, #32
+	stmneia	r0!, {r1, r3, ip, lr}
+	stmneia	r0!, {r1, r3, ip, lr}
+	tst	r2, #16
+	stmneia	r0!, {r1, r3, ip, lr}
+	ldr	lr, [sp], #4
+
+#else
+
+/*
+ * This version aligns the destination pointer in order to write
+ * whole cache lines at once.
+ */
+
+	stmfd	sp!, {r4-r7, lr}
+	mov	r4, r1
+	mov	r5, r1
+	mov	r6, r1
+	mov	r7, r1
+	mov	ip, r1
+	mov	lr, r1
+
+	cmp	r2, #96
+	tstgt	r0, #31
+	ble	3f
+
+	and	ip, r0, #31
+	rsb	ip, ip, #32
+	sub	r2, r2, ip
+	movs	ip, ip, lsl #(32 - 4)
+	stmcsia	r0!, {r4, r5, r6, r7}
+	stmmiia	r0!, {r4, r5}
+	tst	ip, #(1 << 30)
+	mov	ip, r1
+	strne	r1, [r0], #4
+
+3:	subs	r2, r2, #64
+	stmgeia	r0!, {r1, r3-r7, ip, lr}
+	stmgeia	r0!, {r1, r3-r7, ip, lr}
+	bgt	3b
+	ldmeqfd	sp!, {r4-r7, pc}
+
+	tst	r2, #32
+	stmneia	r0!, {r1, r3-r7, ip, lr}
+	tst	r2, #16
+	stmneia	r0!, {r4-r7}
+	ldmfd	sp!, {r4-r7, lr}
+
+#endif
+
+4:	tst	r2, #8
+	stmneia	r0!, {r1, r3}
+	tst	r2, #4
+	strne	r1, [r0], #4
+/*
+ * When we get here, we've got less than 4 bytes to zero.  We
+ * may have an unaligned pointer as well.
+ */
+5:	tst	r2, #2
+	strneb	r1, [r0], #1
+	strneb	r1, [r0], #1
+	tst	r2, #1
+	strneb	r1, [r0], #1
+	mov	pc, lr
+ENDPROC(memset)
diff --git a/xen/arch/arm/lib/memzero.S b/xen/arch/arm/lib/memzero.S
new file mode 100644
index 0000000..ce25aca
--- /dev/null
+++ b/xen/arch/arm/lib/memzero.S
@@ -0,0 +1,127 @@
+/*
+ *  linux/arch/arm/lib/memzero.S
+ *
+ *  Copyright (C) 1995-2000 Russell King
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <xen/config.h>
+
+#include "assembler.h"
+
+	.text
+	.align	5
+	.word	0
+/*
+ * Align the pointer in r0.  r3 contains the number of bytes that we are
+ * mis-aligned by, and r1 is the number of bytes.  If r1 < 4, then we
+ * don't bother; we use byte stores instead.
+ */
+1:	subs	r1, r1, #4		@ 1 do we have enough
+	blt	5f			@ 1 bytes to align with?
+	cmp	r3, #2			@ 1
+	strltb	r2, [r0], #1		@ 1
+	strleb	r2, [r0], #1		@ 1
+	strb	r2, [r0], #1		@ 1
+	add	r1, r1, r3		@ 1 (r1 = r1 - (4 - r3))
+/*
+ * The pointer is now aligned and the length is adjusted.  Try doing the
+ * memzero again.
+ */
+
+ENTRY(__memzero)
+	mov	r2, #0			@ 1
+	ands	r3, r0, #3		@ 1 unaligned?
+	bne	1b			@ 1
+/*
+ * r3 = 0, and we know that the pointer in r0 is aligned to a word boundary.
+ */
+	cmp	r1, #16			@ 1 we can skip this chunk if we
+	blt	4f			@ 1 have < 16 bytes
+
+#if ! CALGN(1)+0
+
+/*
+ * We need an extra register for this loop - save the return address and
+ * use the LR
+ */
+	str	lr, [sp, #-4]!		@ 1
+	mov	ip, r2			@ 1
+	mov	lr, r2			@ 1
+
+3:	subs	r1, r1, #64		@ 1 write 32 bytes out per loop
+	stmgeia	r0!, {r2, r3, ip, lr}	@ 4
+	stmgeia	r0!, {r2, r3, ip, lr}	@ 4
+	stmgeia	r0!, {r2, r3, ip, lr}	@ 4
+	stmgeia	r0!, {r2, r3, ip, lr}	@ 4
+	bgt	3b			@ 1
+	ldmeqfd	sp!, {pc}		@ 1/2 quick exit
+/*
+ * No need to correct the count; we're only testing bits from now on
+ */
+	tst	r1, #32			@ 1
+	stmneia	r0!, {r2, r3, ip, lr}	@ 4
+	stmneia	r0!, {r2, r3, ip, lr}	@ 4
+	tst	r1, #16			@ 1 16 bytes or more?
+	stmneia	r0!, {r2, r3, ip, lr}	@ 4
+	ldr	lr, [sp], #4		@ 1
+
+#else
+
+/*
+ * This version aligns the destination pointer in order to write
+ * whole cache lines at once.
+ */
+
+	stmfd	sp!, {r4-r7, lr}
+	mov	r4, r2
+	mov	r5, r2
+	mov	r6, r2
+	mov	r7, r2
+	mov	ip, r2
+	mov	lr, r2
+
+	cmp	r1, #96
+	andgts	ip, r0, #31
+	ble	3f
+
+	rsb	ip, ip, #32
+	sub	r1, r1, ip
+	movs	ip, ip, lsl #(32 - 4)
+	stmcsia	r0!, {r4, r5, r6, r7}
+	stmmiia	r0!, {r4, r5}
+	movs	ip, ip, lsl #2
+	strcs	r2, [r0], #4
+
+3:	subs	r1, r1, #64
+	stmgeia	r0!, {r2-r7, ip, lr}
+	stmgeia	r0!, {r2-r7, ip, lr}
+	bgt	3b
+	ldmeqfd	sp!, {r4-r7, pc}
+
+	tst	r1, #32
+	stmneia	r0!, {r2-r7, ip, lr}
+	tst	r1, #16
+	stmneia	r0!, {r4-r7}
+	ldmfd	sp!, {r4-r7, lr}
+
+#endif
+
+4:	tst	r1, #8			@ 1 8 bytes or more?
+	stmneia	r0!, {r2, r3}		@ 2
+	tst	r1, #4			@ 1 4 bytes or more?
+	strne	r2, [r0], #4		@ 1
+/*
+ * When we get here, we've got less than 4 bytes to zero.  We
+ * may have an unaligned pointer as well.
+ */
+5:	tst	r1, #2			@ 1 2 bytes or more?
+	strneb	r2, [r0], #1		@ 1
+	strneb	r2, [r0], #1		@ 1
+	tst	r1, #1			@ 1 a byte left over
+	strneb	r2, [r0], #1		@ 1
+	mov	pc, lr			@ 1
+ENDPROC(__memzero)
diff --git a/xen/arch/arm/lib/setbit.S b/xen/arch/arm/lib/setbit.S
new file mode 100644
index 0000000..c828851
--- /dev/null
+++ b/xen/arch/arm/lib/setbit.S
@@ -0,0 +1,18 @@
+/*
+ *  linux/arch/arm/lib/setbit.S
+ *
+ *  Copyright (C) 1995-1996 Russell King
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#include <xen/config.h>
+
+#include "assembler.h"
+#include "bitops.h"
+	.text
+
+ENTRY(_set_bit)
+	bitop	orr
+ENDPROC(_set_bit)
diff --git a/xen/arch/arm/lib/testchangebit.S b/xen/arch/arm/lib/testchangebit.S
new file mode 100644
index 0000000..a7f527c
--- /dev/null
+++ b/xen/arch/arm/lib/testchangebit.S
@@ -0,0 +1,18 @@
+/*
+ *  linux/arch/arm/lib/testchangebit.S
+ *
+ *  Copyright (C) 1995-1996 Russell King
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#include <xen/config.h>
+
+#include "assembler.h"
+#include "bitops.h"
+                .text
+
+ENTRY(_test_and_change_bit)
+	testop	eor, str
+ENDPROC(_test_and_change_bit)
diff --git a/xen/arch/arm/lib/testclearbit.S b/xen/arch/arm/lib/testclearbit.S
new file mode 100644
index 0000000..8f39c72
--- /dev/null
+++ b/xen/arch/arm/lib/testclearbit.S
@@ -0,0 +1,18 @@
+/*
+ *  linux/arch/arm/lib/testclearbit.S
+ *
+ *  Copyright (C) 1995-1996 Russell King
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#include <xen/config.h>
+
+#include "assembler.h"
+#include "bitops.h"
+                .text
+
+ENTRY(_test_and_clear_bit)
+	testop	bicne, strne
+ENDPROC(_test_and_clear_bit)
diff --git a/xen/arch/arm/lib/testsetbit.S b/xen/arch/arm/lib/testsetbit.S
new file mode 100644
index 0000000..1b8d273
--- /dev/null
+++ b/xen/arch/arm/lib/testsetbit.S
@@ -0,0 +1,18 @@
+/*
+ *  linux/arch/arm/lib/testsetbit.S
+ *
+ *  Copyright (C) 1995-1996 Russell King
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#include <xen/config.h>
+
+#include "assembler.h"
+#include "bitops.h"
+                .text
+
+ENTRY(_test_and_set_bit)
+	testop	orreq, streq
+ENDPROC(_test_and_set_bit)
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 17:14:14 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 17:14:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbEse-0000XN-KD; Thu, 15 Dec 2011 17:14:04 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RbEsc-0000Wq-Nk
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 17:14:03 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1323969233!5547101!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjE2NDg=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18823 invoked from network); 15 Dec 2011 17:13:55 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 17:13:55 -0000
X-IronPort-AV: E=Sophos;i="4.71,357,1320642000"; d="scan'208";a="174317837"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Dec 2011 12:13:51 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Thu, 15 Dec 2011 12:13:48 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pBFGSMtY003330;
	Thu, 15 Dec 2011 08:28:47 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Thu, 15 Dec 2011 16:30:42 +0000
Message-ID: <1323966657-19790-10-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1112131831560.3517@kaball-desktop>
References: <alpine.DEB.2.00.1112131831560.3517@kaball-desktop>
MIME-Version: 1.0
Cc: keir.xen@gmail.com, Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, JBeulich@suse.com,
	Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v3 10/25] arm: bit manipulation,
	copy and division libraries
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Bit manipulation, division and memcpy & friends implementations for the
ARM architecture, shamelessly taken from Linux.


Changes in v2:

- implement __aeabi_uldivmod and __aeabi_ldivmod.


Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
---
 xen/arch/arm/lib/Makefile        |    5 +
 xen/arch/arm/lib/assembler.h     |   49 ++++++
 xen/arch/arm/lib/bitops.h        |   36 +++++
 xen/arch/arm/lib/changebit.S     |   18 +++
 xen/arch/arm/lib/clearbit.S      |   19 +++
 xen/arch/arm/lib/copy_template.S |  266 +++++++++++++++++++++++++++++++++
 xen/arch/arm/lib/div64.S         |  149 +++++++++++++++++++
 xen/arch/arm/lib/findbit.S       |  115 +++++++++++++++
 xen/arch/arm/lib/lib1funcs.S     |  302 ++++++++++++++++++++++++++++++++++++++
 xen/arch/arm/lib/memcpy.S        |   64 ++++++++
 xen/arch/arm/lib/memmove.S       |  200 +++++++++++++++++++++++++
 xen/arch/arm/lib/memset.S        |  129 ++++++++++++++++
 xen/arch/arm/lib/memzero.S       |  127 ++++++++++++++++
 xen/arch/arm/lib/setbit.S        |   18 +++
 xen/arch/arm/lib/testchangebit.S |   18 +++
 xen/arch/arm/lib/testclearbit.S  |   18 +++
 xen/arch/arm/lib/testsetbit.S    |   18 +++
 17 files changed, 1551 insertions(+), 0 deletions(-)
 create mode 100644 xen/arch/arm/lib/Makefile
 create mode 100644 xen/arch/arm/lib/assembler.h
 create mode 100644 xen/arch/arm/lib/bitops.h
 create mode 100644 xen/arch/arm/lib/changebit.S
 create mode 100644 xen/arch/arm/lib/clearbit.S
 create mode 100644 xen/arch/arm/lib/copy_template.S
 create mode 100644 xen/arch/arm/lib/div64.S
 create mode 100644 xen/arch/arm/lib/findbit.S
 create mode 100644 xen/arch/arm/lib/lib1funcs.S
 create mode 100644 xen/arch/arm/lib/memcpy.S
 create mode 100644 xen/arch/arm/lib/memmove.S
 create mode 100644 xen/arch/arm/lib/memset.S
 create mode 100644 xen/arch/arm/lib/memzero.S
 create mode 100644 xen/arch/arm/lib/setbit.S
 create mode 100644 xen/arch/arm/lib/testchangebit.S
 create mode 100644 xen/arch/arm/lib/testclearbit.S
 create mode 100644 xen/arch/arm/lib/testsetbit.S

diff --git a/xen/arch/arm/lib/Makefile b/xen/arch/arm/lib/Makefile
new file mode 100644
index 0000000..cbbed68
--- /dev/null
+++ b/xen/arch/arm/lib/Makefile
@@ -0,0 +1,5 @@
+obj-y += memcpy.o memmove.o memset.o memzero.o
+obj-y += findbit.o setbit.o
+obj-y += setbit.o clearbit.o changebit.o
+obj-y += testsetbit.o testclearbit.o testchangebit.o
+obj-y += lib1funcs.o div64.o
diff --git a/xen/arch/arm/lib/assembler.h b/xen/arch/arm/lib/assembler.h
new file mode 100644
index 0000000..f8f0961
--- /dev/null
+++ b/xen/arch/arm/lib/assembler.h
@@ -0,0 +1,49 @@
+#ifndef __ARCH_ARM_LIB_ASSEMBLER_H__
+#define __ARCH_ARM_LIB_ASSEMBLER_H__
+
+/* From Linux arch/arm/include/asm/assembler.h */
+/*
+ * Data preload for architectures that support it
+ */
+#define PLD(code...)    code
+
+/*
+ * This can be used to enable code to cacheline align the destination
+ * pointer when bulk writing to memory.  Experiments on StrongARM and
+ * XScale didn't show this a worthwhile thing to do when the cache is not
+ * set to write-allocate (this would need further testing on XScale when WA
+ * is used).
+ *
+ * On Feroceon there is much to gain however, regardless of cache mode.
+ */
+#ifdef CONFIG_CPU_FEROCEON /* Not in Xen... */
+#define CALGN(code...) code
+#else
+#define CALGN(code...)
+#endif
+
+// No Thumb, hence:
+#define W(instr)        instr
+#define ARM(instr...)   instr
+#define THUMB(instr...)
+
+#ifdef CONFIG_ARM_UNWIND
+#define UNWIND(code...)         code
+#else
+#define UNWIND(code...)
+#endif
+
+#define pull            lsl
+#define push            lsr
+#define get_byte_0      lsr #24
+#define get_byte_1      lsr #16
+#define get_byte_2      lsr #8
+#define get_byte_3      lsl #0
+#define put_byte_0      lsl #24
+#define put_byte_1      lsl #16
+#define put_byte_2      lsl #8
+#define put_byte_3      lsl #0
+
+#define smp_dmb dmb
+
+#endif /*  __ARCH_ARM_LIB_ASSEMBLER_H__ */
diff --git a/xen/arch/arm/lib/bitops.h b/xen/arch/arm/lib/bitops.h
new file mode 100644
index 0000000..e56d4e8
--- /dev/null
+++ b/xen/arch/arm/lib/bitops.h
@@ -0,0 +1,36 @@
+	.macro	bitop, instr
+	ands	ip, r1, #3
+	strneb	r1, [ip]		@ assert word-aligned
+	mov	r2, #1
+	and	r3, r0, #31		@ Get bit offset
+	mov	r0, r0, lsr #5
+	add	r1, r1, r0, lsl #2	@ Get word offset
+	mov	r3, r2, lsl r3
+1:	ldrex	r2, [r1]
+	\instr	r2, r2, r3
+	strex	r0, r2, [r1]
+	cmp	r0, #0
+	bne	1b
+	bx	lr
+	.endm
+
+	.macro	testop, instr, store
+	ands	ip, r1, #3
+	strneb	r1, [ip]		@ assert word-aligned
+	mov	r2, #1
+	and	r3, r0, #31		@ Get bit offset
+	mov	r0, r0, lsr #5
+	add	r1, r1, r0, lsl #2	@ Get word offset
+	mov	r3, r2, lsl r3		@ create mask
+	smp_dmb
+1:	ldrex	r2, [r1]
+	ands	r0, r2, r3		@ save old value of bit
+	\instr	r2, r2, r3		@ toggle bit
+	strex	ip, r2, [r1]
+	cmp	ip, #0
+	bne	1b
+	smp_dmb
+	cmp	r0, #0
+	movne	r0, #1
+2:	bx	lr
+	.endm
diff --git a/xen/arch/arm/lib/changebit.S b/xen/arch/arm/lib/changebit.S
new file mode 100644
index 0000000..62954bc
--- /dev/null
+++ b/xen/arch/arm/lib/changebit.S
@@ -0,0 +1,18 @@
+/*
+ *  linux/arch/arm/lib/changebit.S
+ *
+ *  Copyright (C) 1995-1996 Russell King
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#include <xen/config.h>
+
+#include "assembler.h"
+#include "bitops.h"
+                .text
+
+ENTRY(_change_bit)
+	bitop	eor
+ENDPROC(_change_bit)
diff --git a/xen/arch/arm/lib/clearbit.S b/xen/arch/arm/lib/clearbit.S
new file mode 100644
index 0000000..42ce416
--- /dev/null
+++ b/xen/arch/arm/lib/clearbit.S
@@ -0,0 +1,19 @@
+/*
+ *  linux/arch/arm/lib/clearbit.S
+ *
+ *  Copyright (C) 1995-1996 Russell King
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <xen/config.h>
+
+#include "assembler.h"
+#include "bitops.h"
+                .text
+
+ENTRY(_clear_bit)
+	bitop	bic
+ENDPROC(_clear_bit)
diff --git a/xen/arch/arm/lib/copy_template.S b/xen/arch/arm/lib/copy_template.S
new file mode 100644
index 0000000..7f7f4d5
--- /dev/null
+++ b/xen/arch/arm/lib/copy_template.S
@@ -0,0 +1,266 @@
+/*
+ *  linux/arch/arm/lib/copy_template.s
+ *
+ *  Code template for optimized memory copy functions
+ *
+ *  Author:	Nicolas Pitre
+ *  Created:	Sep 28, 2005
+ *  Copyright:	MontaVista Software, Inc.
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License version 2 as
+ *  published by the Free Software Foundation.
+ */
+
+/*
+ * Theory of operation
+ * -------------------
+ *
+ * This file provides the core code for a forward memory copy used in
+ * the implementation of memcopy(), copy_to_user() and copy_from_user().
+ *
+ * The including file must define the following accessor macros
+ * according to the need of the given function:
+ *
+ * ldr1w ptr reg abort
+ *
+ *	This loads one word from 'ptr', stores it in 'reg' and increments
+ *	'ptr' to the next word. The 'abort' argument is used for fixup tables.
+ *
+ * ldr4w ptr reg1 reg2 reg3 reg4 abort
+ * ldr8w ptr, reg1 reg2 reg3 reg4 reg5 reg6 reg7 reg8 abort
+ *
+ *	This loads four or eight words starting from 'ptr', stores them
+ *	in provided registers and increments 'ptr' past those words.
+ *	The'abort' argument is used for fixup tables.
+ *
+ * ldr1b ptr reg cond abort
+ *
+ *	Similar to ldr1w, but it loads a byte and increments 'ptr' one byte.
+ *	It also must apply the condition code if provided, otherwise the
+ *	"al" condition is assumed by default.
+ *
+ * str1w ptr reg abort
+ * str8w ptr reg1 reg2 reg3 reg4 reg5 reg6 reg7 reg8 abort
+ * str1b ptr reg cond abort
+ *
+ *	Same as their ldr* counterparts, but data is stored to 'ptr' location
+ *	rather than being loaded.
+ *
+ * enter reg1 reg2
+ *
+ *	Preserve the provided registers on the stack plus any additional
+ *	data as needed by the implementation including this code. Called
+ *	upon code entry.
+ *
+ * exit reg1 reg2
+ *
+ *	Restore registers with the values previously saved with the
+ *	'preserv' macro. Called upon code termination.
+ *
+ * LDR1W_SHIFT
+ * STR1W_SHIFT
+ *
+ *	Correction to be applied to the "ip" register when branching into
+ *	the ldr1w or str1w instructions (some of these macros may expand to
+ *	than one 32bit instruction in Thumb-2)
+ */
+
+		enter	r4, lr
+
+		subs	r2, r2, #4
+		blt	8f
+		ands	ip, r0, #3
+	PLD(	pld	[r1, #0]		)
+		bne	9f
+		ands	ip, r1, #3
+		bne	10f
+
+1:		subs	r2, r2, #(28)
+		stmfd	sp!, {r5 - r8}
+		blt	5f
+
+	CALGN(	ands	ip, r0, #31		)
+	CALGN(	rsb	r3, ip, #32		)
+	CALGN(	sbcnes	r4, r3, r2		)  @ C is always set here
+	CALGN(	bcs	2f			)
+	CALGN(	adr	r4, 6f			)
+	CALGN(	subs	r2, r2, r3		)  @ C gets set
+	CALGN(	add	pc, r4, ip		)
+
+	PLD(	pld	[r1, #0]		)
+2:	PLD(	subs	r2, r2, #96		)
+	PLD(	pld	[r1, #28]		)
+	PLD(	blt	4f			)
+	PLD(	pld	[r1, #60]		)
+	PLD(	pld	[r1, #92]		)
+
+3:	PLD(	pld	[r1, #124]		)
+4:		ldr8w	r1, r3, r4, r5, r6, r7, r8, ip, lr, abort=20f
+		subs	r2, r2, #32
+		str8w	r0, r3, r4, r5, r6, r7, r8, ip, lr, abort=20f
+		bge	3b
+	PLD(	cmn	r2, #96			)
+	PLD(	bge	4b			)
+
+5:		ands	ip, r2, #28
+		rsb	ip, ip, #32
+#if LDR1W_SHIFT > 0
+		lsl	ip, ip, #LDR1W_SHIFT
+#endif
+		addne	pc, pc, ip		@ C is always clear here
+		b	7f
+6:
+		.rept	(1 << LDR1W_SHIFT)
+		W(nop)
+		.endr
+		ldr1w	r1, r3, abort=20f
+		ldr1w	r1, r4, abort=20f
+		ldr1w	r1, r5, abort=20f
+		ldr1w	r1, r6, abort=20f
+		ldr1w	r1, r7, abort=20f
+		ldr1w	r1, r8, abort=20f
+		ldr1w	r1, lr, abort=20f
+
+#if LDR1W_SHIFT < STR1W_SHIFT
+		lsl	ip, ip, #STR1W_SHIFT - LDR1W_SHIFT
+#elif LDR1W_SHIFT > STR1W_SHIFT
+		lsr	ip, ip, #LDR1W_SHIFT - STR1W_SHIFT
+#endif
+		add	pc, pc, ip
+		nop
+		.rept	(1 << STR1W_SHIFT)
+		W(nop)
+		.endr
+		str1w	r0, r3, abort=20f
+		str1w	r0, r4, abort=20f
+		str1w	r0, r5, abort=20f
+		str1w	r0, r6, abort=20f
+		str1w	r0, r7, abort=20f
+		str1w	r0, r8, abort=20f
+		str1w	r0, lr, abort=20f
+
+	CALGN(	bcs	2b			)
+
+7:		ldmfd	sp!, {r5 - r8}
+
+8:		movs	r2, r2, lsl #31
+		ldr1b	r1, r3, ne, abort=21f
+		ldr1b	r1, r4, cs, abort=21f
+		ldr1b	r1, ip, cs, abort=21f
+		str1b	r0, r3, ne, abort=21f
+		str1b	r0, r4, cs, abort=21f
+		str1b	r0, ip, cs, abort=21f
+
+		exit	r4, pc
+
+9:		rsb	ip, ip, #4
+		cmp	ip, #2
+		ldr1b	r1, r3, gt, abort=21f
+		ldr1b	r1, r4, ge, abort=21f
+		ldr1b	r1, lr, abort=21f
+		str1b	r0, r3, gt, abort=21f
+		str1b	r0, r4, ge, abort=21f
+		subs	r2, r2, ip
+		str1b	r0, lr, abort=21f
+		blt	8b
+		ands	ip, r1, #3
+		beq	1b
+
+10:		bic	r1, r1, #3
+		cmp	ip, #2
+		ldr1w	r1, lr, abort=21f
+		beq	17f
+		bgt	18f
+
+
+		.macro	forward_copy_shift pull push
+
+		subs	r2, r2, #28
+		blt	14f
+
+	CALGN(	ands	ip, r0, #31		)
+	CALGN(	rsb	ip, ip, #32		)
+	CALGN(	sbcnes	r4, ip, r2		)  @ C is always set here
+	CALGN(	subcc	r2, r2, ip		)
+	CALGN(	bcc	15f			)
+
+11:		stmfd	sp!, {r5 - r9}
+
+	PLD(	pld	[r1, #0]		)
+	PLD(	subs	r2, r2, #96		)
+	PLD(	pld	[r1, #28]		)
+	PLD(	blt	13f			)
+	PLD(	pld	[r1, #60]		)
+	PLD(	pld	[r1, #92]		)
+
+12:	PLD(	pld	[r1, #124]		)
+13:		ldr4w	r1, r4, r5, r6, r7, abort=19f
+		mov	r3, lr, pull #\pull
+		subs	r2, r2, #32
+		ldr4w	r1, r8, r9, ip, lr, abort=19f
+		orr	r3, r3, r4, push #\push
+		mov	r4, r4, pull #\pull
+		orr	r4, r4, r5, push #\push
+		mov	r5, r5, pull #\pull
+		orr	r5, r5, r6, push #\push
+		mov	r6, r6, pull #\pull
+		orr	r6, r6, r7, push #\push
+		mov	r7, r7, pull #\pull
+		orr	r7, r7, r8, push #\push
+		mov	r8, r8, pull #\pull
+		orr	r8, r8, r9, push #\push
+		mov	r9, r9, pull #\pull
+		orr	r9, r9, ip, push #\push
+		mov	ip, ip, pull #\pull
+		orr	ip, ip, lr, push #\push
+		str8w	r0, r3, r4, r5, r6, r7, r8, r9, ip, , abort=19f
+		bge	12b
+	PLD(	cmn	r2, #96			)
+	PLD(	bge	13b			)
+
+		ldmfd	sp!, {r5 - r9}
+
+14:		ands	ip, r2, #28
+		beq	16f
+
+15:		mov	r3, lr, pull #\pull
+		ldr1w	r1, lr, abort=21f
+		subs	ip, ip, #4
+		orr	r3, r3, lr, push #\push
+		str1w	r0, r3, abort=21f
+		bgt	15b
+	CALGN(	cmp	r2, #0			)
+	CALGN(	bge	11b			)
+
+16:		sub	r1, r1, #(\push / 8)
+		b	8b
+
+		.endm
+
+
+		forward_copy_shift	pull=8	push=24
+
+17:		forward_copy_shift	pull=16	push=16
+
+18:		forward_copy_shift	pull=24	push=8
+
+
+/*
+ * Abort preamble and completion macros.
+ * If a fixup handler is required then those macros must surround it.
+ * It is assumed that the fixup code will handle the private part of
+ * the exit macro.
+ */
+
+	.macro	copy_abort_preamble
+19:	ldmfd	sp!, {r5 - r9}
+	b	21f
+20:	ldmfd	sp!, {r5 - r8}
+21:
+	.endm
+
+	.macro	copy_abort_end
+	ldmfd	sp!, {r4, pc}
+	.endm
+
diff --git a/xen/arch/arm/lib/div64.S b/xen/arch/arm/lib/div64.S
new file mode 100644
index 0000000..2584772
--- /dev/null
+++ b/xen/arch/arm/lib/div64.S
@@ -0,0 +1,149 @@
+/*
+ *  linux/arch/arm/lib/div64.S
+ *
+ *  Optimized computation of 64-bit dividend / 32-bit divisor
+ *
+ *  Author:	Nicolas Pitre
+ *  Created:	Oct 5, 2003
+ *  Copyright:	Monta Vista Software, Inc.
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License version 2 as
+ *  published by the Free Software Foundation.
+ */
+
+#include <xen/config.h>
+#include "assembler.h"
+	
+#define xl r0
+#define xh r1
+#define yl r2
+#define yh r3
+
+/*
+ * __do_div64: perform a division with 64-bit dividend and 32-bit divisor.
+ *
+ * Note: Calling convention is totally non standard for optimal code.
+ *       This is meant to be used by do_div() from include/asm/div64.h only.
+ *
+ * Input parameters:
+ * 	xh-xl	= dividend (clobbered)
+ * 	r4	= divisor (preserved)
+ *
+ * Output values:
+ * 	yh-yl	= result
+ * 	xh	= remainder
+ *
+ * Clobbered regs: xl, ip
+ */
+
+ENTRY(__do_div64)
+
+	@ Test for easy paths first.
+	subs	ip, r4, #1
+	bls	9f			@ divisor is 0 or 1
+	tst	ip, r4
+	beq	8f			@ divisor is power of 2
+
+	@ See if we need to handle upper 32-bit result.
+	cmp	xh, r4
+	mov	yh, #0
+	blo	3f
+
+	@ Align divisor with upper part of dividend.
+	@ The aligned divisor is stored in yl preserving the original.
+	@ The bit position is stored in ip.
+
+	clz	yl, r4
+	clz	ip, xh
+	sub	yl, yl, ip
+	mov	ip, #1
+	mov	ip, ip, lsl yl
+	mov	yl, r4, lsl yl
+
+	@ The division loop for needed upper bit positions.
+ 	@ Break out early if dividend reaches 0.
+2:	cmp	xh, yl
+	orrcs	yh, yh, ip
+	subcss	xh, xh, yl
+	movnes	ip, ip, lsr #1
+	mov	yl, yl, lsr #1
+	bne	2b
+
+	@ See if we need to handle lower 32-bit result.
+3:	cmp	xh, #0
+	mov	yl, #0
+	cmpeq	xl, r4
+	movlo	xh, xl
+	movlo	pc, lr
+
+	@ The division loop for lower bit positions.
+	@ Here we shift remainer bits leftwards rather than moving the
+	@ divisor for comparisons, considering the carry-out bit as well.
+	mov	ip, #0x80000000
+4:	movs	xl, xl, lsl #1
+	adcs	xh, xh, xh
+	beq	6f
+	cmpcc	xh, r4
+5:	orrcs	yl, yl, ip
+	subcs	xh, xh, r4
+	movs	ip, ip, lsr #1
+	bne	4b
+	mov	pc, lr
+
+	@ The top part of remainder became zero.  If carry is set
+	@ (the 33th bit) this is a false positive so resume the loop.
+	@ Otherwise, if lower part is also null then we are done.
+6:	bcs	5b
+	cmp	xl, #0
+	moveq	pc, lr
+
+	@ We still have remainer bits in the low part.  Bring them up.
+
+	clz	xh, xl			@ we know xh is zero here so...
+	add	xh, xh, #1
+	mov	xl, xl, lsl xh
+	mov	ip, ip, lsr xh
+
+	@ Current remainder is now 1.  It is worthless to compare with
+	@ divisor at this point since divisor can not be smaller than 3 here.
+	@ If possible, branch for another shift in the division loop.
+	@ If no bit position left then we are done.
+	movs	ip, ip, lsr #1
+	mov	xh, #1
+	bne	4b
+	mov	pc, lr
+
+8:	@ Division by a power of 2: determine what that divisor order is
+	@ then simply shift values around
+
+	clz	ip, r4
+	rsb	ip, ip, #31
+
+	mov	yh, xh, lsr ip
+	mov	yl, xl, lsr ip
+	rsb	ip, ip, #32
+ ARM(	orr	yl, yl, xh, lsl ip	)
+ THUMB(	lsl	xh, xh, ip		)
+ THUMB(	orr	yl, yl, xh		)
+	mov	xh, xl, lsl ip
+	mov	xh, xh, lsr ip
+	mov	pc, lr
+
+	@ eq -> division by 1: obvious enough...
+9:	moveq	yl, xl
+	moveq	yh, xh
+	moveq	xh, #0
+	moveq	pc, lr
+
+	@ Division by 0:
+	str	lr, [sp, #-8]!
+	bl	__div0
+
+	@ as wrong as it could be...
+	mov	yl, #0
+	mov	yh, #0
+	mov	xh, #0
+	ldr	pc, [sp], #8
+
+ENDPROC(__do_div64)
diff --git a/xen/arch/arm/lib/findbit.S b/xen/arch/arm/lib/findbit.S
new file mode 100644
index 0000000..5669b91
--- /dev/null
+++ b/xen/arch/arm/lib/findbit.S
@@ -0,0 +1,115 @@
+/*
+ *  linux/arch/arm/lib/findbit.S
+ *
+ *  Copyright (C) 1995-2000 Russell King
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * 16th March 2001 - John Ripley <jripley@sonicblue.com>
+ *   Fixed so that "size" is an exclusive not an inclusive quantity.
+ *   All users of these functions expect exclusive sizes, and may
+ *   also call with zero size.
+ * Reworked by rmk.
+ */
+
+#include <xen/config.h>
+
+#include "assembler.h"
+                .text
+
+/*
+ * Purpose  : Find a 'zero' bit
+ * Prototype: int find_first_zero_bit(void *addr, unsigned int maxbit);
+ */
+ENTRY(_find_first_zero_bit)
+		teq	r1, #0	
+		beq	3f
+		mov	r2, #0
+1:
+ ARM(		ldrb	r3, [r0, r2, lsr #3]	)
+ THUMB(		lsr	r3, r2, #3		)
+ THUMB(		ldrb	r3, [r0, r3]		)
+		eors	r3, r3, #0xff		@ invert bits
+		bne	.L_found		@ any now set - found zero bit
+		add	r2, r2, #8		@ next bit pointer
+2:		cmp	r2, r1			@ any more?
+		blo	1b
+3:		mov	r0, r1			@ no free bits
+		mov	pc, lr
+ENDPROC(_find_first_zero_bit)
+
+/*
+ * Purpose  : Find next 'zero' bit
+ * Prototype: int find_next_zero_bit(void *addr, unsigned int maxbit, int offset)
+ */
+ENTRY(_find_next_zero_bit)
+		teq	r1, #0
+		beq	3b
+		ands	ip, r2, #7
+		beq	1b			@ If new byte, goto old routine
+ ARM(		ldrb	r3, [r0, r2, lsr #3]	)
+ THUMB(		lsr	r3, r2, #3		)
+ THUMB(		ldrb	r3, [r0, r3]		)
+		eor	r3, r3, #0xff		@ now looking for a 1 bit
+		movs	r3, r3, lsr ip		@ shift off unused bits
+		bne	.L_found
+		orr	r2, r2, #7		@ if zero, then no bits here
+		add	r2, r2, #1		@ align bit pointer
+		b	2b			@ loop for next bit
+ENDPROC(_find_next_zero_bit)
+
+/*
+ * Purpose  : Find a 'one' bit
+ * Prototype: int find_first_bit(const unsigned long *addr, unsigned int maxbit);
+ */
+ENTRY(_find_first_bit)
+		teq	r1, #0	
+		beq	3f
+		mov	r2, #0
+1:
+ ARM(		ldrb	r3, [r0, r2, lsr #3]	)
+ THUMB(		lsr	r3, r2, #3		)
+ THUMB(		ldrb	r3, [r0, r3]		)
+		movs	r3, r3
+		bne	.L_found		@ any now set - found zero bit
+		add	r2, r2, #8		@ next bit pointer
+2:		cmp	r2, r1			@ any more?
+		blo	1b
+3:		mov	r0, r1			@ no free bits
+		mov	pc, lr
+ENDPROC(_find_first_bit)
+
+/*
+ * Purpose  : Find next 'one' bit
+ * Prototype: int find_next_zero_bit(void *addr, unsigned int maxbit, int offset)
+ */
+ENTRY(_find_next_bit)
+		teq	r1, #0
+		beq	3b
+		ands	ip, r2, #7
+		beq	1b			@ If new byte, goto old routine
+ ARM(		ldrb	r3, [r0, r2, lsr #3]	)
+ THUMB(		lsr	r3, r2, #3		)
+ THUMB(		ldrb	r3, [r0, r3]		)
+		movs	r3, r3, lsr ip		@ shift off unused bits
+		bne	.L_found
+		orr	r2, r2, #7		@ if zero, then no bits here
+		add	r2, r2, #1		@ align bit pointer
+		b	2b			@ loop for next bit
+ENDPROC(_find_next_bit)
+
+/*
+ * One or more bits in the LSB of r3 are assumed to be set.
+ */
+.L_found:
+		rsb	r0, r3, #0
+		and	r3, r3, r0
+		clz	r3, r3
+		rsb	r3, r3, #31
+		add	r0, r2, r3
+		cmp	r1, r0			@ Clamp to maxbit
+		movlo	r0, r1
+		mov	pc, lr
+
diff --git a/xen/arch/arm/lib/lib1funcs.S b/xen/arch/arm/lib/lib1funcs.S
new file mode 100644
index 0000000..828e688
--- /dev/null
+++ b/xen/arch/arm/lib/lib1funcs.S
@@ -0,0 +1,302 @@
+/*
+ * linux/arch/arm/lib/lib1funcs.S: Optimized ARM division routines
+ *
+ * Author: Nicolas Pitre <nico@fluxnic.net>
+ *   - contributed to gcc-3.4 on Sep 30, 2003
+ *   - adapted for the Linux kernel on Oct 2, 2003
+ */
+
+/* Copyright 1995, 1996, 1998, 1999, 2000, 2003 Free Software Foundation, Inc.
+
+This file 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, or (at your option) any
+later version.
+
+In addition to the permissions in the GNU General Public License, the
+Free Software Foundation gives you unlimited permission to link the
+compiled version of this file into combinations with other programs,
+and to distribute those combinations without any restriction coming
+from the use of this file.  (The General Public License restrictions
+do apply in other respects; for example, they cover modification of
+the file, and distribution when not linked into a combine
+executable.)
+
+This file is distributed in the hope that it will be useful, but
+WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  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; see the file COPYING.  If not, write to
+the Free Software Foundation, 59 Temple Place - Suite 330,
+Boston, MA 02111-1307, USA.  */
+
+
+#include <xen/config.h>
+#include "assembler.h"
+
+.macro ARM_DIV_BODY dividend, divisor, result, curbit
+
+	clz	\curbit, \divisor
+	clz	\result, \dividend
+	sub	\result, \curbit, \result
+	mov	\curbit, #1
+	mov	\divisor, \divisor, lsl \result
+	mov	\curbit, \curbit, lsl \result
+	mov	\result, #0
+	
+	@ Division loop
+1:	cmp	\dividend, \divisor
+	subhs	\dividend, \dividend, \divisor
+	orrhs	\result,   \result,   \curbit
+	cmp	\dividend, \divisor,  lsr #1
+	subhs	\dividend, \dividend, \divisor, lsr #1
+	orrhs	\result,   \result,   \curbit,  lsr #1
+	cmp	\dividend, \divisor,  lsr #2
+	subhs	\dividend, \dividend, \divisor, lsr #2
+	orrhs	\result,   \result,   \curbit,  lsr #2
+	cmp	\dividend, \divisor,  lsr #3
+	subhs	\dividend, \dividend, \divisor, lsr #3
+	orrhs	\result,   \result,   \curbit,  lsr #3
+	cmp	\dividend, #0			@ Early termination?
+	movnes	\curbit,   \curbit,  lsr #4	@ No, any more bits to do?
+	movne	\divisor,  \divisor, lsr #4
+	bne	1b
+
+.endm
+
+
+.macro ARM_DIV2_ORDER divisor, order
+
+	clz	\order, \divisor
+	rsb	\order, \order, #31
+
+.endm
+
+
+.macro ARM_MOD_BODY dividend, divisor, order, spare
+
+	clz	\order, \divisor
+	clz	\spare, \dividend
+	sub	\order, \order, \spare
+	mov	\divisor, \divisor, lsl \order
+
+	@ Perform all needed substractions to keep only the reminder.
+	@ Do comparisons in batch of 4 first.
+	subs	\order, \order, #3		@ yes, 3 is intended here
+	blt	2f
+
+1:	cmp	\dividend, \divisor
+	subhs	\dividend, \dividend, \divisor
+	cmp	\dividend, \divisor,  lsr #1
+	subhs	\dividend, \dividend, \divisor, lsr #1
+	cmp	\dividend, \divisor,  lsr #2
+	subhs	\dividend, \dividend, \divisor, lsr #2
+	cmp	\dividend, \divisor,  lsr #3
+	subhs	\dividend, \dividend, \divisor, lsr #3
+	cmp	\dividend, #1
+	mov	\divisor, \divisor, lsr #4
+	subges	\order, \order, #4
+	bge	1b
+
+	tst	\order, #3
+	teqne	\dividend, #0
+	beq	5f
+
+	@ Either 1, 2 or 3 comparison/substractions are left.
+2:	cmn	\order, #2
+	blt	4f
+	beq	3f
+	cmp	\dividend, \divisor
+	subhs	\dividend, \dividend, \divisor
+	mov	\divisor,  \divisor,  lsr #1
+3:	cmp	\dividend, \divisor
+	subhs	\dividend, \dividend, \divisor
+	mov	\divisor,  \divisor,  lsr #1
+4:	cmp	\dividend, \divisor
+	subhs	\dividend, \dividend, \divisor
+5:
+.endm
+
+
+ENTRY(__udivsi3)
+ENTRY(__aeabi_uidiv)
+UNWIND(.fnstart)
+
+	subs	r2, r1, #1
+	moveq	pc, lr
+	bcc	Ldiv0
+	cmp	r0, r1
+	bls	11f
+	tst	r1, r2
+	beq	12f
+
+	ARM_DIV_BODY r0, r1, r2, r3
+
+	mov	r0, r2
+	mov	pc, lr
+
+11:	moveq	r0, #1
+	movne	r0, #0
+	mov	pc, lr
+
+12:	ARM_DIV2_ORDER r1, r2
+
+	mov	r0, r0, lsr r2
+	mov	pc, lr
+
+UNWIND(.fnend)
+ENDPROC(__udivsi3)
+ENDPROC(__aeabi_uidiv)
+
+ENTRY(__umodsi3)
+UNWIND(.fnstart)
+
+	subs	r2, r1, #1			@ compare divisor with 1
+	bcc	Ldiv0
+	cmpne	r0, r1				@ compare dividend with divisor
+	moveq   r0, #0
+	tsthi	r1, r2				@ see if divisor is power of 2
+	andeq	r0, r0, r2
+	movls	pc, lr
+
+	ARM_MOD_BODY r0, r1, r2, r3
+
+	mov	pc, lr
+
+UNWIND(.fnend)
+ENDPROC(__umodsi3)
+
+ENTRY(__divsi3)
+ENTRY(__aeabi_idiv)
+UNWIND(.fnstart)
+
+	cmp	r1, #0
+	eor	ip, r0, r1			@ save the sign of the result.
+	beq	Ldiv0
+	rsbmi	r1, r1, #0			@ loops below use unsigned.
+	subs	r2, r1, #1			@ division by 1 or -1 ?
+	beq	10f
+	movs	r3, r0
+	rsbmi	r3, r0, #0			@ positive dividend value
+	cmp	r3, r1
+	bls	11f
+	tst	r1, r2				@ divisor is power of 2 ?
+	beq	12f
+
+	ARM_DIV_BODY r3, r1, r0, r2
+
+	cmp	ip, #0
+	rsbmi	r0, r0, #0
+	mov	pc, lr
+
+10:	teq	ip, r0				@ same sign ?
+	rsbmi	r0, r0, #0
+	mov	pc, lr
+
+11:	movlo	r0, #0
+	moveq	r0, ip, asr #31
+	orreq	r0, r0, #1
+	mov	pc, lr
+
+12:	ARM_DIV2_ORDER r1, r2
+
+	cmp	ip, #0
+	mov	r0, r3, lsr r2
+	rsbmi	r0, r0, #0
+	mov	pc, lr
+
+UNWIND(.fnend)
+ENDPROC(__divsi3)
+ENDPROC(__aeabi_idiv)
+
+ENTRY(__modsi3)
+UNWIND(.fnstart)
+
+	cmp	r1, #0
+	beq	Ldiv0
+	rsbmi	r1, r1, #0			@ loops below use unsigned.
+	movs	ip, r0				@ preserve sign of dividend
+	rsbmi	r0, r0, #0			@ if negative make positive
+	subs	r2, r1, #1			@ compare divisor with 1
+	cmpne	r0, r1				@ compare dividend with divisor
+	moveq	r0, #0
+	tsthi	r1, r2				@ see if divisor is power of 2
+	andeq	r0, r0, r2
+	bls	10f
+
+	ARM_MOD_BODY r0, r1, r2, r3
+
+10:	cmp	ip, #0
+	rsbmi	r0, r0, #0
+	mov	pc, lr
+
+UNWIND(.fnend)
+ENDPROC(__modsi3)
+
+ENTRY(__aeabi_uidivmod)
+UNWIND(.fnstart)
+UNWIND(.save {r0, r1, ip, lr}	)
+
+	stmfd	sp!, {r0, r1, ip, lr}
+	bl	__aeabi_uidiv
+	ldmfd	sp!, {r1, r2, ip, lr}
+	mul	r3, r0, r2
+	sub	r1, r1, r3
+	mov	pc, lr
+
+UNWIND(.fnend)
+ENDPROC(__aeabi_uidivmod)
+
+ENTRY(__aeabi_idivmod)
+UNWIND(.fnstart)
+UNWIND(.save {r0, r1, ip, lr}	)
+	stmfd	sp!, {r0, r1, ip, lr}
+	bl	__aeabi_idiv
+	ldmfd	sp!, {r1, r2, ip, lr}
+	mul	r3, r0, r2
+	sub	r1, r1, r3
+	mov	pc, lr
+
+UNWIND(.fnend)
+ENDPROC(__aeabi_idivmod)
+
+ENTRY(__aeabi_uldivmod)
+UNWIND(.fnstart)
+UNWIND(.save {lr}	)
+	sub sp, sp, #8
+	stmfd   sp!, {sp, lr}
+	bl __qdivrem
+	ldr lr, [sp, #4]
+	add sp, sp, #8
+	ldmfd sp!, {r2, r3}
+	mov	pc, lr
+
+UNWIND(.fnend)
+ENDPROC(__aeabi_uldivmod)
+
+ENTRY(__aeabi_ldivmod)
+UNWIND(.fnstart)
+UNWIND(.save {lr}	)
+	sub sp, sp, #16
+	stmfd   sp!, {sp, lr}
+	bl __ldivmod_helper
+	ldr lr, [sp, #4]
+	add sp, sp, #16
+	ldmfd	sp!, {r2, r3}
+	mov	pc, lr
+	
+UNWIND(.fnend)
+ENDPROC(__aeabi_uldivmod)
+
+Ldiv0:
+UNWIND(.fnstart)
+UNWIND(.pad #4)
+UNWIND(.save {lr})
+	str	lr, [sp, #-8]!
+	bl	__div0
+	mov	r0, #0			@ About as wrong as it could be.
+	ldr	pc, [sp], #8
+UNWIND(.fnend)
+ENDPROC(Ldiv0)
diff --git a/xen/arch/arm/lib/memcpy.S b/xen/arch/arm/lib/memcpy.S
new file mode 100644
index 0000000..f4bad5c
--- /dev/null
+++ b/xen/arch/arm/lib/memcpy.S
@@ -0,0 +1,64 @@
+/*
+ *  linux/arch/arm/lib/memcpy.S
+ *
+ *  Author:     Nicolas Pitre
+ *  Created:    Sep 28, 2005
+ *  Copyright:  MontaVista Software, Inc.
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License version 2 as
+ *  published by the Free Software Foundation.
+ */
+
+#include <xen/config.h>
+
+#include "assembler.h"
+
+#define LDR1W_SHIFT     0
+#define STR1W_SHIFT     0
+
+        .macro ldr1w ptr reg abort
+        W(ldr) \reg, [\ptr], #4
+        .endm
+
+        .macro ldr4w ptr reg1 reg2 reg3 reg4 abort
+        ldmia \ptr!, {\reg1, \reg2, \reg3, \reg4}
+        .endm
+
+        .macro ldr8w ptr reg1 reg2 reg3 reg4 reg5 reg6 reg7 reg8 abort
+        ldmia \ptr!, {\reg1, \reg2, \reg3, \reg4, \reg5, \reg6, \reg7, \reg8}
+        .endm
+
+        .macro ldr1b ptr reg cond=al abort
+        ldr\cond\()b \reg, [\ptr], #1
+        .endm
+
+        .macro str1w ptr reg abort
+        W(str) \reg, [\ptr], #4
+        .endm
+
+        .macro str8w ptr reg1 reg2 reg3 reg4 reg5 reg6 reg7 reg8 abort
+        stmia \ptr!, {\reg1, \reg2, \reg3, \reg4, \reg5, \reg6, \reg7, \reg8}
+        .endm
+
+        .macro str1b ptr reg cond=al abort
+        str\cond\()b \reg, [\ptr], #1
+        .endm
+
+        .macro enter reg1 reg2
+        stmdb sp!, {r0, \reg1, \reg2}
+        .endm
+
+        .macro exit reg1 reg2
+        ldmfd sp!, {r0, \reg1, \reg2}
+        .endm
+
+        .text
+
+/* Prototype: void *memcpy(void *dest, const void *src, size_t n); */
+
+ENTRY(memcpy)
+
+#include "copy_template.S"
+
+ENDPROC(memcpy)
diff --git a/xen/arch/arm/lib/memmove.S b/xen/arch/arm/lib/memmove.S
new file mode 100644
index 0000000..4e142b8
--- /dev/null
+++ b/xen/arch/arm/lib/memmove.S
@@ -0,0 +1,200 @@
+/*
+ *  linux/arch/arm/lib/memmove.S
+ *
+ *  Author:	Nicolas Pitre
+ *  Created:	Sep 28, 2005
+ *  Copyright:	(C) MontaVista Software Inc.
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License version 2 as
+ *  published by the Free Software Foundation.
+ */
+
+#include <xen/config.h>
+
+#include "assembler.h"
+
+		.text
+
+/*
+ * Prototype: void *memmove(void *dest, const void *src, size_t n);
+ *
+ * Note:
+ *
+ * If the memory regions don't overlap, we simply branch to memcpy which is
+ * normally a bit faster. Otherwise the copy is done going downwards.  This
+ * is a transposition of the code from copy_template.S but with the copy
+ * occurring in the opposite direction.
+ */
+
+ENTRY(memmove)
+
+		subs	ip, r0, r1
+		cmphi	r2, ip
+		bls	memcpy
+
+		stmfd	sp!, {r0, r4, lr}
+		add	r1, r1, r2
+		add	r0, r0, r2
+		subs	r2, r2, #4
+		blt	8f
+		ands	ip, r0, #3
+	PLD(	pld	[r1, #-4]		)
+		bne	9f
+		ands	ip, r1, #3
+		bne	10f
+
+1:		subs	r2, r2, #(28)
+		stmfd	sp!, {r5 - r8}
+		blt	5f
+
+	CALGN(	ands	ip, r0, #31		)
+	CALGN(	sbcnes	r4, ip, r2		)  @ C is always set here
+	CALGN(	bcs	2f			)
+	CALGN(	adr	r4, 6f			)
+	CALGN(	subs	r2, r2, ip		)  @ C is set here
+	CALGN(	rsb	ip, ip, #32		)
+	CALGN(	add	pc, r4, ip		)
+
+	PLD(	pld	[r1, #-4]		)
+2:	PLD(	subs	r2, r2, #96		)
+	PLD(	pld	[r1, #-32]		)
+	PLD(	blt	4f			)
+	PLD(	pld	[r1, #-64]		)
+	PLD(	pld	[r1, #-96]		)
+
+3:	PLD(	pld	[r1, #-128]		)
+4:		ldmdb	r1!, {r3, r4, r5, r6, r7, r8, ip, lr}
+		subs	r2, r2, #32
+		stmdb	r0!, {r3, r4, r5, r6, r7, r8, ip, lr}
+		bge	3b
+	PLD(	cmn	r2, #96			)
+	PLD(	bge	4b			)
+
+5:		ands	ip, r2, #28
+		rsb	ip, ip, #32
+		addne	pc, pc, ip		@ C is always clear here
+		b	7f
+6:		W(nop)
+		W(ldr)	r3, [r1, #-4]!
+		W(ldr)	r4, [r1, #-4]!
+		W(ldr)	r5, [r1, #-4]!
+		W(ldr)	r6, [r1, #-4]!
+		W(ldr)	r7, [r1, #-4]!
+		W(ldr)	r8, [r1, #-4]!
+		W(ldr)	lr, [r1, #-4]!
+
+		add	pc, pc, ip
+		nop
+		W(nop)
+		W(str)	r3, [r0, #-4]!
+		W(str)	r4, [r0, #-4]!
+		W(str)	r5, [r0, #-4]!
+		W(str)	r6, [r0, #-4]!
+		W(str)	r7, [r0, #-4]!
+		W(str)	r8, [r0, #-4]!
+		W(str)	lr, [r0, #-4]!
+
+	CALGN(	bcs	2b			)
+
+7:		ldmfd	sp!, {r5 - r8}
+
+8:		movs	r2, r2, lsl #31
+		ldrneb	r3, [r1, #-1]!
+		ldrcsb	r4, [r1, #-1]!
+		ldrcsb	ip, [r1, #-1]
+		strneb	r3, [r0, #-1]!
+		strcsb	r4, [r0, #-1]!
+		strcsb	ip, [r0, #-1]
+		ldmfd	sp!, {r0, r4, pc}
+
+9:		cmp	ip, #2
+		ldrgtb	r3, [r1, #-1]!
+		ldrgeb	r4, [r1, #-1]!
+		ldrb	lr, [r1, #-1]!
+		strgtb	r3, [r0, #-1]!
+		strgeb	r4, [r0, #-1]!
+		subs	r2, r2, ip
+		strb	lr, [r0, #-1]!
+		blt	8b
+		ands	ip, r1, #3
+		beq	1b
+
+10:		bic	r1, r1, #3
+		cmp	ip, #2
+		ldr	r3, [r1, #0]
+		beq	17f
+		blt	18f
+
+
+		.macro	backward_copy_shift push pull
+
+		subs	r2, r2, #28
+		blt	14f
+
+	CALGN(	ands	ip, r0, #31		)
+	CALGN(	sbcnes	r4, ip, r2		)  @ C is always set here
+	CALGN(	subcc	r2, r2, ip		)
+	CALGN(	bcc	15f			)
+
+11:		stmfd	sp!, {r5 - r9}
+
+	PLD(	pld	[r1, #-4]		)
+	PLD(	subs	r2, r2, #96		)
+	PLD(	pld	[r1, #-32]		)
+	PLD(	blt	13f			)
+	PLD(	pld	[r1, #-64]		)
+	PLD(	pld	[r1, #-96]		)
+
+12:	PLD(	pld	[r1, #-128]		)
+13:		ldmdb   r1!, {r7, r8, r9, ip}
+		mov     lr, r3, push #\push
+		subs    r2, r2, #32
+		ldmdb   r1!, {r3, r4, r5, r6}
+		orr     lr, lr, ip, pull #\pull
+		mov     ip, ip, push #\push
+		orr     ip, ip, r9, pull #\pull
+		mov     r9, r9, push #\push
+		orr     r9, r9, r8, pull #\pull
+		mov     r8, r8, push #\push
+		orr     r8, r8, r7, pull #\pull
+		mov     r7, r7, push #\push
+		orr     r7, r7, r6, pull #\pull
+		mov     r6, r6, push #\push
+		orr     r6, r6, r5, pull #\pull
+		mov     r5, r5, push #\push
+		orr     r5, r5, r4, pull #\pull
+		mov     r4, r4, push #\push
+		orr     r4, r4, r3, pull #\pull
+		stmdb   r0!, {r4 - r9, ip, lr}
+		bge	12b
+	PLD(	cmn	r2, #96			)
+	PLD(	bge	13b			)
+
+		ldmfd	sp!, {r5 - r9}
+
+14:		ands	ip, r2, #28
+		beq	16f
+
+15:		mov     lr, r3, push #\push
+		ldr	r3, [r1, #-4]!
+		subs	ip, ip, #4
+		orr	lr, lr, r3, pull #\pull
+		str	lr, [r0, #-4]!
+		bgt	15b
+	CALGN(	cmp	r2, #0			)
+	CALGN(	bge	11b			)
+
+16:		add	r1, r1, #(\pull / 8)
+		b	8b
+
+		.endm
+
+
+		backward_copy_shift	push=8	pull=24
+
+17:		backward_copy_shift	push=16	pull=16
+
+18:		backward_copy_shift	push=24	pull=8
+
+ENDPROC(memmove)
diff --git a/xen/arch/arm/lib/memset.S b/xen/arch/arm/lib/memset.S
new file mode 100644
index 0000000..d2937a3
--- /dev/null
+++ b/xen/arch/arm/lib/memset.S
@@ -0,0 +1,129 @@
+/*
+ *  linux/arch/arm/lib/memset.S
+ *
+ *  Copyright (C) 1995-2000 Russell King
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ *  ASM optimised string functions
+ */
+
+#include <xen/config.h>
+
+#include "assembler.h"
+
+	.text
+	.align	5
+	.word	0
+
+1:	subs	r2, r2, #4		@ 1 do we have enough
+	blt	5f			@ 1 bytes to align with?
+	cmp	r3, #2			@ 1
+	strltb	r1, [r0], #1		@ 1
+	strleb	r1, [r0], #1		@ 1
+	strb	r1, [r0], #1		@ 1
+	add	r2, r2, r3		@ 1 (r2 = r2 - (4 - r3))
+/*
+ * The pointer is now aligned and the length is adjusted.  Try doing the
+ * memset again.
+ */
+
+ENTRY(memset)
+	ands	r3, r0, #3		@ 1 unaligned?
+	bne	1b			@ 1
+/*
+ * we know that the pointer in r0 is aligned to a word boundary.
+ */
+	orr	r1, r1, r1, lsl #8
+	orr	r1, r1, r1, lsl #16
+	mov	r3, r1
+	cmp	r2, #16
+	blt	4f
+
+#if ! CALGN(1)+0
+
+/*
+ * We need an extra register for this loop - save the return address and
+ * use the LR
+ */
+	str	lr, [sp, #-4]!
+	mov	ip, r1
+	mov	lr, r1
+
+2:	subs	r2, r2, #64
+	stmgeia	r0!, {r1, r3, ip, lr}	@ 64 bytes at a time.
+	stmgeia	r0!, {r1, r3, ip, lr}
+	stmgeia	r0!, {r1, r3, ip, lr}
+	stmgeia	r0!, {r1, r3, ip, lr}
+	bgt	2b
+	ldmeqfd	sp!, {pc}		@ Now <64 bytes to go.
+/*
+ * No need to correct the count; we're only testing bits from now on
+ */
+	tst	r2, #32
+	stmneia	r0!, {r1, r3, ip, lr}
+	stmneia	r0!, {r1, r3, ip, lr}
+	tst	r2, #16
+	stmneia	r0!, {r1, r3, ip, lr}
+	ldr	lr, [sp], #4
+
+#else
+
+/*
+ * This version aligns the destination pointer in order to write
+ * whole cache lines at once.
+ */
+
+	stmfd	sp!, {r4-r7, lr}
+	mov	r4, r1
+	mov	r5, r1
+	mov	r6, r1
+	mov	r7, r1
+	mov	ip, r1
+	mov	lr, r1
+
+	cmp	r2, #96
+	tstgt	r0, #31
+	ble	3f
+
+	and	ip, r0, #31
+	rsb	ip, ip, #32
+	sub	r2, r2, ip
+	movs	ip, ip, lsl #(32 - 4)
+	stmcsia	r0!, {r4, r5, r6, r7}
+	stmmiia	r0!, {r4, r5}
+	tst	ip, #(1 << 30)
+	mov	ip, r1
+	strne	r1, [r0], #4
+
+3:	subs	r2, r2, #64
+	stmgeia	r0!, {r1, r3-r7, ip, lr}
+	stmgeia	r0!, {r1, r3-r7, ip, lr}
+	bgt	3b
+	ldmeqfd	sp!, {r4-r7, pc}
+
+	tst	r2, #32
+	stmneia	r0!, {r1, r3-r7, ip, lr}
+	tst	r2, #16
+	stmneia	r0!, {r4-r7}
+	ldmfd	sp!, {r4-r7, lr}
+
+#endif
+
+4:	tst	r2, #8
+	stmneia	r0!, {r1, r3}
+	tst	r2, #4
+	strne	r1, [r0], #4
+/*
+ * When we get here, we've got less than 4 bytes to zero.  We
+ * may have an unaligned pointer as well.
+ */
+5:	tst	r2, #2
+	strneb	r1, [r0], #1
+	strneb	r1, [r0], #1
+	tst	r2, #1
+	strneb	r1, [r0], #1
+	mov	pc, lr
+ENDPROC(memset)
diff --git a/xen/arch/arm/lib/memzero.S b/xen/arch/arm/lib/memzero.S
new file mode 100644
index 0000000..ce25aca
--- /dev/null
+++ b/xen/arch/arm/lib/memzero.S
@@ -0,0 +1,127 @@
+/*
+ *  linux/arch/arm/lib/memzero.S
+ *
+ *  Copyright (C) 1995-2000 Russell King
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <xen/config.h>
+
+#include "assembler.h"
+
+	.text
+	.align	5
+	.word	0
+/*
+ * Align the pointer in r0.  r3 contains the number of bytes that we are
+ * mis-aligned by, and r1 is the number of bytes.  If r1 < 4, then we
+ * don't bother; we use byte stores instead.
+ */
+1:	subs	r1, r1, #4		@ 1 do we have enough
+	blt	5f			@ 1 bytes to align with?
+	cmp	r3, #2			@ 1
+	strltb	r2, [r0], #1		@ 1
+	strleb	r2, [r0], #1		@ 1
+	strb	r2, [r0], #1		@ 1
+	add	r1, r1, r3		@ 1 (r1 = r1 - (4 - r3))
+/*
+ * The pointer is now aligned and the length is adjusted.  Try doing the
+ * memzero again.
+ */
+
+ENTRY(__memzero)
+	mov	r2, #0			@ 1
+	ands	r3, r0, #3		@ 1 unaligned?
+	bne	1b			@ 1
+/*
+ * r3 = 0, and we know that the pointer in r0 is aligned to a word boundary.
+ */
+	cmp	r1, #16			@ 1 we can skip this chunk if we
+	blt	4f			@ 1 have < 16 bytes
+
+#if ! CALGN(1)+0
+
+/*
+ * We need an extra register for this loop - save the return address and
+ * use the LR
+ */
+	str	lr, [sp, #-4]!		@ 1
+	mov	ip, r2			@ 1
+	mov	lr, r2			@ 1
+
+3:	subs	r1, r1, #64		@ 1 write 32 bytes out per loop
+	stmgeia	r0!, {r2, r3, ip, lr}	@ 4
+	stmgeia	r0!, {r2, r3, ip, lr}	@ 4
+	stmgeia	r0!, {r2, r3, ip, lr}	@ 4
+	stmgeia	r0!, {r2, r3, ip, lr}	@ 4
+	bgt	3b			@ 1
+	ldmeqfd	sp!, {pc}		@ 1/2 quick exit
+/*
+ * No need to correct the count; we're only testing bits from now on
+ */
+	tst	r1, #32			@ 1
+	stmneia	r0!, {r2, r3, ip, lr}	@ 4
+	stmneia	r0!, {r2, r3, ip, lr}	@ 4
+	tst	r1, #16			@ 1 16 bytes or more?
+	stmneia	r0!, {r2, r3, ip, lr}	@ 4
+	ldr	lr, [sp], #4		@ 1
+
+#else
+
+/*
+ * This version aligns the destination pointer in order to write
+ * whole cache lines at once.
+ */
+
+	stmfd	sp!, {r4-r7, lr}
+	mov	r4, r2
+	mov	r5, r2
+	mov	r6, r2
+	mov	r7, r2
+	mov	ip, r2
+	mov	lr, r2
+
+	cmp	r1, #96
+	andgts	ip, r0, #31
+	ble	3f
+
+	rsb	ip, ip, #32
+	sub	r1, r1, ip
+	movs	ip, ip, lsl #(32 - 4)
+	stmcsia	r0!, {r4, r5, r6, r7}
+	stmmiia	r0!, {r4, r5}
+	movs	ip, ip, lsl #2
+	strcs	r2, [r0], #4
+
+3:	subs	r1, r1, #64
+	stmgeia	r0!, {r2-r7, ip, lr}
+	stmgeia	r0!, {r2-r7, ip, lr}
+	bgt	3b
+	ldmeqfd	sp!, {r4-r7, pc}
+
+	tst	r1, #32
+	stmneia	r0!, {r2-r7, ip, lr}
+	tst	r1, #16
+	stmneia	r0!, {r4-r7}
+	ldmfd	sp!, {r4-r7, lr}
+
+#endif
+
+4:	tst	r1, #8			@ 1 8 bytes or more?
+	stmneia	r0!, {r2, r3}		@ 2
+	tst	r1, #4			@ 1 4 bytes or more?
+	strne	r2, [r0], #4		@ 1
+/*
+ * When we get here, we've got less than 4 bytes to zero.  We
+ * may have an unaligned pointer as well.
+ */
+5:	tst	r1, #2			@ 1 2 bytes or more?
+	strneb	r2, [r0], #1		@ 1
+	strneb	r2, [r0], #1		@ 1
+	tst	r1, #1			@ 1 a byte left over
+	strneb	r2, [r0], #1		@ 1
+	mov	pc, lr			@ 1
+ENDPROC(__memzero)
diff --git a/xen/arch/arm/lib/setbit.S b/xen/arch/arm/lib/setbit.S
new file mode 100644
index 0000000..c828851
--- /dev/null
+++ b/xen/arch/arm/lib/setbit.S
@@ -0,0 +1,18 @@
+/*
+ *  linux/arch/arm/lib/setbit.S
+ *
+ *  Copyright (C) 1995-1996 Russell King
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#include <xen/config.h>
+
+#include "assembler.h"
+#include "bitops.h"
+	.text
+
+ENTRY(_set_bit)
+	bitop	orr
+ENDPROC(_set_bit)
diff --git a/xen/arch/arm/lib/testchangebit.S b/xen/arch/arm/lib/testchangebit.S
new file mode 100644
index 0000000..a7f527c
--- /dev/null
+++ b/xen/arch/arm/lib/testchangebit.S
@@ -0,0 +1,18 @@
+/*
+ *  linux/arch/arm/lib/testchangebit.S
+ *
+ *  Copyright (C) 1995-1996 Russell King
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#include <xen/config.h>
+
+#include "assembler.h"
+#include "bitops.h"
+                .text
+
+ENTRY(_test_and_change_bit)
+	testop	eor, str
+ENDPROC(_test_and_change_bit)
diff --git a/xen/arch/arm/lib/testclearbit.S b/xen/arch/arm/lib/testclearbit.S
new file mode 100644
index 0000000..8f39c72
--- /dev/null
+++ b/xen/arch/arm/lib/testclearbit.S
@@ -0,0 +1,18 @@
+/*
+ *  linux/arch/arm/lib/testclearbit.S
+ *
+ *  Copyright (C) 1995-1996 Russell King
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#include <xen/config.h>
+
+#include "assembler.h"
+#include "bitops.h"
+                .text
+
+ENTRY(_test_and_clear_bit)
+	testop	bicne, strne
+ENDPROC(_test_and_clear_bit)
diff --git a/xen/arch/arm/lib/testsetbit.S b/xen/arch/arm/lib/testsetbit.S
new file mode 100644
index 0000000..1b8d273
--- /dev/null
+++ b/xen/arch/arm/lib/testsetbit.S
@@ -0,0 +1,18 @@
+/*
+ *  linux/arch/arm/lib/testsetbit.S
+ *
+ *  Copyright (C) 1995-1996 Russell King
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#include <xen/config.h>
+
+#include "assembler.h"
+#include "bitops.h"
+                .text
+
+ENTRY(_test_and_set_bit)
+	testop	orreq, streq
+ENDPROC(_test_and_set_bit)
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 17:19:13 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 17:19:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbExO-0000wR-Jh; Thu, 15 Dec 2011 17:18:58 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RbExN-0000w1-Vg
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 17:18:58 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1323969530!5730417!1
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28927 invoked from network); 15 Dec 2011 17:18:50 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 17:18:50 -0000
Received: by wgbds11 with SMTP id ds11so3744572wgb.24
	for <xen-devel@lists.xensource.com>;
	Thu, 15 Dec 2011 09:18:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:user-agent:date:from:to;
	bh=Gg932IR4I4HAjeMJUG6egZtaoXcUON0f4aAkaJIEiSQ=;
	b=P3MbG59ue8Znbjnnqk3BnxXq+0hwfc5zW5f3lEowQqnOWiZ1HqdnWDjhwz8QCY+zL8
	Qu5JhviEntVj3/Q3LHkzyVX18C5qhaQ8WyESGQxuDW4Fdgb9yZbuE+xgNEobRcZ7A9bU
	skBYGcF08jQIpwNfUmmeDApF4dSLli1Fgc6RY=
Received: by 10.227.208.81 with SMTP id gb17mr3089223wbb.26.1323969530322;
	Thu, 15 Dec 2011 09:18:50 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id d17sm10250400wbh.19.2011.12.15.09.18.48
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 15 Dec 2011 09:18:48 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: a01f1e2f654ea54bbf5d0a77b315b676cc494aa8
Message-Id: <a01f1e2f654ea54bbf5d.1323969513@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Thu, 15 Dec 2011 18:18:33 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH] blktap2: use HAVE_BYTESWAP_H and _BYTESWAP_H
 for uclibc compatibility
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1323969492 -3600
# Node ID a01f1e2f654ea54bbf5d0a77b315b676cc494aa8
# Parent  0051e09f73efea06f2f28c0ece57194e286daedc
blktap2: use HAVE_BYTESWAP_H and _BYTESWAP_H for uclibc compatibility

uclibc defines _BYTESWAP_H instead of HAVE_BYTESWAP_H in byteswap.h:

http://git.uclibc.org/uClibc/tree/include/byteswap.h

Without this fix, blktap2 doesn't compile under uclibc and throws the
following error:

gcc  -O1 -fno-omit-frame-pointer -m64 -g -fno-strict-aliasing
-std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement
-Wno-unused-but-set-variable   -D__XEN_TOOLS__ -MMD -MF
.block-qcow.o.d  -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE
-fno-optimize-sibling-calls -Werror -g -O0 -Wno-unused
-fno-strict-aliasing -I../include -I../drivers
-I/root/xen-unstable/tools/blktap2/drivers/../../../tools/libxc
-I/root/xen-unstable/tools/blktap2/drivers/../../../tools/include -I
/root/xen-unstable/tools/blktap2/drivers/../../../tools/memshr
-D_GNU_SOURCE -DUSE_NFS_LOCKS -fPIC -I
/root/xen-unstable/tools/blktap2/drivers/../../../tools/libaio/src  -c
-o block-qcow.o block-qcow.c  -I/usr/local/include
In file included from block-qcow.c:37:0:
bswap.h:23:0: error: "bswap_16" redefined [-Werror]
/usr/include/byteswap.h:30:0: note: this is the location of the
previous definition
bswap.h:31:0: error: "bswap_32" redefined [-Werror]
/usr/include/byteswap.h:33:0: note: this is the location of the
previous definition
bswap.h:41:0: error: "bswap_64" redefined [-Werror]
/usr/include/byteswap.h:37:0: note: this is the location of the
previous definition
cc1: all warnings being treated as errors

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 0051e09f73ef -r a01f1e2f654e tools/blktap2/drivers/bswap.h
--- a/tools/blktap2/drivers/bswap.h	Thu Dec 15 10:00:09 2011 +0100
+++ b/tools/blktap2/drivers/bswap.h	Thu Dec 15 18:18:12 2011 +0100
@@ -15,7 +15,7 @@
 #define bswap_64(x) swap64(x)
 #else
 
-#ifdef HAVE_BYTESWAP_H
+#if defined(HAVE_BYTESWAP_H) || defined(_BYTESWAP_H)
 #include <byteswap.h>
 #else
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 17:19:13 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 17:19:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbExO-0000wR-Jh; Thu, 15 Dec 2011 17:18:58 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RbExN-0000w1-Vg
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 17:18:58 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1323969530!5730417!1
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28927 invoked from network); 15 Dec 2011 17:18:50 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 17:18:50 -0000
Received: by wgbds11 with SMTP id ds11so3744572wgb.24
	for <xen-devel@lists.xensource.com>;
	Thu, 15 Dec 2011 09:18:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:user-agent:date:from:to;
	bh=Gg932IR4I4HAjeMJUG6egZtaoXcUON0f4aAkaJIEiSQ=;
	b=P3MbG59ue8Znbjnnqk3BnxXq+0hwfc5zW5f3lEowQqnOWiZ1HqdnWDjhwz8QCY+zL8
	Qu5JhviEntVj3/Q3LHkzyVX18C5qhaQ8WyESGQxuDW4Fdgb9yZbuE+xgNEobRcZ7A9bU
	skBYGcF08jQIpwNfUmmeDApF4dSLli1Fgc6RY=
Received: by 10.227.208.81 with SMTP id gb17mr3089223wbb.26.1323969530322;
	Thu, 15 Dec 2011 09:18:50 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id d17sm10250400wbh.19.2011.12.15.09.18.48
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 15 Dec 2011 09:18:48 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: a01f1e2f654ea54bbf5d0a77b315b676cc494aa8
Message-Id: <a01f1e2f654ea54bbf5d.1323969513@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Thu, 15 Dec 2011 18:18:33 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH] blktap2: use HAVE_BYTESWAP_H and _BYTESWAP_H
 for uclibc compatibility
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1323969492 -3600
# Node ID a01f1e2f654ea54bbf5d0a77b315b676cc494aa8
# Parent  0051e09f73efea06f2f28c0ece57194e286daedc
blktap2: use HAVE_BYTESWAP_H and _BYTESWAP_H for uclibc compatibility

uclibc defines _BYTESWAP_H instead of HAVE_BYTESWAP_H in byteswap.h:

http://git.uclibc.org/uClibc/tree/include/byteswap.h

Without this fix, blktap2 doesn't compile under uclibc and throws the
following error:

gcc  -O1 -fno-omit-frame-pointer -m64 -g -fno-strict-aliasing
-std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement
-Wno-unused-but-set-variable   -D__XEN_TOOLS__ -MMD -MF
.block-qcow.o.d  -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE
-fno-optimize-sibling-calls -Werror -g -O0 -Wno-unused
-fno-strict-aliasing -I../include -I../drivers
-I/root/xen-unstable/tools/blktap2/drivers/../../../tools/libxc
-I/root/xen-unstable/tools/blktap2/drivers/../../../tools/include -I
/root/xen-unstable/tools/blktap2/drivers/../../../tools/memshr
-D_GNU_SOURCE -DUSE_NFS_LOCKS -fPIC -I
/root/xen-unstable/tools/blktap2/drivers/../../../tools/libaio/src  -c
-o block-qcow.o block-qcow.c  -I/usr/local/include
In file included from block-qcow.c:37:0:
bswap.h:23:0: error: "bswap_16" redefined [-Werror]
/usr/include/byteswap.h:30:0: note: this is the location of the
previous definition
bswap.h:31:0: error: "bswap_32" redefined [-Werror]
/usr/include/byteswap.h:33:0: note: this is the location of the
previous definition
bswap.h:41:0: error: "bswap_64" redefined [-Werror]
/usr/include/byteswap.h:37:0: note: this is the location of the
previous definition
cc1: all warnings being treated as errors

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 0051e09f73ef -r a01f1e2f654e tools/blktap2/drivers/bswap.h
--- a/tools/blktap2/drivers/bswap.h	Thu Dec 15 10:00:09 2011 +0100
+++ b/tools/blktap2/drivers/bswap.h	Thu Dec 15 18:18:12 2011 +0100
@@ -15,7 +15,7 @@
 #define bswap_64(x) swap64(x)
 #else
 
-#ifdef HAVE_BYTESWAP_H
+#if defined(HAVE_BYTESWAP_H) || defined(_BYTESWAP_H)
 #include <byteswap.h>
 #else
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 17:24:19 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 17: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.xensource.com>)
	id 1RbF2N-00018M-EX; Thu, 15 Dec 2011 17:24:07 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RbF2M-000188-Kn
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 17:24:06 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1323969840!7610283!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjI2MA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13995 invoked from network); 15 Dec 2011 17:24:00 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 17:24:00 -0000
X-IronPort-AV: E=Sophos;i="4.71,357,1320624000"; 
   d="scan'208";a="9498148"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Dec 2011 17:23:46 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 15 Dec 2011 17:23:46 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Thu, 15 Dec 2011 17:23:46 +0000
In-Reply-To: <20202.10428.248647.957239@mariner.uk.xensource.com>
References: <patchbomb.1323793468@cosworth.uk.xensource.com>
	<e0f020d3d812e00aeb0c.1323793470@cosworth.uk.xensource.com>
	<1323796265.20077.341.camel@zakaz.uk.xensource.com>
	<1323796707.20077.346.camel@zakaz.uk.xensource.com>
	<20202.10428.248647.957239@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323969826.20077.508.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 2 of 3] libxl: split libxl_domain_shutdown
 into libxl_domain_shutdown & libxl_domain_reboot
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2011-12-15 at 17:05 +0000, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [PATCH 2 of 3] libxl: split libxl_domain_shutdown into libxl_domain_shutdown & libxl_domain_reboot"):
> > libxl: split libxl_domain_shutdown into libxl_domain_shutdown & libxl_domain_reboot
> > 
> > The other integer request types which shutdown supported are not useful. Specifically:
> > 
> >  * "suspend" is not usable via this interface since it requires other
> >    scaffolding, libxl_domain_suspend provides this already.
> >  * "halt" is the same as "poweroff".
> >  * "crash" is unused and at least Linux does not implement it. If a user
> >    steps forward then libxl_domain_crash is trivial to add.
> 
> The effect of this is to duplicate 25 lines of code.

Ye, I should have rethought this after I pulled the fallback handling
out of the library into xl (originally the two function had different
fallbacks). I'll rework it.

Ian.

> 
> If you really think we should split these into separate functions,
> rather than just sorting out the faux-enum, the separate functions
> probably want to turn out to be something like:
> 
>     int libxl_domain_reboot(libxl_ctx *ctx, uint32_t domid)
>     {
>         return libxl__domain_pvcontrol(ctx, domid, "reboot");
>     }
> 
> Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 17:24:19 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 17: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.xensource.com>)
	id 1RbF2N-00018M-EX; Thu, 15 Dec 2011 17:24:07 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RbF2M-000188-Kn
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 17:24:06 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1323969840!7610283!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjI2MA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13995 invoked from network); 15 Dec 2011 17:24:00 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 17:24:00 -0000
X-IronPort-AV: E=Sophos;i="4.71,357,1320624000"; 
   d="scan'208";a="9498148"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Dec 2011 17:23:46 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 15 Dec 2011 17:23:46 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Thu, 15 Dec 2011 17:23:46 +0000
In-Reply-To: <20202.10428.248647.957239@mariner.uk.xensource.com>
References: <patchbomb.1323793468@cosworth.uk.xensource.com>
	<e0f020d3d812e00aeb0c.1323793470@cosworth.uk.xensource.com>
	<1323796265.20077.341.camel@zakaz.uk.xensource.com>
	<1323796707.20077.346.camel@zakaz.uk.xensource.com>
	<20202.10428.248647.957239@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1323969826.20077.508.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 2 of 3] libxl: split libxl_domain_shutdown
 into libxl_domain_shutdown & libxl_domain_reboot
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2011-12-15 at 17:05 +0000, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [PATCH 2 of 3] libxl: split libxl_domain_shutdown into libxl_domain_shutdown & libxl_domain_reboot"):
> > libxl: split libxl_domain_shutdown into libxl_domain_shutdown & libxl_domain_reboot
> > 
> > The other integer request types which shutdown supported are not useful. Specifically:
> > 
> >  * "suspend" is not usable via this interface since it requires other
> >    scaffolding, libxl_domain_suspend provides this already.
> >  * "halt" is the same as "poweroff".
> >  * "crash" is unused and at least Linux does not implement it. If a user
> >    steps forward then libxl_domain_crash is trivial to add.
> 
> The effect of this is to duplicate 25 lines of code.

Ye, I should have rethought this after I pulled the fallback handling
out of the library into xl (originally the two function had different
fallbacks). I'll rework it.

Ian.

> 
> If you really think we should split these into separate functions,
> rather than just sorting out the faux-enum, the separate functions
> probably want to turn out to be something like:
> 
>     int libxl_domain_reboot(libxl_ctx *ctx, uint32_t domid)
>     {
>         return libxl__domain_pvcontrol(ctx, domid, "reboot");
>     }
> 
> Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 17:26:05 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 17: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.xensource.com>)
	id 1RbF44-0001G4-V6; Thu, 15 Dec 2011 17:25:52 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RbF43-0001Fg-I7
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 17:25:51 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1323969944!7563652!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjI2MA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30284 invoked from network); 15 Dec 2011 17:25:45 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 17:25:45 -0000
X-IronPort-AV: E=Sophos;i="4.71,357,1320624000"; 
   d="scan'208";a="9498212"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Dec 2011 17:25:44 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 15 Dec 2011 17:25:44 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RbF3v-0007be-LL; Thu, 15 Dec 2011 17:25:43 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RbF3v-0003QU-KX;
	Thu, 15 Dec 2011 17:25:43 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20202.11671.623383.650259@mariner.uk.xensource.com>
Date: Thu, 15 Dec 2011 17:25:43 +0000
To: Paul Durrant <paul.durrant@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <972927dc84c7e22520f4.1323855072@cosworth.uk.xensource.com>
References: <patchbomb.1323855070@cosworth.uk.xensource.com>
	<972927dc84c7e22520f4.1323855072@cosworth.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 2 of 2] VM generation ID save/restore and
	migrate
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Paul Durrant writes ("[Xen-devel] [PATCH 2 of 2] VM generation ID save/restore and migrate"):
> VM generation ID save/restore and migrate.
> 
> Add code to track the address of the VM generation ID buffer across a
> save/restore or migrate, and increment it as necessary.
> The address of the buffer is written into xenstore by hvmloader at
> boot time. It must be read from xenstore by the caller of
> xc_domain_save() and then written back again by the caller of
> xc_domain_restore().

You need to rewrap some of this now I'm afraid.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 17:26:05 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 17: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.xensource.com>)
	id 1RbF44-0001G4-V6; Thu, 15 Dec 2011 17:25:52 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RbF43-0001Fg-I7
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 17:25:51 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1323969944!7563652!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjI2MA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30284 invoked from network); 15 Dec 2011 17:25:45 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 17:25:45 -0000
X-IronPort-AV: E=Sophos;i="4.71,357,1320624000"; 
   d="scan'208";a="9498212"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Dec 2011 17:25:44 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 15 Dec 2011 17:25:44 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RbF3v-0007be-LL; Thu, 15 Dec 2011 17:25:43 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RbF3v-0003QU-KX;
	Thu, 15 Dec 2011 17:25:43 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20202.11671.623383.650259@mariner.uk.xensource.com>
Date: Thu, 15 Dec 2011 17:25:43 +0000
To: Paul Durrant <paul.durrant@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <972927dc84c7e22520f4.1323855072@cosworth.uk.xensource.com>
References: <patchbomb.1323855070@cosworth.uk.xensource.com>
	<972927dc84c7e22520f4.1323855072@cosworth.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 2 of 2] VM generation ID save/restore and
	migrate
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Paul Durrant writes ("[Xen-devel] [PATCH 2 of 2] VM generation ID save/restore and migrate"):
> VM generation ID save/restore and migrate.
> 
> Add code to track the address of the VM generation ID buffer across a
> save/restore or migrate, and increment it as necessary.
> The address of the buffer is written into xenstore by hvmloader at
> boot time. It must be read from xenstore by the caller of
> xc_domain_save() and then written back again by the caller of
> xc_domain_restore().

You need to rewrap some of this now I'm afraid.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 17:29:28 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 17: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.xensource.com>)
	id 1RbF7G-0001Sv-LF; Thu, 15 Dec 2011 17:29:10 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RbF7F-0001Sn-95
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 17:29:09 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1323970098!57471648!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjI2MA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5366 invoked from network); 15 Dec 2011 17:28:18 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 17:28:18 -0000
X-IronPort-AV: E=Sophos;i="4.71,357,1320624000"; 
   d="scan'208";a="9498301"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Dec 2011 17:28:55 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 15 Dec 2011 17:28:56 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RbF71-0007ck-Hb; Thu, 15 Dec 2011 17:28:55 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RbF71-0003Qv-Gk;
	Thu, 15 Dec 2011 17:28:55 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20202.11863.501987.497546@mariner.uk.xensource.com>
Date: Thu, 15 Dec 2011 17:28:55 +0000
To: Roger Pau Monne <roger.pau@entel.upc.edu>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <3bac38f7a427af3eb9f6.1323871739@loki.upc.es>
References: <3bac38f7a427af3eb9f6.1323871739@loki.upc.es>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH v2] xenpaging: remove _XOPEN_SOURCE
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Roger Pau Monne writes ("[Xen-devel] [PATCH v2] xenpaging: remove _XOPEN_SOURCE"):
> xenpaging: remove _XOPEN_SOURCE
> 
> The _XOPEN_SOURCE define was breaking the compilation under NetBSD.
> I've removed it becasue it is not necessary.

I thought we'd decided that _NETBSD_SOURCE should be added ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 17:29:28 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 17: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.xensource.com>)
	id 1RbF7G-0001Sv-LF; Thu, 15 Dec 2011 17:29:10 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RbF7F-0001Sn-95
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 17:29:09 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1323970098!57471648!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjI2MA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5366 invoked from network); 15 Dec 2011 17:28:18 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 17:28:18 -0000
X-IronPort-AV: E=Sophos;i="4.71,357,1320624000"; 
   d="scan'208";a="9498301"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Dec 2011 17:28:55 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 15 Dec 2011 17:28:56 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RbF71-0007ck-Hb; Thu, 15 Dec 2011 17:28:55 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RbF71-0003Qv-Gk;
	Thu, 15 Dec 2011 17:28:55 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20202.11863.501987.497546@mariner.uk.xensource.com>
Date: Thu, 15 Dec 2011 17:28:55 +0000
To: Roger Pau Monne <roger.pau@entel.upc.edu>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <3bac38f7a427af3eb9f6.1323871739@loki.upc.es>
References: <3bac38f7a427af3eb9f6.1323871739@loki.upc.es>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH v2] xenpaging: remove _XOPEN_SOURCE
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Roger Pau Monne writes ("[Xen-devel] [PATCH v2] xenpaging: remove _XOPEN_SOURCE"):
> xenpaging: remove _XOPEN_SOURCE
> 
> The _XOPEN_SOURCE define was breaking the compilation under NetBSD.
> I've removed it becasue it is not necessary.

I thought we'd decided that _NETBSD_SOURCE should be added ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 17:34:26 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 17:34:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbFC2-0001iA-DW; Thu, 15 Dec 2011 17:34:06 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RbFC1-0001i3-5o
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 17:34:05 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1323970438!7593979!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjI2MA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18284 invoked from network); 15 Dec 2011 17:33:58 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 17:33:58 -0000
X-IronPort-AV: E=Sophos;i="4.71,357,1320624000"; 
   d="scan'208";a="9498384"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Dec 2011 17:33:33 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 15 Dec 2011 17:33:33 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RbFBV-0007eJ-Bz; Thu, 15 Dec 2011 17:33:33 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RbFBV-0003RJ-As;
	Thu, 15 Dec 2011 17:33:33 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20202.12141.174045.345822@mariner.uk.xensource.com>
Date: Thu, 15 Dec 2011 17:33:33 +0000
To: Wei Wang2 <wei.wang2@amd.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <201112141638.05345.wei.wang2@amd.com>
References: <201112141638.05345.wei.wang2@amd.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Anthony PERARD <anthony.perard@citrix.com>, xen-devel@lists.xensource.com,
	Keir Fraser <keir@xen.org>, qemu-devel@nongnu.org,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH] xen-qemu: register virtual iommu device on
	qemu	pci bus
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Wei Wang2 writes ("[Xen-devel] [PATCH] xen-qemu: register virtual iommu device on qemu pci bus"):
> Attached patch is for qemu to register iommu device on pci bus. Guest OS 
> requires this to access iommu pci config space in some cases.

Thanks for this submission.

However, we are trying to focus development on the new xen-supporting
upstream qemu branches.

This old qemu branch is basically dead.  We will have to give it
bugfixes and security fixes, it in parallel with the new trees, for a
long time (because old guests may need it).  So for that reason I
would really prefer not to add new features to it.

Would you be able to rebase your work on the upstream qemu ?  You will
need Anthony Perard's PCI passthrough series of course, and you will
also need to liase with qemu upstream (so I've CC'd their list) since
it will be their tree that you'll be targeting.

If there is a particular reason why this work should be in
qemu-xen-unstable then please do say.  I'm open to being persuaded.

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 17:34:26 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 17:34:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbFC2-0001iA-DW; Thu, 15 Dec 2011 17:34:06 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RbFC1-0001i3-5o
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 17:34:05 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1323970438!7593979!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjI2MA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18284 invoked from network); 15 Dec 2011 17:33:58 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 17:33:58 -0000
X-IronPort-AV: E=Sophos;i="4.71,357,1320624000"; 
   d="scan'208";a="9498384"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Dec 2011 17:33:33 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 15 Dec 2011 17:33:33 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RbFBV-0007eJ-Bz; Thu, 15 Dec 2011 17:33:33 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RbFBV-0003RJ-As;
	Thu, 15 Dec 2011 17:33:33 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20202.12141.174045.345822@mariner.uk.xensource.com>
Date: Thu, 15 Dec 2011 17:33:33 +0000
To: Wei Wang2 <wei.wang2@amd.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <201112141638.05345.wei.wang2@amd.com>
References: <201112141638.05345.wei.wang2@amd.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Anthony PERARD <anthony.perard@citrix.com>, xen-devel@lists.xensource.com,
	Keir Fraser <keir@xen.org>, qemu-devel@nongnu.org,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH] xen-qemu: register virtual iommu device on
	qemu	pci bus
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Wei Wang2 writes ("[Xen-devel] [PATCH] xen-qemu: register virtual iommu device on qemu pci bus"):
> Attached patch is for qemu to register iommu device on pci bus. Guest OS 
> requires this to access iommu pci config space in some cases.

Thanks for this submission.

However, we are trying to focus development on the new xen-supporting
upstream qemu branches.

This old qemu branch is basically dead.  We will have to give it
bugfixes and security fixes, it in parallel with the new trees, for a
long time (because old guests may need it).  So for that reason I
would really prefer not to add new features to it.

Would you be able to rebase your work on the upstream qemu ?  You will
need Anthony Perard's PCI passthrough series of course, and you will
also need to liase with qemu upstream (so I've CC'd their list) since
it will be their tree that you'll be targeting.

If there is a particular reason why this work should be in
qemu-xen-unstable then please do say.  I'm open to being persuaded.

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 17:34:47 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 17:34:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbFCR-0001kA-R1; Thu, 15 Dec 2011 17:34:31 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RbFCQ-0001jI-E3
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 17:34:30 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1323970461!7438951!1
X-Originating-IP: [209.85.210.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3370 invoked from network); 15 Dec 2011 17:34:23 -0000
Received: from mail-pz0-f43.google.com (HELO mail-pz0-f43.google.com)
	(209.85.210.43)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 17:34:23 -0000
Received: by daec6 with SMTP id c6so8235299dae.30
	for <xen-devel@lists.xensource.com>;
	Thu, 15 Dec 2011 09:34:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=UFgsh5FZiFiNyZNSYJNlHq/ZYArxwS7/hKWfRXm7Mf8=;
	b=jJhATuSNx/iiWuqKbw5EWA3an2iY23CGA0obG8qzo61B2gLLbMEiEdi7j8D3TkUaMJ
	s4BAMPFI1QxV8RwWHD8UozOmEr3qD3432iWUEqbGNvAzm0hPObcxolyMQuYSeRAAIRXK
	oAsfVJnhJ473zYwRLiEGzjElMO2afsB/VcI7E=
MIME-Version: 1.0
Received: by 10.68.74.105 with SMTP id s9mr11192026pbv.64.1323970461127; Thu,
	15 Dec 2011 09:34:21 -0800 (PST)
Received: by 10.142.47.17 with HTTP; Thu, 15 Dec 2011 09:34:21 -0800 (PST)
In-Reply-To: <20202.11863.501987.497546@mariner.uk.xensource.com>
References: <3bac38f7a427af3eb9f6.1323871739@loki.upc.es>
	<20202.11863.501987.497546@mariner.uk.xensource.com>
Date: Thu, 15 Dec 2011 18:34:21 +0100
X-Google-Sender-Auth: vzRgtMLIOFoly-UbaOnnHPM8Fpk
Message-ID: <CAPLaKK6sX634w+SV0DmsSFaYLoN+JOzLWovhR-b0MQR-iBSq6A@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: Olaf Hering <olaf@aepfle.de>, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH v2] xenpaging: remove _XOPEN_SOURCE
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

2011/12/15 Ian Jackson <Ian.Jackson@eu.citrix.com>:
> Roger Pau Monne writes ("[Xen-devel] [PATCH v2] xenpaging: remove _XOPEN_SOURCE"):
>> xenpaging: remove _XOPEN_SOURCE
>>
>> The _XOPEN_SOURCE define was breaking the compilation under NetBSD.
>> I've removed it becasue it is not necessary.
>
> I thought we'd decided that _NETBSD_SOURCE should be added ?

Olaf Hering acked the patch with the condition that I add the error
message, since you didn't say anything I through you where fine with
that. Should I send the patch with _NETBSD_SOURCE instead?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 17:34:47 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 17:34:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbFCR-0001kA-R1; Thu, 15 Dec 2011 17:34:31 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RbFCQ-0001jI-E3
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 17:34:30 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1323970461!7438951!1
X-Originating-IP: [209.85.210.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3370 invoked from network); 15 Dec 2011 17:34:23 -0000
Received: from mail-pz0-f43.google.com (HELO mail-pz0-f43.google.com)
	(209.85.210.43)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 17:34:23 -0000
Received: by daec6 with SMTP id c6so8235299dae.30
	for <xen-devel@lists.xensource.com>;
	Thu, 15 Dec 2011 09:34:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=UFgsh5FZiFiNyZNSYJNlHq/ZYArxwS7/hKWfRXm7Mf8=;
	b=jJhATuSNx/iiWuqKbw5EWA3an2iY23CGA0obG8qzo61B2gLLbMEiEdi7j8D3TkUaMJ
	s4BAMPFI1QxV8RwWHD8UozOmEr3qD3432iWUEqbGNvAzm0hPObcxolyMQuYSeRAAIRXK
	oAsfVJnhJ473zYwRLiEGzjElMO2afsB/VcI7E=
MIME-Version: 1.0
Received: by 10.68.74.105 with SMTP id s9mr11192026pbv.64.1323970461127; Thu,
	15 Dec 2011 09:34:21 -0800 (PST)
Received: by 10.142.47.17 with HTTP; Thu, 15 Dec 2011 09:34:21 -0800 (PST)
In-Reply-To: <20202.11863.501987.497546@mariner.uk.xensource.com>
References: <3bac38f7a427af3eb9f6.1323871739@loki.upc.es>
	<20202.11863.501987.497546@mariner.uk.xensource.com>
Date: Thu, 15 Dec 2011 18:34:21 +0100
X-Google-Sender-Auth: vzRgtMLIOFoly-UbaOnnHPM8Fpk
Message-ID: <CAPLaKK6sX634w+SV0DmsSFaYLoN+JOzLWovhR-b0MQR-iBSq6A@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: Olaf Hering <olaf@aepfle.de>, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH v2] xenpaging: remove _XOPEN_SOURCE
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

2011/12/15 Ian Jackson <Ian.Jackson@eu.citrix.com>:
> Roger Pau Monne writes ("[Xen-devel] [PATCH v2] xenpaging: remove _XOPEN_SOURCE"):
>> xenpaging: remove _XOPEN_SOURCE
>>
>> The _XOPEN_SOURCE define was breaking the compilation under NetBSD.
>> I've removed it becasue it is not necessary.
>
> I thought we'd decided that _NETBSD_SOURCE should be added ?

Olaf Hering acked the patch with the condition that I add the error
message, since you didn't say anything I through you where fine with
that. Should I send the patch with _NETBSD_SOURCE instead?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 17:38:20 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 17:38:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbFFt-000212-Gf; Thu, 15 Dec 2011 17:38:05 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RbFFr-00020Q-HE
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 17:38:03 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1323970677!5729482!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjI2MA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25313 invoked from network); 15 Dec 2011 17:37:57 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 17:37:57 -0000
X-IronPort-AV: E=Sophos;i="4.71,357,1320624000"; 
   d="scan'208";a="9498448"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Dec 2011 17:36:54 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 15 Dec 2011 17:36:54 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RbFEk-0007fa-DL; Thu, 15 Dec 2011 17:36:54 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RbFEk-0003Rn-CH;
	Thu, 15 Dec 2011 17:36:54 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20202.12342.345953.443312@mariner.uk.xensource.com>
Date: Thu, 15 Dec 2011 17:36:54 +0000
To: Roger Pau =?iso-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
In-Reply-To: <CAPLaKK6sX634w+SV0DmsSFaYLoN+JOzLWovhR-b0MQR-iBSq6A@mail.gmail.com>
References: <3bac38f7a427af3eb9f6.1323871739@loki.upc.es>
	<20202.11863.501987.497546@mariner.uk.xensource.com>
	<CAPLaKK6sX634w+SV0DmsSFaYLoN+JOzLWovhR-b0MQR-iBSq6A@mail.gmail.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Olaf Hering <olaf@aepfle.de>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH v2] xenpaging: remove _XOPEN_SOURCE
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============7735531843053127155=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============7735531843053127155==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit

Roger Pau Monné writes ("Re: [Xen-devel] [PATCH v2] xenpaging: remove _XOPEN_SOURCE"):
> Olaf Hering acked the patch with the condition that I add the error
> message, since you didn't say anything I through you where fine with
> that. Should I send the patch with _NETBSD_SOURCE instead?

Did you not see my message, copy below ?

Thanks,
Ian.

From: Ian Jackson <iwj@mariner.uk.xensource.com>
To: Roger Pau Monné <roger.pau@entel.upc.edu>
Cc: Laszlo Ersek <lersek@redhat.com>,
    "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
    Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH] xenpaging: remove XOPEN_SOURCE
Message-ID: <20199.26338.308105.913566@mariner.uk.xensource.com>
Date: Tue, 13 Dec 2011 14:53:22 +0000

Roger Pau Monné writes ("Re: [Xen-devel] [PATCH] xenpaging: remove XOPEN_SOURCE"):
> 2011/12/13 Laszlo Ersek <lersek@redhat.com>:
> > The stuff made visible by _GNU_SOURCE (with glibc) includes everything
> > _XOPEN_SOURCE makes visible [3]. [4] introduced it because of asprintf().
> 
> If it's not necessary I think it's best to remove the definition, to
> avoid having a lot of useless defines all over the code.

I disagree.  The purpose of these kind of macros is purely to allow
systems to claim standards-compliance and absence of namespace
pollution, by default.

The logical conclusion is that these kind of problems should be fixed
by adding more requests for platform-specific features, not removing
them.

In this case that would mean adding:
 #define _NETBSD_SOURCE

If the prevalance of these kind of macros is getting irritating they
can easily be moved into a common header file somewhere.

Ian.


--===============7735531843053127155==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============7735531843053127155==--

From xen-devel-bounces@lists.xensource.com Thu Dec 15 17:38:20 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 17:38:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbFFt-000212-Gf; Thu, 15 Dec 2011 17:38:05 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RbFFr-00020Q-HE
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 17:38:03 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1323970677!5729482!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjI2MA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25313 invoked from network); 15 Dec 2011 17:37:57 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 17:37:57 -0000
X-IronPort-AV: E=Sophos;i="4.71,357,1320624000"; 
   d="scan'208";a="9498448"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Dec 2011 17:36:54 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 15 Dec 2011 17:36:54 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RbFEk-0007fa-DL; Thu, 15 Dec 2011 17:36:54 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RbFEk-0003Rn-CH;
	Thu, 15 Dec 2011 17:36:54 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20202.12342.345953.443312@mariner.uk.xensource.com>
Date: Thu, 15 Dec 2011 17:36:54 +0000
To: Roger Pau =?iso-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
In-Reply-To: <CAPLaKK6sX634w+SV0DmsSFaYLoN+JOzLWovhR-b0MQR-iBSq6A@mail.gmail.com>
References: <3bac38f7a427af3eb9f6.1323871739@loki.upc.es>
	<20202.11863.501987.497546@mariner.uk.xensource.com>
	<CAPLaKK6sX634w+SV0DmsSFaYLoN+JOzLWovhR-b0MQR-iBSq6A@mail.gmail.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Olaf Hering <olaf@aepfle.de>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH v2] xenpaging: remove _XOPEN_SOURCE
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============7735531843053127155=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============7735531843053127155==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit

Roger Pau Monné writes ("Re: [Xen-devel] [PATCH v2] xenpaging: remove _XOPEN_SOURCE"):
> Olaf Hering acked the patch with the condition that I add the error
> message, since you didn't say anything I through you where fine with
> that. Should I send the patch with _NETBSD_SOURCE instead?

Did you not see my message, copy below ?

Thanks,
Ian.

From: Ian Jackson <iwj@mariner.uk.xensource.com>
To: Roger Pau Monné <roger.pau@entel.upc.edu>
Cc: Laszlo Ersek <lersek@redhat.com>,
    "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
    Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH] xenpaging: remove XOPEN_SOURCE
Message-ID: <20199.26338.308105.913566@mariner.uk.xensource.com>
Date: Tue, 13 Dec 2011 14:53:22 +0000

Roger Pau Monné writes ("Re: [Xen-devel] [PATCH] xenpaging: remove XOPEN_SOURCE"):
> 2011/12/13 Laszlo Ersek <lersek@redhat.com>:
> > The stuff made visible by _GNU_SOURCE (with glibc) includes everything
> > _XOPEN_SOURCE makes visible [3]. [4] introduced it because of asprintf().
> 
> If it's not necessary I think it's best to remove the definition, to
> avoid having a lot of useless defines all over the code.

I disagree.  The purpose of these kind of macros is purely to allow
systems to claim standards-compliance and absence of namespace
pollution, by default.

The logical conclusion is that these kind of problems should be fixed
by adding more requests for platform-specific features, not removing
them.

In this case that would mean adding:
 #define _NETBSD_SOURCE

If the prevalance of these kind of macros is getting irritating they
can easily be moved into a common header file somewhere.

Ian.


--===============7735531843053127155==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============7735531843053127155==--

From xen-devel-bounces@lists.xensource.com Thu Dec 15 17:38:38 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 17:38:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbFGF-00024X-UJ; Thu, 15 Dec 2011 17:38:27 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RbFGF-00023R-6z
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 17:38:27 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1323970700!7377830!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjI2MA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23126 invoked from network); 15 Dec 2011 17:38:21 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 17:38:21 -0000
X-IronPort-AV: E=Sophos;i="4.71,357,1320624000"; 
   d="scan'208";a="9498476"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Dec 2011 17:38:20 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 15 Dec 2011 17:38:20 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RbFG8-0007g6-AC; Thu, 15 Dec 2011 17:38:20 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RbFG8-0003S7-9P;
	Thu, 15 Dec 2011 17:38:20 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20202.12428.280036.892796@mariner.uk.xensource.com>
Date: Thu, 15 Dec 2011 17:38:20 +0000
To: Roger Pau Monne <roger.pau@entel.upc.edu>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <patchbomb.1323961634@loki.upc.es>
References: <patchbomb.1323961634@loki.upc.es>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 00 of 15 v5] libxl: add support for hotplug
 script calling from libxl
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Roger Pau Monne writes ("[Xen-devel] [PATCH 00 of 15 v5] libxl: add support for hotplug script calling from libxl"):
> This patch series adds support for hotplug script calling directly
> from libxl, instead of relying on xenbackendd. Also some patches
> contain general bug fixes.

Thanks for the resend.  I think I have already acked a number of these
patches.  But your resend has dropped (or, if you prefer to think of
it like that) not added my Acked-By lines.

Can you please try to keep track Acked-By in your series ?  That will
make it easier for us to see what we need to re-review.

If you can repost a subseries which I have already acked, I would be
inclined to apply them right away.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 17:38:38 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 17:38:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbFGF-00024X-UJ; Thu, 15 Dec 2011 17:38:27 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RbFGF-00023R-6z
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 17:38:27 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1323970700!7377830!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjI2MA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23126 invoked from network); 15 Dec 2011 17:38:21 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 17:38:21 -0000
X-IronPort-AV: E=Sophos;i="4.71,357,1320624000"; 
   d="scan'208";a="9498476"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Dec 2011 17:38:20 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 15 Dec 2011 17:38:20 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RbFG8-0007g6-AC; Thu, 15 Dec 2011 17:38:20 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RbFG8-0003S7-9P;
	Thu, 15 Dec 2011 17:38:20 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20202.12428.280036.892796@mariner.uk.xensource.com>
Date: Thu, 15 Dec 2011 17:38:20 +0000
To: Roger Pau Monne <roger.pau@entel.upc.edu>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <patchbomb.1323961634@loki.upc.es>
References: <patchbomb.1323961634@loki.upc.es>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 00 of 15 v5] libxl: add support for hotplug
 script calling from libxl
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Roger Pau Monne writes ("[Xen-devel] [PATCH 00 of 15 v5] libxl: add support for hotplug script calling from libxl"):
> This patch series adds support for hotplug script calling directly
> from libxl, instead of relying on xenbackendd. Also some patches
> contain general bug fixes.

Thanks for the resend.  I think I have already acked a number of these
patches.  But your resend has dropped (or, if you prefer to think of
it like that) not added my Acked-By lines.

Can you please try to keep track Acked-By in your series ?  That will
make it easier for us to see what we need to re-review.

If you can repost a subseries which I have already acked, I would be
inclined to apply them right away.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 17:40:43 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 17:40:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbFIG-0002Rw-Mt; Thu, 15 Dec 2011 17:40:32 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RbFIF-0002Ra-FG
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 17:40:31 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1323970808!59105828!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjI2MA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22557 invoked from network); 15 Dec 2011 17:40:08 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 17:40:08 -0000
X-IronPort-AV: E=Sophos;i="4.71,357,1320624000"; 
   d="scan'208";a="9498560"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Dec 2011 17:40:27 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 15 Dec 2011 17:40:27 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RbFIA-0007gx-RS; Thu, 15 Dec 2011 17:40:26 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RbFIA-0003SL-Qe;
	Thu, 15 Dec 2011 17:40:26 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20202.12554.813545.194259@mariner.uk.xensource.com>
Date: Thu, 15 Dec 2011 17:40:26 +0000
To: Paul Durrant <Paul.Durrant@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <291EDFCB1E9E224A99088639C4762022B598ED0F0B@LONPMAILBOX01.citrite.net>
References: <patchbomb.1323873459@cosworth.uk.xensource.com>
	<9618ee3b6896eb8202e7.1323873461@cosworth.uk.xensource.com>
	<20202.8040.720939.17273@mariner.uk.xensource.com>
	<291EDFCB1E9E224A99088639C4762022B598ED0F0B@LONPMAILBOX01.citrite.net>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 2 of 3] Re-name xenstore key used to save VM
 generation ID buffer address
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Paul Durrant writes ("Re: [Xen-devel] [PATCH 2 of 3] Re-name xenstore key used to save VM generation ID buffer address"):
> > -----Original Message-----
> > > -    xenstore_write("data/generation-id", addr);
> > > +    xenstore_write("hvmloader/generation-id-address", addr);
> > 
> > Will just making just this change to hvmloader not cause failures
> > without the corresponding patch to the toolstack to make that path
> > writeable ?
> > 
> 
> The xenstore-write will fail with EACCES but the failure is ignored so there should be no knock-on failure. Nothing consumes the key until the subsequent tools patch is applied, at which point the xenstore-write will work because the tools will have made the key writable.

Um, right.  OK, I guess.

Is fault-oblivious computing the usual approach inside hvmloader ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 17:40:43 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 17:40:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbFIG-0002Rw-Mt; Thu, 15 Dec 2011 17:40:32 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RbFIF-0002Ra-FG
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 17:40:31 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1323970808!59105828!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjI2MA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22557 invoked from network); 15 Dec 2011 17:40:08 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 17:40:08 -0000
X-IronPort-AV: E=Sophos;i="4.71,357,1320624000"; 
   d="scan'208";a="9498560"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Dec 2011 17:40:27 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 15 Dec 2011 17:40:27 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RbFIA-0007gx-RS; Thu, 15 Dec 2011 17:40:26 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RbFIA-0003SL-Qe;
	Thu, 15 Dec 2011 17:40:26 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20202.12554.813545.194259@mariner.uk.xensource.com>
Date: Thu, 15 Dec 2011 17:40:26 +0000
To: Paul Durrant <Paul.Durrant@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <291EDFCB1E9E224A99088639C4762022B598ED0F0B@LONPMAILBOX01.citrite.net>
References: <patchbomb.1323873459@cosworth.uk.xensource.com>
	<9618ee3b6896eb8202e7.1323873461@cosworth.uk.xensource.com>
	<20202.8040.720939.17273@mariner.uk.xensource.com>
	<291EDFCB1E9E224A99088639C4762022B598ED0F0B@LONPMAILBOX01.citrite.net>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 2 of 3] Re-name xenstore key used to save VM
 generation ID buffer address
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Paul Durrant writes ("Re: [Xen-devel] [PATCH 2 of 3] Re-name xenstore key used to save VM generation ID buffer address"):
> > -----Original Message-----
> > > -    xenstore_write("data/generation-id", addr);
> > > +    xenstore_write("hvmloader/generation-id-address", addr);
> > 
> > Will just making just this change to hvmloader not cause failures
> > without the corresponding patch to the toolstack to make that path
> > writeable ?
> > 
> 
> The xenstore-write will fail with EACCES but the failure is ignored so there should be no knock-on failure. Nothing consumes the key until the subsequent tools patch is applied, at which point the xenstore-write will work because the tools will have made the key writable.

Um, right.  OK, I guess.

Is fault-oblivious computing the usual approach inside hvmloader ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 17:41:24 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 17:41:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbFIv-0002ZI-5d; Thu, 15 Dec 2011 17:41:13 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RbFIt-0002Yb-Ex
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 17:41:11 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1323970837!45055908!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjI2MA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26823 invoked from network); 15 Dec 2011 17:40:37 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 17:40:37 -0000
X-IronPort-AV: E=Sophos;i="4.71,357,1320624000"; 
   d="scan'208";a="9498573"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Dec 2011 17:41:07 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 15 Dec 2011 17:41:07 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RbFIo-0007hB-TA; Thu, 15 Dec 2011 17:41:06 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RbFIo-0003SV-SU;
	Thu, 15 Dec 2011 17:41:06 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20202.12594.868837.448850@mariner.uk.xensource.com>
Date: Thu, 15 Dec 2011 17:41:06 +0000
To: Roger Pau =?iso-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
In-Reply-To: <CAPLaKK4n9izbZJ0gg+evw=dm39wHbsH4rS_jWEkL433CLk5bDQ@mail.gmail.com>
References: <3bac38f7a427af3eb9f6.1323871739@loki.upc.es>
	<20202.11863.501987.497546@mariner.uk.xensource.com>
	<CAPLaKK6sX634w+SV0DmsSFaYLoN+JOzLWovhR-b0MQR-iBSq6A@mail.gmail.com>
	<20202.12342.345953.443312@mariner.uk.xensource.com>
	<CAPLaKK4n9izbZJ0gg+evw=dm39wHbsH4rS_jWEkL433CLk5bDQ@mail.gmail.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Olaf Hering <olaf@aepfle.de>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH v2] xenpaging: remove _XOPEN_SOURCE
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Roger Pau Monn=E9 writes ("Re: [Xen-devel] [PATCH v2] xenpaging: remove _XO=
PEN_SOURCE"):
> 2011/12/15 Ian Jackson <Ian.Jackson@eu.citrix.com>:
> > Roger Pau Monn=E9 writes ("Re: [Xen-devel] [PATCH v2] xenpaging: remove=
 _XOPEN_SOURCE"):
> >> Olaf Hering acked the patch with the condition that I add the error
> >> message, since you didn't say anything I through you where fine with
> >> that. Should I send the patch with _NETBSD_SOURCE instead?
> >
> > Did you not see my message, copy below ?
> =

> Sorry I think I got them in the wrong order.

NP. It's quite possible that my message came after Olaf's, anyway.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 17:41:24 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 17:41:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbFIv-0002ZI-5d; Thu, 15 Dec 2011 17:41:13 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RbFIt-0002Yb-Ex
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 17:41:11 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1323970837!45055908!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjI2MA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26823 invoked from network); 15 Dec 2011 17:40:37 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 17:40:37 -0000
X-IronPort-AV: E=Sophos;i="4.71,357,1320624000"; 
   d="scan'208";a="9498573"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Dec 2011 17:41:07 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 15 Dec 2011 17:41:07 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RbFIo-0007hB-TA; Thu, 15 Dec 2011 17:41:06 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RbFIo-0003SV-SU;
	Thu, 15 Dec 2011 17:41:06 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20202.12594.868837.448850@mariner.uk.xensource.com>
Date: Thu, 15 Dec 2011 17:41:06 +0000
To: Roger Pau =?iso-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
In-Reply-To: <CAPLaKK4n9izbZJ0gg+evw=dm39wHbsH4rS_jWEkL433CLk5bDQ@mail.gmail.com>
References: <3bac38f7a427af3eb9f6.1323871739@loki.upc.es>
	<20202.11863.501987.497546@mariner.uk.xensource.com>
	<CAPLaKK6sX634w+SV0DmsSFaYLoN+JOzLWovhR-b0MQR-iBSq6A@mail.gmail.com>
	<20202.12342.345953.443312@mariner.uk.xensource.com>
	<CAPLaKK4n9izbZJ0gg+evw=dm39wHbsH4rS_jWEkL433CLk5bDQ@mail.gmail.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Olaf Hering <olaf@aepfle.de>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH v2] xenpaging: remove _XOPEN_SOURCE
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Roger Pau Monn=E9 writes ("Re: [Xen-devel] [PATCH v2] xenpaging: remove _XO=
PEN_SOURCE"):
> 2011/12/15 Ian Jackson <Ian.Jackson@eu.citrix.com>:
> > Roger Pau Monn=E9 writes ("Re: [Xen-devel] [PATCH v2] xenpaging: remove=
 _XOPEN_SOURCE"):
> >> Olaf Hering acked the patch with the condition that I add the error
> >> message, since you didn't say anything I through you where fine with
> >> that. Should I send the patch with _NETBSD_SOURCE instead?
> >
> > Did you not see my message, copy below ?
> =

> Sorry I think I got them in the wrong order.

NP. It's quite possible that my message came after Olaf's, anyway.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 17:42:30 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 17: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.xensource.com>)
	id 1RbFK2-0002jT-LG; Thu, 15 Dec 2011 17:42:22 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RbFK1-0002il-Qm
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 17:42:22 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1323970935!5729932!1
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5934 invoked from network); 15 Dec 2011 17:42:15 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 17:42:15 -0000
Received: by wgbds11 with SMTP id ds11so3774735wgb.24
	for <xen-devel@lists.xensource.com>;
	Thu, 15 Dec 2011 09:42:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:user-agent:date:from:to;
	bh=0Rwo26ewT2WjHrenztJ1Yi15wRaTiLWSw2m1jPDhZM4=;
	b=cVVdddJh7VVi5+UqhbGPZh8klEPf5/Hs7LvM/qb7KEqoeqmqwACxlC5xoUg/9CCsSB
	NUfEGS/BSBp+Z/PHz9IdbEtN2KkRD7B7Rj7p/6qcHdwyh9c+hvS+omU0e5UpHjIPcQE+
	gl5zazTdNWy7oNmWeghe/x4TSYvR2Q6+xGkwY=
Received: by 10.216.132.139 with SMTP id o11mr1814450wei.33.1323970935445;
	Thu, 15 Dec 2011 09:42:15 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id gd6sm10398594wbb.1.2011.12.15.09.42.13
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 15 Dec 2011 09:42:14 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 0051e09f73efea06f2f28c0ece57194e286daedc
Message-Id: <0051e09f73efea06f2f2.1323970917@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Thu, 15 Dec 2011 18:41:57 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH v3] xenpaging: remove _XOPEN_SOURCE
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1323939609 -3600
# Node ID 0051e09f73efea06f2f28c0ece57194e286daedc
# Parent  759f27054f543cd57e008db4031fb7353c88fc20
xenpaging: remove _XOPEN_SOURCE

The _XOPEN_SOURCE define was breaking the compilation under NetBSD.
I've removed it becasue it is not necessary.

Error message:

gcc  -O1 -fno-omit-frame-pointer -m64 -g -fno-strict-aliasing
-std=gnu99 -Wall -Wstrict-prototypes -Wno-unused-value
-Wdeclaration-after-statement   -D__XEN_TOOLS__ -MMD -MF
.xenpaging.o.d -fno-optimize-sibling-calls
-I/root/xen-04102011/tools/xenpaging/../../tools/libxc
-I/root/xen-04102011/tools/xenpaging/../../tools/include
-I/root/xen-04102011/tools/xenpaging/../../tools/xenstore
-I/root/xen-04102011/tools/xenpaging/../../tools/include -Werror
-Wno-unused -g  -c -o xenpaging.o xenpaging.c  -I/usr/xen42/include
-I/usr/include
cc1: warnings being treated as errors
xenpaging.c: In function 'xenpaging_init':
xenpaging.c:333: warning: implicit declaration of function 'asprintf'

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 759f27054f54 -r 0051e09f73ef tools/xenpaging/xenpaging.c
--- a/tools/xenpaging/xenpaging.c	Thu Dec 15 10:00:09 2011 +0100
+++ b/tools/xenpaging/xenpaging.c	Thu Dec 15 10:00:09 2011 +0100
@@ -18,7 +18,6 @@
  * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
  */
 
-#define _XOPEN_SOURCE	600
 #define _GNU_SOURCE
 
 #include <inttypes.h>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 17:42:30 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 17: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.xensource.com>)
	id 1RbFK2-0002jT-LG; Thu, 15 Dec 2011 17:42:22 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RbFK1-0002il-Qm
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 17:42:22 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1323970935!5729932!1
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5934 invoked from network); 15 Dec 2011 17:42:15 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 17:42:15 -0000
Received: by wgbds11 with SMTP id ds11so3774735wgb.24
	for <xen-devel@lists.xensource.com>;
	Thu, 15 Dec 2011 09:42:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:user-agent:date:from:to;
	bh=0Rwo26ewT2WjHrenztJ1Yi15wRaTiLWSw2m1jPDhZM4=;
	b=cVVdddJh7VVi5+UqhbGPZh8klEPf5/Hs7LvM/qb7KEqoeqmqwACxlC5xoUg/9CCsSB
	NUfEGS/BSBp+Z/PHz9IdbEtN2KkRD7B7Rj7p/6qcHdwyh9c+hvS+omU0e5UpHjIPcQE+
	gl5zazTdNWy7oNmWeghe/x4TSYvR2Q6+xGkwY=
Received: by 10.216.132.139 with SMTP id o11mr1814450wei.33.1323970935445;
	Thu, 15 Dec 2011 09:42:15 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id gd6sm10398594wbb.1.2011.12.15.09.42.13
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 15 Dec 2011 09:42:14 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 0051e09f73efea06f2f28c0ece57194e286daedc
Message-Id: <0051e09f73efea06f2f2.1323970917@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Thu, 15 Dec 2011 18:41:57 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH v3] xenpaging: remove _XOPEN_SOURCE
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1323939609 -3600
# Node ID 0051e09f73efea06f2f28c0ece57194e286daedc
# Parent  759f27054f543cd57e008db4031fb7353c88fc20
xenpaging: remove _XOPEN_SOURCE

The _XOPEN_SOURCE define was breaking the compilation under NetBSD.
I've removed it becasue it is not necessary.

Error message:

gcc  -O1 -fno-omit-frame-pointer -m64 -g -fno-strict-aliasing
-std=gnu99 -Wall -Wstrict-prototypes -Wno-unused-value
-Wdeclaration-after-statement   -D__XEN_TOOLS__ -MMD -MF
.xenpaging.o.d -fno-optimize-sibling-calls
-I/root/xen-04102011/tools/xenpaging/../../tools/libxc
-I/root/xen-04102011/tools/xenpaging/../../tools/include
-I/root/xen-04102011/tools/xenpaging/../../tools/xenstore
-I/root/xen-04102011/tools/xenpaging/../../tools/include -Werror
-Wno-unused -g  -c -o xenpaging.o xenpaging.c  -I/usr/xen42/include
-I/usr/include
cc1: warnings being treated as errors
xenpaging.c: In function 'xenpaging_init':
xenpaging.c:333: warning: implicit declaration of function 'asprintf'

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 759f27054f54 -r 0051e09f73ef tools/xenpaging/xenpaging.c
--- a/tools/xenpaging/xenpaging.c	Thu Dec 15 10:00:09 2011 +0100
+++ b/tools/xenpaging/xenpaging.c	Thu Dec 15 10:00:09 2011 +0100
@@ -18,7 +18,6 @@
  * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
  */
 
-#define _XOPEN_SOURCE	600
 #define _GNU_SOURCE
 
 #include <inttypes.h>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 17:44:47 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 17:44:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbFME-0002yO-7T; Thu, 15 Dec 2011 17:44:38 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RbFMD-0002xu-39
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 17:44:37 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1323971070!8971475!1
X-Originating-IP: [209.85.161.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9139 invoked from network); 15 Dec 2011 17:44:31 -0000
Received: from mail-fx0-f43.google.com (HELO mail-fx0-f43.google.com)
	(209.85.161.43)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 17:44:31 -0000
Received: by faap21 with SMTP id p21so5725907faa.30
	for <xen-devel@lists.xensource.com>;
	Thu, 15 Dec 2011 09:44:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:user-agent:date:from:to;
	bh=rV+uWWpOb+Xyq2ybgKBfcIRrGifUWADx6At+ce7WhI4=;
	b=qI3LBVpk8j8B/ISW/0lft9kMhywc5GGBLZcg/prByXTJvNE5Y5pCG/DCh1xxv/puO2
	nChgep3DrOqvVoZcnHZp8OkmRy983aHpCiNcQFlCLG3jKURVWAOI1V4W6e55rlvNGbpc
	5CjgcccQbH1/smiCrNp/5+yy1WYUHM+erBYlU=
Received: by 10.180.88.106 with SMTP id bf10mr7029901wib.25.1323971070511;
	Thu, 15 Dec 2011 09:44:30 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id bs13sm9263719wib.21.2011.12.15.09.44.28
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 15 Dec 2011 09:44:29 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: bdf7e5b3ac350835f172511117dad1fe33606bdf
Message-Id: <bdf7e5b3ac350835f172.1323971049@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Thu, 15 Dec 2011 18:44:09 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH v4] xenpaging: add _NETBSD_SOURCE
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1323971037 -3600
# Node ID bdf7e5b3ac350835f172511117dad1fe33606bdf
# Parent  759f27054f543cd57e008db4031fb7353c88fc20
xenpaging: add _NETBSD_SOURCE

The _XOPEN_SOURCE define was breaking the compilation under NetBSD.
Added _NETBSD_SOURCE to maintain compatibility.

Error message:

gcc  -O1 -fno-omit-frame-pointer -m64 -g -fno-strict-aliasing
-std=gnu99 -Wall -Wstrict-prototypes -Wno-unused-value
-Wdeclaration-after-statement   -D__XEN_TOOLS__ -MMD -MF
.xenpaging.o.d -fno-optimize-sibling-calls
-I/root/xen-04102011/tools/xenpaging/../../tools/libxc
-I/root/xen-04102011/tools/xenpaging/../../tools/include
-I/root/xen-04102011/tools/xenpaging/../../tools/xenstore
-I/root/xen-04102011/tools/xenpaging/../../tools/include -Werror
-Wno-unused -g  -c -o xenpaging.o xenpaging.c  -I/usr/xen42/include
-I/usr/include
cc1: warnings being treated as errors
xenpaging.c: In function 'xenpaging_init':
xenpaging.c:333: warning: implicit declaration of function 'asprintf'

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 759f27054f54 -r bdf7e5b3ac35 tools/xenpaging/xenpaging.c
--- a/tools/xenpaging/xenpaging.c	Thu Dec 15 10:00:09 2011 +0100
+++ b/tools/xenpaging/xenpaging.c	Thu Dec 15 18:43:57 2011 +0100
@@ -20,6 +20,7 @@
 
 #define _XOPEN_SOURCE	600
 #define _GNU_SOURCE
+#define _NETBSD_SOURCE
 
 #include <inttypes.h>
 #include <stdio.h>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 17:44:47 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 17:44:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbFME-0002yO-7T; Thu, 15 Dec 2011 17:44:38 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RbFMD-0002xu-39
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 17:44:37 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1323971070!8971475!1
X-Originating-IP: [209.85.161.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9139 invoked from network); 15 Dec 2011 17:44:31 -0000
Received: from mail-fx0-f43.google.com (HELO mail-fx0-f43.google.com)
	(209.85.161.43)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 17:44:31 -0000
Received: by faap21 with SMTP id p21so5725907faa.30
	for <xen-devel@lists.xensource.com>;
	Thu, 15 Dec 2011 09:44:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:user-agent:date:from:to;
	bh=rV+uWWpOb+Xyq2ybgKBfcIRrGifUWADx6At+ce7WhI4=;
	b=qI3LBVpk8j8B/ISW/0lft9kMhywc5GGBLZcg/prByXTJvNE5Y5pCG/DCh1xxv/puO2
	nChgep3DrOqvVoZcnHZp8OkmRy983aHpCiNcQFlCLG3jKURVWAOI1V4W6e55rlvNGbpc
	5CjgcccQbH1/smiCrNp/5+yy1WYUHM+erBYlU=
Received: by 10.180.88.106 with SMTP id bf10mr7029901wib.25.1323971070511;
	Thu, 15 Dec 2011 09:44:30 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id bs13sm9263719wib.21.2011.12.15.09.44.28
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 15 Dec 2011 09:44:29 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: bdf7e5b3ac350835f172511117dad1fe33606bdf
Message-Id: <bdf7e5b3ac350835f172.1323971049@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Thu, 15 Dec 2011 18:44:09 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH v4] xenpaging: add _NETBSD_SOURCE
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1323971037 -3600
# Node ID bdf7e5b3ac350835f172511117dad1fe33606bdf
# Parent  759f27054f543cd57e008db4031fb7353c88fc20
xenpaging: add _NETBSD_SOURCE

The _XOPEN_SOURCE define was breaking the compilation under NetBSD.
Added _NETBSD_SOURCE to maintain compatibility.

Error message:

gcc  -O1 -fno-omit-frame-pointer -m64 -g -fno-strict-aliasing
-std=gnu99 -Wall -Wstrict-prototypes -Wno-unused-value
-Wdeclaration-after-statement   -D__XEN_TOOLS__ -MMD -MF
.xenpaging.o.d -fno-optimize-sibling-calls
-I/root/xen-04102011/tools/xenpaging/../../tools/libxc
-I/root/xen-04102011/tools/xenpaging/../../tools/include
-I/root/xen-04102011/tools/xenpaging/../../tools/xenstore
-I/root/xen-04102011/tools/xenpaging/../../tools/include -Werror
-Wno-unused -g  -c -o xenpaging.o xenpaging.c  -I/usr/xen42/include
-I/usr/include
cc1: warnings being treated as errors
xenpaging.c: In function 'xenpaging_init':
xenpaging.c:333: warning: implicit declaration of function 'asprintf'

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 759f27054f54 -r bdf7e5b3ac35 tools/xenpaging/xenpaging.c
--- a/tools/xenpaging/xenpaging.c	Thu Dec 15 10:00:09 2011 +0100
+++ b/tools/xenpaging/xenpaging.c	Thu Dec 15 18:43:57 2011 +0100
@@ -20,6 +20,7 @@
 
 #define _XOPEN_SOURCE	600
 #define _GNU_SOURCE
+#define _NETBSD_SOURCE
 
 #include <inttypes.h>
 #include <stdio.h>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 17:45:15 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 17:45:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbFMh-00032C-L4; Thu, 15 Dec 2011 17:45:07 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RbFMf-00031Y-TN
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 17:45:06 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1323971099!5730194!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjI2MA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12658 invoked from network); 15 Dec 2011 17:45:00 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 17:45:00 -0000
X-IronPort-AV: E=Sophos;i="4.71,357,1320624000"; 
   d="scan'208";a="9498674"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Dec 2011 17:44:59 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 15 Dec 2011 17:44:59 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RbFMZ-0007iN-6G; Thu, 15 Dec 2011 17:44:59 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RbFMZ-0003Sq-5N;
	Thu, 15 Dec 2011 17:44:59 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20202.12827.152139.501847@mariner.uk.xensource.com>
Date: Thu, 15 Dec 2011 17:44:59 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1323865369.20077.412.camel@zakaz.uk.xensource.com>
References: <patchbomb.1323768375@loki.upc.es>
	<35c322e6020501447936.1323768387@loki.upc.es>
	<20199.26896.928532.781947@mariner.uk.xensource.com>
	<CAPLaKK6wqa+VAxgzLWudQ2C2kaoXww9KK3BQhU4fKmoCAMFCzQ@mail.gmail.com>
	<1323860097.20077.394.camel@zakaz.uk.xensource.com>
	<CAPLaKK7Wv2HeRbg5Ze=B8DFe=wbzq=V35s6WVFXqrynh0ikRTw@mail.gmail.com>
	<20200.36683.601224.172611@mariner.uk.xensource.com>
	<CAPLaKK5h2PJko6o4v3usJkfttfdFqp9L6DEnfs0YYSSBWS63Eg@mail.gmail.com>
	<1323865369.20077.412.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Roger Pau Monné <roger.pau@entel.upc.edu>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 12 of 14 v4] libxl: set frontend status to 6
 on domain destroy
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

I have been thinking about this whole area.

Originally my opinion was that the block and network setup scripts
(eg, setting up loopback devices or iscsi or bridging whatever) should
be executed directly by xl.  This naturally gives the best error
handling and makes logging easiest.

However, if we are serious about supporting driver domains, or indeed
any kind of backend not running in the same domain as libxl, then
something in the driver domain needs to be responsible for executing
these scripts (or equivalent).

The obvious way to communicate this information to the driver domain
is via xenstore.

What we should be discussing is exactly how the driver domain
translates that into script execution.  Currently on Linux this is
mostly done with udev, and AIUI on BSD using xenbackendd.

So sorry for leading this discussion in what I now think may be a
wrong direction.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 17:45:15 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 17:45:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbFMh-00032C-L4; Thu, 15 Dec 2011 17:45:07 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RbFMf-00031Y-TN
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 17:45:06 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1323971099!5730194!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjI2MA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12658 invoked from network); 15 Dec 2011 17:45:00 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 17:45:00 -0000
X-IronPort-AV: E=Sophos;i="4.71,357,1320624000"; 
   d="scan'208";a="9498674"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Dec 2011 17:44:59 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 15 Dec 2011 17:44:59 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RbFMZ-0007iN-6G; Thu, 15 Dec 2011 17:44:59 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RbFMZ-0003Sq-5N;
	Thu, 15 Dec 2011 17:44:59 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20202.12827.152139.501847@mariner.uk.xensource.com>
Date: Thu, 15 Dec 2011 17:44:59 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1323865369.20077.412.camel@zakaz.uk.xensource.com>
References: <patchbomb.1323768375@loki.upc.es>
	<35c322e6020501447936.1323768387@loki.upc.es>
	<20199.26896.928532.781947@mariner.uk.xensource.com>
	<CAPLaKK6wqa+VAxgzLWudQ2C2kaoXww9KK3BQhU4fKmoCAMFCzQ@mail.gmail.com>
	<1323860097.20077.394.camel@zakaz.uk.xensource.com>
	<CAPLaKK7Wv2HeRbg5Ze=B8DFe=wbzq=V35s6WVFXqrynh0ikRTw@mail.gmail.com>
	<20200.36683.601224.172611@mariner.uk.xensource.com>
	<CAPLaKK5h2PJko6o4v3usJkfttfdFqp9L6DEnfs0YYSSBWS63Eg@mail.gmail.com>
	<1323865369.20077.412.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Roger Pau Monné <roger.pau@entel.upc.edu>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 12 of 14 v4] libxl: set frontend status to 6
 on domain destroy
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

I have been thinking about this whole area.

Originally my opinion was that the block and network setup scripts
(eg, setting up loopback devices or iscsi or bridging whatever) should
be executed directly by xl.  This naturally gives the best error
handling and makes logging easiest.

However, if we are serious about supporting driver domains, or indeed
any kind of backend not running in the same domain as libxl, then
something in the driver domain needs to be responsible for executing
these scripts (or equivalent).

The obvious way to communicate this information to the driver domain
is via xenstore.

What we should be discussing is exactly how the driver domain
translates that into script execution.  Currently on Linux this is
mostly done with udev, and AIUI on BSD using xenbackendd.

So sorry for leading this discussion in what I now think may be a
wrong direction.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 17:48:07 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 17:48:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbFPU-0003KY-M2; Thu, 15 Dec 2011 17:48:00 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RbFPT-0003Jp-AA
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 17:47:59 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1323971241!45056782!1
X-Originating-IP: [209.85.160.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16937 invoked from network); 15 Dec 2011 17:47:23 -0000
Received: from mail-pw0-f43.google.com (HELO mail-pw0-f43.google.com)
	(209.85.160.43)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 17:47:23 -0000
Received: by pbbb11 with SMTP id b11so6692898pbb.30
	for <xen-devel@lists.xensource.com>;
	Thu, 15 Dec 2011 09:47:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=cj8EgtEU3bxD89o/tXsIQt5UrFiXflWPakL92/ubEqg=;
	b=FIhue2YVMGwPF2fS4PEqDa2xtsR7DNzYY2L009YGR0uH8KG1rnOm7Byiw/Up2XvX3u
	XgQ7ct/D6HLC17Qpzl9HrXz4x0TDLhLsaKkGm79X5r3FK8Q5Xa3R4gcnDPi3KiL6q1ob
	v+XwC5dkOtEt46fwODEI03Z5PyULhwk5V4u/k=
MIME-Version: 1.0
Received: by 10.68.211.225 with SMTP id nf1mr11086878pbc.47.1323970800327;
	Thu, 15 Dec 2011 09:40:00 -0800 (PST)
Received: by 10.142.47.17 with HTTP; Thu, 15 Dec 2011 09:40:00 -0800 (PST)
In-Reply-To: <20202.12342.345953.443312@mariner.uk.xensource.com>
References: <3bac38f7a427af3eb9f6.1323871739@loki.upc.es>
	<20202.11863.501987.497546@mariner.uk.xensource.com>
	<CAPLaKK6sX634w+SV0DmsSFaYLoN+JOzLWovhR-b0MQR-iBSq6A@mail.gmail.com>
	<20202.12342.345953.443312@mariner.uk.xensource.com>
Date: Thu, 15 Dec 2011 18:40:00 +0100
X-Google-Sender-Auth: kk8u5hZjGaDMNa33J5xEidzS-oc
Message-ID: <CAPLaKK4n9izbZJ0gg+evw=dm39wHbsH4rS_jWEkL433CLk5bDQ@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: Olaf Hering <olaf@aepfle.de>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH v2] xenpaging: remove _XOPEN_SOURCE
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

MjAxMS8xMi8xNSBJYW4gSmFja3NvbiA8SWFuLkphY2tzb25AZXUuY2l0cml4LmNvbT46Cj4gUm9n
ZXIgUGF1IE1vbm7DqSB3cml0ZXMgKCJSZTogW1hlbi1kZXZlbF0gW1BBVENIIHYyXSB4ZW5wYWdp
bmc6IHJlbW92ZSBfWE9QRU5fU09VUkNFIik6Cj4+IE9sYWYgSGVyaW5nIGFja2VkIHRoZSBwYXRj
aCB3aXRoIHRoZSBjb25kaXRpb24gdGhhdCBJIGFkZCB0aGUgZXJyb3IKPj4gbWVzc2FnZSwgc2lu
Y2UgeW91IGRpZG4ndCBzYXkgYW55dGhpbmcgSSB0aHJvdWdoIHlvdSB3aGVyZSBmaW5lIHdpdGgK
Pj4gdGhhdC4gU2hvdWxkIEkgc2VuZCB0aGUgcGF0Y2ggd2l0aCBfTkVUQlNEX1NPVVJDRSBpbnN0
ZWFkPwo+Cj4gRGlkIHlvdSBub3Qgc2VlIG15IG1lc3NhZ2UsIGNvcHkgYmVsb3cgPwoKU29ycnkg
SSB0aGluayBJIGdvdCB0aGVtIGluIHRoZSB3cm9uZyBvcmRlci4KCl9fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVu
LWRldmVsQGxpc3RzLnhlbnNvdXJjZS5jb20KaHR0cDovL2xpc3RzLnhlbnNvdXJjZS5jb20veGVu
LWRldmVsCg==

From xen-devel-bounces@lists.xensource.com Thu Dec 15 17:48:07 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 17:48:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbFPU-0003KY-M2; Thu, 15 Dec 2011 17:48:00 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RbFPT-0003Jp-AA
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 17:47:59 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1323971241!45056782!1
X-Originating-IP: [209.85.160.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16937 invoked from network); 15 Dec 2011 17:47:23 -0000
Received: from mail-pw0-f43.google.com (HELO mail-pw0-f43.google.com)
	(209.85.160.43)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 17:47:23 -0000
Received: by pbbb11 with SMTP id b11so6692898pbb.30
	for <xen-devel@lists.xensource.com>;
	Thu, 15 Dec 2011 09:47:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=cj8EgtEU3bxD89o/tXsIQt5UrFiXflWPakL92/ubEqg=;
	b=FIhue2YVMGwPF2fS4PEqDa2xtsR7DNzYY2L009YGR0uH8KG1rnOm7Byiw/Up2XvX3u
	XgQ7ct/D6HLC17Qpzl9HrXz4x0TDLhLsaKkGm79X5r3FK8Q5Xa3R4gcnDPi3KiL6q1ob
	v+XwC5dkOtEt46fwODEI03Z5PyULhwk5V4u/k=
MIME-Version: 1.0
Received: by 10.68.211.225 with SMTP id nf1mr11086878pbc.47.1323970800327;
	Thu, 15 Dec 2011 09:40:00 -0800 (PST)
Received: by 10.142.47.17 with HTTP; Thu, 15 Dec 2011 09:40:00 -0800 (PST)
In-Reply-To: <20202.12342.345953.443312@mariner.uk.xensource.com>
References: <3bac38f7a427af3eb9f6.1323871739@loki.upc.es>
	<20202.11863.501987.497546@mariner.uk.xensource.com>
	<CAPLaKK6sX634w+SV0DmsSFaYLoN+JOzLWovhR-b0MQR-iBSq6A@mail.gmail.com>
	<20202.12342.345953.443312@mariner.uk.xensource.com>
Date: Thu, 15 Dec 2011 18:40:00 +0100
X-Google-Sender-Auth: kk8u5hZjGaDMNa33J5xEidzS-oc
Message-ID: <CAPLaKK4n9izbZJ0gg+evw=dm39wHbsH4rS_jWEkL433CLk5bDQ@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: Olaf Hering <olaf@aepfle.de>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH v2] xenpaging: remove _XOPEN_SOURCE
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

MjAxMS8xMi8xNSBJYW4gSmFja3NvbiA8SWFuLkphY2tzb25AZXUuY2l0cml4LmNvbT46Cj4gUm9n
ZXIgUGF1IE1vbm7DqSB3cml0ZXMgKCJSZTogW1hlbi1kZXZlbF0gW1BBVENIIHYyXSB4ZW5wYWdp
bmc6IHJlbW92ZSBfWE9QRU5fU09VUkNFIik6Cj4+IE9sYWYgSGVyaW5nIGFja2VkIHRoZSBwYXRj
aCB3aXRoIHRoZSBjb25kaXRpb24gdGhhdCBJIGFkZCB0aGUgZXJyb3IKPj4gbWVzc2FnZSwgc2lu
Y2UgeW91IGRpZG4ndCBzYXkgYW55dGhpbmcgSSB0aHJvdWdoIHlvdSB3aGVyZSBmaW5lIHdpdGgK
Pj4gdGhhdC4gU2hvdWxkIEkgc2VuZCB0aGUgcGF0Y2ggd2l0aCBfTkVUQlNEX1NPVVJDRSBpbnN0
ZWFkPwo+Cj4gRGlkIHlvdSBub3Qgc2VlIG15IG1lc3NhZ2UsIGNvcHkgYmVsb3cgPwoKU29ycnkg
SSB0aGluayBJIGdvdCB0aGVtIGluIHRoZSB3cm9uZyBvcmRlci4KCl9fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVu
LWRldmVsQGxpc3RzLnhlbnNvdXJjZS5jb20KaHR0cDovL2xpc3RzLnhlbnNvdXJjZS5jb20veGVu
LWRldmVsCg==

From xen-devel-bounces@lists.xensource.com Thu Dec 15 17:48:08 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 17:48:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbFPT-0003KG-7m; Thu, 15 Dec 2011 17:47:59 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RbFPS-0003Jk-54
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 17:47:58 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1323971272!7642396!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjI2MA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16875 invoked from network); 15 Dec 2011 17:47:52 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 17:47:52 -0000
X-IronPort-AV: E=Sophos;i="4.71,357,1320624000"; 
   d="scan'208";a="9498721"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Dec 2011 17:47:52 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.161]) by
	LONPMAILMX01.citrite.net ([10.30.203.162]) with mapi; Thu, 15 Dec 2011
	17:47:52 +0000
From: Paul Durrant <Paul.Durrant@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Thu, 15 Dec 2011 17:47:50 +0000
Thread-Topic: [Xen-devel] [PATCH 2 of 2] VM generation ID save/restore and
	migrate
Thread-Index: Acy7TpOGekgSjW+jT2CHenJmLh3KiAAAvCFA
Message-ID: <291EDFCB1E9E224A99088639C4762022B598ED0F14@LONPMAILBOX01.citrite.net>
References: <patchbomb.1323855070@cosworth.uk.xensource.com>
	<972927dc84c7e22520f4.1323855072@cosworth.uk.xensource.com>
	<20202.11671.623383.650259@mariner.uk.xensource.com>
In-Reply-To: <20202.11671.623383.650259@mariner.uk.xensource.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 2 of 2] VM generation ID save/restore and
 migrate
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> -----Original Message-----
> From: Ian Jackson [mailto:Ian.Jackson@eu.citrix.com]
> Sent: 15 December 2011 17:26
> To: Paul Durrant
> Cc: xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] [PATCH 2 of 2] VM generation ID
> save/restore and migrate
> 
> Paul Durrant writes ("[Xen-devel] [PATCH 2 of 2] VM generation ID
> save/restore and migrate"):
> > VM generation ID save/restore and migrate.
> >
> > Add code to track the address of the VM generation ID buffer
> across a
> > save/restore or migrate, and increment it as necessary.
> > The address of the buffer is written into xenstore by hvmloader at
> > boot time. It must be read from xenstore by the caller of
> > xc_domain_save() and then written back again by the caller of
> > xc_domain_restore().
> 
> You need to rewrap some of this now I'm afraid.
> 

<sigh> OK, I'll post a new series.

  Paul

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 17:48:08 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 17:48:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbFPT-0003KG-7m; Thu, 15 Dec 2011 17:47:59 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RbFPS-0003Jk-54
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 17:47:58 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1323971272!7642396!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjI2MA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16875 invoked from network); 15 Dec 2011 17:47:52 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 17:47:52 -0000
X-IronPort-AV: E=Sophos;i="4.71,357,1320624000"; 
   d="scan'208";a="9498721"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Dec 2011 17:47:52 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.161]) by
	LONPMAILMX01.citrite.net ([10.30.203.162]) with mapi; Thu, 15 Dec 2011
	17:47:52 +0000
From: Paul Durrant <Paul.Durrant@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Thu, 15 Dec 2011 17:47:50 +0000
Thread-Topic: [Xen-devel] [PATCH 2 of 2] VM generation ID save/restore and
	migrate
Thread-Index: Acy7TpOGekgSjW+jT2CHenJmLh3KiAAAvCFA
Message-ID: <291EDFCB1E9E224A99088639C4762022B598ED0F14@LONPMAILBOX01.citrite.net>
References: <patchbomb.1323855070@cosworth.uk.xensource.com>
	<972927dc84c7e22520f4.1323855072@cosworth.uk.xensource.com>
	<20202.11671.623383.650259@mariner.uk.xensource.com>
In-Reply-To: <20202.11671.623383.650259@mariner.uk.xensource.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 2 of 2] VM generation ID save/restore and
 migrate
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> -----Original Message-----
> From: Ian Jackson [mailto:Ian.Jackson@eu.citrix.com]
> Sent: 15 December 2011 17:26
> To: Paul Durrant
> Cc: xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] [PATCH 2 of 2] VM generation ID
> save/restore and migrate
> 
> Paul Durrant writes ("[Xen-devel] [PATCH 2 of 2] VM generation ID
> save/restore and migrate"):
> > VM generation ID save/restore and migrate.
> >
> > Add code to track the address of the VM generation ID buffer
> across a
> > save/restore or migrate, and increment it as necessary.
> > The address of the buffer is written into xenstore by hvmloader at
> > boot time. It must be read from xenstore by the caller of
> > xc_domain_save() and then written back again by the caller of
> > xc_domain_restore().
> 
> You need to rewrap some of this now I'm afraid.
> 

<sigh> OK, I'll post a new series.

  Paul

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 17:52:30 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 17:52:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbFTi-0003eq-Gb; Thu, 15 Dec 2011 17:52:22 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Boris.Ostrovsky@amd.com>) id 1RbFTg-0003ee-CH
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 17:52:20 +0000
X-Env-Sender: Boris.Ostrovsky@amd.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1323971499!56878009!1
X-Originating-IP: [216.32.181.183]
X-SpamReason: No, hits=0.0 required=7.0 tests=UPPERCASE_25_50
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29337 invoked from network); 15 Dec 2011 17:51:40 -0000
Received: from ch1ehsobe003.messaging.microsoft.com (HELO
	ch1outboundpool.messaging.microsoft.com) (216.32.181.183)
	by server-9.tower-27.messagelabs.com with AES128-SHA encrypted SMTP;
	15 Dec 2011 17:51:40 -0000
Received: from mail14-ch1-R.bigfish.com (10.43.68.243) by
	CH1EHSOBE002.bigfish.com (10.43.70.52) with Microsoft SMTP Server id
	14.1.225.23; Thu, 15 Dec 2011 17:52:15 +0000
Received: from mail14-ch1 (localhost [127.0.0.1])	by mail14-ch1-R.bigfish.com
	(Postfix) with ESMTP id D8806340113;
	Thu, 15 Dec 2011 17:52:20 +0000 (UTC)
X-SpamScore: -6
X-BigFish: VPS-6(zz1432Nzz1202hzzz2dh668h839h)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
X-FB-SS: 13,
Received: from mail14-ch1 (localhost.localdomain [127.0.0.1]) by mail14-ch1
	(MessageSwitch) id 1323971540808924_7163;
	Thu, 15 Dec 2011 17:52:20 +0000 (UTC)
Received: from CH1EHSMHS017.bigfish.com (snatpool1.int.messaging.microsoft.com
	[10.43.68.248])	by mail14-ch1.bigfish.com (Postfix) with ESMTP id
	BFC8040042; Thu, 15 Dec 2011 17:52:20 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	CH1EHSMHS017.bigfish.com (10.43.70.17) with Microsoft SMTP Server id
	14.1.225.23; Thu, 15 Dec 2011 17:52:14 +0000
X-WSS-ID: 0LW9AYX-02-36J-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp02.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 224D1FCC00F;	Thu, 15 Dec 2011 11:52:09 -0600 (CST)
Received: from sausexhtp01.amd.com (163.181.3.165) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Thu, 15 Dec 2011 11:52:26 -0600
Received: from [10.234.222.67] (10.234.222.67) by sausexhtp01.amd.com
	(163.181.3.165) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 15 Dec 2011 11:52:10 -0600
Message-ID: <4EEA33CA.7030906@amd.com>
Date: Thu, 15 Dec 2011 12:52:10 -0500
From: Boris Ostrovsky <boris.ostrovsky@amd.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.23) Gecko/20110920 SUSE/3.1.15 Thunderbird/3.1.15
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <mailman.4490.1323956364.12970.xen-devel@lists.xensource.com>
In-Reply-To: <mailman.4490.1323956364.12970.xen-devel@lists.xensource.com>
X-OriginatorOrg: amd.com
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] x86/emulator: workaround for AMD erratum 573
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>--- a/xen/include/asm-x86/amd.h
> +++ b/xen/include/asm-x86/amd.h
> @@ -134,6 +134,12 @@
>       AMD_OSVW_ERRATUM(3, AMD_MODEL_RANGE(0x10, 0x2, 0x1, 0xff, 0xf),	\
>   		        AMD_MODEL_RANGE(0x12, 0x0, 0x0, 0x1, 0x0))
>
> +#define AMD_ERRATUM_573							\
> +    AMD_LEGACY_ERRATUM(AMD_MODEL_RANGE(0x0f, 0x0, 0x0, 0xff, 0xf),	\
> +                       AMD_MODEL_RANGE(0x10, 0x0, 0x0, 0xff, 0xf),	\
> +                       AMD_MODEL_RANGE(0x11, 0x0, 0x0, 0xff, 0xf),	\
> +                       AMD_MODEL_RANGE(0x12, 0x0, 0x0, 0xff, 0xf))

Families 0xf and 0x11 are not affected by erratum 573.

-boris


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 17:52:30 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 17:52:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbFTi-0003eq-Gb; Thu, 15 Dec 2011 17:52:22 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Boris.Ostrovsky@amd.com>) id 1RbFTg-0003ee-CH
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 17:52:20 +0000
X-Env-Sender: Boris.Ostrovsky@amd.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1323971499!56878009!1
X-Originating-IP: [216.32.181.183]
X-SpamReason: No, hits=0.0 required=7.0 tests=UPPERCASE_25_50
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29337 invoked from network); 15 Dec 2011 17:51:40 -0000
Received: from ch1ehsobe003.messaging.microsoft.com (HELO
	ch1outboundpool.messaging.microsoft.com) (216.32.181.183)
	by server-9.tower-27.messagelabs.com with AES128-SHA encrypted SMTP;
	15 Dec 2011 17:51:40 -0000
Received: from mail14-ch1-R.bigfish.com (10.43.68.243) by
	CH1EHSOBE002.bigfish.com (10.43.70.52) with Microsoft SMTP Server id
	14.1.225.23; Thu, 15 Dec 2011 17:52:15 +0000
Received: from mail14-ch1 (localhost [127.0.0.1])	by mail14-ch1-R.bigfish.com
	(Postfix) with ESMTP id D8806340113;
	Thu, 15 Dec 2011 17:52:20 +0000 (UTC)
X-SpamScore: -6
X-BigFish: VPS-6(zz1432Nzz1202hzzz2dh668h839h)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
X-FB-SS: 13,
Received: from mail14-ch1 (localhost.localdomain [127.0.0.1]) by mail14-ch1
	(MessageSwitch) id 1323971540808924_7163;
	Thu, 15 Dec 2011 17:52:20 +0000 (UTC)
Received: from CH1EHSMHS017.bigfish.com (snatpool1.int.messaging.microsoft.com
	[10.43.68.248])	by mail14-ch1.bigfish.com (Postfix) with ESMTP id
	BFC8040042; Thu, 15 Dec 2011 17:52:20 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	CH1EHSMHS017.bigfish.com (10.43.70.17) with Microsoft SMTP Server id
	14.1.225.23; Thu, 15 Dec 2011 17:52:14 +0000
X-WSS-ID: 0LW9AYX-02-36J-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp02.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 224D1FCC00F;	Thu, 15 Dec 2011 11:52:09 -0600 (CST)
Received: from sausexhtp01.amd.com (163.181.3.165) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Thu, 15 Dec 2011 11:52:26 -0600
Received: from [10.234.222.67] (10.234.222.67) by sausexhtp01.amd.com
	(163.181.3.165) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 15 Dec 2011 11:52:10 -0600
Message-ID: <4EEA33CA.7030906@amd.com>
Date: Thu, 15 Dec 2011 12:52:10 -0500
From: Boris Ostrovsky <boris.ostrovsky@amd.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.23) Gecko/20110920 SUSE/3.1.15 Thunderbird/3.1.15
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <mailman.4490.1323956364.12970.xen-devel@lists.xensource.com>
In-Reply-To: <mailman.4490.1323956364.12970.xen-devel@lists.xensource.com>
X-OriginatorOrg: amd.com
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] x86/emulator: workaround for AMD erratum 573
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>--- a/xen/include/asm-x86/amd.h
> +++ b/xen/include/asm-x86/amd.h
> @@ -134,6 +134,12 @@
>       AMD_OSVW_ERRATUM(3, AMD_MODEL_RANGE(0x10, 0x2, 0x1, 0xff, 0xf),	\
>   		        AMD_MODEL_RANGE(0x12, 0x0, 0x0, 0x1, 0x0))
>
> +#define AMD_ERRATUM_573							\
> +    AMD_LEGACY_ERRATUM(AMD_MODEL_RANGE(0x0f, 0x0, 0x0, 0xff, 0xf),	\
> +                       AMD_MODEL_RANGE(0x10, 0x0, 0x0, 0xff, 0xf),	\
> +                       AMD_MODEL_RANGE(0x11, 0x0, 0x0, 0xff, 0xf),	\
> +                       AMD_MODEL_RANGE(0x12, 0x0, 0x0, 0xff, 0xf))

Families 0xf and 0x11 are not affected by erratum 573.

-boris


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 17:59:28 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 17: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.xensource.com>)
	id 1RbFaQ-0003vc-ME; Thu, 15 Dec 2011 17:59:18 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RbFaO-0003vG-U3
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 17:59:17 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1323971913!46909778!2
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24897 invoked from network); 15 Dec 2011 17:58:35 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 17:58:35 -0000
Received: by mail-we0-f171.google.com with SMTP id g1so399137wer.30
	for <xen-devel@lists.xensource.com>;
	Thu, 15 Dec 2011 09:59:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=upUDO130ECQZ0NOSIm1jiIx32xp85x6APu9w+lieQD8=;
	b=QGCBH86dn9al18E06itEwGttjiw1Fn+ncUXiA//j0LY+nilpUWYRCpupndF/LvbrD+
	uu+xi7o5ItHTnoUWEEump9LKhk3dro82p5O9xYFWit77PRxBHoXjUThBrSllokjcx8G5
	SgJU8/pW2jDGEnC7x2AwebpJ+QAelq9saESvY=
Received: by 10.216.139.156 with SMTP id c28mr1357947wej.34.1323971955727;
	Thu, 15 Dec 2011 09:59:15 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id eg7sm9354086wib.8.2011.12.15.09.59.13
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 15 Dec 2011 09:59:14 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: f2274ad5e46301dcc4f3f24a06b1c5e394c61f55
Message-Id: <f2274ad5e46301dcc4f3.1323971895@loki.upc.es>
In-Reply-To: <patchbomb.1323971891@loki.upc.es>
References: <patchbomb.1323971891@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Thu, 15 Dec 2011 18:58:15 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 4 of 6 ACKED v5] libxl: fix incorrect log
 message in libxl_domain_destroy
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1323971746 -3600
# Node ID f2274ad5e46301dcc4f3f24a06b1c5e394c61f55
# Parent  27003c971acf4064b60de68de9e4caec588b5b7d
libxl: fix incorrect log message in libxl_domain_destroy

Fix a log message that was referring to libxl_devices_dispose instead
of libxl__devices_destroy.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

diff -r 27003c971acf -r f2274ad5e463 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Thu Dec 15 18:55:46 2011 +0100
+++ b/tools/libxl/libxl.c	Thu Dec 15 18:55:46 2011 +0100
@@ -773,7 +773,8 @@ int libxl_domain_destroy(libxl_ctx *ctx,
         libxl__qmp_cleanup(gc, domid);
     }
     if (libxl__devices_destroy(gc, domid, force) < 0)
-        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "libxl_devices_dispose failed for %d", domid);
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, 
+                   "libxl__devices_destroy failed for %d", domid);
 
     vm_path = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/vm", dom_path));
     if (vm_path)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 17:59:28 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 17: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.xensource.com>)
	id 1RbFaQ-0003vc-ME; Thu, 15 Dec 2011 17:59:18 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RbFaO-0003vG-U3
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 17:59:17 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1323971913!46909778!2
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24897 invoked from network); 15 Dec 2011 17:58:35 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 17:58:35 -0000
Received: by mail-we0-f171.google.com with SMTP id g1so399137wer.30
	for <xen-devel@lists.xensource.com>;
	Thu, 15 Dec 2011 09:59:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=upUDO130ECQZ0NOSIm1jiIx32xp85x6APu9w+lieQD8=;
	b=QGCBH86dn9al18E06itEwGttjiw1Fn+ncUXiA//j0LY+nilpUWYRCpupndF/LvbrD+
	uu+xi7o5ItHTnoUWEEump9LKhk3dro82p5O9xYFWit77PRxBHoXjUThBrSllokjcx8G5
	SgJU8/pW2jDGEnC7x2AwebpJ+QAelq9saESvY=
Received: by 10.216.139.156 with SMTP id c28mr1357947wej.34.1323971955727;
	Thu, 15 Dec 2011 09:59:15 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id eg7sm9354086wib.8.2011.12.15.09.59.13
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 15 Dec 2011 09:59:14 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: f2274ad5e46301dcc4f3f24a06b1c5e394c61f55
Message-Id: <f2274ad5e46301dcc4f3.1323971895@loki.upc.es>
In-Reply-To: <patchbomb.1323971891@loki.upc.es>
References: <patchbomb.1323971891@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Thu, 15 Dec 2011 18:58:15 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 4 of 6 ACKED v5] libxl: fix incorrect log
 message in libxl_domain_destroy
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1323971746 -3600
# Node ID f2274ad5e46301dcc4f3f24a06b1c5e394c61f55
# Parent  27003c971acf4064b60de68de9e4caec588b5b7d
libxl: fix incorrect log message in libxl_domain_destroy

Fix a log message that was referring to libxl_devices_dispose instead
of libxl__devices_destroy.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

diff -r 27003c971acf -r f2274ad5e463 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Thu Dec 15 18:55:46 2011 +0100
+++ b/tools/libxl/libxl.c	Thu Dec 15 18:55:46 2011 +0100
@@ -773,7 +773,8 @@ int libxl_domain_destroy(libxl_ctx *ctx,
         libxl__qmp_cleanup(gc, domid);
     }
     if (libxl__devices_destroy(gc, domid, force) < 0)
-        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "libxl_devices_dispose failed for %d", domid);
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, 
+                   "libxl__devices_destroy failed for %d", domid);
 
     vm_path = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/vm", dom_path));
     if (vm_path)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 17:59:28 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 17: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.xensource.com>)
	id 1RbFaN-0003v9-Tv; Thu, 15 Dec 2011 17:59:15 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RbFaN-0003v1-2J
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 17:59:15 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1323971913!46909778!1
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24833 invoked from network); 15 Dec 2011 17:58:33 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 17:58:33 -0000
Received: by werg1 with SMTP id g1so399137wer.30
	for <xen-devel@lists.xensource.com>;
	Thu, 15 Dec 2011 09:59:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=rP9gEItJzodNxF8TplPU2/gda5imMCuc/hqZLoVkWGU=;
	b=SeEX7QcMvYfFGZbRKwNb21skFCHyPyh6TrlcqWs2GuGXrrpzltUA/AZ6GNeczelLs5
	zTajtJVgaSNBOTvegRDVNrSxYGGNstbjTZ4gldKSSCCoSEbEVKmuuDkACjRJy7Ibrk+5
	WWc+B+2CueFoWgDRj5f+SEv+wZw+cOATnKa+k=
Received: by 10.216.139.140 with SMTP id c12mr1838107wej.26.1323971953560;
	Thu, 15 Dec 2011 09:59:13 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id eg7sm9354086wib.8.2011.12.15.09.59.11
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 15 Dec 2011 09:59:12 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 75e1660cd4c350105e45f15b2ecbcdd564f2a290
Message-Id: <75e1660cd4c350105e45.1323971894@loki.upc.es>
In-Reply-To: <patchbomb.1323971891@loki.upc.es>
References: <patchbomb.1323971891@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Thu, 15 Dec 2011 18:58:14 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 3 of 6 ACKED v5] hotplug: remove debug messages
 from NetBSD hotplug scripts
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1323971746 -3600
# Node ID 75e1660cd4c350105e45f15b2ecbcdd564f2a290
# Parent  f56b12b7e8d6979844639a88bb1c5118e498e096
hotplug: remove debug messages from NetBSD hotplug scripts

Remove unecessary debug messages from NetBSD hotplug scripts, left
error messages only.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

diff -r f56b12b7e8d6 -r 75e1660cd4c3 tools/hotplug/NetBSD/block
--- a/tools/hotplug/NetBSD/block	Fri Sep 30 14:38:55 2011 +0200
+++ b/tools/hotplug/NetBSD/block	Thu Dec 15 18:55:46 2011 +0100
@@ -69,14 +69,12 @@ 1)
 			if [ "$status" = "free" ] && \
 			    vnconfig /dev/${disk}d $xparams >/dev/null; then
 				device=/dev/${disk}d
-				echo vnconfig /dev/${disk}d $xparams
 				break	
 			fi
 		done
 		if [ x$device = x ] ; then
 			error "no available vnd device"
 		fi
-		echo xenstore-write $xpath/vnd $device
 		xenstore-write $xpath/vnd $device
 		;;
 	phy)
@@ -84,9 +82,7 @@ 1)
 		;;
 	esac
 	physical_device=$(stat -f '%r' "$device")
-	echo xenstore-write $xpath/physical-device $physical_device
 	xenstore-write $xpath/physical-device $physical_device
-	echo xenstore-write $xpath/hotplug-status connected
 	xenstore-write $xpath/hotplug-status connected
 	exit 0
 	;;
diff -r f56b12b7e8d6 -r 75e1660cd4c3 tools/hotplug/NetBSD/vif-bridge
--- a/tools/hotplug/NetBSD/vif-bridge	Fri Sep 30 14:38:55 2011 +0200
+++ b/tools/hotplug/NetBSD/vif-bridge	Thu Dec 15 18:55:46 2011 +0100
@@ -24,12 +24,9 @@ 1)
 	xfid=$(xenstore-read "$xpath/frontend-id")
 	xhandle=$(xenstore-read "$xpath/handle")
 	iface=$(xenstore-read "$xpath/vifname")
-	echo ifconfig $iface up
 	ifconfig $iface up
 	brconfig $xbridge add $iface
-	echo brconfig $xbridge add $iface
 	xenstore-write $xpath/hotplug-status connected
-	echo xenstore-write $xpath/hotplug-status connected
 	exit 0
 	;;
 *)
diff -r f56b12b7e8d6 -r 75e1660cd4c3 tools/hotplug/NetBSD/vif-ip
--- a/tools/hotplug/NetBSD/vif-ip	Fri Sep 30 14:38:55 2011 +0200
+++ b/tools/hotplug/NetBSD/vif-ip	Thu Dec 15 18:55:46 2011 +0100
@@ -24,10 +24,8 @@ 1)
 	xfid=$(xenstore-read "$xpath/frontend-id")
 	xhandle=$(xenstore-read "$xpath/handle")
 	iface=$(xenstore-read "$xpath/vifname")
-	echo ifconfig $iface $xip up
 	ifconfig $iface $xip up
 	xenstore-write $xpath/hotplug-status connected
-	echo xenstore-write $xpath/hotplug-status connected
 	exit 0
 	;;
 *)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 17:59:28 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 17: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.xensource.com>)
	id 1RbFaN-0003v9-Tv; Thu, 15 Dec 2011 17:59:15 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RbFaN-0003v1-2J
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 17:59:15 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1323971913!46909778!1
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24833 invoked from network); 15 Dec 2011 17:58:33 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 17:58:33 -0000
Received: by werg1 with SMTP id g1so399137wer.30
	for <xen-devel@lists.xensource.com>;
	Thu, 15 Dec 2011 09:59:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=rP9gEItJzodNxF8TplPU2/gda5imMCuc/hqZLoVkWGU=;
	b=SeEX7QcMvYfFGZbRKwNb21skFCHyPyh6TrlcqWs2GuGXrrpzltUA/AZ6GNeczelLs5
	zTajtJVgaSNBOTvegRDVNrSxYGGNstbjTZ4gldKSSCCoSEbEVKmuuDkACjRJy7Ibrk+5
	WWc+B+2CueFoWgDRj5f+SEv+wZw+cOATnKa+k=
Received: by 10.216.139.140 with SMTP id c12mr1838107wej.26.1323971953560;
	Thu, 15 Dec 2011 09:59:13 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id eg7sm9354086wib.8.2011.12.15.09.59.11
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 15 Dec 2011 09:59:12 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 75e1660cd4c350105e45f15b2ecbcdd564f2a290
Message-Id: <75e1660cd4c350105e45.1323971894@loki.upc.es>
In-Reply-To: <patchbomb.1323971891@loki.upc.es>
References: <patchbomb.1323971891@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Thu, 15 Dec 2011 18:58:14 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 3 of 6 ACKED v5] hotplug: remove debug messages
 from NetBSD hotplug scripts
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1323971746 -3600
# Node ID 75e1660cd4c350105e45f15b2ecbcdd564f2a290
# Parent  f56b12b7e8d6979844639a88bb1c5118e498e096
hotplug: remove debug messages from NetBSD hotplug scripts

Remove unecessary debug messages from NetBSD hotplug scripts, left
error messages only.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

diff -r f56b12b7e8d6 -r 75e1660cd4c3 tools/hotplug/NetBSD/block
--- a/tools/hotplug/NetBSD/block	Fri Sep 30 14:38:55 2011 +0200
+++ b/tools/hotplug/NetBSD/block	Thu Dec 15 18:55:46 2011 +0100
@@ -69,14 +69,12 @@ 1)
 			if [ "$status" = "free" ] && \
 			    vnconfig /dev/${disk}d $xparams >/dev/null; then
 				device=/dev/${disk}d
-				echo vnconfig /dev/${disk}d $xparams
 				break	
 			fi
 		done
 		if [ x$device = x ] ; then
 			error "no available vnd device"
 		fi
-		echo xenstore-write $xpath/vnd $device
 		xenstore-write $xpath/vnd $device
 		;;
 	phy)
@@ -84,9 +82,7 @@ 1)
 		;;
 	esac
 	physical_device=$(stat -f '%r' "$device")
-	echo xenstore-write $xpath/physical-device $physical_device
 	xenstore-write $xpath/physical-device $physical_device
-	echo xenstore-write $xpath/hotplug-status connected
 	xenstore-write $xpath/hotplug-status connected
 	exit 0
 	;;
diff -r f56b12b7e8d6 -r 75e1660cd4c3 tools/hotplug/NetBSD/vif-bridge
--- a/tools/hotplug/NetBSD/vif-bridge	Fri Sep 30 14:38:55 2011 +0200
+++ b/tools/hotplug/NetBSD/vif-bridge	Thu Dec 15 18:55:46 2011 +0100
@@ -24,12 +24,9 @@ 1)
 	xfid=$(xenstore-read "$xpath/frontend-id")
 	xhandle=$(xenstore-read "$xpath/handle")
 	iface=$(xenstore-read "$xpath/vifname")
-	echo ifconfig $iface up
 	ifconfig $iface up
 	brconfig $xbridge add $iface
-	echo brconfig $xbridge add $iface
 	xenstore-write $xpath/hotplug-status connected
-	echo xenstore-write $xpath/hotplug-status connected
 	exit 0
 	;;
 *)
diff -r f56b12b7e8d6 -r 75e1660cd4c3 tools/hotplug/NetBSD/vif-ip
--- a/tools/hotplug/NetBSD/vif-ip	Fri Sep 30 14:38:55 2011 +0200
+++ b/tools/hotplug/NetBSD/vif-ip	Thu Dec 15 18:55:46 2011 +0100
@@ -24,10 +24,8 @@ 1)
 	xfid=$(xenstore-read "$xpath/frontend-id")
 	xhandle=$(xenstore-read "$xpath/handle")
 	iface=$(xenstore-read "$xpath/vifname")
-	echo ifconfig $iface $xip up
 	ifconfig $iface $xip up
 	xenstore-write $xpath/hotplug-status connected
-	echo xenstore-write $xpath/hotplug-status connected
 	exit 0
 	;;
 *)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 17:59:28 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 17: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.xensource.com>)
	id 1RbFaS-0003w1-FB; Thu, 15 Dec 2011 17:59:20 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RbFaQ-0003v0-Sl
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 17:59:19 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1323971947!7439979!1
X-Originating-IP: [209.85.161.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18661 invoked from network); 15 Dec 2011 17:59:07 -0000
Received: from mail-fx0-f43.google.com (HELO mail-fx0-f43.google.com)
	(209.85.161.43)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 17:59:07 -0000
Received: by faap21 with SMTP id p21so5770467faa.30
	for <xen-devel@lists.xensource.com>;
	Thu, 15 Dec 2011 09:59:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:message-id:user-agent:date:from:to;
	bh=8bFEMWNM8efhPmt2f/8CA8ZADci5Y36C/eMtOhKstUM=;
	b=jI8RruKVbMXJNXDPHgyPQzFGvaPWtblj1Rakpw+xcN6+2oCE4k63i7Cg4H6KeZPDyd
	btjuDtCxKL39rySPGFZSXpC95gjoz0erG0+TmBJ7PXino2W1N6+x/ZU1Z51esbsR1kaQ
	xwbg/RsoNZlmCb5hR192teTs+Nbf10s0YzqU0=
Received: by 10.180.0.100 with SMTP id 4mr6846178wid.48.1323971947099;
	Thu, 15 Dec 2011 09:59:07 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id eg7sm9354086wib.8.2011.12.15.09.59.05
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 15 Dec 2011 09:59:06 -0800 (PST)
MIME-Version: 1.0
Message-Id: <patchbomb.1323971891@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Thu, 15 Dec 2011 18:58:11 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 0 of 6 ACKED v5] libxl: add support for hotplug
 script calling from libxl
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Previously acked patches from the series.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 17:59:28 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 17: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.xensource.com>)
	id 1RbFaS-0003w1-FB; Thu, 15 Dec 2011 17:59:20 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RbFaQ-0003v0-Sl
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 17:59:19 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1323971947!7439979!1
X-Originating-IP: [209.85.161.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18661 invoked from network); 15 Dec 2011 17:59:07 -0000
Received: from mail-fx0-f43.google.com (HELO mail-fx0-f43.google.com)
	(209.85.161.43)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 17:59:07 -0000
Received: by faap21 with SMTP id p21so5770467faa.30
	for <xen-devel@lists.xensource.com>;
	Thu, 15 Dec 2011 09:59:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:message-id:user-agent:date:from:to;
	bh=8bFEMWNM8efhPmt2f/8CA8ZADci5Y36C/eMtOhKstUM=;
	b=jI8RruKVbMXJNXDPHgyPQzFGvaPWtblj1Rakpw+xcN6+2oCE4k63i7Cg4H6KeZPDyd
	btjuDtCxKL39rySPGFZSXpC95gjoz0erG0+TmBJ7PXino2W1N6+x/ZU1Z51esbsR1kaQ
	xwbg/RsoNZlmCb5hR192teTs+Nbf10s0YzqU0=
Received: by 10.180.0.100 with SMTP id 4mr6846178wid.48.1323971947099;
	Thu, 15 Dec 2011 09:59:07 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id eg7sm9354086wib.8.2011.12.15.09.59.05
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 15 Dec 2011 09:59:06 -0800 (PST)
MIME-Version: 1.0
Message-Id: <patchbomb.1323971891@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Thu, 15 Dec 2011 18:58:11 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 0 of 6 ACKED v5] libxl: add support for hotplug
 script calling from libxl
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Previously acked patches from the series.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 17:59:28 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 17: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.xensource.com>)
	id 1RbFaQ-0003vV-AC; Thu, 15 Dec 2011 17:59:18 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RbFaO-0003uy-Hl
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 17:59:16 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1323971950!7441462!1
X-Originating-IP: [209.85.161.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5575 invoked from network); 15 Dec 2011 17:59:10 -0000
Received: from mail-fx0-f43.google.com (HELO mail-fx0-f43.google.com)
	(209.85.161.43)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 17:59:10 -0000
Received: by faap21 with SMTP id p21so5770561faa.30
	for <xen-devel@lists.xensource.com>;
	Thu, 15 Dec 2011 09:59:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=i1eMoySh11jQcd0zlB2WBgzb0/Cnt6/xhd2vADp+TsE=;
	b=Iay9CCenhtOPl4c79dpfRDB1J6ZlonAb1iZgvwHpIJpaHiAsKawdUcxboKZw694FIY
	q9jxypQWb2OWcgp4GOvs0tvAlthlpfd/kFrmDD5qNEXrgVSKxTBLeqRwaGKeo/sAFbWh
	hwP6H5n0818oWbQQJDm5OyjEyyl41pZLL0Uoo=
Received: by 10.180.90.6 with SMTP id bs6mr6749110wib.63.1323971949275;
	Thu, 15 Dec 2011 09:59:09 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id eg7sm9354086wib.8.2011.12.15.09.59.07
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 15 Dec 2011 09:59:08 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: c8de7762b28386a8867b305660673c11eb5cf512
Message-Id: <c8de7762b28386a8867b.1323971892@loki.upc.es>
In-Reply-To: <patchbomb.1323971891@loki.upc.es>
References: <patchbomb.1323971891@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Thu, 15 Dec 2011 18:58:12 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 1 of 6 ACKED v5] libxl: add support for image
	files for NetBSD
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1317386335 -7200
# Node ID c8de7762b28386a8867b305660673c11eb5cf512
# Parent  8e129474fc0ac87623ba814ea865326d45cb8436
libxl: add support for image files for NetBSD

Created a helper function to detect if the OS is capable of using
image files as phy backends. Create two OS specific files, and
changed the Makefile to choose the correct one at compile time.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

diff -r 8e129474fc0a -r c8de7762b283 tools/libxl/Makefile
--- a/tools/libxl/Makefile	Fri Sep 30 14:38:55 2011 +0200
+++ b/tools/libxl/Makefile	Fri Sep 30 14:38:55 2011 +0200
@@ -33,6 +33,15 @@ endif
 LIBXL_OBJS-$(CONFIG_X86) += libxl_cpuid.o
 LIBXL_OBJS-$(CONFIG_IA64) += libxl_nocpuid.o
 
+ifeq ($(CONFIG_NetBSD),y)
+LIBXL_OBJS-y += libxl_netbsd.o
+else ifeq ($(CONFIG_Linux),y)
+LIBXL_OBJS-y += libxl_linux.o
+else
+$(error Your Operating System is not supported by libxenlight, \
+please check libxl_linux.c and libxl_netbsd.c to see how to get it ported)
+endif
+
 LIBXL_LIBS += -lyajl
 
 LIBXL_OBJS = flexarray.o libxl.o libxl_create.o libxl_dm.o libxl_pci.o \
diff -r 8e129474fc0a -r c8de7762b283 tools/libxl/libxl_device.c
--- a/tools/libxl/libxl_device.c	Fri Sep 30 14:38:55 2011 +0200
+++ b/tools/libxl/libxl_device.c	Fri Sep 30 14:38:55 2011 +0200
@@ -137,15 +137,14 @@ static int disk_try_backend(disk_try_bac
               a->disk->format == LIBXL_DISK_FORMAT_EMPTY)) {
             goto bad_format;
         }
-        if (a->disk->format != LIBXL_DISK_FORMAT_EMPTY &&
-            !S_ISBLK(a->stab.st_mode)) {
-            LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Disk vdev=%s, backend phy"
-                       " unsuitable as phys path not a block device",
-                       a->disk->vdev);
-            return 0;
-        }
 
-        return backend;
+        if (libxl__try_phy_backend(a->stab.st_mode))
+            return backend;
+
+        LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Disk vdev=%s, backend phy"
+                   " unsuitable as phys path not a block device",
+                   a->disk->vdev);
+        return 0;
 
     case LIBXL_DISK_BACKEND_TAP:
         if (!libxl__blktap_enabled(a->gc)) {
diff -r 8e129474fc0a -r c8de7762b283 tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Fri Sep 30 14:38:55 2011 +0200
+++ b/tools/libxl/libxl_internal.h	Fri Sep 30 14:38:55 2011 +0200
@@ -271,6 +271,15 @@ _hidden int libxl__device_destroy(libxl_
 _hidden int libxl__devices_destroy(libxl__gc *gc, uint32_t domid, int force);
 _hidden int libxl__wait_for_backend(libxl__gc *gc, char *be_path, char *state);
 
+/*
+ * libxl__try_phy_backend - Check if there's support for the passed
+ * type of file using the PHY backend
+ * st_mode: mode_t of the file, as returned by stat function
+ *
+ * Returns 0 on success, and < 0 on error.
+ */
+_hidden int libxl__try_phy_backend(mode_t st_mode);
+
 /* from libxl_pci */
 
 _hidden int libxl__device_pci_add(libxl__gc *gc, uint32_t domid, libxl_device_pci *pcidev, int starting);
diff -r 8e129474fc0a -r c8de7762b283 tools/libxl/libxl_linux.c
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/tools/libxl/libxl_linux.c	Fri Sep 30 14:38:55 2011 +0200
@@ -0,0 +1,27 @@
+/*
+ * Copyright (C) 2011
+ * Author Roger Pau Monne <roger.pau@entel.upc.edu>
+ *
+ * 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 <sys/stat.h>
+
+#include "libxl_internal.h"
+ 
+int libxl__try_phy_backend(mode_t st_mode)
+{
+    if (!S_ISBLK(st_mode)) {
+        return 0;
+    }
+
+    return 1;
+}
diff -r 8e129474fc0a -r c8de7762b283 tools/libxl/libxl_netbsd.c
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/tools/libxl/libxl_netbsd.c	Fri Sep 30 14:38:55 2011 +0200
@@ -0,0 +1,26 @@
+/*
+ * Copyright (C) 2011
+ * Author Roger Pau Monne <roger.pau@entel.upc.edu>
+ *
+ * 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 <sys/stat.h>
+
+#include "libxl_internal.h"
+
+int libxl__try_phy_backend(mode_t st_mode)
+{
+    if (S_ISREG(st_mode) || S_ISBLK(st_mode))
+        return 1;
+
+    return 0;
+}

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 17:59:28 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 17: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.xensource.com>)
	id 1RbFaQ-0003vV-AC; Thu, 15 Dec 2011 17:59:18 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RbFaO-0003uy-Hl
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 17:59:16 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1323971950!7441462!1
X-Originating-IP: [209.85.161.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5575 invoked from network); 15 Dec 2011 17:59:10 -0000
Received: from mail-fx0-f43.google.com (HELO mail-fx0-f43.google.com)
	(209.85.161.43)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 17:59:10 -0000
Received: by faap21 with SMTP id p21so5770561faa.30
	for <xen-devel@lists.xensource.com>;
	Thu, 15 Dec 2011 09:59:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=i1eMoySh11jQcd0zlB2WBgzb0/Cnt6/xhd2vADp+TsE=;
	b=Iay9CCenhtOPl4c79dpfRDB1J6ZlonAb1iZgvwHpIJpaHiAsKawdUcxboKZw694FIY
	q9jxypQWb2OWcgp4GOvs0tvAlthlpfd/kFrmDD5qNEXrgVSKxTBLeqRwaGKeo/sAFbWh
	hwP6H5n0818oWbQQJDm5OyjEyyl41pZLL0Uoo=
Received: by 10.180.90.6 with SMTP id bs6mr6749110wib.63.1323971949275;
	Thu, 15 Dec 2011 09:59:09 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id eg7sm9354086wib.8.2011.12.15.09.59.07
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 15 Dec 2011 09:59:08 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: c8de7762b28386a8867b305660673c11eb5cf512
Message-Id: <c8de7762b28386a8867b.1323971892@loki.upc.es>
In-Reply-To: <patchbomb.1323971891@loki.upc.es>
References: <patchbomb.1323971891@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Thu, 15 Dec 2011 18:58:12 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 1 of 6 ACKED v5] libxl: add support for image
	files for NetBSD
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1317386335 -7200
# Node ID c8de7762b28386a8867b305660673c11eb5cf512
# Parent  8e129474fc0ac87623ba814ea865326d45cb8436
libxl: add support for image files for NetBSD

Created a helper function to detect if the OS is capable of using
image files as phy backends. Create two OS specific files, and
changed the Makefile to choose the correct one at compile time.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

diff -r 8e129474fc0a -r c8de7762b283 tools/libxl/Makefile
--- a/tools/libxl/Makefile	Fri Sep 30 14:38:55 2011 +0200
+++ b/tools/libxl/Makefile	Fri Sep 30 14:38:55 2011 +0200
@@ -33,6 +33,15 @@ endif
 LIBXL_OBJS-$(CONFIG_X86) += libxl_cpuid.o
 LIBXL_OBJS-$(CONFIG_IA64) += libxl_nocpuid.o
 
+ifeq ($(CONFIG_NetBSD),y)
+LIBXL_OBJS-y += libxl_netbsd.o
+else ifeq ($(CONFIG_Linux),y)
+LIBXL_OBJS-y += libxl_linux.o
+else
+$(error Your Operating System is not supported by libxenlight, \
+please check libxl_linux.c and libxl_netbsd.c to see how to get it ported)
+endif
+
 LIBXL_LIBS += -lyajl
 
 LIBXL_OBJS = flexarray.o libxl.o libxl_create.o libxl_dm.o libxl_pci.o \
diff -r 8e129474fc0a -r c8de7762b283 tools/libxl/libxl_device.c
--- a/tools/libxl/libxl_device.c	Fri Sep 30 14:38:55 2011 +0200
+++ b/tools/libxl/libxl_device.c	Fri Sep 30 14:38:55 2011 +0200
@@ -137,15 +137,14 @@ static int disk_try_backend(disk_try_bac
               a->disk->format == LIBXL_DISK_FORMAT_EMPTY)) {
             goto bad_format;
         }
-        if (a->disk->format != LIBXL_DISK_FORMAT_EMPTY &&
-            !S_ISBLK(a->stab.st_mode)) {
-            LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Disk vdev=%s, backend phy"
-                       " unsuitable as phys path not a block device",
-                       a->disk->vdev);
-            return 0;
-        }
 
-        return backend;
+        if (libxl__try_phy_backend(a->stab.st_mode))
+            return backend;
+
+        LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Disk vdev=%s, backend phy"
+                   " unsuitable as phys path not a block device",
+                   a->disk->vdev);
+        return 0;
 
     case LIBXL_DISK_BACKEND_TAP:
         if (!libxl__blktap_enabled(a->gc)) {
diff -r 8e129474fc0a -r c8de7762b283 tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Fri Sep 30 14:38:55 2011 +0200
+++ b/tools/libxl/libxl_internal.h	Fri Sep 30 14:38:55 2011 +0200
@@ -271,6 +271,15 @@ _hidden int libxl__device_destroy(libxl_
 _hidden int libxl__devices_destroy(libxl__gc *gc, uint32_t domid, int force);
 _hidden int libxl__wait_for_backend(libxl__gc *gc, char *be_path, char *state);
 
+/*
+ * libxl__try_phy_backend - Check if there's support for the passed
+ * type of file using the PHY backend
+ * st_mode: mode_t of the file, as returned by stat function
+ *
+ * Returns 0 on success, and < 0 on error.
+ */
+_hidden int libxl__try_phy_backend(mode_t st_mode);
+
 /* from libxl_pci */
 
 _hidden int libxl__device_pci_add(libxl__gc *gc, uint32_t domid, libxl_device_pci *pcidev, int starting);
diff -r 8e129474fc0a -r c8de7762b283 tools/libxl/libxl_linux.c
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/tools/libxl/libxl_linux.c	Fri Sep 30 14:38:55 2011 +0200
@@ -0,0 +1,27 @@
+/*
+ * Copyright (C) 2011
+ * Author Roger Pau Monne <roger.pau@entel.upc.edu>
+ *
+ * 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 <sys/stat.h>
+
+#include "libxl_internal.h"
+ 
+int libxl__try_phy_backend(mode_t st_mode)
+{
+    if (!S_ISBLK(st_mode)) {
+        return 0;
+    }
+
+    return 1;
+}
diff -r 8e129474fc0a -r c8de7762b283 tools/libxl/libxl_netbsd.c
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/tools/libxl/libxl_netbsd.c	Fri Sep 30 14:38:55 2011 +0200
@@ -0,0 +1,26 @@
+/*
+ * Copyright (C) 2011
+ * Author Roger Pau Monne <roger.pau@entel.upc.edu>
+ *
+ * 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 <sys/stat.h>
+
+#include "libxl_internal.h"
+
+int libxl__try_phy_backend(mode_t st_mode)
+{
+    if (S_ISREG(st_mode) || S_ISBLK(st_mode))
+        return 1;
+
+    return 0;
+}

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 17:59:29 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 17:59:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbFaR-0003vl-1u; Thu, 15 Dec 2011 17:59:19 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RbFaP-0003uz-RB
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 17:59:18 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1323971950!7441462!2
X-Originating-IP: [209.85.161.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5639 invoked from network); 15 Dec 2011 17:59:11 -0000
Received: from mail-fx0-f43.google.com (HELO mail-fx0-f43.google.com)
	(209.85.161.43)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 17:59:11 -0000
Received: by mail-fx0-f43.google.com with SMTP id p21so5770561faa.30
	for <xen-devel@lists.xensource.com>;
	Thu, 15 Dec 2011 09:59:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=K0JuaEYdyj7K0d45I/z7gGNbCwKQiq4LJMaQ3USrH84=;
	b=ZIJz1goI3KzUmdrw7m7BKaYdS0uNnSkBwi6WGEkvCp1j9Oeb46Z6isG14hCkscb6Mm
	Ysr7sor33nu7kwOoEWok+ayM0bzV7XdC4AJ1Gt29KEjSERdpjcxLUKtob4lrX0ZgXGw0
	s2PamgIijDfJrxXl8rQgRuMvqVj0FBEmKb41Y=
Received: by 10.180.102.74 with SMTP id fm10mr7093199wib.26.1323971951506;
	Thu, 15 Dec 2011 09:59:11 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id eg7sm9354086wib.8.2011.12.15.09.59.09
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 15 Dec 2011 09:59:10 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 492fa4832e68f6493e5f61b72e598c164572eb41
Message-Id: <492fa4832e68f6493e5f.1323971893@loki.upc.es>
In-Reply-To: <patchbomb.1323971891@loki.upc.es>
References: <patchbomb.1323971891@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Thu, 15 Dec 2011 18:58:13 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 2 of 6 ACKED v5] libxl: introduce
	libxl__wait_for_device_state
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1323971745 -3600
# Node ID 492fa4832e68f6493e5f61b72e598c164572eb41
# Parent  e428efb092ffdaab1eeee5c304fd5f3b824ad958
libxl: introduce libxl__wait_for_device_state

This is a generic function, that waits for xs watches to reach a
certain state and then executes the passed helper function. Removed
wait_for_dev_destroy and used this new function instead. This
function will also be used by future patches that need to wait for
the initialization of devices before executing hotplug scripts.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

diff -r e428efb092ff -r 492fa4832e68 tools/libxl/libxl_device.c
--- a/tools/libxl/libxl_device.c	Thu Dec 15 18:55:45 2011 +0100
+++ b/tools/libxl/libxl_device.c	Thu Dec 15 18:55:45 2011 +0100
@@ -369,7 +369,9 @@ int libxl__device_disk_dev_number(const 
  * Returns 0 if a device is removed, ERROR_* if an error
  * or timeout occurred.
  */
-static int wait_for_dev_destroy(libxl__gc *gc, struct timeval *tv)
+int libxl__wait_for_device_state(libxl__gc *gc, struct timeval *tv,
+                                 XenbusState state,
+                                 libxl__device_state_handler handler)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
     int nfds, rc;
@@ -394,17 +396,14 @@ start:
         default:
             l1 = xs_read_watch(ctx->xsh, &n);
             if (l1 != NULL) {
-                char *state = libxl__xs_read(gc, XBT_NULL,
+                char *sstate = libxl__xs_read(gc, XBT_NULL,
                                              l1[XS_WATCH_PATH]);
-                if (!state || atoi(state) == 6) {
-                    xs_unwatch(ctx->xsh, l1[0], l1[1]);
-                    xs_rm(ctx->xsh, XBT_NULL, l1[XS_WATCH_TOKEN]);
-                    LIBXL__LOG(ctx, LIBXL__LOG_DEBUG,
-                               "Destroyed device backend at %s",
-                               l1[XS_WATCH_TOKEN]);
-                    rc = 0;
+                if (!sstate || atoi(sstate) == state) {
+                    /* Call handler function if present */
+                    if (handler)
+                        rc = handler(gc, l1, sstate);
                 } else {
-                    /* State is not "disconnected", continue waiting... */
+                    /* State is different than expected, continue waiting... */
                     goto start;
                 }
                 free(l1);
@@ -417,6 +416,23 @@ start:
 }
 
 /*
+ * Handler function for device destruction to be passed to
+ * libxl__wait_for_device_state
+ */
+static int destroy_device(libxl__gc *gc, char **l1, char *state)
+{
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+
+    xs_unwatch(ctx->xsh, l1[0], l1[1]);
+    xs_rm(ctx->xsh, XBT_NULL, l1[XS_WATCH_TOKEN]);
+    LIBXL__LOG(ctx, LIBXL__LOG_DEBUG,
+               "Destroyed device backend at %s",
+               l1[XS_WATCH_TOKEN]);
+
+    return 0;
+}
+
+/*
  * Returns 0 (device already destroyed) or 1 (caller must
  * wait_for_dev_destroy) on success, ERROR_* on fail.
  */
@@ -457,7 +473,8 @@ retry_transaction:
         struct timeval tv;
         tv.tv_sec = LIBXL_DESTROY_TIMEOUT;
         tv.tv_usec = 0;
-        rc = wait_for_dev_destroy(gc, &tv);
+        rc = libxl__wait_for_device_state(gc, &tv, XenbusStateClosed,
+                                          destroy_device);
         if (rc < 0) /* an error or timeout occurred, clear watches */
             xs_unwatch(ctx->xsh, state_path, be_path);
         xs_rm(ctx->xsh, XBT_NULL, libxl__device_frontend_path(gc, dev));
@@ -565,7 +582,8 @@ int libxl__devices_destroy(libxl__gc *gc
         tv.tv_sec = LIBXL_DESTROY_TIMEOUT;
         tv.tv_usec = 0;
         while (n_watches > 0) {
-            if (wait_for_dev_destroy(gc, &tv) < 0) {
+            if (libxl__wait_for_device_state(gc, &tv, XenbusStateClosed,
+                                             destroy_device) < 0) {
                 /* function returned ERROR_* */
                 break;
             } else {
diff -r e428efb092ff -r 492fa4832e68 tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Thu Dec 15 18:55:45 2011 +0100
+++ b/tools/libxl/libxl_internal.h	Thu Dec 15 18:55:45 2011 +0100
@@ -24,11 +24,14 @@
 #include <stdlib.h>
 #include <string.h>
 #include <pthread.h>
+#include <sys/time.h>
 
 #include <xs.h>
 #include <xenctrl.h>
 #include "xentoollog.h"
 
+#include <xen/io/xenbus.h>
+
 #include "libxl.h"
 
 #if __GNUC__ > 3 || (__GNUC__ == 3 && __GNUC_MINOR__ >= 1)
@@ -271,6 +274,31 @@ _hidden int libxl__device_destroy(libxl_
 _hidden int libxl__devices_destroy(libxl__gc *gc, uint32_t domid, int force);
 _hidden int libxl__wait_for_backend(libxl__gc *gc, char *be_path, char *state);
 
+/* Handler for the libxl__wait_for_device_state callback */
+/*
+ * libxl__device_state_handler - Handler for the libxl__wait_for_device_state
+ * gc: allocation pool
+ * l1: array containing the path and token
+ * state: string that contains the state of the device
+ *
+ * Returns 0 on success, and < 0 on error.
+ */
+typedef int libxl__device_state_handler(libxl__gc *gc, char **l1, char *state);
+
+/*
+ * libxl__wait_for_device_state - waits a given time for a device to
+ * reach a given state
+ * gc: allocation pool
+ * tv: timeval struct containing the maximum time to wait
+ * state: state to wait for (check xen/io/xenbus.h)
+ * handler: callback function to execute when state is reached
+ *
+ * Returns 0 on success, and < 0 on error.
+ */
+_hidden int libxl__wait_for_device_state(libxl__gc *gc, struct timeval *tv,
+                                         XenbusState state,
+                                         libxl__device_state_handler handler);
+
 /*
  * libxl__try_phy_backend - Check if there's support for the passed
  * type of file using the PHY backend

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 17:59:29 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 17:59:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbFaR-0003vl-1u; Thu, 15 Dec 2011 17:59:19 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RbFaP-0003uz-RB
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 17:59:18 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1323971950!7441462!2
X-Originating-IP: [209.85.161.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5639 invoked from network); 15 Dec 2011 17:59:11 -0000
Received: from mail-fx0-f43.google.com (HELO mail-fx0-f43.google.com)
	(209.85.161.43)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 17:59:11 -0000
Received: by mail-fx0-f43.google.com with SMTP id p21so5770561faa.30
	for <xen-devel@lists.xensource.com>;
	Thu, 15 Dec 2011 09:59:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=K0JuaEYdyj7K0d45I/z7gGNbCwKQiq4LJMaQ3USrH84=;
	b=ZIJz1goI3KzUmdrw7m7BKaYdS0uNnSkBwi6WGEkvCp1j9Oeb46Z6isG14hCkscb6Mm
	Ysr7sor33nu7kwOoEWok+ayM0bzV7XdC4AJ1Gt29KEjSERdpjcxLUKtob4lrX0ZgXGw0
	s2PamgIijDfJrxXl8rQgRuMvqVj0FBEmKb41Y=
Received: by 10.180.102.74 with SMTP id fm10mr7093199wib.26.1323971951506;
	Thu, 15 Dec 2011 09:59:11 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id eg7sm9354086wib.8.2011.12.15.09.59.09
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 15 Dec 2011 09:59:10 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 492fa4832e68f6493e5f61b72e598c164572eb41
Message-Id: <492fa4832e68f6493e5f.1323971893@loki.upc.es>
In-Reply-To: <patchbomb.1323971891@loki.upc.es>
References: <patchbomb.1323971891@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Thu, 15 Dec 2011 18:58:13 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 2 of 6 ACKED v5] libxl: introduce
	libxl__wait_for_device_state
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1323971745 -3600
# Node ID 492fa4832e68f6493e5f61b72e598c164572eb41
# Parent  e428efb092ffdaab1eeee5c304fd5f3b824ad958
libxl: introduce libxl__wait_for_device_state

This is a generic function, that waits for xs watches to reach a
certain state and then executes the passed helper function. Removed
wait_for_dev_destroy and used this new function instead. This
function will also be used by future patches that need to wait for
the initialization of devices before executing hotplug scripts.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

diff -r e428efb092ff -r 492fa4832e68 tools/libxl/libxl_device.c
--- a/tools/libxl/libxl_device.c	Thu Dec 15 18:55:45 2011 +0100
+++ b/tools/libxl/libxl_device.c	Thu Dec 15 18:55:45 2011 +0100
@@ -369,7 +369,9 @@ int libxl__device_disk_dev_number(const 
  * Returns 0 if a device is removed, ERROR_* if an error
  * or timeout occurred.
  */
-static int wait_for_dev_destroy(libxl__gc *gc, struct timeval *tv)
+int libxl__wait_for_device_state(libxl__gc *gc, struct timeval *tv,
+                                 XenbusState state,
+                                 libxl__device_state_handler handler)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
     int nfds, rc;
@@ -394,17 +396,14 @@ start:
         default:
             l1 = xs_read_watch(ctx->xsh, &n);
             if (l1 != NULL) {
-                char *state = libxl__xs_read(gc, XBT_NULL,
+                char *sstate = libxl__xs_read(gc, XBT_NULL,
                                              l1[XS_WATCH_PATH]);
-                if (!state || atoi(state) == 6) {
-                    xs_unwatch(ctx->xsh, l1[0], l1[1]);
-                    xs_rm(ctx->xsh, XBT_NULL, l1[XS_WATCH_TOKEN]);
-                    LIBXL__LOG(ctx, LIBXL__LOG_DEBUG,
-                               "Destroyed device backend at %s",
-                               l1[XS_WATCH_TOKEN]);
-                    rc = 0;
+                if (!sstate || atoi(sstate) == state) {
+                    /* Call handler function if present */
+                    if (handler)
+                        rc = handler(gc, l1, sstate);
                 } else {
-                    /* State is not "disconnected", continue waiting... */
+                    /* State is different than expected, continue waiting... */
                     goto start;
                 }
                 free(l1);
@@ -417,6 +416,23 @@ start:
 }
 
 /*
+ * Handler function for device destruction to be passed to
+ * libxl__wait_for_device_state
+ */
+static int destroy_device(libxl__gc *gc, char **l1, char *state)
+{
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+
+    xs_unwatch(ctx->xsh, l1[0], l1[1]);
+    xs_rm(ctx->xsh, XBT_NULL, l1[XS_WATCH_TOKEN]);
+    LIBXL__LOG(ctx, LIBXL__LOG_DEBUG,
+               "Destroyed device backend at %s",
+               l1[XS_WATCH_TOKEN]);
+
+    return 0;
+}
+
+/*
  * Returns 0 (device already destroyed) or 1 (caller must
  * wait_for_dev_destroy) on success, ERROR_* on fail.
  */
@@ -457,7 +473,8 @@ retry_transaction:
         struct timeval tv;
         tv.tv_sec = LIBXL_DESTROY_TIMEOUT;
         tv.tv_usec = 0;
-        rc = wait_for_dev_destroy(gc, &tv);
+        rc = libxl__wait_for_device_state(gc, &tv, XenbusStateClosed,
+                                          destroy_device);
         if (rc < 0) /* an error or timeout occurred, clear watches */
             xs_unwatch(ctx->xsh, state_path, be_path);
         xs_rm(ctx->xsh, XBT_NULL, libxl__device_frontend_path(gc, dev));
@@ -565,7 +582,8 @@ int libxl__devices_destroy(libxl__gc *gc
         tv.tv_sec = LIBXL_DESTROY_TIMEOUT;
         tv.tv_usec = 0;
         while (n_watches > 0) {
-            if (wait_for_dev_destroy(gc, &tv) < 0) {
+            if (libxl__wait_for_device_state(gc, &tv, XenbusStateClosed,
+                                             destroy_device) < 0) {
                 /* function returned ERROR_* */
                 break;
             } else {
diff -r e428efb092ff -r 492fa4832e68 tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Thu Dec 15 18:55:45 2011 +0100
+++ b/tools/libxl/libxl_internal.h	Thu Dec 15 18:55:45 2011 +0100
@@ -24,11 +24,14 @@
 #include <stdlib.h>
 #include <string.h>
 #include <pthread.h>
+#include <sys/time.h>
 
 #include <xs.h>
 #include <xenctrl.h>
 #include "xentoollog.h"
 
+#include <xen/io/xenbus.h>
+
 #include "libxl.h"
 
 #if __GNUC__ > 3 || (__GNUC__ == 3 && __GNUC_MINOR__ >= 1)
@@ -271,6 +274,31 @@ _hidden int libxl__device_destroy(libxl_
 _hidden int libxl__devices_destroy(libxl__gc *gc, uint32_t domid, int force);
 _hidden int libxl__wait_for_backend(libxl__gc *gc, char *be_path, char *state);
 
+/* Handler for the libxl__wait_for_device_state callback */
+/*
+ * libxl__device_state_handler - Handler for the libxl__wait_for_device_state
+ * gc: allocation pool
+ * l1: array containing the path and token
+ * state: string that contains the state of the device
+ *
+ * Returns 0 on success, and < 0 on error.
+ */
+typedef int libxl__device_state_handler(libxl__gc *gc, char **l1, char *state);
+
+/*
+ * libxl__wait_for_device_state - waits a given time for a device to
+ * reach a given state
+ * gc: allocation pool
+ * tv: timeval struct containing the maximum time to wait
+ * state: state to wait for (check xen/io/xenbus.h)
+ * handler: callback function to execute when state is reached
+ *
+ * Returns 0 on success, and < 0 on error.
+ */
+_hidden int libxl__wait_for_device_state(libxl__gc *gc, struct timeval *tv,
+                                         XenbusState state,
+                                         libxl__device_state_handler handler);
+
 /*
  * libxl__try_phy_backend - Check if there's support for the passed
  * type of file using the PHY backend

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 17:59:31 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 17:59:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbFaX-0003xi-Sn; Thu, 15 Dec 2011 17:59:25 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RbFaW-0003vp-HP
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 17:59:24 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1323971958!6441143!1
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 904 invoked from network); 15 Dec 2011 17:59:18 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 17:59:18 -0000
Received: by wgbds11 with SMTP id ds11so3797047wgb.24
	for <xen-devel@lists.xensource.com>;
	Thu, 15 Dec 2011 09:59:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=1hkNoyhqw5n78TYUATtz/Wg53YnKvgJ4YijloCA5+Ek=;
	b=sdTGzogOzXnSC+uGmMJpptfDdEu91JWF9lH/bDFEx0UhjdPJ89+NWwSy8iA/HkttVh
	BVMG5PCKx50Tkzkc37mJt580CfBQuO0chI0Yud+64V6nKBNFiEMfXJdePjzapaDFKtEW
	vlXYzdX2jJd3KIPpciWAGqDfZSPWSRq+mlQmA=
Received: by 10.227.197.78 with SMTP id ej14mr3305707wbb.2.1323971957948;
	Thu, 15 Dec 2011 09:59:17 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id eg7sm9354086wib.8.2011.12.15.09.59.15
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 15 Dec 2011 09:59:16 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 1ab9421bf75c620fabb8d02c921a877a323c1a03
Message-Id: <1ab9421bf75c620fabb8.1323971896@loki.upc.es>
In-Reply-To: <patchbomb.1323971891@loki.upc.es>
References: <patchbomb.1323971891@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Thu, 15 Dec 2011 18:58:16 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 5 of 6 ACKED v5] libxl: remove force parameter
 from libxl_domain_destroy
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1323971746 -3600
# Node ID 1ab9421bf75c620fabb8d02c921a877a323c1a03
# Parent  e25ad5cc0963ca0a6d2b8efe2772afa77b4835c4
libxl: remove force parameter from libxl_domain_destroy

Since a destroy is considered a forced shutdown, there's no point in
passing a force parameter. All the occurences of this function have
been replaced with the proper syntax.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

diff -r e25ad5cc0963 -r 1ab9421bf75c tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Thu Dec 15 18:55:46 2011 +0100
+++ b/tools/libxl/libxl.c	Thu Dec 15 18:55:46 2011 +0100
@@ -723,7 +723,7 @@ int libxl_event_get_disk_eject_info(libx
     return 1;
 }
 
-int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid, int force)
+int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid)
 {
     GC_INIT(ctx);
     libxl_dominfo dominfo;
@@ -772,7 +772,7 @@ int libxl_domain_destroy(libxl_ctx *ctx,
 
         libxl__qmp_cleanup(gc, domid);
     }
-    if (libxl__devices_destroy(gc, domid, force) < 0)
+    if (libxl__devices_destroy(gc, domid, 1) < 0)
         LIBXL__LOG(ctx, LIBXL__LOG_ERROR, 
                    "libxl__devices_destroy failed for %d", domid);
 
diff -r e25ad5cc0963 -r 1ab9421bf75c tools/libxl/libxl.h
--- a/tools/libxl/libxl.h	Thu Dec 15 18:55:46 2011 +0100
+++ b/tools/libxl/libxl.h	Thu Dec 15 18:55:46 2011 +0100
@@ -269,7 +269,7 @@ int libxl_domain_suspend(libxl_ctx *ctx,
                           uint32_t domid, int fd);
 int libxl_domain_resume(libxl_ctx *ctx, uint32_t domid);
 int libxl_domain_shutdown(libxl_ctx *ctx, uint32_t domid, int req);
-int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid, int force);
+int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid);
 int libxl_domain_preserve(libxl_ctx *ctx, uint32_t domid, libxl_domain_create_info *info, const char *name_suffix, libxl_uuid new_uuid);
 
 /* get max. number of cpus supported by hypervisor */
diff -r e25ad5cc0963 -r 1ab9421bf75c tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Thu Dec 15 18:55:46 2011 +0100
+++ b/tools/libxl/libxl_create.c	Thu Dec 15 18:55:46 2011 +0100
@@ -662,7 +662,7 @@ static int do_domain_create(libxl__gc *g
 
 error_out:
     if (domid)
-        libxl_domain_destroy(ctx, domid, 0);
+        libxl_domain_destroy(ctx, domid);
 
     return ret;
 }
diff -r e25ad5cc0963 -r 1ab9421bf75c tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Thu Dec 15 18:55:46 2011 +0100
+++ b/tools/libxl/libxl_dm.c	Thu Dec 15 18:55:46 2011 +0100
@@ -917,7 +917,7 @@ int libxl__destroy_device_model(libxl__g
             goto out;
         }
         LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Device model is a stubdom, domid=%d", stubdomid);
-        ret = libxl_domain_destroy(ctx, stubdomid, 0);
+        ret = libxl_domain_destroy(ctx, stubdomid);
         if (ret)
             goto out;
     } else {
diff -r e25ad5cc0963 -r 1ab9421bf75c tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Thu Dec 15 18:55:46 2011 +0100
+++ b/tools/libxl/xl_cmdimpl.c	Thu Dec 15 18:55:46 2011 +0100
@@ -1283,7 +1283,7 @@ static int handle_domain_death(libxl_ctx
         /* fall-through */
     case LIBXL_ACTION_ON_SHUTDOWN_DESTROY:
         LOG("Domain %d needs to be cleaned up: destroying the domain", domid);
-        libxl_domain_destroy(ctx, domid, 0);
+        libxl_domain_destroy(ctx, domid);
         break;
 
     case LIBXL_ACTION_ON_SHUTDOWN_COREDUMP_DESTROY:
@@ -1786,7 +1786,7 @@ start:
 error_out:
     release_lock();
     if (libxl_domid_valid_guest(domid))
-        libxl_domain_destroy(ctx, domid, 0);
+        libxl_domain_destroy(ctx, domid);
 
 out:
     if (logfile != 2)
@@ -2256,7 +2256,7 @@ static void destroy_domain(const char *p
         fprintf(stderr, "Cannot destroy privileged domain 0.\n\n");
         exit(-1);
     }
-    rc = libxl_domain_destroy(ctx, domid, 0);
+    rc = libxl_domain_destroy(ctx, domid);
     if (rc) { fprintf(stderr,"destroy failed (rc=%d)\n",rc); exit(-1); }
 }
 
@@ -2502,7 +2502,7 @@ static int save_domain(const char *p, co
     if (checkpoint)
         libxl_domain_unpause(ctx, domid);
     else
-        libxl_domain_destroy(ctx, domid, 0);
+        libxl_domain_destroy(ctx, domid);
 
     exit(0);
 }
@@ -2735,7 +2735,7 @@ static void migrate_domain(const char *d
     }
 
     fprintf(stderr, "migration sender: Target reports successful startup.\n");
-    libxl_domain_destroy(ctx, domid, 1); /* bang! */
+    libxl_domain_destroy(ctx, domid); /* bang! */
     fprintf(stderr, "Migration successful.\n");
     exit(0);
 
@@ -2852,7 +2852,7 @@ static void migrate_receive(int debug, i
     if (rc) {
         fprintf(stderr, "migration target: Failure, destroying our copy.\n");
 
-        rc2 = libxl_domain_destroy(ctx, domid, 1);
+        rc2 = libxl_domain_destroy(ctx, domid);
         if (rc2) {
             fprintf(stderr, "migration target: Failed to destroy our copy"
                     " (code %d).\n", rc2);
diff -r e25ad5cc0963 -r 1ab9421bf75c tools/python/xen/lowlevel/xl/xl.c
--- a/tools/python/xen/lowlevel/xl/xl.c	Thu Dec 15 18:55:46 2011 +0100
+++ b/tools/python/xen/lowlevel/xl/xl.c	Thu Dec 15 18:55:46 2011 +0100
@@ -437,10 +437,10 @@ static PyObject *pyxl_domain_shutdown(Xl
 
 static PyObject *pyxl_domain_destroy(XlObject *self, PyObject *args)
 {
-    int domid, force = 1;
-    if ( !PyArg_ParseTuple(args, "i|i", &domid, &force) )
+    int domid;
+    if ( !PyArg_ParseTuple(args, "i", &domid) )
         return NULL;
-    if ( libxl_domain_destroy(self->ctx, domid, force) ) {
+    if ( libxl_domain_destroy(self->ctx, domid) ) {
         PyErr_SetString(xl_error_obj, "cannot destroy domain");
         return NULL;
     }

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 17:59:31 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 17:59:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbFaX-0003xi-Sn; Thu, 15 Dec 2011 17:59:25 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RbFaW-0003vp-HP
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 17:59:24 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1323971958!6441143!1
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 904 invoked from network); 15 Dec 2011 17:59:18 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 17:59:18 -0000
Received: by wgbds11 with SMTP id ds11so3797047wgb.24
	for <xen-devel@lists.xensource.com>;
	Thu, 15 Dec 2011 09:59:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=1hkNoyhqw5n78TYUATtz/Wg53YnKvgJ4YijloCA5+Ek=;
	b=sdTGzogOzXnSC+uGmMJpptfDdEu91JWF9lH/bDFEx0UhjdPJ89+NWwSy8iA/HkttVh
	BVMG5PCKx50Tkzkc37mJt580CfBQuO0chI0Yud+64V6nKBNFiEMfXJdePjzapaDFKtEW
	vlXYzdX2jJd3KIPpciWAGqDfZSPWSRq+mlQmA=
Received: by 10.227.197.78 with SMTP id ej14mr3305707wbb.2.1323971957948;
	Thu, 15 Dec 2011 09:59:17 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id eg7sm9354086wib.8.2011.12.15.09.59.15
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 15 Dec 2011 09:59:16 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 1ab9421bf75c620fabb8d02c921a877a323c1a03
Message-Id: <1ab9421bf75c620fabb8.1323971896@loki.upc.es>
In-Reply-To: <patchbomb.1323971891@loki.upc.es>
References: <patchbomb.1323971891@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Thu, 15 Dec 2011 18:58:16 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 5 of 6 ACKED v5] libxl: remove force parameter
 from libxl_domain_destroy
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1323971746 -3600
# Node ID 1ab9421bf75c620fabb8d02c921a877a323c1a03
# Parent  e25ad5cc0963ca0a6d2b8efe2772afa77b4835c4
libxl: remove force parameter from libxl_domain_destroy

Since a destroy is considered a forced shutdown, there's no point in
passing a force parameter. All the occurences of this function have
been replaced with the proper syntax.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

diff -r e25ad5cc0963 -r 1ab9421bf75c tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Thu Dec 15 18:55:46 2011 +0100
+++ b/tools/libxl/libxl.c	Thu Dec 15 18:55:46 2011 +0100
@@ -723,7 +723,7 @@ int libxl_event_get_disk_eject_info(libx
     return 1;
 }
 
-int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid, int force)
+int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid)
 {
     GC_INIT(ctx);
     libxl_dominfo dominfo;
@@ -772,7 +772,7 @@ int libxl_domain_destroy(libxl_ctx *ctx,
 
         libxl__qmp_cleanup(gc, domid);
     }
-    if (libxl__devices_destroy(gc, domid, force) < 0)
+    if (libxl__devices_destroy(gc, domid, 1) < 0)
         LIBXL__LOG(ctx, LIBXL__LOG_ERROR, 
                    "libxl__devices_destroy failed for %d", domid);
 
diff -r e25ad5cc0963 -r 1ab9421bf75c tools/libxl/libxl.h
--- a/tools/libxl/libxl.h	Thu Dec 15 18:55:46 2011 +0100
+++ b/tools/libxl/libxl.h	Thu Dec 15 18:55:46 2011 +0100
@@ -269,7 +269,7 @@ int libxl_domain_suspend(libxl_ctx *ctx,
                           uint32_t domid, int fd);
 int libxl_domain_resume(libxl_ctx *ctx, uint32_t domid);
 int libxl_domain_shutdown(libxl_ctx *ctx, uint32_t domid, int req);
-int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid, int force);
+int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid);
 int libxl_domain_preserve(libxl_ctx *ctx, uint32_t domid, libxl_domain_create_info *info, const char *name_suffix, libxl_uuid new_uuid);
 
 /* get max. number of cpus supported by hypervisor */
diff -r e25ad5cc0963 -r 1ab9421bf75c tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Thu Dec 15 18:55:46 2011 +0100
+++ b/tools/libxl/libxl_create.c	Thu Dec 15 18:55:46 2011 +0100
@@ -662,7 +662,7 @@ static int do_domain_create(libxl__gc *g
 
 error_out:
     if (domid)
-        libxl_domain_destroy(ctx, domid, 0);
+        libxl_domain_destroy(ctx, domid);
 
     return ret;
 }
diff -r e25ad5cc0963 -r 1ab9421bf75c tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Thu Dec 15 18:55:46 2011 +0100
+++ b/tools/libxl/libxl_dm.c	Thu Dec 15 18:55:46 2011 +0100
@@ -917,7 +917,7 @@ int libxl__destroy_device_model(libxl__g
             goto out;
         }
         LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Device model is a stubdom, domid=%d", stubdomid);
-        ret = libxl_domain_destroy(ctx, stubdomid, 0);
+        ret = libxl_domain_destroy(ctx, stubdomid);
         if (ret)
             goto out;
     } else {
diff -r e25ad5cc0963 -r 1ab9421bf75c tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Thu Dec 15 18:55:46 2011 +0100
+++ b/tools/libxl/xl_cmdimpl.c	Thu Dec 15 18:55:46 2011 +0100
@@ -1283,7 +1283,7 @@ static int handle_domain_death(libxl_ctx
         /* fall-through */
     case LIBXL_ACTION_ON_SHUTDOWN_DESTROY:
         LOG("Domain %d needs to be cleaned up: destroying the domain", domid);
-        libxl_domain_destroy(ctx, domid, 0);
+        libxl_domain_destroy(ctx, domid);
         break;
 
     case LIBXL_ACTION_ON_SHUTDOWN_COREDUMP_DESTROY:
@@ -1786,7 +1786,7 @@ start:
 error_out:
     release_lock();
     if (libxl_domid_valid_guest(domid))
-        libxl_domain_destroy(ctx, domid, 0);
+        libxl_domain_destroy(ctx, domid);
 
 out:
     if (logfile != 2)
@@ -2256,7 +2256,7 @@ static void destroy_domain(const char *p
         fprintf(stderr, "Cannot destroy privileged domain 0.\n\n");
         exit(-1);
     }
-    rc = libxl_domain_destroy(ctx, domid, 0);
+    rc = libxl_domain_destroy(ctx, domid);
     if (rc) { fprintf(stderr,"destroy failed (rc=%d)\n",rc); exit(-1); }
 }
 
@@ -2502,7 +2502,7 @@ static int save_domain(const char *p, co
     if (checkpoint)
         libxl_domain_unpause(ctx, domid);
     else
-        libxl_domain_destroy(ctx, domid, 0);
+        libxl_domain_destroy(ctx, domid);
 
     exit(0);
 }
@@ -2735,7 +2735,7 @@ static void migrate_domain(const char *d
     }
 
     fprintf(stderr, "migration sender: Target reports successful startup.\n");
-    libxl_domain_destroy(ctx, domid, 1); /* bang! */
+    libxl_domain_destroy(ctx, domid); /* bang! */
     fprintf(stderr, "Migration successful.\n");
     exit(0);
 
@@ -2852,7 +2852,7 @@ static void migrate_receive(int debug, i
     if (rc) {
         fprintf(stderr, "migration target: Failure, destroying our copy.\n");
 
-        rc2 = libxl_domain_destroy(ctx, domid, 1);
+        rc2 = libxl_domain_destroy(ctx, domid);
         if (rc2) {
             fprintf(stderr, "migration target: Failed to destroy our copy"
                     " (code %d).\n", rc2);
diff -r e25ad5cc0963 -r 1ab9421bf75c tools/python/xen/lowlevel/xl/xl.c
--- a/tools/python/xen/lowlevel/xl/xl.c	Thu Dec 15 18:55:46 2011 +0100
+++ b/tools/python/xen/lowlevel/xl/xl.c	Thu Dec 15 18:55:46 2011 +0100
@@ -437,10 +437,10 @@ static PyObject *pyxl_domain_shutdown(Xl
 
 static PyObject *pyxl_domain_destroy(XlObject *self, PyObject *args)
 {
-    int domid, force = 1;
-    if ( !PyArg_ParseTuple(args, "i|i", &domid, &force) )
+    int domid;
+    if ( !PyArg_ParseTuple(args, "i", &domid) )
         return NULL;
-    if ( libxl_domain_destroy(self->ctx, domid, force) ) {
+    if ( libxl_domain_destroy(self->ctx, domid) ) {
         PyErr_SetString(xl_error_obj, "cannot destroy domain");
         return NULL;
     }

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 17:59:36 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 17:59:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbFaZ-0003ya-KA; Thu, 15 Dec 2011 17:59:27 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RbFaY-0003wU-Oj
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 17:59:27 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1323971950!7441462!3
X-Originating-IP: [209.85.161.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6170 invoked from network); 15 Dec 2011 17:59:20 -0000
Received: from mail-fx0-f43.google.com (HELO mail-fx0-f43.google.com)
	(209.85.161.43)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 17:59:20 -0000
Received: by mail-fx0-f43.google.com with SMTP id p21so5770561faa.30
	for <xen-devel@lists.xensource.com>;
	Thu, 15 Dec 2011 09:59:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=SxUvANdfhyKtK/Xye/SMI1lVB2qJV+WwuN9QVDj2eKs=;
	b=FJQ7CtCK8BwvN+9Xe6fyz9Vu8fWmbmIhLHWAjZWW9Z7cnLGuy3iBH3dUdxim9lKZe3
	9DloRdjc8ASk3NU/Xq6zwN1W6znh001CM0raesRW+Any2hP53E8U6KstrHqaTmWhTa9z
	1l1qJdo8eC3TMh1GZFMcMwRGaOkRC9Pvi29G8=
Received: by 10.180.105.232 with SMTP id gp8mr6913094wib.65.1323971960345;
	Thu, 15 Dec 2011 09:59:20 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id eg7sm9354086wib.8.2011.12.15.09.59.18
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 15 Dec 2011 09:59:18 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 5cb746278dd800860267939f6208abeb3239dc9c
Message-Id: <5cb746278dd800860267.1323971897@loki.upc.es>
In-Reply-To: <patchbomb.1323971891@loki.upc.es>
References: <patchbomb.1323971891@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Thu, 15 Dec 2011 18:58:17 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 6 of 6 ACKED v5] libxl: remove force parameter
 from libxl__devices_destroy
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1323971746 -3600
# Node ID 5cb746278dd800860267939f6208abeb3239dc9c
# Parent  1ab9421bf75c620fabb8d02c921a877a323c1a03
libxl: remove force parameter from libxl__devices_destroy

Remove the force flag, and always use forced destruction.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

diff -r 1ab9421bf75c -r 5cb746278dd8 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Thu Dec 15 18:55:46 2011 +0100
+++ b/tools/libxl/libxl.c	Thu Dec 15 18:55:46 2011 +0100
@@ -772,7 +772,7 @@ int libxl_domain_destroy(libxl_ctx *ctx,
 
         libxl__qmp_cleanup(gc, domid);
     }
-    if (libxl__devices_destroy(gc, domid, 1) < 0)
+    if (libxl__devices_destroy(gc, domid) < 0)
         LIBXL__LOG(ctx, LIBXL__LOG_ERROR, 
                    "libxl__devices_destroy failed for %d", domid);
 
diff -r 1ab9421bf75c -r 5cb746278dd8 tools/libxl/libxl_device.c
--- a/tools/libxl/libxl_device.c	Thu Dec 15 18:55:46 2011 +0100
+++ b/tools/libxl/libxl_device.c	Thu Dec 15 18:55:46 2011 +0100
@@ -505,13 +505,13 @@ int libxl__device_destroy(libxl__gc *gc,
     return rc;
 }
 
-int libxl__devices_destroy(libxl__gc *gc, uint32_t domid, int force)
+int libxl__devices_destroy(libxl__gc *gc, uint32_t domid)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
     char *path;
     unsigned int num_kinds, num_devs;
     char **kinds = NULL, **devs = NULL;
-    int i, j, n_watches = 0;
+    int i, j;
     libxl__device dev;
     libxl__device_kind kind;
 
@@ -542,16 +542,7 @@ int libxl__devices_destroy(libxl__gc *gc
                 dev.kind = kind;
                 dev.devid = atoi(devs[j]);
 
-                if (force) {
-                    libxl__device_destroy(gc, &dev);
-                } else {
-                    int rc = libxl__device_remove(gc, &dev, 0);
-                    if (rc < 0)
-                        LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
-                                   "cannot remove device %s\n", path);
-                    else
-                        n_watches += rc;
-                }
+                libxl__device_destroy(gc, &dev);
             }
         }
     }
@@ -565,37 +556,9 @@ int libxl__devices_destroy(libxl__gc *gc
         dev.kind = LIBXL__DEVICE_KIND_CONSOLE;
         dev.devid = 0;
 
-        if (force) {
-            libxl__device_destroy(gc, &dev);
-        } else {
-            int rc = libxl__device_remove(gc, &dev, 0);
-            if (rc < 0)
-                LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
-                           "cannot remove device %s\n", path);
-            else
-                n_watches += rc;
-        }
+        libxl__device_destroy(gc, &dev);
     }
 
-    if (!force) {
-        /* Linux-ism. Most implementations leave the timeout
-         * untouched after select. Linux, however, will chip
-         * away the elapsed time from it, which is what we
-         * need to enforce a single time span waiting for
-         * device destruction. */
-        struct timeval tv;
-        tv.tv_sec = LIBXL_DESTROY_TIMEOUT;
-        tv.tv_usec = 0;
-        while (n_watches > 0) {
-            if (libxl__wait_for_device_state(gc, &tv, XenbusStateClosed,
-                                             destroy_device) < 0) {
-                /* function returned ERROR_* */
-                break;
-            } else {
-                n_watches--;
-            }
-        }
-    }
 out:
     return 0;
 }
diff -r 1ab9421bf75c -r 5cb746278dd8 tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Thu Dec 15 18:55:46 2011 +0100
+++ b/tools/libxl/libxl_internal.h	Thu Dec 15 18:55:46 2011 +0100
@@ -271,7 +271,7 @@ _hidden int libxl__parse_backend_path(li
                                       libxl__device *dev);
 _hidden int libxl__device_remove(libxl__gc *gc, libxl__device *dev, int wait);
 _hidden int libxl__device_destroy(libxl__gc *gc, libxl__device *dev);
-_hidden int libxl__devices_destroy(libxl__gc *gc, uint32_t domid, int force);
+_hidden int libxl__devices_destroy(libxl__gc *gc, uint32_t domid);
 _hidden int libxl__wait_for_backend(libxl__gc *gc, char *be_path, char *state);
 
 /* Handler for the libxl__wait_for_device_state callback */

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 17:59:36 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 17:59:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbFaZ-0003ya-KA; Thu, 15 Dec 2011 17:59:27 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RbFaY-0003wU-Oj
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 17:59:27 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1323971950!7441462!3
X-Originating-IP: [209.85.161.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6170 invoked from network); 15 Dec 2011 17:59:20 -0000
Received: from mail-fx0-f43.google.com (HELO mail-fx0-f43.google.com)
	(209.85.161.43)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 17:59:20 -0000
Received: by mail-fx0-f43.google.com with SMTP id p21so5770561faa.30
	for <xen-devel@lists.xensource.com>;
	Thu, 15 Dec 2011 09:59:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=SxUvANdfhyKtK/Xye/SMI1lVB2qJV+WwuN9QVDj2eKs=;
	b=FJQ7CtCK8BwvN+9Xe6fyz9Vu8fWmbmIhLHWAjZWW9Z7cnLGuy3iBH3dUdxim9lKZe3
	9DloRdjc8ASk3NU/Xq6zwN1W6znh001CM0raesRW+Any2hP53E8U6KstrHqaTmWhTa9z
	1l1qJdo8eC3TMh1GZFMcMwRGaOkRC9Pvi29G8=
Received: by 10.180.105.232 with SMTP id gp8mr6913094wib.65.1323971960345;
	Thu, 15 Dec 2011 09:59:20 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id eg7sm9354086wib.8.2011.12.15.09.59.18
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 15 Dec 2011 09:59:18 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 5cb746278dd800860267939f6208abeb3239dc9c
Message-Id: <5cb746278dd800860267.1323971897@loki.upc.es>
In-Reply-To: <patchbomb.1323971891@loki.upc.es>
References: <patchbomb.1323971891@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Thu, 15 Dec 2011 18:58:17 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 6 of 6 ACKED v5] libxl: remove force parameter
 from libxl__devices_destroy
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1323971746 -3600
# Node ID 5cb746278dd800860267939f6208abeb3239dc9c
# Parent  1ab9421bf75c620fabb8d02c921a877a323c1a03
libxl: remove force parameter from libxl__devices_destroy

Remove the force flag, and always use forced destruction.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

diff -r 1ab9421bf75c -r 5cb746278dd8 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Thu Dec 15 18:55:46 2011 +0100
+++ b/tools/libxl/libxl.c	Thu Dec 15 18:55:46 2011 +0100
@@ -772,7 +772,7 @@ int libxl_domain_destroy(libxl_ctx *ctx,
 
         libxl__qmp_cleanup(gc, domid);
     }
-    if (libxl__devices_destroy(gc, domid, 1) < 0)
+    if (libxl__devices_destroy(gc, domid) < 0)
         LIBXL__LOG(ctx, LIBXL__LOG_ERROR, 
                    "libxl__devices_destroy failed for %d", domid);
 
diff -r 1ab9421bf75c -r 5cb746278dd8 tools/libxl/libxl_device.c
--- a/tools/libxl/libxl_device.c	Thu Dec 15 18:55:46 2011 +0100
+++ b/tools/libxl/libxl_device.c	Thu Dec 15 18:55:46 2011 +0100
@@ -505,13 +505,13 @@ int libxl__device_destroy(libxl__gc *gc,
     return rc;
 }
 
-int libxl__devices_destroy(libxl__gc *gc, uint32_t domid, int force)
+int libxl__devices_destroy(libxl__gc *gc, uint32_t domid)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
     char *path;
     unsigned int num_kinds, num_devs;
     char **kinds = NULL, **devs = NULL;
-    int i, j, n_watches = 0;
+    int i, j;
     libxl__device dev;
     libxl__device_kind kind;
 
@@ -542,16 +542,7 @@ int libxl__devices_destroy(libxl__gc *gc
                 dev.kind = kind;
                 dev.devid = atoi(devs[j]);
 
-                if (force) {
-                    libxl__device_destroy(gc, &dev);
-                } else {
-                    int rc = libxl__device_remove(gc, &dev, 0);
-                    if (rc < 0)
-                        LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
-                                   "cannot remove device %s\n", path);
-                    else
-                        n_watches += rc;
-                }
+                libxl__device_destroy(gc, &dev);
             }
         }
     }
@@ -565,37 +556,9 @@ int libxl__devices_destroy(libxl__gc *gc
         dev.kind = LIBXL__DEVICE_KIND_CONSOLE;
         dev.devid = 0;
 
-        if (force) {
-            libxl__device_destroy(gc, &dev);
-        } else {
-            int rc = libxl__device_remove(gc, &dev, 0);
-            if (rc < 0)
-                LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
-                           "cannot remove device %s\n", path);
-            else
-                n_watches += rc;
-        }
+        libxl__device_destroy(gc, &dev);
     }
 
-    if (!force) {
-        /* Linux-ism. Most implementations leave the timeout
-         * untouched after select. Linux, however, will chip
-         * away the elapsed time from it, which is what we
-         * need to enforce a single time span waiting for
-         * device destruction. */
-        struct timeval tv;
-        tv.tv_sec = LIBXL_DESTROY_TIMEOUT;
-        tv.tv_usec = 0;
-        while (n_watches > 0) {
-            if (libxl__wait_for_device_state(gc, &tv, XenbusStateClosed,
-                                             destroy_device) < 0) {
-                /* function returned ERROR_* */
-                break;
-            } else {
-                n_watches--;
-            }
-        }
-    }
 out:
     return 0;
 }
diff -r 1ab9421bf75c -r 5cb746278dd8 tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Thu Dec 15 18:55:46 2011 +0100
+++ b/tools/libxl/libxl_internal.h	Thu Dec 15 18:55:46 2011 +0100
@@ -271,7 +271,7 @@ _hidden int libxl__parse_backend_path(li
                                       libxl__device *dev);
 _hidden int libxl__device_remove(libxl__gc *gc, libxl__device *dev, int wait);
 _hidden int libxl__device_destroy(libxl__gc *gc, libxl__device *dev);
-_hidden int libxl__devices_destroy(libxl__gc *gc, uint32_t domid, int force);
+_hidden int libxl__devices_destroy(libxl__gc *gc, uint32_t domid);
 _hidden int libxl__wait_for_backend(libxl__gc *gc, char *be_path, char *state);
 
 /* Handler for the libxl__wait_for_device_state callback */

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 18:02:51 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 18:02:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbFdj-0004uA-B0; Thu, 15 Dec 2011 18:02:43 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RbFdi-0004sq-Fg
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 18:02:42 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1323972156!7567414!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjI2MA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11501 invoked from network); 15 Dec 2011 18:02:36 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 18:02:36 -0000
X-IronPort-AV: E=Sophos;i="4.71,358,1320624000"; 
   d="scan'208";a="9498990"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Dec 2011 18:02:36 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 15 Dec 2011 18:02:36 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RbFdb-0007oS-TL;
	Thu, 15 Dec 2011 18:02:35 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RbFdb-0002WQ-Oj;
	Thu, 15 Dec 2011 18:02:35 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10502-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 15 Dec 2011 18:02:35 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10502: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10502 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10502/

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-amd64-xl-sedf-pin 14 guest-localmigrate/x10    fail REGR. vs. 10491
 test-amd64-amd64-xl-sedf     14 guest-localmigrate/x10    fail REGR. vs. 10491
 test-amd64-i386-win           7 windows-install           fail REGR. vs. 10491
 test-amd64-amd64-win          7 windows-install           fail REGR. vs. 10491

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass

version targeted for testing:
 xen                  ca5f588bd203
baseline version:
 xen                  03138a08366b

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Christoph Egger <Christoph.Egger@amd.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Liu, Jinsong <jinsong.liu@intel.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   24411:ca5f588bd203
tag:         tip
user:        Christoph Egger <Christoph.Egger@amd.com>
date:        Thu Dec 15 11:00:09 2011 +0100
    
    x86/ucode: fix for AMD Fam15 CPUs
    
    Remove hardcoded maximum size a microcode patch can have. This is
    dynamic now.
    
    The microcode patch for family15h can be larger than 2048 bytes and
    gets silently truncated.
    
    Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Committed-by: Jan Beulich <jbeulich@suse.com>
    
    
changeset:   24410:25f8952313ae
user:        Liu, Jinsong <jinsong.liu@intel.com>
date:        Thu Dec 15 10:58:53 2011 +0100
    
    x86/MCE: add more strict sanity check of one SRAR case
    
    When RIPV = EIPV = 0, it's a little bit tricky. It may be an asynchronic error, currently we have no way to precisely locate whether the error occur at guest or hypervisor.
    To avoid handling error in wrong way, we treat it as unrecovered.
    
    Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Committed-by: Jan Beulich <jbeulich@suse.com>
    
    
changeset:   24409:0cd9f3e5f3e0
user:        Liu, Jinsong <jinsong.liu@intel.com>
date:        Thu Dec 15 10:54:51 2011 +0100
    
    x86/MCE: add SRAR handler
    
    Currently Intel SDM add 2 kinds of MCE SRAR errors:
    1). Data Load error, error code = 0x134
    2). Instruction Fetch error, error code = 0x150
    This patch add handler to these new SRAR errors.
    It based on existed mce infrastructure, add code to handle SRAR specific error.
    
    Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
    Committed-by: Jan Beulich <jbeulich@suse.com>
    
    
changeset:   24408:5d2dd48bce21
user:        Andrew Cooper <andrew.cooper3@citrix.com>
date:        Wed Dec 14 17:53:54 2011 +0100
    
    XLAT.lst whitespace fix.
    
    Replace spaces with tabs to be in line with file format.
    
    Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
    Committed-by: Jan Beulich <jbeulich@suse.com>
    
    
changeset:   24407:03138a08366b
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Fri Dec 09 16:19:36 2011 +0000
    
    oxenstored: log Errors and Warnings by default.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Acked-by: Ian Jackson <ian.jackson.citrix.com>
    Committed-by: Ian Jackson <ian.jackson.citrix.com>
    
    
========================================
commit 54e24021005458ad0a361c1d83011b751726a94b
Author: Ian Jackson <ian.jackson@eu.citrix.com>
Date:   Thu Dec 8 16:38:06 2011 +0000

    qemu_get_timer: Provide a comment about the behaviour on ts==NULL
    
    Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 18:02:51 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 18:02:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbFdj-0004uA-B0; Thu, 15 Dec 2011 18:02:43 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RbFdi-0004sq-Fg
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 18:02:42 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1323972156!7567414!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjI2MA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11501 invoked from network); 15 Dec 2011 18:02:36 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 18:02:36 -0000
X-IronPort-AV: E=Sophos;i="4.71,358,1320624000"; 
   d="scan'208";a="9498990"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Dec 2011 18:02:36 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 15 Dec 2011 18:02:36 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RbFdb-0007oS-TL;
	Thu, 15 Dec 2011 18:02:35 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RbFdb-0002WQ-Oj;
	Thu, 15 Dec 2011 18:02:35 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10502-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 15 Dec 2011 18:02:35 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10502: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10502 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10502/

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-amd64-xl-sedf-pin 14 guest-localmigrate/x10    fail REGR. vs. 10491
 test-amd64-amd64-xl-sedf     14 guest-localmigrate/x10    fail REGR. vs. 10491
 test-amd64-i386-win           7 windows-install           fail REGR. vs. 10491
 test-amd64-amd64-win          7 windows-install           fail REGR. vs. 10491

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass

version targeted for testing:
 xen                  ca5f588bd203
baseline version:
 xen                  03138a08366b

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Christoph Egger <Christoph.Egger@amd.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Liu, Jinsong <jinsong.liu@intel.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   24411:ca5f588bd203
tag:         tip
user:        Christoph Egger <Christoph.Egger@amd.com>
date:        Thu Dec 15 11:00:09 2011 +0100
    
    x86/ucode: fix for AMD Fam15 CPUs
    
    Remove hardcoded maximum size a microcode patch can have. This is
    dynamic now.
    
    The microcode patch for family15h can be larger than 2048 bytes and
    gets silently truncated.
    
    Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Committed-by: Jan Beulich <jbeulich@suse.com>
    
    
changeset:   24410:25f8952313ae
user:        Liu, Jinsong <jinsong.liu@intel.com>
date:        Thu Dec 15 10:58:53 2011 +0100
    
    x86/MCE: add more strict sanity check of one SRAR case
    
    When RIPV = EIPV = 0, it's a little bit tricky. It may be an asynchronic error, currently we have no way to precisely locate whether the error occur at guest or hypervisor.
    To avoid handling error in wrong way, we treat it as unrecovered.
    
    Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Committed-by: Jan Beulich <jbeulich@suse.com>
    
    
changeset:   24409:0cd9f3e5f3e0
user:        Liu, Jinsong <jinsong.liu@intel.com>
date:        Thu Dec 15 10:54:51 2011 +0100
    
    x86/MCE: add SRAR handler
    
    Currently Intel SDM add 2 kinds of MCE SRAR errors:
    1). Data Load error, error code = 0x134
    2). Instruction Fetch error, error code = 0x150
    This patch add handler to these new SRAR errors.
    It based on existed mce infrastructure, add code to handle SRAR specific error.
    
    Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
    Committed-by: Jan Beulich <jbeulich@suse.com>
    
    
changeset:   24408:5d2dd48bce21
user:        Andrew Cooper <andrew.cooper3@citrix.com>
date:        Wed Dec 14 17:53:54 2011 +0100
    
    XLAT.lst whitespace fix.
    
    Replace spaces with tabs to be in line with file format.
    
    Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
    Committed-by: Jan Beulich <jbeulich@suse.com>
    
    
changeset:   24407:03138a08366b
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Fri Dec 09 16:19:36 2011 +0000
    
    oxenstored: log Errors and Warnings by default.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Acked-by: Ian Jackson <ian.jackson.citrix.com>
    Committed-by: Ian Jackson <ian.jackson.citrix.com>
    
    
========================================
commit 54e24021005458ad0a361c1d83011b751726a94b
Author: Ian Jackson <ian.jackson@eu.citrix.com>
Date:   Thu Dec 8 16:38:06 2011 +0000

    qemu_get_timer: Provide a comment about the behaviour on ts==NULL
    
    Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 18:06:14 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 18: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.xensource.com>)
	id 1RbFgz-0005Pc-6U; Thu, 15 Dec 2011 18:06:05 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RbFgx-0005PP-U8
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 18:06:04 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1323972356!5735305!1
X-Originating-IP: [209.85.160.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5526 invoked from network); 15 Dec 2011 18:05:57 -0000
Received: from mail-pw0-f43.google.com (HELO mail-pw0-f43.google.com)
	(209.85.160.43)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 18:05:57 -0000
Received: by pbbb11 with SMTP id b11so6734339pbb.30
	for <xen-devel@lists.xensource.com>;
	Thu, 15 Dec 2011 10:05:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:content-type;
	bh=HgFTlF0PWaD/0ESfHbdpx0dEjgU31wkVlrH1Jzkaq1A=;
	b=IqrTFf1xXlSDVnnaydXhHXG2FUCohLtgsIO2y7ejY1+2Cirf6YHpGTFvoFwhJJ/HCb
	dax+UDrMoAcrh3piS1+4zszf4U6OwPd0cn5n/dwe18FxWF+JyXks8BLqQ9c4rybzPcKw
	NKSsFzb85Tb23EMvZ1+o+PkOZmM7E7qt/BskE=
MIME-Version: 1.0
Received: by 10.68.211.225 with SMTP id nf1mr11192920pbc.47.1323972355487;
	Thu, 15 Dec 2011 10:05:55 -0800 (PST)
Received: by 10.142.47.17 with HTTP; Thu, 15 Dec 2011 10:05:55 -0800 (PST)
In-Reply-To: <a01f1e2f654ea54bbf5d.1323969513@loki.upc.es>
References: <a01f1e2f654ea54bbf5d.1323969513@loki.upc.es>
Date: Thu, 15 Dec 2011 19:05:55 +0100
X-Google-Sender-Auth: RZifG_3WTy9YwEeS3OvV1Pu21VU
Message-ID: <CAPLaKK7GCBSxPDfenHOzmVZ-uaHh186gfpHaJ7nmVHHrQVq6wQ@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] blktap2: use HAVE_BYTESWAP_H and
	_BYTESWAP_H for uclibc compatibility
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

I'm having second thoughts about this patch, although it works, I'm
not sure it's the right way to do it. I don't know why configure fails
to set HAVE_BYTESWAP_H when using uclibc. Any thoughts?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 18:06:14 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 18: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.xensource.com>)
	id 1RbFgz-0005Pc-6U; Thu, 15 Dec 2011 18:06:05 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RbFgx-0005PP-U8
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 18:06:04 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1323972356!5735305!1
X-Originating-IP: [209.85.160.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5526 invoked from network); 15 Dec 2011 18:05:57 -0000
Received: from mail-pw0-f43.google.com (HELO mail-pw0-f43.google.com)
	(209.85.160.43)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 18:05:57 -0000
Received: by pbbb11 with SMTP id b11so6734339pbb.30
	for <xen-devel@lists.xensource.com>;
	Thu, 15 Dec 2011 10:05:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:content-type;
	bh=HgFTlF0PWaD/0ESfHbdpx0dEjgU31wkVlrH1Jzkaq1A=;
	b=IqrTFf1xXlSDVnnaydXhHXG2FUCohLtgsIO2y7ejY1+2Cirf6YHpGTFvoFwhJJ/HCb
	dax+UDrMoAcrh3piS1+4zszf4U6OwPd0cn5n/dwe18FxWF+JyXks8BLqQ9c4rybzPcKw
	NKSsFzb85Tb23EMvZ1+o+PkOZmM7E7qt/BskE=
MIME-Version: 1.0
Received: by 10.68.211.225 with SMTP id nf1mr11192920pbc.47.1323972355487;
	Thu, 15 Dec 2011 10:05:55 -0800 (PST)
Received: by 10.142.47.17 with HTTP; Thu, 15 Dec 2011 10:05:55 -0800 (PST)
In-Reply-To: <a01f1e2f654ea54bbf5d.1323969513@loki.upc.es>
References: <a01f1e2f654ea54bbf5d.1323969513@loki.upc.es>
Date: Thu, 15 Dec 2011 19:05:55 +0100
X-Google-Sender-Auth: RZifG_3WTy9YwEeS3OvV1Pu21VU
Message-ID: <CAPLaKK7GCBSxPDfenHOzmVZ-uaHh186gfpHaJ7nmVHHrQVq6wQ@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] blktap2: use HAVE_BYTESWAP_H and
	_BYTESWAP_H for uclibc compatibility
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

I'm having second thoughts about this patch, although it works, I'm
not sure it's the right way to do it. I don't know why configure fails
to set HAVE_BYTESWAP_H when using uclibc. Any thoughts?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 18:31:28 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 18:31:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbG5H-00069W-8o; Thu, 15 Dec 2011 18:31:11 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <waldi@debian.org>) id 1RbG5G-00069A-3H
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 18:31:10 +0000
X-Env-Sender: waldi@debian.org
X-Msg-Ref: server-4.tower-21.messagelabs.com!1323973862!2114361!1
X-Originating-IP: [82.139.201.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3601 invoked from network); 15 Dec 2011 18:31:03 -0000
Received: from wavehammer.waldi.eu.org (HELO wavehammer.waldi.eu.org)
	(82.139.201.20)
	by server-4.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 15 Dec 2011 18:31:03 -0000
Received: by wavehammer.waldi.eu.org (Postfix, from userid 1000)
	id 0CD685415D; Thu, 15 Dec 2011 19:31:00 +0100 (CET)
Date: Thu, 15 Dec 2011 19:31:00 +0100
From: Bastian Blank <waldi@debian.org>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20111215183100.GA1596@wavehammer.waldi.eu.org>
Mail-Followup-To: Bastian Blank <waldi@debian.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
References: <20111215104119.GC18042@wavehammer.waldi.eu.org>
	<1323968854.20077.507.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1323968854.20077.507.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 1/2] xenstored: Use xenbus_backend device on
 Linux
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Dec 15, 2011 at 05:07:34PM +0000, Ian Campbell wrote:
> +static int linux_xenbus_backend_interface(xc_interface *xch, xc_osdep_handle h, void **map, evtchn_port_t *port)
> +{
> +    int ret, fd;
> +    void *addr;
> +
> +    fd = open(XENSTORED_DEV, O_RDWR);
> +    if (fd == -1)
> +    {
> +        if ( errno != ENOENT )
> +            return -1;

This makes the code hard to read. You should first do the stuff on
success and then the error handling.

> +int xc_xenbus_backend_interface(xc_interface *xch, void **map, evtchn_port_t *port)

I prefer returning structs over such pointer stunts, but okay.

Bastian

-- 
There are always alternatives.
		-- Spock, "The Galileo Seven", stardate 2822.3

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 18:31:28 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 18:31:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbG5H-00069W-8o; Thu, 15 Dec 2011 18:31:11 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <waldi@debian.org>) id 1RbG5G-00069A-3H
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 18:31:10 +0000
X-Env-Sender: waldi@debian.org
X-Msg-Ref: server-4.tower-21.messagelabs.com!1323973862!2114361!1
X-Originating-IP: [82.139.201.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3601 invoked from network); 15 Dec 2011 18:31:03 -0000
Received: from wavehammer.waldi.eu.org (HELO wavehammer.waldi.eu.org)
	(82.139.201.20)
	by server-4.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 15 Dec 2011 18:31:03 -0000
Received: by wavehammer.waldi.eu.org (Postfix, from userid 1000)
	id 0CD685415D; Thu, 15 Dec 2011 19:31:00 +0100 (CET)
Date: Thu, 15 Dec 2011 19:31:00 +0100
From: Bastian Blank <waldi@debian.org>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20111215183100.GA1596@wavehammer.waldi.eu.org>
Mail-Followup-To: Bastian Blank <waldi@debian.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
References: <20111215104119.GC18042@wavehammer.waldi.eu.org>
	<1323968854.20077.507.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1323968854.20077.507.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 1/2] xenstored: Use xenbus_backend device on
 Linux
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Dec 15, 2011 at 05:07:34PM +0000, Ian Campbell wrote:
> +static int linux_xenbus_backend_interface(xc_interface *xch, xc_osdep_handle h, void **map, evtchn_port_t *port)
> +{
> +    int ret, fd;
> +    void *addr;
> +
> +    fd = open(XENSTORED_DEV, O_RDWR);
> +    if (fd == -1)
> +    {
> +        if ( errno != ENOENT )
> +            return -1;

This makes the code hard to read. You should first do the stuff on
success and then the error handling.

> +int xc_xenbus_backend_interface(xc_interface *xch, void **map, evtchn_port_t *port)

I prefer returning structs over such pointer stunts, but okay.

Bastian

-- 
There are always alternatives.
		-- Spock, "The Galileo Seven", stardate 2822.3

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 18:52:19 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 18:52:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbGPF-0006wK-QZ; Thu, 15 Dec 2011 18:51:49 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RbGPE-0006wE-MB
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 18:51:49 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-3.tower-174.messagelabs.com!1323975102!5672044!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.5 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMDA4MjI=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMDA4MjI=\n,BODY_RANDOM_LONG,
	UPPERCASE_25_50
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31795 invoked from network); 15 Dec 2011 18:51:42 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-3.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 15 Dec 2011 18:51:42 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1323975102; l=597;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=dTdyNbiTPcqk1jcmO4OLozosdl8=;
	b=tfYEMTSyHGysOuisFAEJMZPzHOzF2F8UILp23bdi/xf8yjxPzaz/Kpx62c8fsd/MEUl
	sdfQZG/TNN/18iW2Q2oYmuaY6OMGWlmX3Vqw61XdkaRmbDXOFj2m+AEGsr60NgRqFgxsp
	62YFYZRyLKDKLsfT+X9r2/zdKUlTKAYl6b4=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lr3s7jGzY=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-067-089.pools.arcor-ip.net [84.57.67.89])
	by smtp.strato.de (cohen mo41) (RZmta 26.15 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id i034c6nBFGh3OA ;
	Thu, 15 Dec 2011 19:51:25 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id A811218637; Thu, 15 Dec 2011 19:51:24 +0100 (CET)
Date: Thu, 15 Dec 2011 19:51:24 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <20111215185124.GA30948@aepfle.de>
References: <3bac38f7a427af3eb9f6.1323871739@loki.upc.es>
	<20202.11863.501987.497546@mariner.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20202.11863.501987.497546@mariner.uk.xensource.com>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: Roger Pau Monne <roger.pau@entel.upc.edu>, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH v2] xenpaging: remove _XOPEN_SOURCE
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Dec 15, Ian Jackson wrote:

> Roger Pau Monne writes ("[Xen-devel] [PATCH v2] xenpaging: remove _XOPEN_SOURCE"):
> > xenpaging: remove _XOPEN_SOURCE
> > 
> > The _XOPEN_SOURCE define was breaking the compilation under NetBSD.
> > I've removed it becasue it is not necessary.
> 
> I thought we'd decided that _NETBSD_SOURCE should be added ?

The initial patch which added _XOPEN_SOURCE should have a reasonable
description which includes the error message, and it should have been
_GNU_SOURCE instead of _XOPEN_SOURCE in the first place.

Please remove _XOPEN_SOURCE.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 18:52:19 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 18:52:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbGPF-0006wK-QZ; Thu, 15 Dec 2011 18:51:49 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RbGPE-0006wE-MB
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 18:51:49 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-3.tower-174.messagelabs.com!1323975102!5672044!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.5 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMDA4MjI=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMDA4MjI=\n,BODY_RANDOM_LONG,
	UPPERCASE_25_50
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31795 invoked from network); 15 Dec 2011 18:51:42 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-3.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 15 Dec 2011 18:51:42 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1323975102; l=597;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=dTdyNbiTPcqk1jcmO4OLozosdl8=;
	b=tfYEMTSyHGysOuisFAEJMZPzHOzF2F8UILp23bdi/xf8yjxPzaz/Kpx62c8fsd/MEUl
	sdfQZG/TNN/18iW2Q2oYmuaY6OMGWlmX3Vqw61XdkaRmbDXOFj2m+AEGsr60NgRqFgxsp
	62YFYZRyLKDKLsfT+X9r2/zdKUlTKAYl6b4=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lr3s7jGzY=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-067-089.pools.arcor-ip.net [84.57.67.89])
	by smtp.strato.de (cohen mo41) (RZmta 26.15 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id i034c6nBFGh3OA ;
	Thu, 15 Dec 2011 19:51:25 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id A811218637; Thu, 15 Dec 2011 19:51:24 +0100 (CET)
Date: Thu, 15 Dec 2011 19:51:24 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <20111215185124.GA30948@aepfle.de>
References: <3bac38f7a427af3eb9f6.1323871739@loki.upc.es>
	<20202.11863.501987.497546@mariner.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20202.11863.501987.497546@mariner.uk.xensource.com>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: Roger Pau Monne <roger.pau@entel.upc.edu>, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH v2] xenpaging: remove _XOPEN_SOURCE
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Dec 15, Ian Jackson wrote:

> Roger Pau Monne writes ("[Xen-devel] [PATCH v2] xenpaging: remove _XOPEN_SOURCE"):
> > xenpaging: remove _XOPEN_SOURCE
> > 
> > The _XOPEN_SOURCE define was breaking the compilation under NetBSD.
> > I've removed it becasue it is not necessary.
> 
> I thought we'd decided that _NETBSD_SOURCE should be added ?

The initial patch which added _XOPEN_SOURCE should have a reasonable
description which includes the error message, and it should have been
_GNU_SOURCE instead of _XOPEN_SOURCE in the first place.

Please remove _XOPEN_SOURCE.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 19:11:01 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 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.xensource.com>)
	id 1RbGhR-0007NB-Hh; Thu, 15 Dec 2011 19:10:37 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RbGhP-0007N6-Rt
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 19:10:36 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-14.tower-182.messagelabs.com!1323976212!7437879!1
X-Originating-IP: [63.239.65.40]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31174 invoked from network); 15 Dec 2011 19:10:29 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-14.tower-182.messagelabs.com with SMTP;
	15 Dec 2011 19:10:29 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea02.nsa.gov (8.12.10/8.12.10) with ESMTP id
	pBFJA5Jf026656; Thu, 15 Dec 2011 19:10:05 GMT
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id pBFJA5tB010864; 
	Thu, 15 Dec 2011 14:10:05 -0500
Message-ID: <4EEA4624.3080308@tycho.nsa.gov>
Date: Thu, 15 Dec 2011 14:10:28 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:7.0.1) Gecko/20110930 Thunderbird/7.0.1
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <1323808737-29125-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1323808737-29125-9-git-send-email-dgdegra@tycho.nsa.gov>
	<alpine.DEB.2.00.1112151639190.3517@kaball-desktop>
In-Reply-To: <alpine.DEB.2.00.1112151639190.3517@kaball-desktop>
X-Enigmail-Version: 1.3.2
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Keir Fraser <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH 8/8] xl.pod.1: improve documentation of
 FLASK commands
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 12/15/2011 11:46 AM, Stefano Stabellini wrote:
> On Tue, 13 Dec 2011, Daniel De Graaf wrote:
>> +=head2 FLASK
>> +
>> +=over 4
>> +
>> +=item B<getenforce>
>> +
>> +Determine if the FLASK security module is loaded and enforcing its policy.
>> +
>> +=item B<setenforce> I<1|0|Enforcing|Permissive>
>> +
>> +Enable or disable enforcing of the FLASK access controls. The default is
>> +permissive and can be changed using the flask_enforcing option on the
>> +hypervisor's command line.
>> +
>> +=item B<loadpolicy> I<policy-file>
>> +
>> +Load FLASK policy from the given policy file. The initial policy is provided to
>> +the hypervisor as a multiboot module; this command allows runtime updates to the
>> +policy. Loading new security policy will reset runtime changes to device labels.
> 
> Thanks for the patch!
> Since we are trying to improve the documentation for Xl, would you be up
> for writing a couple of more lines explaining why people might want to
> use XSM?

FLASK is a security framework that defines a mandatory access control policy
providing fine-grained controls over Xen domains, allowing the policy writer
to define what interactions between domains, devices, and the hypervisor are
permitted. Some example of what you can do using XSM/FLASK:
 - Prevent two domains from communicating via event channels or grants
 - Control which domains can use device passthrough (and which devices)
 - Restrict or audit operations performed by privileged domains
 - Prevent a privileged domain from arbitrarily mapping pages from other domains

Note that some of these examples require dom0 disaggregation to be useful, since
the domain build process requires the ability to write to the new domain's memory.

> In case there are some parameters to be used in the VM config
> file, could you please write a simple text file, like
> docs/misc/xl-network-configuration.markdown, describing which ones they
> are?

There is only one domain configuration parameter (the security label), which
I'm not sure is enough to justify its own file. If using the example policy,
"seclabel='system_u:system_r:domU_t'" would be used for PV domains, while
"seclabel='system_u:system_r:domHU_t'" would be used for HVM domains. A more
complex policy may have a different type for each domain.

It would be better to refer to existing SELinux documentation for an
explanation of the meanings of system_u, system_r, domU_t, and possible MLS
labels. For simple policies, the user and role portions of the label will
be unused and will always be "system_u:system_r".

> Finally it would be great if you could submit, as a separate patch, an
> example policy file that we can keep under tools/examples/ or docs/misc
> for everybody to use.

There is already an example policy file in tools/flask/policy/policy/modules/xen/xen.te
although it will likely require additional rules to be run in enforcing mode.
The policy is not built as part of the normal build process, but it can be
built by running "make -C tools/flask/policy". If using Fedora 16 (or systems
with a checkpolicy version >24) the Makefile will need to be adjusted to
produce policy version 24 which is the latest version supported by Xen.

-- 
Daniel De Graaf
National Security Agency

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 19:11:01 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 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.xensource.com>)
	id 1RbGhR-0007NB-Hh; Thu, 15 Dec 2011 19:10:37 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RbGhP-0007N6-Rt
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 19:10:36 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-14.tower-182.messagelabs.com!1323976212!7437879!1
X-Originating-IP: [63.239.65.40]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31174 invoked from network); 15 Dec 2011 19:10:29 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-14.tower-182.messagelabs.com with SMTP;
	15 Dec 2011 19:10:29 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea02.nsa.gov (8.12.10/8.12.10) with ESMTP id
	pBFJA5Jf026656; Thu, 15 Dec 2011 19:10:05 GMT
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id pBFJA5tB010864; 
	Thu, 15 Dec 2011 14:10:05 -0500
Message-ID: <4EEA4624.3080308@tycho.nsa.gov>
Date: Thu, 15 Dec 2011 14:10:28 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:7.0.1) Gecko/20110930 Thunderbird/7.0.1
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <1323808737-29125-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1323808737-29125-9-git-send-email-dgdegra@tycho.nsa.gov>
	<alpine.DEB.2.00.1112151639190.3517@kaball-desktop>
In-Reply-To: <alpine.DEB.2.00.1112151639190.3517@kaball-desktop>
X-Enigmail-Version: 1.3.2
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Keir Fraser <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH 8/8] xl.pod.1: improve documentation of
 FLASK commands
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 12/15/2011 11:46 AM, Stefano Stabellini wrote:
> On Tue, 13 Dec 2011, Daniel De Graaf wrote:
>> +=head2 FLASK
>> +
>> +=over 4
>> +
>> +=item B<getenforce>
>> +
>> +Determine if the FLASK security module is loaded and enforcing its policy.
>> +
>> +=item B<setenforce> I<1|0|Enforcing|Permissive>
>> +
>> +Enable or disable enforcing of the FLASK access controls. The default is
>> +permissive and can be changed using the flask_enforcing option on the
>> +hypervisor's command line.
>> +
>> +=item B<loadpolicy> I<policy-file>
>> +
>> +Load FLASK policy from the given policy file. The initial policy is provided to
>> +the hypervisor as a multiboot module; this command allows runtime updates to the
>> +policy. Loading new security policy will reset runtime changes to device labels.
> 
> Thanks for the patch!
> Since we are trying to improve the documentation for Xl, would you be up
> for writing a couple of more lines explaining why people might want to
> use XSM?

FLASK is a security framework that defines a mandatory access control policy
providing fine-grained controls over Xen domains, allowing the policy writer
to define what interactions between domains, devices, and the hypervisor are
permitted. Some example of what you can do using XSM/FLASK:
 - Prevent two domains from communicating via event channels or grants
 - Control which domains can use device passthrough (and which devices)
 - Restrict or audit operations performed by privileged domains
 - Prevent a privileged domain from arbitrarily mapping pages from other domains

Note that some of these examples require dom0 disaggregation to be useful, since
the domain build process requires the ability to write to the new domain's memory.

> In case there are some parameters to be used in the VM config
> file, could you please write a simple text file, like
> docs/misc/xl-network-configuration.markdown, describing which ones they
> are?

There is only one domain configuration parameter (the security label), which
I'm not sure is enough to justify its own file. If using the example policy,
"seclabel='system_u:system_r:domU_t'" would be used for PV domains, while
"seclabel='system_u:system_r:domHU_t'" would be used for HVM domains. A more
complex policy may have a different type for each domain.

It would be better to refer to existing SELinux documentation for an
explanation of the meanings of system_u, system_r, domU_t, and possible MLS
labels. For simple policies, the user and role portions of the label will
be unused and will always be "system_u:system_r".

> Finally it would be great if you could submit, as a separate patch, an
> example policy file that we can keep under tools/examples/ or docs/misc
> for everybody to use.

There is already an example policy file in tools/flask/policy/policy/modules/xen/xen.te
although it will likely require additional rules to be run in enforcing mode.
The policy is not built as part of the normal build process, but it can be
built by running "make -C tools/flask/policy". If using Fedora 16 (or systems
with a checkpolicy version >24) the Makefile will need to be adjusted to
produce policy version 24 which is the latest version supported by Xen.

-- 
Daniel De Graaf
National Security Agency

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 19:20:54 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 19:20:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbGr3-0007Zm-Fa; Thu, 15 Dec 2011 19:20:33 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <stefan.bader@canonical.com>) id 1RbGr2-0007ZZ-9g
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 19:20:32 +0000
X-Env-Sender: stefan.bader@canonical.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1323976825!5558934!1
X-Originating-IP: [91.189.89.112]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20459 invoked from network); 15 Dec 2011 19:20:25 -0000
Received: from youngberry.canonical.com (HELO youngberry.canonical.com)
	(91.189.89.112) by server-16.tower-174.messagelabs.com with SMTP;
	15 Dec 2011 19:20:25 -0000
Received: from p5b2e3fb5.dip.t-dialin.net ([91.46.63.181] helo=[192.168.2.5])
	by youngberry.canonical.com with esmtpsa
	(TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71)
	(envelope-from <stefan.bader@canonical.com>)
	id 1RbGqv-00024S-4X; Thu, 15 Dec 2011 19:20:25 +0000
Message-ID: <4EEA4877.8010307@canonical.com>
Date: Thu, 15 Dec 2011 20:20:23 +0100
From: Stefan Bader <stefan.bader@canonical.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:8.0) Gecko/20111124 Thunderbird/8.0
MIME-Version: 1.0
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
X-Enigmail-Version: 1.4a1pre
Cc: Olaf Hering <olaf@aepfle.de>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] xenbus and the message of doom
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

I was investigating a bug report[1] about newer kernels (>3.1) not booting as
HVM guests on Amazon EC2. For some reason git bisect did give the some pain, but
it lead me at least close and with some crash dump data I think I figured the
problem.

commit ddacf5ef684a655abe2bb50c4b2a5b72ae0d5e05
Author: Olaf Hering <olaf@aepfle.de>
Date:   Thu Sep 22 16:14:49 2011 +0200

    xen/pv-on-hvm kexec: add xs_reset_watches to shutdown watches from old
    kernel

This change introduced a xs_reset_watches() call. The problem seems to be that
there is at least some version of Xen (I was able to reproduce with a 3.4.3
version which I admit to deliberately not having updated) for which xenstore
will not return any reply.

At least the backtraces in crash showed that xs_init had been calling
xs_reset_watches() and that was happily idling in read_reply(). Effectively
nothing was going on and the boot just hung.
By just not doing that xs_reset_watches() call, I was able to boot under the
same host. And for what it is worth there has not been an issue with Xen 4.1.1
and a 3.0 dom0 kernel. Just this "older" release is trouble.

Now the big question is, should this never happen and the host needs urgent
updating. Or, should xs_talkv() set up a time limit and assume failure when not
receiving a message after that? I could imagine the latter might lead at least
to a more helpful "there is something wrong here, dude" than just hanging around
without any response. ;)

-Stefan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 19:20:54 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 19:20:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbGr3-0007Zm-Fa; Thu, 15 Dec 2011 19:20:33 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <stefan.bader@canonical.com>) id 1RbGr2-0007ZZ-9g
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 19:20:32 +0000
X-Env-Sender: stefan.bader@canonical.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1323976825!5558934!1
X-Originating-IP: [91.189.89.112]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20459 invoked from network); 15 Dec 2011 19:20:25 -0000
Received: from youngberry.canonical.com (HELO youngberry.canonical.com)
	(91.189.89.112) by server-16.tower-174.messagelabs.com with SMTP;
	15 Dec 2011 19:20:25 -0000
Received: from p5b2e3fb5.dip.t-dialin.net ([91.46.63.181] helo=[192.168.2.5])
	by youngberry.canonical.com with esmtpsa
	(TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71)
	(envelope-from <stefan.bader@canonical.com>)
	id 1RbGqv-00024S-4X; Thu, 15 Dec 2011 19:20:25 +0000
Message-ID: <4EEA4877.8010307@canonical.com>
Date: Thu, 15 Dec 2011 20:20:23 +0100
From: Stefan Bader <stefan.bader@canonical.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:8.0) Gecko/20111124 Thunderbird/8.0
MIME-Version: 1.0
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
X-Enigmail-Version: 1.4a1pre
Cc: Olaf Hering <olaf@aepfle.de>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] xenbus and the message of doom
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

I was investigating a bug report[1] about newer kernels (>3.1) not booting as
HVM guests on Amazon EC2. For some reason git bisect did give the some pain, but
it lead me at least close and with some crash dump data I think I figured the
problem.

commit ddacf5ef684a655abe2bb50c4b2a5b72ae0d5e05
Author: Olaf Hering <olaf@aepfle.de>
Date:   Thu Sep 22 16:14:49 2011 +0200

    xen/pv-on-hvm kexec: add xs_reset_watches to shutdown watches from old
    kernel

This change introduced a xs_reset_watches() call. The problem seems to be that
there is at least some version of Xen (I was able to reproduce with a 3.4.3
version which I admit to deliberately not having updated) for which xenstore
will not return any reply.

At least the backtraces in crash showed that xs_init had been calling
xs_reset_watches() and that was happily idling in read_reply(). Effectively
nothing was going on and the boot just hung.
By just not doing that xs_reset_watches() call, I was able to boot under the
same host. And for what it is worth there has not been an issue with Xen 4.1.1
and a 3.0 dom0 kernel. Just this "older" release is trouble.

Now the big question is, should this never happen and the host needs urgent
updating. Or, should xs_talkv() set up a time limit and assume failure when not
receiving a message after that? I could imagine the latter might lead at least
to a more helpful "there is something wrong here, dude" than just hanging around
without any response. ;)

-Stefan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 19:40:23 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 19:40:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbH9o-00088H-9O; Thu, 15 Dec 2011 19:39:56 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1RbH9m-00087k-BD
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 19:39:54 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-7.tower-216.messagelabs.com!1323977987!7639247!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26734 invoked from network); 15 Dec 2011 19:39:48 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-7.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 15 Dec 2011 19:39:48 -0000
Received: from andromeda.dapyr.net (darnok@localhost [127.0.0.1])
	by andromeda.dapyr.net (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id
	pBFJdhlF007950
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Thu, 15 Dec 2011 14:39:43 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pBFJdgw2007948;
	Thu, 15 Dec 2011 14:39:42 -0500
Date: Thu, 15 Dec 2011 15:39:42 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Stefan Bader <stefan.bader@canonical.com>
Message-ID: <20111215193942.GA7640@andromeda.dapyr.net>
References: <4EEA4877.8010307@canonical.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4EEA4877.8010307@canonical.com>
User-Agent: Mutt/1.5.9i
Cc: Olaf Hering <olaf@aepfle.de>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] xenbus and the message of doom
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Dec 15, 2011 at 08:20:23PM +0100, Stefan Bader wrote:
> I was investigating a bug report[1] about newer kernels (>3.1) not booting as
> HVM guests on Amazon EC2. For some reason git bisect did give the some pain, but
> it lead me at least close and with some crash dump data I think I figured the
> problem.

Stefan, thanks for finding this.

Olaf, what are your thoughts? Should I prep a patch to revert the patch
below and then we can work on 3.3 and rethink this in 3.3? The clock is
ticking for 3.2 and there is not much runway to fix stuff.

> 
> commit ddacf5ef684a655abe2bb50c4b2a5b72ae0d5e05
> Author: Olaf Hering <olaf@aepfle.de>
> Date:   Thu Sep 22 16:14:49 2011 +0200
> 
>     xen/pv-on-hvm kexec: add xs_reset_watches to shutdown watches from old
>     kernel
> 
> This change introduced a xs_reset_watches() call. The problem seems to be that
> there is at least some version of Xen (I was able to reproduce with a 3.4.3
> version which I admit to deliberately not having updated) for which xenstore
> will not return any reply.

And oxenstore too, but Ian prepped a patch for this. Perhaps that is
what Amazon is running.
> 
> At least the backtraces in crash showed that xs_init had been calling
> xs_reset_watches() and that was happily idling in read_reply(). Effectively
> nothing was going on and the boot just hung.

So at least we should have a timeout read_reply. But I don't see
anything in the code that we could immediately use.

> By just not doing that xs_reset_watches() call, I was able to boot under the
> same host. And for what it is worth there has not been an issue with Xen 4.1.1
> and a 3.0 dom0 kernel. Just this "older" release is trouble.
> 
> Now the big question is, should this never happen and the host needs urgent
> updating. Or, should xs_talkv() set up a time limit and assume failure when not
> receiving a message after that? I could imagine the latter might lead at least
> to a more helpful "there is something wrong here, dude" than just hanging around
> without any response. ;)
> 
> -Stefan
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 19:40:23 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 19:40:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbH9o-00088H-9O; Thu, 15 Dec 2011 19:39:56 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1RbH9m-00087k-BD
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 19:39:54 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-7.tower-216.messagelabs.com!1323977987!7639247!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26734 invoked from network); 15 Dec 2011 19:39:48 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-7.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 15 Dec 2011 19:39:48 -0000
Received: from andromeda.dapyr.net (darnok@localhost [127.0.0.1])
	by andromeda.dapyr.net (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id
	pBFJdhlF007950
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Thu, 15 Dec 2011 14:39:43 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pBFJdgw2007948;
	Thu, 15 Dec 2011 14:39:42 -0500
Date: Thu, 15 Dec 2011 15:39:42 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Stefan Bader <stefan.bader@canonical.com>
Message-ID: <20111215193942.GA7640@andromeda.dapyr.net>
References: <4EEA4877.8010307@canonical.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4EEA4877.8010307@canonical.com>
User-Agent: Mutt/1.5.9i
Cc: Olaf Hering <olaf@aepfle.de>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] xenbus and the message of doom
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Dec 15, 2011 at 08:20:23PM +0100, Stefan Bader wrote:
> I was investigating a bug report[1] about newer kernels (>3.1) not booting as
> HVM guests on Amazon EC2. For some reason git bisect did give the some pain, but
> it lead me at least close and with some crash dump data I think I figured the
> problem.

Stefan, thanks for finding this.

Olaf, what are your thoughts? Should I prep a patch to revert the patch
below and then we can work on 3.3 and rethink this in 3.3? The clock is
ticking for 3.2 and there is not much runway to fix stuff.

> 
> commit ddacf5ef684a655abe2bb50c4b2a5b72ae0d5e05
> Author: Olaf Hering <olaf@aepfle.de>
> Date:   Thu Sep 22 16:14:49 2011 +0200
> 
>     xen/pv-on-hvm kexec: add xs_reset_watches to shutdown watches from old
>     kernel
> 
> This change introduced a xs_reset_watches() call. The problem seems to be that
> there is at least some version of Xen (I was able to reproduce with a 3.4.3
> version which I admit to deliberately not having updated) for which xenstore
> will not return any reply.

And oxenstore too, but Ian prepped a patch for this. Perhaps that is
what Amazon is running.
> 
> At least the backtraces in crash showed that xs_init had been calling
> xs_reset_watches() and that was happily idling in read_reply(). Effectively
> nothing was going on and the boot just hung.

So at least we should have a timeout read_reply. But I don't see
anything in the code that we could immediately use.

> By just not doing that xs_reset_watches() call, I was able to boot under the
> same host. And for what it is worth there has not been an issue with Xen 4.1.1
> and a 3.0 dom0 kernel. Just this "older" release is trouble.
> 
> Now the big question is, should this never happen and the host needs urgent
> updating. Or, should xs_talkv() set up a time limit and assume failure when not
> receiving a message after that? I could imagine the latter might lead at least
> to a more helpful "there is something wrong here, dude" than just hanging around
> without any response. ;)
> 
> -Stefan
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 19:46:30 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 19:46:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbHFo-0008OW-3r; Thu, 15 Dec 2011 19:46:08 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <stefan.bader@canonical.com>) id 1RbHFm-0008OL-MM
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 19:46:06 +0000
X-Env-Sender: stefan.bader@canonical.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1323978360!5727334!1
X-Originating-IP: [91.189.89.112]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31461 invoked from network); 15 Dec 2011 19:46:00 -0000
Received: from youngberry.canonical.com (HELO youngberry.canonical.com)
	(91.189.89.112) by server-13.tower-174.messagelabs.com with SMTP;
	15 Dec 2011 19:46:00 -0000
Received: from p5b2e3fb5.dip.t-dialin.net ([91.46.63.181] helo=[192.168.2.5])
	by youngberry.canonical.com with esmtpsa
	(TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71)
	(envelope-from <stefan.bader@canonical.com>)
	id 1RbHFd-0002wz-0B; Thu, 15 Dec 2011 19:45:57 +0000
Message-ID: <4EEA4E73.9030002@canonical.com>
Date: Thu, 15 Dec 2011 20:45:55 +0100
From: Stefan Bader <stefan.bader@canonical.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:8.0) Gecko/20111124 Thunderbird/8.0
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
References: <4EEA4877.8010307@canonical.com>
	<20111215193942.GA7640@andromeda.dapyr.net>
In-Reply-To: <20111215193942.GA7640@andromeda.dapyr.net>
X-Enigmail-Version: 1.4a1pre
Cc: Olaf Hering <olaf@aepfle.de>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] xenbus and the message of doom
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 15.12.2011 20:39, Konrad Rzeszutek Wilk wrote:
> On Thu, Dec 15, 2011 at 08:20:23PM +0100, Stefan Bader wrote:
>> I was investigating a bug report[1] about newer kernels (>3.1) not booting as
>> HVM guests on Amazon EC2. For some reason git bisect did give the some pain, but
>> it lead me at least close and with some crash dump data I think I figured the
>> problem.
> 
> Stefan, thanks for finding this.
> 

I realize I wanted to add the reference to our bug report but completely forgot
to do so. So just for completeness:

http://bugs.launchpad.net/bugs/901305


> Olaf, what are your thoughts? Should I prep a patch to revert the patch
> below and then we can work on 3.3 and rethink this in 3.3? The clock is
> ticking for 3.2 and there is not much runway to fix stuff.
> 
>>
>> commit ddacf5ef684a655abe2bb50c4b2a5b72ae0d5e05
>> Author: Olaf Hering <olaf@aepfle.de>
>> Date:   Thu Sep 22 16:14:49 2011 +0200
>>
>>     xen/pv-on-hvm kexec: add xs_reset_watches to shutdown watches from old
>>     kernel
>>
>> This change introduced a xs_reset_watches() call. The problem seems to be that
>> there is at least some version of Xen (I was able to reproduce with a 3.4.3
>> version which I admit to deliberately not having updated) for which xenstore
>> will not return any reply.
> 
> And oxenstore too, but Ian prepped a patch for this. Perhaps that is
> what Amazon is running.
>>
>> At least the backtraces in crash showed that xs_init had been calling
>> xs_reset_watches() and that was happily idling in read_reply(). Effectively
>> nothing was going on and the boot just hung.
> 
> So at least we should have a timeout read_reply. But I don't see
> anything in the code that we could immediately use.
> 
>> By just not doing that xs_reset_watches() call, I was able to boot under the
>> same host. And for what it is worth there has not been an issue with Xen 4.1.1
>> and a 3.0 dom0 kernel. Just this "older" release is trouble.
>>
>> Now the big question is, should this never happen and the host needs urgent
>> updating. Or, should xs_talkv() set up a time limit and assume failure when not
>> receiving a message after that? I could imagine the latter might lead at least
>> to a more helpful "there is something wrong here, dude" than just hanging around
>> without any response. ;)
>>
>> -Stefan
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 19:46:30 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 19:46:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbHFo-0008OW-3r; Thu, 15 Dec 2011 19:46:08 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <stefan.bader@canonical.com>) id 1RbHFm-0008OL-MM
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 19:46:06 +0000
X-Env-Sender: stefan.bader@canonical.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1323978360!5727334!1
X-Originating-IP: [91.189.89.112]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31461 invoked from network); 15 Dec 2011 19:46:00 -0000
Received: from youngberry.canonical.com (HELO youngberry.canonical.com)
	(91.189.89.112) by server-13.tower-174.messagelabs.com with SMTP;
	15 Dec 2011 19:46:00 -0000
Received: from p5b2e3fb5.dip.t-dialin.net ([91.46.63.181] helo=[192.168.2.5])
	by youngberry.canonical.com with esmtpsa
	(TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71)
	(envelope-from <stefan.bader@canonical.com>)
	id 1RbHFd-0002wz-0B; Thu, 15 Dec 2011 19:45:57 +0000
Message-ID: <4EEA4E73.9030002@canonical.com>
Date: Thu, 15 Dec 2011 20:45:55 +0100
From: Stefan Bader <stefan.bader@canonical.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:8.0) Gecko/20111124 Thunderbird/8.0
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
References: <4EEA4877.8010307@canonical.com>
	<20111215193942.GA7640@andromeda.dapyr.net>
In-Reply-To: <20111215193942.GA7640@andromeda.dapyr.net>
X-Enigmail-Version: 1.4a1pre
Cc: Olaf Hering <olaf@aepfle.de>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] xenbus and the message of doom
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 15.12.2011 20:39, Konrad Rzeszutek Wilk wrote:
> On Thu, Dec 15, 2011 at 08:20:23PM +0100, Stefan Bader wrote:
>> I was investigating a bug report[1] about newer kernels (>3.1) not booting as
>> HVM guests on Amazon EC2. For some reason git bisect did give the some pain, but
>> it lead me at least close and with some crash dump data I think I figured the
>> problem.
> 
> Stefan, thanks for finding this.
> 

I realize I wanted to add the reference to our bug report but completely forgot
to do so. So just for completeness:

http://bugs.launchpad.net/bugs/901305


> Olaf, what are your thoughts? Should I prep a patch to revert the patch
> below and then we can work on 3.3 and rethink this in 3.3? The clock is
> ticking for 3.2 and there is not much runway to fix stuff.
> 
>>
>> commit ddacf5ef684a655abe2bb50c4b2a5b72ae0d5e05
>> Author: Olaf Hering <olaf@aepfle.de>
>> Date:   Thu Sep 22 16:14:49 2011 +0200
>>
>>     xen/pv-on-hvm kexec: add xs_reset_watches to shutdown watches from old
>>     kernel
>>
>> This change introduced a xs_reset_watches() call. The problem seems to be that
>> there is at least some version of Xen (I was able to reproduce with a 3.4.3
>> version which I admit to deliberately not having updated) for which xenstore
>> will not return any reply.
> 
> And oxenstore too, but Ian prepped a patch for this. Perhaps that is
> what Amazon is running.
>>
>> At least the backtraces in crash showed that xs_init had been calling
>> xs_reset_watches() and that was happily idling in read_reply(). Effectively
>> nothing was going on and the boot just hung.
> 
> So at least we should have a timeout read_reply. But I don't see
> anything in the code that we could immediately use.
> 
>> By just not doing that xs_reset_watches() call, I was able to boot under the
>> same host. And for what it is worth there has not been an issue with Xen 4.1.1
>> and a 3.0 dom0 kernel. Just this "older" release is trouble.
>>
>> Now the big question is, should this never happen and the host needs urgent
>> updating. Or, should xs_talkv() set up a time limit and assume failure when not
>> receiving a message after that? I could imagine the latter might lead at least
>> to a more helpful "there is something wrong here, dude" than just hanging around
>> without any response. ;)
>>
>> -Stefan
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 20:54:46 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 20: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.xensource.com>)
	id 1RbIJa-0000qA-2I; Thu, 15 Dec 2011 20:54:06 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RbIJX-0000q5-W1
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 20:54:04 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1323982412!45072801!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjI2MA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31851 invoked from network); 15 Dec 2011 20:53:32 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 20:53:32 -0000
X-IronPort-AV: E=Sophos;i="4.71,359,1320624000"; 
   d="scan'208";a="9500890"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Dec 2011 20:53:38 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 15 Dec 2011 20:53:38 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefan Bader <stefan.bader@canonical.com>
In-Reply-To: <4EEA4877.8010307@canonical.com>
References: <4EEA4877.8010307@canonical.com>
Organization: Citrix Systems, Inc.
Date: Thu, 15 Dec 2011 20:53:37 +0000
Message-ID: <1323982417.20936.898.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
X-Mailer: Evolution 2.32.3 
Cc: Olaf Hering <olaf@aepfle.de>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] xenbus and the message of doom
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2011-12-15 at 19:20 +0000, Stefan Bader wrote:
> I was investigating a bug report[1] about newer kernels (>3.1) not booting as
> HVM guests on Amazon EC2. For some reason git bisect did give the some pain, but
> it lead me at least close and with some crash dump data I think I figured the
> problem.
> 
> commit ddacf5ef684a655abe2bb50c4b2a5b72ae0d5e05
> Author: Olaf Hering <olaf@aepfle.de>
> Date:   Thu Sep 22 16:14:49 2011 +0200
> 
>     xen/pv-on-hvm kexec: add xs_reset_watches to shutdown watches from old
>     kernel
> 
> This change introduced a xs_reset_watches() call. The problem seems to be that
> there is at least some version of Xen (I was able to reproduce with a 3.4.3
> version which I admit to deliberately not having updated) for which xenstore
> will not return any reply.
> 
> At least the backtraces in crash showed that xs_init had been calling
> xs_reset_watches() and that was happily idling in read_reply(). Effectively
> nothing was going on and the boot just hung.
> By just not doing that xs_reset_watches() call, I was able to boot under the
> same host. And for what it is worth there has not been an issue with Xen 4.1.1
> and a 3.0 dom0 kernel. Just this "older" release is trouble.

I sent a patch to fix exactly this issue in oxenstored (the ocaml
xenstore) just this week. Is there any chance that you are running C
xenstored with Xen 4.1.1 and oxenstored with Xen 3.4.3?

> Now the big question is, should this never happen and the host needs urgent
> updating. Or, should xs_talkv() set up a time limit and assume failure when not
> receiving a message after that? I could imagine the latter might lead at least
> to a more helpful "there is something wrong here, dude" than just hanging around
> without any response. ;)
> 
> -Stefan
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 20:54:46 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 20: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.xensource.com>)
	id 1RbIJa-0000qA-2I; Thu, 15 Dec 2011 20:54:06 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RbIJX-0000q5-W1
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 20:54:04 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1323982412!45072801!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjI2MA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31851 invoked from network); 15 Dec 2011 20:53:32 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2011 20:53:32 -0000
X-IronPort-AV: E=Sophos;i="4.71,359,1320624000"; 
   d="scan'208";a="9500890"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Dec 2011 20:53:38 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 15 Dec 2011 20:53:38 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefan Bader <stefan.bader@canonical.com>
In-Reply-To: <4EEA4877.8010307@canonical.com>
References: <4EEA4877.8010307@canonical.com>
Organization: Citrix Systems, Inc.
Date: Thu, 15 Dec 2011 20:53:37 +0000
Message-ID: <1323982417.20936.898.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
X-Mailer: Evolution 2.32.3 
Cc: Olaf Hering <olaf@aepfle.de>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] xenbus and the message of doom
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2011-12-15 at 19:20 +0000, Stefan Bader wrote:
> I was investigating a bug report[1] about newer kernels (>3.1) not booting as
> HVM guests on Amazon EC2. For some reason git bisect did give the some pain, but
> it lead me at least close and with some crash dump data I think I figured the
> problem.
> 
> commit ddacf5ef684a655abe2bb50c4b2a5b72ae0d5e05
> Author: Olaf Hering <olaf@aepfle.de>
> Date:   Thu Sep 22 16:14:49 2011 +0200
> 
>     xen/pv-on-hvm kexec: add xs_reset_watches to shutdown watches from old
>     kernel
> 
> This change introduced a xs_reset_watches() call. The problem seems to be that
> there is at least some version of Xen (I was able to reproduce with a 3.4.3
> version which I admit to deliberately not having updated) for which xenstore
> will not return any reply.
> 
> At least the backtraces in crash showed that xs_init had been calling
> xs_reset_watches() and that was happily idling in read_reply(). Effectively
> nothing was going on and the boot just hung.
> By just not doing that xs_reset_watches() call, I was able to boot under the
> same host. And for what it is worth there has not been an issue with Xen 4.1.1
> and a 3.0 dom0 kernel. Just this "older" release is trouble.

I sent a patch to fix exactly this issue in oxenstored (the ocaml
xenstore) just this week. Is there any chance that you are running C
xenstored with Xen 4.1.1 and oxenstored with Xen 3.4.3?

> Now the big question is, should this never happen and the host needs urgent
> updating. Or, should xs_talkv() set up a time limit and assume failure when not
> receiving a message after that? I could imagine the latter might lead at least
> to a more helpful "there is something wrong here, dude" than just hanging around
> without any response. ;)
> 
> -Stefan
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 20:58:08 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 20: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.xensource.com>)
	id 1RbIMx-0000wF-Mv; Thu, 15 Dec 2011 20:57:35 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1RbIMw-0000w6-QP
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 20:57:35 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-16.tower-216.messagelabs.com!1323982646!7512908!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12738 invoked from network); 15 Dec 2011 20:57:27 -0000
Received: from unknown (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-16.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 15 Dec 2011 20:57:27 -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
	pBFKusrG012230
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Thu, 15 Dec 2011 15:56:54 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pBFKusdl012228;
	Thu, 15 Dec 2011 15:56:54 -0500
Date: Thu, 15 Dec 2011 16:56:54 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Message-ID: <20111215205654.GA11829@andromeda.dapyr.net>
References: <1323808737-29125-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1323808737-29125-9-git-send-email-dgdegra@tycho.nsa.gov>
	<alpine.DEB.2.00.1112151639190.3517@kaball-desktop>
	<4EEA4624.3080308@tycho.nsa.gov>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4EEA4624.3080308@tycho.nsa.gov>
User-Agent: Mutt/1.5.9i
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Keir Fraser <keir@xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 8/8] xl.pod.1: improve documentation of
	FLASK commands
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> There is already an example policy file in tools/flask/policy/policy/modules/xen/xen.te
> although it will likely require additional rules to be run in enforcing mode.
> The policy is not built as part of the normal build process, but it can be
> built by running "make -C tools/flask/policy". If using Fedora 16 (or systems
> with a checkpolicy version >24) the Makefile will need to be adjusted to
> produce policy version 24 which is the latest version supported by Xen.

Is there a howto on how to use it for newbies? Or how to apply policies
against a domain? Would it make sense to have that as part of the 'man
xl' ?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 20:58:08 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 20: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.xensource.com>)
	id 1RbIMx-0000wF-Mv; Thu, 15 Dec 2011 20:57:35 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1RbIMw-0000w6-QP
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 20:57:35 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-16.tower-216.messagelabs.com!1323982646!7512908!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12738 invoked from network); 15 Dec 2011 20:57:27 -0000
Received: from unknown (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-16.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 15 Dec 2011 20:57:27 -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
	pBFKusrG012230
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Thu, 15 Dec 2011 15:56:54 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pBFKusdl012228;
	Thu, 15 Dec 2011 15:56:54 -0500
Date: Thu, 15 Dec 2011 16:56:54 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Message-ID: <20111215205654.GA11829@andromeda.dapyr.net>
References: <1323808737-29125-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1323808737-29125-9-git-send-email-dgdegra@tycho.nsa.gov>
	<alpine.DEB.2.00.1112151639190.3517@kaball-desktop>
	<4EEA4624.3080308@tycho.nsa.gov>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4EEA4624.3080308@tycho.nsa.gov>
User-Agent: Mutt/1.5.9i
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Keir Fraser <keir@xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 8/8] xl.pod.1: improve documentation of
	FLASK commands
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> There is already an example policy file in tools/flask/policy/policy/modules/xen/xen.te
> although it will likely require additional rules to be run in enforcing mode.
> The policy is not built as part of the normal build process, but it can be
> built by running "make -C tools/flask/policy". If using Fedora 16 (or systems
> with a checkpolicy version >24) the Makefile will need to be adjusted to
> produce policy version 24 which is the latest version supported by Xen.

Is there a howto on how to use it for newbies? Or how to apply policies
against a domain? Would it make sense to have that as part of the 'man
xl' ?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 21:12:57 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 21:12:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbIbO-0001LU-4s; Thu, 15 Dec 2011 21:12:30 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1RbIbM-0001LP-W5
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 21:12:29 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-3.tower-182.messagelabs.com!1323983540!7467670!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24526 invoked from network); 15 Dec 2011 21:12:21 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-3.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 15 Dec 2011 21:12:21 -0000
Received: from andromeda.dapyr.net (darnok@localhost [127.0.0.1])
	by andromeda.dapyr.net (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id
	pBFLCJ31015629
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Thu, 15 Dec 2011 16:12:19 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pBFLCIsH015627;
	Thu, 15 Dec 2011 16:12:19 -0500
Date: Thu, 15 Dec 2011 17:12:18 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Anthony Wright <anthony@overnetdata.com>
Message-ID: <20111215211218.GA15407@andromeda.dapyr.net>
References: <4EE0A6C7.9080603@overnetdata.com>
	<20111214213819.GD25896@andromeda.dapyr.net>
	<4EEA1818.6060106@overnetdata.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4EEA1818.6060106@overnetdata.com>
User-Agent: Mutt/1.5.9i
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] VGA Passthrough crashes machine
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Dec 15, 2011 at 03:54:00PM +0000, Anthony Wright wrote:
> On 14/12/2011 21:38, Konrad Rzeszutek Wilk wrote:
> > On Thu, Dec 08, 2011 at 12:00:07PM +0000, Anthony Wright wrote:
> >> I've just had my first attempt at getting VGA passthrough to work, and
> >> it crashed the machine. I'm trying to understand whether this is a
> >> problem with my hardware, configuration or a software problem.
> >>
> >> I'm running Xen 4.1.2 with Linux 3.1.2
> >>
> >>
> >> The CPU is an Intel Core i5-650
> >> http://ark.intel.com/products/43546/Intel-Core-i5-650-Processor-%284M-Cache-3_20-GHz%29
> > And what is your motherboard? Does it have VT-d?
> That was the important question... I'd missed the BIOS option to enable
> VT-d which was disabled by default. I enabled the BIOS option and
> everything worked, and it's very cool. :-)
> 
> This does beg a couple of other questions though....
> 
> Shouldn't I get a nice(ish) error message if I try to start a VGA
> passthrough VM on hardware that doesn't support it rather than crashing
> the machine?


There is this http://wiki.xen.org/xenwiki/VTdHowTo which gives you a
nice idea of what works.
> 
> Can I tell whether hardware will support VGA passthrough without trying
> to start a VM that uses it?
> 
> Also when I shut down the VM I have to use 'xl destroy' as I'm testing
> with Windows. After issuing the 'xl destroy' there is a long pause and
> then the error:
> 
>     libxl: error: libxl_device.c:470:libxl__wait_for_device_model Device
> Model not ready
>     libxl: error: libxl_pci.c:892:do_pci_remove Device Model didn't
> respond in time
> 
> If I pass through more than one device, I get the pause and the message
> for each device.

Hm, it looks to be sending 'pci-rem' to the XenStore, but I am not sure
if QEMU understands it. Did you compile Xen 4.1.2 by yourself? Did it
compile with CONFIG_PASSTHROUGH?

You should see some messages in the qemu.log about hot-remove and such.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 21:12:57 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 21:12:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbIbO-0001LU-4s; Thu, 15 Dec 2011 21:12:30 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1RbIbM-0001LP-W5
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 21:12:29 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-3.tower-182.messagelabs.com!1323983540!7467670!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24526 invoked from network); 15 Dec 2011 21:12:21 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-3.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 15 Dec 2011 21:12:21 -0000
Received: from andromeda.dapyr.net (darnok@localhost [127.0.0.1])
	by andromeda.dapyr.net (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id
	pBFLCJ31015629
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Thu, 15 Dec 2011 16:12:19 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pBFLCIsH015627;
	Thu, 15 Dec 2011 16:12:19 -0500
Date: Thu, 15 Dec 2011 17:12:18 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Anthony Wright <anthony@overnetdata.com>
Message-ID: <20111215211218.GA15407@andromeda.dapyr.net>
References: <4EE0A6C7.9080603@overnetdata.com>
	<20111214213819.GD25896@andromeda.dapyr.net>
	<4EEA1818.6060106@overnetdata.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4EEA1818.6060106@overnetdata.com>
User-Agent: Mutt/1.5.9i
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] VGA Passthrough crashes machine
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Dec 15, 2011 at 03:54:00PM +0000, Anthony Wright wrote:
> On 14/12/2011 21:38, Konrad Rzeszutek Wilk wrote:
> > On Thu, Dec 08, 2011 at 12:00:07PM +0000, Anthony Wright wrote:
> >> I've just had my first attempt at getting VGA passthrough to work, and
> >> it crashed the machine. I'm trying to understand whether this is a
> >> problem with my hardware, configuration or a software problem.
> >>
> >> I'm running Xen 4.1.2 with Linux 3.1.2
> >>
> >>
> >> The CPU is an Intel Core i5-650
> >> http://ark.intel.com/products/43546/Intel-Core-i5-650-Processor-%284M-Cache-3_20-GHz%29
> > And what is your motherboard? Does it have VT-d?
> That was the important question... I'd missed the BIOS option to enable
> VT-d which was disabled by default. I enabled the BIOS option and
> everything worked, and it's very cool. :-)
> 
> This does beg a couple of other questions though....
> 
> Shouldn't I get a nice(ish) error message if I try to start a VGA
> passthrough VM on hardware that doesn't support it rather than crashing
> the machine?


There is this http://wiki.xen.org/xenwiki/VTdHowTo which gives you a
nice idea of what works.
> 
> Can I tell whether hardware will support VGA passthrough without trying
> to start a VM that uses it?
> 
> Also when I shut down the VM I have to use 'xl destroy' as I'm testing
> with Windows. After issuing the 'xl destroy' there is a long pause and
> then the error:
> 
>     libxl: error: libxl_device.c:470:libxl__wait_for_device_model Device
> Model not ready
>     libxl: error: libxl_pci.c:892:do_pci_remove Device Model didn't
> respond in time
> 
> If I pass through more than one device, I get the pause and the message
> for each device.

Hm, it looks to be sending 'pci-rem' to the XenStore, but I am not sure
if QEMU understands it. Did you compile Xen 4.1.2 by yourself? Did it
compile with CONFIG_PASSTHROUGH?

You should see some messages in the qemu.log about hot-remove and such.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 21:46:44 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 21:46:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbJ83-00024o-JW; Thu, 15 Dec 2011 21:46:15 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RbJ82-00024j-Ie
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 21:46:15 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-2.tower-182.messagelabs.com!1323985567!7458722!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28974 invoked from network); 15 Dec 2011 21:46:07 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-2.tower-182.messagelabs.com with SMTP;
	15 Dec 2011 21:46:07 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea01.nsa.gov (8.12.10/8.12.10) with ESMTP id
	pBFLjDFF012360; Thu, 15 Dec 2011 21:45:13 GMT
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id pBFLjDN7018812; 
	Thu, 15 Dec 2011 16:45:13 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: konrad@darnok.org
Date: Thu, 15 Dec 2011 16:45:34 -0500
Message-Id: <1323985534-17321-1-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.4
In-Reply-To: <20111215205654.GA11829@andromeda.dapyr.net>
References: <20111215205654.GA11829@andromeda.dapyr.net>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>, xen-devel@lists.xensource.com,
	keir@xen.org, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH] flask/policy: Update example policy
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Rewrite the example policy to make it easier to understand and
demonstrate some of the security goals that FLASK can enforce.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 tools/flask/policy/policy/modules/xen/xen.if |  150 +++++++++++-----------
 tools/flask/policy/policy/modules/xen/xen.te |  180 ++++++++++++++-----------
 2 files changed, 178 insertions(+), 152 deletions(-)

diff --git a/tools/flask/policy/policy/modules/xen/xen.if b/tools/flask/policy/policy/modules/xen/xen.if
index 1b50898..cd240d8 100644
--- a/tools/flask/policy/policy/modules/xen/xen.if
+++ b/tools/flask/policy/policy/modules/xen/xen.if
@@ -1,92 +1,96 @@
-###############################################################################
-#
-# create_domain(priv_dom, domain, channel)
-#
-################################################################################
-define(`create_domain', `
-	type $2, domain_type;
-	allow $1 $2:domain {create max_vcpus setdomainmaxmem 
-				setaddrsize getdomaininfo hypercall 
-				setvcpucontext scheduler unpause 
-				getvcpuinfo getaddrsize getvcpuaffinity};
-	allow $1 $2:shadow {enable};
-	allow $1 $2:mmu {map_read map_write adjust physmap};
-	allow $2 $2:mmu {adjust physmap};
-	allow $1 $3:event {create};
-')
-
-###############################################################################
-#
-# create_hvm_dom(priv_dom, domain, channel)
-#
-################################################################################
-define(`create_hvm_dom', `
-	create_domain($1, $2, $3)
-	allow $1 $2:hvm { setparam getparam cacheattr pciroute irqlevel	pcilevel trackdirtyvram };
-	allow $2 $2:hvm setparam;
-')	
+# Macro definitions for FLASK policy
 
-###############################################################################
-#
-# create_pv_dom(priv_dom, domain, channel, iodomain)
-#
-################################################################################
-define(`create_pv_dom', `
-	create_domain($1, $2, $3)
-	allow $1 $2:mmu {memorymap pinpage};
-	allow $2 $2:mmu {map_read map_write pinpage};
-	allow $2 $4:mmu {map_read};
-	
-	allow $2 $2:grant {query setup};
-	allow $1 $2:grant {map_read unmap};
-')	
 ################################################################################
 #
-# manage_domain(priv_dom, domain)
+# Domain creation and setup
 #
 ################################################################################
-define(`manage_domain', `
-	allow $1 $2:domain {pause destroy};
+# declare_domain(type)
+#   Declare a type as a domain type, and allow basic domain setup
+define(`declare_domain', `
+	type $1, domain_type;
+	allow $1 $1:grant { query setup };
+	allow $1 $1:mmu { adjust physmap map_read map_write stat pinpage };
+	allow $1 $1:hvm { getparam setparam };
+')
+
+# create_domain(priv, target)
+#   Allow a domain to be created
+define(`create_domain', `
+	allow $1 $2:domain { create max_vcpus setdomainmaxmem setaddrsize
+			getdomaininfo hypercall setvcpucontext scheduler
+			unpause getvcpuinfo getvcpuextstate getaddrsize
+			getvcpuaffinity };
+	allow $1 $2:security check_context;
+	allow $1 $2:shadow enable;
+	allow $1 $2:mmu {map_read map_write adjust memorymap physmap pinpage};
+	allow $1 $2:grant setup;
+	allow $1 $2:hvm { cacheattr getparam hvmctl irqlevel pciroute setparam };
+	allow $1 $2_$1_channel:event create;
 ')
 
 ################################################################################
 #
-# create_channel(caller, peer, channel)
+# Inter-domain communication
 #
 ################################################################################
+
+# create_channel(source, dest, chan-label)
+#   This allows an event channel to be created from domains with labels
+#   <source> to <dest> and will label it <chan-label>
 define(`create_channel', `
 	type $3, event_type;
 	type_transition $1 $2:event $3;
-	allow $1 $3:event {create};
-	allow $3 $2:event {bind};
+	allow $1 $3:event { create send status };
+	allow $3 $2:event { bind };
 ')
-###############################################################################
-#
-# create_passthrough_resource(priv_dom, domain, resource)
-#
-###############################################################################
-define(`create_passthrough_resource', `
-        type $3, resource_type;
-        allow $1 $2:resource {add remove};
-        allow $1 ioport_t:resource {add_ioport use};
-        allow $1 iomem_t:resource {add_iomem use};
-        allow $1 irq_t:resource  {add_irq use};
-        allow $1 domio_t:mmu {map_read map_write};
-        allow $2 domio_t:mmu {map_write};
-        allow $2 irq_t:resource {use};
-        allow $1 $3:resource {add_irq add_iomem add_ioport remove_irq remove_iomem remove_ioport use add_device remove_device};
-        allow $2 $3:resource {use add_ioport add_iomem remove_ioport remove_iomem};
-        allow $2 $3:mmu {map_read map_write};
+
+# domain_event_comms(dom1, dom2)
+#   Allow two domain types to communicate using event channels
+define(`domain_event_comms', `
+	create_channel($1, $2, $1_$2_channel)
+	create_channel($2, $1, $2_$1_channel)
+')
+
+# domain_comms(dom1, dom2)
+#   Allow two domain types to communicate using grants and event channels
+define(`domain_comms', `
+	domain_event_comms($1, $2)
+	allow $1 $2:grant { map_read map_write copy unmap };
+	allow $2 $1:grant { map_read map_write copy unmap };
+')
+
+# domain_self_comms(domain)
+#   Allow a domain types to communicate with others of its type using grants
+#   and event channels (this includes event channels to DOMID_SELF)
+define(`domain_self_comms', `
+	create_channel($1, $1, $1_self_channel)
+	allow $1 $1:grant { map_read map_write copy unmap };
 ')
-###############################################################################
+
+################################################################################
 #
-# create_hvm_resource(priv_dom, domain, resource)
+# Device types and delegation (PCI passthrough)
 #
-###############################################################################
-define(`create_hvm_resource', `
-        type $3, resource_type;
-        allow $1 $2:resource {add remove};
-        allow $1 $3:hvm {bind_irq};
-        allow $1 $3:resource {stat_device add_device remove_device add_irq remove_irq add_iomem remove_iomem add_ioport remove_ioport};
-        allow $2 $3:resource {use};
+################################################################################
+
+# use_device(domain, device)
+#   Allow a device to be used by a domain
+define(`use_device', `
+    allow $1 $2:resource use;
+    allow $1 $2:mmu { map_read map_write };
+')
+
+# admin_device(domain, device)
+#   Allow a device to be used and delegated by a domain
+define(`admin_device', `
+    allow $1 $2:resource { setup stat_device add_device add_irq add_iomem add_ioport remove_device remove_irq remove_iomem remove_ioport };
+    allow $1 $2:hvm bind_irq;
+    use_device($1, $2)
+')
+
+# delegate_devices(priv-domain, target-domain)
+#   Allow devices to be delegated
+define(`delegate_devices', `
+    allow $1 $2:resource { add remove };
 ')
diff --git a/tools/flask/policy/policy/modules/xen/xen.te b/tools/flask/policy/policy/modules/xen/xen.te
index 1a7f29a..0fc31b5 100644
--- a/tools/flask/policy/policy/modules/xen/xen.te
+++ b/tools/flask/policy/policy/modules/xen/xen.te
@@ -1,21 +1,47 @@
+################################################################################
+#
+# Attributes for types
+#
+# An attribute may be used in a rule as shorthand for all types with that
+# attribute.
+#
+################################################################################
 attribute xen_type;
 attribute domain_type;
 attribute resource_type;
 attribute event_type;
 attribute mls_priv;
 
+################################################################################
+#
+# Types for the initial SIDs
+#
+# These types are used internally for objects created during Xen startup or for
+# devices that have not yet been labeled
+#
+################################################################################
+
+# The hypervisor itself
 type xen_t, xen_type, domain_type, mls_priv;
 
+# Domain 0
 type dom0_t, domain_type, mls_priv;
 
+# Untracked I/O memory (pseudo-domain)
 type domio_t, domain_type;
 
+# Xen heap (pseudo-domain)
 type domxen_t, domain_type;
 
+# Unlabeled objects
 type unlabeled_t, domain_type;
 
+# The XSM/FLASK security server
 type security_t, domain_type;
 
+# Unlabeled device resources
+# Note: don't allow access to these types directly; see below for how to label
+#       devices and use that label for allow rules
 type irq_t, resource_type;
 type ioport_t, resource_type;
 type iomem_t, resource_type;
@@ -23,119 +49,115 @@ type device_t, resource_type;
 
 ################################################################################
 #
-# Boot the hypervisor and dom0
+# Rules required to boot the hypervisor and dom0
 #
 ################################################################################
-allow dom0_t xen_t:xen {kexec readapic writeapic mtrr_read mtrr_add mtrr_del 
-scheduler physinfo heap quirk readconsole writeconsole settime microcode};
-
-allow dom0_t domio_t:mmu {map_read map_write};
-allow dom0_t iomem_t:mmu {map_read map_write};
-allow dom0_t xen_t:mmu {memorymap};
-
-allow dom0_t dom0_t:mmu {pinpage map_read map_write adjust updatemp};
-allow dom0_t dom0_t:grant {query setup};
-allow dom0_t dom0_t:domain {scheduler getdomaininfo getvcpuinfo getvcpuaffinity};
-
-allow xen_t dom0_t:domain {create};
-allow xen_t dom0_t:resource {add remove};
-allow xen_t ioport_t:resource {add_ioport remove_ioport};
-allow dom0_t ioport_t:resource {use};
-allow xen_t iomem_t:resource {add_iomem remove_iomem};
-allow dom0_t iomem_t:resource {use};
-allow xen_t irq_t:resource {add_irq remove_irq};
-allow dom0_t irq_t:resource { add_irq remove_irq use};
+allow xen_t dom0_t:domain { create };
+
+allow dom0_t xen_t:xen { kexec readapic writeapic mtrr_read mtrr_add mtrr_del
+	scheduler physinfo heap quirk readconsole writeconsole settime
+	microcode cpupool_op sched_op };
+allow dom0_t xen_t:mmu { memorymap };
+allow dom0_t security_t:security { check_context compute_av compute_create
+	compute_member load_policy compute_relabel compute_user setenforce
+	setbool setsecparam add_ocontext del_ocontext };
+
+allow dom0_t dom0_t:domain { getdomaininfo getvcpuinfo getvcpuaffinity };
+allow dom0_t dom0_t:grant { query setup };
+allow dom0_t dom0_t:mmu { adjust physmap map_read map_write stat pinpage };
 allow dom0_t dom0_t:resource { add remove };
-allow dom0_t xen_t:xen firmware;
 
-allow dom0_t security_t:security {compute_av compute_create compute_member 
-check_context load_policy compute_relabel compute_user setenforce setbool
-setsecparam add_ocontext del_ocontext};
+admin_device(dom0_t, device_t)
+admin_device(dom0_t, irq_t)
+admin_device(dom0_t, ioport_t)
+admin_device(dom0_t, iomem_t)
+allow dom0_t domio_t:mmu { map_read map_write };
 
-create_channel(dom0_t, dom0_t, evchn0-0_t)
-allow dom0_t evchn0-0_t:event {send};
+domain_self_comms(dom0_t)
 
-################################################################################
+auditallow dom0_t security_t:security { load_policy setenforce };
+
+###############################################################################
 #
-# Create and manage a domU w/ dom0 IO
+# Domain creation
 #
-################################################################################
-create_pv_dom(dom0_t, domU_t, evchnU-0_t, domio_t)
+###############################################################################
+
+declare_domain(domU_t)
+domain_self_comms(domU_t)
+create_domain(dom0_t, domU_t)
+domain_comms(dom0_t, domU_t)
+
+declare_domain(isolated_domU_t)
+create_domain(dom0_t, isolated_domU_t)
+domain_comms(dom0_t, isolated_domU_t)
 
-create_channel(domU_t, domU_t, evchnU-U_t)
-allow domU_t evchnU-U_t:event {send};
+###############################################################################
+#
+# Device delegation
+#
+###############################################################################
 
-create_channel(dom0_t, domU_t, evchn0-U_t)
-allow dom0_t evchn0-U_t:event {send};
+type nic_dev_t, resource_type;
 
-create_channel(domU_t, dom0_t, evchnU-0_t)
-allow domU_t evchnU-0_t:event {send};
+admin_device(dom0_t, nic_dev_t)
+use_device(domU_t, nic_dev_t)
 
-allow dom0_t dom0_t:event {send};
-allow dom0_t domU_t:grant {copy};
-allow domU_t domU_t:grant {copy};
+delegate_devices(dom0_t, domU_t)
 
 ###############################################################################
 #
-# Create device labels
+# Label devices for delegation
+#
+# The PCI, IRQ, memory, and I/O port ranges are hardware-specific.
+# You may also use flask-label-pci to dynamically label devices on each boot.
 #
 ###############################################################################
 
-# create device resources
-#create_passthrough_resource(dom0_t, domU_t, nicP_t)
-#create_hvm_resource(dom0_t, domHU_t, nicP_t)
-
 # label e1000e nic
-#pirqcon 33 system_u:object_r:nicP_t
-#pirqcon 55 system_u:object_r:nicP_t
-#iomemcon 0xfebe0-0xfebff system_u:object_r:nicP_t
-#iomemcon 0xfebd9 system_u:object_r:nicP_t
-#ioportcon 0xecc0-0xecdf system_u:object_r:nicP_t
-#pcidevicecon 0xc800 system_u:object_r:nicP_t
+#pirqcon 33 system_u:object_r:nic_dev_t
+#pirqcon 55 system_u:object_r:nic_dev_t
+#iomemcon 0xfebe0-0xfebff system_u:object_r:nic_dev_t
+#iomemcon 0xfebd9 system_u:object_r:nic_dev_t
+#ioportcon 0xecc0-0xecdf system_u:object_r:nic_dev_t
+#pcidevicecon 0xc800 system_u:object_r:nic_dev_t
 
 # label e100 nic
-#pirqcon 16 system_u:object_r:nicP_t
-#iomemcon 0xfe5df system_u:object_r:nicP_t
-#iomemcon 0xfe5e0-0xfe5ff system_u:object_r:nicP_t
-#iomemcon 0xc2000-0xc200f system_u:object_r:nicP_t
-#ioportcon 0xccc0-0xcd00 system_u:object_r:nicP_t
+#pirqcon 16 system_u:object_r:nic_dev_t
+#iomemcon 0xfe5df system_u:object_r:nic_dev_t
+#iomemcon 0xfe5e0-0xfe5ff system_u:object_r:nic_dev_t
+#iomemcon 0xc2000-0xc200f system_u:object_r:nic_dev_t
+#ioportcon 0xccc0-0xcd00 system_u:object_r:nic_dev_t
 
 # label usb 1d.0-2 1d.7
-#pirqcon 23 system_u:object_r:nicP_t
-#pirqcon 17 system_u:object_r:nicP_t
-#pirqcon 18 system_u:object_r:nicP_t
-#ioportcon 0xff80-0xFF9F system_u:object_r:nicP_t
-#ioportcon 0xff60-0xff7f system_u:object_r:nicP_t
-#ioportcon 0xff40-0xff5f system_u:object_r:nicP_t
-#iomemcon 0xff980 system_u:object_r:nicP_t
-#ioportcon 0xff00-0xff1f system_u:object_r:nicP_t
-
-manage_domain(dom0_t, domU_t)
+#pirqcon 23 system_u:object_r:nic_dev_t
+#pirqcon 17 system_u:object_r:nic_dev_t
+#pirqcon 18 system_u:object_r:nic_dev_t
+#ioportcon 0xff80-0xFF9F system_u:object_r:nic_dev_t
+#ioportcon 0xff60-0xff7f system_u:object_r:nic_dev_t
+#ioportcon 0xff40-0xff5f system_u:object_r:nic_dev_t
+#iomemcon 0xff980 system_u:object_r:nic_dev_t
+#ioportcon 0xff00-0xff1f system_u:object_r:nic_dev_t
 
 ################################################################################
 #
-# Create and manage an HVM domU w/ dom0 IO
+# Constraints
 #
 ################################################################################
-create_hvm_dom(dom0_t, domHU_t, evchnHU-0_t)
-allow dom0_t evchn0-HU_t:event {send};
 
-create_channel(domHU_t, domHU_t, evchnHU-HU_t)
-allow domHU_t evchnU-U_t:event {send};
+# Domains must be declared using domain_type
+neverallow * ~domain_type:domain create;
 
-create_channel(dom0_t, domHU_t, evchn0-HU_t)
-allow dom0_t evchn0-U_t:event {send};
+# Resources must be declared using resource_type
+neverallow * ~resource_type:resource use;
 
-create_channel(domHU_t, dom0_t, evchnHU-0_t)
-allow domHU_t evchnU-0_t:event {send};
-
-allow dom0_t dom0_t:event {send};
-
-manage_domain(dom0_t, domHU_t)
+# Events must use event_type (see create_channel for a template)
+neverallow ~event_type *:event bind;
+neverallow * ~event_type:event { create send status };
 
 ################################################################################
 #
-#
+# Labels for initial SIDs and system role
 #
 ################################################################################
 sid xen gen_context(system_u:system_r:xen_t,s0)
-- 
1.7.7.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 21:46:44 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 21:46:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbJ83-00024o-JW; Thu, 15 Dec 2011 21:46:15 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RbJ82-00024j-Ie
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 21:46:15 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-2.tower-182.messagelabs.com!1323985567!7458722!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28974 invoked from network); 15 Dec 2011 21:46:07 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-2.tower-182.messagelabs.com with SMTP;
	15 Dec 2011 21:46:07 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea01.nsa.gov (8.12.10/8.12.10) with ESMTP id
	pBFLjDFF012360; Thu, 15 Dec 2011 21:45:13 GMT
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id pBFLjDN7018812; 
	Thu, 15 Dec 2011 16:45:13 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: konrad@darnok.org
Date: Thu, 15 Dec 2011 16:45:34 -0500
Message-Id: <1323985534-17321-1-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.4
In-Reply-To: <20111215205654.GA11829@andromeda.dapyr.net>
References: <20111215205654.GA11829@andromeda.dapyr.net>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>, xen-devel@lists.xensource.com,
	keir@xen.org, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH] flask/policy: Update example policy
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Rewrite the example policy to make it easier to understand and
demonstrate some of the security goals that FLASK can enforce.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 tools/flask/policy/policy/modules/xen/xen.if |  150 +++++++++++-----------
 tools/flask/policy/policy/modules/xen/xen.te |  180 ++++++++++++++-----------
 2 files changed, 178 insertions(+), 152 deletions(-)

diff --git a/tools/flask/policy/policy/modules/xen/xen.if b/tools/flask/policy/policy/modules/xen/xen.if
index 1b50898..cd240d8 100644
--- a/tools/flask/policy/policy/modules/xen/xen.if
+++ b/tools/flask/policy/policy/modules/xen/xen.if
@@ -1,92 +1,96 @@
-###############################################################################
-#
-# create_domain(priv_dom, domain, channel)
-#
-################################################################################
-define(`create_domain', `
-	type $2, domain_type;
-	allow $1 $2:domain {create max_vcpus setdomainmaxmem 
-				setaddrsize getdomaininfo hypercall 
-				setvcpucontext scheduler unpause 
-				getvcpuinfo getaddrsize getvcpuaffinity};
-	allow $1 $2:shadow {enable};
-	allow $1 $2:mmu {map_read map_write adjust physmap};
-	allow $2 $2:mmu {adjust physmap};
-	allow $1 $3:event {create};
-')
-
-###############################################################################
-#
-# create_hvm_dom(priv_dom, domain, channel)
-#
-################################################################################
-define(`create_hvm_dom', `
-	create_domain($1, $2, $3)
-	allow $1 $2:hvm { setparam getparam cacheattr pciroute irqlevel	pcilevel trackdirtyvram };
-	allow $2 $2:hvm setparam;
-')	
+# Macro definitions for FLASK policy
 
-###############################################################################
-#
-# create_pv_dom(priv_dom, domain, channel, iodomain)
-#
-################################################################################
-define(`create_pv_dom', `
-	create_domain($1, $2, $3)
-	allow $1 $2:mmu {memorymap pinpage};
-	allow $2 $2:mmu {map_read map_write pinpage};
-	allow $2 $4:mmu {map_read};
-	
-	allow $2 $2:grant {query setup};
-	allow $1 $2:grant {map_read unmap};
-')	
 ################################################################################
 #
-# manage_domain(priv_dom, domain)
+# Domain creation and setup
 #
 ################################################################################
-define(`manage_domain', `
-	allow $1 $2:domain {pause destroy};
+# declare_domain(type)
+#   Declare a type as a domain type, and allow basic domain setup
+define(`declare_domain', `
+	type $1, domain_type;
+	allow $1 $1:grant { query setup };
+	allow $1 $1:mmu { adjust physmap map_read map_write stat pinpage };
+	allow $1 $1:hvm { getparam setparam };
+')
+
+# create_domain(priv, target)
+#   Allow a domain to be created
+define(`create_domain', `
+	allow $1 $2:domain { create max_vcpus setdomainmaxmem setaddrsize
+			getdomaininfo hypercall setvcpucontext scheduler
+			unpause getvcpuinfo getvcpuextstate getaddrsize
+			getvcpuaffinity };
+	allow $1 $2:security check_context;
+	allow $1 $2:shadow enable;
+	allow $1 $2:mmu {map_read map_write adjust memorymap physmap pinpage};
+	allow $1 $2:grant setup;
+	allow $1 $2:hvm { cacheattr getparam hvmctl irqlevel pciroute setparam };
+	allow $1 $2_$1_channel:event create;
 ')
 
 ################################################################################
 #
-# create_channel(caller, peer, channel)
+# Inter-domain communication
 #
 ################################################################################
+
+# create_channel(source, dest, chan-label)
+#   This allows an event channel to be created from domains with labels
+#   <source> to <dest> and will label it <chan-label>
 define(`create_channel', `
 	type $3, event_type;
 	type_transition $1 $2:event $3;
-	allow $1 $3:event {create};
-	allow $3 $2:event {bind};
+	allow $1 $3:event { create send status };
+	allow $3 $2:event { bind };
 ')
-###############################################################################
-#
-# create_passthrough_resource(priv_dom, domain, resource)
-#
-###############################################################################
-define(`create_passthrough_resource', `
-        type $3, resource_type;
-        allow $1 $2:resource {add remove};
-        allow $1 ioport_t:resource {add_ioport use};
-        allow $1 iomem_t:resource {add_iomem use};
-        allow $1 irq_t:resource  {add_irq use};
-        allow $1 domio_t:mmu {map_read map_write};
-        allow $2 domio_t:mmu {map_write};
-        allow $2 irq_t:resource {use};
-        allow $1 $3:resource {add_irq add_iomem add_ioport remove_irq remove_iomem remove_ioport use add_device remove_device};
-        allow $2 $3:resource {use add_ioport add_iomem remove_ioport remove_iomem};
-        allow $2 $3:mmu {map_read map_write};
+
+# domain_event_comms(dom1, dom2)
+#   Allow two domain types to communicate using event channels
+define(`domain_event_comms', `
+	create_channel($1, $2, $1_$2_channel)
+	create_channel($2, $1, $2_$1_channel)
+')
+
+# domain_comms(dom1, dom2)
+#   Allow two domain types to communicate using grants and event channels
+define(`domain_comms', `
+	domain_event_comms($1, $2)
+	allow $1 $2:grant { map_read map_write copy unmap };
+	allow $2 $1:grant { map_read map_write copy unmap };
+')
+
+# domain_self_comms(domain)
+#   Allow a domain types to communicate with others of its type using grants
+#   and event channels (this includes event channels to DOMID_SELF)
+define(`domain_self_comms', `
+	create_channel($1, $1, $1_self_channel)
+	allow $1 $1:grant { map_read map_write copy unmap };
 ')
-###############################################################################
+
+################################################################################
 #
-# create_hvm_resource(priv_dom, domain, resource)
+# Device types and delegation (PCI passthrough)
 #
-###############################################################################
-define(`create_hvm_resource', `
-        type $3, resource_type;
-        allow $1 $2:resource {add remove};
-        allow $1 $3:hvm {bind_irq};
-        allow $1 $3:resource {stat_device add_device remove_device add_irq remove_irq add_iomem remove_iomem add_ioport remove_ioport};
-        allow $2 $3:resource {use};
+################################################################################
+
+# use_device(domain, device)
+#   Allow a device to be used by a domain
+define(`use_device', `
+    allow $1 $2:resource use;
+    allow $1 $2:mmu { map_read map_write };
+')
+
+# admin_device(domain, device)
+#   Allow a device to be used and delegated by a domain
+define(`admin_device', `
+    allow $1 $2:resource { setup stat_device add_device add_irq add_iomem add_ioport remove_device remove_irq remove_iomem remove_ioport };
+    allow $1 $2:hvm bind_irq;
+    use_device($1, $2)
+')
+
+# delegate_devices(priv-domain, target-domain)
+#   Allow devices to be delegated
+define(`delegate_devices', `
+    allow $1 $2:resource { add remove };
 ')
diff --git a/tools/flask/policy/policy/modules/xen/xen.te b/tools/flask/policy/policy/modules/xen/xen.te
index 1a7f29a..0fc31b5 100644
--- a/tools/flask/policy/policy/modules/xen/xen.te
+++ b/tools/flask/policy/policy/modules/xen/xen.te
@@ -1,21 +1,47 @@
+################################################################################
+#
+# Attributes for types
+#
+# An attribute may be used in a rule as shorthand for all types with that
+# attribute.
+#
+################################################################################
 attribute xen_type;
 attribute domain_type;
 attribute resource_type;
 attribute event_type;
 attribute mls_priv;
 
+################################################################################
+#
+# Types for the initial SIDs
+#
+# These types are used internally for objects created during Xen startup or for
+# devices that have not yet been labeled
+#
+################################################################################
+
+# The hypervisor itself
 type xen_t, xen_type, domain_type, mls_priv;
 
+# Domain 0
 type dom0_t, domain_type, mls_priv;
 
+# Untracked I/O memory (pseudo-domain)
 type domio_t, domain_type;
 
+# Xen heap (pseudo-domain)
 type domxen_t, domain_type;
 
+# Unlabeled objects
 type unlabeled_t, domain_type;
 
+# The XSM/FLASK security server
 type security_t, domain_type;
 
+# Unlabeled device resources
+# Note: don't allow access to these types directly; see below for how to label
+#       devices and use that label for allow rules
 type irq_t, resource_type;
 type ioport_t, resource_type;
 type iomem_t, resource_type;
@@ -23,119 +49,115 @@ type device_t, resource_type;
 
 ################################################################################
 #
-# Boot the hypervisor and dom0
+# Rules required to boot the hypervisor and dom0
 #
 ################################################################################
-allow dom0_t xen_t:xen {kexec readapic writeapic mtrr_read mtrr_add mtrr_del 
-scheduler physinfo heap quirk readconsole writeconsole settime microcode};
-
-allow dom0_t domio_t:mmu {map_read map_write};
-allow dom0_t iomem_t:mmu {map_read map_write};
-allow dom0_t xen_t:mmu {memorymap};
-
-allow dom0_t dom0_t:mmu {pinpage map_read map_write adjust updatemp};
-allow dom0_t dom0_t:grant {query setup};
-allow dom0_t dom0_t:domain {scheduler getdomaininfo getvcpuinfo getvcpuaffinity};
-
-allow xen_t dom0_t:domain {create};
-allow xen_t dom0_t:resource {add remove};
-allow xen_t ioport_t:resource {add_ioport remove_ioport};
-allow dom0_t ioport_t:resource {use};
-allow xen_t iomem_t:resource {add_iomem remove_iomem};
-allow dom0_t iomem_t:resource {use};
-allow xen_t irq_t:resource {add_irq remove_irq};
-allow dom0_t irq_t:resource { add_irq remove_irq use};
+allow xen_t dom0_t:domain { create };
+
+allow dom0_t xen_t:xen { kexec readapic writeapic mtrr_read mtrr_add mtrr_del
+	scheduler physinfo heap quirk readconsole writeconsole settime
+	microcode cpupool_op sched_op };
+allow dom0_t xen_t:mmu { memorymap };
+allow dom0_t security_t:security { check_context compute_av compute_create
+	compute_member load_policy compute_relabel compute_user setenforce
+	setbool setsecparam add_ocontext del_ocontext };
+
+allow dom0_t dom0_t:domain { getdomaininfo getvcpuinfo getvcpuaffinity };
+allow dom0_t dom0_t:grant { query setup };
+allow dom0_t dom0_t:mmu { adjust physmap map_read map_write stat pinpage };
 allow dom0_t dom0_t:resource { add remove };
-allow dom0_t xen_t:xen firmware;
 
-allow dom0_t security_t:security {compute_av compute_create compute_member 
-check_context load_policy compute_relabel compute_user setenforce setbool
-setsecparam add_ocontext del_ocontext};
+admin_device(dom0_t, device_t)
+admin_device(dom0_t, irq_t)
+admin_device(dom0_t, ioport_t)
+admin_device(dom0_t, iomem_t)
+allow dom0_t domio_t:mmu { map_read map_write };
 
-create_channel(dom0_t, dom0_t, evchn0-0_t)
-allow dom0_t evchn0-0_t:event {send};
+domain_self_comms(dom0_t)
 
-################################################################################
+auditallow dom0_t security_t:security { load_policy setenforce };
+
+###############################################################################
 #
-# Create and manage a domU w/ dom0 IO
+# Domain creation
 #
-################################################################################
-create_pv_dom(dom0_t, domU_t, evchnU-0_t, domio_t)
+###############################################################################
+
+declare_domain(domU_t)
+domain_self_comms(domU_t)
+create_domain(dom0_t, domU_t)
+domain_comms(dom0_t, domU_t)
+
+declare_domain(isolated_domU_t)
+create_domain(dom0_t, isolated_domU_t)
+domain_comms(dom0_t, isolated_domU_t)
 
-create_channel(domU_t, domU_t, evchnU-U_t)
-allow domU_t evchnU-U_t:event {send};
+###############################################################################
+#
+# Device delegation
+#
+###############################################################################
 
-create_channel(dom0_t, domU_t, evchn0-U_t)
-allow dom0_t evchn0-U_t:event {send};
+type nic_dev_t, resource_type;
 
-create_channel(domU_t, dom0_t, evchnU-0_t)
-allow domU_t evchnU-0_t:event {send};
+admin_device(dom0_t, nic_dev_t)
+use_device(domU_t, nic_dev_t)
 
-allow dom0_t dom0_t:event {send};
-allow dom0_t domU_t:grant {copy};
-allow domU_t domU_t:grant {copy};
+delegate_devices(dom0_t, domU_t)
 
 ###############################################################################
 #
-# Create device labels
+# Label devices for delegation
+#
+# The PCI, IRQ, memory, and I/O port ranges are hardware-specific.
+# You may also use flask-label-pci to dynamically label devices on each boot.
 #
 ###############################################################################
 
-# create device resources
-#create_passthrough_resource(dom0_t, domU_t, nicP_t)
-#create_hvm_resource(dom0_t, domHU_t, nicP_t)
-
 # label e1000e nic
-#pirqcon 33 system_u:object_r:nicP_t
-#pirqcon 55 system_u:object_r:nicP_t
-#iomemcon 0xfebe0-0xfebff system_u:object_r:nicP_t
-#iomemcon 0xfebd9 system_u:object_r:nicP_t
-#ioportcon 0xecc0-0xecdf system_u:object_r:nicP_t
-#pcidevicecon 0xc800 system_u:object_r:nicP_t
+#pirqcon 33 system_u:object_r:nic_dev_t
+#pirqcon 55 system_u:object_r:nic_dev_t
+#iomemcon 0xfebe0-0xfebff system_u:object_r:nic_dev_t
+#iomemcon 0xfebd9 system_u:object_r:nic_dev_t
+#ioportcon 0xecc0-0xecdf system_u:object_r:nic_dev_t
+#pcidevicecon 0xc800 system_u:object_r:nic_dev_t
 
 # label e100 nic
-#pirqcon 16 system_u:object_r:nicP_t
-#iomemcon 0xfe5df system_u:object_r:nicP_t
-#iomemcon 0xfe5e0-0xfe5ff system_u:object_r:nicP_t
-#iomemcon 0xc2000-0xc200f system_u:object_r:nicP_t
-#ioportcon 0xccc0-0xcd00 system_u:object_r:nicP_t
+#pirqcon 16 system_u:object_r:nic_dev_t
+#iomemcon 0xfe5df system_u:object_r:nic_dev_t
+#iomemcon 0xfe5e0-0xfe5ff system_u:object_r:nic_dev_t
+#iomemcon 0xc2000-0xc200f system_u:object_r:nic_dev_t
+#ioportcon 0xccc0-0xcd00 system_u:object_r:nic_dev_t
 
 # label usb 1d.0-2 1d.7
-#pirqcon 23 system_u:object_r:nicP_t
-#pirqcon 17 system_u:object_r:nicP_t
-#pirqcon 18 system_u:object_r:nicP_t
-#ioportcon 0xff80-0xFF9F system_u:object_r:nicP_t
-#ioportcon 0xff60-0xff7f system_u:object_r:nicP_t
-#ioportcon 0xff40-0xff5f system_u:object_r:nicP_t
-#iomemcon 0xff980 system_u:object_r:nicP_t
-#ioportcon 0xff00-0xff1f system_u:object_r:nicP_t
-
-manage_domain(dom0_t, domU_t)
+#pirqcon 23 system_u:object_r:nic_dev_t
+#pirqcon 17 system_u:object_r:nic_dev_t
+#pirqcon 18 system_u:object_r:nic_dev_t
+#ioportcon 0xff80-0xFF9F system_u:object_r:nic_dev_t
+#ioportcon 0xff60-0xff7f system_u:object_r:nic_dev_t
+#ioportcon 0xff40-0xff5f system_u:object_r:nic_dev_t
+#iomemcon 0xff980 system_u:object_r:nic_dev_t
+#ioportcon 0xff00-0xff1f system_u:object_r:nic_dev_t
 
 ################################################################################
 #
-# Create and manage an HVM domU w/ dom0 IO
+# Constraints
 #
 ################################################################################
-create_hvm_dom(dom0_t, domHU_t, evchnHU-0_t)
-allow dom0_t evchn0-HU_t:event {send};
 
-create_channel(domHU_t, domHU_t, evchnHU-HU_t)
-allow domHU_t evchnU-U_t:event {send};
+# Domains must be declared using domain_type
+neverallow * ~domain_type:domain create;
 
-create_channel(dom0_t, domHU_t, evchn0-HU_t)
-allow dom0_t evchn0-U_t:event {send};
+# Resources must be declared using resource_type
+neverallow * ~resource_type:resource use;
 
-create_channel(domHU_t, dom0_t, evchnHU-0_t)
-allow domHU_t evchnU-0_t:event {send};
-
-allow dom0_t dom0_t:event {send};
-
-manage_domain(dom0_t, domHU_t)
+# Events must use event_type (see create_channel for a template)
+neverallow ~event_type *:event bind;
+neverallow * ~event_type:event { create send status };
 
 ################################################################################
 #
-#
+# Labels for initial SIDs and system role
 #
 ################################################################################
 sid xen gen_context(system_u:system_r:xen_t,s0)
-- 
1.7.7.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 21:58:35 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 21:58:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbJJS-0002HG-0R; Thu, 15 Dec 2011 21:58:02 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RbJJQ-0002HB-LU
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 21:58:00 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-14.tower-27.messagelabs.com!1323986153!48502275!1
X-Originating-IP: [63.239.65.40]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1650 invoked from network); 15 Dec 2011 21:55:54 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-14.tower-27.messagelabs.com with SMTP;
	15 Dec 2011 21:55:54 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea02.nsa.gov (8.12.10/8.12.10) with ESMTP id
	pBFLvDHM020259; Thu, 15 Dec 2011 21:57:13 GMT
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id pBFLvDg0019328; 
	Thu, 15 Dec 2011 16:57:13 -0500
Message-ID: <4EEA6D50.80902@tycho.nsa.gov>
Date: Thu, 15 Dec 2011 16:57:36 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:7.0.1) Gecko/20110930 Thunderbird/7.0.1
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
References: <1323808737-29125-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1323808737-29125-9-git-send-email-dgdegra@tycho.nsa.gov>
	<alpine.DEB.2.00.1112151639190.3517@kaball-desktop>
	<4EEA4624.3080308@tycho.nsa.gov>
	<20111215205654.GA11829@andromeda.dapyr.net>
In-Reply-To: <20111215205654.GA11829@andromeda.dapyr.net>
X-Enigmail-Version: 1.3.2
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Keir Fraser <keir@xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 8/8] xl.pod.1: improve documentation of
 FLASK commands
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 12/15/2011 03:56 PM, Konrad Rzeszutek Wilk wrote:
>> There is already an example policy file in tools/flask/policy/policy/modules/xen/xen.te
>> although it will likely require additional rules to be run in enforcing mode.
>> The policy is not built as part of the normal build process, but it can be
>> built by running "make -C tools/flask/policy". If using Fedora 16 (or systems
>> with a checkpolicy version >24) the Makefile will need to be adjusted to
>> produce policy version 24 which is the latest version supported by Xen.
> 
> Is there a howto on how to use it for newbies? Or how to apply policies
> against a domain? Would it make sense to have that as part of the 'man
> xl' ?
> 

I just sent an updated example policy that demonstrates most of the features
that can be used without dom0 disaggregation. It has two main types for domU:

domU_t is a domain that can communicate with any other domU_t
isolated_domU_t can only communicate with dom0

There is also a resource type for device passthrough, configured for domU_t.
To label the PCI device 3:2.0 for passthrough, run:

./tools/flask/utils/flask-label-pci 0000:03:02.0 system_u:object_r:nic_dev_t

I'm not sure this belongs in "man xl" except for a mention of how to set the
security label of a newly created domain. There is already a docs/misc/xsm-flask.txt
that explains a bit about the policy creation; this may need to be updated
to better explain how to use FLASK.

-- 
Daniel De Graaf
National Security Agency

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 15 21:58:35 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 Dec 2011 21:58:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbJJS-0002HG-0R; Thu, 15 Dec 2011 21:58:02 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RbJJQ-0002HB-LU
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 21:58:00 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-14.tower-27.messagelabs.com!1323986153!48502275!1
X-Originating-IP: [63.239.65.40]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1650 invoked from network); 15 Dec 2011 21:55:54 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-14.tower-27.messagelabs.com with SMTP;
	15 Dec 2011 21:55:54 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea02.nsa.gov (8.12.10/8.12.10) with ESMTP id
	pBFLvDHM020259; Thu, 15 Dec 2011 21:57:13 GMT
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id pBFLvDg0019328; 
	Thu, 15 Dec 2011 16:57:13 -0500
Message-ID: <4EEA6D50.80902@tycho.nsa.gov>
Date: Thu, 15 Dec 2011 16:57:36 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:7.0.1) Gecko/20110930 Thunderbird/7.0.1
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
References: <1323808737-29125-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1323808737-29125-9-git-send-email-dgdegra@tycho.nsa.gov>
	<alpine.DEB.2.00.1112151639190.3517@kaball-desktop>
	<4EEA4624.3080308@tycho.nsa.gov>
	<20111215205654.GA11829@andromeda.dapyr.net>
In-Reply-To: <20111215205654.GA11829@andromeda.dapyr.net>
X-Enigmail-Version: 1.3.2
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Keir Fraser <keir@xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 8/8] xl.pod.1: improve documentation of
 FLASK commands
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 12/15/2011 03:56 PM, Konrad Rzeszutek Wilk wrote:
>> There is already an example policy file in tools/flask/policy/policy/modules/xen/xen.te
>> although it will likely require additional rules to be run in enforcing mode.
>> The policy is not built as part of the normal build process, but it can be
>> built by running "make -C tools/flask/policy". If using Fedora 16 (or systems
>> with a checkpolicy version >24) the Makefile will need to be adjusted to
>> produce policy version 24 which is the latest version supported by Xen.
> 
> Is there a howto on how to use it for newbies? Or how to apply policies
> against a domain? Would it make sense to have that as part of the 'man
> xl' ?
> 

I just sent an updated example policy that demonstrates most of the features
that can be used without dom0 disaggregation. It has two main types for domU:

domU_t is a domain that can communicate with any other domU_t
isolated_domU_t can only communicate with dom0

There is also a resource type for device passthrough, configured for domU_t.
To label the PCI device 3:2.0 for passthrough, run:

./tools/flask/utils/flask-label-pci 0000:03:02.0 system_u:object_r:nic_dev_t

I'm not sure this belongs in "man xl" except for a mention of how to set the
security label of a newly created domain. There is already a docs/misc/xsm-flask.txt
that explains a bit about the policy creation; this may need to be updated
to better explain how to use FLASK.

-- 
Daniel De Graaf
National Security Agency

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 00:59:49 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 00:59:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbM8i-0004Ct-Qa; Fri, 16 Dec 2011 00:59:08 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Neal.Taylor@ca.com>) id 1RbM8h-0004Co-AT
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 00:59:07 +0000
X-Env-Sender: Neal.Taylor@ca.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1323997139!8447033!1
X-Originating-IP: [74.125.149.76]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11329 invoked from network); 16 Dec 2011 00:59:00 -0000
Received: from na3sys009aob106.obsmtp.com (HELO na3sys009aog106.obsmtp.com)
	(74.125.149.76)
	by server-3.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Dec 2011 00:59:00 -0000
Received: from USILMS190.ca.com ([141.202.246.44]) (using TLSv1) by
	na3sys009aob106.postini.com ([74.125.148.12]) with SMTP
	ID DSNKTuqX0o4PfuKqbly4GHbySZmCk1H2GmHq@postini.com;
	Thu, 15 Dec 2011 16:59:00 PST
Received: from USILMS172.ca.com (141.202.6.22) by USILMS190.ca.com
	(141.202.246.44) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Thu, 15 Dec 2011 19:58:57 -0500
Received: from USILMS110A.ca.com ([169.254.1.109]) by USILMS172.ca.com
	([141.202.6.22]) with mapi id 14.01.0289.001;
	Thu, 15 Dec 2011 19:58:57 -0500
From: "Taylor, Neal E" <Neal.Taylor@ca.com>
To: "konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
Thread-Topic: patch "[PATCH] xen/swiotlb: Use page alignment for early
	buffer allocation." failed to apply to 3.1-stable tree
Thread-Index: AQHMu39EqhS6jdpwjEafu8REQ03Ud5Xdo1+g
Date: Fri, 16 Dec 2011 00:58:55 +0000
Message-ID: <3E243B26F475504B9BB0BCC9728B0DA629E1AC69@USILMS110A.ca.com>
References: <13239908451694@kroah.org>
In-Reply-To: <13239908451694@kroah.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [138.42.46.105]
MIME-Version: 1.0
Cc: "gregkh@suse.de" <gregkh@suse.de>, "Kalev, Leonid" <Leonid.Kalev@ca.com>,
	xen-devel <xen-devel@lists.xensource.com>,
	"stable@vger.kernel.org" <stable@vger.kernel.org>
Subject: Re: [Xen-devel] patch "[PATCH] xen/swiotlb: Use page alignment for
 early buffer allocation." failed to apply to 3.1-stable tree
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Konrad,

This patch applies and compiles on 3.1.5 and 3.0.4. I'll test tomorrow.

Neal

diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index 8e964b9..5c8e445 100644
--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -166,7 +166,8 @@ retry:
        /*
         * Get IO TLB memory from any location.
         */
-       xen_io_tlb_start = alloc_bootmem(bytes);
+       xen_io_tlb_start = alloc_bootmem_pages(PAGE_ALIGN(bytes));
+
        if (!xen_io_tlb_start)
                panic("Cannot allocate SWIOTLB buffer");

-----Original Message-----
From: gregkh@suse.de [mailto:gregkh@suse.de] 
Sent: Thursday, December 15, 2011 3:14 PM
To: konrad.wilk@oracle.com; Kalev, Leonid; Taylor, Neal E
Cc: stable@vger.kernel.org
Subject: patch "[PATCH] xen/swiotlb: Use page alignment for early buffer allocation." failed to apply to 3.1-stable tree


The patch below does not apply to the 3.1-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable@vger.kernel.org>.

thanks,

greg k-h

------------------ original commit in Linus's tree ------------------

>From 63a741757d15320a25ebf5778f8651cce2ed0611 Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Thu, 15 Dec 2011 11:28:46 -0500
Subject: [PATCH] xen/swiotlb: Use page alignment for early buffer allocation.

This fixes an odd bug found on a Dell PowerEdge 1850/0RC130
(BIOS A05 01/09/2006) where all of the modules doing pci_set_dma_mask
would fail with:

ata_piix 0000:00:1f.1: enabling device (0005 -> 0007)
ata_piix 0000:00:1f.1: can't derive routing for PCI INT A
ata_piix 0000:00:1f.1: BMDMA: failed to set dma mask, falling back to PIO

The issue was the Xen-SWIOTLB was allocated such as that the end of
buffer was stradling a page (and also above 4GB). The fix was
spotted by Kalev Leonid  which was to piggyback on git commit
e79f86b2ef9c0a8c47225217c1018b7d3d90101c "swiotlb: Use page alignment
for early buffer allocation" which:

	We could call free_bootmem_late() if swiotlb is not used, and
	it will shrink to page alignment.

	So alloc them with page alignment at first, to avoid lose two pages

And doing that fixes the outstanding issue.

CC: stable@kernel.org
Suggested-by: "Kalev, Leonid" <Leonid.Kalev@ca.com>
Reported-and-Tested-by: "Taylor, Neal E" <Neal.Taylor@ca.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index 8e964b9..284798a 100644
--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -166,7 +166,7 @@ retry:
 	/*
 	 * Get IO TLB memory from any location.
 	 */
-	xen_io_tlb_start = alloc_bootmem(bytes);
+	xen_io_tlb_start = alloc_bootmem_pages(PAGE_ALIGN(bytes));
 	if (!xen_io_tlb_start) {
 		m = "Cannot allocate Xen-SWIOTLB buffer!\n";
 		goto error;
@@ -179,7 +179,7 @@ retry:
 			       bytes,
 			       xen_io_tlb_nslabs);
 	if (rc) {
-		free_bootmem(__pa(xen_io_tlb_start), bytes);
+		free_bootmem(__pa(xen_io_tlb_start), PAGE_ALIGN(bytes));
 		m = "Failed to get contiguous memory for DMA from Xen!\n"\
 		    "You either: don't have the permissions, do not have"\
 		    " enough free memory under 4GB, or the hypervisor memory"\


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 00:59:49 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 00:59:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbM8i-0004Ct-Qa; Fri, 16 Dec 2011 00:59:08 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Neal.Taylor@ca.com>) id 1RbM8h-0004Co-AT
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 00:59:07 +0000
X-Env-Sender: Neal.Taylor@ca.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1323997139!8447033!1
X-Originating-IP: [74.125.149.76]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11329 invoked from network); 16 Dec 2011 00:59:00 -0000
Received: from na3sys009aob106.obsmtp.com (HELO na3sys009aog106.obsmtp.com)
	(74.125.149.76)
	by server-3.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Dec 2011 00:59:00 -0000
Received: from USILMS190.ca.com ([141.202.246.44]) (using TLSv1) by
	na3sys009aob106.postini.com ([74.125.148.12]) with SMTP
	ID DSNKTuqX0o4PfuKqbly4GHbySZmCk1H2GmHq@postini.com;
	Thu, 15 Dec 2011 16:59:00 PST
Received: from USILMS172.ca.com (141.202.6.22) by USILMS190.ca.com
	(141.202.246.44) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Thu, 15 Dec 2011 19:58:57 -0500
Received: from USILMS110A.ca.com ([169.254.1.109]) by USILMS172.ca.com
	([141.202.6.22]) with mapi id 14.01.0289.001;
	Thu, 15 Dec 2011 19:58:57 -0500
From: "Taylor, Neal E" <Neal.Taylor@ca.com>
To: "konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
Thread-Topic: patch "[PATCH] xen/swiotlb: Use page alignment for early
	buffer allocation." failed to apply to 3.1-stable tree
Thread-Index: AQHMu39EqhS6jdpwjEafu8REQ03Ud5Xdo1+g
Date: Fri, 16 Dec 2011 00:58:55 +0000
Message-ID: <3E243B26F475504B9BB0BCC9728B0DA629E1AC69@USILMS110A.ca.com>
References: <13239908451694@kroah.org>
In-Reply-To: <13239908451694@kroah.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [138.42.46.105]
MIME-Version: 1.0
Cc: "gregkh@suse.de" <gregkh@suse.de>, "Kalev, Leonid" <Leonid.Kalev@ca.com>,
	xen-devel <xen-devel@lists.xensource.com>,
	"stable@vger.kernel.org" <stable@vger.kernel.org>
Subject: Re: [Xen-devel] patch "[PATCH] xen/swiotlb: Use page alignment for
 early buffer allocation." failed to apply to 3.1-stable tree
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Konrad,

This patch applies and compiles on 3.1.5 and 3.0.4. I'll test tomorrow.

Neal

diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index 8e964b9..5c8e445 100644
--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -166,7 +166,8 @@ retry:
        /*
         * Get IO TLB memory from any location.
         */
-       xen_io_tlb_start = alloc_bootmem(bytes);
+       xen_io_tlb_start = alloc_bootmem_pages(PAGE_ALIGN(bytes));
+
        if (!xen_io_tlb_start)
                panic("Cannot allocate SWIOTLB buffer");

-----Original Message-----
From: gregkh@suse.de [mailto:gregkh@suse.de] 
Sent: Thursday, December 15, 2011 3:14 PM
To: konrad.wilk@oracle.com; Kalev, Leonid; Taylor, Neal E
Cc: stable@vger.kernel.org
Subject: patch "[PATCH] xen/swiotlb: Use page alignment for early buffer allocation." failed to apply to 3.1-stable tree


The patch below does not apply to the 3.1-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable@vger.kernel.org>.

thanks,

greg k-h

------------------ original commit in Linus's tree ------------------

>From 63a741757d15320a25ebf5778f8651cce2ed0611 Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Thu, 15 Dec 2011 11:28:46 -0500
Subject: [PATCH] xen/swiotlb: Use page alignment for early buffer allocation.

This fixes an odd bug found on a Dell PowerEdge 1850/0RC130
(BIOS A05 01/09/2006) where all of the modules doing pci_set_dma_mask
would fail with:

ata_piix 0000:00:1f.1: enabling device (0005 -> 0007)
ata_piix 0000:00:1f.1: can't derive routing for PCI INT A
ata_piix 0000:00:1f.1: BMDMA: failed to set dma mask, falling back to PIO

The issue was the Xen-SWIOTLB was allocated such as that the end of
buffer was stradling a page (and also above 4GB). The fix was
spotted by Kalev Leonid  which was to piggyback on git commit
e79f86b2ef9c0a8c47225217c1018b7d3d90101c "swiotlb: Use page alignment
for early buffer allocation" which:

	We could call free_bootmem_late() if swiotlb is not used, and
	it will shrink to page alignment.

	So alloc them with page alignment at first, to avoid lose two pages

And doing that fixes the outstanding issue.

CC: stable@kernel.org
Suggested-by: "Kalev, Leonid" <Leonid.Kalev@ca.com>
Reported-and-Tested-by: "Taylor, Neal E" <Neal.Taylor@ca.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index 8e964b9..284798a 100644
--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -166,7 +166,7 @@ retry:
 	/*
 	 * Get IO TLB memory from any location.
 	 */
-	xen_io_tlb_start = alloc_bootmem(bytes);
+	xen_io_tlb_start = alloc_bootmem_pages(PAGE_ALIGN(bytes));
 	if (!xen_io_tlb_start) {
 		m = "Cannot allocate Xen-SWIOTLB buffer!\n";
 		goto error;
@@ -179,7 +179,7 @@ retry:
 			       bytes,
 			       xen_io_tlb_nslabs);
 	if (rc) {
-		free_bootmem(__pa(xen_io_tlb_start), bytes);
+		free_bootmem(__pa(xen_io_tlb_start), PAGE_ALIGN(bytes));
 		m = "Failed to get contiguous memory for DMA from Xen!\n"\
 		    "You either: don't have the permissions, do not have"\
 		    " enough free memory under 4GB, or the hypervisor memory"\


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 01:15:01 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 01:15:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbMNS-0008Hy-CH; Fri, 16 Dec 2011 01:14:22 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RbMNQ-0008Hq-Dg
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 01:14:20 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1323998053!7527350!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjM1Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27011 invoked from network); 16 Dec 2011 01:14:13 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Dec 2011 01:14:13 -0000
X-IronPort-AV: E=Sophos;i="4.71,360,1320624000"; 
   d="scan'208";a="9503358"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Dec 2011 01:14:12 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 16 Dec 2011 01:14:12 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RbMNI-0001lc-6O;
	Fri, 16 Dec 2011 01:14:12 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RbMNI-0000mb-1T;
	Fri, 16 Dec 2011 01:14:12 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10504-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 16 Dec 2011 01:14:12 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10504: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10504 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10504/

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-amd64-xl-sedf     14 guest-localmigrate/x10    fail REGR. vs. 10491
 test-amd64-i386-win           7 windows-install           fail REGR. vs. 10491
 test-amd64-amd64-xl-winxpsp3  7 windows-install           fail REGR. vs. 10491

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass

version targeted for testing:
 xen                  01c8b27e3d7d
baseline version:
 xen                  03138a08366b

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Christoph Egger <Christoph.Egger@amd.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Liu, Jinsong <jinsong.liu@intel.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   24416:01c8b27e3d7d
tag:         tip
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Thu Dec 15 16:56:21 2011 +0000
    
    libxl: remove stubdom device model save file when destroying stubdom
    
    /var/lib/xen/qemu-save.<domid> is created when the stub domain is started
    (connected to a stubdom console) and is used to save the device model state on
    suspend/migrate but never cleaned up.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24415:27736c7944b9
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Thu Dec 15 16:53:52 2011 +0000
    
    oxenstored: Always log something at start of day (if logging enabled at all)
    
    Otherwise at the default level we rarely log anything at all.
    
    A completely empty log file is a good sign, but only if you know you are
    looking in the right place...
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24414:de4034343b3a
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Thu Dec 15 16:52:22 2011 +0000
    
    oxenstored: install configuration file
    
    First though:
      - Move it to /etc/xen/oxenstored.conf.
      - Use /var/run/xenstored.pid as default pid file
      - Disable test-eagain "Randomly failed a transaction with EAGAIN. Used for
        testing Xs user". Doesn't sound fun by default...
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24413:a9d61ea9973a
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Thu Dec 15 16:50:36 2011 +0000
    
    oxenstored: handle unknown operations by returning an error to the client
    
    Previous an unknown operation would be decoded as a Not_found exception which
    would bubble all the way up to the try ... with surrounding the call to
    main_loop where it would be logged and ignored.
    
    This would leave the guest hanging waiting for a response to the invalid
    request.
    
    Instead introduce a specific "Invalid" operation. Higher level functionality,
    such as Process.process_packet, already handles operations which are not
    understood with an error reply due to the final wildcard entry in
    Process.function_of_type but explicitly handle Invalid this way to make it
    clear what is going on.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24412:99caac2e35df
user:        Jan Beulich <jbeulich@suse.com>
date:        Thu Dec 15 14:28:45 2011 +0100
    
    x86/AMD: use correct shift count when merging model and stepping
    
    ... for legacy errata matching.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24411:ca5f588bd203
user:        Christoph Egger <Christoph.Egger@amd.com>
date:        Thu Dec 15 11:00:09 2011 +0100
    
    x86/ucode: fix for AMD Fam15 CPUs
    
    Remove hardcoded maximum size a microcode patch can have. This is
    dynamic now.
    
    The microcode patch for family15h can be larger than 2048 bytes and
    gets silently truncated.
    
    Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Committed-by: Jan Beulich <jbeulich@suse.com>
    
    
changeset:   24410:25f8952313ae
user:        Liu, Jinsong <jinsong.liu@intel.com>
date:        Thu Dec 15 10:58:53 2011 +0100
    
    x86/MCE: add more strict sanity check of one SRAR case
    
    When RIPV = EIPV = 0, it's a little bit tricky. It may be an asynchronic error, currently we have no way to precisely locate whether the error occur at guest or hypervisor.
    To avoid handling error in wrong way, we treat it as unrecovered.
    
    Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Committed-by: Jan Beulich <jbeulich@suse.com>
    
    
changeset:   24409:0cd9f3e5f3e0
user:        Liu, Jinsong <jinsong.liu@intel.com>
date:        Thu Dec 15 10:54:51 2011 +0100
    
    x86/MCE: add SRAR handler
    
    Currently Intel SDM add 2 kinds of MCE SRAR errors:
    1). Data Load error, error code = 0x134
    2). Instruction Fetch error, error code = 0x150
    This patch add handler to these new SRAR errors.
    It based on existed mce infrastructure, add code to handle SRAR specific error.
    
    Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
    Committed-by: Jan Beulich <jbeulich@suse.com>
    
    
changeset:   24408:5d2dd48bce21
user:        Andrew Cooper <andrew.cooper3@citrix.com>
date:        Wed Dec 14 17:53:54 2011 +0100
    
    XLAT.lst whitespace fix.
    
    Replace spaces with tabs to be in line with file format.
    
    Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
    Committed-by: Jan Beulich <jbeulich@suse.com>
    
    
changeset:   24407:03138a08366b
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Fri Dec 09 16:19:36 2011 +0000
    
    oxenstored: log Errors and Warnings by default.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Acked-by: Ian Jackson <ian.jackson.citrix.com>
    Committed-by: Ian Jackson <ian.jackson.citrix.com>
    
    
========================================
commit 54e24021005458ad0a361c1d83011b751726a94b
Author: Ian Jackson <ian.jackson@eu.citrix.com>
Date:   Thu Dec 8 16:38:06 2011 +0000

    qemu_get_timer: Provide a comment about the behaviour on ts==NULL
    
    Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 01:15:01 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 01:15:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbMNS-0008Hy-CH; Fri, 16 Dec 2011 01:14:22 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RbMNQ-0008Hq-Dg
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 01:14:20 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1323998053!7527350!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjM1Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27011 invoked from network); 16 Dec 2011 01:14:13 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Dec 2011 01:14:13 -0000
X-IronPort-AV: E=Sophos;i="4.71,360,1320624000"; 
   d="scan'208";a="9503358"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Dec 2011 01:14:12 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 16 Dec 2011 01:14:12 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RbMNI-0001lc-6O;
	Fri, 16 Dec 2011 01:14:12 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RbMNI-0000mb-1T;
	Fri, 16 Dec 2011 01:14:12 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10504-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 16 Dec 2011 01:14:12 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10504: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10504 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10504/

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-amd64-xl-sedf     14 guest-localmigrate/x10    fail REGR. vs. 10491
 test-amd64-i386-win           7 windows-install           fail REGR. vs. 10491
 test-amd64-amd64-xl-winxpsp3  7 windows-install           fail REGR. vs. 10491

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass

version targeted for testing:
 xen                  01c8b27e3d7d
baseline version:
 xen                  03138a08366b

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Christoph Egger <Christoph.Egger@amd.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Liu, Jinsong <jinsong.liu@intel.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   24416:01c8b27e3d7d
tag:         tip
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Thu Dec 15 16:56:21 2011 +0000
    
    libxl: remove stubdom device model save file when destroying stubdom
    
    /var/lib/xen/qemu-save.<domid> is created when the stub domain is started
    (connected to a stubdom console) and is used to save the device model state on
    suspend/migrate but never cleaned up.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24415:27736c7944b9
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Thu Dec 15 16:53:52 2011 +0000
    
    oxenstored: Always log something at start of day (if logging enabled at all)
    
    Otherwise at the default level we rarely log anything at all.
    
    A completely empty log file is a good sign, but only if you know you are
    looking in the right place...
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24414:de4034343b3a
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Thu Dec 15 16:52:22 2011 +0000
    
    oxenstored: install configuration file
    
    First though:
      - Move it to /etc/xen/oxenstored.conf.
      - Use /var/run/xenstored.pid as default pid file
      - Disable test-eagain "Randomly failed a transaction with EAGAIN. Used for
        testing Xs user". Doesn't sound fun by default...
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24413:a9d61ea9973a
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Thu Dec 15 16:50:36 2011 +0000
    
    oxenstored: handle unknown operations by returning an error to the client
    
    Previous an unknown operation would be decoded as a Not_found exception which
    would bubble all the way up to the try ... with surrounding the call to
    main_loop where it would be logged and ignored.
    
    This would leave the guest hanging waiting for a response to the invalid
    request.
    
    Instead introduce a specific "Invalid" operation. Higher level functionality,
    such as Process.process_packet, already handles operations which are not
    understood with an error reply due to the final wildcard entry in
    Process.function_of_type but explicitly handle Invalid this way to make it
    clear what is going on.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24412:99caac2e35df
user:        Jan Beulich <jbeulich@suse.com>
date:        Thu Dec 15 14:28:45 2011 +0100
    
    x86/AMD: use correct shift count when merging model and stepping
    
    ... for legacy errata matching.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24411:ca5f588bd203
user:        Christoph Egger <Christoph.Egger@amd.com>
date:        Thu Dec 15 11:00:09 2011 +0100
    
    x86/ucode: fix for AMD Fam15 CPUs
    
    Remove hardcoded maximum size a microcode patch can have. This is
    dynamic now.
    
    The microcode patch for family15h can be larger than 2048 bytes and
    gets silently truncated.
    
    Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Committed-by: Jan Beulich <jbeulich@suse.com>
    
    
changeset:   24410:25f8952313ae
user:        Liu, Jinsong <jinsong.liu@intel.com>
date:        Thu Dec 15 10:58:53 2011 +0100
    
    x86/MCE: add more strict sanity check of one SRAR case
    
    When RIPV = EIPV = 0, it's a little bit tricky. It may be an asynchronic error, currently we have no way to precisely locate whether the error occur at guest or hypervisor.
    To avoid handling error in wrong way, we treat it as unrecovered.
    
    Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Committed-by: Jan Beulich <jbeulich@suse.com>
    
    
changeset:   24409:0cd9f3e5f3e0
user:        Liu, Jinsong <jinsong.liu@intel.com>
date:        Thu Dec 15 10:54:51 2011 +0100
    
    x86/MCE: add SRAR handler
    
    Currently Intel SDM add 2 kinds of MCE SRAR errors:
    1). Data Load error, error code = 0x134
    2). Instruction Fetch error, error code = 0x150
    This patch add handler to these new SRAR errors.
    It based on existed mce infrastructure, add code to handle SRAR specific error.
    
    Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
    Committed-by: Jan Beulich <jbeulich@suse.com>
    
    
changeset:   24408:5d2dd48bce21
user:        Andrew Cooper <andrew.cooper3@citrix.com>
date:        Wed Dec 14 17:53:54 2011 +0100
    
    XLAT.lst whitespace fix.
    
    Replace spaces with tabs to be in line with file format.
    
    Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
    Committed-by: Jan Beulich <jbeulich@suse.com>
    
    
changeset:   24407:03138a08366b
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Fri Dec 09 16:19:36 2011 +0000
    
    oxenstored: log Errors and Warnings by default.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Acked-by: Ian Jackson <ian.jackson.citrix.com>
    Committed-by: Ian Jackson <ian.jackson.citrix.com>
    
    
========================================
commit 54e24021005458ad0a361c1d83011b751726a94b
Author: Ian Jackson <ian.jackson@eu.citrix.com>
Date:   Thu Dec 8 16:38:06 2011 +0000

    qemu_get_timer: Provide a comment about the behaviour on ts==NULL
    
    Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 02:26:20 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 02:26:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbNUQ-0000V6-Sl; Fri, 16 Dec 2011 02:25:38 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <thunderbird2k@gmail.com>) id 1RbNUO-0000V1-Nn
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 02:25:36 +0000
X-Env-Sender: thunderbird2k@gmail.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1324002328!5773643!1
X-Originating-IP: [209.85.213.171]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15990 invoked from network); 16 Dec 2011 02:25:29 -0000
Received: from mail-yx0-f171.google.com (HELO mail-yx0-f171.google.com)
	(209.85.213.171)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Dec 2011 02:25:29 -0000
Received: by yenr9 with SMTP id r9so38517548yen.30
	for <xen-devel@lists.xensource.com>;
	Thu, 15 Dec 2011 18:25:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=IEKYesob/zO+1cYYosU9fAgQDpJLvloOcR15AVtmRwk=;
	b=Hvhjs8Ww30XlCmtnpLqySYSwnTPT88OH7aZlqQf9Z6SmcaYNglB6UJiebp0/OCEMeF
	XERxgL4i+9fxSEwo9AuaRvhE4UUAejsbdkSKza9cw7DrBPR0l11dV5rndI+SiTc6It3T
	0XukuAMD7UJm39FCpxTgbRO2Z8I1ooLO2GaNA=
MIME-Version: 1.0
Received: by 10.236.75.167 with SMTP id z27mr9055526yhd.53.1324002325619; Thu,
	15 Dec 2011 18:25:25 -0800 (PST)
Received: by 10.100.27.35 with HTTP; Thu, 15 Dec 2011 18:25:25 -0800 (PST)
In-Reply-To: <20111213212031.GA8410@konrad-lan>
References: <CAEc3jaACffpr9D1Hq_012vHAGhPLEfvsZjh7YyJ=Q-3FdtHS0Q@mail.gmail.com>
	<CAPbh3rtOQ1HTPReqYcpE3vzk+-na0MTLLHZD15=Fg4yxB+ypaA@mail.gmail.com>
	<CAEc3jaBdQKmVJToNZRf+25GtJXqGc274ieHf_yHKRJ+YOKWdgA@mail.gmail.com>
	<20111208234624.GD32474@konrad-lan>
	<CAEc3jaC9=HiMoxSYZmXKRzoFcMYRaT9jrX3m1ZQO+M8CrH35Fg@mail.gmail.com>
	<CAEc3jaBBYBME0G3Ku_sTvzQz+oKQnpBPffA+bRUKxxRPABAeww@mail.gmail.com>
	<20111211125247.GQ12984@reaktio.net>
	<CAEc3jaCJ6wP27Ffm0wpOggWMgqcSNJiGxhtkszq6jgRD1nrZLg@mail.gmail.com>
	<CAEc3jaBS6WUB_oViMp=qT_0RP+LPjZuEV8Qko9Jabs6qaeSibQ@mail.gmail.com>
	<20111213020229.GB2730@konrad-lan>
	<20111213212031.GA8410@konrad-lan>
Date: Fri, 16 Dec 2011 02:25:25 +0000
Message-ID: <CAEc3jaA8q1fLaH60MgtCtqMyUbE97cmtiERUFSOJsAY1HiK-ig@mail.gmail.com>
From: Roderick Colenbrander <thunderbird2k@gmail.com>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
Cc: xen-devel@lists.xensource.com, Andreas Kinzler <ml-xen-devel@hfp.de>
Subject: Re: [Xen-devel] Questions about GPLPV stability tests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Thanks. On Tuesday I set up your monitoring tool on the already
running tests. Some of the systems were on the verge of showing
results, but we just had a power outage and I have to restart the
tests. It will probably take until the Holidays before there any
results :(

Roderick

On Tue, Dec 13, 2011 at 9:20 PM, Konrad Rzeszutek Wilk
<konrad@darnok.org> wrote:
>> > Does this feel like blktap issues? Or is it more likely that something
>> > else happened which causes blktap and the other things to fail?
>>
>> It looks like the interrupts stopped. Perhaps you can run the C code
>> (attached) on the serial console and see _what_ (or perhaps _when_)
>> the interrupts stops (and also verify that the timeouts and 'frozen'
>> happen due to no interrupts being received).
>
> The C code is http://darnok.org/xen/read_interrupts.c
>
>>
>> There are a couple of bugs that were discovered in the interrupt code
>> (that had been there since 2.6.27!) that went to the stable tree - so
>> they should been backported to 2.6.32.x tree - but I honestly don't
>> recall the names. I can look them up tomorrow.
>
> xen: x86_32: do not enable iterrupts when returning from exception in
> interrupt context (git commit d198d499148a0c64a41b3aba9e7dd43772832b91)
>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 02:26:20 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 02:26:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbNUQ-0000V6-Sl; Fri, 16 Dec 2011 02:25:38 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <thunderbird2k@gmail.com>) id 1RbNUO-0000V1-Nn
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 02:25:36 +0000
X-Env-Sender: thunderbird2k@gmail.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1324002328!5773643!1
X-Originating-IP: [209.85.213.171]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15990 invoked from network); 16 Dec 2011 02:25:29 -0000
Received: from mail-yx0-f171.google.com (HELO mail-yx0-f171.google.com)
	(209.85.213.171)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Dec 2011 02:25:29 -0000
Received: by yenr9 with SMTP id r9so38517548yen.30
	for <xen-devel@lists.xensource.com>;
	Thu, 15 Dec 2011 18:25:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=IEKYesob/zO+1cYYosU9fAgQDpJLvloOcR15AVtmRwk=;
	b=Hvhjs8Ww30XlCmtnpLqySYSwnTPT88OH7aZlqQf9Z6SmcaYNglB6UJiebp0/OCEMeF
	XERxgL4i+9fxSEwo9AuaRvhE4UUAejsbdkSKza9cw7DrBPR0l11dV5rndI+SiTc6It3T
	0XukuAMD7UJm39FCpxTgbRO2Z8I1ooLO2GaNA=
MIME-Version: 1.0
Received: by 10.236.75.167 with SMTP id z27mr9055526yhd.53.1324002325619; Thu,
	15 Dec 2011 18:25:25 -0800 (PST)
Received: by 10.100.27.35 with HTTP; Thu, 15 Dec 2011 18:25:25 -0800 (PST)
In-Reply-To: <20111213212031.GA8410@konrad-lan>
References: <CAEc3jaACffpr9D1Hq_012vHAGhPLEfvsZjh7YyJ=Q-3FdtHS0Q@mail.gmail.com>
	<CAPbh3rtOQ1HTPReqYcpE3vzk+-na0MTLLHZD15=Fg4yxB+ypaA@mail.gmail.com>
	<CAEc3jaBdQKmVJToNZRf+25GtJXqGc274ieHf_yHKRJ+YOKWdgA@mail.gmail.com>
	<20111208234624.GD32474@konrad-lan>
	<CAEc3jaC9=HiMoxSYZmXKRzoFcMYRaT9jrX3m1ZQO+M8CrH35Fg@mail.gmail.com>
	<CAEc3jaBBYBME0G3Ku_sTvzQz+oKQnpBPffA+bRUKxxRPABAeww@mail.gmail.com>
	<20111211125247.GQ12984@reaktio.net>
	<CAEc3jaCJ6wP27Ffm0wpOggWMgqcSNJiGxhtkszq6jgRD1nrZLg@mail.gmail.com>
	<CAEc3jaBS6WUB_oViMp=qT_0RP+LPjZuEV8Qko9Jabs6qaeSibQ@mail.gmail.com>
	<20111213020229.GB2730@konrad-lan>
	<20111213212031.GA8410@konrad-lan>
Date: Fri, 16 Dec 2011 02:25:25 +0000
Message-ID: <CAEc3jaA8q1fLaH60MgtCtqMyUbE97cmtiERUFSOJsAY1HiK-ig@mail.gmail.com>
From: Roderick Colenbrander <thunderbird2k@gmail.com>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
Cc: xen-devel@lists.xensource.com, Andreas Kinzler <ml-xen-devel@hfp.de>
Subject: Re: [Xen-devel] Questions about GPLPV stability tests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Thanks. On Tuesday I set up your monitoring tool on the already
running tests. Some of the systems were on the verge of showing
results, but we just had a power outage and I have to restart the
tests. It will probably take until the Holidays before there any
results :(

Roderick

On Tue, Dec 13, 2011 at 9:20 PM, Konrad Rzeszutek Wilk
<konrad@darnok.org> wrote:
>> > Does this feel like blktap issues? Or is it more likely that something
>> > else happened which causes blktap and the other things to fail?
>>
>> It looks like the interrupts stopped. Perhaps you can run the C code
>> (attached) on the serial console and see _what_ (or perhaps _when_)
>> the interrupts stops (and also verify that the timeouts and 'frozen'
>> happen due to no interrupts being received).
>
> The C code is http://darnok.org/xen/read_interrupts.c
>
>>
>> There are a couple of bugs that were discovered in the interrupt code
>> (that had been there since 2.6.27!) that went to the stable tree - so
>> they should been backported to 2.6.32.x tree - but I honestly don't
>> recall the names. I can look them up tomorrow.
>
> xen: x86_32: do not enable iterrupts when returning from exception in
> interrupt context (git commit d198d499148a0c64a41b3aba9e7dd43772832b91)
>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 06:01:35 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 06:01:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbQqj-0001z9-VE; Fri, 16 Dec 2011 06:00:53 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RbQqi-0001z3-3m
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 06:00:52 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1324015206!49237296!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjM1Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25960 invoked from network); 16 Dec 2011 06:00:06 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Dec 2011 06:00:06 -0000
X-IronPort-AV: E=Sophos;i="4.71,361,1320624000"; 
   d="scan'208";a="9504801"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Dec 2011 06:00:50 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 16 Dec 2011 06:00:50 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RbQqf-0003Kw-S5;
	Fri, 16 Dec 2011 06:00:49 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RbQqf-0004hC-RY;
	Fri, 16 Dec 2011 06:00:49 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10511-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 16 Dec 2011 06:00:49 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10511: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10511 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10511/

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-amd64-xl-sedf 14 guest-localmigrate/x10 fail in 10504 REGR. vs. 10491

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf     13 guest-localmigrate.2        fail pass in 10504
 test-i386-i386-win            7 windows-install             fail pass in 10504
 test-amd64-i386-win           7 windows-install    fail in 10504 pass in 10511
 test-amd64-amd64-xl-winxpsp3  7 windows-install    fail in 10504 pass in 10511

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-i386-i386-win           16 leak-check/check      fail in 10504 never pass

version targeted for testing:
 xen                  01c8b27e3d7d
baseline version:
 xen                  03138a08366b

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Christoph Egger <Christoph.Egger@amd.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Liu, Jinsong <jinsong.liu@intel.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   24416:01c8b27e3d7d
tag:         tip
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Thu Dec 15 16:56:21 2011 +0000
    
    libxl: remove stubdom device model save file when destroying stubdom
    
    /var/lib/xen/qemu-save.<domid> is created when the stub domain is started
    (connected to a stubdom console) and is used to save the device model state on
    suspend/migrate but never cleaned up.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24415:27736c7944b9
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Thu Dec 15 16:53:52 2011 +0000
    
    oxenstored: Always log something at start of day (if logging enabled at all)
    
    Otherwise at the default level we rarely log anything at all.
    
    A completely empty log file is a good sign, but only if you know you are
    looking in the right place...
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24414:de4034343b3a
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Thu Dec 15 16:52:22 2011 +0000
    
    oxenstored: install configuration file
    
    First though:
      - Move it to /etc/xen/oxenstored.conf.
      - Use /var/run/xenstored.pid as default pid file
      - Disable test-eagain "Randomly failed a transaction with EAGAIN. Used for
        testing Xs user". Doesn't sound fun by default...
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24413:a9d61ea9973a
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Thu Dec 15 16:50:36 2011 +0000
    
    oxenstored: handle unknown operations by returning an error to the client
    
    Previous an unknown operation would be decoded as a Not_found exception which
    would bubble all the way up to the try ... with surrounding the call to
    main_loop where it would be logged and ignored.
    
    This would leave the guest hanging waiting for a response to the invalid
    request.
    
    Instead introduce a specific "Invalid" operation. Higher level functionality,
    such as Process.process_packet, already handles operations which are not
    understood with an error reply due to the final wildcard entry in
    Process.function_of_type but explicitly handle Invalid this way to make it
    clear what is going on.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24412:99caac2e35df
user:        Jan Beulich <jbeulich@suse.com>
date:        Thu Dec 15 14:28:45 2011 +0100
    
    x86/AMD: use correct shift count when merging model and stepping
    
    ... for legacy errata matching.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24411:ca5f588bd203
user:        Christoph Egger <Christoph.Egger@amd.com>
date:        Thu Dec 15 11:00:09 2011 +0100
    
    x86/ucode: fix for AMD Fam15 CPUs
    
    Remove hardcoded maximum size a microcode patch can have. This is
    dynamic now.
    
    The microcode patch for family15h can be larger than 2048 bytes and
    gets silently truncated.
    
    Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Committed-by: Jan Beulich <jbeulich@suse.com>
    
    
changeset:   24410:25f8952313ae
user:        Liu, Jinsong <jinsong.liu@intel.com>
date:        Thu Dec 15 10:58:53 2011 +0100
    
    x86/MCE: add more strict sanity check of one SRAR case
    
    When RIPV = EIPV = 0, it's a little bit tricky. It may be an asynchronic error, currently we have no way to precisely locate whether the error occur at guest or hypervisor.
    To avoid handling error in wrong way, we treat it as unrecovered.
    
    Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Committed-by: Jan Beulich <jbeulich@suse.com>
    
    
changeset:   24409:0cd9f3e5f3e0
user:        Liu, Jinsong <jinsong.liu@intel.com>
date:        Thu Dec 15 10:54:51 2011 +0100
    
    x86/MCE: add SRAR handler
    
    Currently Intel SDM add 2 kinds of MCE SRAR errors:
    1). Data Load error, error code = 0x134
    2). Instruction Fetch error, error code = 0x150
    This patch add handler to these new SRAR errors.
    It based on existed mce infrastructure, add code to handle SRAR specific error.
    
    Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
    Committed-by: Jan Beulich <jbeulich@suse.com>
    
    
changeset:   24408:5d2dd48bce21
user:        Andrew Cooper <andrew.cooper3@citrix.com>
date:        Wed Dec 14 17:53:54 2011 +0100
    
    XLAT.lst whitespace fix.
    
    Replace spaces with tabs to be in line with file format.
    
    Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
    Committed-by: Jan Beulich <jbeulich@suse.com>
    
    
changeset:   24407:03138a08366b
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Fri Dec 09 16:19:36 2011 +0000
    
    oxenstored: log Errors and Warnings by default.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Acked-by: Ian Jackson <ian.jackson.citrix.com>
    Committed-by: Ian Jackson <ian.jackson.citrix.com>
    
    
========================================
commit 54e24021005458ad0a361c1d83011b751726a94b
Author: Ian Jackson <ian.jackson@eu.citrix.com>
Date:   Thu Dec 8 16:38:06 2011 +0000

    qemu_get_timer: Provide a comment about the behaviour on ts==NULL
    
    Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 06:01:35 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 06:01:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbQqj-0001z9-VE; Fri, 16 Dec 2011 06:00:53 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RbQqi-0001z3-3m
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 06:00:52 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1324015206!49237296!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjM1Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25960 invoked from network); 16 Dec 2011 06:00:06 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Dec 2011 06:00:06 -0000
X-IronPort-AV: E=Sophos;i="4.71,361,1320624000"; 
   d="scan'208";a="9504801"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Dec 2011 06:00:50 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 16 Dec 2011 06:00:50 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RbQqf-0003Kw-S5;
	Fri, 16 Dec 2011 06:00:49 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RbQqf-0004hC-RY;
	Fri, 16 Dec 2011 06:00:49 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10511-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 16 Dec 2011 06:00:49 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10511: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10511 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10511/

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-amd64-xl-sedf 14 guest-localmigrate/x10 fail in 10504 REGR. vs. 10491

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf     13 guest-localmigrate.2        fail pass in 10504
 test-i386-i386-win            7 windows-install             fail pass in 10504
 test-amd64-i386-win           7 windows-install    fail in 10504 pass in 10511
 test-amd64-amd64-xl-winxpsp3  7 windows-install    fail in 10504 pass in 10511

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-i386-i386-win           16 leak-check/check      fail in 10504 never pass

version targeted for testing:
 xen                  01c8b27e3d7d
baseline version:
 xen                  03138a08366b

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Christoph Egger <Christoph.Egger@amd.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Liu, Jinsong <jinsong.liu@intel.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   24416:01c8b27e3d7d
tag:         tip
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Thu Dec 15 16:56:21 2011 +0000
    
    libxl: remove stubdom device model save file when destroying stubdom
    
    /var/lib/xen/qemu-save.<domid> is created when the stub domain is started
    (connected to a stubdom console) and is used to save the device model state on
    suspend/migrate but never cleaned up.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24415:27736c7944b9
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Thu Dec 15 16:53:52 2011 +0000
    
    oxenstored: Always log something at start of day (if logging enabled at all)
    
    Otherwise at the default level we rarely log anything at all.
    
    A completely empty log file is a good sign, but only if you know you are
    looking in the right place...
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24414:de4034343b3a
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Thu Dec 15 16:52:22 2011 +0000
    
    oxenstored: install configuration file
    
    First though:
      - Move it to /etc/xen/oxenstored.conf.
      - Use /var/run/xenstored.pid as default pid file
      - Disable test-eagain "Randomly failed a transaction with EAGAIN. Used for
        testing Xs user". Doesn't sound fun by default...
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24413:a9d61ea9973a
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Thu Dec 15 16:50:36 2011 +0000
    
    oxenstored: handle unknown operations by returning an error to the client
    
    Previous an unknown operation would be decoded as a Not_found exception which
    would bubble all the way up to the try ... with surrounding the call to
    main_loop where it would be logged and ignored.
    
    This would leave the guest hanging waiting for a response to the invalid
    request.
    
    Instead introduce a specific "Invalid" operation. Higher level functionality,
    such as Process.process_packet, already handles operations which are not
    understood with an error reply due to the final wildcard entry in
    Process.function_of_type but explicitly handle Invalid this way to make it
    clear what is going on.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24412:99caac2e35df
user:        Jan Beulich <jbeulich@suse.com>
date:        Thu Dec 15 14:28:45 2011 +0100
    
    x86/AMD: use correct shift count when merging model and stepping
    
    ... for legacy errata matching.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24411:ca5f588bd203
user:        Christoph Egger <Christoph.Egger@amd.com>
date:        Thu Dec 15 11:00:09 2011 +0100
    
    x86/ucode: fix for AMD Fam15 CPUs
    
    Remove hardcoded maximum size a microcode patch can have. This is
    dynamic now.
    
    The microcode patch for family15h can be larger than 2048 bytes and
    gets silently truncated.
    
    Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Committed-by: Jan Beulich <jbeulich@suse.com>
    
    
changeset:   24410:25f8952313ae
user:        Liu, Jinsong <jinsong.liu@intel.com>
date:        Thu Dec 15 10:58:53 2011 +0100
    
    x86/MCE: add more strict sanity check of one SRAR case
    
    When RIPV = EIPV = 0, it's a little bit tricky. It may be an asynchronic error, currently we have no way to precisely locate whether the error occur at guest or hypervisor.
    To avoid handling error in wrong way, we treat it as unrecovered.
    
    Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Committed-by: Jan Beulich <jbeulich@suse.com>
    
    
changeset:   24409:0cd9f3e5f3e0
user:        Liu, Jinsong <jinsong.liu@intel.com>
date:        Thu Dec 15 10:54:51 2011 +0100
    
    x86/MCE: add SRAR handler
    
    Currently Intel SDM add 2 kinds of MCE SRAR errors:
    1). Data Load error, error code = 0x134
    2). Instruction Fetch error, error code = 0x150
    This patch add handler to these new SRAR errors.
    It based on existed mce infrastructure, add code to handle SRAR specific error.
    
    Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
    Committed-by: Jan Beulich <jbeulich@suse.com>
    
    
changeset:   24408:5d2dd48bce21
user:        Andrew Cooper <andrew.cooper3@citrix.com>
date:        Wed Dec 14 17:53:54 2011 +0100
    
    XLAT.lst whitespace fix.
    
    Replace spaces with tabs to be in line with file format.
    
    Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
    Committed-by: Jan Beulich <jbeulich@suse.com>
    
    
changeset:   24407:03138a08366b
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Fri Dec 09 16:19:36 2011 +0000
    
    oxenstored: log Errors and Warnings by default.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Acked-by: Ian Jackson <ian.jackson.citrix.com>
    Committed-by: Ian Jackson <ian.jackson.citrix.com>
    
    
========================================
commit 54e24021005458ad0a361c1d83011b751726a94b
Author: Ian Jackson <ian.jackson@eu.citrix.com>
Date:   Thu Dec 8 16:38:06 2011 +0000

    qemu_get_timer: Provide a comment about the behaviour on ts==NULL
    
    Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 06:01:52 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 06: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.xensource.com>)
	id 1RbQr4-00020E-Hm; Fri, 16 Dec 2011 06:01:14 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <amit.shah@redhat.com>) id 1RbQr2-000203-MO
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 06:01:12 +0000
X-Env-Sender: amit.shah@redhat.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1324015265!5726212!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDY0MDQ=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9042 invoked from network); 16 Dec 2011 06:01:06 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-12.tower-174.messagelabs.com with SMTP;
	16 Dec 2011 06:01:06 -0000
Received: from int-mx01.intmail.prod.int.phx2.redhat.com
	(int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id pBG60rxa006761
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 16 Dec 2011 01:00:53 -0500
Received: from localhost (ovpn-113-36.phx2.redhat.com [10.3.113.36])
	by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP
	id pBG60okG019224; Fri, 16 Dec 2011 01:00:51 -0500
Date: Fri, 16 Dec 2011 11:30:48 +0530
From: Amit Shah <amit.shah@redhat.com>
To: Miche Baker-Harvey <miche@google.com>
Message-ID: <20111216060048.GA12211@amit-x200.redhat.com>
References: <20111108214504.28884.61814.stgit@miche.sea.corp.google.com>
	<874nybqo0o.fsf@rustcorp.com.au>
	<CAB8RdapbaueyWLJuJDE_ZdvLkRNM4sQHTxgmgO=jrnXZ6YPSmA@mail.gmail.com>
	<20111123103852.GG16665@amit-x200.redhat.com>
	<CAB8RdaoDxMCgTjuGP70bGrsrtgh=USYtU3Spo5OPtVMYAM5EzQ@mail.gmail.com>
	<20111129142149.GE2822@amit-x200.redhat.com>
	<CAB8RdapuPRym2dH_9mgmGdzpCxnP1KpS+hS8JJ-geVkga5fMcw@mail.gmail.com>
	<CAB8Rdapfuf5XH+X9gsUL+CJ9gTQcSNfq4Dj9DoYWQeFgD04ODQ@mail.gmail.com>
	<20111205105452.GB27683@amit-x200.redhat.com>
	<CAB8Rdar=qOokxZkjQVRmo=zN_f75jPwzU+6=WBRo0g+P7w+pAw@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAB8Rdar=qOokxZkjQVRmo=zN_f75jPwzU+6=WBRo0g+P7w+pAw@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.11
Cc: Stephen Rothwell <sfr@canb.auug.org.au>, xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Rusty Russell <rusty@rustcorp.com.au>, linux-kernel@vger.kernel.org,
	virtualization@lists.linux-foundation.org,
	Anton Blanchard <anton@samba.org>, Mike Waychison <mikew@google.com>,
	ppc-dev <linuxppc-dev@lists.ozlabs.org>,
	Greg Kroah-Hartman <gregkh@suse.de>, Eric Northrup <digitaleric@google.com>
Subject: Re: [Xen-devel] [PATCH v3 2/3] hvc_init(): Enforce one-time
	initialization.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On (Tue) 06 Dec 2011 [09:05:38], Miche Baker-Harvey wrote:
> Amit,
> 
> Ah, indeed.  I am not using MSI-X, so virtio_pci::vp_try_to_find_vqs()
> calls vp_request_intx() and sets up an interrupt callback.  From
> there, when an interrupt occurs, the stack looks something like this:
> 
> virtio_pci::vp_interrupt()
>   virtio_pci::vp_vring_interrupt()
>     virtio_ring::vring_interrupt()
>       vq->vq.callback()  <-- in this case, that's virtio_console::control_intr()
>         workqueue::schedule_work()
>           workqueue::queue_work()
>             queue_work_on(get_cpu())  <-- queues the work on the current CPU.
> 
> I'm not doing anything to keep multiple control message from being
> sent concurrently to the guest, and we will take those interrupts on
> any CPU. I've confirmed that the two instances of
> handle_control_message() are occurring on different CPUs.

Hi Miche,

Here's a quick-and-dirty hack that should help.  I've not tested this,
and it's not yet signed-off-by.  Let me know if this helps.

>From 16708fa247c0dd34aa55d78166d65e463f9be6d6 Mon Sep 17 00:00:00 2001
Message-Id: <16708fa247c0dd34aa55d78166d65e463f9be6d6.1324015123.git.amit.shah@redhat.com>
From: Amit Shah <amit.shah@redhat.com>
Date: Fri, 16 Dec 2011 11:27:04 +0530
Subject: [PATCH 1/1] virtio: console: Serialise control work

We currently allow multiple instances of the control work handler to run
in parallel.  This isn't expected to work; serialise access by disabling
interrupts on new packets from the Host and enable them when all the
existing ones are consumed.
---
 drivers/char/virtio_console.c |    6 ++++++
 1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/drivers/char/virtio_console.c b/drivers/char/virtio_console.c
index 8e3c46d..72d396c 100644
--- a/drivers/char/virtio_console.c
+++ b/drivers/char/virtio_console.c
@@ -1466,6 +1466,7 @@ static void control_work_handler(struct work_struct *work)
 	portdev = container_of(work, struct ports_device, control_work);
 	vq = portdev->c_ivq;
 
+ start:
 	spin_lock(&portdev->cvq_lock);
 	while ((buf = virtqueue_get_buf(vq, &len))) {
 		spin_unlock(&portdev->cvq_lock);
@@ -1483,6 +1484,10 @@ static void control_work_handler(struct work_struct *work)
 		}
 	}
 	spin_unlock(&portdev->cvq_lock);
+	if (unlikely(!virtqueue_enable_cb(vq))) {
+		virtqueue_disable_cb(vq);
+		goto start;
+	}
 }
 
 static void out_intr(struct virtqueue *vq)
@@ -1533,6 +1538,7 @@ static void control_intr(struct virtqueue *vq)
 {
 	struct ports_device *portdev;
 
+	virtqueue_disable_cb(vq);
 	portdev = vq->vdev->priv;
 	schedule_work(&portdev->control_work);
 }
-- 
1.7.7.4



		Amit

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 06:01:52 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 06: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.xensource.com>)
	id 1RbQr4-00020E-Hm; Fri, 16 Dec 2011 06:01:14 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <amit.shah@redhat.com>) id 1RbQr2-000203-MO
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 06:01:12 +0000
X-Env-Sender: amit.shah@redhat.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1324015265!5726212!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDY0MDQ=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9042 invoked from network); 16 Dec 2011 06:01:06 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-12.tower-174.messagelabs.com with SMTP;
	16 Dec 2011 06:01:06 -0000
Received: from int-mx01.intmail.prod.int.phx2.redhat.com
	(int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id pBG60rxa006761
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 16 Dec 2011 01:00:53 -0500
Received: from localhost (ovpn-113-36.phx2.redhat.com [10.3.113.36])
	by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP
	id pBG60okG019224; Fri, 16 Dec 2011 01:00:51 -0500
Date: Fri, 16 Dec 2011 11:30:48 +0530
From: Amit Shah <amit.shah@redhat.com>
To: Miche Baker-Harvey <miche@google.com>
Message-ID: <20111216060048.GA12211@amit-x200.redhat.com>
References: <20111108214504.28884.61814.stgit@miche.sea.corp.google.com>
	<874nybqo0o.fsf@rustcorp.com.au>
	<CAB8RdapbaueyWLJuJDE_ZdvLkRNM4sQHTxgmgO=jrnXZ6YPSmA@mail.gmail.com>
	<20111123103852.GG16665@amit-x200.redhat.com>
	<CAB8RdaoDxMCgTjuGP70bGrsrtgh=USYtU3Spo5OPtVMYAM5EzQ@mail.gmail.com>
	<20111129142149.GE2822@amit-x200.redhat.com>
	<CAB8RdapuPRym2dH_9mgmGdzpCxnP1KpS+hS8JJ-geVkga5fMcw@mail.gmail.com>
	<CAB8Rdapfuf5XH+X9gsUL+CJ9gTQcSNfq4Dj9DoYWQeFgD04ODQ@mail.gmail.com>
	<20111205105452.GB27683@amit-x200.redhat.com>
	<CAB8Rdar=qOokxZkjQVRmo=zN_f75jPwzU+6=WBRo0g+P7w+pAw@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAB8Rdar=qOokxZkjQVRmo=zN_f75jPwzU+6=WBRo0g+P7w+pAw@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.11
Cc: Stephen Rothwell <sfr@canb.auug.org.au>, xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Rusty Russell <rusty@rustcorp.com.au>, linux-kernel@vger.kernel.org,
	virtualization@lists.linux-foundation.org,
	Anton Blanchard <anton@samba.org>, Mike Waychison <mikew@google.com>,
	ppc-dev <linuxppc-dev@lists.ozlabs.org>,
	Greg Kroah-Hartman <gregkh@suse.de>, Eric Northrup <digitaleric@google.com>
Subject: Re: [Xen-devel] [PATCH v3 2/3] hvc_init(): Enforce one-time
	initialization.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On (Tue) 06 Dec 2011 [09:05:38], Miche Baker-Harvey wrote:
> Amit,
> 
> Ah, indeed.  I am not using MSI-X, so virtio_pci::vp_try_to_find_vqs()
> calls vp_request_intx() and sets up an interrupt callback.  From
> there, when an interrupt occurs, the stack looks something like this:
> 
> virtio_pci::vp_interrupt()
>   virtio_pci::vp_vring_interrupt()
>     virtio_ring::vring_interrupt()
>       vq->vq.callback()  <-- in this case, that's virtio_console::control_intr()
>         workqueue::schedule_work()
>           workqueue::queue_work()
>             queue_work_on(get_cpu())  <-- queues the work on the current CPU.
> 
> I'm not doing anything to keep multiple control message from being
> sent concurrently to the guest, and we will take those interrupts on
> any CPU. I've confirmed that the two instances of
> handle_control_message() are occurring on different CPUs.

Hi Miche,

Here's a quick-and-dirty hack that should help.  I've not tested this,
and it's not yet signed-off-by.  Let me know if this helps.

>From 16708fa247c0dd34aa55d78166d65e463f9be6d6 Mon Sep 17 00:00:00 2001
Message-Id: <16708fa247c0dd34aa55d78166d65e463f9be6d6.1324015123.git.amit.shah@redhat.com>
From: Amit Shah <amit.shah@redhat.com>
Date: Fri, 16 Dec 2011 11:27:04 +0530
Subject: [PATCH 1/1] virtio: console: Serialise control work

We currently allow multiple instances of the control work handler to run
in parallel.  This isn't expected to work; serialise access by disabling
interrupts on new packets from the Host and enable them when all the
existing ones are consumed.
---
 drivers/char/virtio_console.c |    6 ++++++
 1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/drivers/char/virtio_console.c b/drivers/char/virtio_console.c
index 8e3c46d..72d396c 100644
--- a/drivers/char/virtio_console.c
+++ b/drivers/char/virtio_console.c
@@ -1466,6 +1466,7 @@ static void control_work_handler(struct work_struct *work)
 	portdev = container_of(work, struct ports_device, control_work);
 	vq = portdev->c_ivq;
 
+ start:
 	spin_lock(&portdev->cvq_lock);
 	while ((buf = virtqueue_get_buf(vq, &len))) {
 		spin_unlock(&portdev->cvq_lock);
@@ -1483,6 +1484,10 @@ static void control_work_handler(struct work_struct *work)
 		}
 	}
 	spin_unlock(&portdev->cvq_lock);
+	if (unlikely(!virtqueue_enable_cb(vq))) {
+		virtqueue_disable_cb(vq);
+		goto start;
+	}
 }
 
 static void out_intr(struct virtqueue *vq)
@@ -1533,6 +1538,7 @@ static void control_intr(struct virtqueue *vq)
 {
 	struct ports_device *portdev;
 
+	virtqueue_disable_cb(vq);
 	portdev = vq->vdev->priv;
 	schedule_work(&portdev->control_work);
 }
-- 
1.7.7.4



		Amit

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 07:56:01 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 07:56:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbSdW-00032R-Vy; Fri, 16 Dec 2011 07:55:22 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <gbtux@126.com>) id 1RbSdU-00032J-Dx
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 07:55:20 +0000
X-Env-Sender: gbtux@126.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1324022112!7497538!1
X-Originating-IP: [220.181.15.61]
X-SpamReason: No, hits=0.6 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMjAuMTgxLjE1LjYxID0+IDg3ODU=\n,sa_preprocessor: 
	QmFkIElQOiAyMjAuMTgxLjE1LjYxID0+IDg3ODU=\n,HTML_40_50,HTML_MESSAGE
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19245 invoked from network); 16 Dec 2011 07:55:13 -0000
Received: from m15-61.126.com (HELO m15-61.126.com) (220.181.15.61)
	by server-6.tower-182.messagelabs.com with SMTP;
	16 Dec 2011 07:55:13 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=126.com;
	s=s110527; h=Received:Date:From:To:Message-ID:Subject:
	MIME-Version:Content-Type; bh=nUD23NFihi6ezN7DNdZ6NL1QpGnS4lNh99
	KBE21mPLg=; b=BObJWvGxOQ9/MB0z+movAz1nzySFo7wsLSPYJ3bKyqHt5K5o65
	Eo+v0iCxLlo85rlXSybEJpeeUVPyhXj5wh4kbxr6e958DgdRza1T+iEArieC77CP
	LAL3ngmXgEPJXY0QH6CSIgWznQW5//jiPDZqsOLSxBERuDO/aIcevA62U=
Received: from gbtux ( [124.16.139.196] ) by ajax-webmail-wmsvr61 (Coremail)
	; Fri, 16 Dec 2011 15:55:07 +0800 (CST)
Date: Fri, 16 Dec 2011 15:55:07 +0800 (CST)
From: zhikai <gbtux@126.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Message-ID: <26c93838.3b3fb.13445de0e67.Coremail.gbtux@126.com>
MIME-Version: 1.0
X-Originating-IP: [124.16.139.196]
X-Priority: 3
X-Mailer: Coremail Webmail Server Version SP_ntes V3.5 build
	111202(16086.4213.4207) Copyright (c) 2002-2011 www.mailtech.cn 126com
X-CM-CTRLDATA: ewGpUWZvb3Rlcl9odG09NjExOjgx
X-CM-TRANSID: PcqowEA5a0Ve+epO6MkmAA--.1464W
X-CM-SenderInfo: pjew35a6rslhhfrp/1tbiWQIYnE3AJNfJ1wAAs-
X-Coremail-Antispam: 1U5529EdanIXcx71UUUUU7vcSsGvfC2KfnxnUU==
Subject: [Xen-devel] A question on the credit scheduler
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============9023758457994064493=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============9023758457994064493==
Content-Type: multipart/alternative; 
	boundary="----=_Part_684796_492820696.1324022107751"

------=_Part_684796_492820696.1324022107751
Content-Type: text/plain; charset=GBK
Content-Transfer-Encoding: 7bit

Hi All,


In the credit scheduler, the scheduling decision function csched_schedule() is called in the schedule function in scheduler.c, such as the following.
next_slice = sched->do_schedule(sched, now, tasklet_work_scheduled);


But, how often the csched_schedule() is called and to run? Does this frequency have something to do with the slice of credit scheduler that is 30ms?


Best Regards,
Gavin


------=_Part_684796_492820696.1324022107751
Content-Type: text/html; charset=GBK
Content-Transfer-Encoding: 7bit

<div style="line-height:1.7;color:#000000;font-size:14px;font-family:arial">Hi All,<div><br></div><div>In the credit scheduler, the scheduling decision function&nbsp;csched_schedule() is called in the schedule function in scheduler.c, such as the following.</div><div><div>next_slice = sched-&gt;do_schedule(sched, now, tasklet_work_scheduled);</div><div><br></div><div>But, how often the&nbsp;csched_schedule() is called and to run? Does this frequency have something to do with the slice of credit scheduler that is 30ms?</div><div><br></div></div><div>Best Regards,</div><div>Gavin</div><div><br></div></div><br><br><span title="neteasefooter"><span id="netease_mail_footer"></span></span>
------=_Part_684796_492820696.1324022107751--



--===============9023758457994064493==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============9023758457994064493==--



From xen-devel-bounces@lists.xensource.com Fri Dec 16 07:56:01 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 07:56:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbSdW-00032R-Vy; Fri, 16 Dec 2011 07:55:22 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <gbtux@126.com>) id 1RbSdU-00032J-Dx
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 07:55:20 +0000
X-Env-Sender: gbtux@126.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1324022112!7497538!1
X-Originating-IP: [220.181.15.61]
X-SpamReason: No, hits=0.6 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMjAuMTgxLjE1LjYxID0+IDg3ODU=\n,sa_preprocessor: 
	QmFkIElQOiAyMjAuMTgxLjE1LjYxID0+IDg3ODU=\n,HTML_40_50,HTML_MESSAGE
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19245 invoked from network); 16 Dec 2011 07:55:13 -0000
Received: from m15-61.126.com (HELO m15-61.126.com) (220.181.15.61)
	by server-6.tower-182.messagelabs.com with SMTP;
	16 Dec 2011 07:55:13 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=126.com;
	s=s110527; h=Received:Date:From:To:Message-ID:Subject:
	MIME-Version:Content-Type; bh=nUD23NFihi6ezN7DNdZ6NL1QpGnS4lNh99
	KBE21mPLg=; b=BObJWvGxOQ9/MB0z+movAz1nzySFo7wsLSPYJ3bKyqHt5K5o65
	Eo+v0iCxLlo85rlXSybEJpeeUVPyhXj5wh4kbxr6e958DgdRza1T+iEArieC77CP
	LAL3ngmXgEPJXY0QH6CSIgWznQW5//jiPDZqsOLSxBERuDO/aIcevA62U=
Received: from gbtux ( [124.16.139.196] ) by ajax-webmail-wmsvr61 (Coremail)
	; Fri, 16 Dec 2011 15:55:07 +0800 (CST)
Date: Fri, 16 Dec 2011 15:55:07 +0800 (CST)
From: zhikai <gbtux@126.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Message-ID: <26c93838.3b3fb.13445de0e67.Coremail.gbtux@126.com>
MIME-Version: 1.0
X-Originating-IP: [124.16.139.196]
X-Priority: 3
X-Mailer: Coremail Webmail Server Version SP_ntes V3.5 build
	111202(16086.4213.4207) Copyright (c) 2002-2011 www.mailtech.cn 126com
X-CM-CTRLDATA: ewGpUWZvb3Rlcl9odG09NjExOjgx
X-CM-TRANSID: PcqowEA5a0Ve+epO6MkmAA--.1464W
X-CM-SenderInfo: pjew35a6rslhhfrp/1tbiWQIYnE3AJNfJ1wAAs-
X-Coremail-Antispam: 1U5529EdanIXcx71UUUUU7vcSsGvfC2KfnxnUU==
Subject: [Xen-devel] A question on the credit scheduler
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============9023758457994064493=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============9023758457994064493==
Content-Type: multipart/alternative; 
	boundary="----=_Part_684796_492820696.1324022107751"

------=_Part_684796_492820696.1324022107751
Content-Type: text/plain; charset=GBK
Content-Transfer-Encoding: 7bit

Hi All,


In the credit scheduler, the scheduling decision function csched_schedule() is called in the schedule function in scheduler.c, such as the following.
next_slice = sched->do_schedule(sched, now, tasklet_work_scheduled);


But, how often the csched_schedule() is called and to run? Does this frequency have something to do with the slice of credit scheduler that is 30ms?


Best Regards,
Gavin


------=_Part_684796_492820696.1324022107751
Content-Type: text/html; charset=GBK
Content-Transfer-Encoding: 7bit

<div style="line-height:1.7;color:#000000;font-size:14px;font-family:arial">Hi All,<div><br></div><div>In the credit scheduler, the scheduling decision function&nbsp;csched_schedule() is called in the schedule function in scheduler.c, such as the following.</div><div><div>next_slice = sched-&gt;do_schedule(sched, now, tasklet_work_scheduled);</div><div><br></div><div>But, how often the&nbsp;csched_schedule() is called and to run? Does this frequency have something to do with the slice of credit scheduler that is 30ms?</div><div><br></div></div><div>Best Regards,</div><div>Gavin</div><div><br></div></div><br><br><span title="neteasefooter"><span id="netease_mail_footer"></span></span>
------=_Part_684796_492820696.1324022107751--



--===============9023758457994064493==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============9023758457994064493==--



From xen-devel-bounces@lists.xensource.com Fri Dec 16 08:27:33 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 08:27:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbT82-0003j1-1L; Fri, 16 Dec 2011 08:26:54 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RbT81-0003it-Ip
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 08:26:53 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1324024006!8443802!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29765 invoked from network); 16 Dec 2011 08:26:47 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-8.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 16 Dec 2011 08:26:47 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 16 Dec 2011 08:27:49 +0000
Message-Id: <4EEB0ED402000078000686CE@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 16 Dec 2011 08:26:44 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Boris Ostrovsky" <boris.ostrovsky@amd.com>
References: <mailman.4490.1323956364.12970.xen-devel@lists.xensource.com>
	<4EEA33CA.7030906@amd.com>
In-Reply-To: <4EEA33CA.7030906@amd.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] x86/emulator: workaround for AMD erratum 573
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 15.12.11 at 18:52, Boris Ostrovsky <boris.ostrovsky@amd.com> wrote:
>> --- a/xen/include/asm-x86/amd.h
>> +++ b/xen/include/asm-x86/amd.h
>> @@ -134,6 +134,12 @@
>>       AMD_OSVW_ERRATUM(3, AMD_MODEL_RANGE(0x10, 0x2, 0x1, 0xff, 0xf),	\
>>   		        AMD_MODEL_RANGE(0x12, 0x0, 0x0, 0x1, 0x0))
>>
>> +#define AMD_ERRATUM_573							\
>> +    AMD_LEGACY_ERRATUM(AMD_MODEL_RANGE(0x0f, 0x0, 0x0, 0xff, 0xf),	\
>> +                       AMD_MODEL_RANGE(0x10, 0x0, 0x0, 0xff, 0xf),	\
>> +                       AMD_MODEL_RANGE(0x11, 0x0, 0x0, 0xff, 0xf),	\
>> +                       AMD_MODEL_RANGE(0x12, 0x0, 0x0, 0xff, 0xf))
> 
> Families 0xf and 0x11 are not affected by erratum 573.

Are you saying that these two documents

33610 Rev. 3.48 December 2011
41788 Rev. 3.10 December 2011

both wrong? For fam 0xf it may be that we can set a lower bound for
pre-NPT ones if those indeed are unaffected (but we'd like to be sure
this is the case) - that would appear to be all with a model below 0x40.

Please clarify.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 08:27:33 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 08:27:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbT82-0003j1-1L; Fri, 16 Dec 2011 08:26:54 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RbT81-0003it-Ip
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 08:26:53 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1324024006!8443802!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29765 invoked from network); 16 Dec 2011 08:26:47 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-8.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 16 Dec 2011 08:26:47 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 16 Dec 2011 08:27:49 +0000
Message-Id: <4EEB0ED402000078000686CE@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 16 Dec 2011 08:26:44 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Boris Ostrovsky" <boris.ostrovsky@amd.com>
References: <mailman.4490.1323956364.12970.xen-devel@lists.xensource.com>
	<4EEA33CA.7030906@amd.com>
In-Reply-To: <4EEA33CA.7030906@amd.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] x86/emulator: workaround for AMD erratum 573
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 15.12.11 at 18:52, Boris Ostrovsky <boris.ostrovsky@amd.com> wrote:
>> --- a/xen/include/asm-x86/amd.h
>> +++ b/xen/include/asm-x86/amd.h
>> @@ -134,6 +134,12 @@
>>       AMD_OSVW_ERRATUM(3, AMD_MODEL_RANGE(0x10, 0x2, 0x1, 0xff, 0xf),	\
>>   		        AMD_MODEL_RANGE(0x12, 0x0, 0x0, 0x1, 0x0))
>>
>> +#define AMD_ERRATUM_573							\
>> +    AMD_LEGACY_ERRATUM(AMD_MODEL_RANGE(0x0f, 0x0, 0x0, 0xff, 0xf),	\
>> +                       AMD_MODEL_RANGE(0x10, 0x0, 0x0, 0xff, 0xf),	\
>> +                       AMD_MODEL_RANGE(0x11, 0x0, 0x0, 0xff, 0xf),	\
>> +                       AMD_MODEL_RANGE(0x12, 0x0, 0x0, 0xff, 0xf))
> 
> Families 0xf and 0x11 are not affected by erratum 573.

Are you saying that these two documents

33610 Rev. 3.48 December 2011
41788 Rev. 3.10 December 2011

both wrong? For fam 0xf it may be that we can set a lower bound for
pre-NPT ones if those indeed are unaffected (but we'd like to be sure
this is the case) - that would appear to be all with a model below 0x40.

Please clarify.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 08:51:29 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 08:51:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbTVJ-0004GL-Q8; Fri, 16 Dec 2011 08:50:57 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RbTVH-0004GC-Tn
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 08:50:56 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1324025447!7693627!1
X-Originating-IP: [209.85.160.43]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3063 invoked from network); 16 Dec 2011 08:50:49 -0000
Received: from mail-pw0-f43.google.com (HELO mail-pw0-f43.google.com)
	(209.85.160.43)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Dec 2011 08:50:49 -0000
Received: by pbbb11 with SMTP id b11so8760136pbb.30
	for <xen-devel@lists.xensource.com>;
	Fri, 16 Dec 2011 00:50:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=zR+SLy9cPiaA9hL+ZJNVJnvmr1T6nhqLdq4f8pgfIcw=;
	b=rrA7gEZWi5cNe2qQEi43XsqbCJwauwyiv5i9rYrxvVJbh73iNyQKH0Bvu3vu21j04F
	58xVHK0QbikP7hEyabrxq7e7ybwqdn3LwO1GfFeLh74Da/QFXm+dW/DQuHCZSUbBoNnz
	wAUf7KcLWxT/y/yDIk232U4PSQo1AHvSA6otY=
MIME-Version: 1.0
Received: by 10.68.73.103 with SMTP id k7mr14690021pbv.132.1324025447346; Fri,
	16 Dec 2011 00:50:47 -0800 (PST)
Received: by 10.142.47.17 with HTTP; Fri, 16 Dec 2011 00:50:47 -0800 (PST)
In-Reply-To: <20111215185124.GA30948@aepfle.de>
References: <3bac38f7a427af3eb9f6.1323871739@loki.upc.es>
	<20202.11863.501987.497546@mariner.uk.xensource.com>
	<20111215185124.GA30948@aepfle.de>
Date: Fri, 16 Dec 2011 09:50:47 +0100
X-Google-Sender-Auth: Xx7l8mXuwcPrS2A6lBM8hNbCzfU
Message-ID: <CAPLaKK7=-M_x88amMZ5nKNk0FdFdHmQ+tgR5RQzSKAy9Ed7fCA@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Olaf Hering <olaf@aepfle.de>
Cc: xen-devel@lists.xensource.com, Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v2] xenpaging: remove _XOPEN_SOURCE
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

2011/12/15 Olaf Hering <olaf@aepfle.de>:
> On Thu, Dec 15, Ian Jackson wrote:
>
>> Roger Pau Monne writes ("[Xen-devel] [PATCH v2] xenpaging: remove _XOPEN_SOURCE"):
>> > xenpaging: remove _XOPEN_SOURCE
>> >
>> > The _XOPEN_SOURCE define was breaking the compilation under NetBSD.
>> > I've removed it becasue it is not necessary.
>>
>> I thought we'd decided that _NETBSD_SOURCE should be added ?
>
> The initial patch which added _XOPEN_SOURCE should have a reasonable
> description which includes the error message, and it should have been
> _GNU_SOURCE instead of _XOPEN_SOURCE in the first place.
>
> Please remove _XOPEN_SOURCE.

Both patches are on the list, now it's up to Ian Jackson to decide
which one to apply.

Roger.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 08:51:29 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 08:51:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbTVJ-0004GL-Q8; Fri, 16 Dec 2011 08:50:57 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RbTVH-0004GC-Tn
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 08:50:56 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1324025447!7693627!1
X-Originating-IP: [209.85.160.43]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3063 invoked from network); 16 Dec 2011 08:50:49 -0000
Received: from mail-pw0-f43.google.com (HELO mail-pw0-f43.google.com)
	(209.85.160.43)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Dec 2011 08:50:49 -0000
Received: by pbbb11 with SMTP id b11so8760136pbb.30
	for <xen-devel@lists.xensource.com>;
	Fri, 16 Dec 2011 00:50:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=zR+SLy9cPiaA9hL+ZJNVJnvmr1T6nhqLdq4f8pgfIcw=;
	b=rrA7gEZWi5cNe2qQEi43XsqbCJwauwyiv5i9rYrxvVJbh73iNyQKH0Bvu3vu21j04F
	58xVHK0QbikP7hEyabrxq7e7ybwqdn3LwO1GfFeLh74Da/QFXm+dW/DQuHCZSUbBoNnz
	wAUf7KcLWxT/y/yDIk232U4PSQo1AHvSA6otY=
MIME-Version: 1.0
Received: by 10.68.73.103 with SMTP id k7mr14690021pbv.132.1324025447346; Fri,
	16 Dec 2011 00:50:47 -0800 (PST)
Received: by 10.142.47.17 with HTTP; Fri, 16 Dec 2011 00:50:47 -0800 (PST)
In-Reply-To: <20111215185124.GA30948@aepfle.de>
References: <3bac38f7a427af3eb9f6.1323871739@loki.upc.es>
	<20202.11863.501987.497546@mariner.uk.xensource.com>
	<20111215185124.GA30948@aepfle.de>
Date: Fri, 16 Dec 2011 09:50:47 +0100
X-Google-Sender-Auth: Xx7l8mXuwcPrS2A6lBM8hNbCzfU
Message-ID: <CAPLaKK7=-M_x88amMZ5nKNk0FdFdHmQ+tgR5RQzSKAy9Ed7fCA@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Olaf Hering <olaf@aepfle.de>
Cc: xen-devel@lists.xensource.com, Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v2] xenpaging: remove _XOPEN_SOURCE
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

2011/12/15 Olaf Hering <olaf@aepfle.de>:
> On Thu, Dec 15, Ian Jackson wrote:
>
>> Roger Pau Monne writes ("[Xen-devel] [PATCH v2] xenpaging: remove _XOPEN_SOURCE"):
>> > xenpaging: remove _XOPEN_SOURCE
>> >
>> > The _XOPEN_SOURCE define was breaking the compilation under NetBSD.
>> > I've removed it becasue it is not necessary.
>>
>> I thought we'd decided that _NETBSD_SOURCE should be added ?
>
> The initial patch which added _XOPEN_SOURCE should have a reasonable
> description which includes the error message, and it should have been
> _GNU_SOURCE instead of _XOPEN_SOURCE in the first place.
>
> Please remove _XOPEN_SOURCE.

Both patches are on the list, now it's up to Ian Jackson to decide
which one to apply.

Roger.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 08:51:58 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 08:51:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbTVr-0004Hs-7T; Fri, 16 Dec 2011 08:51:31 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RbTVp-0004HX-Pq
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 08:51:30 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1324025431!60985447!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5689 invoked from network); 16 Dec 2011 08:50:31 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-7.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 16 Dec 2011 08:50:31 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 16 Dec 2011 08:52:28 +0000
Message-Id: <4EEB149B02000078000686E3@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 16 Dec 2011 08:51:23 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "dbrace" <dab@hp.com>
References: <4EDFDF0D.2020104@hp.com>
	<4EE628D80200007800066F9E@nat28.tlf.novell.com>
	<20111214213443.GC25896@andromeda.dapyr.net>
	<4EE9C15602000078000680D3@nat28.tlf.novell.com>
	<6738613108553D49BEFEFDD59230CCDF011BED93@G4W3300.americas.hpqcorp.net>
	<4EEA304402000078000684C8@nat28.tlf.novell.com>
	<4EEA8084.8030208@hp.com>
In-Reply-To: <4EEA8084.8030208@hp.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] kmap_atomic issue with SLES11SP1 32bit XEN driver
 code
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 16.12.11 at 00:19, dbrace <dab@hp.com> wrote:
> Can you give me some URLs to documentation that can help me understand 
> my issue?

I'm not aware of any.

> Is sounds like I cannot go back to the correct virtual address after I 
> map it for DMA.

Is it really a problem to insert a proper bus_to_phys() (or mfn_to_pfn()
if you are willing to tolerate Xen-specific code) translation?

Jan

> On 12/15/2011 10:37 AM, Jan Beulich wrote:
>>>>> On 15.12.11 at 17:15, "Brace, Don"<dab@hp.com>  wrote:
>>> I do not understand what this means:
>>> " That is, we'd be susceptible to this problem only if within a
>>> lazy-mode enabled section k{,un}map_atomic were used
>>> synchronously (which I'd consider a coding mistake)."
>>>
>>> Could you elaborate on this?
>> Not sure what additional explanation is needed. kmap_atomic() is
>> intended to be used in atomic context, and if you use it elsewhere
>> that's a mis-use.
>>
>>> Here is what I am trying to do.
>>> I am in a LLD I have bus addresses that are DMA-able that I would normally
>>> DMA to except this driver is emulating hardware in software and so it does
>>> not need to DMA is needs to transfer the data with the CPU.
>> So this makes clear that what I told you about a possibly missing
>> translation is likely the culprit. Quoting from your original mail
>>
>>                   linux_page = __pfn_to_page(physical_address>>  PAGE_SHIFT);
>>
>> I have to assume that physical_address really isn't a physical address,
>> but a bus one. Hence you first need to translate it to a physical one
>> before passing it to __pfn_to_page().
>>
>>> On non-XEN 32bit kernels I use kmap_atomic() and it handles both highmem
>>> addresses and non highmem addresses with no issues.
>> And so does it on Xen.
>>
>>> When I am running 32bit XEN kernels I run into issues like this:
>>>      "BUG: unable to handle kernel paging request at 9822bf40"
>> Because you pass in a random struct page *.
>>
>> Jan
>>
> 
> -- 
> Don Brace
> SPSN Linux Development
> Hewlett-Packard Company




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 08:51:58 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 08:51:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbTVr-0004Hs-7T; Fri, 16 Dec 2011 08:51:31 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RbTVp-0004HX-Pq
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 08:51:30 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1324025431!60985447!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5689 invoked from network); 16 Dec 2011 08:50:31 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-7.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 16 Dec 2011 08:50:31 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 16 Dec 2011 08:52:28 +0000
Message-Id: <4EEB149B02000078000686E3@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 16 Dec 2011 08:51:23 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "dbrace" <dab@hp.com>
References: <4EDFDF0D.2020104@hp.com>
	<4EE628D80200007800066F9E@nat28.tlf.novell.com>
	<20111214213443.GC25896@andromeda.dapyr.net>
	<4EE9C15602000078000680D3@nat28.tlf.novell.com>
	<6738613108553D49BEFEFDD59230CCDF011BED93@G4W3300.americas.hpqcorp.net>
	<4EEA304402000078000684C8@nat28.tlf.novell.com>
	<4EEA8084.8030208@hp.com>
In-Reply-To: <4EEA8084.8030208@hp.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] kmap_atomic issue with SLES11SP1 32bit XEN driver
 code
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 16.12.11 at 00:19, dbrace <dab@hp.com> wrote:
> Can you give me some URLs to documentation that can help me understand 
> my issue?

I'm not aware of any.

> Is sounds like I cannot go back to the correct virtual address after I 
> map it for DMA.

Is it really a problem to insert a proper bus_to_phys() (or mfn_to_pfn()
if you are willing to tolerate Xen-specific code) translation?

Jan

> On 12/15/2011 10:37 AM, Jan Beulich wrote:
>>>>> On 15.12.11 at 17:15, "Brace, Don"<dab@hp.com>  wrote:
>>> I do not understand what this means:
>>> " That is, we'd be susceptible to this problem only if within a
>>> lazy-mode enabled section k{,un}map_atomic were used
>>> synchronously (which I'd consider a coding mistake)."
>>>
>>> Could you elaborate on this?
>> Not sure what additional explanation is needed. kmap_atomic() is
>> intended to be used in atomic context, and if you use it elsewhere
>> that's a mis-use.
>>
>>> Here is what I am trying to do.
>>> I am in a LLD I have bus addresses that are DMA-able that I would normally
>>> DMA to except this driver is emulating hardware in software and so it does
>>> not need to DMA is needs to transfer the data with the CPU.
>> So this makes clear that what I told you about a possibly missing
>> translation is likely the culprit. Quoting from your original mail
>>
>>                   linux_page = __pfn_to_page(physical_address>>  PAGE_SHIFT);
>>
>> I have to assume that physical_address really isn't a physical address,
>> but a bus one. Hence you first need to translate it to a physical one
>> before passing it to __pfn_to_page().
>>
>>> On non-XEN 32bit kernels I use kmap_atomic() and it handles both highmem
>>> addresses and non highmem addresses with no issues.
>> And so does it on Xen.
>>
>>> When I am running 32bit XEN kernels I run into issues like this:
>>>      "BUG: unable to handle kernel paging request at 9822bf40"
>> Because you pass in a random struct page *.
>>
>> Jan
>>
> 
> -- 
> Don Brace
> SPSN Linux Development
> Hewlett-Packard Company




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 09:09:42 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 09: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.xensource.com>)
	id 1RbTmx-0004fD-Dv; Fri, 16 Dec 2011 09:09:11 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RbTmw-0004f8-M9
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 09:09:10 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1324026499!49259309!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjU3OQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32474 invoked from network); 16 Dec 2011 09:08:20 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Dec 2011 09:08:20 -0000
X-IronPort-AV: E=Sophos;i="4.71,362,1320624000"; 
   d="scan'208";a="9507238"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Dec 2011 09:08:37 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 16 Dec 2011 09:08:37 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Fri, 16 Dec 2011 09:08:36 +0000
In-Reply-To: <20202.12428.280036.892796@mariner.uk.xensource.com>
References: <patchbomb.1323961634@loki.upc.es>
	<20202.12428.280036.892796@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1324026516.20077.518.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Roger Pau Monne <roger.pau@entel.upc.edu>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 00 of 15 v5] libxl: add support for hotplug
 script calling from libxl
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2011-12-15 at 17:38 +0000, Ian Jackson wrote:
> Roger Pau Monne writes ("[Xen-devel] [PATCH 00 of 15 v5] libxl: add support for hotplug script calling from libxl"):
> > This patch series adds support for hotplug script calling directly
> > from libxl, instead of relying on xenbackendd. Also some patches
> > contain general bug fixes.
> 
> Thanks for the resend.  I think I have already acked a number of these
> patches.  But your resend has dropped (or, if you prefer to think of
> it like that) not added my Acked-By lines.
> 
> Can you please try to keep track Acked-By in your series ?  That will
> make it easier for us to see what we need to re-review.

This is a common omission. I've added a section to
http://wiki.xen.org/wiki/SubmittingXenPatches on resending and have
included this advice.

Ian.

> 
> If you can repost a subseries which I have already acked, I would be
> inclined to apply them right away.
> 
> Ian.
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 09:09:42 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 09: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.xensource.com>)
	id 1RbTmx-0004fD-Dv; Fri, 16 Dec 2011 09:09:11 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RbTmw-0004f8-M9
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 09:09:10 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1324026499!49259309!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjU3OQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32474 invoked from network); 16 Dec 2011 09:08:20 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Dec 2011 09:08:20 -0000
X-IronPort-AV: E=Sophos;i="4.71,362,1320624000"; 
   d="scan'208";a="9507238"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Dec 2011 09:08:37 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 16 Dec 2011 09:08:37 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Fri, 16 Dec 2011 09:08:36 +0000
In-Reply-To: <20202.12428.280036.892796@mariner.uk.xensource.com>
References: <patchbomb.1323961634@loki.upc.es>
	<20202.12428.280036.892796@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1324026516.20077.518.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Roger Pau Monne <roger.pau@entel.upc.edu>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 00 of 15 v5] libxl: add support for hotplug
 script calling from libxl
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2011-12-15 at 17:38 +0000, Ian Jackson wrote:
> Roger Pau Monne writes ("[Xen-devel] [PATCH 00 of 15 v5] libxl: add support for hotplug script calling from libxl"):
> > This patch series adds support for hotplug script calling directly
> > from libxl, instead of relying on xenbackendd. Also some patches
> > contain general bug fixes.
> 
> Thanks for the resend.  I think I have already acked a number of these
> patches.  But your resend has dropped (or, if you prefer to think of
> it like that) not added my Acked-By lines.
> 
> Can you please try to keep track Acked-By in your series ?  That will
> make it easier for us to see what we need to re-review.

This is a common omission. I've added a section to
http://wiki.xen.org/wiki/SubmittingXenPatches on resending and have
included this advice.

Ian.

> 
> If you can repost a subseries which I have already acked, I would be
> inclined to apply them right away.
> 
> Ian.
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 09:09:58 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 09: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.xensource.com>)
	id 1RbTnL-0004g9-Rk; Fri, 16 Dec 2011 09:09:35 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RbTnK-0004fd-K3
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 09:09:34 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1324026565!7504032!1
X-Originating-IP: [209.85.161.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1344 invoked from network); 16 Dec 2011 09:09:26 -0000
Received: from mail-fx0-f43.google.com (HELO mail-fx0-f43.google.com)
	(209.85.161.43)
	by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Dec 2011 09:09:26 -0000
Received: by faap21 with SMTP id p21so6814279faa.30
	for <xen-devel@lists.xensource.com>;
	Fri, 16 Dec 2011 01:09:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=NlQkRa59qbnSv3Hqa9CKWmZPZhApwWR87PVmkOf9DLw=;
	b=pYrmKWwMJZtTCXmf3kSBEqoD/3VZfXAp082VczPDyFSb7tbYHv0UEdznIT2cJP7B2P
	ElMGGwCZBi1WSWRotUYW7LXrP+KRa8AUGKonkj+mfG1xji5Xrd+IBtC+XvZ9tJyjyH4Y
	mSuchmcltHMa2EnlSbdwxS7ZDKxGc87DzYA2Q=
Received: by 10.180.4.42 with SMTP id h10mr10940648wih.22.1324026564988;
	Fri, 16 Dec 2011 01:09:24 -0800 (PST)
Received: from [192.168.1.70] (host81-152-17-11.range81-152.btcentralplus.com.
	[81.152.17.11])
	by mx.google.com with ESMTPS id v10sm12186870wiy.23.2011.12.16.01.09.22
	(version=SSLv3 cipher=OTHER); Fri, 16 Dec 2011 01:09:24 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Fri, 16 Dec 2011 09:09:20 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Message-ID: <CB10BB40.27633%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH] x86: convert BUG_ON()s to WARN_ON()s in
	read_descriptor()
Thread-Index: Acy70mUQUKTJYlXGukOY9It2BALSFQ==
In-Reply-To: <4EE9D92A020000780006813A@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH] x86: convert BUG_ON()s to WARN_ON()s in
 read_descriptor()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 15/12/2011 10:25, "Jan Beulich" <JBeulich@suse.com> wrote:

> In the light of AMD erratum #700, and given that these checks happen
> for debugging purposes only and also only in debug builds of the
> hypervisor, make the failures non-fatal.

I think the changeset comment should have a brief description of erratum
#700. I also some reference should be made in a comment above the first
WARN_ON, explaining why they are now WARN_Ons (again, with reference to #700
and its symptoms).

Apart from that:
Acked-by: Keir Fraser <keir@xen.org>

> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> --- a/xen/arch/x86/traps.c
> +++ b/xen/arch/x86/traps.c
> @@ -1544,11 +1544,11 @@ static int read_descriptor(unsigned int
>              asm volatile (
>                  "larl %2,%0 ; setz %1"
>                  : "=r" (a), "=qm" (valid) : "rm" (sel));
> -            BUG_ON(valid && ((a & 0x00f0ff00) != *ar));
> +            WARN_ON(valid && ((a & 0x00f0ff00) != *ar));
>              asm volatile (
>                  "lsll %2,%0 ; setz %1"
>                  : "=r" (l), "=qm" (valid) : "rm" (sel));
> -            BUG_ON(valid && (l != *limit));
> +            WARN_ON(valid && (l != *limit));
>          }
>  #endif
>      }
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 09:09:58 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 09: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.xensource.com>)
	id 1RbTnL-0004g9-Rk; Fri, 16 Dec 2011 09:09:35 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RbTnK-0004fd-K3
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 09:09:34 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1324026565!7504032!1
X-Originating-IP: [209.85.161.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1344 invoked from network); 16 Dec 2011 09:09:26 -0000
Received: from mail-fx0-f43.google.com (HELO mail-fx0-f43.google.com)
	(209.85.161.43)
	by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Dec 2011 09:09:26 -0000
Received: by faap21 with SMTP id p21so6814279faa.30
	for <xen-devel@lists.xensource.com>;
	Fri, 16 Dec 2011 01:09:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=NlQkRa59qbnSv3Hqa9CKWmZPZhApwWR87PVmkOf9DLw=;
	b=pYrmKWwMJZtTCXmf3kSBEqoD/3VZfXAp082VczPDyFSb7tbYHv0UEdznIT2cJP7B2P
	ElMGGwCZBi1WSWRotUYW7LXrP+KRa8AUGKonkj+mfG1xji5Xrd+IBtC+XvZ9tJyjyH4Y
	mSuchmcltHMa2EnlSbdwxS7ZDKxGc87DzYA2Q=
Received: by 10.180.4.42 with SMTP id h10mr10940648wih.22.1324026564988;
	Fri, 16 Dec 2011 01:09:24 -0800 (PST)
Received: from [192.168.1.70] (host81-152-17-11.range81-152.btcentralplus.com.
	[81.152.17.11])
	by mx.google.com with ESMTPS id v10sm12186870wiy.23.2011.12.16.01.09.22
	(version=SSLv3 cipher=OTHER); Fri, 16 Dec 2011 01:09:24 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Fri, 16 Dec 2011 09:09:20 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Message-ID: <CB10BB40.27633%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH] x86: convert BUG_ON()s to WARN_ON()s in
	read_descriptor()
Thread-Index: Acy70mUQUKTJYlXGukOY9It2BALSFQ==
In-Reply-To: <4EE9D92A020000780006813A@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH] x86: convert BUG_ON()s to WARN_ON()s in
 read_descriptor()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 15/12/2011 10:25, "Jan Beulich" <JBeulich@suse.com> wrote:

> In the light of AMD erratum #700, and given that these checks happen
> for debugging purposes only and also only in debug builds of the
> hypervisor, make the failures non-fatal.

I think the changeset comment should have a brief description of erratum
#700. I also some reference should be made in a comment above the first
WARN_ON, explaining why they are now WARN_Ons (again, with reference to #700
and its symptoms).

Apart from that:
Acked-by: Keir Fraser <keir@xen.org>

> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> --- a/xen/arch/x86/traps.c
> +++ b/xen/arch/x86/traps.c
> @@ -1544,11 +1544,11 @@ static int read_descriptor(unsigned int
>              asm volatile (
>                  "larl %2,%0 ; setz %1"
>                  : "=r" (a), "=qm" (valid) : "rm" (sel));
> -            BUG_ON(valid && ((a & 0x00f0ff00) != *ar));
> +            WARN_ON(valid && ((a & 0x00f0ff00) != *ar));
>              asm volatile (
>                  "lsll %2,%0 ; setz %1"
>                  : "=r" (l), "=qm" (valid) : "rm" (sel));
> -            BUG_ON(valid && (l != *limit));
> +            WARN_ON(valid && (l != *limit));
>          }
>  #endif
>      }
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 09:19:17 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 09:19:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbTwL-00050Y-5D; Fri, 16 Dec 2011 09:18:53 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <stefan.bader@canonical.com>) id 1RbTwJ-00050H-Lr
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 09:18:51 +0000
X-Env-Sender: stefan.bader@canonical.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1324027116!7636046!1
X-Originating-IP: [91.189.89.112]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29950 invoked from network); 16 Dec 2011 09:18:43 -0000
Received: from youngberry.canonical.com (HELO youngberry.canonical.com)
	(91.189.89.112) by server-14.tower-21.messagelabs.com with SMTP;
	16 Dec 2011 09:18:43 -0000
Received: from p5b2e5f25.dip.t-dialin.net ([91.46.95.37] helo=[192.168.2.5])
	by youngberry.canonical.com with esmtpsa
	(TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71)
	(envelope-from <stefan.bader@canonical.com>)
	id 1RbTw2-0001M3-WE; Fri, 16 Dec 2011 09:18:35 +0000
Message-ID: <4EEB0CE9.4040405@canonical.com>
Date: Fri, 16 Dec 2011 10:18:33 +0100
From: Stefan Bader <stefan.bader@canonical.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:8.0) Gecko/20111124 Thunderbird/8.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <4EEA4877.8010307@canonical.com>
	<1323982417.20936.898.camel@dagon.hellion.org.uk>
In-Reply-To: <1323982417.20936.898.camel@dagon.hellion.org.uk>
X-Enigmail-Version: 1.4a1pre
Cc: Olaf Hering <olaf@aepfle.de>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] xenbus and the message of doom
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 15.12.2011 21:53, Ian Campbell wrote:
> On Thu, 2011-12-15 at 19:20 +0000, Stefan Bader wrote:
>> I was investigating a bug report[1] about newer kernels (>3.1) not booting as
>> HVM guests on Amazon EC2. For some reason git bisect did give the some pain, but
>> it lead me at least close and with some crash dump data I think I figured the
>> problem.
>>
>> commit ddacf5ef684a655abe2bb50c4b2a5b72ae0d5e05
>> Author: Olaf Hering <olaf@aepfle.de>
>> Date:   Thu Sep 22 16:14:49 2011 +0200
>>
>>     xen/pv-on-hvm kexec: add xs_reset_watches to shutdown watches from old
>>     kernel
>>
>> This change introduced a xs_reset_watches() call. The problem seems to be that
>> there is at least some version of Xen (I was able to reproduce with a 3.4.3
>> version which I admit to deliberately not having updated) for which xenstore
>> will not return any reply.
>>
>> At least the backtraces in crash showed that xs_init had been calling
>> xs_reset_watches() and that was happily idling in read_reply(). Effectively
>> nothing was going on and the boot just hung.
>> By just not doing that xs_reset_watches() call, I was able to boot under the
>> same host. And for what it is worth there has not been an issue with Xen 4.1.1
>> and a 3.0 dom0 kernel. Just this "older" release is trouble.
> 
> I sent a patch to fix exactly this issue in oxenstored (the ocaml
> xenstore) just this week. Is there any chance that you are running C
> xenstored with Xen 4.1.1 and oxenstored with Xen 3.4.3?

Thanks for the pointer, I missed that thread. Now dumb question, would
oxenstored be named that way? Or iow, how do I quickly find out what is running?
The binary running in 3.4.3 is xenstored which is a linked executable (same in
4.1.1).

But I guess, whatever version is running, any oxenstored would not have the
bugfix because things take longer to reach any packaged versions. I rather would
suspect that in 4.1.1, the reset watches message probably is just known and thus
avoiding the problem. Unfortunately it is near impossible to tell for sure what
exactly EC2 is running.

The major point here probably is that when the upstream kernels are calling that
message and there are versions of xenstored in production that will just ignore
it while the kernel blocks waiting, this is a painful path. Production systems
tend to update slowly and the symptoms are not that obvious. Having a timeout
maybe could be useful not only for this case, but clearly it is nothing that
should be rushed.

So reverting the patch introducing that call (at least in the distro kernel) may
be the best thing to do (knowing that this will be bought by loosing the fix for
kexec boots fo crash kernels).

-Stefan

>> Now the big question is, should this never happen and the host needs urgent
>> updating. Or, should xs_talkv() set up a time limit and assume failure when not
>> receiving a message after that? I could imagine the latter might lead at least
>> to a more helpful "there is something wrong here, dude" than just hanging around
>> without any response. ;)
>>
>> -Stefan
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 09:19:17 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 09:19:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbTwL-00050Y-5D; Fri, 16 Dec 2011 09:18:53 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <stefan.bader@canonical.com>) id 1RbTwJ-00050H-Lr
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 09:18:51 +0000
X-Env-Sender: stefan.bader@canonical.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1324027116!7636046!1
X-Originating-IP: [91.189.89.112]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29950 invoked from network); 16 Dec 2011 09:18:43 -0000
Received: from youngberry.canonical.com (HELO youngberry.canonical.com)
	(91.189.89.112) by server-14.tower-21.messagelabs.com with SMTP;
	16 Dec 2011 09:18:43 -0000
Received: from p5b2e5f25.dip.t-dialin.net ([91.46.95.37] helo=[192.168.2.5])
	by youngberry.canonical.com with esmtpsa
	(TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71)
	(envelope-from <stefan.bader@canonical.com>)
	id 1RbTw2-0001M3-WE; Fri, 16 Dec 2011 09:18:35 +0000
Message-ID: <4EEB0CE9.4040405@canonical.com>
Date: Fri, 16 Dec 2011 10:18:33 +0100
From: Stefan Bader <stefan.bader@canonical.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:8.0) Gecko/20111124 Thunderbird/8.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <4EEA4877.8010307@canonical.com>
	<1323982417.20936.898.camel@dagon.hellion.org.uk>
In-Reply-To: <1323982417.20936.898.camel@dagon.hellion.org.uk>
X-Enigmail-Version: 1.4a1pre
Cc: Olaf Hering <olaf@aepfle.de>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] xenbus and the message of doom
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 15.12.2011 21:53, Ian Campbell wrote:
> On Thu, 2011-12-15 at 19:20 +0000, Stefan Bader wrote:
>> I was investigating a bug report[1] about newer kernels (>3.1) not booting as
>> HVM guests on Amazon EC2. For some reason git bisect did give the some pain, but
>> it lead me at least close and with some crash dump data I think I figured the
>> problem.
>>
>> commit ddacf5ef684a655abe2bb50c4b2a5b72ae0d5e05
>> Author: Olaf Hering <olaf@aepfle.de>
>> Date:   Thu Sep 22 16:14:49 2011 +0200
>>
>>     xen/pv-on-hvm kexec: add xs_reset_watches to shutdown watches from old
>>     kernel
>>
>> This change introduced a xs_reset_watches() call. The problem seems to be that
>> there is at least some version of Xen (I was able to reproduce with a 3.4.3
>> version which I admit to deliberately not having updated) for which xenstore
>> will not return any reply.
>>
>> At least the backtraces in crash showed that xs_init had been calling
>> xs_reset_watches() and that was happily idling in read_reply(). Effectively
>> nothing was going on and the boot just hung.
>> By just not doing that xs_reset_watches() call, I was able to boot under the
>> same host. And for what it is worth there has not been an issue with Xen 4.1.1
>> and a 3.0 dom0 kernel. Just this "older" release is trouble.
> 
> I sent a patch to fix exactly this issue in oxenstored (the ocaml
> xenstore) just this week. Is there any chance that you are running C
> xenstored with Xen 4.1.1 and oxenstored with Xen 3.4.3?

Thanks for the pointer, I missed that thread. Now dumb question, would
oxenstored be named that way? Or iow, how do I quickly find out what is running?
The binary running in 3.4.3 is xenstored which is a linked executable (same in
4.1.1).

But I guess, whatever version is running, any oxenstored would not have the
bugfix because things take longer to reach any packaged versions. I rather would
suspect that in 4.1.1, the reset watches message probably is just known and thus
avoiding the problem. Unfortunately it is near impossible to tell for sure what
exactly EC2 is running.

The major point here probably is that when the upstream kernels are calling that
message and there are versions of xenstored in production that will just ignore
it while the kernel blocks waiting, this is a painful path. Production systems
tend to update slowly and the symptoms are not that obvious. Having a timeout
maybe could be useful not only for this case, but clearly it is nothing that
should be rushed.

So reverting the patch introducing that call (at least in the distro kernel) may
be the best thing to do (knowing that this will be bought by loosing the fix for
kexec boots fo crash kernels).

-Stefan

>> Now the big question is, should this never happen and the host needs urgent
>> updating. Or, should xs_talkv() set up a time limit and assume failure when not
>> receiving a message after that? I could imagine the latter might lead at least
>> to a more helpful "there is something wrong here, dude" than just hanging around
>> without any response. ;)
>>
>> -Stefan
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 09:24:09 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 09:24:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbU17-0005DZ-3N; Fri, 16 Dec 2011 09:23:49 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RbU15-0005DR-5C
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 09:23:47 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1324027418!5593885!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13627 invoked from network); 16 Dec 2011 09:23:39 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-14.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 16 Dec 2011 09:23:39 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 16 Dec 2011 09:24:41 +0000
Message-Id: <4EEB1C2902000078000686EE@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 16 Dec 2011 09:23:37 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartCAE56209.0__="
Subject: [Xen-devel] [PATCH,
 v2] linux-2.6.18: consolidate and simplify struct xenbus_driver
 instantiation
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__PartCAE56209.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

The 'name' and 'owner' members are redundant with the identically named
fields in the 'driver' sub-structure. Rather than switching each
instance to specify these fields explicitly, introduce a macro to
simplify this (and at once to abstract out - for the unmodified drivers
build - the absence of the 'owner' field in Linux prior to 2.6.10).

Also add a module alias for the vtpm frontend driver (overlooked in
141:5e294e29a43e).

v2: Eliminate further redundancy by allowing the drvname argument to
DEFINE_XENBUS_DRIVER() to be blank (in which case the first entry from
the ID table will be used for .driver.name).

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/drivers/char/tpm/tpm_xen.c
+++ b/drivers/char/tpm/tpm_xen.c
@@ -475,26 +475,24 @@ static int tpmif_connect(struct xenbus_d
 	return 0;
 }
=20
-static struct xenbus_device_id tpmfront_ids[] =3D {
+static const struct xenbus_device_id tpmfront_ids[] =3D {
 	{ "vtpm" },
 	{ "" }
 };
+MODULE_ALIAS("xen:vtpm");
=20
-static struct xenbus_driver tpmfront =3D {
-	.name =3D "vtpm",
-	.owner =3D THIS_MODULE,
-	.ids =3D tpmfront_ids,
+static DEFINE_XENBUS_DRIVER(tpmfront, ,
 	.probe =3D tpmfront_probe,
 	.remove =3D  tpmfront_remove,
 	.resume =3D tpmfront_resume,
 	.otherend_changed =3D backend_changed,
 	.suspend =3D tpmfront_suspend,
 	.suspend_cancel =3D tpmfront_suspend_cancel,
-};
+);
=20
 static void __init init_tpm_xenbus(void)
 {
-	xenbus_register_frontend(&tpmfront);
+	xenbus_register_frontend(&tpmfront_driver);
 }
=20
 static int tpmif_allocate_tx_buffers(struct tpm_private *tp)
--- a/drivers/xen/blkback/xenbus.c
+++ b/drivers/xen/blkback/xenbus.c
@@ -542,18 +542,14 @@ static const struct xenbus_device_id blk
 	{ "" }
 };
=20
-
-static struct xenbus_driver blkback =3D {
-	.name =3D "vbd",
-	.owner =3D THIS_MODULE,
-	.ids =3D blkback_ids,
+static DEFINE_XENBUS_DRIVER(blkback, ,
 	.probe =3D blkback_probe,
 	.remove =3D blkback_remove,
 	.otherend_changed =3D frontend_changed
-};
+);
=20
=20
 void blkif_xenbus_init(void)
 {
-	xenbus_register_backend(&blkback);
+	xenbus_register_backend(&blkback_driver);
 }
--- a/drivers/xen/blkfront/blkfront.c
+++ b/drivers/xen/blkfront/blkfront.c
@@ -934,16 +934,13 @@ static const struct xenbus_device_id blk
 };
 MODULE_ALIAS("xen:vbd");
=20
-static struct xenbus_driver blkfront =3D {
-	.name =3D "vbd",
-	.owner =3D THIS_MODULE,
-	.ids =3D blkfront_ids,
+static DEFINE_XENBUS_DRIVER(blkfront, ,
 	.probe =3D blkfront_probe,
 	.remove =3D blkfront_remove,
 	.resume =3D blkfront_resume,
 	.otherend_changed =3D backend_changed,
 	.is_ready =3D blkfront_is_ready,
-};
+);
=20
=20
 static int __init xlblk_init(void)
@@ -951,14 +948,14 @@ static int __init xlblk_init(void)
 	if (!is_running_on_xen())
 		return -ENODEV;
=20
-	return xenbus_register_frontend(&blkfront);
+	return xenbus_register_frontend(&blkfront_driver);
 }
 module_init(xlblk_init);
=20
=20
 static void __exit xlblk_exit(void)
 {
-	return xenbus_unregister_driver(&blkfront);
+	return xenbus_unregister_driver(&blkfront_driver);
 }
 module_exit(xlblk_exit);
=20
--- a/drivers/xen/blktap/xenbus.c
+++ b/drivers/xen/blktap/xenbus.c
@@ -490,18 +490,14 @@ static const struct xenbus_device_id blk
 	{ "" }
 };
=20
-
-static struct xenbus_driver blktap =3D {
-	.name =3D "tap",
-	.owner =3D THIS_MODULE,
-	.ids =3D blktap_ids,
+static DEFINE_XENBUS_DRIVER(blktap, ,
 	.probe =3D blktap_probe,
 	.remove =3D blktap_remove,
 	.otherend_changed =3D tap_frontend_changed
-};
+);
=20
=20
 void tap_blkif_xenbus_init(void)
 {
-	xenbus_register_backend(&blktap);
+	xenbus_register_backend(&blktap_driver);
 }
--- a/drivers/xen/fbfront/xenfb.c
+++ b/drivers/xen/fbfront/xenfb.c
@@ -857,15 +857,12 @@ static const struct xenbus_device_id xen
 };
 MODULE_ALIAS("xen:vfb");
=20
-static struct xenbus_driver xenfb_driver =3D {
-	.name =3D "vfb",
-	.owner =3D THIS_MODULE,
-	.ids =3D xenfb_ids,
+static DEFINE_XENBUS_DRIVER(xenfb, ,
 	.probe =3D xenfb_probe,
 	.remove =3D xenfb_remove,
 	.resume =3D xenfb_resume,
 	.otherend_changed =3D xenfb_backend_changed,
-};
+);
=20
 static int __init xenfb_init(void)
 {
--- a/drivers/xen/fbfront/xenkbd.c
+++ b/drivers/xen/fbfront/xenkbd.c
@@ -335,15 +335,12 @@ static const struct xenbus_device_id xen
 };
 MODULE_ALIAS("xen:vkbd");
=20
-static struct xenbus_driver xenkbd_driver =3D {
-	.name =3D "vkbd",
-	.owner =3D THIS_MODULE,
-	.ids =3D xenkbd_ids,
+static DEFINE_XENBUS_DRIVER(xenkbd, ,
 	.probe =3D xenkbd_probe,
 	.remove =3D xenkbd_remove,
 	.resume =3D xenkbd_resume,
 	.otherend_changed =3D xenkbd_backend_changed,
-};
+);
=20
 static int __init xenkbd_init(void)
 {
--- a/drivers/xen/netback/xenbus.c
+++ b/drivers/xen/netback/xenbus.c
@@ -437,19 +437,15 @@ static const struct xenbus_device_id net
 	{ "" }
 };
=20
-
-static struct xenbus_driver netback =3D {
-	.name =3D "vif",
-	.owner =3D THIS_MODULE,
-	.ids =3D netback_ids,
+static DEFINE_XENBUS_DRIVER(netback, ,
 	.probe =3D netback_probe,
 	.remove =3D netback_remove,
 	.uevent =3D netback_uevent,
 	.otherend_changed =3D frontend_changed,
-};
+);
=20
=20
 void netif_xenbus_init(void)
 {
-	xenbus_register_backend(&netback);
+	xenbus_register_backend(&netback_driver);
 }
--- a/drivers/xen/netfront/netfront.c
+++ b/drivers/xen/netfront/netfront.c
@@ -2197,18 +2197,14 @@ static const struct xenbus_device_id net
 };
 MODULE_ALIAS("xen:vif");
=20
-
-static struct xenbus_driver netfront_driver =3D {
-	.name =3D "vif",
-	.owner =3D THIS_MODULE,
-	.ids =3D netfront_ids,
+static DEFINE_XENBUS_DRIVER(netfront, ,
 	.probe =3D netfront_probe,
 	.remove =3D __devexit_p(netfront_remove),
 	.suspend =3D netfront_suspend,
 	.suspend_cancel =3D netfront_suspend_cancel,
 	.resume =3D netfront_resume,
 	.otherend_changed =3D backend_changed,
-};
+);
=20
=20
 static int __init netif_init(void)
--- a/drivers/xen/pciback/xenbus.c
+++ b/drivers/xen/pciback/xenbus.c
@@ -676,19 +676,16 @@ static int pciback_xenbus_remove(struct=20
 	return 0;
 }
=20
-static const struct xenbus_device_id xenpci_ids[] =3D {
+static const struct xenbus_device_id pciback_ids[] =3D {
 	{"pci"},
 	{{0}},
 };
=20
-static struct xenbus_driver xenbus_pciback_driver =3D {
-	.name 			=3D "pciback",
-	.owner 			=3D THIS_MODULE,
-	.ids 			=3D xenpci_ids,
+static DEFINE_XENBUS_DRIVER(pciback, "pciback",
 	.probe 			=3D pciback_xenbus_probe,
 	.remove 		=3D pciback_xenbus_remove,
 	.otherend_changed 	=3D pciback_frontend_changed,
-};
+);
=20
 int __init pciback_xenbus_register(void)
 {
@@ -700,11 +697,11 @@ int __init pciback_xenbus_register(void)
 			"pciback_workqueue failed\n");
 		return -EFAULT;
 	}
-	return xenbus_register_backend(&xenbus_pciback_driver);
+	return xenbus_register_backend(&pciback_driver);
 }
=20
 void __exit pciback_xenbus_unregister(void)
 {
 	destroy_workqueue(pciback_wq);
-	xenbus_unregister_driver(&xenbus_pciback_driver);
+	xenbus_unregister_driver(&pciback_driver);
 }
--- a/drivers/xen/pcifront/xenbus.c
+++ b/drivers/xen/pcifront/xenbus.c
@@ -456,27 +456,24 @@ static int pcifront_xenbus_remove(struct
 	return 0;
 }
=20
-static const struct xenbus_device_id xenpci_ids[] =3D {
+static const struct xenbus_device_id pcifront_ids[] =3D {
 	{"pci"},
 	{{0}},
 };
 MODULE_ALIAS("xen:pci");
=20
-static struct xenbus_driver xenbus_pcifront_driver =3D {
-	.name 			=3D "pcifront",
-	.owner 			=3D THIS_MODULE,
-	.ids 			=3D xenpci_ids,
+static DEFINE_XENBUS_DRIVER(pcifront, "pcifront",
 	.probe 			=3D pcifront_xenbus_probe,
 	.remove 		=3D pcifront_xenbus_remove,
 	.otherend_changed 	=3D pcifront_backend_changed,
-};
+);
=20
 static int __init pcifront_init(void)
 {
 	if (!is_running_on_xen())
 		return -ENODEV;
=20
-	return xenbus_register_frontend(&xenbus_pcifront_driver);
+	return xenbus_register_frontend(&pcifront_driver);
 }
=20
 /* Initialize after the Xen PCI Frontend Stub is initialized */
--- a/drivers/xen/scsiback/xenbus.c
+++ b/drivers/xen/scsiback/xenbus.c
@@ -352,26 +352,23 @@ fail:
 }
=20
=20
-static struct xenbus_device_id scsiback_ids[] =3D {
+static const struct xenbus_device_id scsiback_ids[] =3D {
 	{ "vscsi" },
 	{ "" }
 };
=20
-static struct xenbus_driver scsiback =3D {
-	.name			=3D "vscsi",
-	.owner			=3D THIS_MODULE,
-	.ids			=3D scsiback_ids,
+static DEFINE_XENBUS_DRIVER(scsiback, ,
 	.probe			=3D scsiback_probe,
 	.remove			=3D scsiback_remove,
 	.otherend_changed	=3D scsiback_frontend_changed
-};
+);
=20
 int scsiback_xenbus_init(void)
 {
-	return xenbus_register_backend(&scsiback);
+	return xenbus_register_backend(&scsiback_driver);
 }
=20
 void scsiback_xenbus_unregister(void)
 {
-	xenbus_unregister_driver(&scsiback);
+	xenbus_unregister_driver(&scsiback_driver);
 }
--- a/drivers/xen/scsifront/xenbus.c
+++ b/drivers/xen/scsifront/xenbus.c
@@ -398,21 +398,18 @@ static void scsifront_backend_changed(st
 }
=20
=20
-static struct xenbus_device_id scsifront_ids[] =3D {
+static const struct xenbus_device_id scsifront_ids[] =3D {
 	{ "vscsi" },
 	{ "" }
 };
 MODULE_ALIAS("xen:vscsi");
=20
-static struct xenbus_driver scsifront_driver =3D {
-	.name			=3D "vscsi",
-	.owner			=3D THIS_MODULE,
-	.ids			=3D scsifront_ids,
+static DEFINE_XENBUS_DRIVER(scsifront, ,
 	.probe			=3D scsifront_probe,
 	.remove			=3D scsifront_remove,
 /* 	.resume			=3D scsifront_resume, */
 	.otherend_changed	=3D scsifront_backend_changed,
-};
+);
=20
 int scsifront_xenbus_init(void)
 {
--- a/drivers/xen/tpmback/xenbus.c
+++ b/drivers/xen/tpmback/xenbus.c
@@ -251,23 +251,19 @@ static const struct xenbus_device_id tpm
 	{ "" }
 };
=20
-
-static struct xenbus_driver tpmback =3D {
-	.name =3D "vtpm",
-	.owner =3D THIS_MODULE,
-	.ids =3D tpmback_ids,
+static DEFINE_XENBUS_DRIVER(tpmback, ,
 	.probe =3D tpmback_probe,
 	.remove =3D tpmback_remove,
 	.otherend_changed =3D frontend_changed,
-};
+);
=20
=20
 void tpmif_xenbus_init(void)
 {
-	xenbus_register_backend(&tpmback);
+	xenbus_register_backend(&tpmback_driver);
 }
=20
 void tpmif_xenbus_exit(void)
 {
-	xenbus_unregister_driver(&tpmback);
+	xenbus_unregister_driver(&tpmback_driver);
 }
--- a/drivers/xen/usbback/xenbus.c
+++ b/drivers/xen/usbback/xenbus.c
@@ -317,14 +317,11 @@ static const struct xenbus_device_id usb
 	{ "" },
 };
=20
-static struct xenbus_driver usbback_driver =3D {
-	.name =3D "vusb",
-	.owner =3D THIS_MODULE,
-	.ids =3D usbback_ids,
+static DEFINE_XENBUS_DRIVER(usbback, ,
 	.probe =3D usbback_probe,
 	.otherend_changed =3D frontend_changed,
 	.remove =3D usbback_remove,
-};
+);
=20
 int __init usbback_xenbus_init(void)
 {
--- a/drivers/xen/usbfront/xenbus.c
+++ b/drivers/xen/usbfront/xenbus.c
@@ -379,14 +379,11 @@ static const struct xenbus_device_id usb
 };
 MODULE_ALIAS("xen:vusb");
=20
-static struct xenbus_driver usbfront_driver =3D {
-	.name =3D "vusb",
-	.owner =3D THIS_MODULE,
-	.ids =3D usbfront_ids,
+static DEFINE_XENBUS_DRIVER(usbfront, ,
 	.probe =3D usbfront_probe,
 	.otherend_changed =3D backend_changed,
 	.remove =3D usbfront_remove,
-};
+);
=20
 static int __init usbfront_init(void)
 {
--- a/drivers/xen/xenbus/xenbus_probe.c
+++ b/drivers/xen/xenbus/xenbus_probe.c
@@ -382,11 +382,7 @@ int xenbus_register_driver_common(struct
 	if (bus->error)
 		return bus->error;
=20
-	drv->driver.name =3D drv->name;
 	drv->driver.bus =3D &bus->bus;
-#if LINUX_VERSION_CODE >=3D KERNEL_VERSION(2,6,10)
-	drv->driver.owner =3D drv->owner;
-#endif
 #if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,16)
 	drv->driver.probe =3D xenbus_dev_probe;
 	drv->driver.remove =3D xenbus_dev_remove;
--- a/include/xen/xenbus.h
+++ b/include/xen/xenbus.h
@@ -40,6 +40,7 @@
 #include <linux/completion.h>
 #include <linux/init.h>
 #include <linux/err.h>
+#include <linux/version.h>
 #include <xen/interface/xen.h>
 #include <xen/interface/grant_table.h>
 #include <xen/interface/io/xenbus.h>
@@ -93,8 +94,6 @@ struct xenbus_device_id
=20
 /* A xenbus driver. */
 struct xenbus_driver {
-	char *name;
-	struct module *owner;
 	const struct xenbus_device_id *ids;
 	int (*probe)(struct xenbus_device *dev,
 		     const struct xenbus_device_id *id);
@@ -110,6 +109,19 @@ struct xenbus_driver {
 	int (*is_ready)(struct xenbus_device *dev);
 };
=20
+#if LINUX_VERSION_CODE >=3D KERNEL_VERSION(2,6,10)
+# define XENBUS_DRIVER_SET_OWNER(mod) .driver.owner =3D mod,
+#else
+# define XENBUS_DRIVER_SET_OWNER(mod)
+#endif
+
+#define DEFINE_XENBUS_DRIVER(var, drvname, methods...)		\
+struct xenbus_driver var ## _driver =3D {				\
+	.driver.name =3D drvname + 0 ?: var ## _ids->devicetype,	\
+	XENBUS_DRIVER_SET_OWNER(THIS_MODULE)			\
+	.ids =3D var ## _ids, ## methods				\
+}
+
 static inline struct xenbus_driver *to_xenbus_driver(struct device_driver =
*drv)
 {
 	return container_of(drv, struct xenbus_driver, driver);



--=__PartCAE56209.0__=
Content-Type: text/plain; name="xen-xenbus-driver-cleanup.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="xen-xenbus-driver-cleanup.patch"

consolidate and simplify struct xenbus_driver instantiation=0A=0AThe =
'name' and 'owner' members are redundant with the identically named=0Afield=
s in the 'driver' sub-structure. Rather than switching each=0Ainstance to =
specify these fields explicitly, introduce a macro to=0Asimplify this (and =
at once to abstract out - for the unmodified drivers=0Abuild - the absence =
of the 'owner' field in Linux prior to 2.6.10).=0A=0AAlso add a module =
alias for the vtpm frontend driver (overlooked in=0A141:5e294e29a43e).=0A=
=0Av2: Eliminate further redundancy by allowing the drvname argument =
to=0ADEFINE_XENBUS_DRIVER() to be blank (in which case the first entry =
from=0Athe ID table will be used for .driver.name).=0A=0ASigned-off-by: =
Jan Beulich <jbeulich@suse.com>=0A=0A--- a/drivers/char/tpm/tpm_xen.c=0A+++=
 b/drivers/char/tpm/tpm_xen.c=0A@@ -475,26 +475,24 @@ static int tpmif_conn=
ect(struct xenbus_d=0A 	return 0;=0A }=0A =0A-static struct xenbus_device_i=
d tpmfront_ids[] =3D {=0A+static const struct xenbus_device_id tpmfront_ids=
[] =3D {=0A 	{ "vtpm" },=0A 	{ "" }=0A };=0A+MODULE_ALIAS("xen:vtpm");=
=0A =0A-static struct xenbus_driver tpmfront =3D {=0A-	.name =3D =
"vtpm",=0A-	.owner =3D THIS_MODULE,=0A-	.ids =3D tpmfront_ids,=0A+s=
tatic DEFINE_XENBUS_DRIVER(tpmfront, ,=0A 	.probe =3D tpmfront_probe,=
=0A 	.remove =3D  tpmfront_remove,=0A 	.resume =3D tpmfront_resume=
,=0A 	.otherend_changed =3D backend_changed,=0A 	.suspend =3D =
tpmfront_suspend,=0A 	.suspend_cancel =3D tpmfront_suspend_cancel,=0A-};=
=0A+);=0A =0A static void __init init_tpm_xenbus(void)=0A {=0A-	xenbus_regi=
ster_frontend(&tpmfront);=0A+	xenbus_register_frontend(&tpmfront_driver);=
=0A }=0A =0A static int tpmif_allocate_tx_buffers(struct tpm_private =
*tp)=0A--- a/drivers/xen/blkback/xenbus.c=0A+++ b/drivers/xen/blkback/xenbu=
s.c=0A@@ -542,18 +542,14 @@ static const struct xenbus_device_id blk=0A 	=
{ "" }=0A };=0A =0A-=0A-static struct xenbus_driver blkback =3D {=0A-	=
.name =3D "vbd",=0A-	.owner =3D THIS_MODULE,=0A-	.ids =3D blkback_id=
s,=0A+static DEFINE_XENBUS_DRIVER(blkback, ,=0A 	.probe =3D =
blkback_probe,=0A 	.remove =3D blkback_remove,=0A 	.otherend_changed =
=3D frontend_changed=0A-};=0A+);=0A =0A =0A void blkif_xenbus_init(void)=0A=
 {=0A-	xenbus_register_backend(&blkback);=0A+	xenbus_register_backend(&bl=
kback_driver);=0A }=0A--- a/drivers/xen/blkfront/blkfront.c=0A+++ =
b/drivers/xen/blkfront/blkfront.c=0A@@ -934,16 +934,13 @@ static const =
struct xenbus_device_id blk=0A };=0A MODULE_ALIAS("xen:vbd");=0A =0A-static=
 struct xenbus_driver blkfront =3D {=0A-	.name =3D "vbd",=0A-	=
.owner =3D THIS_MODULE,=0A-	.ids =3D blkfront_ids,=0A+static DEFINE_XEN=
BUS_DRIVER(blkfront, ,=0A 	.probe =3D blkfront_probe,=0A 	.remove =
=3D blkfront_remove,=0A 	.resume =3D blkfront_resume,=0A 	=
.otherend_changed =3D backend_changed,=0A 	.is_ready =3D blkfront_is_r=
eady,=0A-};=0A+);=0A =0A =0A static int __init xlblk_init(void)=0A@@ =
-951,14 +948,14 @@ static int __init xlblk_init(void)=0A 	if =
(!is_running_on_xen())=0A 		return -ENODEV;=0A =0A-	return =
xenbus_register_frontend(&blkfront);=0A+	return xenbus_register_fron=
tend(&blkfront_driver);=0A }=0A module_init(xlblk_init);=0A =0A =0A static =
void __exit xlblk_exit(void)=0A {=0A-	return xenbus_unregister_driver(&bl=
kfront);=0A+	return xenbus_unregister_driver(&blkfront_driver);=0A }=0A =
module_exit(xlblk_exit);=0A =0A--- a/drivers/xen/blktap/xenbus.c=0A+++ =
b/drivers/xen/blktap/xenbus.c=0A@@ -490,18 +490,14 @@ static const struct =
xenbus_device_id blk=0A 	{ "" }=0A };=0A =0A-=0A-static struct =
xenbus_driver blktap =3D {=0A-	.name =3D "tap",=0A-	.owner =3D =
THIS_MODULE,=0A-	.ids =3D blktap_ids,=0A+static DEFINE_XENBUS_DRIVER=
(blktap, ,=0A 	.probe =3D blktap_probe,=0A 	.remove =3D blktap_remove,=
=0A 	.otherend_changed =3D tap_frontend_changed=0A-};=0A+);=0A =0A =0A =
void tap_blkif_xenbus_init(void)=0A {=0A-	xenbus_register_backend(&bl=
ktap);=0A+	xenbus_register_backend(&blktap_driver);=0A }=0A--- =
a/drivers/xen/fbfront/xenfb.c=0A+++ b/drivers/xen/fbfront/xenfb.c=0A@@ =
-857,15 +857,12 @@ static const struct xenbus_device_id xen=0A };=0A =
MODULE_ALIAS("xen:vfb");=0A =0A-static struct xenbus_driver xenfb_driver =
=3D {=0A-	.name =3D "vfb",=0A-	.owner =3D THIS_MODULE,=0A-	=
.ids =3D xenfb_ids,=0A+static DEFINE_XENBUS_DRIVER(xenfb, ,=0A 	.probe =3D =
xenfb_probe,=0A 	.remove =3D xenfb_remove,=0A 	.resume =3D =
xenfb_resume,=0A 	.otherend_changed =3D xenfb_backend_changed,=0A-};=
=0A+);=0A =0A static int __init xenfb_init(void)=0A {=0A--- a/drivers/xen/f=
bfront/xenkbd.c=0A+++ b/drivers/xen/fbfront/xenkbd.c=0A@@ -335,15 +335,12 =
@@ static const struct xenbus_device_id xen=0A };=0A MODULE_ALIAS("xen:vkbd=
");=0A =0A-static struct xenbus_driver xenkbd_driver =3D {=0A-	.name =3D =
"vkbd",=0A-	.owner =3D THIS_MODULE,=0A-	.ids =3D xenkbd_ids,=0A+sta=
tic DEFINE_XENBUS_DRIVER(xenkbd, ,=0A 	.probe =3D xenkbd_probe,=0A 	=
.remove =3D xenkbd_remove,=0A 	.resume =3D xenkbd_resume,=0A 	.otherend_c=
hanged =3D xenkbd_backend_changed,=0A-};=0A+);=0A =0A static int __init =
xenkbd_init(void)=0A {=0A--- a/drivers/xen/netback/xenbus.c=0A+++ =
b/drivers/xen/netback/xenbus.c=0A@@ -437,19 +437,15 @@ static const struct =
xenbus_device_id net=0A 	{ "" }=0A };=0A =0A-=0A-static struct =
xenbus_driver netback =3D {=0A-	.name =3D "vif",=0A-	.owner =3D =
THIS_MODULE,=0A-	.ids =3D netback_ids,=0A+static DEFINE_XENBUS_DRIVE=
R(netback, ,=0A 	.probe =3D netback_probe,=0A 	.remove =3D =
netback_remove,=0A 	.uevent =3D netback_uevent,=0A 	.otherend_changed =
=3D frontend_changed,=0A-};=0A+);=0A =0A =0A void netif_xenbus_init(void)=
=0A {=0A-	xenbus_register_backend(&netback);=0A+	xenbus_register_bac=
kend(&netback_driver);=0A }=0A--- a/drivers/xen/netfront/netfront.c=0A+++ =
b/drivers/xen/netfront/netfront.c=0A@@ -2197,18 +2197,14 @@ static const =
struct xenbus_device_id net=0A };=0A MODULE_ALIAS("xen:vif");=0A =0A-=0A-st=
atic struct xenbus_driver netfront_driver =3D {=0A-	.name =3D =
"vif",=0A-	.owner =3D THIS_MODULE,=0A-	.ids =3D netfront_ids,=0A+s=
tatic DEFINE_XENBUS_DRIVER(netfront, ,=0A 	.probe =3D netfront_probe,=
=0A 	.remove =3D __devexit_p(netfront_remove),=0A 	.suspend =3D =
netfront_suspend,=0A 	.suspend_cancel =3D netfront_suspend_cancel,=0A 	=
.resume =3D netfront_resume,=0A 	.otherend_changed =3D backend_chang=
ed,=0A-};=0A+);=0A =0A =0A static int __init netif_init(void)=0A--- =
a/drivers/xen/pciback/xenbus.c=0A+++ b/drivers/xen/pciback/xenbus.c=0A@@ =
-676,19 +676,16 @@ static int pciback_xenbus_remove(struct =0A 	return =
0;=0A }=0A =0A-static const struct xenbus_device_id xenpci_ids[] =3D =
{=0A+static const struct xenbus_device_id pciback_ids[] =3D {=0A 	=
{"pci"},=0A 	{{0}},=0A };=0A =0A-static struct xenbus_driver xenbus_pcib=
ack_driver =3D {=0A-	.name 			=3D "pciback",=0A-	=
.owner 			=3D THIS_MODULE,=0A-	.ids 			=
=3D xenpci_ids,=0A+static DEFINE_XENBUS_DRIVER(pciback, "pciback",=0A 	=
.probe 			=3D pciback_xenbus_probe,=0A 	.remove 		=
=3D pciback_xenbus_remove,=0A 	.otherend_changed 	=3D pciback_fronten=
d_changed,=0A-};=0A+);=0A =0A int __init pciback_xenbus_register(void)=0A =
{=0A@@ -700,11 +697,11 @@ int __init pciback_xenbus_register(void)=0A 		=
	"pciback_workqueue failed\n");=0A 		return -EFAULT;=0A =
	}=0A-	return xenbus_register_backend(&xenbus_pciback_driver);=0A+=
	return xenbus_register_backend(&pciback_driver);=0A }=0A =0A void =
__exit pciback_xenbus_unregister(void)=0A {=0A 	destroy_workqueue(pciback_w=
q);=0A-	xenbus_unregister_driver(&xenbus_pciback_driver);=0A+	xenbus_unre=
gister_driver(&pciback_driver);=0A }=0A--- a/drivers/xen/pcifront/xenbus.c=
=0A+++ b/drivers/xen/pcifront/xenbus.c=0A@@ -456,27 +456,24 @@ static int =
pcifront_xenbus_remove(struct=0A 	return 0;=0A }=0A =0A-static const =
struct xenbus_device_id xenpci_ids[] =3D {=0A+static const struct =
xenbus_device_id pcifront_ids[] =3D {=0A 	{"pci"},=0A 	{{0}},=0A =
};=0A MODULE_ALIAS("xen:pci");=0A =0A-static struct xenbus_driver =
xenbus_pcifront_driver =3D {=0A-	.name 			=3D =
"pcifront",=0A-	.owner 			=3D THIS_MODULE,=0A-	.ids 		=
	=3D xenpci_ids,=0A+static DEFINE_XENBUS_DRIVER(pcifront, "pcifront"=
,=0A 	.probe 			=3D pcifront_xenbus_probe,=0A 	.remove 	=
	=3D pcifront_xenbus_remove,=0A 	.otherend_changed 	=3D =
pcifront_backend_changed,=0A-};=0A+);=0A =0A static int __init pcifront_ini=
t(void)=0A {=0A 	if (!is_running_on_xen())=0A 		return =
-ENODEV;=0A =0A-	return xenbus_register_frontend(&xenbus_pcifront_dr=
iver);=0A+	return xenbus_register_frontend(&pcifront_driver);=0A }=0A =
=0A /* Initialize after the Xen PCI Frontend Stub is initialized */=0A--- =
a/drivers/xen/scsiback/xenbus.c=0A+++ b/drivers/xen/scsiback/xenbus.c=0A@@ =
-352,26 +352,23 @@ fail:=0A }=0A =0A =0A-static struct xenbus_device_id =
scsiback_ids[] =3D {=0A+static const struct xenbus_device_id scsiback_ids[]=
 =3D {=0A 	{ "vscsi" },=0A 	{ "" }=0A };=0A =0A-static struct =
xenbus_driver scsiback =3D {=0A-	.name			=3D =
"vscsi",=0A-	.owner			=3D THIS_MODULE,=0A-	.ids		=
	=3D scsiback_ids,=0A+static DEFINE_XENBUS_DRIVER(scsiback, ,=0A 	=
.probe			=3D scsiback_probe,=0A 	.remove			=
=3D scsiback_remove,=0A 	.otherend_changed	=3D scsiback_fronte=
nd_changed=0A-};=0A+);=0A =0A int scsiback_xenbus_init(void)=0A {=0A-	=
return xenbus_register_backend(&scsiback);=0A+	return xenbus_register_back=
end(&scsiback_driver);=0A }=0A =0A void scsiback_xenbus_unregister(void)=0A=
 {=0A-	xenbus_unregister_driver(&scsiback);=0A+	xenbus_unregister_d=
river(&scsiback_driver);=0A }=0A--- a/drivers/xen/scsifront/xenbus.c=0A+++ =
b/drivers/xen/scsifront/xenbus.c=0A@@ -398,21 +398,18 @@ static void =
scsifront_backend_changed(st=0A }=0A =0A =0A-static struct xenbus_device_id=
 scsifront_ids[] =3D {=0A+static const struct xenbus_device_id scsifront_id=
s[] =3D {=0A 	{ "vscsi" },=0A 	{ "" }=0A };=0A MODULE_ALIAS("xen:v=
scsi");=0A =0A-static struct xenbus_driver scsifront_driver =3D {=0A-	=
.name			=3D "vscsi",=0A-	.owner			=
=3D THIS_MODULE,=0A-	.ids			=3D scsifront_ids,=0A+stati=
c DEFINE_XENBUS_DRIVER(scsifront, ,=0A 	.probe			=3D =
scsifront_probe,=0A 	.remove			=3D scsifront_remove,=0A =
/* 	.resume			=3D scsifront_resume, */=0A 	.otherend_c=
hanged	=3D scsifront_backend_changed,=0A-};=0A+);=0A =0A int scsifront_xen=
bus_init(void)=0A {=0A--- a/drivers/xen/tpmback/xenbus.c=0A+++ b/drivers/xe=
n/tpmback/xenbus.c=0A@@ -251,23 +251,19 @@ static const struct xenbus_devic=
e_id tpm=0A 	{ "" }=0A };=0A =0A-=0A-static struct xenbus_driver =
tpmback =3D {=0A-	.name =3D "vtpm",=0A-	.owner =3D THIS_MODULE,=0A-=
	.ids =3D tpmback_ids,=0A+static DEFINE_XENBUS_DRIVER(tpmback, ,=0A =
	.probe =3D tpmback_probe,=0A 	.remove =3D tpmback_remove,=0A 	=
.otherend_changed =3D frontend_changed,=0A-};=0A+);=0A =0A =0A void =
tpmif_xenbus_init(void)=0A {=0A-	xenbus_register_backend(&tpmback);=
=0A+	xenbus_register_backend(&tpmback_driver);=0A }=0A =0A void =
tpmif_xenbus_exit(void)=0A {=0A-	xenbus_unregister_driver(&tpmback);=
=0A+	xenbus_unregister_driver(&tpmback_driver);=0A }=0A--- a/drivers/xen=
/usbback/xenbus.c=0A+++ b/drivers/xen/usbback/xenbus.c=0A@@ -317,14 =
+317,11 @@ static const struct xenbus_device_id usb=0A 	{ "" },=0A };=0A =
=0A-static struct xenbus_driver usbback_driver =3D {=0A-	.name =3D =
"vusb",=0A-	.owner =3D THIS_MODULE,=0A-	.ids =3D usbback_ids,=0A+st=
atic DEFINE_XENBUS_DRIVER(usbback, ,=0A 	.probe =3D usbback_probe,=
=0A 	.otherend_changed =3D frontend_changed,=0A 	.remove =3D =
usbback_remove,=0A-};=0A+);=0A =0A int __init usbback_xenbus_init(void)=0A =
{=0A--- a/drivers/xen/usbfront/xenbus.c=0A+++ b/drivers/xen/usbfront/xenbus=
.c=0A@@ -379,14 +379,11 @@ static const struct xenbus_device_id usb=0A =
};=0A MODULE_ALIAS("xen:vusb");=0A =0A-static struct xenbus_driver =
usbfront_driver =3D {=0A-	.name =3D "vusb",=0A-	.owner =3D =
THIS_MODULE,=0A-	.ids =3D usbfront_ids,=0A+static DEFINE_XENBUS_DRIV=
ER(usbfront, ,=0A 	.probe =3D usbfront_probe,=0A 	.otherend_changed =
=3D backend_changed,=0A 	.remove =3D usbfront_remove,=0A-};=0A+);=0A=
 =0A static int __init usbfront_init(void)=0A {=0A--- a/drivers/xen/xenbus/=
xenbus_probe.c=0A+++ b/drivers/xen/xenbus/xenbus_probe.c=0A@@ -382,11 =
+382,7 @@ int xenbus_register_driver_common(struct=0A 	if (bus->error)=0A =
		return bus->error;=0A =0A-	drv->driver.name =3D =
drv->name;=0A 	drv->driver.bus =3D &bus->bus;=0A-#if LINUX_VERSION_CODE =
>=3D KERNEL_VERSION(2,6,10)=0A-	drv->driver.owner =3D drv->owner;=0A-#endif=
=0A #if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,16)=0A 	drv->driver.probe =
=3D xenbus_dev_probe;=0A 	drv->driver.remove =3D xenbus_dev_remove;=
=0A--- a/include/xen/xenbus.h=0A+++ b/include/xen/xenbus.h=0A@@ -40,6 =
+40,7 @@=0A #include <linux/completion.h>=0A #include <linux/init.h>=0A =
#include <linux/err.h>=0A+#include <linux/version.h>=0A #include <xen/inter=
face/xen.h>=0A #include <xen/interface/grant_table.h>=0A #include =
<xen/interface/io/xenbus.h>=0A@@ -93,8 +94,6 @@ struct xenbus_device_id=0A =
=0A /* A xenbus driver. */=0A struct xenbus_driver {=0A-	char =
*name;=0A-	struct module *owner;=0A 	const struct xenbus_device_=
id *ids;=0A 	int (*probe)(struct xenbus_device *dev,=0A 		   =
  const struct xenbus_device_id *id);=0A@@ -110,6 +109,19 @@ struct =
xenbus_driver {=0A 	int (*is_ready)(struct xenbus_device *dev);=0A =
};=0A =0A+#if LINUX_VERSION_CODE >=3D KERNEL_VERSION(2,6,10)=0A+# define =
XENBUS_DRIVER_SET_OWNER(mod) .driver.owner =3D mod,=0A+#else=0A+# define =
XENBUS_DRIVER_SET_OWNER(mod)=0A+#endif=0A+=0A+#define DEFINE_XENBUS_DRIVER(=
var, drvname, methods...)		\=0A+struct xenbus_driver var ## =
_driver =3D {				\=0A+	.driver.name =3D drvname + =
0 ?: var ## _ids->devicetype,	\=0A+	XENBUS_DRIVER_SET_OWNER(THIS_MODULE=
)			\=0A+	.ids =3D var ## _ids, ## methods		=
		\=0A+}=0A+=0A static inline struct xenbus_driver *to_xenbus=
_driver(struct device_driver *drv)=0A {=0A 	return container_of(drv, =
struct xenbus_driver, driver);=0A
--=__PartCAE56209.0__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--=__PartCAE56209.0__=--


From xen-devel-bounces@lists.xensource.com Fri Dec 16 09:24:09 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 09:24:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbU17-0005DZ-3N; Fri, 16 Dec 2011 09:23:49 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RbU15-0005DR-5C
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 09:23:47 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1324027418!5593885!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13627 invoked from network); 16 Dec 2011 09:23:39 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-14.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 16 Dec 2011 09:23:39 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 16 Dec 2011 09:24:41 +0000
Message-Id: <4EEB1C2902000078000686EE@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 16 Dec 2011 09:23:37 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartCAE56209.0__="
Subject: [Xen-devel] [PATCH,
 v2] linux-2.6.18: consolidate and simplify struct xenbus_driver
 instantiation
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__PartCAE56209.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

The 'name' and 'owner' members are redundant with the identically named
fields in the 'driver' sub-structure. Rather than switching each
instance to specify these fields explicitly, introduce a macro to
simplify this (and at once to abstract out - for the unmodified drivers
build - the absence of the 'owner' field in Linux prior to 2.6.10).

Also add a module alias for the vtpm frontend driver (overlooked in
141:5e294e29a43e).

v2: Eliminate further redundancy by allowing the drvname argument to
DEFINE_XENBUS_DRIVER() to be blank (in which case the first entry from
the ID table will be used for .driver.name).

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/drivers/char/tpm/tpm_xen.c
+++ b/drivers/char/tpm/tpm_xen.c
@@ -475,26 +475,24 @@ static int tpmif_connect(struct xenbus_d
 	return 0;
 }
=20
-static struct xenbus_device_id tpmfront_ids[] =3D {
+static const struct xenbus_device_id tpmfront_ids[] =3D {
 	{ "vtpm" },
 	{ "" }
 };
+MODULE_ALIAS("xen:vtpm");
=20
-static struct xenbus_driver tpmfront =3D {
-	.name =3D "vtpm",
-	.owner =3D THIS_MODULE,
-	.ids =3D tpmfront_ids,
+static DEFINE_XENBUS_DRIVER(tpmfront, ,
 	.probe =3D tpmfront_probe,
 	.remove =3D  tpmfront_remove,
 	.resume =3D tpmfront_resume,
 	.otherend_changed =3D backend_changed,
 	.suspend =3D tpmfront_suspend,
 	.suspend_cancel =3D tpmfront_suspend_cancel,
-};
+);
=20
 static void __init init_tpm_xenbus(void)
 {
-	xenbus_register_frontend(&tpmfront);
+	xenbus_register_frontend(&tpmfront_driver);
 }
=20
 static int tpmif_allocate_tx_buffers(struct tpm_private *tp)
--- a/drivers/xen/blkback/xenbus.c
+++ b/drivers/xen/blkback/xenbus.c
@@ -542,18 +542,14 @@ static const struct xenbus_device_id blk
 	{ "" }
 };
=20
-
-static struct xenbus_driver blkback =3D {
-	.name =3D "vbd",
-	.owner =3D THIS_MODULE,
-	.ids =3D blkback_ids,
+static DEFINE_XENBUS_DRIVER(blkback, ,
 	.probe =3D blkback_probe,
 	.remove =3D blkback_remove,
 	.otherend_changed =3D frontend_changed
-};
+);
=20
=20
 void blkif_xenbus_init(void)
 {
-	xenbus_register_backend(&blkback);
+	xenbus_register_backend(&blkback_driver);
 }
--- a/drivers/xen/blkfront/blkfront.c
+++ b/drivers/xen/blkfront/blkfront.c
@@ -934,16 +934,13 @@ static const struct xenbus_device_id blk
 };
 MODULE_ALIAS("xen:vbd");
=20
-static struct xenbus_driver blkfront =3D {
-	.name =3D "vbd",
-	.owner =3D THIS_MODULE,
-	.ids =3D blkfront_ids,
+static DEFINE_XENBUS_DRIVER(blkfront, ,
 	.probe =3D blkfront_probe,
 	.remove =3D blkfront_remove,
 	.resume =3D blkfront_resume,
 	.otherend_changed =3D backend_changed,
 	.is_ready =3D blkfront_is_ready,
-};
+);
=20
=20
 static int __init xlblk_init(void)
@@ -951,14 +948,14 @@ static int __init xlblk_init(void)
 	if (!is_running_on_xen())
 		return -ENODEV;
=20
-	return xenbus_register_frontend(&blkfront);
+	return xenbus_register_frontend(&blkfront_driver);
 }
 module_init(xlblk_init);
=20
=20
 static void __exit xlblk_exit(void)
 {
-	return xenbus_unregister_driver(&blkfront);
+	return xenbus_unregister_driver(&blkfront_driver);
 }
 module_exit(xlblk_exit);
=20
--- a/drivers/xen/blktap/xenbus.c
+++ b/drivers/xen/blktap/xenbus.c
@@ -490,18 +490,14 @@ static const struct xenbus_device_id blk
 	{ "" }
 };
=20
-
-static struct xenbus_driver blktap =3D {
-	.name =3D "tap",
-	.owner =3D THIS_MODULE,
-	.ids =3D blktap_ids,
+static DEFINE_XENBUS_DRIVER(blktap, ,
 	.probe =3D blktap_probe,
 	.remove =3D blktap_remove,
 	.otherend_changed =3D tap_frontend_changed
-};
+);
=20
=20
 void tap_blkif_xenbus_init(void)
 {
-	xenbus_register_backend(&blktap);
+	xenbus_register_backend(&blktap_driver);
 }
--- a/drivers/xen/fbfront/xenfb.c
+++ b/drivers/xen/fbfront/xenfb.c
@@ -857,15 +857,12 @@ static const struct xenbus_device_id xen
 };
 MODULE_ALIAS("xen:vfb");
=20
-static struct xenbus_driver xenfb_driver =3D {
-	.name =3D "vfb",
-	.owner =3D THIS_MODULE,
-	.ids =3D xenfb_ids,
+static DEFINE_XENBUS_DRIVER(xenfb, ,
 	.probe =3D xenfb_probe,
 	.remove =3D xenfb_remove,
 	.resume =3D xenfb_resume,
 	.otherend_changed =3D xenfb_backend_changed,
-};
+);
=20
 static int __init xenfb_init(void)
 {
--- a/drivers/xen/fbfront/xenkbd.c
+++ b/drivers/xen/fbfront/xenkbd.c
@@ -335,15 +335,12 @@ static const struct xenbus_device_id xen
 };
 MODULE_ALIAS("xen:vkbd");
=20
-static struct xenbus_driver xenkbd_driver =3D {
-	.name =3D "vkbd",
-	.owner =3D THIS_MODULE,
-	.ids =3D xenkbd_ids,
+static DEFINE_XENBUS_DRIVER(xenkbd, ,
 	.probe =3D xenkbd_probe,
 	.remove =3D xenkbd_remove,
 	.resume =3D xenkbd_resume,
 	.otherend_changed =3D xenkbd_backend_changed,
-};
+);
=20
 static int __init xenkbd_init(void)
 {
--- a/drivers/xen/netback/xenbus.c
+++ b/drivers/xen/netback/xenbus.c
@@ -437,19 +437,15 @@ static const struct xenbus_device_id net
 	{ "" }
 };
=20
-
-static struct xenbus_driver netback =3D {
-	.name =3D "vif",
-	.owner =3D THIS_MODULE,
-	.ids =3D netback_ids,
+static DEFINE_XENBUS_DRIVER(netback, ,
 	.probe =3D netback_probe,
 	.remove =3D netback_remove,
 	.uevent =3D netback_uevent,
 	.otherend_changed =3D frontend_changed,
-};
+);
=20
=20
 void netif_xenbus_init(void)
 {
-	xenbus_register_backend(&netback);
+	xenbus_register_backend(&netback_driver);
 }
--- a/drivers/xen/netfront/netfront.c
+++ b/drivers/xen/netfront/netfront.c
@@ -2197,18 +2197,14 @@ static const struct xenbus_device_id net
 };
 MODULE_ALIAS("xen:vif");
=20
-
-static struct xenbus_driver netfront_driver =3D {
-	.name =3D "vif",
-	.owner =3D THIS_MODULE,
-	.ids =3D netfront_ids,
+static DEFINE_XENBUS_DRIVER(netfront, ,
 	.probe =3D netfront_probe,
 	.remove =3D __devexit_p(netfront_remove),
 	.suspend =3D netfront_suspend,
 	.suspend_cancel =3D netfront_suspend_cancel,
 	.resume =3D netfront_resume,
 	.otherend_changed =3D backend_changed,
-};
+);
=20
=20
 static int __init netif_init(void)
--- a/drivers/xen/pciback/xenbus.c
+++ b/drivers/xen/pciback/xenbus.c
@@ -676,19 +676,16 @@ static int pciback_xenbus_remove(struct=20
 	return 0;
 }
=20
-static const struct xenbus_device_id xenpci_ids[] =3D {
+static const struct xenbus_device_id pciback_ids[] =3D {
 	{"pci"},
 	{{0}},
 };
=20
-static struct xenbus_driver xenbus_pciback_driver =3D {
-	.name 			=3D "pciback",
-	.owner 			=3D THIS_MODULE,
-	.ids 			=3D xenpci_ids,
+static DEFINE_XENBUS_DRIVER(pciback, "pciback",
 	.probe 			=3D pciback_xenbus_probe,
 	.remove 		=3D pciback_xenbus_remove,
 	.otherend_changed 	=3D pciback_frontend_changed,
-};
+);
=20
 int __init pciback_xenbus_register(void)
 {
@@ -700,11 +697,11 @@ int __init pciback_xenbus_register(void)
 			"pciback_workqueue failed\n");
 		return -EFAULT;
 	}
-	return xenbus_register_backend(&xenbus_pciback_driver);
+	return xenbus_register_backend(&pciback_driver);
 }
=20
 void __exit pciback_xenbus_unregister(void)
 {
 	destroy_workqueue(pciback_wq);
-	xenbus_unregister_driver(&xenbus_pciback_driver);
+	xenbus_unregister_driver(&pciback_driver);
 }
--- a/drivers/xen/pcifront/xenbus.c
+++ b/drivers/xen/pcifront/xenbus.c
@@ -456,27 +456,24 @@ static int pcifront_xenbus_remove(struct
 	return 0;
 }
=20
-static const struct xenbus_device_id xenpci_ids[] =3D {
+static const struct xenbus_device_id pcifront_ids[] =3D {
 	{"pci"},
 	{{0}},
 };
 MODULE_ALIAS("xen:pci");
=20
-static struct xenbus_driver xenbus_pcifront_driver =3D {
-	.name 			=3D "pcifront",
-	.owner 			=3D THIS_MODULE,
-	.ids 			=3D xenpci_ids,
+static DEFINE_XENBUS_DRIVER(pcifront, "pcifront",
 	.probe 			=3D pcifront_xenbus_probe,
 	.remove 		=3D pcifront_xenbus_remove,
 	.otherend_changed 	=3D pcifront_backend_changed,
-};
+);
=20
 static int __init pcifront_init(void)
 {
 	if (!is_running_on_xen())
 		return -ENODEV;
=20
-	return xenbus_register_frontend(&xenbus_pcifront_driver);
+	return xenbus_register_frontend(&pcifront_driver);
 }
=20
 /* Initialize after the Xen PCI Frontend Stub is initialized */
--- a/drivers/xen/scsiback/xenbus.c
+++ b/drivers/xen/scsiback/xenbus.c
@@ -352,26 +352,23 @@ fail:
 }
=20
=20
-static struct xenbus_device_id scsiback_ids[] =3D {
+static const struct xenbus_device_id scsiback_ids[] =3D {
 	{ "vscsi" },
 	{ "" }
 };
=20
-static struct xenbus_driver scsiback =3D {
-	.name			=3D "vscsi",
-	.owner			=3D THIS_MODULE,
-	.ids			=3D scsiback_ids,
+static DEFINE_XENBUS_DRIVER(scsiback, ,
 	.probe			=3D scsiback_probe,
 	.remove			=3D scsiback_remove,
 	.otherend_changed	=3D scsiback_frontend_changed
-};
+);
=20
 int scsiback_xenbus_init(void)
 {
-	return xenbus_register_backend(&scsiback);
+	return xenbus_register_backend(&scsiback_driver);
 }
=20
 void scsiback_xenbus_unregister(void)
 {
-	xenbus_unregister_driver(&scsiback);
+	xenbus_unregister_driver(&scsiback_driver);
 }
--- a/drivers/xen/scsifront/xenbus.c
+++ b/drivers/xen/scsifront/xenbus.c
@@ -398,21 +398,18 @@ static void scsifront_backend_changed(st
 }
=20
=20
-static struct xenbus_device_id scsifront_ids[] =3D {
+static const struct xenbus_device_id scsifront_ids[] =3D {
 	{ "vscsi" },
 	{ "" }
 };
 MODULE_ALIAS("xen:vscsi");
=20
-static struct xenbus_driver scsifront_driver =3D {
-	.name			=3D "vscsi",
-	.owner			=3D THIS_MODULE,
-	.ids			=3D scsifront_ids,
+static DEFINE_XENBUS_DRIVER(scsifront, ,
 	.probe			=3D scsifront_probe,
 	.remove			=3D scsifront_remove,
 /* 	.resume			=3D scsifront_resume, */
 	.otherend_changed	=3D scsifront_backend_changed,
-};
+);
=20
 int scsifront_xenbus_init(void)
 {
--- a/drivers/xen/tpmback/xenbus.c
+++ b/drivers/xen/tpmback/xenbus.c
@@ -251,23 +251,19 @@ static const struct xenbus_device_id tpm
 	{ "" }
 };
=20
-
-static struct xenbus_driver tpmback =3D {
-	.name =3D "vtpm",
-	.owner =3D THIS_MODULE,
-	.ids =3D tpmback_ids,
+static DEFINE_XENBUS_DRIVER(tpmback, ,
 	.probe =3D tpmback_probe,
 	.remove =3D tpmback_remove,
 	.otherend_changed =3D frontend_changed,
-};
+);
=20
=20
 void tpmif_xenbus_init(void)
 {
-	xenbus_register_backend(&tpmback);
+	xenbus_register_backend(&tpmback_driver);
 }
=20
 void tpmif_xenbus_exit(void)
 {
-	xenbus_unregister_driver(&tpmback);
+	xenbus_unregister_driver(&tpmback_driver);
 }
--- a/drivers/xen/usbback/xenbus.c
+++ b/drivers/xen/usbback/xenbus.c
@@ -317,14 +317,11 @@ static const struct xenbus_device_id usb
 	{ "" },
 };
=20
-static struct xenbus_driver usbback_driver =3D {
-	.name =3D "vusb",
-	.owner =3D THIS_MODULE,
-	.ids =3D usbback_ids,
+static DEFINE_XENBUS_DRIVER(usbback, ,
 	.probe =3D usbback_probe,
 	.otherend_changed =3D frontend_changed,
 	.remove =3D usbback_remove,
-};
+);
=20
 int __init usbback_xenbus_init(void)
 {
--- a/drivers/xen/usbfront/xenbus.c
+++ b/drivers/xen/usbfront/xenbus.c
@@ -379,14 +379,11 @@ static const struct xenbus_device_id usb
 };
 MODULE_ALIAS("xen:vusb");
=20
-static struct xenbus_driver usbfront_driver =3D {
-	.name =3D "vusb",
-	.owner =3D THIS_MODULE,
-	.ids =3D usbfront_ids,
+static DEFINE_XENBUS_DRIVER(usbfront, ,
 	.probe =3D usbfront_probe,
 	.otherend_changed =3D backend_changed,
 	.remove =3D usbfront_remove,
-};
+);
=20
 static int __init usbfront_init(void)
 {
--- a/drivers/xen/xenbus/xenbus_probe.c
+++ b/drivers/xen/xenbus/xenbus_probe.c
@@ -382,11 +382,7 @@ int xenbus_register_driver_common(struct
 	if (bus->error)
 		return bus->error;
=20
-	drv->driver.name =3D drv->name;
 	drv->driver.bus =3D &bus->bus;
-#if LINUX_VERSION_CODE >=3D KERNEL_VERSION(2,6,10)
-	drv->driver.owner =3D drv->owner;
-#endif
 #if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,16)
 	drv->driver.probe =3D xenbus_dev_probe;
 	drv->driver.remove =3D xenbus_dev_remove;
--- a/include/xen/xenbus.h
+++ b/include/xen/xenbus.h
@@ -40,6 +40,7 @@
 #include <linux/completion.h>
 #include <linux/init.h>
 #include <linux/err.h>
+#include <linux/version.h>
 #include <xen/interface/xen.h>
 #include <xen/interface/grant_table.h>
 #include <xen/interface/io/xenbus.h>
@@ -93,8 +94,6 @@ struct xenbus_device_id
=20
 /* A xenbus driver. */
 struct xenbus_driver {
-	char *name;
-	struct module *owner;
 	const struct xenbus_device_id *ids;
 	int (*probe)(struct xenbus_device *dev,
 		     const struct xenbus_device_id *id);
@@ -110,6 +109,19 @@ struct xenbus_driver {
 	int (*is_ready)(struct xenbus_device *dev);
 };
=20
+#if LINUX_VERSION_CODE >=3D KERNEL_VERSION(2,6,10)
+# define XENBUS_DRIVER_SET_OWNER(mod) .driver.owner =3D mod,
+#else
+# define XENBUS_DRIVER_SET_OWNER(mod)
+#endif
+
+#define DEFINE_XENBUS_DRIVER(var, drvname, methods...)		\
+struct xenbus_driver var ## _driver =3D {				\
+	.driver.name =3D drvname + 0 ?: var ## _ids->devicetype,	\
+	XENBUS_DRIVER_SET_OWNER(THIS_MODULE)			\
+	.ids =3D var ## _ids, ## methods				\
+}
+
 static inline struct xenbus_driver *to_xenbus_driver(struct device_driver =
*drv)
 {
 	return container_of(drv, struct xenbus_driver, driver);



--=__PartCAE56209.0__=
Content-Type: text/plain; name="xen-xenbus-driver-cleanup.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="xen-xenbus-driver-cleanup.patch"

consolidate and simplify struct xenbus_driver instantiation=0A=0AThe =
'name' and 'owner' members are redundant with the identically named=0Afield=
s in the 'driver' sub-structure. Rather than switching each=0Ainstance to =
specify these fields explicitly, introduce a macro to=0Asimplify this (and =
at once to abstract out - for the unmodified drivers=0Abuild - the absence =
of the 'owner' field in Linux prior to 2.6.10).=0A=0AAlso add a module =
alias for the vtpm frontend driver (overlooked in=0A141:5e294e29a43e).=0A=
=0Av2: Eliminate further redundancy by allowing the drvname argument =
to=0ADEFINE_XENBUS_DRIVER() to be blank (in which case the first entry =
from=0Athe ID table will be used for .driver.name).=0A=0ASigned-off-by: =
Jan Beulich <jbeulich@suse.com>=0A=0A--- a/drivers/char/tpm/tpm_xen.c=0A+++=
 b/drivers/char/tpm/tpm_xen.c=0A@@ -475,26 +475,24 @@ static int tpmif_conn=
ect(struct xenbus_d=0A 	return 0;=0A }=0A =0A-static struct xenbus_device_i=
d tpmfront_ids[] =3D {=0A+static const struct xenbus_device_id tpmfront_ids=
[] =3D {=0A 	{ "vtpm" },=0A 	{ "" }=0A };=0A+MODULE_ALIAS("xen:vtpm");=
=0A =0A-static struct xenbus_driver tpmfront =3D {=0A-	.name =3D =
"vtpm",=0A-	.owner =3D THIS_MODULE,=0A-	.ids =3D tpmfront_ids,=0A+s=
tatic DEFINE_XENBUS_DRIVER(tpmfront, ,=0A 	.probe =3D tpmfront_probe,=
=0A 	.remove =3D  tpmfront_remove,=0A 	.resume =3D tpmfront_resume=
,=0A 	.otherend_changed =3D backend_changed,=0A 	.suspend =3D =
tpmfront_suspend,=0A 	.suspend_cancel =3D tpmfront_suspend_cancel,=0A-};=
=0A+);=0A =0A static void __init init_tpm_xenbus(void)=0A {=0A-	xenbus_regi=
ster_frontend(&tpmfront);=0A+	xenbus_register_frontend(&tpmfront_driver);=
=0A }=0A =0A static int tpmif_allocate_tx_buffers(struct tpm_private =
*tp)=0A--- a/drivers/xen/blkback/xenbus.c=0A+++ b/drivers/xen/blkback/xenbu=
s.c=0A@@ -542,18 +542,14 @@ static const struct xenbus_device_id blk=0A 	=
{ "" }=0A };=0A =0A-=0A-static struct xenbus_driver blkback =3D {=0A-	=
.name =3D "vbd",=0A-	.owner =3D THIS_MODULE,=0A-	.ids =3D blkback_id=
s,=0A+static DEFINE_XENBUS_DRIVER(blkback, ,=0A 	.probe =3D =
blkback_probe,=0A 	.remove =3D blkback_remove,=0A 	.otherend_changed =
=3D frontend_changed=0A-};=0A+);=0A =0A =0A void blkif_xenbus_init(void)=0A=
 {=0A-	xenbus_register_backend(&blkback);=0A+	xenbus_register_backend(&bl=
kback_driver);=0A }=0A--- a/drivers/xen/blkfront/blkfront.c=0A+++ =
b/drivers/xen/blkfront/blkfront.c=0A@@ -934,16 +934,13 @@ static const =
struct xenbus_device_id blk=0A };=0A MODULE_ALIAS("xen:vbd");=0A =0A-static=
 struct xenbus_driver blkfront =3D {=0A-	.name =3D "vbd",=0A-	=
.owner =3D THIS_MODULE,=0A-	.ids =3D blkfront_ids,=0A+static DEFINE_XEN=
BUS_DRIVER(blkfront, ,=0A 	.probe =3D blkfront_probe,=0A 	.remove =
=3D blkfront_remove,=0A 	.resume =3D blkfront_resume,=0A 	=
.otherend_changed =3D backend_changed,=0A 	.is_ready =3D blkfront_is_r=
eady,=0A-};=0A+);=0A =0A =0A static int __init xlblk_init(void)=0A@@ =
-951,14 +948,14 @@ static int __init xlblk_init(void)=0A 	if =
(!is_running_on_xen())=0A 		return -ENODEV;=0A =0A-	return =
xenbus_register_frontend(&blkfront);=0A+	return xenbus_register_fron=
tend(&blkfront_driver);=0A }=0A module_init(xlblk_init);=0A =0A =0A static =
void __exit xlblk_exit(void)=0A {=0A-	return xenbus_unregister_driver(&bl=
kfront);=0A+	return xenbus_unregister_driver(&blkfront_driver);=0A }=0A =
module_exit(xlblk_exit);=0A =0A--- a/drivers/xen/blktap/xenbus.c=0A+++ =
b/drivers/xen/blktap/xenbus.c=0A@@ -490,18 +490,14 @@ static const struct =
xenbus_device_id blk=0A 	{ "" }=0A };=0A =0A-=0A-static struct =
xenbus_driver blktap =3D {=0A-	.name =3D "tap",=0A-	.owner =3D =
THIS_MODULE,=0A-	.ids =3D blktap_ids,=0A+static DEFINE_XENBUS_DRIVER=
(blktap, ,=0A 	.probe =3D blktap_probe,=0A 	.remove =3D blktap_remove,=
=0A 	.otherend_changed =3D tap_frontend_changed=0A-};=0A+);=0A =0A =0A =
void tap_blkif_xenbus_init(void)=0A {=0A-	xenbus_register_backend(&bl=
ktap);=0A+	xenbus_register_backend(&blktap_driver);=0A }=0A--- =
a/drivers/xen/fbfront/xenfb.c=0A+++ b/drivers/xen/fbfront/xenfb.c=0A@@ =
-857,15 +857,12 @@ static const struct xenbus_device_id xen=0A };=0A =
MODULE_ALIAS("xen:vfb");=0A =0A-static struct xenbus_driver xenfb_driver =
=3D {=0A-	.name =3D "vfb",=0A-	.owner =3D THIS_MODULE,=0A-	=
.ids =3D xenfb_ids,=0A+static DEFINE_XENBUS_DRIVER(xenfb, ,=0A 	.probe =3D =
xenfb_probe,=0A 	.remove =3D xenfb_remove,=0A 	.resume =3D =
xenfb_resume,=0A 	.otherend_changed =3D xenfb_backend_changed,=0A-};=
=0A+);=0A =0A static int __init xenfb_init(void)=0A {=0A--- a/drivers/xen/f=
bfront/xenkbd.c=0A+++ b/drivers/xen/fbfront/xenkbd.c=0A@@ -335,15 +335,12 =
@@ static const struct xenbus_device_id xen=0A };=0A MODULE_ALIAS("xen:vkbd=
");=0A =0A-static struct xenbus_driver xenkbd_driver =3D {=0A-	.name =3D =
"vkbd",=0A-	.owner =3D THIS_MODULE,=0A-	.ids =3D xenkbd_ids,=0A+sta=
tic DEFINE_XENBUS_DRIVER(xenkbd, ,=0A 	.probe =3D xenkbd_probe,=0A 	=
.remove =3D xenkbd_remove,=0A 	.resume =3D xenkbd_resume,=0A 	.otherend_c=
hanged =3D xenkbd_backend_changed,=0A-};=0A+);=0A =0A static int __init =
xenkbd_init(void)=0A {=0A--- a/drivers/xen/netback/xenbus.c=0A+++ =
b/drivers/xen/netback/xenbus.c=0A@@ -437,19 +437,15 @@ static const struct =
xenbus_device_id net=0A 	{ "" }=0A };=0A =0A-=0A-static struct =
xenbus_driver netback =3D {=0A-	.name =3D "vif",=0A-	.owner =3D =
THIS_MODULE,=0A-	.ids =3D netback_ids,=0A+static DEFINE_XENBUS_DRIVE=
R(netback, ,=0A 	.probe =3D netback_probe,=0A 	.remove =3D =
netback_remove,=0A 	.uevent =3D netback_uevent,=0A 	.otherend_changed =
=3D frontend_changed,=0A-};=0A+);=0A =0A =0A void netif_xenbus_init(void)=
=0A {=0A-	xenbus_register_backend(&netback);=0A+	xenbus_register_bac=
kend(&netback_driver);=0A }=0A--- a/drivers/xen/netfront/netfront.c=0A+++ =
b/drivers/xen/netfront/netfront.c=0A@@ -2197,18 +2197,14 @@ static const =
struct xenbus_device_id net=0A };=0A MODULE_ALIAS("xen:vif");=0A =0A-=0A-st=
atic struct xenbus_driver netfront_driver =3D {=0A-	.name =3D =
"vif",=0A-	.owner =3D THIS_MODULE,=0A-	.ids =3D netfront_ids,=0A+s=
tatic DEFINE_XENBUS_DRIVER(netfront, ,=0A 	.probe =3D netfront_probe,=
=0A 	.remove =3D __devexit_p(netfront_remove),=0A 	.suspend =3D =
netfront_suspend,=0A 	.suspend_cancel =3D netfront_suspend_cancel,=0A 	=
.resume =3D netfront_resume,=0A 	.otherend_changed =3D backend_chang=
ed,=0A-};=0A+);=0A =0A =0A static int __init netif_init(void)=0A--- =
a/drivers/xen/pciback/xenbus.c=0A+++ b/drivers/xen/pciback/xenbus.c=0A@@ =
-676,19 +676,16 @@ static int pciback_xenbus_remove(struct =0A 	return =
0;=0A }=0A =0A-static const struct xenbus_device_id xenpci_ids[] =3D =
{=0A+static const struct xenbus_device_id pciback_ids[] =3D {=0A 	=
{"pci"},=0A 	{{0}},=0A };=0A =0A-static struct xenbus_driver xenbus_pcib=
ack_driver =3D {=0A-	.name 			=3D "pciback",=0A-	=
.owner 			=3D THIS_MODULE,=0A-	.ids 			=
=3D xenpci_ids,=0A+static DEFINE_XENBUS_DRIVER(pciback, "pciback",=0A 	=
.probe 			=3D pciback_xenbus_probe,=0A 	.remove 		=
=3D pciback_xenbus_remove,=0A 	.otherend_changed 	=3D pciback_fronten=
d_changed,=0A-};=0A+);=0A =0A int __init pciback_xenbus_register(void)=0A =
{=0A@@ -700,11 +697,11 @@ int __init pciback_xenbus_register(void)=0A 		=
	"pciback_workqueue failed\n");=0A 		return -EFAULT;=0A =
	}=0A-	return xenbus_register_backend(&xenbus_pciback_driver);=0A+=
	return xenbus_register_backend(&pciback_driver);=0A }=0A =0A void =
__exit pciback_xenbus_unregister(void)=0A {=0A 	destroy_workqueue(pciback_w=
q);=0A-	xenbus_unregister_driver(&xenbus_pciback_driver);=0A+	xenbus_unre=
gister_driver(&pciback_driver);=0A }=0A--- a/drivers/xen/pcifront/xenbus.c=
=0A+++ b/drivers/xen/pcifront/xenbus.c=0A@@ -456,27 +456,24 @@ static int =
pcifront_xenbus_remove(struct=0A 	return 0;=0A }=0A =0A-static const =
struct xenbus_device_id xenpci_ids[] =3D {=0A+static const struct =
xenbus_device_id pcifront_ids[] =3D {=0A 	{"pci"},=0A 	{{0}},=0A =
};=0A MODULE_ALIAS("xen:pci");=0A =0A-static struct xenbus_driver =
xenbus_pcifront_driver =3D {=0A-	.name 			=3D =
"pcifront",=0A-	.owner 			=3D THIS_MODULE,=0A-	.ids 		=
	=3D xenpci_ids,=0A+static DEFINE_XENBUS_DRIVER(pcifront, "pcifront"=
,=0A 	.probe 			=3D pcifront_xenbus_probe,=0A 	.remove 	=
	=3D pcifront_xenbus_remove,=0A 	.otherend_changed 	=3D =
pcifront_backend_changed,=0A-};=0A+);=0A =0A static int __init pcifront_ini=
t(void)=0A {=0A 	if (!is_running_on_xen())=0A 		return =
-ENODEV;=0A =0A-	return xenbus_register_frontend(&xenbus_pcifront_dr=
iver);=0A+	return xenbus_register_frontend(&pcifront_driver);=0A }=0A =
=0A /* Initialize after the Xen PCI Frontend Stub is initialized */=0A--- =
a/drivers/xen/scsiback/xenbus.c=0A+++ b/drivers/xen/scsiback/xenbus.c=0A@@ =
-352,26 +352,23 @@ fail:=0A }=0A =0A =0A-static struct xenbus_device_id =
scsiback_ids[] =3D {=0A+static const struct xenbus_device_id scsiback_ids[]=
 =3D {=0A 	{ "vscsi" },=0A 	{ "" }=0A };=0A =0A-static struct =
xenbus_driver scsiback =3D {=0A-	.name			=3D =
"vscsi",=0A-	.owner			=3D THIS_MODULE,=0A-	.ids		=
	=3D scsiback_ids,=0A+static DEFINE_XENBUS_DRIVER(scsiback, ,=0A 	=
.probe			=3D scsiback_probe,=0A 	.remove			=
=3D scsiback_remove,=0A 	.otherend_changed	=3D scsiback_fronte=
nd_changed=0A-};=0A+);=0A =0A int scsiback_xenbus_init(void)=0A {=0A-	=
return xenbus_register_backend(&scsiback);=0A+	return xenbus_register_back=
end(&scsiback_driver);=0A }=0A =0A void scsiback_xenbus_unregister(void)=0A=
 {=0A-	xenbus_unregister_driver(&scsiback);=0A+	xenbus_unregister_d=
river(&scsiback_driver);=0A }=0A--- a/drivers/xen/scsifront/xenbus.c=0A+++ =
b/drivers/xen/scsifront/xenbus.c=0A@@ -398,21 +398,18 @@ static void =
scsifront_backend_changed(st=0A }=0A =0A =0A-static struct xenbus_device_id=
 scsifront_ids[] =3D {=0A+static const struct xenbus_device_id scsifront_id=
s[] =3D {=0A 	{ "vscsi" },=0A 	{ "" }=0A };=0A MODULE_ALIAS("xen:v=
scsi");=0A =0A-static struct xenbus_driver scsifront_driver =3D {=0A-	=
.name			=3D "vscsi",=0A-	.owner			=
=3D THIS_MODULE,=0A-	.ids			=3D scsifront_ids,=0A+stati=
c DEFINE_XENBUS_DRIVER(scsifront, ,=0A 	.probe			=3D =
scsifront_probe,=0A 	.remove			=3D scsifront_remove,=0A =
/* 	.resume			=3D scsifront_resume, */=0A 	.otherend_c=
hanged	=3D scsifront_backend_changed,=0A-};=0A+);=0A =0A int scsifront_xen=
bus_init(void)=0A {=0A--- a/drivers/xen/tpmback/xenbus.c=0A+++ b/drivers/xe=
n/tpmback/xenbus.c=0A@@ -251,23 +251,19 @@ static const struct xenbus_devic=
e_id tpm=0A 	{ "" }=0A };=0A =0A-=0A-static struct xenbus_driver =
tpmback =3D {=0A-	.name =3D "vtpm",=0A-	.owner =3D THIS_MODULE,=0A-=
	.ids =3D tpmback_ids,=0A+static DEFINE_XENBUS_DRIVER(tpmback, ,=0A =
	.probe =3D tpmback_probe,=0A 	.remove =3D tpmback_remove,=0A 	=
.otherend_changed =3D frontend_changed,=0A-};=0A+);=0A =0A =0A void =
tpmif_xenbus_init(void)=0A {=0A-	xenbus_register_backend(&tpmback);=
=0A+	xenbus_register_backend(&tpmback_driver);=0A }=0A =0A void =
tpmif_xenbus_exit(void)=0A {=0A-	xenbus_unregister_driver(&tpmback);=
=0A+	xenbus_unregister_driver(&tpmback_driver);=0A }=0A--- a/drivers/xen=
/usbback/xenbus.c=0A+++ b/drivers/xen/usbback/xenbus.c=0A@@ -317,14 =
+317,11 @@ static const struct xenbus_device_id usb=0A 	{ "" },=0A };=0A =
=0A-static struct xenbus_driver usbback_driver =3D {=0A-	.name =3D =
"vusb",=0A-	.owner =3D THIS_MODULE,=0A-	.ids =3D usbback_ids,=0A+st=
atic DEFINE_XENBUS_DRIVER(usbback, ,=0A 	.probe =3D usbback_probe,=
=0A 	.otherend_changed =3D frontend_changed,=0A 	.remove =3D =
usbback_remove,=0A-};=0A+);=0A =0A int __init usbback_xenbus_init(void)=0A =
{=0A--- a/drivers/xen/usbfront/xenbus.c=0A+++ b/drivers/xen/usbfront/xenbus=
.c=0A@@ -379,14 +379,11 @@ static const struct xenbus_device_id usb=0A =
};=0A MODULE_ALIAS("xen:vusb");=0A =0A-static struct xenbus_driver =
usbfront_driver =3D {=0A-	.name =3D "vusb",=0A-	.owner =3D =
THIS_MODULE,=0A-	.ids =3D usbfront_ids,=0A+static DEFINE_XENBUS_DRIV=
ER(usbfront, ,=0A 	.probe =3D usbfront_probe,=0A 	.otherend_changed =
=3D backend_changed,=0A 	.remove =3D usbfront_remove,=0A-};=0A+);=0A=
 =0A static int __init usbfront_init(void)=0A {=0A--- a/drivers/xen/xenbus/=
xenbus_probe.c=0A+++ b/drivers/xen/xenbus/xenbus_probe.c=0A@@ -382,11 =
+382,7 @@ int xenbus_register_driver_common(struct=0A 	if (bus->error)=0A =
		return bus->error;=0A =0A-	drv->driver.name =3D =
drv->name;=0A 	drv->driver.bus =3D &bus->bus;=0A-#if LINUX_VERSION_CODE =
>=3D KERNEL_VERSION(2,6,10)=0A-	drv->driver.owner =3D drv->owner;=0A-#endif=
=0A #if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,16)=0A 	drv->driver.probe =
=3D xenbus_dev_probe;=0A 	drv->driver.remove =3D xenbus_dev_remove;=
=0A--- a/include/xen/xenbus.h=0A+++ b/include/xen/xenbus.h=0A@@ -40,6 =
+40,7 @@=0A #include <linux/completion.h>=0A #include <linux/init.h>=0A =
#include <linux/err.h>=0A+#include <linux/version.h>=0A #include <xen/inter=
face/xen.h>=0A #include <xen/interface/grant_table.h>=0A #include =
<xen/interface/io/xenbus.h>=0A@@ -93,8 +94,6 @@ struct xenbus_device_id=0A =
=0A /* A xenbus driver. */=0A struct xenbus_driver {=0A-	char =
*name;=0A-	struct module *owner;=0A 	const struct xenbus_device_=
id *ids;=0A 	int (*probe)(struct xenbus_device *dev,=0A 		   =
  const struct xenbus_device_id *id);=0A@@ -110,6 +109,19 @@ struct =
xenbus_driver {=0A 	int (*is_ready)(struct xenbus_device *dev);=0A =
};=0A =0A+#if LINUX_VERSION_CODE >=3D KERNEL_VERSION(2,6,10)=0A+# define =
XENBUS_DRIVER_SET_OWNER(mod) .driver.owner =3D mod,=0A+#else=0A+# define =
XENBUS_DRIVER_SET_OWNER(mod)=0A+#endif=0A+=0A+#define DEFINE_XENBUS_DRIVER(=
var, drvname, methods...)		\=0A+struct xenbus_driver var ## =
_driver =3D {				\=0A+	.driver.name =3D drvname + =
0 ?: var ## _ids->devicetype,	\=0A+	XENBUS_DRIVER_SET_OWNER(THIS_MODULE=
)			\=0A+	.ids =3D var ## _ids, ## methods		=
		\=0A+}=0A+=0A static inline struct xenbus_driver *to_xenbus=
_driver(struct device_driver *drv)=0A {=0A 	return container_of(drv, =
struct xenbus_driver, driver);=0A
--=__PartCAE56209.0__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--=__PartCAE56209.0__=--


From xen-devel-bounces@lists.xensource.com Fri Dec 16 09:32:28 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 09:32:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbU98-0005Qk-40; Fri, 16 Dec 2011 09:32:06 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RbU96-0005Qf-Id
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 09:32:04 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1324027894!52427999!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjU3OQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 692 invoked from network); 16 Dec 2011 09:31:34 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Dec 2011 09:31:34 -0000
X-IronPort-AV: E=Sophos;i="4.71,362,1320624000"; 
   d="scan'208";a="9507808"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Dec 2011 09:31:58 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 16 Dec 2011 09:31:58 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefan Bader <stefan.bader@canonical.com>
Date: Fri, 16 Dec 2011 09:31:57 +0000
In-Reply-To: <4EEB0CE9.4040405@canonical.com>
References: <4EEA4877.8010307@canonical.com>
	<1323982417.20936.898.camel@dagon.hellion.org.uk>
	<4EEB0CE9.4040405@canonical.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1324027918.20077.530.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Olaf Hering <olaf@aepfle.de>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] xenbus and the message of doom
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2011-12-16 at 09:18 +0000, Stefan Bader wrote:
> On 15.12.2011 21:53, Ian Campbell wrote:
> > On Thu, 2011-12-15 at 19:20 +0000, Stefan Bader wrote:
> >> I was investigating a bug report[1] about newer kernels (>3.1) not booting as
> >> HVM guests on Amazon EC2. For some reason git bisect did give the some pain, but
> >> it lead me at least close and with some crash dump data I think I figured the
> >> problem.
> >>
> >> commit ddacf5ef684a655abe2bb50c4b2a5b72ae0d5e05
> >> Author: Olaf Hering <olaf@aepfle.de>
> >> Date:   Thu Sep 22 16:14:49 2011 +0200
> >>
> >>     xen/pv-on-hvm kexec: add xs_reset_watches to shutdown watches from old
> >>     kernel
> >>
> >> This change introduced a xs_reset_watches() call. The problem seems to be that
> >> there is at least some version of Xen (I was able to reproduce with a 3.4.3
> >> version which I admit to deliberately not having updated) for which xenstore
> >> will not return any reply.
> >>
> >> At least the backtraces in crash showed that xs_init had been calling
> >> xs_reset_watches() and that was happily idling in read_reply(). Effectively
> >> nothing was going on and the boot just hung.
> >> By just not doing that xs_reset_watches() call, I was able to boot under the
> >> same host. And for what it is worth there has not been an issue with Xen 4.1.1
> >> and a 3.0 dom0 kernel. Just this "older" release is trouble.
> > 
> > I sent a patch to fix exactly this issue in oxenstored (the ocaml
> > xenstore) just this week. Is there any chance that you are running C
> > xenstored with Xen 4.1.1 and oxenstored with Xen 3.4.3?
> 
> Thanks for the pointer, I missed that thread. Now dumb question, would
> oxenstored be named that way? Or iow, how do I quickly find out what is running?

The process name will be oxenstored instead of xenstored.

> The binary running in 3.4.3 is xenstored which is a linked executable (same in
> 4.1.1).

The sounds like you are running the C xenstored in both cases so this is
a red-herring.

> But I guess, whatever version is running, any oxenstored would not have the
> bugfix because things take longer to reach any packaged versions.

Correct.

> I rather would suspect that in 4.1.1, the reset watches message probably is just
> known and thus avoiding the problem. Unfortunately it is near impossible to tell
> for sure what exactly EC2 is running.
> 
> The major point here probably is that when the upstream kernels are calling that
> message and there are versions of xenstored in production that will just ignore
> it while the kernel blocks waiting, this is a painful path. Production systems
> tend to update slowly and the symptoms are not that obvious.

Yes. It is unfortunate that xenstored in the field has this bug but it
does mean that the approach taken here with this new message cannot
work.

FWIW there weren't all that many changes to C xenstored between 3.4.x
and current unstable so it wouldn't be hard to identify where the fix
is, but that doesn't really help people stuck with an older xenstored.

> Having a timeout
> maybe could be useful not only for this case, but clearly it is nothing that
> should be rushed.

A timeout may not help, it depends what the daemon does after the
invalid message.

It looks as if oxenstored just throws it away and will process the next
message fine so that is OK but I didn't check the C version.

I think (or hope!) that Olaf tested with the most recent version of C
xenstored which did not support this new message and so I presume that
it correct returns an error for an unknown message but that doesn't help
us with the older C xenstored which you have.

In any case someone really needs to check both the ocaml and the
version's behaviour.

> So reverting the patch introducing that call (at least in the distro kernel) may
> be the best thing to do (knowing that this will be bought by loosing the fix for
> kexec boots fo crash kernels).

Agreed. We should revert the kernel change for now and revisit it.

One potential solution, depending on the actual behaviour of the
daemons, would be to follow the potentially unsupported command with an
innocuous well established one and use the ID field to identify which we
get a response to.

Does the target kernel know that it has been kexec'd? Perhaps we should
only reset xenstore watches if we are booting after a kexec. Worst case
the kexec tool can add a command line argument to trigger this. Doing it
this way means there is no possibility of regressions for normal boot
and kexec wasn't supported on older xenstored anyway.

Ian.

> 
> -Stefan
> 
> >> Now the big question is, should this never happen and the host needs urgent
> >> updating. Or, should xs_talkv() set up a time limit and assume failure when not
> >> receiving a message after that? I could imagine the latter might lead at least
> >> to a more helpful "there is something wrong here, dude" than just hanging around
> >> without any response. ;)
> >>
> >> -Stefan
> >>
> >> _______________________________________________
> >> Xen-devel mailing list
> >> Xen-devel@lists.xensource.com
> >> http://lists.xensource.com/xen-devel
> > 
> > 
> > 
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xensource.com
> > http://lists.xensource.com/xen-devel
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 09:32:28 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 09:32:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbU98-0005Qk-40; Fri, 16 Dec 2011 09:32:06 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RbU96-0005Qf-Id
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 09:32:04 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1324027894!52427999!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjU3OQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 692 invoked from network); 16 Dec 2011 09:31:34 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Dec 2011 09:31:34 -0000
X-IronPort-AV: E=Sophos;i="4.71,362,1320624000"; 
   d="scan'208";a="9507808"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Dec 2011 09:31:58 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 16 Dec 2011 09:31:58 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefan Bader <stefan.bader@canonical.com>
Date: Fri, 16 Dec 2011 09:31:57 +0000
In-Reply-To: <4EEB0CE9.4040405@canonical.com>
References: <4EEA4877.8010307@canonical.com>
	<1323982417.20936.898.camel@dagon.hellion.org.uk>
	<4EEB0CE9.4040405@canonical.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1324027918.20077.530.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Olaf Hering <olaf@aepfle.de>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] xenbus and the message of doom
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2011-12-16 at 09:18 +0000, Stefan Bader wrote:
> On 15.12.2011 21:53, Ian Campbell wrote:
> > On Thu, 2011-12-15 at 19:20 +0000, Stefan Bader wrote:
> >> I was investigating a bug report[1] about newer kernels (>3.1) not booting as
> >> HVM guests on Amazon EC2. For some reason git bisect did give the some pain, but
> >> it lead me at least close and with some crash dump data I think I figured the
> >> problem.
> >>
> >> commit ddacf5ef684a655abe2bb50c4b2a5b72ae0d5e05
> >> Author: Olaf Hering <olaf@aepfle.de>
> >> Date:   Thu Sep 22 16:14:49 2011 +0200
> >>
> >>     xen/pv-on-hvm kexec: add xs_reset_watches to shutdown watches from old
> >>     kernel
> >>
> >> This change introduced a xs_reset_watches() call. The problem seems to be that
> >> there is at least some version of Xen (I was able to reproduce with a 3.4.3
> >> version which I admit to deliberately not having updated) for which xenstore
> >> will not return any reply.
> >>
> >> At least the backtraces in crash showed that xs_init had been calling
> >> xs_reset_watches() and that was happily idling in read_reply(). Effectively
> >> nothing was going on and the boot just hung.
> >> By just not doing that xs_reset_watches() call, I was able to boot under the
> >> same host. And for what it is worth there has not been an issue with Xen 4.1.1
> >> and a 3.0 dom0 kernel. Just this "older" release is trouble.
> > 
> > I sent a patch to fix exactly this issue in oxenstored (the ocaml
> > xenstore) just this week. Is there any chance that you are running C
> > xenstored with Xen 4.1.1 and oxenstored with Xen 3.4.3?
> 
> Thanks for the pointer, I missed that thread. Now dumb question, would
> oxenstored be named that way? Or iow, how do I quickly find out what is running?

The process name will be oxenstored instead of xenstored.

> The binary running in 3.4.3 is xenstored which is a linked executable (same in
> 4.1.1).

The sounds like you are running the C xenstored in both cases so this is
a red-herring.

> But I guess, whatever version is running, any oxenstored would not have the
> bugfix because things take longer to reach any packaged versions.

Correct.

> I rather would suspect that in 4.1.1, the reset watches message probably is just
> known and thus avoiding the problem. Unfortunately it is near impossible to tell
> for sure what exactly EC2 is running.
> 
> The major point here probably is that when the upstream kernels are calling that
> message and there are versions of xenstored in production that will just ignore
> it while the kernel blocks waiting, this is a painful path. Production systems
> tend to update slowly and the symptoms are not that obvious.

Yes. It is unfortunate that xenstored in the field has this bug but it
does mean that the approach taken here with this new message cannot
work.

FWIW there weren't all that many changes to C xenstored between 3.4.x
and current unstable so it wouldn't be hard to identify where the fix
is, but that doesn't really help people stuck with an older xenstored.

> Having a timeout
> maybe could be useful not only for this case, but clearly it is nothing that
> should be rushed.

A timeout may not help, it depends what the daemon does after the
invalid message.

It looks as if oxenstored just throws it away and will process the next
message fine so that is OK but I didn't check the C version.

I think (or hope!) that Olaf tested with the most recent version of C
xenstored which did not support this new message and so I presume that
it correct returns an error for an unknown message but that doesn't help
us with the older C xenstored which you have.

In any case someone really needs to check both the ocaml and the
version's behaviour.

> So reverting the patch introducing that call (at least in the distro kernel) may
> be the best thing to do (knowing that this will be bought by loosing the fix for
> kexec boots fo crash kernels).

Agreed. We should revert the kernel change for now and revisit it.

One potential solution, depending on the actual behaviour of the
daemons, would be to follow the potentially unsupported command with an
innocuous well established one and use the ID field to identify which we
get a response to.

Does the target kernel know that it has been kexec'd? Perhaps we should
only reset xenstore watches if we are booting after a kexec. Worst case
the kexec tool can add a command line argument to trigger this. Doing it
this way means there is no possibility of regressions for normal boot
and kexec wasn't supported on older xenstored anyway.

Ian.

> 
> -Stefan
> 
> >> Now the big question is, should this never happen and the host needs urgent
> >> updating. Or, should xs_talkv() set up a time limit and assume failure when not
> >> receiving a message after that? I could imagine the latter might lead at least
> >> to a more helpful "there is something wrong here, dude" than just hanging around
> >> without any response. ;)
> >>
> >> -Stefan
> >>
> >> _______________________________________________
> >> Xen-devel mailing list
> >> Xen-devel@lists.xensource.com
> >> http://lists.xensource.com/xen-devel
> > 
> > 
> > 
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xensource.com
> > http://lists.xensource.com/xen-devel
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 09:34:33 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 09:34:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbUBD-0005Y1-VJ; Fri, 16 Dec 2011 09:34:15 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RbUBC-0005Xe-BK
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 09:34:14 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1324028048!5770828!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjU3OQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8953 invoked from network); 16 Dec 2011 09:34:08 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Dec 2011 09:34:08 -0000
X-IronPort-AV: E=Sophos;i="4.71,362,1320624000"; 
   d="scan'208";a="9507862"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Dec 2011 09:33:55 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 16 Dec 2011 09:33:55 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Fri, 16 Dec 2011 09:33:54 +0000
In-Reply-To: <1323968201.20077.498.camel@zakaz.uk.xensource.com>
References: <patchbomb.1323792779@cosworth.uk.xensource.com>
	<f4586d1a539c869e31fa.1323792781@cosworth.uk.xensource.com>
	<20202.9800.381383.266900@mariner.uk.xensource.com>
	<1323968201.20077.498.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1324028035.20077.531.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Olaf Hering <olaf@aepfle.de>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Vincent Hanquez <Vincent.Hanquez@eu.citrix.com>,
	Jonathan Ludlam <Jonathan.Ludlam@eu.citrix.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH 2 of 4 V2] Linux/xencommons: Use oxenstored
 by default when available
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2011-12-15 at 16:56 +0000, Ian Campbell wrote:
> On Thu, 2011-12-15 at 16:54 +0000, Ian Jackson wrote:
> > Ian Campbell writes ("[Xen-devel] [PATCH 2 of 4 V2] Linux/xencommons: Use oxenstored by default when available"):
> > > Linux/xencommons: Use oxenstored by default when available
> > 
> > I've applied #1, #3, and #4.  I'll wait with #2 until my test system
> > gets a pass and push on the change to collect the oxenstored logs.
> 
> Sounds good. Thanks.

But did you see my response re: /var/log/xenstored.conf
vs /var/log/xenstored.log in
<1323963349.20077.494.camel@zakaz.uk.xensource.com> ?

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 09:34:33 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 09:34:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbUBD-0005Y1-VJ; Fri, 16 Dec 2011 09:34:15 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RbUBC-0005Xe-BK
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 09:34:14 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1324028048!5770828!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjU3OQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8953 invoked from network); 16 Dec 2011 09:34:08 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Dec 2011 09:34:08 -0000
X-IronPort-AV: E=Sophos;i="4.71,362,1320624000"; 
   d="scan'208";a="9507862"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Dec 2011 09:33:55 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 16 Dec 2011 09:33:55 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Fri, 16 Dec 2011 09:33:54 +0000
In-Reply-To: <1323968201.20077.498.camel@zakaz.uk.xensource.com>
References: <patchbomb.1323792779@cosworth.uk.xensource.com>
	<f4586d1a539c869e31fa.1323792781@cosworth.uk.xensource.com>
	<20202.9800.381383.266900@mariner.uk.xensource.com>
	<1323968201.20077.498.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1324028035.20077.531.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Olaf Hering <olaf@aepfle.de>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Vincent Hanquez <Vincent.Hanquez@eu.citrix.com>,
	Jonathan Ludlam <Jonathan.Ludlam@eu.citrix.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH 2 of 4 V2] Linux/xencommons: Use oxenstored
 by default when available
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2011-12-15 at 16:56 +0000, Ian Campbell wrote:
> On Thu, 2011-12-15 at 16:54 +0000, Ian Jackson wrote:
> > Ian Campbell writes ("[Xen-devel] [PATCH 2 of 4 V2] Linux/xencommons: Use oxenstored by default when available"):
> > > Linux/xencommons: Use oxenstored by default when available
> > 
> > I've applied #1, #3, and #4.  I'll wait with #2 until my test system
> > gets a pass and push on the change to collect the oxenstored logs.
> 
> Sounds good. Thanks.

But did you see my response re: /var/log/xenstored.conf
vs /var/log/xenstored.log in
<1323963349.20077.494.camel@zakaz.uk.xensource.com> ?

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 09:52:18 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 09:52:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbUSL-0005qq-UE; Fri, 16 Dec 2011 09:51:57 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RbUSJ-0005qf-TK
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 09:51:56 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1324029078!52695198!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjI0MzY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13508 invoked from network); 16 Dec 2011 09:51:19 -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 2011 09:51:19 -0000
X-IronPort-AV: E=Sophos;i="4.71,362,1320642000"; d="scan'208";a="174424753"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Dec 2011 04:51:53 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 16 Dec 2011 04:51:52 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pBG9poq9005701;	Fri, 16 Dec 2011 01:51:51 -0800
MIME-Version: 1.0
X-Mercurial-Node: 38902f8c4ef37b841e1ec93b740108e0767aada4
Message-ID: <38902f8c4ef37b841e1e.1324029110@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1324029109@cosworth.uk.xensource.com>
References: <patchbomb.1324029109@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 16 Dec 2011 09:51:50 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 1 of 3 V2] libxl: add
 libxl__domain_pvcontrol_{available, read, write}
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1324028086 0
# Node ID 38902f8c4ef37b841e1ec93b740108e0767aada4
# Parent  511748da941c0d87f56e56ff05abfe860bd37689
libxl: add libxl__domain_pvcontrol_{available,read,write}

Use instead of open coding.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 511748da941c -r 38902f8c4ef3 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Fri Dec 16 09:34:43 2011 +0000
+++ b/tools/libxl/libxl.c	Fri Dec 16 09:34:46 2011 +0000
@@ -542,6 +542,58 @@ int libxl_domain_unpause(libxl_ctx *ctx,
     return rc;
 }
 
+int libxl__domain_pvcontrol_available(libxl__gc *gc, uint32_t domid)
+{
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+
+    unsigned long pvdriver = 0;
+    int ret;
+
+    if (LIBXL__DOMAIN_IS_TYPE(gc, domid, PV))
+        return 1;
+
+    ret = xc_get_hvm_param(ctx->xch, domid, HVM_PARAM_CALLBACK_IRQ, &pvdriver);
+    if (ret<0) {
+        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "getting HVM callback IRQ");
+        return ERROR_FAIL;
+    }
+    return !!pvdriver;
+}
+
+char * libxl__domain_pvcontrol_read(libxl__gc *gc, xs_transaction_t t,
+                                    uint32_t domid)
+{
+    const char *shutdown_path;
+    const char *dom_path;
+
+    dom_path = libxl__xs_get_dompath(gc, domid);
+    if (!dom_path)
+        return NULL;
+
+    shutdown_path = libxl__sprintf(gc, "%s/control/shutdown", dom_path);
+    if (!shutdown_path)
+        return NULL;
+
+    return libxl__xs_read(gc, t, shutdown_path);
+}
+
+int libxl__domain_pvcontrol_write(libxl__gc *gc, xs_transaction_t t,
+                                  uint32_t domid, const char *cmd)
+{
+    const char *shutdown_path;
+    const char *dom_path;
+
+    dom_path = libxl__xs_get_dompath(gc, domid);
+    if (!dom_path)
+        return ERROR_FAIL;
+
+    shutdown_path = libxl__sprintf(gc, "%s/control/shutdown", dom_path);
+    if (!shutdown_path)
+        return ERROR_FAIL;
+
+    return libxl__xs_write(gc, t, shutdown_path, "%s", cmd);
+}
+
 static char *req_table[] = {
     [0] = "poweroff",
     [1] = "reboot",
@@ -553,42 +605,29 @@ static char *req_table[] = {
 int libxl_domain_shutdown(libxl_ctx *ctx, uint32_t domid, int req)
 {
     GC_INIT(ctx);
-    char *shutdown_path;
-    char *dom_path;
+    int ret;
 
     if (req > ARRAY_SIZE(req_table)) {
         GC_FREE;
         return ERROR_INVAL;
     }
 
-    dom_path = libxl__xs_get_dompath(gc, domid);
-    if (!dom_path) {
-        GC_FREE;
-        return ERROR_FAIL;
+    ret = libxl__domain_pvcontrol_available(gc, domid);
+    if (ret < 0)
+        goto out;
+
+    if (!ret) {
+        LIBXL__LOG(CTX, LIBXL__LOG_ERROR, "PV shutdown control not available:"
+                   " graceful shutdown not possible, use destroy");
+        ret = ERROR_FAIL;
+        goto out;
     }
 
-    if (LIBXL__DOMAIN_IS_TYPE(gc,  domid, HVM)) {
-        unsigned long pvdriver = 0;
-        int ret;
-        ret = xc_get_hvm_param(ctx->xch, domid, HVM_PARAM_CALLBACK_IRQ, &pvdriver);
-        if (ret<0) {
-            LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "getting HVM callback IRQ");
-            GC_FREE;
-            return ERROR_FAIL;
-        }
-        if (!pvdriver) {
-            LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "HVM domain without PV drivers:"
-                       " graceful shutdown not possible, use destroy");
-            GC_FREE;
-            return ERROR_FAIL;
-        }
-    }
-
-    shutdown_path = libxl__sprintf(gc, "%s/control/shutdown", dom_path);
-    xs_write(ctx->xsh, XBT_NULL, shutdown_path, req_table[req], strlen(req_table[req]));
-
+    ret = libxl__domain_pvcontrol_write(gc, XBT_NULL, domid, req_table[req]);
+
+out:
     GC_FREE;
-    return 0;
+    return ret;
 }
 
 int libxl_get_wait_fd(libxl_ctx *ctx, int *fd)
diff -r 511748da941c -r 38902f8c4ef3 tools/libxl/libxl_dom.c
--- a/tools/libxl/libxl_dom.c	Fri Dec 16 09:34:43 2011 +0000
+++ b/tools/libxl/libxl_dom.c	Fri Dec 16 09:34:46 2011 +0000
@@ -415,7 +415,7 @@ static int libxl__domain_suspend_common_
     struct suspendinfo *si = data;
     unsigned long hvm_s_state = 0, hvm_pvdrv = 0;
     int ret;
-    char *path, *state = "suspend";
+    char *state = "suspend";
     int watchdog;
     libxl_ctx *ctx = libxl__gc_owner(si->gc);
     xs_transaction_t t;
@@ -451,15 +451,14 @@ static int libxl__domain_suspend_common_
         LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "issuing %s suspend request via XenBus control node",
                    si->hvm ? "PVHVM" : "PV");
 
-        path = libxl__sprintf(si->gc, "%s/control/shutdown", libxl__xs_get_dompath(si->gc, si->domid));
-        libxl__xs_write(si->gc, XBT_NULL, path, "suspend");
+        libxl__domain_pvcontrol_write(si->gc, XBT_NULL, si->domid, "suspend");
 
         LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "wait for the guest to acknowledge suspend request");
         watchdog = 60;
         while (!strcmp(state, "suspend") && watchdog > 0) {
             usleep(100000);
 
-            state = libxl__xs_read(si->gc, XBT_NULL, path);
+            state = libxl__domain_pvcontrol_read(si->gc, XBT_NULL, si->domid);
             if (!state) state = "";
 
             watchdog--;
@@ -479,11 +478,11 @@ static int libxl__domain_suspend_common_
         retry_transaction:
             t = xs_transaction_start(ctx->xsh);
 
-            state = libxl__xs_read(si->gc, t, path);
+            state = libxl__domain_pvcontrol_read(si->gc, t, si->domid);
             if (!state) state = "";
 
             if (!strcmp(state, "suspend"))
-                libxl__xs_write(si->gc, t, path, "");
+                libxl__domain_pvcontrol_write(si->gc, t, si->domid, "");
 
             if (!xs_transaction_end(ctx->xsh, t, 0))
                 if (errno == EAGAIN)
diff -r 511748da941c -r 38902f8c4ef3 tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Fri Dec 16 09:34:43 2011 +0000
+++ b/tools/libxl/libxl_internal.h	Fri Dec 16 09:34:46 2011 +0000
@@ -247,6 +247,12 @@ _hidden const char *libxl__device_model_
 _hidden int libxl__domain_save_device_model(libxl__gc *gc, uint32_t domid, int fd);
 _hidden void libxl__userdata_destroyall(libxl__gc *gc, uint32_t domid);
 
+_hidden int libxl__domain_pvcontrol_available(libxl__gc *gc, uint32_t domid);
+_hidden char * libxl__domain_pvcontrol_read(libxl__gc *gc,
+                                            xs_transaction_t t, uint32_t domid);
+_hidden int libxl__domain_pvcontrol_write(libxl__gc *gc, xs_transaction_t t,
+                                          uint32_t domid, const char *cmd);
+
 /* from xl_device */
 _hidden char *libxl__device_disk_string_of_backend(libxl_disk_backend backend);
 _hidden char *libxl__device_disk_string_of_format(libxl_disk_format format);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 09:52:18 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 09:52:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbUSL-0005qq-UE; Fri, 16 Dec 2011 09:51:57 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RbUSJ-0005qf-TK
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 09:51:56 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1324029078!52695198!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjI0MzY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13508 invoked from network); 16 Dec 2011 09:51:19 -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 2011 09:51:19 -0000
X-IronPort-AV: E=Sophos;i="4.71,362,1320642000"; d="scan'208";a="174424753"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Dec 2011 04:51:53 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 16 Dec 2011 04:51:52 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pBG9poq9005701;	Fri, 16 Dec 2011 01:51:51 -0800
MIME-Version: 1.0
X-Mercurial-Node: 38902f8c4ef37b841e1ec93b740108e0767aada4
Message-ID: <38902f8c4ef37b841e1e.1324029110@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1324029109@cosworth.uk.xensource.com>
References: <patchbomb.1324029109@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 16 Dec 2011 09:51:50 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 1 of 3 V2] libxl: add
 libxl__domain_pvcontrol_{available, read, write}
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1324028086 0
# Node ID 38902f8c4ef37b841e1ec93b740108e0767aada4
# Parent  511748da941c0d87f56e56ff05abfe860bd37689
libxl: add libxl__domain_pvcontrol_{available,read,write}

Use instead of open coding.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 511748da941c -r 38902f8c4ef3 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Fri Dec 16 09:34:43 2011 +0000
+++ b/tools/libxl/libxl.c	Fri Dec 16 09:34:46 2011 +0000
@@ -542,6 +542,58 @@ int libxl_domain_unpause(libxl_ctx *ctx,
     return rc;
 }
 
+int libxl__domain_pvcontrol_available(libxl__gc *gc, uint32_t domid)
+{
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+
+    unsigned long pvdriver = 0;
+    int ret;
+
+    if (LIBXL__DOMAIN_IS_TYPE(gc, domid, PV))
+        return 1;
+
+    ret = xc_get_hvm_param(ctx->xch, domid, HVM_PARAM_CALLBACK_IRQ, &pvdriver);
+    if (ret<0) {
+        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "getting HVM callback IRQ");
+        return ERROR_FAIL;
+    }
+    return !!pvdriver;
+}
+
+char * libxl__domain_pvcontrol_read(libxl__gc *gc, xs_transaction_t t,
+                                    uint32_t domid)
+{
+    const char *shutdown_path;
+    const char *dom_path;
+
+    dom_path = libxl__xs_get_dompath(gc, domid);
+    if (!dom_path)
+        return NULL;
+
+    shutdown_path = libxl__sprintf(gc, "%s/control/shutdown", dom_path);
+    if (!shutdown_path)
+        return NULL;
+
+    return libxl__xs_read(gc, t, shutdown_path);
+}
+
+int libxl__domain_pvcontrol_write(libxl__gc *gc, xs_transaction_t t,
+                                  uint32_t domid, const char *cmd)
+{
+    const char *shutdown_path;
+    const char *dom_path;
+
+    dom_path = libxl__xs_get_dompath(gc, domid);
+    if (!dom_path)
+        return ERROR_FAIL;
+
+    shutdown_path = libxl__sprintf(gc, "%s/control/shutdown", dom_path);
+    if (!shutdown_path)
+        return ERROR_FAIL;
+
+    return libxl__xs_write(gc, t, shutdown_path, "%s", cmd);
+}
+
 static char *req_table[] = {
     [0] = "poweroff",
     [1] = "reboot",
@@ -553,42 +605,29 @@ static char *req_table[] = {
 int libxl_domain_shutdown(libxl_ctx *ctx, uint32_t domid, int req)
 {
     GC_INIT(ctx);
-    char *shutdown_path;
-    char *dom_path;
+    int ret;
 
     if (req > ARRAY_SIZE(req_table)) {
         GC_FREE;
         return ERROR_INVAL;
     }
 
-    dom_path = libxl__xs_get_dompath(gc, domid);
-    if (!dom_path) {
-        GC_FREE;
-        return ERROR_FAIL;
+    ret = libxl__domain_pvcontrol_available(gc, domid);
+    if (ret < 0)
+        goto out;
+
+    if (!ret) {
+        LIBXL__LOG(CTX, LIBXL__LOG_ERROR, "PV shutdown control not available:"
+                   " graceful shutdown not possible, use destroy");
+        ret = ERROR_FAIL;
+        goto out;
     }
 
-    if (LIBXL__DOMAIN_IS_TYPE(gc,  domid, HVM)) {
-        unsigned long pvdriver = 0;
-        int ret;
-        ret = xc_get_hvm_param(ctx->xch, domid, HVM_PARAM_CALLBACK_IRQ, &pvdriver);
-        if (ret<0) {
-            LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "getting HVM callback IRQ");
-            GC_FREE;
-            return ERROR_FAIL;
-        }
-        if (!pvdriver) {
-            LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "HVM domain without PV drivers:"
-                       " graceful shutdown not possible, use destroy");
-            GC_FREE;
-            return ERROR_FAIL;
-        }
-    }
-
-    shutdown_path = libxl__sprintf(gc, "%s/control/shutdown", dom_path);
-    xs_write(ctx->xsh, XBT_NULL, shutdown_path, req_table[req], strlen(req_table[req]));
-
+    ret = libxl__domain_pvcontrol_write(gc, XBT_NULL, domid, req_table[req]);
+
+out:
     GC_FREE;
-    return 0;
+    return ret;
 }
 
 int libxl_get_wait_fd(libxl_ctx *ctx, int *fd)
diff -r 511748da941c -r 38902f8c4ef3 tools/libxl/libxl_dom.c
--- a/tools/libxl/libxl_dom.c	Fri Dec 16 09:34:43 2011 +0000
+++ b/tools/libxl/libxl_dom.c	Fri Dec 16 09:34:46 2011 +0000
@@ -415,7 +415,7 @@ static int libxl__domain_suspend_common_
     struct suspendinfo *si = data;
     unsigned long hvm_s_state = 0, hvm_pvdrv = 0;
     int ret;
-    char *path, *state = "suspend";
+    char *state = "suspend";
     int watchdog;
     libxl_ctx *ctx = libxl__gc_owner(si->gc);
     xs_transaction_t t;
@@ -451,15 +451,14 @@ static int libxl__domain_suspend_common_
         LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "issuing %s suspend request via XenBus control node",
                    si->hvm ? "PVHVM" : "PV");
 
-        path = libxl__sprintf(si->gc, "%s/control/shutdown", libxl__xs_get_dompath(si->gc, si->domid));
-        libxl__xs_write(si->gc, XBT_NULL, path, "suspend");
+        libxl__domain_pvcontrol_write(si->gc, XBT_NULL, si->domid, "suspend");
 
         LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "wait for the guest to acknowledge suspend request");
         watchdog = 60;
         while (!strcmp(state, "suspend") && watchdog > 0) {
             usleep(100000);
 
-            state = libxl__xs_read(si->gc, XBT_NULL, path);
+            state = libxl__domain_pvcontrol_read(si->gc, XBT_NULL, si->domid);
             if (!state) state = "";
 
             watchdog--;
@@ -479,11 +478,11 @@ static int libxl__domain_suspend_common_
         retry_transaction:
             t = xs_transaction_start(ctx->xsh);
 
-            state = libxl__xs_read(si->gc, t, path);
+            state = libxl__domain_pvcontrol_read(si->gc, t, si->domid);
             if (!state) state = "";
 
             if (!strcmp(state, "suspend"))
-                libxl__xs_write(si->gc, t, path, "");
+                libxl__domain_pvcontrol_write(si->gc, t, si->domid, "");
 
             if (!xs_transaction_end(ctx->xsh, t, 0))
                 if (errno == EAGAIN)
diff -r 511748da941c -r 38902f8c4ef3 tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Fri Dec 16 09:34:43 2011 +0000
+++ b/tools/libxl/libxl_internal.h	Fri Dec 16 09:34:46 2011 +0000
@@ -247,6 +247,12 @@ _hidden const char *libxl__device_model_
 _hidden int libxl__domain_save_device_model(libxl__gc *gc, uint32_t domid, int fd);
 _hidden void libxl__userdata_destroyall(libxl__gc *gc, uint32_t domid);
 
+_hidden int libxl__domain_pvcontrol_available(libxl__gc *gc, uint32_t domid);
+_hidden char * libxl__domain_pvcontrol_read(libxl__gc *gc,
+                                            xs_transaction_t t, uint32_t domid);
+_hidden int libxl__domain_pvcontrol_write(libxl__gc *gc, xs_transaction_t t,
+                                          uint32_t domid, const char *cmd);
+
 /* from xl_device */
 _hidden char *libxl__device_disk_string_of_backend(libxl_disk_backend backend);
 _hidden char *libxl__device_disk_string_of_format(libxl_disk_format format);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 09:52:18 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 09:52:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbUSQ-0005rC-9R; Fri, 16 Dec 2011 09:52:02 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RbUSO-0005qe-1O
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 09:52:00 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1324029112!5598672!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDc2NTY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7043 invoked from network); 16 Dec 2011 09:51:53 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Dec 2011 09:51:53 -0000
X-IronPort-AV: E=Sophos;i="4.71,362,1320642000"; d="scan'208";a="20032088"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Dec 2011 04:51:52 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 16 Dec 2011 04:51:51 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pBG9poq8005701;	Fri, 16 Dec 2011 01:51:51 -0800
MIME-Version: 1.0
Message-ID: <patchbomb.1324029109@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 16 Dec 2011 09:51:49 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 0 of 3 V2] libxl: domain shutdown cleanup
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

The existing libxl_domain_shutdown is a bit odd, it takes an integer
"req" which can be used to indicate one of:
  * [0] = "poweroff",
  * [1] = "reboot",
  * [2] = "suspend",
  * [3] = "crash",
  * [4] = "halt",

"suspend" is not usable via this interface since it requires other
scaffolding, libxl_domain_suspend provides this already.

"halt" is the same as "poweroff".

"crash" is unused and at least Linux does not implement it. If a user
steps forward then libxl_domain_crash is trivial to add.

Therefore split libxl_domain_shutdown into libxl_domain_shutdown and
libxl_domain_reboot corresponding to "poweroff" and "reboot"
respectively.

Also push responsibility for dealing with lack of PV drivers into the
caller and at the same time improve the error messages presented to
the user when they try and "xl shutdown/reboot" an HVM guest with no
PV drivers and the corresponding documentation.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 09:52:18 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 09:52:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbUSQ-0005rC-9R; Fri, 16 Dec 2011 09:52:02 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RbUSO-0005qe-1O
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 09:52:00 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1324029112!5598672!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDc2NTY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7043 invoked from network); 16 Dec 2011 09:51:53 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Dec 2011 09:51:53 -0000
X-IronPort-AV: E=Sophos;i="4.71,362,1320642000"; d="scan'208";a="20032088"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Dec 2011 04:51:52 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 16 Dec 2011 04:51:51 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pBG9poq8005701;	Fri, 16 Dec 2011 01:51:51 -0800
MIME-Version: 1.0
Message-ID: <patchbomb.1324029109@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 16 Dec 2011 09:51:49 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 0 of 3 V2] libxl: domain shutdown cleanup
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

The existing libxl_domain_shutdown is a bit odd, it takes an integer
"req" which can be used to indicate one of:
  * [0] = "poweroff",
  * [1] = "reboot",
  * [2] = "suspend",
  * [3] = "crash",
  * [4] = "halt",

"suspend" is not usable via this interface since it requires other
scaffolding, libxl_domain_suspend provides this already.

"halt" is the same as "poweroff".

"crash" is unused and at least Linux does not implement it. If a user
steps forward then libxl_domain_crash is trivial to add.

Therefore split libxl_domain_shutdown into libxl_domain_shutdown and
libxl_domain_reboot corresponding to "poweroff" and "reboot"
respectively.

Also push responsibility for dealing with lack of PV drivers into the
caller and at the same time improve the error messages presented to
the user when they try and "xl shutdown/reboot" an HVM guest with no
PV drivers and the corresponding documentation.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 09:52:18 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 09:52:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbUSM-0005qx-Ai; Fri, 16 Dec 2011 09:51:58 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RbUSK-0005qh-JP
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 09:51:56 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1324029078!52695198!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjI0MzY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13536 invoked from network); 16 Dec 2011 09:51:20 -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 2011 09:51:20 -0000
X-IronPort-AV: E=Sophos;i="4.71,362,1320642000"; d="scan'208";a="174424755"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Dec 2011 04:51:54 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 16 Dec 2011 04:51:54 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pBG9poqB005701;	Fri, 16 Dec 2011 01:51:53 -0800
MIME-Version: 1.0
X-Mercurial-Node: 5924514e0523e284ac12f06909d04d7cb35faa73
Message-ID: <5924514e0523e284ac12.1324029112@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1324029109@cosworth.uk.xensource.com>
References: <patchbomb.1324029109@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 16 Dec 2011 09:51:52 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 3 of 3 V2] libxl: report failure to
 reboot/shutdown due to lackof PV interfaces to caller
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1324028886 0
# Node ID 5924514e0523e284ac12f06909d04d7cb35faa73
# Parent  381829d0bb2b418a45962821718e824c353ae705
libxl: report failure to reboot/shutdown due to lackof PV interfaces to caller

This allow the caller to react as they think is appropriate. xl now prints a
message much like the library did previously, although hopefully somewhat more
informative.

Update the xl(1) man page to be similarly more informative.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 381829d0bb2b -r 5924514e0523 docs/man/xl.pod.1
--- a/docs/man/xl.pod.1	Fri Dec 16 09:47:27 2011 +0000
+++ b/docs/man/xl.pod.1	Fri Dec 16 09:48:06 2011 +0000
@@ -368,7 +368,11 @@ Reboot a domain.  This acts just as if t
 command run from the console.  The command returns as soon as it has
 executed the reboot action, which may be significantly before the
 domain actually reboots.
-It requires PV drivers installed in your guest OS.
+
+For HVM domains this requires PV drivers to be installed in your guest
+OS. If PV drivers are not present but you have configured the guest OS
+to behave appropriately you may be able to use the I<button-press>
+subcommand to trigger a power button press.
 
 The behavior of what happens to a domain when it reboots is set by the
 B<on_reboot> parameter of the domain configuration file when the
@@ -424,9 +428,15 @@ Leave domain running after creating the 
 Gracefully shuts down a domain.  This coordinates with the domain OS
 to perform graceful shutdown, so there is no guarantee that it will
 succeed, and may take a variable length of time depending on what
-services must be shutdown in the domain.  The command returns
-immediately after signally the domain unless that B<-w> flag is used.
-For HVM domains it requires PV drivers to be installed in your guest OS.
+services must be shutdown in the domain.
+
+For HVM domains this requires PV drivers to be installed in your guest
+OS. If PV drivers are not present but you have configured the guest OS
+to behave appropriately you may be able to use the I<button-press>
+subcommand to trigger a power button press.
+
+The command returns immediately after signally the domain unless that
+B<-w> flag is used.
 
 The behavior of what happens to a domain when it reboots is set by the
 B<on_shutdown> parameter of the domain configuration file when the
diff -r 381829d0bb2b -r 5924514e0523 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Fri Dec 16 09:47:27 2011 +0000
+++ b/tools/libxl/libxl.c	Fri Dec 16 09:48:06 2011 +0000
@@ -603,11 +603,8 @@ static int libxl__domain_pvcontrol(libxl
     if (ret < 0)
         return ret;
 
-    if (!ret) {
-        LIBXL__LOG(CTX, LIBXL__LOG_ERROR,
-                   "PV control interface not available\n");
-        return ERROR_FAIL;
-    }
+    if (!ret)
+        return ERROR_NOPARAVIRT;
 
     return libxl__domain_pvcontrol_write(gc, XBT_NULL, domid, cmd);
 }
diff -r 381829d0bb2b -r 5924514e0523 tools/libxl/libxl.h
--- a/tools/libxl/libxl.h	Fri Dec 16 09:47:27 2011 +0000
+++ b/tools/libxl/libxl.h	Fri Dec 16 09:48:06 2011 +0000
@@ -222,6 +222,7 @@ enum {
     ERROR_BADFAIL = -7,
     ERROR_GUEST_TIMEDOUT = -8,
     ERROR_TIMEDOUT = -9,
+    ERROR_NOPARAVIRT = -10,
 };
 
 #define LIBXL_VERSION 0
diff -r 381829d0bb2b -r 5924514e0523 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Fri Dec 16 09:47:27 2011 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Fri Dec 16 09:48:06 2011 +0000
@@ -2266,7 +2266,15 @@ static void shutdown_domain(const char *
 
     find_domain(p);
     rc=libxl_domain_shutdown(ctx, domid);
-    if (rc) { fprintf(stderr,"shutdown failed (rc=%d)\n",rc);exit(-1); }
+    if (rc) {
+        if (rc == ERROR_NOPARAVIRT) {
+            fprintf(stderr, "PV control interface not available:"
+                    " external graceful shutdown not possible.\n");
+            fprintf(stderr, "Use \"xl button-press <dom> power\" or"
+                    " \"xl destroy <dom>\".\n");
+        }
+        fprintf(stderr,"shutdown failed (rc=%d)\n",rc);exit(-1);
+    }
 
     if (wait) {
         libxl_waiter waiter;
@@ -2308,7 +2316,14 @@ static void reboot_domain(const char *p)
     int rc;
     find_domain(p);
     rc=libxl_domain_reboot(ctx, domid);
-    if (rc) { fprintf(stderr,"reboot failed (rc=%d)\n",rc);exit(-1); }
+    if (rc) {
+        if (rc == ERROR_NOPARAVIRT) {
+            fprintf(stderr, "PV control interface not available:"
+                    " external graceful reboot not possible.\n");
+            fprintf(stderr, "Use \"xl button-press <dom> power\" or"
+                    " \"xl destroy <dom>\".\n");
+        }
+        fprintf(stderr,"reboot failed (rc=%d)\n",rc);exit(-1); }
 }
 
 static void list_domains_details(const libxl_dominfo *info, int nb_domain)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 09:52:18 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 09:52:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbUSM-0005qx-Ai; Fri, 16 Dec 2011 09:51:58 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RbUSK-0005qh-JP
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 09:51:56 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1324029078!52695198!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjI0MzY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13536 invoked from network); 16 Dec 2011 09:51:20 -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 2011 09:51:20 -0000
X-IronPort-AV: E=Sophos;i="4.71,362,1320642000"; d="scan'208";a="174424755"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Dec 2011 04:51:54 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 16 Dec 2011 04:51:54 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pBG9poqB005701;	Fri, 16 Dec 2011 01:51:53 -0800
MIME-Version: 1.0
X-Mercurial-Node: 5924514e0523e284ac12f06909d04d7cb35faa73
Message-ID: <5924514e0523e284ac12.1324029112@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1324029109@cosworth.uk.xensource.com>
References: <patchbomb.1324029109@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 16 Dec 2011 09:51:52 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 3 of 3 V2] libxl: report failure to
 reboot/shutdown due to lackof PV interfaces to caller
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1324028886 0
# Node ID 5924514e0523e284ac12f06909d04d7cb35faa73
# Parent  381829d0bb2b418a45962821718e824c353ae705
libxl: report failure to reboot/shutdown due to lackof PV interfaces to caller

This allow the caller to react as they think is appropriate. xl now prints a
message much like the library did previously, although hopefully somewhat more
informative.

Update the xl(1) man page to be similarly more informative.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 381829d0bb2b -r 5924514e0523 docs/man/xl.pod.1
--- a/docs/man/xl.pod.1	Fri Dec 16 09:47:27 2011 +0000
+++ b/docs/man/xl.pod.1	Fri Dec 16 09:48:06 2011 +0000
@@ -368,7 +368,11 @@ Reboot a domain.  This acts just as if t
 command run from the console.  The command returns as soon as it has
 executed the reboot action, which may be significantly before the
 domain actually reboots.
-It requires PV drivers installed in your guest OS.
+
+For HVM domains this requires PV drivers to be installed in your guest
+OS. If PV drivers are not present but you have configured the guest OS
+to behave appropriately you may be able to use the I<button-press>
+subcommand to trigger a power button press.
 
 The behavior of what happens to a domain when it reboots is set by the
 B<on_reboot> parameter of the domain configuration file when the
@@ -424,9 +428,15 @@ Leave domain running after creating the 
 Gracefully shuts down a domain.  This coordinates with the domain OS
 to perform graceful shutdown, so there is no guarantee that it will
 succeed, and may take a variable length of time depending on what
-services must be shutdown in the domain.  The command returns
-immediately after signally the domain unless that B<-w> flag is used.
-For HVM domains it requires PV drivers to be installed in your guest OS.
+services must be shutdown in the domain.
+
+For HVM domains this requires PV drivers to be installed in your guest
+OS. If PV drivers are not present but you have configured the guest OS
+to behave appropriately you may be able to use the I<button-press>
+subcommand to trigger a power button press.
+
+The command returns immediately after signally the domain unless that
+B<-w> flag is used.
 
 The behavior of what happens to a domain when it reboots is set by the
 B<on_shutdown> parameter of the domain configuration file when the
diff -r 381829d0bb2b -r 5924514e0523 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Fri Dec 16 09:47:27 2011 +0000
+++ b/tools/libxl/libxl.c	Fri Dec 16 09:48:06 2011 +0000
@@ -603,11 +603,8 @@ static int libxl__domain_pvcontrol(libxl
     if (ret < 0)
         return ret;
 
-    if (!ret) {
-        LIBXL__LOG(CTX, LIBXL__LOG_ERROR,
-                   "PV control interface not available\n");
-        return ERROR_FAIL;
-    }
+    if (!ret)
+        return ERROR_NOPARAVIRT;
 
     return libxl__domain_pvcontrol_write(gc, XBT_NULL, domid, cmd);
 }
diff -r 381829d0bb2b -r 5924514e0523 tools/libxl/libxl.h
--- a/tools/libxl/libxl.h	Fri Dec 16 09:47:27 2011 +0000
+++ b/tools/libxl/libxl.h	Fri Dec 16 09:48:06 2011 +0000
@@ -222,6 +222,7 @@ enum {
     ERROR_BADFAIL = -7,
     ERROR_GUEST_TIMEDOUT = -8,
     ERROR_TIMEDOUT = -9,
+    ERROR_NOPARAVIRT = -10,
 };
 
 #define LIBXL_VERSION 0
diff -r 381829d0bb2b -r 5924514e0523 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Fri Dec 16 09:47:27 2011 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Fri Dec 16 09:48:06 2011 +0000
@@ -2266,7 +2266,15 @@ static void shutdown_domain(const char *
 
     find_domain(p);
     rc=libxl_domain_shutdown(ctx, domid);
-    if (rc) { fprintf(stderr,"shutdown failed (rc=%d)\n",rc);exit(-1); }
+    if (rc) {
+        if (rc == ERROR_NOPARAVIRT) {
+            fprintf(stderr, "PV control interface not available:"
+                    " external graceful shutdown not possible.\n");
+            fprintf(stderr, "Use \"xl button-press <dom> power\" or"
+                    " \"xl destroy <dom>\".\n");
+        }
+        fprintf(stderr,"shutdown failed (rc=%d)\n",rc);exit(-1);
+    }
 
     if (wait) {
         libxl_waiter waiter;
@@ -2308,7 +2316,14 @@ static void reboot_domain(const char *p)
     int rc;
     find_domain(p);
     rc=libxl_domain_reboot(ctx, domid);
-    if (rc) { fprintf(stderr,"reboot failed (rc=%d)\n",rc);exit(-1); }
+    if (rc) {
+        if (rc == ERROR_NOPARAVIRT) {
+            fprintf(stderr, "PV control interface not available:"
+                    " external graceful reboot not possible.\n");
+            fprintf(stderr, "Use \"xl button-press <dom> power\" or"
+                    " \"xl destroy <dom>\".\n");
+        }
+        fprintf(stderr,"reboot failed (rc=%d)\n",rc);exit(-1); }
 }
 
 static void list_domains_details(const libxl_dominfo *info, int nb_domain)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 09:52:19 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 09:52:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbUSR-0005rT-Mz; Fri, 16 Dec 2011 09:52:03 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RbUSP-0005qg-2C
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 09:52:02 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1324029112!5598672!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDc2NTY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7087 invoked from network); 16 Dec 2011 09:51:54 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Dec 2011 09:51:54 -0000
X-IronPort-AV: E=Sophos;i="4.71,362,1320642000"; d="scan'208";a="20032089"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Dec 2011 04:51:53 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 16 Dec 2011 04:51:53 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pBG9poqA005701;	Fri, 16 Dec 2011 01:51:52 -0800
MIME-Version: 1.0
X-Mercurial-Node: 381829d0bb2b418a45962821718e824c353ae705
Message-ID: <381829d0bb2b418a4596.1324029111@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1324029109@cosworth.uk.xensource.com>
References: <patchbomb.1324029109@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 16 Dec 2011 09:51:51 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 2 of 3 V2] libxl: split libxl_domain_shutdown
 into libxl_domain_shutdown & libxl_domain_reboot
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1324028847 0
# Node ID 381829d0bb2b418a45962821718e824c353ae705
# Parent  38902f8c4ef37b841e1ec93b740108e0767aada4
libxl: split libxl_domain_shutdown into libxl_domain_shutdown & libxl_domain_reboot

The other integer request types which shutdown supported are not useful. Specifically:

 * "suspend" is not usable via this interface since it requires other
   scaffolding, libxl_domain_suspend provides this already.
 * "halt" is the same as "poweroff".
 * "crash" is unused and at least Linux does not implement it. If a user
   steps forward then libxl_domain_crash is trivial to add.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 38902f8c4ef3 -r 381829d0bb2b tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Fri Dec 16 09:34:46 2011 +0000
+++ b/tools/libxl/libxl.c	Fri Dec 16 09:47:27 2011 +0000
@@ -594,38 +594,38 @@ int libxl__domain_pvcontrol_write(libxl_
     return libxl__xs_write(gc, t, shutdown_path, "%s", cmd);
 }
 
-static char *req_table[] = {
-    [0] = "poweroff",
-    [1] = "reboot",
-    [2] = "suspend",
-    [3] = "crash",
-    [4] = "halt",
-};
-
-int libxl_domain_shutdown(libxl_ctx *ctx, uint32_t domid, int req)
+static int libxl__domain_pvcontrol(libxl__gc *gc, uint32_t domid,
+                                   const char *cmd)
+{
+    int ret;
+
+    ret = libxl__domain_pvcontrol_available(gc, domid);
+    if (ret < 0)
+        return ret;
+
+    if (!ret) {
+        LIBXL__LOG(CTX, LIBXL__LOG_ERROR,
+                   "PV control interface not available\n");
+        return ERROR_FAIL;
+    }
+
+    return libxl__domain_pvcontrol_write(gc, XBT_NULL, domid, cmd);
+}
+
+int libxl_domain_shutdown(libxl_ctx *ctx, uint32_t domid)
 {
     GC_INIT(ctx);
     int ret;
-
-    if (req > ARRAY_SIZE(req_table)) {
-        GC_FREE;
-        return ERROR_INVAL;
-    }
-
-    ret = libxl__domain_pvcontrol_available(gc, domid);
-    if (ret < 0)
-        goto out;
-
-    if (!ret) {
-        LIBXL__LOG(CTX, LIBXL__LOG_ERROR, "PV shutdown control not available:"
-                   " graceful shutdown not possible, use destroy");
-        ret = ERROR_FAIL;
-        goto out;
-    }
-
-    ret = libxl__domain_pvcontrol_write(gc, XBT_NULL, domid, req_table[req]);
-
-out:
+    ret = libxl__domain_pvcontrol(gc, domid, "poweroff");
+    GC_FREE;
+    return ret;
+}
+
+int libxl_domain_reboot(libxl_ctx *ctx, uint32_t domid)
+{
+    GC_INIT(ctx);
+    int ret;
+    ret = libxl__domain_pvcontrol(gc, domid, "reboot");
     GC_FREE;
     return ret;
 }
diff -r 38902f8c4ef3 -r 381829d0bb2b tools/libxl/libxl.h
--- a/tools/libxl/libxl.h	Fri Dec 16 09:34:46 2011 +0000
+++ b/tools/libxl/libxl.h	Fri Dec 16 09:47:27 2011 +0000
@@ -268,7 +268,8 @@ void libxl_domain_config_dispose(libxl_d
 int libxl_domain_suspend(libxl_ctx *ctx, libxl_domain_suspend_info *info,
                           uint32_t domid, int fd);
 int libxl_domain_resume(libxl_ctx *ctx, uint32_t domid);
-int libxl_domain_shutdown(libxl_ctx *ctx, uint32_t domid, int req);
+int libxl_domain_shutdown(libxl_ctx *ctx, uint32_t domid);
+int libxl_domain_reboot(libxl_ctx *ctx, uint32_t domid);
 int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid, int force);
 int libxl_domain_preserve(libxl_ctx *ctx, uint32_t domid, libxl_domain_create_info *info, const char *name_suffix, libxl_uuid new_uuid);
 
diff -r 38902f8c4ef3 -r 381829d0bb2b tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Fri Dec 16 09:34:46 2011 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Fri Dec 16 09:47:27 2011 +0000
@@ -2265,7 +2265,7 @@ static void shutdown_domain(const char *
     int rc;
 
     find_domain(p);
-    rc=libxl_domain_shutdown(ctx, domid, 0);
+    rc=libxl_domain_shutdown(ctx, domid);
     if (rc) { fprintf(stderr,"shutdown failed (rc=%d)\n",rc);exit(-1); }
 
     if (wait) {
@@ -2307,7 +2307,7 @@ static void reboot_domain(const char *p)
 {
     int rc;
     find_domain(p);
-    rc=libxl_domain_shutdown(ctx, domid, 1);
+    rc=libxl_domain_reboot(ctx, domid);
     if (rc) { fprintf(stderr,"reboot failed (rc=%d)\n",rc);exit(-1); }
 }
 
diff -r 38902f8c4ef3 -r 381829d0bb2b tools/python/xen/lowlevel/xl/xl.c
--- a/tools/python/xen/lowlevel/xl/xl.c	Fri Dec 16 09:34:46 2011 +0000
+++ b/tools/python/xen/lowlevel/xl/xl.c	Fri Dec 16 09:47:27 2011 +0000
@@ -424,10 +424,10 @@ static PyObject *pyxl_domid_to_name(XlOb
 
 static PyObject *pyxl_domain_shutdown(XlObject *self, PyObject *args)
 {
-    int domid, req = 0;
-    if ( !PyArg_ParseTuple(args, "i|i", &domid, &req) )
+    int domid;
+    if ( !PyArg_ParseTuple(args, "i", &domid) )
         return NULL;
-    if ( libxl_domain_shutdown(self->ctx, domid, req) ) {
+    if ( libxl_domain_shutdown(self->ctx, domid) ) {
         PyErr_SetString(xl_error_obj, "cannot shutdown domain");
         return NULL;
     }
@@ -435,6 +435,19 @@ static PyObject *pyxl_domain_shutdown(Xl
     return Py_None;
 }
 
+static PyObject *pyxl_domain_reboot(XlObject *self, PyObject *args)
+{
+    int domid;
+    if ( !PyArg_ParseTuple(args, "i", &domid) )
+        return NULL;
+    if ( libxl_domain_reboot(self->ctx, domid) ) {
+        PyErr_SetString(xl_error_obj, "cannot reboot domain");
+        return NULL;
+    }
+    Py_INCREF(Py_None);
+    return Py_None;
+}
+
 static PyObject *pyxl_domain_destroy(XlObject *self, PyObject *args)
 {
     int domid, force = 1;
@@ -637,6 +650,8 @@ static PyMethodDef pyxl_methods[] = {
          "Retrieve name from domain-id"},
     {"domain_shutdown", (PyCFunction)pyxl_domain_shutdown, METH_VARARGS,
          "Shutdown a domain"},
+    {"domain_reboot", (PyCFunction)pyxl_domain_reboot, METH_VARARGS,
+         "Reboot a domain"},
     {"domain_destroy", (PyCFunction)pyxl_domain_destroy, METH_VARARGS,
          "Destroy a domain"},
     {"domain_pause", (PyCFunction)pyxl_domain_pause, METH_VARARGS,

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 09:52:19 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 09:52:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbUSR-0005rT-Mz; Fri, 16 Dec 2011 09:52:03 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RbUSP-0005qg-2C
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 09:52:02 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1324029112!5598672!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDc2NTY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7087 invoked from network); 16 Dec 2011 09:51:54 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Dec 2011 09:51:54 -0000
X-IronPort-AV: E=Sophos;i="4.71,362,1320642000"; d="scan'208";a="20032089"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Dec 2011 04:51:53 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 16 Dec 2011 04:51:53 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pBG9poqA005701;	Fri, 16 Dec 2011 01:51:52 -0800
MIME-Version: 1.0
X-Mercurial-Node: 381829d0bb2b418a45962821718e824c353ae705
Message-ID: <381829d0bb2b418a4596.1324029111@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1324029109@cosworth.uk.xensource.com>
References: <patchbomb.1324029109@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 16 Dec 2011 09:51:51 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 2 of 3 V2] libxl: split libxl_domain_shutdown
 into libxl_domain_shutdown & libxl_domain_reboot
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1324028847 0
# Node ID 381829d0bb2b418a45962821718e824c353ae705
# Parent  38902f8c4ef37b841e1ec93b740108e0767aada4
libxl: split libxl_domain_shutdown into libxl_domain_shutdown & libxl_domain_reboot

The other integer request types which shutdown supported are not useful. Specifically:

 * "suspend" is not usable via this interface since it requires other
   scaffolding, libxl_domain_suspend provides this already.
 * "halt" is the same as "poweroff".
 * "crash" is unused and at least Linux does not implement it. If a user
   steps forward then libxl_domain_crash is trivial to add.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 38902f8c4ef3 -r 381829d0bb2b tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Fri Dec 16 09:34:46 2011 +0000
+++ b/tools/libxl/libxl.c	Fri Dec 16 09:47:27 2011 +0000
@@ -594,38 +594,38 @@ int libxl__domain_pvcontrol_write(libxl_
     return libxl__xs_write(gc, t, shutdown_path, "%s", cmd);
 }
 
-static char *req_table[] = {
-    [0] = "poweroff",
-    [1] = "reboot",
-    [2] = "suspend",
-    [3] = "crash",
-    [4] = "halt",
-};
-
-int libxl_domain_shutdown(libxl_ctx *ctx, uint32_t domid, int req)
+static int libxl__domain_pvcontrol(libxl__gc *gc, uint32_t domid,
+                                   const char *cmd)
+{
+    int ret;
+
+    ret = libxl__domain_pvcontrol_available(gc, domid);
+    if (ret < 0)
+        return ret;
+
+    if (!ret) {
+        LIBXL__LOG(CTX, LIBXL__LOG_ERROR,
+                   "PV control interface not available\n");
+        return ERROR_FAIL;
+    }
+
+    return libxl__domain_pvcontrol_write(gc, XBT_NULL, domid, cmd);
+}
+
+int libxl_domain_shutdown(libxl_ctx *ctx, uint32_t domid)
 {
     GC_INIT(ctx);
     int ret;
-
-    if (req > ARRAY_SIZE(req_table)) {
-        GC_FREE;
-        return ERROR_INVAL;
-    }
-
-    ret = libxl__domain_pvcontrol_available(gc, domid);
-    if (ret < 0)
-        goto out;
-
-    if (!ret) {
-        LIBXL__LOG(CTX, LIBXL__LOG_ERROR, "PV shutdown control not available:"
-                   " graceful shutdown not possible, use destroy");
-        ret = ERROR_FAIL;
-        goto out;
-    }
-
-    ret = libxl__domain_pvcontrol_write(gc, XBT_NULL, domid, req_table[req]);
-
-out:
+    ret = libxl__domain_pvcontrol(gc, domid, "poweroff");
+    GC_FREE;
+    return ret;
+}
+
+int libxl_domain_reboot(libxl_ctx *ctx, uint32_t domid)
+{
+    GC_INIT(ctx);
+    int ret;
+    ret = libxl__domain_pvcontrol(gc, domid, "reboot");
     GC_FREE;
     return ret;
 }
diff -r 38902f8c4ef3 -r 381829d0bb2b tools/libxl/libxl.h
--- a/tools/libxl/libxl.h	Fri Dec 16 09:34:46 2011 +0000
+++ b/tools/libxl/libxl.h	Fri Dec 16 09:47:27 2011 +0000
@@ -268,7 +268,8 @@ void libxl_domain_config_dispose(libxl_d
 int libxl_domain_suspend(libxl_ctx *ctx, libxl_domain_suspend_info *info,
                           uint32_t domid, int fd);
 int libxl_domain_resume(libxl_ctx *ctx, uint32_t domid);
-int libxl_domain_shutdown(libxl_ctx *ctx, uint32_t domid, int req);
+int libxl_domain_shutdown(libxl_ctx *ctx, uint32_t domid);
+int libxl_domain_reboot(libxl_ctx *ctx, uint32_t domid);
 int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid, int force);
 int libxl_domain_preserve(libxl_ctx *ctx, uint32_t domid, libxl_domain_create_info *info, const char *name_suffix, libxl_uuid new_uuid);
 
diff -r 38902f8c4ef3 -r 381829d0bb2b tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Fri Dec 16 09:34:46 2011 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Fri Dec 16 09:47:27 2011 +0000
@@ -2265,7 +2265,7 @@ static void shutdown_domain(const char *
     int rc;
 
     find_domain(p);
-    rc=libxl_domain_shutdown(ctx, domid, 0);
+    rc=libxl_domain_shutdown(ctx, domid);
     if (rc) { fprintf(stderr,"shutdown failed (rc=%d)\n",rc);exit(-1); }
 
     if (wait) {
@@ -2307,7 +2307,7 @@ static void reboot_domain(const char *p)
 {
     int rc;
     find_domain(p);
-    rc=libxl_domain_shutdown(ctx, domid, 1);
+    rc=libxl_domain_reboot(ctx, domid);
     if (rc) { fprintf(stderr,"reboot failed (rc=%d)\n",rc);exit(-1); }
 }
 
diff -r 38902f8c4ef3 -r 381829d0bb2b tools/python/xen/lowlevel/xl/xl.c
--- a/tools/python/xen/lowlevel/xl/xl.c	Fri Dec 16 09:34:46 2011 +0000
+++ b/tools/python/xen/lowlevel/xl/xl.c	Fri Dec 16 09:47:27 2011 +0000
@@ -424,10 +424,10 @@ static PyObject *pyxl_domid_to_name(XlOb
 
 static PyObject *pyxl_domain_shutdown(XlObject *self, PyObject *args)
 {
-    int domid, req = 0;
-    if ( !PyArg_ParseTuple(args, "i|i", &domid, &req) )
+    int domid;
+    if ( !PyArg_ParseTuple(args, "i", &domid) )
         return NULL;
-    if ( libxl_domain_shutdown(self->ctx, domid, req) ) {
+    if ( libxl_domain_shutdown(self->ctx, domid) ) {
         PyErr_SetString(xl_error_obj, "cannot shutdown domain");
         return NULL;
     }
@@ -435,6 +435,19 @@ static PyObject *pyxl_domain_shutdown(Xl
     return Py_None;
 }
 
+static PyObject *pyxl_domain_reboot(XlObject *self, PyObject *args)
+{
+    int domid;
+    if ( !PyArg_ParseTuple(args, "i", &domid) )
+        return NULL;
+    if ( libxl_domain_reboot(self->ctx, domid) ) {
+        PyErr_SetString(xl_error_obj, "cannot reboot domain");
+        return NULL;
+    }
+    Py_INCREF(Py_None);
+    return Py_None;
+}
+
 static PyObject *pyxl_domain_destroy(XlObject *self, PyObject *args)
 {
     int domid, force = 1;
@@ -637,6 +650,8 @@ static PyMethodDef pyxl_methods[] = {
          "Retrieve name from domain-id"},
     {"domain_shutdown", (PyCFunction)pyxl_domain_shutdown, METH_VARARGS,
          "Shutdown a domain"},
+    {"domain_reboot", (PyCFunction)pyxl_domain_reboot, METH_VARARGS,
+         "Reboot a domain"},
     {"domain_destroy", (PyCFunction)pyxl_domain_destroy, METH_VARARGS,
          "Destroy a domain"},
     {"domain_pause", (PyCFunction)pyxl_domain_pause, METH_VARARGS,

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 09:56:09 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 09: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.xensource.com>)
	id 1RbUW8-0006LB-KO; Fri, 16 Dec 2011 09:55:52 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RbUW6-0006Jz-NM
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 09:55:50 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1324029344!8199024!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjU3OQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7171 invoked from network); 16 Dec 2011 09:55:44 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Dec 2011 09:55:44 -0000
X-IronPort-AV: E=Sophos;i="4.71,362,1320624000"; 
   d="scan'208";a="9508454"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Dec 2011 09:55:43 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 16 Dec 2011 09:55:43 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Fri, 16 Dec 2011 09:55:43 +0000
In-Reply-To: <patchbomb.1324029109@cosworth.uk.xensource.com>
References: <patchbomb.1324029109@cosworth.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1324029343.20077.537.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 0 of 3 V2] libxl: domain shutdown cleanup
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2011-12-16 at 09:51 +0000, Ian Campbell wrote:
> The existing libxl_domain_shutdown is a bit odd, it takes an integer
> "req" which can be used to indicate one of:
>   * [0] = "poweroff",
>   * [1] = "reboot",
>   * [2] = "suspend",
>   * [3] = "crash",
>   * [4] = "halt",
> 
> "suspend" is not usable via this interface since it requires other
> scaffolding, libxl_domain_suspend provides this already.
> 
> "halt" is the same as "poweroff".
> 
> "crash" is unused and at least Linux does not implement it. If a user
> steps forward then libxl_domain_crash is trivial to add.
> 
> Therefore split libxl_domain_shutdown into libxl_domain_shutdown and
> libxl_domain_reboot corresponding to "poweroff" and "reboot"
> respectively.
> 
> Also push responsibility for dealing with lack of PV drivers into the
> caller and at the same time improve the error messages presented to
> the user when they try and "xl shutdown/reboot" an HVM guest with no
> PV drivers and the corresponding documentation.

Forgot to save before hg email, should have said:

Changes since last time:
  - Remove massive redundancy in libxl_domain_{shutdown,reboot}

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 09:56:09 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 09: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.xensource.com>)
	id 1RbUW8-0006LB-KO; Fri, 16 Dec 2011 09:55:52 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RbUW6-0006Jz-NM
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 09:55:50 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1324029344!8199024!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjU3OQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7171 invoked from network); 16 Dec 2011 09:55:44 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Dec 2011 09:55:44 -0000
X-IronPort-AV: E=Sophos;i="4.71,362,1320624000"; 
   d="scan'208";a="9508454"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Dec 2011 09:55:43 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 16 Dec 2011 09:55:43 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Fri, 16 Dec 2011 09:55:43 +0000
In-Reply-To: <patchbomb.1324029109@cosworth.uk.xensource.com>
References: <patchbomb.1324029109@cosworth.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1324029343.20077.537.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 0 of 3 V2] libxl: domain shutdown cleanup
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2011-12-16 at 09:51 +0000, Ian Campbell wrote:
> The existing libxl_domain_shutdown is a bit odd, it takes an integer
> "req" which can be used to indicate one of:
>   * [0] = "poweroff",
>   * [1] = "reboot",
>   * [2] = "suspend",
>   * [3] = "crash",
>   * [4] = "halt",
> 
> "suspend" is not usable via this interface since it requires other
> scaffolding, libxl_domain_suspend provides this already.
> 
> "halt" is the same as "poweroff".
> 
> "crash" is unused and at least Linux does not implement it. If a user
> steps forward then libxl_domain_crash is trivial to add.
> 
> Therefore split libxl_domain_shutdown into libxl_domain_shutdown and
> libxl_domain_reboot corresponding to "poweroff" and "reboot"
> respectively.
> 
> Also push responsibility for dealing with lack of PV drivers into the
> caller and at the same time improve the error messages presented to
> the user when they try and "xl shutdown/reboot" an HVM guest with no
> PV drivers and the corresponding documentation.

Forgot to save before hg email, should have said:

Changes since last time:
  - Remove massive redundancy in libxl_domain_{shutdown,reboot}

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 10:31:31 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 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.xensource.com>)
	id 1RbV4B-0007AS-To; Fri, 16 Dec 2011 10:31:03 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Wang2@amd.com>) id 1RbV4A-0007AM-Nc
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 10:31:02 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1324031455!8358203!1
X-Originating-IP: [216.32.180.16]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25029 invoked from network); 16 Dec 2011 10:30:56 -0000
Received: from va3ehsobe006.messaging.microsoft.com (HELO
	VA3EHSOBE009.bigfish.com) (216.32.180.16)
	by server-12.tower-21.messagelabs.com with AES128-SHA encrypted SMTP;
	16 Dec 2011 10:30:56 -0000
Received: from mail22-va3-R.bigfish.com (10.7.14.254) by
	VA3EHSOBE009.bigfish.com (10.7.40.29) with Microsoft SMTP Server id
	14.1.225.23; Fri, 16 Dec 2011 10:30:54 +0000
Received: from mail22-va3 (localhost [127.0.0.1])	by mail22-va3-R.bigfish.com
	(Postfix) with ESMTP id 06BBA1C03EC;
	Fri, 16 Dec 2011 10:31:03 +0000 (UTC)
X-SpamScore: -18
X-BigFish: VPS-18(zz1447M1432N98dK4015Lzz1202hzzz2dh668h839h61h)
X-Spam-TCS-SCL: 0:0
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
X-FB-SS: 0,
Received: from mail22-va3 (localhost.localdomain [127.0.0.1]) by mail22-va3
	(MessageSwitch) id 1324031440976286_31427;
	Fri, 16 Dec 2011 10:30:40 +0000 (UTC)
Received: from VA3EHSMHS001.bigfish.com (unknown [10.7.14.246])	by
	mail22-va3.bigfish.com (Postfix) with ESMTP id E68B7600043;
	Fri, 16 Dec 2011 10:30:40 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	VA3EHSMHS001.bigfish.com (10.7.99.11) with Microsoft SMTP Server id
	14.1.225.23; Fri, 16 Dec 2011 10:30:32 +0000
X-WSS-ID: 0LWAL6U-01-AFH-02
X-M-MSG: 
Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com
	[163.181.249.73])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2F93F1028062;	Fri, 16 Dec 2011 04:30:29 -0600 (CST)
Received: from SAUSEXDAG03.amd.com (163.181.55.3) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Fri, 16 Dec 2011 04:30:47 -0600
Received: from storexhtp01.amd.com (172.24.4.3) by sausexdag03.amd.com
	(163.181.55.3) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Fri, 16 Dec 2011 04:30:29 -0600
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp01.amd.com
	(172.24.4.3) with Microsoft SMTP Server id 8.3.213.0; Fri, 16 Dec 2011
	05:30:28 -0500
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id D6CEC49C0F1; Fri, 16 Dec 2011
	10:30:27 +0000 (GMT)
Received: from gran.osrc.amd.com (gran.osrc.amd.com [165.204.15.57])	by
	mail.osrc.amd.com (Postfix) with ESMTP id C18655940FF; Fri, 16 Dec 2011
	11:30:27 +0100 (CET)
From: Wei Wang2 <wei.wang2@amd.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Fri, 16 Dec 2011 11:33:10 +0100
User-Agent: KMail/1.9.6 (enterprise 20070904.708012)
References: <201112141638.05345.wei.wang2@amd.com>
	<20202.12141.174045.345822@mariner.uk.xensource.com>
In-Reply-To: <20202.12141.174045.345822@mariner.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
Message-ID: <201112161133.10811.wei.wang2@amd.com>
X-OriginatorOrg: amd.com
Cc: Anthony PERARD <anthony.perard@citrix.com>, xen-devel@lists.xensource.com,
	Keir Fraser <keir@xen.org>, qemu-devel@nongnu.org,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH] xen-qemu: register virtual iommu device on
	qemu pci bus
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thursday 15 December 2011 18:33:33 Ian Jackson wrote:
> Wei Wang2 writes ("[Xen-devel] [PATCH] xen-qemu: register virtual iommu 
device on qemu pci bus"):
> > Attached patch is for qemu to register iommu device on pci bus. Guest OS
> > requires this to access iommu pci config space in some cases.
>
> Thanks for this submission.
>
> However, we are trying to focus development on the new xen-supporting
> upstream qemu branches.
>
> This old qemu branch is basically dead.  We will have to give it
> bugfixes and security fixes, it in parallel with the new trees, for a
> long time (because old guests may need it).  So for that reason I
> would really prefer not to add new features to it.
>
> Would you be able to rebase your work on the upstream qemu ?  You will
> need Anthony Perard's PCI passthrough series of course, and you will
> also need to liase with qemu upstream (so I've CC'd their list) since
> it will be their tree that you'll be targeting.
>
> If there is a particular reason why this work should be in
> qemu-xen-unstable then please do say.  I'm open to being persuaded.
>
> Thanks,
> Ian.
Sure, I will do that. Thanks for the suggestion
Wei.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 10:31:31 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 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.xensource.com>)
	id 1RbV4B-0007AS-To; Fri, 16 Dec 2011 10:31:03 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Wang2@amd.com>) id 1RbV4A-0007AM-Nc
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 10:31:02 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1324031455!8358203!1
X-Originating-IP: [216.32.180.16]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25029 invoked from network); 16 Dec 2011 10:30:56 -0000
Received: from va3ehsobe006.messaging.microsoft.com (HELO
	VA3EHSOBE009.bigfish.com) (216.32.180.16)
	by server-12.tower-21.messagelabs.com with AES128-SHA encrypted SMTP;
	16 Dec 2011 10:30:56 -0000
Received: from mail22-va3-R.bigfish.com (10.7.14.254) by
	VA3EHSOBE009.bigfish.com (10.7.40.29) with Microsoft SMTP Server id
	14.1.225.23; Fri, 16 Dec 2011 10:30:54 +0000
Received: from mail22-va3 (localhost [127.0.0.1])	by mail22-va3-R.bigfish.com
	(Postfix) with ESMTP id 06BBA1C03EC;
	Fri, 16 Dec 2011 10:31:03 +0000 (UTC)
X-SpamScore: -18
X-BigFish: VPS-18(zz1447M1432N98dK4015Lzz1202hzzz2dh668h839h61h)
X-Spam-TCS-SCL: 0:0
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
X-FB-SS: 0,
Received: from mail22-va3 (localhost.localdomain [127.0.0.1]) by mail22-va3
	(MessageSwitch) id 1324031440976286_31427;
	Fri, 16 Dec 2011 10:30:40 +0000 (UTC)
Received: from VA3EHSMHS001.bigfish.com (unknown [10.7.14.246])	by
	mail22-va3.bigfish.com (Postfix) with ESMTP id E68B7600043;
	Fri, 16 Dec 2011 10:30:40 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	VA3EHSMHS001.bigfish.com (10.7.99.11) with Microsoft SMTP Server id
	14.1.225.23; Fri, 16 Dec 2011 10:30:32 +0000
X-WSS-ID: 0LWAL6U-01-AFH-02
X-M-MSG: 
Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com
	[163.181.249.73])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2F93F1028062;	Fri, 16 Dec 2011 04:30:29 -0600 (CST)
Received: from SAUSEXDAG03.amd.com (163.181.55.3) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Fri, 16 Dec 2011 04:30:47 -0600
Received: from storexhtp01.amd.com (172.24.4.3) by sausexdag03.amd.com
	(163.181.55.3) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Fri, 16 Dec 2011 04:30:29 -0600
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp01.amd.com
	(172.24.4.3) with Microsoft SMTP Server id 8.3.213.0; Fri, 16 Dec 2011
	05:30:28 -0500
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id D6CEC49C0F1; Fri, 16 Dec 2011
	10:30:27 +0000 (GMT)
Received: from gran.osrc.amd.com (gran.osrc.amd.com [165.204.15.57])	by
	mail.osrc.amd.com (Postfix) with ESMTP id C18655940FF; Fri, 16 Dec 2011
	11:30:27 +0100 (CET)
From: Wei Wang2 <wei.wang2@amd.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Fri, 16 Dec 2011 11:33:10 +0100
User-Agent: KMail/1.9.6 (enterprise 20070904.708012)
References: <201112141638.05345.wei.wang2@amd.com>
	<20202.12141.174045.345822@mariner.uk.xensource.com>
In-Reply-To: <20202.12141.174045.345822@mariner.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
Message-ID: <201112161133.10811.wei.wang2@amd.com>
X-OriginatorOrg: amd.com
Cc: Anthony PERARD <anthony.perard@citrix.com>, xen-devel@lists.xensource.com,
	Keir Fraser <keir@xen.org>, qemu-devel@nongnu.org,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH] xen-qemu: register virtual iommu device on
	qemu pci bus
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thursday 15 December 2011 18:33:33 Ian Jackson wrote:
> Wei Wang2 writes ("[Xen-devel] [PATCH] xen-qemu: register virtual iommu 
device on qemu pci bus"):
> > Attached patch is for qemu to register iommu device on pci bus. Guest OS
> > requires this to access iommu pci config space in some cases.
>
> Thanks for this submission.
>
> However, we are trying to focus development on the new xen-supporting
> upstream qemu branches.
>
> This old qemu branch is basically dead.  We will have to give it
> bugfixes and security fixes, it in parallel with the new trees, for a
> long time (because old guests may need it).  So for that reason I
> would really prefer not to add new features to it.
>
> Would you be able to rebase your work on the upstream qemu ?  You will
> need Anthony Perard's PCI passthrough series of course, and you will
> also need to liase with qemu upstream (so I've CC'd their list) since
> it will be their tree that you'll be targeting.
>
> If there is a particular reason why this work should be in
> qemu-xen-unstable then please do say.  I'm open to being persuaded.
>
> Thanks,
> Ian.
Sure, I will do that. Thanks for the suggestion
Wei.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 10:37:39 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 10:37:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbVA9-0007Ou-ST; Fri, 16 Dec 2011 10:37:13 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RbVA8-0007Od-EF
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 10:37:12 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1324031826!7722541!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjU3OQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28923 invoked from network); 16 Dec 2011 10:37:06 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Dec 2011 10:37:06 -0000
X-IronPort-AV: E=Sophos;i="4.71,362,1320624000"; 
   d="scan'208";a="9509573"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Dec 2011 10:37:05 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 16 Dec 2011 10:37:05 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Fri, 16 Dec 2011 10:37:05 +0000
In-Reply-To: <20202.10169.101830.45527@mariner.uk.xensource.com>
References: <64e48ae2ef6760db221f.1323796155@cosworth.uk.xensource.com>
	<20202.10169.101830.45527@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1324031825.20077.562.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Anthony Perard <anthony.perard@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] libxl: improve error handling when saving
 device model state
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2011-12-15 at 17:00 +0000, Ian Jackson wrote:
> Ian Campbell writes ("[Xen-devel] [PATCH] libxl: improve error handling when saving device model state"):
> > libxl: improve error handling when saving device model state.
> ...
> > +out_close_fd2:
> >      close(fd2);
> > +out_unlink:
> >      unlink(filename);
> 
> This style of error handling is very prone to errors.
> 
> How about:
> 
>     int fd2 = -1;
> 
>     blah blah maybe goto out blah blah
> 
>     if (fd2 >= 0) close(fd2);
> 
> And always unlinking the filename is fine, surely ?

Yes. Patch is below.

In principal it ought to be possible to save upstream qemu state direct
to the fd and avoid the file altogether, Anthony what do you think?

Ian.

diff -r 5924514e0523 tools/libxl/libxl_dom.c
--- a/tools/libxl/libxl_dom.c	Fri Dec 16 09:48:06 2011 +0000
+++ b/tools/libxl/libxl_dom.c	Fri Dec 16 10:36:34 2011 +0000
@@ -605,7 +605,7 @@ out:
 int libxl__domain_save_device_model(libxl__gc *gc, uint32_t domid, int fd)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
-    int fd2, c;
+    int ret, fd2 = -1, c;
     char buf[1024];
     const char *filename = libxl__device_model_savefile(gc, domid);
     struct stat st;
@@ -630,8 +630,11 @@ int libxl__domain_save_device_model(libx
             return ERROR_FAIL;
         }
         /* Save DM state into fd2 */
-        if (libxl__qmp_migrate(gc, domid, fd2))
-            return ERROR_FAIL;
+        ret = libxl__qmp_migrate(gc, domid, fd2);
+        if (ret)
+            goto out;
+        close(fd2);
+        fd2 = -1;
         break;
     default:
         return ERROR_INVAL;
@@ -640,37 +643,45 @@ int libxl__domain_save_device_model(libx
     if (stat(filename, &st) < 0)
     {
         LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Unable to stat qemu save file\n");
-        return ERROR_FAIL;
+        ret = ERROR_FAIL;
+        goto out;
     }
 
     qemu_state_len = st.st_size;
     LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Qemu state is %d bytes\n", qemu_state_len);
 
-    c = libxl_write_exactly(ctx, fd, QEMU_SIGNATURE, strlen(QEMU_SIGNATURE),
-                            "saved-state file", "qemu signature");
-    if (c)
-        return c;
+    ret = libxl_write_exactly(ctx, fd, QEMU_SIGNATURE, strlen(QEMU_SIGNATURE),
+                              "saved-state file", "qemu signature");
+    if (ret)
+        goto out;
 
-    c = libxl_write_exactly(ctx, fd, &qemu_state_len, sizeof(qemu_state_len),
+    ret = libxl_write_exactly(ctx, fd, &qemu_state_len, sizeof(qemu_state_len),
                             "saved-state file", "saved-state length");
-    if (c)
-        return c;
+    if (ret)
+        goto out;
 
     fd2 = open(filename, O_RDONLY);
+    if (fd2 < 0) {
+        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "Unable to open qemu save file\n");
+        goto out;
+    }
     while ((c = read(fd2, buf, sizeof(buf))) != 0) {
         if (c < 0) {
             if (errno == EINTR)
                 continue;
-            return errno;
+            ret = errno;
+            goto out;
         }
-        c = libxl_write_exactly(
+        ret = libxl_write_exactly(
             ctx, fd, buf, c, "saved-state file", "qemu state");
-        if (c)
-            return c;
+        if (ret)
+            goto out;
     }
-    close(fd2);
+    ret = 0;
+out:
+    if (fd2 >= 0) close(fd2);
     unlink(filename);
-    return 0;
+    return ret;
 }
 
 char *libxl__uuid2string(libxl__gc *gc, const libxl_uuid uuid)



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 10:37:39 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 10:37:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbVA9-0007Ou-ST; Fri, 16 Dec 2011 10:37:13 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RbVA8-0007Od-EF
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 10:37:12 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1324031826!7722541!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjU3OQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28923 invoked from network); 16 Dec 2011 10:37:06 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Dec 2011 10:37:06 -0000
X-IronPort-AV: E=Sophos;i="4.71,362,1320624000"; 
   d="scan'208";a="9509573"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Dec 2011 10:37:05 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 16 Dec 2011 10:37:05 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Fri, 16 Dec 2011 10:37:05 +0000
In-Reply-To: <20202.10169.101830.45527@mariner.uk.xensource.com>
References: <64e48ae2ef6760db221f.1323796155@cosworth.uk.xensource.com>
	<20202.10169.101830.45527@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1324031825.20077.562.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Anthony Perard <anthony.perard@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] libxl: improve error handling when saving
 device model state
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2011-12-15 at 17:00 +0000, Ian Jackson wrote:
> Ian Campbell writes ("[Xen-devel] [PATCH] libxl: improve error handling when saving device model state"):
> > libxl: improve error handling when saving device model state.
> ...
> > +out_close_fd2:
> >      close(fd2);
> > +out_unlink:
> >      unlink(filename);
> 
> This style of error handling is very prone to errors.
> 
> How about:
> 
>     int fd2 = -1;
> 
>     blah blah maybe goto out blah blah
> 
>     if (fd2 >= 0) close(fd2);
> 
> And always unlinking the filename is fine, surely ?

Yes. Patch is below.

In principal it ought to be possible to save upstream qemu state direct
to the fd and avoid the file altogether, Anthony what do you think?

Ian.

diff -r 5924514e0523 tools/libxl/libxl_dom.c
--- a/tools/libxl/libxl_dom.c	Fri Dec 16 09:48:06 2011 +0000
+++ b/tools/libxl/libxl_dom.c	Fri Dec 16 10:36:34 2011 +0000
@@ -605,7 +605,7 @@ out:
 int libxl__domain_save_device_model(libxl__gc *gc, uint32_t domid, int fd)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
-    int fd2, c;
+    int ret, fd2 = -1, c;
     char buf[1024];
     const char *filename = libxl__device_model_savefile(gc, domid);
     struct stat st;
@@ -630,8 +630,11 @@ int libxl__domain_save_device_model(libx
             return ERROR_FAIL;
         }
         /* Save DM state into fd2 */
-        if (libxl__qmp_migrate(gc, domid, fd2))
-            return ERROR_FAIL;
+        ret = libxl__qmp_migrate(gc, domid, fd2);
+        if (ret)
+            goto out;
+        close(fd2);
+        fd2 = -1;
         break;
     default:
         return ERROR_INVAL;
@@ -640,37 +643,45 @@ int libxl__domain_save_device_model(libx
     if (stat(filename, &st) < 0)
     {
         LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Unable to stat qemu save file\n");
-        return ERROR_FAIL;
+        ret = ERROR_FAIL;
+        goto out;
     }
 
     qemu_state_len = st.st_size;
     LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Qemu state is %d bytes\n", qemu_state_len);
 
-    c = libxl_write_exactly(ctx, fd, QEMU_SIGNATURE, strlen(QEMU_SIGNATURE),
-                            "saved-state file", "qemu signature");
-    if (c)
-        return c;
+    ret = libxl_write_exactly(ctx, fd, QEMU_SIGNATURE, strlen(QEMU_SIGNATURE),
+                              "saved-state file", "qemu signature");
+    if (ret)
+        goto out;
 
-    c = libxl_write_exactly(ctx, fd, &qemu_state_len, sizeof(qemu_state_len),
+    ret = libxl_write_exactly(ctx, fd, &qemu_state_len, sizeof(qemu_state_len),
                             "saved-state file", "saved-state length");
-    if (c)
-        return c;
+    if (ret)
+        goto out;
 
     fd2 = open(filename, O_RDONLY);
+    if (fd2 < 0) {
+        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "Unable to open qemu save file\n");
+        goto out;
+    }
     while ((c = read(fd2, buf, sizeof(buf))) != 0) {
         if (c < 0) {
             if (errno == EINTR)
                 continue;
-            return errno;
+            ret = errno;
+            goto out;
         }
-        c = libxl_write_exactly(
+        ret = libxl_write_exactly(
             ctx, fd, buf, c, "saved-state file", "qemu state");
-        if (c)
-            return c;
+        if (ret)
+            goto out;
     }
-    close(fd2);
+    ret = 0;
+out:
+    if (fd2 >= 0) close(fd2);
     unlink(filename);
-    return 0;
+    return ret;
 }
 
 char *libxl__uuid2string(libxl__gc *gc, const libxl_uuid uuid)



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 10:59:53 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 10:59:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbVVd-0007dS-S7; Fri, 16 Dec 2011 10:59:25 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <george.shuklin@gmail.com>)
	id 1RbVVc-0007cn-DR; Fri, 16 Dec 2011 10:59:24 +0000
X-Env-Sender: george.shuklin@gmail.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1324033157!7721446!1
X-Originating-IP: [209.85.215.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20378 invoked from network); 16 Dec 2011 10:59:17 -0000
Received: from mail-ey0-f171.google.com (HELO mail-ey0-f171.google.com)
	(209.85.215.171)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Dec 2011 10:59:17 -0000
Received: by eaad11 with SMTP id d11so5844884eaa.30
	for <multiple recipients>; Fri, 16 Dec 2011 02:59:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=message-id:date:from:user-agent:mime-version:to:subject
	:content-type:content-transfer-encoding;
	bh=5ClM/+I5wqE49LdhG1vMSpYi7/lMMANP3WIAzkBWrkM=;
	b=NFDglFCWm5rhkdnt4mFvBTnsY1tPD7V6Q94L6YK+N8ruA1cfpX1vjB2TmX3Kty33UJ
	ztl9GUJDYzwNQvoY8d3Cc+fpkeRyZwb96WPCMKv00chybeoFe8uXFPf2lKwZQFTAV7XI
	QHfZLqy+VjZMHEWSE4hQSam9J28URd2IrIn24=
Received: by 10.205.130.1 with SMTP id hk1mr2804771bkc.68.1324033157371;
	Fri, 16 Dec 2011 02:59:17 -0800 (PST)
Received: from [192.168.40.44] (officecvt.selectel.ru. [188.93.16.50])
	by mx.google.com with ESMTPS id cc2sm22046194bkb.8.2011.12.16.02.59.15
	(version=SSLv3 cipher=OTHER); Fri, 16 Dec 2011 02:59:16 -0800 (PST)
Message-ID: <4EEB2482.7080005@gmail.com>
Date: Fri, 16 Dec 2011 14:59:14 +0400
From: George Shuklin <george.shuklin@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:9.0) Gecko/20111209 Thunderbird/9.0
MIME-Version: 1.0
To: xen-devel <xen-devel@lists.xensource.com>, 
	"xen-users@lists.xensource.com" <xen-users@lists.xensource.com>
Subject: [Xen-devel] Our pyxs library is now opensource
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Good day.

We (Selectel Ltd) decided to publish our internal library for accessing 
XenStore from python (pyxs) under LGPL license.

Main difference from classic xen.lowlevel.xs is nice support for 
multiple subscriptions to different keys in xenstore and overall 
'pythonic' way do do some staff. F.e. instead x.read('path') you can use 
just x['path'], instead x.write('','path',value) x['path']=value. But 
the main cool feature - is Monitor class to allow multiple subscription.

It written purely on python without C dependences.

Repository: https://github.com/selectel/pyxs

Any comments and bugreports appreciated.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 10:59:53 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 10:59:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbVVd-0007dS-S7; Fri, 16 Dec 2011 10:59:25 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <george.shuklin@gmail.com>)
	id 1RbVVc-0007cn-DR; Fri, 16 Dec 2011 10:59:24 +0000
X-Env-Sender: george.shuklin@gmail.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1324033157!7721446!1
X-Originating-IP: [209.85.215.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20378 invoked from network); 16 Dec 2011 10:59:17 -0000
Received: from mail-ey0-f171.google.com (HELO mail-ey0-f171.google.com)
	(209.85.215.171)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Dec 2011 10:59:17 -0000
Received: by eaad11 with SMTP id d11so5844884eaa.30
	for <multiple recipients>; Fri, 16 Dec 2011 02:59:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=message-id:date:from:user-agent:mime-version:to:subject
	:content-type:content-transfer-encoding;
	bh=5ClM/+I5wqE49LdhG1vMSpYi7/lMMANP3WIAzkBWrkM=;
	b=NFDglFCWm5rhkdnt4mFvBTnsY1tPD7V6Q94L6YK+N8ruA1cfpX1vjB2TmX3Kty33UJ
	ztl9GUJDYzwNQvoY8d3Cc+fpkeRyZwb96WPCMKv00chybeoFe8uXFPf2lKwZQFTAV7XI
	QHfZLqy+VjZMHEWSE4hQSam9J28URd2IrIn24=
Received: by 10.205.130.1 with SMTP id hk1mr2804771bkc.68.1324033157371;
	Fri, 16 Dec 2011 02:59:17 -0800 (PST)
Received: from [192.168.40.44] (officecvt.selectel.ru. [188.93.16.50])
	by mx.google.com with ESMTPS id cc2sm22046194bkb.8.2011.12.16.02.59.15
	(version=SSLv3 cipher=OTHER); Fri, 16 Dec 2011 02:59:16 -0800 (PST)
Message-ID: <4EEB2482.7080005@gmail.com>
Date: Fri, 16 Dec 2011 14:59:14 +0400
From: George Shuklin <george.shuklin@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:9.0) Gecko/20111209 Thunderbird/9.0
MIME-Version: 1.0
To: xen-devel <xen-devel@lists.xensource.com>, 
	"xen-users@lists.xensource.com" <xen-users@lists.xensource.com>
Subject: [Xen-devel] Our pyxs library is now opensource
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Good day.

We (Selectel Ltd) decided to publish our internal library for accessing 
XenStore from python (pyxs) under LGPL license.

Main difference from classic xen.lowlevel.xs is nice support for 
multiple subscriptions to different keys in xenstore and overall 
'pythonic' way do do some staff. F.e. instead x.read('path') you can use 
just x['path'], instead x.write('','path',value) x['path']=value. But 
the main cool feature - is Monitor class to allow multiple subscription.

It written purely on python without C dependences.

Repository: https://github.com/selectel/pyxs

Any comments and bugreports appreciated.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 11:04:53 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 11:04:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbVaW-00083b-9R; Fri, 16 Dec 2011 11:04:28 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1RbVaV-00083I-1Q
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 11:04:27 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1324033459!5764246!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17527 invoked from network); 16 Dec 2011 11:04:20 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Dec 2011 11:04:20 -0000
Received: by iagw33 with SMTP id w33so11008920iag.30
	for <xen-devel@lists.xensource.com>;
	Fri, 16 Dec 2011 03:04:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=OjgZgiJ4OeV5zmjWxMqIT5QjDm1VIHX5czXTgRFla1o=;
	b=AOZYkGauyHZZ4IIp6hLkvtN2neOWyz3rAXfptG3R9ERNqJi4h/gt3RtPpof7zNr1EN
	Sl8/P5Fj6lq+FAKoPh2HjE9keyGAPTqAz1PNxfZQwDzgp1Ov+AX1IcE7Kqcu3Lo0Ym2g
	6YbRTnjswd/KqOo9J40O4VnAwcgRJR+EMaV6g=
MIME-Version: 1.0
Received: by 10.50.181.161 with SMTP id dx1mr7771726igc.90.1324033459111; Fri,
	16 Dec 2011 03:04:19 -0800 (PST)
Received: by 10.231.146.21 with HTTP; Fri, 16 Dec 2011 03:04:19 -0800 (PST)
In-Reply-To: <26c93838.3b3fb.13445de0e67.Coremail.gbtux@126.com>
References: <26c93838.3b3fb.13445de0e67.Coremail.gbtux@126.com>
Date: Fri, 16 Dec 2011 11:04:19 +0000
X-Google-Sender-Auth: CLwMAMQhd2A2ia0yFxx3j1hkzoA
Message-ID: <CAFLBxZYM-8vEc5Egmv+iXqMDUE_UJcgHbwr7=71H-kFowTzXWA@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: zhikai <gbtux@126.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] A question on the credit scheduler
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

2011/12/16 zhikai <gbtux@126.com>:
> Hi All,
>
> In the credit scheduler, the scheduling decision function=A0csched_schedu=
le()
> is called in the schedule function in scheduler.c, such as the following.
> next_slice =3D sched->do_schedule(sched, now, tasklet_work_scheduled);
>
> But, how often the=A0csched_schedule() is called and to run? Does this
> frequency have something to do with the slice of credit scheduler that is
> 30ms?

The scheduler runs whenever the SCHEDULE_SOFTIRQ is raised.  If you
grep through the source code fro that string, you can find all the
places where it's raised.

Some examples include:
* When the 30ms timeslice is finished
* When a sleeping vcpu of higher priority than what's currently running wak=
es up
* When a vcpu blocks
* When a vcpu is migrated from one cpu to another

30ms is actually a pretty long time; in typical workloads, vcpus block
or are preempted by other waking vcpus without using up their full
timeslice.

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 11:04:53 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 11:04:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbVaW-00083b-9R; Fri, 16 Dec 2011 11:04:28 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1RbVaV-00083I-1Q
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 11:04:27 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1324033459!5764246!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17527 invoked from network); 16 Dec 2011 11:04:20 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Dec 2011 11:04:20 -0000
Received: by iagw33 with SMTP id w33so11008920iag.30
	for <xen-devel@lists.xensource.com>;
	Fri, 16 Dec 2011 03:04:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=OjgZgiJ4OeV5zmjWxMqIT5QjDm1VIHX5czXTgRFla1o=;
	b=AOZYkGauyHZZ4IIp6hLkvtN2neOWyz3rAXfptG3R9ERNqJi4h/gt3RtPpof7zNr1EN
	Sl8/P5Fj6lq+FAKoPh2HjE9keyGAPTqAz1PNxfZQwDzgp1Ov+AX1IcE7Kqcu3Lo0Ym2g
	6YbRTnjswd/KqOo9J40O4VnAwcgRJR+EMaV6g=
MIME-Version: 1.0
Received: by 10.50.181.161 with SMTP id dx1mr7771726igc.90.1324033459111; Fri,
	16 Dec 2011 03:04:19 -0800 (PST)
Received: by 10.231.146.21 with HTTP; Fri, 16 Dec 2011 03:04:19 -0800 (PST)
In-Reply-To: <26c93838.3b3fb.13445de0e67.Coremail.gbtux@126.com>
References: <26c93838.3b3fb.13445de0e67.Coremail.gbtux@126.com>
Date: Fri, 16 Dec 2011 11:04:19 +0000
X-Google-Sender-Auth: CLwMAMQhd2A2ia0yFxx3j1hkzoA
Message-ID: <CAFLBxZYM-8vEc5Egmv+iXqMDUE_UJcgHbwr7=71H-kFowTzXWA@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: zhikai <gbtux@126.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] A question on the credit scheduler
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

2011/12/16 zhikai <gbtux@126.com>:
> Hi All,
>
> In the credit scheduler, the scheduling decision function=A0csched_schedu=
le()
> is called in the schedule function in scheduler.c, such as the following.
> next_slice =3D sched->do_schedule(sched, now, tasklet_work_scheduled);
>
> But, how often the=A0csched_schedule() is called and to run? Does this
> frequency have something to do with the slice of credit scheduler that is
> 30ms?

The scheduler runs whenever the SCHEDULE_SOFTIRQ is raised.  If you
grep through the source code fro that string, you can find all the
places where it's raised.

Some examples include:
* When the 30ms timeslice is finished
* When a sleeping vcpu of higher priority than what's currently running wak=
es up
* When a vcpu blocks
* When a vcpu is migrated from one cpu to another

30ms is actually a pretty long time; in typical workloads, vcpus block
or are preempted by other waking vcpus without using up their full
timeslice.

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 11:10:03 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 11:10:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbVfj-0008No-AM; Fri, 16 Dec 2011 11:09:51 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <lcapitulino@redhat.com>) id 1RbEDd-0004K2-R9
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 16:31:42 +0000
X-Env-Sender: lcapitulino@redhat.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1323966660!50789317!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDYzNzk=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1951 invoked from network); 15 Dec 2011 16:31:00 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-6.tower-27.messagelabs.com with SMTP;
	15 Dec 2011 16:31:00 -0000
Received: from int-mx02.intmail.prod.int.phx2.redhat.com
	(int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id pBFGVYOE018186
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 15 Dec 2011 11:31:34 -0500
Received: from doriath (ovpn-113-72.phx2.redhat.com [10.3.113.72])
	by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP
	id pBFGVVRA011630; Thu, 15 Dec 2011 11:31:32 -0500
Date: Thu, 15 Dec 2011 14:31:31 -0200
From: Luiz Capitulino <lcapitulino@redhat.com>
To: Anthony Liguori <anthony@codemonkey.ws>
Message-ID: <20111215143131.75239a3e@doriath>
In-Reply-To: <4EEA0EB8.4020203@codemonkey.ws>
References: <1323467645-24271-1-git-send-email-anthony.perard@citrix.com>
	<1323467645-24271-4-git-send-email-anthony.perard@citrix.com>
	<4EEA0EB8.4020203@codemonkey.ws>
Organization: Red Hat
Mime-Version: 1.0
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.12
X-Mailman-Approved-At: Fri, 16 Dec 2011 11:09:48 +0000
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	QEMU-devel <qemu-devel@nongnu.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH V2 3/5] Introduce premigrate
	RunState.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 15 Dec 2011 09:14:00 -0600
Anthony Liguori <anthony@codemonkey.ws> wrote:

> On 12/09/2011 03:54 PM, Anthony PERARD wrote:
> > This new state will be used by Xen functions to know QEMU will wait for a
> > migration. This is important to know for memory related function because the
> > memory is already allocated and reallocated them will not works.

How is premigrate different from inmigrate? It looks like the same thing to me.

> >
> > Signed-off-by: Anthony PERARD<anthony.perard@citrix.com>
> 
> Luiz, please Ack.  In the future, when you make QMP changes, please CC the 
> appropriate maintainer.

I should improve my filter too.

> 
> Regards,
> 
> Anthony Liguori
> 
> > ---
> >   qapi-schema.json |    2 +-
> >   vl.c             |    4 ++++
> >   2 files changed, 5 insertions(+), 1 deletions(-)
> >
> > diff --git a/qapi-schema.json b/qapi-schema.json
> > index cb1ba77..bd77444 100644
> > --- a/qapi-schema.json
> > +++ b/qapi-schema.json
> > @@ -121,7 +121,7 @@
> >   { 'enum': 'RunState',
> >     'data': [ 'debug', 'inmigrate', 'internal-error', 'io-error', 'paused',
> >               'postmigrate', 'prelaunch', 'finish-migrate', 'restore-vm',
> > -            'running', 'save-vm', 'shutdown', 'watchdog' ] }
> > +            'running', 'save-vm', 'shutdown', 'watchdog', 'premigrate' ] }
> >
> >   ##
> >   # @StatusInfo:
> > diff --git a/vl.c b/vl.c
> > index e7dced2..a291416 100644
> > --- a/vl.c
> > +++ b/vl.c
> > @@ -351,8 +351,11 @@ static const RunStateTransition runstate_transitions_def[] = {
> >
> >       { RUN_STATE_PRELAUNCH, RUN_STATE_RUNNING },
> >       { RUN_STATE_PRELAUNCH, RUN_STATE_FINISH_MIGRATE },
> > +    { RUN_STATE_PRELAUNCH, RUN_STATE_PREMIGRATE },
> >       { RUN_STATE_PRELAUNCH, RUN_STATE_INMIGRATE },
> >
> > +    { RUN_STATE_PREMIGRATE, RUN_STATE_INMIGRATE },
> > +
> >       { RUN_STATE_FINISH_MIGRATE, RUN_STATE_RUNNING },
> >       { RUN_STATE_FINISH_MIGRATE, RUN_STATE_POSTMIGRATE },
> >
> > @@ -2975,6 +2978,7 @@ int main(int argc, char **argv, char **envp)
> >                   break;
> >               case QEMU_OPTION_incoming:
> >                   incoming = optarg;
> > +                runstate_set(RUN_STATE_PREMIGRATE);
> >                   break;
> >               case QEMU_OPTION_nodefaults:
> >                   default_serial = 0;
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 11:10:03 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 11:10:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbVfj-0008No-AM; Fri, 16 Dec 2011 11:09:51 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <lcapitulino@redhat.com>) id 1RbEDd-0004K2-R9
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 16:31:42 +0000
X-Env-Sender: lcapitulino@redhat.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1323966660!50789317!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDYzNzk=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1951 invoked from network); 15 Dec 2011 16:31:00 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-6.tower-27.messagelabs.com with SMTP;
	15 Dec 2011 16:31:00 -0000
Received: from int-mx02.intmail.prod.int.phx2.redhat.com
	(int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id pBFGVYOE018186
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 15 Dec 2011 11:31:34 -0500
Received: from doriath (ovpn-113-72.phx2.redhat.com [10.3.113.72])
	by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP
	id pBFGVVRA011630; Thu, 15 Dec 2011 11:31:32 -0500
Date: Thu, 15 Dec 2011 14:31:31 -0200
From: Luiz Capitulino <lcapitulino@redhat.com>
To: Anthony Liguori <anthony@codemonkey.ws>
Message-ID: <20111215143131.75239a3e@doriath>
In-Reply-To: <4EEA0EB8.4020203@codemonkey.ws>
References: <1323467645-24271-1-git-send-email-anthony.perard@citrix.com>
	<1323467645-24271-4-git-send-email-anthony.perard@citrix.com>
	<4EEA0EB8.4020203@codemonkey.ws>
Organization: Red Hat
Mime-Version: 1.0
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.12
X-Mailman-Approved-At: Fri, 16 Dec 2011 11:09:48 +0000
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	QEMU-devel <qemu-devel@nongnu.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH V2 3/5] Introduce premigrate
	RunState.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 15 Dec 2011 09:14:00 -0600
Anthony Liguori <anthony@codemonkey.ws> wrote:

> On 12/09/2011 03:54 PM, Anthony PERARD wrote:
> > This new state will be used by Xen functions to know QEMU will wait for a
> > migration. This is important to know for memory related function because the
> > memory is already allocated and reallocated them will not works.

How is premigrate different from inmigrate? It looks like the same thing to me.

> >
> > Signed-off-by: Anthony PERARD<anthony.perard@citrix.com>
> 
> Luiz, please Ack.  In the future, when you make QMP changes, please CC the 
> appropriate maintainer.

I should improve my filter too.

> 
> Regards,
> 
> Anthony Liguori
> 
> > ---
> >   qapi-schema.json |    2 +-
> >   vl.c             |    4 ++++
> >   2 files changed, 5 insertions(+), 1 deletions(-)
> >
> > diff --git a/qapi-schema.json b/qapi-schema.json
> > index cb1ba77..bd77444 100644
> > --- a/qapi-schema.json
> > +++ b/qapi-schema.json
> > @@ -121,7 +121,7 @@
> >   { 'enum': 'RunState',
> >     'data': [ 'debug', 'inmigrate', 'internal-error', 'io-error', 'paused',
> >               'postmigrate', 'prelaunch', 'finish-migrate', 'restore-vm',
> > -            'running', 'save-vm', 'shutdown', 'watchdog' ] }
> > +            'running', 'save-vm', 'shutdown', 'watchdog', 'premigrate' ] }
> >
> >   ##
> >   # @StatusInfo:
> > diff --git a/vl.c b/vl.c
> > index e7dced2..a291416 100644
> > --- a/vl.c
> > +++ b/vl.c
> > @@ -351,8 +351,11 @@ static const RunStateTransition runstate_transitions_def[] = {
> >
> >       { RUN_STATE_PRELAUNCH, RUN_STATE_RUNNING },
> >       { RUN_STATE_PRELAUNCH, RUN_STATE_FINISH_MIGRATE },
> > +    { RUN_STATE_PRELAUNCH, RUN_STATE_PREMIGRATE },
> >       { RUN_STATE_PRELAUNCH, RUN_STATE_INMIGRATE },
> >
> > +    { RUN_STATE_PREMIGRATE, RUN_STATE_INMIGRATE },
> > +
> >       { RUN_STATE_FINISH_MIGRATE, RUN_STATE_RUNNING },
> >       { RUN_STATE_FINISH_MIGRATE, RUN_STATE_POSTMIGRATE },
> >
> > @@ -2975,6 +2978,7 @@ int main(int argc, char **argv, char **envp)
> >                   break;
> >               case QEMU_OPTION_incoming:
> >                   incoming = optarg;
> > +                runstate_set(RUN_STATE_PREMIGRATE);
> >                   break;
> >               case QEMU_OPTION_nodefaults:
> >                   default_serial = 0;
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 11:10:04 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 11:10:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbVfi-0008N8-24; Fri, 16 Dec 2011 11:09:50 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Leonid.Kalev@ca.com>) id 1RatnI-0004Sr-Et
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 18:43:08 +0000
X-Env-Sender: Leonid.Kalev@ca.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1323888129!5550678!1
X-Originating-IP: [74.125.149.201]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12592 invoked from network); 14 Dec 2011 18:42:11 -0000
Received: from na3sys009aog109.obsmtp.com (HELO na3sys009aog109.obsmtp.com)
	(74.125.149.201)
	by server-2.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Dec 2011 18:42:11 -0000
Received: from USILMS190.ca.com ([141.202.246.44]) (using TLSv1) by
	na3sys009aob109.postini.com ([74.125.148.12]) with SMTP
	ID DSNKTujuAQ/vY+ghLkjkY+36x7FuMw1tk7Y4@postini.com;
	Wed, 14 Dec 2011 10:42:11 PST
Received: from USILMS175.ca.com (141.202.6.25) by USILMS190.ca.com
	(141.202.246.44) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Wed, 14 Dec 2011 13:42:08 -0500
Received: from USILMS111B.ca.com ([169.254.8.141]) by usilms175.ca.com
	([141.202.6.25]) with mapi id 14.01.0289.001;
	Wed, 14 Dec 2011 13:42:08 -0500
From: "Kalev, Leonid" <Leonid.Kalev@ca.com>
To: "Taylor, Neal E" <Neal.Taylor@ca.com>
Thread-Topic: [Xen-devel] Buffers not reachable by PCI
Thread-Index: Acy2r+Ulg1PsfbmtTl6QVj0jZAx7mwAK1xcAAIXl/sAAGPmvgAAhEiCwAA9ukQAACILlsAAMK30AAALQl/AAEM4lgA==
Date: Wed, 14 Dec 2011 18:42:07 +0000
Message-ID: <4EE8EDF5.5070800@ca.com>
References: <3E243B26F475504B9BB0BCC9728B0DA629E16E01@USILMS110A.ca.com>
	<20111209203010.GA14412@andromeda.dapyr.net>
	<3E243B26F475504B9BB0BCC9728B0DA629E17AEA@USILMS110A.ca.com>
	<20111213001912.GA2730@konrad-lan>
	<3E243B26F475504B9BB0BCC9728B0DA629E184FA@USILMS110A.ca.com>
	<20111213232759.GA8702@konrad-lan>
	<3E243B26F475504B9BB0BCC9728B0DA629E18564@USILMS110A.ca.com>
	<4EE8785A0200007800067A16@nat28.tlf.novell.com>
	<3E243B26F475504B9BB0BCC9728B0DA629E18A6B@USILMS110A.ca.com>
In-Reply-To: <3E243B26F475504B9BB0BCC9728B0DA629E18A6B@USILMS110A.ca.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.23)
	Gecko/20110921 Lightning/1.0b2 Thunderbird/3.1.15
x-originating-ip: [81.218.169.161]
Content-ID: <BABB19CC8A48804AB2A9EE30F6497592@ca.com>
MIME-Version: 1.0
X-Mailman-Approved-At: Fri, 16 Dec 2011 11:09:48 +0000
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>,
	xen-devel <xen-devel@lists.xensource.com>,
	Tushar N Dave <tushar.n.dave@intel.com>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] Buffers not reachable by PCI
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 12/14/2011 06:42 PM, Taylor, Neal E wrote:
> The last quoted printout is calculated the same way as the test that fails which leads me to question the computation's validity.

The computation validity seems OK to me (the 'phys' address is, as correctly stated 
in the comments, not suitable for DMA, but it is first translated via 
xen_phys_to_bus, which gives the machine address - and on x86 that is also the bus 
address)

I have a STUPID question, though: why are the start and end addresses of the swiotlb 
memory area not page-aligned???

The io_tlb_end address is one byte PAST the valid area, which is why the 
xen_swiotlb_dma_supported function uses (xen_io_tlb_end-1). However, this will work 
properly only if the value is page-aligned. If it isn't, then decrementing it by one 
will keep the value in the same page (which is one page past the last valid one).

The function that allocates the memory uses alloc_bootmem(), which provides just 
cache-aligned memory (not page-aligned).

If it is OK for the swiotlb area not to be page-aligned, then the 
xen_swiotlb_dma_supported should use (xen_io_tlb_end - (PAGE_SIZE-1))

If the memory should be in fact aligned, then the allocation must be changed to 
alloc_bootmem_pages() (which is the same as alloc_bootmem, but page-aligned).


>
> The test that fails is (from drivers/xen/swiotlb-xen.c):
> xen_swiotlb_dma_supported(struct device *hwdev, u64 mask)
> {
>          return xen_virt_to_bus(xen_io_tlb_end - 1)<= mask;
> }
>
>
> "xen_virt_to_bus" in turn:
> static dma_addr_t xen_virt_to_bus(void *address)
> {
>          return xen_phys_to_bus(virt_to_phys(address));
> }
>
>
> Now, "virt_to_phys" (out of arch/x86/include/asm/io.h) is defined as follows but carries a comment bothersome to this usage of it as we're, basically, dealing with a dma "transfer" and calling from a device driver:
> /**
>   *      virt_to_phys    -       map virtual addresses to physical
>   *      @address: address to remap
>   *
>   *      The returned physical address is the physical (CPU) mapping for
>   *      the memory address given. It is only valid to use this function on
>   *      addresses directly mapped or allocated via kmalloc.
>   *
>   *      This function does not give bus mappings for DMA transfers. In
>   *      almost all conceivable cases a device driver should not be using
>   *      this function
>   */
> static inline phys_addr_t virt_to_phys(volatile void *address)
> {
>          return __pa(address);
> }
>
>
> Going a couple of steps further, "__pa" is defined (in arch/x86/include/asm/page.h) as:
> #define __pa(x)         __phys_addr((unsigned long)(x))
>
>
> and "__phys_addr" (in arch/x86/mm/physaddr.c) as:
> unsigned long __phys_addr(unsigned long x)
> {
>          if (x>= __START_KERNEL_map) {
>                  x -= __START_KERNEL_map;
>                  VIRTUAL_BUG_ON(x>= KERNEL_IMAGE_SIZE);
>                  x += phys_base;
>          } else {
>                  VIRTUAL_BUG_ON(x<  PAGE_OFFSET);
>                  x -= PAGE_OFFSET;
>                  VIRTUAL_BUG_ON(!phys_addr_valid(x));
>          }
>          return x;
> }
> EXPORT_SYMBOL(__phys_addr);
>
>
> So, if "virt_to_phys" isn't yielding a valid test of whether addresses will be reachable from a PCI device, what's the correct way to test it and should xen_swiotlb_dma_supported be updated to the correct way (I think so) or a new function be created?
>
> Neal
>
>
> -----Original Message-----
> From: Jan Beulich [mailto:JBeulich@suse.com]
> Sent: Wednesday, December 14, 2011 1:20 AM
> To: Taylor, Neal E
> Cc: Kalev, Leonid; Konrad Rzeszutek Wilk; Tushar N Dave; xen-devel
> Subject: Re: [Xen-devel] Buffers not reachable by PCI
>
>>>> On 14.12.11 at 01:38, "Taylor, Neal E"<Neal.Taylor@ca.com>  wrote:
>> [    0.000000] MFN 0x7f7f->0x7f00
>
> This is clearly indicating the last chunk ends well below the 4G boundary.
>
>> [    0.000000] Placing 64MB software IO TLB between d832cf00 - dc32cf00
>> [    0.000000] software IO TLB at phys 0x1832cf00 - 0x1c32cf00
>> [    0.000000] software IO TLB at bus 0x1c0f00 - 0x120fdff00
>
> Consequently, the question is how you got to this value, or what
> changed between the first and last quoted printouts.
>
> Jan
>


-- 
Leonid Kalev
CA Technologies
Principal Software Engineer
Tel:     +972 4 825 3952
Mobile:  +972 54 4631508
Leonid.Kalev@ca.com
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 11:10:04 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 11:10:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbVfi-0008N8-24; Fri, 16 Dec 2011 11:09:50 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Leonid.Kalev@ca.com>) id 1RatnI-0004Sr-Et
	for xen-devel@lists.xensource.com; Wed, 14 Dec 2011 18:43:08 +0000
X-Env-Sender: Leonid.Kalev@ca.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1323888129!5550678!1
X-Originating-IP: [74.125.149.201]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12592 invoked from network); 14 Dec 2011 18:42:11 -0000
Received: from na3sys009aog109.obsmtp.com (HELO na3sys009aog109.obsmtp.com)
	(74.125.149.201)
	by server-2.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Dec 2011 18:42:11 -0000
Received: from USILMS190.ca.com ([141.202.246.44]) (using TLSv1) by
	na3sys009aob109.postini.com ([74.125.148.12]) with SMTP
	ID DSNKTujuAQ/vY+ghLkjkY+36x7FuMw1tk7Y4@postini.com;
	Wed, 14 Dec 2011 10:42:11 PST
Received: from USILMS175.ca.com (141.202.6.25) by USILMS190.ca.com
	(141.202.246.44) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Wed, 14 Dec 2011 13:42:08 -0500
Received: from USILMS111B.ca.com ([169.254.8.141]) by usilms175.ca.com
	([141.202.6.25]) with mapi id 14.01.0289.001;
	Wed, 14 Dec 2011 13:42:08 -0500
From: "Kalev, Leonid" <Leonid.Kalev@ca.com>
To: "Taylor, Neal E" <Neal.Taylor@ca.com>
Thread-Topic: [Xen-devel] Buffers not reachable by PCI
Thread-Index: Acy2r+Ulg1PsfbmtTl6QVj0jZAx7mwAK1xcAAIXl/sAAGPmvgAAhEiCwAA9ukQAACILlsAAMK30AAALQl/AAEM4lgA==
Date: Wed, 14 Dec 2011 18:42:07 +0000
Message-ID: <4EE8EDF5.5070800@ca.com>
References: <3E243B26F475504B9BB0BCC9728B0DA629E16E01@USILMS110A.ca.com>
	<20111209203010.GA14412@andromeda.dapyr.net>
	<3E243B26F475504B9BB0BCC9728B0DA629E17AEA@USILMS110A.ca.com>
	<20111213001912.GA2730@konrad-lan>
	<3E243B26F475504B9BB0BCC9728B0DA629E184FA@USILMS110A.ca.com>
	<20111213232759.GA8702@konrad-lan>
	<3E243B26F475504B9BB0BCC9728B0DA629E18564@USILMS110A.ca.com>
	<4EE8785A0200007800067A16@nat28.tlf.novell.com>
	<3E243B26F475504B9BB0BCC9728B0DA629E18A6B@USILMS110A.ca.com>
In-Reply-To: <3E243B26F475504B9BB0BCC9728B0DA629E18A6B@USILMS110A.ca.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.23)
	Gecko/20110921 Lightning/1.0b2 Thunderbird/3.1.15
x-originating-ip: [81.218.169.161]
Content-ID: <BABB19CC8A48804AB2A9EE30F6497592@ca.com>
MIME-Version: 1.0
X-Mailman-Approved-At: Fri, 16 Dec 2011 11:09:48 +0000
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>,
	xen-devel <xen-devel@lists.xensource.com>,
	Tushar N Dave <tushar.n.dave@intel.com>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] Buffers not reachable by PCI
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 12/14/2011 06:42 PM, Taylor, Neal E wrote:
> The last quoted printout is calculated the same way as the test that fails which leads me to question the computation's validity.

The computation validity seems OK to me (the 'phys' address is, as correctly stated 
in the comments, not suitable for DMA, but it is first translated via 
xen_phys_to_bus, which gives the machine address - and on x86 that is also the bus 
address)

I have a STUPID question, though: why are the start and end addresses of the swiotlb 
memory area not page-aligned???

The io_tlb_end address is one byte PAST the valid area, which is why the 
xen_swiotlb_dma_supported function uses (xen_io_tlb_end-1). However, this will work 
properly only if the value is page-aligned. If it isn't, then decrementing it by one 
will keep the value in the same page (which is one page past the last valid one).

The function that allocates the memory uses alloc_bootmem(), which provides just 
cache-aligned memory (not page-aligned).

If it is OK for the swiotlb area not to be page-aligned, then the 
xen_swiotlb_dma_supported should use (xen_io_tlb_end - (PAGE_SIZE-1))

If the memory should be in fact aligned, then the allocation must be changed to 
alloc_bootmem_pages() (which is the same as alloc_bootmem, but page-aligned).


>
> The test that fails is (from drivers/xen/swiotlb-xen.c):
> xen_swiotlb_dma_supported(struct device *hwdev, u64 mask)
> {
>          return xen_virt_to_bus(xen_io_tlb_end - 1)<= mask;
> }
>
>
> "xen_virt_to_bus" in turn:
> static dma_addr_t xen_virt_to_bus(void *address)
> {
>          return xen_phys_to_bus(virt_to_phys(address));
> }
>
>
> Now, "virt_to_phys" (out of arch/x86/include/asm/io.h) is defined as follows but carries a comment bothersome to this usage of it as we're, basically, dealing with a dma "transfer" and calling from a device driver:
> /**
>   *      virt_to_phys    -       map virtual addresses to physical
>   *      @address: address to remap
>   *
>   *      The returned physical address is the physical (CPU) mapping for
>   *      the memory address given. It is only valid to use this function on
>   *      addresses directly mapped or allocated via kmalloc.
>   *
>   *      This function does not give bus mappings for DMA transfers. In
>   *      almost all conceivable cases a device driver should not be using
>   *      this function
>   */
> static inline phys_addr_t virt_to_phys(volatile void *address)
> {
>          return __pa(address);
> }
>
>
> Going a couple of steps further, "__pa" is defined (in arch/x86/include/asm/page.h) as:
> #define __pa(x)         __phys_addr((unsigned long)(x))
>
>
> and "__phys_addr" (in arch/x86/mm/physaddr.c) as:
> unsigned long __phys_addr(unsigned long x)
> {
>          if (x>= __START_KERNEL_map) {
>                  x -= __START_KERNEL_map;
>                  VIRTUAL_BUG_ON(x>= KERNEL_IMAGE_SIZE);
>                  x += phys_base;
>          } else {
>                  VIRTUAL_BUG_ON(x<  PAGE_OFFSET);
>                  x -= PAGE_OFFSET;
>                  VIRTUAL_BUG_ON(!phys_addr_valid(x));
>          }
>          return x;
> }
> EXPORT_SYMBOL(__phys_addr);
>
>
> So, if "virt_to_phys" isn't yielding a valid test of whether addresses will be reachable from a PCI device, what's the correct way to test it and should xen_swiotlb_dma_supported be updated to the correct way (I think so) or a new function be created?
>
> Neal
>
>
> -----Original Message-----
> From: Jan Beulich [mailto:JBeulich@suse.com]
> Sent: Wednesday, December 14, 2011 1:20 AM
> To: Taylor, Neal E
> Cc: Kalev, Leonid; Konrad Rzeszutek Wilk; Tushar N Dave; xen-devel
> Subject: Re: [Xen-devel] Buffers not reachable by PCI
>
>>>> On 14.12.11 at 01:38, "Taylor, Neal E"<Neal.Taylor@ca.com>  wrote:
>> [    0.000000] MFN 0x7f7f->0x7f00
>
> This is clearly indicating the last chunk ends well below the 4G boundary.
>
>> [    0.000000] Placing 64MB software IO TLB between d832cf00 - dc32cf00
>> [    0.000000] software IO TLB at phys 0x1832cf00 - 0x1c32cf00
>> [    0.000000] software IO TLB at bus 0x1c0f00 - 0x120fdff00
>
> Consequently, the question is how you got to this value, or what
> changed between the first and last quoted printouts.
>
> Jan
>


-- 
Leonid Kalev
CA Technologies
Principal Software Engineer
Tel:     +972 4 825 3952
Mobile:  +972 54 4631508
Leonid.Kalev@ca.com
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 11:10:04 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 11:10:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbVfi-0008NS-Tp; Fri, 16 Dec 2011 11:09:50 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <dab@hp.com>)
	id 1RbE7i-0001Sw-3a
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 16:25:34 +0000
X-Env-Sender: dab@hp.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1323966324!8009986!1
X-Originating-IP: [15.193.32.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTUuMTkzLjMyLjYzID0+IDMzMTYxOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17253 invoked from network); 15 Dec 2011 16:25:26 -0000
Received: from g6t0186.atlanta.hp.com (HELO g6t0186.atlanta.hp.com)
	(15.193.32.63)
	by server-11.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 15 Dec 2011 16:25:26 -0000
Received: from G5W2206G.americas.hpqcorp.net (g5w2206g.atlanta.hp.com
	[16.228.43.185]) (using TLSv1 with cipher AES128-SHA (128/128 bits))
	(No client certificate requested)
	by g6t0186.atlanta.hp.com (Postfix) with ESMTPS id BE6822C203;
	Thu, 15 Dec 2011 16:16:12 +0000 (UTC)
Received: from G4W3200G.americas.hpqcorp.net (16.234.105.236) by
	G5W2206G.americas.hpqcorp.net (16.228.43.185) with Microsoft SMTP
	Server (TLS) id 14.1.289.1; Thu, 15 Dec 2011 16:15:14 +0000
Received: from G4W3300.americas.hpqcorp.net ([169.254.9.141]) by
	G4W3200G.americas.hpqcorp.net ([16.234.105.236]) with mapi id
	14.01.0289.001; Thu, 15 Dec 2011 16:15:13 +0000
From: "Brace, Don" <dab@hp.com>
To: Jan Beulich <JBeulich@suse.com>, Konrad Rzeszutek Wilk <konrad@darnok.org>
Thread-Topic: [Xen-devel] kmap_atomic issue with SLES11SP1 32bit XEN driver
	code
Thread-Index: AQHMtSmbiuYPLZ2jDESW+pZ1Tz6425XYV7IAgAOOXYCAALrzAIAAaA+Q
Date: Thu, 15 Dec 2011 16:15:12 +0000
Message-ID: <6738613108553D49BEFEFDD59230CCDF011BED93@G4W3300.americas.hpqcorp.net>
References: <4EDFDF0D.2020104@hp.com>
	<4EE628D80200007800066F9E@nat28.tlf.novell.com>
	<20111214213443.GC25896@andromeda.dapyr.net>
	<4EE9C15602000078000680D3@nat28.tlf.novell.com>
In-Reply-To: <4EE9C15602000078000680D3@nat28.tlf.novell.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [16.216.12.12]
MIME-Version: 1.0
X-Mailman-Approved-At: Fri, 16 Dec 2011 11:09:48 +0000
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] kmap_atomic issue with SLES11SP1 32bit XEN driver
 code
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

I do not understand what this means:
" That is, we'd be susceptible to this problem only if within a
lazy-mode enabled section k{,un}map_atomic were used
synchronously (which I'd consider a coding mistake)."

Could you elaborate on this?


Here is what I am trying to do.
I am in a LLD I have bus addresses that are DMA-able that I would normally
DMA to except this driver is emulating hardware in software and so it does
not need to DMA is needs to transfer the data with the CPU.

On non-XEN 32bit kernels I use kmap_atomic() and it handles both highmem addresses
and non highmem addresses with no issues.

When I am running 32bit XEN kernels I run into issues like this:
    "BUG: unable to handle kernel paging request at 9822bf40"

-----Original Message-----
From: Jan Beulich [mailto:JBeulich@suse.com] 
Sent: Thursday, December 15, 2011 2:44 AM
To: Konrad Rzeszutek Wilk
Cc: Brace, Don; xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] kmap_atomic issue with SLES11SP1 32bit XEN driver code

>>> On 14.12.11 at 22:34, Konrad Rzeszutek Wilk <konrad@darnok.org> wrote:
> I don't know much about the SLES kernels, but if it uses lazy page
> updating it might be hitting:
> 
> 2cd1c8d x86/paravirt: PTE updates in k(un)map_atomic need to be
> synchronous, regardless of lazy_mmu mode

We use lazy mode, but only in non-IRQ (and theoretically
preemption-enabled; theoretically because PREEMPT isn't a
permitted config option in the forward ported kernels) context.
That is, we'd be susceptible to this problem only if within a
lazy-mode enabled section k{,un}map_atomic were used
synchronously (which I'd consider a coding mistake).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 11:10:04 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 11:10:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbVfi-0008NS-Tp; Fri, 16 Dec 2011 11:09:50 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <dab@hp.com>)
	id 1RbE7i-0001Sw-3a
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 16:25:34 +0000
X-Env-Sender: dab@hp.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1323966324!8009986!1
X-Originating-IP: [15.193.32.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTUuMTkzLjMyLjYzID0+IDMzMTYxOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17253 invoked from network); 15 Dec 2011 16:25:26 -0000
Received: from g6t0186.atlanta.hp.com (HELO g6t0186.atlanta.hp.com)
	(15.193.32.63)
	by server-11.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 15 Dec 2011 16:25:26 -0000
Received: from G5W2206G.americas.hpqcorp.net (g5w2206g.atlanta.hp.com
	[16.228.43.185]) (using TLSv1 with cipher AES128-SHA (128/128 bits))
	(No client certificate requested)
	by g6t0186.atlanta.hp.com (Postfix) with ESMTPS id BE6822C203;
	Thu, 15 Dec 2011 16:16:12 +0000 (UTC)
Received: from G4W3200G.americas.hpqcorp.net (16.234.105.236) by
	G5W2206G.americas.hpqcorp.net (16.228.43.185) with Microsoft SMTP
	Server (TLS) id 14.1.289.1; Thu, 15 Dec 2011 16:15:14 +0000
Received: from G4W3300.americas.hpqcorp.net ([169.254.9.141]) by
	G4W3200G.americas.hpqcorp.net ([16.234.105.236]) with mapi id
	14.01.0289.001; Thu, 15 Dec 2011 16:15:13 +0000
From: "Brace, Don" <dab@hp.com>
To: Jan Beulich <JBeulich@suse.com>, Konrad Rzeszutek Wilk <konrad@darnok.org>
Thread-Topic: [Xen-devel] kmap_atomic issue with SLES11SP1 32bit XEN driver
	code
Thread-Index: AQHMtSmbiuYPLZ2jDESW+pZ1Tz6425XYV7IAgAOOXYCAALrzAIAAaA+Q
Date: Thu, 15 Dec 2011 16:15:12 +0000
Message-ID: <6738613108553D49BEFEFDD59230CCDF011BED93@G4W3300.americas.hpqcorp.net>
References: <4EDFDF0D.2020104@hp.com>
	<4EE628D80200007800066F9E@nat28.tlf.novell.com>
	<20111214213443.GC25896@andromeda.dapyr.net>
	<4EE9C15602000078000680D3@nat28.tlf.novell.com>
In-Reply-To: <4EE9C15602000078000680D3@nat28.tlf.novell.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [16.216.12.12]
MIME-Version: 1.0
X-Mailman-Approved-At: Fri, 16 Dec 2011 11:09:48 +0000
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] kmap_atomic issue with SLES11SP1 32bit XEN driver
 code
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

I do not understand what this means:
" That is, we'd be susceptible to this problem only if within a
lazy-mode enabled section k{,un}map_atomic were used
synchronously (which I'd consider a coding mistake)."

Could you elaborate on this?


Here is what I am trying to do.
I am in a LLD I have bus addresses that are DMA-able that I would normally
DMA to except this driver is emulating hardware in software and so it does
not need to DMA is needs to transfer the data with the CPU.

On non-XEN 32bit kernels I use kmap_atomic() and it handles both highmem addresses
and non highmem addresses with no issues.

When I am running 32bit XEN kernels I run into issues like this:
    "BUG: unable to handle kernel paging request at 9822bf40"

-----Original Message-----
From: Jan Beulich [mailto:JBeulich@suse.com] 
Sent: Thursday, December 15, 2011 2:44 AM
To: Konrad Rzeszutek Wilk
Cc: Brace, Don; xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] kmap_atomic issue with SLES11SP1 32bit XEN driver code

>>> On 14.12.11 at 22:34, Konrad Rzeszutek Wilk <konrad@darnok.org> wrote:
> I don't know much about the SLES kernels, but if it uses lazy page
> updating it might be hitting:
> 
> 2cd1c8d x86/paravirt: PTE updates in k(un)map_atomic need to be
> synchronous, regardless of lazy_mmu mode

We use lazy mode, but only in non-IRQ (and theoretically
preemption-enabled; theoretically because PREEMPT isn't a
permitted config option in the forward ported kernels) context.
That is, we'd be susceptible to this problem only if within a
lazy-mode enabled section k{,un}map_atomic were used
synchronously (which I'd consider a coding mistake).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 11:10:04 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 11:10:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbVfj-0008O2-Pm; Fri, 16 Dec 2011 11:09:51 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <dab@hp.com>)
	id 1RbKYH-00038U-Jz
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 23:17:25 +0000
X-Env-Sender: dab@hp.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1323991013!45081156!1
X-Originating-IP: [15.201.24.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTUuMjAxLjI0LjIwID0+IDc5NDg4NQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14992 invoked from network); 15 Dec 2011 23:16:54 -0000
Received: from g4t0017.houston.hp.com (HELO g4t0017.houston.hp.com)
	(15.201.24.20)
	by server-12.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 15 Dec 2011 23:16:54 -0000
Received: from g4t0009.houston.hp.com (g4t0009.houston.hp.com [16.234.32.26])
	by g4t0017.houston.hp.com (Postfix) with ESMTP id 01265380E0;
	Thu, 15 Dec 2011 23:17:22 +0000 (UTC)
Received: from [10.10.13.84] (data.cce.hp.com [16.84.84.25])
	by g4t0009.houston.hp.com (Postfix) with ESMTP id 6F4ECC3E1;
	Thu, 15 Dec 2011 23:17:21 +0000 (UTC)
Message-ID: <4EEA8084.8030208@hp.com>
Date: Thu, 15 Dec 2011 17:19:32 -0600
From: dbrace <dab@hp.com>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <4EDFDF0D.2020104@hp.com>
	<4EE628D80200007800066F9E@nat28.tlf.novell.com>
	<20111214213443.GC25896@andromeda.dapyr.net>
	<4EE9C15602000078000680D3@nat28.tlf.novell.com>
	<6738613108553D49BEFEFDD59230CCDF011BED93@G4W3300.americas.hpqcorp.net>
	<4EEA304402000078000684C8@nat28.tlf.novell.com>
In-Reply-To: <4EEA304402000078000684C8@nat28.tlf.novell.com>
X-Mailman-Approved-At: Fri, 16 Dec 2011 11:09:48 +0000
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] kmap_atomic issue with SLES11SP1 32bit XEN driver
 code
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Can you give me some URLs to documentation that can help me understand 
my issue?

Is sounds like I cannot go back to the correct virtual address after I 
map it for DMA.



On 12/15/2011 10:37 AM, Jan Beulich wrote:
>>>> On 15.12.11 at 17:15, "Brace, Don"<dab@hp.com>  wrote:
>> I do not understand what this means:
>> " That is, we'd be susceptible to this problem only if within a
>> lazy-mode enabled section k{,un}map_atomic were used
>> synchronously (which I'd consider a coding mistake)."
>>
>> Could you elaborate on this?
> Not sure what additional explanation is needed. kmap_atomic() is
> intended to be used in atomic context, and if you use it elsewhere
> that's a mis-use.
>
>> Here is what I am trying to do.
>> I am in a LLD I have bus addresses that are DMA-able that I would normally
>> DMA to except this driver is emulating hardware in software and so it does
>> not need to DMA is needs to transfer the data with the CPU.
> So this makes clear that what I told you about a possibly missing
> translation is likely the culprit. Quoting from your original mail
>
>                   linux_page = __pfn_to_page(physical_address>>  PAGE_SHIFT);
>
> I have to assume that physical_address really isn't a physical address,
> but a bus one. Hence you first need to translate it to a physical one
> before passing it to __pfn_to_page().
>
>> On non-XEN 32bit kernels I use kmap_atomic() and it handles both highmem
>> addresses and non highmem addresses with no issues.
> And so does it on Xen.
>
>> When I am running 32bit XEN kernels I run into issues like this:
>>      "BUG: unable to handle kernel paging request at 9822bf40"
> Because you pass in a random struct page *.
>
> Jan
>

-- 
Don Brace
SPSN Linux Development
Hewlett-Packard Company

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 11:10:04 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 11:10:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbVfj-0008O2-Pm; Fri, 16 Dec 2011 11:09:51 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <dab@hp.com>)
	id 1RbKYH-00038U-Jz
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 23:17:25 +0000
X-Env-Sender: dab@hp.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1323991013!45081156!1
X-Originating-IP: [15.201.24.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTUuMjAxLjI0LjIwID0+IDc5NDg4NQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14992 invoked from network); 15 Dec 2011 23:16:54 -0000
Received: from g4t0017.houston.hp.com (HELO g4t0017.houston.hp.com)
	(15.201.24.20)
	by server-12.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 15 Dec 2011 23:16:54 -0000
Received: from g4t0009.houston.hp.com (g4t0009.houston.hp.com [16.234.32.26])
	by g4t0017.houston.hp.com (Postfix) with ESMTP id 01265380E0;
	Thu, 15 Dec 2011 23:17:22 +0000 (UTC)
Received: from [10.10.13.84] (data.cce.hp.com [16.84.84.25])
	by g4t0009.houston.hp.com (Postfix) with ESMTP id 6F4ECC3E1;
	Thu, 15 Dec 2011 23:17:21 +0000 (UTC)
Message-ID: <4EEA8084.8030208@hp.com>
Date: Thu, 15 Dec 2011 17:19:32 -0600
From: dbrace <dab@hp.com>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <4EDFDF0D.2020104@hp.com>
	<4EE628D80200007800066F9E@nat28.tlf.novell.com>
	<20111214213443.GC25896@andromeda.dapyr.net>
	<4EE9C15602000078000680D3@nat28.tlf.novell.com>
	<6738613108553D49BEFEFDD59230CCDF011BED93@G4W3300.americas.hpqcorp.net>
	<4EEA304402000078000684C8@nat28.tlf.novell.com>
In-Reply-To: <4EEA304402000078000684C8@nat28.tlf.novell.com>
X-Mailman-Approved-At: Fri, 16 Dec 2011 11:09:48 +0000
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] kmap_atomic issue with SLES11SP1 32bit XEN driver
 code
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Can you give me some URLs to documentation that can help me understand 
my issue?

Is sounds like I cannot go back to the correct virtual address after I 
map it for DMA.



On 12/15/2011 10:37 AM, Jan Beulich wrote:
>>>> On 15.12.11 at 17:15, "Brace, Don"<dab@hp.com>  wrote:
>> I do not understand what this means:
>> " That is, we'd be susceptible to this problem only if within a
>> lazy-mode enabled section k{,un}map_atomic were used
>> synchronously (which I'd consider a coding mistake)."
>>
>> Could you elaborate on this?
> Not sure what additional explanation is needed. kmap_atomic() is
> intended to be used in atomic context, and if you use it elsewhere
> that's a mis-use.
>
>> Here is what I am trying to do.
>> I am in a LLD I have bus addresses that are DMA-able that I would normally
>> DMA to except this driver is emulating hardware in software and so it does
>> not need to DMA is needs to transfer the data with the CPU.
> So this makes clear that what I told you about a possibly missing
> translation is likely the culprit. Quoting from your original mail
>
>                   linux_page = __pfn_to_page(physical_address>>  PAGE_SHIFT);
>
> I have to assume that physical_address really isn't a physical address,
> but a bus one. Hence you first need to translate it to a physical one
> before passing it to __pfn_to_page().
>
>> On non-XEN 32bit kernels I use kmap_atomic() and it handles both highmem
>> addresses and non highmem addresses with no issues.
> And so does it on Xen.
>
>> When I am running 32bit XEN kernels I run into issues like this:
>>      "BUG: unable to handle kernel paging request at 9822bf40"
> Because you pass in a random struct page *.
>
> Jan
>

-- 
Don Brace
SPSN Linux Development
Hewlett-Packard Company

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 11:10:04 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 11:10:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbVfi-0008NH-GG; Fri, 16 Dec 2011 11:09:50 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <dab@hp.com>)
	id 1RazT9-0000Un-Rt
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 00:46:44 +0000
X-Env-Sender: dab@hp.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1323909946!7472008!1
X-Originating-IP: [15.192.0.46]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTUuMTkyLjAuNDYgPT4gNjE5NjAy\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26354 invoked from network); 15 Dec 2011 00:45:47 -0000
Received: from g5t0009.atlanta.hp.com (HELO g5t0009.atlanta.hp.com)
	(15.192.0.46)
	by server-3.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 15 Dec 2011 00:45:47 -0000
Received: from g5t0029.atlanta.hp.com (g5t0029.atlanta.hp.com [16.228.8.141])
	by g5t0009.atlanta.hp.com (Postfix) with ESMTP id 99C7F30167;
	Thu, 15 Dec 2011 00:45:45 +0000 (UTC)
Received: from [10.10.13.84] (data.cce.hp.com [16.84.84.25])
	by g5t0029.atlanta.hp.com (Postfix) with ESMTP id 48B752025A;
	Thu, 15 Dec 2011 00:45:45 +0000 (UTC)
Message-ID: <4EE943BA.6010202@hp.com>
Date: Wed, 14 Dec 2011 18:47:54 -0600
From: dbrace <dab@hp.com>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <4EDFDF0D.2020104@hp.com>
	<4EE628D80200007800066F9E@nat28.tlf.novell.com>
In-Reply-To: <4EE628D80200007800066F9E@nat28.tlf.novell.com>
X-Mailman-Approved-At: Fri, 16 Dec 2011 11:09:48 +0000
Cc: xen-devel@lists.xensource.com,
	"scameron@beardog.cce.hp.com" <scameron@beardog.cce.hp.com>
Subject: Re: [Xen-devel] kmap_atomic issue with SLES11SP1 32bit XEN driver
 code
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>... without knowing where you got physical_address from it's impossible
>>to tell whether your problem is that under Xen physical and machine
>>(sometimes called "bus") addresses being distinct (end hence you're
??possibly lacking a translation between the two).


Is there a way to tell from the address is this is happening?

On 12/12/2011 09:16 AM, Jan Beulich wrote:
>>>> On 07.12.11 at 22:47, dbrace<dab@hp.com>  wrote:
>> kernel: Linux 360 2.6.32.12-0.7-xen #1 SMP 2010-05-20 11:14:20 +0200
>> i686 i686 i386 GNU/Linux
> Pretty outdated.
>
>> I am having issues with some code that uses kmap_atomic(). I am getting:
>>
>> BUG: unable to handle kernel paging request at 23a1a000 (which is the
>> address returned from kmap_atomic().)
> For a valid high memory page this is surely not being returned by
> kmap_atomic(), so we have to assume that what you started with is
> the address of a low memory one.
>
>> The same code works when running on non-XEN 32bit kernels so I am
>> wondering why this does not work under
>> XEN kernels. Is there a different approach that I need to take for 32bit
>> XEN kernels?
> No, but ...
>
>> I really only need to do this code segment if the memory address is a
>> high memory address. Is there a MACRO or function
>> that can help me determine this?
> PageHighMem().
>
>> Here is a code snippet:
>>
>>                   void *linux_vaddr = NULL;       /* kmapped temporary
>> virtual address */
>>                   int linux_page_offset = 0;      /* offset in page */
>>                   int count = 0;                  /* bytes left to
>> transfer */
>>                   int left = byte_count;          /* number of bytes left
>> to transfer */
>>                   int memcpysize = 0;             /* current size to
>> transfer */
>>                   struct page *linux_page = NULL; /* calculated page */
>>                   int kmap_flags = 0;
>>
>>                   linux_page = __pfn_to_page(physical_address>>  PAGE_SHIFT);
> ... without knowing where you got physical_address from it's impossible
> to tell whether your problem is that under Xen physical and machine
> (sometimes called "bus") addresses being distinct (end hence you're
> possibly lacking a translation between the two).
>
> Jan
>
>>                   linux_page_offset = (physical_address&
>> 0x0000000000000FFFULL);
>>                   memcpysize =  min((PAGE_SIZE - linux_page_offset), left);
>>
>>                   kmap_flags = KM_USER0;
>>
>>                   linux_vaddr = kmap_atomic(linux_page, kmap_flags) +
>> linux_page_offset;
>>
>>                   printk("%s: called kmap_atomic, "
>>                           "calling memcpy linux_vaddr = 0x%x virt_address
>> = 0x%x count = 0x%x\n",
>>                           __func__, linux_vaddr, virt_address, count);
>>                   /*
>>                    * Either need to copy to a kmapped destination
>>                    * or a kmapped source.
>>                    */
>>                   if (type == 0) // Write to s/g element, dest virtual
>> addr was known.
>>                           memcpy((void *)virt_address+count, (void
>> *)linux_vaddr, memcpysize);
>>                   else // Source virt. address was known.
>>                           memcpy((void *)linux_vaddr, (void
>> *)virt_address+count, memcpysize);
>>
>>                   printk("OS_Linux32_Xfer_SG_Page: calling kunmap_atomic, "
>>                           "calling memcpy linux_vaddr = 0x%lx\n",
>> linux_vaddr);
>>
>>                   kunmap_atomic(linux_vaddr, kmap_flags);
>>
>>
>> -- 
>> Don Brace
>> SPSN Linux Development
>> Hewlett-Packard Company
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel
>
>

-- 
Don Brace
SPSN Linux Development
Hewlett-Packard Company

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 11:10:04 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 11:10:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbVfi-0008NH-GG; Fri, 16 Dec 2011 11:09:50 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <dab@hp.com>)
	id 1RazT9-0000Un-Rt
	for xen-devel@lists.xensource.com; Thu, 15 Dec 2011 00:46:44 +0000
X-Env-Sender: dab@hp.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1323909946!7472008!1
X-Originating-IP: [15.192.0.46]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTUuMTkyLjAuNDYgPT4gNjE5NjAy\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26354 invoked from network); 15 Dec 2011 00:45:47 -0000
Received: from g5t0009.atlanta.hp.com (HELO g5t0009.atlanta.hp.com)
	(15.192.0.46)
	by server-3.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 15 Dec 2011 00:45:47 -0000
Received: from g5t0029.atlanta.hp.com (g5t0029.atlanta.hp.com [16.228.8.141])
	by g5t0009.atlanta.hp.com (Postfix) with ESMTP id 99C7F30167;
	Thu, 15 Dec 2011 00:45:45 +0000 (UTC)
Received: from [10.10.13.84] (data.cce.hp.com [16.84.84.25])
	by g5t0029.atlanta.hp.com (Postfix) with ESMTP id 48B752025A;
	Thu, 15 Dec 2011 00:45:45 +0000 (UTC)
Message-ID: <4EE943BA.6010202@hp.com>
Date: Wed, 14 Dec 2011 18:47:54 -0600
From: dbrace <dab@hp.com>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <4EDFDF0D.2020104@hp.com>
	<4EE628D80200007800066F9E@nat28.tlf.novell.com>
In-Reply-To: <4EE628D80200007800066F9E@nat28.tlf.novell.com>
X-Mailman-Approved-At: Fri, 16 Dec 2011 11:09:48 +0000
Cc: xen-devel@lists.xensource.com,
	"scameron@beardog.cce.hp.com" <scameron@beardog.cce.hp.com>
Subject: Re: [Xen-devel] kmap_atomic issue with SLES11SP1 32bit XEN driver
 code
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>... without knowing where you got physical_address from it's impossible
>>to tell whether your problem is that under Xen physical and machine
>>(sometimes called "bus") addresses being distinct (end hence you're
??possibly lacking a translation between the two).


Is there a way to tell from the address is this is happening?

On 12/12/2011 09:16 AM, Jan Beulich wrote:
>>>> On 07.12.11 at 22:47, dbrace<dab@hp.com>  wrote:
>> kernel: Linux 360 2.6.32.12-0.7-xen #1 SMP 2010-05-20 11:14:20 +0200
>> i686 i686 i386 GNU/Linux
> Pretty outdated.
>
>> I am having issues with some code that uses kmap_atomic(). I am getting:
>>
>> BUG: unable to handle kernel paging request at 23a1a000 (which is the
>> address returned from kmap_atomic().)
> For a valid high memory page this is surely not being returned by
> kmap_atomic(), so we have to assume that what you started with is
> the address of a low memory one.
>
>> The same code works when running on non-XEN 32bit kernels so I am
>> wondering why this does not work under
>> XEN kernels. Is there a different approach that I need to take for 32bit
>> XEN kernels?
> No, but ...
>
>> I really only need to do this code segment if the memory address is a
>> high memory address. Is there a MACRO or function
>> that can help me determine this?
> PageHighMem().
>
>> Here is a code snippet:
>>
>>                   void *linux_vaddr = NULL;       /* kmapped temporary
>> virtual address */
>>                   int linux_page_offset = 0;      /* offset in page */
>>                   int count = 0;                  /* bytes left to
>> transfer */
>>                   int left = byte_count;          /* number of bytes left
>> to transfer */
>>                   int memcpysize = 0;             /* current size to
>> transfer */
>>                   struct page *linux_page = NULL; /* calculated page */
>>                   int kmap_flags = 0;
>>
>>                   linux_page = __pfn_to_page(physical_address>>  PAGE_SHIFT);
> ... without knowing where you got physical_address from it's impossible
> to tell whether your problem is that under Xen physical and machine
> (sometimes called "bus") addresses being distinct (end hence you're
> possibly lacking a translation between the two).
>
> Jan
>
>>                   linux_page_offset = (physical_address&
>> 0x0000000000000FFFULL);
>>                   memcpysize =  min((PAGE_SIZE - linux_page_offset), left);
>>
>>                   kmap_flags = KM_USER0;
>>
>>                   linux_vaddr = kmap_atomic(linux_page, kmap_flags) +
>> linux_page_offset;
>>
>>                   printk("%s: called kmap_atomic, "
>>                           "calling memcpy linux_vaddr = 0x%x virt_address
>> = 0x%x count = 0x%x\n",
>>                           __func__, linux_vaddr, virt_address, count);
>>                   /*
>>                    * Either need to copy to a kmapped destination
>>                    * or a kmapped source.
>>                    */
>>                   if (type == 0) // Write to s/g element, dest virtual
>> addr was known.
>>                           memcpy((void *)virt_address+count, (void
>> *)linux_vaddr, memcpysize);
>>                   else // Source virt. address was known.
>>                           memcpy((void *)linux_vaddr, (void
>> *)virt_address+count, memcpysize);
>>
>>                   printk("OS_Linux32_Xfer_SG_Page: calling kunmap_atomic, "
>>                           "calling memcpy linux_vaddr = 0x%lx\n",
>> linux_vaddr);
>>
>>                   kunmap_atomic(linux_vaddr, kmap_flags);
>>
>>
>> -- 
>> Don Brace
>> SPSN Linux Development
>> Hewlett-Packard Company
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel
>
>

-- 
Don Brace
SPSN Linux Development
Hewlett-Packard Company

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 11:10:04 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 11:10:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbVfh-0008Mr-Ly; Fri, 16 Dec 2011 11:09:49 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jan.vejvalka@lfmotol.cuni.cz>) id 1RatKx-0003Ig-2t
	for xen-DEVEL@lists.xensource.com; Wed, 14 Dec 2011 18:13:51 +0000
X-Env-Sender: jan.vejvalka@lfmotol.cuni.cz
X-Msg-Ref: server-2.tower-216.messagelabs.com!1323886375!8820842!1
X-Originating-IP: [195.113.40.14]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23519 invoked from network); 14 Dec 2011 18:12:55 -0000
Received: from mailer.lf2.cuni.cz (HELO sakal.lf2.cuni.cz) (195.113.40.14)
	by server-2.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Dec 2011 18:12:55 -0000
Received: from kremail.lf2.cuni.cz (kremail [195.113.40.28])
	by sakal.lf2.cuni.cz (8.14.3/8.14.3) with ESMTP id pBEICsY3032673
	for <xen-DEVEL@lists.xensource.com>; Wed, 14 Dec 2011 19:12:54 +0100
Received: from [195.113.43.131] ([195.113.43.131]) (authenticated bits=0)
	by kremail.lf2.cuni.cz (8.13.7/8.13.7) with ESMTP id pBEICpQH025905
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <xen-DEVEL@lists.xensource.com>; Wed, 14 Dec 2011 19:12:54 +0100
Message-ID: <4EE8E725.30208@lfmotol.cuni.cz>
Date: Wed, 14 Dec 2011 19:12:53 +0100
From: Jan Vejvalka <jan.vejvalka@lfmotol.cuni.cz>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: xen-DEVEL@lists.xensource.com
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3
	(sakal.lf2.cuni.cz [195.113.40.14]);
	Wed, 14 Dec 2011 19:12:54 +0100 (CET)
X-Spam-Status: No, hits=-0.2, tests=AWL=-0.232,BAYES_50=0.001,
	rbl=<dns:lfmotol.cuni.cz?type=MX> [20 mailer.lf2.cuni.cz.],
X-Mailman-Approved-At: Fri, 16 Dec 2011 11:09:48 +0000
Subject: [Xen-devel] Failure to start X windows in Dom0 under Xen 4.1.2
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi *,

   after two unsuccessful attempts to get help on xen-users, I dare to
re-post my problem to zen-devel.
I'll be grateful for any hint.

Trying to run X windows on Linux 3.1.1 Dom0 kernel under Xen 4.1.2
(built as http://slackbuilds.org/repository/13.37/system/xen/) on
Slackware 64-13.37. (The next step should be a HVM guest driven through
a vnc window from Dom0).

On the same kernel booted natively, all works fine; when booting under
Xen, Xorg does not start. The (relevant?) error messages that I find in
Xorg.0.log are

(WW) System lacks support for changing MTRRs
(EE) VESA(0): V_BIOS address 0x0 out of range

(the full diff of the respective Xorg.0.log-s is at
http://camelot.lf2.cuni.cz/vejvalka/posts/xlog-diff)

What is it that I am missing ?
Thanks for any hint,

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 11:10:04 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 11:10:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbVfh-0008Mr-Ly; Fri, 16 Dec 2011 11:09:49 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jan.vejvalka@lfmotol.cuni.cz>) id 1RatKx-0003Ig-2t
	for xen-DEVEL@lists.xensource.com; Wed, 14 Dec 2011 18:13:51 +0000
X-Env-Sender: jan.vejvalka@lfmotol.cuni.cz
X-Msg-Ref: server-2.tower-216.messagelabs.com!1323886375!8820842!1
X-Originating-IP: [195.113.40.14]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23519 invoked from network); 14 Dec 2011 18:12:55 -0000
Received: from mailer.lf2.cuni.cz (HELO sakal.lf2.cuni.cz) (195.113.40.14)
	by server-2.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Dec 2011 18:12:55 -0000
Received: from kremail.lf2.cuni.cz (kremail [195.113.40.28])
	by sakal.lf2.cuni.cz (8.14.3/8.14.3) with ESMTP id pBEICsY3032673
	for <xen-DEVEL@lists.xensource.com>; Wed, 14 Dec 2011 19:12:54 +0100
Received: from [195.113.43.131] ([195.113.43.131]) (authenticated bits=0)
	by kremail.lf2.cuni.cz (8.13.7/8.13.7) with ESMTP id pBEICpQH025905
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <xen-DEVEL@lists.xensource.com>; Wed, 14 Dec 2011 19:12:54 +0100
Message-ID: <4EE8E725.30208@lfmotol.cuni.cz>
Date: Wed, 14 Dec 2011 19:12:53 +0100
From: Jan Vejvalka <jan.vejvalka@lfmotol.cuni.cz>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: xen-DEVEL@lists.xensource.com
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3
	(sakal.lf2.cuni.cz [195.113.40.14]);
	Wed, 14 Dec 2011 19:12:54 +0100 (CET)
X-Spam-Status: No, hits=-0.2, tests=AWL=-0.232,BAYES_50=0.001,
	rbl=<dns:lfmotol.cuni.cz?type=MX> [20 mailer.lf2.cuni.cz.],
X-Mailman-Approved-At: Fri, 16 Dec 2011 11:09:48 +0000
Subject: [Xen-devel] Failure to start X windows in Dom0 under Xen 4.1.2
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi *,

   after two unsuccessful attempts to get help on xen-users, I dare to
re-post my problem to zen-devel.
I'll be grateful for any hint.

Trying to run X windows on Linux 3.1.1 Dom0 kernel under Xen 4.1.2
(built as http://slackbuilds.org/repository/13.37/system/xen/) on
Slackware 64-13.37. (The next step should be a HVM guest driven through
a vnc window from Dom0).

On the same kernel booted natively, all works fine; when booting under
Xen, Xorg does not start. The (relevant?) error messages that I find in
Xorg.0.log are

(WW) System lacks support for changing MTRRs
(EE) VESA(0): V_BIOS address 0x0 out of range

(the full diff of the respective Xorg.0.log-s is at
http://camelot.lf2.cuni.cz/vejvalka/posts/xlog-diff)

What is it that I am missing ?
Thanks for any hint,

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 11:12:51 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 11:12:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbViV-0001az-Ox; Fri, 16 Dec 2011 11:12:43 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RbViU-0001Yg-JF
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 11:12:42 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1324033956!8482235!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjU3OQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29725 invoked from network); 16 Dec 2011 11:12:36 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Dec 2011 11:12:36 -0000
X-IronPort-AV: E=Sophos;i="4.71,362,1320624000"; 
   d="scan'208";a="9510525"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Dec 2011 11:12:35 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 16 Dec 2011 11:12:35 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Fri, 16 Dec 2011 11:12:35 +0000
In-Reply-To: <20202.12827.152139.501847@mariner.uk.xensource.com>
References: <patchbomb.1323768375@loki.upc.es>
	<35c322e6020501447936.1323768387@loki.upc.es>
	<20199.26896.928532.781947@mariner.uk.xensource.com>
	<CAPLaKK6wqa+VAxgzLWudQ2C2kaoXww9KK3BQhU4fKmoCAMFCzQ@mail.gmail.com>
	<1323860097.20077.394.camel@zakaz.uk.xensource.com>
	<CAPLaKK7Wv2HeRbg5Ze=B8DFe=wbzq=V35s6WVFXqrynh0ikRTw@mail.gmail.com>
	<20200.36683.601224.172611@mariner.uk.xensource.com>
	<CAPLaKK5h2PJko6o4v3usJkfttfdFqp9L6DEnfs0YYSSBWS63Eg@mail.gmail.com>
	<1323865369.20077.412.camel@zakaz.uk.xensource.com>
	<20202.12827.152139.501847@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1324033955.20077.584.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Roger Pau Monn? <roger.pau@entel.upc.edu>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 12 of 14 v4] libxl: set frontend status to 6
 on domain destroy
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2011-12-15 at 17:44 +0000, Ian Jackson wrote:
> I have been thinking about this whole area.
> 
> Originally my opinion was that the block and network setup scripts
> (eg, setting up loopback devices or iscsi or bridging whatever) should
> be executed directly by xl.  This naturally gives the best error
> handling and makes logging easiest.
> 
> However, if we are serious about supporting driver domains, or indeed
> any kind of backend not running in the same domain as libxl, then
> something in the driver domain needs to be responsible for executing
> these scripts (or equivalent).
> 
> The obvious way to communicate this information to the driver domain
> is via xenstore.
> 
> What we should be discussing is exactly how the driver domain
> translates that into script execution.  Currently on Linux this is
> mostly done with udev, and AIUI on BSD using xenbackendd.

xenbackendd is (AFAIK) watching for events (e.g. creation and deletion
of backend state nodes) in xenstore so at least in concept it is
portable to all OSes, whereas udev is pretty Linux specific.

One nice effect of the udev approach is that you get an explicit event
e.g. when a block device is torn down. This makes it trivial to avoid
problems like racing to teardown a loopback device.

Since xenbackendd is mostly inferring things by watching the backend
nodes used by the kernel side drivers it struggles due to the model
where we rm the backend's xenstore directory on destroy which nukes
state required by xenbackendd. 
The xenbackendd model seems slightly preferable to me, it's simpler to
setup and more portable. Doing things differently on different OSes
doesn't help with the confusion here!

Perhaps the core functionality could be in libxl such that a toolstack
can choose to integrate the functionality or run it as a separate daemon
as necessary?

The main issue with the xenbackendd model is the manner in which it has
to guess what is going on and try to synchronise with what the drivers
are going. This does also effect the udev driven way of doing things too
since the scripts often want to look in xenstore for parameters and on
destroy they are often missing.

We currently get this wrong under Linux at the minute and the network
teardown hotplug script doesn't work right because the necessary bits
are gone from xenstore. We mostly get away with this for bridging since
the device is automatically remove from the bridge but for vswitch we do
need to actually do some reconfiguration at this point. We also appear
to leak iptables rules under some circumstances.

Perhaps we would be better off splitting the hotplug stuff into its own
place in xenstore and have the toolstack explicitly trigger events at
the right time by writing to it? This could be compatible with existing
scripts since they use an environment variable to find their xenstore
base path.

We need to be aware that the script models (or at least the sequencing
wrt the xenstore state transitions) vary slightly with the device type
since for block devices you typically need to run the hotplug script
before creating the backend whereas with network devices you create the
device first and then run the script to configure it. vice versa for
destroy.

We also need to consider Network tap devices. Not all tap devices are
part of Xen's world which is a wrinkle which needs thought.

I tried to write down my understanding of the events and sequencing
under Linux but that mostly showed the gaps in my understanding...

AIUI XCP does a lot more of this stuff via xenstored and have been
(successfully) playing with driver domains -- we should ask for their
input.

> So sorry for leading this discussion in what I now think may be a
> wrong direction.
> 
> Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 11:12:51 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 11:12:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbViV-0001az-Ox; Fri, 16 Dec 2011 11:12:43 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RbViU-0001Yg-JF
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 11:12:42 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1324033956!8482235!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjU3OQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29725 invoked from network); 16 Dec 2011 11:12:36 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Dec 2011 11:12:36 -0000
X-IronPort-AV: E=Sophos;i="4.71,362,1320624000"; 
   d="scan'208";a="9510525"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Dec 2011 11:12:35 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 16 Dec 2011 11:12:35 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Fri, 16 Dec 2011 11:12:35 +0000
In-Reply-To: <20202.12827.152139.501847@mariner.uk.xensource.com>
References: <patchbomb.1323768375@loki.upc.es>
	<35c322e6020501447936.1323768387@loki.upc.es>
	<20199.26896.928532.781947@mariner.uk.xensource.com>
	<CAPLaKK6wqa+VAxgzLWudQ2C2kaoXww9KK3BQhU4fKmoCAMFCzQ@mail.gmail.com>
	<1323860097.20077.394.camel@zakaz.uk.xensource.com>
	<CAPLaKK7Wv2HeRbg5Ze=B8DFe=wbzq=V35s6WVFXqrynh0ikRTw@mail.gmail.com>
	<20200.36683.601224.172611@mariner.uk.xensource.com>
	<CAPLaKK5h2PJko6o4v3usJkfttfdFqp9L6DEnfs0YYSSBWS63Eg@mail.gmail.com>
	<1323865369.20077.412.camel@zakaz.uk.xensource.com>
	<20202.12827.152139.501847@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1324033955.20077.584.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Roger Pau Monn? <roger.pau@entel.upc.edu>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 12 of 14 v4] libxl: set frontend status to 6
 on domain destroy
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2011-12-15 at 17:44 +0000, Ian Jackson wrote:
> I have been thinking about this whole area.
> 
> Originally my opinion was that the block and network setup scripts
> (eg, setting up loopback devices or iscsi or bridging whatever) should
> be executed directly by xl.  This naturally gives the best error
> handling and makes logging easiest.
> 
> However, if we are serious about supporting driver domains, or indeed
> any kind of backend not running in the same domain as libxl, then
> something in the driver domain needs to be responsible for executing
> these scripts (or equivalent).
> 
> The obvious way to communicate this information to the driver domain
> is via xenstore.
> 
> What we should be discussing is exactly how the driver domain
> translates that into script execution.  Currently on Linux this is
> mostly done with udev, and AIUI on BSD using xenbackendd.

xenbackendd is (AFAIK) watching for events (e.g. creation and deletion
of backend state nodes) in xenstore so at least in concept it is
portable to all OSes, whereas udev is pretty Linux specific.

One nice effect of the udev approach is that you get an explicit event
e.g. when a block device is torn down. This makes it trivial to avoid
problems like racing to teardown a loopback device.

Since xenbackendd is mostly inferring things by watching the backend
nodes used by the kernel side drivers it struggles due to the model
where we rm the backend's xenstore directory on destroy which nukes
state required by xenbackendd. 
The xenbackendd model seems slightly preferable to me, it's simpler to
setup and more portable. Doing things differently on different OSes
doesn't help with the confusion here!

Perhaps the core functionality could be in libxl such that a toolstack
can choose to integrate the functionality or run it as a separate daemon
as necessary?

The main issue with the xenbackendd model is the manner in which it has
to guess what is going on and try to synchronise with what the drivers
are going. This does also effect the udev driven way of doing things too
since the scripts often want to look in xenstore for parameters and on
destroy they are often missing.

We currently get this wrong under Linux at the minute and the network
teardown hotplug script doesn't work right because the necessary bits
are gone from xenstore. We mostly get away with this for bridging since
the device is automatically remove from the bridge but for vswitch we do
need to actually do some reconfiguration at this point. We also appear
to leak iptables rules under some circumstances.

Perhaps we would be better off splitting the hotplug stuff into its own
place in xenstore and have the toolstack explicitly trigger events at
the right time by writing to it? This could be compatible with existing
scripts since they use an environment variable to find their xenstore
base path.

We need to be aware that the script models (or at least the sequencing
wrt the xenstore state transitions) vary slightly with the device type
since for block devices you typically need to run the hotplug script
before creating the backend whereas with network devices you create the
device first and then run the script to configure it. vice versa for
destroy.

We also need to consider Network tap devices. Not all tap devices are
part of Xen's world which is a wrinkle which needs thought.

I tried to write down my understanding of the events and sequencing
under Linux but that mostly showed the gaps in my understanding...

AIUI XCP does a lot more of this stuff via xenstored and have been
(successfully) playing with driver domains -- we should ask for their
input.

> So sorry for leading this discussion in what I now think may be a
> wrong direction.
> 
> Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 11:33:41 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 11:33:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbW2V-0002uI-1i; Fri, 16 Dec 2011 11:33:23 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RbW2T-0002tt-E8
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 11:33:21 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-11.tower-21.messagelabs.com!1324035195!8114159!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzMzExNDY=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzMzExNDY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1026 invoked from network); 16 Dec 2011 11:33:15 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-11.tower-21.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 16 Dec 2011 11:33:15 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1324035194; l=1525;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=s9HqiZj9NwS6e7mLiFawmNWKTpg=;
	b=Kmf6HLElFuVzXBvkXt/NxY+oo9hpONsDqhht0RRqned8+2Mbp3RsGFA5Cyxi9gNzem/
	VOcIs1bUSGsTwEMeqzpeIWzfzhtTeWCiCQKSMHK4zr0BVns1CgOEZ5jQcyZ6Ps+qPkOlQ
	lwOvrzNTDQISCGDj0LUYQOXBZOA1gkJWnE0=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFPjzEQG5of
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-112-083.pools.arcor-ip.net [88.65.112.83])
	by smtp.strato.de (fruni mo56) (RZmta 26.15 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id 5053c6nBGAPCxk ;
	Fri, 16 Dec 2011 12:33:01 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 8E94D18637; Fri, 16 Dec 2011 12:33:00 +0100 (CET)
Date: Fri, 16 Dec 2011 12:33:00 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
Message-ID: <20111216113300.GA4854@aepfle.de>
References: <4EEA4877.8010307@canonical.com>
	<20111215193942.GA7640@andromeda.dapyr.net>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20111215193942.GA7640@andromeda.dapyr.net>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefan Bader <stefan.bader@canonical.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] xenbus and the message of doom
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Dec 15, Konrad Rzeszutek Wilk wrote:

> On Thu, Dec 15, 2011 at 08:20:23PM +0100, Stefan Bader wrote:
> > I was investigating a bug report[1] about newer kernels (>3.1) not booting as
> > HVM guests on Amazon EC2. For some reason git bisect did give the some pain, but
> > it lead me at least close and with some crash dump data I think I figured the
> > problem.
> 
> Stefan, thanks for finding this.
> 
> Olaf, what are your thoughts? Should I prep a patch to revert the patch
> below and then we can work on 3.3 and rethink this in 3.3? The clock is
> ticking for 3.2 and there is not much runway to fix stuff.

Sometimes guest changes expose bugs in the host. Its my understanding
that hosts should be kept uptodate so that it can serve both old and new
guests well.

In my testing with Xen4 based hosts their xenstored did properly ignore
the new command.

I proposed several ways to get rid of existing watches, but finally we
came to the conclusion that a new xenstored command would be the
cleanest way.

Wether adding a timeout is a good idea has to be decided. I can imagine
that a busy host may take some time to respond to guest commands.


Perhaps we should figure out what exactly EC2 is using as host and why
it only breaks with upstream kernels. So far I havent received reports
for SLES11 guests. SP1 got an update recently, so their HVM guests would
have seen the hang as well. The not yet released SP2 sends
XS_RESET_WATCHES as well since quite some time.


Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 11:33:41 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 11:33:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbW2V-0002uI-1i; Fri, 16 Dec 2011 11:33:23 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RbW2T-0002tt-E8
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 11:33:21 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-11.tower-21.messagelabs.com!1324035195!8114159!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzMzExNDY=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzMzExNDY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1026 invoked from network); 16 Dec 2011 11:33:15 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-11.tower-21.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 16 Dec 2011 11:33:15 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1324035194; l=1525;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=s9HqiZj9NwS6e7mLiFawmNWKTpg=;
	b=Kmf6HLElFuVzXBvkXt/NxY+oo9hpONsDqhht0RRqned8+2Mbp3RsGFA5Cyxi9gNzem/
	VOcIs1bUSGsTwEMeqzpeIWzfzhtTeWCiCQKSMHK4zr0BVns1CgOEZ5jQcyZ6Ps+qPkOlQ
	lwOvrzNTDQISCGDj0LUYQOXBZOA1gkJWnE0=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFPjzEQG5of
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-112-083.pools.arcor-ip.net [88.65.112.83])
	by smtp.strato.de (fruni mo56) (RZmta 26.15 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id 5053c6nBGAPCxk ;
	Fri, 16 Dec 2011 12:33:01 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 8E94D18637; Fri, 16 Dec 2011 12:33:00 +0100 (CET)
Date: Fri, 16 Dec 2011 12:33:00 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
Message-ID: <20111216113300.GA4854@aepfle.de>
References: <4EEA4877.8010307@canonical.com>
	<20111215193942.GA7640@andromeda.dapyr.net>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20111215193942.GA7640@andromeda.dapyr.net>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefan Bader <stefan.bader@canonical.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] xenbus and the message of doom
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Dec 15, Konrad Rzeszutek Wilk wrote:

> On Thu, Dec 15, 2011 at 08:20:23PM +0100, Stefan Bader wrote:
> > I was investigating a bug report[1] about newer kernels (>3.1) not booting as
> > HVM guests on Amazon EC2. For some reason git bisect did give the some pain, but
> > it lead me at least close and with some crash dump data I think I figured the
> > problem.
> 
> Stefan, thanks for finding this.
> 
> Olaf, what are your thoughts? Should I prep a patch to revert the patch
> below and then we can work on 3.3 and rethink this in 3.3? The clock is
> ticking for 3.2 and there is not much runway to fix stuff.

Sometimes guest changes expose bugs in the host. Its my understanding
that hosts should be kept uptodate so that it can serve both old and new
guests well.

In my testing with Xen4 based hosts their xenstored did properly ignore
the new command.

I proposed several ways to get rid of existing watches, but finally we
came to the conclusion that a new xenstored command would be the
cleanest way.

Wether adding a timeout is a good idea has to be decided. I can imagine
that a busy host may take some time to respond to guest commands.


Perhaps we should figure out what exactly EC2 is using as host and why
it only breaks with upstream kernels. So far I havent received reports
for SLES11 guests. SP1 got an update recently, so their HVM guests would
have seen the hang as well. The not yet released SP2 sends
XS_RESET_WATCHES as well since quite some time.


Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 11:44:49 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 11:44:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbWDH-0003G5-Eb; Fri, 16 Dec 2011 11:44:31 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RbWDF-0003Fv-R0
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 11:44:30 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1324035863!5807309!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjU3OQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14551 invoked from network); 16 Dec 2011 11:44:23 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Dec 2011 11:44:23 -0000
X-IronPort-AV: E=Sophos;i="4.71,362,1320624000"; 
   d="scan'208";a="9511701"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Dec 2011 11:44:22 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 16 Dec 2011 11:44:22 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Wei Wang2 <wei.wang2@amd.com>
Date: Fri, 16 Dec 2011 11:44:22 +0000
In-Reply-To: <201112151810.20262.wei.wang2@amd.com>
References: <patchbomb.1323876561@gran.amd.com>
	<201112151552.09037.wei.wang2@amd.com>
	<1323968359.20077.501.camel@zakaz.uk.xensource.com>
	<201112151810.20262.wei.wang2@amd.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1324035862.20077.587.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Keir
	\(Xen.org\)" <keir@xen.org>, "JBeulich@suse.com" <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 16 of 16] libxl: add iommu parameter to
 qemu-dm
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2011-12-15 at 17:10 +0000, Wei Wang2 wrote:
> 
> >
> > > Also I cannot make a reference of libxl_domain_build_info in
> > > libxl__build_device_model_args.
> >
> > You just need to plumb the variable through. This is apparently just
> the
> > first time we have need of it.
> Ok, that sounds doable. I will fix that in the next version. 

Thanks.

I actually don't think libxl_device_model_info should really be exposed
to users of the library. That stuff all belongs in the build_info and
should be turned into dm config as necessary internally by the library.

However I don't expect you to take on that change!

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 11:44:49 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 11:44:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbWDH-0003G5-Eb; Fri, 16 Dec 2011 11:44:31 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RbWDF-0003Fv-R0
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 11:44:30 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1324035863!5807309!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjU3OQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14551 invoked from network); 16 Dec 2011 11:44:23 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Dec 2011 11:44:23 -0000
X-IronPort-AV: E=Sophos;i="4.71,362,1320624000"; 
   d="scan'208";a="9511701"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Dec 2011 11:44:22 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 16 Dec 2011 11:44:22 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Wei Wang2 <wei.wang2@amd.com>
Date: Fri, 16 Dec 2011 11:44:22 +0000
In-Reply-To: <201112151810.20262.wei.wang2@amd.com>
References: <patchbomb.1323876561@gran.amd.com>
	<201112151552.09037.wei.wang2@amd.com>
	<1323968359.20077.501.camel@zakaz.uk.xensource.com>
	<201112151810.20262.wei.wang2@amd.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1324035862.20077.587.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Keir
	\(Xen.org\)" <keir@xen.org>, "JBeulich@suse.com" <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 16 of 16] libxl: add iommu parameter to
 qemu-dm
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2011-12-15 at 17:10 +0000, Wei Wang2 wrote:
> 
> >
> > > Also I cannot make a reference of libxl_domain_build_info in
> > > libxl__build_device_model_args.
> >
> > You just need to plumb the variable through. This is apparently just
> the
> > first time we have need of it.
> Ok, that sounds doable. I will fix that in the next version. 

Thanks.

I actually don't think libxl_device_model_info should really be exposed
to users of the library. That stuff all belongs in the build_info and
should be turned into dm config as necessary internally by the library.

However I don't expect you to take on that change!

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 11:48:20 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 11:48:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbWGm-0003Nm-4W; Fri, 16 Dec 2011 11:48:08 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1RbWGl-0003NW-BP
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 11:48:07 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1324036080!5807874!1
X-Originating-IP: [143.182.124.37]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjEyNDkx\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26673 invoked from network); 16 Dec 2011 11:48:00 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37)
	by server-4.tower-174.messagelabs.com with SMTP;
	16 Dec 2011 11:48:00 -0000
Received: from azsmga002.ch.intel.com ([10.2.17.35])
	by azsmga102.ch.intel.com with ESMTP; 16 Dec 2011 03:47:59 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="47875143"
Received: from pgsmsx603.gar.corp.intel.com ([10.221.43.87])
	by AZSMGA002.ch.intel.com with ESMTP; 16 Dec 2011 03:47:58 -0800
Received: from shsmsx602.ccr.corp.intel.com (10.239.4.104) by
	pgsmsx603.gar.corp.intel.com (10.221.43.87) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Fri, 16 Dec 2011 19:47:57 +0800
Received: from shsmsx502.ccr.corp.intel.com ([10.239.4.96]) by
	SHSMSX602.ccr.corp.intel.com ([10.239.4.104]) with mapi;
	Fri, 16 Dec 2011 19:47:55 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Jan Beulich <JBeulich@suse.com>, "keir.xen@gmail.com"
	<keir.xen@gmail.com>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>
Date: Fri, 16 Dec 2011 19:47:54 +0800
Thread-Topic: X86-MCE: fix a bug of xen-mceinj tool
Thread-Index: Acy76IwZJ9WPzF5ZRRie/gDrkAgq7A==
Message-ID: <BC00F5384FCFC9499AF06F92E8B78A9E288CB0FF82@shsmsx502.ccr.corp.intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/mixed;
	boundary="_002_BC00F5384FCFC9499AF06F92E8B78A9E288CB0FF82shsmsx502ccrc_"
MIME-Version: 1.0
Subject: [Xen-devel] X86-MCE: fix a bug of xen-mceinj tool
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--_002_BC00F5384FCFC9499AF06F92E8B78A9E288CB0FF82shsmsx502ccrc_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

X86-MCE: fix a bug of xen-mceinj tool

Fix a bug of xen-mceinj tool which used to test mce by software way.

Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>

diff -r 86defe150053 tools/tests/mce-test/tools/xen-mceinj.c
--- a/tools/tests/mce-test/tools/xen-mceinj.c	Fri Dec 16 16:24:31 2011 +080=
0
+++ b/tools/tests/mce-test/tools/xen-mceinj.c	Fri Dec 16 17:28:38 2011 +080=
0
@@ -134,8 +134,12 @@ static int mca_cpuinfo(xc_interface *xc_
 {
     struct xen_mc mc;
=20
+    memset(&mc, 0, sizeof(struct xen_mc));
+
     mc.cmd =3D XEN_MC_physcpuinfo;
-    if (xc_mca_op(xc_handle, &mc))
+    mc.interface_version =3D XEN_MCA_INTERFACE_VERSION;
+
+    if (!xc_mca_op(xc_handle, &mc))
         return mc.u.mc_physcpuinfo.ncpus;
     else
         return 0;=

--_002_BC00F5384FCFC9499AF06F92E8B78A9E288CB0FF82shsmsx502ccrc_
Content-Type: application/octet-stream; name="mceinj-tools-fix.patch"
Content-Description: mceinj-tools-fix.patch
Content-Disposition: attachment; filename="mceinj-tools-fix.patch"; size=749;
	creation-date="Fri, 16 Dec 2011 19:45:08 GMT";
	modification-date="Fri, 16 Dec 2011 19:32:16 GMT"
Content-Transfer-Encoding: base64

WDg2LU1DRTogZml4IGEgYnVnIG9mIHhlbi1tY2VpbmogdG9vbAoKRml4IGEgYnVnIG9mIHhlbi1t
Y2VpbmogdG9vbCB3aGljaCB1c2VkIHRvIHRlc3QgbWNlIGJ5IHNvZnR3YXJlIHdheS4KClNpZ25l
ZC1vZmYtYnk6IExpdSwgSmluc29uZyA8amluc29uZy5saXVAaW50ZWwuY29tPgoKZGlmZiAtciA4
NmRlZmUxNTAwNTMgdG9vbHMvdGVzdHMvbWNlLXRlc3QvdG9vbHMveGVuLW1jZWluai5jCi0tLSBh
L3Rvb2xzL3Rlc3RzL21jZS10ZXN0L3Rvb2xzL3hlbi1tY2VpbmouYwlGcmkgRGVjIDE2IDE2OjI0
OjMxIDIwMTEgKzA4MDAKKysrIGIvdG9vbHMvdGVzdHMvbWNlLXRlc3QvdG9vbHMveGVuLW1jZWlu
ai5jCUZyaSBEZWMgMTYgMTc6Mjg6MzggMjAxMSArMDgwMApAQCAtMTM0LDggKzEzNCwxMiBAQCBz
dGF0aWMgaW50IG1jYV9jcHVpbmZvKHhjX2ludGVyZmFjZSAqeGNfCiB7CiAgICAgc3RydWN0IHhl
bl9tYyBtYzsKIAorICAgIG1lbXNldCgmbWMsIDAsIHNpemVvZihzdHJ1Y3QgeGVuX21jKSk7CisK
ICAgICBtYy5jbWQgPSBYRU5fTUNfcGh5c2NwdWluZm87Ci0gICAgaWYgKHhjX21jYV9vcCh4Y19o
YW5kbGUsICZtYykpCisgICAgbWMuaW50ZXJmYWNlX3ZlcnNpb24gPSBYRU5fTUNBX0lOVEVSRkFD
RV9WRVJTSU9OOworCisgICAgaWYgKCF4Y19tY2Ffb3AoeGNfaGFuZGxlLCAmbWMpKQogICAgICAg
ICByZXR1cm4gbWMudS5tY19waHlzY3B1aW5mby5uY3B1czsKICAgICBlbHNlCiAgICAgICAgIHJl
dHVybiAwOwo=

--_002_BC00F5384FCFC9499AF06F92E8B78A9E288CB0FF82shsmsx502ccrc_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--_002_BC00F5384FCFC9499AF06F92E8B78A9E288CB0FF82shsmsx502ccrc_--


From xen-devel-bounces@lists.xensource.com Fri Dec 16 11:48:20 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 11:48:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbWGm-0003Nm-4W; Fri, 16 Dec 2011 11:48:08 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1RbWGl-0003NW-BP
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 11:48:07 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1324036080!5807874!1
X-Originating-IP: [143.182.124.37]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjEyNDkx\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26673 invoked from network); 16 Dec 2011 11:48:00 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37)
	by server-4.tower-174.messagelabs.com with SMTP;
	16 Dec 2011 11:48:00 -0000
Received: from azsmga002.ch.intel.com ([10.2.17.35])
	by azsmga102.ch.intel.com with ESMTP; 16 Dec 2011 03:47:59 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="47875143"
Received: from pgsmsx603.gar.corp.intel.com ([10.221.43.87])
	by AZSMGA002.ch.intel.com with ESMTP; 16 Dec 2011 03:47:58 -0800
Received: from shsmsx602.ccr.corp.intel.com (10.239.4.104) by
	pgsmsx603.gar.corp.intel.com (10.221.43.87) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Fri, 16 Dec 2011 19:47:57 +0800
Received: from shsmsx502.ccr.corp.intel.com ([10.239.4.96]) by
	SHSMSX602.ccr.corp.intel.com ([10.239.4.104]) with mapi;
	Fri, 16 Dec 2011 19:47:55 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Jan Beulich <JBeulich@suse.com>, "keir.xen@gmail.com"
	<keir.xen@gmail.com>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>
Date: Fri, 16 Dec 2011 19:47:54 +0800
Thread-Topic: X86-MCE: fix a bug of xen-mceinj tool
Thread-Index: Acy76IwZJ9WPzF5ZRRie/gDrkAgq7A==
Message-ID: <BC00F5384FCFC9499AF06F92E8B78A9E288CB0FF82@shsmsx502.ccr.corp.intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/mixed;
	boundary="_002_BC00F5384FCFC9499AF06F92E8B78A9E288CB0FF82shsmsx502ccrc_"
MIME-Version: 1.0
Subject: [Xen-devel] X86-MCE: fix a bug of xen-mceinj tool
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--_002_BC00F5384FCFC9499AF06F92E8B78A9E288CB0FF82shsmsx502ccrc_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

X86-MCE: fix a bug of xen-mceinj tool

Fix a bug of xen-mceinj tool which used to test mce by software way.

Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>

diff -r 86defe150053 tools/tests/mce-test/tools/xen-mceinj.c
--- a/tools/tests/mce-test/tools/xen-mceinj.c	Fri Dec 16 16:24:31 2011 +080=
0
+++ b/tools/tests/mce-test/tools/xen-mceinj.c	Fri Dec 16 17:28:38 2011 +080=
0
@@ -134,8 +134,12 @@ static int mca_cpuinfo(xc_interface *xc_
 {
     struct xen_mc mc;
=20
+    memset(&mc, 0, sizeof(struct xen_mc));
+
     mc.cmd =3D XEN_MC_physcpuinfo;
-    if (xc_mca_op(xc_handle, &mc))
+    mc.interface_version =3D XEN_MCA_INTERFACE_VERSION;
+
+    if (!xc_mca_op(xc_handle, &mc))
         return mc.u.mc_physcpuinfo.ncpus;
     else
         return 0;=

--_002_BC00F5384FCFC9499AF06F92E8B78A9E288CB0FF82shsmsx502ccrc_
Content-Type: application/octet-stream; name="mceinj-tools-fix.patch"
Content-Description: mceinj-tools-fix.patch
Content-Disposition: attachment; filename="mceinj-tools-fix.patch"; size=749;
	creation-date="Fri, 16 Dec 2011 19:45:08 GMT";
	modification-date="Fri, 16 Dec 2011 19:32:16 GMT"
Content-Transfer-Encoding: base64

WDg2LU1DRTogZml4IGEgYnVnIG9mIHhlbi1tY2VpbmogdG9vbAoKRml4IGEgYnVnIG9mIHhlbi1t
Y2VpbmogdG9vbCB3aGljaCB1c2VkIHRvIHRlc3QgbWNlIGJ5IHNvZnR3YXJlIHdheS4KClNpZ25l
ZC1vZmYtYnk6IExpdSwgSmluc29uZyA8amluc29uZy5saXVAaW50ZWwuY29tPgoKZGlmZiAtciA4
NmRlZmUxNTAwNTMgdG9vbHMvdGVzdHMvbWNlLXRlc3QvdG9vbHMveGVuLW1jZWluai5jCi0tLSBh
L3Rvb2xzL3Rlc3RzL21jZS10ZXN0L3Rvb2xzL3hlbi1tY2VpbmouYwlGcmkgRGVjIDE2IDE2OjI0
OjMxIDIwMTEgKzA4MDAKKysrIGIvdG9vbHMvdGVzdHMvbWNlLXRlc3QvdG9vbHMveGVuLW1jZWlu
ai5jCUZyaSBEZWMgMTYgMTc6Mjg6MzggMjAxMSArMDgwMApAQCAtMTM0LDggKzEzNCwxMiBAQCBz
dGF0aWMgaW50IG1jYV9jcHVpbmZvKHhjX2ludGVyZmFjZSAqeGNfCiB7CiAgICAgc3RydWN0IHhl
bl9tYyBtYzsKIAorICAgIG1lbXNldCgmbWMsIDAsIHNpemVvZihzdHJ1Y3QgeGVuX21jKSk7CisK
ICAgICBtYy5jbWQgPSBYRU5fTUNfcGh5c2NwdWluZm87Ci0gICAgaWYgKHhjX21jYV9vcCh4Y19o
YW5kbGUsICZtYykpCisgICAgbWMuaW50ZXJmYWNlX3ZlcnNpb24gPSBYRU5fTUNBX0lOVEVSRkFD
RV9WRVJTSU9OOworCisgICAgaWYgKCF4Y19tY2Ffb3AoeGNfaGFuZGxlLCAmbWMpKQogICAgICAg
ICByZXR1cm4gbWMudS5tY19waHlzY3B1aW5mby5uY3B1czsKICAgICBlbHNlCiAgICAgICAgIHJl
dHVybiAwOwo=

--_002_BC00F5384FCFC9499AF06F92E8B78A9E288CB0FF82shsmsx502ccrc_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--_002_BC00F5384FCFC9499AF06F92E8B78A9E288CB0FF82shsmsx502ccrc_--


From xen-devel-bounces@lists.xensource.com Fri Dec 16 11:50:33 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 11: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.xensource.com>)
	id 1RbWIt-0003VS-Mt; Fri, 16 Dec 2011 11:50:19 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RbWIs-0003V2-Mz
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 11:50:18 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1324036211!7734931!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjI0MzY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13333 invoked from network); 16 Dec 2011 11:50:12 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Dec 2011 11:50:12 -0000
X-IronPort-AV: E=Sophos;i="4.71,362,1320642000"; d="scan'208";a="174435052"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Dec 2011 06:50:10 -0500
Received: from cosworth.uk.xensource.com (10.80.16.52) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 16 Dec 2011 06:50:09 -0500
MIME-Version: 1.0
X-Mercurial-Node: d44e885e0389e1e2cad544d098f47c37f2d5a755
Message-ID: <d44e885e0389e1e2cad5.1324036048@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1324036046@cosworth.uk.xensource.com>
References: <patchbomb.1324036046@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 16 Dec 2011 11:47:28 +0000
From: Paul Durrant <paul.durrant@citrix.com>
To: xen-devel@lists.xensource.com
Cc: paul.durrant@citrix.com
Subject: [Xen-devel] [PATCH 2 of 3] Re-name xenstore key used to save VM
 generation ID buffer address
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Paul Durrant <paul.durrant@citrix.com>
# Date 1324035832 0
# Node ID d44e885e0389e1e2cad544d098f47c37f2d5a755
# Parent  24fc8670dfcaa9cbdfd89532823b68feb96ca2eb
Re-name xenstore key used to save VM generation ID buffer address.

Signed-off-by: Paul Durrant <paul.durrant@citrix.com>

diff -r 24fc8670dfca -r d44e885e0389 tools/firmware/hvmloader/acpi/build.c
--- a/tools/firmware/hvmloader/acpi/build.c	Fri Dec 16 11:43:52 2011 +0000
+++ b/tools/firmware/hvmloader/acpi/build.c	Fri Dec 16 11:43:52 2011 +0000
@@ -309,7 +309,7 @@ unsigned long new_vm_gid(void)
     if ( snprintf(addr, sizeof(addr), "0x%lx", virt_to_phys(buf))
          >= sizeof(addr) )
         return 0;
-    xenstore_write("data/generation-id", addr);
+    xenstore_write("hvmloader/generation-id-address", addr);
 
     gid = strtoll(xenstore_read("platform/generation-id", "0"), NULL, 0);
     *(uint64_t *)buf = gid;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 11:50:33 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 11: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.xensource.com>)
	id 1RbWIt-0003VS-Mt; Fri, 16 Dec 2011 11:50:19 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RbWIs-0003V2-Mz
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 11:50:18 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1324036211!7734931!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjI0MzY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13333 invoked from network); 16 Dec 2011 11:50:12 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Dec 2011 11:50:12 -0000
X-IronPort-AV: E=Sophos;i="4.71,362,1320642000"; d="scan'208";a="174435052"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Dec 2011 06:50:10 -0500
Received: from cosworth.uk.xensource.com (10.80.16.52) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 16 Dec 2011 06:50:09 -0500
MIME-Version: 1.0
X-Mercurial-Node: d44e885e0389e1e2cad544d098f47c37f2d5a755
Message-ID: <d44e885e0389e1e2cad5.1324036048@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1324036046@cosworth.uk.xensource.com>
References: <patchbomb.1324036046@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 16 Dec 2011 11:47:28 +0000
From: Paul Durrant <paul.durrant@citrix.com>
To: xen-devel@lists.xensource.com
Cc: paul.durrant@citrix.com
Subject: [Xen-devel] [PATCH 2 of 3] Re-name xenstore key used to save VM
 generation ID buffer address
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Paul Durrant <paul.durrant@citrix.com>
# Date 1324035832 0
# Node ID d44e885e0389e1e2cad544d098f47c37f2d5a755
# Parent  24fc8670dfcaa9cbdfd89532823b68feb96ca2eb
Re-name xenstore key used to save VM generation ID buffer address.

Signed-off-by: Paul Durrant <paul.durrant@citrix.com>

diff -r 24fc8670dfca -r d44e885e0389 tools/firmware/hvmloader/acpi/build.c
--- a/tools/firmware/hvmloader/acpi/build.c	Fri Dec 16 11:43:52 2011 +0000
+++ b/tools/firmware/hvmloader/acpi/build.c	Fri Dec 16 11:43:52 2011 +0000
@@ -309,7 +309,7 @@ unsigned long new_vm_gid(void)
     if ( snprintf(addr, sizeof(addr), "0x%lx", virt_to_phys(buf))
          >= sizeof(addr) )
         return 0;
-    xenstore_write("data/generation-id", addr);
+    xenstore_write("hvmloader/generation-id-address", addr);
 
     gid = strtoll(xenstore_read("platform/generation-id", "0"), NULL, 0);
     *(uint64_t *)buf = gid;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 11:50:33 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 11: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.xensource.com>)
	id 1RbWIv-0003Vr-H2; Fri, 16 Dec 2011 11:50:21 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RbWIt-0003V4-4J
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 11:50:19 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1324036211!7660834!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDc2NTY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27248 invoked from network); 16 Dec 2011 11:50:12 -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;
	16 Dec 2011 11:50:12 -0000
X-IronPort-AV: E=Sophos;i="4.71,362,1320642000"; d="scan'208";a="20034943"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Dec 2011 06:50:11 -0500
Received: from cosworth.uk.xensource.com (10.80.16.52) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 16 Dec 2011 06:50:10 -0500
MIME-Version: 1.0
X-Mercurial-Node: e745cfbe7e114cb8a8c331cb6b9c711462300c1f
Message-ID: <e745cfbe7e114cb8a8c3.1324036049@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1324036046@cosworth.uk.xensource.com>
References: <patchbomb.1324036046@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 16 Dec 2011 11:47:29 +0000
From: Paul Durrant <paul.durrant@citrix.com>
To: xen-devel@lists.xensource.com
Cc: paul.durrant@citrix.com
Subject: [Xen-devel] [PATCH 3 of 3] VM generation ID save/restore and migrate
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Paul Durrant <paul.durrant@citrix.com>
# Date 1324035833 0
# Node ID e745cfbe7e114cb8a8c331cb6b9c711462300c1f
# Parent  d44e885e0389e1e2cad544d098f47c37f2d5a755
VM generation ID save/restore and migrate.

Add code to track the address of the VM generation ID buffer across a
save/restore or migrate, and increment it as necessary.
The address of the buffer is written into xenstore by hvmloader at
boot time. It must be read from xenstore by the caller of
xc_domain_save() and then written back again by the caller of
xc_domain_restore().

Signed-off-by: Paul Durrant <paul.durrant@citrix.com>

diff -r d44e885e0389 -r e745cfbe7e11 tools/libxc/ia64/xc_ia64_linux_restore.c
--- a/tools/libxc/ia64/xc_ia64_linux_restore.c	Fri Dec 16 11:43:52 2011 +0000
+++ b/tools/libxc/ia64/xc_ia64_linux_restore.c	Fri Dec 16 11:43:53 2011 +0000
@@ -548,7 +548,9 @@ int
 xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
                   unsigned int store_evtchn, unsigned long *store_mfn,
                   unsigned int console_evtchn, unsigned long *console_mfn,
-                  unsigned int hvm, unsigned int pae, int superpages)
+                  unsigned int hvm, unsigned int pae, int superpages,
+                  int no_incr_generationid,
+                  unsigned long *vm_generationid_addr)
 {
     DECLARE_DOMCTL;
     int rc = 1;
diff -r d44e885e0389 -r e745cfbe7e11 tools/libxc/ia64/xc_ia64_linux_save.c
--- a/tools/libxc/ia64/xc_ia64_linux_save.c	Fri Dec 16 11:43:52 2011 +0000
+++ b/tools/libxc/ia64/xc_ia64_linux_save.c	Fri Dec 16 11:43:53 2011 +0000
@@ -382,7 +382,8 @@ out:
 int
 xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iters,
                uint32_t max_factor, uint32_t flags,
-               struct save_callbacks* callbacks, int hvm)
+               struct save_callbacks* callbacks, int hvm,
+               unsigned long vm_generationid_addr)
 {
     DECLARE_DOMCTL;
     xc_dominfo_t info;
diff -r d44e885e0389 -r e745cfbe7e11 tools/libxc/xc_domain_restore.c
--- a/tools/libxc/xc_domain_restore.c	Fri Dec 16 11:43:52 2011 +0000
+++ b/tools/libxc/xc_domain_restore.c	Fri Dec 16 11:43:53 2011 +0000
@@ -681,6 +681,7 @@ typedef struct {
     uint64_t console_pfn;
     uint64_t acpi_ioport_location;
     uint64_t viridian;
+    uint64_t vm_generationid_addr;
 } pagebuf_t;
 
 static int pagebuf_init(pagebuf_t* buf)
@@ -860,6 +861,17 @@ static int pagebuf_get_one(xc_interface 
         }
         return compbuf_size;
 
+    case XC_SAVE_ID_HVM_GENERATION_ID_ADDR:
+        /* Skip padding 4 bytes then read the generation id buffer location. */
+        if ( RDEXACT(fd, &buf->vm_generationid_addr, sizeof(uint32_t)) ||
+             RDEXACT(fd, &buf->vm_generationid_addr, sizeof(uint64_t)) )
+        {
+            PERROR("error read the generation id buffer location");
+            return -1;
+        }
+        DPRINTF("read generation id buffer address");
+        return pagebuf_get_one(xch, ctx, buf, fd, dom);
+
     default:
         if ( (count > MAX_BATCH_SIZE) || (count < 0) ) {
             ERROR("Max batch size exceeded (%d). Giving up.", count);
@@ -1248,7 +1260,9 @@ static int apply_batch(xc_interface *xch
 int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
                       unsigned int store_evtchn, unsigned long *store_mfn,
                       unsigned int console_evtchn, unsigned long *console_mfn,
-                      unsigned int hvm, unsigned int pae, int superpages)
+                      unsigned int hvm, unsigned int pae, int superpages,
+                      int no_incr_generationid,
+                      unsigned long *vm_generationid_addr)
 {
     DECLARE_DOMCTL;
     int rc = 1, frc, i, j, n, m, pae_extended_cr3 = 0, ext_vcpucontext = 0;
@@ -1449,6 +1463,39 @@ int xc_domain_restore(xc_interface *xch,
                 xc_set_hvm_param(xch, dom, HVM_PARAM_VM86_TSS, pagebuf.vm86_tss);
             if ( pagebuf.console_pfn )
                 console_pfn = pagebuf.console_pfn;
+            if ( pagebuf.vm_generationid_addr ) {
+                if ( !no_incr_generationid ) {
+                    unsigned int offset;
+                    unsigned char *buf;
+                    unsigned long long generationid;
+
+                    /*
+                     * Map the VM generation id buffer and inject the new value.
+                     */
+
+                    pfn = pagebuf.vm_generationid_addr >> PAGE_SHIFT;
+                    offset = pagebuf.vm_generationid_addr & (PAGE_SIZE - 1);
+                
+                    if ( (pfn >= dinfo->p2m_size) ||
+                         (pfn_type[pfn] != XEN_DOMCTL_PFINFO_NOTAB) )
+                    {
+                        ERROR("generation id buffer frame is bad");
+                        goto out;
+                    }
+
+                    mfn = ctx->p2m[pfn];
+                    buf = xc_map_foreign_range(xch, dom, PAGE_SIZE,
+                                               PROT_READ | PROT_WRITE, mfn);
+
+                    generationid = *(unsigned long long *)(buf + offset);
+                    *(unsigned long long *)(buf + offset) = generationid + 1;
+
+                    munmap(buf, PAGE_SIZE);
+                }
+
+                *vm_generationid_addr = pagebuf.vm_generationid_addr;
+            }
+
             break;  /* our work here is done */
         }
 
diff -r d44e885e0389 -r e745cfbe7e11 tools/libxc/xc_domain_save.c
--- a/tools/libxc/xc_domain_save.c	Fri Dec 16 11:43:52 2011 +0000
+++ b/tools/libxc/xc_domain_save.c	Fri Dec 16 11:43:53 2011 +0000
@@ -804,7 +804,8 @@ static int save_tsc_info(xc_interface *x
 
 int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iters,
                    uint32_t max_factor, uint32_t flags,
-                   struct save_callbacks* callbacks, int hvm)
+                   struct save_callbacks* callbacks, int hvm,
+                   unsigned long vm_generationid_addr)
 {
     xc_dominfo_t info;
     DECLARE_DOMCTL;
@@ -1616,6 +1617,16 @@ int xc_domain_save(xc_interface *xch, in
             uint64_t data;
         } chunk = { 0, };
 
+        chunk.id = XC_SAVE_ID_HVM_GENERATION_ID_ADDR;
+        chunk.data = vm_generationid_addr;
+
+        if ( (chunk.data != 0) &&
+             wrexact(io_fd, &chunk, sizeof(chunk)) )
+        {
+            PERROR("Error when writing the generation id buffer location for guest");
+            goto out;
+        }
+
         chunk.id = XC_SAVE_ID_HVM_IDENT_PT;
         chunk.data = 0;
         xc_get_hvm_param(xch, dom, HVM_PARAM_IDENT_PT,
diff -r d44e885e0389 -r e745cfbe7e11 tools/libxc/xenguest.h
--- a/tools/libxc/xenguest.h	Fri Dec 16 11:43:52 2011 +0000
+++ b/tools/libxc/xenguest.h	Fri Dec 16 11:43:53 2011 +0000
@@ -58,7 +58,8 @@ struct save_callbacks {
  */
 int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iters,
                    uint32_t max_factor, uint32_t flags /* XCFLAGS_xxx */,
-                   struct save_callbacks* callbacks, int hvm);
+                   struct save_callbacks* callbacks, int hvm,
+                   unsigned long vm_generationid_addr);
 
 
 /**
@@ -72,12 +73,16 @@ int xc_domain_save(xc_interface *xch, in
  * @parm hvm non-zero if this is a HVM restore
  * @parm pae non-zero if this HVM domain has PAE support enabled
  * @parm superpages non-zero to allocate guest memory with superpages
+ * @parm no_incr_generationid non-zero if generation id is NOT to be incremented
+ * @parm vm_generationid_addr returned with the address of the generation id buffer
  * @return 0 on success, -1 on failure
  */
 int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
                       unsigned int store_evtchn, unsigned long *store_mfn,
                       unsigned int console_evtchn, unsigned long *console_mfn,
-                      unsigned int hvm, unsigned int pae, int superpages);
+                      unsigned int hvm, unsigned int pae, int superpages,
+                      int no_incr_generationid,
+		      unsigned long *vm_generationid_addr);
 /**
  * xc_domain_restore writes a file to disk that contains the device
  * model saved state.
diff -r d44e885e0389 -r e745cfbe7e11 tools/libxc/xg_save_restore.h
--- a/tools/libxc/xg_save_restore.h	Fri Dec 16 11:43:52 2011 +0000
+++ b/tools/libxc/xg_save_restore.h	Fri Dec 16 11:43:53 2011 +0000
@@ -253,6 +253,7 @@
 #define XC_SAVE_ID_HVM_VIRIDIAN       -11
 #define XC_SAVE_ID_COMPRESSED_DATA    -12 /* Marker to indicate arrival of compressed data */
 #define XC_SAVE_ID_ENABLE_COMPRESSION -13 /* Marker to enable compression logic at receiver side */
+#define XC_SAVE_ID_HVM_GENERATION_ID_ADDR -14
 
 /*
 ** We process save/restore/migrate in batches of pages; the below
diff -r d44e885e0389 -r e745cfbe7e11 tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Fri Dec 16 11:43:52 2011 +0000
+++ b/tools/libxl/libxl_create.c	Fri Dec 16 11:43:53 2011 +0000
@@ -99,6 +99,7 @@ int libxl_init_build_info(libxl_ctx *ctx
         b_info->u.hvm.vpt_align = 1;
         b_info->u.hvm.timer_mode = 1;
         b_info->u.hvm.nested_hvm = 0;
+        b_info->u.hvm.no_incr_generationid = 0;
         break;
     case LIBXL_DOMAIN_TYPE_PV:
         b_info->u.pv.slack_memkb = 8 * 1024;
diff -r d44e885e0389 -r e745cfbe7e11 tools/libxl/libxl_dom.c
--- a/tools/libxl/libxl_dom.c	Fri Dec 16 11:43:52 2011 +0000
+++ b/tools/libxl/libxl_dom.c	Fri Dec 16 11:43:53 2011 +0000
@@ -106,6 +106,7 @@ int libxl__build_pre(libxl__gc *gc, uint
 
     state->store_port = xc_evtchn_alloc_unbound(ctx->xch, domid, 0);
     state->console_port = xc_evtchn_alloc_unbound(ctx->xch, domid, 0);
+    state->vm_generationid_addr = 0;
     return 0;
 }
 
@@ -117,7 +118,7 @@ int libxl__build_post(libxl__gc *gc, uin
     libxl_ctx *ctx = libxl__gc_owner(gc);
     char *dom_path, *vm_path;
     xs_transaction_t t;
-    char **ents;
+    char **ents, **hvm_ents;
     int i;
 
     libxl_cpuid_apply_policy(ctx, domid);
@@ -143,6 +144,13 @@ int libxl__build_post(libxl__gc *gc, uin
                             ? "offline" : "online";
     }
 
+    hvm_ents = NULL;
+    if (info->type == LIBXL_DOMAIN_TYPE_HVM) {
+        hvm_ents = libxl__calloc(gc, 3, sizeof(char *));
+        hvm_ents[0] = "hvmloader/generation-id-address";
+        hvm_ents[1] = libxl__sprintf(gc, "0x%lx", state->vm_generationid_addr);
+    }
+
     dom_path = libxl__xs_get_dompath(gc, domid);
     if (!dom_path) {
         return ERROR_FAIL;
@@ -153,6 +161,9 @@ retry_transaction:
     t = xs_transaction_start(ctx->xsh);
 
     libxl__xs_writev(gc, t, dom_path, ents);
+    if (info->type == LIBXL_DOMAIN_TYPE_HVM)
+        libxl__xs_writev(gc, t, dom_path, hvm_ents);
+
     libxl__xs_writev(gc, t, dom_path, local_ents);
     libxl__xs_writev(gc, t, vm_path, vms_ents);
 
@@ -356,16 +367,19 @@ int libxl__domain_restore_common(libxl__
     /* read signature */
     int rc;
     int hvm, pae, superpages;
+    int no_incr_generationid;
     switch (info->type) {
     case LIBXL_DOMAIN_TYPE_HVM:
         hvm = 1;
         superpages = 1;
         pae = info->u.hvm.pae;
+        no_incr_generationid = info->u.hvm.no_incr_generationid;
         break;
     case LIBXL_DOMAIN_TYPE_PV:
         hvm = 0;
         superpages = 0;
         pae = 1;
+        no_incr_generationid = 0;
         break;
     default:
         return ERROR_INVAL;
@@ -373,7 +387,8 @@ int libxl__domain_restore_common(libxl__
     rc = xc_domain_restore(ctx->xch, fd, domid,
                            state->store_port, &state->store_mfn,
                            state->console_port, &state->console_mfn,
-                           hvm, pae, superpages);
+                           hvm, pae, superpages, no_incr_generationid,
+                           &state->vm_generationid_addr);
     if ( rc ) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "restoring domain");
         return ERROR_FAIL;
@@ -539,12 +554,23 @@ int libxl__domain_suspend_common(libxl__
     struct save_callbacks callbacks;
     struct suspendinfo si;
     int hvm, rc = ERROR_FAIL;
+    unsigned long vm_generationid_addr;
 
     switch (type) {
-    case LIBXL_DOMAIN_TYPE_HVM:
+    case LIBXL_DOMAIN_TYPE_HVM: {
+        char *path;
+        char *addr;
+
+        path = libxl__sprintf(gc, "%s/hvmloader/generation-id-address",
+                              libxl__xs_get_dompath(gc, domid));
+        addr = libxl__xs_read(gc, XBT_NULL, path);
+
+        vm_generationid_addr = (addr) ? strtoul(addr, NULL, 0) : 0;
         hvm = 1;
         break;
+    }
     case LIBXL_DOMAIN_TYPE_PV:
+        vm_generationid_addr = 0;
         hvm = 0;
         break;
     default:
@@ -582,7 +608,8 @@ int libxl__domain_suspend_common(libxl__
     callbacks.switch_qemu_logdirty = libxl__domain_suspend_common_switch_qemu_logdirty;
     callbacks.data = &si;
 
-    rc = xc_domain_save(ctx->xch, fd, domid, 0, 0, flags, &callbacks, hvm);
+    rc = xc_domain_save(ctx->xch, fd, domid, 0, 0, flags, &callbacks,
+                        hvm, vm_generationid_addr);
     if ( rc ) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "saving domain: %s",
                          si.guest_responded ?
diff -r d44e885e0389 -r e745cfbe7e11 tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Fri Dec 16 11:43:52 2011 +0000
+++ b/tools/libxl/libxl_internal.h	Fri Dec 16 11:43:53 2011 +0000
@@ -218,6 +218,7 @@ typedef struct {
 
     uint32_t console_port;
     unsigned long console_mfn;
+    unsigned long vm_generationid_addr;
 } libxl__domain_build_state;
 
 _hidden int libxl__build_pre(libxl__gc *gc, uint32_t domid,
diff -r d44e885e0389 -r e745cfbe7e11 tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Fri Dec 16 11:43:52 2011 +0000
+++ b/tools/libxl/libxl_types.idl	Fri Dec 16 11:43:53 2011 +0000
@@ -184,6 +184,7 @@ libxl_domain_build_info = Struct("domain
                                        ("vpt_align", bool),
                                        ("timer_mode", integer),
                                        ("nested_hvm", bool),
+                                       ("no_incr_generationid", bool),
                                        ])),
                  ("pv", Struct(None, [("kernel", libxl_file_reference),
                                       ("slack_memkb", uint32),
diff -r d44e885e0389 -r e745cfbe7e11 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Fri Dec 16 11:43:52 2011 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Fri Dec 16 11:43:53 2011 +0000
@@ -360,6 +360,8 @@ static void printf_info(int domid,
         printf("\t\t\t(vpt_align %d)\n", b_info->u.hvm.vpt_align);
         printf("\t\t\t(timer_mode %d)\n", b_info->u.hvm.timer_mode);
         printf("\t\t\t(nestedhvm %d)\n", b_info->u.hvm.nested_hvm);
+        printf("\t\t\t(no_incr_generationid %d)\n",
+                    b_info->u.hvm.no_incr_generationid);
 
         printf("\t\t\t(device_model %s)\n", dm_info->device_model ? : "default");
         printf("\t\t\t(videoram %d)\n", dm_info->videoram);
@@ -1362,6 +1364,7 @@ struct domain_create {
     const char *restore_file;
     int migrate_fd; /* -1 means none */
     char **migration_domname_r; /* from malloc */
+    int no_incr_generationid;
 };
 
 static int freemem(libxl_domain_build_info *b_info, libxl_device_model_info *dm_info)
@@ -1575,6 +1578,8 @@ static int create_domain(struct domain_c
         }
     }
 
+    d_config.b_info.u.hvm.no_incr_generationid = dom_info->no_incr_generationid;
+
     if (debug || dom_info->dryrun)
         printf_info(-1, &d_config, &d_config.dm_info);
 
@@ -2800,6 +2805,7 @@ static void migrate_receive(int debug, i
     dom_info.restore_file = "incoming migration stream";
     dom_info.migrate_fd = 0; /* stdin */
     dom_info.migration_domname_r = &migration_domname;
+    dom_info.no_incr_generationid = 1;
 
     rc = create_domain(&dom_info);
     if (rc < 0) {
diff -r d44e885e0389 -r e745cfbe7e11 tools/python/xen/lowlevel/checkpoint/libcheckpoint.c
--- a/tools/python/xen/lowlevel/checkpoint/libcheckpoint.c	Fri Dec 16 11:43:52 2011 +0000
+++ b/tools/python/xen/lowlevel/checkpoint/libcheckpoint.c	Fri Dec 16 11:43:53 2011 +0000
@@ -175,6 +175,7 @@ int checkpoint_start(checkpoint_state* s
 {
     int hvm, rc;
     int flags = XCFLAGS_LIVE;
+    unsigned long vm_generationid_addr;
 
     if (!s->domid) {
        s->errstr = "checkpoint state not opened";
@@ -185,16 +186,28 @@ int checkpoint_start(checkpoint_state* s
 
     hvm = s->domtype > dt_pv;
     if (hvm) {
+       char path[128];
+       char *addr;
+
+       sprintf(path, "/local/domain/%u/hvmloader/generation-id-address", s->domid);
+       addr = xs_read(s->xsh, XBT_NULL, path, NULL);
+
+       vm_generationid_addr = (addr) ? strtoul(addr, NULL, 0) : 0;
+       free(addr);
+
        flags |= XCFLAGS_HVM;
        if (switch_qemu_logdirty(s, 1))
            return -1;
+    } else {
+       vm_generationid_addr = 0;
     }
     if (remus_flags & CHECKPOINT_FLAGS_COMPRESSION)
       flags |= XCFLAGS_CHECKPOINT_COMPRESS;
 
     callbacks->switch_qemu_logdirty = noop_switch_logdirty;
 
-    rc = xc_domain_save(s->xch, fd, s->domid, 0, 0, flags, callbacks, hvm);
+    rc = xc_domain_save(s->xch, fd, s->domid, 0, 0, flags, callbacks, hvm,
+                        vm_generationid_addr);
 
     if (hvm)
        switch_qemu_logdirty(s, 0);
diff -r d44e885e0389 -r e745cfbe7e11 tools/xcutils/xc_restore.c
--- a/tools/xcutils/xc_restore.c	Fri Dec 16 11:43:52 2011 +0000
+++ b/tools/xcutils/xc_restore.c	Fri Dec 16 11:43:53 2011 +0000
@@ -23,11 +23,13 @@ main(int argc, char **argv)
     xc_interface *xch;
     int io_fd, ret;
     int superpages;
-    unsigned long store_mfn, console_mfn;
+    unsigned long store_mfn, console_mfn, vm_generationid_addr;
+    int no_incr_generationid;
 
-    if ( (argc != 8) && (argc != 9) )
+    if ( (argc < 8) || (argc > 10) )
         errx(1, "usage: %s iofd domid store_evtchn "
-             "console_evtchn hvm pae apic [superpages]", argv[0]);
+             "console_evtchn hvm pae apic "
+             "[superpages [no_incr_generationid]]", argv[0]);
 
     xch = xc_interface_open(0,0,0);
     if ( !xch )
@@ -40,19 +42,25 @@ main(int argc, char **argv)
     hvm  = atoi(argv[5]);
     pae  = atoi(argv[6]);
     apic = atoi(argv[7]);
-    if ( argc == 9 )
+    if ( argc >= 9 )
 	    superpages = atoi(argv[8]);
     else
 	    superpages = !!hvm;
+    if ( argc == 10 )
+	    no_incr_generationid = !atoi(argv[9]);
+    else
+	    no_incr_generationid = 0;
 
     ret = xc_domain_restore(xch, io_fd, domid, store_evtchn, &store_mfn,
-                            console_evtchn, &console_mfn, hvm, pae, superpages);
+                            console_evtchn, &console_mfn, hvm, pae, superpages,
+                            no_incr_generationid, &vm_generationid_addr);
 
     if ( ret == 0 )
     {
 	printf("store-mfn %li\n", store_mfn);
         if ( !hvm )
             printf("console-mfn %li\n", console_mfn);
+	printf("generation-id-address %lx\n", vm_generationid_addr);
 	fflush(stdout);
     }
 
diff -r d44e885e0389 -r e745cfbe7e11 tools/xcutils/xc_save.c
--- a/tools/xcutils/xc_save.c	Fri Dec 16 11:43:52 2011 +0000
+++ b/tools/xcutils/xc_save.c	Fri Dec 16 11:43:53 2011 +0000
@@ -169,6 +169,10 @@ main(int argc, char **argv)
     unsigned int maxit, max_f;
     int io_fd, ret, port;
     struct save_callbacks callbacks;
+    char path[128];
+    struct xs_handle *xs;
+    char *addr;
+    unsigned long vm_generationid_addr;
 
     if (argc != 6)
         errx(1, "usage: %s iofd domid maxit maxf flags", argv[0]);
@@ -207,8 +211,22 @@ main(int argc, char **argv)
     memset(&callbacks, 0, sizeof(callbacks));
     callbacks.suspend = suspend;
     callbacks.switch_qemu_logdirty = switch_qemu_logdirty;
+
+    sprintf(path, "/local/domain/%d/hvmloader/generation-id-address", si.domid);
+
+    if ((xs = xs_daemon_open()) == NULL)
+        errx(1, "Couldn't contact xenstore");
+
+    addr = xs_read(xs, XBT_NULL, path, NULL);
+
+    xs_daemon_close(xs);
+
+    vm_generationid_addr = (addr) ? strtoul(addr, NULL, 0) : 0;
+    free(addr);
+
     ret = xc_domain_save(si.xch, io_fd, si.domid, maxit, max_f, si.flags, 
-                         &callbacks, !!(si.flags & XCFLAGS_HVM));
+                         &callbacks, !!(si.flags & XCFLAGS_HVM),
+                         vm_generationid_addr);
 
     if (si.suspend_evtchn > 0)
 	 xc_suspend_evtchn_release(si.xch, si.xce, si.domid, si.suspend_evtchn);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 11:50:33 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 11: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.xensource.com>)
	id 1RbWIv-0003Vr-H2; Fri, 16 Dec 2011 11:50:21 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RbWIt-0003V4-4J
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 11:50:19 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1324036211!7660834!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDc2NTY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27248 invoked from network); 16 Dec 2011 11:50:12 -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;
	16 Dec 2011 11:50:12 -0000
X-IronPort-AV: E=Sophos;i="4.71,362,1320642000"; d="scan'208";a="20034943"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Dec 2011 06:50:11 -0500
Received: from cosworth.uk.xensource.com (10.80.16.52) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 16 Dec 2011 06:50:10 -0500
MIME-Version: 1.0
X-Mercurial-Node: e745cfbe7e114cb8a8c331cb6b9c711462300c1f
Message-ID: <e745cfbe7e114cb8a8c3.1324036049@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1324036046@cosworth.uk.xensource.com>
References: <patchbomb.1324036046@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 16 Dec 2011 11:47:29 +0000
From: Paul Durrant <paul.durrant@citrix.com>
To: xen-devel@lists.xensource.com
Cc: paul.durrant@citrix.com
Subject: [Xen-devel] [PATCH 3 of 3] VM generation ID save/restore and migrate
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Paul Durrant <paul.durrant@citrix.com>
# Date 1324035833 0
# Node ID e745cfbe7e114cb8a8c331cb6b9c711462300c1f
# Parent  d44e885e0389e1e2cad544d098f47c37f2d5a755
VM generation ID save/restore and migrate.

Add code to track the address of the VM generation ID buffer across a
save/restore or migrate, and increment it as necessary.
The address of the buffer is written into xenstore by hvmloader at
boot time. It must be read from xenstore by the caller of
xc_domain_save() and then written back again by the caller of
xc_domain_restore().

Signed-off-by: Paul Durrant <paul.durrant@citrix.com>

diff -r d44e885e0389 -r e745cfbe7e11 tools/libxc/ia64/xc_ia64_linux_restore.c
--- a/tools/libxc/ia64/xc_ia64_linux_restore.c	Fri Dec 16 11:43:52 2011 +0000
+++ b/tools/libxc/ia64/xc_ia64_linux_restore.c	Fri Dec 16 11:43:53 2011 +0000
@@ -548,7 +548,9 @@ int
 xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
                   unsigned int store_evtchn, unsigned long *store_mfn,
                   unsigned int console_evtchn, unsigned long *console_mfn,
-                  unsigned int hvm, unsigned int pae, int superpages)
+                  unsigned int hvm, unsigned int pae, int superpages,
+                  int no_incr_generationid,
+                  unsigned long *vm_generationid_addr)
 {
     DECLARE_DOMCTL;
     int rc = 1;
diff -r d44e885e0389 -r e745cfbe7e11 tools/libxc/ia64/xc_ia64_linux_save.c
--- a/tools/libxc/ia64/xc_ia64_linux_save.c	Fri Dec 16 11:43:52 2011 +0000
+++ b/tools/libxc/ia64/xc_ia64_linux_save.c	Fri Dec 16 11:43:53 2011 +0000
@@ -382,7 +382,8 @@ out:
 int
 xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iters,
                uint32_t max_factor, uint32_t flags,
-               struct save_callbacks* callbacks, int hvm)
+               struct save_callbacks* callbacks, int hvm,
+               unsigned long vm_generationid_addr)
 {
     DECLARE_DOMCTL;
     xc_dominfo_t info;
diff -r d44e885e0389 -r e745cfbe7e11 tools/libxc/xc_domain_restore.c
--- a/tools/libxc/xc_domain_restore.c	Fri Dec 16 11:43:52 2011 +0000
+++ b/tools/libxc/xc_domain_restore.c	Fri Dec 16 11:43:53 2011 +0000
@@ -681,6 +681,7 @@ typedef struct {
     uint64_t console_pfn;
     uint64_t acpi_ioport_location;
     uint64_t viridian;
+    uint64_t vm_generationid_addr;
 } pagebuf_t;
 
 static int pagebuf_init(pagebuf_t* buf)
@@ -860,6 +861,17 @@ static int pagebuf_get_one(xc_interface 
         }
         return compbuf_size;
 
+    case XC_SAVE_ID_HVM_GENERATION_ID_ADDR:
+        /* Skip padding 4 bytes then read the generation id buffer location. */
+        if ( RDEXACT(fd, &buf->vm_generationid_addr, sizeof(uint32_t)) ||
+             RDEXACT(fd, &buf->vm_generationid_addr, sizeof(uint64_t)) )
+        {
+            PERROR("error read the generation id buffer location");
+            return -1;
+        }
+        DPRINTF("read generation id buffer address");
+        return pagebuf_get_one(xch, ctx, buf, fd, dom);
+
     default:
         if ( (count > MAX_BATCH_SIZE) || (count < 0) ) {
             ERROR("Max batch size exceeded (%d). Giving up.", count);
@@ -1248,7 +1260,9 @@ static int apply_batch(xc_interface *xch
 int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
                       unsigned int store_evtchn, unsigned long *store_mfn,
                       unsigned int console_evtchn, unsigned long *console_mfn,
-                      unsigned int hvm, unsigned int pae, int superpages)
+                      unsigned int hvm, unsigned int pae, int superpages,
+                      int no_incr_generationid,
+                      unsigned long *vm_generationid_addr)
 {
     DECLARE_DOMCTL;
     int rc = 1, frc, i, j, n, m, pae_extended_cr3 = 0, ext_vcpucontext = 0;
@@ -1449,6 +1463,39 @@ int xc_domain_restore(xc_interface *xch,
                 xc_set_hvm_param(xch, dom, HVM_PARAM_VM86_TSS, pagebuf.vm86_tss);
             if ( pagebuf.console_pfn )
                 console_pfn = pagebuf.console_pfn;
+            if ( pagebuf.vm_generationid_addr ) {
+                if ( !no_incr_generationid ) {
+                    unsigned int offset;
+                    unsigned char *buf;
+                    unsigned long long generationid;
+
+                    /*
+                     * Map the VM generation id buffer and inject the new value.
+                     */
+
+                    pfn = pagebuf.vm_generationid_addr >> PAGE_SHIFT;
+                    offset = pagebuf.vm_generationid_addr & (PAGE_SIZE - 1);
+                
+                    if ( (pfn >= dinfo->p2m_size) ||
+                         (pfn_type[pfn] != XEN_DOMCTL_PFINFO_NOTAB) )
+                    {
+                        ERROR("generation id buffer frame is bad");
+                        goto out;
+                    }
+
+                    mfn = ctx->p2m[pfn];
+                    buf = xc_map_foreign_range(xch, dom, PAGE_SIZE,
+                                               PROT_READ | PROT_WRITE, mfn);
+
+                    generationid = *(unsigned long long *)(buf + offset);
+                    *(unsigned long long *)(buf + offset) = generationid + 1;
+
+                    munmap(buf, PAGE_SIZE);
+                }
+
+                *vm_generationid_addr = pagebuf.vm_generationid_addr;
+            }
+
             break;  /* our work here is done */
         }
 
diff -r d44e885e0389 -r e745cfbe7e11 tools/libxc/xc_domain_save.c
--- a/tools/libxc/xc_domain_save.c	Fri Dec 16 11:43:52 2011 +0000
+++ b/tools/libxc/xc_domain_save.c	Fri Dec 16 11:43:53 2011 +0000
@@ -804,7 +804,8 @@ static int save_tsc_info(xc_interface *x
 
 int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iters,
                    uint32_t max_factor, uint32_t flags,
-                   struct save_callbacks* callbacks, int hvm)
+                   struct save_callbacks* callbacks, int hvm,
+                   unsigned long vm_generationid_addr)
 {
     xc_dominfo_t info;
     DECLARE_DOMCTL;
@@ -1616,6 +1617,16 @@ int xc_domain_save(xc_interface *xch, in
             uint64_t data;
         } chunk = { 0, };
 
+        chunk.id = XC_SAVE_ID_HVM_GENERATION_ID_ADDR;
+        chunk.data = vm_generationid_addr;
+
+        if ( (chunk.data != 0) &&
+             wrexact(io_fd, &chunk, sizeof(chunk)) )
+        {
+            PERROR("Error when writing the generation id buffer location for guest");
+            goto out;
+        }
+
         chunk.id = XC_SAVE_ID_HVM_IDENT_PT;
         chunk.data = 0;
         xc_get_hvm_param(xch, dom, HVM_PARAM_IDENT_PT,
diff -r d44e885e0389 -r e745cfbe7e11 tools/libxc/xenguest.h
--- a/tools/libxc/xenguest.h	Fri Dec 16 11:43:52 2011 +0000
+++ b/tools/libxc/xenguest.h	Fri Dec 16 11:43:53 2011 +0000
@@ -58,7 +58,8 @@ struct save_callbacks {
  */
 int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iters,
                    uint32_t max_factor, uint32_t flags /* XCFLAGS_xxx */,
-                   struct save_callbacks* callbacks, int hvm);
+                   struct save_callbacks* callbacks, int hvm,
+                   unsigned long vm_generationid_addr);
 
 
 /**
@@ -72,12 +73,16 @@ int xc_domain_save(xc_interface *xch, in
  * @parm hvm non-zero if this is a HVM restore
  * @parm pae non-zero if this HVM domain has PAE support enabled
  * @parm superpages non-zero to allocate guest memory with superpages
+ * @parm no_incr_generationid non-zero if generation id is NOT to be incremented
+ * @parm vm_generationid_addr returned with the address of the generation id buffer
  * @return 0 on success, -1 on failure
  */
 int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
                       unsigned int store_evtchn, unsigned long *store_mfn,
                       unsigned int console_evtchn, unsigned long *console_mfn,
-                      unsigned int hvm, unsigned int pae, int superpages);
+                      unsigned int hvm, unsigned int pae, int superpages,
+                      int no_incr_generationid,
+		      unsigned long *vm_generationid_addr);
 /**
  * xc_domain_restore writes a file to disk that contains the device
  * model saved state.
diff -r d44e885e0389 -r e745cfbe7e11 tools/libxc/xg_save_restore.h
--- a/tools/libxc/xg_save_restore.h	Fri Dec 16 11:43:52 2011 +0000
+++ b/tools/libxc/xg_save_restore.h	Fri Dec 16 11:43:53 2011 +0000
@@ -253,6 +253,7 @@
 #define XC_SAVE_ID_HVM_VIRIDIAN       -11
 #define XC_SAVE_ID_COMPRESSED_DATA    -12 /* Marker to indicate arrival of compressed data */
 #define XC_SAVE_ID_ENABLE_COMPRESSION -13 /* Marker to enable compression logic at receiver side */
+#define XC_SAVE_ID_HVM_GENERATION_ID_ADDR -14
 
 /*
 ** We process save/restore/migrate in batches of pages; the below
diff -r d44e885e0389 -r e745cfbe7e11 tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Fri Dec 16 11:43:52 2011 +0000
+++ b/tools/libxl/libxl_create.c	Fri Dec 16 11:43:53 2011 +0000
@@ -99,6 +99,7 @@ int libxl_init_build_info(libxl_ctx *ctx
         b_info->u.hvm.vpt_align = 1;
         b_info->u.hvm.timer_mode = 1;
         b_info->u.hvm.nested_hvm = 0;
+        b_info->u.hvm.no_incr_generationid = 0;
         break;
     case LIBXL_DOMAIN_TYPE_PV:
         b_info->u.pv.slack_memkb = 8 * 1024;
diff -r d44e885e0389 -r e745cfbe7e11 tools/libxl/libxl_dom.c
--- a/tools/libxl/libxl_dom.c	Fri Dec 16 11:43:52 2011 +0000
+++ b/tools/libxl/libxl_dom.c	Fri Dec 16 11:43:53 2011 +0000
@@ -106,6 +106,7 @@ int libxl__build_pre(libxl__gc *gc, uint
 
     state->store_port = xc_evtchn_alloc_unbound(ctx->xch, domid, 0);
     state->console_port = xc_evtchn_alloc_unbound(ctx->xch, domid, 0);
+    state->vm_generationid_addr = 0;
     return 0;
 }
 
@@ -117,7 +118,7 @@ int libxl__build_post(libxl__gc *gc, uin
     libxl_ctx *ctx = libxl__gc_owner(gc);
     char *dom_path, *vm_path;
     xs_transaction_t t;
-    char **ents;
+    char **ents, **hvm_ents;
     int i;
 
     libxl_cpuid_apply_policy(ctx, domid);
@@ -143,6 +144,13 @@ int libxl__build_post(libxl__gc *gc, uin
                             ? "offline" : "online";
     }
 
+    hvm_ents = NULL;
+    if (info->type == LIBXL_DOMAIN_TYPE_HVM) {
+        hvm_ents = libxl__calloc(gc, 3, sizeof(char *));
+        hvm_ents[0] = "hvmloader/generation-id-address";
+        hvm_ents[1] = libxl__sprintf(gc, "0x%lx", state->vm_generationid_addr);
+    }
+
     dom_path = libxl__xs_get_dompath(gc, domid);
     if (!dom_path) {
         return ERROR_FAIL;
@@ -153,6 +161,9 @@ retry_transaction:
     t = xs_transaction_start(ctx->xsh);
 
     libxl__xs_writev(gc, t, dom_path, ents);
+    if (info->type == LIBXL_DOMAIN_TYPE_HVM)
+        libxl__xs_writev(gc, t, dom_path, hvm_ents);
+
     libxl__xs_writev(gc, t, dom_path, local_ents);
     libxl__xs_writev(gc, t, vm_path, vms_ents);
 
@@ -356,16 +367,19 @@ int libxl__domain_restore_common(libxl__
     /* read signature */
     int rc;
     int hvm, pae, superpages;
+    int no_incr_generationid;
     switch (info->type) {
     case LIBXL_DOMAIN_TYPE_HVM:
         hvm = 1;
         superpages = 1;
         pae = info->u.hvm.pae;
+        no_incr_generationid = info->u.hvm.no_incr_generationid;
         break;
     case LIBXL_DOMAIN_TYPE_PV:
         hvm = 0;
         superpages = 0;
         pae = 1;
+        no_incr_generationid = 0;
         break;
     default:
         return ERROR_INVAL;
@@ -373,7 +387,8 @@ int libxl__domain_restore_common(libxl__
     rc = xc_domain_restore(ctx->xch, fd, domid,
                            state->store_port, &state->store_mfn,
                            state->console_port, &state->console_mfn,
-                           hvm, pae, superpages);
+                           hvm, pae, superpages, no_incr_generationid,
+                           &state->vm_generationid_addr);
     if ( rc ) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "restoring domain");
         return ERROR_FAIL;
@@ -539,12 +554,23 @@ int libxl__domain_suspend_common(libxl__
     struct save_callbacks callbacks;
     struct suspendinfo si;
     int hvm, rc = ERROR_FAIL;
+    unsigned long vm_generationid_addr;
 
     switch (type) {
-    case LIBXL_DOMAIN_TYPE_HVM:
+    case LIBXL_DOMAIN_TYPE_HVM: {
+        char *path;
+        char *addr;
+
+        path = libxl__sprintf(gc, "%s/hvmloader/generation-id-address",
+                              libxl__xs_get_dompath(gc, domid));
+        addr = libxl__xs_read(gc, XBT_NULL, path);
+
+        vm_generationid_addr = (addr) ? strtoul(addr, NULL, 0) : 0;
         hvm = 1;
         break;
+    }
     case LIBXL_DOMAIN_TYPE_PV:
+        vm_generationid_addr = 0;
         hvm = 0;
         break;
     default:
@@ -582,7 +608,8 @@ int libxl__domain_suspend_common(libxl__
     callbacks.switch_qemu_logdirty = libxl__domain_suspend_common_switch_qemu_logdirty;
     callbacks.data = &si;
 
-    rc = xc_domain_save(ctx->xch, fd, domid, 0, 0, flags, &callbacks, hvm);
+    rc = xc_domain_save(ctx->xch, fd, domid, 0, 0, flags, &callbacks,
+                        hvm, vm_generationid_addr);
     if ( rc ) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "saving domain: %s",
                          si.guest_responded ?
diff -r d44e885e0389 -r e745cfbe7e11 tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Fri Dec 16 11:43:52 2011 +0000
+++ b/tools/libxl/libxl_internal.h	Fri Dec 16 11:43:53 2011 +0000
@@ -218,6 +218,7 @@ typedef struct {
 
     uint32_t console_port;
     unsigned long console_mfn;
+    unsigned long vm_generationid_addr;
 } libxl__domain_build_state;
 
 _hidden int libxl__build_pre(libxl__gc *gc, uint32_t domid,
diff -r d44e885e0389 -r e745cfbe7e11 tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Fri Dec 16 11:43:52 2011 +0000
+++ b/tools/libxl/libxl_types.idl	Fri Dec 16 11:43:53 2011 +0000
@@ -184,6 +184,7 @@ libxl_domain_build_info = Struct("domain
                                        ("vpt_align", bool),
                                        ("timer_mode", integer),
                                        ("nested_hvm", bool),
+                                       ("no_incr_generationid", bool),
                                        ])),
                  ("pv", Struct(None, [("kernel", libxl_file_reference),
                                       ("slack_memkb", uint32),
diff -r d44e885e0389 -r e745cfbe7e11 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Fri Dec 16 11:43:52 2011 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Fri Dec 16 11:43:53 2011 +0000
@@ -360,6 +360,8 @@ static void printf_info(int domid,
         printf("\t\t\t(vpt_align %d)\n", b_info->u.hvm.vpt_align);
         printf("\t\t\t(timer_mode %d)\n", b_info->u.hvm.timer_mode);
         printf("\t\t\t(nestedhvm %d)\n", b_info->u.hvm.nested_hvm);
+        printf("\t\t\t(no_incr_generationid %d)\n",
+                    b_info->u.hvm.no_incr_generationid);
 
         printf("\t\t\t(device_model %s)\n", dm_info->device_model ? : "default");
         printf("\t\t\t(videoram %d)\n", dm_info->videoram);
@@ -1362,6 +1364,7 @@ struct domain_create {
     const char *restore_file;
     int migrate_fd; /* -1 means none */
     char **migration_domname_r; /* from malloc */
+    int no_incr_generationid;
 };
 
 static int freemem(libxl_domain_build_info *b_info, libxl_device_model_info *dm_info)
@@ -1575,6 +1578,8 @@ static int create_domain(struct domain_c
         }
     }
 
+    d_config.b_info.u.hvm.no_incr_generationid = dom_info->no_incr_generationid;
+
     if (debug || dom_info->dryrun)
         printf_info(-1, &d_config, &d_config.dm_info);
 
@@ -2800,6 +2805,7 @@ static void migrate_receive(int debug, i
     dom_info.restore_file = "incoming migration stream";
     dom_info.migrate_fd = 0; /* stdin */
     dom_info.migration_domname_r = &migration_domname;
+    dom_info.no_incr_generationid = 1;
 
     rc = create_domain(&dom_info);
     if (rc < 0) {
diff -r d44e885e0389 -r e745cfbe7e11 tools/python/xen/lowlevel/checkpoint/libcheckpoint.c
--- a/tools/python/xen/lowlevel/checkpoint/libcheckpoint.c	Fri Dec 16 11:43:52 2011 +0000
+++ b/tools/python/xen/lowlevel/checkpoint/libcheckpoint.c	Fri Dec 16 11:43:53 2011 +0000
@@ -175,6 +175,7 @@ int checkpoint_start(checkpoint_state* s
 {
     int hvm, rc;
     int flags = XCFLAGS_LIVE;
+    unsigned long vm_generationid_addr;
 
     if (!s->domid) {
        s->errstr = "checkpoint state not opened";
@@ -185,16 +186,28 @@ int checkpoint_start(checkpoint_state* s
 
     hvm = s->domtype > dt_pv;
     if (hvm) {
+       char path[128];
+       char *addr;
+
+       sprintf(path, "/local/domain/%u/hvmloader/generation-id-address", s->domid);
+       addr = xs_read(s->xsh, XBT_NULL, path, NULL);
+
+       vm_generationid_addr = (addr) ? strtoul(addr, NULL, 0) : 0;
+       free(addr);
+
        flags |= XCFLAGS_HVM;
        if (switch_qemu_logdirty(s, 1))
            return -1;
+    } else {
+       vm_generationid_addr = 0;
     }
     if (remus_flags & CHECKPOINT_FLAGS_COMPRESSION)
       flags |= XCFLAGS_CHECKPOINT_COMPRESS;
 
     callbacks->switch_qemu_logdirty = noop_switch_logdirty;
 
-    rc = xc_domain_save(s->xch, fd, s->domid, 0, 0, flags, callbacks, hvm);
+    rc = xc_domain_save(s->xch, fd, s->domid, 0, 0, flags, callbacks, hvm,
+                        vm_generationid_addr);
 
     if (hvm)
        switch_qemu_logdirty(s, 0);
diff -r d44e885e0389 -r e745cfbe7e11 tools/xcutils/xc_restore.c
--- a/tools/xcutils/xc_restore.c	Fri Dec 16 11:43:52 2011 +0000
+++ b/tools/xcutils/xc_restore.c	Fri Dec 16 11:43:53 2011 +0000
@@ -23,11 +23,13 @@ main(int argc, char **argv)
     xc_interface *xch;
     int io_fd, ret;
     int superpages;
-    unsigned long store_mfn, console_mfn;
+    unsigned long store_mfn, console_mfn, vm_generationid_addr;
+    int no_incr_generationid;
 
-    if ( (argc != 8) && (argc != 9) )
+    if ( (argc < 8) || (argc > 10) )
         errx(1, "usage: %s iofd domid store_evtchn "
-             "console_evtchn hvm pae apic [superpages]", argv[0]);
+             "console_evtchn hvm pae apic "
+             "[superpages [no_incr_generationid]]", argv[0]);
 
     xch = xc_interface_open(0,0,0);
     if ( !xch )
@@ -40,19 +42,25 @@ main(int argc, char **argv)
     hvm  = atoi(argv[5]);
     pae  = atoi(argv[6]);
     apic = atoi(argv[7]);
-    if ( argc == 9 )
+    if ( argc >= 9 )
 	    superpages = atoi(argv[8]);
     else
 	    superpages = !!hvm;
+    if ( argc == 10 )
+	    no_incr_generationid = !atoi(argv[9]);
+    else
+	    no_incr_generationid = 0;
 
     ret = xc_domain_restore(xch, io_fd, domid, store_evtchn, &store_mfn,
-                            console_evtchn, &console_mfn, hvm, pae, superpages);
+                            console_evtchn, &console_mfn, hvm, pae, superpages,
+                            no_incr_generationid, &vm_generationid_addr);
 
     if ( ret == 0 )
     {
 	printf("store-mfn %li\n", store_mfn);
         if ( !hvm )
             printf("console-mfn %li\n", console_mfn);
+	printf("generation-id-address %lx\n", vm_generationid_addr);
 	fflush(stdout);
     }
 
diff -r d44e885e0389 -r e745cfbe7e11 tools/xcutils/xc_save.c
--- a/tools/xcutils/xc_save.c	Fri Dec 16 11:43:52 2011 +0000
+++ b/tools/xcutils/xc_save.c	Fri Dec 16 11:43:53 2011 +0000
@@ -169,6 +169,10 @@ main(int argc, char **argv)
     unsigned int maxit, max_f;
     int io_fd, ret, port;
     struct save_callbacks callbacks;
+    char path[128];
+    struct xs_handle *xs;
+    char *addr;
+    unsigned long vm_generationid_addr;
 
     if (argc != 6)
         errx(1, "usage: %s iofd domid maxit maxf flags", argv[0]);
@@ -207,8 +211,22 @@ main(int argc, char **argv)
     memset(&callbacks, 0, sizeof(callbacks));
     callbacks.suspend = suspend;
     callbacks.switch_qemu_logdirty = switch_qemu_logdirty;
+
+    sprintf(path, "/local/domain/%d/hvmloader/generation-id-address", si.domid);
+
+    if ((xs = xs_daemon_open()) == NULL)
+        errx(1, "Couldn't contact xenstore");
+
+    addr = xs_read(xs, XBT_NULL, path, NULL);
+
+    xs_daemon_close(xs);
+
+    vm_generationid_addr = (addr) ? strtoul(addr, NULL, 0) : 0;
+    free(addr);
+
     ret = xc_domain_save(si.xch, io_fd, si.domid, maxit, max_f, si.flags, 
-                         &callbacks, !!(si.flags & XCFLAGS_HVM));
+                         &callbacks, !!(si.flags & XCFLAGS_HVM),
+                         vm_generationid_addr);
 
     if (si.suspend_evtchn > 0)
 	 xc_suspend_evtchn_release(si.xch, si.xce, si.domid, si.suspend_evtchn);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 11:50:34 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 11: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.xensource.com>)
	id 1RbWIv-0003Vi-3U; Fri, 16 Dec 2011 11:50:21 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RbWIt-0003V3-4g
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 11:50:19 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1324036211!7734931!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjI0MzY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13351 invoked from network); 16 Dec 2011 11:50:13 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Dec 2011 11:50:13 -0000
X-IronPort-AV: E=Sophos;i="4.71,362,1320642000"; d="scan'208";a="174435051"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Dec 2011 06:50:08 -0500
Received: from cosworth.uk.xensource.com (10.80.16.52) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 16 Dec 2011 06:50:08 -0500
MIME-Version: 1.0
Message-ID: <patchbomb.1324036046@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 16 Dec 2011 11:47:26 +0000
From: Paul Durrant <paul.durrant@citrix.com>
To: xen-devel@lists.xensource.com
Cc: paul.durrant@citrix.com
Subject: [Xen-devel] [PATCH 0 of 3] Support for VM generation ID
	save/restore and migrate
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This patch series adds support for preservation of the VM generation ID buffer
address in xenstore across save/restore and migrate, and also code to increment
the value in all cases except for migration.
The first patch modifies creation of the hvmloader key in xenstore and adds
creation of a new read/write hvmloader/generation-id-addr key.
The second patch changes hvmloader to use the new key (as opposed to the old
data/generation-id key).
The third patch adds the infrastructure to save and restore the VM generation ID
address in xenstore and the code to increment the value.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 11:50:34 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 11: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.xensource.com>)
	id 1RbWIv-0003Vi-3U; Fri, 16 Dec 2011 11:50:21 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RbWIt-0003V3-4g
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 11:50:19 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1324036211!7734931!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjI0MzY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13351 invoked from network); 16 Dec 2011 11:50:13 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Dec 2011 11:50:13 -0000
X-IronPort-AV: E=Sophos;i="4.71,362,1320642000"; d="scan'208";a="174435051"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Dec 2011 06:50:08 -0500
Received: from cosworth.uk.xensource.com (10.80.16.52) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 16 Dec 2011 06:50:08 -0500
MIME-Version: 1.0
Message-ID: <patchbomb.1324036046@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 16 Dec 2011 11:47:26 +0000
From: Paul Durrant <paul.durrant@citrix.com>
To: xen-devel@lists.xensource.com
Cc: paul.durrant@citrix.com
Subject: [Xen-devel] [PATCH 0 of 3] Support for VM generation ID
	save/restore and migrate
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This patch series adds support for preservation of the VM generation ID buffer
address in xenstore across save/restore and migrate, and also code to increment
the value in all cases except for migration.
The first patch modifies creation of the hvmloader key in xenstore and adds
creation of a new read/write hvmloader/generation-id-addr key.
The second patch changes hvmloader to use the new key (as opposed to the old
data/generation-id key).
The third patch adds the infrastructure to save and restore the VM generation ID
address in xenstore and the code to increment the value.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 11:50:34 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 11: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.xensource.com>)
	id 1RbWIw-0003WD-53; Fri, 16 Dec 2011 11:50:22 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RbWIu-0003V5-5F
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 11:50:20 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1324036209!7731017!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDc2NTY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3808 invoked from network); 16 Dec 2011 11:50:13 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Dec 2011 11:50:13 -0000
X-IronPort-AV: E=Sophos;i="4.71,362,1320642000"; d="scan'208";a="20034942"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Dec 2011 06:50:09 -0500
Received: from cosworth.uk.xensource.com (10.80.16.52) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 16 Dec 2011 06:50:09 -0500
MIME-Version: 1.0
X-Mercurial-Node: 24fc8670dfcaa9cbdfd89532823b68feb96ca2eb
Message-ID: <24fc8670dfcaa9cbdfd8.1324036047@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1324036046@cosworth.uk.xensource.com>
References: <patchbomb.1324036046@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 16 Dec 2011 11:47:27 +0000
From: Paul Durrant <paul.durrant@citrix.com>
To: xen-devel@lists.xensource.com
Cc: paul.durrant@citrix.com
Subject: [Xen-devel] [PATCH 1 of 3] Make ro_paths and rw_paths dynamic
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Paul Durrant <paul.durrant@citrix.com>
# Date 1324035832 0
# Node ID 24fc8670dfcaa9cbdfd89532823b68feb96ca2eb
# Parent  03138a08366b895d79e143119d4c9c72833cdbcd
Make ro_paths and rw_paths dynamic.

The paths need to be different for the HVM and non-HVM cases as, in
the HVM case, we need an 'hvmloader' key. This was previously
handled by creating the hvmloader key in libxl__create_device_model(),
which is only invoked for HVM guests. However, if we are to use the
hvmloader key to parent the 'generation-id-address' key, the creation
needs to move earlier in the sequence. Handling this by making
ro_paths and rw_paths dynamic in libxl__domain_make() seems like
the cleanest approach.
The read-only 'error', 'drivers', 'attr' and 'messages' keys are no
longer created as they seem to be completely unused.

Signed-off-by: Paul Durrant <paul.durrant@citrix.com>

diff -r 03138a08366b -r 24fc8670dfca tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Fri Dec 09 16:19:36 2011 +0000
+++ b/tools/libxl/libxl_create.c	Fri Dec 16 11:43:52 2011 +0000
@@ -322,9 +322,10 @@ int libxl__domain_make(libxl__gc *gc, li
     libxl_ctx *ctx = libxl__gc_owner(gc);
     int flags, ret, i, rc;
     char *uuid_string;
-    char *rw_paths[] = { "control/shutdown", "device", "device/suspend/event-channel" , "data"};
-    char *ro_paths[] = { "cpu", "memory", "device", "error", "drivers",
-                         "control", "attr", "messages" };
+    char **ro_paths;
+    int nr_ro_paths;
+    char **rw_paths;
+    int nr_rw_paths;
     char *dom_path, *vm_path, *libxl_path;
     struct xs_permissions roperm[2];
     struct xs_permissions rwperm[1];
@@ -341,6 +342,31 @@ int libxl__domain_make(libxl__gc *gc, li
         goto out;
     }
 
+    nr_ro_paths = 0;
+    if (info->type == LIBXL_DOMAIN_TYPE_HVM) {
+        ro_paths = libxl__calloc(gc, 5, sizeof(char *));
+        ro_paths[nr_ro_paths++] = "hvmloader";
+    } else {
+        ro_paths = libxl__calloc(gc, 4, sizeof(char *));
+    }
+
+    ro_paths[nr_ro_paths++] = "cpu";
+    ro_paths[nr_ro_paths++] = "memory";
+    ro_paths[nr_ro_paths++] = "device";
+    ro_paths[nr_ro_paths++] = "control";
+
+    nr_rw_paths = 0;
+    if (info->type == LIBXL_DOMAIN_TYPE_HVM) {
+        rw_paths = libxl__calloc(gc, 4, sizeof(char *));
+        rw_paths[nr_rw_paths++] = "hvmloader/generation-id-address";
+    } else {
+        rw_paths = libxl__calloc(gc, 3, sizeof(char *));
+    }
+
+    rw_paths[nr_rw_paths++] = "control/shutdown";
+    rw_paths[nr_rw_paths++] = "device/suspend/event-channel";
+    rw_paths[nr_rw_paths++] = "data";
+
     flags = 0;
     if (info->type == LIBXL_DOMAIN_TYPE_HVM) {
         flags |= XEN_DOMCTL_CDF_hvm_guest;
@@ -414,16 +440,16 @@ retry_transaction:
     if (rc)
         goto out;
 
-    for (i = 0; i < ARRAY_SIZE(rw_paths); i++) {
-        char *path = libxl__sprintf(gc, "%s/%s", dom_path, rw_paths[i]);
-        xs_mkdir(ctx->xsh, t, path);
-        xs_set_permissions(ctx->xsh, t, path, rwperm, ARRAY_SIZE(rwperm));
-    }
     for (i = 0; i < ARRAY_SIZE(ro_paths); i++) {
         char *path = libxl__sprintf(gc, "%s/%s", dom_path, ro_paths[i]);
         xs_mkdir(ctx->xsh, t, path);
         xs_set_permissions(ctx->xsh, t, path, roperm, ARRAY_SIZE(roperm));
     }
+    for (i = 0; i < nr_rw_paths; i++) {
+        char *path = libxl__sprintf(gc, "%s/%s", dom_path, rw_paths[i]);
+        xs_mkdir(ctx->xsh, t, path);
+        xs_set_permissions(ctx->xsh, t, path, rwperm, ARRAY_SIZE(rwperm));
+    }
 
     xs_write(ctx->xsh, t, libxl__sprintf(gc, "%s/uuid", vm_path), uuid_string, strlen(uuid_string));
     xs_write(ctx->xsh, t, libxl__sprintf(gc, "%s/name", vm_path), info->name, strlen(info->name));
diff -r 03138a08366b -r 24fc8670dfca tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Fri Dec 09 16:19:36 2011 +0000
+++ b/tools/libxl/libxl_dm.c	Fri Dec 16 11:43:52 2011 +0000
@@ -821,9 +821,7 @@ int libxl__create_device_model(libxl__gc
         goto out;
     }
 
-    path = libxl__sprintf(gc, "/local/domain/%d/hvmloader", info->domid);
-    xs_mkdir(ctx->xsh, XBT_NULL, path);
-    libxl__xs_write(gc, XBT_NULL, libxl__sprintf(gc, "%s/bios", path),
+    libxl__xs_write(gc, XBT_NULL, libxl__sprintf(gc, "/local/domain/%d/hvmloader/bios", info->domid),
                     "%s", libxl__domain_bios(gc, info));
 
     path = libxl__sprintf(gc, "/local/domain/0/device-model/%d", info->domid);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 11:50:34 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 11: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.xensource.com>)
	id 1RbWIw-0003WD-53; Fri, 16 Dec 2011 11:50:22 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RbWIu-0003V5-5F
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 11:50:20 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1324036209!7731017!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDc2NTY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3808 invoked from network); 16 Dec 2011 11:50:13 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Dec 2011 11:50:13 -0000
X-IronPort-AV: E=Sophos;i="4.71,362,1320642000"; d="scan'208";a="20034942"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Dec 2011 06:50:09 -0500
Received: from cosworth.uk.xensource.com (10.80.16.52) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 16 Dec 2011 06:50:09 -0500
MIME-Version: 1.0
X-Mercurial-Node: 24fc8670dfcaa9cbdfd89532823b68feb96ca2eb
Message-ID: <24fc8670dfcaa9cbdfd8.1324036047@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1324036046@cosworth.uk.xensource.com>
References: <patchbomb.1324036046@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 16 Dec 2011 11:47:27 +0000
From: Paul Durrant <paul.durrant@citrix.com>
To: xen-devel@lists.xensource.com
Cc: paul.durrant@citrix.com
Subject: [Xen-devel] [PATCH 1 of 3] Make ro_paths and rw_paths dynamic
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Paul Durrant <paul.durrant@citrix.com>
# Date 1324035832 0
# Node ID 24fc8670dfcaa9cbdfd89532823b68feb96ca2eb
# Parent  03138a08366b895d79e143119d4c9c72833cdbcd
Make ro_paths and rw_paths dynamic.

The paths need to be different for the HVM and non-HVM cases as, in
the HVM case, we need an 'hvmloader' key. This was previously
handled by creating the hvmloader key in libxl__create_device_model(),
which is only invoked for HVM guests. However, if we are to use the
hvmloader key to parent the 'generation-id-address' key, the creation
needs to move earlier in the sequence. Handling this by making
ro_paths and rw_paths dynamic in libxl__domain_make() seems like
the cleanest approach.
The read-only 'error', 'drivers', 'attr' and 'messages' keys are no
longer created as they seem to be completely unused.

Signed-off-by: Paul Durrant <paul.durrant@citrix.com>

diff -r 03138a08366b -r 24fc8670dfca tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Fri Dec 09 16:19:36 2011 +0000
+++ b/tools/libxl/libxl_create.c	Fri Dec 16 11:43:52 2011 +0000
@@ -322,9 +322,10 @@ int libxl__domain_make(libxl__gc *gc, li
     libxl_ctx *ctx = libxl__gc_owner(gc);
     int flags, ret, i, rc;
     char *uuid_string;
-    char *rw_paths[] = { "control/shutdown", "device", "device/suspend/event-channel" , "data"};
-    char *ro_paths[] = { "cpu", "memory", "device", "error", "drivers",
-                         "control", "attr", "messages" };
+    char **ro_paths;
+    int nr_ro_paths;
+    char **rw_paths;
+    int nr_rw_paths;
     char *dom_path, *vm_path, *libxl_path;
     struct xs_permissions roperm[2];
     struct xs_permissions rwperm[1];
@@ -341,6 +342,31 @@ int libxl__domain_make(libxl__gc *gc, li
         goto out;
     }
 
+    nr_ro_paths = 0;
+    if (info->type == LIBXL_DOMAIN_TYPE_HVM) {
+        ro_paths = libxl__calloc(gc, 5, sizeof(char *));
+        ro_paths[nr_ro_paths++] = "hvmloader";
+    } else {
+        ro_paths = libxl__calloc(gc, 4, sizeof(char *));
+    }
+
+    ro_paths[nr_ro_paths++] = "cpu";
+    ro_paths[nr_ro_paths++] = "memory";
+    ro_paths[nr_ro_paths++] = "device";
+    ro_paths[nr_ro_paths++] = "control";
+
+    nr_rw_paths = 0;
+    if (info->type == LIBXL_DOMAIN_TYPE_HVM) {
+        rw_paths = libxl__calloc(gc, 4, sizeof(char *));
+        rw_paths[nr_rw_paths++] = "hvmloader/generation-id-address";
+    } else {
+        rw_paths = libxl__calloc(gc, 3, sizeof(char *));
+    }
+
+    rw_paths[nr_rw_paths++] = "control/shutdown";
+    rw_paths[nr_rw_paths++] = "device/suspend/event-channel";
+    rw_paths[nr_rw_paths++] = "data";
+
     flags = 0;
     if (info->type == LIBXL_DOMAIN_TYPE_HVM) {
         flags |= XEN_DOMCTL_CDF_hvm_guest;
@@ -414,16 +440,16 @@ retry_transaction:
     if (rc)
         goto out;
 
-    for (i = 0; i < ARRAY_SIZE(rw_paths); i++) {
-        char *path = libxl__sprintf(gc, "%s/%s", dom_path, rw_paths[i]);
-        xs_mkdir(ctx->xsh, t, path);
-        xs_set_permissions(ctx->xsh, t, path, rwperm, ARRAY_SIZE(rwperm));
-    }
     for (i = 0; i < ARRAY_SIZE(ro_paths); i++) {
         char *path = libxl__sprintf(gc, "%s/%s", dom_path, ro_paths[i]);
         xs_mkdir(ctx->xsh, t, path);
         xs_set_permissions(ctx->xsh, t, path, roperm, ARRAY_SIZE(roperm));
     }
+    for (i = 0; i < nr_rw_paths; i++) {
+        char *path = libxl__sprintf(gc, "%s/%s", dom_path, rw_paths[i]);
+        xs_mkdir(ctx->xsh, t, path);
+        xs_set_permissions(ctx->xsh, t, path, rwperm, ARRAY_SIZE(rwperm));
+    }
 
     xs_write(ctx->xsh, t, libxl__sprintf(gc, "%s/uuid", vm_path), uuid_string, strlen(uuid_string));
     xs_write(ctx->xsh, t, libxl__sprintf(gc, "%s/name", vm_path), info->name, strlen(info->name));
diff -r 03138a08366b -r 24fc8670dfca tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Fri Dec 09 16:19:36 2011 +0000
+++ b/tools/libxl/libxl_dm.c	Fri Dec 16 11:43:52 2011 +0000
@@ -821,9 +821,7 @@ int libxl__create_device_model(libxl__gc
         goto out;
     }
 
-    path = libxl__sprintf(gc, "/local/domain/%d/hvmloader", info->domid);
-    xs_mkdir(ctx->xsh, XBT_NULL, path);
-    libxl__xs_write(gc, XBT_NULL, libxl__sprintf(gc, "%s/bios", path),
+    libxl__xs_write(gc, XBT_NULL, libxl__sprintf(gc, "/local/domain/%d/hvmloader/bios", info->domid),
                     "%s", libxl__domain_bios(gc, info));
 
     path = libxl__sprintf(gc, "/local/domain/0/device-model/%d", info->domid);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 12:01:38 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 12:01:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbWTY-0004Kz-6R; Fri, 16 Dec 2011 12:01:20 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RbWTV-0004KO-SV
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 12:01:18 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1324036869!7725455!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjU3OQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24658 invoked from network); 16 Dec 2011 12:01:09 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Dec 2011 12:01:09 -0000
X-IronPort-AV: E=Sophos;i="4.71,362,1320624000"; 
   d="scan'208";a="9512157"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Dec 2011 12:01:09 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 16 Dec 2011 12:01:09 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RbWTN-0005Mj-0b;
	Fri, 16 Dec 2011 12:01:09 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RbWTM-0005fR-Rf;
	Fri, 16 Dec 2011 12:01:08 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10515-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 16 Dec 2011 12:01:08 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10515: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10515 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10515/

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-amd64-xl-sedf 14 guest-localmigrate/x10 fail in 10504 REGR. vs. 10491

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-credit2    7 debian-install              fail pass in 10511
 test-amd64-amd64-xl-sedf      5 xen-boot                    fail pass in 10511
 test-amd64-amd64-xl-sedf   13 guest-localmigrate.2 fail in 10511 pass in 10504
 test-i386-i386-win            7 windows-install    fail in 10511 pass in 10515
 test-amd64-i386-win           7 windows-install    fail in 10504 pass in 10515
 test-amd64-amd64-xl-winxpsp3  7 windows-install    fail in 10504 pass in 10515

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xend-winxpsp3  7 windows-install              fail  like 10491
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check     fail in 10511 never pass

version targeted for testing:
 xen                  01c8b27e3d7d
baseline version:
 xen                  03138a08366b

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Christoph Egger <Christoph.Egger@amd.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Liu, Jinsong <jinsong.liu@intel.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   24416:01c8b27e3d7d
tag:         tip
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Thu Dec 15 16:56:21 2011 +0000
    
    libxl: remove stubdom device model save file when destroying stubdom
    
    /var/lib/xen/qemu-save.<domid> is created when the stub domain is started
    (connected to a stubdom console) and is used to save the device model state on
    suspend/migrate but never cleaned up.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24415:27736c7944b9
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Thu Dec 15 16:53:52 2011 +0000
    
    oxenstored: Always log something at start of day (if logging enabled at all)
    
    Otherwise at the default level we rarely log anything at all.
    
    A completely empty log file is a good sign, but only if you know you are
    looking in the right place...
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24414:de4034343b3a
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Thu Dec 15 16:52:22 2011 +0000
    
    oxenstored: install configuration file
    
    First though:
      - Move it to /etc/xen/oxenstored.conf.
      - Use /var/run/xenstored.pid as default pid file
      - Disable test-eagain "Randomly failed a transaction with EAGAIN. Used for
        testing Xs user". Doesn't sound fun by default...
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24413:a9d61ea9973a
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Thu Dec 15 16:50:36 2011 +0000
    
    oxenstored: handle unknown operations by returning an error to the client
    
    Previous an unknown operation would be decoded as a Not_found exception which
    would bubble all the way up to the try ... with surrounding the call to
    main_loop where it would be logged and ignored.
    
    This would leave the guest hanging waiting for a response to the invalid
    request.
    
    Instead introduce a specific "Invalid" operation. Higher level functionality,
    such as Process.process_packet, already handles operations which are not
    understood with an error reply due to the final wildcard entry in
    Process.function_of_type but explicitly handle Invalid this way to make it
    clear what is going on.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24412:99caac2e35df
user:        Jan Beulich <jbeulich@suse.com>
date:        Thu Dec 15 14:28:45 2011 +0100
    
    x86/AMD: use correct shift count when merging model and stepping
    
    ... for legacy errata matching.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24411:ca5f588bd203
user:        Christoph Egger <Christoph.Egger@amd.com>
date:        Thu Dec 15 11:00:09 2011 +0100
    
    x86/ucode: fix for AMD Fam15 CPUs
    
    Remove hardcoded maximum size a microcode patch can have. This is
    dynamic now.
    
    The microcode patch for family15h can be larger than 2048 bytes and
    gets silently truncated.
    
    Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Committed-by: Jan Beulich <jbeulich@suse.com>
    
    
changeset:   24410:25f8952313ae
user:        Liu, Jinsong <jinsong.liu@intel.com>
date:        Thu Dec 15 10:58:53 2011 +0100
    
    x86/MCE: add more strict sanity check of one SRAR case
    
    When RIPV = EIPV = 0, it's a little bit tricky. It may be an asynchronic error, currently we have no way to precisely locate whether the error occur at guest or hypervisor.
    To avoid handling error in wrong way, we treat it as unrecovered.
    
    Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Committed-by: Jan Beulich <jbeulich@suse.com>
    
    
changeset:   24409:0cd9f3e5f3e0
user:        Liu, Jinsong <jinsong.liu@intel.com>
date:        Thu Dec 15 10:54:51 2011 +0100
    
    x86/MCE: add SRAR handler
    
    Currently Intel SDM add 2 kinds of MCE SRAR errors:
    1). Data Load error, error code = 0x134
    2). Instruction Fetch error, error code = 0x150
    This patch add handler to these new SRAR errors.
    It based on existed mce infrastructure, add code to handle SRAR specific error.
    
    Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
    Committed-by: Jan Beulich <jbeulich@suse.com>
    
    
changeset:   24408:5d2dd48bce21
user:        Andrew Cooper <andrew.cooper3@citrix.com>
date:        Wed Dec 14 17:53:54 2011 +0100
    
    XLAT.lst whitespace fix.
    
    Replace spaces with tabs to be in line with file format.
    
    Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
    Committed-by: Jan Beulich <jbeulich@suse.com>
    
    
changeset:   24407:03138a08366b
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Fri Dec 09 16:19:36 2011 +0000
    
    oxenstored: log Errors and Warnings by default.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Acked-by: Ian Jackson <ian.jackson.citrix.com>
    Committed-by: Ian Jackson <ian.jackson.citrix.com>
    
    
========================================
commit 54e24021005458ad0a361c1d83011b751726a94b
Author: Ian Jackson <ian.jackson@eu.citrix.com>
Date:   Thu Dec 8 16:38:06 2011 +0000

    qemu_get_timer: Provide a comment about the behaviour on ts==NULL
    
    Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 12:01:38 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 12:01:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbWTY-0004Kz-6R; Fri, 16 Dec 2011 12:01:20 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RbWTV-0004KO-SV
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 12:01:18 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1324036869!7725455!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjU3OQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24658 invoked from network); 16 Dec 2011 12:01:09 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Dec 2011 12:01:09 -0000
X-IronPort-AV: E=Sophos;i="4.71,362,1320624000"; 
   d="scan'208";a="9512157"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Dec 2011 12:01:09 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 16 Dec 2011 12:01:09 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RbWTN-0005Mj-0b;
	Fri, 16 Dec 2011 12:01:09 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RbWTM-0005fR-Rf;
	Fri, 16 Dec 2011 12:01:08 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10515-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 16 Dec 2011 12:01:08 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10515: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10515 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10515/

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-amd64-xl-sedf 14 guest-localmigrate/x10 fail in 10504 REGR. vs. 10491

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-credit2    7 debian-install              fail pass in 10511
 test-amd64-amd64-xl-sedf      5 xen-boot                    fail pass in 10511
 test-amd64-amd64-xl-sedf   13 guest-localmigrate.2 fail in 10511 pass in 10504
 test-i386-i386-win            7 windows-install    fail in 10511 pass in 10515
 test-amd64-i386-win           7 windows-install    fail in 10504 pass in 10515
 test-amd64-amd64-xl-winxpsp3  7 windows-install    fail in 10504 pass in 10515

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xend-winxpsp3  7 windows-install              fail  like 10491
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check     fail in 10511 never pass

version targeted for testing:
 xen                  01c8b27e3d7d
baseline version:
 xen                  03138a08366b

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Christoph Egger <Christoph.Egger@amd.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Liu, Jinsong <jinsong.liu@intel.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   24416:01c8b27e3d7d
tag:         tip
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Thu Dec 15 16:56:21 2011 +0000
    
    libxl: remove stubdom device model save file when destroying stubdom
    
    /var/lib/xen/qemu-save.<domid> is created when the stub domain is started
    (connected to a stubdom console) and is used to save the device model state on
    suspend/migrate but never cleaned up.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24415:27736c7944b9
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Thu Dec 15 16:53:52 2011 +0000
    
    oxenstored: Always log something at start of day (if logging enabled at all)
    
    Otherwise at the default level we rarely log anything at all.
    
    A completely empty log file is a good sign, but only if you know you are
    looking in the right place...
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24414:de4034343b3a
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Thu Dec 15 16:52:22 2011 +0000
    
    oxenstored: install configuration file
    
    First though:
      - Move it to /etc/xen/oxenstored.conf.
      - Use /var/run/xenstored.pid as default pid file
      - Disable test-eagain "Randomly failed a transaction with EAGAIN. Used for
        testing Xs user". Doesn't sound fun by default...
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24413:a9d61ea9973a
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Thu Dec 15 16:50:36 2011 +0000
    
    oxenstored: handle unknown operations by returning an error to the client
    
    Previous an unknown operation would be decoded as a Not_found exception which
    would bubble all the way up to the try ... with surrounding the call to
    main_loop where it would be logged and ignored.
    
    This would leave the guest hanging waiting for a response to the invalid
    request.
    
    Instead introduce a specific "Invalid" operation. Higher level functionality,
    such as Process.process_packet, already handles operations which are not
    understood with an error reply due to the final wildcard entry in
    Process.function_of_type but explicitly handle Invalid this way to make it
    clear what is going on.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24412:99caac2e35df
user:        Jan Beulich <jbeulich@suse.com>
date:        Thu Dec 15 14:28:45 2011 +0100
    
    x86/AMD: use correct shift count when merging model and stepping
    
    ... for legacy errata matching.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24411:ca5f588bd203
user:        Christoph Egger <Christoph.Egger@amd.com>
date:        Thu Dec 15 11:00:09 2011 +0100
    
    x86/ucode: fix for AMD Fam15 CPUs
    
    Remove hardcoded maximum size a microcode patch can have. This is
    dynamic now.
    
    The microcode patch for family15h can be larger than 2048 bytes and
    gets silently truncated.
    
    Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Committed-by: Jan Beulich <jbeulich@suse.com>
    
    
changeset:   24410:25f8952313ae
user:        Liu, Jinsong <jinsong.liu@intel.com>
date:        Thu Dec 15 10:58:53 2011 +0100
    
    x86/MCE: add more strict sanity check of one SRAR case
    
    When RIPV = EIPV = 0, it's a little bit tricky. It may be an asynchronic error, currently we have no way to precisely locate whether the error occur at guest or hypervisor.
    To avoid handling error in wrong way, we treat it as unrecovered.
    
    Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Committed-by: Jan Beulich <jbeulich@suse.com>
    
    
changeset:   24409:0cd9f3e5f3e0
user:        Liu, Jinsong <jinsong.liu@intel.com>
date:        Thu Dec 15 10:54:51 2011 +0100
    
    x86/MCE: add SRAR handler
    
    Currently Intel SDM add 2 kinds of MCE SRAR errors:
    1). Data Load error, error code = 0x134
    2). Instruction Fetch error, error code = 0x150
    This patch add handler to these new SRAR errors.
    It based on existed mce infrastructure, add code to handle SRAR specific error.
    
    Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
    Committed-by: Jan Beulich <jbeulich@suse.com>
    
    
changeset:   24408:5d2dd48bce21
user:        Andrew Cooper <andrew.cooper3@citrix.com>
date:        Wed Dec 14 17:53:54 2011 +0100
    
    XLAT.lst whitespace fix.
    
    Replace spaces with tabs to be in line with file format.
    
    Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
    Committed-by: Jan Beulich <jbeulich@suse.com>
    
    
changeset:   24407:03138a08366b
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Fri Dec 09 16:19:36 2011 +0000
    
    oxenstored: log Errors and Warnings by default.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Acked-by: Ian Jackson <ian.jackson.citrix.com>
    Committed-by: Ian Jackson <ian.jackson.citrix.com>
    
    
========================================
commit 54e24021005458ad0a361c1d83011b751726a94b
Author: Ian Jackson <ian.jackson@eu.citrix.com>
Date:   Thu Dec 8 16:38:06 2011 +0000

    qemu_get_timer: Provide a comment about the behaviour on ts==NULL
    
    Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 12:02:37 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 12:02:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbWUY-0004RM-NI; Fri, 16 Dec 2011 12:02:22 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RbWUY-0004RC-05
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 12:02:22 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1324036921!49574925!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjU3OQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17455 invoked from network); 16 Dec 2011 12:02:01 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Dec 2011 12:02:01 -0000
X-IronPort-AV: E=Sophos;i="4.71,362,1320624000"; 
   d="scan'208";a="9512192"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Dec 2011 12:02:20 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 16 Dec 2011 12:02:20 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Paul Durrant <paul.durrant@citrix.com>
Date: Fri, 16 Dec 2011 12:02:20 +0000
In-Reply-To: <24fc8670dfcaa9cbdfd8.1324036047@cosworth.uk.xensource.com>
References: <patchbomb.1324036046@cosworth.uk.xensource.com>
	<24fc8670dfcaa9cbdfd8.1324036047@cosworth.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1324036940.20077.593.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 1 of 3] Make ro_paths and rw_paths dynamic
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2011-12-16 at 11:47 +0000, Paul Durrant wrote:
> +    nr_ro_paths = 0;
> +    if (info->type == LIBXL_DOMAIN_TYPE_HVM) {
> +        ro_paths = libxl__calloc(gc, 5, sizeof(char *));
> +        ro_paths[nr_ro_paths++] = "hvmloader";
> +    } else {
> +        ro_paths = libxl__calloc(gc, 4, sizeof(char *));
> +    }
> +
> +    ro_paths[nr_ro_paths++] = "cpu";
> +    ro_paths[nr_ro_paths++] = "memory";
> +    ro_paths[nr_ro_paths++] = "device";
> +    ro_paths[nr_ro_paths++] = "control"; 

The flexarray stuff allows you do to this sort of thing without worrying
about running off the end of the allocated array etc.

Part of me thinks that if the arrays aren't static any more you might as
well just do the create in an open coded list, instead of open coding
the creation of a list and then iterating over it.

A helper function like libxl__xs_mkdir(gc, t, path, perm) would reduce
the amount of boilerplate.

> @@ -414,16 +440,16 @@ retry_transaction:
>      if (rc)
>          goto out;
>  
> -    for (i = 0; i < ARRAY_SIZE(rw_paths); i++) {
> -        char *path = libxl__sprintf(gc, "%s/%s", dom_path, rw_paths[i]);
> -        xs_mkdir(ctx->xsh, t, path);
> -        xs_set_permissions(ctx->xsh, t, path, rwperm, ARRAY_SIZE(rwperm));
> -    }
>      for (i = 0; i < ARRAY_SIZE(ro_paths); i++) {
>          char *path = libxl__sprintf(gc, "%s/%s", dom_path, ro_paths[i]);
>          xs_mkdir(ctx->xsh, t, path);
>          xs_set_permissions(ctx->xsh, t, path, roperm, ARRAY_SIZE(roperm));
>      }
> +    for (i = 0; i < nr_rw_paths; i++) {
> +        char *path = libxl__sprintf(gc, "%s/%s", dom_path, rw_paths[i]);
> +        xs_mkdir(ctx->xsh, t, path);
> +        xs_set_permissions(ctx->xsh, t, path, rwperm, ARRAY_SIZE(rwperm));
> +    }

What does "xenstore-ls -fp" show before and after this re-ordering?

>      xs_write(ctx->xsh, t, libxl__sprintf(gc, "%s/uuid", vm_path), uuid_string, strlen(uuid_string));
>      xs_write(ctx->xsh, t, libxl__sprintf(gc, "%s/name", vm_path), info->name, strlen(info->name));


> diff -r 03138a08366b -r 24fc8670dfca tools/libxl/libxl_dm.c
> --- a/tools/libxl/libxl_dm.c    Fri Dec 09 16:19:36 2011 +0000
> +++ b/tools/libxl/libxl_dm.c    Fri Dec 16 11:43:52 2011 +0000
> @@ -821,9 +821,7 @@ int libxl__create_device_model(libxl__gc
>          goto out;
>      }
>  
> -    path = libxl__sprintf(gc, "/local/domain/%d/hvmloader", info->domid);
> -    xs_mkdir(ctx->xsh, XBT_NULL, path);
> -    libxl__xs_write(gc, XBT_NULL, libxl__sprintf(gc, "%s/bios", path),
> +    libxl__xs_write(gc, XBT_NULL, libxl__sprintf(gc, "/local/domain/%d/hvmloader/bios", info->domid),
>                      "%s", libxl__domain_bios(gc, info));
>  
>      path = libxl__sprintf(gc, "/local/domain/0/device-model/%d", info->domid);

Pre-existing problem but this should be libxl__xs_get_dompath.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 12:02:37 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 12:02:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbWUY-0004RM-NI; Fri, 16 Dec 2011 12:02:22 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RbWUY-0004RC-05
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 12:02:22 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1324036921!49574925!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjU3OQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17455 invoked from network); 16 Dec 2011 12:02:01 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Dec 2011 12:02:01 -0000
X-IronPort-AV: E=Sophos;i="4.71,362,1320624000"; 
   d="scan'208";a="9512192"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Dec 2011 12:02:20 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 16 Dec 2011 12:02:20 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Paul Durrant <paul.durrant@citrix.com>
Date: Fri, 16 Dec 2011 12:02:20 +0000
In-Reply-To: <24fc8670dfcaa9cbdfd8.1324036047@cosworth.uk.xensource.com>
References: <patchbomb.1324036046@cosworth.uk.xensource.com>
	<24fc8670dfcaa9cbdfd8.1324036047@cosworth.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1324036940.20077.593.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 1 of 3] Make ro_paths and rw_paths dynamic
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2011-12-16 at 11:47 +0000, Paul Durrant wrote:
> +    nr_ro_paths = 0;
> +    if (info->type == LIBXL_DOMAIN_TYPE_HVM) {
> +        ro_paths = libxl__calloc(gc, 5, sizeof(char *));
> +        ro_paths[nr_ro_paths++] = "hvmloader";
> +    } else {
> +        ro_paths = libxl__calloc(gc, 4, sizeof(char *));
> +    }
> +
> +    ro_paths[nr_ro_paths++] = "cpu";
> +    ro_paths[nr_ro_paths++] = "memory";
> +    ro_paths[nr_ro_paths++] = "device";
> +    ro_paths[nr_ro_paths++] = "control"; 

The flexarray stuff allows you do to this sort of thing without worrying
about running off the end of the allocated array etc.

Part of me thinks that if the arrays aren't static any more you might as
well just do the create in an open coded list, instead of open coding
the creation of a list and then iterating over it.

A helper function like libxl__xs_mkdir(gc, t, path, perm) would reduce
the amount of boilerplate.

> @@ -414,16 +440,16 @@ retry_transaction:
>      if (rc)
>          goto out;
>  
> -    for (i = 0; i < ARRAY_SIZE(rw_paths); i++) {
> -        char *path = libxl__sprintf(gc, "%s/%s", dom_path, rw_paths[i]);
> -        xs_mkdir(ctx->xsh, t, path);
> -        xs_set_permissions(ctx->xsh, t, path, rwperm, ARRAY_SIZE(rwperm));
> -    }
>      for (i = 0; i < ARRAY_SIZE(ro_paths); i++) {
>          char *path = libxl__sprintf(gc, "%s/%s", dom_path, ro_paths[i]);
>          xs_mkdir(ctx->xsh, t, path);
>          xs_set_permissions(ctx->xsh, t, path, roperm, ARRAY_SIZE(roperm));
>      }
> +    for (i = 0; i < nr_rw_paths; i++) {
> +        char *path = libxl__sprintf(gc, "%s/%s", dom_path, rw_paths[i]);
> +        xs_mkdir(ctx->xsh, t, path);
> +        xs_set_permissions(ctx->xsh, t, path, rwperm, ARRAY_SIZE(rwperm));
> +    }

What does "xenstore-ls -fp" show before and after this re-ordering?

>      xs_write(ctx->xsh, t, libxl__sprintf(gc, "%s/uuid", vm_path), uuid_string, strlen(uuid_string));
>      xs_write(ctx->xsh, t, libxl__sprintf(gc, "%s/name", vm_path), info->name, strlen(info->name));


> diff -r 03138a08366b -r 24fc8670dfca tools/libxl/libxl_dm.c
> --- a/tools/libxl/libxl_dm.c    Fri Dec 09 16:19:36 2011 +0000
> +++ b/tools/libxl/libxl_dm.c    Fri Dec 16 11:43:52 2011 +0000
> @@ -821,9 +821,7 @@ int libxl__create_device_model(libxl__gc
>          goto out;
>      }
>  
> -    path = libxl__sprintf(gc, "/local/domain/%d/hvmloader", info->domid);
> -    xs_mkdir(ctx->xsh, XBT_NULL, path);
> -    libxl__xs_write(gc, XBT_NULL, libxl__sprintf(gc, "%s/bios", path),
> +    libxl__xs_write(gc, XBT_NULL, libxl__sprintf(gc, "/local/domain/%d/hvmloader/bios", info->domid),
>                      "%s", libxl__domain_bios(gc, info));
>  
>      path = libxl__sprintf(gc, "/local/domain/0/device-model/%d", info->domid);

Pre-existing problem but this should be libxl__xs_get_dompath.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 12:08:12 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 12:08:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbWZu-0004oj-HQ; Fri, 16 Dec 2011 12:07:54 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RbWZs-0004oU-Q2
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 12:07:53 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1324037266!2217567!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjU3OQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11102 invoked from network); 16 Dec 2011 12:07:46 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Dec 2011 12:07:46 -0000
X-IronPort-AV: E=Sophos;i="4.71,362,1320624000"; 
   d="scan'208";a="9512417"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Dec 2011 12:07:46 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 16 Dec 2011 12:07:46 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Paul Durrant <paul.durrant@citrix.com>
Date: Fri, 16 Dec 2011 12:07:46 +0000
In-Reply-To: <e745cfbe7e114cb8a8c3.1324036049@cosworth.uk.xensource.com>
References: <patchbomb.1324036046@cosworth.uk.xensource.com>
	<e745cfbe7e114cb8a8c3.1324036049@cosworth.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1324037266.20077.596.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 3 of 3] VM generation ID save/restore and
 migrate
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2011-12-16 at 11:47 +0000, Paul Durrant wrote:
> diff -r d44e885e0389 -r e745cfbe7e11 tools/python/xen/lowlevel/checkpoint/libcheckpoint.c
> --- a/tools/python/xen/lowlevel/checkpoint/libcheckpoint.c      Fri Dec 16 11:43:52 2011 +0000
> +++ b/tools/python/xen/lowlevel/checkpoint/libcheckpoint.c      Fri Dec 16 11:43:53 2011 +0000
> @@ -175,6 +175,7 @@ int checkpoint_start(checkpoint_state* s
>  {
>      int hvm, rc;
>      int flags = XCFLAGS_LIVE;
> +    unsigned long vm_generationid_addr;
> 
>      if (!s->domid) {
>         s->errstr = "checkpoint state not opened";
> @@ -185,16 +186,28 @@ int checkpoint_start(checkpoint_state* s
> 
>      hvm = s->domtype > dt_pv;
>      if (hvm) {
> +       char path[128];
> +       char *addr;
> +
> +       sprintf(path, "/local/domain/%u/hvmloader/generation-id-address", s->domid);

xs_get_domain_path() gives you the correct base path (I saw at least one
more of these).

> diff -r d44e885e0389 -r e745cfbe7e11 tools/xcutils/xc_restore.c
> --- a/tools/xcutils/xc_restore.c        Fri Dec 16 11:43:52 2011 +0000
> +++ b/tools/xcutils/xc_restore.c        Fri Dec 16 11:43:53 2011 +0000
[...]
> diff -r d44e885e0389 -r e745cfbe7e11 tools/xcutils/xc_save.c
> --- a/tools/xcutils/xc_save.c   Fri Dec 16 11:43:52 2011 +0000
> +++ b/tools/xcutils/xc_save.c   Fri Dec 16 11:43:53 2011 +0000
[...]

AFAIK these two are only used by xend so unless you are adding support
for this stuff there (it's deprecated so no need) this isn't necessary,
also I think xend reads the stdout of one or both and you've added to
what gets printed, running the risk of breaking things.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 12:08:12 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 12:08:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbWZu-0004oj-HQ; Fri, 16 Dec 2011 12:07:54 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RbWZs-0004oU-Q2
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 12:07:53 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1324037266!2217567!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjU3OQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11102 invoked from network); 16 Dec 2011 12:07:46 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Dec 2011 12:07:46 -0000
X-IronPort-AV: E=Sophos;i="4.71,362,1320624000"; 
   d="scan'208";a="9512417"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Dec 2011 12:07:46 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 16 Dec 2011 12:07:46 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Paul Durrant <paul.durrant@citrix.com>
Date: Fri, 16 Dec 2011 12:07:46 +0000
In-Reply-To: <e745cfbe7e114cb8a8c3.1324036049@cosworth.uk.xensource.com>
References: <patchbomb.1324036046@cosworth.uk.xensource.com>
	<e745cfbe7e114cb8a8c3.1324036049@cosworth.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1324037266.20077.596.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 3 of 3] VM generation ID save/restore and
 migrate
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2011-12-16 at 11:47 +0000, Paul Durrant wrote:
> diff -r d44e885e0389 -r e745cfbe7e11 tools/python/xen/lowlevel/checkpoint/libcheckpoint.c
> --- a/tools/python/xen/lowlevel/checkpoint/libcheckpoint.c      Fri Dec 16 11:43:52 2011 +0000
> +++ b/tools/python/xen/lowlevel/checkpoint/libcheckpoint.c      Fri Dec 16 11:43:53 2011 +0000
> @@ -175,6 +175,7 @@ int checkpoint_start(checkpoint_state* s
>  {
>      int hvm, rc;
>      int flags = XCFLAGS_LIVE;
> +    unsigned long vm_generationid_addr;
> 
>      if (!s->domid) {
>         s->errstr = "checkpoint state not opened";
> @@ -185,16 +186,28 @@ int checkpoint_start(checkpoint_state* s
> 
>      hvm = s->domtype > dt_pv;
>      if (hvm) {
> +       char path[128];
> +       char *addr;
> +
> +       sprintf(path, "/local/domain/%u/hvmloader/generation-id-address", s->domid);

xs_get_domain_path() gives you the correct base path (I saw at least one
more of these).

> diff -r d44e885e0389 -r e745cfbe7e11 tools/xcutils/xc_restore.c
> --- a/tools/xcutils/xc_restore.c        Fri Dec 16 11:43:52 2011 +0000
> +++ b/tools/xcutils/xc_restore.c        Fri Dec 16 11:43:53 2011 +0000
[...]
> diff -r d44e885e0389 -r e745cfbe7e11 tools/xcutils/xc_save.c
> --- a/tools/xcutils/xc_save.c   Fri Dec 16 11:43:52 2011 +0000
> +++ b/tools/xcutils/xc_save.c   Fri Dec 16 11:43:53 2011 +0000
[...]

AFAIK these two are only used by xend so unless you are adding support
for this stuff there (it's deprecated so no need) this isn't necessary,
also I think xend reads the stdout of one or both and you've added to
what gets printed, running the risk of breaking things.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 12:47:48 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 12:47:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbXC5-0005Kf-Uh; Fri, 16 Dec 2011 12:47:21 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RbXC4-0005KX-NP
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 12:47:20 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1324039630!7743271!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjU3OQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4284 invoked from network); 16 Dec 2011 12:47:14 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Dec 2011 12:47:14 -0000
X-IronPort-AV: E=Sophos;i="4.71,363,1320624000"; 
   d="scan'208";a="9513640"
Received: from lonpmailmx02.citrite.net ([10.30.203.163])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Dec 2011 12:47:10 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.161]) by
	LONPMAILMX02.citrite.net ([10.30.203.163]) with mapi; Fri, 16 Dec 2011
	12:47:10 +0000
From: Paul Durrant <Paul.Durrant@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Fri, 16 Dec 2011 12:47:09 +0000
Thread-Topic: [Xen-devel] [PATCH 1 of 3] Make ro_paths and rw_paths dynamic
Thread-Index: Acy76pX8rvc6bbJRRW2V1w+FuhNCywABhx7Q
Message-ID: <291EDFCB1E9E224A99088639C4762022B598ED0FE2@LONPMAILBOX01.citrite.net>
References: <patchbomb.1324036046@cosworth.uk.xensource.com>
	<24fc8670dfcaa9cbdfd8.1324036047@cosworth.uk.xensource.com>
	<1324036940.20077.593.camel@zakaz.uk.xensource.com>
In-Reply-To: <1324036940.20077.593.camel@zakaz.uk.xensource.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 1 of 3] Make ro_paths and rw_paths dynamic
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> -----Original Message-----
> From: Ian Campbell
> Sent: 16 December 2011 12:02
> To: Paul Durrant
> Cc: xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] [PATCH 1 of 3] Make ro_paths and rw_paths
> dynamic
> 
> On Fri, 2011-12-16 at 11:47 +0000, Paul Durrant wrote:
> > +    nr_ro_paths = 0;
> > +    if (info->type == LIBXL_DOMAIN_TYPE_HVM) {
> > +        ro_paths = libxl__calloc(gc, 5, sizeof(char *));
> > +        ro_paths[nr_ro_paths++] = "hvmloader";
> > +    } else {
> > +        ro_paths = libxl__calloc(gc, 4, sizeof(char *));
> > +    }
> > +
> > +    ro_paths[nr_ro_paths++] = "cpu";
> > +    ro_paths[nr_ro_paths++] = "memory";
> > +    ro_paths[nr_ro_paths++] = "device";
> > +    ro_paths[nr_ro_paths++] = "control";
> 
> The flexarray stuff allows you do to this sort of thing without
> worrying about running off the end of the allocated array etc.
> 
> Part of me thinks that if the arrays aren't static any more you
> might as well just do the create in an open coded list, instead of
> open coding the creation of a list and then iterating over it.
> 
> A helper function like libxl__xs_mkdir(gc, t, path, perm) would
> reduce the amount of boilerplate.
> 

Actually, yes, the helper function would be a much neater solution. I'll go for that.

  Paul

> > @@ -414,16 +440,16 @@ retry_transaction:
> >      if (rc)
> >          goto out;
> >
> > -    for (i = 0; i < ARRAY_SIZE(rw_paths); i++) {
> > -        char *path = libxl__sprintf(gc, "%s/%s", dom_path,
> rw_paths[i]);
> > -        xs_mkdir(ctx->xsh, t, path);
> > -        xs_set_permissions(ctx->xsh, t, path, rwperm,
> ARRAY_SIZE(rwperm));
> > -    }
> >      for (i = 0; i < ARRAY_SIZE(ro_paths); i++) {
> >          char *path = libxl__sprintf(gc, "%s/%s", dom_path,
> ro_paths[i]);
> >          xs_mkdir(ctx->xsh, t, path);
> >          xs_set_permissions(ctx->xsh, t, path, roperm,
> ARRAY_SIZE(roperm));
> >      }
> > +    for (i = 0; i < nr_rw_paths; i++) {
> > +        char *path = libxl__sprintf(gc, "%s/%s", dom_path,
> rw_paths[i]);
> > +        xs_mkdir(ctx->xsh, t, path);
> > +        xs_set_permissions(ctx->xsh, t, path, rwperm,
> ARRAY_SIZE(rwperm));
> > +    }
> 
> What does "xenstore-ls -fp" show before and after this re-ordering?
> 
> >      xs_write(ctx->xsh, t, libxl__sprintf(gc, "%s/uuid", vm_path),
> uuid_string, strlen(uuid_string));
> >      xs_write(ctx->xsh, t, libxl__sprintf(gc, "%s/name", vm_path),
> > info->name, strlen(info->name));
> 
> 
> > diff -r 03138a08366b -r 24fc8670dfca tools/libxl/libxl_dm.c
> > --- a/tools/libxl/libxl_dm.c    Fri Dec 09 16:19:36 2011 +0000
> > +++ b/tools/libxl/libxl_dm.c    Fri Dec 16 11:43:52 2011 +0000
> > @@ -821,9 +821,7 @@ int libxl__create_device_model(libxl__gc
> >          goto out;
> >      }
> >
> > -    path = libxl__sprintf(gc, "/local/domain/%d/hvmloader", info-
> >domid);
> > -    xs_mkdir(ctx->xsh, XBT_NULL, path);
> > -    libxl__xs_write(gc, XBT_NULL, libxl__sprintf(gc, "%s/bios",
> path),
> > +    libxl__xs_write(gc, XBT_NULL, libxl__sprintf(gc,
> > + "/local/domain/%d/hvmloader/bios", info->domid),
> >                      "%s", libxl__domain_bios(gc, info));
> >
> >      path = libxl__sprintf(gc, "/local/domain/0/device-model/%d",
> > info->domid);
> 
> Pre-existing problem but this should be libxl__xs_get_dompath.
> 
> Ian.
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 12:47:48 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 12:47:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbXC5-0005Kf-Uh; Fri, 16 Dec 2011 12:47:21 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RbXC4-0005KX-NP
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 12:47:20 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1324039630!7743271!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjU3OQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4284 invoked from network); 16 Dec 2011 12:47:14 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Dec 2011 12:47:14 -0000
X-IronPort-AV: E=Sophos;i="4.71,363,1320624000"; 
   d="scan'208";a="9513640"
Received: from lonpmailmx02.citrite.net ([10.30.203.163])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Dec 2011 12:47:10 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.161]) by
	LONPMAILMX02.citrite.net ([10.30.203.163]) with mapi; Fri, 16 Dec 2011
	12:47:10 +0000
From: Paul Durrant <Paul.Durrant@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Fri, 16 Dec 2011 12:47:09 +0000
Thread-Topic: [Xen-devel] [PATCH 1 of 3] Make ro_paths and rw_paths dynamic
Thread-Index: Acy76pX8rvc6bbJRRW2V1w+FuhNCywABhx7Q
Message-ID: <291EDFCB1E9E224A99088639C4762022B598ED0FE2@LONPMAILBOX01.citrite.net>
References: <patchbomb.1324036046@cosworth.uk.xensource.com>
	<24fc8670dfcaa9cbdfd8.1324036047@cosworth.uk.xensource.com>
	<1324036940.20077.593.camel@zakaz.uk.xensource.com>
In-Reply-To: <1324036940.20077.593.camel@zakaz.uk.xensource.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 1 of 3] Make ro_paths and rw_paths dynamic
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> -----Original Message-----
> From: Ian Campbell
> Sent: 16 December 2011 12:02
> To: Paul Durrant
> Cc: xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] [PATCH 1 of 3] Make ro_paths and rw_paths
> dynamic
> 
> On Fri, 2011-12-16 at 11:47 +0000, Paul Durrant wrote:
> > +    nr_ro_paths = 0;
> > +    if (info->type == LIBXL_DOMAIN_TYPE_HVM) {
> > +        ro_paths = libxl__calloc(gc, 5, sizeof(char *));
> > +        ro_paths[nr_ro_paths++] = "hvmloader";
> > +    } else {
> > +        ro_paths = libxl__calloc(gc, 4, sizeof(char *));
> > +    }
> > +
> > +    ro_paths[nr_ro_paths++] = "cpu";
> > +    ro_paths[nr_ro_paths++] = "memory";
> > +    ro_paths[nr_ro_paths++] = "device";
> > +    ro_paths[nr_ro_paths++] = "control";
> 
> The flexarray stuff allows you do to this sort of thing without
> worrying about running off the end of the allocated array etc.
> 
> Part of me thinks that if the arrays aren't static any more you
> might as well just do the create in an open coded list, instead of
> open coding the creation of a list and then iterating over it.
> 
> A helper function like libxl__xs_mkdir(gc, t, path, perm) would
> reduce the amount of boilerplate.
> 

Actually, yes, the helper function would be a much neater solution. I'll go for that.

  Paul

> > @@ -414,16 +440,16 @@ retry_transaction:
> >      if (rc)
> >          goto out;
> >
> > -    for (i = 0; i < ARRAY_SIZE(rw_paths); i++) {
> > -        char *path = libxl__sprintf(gc, "%s/%s", dom_path,
> rw_paths[i]);
> > -        xs_mkdir(ctx->xsh, t, path);
> > -        xs_set_permissions(ctx->xsh, t, path, rwperm,
> ARRAY_SIZE(rwperm));
> > -    }
> >      for (i = 0; i < ARRAY_SIZE(ro_paths); i++) {
> >          char *path = libxl__sprintf(gc, "%s/%s", dom_path,
> ro_paths[i]);
> >          xs_mkdir(ctx->xsh, t, path);
> >          xs_set_permissions(ctx->xsh, t, path, roperm,
> ARRAY_SIZE(roperm));
> >      }
> > +    for (i = 0; i < nr_rw_paths; i++) {
> > +        char *path = libxl__sprintf(gc, "%s/%s", dom_path,
> rw_paths[i]);
> > +        xs_mkdir(ctx->xsh, t, path);
> > +        xs_set_permissions(ctx->xsh, t, path, rwperm,
> ARRAY_SIZE(rwperm));
> > +    }
> 
> What does "xenstore-ls -fp" show before and after this re-ordering?
> 
> >      xs_write(ctx->xsh, t, libxl__sprintf(gc, "%s/uuid", vm_path),
> uuid_string, strlen(uuid_string));
> >      xs_write(ctx->xsh, t, libxl__sprintf(gc, "%s/name", vm_path),
> > info->name, strlen(info->name));
> 
> 
> > diff -r 03138a08366b -r 24fc8670dfca tools/libxl/libxl_dm.c
> > --- a/tools/libxl/libxl_dm.c    Fri Dec 09 16:19:36 2011 +0000
> > +++ b/tools/libxl/libxl_dm.c    Fri Dec 16 11:43:52 2011 +0000
> > @@ -821,9 +821,7 @@ int libxl__create_device_model(libxl__gc
> >          goto out;
> >      }
> >
> > -    path = libxl__sprintf(gc, "/local/domain/%d/hvmloader", info-
> >domid);
> > -    xs_mkdir(ctx->xsh, XBT_NULL, path);
> > -    libxl__xs_write(gc, XBT_NULL, libxl__sprintf(gc, "%s/bios",
> path),
> > +    libxl__xs_write(gc, XBT_NULL, libxl__sprintf(gc,
> > + "/local/domain/%d/hvmloader/bios", info->domid),
> >                      "%s", libxl__domain_bios(gc, info));
> >
> >      path = libxl__sprintf(gc, "/local/domain/0/device-model/%d",
> > info->domid);
> 
> Pre-existing problem but this should be libxl__xs_get_dompath.
> 
> Ian.
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 12:51:04 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 12:51:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbXFG-0005SZ-NG; Fri, 16 Dec 2011 12:50:38 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RbXFF-0005SO-ME
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 12:50:37 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1324039830!2243099!1
X-Originating-IP: [74.125.82.41]
X-SpamReason: No, hits=0.6 required=7.0 tests=MAILTO_TO_SPAM_ADDR, RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3795 invoked from network); 16 Dec 2011 12:50:30 -0000
Received: from mail-ww0-f41.google.com (HELO mail-ww0-f41.google.com)
	(74.125.82.41)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Dec 2011 12:50:30 -0000
Received: by wgbdt12 with SMTP id dt12so3533221wgb.0
	for <xen-devel@lists.xensource.com>;
	Fri, 16 Dec 2011 04:50:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:user-agent:date:from:to;
	bh=yROmtfxRPFg7bMAb+SiJRjZx+FfybdFOlcHHPl4gysw=;
	b=QuYj+GrruXO8sqGE4ELBFAdk5H8nyhFHr2Zmp29ZY6BFDiRrPpDbzwK8ZC+imfS8Qn
	nI4toWy3ekrWOirN6wflGh86SBumZywWPme2xOEqkX3SpCobX5KEDETLk4u28H6kgcjx
	3MOIHTfC8hj6GOkV28EuZehTsh2GvBTW9IvF4=
Received: by 10.180.107.97 with SMTP id hb1mr12202485wib.18.1324039830023;
	Fri, 16 Dec 2011 04:50:30 -0800 (PST)
Received: from alpine.localdomain (tina.upc.es. [147.83.39.243])
	by mx.google.com with ESMTPS id hq5sm12973451wib.7.2011.12.16.04.50.28
	(version=TLSv1/SSLv3 cipher=OTHER);
	Fri, 16 Dec 2011 04:50:28 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 8c0ce135cda382630adc72d64757ec64854ba696
Message-Id: <8c0ce135cda382630adc.1324039808@alpine.localdomain>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Fri, 16 Dec 2011 13:50:08 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH] ipxe: fix compilation issues with some gcc
	versions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1324039730 -3600
# Node ID 8c0ce135cda382630adc72d64757ec64854ba696
# Parent  b60667a56ae085ee2bcea896887d0907fb86af41
ipxe: fix compilation issues with some gcc versions

Backported some changes from current ipxe, to fix a issue with some
new versions of gcc that add -fPIC by default, and compilation fails
with the following error:

arch/i386/core/cpu.c: In function 'get_cpuinfo':
arch/i386/include/bits/cpu.h:79:2: error: inconsistent operand
constraints in an 'asm'
arch/i386/include/bits/cpu.h:79:2: error: inconsistent operand
constraints in an 'asm'
arch/i386/include/bits/cpu.h:79:2: error: inconsistent operand
constraints in an 'asm'
arch/i386/include/bits/cpu.h:79:2: error: inconsistent operand
constraints in an 'asm'

Two patches from ipxe git have been added. The problem is reproducible
with at least this version of gcc:

Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-alpine-linux-uclibc/4.6.2/lto-wrapper
Target: x86_64-alpine-linux-uclibc
Configured with:
/home/buildozer/aports/main/gcc/src/gcc-4.6.2/configure --prefix=/usr
--mandir=/usr/share/man --infodir=/usr/share/info
--build=x86_64-alpine-linux-uclibc --host=x86_64-alpine-linux-uclibc
--target=x86_64-alpine-linux-uclibc --with-pkgversion='Alpine
4.6.2-r1' --disable-altivec --disable-checking --disable-fixed-point
--disable-libssp --disable-libstdcxx-pch --disable-multilib
--disable-nls --disable-werror --enable-__cxa_atexit --enable-cld
--enable-esp --enable-cloog-backend
--enable-languages=c,c++,objc,java,go --enable-shared
--enable-target-optspace --enable-tls --enable-threads
--with-dynamic-linker=ld64-uClibc.so.0.9.32
--with-dynamic-linker-prefix=/lib --with-system-zlib
--without-system-libunwind
Thread model: posix
gcc version 4.6.2 (Alpine 4.6.2-r1)

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r b60667a56ae0 -r 8c0ce135cda3 tools/firmware/etherboot/patches/gpxe-git-b8924c1aed51
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/tools/firmware/etherboot/patches/gpxe-git-b8924c1aed51	Fri Dec 16 13:48:50 2011 +0100
@@ -0,0 +1,72 @@
+commit b8924c1aed512aa40cf28a43635df383880f771d
+Author: Michael Brown <mcb30@ipxe.org>
+Date:   Wed Mar 16 19:30:42 2011 +0000
+
+    [build] Allow workaround-specific flags to override default flags
+    
+    Signed-off-by: Michael Brown <mcb30@ipxe.org>
+
+diff --git a/src/Makefile.housekeeping b/src/Makefile.housekeeping
+index 709f8de..78e78c9 100644
+--- a/src/Makefile.housekeeping
++++ b/src/Makefile.housekeeping
+@@ -109,6 +109,10 @@ VERYCLEANUP	+= .toolcheck
+ # Check for various tool workarounds
+ #
+ 
++WORKAROUND_CFLAGS :=
++WORKAROUND_ASFLAGS :=
++WORKAROUND_LDFLAGS :=
++
+ # Make syntax does not allow use of comma or space in certain places.
+ # This ugly workaround is suggested in the manual.
+ #
+@@ -119,7 +123,7 @@ SPACE	:= $(EMPTY) $(EMPTY)
+ # Check for an old version of gas (binutils 2.9.1)
+ #
+ OLDGAS	:= $(shell $(AS) --version | grep -q '2\.9\.1' && $(ECHO) -DGAS291)
+-CFLAGS	+= $(OLDGAS)
++WORKAROUND_CFLAGS += $(OLDGAS)
+ oldgas :
+ 	@$(ECHO) $(oldgas)
+ 
+@@ -131,7 +135,7 @@ ifeq ($(CCTYPE),gcc)
+ SP_TEST = $(CC) -fno-stack-protector -x c -c /dev/null \
+ 		-o /dev/null >/dev/null 2>&1
+ SP_FLAGS := $(shell $(SP_TEST) && $(ECHO) '-fno-stack-protector')
+-CFLAGS	+= $(SP_FLAGS)
++WORKAROUND_CFLAGS += $(SP_FLAGS)
+ endif
+ 
+ # gcc 4.4 generates .eh_frame sections by default, which distort the
+@@ -141,7 +145,7 @@ ifeq ($(CCTYPE),gcc)
+ CFI_TEST = $(CC) -fno-dwarf2-cfi-asm -x c -c /dev/null \
+ 		 -o /dev/null >/dev/null 2>&1
+ CFI_FLAGS := $(shell $(CFI_TEST) && $(ECHO) '-fno-dwarf2-cfi-asm')
+-CFLAGS	+= $(CFI_FLAGS)
++WORKAROUND_CFLAGS += $(CFI_FLAGS)
+ endif
+ 
+ # Some versions of gas choke on division operators, treating them as
+@@ -150,7 +154,7 @@ endif
+ #
+ DIVIDE_TEST = $(AS) --divide /dev/null -o /dev/null 2>/dev/null
+ DIVIDE_FLAGS := $(shell $(DIVIDE_TEST) && $(ECHO) '--divide')
+-ASFLAGS	+= $(DIVIDE_FLAGS)
++WORKAROUND_ASFLAGS += $(DIVIDE_FLAGS)
+ 
+ ###############################################################################
+ #
+@@ -375,9 +379,9 @@ CFLAGS		+= -diag-disable 1419 # Missing prototypes
+ CFLAGS		+= -diag-disable 1599 # Hidden variables
+ CFLAGS		+= -Wall -Wmissing-declarations
+ endif
+-CFLAGS		+= $(EXTRA_CFLAGS)
+-ASFLAGS		+= $(EXTRA_ASFLAGS)
+-LDFLAGS		+= $(EXTRA_LDFLAGS)
++CFLAGS		+= $(WORKAROUND_CFLAGS) $(EXTRA_CFLAGS)
++ASFLAGS		+= $(WORKAROUND_ASFLAGS) $(EXTRA_ASFLAGS)
++LDFLAGS		+= $(WORKAROUND_LDFLAGS) $(EXTRA_LDFLAGS)
+ 
+ # Inhibit -Werror if NO_WERROR is specified on make command line
+ #
diff -r b60667a56ae0 -r 8c0ce135cda3 tools/firmware/etherboot/patches/gpxe-git-fe61f6de0dd5
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/tools/firmware/etherboot/patches/gpxe-git-fe61f6de0dd5	Fri Dec 16 13:48:50 2011 +0100
@@ -0,0 +1,32 @@
+commit fe61f6de0dd5d39ac3de5e8e18742f9bd0aafad7
+Author: Gilles Espinasse <g.esp@free.fr>
+Date:   Tue Mar 29 15:30:11 2011 +0100
+
+    [build] Fix compilation when gcc is patched to default to -fPIE -Wl,-pie
+    
+    Signed-off-by: Gilles Espinasse <g.esp@free.fr>
+    Modified-by: Michael Brown <mcb30@ipxe.org>
+    Signed-off-by: Michael Brown <mcb30@ipxe.org>
+
+diff --git a/src/Makefile.housekeeping b/src/Makefile.housekeeping
+index 57e52c0..c184351 100644
+--- a/src/Makefile.housekeeping
++++ b/src/Makefile.housekeeping
+@@ -138,6 +138,17 @@ SP_FLAGS := $(shell $(SP_TEST) && $(ECHO) '-fno-stack-protector')
+ WORKAROUND_CFLAGS += $(SP_FLAGS)
+ endif
+ 
++# Some widespread patched versions of gcc include -fPIE -Wl,-pie by
++# default.  Note that gcc will exit *successfully* if it fails to
++# recognise an option that starts with "no", so we have to test for
++# output on stderr instead of checking the exit status.
++#
++ifeq ($(CCTYPE),gcc)
++PIE_TEST = [ -z "`$(CC) -fno-PIE -nopie -x c -c /dev/null -o /dev/null 2>&1`" ]
++PIE_FLAGS := $(shell $(PIE_TEST) && $(ECHO) '-fno-PIE -nopie')
++WORKAROUND_CFLAGS += $(PIE_FLAGS)
++endif
++
+ # gcc 4.4 generates .eh_frame sections by default, which distort the
+ # output of "size".  Inhibit this.
+ #
diff -r b60667a56ae0 -r 8c0ce135cda3 tools/firmware/etherboot/patches/series
--- a/tools/firmware/etherboot/patches/series	Fri Dec 16 10:47:18 2011 +0100
+++ b/tools/firmware/etherboot/patches/series	Fri Dec 16 13:48:50 2011 +0100
@@ -1,3 +1,5 @@
 boot_prompt_option.patch
 gpxe-git-0edf2405b457
 gpxe-git-a803ef3dfeac
+gpxe-git-b8924c1aed51
+gpxe-git-fe61f6de0dd5

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 12:51:04 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 12:51:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbXFG-0005SZ-NG; Fri, 16 Dec 2011 12:50:38 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RbXFF-0005SO-ME
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 12:50:37 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1324039830!2243099!1
X-Originating-IP: [74.125.82.41]
X-SpamReason: No, hits=0.6 required=7.0 tests=MAILTO_TO_SPAM_ADDR, RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3795 invoked from network); 16 Dec 2011 12:50:30 -0000
Received: from mail-ww0-f41.google.com (HELO mail-ww0-f41.google.com)
	(74.125.82.41)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Dec 2011 12:50:30 -0000
Received: by wgbdt12 with SMTP id dt12so3533221wgb.0
	for <xen-devel@lists.xensource.com>;
	Fri, 16 Dec 2011 04:50:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:user-agent:date:from:to;
	bh=yROmtfxRPFg7bMAb+SiJRjZx+FfybdFOlcHHPl4gysw=;
	b=QuYj+GrruXO8sqGE4ELBFAdk5H8nyhFHr2Zmp29ZY6BFDiRrPpDbzwK8ZC+imfS8Qn
	nI4toWy3ekrWOirN6wflGh86SBumZywWPme2xOEqkX3SpCobX5KEDETLk4u28H6kgcjx
	3MOIHTfC8hj6GOkV28EuZehTsh2GvBTW9IvF4=
Received: by 10.180.107.97 with SMTP id hb1mr12202485wib.18.1324039830023;
	Fri, 16 Dec 2011 04:50:30 -0800 (PST)
Received: from alpine.localdomain (tina.upc.es. [147.83.39.243])
	by mx.google.com with ESMTPS id hq5sm12973451wib.7.2011.12.16.04.50.28
	(version=TLSv1/SSLv3 cipher=OTHER);
	Fri, 16 Dec 2011 04:50:28 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 8c0ce135cda382630adc72d64757ec64854ba696
Message-Id: <8c0ce135cda382630adc.1324039808@alpine.localdomain>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Fri, 16 Dec 2011 13:50:08 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH] ipxe: fix compilation issues with some gcc
	versions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1324039730 -3600
# Node ID 8c0ce135cda382630adc72d64757ec64854ba696
# Parent  b60667a56ae085ee2bcea896887d0907fb86af41
ipxe: fix compilation issues with some gcc versions

Backported some changes from current ipxe, to fix a issue with some
new versions of gcc that add -fPIC by default, and compilation fails
with the following error:

arch/i386/core/cpu.c: In function 'get_cpuinfo':
arch/i386/include/bits/cpu.h:79:2: error: inconsistent operand
constraints in an 'asm'
arch/i386/include/bits/cpu.h:79:2: error: inconsistent operand
constraints in an 'asm'
arch/i386/include/bits/cpu.h:79:2: error: inconsistent operand
constraints in an 'asm'
arch/i386/include/bits/cpu.h:79:2: error: inconsistent operand
constraints in an 'asm'

Two patches from ipxe git have been added. The problem is reproducible
with at least this version of gcc:

Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-alpine-linux-uclibc/4.6.2/lto-wrapper
Target: x86_64-alpine-linux-uclibc
Configured with:
/home/buildozer/aports/main/gcc/src/gcc-4.6.2/configure --prefix=/usr
--mandir=/usr/share/man --infodir=/usr/share/info
--build=x86_64-alpine-linux-uclibc --host=x86_64-alpine-linux-uclibc
--target=x86_64-alpine-linux-uclibc --with-pkgversion='Alpine
4.6.2-r1' --disable-altivec --disable-checking --disable-fixed-point
--disable-libssp --disable-libstdcxx-pch --disable-multilib
--disable-nls --disable-werror --enable-__cxa_atexit --enable-cld
--enable-esp --enable-cloog-backend
--enable-languages=c,c++,objc,java,go --enable-shared
--enable-target-optspace --enable-tls --enable-threads
--with-dynamic-linker=ld64-uClibc.so.0.9.32
--with-dynamic-linker-prefix=/lib --with-system-zlib
--without-system-libunwind
Thread model: posix
gcc version 4.6.2 (Alpine 4.6.2-r1)

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r b60667a56ae0 -r 8c0ce135cda3 tools/firmware/etherboot/patches/gpxe-git-b8924c1aed51
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/tools/firmware/etherboot/patches/gpxe-git-b8924c1aed51	Fri Dec 16 13:48:50 2011 +0100
@@ -0,0 +1,72 @@
+commit b8924c1aed512aa40cf28a43635df383880f771d
+Author: Michael Brown <mcb30@ipxe.org>
+Date:   Wed Mar 16 19:30:42 2011 +0000
+
+    [build] Allow workaround-specific flags to override default flags
+    
+    Signed-off-by: Michael Brown <mcb30@ipxe.org>
+
+diff --git a/src/Makefile.housekeeping b/src/Makefile.housekeeping
+index 709f8de..78e78c9 100644
+--- a/src/Makefile.housekeeping
++++ b/src/Makefile.housekeeping
+@@ -109,6 +109,10 @@ VERYCLEANUP	+= .toolcheck
+ # Check for various tool workarounds
+ #
+ 
++WORKAROUND_CFLAGS :=
++WORKAROUND_ASFLAGS :=
++WORKAROUND_LDFLAGS :=
++
+ # Make syntax does not allow use of comma or space in certain places.
+ # This ugly workaround is suggested in the manual.
+ #
+@@ -119,7 +123,7 @@ SPACE	:= $(EMPTY) $(EMPTY)
+ # Check for an old version of gas (binutils 2.9.1)
+ #
+ OLDGAS	:= $(shell $(AS) --version | grep -q '2\.9\.1' && $(ECHO) -DGAS291)
+-CFLAGS	+= $(OLDGAS)
++WORKAROUND_CFLAGS += $(OLDGAS)
+ oldgas :
+ 	@$(ECHO) $(oldgas)
+ 
+@@ -131,7 +135,7 @@ ifeq ($(CCTYPE),gcc)
+ SP_TEST = $(CC) -fno-stack-protector -x c -c /dev/null \
+ 		-o /dev/null >/dev/null 2>&1
+ SP_FLAGS := $(shell $(SP_TEST) && $(ECHO) '-fno-stack-protector')
+-CFLAGS	+= $(SP_FLAGS)
++WORKAROUND_CFLAGS += $(SP_FLAGS)
+ endif
+ 
+ # gcc 4.4 generates .eh_frame sections by default, which distort the
+@@ -141,7 +145,7 @@ ifeq ($(CCTYPE),gcc)
+ CFI_TEST = $(CC) -fno-dwarf2-cfi-asm -x c -c /dev/null \
+ 		 -o /dev/null >/dev/null 2>&1
+ CFI_FLAGS := $(shell $(CFI_TEST) && $(ECHO) '-fno-dwarf2-cfi-asm')
+-CFLAGS	+= $(CFI_FLAGS)
++WORKAROUND_CFLAGS += $(CFI_FLAGS)
+ endif
+ 
+ # Some versions of gas choke on division operators, treating them as
+@@ -150,7 +154,7 @@ endif
+ #
+ DIVIDE_TEST = $(AS) --divide /dev/null -o /dev/null 2>/dev/null
+ DIVIDE_FLAGS := $(shell $(DIVIDE_TEST) && $(ECHO) '--divide')
+-ASFLAGS	+= $(DIVIDE_FLAGS)
++WORKAROUND_ASFLAGS += $(DIVIDE_FLAGS)
+ 
+ ###############################################################################
+ #
+@@ -375,9 +379,9 @@ CFLAGS		+= -diag-disable 1419 # Missing prototypes
+ CFLAGS		+= -diag-disable 1599 # Hidden variables
+ CFLAGS		+= -Wall -Wmissing-declarations
+ endif
+-CFLAGS		+= $(EXTRA_CFLAGS)
+-ASFLAGS		+= $(EXTRA_ASFLAGS)
+-LDFLAGS		+= $(EXTRA_LDFLAGS)
++CFLAGS		+= $(WORKAROUND_CFLAGS) $(EXTRA_CFLAGS)
++ASFLAGS		+= $(WORKAROUND_ASFLAGS) $(EXTRA_ASFLAGS)
++LDFLAGS		+= $(WORKAROUND_LDFLAGS) $(EXTRA_LDFLAGS)
+ 
+ # Inhibit -Werror if NO_WERROR is specified on make command line
+ #
diff -r b60667a56ae0 -r 8c0ce135cda3 tools/firmware/etherboot/patches/gpxe-git-fe61f6de0dd5
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/tools/firmware/etherboot/patches/gpxe-git-fe61f6de0dd5	Fri Dec 16 13:48:50 2011 +0100
@@ -0,0 +1,32 @@
+commit fe61f6de0dd5d39ac3de5e8e18742f9bd0aafad7
+Author: Gilles Espinasse <g.esp@free.fr>
+Date:   Tue Mar 29 15:30:11 2011 +0100
+
+    [build] Fix compilation when gcc is patched to default to -fPIE -Wl,-pie
+    
+    Signed-off-by: Gilles Espinasse <g.esp@free.fr>
+    Modified-by: Michael Brown <mcb30@ipxe.org>
+    Signed-off-by: Michael Brown <mcb30@ipxe.org>
+
+diff --git a/src/Makefile.housekeeping b/src/Makefile.housekeeping
+index 57e52c0..c184351 100644
+--- a/src/Makefile.housekeeping
++++ b/src/Makefile.housekeeping
+@@ -138,6 +138,17 @@ SP_FLAGS := $(shell $(SP_TEST) && $(ECHO) '-fno-stack-protector')
+ WORKAROUND_CFLAGS += $(SP_FLAGS)
+ endif
+ 
++# Some widespread patched versions of gcc include -fPIE -Wl,-pie by
++# default.  Note that gcc will exit *successfully* if it fails to
++# recognise an option that starts with "no", so we have to test for
++# output on stderr instead of checking the exit status.
++#
++ifeq ($(CCTYPE),gcc)
++PIE_TEST = [ -z "`$(CC) -fno-PIE -nopie -x c -c /dev/null -o /dev/null 2>&1`" ]
++PIE_FLAGS := $(shell $(PIE_TEST) && $(ECHO) '-fno-PIE -nopie')
++WORKAROUND_CFLAGS += $(PIE_FLAGS)
++endif
++
+ # gcc 4.4 generates .eh_frame sections by default, which distort the
+ # output of "size".  Inhibit this.
+ #
diff -r b60667a56ae0 -r 8c0ce135cda3 tools/firmware/etherboot/patches/series
--- a/tools/firmware/etherboot/patches/series	Fri Dec 16 10:47:18 2011 +0100
+++ b/tools/firmware/etherboot/patches/series	Fri Dec 16 13:48:50 2011 +0100
@@ -1,3 +1,5 @@
 boot_prompt_option.patch
 gpxe-git-0edf2405b457
 gpxe-git-a803ef3dfeac
+gpxe-git-b8924c1aed51
+gpxe-git-fe61f6de0dd5

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 12:52:38 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 12:52:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbXGh-0005Xa-6q; Fri, 16 Dec 2011 12:52:07 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RbXGg-0005X9-3P
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 12:52:06 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1324039920!7697181!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjU3OQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4550 invoked from network); 16 Dec 2011 12:52:00 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Dec 2011 12:52:00 -0000
X-IronPort-AV: E=Sophos;i="4.71,363,1320624000"; 
   d="scan'208";a="9513775"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Dec 2011 12:52:00 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.161]) by
	LONPMAILMX01.citrite.net ([10.30.203.162]) with mapi; Fri, 16 Dec 2011
	12:52:00 +0000
From: Paul Durrant <Paul.Durrant@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Fri, 16 Dec 2011 12:51:59 +0000
Thread-Topic: [Xen-devel] [PATCH 3 of 3] VM generation ID save/restore and
	migrate
Thread-Index: Acy761MNg9LtbgR0QH2azxaN2Awp4wABcltA
Message-ID: <291EDFCB1E9E224A99088639C4762022B598ED0FE5@LONPMAILBOX01.citrite.net>
References: <patchbomb.1324036046@cosworth.uk.xensource.com>
	<e745cfbe7e114cb8a8c3.1324036049@cosworth.uk.xensource.com>
	<1324037266.20077.596.camel@zakaz.uk.xensource.com>
In-Reply-To: <1324037266.20077.596.camel@zakaz.uk.xensource.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 3 of 3] VM generation ID save/restore and
 migrate
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> -----Original Message-----
> From: Ian Campbell
> Sent: 16 December 2011 12:08
> To: Paul Durrant
> Cc: xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] [PATCH 3 of 3] VM generation ID
> save/restore and migrate
> 
> On Fri, 2011-12-16 at 11:47 +0000, Paul Durrant wrote:
> > diff -r d44e885e0389 -r e745cfbe7e11
> tools/python/xen/lowlevel/checkpoint/libcheckpoint.c
> > --- a/tools/python/xen/lowlevel/checkpoint/libcheckpoint.c
> Fri Dec 16 11:43:52 2011 +0000
> > +++ b/tools/python/xen/lowlevel/checkpoint/libcheckpoint.c
> Fri Dec 16 11:43:53 2011 +0000
> > @@ -175,6 +175,7 @@ int checkpoint_start(checkpoint_state* s  {
> >      int hvm, rc;
> >      int flags = XCFLAGS_LIVE;
> > +    unsigned long vm_generationid_addr;
> >
> >      if (!s->domid) {
> >         s->errstr = "checkpoint state not opened"; @@ -185,16
> +186,28
> > @@ int checkpoint_start(checkpoint_state* s
> >
> >      hvm = s->domtype > dt_pv;
> >      if (hvm) {
> > +       char path[128];
> > +       char *addr;
> > +
> > +       sprintf(path,
> > + "/local/domain/%u/hvmloader/generation-id-address", s->domid);
> 
> xs_get_domain_path() gives you the correct base path (I saw at least
> one more of these).
> 

Does that save me anything? I'd end up having to

sprintf(path, "%s/hvmloader/generation-id-address", xs_get_domain_path(s->xsh, s->domid))

since xs_read() just takes a path rather than a (prefix, node) couple.

  Paul

> > diff -r d44e885e0389 -r e745cfbe7e11 tools/xcutils/xc_restore.c
> > --- a/tools/xcutils/xc_restore.c        Fri Dec 16 11:43:52 2011
> +0000
> > +++ b/tools/xcutils/xc_restore.c        Fri Dec 16 11:43:53 2011
> +0000
> [...]
> > diff -r d44e885e0389 -r e745cfbe7e11 tools/xcutils/xc_save.c
> > --- a/tools/xcutils/xc_save.c   Fri Dec 16 11:43:52 2011 +0000
> > +++ b/tools/xcutils/xc_save.c   Fri Dec 16 11:43:53 2011 +0000
> [...]
> 
> AFAIK these two are only used by xend so unless you are adding
> support for this stuff there (it's deprecated so no need) this isn't
> necessary, also I think xend reads the stdout of one or both and
> you've added to what gets printed, running the risk of breaking
> things.
> 
> Ian.
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 12:52:38 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 12:52:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbXGh-0005Xa-6q; Fri, 16 Dec 2011 12:52:07 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RbXGg-0005X9-3P
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 12:52:06 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1324039920!7697181!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjU3OQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4550 invoked from network); 16 Dec 2011 12:52:00 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Dec 2011 12:52:00 -0000
X-IronPort-AV: E=Sophos;i="4.71,363,1320624000"; 
   d="scan'208";a="9513775"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Dec 2011 12:52:00 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.161]) by
	LONPMAILMX01.citrite.net ([10.30.203.162]) with mapi; Fri, 16 Dec 2011
	12:52:00 +0000
From: Paul Durrant <Paul.Durrant@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Fri, 16 Dec 2011 12:51:59 +0000
Thread-Topic: [Xen-devel] [PATCH 3 of 3] VM generation ID save/restore and
	migrate
Thread-Index: Acy761MNg9LtbgR0QH2azxaN2Awp4wABcltA
Message-ID: <291EDFCB1E9E224A99088639C4762022B598ED0FE5@LONPMAILBOX01.citrite.net>
References: <patchbomb.1324036046@cosworth.uk.xensource.com>
	<e745cfbe7e114cb8a8c3.1324036049@cosworth.uk.xensource.com>
	<1324037266.20077.596.camel@zakaz.uk.xensource.com>
In-Reply-To: <1324037266.20077.596.camel@zakaz.uk.xensource.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 3 of 3] VM generation ID save/restore and
 migrate
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> -----Original Message-----
> From: Ian Campbell
> Sent: 16 December 2011 12:08
> To: Paul Durrant
> Cc: xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] [PATCH 3 of 3] VM generation ID
> save/restore and migrate
> 
> On Fri, 2011-12-16 at 11:47 +0000, Paul Durrant wrote:
> > diff -r d44e885e0389 -r e745cfbe7e11
> tools/python/xen/lowlevel/checkpoint/libcheckpoint.c
> > --- a/tools/python/xen/lowlevel/checkpoint/libcheckpoint.c
> Fri Dec 16 11:43:52 2011 +0000
> > +++ b/tools/python/xen/lowlevel/checkpoint/libcheckpoint.c
> Fri Dec 16 11:43:53 2011 +0000
> > @@ -175,6 +175,7 @@ int checkpoint_start(checkpoint_state* s  {
> >      int hvm, rc;
> >      int flags = XCFLAGS_LIVE;
> > +    unsigned long vm_generationid_addr;
> >
> >      if (!s->domid) {
> >         s->errstr = "checkpoint state not opened"; @@ -185,16
> +186,28
> > @@ int checkpoint_start(checkpoint_state* s
> >
> >      hvm = s->domtype > dt_pv;
> >      if (hvm) {
> > +       char path[128];
> > +       char *addr;
> > +
> > +       sprintf(path,
> > + "/local/domain/%u/hvmloader/generation-id-address", s->domid);
> 
> xs_get_domain_path() gives you the correct base path (I saw at least
> one more of these).
> 

Does that save me anything? I'd end up having to

sprintf(path, "%s/hvmloader/generation-id-address", xs_get_domain_path(s->xsh, s->domid))

since xs_read() just takes a path rather than a (prefix, node) couple.

  Paul

> > diff -r d44e885e0389 -r e745cfbe7e11 tools/xcutils/xc_restore.c
> > --- a/tools/xcutils/xc_restore.c        Fri Dec 16 11:43:52 2011
> +0000
> > +++ b/tools/xcutils/xc_restore.c        Fri Dec 16 11:43:53 2011
> +0000
> [...]
> > diff -r d44e885e0389 -r e745cfbe7e11 tools/xcutils/xc_save.c
> > --- a/tools/xcutils/xc_save.c   Fri Dec 16 11:43:52 2011 +0000
> > +++ b/tools/xcutils/xc_save.c   Fri Dec 16 11:43:53 2011 +0000
> [...]
> 
> AFAIK these two are only used by xend so unless you are adding
> support for this stuff there (it's deprecated so no need) this isn't
> necessary, also I think xend reads the stdout of one or both and
> you've added to what gets printed, running the risk of breaking
> things.
> 
> Ian.
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 12:59:46 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 12:59:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbXNl-0005pS-6Q; Fri, 16 Dec 2011 12:59:25 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RbXNj-0005pE-5M
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 12:59:23 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1324040356!2219181!1
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.6 required=7.0 tests=MAILTO_TO_SPAM_ADDR,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10379 invoked from network); 16 Dec 2011 12:59:16 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Dec 2011 12:59:16 -0000
Received: by wgbds11 with SMTP id ds11so5201679wgb.24
	for <xen-devel@lists.xensource.com>;
	Fri, 16 Dec 2011 04:59:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=rqY9Kz+nSYc3ryHhw14+nYPX3JCUzMgTgVGw9rWTHyE=;
	b=iz0PmmkZqlLtO9mknQJTS0Mq+SZAzR0jgEVzVwpc7hyWsu9SarkDV90Lhfir6Iulz3
	iZ28gaj1b6a3EnxAjYgSB9kstW6UPULonLk893iD7Evjpc7a1Q7//ZA6GvBxSxw060Nr
	NPoksokuQx9ReSSRGpe0ktsvw5xcU16iq6gac=
Received: by 10.180.19.135 with SMTP id f7mr1868940wie.21.1324040356546;
	Fri, 16 Dec 2011 04:59:16 -0800 (PST)
Received: from [192.168.1.70] (host81-152-17-11.range81-152.btcentralplus.com.
	[81.152.17.11]) by mx.google.com with ESMTPS id
	bl10sm12983823wib.15.2011.12.16.04.59.12
	(version=SSLv3 cipher=OTHER); Fri, 16 Dec 2011 04:59:15 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Fri, 16 Dec 2011 12:59:10 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Roger Pau Monne <roger.pau@entel.upc.edu>, <xen-devel@lists.xensource.com>
Message-ID: <CB10F11E.27664%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH] ipxe: fix compilation issues with some gcc
	versions
Thread-Index: Acy78oCLOKqhbAQjD0KZeXiHTjEmDg==
In-Reply-To: <8c0ce135cda382630adc.1324039808@alpine.localdomain>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH] ipxe: fix compilation issues with some gcc
 versions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 16/12/2011 12:50, "Roger Pau Monne" <roger.pau@entel.upc.edu> wrote:

> # HG changeset patch
> # User Roger Pau Monne <roger.pau@entel.upc.edu>
> # Date 1324039730 -3600
> # Node ID 8c0ce135cda382630adc72d64757ec64854ba696
> # Parent  b60667a56ae085ee2bcea896887d0907fb86af41
> ipxe: fix compilation issues with some gcc versions
> 
> Backported some changes from current ipxe, to fix a issue with some
> new versions of gcc that add -fPIC by default, and compilation fails
> with the following error:

Is there a newer release tag on the ipxe repo that we could build instead,
that would automatically get us these fixes?

 -- Keir

> arch/i386/core/cpu.c: In function 'get_cpuinfo':
> arch/i386/include/bits/cpu.h:79:2: error: inconsistent operand
> constraints in an 'asm'
> arch/i386/include/bits/cpu.h:79:2: error: inconsistent operand
> constraints in an 'asm'
> arch/i386/include/bits/cpu.h:79:2: error: inconsistent operand
> constraints in an 'asm'
> arch/i386/include/bits/cpu.h:79:2: error: inconsistent operand
> constraints in an 'asm'
> 
> Two patches from ipxe git have been added. The problem is reproducible
> with at least this version of gcc:
> 
> Using built-in specs.
> COLLECT_GCC=gcc
> COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-alpine-linux-uclibc/4.6.2/lto-wrap
> per
> Target: x86_64-alpine-linux-uclibc
> Configured with:
> /home/buildozer/aports/main/gcc/src/gcc-4.6.2/configure --prefix=/usr
> --mandir=/usr/share/man --infodir=/usr/share/info
> --build=x86_64-alpine-linux-uclibc --host=x86_64-alpine-linux-uclibc
> --target=x86_64-alpine-linux-uclibc --with-pkgversion='Alpine
> 4.6.2-r1' --disable-altivec --disable-checking --disable-fixed-point
> --disable-libssp --disable-libstdcxx-pch --disable-multilib
> --disable-nls --disable-werror --enable-__cxa_atexit --enable-cld
> --enable-esp --enable-cloog-backend
> --enable-languages=c,c++,objc,java,go --enable-shared
> --enable-target-optspace --enable-tls --enable-threads
> --with-dynamic-linker=ld64-uClibc.so.0.9.32
> --with-dynamic-linker-prefix=/lib --with-system-zlib
> --without-system-libunwind
> Thread model: posix
> gcc version 4.6.2 (Alpine 4.6.2-r1)
> 
> Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>
> 
> diff -r b60667a56ae0 -r 8c0ce135cda3
> tools/firmware/etherboot/patches/gpxe-git-b8924c1aed51
> --- /dev/null Thu Jan 01 00:00:00 1970 +0000
> +++ b/tools/firmware/etherboot/patches/gpxe-git-b8924c1aed51 Fri Dec 16
> 13:48:50 2011 +0100
> @@ -0,0 +1,72 @@
> +commit b8924c1aed512aa40cf28a43635df383880f771d
> +Author: Michael Brown <mcb30@ipxe.org>
> +Date:   Wed Mar 16 19:30:42 2011 +0000
> +
> +    [build] Allow workaround-specific flags to override default flags
> +    
> +    Signed-off-by: Michael Brown <mcb30@ipxe.org>
> +
> +diff --git a/src/Makefile.housekeeping b/src/Makefile.housekeeping
> +index 709f8de..78e78c9 100644
> +--- a/src/Makefile.housekeeping
> ++++ b/src/Makefile.housekeeping
> +@@ -109,6 +109,10 @@ VERYCLEANUP += .toolcheck
> + # Check for various tool workarounds
> + #
> + 
> ++WORKAROUND_CFLAGS :=
> ++WORKAROUND_ASFLAGS :=
> ++WORKAROUND_LDFLAGS :=
> ++
> + # Make syntax does not allow use of comma or space in certain places.
> + # This ugly workaround is suggested in the manual.
> + #
> +@@ -119,7 +123,7 @@ SPACE := $(EMPTY) $(EMPTY)
> + # Check for an old version of gas (binutils 2.9.1)
> + #
> + OLDGAS := $(shell $(AS) --version | grep -q '2\.9\.1' && $(ECHO) -DGAS291)
> +-CFLAGS += $(OLDGAS)
> ++WORKAROUND_CFLAGS += $(OLDGAS)
> + oldgas :
> +  @$(ECHO) $(oldgas)
> + 
> +@@ -131,7 +135,7 @@ ifeq ($(CCTYPE),gcc)
> + SP_TEST = $(CC) -fno-stack-protector -x c -c /dev/null \
> +   -o /dev/null >/dev/null 2>&1
> + SP_FLAGS := $(shell $(SP_TEST) && $(ECHO) '-fno-stack-protector')
> +-CFLAGS += $(SP_FLAGS)
> ++WORKAROUND_CFLAGS += $(SP_FLAGS)
> + endif
> + 
> + # gcc 4.4 generates .eh_frame sections by default, which distort the
> +@@ -141,7 +145,7 @@ ifeq ($(CCTYPE),gcc)
> + CFI_TEST = $(CC) -fno-dwarf2-cfi-asm -x c -c /dev/null \
> +    -o /dev/null >/dev/null 2>&1
> + CFI_FLAGS := $(shell $(CFI_TEST) && $(ECHO) '-fno-dwarf2-cfi-asm')
> +-CFLAGS += $(CFI_FLAGS)
> ++WORKAROUND_CFLAGS += $(CFI_FLAGS)
> + endif
> + 
> + # Some versions of gas choke on division operators, treating them as
> +@@ -150,7 +154,7 @@ endif
> + #
> + DIVIDE_TEST = $(AS) --divide /dev/null -o /dev/null 2>/dev/null
> + DIVIDE_FLAGS := $(shell $(DIVIDE_TEST) && $(ECHO) '--divide')
> +-ASFLAGS += $(DIVIDE_FLAGS)
> ++WORKAROUND_ASFLAGS += $(DIVIDE_FLAGS)
> + 
> + 
> 
##############################################################################>
#
> + #
> +@@ -375,9 +379,9 @@ CFLAGS  += -diag-disable 1419 # Missing prototypes
> + CFLAGS  += -diag-disable 1599 # Hidden variables
> + CFLAGS  += -Wall -Wmissing-declarations
> + endif
> +-CFLAGS  += $(EXTRA_CFLAGS)
> +-ASFLAGS  += $(EXTRA_ASFLAGS)
> +-LDFLAGS  += $(EXTRA_LDFLAGS)
> ++CFLAGS  += $(WORKAROUND_CFLAGS) $(EXTRA_CFLAGS)
> ++ASFLAGS  += $(WORKAROUND_ASFLAGS) $(EXTRA_ASFLAGS)
> ++LDFLAGS  += $(WORKAROUND_LDFLAGS) $(EXTRA_LDFLAGS)
> + 
> + # Inhibit -Werror if NO_WERROR is specified on make command line
> + #
> diff -r b60667a56ae0 -r 8c0ce135cda3
> tools/firmware/etherboot/patches/gpxe-git-fe61f6de0dd5
> --- /dev/null Thu Jan 01 00:00:00 1970 +0000
> +++ b/tools/firmware/etherboot/patches/gpxe-git-fe61f6de0dd5 Fri Dec 16
> 13:48:50 2011 +0100
> @@ -0,0 +1,32 @@
> +commit fe61f6de0dd5d39ac3de5e8e18742f9bd0aafad7
> +Author: Gilles Espinasse <g.esp@free.fr>
> +Date:   Tue Mar 29 15:30:11 2011 +0100
> +
> +    [build] Fix compilation when gcc is patched to default to -fPIE -Wl,-pie
> +    
> +    Signed-off-by: Gilles Espinasse <g.esp@free.fr>
> +    Modified-by: Michael Brown <mcb30@ipxe.org>
> +    Signed-off-by: Michael Brown <mcb30@ipxe.org>
> +
> +diff --git a/src/Makefile.housekeeping b/src/Makefile.housekeeping
> +index 57e52c0..c184351 100644
> +--- a/src/Makefile.housekeeping
> ++++ b/src/Makefile.housekeeping
> +@@ -138,6 +138,17 @@ SP_FLAGS := $(shell $(SP_TEST) && $(ECHO)
> '-fno-stack-protector')
> + WORKAROUND_CFLAGS += $(SP_FLAGS)
> + endif
> + 
> ++# Some widespread patched versions of gcc include -fPIE -Wl,-pie by
> ++# default.  Note that gcc will exit *successfully* if it fails to
> ++# recognise an option that starts with "no", so we have to test for
> ++# output on stderr instead of checking the exit status.
> ++#
> ++ifeq ($(CCTYPE),gcc)
> ++PIE_TEST = [ -z "`$(CC) -fno-PIE -nopie -x c -c /dev/null -o /dev/null
> 2>&1`" ]
> ++PIE_FLAGS := $(shell $(PIE_TEST) && $(ECHO) '-fno-PIE -nopie')
> ++WORKAROUND_CFLAGS += $(PIE_FLAGS)
> ++endif
> ++
> + # gcc 4.4 generates .eh_frame sections by default, which distort the
> + # output of "size".  Inhibit this.
> + #
> diff -r b60667a56ae0 -r 8c0ce135cda3 tools/firmware/etherboot/patches/series
> --- a/tools/firmware/etherboot/patches/series Fri Dec 16 10:47:18 2011 +0100
> +++ b/tools/firmware/etherboot/patches/series Fri Dec 16 13:48:50 2011 +0100
> @@ -1,3 +1,5 @@
>  boot_prompt_option.patch
>  gpxe-git-0edf2405b457
>  gpxe-git-a803ef3dfeac
> +gpxe-git-b8924c1aed51
> +gpxe-git-fe61f6de0dd5
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 12:59:46 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 12:59:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbXNl-0005pS-6Q; Fri, 16 Dec 2011 12:59:25 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RbXNj-0005pE-5M
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 12:59:23 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1324040356!2219181!1
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.6 required=7.0 tests=MAILTO_TO_SPAM_ADDR,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10379 invoked from network); 16 Dec 2011 12:59:16 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Dec 2011 12:59:16 -0000
Received: by wgbds11 with SMTP id ds11so5201679wgb.24
	for <xen-devel@lists.xensource.com>;
	Fri, 16 Dec 2011 04:59:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=rqY9Kz+nSYc3ryHhw14+nYPX3JCUzMgTgVGw9rWTHyE=;
	b=iz0PmmkZqlLtO9mknQJTS0Mq+SZAzR0jgEVzVwpc7hyWsu9SarkDV90Lhfir6Iulz3
	iZ28gaj1b6a3EnxAjYgSB9kstW6UPULonLk893iD7Evjpc7a1Q7//ZA6GvBxSxw060Nr
	NPoksokuQx9ReSSRGpe0ktsvw5xcU16iq6gac=
Received: by 10.180.19.135 with SMTP id f7mr1868940wie.21.1324040356546;
	Fri, 16 Dec 2011 04:59:16 -0800 (PST)
Received: from [192.168.1.70] (host81-152-17-11.range81-152.btcentralplus.com.
	[81.152.17.11]) by mx.google.com with ESMTPS id
	bl10sm12983823wib.15.2011.12.16.04.59.12
	(version=SSLv3 cipher=OTHER); Fri, 16 Dec 2011 04:59:15 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Fri, 16 Dec 2011 12:59:10 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Roger Pau Monne <roger.pau@entel.upc.edu>, <xen-devel@lists.xensource.com>
Message-ID: <CB10F11E.27664%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH] ipxe: fix compilation issues with some gcc
	versions
Thread-Index: Acy78oCLOKqhbAQjD0KZeXiHTjEmDg==
In-Reply-To: <8c0ce135cda382630adc.1324039808@alpine.localdomain>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH] ipxe: fix compilation issues with some gcc
 versions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 16/12/2011 12:50, "Roger Pau Monne" <roger.pau@entel.upc.edu> wrote:

> # HG changeset patch
> # User Roger Pau Monne <roger.pau@entel.upc.edu>
> # Date 1324039730 -3600
> # Node ID 8c0ce135cda382630adc72d64757ec64854ba696
> # Parent  b60667a56ae085ee2bcea896887d0907fb86af41
> ipxe: fix compilation issues with some gcc versions
> 
> Backported some changes from current ipxe, to fix a issue with some
> new versions of gcc that add -fPIC by default, and compilation fails
> with the following error:

Is there a newer release tag on the ipxe repo that we could build instead,
that would automatically get us these fixes?

 -- Keir

> arch/i386/core/cpu.c: In function 'get_cpuinfo':
> arch/i386/include/bits/cpu.h:79:2: error: inconsistent operand
> constraints in an 'asm'
> arch/i386/include/bits/cpu.h:79:2: error: inconsistent operand
> constraints in an 'asm'
> arch/i386/include/bits/cpu.h:79:2: error: inconsistent operand
> constraints in an 'asm'
> arch/i386/include/bits/cpu.h:79:2: error: inconsistent operand
> constraints in an 'asm'
> 
> Two patches from ipxe git have been added. The problem is reproducible
> with at least this version of gcc:
> 
> Using built-in specs.
> COLLECT_GCC=gcc
> COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-alpine-linux-uclibc/4.6.2/lto-wrap
> per
> Target: x86_64-alpine-linux-uclibc
> Configured with:
> /home/buildozer/aports/main/gcc/src/gcc-4.6.2/configure --prefix=/usr
> --mandir=/usr/share/man --infodir=/usr/share/info
> --build=x86_64-alpine-linux-uclibc --host=x86_64-alpine-linux-uclibc
> --target=x86_64-alpine-linux-uclibc --with-pkgversion='Alpine
> 4.6.2-r1' --disable-altivec --disable-checking --disable-fixed-point
> --disable-libssp --disable-libstdcxx-pch --disable-multilib
> --disable-nls --disable-werror --enable-__cxa_atexit --enable-cld
> --enable-esp --enable-cloog-backend
> --enable-languages=c,c++,objc,java,go --enable-shared
> --enable-target-optspace --enable-tls --enable-threads
> --with-dynamic-linker=ld64-uClibc.so.0.9.32
> --with-dynamic-linker-prefix=/lib --with-system-zlib
> --without-system-libunwind
> Thread model: posix
> gcc version 4.6.2 (Alpine 4.6.2-r1)
> 
> Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>
> 
> diff -r b60667a56ae0 -r 8c0ce135cda3
> tools/firmware/etherboot/patches/gpxe-git-b8924c1aed51
> --- /dev/null Thu Jan 01 00:00:00 1970 +0000
> +++ b/tools/firmware/etherboot/patches/gpxe-git-b8924c1aed51 Fri Dec 16
> 13:48:50 2011 +0100
> @@ -0,0 +1,72 @@
> +commit b8924c1aed512aa40cf28a43635df383880f771d
> +Author: Michael Brown <mcb30@ipxe.org>
> +Date:   Wed Mar 16 19:30:42 2011 +0000
> +
> +    [build] Allow workaround-specific flags to override default flags
> +    
> +    Signed-off-by: Michael Brown <mcb30@ipxe.org>
> +
> +diff --git a/src/Makefile.housekeeping b/src/Makefile.housekeeping
> +index 709f8de..78e78c9 100644
> +--- a/src/Makefile.housekeeping
> ++++ b/src/Makefile.housekeeping
> +@@ -109,6 +109,10 @@ VERYCLEANUP += .toolcheck
> + # Check for various tool workarounds
> + #
> + 
> ++WORKAROUND_CFLAGS :=
> ++WORKAROUND_ASFLAGS :=
> ++WORKAROUND_LDFLAGS :=
> ++
> + # Make syntax does not allow use of comma or space in certain places.
> + # This ugly workaround is suggested in the manual.
> + #
> +@@ -119,7 +123,7 @@ SPACE := $(EMPTY) $(EMPTY)
> + # Check for an old version of gas (binutils 2.9.1)
> + #
> + OLDGAS := $(shell $(AS) --version | grep -q '2\.9\.1' && $(ECHO) -DGAS291)
> +-CFLAGS += $(OLDGAS)
> ++WORKAROUND_CFLAGS += $(OLDGAS)
> + oldgas :
> +  @$(ECHO) $(oldgas)
> + 
> +@@ -131,7 +135,7 @@ ifeq ($(CCTYPE),gcc)
> + SP_TEST = $(CC) -fno-stack-protector -x c -c /dev/null \
> +   -o /dev/null >/dev/null 2>&1
> + SP_FLAGS := $(shell $(SP_TEST) && $(ECHO) '-fno-stack-protector')
> +-CFLAGS += $(SP_FLAGS)
> ++WORKAROUND_CFLAGS += $(SP_FLAGS)
> + endif
> + 
> + # gcc 4.4 generates .eh_frame sections by default, which distort the
> +@@ -141,7 +145,7 @@ ifeq ($(CCTYPE),gcc)
> + CFI_TEST = $(CC) -fno-dwarf2-cfi-asm -x c -c /dev/null \
> +    -o /dev/null >/dev/null 2>&1
> + CFI_FLAGS := $(shell $(CFI_TEST) && $(ECHO) '-fno-dwarf2-cfi-asm')
> +-CFLAGS += $(CFI_FLAGS)
> ++WORKAROUND_CFLAGS += $(CFI_FLAGS)
> + endif
> + 
> + # Some versions of gas choke on division operators, treating them as
> +@@ -150,7 +154,7 @@ endif
> + #
> + DIVIDE_TEST = $(AS) --divide /dev/null -o /dev/null 2>/dev/null
> + DIVIDE_FLAGS := $(shell $(DIVIDE_TEST) && $(ECHO) '--divide')
> +-ASFLAGS += $(DIVIDE_FLAGS)
> ++WORKAROUND_ASFLAGS += $(DIVIDE_FLAGS)
> + 
> + 
> 
##############################################################################>
#
> + #
> +@@ -375,9 +379,9 @@ CFLAGS  += -diag-disable 1419 # Missing prototypes
> + CFLAGS  += -diag-disable 1599 # Hidden variables
> + CFLAGS  += -Wall -Wmissing-declarations
> + endif
> +-CFLAGS  += $(EXTRA_CFLAGS)
> +-ASFLAGS  += $(EXTRA_ASFLAGS)
> +-LDFLAGS  += $(EXTRA_LDFLAGS)
> ++CFLAGS  += $(WORKAROUND_CFLAGS) $(EXTRA_CFLAGS)
> ++ASFLAGS  += $(WORKAROUND_ASFLAGS) $(EXTRA_ASFLAGS)
> ++LDFLAGS  += $(WORKAROUND_LDFLAGS) $(EXTRA_LDFLAGS)
> + 
> + # Inhibit -Werror if NO_WERROR is specified on make command line
> + #
> diff -r b60667a56ae0 -r 8c0ce135cda3
> tools/firmware/etherboot/patches/gpxe-git-fe61f6de0dd5
> --- /dev/null Thu Jan 01 00:00:00 1970 +0000
> +++ b/tools/firmware/etherboot/patches/gpxe-git-fe61f6de0dd5 Fri Dec 16
> 13:48:50 2011 +0100
> @@ -0,0 +1,32 @@
> +commit fe61f6de0dd5d39ac3de5e8e18742f9bd0aafad7
> +Author: Gilles Espinasse <g.esp@free.fr>
> +Date:   Tue Mar 29 15:30:11 2011 +0100
> +
> +    [build] Fix compilation when gcc is patched to default to -fPIE -Wl,-pie
> +    
> +    Signed-off-by: Gilles Espinasse <g.esp@free.fr>
> +    Modified-by: Michael Brown <mcb30@ipxe.org>
> +    Signed-off-by: Michael Brown <mcb30@ipxe.org>
> +
> +diff --git a/src/Makefile.housekeeping b/src/Makefile.housekeeping
> +index 57e52c0..c184351 100644
> +--- a/src/Makefile.housekeeping
> ++++ b/src/Makefile.housekeeping
> +@@ -138,6 +138,17 @@ SP_FLAGS := $(shell $(SP_TEST) && $(ECHO)
> '-fno-stack-protector')
> + WORKAROUND_CFLAGS += $(SP_FLAGS)
> + endif
> + 
> ++# Some widespread patched versions of gcc include -fPIE -Wl,-pie by
> ++# default.  Note that gcc will exit *successfully* if it fails to
> ++# recognise an option that starts with "no", so we have to test for
> ++# output on stderr instead of checking the exit status.
> ++#
> ++ifeq ($(CCTYPE),gcc)
> ++PIE_TEST = [ -z "`$(CC) -fno-PIE -nopie -x c -c /dev/null -o /dev/null
> 2>&1`" ]
> ++PIE_FLAGS := $(shell $(PIE_TEST) && $(ECHO) '-fno-PIE -nopie')
> ++WORKAROUND_CFLAGS += $(PIE_FLAGS)
> ++endif
> ++
> + # gcc 4.4 generates .eh_frame sections by default, which distort the
> + # output of "size".  Inhibit this.
> + #
> diff -r b60667a56ae0 -r 8c0ce135cda3 tools/firmware/etherboot/patches/series
> --- a/tools/firmware/etherboot/patches/series Fri Dec 16 10:47:18 2011 +0100
> +++ b/tools/firmware/etherboot/patches/series Fri Dec 16 13:48:50 2011 +0100
> @@ -1,3 +1,5 @@
>  boot_prompt_option.patch
>  gpxe-git-0edf2405b457
>  gpxe-git-a803ef3dfeac
> +gpxe-git-b8924c1aed51
> +gpxe-git-fe61f6de0dd5
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 13:01:12 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 13:01:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbXPA-0005vW-M3; Fri, 16 Dec 2011 13:00:52 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RbXP9-0005vN-FF
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 13:00:51 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1324040430!49586144!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11471 invoked from network); 16 Dec 2011 13:00:31 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-11.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 16 Dec 2011 13:00:31 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 16 Dec 2011 13:00:49 +0000
Message-Id: <4EEB4F1002000078000687A5@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 16 Dec 2011 13:00:48 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Jinsong Liu" <jinsong.liu@intel.com>
References: <BC00F5384FCFC9499AF06F92E8B78A9E288CB0FF82@shsmsx502.ccr.corp.intel.com>
In-Reply-To: <BC00F5384FCFC9499AF06F92E8B78A9E288CB0FF82@shsmsx502.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "keir.xen@gmail.com" <keir.xen@gmail.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] X86-MCE: fix a bug of xen-mceinj tool
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 16.12.11 at 12:47, "Liu, Jinsong" <jinsong.liu@intel.com> wrote:
> X86-MCE: fix a bug of xen-mceinj tool
> 
> Fix a bug of xen-mceinj tool which used to test mce by software way.
> 
> Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
> 
> diff -r 86defe150053 tools/tests/mce-test/tools/xen-mceinj.c
> --- a/tools/tests/mce-test/tools/xen-mceinj.c	Fri Dec 16 16:24:31 2011 +0800
> +++ b/tools/tests/mce-test/tools/xen-mceinj.c	Fri Dec 16 17:28:38 2011 +0800
> @@ -134,8 +134,12 @@ static int mca_cpuinfo(xc_interface *xc_
>  {
>      struct xen_mc mc;
>  
> +    memset(&mc, 0, sizeof(struct xen_mc));

I doubt this is really needed.

> +
>      mc.cmd = XEN_MC_physcpuinfo;
> -    if (xc_mca_op(xc_handle, &mc))
> +    mc.interface_version = XEN_MCA_INTERFACE_VERSION;

Wouldn't this rather belong into xc_mca_op()?

Jan

> +
> +    if (!xc_mca_op(xc_handle, &mc))
>          return mc.u.mc_physcpuinfo.ncpus;
>      else
>          return 0;




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 13:01:12 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 13:01:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbXPA-0005vW-M3; Fri, 16 Dec 2011 13:00:52 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RbXP9-0005vN-FF
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 13:00:51 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1324040430!49586144!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11471 invoked from network); 16 Dec 2011 13:00:31 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-11.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 16 Dec 2011 13:00:31 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 16 Dec 2011 13:00:49 +0000
Message-Id: <4EEB4F1002000078000687A5@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 16 Dec 2011 13:00:48 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Jinsong Liu" <jinsong.liu@intel.com>
References: <BC00F5384FCFC9499AF06F92E8B78A9E288CB0FF82@shsmsx502.ccr.corp.intel.com>
In-Reply-To: <BC00F5384FCFC9499AF06F92E8B78A9E288CB0FF82@shsmsx502.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "keir.xen@gmail.com" <keir.xen@gmail.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] X86-MCE: fix a bug of xen-mceinj tool
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 16.12.11 at 12:47, "Liu, Jinsong" <jinsong.liu@intel.com> wrote:
> X86-MCE: fix a bug of xen-mceinj tool
> 
> Fix a bug of xen-mceinj tool which used to test mce by software way.
> 
> Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
> 
> diff -r 86defe150053 tools/tests/mce-test/tools/xen-mceinj.c
> --- a/tools/tests/mce-test/tools/xen-mceinj.c	Fri Dec 16 16:24:31 2011 +0800
> +++ b/tools/tests/mce-test/tools/xen-mceinj.c	Fri Dec 16 17:28:38 2011 +0800
> @@ -134,8 +134,12 @@ static int mca_cpuinfo(xc_interface *xc_
>  {
>      struct xen_mc mc;
>  
> +    memset(&mc, 0, sizeof(struct xen_mc));

I doubt this is really needed.

> +
>      mc.cmd = XEN_MC_physcpuinfo;
> -    if (xc_mca_op(xc_handle, &mc))
> +    mc.interface_version = XEN_MCA_INTERFACE_VERSION;

Wouldn't this rather belong into xc_mca_op()?

Jan

> +
> +    if (!xc_mca_op(xc_handle, &mc))
>          return mc.u.mc_physcpuinfo.ncpus;
>      else
>          return 0;




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 13:05:04 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 13:05:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbXT1-0006At-DB; Fri, 16 Dec 2011 13:04:51 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RbXSz-0006AQ-OT
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 13:04:49 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1324040681!7548818!1
X-Originating-IP: [209.85.210.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11645 invoked from network); 16 Dec 2011 13:04:43 -0000
Received: from mail-pz0-f43.google.com (HELO mail-pz0-f43.google.com)
	(209.85.210.43)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Dec 2011 13:04:43 -0000
Received: by daec6 with SMTP id c6so12293458dae.30
	for <xen-devel@lists.xensource.com>;
	Fri, 16 Dec 2011 05:04:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=3XcXAon83TP7pO+9thuXJnQOchaf3fmZWAwoBy8r1Vk=;
	b=P2pUXXENBLzvy4iHwuZpyueM+h3JYSqKL0gYGnykJwi/gYZmlZHqPcoeP1Vj6kl8oy
	V46ZtMOfonVyIvYhqict2BZrOgoGCfHnCjNObBZO258uM5xuDbzd4jrjoBYhB19mWcL+
	vx8MKHLliVdpm0XS26DTdR83buQVIjpK+7kfE=
MIME-Version: 1.0
Received: by 10.68.192.74 with SMTP id he10mr15971384pbc.13.1324040681466;
	Fri, 16 Dec 2011 05:04:41 -0800 (PST)
Received: by 10.142.47.17 with HTTP; Fri, 16 Dec 2011 05:04:41 -0800 (PST)
In-Reply-To: <CB10F11E.27664%keir.xen@gmail.com>
References: <8c0ce135cda382630adc.1324039808@alpine.localdomain>
	<CB10F11E.27664%keir.xen@gmail.com>
Date: Fri, 16 Dec 2011 14:04:41 +0100
X-Google-Sender-Auth: _mNi8zdDv12NVtUpmRz_YDuwbvw
Message-ID: <CAPLaKK7J312vgixP-SpH6VkrUF_WvdFpB7X72viNpiJXyU5UJg@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Keir Fraser <keir.xen@gmail.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] ipxe: fix compilation issues with some gcc
	versions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

MjAxMS8xMi8xNiBLZWlyIEZyYXNlciA8a2Vpci54ZW5AZ21haWwuY29tPjoKPiBPbiAxNi8xMi8y
MDExIDEyOjUwLCAiUm9nZXIgUGF1IE1vbm5lIiA8cm9nZXIucGF1QGVudGVsLnVwYy5lZHU+IHdy
b3RlOgo+Cj4+ICMgSEcgY2hhbmdlc2V0IHBhdGNoCj4+ICMgVXNlciBSb2dlciBQYXUgTW9ubmUg
PHJvZ2VyLnBhdUBlbnRlbC51cGMuZWR1Pgo+PiAjIERhdGUgMTMyNDAzOTczMCAtMzYwMAo+PiAj
IE5vZGUgSUQgOGMwY2UxMzVjZGEzODI2MzBhZGM3MmQ2NDc1N2VjNjQ4NTRiYTY5Ngo+PiAjIFBh
cmVudCDCoGI2MDY2N2E1NmFlMDg1ZWUyYmNlYTg5Njg4N2QwOTA3ZmI4NmFmNDEKPj4gaXB4ZTog
Zml4IGNvbXBpbGF0aW9uIGlzc3VlcyB3aXRoIHNvbWUgZ2NjIHZlcnNpb25zCj4+Cj4+IEJhY2tw
b3J0ZWQgc29tZSBjaGFuZ2VzIGZyb20gY3VycmVudCBpcHhlLCB0byBmaXggYSBpc3N1ZSB3aXRo
IHNvbWUKPj4gbmV3IHZlcnNpb25zIG9mIGdjYyB0aGF0IGFkZCAtZlBJQyBieSBkZWZhdWx0LCBh
bmQgY29tcGlsYXRpb24gZmFpbHMKPj4gd2l0aCB0aGUgZm9sbG93aW5nIGVycm9yOgo+Cj4gSXMg
dGhlcmUgYSBuZXdlciByZWxlYXNlIHRhZyBvbiB0aGUgaXB4ZSByZXBvIHRoYXQgd2UgY291bGQg
YnVpbGQgaW5zdGVhZCwKPiB0aGF0IHdvdWxkIGF1dG9tYXRpY2FsbHkgZ2V0IHVzIHRoZXNlIGZp
eGVzPwoKTm8sIGxhdGVzdCB0YWcgKGFsbW9zdCB0d28geWVhcnMgYWdvKSBpcyAxLjAuMCwgd2hp
Y2ggaXMgdGhlIG9uZSB3ZQphcmUgY3VycmVudGx5IHVzaW5nLgoKX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4t
ZGV2ZWxAbGlzdHMueGVuc291cmNlLmNvbQpodHRwOi8vbGlzdHMueGVuc291cmNlLmNvbS94ZW4t
ZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Fri Dec 16 13:05:04 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 13:05:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbXT1-0006At-DB; Fri, 16 Dec 2011 13:04:51 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RbXSz-0006AQ-OT
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 13:04:49 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1324040681!7548818!1
X-Originating-IP: [209.85.210.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11645 invoked from network); 16 Dec 2011 13:04:43 -0000
Received: from mail-pz0-f43.google.com (HELO mail-pz0-f43.google.com)
	(209.85.210.43)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Dec 2011 13:04:43 -0000
Received: by daec6 with SMTP id c6so12293458dae.30
	for <xen-devel@lists.xensource.com>;
	Fri, 16 Dec 2011 05:04:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=3XcXAon83TP7pO+9thuXJnQOchaf3fmZWAwoBy8r1Vk=;
	b=P2pUXXENBLzvy4iHwuZpyueM+h3JYSqKL0gYGnykJwi/gYZmlZHqPcoeP1Vj6kl8oy
	V46ZtMOfonVyIvYhqict2BZrOgoGCfHnCjNObBZO258uM5xuDbzd4jrjoBYhB19mWcL+
	vx8MKHLliVdpm0XS26DTdR83buQVIjpK+7kfE=
MIME-Version: 1.0
Received: by 10.68.192.74 with SMTP id he10mr15971384pbc.13.1324040681466;
	Fri, 16 Dec 2011 05:04:41 -0800 (PST)
Received: by 10.142.47.17 with HTTP; Fri, 16 Dec 2011 05:04:41 -0800 (PST)
In-Reply-To: <CB10F11E.27664%keir.xen@gmail.com>
References: <8c0ce135cda382630adc.1324039808@alpine.localdomain>
	<CB10F11E.27664%keir.xen@gmail.com>
Date: Fri, 16 Dec 2011 14:04:41 +0100
X-Google-Sender-Auth: _mNi8zdDv12NVtUpmRz_YDuwbvw
Message-ID: <CAPLaKK7J312vgixP-SpH6VkrUF_WvdFpB7X72viNpiJXyU5UJg@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Keir Fraser <keir.xen@gmail.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] ipxe: fix compilation issues with some gcc
	versions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

MjAxMS8xMi8xNiBLZWlyIEZyYXNlciA8a2Vpci54ZW5AZ21haWwuY29tPjoKPiBPbiAxNi8xMi8y
MDExIDEyOjUwLCAiUm9nZXIgUGF1IE1vbm5lIiA8cm9nZXIucGF1QGVudGVsLnVwYy5lZHU+IHdy
b3RlOgo+Cj4+ICMgSEcgY2hhbmdlc2V0IHBhdGNoCj4+ICMgVXNlciBSb2dlciBQYXUgTW9ubmUg
PHJvZ2VyLnBhdUBlbnRlbC51cGMuZWR1Pgo+PiAjIERhdGUgMTMyNDAzOTczMCAtMzYwMAo+PiAj
IE5vZGUgSUQgOGMwY2UxMzVjZGEzODI2MzBhZGM3MmQ2NDc1N2VjNjQ4NTRiYTY5Ngo+PiAjIFBh
cmVudCDCoGI2MDY2N2E1NmFlMDg1ZWUyYmNlYTg5Njg4N2QwOTA3ZmI4NmFmNDEKPj4gaXB4ZTog
Zml4IGNvbXBpbGF0aW9uIGlzc3VlcyB3aXRoIHNvbWUgZ2NjIHZlcnNpb25zCj4+Cj4+IEJhY2tw
b3J0ZWQgc29tZSBjaGFuZ2VzIGZyb20gY3VycmVudCBpcHhlLCB0byBmaXggYSBpc3N1ZSB3aXRo
IHNvbWUKPj4gbmV3IHZlcnNpb25zIG9mIGdjYyB0aGF0IGFkZCAtZlBJQyBieSBkZWZhdWx0LCBh
bmQgY29tcGlsYXRpb24gZmFpbHMKPj4gd2l0aCB0aGUgZm9sbG93aW5nIGVycm9yOgo+Cj4gSXMg
dGhlcmUgYSBuZXdlciByZWxlYXNlIHRhZyBvbiB0aGUgaXB4ZSByZXBvIHRoYXQgd2UgY291bGQg
YnVpbGQgaW5zdGVhZCwKPiB0aGF0IHdvdWxkIGF1dG9tYXRpY2FsbHkgZ2V0IHVzIHRoZXNlIGZp
eGVzPwoKTm8sIGxhdGVzdCB0YWcgKGFsbW9zdCB0d28geWVhcnMgYWdvKSBpcyAxLjAuMCwgd2hp
Y2ggaXMgdGhlIG9uZSB3ZQphcmUgY3VycmVudGx5IHVzaW5nLgoKX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4t
ZGV2ZWxAbGlzdHMueGVuc291cmNlLmNvbQpodHRwOi8vbGlzdHMueGVuc291cmNlLmNvbS94ZW4t
ZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Fri Dec 16 13:19:52 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 13:19:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbXhD-0006TC-3Y; Fri, 16 Dec 2011 13:19:31 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RbXhB-0006T7-9n
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 13:19:29 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1324041561!7744853!1
X-Originating-IP: [209.85.160.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6946 invoked from network); 16 Dec 2011 13:19:23 -0000
Received: from mail-pw0-f43.google.com (HELO mail-pw0-f43.google.com)
	(209.85.160.43)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Dec 2011 13:19:23 -0000
Received: by pbbb11 with SMTP id b11so9488193pbb.30
	for <xen-devel@lists.xensource.com>;
	Fri, 16 Dec 2011 05:19:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:content-type;
	bh=IliZKRumcW91H5/l+sgXNk/VYeTnPxzELaHzMFON0+U=;
	b=DLbKJU+tmME9QPchTkcX1i0k6/E30A6xWArmWrs163QsWdIX5IP5C3xrwx6tKo9WMz
	OQP9JHktzyqW66R+ddBJoAKMSiFXQx9Jd45FOjqe7cthCACwbtLUtJdLcgRkhhQgjxaJ
	PhtHH7EMrlSzbfAn4f86W7mctnunIThbZdK8Y=
MIME-Version: 1.0
Received: by 10.68.73.103 with SMTP id k7mr15895306pbv.132.1324041561023; Fri,
	16 Dec 2011 05:19:21 -0800 (PST)
Received: by 10.142.47.17 with HTTP; Fri, 16 Dec 2011 05:19:20 -0800 (PST)
In-Reply-To: <CAPLaKK7GCBSxPDfenHOzmVZ-uaHh186gfpHaJ7nmVHHrQVq6wQ@mail.gmail.com>
References: <a01f1e2f654ea54bbf5d.1323969513@loki.upc.es>
	<CAPLaKK7GCBSxPDfenHOzmVZ-uaHh186gfpHaJ7nmVHHrQVq6wQ@mail.gmail.com>
Date: Fri, 16 Dec 2011 14:19:20 +0100
X-Google-Sender-Auth: vGMYKLm6QiR9MLMv65L37GY7-qY
Message-ID: <CAPLaKK5tcNvJ_BKoso-q-G8uD9fvJrMyz3Rthsr7mXwMfg8LSA@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] blktap2: use HAVE_BYTESWAP_H and
	_BYTESWAP_H for uclibc compatibility
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This patch is wrong, but I think blktap bswap.h is also wrong, because
HAVE_BYTESWAP_H is defined by qemu, but blktap doesn't include qemu
config file, so HAVE_BYTESWAP_H is not defined in this header file
(which doesn't mean that byteswap.h is not present on the system). How
should we fix this? Forget about including byteswap.h and always
define the functions ourselves?

Thanks, Roger.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 13:19:52 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 13:19:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbXhD-0006TC-3Y; Fri, 16 Dec 2011 13:19:31 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RbXhB-0006T7-9n
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 13:19:29 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1324041561!7744853!1
X-Originating-IP: [209.85.160.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6946 invoked from network); 16 Dec 2011 13:19:23 -0000
Received: from mail-pw0-f43.google.com (HELO mail-pw0-f43.google.com)
	(209.85.160.43)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Dec 2011 13:19:23 -0000
Received: by pbbb11 with SMTP id b11so9488193pbb.30
	for <xen-devel@lists.xensource.com>;
	Fri, 16 Dec 2011 05:19:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:content-type;
	bh=IliZKRumcW91H5/l+sgXNk/VYeTnPxzELaHzMFON0+U=;
	b=DLbKJU+tmME9QPchTkcX1i0k6/E30A6xWArmWrs163QsWdIX5IP5C3xrwx6tKo9WMz
	OQP9JHktzyqW66R+ddBJoAKMSiFXQx9Jd45FOjqe7cthCACwbtLUtJdLcgRkhhQgjxaJ
	PhtHH7EMrlSzbfAn4f86W7mctnunIThbZdK8Y=
MIME-Version: 1.0
Received: by 10.68.73.103 with SMTP id k7mr15895306pbv.132.1324041561023; Fri,
	16 Dec 2011 05:19:21 -0800 (PST)
Received: by 10.142.47.17 with HTTP; Fri, 16 Dec 2011 05:19:20 -0800 (PST)
In-Reply-To: <CAPLaKK7GCBSxPDfenHOzmVZ-uaHh186gfpHaJ7nmVHHrQVq6wQ@mail.gmail.com>
References: <a01f1e2f654ea54bbf5d.1323969513@loki.upc.es>
	<CAPLaKK7GCBSxPDfenHOzmVZ-uaHh186gfpHaJ7nmVHHrQVq6wQ@mail.gmail.com>
Date: Fri, 16 Dec 2011 14:19:20 +0100
X-Google-Sender-Auth: vGMYKLm6QiR9MLMv65L37GY7-qY
Message-ID: <CAPLaKK5tcNvJ_BKoso-q-G8uD9fvJrMyz3Rthsr7mXwMfg8LSA@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] blktap2: use HAVE_BYTESWAP_H and
	_BYTESWAP_H for uclibc compatibility
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This patch is wrong, but I think blktap bswap.h is also wrong, because
HAVE_BYTESWAP_H is defined by qemu, but blktap doesn't include qemu
config file, so HAVE_BYTESWAP_H is not defined in this header file
(which doesn't mean that byteswap.h is not present on the system). How
should we fix this? Forget about including byteswap.h and always
define the functions ourselves?

Thanks, Roger.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 13:21:13 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 13: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.xensource.com>)
	id 1RbXiX-0006WN-J2; Fri, 16 Dec 2011 13:20:53 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RbXiW-0006WB-1b
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 13:20:52 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1324041645!1787062!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjU3OQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2527 invoked from network); 16 Dec 2011 13:20:45 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Dec 2011 13:20:45 -0000
X-IronPort-AV: E=Sophos;i="4.71,363,1320624000"; 
   d="scan'208";a="9514521"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Dec 2011 13:20:45 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 16 Dec 2011 13:20:44 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Paul Durrant <Paul.Durrant@citrix.com>
Date: Fri, 16 Dec 2011 13:20:44 +0000
In-Reply-To: <291EDFCB1E9E224A99088639C4762022B598ED0FE5@LONPMAILBOX01.citrite.net>
References: <patchbomb.1324036046@cosworth.uk.xensource.com>
	<e745cfbe7e114cb8a8c3.1324036049@cosworth.uk.xensource.com>
	<1324037266.20077.596.camel@zakaz.uk.xensource.com>
	<291EDFCB1E9E224A99088639C4762022B598ED0FE5@LONPMAILBOX01.citrite.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1324041644.20077.599.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 3 of 3] VM generation ID save/restore and
 migrate
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2011-12-16 at 12:51 +0000, Paul Durrant wrote:
> > -----Original Message-----
> > From: Ian Campbell
> > Sent: 16 December 2011 12:08
> > To: Paul Durrant
> > Cc: xen-devel@lists.xensource.com
> > Subject: Re: [Xen-devel] [PATCH 3 of 3] VM generation ID
> > save/restore and migrate
> > 
> > On Fri, 2011-12-16 at 11:47 +0000, Paul Durrant wrote:
> > > diff -r d44e885e0389 -r e745cfbe7e11
> > tools/python/xen/lowlevel/checkpoint/libcheckpoint.c
> > > --- a/tools/python/xen/lowlevel/checkpoint/libcheckpoint.c
> > Fri Dec 16 11:43:52 2011 +0000
> > > +++ b/tools/python/xen/lowlevel/checkpoint/libcheckpoint.c
> > Fri Dec 16 11:43:53 2011 +0000
> > > @@ -175,6 +175,7 @@ int checkpoint_start(checkpoint_state* s  {
> > >      int hvm, rc;
> > >      int flags = XCFLAGS_LIVE;
> > > +    unsigned long vm_generationid_addr;
> > >
> > >      if (!s->domid) {
> > >         s->errstr = "checkpoint state not opened"; @@ -185,16
> > +186,28
> > > @@ int checkpoint_start(checkpoint_state* s
> > >
> > >      hvm = s->domtype > dt_pv;
> > >      if (hvm) {
> > > +       char path[128];
> > > +       char *addr;
> > > +
> > > +       sprintf(path,
> > > + "/local/domain/%u/hvmloader/generation-id-address", s->domid);
> > 
> > xs_get_domain_path() gives you the correct base path (I saw at least
> > one more of these).
> > 
> 
> Does that save me anything?

Probably not much, other than avoiding hardcoding something. I
guess /local/domain/%d is fair game in a toolstack.

>  I'd end up having to
> 
> sprintf(path, "%s/hvmloader/generation-id-address", xs_get_domain_path(s->xsh, s->domid))
> 
> since xs_read() just takes a path rather than a (prefix, node) couple.

xs_chdir() would actually be quite useful for this sort of thing, but it
doesn't exist so nevermind.

Ian.


> 
>   Paul
> 
> > > diff -r d44e885e0389 -r e745cfbe7e11 tools/xcutils/xc_restore.c
> > > --- a/tools/xcutils/xc_restore.c        Fri Dec 16 11:43:52 2011
> > +0000
> > > +++ b/tools/xcutils/xc_restore.c        Fri Dec 16 11:43:53 2011
> > +0000
> > [...]
> > > diff -r d44e885e0389 -r e745cfbe7e11 tools/xcutils/xc_save.c
> > > --- a/tools/xcutils/xc_save.c   Fri Dec 16 11:43:52 2011 +0000
> > > +++ b/tools/xcutils/xc_save.c   Fri Dec 16 11:43:53 2011 +0000
> > [...]
> > 
> > AFAIK these two are only used by xend so unless you are adding
> > support for this stuff there (it's deprecated so no need) this isn't
> > necessary, also I think xend reads the stdout of one or both and
> > you've added to what gets printed, running the risk of breaking
> > things.
> > 
> > Ian.
> > 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 13:21:13 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 13: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.xensource.com>)
	id 1RbXiX-0006WN-J2; Fri, 16 Dec 2011 13:20:53 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RbXiW-0006WB-1b
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 13:20:52 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1324041645!1787062!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjU3OQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2527 invoked from network); 16 Dec 2011 13:20:45 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Dec 2011 13:20:45 -0000
X-IronPort-AV: E=Sophos;i="4.71,363,1320624000"; 
   d="scan'208";a="9514521"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Dec 2011 13:20:45 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 16 Dec 2011 13:20:44 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Paul Durrant <Paul.Durrant@citrix.com>
Date: Fri, 16 Dec 2011 13:20:44 +0000
In-Reply-To: <291EDFCB1E9E224A99088639C4762022B598ED0FE5@LONPMAILBOX01.citrite.net>
References: <patchbomb.1324036046@cosworth.uk.xensource.com>
	<e745cfbe7e114cb8a8c3.1324036049@cosworth.uk.xensource.com>
	<1324037266.20077.596.camel@zakaz.uk.xensource.com>
	<291EDFCB1E9E224A99088639C4762022B598ED0FE5@LONPMAILBOX01.citrite.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1324041644.20077.599.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 3 of 3] VM generation ID save/restore and
 migrate
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2011-12-16 at 12:51 +0000, Paul Durrant wrote:
> > -----Original Message-----
> > From: Ian Campbell
> > Sent: 16 December 2011 12:08
> > To: Paul Durrant
> > Cc: xen-devel@lists.xensource.com
> > Subject: Re: [Xen-devel] [PATCH 3 of 3] VM generation ID
> > save/restore and migrate
> > 
> > On Fri, 2011-12-16 at 11:47 +0000, Paul Durrant wrote:
> > > diff -r d44e885e0389 -r e745cfbe7e11
> > tools/python/xen/lowlevel/checkpoint/libcheckpoint.c
> > > --- a/tools/python/xen/lowlevel/checkpoint/libcheckpoint.c
> > Fri Dec 16 11:43:52 2011 +0000
> > > +++ b/tools/python/xen/lowlevel/checkpoint/libcheckpoint.c
> > Fri Dec 16 11:43:53 2011 +0000
> > > @@ -175,6 +175,7 @@ int checkpoint_start(checkpoint_state* s  {
> > >      int hvm, rc;
> > >      int flags = XCFLAGS_LIVE;
> > > +    unsigned long vm_generationid_addr;
> > >
> > >      if (!s->domid) {
> > >         s->errstr = "checkpoint state not opened"; @@ -185,16
> > +186,28
> > > @@ int checkpoint_start(checkpoint_state* s
> > >
> > >      hvm = s->domtype > dt_pv;
> > >      if (hvm) {
> > > +       char path[128];
> > > +       char *addr;
> > > +
> > > +       sprintf(path,
> > > + "/local/domain/%u/hvmloader/generation-id-address", s->domid);
> > 
> > xs_get_domain_path() gives you the correct base path (I saw at least
> > one more of these).
> > 
> 
> Does that save me anything?

Probably not much, other than avoiding hardcoding something. I
guess /local/domain/%d is fair game in a toolstack.

>  I'd end up having to
> 
> sprintf(path, "%s/hvmloader/generation-id-address", xs_get_domain_path(s->xsh, s->domid))
> 
> since xs_read() just takes a path rather than a (prefix, node) couple.

xs_chdir() would actually be quite useful for this sort of thing, but it
doesn't exist so nevermind.

Ian.


> 
>   Paul
> 
> > > diff -r d44e885e0389 -r e745cfbe7e11 tools/xcutils/xc_restore.c
> > > --- a/tools/xcutils/xc_restore.c        Fri Dec 16 11:43:52 2011
> > +0000
> > > +++ b/tools/xcutils/xc_restore.c        Fri Dec 16 11:43:53 2011
> > +0000
> > [...]
> > > diff -r d44e885e0389 -r e745cfbe7e11 tools/xcutils/xc_save.c
> > > --- a/tools/xcutils/xc_save.c   Fri Dec 16 11:43:52 2011 +0000
> > > +++ b/tools/xcutils/xc_save.c   Fri Dec 16 11:43:53 2011 +0000
> > [...]
> > 
> > AFAIK these two are only used by xend so unless you are adding
> > support for this stuff there (it's deprecated so no need) this isn't
> > necessary, also I think xend reads the stdout of one or both and
> > you've added to what gets printed, running the risk of breaking
> > things.
> > 
> > Ian.
> > 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 13:22:09 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 13:22:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbXjY-0006bb-24; Fri, 16 Dec 2011 13:21:56 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RbXjX-0006aj-4E
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 13:21:55 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1324041708!7016372!1
X-Originating-IP: [209.85.161.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27647 invoked from network); 16 Dec 2011 13:21:48 -0000
Received: from mail-fx0-f43.google.com (HELO mail-fx0-f43.google.com)
	(209.85.161.43)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Dec 2011 13:21:48 -0000
Received: by faap21 with SMTP id p21so7191403faa.30
	for <xen-devel@lists.xensource.com>;
	Fri, 16 Dec 2011 05:21:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=jnNhRRgAF7AZfurd11GJyyszQOTBf5EfyptgGuf4aL8=;
	b=Ee+TUC/+G5SL2jTls7rGPqn9vOUw4Hn6ZE1C85Q7iGwmUtZSJVoqEs8W21eaK3B+Qw
	bJk0m/LLxyCXbakmSGX5k9R4Mr4dG2IJEjbaurbD/XoASjqqIujR9ncO1pJ5eQFzyB1v
	mtDuKgmhkEG40xBTxuwY9N8n3vkZQbtLUOjNs=
Received: by 10.180.14.193 with SMTP id r1mr8989468wic.2.1324041707591;
	Fri, 16 Dec 2011 05:21:47 -0800 (PST)
Received: from [192.168.1.3] (host81-152-17-11.range81-152.btcentralplus.com.
	[81.152.17.11])
	by mx.google.com with ESMTPS id di5sm13094738wib.3.2011.12.16.05.21.46
	(version=SSLv3 cipher=OTHER); Fri, 16 Dec 2011 05:21:47 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Fri, 16 Dec 2011 13:21:41 +0000
From: Keir Fraser <keir@xen.org>
To: Roger Pau =?ISO-8859-1?B?TW9ubuk=?= <roger.pau@entel.upc.edu>
Message-ID: <CB10F665.361A4%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH] ipxe: fix compilation issues with some gcc
	versions
Thread-Index: Acy79aXNII6nb5Y3skOyK73d7rocng==
In-Reply-To: <CAPLaKK7J312vgixP-SpH6VkrUF_WvdFpB7X72viNpiJXyU5UJg@mail.gmail.com>
Mime-version: 1.0
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] ipxe: fix compilation issues with some gcc
 versions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 16/12/2011 13:04, "Roger Pau Monn=E9" <roger.pau@entel.upc.edu> wrote:

> 2011/12/16 Keir Fraser <keir.xen@gmail.com>:
>> On 16/12/2011 12:50, "Roger Pau Monne" <roger.pau@entel.upc.edu> wrote:
>> =

>>> # HG changeset patch
>>> # User Roger Pau Monne <roger.pau@entel.upc.edu>
>>> # Date 1324039730 -3600
>>> # Node ID 8c0ce135cda382630adc72d64757ec64854ba696
>>> # Parent =A0b60667a56ae085ee2bcea896887d0907fb86af41
>>> ipxe: fix compilation issues with some gcc versions
>>> =

>>> Backported some changes from current ipxe, to fix a issue with some
>>> new versions of gcc that add -fPIC by default, and compilation fails
>>> with the following error:
>> =

>> Is there a newer release tag on the ipxe repo that we could build instea=
d,
>> that would automatically get us these fixes?
> =

> No, latest tag (almost two years ago) is 1.0.0, which is the one we
> are currently using.

Perhaps we should pick a recent commit hash to clone, then? There's plenty
going on in there development-wise, which would surely have warranted a
release or two; it just looks like they couldn't be arsed to tag releases.
Hanging on to a two-year-old version and building up a backport queue
doesn't make sense. At the very least we should do this in xen-unstable, and
get some testing done of recent ipxe upstream.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 13:22:09 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 13:22:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbXjY-0006bb-24; Fri, 16 Dec 2011 13:21:56 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RbXjX-0006aj-4E
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 13:21:55 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1324041708!7016372!1
X-Originating-IP: [209.85.161.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27647 invoked from network); 16 Dec 2011 13:21:48 -0000
Received: from mail-fx0-f43.google.com (HELO mail-fx0-f43.google.com)
	(209.85.161.43)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Dec 2011 13:21:48 -0000
Received: by faap21 with SMTP id p21so7191403faa.30
	for <xen-devel@lists.xensource.com>;
	Fri, 16 Dec 2011 05:21:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=jnNhRRgAF7AZfurd11GJyyszQOTBf5EfyptgGuf4aL8=;
	b=Ee+TUC/+G5SL2jTls7rGPqn9vOUw4Hn6ZE1C85Q7iGwmUtZSJVoqEs8W21eaK3B+Qw
	bJk0m/LLxyCXbakmSGX5k9R4Mr4dG2IJEjbaurbD/XoASjqqIujR9ncO1pJ5eQFzyB1v
	mtDuKgmhkEG40xBTxuwY9N8n3vkZQbtLUOjNs=
Received: by 10.180.14.193 with SMTP id r1mr8989468wic.2.1324041707591;
	Fri, 16 Dec 2011 05:21:47 -0800 (PST)
Received: from [192.168.1.3] (host81-152-17-11.range81-152.btcentralplus.com.
	[81.152.17.11])
	by mx.google.com with ESMTPS id di5sm13094738wib.3.2011.12.16.05.21.46
	(version=SSLv3 cipher=OTHER); Fri, 16 Dec 2011 05:21:47 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Fri, 16 Dec 2011 13:21:41 +0000
From: Keir Fraser <keir@xen.org>
To: Roger Pau =?ISO-8859-1?B?TW9ubuk=?= <roger.pau@entel.upc.edu>
Message-ID: <CB10F665.361A4%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH] ipxe: fix compilation issues with some gcc
	versions
Thread-Index: Acy79aXNII6nb5Y3skOyK73d7rocng==
In-Reply-To: <CAPLaKK7J312vgixP-SpH6VkrUF_WvdFpB7X72viNpiJXyU5UJg@mail.gmail.com>
Mime-version: 1.0
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] ipxe: fix compilation issues with some gcc
 versions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 16/12/2011 13:04, "Roger Pau Monn=E9" <roger.pau@entel.upc.edu> wrote:

> 2011/12/16 Keir Fraser <keir.xen@gmail.com>:
>> On 16/12/2011 12:50, "Roger Pau Monne" <roger.pau@entel.upc.edu> wrote:
>> =

>>> # HG changeset patch
>>> # User Roger Pau Monne <roger.pau@entel.upc.edu>
>>> # Date 1324039730 -3600
>>> # Node ID 8c0ce135cda382630adc72d64757ec64854ba696
>>> # Parent =A0b60667a56ae085ee2bcea896887d0907fb86af41
>>> ipxe: fix compilation issues with some gcc versions
>>> =

>>> Backported some changes from current ipxe, to fix a issue with some
>>> new versions of gcc that add -fPIC by default, and compilation fails
>>> with the following error:
>> =

>> Is there a newer release tag on the ipxe repo that we could build instea=
d,
>> that would automatically get us these fixes?
> =

> No, latest tag (almost two years ago) is 1.0.0, which is the one we
> are currently using.

Perhaps we should pick a recent commit hash to clone, then? There's plenty
going on in there development-wise, which would surely have warranted a
release or two; it just looks like they couldn't be arsed to tag releases.
Hanging on to a two-year-old version and building up a backport queue
doesn't make sense. At the very least we should do this in xen-unstable, and
get some testing done of recent ipxe upstream.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 13:26:15 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 13:26:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbXnV-0006to-4k; Fri, 16 Dec 2011 13:26:01 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RbXnT-0006tI-MF
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 13:25:59 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1324041953!7551619!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjU3OQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3910 invoked from network); 16 Dec 2011 13:25:53 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Dec 2011 13:25:53 -0000
X-IronPort-AV: E=Sophos;i="4.71,363,1320624000"; 
   d="scan'208";a="9514624"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Dec 2011 13:25:53 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 16 Dec 2011 13:25:53 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau =?ISO-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
Date: Fri, 16 Dec 2011 13:25:53 +0000
In-Reply-To: <CAPLaKK5tcNvJ_BKoso-q-G8uD9fvJrMyz3Rthsr7mXwMfg8LSA@mail.gmail.com>
References: <a01f1e2f654ea54bbf5d.1323969513@loki.upc.es>
	<CAPLaKK7GCBSxPDfenHOzmVZ-uaHh186gfpHaJ7nmVHHrQVq6wQ@mail.gmail.com>
	<CAPLaKK5tcNvJ_BKoso-q-G8uD9fvJrMyz3Rthsr7mXwMfg8LSA@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1324041953.20077.601.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] blktap2: use HAVE_BYTESWAP_H and
 _BYTESWAP_H for uclibc compatibility
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gRnJpLCAyMDExLTEyLTE2IGF0IDEzOjE5ICswMDAwLCBSb2dlciBQYXUgTW9ubsOpIHdyb3Rl
Ogo+IFRoaXMgcGF0Y2ggaXMgd3JvbmcsIGJ1dCBJIHRoaW5rIGJsa3RhcCBic3dhcC5oIGlzIGFs
c28gd3JvbmcsIGJlY2F1c2UKPiBIQVZFX0JZVEVTV0FQX0ggaXMgZGVmaW5lZCBieSBxZW11LCBi
dXQgYmxrdGFwIGRvZXNuJ3QgaW5jbHVkZSBxZW11Cj4gY29uZmlnIGZpbGUsIHNvIEhBVkVfQllU
RVNXQVBfSCBpcyBub3QgZGVmaW5lZCBpbiB0aGlzIGhlYWRlciBmaWxlCj4gKHdoaWNoIGRvZXNu
J3QgbWVhbiB0aGF0IGJ5dGVzd2FwLmggaXMgbm90IHByZXNlbnQgb24gdGhlIHN5c3RlbSkuIEhv
dwo+IHNob3VsZCB3ZSBmaXggdGhpcz8gRm9yZ2V0IGFib3V0IGluY2x1ZGluZyBieXRlc3dhcC5o
IGFuZCBhbHdheXMKPiBkZWZpbmUgdGhlIGZ1bmN0aW9ucyBvdXJzZWx2ZXM/CgpJZiBIQVZFX0JZ
VEVTV0FQX0ggaGFzIG5ldmVyIGJlZW4gZGVmaW5lZCB1cCB1bnRpbCBub3cgY2FuJ3Qgd2UganVz
dApkZWxldGUgdGhlIGluY2x1ZGU/Cgo+IAo+IFRoYW5rcywgUm9nZXIuCj4gCj4gX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPiBYZW4tZGV2ZWwgbWFpbGlu
ZyBsaXN0Cj4gWGVuLWRldmVsQGxpc3RzLnhlbnNvdXJjZS5jb20KPiBodHRwOi8vbGlzdHMueGVu
c291cmNlLmNvbS94ZW4tZGV2ZWwKCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVu
c291cmNlLmNvbQpodHRwOi8vbGlzdHMueGVuc291cmNlLmNvbS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Fri Dec 16 13:26:15 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 13:26:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbXnV-0006to-4k; Fri, 16 Dec 2011 13:26:01 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RbXnT-0006tI-MF
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 13:25:59 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1324041953!7551619!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjU3OQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3910 invoked from network); 16 Dec 2011 13:25:53 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Dec 2011 13:25:53 -0000
X-IronPort-AV: E=Sophos;i="4.71,363,1320624000"; 
   d="scan'208";a="9514624"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Dec 2011 13:25:53 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 16 Dec 2011 13:25:53 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau =?ISO-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
Date: Fri, 16 Dec 2011 13:25:53 +0000
In-Reply-To: <CAPLaKK5tcNvJ_BKoso-q-G8uD9fvJrMyz3Rthsr7mXwMfg8LSA@mail.gmail.com>
References: <a01f1e2f654ea54bbf5d.1323969513@loki.upc.es>
	<CAPLaKK7GCBSxPDfenHOzmVZ-uaHh186gfpHaJ7nmVHHrQVq6wQ@mail.gmail.com>
	<CAPLaKK5tcNvJ_BKoso-q-G8uD9fvJrMyz3Rthsr7mXwMfg8LSA@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1324041953.20077.601.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] blktap2: use HAVE_BYTESWAP_H and
 _BYTESWAP_H for uclibc compatibility
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gRnJpLCAyMDExLTEyLTE2IGF0IDEzOjE5ICswMDAwLCBSb2dlciBQYXUgTW9ubsOpIHdyb3Rl
Ogo+IFRoaXMgcGF0Y2ggaXMgd3JvbmcsIGJ1dCBJIHRoaW5rIGJsa3RhcCBic3dhcC5oIGlzIGFs
c28gd3JvbmcsIGJlY2F1c2UKPiBIQVZFX0JZVEVTV0FQX0ggaXMgZGVmaW5lZCBieSBxZW11LCBi
dXQgYmxrdGFwIGRvZXNuJ3QgaW5jbHVkZSBxZW11Cj4gY29uZmlnIGZpbGUsIHNvIEhBVkVfQllU
RVNXQVBfSCBpcyBub3QgZGVmaW5lZCBpbiB0aGlzIGhlYWRlciBmaWxlCj4gKHdoaWNoIGRvZXNu
J3QgbWVhbiB0aGF0IGJ5dGVzd2FwLmggaXMgbm90IHByZXNlbnQgb24gdGhlIHN5c3RlbSkuIEhv
dwo+IHNob3VsZCB3ZSBmaXggdGhpcz8gRm9yZ2V0IGFib3V0IGluY2x1ZGluZyBieXRlc3dhcC5o
IGFuZCBhbHdheXMKPiBkZWZpbmUgdGhlIGZ1bmN0aW9ucyBvdXJzZWx2ZXM/CgpJZiBIQVZFX0JZ
VEVTV0FQX0ggaGFzIG5ldmVyIGJlZW4gZGVmaW5lZCB1cCB1bnRpbCBub3cgY2FuJ3Qgd2UganVz
dApkZWxldGUgdGhlIGluY2x1ZGU/Cgo+IAo+IFRoYW5rcywgUm9nZXIuCj4gCj4gX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPiBYZW4tZGV2ZWwgbWFpbGlu
ZyBsaXN0Cj4gWGVuLWRldmVsQGxpc3RzLnhlbnNvdXJjZS5jb20KPiBodHRwOi8vbGlzdHMueGVu
c291cmNlLmNvbS94ZW4tZGV2ZWwKCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVu
c291cmNlLmNvbQpodHRwOi8vbGlzdHMueGVuc291cmNlLmNvbS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Fri Dec 16 13:26:16 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 13: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.xensource.com>)
	id 1RbXnU-0006tg-Nu; Fri, 16 Dec 2011 13:26:00 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pasik@iki.fi>) id 1RbXnS-0006tF-Pu
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 13:25:59 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-3.tower-182.messagelabs.com!1324041952!7562437!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiAzODk1MjA=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6582 invoked from network); 16 Dec 2011 13:25:52 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-3.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Dec 2011 13:25:52 -0000
X-Originating-Ip: [194.89.68.22]
Received: from ydin.reaktio.net (reaktio.net [194.89.68.22])
	by smtp.tele.fi (Postfix) with ESMTP id 016282A7E;
	Fri, 16 Dec 2011 15:25:51 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id BA29B20056; Fri, 16 Dec 2011 15:25:51 +0200 (EET)
Date: Fri, 16 Dec 2011 15:25:51 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Paul Durrant <paul.durrant@citrix.com>
Message-ID: <20111216132551.GY12984@reaktio.net>
References: <patchbomb.1324036046@cosworth.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <patchbomb.1324036046@cosworth.uk.xensource.com>
User-Agent: Mutt/1.5.18 (2008-05-17)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 0 of 3] Support for VM generation
	ID	save/restore and migrate
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Dec 16, 2011 at 11:47:26AM +0000, Paul Durrant wrote:
> This patch series adds support for preservation of the VM generation ID buffer
> address in xenstore across save/restore and migrate, and also code to increment
> the value in all cases except for migration.
>

Sorry for a stupid question, but what's the usecase for this 'generation ID' ?

-- Pasi

> The first patch modifies creation of the hvmloader key in xenstore and adds
> creation of a new read/write hvmloader/generation-id-addr key.
> The second patch changes hvmloader to use the new key (as opposed to the old
> data/generation-id key).
> The third patch adds the infrastructure to save and restore the VM generation ID
> address in xenstore and the code to increment the value.
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 13:26:16 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 13: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.xensource.com>)
	id 1RbXnU-0006tg-Nu; Fri, 16 Dec 2011 13:26:00 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pasik@iki.fi>) id 1RbXnS-0006tF-Pu
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 13:25:59 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-3.tower-182.messagelabs.com!1324041952!7562437!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiAzODk1MjA=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6582 invoked from network); 16 Dec 2011 13:25:52 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-3.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Dec 2011 13:25:52 -0000
X-Originating-Ip: [194.89.68.22]
Received: from ydin.reaktio.net (reaktio.net [194.89.68.22])
	by smtp.tele.fi (Postfix) with ESMTP id 016282A7E;
	Fri, 16 Dec 2011 15:25:51 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id BA29B20056; Fri, 16 Dec 2011 15:25:51 +0200 (EET)
Date: Fri, 16 Dec 2011 15:25:51 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Paul Durrant <paul.durrant@citrix.com>
Message-ID: <20111216132551.GY12984@reaktio.net>
References: <patchbomb.1324036046@cosworth.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <patchbomb.1324036046@cosworth.uk.xensource.com>
User-Agent: Mutt/1.5.18 (2008-05-17)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 0 of 3] Support for VM generation
	ID	save/restore and migrate
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Dec 16, 2011 at 11:47:26AM +0000, Paul Durrant wrote:
> This patch series adds support for preservation of the VM generation ID buffer
> address in xenstore across save/restore and migrate, and also code to increment
> the value in all cases except for migration.
>

Sorry for a stupid question, but what's the usecase for this 'generation ID' ?

-- Pasi

> The first patch modifies creation of the hvmloader key in xenstore and adds
> creation of a new read/write hvmloader/generation-id-addr key.
> The second patch changes hvmloader to use the new key (as opposed to the old
> data/generation-id key).
> The third patch adds the infrastructure to save and restore the VM generation ID
> address in xenstore and the code to increment the value.
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 14:07:47 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 14:07:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbYRZ-0007b3-ED; Fri, 16 Dec 2011 14:07:25 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RbYRX-0007ay-M8
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 14:07:23 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1324044437!7639938!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjU3OQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22637 invoked from network); 16 Dec 2011 14:07:17 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Dec 2011 14:07:17 -0000
X-IronPort-AV: E=Sophos;i="4.71,363,1320624000"; 
   d="scan'208";a="9516084"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Dec 2011 14:07:17 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.161]) by
	LONPMAILMX01.citrite.net ([10.30.203.162]) with mapi; Fri, 16 Dec 2011
	14:07:17 +0000
From: Paul Durrant <Paul.Durrant@citrix.com>
To: =?iso-8859-1?Q?Pasi_K=E4rkk=E4inen?= <pasik@iki.fi>
Date: Fri, 16 Dec 2011 14:07:16 +0000
Thread-Topic: [Xen-devel] [PATCH 0 of 3] Support for VM generation ID
	save/restore and migrate
Thread-Index: Acy79lF2ISnL27h9Qn2cIs31J+b/wwABPv7Q
Message-ID: <291EDFCB1E9E224A99088639C4762022B598ED100B@LONPMAILBOX01.citrite.net>
References: <patchbomb.1324036046@cosworth.uk.xensource.com>
	<20111216132551.GY12984@reaktio.net>
In-Reply-To: <20111216132551.GY12984@reaktio.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 0 of 3] Support for VM generation
	ID	save/restore and migrate
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> -----Original Message-----
> From: Pasi K=E4rkk=E4inen [mailto:pasik@iki.fi]
> Sent: 16 December 2011 13:26
> To: Paul Durrant
> Cc: xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] [PATCH 0 of 3] Support for VM generation ID
> save/restore and migrate
> =

> On Fri, Dec 16, 2011 at 11:47:26AM +0000, Paul Durrant wrote:
> > This patch series adds support for preservation of the VM
> generation
> > ID buffer address in xenstore across save/restore and migrate, and
> > also code to increment the value in all cases except for
> migration.
> >
> =

> Sorry for a stupid question, but what's the usecase for this
> 'generation ID' ?
> =


Pasi,

  I did mention this before on 1st December. Here's what I said then:

"I already know there is one OS that consumes this interface and another
hypervisor that produces it but unfortunately I'm not at liberty to say
much more because I'm under NDA. Hopefully a spec. will be forthcoming
at some point."

  That really is all I believe I'm at liberty to say :-(

  Paul

> -- Pasi
> =

> > The first patch modifies creation of the hvmloader key in xenstore
> and
> > adds creation of a new read/write hvmloader/generation-id-addr
> key.
> > The second patch changes hvmloader to use the new key (as opposed
> to
> > the old data/generation-id key).
> > The third patch adds the infrastructure to save and restore the VM
> > generation ID address in xenstore and the code to increment the
> value.
> >
> >
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xensource.com
> > http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 14:07:47 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 14:07:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbYRZ-0007b3-ED; Fri, 16 Dec 2011 14:07:25 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RbYRX-0007ay-M8
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 14:07:23 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1324044437!7639938!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjU3OQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22637 invoked from network); 16 Dec 2011 14:07:17 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Dec 2011 14:07:17 -0000
X-IronPort-AV: E=Sophos;i="4.71,363,1320624000"; 
   d="scan'208";a="9516084"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Dec 2011 14:07:17 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.161]) by
	LONPMAILMX01.citrite.net ([10.30.203.162]) with mapi; Fri, 16 Dec 2011
	14:07:17 +0000
From: Paul Durrant <Paul.Durrant@citrix.com>
To: =?iso-8859-1?Q?Pasi_K=E4rkk=E4inen?= <pasik@iki.fi>
Date: Fri, 16 Dec 2011 14:07:16 +0000
Thread-Topic: [Xen-devel] [PATCH 0 of 3] Support for VM generation ID
	save/restore and migrate
Thread-Index: Acy79lF2ISnL27h9Qn2cIs31J+b/wwABPv7Q
Message-ID: <291EDFCB1E9E224A99088639C4762022B598ED100B@LONPMAILBOX01.citrite.net>
References: <patchbomb.1324036046@cosworth.uk.xensource.com>
	<20111216132551.GY12984@reaktio.net>
In-Reply-To: <20111216132551.GY12984@reaktio.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 0 of 3] Support for VM generation
	ID	save/restore and migrate
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> -----Original Message-----
> From: Pasi K=E4rkk=E4inen [mailto:pasik@iki.fi]
> Sent: 16 December 2011 13:26
> To: Paul Durrant
> Cc: xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] [PATCH 0 of 3] Support for VM generation ID
> save/restore and migrate
> =

> On Fri, Dec 16, 2011 at 11:47:26AM +0000, Paul Durrant wrote:
> > This patch series adds support for preservation of the VM
> generation
> > ID buffer address in xenstore across save/restore and migrate, and
> > also code to increment the value in all cases except for
> migration.
> >
> =

> Sorry for a stupid question, but what's the usecase for this
> 'generation ID' ?
> =


Pasi,

  I did mention this before on 1st December. Here's what I said then:

"I already know there is one OS that consumes this interface and another
hypervisor that produces it but unfortunately I'm not at liberty to say
much more because I'm under NDA. Hopefully a spec. will be forthcoming
at some point."

  That really is all I believe I'm at liberty to say :-(

  Paul

> -- Pasi
> =

> > The first patch modifies creation of the hvmloader key in xenstore
> and
> > adds creation of a new read/write hvmloader/generation-id-addr
> key.
> > The second patch changes hvmloader to use the new key (as opposed
> to
> > the old data/generation-id key).
> > The third patch adds the infrastructure to save and restore the VM
> > generation ID address in xenstore and the code to increment the
> value.
> >
> >
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xensource.com
> > http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 14:17:43 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 14:17:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbYb7-0007lD-Gg; Fri, 16 Dec 2011 14:17:17 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Boris.Ostrovsky@amd.com>) id 1RbYb6-0007l3-6J
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 14:17:16 +0000
X-Env-Sender: Boris.Ostrovsky@amd.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1324044994!57003470!1
X-Originating-IP: [65.55.88.14]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28822 invoked from network); 16 Dec 2011 14:16:36 -0000
Received: from tx2ehsobe004.messaging.microsoft.com (HELO
	TX2EHSOBE009.bigfish.com) (65.55.88.14)
	by server-9.tower-27.messagelabs.com with AES128-SHA encrypted SMTP;
	16 Dec 2011 14:16:36 -0000
Received: from mail95-tx2-R.bigfish.com (10.9.14.242) by
	TX2EHSOBE009.bigfish.com (10.9.40.29) with Microsoft SMTP Server id
	14.1.225.23; Fri, 16 Dec 2011 14:17:09 +0000
Received: from mail95-tx2 (localhost [127.0.0.1])	by mail95-tx2-R.bigfish.com
	(Postfix) with ESMTP id 568D3460682;
	Fri, 16 Dec 2011 14:17:25 +0000 (UTC)
X-SpamScore: -10
X-BigFish: VPS-10(zzbb2dI1432N98dKzz1202hzz8275bhz2dh668h839h61h)
X-Spam-TCS-SCL: 0:0
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
Received: from mail95-tx2 (localhost.localdomain [127.0.0.1]) by mail95-tx2
	(MessageSwitch) id 1324045044321892_7605;
	Fri, 16 Dec 2011 14:17:24 +0000 (UTC)
Received: from TX2EHSMHS004.bigfish.com (unknown [10.9.14.248])	by
	mail95-tx2.bigfish.com (Postfix) with ESMTP id C4BAB700099;
	Fri, 16 Dec 2011 14:16:26 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	TX2EHSMHS004.bigfish.com (10.9.99.104) with Microsoft SMTP Server id
	14.1.225.22; Fri, 16 Dec 2011 14:16:01 +0000
X-WSS-ID: 0LWAVMM-02-BA5-02
X-M-MSG: 
Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com
	[163.181.249.73])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp02.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2488FC808E;	Fri, 16 Dec 2011 08:15:58 -0600 (CST)
Received: from sausexhtp02.amd.com (163.181.3.152) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Fri, 16 Dec 2011 08:16:18 -0600
Received: from [10.234.222.67] (10.234.222.67) by sausexhtp02.amd.com
	(163.181.3.152) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 16 Dec 2011 08:16:00 -0600
Message-ID: <4EEB529F.5010204@amd.com>
Date: Fri, 16 Dec 2011 09:15:59 -0500
From: Boris Ostrovsky <boris.ostrovsky@amd.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.23) Gecko/20110920 SUSE/3.1.15 Thunderbird/3.1.15
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <mailman.4490.1323956364.12970.xen-devel@lists.xensource.com>
	<4EEA33CA.7030906@amd.com>
	<4EEB0ED402000078000686CE@nat28.tlf.novell.com>
In-Reply-To: <4EEB0ED402000078000686CE@nat28.tlf.novell.com>
X-OriginatorOrg: amd.com
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] x86/emulator: workaround for AMD erratum 573
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 12/16/11 03:26, Jan Beulich wrote:
>>>> On 15.12.11 at 18:52, Boris Ostrovsky<boris.ostrovsky@amd.com>  wrote:
>>> --- a/xen/include/asm-x86/amd.h
>>> +++ b/xen/include/asm-x86/amd.h
>>> @@ -134,6 +134,12 @@
>>>        AMD_OSVW_ERRATUM(3, AMD_MODEL_RANGE(0x10, 0x2, 0x1, 0xff, 0xf),	\
>>>    		        AMD_MODEL_RANGE(0x12, 0x0, 0x0, 0x1, 0x0))
>>>
>>> +#define AMD_ERRATUM_573							\
>>> +    AMD_LEGACY_ERRATUM(AMD_MODEL_RANGE(0x0f, 0x0, 0x0, 0xff, 0xf),	\
>>> +                       AMD_MODEL_RANGE(0x10, 0x0, 0x0, 0xff, 0xf),	\
>>> +                       AMD_MODEL_RANGE(0x11, 0x0, 0x0, 0xff, 0xf),	\
>>> +                       AMD_MODEL_RANGE(0x12, 0x0, 0x0, 0xff, 0xf))
>>
>> Families 0xf and 0x11 are not affected by erratum 573.
>
> Are you saying that these two documents
>
> 33610 Rev. 3.48 December 2011
> 41788 Rev. 3.10 December 2011
>
> both wrong? For fam 0xf it may be that we can set a lower bound for
> pre-NPT ones if those indeed are unaffected (but we'd like to be sure
> this is the case) - that would appear to be all with a model below 0x40.
>
> Please clarify.


Sorry, my bad. You are right --- somehow I thought it was only 10h and 12h.

-boris


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 14:17:43 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 14:17:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbYb7-0007lD-Gg; Fri, 16 Dec 2011 14:17:17 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Boris.Ostrovsky@amd.com>) id 1RbYb6-0007l3-6J
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 14:17:16 +0000
X-Env-Sender: Boris.Ostrovsky@amd.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1324044994!57003470!1
X-Originating-IP: [65.55.88.14]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28822 invoked from network); 16 Dec 2011 14:16:36 -0000
Received: from tx2ehsobe004.messaging.microsoft.com (HELO
	TX2EHSOBE009.bigfish.com) (65.55.88.14)
	by server-9.tower-27.messagelabs.com with AES128-SHA encrypted SMTP;
	16 Dec 2011 14:16:36 -0000
Received: from mail95-tx2-R.bigfish.com (10.9.14.242) by
	TX2EHSOBE009.bigfish.com (10.9.40.29) with Microsoft SMTP Server id
	14.1.225.23; Fri, 16 Dec 2011 14:17:09 +0000
Received: from mail95-tx2 (localhost [127.0.0.1])	by mail95-tx2-R.bigfish.com
	(Postfix) with ESMTP id 568D3460682;
	Fri, 16 Dec 2011 14:17:25 +0000 (UTC)
X-SpamScore: -10
X-BigFish: VPS-10(zzbb2dI1432N98dKzz1202hzz8275bhz2dh668h839h61h)
X-Spam-TCS-SCL: 0:0
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
Received: from mail95-tx2 (localhost.localdomain [127.0.0.1]) by mail95-tx2
	(MessageSwitch) id 1324045044321892_7605;
	Fri, 16 Dec 2011 14:17:24 +0000 (UTC)
Received: from TX2EHSMHS004.bigfish.com (unknown [10.9.14.248])	by
	mail95-tx2.bigfish.com (Postfix) with ESMTP id C4BAB700099;
	Fri, 16 Dec 2011 14:16:26 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	TX2EHSMHS004.bigfish.com (10.9.99.104) with Microsoft SMTP Server id
	14.1.225.22; Fri, 16 Dec 2011 14:16:01 +0000
X-WSS-ID: 0LWAVMM-02-BA5-02
X-M-MSG: 
Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com
	[163.181.249.73])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp02.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2488FC808E;	Fri, 16 Dec 2011 08:15:58 -0600 (CST)
Received: from sausexhtp02.amd.com (163.181.3.152) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Fri, 16 Dec 2011 08:16:18 -0600
Received: from [10.234.222.67] (10.234.222.67) by sausexhtp02.amd.com
	(163.181.3.152) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 16 Dec 2011 08:16:00 -0600
Message-ID: <4EEB529F.5010204@amd.com>
Date: Fri, 16 Dec 2011 09:15:59 -0500
From: Boris Ostrovsky <boris.ostrovsky@amd.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.23) Gecko/20110920 SUSE/3.1.15 Thunderbird/3.1.15
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <mailman.4490.1323956364.12970.xen-devel@lists.xensource.com>
	<4EEA33CA.7030906@amd.com>
	<4EEB0ED402000078000686CE@nat28.tlf.novell.com>
In-Reply-To: <4EEB0ED402000078000686CE@nat28.tlf.novell.com>
X-OriginatorOrg: amd.com
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] x86/emulator: workaround for AMD erratum 573
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 12/16/11 03:26, Jan Beulich wrote:
>>>> On 15.12.11 at 18:52, Boris Ostrovsky<boris.ostrovsky@amd.com>  wrote:
>>> --- a/xen/include/asm-x86/amd.h
>>> +++ b/xen/include/asm-x86/amd.h
>>> @@ -134,6 +134,12 @@
>>>        AMD_OSVW_ERRATUM(3, AMD_MODEL_RANGE(0x10, 0x2, 0x1, 0xff, 0xf),	\
>>>    		        AMD_MODEL_RANGE(0x12, 0x0, 0x0, 0x1, 0x0))
>>>
>>> +#define AMD_ERRATUM_573							\
>>> +    AMD_LEGACY_ERRATUM(AMD_MODEL_RANGE(0x0f, 0x0, 0x0, 0xff, 0xf),	\
>>> +                       AMD_MODEL_RANGE(0x10, 0x0, 0x0, 0xff, 0xf),	\
>>> +                       AMD_MODEL_RANGE(0x11, 0x0, 0x0, 0xff, 0xf),	\
>>> +                       AMD_MODEL_RANGE(0x12, 0x0, 0x0, 0xff, 0xf))
>>
>> Families 0xf and 0x11 are not affected by erratum 573.
>
> Are you saying that these two documents
>
> 33610 Rev. 3.48 December 2011
> 41788 Rev. 3.10 December 2011
>
> both wrong? For fam 0xf it may be that we can set a lower bound for
> pre-NPT ones if those indeed are unaffected (but we'd like to be sure
> this is the case) - that would appear to be all with a model below 0x40.
>
> Please clarify.


Sorry, my bad. You are right --- somehow I thought it was only 10h and 12h.

-boris


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 14:32:48 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 14:32:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbYpc-00080Y-V0; Fri, 16 Dec 2011 14:32:16 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pasik@iki.fi>) id 1RbYpb-00080B-BS
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 14:32:15 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-5.tower-21.messagelabs.com!1324045928!2240562!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiAzODk1MjA=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22711 invoked from network); 16 Dec 2011 14:32:08 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-5.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Dec 2011 14:32:08 -0000
X-Originating-Ip: [194.89.68.22]
Received: from ydin.reaktio.net (reaktio.net [194.89.68.22])
	by smtp.tele.fi (Postfix) with ESMTP id 43A4D232D;
	Fri, 16 Dec 2011 16:32:07 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id E003320056; Fri, 16 Dec 2011 16:32:06 +0200 (EET)
Date: Fri, 16 Dec 2011 16:32:06 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Paul Durrant <Paul.Durrant@citrix.com>
Message-ID: <20111216143206.GA12984@reaktio.net>
References: <patchbomb.1324036046@cosworth.uk.xensource.com>
	<20111216132551.GY12984@reaktio.net>
	<291EDFCB1E9E224A99088639C4762022B598ED100B@LONPMAILBOX01.citrite.net>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <291EDFCB1E9E224A99088639C4762022B598ED100B@LONPMAILBOX01.citrite.net>
User-Agent: Mutt/1.5.18 (2008-05-17)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 0 of 3] Support for VM generation
	ID	save/restore and migrate
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Dec 16, 2011 at 02:07:16PM +0000, Paul Durrant wrote:
> > -----Original Message-----
> > From: Pasi K=E4rkk=E4inen [mailto:pasik@iki.fi]
> > Sent: 16 December 2011 13:26
> > To: Paul Durrant
> > Cc: xen-devel@lists.xensource.com
> > Subject: Re: [Xen-devel] [PATCH 0 of 3] Support for VM generation ID
> > save/restore and migrate
> > =

> > On Fri, Dec 16, 2011 at 11:47:26AM +0000, Paul Durrant wrote:
> > > This patch series adds support for preservation of the VM
> > generation
> > > ID buffer address in xenstore across save/restore and migrate, and
> > > also code to increment the value in all cases except for
> > migration.
> > >
> > =

> > Sorry for a stupid question, but what's the usecase for this
> > 'generation ID' ?
> > =

> =

> Pasi,
> =

>   I did mention this before on 1st December. Here's what I said then:
> =

> "I already know there is one OS that consumes this interface and another
> hypervisor that produces it but unfortunately I'm not at liberty to say
> much more because I'm under NDA. Hopefully a spec. will be forthcoming
> at some point."
> =

>   That really is all I believe I'm at liberty to say :-(
> =


Oh, OK. I missed that comment..
Thanks for the info :) =


-- Pasi


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 14:32:48 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 14:32:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbYpc-00080Y-V0; Fri, 16 Dec 2011 14:32:16 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pasik@iki.fi>) id 1RbYpb-00080B-BS
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 14:32:15 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-5.tower-21.messagelabs.com!1324045928!2240562!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiAzODk1MjA=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22711 invoked from network); 16 Dec 2011 14:32:08 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-5.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Dec 2011 14:32:08 -0000
X-Originating-Ip: [194.89.68.22]
Received: from ydin.reaktio.net (reaktio.net [194.89.68.22])
	by smtp.tele.fi (Postfix) with ESMTP id 43A4D232D;
	Fri, 16 Dec 2011 16:32:07 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id E003320056; Fri, 16 Dec 2011 16:32:06 +0200 (EET)
Date: Fri, 16 Dec 2011 16:32:06 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Paul Durrant <Paul.Durrant@citrix.com>
Message-ID: <20111216143206.GA12984@reaktio.net>
References: <patchbomb.1324036046@cosworth.uk.xensource.com>
	<20111216132551.GY12984@reaktio.net>
	<291EDFCB1E9E224A99088639C4762022B598ED100B@LONPMAILBOX01.citrite.net>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <291EDFCB1E9E224A99088639C4762022B598ED100B@LONPMAILBOX01.citrite.net>
User-Agent: Mutt/1.5.18 (2008-05-17)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 0 of 3] Support for VM generation
	ID	save/restore and migrate
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Dec 16, 2011 at 02:07:16PM +0000, Paul Durrant wrote:
> > -----Original Message-----
> > From: Pasi K=E4rkk=E4inen [mailto:pasik@iki.fi]
> > Sent: 16 December 2011 13:26
> > To: Paul Durrant
> > Cc: xen-devel@lists.xensource.com
> > Subject: Re: [Xen-devel] [PATCH 0 of 3] Support for VM generation ID
> > save/restore and migrate
> > =

> > On Fri, Dec 16, 2011 at 11:47:26AM +0000, Paul Durrant wrote:
> > > This patch series adds support for preservation of the VM
> > generation
> > > ID buffer address in xenstore across save/restore and migrate, and
> > > also code to increment the value in all cases except for
> > migration.
> > >
> > =

> > Sorry for a stupid question, but what's the usecase for this
> > 'generation ID' ?
> > =

> =

> Pasi,
> =

>   I did mention this before on 1st December. Here's what I said then:
> =

> "I already know there is one OS that consumes this interface and another
> hypervisor that produces it but unfortunately I'm not at liberty to say
> much more because I'm under NDA. Hopefully a spec. will be forthcoming
> at some point."
> =

>   That really is all I believe I'm at liberty to say :-(
> =


Oh, OK. I missed that comment..
Thanks for the info :) =


-- Pasi


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 14:44:13 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 14:44:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbZ0k-0008EQ-C1; Fri, 16 Dec 2011 14:43:46 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RbZ0j-0008EL-E3
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 14:43:45 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1324046619!6565319!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17524 invoked from network); 16 Dec 2011 14:43:39 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-13.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 16 Dec 2011 14:43:39 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 16 Dec 2011 14:43:38 +0000
Message-Id: <4EEB676102000078000687FA@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 16 Dec 2011 14:44:33 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Keir Fraser" <keir.xen@gmail.com>
References: <4EE9D92A020000780006813A@nat28.tlf.novell.com>
	<CB10BB40.27633%keir.xen@gmail.com>
In-Reply-To: <CB10BB40.27633%keir.xen@gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] x86: convert BUG_ON()s to WARN_ON()s in
 read_descriptor()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 16.12.11 at 10:09, Keir Fraser <keir.xen@gmail.com> wrote:
> On 15/12/2011 10:25, "Jan Beulich" <JBeulich@suse.com> wrote:
> 
>> In the light of AMD erratum #700, and given that these checks happen
>> for debugging purposes only and also only in debug builds of the
>> hypervisor, make the failures non-fatal.
> 
> I think the changeset comment should have a brief description of erratum
> #700.

I'd do this, but ...

> I also some reference should be made in a comment above the first
> WARN_ON, explaining why they are now WARN_Ons (again, with reference to #700
> and its symptoms).

... I now think that these should never have been BUG_ON()s in the
first place (despite probably having been the one who introduced
them).

Additionally, on a second look, check_descriptor() would not allow any
of the affected selector types to be installed into a descriptor table,
and we clearly don't put in any such descriptors ourselves, so from the
perspective of the erratum we're okay without the patch.

So if you prefer them to stay BUG_ON(), I think I'll just withdraw the
patch.

Jan

> Apart from that:
> Acked-by: Keir Fraser <keir@xen.org>
> 
>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>> 
>> --- a/xen/arch/x86/traps.c
>> +++ b/xen/arch/x86/traps.c
>> @@ -1544,11 +1544,11 @@ static int read_descriptor(unsigned int
>>              asm volatile (
>>                  "larl %2,%0 ; setz %1"
>>                  : "=r" (a), "=qm" (valid) : "rm" (sel));
>> -            BUG_ON(valid && ((a & 0x00f0ff00) != *ar));
>> +            WARN_ON(valid && ((a & 0x00f0ff00) != *ar));
>>              asm volatile (
>>                  "lsll %2,%0 ; setz %1"
>>                  : "=r" (l), "=qm" (valid) : "rm" (sel));
>> -            BUG_ON(valid && (l != *limit));
>> +            WARN_ON(valid && (l != *limit));
>>          }
>>  #endif
>>      }
>> 
>> 
>> 
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com 
>> http://lists.xensource.com/xen-devel 




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 14:44:13 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 14:44:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbZ0k-0008EQ-C1; Fri, 16 Dec 2011 14:43:46 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RbZ0j-0008EL-E3
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 14:43:45 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1324046619!6565319!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17524 invoked from network); 16 Dec 2011 14:43:39 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-13.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 16 Dec 2011 14:43:39 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 16 Dec 2011 14:43:38 +0000
Message-Id: <4EEB676102000078000687FA@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 16 Dec 2011 14:44:33 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Keir Fraser" <keir.xen@gmail.com>
References: <4EE9D92A020000780006813A@nat28.tlf.novell.com>
	<CB10BB40.27633%keir.xen@gmail.com>
In-Reply-To: <CB10BB40.27633%keir.xen@gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] x86: convert BUG_ON()s to WARN_ON()s in
 read_descriptor()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 16.12.11 at 10:09, Keir Fraser <keir.xen@gmail.com> wrote:
> On 15/12/2011 10:25, "Jan Beulich" <JBeulich@suse.com> wrote:
> 
>> In the light of AMD erratum #700, and given that these checks happen
>> for debugging purposes only and also only in debug builds of the
>> hypervisor, make the failures non-fatal.
> 
> I think the changeset comment should have a brief description of erratum
> #700.

I'd do this, but ...

> I also some reference should be made in a comment above the first
> WARN_ON, explaining why they are now WARN_Ons (again, with reference to #700
> and its symptoms).

... I now think that these should never have been BUG_ON()s in the
first place (despite probably having been the one who introduced
them).

Additionally, on a second look, check_descriptor() would not allow any
of the affected selector types to be installed into a descriptor table,
and we clearly don't put in any such descriptors ourselves, so from the
perspective of the erratum we're okay without the patch.

So if you prefer them to stay BUG_ON(), I think I'll just withdraw the
patch.

Jan

> Apart from that:
> Acked-by: Keir Fraser <keir@xen.org>
> 
>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>> 
>> --- a/xen/arch/x86/traps.c
>> +++ b/xen/arch/x86/traps.c
>> @@ -1544,11 +1544,11 @@ static int read_descriptor(unsigned int
>>              asm volatile (
>>                  "larl %2,%0 ; setz %1"
>>                  : "=r" (a), "=qm" (valid) : "rm" (sel));
>> -            BUG_ON(valid && ((a & 0x00f0ff00) != *ar));
>> +            WARN_ON(valid && ((a & 0x00f0ff00) != *ar));
>>              asm volatile (
>>                  "lsll %2,%0 ; setz %1"
>>                  : "=r" (l), "=qm" (valid) : "rm" (sel));
>> -            BUG_ON(valid && (l != *limit));
>> +            WARN_ON(valid && (l != *limit));
>>          }
>>  #endif
>>      }
>> 
>> 
>> 
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com 
>> http://lists.xensource.com/xen-devel 




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 14:45:26 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 14:45:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbZ1u-0008HK-RT; Fri, 16 Dec 2011 14:44:58 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RbZ1t-0008Gw-1l
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 14:44:57 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1324046691!7728498!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjU3OQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9378 invoked from network); 16 Dec 2011 14:44:51 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Dec 2011 14:44:51 -0000
X-IronPort-AV: E=Sophos;i="4.71,363,1320624000"; 
   d="scan'208";a="9517259"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Dec 2011 14:44:50 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 16 Dec 2011 14:44:50 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RbZ1m-0006GP-I4; Fri, 16 Dec 2011 14:44:50 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RbZ1m-0004Y1-HC;
	Fri, 16 Dec 2011 14:44:50 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20203.22882.367878.751200@mariner.uk.xensource.com>
Date: Fri, 16 Dec 2011 14:44:50 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1324028035.20077.531.camel@zakaz.uk.xensource.com>
References: <patchbomb.1323792779@cosworth.uk.xensource.com>
	<f4586d1a539c869e31fa.1323792781@cosworth.uk.xensource.com>
	<20202.9800.381383.266900@mariner.uk.xensource.com>
	<1323968201.20077.498.camel@zakaz.uk.xensource.com>
	<1324028035.20077.531.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Olaf Hering <olaf@aepfle.de>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Vincent Hanquez <Vincent.Hanquez@eu.citrix.com>,
	Jonathan Ludlam <Jonathan.Ludlam@eu.citrix.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH 2 of 4 V2] Linux/xencommons: Use oxenstored
 by default when available
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("Re: [Xen-devel] [PATCH 2 of 4 V2] Linux/xencommons: Use oxenstored by default when available"):
> On Thu, 2011-12-15 at 16:56 +0000, Ian Campbell wrote:
> > On Thu, 2011-12-15 at 16:54 +0000, Ian Jackson wrote:
> > > I've applied #1, #3, and #4.  I'll wait with #2 until my test system
> > > gets a pass and push on the change to collect the oxenstored logs.
> > 
> > Sounds good. Thanks.
> 
> But did you see my response re: /var/log/xenstored.conf
> vs /var/log/xenstored.log in
> <1323963349.20077.494.camel@zakaz.uk.xensource.com> ?

Yes :-).

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 14:45:26 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 14:45:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbZ1u-0008HK-RT; Fri, 16 Dec 2011 14:44:58 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RbZ1t-0008Gw-1l
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 14:44:57 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1324046691!7728498!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjU3OQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9378 invoked from network); 16 Dec 2011 14:44:51 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Dec 2011 14:44:51 -0000
X-IronPort-AV: E=Sophos;i="4.71,363,1320624000"; 
   d="scan'208";a="9517259"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Dec 2011 14:44:50 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 16 Dec 2011 14:44:50 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RbZ1m-0006GP-I4; Fri, 16 Dec 2011 14:44:50 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RbZ1m-0004Y1-HC;
	Fri, 16 Dec 2011 14:44:50 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20203.22882.367878.751200@mariner.uk.xensource.com>
Date: Fri, 16 Dec 2011 14:44:50 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1324028035.20077.531.camel@zakaz.uk.xensource.com>
References: <patchbomb.1323792779@cosworth.uk.xensource.com>
	<f4586d1a539c869e31fa.1323792781@cosworth.uk.xensource.com>
	<20202.9800.381383.266900@mariner.uk.xensource.com>
	<1323968201.20077.498.camel@zakaz.uk.xensource.com>
	<1324028035.20077.531.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Olaf Hering <olaf@aepfle.de>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Vincent Hanquez <Vincent.Hanquez@eu.citrix.com>,
	Jonathan Ludlam <Jonathan.Ludlam@eu.citrix.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH 2 of 4 V2] Linux/xencommons: Use oxenstored
 by default when available
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("Re: [Xen-devel] [PATCH 2 of 4 V2] Linux/xencommons: Use oxenstored by default when available"):
> On Thu, 2011-12-15 at 16:56 +0000, Ian Campbell wrote:
> > On Thu, 2011-12-15 at 16:54 +0000, Ian Jackson wrote:
> > > I've applied #1, #3, and #4.  I'll wait with #2 until my test system
> > > gets a pass and push on the change to collect the oxenstored logs.
> > 
> > Sounds good. Thanks.
> 
> But did you see my response re: /var/log/xenstored.conf
> vs /var/log/xenstored.log in
> <1323963349.20077.494.camel@zakaz.uk.xensource.com> ?

Yes :-).

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 14:45:54 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 14:45:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbZ2X-0008KE-9e; Fri, 16 Dec 2011 14:45:37 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <gbtux@126.com>) id 1RbZ2U-0008JV-Tp
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 14:45:36 +0000
X-Env-Sender: gbtux@126.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1324046725!7152399!1
X-Originating-IP: [220.181.15.34]
X-SpamReason: No, hits=1.1 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMjAuMTgxLjE1LjM0ID0+IDY3MTE=\n,sa_preprocessor: 
	QmFkIElQOiAyMjAuMTgxLjE1LjM0ID0+IDY3MTE=\n, BODY_RANDOM_LONG, HTML_40_50,
	HTML_MESSAGE
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4754 invoked from network); 16 Dec 2011 14:45:27 -0000
Received: from m15-34.126.com (HELO m15-34.126.com) (220.181.15.34)
	by server-13.tower-216.messagelabs.com with SMTP;
	16 Dec 2011 14:45:27 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=126.com;
	s=s110527; h=Received:Date:From:To:Cc:Message-ID:In-Reply-To:
	References:Subject:MIME-Version:Content-Type; bh=eOtI1tQD7G33GeZ
	qP1v8Caa+YtZ1FTrtAi/UwPRidxs=; b=jyvx+q12svUA/QvveC+hYacC/DCdBE3
	T/ACSDETx+A6XA5aZFoo0HY++o7tgt4TGgQAmglPQIPho1DaxQ5eEY+mlG9D2qhe
	DuSZ+D3OSedM0ovhwI+/za84Y5JKjIZg8nQyrNzhGRDuCbdD6qdOQXc+RP7gsv3c
	VR/grCL77zag=
Received: from gbtux ( [124.16.139.196] ) by ajax-webmail-wmsvr34 (Coremail)
	; Fri, 16 Dec 2011 22:44:54 +0800 (CST)
Date: Fri, 16 Dec 2011 22:44:54 +0800 (CST)
From: gavin  <gbtux@126.com>
To: "George Dunlap" <George.Dunlap@eu.citrix.com>
Message-ID: <676b608e.2fb26.13447553671.Coremail.gbtux@126.com>
In-Reply-To: <CAFLBxZYM-8vEc5Egmv+iXqMDUE_UJcgHbwr7=71H-kFowTzXWA@mail.gmail.com>
References: <CAFLBxZYM-8vEc5Egmv+iXqMDUE_UJcgHbwr7=71H-kFowTzXWA@mail.gmail.com>
	<26c93838.3b3fb.13445de0e67.Coremail.gbtux@126.com>
MIME-Version: 1.0
X-Originating-IP: [124.16.139.196]
X-Priority: 3
X-Mailer: Coremail Webmail Server Version SP_ntes V3.5 build
	111202(16086.4213.4207) Copyright (c) 2002-2011 www.mailtech.cn 126com
X-CM-CTRLDATA: mRuQCmZvb3Rlcl9odG09MjYxNTo4MQ==
X-CM-TRANSID: IsqowEBJ1EF8WetO560aAA--.1140W
X-CM-SenderInfo: pjew35a6rslhhfrp/1tbiOgQYnE50yaWnkQAAsa
X-Coremail-Antispam: 1U5529EdanIXcx71UUUUU7vcSsGvfC2KfnxnUU==
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] A question on the credit scheduler
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============9007817294162305594=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============9007817294162305594==
Content-Type: multipart/alternative; 
	boundary="----=_Part_551282_1275005648.1324046694000"

------=_Part_551282_1275005648.1324046694000
Content-Type: text/plain; charset=GBK
Content-Transfer-Encoding: 7bit

At 2011-12-16 19:04:19,"George Dunlap" <George.Dunlap@eu.citrix.com> wrote:>2011/12/16 zhikai <gbtux@126.com>:
>> Hi All,
>>
>> In the credit scheduler, the scheduling decision function csched_schedule()
>> is called in the schedule function in scheduler.c, such as the following.
>> next_slice = sched->do_schedule(sched, now, tasklet_work_scheduled);
>>
>> But, how often the csched_schedule() is called and to run? Does this
>> frequency have something to do with the slice of credit scheduler that is
>> 30ms?
>
>The scheduler runs whenever the SCHEDULE_SOFTIRQ is raised.  If you
>grep through the source code fro that string, you can find all the
>places where it's raised.
>
>Some examples include:
>* When the 30ms timeslice is finished
>* When a sleeping vcpu of higher priority than what's currently running wakes up
>* When a vcpu blocks
>* When a vcpu is migrated from one cpu to another
>
>30ms is actually a pretty long time; in typical workloads, vcpus block
>or are preempted by other waking vcpus without using up their full
>timeslice.


Thank you very much for your reply.
So, the vcpu is very likely to be preempted whenever the SCHEDULE_SOFTIRQ is raised. And we cannot find a small timeslice, such as a(ms), which makes the time any vcpu spending on running phase is k*a(ms), k is integer here. There is no such a small timeslice. Is it right?


Best Regards,
Gavin


>
> -George
>
>_______________________________________________
>Xen-devel mailing list
>Xen-devel@lists.xensource.com
>http://lists.xensource.com/xen-devel

------=_Part_551282_1275005648.1324046694000
Content-Type: text/html; charset=GBK
Content-Transfer-Encoding: 7bit

<div style="line-height:1.7;color:#000000;font-size:14px;font-family:arial"><pre>At&nbsp;2011-12-16&nbsp;19:04:19,"George&nbsp;Dunlap"&nbsp;&lt;George.Dunlap@eu.citrix.com&gt;&nbsp;wrote:</pre><pre>&gt;2011/12/16&nbsp;zhikai&nbsp;&lt;gbtux@126.com&gt;:
&gt;&gt;&nbsp;Hi&nbsp;All,
&gt;&gt;
&gt;&gt;&nbsp;In&nbsp;the&nbsp;credit&nbsp;scheduler,&nbsp;the&nbsp;scheduling&nbsp;decision&nbsp;function&nbsp;csched_schedule()
&gt;&gt;&nbsp;is&nbsp;called&nbsp;in&nbsp;the&nbsp;schedule&nbsp;function&nbsp;in&nbsp;scheduler.c,&nbsp;such&nbsp;as&nbsp;the&nbsp;following.
&gt;&gt;&nbsp;next_slice&nbsp;=&nbsp;sched-&gt;do_schedule(sched,&nbsp;now,&nbsp;tasklet_work_scheduled);
&gt;&gt;
&gt;&gt;&nbsp;But,&nbsp;how&nbsp;often&nbsp;the&nbsp;csched_schedule()&nbsp;is&nbsp;called&nbsp;and&nbsp;to&nbsp;run?&nbsp;Does&nbsp;this
&gt;&gt;&nbsp;frequency&nbsp;have&nbsp;something&nbsp;to&nbsp;do&nbsp;with&nbsp;the&nbsp;slice&nbsp;of&nbsp;credit&nbsp;scheduler&nbsp;that&nbsp;is
&gt;&gt;&nbsp;30ms?
&gt;
&gt;The&nbsp;scheduler&nbsp;runs&nbsp;whenever&nbsp;the&nbsp;SCHEDULE_SOFTIRQ&nbsp;is&nbsp;raised.&nbsp;&nbsp;If&nbsp;you
&gt;grep&nbsp;through&nbsp;the&nbsp;source&nbsp;code&nbsp;fro&nbsp;that&nbsp;string,&nbsp;you&nbsp;can&nbsp;find&nbsp;all&nbsp;the
&gt;places&nbsp;where&nbsp;it's&nbsp;raised.
&gt;
&gt;Some&nbsp;examples&nbsp;include:
&gt;*&nbsp;When&nbsp;the&nbsp;30ms&nbsp;timeslice&nbsp;is&nbsp;finished
&gt;*&nbsp;When&nbsp;a&nbsp;sleeping&nbsp;vcpu&nbsp;of&nbsp;higher&nbsp;priority&nbsp;than&nbsp;what's&nbsp;currently&nbsp;running&nbsp;wakes&nbsp;up
&gt;*&nbsp;When&nbsp;a&nbsp;vcpu&nbsp;blocks
&gt;*&nbsp;When&nbsp;a&nbsp;vcpu&nbsp;is&nbsp;migrated&nbsp;from&nbsp;one&nbsp;cpu&nbsp;to&nbsp;another
&gt;
&gt;30ms&nbsp;is&nbsp;actually&nbsp;a&nbsp;pretty&nbsp;long&nbsp;time;&nbsp;in&nbsp;typical&nbsp;workloads,&nbsp;vcpus&nbsp;block
&gt;or&nbsp;are&nbsp;preempted&nbsp;by&nbsp;other&nbsp;waking&nbsp;vcpus&nbsp;without&nbsp;using&nbsp;up&nbsp;their&nbsp;full
&gt;timeslice.
<br></pre><pre><pre>Thank you very much for your reply.</pre><pre>So, the vcpu is very likely to be preempted whenever the SCHEDULE_SOFTIRQ&nbsp;is raised. And we cannot find a small timeslice, such as a(ms), which makes the time any vcpu spending on&nbsp;running phase is k*a(ms), k is integer here. There is no such a small timeslice. Is it right?</pre><pre><br></pre><pre>Best Regards,</pre><pre>Gavin</pre></pre><pre><br></pre><pre>&gt;
&gt;&nbsp;-George
&gt;
&gt;_______________________________________________
&gt;Xen-devel&nbsp;mailing&nbsp;list
&gt;Xen-devel@lists.xensource.com
&gt;http://lists.xensource.com/xen-devel
</pre></div><br><br><span title="neteasefooter"><span id="netease_mail_footer"></span></span>
------=_Part_551282_1275005648.1324046694000--



--===============9007817294162305594==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============9007817294162305594==--



From xen-devel-bounces@lists.xensource.com Fri Dec 16 14:45:54 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 14:45:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbZ2X-0008KE-9e; Fri, 16 Dec 2011 14:45:37 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <gbtux@126.com>) id 1RbZ2U-0008JV-Tp
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 14:45:36 +0000
X-Env-Sender: gbtux@126.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1324046725!7152399!1
X-Originating-IP: [220.181.15.34]
X-SpamReason: No, hits=1.1 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMjAuMTgxLjE1LjM0ID0+IDY3MTE=\n,sa_preprocessor: 
	QmFkIElQOiAyMjAuMTgxLjE1LjM0ID0+IDY3MTE=\n, BODY_RANDOM_LONG, HTML_40_50,
	HTML_MESSAGE
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4754 invoked from network); 16 Dec 2011 14:45:27 -0000
Received: from m15-34.126.com (HELO m15-34.126.com) (220.181.15.34)
	by server-13.tower-216.messagelabs.com with SMTP;
	16 Dec 2011 14:45:27 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=126.com;
	s=s110527; h=Received:Date:From:To:Cc:Message-ID:In-Reply-To:
	References:Subject:MIME-Version:Content-Type; bh=eOtI1tQD7G33GeZ
	qP1v8Caa+YtZ1FTrtAi/UwPRidxs=; b=jyvx+q12svUA/QvveC+hYacC/DCdBE3
	T/ACSDETx+A6XA5aZFoo0HY++o7tgt4TGgQAmglPQIPho1DaxQ5eEY+mlG9D2qhe
	DuSZ+D3OSedM0ovhwI+/za84Y5JKjIZg8nQyrNzhGRDuCbdD6qdOQXc+RP7gsv3c
	VR/grCL77zag=
Received: from gbtux ( [124.16.139.196] ) by ajax-webmail-wmsvr34 (Coremail)
	; Fri, 16 Dec 2011 22:44:54 +0800 (CST)
Date: Fri, 16 Dec 2011 22:44:54 +0800 (CST)
From: gavin  <gbtux@126.com>
To: "George Dunlap" <George.Dunlap@eu.citrix.com>
Message-ID: <676b608e.2fb26.13447553671.Coremail.gbtux@126.com>
In-Reply-To: <CAFLBxZYM-8vEc5Egmv+iXqMDUE_UJcgHbwr7=71H-kFowTzXWA@mail.gmail.com>
References: <CAFLBxZYM-8vEc5Egmv+iXqMDUE_UJcgHbwr7=71H-kFowTzXWA@mail.gmail.com>
	<26c93838.3b3fb.13445de0e67.Coremail.gbtux@126.com>
MIME-Version: 1.0
X-Originating-IP: [124.16.139.196]
X-Priority: 3
X-Mailer: Coremail Webmail Server Version SP_ntes V3.5 build
	111202(16086.4213.4207) Copyright (c) 2002-2011 www.mailtech.cn 126com
X-CM-CTRLDATA: mRuQCmZvb3Rlcl9odG09MjYxNTo4MQ==
X-CM-TRANSID: IsqowEBJ1EF8WetO560aAA--.1140W
X-CM-SenderInfo: pjew35a6rslhhfrp/1tbiOgQYnE50yaWnkQAAsa
X-Coremail-Antispam: 1U5529EdanIXcx71UUUUU7vcSsGvfC2KfnxnUU==
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] A question on the credit scheduler
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============9007817294162305594=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============9007817294162305594==
Content-Type: multipart/alternative; 
	boundary="----=_Part_551282_1275005648.1324046694000"

------=_Part_551282_1275005648.1324046694000
Content-Type: text/plain; charset=GBK
Content-Transfer-Encoding: 7bit

At 2011-12-16 19:04:19,"George Dunlap" <George.Dunlap@eu.citrix.com> wrote:>2011/12/16 zhikai <gbtux@126.com>:
>> Hi All,
>>
>> In the credit scheduler, the scheduling decision function csched_schedule()
>> is called in the schedule function in scheduler.c, such as the following.
>> next_slice = sched->do_schedule(sched, now, tasklet_work_scheduled);
>>
>> But, how often the csched_schedule() is called and to run? Does this
>> frequency have something to do with the slice of credit scheduler that is
>> 30ms?
>
>The scheduler runs whenever the SCHEDULE_SOFTIRQ is raised.  If you
>grep through the source code fro that string, you can find all the
>places where it's raised.
>
>Some examples include:
>* When the 30ms timeslice is finished
>* When a sleeping vcpu of higher priority than what's currently running wakes up
>* When a vcpu blocks
>* When a vcpu is migrated from one cpu to another
>
>30ms is actually a pretty long time; in typical workloads, vcpus block
>or are preempted by other waking vcpus without using up their full
>timeslice.


Thank you very much for your reply.
So, the vcpu is very likely to be preempted whenever the SCHEDULE_SOFTIRQ is raised. And we cannot find a small timeslice, such as a(ms), which makes the time any vcpu spending on running phase is k*a(ms), k is integer here. There is no such a small timeslice. Is it right?


Best Regards,
Gavin


>
> -George
>
>_______________________________________________
>Xen-devel mailing list
>Xen-devel@lists.xensource.com
>http://lists.xensource.com/xen-devel

------=_Part_551282_1275005648.1324046694000
Content-Type: text/html; charset=GBK
Content-Transfer-Encoding: 7bit

<div style="line-height:1.7;color:#000000;font-size:14px;font-family:arial"><pre>At&nbsp;2011-12-16&nbsp;19:04:19,"George&nbsp;Dunlap"&nbsp;&lt;George.Dunlap@eu.citrix.com&gt;&nbsp;wrote:</pre><pre>&gt;2011/12/16&nbsp;zhikai&nbsp;&lt;gbtux@126.com&gt;:
&gt;&gt;&nbsp;Hi&nbsp;All,
&gt;&gt;
&gt;&gt;&nbsp;In&nbsp;the&nbsp;credit&nbsp;scheduler,&nbsp;the&nbsp;scheduling&nbsp;decision&nbsp;function&nbsp;csched_schedule()
&gt;&gt;&nbsp;is&nbsp;called&nbsp;in&nbsp;the&nbsp;schedule&nbsp;function&nbsp;in&nbsp;scheduler.c,&nbsp;such&nbsp;as&nbsp;the&nbsp;following.
&gt;&gt;&nbsp;next_slice&nbsp;=&nbsp;sched-&gt;do_schedule(sched,&nbsp;now,&nbsp;tasklet_work_scheduled);
&gt;&gt;
&gt;&gt;&nbsp;But,&nbsp;how&nbsp;often&nbsp;the&nbsp;csched_schedule()&nbsp;is&nbsp;called&nbsp;and&nbsp;to&nbsp;run?&nbsp;Does&nbsp;this
&gt;&gt;&nbsp;frequency&nbsp;have&nbsp;something&nbsp;to&nbsp;do&nbsp;with&nbsp;the&nbsp;slice&nbsp;of&nbsp;credit&nbsp;scheduler&nbsp;that&nbsp;is
&gt;&gt;&nbsp;30ms?
&gt;
&gt;The&nbsp;scheduler&nbsp;runs&nbsp;whenever&nbsp;the&nbsp;SCHEDULE_SOFTIRQ&nbsp;is&nbsp;raised.&nbsp;&nbsp;If&nbsp;you
&gt;grep&nbsp;through&nbsp;the&nbsp;source&nbsp;code&nbsp;fro&nbsp;that&nbsp;string,&nbsp;you&nbsp;can&nbsp;find&nbsp;all&nbsp;the
&gt;places&nbsp;where&nbsp;it's&nbsp;raised.
&gt;
&gt;Some&nbsp;examples&nbsp;include:
&gt;*&nbsp;When&nbsp;the&nbsp;30ms&nbsp;timeslice&nbsp;is&nbsp;finished
&gt;*&nbsp;When&nbsp;a&nbsp;sleeping&nbsp;vcpu&nbsp;of&nbsp;higher&nbsp;priority&nbsp;than&nbsp;what's&nbsp;currently&nbsp;running&nbsp;wakes&nbsp;up
&gt;*&nbsp;When&nbsp;a&nbsp;vcpu&nbsp;blocks
&gt;*&nbsp;When&nbsp;a&nbsp;vcpu&nbsp;is&nbsp;migrated&nbsp;from&nbsp;one&nbsp;cpu&nbsp;to&nbsp;another
&gt;
&gt;30ms&nbsp;is&nbsp;actually&nbsp;a&nbsp;pretty&nbsp;long&nbsp;time;&nbsp;in&nbsp;typical&nbsp;workloads,&nbsp;vcpus&nbsp;block
&gt;or&nbsp;are&nbsp;preempted&nbsp;by&nbsp;other&nbsp;waking&nbsp;vcpus&nbsp;without&nbsp;using&nbsp;up&nbsp;their&nbsp;full
&gt;timeslice.
<br></pre><pre><pre>Thank you very much for your reply.</pre><pre>So, the vcpu is very likely to be preempted whenever the SCHEDULE_SOFTIRQ&nbsp;is raised. And we cannot find a small timeslice, such as a(ms), which makes the time any vcpu spending on&nbsp;running phase is k*a(ms), k is integer here. There is no such a small timeslice. Is it right?</pre><pre><br></pre><pre>Best Regards,</pre><pre>Gavin</pre></pre><pre><br></pre><pre>&gt;
&gt;&nbsp;-George
&gt;
&gt;_______________________________________________
&gt;Xen-devel&nbsp;mailing&nbsp;list
&gt;Xen-devel@lists.xensource.com
&gt;http://lists.xensource.com/xen-devel
</pre></div><br><br><span title="neteasefooter"><span id="netease_mail_footer"></span></span>
------=_Part_551282_1275005648.1324046694000--



--===============9007817294162305594==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============9007817294162305594==--



From xen-devel-bounces@lists.xensource.com Fri Dec 16 14:49:16 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 14:49:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbZ5n-0000AV-Vk; Fri, 16 Dec 2011 14:48:59 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RbZ5m-0000A2-RP
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 14:48:59 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1324046932!8245842!1
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28456 invoked from network); 16 Dec 2011 14:48:52 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Dec 2011 14:48:52 -0000
Received: by wgbds11 with SMTP id ds11so5353087wgb.24
	for <xen-devel@lists.xensource.com>;
	Fri, 16 Dec 2011 06:48:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=mhTV1uMhJocI4x+F73TYZT0eWmHrNlUXr+my5lM9yfQ=;
	b=pHipM2Fxs2gMoSCkdKWUhNZPnjLpHSKBpfnz2Wza+9+dkRm12ztYtJgRqRBBku/IIw
	5jqZqtl+ZFGoj1yYghJJTulI4pdX9OqCZrElDlNIma/NU1lnggeb7JIg8HsEY84kauE9
	3+SXUx5iQ6tX/OBSC1lNx7d06QJ+5iVt2VwoQ=
Received: by 10.216.143.206 with SMTP id l56mr740313wej.46.1324046932586;
	Fri, 16 Dec 2011 06:48:52 -0800 (PST)
Received: from [192.168.1.70] (host81-152-17-11.range81-152.btcentralplus.com.
	[81.152.17.11])
	by mx.google.com with ESMTPS id fo3sm13374931wib.11.2011.12.16.06.48.51
	(version=SSLv3 cipher=OTHER); Fri, 16 Dec 2011 06:48:52 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Fri, 16 Dec 2011 14:48:49 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <CB110AD1.27676%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH] x86: convert BUG_ON()s to WARN_ON()s in
	read_descriptor()
Thread-Index: Acy8AdHv0va1S9srqUaFz5gEFE87KA==
In-Reply-To: <4EEB676102000078000687FA@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] x86: convert BUG_ON()s to WARN_ON()s in
 read_descriptor()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 16/12/2011 14:44, "Jan Beulich" <JBeulich@suse.com> wrote:

>>>> On 16.12.11 at 10:09, Keir Fraser <keir.xen@gmail.com> wrote:
>> On 15/12/2011 10:25, "Jan Beulich" <JBeulich@suse.com> wrote:
>> 
>>> In the light of AMD erratum #700, and given that these checks happen
>>> for debugging purposes only and also only in debug builds of the
>>> hypervisor, make the failures non-fatal.
>> 
>> I think the changeset comment should have a brief description of erratum
>> #700.
> 
> I'd do this, but ...
> 
>> I also some reference should be made in a comment above the first
>> WARN_ON, explaining why they are now WARN_Ons (again, with reference to #700
>> and its symptoms).
> 
> ... I now think that these should never have been BUG_ON()s in the
> first place (despite probably having been the one who introduced
> them).
> 
> Additionally, on a second look, check_descriptor() would not allow any
> of the affected selector types to be installed into a descriptor table,
> and we clearly don't put in any such descriptors ourselves, so from the
> perspective of the erratum we're okay without the patch.
> 
> So if you prefer them to stay BUG_ON(), I think I'll just withdraw the
> patch.

If the erratum cannot affect us then they may as well stay as BUG_ON and we
sidestep the whole thing.

 -- Keir

> Jan
> 
>> Apart from that:
>> Acked-by: Keir Fraser <keir@xen.org>
>> 
>>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>>> 
>>> --- a/xen/arch/x86/traps.c
>>> +++ b/xen/arch/x86/traps.c
>>> @@ -1544,11 +1544,11 @@ static int read_descriptor(unsigned int
>>>              asm volatile (
>>>                  "larl %2,%0 ; setz %1"
>>>                  : "=r" (a), "=qm" (valid) : "rm" (sel));
>>> -            BUG_ON(valid && ((a & 0x00f0ff00) != *ar));
>>> +            WARN_ON(valid && ((a & 0x00f0ff00) != *ar));
>>>              asm volatile (
>>>                  "lsll %2,%0 ; setz %1"
>>>                  : "=r" (l), "=qm" (valid) : "rm" (sel));
>>> -            BUG_ON(valid && (l != *limit));
>>> +            WARN_ON(valid && (l != *limit));
>>>          }
>>>  #endif
>>>      }
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> Xen-devel mailing list
>>> Xen-devel@lists.xensource.com
>>> http://lists.xensource.com/xen-devel
> 
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 14:49:16 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 14:49:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbZ5n-0000AV-Vk; Fri, 16 Dec 2011 14:48:59 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RbZ5m-0000A2-RP
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 14:48:59 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1324046932!8245842!1
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28456 invoked from network); 16 Dec 2011 14:48:52 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Dec 2011 14:48:52 -0000
Received: by wgbds11 with SMTP id ds11so5353087wgb.24
	for <xen-devel@lists.xensource.com>;
	Fri, 16 Dec 2011 06:48:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=mhTV1uMhJocI4x+F73TYZT0eWmHrNlUXr+my5lM9yfQ=;
	b=pHipM2Fxs2gMoSCkdKWUhNZPnjLpHSKBpfnz2Wza+9+dkRm12ztYtJgRqRBBku/IIw
	5jqZqtl+ZFGoj1yYghJJTulI4pdX9OqCZrElDlNIma/NU1lnggeb7JIg8HsEY84kauE9
	3+SXUx5iQ6tX/OBSC1lNx7d06QJ+5iVt2VwoQ=
Received: by 10.216.143.206 with SMTP id l56mr740313wej.46.1324046932586;
	Fri, 16 Dec 2011 06:48:52 -0800 (PST)
Received: from [192.168.1.70] (host81-152-17-11.range81-152.btcentralplus.com.
	[81.152.17.11])
	by mx.google.com with ESMTPS id fo3sm13374931wib.11.2011.12.16.06.48.51
	(version=SSLv3 cipher=OTHER); Fri, 16 Dec 2011 06:48:52 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Fri, 16 Dec 2011 14:48:49 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <CB110AD1.27676%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH] x86: convert BUG_ON()s to WARN_ON()s in
	read_descriptor()
Thread-Index: Acy8AdHv0va1S9srqUaFz5gEFE87KA==
In-Reply-To: <4EEB676102000078000687FA@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] x86: convert BUG_ON()s to WARN_ON()s in
 read_descriptor()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 16/12/2011 14:44, "Jan Beulich" <JBeulich@suse.com> wrote:

>>>> On 16.12.11 at 10:09, Keir Fraser <keir.xen@gmail.com> wrote:
>> On 15/12/2011 10:25, "Jan Beulich" <JBeulich@suse.com> wrote:
>> 
>>> In the light of AMD erratum #700, and given that these checks happen
>>> for debugging purposes only and also only in debug builds of the
>>> hypervisor, make the failures non-fatal.
>> 
>> I think the changeset comment should have a brief description of erratum
>> #700.
> 
> I'd do this, but ...
> 
>> I also some reference should be made in a comment above the first
>> WARN_ON, explaining why they are now WARN_Ons (again, with reference to #700
>> and its symptoms).
> 
> ... I now think that these should never have been BUG_ON()s in the
> first place (despite probably having been the one who introduced
> them).
> 
> Additionally, on a second look, check_descriptor() would not allow any
> of the affected selector types to be installed into a descriptor table,
> and we clearly don't put in any such descriptors ourselves, so from the
> perspective of the erratum we're okay without the patch.
> 
> So if you prefer them to stay BUG_ON(), I think I'll just withdraw the
> patch.

If the erratum cannot affect us then they may as well stay as BUG_ON and we
sidestep the whole thing.

 -- Keir

> Jan
> 
>> Apart from that:
>> Acked-by: Keir Fraser <keir@xen.org>
>> 
>>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>>> 
>>> --- a/xen/arch/x86/traps.c
>>> +++ b/xen/arch/x86/traps.c
>>> @@ -1544,11 +1544,11 @@ static int read_descriptor(unsigned int
>>>              asm volatile (
>>>                  "larl %2,%0 ; setz %1"
>>>                  : "=r" (a), "=qm" (valid) : "rm" (sel));
>>> -            BUG_ON(valid && ((a & 0x00f0ff00) != *ar));
>>> +            WARN_ON(valid && ((a & 0x00f0ff00) != *ar));
>>>              asm volatile (
>>>                  "lsll %2,%0 ; setz %1"
>>>                  : "=r" (l), "=qm" (valid) : "rm" (sel));
>>> -            BUG_ON(valid && (l != *limit));
>>> +            WARN_ON(valid && (l != *limit));
>>>          }
>>>  #endif
>>>      }
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> Xen-devel mailing list
>>> Xen-devel@lists.xensource.com
>>> http://lists.xensource.com/xen-devel
> 
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 14:52:24 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 14: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.xensource.com>)
	id 1RbZ8v-0000Qg-4W; Fri, 16 Dec 2011 14:52:13 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RbZ8u-0000Q8-5E
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 14:52:12 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1324047074!57606801!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjI0MzY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9686 invoked from network); 16 Dec 2011 14:51:16 -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;
	16 Dec 2011 14:51:16 -0000
X-IronPort-AV: E=Sophos;i="4.71,363,1320642000"; d="scan'208";a="174457703"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Dec 2011 09:52:05 -0500
Received: from cosworth.uk.xensource.com (10.80.16.52) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 16 Dec 2011 09:52:05 -0500
MIME-Version: 1.0
X-Mercurial-Node: 83dad81a557e4499827830f693139f27986f4139
Message-ID: <83dad81a557e44998278.1324046715@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1324046713@cosworth.uk.xensource.com>
References: <patchbomb.1324046713@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 16 Dec 2011 14:45:15 +0000
From: Paul Durrant <paul.durrant@citrix.com>
To: xen-devel@lists.xensource.com
Cc: paul.durrant@citrix.com
Subject: [Xen-devel] [PATCH 2 of 4] Add hvm specific ro and rw nodes
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Paul Durrant <paul.durrant@citrix.com>
# Date 1324046220 0
# Node ID 83dad81a557e4499827830f693139f27986f4139
# Parent  a8c26cdf079cd6e3aa934e5011e554e36f33fce3
Add hvm specific ro and rw nodes.

The hvmloader node was created by libxl__create_device_model() but it
needs to be moved earlier so that it can parent the new rw
generation-id-address node.

Signed-off-by: Paul Durrant <paul.durrant@citrix.com>

diff -r a8c26cdf079c -r 83dad81a557e tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Fri Dec 16 14:12:15 2011 +0000
+++ b/tools/libxl/libxl_create.c	Fri Dec 16 14:37:00 2011 +0000
@@ -423,6 +423,10 @@ retry_transaction:
     libxl__xs_mkdir(gc, t,
                     libxl__sprintf(gc, "%s/control", dom_path),
                     roperm, ARRAY_SIZE(roperm));
+    if (info->type == LIBXL_DOMAIN_TYPE_HVM)
+        libxl__xs_mkdir(gc, t,
+                        libxl__sprintf(gc, "%s/hvmloader", dom_path),
+                        roperm, ARRAY_SIZE(roperm));
 
     libxl__xs_mkdir(gc, t,
                     libxl__sprintf(gc, "%s/control/shutdown", dom_path),
@@ -433,6 +437,10 @@ retry_transaction:
     libxl__xs_mkdir(gc, t,
                     libxl__sprintf(gc, "%s/data", dom_path),
                     rwperm, ARRAY_SIZE(rwperm));
+    if (info->type == LIBXL_DOMAIN_TYPE_HVM)
+        libxl__xs_mkdir(gc, t,
+                        libxl__sprintf(gc, "%s/hvmloader/generation-id-address", dom_path),
+                        rwperm, ARRAY_SIZE(rwperm));
 
     xs_write(ctx->xsh, t, libxl__sprintf(gc, "%s/uuid", vm_path), uuid_string, strlen(uuid_string));
     xs_write(ctx->xsh, t, libxl__sprintf(gc, "%s/name", vm_path), info->name, strlen(info->name));
diff -r a8c26cdf079c -r 83dad81a557e tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Fri Dec 16 14:12:15 2011 +0000
+++ b/tools/libxl/libxl_dm.c	Fri Dec 16 14:37:00 2011 +0000
@@ -821,10 +821,10 @@ int libxl__create_device_model(libxl__gc
         goto out;
     }
 
-    path = libxl__sprintf(gc, "/local/domain/%d/hvmloader", info->domid);
-    xs_mkdir(ctx->xsh, XBT_NULL, path);
-    libxl__xs_write(gc, XBT_NULL, libxl__sprintf(gc, "%s/bios", path),
+    path = xs_get_domain_path(ctx->xsh, info->domid);
+    libxl__xs_write(gc, XBT_NULL, libxl__sprintf(gc, "%s/hvmloader/bios", path),
                     "%s", libxl__domain_bios(gc, info));
+    free(path);
 
     path = libxl__sprintf(gc, "/local/domain/0/device-model/%d", info->domid);
     xs_mkdir(ctx->xsh, XBT_NULL, path);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 14:52:24 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 14: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.xensource.com>)
	id 1RbZ8v-0000Qg-4W; Fri, 16 Dec 2011 14:52:13 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RbZ8u-0000Q8-5E
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 14:52:12 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1324047074!57606801!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjI0MzY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9686 invoked from network); 16 Dec 2011 14:51:16 -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;
	16 Dec 2011 14:51:16 -0000
X-IronPort-AV: E=Sophos;i="4.71,363,1320642000"; d="scan'208";a="174457703"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Dec 2011 09:52:05 -0500
Received: from cosworth.uk.xensource.com (10.80.16.52) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 16 Dec 2011 09:52:05 -0500
MIME-Version: 1.0
X-Mercurial-Node: 83dad81a557e4499827830f693139f27986f4139
Message-ID: <83dad81a557e44998278.1324046715@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1324046713@cosworth.uk.xensource.com>
References: <patchbomb.1324046713@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 16 Dec 2011 14:45:15 +0000
From: Paul Durrant <paul.durrant@citrix.com>
To: xen-devel@lists.xensource.com
Cc: paul.durrant@citrix.com
Subject: [Xen-devel] [PATCH 2 of 4] Add hvm specific ro and rw nodes
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Paul Durrant <paul.durrant@citrix.com>
# Date 1324046220 0
# Node ID 83dad81a557e4499827830f693139f27986f4139
# Parent  a8c26cdf079cd6e3aa934e5011e554e36f33fce3
Add hvm specific ro and rw nodes.

The hvmloader node was created by libxl__create_device_model() but it
needs to be moved earlier so that it can parent the new rw
generation-id-address node.

Signed-off-by: Paul Durrant <paul.durrant@citrix.com>

diff -r a8c26cdf079c -r 83dad81a557e tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Fri Dec 16 14:12:15 2011 +0000
+++ b/tools/libxl/libxl_create.c	Fri Dec 16 14:37:00 2011 +0000
@@ -423,6 +423,10 @@ retry_transaction:
     libxl__xs_mkdir(gc, t,
                     libxl__sprintf(gc, "%s/control", dom_path),
                     roperm, ARRAY_SIZE(roperm));
+    if (info->type == LIBXL_DOMAIN_TYPE_HVM)
+        libxl__xs_mkdir(gc, t,
+                        libxl__sprintf(gc, "%s/hvmloader", dom_path),
+                        roperm, ARRAY_SIZE(roperm));
 
     libxl__xs_mkdir(gc, t,
                     libxl__sprintf(gc, "%s/control/shutdown", dom_path),
@@ -433,6 +437,10 @@ retry_transaction:
     libxl__xs_mkdir(gc, t,
                     libxl__sprintf(gc, "%s/data", dom_path),
                     rwperm, ARRAY_SIZE(rwperm));
+    if (info->type == LIBXL_DOMAIN_TYPE_HVM)
+        libxl__xs_mkdir(gc, t,
+                        libxl__sprintf(gc, "%s/hvmloader/generation-id-address", dom_path),
+                        rwperm, ARRAY_SIZE(rwperm));
 
     xs_write(ctx->xsh, t, libxl__sprintf(gc, "%s/uuid", vm_path), uuid_string, strlen(uuid_string));
     xs_write(ctx->xsh, t, libxl__sprintf(gc, "%s/name", vm_path), info->name, strlen(info->name));
diff -r a8c26cdf079c -r 83dad81a557e tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Fri Dec 16 14:12:15 2011 +0000
+++ b/tools/libxl/libxl_dm.c	Fri Dec 16 14:37:00 2011 +0000
@@ -821,10 +821,10 @@ int libxl__create_device_model(libxl__gc
         goto out;
     }
 
-    path = libxl__sprintf(gc, "/local/domain/%d/hvmloader", info->domid);
-    xs_mkdir(ctx->xsh, XBT_NULL, path);
-    libxl__xs_write(gc, XBT_NULL, libxl__sprintf(gc, "%s/bios", path),
+    path = xs_get_domain_path(ctx->xsh, info->domid);
+    libxl__xs_write(gc, XBT_NULL, libxl__sprintf(gc, "%s/hvmloader/bios", path),
                     "%s", libxl__domain_bios(gc, info));
+    free(path);
 
     path = libxl__sprintf(gc, "/local/domain/0/device-model/%d", info->domid);
     xs_mkdir(ctx->xsh, XBT_NULL, path);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 14:52:26 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 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.xensource.com>)
	id 1RbZ8t-0000QS-OK; Fri, 16 Dec 2011 14:52:11 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RbZ8r-0000Q4-Ka
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 14:52:09 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1324047074!57606801!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjI0MzY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9643 invoked from network); 16 Dec 2011 14:51:15 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Dec 2011 14:51:15 -0000
X-IronPort-AV: E=Sophos;i="4.71,363,1320642000"; d="scan'208";a="174457700"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Dec 2011 09:52:03 -0500
Received: from cosworth.uk.xensource.com (10.80.16.52) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 16 Dec 2011 09:52:03 -0500
MIME-Version: 1.0
Message-ID: <patchbomb.1324046713@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 16 Dec 2011 14:45:13 +0000
From: Paul Durrant <paul.durrant@citrix.com>
To: xen-devel@lists.xensource.com
Cc: paul.durrant@citrix.com
Subject: [Xen-devel] [PATCH 0 of 4] Support for VM generation ID
	save/restore and migrate
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This patch series adds support for preservation of the VM generation ID buffer
address in xenstore across save/restore and migrate, and also code to
increment the value in all cases except for migration.

Patch 1 modifies the guest ro and rw node creation to an open coding style
and cleans up some extraneous node creation.
Patch 2 modifies creation of the hvmloader key in xenstore and adds
creation of a new read/write hvmloader/generation-id-addr key.
Patch 3 changes hvmloader to use the new key (as opposed to the old
data/generation-id key). Note that it is safe to apply this patch
independently of the others but it logically belongs at this position in
the series.
Patch 4 adds the infrastructure to save and restore the VM generation
ID address in xenstore and the code to increment the value.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 14:52:26 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 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.xensource.com>)
	id 1RbZ8t-0000QS-OK; Fri, 16 Dec 2011 14:52:11 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RbZ8r-0000Q4-Ka
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 14:52:09 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1324047074!57606801!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjI0MzY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9643 invoked from network); 16 Dec 2011 14:51:15 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Dec 2011 14:51:15 -0000
X-IronPort-AV: E=Sophos;i="4.71,363,1320642000"; d="scan'208";a="174457700"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Dec 2011 09:52:03 -0500
Received: from cosworth.uk.xensource.com (10.80.16.52) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 16 Dec 2011 09:52:03 -0500
MIME-Version: 1.0
Message-ID: <patchbomb.1324046713@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 16 Dec 2011 14:45:13 +0000
From: Paul Durrant <paul.durrant@citrix.com>
To: xen-devel@lists.xensource.com
Cc: paul.durrant@citrix.com
Subject: [Xen-devel] [PATCH 0 of 4] Support for VM generation ID
	save/restore and migrate
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This patch series adds support for preservation of the VM generation ID buffer
address in xenstore across save/restore and migrate, and also code to
increment the value in all cases except for migration.

Patch 1 modifies the guest ro and rw node creation to an open coding style
and cleans up some extraneous node creation.
Patch 2 modifies creation of the hvmloader key in xenstore and adds
creation of a new read/write hvmloader/generation-id-addr key.
Patch 3 changes hvmloader to use the new key (as opposed to the old
data/generation-id key). Note that it is safe to apply this patch
independently of the others but it logically belongs at this position in
the series.
Patch 4 adds the infrastructure to save and restore the VM generation
ID address in xenstore and the code to increment the value.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 14:52:46 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 14:52:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbZ9I-0000V6-6y; Fri, 16 Dec 2011 14:52:36 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RbZ9G-0000U0-BH
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 14:52:34 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1324047145!2243762!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDc2NTY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20151 invoked from network); 16 Dec 2011 14:52:27 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Dec 2011 14:52:27 -0000
X-IronPort-AV: E=Sophos;i="4.71,363,1320642000"; d="scan'208";a="20040583"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Dec 2011 09:52:06 -0500
Received: from cosworth.uk.xensource.com (10.80.16.52) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 16 Dec 2011 09:52:06 -0500
MIME-Version: 1.0
X-Mercurial-Node: 5df9a24e0078e96ee5d45853f75b99db32e07ebe
Message-ID: <5df9a24e0078e96ee5d4.1324046717@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1324046713@cosworth.uk.xensource.com>
References: <patchbomb.1324046713@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 16 Dec 2011 14:45:17 +0000
From: Paul Durrant <paul.durrant@citrix.com>
To: xen-devel@lists.xensource.com
Cc: paul.durrant@citrix.com
Subject: [Xen-devel] [PATCH 4 of 4] VM generation ID save/restore and migrate
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Paul Durrant <paul.durrant@citrix.com>
# Date 1324046228 0
# Node ID 5df9a24e0078e96ee5d45853f75b99db32e07ebe
# Parent  bd8e9eb71611c08850eb5843e915f71748037457
VM generation ID save/restore and migrate.

Add code to track the address of the VM generation ID buffer across a
save/restore or migrate, and increment it as necessary.
The address of the buffer is written into xenstore by hvmloader at
boot time. It must be read from xenstore by the caller of
xc_domain_save() and then written back again by the caller of
xc_domain_restore().

Note that the changes to xc_save.c and xc_restore.c are merely
sufficient for them to build.

Signed-off-by: Paul Durrant <paul.durrant@citrix.com>

diff -r bd8e9eb71611 -r 5df9a24e0078 tools/libxc/ia64/xc_ia64_linux_restore.c
--- a/tools/libxc/ia64/xc_ia64_linux_restore.c	Fri Dec 16 14:37:08 2011 +0000
+++ b/tools/libxc/ia64/xc_ia64_linux_restore.c	Fri Dec 16 14:37:08 2011 +0000
@@ -548,7 +548,9 @@ int
 xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
                   unsigned int store_evtchn, unsigned long *store_mfn,
                   unsigned int console_evtchn, unsigned long *console_mfn,
-                  unsigned int hvm, unsigned int pae, int superpages)
+                  unsigned int hvm, unsigned int pae, int superpages,
+                  int no_incr_generationid,
+                  unsigned long *vm_generationid_addr)
 {
     DECLARE_DOMCTL;
     int rc = 1;
diff -r bd8e9eb71611 -r 5df9a24e0078 tools/libxc/ia64/xc_ia64_linux_save.c
--- a/tools/libxc/ia64/xc_ia64_linux_save.c	Fri Dec 16 14:37:08 2011 +0000
+++ b/tools/libxc/ia64/xc_ia64_linux_save.c	Fri Dec 16 14:37:08 2011 +0000
@@ -382,7 +382,8 @@ out:
 int
 xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iters,
                uint32_t max_factor, uint32_t flags,
-               struct save_callbacks* callbacks, int hvm)
+               struct save_callbacks* callbacks, int hvm,
+               unsigned long vm_generationid_addr)
 {
     DECLARE_DOMCTL;
     xc_dominfo_t info;
diff -r bd8e9eb71611 -r 5df9a24e0078 tools/libxc/xc_domain_restore.c
--- a/tools/libxc/xc_domain_restore.c	Fri Dec 16 14:37:08 2011 +0000
+++ b/tools/libxc/xc_domain_restore.c	Fri Dec 16 14:37:08 2011 +0000
@@ -681,6 +681,7 @@ typedef struct {
     uint64_t console_pfn;
     uint64_t acpi_ioport_location;
     uint64_t viridian;
+    uint64_t vm_generationid_addr;
 } pagebuf_t;
 
 static int pagebuf_init(pagebuf_t* buf)
@@ -860,6 +861,17 @@ static int pagebuf_get_one(xc_interface 
         }
         return compbuf_size;
 
+    case XC_SAVE_ID_HVM_GENERATION_ID_ADDR:
+        /* Skip padding 4 bytes then read the generation id buffer location. */
+        if ( RDEXACT(fd, &buf->vm_generationid_addr, sizeof(uint32_t)) ||
+             RDEXACT(fd, &buf->vm_generationid_addr, sizeof(uint64_t)) )
+        {
+            PERROR("error read the generation id buffer location");
+            return -1;
+        }
+        DPRINTF("read generation id buffer address");
+        return pagebuf_get_one(xch, ctx, buf, fd, dom);
+
     default:
         if ( (count > MAX_BATCH_SIZE) || (count < 0) ) {
             ERROR("Max batch size exceeded (%d). Giving up.", count);
@@ -1248,7 +1260,9 @@ static int apply_batch(xc_interface *xch
 int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
                       unsigned int store_evtchn, unsigned long *store_mfn,
                       unsigned int console_evtchn, unsigned long *console_mfn,
-                      unsigned int hvm, unsigned int pae, int superpages)
+                      unsigned int hvm, unsigned int pae, int superpages,
+                      int no_incr_generationid,
+                      unsigned long *vm_generationid_addr)
 {
     DECLARE_DOMCTL;
     int rc = 1, frc, i, j, n, m, pae_extended_cr3 = 0, ext_vcpucontext = 0;
@@ -1449,6 +1463,39 @@ int xc_domain_restore(xc_interface *xch,
                 xc_set_hvm_param(xch, dom, HVM_PARAM_VM86_TSS, pagebuf.vm86_tss);
             if ( pagebuf.console_pfn )
                 console_pfn = pagebuf.console_pfn;
+            if ( pagebuf.vm_generationid_addr ) {
+                if ( !no_incr_generationid ) {
+                    unsigned int offset;
+                    unsigned char *buf;
+                    unsigned long long generationid;
+
+                    /*
+                     * Map the VM generation id buffer and inject the new value.
+                     */
+
+                    pfn = pagebuf.vm_generationid_addr >> PAGE_SHIFT;
+                    offset = pagebuf.vm_generationid_addr & (PAGE_SIZE - 1);
+                
+                    if ( (pfn >= dinfo->p2m_size) ||
+                         (pfn_type[pfn] != XEN_DOMCTL_PFINFO_NOTAB) )
+                    {
+                        ERROR("generation id buffer frame is bad");
+                        goto out;
+                    }
+
+                    mfn = ctx->p2m[pfn];
+                    buf = xc_map_foreign_range(xch, dom, PAGE_SIZE,
+                                               PROT_READ | PROT_WRITE, mfn);
+
+                    generationid = *(unsigned long long *)(buf + offset);
+                    *(unsigned long long *)(buf + offset) = generationid + 1;
+
+                    munmap(buf, PAGE_SIZE);
+                }
+
+                *vm_generationid_addr = pagebuf.vm_generationid_addr;
+            }
+
             break;  /* our work here is done */
         }
 
diff -r bd8e9eb71611 -r 5df9a24e0078 tools/libxc/xc_domain_save.c
--- a/tools/libxc/xc_domain_save.c	Fri Dec 16 14:37:08 2011 +0000
+++ b/tools/libxc/xc_domain_save.c	Fri Dec 16 14:37:08 2011 +0000
@@ -804,7 +804,8 @@ static int save_tsc_info(xc_interface *x
 
 int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iters,
                    uint32_t max_factor, uint32_t flags,
-                   struct save_callbacks* callbacks, int hvm)
+                   struct save_callbacks* callbacks, int hvm,
+                   unsigned long vm_generationid_addr)
 {
     xc_dominfo_t info;
     DECLARE_DOMCTL;
@@ -1616,6 +1617,16 @@ int xc_domain_save(xc_interface *xch, in
             uint64_t data;
         } chunk = { 0, };
 
+        chunk.id = XC_SAVE_ID_HVM_GENERATION_ID_ADDR;
+        chunk.data = vm_generationid_addr;
+
+        if ( (chunk.data != 0) &&
+             wrexact(io_fd, &chunk, sizeof(chunk)) )
+        {
+            PERROR("Error when writing the generation id buffer location for guest");
+            goto out;
+        }
+
         chunk.id = XC_SAVE_ID_HVM_IDENT_PT;
         chunk.data = 0;
         xc_get_hvm_param(xch, dom, HVM_PARAM_IDENT_PT,
diff -r bd8e9eb71611 -r 5df9a24e0078 tools/libxc/xenguest.h
--- a/tools/libxc/xenguest.h	Fri Dec 16 14:37:08 2011 +0000
+++ b/tools/libxc/xenguest.h	Fri Dec 16 14:37:08 2011 +0000
@@ -58,7 +58,8 @@ struct save_callbacks {
  */
 int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iters,
                    uint32_t max_factor, uint32_t flags /* XCFLAGS_xxx */,
-                   struct save_callbacks* callbacks, int hvm);
+                   struct save_callbacks* callbacks, int hvm,
+                   unsigned long vm_generationid_addr);
 
 
 /**
@@ -72,12 +73,16 @@ int xc_domain_save(xc_interface *xch, in
  * @parm hvm non-zero if this is a HVM restore
  * @parm pae non-zero if this HVM domain has PAE support enabled
  * @parm superpages non-zero to allocate guest memory with superpages
+ * @parm no_incr_generationid non-zero if generation id is NOT to be incremented
+ * @parm vm_generationid_addr returned with the address of the generation id buffer
  * @return 0 on success, -1 on failure
  */
 int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
                       unsigned int store_evtchn, unsigned long *store_mfn,
                       unsigned int console_evtchn, unsigned long *console_mfn,
-                      unsigned int hvm, unsigned int pae, int superpages);
+                      unsigned int hvm, unsigned int pae, int superpages,
+                      int no_incr_generationid,
+		      unsigned long *vm_generationid_addr);
 /**
  * xc_domain_restore writes a file to disk that contains the device
  * model saved state.
diff -r bd8e9eb71611 -r 5df9a24e0078 tools/libxc/xg_save_restore.h
--- a/tools/libxc/xg_save_restore.h	Fri Dec 16 14:37:08 2011 +0000
+++ b/tools/libxc/xg_save_restore.h	Fri Dec 16 14:37:08 2011 +0000
@@ -253,6 +253,7 @@
 #define XC_SAVE_ID_HVM_VIRIDIAN       -11
 #define XC_SAVE_ID_COMPRESSED_DATA    -12 /* Marker to indicate arrival of compressed data */
 #define XC_SAVE_ID_ENABLE_COMPRESSION -13 /* Marker to enable compression logic at receiver side */
+#define XC_SAVE_ID_HVM_GENERATION_ID_ADDR -14
 
 /*
 ** We process save/restore/migrate in batches of pages; the below
diff -r bd8e9eb71611 -r 5df9a24e0078 tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Fri Dec 16 14:37:08 2011 +0000
+++ b/tools/libxl/libxl_create.c	Fri Dec 16 14:37:08 2011 +0000
@@ -99,6 +99,7 @@ int libxl_init_build_info(libxl_ctx *ctx
         b_info->u.hvm.vpt_align = 1;
         b_info->u.hvm.timer_mode = 1;
         b_info->u.hvm.nested_hvm = 0;
+        b_info->u.hvm.no_incr_generationid = 0;
         break;
     case LIBXL_DOMAIN_TYPE_PV:
         b_info->u.pv.slack_memkb = 8 * 1024;
diff -r bd8e9eb71611 -r 5df9a24e0078 tools/libxl/libxl_dom.c
--- a/tools/libxl/libxl_dom.c	Fri Dec 16 14:37:08 2011 +0000
+++ b/tools/libxl/libxl_dom.c	Fri Dec 16 14:37:08 2011 +0000
@@ -106,6 +106,7 @@ int libxl__build_pre(libxl__gc *gc, uint
 
     state->store_port = xc_evtchn_alloc_unbound(ctx->xch, domid, 0);
     state->console_port = xc_evtchn_alloc_unbound(ctx->xch, domid, 0);
+    state->vm_generationid_addr = 0;
     return 0;
 }
 
@@ -117,7 +118,7 @@ int libxl__build_post(libxl__gc *gc, uin
     libxl_ctx *ctx = libxl__gc_owner(gc);
     char *dom_path, *vm_path;
     xs_transaction_t t;
-    char **ents;
+    char **ents, **hvm_ents;
     int i;
 
     libxl_cpuid_apply_policy(ctx, domid);
@@ -143,6 +144,13 @@ int libxl__build_post(libxl__gc *gc, uin
                             ? "offline" : "online";
     }
 
+    hvm_ents = NULL;
+    if (info->type == LIBXL_DOMAIN_TYPE_HVM) {
+        hvm_ents = libxl__calloc(gc, 3, sizeof(char *));
+        hvm_ents[0] = "hvmloader/generation-id-address";
+        hvm_ents[1] = libxl__sprintf(gc, "0x%lx", state->vm_generationid_addr);
+    }
+
     dom_path = libxl__xs_get_dompath(gc, domid);
     if (!dom_path) {
         return ERROR_FAIL;
@@ -153,6 +161,9 @@ retry_transaction:
     t = xs_transaction_start(ctx->xsh);
 
     libxl__xs_writev(gc, t, dom_path, ents);
+    if (info->type == LIBXL_DOMAIN_TYPE_HVM)
+        libxl__xs_writev(gc, t, dom_path, hvm_ents);
+
     libxl__xs_writev(gc, t, dom_path, local_ents);
     libxl__xs_writev(gc, t, vm_path, vms_ents);
 
@@ -356,16 +367,19 @@ int libxl__domain_restore_common(libxl__
     /* read signature */
     int rc;
     int hvm, pae, superpages;
+    int no_incr_generationid;
     switch (info->type) {
     case LIBXL_DOMAIN_TYPE_HVM:
         hvm = 1;
         superpages = 1;
         pae = info->u.hvm.pae;
+        no_incr_generationid = info->u.hvm.no_incr_generationid;
         break;
     case LIBXL_DOMAIN_TYPE_PV:
         hvm = 0;
         superpages = 0;
         pae = 1;
+        no_incr_generationid = 0;
         break;
     default:
         return ERROR_INVAL;
@@ -373,7 +387,8 @@ int libxl__domain_restore_common(libxl__
     rc = xc_domain_restore(ctx->xch, fd, domid,
                            state->store_port, &state->store_mfn,
                            state->console_port, &state->console_mfn,
-                           hvm, pae, superpages);
+                           hvm, pae, superpages, no_incr_generationid,
+                           &state->vm_generationid_addr);
     if ( rc ) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "restoring domain");
         return ERROR_FAIL;
@@ -539,12 +554,23 @@ int libxl__domain_suspend_common(libxl__
     struct save_callbacks callbacks;
     struct suspendinfo si;
     int hvm, rc = ERROR_FAIL;
+    unsigned long vm_generationid_addr;
 
     switch (type) {
-    case LIBXL_DOMAIN_TYPE_HVM:
+    case LIBXL_DOMAIN_TYPE_HVM: {
+        char *path;
+        char *addr;
+
+        path = libxl__sprintf(gc, "%s/hvmloader/generation-id-address",
+                              libxl__xs_get_dompath(gc, domid));
+        addr = libxl__xs_read(gc, XBT_NULL, path);
+
+        vm_generationid_addr = (addr) ? strtoul(addr, NULL, 0) : 0;
         hvm = 1;
         break;
+    }
     case LIBXL_DOMAIN_TYPE_PV:
+        vm_generationid_addr = 0;
         hvm = 0;
         break;
     default:
@@ -582,7 +608,8 @@ int libxl__domain_suspend_common(libxl__
     callbacks.switch_qemu_logdirty = libxl__domain_suspend_common_switch_qemu_logdirty;
     callbacks.data = &si;
 
-    rc = xc_domain_save(ctx->xch, fd, domid, 0, 0, flags, &callbacks, hvm);
+    rc = xc_domain_save(ctx->xch, fd, domid, 0, 0, flags, &callbacks,
+                        hvm, vm_generationid_addr);
     if ( rc ) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "saving domain: %s",
                          si.guest_responded ?
diff -r bd8e9eb71611 -r 5df9a24e0078 tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Fri Dec 16 14:37:08 2011 +0000
+++ b/tools/libxl/libxl_internal.h	Fri Dec 16 14:37:08 2011 +0000
@@ -221,6 +221,7 @@ typedef struct {
 
     uint32_t console_port;
     unsigned long console_mfn;
+    unsigned long vm_generationid_addr;
 } libxl__domain_build_state;
 
 _hidden int libxl__build_pre(libxl__gc *gc, uint32_t domid,
diff -r bd8e9eb71611 -r 5df9a24e0078 tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Fri Dec 16 14:37:08 2011 +0000
+++ b/tools/libxl/libxl_types.idl	Fri Dec 16 14:37:08 2011 +0000
@@ -184,6 +184,7 @@ libxl_domain_build_info = Struct("domain
                                        ("vpt_align", bool),
                                        ("timer_mode", integer),
                                        ("nested_hvm", bool),
+                                       ("no_incr_generationid", bool),
                                        ])),
                  ("pv", Struct(None, [("kernel", libxl_file_reference),
                                       ("slack_memkb", uint32),
diff -r bd8e9eb71611 -r 5df9a24e0078 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Fri Dec 16 14:37:08 2011 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Fri Dec 16 14:37:08 2011 +0000
@@ -360,6 +360,8 @@ static void printf_info(int domid,
         printf("\t\t\t(vpt_align %d)\n", b_info->u.hvm.vpt_align);
         printf("\t\t\t(timer_mode %d)\n", b_info->u.hvm.timer_mode);
         printf("\t\t\t(nestedhvm %d)\n", b_info->u.hvm.nested_hvm);
+        printf("\t\t\t(no_incr_generationid %d)\n",
+                    b_info->u.hvm.no_incr_generationid);
 
         printf("\t\t\t(device_model %s)\n", dm_info->device_model ? : "default");
         printf("\t\t\t(videoram %d)\n", dm_info->videoram);
@@ -1362,6 +1364,7 @@ struct domain_create {
     const char *restore_file;
     int migrate_fd; /* -1 means none */
     char **migration_domname_r; /* from malloc */
+    int no_incr_generationid;
 };
 
 static int freemem(libxl_domain_build_info *b_info, libxl_device_model_info *dm_info)
@@ -1575,6 +1578,8 @@ static int create_domain(struct domain_c
         }
     }
 
+    d_config.b_info.u.hvm.no_incr_generationid = dom_info->no_incr_generationid;
+
     if (debug || dom_info->dryrun)
         printf_info(-1, &d_config, &d_config.dm_info);
 
@@ -2800,6 +2805,7 @@ static void migrate_receive(int debug, i
     dom_info.restore_file = "incoming migration stream";
     dom_info.migrate_fd = 0; /* stdin */
     dom_info.migration_domname_r = &migration_domname;
+    dom_info.no_incr_generationid = 1;
 
     rc = create_domain(&dom_info);
     if (rc < 0) {
diff -r bd8e9eb71611 -r 5df9a24e0078 tools/python/xen/lowlevel/checkpoint/libcheckpoint.c
--- a/tools/python/xen/lowlevel/checkpoint/libcheckpoint.c	Fri Dec 16 14:37:08 2011 +0000
+++ b/tools/python/xen/lowlevel/checkpoint/libcheckpoint.c	Fri Dec 16 14:37:08 2011 +0000
@@ -175,6 +175,7 @@ int checkpoint_start(checkpoint_state* s
 {
     int hvm, rc;
     int flags = XCFLAGS_LIVE;
+    unsigned long vm_generationid_addr;
 
     if (!s->domid) {
        s->errstr = "checkpoint state not opened";
@@ -185,16 +186,28 @@ int checkpoint_start(checkpoint_state* s
 
     hvm = s->domtype > dt_pv;
     if (hvm) {
+       char path[128];
+       char *addr;
+
+       sprintf(path, "/local/domain/%u/hvmloader/generation-id-address", s->domid);
+       addr = xs_read(s->xsh, XBT_NULL, path, NULL);
+
+       vm_generationid_addr = (addr) ? strtoul(addr, NULL, 0) : 0;
+       free(addr);
+
        flags |= XCFLAGS_HVM;
        if (switch_qemu_logdirty(s, 1))
            return -1;
+    } else {
+       vm_generationid_addr = 0;
     }
     if (remus_flags & CHECKPOINT_FLAGS_COMPRESSION)
       flags |= XCFLAGS_CHECKPOINT_COMPRESS;
 
     callbacks->switch_qemu_logdirty = noop_switch_logdirty;
 
-    rc = xc_domain_save(s->xch, fd, s->domid, 0, 0, flags, callbacks, hvm);
+    rc = xc_domain_save(s->xch, fd, s->domid, 0, 0, flags, callbacks, hvm,
+                        vm_generationid_addr);
 
     if (hvm)
        switch_qemu_logdirty(s, 0);
diff -r bd8e9eb71611 -r 5df9a24e0078 tools/xcutils/xc_restore.c
--- a/tools/xcutils/xc_restore.c	Fri Dec 16 14:37:08 2011 +0000
+++ b/tools/xcutils/xc_restore.c	Fri Dec 16 14:37:08 2011 +0000
@@ -46,7 +46,8 @@ main(int argc, char **argv)
 	    superpages = !!hvm;
 
     ret = xc_domain_restore(xch, io_fd, domid, store_evtchn, &store_mfn,
-                            console_evtchn, &console_mfn, hvm, pae, superpages);
+                            console_evtchn, &console_mfn, hvm, pae, superpages,
+                            0, NULL);
 
     if ( ret == 0 )
     {
diff -r bd8e9eb71611 -r 5df9a24e0078 tools/xcutils/xc_save.c
--- a/tools/xcutils/xc_save.c	Fri Dec 16 14:37:08 2011 +0000
+++ b/tools/xcutils/xc_save.c	Fri Dec 16 14:37:08 2011 +0000
@@ -208,7 +208,7 @@ main(int argc, char **argv)
     callbacks.suspend = suspend;
     callbacks.switch_qemu_logdirty = switch_qemu_logdirty;
     ret = xc_domain_save(si.xch, io_fd, si.domid, maxit, max_f, si.flags, 
-                         &callbacks, !!(si.flags & XCFLAGS_HVM));
+                         &callbacks, !!(si.flags & XCFLAGS_HVM), 0);
 
     if (si.suspend_evtchn > 0)
 	 xc_suspend_evtchn_release(si.xch, si.xce, si.domid, si.suspend_evtchn);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 14:52:46 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 14:52:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbZ9H-0000Uy-IC; Fri, 16 Dec 2011 14:52:35 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RbZ9F-0000Tr-Py
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 14:52:34 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1324047145!2243762!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDc2NTY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20143 invoked from network); 16 Dec 2011 14:52:27 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Dec 2011 14:52:27 -0000
X-IronPort-AV: E=Sophos;i="4.71,363,1320642000"; d="scan'208";a="20040567"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Dec 2011 09:52:04 -0500
Received: from cosworth.uk.xensource.com (10.80.16.52) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 16 Dec 2011 09:52:04 -0500
MIME-Version: 1.0
X-Mercurial-Node: a8c26cdf079cd6e3aa934e5011e554e36f33fce3
Message-ID: <a8c26cdf079cd6e3aa93.1324046714@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1324046713@cosworth.uk.xensource.com>
References: <patchbomb.1324046713@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 16 Dec 2011 14:45:14 +0000
From: Paul Durrant <paul.durrant@citrix.com>
To: xen-devel@lists.xensource.com
Cc: paul.durrant@citrix.com
Subject: [Xen-devel] [PATCH 1 of 4] Open code rw and ro path creation
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Paul Durrant <paul.durrant@citrix.com>
# Date 1324044735 0
# Node ID a8c26cdf079cd6e3aa934e5011e554e36f33fce3
# Parent  03138a08366b895d79e143119d4c9c72833cdbcd
Open code rw and ro path creation.

Use a new libxl__xs_mkdir() to do this and also clean up extraneous path creation
while in the neighbourhood. Checking 'xenstore-ls -fp' output before and after
shows that, as well as the disappearance of error, drivers, messages and domid, the
following perms change is also present:

-device/suspend = ""   (ndomU)
+device/suspend = ""   (n0,rdomU)

I believe the new perms are more desirable than the old ones.

Signed-off-by: Paul Durrant <paul.durrant@citrix.com>

diff -r 03138a08366b -r a8c26cdf079c tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Fri Dec 09 16:19:36 2011 +0000
+++ b/tools/libxl/libxl_create.c	Fri Dec 16 14:12:15 2011 +0000
@@ -320,11 +320,8 @@ int libxl__domain_make(libxl__gc *gc, li
   * on exit (even error exit), domid may be valid and refer to a domain */
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
-    int flags, ret, i, rc;
+    int flags, ret, rc;
     char *uuid_string;
-    char *rw_paths[] = { "control/shutdown", "device", "device/suspend/event-channel" , "data"};
-    char *ro_paths[] = { "cpu", "memory", "device", "error", "drivers",
-                         "control", "attr", "messages" };
     char *dom_path, *vm_path, *libxl_path;
     struct xs_permissions roperm[2];
     struct xs_permissions rwperm[1];
@@ -384,6 +381,7 @@ int libxl__domain_make(libxl__gc *gc, li
         rc = ERROR_FAIL;
         goto out;
     }
+
     noperm[0].id = 0;
     noperm[0].perms = XS_PERM_NONE;
 
@@ -391,6 +389,7 @@ int libxl__domain_make(libxl__gc *gc, li
     roperm[0].perms = XS_PERM_NONE;
     roperm[1].id = *domid;
     roperm[1].perms = XS_PERM_READ;
+
     rwperm[0].id = *domid;
     rwperm[0].perms = XS_PERM_NONE;
 
@@ -398,32 +397,42 @@ retry_transaction:
     t = xs_transaction_start(ctx->xsh);
 
     xs_rm(ctx->xsh, t, dom_path);
-    xs_mkdir(ctx->xsh, t, dom_path);
-    xs_set_permissions(ctx->xsh, t, dom_path, roperm, ARRAY_SIZE(roperm));
+    libxl__xs_mkdir(gc, t, dom_path, roperm, ARRAY_SIZE(roperm));
+
 
     xs_rm(ctx->xsh, t, vm_path);
-    xs_mkdir(ctx->xsh, t, vm_path);
-    xs_set_permissions(ctx->xsh, t, vm_path, roperm, ARRAY_SIZE(roperm));
+    libxl__xs_mkdir(gc, t, vm_path, roperm, ARRAY_SIZE(roperm));
 
     xs_rm(ctx->xsh, t, libxl_path);
-    xs_mkdir(ctx->xsh, t, libxl_path);
-    xs_set_permissions(ctx->xsh, t, libxl_path, noperm, ARRAY_SIZE(noperm));
+    libxl__xs_mkdir(gc, t, libxl_path, noperm, ARRAY_SIZE(noperm));
 
     xs_write(ctx->xsh, t, libxl__sprintf(gc, "%s/vm", dom_path), vm_path, strlen(vm_path));
     rc = libxl__domain_rename(gc, *domid, 0, info->name, t);
     if (rc)
         goto out;
 
-    for (i = 0; i < ARRAY_SIZE(rw_paths); i++) {
-        char *path = libxl__sprintf(gc, "%s/%s", dom_path, rw_paths[i]);
-        xs_mkdir(ctx->xsh, t, path);
-        xs_set_permissions(ctx->xsh, t, path, rwperm, ARRAY_SIZE(rwperm));
-    }
-    for (i = 0; i < ARRAY_SIZE(ro_paths); i++) {
-        char *path = libxl__sprintf(gc, "%s/%s", dom_path, ro_paths[i]);
-        xs_mkdir(ctx->xsh, t, path);
-        xs_set_permissions(ctx->xsh, t, path, roperm, ARRAY_SIZE(roperm));
-    }
+    libxl__xs_mkdir(gc, t,
+                    libxl__sprintf(gc, "%s/cpu", dom_path),
+                    roperm, ARRAY_SIZE(roperm));
+    libxl__xs_mkdir(gc, t,
+                    libxl__sprintf(gc, "%s/memory", dom_path),
+                    roperm, ARRAY_SIZE(roperm));
+    libxl__xs_mkdir(gc, t,
+                    libxl__sprintf(gc, "%s/device", dom_path),
+                    roperm, ARRAY_SIZE(roperm));
+    libxl__xs_mkdir(gc, t,
+                    libxl__sprintf(gc, "%s/control", dom_path),
+                    roperm, ARRAY_SIZE(roperm));
+
+    libxl__xs_mkdir(gc, t,
+                    libxl__sprintf(gc, "%s/control/shutdown", dom_path),
+                    rwperm, ARRAY_SIZE(rwperm));
+    libxl__xs_mkdir(gc, t,
+                    libxl__sprintf(gc, "%s/device/suspend/event-channel", dom_path),
+                    rwperm, ARRAY_SIZE(rwperm));
+    libxl__xs_mkdir(gc, t,
+                    libxl__sprintf(gc, "%s/data", dom_path),
+                    rwperm, ARRAY_SIZE(rwperm));
 
     xs_write(ctx->xsh, t, libxl__sprintf(gc, "%s/uuid", vm_path), uuid_string, strlen(uuid_string));
     xs_write(ctx->xsh, t, libxl__sprintf(gc, "%s/name", vm_path), info->name, strlen(info->name));
diff -r 03138a08366b -r a8c26cdf079c tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Fri Dec 09 16:19:36 2011 +0000
+++ b/tools/libxl/libxl_internal.h	Fri Dec 16 14:12:15 2011 +0000
@@ -204,6 +204,9 @@ _hidden char *libxl__xs_read(libxl__gc *
 _hidden char **libxl__xs_directory(libxl__gc *gc, xs_transaction_t t,
                                    const char *path, unsigned int *nb);
    /* On error: returns NULL, sets errno (no logging) */
+_hidden bool libxl__xs_mkdir(libxl__gc *gc, xs_transaction_t t,
+                             const char *path, struct xs_permissions *perms,
+			     unsigned int num_perms);
 
 _hidden char *libxl__xs_libxl_path(libxl__gc *gc, uint32_t domid);
 
diff -r 03138a08366b -r a8c26cdf079c tools/libxl/libxl_xshelp.c
--- a/tools/libxl/libxl_xshelp.c	Fri Dec 09 16:19:36 2011 +0000
+++ b/tools/libxl/libxl_xshelp.c	Fri Dec 16 14:12:15 2011 +0000
@@ -122,6 +122,16 @@ char **libxl__xs_directory(libxl__gc *gc
     return ret;
 }
 
+bool libxl__xs_mkdir(libxl__gc *gc, xs_transaction_t t,
+                     const char *path, struct xs_permissions *perms,
+			         unsigned int num_perms)
+{
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+    if (!xs_mkdir(ctx->xsh, t, path))
+        return false;
+    return xs_set_permissions(ctx->xsh, t, path, perms, num_perms);
+}
+
 char *libxl__xs_libxl_path(libxl__gc *gc, uint32_t domid)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 14:52:46 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 14:52:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbZ9I-0000V6-6y; Fri, 16 Dec 2011 14:52:36 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RbZ9G-0000U0-BH
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 14:52:34 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1324047145!2243762!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDc2NTY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20151 invoked from network); 16 Dec 2011 14:52:27 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Dec 2011 14:52:27 -0000
X-IronPort-AV: E=Sophos;i="4.71,363,1320642000"; d="scan'208";a="20040583"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Dec 2011 09:52:06 -0500
Received: from cosworth.uk.xensource.com (10.80.16.52) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 16 Dec 2011 09:52:06 -0500
MIME-Version: 1.0
X-Mercurial-Node: 5df9a24e0078e96ee5d45853f75b99db32e07ebe
Message-ID: <5df9a24e0078e96ee5d4.1324046717@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1324046713@cosworth.uk.xensource.com>
References: <patchbomb.1324046713@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 16 Dec 2011 14:45:17 +0000
From: Paul Durrant <paul.durrant@citrix.com>
To: xen-devel@lists.xensource.com
Cc: paul.durrant@citrix.com
Subject: [Xen-devel] [PATCH 4 of 4] VM generation ID save/restore and migrate
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Paul Durrant <paul.durrant@citrix.com>
# Date 1324046228 0
# Node ID 5df9a24e0078e96ee5d45853f75b99db32e07ebe
# Parent  bd8e9eb71611c08850eb5843e915f71748037457
VM generation ID save/restore and migrate.

Add code to track the address of the VM generation ID buffer across a
save/restore or migrate, and increment it as necessary.
The address of the buffer is written into xenstore by hvmloader at
boot time. It must be read from xenstore by the caller of
xc_domain_save() and then written back again by the caller of
xc_domain_restore().

Note that the changes to xc_save.c and xc_restore.c are merely
sufficient for them to build.

Signed-off-by: Paul Durrant <paul.durrant@citrix.com>

diff -r bd8e9eb71611 -r 5df9a24e0078 tools/libxc/ia64/xc_ia64_linux_restore.c
--- a/tools/libxc/ia64/xc_ia64_linux_restore.c	Fri Dec 16 14:37:08 2011 +0000
+++ b/tools/libxc/ia64/xc_ia64_linux_restore.c	Fri Dec 16 14:37:08 2011 +0000
@@ -548,7 +548,9 @@ int
 xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
                   unsigned int store_evtchn, unsigned long *store_mfn,
                   unsigned int console_evtchn, unsigned long *console_mfn,
-                  unsigned int hvm, unsigned int pae, int superpages)
+                  unsigned int hvm, unsigned int pae, int superpages,
+                  int no_incr_generationid,
+                  unsigned long *vm_generationid_addr)
 {
     DECLARE_DOMCTL;
     int rc = 1;
diff -r bd8e9eb71611 -r 5df9a24e0078 tools/libxc/ia64/xc_ia64_linux_save.c
--- a/tools/libxc/ia64/xc_ia64_linux_save.c	Fri Dec 16 14:37:08 2011 +0000
+++ b/tools/libxc/ia64/xc_ia64_linux_save.c	Fri Dec 16 14:37:08 2011 +0000
@@ -382,7 +382,8 @@ out:
 int
 xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iters,
                uint32_t max_factor, uint32_t flags,
-               struct save_callbacks* callbacks, int hvm)
+               struct save_callbacks* callbacks, int hvm,
+               unsigned long vm_generationid_addr)
 {
     DECLARE_DOMCTL;
     xc_dominfo_t info;
diff -r bd8e9eb71611 -r 5df9a24e0078 tools/libxc/xc_domain_restore.c
--- a/tools/libxc/xc_domain_restore.c	Fri Dec 16 14:37:08 2011 +0000
+++ b/tools/libxc/xc_domain_restore.c	Fri Dec 16 14:37:08 2011 +0000
@@ -681,6 +681,7 @@ typedef struct {
     uint64_t console_pfn;
     uint64_t acpi_ioport_location;
     uint64_t viridian;
+    uint64_t vm_generationid_addr;
 } pagebuf_t;
 
 static int pagebuf_init(pagebuf_t* buf)
@@ -860,6 +861,17 @@ static int pagebuf_get_one(xc_interface 
         }
         return compbuf_size;
 
+    case XC_SAVE_ID_HVM_GENERATION_ID_ADDR:
+        /* Skip padding 4 bytes then read the generation id buffer location. */
+        if ( RDEXACT(fd, &buf->vm_generationid_addr, sizeof(uint32_t)) ||
+             RDEXACT(fd, &buf->vm_generationid_addr, sizeof(uint64_t)) )
+        {
+            PERROR("error read the generation id buffer location");
+            return -1;
+        }
+        DPRINTF("read generation id buffer address");
+        return pagebuf_get_one(xch, ctx, buf, fd, dom);
+
     default:
         if ( (count > MAX_BATCH_SIZE) || (count < 0) ) {
             ERROR("Max batch size exceeded (%d). Giving up.", count);
@@ -1248,7 +1260,9 @@ static int apply_batch(xc_interface *xch
 int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
                       unsigned int store_evtchn, unsigned long *store_mfn,
                       unsigned int console_evtchn, unsigned long *console_mfn,
-                      unsigned int hvm, unsigned int pae, int superpages)
+                      unsigned int hvm, unsigned int pae, int superpages,
+                      int no_incr_generationid,
+                      unsigned long *vm_generationid_addr)
 {
     DECLARE_DOMCTL;
     int rc = 1, frc, i, j, n, m, pae_extended_cr3 = 0, ext_vcpucontext = 0;
@@ -1449,6 +1463,39 @@ int xc_domain_restore(xc_interface *xch,
                 xc_set_hvm_param(xch, dom, HVM_PARAM_VM86_TSS, pagebuf.vm86_tss);
             if ( pagebuf.console_pfn )
                 console_pfn = pagebuf.console_pfn;
+            if ( pagebuf.vm_generationid_addr ) {
+                if ( !no_incr_generationid ) {
+                    unsigned int offset;
+                    unsigned char *buf;
+                    unsigned long long generationid;
+
+                    /*
+                     * Map the VM generation id buffer and inject the new value.
+                     */
+
+                    pfn = pagebuf.vm_generationid_addr >> PAGE_SHIFT;
+                    offset = pagebuf.vm_generationid_addr & (PAGE_SIZE - 1);
+                
+                    if ( (pfn >= dinfo->p2m_size) ||
+                         (pfn_type[pfn] != XEN_DOMCTL_PFINFO_NOTAB) )
+                    {
+                        ERROR("generation id buffer frame is bad");
+                        goto out;
+                    }
+
+                    mfn = ctx->p2m[pfn];
+                    buf = xc_map_foreign_range(xch, dom, PAGE_SIZE,
+                                               PROT_READ | PROT_WRITE, mfn);
+
+                    generationid = *(unsigned long long *)(buf + offset);
+                    *(unsigned long long *)(buf + offset) = generationid + 1;
+
+                    munmap(buf, PAGE_SIZE);
+                }
+
+                *vm_generationid_addr = pagebuf.vm_generationid_addr;
+            }
+
             break;  /* our work here is done */
         }
 
diff -r bd8e9eb71611 -r 5df9a24e0078 tools/libxc/xc_domain_save.c
--- a/tools/libxc/xc_domain_save.c	Fri Dec 16 14:37:08 2011 +0000
+++ b/tools/libxc/xc_domain_save.c	Fri Dec 16 14:37:08 2011 +0000
@@ -804,7 +804,8 @@ static int save_tsc_info(xc_interface *x
 
 int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iters,
                    uint32_t max_factor, uint32_t flags,
-                   struct save_callbacks* callbacks, int hvm)
+                   struct save_callbacks* callbacks, int hvm,
+                   unsigned long vm_generationid_addr)
 {
     xc_dominfo_t info;
     DECLARE_DOMCTL;
@@ -1616,6 +1617,16 @@ int xc_domain_save(xc_interface *xch, in
             uint64_t data;
         } chunk = { 0, };
 
+        chunk.id = XC_SAVE_ID_HVM_GENERATION_ID_ADDR;
+        chunk.data = vm_generationid_addr;
+
+        if ( (chunk.data != 0) &&
+             wrexact(io_fd, &chunk, sizeof(chunk)) )
+        {
+            PERROR("Error when writing the generation id buffer location for guest");
+            goto out;
+        }
+
         chunk.id = XC_SAVE_ID_HVM_IDENT_PT;
         chunk.data = 0;
         xc_get_hvm_param(xch, dom, HVM_PARAM_IDENT_PT,
diff -r bd8e9eb71611 -r 5df9a24e0078 tools/libxc/xenguest.h
--- a/tools/libxc/xenguest.h	Fri Dec 16 14:37:08 2011 +0000
+++ b/tools/libxc/xenguest.h	Fri Dec 16 14:37:08 2011 +0000
@@ -58,7 +58,8 @@ struct save_callbacks {
  */
 int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iters,
                    uint32_t max_factor, uint32_t flags /* XCFLAGS_xxx */,
-                   struct save_callbacks* callbacks, int hvm);
+                   struct save_callbacks* callbacks, int hvm,
+                   unsigned long vm_generationid_addr);
 
 
 /**
@@ -72,12 +73,16 @@ int xc_domain_save(xc_interface *xch, in
  * @parm hvm non-zero if this is a HVM restore
  * @parm pae non-zero if this HVM domain has PAE support enabled
  * @parm superpages non-zero to allocate guest memory with superpages
+ * @parm no_incr_generationid non-zero if generation id is NOT to be incremented
+ * @parm vm_generationid_addr returned with the address of the generation id buffer
  * @return 0 on success, -1 on failure
  */
 int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
                       unsigned int store_evtchn, unsigned long *store_mfn,
                       unsigned int console_evtchn, unsigned long *console_mfn,
-                      unsigned int hvm, unsigned int pae, int superpages);
+                      unsigned int hvm, unsigned int pae, int superpages,
+                      int no_incr_generationid,
+		      unsigned long *vm_generationid_addr);
 /**
  * xc_domain_restore writes a file to disk that contains the device
  * model saved state.
diff -r bd8e9eb71611 -r 5df9a24e0078 tools/libxc/xg_save_restore.h
--- a/tools/libxc/xg_save_restore.h	Fri Dec 16 14:37:08 2011 +0000
+++ b/tools/libxc/xg_save_restore.h	Fri Dec 16 14:37:08 2011 +0000
@@ -253,6 +253,7 @@
 #define XC_SAVE_ID_HVM_VIRIDIAN       -11
 #define XC_SAVE_ID_COMPRESSED_DATA    -12 /* Marker to indicate arrival of compressed data */
 #define XC_SAVE_ID_ENABLE_COMPRESSION -13 /* Marker to enable compression logic at receiver side */
+#define XC_SAVE_ID_HVM_GENERATION_ID_ADDR -14
 
 /*
 ** We process save/restore/migrate in batches of pages; the below
diff -r bd8e9eb71611 -r 5df9a24e0078 tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Fri Dec 16 14:37:08 2011 +0000
+++ b/tools/libxl/libxl_create.c	Fri Dec 16 14:37:08 2011 +0000
@@ -99,6 +99,7 @@ int libxl_init_build_info(libxl_ctx *ctx
         b_info->u.hvm.vpt_align = 1;
         b_info->u.hvm.timer_mode = 1;
         b_info->u.hvm.nested_hvm = 0;
+        b_info->u.hvm.no_incr_generationid = 0;
         break;
     case LIBXL_DOMAIN_TYPE_PV:
         b_info->u.pv.slack_memkb = 8 * 1024;
diff -r bd8e9eb71611 -r 5df9a24e0078 tools/libxl/libxl_dom.c
--- a/tools/libxl/libxl_dom.c	Fri Dec 16 14:37:08 2011 +0000
+++ b/tools/libxl/libxl_dom.c	Fri Dec 16 14:37:08 2011 +0000
@@ -106,6 +106,7 @@ int libxl__build_pre(libxl__gc *gc, uint
 
     state->store_port = xc_evtchn_alloc_unbound(ctx->xch, domid, 0);
     state->console_port = xc_evtchn_alloc_unbound(ctx->xch, domid, 0);
+    state->vm_generationid_addr = 0;
     return 0;
 }
 
@@ -117,7 +118,7 @@ int libxl__build_post(libxl__gc *gc, uin
     libxl_ctx *ctx = libxl__gc_owner(gc);
     char *dom_path, *vm_path;
     xs_transaction_t t;
-    char **ents;
+    char **ents, **hvm_ents;
     int i;
 
     libxl_cpuid_apply_policy(ctx, domid);
@@ -143,6 +144,13 @@ int libxl__build_post(libxl__gc *gc, uin
                             ? "offline" : "online";
     }
 
+    hvm_ents = NULL;
+    if (info->type == LIBXL_DOMAIN_TYPE_HVM) {
+        hvm_ents = libxl__calloc(gc, 3, sizeof(char *));
+        hvm_ents[0] = "hvmloader/generation-id-address";
+        hvm_ents[1] = libxl__sprintf(gc, "0x%lx", state->vm_generationid_addr);
+    }
+
     dom_path = libxl__xs_get_dompath(gc, domid);
     if (!dom_path) {
         return ERROR_FAIL;
@@ -153,6 +161,9 @@ retry_transaction:
     t = xs_transaction_start(ctx->xsh);
 
     libxl__xs_writev(gc, t, dom_path, ents);
+    if (info->type == LIBXL_DOMAIN_TYPE_HVM)
+        libxl__xs_writev(gc, t, dom_path, hvm_ents);
+
     libxl__xs_writev(gc, t, dom_path, local_ents);
     libxl__xs_writev(gc, t, vm_path, vms_ents);
 
@@ -356,16 +367,19 @@ int libxl__domain_restore_common(libxl__
     /* read signature */
     int rc;
     int hvm, pae, superpages;
+    int no_incr_generationid;
     switch (info->type) {
     case LIBXL_DOMAIN_TYPE_HVM:
         hvm = 1;
         superpages = 1;
         pae = info->u.hvm.pae;
+        no_incr_generationid = info->u.hvm.no_incr_generationid;
         break;
     case LIBXL_DOMAIN_TYPE_PV:
         hvm = 0;
         superpages = 0;
         pae = 1;
+        no_incr_generationid = 0;
         break;
     default:
         return ERROR_INVAL;
@@ -373,7 +387,8 @@ int libxl__domain_restore_common(libxl__
     rc = xc_domain_restore(ctx->xch, fd, domid,
                            state->store_port, &state->store_mfn,
                            state->console_port, &state->console_mfn,
-                           hvm, pae, superpages);
+                           hvm, pae, superpages, no_incr_generationid,
+                           &state->vm_generationid_addr);
     if ( rc ) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "restoring domain");
         return ERROR_FAIL;
@@ -539,12 +554,23 @@ int libxl__domain_suspend_common(libxl__
     struct save_callbacks callbacks;
     struct suspendinfo si;
     int hvm, rc = ERROR_FAIL;
+    unsigned long vm_generationid_addr;
 
     switch (type) {
-    case LIBXL_DOMAIN_TYPE_HVM:
+    case LIBXL_DOMAIN_TYPE_HVM: {
+        char *path;
+        char *addr;
+
+        path = libxl__sprintf(gc, "%s/hvmloader/generation-id-address",
+                              libxl__xs_get_dompath(gc, domid));
+        addr = libxl__xs_read(gc, XBT_NULL, path);
+
+        vm_generationid_addr = (addr) ? strtoul(addr, NULL, 0) : 0;
         hvm = 1;
         break;
+    }
     case LIBXL_DOMAIN_TYPE_PV:
+        vm_generationid_addr = 0;
         hvm = 0;
         break;
     default:
@@ -582,7 +608,8 @@ int libxl__domain_suspend_common(libxl__
     callbacks.switch_qemu_logdirty = libxl__domain_suspend_common_switch_qemu_logdirty;
     callbacks.data = &si;
 
-    rc = xc_domain_save(ctx->xch, fd, domid, 0, 0, flags, &callbacks, hvm);
+    rc = xc_domain_save(ctx->xch, fd, domid, 0, 0, flags, &callbacks,
+                        hvm, vm_generationid_addr);
     if ( rc ) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "saving domain: %s",
                          si.guest_responded ?
diff -r bd8e9eb71611 -r 5df9a24e0078 tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Fri Dec 16 14:37:08 2011 +0000
+++ b/tools/libxl/libxl_internal.h	Fri Dec 16 14:37:08 2011 +0000
@@ -221,6 +221,7 @@ typedef struct {
 
     uint32_t console_port;
     unsigned long console_mfn;
+    unsigned long vm_generationid_addr;
 } libxl__domain_build_state;
 
 _hidden int libxl__build_pre(libxl__gc *gc, uint32_t domid,
diff -r bd8e9eb71611 -r 5df9a24e0078 tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Fri Dec 16 14:37:08 2011 +0000
+++ b/tools/libxl/libxl_types.idl	Fri Dec 16 14:37:08 2011 +0000
@@ -184,6 +184,7 @@ libxl_domain_build_info = Struct("domain
                                        ("vpt_align", bool),
                                        ("timer_mode", integer),
                                        ("nested_hvm", bool),
+                                       ("no_incr_generationid", bool),
                                        ])),
                  ("pv", Struct(None, [("kernel", libxl_file_reference),
                                       ("slack_memkb", uint32),
diff -r bd8e9eb71611 -r 5df9a24e0078 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Fri Dec 16 14:37:08 2011 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Fri Dec 16 14:37:08 2011 +0000
@@ -360,6 +360,8 @@ static void printf_info(int domid,
         printf("\t\t\t(vpt_align %d)\n", b_info->u.hvm.vpt_align);
         printf("\t\t\t(timer_mode %d)\n", b_info->u.hvm.timer_mode);
         printf("\t\t\t(nestedhvm %d)\n", b_info->u.hvm.nested_hvm);
+        printf("\t\t\t(no_incr_generationid %d)\n",
+                    b_info->u.hvm.no_incr_generationid);
 
         printf("\t\t\t(device_model %s)\n", dm_info->device_model ? : "default");
         printf("\t\t\t(videoram %d)\n", dm_info->videoram);
@@ -1362,6 +1364,7 @@ struct domain_create {
     const char *restore_file;
     int migrate_fd; /* -1 means none */
     char **migration_domname_r; /* from malloc */
+    int no_incr_generationid;
 };
 
 static int freemem(libxl_domain_build_info *b_info, libxl_device_model_info *dm_info)
@@ -1575,6 +1578,8 @@ static int create_domain(struct domain_c
         }
     }
 
+    d_config.b_info.u.hvm.no_incr_generationid = dom_info->no_incr_generationid;
+
     if (debug || dom_info->dryrun)
         printf_info(-1, &d_config, &d_config.dm_info);
 
@@ -2800,6 +2805,7 @@ static void migrate_receive(int debug, i
     dom_info.restore_file = "incoming migration stream";
     dom_info.migrate_fd = 0; /* stdin */
     dom_info.migration_domname_r = &migration_domname;
+    dom_info.no_incr_generationid = 1;
 
     rc = create_domain(&dom_info);
     if (rc < 0) {
diff -r bd8e9eb71611 -r 5df9a24e0078 tools/python/xen/lowlevel/checkpoint/libcheckpoint.c
--- a/tools/python/xen/lowlevel/checkpoint/libcheckpoint.c	Fri Dec 16 14:37:08 2011 +0000
+++ b/tools/python/xen/lowlevel/checkpoint/libcheckpoint.c	Fri Dec 16 14:37:08 2011 +0000
@@ -175,6 +175,7 @@ int checkpoint_start(checkpoint_state* s
 {
     int hvm, rc;
     int flags = XCFLAGS_LIVE;
+    unsigned long vm_generationid_addr;
 
     if (!s->domid) {
        s->errstr = "checkpoint state not opened";
@@ -185,16 +186,28 @@ int checkpoint_start(checkpoint_state* s
 
     hvm = s->domtype > dt_pv;
     if (hvm) {
+       char path[128];
+       char *addr;
+
+       sprintf(path, "/local/domain/%u/hvmloader/generation-id-address", s->domid);
+       addr = xs_read(s->xsh, XBT_NULL, path, NULL);
+
+       vm_generationid_addr = (addr) ? strtoul(addr, NULL, 0) : 0;
+       free(addr);
+
        flags |= XCFLAGS_HVM;
        if (switch_qemu_logdirty(s, 1))
            return -1;
+    } else {
+       vm_generationid_addr = 0;
     }
     if (remus_flags & CHECKPOINT_FLAGS_COMPRESSION)
       flags |= XCFLAGS_CHECKPOINT_COMPRESS;
 
     callbacks->switch_qemu_logdirty = noop_switch_logdirty;
 
-    rc = xc_domain_save(s->xch, fd, s->domid, 0, 0, flags, callbacks, hvm);
+    rc = xc_domain_save(s->xch, fd, s->domid, 0, 0, flags, callbacks, hvm,
+                        vm_generationid_addr);
 
     if (hvm)
        switch_qemu_logdirty(s, 0);
diff -r bd8e9eb71611 -r 5df9a24e0078 tools/xcutils/xc_restore.c
--- a/tools/xcutils/xc_restore.c	Fri Dec 16 14:37:08 2011 +0000
+++ b/tools/xcutils/xc_restore.c	Fri Dec 16 14:37:08 2011 +0000
@@ -46,7 +46,8 @@ main(int argc, char **argv)
 	    superpages = !!hvm;
 
     ret = xc_domain_restore(xch, io_fd, domid, store_evtchn, &store_mfn,
-                            console_evtchn, &console_mfn, hvm, pae, superpages);
+                            console_evtchn, &console_mfn, hvm, pae, superpages,
+                            0, NULL);
 
     if ( ret == 0 )
     {
diff -r bd8e9eb71611 -r 5df9a24e0078 tools/xcutils/xc_save.c
--- a/tools/xcutils/xc_save.c	Fri Dec 16 14:37:08 2011 +0000
+++ b/tools/xcutils/xc_save.c	Fri Dec 16 14:37:08 2011 +0000
@@ -208,7 +208,7 @@ main(int argc, char **argv)
     callbacks.suspend = suspend;
     callbacks.switch_qemu_logdirty = switch_qemu_logdirty;
     ret = xc_domain_save(si.xch, io_fd, si.domid, maxit, max_f, si.flags, 
-                         &callbacks, !!(si.flags & XCFLAGS_HVM));
+                         &callbacks, !!(si.flags & XCFLAGS_HVM), 0);
 
     if (si.suspend_evtchn > 0)
 	 xc_suspend_evtchn_release(si.xch, si.xce, si.domid, si.suspend_evtchn);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 14:52:46 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 14:52:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbZ9H-0000Uy-IC; Fri, 16 Dec 2011 14:52:35 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RbZ9F-0000Tr-Py
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 14:52:34 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1324047145!2243762!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDc2NTY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20143 invoked from network); 16 Dec 2011 14:52:27 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Dec 2011 14:52:27 -0000
X-IronPort-AV: E=Sophos;i="4.71,363,1320642000"; d="scan'208";a="20040567"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Dec 2011 09:52:04 -0500
Received: from cosworth.uk.xensource.com (10.80.16.52) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 16 Dec 2011 09:52:04 -0500
MIME-Version: 1.0
X-Mercurial-Node: a8c26cdf079cd6e3aa934e5011e554e36f33fce3
Message-ID: <a8c26cdf079cd6e3aa93.1324046714@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1324046713@cosworth.uk.xensource.com>
References: <patchbomb.1324046713@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 16 Dec 2011 14:45:14 +0000
From: Paul Durrant <paul.durrant@citrix.com>
To: xen-devel@lists.xensource.com
Cc: paul.durrant@citrix.com
Subject: [Xen-devel] [PATCH 1 of 4] Open code rw and ro path creation
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Paul Durrant <paul.durrant@citrix.com>
# Date 1324044735 0
# Node ID a8c26cdf079cd6e3aa934e5011e554e36f33fce3
# Parent  03138a08366b895d79e143119d4c9c72833cdbcd
Open code rw and ro path creation.

Use a new libxl__xs_mkdir() to do this and also clean up extraneous path creation
while in the neighbourhood. Checking 'xenstore-ls -fp' output before and after
shows that, as well as the disappearance of error, drivers, messages and domid, the
following perms change is also present:

-device/suspend = ""   (ndomU)
+device/suspend = ""   (n0,rdomU)

I believe the new perms are more desirable than the old ones.

Signed-off-by: Paul Durrant <paul.durrant@citrix.com>

diff -r 03138a08366b -r a8c26cdf079c tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Fri Dec 09 16:19:36 2011 +0000
+++ b/tools/libxl/libxl_create.c	Fri Dec 16 14:12:15 2011 +0000
@@ -320,11 +320,8 @@ int libxl__domain_make(libxl__gc *gc, li
   * on exit (even error exit), domid may be valid and refer to a domain */
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
-    int flags, ret, i, rc;
+    int flags, ret, rc;
     char *uuid_string;
-    char *rw_paths[] = { "control/shutdown", "device", "device/suspend/event-channel" , "data"};
-    char *ro_paths[] = { "cpu", "memory", "device", "error", "drivers",
-                         "control", "attr", "messages" };
     char *dom_path, *vm_path, *libxl_path;
     struct xs_permissions roperm[2];
     struct xs_permissions rwperm[1];
@@ -384,6 +381,7 @@ int libxl__domain_make(libxl__gc *gc, li
         rc = ERROR_FAIL;
         goto out;
     }
+
     noperm[0].id = 0;
     noperm[0].perms = XS_PERM_NONE;
 
@@ -391,6 +389,7 @@ int libxl__domain_make(libxl__gc *gc, li
     roperm[0].perms = XS_PERM_NONE;
     roperm[1].id = *domid;
     roperm[1].perms = XS_PERM_READ;
+
     rwperm[0].id = *domid;
     rwperm[0].perms = XS_PERM_NONE;
 
@@ -398,32 +397,42 @@ retry_transaction:
     t = xs_transaction_start(ctx->xsh);
 
     xs_rm(ctx->xsh, t, dom_path);
-    xs_mkdir(ctx->xsh, t, dom_path);
-    xs_set_permissions(ctx->xsh, t, dom_path, roperm, ARRAY_SIZE(roperm));
+    libxl__xs_mkdir(gc, t, dom_path, roperm, ARRAY_SIZE(roperm));
+
 
     xs_rm(ctx->xsh, t, vm_path);
-    xs_mkdir(ctx->xsh, t, vm_path);
-    xs_set_permissions(ctx->xsh, t, vm_path, roperm, ARRAY_SIZE(roperm));
+    libxl__xs_mkdir(gc, t, vm_path, roperm, ARRAY_SIZE(roperm));
 
     xs_rm(ctx->xsh, t, libxl_path);
-    xs_mkdir(ctx->xsh, t, libxl_path);
-    xs_set_permissions(ctx->xsh, t, libxl_path, noperm, ARRAY_SIZE(noperm));
+    libxl__xs_mkdir(gc, t, libxl_path, noperm, ARRAY_SIZE(noperm));
 
     xs_write(ctx->xsh, t, libxl__sprintf(gc, "%s/vm", dom_path), vm_path, strlen(vm_path));
     rc = libxl__domain_rename(gc, *domid, 0, info->name, t);
     if (rc)
         goto out;
 
-    for (i = 0; i < ARRAY_SIZE(rw_paths); i++) {
-        char *path = libxl__sprintf(gc, "%s/%s", dom_path, rw_paths[i]);
-        xs_mkdir(ctx->xsh, t, path);
-        xs_set_permissions(ctx->xsh, t, path, rwperm, ARRAY_SIZE(rwperm));
-    }
-    for (i = 0; i < ARRAY_SIZE(ro_paths); i++) {
-        char *path = libxl__sprintf(gc, "%s/%s", dom_path, ro_paths[i]);
-        xs_mkdir(ctx->xsh, t, path);
-        xs_set_permissions(ctx->xsh, t, path, roperm, ARRAY_SIZE(roperm));
-    }
+    libxl__xs_mkdir(gc, t,
+                    libxl__sprintf(gc, "%s/cpu", dom_path),
+                    roperm, ARRAY_SIZE(roperm));
+    libxl__xs_mkdir(gc, t,
+                    libxl__sprintf(gc, "%s/memory", dom_path),
+                    roperm, ARRAY_SIZE(roperm));
+    libxl__xs_mkdir(gc, t,
+                    libxl__sprintf(gc, "%s/device", dom_path),
+                    roperm, ARRAY_SIZE(roperm));
+    libxl__xs_mkdir(gc, t,
+                    libxl__sprintf(gc, "%s/control", dom_path),
+                    roperm, ARRAY_SIZE(roperm));
+
+    libxl__xs_mkdir(gc, t,
+                    libxl__sprintf(gc, "%s/control/shutdown", dom_path),
+                    rwperm, ARRAY_SIZE(rwperm));
+    libxl__xs_mkdir(gc, t,
+                    libxl__sprintf(gc, "%s/device/suspend/event-channel", dom_path),
+                    rwperm, ARRAY_SIZE(rwperm));
+    libxl__xs_mkdir(gc, t,
+                    libxl__sprintf(gc, "%s/data", dom_path),
+                    rwperm, ARRAY_SIZE(rwperm));
 
     xs_write(ctx->xsh, t, libxl__sprintf(gc, "%s/uuid", vm_path), uuid_string, strlen(uuid_string));
     xs_write(ctx->xsh, t, libxl__sprintf(gc, "%s/name", vm_path), info->name, strlen(info->name));
diff -r 03138a08366b -r a8c26cdf079c tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Fri Dec 09 16:19:36 2011 +0000
+++ b/tools/libxl/libxl_internal.h	Fri Dec 16 14:12:15 2011 +0000
@@ -204,6 +204,9 @@ _hidden char *libxl__xs_read(libxl__gc *
 _hidden char **libxl__xs_directory(libxl__gc *gc, xs_transaction_t t,
                                    const char *path, unsigned int *nb);
    /* On error: returns NULL, sets errno (no logging) */
+_hidden bool libxl__xs_mkdir(libxl__gc *gc, xs_transaction_t t,
+                             const char *path, struct xs_permissions *perms,
+			     unsigned int num_perms);
 
 _hidden char *libxl__xs_libxl_path(libxl__gc *gc, uint32_t domid);
 
diff -r 03138a08366b -r a8c26cdf079c tools/libxl/libxl_xshelp.c
--- a/tools/libxl/libxl_xshelp.c	Fri Dec 09 16:19:36 2011 +0000
+++ b/tools/libxl/libxl_xshelp.c	Fri Dec 16 14:12:15 2011 +0000
@@ -122,6 +122,16 @@ char **libxl__xs_directory(libxl__gc *gc
     return ret;
 }
 
+bool libxl__xs_mkdir(libxl__gc *gc, xs_transaction_t t,
+                     const char *path, struct xs_permissions *perms,
+			         unsigned int num_perms)
+{
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+    if (!xs_mkdir(ctx->xsh, t, path))
+        return false;
+    return xs_set_permissions(ctx->xsh, t, path, perms, num_perms);
+}
+
 char *libxl__xs_libxl_path(libxl__gc *gc, uint32_t domid)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 14:52:46 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 14:52:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbZ9I-0000VM-OU; Fri, 16 Dec 2011 14:52:36 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RbZ9G-0000UA-Q1
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 14:52:35 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1324047145!2243762!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDc2NTY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20242 invoked from network); 16 Dec 2011 14:52:28 -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;
	16 Dec 2011 14:52:28 -0000
X-IronPort-AV: E=Sophos;i="4.71,363,1320642000"; d="scan'208";a="20040575"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Dec 2011 09:52:06 -0500
Received: from cosworth.uk.xensource.com (10.80.16.52) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 16 Dec 2011 09:52:05 -0500
MIME-Version: 1.0
X-Mercurial-Node: bd8e9eb71611c08850eb5843e915f71748037457
Message-ID: <bd8e9eb71611c08850eb.1324046716@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1324046713@cosworth.uk.xensource.com>
References: <patchbomb.1324046713@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 16 Dec 2011 14:45:16 +0000
From: Paul Durrant <paul.durrant@citrix.com>
To: xen-devel@lists.xensource.com
Cc: paul.durrant@citrix.com
Subject: [Xen-devel] [PATCH 3 of 4] Re-name xenstore key used to save VM
 generation ID buffer address
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Paul Durrant <paul.durrant@citrix.com>
# Date 1324046228 0
# Node ID bd8e9eb71611c08850eb5843e915f71748037457
# Parent  83dad81a557e4499827830f693139f27986f4139
Re-name xenstore key used to save VM generation ID buffer address.

Signed-off-by: Paul Durrant <paul.durrant@citrix.com>

diff -r 83dad81a557e -r bd8e9eb71611 tools/firmware/hvmloader/acpi/build.c
--- a/tools/firmware/hvmloader/acpi/build.c	Fri Dec 16 14:37:00 2011 +0000
+++ b/tools/firmware/hvmloader/acpi/build.c	Fri Dec 16 14:37:08 2011 +0000
@@ -309,7 +309,7 @@ unsigned long new_vm_gid(void)
     if ( snprintf(addr, sizeof(addr), "0x%lx", virt_to_phys(buf))
          >= sizeof(addr) )
         return 0;
-    xenstore_write("data/generation-id", addr);
+    xenstore_write("hvmloader/generation-id-address", addr);
 
     gid = strtoll(xenstore_read("platform/generation-id", "0"), NULL, 0);
     *(uint64_t *)buf = gid;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 14:52:46 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 14:52:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbZ9I-0000VM-OU; Fri, 16 Dec 2011 14:52:36 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RbZ9G-0000UA-Q1
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 14:52:35 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1324047145!2243762!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDc2NTY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20242 invoked from network); 16 Dec 2011 14:52:28 -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;
	16 Dec 2011 14:52:28 -0000
X-IronPort-AV: E=Sophos;i="4.71,363,1320642000"; d="scan'208";a="20040575"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Dec 2011 09:52:06 -0500
Received: from cosworth.uk.xensource.com (10.80.16.52) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 16 Dec 2011 09:52:05 -0500
MIME-Version: 1.0
X-Mercurial-Node: bd8e9eb71611c08850eb5843e915f71748037457
Message-ID: <bd8e9eb71611c08850eb.1324046716@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1324046713@cosworth.uk.xensource.com>
References: <patchbomb.1324046713@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 16 Dec 2011 14:45:16 +0000
From: Paul Durrant <paul.durrant@citrix.com>
To: xen-devel@lists.xensource.com
Cc: paul.durrant@citrix.com
Subject: [Xen-devel] [PATCH 3 of 4] Re-name xenstore key used to save VM
 generation ID buffer address
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Paul Durrant <paul.durrant@citrix.com>
# Date 1324046228 0
# Node ID bd8e9eb71611c08850eb5843e915f71748037457
# Parent  83dad81a557e4499827830f693139f27986f4139
Re-name xenstore key used to save VM generation ID buffer address.

Signed-off-by: Paul Durrant <paul.durrant@citrix.com>

diff -r 83dad81a557e -r bd8e9eb71611 tools/firmware/hvmloader/acpi/build.c
--- a/tools/firmware/hvmloader/acpi/build.c	Fri Dec 16 14:37:00 2011 +0000
+++ b/tools/firmware/hvmloader/acpi/build.c	Fri Dec 16 14:37:08 2011 +0000
@@ -309,7 +309,7 @@ unsigned long new_vm_gid(void)
     if ( snprintf(addr, sizeof(addr), "0x%lx", virt_to_phys(buf))
          >= sizeof(addr) )
         return 0;
-    xenstore_write("data/generation-id", addr);
+    xenstore_write("hvmloader/generation-id-address", addr);
 
     gid = strtoll(xenstore_read("platform/generation-id", "0"), NULL, 0);
     *(uint64_t *)buf = gid;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 14:54:26 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 14:54:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbZAt-0000s9-HV; Fri, 16 Dec 2011 14:54:15 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RbZAr-0000qC-5f
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 14:54:13 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1324047245!5861523!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjU3OQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26587 invoked from network); 16 Dec 2011 14:54:06 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Dec 2011 14:54:06 -0000
X-IronPort-AV: E=Sophos;i="4.71,363,1320624000"; 
   d="scan'208";a="9517567"
Received: from lonpmailmx02.citrite.net ([10.30.203.163])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Dec 2011 14:54:00 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.161]) by
	LONPMAILMX02.citrite.net ([10.30.203.163]) with mapi; Fri, 16 Dec 2011
	14:54:00 +0000
From: Paul Durrant <Paul.Durrant@citrix.com>
To: Paul Durrant <Paul.Durrant@citrix.com>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>
Date: Fri, 16 Dec 2011 14:54:00 +0000
Thread-Topic: [PATCH 1 of 4] Open code rw and ro path creation
Thread-Index: Acy8Akd4gIuuys+CTlial+Hh57G3PwAADHSQ
Message-ID: <291EDFCB1E9E224A99088639C4762022B598ED101B@LONPMAILBOX01.citrite.net>
References: <patchbomb.1324046713@cosworth.uk.xensource.com>
	<a8c26cdf079cd6e3aa93.1324046714@cosworth.uk.xensource.com>
In-Reply-To: <a8c26cdf079cd6e3aa93.1324046714@cosworth.uk.xensource.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Subject: Re: [Xen-devel] [PATCH 1 of 4] Open code rw and ro path creation
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Damn. This is a stale version of this patch. I'll re-send.

  Paul

> -----Original Message-----
> From: Paul Durrant [mailto:paul.durrant@citrix.com]
> Sent: 16 December 2011 14:45
> To: xen-devel@lists.xensource.com
> Cc: Paul Durrant
> Subject: [PATCH 1 of 4] Open code rw and ro path creation
> 
> # HG changeset patch
> # User Paul Durrant <paul.durrant@citrix.com> # Date 1324044735 0 #
> Node ID a8c26cdf079cd6e3aa934e5011e554e36f33fce3
> # Parent  03138a08366b895d79e143119d4c9c72833cdbcd
> Open code rw and ro path creation.
> 
> Use a new libxl__xs_mkdir() to do this and also clean up extraneous
> path creation while in the neighbourhood. Checking 'xenstore-ls -fp'
> output before and after shows that, as well as the disappearance of
> error, drivers, messages and domid, the following perms change is
> also present:
> 
> -device/suspend = ""   (ndomU)
> +device/suspend = ""   (n0,rdomU)
> 
> I believe the new perms are more desirable than the old ones.
> 
> Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
> 
> diff -r 03138a08366b -r a8c26cdf079c tools/libxl/libxl_create.c
> --- a/tools/libxl/libxl_create.c	Fri Dec 09 16:19:36 2011 +0000
> +++ b/tools/libxl/libxl_create.c	Fri Dec 16 14:12:15 2011 +0000
> @@ -320,11 +320,8 @@ int libxl__domain_make(libxl__gc *gc, li
>    * on exit (even error exit), domid may be valid and refer to a
> domain */  {
>      libxl_ctx *ctx = libxl__gc_owner(gc);
> -    int flags, ret, i, rc;
> +    int flags, ret, rc;
>      char *uuid_string;
> -    char *rw_paths[] = { "control/shutdown", "device",
> "device/suspend/event-channel" , "data"};
> -    char *ro_paths[] = { "cpu", "memory", "device", "error",
> "drivers",
> -                         "control", "attr", "messages" };
>      char *dom_path, *vm_path, *libxl_path;
>      struct xs_permissions roperm[2];
>      struct xs_permissions rwperm[1];
> @@ -384,6 +381,7 @@ int libxl__domain_make(libxl__gc *gc, li
>          rc = ERROR_FAIL;
>          goto out;
>      }
> +
>      noperm[0].id = 0;
>      noperm[0].perms = XS_PERM_NONE;
> 
> @@ -391,6 +389,7 @@ int libxl__domain_make(libxl__gc *gc, li
>      roperm[0].perms = XS_PERM_NONE;
>      roperm[1].id = *domid;
>      roperm[1].perms = XS_PERM_READ;
> +
>      rwperm[0].id = *domid;
>      rwperm[0].perms = XS_PERM_NONE;
> 
> @@ -398,32 +397,42 @@ retry_transaction:
>      t = xs_transaction_start(ctx->xsh);
> 
>      xs_rm(ctx->xsh, t, dom_path);
> -    xs_mkdir(ctx->xsh, t, dom_path);
> -    xs_set_permissions(ctx->xsh, t, dom_path, roperm,
> ARRAY_SIZE(roperm));
> +    libxl__xs_mkdir(gc, t, dom_path, roperm, ARRAY_SIZE(roperm));
> +
> 
>      xs_rm(ctx->xsh, t, vm_path);
> -    xs_mkdir(ctx->xsh, t, vm_path);
> -    xs_set_permissions(ctx->xsh, t, vm_path, roperm,
> ARRAY_SIZE(roperm));
> +    libxl__xs_mkdir(gc, t, vm_path, roperm, ARRAY_SIZE(roperm));
> 
>      xs_rm(ctx->xsh, t, libxl_path);
> -    xs_mkdir(ctx->xsh, t, libxl_path);
> -    xs_set_permissions(ctx->xsh, t, libxl_path, noperm,
> ARRAY_SIZE(noperm));
> +    libxl__xs_mkdir(gc, t, libxl_path, noperm, ARRAY_SIZE(noperm));
> 
>      xs_write(ctx->xsh, t, libxl__sprintf(gc, "%s/vm", dom_path),
> vm_path, strlen(vm_path));
>      rc = libxl__domain_rename(gc, *domid, 0, info->name, t);
>      if (rc)
>          goto out;
> 
> -    for (i = 0; i < ARRAY_SIZE(rw_paths); i++) {
> -        char *path = libxl__sprintf(gc, "%s/%s", dom_path,
> rw_paths[i]);
> -        xs_mkdir(ctx->xsh, t, path);
> -        xs_set_permissions(ctx->xsh, t, path, rwperm,
> ARRAY_SIZE(rwperm));
> -    }
> -    for (i = 0; i < ARRAY_SIZE(ro_paths); i++) {
> -        char *path = libxl__sprintf(gc, "%s/%s", dom_path,
> ro_paths[i]);
> -        xs_mkdir(ctx->xsh, t, path);
> -        xs_set_permissions(ctx->xsh, t, path, roperm,
> ARRAY_SIZE(roperm));
> -    }
> +    libxl__xs_mkdir(gc, t,
> +                    libxl__sprintf(gc, "%s/cpu", dom_path),
> +                    roperm, ARRAY_SIZE(roperm));
> +    libxl__xs_mkdir(gc, t,
> +                    libxl__sprintf(gc, "%s/memory", dom_path),
> +                    roperm, ARRAY_SIZE(roperm));
> +    libxl__xs_mkdir(gc, t,
> +                    libxl__sprintf(gc, "%s/device", dom_path),
> +                    roperm, ARRAY_SIZE(roperm));
> +    libxl__xs_mkdir(gc, t,
> +                    libxl__sprintf(gc, "%s/control", dom_path),
> +                    roperm, ARRAY_SIZE(roperm));
> +
> +    libxl__xs_mkdir(gc, t,
> +                    libxl__sprintf(gc, "%s/control/shutdown",
> dom_path),
> +                    rwperm, ARRAY_SIZE(rwperm));
> +    libxl__xs_mkdir(gc, t,
> +                    libxl__sprintf(gc, "%s/device/suspend/event-
> channel", dom_path),
> +                    rwperm, ARRAY_SIZE(rwperm));
> +    libxl__xs_mkdir(gc, t,
> +                    libxl__sprintf(gc, "%s/data", dom_path),
> +                    rwperm, ARRAY_SIZE(rwperm));
> 
>      xs_write(ctx->xsh, t, libxl__sprintf(gc, "%s/uuid", vm_path),
> uuid_string, strlen(uuid_string));
>      xs_write(ctx->xsh, t, libxl__sprintf(gc, "%s/name", vm_path),
> info->name, strlen(info->name)); diff -r 03138a08366b -r
> a8c26cdf079c tools/libxl/libxl_internal.h
> --- a/tools/libxl/libxl_internal.h	Fri Dec 09 16:19:36 2011 +0000
> +++ b/tools/libxl/libxl_internal.h	Fri Dec 16 14:12:15 2011 +0000
> @@ -204,6 +204,9 @@ _hidden char *libxl__xs_read(libxl__gc *
> _hidden char **libxl__xs_directory(libxl__gc *gc, xs_transaction_t
> t,
>                                     const char *path, unsigned int
> *nb);
>     /* On error: returns NULL, sets errno (no logging) */
> +_hidden bool libxl__xs_mkdir(libxl__gc *gc, xs_transaction_t t,
> +                             const char *path, struct
> xs_permissions *perms,
> +			     unsigned int num_perms);
> 
>  _hidden char *libxl__xs_libxl_path(libxl__gc *gc, uint32_t domid);
> 
> diff -r 03138a08366b -r a8c26cdf079c tools/libxl/libxl_xshelp.c
> --- a/tools/libxl/libxl_xshelp.c	Fri Dec 09 16:19:36 2011 +0000
> +++ b/tools/libxl/libxl_xshelp.c	Fri Dec 16 14:12:15 2011 +0000
> @@ -122,6 +122,16 @@ char **libxl__xs_directory(libxl__gc *gc
>      return ret;
>  }
> 
> +bool libxl__xs_mkdir(libxl__gc *gc, xs_transaction_t t,
> +                     const char *path, struct xs_permissions
> *perms,
> +			         unsigned int num_perms)
> +{
> +    libxl_ctx *ctx = libxl__gc_owner(gc);
> +    if (!xs_mkdir(ctx->xsh, t, path))
> +        return false;
> +    return xs_set_permissions(ctx->xsh, t, path, perms, num_perms);
> }
> +
>  char *libxl__xs_libxl_path(libxl__gc *gc, uint32_t domid)  {
>      libxl_ctx *ctx = libxl__gc_owner(gc);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 14:54:26 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 14:54:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbZAt-0000s9-HV; Fri, 16 Dec 2011 14:54:15 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RbZAr-0000qC-5f
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 14:54:13 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1324047245!5861523!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjU3OQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26587 invoked from network); 16 Dec 2011 14:54:06 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Dec 2011 14:54:06 -0000
X-IronPort-AV: E=Sophos;i="4.71,363,1320624000"; 
   d="scan'208";a="9517567"
Received: from lonpmailmx02.citrite.net ([10.30.203.163])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Dec 2011 14:54:00 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.161]) by
	LONPMAILMX02.citrite.net ([10.30.203.163]) with mapi; Fri, 16 Dec 2011
	14:54:00 +0000
From: Paul Durrant <Paul.Durrant@citrix.com>
To: Paul Durrant <Paul.Durrant@citrix.com>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>
Date: Fri, 16 Dec 2011 14:54:00 +0000
Thread-Topic: [PATCH 1 of 4] Open code rw and ro path creation
Thread-Index: Acy8Akd4gIuuys+CTlial+Hh57G3PwAADHSQ
Message-ID: <291EDFCB1E9E224A99088639C4762022B598ED101B@LONPMAILBOX01.citrite.net>
References: <patchbomb.1324046713@cosworth.uk.xensource.com>
	<a8c26cdf079cd6e3aa93.1324046714@cosworth.uk.xensource.com>
In-Reply-To: <a8c26cdf079cd6e3aa93.1324046714@cosworth.uk.xensource.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Subject: Re: [Xen-devel] [PATCH 1 of 4] Open code rw and ro path creation
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Damn. This is a stale version of this patch. I'll re-send.

  Paul

> -----Original Message-----
> From: Paul Durrant [mailto:paul.durrant@citrix.com]
> Sent: 16 December 2011 14:45
> To: xen-devel@lists.xensource.com
> Cc: Paul Durrant
> Subject: [PATCH 1 of 4] Open code rw and ro path creation
> 
> # HG changeset patch
> # User Paul Durrant <paul.durrant@citrix.com> # Date 1324044735 0 #
> Node ID a8c26cdf079cd6e3aa934e5011e554e36f33fce3
> # Parent  03138a08366b895d79e143119d4c9c72833cdbcd
> Open code rw and ro path creation.
> 
> Use a new libxl__xs_mkdir() to do this and also clean up extraneous
> path creation while in the neighbourhood. Checking 'xenstore-ls -fp'
> output before and after shows that, as well as the disappearance of
> error, drivers, messages and domid, the following perms change is
> also present:
> 
> -device/suspend = ""   (ndomU)
> +device/suspend = ""   (n0,rdomU)
> 
> I believe the new perms are more desirable than the old ones.
> 
> Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
> 
> diff -r 03138a08366b -r a8c26cdf079c tools/libxl/libxl_create.c
> --- a/tools/libxl/libxl_create.c	Fri Dec 09 16:19:36 2011 +0000
> +++ b/tools/libxl/libxl_create.c	Fri Dec 16 14:12:15 2011 +0000
> @@ -320,11 +320,8 @@ int libxl__domain_make(libxl__gc *gc, li
>    * on exit (even error exit), domid may be valid and refer to a
> domain */  {
>      libxl_ctx *ctx = libxl__gc_owner(gc);
> -    int flags, ret, i, rc;
> +    int flags, ret, rc;
>      char *uuid_string;
> -    char *rw_paths[] = { "control/shutdown", "device",
> "device/suspend/event-channel" , "data"};
> -    char *ro_paths[] = { "cpu", "memory", "device", "error",
> "drivers",
> -                         "control", "attr", "messages" };
>      char *dom_path, *vm_path, *libxl_path;
>      struct xs_permissions roperm[2];
>      struct xs_permissions rwperm[1];
> @@ -384,6 +381,7 @@ int libxl__domain_make(libxl__gc *gc, li
>          rc = ERROR_FAIL;
>          goto out;
>      }
> +
>      noperm[0].id = 0;
>      noperm[0].perms = XS_PERM_NONE;
> 
> @@ -391,6 +389,7 @@ int libxl__domain_make(libxl__gc *gc, li
>      roperm[0].perms = XS_PERM_NONE;
>      roperm[1].id = *domid;
>      roperm[1].perms = XS_PERM_READ;
> +
>      rwperm[0].id = *domid;
>      rwperm[0].perms = XS_PERM_NONE;
> 
> @@ -398,32 +397,42 @@ retry_transaction:
>      t = xs_transaction_start(ctx->xsh);
> 
>      xs_rm(ctx->xsh, t, dom_path);
> -    xs_mkdir(ctx->xsh, t, dom_path);
> -    xs_set_permissions(ctx->xsh, t, dom_path, roperm,
> ARRAY_SIZE(roperm));
> +    libxl__xs_mkdir(gc, t, dom_path, roperm, ARRAY_SIZE(roperm));
> +
> 
>      xs_rm(ctx->xsh, t, vm_path);
> -    xs_mkdir(ctx->xsh, t, vm_path);
> -    xs_set_permissions(ctx->xsh, t, vm_path, roperm,
> ARRAY_SIZE(roperm));
> +    libxl__xs_mkdir(gc, t, vm_path, roperm, ARRAY_SIZE(roperm));
> 
>      xs_rm(ctx->xsh, t, libxl_path);
> -    xs_mkdir(ctx->xsh, t, libxl_path);
> -    xs_set_permissions(ctx->xsh, t, libxl_path, noperm,
> ARRAY_SIZE(noperm));
> +    libxl__xs_mkdir(gc, t, libxl_path, noperm, ARRAY_SIZE(noperm));
> 
>      xs_write(ctx->xsh, t, libxl__sprintf(gc, "%s/vm", dom_path),
> vm_path, strlen(vm_path));
>      rc = libxl__domain_rename(gc, *domid, 0, info->name, t);
>      if (rc)
>          goto out;
> 
> -    for (i = 0; i < ARRAY_SIZE(rw_paths); i++) {
> -        char *path = libxl__sprintf(gc, "%s/%s", dom_path,
> rw_paths[i]);
> -        xs_mkdir(ctx->xsh, t, path);
> -        xs_set_permissions(ctx->xsh, t, path, rwperm,
> ARRAY_SIZE(rwperm));
> -    }
> -    for (i = 0; i < ARRAY_SIZE(ro_paths); i++) {
> -        char *path = libxl__sprintf(gc, "%s/%s", dom_path,
> ro_paths[i]);
> -        xs_mkdir(ctx->xsh, t, path);
> -        xs_set_permissions(ctx->xsh, t, path, roperm,
> ARRAY_SIZE(roperm));
> -    }
> +    libxl__xs_mkdir(gc, t,
> +                    libxl__sprintf(gc, "%s/cpu", dom_path),
> +                    roperm, ARRAY_SIZE(roperm));
> +    libxl__xs_mkdir(gc, t,
> +                    libxl__sprintf(gc, "%s/memory", dom_path),
> +                    roperm, ARRAY_SIZE(roperm));
> +    libxl__xs_mkdir(gc, t,
> +                    libxl__sprintf(gc, "%s/device", dom_path),
> +                    roperm, ARRAY_SIZE(roperm));
> +    libxl__xs_mkdir(gc, t,
> +                    libxl__sprintf(gc, "%s/control", dom_path),
> +                    roperm, ARRAY_SIZE(roperm));
> +
> +    libxl__xs_mkdir(gc, t,
> +                    libxl__sprintf(gc, "%s/control/shutdown",
> dom_path),
> +                    rwperm, ARRAY_SIZE(rwperm));
> +    libxl__xs_mkdir(gc, t,
> +                    libxl__sprintf(gc, "%s/device/suspend/event-
> channel", dom_path),
> +                    rwperm, ARRAY_SIZE(rwperm));
> +    libxl__xs_mkdir(gc, t,
> +                    libxl__sprintf(gc, "%s/data", dom_path),
> +                    rwperm, ARRAY_SIZE(rwperm));
> 
>      xs_write(ctx->xsh, t, libxl__sprintf(gc, "%s/uuid", vm_path),
> uuid_string, strlen(uuid_string));
>      xs_write(ctx->xsh, t, libxl__sprintf(gc, "%s/name", vm_path),
> info->name, strlen(info->name)); diff -r 03138a08366b -r
> a8c26cdf079c tools/libxl/libxl_internal.h
> --- a/tools/libxl/libxl_internal.h	Fri Dec 09 16:19:36 2011 +0000
> +++ b/tools/libxl/libxl_internal.h	Fri Dec 16 14:12:15 2011 +0000
> @@ -204,6 +204,9 @@ _hidden char *libxl__xs_read(libxl__gc *
> _hidden char **libxl__xs_directory(libxl__gc *gc, xs_transaction_t
> t,
>                                     const char *path, unsigned int
> *nb);
>     /* On error: returns NULL, sets errno (no logging) */
> +_hidden bool libxl__xs_mkdir(libxl__gc *gc, xs_transaction_t t,
> +                             const char *path, struct
> xs_permissions *perms,
> +			     unsigned int num_perms);
> 
>  _hidden char *libxl__xs_libxl_path(libxl__gc *gc, uint32_t domid);
> 
> diff -r 03138a08366b -r a8c26cdf079c tools/libxl/libxl_xshelp.c
> --- a/tools/libxl/libxl_xshelp.c	Fri Dec 09 16:19:36 2011 +0000
> +++ b/tools/libxl/libxl_xshelp.c	Fri Dec 16 14:12:15 2011 +0000
> @@ -122,6 +122,16 @@ char **libxl__xs_directory(libxl__gc *gc
>      return ret;
>  }
> 
> +bool libxl__xs_mkdir(libxl__gc *gc, xs_transaction_t t,
> +                     const char *path, struct xs_permissions
> *perms,
> +			         unsigned int num_perms)
> +{
> +    libxl_ctx *ctx = libxl__gc_owner(gc);
> +    if (!xs_mkdir(ctx->xsh, t, path))
> +        return false;
> +    return xs_set_permissions(ctx->xsh, t, path, perms, num_perms);
> }
> +
>  char *libxl__xs_libxl_path(libxl__gc *gc, uint32_t domid)  {
>      libxl_ctx *ctx = libxl__gc_owner(gc);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 14:56:16 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 14:56:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbZCj-0001Et-Bp; Fri, 16 Dec 2011 14:56:09 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RbZCh-0001Dw-MZ
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 14:56:07 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1324047360!7647243!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjI0MzY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3353 invoked from network); 16 Dec 2011 14:56:01 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Dec 2011 14:56:01 -0000
X-IronPort-AV: E=Sophos;i="4.71,363,1320642000"; d="scan'208";a="174458357"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Dec 2011 09:55:59 -0500
Received: from cosworth.uk.xensource.com (10.80.16.52) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 16 Dec 2011 09:55:59 -0500
MIME-Version: 1.0
Message-ID: <patchbomb.1324047273@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 16 Dec 2011 14:54:33 +0000
From: Paul Durrant <paul.durrant@citrix.com>
To: xen-devel@lists.xensource.com
Cc: paul.durrant@citrix.com
Subject: [Xen-devel] [PATCH 0 of 4] Support for VM generation ID
	save/restore and migrate
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This patch series adds support for preservation of the VM generation ID buffer address in 
xenstore across save/restore and migrate, and also code to increment the value in all cases 
except for migration.

Patch 1 modifies the guest ro and rw node creation to an open coding style and cleans up some 
extraneous node creation.
Patch 2 modifies creation of the hvmloader key in xenstore and adds creation of a new read/write 
hvmloader/generation-id-addr key.
Patch 3 changes hvmloader to use the new key (as opposed to the old data/generation-id key). Note 
that it is safe to apply this patch independently of the others but it logically belongs at this 
position in the series.
Patch 4 adds the infrastructure to save and restore the VM generation ID address in xenstore and 
the code to increment the value.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 14:56:16 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 14:56:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbZCj-0001Et-Bp; Fri, 16 Dec 2011 14:56:09 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RbZCh-0001Dw-MZ
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 14:56:07 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1324047360!7647243!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjI0MzY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3353 invoked from network); 16 Dec 2011 14:56:01 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Dec 2011 14:56:01 -0000
X-IronPort-AV: E=Sophos;i="4.71,363,1320642000"; d="scan'208";a="174458357"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Dec 2011 09:55:59 -0500
Received: from cosworth.uk.xensource.com (10.80.16.52) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 16 Dec 2011 09:55:59 -0500
MIME-Version: 1.0
Message-ID: <patchbomb.1324047273@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 16 Dec 2011 14:54:33 +0000
From: Paul Durrant <paul.durrant@citrix.com>
To: xen-devel@lists.xensource.com
Cc: paul.durrant@citrix.com
Subject: [Xen-devel] [PATCH 0 of 4] Support for VM generation ID
	save/restore and migrate
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This patch series adds support for preservation of the VM generation ID buffer address in 
xenstore across save/restore and migrate, and also code to increment the value in all cases 
except for migration.

Patch 1 modifies the guest ro and rw node creation to an open coding style and cleans up some 
extraneous node creation.
Patch 2 modifies creation of the hvmloader key in xenstore and adds creation of a new read/write 
hvmloader/generation-id-addr key.
Patch 3 changes hvmloader to use the new key (as opposed to the old data/generation-id key). Note 
that it is safe to apply this patch independently of the others but it logically belongs at this 
position in the series.
Patch 4 adds the infrastructure to save and restore the VM generation ID address in xenstore and 
the code to increment the value.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 14:56:16 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 14:56:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbZCk-0001FH-5X; Fri, 16 Dec 2011 14:56:10 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RbZCi-0001E4-Ls
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 14:56:08 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1324047360!7689983!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDc2NTY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27891 invoked from network); 16 Dec 2011 14:56:02 -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;
	16 Dec 2011 14:56:02 -0000
X-IronPort-AV: E=Sophos;i="4.71,363,1320642000"; d="scan'208";a="20040735"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Dec 2011 09:56:00 -0500
Received: from cosworth.uk.xensource.com (10.80.16.52) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 16 Dec 2011 09:56:00 -0500
MIME-Version: 1.0
X-Mercurial-Node: 89d9abeb76c72c634a35ad32c983f2811b270ec9
Message-ID: <89d9abeb76c72c634a35.1324047274@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1324047273@cosworth.uk.xensource.com>
References: <patchbomb.1324047273@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 16 Dec 2011 14:54:34 +0000
From: Paul Durrant <paul.durrant@citrix.com>
To: xen-devel@lists.xensource.com
Cc: paul.durrant@citrix.com
Subject: [Xen-devel] [PATCH 1 of 4] Open code rw and ro node creation
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Paul Durrant <paul.durrant@citrix.com>
# Date 1324047253 0
# Node ID 89d9abeb76c72c634a35ad32c983f2811b270ec9
# Parent  03138a08366b895d79e143119d4c9c72833cdbcd
Open code rw and ro node creation.

Use a new libxl__xs_mkdir() to do this and also clean up extraneous node creation
while in the neighbourhood. Checking 'xenstore-ls -fp' output before and after
shows that, as well as the disappearance of error, drivers, messages and domid, the
following perms change is also present:

-device/suspend = ""   (ndomU)
+device/suspend = ""   (n0,rdomU)

I believe the new perms are more desirable than the old ones.

Signed-off-by: Paul Durrant <paul.durrant@citrix.com>

diff -r 03138a08366b -r 89d9abeb76c7 tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Fri Dec 09 16:19:36 2011 +0000
+++ b/tools/libxl/libxl_create.c	Fri Dec 16 14:54:13 2011 +0000
@@ -320,11 +320,8 @@ int libxl__domain_make(libxl__gc *gc, li
   * on exit (even error exit), domid may be valid and refer to a domain */
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
-    int flags, ret, i, rc;
+    int flags, ret, rc;
     char *uuid_string;
-    char *rw_paths[] = { "control/shutdown", "device", "device/suspend/event-channel" , "data"};
-    char *ro_paths[] = { "cpu", "memory", "device", "error", "drivers",
-                         "control", "attr", "messages" };
     char *dom_path, *vm_path, *libxl_path;
     struct xs_permissions roperm[2];
     struct xs_permissions rwperm[1];
@@ -384,6 +381,7 @@ int libxl__domain_make(libxl__gc *gc, li
         rc = ERROR_FAIL;
         goto out;
     }
+
     noperm[0].id = 0;
     noperm[0].perms = XS_PERM_NONE;
 
@@ -391,6 +389,7 @@ int libxl__domain_make(libxl__gc *gc, li
     roperm[0].perms = XS_PERM_NONE;
     roperm[1].id = *domid;
     roperm[1].perms = XS_PERM_READ;
+
     rwperm[0].id = *domid;
     rwperm[0].perms = XS_PERM_NONE;
 
@@ -398,32 +397,42 @@ retry_transaction:
     t = xs_transaction_start(ctx->xsh);
 
     xs_rm(ctx->xsh, t, dom_path);
-    xs_mkdir(ctx->xsh, t, dom_path);
-    xs_set_permissions(ctx->xsh, t, dom_path, roperm, ARRAY_SIZE(roperm));
+    libxl__xs_mkdir(gc, t, dom_path, roperm, ARRAY_SIZE(roperm));
+
 
     xs_rm(ctx->xsh, t, vm_path);
-    xs_mkdir(ctx->xsh, t, vm_path);
-    xs_set_permissions(ctx->xsh, t, vm_path, roperm, ARRAY_SIZE(roperm));
+    libxl__xs_mkdir(gc, t, vm_path, roperm, ARRAY_SIZE(roperm));
 
     xs_rm(ctx->xsh, t, libxl_path);
-    xs_mkdir(ctx->xsh, t, libxl_path);
-    xs_set_permissions(ctx->xsh, t, libxl_path, noperm, ARRAY_SIZE(noperm));
+    libxl__xs_mkdir(gc, t, libxl_path, noperm, ARRAY_SIZE(noperm));
 
     xs_write(ctx->xsh, t, libxl__sprintf(gc, "%s/vm", dom_path), vm_path, strlen(vm_path));
     rc = libxl__domain_rename(gc, *domid, 0, info->name, t);
     if (rc)
         goto out;
 
-    for (i = 0; i < ARRAY_SIZE(rw_paths); i++) {
-        char *path = libxl__sprintf(gc, "%s/%s", dom_path, rw_paths[i]);
-        xs_mkdir(ctx->xsh, t, path);
-        xs_set_permissions(ctx->xsh, t, path, rwperm, ARRAY_SIZE(rwperm));
-    }
-    for (i = 0; i < ARRAY_SIZE(ro_paths); i++) {
-        char *path = libxl__sprintf(gc, "%s/%s", dom_path, ro_paths[i]);
-        xs_mkdir(ctx->xsh, t, path);
-        xs_set_permissions(ctx->xsh, t, path, roperm, ARRAY_SIZE(roperm));
-    }
+    libxl__xs_mkdir(gc, t,
+                    libxl__sprintf(gc, "%s/cpu", dom_path),
+                    roperm, ARRAY_SIZE(roperm));
+    libxl__xs_mkdir(gc, t,
+                    libxl__sprintf(gc, "%s/memory", dom_path),
+                    roperm, ARRAY_SIZE(roperm));
+    libxl__xs_mkdir(gc, t,
+                    libxl__sprintf(gc, "%s/device", dom_path),
+                    roperm, ARRAY_SIZE(roperm));
+    libxl__xs_mkdir(gc, t,
+                    libxl__sprintf(gc, "%s/control", dom_path),
+                    roperm, ARRAY_SIZE(roperm));
+
+    libxl__xs_mkdir(gc, t,
+                    libxl__sprintf(gc, "%s/control/shutdown", dom_path),
+                    rwperm, ARRAY_SIZE(rwperm));
+    libxl__xs_mkdir(gc, t,
+                    libxl__sprintf(gc, "%s/device/suspend/event-channel", dom_path),
+                    rwperm, ARRAY_SIZE(rwperm));
+    libxl__xs_mkdir(gc, t,
+                    libxl__sprintf(gc, "%s/data", dom_path),
+                    rwperm, ARRAY_SIZE(rwperm));
 
     xs_write(ctx->xsh, t, libxl__sprintf(gc, "%s/uuid", vm_path), uuid_string, strlen(uuid_string));
     xs_write(ctx->xsh, t, libxl__sprintf(gc, "%s/name", vm_path), info->name, strlen(info->name));
diff -r 03138a08366b -r 89d9abeb76c7 tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Fri Dec 09 16:19:36 2011 +0000
+++ b/tools/libxl/libxl_internal.h	Fri Dec 16 14:54:13 2011 +0000
@@ -204,6 +204,9 @@ _hidden char *libxl__xs_read(libxl__gc *
 _hidden char **libxl__xs_directory(libxl__gc *gc, xs_transaction_t t,
                                    const char *path, unsigned int *nb);
    /* On error: returns NULL, sets errno (no logging) */
+_hidden bool libxl__xs_mkdir(libxl__gc *gc, xs_transaction_t t,
+                             const char *path, struct xs_permissions *perms,
+			     unsigned int num_perms);
 
 _hidden char *libxl__xs_libxl_path(libxl__gc *gc, uint32_t domid);
 
diff -r 03138a08366b -r 89d9abeb76c7 tools/libxl/libxl_xshelp.c
--- a/tools/libxl/libxl_xshelp.c	Fri Dec 09 16:19:36 2011 +0000
+++ b/tools/libxl/libxl_xshelp.c	Fri Dec 16 14:54:13 2011 +0000
@@ -122,6 +122,16 @@ char **libxl__xs_directory(libxl__gc *gc
     return ret;
 }
 
+bool libxl__xs_mkdir(libxl__gc *gc, xs_transaction_t t,
+                     const char *path, struct xs_permissions *perms,
+			         unsigned int num_perms)
+{
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+    if (!xs_mkdir(ctx->xsh, t, path))
+        return false;
+    return xs_set_permissions(ctx->xsh, t, path, perms, num_perms);
+}
+
 char *libxl__xs_libxl_path(libxl__gc *gc, uint32_t domid)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 14:56:16 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 14:56:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbZCk-0001FH-5X; Fri, 16 Dec 2011 14:56:10 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RbZCi-0001E4-Ls
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 14:56:08 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1324047360!7689983!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDc2NTY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27891 invoked from network); 16 Dec 2011 14:56:02 -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;
	16 Dec 2011 14:56:02 -0000
X-IronPort-AV: E=Sophos;i="4.71,363,1320642000"; d="scan'208";a="20040735"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Dec 2011 09:56:00 -0500
Received: from cosworth.uk.xensource.com (10.80.16.52) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 16 Dec 2011 09:56:00 -0500
MIME-Version: 1.0
X-Mercurial-Node: 89d9abeb76c72c634a35ad32c983f2811b270ec9
Message-ID: <89d9abeb76c72c634a35.1324047274@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1324047273@cosworth.uk.xensource.com>
References: <patchbomb.1324047273@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 16 Dec 2011 14:54:34 +0000
From: Paul Durrant <paul.durrant@citrix.com>
To: xen-devel@lists.xensource.com
Cc: paul.durrant@citrix.com
Subject: [Xen-devel] [PATCH 1 of 4] Open code rw and ro node creation
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Paul Durrant <paul.durrant@citrix.com>
# Date 1324047253 0
# Node ID 89d9abeb76c72c634a35ad32c983f2811b270ec9
# Parent  03138a08366b895d79e143119d4c9c72833cdbcd
Open code rw and ro node creation.

Use a new libxl__xs_mkdir() to do this and also clean up extraneous node creation
while in the neighbourhood. Checking 'xenstore-ls -fp' output before and after
shows that, as well as the disappearance of error, drivers, messages and domid, the
following perms change is also present:

-device/suspend = ""   (ndomU)
+device/suspend = ""   (n0,rdomU)

I believe the new perms are more desirable than the old ones.

Signed-off-by: Paul Durrant <paul.durrant@citrix.com>

diff -r 03138a08366b -r 89d9abeb76c7 tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Fri Dec 09 16:19:36 2011 +0000
+++ b/tools/libxl/libxl_create.c	Fri Dec 16 14:54:13 2011 +0000
@@ -320,11 +320,8 @@ int libxl__domain_make(libxl__gc *gc, li
   * on exit (even error exit), domid may be valid and refer to a domain */
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
-    int flags, ret, i, rc;
+    int flags, ret, rc;
     char *uuid_string;
-    char *rw_paths[] = { "control/shutdown", "device", "device/suspend/event-channel" , "data"};
-    char *ro_paths[] = { "cpu", "memory", "device", "error", "drivers",
-                         "control", "attr", "messages" };
     char *dom_path, *vm_path, *libxl_path;
     struct xs_permissions roperm[2];
     struct xs_permissions rwperm[1];
@@ -384,6 +381,7 @@ int libxl__domain_make(libxl__gc *gc, li
         rc = ERROR_FAIL;
         goto out;
     }
+
     noperm[0].id = 0;
     noperm[0].perms = XS_PERM_NONE;
 
@@ -391,6 +389,7 @@ int libxl__domain_make(libxl__gc *gc, li
     roperm[0].perms = XS_PERM_NONE;
     roperm[1].id = *domid;
     roperm[1].perms = XS_PERM_READ;
+
     rwperm[0].id = *domid;
     rwperm[0].perms = XS_PERM_NONE;
 
@@ -398,32 +397,42 @@ retry_transaction:
     t = xs_transaction_start(ctx->xsh);
 
     xs_rm(ctx->xsh, t, dom_path);
-    xs_mkdir(ctx->xsh, t, dom_path);
-    xs_set_permissions(ctx->xsh, t, dom_path, roperm, ARRAY_SIZE(roperm));
+    libxl__xs_mkdir(gc, t, dom_path, roperm, ARRAY_SIZE(roperm));
+
 
     xs_rm(ctx->xsh, t, vm_path);
-    xs_mkdir(ctx->xsh, t, vm_path);
-    xs_set_permissions(ctx->xsh, t, vm_path, roperm, ARRAY_SIZE(roperm));
+    libxl__xs_mkdir(gc, t, vm_path, roperm, ARRAY_SIZE(roperm));
 
     xs_rm(ctx->xsh, t, libxl_path);
-    xs_mkdir(ctx->xsh, t, libxl_path);
-    xs_set_permissions(ctx->xsh, t, libxl_path, noperm, ARRAY_SIZE(noperm));
+    libxl__xs_mkdir(gc, t, libxl_path, noperm, ARRAY_SIZE(noperm));
 
     xs_write(ctx->xsh, t, libxl__sprintf(gc, "%s/vm", dom_path), vm_path, strlen(vm_path));
     rc = libxl__domain_rename(gc, *domid, 0, info->name, t);
     if (rc)
         goto out;
 
-    for (i = 0; i < ARRAY_SIZE(rw_paths); i++) {
-        char *path = libxl__sprintf(gc, "%s/%s", dom_path, rw_paths[i]);
-        xs_mkdir(ctx->xsh, t, path);
-        xs_set_permissions(ctx->xsh, t, path, rwperm, ARRAY_SIZE(rwperm));
-    }
-    for (i = 0; i < ARRAY_SIZE(ro_paths); i++) {
-        char *path = libxl__sprintf(gc, "%s/%s", dom_path, ro_paths[i]);
-        xs_mkdir(ctx->xsh, t, path);
-        xs_set_permissions(ctx->xsh, t, path, roperm, ARRAY_SIZE(roperm));
-    }
+    libxl__xs_mkdir(gc, t,
+                    libxl__sprintf(gc, "%s/cpu", dom_path),
+                    roperm, ARRAY_SIZE(roperm));
+    libxl__xs_mkdir(gc, t,
+                    libxl__sprintf(gc, "%s/memory", dom_path),
+                    roperm, ARRAY_SIZE(roperm));
+    libxl__xs_mkdir(gc, t,
+                    libxl__sprintf(gc, "%s/device", dom_path),
+                    roperm, ARRAY_SIZE(roperm));
+    libxl__xs_mkdir(gc, t,
+                    libxl__sprintf(gc, "%s/control", dom_path),
+                    roperm, ARRAY_SIZE(roperm));
+
+    libxl__xs_mkdir(gc, t,
+                    libxl__sprintf(gc, "%s/control/shutdown", dom_path),
+                    rwperm, ARRAY_SIZE(rwperm));
+    libxl__xs_mkdir(gc, t,
+                    libxl__sprintf(gc, "%s/device/suspend/event-channel", dom_path),
+                    rwperm, ARRAY_SIZE(rwperm));
+    libxl__xs_mkdir(gc, t,
+                    libxl__sprintf(gc, "%s/data", dom_path),
+                    rwperm, ARRAY_SIZE(rwperm));
 
     xs_write(ctx->xsh, t, libxl__sprintf(gc, "%s/uuid", vm_path), uuid_string, strlen(uuid_string));
     xs_write(ctx->xsh, t, libxl__sprintf(gc, "%s/name", vm_path), info->name, strlen(info->name));
diff -r 03138a08366b -r 89d9abeb76c7 tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Fri Dec 09 16:19:36 2011 +0000
+++ b/tools/libxl/libxl_internal.h	Fri Dec 16 14:54:13 2011 +0000
@@ -204,6 +204,9 @@ _hidden char *libxl__xs_read(libxl__gc *
 _hidden char **libxl__xs_directory(libxl__gc *gc, xs_transaction_t t,
                                    const char *path, unsigned int *nb);
    /* On error: returns NULL, sets errno (no logging) */
+_hidden bool libxl__xs_mkdir(libxl__gc *gc, xs_transaction_t t,
+                             const char *path, struct xs_permissions *perms,
+			     unsigned int num_perms);
 
 _hidden char *libxl__xs_libxl_path(libxl__gc *gc, uint32_t domid);
 
diff -r 03138a08366b -r 89d9abeb76c7 tools/libxl/libxl_xshelp.c
--- a/tools/libxl/libxl_xshelp.c	Fri Dec 09 16:19:36 2011 +0000
+++ b/tools/libxl/libxl_xshelp.c	Fri Dec 16 14:54:13 2011 +0000
@@ -122,6 +122,16 @@ char **libxl__xs_directory(libxl__gc *gc
     return ret;
 }
 
+bool libxl__xs_mkdir(libxl__gc *gc, xs_transaction_t t,
+                     const char *path, struct xs_permissions *perms,
+			         unsigned int num_perms)
+{
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+    if (!xs_mkdir(ctx->xsh, t, path))
+        return false;
+    return xs_set_permissions(ctx->xsh, t, path, perms, num_perms);
+}
+
 char *libxl__xs_libxl_path(libxl__gc *gc, uint32_t domid)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 14:56:16 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 14:56:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbZCj-0001F4-Of; Fri, 16 Dec 2011 14:56:09 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RbZCi-0001E1-B6
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 14:56:08 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1324047360!7647243!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjI0MzY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3439 invoked from network); 16 Dec 2011 14:56:02 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Dec 2011 14:56:02 -0000
X-IronPort-AV: E=Sophos;i="4.71,363,1320642000"; d="scan'208";a="174458362"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Dec 2011 09:56:01 -0500
Received: from cosworth.uk.xensource.com (10.80.16.52) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 16 Dec 2011 09:56:00 -0500
MIME-Version: 1.0
X-Mercurial-Node: 67797c4782d97efa1d9c19f8d13636d6f4730a3b
Message-ID: <67797c4782d97efa1d9c.1324047275@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1324047273@cosworth.uk.xensource.com>
References: <patchbomb.1324047273@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 16 Dec 2011 14:54:35 +0000
From: Paul Durrant <paul.durrant@citrix.com>
To: xen-devel@lists.xensource.com
Cc: paul.durrant@citrix.com
Subject: [Xen-devel] [PATCH 2 of 4] Add hvm specific ro and rw nodes
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Paul Durrant <paul.durrant@citrix.com>
# Date 1324047253 0
# Node ID 67797c4782d97efa1d9c19f8d13636d6f4730a3b
# Parent  89d9abeb76c72c634a35ad32c983f2811b270ec9
Add hvm specific ro and rw nodes.

The hvmloader node was created by libxl__create_device_model() but it
needs to be moved earlier so that it can parent the new rw
generation-id-address node.

Signed-off-by: Paul Durrant <paul.durrant@citrix.com>

diff -r 89d9abeb76c7 -r 67797c4782d9 tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Fri Dec 16 14:54:13 2011 +0000
+++ b/tools/libxl/libxl_create.c	Fri Dec 16 14:54:13 2011 +0000
@@ -423,6 +423,10 @@ retry_transaction:
     libxl__xs_mkdir(gc, t,
                     libxl__sprintf(gc, "%s/control", dom_path),
                     roperm, ARRAY_SIZE(roperm));
+    if (info->type == LIBXL_DOMAIN_TYPE_HVM)
+        libxl__xs_mkdir(gc, t,
+                        libxl__sprintf(gc, "%s/hvmloader", dom_path),
+                        roperm, ARRAY_SIZE(roperm));
 
     libxl__xs_mkdir(gc, t,
                     libxl__sprintf(gc, "%s/control/shutdown", dom_path),
@@ -433,6 +437,10 @@ retry_transaction:
     libxl__xs_mkdir(gc, t,
                     libxl__sprintf(gc, "%s/data", dom_path),
                     rwperm, ARRAY_SIZE(rwperm));
+    if (info->type == LIBXL_DOMAIN_TYPE_HVM)
+        libxl__xs_mkdir(gc, t,
+                        libxl__sprintf(gc, "%s/hvmloader/generation-id-address", dom_path),
+                        rwperm, ARRAY_SIZE(rwperm));
 
     xs_write(ctx->xsh, t, libxl__sprintf(gc, "%s/uuid", vm_path), uuid_string, strlen(uuid_string));
     xs_write(ctx->xsh, t, libxl__sprintf(gc, "%s/name", vm_path), info->name, strlen(info->name));
diff -r 89d9abeb76c7 -r 67797c4782d9 tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Fri Dec 16 14:54:13 2011 +0000
+++ b/tools/libxl/libxl_dm.c	Fri Dec 16 14:54:13 2011 +0000
@@ -821,10 +821,10 @@ int libxl__create_device_model(libxl__gc
         goto out;
     }
 
-    path = libxl__sprintf(gc, "/local/domain/%d/hvmloader", info->domid);
-    xs_mkdir(ctx->xsh, XBT_NULL, path);
-    libxl__xs_write(gc, XBT_NULL, libxl__sprintf(gc, "%s/bios", path),
+    path = xs_get_domain_path(ctx->xsh, info->domid);
+    libxl__xs_write(gc, XBT_NULL, libxl__sprintf(gc, "%s/hvmloader/bios", path),
                     "%s", libxl__domain_bios(gc, info));
+    free(path);
 
     path = libxl__sprintf(gc, "/local/domain/0/device-model/%d", info->domid);
     xs_mkdir(ctx->xsh, XBT_NULL, path);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 14:56:16 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 14:56:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbZCj-0001F4-Of; Fri, 16 Dec 2011 14:56:09 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RbZCi-0001E1-B6
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 14:56:08 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1324047360!7647243!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjI0MzY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3439 invoked from network); 16 Dec 2011 14:56:02 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Dec 2011 14:56:02 -0000
X-IronPort-AV: E=Sophos;i="4.71,363,1320642000"; d="scan'208";a="174458362"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Dec 2011 09:56:01 -0500
Received: from cosworth.uk.xensource.com (10.80.16.52) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 16 Dec 2011 09:56:00 -0500
MIME-Version: 1.0
X-Mercurial-Node: 67797c4782d97efa1d9c19f8d13636d6f4730a3b
Message-ID: <67797c4782d97efa1d9c.1324047275@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1324047273@cosworth.uk.xensource.com>
References: <patchbomb.1324047273@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 16 Dec 2011 14:54:35 +0000
From: Paul Durrant <paul.durrant@citrix.com>
To: xen-devel@lists.xensource.com
Cc: paul.durrant@citrix.com
Subject: [Xen-devel] [PATCH 2 of 4] Add hvm specific ro and rw nodes
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Paul Durrant <paul.durrant@citrix.com>
# Date 1324047253 0
# Node ID 67797c4782d97efa1d9c19f8d13636d6f4730a3b
# Parent  89d9abeb76c72c634a35ad32c983f2811b270ec9
Add hvm specific ro and rw nodes.

The hvmloader node was created by libxl__create_device_model() but it
needs to be moved earlier so that it can parent the new rw
generation-id-address node.

Signed-off-by: Paul Durrant <paul.durrant@citrix.com>

diff -r 89d9abeb76c7 -r 67797c4782d9 tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Fri Dec 16 14:54:13 2011 +0000
+++ b/tools/libxl/libxl_create.c	Fri Dec 16 14:54:13 2011 +0000
@@ -423,6 +423,10 @@ retry_transaction:
     libxl__xs_mkdir(gc, t,
                     libxl__sprintf(gc, "%s/control", dom_path),
                     roperm, ARRAY_SIZE(roperm));
+    if (info->type == LIBXL_DOMAIN_TYPE_HVM)
+        libxl__xs_mkdir(gc, t,
+                        libxl__sprintf(gc, "%s/hvmloader", dom_path),
+                        roperm, ARRAY_SIZE(roperm));
 
     libxl__xs_mkdir(gc, t,
                     libxl__sprintf(gc, "%s/control/shutdown", dom_path),
@@ -433,6 +437,10 @@ retry_transaction:
     libxl__xs_mkdir(gc, t,
                     libxl__sprintf(gc, "%s/data", dom_path),
                     rwperm, ARRAY_SIZE(rwperm));
+    if (info->type == LIBXL_DOMAIN_TYPE_HVM)
+        libxl__xs_mkdir(gc, t,
+                        libxl__sprintf(gc, "%s/hvmloader/generation-id-address", dom_path),
+                        rwperm, ARRAY_SIZE(rwperm));
 
     xs_write(ctx->xsh, t, libxl__sprintf(gc, "%s/uuid", vm_path), uuid_string, strlen(uuid_string));
     xs_write(ctx->xsh, t, libxl__sprintf(gc, "%s/name", vm_path), info->name, strlen(info->name));
diff -r 89d9abeb76c7 -r 67797c4782d9 tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Fri Dec 16 14:54:13 2011 +0000
+++ b/tools/libxl/libxl_dm.c	Fri Dec 16 14:54:13 2011 +0000
@@ -821,10 +821,10 @@ int libxl__create_device_model(libxl__gc
         goto out;
     }
 
-    path = libxl__sprintf(gc, "/local/domain/%d/hvmloader", info->domid);
-    xs_mkdir(ctx->xsh, XBT_NULL, path);
-    libxl__xs_write(gc, XBT_NULL, libxl__sprintf(gc, "%s/bios", path),
+    path = xs_get_domain_path(ctx->xsh, info->domid);
+    libxl__xs_write(gc, XBT_NULL, libxl__sprintf(gc, "%s/hvmloader/bios", path),
                     "%s", libxl__domain_bios(gc, info));
+    free(path);
 
     path = libxl__sprintf(gc, "/local/domain/0/device-model/%d", info->domid);
     xs_mkdir(ctx->xsh, XBT_NULL, path);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 14:56:17 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 14:56:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbZCk-0001FV-Iq; Fri, 16 Dec 2011 14:56:10 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RbZCj-0001E6-4r
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 14:56:09 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1324047360!7689983!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDc2NTY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27929 invoked from network); 16 Dec 2011 14:56:02 -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;
	16 Dec 2011 14:56:02 -0000
X-IronPort-AV: E=Sophos;i="4.71,363,1320642000"; d="scan'208";a="20040739"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Dec 2011 09:56:01 -0500
Received: from cosworth.uk.xensource.com (10.80.16.52) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 16 Dec 2011 09:56:01 -0500
MIME-Version: 1.0
X-Mercurial-Node: fa0f840c516b6d6db7f9c8903e06335c1cb87f44
Message-ID: <fa0f840c516b6d6db7f9.1324047276@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1324047273@cosworth.uk.xensource.com>
References: <patchbomb.1324047273@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 16 Dec 2011 14:54:36 +0000
From: Paul Durrant <paul.durrant@citrix.com>
To: xen-devel@lists.xensource.com
Cc: paul.durrant@citrix.com
Subject: [Xen-devel] [PATCH 3 of 4] Re-name xenstore key used to save VM
 generation ID buffer address
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Paul Durrant <paul.durrant@citrix.com>
# Date 1324047253 0
# Node ID fa0f840c516b6d6db7f9c8903e06335c1cb87f44
# Parent  67797c4782d97efa1d9c19f8d13636d6f4730a3b
Re-name xenstore key used to save VM generation ID buffer address.

Signed-off-by: Paul Durrant <paul.durrant@citrix.com>

diff -r 67797c4782d9 -r fa0f840c516b tools/firmware/hvmloader/acpi/build.c
--- a/tools/firmware/hvmloader/acpi/build.c	Fri Dec 16 14:54:13 2011 +0000
+++ b/tools/firmware/hvmloader/acpi/build.c	Fri Dec 16 14:54:13 2011 +0000
@@ -309,7 +309,7 @@ unsigned long new_vm_gid(void)
     if ( snprintf(addr, sizeof(addr), "0x%lx", virt_to_phys(buf))
          >= sizeof(addr) )
         return 0;
-    xenstore_write("data/generation-id", addr);
+    xenstore_write("hvmloader/generation-id-address", addr);
 
     gid = strtoll(xenstore_read("platform/generation-id", "0"), NULL, 0);
     *(uint64_t *)buf = gid;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 14:56:17 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 14:56:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbZCk-0001FV-Iq; Fri, 16 Dec 2011 14:56:10 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RbZCj-0001E6-4r
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 14:56:09 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1324047360!7689983!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDc2NTY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27929 invoked from network); 16 Dec 2011 14:56:02 -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;
	16 Dec 2011 14:56:02 -0000
X-IronPort-AV: E=Sophos;i="4.71,363,1320642000"; d="scan'208";a="20040739"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Dec 2011 09:56:01 -0500
Received: from cosworth.uk.xensource.com (10.80.16.52) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 16 Dec 2011 09:56:01 -0500
MIME-Version: 1.0
X-Mercurial-Node: fa0f840c516b6d6db7f9c8903e06335c1cb87f44
Message-ID: <fa0f840c516b6d6db7f9.1324047276@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1324047273@cosworth.uk.xensource.com>
References: <patchbomb.1324047273@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 16 Dec 2011 14:54:36 +0000
From: Paul Durrant <paul.durrant@citrix.com>
To: xen-devel@lists.xensource.com
Cc: paul.durrant@citrix.com
Subject: [Xen-devel] [PATCH 3 of 4] Re-name xenstore key used to save VM
 generation ID buffer address
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Paul Durrant <paul.durrant@citrix.com>
# Date 1324047253 0
# Node ID fa0f840c516b6d6db7f9c8903e06335c1cb87f44
# Parent  67797c4782d97efa1d9c19f8d13636d6f4730a3b
Re-name xenstore key used to save VM generation ID buffer address.

Signed-off-by: Paul Durrant <paul.durrant@citrix.com>

diff -r 67797c4782d9 -r fa0f840c516b tools/firmware/hvmloader/acpi/build.c
--- a/tools/firmware/hvmloader/acpi/build.c	Fri Dec 16 14:54:13 2011 +0000
+++ b/tools/firmware/hvmloader/acpi/build.c	Fri Dec 16 14:54:13 2011 +0000
@@ -309,7 +309,7 @@ unsigned long new_vm_gid(void)
     if ( snprintf(addr, sizeof(addr), "0x%lx", virt_to_phys(buf))
          >= sizeof(addr) )
         return 0;
-    xenstore_write("data/generation-id", addr);
+    xenstore_write("hvmloader/generation-id-address", addr);
 
     gid = strtoll(xenstore_read("platform/generation-id", "0"), NULL, 0);
     *(uint64_t *)buf = gid;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 14:56:17 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 14:56:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbZCn-0001Gb-0j; Fri, 16 Dec 2011 14:56:13 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RbZCl-0001EF-AH
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 14:56:11 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1324047363!7553767!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjI0MzY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16570 invoked from network); 16 Dec 2011 14:56:04 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Dec 2011 14:56:04 -0000
X-IronPort-AV: E=Sophos;i="4.71,363,1320642000"; d="scan'208";a="174458365"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Dec 2011 09:56:02 -0500
Received: from cosworth.uk.xensource.com (10.80.16.52) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 16 Dec 2011 09:56:02 -0500
MIME-Version: 1.0
X-Mercurial-Node: 2ec1d2a1372cd84d1fa636f54aeedaed57d84791
Message-ID: <2ec1d2a1372cd84d1fa6.1324047277@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1324047273@cosworth.uk.xensource.com>
References: <patchbomb.1324047273@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 16 Dec 2011 14:54:37 +0000
From: Paul Durrant <paul.durrant@citrix.com>
To: xen-devel@lists.xensource.com
Cc: paul.durrant@citrix.com
Subject: [Xen-devel] [PATCH 4 of 4] VM generation ID save/restore and migrate
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Paul Durrant <paul.durrant@citrix.com>
# Date 1324047254 0
# Node ID 2ec1d2a1372cd84d1fa636f54aeedaed57d84791
# Parent  fa0f840c516b6d6db7f9c8903e06335c1cb87f44
VM generation ID save/restore and migrate.

Add code to track the address of the VM generation ID buffer across a
save/restore or migrate, and increment it as necessary.
The address of the buffer is written into xenstore by hvmloader at
boot time. It must be read from xenstore by the caller of
xc_domain_save() and then written back again by the caller of
xc_domain_restore().

Note that the changes to xc_save.c and xc_restore.c are merely
sufficient for them to build.

Signed-off-by: Paul Durrant <paul.durrant@citrix.com>

diff -r fa0f840c516b -r 2ec1d2a1372c tools/libxc/ia64/xc_ia64_linux_restore.c
--- a/tools/libxc/ia64/xc_ia64_linux_restore.c	Fri Dec 16 14:54:13 2011 +0000
+++ b/tools/libxc/ia64/xc_ia64_linux_restore.c	Fri Dec 16 14:54:14 2011 +0000
@@ -548,7 +548,9 @@ int
 xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
                   unsigned int store_evtchn, unsigned long *store_mfn,
                   unsigned int console_evtchn, unsigned long *console_mfn,
-                  unsigned int hvm, unsigned int pae, int superpages)
+                  unsigned int hvm, unsigned int pae, int superpages,
+                  int no_incr_generationid,
+                  unsigned long *vm_generationid_addr)
 {
     DECLARE_DOMCTL;
     int rc = 1;
diff -r fa0f840c516b -r 2ec1d2a1372c tools/libxc/ia64/xc_ia64_linux_save.c
--- a/tools/libxc/ia64/xc_ia64_linux_save.c	Fri Dec 16 14:54:13 2011 +0000
+++ b/tools/libxc/ia64/xc_ia64_linux_save.c	Fri Dec 16 14:54:14 2011 +0000
@@ -382,7 +382,8 @@ out:
 int
 xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iters,
                uint32_t max_factor, uint32_t flags,
-               struct save_callbacks* callbacks, int hvm)
+               struct save_callbacks* callbacks, int hvm,
+               unsigned long vm_generationid_addr)
 {
     DECLARE_DOMCTL;
     xc_dominfo_t info;
diff -r fa0f840c516b -r 2ec1d2a1372c tools/libxc/xc_domain_restore.c
--- a/tools/libxc/xc_domain_restore.c	Fri Dec 16 14:54:13 2011 +0000
+++ b/tools/libxc/xc_domain_restore.c	Fri Dec 16 14:54:14 2011 +0000
@@ -681,6 +681,7 @@ typedef struct {
     uint64_t console_pfn;
     uint64_t acpi_ioport_location;
     uint64_t viridian;
+    uint64_t vm_generationid_addr;
 } pagebuf_t;
 
 static int pagebuf_init(pagebuf_t* buf)
@@ -860,6 +861,17 @@ static int pagebuf_get_one(xc_interface 
         }
         return compbuf_size;
 
+    case XC_SAVE_ID_HVM_GENERATION_ID_ADDR:
+        /* Skip padding 4 bytes then read the generation id buffer location. */
+        if ( RDEXACT(fd, &buf->vm_generationid_addr, sizeof(uint32_t)) ||
+             RDEXACT(fd, &buf->vm_generationid_addr, sizeof(uint64_t)) )
+        {
+            PERROR("error read the generation id buffer location");
+            return -1;
+        }
+        DPRINTF("read generation id buffer address");
+        return pagebuf_get_one(xch, ctx, buf, fd, dom);
+
     default:
         if ( (count > MAX_BATCH_SIZE) || (count < 0) ) {
             ERROR("Max batch size exceeded (%d). Giving up.", count);
@@ -1248,7 +1260,9 @@ static int apply_batch(xc_interface *xch
 int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
                       unsigned int store_evtchn, unsigned long *store_mfn,
                       unsigned int console_evtchn, unsigned long *console_mfn,
-                      unsigned int hvm, unsigned int pae, int superpages)
+                      unsigned int hvm, unsigned int pae, int superpages,
+                      int no_incr_generationid,
+                      unsigned long *vm_generationid_addr)
 {
     DECLARE_DOMCTL;
     int rc = 1, frc, i, j, n, m, pae_extended_cr3 = 0, ext_vcpucontext = 0;
@@ -1449,6 +1463,39 @@ int xc_domain_restore(xc_interface *xch,
                 xc_set_hvm_param(xch, dom, HVM_PARAM_VM86_TSS, pagebuf.vm86_tss);
             if ( pagebuf.console_pfn )
                 console_pfn = pagebuf.console_pfn;
+            if ( pagebuf.vm_generationid_addr ) {
+                if ( !no_incr_generationid ) {
+                    unsigned int offset;
+                    unsigned char *buf;
+                    unsigned long long generationid;
+
+                    /*
+                     * Map the VM generation id buffer and inject the new value.
+                     */
+
+                    pfn = pagebuf.vm_generationid_addr >> PAGE_SHIFT;
+                    offset = pagebuf.vm_generationid_addr & (PAGE_SIZE - 1);
+                
+                    if ( (pfn >= dinfo->p2m_size) ||
+                         (pfn_type[pfn] != XEN_DOMCTL_PFINFO_NOTAB) )
+                    {
+                        ERROR("generation id buffer frame is bad");
+                        goto out;
+                    }
+
+                    mfn = ctx->p2m[pfn];
+                    buf = xc_map_foreign_range(xch, dom, PAGE_SIZE,
+                                               PROT_READ | PROT_WRITE, mfn);
+
+                    generationid = *(unsigned long long *)(buf + offset);
+                    *(unsigned long long *)(buf + offset) = generationid + 1;
+
+                    munmap(buf, PAGE_SIZE);
+                }
+
+                *vm_generationid_addr = pagebuf.vm_generationid_addr;
+            }
+
             break;  /* our work here is done */
         }
 
diff -r fa0f840c516b -r 2ec1d2a1372c tools/libxc/xc_domain_save.c
--- a/tools/libxc/xc_domain_save.c	Fri Dec 16 14:54:13 2011 +0000
+++ b/tools/libxc/xc_domain_save.c	Fri Dec 16 14:54:14 2011 +0000
@@ -804,7 +804,8 @@ static int save_tsc_info(xc_interface *x
 
 int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iters,
                    uint32_t max_factor, uint32_t flags,
-                   struct save_callbacks* callbacks, int hvm)
+                   struct save_callbacks* callbacks, int hvm,
+                   unsigned long vm_generationid_addr)
 {
     xc_dominfo_t info;
     DECLARE_DOMCTL;
@@ -1616,6 +1617,16 @@ int xc_domain_save(xc_interface *xch, in
             uint64_t data;
         } chunk = { 0, };
 
+        chunk.id = XC_SAVE_ID_HVM_GENERATION_ID_ADDR;
+        chunk.data = vm_generationid_addr;
+
+        if ( (chunk.data != 0) &&
+             wrexact(io_fd, &chunk, sizeof(chunk)) )
+        {
+            PERROR("Error when writing the generation id buffer location for guest");
+            goto out;
+        }
+
         chunk.id = XC_SAVE_ID_HVM_IDENT_PT;
         chunk.data = 0;
         xc_get_hvm_param(xch, dom, HVM_PARAM_IDENT_PT,
diff -r fa0f840c516b -r 2ec1d2a1372c tools/libxc/xenguest.h
--- a/tools/libxc/xenguest.h	Fri Dec 16 14:54:13 2011 +0000
+++ b/tools/libxc/xenguest.h	Fri Dec 16 14:54:14 2011 +0000
@@ -58,7 +58,8 @@ struct save_callbacks {
  */
 int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iters,
                    uint32_t max_factor, uint32_t flags /* XCFLAGS_xxx */,
-                   struct save_callbacks* callbacks, int hvm);
+                   struct save_callbacks* callbacks, int hvm,
+                   unsigned long vm_generationid_addr);
 
 
 /**
@@ -72,12 +73,16 @@ int xc_domain_save(xc_interface *xch, in
  * @parm hvm non-zero if this is a HVM restore
  * @parm pae non-zero if this HVM domain has PAE support enabled
  * @parm superpages non-zero to allocate guest memory with superpages
+ * @parm no_incr_generationid non-zero if generation id is NOT to be incremented
+ * @parm vm_generationid_addr returned with the address of the generation id buffer
  * @return 0 on success, -1 on failure
  */
 int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
                       unsigned int store_evtchn, unsigned long *store_mfn,
                       unsigned int console_evtchn, unsigned long *console_mfn,
-                      unsigned int hvm, unsigned int pae, int superpages);
+                      unsigned int hvm, unsigned int pae, int superpages,
+                      int no_incr_generationid,
+		      unsigned long *vm_generationid_addr);
 /**
  * xc_domain_restore writes a file to disk that contains the device
  * model saved state.
diff -r fa0f840c516b -r 2ec1d2a1372c tools/libxc/xg_save_restore.h
--- a/tools/libxc/xg_save_restore.h	Fri Dec 16 14:54:13 2011 +0000
+++ b/tools/libxc/xg_save_restore.h	Fri Dec 16 14:54:14 2011 +0000
@@ -253,6 +253,7 @@
 #define XC_SAVE_ID_HVM_VIRIDIAN       -11
 #define XC_SAVE_ID_COMPRESSED_DATA    -12 /* Marker to indicate arrival of compressed data */
 #define XC_SAVE_ID_ENABLE_COMPRESSION -13 /* Marker to enable compression logic at receiver side */
+#define XC_SAVE_ID_HVM_GENERATION_ID_ADDR -14
 
 /*
 ** We process save/restore/migrate in batches of pages; the below
diff -r fa0f840c516b -r 2ec1d2a1372c tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Fri Dec 16 14:54:13 2011 +0000
+++ b/tools/libxl/libxl_create.c	Fri Dec 16 14:54:14 2011 +0000
@@ -99,6 +99,7 @@ int libxl_init_build_info(libxl_ctx *ctx
         b_info->u.hvm.vpt_align = 1;
         b_info->u.hvm.timer_mode = 1;
         b_info->u.hvm.nested_hvm = 0;
+        b_info->u.hvm.no_incr_generationid = 0;
         break;
     case LIBXL_DOMAIN_TYPE_PV:
         b_info->u.pv.slack_memkb = 8 * 1024;
diff -r fa0f840c516b -r 2ec1d2a1372c tools/libxl/libxl_dom.c
--- a/tools/libxl/libxl_dom.c	Fri Dec 16 14:54:13 2011 +0000
+++ b/tools/libxl/libxl_dom.c	Fri Dec 16 14:54:14 2011 +0000
@@ -106,6 +106,7 @@ int libxl__build_pre(libxl__gc *gc, uint
 
     state->store_port = xc_evtchn_alloc_unbound(ctx->xch, domid, 0);
     state->console_port = xc_evtchn_alloc_unbound(ctx->xch, domid, 0);
+    state->vm_generationid_addr = 0;
     return 0;
 }
 
@@ -117,7 +118,7 @@ int libxl__build_post(libxl__gc *gc, uin
     libxl_ctx *ctx = libxl__gc_owner(gc);
     char *dom_path, *vm_path;
     xs_transaction_t t;
-    char **ents;
+    char **ents, **hvm_ents;
     int i;
 
     libxl_cpuid_apply_policy(ctx, domid);
@@ -143,6 +144,13 @@ int libxl__build_post(libxl__gc *gc, uin
                             ? "offline" : "online";
     }
 
+    hvm_ents = NULL;
+    if (info->type == LIBXL_DOMAIN_TYPE_HVM) {
+        hvm_ents = libxl__calloc(gc, 3, sizeof(char *));
+        hvm_ents[0] = "hvmloader/generation-id-address";
+        hvm_ents[1] = libxl__sprintf(gc, "0x%lx", state->vm_generationid_addr);
+    }
+
     dom_path = libxl__xs_get_dompath(gc, domid);
     if (!dom_path) {
         return ERROR_FAIL;
@@ -153,6 +161,9 @@ retry_transaction:
     t = xs_transaction_start(ctx->xsh);
 
     libxl__xs_writev(gc, t, dom_path, ents);
+    if (info->type == LIBXL_DOMAIN_TYPE_HVM)
+        libxl__xs_writev(gc, t, dom_path, hvm_ents);
+
     libxl__xs_writev(gc, t, dom_path, local_ents);
     libxl__xs_writev(gc, t, vm_path, vms_ents);
 
@@ -356,16 +367,19 @@ int libxl__domain_restore_common(libxl__
     /* read signature */
     int rc;
     int hvm, pae, superpages;
+    int no_incr_generationid;
     switch (info->type) {
     case LIBXL_DOMAIN_TYPE_HVM:
         hvm = 1;
         superpages = 1;
         pae = info->u.hvm.pae;
+        no_incr_generationid = info->u.hvm.no_incr_generationid;
         break;
     case LIBXL_DOMAIN_TYPE_PV:
         hvm = 0;
         superpages = 0;
         pae = 1;
+        no_incr_generationid = 0;
         break;
     default:
         return ERROR_INVAL;
@@ -373,7 +387,8 @@ int libxl__domain_restore_common(libxl__
     rc = xc_domain_restore(ctx->xch, fd, domid,
                            state->store_port, &state->store_mfn,
                            state->console_port, &state->console_mfn,
-                           hvm, pae, superpages);
+                           hvm, pae, superpages, no_incr_generationid,
+                           &state->vm_generationid_addr);
     if ( rc ) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "restoring domain");
         return ERROR_FAIL;
@@ -539,12 +554,23 @@ int libxl__domain_suspend_common(libxl__
     struct save_callbacks callbacks;
     struct suspendinfo si;
     int hvm, rc = ERROR_FAIL;
+    unsigned long vm_generationid_addr;
 
     switch (type) {
-    case LIBXL_DOMAIN_TYPE_HVM:
+    case LIBXL_DOMAIN_TYPE_HVM: {
+        char *path;
+        char *addr;
+
+        path = libxl__sprintf(gc, "%s/hvmloader/generation-id-address",
+                              libxl__xs_get_dompath(gc, domid));
+        addr = libxl__xs_read(gc, XBT_NULL, path);
+
+        vm_generationid_addr = (addr) ? strtoul(addr, NULL, 0) : 0;
         hvm = 1;
         break;
+    }
     case LIBXL_DOMAIN_TYPE_PV:
+        vm_generationid_addr = 0;
         hvm = 0;
         break;
     default:
@@ -582,7 +608,8 @@ int libxl__domain_suspend_common(libxl__
     callbacks.switch_qemu_logdirty = libxl__domain_suspend_common_switch_qemu_logdirty;
     callbacks.data = &si;
 
-    rc = xc_domain_save(ctx->xch, fd, domid, 0, 0, flags, &callbacks, hvm);
+    rc = xc_domain_save(ctx->xch, fd, domid, 0, 0, flags, &callbacks,
+                        hvm, vm_generationid_addr);
     if ( rc ) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "saving domain: %s",
                          si.guest_responded ?
diff -r fa0f840c516b -r 2ec1d2a1372c tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Fri Dec 16 14:54:13 2011 +0000
+++ b/tools/libxl/libxl_internal.h	Fri Dec 16 14:54:14 2011 +0000
@@ -221,6 +221,7 @@ typedef struct {
 
     uint32_t console_port;
     unsigned long console_mfn;
+    unsigned long vm_generationid_addr;
 } libxl__domain_build_state;
 
 _hidden int libxl__build_pre(libxl__gc *gc, uint32_t domid,
diff -r fa0f840c516b -r 2ec1d2a1372c tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Fri Dec 16 14:54:13 2011 +0000
+++ b/tools/libxl/libxl_types.idl	Fri Dec 16 14:54:14 2011 +0000
@@ -184,6 +184,7 @@ libxl_domain_build_info = Struct("domain
                                        ("vpt_align", bool),
                                        ("timer_mode", integer),
                                        ("nested_hvm", bool),
+                                       ("no_incr_generationid", bool),
                                        ])),
                  ("pv", Struct(None, [("kernel", libxl_file_reference),
                                       ("slack_memkb", uint32),
diff -r fa0f840c516b -r 2ec1d2a1372c tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Fri Dec 16 14:54:13 2011 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Fri Dec 16 14:54:14 2011 +0000
@@ -360,6 +360,8 @@ static void printf_info(int domid,
         printf("\t\t\t(vpt_align %d)\n", b_info->u.hvm.vpt_align);
         printf("\t\t\t(timer_mode %d)\n", b_info->u.hvm.timer_mode);
         printf("\t\t\t(nestedhvm %d)\n", b_info->u.hvm.nested_hvm);
+        printf("\t\t\t(no_incr_generationid %d)\n",
+                    b_info->u.hvm.no_incr_generationid);
 
         printf("\t\t\t(device_model %s)\n", dm_info->device_model ? : "default");
         printf("\t\t\t(videoram %d)\n", dm_info->videoram);
@@ -1362,6 +1364,7 @@ struct domain_create {
     const char *restore_file;
     int migrate_fd; /* -1 means none */
     char **migration_domname_r; /* from malloc */
+    int no_incr_generationid;
 };
 
 static int freemem(libxl_domain_build_info *b_info, libxl_device_model_info *dm_info)
@@ -1575,6 +1578,8 @@ static int create_domain(struct domain_c
         }
     }
 
+    d_config.b_info.u.hvm.no_incr_generationid = dom_info->no_incr_generationid;
+
     if (debug || dom_info->dryrun)
         printf_info(-1, &d_config, &d_config.dm_info);
 
@@ -2800,6 +2805,7 @@ static void migrate_receive(int debug, i
     dom_info.restore_file = "incoming migration stream";
     dom_info.migrate_fd = 0; /* stdin */
     dom_info.migration_domname_r = &migration_domname;
+    dom_info.no_incr_generationid = 1;
 
     rc = create_domain(&dom_info);
     if (rc < 0) {
diff -r fa0f840c516b -r 2ec1d2a1372c tools/python/xen/lowlevel/checkpoint/libcheckpoint.c
--- a/tools/python/xen/lowlevel/checkpoint/libcheckpoint.c	Fri Dec 16 14:54:13 2011 +0000
+++ b/tools/python/xen/lowlevel/checkpoint/libcheckpoint.c	Fri Dec 16 14:54:14 2011 +0000
@@ -175,6 +175,7 @@ int checkpoint_start(checkpoint_state* s
 {
     int hvm, rc;
     int flags = XCFLAGS_LIVE;
+    unsigned long vm_generationid_addr;
 
     if (!s->domid) {
        s->errstr = "checkpoint state not opened";
@@ -185,16 +186,28 @@ int checkpoint_start(checkpoint_state* s
 
     hvm = s->domtype > dt_pv;
     if (hvm) {
+       char path[128];
+       char *addr;
+
+       sprintf(path, "/local/domain/%u/hvmloader/generation-id-address", s->domid);
+       addr = xs_read(s->xsh, XBT_NULL, path, NULL);
+
+       vm_generationid_addr = (addr) ? strtoul(addr, NULL, 0) : 0;
+       free(addr);
+
        flags |= XCFLAGS_HVM;
        if (switch_qemu_logdirty(s, 1))
            return -1;
+    } else {
+       vm_generationid_addr = 0;
     }
     if (remus_flags & CHECKPOINT_FLAGS_COMPRESSION)
       flags |= XCFLAGS_CHECKPOINT_COMPRESS;
 
     callbacks->switch_qemu_logdirty = noop_switch_logdirty;
 
-    rc = xc_domain_save(s->xch, fd, s->domid, 0, 0, flags, callbacks, hvm);
+    rc = xc_domain_save(s->xch, fd, s->domid, 0, 0, flags, callbacks, hvm,
+                        vm_generationid_addr);
 
     if (hvm)
        switch_qemu_logdirty(s, 0);
diff -r fa0f840c516b -r 2ec1d2a1372c tools/xcutils/xc_restore.c
--- a/tools/xcutils/xc_restore.c	Fri Dec 16 14:54:13 2011 +0000
+++ b/tools/xcutils/xc_restore.c	Fri Dec 16 14:54:14 2011 +0000
@@ -46,7 +46,8 @@ main(int argc, char **argv)
 	    superpages = !!hvm;
 
     ret = xc_domain_restore(xch, io_fd, domid, store_evtchn, &store_mfn,
-                            console_evtchn, &console_mfn, hvm, pae, superpages);
+                            console_evtchn, &console_mfn, hvm, pae, superpages,
+                            0, NULL);
 
     if ( ret == 0 )
     {
diff -r fa0f840c516b -r 2ec1d2a1372c tools/xcutils/xc_save.c
--- a/tools/xcutils/xc_save.c	Fri Dec 16 14:54:13 2011 +0000
+++ b/tools/xcutils/xc_save.c	Fri Dec 16 14:54:14 2011 +0000
@@ -208,7 +208,7 @@ main(int argc, char **argv)
     callbacks.suspend = suspend;
     callbacks.switch_qemu_logdirty = switch_qemu_logdirty;
     ret = xc_domain_save(si.xch, io_fd, si.domid, maxit, max_f, si.flags, 
-                         &callbacks, !!(si.flags & XCFLAGS_HVM));
+                         &callbacks, !!(si.flags & XCFLAGS_HVM), 0);
 
     if (si.suspend_evtchn > 0)
 	 xc_suspend_evtchn_release(si.xch, si.xce, si.domid, si.suspend_evtchn);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 14:56:17 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 14:56:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbZCn-0001Gb-0j; Fri, 16 Dec 2011 14:56:13 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RbZCl-0001EF-AH
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 14:56:11 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1324047363!7553767!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjI0MzY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16570 invoked from network); 16 Dec 2011 14:56:04 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Dec 2011 14:56:04 -0000
X-IronPort-AV: E=Sophos;i="4.71,363,1320642000"; d="scan'208";a="174458365"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Dec 2011 09:56:02 -0500
Received: from cosworth.uk.xensource.com (10.80.16.52) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 16 Dec 2011 09:56:02 -0500
MIME-Version: 1.0
X-Mercurial-Node: 2ec1d2a1372cd84d1fa636f54aeedaed57d84791
Message-ID: <2ec1d2a1372cd84d1fa6.1324047277@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1324047273@cosworth.uk.xensource.com>
References: <patchbomb.1324047273@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 16 Dec 2011 14:54:37 +0000
From: Paul Durrant <paul.durrant@citrix.com>
To: xen-devel@lists.xensource.com
Cc: paul.durrant@citrix.com
Subject: [Xen-devel] [PATCH 4 of 4] VM generation ID save/restore and migrate
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Paul Durrant <paul.durrant@citrix.com>
# Date 1324047254 0
# Node ID 2ec1d2a1372cd84d1fa636f54aeedaed57d84791
# Parent  fa0f840c516b6d6db7f9c8903e06335c1cb87f44
VM generation ID save/restore and migrate.

Add code to track the address of the VM generation ID buffer across a
save/restore or migrate, and increment it as necessary.
The address of the buffer is written into xenstore by hvmloader at
boot time. It must be read from xenstore by the caller of
xc_domain_save() and then written back again by the caller of
xc_domain_restore().

Note that the changes to xc_save.c and xc_restore.c are merely
sufficient for them to build.

Signed-off-by: Paul Durrant <paul.durrant@citrix.com>

diff -r fa0f840c516b -r 2ec1d2a1372c tools/libxc/ia64/xc_ia64_linux_restore.c
--- a/tools/libxc/ia64/xc_ia64_linux_restore.c	Fri Dec 16 14:54:13 2011 +0000
+++ b/tools/libxc/ia64/xc_ia64_linux_restore.c	Fri Dec 16 14:54:14 2011 +0000
@@ -548,7 +548,9 @@ int
 xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
                   unsigned int store_evtchn, unsigned long *store_mfn,
                   unsigned int console_evtchn, unsigned long *console_mfn,
-                  unsigned int hvm, unsigned int pae, int superpages)
+                  unsigned int hvm, unsigned int pae, int superpages,
+                  int no_incr_generationid,
+                  unsigned long *vm_generationid_addr)
 {
     DECLARE_DOMCTL;
     int rc = 1;
diff -r fa0f840c516b -r 2ec1d2a1372c tools/libxc/ia64/xc_ia64_linux_save.c
--- a/tools/libxc/ia64/xc_ia64_linux_save.c	Fri Dec 16 14:54:13 2011 +0000
+++ b/tools/libxc/ia64/xc_ia64_linux_save.c	Fri Dec 16 14:54:14 2011 +0000
@@ -382,7 +382,8 @@ out:
 int
 xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iters,
                uint32_t max_factor, uint32_t flags,
-               struct save_callbacks* callbacks, int hvm)
+               struct save_callbacks* callbacks, int hvm,
+               unsigned long vm_generationid_addr)
 {
     DECLARE_DOMCTL;
     xc_dominfo_t info;
diff -r fa0f840c516b -r 2ec1d2a1372c tools/libxc/xc_domain_restore.c
--- a/tools/libxc/xc_domain_restore.c	Fri Dec 16 14:54:13 2011 +0000
+++ b/tools/libxc/xc_domain_restore.c	Fri Dec 16 14:54:14 2011 +0000
@@ -681,6 +681,7 @@ typedef struct {
     uint64_t console_pfn;
     uint64_t acpi_ioport_location;
     uint64_t viridian;
+    uint64_t vm_generationid_addr;
 } pagebuf_t;
 
 static int pagebuf_init(pagebuf_t* buf)
@@ -860,6 +861,17 @@ static int pagebuf_get_one(xc_interface 
         }
         return compbuf_size;
 
+    case XC_SAVE_ID_HVM_GENERATION_ID_ADDR:
+        /* Skip padding 4 bytes then read the generation id buffer location. */
+        if ( RDEXACT(fd, &buf->vm_generationid_addr, sizeof(uint32_t)) ||
+             RDEXACT(fd, &buf->vm_generationid_addr, sizeof(uint64_t)) )
+        {
+            PERROR("error read the generation id buffer location");
+            return -1;
+        }
+        DPRINTF("read generation id buffer address");
+        return pagebuf_get_one(xch, ctx, buf, fd, dom);
+
     default:
         if ( (count > MAX_BATCH_SIZE) || (count < 0) ) {
             ERROR("Max batch size exceeded (%d). Giving up.", count);
@@ -1248,7 +1260,9 @@ static int apply_batch(xc_interface *xch
 int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
                       unsigned int store_evtchn, unsigned long *store_mfn,
                       unsigned int console_evtchn, unsigned long *console_mfn,
-                      unsigned int hvm, unsigned int pae, int superpages)
+                      unsigned int hvm, unsigned int pae, int superpages,
+                      int no_incr_generationid,
+                      unsigned long *vm_generationid_addr)
 {
     DECLARE_DOMCTL;
     int rc = 1, frc, i, j, n, m, pae_extended_cr3 = 0, ext_vcpucontext = 0;
@@ -1449,6 +1463,39 @@ int xc_domain_restore(xc_interface *xch,
                 xc_set_hvm_param(xch, dom, HVM_PARAM_VM86_TSS, pagebuf.vm86_tss);
             if ( pagebuf.console_pfn )
                 console_pfn = pagebuf.console_pfn;
+            if ( pagebuf.vm_generationid_addr ) {
+                if ( !no_incr_generationid ) {
+                    unsigned int offset;
+                    unsigned char *buf;
+                    unsigned long long generationid;
+
+                    /*
+                     * Map the VM generation id buffer and inject the new value.
+                     */
+
+                    pfn = pagebuf.vm_generationid_addr >> PAGE_SHIFT;
+                    offset = pagebuf.vm_generationid_addr & (PAGE_SIZE - 1);
+                
+                    if ( (pfn >= dinfo->p2m_size) ||
+                         (pfn_type[pfn] != XEN_DOMCTL_PFINFO_NOTAB) )
+                    {
+                        ERROR("generation id buffer frame is bad");
+                        goto out;
+                    }
+
+                    mfn = ctx->p2m[pfn];
+                    buf = xc_map_foreign_range(xch, dom, PAGE_SIZE,
+                                               PROT_READ | PROT_WRITE, mfn);
+
+                    generationid = *(unsigned long long *)(buf + offset);
+                    *(unsigned long long *)(buf + offset) = generationid + 1;
+
+                    munmap(buf, PAGE_SIZE);
+                }
+
+                *vm_generationid_addr = pagebuf.vm_generationid_addr;
+            }
+
             break;  /* our work here is done */
         }
 
diff -r fa0f840c516b -r 2ec1d2a1372c tools/libxc/xc_domain_save.c
--- a/tools/libxc/xc_domain_save.c	Fri Dec 16 14:54:13 2011 +0000
+++ b/tools/libxc/xc_domain_save.c	Fri Dec 16 14:54:14 2011 +0000
@@ -804,7 +804,8 @@ static int save_tsc_info(xc_interface *x
 
 int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iters,
                    uint32_t max_factor, uint32_t flags,
-                   struct save_callbacks* callbacks, int hvm)
+                   struct save_callbacks* callbacks, int hvm,
+                   unsigned long vm_generationid_addr)
 {
     xc_dominfo_t info;
     DECLARE_DOMCTL;
@@ -1616,6 +1617,16 @@ int xc_domain_save(xc_interface *xch, in
             uint64_t data;
         } chunk = { 0, };
 
+        chunk.id = XC_SAVE_ID_HVM_GENERATION_ID_ADDR;
+        chunk.data = vm_generationid_addr;
+
+        if ( (chunk.data != 0) &&
+             wrexact(io_fd, &chunk, sizeof(chunk)) )
+        {
+            PERROR("Error when writing the generation id buffer location for guest");
+            goto out;
+        }
+
         chunk.id = XC_SAVE_ID_HVM_IDENT_PT;
         chunk.data = 0;
         xc_get_hvm_param(xch, dom, HVM_PARAM_IDENT_PT,
diff -r fa0f840c516b -r 2ec1d2a1372c tools/libxc/xenguest.h
--- a/tools/libxc/xenguest.h	Fri Dec 16 14:54:13 2011 +0000
+++ b/tools/libxc/xenguest.h	Fri Dec 16 14:54:14 2011 +0000
@@ -58,7 +58,8 @@ struct save_callbacks {
  */
 int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iters,
                    uint32_t max_factor, uint32_t flags /* XCFLAGS_xxx */,
-                   struct save_callbacks* callbacks, int hvm);
+                   struct save_callbacks* callbacks, int hvm,
+                   unsigned long vm_generationid_addr);
 
 
 /**
@@ -72,12 +73,16 @@ int xc_domain_save(xc_interface *xch, in
  * @parm hvm non-zero if this is a HVM restore
  * @parm pae non-zero if this HVM domain has PAE support enabled
  * @parm superpages non-zero to allocate guest memory with superpages
+ * @parm no_incr_generationid non-zero if generation id is NOT to be incremented
+ * @parm vm_generationid_addr returned with the address of the generation id buffer
  * @return 0 on success, -1 on failure
  */
 int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
                       unsigned int store_evtchn, unsigned long *store_mfn,
                       unsigned int console_evtchn, unsigned long *console_mfn,
-                      unsigned int hvm, unsigned int pae, int superpages);
+                      unsigned int hvm, unsigned int pae, int superpages,
+                      int no_incr_generationid,
+		      unsigned long *vm_generationid_addr);
 /**
  * xc_domain_restore writes a file to disk that contains the device
  * model saved state.
diff -r fa0f840c516b -r 2ec1d2a1372c tools/libxc/xg_save_restore.h
--- a/tools/libxc/xg_save_restore.h	Fri Dec 16 14:54:13 2011 +0000
+++ b/tools/libxc/xg_save_restore.h	Fri Dec 16 14:54:14 2011 +0000
@@ -253,6 +253,7 @@
 #define XC_SAVE_ID_HVM_VIRIDIAN       -11
 #define XC_SAVE_ID_COMPRESSED_DATA    -12 /* Marker to indicate arrival of compressed data */
 #define XC_SAVE_ID_ENABLE_COMPRESSION -13 /* Marker to enable compression logic at receiver side */
+#define XC_SAVE_ID_HVM_GENERATION_ID_ADDR -14
 
 /*
 ** We process save/restore/migrate in batches of pages; the below
diff -r fa0f840c516b -r 2ec1d2a1372c tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Fri Dec 16 14:54:13 2011 +0000
+++ b/tools/libxl/libxl_create.c	Fri Dec 16 14:54:14 2011 +0000
@@ -99,6 +99,7 @@ int libxl_init_build_info(libxl_ctx *ctx
         b_info->u.hvm.vpt_align = 1;
         b_info->u.hvm.timer_mode = 1;
         b_info->u.hvm.nested_hvm = 0;
+        b_info->u.hvm.no_incr_generationid = 0;
         break;
     case LIBXL_DOMAIN_TYPE_PV:
         b_info->u.pv.slack_memkb = 8 * 1024;
diff -r fa0f840c516b -r 2ec1d2a1372c tools/libxl/libxl_dom.c
--- a/tools/libxl/libxl_dom.c	Fri Dec 16 14:54:13 2011 +0000
+++ b/tools/libxl/libxl_dom.c	Fri Dec 16 14:54:14 2011 +0000
@@ -106,6 +106,7 @@ int libxl__build_pre(libxl__gc *gc, uint
 
     state->store_port = xc_evtchn_alloc_unbound(ctx->xch, domid, 0);
     state->console_port = xc_evtchn_alloc_unbound(ctx->xch, domid, 0);
+    state->vm_generationid_addr = 0;
     return 0;
 }
 
@@ -117,7 +118,7 @@ int libxl__build_post(libxl__gc *gc, uin
     libxl_ctx *ctx = libxl__gc_owner(gc);
     char *dom_path, *vm_path;
     xs_transaction_t t;
-    char **ents;
+    char **ents, **hvm_ents;
     int i;
 
     libxl_cpuid_apply_policy(ctx, domid);
@@ -143,6 +144,13 @@ int libxl__build_post(libxl__gc *gc, uin
                             ? "offline" : "online";
     }
 
+    hvm_ents = NULL;
+    if (info->type == LIBXL_DOMAIN_TYPE_HVM) {
+        hvm_ents = libxl__calloc(gc, 3, sizeof(char *));
+        hvm_ents[0] = "hvmloader/generation-id-address";
+        hvm_ents[1] = libxl__sprintf(gc, "0x%lx", state->vm_generationid_addr);
+    }
+
     dom_path = libxl__xs_get_dompath(gc, domid);
     if (!dom_path) {
         return ERROR_FAIL;
@@ -153,6 +161,9 @@ retry_transaction:
     t = xs_transaction_start(ctx->xsh);
 
     libxl__xs_writev(gc, t, dom_path, ents);
+    if (info->type == LIBXL_DOMAIN_TYPE_HVM)
+        libxl__xs_writev(gc, t, dom_path, hvm_ents);
+
     libxl__xs_writev(gc, t, dom_path, local_ents);
     libxl__xs_writev(gc, t, vm_path, vms_ents);
 
@@ -356,16 +367,19 @@ int libxl__domain_restore_common(libxl__
     /* read signature */
     int rc;
     int hvm, pae, superpages;
+    int no_incr_generationid;
     switch (info->type) {
     case LIBXL_DOMAIN_TYPE_HVM:
         hvm = 1;
         superpages = 1;
         pae = info->u.hvm.pae;
+        no_incr_generationid = info->u.hvm.no_incr_generationid;
         break;
     case LIBXL_DOMAIN_TYPE_PV:
         hvm = 0;
         superpages = 0;
         pae = 1;
+        no_incr_generationid = 0;
         break;
     default:
         return ERROR_INVAL;
@@ -373,7 +387,8 @@ int libxl__domain_restore_common(libxl__
     rc = xc_domain_restore(ctx->xch, fd, domid,
                            state->store_port, &state->store_mfn,
                            state->console_port, &state->console_mfn,
-                           hvm, pae, superpages);
+                           hvm, pae, superpages, no_incr_generationid,
+                           &state->vm_generationid_addr);
     if ( rc ) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "restoring domain");
         return ERROR_FAIL;
@@ -539,12 +554,23 @@ int libxl__domain_suspend_common(libxl__
     struct save_callbacks callbacks;
     struct suspendinfo si;
     int hvm, rc = ERROR_FAIL;
+    unsigned long vm_generationid_addr;
 
     switch (type) {
-    case LIBXL_DOMAIN_TYPE_HVM:
+    case LIBXL_DOMAIN_TYPE_HVM: {
+        char *path;
+        char *addr;
+
+        path = libxl__sprintf(gc, "%s/hvmloader/generation-id-address",
+                              libxl__xs_get_dompath(gc, domid));
+        addr = libxl__xs_read(gc, XBT_NULL, path);
+
+        vm_generationid_addr = (addr) ? strtoul(addr, NULL, 0) : 0;
         hvm = 1;
         break;
+    }
     case LIBXL_DOMAIN_TYPE_PV:
+        vm_generationid_addr = 0;
         hvm = 0;
         break;
     default:
@@ -582,7 +608,8 @@ int libxl__domain_suspend_common(libxl__
     callbacks.switch_qemu_logdirty = libxl__domain_suspend_common_switch_qemu_logdirty;
     callbacks.data = &si;
 
-    rc = xc_domain_save(ctx->xch, fd, domid, 0, 0, flags, &callbacks, hvm);
+    rc = xc_domain_save(ctx->xch, fd, domid, 0, 0, flags, &callbacks,
+                        hvm, vm_generationid_addr);
     if ( rc ) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "saving domain: %s",
                          si.guest_responded ?
diff -r fa0f840c516b -r 2ec1d2a1372c tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Fri Dec 16 14:54:13 2011 +0000
+++ b/tools/libxl/libxl_internal.h	Fri Dec 16 14:54:14 2011 +0000
@@ -221,6 +221,7 @@ typedef struct {
 
     uint32_t console_port;
     unsigned long console_mfn;
+    unsigned long vm_generationid_addr;
 } libxl__domain_build_state;
 
 _hidden int libxl__build_pre(libxl__gc *gc, uint32_t domid,
diff -r fa0f840c516b -r 2ec1d2a1372c tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Fri Dec 16 14:54:13 2011 +0000
+++ b/tools/libxl/libxl_types.idl	Fri Dec 16 14:54:14 2011 +0000
@@ -184,6 +184,7 @@ libxl_domain_build_info = Struct("domain
                                        ("vpt_align", bool),
                                        ("timer_mode", integer),
                                        ("nested_hvm", bool),
+                                       ("no_incr_generationid", bool),
                                        ])),
                  ("pv", Struct(None, [("kernel", libxl_file_reference),
                                       ("slack_memkb", uint32),
diff -r fa0f840c516b -r 2ec1d2a1372c tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Fri Dec 16 14:54:13 2011 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Fri Dec 16 14:54:14 2011 +0000
@@ -360,6 +360,8 @@ static void printf_info(int domid,
         printf("\t\t\t(vpt_align %d)\n", b_info->u.hvm.vpt_align);
         printf("\t\t\t(timer_mode %d)\n", b_info->u.hvm.timer_mode);
         printf("\t\t\t(nestedhvm %d)\n", b_info->u.hvm.nested_hvm);
+        printf("\t\t\t(no_incr_generationid %d)\n",
+                    b_info->u.hvm.no_incr_generationid);
 
         printf("\t\t\t(device_model %s)\n", dm_info->device_model ? : "default");
         printf("\t\t\t(videoram %d)\n", dm_info->videoram);
@@ -1362,6 +1364,7 @@ struct domain_create {
     const char *restore_file;
     int migrate_fd; /* -1 means none */
     char **migration_domname_r; /* from malloc */
+    int no_incr_generationid;
 };
 
 static int freemem(libxl_domain_build_info *b_info, libxl_device_model_info *dm_info)
@@ -1575,6 +1578,8 @@ static int create_domain(struct domain_c
         }
     }
 
+    d_config.b_info.u.hvm.no_incr_generationid = dom_info->no_incr_generationid;
+
     if (debug || dom_info->dryrun)
         printf_info(-1, &d_config, &d_config.dm_info);
 
@@ -2800,6 +2805,7 @@ static void migrate_receive(int debug, i
     dom_info.restore_file = "incoming migration stream";
     dom_info.migrate_fd = 0; /* stdin */
     dom_info.migration_domname_r = &migration_domname;
+    dom_info.no_incr_generationid = 1;
 
     rc = create_domain(&dom_info);
     if (rc < 0) {
diff -r fa0f840c516b -r 2ec1d2a1372c tools/python/xen/lowlevel/checkpoint/libcheckpoint.c
--- a/tools/python/xen/lowlevel/checkpoint/libcheckpoint.c	Fri Dec 16 14:54:13 2011 +0000
+++ b/tools/python/xen/lowlevel/checkpoint/libcheckpoint.c	Fri Dec 16 14:54:14 2011 +0000
@@ -175,6 +175,7 @@ int checkpoint_start(checkpoint_state* s
 {
     int hvm, rc;
     int flags = XCFLAGS_LIVE;
+    unsigned long vm_generationid_addr;
 
     if (!s->domid) {
        s->errstr = "checkpoint state not opened";
@@ -185,16 +186,28 @@ int checkpoint_start(checkpoint_state* s
 
     hvm = s->domtype > dt_pv;
     if (hvm) {
+       char path[128];
+       char *addr;
+
+       sprintf(path, "/local/domain/%u/hvmloader/generation-id-address", s->domid);
+       addr = xs_read(s->xsh, XBT_NULL, path, NULL);
+
+       vm_generationid_addr = (addr) ? strtoul(addr, NULL, 0) : 0;
+       free(addr);
+
        flags |= XCFLAGS_HVM;
        if (switch_qemu_logdirty(s, 1))
            return -1;
+    } else {
+       vm_generationid_addr = 0;
     }
     if (remus_flags & CHECKPOINT_FLAGS_COMPRESSION)
       flags |= XCFLAGS_CHECKPOINT_COMPRESS;
 
     callbacks->switch_qemu_logdirty = noop_switch_logdirty;
 
-    rc = xc_domain_save(s->xch, fd, s->domid, 0, 0, flags, callbacks, hvm);
+    rc = xc_domain_save(s->xch, fd, s->domid, 0, 0, flags, callbacks, hvm,
+                        vm_generationid_addr);
 
     if (hvm)
        switch_qemu_logdirty(s, 0);
diff -r fa0f840c516b -r 2ec1d2a1372c tools/xcutils/xc_restore.c
--- a/tools/xcutils/xc_restore.c	Fri Dec 16 14:54:13 2011 +0000
+++ b/tools/xcutils/xc_restore.c	Fri Dec 16 14:54:14 2011 +0000
@@ -46,7 +46,8 @@ main(int argc, char **argv)
 	    superpages = !!hvm;
 
     ret = xc_domain_restore(xch, io_fd, domid, store_evtchn, &store_mfn,
-                            console_evtchn, &console_mfn, hvm, pae, superpages);
+                            console_evtchn, &console_mfn, hvm, pae, superpages,
+                            0, NULL);
 
     if ( ret == 0 )
     {
diff -r fa0f840c516b -r 2ec1d2a1372c tools/xcutils/xc_save.c
--- a/tools/xcutils/xc_save.c	Fri Dec 16 14:54:13 2011 +0000
+++ b/tools/xcutils/xc_save.c	Fri Dec 16 14:54:14 2011 +0000
@@ -208,7 +208,7 @@ main(int argc, char **argv)
     callbacks.suspend = suspend;
     callbacks.switch_qemu_logdirty = switch_qemu_logdirty;
     ret = xc_domain_save(si.xch, io_fd, si.domid, maxit, max_f, si.flags, 
-                         &callbacks, !!(si.flags & XCFLAGS_HVM));
+                         &callbacks, !!(si.flags & XCFLAGS_HVM), 0);
 
     if (si.suspend_evtchn > 0)
 	 xc_suspend_evtchn_release(si.xch, si.xce, si.domid, si.suspend_evtchn);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 14:56:26 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 14:56:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbZCw-0001NS-JY; Fri, 16 Dec 2011 14:56:22 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <carsten@schiers.de>) id 1RbZCu-0001MH-NF
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 14:56:21 +0000
X-Env-Sender: carsten@schiers.de
X-Msg-Ref: server-15.tower-27.messagelabs.com!1324047360!59239924!1
X-Originating-IP: [194.117.254.36]
X-SpamReason: No, hits=0.0 required=7.0 tests=FROM_EXCESS_QP,
  HTML_MESSAGE
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20956 invoked from network); 16 Dec 2011 14:56:00 -0000
Received: from www.zeus06.de (HELO mail.zeus06.de) (194.117.254.36)
	by server-15.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Dec 2011 14:56:00 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=mail.zeus06.de; h=subject
	:from:to:cc:date:mime-version:content-type:in-reply-to
	:references:message-id; s=beta; bh=ndad9eStOAjQJLGtAzJ9GtZQvG9GA
	mwKQU3s3e19/pQ=; b=KcwfoDHWAx9J8kj69rnZ62jKIbHDyZag5ODZhzZKPrDFy
	z/Kx7cvobEvkVGTK0+XsauQt1X9BGoVUkQxhEYk3dsQEnXIwAoep9omLLggtHCFH
	uc7aekx4QbVsUy5X6DOWEwxwfWF0QLHyZlNMjL0lydUCyX6R/i/BUjjz+3YTgQ=
Received: (qmail 4618 invoked from network); 16 Dec 2011 15:56:18 +0100
Received: from unknown (HELO uhura.zz) (l3s6271p1@46.59.190.170)
	by mail.zeus06.de with ESMTPA; 16 Dec 2011 15:56:18 +0100
Received: from localhost (localhost [127.0.0.1])
	by uhura.zz (Postfix) with ESMTP id 405BB2C525;
	Fri, 16 Dec 2011 15:56:18 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at schiers.de
Received: from uhura.zz ([127.0.0.1])
	by localhost (uhura.space.zz [127.0.0.1]) (amavisd-new, port 10024)
	with LMTP id qYJiOM2x68eO; Fri, 16 Dec 2011 15:56:10 +0100 (CET)
Received: from uhura.space.zz (localhost [127.0.0.1])
	by uhura.zz (Postfix) with ESMTP id B92882C526;
	Fri, 16 Dec 2011 15:56:10 +0100 (CET)
From: =?utf-8?Q?Carsten_Schiers?= <carsten@schiers.de>
To: =?utf-8?Q?Konrad_Rzeszutek_Wilk?= <konrad.wilk@oracle.com>
Date: Fri, 16 Dec 2011 15:56:10 +0100
Mime-Version: 1.0
In-Reply-To: <>
References: <20111214220700.GA9926@phenom.dumpdata.com>
X-Priority: 3 (Normal)
X-Mailer: Zarafa 7.0.2-29470
Thread-Index: Acy8AtFIW+B7tUUlTfmGU/vtOY9vbw==
Message-Id: <zarafa.4eeb5c0a.5be7.47c97c5342bf0bf4@uhura.space.zz>
Cc: =?utf-8?Q?linux=40eikelenboom=2Eit?= <linux@eikelenboom.it>,
	=?utf-8?Q?xen-devel?= <xen-devel@lists.xensource.com>,
	=?utf-8?Q?lersek=40redhat=2Ecom?= <lersek@redhat.com>,
	=?utf-8?Q?zhenzhong=2Eduan=40oracle=2Ecom?= <zhenzhong.duan@oracle.com>,
	=?utf-8?Q?Ian_Campbell?= <ian.campbell@citrix.com>
Subject: Re: [Xen-devel] Load increase after memory upgrade (part2)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============7808909783111654366=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a multi-part message in MIME format. Your mail reader does not
understand MIME message format.
--===============7808909783111654366==
Content-Type: multipart/alternative; 
 boundary="=_aMRW6iVVGB-NCUiHa3cI7TggifUX-+QJOOaVvEt1VAOcLQRR"

This is a multi-part message in MIME format. Your mail reader does not
understand MIME message format.
--=_aMRW6iVVGB-NCUiHa3cI7TggifUX-+QJOOaVvEt1VAOcLQRR
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Well, it will do nothing but print out =E2=80=9CSWIOTLB is 0% full=E2=80=9D=
=2E=0D=0A=0D=0A=C2=A0=0D=0ADoes that help=3F Or do you think something we=
nt wrong with the patch=E2=80=A6=0D=0A=0D=0A=C2=A0=0D=0ABR,=0D=0A=0D=0ACa=
rsten.=0D=0A=0D=0A=C2=A0=0D=0A=C2=A0=0D=0A=C2=A0=0D=0AVon: Carsten Schier=
s=20=0D=0AGesendet: Donnerstag, 15. Dezember 2011 15:53=0D=0AAn: Konrad R=
zeszutek Wilk; Konrad Rzeszutek Wilk=0D=0ACc: linux@eikelenboom.it; zhenz=
hong.duan@oracle.com; Ian Campbell; lersek@redhat.com; xen-devel=0D=0ABet=
reff: AW: [Xen-devel] Load increase after memory upgrade (part2)=0D=0A=0D=
=0A=C2=A0=0D=0A...=0D=0A=0D=0A> which will require some fiddling around.=0D=
=0A=0D=0AHere is the patch I used against classic XenLinux. Any chance yo=
u could run=0D=0Ait with your classis guests and see what numbers you get=
=3F=0D=0A=0D=0ASure, it might take a bit, but I'll try it with my 2.6.34 =
classic kernel.=0D=0A=0D=0A=C2=A0=0D=0ACarsten.=0D=0A=0D=0A
--=_aMRW6iVVGB-NCUiHa3cI7TggifUX-+QJOOaVvEt1VAOcLQRR
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

=0D=0A<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:sche=
mas-microsoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:off=
ice:word" xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xm=
lns=3D"http://www.w3.org/TR/REC-html40"><head><meta http-equiv=3DContent-=
Type content=3D"text/html; charset=3Dutf-8"><meta name=3DGenerator conten=
t=3D"Microsoft Word 12 (filtered medium)"><title>AW: [Xen-devel] Load inc=
rease after memory upgrade (part2)</title><style><!--=0D=0A/* Font Defini=
tions */=0D=0A@font-face=0D=0A   {font-family:"Cambria Math";=0D=0A   pan=
ose-1:0 0 0 0 0 0 0 0 0 0;}=0D=0A@font-face=0D=0A   {font-family:Calibri;=
=0D=0A   panose-1:2 15 5 2 2 2 4 3 2 4;}=0D=0A@font-face=0D=0A   {font-fa=
mily:Tahoma;=0D=0A   panose-1:2 11 6 4 3 5 4 4 2 4;}=0D=0A/* Style Defini=
tions */=0D=0Ap.MsoNormal, li.MsoNormal, div.MsoNormal=0D=0A   {margin:0c=
m;=0D=0A   margin-bottom:.0001pt;=0D=0A   font-size:12.0pt;=0D=0A   font-=
family:"Times New Roman","serif";}=0D=0Aa:link, span.MsoHyperlink=0D=0A  =
 {mso-style-priority:99;=0D=0A   color:blue;=0D=0A   text-decoration:unde=
rline;}=0D=0Aa:visited, span.MsoHyperlinkFollowed=0D=0A   {mso-style-prio=
rity:99;=0D=0A   color:purple;=0D=0A   text-decoration:underline;}=0D=0Ap=
=0D=0A   {mso-style-priority:99;=0D=0A   margin:0cm;=0D=0A   margin-botto=
m:.0001pt;=0D=0A   font-size:12.0pt;=0D=0A   font-family:"Times New Roman=
","serif";}=0D=0Aspan.E-MailFormatvorlage18=0D=0A   {mso-style-type:perso=
nal-reply;=0D=0A   font-family:"Calibri","sans-serif";=0D=0A   color:#1F4=
97D;}=0D=0A.MsoChpDefault=0D=0A   {mso-style-type:export-only;=0D=0A   fo=
nt-size:10.0pt;}=0D=0A@page WordSection1=0D=0A   {size:612.0pt 792.0pt;=0D=
=0A   margin:70.85pt 70.85pt 2.0cm 70.85pt;}=0D=0Adiv.WordSection1=0D=0A =
  {page:WordSection1;}=0D=0A--></style><!--[if gte mso 9]><xml>=0D=0A<o:s=
hapedefaults v:ext=3D"edit" spidmax=3D"1026" />=0D=0A</xml><![endif]--><!=
--[if gte mso 9]><xml>=0D=0A<o:shapelayout v:ext=3D"edit">=0D=0A<o:idmap =
v:ext=3D"edit" data=3D"1" />=0D=0A</o:shapelayout></xml><![endif]--></hea=
d><body bgcolor=3Dwhite lang=3DDE link=3Dblue vlink=3Dpurple><div class=3D=
WordSection1><p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:1=
1.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Well, it will do =
nothing but print out =E2=80=9CSWIOTLB is 0% full=E2=80=9D.<o:p></o:p></s=
pan></p><p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:11.0pt=
;font-family:"Calibri","sans-serif";color:#1F497D'><o:p>&nbsp;</o:p></spa=
n></p><p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:11.0pt;f=
ont-family:"Calibri","sans-serif";color:#1F497D'>Does that help=3F Or do =
you think something went wrong with the patch=E2=80=A6<o:p></o:p></span><=
/p><p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:11.0pt;font=
-family:"Calibri","sans-serif";color:#1F497D'><o:p>&nbsp;</o:p></span></p=
><p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:11.0pt;font-f=
amily:"Calibri","sans-serif";color:#1F497D'>BR,<o:p></o:p></span></p><p c=
lass=3DMsoNormal><span lang=3DEN-US style=3D'font-size:11.0pt;font-family=
:"Calibri","sans-serif";color:#1F497D'>Carsten.<o:p></o:p></span></p><p c=
lass=3DMsoNormal><span lang=3DEN-US style=3D'font-size:11.0pt;font-family=
:"Calibri","sans-serif";color:#1F497D'><o:p>&nbsp;</o:p></span></p><p cla=
ss=3DMsoNormal><span lang=3DEN-US style=3D'font-size:11.0pt;font-family:"=
Calibri","sans-serif";color:#1F497D'><o:p>&nbsp;</o:p></span></p><p class=
=3DMsoNormal><span lang=3DEN-US style=3D'font-size:11.0pt;font-family:"Ca=
libri","sans-serif";color:#1F497D'><o:p>&nbsp;</o:p></span></p><div><div =
style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm=
 0cm'><p class=3DMsoNormal><b><span style=3D'font-size:10.0pt;font-family=
:"Tahoma","sans-serif"'>Von:</span></b><span style=3D'font-size:10.0pt;fo=
nt-family:"Tahoma","sans-serif"'> Carsten Schiers <br><b>Gesendet:</b> Do=
nnerstag, 15. Dezember 2011 15:53<br><b>An:</b> Konrad Rzeszutek Wilk; Ko=
nrad Rzeszutek Wilk<br><b>Cc:</b> linux@eikelenboom.it; zhenzhong.duan@or=
acle.com; Ian Campbell; lersek@redhat.com; xen-devel<br><b>Betreff:</b> A=
W: [Xen-devel] Load increase after memory upgrade (part2)<o:p></o:p></spa=
n></p></div></div><p class=3DMsoNormal><o:p>&nbsp;</o:p></p><p><span styl=
e=3D'font-size:9.0pt;font-family:"Arial","sans-serif"'>...<o:p></o:p></sp=
an></p><p><span style=3D'font-size:9.0pt;font-family:"Arial","sans-serif"=
'>&gt; which will require some fiddling around.<o:p></o:p></span></p><blo=
ckquote style=3D'border:none;border-left:solid #325FBA 1.5pt;padding:0cm =
0cm 0cm 4.0pt;margin-left:3.75pt;margin-top:5.0pt;margin-bottom:5.0pt'><p=
 class=3DMsoNormal><span style=3D'font-size:9.0pt;font-family:"Arial","sa=
ns-serif"'>Here is the patch I used against classic XenLinux. Any chance =
you could run<br>it with your classis guests and see what numbers you get=
=3F<o:p></o:p></span></p></blockquote><p><span style=3D'font-size:9.0pt;f=
ont-family:"Arial","sans-serif"'>Sure, it might take a bit, but I'll try =
it with my 2.6.34 classic kernel.<o:p></o:p></span></p><p><span style=3D'=
font-size:9.0pt;font-family:"Arial","sans-serif"'>&nbsp;<o:p></o:p></span=
></p><p><span style=3D'font-size:9.0pt;font-family:"Arial","sans-serif"'>=
Carsten.<o:p></o:p></span></p></div></body></html>
--=_aMRW6iVVGB-NCUiHa3cI7TggifUX-+QJOOaVvEt1VAOcLQRR--



--===============7808909783111654366==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============7808909783111654366==--



From xen-devel-bounces@lists.xensource.com Fri Dec 16 14:56:26 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 14:56:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbZCw-0001NS-JY; Fri, 16 Dec 2011 14:56:22 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <carsten@schiers.de>) id 1RbZCu-0001MH-NF
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 14:56:21 +0000
X-Env-Sender: carsten@schiers.de
X-Msg-Ref: server-15.tower-27.messagelabs.com!1324047360!59239924!1
X-Originating-IP: [194.117.254.36]
X-SpamReason: No, hits=0.0 required=7.0 tests=FROM_EXCESS_QP,
  HTML_MESSAGE
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20956 invoked from network); 16 Dec 2011 14:56:00 -0000
Received: from www.zeus06.de (HELO mail.zeus06.de) (194.117.254.36)
	by server-15.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Dec 2011 14:56:00 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=mail.zeus06.de; h=subject
	:from:to:cc:date:mime-version:content-type:in-reply-to
	:references:message-id; s=beta; bh=ndad9eStOAjQJLGtAzJ9GtZQvG9GA
	mwKQU3s3e19/pQ=; b=KcwfoDHWAx9J8kj69rnZ62jKIbHDyZag5ODZhzZKPrDFy
	z/Kx7cvobEvkVGTK0+XsauQt1X9BGoVUkQxhEYk3dsQEnXIwAoep9omLLggtHCFH
	uc7aekx4QbVsUy5X6DOWEwxwfWF0QLHyZlNMjL0lydUCyX6R/i/BUjjz+3YTgQ=
Received: (qmail 4618 invoked from network); 16 Dec 2011 15:56:18 +0100
Received: from unknown (HELO uhura.zz) (l3s6271p1@46.59.190.170)
	by mail.zeus06.de with ESMTPA; 16 Dec 2011 15:56:18 +0100
Received: from localhost (localhost [127.0.0.1])
	by uhura.zz (Postfix) with ESMTP id 405BB2C525;
	Fri, 16 Dec 2011 15:56:18 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at schiers.de
Received: from uhura.zz ([127.0.0.1])
	by localhost (uhura.space.zz [127.0.0.1]) (amavisd-new, port 10024)
	with LMTP id qYJiOM2x68eO; Fri, 16 Dec 2011 15:56:10 +0100 (CET)
Received: from uhura.space.zz (localhost [127.0.0.1])
	by uhura.zz (Postfix) with ESMTP id B92882C526;
	Fri, 16 Dec 2011 15:56:10 +0100 (CET)
From: =?utf-8?Q?Carsten_Schiers?= <carsten@schiers.de>
To: =?utf-8?Q?Konrad_Rzeszutek_Wilk?= <konrad.wilk@oracle.com>
Date: Fri, 16 Dec 2011 15:56:10 +0100
Mime-Version: 1.0
In-Reply-To: <>
References: <20111214220700.GA9926@phenom.dumpdata.com>
X-Priority: 3 (Normal)
X-Mailer: Zarafa 7.0.2-29470
Thread-Index: Acy8AtFIW+B7tUUlTfmGU/vtOY9vbw==
Message-Id: <zarafa.4eeb5c0a.5be7.47c97c5342bf0bf4@uhura.space.zz>
Cc: =?utf-8?Q?linux=40eikelenboom=2Eit?= <linux@eikelenboom.it>,
	=?utf-8?Q?xen-devel?= <xen-devel@lists.xensource.com>,
	=?utf-8?Q?lersek=40redhat=2Ecom?= <lersek@redhat.com>,
	=?utf-8?Q?zhenzhong=2Eduan=40oracle=2Ecom?= <zhenzhong.duan@oracle.com>,
	=?utf-8?Q?Ian_Campbell?= <ian.campbell@citrix.com>
Subject: Re: [Xen-devel] Load increase after memory upgrade (part2)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============7808909783111654366=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a multi-part message in MIME format. Your mail reader does not
understand MIME message format.
--===============7808909783111654366==
Content-Type: multipart/alternative; 
 boundary="=_aMRW6iVVGB-NCUiHa3cI7TggifUX-+QJOOaVvEt1VAOcLQRR"

This is a multi-part message in MIME format. Your mail reader does not
understand MIME message format.
--=_aMRW6iVVGB-NCUiHa3cI7TggifUX-+QJOOaVvEt1VAOcLQRR
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Well, it will do nothing but print out =E2=80=9CSWIOTLB is 0% full=E2=80=9D=
=2E=0D=0A=0D=0A=C2=A0=0D=0ADoes that help=3F Or do you think something we=
nt wrong with the patch=E2=80=A6=0D=0A=0D=0A=C2=A0=0D=0ABR,=0D=0A=0D=0ACa=
rsten.=0D=0A=0D=0A=C2=A0=0D=0A=C2=A0=0D=0A=C2=A0=0D=0AVon: Carsten Schier=
s=20=0D=0AGesendet: Donnerstag, 15. Dezember 2011 15:53=0D=0AAn: Konrad R=
zeszutek Wilk; Konrad Rzeszutek Wilk=0D=0ACc: linux@eikelenboom.it; zhenz=
hong.duan@oracle.com; Ian Campbell; lersek@redhat.com; xen-devel=0D=0ABet=
reff: AW: [Xen-devel] Load increase after memory upgrade (part2)=0D=0A=0D=
=0A=C2=A0=0D=0A...=0D=0A=0D=0A> which will require some fiddling around.=0D=
=0A=0D=0AHere is the patch I used against classic XenLinux. Any chance yo=
u could run=0D=0Ait with your classis guests and see what numbers you get=
=3F=0D=0A=0D=0ASure, it might take a bit, but I'll try it with my 2.6.34 =
classic kernel.=0D=0A=0D=0A=C2=A0=0D=0ACarsten.=0D=0A=0D=0A
--=_aMRW6iVVGB-NCUiHa3cI7TggifUX-+QJOOaVvEt1VAOcLQRR
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

=0D=0A<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:sche=
mas-microsoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:off=
ice:word" xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xm=
lns=3D"http://www.w3.org/TR/REC-html40"><head><meta http-equiv=3DContent-=
Type content=3D"text/html; charset=3Dutf-8"><meta name=3DGenerator conten=
t=3D"Microsoft Word 12 (filtered medium)"><title>AW: [Xen-devel] Load inc=
rease after memory upgrade (part2)</title><style><!--=0D=0A/* Font Defini=
tions */=0D=0A@font-face=0D=0A   {font-family:"Cambria Math";=0D=0A   pan=
ose-1:0 0 0 0 0 0 0 0 0 0;}=0D=0A@font-face=0D=0A   {font-family:Calibri;=
=0D=0A   panose-1:2 15 5 2 2 2 4 3 2 4;}=0D=0A@font-face=0D=0A   {font-fa=
mily:Tahoma;=0D=0A   panose-1:2 11 6 4 3 5 4 4 2 4;}=0D=0A/* Style Defini=
tions */=0D=0Ap.MsoNormal, li.MsoNormal, div.MsoNormal=0D=0A   {margin:0c=
m;=0D=0A   margin-bottom:.0001pt;=0D=0A   font-size:12.0pt;=0D=0A   font-=
family:"Times New Roman","serif";}=0D=0Aa:link, span.MsoHyperlink=0D=0A  =
 {mso-style-priority:99;=0D=0A   color:blue;=0D=0A   text-decoration:unde=
rline;}=0D=0Aa:visited, span.MsoHyperlinkFollowed=0D=0A   {mso-style-prio=
rity:99;=0D=0A   color:purple;=0D=0A   text-decoration:underline;}=0D=0Ap=
=0D=0A   {mso-style-priority:99;=0D=0A   margin:0cm;=0D=0A   margin-botto=
m:.0001pt;=0D=0A   font-size:12.0pt;=0D=0A   font-family:"Times New Roman=
","serif";}=0D=0Aspan.E-MailFormatvorlage18=0D=0A   {mso-style-type:perso=
nal-reply;=0D=0A   font-family:"Calibri","sans-serif";=0D=0A   color:#1F4=
97D;}=0D=0A.MsoChpDefault=0D=0A   {mso-style-type:export-only;=0D=0A   fo=
nt-size:10.0pt;}=0D=0A@page WordSection1=0D=0A   {size:612.0pt 792.0pt;=0D=
=0A   margin:70.85pt 70.85pt 2.0cm 70.85pt;}=0D=0Adiv.WordSection1=0D=0A =
  {page:WordSection1;}=0D=0A--></style><!--[if gte mso 9]><xml>=0D=0A<o:s=
hapedefaults v:ext=3D"edit" spidmax=3D"1026" />=0D=0A</xml><![endif]--><!=
--[if gte mso 9]><xml>=0D=0A<o:shapelayout v:ext=3D"edit">=0D=0A<o:idmap =
v:ext=3D"edit" data=3D"1" />=0D=0A</o:shapelayout></xml><![endif]--></hea=
d><body bgcolor=3Dwhite lang=3DDE link=3Dblue vlink=3Dpurple><div class=3D=
WordSection1><p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:1=
1.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Well, it will do =
nothing but print out =E2=80=9CSWIOTLB is 0% full=E2=80=9D.<o:p></o:p></s=
pan></p><p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:11.0pt=
;font-family:"Calibri","sans-serif";color:#1F497D'><o:p>&nbsp;</o:p></spa=
n></p><p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:11.0pt;f=
ont-family:"Calibri","sans-serif";color:#1F497D'>Does that help=3F Or do =
you think something went wrong with the patch=E2=80=A6<o:p></o:p></span><=
/p><p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:11.0pt;font=
-family:"Calibri","sans-serif";color:#1F497D'><o:p>&nbsp;</o:p></span></p=
><p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:11.0pt;font-f=
amily:"Calibri","sans-serif";color:#1F497D'>BR,<o:p></o:p></span></p><p c=
lass=3DMsoNormal><span lang=3DEN-US style=3D'font-size:11.0pt;font-family=
:"Calibri","sans-serif";color:#1F497D'>Carsten.<o:p></o:p></span></p><p c=
lass=3DMsoNormal><span lang=3DEN-US style=3D'font-size:11.0pt;font-family=
:"Calibri","sans-serif";color:#1F497D'><o:p>&nbsp;</o:p></span></p><p cla=
ss=3DMsoNormal><span lang=3DEN-US style=3D'font-size:11.0pt;font-family:"=
Calibri","sans-serif";color:#1F497D'><o:p>&nbsp;</o:p></span></p><p class=
=3DMsoNormal><span lang=3DEN-US style=3D'font-size:11.0pt;font-family:"Ca=
libri","sans-serif";color:#1F497D'><o:p>&nbsp;</o:p></span></p><div><div =
style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm=
 0cm'><p class=3DMsoNormal><b><span style=3D'font-size:10.0pt;font-family=
:"Tahoma","sans-serif"'>Von:</span></b><span style=3D'font-size:10.0pt;fo=
nt-family:"Tahoma","sans-serif"'> Carsten Schiers <br><b>Gesendet:</b> Do=
nnerstag, 15. Dezember 2011 15:53<br><b>An:</b> Konrad Rzeszutek Wilk; Ko=
nrad Rzeszutek Wilk<br><b>Cc:</b> linux@eikelenboom.it; zhenzhong.duan@or=
acle.com; Ian Campbell; lersek@redhat.com; xen-devel<br><b>Betreff:</b> A=
W: [Xen-devel] Load increase after memory upgrade (part2)<o:p></o:p></spa=
n></p></div></div><p class=3DMsoNormal><o:p>&nbsp;</o:p></p><p><span styl=
e=3D'font-size:9.0pt;font-family:"Arial","sans-serif"'>...<o:p></o:p></sp=
an></p><p><span style=3D'font-size:9.0pt;font-family:"Arial","sans-serif"=
'>&gt; which will require some fiddling around.<o:p></o:p></span></p><blo=
ckquote style=3D'border:none;border-left:solid #325FBA 1.5pt;padding:0cm =
0cm 0cm 4.0pt;margin-left:3.75pt;margin-top:5.0pt;margin-bottom:5.0pt'><p=
 class=3DMsoNormal><span style=3D'font-size:9.0pt;font-family:"Arial","sa=
ns-serif"'>Here is the patch I used against classic XenLinux. Any chance =
you could run<br>it with your classis guests and see what numbers you get=
=3F<o:p></o:p></span></p></blockquote><p><span style=3D'font-size:9.0pt;f=
ont-family:"Arial","sans-serif"'>Sure, it might take a bit, but I'll try =
it with my 2.6.34 classic kernel.<o:p></o:p></span></p><p><span style=3D'=
font-size:9.0pt;font-family:"Arial","sans-serif"'>&nbsp;<o:p></o:p></span=
></p><p><span style=3D'font-size:9.0pt;font-family:"Arial","sans-serif"'>=
Carsten.<o:p></o:p></span></p></div></body></html>
--=_aMRW6iVVGB-NCUiHa3cI7TggifUX-+QJOOaVvEt1VAOcLQRR--



--===============7808909783111654366==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============7808909783111654366==--



From xen-devel-bounces@lists.xensource.com Fri Dec 16 14:57:02 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 14:57:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbZDW-0001bo-2x; Fri, 16 Dec 2011 14:56:58 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1RbZDU-0001Yn-F4
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 14:56:56 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1324047409!7573326!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDI5ODc5Ng==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9613 invoked from network); 16 Dec 2011 14:56:50 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-12.tower-182.messagelabs.com with SMTP;
	16 Dec 2011 14:56:50 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga102.fm.intel.com with ESMTP; 16 Dec 2011 06:56:48 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="96997524"
Received: from pgsmsx602.gar.corp.intel.com ([10.221.43.81])
	by fmsmga001.fm.intel.com with ESMTP; 16 Dec 2011 06:56:47 -0800
Received: from pgsmsx104.gar.corp.intel.com (10.221.44.91) by
	pgsmsx602.gar.corp.intel.com (10.221.43.81) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Fri, 16 Dec 2011 22:55:46 +0800
Received: from shsmsx602.ccr.corp.intel.com (10.239.4.104) by
	PGSMSX104.gar.corp.intel.com (10.221.44.91) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Fri, 16 Dec 2011 22:55:45 +0800
Received: from shsmsx502.ccr.corp.intel.com ([10.239.4.96]) by
	SHSMSX602.ccr.corp.intel.com ([10.239.4.104]) with mapi;
	Fri, 16 Dec 2011 22:55:44 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Fri, 16 Dec 2011 22:55:43 +0800
Thread-Topic: X86-MCE: fix a bug of xen-mceinj tool
Thread-Index: Acy78r553aIpmRL5R5WireUhYl58xQAD6tGg
Message-ID: <BC00F5384FCFC9499AF06F92E8B78A9E288CB0FFA5@shsmsx502.ccr.corp.intel.com>
References: <BC00F5384FCFC9499AF06F92E8B78A9E288CB0FF82@shsmsx502.ccr.corp.intel.com>
	<4EEB4F1002000078000687A5@nat28.tlf.novell.com>
In-Reply-To: <4EEB4F1002000078000687A5@nat28.tlf.novell.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/mixed;
	boundary="_002_BC00F5384FCFC9499AF06F92E8B78A9E288CB0FFA5shsmsx502ccrc_"
MIME-Version: 1.0
Cc: "keir.xen@gmail.com" <keir.xen@gmail.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] X86-MCE: fix a bug of xen-mceinj tool
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--_002_BC00F5384FCFC9499AF06F92E8B78A9E288CB0FFA5shsmsx502ccrc_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

>>      mca_cpuinfo(xc_interface *xc_  { struct xen_mc mc;
>>=20
>> +    memset(&mc, 0, sizeof(struct xen_mc));
>=20
> I doubt this is really needed.
>=20
>> +
>>      mc.cmd =3D XEN_MC_physcpuinfo;
>> -    if (xc_mca_op(xc_handle, &mc))
>> +    mc.interface_version =3D XEN_MCA_INTERFACE_VERSION;
>=20
> Wouldn't this rather belong into xc_mca_op()?
>=20
> Jan
>=20

Yes, not necessary, update as attached.

Thanks,
Jinsong

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
X86-MCE: fix a bug of xen-mceinj tool

Fix a bug of xen-mceinj tool which used to test mce by software way.

Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>

diff -r 86defe150053 tools/tests/mce-test/tools/xen-mceinj.c
--- a/tools/tests/mce-test/tools/xen-mceinj.c	Fri Dec 16 16:24:31 2011 +080=
0
+++ b/tools/tests/mce-test/tools/xen-mceinj.c	Fri Dec 16 22:33:26 2011 +080=
0
@@ -135,7 +135,7 @@ static int mca_cpuinfo(xc_interface *xc_
     struct xen_mc mc;
=20
     mc.cmd =3D XEN_MC_physcpuinfo;
-    if (xc_mca_op(xc_handle, &mc))
+    if (!xc_mca_op(xc_handle, &mc))
         return mc.u.mc_physcpuinfo.ncpus;
     else
         return 0;=

--_002_BC00F5384FCFC9499AF06F92E8B78A9E288CB0FFA5shsmsx502ccrc_
Content-Type: application/octet-stream; name="mceinj-tools-fix.patch"
Content-Description: mceinj-tools-fix.patch
Content-Disposition: attachment; filename="mceinj-tools-fix.patch"; size=642;
	creation-date="Fri, 16 Dec 2011 22:51:26 GMT";
	modification-date="Fri, 16 Dec 2011 22:33:26 GMT"
Content-Transfer-Encoding: base64

WDg2LU1DRTogZml4IGEgYnVnIG9mIHhlbi1tY2VpbmogdG9vbAoKRml4IGEgYnVnIG9mIHhlbi1t
Y2VpbmogdG9vbCB3aGljaCB1c2VkIHRvIHRlc3QgbWNlIGJ5IHNvZnR3YXJlIHdheS4KClNpZ25l
ZC1vZmYtYnk6IExpdSwgSmluc29uZyA8amluc29uZy5saXVAaW50ZWwuY29tPgoKZGlmZiAtciA4
NmRlZmUxNTAwNTMgdG9vbHMvdGVzdHMvbWNlLXRlc3QvdG9vbHMveGVuLW1jZWluai5jCi0tLSBh
L3Rvb2xzL3Rlc3RzL21jZS10ZXN0L3Rvb2xzL3hlbi1tY2VpbmouYwlGcmkgRGVjIDE2IDE2OjI0
OjMxIDIwMTEgKzA4MDAKKysrIGIvdG9vbHMvdGVzdHMvbWNlLXRlc3QvdG9vbHMveGVuLW1jZWlu
ai5jCUZyaSBEZWMgMTYgMjI6MzM6MjYgMjAxMSArMDgwMApAQCAtMTM1LDcgKzEzNSw3IEBAIHN0
YXRpYyBpbnQgbWNhX2NwdWluZm8oeGNfaW50ZXJmYWNlICp4Y18KICAgICBzdHJ1Y3QgeGVuX21j
IG1jOwogCiAgICAgbWMuY21kID0gWEVOX01DX3BoeXNjcHVpbmZvOwotICAgIGlmICh4Y19tY2Ff
b3AoeGNfaGFuZGxlLCAmbWMpKQorICAgIGlmICgheGNfbWNhX29wKHhjX2hhbmRsZSwgJm1jKSkK
ICAgICAgICAgcmV0dXJuIG1jLnUubWNfcGh5c2NwdWluZm8ubmNwdXM7CiAgICAgZWxzZQogICAg
ICAgICByZXR1cm4gMDsK

--_002_BC00F5384FCFC9499AF06F92E8B78A9E288CB0FFA5shsmsx502ccrc_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--_002_BC00F5384FCFC9499AF06F92E8B78A9E288CB0FFA5shsmsx502ccrc_--


From xen-devel-bounces@lists.xensource.com Fri Dec 16 14:57:02 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 14:57:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbZDW-0001bo-2x; Fri, 16 Dec 2011 14:56:58 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1RbZDU-0001Yn-F4
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 14:56:56 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1324047409!7573326!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDI5ODc5Ng==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9613 invoked from network); 16 Dec 2011 14:56:50 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-12.tower-182.messagelabs.com with SMTP;
	16 Dec 2011 14:56:50 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga102.fm.intel.com with ESMTP; 16 Dec 2011 06:56:48 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="96997524"
Received: from pgsmsx602.gar.corp.intel.com ([10.221.43.81])
	by fmsmga001.fm.intel.com with ESMTP; 16 Dec 2011 06:56:47 -0800
Received: from pgsmsx104.gar.corp.intel.com (10.221.44.91) by
	pgsmsx602.gar.corp.intel.com (10.221.43.81) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Fri, 16 Dec 2011 22:55:46 +0800
Received: from shsmsx602.ccr.corp.intel.com (10.239.4.104) by
	PGSMSX104.gar.corp.intel.com (10.221.44.91) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Fri, 16 Dec 2011 22:55:45 +0800
Received: from shsmsx502.ccr.corp.intel.com ([10.239.4.96]) by
	SHSMSX602.ccr.corp.intel.com ([10.239.4.104]) with mapi;
	Fri, 16 Dec 2011 22:55:44 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Fri, 16 Dec 2011 22:55:43 +0800
Thread-Topic: X86-MCE: fix a bug of xen-mceinj tool
Thread-Index: Acy78r553aIpmRL5R5WireUhYl58xQAD6tGg
Message-ID: <BC00F5384FCFC9499AF06F92E8B78A9E288CB0FFA5@shsmsx502.ccr.corp.intel.com>
References: <BC00F5384FCFC9499AF06F92E8B78A9E288CB0FF82@shsmsx502.ccr.corp.intel.com>
	<4EEB4F1002000078000687A5@nat28.tlf.novell.com>
In-Reply-To: <4EEB4F1002000078000687A5@nat28.tlf.novell.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/mixed;
	boundary="_002_BC00F5384FCFC9499AF06F92E8B78A9E288CB0FFA5shsmsx502ccrc_"
MIME-Version: 1.0
Cc: "keir.xen@gmail.com" <keir.xen@gmail.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] X86-MCE: fix a bug of xen-mceinj tool
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--_002_BC00F5384FCFC9499AF06F92E8B78A9E288CB0FFA5shsmsx502ccrc_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

>>      mca_cpuinfo(xc_interface *xc_  { struct xen_mc mc;
>>=20
>> +    memset(&mc, 0, sizeof(struct xen_mc));
>=20
> I doubt this is really needed.
>=20
>> +
>>      mc.cmd =3D XEN_MC_physcpuinfo;
>> -    if (xc_mca_op(xc_handle, &mc))
>> +    mc.interface_version =3D XEN_MCA_INTERFACE_VERSION;
>=20
> Wouldn't this rather belong into xc_mca_op()?
>=20
> Jan
>=20

Yes, not necessary, update as attached.

Thanks,
Jinsong

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
X86-MCE: fix a bug of xen-mceinj tool

Fix a bug of xen-mceinj tool which used to test mce by software way.

Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>

diff -r 86defe150053 tools/tests/mce-test/tools/xen-mceinj.c
--- a/tools/tests/mce-test/tools/xen-mceinj.c	Fri Dec 16 16:24:31 2011 +080=
0
+++ b/tools/tests/mce-test/tools/xen-mceinj.c	Fri Dec 16 22:33:26 2011 +080=
0
@@ -135,7 +135,7 @@ static int mca_cpuinfo(xc_interface *xc_
     struct xen_mc mc;
=20
     mc.cmd =3D XEN_MC_physcpuinfo;
-    if (xc_mca_op(xc_handle, &mc))
+    if (!xc_mca_op(xc_handle, &mc))
         return mc.u.mc_physcpuinfo.ncpus;
     else
         return 0;=

--_002_BC00F5384FCFC9499AF06F92E8B78A9E288CB0FFA5shsmsx502ccrc_
Content-Type: application/octet-stream; name="mceinj-tools-fix.patch"
Content-Description: mceinj-tools-fix.patch
Content-Disposition: attachment; filename="mceinj-tools-fix.patch"; size=642;
	creation-date="Fri, 16 Dec 2011 22:51:26 GMT";
	modification-date="Fri, 16 Dec 2011 22:33:26 GMT"
Content-Transfer-Encoding: base64

WDg2LU1DRTogZml4IGEgYnVnIG9mIHhlbi1tY2VpbmogdG9vbAoKRml4IGEgYnVnIG9mIHhlbi1t
Y2VpbmogdG9vbCB3aGljaCB1c2VkIHRvIHRlc3QgbWNlIGJ5IHNvZnR3YXJlIHdheS4KClNpZ25l
ZC1vZmYtYnk6IExpdSwgSmluc29uZyA8amluc29uZy5saXVAaW50ZWwuY29tPgoKZGlmZiAtciA4
NmRlZmUxNTAwNTMgdG9vbHMvdGVzdHMvbWNlLXRlc3QvdG9vbHMveGVuLW1jZWluai5jCi0tLSBh
L3Rvb2xzL3Rlc3RzL21jZS10ZXN0L3Rvb2xzL3hlbi1tY2VpbmouYwlGcmkgRGVjIDE2IDE2OjI0
OjMxIDIwMTEgKzA4MDAKKysrIGIvdG9vbHMvdGVzdHMvbWNlLXRlc3QvdG9vbHMveGVuLW1jZWlu
ai5jCUZyaSBEZWMgMTYgMjI6MzM6MjYgMjAxMSArMDgwMApAQCAtMTM1LDcgKzEzNSw3IEBAIHN0
YXRpYyBpbnQgbWNhX2NwdWluZm8oeGNfaW50ZXJmYWNlICp4Y18KICAgICBzdHJ1Y3QgeGVuX21j
IG1jOwogCiAgICAgbWMuY21kID0gWEVOX01DX3BoeXNjcHVpbmZvOwotICAgIGlmICh4Y19tY2Ff
b3AoeGNfaGFuZGxlLCAmbWMpKQorICAgIGlmICgheGNfbWNhX29wKHhjX2hhbmRsZSwgJm1jKSkK
ICAgICAgICAgcmV0dXJuIG1jLnUubWNfcGh5c2NwdWluZm8ubmNwdXM7CiAgICAgZWxzZQogICAg
ICAgICByZXR1cm4gMDsK

--_002_BC00F5384FCFC9499AF06F92E8B78A9E288CB0FFA5shsmsx502ccrc_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--_002_BC00F5384FCFC9499AF06F92E8B78A9E288CB0FFA5shsmsx502ccrc_--


From xen-devel-bounces@lists.xensource.com Fri Dec 16 15:06:02 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 15:06:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbZM8-0002gn-7q; Fri, 16 Dec 2011 15:05:52 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RbZM6-0002gU-Sw
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 15:05:51 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1324047942!5840439!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDQ2MDg3\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5754 invoked from network); 16 Dec 2011 15:05:44 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-13.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 16 Dec 2011 15:05:44 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pBGF5bLh016063
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 16 Dec 2011 15:05:38 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pBGF5ZHx007898
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 16 Dec 2011 15:05:35 GMT
Received: from abhmt101.oracle.com (abhmt101.oracle.com [141.146.116.53])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pBGF5Ykr008334; Fri, 16 Dec 2011 09:05:34 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 16 Dec 2011 07:05:34 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 7842F4018D; Fri, 16 Dec 2011 10:04:40 -0500 (EST)
Date: Fri, 16 Dec 2011 10:04:40 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Carsten Schiers <carsten@schiers.de>
Message-ID: <20111216150440.GD31755@phenom.dumpdata.com>
References: <20111214220700.GA9926@phenom.dumpdata.com>
	<zarafa.4eeb5c0a.5be7.47c97c5342bf0bf4@uhura.space.zz>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <zarafa.4eeb5c0a.5be7.47c97c5342bf0bf4@uhura.space.zz>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090207.4EEB5E42.011C,ss=1,re=0.000,fgs=0
Cc: "linux@eikelenboom.it" <linux@eikelenboom.it>,
	xen-devel <xen-devel@lists.xensource.com>,
	"lersek@redhat.com" <lersek@redhat.com>,
	"zhenzhong.duan@oracle.com" <zhenzhong.duan@oracle.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: Re: [Xen-devel] Load increase after memory upgrade (part2)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gRnJpLCBEZWMgMTYsIDIwMTEgYXQgMDM6NTY6MTBQTSArMDEwMCwgQ2Fyc3RlbiBTY2hpZXJz
IHdyb3RlOgo+IFdlbGwsIGl0IHdpbGwgZG8gbm90aGluZyBidXQgcHJpbnQgb3V0IOKAnFNXSU9U
TEIgaXMgMCUgZnVsbOKAnS4KPiAKPiDCoAo+IERvZXMgdGhhdCBoZWxwPyBPciBkbyB5b3UgdGhp
bmsgc29tZXRoaW5nIHdlbnQgd3Jvbmcgd2l0aCB0aGUgcGF0Y2jigKYKPiAKCkFuZCB5b3UgYXJl
IHVzaW5nIHN3aW90bGI9Zm9yY2Ugb24gdGhlIDIuNi4zNCBjbGFzc2ljIGtlcm5lbCBhbmQgcGFz
c2luZwppbiB5b3VyIGJ1ZGdldC1hdiBjYXJkIGluIGl0PyBDb3VsZCB5b3UgYXBwZW5kIHRoZSBk
bWVzZyBvdXRwdXQgcGxlYXNlPwoKClRoYW5rcy4KPiDCoAo+IEJSLAo+IAo+IENhcnN0ZW4uCj4g
Cj4gwqAKPiDCoAo+IMKgCj4gVm9uOiBDYXJzdGVuIFNjaGllcnMgCj4gR2VzZW5kZXQ6IERvbm5l
cnN0YWcsIDE1LiBEZXplbWJlciAyMDExIDE1OjUzCj4gQW46IEtvbnJhZCBSemVzenV0ZWsgV2ls
azsgS29ucmFkIFJ6ZXN6dXRlayBXaWxrCj4gQ2M6IGxpbnV4QGVpa2VsZW5ib29tLml0OyB6aGVu
emhvbmcuZHVhbkBvcmFjbGUuY29tOyBJYW4gQ2FtcGJlbGw7IGxlcnNla0ByZWRoYXQuY29tOyB4
ZW4tZGV2ZWwKPiBCZXRyZWZmOiBBVzogW1hlbi1kZXZlbF0gTG9hZCBpbmNyZWFzZSBhZnRlciBt
ZW1vcnkgdXBncmFkZSAocGFydDIpCj4gCj4gwqAKPiAuLi4KPiAKPiA+IHdoaWNoIHdpbGwgcmVx
dWlyZSBzb21lIGZpZGRsaW5nIGFyb3VuZC4KPiAKPiBIZXJlIGlzIHRoZSBwYXRjaCBJIHVzZWQg
YWdhaW5zdCBjbGFzc2ljIFhlbkxpbnV4LiBBbnkgY2hhbmNlIHlvdSBjb3VsZCBydW4KPiBpdCB3
aXRoIHlvdXIgY2xhc3NpcyBndWVzdHMgYW5kIHNlZSB3aGF0IG51bWJlcnMgeW91IGdldD8KPiAK
PiBTdXJlLCBpdCBtaWdodCB0YWtlIGEgYml0LCBidXQgSSdsbCB0cnkgaXQgd2l0aCBteSAyLjYu
MzQgY2xhc3NpYyBrZXJuZWwuCj4gCj4gwqAKPiBDYXJzdGVuLgo+IAoKX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApY
ZW4tZGV2ZWxAbGlzdHMueGVuc291cmNlLmNvbQpodHRwOi8vbGlzdHMueGVuc291cmNlLmNvbS94
ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Fri Dec 16 15:06:02 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 15:06:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbZM8-0002gn-7q; Fri, 16 Dec 2011 15:05:52 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RbZM6-0002gU-Sw
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 15:05:51 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1324047942!5840439!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDQ2MDg3\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5754 invoked from network); 16 Dec 2011 15:05:44 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-13.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 16 Dec 2011 15:05:44 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pBGF5bLh016063
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 16 Dec 2011 15:05:38 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pBGF5ZHx007898
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 16 Dec 2011 15:05:35 GMT
Received: from abhmt101.oracle.com (abhmt101.oracle.com [141.146.116.53])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pBGF5Ykr008334; Fri, 16 Dec 2011 09:05:34 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 16 Dec 2011 07:05:34 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 7842F4018D; Fri, 16 Dec 2011 10:04:40 -0500 (EST)
Date: Fri, 16 Dec 2011 10:04:40 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Carsten Schiers <carsten@schiers.de>
Message-ID: <20111216150440.GD31755@phenom.dumpdata.com>
References: <20111214220700.GA9926@phenom.dumpdata.com>
	<zarafa.4eeb5c0a.5be7.47c97c5342bf0bf4@uhura.space.zz>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <zarafa.4eeb5c0a.5be7.47c97c5342bf0bf4@uhura.space.zz>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090207.4EEB5E42.011C,ss=1,re=0.000,fgs=0
Cc: "linux@eikelenboom.it" <linux@eikelenboom.it>,
	xen-devel <xen-devel@lists.xensource.com>,
	"lersek@redhat.com" <lersek@redhat.com>,
	"zhenzhong.duan@oracle.com" <zhenzhong.duan@oracle.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: Re: [Xen-devel] Load increase after memory upgrade (part2)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gRnJpLCBEZWMgMTYsIDIwMTEgYXQgMDM6NTY6MTBQTSArMDEwMCwgQ2Fyc3RlbiBTY2hpZXJz
IHdyb3RlOgo+IFdlbGwsIGl0IHdpbGwgZG8gbm90aGluZyBidXQgcHJpbnQgb3V0IOKAnFNXSU9U
TEIgaXMgMCUgZnVsbOKAnS4KPiAKPiDCoAo+IERvZXMgdGhhdCBoZWxwPyBPciBkbyB5b3UgdGhp
bmsgc29tZXRoaW5nIHdlbnQgd3Jvbmcgd2l0aCB0aGUgcGF0Y2jigKYKPiAKCkFuZCB5b3UgYXJl
IHVzaW5nIHN3aW90bGI9Zm9yY2Ugb24gdGhlIDIuNi4zNCBjbGFzc2ljIGtlcm5lbCBhbmQgcGFz
c2luZwppbiB5b3VyIGJ1ZGdldC1hdiBjYXJkIGluIGl0PyBDb3VsZCB5b3UgYXBwZW5kIHRoZSBk
bWVzZyBvdXRwdXQgcGxlYXNlPwoKClRoYW5rcy4KPiDCoAo+IEJSLAo+IAo+IENhcnN0ZW4uCj4g
Cj4gwqAKPiDCoAo+IMKgCj4gVm9uOiBDYXJzdGVuIFNjaGllcnMgCj4gR2VzZW5kZXQ6IERvbm5l
cnN0YWcsIDE1LiBEZXplbWJlciAyMDExIDE1OjUzCj4gQW46IEtvbnJhZCBSemVzenV0ZWsgV2ls
azsgS29ucmFkIFJ6ZXN6dXRlayBXaWxrCj4gQ2M6IGxpbnV4QGVpa2VsZW5ib29tLml0OyB6aGVu
emhvbmcuZHVhbkBvcmFjbGUuY29tOyBJYW4gQ2FtcGJlbGw7IGxlcnNla0ByZWRoYXQuY29tOyB4
ZW4tZGV2ZWwKPiBCZXRyZWZmOiBBVzogW1hlbi1kZXZlbF0gTG9hZCBpbmNyZWFzZSBhZnRlciBt
ZW1vcnkgdXBncmFkZSAocGFydDIpCj4gCj4gwqAKPiAuLi4KPiAKPiA+IHdoaWNoIHdpbGwgcmVx
dWlyZSBzb21lIGZpZGRsaW5nIGFyb3VuZC4KPiAKPiBIZXJlIGlzIHRoZSBwYXRjaCBJIHVzZWQg
YWdhaW5zdCBjbGFzc2ljIFhlbkxpbnV4LiBBbnkgY2hhbmNlIHlvdSBjb3VsZCBydW4KPiBpdCB3
aXRoIHlvdXIgY2xhc3NpcyBndWVzdHMgYW5kIHNlZSB3aGF0IG51bWJlcnMgeW91IGdldD8KPiAK
PiBTdXJlLCBpdCBtaWdodCB0YWtlIGEgYml0LCBidXQgSSdsbCB0cnkgaXQgd2l0aCBteSAyLjYu
MzQgY2xhc3NpYyBrZXJuZWwuCj4gCj4gwqAKPiBDYXJzdGVuLgo+IAoKX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApY
ZW4tZGV2ZWxAbGlzdHMueGVuc291cmNlLmNvbQpodHRwOi8vbGlzdHMueGVuc291cmNlLmNvbS94
ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Fri Dec 16 15:17:04 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 15:17:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbZWj-0002t3-GV; Fri, 16 Dec 2011 15:16:49 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1RbZWi-0002sy-Ma
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 15:16:48 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-11.tower-174.messagelabs.com!1324048600!5855861!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25104 invoked from network); 16 Dec 2011 15:16:42 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-11.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 16 Dec 2011 15:16:42 -0000
Received: from andromeda.dapyr.net (darnok@localhost [127.0.0.1])
	by andromeda.dapyr.net (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id
	pBGFGDlH004495
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Fri, 16 Dec 2011 10:16:13 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pBGFGDfN004493;
	Fri, 16 Dec 2011 10:16:13 -0500
Date: Fri, 16 Dec 2011 11:16:13 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: dbrace <dab@hp.com>
Message-ID: <20111216151613.GA4369@andromeda.dapyr.net>
References: <4EDFDF0D.2020104@hp.com>
	<4EE628D80200007800066F9E@nat28.tlf.novell.com>
	<20111214213443.GC25896@andromeda.dapyr.net>
	<4EE9C15602000078000680D3@nat28.tlf.novell.com>
	<6738613108553D49BEFEFDD59230CCDF011BED93@G4W3300.americas.hpqcorp.net>
	<4EEA304402000078000684C8@nat28.tlf.novell.com>
	<4EEA8084.8030208@hp.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4EEA8084.8030208@hp.com>
User-Agent: Mutt/1.5.9i
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] kmap_atomic issue with SLES11SP1 32bit XEN driver
	code
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Dec 15, 2011 at 05:19:32PM -0600, dbrace wrote:
> Can you give me some URLs to documentation that can help me understand 
> my issue?
> 
> Is sounds like I cannot go back to the correct virtual address after I 
> map it for DMA.

Well yes. That assumption that virt_to_phys == phys_to_virt is not valid
anymore. The obvious solution to your problem is to carry a _both_
values - the bus address (the one you get from the DMA API), and the
virtual address (the one you get from alloc_page). That is how all the 
drivers do it.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 15:17:04 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 15:17:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbZWj-0002t3-GV; Fri, 16 Dec 2011 15:16:49 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1RbZWi-0002sy-Ma
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 15:16:48 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-11.tower-174.messagelabs.com!1324048600!5855861!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25104 invoked from network); 16 Dec 2011 15:16:42 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-11.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 16 Dec 2011 15:16:42 -0000
Received: from andromeda.dapyr.net (darnok@localhost [127.0.0.1])
	by andromeda.dapyr.net (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id
	pBGFGDlH004495
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Fri, 16 Dec 2011 10:16:13 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pBGFGDfN004493;
	Fri, 16 Dec 2011 10:16:13 -0500
Date: Fri, 16 Dec 2011 11:16:13 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: dbrace <dab@hp.com>
Message-ID: <20111216151613.GA4369@andromeda.dapyr.net>
References: <4EDFDF0D.2020104@hp.com>
	<4EE628D80200007800066F9E@nat28.tlf.novell.com>
	<20111214213443.GC25896@andromeda.dapyr.net>
	<4EE9C15602000078000680D3@nat28.tlf.novell.com>
	<6738613108553D49BEFEFDD59230CCDF011BED93@G4W3300.americas.hpqcorp.net>
	<4EEA304402000078000684C8@nat28.tlf.novell.com>
	<4EEA8084.8030208@hp.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4EEA8084.8030208@hp.com>
User-Agent: Mutt/1.5.9i
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] kmap_atomic issue with SLES11SP1 32bit XEN driver
	code
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Dec 15, 2011 at 05:19:32PM -0600, dbrace wrote:
> Can you give me some URLs to documentation that can help me understand 
> my issue?
> 
> Is sounds like I cannot go back to the correct virtual address after I 
> map it for DMA.

Well yes. That assumption that virt_to_phys == phys_to_virt is not valid
anymore. The obvious solution to your problem is to carry a _both_
values - the bus address (the one you get from the DMA API), and the
virtual address (the one you get from alloc_page). That is how all the 
drivers do it.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 15:23:16 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 15: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.xensource.com>)
	id 1RbZci-000348-AH; Fri, 16 Dec 2011 15:23:00 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RbZch-000340-BT
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 15:22:59 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1324048953!59244635!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30688 invoked from network); 16 Dec 2011 15:22:33 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-15.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 16 Dec 2011 15:22:33 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 16 Dec 2011 15:22:52 +0000
Message-Id: <4EEB70910200007800068852@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 16 Dec 2011 15:23:45 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part3E119691.1__="
Cc: wei.huang2@amd.com
Subject: [Xen-devel] [PATCH] x86/AMD: fold redundant parameters of
 cpu_has_amd_erratum()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__Part3E119691.1__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

The boolean 'osvw' indicator and 'osvw_id' can be folded - the function
can as well distinguish the non-OSVW case by checking for a negative
'osvw_id'. That way the whole variable argument list processing is only
needed on the legacy code path.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/cpu/amd.c
+++ b/xen/arch/x86/cpu/amd.c
@@ -186,7 +186,7 @@ static void __devinit set_cpuidmask(cons
  * Check for the presence of an AMD erratum. Arguments are defined in =
amd.h=20
  * for each known erratum. Return 1 if erratum is found.
  */
-int cpu_has_amd_erratum(const struct cpuinfo_x86 *cpu, int osvw, ...)=20
+int cpu_has_amd_erratum(const struct cpuinfo_x86 *cpu, int osvw_id, ...)
 {
 	va_list ap;
 	u32 range;
@@ -195,27 +195,24 @@ int cpu_has_amd_erratum(const struct cpu
 	if (cpu->x86_vendor !=3D X86_VENDOR_AMD)
 		return 0;
=20
-	va_start(ap, osvw);
+	if (osvw_id >=3D 0 && cpu_has(cpu, X86_FEATURE_OSVW)) {
+		u64 osvw_len;
=20
-	if (osvw) {
-		u16 osvw_id =3D va_arg(ap, int);
+		rdmsrl(MSR_AMD_OSVW_ID_LENGTH, osvw_len);
=20
-		if (cpu_has(cpu, X86_FEATURE_OSVW)) {
-			u64 osvw_len;
-			rdmsrl(MSR_AMD_OSVW_ID_LENGTH, osvw_len);
-
-			if (osvw_id < osvw_len) {
-				u64 osvw_bits;
-				rdmsrl(MSR_AMD_OSVW_STATUS + (osvw_id >> =
6),=20
-				       osvw_bits);
+		if (osvw_id < osvw_len) {
+			u64 osvw_bits;
=20
-				va_end(ap);
-				return (osvw_bits >> (osvw_id & 0x3f)) & =
0x01;
-			}
+			rdmsrl(MSR_AMD_OSVW_STATUS + (osvw_id >> 6),
+			       osvw_bits);
+
+			return (osvw_bits >> (osvw_id & 0x3f)) & 1;
 		}
 	}
=20
 	/* OSVW unavailable or ID unknown, match family-model-stepping =
range */
+	va_start(ap, osvw_id);
+
 	ms =3D (cpu->x86_model << 4) | cpu->x86_mask;
 	while ((range =3D va_arg(ap, int))) {
 		if ((cpu->x86 =3D=3D AMD_MODEL_RANGE_FAMILY(range)) &&
--- a/xen/include/asm-x86/amd.h
+++ b/xen/include/asm-x86/amd.h
@@ -119,8 +119,8 @@
  *  =20
  */
=20
-#define AMD_LEGACY_ERRATUM(...)         0 /* legacy */, __VA_ARGS__, 0
-#define AMD_OSVW_ERRATUM(osvw_id, ...)  1 /* osvw */, osvw_id, __VA_ARGS__=
, 0
+#define AMD_LEGACY_ERRATUM(...)         -1 /* legacy */, __VA_ARGS__, 0
+#define AMD_OSVW_ERRATUM(osvw_id, ...)  osvw_id, __VA_ARGS__, 0
 #define AMD_MODEL_RANGE(f, m_start, s_start, m_end, s_end)              \
     ((f << 24) | (m_start << 16) | (s_start << 12) | (m_end << 4) | =
(s_end))
 #define AMD_MODEL_RANGE_FAMILY(range)   (((range) >> 24) & 0xff)




--=__Part3E119691.1__=
Content-Type: text/plain; name="amd-errata-redundant-param.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="amd-errata-redundant-param.patch"

x86/AMD: fold redundant parameters of cpu_has_amd_erratum()=0A=0AThe =
boolean 'osvw' indicator and 'osvw_id' can be folded - the function=0Acan =
as well distinguish the non-OSVW case by checking for a negative=0A'osvw_id=
'. That way the whole variable argument list processing is only=0Aneeded =
on the legacy code path.=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.com=
>=0A=0A--- a/xen/arch/x86/cpu/amd.c=0A+++ b/xen/arch/x86/cpu/amd.c=0A@@ =
-186,7 +186,7 @@ static void __devinit set_cpuidmask(cons=0A  * Check for =
the presence of an AMD erratum. Arguments are defined in amd.h =0A  * for =
each known erratum. Return 1 if erratum is found.=0A  */=0A-int cpu_has_amd=
_erratum(const struct cpuinfo_x86 *cpu, int osvw, ...) =0A+int cpu_has_amd_=
erratum(const struct cpuinfo_x86 *cpu, int osvw_id, ...)=0A {=0A 	=
va_list ap;=0A 	u32 range;=0A@@ -195,27 +195,24 @@ int cpu_has_amd_erratum(=
const struct cpu=0A 	if (cpu->x86_vendor !=3D X86_VENDOR_AMD)=0A 		=
return 0;=0A =0A-	va_start(ap, osvw);=0A+	if (osvw_id >=3D 0 && =
cpu_has(cpu, X86_FEATURE_OSVW)) {=0A+		u64 osvw_len;=0A =0A-	if =
(osvw) {=0A-		u16 osvw_id =3D va_arg(ap, int);=0A+		=
rdmsrl(MSR_AMD_OSVW_ID_LENGTH, osvw_len);=0A =0A-		if =
(cpu_has(cpu, X86_FEATURE_OSVW)) {=0A-			u64 osvw_len;=0A-	=
		rdmsrl(MSR_AMD_OSVW_ID_LENGTH, osvw_len);=0A-=0A-		=
	if (osvw_id < osvw_len) {=0A-				u64 =
osvw_bits;=0A-				rdmsrl(MSR_AMD_OSVW_STATUS + =
(osvw_id >> 6), =0A-				       osvw_bits);=0A+		=
if (osvw_id < osvw_len) {=0A+			u64 osvw_bits;=0A =0A-		=
		va_end(ap);=0A-				return (osvw_bits =
>> (osvw_id & 0x3f)) & 0x01;=0A-			}=0A+			=
rdmsrl(MSR_AMD_OSVW_STATUS + (osvw_id >> 6),=0A+			   =
    osvw_bits);=0A+=0A+			return (osvw_bits >> (osvw_id & =
0x3f)) & 1;=0A 		}=0A 	}=0A =0A 	/* OSVW unavailable or ID =
unknown, match family-model-stepping range */=0A+	va_start(ap, =
osvw_id);=0A+=0A 	ms =3D (cpu->x86_model << 4) | cpu->x86_mask;=0A 	=
while ((range =3D va_arg(ap, int))) {=0A 		if ((cpu->x86 =
=3D=3D AMD_MODEL_RANGE_FAMILY(range)) &&=0A--- a/xen/include/asm-x86/amd.h=
=0A+++ b/xen/include/asm-x86/amd.h=0A@@ -119,8 +119,8 @@=0A  *   =0A  =
*/=0A =0A-#define AMD_LEGACY_ERRATUM(...)         0 /* legacy */, =
__VA_ARGS__, 0=0A-#define AMD_OSVW_ERRATUM(osvw_id, ...)  1 /* osvw */, =
osvw_id, __VA_ARGS__, 0=0A+#define AMD_LEGACY_ERRATUM(...)         -1 /* =
legacy */, __VA_ARGS__, 0=0A+#define AMD_OSVW_ERRATUM(osvw_id, ...)  =
osvw_id, __VA_ARGS__, 0=0A #define AMD_MODEL_RANGE(f, m_start, s_start, =
m_end, s_end)              \=0A     ((f << 24) | (m_start << 16) | =
(s_start << 12) | (m_end << 4) | (s_end))=0A #define AMD_MODEL_RANGE_FAMILY=
(range)   (((range) >> 24) & 0xff)=0A
--=__Part3E119691.1__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--=__Part3E119691.1__=--


From xen-devel-bounces@lists.xensource.com Fri Dec 16 15:23:16 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 15: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.xensource.com>)
	id 1RbZci-000348-AH; Fri, 16 Dec 2011 15:23:00 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RbZch-000340-BT
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 15:22:59 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1324048953!59244635!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30688 invoked from network); 16 Dec 2011 15:22:33 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-15.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 16 Dec 2011 15:22:33 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 16 Dec 2011 15:22:52 +0000
Message-Id: <4EEB70910200007800068852@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 16 Dec 2011 15:23:45 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part3E119691.1__="
Cc: wei.huang2@amd.com
Subject: [Xen-devel] [PATCH] x86/AMD: fold redundant parameters of
 cpu_has_amd_erratum()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__Part3E119691.1__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

The boolean 'osvw' indicator and 'osvw_id' can be folded - the function
can as well distinguish the non-OSVW case by checking for a negative
'osvw_id'. That way the whole variable argument list processing is only
needed on the legacy code path.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/cpu/amd.c
+++ b/xen/arch/x86/cpu/amd.c
@@ -186,7 +186,7 @@ static void __devinit set_cpuidmask(cons
  * Check for the presence of an AMD erratum. Arguments are defined in =
amd.h=20
  * for each known erratum. Return 1 if erratum is found.
  */
-int cpu_has_amd_erratum(const struct cpuinfo_x86 *cpu, int osvw, ...)=20
+int cpu_has_amd_erratum(const struct cpuinfo_x86 *cpu, int osvw_id, ...)
 {
 	va_list ap;
 	u32 range;
@@ -195,27 +195,24 @@ int cpu_has_amd_erratum(const struct cpu
 	if (cpu->x86_vendor !=3D X86_VENDOR_AMD)
 		return 0;
=20
-	va_start(ap, osvw);
+	if (osvw_id >=3D 0 && cpu_has(cpu, X86_FEATURE_OSVW)) {
+		u64 osvw_len;
=20
-	if (osvw) {
-		u16 osvw_id =3D va_arg(ap, int);
+		rdmsrl(MSR_AMD_OSVW_ID_LENGTH, osvw_len);
=20
-		if (cpu_has(cpu, X86_FEATURE_OSVW)) {
-			u64 osvw_len;
-			rdmsrl(MSR_AMD_OSVW_ID_LENGTH, osvw_len);
-
-			if (osvw_id < osvw_len) {
-				u64 osvw_bits;
-				rdmsrl(MSR_AMD_OSVW_STATUS + (osvw_id >> =
6),=20
-				       osvw_bits);
+		if (osvw_id < osvw_len) {
+			u64 osvw_bits;
=20
-				va_end(ap);
-				return (osvw_bits >> (osvw_id & 0x3f)) & =
0x01;
-			}
+			rdmsrl(MSR_AMD_OSVW_STATUS + (osvw_id >> 6),
+			       osvw_bits);
+
+			return (osvw_bits >> (osvw_id & 0x3f)) & 1;
 		}
 	}
=20
 	/* OSVW unavailable or ID unknown, match family-model-stepping =
range */
+	va_start(ap, osvw_id);
+
 	ms =3D (cpu->x86_model << 4) | cpu->x86_mask;
 	while ((range =3D va_arg(ap, int))) {
 		if ((cpu->x86 =3D=3D AMD_MODEL_RANGE_FAMILY(range)) &&
--- a/xen/include/asm-x86/amd.h
+++ b/xen/include/asm-x86/amd.h
@@ -119,8 +119,8 @@
  *  =20
  */
=20
-#define AMD_LEGACY_ERRATUM(...)         0 /* legacy */, __VA_ARGS__, 0
-#define AMD_OSVW_ERRATUM(osvw_id, ...)  1 /* osvw */, osvw_id, __VA_ARGS__=
, 0
+#define AMD_LEGACY_ERRATUM(...)         -1 /* legacy */, __VA_ARGS__, 0
+#define AMD_OSVW_ERRATUM(osvw_id, ...)  osvw_id, __VA_ARGS__, 0
 #define AMD_MODEL_RANGE(f, m_start, s_start, m_end, s_end)              \
     ((f << 24) | (m_start << 16) | (s_start << 12) | (m_end << 4) | =
(s_end))
 #define AMD_MODEL_RANGE_FAMILY(range)   (((range) >> 24) & 0xff)




--=__Part3E119691.1__=
Content-Type: text/plain; name="amd-errata-redundant-param.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="amd-errata-redundant-param.patch"

x86/AMD: fold redundant parameters of cpu_has_amd_erratum()=0A=0AThe =
boolean 'osvw' indicator and 'osvw_id' can be folded - the function=0Acan =
as well distinguish the non-OSVW case by checking for a negative=0A'osvw_id=
'. That way the whole variable argument list processing is only=0Aneeded =
on the legacy code path.=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.com=
>=0A=0A--- a/xen/arch/x86/cpu/amd.c=0A+++ b/xen/arch/x86/cpu/amd.c=0A@@ =
-186,7 +186,7 @@ static void __devinit set_cpuidmask(cons=0A  * Check for =
the presence of an AMD erratum. Arguments are defined in amd.h =0A  * for =
each known erratum. Return 1 if erratum is found.=0A  */=0A-int cpu_has_amd=
_erratum(const struct cpuinfo_x86 *cpu, int osvw, ...) =0A+int cpu_has_amd_=
erratum(const struct cpuinfo_x86 *cpu, int osvw_id, ...)=0A {=0A 	=
va_list ap;=0A 	u32 range;=0A@@ -195,27 +195,24 @@ int cpu_has_amd_erratum(=
const struct cpu=0A 	if (cpu->x86_vendor !=3D X86_VENDOR_AMD)=0A 		=
return 0;=0A =0A-	va_start(ap, osvw);=0A+	if (osvw_id >=3D 0 && =
cpu_has(cpu, X86_FEATURE_OSVW)) {=0A+		u64 osvw_len;=0A =0A-	if =
(osvw) {=0A-		u16 osvw_id =3D va_arg(ap, int);=0A+		=
rdmsrl(MSR_AMD_OSVW_ID_LENGTH, osvw_len);=0A =0A-		if =
(cpu_has(cpu, X86_FEATURE_OSVW)) {=0A-			u64 osvw_len;=0A-	=
		rdmsrl(MSR_AMD_OSVW_ID_LENGTH, osvw_len);=0A-=0A-		=
	if (osvw_id < osvw_len) {=0A-				u64 =
osvw_bits;=0A-				rdmsrl(MSR_AMD_OSVW_STATUS + =
(osvw_id >> 6), =0A-				       osvw_bits);=0A+		=
if (osvw_id < osvw_len) {=0A+			u64 osvw_bits;=0A =0A-		=
		va_end(ap);=0A-				return (osvw_bits =
>> (osvw_id & 0x3f)) & 0x01;=0A-			}=0A+			=
rdmsrl(MSR_AMD_OSVW_STATUS + (osvw_id >> 6),=0A+			   =
    osvw_bits);=0A+=0A+			return (osvw_bits >> (osvw_id & =
0x3f)) & 1;=0A 		}=0A 	}=0A =0A 	/* OSVW unavailable or ID =
unknown, match family-model-stepping range */=0A+	va_start(ap, =
osvw_id);=0A+=0A 	ms =3D (cpu->x86_model << 4) | cpu->x86_mask;=0A 	=
while ((range =3D va_arg(ap, int))) {=0A 		if ((cpu->x86 =
=3D=3D AMD_MODEL_RANGE_FAMILY(range)) &&=0A--- a/xen/include/asm-x86/amd.h=
=0A+++ b/xen/include/asm-x86/amd.h=0A@@ -119,8 +119,8 @@=0A  *   =0A  =
*/=0A =0A-#define AMD_LEGACY_ERRATUM(...)         0 /* legacy */, =
__VA_ARGS__, 0=0A-#define AMD_OSVW_ERRATUM(osvw_id, ...)  1 /* osvw */, =
osvw_id, __VA_ARGS__, 0=0A+#define AMD_LEGACY_ERRATUM(...)         -1 /* =
legacy */, __VA_ARGS__, 0=0A+#define AMD_OSVW_ERRATUM(osvw_id, ...)  =
osvw_id, __VA_ARGS__, 0=0A #define AMD_MODEL_RANGE(f, m_start, s_start, =
m_end, s_end)              \=0A     ((f << 24) | (m_start << 16) | =
(s_start << 12) | (m_end << 4) | (s_end))=0A #define AMD_MODEL_RANGE_FAMILY=
(range)   (((range) >> 24) & 0xff)=0A
--=__Part3E119691.1__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--=__Part3E119691.1__=--


From xen-devel-bounces@lists.xensource.com Fri Dec 16 15:26:13 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 15:26:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbZfZ-0003DM-Sc; Fri, 16 Dec 2011 15:25:57 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RbZfX-0003D4-SE
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 15:25:56 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1324049149!5677846!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29744 invoked from network); 16 Dec 2011 15:25:49 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-16.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 16 Dec 2011 15:25:49 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 16 Dec 2011 15:25:49 +0000
Message-Id: <4EEB71410200007800068855@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 16 Dec 2011 15:26:41 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Jackson" <Ian.Jackson@eu.citrix.com>,
	"Jinsong Liu" <jinsong.liu@intel.com>
References: <BC00F5384FCFC9499AF06F92E8B78A9E288CB0FF82@shsmsx502.ccr.corp.intel.com>
	<4EEB4F1002000078000687A5@nat28.tlf.novell.com>
	<BC00F5384FCFC9499AF06F92E8B78A9E288CB0FFA5@shsmsx502.ccr.corp.intel.com>
In-Reply-To: <BC00F5384FCFC9499AF06F92E8B78A9E288CB0FFA5@shsmsx502.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "keir.xen@gmail.com" <keir.xen@gmail.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] X86-MCE: fix a bug of xen-mceinj tool
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 16.12.11 at 15:55, "Liu, Jinsong" <jinsong.liu@intel.com> wrote:
> X86-MCE: fix a bug of xen-mceinj tool
> 
> Fix a bug of xen-mceinj tool which used to test mce by software way.
> 
> Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>

Acked-by: Jan Beulich <jbeulich@suse.com>

> diff -r 86defe150053 tools/tests/mce-test/tools/xen-mceinj.c
> --- a/tools/tests/mce-test/tools/xen-mceinj.c	Fri Dec 16 16:24:31 2011 +0800
> +++ b/tools/tests/mce-test/tools/xen-mceinj.c	Fri Dec 16 22:33:26 2011 +0800
> @@ -135,7 +135,7 @@ static int mca_cpuinfo(xc_interface *xc_
>      struct xen_mc mc;
>  
>      mc.cmd = XEN_MC_physcpuinfo;
> -    if (xc_mca_op(xc_handle, &mc))
> +    if (!xc_mca_op(xc_handle, &mc))
>          return mc.u.mc_physcpuinfo.ncpus;
>      else
>          return 0;




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 15:26:13 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 15:26:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbZfZ-0003DM-Sc; Fri, 16 Dec 2011 15:25:57 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RbZfX-0003D4-SE
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 15:25:56 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1324049149!5677846!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29744 invoked from network); 16 Dec 2011 15:25:49 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-16.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 16 Dec 2011 15:25:49 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 16 Dec 2011 15:25:49 +0000
Message-Id: <4EEB71410200007800068855@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 16 Dec 2011 15:26:41 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Jackson" <Ian.Jackson@eu.citrix.com>,
	"Jinsong Liu" <jinsong.liu@intel.com>
References: <BC00F5384FCFC9499AF06F92E8B78A9E288CB0FF82@shsmsx502.ccr.corp.intel.com>
	<4EEB4F1002000078000687A5@nat28.tlf.novell.com>
	<BC00F5384FCFC9499AF06F92E8B78A9E288CB0FFA5@shsmsx502.ccr.corp.intel.com>
In-Reply-To: <BC00F5384FCFC9499AF06F92E8B78A9E288CB0FFA5@shsmsx502.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "keir.xen@gmail.com" <keir.xen@gmail.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] X86-MCE: fix a bug of xen-mceinj tool
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 16.12.11 at 15:55, "Liu, Jinsong" <jinsong.liu@intel.com> wrote:
> X86-MCE: fix a bug of xen-mceinj tool
> 
> Fix a bug of xen-mceinj tool which used to test mce by software way.
> 
> Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>

Acked-by: Jan Beulich <jbeulich@suse.com>

> diff -r 86defe150053 tools/tests/mce-test/tools/xen-mceinj.c
> --- a/tools/tests/mce-test/tools/xen-mceinj.c	Fri Dec 16 16:24:31 2011 +0800
> +++ b/tools/tests/mce-test/tools/xen-mceinj.c	Fri Dec 16 22:33:26 2011 +0800
> @@ -135,7 +135,7 @@ static int mca_cpuinfo(xc_interface *xc_
>      struct xen_mc mc;
>  
>      mc.cmd = XEN_MC_physcpuinfo;
> -    if (xc_mca_op(xc_handle, &mc))
> +    if (!xc_mca_op(xc_handle, &mc))
>          return mc.u.mc_physcpuinfo.ncpus;
>      else
>          return 0;




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 15:27:36 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 15: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.xensource.com>)
	id 1RbZgy-0003J4-CW; Fri, 16 Dec 2011 15:27:24 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RbZgw-0003Is-Ej
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 15:27:22 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1324049129!56488563!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDQ2MDg3\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27144 invoked from network); 16 Dec 2011 15:25:30 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-8.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Dec 2011 15:25:30 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pBGFQTdY010557
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 16 Dec 2011 15:26:30 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pBGFQSKs014433
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 16 Dec 2011 15:26:28 GMT
Received: from abhmt112.oracle.com (abhmt112.oracle.com [141.146.116.64])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pBGFQR2Y029702; Fri, 16 Dec 2011 09:26:27 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 16 Dec 2011 07:26:27 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 92BD84018D; Fri, 16 Dec 2011 10:25:33 -0500 (EST)
Date: Fri, 16 Dec 2011 10:25:33 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Olaf Hering <olaf@aepfle.de>, pradeepv@amazon.com,
	scott.moser@canonical.com
Message-ID: <20111216152533.GE31755@phenom.dumpdata.com>
References: <4EEA4877.8010307@canonical.com>
	<20111215193942.GA7640@andromeda.dapyr.net>
	<20111216113300.GA4854@aepfle.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20111216113300.GA4854@aepfle.de>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090208.4EEB6327.0041,ss=1,re=0.000,fgs=0
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefan Bader <stefan.bader@canonical.com>
Subject: Re: [Xen-devel] xenbus and the message of doom
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Dec 16, 2011 at 12:33:00PM +0100, Olaf Hering wrote:
> On Thu, Dec 15, Konrad Rzeszutek Wilk wrote:
> 
> > On Thu, Dec 15, 2011 at 08:20:23PM +0100, Stefan Bader wrote:
> > > I was investigating a bug report[1] about newer kernels (>3.1) not booting as
> > > HVM guests on Amazon EC2. For some reason git bisect did give the some pain, but
> > > it lead me at least close and with some crash dump data I think I figured the
> > > problem.
> > 
> > Stefan, thanks for finding this.
> > 
> > Olaf, what are your thoughts? Should I prep a patch to revert the patch
> > below and then we can work on 3.3 and rethink this in 3.3? The clock is
> > ticking for 3.2 and there is not much runway to fix stuff.
> 
> Sometimes guest changes expose bugs in the host. Its my understanding
> that hosts should be kept uptodate so that it can serve both old and new
> guests well.
> 
> In my testing with Xen4 based hosts their xenstored did properly ignore
> the new command.
> 
> I proposed several ways to get rid of existing watches, but finally we
> came to the conclusion that a new xenstored command would be the
> cleanest way.
> 
> Wether adding a timeout is a good idea has to be decided. I can imagine
> that a busy host may take some time to respond to guest commands.
> 
> 
> Perhaps we should figure out what exactly EC2 is using as host and why
> it only breaks with upstream kernels. So far I havent received reports

Good point. Stefan were you able to provide to Scott a kernel without the
git commit mentioned to see if that fixed the issue?

CC-ing here Vincent in hopes of getting some hints..

> for SLES11 guests. SP1 got an update recently, so their HVM guests would
> have seen the hang as well. The not yet released SP2 sends
> XS_RESET_WATCHES as well since quite some time.
> 
> 
> Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 15:27:36 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 15: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.xensource.com>)
	id 1RbZgy-0003J4-CW; Fri, 16 Dec 2011 15:27:24 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RbZgw-0003Is-Ej
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 15:27:22 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1324049129!56488563!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDQ2MDg3\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27144 invoked from network); 16 Dec 2011 15:25:30 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-8.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Dec 2011 15:25:30 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pBGFQTdY010557
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 16 Dec 2011 15:26:30 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pBGFQSKs014433
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 16 Dec 2011 15:26:28 GMT
Received: from abhmt112.oracle.com (abhmt112.oracle.com [141.146.116.64])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pBGFQR2Y029702; Fri, 16 Dec 2011 09:26:27 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 16 Dec 2011 07:26:27 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 92BD84018D; Fri, 16 Dec 2011 10:25:33 -0500 (EST)
Date: Fri, 16 Dec 2011 10:25:33 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Olaf Hering <olaf@aepfle.de>, pradeepv@amazon.com,
	scott.moser@canonical.com
Message-ID: <20111216152533.GE31755@phenom.dumpdata.com>
References: <4EEA4877.8010307@canonical.com>
	<20111215193942.GA7640@andromeda.dapyr.net>
	<20111216113300.GA4854@aepfle.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20111216113300.GA4854@aepfle.de>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090208.4EEB6327.0041,ss=1,re=0.000,fgs=0
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefan Bader <stefan.bader@canonical.com>
Subject: Re: [Xen-devel] xenbus and the message of doom
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Dec 16, 2011 at 12:33:00PM +0100, Olaf Hering wrote:
> On Thu, Dec 15, Konrad Rzeszutek Wilk wrote:
> 
> > On Thu, Dec 15, 2011 at 08:20:23PM +0100, Stefan Bader wrote:
> > > I was investigating a bug report[1] about newer kernels (>3.1) not booting as
> > > HVM guests on Amazon EC2. For some reason git bisect did give the some pain, but
> > > it lead me at least close and with some crash dump data I think I figured the
> > > problem.
> > 
> > Stefan, thanks for finding this.
> > 
> > Olaf, what are your thoughts? Should I prep a patch to revert the patch
> > below and then we can work on 3.3 and rethink this in 3.3? The clock is
> > ticking for 3.2 and there is not much runway to fix stuff.
> 
> Sometimes guest changes expose bugs in the host. Its my understanding
> that hosts should be kept uptodate so that it can serve both old and new
> guests well.
> 
> In my testing with Xen4 based hosts their xenstored did properly ignore
> the new command.
> 
> I proposed several ways to get rid of existing watches, but finally we
> came to the conclusion that a new xenstored command would be the
> cleanest way.
> 
> Wether adding a timeout is a good idea has to be decided. I can imagine
> that a busy host may take some time to respond to guest commands.
> 
> 
> Perhaps we should figure out what exactly EC2 is using as host and why
> it only breaks with upstream kernels. So far I havent received reports

Good point. Stefan were you able to provide to Scott a kernel without the
git commit mentioned to see if that fixed the issue?

CC-ing here Vincent in hopes of getting some hints..

> for SLES11 guests. SP1 got an update recently, so their HVM guests would
> have seen the hang as well. The not yet released SP2 sends
> XS_RESET_WATCHES as well since quite some time.
> 
> 
> Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 15:32:39 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 15:32:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbZlq-0003Zn-4Y; Fri, 16 Dec 2011 15:32:26 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1RbZlp-0003Zb-Aq
	for xen-DEVEL@lists.xensource.com; Fri, 16 Dec 2011 15:32:25 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-11.tower-174.messagelabs.com!1324049536!5858223!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17915 invoked from network); 16 Dec 2011 15:32:18 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-11.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 16 Dec 2011 15:32:18 -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
	pBGFWCrw005385
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Fri, 16 Dec 2011 10:32:12 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pBGFWBj1005383;
	Fri, 16 Dec 2011 10:32:11 -0500
Date: Fri, 16 Dec 2011 11:32:11 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Jan Vejvalka <jan.vejvalka@lfmotol.cuni.cz>
Message-ID: <20111216153211.GA5120@andromeda.dapyr.net>
References: <4EE8E725.30208@lfmotol.cuni.cz>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4EE8E725.30208@lfmotol.cuni.cz>
User-Agent: Mutt/1.5.9i
Cc: xen-DEVEL@lists.xensource.com
Subject: Re: [Xen-devel] Failure to start X windows in Dom0 under Xen 4.1.2
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Dec 14, 2011 at 07:12:53PM +0100, Jan Vejvalka wrote:
> Hi *,
> 
>   after two unsuccessful attempts to get help on xen-users, I dare to
> re-post my problem to zen-devel.
> I'll be grateful for any hint.

I am going to need some more details
[http://wiki.xen.org/xenwiki/XenParavirtOpsHelp.html]

If you can't get the full serial console, you can give the 'xl dmesg'
and 'dmesg' output.

Also did you look in:
http://wiki.xen.org/xenwiki/XenParavirtOps.html#head-214e7c90d504695bacd261fbeed67f6a0d1e73a7

and
http://wiki.xen.org/xenwiki/XenParavirtOps.html#head-9fb34d1cf597800d371b844568797d4db8587dce

> 
> Trying to run X windows on Linux 3.1.1 Dom0 kernel under Xen 4.1.2
> (built as http://slackbuilds.org/repository/13.37/system/xen/) on
> Slackware 64-13.37. (The next step should be a HVM guest driven through
> a vnc window from Dom0).
> 
> On the same kernel booted natively, all works fine; when booting under
> Xen, Xorg does not start. The (relevant?) error messages that I find in
> Xorg.0.log are
> 
> (WW) System lacks support for changing MTRRs
> (EE) VESA(0): V_BIOS address 0x0 out of range
> 
> (the full diff of the respective Xorg.0.log-s is at
> http://camelot.lf2.cuni.cz/vejvalka/posts/xlog-diff)
> 
> What is it that I am missing ?

>From a first glance it looks as if the KMS drivers hadn't been loaded -
but I don't know which ones (since I don't know what drivers you have).

> Thanks for any hint,
> 
> Jan
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 15:32:39 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 15:32:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbZlq-0003Zn-4Y; Fri, 16 Dec 2011 15:32:26 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1RbZlp-0003Zb-Aq
	for xen-DEVEL@lists.xensource.com; Fri, 16 Dec 2011 15:32:25 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-11.tower-174.messagelabs.com!1324049536!5858223!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17915 invoked from network); 16 Dec 2011 15:32:18 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-11.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 16 Dec 2011 15:32:18 -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
	pBGFWCrw005385
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Fri, 16 Dec 2011 10:32:12 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pBGFWBj1005383;
	Fri, 16 Dec 2011 10:32:11 -0500
Date: Fri, 16 Dec 2011 11:32:11 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Jan Vejvalka <jan.vejvalka@lfmotol.cuni.cz>
Message-ID: <20111216153211.GA5120@andromeda.dapyr.net>
References: <4EE8E725.30208@lfmotol.cuni.cz>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4EE8E725.30208@lfmotol.cuni.cz>
User-Agent: Mutt/1.5.9i
Cc: xen-DEVEL@lists.xensource.com
Subject: Re: [Xen-devel] Failure to start X windows in Dom0 under Xen 4.1.2
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Dec 14, 2011 at 07:12:53PM +0100, Jan Vejvalka wrote:
> Hi *,
> 
>   after two unsuccessful attempts to get help on xen-users, I dare to
> re-post my problem to zen-devel.
> I'll be grateful for any hint.

I am going to need some more details
[http://wiki.xen.org/xenwiki/XenParavirtOpsHelp.html]

If you can't get the full serial console, you can give the 'xl dmesg'
and 'dmesg' output.

Also did you look in:
http://wiki.xen.org/xenwiki/XenParavirtOps.html#head-214e7c90d504695bacd261fbeed67f6a0d1e73a7

and
http://wiki.xen.org/xenwiki/XenParavirtOps.html#head-9fb34d1cf597800d371b844568797d4db8587dce

> 
> Trying to run X windows on Linux 3.1.1 Dom0 kernel under Xen 4.1.2
> (built as http://slackbuilds.org/repository/13.37/system/xen/) on
> Slackware 64-13.37. (The next step should be a HVM guest driven through
> a vnc window from Dom0).
> 
> On the same kernel booted natively, all works fine; when booting under
> Xen, Xorg does not start. The (relevant?) error messages that I find in
> Xorg.0.log are
> 
> (WW) System lacks support for changing MTRRs
> (EE) VESA(0): V_BIOS address 0x0 out of range
> 
> (the full diff of the respective Xorg.0.log-s is at
> http://camelot.lf2.cuni.cz/vejvalka/posts/xlog-diff)
> 
> What is it that I am missing ?

>From a first glance it looks as if the KMS drivers hadn't been loaded -
but I don't know which ones (since I don't know what drivers you have).

> Thanks for any hint,
> 
> Jan
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 15:44:18 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 15:44:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbZx5-0003vr-Dc; Fri, 16 Dec 2011 15:44:03 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1RbZx4-0003vk-4d
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 15:44:02 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1324050129!56490610!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDc2NTY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6298 invoked from network); 16 Dec 2011 15:42:10 -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;
	16 Dec 2011 15:42:10 -0000
X-IronPort-AV: E=Sophos;i="4.71,363,1320642000"; d="scan'208";a="20044593"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Dec 2011 10:43:59 -0500
Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX01.citrite.net
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Fri, 16 Dec 2011
	10:43:59 -0500
Message-ID: <4EEB673D.3040608@citrix.com>
Date: Fri, 16 Dec 2011 15:43:57 +0000
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20111110 Icedove/3.0.11
MIME-Version: 1.0
To: Catalin Marinas <catalin.marinas@arm.com>
References: <alpine.DEB.2.00.1111281009090.31179@kaball-desktop>	<201111292129.20444.arnd@arndb.de>	<alpine.DEB.2.00.1111301053300.31179@kaball-desktop>
	<CAHkRjk48jHO19H04rf8252+v04hk9qSdKBrfYCqJsZyamVhMEw@mail.gmail.com>
In-Reply-To: <CAHkRjk48jHO19H04rf8252+v04hk9qSdKBrfYCqJsZyamVhMEw@mail.gmail.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>, Arnd Bergmann <arnd@arndb.de>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [ANNOUNCE] Xen port to Cortex-A15 / ARMv7 with virt
 extensions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 30/11/11 14:11, Catalin Marinas wrote:
> On 30 November 2011 11:39, Stefano Stabellini
> <stefano.stabellini@eu.citrix.com> wrote:
>> A git branch is available here (not ready for submission):
>>
>> git://xenbits.xen.org/people/sstabellini/linux-pvhvm.git arm
>>
>> the branch above is based on git://linux-arm.org/linux-2.6.git arm-lpae,
>> even though guests don't really need lpae support to run on Xen.
> 
> Indeed, you don't really need LPAE. What you may need though is
> generic timers support for A15, it would allow less Hypervisor traps.
> For up-to-date architecture patches (well, development tree, not
> guaranteed to be stable), I would recommend this (they get into
> mainline at some point):
> 
> http://git.kernel.org/?p=linux/kernel/git/cmarinas/linux-arm-arch.git;a=summary
> 
> Either use master or just cherry-pick the branches that you are interested in.

Hi Catalin,

Which branches are required for the Versatile Express with the
Cortex-A15? I merged linux-arm-arch/arm-arch/vexpress in but I get a
instruction fault immediately after branching to __mmap_switched.

Is it not setting up the MMU correctly?

David


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 15:44:18 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 15:44:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbZx5-0003vr-Dc; Fri, 16 Dec 2011 15:44:03 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1RbZx4-0003vk-4d
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 15:44:02 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1324050129!56490610!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDc2NTY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6298 invoked from network); 16 Dec 2011 15:42:10 -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;
	16 Dec 2011 15:42:10 -0000
X-IronPort-AV: E=Sophos;i="4.71,363,1320642000"; d="scan'208";a="20044593"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Dec 2011 10:43:59 -0500
Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX01.citrite.net
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Fri, 16 Dec 2011
	10:43:59 -0500
Message-ID: <4EEB673D.3040608@citrix.com>
Date: Fri, 16 Dec 2011 15:43:57 +0000
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20111110 Icedove/3.0.11
MIME-Version: 1.0
To: Catalin Marinas <catalin.marinas@arm.com>
References: <alpine.DEB.2.00.1111281009090.31179@kaball-desktop>	<201111292129.20444.arnd@arndb.de>	<alpine.DEB.2.00.1111301053300.31179@kaball-desktop>
	<CAHkRjk48jHO19H04rf8252+v04hk9qSdKBrfYCqJsZyamVhMEw@mail.gmail.com>
In-Reply-To: <CAHkRjk48jHO19H04rf8252+v04hk9qSdKBrfYCqJsZyamVhMEw@mail.gmail.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>, Arnd Bergmann <arnd@arndb.de>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [ANNOUNCE] Xen port to Cortex-A15 / ARMv7 with virt
 extensions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 30/11/11 14:11, Catalin Marinas wrote:
> On 30 November 2011 11:39, Stefano Stabellini
> <stefano.stabellini@eu.citrix.com> wrote:
>> A git branch is available here (not ready for submission):
>>
>> git://xenbits.xen.org/people/sstabellini/linux-pvhvm.git arm
>>
>> the branch above is based on git://linux-arm.org/linux-2.6.git arm-lpae,
>> even though guests don't really need lpae support to run on Xen.
> 
> Indeed, you don't really need LPAE. What you may need though is
> generic timers support for A15, it would allow less Hypervisor traps.
> For up-to-date architecture patches (well, development tree, not
> guaranteed to be stable), I would recommend this (they get into
> mainline at some point):
> 
> http://git.kernel.org/?p=linux/kernel/git/cmarinas/linux-arm-arch.git;a=summary
> 
> Either use master or just cherry-pick the branches that you are interested in.

Hi Catalin,

Which branches are required for the Versatile Express with the
Cortex-A15? I merged linux-arm-arch/arm-arch/vexpress in but I get a
instruction fault immediately after branching to __mmap_switched.

Is it not setting up the MMU correctly?

David


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 15:47:24 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 15:47:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbZzz-00042V-4W; Fri, 16 Dec 2011 15:47:03 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RbZzx-00042J-JR
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 15:47:02 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1324050414!8153034!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ0MzA3NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5202 invoked from network); 16 Dec 2011 15:46:55 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-11.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Dec 2011 15:46:55 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pBGFknSB016457
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 16 Dec 2011 15:46:50 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pBGFkmPY018335
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 16 Dec 2011 15:46:49 GMT
Received: from abhmt103.oracle.com (abhmt103.oracle.com [141.146.116.55])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pBGFkmEP012102; Fri, 16 Dec 2011 09:46:48 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 16 Dec 2011 07:46:48 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id BA92B4018D; Fri, 16 Dec 2011 10:45:54 -0500 (EST)
Date: Fri, 16 Dec 2011 10:45:54 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "Taylor, Neal E" <Neal.Taylor@ca.com>
Message-ID: <20111216154554.GG31755@phenom.dumpdata.com>
References: <13239908451694@kroah.org>
	<3E243B26F475504B9BB0BCC9728B0DA629E1AC69@USILMS110A.ca.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <3E243B26F475504B9BB0BCC9728B0DA629E1AC69@USILMS110A.ca.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090202.4EEB67EA.012A,ss=1,re=0.000,fgs=0
Cc: "gregkh@suse.de" <gregkh@suse.de>, "Kalev, Leonid" <Leonid.Kalev@ca.com>,
	xen-devel <xen-devel@lists.xensource.com>,
	"stable@vger.kernel.org" <stable@vger.kernel.org>
Subject: Re: [Xen-devel] patch "[PATCH] xen/swiotlb: Use page alignment for
 early buffer allocation." failed to apply to 3.1-stable tree
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Dec 16, 2011 at 12:58:55AM +0000, Taylor, Neal E wrote:
> Konrad,
> 
> This patch applies and compiles on 3.1.5 and 3.0.4. I'll test tomorrow.

OK. I've tested it on 3.1.5 and 3.0.6 as well. If I recall you mentioned
that you had tested the 3.0.4 + this patch yesterday (thought you
probably had tons of debugging patches too). Is that you are testing a clean
version of 3.0.4 with this patch? Or are you testing both trees on your box?

Thanks!
> 
> Neal
> 
> diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
> index 8e964b9..5c8e445 100644
> --- a/drivers/xen/swiotlb-xen.c
> +++ b/drivers/xen/swiotlb-xen.c
> @@ -166,7 +166,8 @@ retry:
>         /*
>          * Get IO TLB memory from any location.
>          */
> -       xen_io_tlb_start = alloc_bootmem(bytes);
> +       xen_io_tlb_start = alloc_bootmem_pages(PAGE_ALIGN(bytes));
> +
>         if (!xen_io_tlb_start)
>                 panic("Cannot allocate SWIOTLB buffer");
> 
> -----Original Message-----
> From: gregkh@suse.de [mailto:gregkh@suse.de] 
> Sent: Thursday, December 15, 2011 3:14 PM
> To: konrad.wilk@oracle.com; Kalev, Leonid; Taylor, Neal E
> Cc: stable@vger.kernel.org
> Subject: patch "[PATCH] xen/swiotlb: Use page alignment for early buffer allocation." failed to apply to 3.1-stable tree
> 
> 
> The patch below does not apply to the 3.1-stable tree.
> If someone wants it applied there, or to any other stable or longterm
> tree, then please email the backport, including the original git commit
> id to <stable@vger.kernel.org>.
> 
> thanks,
> 
> greg k-h
> 
> ------------------ original commit in Linus's tree ------------------
> 
> >From 63a741757d15320a25ebf5778f8651cce2ed0611 Mon Sep 17 00:00:00 2001
> From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> Date: Thu, 15 Dec 2011 11:28:46 -0500
> Subject: [PATCH] xen/swiotlb: Use page alignment for early buffer allocation.
> 
> This fixes an odd bug found on a Dell PowerEdge 1850/0RC130
> (BIOS A05 01/09/2006) where all of the modules doing pci_set_dma_mask
> would fail with:
> 
> ata_piix 0000:00:1f.1: enabling device (0005 -> 0007)
> ata_piix 0000:00:1f.1: can't derive routing for PCI INT A
> ata_piix 0000:00:1f.1: BMDMA: failed to set dma mask, falling back to PIO
> 
> The issue was the Xen-SWIOTLB was allocated such as that the end of
> buffer was stradling a page (and also above 4GB). The fix was
> spotted by Kalev Leonid  which was to piggyback on git commit
> e79f86b2ef9c0a8c47225217c1018b7d3d90101c "swiotlb: Use page alignment
> for early buffer allocation" which:
> 
> 	We could call free_bootmem_late() if swiotlb is not used, and
> 	it will shrink to page alignment.
> 
> 	So alloc them with page alignment at first, to avoid lose two pages
> 
> And doing that fixes the outstanding issue.
> 
> CC: stable@kernel.org
> Suggested-by: "Kalev, Leonid" <Leonid.Kalev@ca.com>
> Reported-and-Tested-by: "Taylor, Neal E" <Neal.Taylor@ca.com>
> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> 
> diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
> index 8e964b9..284798a 100644
> --- a/drivers/xen/swiotlb-xen.c
> +++ b/drivers/xen/swiotlb-xen.c
> @@ -166,7 +166,7 @@ retry:
>  	/*
>  	 * Get IO TLB memory from any location.
>  	 */
> -	xen_io_tlb_start = alloc_bootmem(bytes);
> +	xen_io_tlb_start = alloc_bootmem_pages(PAGE_ALIGN(bytes));
>  	if (!xen_io_tlb_start) {
>  		m = "Cannot allocate Xen-SWIOTLB buffer!\n";
>  		goto error;
> @@ -179,7 +179,7 @@ retry:
>  			       bytes,
>  			       xen_io_tlb_nslabs);
>  	if (rc) {
> -		free_bootmem(__pa(xen_io_tlb_start), bytes);
> +		free_bootmem(__pa(xen_io_tlb_start), PAGE_ALIGN(bytes));
>  		m = "Failed to get contiguous memory for DMA from Xen!\n"\
>  		    "You either: don't have the permissions, do not have"\
>  		    " enough free memory under 4GB, or the hypervisor memory"\

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 15:47:24 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 15:47:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbZzz-00042V-4W; Fri, 16 Dec 2011 15:47:03 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RbZzx-00042J-JR
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 15:47:02 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1324050414!8153034!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ0MzA3NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5202 invoked from network); 16 Dec 2011 15:46:55 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-11.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Dec 2011 15:46:55 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pBGFknSB016457
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 16 Dec 2011 15:46:50 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pBGFkmPY018335
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 16 Dec 2011 15:46:49 GMT
Received: from abhmt103.oracle.com (abhmt103.oracle.com [141.146.116.55])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pBGFkmEP012102; Fri, 16 Dec 2011 09:46:48 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 16 Dec 2011 07:46:48 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id BA92B4018D; Fri, 16 Dec 2011 10:45:54 -0500 (EST)
Date: Fri, 16 Dec 2011 10:45:54 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "Taylor, Neal E" <Neal.Taylor@ca.com>
Message-ID: <20111216154554.GG31755@phenom.dumpdata.com>
References: <13239908451694@kroah.org>
	<3E243B26F475504B9BB0BCC9728B0DA629E1AC69@USILMS110A.ca.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <3E243B26F475504B9BB0BCC9728B0DA629E1AC69@USILMS110A.ca.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090202.4EEB67EA.012A,ss=1,re=0.000,fgs=0
Cc: "gregkh@suse.de" <gregkh@suse.de>, "Kalev, Leonid" <Leonid.Kalev@ca.com>,
	xen-devel <xen-devel@lists.xensource.com>,
	"stable@vger.kernel.org" <stable@vger.kernel.org>
Subject: Re: [Xen-devel] patch "[PATCH] xen/swiotlb: Use page alignment for
 early buffer allocation." failed to apply to 3.1-stable tree
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Dec 16, 2011 at 12:58:55AM +0000, Taylor, Neal E wrote:
> Konrad,
> 
> This patch applies and compiles on 3.1.5 and 3.0.4. I'll test tomorrow.

OK. I've tested it on 3.1.5 and 3.0.6 as well. If I recall you mentioned
that you had tested the 3.0.4 + this patch yesterday (thought you
probably had tons of debugging patches too). Is that you are testing a clean
version of 3.0.4 with this patch? Or are you testing both trees on your box?

Thanks!
> 
> Neal
> 
> diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
> index 8e964b9..5c8e445 100644
> --- a/drivers/xen/swiotlb-xen.c
> +++ b/drivers/xen/swiotlb-xen.c
> @@ -166,7 +166,8 @@ retry:
>         /*
>          * Get IO TLB memory from any location.
>          */
> -       xen_io_tlb_start = alloc_bootmem(bytes);
> +       xen_io_tlb_start = alloc_bootmem_pages(PAGE_ALIGN(bytes));
> +
>         if (!xen_io_tlb_start)
>                 panic("Cannot allocate SWIOTLB buffer");
> 
> -----Original Message-----
> From: gregkh@suse.de [mailto:gregkh@suse.de] 
> Sent: Thursday, December 15, 2011 3:14 PM
> To: konrad.wilk@oracle.com; Kalev, Leonid; Taylor, Neal E
> Cc: stable@vger.kernel.org
> Subject: patch "[PATCH] xen/swiotlb: Use page alignment for early buffer allocation." failed to apply to 3.1-stable tree
> 
> 
> The patch below does not apply to the 3.1-stable tree.
> If someone wants it applied there, or to any other stable or longterm
> tree, then please email the backport, including the original git commit
> id to <stable@vger.kernel.org>.
> 
> thanks,
> 
> greg k-h
> 
> ------------------ original commit in Linus's tree ------------------
> 
> >From 63a741757d15320a25ebf5778f8651cce2ed0611 Mon Sep 17 00:00:00 2001
> From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> Date: Thu, 15 Dec 2011 11:28:46 -0500
> Subject: [PATCH] xen/swiotlb: Use page alignment for early buffer allocation.
> 
> This fixes an odd bug found on a Dell PowerEdge 1850/0RC130
> (BIOS A05 01/09/2006) where all of the modules doing pci_set_dma_mask
> would fail with:
> 
> ata_piix 0000:00:1f.1: enabling device (0005 -> 0007)
> ata_piix 0000:00:1f.1: can't derive routing for PCI INT A
> ata_piix 0000:00:1f.1: BMDMA: failed to set dma mask, falling back to PIO
> 
> The issue was the Xen-SWIOTLB was allocated such as that the end of
> buffer was stradling a page (and also above 4GB). The fix was
> spotted by Kalev Leonid  which was to piggyback on git commit
> e79f86b2ef9c0a8c47225217c1018b7d3d90101c "swiotlb: Use page alignment
> for early buffer allocation" which:
> 
> 	We could call free_bootmem_late() if swiotlb is not used, and
> 	it will shrink to page alignment.
> 
> 	So alloc them with page alignment at first, to avoid lose two pages
> 
> And doing that fixes the outstanding issue.
> 
> CC: stable@kernel.org
> Suggested-by: "Kalev, Leonid" <Leonid.Kalev@ca.com>
> Reported-and-Tested-by: "Taylor, Neal E" <Neal.Taylor@ca.com>
> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> 
> diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
> index 8e964b9..284798a 100644
> --- a/drivers/xen/swiotlb-xen.c
> +++ b/drivers/xen/swiotlb-xen.c
> @@ -166,7 +166,7 @@ retry:
>  	/*
>  	 * Get IO TLB memory from any location.
>  	 */
> -	xen_io_tlb_start = alloc_bootmem(bytes);
> +	xen_io_tlb_start = alloc_bootmem_pages(PAGE_ALIGN(bytes));
>  	if (!xen_io_tlb_start) {
>  		m = "Cannot allocate Xen-SWIOTLB buffer!\n";
>  		goto error;
> @@ -179,7 +179,7 @@ retry:
>  			       bytes,
>  			       xen_io_tlb_nslabs);
>  	if (rc) {
> -		free_bootmem(__pa(xen_io_tlb_start), bytes);
> +		free_bootmem(__pa(xen_io_tlb_start), PAGE_ALIGN(bytes));
>  		m = "Failed to get contiguous memory for DMA from Xen!\n"\
>  		    "You either: don't have the permissions, do not have"\
>  		    " enough free memory under 4GB, or the hypervisor memory"\

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 15:58:57 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 15:58:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbaB7-0004GC-Bb; Fri, 16 Dec 2011 15:58:33 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1RbaB6-0004G7-IH
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 15:58:32 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1324051076!45202023!1
X-Originating-IP: [209.85.161.171]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20691 invoked from network); 16 Dec 2011 15:57:57 -0000
Received: from mail-gx0-f171.google.com (HELO mail-gx0-f171.google.com)
	(209.85.161.171)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Dec 2011 15:57:57 -0000
Received: by ggnh4 with SMTP id h4so12187163ggn.30
	for <xen-devel@lists.xensource.com>;
	Fri, 16 Dec 2011 07:58:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=R5um9ln7qvSTm8zv7btz8n0xwtxvkae+2N3QtxZudOY=;
	b=WDt3VjRgrune/fbH1V2ub52q4R//YjkV/9TWVcSHomOZC5jOCAvd4H8P4g1/qDfmUL
	prmpEwgYG9pclWA5GlzXKoaG3c9p3hLu6Isix31JznmGwkmvfiMRkBE9il3gq7JQq5ll
	+5RLjZQZsm1DIQiqCNdbzwviHZwd2IcNQdFDs=
MIME-Version: 1.0
Received: by 10.50.169.71 with SMTP id ac7mr9184366igc.18.1324051106778; Fri,
	16 Dec 2011 07:58:26 -0800 (PST)
Received: by 10.231.146.21 with HTTP; Fri, 16 Dec 2011 07:58:26 -0800 (PST)
In-Reply-To: <676b608e.2fb26.13447553671.Coremail.gbtux@126.com>
References: <26c93838.3b3fb.13445de0e67.Coremail.gbtux@126.com>
	<CAFLBxZYM-8vEc5Egmv+iXqMDUE_UJcgHbwr7=71H-kFowTzXWA@mail.gmail.com>
	<676b608e.2fb26.13447553671.Coremail.gbtux@126.com>
Date: Fri, 16 Dec 2011 15:58:26 +0000
X-Google-Sender-Auth: J8JSnD5txv38G1Mdcfy58YysV7g
Message-ID: <CAFLBxZaBiwEvz-dgPzgBQQTj2xMi8m+QnZ3M+uoqw4AKmb0ZvA@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: gavin <gbtux@126.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] A question on the credit scheduler
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

2011/12/16 gavin <gbtux@126.com>:
> At=A02011-12-16=A019:04:19,"George=A0Dunlap"=A0<George.Dunlap@eu.citrix.c=
om>=A0wrote:
>
>>2011/12/16=A0zhikai=A0<gbtux@126.com>:
>>>=A0Hi=A0All,
>>>
>>>=A0In=A0the=A0credit=A0scheduler,=A0the=A0scheduling=A0decision=A0functi=
on=A0csched_schedule()
>>>=A0is=A0called=A0in=A0the=A0schedule=A0function=A0in=A0scheduler.c,=A0su=
ch=A0as=A0the=A0following.
>>>=A0next_slice=A0=3D=A0sched->do_schedule(sched,=A0now,=A0tasklet_work_sc=
heduled);
>>>
>>>=A0But,=A0how=A0often=A0the=A0csched_schedule()=A0is=A0called=A0and=A0to=
=A0run?=A0Does=A0this
>>>=A0frequency=A0have=A0something=A0to=A0do=A0with=A0the=A0slice=A0of=A0cr=
edit=A0scheduler=A0that=A0is
>>>=A030ms?
>>
>>The=A0scheduler=A0runs=A0whenever=A0the=A0SCHEDULE_SOFTIRQ=A0is=A0raised.=
=A0=A0If=A0you
>>grep=A0through=A0the=A0source=A0code=A0fro=A0that=A0string,=A0you=A0can=
=A0find=A0all=A0the
>>places=A0where=A0it's=A0raised.
>>
>>Some=A0examples=A0include:
>>*=A0When=A0the=A030ms=A0timeslice=A0is=A0finished
>>*=A0When=A0a=A0sleeping=A0vcpu=A0of=A0higher=A0priority=A0than=A0what's=
=A0currently=A0running=A0wakes=A0up
>>*=A0When=A0a=A0vcpu=A0blocks
>>*=A0When=A0a=A0vcpu=A0is=A0migrated=A0from=A0one=A0cpu=A0to=A0another
>>
>>30ms=A0is=A0actually=A0a=A0pretty=A0long=A0time;=A0in=A0typical=A0workloa=
ds,=A0vcpus=A0block
>>or=A0are=A0preempted=A0by=A0other=A0waking=A0vcpus=A0without=A0using=A0up=
=A0their=A0full
>>timeslice.
>
> Thank you very much for your reply.
>
> So, the vcpu is very likely to be preempted whenever the SCHEDULE_SOFTIRQ=
=A0is
> raised.

It depends; if you have a cpu-burning vcpu running on a cpu all by
itself, then after its 30ms timeslice, Xen will have no one else to
run, and so will let it run again.

But yes, if there are other vcpus on the runqueue, or the host is
moderately busy, it's likely that SCHEDULE_SOFTIRQ will cause a
context-switch.

> And we cannot find a small timeslice, such as a(ms), which makes the
> time any vcpu spending on=A0running phase is k*a(ms), k is integer here. =
There
> is no such a small timeslice. Is it right?

I'm sorry, I don't really understand your question.  Perhaps if you
told me what you're trying to accomplish?

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 15:58:57 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 15:58:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbaB7-0004GC-Bb; Fri, 16 Dec 2011 15:58:33 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1RbaB6-0004G7-IH
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 15:58:32 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1324051076!45202023!1
X-Originating-IP: [209.85.161.171]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20691 invoked from network); 16 Dec 2011 15:57:57 -0000
Received: from mail-gx0-f171.google.com (HELO mail-gx0-f171.google.com)
	(209.85.161.171)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Dec 2011 15:57:57 -0000
Received: by ggnh4 with SMTP id h4so12187163ggn.30
	for <xen-devel@lists.xensource.com>;
	Fri, 16 Dec 2011 07:58:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=R5um9ln7qvSTm8zv7btz8n0xwtxvkae+2N3QtxZudOY=;
	b=WDt3VjRgrune/fbH1V2ub52q4R//YjkV/9TWVcSHomOZC5jOCAvd4H8P4g1/qDfmUL
	prmpEwgYG9pclWA5GlzXKoaG3c9p3hLu6Isix31JznmGwkmvfiMRkBE9il3gq7JQq5ll
	+5RLjZQZsm1DIQiqCNdbzwviHZwd2IcNQdFDs=
MIME-Version: 1.0
Received: by 10.50.169.71 with SMTP id ac7mr9184366igc.18.1324051106778; Fri,
	16 Dec 2011 07:58:26 -0800 (PST)
Received: by 10.231.146.21 with HTTP; Fri, 16 Dec 2011 07:58:26 -0800 (PST)
In-Reply-To: <676b608e.2fb26.13447553671.Coremail.gbtux@126.com>
References: <26c93838.3b3fb.13445de0e67.Coremail.gbtux@126.com>
	<CAFLBxZYM-8vEc5Egmv+iXqMDUE_UJcgHbwr7=71H-kFowTzXWA@mail.gmail.com>
	<676b608e.2fb26.13447553671.Coremail.gbtux@126.com>
Date: Fri, 16 Dec 2011 15:58:26 +0000
X-Google-Sender-Auth: J8JSnD5txv38G1Mdcfy58YysV7g
Message-ID: <CAFLBxZaBiwEvz-dgPzgBQQTj2xMi8m+QnZ3M+uoqw4AKmb0ZvA@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: gavin <gbtux@126.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] A question on the credit scheduler
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

2011/12/16 gavin <gbtux@126.com>:
> At=A02011-12-16=A019:04:19,"George=A0Dunlap"=A0<George.Dunlap@eu.citrix.c=
om>=A0wrote:
>
>>2011/12/16=A0zhikai=A0<gbtux@126.com>:
>>>=A0Hi=A0All,
>>>
>>>=A0In=A0the=A0credit=A0scheduler,=A0the=A0scheduling=A0decision=A0functi=
on=A0csched_schedule()
>>>=A0is=A0called=A0in=A0the=A0schedule=A0function=A0in=A0scheduler.c,=A0su=
ch=A0as=A0the=A0following.
>>>=A0next_slice=A0=3D=A0sched->do_schedule(sched,=A0now,=A0tasklet_work_sc=
heduled);
>>>
>>>=A0But,=A0how=A0often=A0the=A0csched_schedule()=A0is=A0called=A0and=A0to=
=A0run?=A0Does=A0this
>>>=A0frequency=A0have=A0something=A0to=A0do=A0with=A0the=A0slice=A0of=A0cr=
edit=A0scheduler=A0that=A0is
>>>=A030ms?
>>
>>The=A0scheduler=A0runs=A0whenever=A0the=A0SCHEDULE_SOFTIRQ=A0is=A0raised.=
=A0=A0If=A0you
>>grep=A0through=A0the=A0source=A0code=A0fro=A0that=A0string,=A0you=A0can=
=A0find=A0all=A0the
>>places=A0where=A0it's=A0raised.
>>
>>Some=A0examples=A0include:
>>*=A0When=A0the=A030ms=A0timeslice=A0is=A0finished
>>*=A0When=A0a=A0sleeping=A0vcpu=A0of=A0higher=A0priority=A0than=A0what's=
=A0currently=A0running=A0wakes=A0up
>>*=A0When=A0a=A0vcpu=A0blocks
>>*=A0When=A0a=A0vcpu=A0is=A0migrated=A0from=A0one=A0cpu=A0to=A0another
>>
>>30ms=A0is=A0actually=A0a=A0pretty=A0long=A0time;=A0in=A0typical=A0workloa=
ds,=A0vcpus=A0block
>>or=A0are=A0preempted=A0by=A0other=A0waking=A0vcpus=A0without=A0using=A0up=
=A0their=A0full
>>timeslice.
>
> Thank you very much for your reply.
>
> So, the vcpu is very likely to be preempted whenever the SCHEDULE_SOFTIRQ=
=A0is
> raised.

It depends; if you have a cpu-burning vcpu running on a cpu all by
itself, then after its 30ms timeslice, Xen will have no one else to
run, and so will let it run again.

But yes, if there are other vcpus on the runqueue, or the host is
moderately busy, it's likely that SCHEDULE_SOFTIRQ will cause a
context-switch.

> And we cannot find a small timeslice, such as a(ms), which makes the
> time any vcpu spending on=A0running phase is k*a(ms), k is integer here. =
There
> is no such a small timeslice. Is it right?

I'm sorry, I don't really understand your question.  Perhaps if you
told me what you're trying to accomplish?

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 16:02:24 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 16:02:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbaER-0004ne-02; Fri, 16 Dec 2011 16:01:59 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <carsten@schiers.de>) id 1RbaEO-0004nK-O6
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 16:01:57 +0000
X-Env-Sender: carsten@schiers.de
X-Msg-Ref: server-2.tower-216.messagelabs.com!1324051310!9098196!1
X-Originating-IP: [194.117.254.36]
X-SpamReason: No, hits=0.2 required=7.0 tests=FROM_EXCESS_QP, MIME_QP_LONG_LINE
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26546 invoked from network); 16 Dec 2011 16:01:50 -0000
Received: from www.zeus06.de (HELO mail.zeus06.de) (194.117.254.36)
	by server-2.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Dec 2011 16:01:50 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=mail.zeus06.de; h=subject
	:from:to:cc:date:mime-version:content-type:in-reply-to
	:references:message-id; s=beta; bh=VH904Q6YPeUeRztGTyxKc/GC0Lr3s
	3dFdKLSPf5AraU=; b=KQUaWZ73F9dD8PEGj1AXlW/om6TDS+Vb0Dp2V/8EVAq8P
	cKuFQXiXFM4JOR8gSb8hJ1TRV1OzxTWsz7FPftUoqZv3weaa/tG6hvvmRGO6u/xG
	U9gPjwbqM8OSoVLF1ymDdeMPSSOX4qtaGhMljZYxxRc9tqWqEjs0BAW5taNvhA=
Received: (qmail 18271 invoked from network); 16 Dec 2011 17:01:43 +0100
Received: from unknown (HELO uhura.zz) (l3s6271p1@46.59.162.10)
	by mail.zeus06.de with ESMTPA; 16 Dec 2011 17:01:43 +0100
Received: from localhost (localhost [127.0.0.1])
	by uhura.zz (Postfix) with ESMTP id E02B22C525;
	Fri, 16 Dec 2011 16:52:00 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at schiers.de
Received: from uhura.zz ([127.0.0.1])
	by localhost (uhura.space.zz [127.0.0.1]) (amavisd-new, port 10024)
	with LMTP id OaPos0cw3+ug; Fri, 16 Dec 2011 16:51:47 +0100 (CET)
Received: from uhura.space.zz (localhost [127.0.0.1])
	by uhura.zz (Postfix) with ESMTP id 57BB42C526;
	Fri, 16 Dec 2011 16:51:47 +0100 (CET)
From: =?utf-8?Q?Carsten_Schiers?= <carsten@schiers.de>
To: =?utf-8?Q?Konrad_Rzeszutek_Wilk?= <konrad.wilk@oracle.com>
Date: Fri, 16 Dec 2011 16:51:47 +0100
Mime-Version: 1.0
Content-Type: multipart/mixed; 
	boundary="=_jASWBVRfAzzjZ2gubxT7JfE4rOPAtg-rILiWQbFgI4tLQ-VX"
In-Reply-To: <20111216150440.GD31755@phenom.dumpdata.com>
References: <20111214220700.GA9926@phenom.dumpdata.com>
X-Priority: 3 (Normal)
X-Mailer: Zarafa 7.0.2-29470
Thread-Index: Acy8CpY10TkQVNhYRXi5GOwMxjBFyQ==
Message-Id: <zarafa.4eeb6913.0870.04527b5d644d76ef@uhura.space.zz>
Cc: =?utf-8?Q?linux=40eikelenboom=2Eit?= <linux@eikelenboom.it>,
	=?utf-8?Q?xen-devel?= <xen-devel@lists.xensource.com>,
	=?utf-8?Q?lersek=40redhat=2Ecom?= <lersek@redhat.com>,
	=?utf-8?Q?zhenzhong=2Eduan=40oracle=2Ecom?= <zhenzhong.duan@oracle.com>,
	=?utf-8?Q?Ian_Campbell?= <ian.campbell@citrix.com>
Subject: Re: [Xen-devel] Load increase after memory upgrade (part2)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a multi-part message in MIME format. Your mail reader does not
understand MIME message format.
--=_jASWBVRfAzzjZ2gubxT7JfE4rOPAtg-rILiWQbFgI4tLQ-VX
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

> And you are using swiotlb=3Dforce on the 2.6.34 classic kernel and passing in your budget-av card in it=3F

Yes, two of them with swiotlb=3D32,force.


> Could you append the dmesg output please=3F

Attached. You find a "normal" boot after the one with the patched kernel.

Carsten.



--=_jASWBVRfAzzjZ2gubxT7JfE4rOPAtg-rILiWQbFgI4tLQ-VX
Content-Type: application/octet-stream; name=dmesg.txt
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=dmesg.txt

RGVjIDE2IDE1OjUzOjExIHJpa2VyIGtlcm5lbDogTGludXggdmVyc2lvbiAyLjYuMzQuNy4x
LXhlbi1hbWQ2NCAocm9vdEBjaGVrb3RleSkgKGdjYyB2ZXJzaW9uIDQuNC41IChEZWJpYW4g
NC40LjUtOCkgKSAjNyBTTVAgRnJpIERlYyAxNiAxMzozNjozMyBDRVQgMjAxMQpEZWMgMTYg
MTU6NTM6MTEgcmlrZXIga2VybmVsOiBDb21tYW5kIGxpbmU6IHJvb3Q9L2Rldi94dmRhMSBy
byBzd2lvdGxiPTMyLGZvcmNlIHhlbmNvbnM9dHR5CkRlYyAxNiAxNTo1MzoxMSByaWtlciBr
ZXJuZWw6IFhlbi1wcm92aWRlZCBwaHlzaWNhbCBSQU0gbWFwOgpEZWMgMTYgMTU6NTM6MTEg
cmlrZXIga2VybmVsOiBYZW46IDAwMDAwMDAwMDAwMDAwMDAgLSAwMDAwMDAwMDE0ODAwMDAw
ICh1c2FibGUpCkRlYyAxNiAxNTo1MzoxMSByaWtlciBrZXJuZWw6IE5YIChFeGVjdXRlIERp
c2FibGUpIHByb3RlY3Rpb246IGFjdGl2ZQpEZWMgMTYgMTU6NTM6MTEgcmlrZXIga2VybmVs
OiBsYXN0X3BmbiA9IDB4MTQ4MDAgbWF4X2FyY2hfcGZuID0gMHg4MDAwMDAwMApEZWMgMTYg
MTU6NTM6MTEgcmlrZXIga2VybmVsOiBpbml0X21lbW9yeV9tYXBwaW5nOiAwMDAwMDAwMDAw
MDAwMDAwLTAwMDAwMDAwMTQ4MDAwMDAKRGVjIDE2IDE1OjUzOjExIHJpa2VyIGtlcm5lbDog
UkFNRElTSzogMDA3ZmIwMDAgLSAwMTAwNjAwMApEZWMgMTYgMTU6NTM6MTEgcmlrZXIga2Vy
bmVsOiBBQ1BJIGluIHVucHJpdmlsZWdlZCBkb21haW4gZGlzYWJsZWQKRGVjIDE2IDE1OjUz
OjExIHJpa2VyIGtlcm5lbDogWm9uZSBQRk4gcmFuZ2VzOgpEZWMgMTYgMTU6NTM6MTEgcmlr
ZXIga2VybmVsOiAgRE1BICAgICAgMHgwMDAwMDAwMCAtPiAweDAwMDAxMDAwCkRlYyAxNiAx
NTo1MzoxMSByaWtlciBrZXJuZWw6ICBETUEzMiAgICAweDAwMDAxMDAwIC0+IDB4MDAxMDAw
MDAKRGVjIDE2IDE1OjUzOjExIHJpa2VyIGtlcm5lbDogIE5vcm1hbCAgIGVtcHR5CkRlYyAx
NiAxNTo1MzoxMSByaWtlciBrZXJuZWw6IE1vdmFibGUgem9uZSBzdGFydCBQRk4gZm9yIGVh
Y2ggbm9kZQpEZWMgMTYgMTU6NTM6MTEgcmlrZXIga2VybmVsOiBlYXJseV9ub2RlX21hcFsy
XSBhY3RpdmUgUEZOIHJhbmdlcwpEZWMgMTYgMTU6NTM6MTEgcmlrZXIga2VybmVsOiAgICAw
OiAweDAwMDAwMDAwIC0+IDB4MDAwMTQwMDAKRGVjIDE2IDE1OjUzOjExIHJpa2VyIGtlcm5l
bDogICAgMDogMHgwMDAxNDgwMCAtPiAweDAwMDE0ODAwCkRlYyAxNiAxNTo1MzoxMSByaWtl
ciBrZXJuZWw6IHNldHVwX3BlcmNwdTogTlJfQ1BVUzozMiBucl9jcHVtYXNrX2JpdHM6MzIg
bnJfY3B1X2lkczoxIG5yX25vZGVfaWRzOjEKRGVjIDE2IDE1OjUzOjExIHJpa2VyIGtlcm5l
bDogUEVSQ1BVOiBFbWJlZGRlZCAxNyBwYWdlcy9jcHUgQGZmZmY4ODAwMDEwMGEwMDAgczM5
NjU2IHI4MTkyIGQyMTc4NCB1Njk2MzIKRGVjIDE2IDE1OjUzOjExIHJpa2VyIGtlcm5lbDog
cGNwdS1hbGxvYzogczM5NjU2IHI4MTkyIGQyMTc4NCB1Njk2MzIgYWxsb2M9MTcqNDA5NgpE
ZWMgMTYgMTU6NTM6MTEgcmlrZXIga2VybmVsOiBwY3B1LWFsbG9jOiBbMF0gMCAKRGVjIDE2
IDE1OjUzOjExIHJpa2VyIGtlcm5lbDogQnVpbHQgMSB6b25lbGlzdHMgaW4gWm9uZSBvcmRl
ciwgbW9iaWxpdHkgZ3JvdXBpbmcgb24uICBUb3RhbCBwYWdlczogODA3NzIKRGVjIDE2IDE1
OjUzOjExIHJpa2VyIGtlcm5lbDogS2VybmVsIGNvbW1hbmQgbGluZTogcm9vdD0vZGV2L3h2
ZGExIHJvIHN3aW90bGI9MzIsZm9yY2UgeGVuY29ucz10dHkKRGVjIDE2IDE1OjUzOjExIHJp
a2VyIGtlcm5lbDogUElEIGhhc2ggdGFibGUgZW50cmllczogMjA0OCAob3JkZXI6IDIsIDE2
Mzg0IGJ5dGVzKQpEZWMgMTYgMTU6NTM6MTEgcmlrZXIga2VybmVsOiBEZW50cnkgY2FjaGUg
aGFzaCB0YWJsZSBlbnRyaWVzOiA2NTUzNiAob3JkZXI6IDcsIDUyNDI4OCBieXRlcykKRGVj
IDE2IDE1OjUzOjExIHJpa2VyIGtlcm5lbDogSW5vZGUtY2FjaGUgaGFzaCB0YWJsZSBlbnRy
aWVzOiAzMjc2OCAob3JkZXI6IDYsIDI2MjE0NCBieXRlcykKRGVjIDE2IDE1OjUzOjExIHJp
a2VyIGtlcm5lbDogU29mdHdhcmUgSU8gVExCIGVuYWJsZWQ6IApEZWMgMTYgMTU6NTM6MTEg
cmlrZXIga2VybmVsOiBBcGVydHVyZTogICAgIDMyIG1lZ2FieXRlcwpEZWMgMTYgMTU6NTM6
MTEgcmlrZXIga2VybmVsOiBBZGRyZXNzIHNpemU6IDI4IGJpdHMKRGVjIDE2IDE1OjUzOjEx
IHJpa2VyIGtlcm5lbDogS2VybmVsIHJhbmdlOiBmZmZmODgwMDAxNmMzMDAwIC0gZmZmZjg4
MDAwMzZjMzAwMApEZWMgMTYgMTU6NTM6MTEgcmlrZXIga2VybmVsOiBQQ0ktRE1BOiBVc2lu
ZyBzb2Z0d2FyZSBib3VuY2UgYnVmZmVyaW5nIGZvciBJTyAoU1dJT1RMQikKRGVjIDE2IDE1
OjUzOjExIHJpa2VyIGtlcm5lbDogU3VidHJhY3QgKDM1IGVhcmx5IHJlc2VydmF0aW9ucykK
RGVjIDE2IDE1OjUzOjExIHJpa2VyIGtlcm5lbDogICMxIFswMDAwN2ZiMDAwIC0gMDAwMTAw
NjAwMF0gICAgWGVuIHByb3ZpZGVkCkRlYyAxNiAxNTo1MzoxMSByaWtlciBrZXJuZWw6ICAj
MiBbMDAwMDIwMDAwMCAtIDAwMDA3ZGFhOTRdICAgVEVYVCBEQVRBIEJTUwpEZWMgMTYgMTU6
NTM6MTEgcmlrZXIga2VybmVsOiAgIzMgWzAwMDEwYjYwMDAgLSAwMDAxMTVjMDAwXSAgICAg
ICAgIFBHVEFCTEUKRGVjIDE2IDE1OjUzOjExIHJpa2VyIGtlcm5lbDogICM0IFswMDE0MDAw
MDAwIC0gMDAxNDgwMDAwMF0gICAgICAgICBCQUxMT09OCkRlYyAxNiAxNTo1MzoxMSByaWtl
ciBrZXJuZWw6ICAjNSBbMDAwMTE1YzAwMCAtIDAwMDE1ZDgwMDBdICAgICAgICAgQk9PVE1F
TQpEZWMgMTYgMTU6NTM6MTEgcmlrZXIga2VybmVsOiAgIzYgWzAwMDE1ZDgwMDAgLSAwMDAx
NWQ4MDA4XSAgICAgICAgIEJPT1RNRU0KRGVjIDE2IDE1OjUzOjExIHJpa2VyIGtlcm5lbDog
ICM3IFswMDAxNWQ4MDQwIC0gMDAwMTVkODFjMF0gICAgICAgICBCT09UTUVNCkRlYyAxNiAx
NTo1MzoxMSByaWtlciBrZXJuZWw6ICAjOCBbMDAwMTVkODFjMCAtIDAwMDE1ZDgxZTBdICAg
ICAgICAgQk9PVE1FTQpEZWMgMTYgMTU6NTM6MTEgcmlrZXIga2VybmVsOiAgIzkgWzAwMDE1
ZDgyMDAgLSAwMDAxNWRiMjAwXSAgICAgICAgIEJPT1RNRU0KRGVjIDE2IDE1OjUzOjExIHJp
a2VyIGtlcm5lbDogICMxMCBbMDAwMTVkYzAwMCAtIDAwMDE1ZGQwMDBdICAgICAgICAgQk9P
VE1FTQpEZWMgMTYgMTU6NTM6MTEgcmlrZXIga2VybmVsOiAgIzExIFswMDAxNWRkMDAwIC0g
MDAwMTVkZTAwMF0gICAgICAgICBCT09UTUVNCkRlYyAxNiAxNTo1MzoxMSByaWtlciBrZXJu
ZWw6ICAjMTIgWzAwMDE1ZGUwMDAgLSAwMDAxNWRmMDAwXSAgICAgICAgIEJPT1RNRU0KRGVj
IDE2IDE1OjUzOjExIHJpa2VyIGtlcm5lbDogICMxMyBbMDAwMTVkZjAwMCAtIDAwMDE2ODMw
MDBdICAgICAgICAgQk9PVE1FTQpEZWMgMTYgMTU6NTM6MTEgcmlrZXIga2VybmVsOiAgIzE0
IFswMDAxMGE2MDAwIC0gMDAwMTBiNjAwMF0gICAgWGVuIHByb3ZpZGVkCkRlYyAxNiAxNTo1
MzoxMSByaWtlciBrZXJuZWw6ICAjMTUgWzAwMDEwMDYwMDAgLSAwMDAxMDA2MDEwXSAgICAg
ICAgIEJPT1RNRU0KRGVjIDE2IDE1OjUzOjExIHJpa2VyIGtlcm5lbDogICMxNiBbMDAwMTAw
NjA0MCAtIDAwMDEwMDYwNDhdICAgICAgICAgQk9PVE1FTQpEZWMgMTYgMTU6NTM6MTEgcmlr
ZXIga2VybmVsOiAgIzE3IFswMDAxMDA3MDAwIC0gMDAwMTAwODAwMF0gICAgICAgICBCT09U
TUVNCkRlYyAxNiAxNTo1MzoxMSByaWtlciBrZXJuZWw6ICAjMTggWzAwMDEwMDYwODAgLSAw
MDAxMDA2MGIwXSAgICAgICAgIEJPT1RNRU0KRGVjIDE2IDE1OjUzOjExIHJpa2VyIGtlcm5l
bDogICMxOSBbMDAwMTAwNjBjMCAtIDAwMDEwMDYwZjBdICAgICAgICAgQk9PVE1FTQpEZWMg
MTYgMTU6NTM6MTEgcmlrZXIga2VybmVsOiAgIzIwIFswMDAxMDBhMDAwIC0gMDAwMTAxYjAw
MF0gICAgICAgICBCT09UTUVNCkRlYyAxNiAxNTo1MzoxMSByaWtlciBrZXJuZWw6ICAjMjEg
WzAwMDEwMDYxMDAgLSAwMDAxMDA2MTA4XSAgICAgICAgIEJPT1RNRU0KRGVjIDE2IDE1OjUz
OjExIHJpa2VyIGtlcm5lbDogICMyMiBbMDAwMTAwNjE0MCAtIDAwMDEwMDYxNDhdICAgICAg
ICAgQk9PVE1FTQpEZWMgMTYgMTU6NTM6MTEgcmlrZXIga2VybmVsOiAgIzIzIFswMDAxMDA2
MTgwIC0gMDAwMTAwNjE4NF0gICAgICAgICBCT09UTUVNCkRlYyAxNiAxNTo1MzoxMSByaWtl
ciBrZXJuZWw6ICAjMjQgWzAwMDEwMDYxYzAgLSAwMDAxMDA2MWM4XSAgICAgICAgIEJPT1RN
RU0KRGVjIDE2IDE1OjUzOjExIHJpa2VyIGtlcm5lbDogICMyNSBbMDAwMTAwNjIwMCAtIDAw
MDEwMDYzMDBdICAgICAgICAgQk9PVE1FTQpEZWMgMTYgMTU6NTM6MTEgcmlrZXIga2VybmVs
OiAgIzI2IFswMDAxMDA2MzAwIC0gMDAwMTAwNjM0OF0gICAgICAgICBCT09UTUVNCkRlYyAx
NiAxNTo1MzoxMSByaWtlciBrZXJuZWw6ICAjMjcgWzAwMDEwMDYzODAgLSAwMDAxMDA2M2M4
XSAgICAgICAgIEJPT1RNRU0KRGVjIDE2IDE1OjUzOjExIHJpa2VyIGtlcm5lbDogICMyOCBb
MDAwMTAxYjAwMCAtIDAwMDEwMWYwMDBdICAgICAgICAgQk9PVE1FTQpEZWMgMTYgMTU6NTM6
MTEgcmlrZXIga2VybmVsOiAgIzI5IFswMDAxMDFmMDAwIC0gMDAwMTA5ZjAwMF0gICAgICAg
ICBCT09UTUVNCkRlYyAxNiAxNTo1MzoxMSByaWtlciBrZXJuZWw6ICAjMzAgWzAwMDE2ODMw
MDAgLSAwMDAxNmMzMDAwXSAgICAgICAgIEJPT1RNRU0KRGVjIDE2IDE1OjUzOjExIHJpa2Vy
IGtlcm5lbDogICMzMSBbMDAwMTZjMzAwMCAtIDAwMDM2YzMwMDBdICAgICAgICAgQk9PVE1F
TQpEZWMgMTYgMTU6NTM6MTEgcmlrZXIga2VybmVsOiAgIzMyIFswMDAzNmMzMDAwIC0gMDAw
MzZkMzAwMF0gICAgICAgICBCT09UTUVNCkRlYyAxNiAxNTo1MzoxMSByaWtlciBrZXJuZWw6
ICAjMzMgWzAwMDM2ZDMwMDAgLSAwMDAzNmYzMDAwXSAgICAgICAgIEJPT1RNRU0KRGVjIDE2
IDE1OjUzOjExIHJpa2VyIGtlcm5lbDogICMzNCBbMDAwMzZmMzAwMCAtIDAwMDM2ZmIwMDBd
ICAgICAgICAgQk9PVE1FTQpEZWMgMTYgMTU6NTM6MTEgcmlrZXIga2VybmVsOiBNZW1vcnk6
IDI3MzU5MmsvMzM1ODcyayBhdmFpbGFibGUgKDMyMjlrIGtlcm5lbCBjb2RlLCA4MTkyayBh
YnNlbnQsIDU0MDg4ayByZXNlcnZlZCwgMTcyMmsgZGF0YSwgMzIwayBpbml0KQpEZWMgMTYg
MTU6NTM6MTEgcmlrZXIga2VybmVsOiBIaWVyYXJjaGljYWwgUkNVIGltcGxlbWVudGF0aW9u
LgpEZWMgMTYgMTU6NTM6MTEgcmlrZXIga2VybmVsOiBSQ1UtYmFzZWQgZGV0ZWN0aW9uIG9m
IHN0YWxsZWQgQ1BVcyBpcyBlbmFibGVkLgpEZWMgMTYgMTU6NTM6MTEgcmlrZXIga2VybmVs
OiBOUl9JUlFTOjE2MDAKRGVjIDE2IDE1OjUzOjExIHJpa2VyIGtlcm5lbDogWGVuIHJlcG9y
dGVkOiAyMjEwLjAzOCBNSHogcHJvY2Vzc29yLgpEZWMgMTYgMTU6NTM6MTEgcmlrZXIga2Vy
bmVsOiBDb25zb2xlOiBjb2xvdXIgZHVtbXkgZGV2aWNlIDgweDI1CkRlYyAxNiAxNTo1Mzox
MSByaWtlciBrZXJuZWw6IGNvbnNvbGUgW3R0eTBdIGVuYWJsZWQKRGVjIDE2IDE1OjUzOjEx
IHJpa2VyIGtlcm5lbDogY29uc29sZSBbdHR5LTFdIGVuYWJsZWQKRGVjIDE2IDE1OjUzOjEx
IHJpa2VyIGtlcm5lbDogQ2FsaWJyYXRpbmcgZGVsYXkgdXNpbmcgdGltZXIgc3BlY2lmaWMg
cm91dGluZS4uIDQ0NzguNTggQm9nb01JUFMgKGxwaj04OTU3MTczKQpEZWMgMTYgMTU6NTM6
MTEgcmlrZXIga2VybmVsOiBTZWN1cml0eSBGcmFtZXdvcmsgaW5pdGlhbGl6ZWQKRGVjIDE2
IDE1OjUzOjExIHJpa2VyIGtlcm5lbDogU0VMaW51eDogIERpc2FibGVkIGF0IGJvb3QuCkRl
YyAxNiAxNTo1MzoxMSByaWtlciBrZXJuZWw6IE1vdW50LWNhY2hlIGhhc2ggdGFibGUgZW50
cmllczogMjU2CkRlYyAxNiAxNTo1MzoxMSByaWtlciBrZXJuZWw6IFNNUCBhbHRlcm5hdGl2
ZXM6IHN3aXRjaGluZyB0byBVUCBjb2RlCkRlYyAxNiAxNTo1MzoxMSByaWtlciBrZXJuZWw6
IEZyZWVpbmcgU01QIGFsdGVybmF0aXZlczogMzZrIGZyZWVkCkRlYyAxNiAxNTo1MzoxMSBy
aWtlciBrZXJuZWw6IEJyb3VnaHQgdXAgMSBDUFVzCkRlYyAxNiAxNTo1MzoxMSByaWtlciBr
ZXJuZWw6IE5FVDogUmVnaXN0ZXJlZCBwcm90b2NvbCBmYW1pbHkgMTYKRGVjIDE2IDE1OjUz
OjExIHJpa2VyIGtlcm5lbDogQnJvdWdodCB1cCAxIENQVXMKRGVjIDE2IDE1OjUzOjExIHJp
a2VyIGtlcm5lbDogUENJOiBzZXR0aW5nIHVwIFhlbiBQQ0kgZnJvbnRlbmQgc3R1YgpEZWMg
MTYgMTU6NTM6MTEgcmlrZXIga2VybmVsOiBiaW86IGNyZWF0ZSBzbGFiIDxiaW8tMD4gYXQg
MApEZWMgMTYgMTU6NTM6MTEgcmlrZXIga2VybmVsOiBBQ1BJOiBJbnRlcnByZXRlciBkaXNh
YmxlZC4KRGVjIDE2IDE1OjUzOjExIHJpa2VyIGtlcm5lbDogdmdhYXJiOiBsb2FkZWQKRGVj
IDE2IDE1OjUzOjExIHJpa2VyIGtlcm5lbDogeGVuX21lbTogSW5pdGlhbGlzaW5nIGJhbGxv
b24gZHJpdmVyLgpEZWMgMTYgMTU6NTM6MTEgcmlrZXIga2VybmVsOiBTQ1NJIHN1YnN5c3Rl
bSBpbml0aWFsaXplZApEZWMgMTYgMTU6NTM6MTEgcmlrZXIga2VybmVsOiB1c2Jjb3JlOiBy
ZWdpc3RlcmVkIG5ldyBpbnRlcmZhY2UgZHJpdmVyIHVzYmZzCkRlYyAxNiAxNTo1MzoxMSBy
aWtlciBrZXJuZWw6IHVzYmNvcmU6IHJlZ2lzdGVyZWQgbmV3IGludGVyZmFjZSBkcml2ZXIg
aHViCkRlYyAxNiAxNTo1MzoxMSByaWtlciBrZXJuZWw6IHVzYmNvcmU6IHJlZ2lzdGVyZWQg
bmV3IGRldmljZSBkcml2ZXIgdXNiCkRlYyAxNiAxNTo1MzoxMSByaWtlciBrZXJuZWw6IFBD
STogU3lzdGVtIGRvZXMgbm90IHN1cHBvcnQgUENJCkRlYyAxNiAxNTo1MzoxMSByaWtlciBr
ZXJuZWw6IFBDSTogU3lzdGVtIGRvZXMgbm90IHN1cHBvcnQgUENJCkRlYyAxNiAxNTo1Mzox
MSByaWtlciBrZXJuZWw6IE5FVDogUmVnaXN0ZXJlZCBwcm90b2NvbCBmYW1pbHkgOApEZWMg
MTYgMTU6NTM6MTEgcmlrZXIga2VybmVsOiBORVQ6IFJlZ2lzdGVyZWQgcHJvdG9jb2wgZmFt
aWx5IDIwCkRlYyAxNiAxNTo1MzoxMSByaWtlciBrZXJuZWw6IFN3aXRjaGluZyB0byBjbG9j
a3NvdXJjZSB4ZW4KRGVjIDE2IDE1OjUzOjExIHJpa2VyIGtlcm5lbDogcG5wOiBQblAgQUNQ
STogZGlzYWJsZWQKRGVjIDE2IDE1OjUzOjExIHJpa2VyIGtlcm5lbDogTkVUOiBSZWdpc3Rl
cmVkIHByb3RvY29sIGZhbWlseSAyCkRlYyAxNiAxNTo1MzoxMSByaWtlciBrZXJuZWw6IElQ
IHJvdXRlIGNhY2hlIGhhc2ggdGFibGUgZW50cmllczogNDA5NiAob3JkZXI6IDMsIDMyNzY4
IGJ5dGVzKQpEZWMgMTYgMTU6NTM6MTEgcmlrZXIga2VybmVsOiBUQ1AgZXN0YWJsaXNoZWQg
aGFzaCB0YWJsZSBlbnRyaWVzOiAxNjM4NCAob3JkZXI6IDYsIDI2MjE0NCBieXRlcykKRGVj
IDE2IDE1OjUzOjExIHJpa2VyIGtlcm5lbDogVENQIGJpbmQgaGFzaCB0YWJsZSBlbnRyaWVz
OiAxNjM4NCAob3JkZXI6IDYsIDI2MjE0NCBieXRlcykKRGVjIDE2IDE1OjUzOjExIHJpa2Vy
IGtlcm5lbDogVENQOiBIYXNoIHRhYmxlcyBjb25maWd1cmVkIChlc3RhYmxpc2hlZCAxNjM4
NCBiaW5kIDE2Mzg0KQpEZWMgMTYgMTU6NTM6MTEgcmlrZXIga2VybmVsOiBUQ1AgcmVubyBy
ZWdpc3RlcmVkCkRlYyAxNiAxNTo1MzoxMSByaWtlciBrZXJuZWw6IFVEUCBoYXNoIHRhYmxl
IGVudHJpZXM6IDI1NiAob3JkZXI6IDEsIDgxOTIgYnl0ZXMpCkRlYyAxNiAxNTo1MzoxMSBy
aWtlciBrZXJuZWw6IFVEUC1MaXRlIGhhc2ggdGFibGUgZW50cmllczogMjU2IChvcmRlcjog
MSwgODE5MiBieXRlcykKRGVjIDE2IDE1OjUzOjExIHJpa2VyIGtlcm5lbDogTkVUOiBSZWdp
c3RlcmVkIHByb3RvY29sIGZhbWlseSAxCkRlYyAxNiAxNTo1MzoxMSByaWtlciBrZXJuZWw6
IFRyeWluZyB0byB1bnBhY2sgcm9vdGZzIGltYWdlIGFzIGluaXRyYW1mcy4uLgpEZWMgMTYg
MTU6NTM6MTEgcmlrZXIga2VybmVsOiBwY2lmcm9udCBwY2ktMDogSW5zdGFsbGluZyBQQ0kg
ZnJvbnRlbmQKRGVjIDE2IDE1OjUzOjExIHJpa2VyIGtlcm5lbDogcGNpZnJvbnQgcGNpLTA6
IENyZWF0aW5nIFBDSSBGcm9udGVuZCBCdXMgMDAwMDowMApEZWMgMTYgMTU6NTM6MTEgcmlr
ZXIga2VybmVsOiBGcmVlaW5nIGluaXRyZCBtZW1vcnk6IDgyMzZrIGZyZWVkCkRlYyAxNiAx
NTo1MzoxMSByaWtlciBrZXJuZWw6IHBsYXRmb3JtIHJ0Y19jbW9zOiByZWdpc3RlcmVkIHBs
YXRmb3JtIFJUQyBkZXZpY2UgKG5vIFBOUCBkZXZpY2UgZm91bmQpCkRlYyAxNiAxNTo1Mzox
MSByaWtlciBrZXJuZWw6IGF1ZGl0OiBpbml0aWFsaXppbmcgbmV0bGluayBzb2NrZXQgKGRp
c2FibGVkKQpEZWMgMTYgMTU6NTM6MTEgcmlrZXIga2VybmVsOiB0eXBlPTIwMDAgYXVkaXQo
MTMyNDA0NzE4Ni4zMzQ6MSk6IGluaXRpYWxpemVkCkRlYyAxNiAxNTo1MzoxMSByaWtlciBr
ZXJuZWw6IFZGUzogRGlzayBxdW90YXMgZHF1b3RfNi41LjIKRGVjIDE2IDE1OjUzOjExIHJp
a2VyIGtlcm5lbDogRHF1b3QtY2FjaGUgaGFzaCB0YWJsZSBlbnRyaWVzOiA1MTIgKG9yZGVy
IDAsIDQwOTYgYnl0ZXMpCkRlYyAxNiAxNTo1MzoxMSByaWtlciBrZXJuZWw6IE5URlMgZHJp
dmVyIDIuMS4yOSBbRmxhZ3M6IFIvV10uCkRlYyAxNiAxNTo1MzoxMSByaWtlciBrZXJuZWw6
IG1zZ21uaSBoYXMgYmVlbiBzZXQgdG8gNjU2CkRlYyAxNiAxNTo1MzoxMSByaWtlciBrZXJu
ZWw6IGFsZzogTm8gdGVzdCBmb3Igc3Rkcm5nIChrcm5nKQpEZWMgMTYgMTU6NTM6MTEgcmlr
ZXIga2VybmVsOiBCbG9jayBsYXllciBTQ1NJIGdlbmVyaWMgKGJzZykgZHJpdmVyIHZlcnNp
b24gMC40IGxvYWRlZCAobWFqb3IgMjU0KQpEZWMgMTYgMTU6NTM6MTEgcmlrZXIga2VybmVs
OiBpbyBzY2hlZHVsZXIgbm9vcCByZWdpc3RlcmVkCkRlYyAxNiAxNTo1MzoxMSByaWtlciBr
ZXJuZWw6IGlvIHNjaGVkdWxlciBkZWFkbGluZSByZWdpc3RlcmVkCkRlYyAxNiAxNTo1Mzox
MSByaWtlciBrZXJuZWw6IGlvIHNjaGVkdWxlciBjZnEgcmVnaXN0ZXJlZCAoZGVmYXVsdCkK
RGVjIDE2IDE1OjUzOjExIHJpa2VyIGtlcm5lbDogTGludXggYWdwZ2FydCBpbnRlcmZhY2Ug
djAuMTAzCkRlYyAxNiAxNTo1MzoxMSByaWtlciBrZXJuZWw6IGJyZDogbW9kdWxlIGxvYWRl
ZApEZWMgMTYgMTU6NTM6MTEgcmlrZXIga2VybmVsOiBYZW4gdmlydHVhbCBjb25zb2xlIHN1
Y2Nlc3NmdWxseSBpbnN0YWxsZWQgYXMgdHR5MQpEZWMgMTYgMTU6NTM6MTEgcmlrZXIga2Vy
bmVsOiBFdmVudC1jaGFubmVsIGRldmljZSBpbnN0YWxsZWQuCkRlYyAxNiAxNTo1MzoxMSBy
aWtlciBrZXJuZWw6IGJsa3RhcF9kZXZpY2VfaW5pdDogYmxrdGFwIGRldmljZSBtYWpvciAy
NTQKRGVjIDE2IDE1OjUzOjExIHJpa2VyIGtlcm5lbDogYmxrdGFwX3JpbmdfaW5pdDogYmxr
dGFwIHJpbmcgbWFqb3I6IDI1MgpEZWMgMTYgMTU6NTM6MTEgcmlrZXIga2VybmVsOiBuZXRm
cm9udDogSW5pdGlhbGlzaW5nIHZpcnR1YWwgZXRoZXJuZXQgZHJpdmVyLgpEZWMgMTYgMTU6
NTM6MTEgcmlrZXIga2VybmVsOiB4ZW4tdmJkOiByZWdpc3RlcmVkIGJsb2NrIGRldmljZSBt
YWpvciAyMDIKRGVjIDE2IDE1OjUzOjExIHJpa2VyIGtlcm5lbDogYmxrZnJvbnQ6IHh2ZGEx
OiBiYXJyaWVycyBlbmFibGVkCkRlYyAxNiAxNTo1MzoxMSByaWtlciBrZXJuZWw6IGJsa2Zy
b250OiB4dmRhMjogYmFycmllcnMgZW5hYmxlZApEZWMgMTYgMTU6NTM6MTEgcmlrZXIga2Vy
bmVsOiBTZXR0aW5nIGNhcGFjaXR5IHRvIDgzODg2MDgKRGVjIDE2IDE1OjUzOjExIHJpa2Vy
IGtlcm5lbDogeHZkYTE6IGRldGVjdGVkIGNhcGFjaXR5IGNoYW5nZSBmcm9tIDAgdG8gNDI5
NDk2NzI5NgpEZWMgMTYgMTU6NTM6MTEgcmlrZXIga2VybmVsOiBibGtmcm9udDogeHZkYjE6
IGJhcnJpZXJzIGVuYWJsZWQKRGVjIDE2IDE1OjUzOjExIHJpa2VyIGtlcm5lbDogU2V0dGlu
ZyBjYXBhY2l0eSB0byAyMDk3MTUyCkRlYyAxNiAxNTo1MzoxMSByaWtlciBrZXJuZWw6IHh2
ZGEyOiBkZXRlY3RlZCBjYXBhY2l0eSBjaGFuZ2UgZnJvbSAwIHRvIDEwNzM3NDE4MjQKRGVj
IDE2IDE1OjUzOjExIHJpa2VyIGtlcm5lbDogU2V0dGluZyBjYXBhY2l0eSB0byAyOTMwMjcy
MDAyCkRlYyAxNiAxNTo1MzoxMSByaWtlciBrZXJuZWw6IHh2ZGIxOiBkZXRlY3RlZCBjYXBh
Y2l0eSBjaGFuZ2UgZnJvbSAwIHRvIDE1MDAyOTkyNjUwMjQKRGVjIDE2IDE1OjUzOjExIHJp
a2VyIGtlcm5lbDogdXNiY29yZTogcmVnaXN0ZXJlZCBuZXcgaW50ZXJmYWNlIGRyaXZlciB1
c2JiYWNrCkRlYyAxNiAxNTo1MzoxMSByaWtlciBrZXJuZWw6IFBQUCBnZW5lcmljIGRyaXZl
ciB2ZXJzaW9uIDIuNC4yCkRlYyAxNiAxNTo1MzoxMSByaWtlciBrZXJuZWw6IFBOUDogTm8g
UFMvMiBjb250cm9sbGVyIGZvdW5kLiBQcm9iaW5nIHBvcnRzIGRpcmVjdGx5LgpEZWMgMTYg
MTU6NTM6MTEgcmlrZXIga2VybmVsOiBtaWNlOiBQUy8yIG1vdXNlIGRldmljZSBjb21tb24g
Zm9yIGFsbCBtaWNlCkRlYyAxNiAxNTo1MzoxMSByaWtlciBrZXJuZWw6IFRDUCBiaWMgcmVn
aXN0ZXJlZApEZWMgMTYgMTU6NTM6MTEgcmlrZXIga2VybmVsOiBORVQ6IFJlZ2lzdGVyZWQg
cHJvdG9jb2wgZmFtaWx5IDE3CkRlYyAxNiAxNTo1MzoxMSByaWtlciBrZXJuZWw6IFBDSSBJ
TyBtdWx0aXBsZXhlciBkZXZpY2UgaW5zdGFsbGVkLgpEZWMgMTYgMTU6NTM6MTEgcmlrZXIg
a2VybmVsOiBGcmVlaW5nIHVudXNlZCBrZXJuZWwgbWVtb3J5OiAzMjBrIGZyZWVkCkRlYyAx
NiAxNTo1MzoxMSByaWtlciBrZXJuZWw6IGtqb3VybmFsZCBzdGFydGluZy4gIENvbW1pdCBp
bnRlcnZhbCA1IHNlY29uZHMKRGVjIDE2IDE1OjUzOjExIHJpa2VyIGtlcm5lbDogRVhUMy1m
cyAoeHZkYTEpOiBtb3VudGVkIGZpbGVzeXN0ZW0gd2l0aCB3cml0ZWJhY2sgZGF0YSBtb2Rl
CkRlYyAxNiAxNTo1MzoxMSByaWtlciBrZXJuZWw6IHVkZXZbMTc3XTogc3RhcnRpbmcgdmVy
c2lvbiAxNjQKRGVjIDE2IDE1OjUzOjExIHJpa2VyIGtlcm5lbDogTGludXggdmlkZW8gY2Fw
dHVyZSBpbnRlcmZhY2U6IHYyLjAwCkRlYyAxNiAxNTo1MzoxMSByaWtlciBrZXJuZWw6IHNh
YTcxNDY6IHJlZ2lzdGVyIGV4dGVuc2lvbiAnYnVkZ2V0X2F2Jy4KRGVjIDE2IDE1OjUzOjEx
IHJpa2VyIGtlcm5lbDogYnVkZ2V0X2F2IDAwMDA6MDA6MDAuMDogZW5hYmxpbmcgZGV2aWNl
ICgwMDAwIC0+IDAwMDIpCkRlYyAxNiAxNTo1MzoxMSByaWtlciBrZXJuZWw6IElSUSAxNy86
IElSUUZfRElTQUJMRUQgaXMgbm90IGd1YXJhbnRlZWQgb24gc2hhcmVkIElSUXMKRGVjIDE2
IDE1OjUzOjExIHJpa2VyIGtlcm5lbDogc2FhNzE0NjogZm91bmQgc2FhNzE0NiBAIG1lbSBm
ZmZmYzkwMDAwMjQ2MDAwIChyZXZpc2lvbiAxLCBpcnEgMTcpICgweDE4OTQsMHgwMDI4KS4K
RGVjIDE2IDE1OjUzOjExIHJpa2VyIGtlcm5lbDogc2FhNzE0NiAoMCk6IGRtYSBidWZmZXIg
c2l6ZSAxMzQ3NTg0CkRlYyAxNiAxNTo1MzoxMSByaWtlciBrZXJuZWw6IERWQjogcmVnaXN0
ZXJpbmcgbmV3IGFkYXB0ZXIgKEtOQzEgRFZCLUMgTUszKQpEZWMgMTYgMTU6NTM6MTEgcmlr
ZXIga2VybmVsOiBhZGFwdGVyIGZhaWxlZCBNQUMgc2lnbmF0dXJlIGNoZWNrCkRlYyAxNiAx
NTo1MzoxMSByaWtlciBrZXJuZWw6IGVuY29kZWQgTUFDIGZyb20gRUVQUk9NIHdhcyBmZjpm
ZjpmZjpmZjpmZjpmZjpmZjpmZjpmZjpmZjpmZjpmZjpmZjpmZjpmZjpmZjpmZjpmZjpmZjpm
ZgpEZWMgMTYgMTU6NTM6MTEgcmlrZXIga2VybmVsOiBLTkMxLTA6IE1BQyBhZGRyID0gMDA6
MDk6ZDY6NmQ6YjM6MGEKRGVjIDE2IDE1OjUzOjExIHJpa2VyIGtlcm5lbDogRFZCOiByZWdp
c3RlcmluZyBhZGFwdGVyIDAgZnJvbnRlbmQgMCAoUGhpbGlwcyBUREExMDAyMyBEVkItQyku
Li4KRGVjIDE2IDE1OjUzOjExIHJpa2VyIGtlcm5lbDogYnVkZ2V0LWF2OiBjaSBpbnRlcmZh
Y2UgaW5pdGlhbGlzZWQuCkRlYyAxNiAxNTo1MzoxMSByaWtlciBrZXJuZWw6IGJ1ZGdldF9h
diAwMDAwOjAwOjAxLjA6IGVuYWJsaW5nIGRldmljZSAoMDAwMCAtPiAwMDAyKQpEZWMgMTYg
MTU6NTM6MTEgcmlrZXIga2VybmVsOiBJUlEgMTgvOiBJUlFGX0RJU0FCTEVEIGlzIG5vdCBn
dWFyYW50ZWVkIG9uIHNoYXJlZCBJUlFzCkRlYyAxNiAxNTo1MzoxMSByaWtlciBrZXJuZWw6
IHNhYTcxNDY6IGZvdW5kIHNhYTcxNDYgQCBtZW0gZmZmZmM5MDAwMDRkZTAwMCAocmV2aXNp
b24gMSwgaXJxIDE4KSAoMHgxODk0LDB4MDAyYykuCkRlYyAxNiAxNTo1MzoxMSByaWtlciBr
ZXJuZWw6IHNhYTcxNDYgKDEpOiBkbWEgYnVmZmVyIHNpemUgMTM0NzU4NApEZWMgMTYgMTU6
NTM6MTEgcmlrZXIga2VybmVsOiBEVkI6IHJlZ2lzdGVyaW5nIG5ldyBhZGFwdGVyIChTYXRl
bGNvIEVhc3lXYXRjaCBEVkItQyBNSzMpCkRlYyAxNiAxNTo1MzoxMSByaWtlciBrZXJuZWw6
IGFkYXB0ZXIgZmFpbGVkIE1BQyBzaWduYXR1cmUgY2hlY2sKRGVjIDE2IDE1OjUzOjExIHJp
a2VyIGtlcm5lbDogZW5jb2RlZCBNQUMgZnJvbSBFRVBST00gd2FzIGZmOmZmOmZmOmZmOmZm
OmZmOmZmOmZmOmZmOmZmOmZmOmZmOmZmOmZmOmZmOmZmOmZmOmZmOmZmOmZmCkRlYyAxNiAx
NTo1MzoxMSByaWtlciBrZXJuZWw6IEtOQzEtMTogTUFDIGFkZHIgPSAwMDowOTpkNjo2ZDpi
MDozMwpEZWMgMTYgMTU6NTM6MTEgcmlrZXIga2VybmVsOiBEVkI6IHJlZ2lzdGVyaW5nIGFk
YXB0ZXIgMSBmcm9udGVuZCAwIChQaGlsaXBzIFREQTEwMDIzIERWQi1DKS4uLgpEZWMgMTYg
MTU6NTM6MTEgcmlrZXIga2VybmVsOiBidWRnZXQtYXY6IGNpIGludGVyZmFjZSBpbml0aWFs
aXNlZC4KRGVjIDE2IDE1OjUzOjExIHJpa2VyIGtlcm5lbDogQWRkaW5nIDEwNDg1NzJrIHN3
YXAgb24gL2Rldi94dmRhMi4gIFByaW9yaXR5Oi0xIGV4dGVudHM6MSBhY3Jvc3M6MTA0ODU3
MmsgU1MKRGVjIDE2IDE1OjUzOjExIHJpa2VyIGtlcm5lbDogRVhUMy1mcyAoeHZkYTEpOiB3
YXJuaW5nOiBtYXhpbWFsIG1vdW50IGNvdW50IHJlYWNoZWQsIHJ1bm5pbmcgZTJmc2NrIGlz
IHJlY29tbWVuZGVkCkRlYyAxNiAxNTo1MzoxMSByaWtlciBrZXJuZWw6IEVYVDMtZnMgKHh2
ZGExKTogdXNpbmcgaW50ZXJuYWwgam91cm5hbApEZWMgMTYgMTU6NTM6MTEgcmlrZXIga2Vy
bmVsOiBram91cm5hbGQgc3RhcnRpbmcuICBDb21taXQgaW50ZXJ2YWwgNSBzZWNvbmRzCkRl
YyAxNiAxNTo1MzoxMSByaWtlciBrZXJuZWw6IEVYVDMtZnMgKHh2ZGIxKTogd2FybmluZzog
bWF4aW1hbCBtb3VudCBjb3VudCByZWFjaGVkLCBydW5uaW5nIGUyZnNjayBpcyByZWNvbW1l
bmRlZApEZWMgMTYgMTU6NTM6MTEgcmlrZXIga2VybmVsOiBFWFQzLWZzICh4dmRiMSk6IHVz
aW5nIGludGVybmFsIGpvdXJuYWwKRGVjIDE2IDE1OjUzOjExIHJpa2VyIGtlcm5lbDogRVhU
My1mcyAoeHZkYjEpOiBtb3VudGVkIGZpbGVzeXN0ZW0gd2l0aCB3cml0ZWJhY2sgZGF0YSBt
b2RlCkRlYyAxNiAxNTo1MzoxMSByaWtlciBrZXJuZWw6IFJQQzogUmVnaXN0ZXJlZCB1ZHAg
dHJhbnNwb3J0IG1vZHVsZS4KRGVjIDE2IDE1OjUzOjExIHJpa2VyIGtlcm5lbDogUlBDOiBS
ZWdpc3RlcmVkIHRjcCB0cmFuc3BvcnQgbW9kdWxlLgpEZWMgMTYgMTU6NTM6MTEgcmlrZXIg
a2VybmVsOiBSUEM6IFJlZ2lzdGVyZWQgdGNwIE5GU3Y0LjEgYmFja2NoYW5uZWwgdHJhbnNw
b3J0IG1vZHVsZS4KRGVjIDE2IDE1OjUzOjExIHJpa2VyIGtlcm5lbDogSW5zdGFsbGluZyBr
bmZzZCAoY29weXJpZ2h0IChDKSAxOTk2IG9raXJAbW9uYWQuc3diLmRlKS4KRGVjIDE2IDE1
OjUzOjExIHJpa2VyIGtlcm5lbDogTkVUOiBSZWdpc3RlcmVkIHByb3RvY29sIGZhbWlseSAx
MApEZWMgMTYgMTU6NTM6MTEgcmlrZXIga2VybmVsOiBsbzogRGlzYWJsZWQgUHJpdmFjeSBF
eHRlbnNpb25zCkRlYyAxNiAxNTo1MzoxMSByaWtlciBrZXJuZWw6IHN2YzogZmFpbGVkIHRv
IHJlZ2lzdGVyIGxvY2tkdjEgUlBDIHNlcnZpY2UgKGVycm5vIDk3KS4KRGVjIDE2IDE1OjUz
OjExIHJpa2VyIGtlcm5lbDogTkZTRDogVXNpbmcgL3Zhci9saWIvbmZzL3Y0cmVjb3Zlcnkg
YXMgdGhlIE5GU3Y0IHN0YXRlIHJlY292ZXJ5IGRpcmVjdG9yeQpEZWMgMTYgMTU6NTM6MTEg
cmlrZXIga2VybmVsOiBORlNEOiBzdGFydGluZyA5MC1zZWNvbmQgZ3JhY2UgcGVyaW9kCkRl
YyAxNiAxNTo1MzoyOSByaWtlciBrZXJuZWw6IFN0YXJ0aW5nIFNXSU9UTEIgZGVidWcgdGhy
ZWFkLgpEZWMgMTYgMTU6NTM6MjkgcmlrZXIga2VybmVsOiBzd2lvdGxiX3N0YXJ0X3RocmVh
ZDogR28hCkRlYyAxNiAxNTo1MzozNCByaWtlciBrZXJuZWw6IFNXSU9UTEIgaXMgMCUgZnVs
bApEZWMgMTYgMTU6NTM6MzkgcmlrZXIga2VybmVsOiBTV0lPVExCIGlzIDAlIGZ1bGwKRGVj
IDE2IDE1OjUzOjQ0IHJpa2VyIGtlcm5lbDogU1dJT1RMQiBpcyAwJSBmdWxsCkRlYyAxNiAx
NTo1Mzo0OSByaWtlciBrZXJuZWw6IFNXSU9UTEIgaXMgMCUgZnVsbApEZWMgMTYgMTU6NTM6
NTQgcmlrZXIga2VybmVsOiBTV0lPVExCIGlzIDAlIGZ1bGwKRGVjIDE2IDE1OjUzOjU5IHJp
a2VyIGtlcm5lbDogU1dJT1RMQiBpcyAwJSBmdWxsCkRlYyAxNiAxNTo1NDowNCByaWtlciBr
ZXJuZWw6IFNXSU9UTEIgaXMgMCUgZnVsbApEZWMgMTYgMTU6NTQ6MDkgcmlrZXIga2VybmVs
OiBTV0lPVExCIGlzIDAlIGZ1bGwKRGVjIDE2IDE1OjU0OjE0IHJpa2VyIGtlcm5lbDogU1dJ
T1RMQiBpcyAwJSBmdWxsCkRlYyAxNiAxNTo1NDoxOSByaWtlciBrZXJuZWw6IFNXSU9UTEIg
aXMgMCUgZnVsbApEZWMgMTYgMTU6NTQ6MjQgcmlrZXIga2VybmVsOiBTV0lPVExCIGlzIDAl
IGZ1bGwKRGVjIDE2IDE1OjU0OjI5IHJpa2VyIGtlcm5lbDogU1dJT1RMQiBpcyAwJSBmdWxs
CkRlYyAxNiAxNTo1NDozNCByaWtlciBrZXJuZWw6IFNXSU9UTEIgaXMgMCUgZnVsbApEZWMg
MTYgMTU6NTQ6MzkgcmlrZXIga2VybmVsOiBTV0lPVExCIGlzIDAlIGZ1bGwKRGVjIDE2IDE1
OjU0OjQ0IHJpa2VyIGtlcm5lbDogU1dJT1RMQiBpcyAwJSBmdWxsCkRlYyAxNiAxNTo1NDo0
OSByaWtlciBrZXJuZWw6IFNXSU9UTEIgaXMgMCUgZnVsbApEZWMgMTYgMTU6NTQ6NTQgcmlr
ZXIga2VybmVsOiBTV0lPVExCIGlzIDAlIGZ1bGwKRGVjIDE2IDE1OjU0OjU5IHJpa2VyIGtl
cm5lbDogU1dJT1RMQiBpcyAwJSBmdWxsCkRlYyAxNiAxNTo1NTowNCByaWtlciBrZXJuZWw6
IFNXSU9UTEIgaXMgMCUgZnVsbApEZWMgMTYgMTU6NTU6MDkgcmlrZXIga2VybmVsOiBTV0lP
VExCIGlzIDAlIGZ1bGwKRGVjIDE2IDE1OjU1OjE0IHJpa2VyIGtlcm5lbDogU1dJT1RMQiBp
cyAwJSBmdWxsCkRlYyAxNiAxNTo1NToxOSByaWtlciBrZXJuZWw6IFNXSU9UTEIgaXMgMCUg
ZnVsbApEZWMgMTYgMTU6NTU6MjQgcmlrZXIga2VybmVsOiBTV0lPVExCIGlzIDAlIGZ1bGwK
RGVjIDE2IDE1OjU1OjI5IHJpa2VyIGtlcm5lbDogU1dJT1RMQiBpcyAwJSBmdWxsCkRlYyAx
NiAxNTo1NTozNCByaWtlciBrZXJuZWw6IFNXSU9UTEIgaXMgMCUgZnVsbApEZWMgMTYgMTU6
NTU6MzkgcmlrZXIga2VybmVsOiBTV0lPVExCIGlzIDAlIGZ1bGwKRGVjIDE2IDE1OjU1OjQz
IHJpa2VyIGtlcm5lbDogU1dJT1RMQiBpcyAwJSBmdWxsCkRlYyAxNiAxNTo1NTo0OCByaWtl
ciBrZXJuZWw6IFNXSU9UTEIgaXMgMCUgZnVsbApEZWMgMTYgMTU6NTU6NTMgcmlrZXIga2Vy
bmVsOiBTV0lPVExCIGlzIDAlIGZ1bGwKRGVjIDE2IDE1OjU1OjU4IHJpa2VyIGtlcm5lbDog
U1dJT1RMQiBpcyAwJSBmdWxsCkRlYyAxNiAxNTo1NjowMyByaWtlciBrZXJuZWw6IFNXSU9U
TEIgaXMgMCUgZnVsbApEZWMgMTYgMTU6NTY6MDggcmlrZXIga2VybmVsOiBTV0lPVExCIGlz
IDAlIGZ1bGwKRGVjIDE2IDE1OjU2OjEzIHJpa2VyIGtlcm5lbDogU1dJT1RMQiBpcyAwJSBm
dWxsCkRlYyAxNiAxNTo1NjoxOCByaWtlciBrZXJuZWw6IFNXSU9UTEIgaXMgMCUgZnVsbApE
ZWMgMTYgMTU6NTY6MjMgcmlrZXIga2VybmVsOiBTV0lPVExCIGlzIDAlIGZ1bGwKRGVjIDE2
IDE1OjU2OjI4IHJpa2VyIGtlcm5lbDogU1dJT1RMQiBpcyAwJSBmdWxsCkRlYyAxNiAxNTo1
NjozMyByaWtlciBrZXJuZWw6IFNXSU9UTEIgaXMgMCUgZnVsbApEZWMgMTYgMTU6NTY6MzYg
cmlrZXIga2VybmVsOiBzd2lvdGxiX3N0b3BfdGhyZWFkOiBTdG9wIQpEZWMgMTYgMTU6NTY6
MzYgcmlrZXIga2VybmVsOiBTV0lPVExCIGlzIDAlIGZ1bGwKRGVjIDE2IDE1OjU3OjIyIHJp
a2VyIHNodXRkb3duWzEyODFdOiBzaHV0dGluZyBkb3duIGZvciBzeXN0ZW0gaGFsdApEZWMg
MTYgMTU6NTc6MjMgcmlrZXIga2VybmVsOiBuZnNkOiBsYXN0IHNlcnZlciBoYXMgZXhpdGVk
LCBmbHVzaGluZyBleHBvcnQgY2FjaGUKRGVjIDE2IDE1OjU3OjI1IHJpa2VyIGtlcm5lbDog
S2VybmVsIGxvZ2dpbmcgKHByb2MpIHN0b3BwZWQuCkRlYyAxNiAxNTo1NzoyNSByaWtlciBy
c3lzbG9nZDogW29yaWdpbiBzb2Z0d2FyZT0icnN5c2xvZ2QiIHN3VmVyc2lvbj0iNC42LjQi
IHgtcGlkPSI2MTAiIHgtaW5mbz0iaHR0cDovL3d3dy5yc3lzbG9nLmNvbSJdIGV4aXRpbmcg
b24gc2lnbmFsIDE1LgpEZWMgMTYgMTU6NTg6MDAgcmlrZXIga2VybmVsOiBpbWtsb2cgNC42
LjQsIGxvZyBzb3VyY2UgPSAvcHJvYy9rbXNnIHN0YXJ0ZWQuCkRlYyAxNiAxNTo1ODowMCBy
aWtlciByc3lzbG9nZDogW29yaWdpbiBzb2Z0d2FyZT0icnN5c2xvZ2QiIHN3VmVyc2lvbj0i
NC42LjQiIHgtcGlkPSI2MTQiIHgtaW5mbz0iaHR0cDovL3d3dy5yc3lzbG9nLmNvbSJdIChy
ZSlzdGFydAoKIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIG5vcm1hbCBib290
ICMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMKCkRlYyAxNiAx
NTo1ODowMCByaWtlciBrZXJuZWw6IExpbnV4IHZlcnNpb24gMi42LjM0LjcuMS14ZW4tYW1k
NjQgKHJvb3RAY2hla290ZXkpIChnY2MgdmVyc2lvbiA0LjQuNSAoRGViaWFuIDQuNC41LTgp
ICkgIzYgU01QIFdlZCBBdWcgMTcgMTE6NDk6NTMgQ0VTVCAyMDExCkRlYyAxNiAxNTo1ODow
MCByaWtlciBrZXJuZWw6IENvbW1hbmQgbGluZTogcm9vdD0vZGV2L3h2ZGExIHJvIHN3aW90
bGI9MzIsZm9yY2UgeGVuY29ucz10dHkKRGVjIDE2IDE1OjU4OjAwIHJpa2VyIGtlcm5lbDog
WGVuLXByb3ZpZGVkIHBoeXNpY2FsIFJBTSBtYXA6CkRlYyAxNiAxNTo1ODowMCByaWtlciBr
ZXJuZWw6IFhlbjogMDAwMDAwMDAwMDAwMDAwMCAtIDAwMDAwMDAwMTQ4MDAwMDAgKHVzYWJs
ZSkKRGVjIDE2IDE1OjU4OjAwIHJpa2VyIGtlcm5lbDogTlggKEV4ZWN1dGUgRGlzYWJsZSkg
cHJvdGVjdGlvbjogYWN0aXZlCkRlYyAxNiAxNTo1ODowMCByaWtlciBrZXJuZWw6IGxhc3Rf
cGZuID0gMHgxNDgwMCBtYXhfYXJjaF9wZm4gPSAweDgwMDAwMDAwCkRlYyAxNiAxNTo1ODow
MCByaWtlciBrZXJuZWw6IGluaXRfbWVtb3J5X21hcHBpbmc6IDAwMDAwMDAwMDAwMDAwMDAt
MDAwMDAwMDAxNDgwMDAwMApEZWMgMTYgMTU6NTg6MDAgcmlrZXIga2VybmVsOiBSQU1ESVNL
OiAwMDdmYjAwMCAtIDAxMDA2MDAwCkRlYyAxNiAxNTo1ODowMCByaWtlciBrZXJuZWw6IEFD
UEkgaW4gdW5wcml2aWxlZ2VkIGRvbWFpbiBkaXNhYmxlZApEZWMgMTYgMTU6NTg6MDAgcmlr
ZXIga2VybmVsOiBab25lIFBGTiByYW5nZXM6CkRlYyAxNiAxNTo1ODowMCByaWtlciBrZXJu
ZWw6ICBETUEgICAgICAweDAwMDAwMDAwIC0+IDB4MDAwMDEwMDAKRGVjIDE2IDE1OjU4OjAw
IHJpa2VyIGtlcm5lbDogIERNQTMyICAgIDB4MDAwMDEwMDAgLT4gMHgwMDEwMDAwMApEZWMg
MTYgMTU6NTg6MDAgcmlrZXIga2VybmVsOiAgTm9ybWFsICAgZW1wdHkKRGVjIDE2IDE1OjU4
OjAwIHJpa2VyIGtlcm5lbDogTW92YWJsZSB6b25lIHN0YXJ0IFBGTiBmb3IgZWFjaCBub2Rl
CkRlYyAxNiAxNTo1ODowMCByaWtlciBrZXJuZWw6IGVhcmx5X25vZGVfbWFwWzJdIGFjdGl2
ZSBQRk4gcmFuZ2VzCkRlYyAxNiAxNTo1ODowMCByaWtlciBrZXJuZWw6ICAgIDA6IDB4MDAw
MDAwMDAgLT4gMHgwMDAxNDAwMApEZWMgMTYgMTU6NTg6MDAgcmlrZXIga2VybmVsOiAgICAw
OiAweDAwMDE0ODAwIC0+IDB4MDAwMTQ4MDAKRGVjIDE2IDE1OjU4OjAwIHJpa2VyIGtlcm5l
bDogc2V0dXBfcGVyY3B1OiBOUl9DUFVTOjMyIG5yX2NwdW1hc2tfYml0czozMiBucl9jcHVf
aWRzOjEgbnJfbm9kZV9pZHM6MQpEZWMgMTYgMTU6NTg6MDAgcmlrZXIga2VybmVsOiBQRVJD
UFU6IEVtYmVkZGVkIDE3IHBhZ2VzL2NwdSBAZmZmZjg4MDAwMTAwYTAwMCBzMzk1OTIgcjgx
OTIgZDIxODQ4IHU2OTYzMgpEZWMgMTYgMTU6NTg6MDAgcmlrZXIga2VybmVsOiBwY3B1LWFs
bG9jOiBzMzk1OTIgcjgxOTIgZDIxODQ4IHU2OTYzMiBhbGxvYz0xNyo0MDk2CkRlYyAxNiAx
NTo1ODowMCByaWtlciBrZXJuZWw6IHBjcHUtYWxsb2M6IFswXSAwIApEZWMgMTYgMTU6NTg6
MDAgcmlrZXIga2VybmVsOiBCdWlsdCAxIHpvbmVsaXN0cyBpbiBab25lIG9yZGVyLCBtb2Jp
bGl0eSBncm91cGluZyBvbi4gIFRvdGFsIHBhZ2VzOiA4MDc3MgpEZWMgMTYgMTU6NTg6MDAg
cmlrZXIga2VybmVsOiBLZXJuZWwgY29tbWFuZCBsaW5lOiByb290PS9kZXYveHZkYTEgcm8g
c3dpb3RsYj0zMixmb3JjZSB4ZW5jb25zPXR0eQpEZWMgMTYgMTU6NTg6MDAgcmlrZXIga2Vy
bmVsOiBQSUQgaGFzaCB0YWJsZSBlbnRyaWVzOiAyMDQ4IChvcmRlcjogMiwgMTYzODQgYnl0
ZXMpCkRlYyAxNiAxNTo1ODowMCByaWtlciBrZXJuZWw6IERlbnRyeSBjYWNoZSBoYXNoIHRh
YmxlIGVudHJpZXM6IDY1NTM2IChvcmRlcjogNywgNTI0Mjg4IGJ5dGVzKQpEZWMgMTYgMTU6
NTg6MDAgcmlrZXIga2VybmVsOiBJbm9kZS1jYWNoZSBoYXNoIHRhYmxlIGVudHJpZXM6IDMy
NzY4IChvcmRlcjogNiwgMjYyMTQ0IGJ5dGVzKQpEZWMgMTYgMTU6NTg6MDAgcmlrZXIga2Vy
bmVsOiBTb2Z0d2FyZSBJTyBUTEIgZW5hYmxlZDogCkRlYyAxNiAxNTo1ODowMCByaWtlciBr
ZXJuZWw6IEFwZXJ0dXJlOiAgICAgMzIgbWVnYWJ5dGVzCkRlYyAxNiAxNTo1ODowMCByaWtl
ciBrZXJuZWw6IEFkZHJlc3Mgc2l6ZTogMjggYml0cwpEZWMgMTYgMTU6NTg6MDAgcmlrZXIg
a2VybmVsOiBLZXJuZWwgcmFuZ2U6IGZmZmY4ODAwMDE2YzMwMDAgLSBmZmZmODgwMDAzNmMz
MDAwCkRlYyAxNiAxNTo1ODowMCByaWtlciBrZXJuZWw6IFBDSS1ETUE6IFVzaW5nIHNvZnR3
YXJlIGJvdW5jZSBidWZmZXJpbmcgZm9yIElPIChTV0lPVExCKQpEZWMgMTYgMTU6NTg6MDAg
cmlrZXIga2VybmVsOiBTdWJ0cmFjdCAoMzUgZWFybHkgcmVzZXJ2YXRpb25zKQpEZWMgMTYg
MTU6NTg6MDAgcmlrZXIga2VybmVsOiAgIzEgWzAwMDA3ZmIwMDAgLSAwMDAxMDA2MDAwXSAg
ICBYZW4gcHJvdmlkZWQKRGVjIDE2IDE1OjU4OjAwIHJpa2VyIGtlcm5lbDogICMyIFswMDAw
MjAwMDAwIC0gMDAwMDdkYWE5NF0gICBURVhUIERBVEEgQlNTCkRlYyAxNiAxNTo1ODowMCBy
aWtlciBrZXJuZWw6ICAjMyBbMDAwMTBiNjAwMCAtIDAwMDExNWMwMDBdICAgICAgICAgUEdU
QUJMRQpEZWMgMTYgMTU6NTg6MDAgcmlrZXIga2VybmVsOiAgIzQgWzAwMTQwMDAwMDAgLSAw
MDE0ODAwMDAwXSAgICAgICAgIEJBTExPT04KRGVjIDE2IDE1OjU4OjAwIHJpa2VyIGtlcm5l
bDogICM1IFswMDAxMTVjMDAwIC0gMDAwMTVkODAwMF0gICAgICAgICBCT09UTUVNCkRlYyAx
NiAxNTo1ODowMCByaWtlciBrZXJuZWw6ICAjNiBbMDAwMTVkODAwMCAtIDAwMDE1ZDgwMDhd
ICAgICAgICAgQk9PVE1FTQpEZWMgMTYgMTU6NTg6MDAgcmlrZXIga2VybmVsOiAgIzcgWzAw
MDE1ZDgwNDAgLSAwMDAxNWQ4MWMwXSAgICAgICAgIEJPT1RNRU0KRGVjIDE2IDE1OjU4OjAw
IHJpa2VyIGtlcm5lbDogICM4IFswMDAxNWQ4MWMwIC0gMDAwMTVkODFlMF0gICAgICAgICBC
T09UTUVNCkRlYyAxNiAxNTo1ODowMCByaWtlciBrZXJuZWw6ICAjOSBbMDAwMTVkODIwMCAt
IDAwMDE1ZGIyMDBdICAgICAgICAgQk9PVE1FTQpEZWMgMTYgMTU6NTg6MDAgcmlrZXIga2Vy
bmVsOiAgIzEwIFswMDAxNWRjMDAwIC0gMDAwMTVkZDAwMF0gICAgICAgICBCT09UTUVNCkRl
YyAxNiAxNTo1ODowMCByaWtlciBrZXJuZWw6ICAjMTEgWzAwMDE1ZGQwMDAgLSAwMDAxNWRl
MDAwXSAgICAgICAgIEJPT1RNRU0KRGVjIDE2IDE1OjU4OjAwIHJpa2VyIGtlcm5lbDogICMx
MiBbMDAwMTVkZTAwMCAtIDAwMDE1ZGYwMDBdICAgICAgICAgQk9PVE1FTQpEZWMgMTYgMTU6
NTg6MDAgcmlrZXIga2VybmVsOiAgIzEzIFswMDAxNWRmMDAwIC0gMDAwMTY4MzAwMF0gICAg
ICAgICBCT09UTUVNCkRlYyAxNiAxNTo1ODowMCByaWtlciBrZXJuZWw6ICAjMTQgWzAwMDEw
YTYwMDAgLSAwMDAxMGI2MDAwXSAgICBYZW4gcHJvdmlkZWQKRGVjIDE2IDE1OjU4OjAwIHJp
a2VyIGtlcm5lbDogICMxNSBbMDAwMTAwNjAwMCAtIDAwMDEwMDYwMTBdICAgICAgICAgQk9P
VE1FTQpEZWMgMTYgMTU6NTg6MDAgcmlrZXIga2VybmVsOiAgIzE2IFswMDAxMDA2MDQwIC0g
MDAwMTAwNjA0OF0gICAgICAgICBCT09UTUVNCkRlYyAxNiAxNTo1ODowMCByaWtlciBrZXJu
ZWw6ICAjMTcgWzAwMDEwMDcwMDAgLSAwMDAxMDA4MDAwXSAgICAgICAgIEJPT1RNRU0KRGVj
IDE2IDE1OjU4OjAwIHJpa2VyIGtlcm5lbDogICMxOCBbMDAwMTAwNjA4MCAtIDAwMDEwMDYw
YjBdICAgICAgICAgQk9PVE1FTQpEZWMgMTYgMTU6NTg6MDAgcmlrZXIga2VybmVsOiAgIzE5
IFswMDAxMDA2MGMwIC0gMDAwMTAwNjBmMF0gICAgICAgICBCT09UTUVNCkRlYyAxNiAxNTo1
ODowMCByaWtlciBrZXJuZWw6ICAjMjAgWzAwMDEwMGEwMDAgLSAwMDAxMDFiMDAwXSAgICAg
ICAgIEJPT1RNRU0KRGVjIDE2IDE1OjU4OjAwIHJpa2VyIGtlcm5lbDogICMyMSBbMDAwMTAw
NjEwMCAtIDAwMDEwMDYxMDhdICAgICAgICAgQk9PVE1FTQpEZWMgMTYgMTU6NTg6MDAgcmlr
ZXIga2VybmVsOiAgIzIyIFswMDAxMDA2MTQwIC0gMDAwMTAwNjE0OF0gICAgICAgICBCT09U
TUVNCkRlYyAxNiAxNTo1ODowMCByaWtlciBrZXJuZWw6ICAjMjMgWzAwMDEwMDYxODAgLSAw
MDAxMDA2MTg0XSAgICAgICAgIEJPT1RNRU0KRGVjIDE2IDE1OjU4OjAwIHJpa2VyIGtlcm5l
bDogICMyNCBbMDAwMTAwNjFjMCAtIDAwMDEwMDYxYzhdICAgICAgICAgQk9PVE1FTQpEZWMg
MTYgMTU6NTg6MDAgcmlrZXIga2VybmVsOiAgIzI1IFswMDAxMDA2MjAwIC0gMDAwMTAwNjMw
MF0gICAgICAgICBCT09UTUVNCkRlYyAxNiAxNTo1ODowMCByaWtlciBrZXJuZWw6ICAjMjYg
WzAwMDEwMDYzMDAgLSAwMDAxMDA2MzQ4XSAgICAgICAgIEJPT1RNRU0KRGVjIDE2IDE1OjU4
OjAwIHJpa2VyIGtlcm5lbDogICMyNyBbMDAwMTAwNjM4MCAtIDAwMDEwMDYzYzhdICAgICAg
ICAgQk9PVE1FTQpEZWMgMTYgMTU6NTg6MDAgcmlrZXIga2VybmVsOiAgIzI4IFswMDAxMDFi
MDAwIC0gMDAwMTAxZjAwMF0gICAgICAgICBCT09UTUVNCkRlYyAxNiAxNTo1ODowMCByaWtl
ciBrZXJuZWw6ICAjMjkgWzAwMDEwMWYwMDAgLSAwMDAxMDlmMDAwXSAgICAgICAgIEJPT1RN
RU0KRGVjIDE2IDE1OjU4OjAwIHJpa2VyIGtlcm5lbDogICMzMCBbMDAwMTY4MzAwMCAtIDAw
MDE2YzMwMDBdICAgICAgICAgQk9PVE1FTQpEZWMgMTYgMTU6NTg6MDAgcmlrZXIga2VybmVs
OiAgIzMxIFswMDAxNmMzMDAwIC0gMDAwMzZjMzAwMF0gICAgICAgICBCT09UTUVNCkRlYyAx
NiAxNTo1ODowMCByaWtlciBrZXJuZWw6ICAjMzIgWzAwMDM2YzMwMDAgLSAwMDAzNmQzMDAw
XSAgICAgICAgIEJPT1RNRU0KRGVjIDE2IDE1OjU4OjAwIHJpa2VyIGtlcm5lbDogICMzMyBb
MDAwMzZkMzAwMCAtIDAwMDM2ZjMwMDBdICAgICAgICAgQk9PVE1FTQpEZWMgMTYgMTU6NTg6
MDAgcmlrZXIga2VybmVsOiAgIzM0IFswMDAzNmYzMDAwIC0gMDAwMzZmYjAwMF0gICAgICAg
ICBCT09UTUVNCkRlYyAxNiAxNTo1ODowMCByaWtlciBrZXJuZWw6IE1lbW9yeTogMjczNTky
ay8zMzU4NzJrIGF2YWlsYWJsZSAoMzIyOGsga2VybmVsIGNvZGUsIDgxOTJrIGFic2VudCwg
NTQwODhrIHJlc2VydmVkLCAxNzIzayBkYXRhLCAzMjBrIGluaXQpCkRlYyAxNiAxNTo1ODow
MCByaWtlciBrZXJuZWw6IEhpZXJhcmNoaWNhbCBSQ1UgaW1wbGVtZW50YXRpb24uCkRlYyAx
NiAxNTo1ODowMCByaWtlciBrZXJuZWw6IFJDVS1iYXNlZCBkZXRlY3Rpb24gb2Ygc3RhbGxl
ZCBDUFVzIGlzIGVuYWJsZWQuCkRlYyAxNiAxNTo1ODowMCByaWtlciBrZXJuZWw6IE5SX0lS
UVM6MTYwMApEZWMgMTYgMTU6NTg6MDAgcmlrZXIga2VybmVsOiBYZW4gcmVwb3J0ZWQ6IDIy
MTAuMDM4IE1IeiBwcm9jZXNzb3IuCkRlYyAxNiAxNTo1ODowMCByaWtlciBrZXJuZWw6IENv
bnNvbGU6IGNvbG91ciBkdW1teSBkZXZpY2UgODB4MjUKRGVjIDE2IDE1OjU4OjAwIHJpa2Vy
IGtlcm5lbDogY29uc29sZSBbdHR5MF0gZW5hYmxlZApEZWMgMTYgMTU6NTg6MDAgcmlrZXIg
a2VybmVsOiBjb25zb2xlIFt0dHktMV0gZW5hYmxlZApEZWMgMTYgMTU6NTg6MDAgcmlrZXIg
a2VybmVsOiBDYWxpYnJhdGluZyBkZWxheSB1c2luZyB0aW1lciBzcGVjaWZpYyByb3V0aW5l
Li4gNDQ3OC42MyBCb2dvTUlQUyAobHBqPTg5NTcyNzYpCkRlYyAxNiAxNTo1ODowMCByaWtl
ciBrZXJuZWw6IFNlY3VyaXR5IEZyYW1ld29yayBpbml0aWFsaXplZApEZWMgMTYgMTU6NTg6
MDAgcmlrZXIga2VybmVsOiBTRUxpbnV4OiAgRGlzYWJsZWQgYXQgYm9vdC4KRGVjIDE2IDE1
OjU4OjAwIHJpa2VyIGtlcm5lbDogTW91bnQtY2FjaGUgaGFzaCB0YWJsZSBlbnRyaWVzOiAy
NTYKRGVjIDE2IDE1OjU4OjAwIHJpa2VyIGtlcm5lbDogU01QIGFsdGVybmF0aXZlczogc3dp
dGNoaW5nIHRvIFVQIGNvZGUKRGVjIDE2IDE1OjU4OjAwIHJpa2VyIGtlcm5lbDogRnJlZWlu
ZyBTTVAgYWx0ZXJuYXRpdmVzOiAzNmsgZnJlZWQKRGVjIDE2IDE1OjU4OjAwIHJpa2VyIGtl
cm5lbDogQnJvdWdodCB1cCAxIENQVXMKRGVjIDE2IDE1OjU4OjAwIHJpa2VyIGtlcm5lbDog
TkVUOiBSZWdpc3RlcmVkIHByb3RvY29sIGZhbWlseSAxNgpEZWMgMTYgMTU6NTg6MDAgcmlr
ZXIga2VybmVsOiBCcm91Z2h0IHVwIDEgQ1BVcwpEZWMgMTYgMTU6NTg6MDAgcmlrZXIga2Vy
bmVsOiBQQ0k6IHNldHRpbmcgdXAgWGVuIFBDSSBmcm9udGVuZCBzdHViCkRlYyAxNiAxNTo1
ODowMCByaWtlciBrZXJuZWw6IGJpbzogY3JlYXRlIHNsYWIgPGJpby0wPiBhdCAwCkRlYyAx
NiAxNTo1ODowMCByaWtlciBrZXJuZWw6IEFDUEk6IEludGVycHJldGVyIGRpc2FibGVkLgpE
ZWMgMTYgMTU6NTg6MDAgcmlrZXIga2VybmVsOiB2Z2FhcmI6IGxvYWRlZApEZWMgMTYgMTU6
NTg6MDAgcmlrZXIga2VybmVsOiB4ZW5fbWVtOiBJbml0aWFsaXNpbmcgYmFsbG9vbiBkcml2
ZXIuCkRlYyAxNiAxNTo1ODowMCByaWtlciBrZXJuZWw6IFNDU0kgc3Vic3lzdGVtIGluaXRp
YWxpemVkCkRlYyAxNiAxNTo1ODowMCByaWtlciBrZXJuZWw6IHVzYmNvcmU6IHJlZ2lzdGVy
ZWQgbmV3IGludGVyZmFjZSBkcml2ZXIgdXNiZnMKRGVjIDE2IDE1OjU4OjAwIHJpa2VyIGtl
cm5lbDogdXNiY29yZTogcmVnaXN0ZXJlZCBuZXcgaW50ZXJmYWNlIGRyaXZlciBodWIKRGVj
IDE2IDE1OjU4OjAwIHJpa2VyIGtlcm5lbDogdXNiY29yZTogcmVnaXN0ZXJlZCBuZXcgZGV2
aWNlIGRyaXZlciB1c2IKRGVjIDE2IDE1OjU4OjAwIHJpa2VyIGtlcm5lbDogUENJOiBTeXN0
ZW0gZG9lcyBub3Qgc3VwcG9ydCBQQ0kKRGVjIDE2IDE1OjU4OjAwIHJpa2VyIGtlcm5lbDog
UENJOiBTeXN0ZW0gZG9lcyBub3Qgc3VwcG9ydCBQQ0kKRGVjIDE2IDE1OjU4OjAwIHJpa2Vy
IGtlcm5lbDogTkVUOiBSZWdpc3RlcmVkIHByb3RvY29sIGZhbWlseSA4CkRlYyAxNiAxNTo1
ODowMCByaWtlciBrZXJuZWw6IE5FVDogUmVnaXN0ZXJlZCBwcm90b2NvbCBmYW1pbHkgMjAK
RGVjIDE2IDE1OjU4OjAwIHJpa2VyIGtlcm5lbDogU3dpdGNoaW5nIHRvIGNsb2Nrc291cmNl
IHhlbgpEZWMgMTYgMTU6NTg6MDAgcmlrZXIga2VybmVsOiBwbnA6IFBuUCBBQ1BJOiBkaXNh
YmxlZApEZWMgMTYgMTU6NTg6MDAgcmlrZXIga2VybmVsOiBORVQ6IFJlZ2lzdGVyZWQgcHJv
dG9jb2wgZmFtaWx5IDIKRGVjIDE2IDE1OjU4OjAwIHJpa2VyIGtlcm5lbDogSVAgcm91dGUg
Y2FjaGUgaGFzaCB0YWJsZSBlbnRyaWVzOiA0MDk2IChvcmRlcjogMywgMzI3NjggYnl0ZXMp
CkRlYyAxNiAxNTo1ODowMCByaWtlciBrZXJuZWw6IFRDUCBlc3RhYmxpc2hlZCBoYXNoIHRh
YmxlIGVudHJpZXM6IDE2Mzg0IChvcmRlcjogNiwgMjYyMTQ0IGJ5dGVzKQpEZWMgMTYgMTU6
NTg6MDAgcmlrZXIga2VybmVsOiBUQ1AgYmluZCBoYXNoIHRhYmxlIGVudHJpZXM6IDE2Mzg0
IChvcmRlcjogNiwgMjYyMTQ0IGJ5dGVzKQpEZWMgMTYgMTU6NTg6MDAgcmlrZXIga2VybmVs
OiBUQ1A6IEhhc2ggdGFibGVzIGNvbmZpZ3VyZWQgKGVzdGFibGlzaGVkIDE2Mzg0IGJpbmQg
MTYzODQpCkRlYyAxNiAxNTo1ODowMCByaWtlciBrZXJuZWw6IFRDUCByZW5vIHJlZ2lzdGVy
ZWQKRGVjIDE2IDE1OjU4OjAwIHJpa2VyIGtlcm5lbDogVURQIGhhc2ggdGFibGUgZW50cmll
czogMjU2IChvcmRlcjogMSwgODE5MiBieXRlcykKRGVjIDE2IDE1OjU4OjAwIHJpa2VyIGtl
cm5lbDogVURQLUxpdGUgaGFzaCB0YWJsZSBlbnRyaWVzOiAyNTYgKG9yZGVyOiAxLCA4MTky
IGJ5dGVzKQpEZWMgMTYgMTU6NTg6MDAgcmlrZXIga2VybmVsOiBORVQ6IFJlZ2lzdGVyZWQg
cHJvdG9jb2wgZmFtaWx5IDEKRGVjIDE2IDE1OjU4OjAwIHJpa2VyIGtlcm5lbDogVHJ5aW5n
IHRvIHVucGFjayByb290ZnMgaW1hZ2UgYXMgaW5pdHJhbWZzLi4uCkRlYyAxNiAxNTo1ODow
MCByaWtlciBrZXJuZWw6IEZyZWVpbmcgaW5pdHJkIG1lbW9yeTogODIzNmsgZnJlZWQKRGVj
IDE2IDE1OjU4OjAwIHJpa2VyIGtlcm5lbDogcGxhdGZvcm0gcnRjX2Ntb3M6IHJlZ2lzdGVy
ZWQgcGxhdGZvcm0gUlRDIGRldmljZSAobm8gUE5QIGRldmljZSBmb3VuZCkKRGVjIDE2IDE1
OjU4OjAwIHJpa2VyIGtlcm5lbDogYXVkaXQ6IGluaXRpYWxpemluZyBuZXRsaW5rIHNvY2tl
dCAoZGlzYWJsZWQpCkRlYyAxNiAxNTo1ODowMCByaWtlciBrZXJuZWw6IHR5cGU9MjAwMCBh
dWRpdCgxMzI0MDQ3NDc1LjMxMjoxKTogaW5pdGlhbGl6ZWQKRGVjIDE2IDE1OjU4OjAwIHJp
a2VyIGtlcm5lbDogVkZTOiBEaXNrIHF1b3RhcyBkcXVvdF82LjUuMgpEZWMgMTYgMTU6NTg6
MDAgcmlrZXIga2VybmVsOiBEcXVvdC1jYWNoZSBoYXNoIHRhYmxlIGVudHJpZXM6IDUxMiAo
b3JkZXIgMCwgNDA5NiBieXRlcykKRGVjIDE2IDE1OjU4OjAwIHJpa2VyIGtlcm5lbDogTlRG
UyBkcml2ZXIgMi4xLjI5IFtGbGFnczogUi9XXS4KRGVjIDE2IDE1OjU4OjAwIHJpa2VyIGtl
cm5lbDogbXNnbW5pIGhhcyBiZWVuIHNldCB0byA2NTYKRGVjIDE2IDE1OjU4OjAwIHJpa2Vy
IGtlcm5lbDogcGNpZnJvbnQgcGNpLTA6IEluc3RhbGxpbmcgUENJIGZyb250ZW5kCkRlYyAx
NiAxNTo1ODowMCByaWtlciBrZXJuZWw6IGFsZzogTm8gdGVzdCBmb3Igc3Rkcm5nIChrcm5n
KQpEZWMgMTYgMTU6NTg6MDAgcmlrZXIga2VybmVsOiBCbG9jayBsYXllciBTQ1NJIGdlbmVy
aWMgKGJzZykgZHJpdmVyIHZlcnNpb24gMC40IGxvYWRlZCAobWFqb3IgMjU0KQpEZWMgMTYg
MTU6NTg6MDAgcmlrZXIga2VybmVsOiBpbyBzY2hlZHVsZXIgbm9vcCByZWdpc3RlcmVkCkRl
YyAxNiAxNTo1ODowMCByaWtlciBrZXJuZWw6IGlvIHNjaGVkdWxlciBkZWFkbGluZSByZWdp
c3RlcmVkCkRlYyAxNiAxNTo1ODowMCByaWtlciBrZXJuZWw6IGlvIHNjaGVkdWxlciBjZnEg
cmVnaXN0ZXJlZCAoZGVmYXVsdCkKRGVjIDE2IDE1OjU4OjAwIHJpa2VyIGtlcm5lbDogTGlu
dXggYWdwZ2FydCBpbnRlcmZhY2UgdjAuMTAzCkRlYyAxNiAxNTo1ODowMCByaWtlciBrZXJu
ZWw6IGJyZDogbW9kdWxlIGxvYWRlZApEZWMgMTYgMTU6NTg6MDAgcmlrZXIga2VybmVsOiBY
ZW4gdmlydHVhbCBjb25zb2xlIHN1Y2Nlc3NmdWxseSBpbnN0YWxsZWQgYXMgdHR5MQpEZWMg
MTYgMTU6NTg6MDAgcmlrZXIga2VybmVsOiBFdmVudC1jaGFubmVsIGRldmljZSBpbnN0YWxs
ZWQuCkRlYyAxNiAxNTo1ODowMCByaWtlciBrZXJuZWw6IHBjaWZyb250IHBjaS0wOiBDcmVh
dGluZyBQQ0kgRnJvbnRlbmQgQnVzIDAwMDA6MDAKRGVjIDE2IDE1OjU4OjAwIHJpa2VyIGtl
cm5lbDogYmxrdGFwX2RldmljZV9pbml0OiBibGt0YXAgZGV2aWNlIG1ham9yIDI1NApEZWMg
MTYgMTU6NTg6MDAgcmlrZXIga2VybmVsOiBibGt0YXBfcmluZ19pbml0OiBibGt0YXAgcmlu
ZyBtYWpvcjogMjUyCkRlYyAxNiAxNTo1ODowMCByaWtlciBrZXJuZWw6IG5ldGZyb250OiBJ
bml0aWFsaXNpbmcgdmlydHVhbCBldGhlcm5ldCBkcml2ZXIuCkRlYyAxNiAxNTo1ODowMCBy
aWtlciBrZXJuZWw6IHhlbi12YmQ6IHJlZ2lzdGVyZWQgYmxvY2sgZGV2aWNlIG1ham9yIDIw
MgpEZWMgMTYgMTU6NTg6MDAgcmlrZXIga2VybmVsOiBibGtmcm9udDogeHZkYTE6IGJhcnJp
ZXJzIGVuYWJsZWQKRGVjIDE2IDE1OjU4OjAwIHJpa2VyIGtlcm5lbDogYmxrZnJvbnQ6IHh2
ZGEyOiBiYXJyaWVycyBlbmFibGVkCkRlYyAxNiAxNTo1ODowMCByaWtlciBrZXJuZWw6IFNl
dHRpbmcgY2FwYWNpdHkgdG8gODM4ODYwOApEZWMgMTYgMTU6NTg6MDAgcmlrZXIga2VybmVs
OiB4dmRhMTogZGV0ZWN0ZWQgY2FwYWNpdHkgY2hhbmdlIGZyb20gMCB0byA0Mjk0OTY3Mjk2
CkRlYyAxNiAxNTo1ODowMCByaWtlciBrZXJuZWw6IFNldHRpbmcgY2FwYWNpdHkgdG8gMjA5
NzE1MgpEZWMgMTYgMTU6NTg6MDAgcmlrZXIga2VybmVsOiB4dmRhMjogZGV0ZWN0ZWQgY2Fw
YWNpdHkgY2hhbmdlIGZyb20gMCB0byAxMDczNzQxODI0CkRlYyAxNiAxNTo1ODowMCByaWtl
ciBrZXJuZWw6IGJsa2Zyb250OiB4dmRiMTogYmFycmllcnMgZW5hYmxlZApEZWMgMTYgMTU6
NTg6MDAgcmlrZXIga2VybmVsOiB1c2Jjb3JlOiByZWdpc3RlcmVkIG5ldyBpbnRlcmZhY2Ug
ZHJpdmVyIHVzYmJhY2sKRGVjIDE2IDE1OjU4OjAwIHJpa2VyIGtlcm5lbDogUFBQIGdlbmVy
aWMgZHJpdmVyIHZlcnNpb24gMi40LjIKRGVjIDE2IDE1OjU4OjAwIHJpa2VyIGtlcm5lbDog
UE5QOiBObyBQUy8yIGNvbnRyb2xsZXIgZm91bmQuIFByb2JpbmcgcG9ydHMgZGlyZWN0bHku
CkRlYyAxNiAxNTo1ODowMCByaWtlciBrZXJuZWw6IG1pY2U6IFBTLzIgbW91c2UgZGV2aWNl
IGNvbW1vbiBmb3IgYWxsIG1pY2UKRGVjIDE2IDE1OjU4OjAwIHJpa2VyIGtlcm5lbDogVENQ
IGJpYyByZWdpc3RlcmVkCkRlYyAxNiAxNTo1ODowMCByaWtlciBrZXJuZWw6IE5FVDogUmVn
aXN0ZXJlZCBwcm90b2NvbCBmYW1pbHkgMTcKRGVjIDE2IDE1OjU4OjAwIHJpa2VyIGtlcm5l
bDogUENJIElPIG11bHRpcGxleGVyIGRldmljZSBpbnN0YWxsZWQuCkRlYyAxNiAxNTo1ODow
MCByaWtlciBrZXJuZWw6IEZyZWVpbmcgdW51c2VkIGtlcm5lbCBtZW1vcnk6IDMyMGsgZnJl
ZWQKRGVjIDE2IDE1OjU4OjAwIHJpa2VyIGtlcm5lbDoga2pvdXJuYWxkIHN0YXJ0aW5nLiAg
Q29tbWl0IGludGVydmFsIDUgc2Vjb25kcwpEZWMgMTYgMTU6NTg6MDAgcmlrZXIga2VybmVs
OiBFWFQzLWZzICh4dmRhMSk6IG1vdW50ZWQgZmlsZXN5c3RlbSB3aXRoIHdyaXRlYmFjayBk
YXRhIG1vZGUKRGVjIDE2IDE1OjU4OjAwIHJpa2VyIGtlcm5lbDogdWRldlsxODZdOiBzdGFy
dGluZyB2ZXJzaW9uIDE2NApEZWMgMTYgMTU6NTg6MDAgcmlrZXIga2VybmVsOiBMaW51eCB2
aWRlbyBjYXB0dXJlIGludGVyZmFjZTogdjIuMDAKRGVjIDE2IDE1OjU4OjAwIHJpa2VyIGtl
cm5lbDogc2FhNzE0NjogcmVnaXN0ZXIgZXh0ZW5zaW9uICdidWRnZXRfYXYnLgpEZWMgMTYg
MTU6NTg6MDAgcmlrZXIga2VybmVsOiBidWRnZXRfYXYgMDAwMDowMDowMC4wOiBlbmFibGlu
ZyBkZXZpY2UgKDAwMDAgLT4gMDAwMikKRGVjIDE2IDE1OjU4OjAwIHJpa2VyIGtlcm5lbDog
SVJRIDE3LzogSVJRRl9ESVNBQkxFRCBpcyBub3QgZ3VhcmFudGVlZCBvbiBzaGFyZWQgSVJR
cwpEZWMgMTYgMTU6NTg6MDAgcmlrZXIga2VybmVsOiBzYWE3MTQ2OiBmb3VuZCBzYWE3MTQ2
IEAgbWVtIGZmZmZjOTAwMDAyM2UwMDAgKHJldmlzaW9uIDEsIGlycSAxNykgKDB4MTg5NCww
eDAwMjgpLgpEZWMgMTYgMTU6NTg6MDAgcmlrZXIga2VybmVsOiBzYWE3MTQ2ICgwKTogZG1h
IGJ1ZmZlciBzaXplIDEzNDc1ODQKRGVjIDE2IDE1OjU4OjAwIHJpa2VyIGtlcm5lbDogRFZC
OiByZWdpc3RlcmluZyBuZXcgYWRhcHRlciAoS05DMSBEVkItQyBNSzMpCkRlYyAxNiAxNTo1
ODowMCByaWtlciBrZXJuZWw6IGFkYXB0ZXIgZmFpbGVkIE1BQyBzaWduYXR1cmUgY2hlY2sK
RGVjIDE2IDE1OjU4OjAwIHJpa2VyIGtlcm5lbDogZW5jb2RlZCBNQUMgZnJvbSBFRVBST00g
d2FzIGZmOmZmOmZmOmZmOmZmOmZmOmZmOmZmOmZmOmZmOmZmOmZmOmZmOmZmOmZmOmZmOmZm
OmZmOmZmOmZmCkRlYyAxNiAxNTo1ODowMCByaWtlciBrZXJuZWw6IEtOQzEtMDogTUFDIGFk
ZHIgPSAwMDowOTpkNjo2ZDpiMzowYQpEZWMgMTYgMTU6NTg6MDAgcmlrZXIga2VybmVsOiBE
VkI6IHJlZ2lzdGVyaW5nIGFkYXB0ZXIgMCBmcm9udGVuZCAwIChQaGlsaXBzIFREQTEwMDIz
IERWQi1DKS4uLgpEZWMgMTYgMTU6NTg6MDAgcmlrZXIga2VybmVsOiBidWRnZXQtYXY6IGNp
IGludGVyZmFjZSBpbml0aWFsaXNlZC4KRGVjIDE2IDE1OjU4OjAwIHJpa2VyIGtlcm5lbDog
YnVkZ2V0X2F2IDAwMDA6MDA6MDEuMDogZW5hYmxpbmcgZGV2aWNlICgwMDAwIC0+IDAwMDIp
CkRlYyAxNiAxNTo1ODowMCByaWtlciBrZXJuZWw6IElSUSAxOC86IElSUUZfRElTQUJMRUQg
aXMgbm90IGd1YXJhbnRlZWQgb24gc2hhcmVkIElSUXMKRGVjIDE2IDE1OjU4OjAwIHJpa2Vy
IGtlcm5lbDogc2FhNzE0NjogZm91bmQgc2FhNzE0NiBAIG1lbSBmZmZmYzkwMDAwNGQ2MDAw
IChyZXZpc2lvbiAxLCBpcnEgMTgpICgweDE4OTQsMHgwMDJjKS4KRGVjIDE2IDE1OjU4OjAw
IHJpa2VyIGtlcm5lbDogc2FhNzE0NiAoMSk6IGRtYSBidWZmZXIgc2l6ZSAxMzQ3NTg0CkRl
YyAxNiAxNTo1ODowMCByaWtlciBrZXJuZWw6IERWQjogcmVnaXN0ZXJpbmcgbmV3IGFkYXB0
ZXIgKFNhdGVsY28gRWFzeVdhdGNoIERWQi1DIE1LMykKRGVjIDE2IDE1OjU4OjAwIHJpa2Vy
IGtlcm5lbDogYWRhcHRlciBmYWlsZWQgTUFDIHNpZ25hdHVyZSBjaGVjawpEZWMgMTYgMTU6
NTg6MDAgcmlrZXIga2VybmVsOiBlbmNvZGVkIE1BQyBmcm9tIEVFUFJPTSB3YXMgZmY6ZmY6
ZmY6ZmY6ZmY6ZmY6ZmY6ZmY6ZmY6ZmY6ZmY6ZmY6ZmY6ZmY6ZmY6ZmY6ZmY6ZmY6ZmY6ZmYK
RGVjIDE2IDE1OjU4OjAwIHJpa2VyIGtlcm5lbDogS05DMS0xOiBNQUMgYWRkciA9IDAwOjA5
OmQ2OjZkOmIwOjMzCkRlYyAxNiAxNTo1ODowMCByaWtlciBrZXJuZWw6IERWQjogcmVnaXN0
ZXJpbmcgYWRhcHRlciAxIGZyb250ZW5kIDAgKFBoaWxpcHMgVERBMTAwMjMgRFZCLUMpLi4u
CkRlYyAxNiAxNTo1ODowMCByaWtlciBrZXJuZWw6IGJ1ZGdldC1hdjogY2kgaW50ZXJmYWNl
IGluaXRpYWxpc2VkLgpEZWMgMTYgMTU6NTg6MDAgcmlrZXIga2VybmVsOiBBZGRpbmcgMTA0
ODU3Mmsgc3dhcCBvbiAvZGV2L3h2ZGEyLiAgUHJpb3JpdHk6LTEgZXh0ZW50czoxIGFjcm9z
czoxMDQ4NTcyayBTUwpEZWMgMTYgMTU6NTg6MDAgcmlrZXIga2VybmVsOiBFWFQzLWZzICh4
dmRhMSk6IHdhcm5pbmc6IG1heGltYWwgbW91bnQgY291bnQgcmVhY2hlZCwgcnVubmluZyBl
MmZzY2sgaXMgcmVjb21tZW5kZWQKRGVjIDE2IDE1OjU4OjAwIHJpa2VyIGtlcm5lbDogRVhU
My1mcyAoeHZkYTEpOiB1c2luZyBpbnRlcm5hbCBqb3VybmFsCkRlYyAxNiAxNTo1ODowMCBy
aWtlciBrZXJuZWw6IGtqb3VybmFsZCBzdGFydGluZy4gIENvbW1pdCBpbnRlcnZhbCA1IHNl
Y29uZHMKRGVjIDE2IDE1OjU4OjAwIHJpa2VyIGtlcm5lbDogRVhUMy1mcyAoeHZkYjEpOiB3
YXJuaW5nOiBtYXhpbWFsIG1vdW50IGNvdW50IHJlYWNoZWQsIHJ1bm5pbmcgZTJmc2NrIGlz
IHJlY29tbWVuZGVkCkRlYyAxNiAxNTo1ODowMCByaWtlciBrZXJuZWw6IEVYVDMtZnMgKHh2
ZGIxKTogdXNpbmcgaW50ZXJuYWwgam91cm5hbApEZWMgMTYgMTU6NTg6MDAgcmlrZXIga2Vy
bmVsOiBFWFQzLWZzICh4dmRiMSk6IG1vdW50ZWQgZmlsZXN5c3RlbSB3aXRoIHdyaXRlYmFj
ayBkYXRhIG1vZGUKRGVjIDE2IDE1OjU4OjAwIHJpa2VyIGtlcm5lbDogUlBDOiBSZWdpc3Rl
cmVkIHVkcCB0cmFuc3BvcnQgbW9kdWxlLgpEZWMgMTYgMTU6NTg6MDAgcmlrZXIga2VybmVs
OiBSUEM6IFJlZ2lzdGVyZWQgdGNwIHRyYW5zcG9ydCBtb2R1bGUuCkRlYyAxNiAxNTo1ODow
MCByaWtlciBrZXJuZWw6IFJQQzogUmVnaXN0ZXJlZCB0Y3AgTkZTdjQuMSBiYWNrY2hhbm5l
bCB0cmFuc3BvcnQgbW9kdWxlLgpEZWMgMTYgMTU6NTg6MDAgcmlrZXIga2VybmVsOiBJbnN0
YWxsaW5nIGtuZnNkIChjb3B5cmlnaHQgKEMpIDE5OTYgb2tpckBtb25hZC5zd2IuZGUpLgpE
ZWMgMTYgMTU6NTg6MDAgcmlrZXIga2VybmVsOiBORVQ6IFJlZ2lzdGVyZWQgcHJvdG9jb2wg
ZmFtaWx5IDEwCkRlYyAxNiAxNTo1ODowMCByaWtlciBrZXJuZWw6IGxvOiBEaXNhYmxlZCBQ
cml2YWN5IEV4dGVuc2lvbnMKRGVjIDE2IDE1OjU4OjAwIHJpa2VyIGtlcm5lbDogc3ZjOiBm
YWlsZWQgdG8gcmVnaXN0ZXIgbG9ja2R2MSBSUEMgc2VydmljZSAoZXJybm8gOTcpLgpEZWMg
MTYgMTU6NTg6MDAgcmlrZXIga2VybmVsOiBORlNEOiBVc2luZyAvdmFyL2xpYi9uZnMvdjRy
ZWNvdmVyeSBhcyB0aGUgTkZTdjQgc3RhdGUgcmVjb3ZlcnkgZGlyZWN0b3J5CkRlYyAxNiAx
NTo1ODowMCByaWtlciBrZXJuZWw6IE5GU0Q6IHN0YXJ0aW5nIDkwLXNlY29uZCBncmFjZSBw
ZXJpb2QK
--=_jASWBVRfAzzjZ2gubxT7JfE4rOPAtg-rILiWQbFgI4tLQ-VX
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--=_jASWBVRfAzzjZ2gubxT7JfE4rOPAtg-rILiWQbFgI4tLQ-VX--



From xen-devel-bounces@lists.xensource.com Fri Dec 16 16:02:24 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 16:02:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbaER-0004ne-02; Fri, 16 Dec 2011 16:01:59 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <carsten@schiers.de>) id 1RbaEO-0004nK-O6
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 16:01:57 +0000
X-Env-Sender: carsten@schiers.de
X-Msg-Ref: server-2.tower-216.messagelabs.com!1324051310!9098196!1
X-Originating-IP: [194.117.254.36]
X-SpamReason: No, hits=0.2 required=7.0 tests=FROM_EXCESS_QP, MIME_QP_LONG_LINE
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26546 invoked from network); 16 Dec 2011 16:01:50 -0000
Received: from www.zeus06.de (HELO mail.zeus06.de) (194.117.254.36)
	by server-2.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Dec 2011 16:01:50 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=mail.zeus06.de; h=subject
	:from:to:cc:date:mime-version:content-type:in-reply-to
	:references:message-id; s=beta; bh=VH904Q6YPeUeRztGTyxKc/GC0Lr3s
	3dFdKLSPf5AraU=; b=KQUaWZ73F9dD8PEGj1AXlW/om6TDS+Vb0Dp2V/8EVAq8P
	cKuFQXiXFM4JOR8gSb8hJ1TRV1OzxTWsz7FPftUoqZv3weaa/tG6hvvmRGO6u/xG
	U9gPjwbqM8OSoVLF1ymDdeMPSSOX4qtaGhMljZYxxRc9tqWqEjs0BAW5taNvhA=
Received: (qmail 18271 invoked from network); 16 Dec 2011 17:01:43 +0100
Received: from unknown (HELO uhura.zz) (l3s6271p1@46.59.162.10)
	by mail.zeus06.de with ESMTPA; 16 Dec 2011 17:01:43 +0100
Received: from localhost (localhost [127.0.0.1])
	by uhura.zz (Postfix) with ESMTP id E02B22C525;
	Fri, 16 Dec 2011 16:52:00 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at schiers.de
Received: from uhura.zz ([127.0.0.1])
	by localhost (uhura.space.zz [127.0.0.1]) (amavisd-new, port 10024)
	with LMTP id OaPos0cw3+ug; Fri, 16 Dec 2011 16:51:47 +0100 (CET)
Received: from uhura.space.zz (localhost [127.0.0.1])
	by uhura.zz (Postfix) with ESMTP id 57BB42C526;
	Fri, 16 Dec 2011 16:51:47 +0100 (CET)
From: =?utf-8?Q?Carsten_Schiers?= <carsten@schiers.de>
To: =?utf-8?Q?Konrad_Rzeszutek_Wilk?= <konrad.wilk@oracle.com>
Date: Fri, 16 Dec 2011 16:51:47 +0100
Mime-Version: 1.0
Content-Type: multipart/mixed; 
	boundary="=_jASWBVRfAzzjZ2gubxT7JfE4rOPAtg-rILiWQbFgI4tLQ-VX"
In-Reply-To: <20111216150440.GD31755@phenom.dumpdata.com>
References: <20111214220700.GA9926@phenom.dumpdata.com>
X-Priority: 3 (Normal)
X-Mailer: Zarafa 7.0.2-29470
Thread-Index: Acy8CpY10TkQVNhYRXi5GOwMxjBFyQ==
Message-Id: <zarafa.4eeb6913.0870.04527b5d644d76ef@uhura.space.zz>
Cc: =?utf-8?Q?linux=40eikelenboom=2Eit?= <linux@eikelenboom.it>,
	=?utf-8?Q?xen-devel?= <xen-devel@lists.xensource.com>,
	=?utf-8?Q?lersek=40redhat=2Ecom?= <lersek@redhat.com>,
	=?utf-8?Q?zhenzhong=2Eduan=40oracle=2Ecom?= <zhenzhong.duan@oracle.com>,
	=?utf-8?Q?Ian_Campbell?= <ian.campbell@citrix.com>
Subject: Re: [Xen-devel] Load increase after memory upgrade (part2)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a multi-part message in MIME format. Your mail reader does not
understand MIME message format.
--=_jASWBVRfAzzjZ2gubxT7JfE4rOPAtg-rILiWQbFgI4tLQ-VX
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

> And you are using swiotlb=3Dforce on the 2.6.34 classic kernel and passing in your budget-av card in it=3F

Yes, two of them with swiotlb=3D32,force.


> Could you append the dmesg output please=3F

Attached. You find a "normal" boot after the one with the patched kernel.

Carsten.



--=_jASWBVRfAzzjZ2gubxT7JfE4rOPAtg-rILiWQbFgI4tLQ-VX
Content-Type: application/octet-stream; name=dmesg.txt
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=dmesg.txt

RGVjIDE2IDE1OjUzOjExIHJpa2VyIGtlcm5lbDogTGludXggdmVyc2lvbiAyLjYuMzQuNy4x
LXhlbi1hbWQ2NCAocm9vdEBjaGVrb3RleSkgKGdjYyB2ZXJzaW9uIDQuNC41IChEZWJpYW4g
NC40LjUtOCkgKSAjNyBTTVAgRnJpIERlYyAxNiAxMzozNjozMyBDRVQgMjAxMQpEZWMgMTYg
MTU6NTM6MTEgcmlrZXIga2VybmVsOiBDb21tYW5kIGxpbmU6IHJvb3Q9L2Rldi94dmRhMSBy
byBzd2lvdGxiPTMyLGZvcmNlIHhlbmNvbnM9dHR5CkRlYyAxNiAxNTo1MzoxMSByaWtlciBr
ZXJuZWw6IFhlbi1wcm92aWRlZCBwaHlzaWNhbCBSQU0gbWFwOgpEZWMgMTYgMTU6NTM6MTEg
cmlrZXIga2VybmVsOiBYZW46IDAwMDAwMDAwMDAwMDAwMDAgLSAwMDAwMDAwMDE0ODAwMDAw
ICh1c2FibGUpCkRlYyAxNiAxNTo1MzoxMSByaWtlciBrZXJuZWw6IE5YIChFeGVjdXRlIERp
c2FibGUpIHByb3RlY3Rpb246IGFjdGl2ZQpEZWMgMTYgMTU6NTM6MTEgcmlrZXIga2VybmVs
OiBsYXN0X3BmbiA9IDB4MTQ4MDAgbWF4X2FyY2hfcGZuID0gMHg4MDAwMDAwMApEZWMgMTYg
MTU6NTM6MTEgcmlrZXIga2VybmVsOiBpbml0X21lbW9yeV9tYXBwaW5nOiAwMDAwMDAwMDAw
MDAwMDAwLTAwMDAwMDAwMTQ4MDAwMDAKRGVjIDE2IDE1OjUzOjExIHJpa2VyIGtlcm5lbDog
UkFNRElTSzogMDA3ZmIwMDAgLSAwMTAwNjAwMApEZWMgMTYgMTU6NTM6MTEgcmlrZXIga2Vy
bmVsOiBBQ1BJIGluIHVucHJpdmlsZWdlZCBkb21haW4gZGlzYWJsZWQKRGVjIDE2IDE1OjUz
OjExIHJpa2VyIGtlcm5lbDogWm9uZSBQRk4gcmFuZ2VzOgpEZWMgMTYgMTU6NTM6MTEgcmlr
ZXIga2VybmVsOiAgRE1BICAgICAgMHgwMDAwMDAwMCAtPiAweDAwMDAxMDAwCkRlYyAxNiAx
NTo1MzoxMSByaWtlciBrZXJuZWw6ICBETUEzMiAgICAweDAwMDAxMDAwIC0+IDB4MDAxMDAw
MDAKRGVjIDE2IDE1OjUzOjExIHJpa2VyIGtlcm5lbDogIE5vcm1hbCAgIGVtcHR5CkRlYyAx
NiAxNTo1MzoxMSByaWtlciBrZXJuZWw6IE1vdmFibGUgem9uZSBzdGFydCBQRk4gZm9yIGVh
Y2ggbm9kZQpEZWMgMTYgMTU6NTM6MTEgcmlrZXIga2VybmVsOiBlYXJseV9ub2RlX21hcFsy
XSBhY3RpdmUgUEZOIHJhbmdlcwpEZWMgMTYgMTU6NTM6MTEgcmlrZXIga2VybmVsOiAgICAw
OiAweDAwMDAwMDAwIC0+IDB4MDAwMTQwMDAKRGVjIDE2IDE1OjUzOjExIHJpa2VyIGtlcm5l
bDogICAgMDogMHgwMDAxNDgwMCAtPiAweDAwMDE0ODAwCkRlYyAxNiAxNTo1MzoxMSByaWtl
ciBrZXJuZWw6IHNldHVwX3BlcmNwdTogTlJfQ1BVUzozMiBucl9jcHVtYXNrX2JpdHM6MzIg
bnJfY3B1X2lkczoxIG5yX25vZGVfaWRzOjEKRGVjIDE2IDE1OjUzOjExIHJpa2VyIGtlcm5l
bDogUEVSQ1BVOiBFbWJlZGRlZCAxNyBwYWdlcy9jcHUgQGZmZmY4ODAwMDEwMGEwMDAgczM5
NjU2IHI4MTkyIGQyMTc4NCB1Njk2MzIKRGVjIDE2IDE1OjUzOjExIHJpa2VyIGtlcm5lbDog
cGNwdS1hbGxvYzogczM5NjU2IHI4MTkyIGQyMTc4NCB1Njk2MzIgYWxsb2M9MTcqNDA5NgpE
ZWMgMTYgMTU6NTM6MTEgcmlrZXIga2VybmVsOiBwY3B1LWFsbG9jOiBbMF0gMCAKRGVjIDE2
IDE1OjUzOjExIHJpa2VyIGtlcm5lbDogQnVpbHQgMSB6b25lbGlzdHMgaW4gWm9uZSBvcmRl
ciwgbW9iaWxpdHkgZ3JvdXBpbmcgb24uICBUb3RhbCBwYWdlczogODA3NzIKRGVjIDE2IDE1
OjUzOjExIHJpa2VyIGtlcm5lbDogS2VybmVsIGNvbW1hbmQgbGluZTogcm9vdD0vZGV2L3h2
ZGExIHJvIHN3aW90bGI9MzIsZm9yY2UgeGVuY29ucz10dHkKRGVjIDE2IDE1OjUzOjExIHJp
a2VyIGtlcm5lbDogUElEIGhhc2ggdGFibGUgZW50cmllczogMjA0OCAob3JkZXI6IDIsIDE2
Mzg0IGJ5dGVzKQpEZWMgMTYgMTU6NTM6MTEgcmlrZXIga2VybmVsOiBEZW50cnkgY2FjaGUg
aGFzaCB0YWJsZSBlbnRyaWVzOiA2NTUzNiAob3JkZXI6IDcsIDUyNDI4OCBieXRlcykKRGVj
IDE2IDE1OjUzOjExIHJpa2VyIGtlcm5lbDogSW5vZGUtY2FjaGUgaGFzaCB0YWJsZSBlbnRy
aWVzOiAzMjc2OCAob3JkZXI6IDYsIDI2MjE0NCBieXRlcykKRGVjIDE2IDE1OjUzOjExIHJp
a2VyIGtlcm5lbDogU29mdHdhcmUgSU8gVExCIGVuYWJsZWQ6IApEZWMgMTYgMTU6NTM6MTEg
cmlrZXIga2VybmVsOiBBcGVydHVyZTogICAgIDMyIG1lZ2FieXRlcwpEZWMgMTYgMTU6NTM6
MTEgcmlrZXIga2VybmVsOiBBZGRyZXNzIHNpemU6IDI4IGJpdHMKRGVjIDE2IDE1OjUzOjEx
IHJpa2VyIGtlcm5lbDogS2VybmVsIHJhbmdlOiBmZmZmODgwMDAxNmMzMDAwIC0gZmZmZjg4
MDAwMzZjMzAwMApEZWMgMTYgMTU6NTM6MTEgcmlrZXIga2VybmVsOiBQQ0ktRE1BOiBVc2lu
ZyBzb2Z0d2FyZSBib3VuY2UgYnVmZmVyaW5nIGZvciBJTyAoU1dJT1RMQikKRGVjIDE2IDE1
OjUzOjExIHJpa2VyIGtlcm5lbDogU3VidHJhY3QgKDM1IGVhcmx5IHJlc2VydmF0aW9ucykK
RGVjIDE2IDE1OjUzOjExIHJpa2VyIGtlcm5lbDogICMxIFswMDAwN2ZiMDAwIC0gMDAwMTAw
NjAwMF0gICAgWGVuIHByb3ZpZGVkCkRlYyAxNiAxNTo1MzoxMSByaWtlciBrZXJuZWw6ICAj
MiBbMDAwMDIwMDAwMCAtIDAwMDA3ZGFhOTRdICAgVEVYVCBEQVRBIEJTUwpEZWMgMTYgMTU6
NTM6MTEgcmlrZXIga2VybmVsOiAgIzMgWzAwMDEwYjYwMDAgLSAwMDAxMTVjMDAwXSAgICAg
ICAgIFBHVEFCTEUKRGVjIDE2IDE1OjUzOjExIHJpa2VyIGtlcm5lbDogICM0IFswMDE0MDAw
MDAwIC0gMDAxNDgwMDAwMF0gICAgICAgICBCQUxMT09OCkRlYyAxNiAxNTo1MzoxMSByaWtl
ciBrZXJuZWw6ICAjNSBbMDAwMTE1YzAwMCAtIDAwMDE1ZDgwMDBdICAgICAgICAgQk9PVE1F
TQpEZWMgMTYgMTU6NTM6MTEgcmlrZXIga2VybmVsOiAgIzYgWzAwMDE1ZDgwMDAgLSAwMDAx
NWQ4MDA4XSAgICAgICAgIEJPT1RNRU0KRGVjIDE2IDE1OjUzOjExIHJpa2VyIGtlcm5lbDog
ICM3IFswMDAxNWQ4MDQwIC0gMDAwMTVkODFjMF0gICAgICAgICBCT09UTUVNCkRlYyAxNiAx
NTo1MzoxMSByaWtlciBrZXJuZWw6ICAjOCBbMDAwMTVkODFjMCAtIDAwMDE1ZDgxZTBdICAg
ICAgICAgQk9PVE1FTQpEZWMgMTYgMTU6NTM6MTEgcmlrZXIga2VybmVsOiAgIzkgWzAwMDE1
ZDgyMDAgLSAwMDAxNWRiMjAwXSAgICAgICAgIEJPT1RNRU0KRGVjIDE2IDE1OjUzOjExIHJp
a2VyIGtlcm5lbDogICMxMCBbMDAwMTVkYzAwMCAtIDAwMDE1ZGQwMDBdICAgICAgICAgQk9P
VE1FTQpEZWMgMTYgMTU6NTM6MTEgcmlrZXIga2VybmVsOiAgIzExIFswMDAxNWRkMDAwIC0g
MDAwMTVkZTAwMF0gICAgICAgICBCT09UTUVNCkRlYyAxNiAxNTo1MzoxMSByaWtlciBrZXJu
ZWw6ICAjMTIgWzAwMDE1ZGUwMDAgLSAwMDAxNWRmMDAwXSAgICAgICAgIEJPT1RNRU0KRGVj
IDE2IDE1OjUzOjExIHJpa2VyIGtlcm5lbDogICMxMyBbMDAwMTVkZjAwMCAtIDAwMDE2ODMw
MDBdICAgICAgICAgQk9PVE1FTQpEZWMgMTYgMTU6NTM6MTEgcmlrZXIga2VybmVsOiAgIzE0
IFswMDAxMGE2MDAwIC0gMDAwMTBiNjAwMF0gICAgWGVuIHByb3ZpZGVkCkRlYyAxNiAxNTo1
MzoxMSByaWtlciBrZXJuZWw6ICAjMTUgWzAwMDEwMDYwMDAgLSAwMDAxMDA2MDEwXSAgICAg
ICAgIEJPT1RNRU0KRGVjIDE2IDE1OjUzOjExIHJpa2VyIGtlcm5lbDogICMxNiBbMDAwMTAw
NjA0MCAtIDAwMDEwMDYwNDhdICAgICAgICAgQk9PVE1FTQpEZWMgMTYgMTU6NTM6MTEgcmlr
ZXIga2VybmVsOiAgIzE3IFswMDAxMDA3MDAwIC0gMDAwMTAwODAwMF0gICAgICAgICBCT09U
TUVNCkRlYyAxNiAxNTo1MzoxMSByaWtlciBrZXJuZWw6ICAjMTggWzAwMDEwMDYwODAgLSAw
MDAxMDA2MGIwXSAgICAgICAgIEJPT1RNRU0KRGVjIDE2IDE1OjUzOjExIHJpa2VyIGtlcm5l
bDogICMxOSBbMDAwMTAwNjBjMCAtIDAwMDEwMDYwZjBdICAgICAgICAgQk9PVE1FTQpEZWMg
MTYgMTU6NTM6MTEgcmlrZXIga2VybmVsOiAgIzIwIFswMDAxMDBhMDAwIC0gMDAwMTAxYjAw
MF0gICAgICAgICBCT09UTUVNCkRlYyAxNiAxNTo1MzoxMSByaWtlciBrZXJuZWw6ICAjMjEg
WzAwMDEwMDYxMDAgLSAwMDAxMDA2MTA4XSAgICAgICAgIEJPT1RNRU0KRGVjIDE2IDE1OjUz
OjExIHJpa2VyIGtlcm5lbDogICMyMiBbMDAwMTAwNjE0MCAtIDAwMDEwMDYxNDhdICAgICAg
ICAgQk9PVE1FTQpEZWMgMTYgMTU6NTM6MTEgcmlrZXIga2VybmVsOiAgIzIzIFswMDAxMDA2
MTgwIC0gMDAwMTAwNjE4NF0gICAgICAgICBCT09UTUVNCkRlYyAxNiAxNTo1MzoxMSByaWtl
ciBrZXJuZWw6ICAjMjQgWzAwMDEwMDYxYzAgLSAwMDAxMDA2MWM4XSAgICAgICAgIEJPT1RN
RU0KRGVjIDE2IDE1OjUzOjExIHJpa2VyIGtlcm5lbDogICMyNSBbMDAwMTAwNjIwMCAtIDAw
MDEwMDYzMDBdICAgICAgICAgQk9PVE1FTQpEZWMgMTYgMTU6NTM6MTEgcmlrZXIga2VybmVs
OiAgIzI2IFswMDAxMDA2MzAwIC0gMDAwMTAwNjM0OF0gICAgICAgICBCT09UTUVNCkRlYyAx
NiAxNTo1MzoxMSByaWtlciBrZXJuZWw6ICAjMjcgWzAwMDEwMDYzODAgLSAwMDAxMDA2M2M4
XSAgICAgICAgIEJPT1RNRU0KRGVjIDE2IDE1OjUzOjExIHJpa2VyIGtlcm5lbDogICMyOCBb
MDAwMTAxYjAwMCAtIDAwMDEwMWYwMDBdICAgICAgICAgQk9PVE1FTQpEZWMgMTYgMTU6NTM6
MTEgcmlrZXIga2VybmVsOiAgIzI5IFswMDAxMDFmMDAwIC0gMDAwMTA5ZjAwMF0gICAgICAg
ICBCT09UTUVNCkRlYyAxNiAxNTo1MzoxMSByaWtlciBrZXJuZWw6ICAjMzAgWzAwMDE2ODMw
MDAgLSAwMDAxNmMzMDAwXSAgICAgICAgIEJPT1RNRU0KRGVjIDE2IDE1OjUzOjExIHJpa2Vy
IGtlcm5lbDogICMzMSBbMDAwMTZjMzAwMCAtIDAwMDM2YzMwMDBdICAgICAgICAgQk9PVE1F
TQpEZWMgMTYgMTU6NTM6MTEgcmlrZXIga2VybmVsOiAgIzMyIFswMDAzNmMzMDAwIC0gMDAw
MzZkMzAwMF0gICAgICAgICBCT09UTUVNCkRlYyAxNiAxNTo1MzoxMSByaWtlciBrZXJuZWw6
ICAjMzMgWzAwMDM2ZDMwMDAgLSAwMDAzNmYzMDAwXSAgICAgICAgIEJPT1RNRU0KRGVjIDE2
IDE1OjUzOjExIHJpa2VyIGtlcm5lbDogICMzNCBbMDAwMzZmMzAwMCAtIDAwMDM2ZmIwMDBd
ICAgICAgICAgQk9PVE1FTQpEZWMgMTYgMTU6NTM6MTEgcmlrZXIga2VybmVsOiBNZW1vcnk6
IDI3MzU5MmsvMzM1ODcyayBhdmFpbGFibGUgKDMyMjlrIGtlcm5lbCBjb2RlLCA4MTkyayBh
YnNlbnQsIDU0MDg4ayByZXNlcnZlZCwgMTcyMmsgZGF0YSwgMzIwayBpbml0KQpEZWMgMTYg
MTU6NTM6MTEgcmlrZXIga2VybmVsOiBIaWVyYXJjaGljYWwgUkNVIGltcGxlbWVudGF0aW9u
LgpEZWMgMTYgMTU6NTM6MTEgcmlrZXIga2VybmVsOiBSQ1UtYmFzZWQgZGV0ZWN0aW9uIG9m
IHN0YWxsZWQgQ1BVcyBpcyBlbmFibGVkLgpEZWMgMTYgMTU6NTM6MTEgcmlrZXIga2VybmVs
OiBOUl9JUlFTOjE2MDAKRGVjIDE2IDE1OjUzOjExIHJpa2VyIGtlcm5lbDogWGVuIHJlcG9y
dGVkOiAyMjEwLjAzOCBNSHogcHJvY2Vzc29yLgpEZWMgMTYgMTU6NTM6MTEgcmlrZXIga2Vy
bmVsOiBDb25zb2xlOiBjb2xvdXIgZHVtbXkgZGV2aWNlIDgweDI1CkRlYyAxNiAxNTo1Mzox
MSByaWtlciBrZXJuZWw6IGNvbnNvbGUgW3R0eTBdIGVuYWJsZWQKRGVjIDE2IDE1OjUzOjEx
IHJpa2VyIGtlcm5lbDogY29uc29sZSBbdHR5LTFdIGVuYWJsZWQKRGVjIDE2IDE1OjUzOjEx
IHJpa2VyIGtlcm5lbDogQ2FsaWJyYXRpbmcgZGVsYXkgdXNpbmcgdGltZXIgc3BlY2lmaWMg
cm91dGluZS4uIDQ0NzguNTggQm9nb01JUFMgKGxwaj04OTU3MTczKQpEZWMgMTYgMTU6NTM6
MTEgcmlrZXIga2VybmVsOiBTZWN1cml0eSBGcmFtZXdvcmsgaW5pdGlhbGl6ZWQKRGVjIDE2
IDE1OjUzOjExIHJpa2VyIGtlcm5lbDogU0VMaW51eDogIERpc2FibGVkIGF0IGJvb3QuCkRl
YyAxNiAxNTo1MzoxMSByaWtlciBrZXJuZWw6IE1vdW50LWNhY2hlIGhhc2ggdGFibGUgZW50
cmllczogMjU2CkRlYyAxNiAxNTo1MzoxMSByaWtlciBrZXJuZWw6IFNNUCBhbHRlcm5hdGl2
ZXM6IHN3aXRjaGluZyB0byBVUCBjb2RlCkRlYyAxNiAxNTo1MzoxMSByaWtlciBrZXJuZWw6
IEZyZWVpbmcgU01QIGFsdGVybmF0aXZlczogMzZrIGZyZWVkCkRlYyAxNiAxNTo1MzoxMSBy
aWtlciBrZXJuZWw6IEJyb3VnaHQgdXAgMSBDUFVzCkRlYyAxNiAxNTo1MzoxMSByaWtlciBr
ZXJuZWw6IE5FVDogUmVnaXN0ZXJlZCBwcm90b2NvbCBmYW1pbHkgMTYKRGVjIDE2IDE1OjUz
OjExIHJpa2VyIGtlcm5lbDogQnJvdWdodCB1cCAxIENQVXMKRGVjIDE2IDE1OjUzOjExIHJp
a2VyIGtlcm5lbDogUENJOiBzZXR0aW5nIHVwIFhlbiBQQ0kgZnJvbnRlbmQgc3R1YgpEZWMg
MTYgMTU6NTM6MTEgcmlrZXIga2VybmVsOiBiaW86IGNyZWF0ZSBzbGFiIDxiaW8tMD4gYXQg
MApEZWMgMTYgMTU6NTM6MTEgcmlrZXIga2VybmVsOiBBQ1BJOiBJbnRlcnByZXRlciBkaXNh
YmxlZC4KRGVjIDE2IDE1OjUzOjExIHJpa2VyIGtlcm5lbDogdmdhYXJiOiBsb2FkZWQKRGVj
IDE2IDE1OjUzOjExIHJpa2VyIGtlcm5lbDogeGVuX21lbTogSW5pdGlhbGlzaW5nIGJhbGxv
b24gZHJpdmVyLgpEZWMgMTYgMTU6NTM6MTEgcmlrZXIga2VybmVsOiBTQ1NJIHN1YnN5c3Rl
bSBpbml0aWFsaXplZApEZWMgMTYgMTU6NTM6MTEgcmlrZXIga2VybmVsOiB1c2Jjb3JlOiBy
ZWdpc3RlcmVkIG5ldyBpbnRlcmZhY2UgZHJpdmVyIHVzYmZzCkRlYyAxNiAxNTo1MzoxMSBy
aWtlciBrZXJuZWw6IHVzYmNvcmU6IHJlZ2lzdGVyZWQgbmV3IGludGVyZmFjZSBkcml2ZXIg
aHViCkRlYyAxNiAxNTo1MzoxMSByaWtlciBrZXJuZWw6IHVzYmNvcmU6IHJlZ2lzdGVyZWQg
bmV3IGRldmljZSBkcml2ZXIgdXNiCkRlYyAxNiAxNTo1MzoxMSByaWtlciBrZXJuZWw6IFBD
STogU3lzdGVtIGRvZXMgbm90IHN1cHBvcnQgUENJCkRlYyAxNiAxNTo1MzoxMSByaWtlciBr
ZXJuZWw6IFBDSTogU3lzdGVtIGRvZXMgbm90IHN1cHBvcnQgUENJCkRlYyAxNiAxNTo1Mzox
MSByaWtlciBrZXJuZWw6IE5FVDogUmVnaXN0ZXJlZCBwcm90b2NvbCBmYW1pbHkgOApEZWMg
MTYgMTU6NTM6MTEgcmlrZXIga2VybmVsOiBORVQ6IFJlZ2lzdGVyZWQgcHJvdG9jb2wgZmFt
aWx5IDIwCkRlYyAxNiAxNTo1MzoxMSByaWtlciBrZXJuZWw6IFN3aXRjaGluZyB0byBjbG9j
a3NvdXJjZSB4ZW4KRGVjIDE2IDE1OjUzOjExIHJpa2VyIGtlcm5lbDogcG5wOiBQblAgQUNQ
STogZGlzYWJsZWQKRGVjIDE2IDE1OjUzOjExIHJpa2VyIGtlcm5lbDogTkVUOiBSZWdpc3Rl
cmVkIHByb3RvY29sIGZhbWlseSAyCkRlYyAxNiAxNTo1MzoxMSByaWtlciBrZXJuZWw6IElQ
IHJvdXRlIGNhY2hlIGhhc2ggdGFibGUgZW50cmllczogNDA5NiAob3JkZXI6IDMsIDMyNzY4
IGJ5dGVzKQpEZWMgMTYgMTU6NTM6MTEgcmlrZXIga2VybmVsOiBUQ1AgZXN0YWJsaXNoZWQg
aGFzaCB0YWJsZSBlbnRyaWVzOiAxNjM4NCAob3JkZXI6IDYsIDI2MjE0NCBieXRlcykKRGVj
IDE2IDE1OjUzOjExIHJpa2VyIGtlcm5lbDogVENQIGJpbmQgaGFzaCB0YWJsZSBlbnRyaWVz
OiAxNjM4NCAob3JkZXI6IDYsIDI2MjE0NCBieXRlcykKRGVjIDE2IDE1OjUzOjExIHJpa2Vy
IGtlcm5lbDogVENQOiBIYXNoIHRhYmxlcyBjb25maWd1cmVkIChlc3RhYmxpc2hlZCAxNjM4
NCBiaW5kIDE2Mzg0KQpEZWMgMTYgMTU6NTM6MTEgcmlrZXIga2VybmVsOiBUQ1AgcmVubyBy
ZWdpc3RlcmVkCkRlYyAxNiAxNTo1MzoxMSByaWtlciBrZXJuZWw6IFVEUCBoYXNoIHRhYmxl
IGVudHJpZXM6IDI1NiAob3JkZXI6IDEsIDgxOTIgYnl0ZXMpCkRlYyAxNiAxNTo1MzoxMSBy
aWtlciBrZXJuZWw6IFVEUC1MaXRlIGhhc2ggdGFibGUgZW50cmllczogMjU2IChvcmRlcjog
MSwgODE5MiBieXRlcykKRGVjIDE2IDE1OjUzOjExIHJpa2VyIGtlcm5lbDogTkVUOiBSZWdp
c3RlcmVkIHByb3RvY29sIGZhbWlseSAxCkRlYyAxNiAxNTo1MzoxMSByaWtlciBrZXJuZWw6
IFRyeWluZyB0byB1bnBhY2sgcm9vdGZzIGltYWdlIGFzIGluaXRyYW1mcy4uLgpEZWMgMTYg
MTU6NTM6MTEgcmlrZXIga2VybmVsOiBwY2lmcm9udCBwY2ktMDogSW5zdGFsbGluZyBQQ0kg
ZnJvbnRlbmQKRGVjIDE2IDE1OjUzOjExIHJpa2VyIGtlcm5lbDogcGNpZnJvbnQgcGNpLTA6
IENyZWF0aW5nIFBDSSBGcm9udGVuZCBCdXMgMDAwMDowMApEZWMgMTYgMTU6NTM6MTEgcmlr
ZXIga2VybmVsOiBGcmVlaW5nIGluaXRyZCBtZW1vcnk6IDgyMzZrIGZyZWVkCkRlYyAxNiAx
NTo1MzoxMSByaWtlciBrZXJuZWw6IHBsYXRmb3JtIHJ0Y19jbW9zOiByZWdpc3RlcmVkIHBs
YXRmb3JtIFJUQyBkZXZpY2UgKG5vIFBOUCBkZXZpY2UgZm91bmQpCkRlYyAxNiAxNTo1Mzox
MSByaWtlciBrZXJuZWw6IGF1ZGl0OiBpbml0aWFsaXppbmcgbmV0bGluayBzb2NrZXQgKGRp
c2FibGVkKQpEZWMgMTYgMTU6NTM6MTEgcmlrZXIga2VybmVsOiB0eXBlPTIwMDAgYXVkaXQo
MTMyNDA0NzE4Ni4zMzQ6MSk6IGluaXRpYWxpemVkCkRlYyAxNiAxNTo1MzoxMSByaWtlciBr
ZXJuZWw6IFZGUzogRGlzayBxdW90YXMgZHF1b3RfNi41LjIKRGVjIDE2IDE1OjUzOjExIHJp
a2VyIGtlcm5lbDogRHF1b3QtY2FjaGUgaGFzaCB0YWJsZSBlbnRyaWVzOiA1MTIgKG9yZGVy
IDAsIDQwOTYgYnl0ZXMpCkRlYyAxNiAxNTo1MzoxMSByaWtlciBrZXJuZWw6IE5URlMgZHJp
dmVyIDIuMS4yOSBbRmxhZ3M6IFIvV10uCkRlYyAxNiAxNTo1MzoxMSByaWtlciBrZXJuZWw6
IG1zZ21uaSBoYXMgYmVlbiBzZXQgdG8gNjU2CkRlYyAxNiAxNTo1MzoxMSByaWtlciBrZXJu
ZWw6IGFsZzogTm8gdGVzdCBmb3Igc3Rkcm5nIChrcm5nKQpEZWMgMTYgMTU6NTM6MTEgcmlr
ZXIga2VybmVsOiBCbG9jayBsYXllciBTQ1NJIGdlbmVyaWMgKGJzZykgZHJpdmVyIHZlcnNp
b24gMC40IGxvYWRlZCAobWFqb3IgMjU0KQpEZWMgMTYgMTU6NTM6MTEgcmlrZXIga2VybmVs
OiBpbyBzY2hlZHVsZXIgbm9vcCByZWdpc3RlcmVkCkRlYyAxNiAxNTo1MzoxMSByaWtlciBr
ZXJuZWw6IGlvIHNjaGVkdWxlciBkZWFkbGluZSByZWdpc3RlcmVkCkRlYyAxNiAxNTo1Mzox
MSByaWtlciBrZXJuZWw6IGlvIHNjaGVkdWxlciBjZnEgcmVnaXN0ZXJlZCAoZGVmYXVsdCkK
RGVjIDE2IDE1OjUzOjExIHJpa2VyIGtlcm5lbDogTGludXggYWdwZ2FydCBpbnRlcmZhY2Ug
djAuMTAzCkRlYyAxNiAxNTo1MzoxMSByaWtlciBrZXJuZWw6IGJyZDogbW9kdWxlIGxvYWRl
ZApEZWMgMTYgMTU6NTM6MTEgcmlrZXIga2VybmVsOiBYZW4gdmlydHVhbCBjb25zb2xlIHN1
Y2Nlc3NmdWxseSBpbnN0YWxsZWQgYXMgdHR5MQpEZWMgMTYgMTU6NTM6MTEgcmlrZXIga2Vy
bmVsOiBFdmVudC1jaGFubmVsIGRldmljZSBpbnN0YWxsZWQuCkRlYyAxNiAxNTo1MzoxMSBy
aWtlciBrZXJuZWw6IGJsa3RhcF9kZXZpY2VfaW5pdDogYmxrdGFwIGRldmljZSBtYWpvciAy
NTQKRGVjIDE2IDE1OjUzOjExIHJpa2VyIGtlcm5lbDogYmxrdGFwX3JpbmdfaW5pdDogYmxr
dGFwIHJpbmcgbWFqb3I6IDI1MgpEZWMgMTYgMTU6NTM6MTEgcmlrZXIga2VybmVsOiBuZXRm
cm9udDogSW5pdGlhbGlzaW5nIHZpcnR1YWwgZXRoZXJuZXQgZHJpdmVyLgpEZWMgMTYgMTU6
NTM6MTEgcmlrZXIga2VybmVsOiB4ZW4tdmJkOiByZWdpc3RlcmVkIGJsb2NrIGRldmljZSBt
YWpvciAyMDIKRGVjIDE2IDE1OjUzOjExIHJpa2VyIGtlcm5lbDogYmxrZnJvbnQ6IHh2ZGEx
OiBiYXJyaWVycyBlbmFibGVkCkRlYyAxNiAxNTo1MzoxMSByaWtlciBrZXJuZWw6IGJsa2Zy
b250OiB4dmRhMjogYmFycmllcnMgZW5hYmxlZApEZWMgMTYgMTU6NTM6MTEgcmlrZXIga2Vy
bmVsOiBTZXR0aW5nIGNhcGFjaXR5IHRvIDgzODg2MDgKRGVjIDE2IDE1OjUzOjExIHJpa2Vy
IGtlcm5lbDogeHZkYTE6IGRldGVjdGVkIGNhcGFjaXR5IGNoYW5nZSBmcm9tIDAgdG8gNDI5
NDk2NzI5NgpEZWMgMTYgMTU6NTM6MTEgcmlrZXIga2VybmVsOiBibGtmcm9udDogeHZkYjE6
IGJhcnJpZXJzIGVuYWJsZWQKRGVjIDE2IDE1OjUzOjExIHJpa2VyIGtlcm5lbDogU2V0dGlu
ZyBjYXBhY2l0eSB0byAyMDk3MTUyCkRlYyAxNiAxNTo1MzoxMSByaWtlciBrZXJuZWw6IHh2
ZGEyOiBkZXRlY3RlZCBjYXBhY2l0eSBjaGFuZ2UgZnJvbSAwIHRvIDEwNzM3NDE4MjQKRGVj
IDE2IDE1OjUzOjExIHJpa2VyIGtlcm5lbDogU2V0dGluZyBjYXBhY2l0eSB0byAyOTMwMjcy
MDAyCkRlYyAxNiAxNTo1MzoxMSByaWtlciBrZXJuZWw6IHh2ZGIxOiBkZXRlY3RlZCBjYXBh
Y2l0eSBjaGFuZ2UgZnJvbSAwIHRvIDE1MDAyOTkyNjUwMjQKRGVjIDE2IDE1OjUzOjExIHJp
a2VyIGtlcm5lbDogdXNiY29yZTogcmVnaXN0ZXJlZCBuZXcgaW50ZXJmYWNlIGRyaXZlciB1
c2JiYWNrCkRlYyAxNiAxNTo1MzoxMSByaWtlciBrZXJuZWw6IFBQUCBnZW5lcmljIGRyaXZl
ciB2ZXJzaW9uIDIuNC4yCkRlYyAxNiAxNTo1MzoxMSByaWtlciBrZXJuZWw6IFBOUDogTm8g
UFMvMiBjb250cm9sbGVyIGZvdW5kLiBQcm9iaW5nIHBvcnRzIGRpcmVjdGx5LgpEZWMgMTYg
MTU6NTM6MTEgcmlrZXIga2VybmVsOiBtaWNlOiBQUy8yIG1vdXNlIGRldmljZSBjb21tb24g
Zm9yIGFsbCBtaWNlCkRlYyAxNiAxNTo1MzoxMSByaWtlciBrZXJuZWw6IFRDUCBiaWMgcmVn
aXN0ZXJlZApEZWMgMTYgMTU6NTM6MTEgcmlrZXIga2VybmVsOiBORVQ6IFJlZ2lzdGVyZWQg
cHJvdG9jb2wgZmFtaWx5IDE3CkRlYyAxNiAxNTo1MzoxMSByaWtlciBrZXJuZWw6IFBDSSBJ
TyBtdWx0aXBsZXhlciBkZXZpY2UgaW5zdGFsbGVkLgpEZWMgMTYgMTU6NTM6MTEgcmlrZXIg
a2VybmVsOiBGcmVlaW5nIHVudXNlZCBrZXJuZWwgbWVtb3J5OiAzMjBrIGZyZWVkCkRlYyAx
NiAxNTo1MzoxMSByaWtlciBrZXJuZWw6IGtqb3VybmFsZCBzdGFydGluZy4gIENvbW1pdCBp
bnRlcnZhbCA1IHNlY29uZHMKRGVjIDE2IDE1OjUzOjExIHJpa2VyIGtlcm5lbDogRVhUMy1m
cyAoeHZkYTEpOiBtb3VudGVkIGZpbGVzeXN0ZW0gd2l0aCB3cml0ZWJhY2sgZGF0YSBtb2Rl
CkRlYyAxNiAxNTo1MzoxMSByaWtlciBrZXJuZWw6IHVkZXZbMTc3XTogc3RhcnRpbmcgdmVy
c2lvbiAxNjQKRGVjIDE2IDE1OjUzOjExIHJpa2VyIGtlcm5lbDogTGludXggdmlkZW8gY2Fw
dHVyZSBpbnRlcmZhY2U6IHYyLjAwCkRlYyAxNiAxNTo1MzoxMSByaWtlciBrZXJuZWw6IHNh
YTcxNDY6IHJlZ2lzdGVyIGV4dGVuc2lvbiAnYnVkZ2V0X2F2Jy4KRGVjIDE2IDE1OjUzOjEx
IHJpa2VyIGtlcm5lbDogYnVkZ2V0X2F2IDAwMDA6MDA6MDAuMDogZW5hYmxpbmcgZGV2aWNl
ICgwMDAwIC0+IDAwMDIpCkRlYyAxNiAxNTo1MzoxMSByaWtlciBrZXJuZWw6IElSUSAxNy86
IElSUUZfRElTQUJMRUQgaXMgbm90IGd1YXJhbnRlZWQgb24gc2hhcmVkIElSUXMKRGVjIDE2
IDE1OjUzOjExIHJpa2VyIGtlcm5lbDogc2FhNzE0NjogZm91bmQgc2FhNzE0NiBAIG1lbSBm
ZmZmYzkwMDAwMjQ2MDAwIChyZXZpc2lvbiAxLCBpcnEgMTcpICgweDE4OTQsMHgwMDI4KS4K
RGVjIDE2IDE1OjUzOjExIHJpa2VyIGtlcm5lbDogc2FhNzE0NiAoMCk6IGRtYSBidWZmZXIg
c2l6ZSAxMzQ3NTg0CkRlYyAxNiAxNTo1MzoxMSByaWtlciBrZXJuZWw6IERWQjogcmVnaXN0
ZXJpbmcgbmV3IGFkYXB0ZXIgKEtOQzEgRFZCLUMgTUszKQpEZWMgMTYgMTU6NTM6MTEgcmlr
ZXIga2VybmVsOiBhZGFwdGVyIGZhaWxlZCBNQUMgc2lnbmF0dXJlIGNoZWNrCkRlYyAxNiAx
NTo1MzoxMSByaWtlciBrZXJuZWw6IGVuY29kZWQgTUFDIGZyb20gRUVQUk9NIHdhcyBmZjpm
ZjpmZjpmZjpmZjpmZjpmZjpmZjpmZjpmZjpmZjpmZjpmZjpmZjpmZjpmZjpmZjpmZjpmZjpm
ZgpEZWMgMTYgMTU6NTM6MTEgcmlrZXIga2VybmVsOiBLTkMxLTA6IE1BQyBhZGRyID0gMDA6
MDk6ZDY6NmQ6YjM6MGEKRGVjIDE2IDE1OjUzOjExIHJpa2VyIGtlcm5lbDogRFZCOiByZWdp
c3RlcmluZyBhZGFwdGVyIDAgZnJvbnRlbmQgMCAoUGhpbGlwcyBUREExMDAyMyBEVkItQyku
Li4KRGVjIDE2IDE1OjUzOjExIHJpa2VyIGtlcm5lbDogYnVkZ2V0LWF2OiBjaSBpbnRlcmZh
Y2UgaW5pdGlhbGlzZWQuCkRlYyAxNiAxNTo1MzoxMSByaWtlciBrZXJuZWw6IGJ1ZGdldF9h
diAwMDAwOjAwOjAxLjA6IGVuYWJsaW5nIGRldmljZSAoMDAwMCAtPiAwMDAyKQpEZWMgMTYg
MTU6NTM6MTEgcmlrZXIga2VybmVsOiBJUlEgMTgvOiBJUlFGX0RJU0FCTEVEIGlzIG5vdCBn
dWFyYW50ZWVkIG9uIHNoYXJlZCBJUlFzCkRlYyAxNiAxNTo1MzoxMSByaWtlciBrZXJuZWw6
IHNhYTcxNDY6IGZvdW5kIHNhYTcxNDYgQCBtZW0gZmZmZmM5MDAwMDRkZTAwMCAocmV2aXNp
b24gMSwgaXJxIDE4KSAoMHgxODk0LDB4MDAyYykuCkRlYyAxNiAxNTo1MzoxMSByaWtlciBr
ZXJuZWw6IHNhYTcxNDYgKDEpOiBkbWEgYnVmZmVyIHNpemUgMTM0NzU4NApEZWMgMTYgMTU6
NTM6MTEgcmlrZXIga2VybmVsOiBEVkI6IHJlZ2lzdGVyaW5nIG5ldyBhZGFwdGVyIChTYXRl
bGNvIEVhc3lXYXRjaCBEVkItQyBNSzMpCkRlYyAxNiAxNTo1MzoxMSByaWtlciBrZXJuZWw6
IGFkYXB0ZXIgZmFpbGVkIE1BQyBzaWduYXR1cmUgY2hlY2sKRGVjIDE2IDE1OjUzOjExIHJp
a2VyIGtlcm5lbDogZW5jb2RlZCBNQUMgZnJvbSBFRVBST00gd2FzIGZmOmZmOmZmOmZmOmZm
OmZmOmZmOmZmOmZmOmZmOmZmOmZmOmZmOmZmOmZmOmZmOmZmOmZmOmZmOmZmCkRlYyAxNiAx
NTo1MzoxMSByaWtlciBrZXJuZWw6IEtOQzEtMTogTUFDIGFkZHIgPSAwMDowOTpkNjo2ZDpi
MDozMwpEZWMgMTYgMTU6NTM6MTEgcmlrZXIga2VybmVsOiBEVkI6IHJlZ2lzdGVyaW5nIGFk
YXB0ZXIgMSBmcm9udGVuZCAwIChQaGlsaXBzIFREQTEwMDIzIERWQi1DKS4uLgpEZWMgMTYg
MTU6NTM6MTEgcmlrZXIga2VybmVsOiBidWRnZXQtYXY6IGNpIGludGVyZmFjZSBpbml0aWFs
aXNlZC4KRGVjIDE2IDE1OjUzOjExIHJpa2VyIGtlcm5lbDogQWRkaW5nIDEwNDg1NzJrIHN3
YXAgb24gL2Rldi94dmRhMi4gIFByaW9yaXR5Oi0xIGV4dGVudHM6MSBhY3Jvc3M6MTA0ODU3
MmsgU1MKRGVjIDE2IDE1OjUzOjExIHJpa2VyIGtlcm5lbDogRVhUMy1mcyAoeHZkYTEpOiB3
YXJuaW5nOiBtYXhpbWFsIG1vdW50IGNvdW50IHJlYWNoZWQsIHJ1bm5pbmcgZTJmc2NrIGlz
IHJlY29tbWVuZGVkCkRlYyAxNiAxNTo1MzoxMSByaWtlciBrZXJuZWw6IEVYVDMtZnMgKHh2
ZGExKTogdXNpbmcgaW50ZXJuYWwgam91cm5hbApEZWMgMTYgMTU6NTM6MTEgcmlrZXIga2Vy
bmVsOiBram91cm5hbGQgc3RhcnRpbmcuICBDb21taXQgaW50ZXJ2YWwgNSBzZWNvbmRzCkRl
YyAxNiAxNTo1MzoxMSByaWtlciBrZXJuZWw6IEVYVDMtZnMgKHh2ZGIxKTogd2FybmluZzog
bWF4aW1hbCBtb3VudCBjb3VudCByZWFjaGVkLCBydW5uaW5nIGUyZnNjayBpcyByZWNvbW1l
bmRlZApEZWMgMTYgMTU6NTM6MTEgcmlrZXIga2VybmVsOiBFWFQzLWZzICh4dmRiMSk6IHVz
aW5nIGludGVybmFsIGpvdXJuYWwKRGVjIDE2IDE1OjUzOjExIHJpa2VyIGtlcm5lbDogRVhU
My1mcyAoeHZkYjEpOiBtb3VudGVkIGZpbGVzeXN0ZW0gd2l0aCB3cml0ZWJhY2sgZGF0YSBt
b2RlCkRlYyAxNiAxNTo1MzoxMSByaWtlciBrZXJuZWw6IFJQQzogUmVnaXN0ZXJlZCB1ZHAg
dHJhbnNwb3J0IG1vZHVsZS4KRGVjIDE2IDE1OjUzOjExIHJpa2VyIGtlcm5lbDogUlBDOiBS
ZWdpc3RlcmVkIHRjcCB0cmFuc3BvcnQgbW9kdWxlLgpEZWMgMTYgMTU6NTM6MTEgcmlrZXIg
a2VybmVsOiBSUEM6IFJlZ2lzdGVyZWQgdGNwIE5GU3Y0LjEgYmFja2NoYW5uZWwgdHJhbnNw
b3J0IG1vZHVsZS4KRGVjIDE2IDE1OjUzOjExIHJpa2VyIGtlcm5lbDogSW5zdGFsbGluZyBr
bmZzZCAoY29weXJpZ2h0IChDKSAxOTk2IG9raXJAbW9uYWQuc3diLmRlKS4KRGVjIDE2IDE1
OjUzOjExIHJpa2VyIGtlcm5lbDogTkVUOiBSZWdpc3RlcmVkIHByb3RvY29sIGZhbWlseSAx
MApEZWMgMTYgMTU6NTM6MTEgcmlrZXIga2VybmVsOiBsbzogRGlzYWJsZWQgUHJpdmFjeSBF
eHRlbnNpb25zCkRlYyAxNiAxNTo1MzoxMSByaWtlciBrZXJuZWw6IHN2YzogZmFpbGVkIHRv
IHJlZ2lzdGVyIGxvY2tkdjEgUlBDIHNlcnZpY2UgKGVycm5vIDk3KS4KRGVjIDE2IDE1OjUz
OjExIHJpa2VyIGtlcm5lbDogTkZTRDogVXNpbmcgL3Zhci9saWIvbmZzL3Y0cmVjb3Zlcnkg
YXMgdGhlIE5GU3Y0IHN0YXRlIHJlY292ZXJ5IGRpcmVjdG9yeQpEZWMgMTYgMTU6NTM6MTEg
cmlrZXIga2VybmVsOiBORlNEOiBzdGFydGluZyA5MC1zZWNvbmQgZ3JhY2UgcGVyaW9kCkRl
YyAxNiAxNTo1MzoyOSByaWtlciBrZXJuZWw6IFN0YXJ0aW5nIFNXSU9UTEIgZGVidWcgdGhy
ZWFkLgpEZWMgMTYgMTU6NTM6MjkgcmlrZXIga2VybmVsOiBzd2lvdGxiX3N0YXJ0X3RocmVh
ZDogR28hCkRlYyAxNiAxNTo1MzozNCByaWtlciBrZXJuZWw6IFNXSU9UTEIgaXMgMCUgZnVs
bApEZWMgMTYgMTU6NTM6MzkgcmlrZXIga2VybmVsOiBTV0lPVExCIGlzIDAlIGZ1bGwKRGVj
IDE2IDE1OjUzOjQ0IHJpa2VyIGtlcm5lbDogU1dJT1RMQiBpcyAwJSBmdWxsCkRlYyAxNiAx
NTo1Mzo0OSByaWtlciBrZXJuZWw6IFNXSU9UTEIgaXMgMCUgZnVsbApEZWMgMTYgMTU6NTM6
NTQgcmlrZXIga2VybmVsOiBTV0lPVExCIGlzIDAlIGZ1bGwKRGVjIDE2IDE1OjUzOjU5IHJp
a2VyIGtlcm5lbDogU1dJT1RMQiBpcyAwJSBmdWxsCkRlYyAxNiAxNTo1NDowNCByaWtlciBr
ZXJuZWw6IFNXSU9UTEIgaXMgMCUgZnVsbApEZWMgMTYgMTU6NTQ6MDkgcmlrZXIga2VybmVs
OiBTV0lPVExCIGlzIDAlIGZ1bGwKRGVjIDE2IDE1OjU0OjE0IHJpa2VyIGtlcm5lbDogU1dJ
T1RMQiBpcyAwJSBmdWxsCkRlYyAxNiAxNTo1NDoxOSByaWtlciBrZXJuZWw6IFNXSU9UTEIg
aXMgMCUgZnVsbApEZWMgMTYgMTU6NTQ6MjQgcmlrZXIga2VybmVsOiBTV0lPVExCIGlzIDAl
IGZ1bGwKRGVjIDE2IDE1OjU0OjI5IHJpa2VyIGtlcm5lbDogU1dJT1RMQiBpcyAwJSBmdWxs
CkRlYyAxNiAxNTo1NDozNCByaWtlciBrZXJuZWw6IFNXSU9UTEIgaXMgMCUgZnVsbApEZWMg
MTYgMTU6NTQ6MzkgcmlrZXIga2VybmVsOiBTV0lPVExCIGlzIDAlIGZ1bGwKRGVjIDE2IDE1
OjU0OjQ0IHJpa2VyIGtlcm5lbDogU1dJT1RMQiBpcyAwJSBmdWxsCkRlYyAxNiAxNTo1NDo0
OSByaWtlciBrZXJuZWw6IFNXSU9UTEIgaXMgMCUgZnVsbApEZWMgMTYgMTU6NTQ6NTQgcmlr
ZXIga2VybmVsOiBTV0lPVExCIGlzIDAlIGZ1bGwKRGVjIDE2IDE1OjU0OjU5IHJpa2VyIGtl
cm5lbDogU1dJT1RMQiBpcyAwJSBmdWxsCkRlYyAxNiAxNTo1NTowNCByaWtlciBrZXJuZWw6
IFNXSU9UTEIgaXMgMCUgZnVsbApEZWMgMTYgMTU6NTU6MDkgcmlrZXIga2VybmVsOiBTV0lP
VExCIGlzIDAlIGZ1bGwKRGVjIDE2IDE1OjU1OjE0IHJpa2VyIGtlcm5lbDogU1dJT1RMQiBp
cyAwJSBmdWxsCkRlYyAxNiAxNTo1NToxOSByaWtlciBrZXJuZWw6IFNXSU9UTEIgaXMgMCUg
ZnVsbApEZWMgMTYgMTU6NTU6MjQgcmlrZXIga2VybmVsOiBTV0lPVExCIGlzIDAlIGZ1bGwK
RGVjIDE2IDE1OjU1OjI5IHJpa2VyIGtlcm5lbDogU1dJT1RMQiBpcyAwJSBmdWxsCkRlYyAx
NiAxNTo1NTozNCByaWtlciBrZXJuZWw6IFNXSU9UTEIgaXMgMCUgZnVsbApEZWMgMTYgMTU6
NTU6MzkgcmlrZXIga2VybmVsOiBTV0lPVExCIGlzIDAlIGZ1bGwKRGVjIDE2IDE1OjU1OjQz
IHJpa2VyIGtlcm5lbDogU1dJT1RMQiBpcyAwJSBmdWxsCkRlYyAxNiAxNTo1NTo0OCByaWtl
ciBrZXJuZWw6IFNXSU9UTEIgaXMgMCUgZnVsbApEZWMgMTYgMTU6NTU6NTMgcmlrZXIga2Vy
bmVsOiBTV0lPVExCIGlzIDAlIGZ1bGwKRGVjIDE2IDE1OjU1OjU4IHJpa2VyIGtlcm5lbDog
U1dJT1RMQiBpcyAwJSBmdWxsCkRlYyAxNiAxNTo1NjowMyByaWtlciBrZXJuZWw6IFNXSU9U
TEIgaXMgMCUgZnVsbApEZWMgMTYgMTU6NTY6MDggcmlrZXIga2VybmVsOiBTV0lPVExCIGlz
IDAlIGZ1bGwKRGVjIDE2IDE1OjU2OjEzIHJpa2VyIGtlcm5lbDogU1dJT1RMQiBpcyAwJSBm
dWxsCkRlYyAxNiAxNTo1NjoxOCByaWtlciBrZXJuZWw6IFNXSU9UTEIgaXMgMCUgZnVsbApE
ZWMgMTYgMTU6NTY6MjMgcmlrZXIga2VybmVsOiBTV0lPVExCIGlzIDAlIGZ1bGwKRGVjIDE2
IDE1OjU2OjI4IHJpa2VyIGtlcm5lbDogU1dJT1RMQiBpcyAwJSBmdWxsCkRlYyAxNiAxNTo1
NjozMyByaWtlciBrZXJuZWw6IFNXSU9UTEIgaXMgMCUgZnVsbApEZWMgMTYgMTU6NTY6MzYg
cmlrZXIga2VybmVsOiBzd2lvdGxiX3N0b3BfdGhyZWFkOiBTdG9wIQpEZWMgMTYgMTU6NTY6
MzYgcmlrZXIga2VybmVsOiBTV0lPVExCIGlzIDAlIGZ1bGwKRGVjIDE2IDE1OjU3OjIyIHJp
a2VyIHNodXRkb3duWzEyODFdOiBzaHV0dGluZyBkb3duIGZvciBzeXN0ZW0gaGFsdApEZWMg
MTYgMTU6NTc6MjMgcmlrZXIga2VybmVsOiBuZnNkOiBsYXN0IHNlcnZlciBoYXMgZXhpdGVk
LCBmbHVzaGluZyBleHBvcnQgY2FjaGUKRGVjIDE2IDE1OjU3OjI1IHJpa2VyIGtlcm5lbDog
S2VybmVsIGxvZ2dpbmcgKHByb2MpIHN0b3BwZWQuCkRlYyAxNiAxNTo1NzoyNSByaWtlciBy
c3lzbG9nZDogW29yaWdpbiBzb2Z0d2FyZT0icnN5c2xvZ2QiIHN3VmVyc2lvbj0iNC42LjQi
IHgtcGlkPSI2MTAiIHgtaW5mbz0iaHR0cDovL3d3dy5yc3lzbG9nLmNvbSJdIGV4aXRpbmcg
b24gc2lnbmFsIDE1LgpEZWMgMTYgMTU6NTg6MDAgcmlrZXIga2VybmVsOiBpbWtsb2cgNC42
LjQsIGxvZyBzb3VyY2UgPSAvcHJvYy9rbXNnIHN0YXJ0ZWQuCkRlYyAxNiAxNTo1ODowMCBy
aWtlciByc3lzbG9nZDogW29yaWdpbiBzb2Z0d2FyZT0icnN5c2xvZ2QiIHN3VmVyc2lvbj0i
NC42LjQiIHgtcGlkPSI2MTQiIHgtaW5mbz0iaHR0cDovL3d3dy5yc3lzbG9nLmNvbSJdIChy
ZSlzdGFydAoKIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIG5vcm1hbCBib290
ICMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMKCkRlYyAxNiAx
NTo1ODowMCByaWtlciBrZXJuZWw6IExpbnV4IHZlcnNpb24gMi42LjM0LjcuMS14ZW4tYW1k
NjQgKHJvb3RAY2hla290ZXkpIChnY2MgdmVyc2lvbiA0LjQuNSAoRGViaWFuIDQuNC41LTgp
ICkgIzYgU01QIFdlZCBBdWcgMTcgMTE6NDk6NTMgQ0VTVCAyMDExCkRlYyAxNiAxNTo1ODow
MCByaWtlciBrZXJuZWw6IENvbW1hbmQgbGluZTogcm9vdD0vZGV2L3h2ZGExIHJvIHN3aW90
bGI9MzIsZm9yY2UgeGVuY29ucz10dHkKRGVjIDE2IDE1OjU4OjAwIHJpa2VyIGtlcm5lbDog
WGVuLXByb3ZpZGVkIHBoeXNpY2FsIFJBTSBtYXA6CkRlYyAxNiAxNTo1ODowMCByaWtlciBr
ZXJuZWw6IFhlbjogMDAwMDAwMDAwMDAwMDAwMCAtIDAwMDAwMDAwMTQ4MDAwMDAgKHVzYWJs
ZSkKRGVjIDE2IDE1OjU4OjAwIHJpa2VyIGtlcm5lbDogTlggKEV4ZWN1dGUgRGlzYWJsZSkg
cHJvdGVjdGlvbjogYWN0aXZlCkRlYyAxNiAxNTo1ODowMCByaWtlciBrZXJuZWw6IGxhc3Rf
cGZuID0gMHgxNDgwMCBtYXhfYXJjaF9wZm4gPSAweDgwMDAwMDAwCkRlYyAxNiAxNTo1ODow
MCByaWtlciBrZXJuZWw6IGluaXRfbWVtb3J5X21hcHBpbmc6IDAwMDAwMDAwMDAwMDAwMDAt
MDAwMDAwMDAxNDgwMDAwMApEZWMgMTYgMTU6NTg6MDAgcmlrZXIga2VybmVsOiBSQU1ESVNL
OiAwMDdmYjAwMCAtIDAxMDA2MDAwCkRlYyAxNiAxNTo1ODowMCByaWtlciBrZXJuZWw6IEFD
UEkgaW4gdW5wcml2aWxlZ2VkIGRvbWFpbiBkaXNhYmxlZApEZWMgMTYgMTU6NTg6MDAgcmlr
ZXIga2VybmVsOiBab25lIFBGTiByYW5nZXM6CkRlYyAxNiAxNTo1ODowMCByaWtlciBrZXJu
ZWw6ICBETUEgICAgICAweDAwMDAwMDAwIC0+IDB4MDAwMDEwMDAKRGVjIDE2IDE1OjU4OjAw
IHJpa2VyIGtlcm5lbDogIERNQTMyICAgIDB4MDAwMDEwMDAgLT4gMHgwMDEwMDAwMApEZWMg
MTYgMTU6NTg6MDAgcmlrZXIga2VybmVsOiAgTm9ybWFsICAgZW1wdHkKRGVjIDE2IDE1OjU4
OjAwIHJpa2VyIGtlcm5lbDogTW92YWJsZSB6b25lIHN0YXJ0IFBGTiBmb3IgZWFjaCBub2Rl
CkRlYyAxNiAxNTo1ODowMCByaWtlciBrZXJuZWw6IGVhcmx5X25vZGVfbWFwWzJdIGFjdGl2
ZSBQRk4gcmFuZ2VzCkRlYyAxNiAxNTo1ODowMCByaWtlciBrZXJuZWw6ICAgIDA6IDB4MDAw
MDAwMDAgLT4gMHgwMDAxNDAwMApEZWMgMTYgMTU6NTg6MDAgcmlrZXIga2VybmVsOiAgICAw
OiAweDAwMDE0ODAwIC0+IDB4MDAwMTQ4MDAKRGVjIDE2IDE1OjU4OjAwIHJpa2VyIGtlcm5l
bDogc2V0dXBfcGVyY3B1OiBOUl9DUFVTOjMyIG5yX2NwdW1hc2tfYml0czozMiBucl9jcHVf
aWRzOjEgbnJfbm9kZV9pZHM6MQpEZWMgMTYgMTU6NTg6MDAgcmlrZXIga2VybmVsOiBQRVJD
UFU6IEVtYmVkZGVkIDE3IHBhZ2VzL2NwdSBAZmZmZjg4MDAwMTAwYTAwMCBzMzk1OTIgcjgx
OTIgZDIxODQ4IHU2OTYzMgpEZWMgMTYgMTU6NTg6MDAgcmlrZXIga2VybmVsOiBwY3B1LWFs
bG9jOiBzMzk1OTIgcjgxOTIgZDIxODQ4IHU2OTYzMiBhbGxvYz0xNyo0MDk2CkRlYyAxNiAx
NTo1ODowMCByaWtlciBrZXJuZWw6IHBjcHUtYWxsb2M6IFswXSAwIApEZWMgMTYgMTU6NTg6
MDAgcmlrZXIga2VybmVsOiBCdWlsdCAxIHpvbmVsaXN0cyBpbiBab25lIG9yZGVyLCBtb2Jp
bGl0eSBncm91cGluZyBvbi4gIFRvdGFsIHBhZ2VzOiA4MDc3MgpEZWMgMTYgMTU6NTg6MDAg
cmlrZXIga2VybmVsOiBLZXJuZWwgY29tbWFuZCBsaW5lOiByb290PS9kZXYveHZkYTEgcm8g
c3dpb3RsYj0zMixmb3JjZSB4ZW5jb25zPXR0eQpEZWMgMTYgMTU6NTg6MDAgcmlrZXIga2Vy
bmVsOiBQSUQgaGFzaCB0YWJsZSBlbnRyaWVzOiAyMDQ4IChvcmRlcjogMiwgMTYzODQgYnl0
ZXMpCkRlYyAxNiAxNTo1ODowMCByaWtlciBrZXJuZWw6IERlbnRyeSBjYWNoZSBoYXNoIHRh
YmxlIGVudHJpZXM6IDY1NTM2IChvcmRlcjogNywgNTI0Mjg4IGJ5dGVzKQpEZWMgMTYgMTU6
NTg6MDAgcmlrZXIga2VybmVsOiBJbm9kZS1jYWNoZSBoYXNoIHRhYmxlIGVudHJpZXM6IDMy
NzY4IChvcmRlcjogNiwgMjYyMTQ0IGJ5dGVzKQpEZWMgMTYgMTU6NTg6MDAgcmlrZXIga2Vy
bmVsOiBTb2Z0d2FyZSBJTyBUTEIgZW5hYmxlZDogCkRlYyAxNiAxNTo1ODowMCByaWtlciBr
ZXJuZWw6IEFwZXJ0dXJlOiAgICAgMzIgbWVnYWJ5dGVzCkRlYyAxNiAxNTo1ODowMCByaWtl
ciBrZXJuZWw6IEFkZHJlc3Mgc2l6ZTogMjggYml0cwpEZWMgMTYgMTU6NTg6MDAgcmlrZXIg
a2VybmVsOiBLZXJuZWwgcmFuZ2U6IGZmZmY4ODAwMDE2YzMwMDAgLSBmZmZmODgwMDAzNmMz
MDAwCkRlYyAxNiAxNTo1ODowMCByaWtlciBrZXJuZWw6IFBDSS1ETUE6IFVzaW5nIHNvZnR3
YXJlIGJvdW5jZSBidWZmZXJpbmcgZm9yIElPIChTV0lPVExCKQpEZWMgMTYgMTU6NTg6MDAg
cmlrZXIga2VybmVsOiBTdWJ0cmFjdCAoMzUgZWFybHkgcmVzZXJ2YXRpb25zKQpEZWMgMTYg
MTU6NTg6MDAgcmlrZXIga2VybmVsOiAgIzEgWzAwMDA3ZmIwMDAgLSAwMDAxMDA2MDAwXSAg
ICBYZW4gcHJvdmlkZWQKRGVjIDE2IDE1OjU4OjAwIHJpa2VyIGtlcm5lbDogICMyIFswMDAw
MjAwMDAwIC0gMDAwMDdkYWE5NF0gICBURVhUIERBVEEgQlNTCkRlYyAxNiAxNTo1ODowMCBy
aWtlciBrZXJuZWw6ICAjMyBbMDAwMTBiNjAwMCAtIDAwMDExNWMwMDBdICAgICAgICAgUEdU
QUJMRQpEZWMgMTYgMTU6NTg6MDAgcmlrZXIga2VybmVsOiAgIzQgWzAwMTQwMDAwMDAgLSAw
MDE0ODAwMDAwXSAgICAgICAgIEJBTExPT04KRGVjIDE2IDE1OjU4OjAwIHJpa2VyIGtlcm5l
bDogICM1IFswMDAxMTVjMDAwIC0gMDAwMTVkODAwMF0gICAgICAgICBCT09UTUVNCkRlYyAx
NiAxNTo1ODowMCByaWtlciBrZXJuZWw6ICAjNiBbMDAwMTVkODAwMCAtIDAwMDE1ZDgwMDhd
ICAgICAgICAgQk9PVE1FTQpEZWMgMTYgMTU6NTg6MDAgcmlrZXIga2VybmVsOiAgIzcgWzAw
MDE1ZDgwNDAgLSAwMDAxNWQ4MWMwXSAgICAgICAgIEJPT1RNRU0KRGVjIDE2IDE1OjU4OjAw
IHJpa2VyIGtlcm5lbDogICM4IFswMDAxNWQ4MWMwIC0gMDAwMTVkODFlMF0gICAgICAgICBC
T09UTUVNCkRlYyAxNiAxNTo1ODowMCByaWtlciBrZXJuZWw6ICAjOSBbMDAwMTVkODIwMCAt
IDAwMDE1ZGIyMDBdICAgICAgICAgQk9PVE1FTQpEZWMgMTYgMTU6NTg6MDAgcmlrZXIga2Vy
bmVsOiAgIzEwIFswMDAxNWRjMDAwIC0gMDAwMTVkZDAwMF0gICAgICAgICBCT09UTUVNCkRl
YyAxNiAxNTo1ODowMCByaWtlciBrZXJuZWw6ICAjMTEgWzAwMDE1ZGQwMDAgLSAwMDAxNWRl
MDAwXSAgICAgICAgIEJPT1RNRU0KRGVjIDE2IDE1OjU4OjAwIHJpa2VyIGtlcm5lbDogICMx
MiBbMDAwMTVkZTAwMCAtIDAwMDE1ZGYwMDBdICAgICAgICAgQk9PVE1FTQpEZWMgMTYgMTU6
NTg6MDAgcmlrZXIga2VybmVsOiAgIzEzIFswMDAxNWRmMDAwIC0gMDAwMTY4MzAwMF0gICAg
ICAgICBCT09UTUVNCkRlYyAxNiAxNTo1ODowMCByaWtlciBrZXJuZWw6ICAjMTQgWzAwMDEw
YTYwMDAgLSAwMDAxMGI2MDAwXSAgICBYZW4gcHJvdmlkZWQKRGVjIDE2IDE1OjU4OjAwIHJp
a2VyIGtlcm5lbDogICMxNSBbMDAwMTAwNjAwMCAtIDAwMDEwMDYwMTBdICAgICAgICAgQk9P
VE1FTQpEZWMgMTYgMTU6NTg6MDAgcmlrZXIga2VybmVsOiAgIzE2IFswMDAxMDA2MDQwIC0g
MDAwMTAwNjA0OF0gICAgICAgICBCT09UTUVNCkRlYyAxNiAxNTo1ODowMCByaWtlciBrZXJu
ZWw6ICAjMTcgWzAwMDEwMDcwMDAgLSAwMDAxMDA4MDAwXSAgICAgICAgIEJPT1RNRU0KRGVj
IDE2IDE1OjU4OjAwIHJpa2VyIGtlcm5lbDogICMxOCBbMDAwMTAwNjA4MCAtIDAwMDEwMDYw
YjBdICAgICAgICAgQk9PVE1FTQpEZWMgMTYgMTU6NTg6MDAgcmlrZXIga2VybmVsOiAgIzE5
IFswMDAxMDA2MGMwIC0gMDAwMTAwNjBmMF0gICAgICAgICBCT09UTUVNCkRlYyAxNiAxNTo1
ODowMCByaWtlciBrZXJuZWw6ICAjMjAgWzAwMDEwMGEwMDAgLSAwMDAxMDFiMDAwXSAgICAg
ICAgIEJPT1RNRU0KRGVjIDE2IDE1OjU4OjAwIHJpa2VyIGtlcm5lbDogICMyMSBbMDAwMTAw
NjEwMCAtIDAwMDEwMDYxMDhdICAgICAgICAgQk9PVE1FTQpEZWMgMTYgMTU6NTg6MDAgcmlr
ZXIga2VybmVsOiAgIzIyIFswMDAxMDA2MTQwIC0gMDAwMTAwNjE0OF0gICAgICAgICBCT09U
TUVNCkRlYyAxNiAxNTo1ODowMCByaWtlciBrZXJuZWw6ICAjMjMgWzAwMDEwMDYxODAgLSAw
MDAxMDA2MTg0XSAgICAgICAgIEJPT1RNRU0KRGVjIDE2IDE1OjU4OjAwIHJpa2VyIGtlcm5l
bDogICMyNCBbMDAwMTAwNjFjMCAtIDAwMDEwMDYxYzhdICAgICAgICAgQk9PVE1FTQpEZWMg
MTYgMTU6NTg6MDAgcmlrZXIga2VybmVsOiAgIzI1IFswMDAxMDA2MjAwIC0gMDAwMTAwNjMw
MF0gICAgICAgICBCT09UTUVNCkRlYyAxNiAxNTo1ODowMCByaWtlciBrZXJuZWw6ICAjMjYg
WzAwMDEwMDYzMDAgLSAwMDAxMDA2MzQ4XSAgICAgICAgIEJPT1RNRU0KRGVjIDE2IDE1OjU4
OjAwIHJpa2VyIGtlcm5lbDogICMyNyBbMDAwMTAwNjM4MCAtIDAwMDEwMDYzYzhdICAgICAg
ICAgQk9PVE1FTQpEZWMgMTYgMTU6NTg6MDAgcmlrZXIga2VybmVsOiAgIzI4IFswMDAxMDFi
MDAwIC0gMDAwMTAxZjAwMF0gICAgICAgICBCT09UTUVNCkRlYyAxNiAxNTo1ODowMCByaWtl
ciBrZXJuZWw6ICAjMjkgWzAwMDEwMWYwMDAgLSAwMDAxMDlmMDAwXSAgICAgICAgIEJPT1RN
RU0KRGVjIDE2IDE1OjU4OjAwIHJpa2VyIGtlcm5lbDogICMzMCBbMDAwMTY4MzAwMCAtIDAw
MDE2YzMwMDBdICAgICAgICAgQk9PVE1FTQpEZWMgMTYgMTU6NTg6MDAgcmlrZXIga2VybmVs
OiAgIzMxIFswMDAxNmMzMDAwIC0gMDAwMzZjMzAwMF0gICAgICAgICBCT09UTUVNCkRlYyAx
NiAxNTo1ODowMCByaWtlciBrZXJuZWw6ICAjMzIgWzAwMDM2YzMwMDAgLSAwMDAzNmQzMDAw
XSAgICAgICAgIEJPT1RNRU0KRGVjIDE2IDE1OjU4OjAwIHJpa2VyIGtlcm5lbDogICMzMyBb
MDAwMzZkMzAwMCAtIDAwMDM2ZjMwMDBdICAgICAgICAgQk9PVE1FTQpEZWMgMTYgMTU6NTg6
MDAgcmlrZXIga2VybmVsOiAgIzM0IFswMDAzNmYzMDAwIC0gMDAwMzZmYjAwMF0gICAgICAg
ICBCT09UTUVNCkRlYyAxNiAxNTo1ODowMCByaWtlciBrZXJuZWw6IE1lbW9yeTogMjczNTky
ay8zMzU4NzJrIGF2YWlsYWJsZSAoMzIyOGsga2VybmVsIGNvZGUsIDgxOTJrIGFic2VudCwg
NTQwODhrIHJlc2VydmVkLCAxNzIzayBkYXRhLCAzMjBrIGluaXQpCkRlYyAxNiAxNTo1ODow
MCByaWtlciBrZXJuZWw6IEhpZXJhcmNoaWNhbCBSQ1UgaW1wbGVtZW50YXRpb24uCkRlYyAx
NiAxNTo1ODowMCByaWtlciBrZXJuZWw6IFJDVS1iYXNlZCBkZXRlY3Rpb24gb2Ygc3RhbGxl
ZCBDUFVzIGlzIGVuYWJsZWQuCkRlYyAxNiAxNTo1ODowMCByaWtlciBrZXJuZWw6IE5SX0lS
UVM6MTYwMApEZWMgMTYgMTU6NTg6MDAgcmlrZXIga2VybmVsOiBYZW4gcmVwb3J0ZWQ6IDIy
MTAuMDM4IE1IeiBwcm9jZXNzb3IuCkRlYyAxNiAxNTo1ODowMCByaWtlciBrZXJuZWw6IENv
bnNvbGU6IGNvbG91ciBkdW1teSBkZXZpY2UgODB4MjUKRGVjIDE2IDE1OjU4OjAwIHJpa2Vy
IGtlcm5lbDogY29uc29sZSBbdHR5MF0gZW5hYmxlZApEZWMgMTYgMTU6NTg6MDAgcmlrZXIg
a2VybmVsOiBjb25zb2xlIFt0dHktMV0gZW5hYmxlZApEZWMgMTYgMTU6NTg6MDAgcmlrZXIg
a2VybmVsOiBDYWxpYnJhdGluZyBkZWxheSB1c2luZyB0aW1lciBzcGVjaWZpYyByb3V0aW5l
Li4gNDQ3OC42MyBCb2dvTUlQUyAobHBqPTg5NTcyNzYpCkRlYyAxNiAxNTo1ODowMCByaWtl
ciBrZXJuZWw6IFNlY3VyaXR5IEZyYW1ld29yayBpbml0aWFsaXplZApEZWMgMTYgMTU6NTg6
MDAgcmlrZXIga2VybmVsOiBTRUxpbnV4OiAgRGlzYWJsZWQgYXQgYm9vdC4KRGVjIDE2IDE1
OjU4OjAwIHJpa2VyIGtlcm5lbDogTW91bnQtY2FjaGUgaGFzaCB0YWJsZSBlbnRyaWVzOiAy
NTYKRGVjIDE2IDE1OjU4OjAwIHJpa2VyIGtlcm5lbDogU01QIGFsdGVybmF0aXZlczogc3dp
dGNoaW5nIHRvIFVQIGNvZGUKRGVjIDE2IDE1OjU4OjAwIHJpa2VyIGtlcm5lbDogRnJlZWlu
ZyBTTVAgYWx0ZXJuYXRpdmVzOiAzNmsgZnJlZWQKRGVjIDE2IDE1OjU4OjAwIHJpa2VyIGtl
cm5lbDogQnJvdWdodCB1cCAxIENQVXMKRGVjIDE2IDE1OjU4OjAwIHJpa2VyIGtlcm5lbDog
TkVUOiBSZWdpc3RlcmVkIHByb3RvY29sIGZhbWlseSAxNgpEZWMgMTYgMTU6NTg6MDAgcmlr
ZXIga2VybmVsOiBCcm91Z2h0IHVwIDEgQ1BVcwpEZWMgMTYgMTU6NTg6MDAgcmlrZXIga2Vy
bmVsOiBQQ0k6IHNldHRpbmcgdXAgWGVuIFBDSSBmcm9udGVuZCBzdHViCkRlYyAxNiAxNTo1
ODowMCByaWtlciBrZXJuZWw6IGJpbzogY3JlYXRlIHNsYWIgPGJpby0wPiBhdCAwCkRlYyAx
NiAxNTo1ODowMCByaWtlciBrZXJuZWw6IEFDUEk6IEludGVycHJldGVyIGRpc2FibGVkLgpE
ZWMgMTYgMTU6NTg6MDAgcmlrZXIga2VybmVsOiB2Z2FhcmI6IGxvYWRlZApEZWMgMTYgMTU6
NTg6MDAgcmlrZXIga2VybmVsOiB4ZW5fbWVtOiBJbml0aWFsaXNpbmcgYmFsbG9vbiBkcml2
ZXIuCkRlYyAxNiAxNTo1ODowMCByaWtlciBrZXJuZWw6IFNDU0kgc3Vic3lzdGVtIGluaXRp
YWxpemVkCkRlYyAxNiAxNTo1ODowMCByaWtlciBrZXJuZWw6IHVzYmNvcmU6IHJlZ2lzdGVy
ZWQgbmV3IGludGVyZmFjZSBkcml2ZXIgdXNiZnMKRGVjIDE2IDE1OjU4OjAwIHJpa2VyIGtl
cm5lbDogdXNiY29yZTogcmVnaXN0ZXJlZCBuZXcgaW50ZXJmYWNlIGRyaXZlciBodWIKRGVj
IDE2IDE1OjU4OjAwIHJpa2VyIGtlcm5lbDogdXNiY29yZTogcmVnaXN0ZXJlZCBuZXcgZGV2
aWNlIGRyaXZlciB1c2IKRGVjIDE2IDE1OjU4OjAwIHJpa2VyIGtlcm5lbDogUENJOiBTeXN0
ZW0gZG9lcyBub3Qgc3VwcG9ydCBQQ0kKRGVjIDE2IDE1OjU4OjAwIHJpa2VyIGtlcm5lbDog
UENJOiBTeXN0ZW0gZG9lcyBub3Qgc3VwcG9ydCBQQ0kKRGVjIDE2IDE1OjU4OjAwIHJpa2Vy
IGtlcm5lbDogTkVUOiBSZWdpc3RlcmVkIHByb3RvY29sIGZhbWlseSA4CkRlYyAxNiAxNTo1
ODowMCByaWtlciBrZXJuZWw6IE5FVDogUmVnaXN0ZXJlZCBwcm90b2NvbCBmYW1pbHkgMjAK
RGVjIDE2IDE1OjU4OjAwIHJpa2VyIGtlcm5lbDogU3dpdGNoaW5nIHRvIGNsb2Nrc291cmNl
IHhlbgpEZWMgMTYgMTU6NTg6MDAgcmlrZXIga2VybmVsOiBwbnA6IFBuUCBBQ1BJOiBkaXNh
YmxlZApEZWMgMTYgMTU6NTg6MDAgcmlrZXIga2VybmVsOiBORVQ6IFJlZ2lzdGVyZWQgcHJv
dG9jb2wgZmFtaWx5IDIKRGVjIDE2IDE1OjU4OjAwIHJpa2VyIGtlcm5lbDogSVAgcm91dGUg
Y2FjaGUgaGFzaCB0YWJsZSBlbnRyaWVzOiA0MDk2IChvcmRlcjogMywgMzI3NjggYnl0ZXMp
CkRlYyAxNiAxNTo1ODowMCByaWtlciBrZXJuZWw6IFRDUCBlc3RhYmxpc2hlZCBoYXNoIHRh
YmxlIGVudHJpZXM6IDE2Mzg0IChvcmRlcjogNiwgMjYyMTQ0IGJ5dGVzKQpEZWMgMTYgMTU6
NTg6MDAgcmlrZXIga2VybmVsOiBUQ1AgYmluZCBoYXNoIHRhYmxlIGVudHJpZXM6IDE2Mzg0
IChvcmRlcjogNiwgMjYyMTQ0IGJ5dGVzKQpEZWMgMTYgMTU6NTg6MDAgcmlrZXIga2VybmVs
OiBUQ1A6IEhhc2ggdGFibGVzIGNvbmZpZ3VyZWQgKGVzdGFibGlzaGVkIDE2Mzg0IGJpbmQg
MTYzODQpCkRlYyAxNiAxNTo1ODowMCByaWtlciBrZXJuZWw6IFRDUCByZW5vIHJlZ2lzdGVy
ZWQKRGVjIDE2IDE1OjU4OjAwIHJpa2VyIGtlcm5lbDogVURQIGhhc2ggdGFibGUgZW50cmll
czogMjU2IChvcmRlcjogMSwgODE5MiBieXRlcykKRGVjIDE2IDE1OjU4OjAwIHJpa2VyIGtl
cm5lbDogVURQLUxpdGUgaGFzaCB0YWJsZSBlbnRyaWVzOiAyNTYgKG9yZGVyOiAxLCA4MTky
IGJ5dGVzKQpEZWMgMTYgMTU6NTg6MDAgcmlrZXIga2VybmVsOiBORVQ6IFJlZ2lzdGVyZWQg
cHJvdG9jb2wgZmFtaWx5IDEKRGVjIDE2IDE1OjU4OjAwIHJpa2VyIGtlcm5lbDogVHJ5aW5n
IHRvIHVucGFjayByb290ZnMgaW1hZ2UgYXMgaW5pdHJhbWZzLi4uCkRlYyAxNiAxNTo1ODow
MCByaWtlciBrZXJuZWw6IEZyZWVpbmcgaW5pdHJkIG1lbW9yeTogODIzNmsgZnJlZWQKRGVj
IDE2IDE1OjU4OjAwIHJpa2VyIGtlcm5lbDogcGxhdGZvcm0gcnRjX2Ntb3M6IHJlZ2lzdGVy
ZWQgcGxhdGZvcm0gUlRDIGRldmljZSAobm8gUE5QIGRldmljZSBmb3VuZCkKRGVjIDE2IDE1
OjU4OjAwIHJpa2VyIGtlcm5lbDogYXVkaXQ6IGluaXRpYWxpemluZyBuZXRsaW5rIHNvY2tl
dCAoZGlzYWJsZWQpCkRlYyAxNiAxNTo1ODowMCByaWtlciBrZXJuZWw6IHR5cGU9MjAwMCBh
dWRpdCgxMzI0MDQ3NDc1LjMxMjoxKTogaW5pdGlhbGl6ZWQKRGVjIDE2IDE1OjU4OjAwIHJp
a2VyIGtlcm5lbDogVkZTOiBEaXNrIHF1b3RhcyBkcXVvdF82LjUuMgpEZWMgMTYgMTU6NTg6
MDAgcmlrZXIga2VybmVsOiBEcXVvdC1jYWNoZSBoYXNoIHRhYmxlIGVudHJpZXM6IDUxMiAo
b3JkZXIgMCwgNDA5NiBieXRlcykKRGVjIDE2IDE1OjU4OjAwIHJpa2VyIGtlcm5lbDogTlRG
UyBkcml2ZXIgMi4xLjI5IFtGbGFnczogUi9XXS4KRGVjIDE2IDE1OjU4OjAwIHJpa2VyIGtl
cm5lbDogbXNnbW5pIGhhcyBiZWVuIHNldCB0byA2NTYKRGVjIDE2IDE1OjU4OjAwIHJpa2Vy
IGtlcm5lbDogcGNpZnJvbnQgcGNpLTA6IEluc3RhbGxpbmcgUENJIGZyb250ZW5kCkRlYyAx
NiAxNTo1ODowMCByaWtlciBrZXJuZWw6IGFsZzogTm8gdGVzdCBmb3Igc3Rkcm5nIChrcm5n
KQpEZWMgMTYgMTU6NTg6MDAgcmlrZXIga2VybmVsOiBCbG9jayBsYXllciBTQ1NJIGdlbmVy
aWMgKGJzZykgZHJpdmVyIHZlcnNpb24gMC40IGxvYWRlZCAobWFqb3IgMjU0KQpEZWMgMTYg
MTU6NTg6MDAgcmlrZXIga2VybmVsOiBpbyBzY2hlZHVsZXIgbm9vcCByZWdpc3RlcmVkCkRl
YyAxNiAxNTo1ODowMCByaWtlciBrZXJuZWw6IGlvIHNjaGVkdWxlciBkZWFkbGluZSByZWdp
c3RlcmVkCkRlYyAxNiAxNTo1ODowMCByaWtlciBrZXJuZWw6IGlvIHNjaGVkdWxlciBjZnEg
cmVnaXN0ZXJlZCAoZGVmYXVsdCkKRGVjIDE2IDE1OjU4OjAwIHJpa2VyIGtlcm5lbDogTGlu
dXggYWdwZ2FydCBpbnRlcmZhY2UgdjAuMTAzCkRlYyAxNiAxNTo1ODowMCByaWtlciBrZXJu
ZWw6IGJyZDogbW9kdWxlIGxvYWRlZApEZWMgMTYgMTU6NTg6MDAgcmlrZXIga2VybmVsOiBY
ZW4gdmlydHVhbCBjb25zb2xlIHN1Y2Nlc3NmdWxseSBpbnN0YWxsZWQgYXMgdHR5MQpEZWMg
MTYgMTU6NTg6MDAgcmlrZXIga2VybmVsOiBFdmVudC1jaGFubmVsIGRldmljZSBpbnN0YWxs
ZWQuCkRlYyAxNiAxNTo1ODowMCByaWtlciBrZXJuZWw6IHBjaWZyb250IHBjaS0wOiBDcmVh
dGluZyBQQ0kgRnJvbnRlbmQgQnVzIDAwMDA6MDAKRGVjIDE2IDE1OjU4OjAwIHJpa2VyIGtl
cm5lbDogYmxrdGFwX2RldmljZV9pbml0OiBibGt0YXAgZGV2aWNlIG1ham9yIDI1NApEZWMg
MTYgMTU6NTg6MDAgcmlrZXIga2VybmVsOiBibGt0YXBfcmluZ19pbml0OiBibGt0YXAgcmlu
ZyBtYWpvcjogMjUyCkRlYyAxNiAxNTo1ODowMCByaWtlciBrZXJuZWw6IG5ldGZyb250OiBJ
bml0aWFsaXNpbmcgdmlydHVhbCBldGhlcm5ldCBkcml2ZXIuCkRlYyAxNiAxNTo1ODowMCBy
aWtlciBrZXJuZWw6IHhlbi12YmQ6IHJlZ2lzdGVyZWQgYmxvY2sgZGV2aWNlIG1ham9yIDIw
MgpEZWMgMTYgMTU6NTg6MDAgcmlrZXIga2VybmVsOiBibGtmcm9udDogeHZkYTE6IGJhcnJp
ZXJzIGVuYWJsZWQKRGVjIDE2IDE1OjU4OjAwIHJpa2VyIGtlcm5lbDogYmxrZnJvbnQ6IHh2
ZGEyOiBiYXJyaWVycyBlbmFibGVkCkRlYyAxNiAxNTo1ODowMCByaWtlciBrZXJuZWw6IFNl
dHRpbmcgY2FwYWNpdHkgdG8gODM4ODYwOApEZWMgMTYgMTU6NTg6MDAgcmlrZXIga2VybmVs
OiB4dmRhMTogZGV0ZWN0ZWQgY2FwYWNpdHkgY2hhbmdlIGZyb20gMCB0byA0Mjk0OTY3Mjk2
CkRlYyAxNiAxNTo1ODowMCByaWtlciBrZXJuZWw6IFNldHRpbmcgY2FwYWNpdHkgdG8gMjA5
NzE1MgpEZWMgMTYgMTU6NTg6MDAgcmlrZXIga2VybmVsOiB4dmRhMjogZGV0ZWN0ZWQgY2Fw
YWNpdHkgY2hhbmdlIGZyb20gMCB0byAxMDczNzQxODI0CkRlYyAxNiAxNTo1ODowMCByaWtl
ciBrZXJuZWw6IGJsa2Zyb250OiB4dmRiMTogYmFycmllcnMgZW5hYmxlZApEZWMgMTYgMTU6
NTg6MDAgcmlrZXIga2VybmVsOiB1c2Jjb3JlOiByZWdpc3RlcmVkIG5ldyBpbnRlcmZhY2Ug
ZHJpdmVyIHVzYmJhY2sKRGVjIDE2IDE1OjU4OjAwIHJpa2VyIGtlcm5lbDogUFBQIGdlbmVy
aWMgZHJpdmVyIHZlcnNpb24gMi40LjIKRGVjIDE2IDE1OjU4OjAwIHJpa2VyIGtlcm5lbDog
UE5QOiBObyBQUy8yIGNvbnRyb2xsZXIgZm91bmQuIFByb2JpbmcgcG9ydHMgZGlyZWN0bHku
CkRlYyAxNiAxNTo1ODowMCByaWtlciBrZXJuZWw6IG1pY2U6IFBTLzIgbW91c2UgZGV2aWNl
IGNvbW1vbiBmb3IgYWxsIG1pY2UKRGVjIDE2IDE1OjU4OjAwIHJpa2VyIGtlcm5lbDogVENQ
IGJpYyByZWdpc3RlcmVkCkRlYyAxNiAxNTo1ODowMCByaWtlciBrZXJuZWw6IE5FVDogUmVn
aXN0ZXJlZCBwcm90b2NvbCBmYW1pbHkgMTcKRGVjIDE2IDE1OjU4OjAwIHJpa2VyIGtlcm5l
bDogUENJIElPIG11bHRpcGxleGVyIGRldmljZSBpbnN0YWxsZWQuCkRlYyAxNiAxNTo1ODow
MCByaWtlciBrZXJuZWw6IEZyZWVpbmcgdW51c2VkIGtlcm5lbCBtZW1vcnk6IDMyMGsgZnJl
ZWQKRGVjIDE2IDE1OjU4OjAwIHJpa2VyIGtlcm5lbDoga2pvdXJuYWxkIHN0YXJ0aW5nLiAg
Q29tbWl0IGludGVydmFsIDUgc2Vjb25kcwpEZWMgMTYgMTU6NTg6MDAgcmlrZXIga2VybmVs
OiBFWFQzLWZzICh4dmRhMSk6IG1vdW50ZWQgZmlsZXN5c3RlbSB3aXRoIHdyaXRlYmFjayBk
YXRhIG1vZGUKRGVjIDE2IDE1OjU4OjAwIHJpa2VyIGtlcm5lbDogdWRldlsxODZdOiBzdGFy
dGluZyB2ZXJzaW9uIDE2NApEZWMgMTYgMTU6NTg6MDAgcmlrZXIga2VybmVsOiBMaW51eCB2
aWRlbyBjYXB0dXJlIGludGVyZmFjZTogdjIuMDAKRGVjIDE2IDE1OjU4OjAwIHJpa2VyIGtl
cm5lbDogc2FhNzE0NjogcmVnaXN0ZXIgZXh0ZW5zaW9uICdidWRnZXRfYXYnLgpEZWMgMTYg
MTU6NTg6MDAgcmlrZXIga2VybmVsOiBidWRnZXRfYXYgMDAwMDowMDowMC4wOiBlbmFibGlu
ZyBkZXZpY2UgKDAwMDAgLT4gMDAwMikKRGVjIDE2IDE1OjU4OjAwIHJpa2VyIGtlcm5lbDog
SVJRIDE3LzogSVJRRl9ESVNBQkxFRCBpcyBub3QgZ3VhcmFudGVlZCBvbiBzaGFyZWQgSVJR
cwpEZWMgMTYgMTU6NTg6MDAgcmlrZXIga2VybmVsOiBzYWE3MTQ2OiBmb3VuZCBzYWE3MTQ2
IEAgbWVtIGZmZmZjOTAwMDAyM2UwMDAgKHJldmlzaW9uIDEsIGlycSAxNykgKDB4MTg5NCww
eDAwMjgpLgpEZWMgMTYgMTU6NTg6MDAgcmlrZXIga2VybmVsOiBzYWE3MTQ2ICgwKTogZG1h
IGJ1ZmZlciBzaXplIDEzNDc1ODQKRGVjIDE2IDE1OjU4OjAwIHJpa2VyIGtlcm5lbDogRFZC
OiByZWdpc3RlcmluZyBuZXcgYWRhcHRlciAoS05DMSBEVkItQyBNSzMpCkRlYyAxNiAxNTo1
ODowMCByaWtlciBrZXJuZWw6IGFkYXB0ZXIgZmFpbGVkIE1BQyBzaWduYXR1cmUgY2hlY2sK
RGVjIDE2IDE1OjU4OjAwIHJpa2VyIGtlcm5lbDogZW5jb2RlZCBNQUMgZnJvbSBFRVBST00g
d2FzIGZmOmZmOmZmOmZmOmZmOmZmOmZmOmZmOmZmOmZmOmZmOmZmOmZmOmZmOmZmOmZmOmZm
OmZmOmZmOmZmCkRlYyAxNiAxNTo1ODowMCByaWtlciBrZXJuZWw6IEtOQzEtMDogTUFDIGFk
ZHIgPSAwMDowOTpkNjo2ZDpiMzowYQpEZWMgMTYgMTU6NTg6MDAgcmlrZXIga2VybmVsOiBE
VkI6IHJlZ2lzdGVyaW5nIGFkYXB0ZXIgMCBmcm9udGVuZCAwIChQaGlsaXBzIFREQTEwMDIz
IERWQi1DKS4uLgpEZWMgMTYgMTU6NTg6MDAgcmlrZXIga2VybmVsOiBidWRnZXQtYXY6IGNp
IGludGVyZmFjZSBpbml0aWFsaXNlZC4KRGVjIDE2IDE1OjU4OjAwIHJpa2VyIGtlcm5lbDog
YnVkZ2V0X2F2IDAwMDA6MDA6MDEuMDogZW5hYmxpbmcgZGV2aWNlICgwMDAwIC0+IDAwMDIp
CkRlYyAxNiAxNTo1ODowMCByaWtlciBrZXJuZWw6IElSUSAxOC86IElSUUZfRElTQUJMRUQg
aXMgbm90IGd1YXJhbnRlZWQgb24gc2hhcmVkIElSUXMKRGVjIDE2IDE1OjU4OjAwIHJpa2Vy
IGtlcm5lbDogc2FhNzE0NjogZm91bmQgc2FhNzE0NiBAIG1lbSBmZmZmYzkwMDAwNGQ2MDAw
IChyZXZpc2lvbiAxLCBpcnEgMTgpICgweDE4OTQsMHgwMDJjKS4KRGVjIDE2IDE1OjU4OjAw
IHJpa2VyIGtlcm5lbDogc2FhNzE0NiAoMSk6IGRtYSBidWZmZXIgc2l6ZSAxMzQ3NTg0CkRl
YyAxNiAxNTo1ODowMCByaWtlciBrZXJuZWw6IERWQjogcmVnaXN0ZXJpbmcgbmV3IGFkYXB0
ZXIgKFNhdGVsY28gRWFzeVdhdGNoIERWQi1DIE1LMykKRGVjIDE2IDE1OjU4OjAwIHJpa2Vy
IGtlcm5lbDogYWRhcHRlciBmYWlsZWQgTUFDIHNpZ25hdHVyZSBjaGVjawpEZWMgMTYgMTU6
NTg6MDAgcmlrZXIga2VybmVsOiBlbmNvZGVkIE1BQyBmcm9tIEVFUFJPTSB3YXMgZmY6ZmY6
ZmY6ZmY6ZmY6ZmY6ZmY6ZmY6ZmY6ZmY6ZmY6ZmY6ZmY6ZmY6ZmY6ZmY6ZmY6ZmY6ZmY6ZmYK
RGVjIDE2IDE1OjU4OjAwIHJpa2VyIGtlcm5lbDogS05DMS0xOiBNQUMgYWRkciA9IDAwOjA5
OmQ2OjZkOmIwOjMzCkRlYyAxNiAxNTo1ODowMCByaWtlciBrZXJuZWw6IERWQjogcmVnaXN0
ZXJpbmcgYWRhcHRlciAxIGZyb250ZW5kIDAgKFBoaWxpcHMgVERBMTAwMjMgRFZCLUMpLi4u
CkRlYyAxNiAxNTo1ODowMCByaWtlciBrZXJuZWw6IGJ1ZGdldC1hdjogY2kgaW50ZXJmYWNl
IGluaXRpYWxpc2VkLgpEZWMgMTYgMTU6NTg6MDAgcmlrZXIga2VybmVsOiBBZGRpbmcgMTA0
ODU3Mmsgc3dhcCBvbiAvZGV2L3h2ZGEyLiAgUHJpb3JpdHk6LTEgZXh0ZW50czoxIGFjcm9z
czoxMDQ4NTcyayBTUwpEZWMgMTYgMTU6NTg6MDAgcmlrZXIga2VybmVsOiBFWFQzLWZzICh4
dmRhMSk6IHdhcm5pbmc6IG1heGltYWwgbW91bnQgY291bnQgcmVhY2hlZCwgcnVubmluZyBl
MmZzY2sgaXMgcmVjb21tZW5kZWQKRGVjIDE2IDE1OjU4OjAwIHJpa2VyIGtlcm5lbDogRVhU
My1mcyAoeHZkYTEpOiB1c2luZyBpbnRlcm5hbCBqb3VybmFsCkRlYyAxNiAxNTo1ODowMCBy
aWtlciBrZXJuZWw6IGtqb3VybmFsZCBzdGFydGluZy4gIENvbW1pdCBpbnRlcnZhbCA1IHNl
Y29uZHMKRGVjIDE2IDE1OjU4OjAwIHJpa2VyIGtlcm5lbDogRVhUMy1mcyAoeHZkYjEpOiB3
YXJuaW5nOiBtYXhpbWFsIG1vdW50IGNvdW50IHJlYWNoZWQsIHJ1bm5pbmcgZTJmc2NrIGlz
IHJlY29tbWVuZGVkCkRlYyAxNiAxNTo1ODowMCByaWtlciBrZXJuZWw6IEVYVDMtZnMgKHh2
ZGIxKTogdXNpbmcgaW50ZXJuYWwgam91cm5hbApEZWMgMTYgMTU6NTg6MDAgcmlrZXIga2Vy
bmVsOiBFWFQzLWZzICh4dmRiMSk6IG1vdW50ZWQgZmlsZXN5c3RlbSB3aXRoIHdyaXRlYmFj
ayBkYXRhIG1vZGUKRGVjIDE2IDE1OjU4OjAwIHJpa2VyIGtlcm5lbDogUlBDOiBSZWdpc3Rl
cmVkIHVkcCB0cmFuc3BvcnQgbW9kdWxlLgpEZWMgMTYgMTU6NTg6MDAgcmlrZXIga2VybmVs
OiBSUEM6IFJlZ2lzdGVyZWQgdGNwIHRyYW5zcG9ydCBtb2R1bGUuCkRlYyAxNiAxNTo1ODow
MCByaWtlciBrZXJuZWw6IFJQQzogUmVnaXN0ZXJlZCB0Y3AgTkZTdjQuMSBiYWNrY2hhbm5l
bCB0cmFuc3BvcnQgbW9kdWxlLgpEZWMgMTYgMTU6NTg6MDAgcmlrZXIga2VybmVsOiBJbnN0
YWxsaW5nIGtuZnNkIChjb3B5cmlnaHQgKEMpIDE5OTYgb2tpckBtb25hZC5zd2IuZGUpLgpE
ZWMgMTYgMTU6NTg6MDAgcmlrZXIga2VybmVsOiBORVQ6IFJlZ2lzdGVyZWQgcHJvdG9jb2wg
ZmFtaWx5IDEwCkRlYyAxNiAxNTo1ODowMCByaWtlciBrZXJuZWw6IGxvOiBEaXNhYmxlZCBQ
cml2YWN5IEV4dGVuc2lvbnMKRGVjIDE2IDE1OjU4OjAwIHJpa2VyIGtlcm5lbDogc3ZjOiBm
YWlsZWQgdG8gcmVnaXN0ZXIgbG9ja2R2MSBSUEMgc2VydmljZSAoZXJybm8gOTcpLgpEZWMg
MTYgMTU6NTg6MDAgcmlrZXIga2VybmVsOiBORlNEOiBVc2luZyAvdmFyL2xpYi9uZnMvdjRy
ZWNvdmVyeSBhcyB0aGUgTkZTdjQgc3RhdGUgcmVjb3ZlcnkgZGlyZWN0b3J5CkRlYyAxNiAx
NTo1ODowMCByaWtlciBrZXJuZWw6IE5GU0Q6IHN0YXJ0aW5nIDkwLXNlY29uZCBncmFjZSBw
ZXJpb2QK
--=_jASWBVRfAzzjZ2gubxT7JfE4rOPAtg-rILiWQbFgI4tLQ-VX
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--=_jASWBVRfAzzjZ2gubxT7JfE4rOPAtg-rILiWQbFgI4tLQ-VX--



From xen-devel-bounces@lists.xensource.com Fri Dec 16 16:03:32 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 16:03:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbaFg-0004vo-TO; Fri, 16 Dec 2011 16:03:16 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Neal.Taylor@ca.com>) id 1RbaFf-0004vA-AE
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 16:03:15 +0000
X-Env-Sender: Neal.Taylor@ca.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1324051386!6576560!1
X-Originating-IP: [74.125.149.244]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23846 invoked from network); 16 Dec 2011 16:03:08 -0000
Received: from na3sys009aog118.obsmtp.com (HELO na3sys009aog118.obsmtp.com)
	(74.125.149.244)
	by server-13.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Dec 2011 16:03:08 -0000
Received: from USILMS190.ca.com ([141.202.246.44]) (using TLSv1) by
	na3sys009aob118.postini.com ([74.125.148.12]) with SMTP
	ID DSNKTutruuGtm7/16AZr8BFDKwlKflF96xca@postini.com;
	Fri, 16 Dec 2011 08:03:08 PST
Received: from USILMS175.ca.com (141.202.6.25) by USILMS190.ca.com
	(141.202.246.44) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Fri, 16 Dec 2011 11:03:05 -0500
Received: from USILMS110A.ca.com ([169.254.1.109]) by usilms175.ca.com
	([141.202.6.25]) with mapi id 14.01.0289.001;
	Fri, 16 Dec 2011 11:03:04 -0500
From: "Taylor, Neal E" <Neal.Taylor@ca.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Thread-Topic: patch "[PATCH] xen/swiotlb: Use page alignment for early
	buffer allocation." failed to apply to 3.1-stable tree
Thread-Index: AQHMu39EqhS6jdpwjEafu8REQ03Ud5Xdo1+ggAFNCgD//640YA==
Date: Fri, 16 Dec 2011 16:03:04 +0000
Message-ID: <3E243B26F475504B9BB0BCC9728B0DA629E1B0E9@USILMS110A.ca.com>
References: <13239908451694@kroah.org>
	<3E243B26F475504B9BB0BCC9728B0DA629E1AC69@USILMS110A.ca.com>
	<20111216154554.GG31755@phenom.dumpdata.com>
In-Reply-To: <20111216154554.GG31755@phenom.dumpdata.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [138.42.46.105]
MIME-Version: 1.0
Cc: "gregkh@suse.de" <gregkh@suse.de>, "Kalev, Leonid" <Leonid.Kalev@ca.com>,
	xen-devel <xen-devel@lists.xensource.com>,
	"stable@vger.kernel.org" <stable@vger.kernel.org>
Subject: Re: [Xen-devel] patch "[PATCH] xen/swiotlb: Use page alignment for
 early buffer allocation." failed to apply to 3.1-stable tree
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

I tested on 3.0.4 both with tons of debugging and cleaner version (running with just our production patches.)
The 3.1.5 I compiled was with only that patch, but you've tested that.

I'm testing both trees on "my box" - which technically is a set of 8 boxes from a sister organization which are nearly useless to them until we get this resolved, incorporated and delivered.

Neal

-----Original Message-----
From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@oracle.com] 
Sent: Friday, December 16, 2011 7:46 AM
To: Taylor, Neal E
Cc: stable@vger.kernel.org; gregkh@suse.de; Kalev, Leonid; xen-devel
Subject: Re: patch "[PATCH] xen/swiotlb: Use page alignment for early buffer allocation." failed to apply to 3.1-stable tree

On Fri, Dec 16, 2011 at 12:58:55AM +0000, Taylor, Neal E wrote:
> Konrad,
> 
> This patch applies and compiles on 3.1.5 and 3.0.4. I'll test tomorrow.

OK. I've tested it on 3.1.5 and 3.0.6 as well. If I recall you mentioned
that you had tested the 3.0.4 + this patch yesterday (thought you
probably had tons of debugging patches too). Is that you are testing a clean
version of 3.0.4 with this patch? Or are you testing both trees on your box?

Thanks!
> 
> Neal
> 
> diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
> index 8e964b9..5c8e445 100644
> --- a/drivers/xen/swiotlb-xen.c
> +++ b/drivers/xen/swiotlb-xen.c
> @@ -166,7 +166,8 @@ retry:
>         /*
>          * Get IO TLB memory from any location.
>          */
> -       xen_io_tlb_start = alloc_bootmem(bytes);
> +       xen_io_tlb_start = alloc_bootmem_pages(PAGE_ALIGN(bytes));
> +
>         if (!xen_io_tlb_start)
>                 panic("Cannot allocate SWIOTLB buffer");
> 
> -----Original Message-----
> From: gregkh@suse.de [mailto:gregkh@suse.de] 
> Sent: Thursday, December 15, 2011 3:14 PM
> To: konrad.wilk@oracle.com; Kalev, Leonid; Taylor, Neal E
> Cc: stable@vger.kernel.org
> Subject: patch "[PATCH] xen/swiotlb: Use page alignment for early buffer allocation." failed to apply to 3.1-stable tree
> 
> 
> The patch below does not apply to the 3.1-stable tree.
> If someone wants it applied there, or to any other stable or longterm
> tree, then please email the backport, including the original git commit
> id to <stable@vger.kernel.org>.
> 
> thanks,
> 
> greg k-h
> 
> ------------------ original commit in Linus's tree ------------------
> 
> >From 63a741757d15320a25ebf5778f8651cce2ed0611 Mon Sep 17 00:00:00 2001
> From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> Date: Thu, 15 Dec 2011 11:28:46 -0500
> Subject: [PATCH] xen/swiotlb: Use page alignment for early buffer allocation.
> 
> This fixes an odd bug found on a Dell PowerEdge 1850/0RC130
> (BIOS A05 01/09/2006) where all of the modules doing pci_set_dma_mask
> would fail with:
> 
> ata_piix 0000:00:1f.1: enabling device (0005 -> 0007)
> ata_piix 0000:00:1f.1: can't derive routing for PCI INT A
> ata_piix 0000:00:1f.1: BMDMA: failed to set dma mask, falling back to PIO
> 
> The issue was the Xen-SWIOTLB was allocated such as that the end of
> buffer was stradling a page (and also above 4GB). The fix was
> spotted by Kalev Leonid  which was to piggyback on git commit
> e79f86b2ef9c0a8c47225217c1018b7d3d90101c "swiotlb: Use page alignment
> for early buffer allocation" which:
> 
> 	We could call free_bootmem_late() if swiotlb is not used, and
> 	it will shrink to page alignment.
> 
> 	So alloc them with page alignment at first, to avoid lose two pages
> 
> And doing that fixes the outstanding issue.
> 
> CC: stable@kernel.org
> Suggested-by: "Kalev, Leonid" <Leonid.Kalev@ca.com>
> Reported-and-Tested-by: "Taylor, Neal E" <Neal.Taylor@ca.com>
> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> 
> diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
> index 8e964b9..284798a 100644
> --- a/drivers/xen/swiotlb-xen.c
> +++ b/drivers/xen/swiotlb-xen.c
> @@ -166,7 +166,7 @@ retry:
>  	/*
>  	 * Get IO TLB memory from any location.
>  	 */
> -	xen_io_tlb_start = alloc_bootmem(bytes);
> +	xen_io_tlb_start = alloc_bootmem_pages(PAGE_ALIGN(bytes));
>  	if (!xen_io_tlb_start) {
>  		m = "Cannot allocate Xen-SWIOTLB buffer!\n";
>  		goto error;
> @@ -179,7 +179,7 @@ retry:
>  			       bytes,
>  			       xen_io_tlb_nslabs);
>  	if (rc) {
> -		free_bootmem(__pa(xen_io_tlb_start), bytes);
> +		free_bootmem(__pa(xen_io_tlb_start), PAGE_ALIGN(bytes));
>  		m = "Failed to get contiguous memory for DMA from Xen!\n"\
>  		    "You either: don't have the permissions, do not have"\
>  		    " enough free memory under 4GB, or the hypervisor memory"\

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 16:03:32 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 16:03:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbaFg-0004vo-TO; Fri, 16 Dec 2011 16:03:16 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Neal.Taylor@ca.com>) id 1RbaFf-0004vA-AE
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 16:03:15 +0000
X-Env-Sender: Neal.Taylor@ca.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1324051386!6576560!1
X-Originating-IP: [74.125.149.244]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23846 invoked from network); 16 Dec 2011 16:03:08 -0000
Received: from na3sys009aog118.obsmtp.com (HELO na3sys009aog118.obsmtp.com)
	(74.125.149.244)
	by server-13.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Dec 2011 16:03:08 -0000
Received: from USILMS190.ca.com ([141.202.246.44]) (using TLSv1) by
	na3sys009aob118.postini.com ([74.125.148.12]) with SMTP
	ID DSNKTutruuGtm7/16AZr8BFDKwlKflF96xca@postini.com;
	Fri, 16 Dec 2011 08:03:08 PST
Received: from USILMS175.ca.com (141.202.6.25) by USILMS190.ca.com
	(141.202.246.44) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Fri, 16 Dec 2011 11:03:05 -0500
Received: from USILMS110A.ca.com ([169.254.1.109]) by usilms175.ca.com
	([141.202.6.25]) with mapi id 14.01.0289.001;
	Fri, 16 Dec 2011 11:03:04 -0500
From: "Taylor, Neal E" <Neal.Taylor@ca.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Thread-Topic: patch "[PATCH] xen/swiotlb: Use page alignment for early
	buffer allocation." failed to apply to 3.1-stable tree
Thread-Index: AQHMu39EqhS6jdpwjEafu8REQ03Ud5Xdo1+ggAFNCgD//640YA==
Date: Fri, 16 Dec 2011 16:03:04 +0000
Message-ID: <3E243B26F475504B9BB0BCC9728B0DA629E1B0E9@USILMS110A.ca.com>
References: <13239908451694@kroah.org>
	<3E243B26F475504B9BB0BCC9728B0DA629E1AC69@USILMS110A.ca.com>
	<20111216154554.GG31755@phenom.dumpdata.com>
In-Reply-To: <20111216154554.GG31755@phenom.dumpdata.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [138.42.46.105]
MIME-Version: 1.0
Cc: "gregkh@suse.de" <gregkh@suse.de>, "Kalev, Leonid" <Leonid.Kalev@ca.com>,
	xen-devel <xen-devel@lists.xensource.com>,
	"stable@vger.kernel.org" <stable@vger.kernel.org>
Subject: Re: [Xen-devel] patch "[PATCH] xen/swiotlb: Use page alignment for
 early buffer allocation." failed to apply to 3.1-stable tree
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

I tested on 3.0.4 both with tons of debugging and cleaner version (running with just our production patches.)
The 3.1.5 I compiled was with only that patch, but you've tested that.

I'm testing both trees on "my box" - which technically is a set of 8 boxes from a sister organization which are nearly useless to them until we get this resolved, incorporated and delivered.

Neal

-----Original Message-----
From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@oracle.com] 
Sent: Friday, December 16, 2011 7:46 AM
To: Taylor, Neal E
Cc: stable@vger.kernel.org; gregkh@suse.de; Kalev, Leonid; xen-devel
Subject: Re: patch "[PATCH] xen/swiotlb: Use page alignment for early buffer allocation." failed to apply to 3.1-stable tree

On Fri, Dec 16, 2011 at 12:58:55AM +0000, Taylor, Neal E wrote:
> Konrad,
> 
> This patch applies and compiles on 3.1.5 and 3.0.4. I'll test tomorrow.

OK. I've tested it on 3.1.5 and 3.0.6 as well. If I recall you mentioned
that you had tested the 3.0.4 + this patch yesterday (thought you
probably had tons of debugging patches too). Is that you are testing a clean
version of 3.0.4 with this patch? Or are you testing both trees on your box?

Thanks!
> 
> Neal
> 
> diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
> index 8e964b9..5c8e445 100644
> --- a/drivers/xen/swiotlb-xen.c
> +++ b/drivers/xen/swiotlb-xen.c
> @@ -166,7 +166,8 @@ retry:
>         /*
>          * Get IO TLB memory from any location.
>          */
> -       xen_io_tlb_start = alloc_bootmem(bytes);
> +       xen_io_tlb_start = alloc_bootmem_pages(PAGE_ALIGN(bytes));
> +
>         if (!xen_io_tlb_start)
>                 panic("Cannot allocate SWIOTLB buffer");
> 
> -----Original Message-----
> From: gregkh@suse.de [mailto:gregkh@suse.de] 
> Sent: Thursday, December 15, 2011 3:14 PM
> To: konrad.wilk@oracle.com; Kalev, Leonid; Taylor, Neal E
> Cc: stable@vger.kernel.org
> Subject: patch "[PATCH] xen/swiotlb: Use page alignment for early buffer allocation." failed to apply to 3.1-stable tree
> 
> 
> The patch below does not apply to the 3.1-stable tree.
> If someone wants it applied there, or to any other stable or longterm
> tree, then please email the backport, including the original git commit
> id to <stable@vger.kernel.org>.
> 
> thanks,
> 
> greg k-h
> 
> ------------------ original commit in Linus's tree ------------------
> 
> >From 63a741757d15320a25ebf5778f8651cce2ed0611 Mon Sep 17 00:00:00 2001
> From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> Date: Thu, 15 Dec 2011 11:28:46 -0500
> Subject: [PATCH] xen/swiotlb: Use page alignment for early buffer allocation.
> 
> This fixes an odd bug found on a Dell PowerEdge 1850/0RC130
> (BIOS A05 01/09/2006) where all of the modules doing pci_set_dma_mask
> would fail with:
> 
> ata_piix 0000:00:1f.1: enabling device (0005 -> 0007)
> ata_piix 0000:00:1f.1: can't derive routing for PCI INT A
> ata_piix 0000:00:1f.1: BMDMA: failed to set dma mask, falling back to PIO
> 
> The issue was the Xen-SWIOTLB was allocated such as that the end of
> buffer was stradling a page (and also above 4GB). The fix was
> spotted by Kalev Leonid  which was to piggyback on git commit
> e79f86b2ef9c0a8c47225217c1018b7d3d90101c "swiotlb: Use page alignment
> for early buffer allocation" which:
> 
> 	We could call free_bootmem_late() if swiotlb is not used, and
> 	it will shrink to page alignment.
> 
> 	So alloc them with page alignment at first, to avoid lose two pages
> 
> And doing that fixes the outstanding issue.
> 
> CC: stable@kernel.org
> Suggested-by: "Kalev, Leonid" <Leonid.Kalev@ca.com>
> Reported-and-Tested-by: "Taylor, Neal E" <Neal.Taylor@ca.com>
> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> 
> diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
> index 8e964b9..284798a 100644
> --- a/drivers/xen/swiotlb-xen.c
> +++ b/drivers/xen/swiotlb-xen.c
> @@ -166,7 +166,7 @@ retry:
>  	/*
>  	 * Get IO TLB memory from any location.
>  	 */
> -	xen_io_tlb_start = alloc_bootmem(bytes);
> +	xen_io_tlb_start = alloc_bootmem_pages(PAGE_ALIGN(bytes));
>  	if (!xen_io_tlb_start) {
>  		m = "Cannot allocate Xen-SWIOTLB buffer!\n";
>  		goto error;
> @@ -179,7 +179,7 @@ retry:
>  			       bytes,
>  			       xen_io_tlb_nslabs);
>  	if (rc) {
> -		free_bootmem(__pa(xen_io_tlb_start), bytes);
> +		free_bootmem(__pa(xen_io_tlb_start), PAGE_ALIGN(bytes));
>  		m = "Failed to get contiguous memory for DMA from Xen!\n"\
>  		    "You either: don't have the permissions, do not have"\
>  		    " enough free memory under 4GB, or the hypervisor memory"\

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 16:20:55 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 16:20:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbaWO-0005Iz-IT; Fri, 16 Dec 2011 16:20:32 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RbaWN-0005Iu-Gj
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 16:20:31 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1324052423!8413194!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ0MzA3NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26046 invoked from network); 16 Dec 2011 16:20:25 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-12.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Dec 2011 16:20:25 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pBGGKIRU027245
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 16 Dec 2011 16:20:18 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pBGGKHOB019152
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 16 Dec 2011 16:20:17 GMT
Received: from abhmt119.oracle.com (abhmt119.oracle.com [141.146.116.71])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pBGGKGgA015329; Fri, 16 Dec 2011 10:20:16 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 16 Dec 2011 08:20:16 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id E16C84018D; Fri, 16 Dec 2011 11:19:22 -0500 (EST)
Date: Fri, 16 Dec 2011 11:19:22 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Carsten Schiers <carsten@schiers.de>
Message-ID: <20111216161922.GH31755@phenom.dumpdata.com>
References: <20111214220700.GA9926@phenom.dumpdata.com>
	<zarafa.4eeb6913.0870.04527b5d644d76ef@uhura.space.zz>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <zarafa.4eeb6913.0870.04527b5d644d76ef@uhura.space.zz>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090203.4EEB6FC3.0118,ss=1,re=0.000,fgs=0
Cc: "linux@eikelenboom.it" <linux@eikelenboom.it>,
	xen-devel <xen-devel@lists.xensource.com>,
	"lersek@redhat.com" <lersek@redhat.com>,
	"zhenzhong.duan@oracle.com" <zhenzhong.duan@oracle.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: Re: [Xen-devel] Load increase after memory upgrade (part2)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Dec 16, 2011 at 04:51:47PM +0100, Carsten Schiers wrote:
> > And you are using swiotlb=force on the 2.6.34 classic kernel and passing in your budget-av card in it?
> 
> Yes, two of them with swiotlb=32,force.
> 
> 
> > Could you append the dmesg output please?
> 
> Attached. You find a "normal" boot after the one with the patched kernel.

Uh, what happens when you run the driver, meaning capture stuff. I remember with
the pvops you had about ~30K or so of bounces, but not sure about the bootup?

Thanks for being willing to be a guinea pig while trying to fix this.
> 
> Carsten.
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 16:20:55 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 16:20:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbaWO-0005Iz-IT; Fri, 16 Dec 2011 16:20:32 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RbaWN-0005Iu-Gj
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 16:20:31 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1324052423!8413194!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ0MzA3NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26046 invoked from network); 16 Dec 2011 16:20:25 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-12.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Dec 2011 16:20:25 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pBGGKIRU027245
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 16 Dec 2011 16:20:18 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pBGGKHOB019152
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 16 Dec 2011 16:20:17 GMT
Received: from abhmt119.oracle.com (abhmt119.oracle.com [141.146.116.71])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pBGGKGgA015329; Fri, 16 Dec 2011 10:20:16 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 16 Dec 2011 08:20:16 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id E16C84018D; Fri, 16 Dec 2011 11:19:22 -0500 (EST)
Date: Fri, 16 Dec 2011 11:19:22 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Carsten Schiers <carsten@schiers.de>
Message-ID: <20111216161922.GH31755@phenom.dumpdata.com>
References: <20111214220700.GA9926@phenom.dumpdata.com>
	<zarafa.4eeb6913.0870.04527b5d644d76ef@uhura.space.zz>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <zarafa.4eeb6913.0870.04527b5d644d76ef@uhura.space.zz>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090203.4EEB6FC3.0118,ss=1,re=0.000,fgs=0
Cc: "linux@eikelenboom.it" <linux@eikelenboom.it>,
	xen-devel <xen-devel@lists.xensource.com>,
	"lersek@redhat.com" <lersek@redhat.com>,
	"zhenzhong.duan@oracle.com" <zhenzhong.duan@oracle.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: Re: [Xen-devel] Load increase after memory upgrade (part2)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Dec 16, 2011 at 04:51:47PM +0100, Carsten Schiers wrote:
> > And you are using swiotlb=force on the 2.6.34 classic kernel and passing in your budget-av card in it?
> 
> Yes, two of them with swiotlb=32,force.
> 
> 
> > Could you append the dmesg output please?
> 
> Attached. You find a "normal" boot after the one with the patched kernel.

Uh, what happens when you run the driver, meaning capture stuff. I remember with
the pvops you had about ~30K or so of bounces, but not sure about the bootup?

Thanks for being willing to be a guinea pig while trying to fix this.
> 
> Carsten.
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 16:30:00 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 16:30:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbafE-0005UT-KC; Fri, 16 Dec 2011 16:29:40 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dario.faggioli@citrix.com>) id 1RbafD-0005UB-0j
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 16:29:39 +0000
X-Env-Sender: dario.faggioli@citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1324052972!8261274!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjU3OQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19523 invoked from network); 16 Dec 2011 16:29:32 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Dec 2011 16:29:32 -0000
X-IronPort-AV: E=Sophos;i="4.71,364,1320624000"; d="asc'?scan'208";a="9520395"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Dec 2011 16:29:31 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 16 Dec 2011 16:29:31 +0000
Message-ID: <1324052965.2599.8.camel@Solace>
From: Dario Faggioli <dario.faggioli@citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Fri, 16 Dec 2011 17:29:25 +0100
X-Mailer: Evolution 3.0.3-3+b1 
MIME-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Keir Fraser <keir@xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH] All domains (including dom0) should be best
 effort upon creation.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3355710950159450660=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============3355710950159450660==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="=-uJD1GS+5VhIzwMREW8iI"

--=-uJD1GS+5VhIzwMREW8iI
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

All domains (including dom0) should be best effort upon creation.

In the sedf scheduler, while trying to guarantee to dom0 the proper
amount of CPU time for being able to do its job, we end up allocating
75% CPU-share to each and every of its VCPUs. This, combined with the
fact that such a scheduler has no load balancing logic at all (and
thus *all* dom0's VCPUs just rise and stay on physical CPU #0), means
that for example on a 12-cores system we're trying to exploit
75x12=3D900% of what we have on a PCPU, which is definitely too much!

Moreover, even if a cleverer mechanism for distributing VCPUs among
the available PCPUs (if not a proper load balancer) will be put in
place some day, it will still be difficult to decide how much guaranteed
CPU bandwidth each of the dom0's VCPUs should be provided with, without
posing the system at risk of livelock or starvation, even during
boot time.

Therefore, since sedf is capable of some form of best-effort
scheduling, the best thing we can do is ask for this behaviour for
dom0, as it is for all other domains, right upon creation. It will
then be the sysadmin's job to modify dom0's scheduling parameters
to better fit his particular needs, maybe after spreading the load
a bit by pinning VCPUs on PCPUs, or using cpupools, etc.

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>


diff -r 01c8b27e3d7d xen/common/sched_sedf.c
--- a/xen/common/sched_sedf.c	Thu Dec 15 16:56:21 2011 +0000
+++ b/xen/common/sched_sedf.c	Fri Dec 16 16:05:37 2011 +0100
@@ -359,19 +359,9 @@ static void *sedf_alloc_vdata(const stru
     inf->latency     =3D 0;
     inf->status      =3D EXTRA_AWARE | SEDF_ASLEEP;
     inf->extraweight =3D 1;
-
-    if ( v->domain->domain_id =3D=3D 0 )
-    {
-        /* Domain0 gets 75% guaranteed (15ms every 20ms). */
-        inf->period    =3D MILLISECS(20);
-        inf->slice     =3D MILLISECS(15);
-    }
-    else
-    {
-        /* Best-effort extratime only. */
-        inf->period    =3D WEIGHT_PERIOD;
-        inf->slice     =3D 0;
-    }
+    /* Upon creation all domain are best-effort. */
+    inf->period      =3D WEIGHT_PERIOD;
+    inf->slice       =3D 0;
=20
     inf->period_orig =3D inf->period; inf->slice_orig =3D inf->slice;
     INIT_LIST_HEAD(&(inf->list));

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-------------------------------------------------------------------
Dario Faggioli, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
PhD Candidate, ReTiS Lab, Scuola Superiore Sant'Anna, Pisa (Italy)


--=-uJD1GS+5VhIzwMREW8iI
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEABECAAYFAk7rceYACgkQk4XaBE3IOsRP1gCeM5+T+ybLRSO09Z8wWh335A78
e7sAoJyRdI92fEpDJeAWVmdz1fozEGzY
=aWx9
-----END PGP SIGNATURE-----

--=-uJD1GS+5VhIzwMREW8iI--


--===============3355710950159450660==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============3355710950159450660==--


From xen-devel-bounces@lists.xensource.com Fri Dec 16 16:30:00 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 16:30:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbafE-0005UT-KC; Fri, 16 Dec 2011 16:29:40 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dario.faggioli@citrix.com>) id 1RbafD-0005UB-0j
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 16:29:39 +0000
X-Env-Sender: dario.faggioli@citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1324052972!8261274!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjU3OQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19523 invoked from network); 16 Dec 2011 16:29:32 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Dec 2011 16:29:32 -0000
X-IronPort-AV: E=Sophos;i="4.71,364,1320624000"; d="asc'?scan'208";a="9520395"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Dec 2011 16:29:31 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 16 Dec 2011 16:29:31 +0000
Message-ID: <1324052965.2599.8.camel@Solace>
From: Dario Faggioli <dario.faggioli@citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Fri, 16 Dec 2011 17:29:25 +0100
X-Mailer: Evolution 3.0.3-3+b1 
MIME-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Keir Fraser <keir@xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH] All domains (including dom0) should be best
 effort upon creation.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3355710950159450660=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============3355710950159450660==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="=-uJD1GS+5VhIzwMREW8iI"

--=-uJD1GS+5VhIzwMREW8iI
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

All domains (including dom0) should be best effort upon creation.

In the sedf scheduler, while trying to guarantee to dom0 the proper
amount of CPU time for being able to do its job, we end up allocating
75% CPU-share to each and every of its VCPUs. This, combined with the
fact that such a scheduler has no load balancing logic at all (and
thus *all* dom0's VCPUs just rise and stay on physical CPU #0), means
that for example on a 12-cores system we're trying to exploit
75x12=3D900% of what we have on a PCPU, which is definitely too much!

Moreover, even if a cleverer mechanism for distributing VCPUs among
the available PCPUs (if not a proper load balancer) will be put in
place some day, it will still be difficult to decide how much guaranteed
CPU bandwidth each of the dom0's VCPUs should be provided with, without
posing the system at risk of livelock or starvation, even during
boot time.

Therefore, since sedf is capable of some form of best-effort
scheduling, the best thing we can do is ask for this behaviour for
dom0, as it is for all other domains, right upon creation. It will
then be the sysadmin's job to modify dom0's scheduling parameters
to better fit his particular needs, maybe after spreading the load
a bit by pinning VCPUs on PCPUs, or using cpupools, etc.

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>


diff -r 01c8b27e3d7d xen/common/sched_sedf.c
--- a/xen/common/sched_sedf.c	Thu Dec 15 16:56:21 2011 +0000
+++ b/xen/common/sched_sedf.c	Fri Dec 16 16:05:37 2011 +0100
@@ -359,19 +359,9 @@ static void *sedf_alloc_vdata(const stru
     inf->latency     =3D 0;
     inf->status      =3D EXTRA_AWARE | SEDF_ASLEEP;
     inf->extraweight =3D 1;
-
-    if ( v->domain->domain_id =3D=3D 0 )
-    {
-        /* Domain0 gets 75% guaranteed (15ms every 20ms). */
-        inf->period    =3D MILLISECS(20);
-        inf->slice     =3D MILLISECS(15);
-    }
-    else
-    {
-        /* Best-effort extratime only. */
-        inf->period    =3D WEIGHT_PERIOD;
-        inf->slice     =3D 0;
-    }
+    /* Upon creation all domain are best-effort. */
+    inf->period      =3D WEIGHT_PERIOD;
+    inf->slice       =3D 0;
=20
     inf->period_orig =3D inf->period; inf->slice_orig =3D inf->slice;
     INIT_LIST_HEAD(&(inf->list));

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-------------------------------------------------------------------
Dario Faggioli, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
PhD Candidate, ReTiS Lab, Scuola Superiore Sant'Anna, Pisa (Italy)


--=-uJD1GS+5VhIzwMREW8iI
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEABECAAYFAk7rceYACgkQk4XaBE3IOsRP1gCeM5+T+ybLRSO09Z8wWh335A78
e7sAoJyRdI92fEpDJeAWVmdz1fozEGzY
=aWx9
-----END PGP SIGNATURE-----

--=-uJD1GS+5VhIzwMREW8iI--


--===============3355710950159450660==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============3355710950159450660==--


From xen-devel-bounces@lists.xensource.com Fri Dec 16 16:41:17 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 16:41:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbaqA-0005mk-Q5; Fri, 16 Dec 2011 16:40:58 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1Rbaq9-0005me-Nw
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 16:40:58 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-8.tower-174.messagelabs.com!1324053650!5843608!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.5 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMTM4OTk=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMTM4OTk=\n,BODY_RANDOM_LONG
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19271 invoked from network); 16 Dec 2011 16:40:51 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-8.tower-174.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 16 Dec 2011 16:40:51 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1324053650; l=5304;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=C5K/+ZHtp1Bqfc5xrTZN0K9k9r8=;
	b=PoG61fPoqqEmqi87cUkS8EJP/EdB4+k0QSC/2HozvQI8t0iDDAIKKJctOuuiyCe2pep
	3th9koczfp46zhI0b1sRWpx+CJfgV/hUSDUaaISBRj45aQMujJibNbgHLYbGxkkzw++6w
	wIN7OOBpfVcBlDRhuufXUquooiFODeeQofc=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFPjzEQG5of
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-112-083.pools.arcor-ip.net [88.65.112.83])
	by post.strato.de (mrclete mo24) (RZmta 26.15 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id v053fanBGEQTO1 ;
	Fri, 16 Dec 2011 17:40:33 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 5A0F118637; Fri, 16 Dec 2011 17:40:33 +0100 (CET)
Date: Fri, 16 Dec 2011 17:40:33 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20111216164033.GA25508@aepfle.de>
References: <mailman.4227.1323785898.12970.xen-devel@lists.xensource.com>
	<3d5947b7ee3b2fdda393744f59d55b76.squirrel@webmail.lagarcavilla.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <3d5947b7ee3b2fdda393744f59d55b76.squirrel@webmail.lagarcavilla.org>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: xen-devel@lists.xensource.com, tim@xen.org
Subject: Re: [Xen-devel] [PATCH] mem_event: use wait queue when ring is full
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Dec 15, Andres Lagar-Cavilla wrote:

> > - How many requests should foreign vcpus place in the ring if the guest
> >   has more vcpus than available slots in the ring? Just a single one so
> >   that foreigners can also make some progress?
> The idea is that foreign vcpus can place as many events as they want as
> long as each guest vcpu that is not blocked on a men event has room to
> send one men event. When we reach that border condition, no more foreign
> men events.
> 
> The case for which there are way too many guest vcpus needs to be handled,
> either by capping the max number of vcpus for domains using a men event,
> or by growing the ring size.

Right now the ring is one page, so it can not hold more than 64 entries.
If that ever changes, the accounting can be adjusted.

> > - Should access and paging have the same rules for accounting?
> Absolutely.
> 
> And both should use wait queues in extreme cases in which a guest vcpu
> with a single action generates multiple memory events. Given that when we
> hit a border condition the guest vcpu will place one event and be flagged
> VPF_mem_event_paused (or whatever that flag is named), if a guest vcpu
> generates another event when flagged, that's our queue for putting the
> vcpu on a wait queue.

An extra flag is not needed.

Below is an incremental patch (on top of v6) which does some accounting.
Its just compile tested.

Olaf


diff -r 5d5d10e1568b xen/arch/x86/mm/mem_event.c
--- a/xen/arch/x86/mm/mem_event.c
+++ b/xen/arch/x86/mm/mem_event.c
@@ -114,6 +114,19 @@ static int mem_event_enable(
 
     med->pause_flag = pause_flag;
 
+    /*
+     * Configure ring accounting:
+     * Each guest vcpu should be able to place at least one request.
+     * If there are more vcpus than available slots in the ring, not all vcpus
+     * can place requests in the ring anyway.  A minimum (arbitrary) number of
+     * foreign requests will be allowed in this case.
+     */
+    if ( d->max_vcpus < RING_SIZE(&med->front_ring) )
+        med->max_foreign = RING_SIZE(&med->front_ring) - d->max_vcpus;
+    if ( med->max_foreign < 13 )
+        med->max_foreign = 13;
+    med->max_target = RING_SIZE(&med->front_ring) - med->max_foreign;
+
     init_waitqueue_head(&med->wq);
 
     /* Wake any VCPUs waiting for the ring to appear */
@@ -147,23 +160,28 @@ static int mem_event_disable(struct mem_
 
 static int _mem_event_put_request(struct domain *d,
                                   struct mem_event_domain *med,
-                                  mem_event_request_t *req)
+                                  mem_event_request_t *req,
+                                  int *done)
 {
     mem_event_front_ring_t *front_ring;
-    int free_req, claimed_req;
+    int free_req, claimed_req, ret;
     RING_IDX req_prod;
 
+    if ( *done )
+        return 1;
+
     mem_event_ring_lock(med);
 
-    free_req = RING_FREE_REQUESTS(&med->front_ring);
+    front_ring = &med->front_ring;
+
     /* Foreign requests must succeed because their vcpus can not sleep */
     claimed_req = med->foreign_producers;
+    free_req = RING_FREE_REQUESTS(front_ring);
     if ( !free_req || ( current->domain == d && free_req <= claimed_req ) ) {
         mem_event_ring_unlock(med);
         return 0;
     }
 
-    front_ring = &med->front_ring;
     req_prod = front_ring->req_prod_pvt;
 
     if ( current->domain != d )
@@ -176,9 +194,18 @@ static int _mem_event_put_request(struct
     memcpy(RING_GET_REQUEST(front_ring, req_prod), req, sizeof(*req));
     req_prod++;
 
+    ret = 1;
+    *done = 1;
+    free_req--;
+
     /* Update accounting */
     if ( current->domain == d )
+    {
         med->target_producers--;
+        /* Ring is full, no more requests from this vcpu, go to sleep */
+        if ( free_req < med->max_target )
+            ret = 0;
+    }
     else
         med->foreign_producers--;
 
@@ -190,19 +217,20 @@ static int _mem_event_put_request(struct
 
     notify_via_xen_event_channel(d, med->xen_port);
 
-    return 1;
+    return ret;
 }
 
 void mem_event_put_request(struct domain *d, struct mem_event_domain *med,
                            mem_event_request_t *req)
 {
+    int done = 0;
     /* Go to sleep if request came from guest */
     if (current->domain == d) {
-        wait_event(med->wq, _mem_event_put_request(d, med, req));
+        wait_event(med->wq, _mem_event_put_request(d, med, req, &done));
         return;
     }
     /* Ring was full anyway, unable to sleep in non-guest context */
-    if (!_mem_event_put_request(d, med, req))
+    if (!_mem_event_put_request(d, med, req, &done))
         printk("Failed to put memreq: d %u t %x f %x gfn %lx\n", d->domain_id,
                 req->type, req->flags, (unsigned long)req->gfn);
 }
@@ -341,7 +369,8 @@ int mem_event_claim_slot(struct domain *
         med->target_producers++;
         ring_full = 0;
     }
-    else if ( med->foreign_producers + med->target_producers + 1 < free_req )
+    else if ( med->foreign_producers + med->target_producers < free_req &&
+              med->foreign_producers < med->max_foreign )
     {
         med->foreign_producers++;
         ring_full = 0;
diff -r 5d5d10e1568b xen/include/xen/sched.h
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -184,8 +184,11 @@ struct mem_event_domain
 {
     /* ring lock */
     spinlock_t ring_lock;
-    unsigned short foreign_producers;
-    unsigned short target_producers;
+    /* The ring has 64 entries */
+    unsigned char foreign_producers;
+    unsigned char max_foreign;
+    unsigned char target_producers;
+    unsigned char max_target;
     /* shared page */
     mem_event_shared_page_t *shared_page;
     /* shared ring page */

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 16:41:17 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 16:41:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbaqA-0005mk-Q5; Fri, 16 Dec 2011 16:40:58 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1Rbaq9-0005me-Nw
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 16:40:58 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-8.tower-174.messagelabs.com!1324053650!5843608!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.5 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMTM4OTk=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMTM4OTk=\n,BODY_RANDOM_LONG
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19271 invoked from network); 16 Dec 2011 16:40:51 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-8.tower-174.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 16 Dec 2011 16:40:51 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1324053650; l=5304;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=C5K/+ZHtp1Bqfc5xrTZN0K9k9r8=;
	b=PoG61fPoqqEmqi87cUkS8EJP/EdB4+k0QSC/2HozvQI8t0iDDAIKKJctOuuiyCe2pep
	3th9koczfp46zhI0b1sRWpx+CJfgV/hUSDUaaISBRj45aQMujJibNbgHLYbGxkkzw++6w
	wIN7OOBpfVcBlDRhuufXUquooiFODeeQofc=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFPjzEQG5of
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-112-083.pools.arcor-ip.net [88.65.112.83])
	by post.strato.de (mrclete mo24) (RZmta 26.15 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id v053fanBGEQTO1 ;
	Fri, 16 Dec 2011 17:40:33 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 5A0F118637; Fri, 16 Dec 2011 17:40:33 +0100 (CET)
Date: Fri, 16 Dec 2011 17:40:33 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20111216164033.GA25508@aepfle.de>
References: <mailman.4227.1323785898.12970.xen-devel@lists.xensource.com>
	<3d5947b7ee3b2fdda393744f59d55b76.squirrel@webmail.lagarcavilla.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <3d5947b7ee3b2fdda393744f59d55b76.squirrel@webmail.lagarcavilla.org>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: xen-devel@lists.xensource.com, tim@xen.org
Subject: Re: [Xen-devel] [PATCH] mem_event: use wait queue when ring is full
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Dec 15, Andres Lagar-Cavilla wrote:

> > - How many requests should foreign vcpus place in the ring if the guest
> >   has more vcpus than available slots in the ring? Just a single one so
> >   that foreigners can also make some progress?
> The idea is that foreign vcpus can place as many events as they want as
> long as each guest vcpu that is not blocked on a men event has room to
> send one men event. When we reach that border condition, no more foreign
> men events.
> 
> The case for which there are way too many guest vcpus needs to be handled,
> either by capping the max number of vcpus for domains using a men event,
> or by growing the ring size.

Right now the ring is one page, so it can not hold more than 64 entries.
If that ever changes, the accounting can be adjusted.

> > - Should access and paging have the same rules for accounting?
> Absolutely.
> 
> And both should use wait queues in extreme cases in which a guest vcpu
> with a single action generates multiple memory events. Given that when we
> hit a border condition the guest vcpu will place one event and be flagged
> VPF_mem_event_paused (or whatever that flag is named), if a guest vcpu
> generates another event when flagged, that's our queue for putting the
> vcpu on a wait queue.

An extra flag is not needed.

Below is an incremental patch (on top of v6) which does some accounting.
Its just compile tested.

Olaf


diff -r 5d5d10e1568b xen/arch/x86/mm/mem_event.c
--- a/xen/arch/x86/mm/mem_event.c
+++ b/xen/arch/x86/mm/mem_event.c
@@ -114,6 +114,19 @@ static int mem_event_enable(
 
     med->pause_flag = pause_flag;
 
+    /*
+     * Configure ring accounting:
+     * Each guest vcpu should be able to place at least one request.
+     * If there are more vcpus than available slots in the ring, not all vcpus
+     * can place requests in the ring anyway.  A minimum (arbitrary) number of
+     * foreign requests will be allowed in this case.
+     */
+    if ( d->max_vcpus < RING_SIZE(&med->front_ring) )
+        med->max_foreign = RING_SIZE(&med->front_ring) - d->max_vcpus;
+    if ( med->max_foreign < 13 )
+        med->max_foreign = 13;
+    med->max_target = RING_SIZE(&med->front_ring) - med->max_foreign;
+
     init_waitqueue_head(&med->wq);
 
     /* Wake any VCPUs waiting for the ring to appear */
@@ -147,23 +160,28 @@ static int mem_event_disable(struct mem_
 
 static int _mem_event_put_request(struct domain *d,
                                   struct mem_event_domain *med,
-                                  mem_event_request_t *req)
+                                  mem_event_request_t *req,
+                                  int *done)
 {
     mem_event_front_ring_t *front_ring;
-    int free_req, claimed_req;
+    int free_req, claimed_req, ret;
     RING_IDX req_prod;
 
+    if ( *done )
+        return 1;
+
     mem_event_ring_lock(med);
 
-    free_req = RING_FREE_REQUESTS(&med->front_ring);
+    front_ring = &med->front_ring;
+
     /* Foreign requests must succeed because their vcpus can not sleep */
     claimed_req = med->foreign_producers;
+    free_req = RING_FREE_REQUESTS(front_ring);
     if ( !free_req || ( current->domain == d && free_req <= claimed_req ) ) {
         mem_event_ring_unlock(med);
         return 0;
     }
 
-    front_ring = &med->front_ring;
     req_prod = front_ring->req_prod_pvt;
 
     if ( current->domain != d )
@@ -176,9 +194,18 @@ static int _mem_event_put_request(struct
     memcpy(RING_GET_REQUEST(front_ring, req_prod), req, sizeof(*req));
     req_prod++;
 
+    ret = 1;
+    *done = 1;
+    free_req--;
+
     /* Update accounting */
     if ( current->domain == d )
+    {
         med->target_producers--;
+        /* Ring is full, no more requests from this vcpu, go to sleep */
+        if ( free_req < med->max_target )
+            ret = 0;
+    }
     else
         med->foreign_producers--;
 
@@ -190,19 +217,20 @@ static int _mem_event_put_request(struct
 
     notify_via_xen_event_channel(d, med->xen_port);
 
-    return 1;
+    return ret;
 }
 
 void mem_event_put_request(struct domain *d, struct mem_event_domain *med,
                            mem_event_request_t *req)
 {
+    int done = 0;
     /* Go to sleep if request came from guest */
     if (current->domain == d) {
-        wait_event(med->wq, _mem_event_put_request(d, med, req));
+        wait_event(med->wq, _mem_event_put_request(d, med, req, &done));
         return;
     }
     /* Ring was full anyway, unable to sleep in non-guest context */
-    if (!_mem_event_put_request(d, med, req))
+    if (!_mem_event_put_request(d, med, req, &done))
         printk("Failed to put memreq: d %u t %x f %x gfn %lx\n", d->domain_id,
                 req->type, req->flags, (unsigned long)req->gfn);
 }
@@ -341,7 +369,8 @@ int mem_event_claim_slot(struct domain *
         med->target_producers++;
         ring_full = 0;
     }
-    else if ( med->foreign_producers + med->target_producers + 1 < free_req )
+    else if ( med->foreign_producers + med->target_producers < free_req &&
+              med->foreign_producers < med->max_foreign )
     {
         med->foreign_producers++;
         ring_full = 0;
diff -r 5d5d10e1568b xen/include/xen/sched.h
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -184,8 +184,11 @@ struct mem_event_domain
 {
     /* ring lock */
     spinlock_t ring_lock;
-    unsigned short foreign_producers;
-    unsigned short target_producers;
+    /* The ring has 64 entries */
+    unsigned char foreign_producers;
+    unsigned char max_foreign;
+    unsigned char target_producers;
+    unsigned char max_target;
     /* shared page */
     mem_event_shared_page_t *shared_page;
     /* shared ring page */

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 16:54:27 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 16:54:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rbb2s-0005yP-6p; Fri, 16 Dec 2011 16:54:06 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1Rbb2q-0005yK-C2
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 16:54:04 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-4.tower-182.messagelabs.com!1324054436!7581068!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=1.1 required=7.0 tests=BODY_RANDOM_LONG,DIET_1
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14913 invoked from network); 16 Dec 2011 16:53:56 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-4.tower-182.messagelabs.com with SMTP;
	16 Dec 2011 16:53:56 -0000
Received: from [62.94.142.93] (account d.faggioli@sssup.it HELO [192.168.0.40])
	by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 73976478; Fri, 16 Dec 2011 17:53:54 +0100
Message-ID: <1324054424.2599.13.camel@Solace>
From: Dario Faggioli <raistlin@linux.it>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Fri, 16 Dec 2011 17:53:44 +0100
X-Mailer: Evolution 3.0.3-3+b1 
Mime-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCHv2] Rework locking for sched_adjust.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0469156300206918351=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--===============0469156300206918351==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-s6aQxhtWfeniZORipy49"


--=-s6aQxhtWfeniZORipy49
Content-Type: multipart/mixed; boundary="=-2gDoRwjHAIAVny3ceOG+"


--=-2gDoRwjHAIAVny3ceOG+
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

[Re-posting as the patch was damaged in the previous message]

Hi everyone,

Here it is v2 of the lock reworking around and within sched-adjust.

With respect to the first posting [1]:
 - I _did_not_ move the per-pluggable scheduler lock toward schedule.c,
   as agreed with George during review;
 - I fixed the bug in sedf spotted by Juergen the way he suggested;
 - I've finally been able to test it under all the three schedulers,=20
   and it is doing its job, at least here;

Notice the series "collapsed" in one signle patch, as it was being hard
to find a breakdown of it that does not introduce regressions and/or
transient deadlock situations worse than the ones it's trying to cure...
I hope it's still readable and comfortable to review. :-)

Thanks to everyone who provided his feedback on the first version of
this.

Regards,
Dario

[1]
http://xen.1045712.n5.nabble.com/RFC-RFT-PATCH-0-of-3-rework-locking-in-sch=
ed-adjust-td5016899.html

--
 xen/common/sched_credit.c  |   10 ++++++--
 xen/common/sched_credit2.c |   21 ++++++++++---------
 xen/common/sched_sedf.c    |  156
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++=
++++++++++++++++++++++++++++++++++++++++++++-------------------------------=
----
 xen/common/schedule.c      |   34 +-------------------------------
 4 files changed, 140 insertions(+), 81 deletions(-)

--

# HG changeset patch
# Parent 1452fb248cd513832cfbbd1100b9b72a0dde7ea6
Rework locking for sched_adjust.

The main idea is to move (as much as possible) locking logic
from generic code to the various pluggable schedulers.

While at it, the following is also accomplished:
 - pausing all the non-current VCPUs of a domain while changing its
   scheduling parameters is not effective in avoiding races and it is
   prone to deadlock, so that is removed.
 - sedf needs a global lock for preventing races while adjusting
   domains' scheduling parameters (as it is for credit and credit2),
   so that is added.

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>

diff -r 1452fb248cd5 xen/common/sched_credit.c
--- a/xen/common/sched_credit.c	Fri Dec 16 15:45:40 2011 +0100
+++ b/xen/common/sched_credit.c	Fri Dec 16 17:49:46 2011 +0100
@@ -161,6 +161,7 @@ struct csched_dom {
  * System-wide private data
  */
 struct csched_private {
+    /* lock for the whole pluggable scheduler, nests inside cpupool_lock *=
/
     spinlock_t lock;
     struct list_head active_sdom;
     uint32_t ncpus;
@@ -800,6 +801,10 @@ csched_dom_cntl(
     struct csched_private *prv =3D CSCHED_PRIV(ops);
     unsigned long flags;
=20
+    /* Protect both get and put branches with the pluggable scheduler
+     * lock. Runq lock not needed anywhere in here. */
+    spin_lock_irqsave(&prv->lock, flags);
+
     if ( op->cmd =3D=3D XEN_DOMCTL_SCHEDOP_getinfo )
     {
         op->u.credit.weight =3D sdom->weight;
@@ -809,8 +814,6 @@ csched_dom_cntl(
     {
         ASSERT(op->cmd =3D=3D XEN_DOMCTL_SCHEDOP_putinfo);
=20
-        spin_lock_irqsave(&prv->lock, flags);
-
         if ( op->u.credit.weight !=3D 0 )
         {
             if ( !list_empty(&sdom->active_sdom_elem) )
@@ -824,9 +827,10 @@ csched_dom_cntl(
         if ( op->u.credit.cap !=3D (uint16_t)~0U )
             sdom->cap =3D op->u.credit.cap;
=20
-        spin_unlock_irqrestore(&prv->lock, flags);
     }
=20
+    spin_unlock_irqrestore(&prv->lock, flags);
+
     return 0;
 }
=20
diff -r 1452fb248cd5 xen/common/sched_credit2.c
--- a/xen/common/sched_credit2.c	Fri Dec 16 15:45:40 2011 +0100
+++ b/xen/common/sched_credit2.c	Fri Dec 16 17:49:46 2011 +0100
@@ -1384,6 +1384,10 @@ csched_dom_cntl(
     struct csched_private *prv =3D CSCHED_PRIV(ops);
     unsigned long flags;
=20
+    /* Must hold csched_priv lock to read and update sdom,
+     * runq lock to update csvcs. */
+    spin_lock_irqsave(&prv->lock, flags);
+
     if ( op->cmd =3D=3D XEN_DOMCTL_SCHEDOP_getinfo )
     {
         op->u.credit2.weight =3D sdom->weight;
@@ -1397,10 +1401,6 @@ csched_dom_cntl(
             struct list_head *iter;
             int old_weight;
=20
-            /* Must hold csched_priv lock to update sdom, runq lock to
-             * update csvcs. */
-            spin_lock_irqsave(&prv->lock, flags);
-
             old_weight =3D sdom->weight;
=20
             sdom->weight =3D op->u.credit2.weight;
@@ -1411,22 +1411,23 @@ csched_dom_cntl(
                 struct csched_vcpu *svc =3D list_entry(iter, struct csched=
_vcpu, sdom_elem);
=20
                 /* NB: Locking order is important here.  Because we grab t=
his lock here, we
-                 * must never lock csched_priv.lock if we're holding a run=
queue
-                 * lock. */
-                vcpu_schedule_lock_irq(svc->vcpu);
+                 * must never lock csched_priv.lock if we're holding a run=
queue lock.
+                 * Also, calling vcpu_schedule_lock() is enough, since IRQ=
s have already
+                 * been disabled. */
+                vcpu_schedule_lock(svc->vcpu);
=20
                 BUG_ON(svc->rqd !=3D RQD(ops, svc->vcpu->processor));
=20
                 svc->weight =3D sdom->weight;
                 update_max_weight(svc->rqd, svc->weight, old_weight);
=20
-                vcpu_schedule_unlock_irq(svc->vcpu);
+                vcpu_schedule_unlock(svc->vcpu);
             }
-
-            spin_unlock_irqrestore(&prv->lock, flags);
         }
     }
=20
+    spin_unlock_irqrestore(&prv->lock, flags);
+
     return 0;
 }
=20
diff -r 1452fb248cd5 xen/common/sched_sedf.c
--- a/xen/common/sched_sedf.c	Fri Dec 16 15:45:40 2011 +0100
+++ b/xen/common/sched_sedf.c	Fri Dec 16 17:49:46 2011 +0100
@@ -61,6 +61,11 @@ struct sedf_dom_info {
     struct domain  *domain;
 };
=20
+struct sedf_priv_info {
+    /* lock for the whole pluggable scheduler, nests inside cpupool_lock *=
/
+    spinlock_t lock;
+};
+
 struct sedf_vcpu_info {
     struct vcpu *vcpu;
     struct list_head list;
@@ -115,6 +120,8 @@ struct sedf_cpu_info {
     s_time_t         current_slice_expires;
 };
=20
+#define SEDF_PRIV(_ops) \
+    ((struct sedf_priv_info *)((_ops)->sched_data))
 #define EDOM_INFO(d)   ((struct sedf_vcpu_info *)((d)->sched_priv))
 #define CPU_INFO(cpu)  \
     ((struct sedf_cpu_info *)per_cpu(schedule_data, cpu).sched_priv)
@@ -772,6 +779,31 @@ static struct task_slice sedf_do_extra_s
 }
=20
=20
+static int sedf_init(struct scheduler *ops)
+{
+    struct sedf_priv_info *prv;
+
+    prv =3D xzalloc(struct sedf_priv_info);
+    if ( prv =3D=3D NULL )
+        return -ENOMEM;
+
+    ops->sched_data =3D prv;
+    spin_lock_init(&prv->lock);
+
+    return 0;
+}
+
+
+static void sedf_deinit(const struct scheduler *ops)
+{
+    struct sedf_priv_info *prv;
+
+    prv =3D SEDF_PRIV(ops);
+    if ( prv !=3D NULL )
+        xfree(prv);
+}
+
+
 /* Main scheduling function
    Reasons for calling this function are:
    -timeslice for the current period used up
@@ -1320,22 +1352,15 @@ static void sedf_dump_cpu_state(const st
=20
=20
 /* Adjusts periods and slices of the domains accordingly to their weights.=
 */
-static int sedf_adjust_weights(struct cpupool *c, struct xen_domctl_schedu=
ler_op *cmd)
+static int sedf_adjust_weights(struct cpupool *c, int nr_cpus, int *sumw, =
s_time_t *sumt)
 {
     struct vcpu *p;
     struct domain      *d;
-    unsigned int        cpu, nr_cpus =3D cpumask_last(&cpu_online_map) + 1=
;
-    int                *sumw =3D xzalloc_array(int, nr_cpus);
-    s_time_t           *sumt =3D xzalloc_array(s_time_t, nr_cpus);
+    unsigned int        cpu;
=20
-    if ( !sumw || !sumt )
-    {
-        xfree(sumt);
-        xfree(sumw);
-        return -ENOMEM;
-    }
-
-    /* Sum across all weights. */
+    /* Sum across all weights. Notice that no runq locking is needed
+     * here: the caller holds sedf_priv_info.lock and we're not changing
+     * anything that is accessed during scheduling. */
     rcu_read_lock(&domlist_read_lock);
     for_each_domain_in_cpupool( d, c )
     {
@@ -1365,7 +1390,9 @@ static int sedf_adjust_weights(struct cp
     }
     rcu_read_unlock(&domlist_read_lock);
=20
-    /* Adjust all slices (and periods) to the new weight. */
+    /* Adjust all slices (and periods) to the new weight. Unlike above, we
+     * need to take thr runq lock for the various VCPUs: we're modyfing
+     * slice and period which are referenced during scheduling. */
     rcu_read_lock(&domlist_read_lock);
     for_each_domain_in_cpupool( d, c )
     {
@@ -1375,20 +1402,20 @@ static int sedf_adjust_weights(struct cp
                 continue;
             if ( EDOM_INFO(p)->weight )
             {
+                /* Interrupts already off */
+                vcpu_schedule_lock(p);
                 EDOM_INFO(p)->period_orig =3D=20
                     EDOM_INFO(p)->period  =3D WEIGHT_PERIOD;
                 EDOM_INFO(p)->slice_orig  =3D
                     EDOM_INFO(p)->slice   =3D=20
                     (EDOM_INFO(p)->weight *
                      (WEIGHT_PERIOD - WEIGHT_SAFETY - sumt[cpu])) / sumw[c=
pu];
+                vcpu_schedule_unlock(p);
             }
         }
     }
     rcu_read_unlock(&domlist_read_lock);
=20
-    xfree(sumt);
-    xfree(sumw);
-
     return 0;
 }
=20
@@ -1396,19 +1423,45 @@ static int sedf_adjust_weights(struct cp
 /* set or fetch domain scheduling parameters */
 static int sedf_adjust(const struct scheduler *ops, struct domain *p, stru=
ct xen_domctl_scheduler_op *op)
 {
+    struct sedf_priv_info *prv =3D SEDF_PRIV(ops);
+    unsigned long flags;
+    unsigned int nr_cpus =3D cpumask_last(&cpu_online_map) + 1;
+    int *sumw =3D xzalloc_array(int, nr_cpus);
+    s_time_t *sumt =3D xzalloc_array(s_time_t, nr_cpus);
     struct vcpu *v;
-    int rc;
+    int rc =3D 0;
=20
     PRINT(2,"sedf_adjust was called, domain-id %i new period %"PRIu64" "
           "new slice %"PRIu64"\nlatency %"PRIu64" extra:%s\n",
           p->domain_id, op->u.sedf.period, op->u.sedf.slice,
           op->u.sedf.latency, (op->u.sedf.extratime)?"yes":"no");
=20
+    /* Serialize against the pluggable scheduler lock to protect from
+     * concurrent updates. We need to take the runq lock for the VCPUs
+     * as well, since we are touching extraweight, weight, slice and
+     * period. As in sched_credit2.c, runq locks nest inside the
+     * pluggable scheduler lock. */
+    spin_lock_irqsave(&prv->lock, flags);
+
     if ( op->cmd =3D=3D XEN_DOMCTL_SCHEDOP_putinfo )
     {
+        /* These are used in sedf_adjust_weights() but have to be allocate=
d in
+         * this function, as we need to avoid nesting xmem_pool_alloc's lo=
ck
+         * within our prv->lock. */
+        if ( !sumw || !sumt )
+        {
+            /* Check for errors here, the _getinfo branch doesn't care */
+            rc =3D -ENOMEM;
+            goto out;
+        }
+
         /* Check for sane parameters. */
         if ( !op->u.sedf.period && !op->u.sedf.weight )
-            return -EINVAL;
+        {
+            rc =3D -EINVAL;
+            goto out;
+        }
+
         if ( op->u.sedf.weight )
         {
             if ( (op->u.sedf.extratime & EXTRA_AWARE) &&
@@ -1417,59 +1470,78 @@ static int sedf_adjust(const struct sche
                 /* Weight-driven domains with extratime only. */
                 for_each_vcpu ( p, v )
                 {
+                    /* (Here and everywhere in the following) IRQs are alr=
eady off,
+                     * hence vcpu_spin_lock() is the one. */
+                    vcpu_schedule_lock(v);
                     EDOM_INFO(v)->extraweight =3D op->u.sedf.weight;
                     EDOM_INFO(v)->weight =3D 0;
                     EDOM_INFO(v)->slice =3D 0;
                     EDOM_INFO(v)->period =3D WEIGHT_PERIOD;
+                    vcpu_schedule_unlock(v);
                 }
             }
             else
             {
                 /* Weight-driven domains with real-time execution. */
-                for_each_vcpu ( p, v )
+                for_each_vcpu ( p, v ) {
+                    vcpu_schedule_lock(v);
                     EDOM_INFO(v)->weight =3D op->u.sedf.weight;
+                    vcpu_schedule_unlock(v);
+                }
             }
         }
         else
         {
+            /*
+             * Sanity checking: note that disabling extra weight requires
+             * that we set a non-zero slice.
+             */
+            if ( (op->u.sedf.period > PERIOD_MAX) ||
+                 (op->u.sedf.period < PERIOD_MIN) ||
+                 (op->u.sedf.slice  > op->u.sedf.period) ||
+                 (op->u.sedf.slice  < SLICE_MIN) )
+            {
+                rc =3D -EINVAL;
+                goto out;
+            }
+
             /* Time-driven domains. */
             for_each_vcpu ( p, v )
             {
-                /*
-                 * Sanity checking: note that disabling extra weight requi=
res
-                 * that we set a non-zero slice.
-                 */
-                if ( (op->u.sedf.period > PERIOD_MAX) ||
-                     (op->u.sedf.period < PERIOD_MIN) ||
-                     (op->u.sedf.slice  > op->u.sedf.period) ||
-                     (op->u.sedf.slice  < SLICE_MIN) )
-                    return -EINVAL;
+                vcpu_schedule_lock(v);
                 EDOM_INFO(v)->weight =3D 0;
                 EDOM_INFO(v)->extraweight =3D 0;
                 EDOM_INFO(v)->period_orig =3D=20
                     EDOM_INFO(v)->period  =3D op->u.sedf.period;
                 EDOM_INFO(v)->slice_orig  =3D=20
                     EDOM_INFO(v)->slice   =3D op->u.sedf.slice;
+                vcpu_schedule_unlock(v);
             }
         }
=20
-        rc =3D sedf_adjust_weights(p->cpupool, op);
+        rc =3D sedf_adjust_weights(p->cpupool, nr_cpus, sumw, sumt);
         if ( rc )
-            return rc;
+            goto out;
=20
         for_each_vcpu ( p, v )
         {
+            vcpu_schedule_lock(v);
             EDOM_INFO(v)->status  =3D=20
                 (EDOM_INFO(v)->status &
                  ~EXTRA_AWARE) | (op->u.sedf.extratime & EXTRA_AWARE);
             EDOM_INFO(v)->latency =3D op->u.sedf.latency;
             extraq_check(v);
+            vcpu_schedule_unlock(v);
         }
     }
     else if ( op->cmd =3D=3D XEN_DOMCTL_SCHEDOP_getinfo )
     {
         if ( p->vcpu[0] =3D=3D NULL )
-            return -EINVAL;
+        {
+            rc =3D -EINVAL;
+            goto out;
+        }
+
         op->u.sedf.period    =3D EDOM_INFO(p->vcpu[0])->period;
         op->u.sedf.slice     =3D EDOM_INFO(p->vcpu[0])->slice;
         op->u.sedf.extratime =3D EDOM_INFO(p->vcpu[0])->status & EXTRA_AWA=
RE;
@@ -1477,14 +1549,23 @@ static int sedf_adjust(const struct sche
         op->u.sedf.weight    =3D EDOM_INFO(p->vcpu[0])->weight;
     }
=20
-    PRINT(2,"sedf_adjust_finished\n");
-    return 0;
+out:
+    spin_unlock_irqrestore(&prv->lock, flags);
+
+    xfree(sumt);
+    xfree(sumw);
+
+    PRINT(2,"sedf_adjust_finished with return code %d\n", rc);
+    return rc;
 }
=20
+static struct sedf_priv_info _sedf_priv;
+
 const struct scheduler sched_sedf_def =3D {
-    .name     =3D "Simple EDF Scheduler",
-    .opt_name =3D "sedf",
-    .sched_id =3D XEN_SCHEDULER_SEDF,
+    .name           =3D "Simple EDF Scheduler",
+    .opt_name       =3D "sedf",
+    .sched_id       =3D XEN_SCHEDULER_SEDF,
+    .sched_data     =3D &_sedf_priv,
    =20
     .init_domain    =3D sedf_init_domain,
     .destroy_domain =3D sedf_destroy_domain,
@@ -1498,6 +1579,9 @@ const struct scheduler sched_sedf_def =3D=20
     .alloc_domdata  =3D sedf_alloc_domdata,
     .free_domdata   =3D sedf_free_domdata,
=20
+    .init           =3D sedf_init,
+    .deinit         =3D sedf_deinit,
+
     .do_schedule    =3D sedf_do_schedule,
     .pick_cpu       =3D sedf_pick_cpu,
     .dump_cpu_state =3D sedf_dump_cpu_state,
diff -r 1452fb248cd5 xen/common/schedule.c
--- a/xen/common/schedule.c	Fri Dec 16 15:45:40 2011 +0100
+++ b/xen/common/schedule.c	Fri Dec 16 17:49:46 2011 +0100
@@ -1005,7 +1005,6 @@ int sched_id(void)
 /* Adjust scheduling parameter for a given domain. */
 long sched_adjust(struct domain *d, struct xen_domctl_scheduler_op *op)
 {
-    struct vcpu *v;
     long ret;
    =20
     if ( (op->sched_id !=3D DOM2OP(d)->sched_id) ||
@@ -1013,40 +1012,11 @@ long sched_adjust(struct domain *d, stru
           (op->cmd !=3D XEN_DOMCTL_SCHEDOP_getinfo)) )
         return -EINVAL;
=20
-    /*
-     * Most VCPUs we can simply pause. If we are adjusting this VCPU then
-     * we acquire the local schedule_lock to guard against concurrent upda=
tes.
-     *
-     * We only acquire the local schedule lock after we have paused all ot=
her
-     * VCPUs in this domain. There are two reasons for this:
-     * 1- We don't want to hold up interrupts as pausing a VCPU can
-     *    trigger a tlb shootdown.
-     * 2- Pausing other VCPUs involves briefly locking the schedule
-     *    lock of the CPU they are running on. This CPU could be the
-     *    same as ours.
-     */
-
-    for_each_vcpu ( d, v )
-    {
-        if ( v !=3D current )
-            vcpu_pause(v);
-    }
-
-    if ( d =3D=3D current->domain )
-        vcpu_schedule_lock_irq(current);
-
+    /* NB: the pluggable scheduler code needs to take care
+     * of locking by itself. */
     if ( (ret =3D SCHED_OP(DOM2OP(d), adjust, d, op)) =3D=3D 0 )
         TRACE_1D(TRC_SCHED_ADJDOM, d->domain_id);
=20
-    if ( d =3D=3D current->domain )
-        vcpu_schedule_unlock_irq(current);
-
-    for_each_vcpu ( d, v )
-    {
-        if ( v !=3D current )
-            vcpu_unpause(v);
-    }
-
     return ret;
 }
=20
--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-------------------------------------------------------------------
Dario Faggioli, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
PhD Candidate, ReTiS Lab, Scuola Superiore Sant'Anna, Pisa (Italy)


--=-2gDoRwjHAIAVny3ceOG+
Content-Disposition: attachment; filename="rework-locking-for-sched-adjust.patch"
Content-Transfer-Encoding: base64
Content-Type: text/x-patch; name="rework-locking-for-sched-adjust.patch";
	charset="UTF-8"

IyBIRyBjaGFuZ2VzZXQgcGF0Y2gNCiMgUGFyZW50IDE0NTJmYjI0OGNkNTEzODMyY2ZiYmQxMTAw
YjliNzJhMGRkZTdlYTYNClJld29yayBsb2NraW5nIGZvciBzY2hlZF9hZGp1c3QuDQoNClRoZSBt
YWluIGlkZWEgaXMgdG8gbW92ZSAoYXMgbXVjaCBhcyBwb3NzaWJsZSkgbG9ja2luZyBsb2dpYw0K
ZnJvbSBnZW5lcmljIGNvZGUgdG8gdGhlIHZhcmlvdXMgcGx1Z2dhYmxlIHNjaGVkdWxlcnMuDQoN
CldoaWxlIGF0IGl0LCB0aGUgZm9sbG93aW5nIGlzIGFsc28gYWNjb21wbGlzaGVkOg0KIC0gcGF1
c2luZyBhbGwgdGhlIG5vbi1jdXJyZW50IFZDUFVzIG9mIGEgZG9tYWluIHdoaWxlIGNoYW5naW5n
IGl0cw0KICAgc2NoZWR1bGluZyBwYXJhbWV0ZXJzIGlzIG5vdCBlZmZlY3RpdmUgaW4gYXZvaWRp
bmcgcmFjZXMgYW5kIGl0IGlzDQogICBwcm9uZSB0byBkZWFkbG9jaywgc28gdGhhdCBpcyByZW1v
dmVkLg0KIC0gc2VkZiBuZWVkcyBhIGdsb2JhbCBsb2NrIGZvciBwcmV2ZW50aW5nIHJhY2VzIHdo
aWxlIGFkanVzdGluZw0KICAgZG9tYWlucycgc2NoZWR1bGluZyBwYXJhbWV0ZXJzIChhcyBpdCBp
cyBmb3IgY3JlZGl0IGFuZCBjcmVkaXQyKSwNCiAgIHNvIHRoYXQgaXMgYWRkZWQuDQoNClNpZ25l
ZC1vZmYtYnk6IERhcmlvIEZhZ2dpb2xpIDxkYXJpby5mYWdnaW9saUBjaXRyaXguY29tPg0KDQpk
aWZmIC1yIDE0NTJmYjI0OGNkNSB4ZW4vY29tbW9uL3NjaGVkX2NyZWRpdC5jDQotLS0gYS94ZW4v
Y29tbW9uL3NjaGVkX2NyZWRpdC5jCUZyaSBEZWMgMTYgMTU6NDU6NDAgMjAxMSArMDEwMA0KKysr
IGIveGVuL2NvbW1vbi9zY2hlZF9jcmVkaXQuYwlGcmkgRGVjIDE2IDE3OjQ5OjQ2IDIwMTEgKzAx
MDANCkBAIC0xNjEsNiArMTYxLDcgQEAgc3RydWN0IGNzY2hlZF9kb20gew0KICAqIFN5c3RlbS13
aWRlIHByaXZhdGUgZGF0YQ0KICAqLw0KIHN0cnVjdCBjc2NoZWRfcHJpdmF0ZSB7DQorICAgIC8q
IGxvY2sgZm9yIHRoZSB3aG9sZSBwbHVnZ2FibGUgc2NoZWR1bGVyLCBuZXN0cyBpbnNpZGUgY3B1
cG9vbF9sb2NrICovDQogICAgIHNwaW5sb2NrX3QgbG9jazsNCiAgICAgc3RydWN0IGxpc3RfaGVh
ZCBhY3RpdmVfc2RvbTsNCiAgICAgdWludDMyX3QgbmNwdXM7DQpAQCAtODAwLDYgKzgwMSwxMCBA
QCBjc2NoZWRfZG9tX2NudGwoDQogICAgIHN0cnVjdCBjc2NoZWRfcHJpdmF0ZSAqcHJ2ID0gQ1ND
SEVEX1BSSVYob3BzKTsNCiAgICAgdW5zaWduZWQgbG9uZyBmbGFnczsNCiANCisgICAgLyogUHJv
dGVjdCBib3RoIGdldCBhbmQgcHV0IGJyYW5jaGVzIHdpdGggdGhlIHBsdWdnYWJsZSBzY2hlZHVs
ZXINCisgICAgICogbG9jay4gUnVucSBsb2NrIG5vdCBuZWVkZWQgYW55d2hlcmUgaW4gaGVyZS4g
Ki8NCisgICAgc3Bpbl9sb2NrX2lycXNhdmUoJnBydi0+bG9jaywgZmxhZ3MpOw0KKw0KICAgICBp
ZiAoIG9wLT5jbWQgPT0gWEVOX0RPTUNUTF9TQ0hFRE9QX2dldGluZm8gKQ0KICAgICB7DQogICAg
ICAgICBvcC0+dS5jcmVkaXQud2VpZ2h0ID0gc2RvbS0+d2VpZ2h0Ow0KQEAgLTgwOSw4ICs4MTQs
NiBAQCBjc2NoZWRfZG9tX2NudGwoDQogICAgIHsNCiAgICAgICAgIEFTU0VSVChvcC0+Y21kID09
IFhFTl9ET01DVExfU0NIRURPUF9wdXRpbmZvKTsNCiANCi0gICAgICAgIHNwaW5fbG9ja19pcnFz
YXZlKCZwcnYtPmxvY2ssIGZsYWdzKTsNCi0NCiAgICAgICAgIGlmICggb3AtPnUuY3JlZGl0Lndl
aWdodCAhPSAwICkNCiAgICAgICAgIHsNCiAgICAgICAgICAgICBpZiAoICFsaXN0X2VtcHR5KCZz
ZG9tLT5hY3RpdmVfc2RvbV9lbGVtKSApDQpAQCAtODI0LDkgKzgyNywxMCBAQCBjc2NoZWRfZG9t
X2NudGwoDQogICAgICAgICBpZiAoIG9wLT51LmNyZWRpdC5jYXAgIT0gKHVpbnQxNl90KX4wVSAp
DQogICAgICAgICAgICAgc2RvbS0+Y2FwID0gb3AtPnUuY3JlZGl0LmNhcDsNCiANCi0gICAgICAg
IHNwaW5fdW5sb2NrX2lycXJlc3RvcmUoJnBydi0+bG9jaywgZmxhZ3MpOw0KICAgICB9DQogDQor
ICAgIHNwaW5fdW5sb2NrX2lycXJlc3RvcmUoJnBydi0+bG9jaywgZmxhZ3MpOw0KKw0KICAgICBy
ZXR1cm4gMDsNCiB9DQogDQpkaWZmIC1yIDE0NTJmYjI0OGNkNSB4ZW4vY29tbW9uL3NjaGVkX2Ny
ZWRpdDIuYw0KLS0tIGEveGVuL2NvbW1vbi9zY2hlZF9jcmVkaXQyLmMJRnJpIERlYyAxNiAxNTo0
NTo0MCAyMDExICswMTAwDQorKysgYi94ZW4vY29tbW9uL3NjaGVkX2NyZWRpdDIuYwlGcmkgRGVj
IDE2IDE3OjQ5OjQ2IDIwMTEgKzAxMDANCkBAIC0xMzg0LDYgKzEzODQsMTAgQEAgY3NjaGVkX2Rv
bV9jbnRsKA0KICAgICBzdHJ1Y3QgY3NjaGVkX3ByaXZhdGUgKnBydiA9IENTQ0hFRF9QUklWKG9w
cyk7DQogICAgIHVuc2lnbmVkIGxvbmcgZmxhZ3M7DQogDQorICAgIC8qIE11c3QgaG9sZCBjc2No
ZWRfcHJpdiBsb2NrIHRvIHJlYWQgYW5kIHVwZGF0ZSBzZG9tLA0KKyAgICAgKiBydW5xIGxvY2sg
dG8gdXBkYXRlIGNzdmNzLiAqLw0KKyAgICBzcGluX2xvY2tfaXJxc2F2ZSgmcHJ2LT5sb2NrLCBm
bGFncyk7DQorDQogICAgIGlmICggb3AtPmNtZCA9PSBYRU5fRE9NQ1RMX1NDSEVET1BfZ2V0aW5m
byApDQogICAgIHsNCiAgICAgICAgIG9wLT51LmNyZWRpdDIud2VpZ2h0ID0gc2RvbS0+d2VpZ2h0
Ow0KQEAgLTEzOTcsMTAgKzE0MDEsNiBAQCBjc2NoZWRfZG9tX2NudGwoDQogICAgICAgICAgICAg
c3RydWN0IGxpc3RfaGVhZCAqaXRlcjsNCiAgICAgICAgICAgICBpbnQgb2xkX3dlaWdodDsNCiAN
Ci0gICAgICAgICAgICAvKiBNdXN0IGhvbGQgY3NjaGVkX3ByaXYgbG9jayB0byB1cGRhdGUgc2Rv
bSwgcnVucSBsb2NrIHRvDQotICAgICAgICAgICAgICogdXBkYXRlIGNzdmNzLiAqLw0KLSAgICAg
ICAgICAgIHNwaW5fbG9ja19pcnFzYXZlKCZwcnYtPmxvY2ssIGZsYWdzKTsNCi0NCiAgICAgICAg
ICAgICBvbGRfd2VpZ2h0ID0gc2RvbS0+d2VpZ2h0Ow0KIA0KICAgICAgICAgICAgIHNkb20tPndl
aWdodCA9IG9wLT51LmNyZWRpdDIud2VpZ2h0Ow0KQEAgLTE0MTEsMjIgKzE0MTEsMjMgQEAgY3Nj
aGVkX2RvbV9jbnRsKA0KICAgICAgICAgICAgICAgICBzdHJ1Y3QgY3NjaGVkX3ZjcHUgKnN2YyA9
IGxpc3RfZW50cnkoaXRlciwgc3RydWN0IGNzY2hlZF92Y3B1LCBzZG9tX2VsZW0pOw0KIA0KICAg
ICAgICAgICAgICAgICAvKiBOQjogTG9ja2luZyBvcmRlciBpcyBpbXBvcnRhbnQgaGVyZS4gIEJl
Y2F1c2Ugd2UgZ3JhYiB0aGlzIGxvY2sgaGVyZSwgd2UNCi0gICAgICAgICAgICAgICAgICogbXVz
dCBuZXZlciBsb2NrIGNzY2hlZF9wcml2LmxvY2sgaWYgd2UncmUgaG9sZGluZyBhIHJ1bnF1ZXVl
DQotICAgICAgICAgICAgICAgICAqIGxvY2suICovDQotICAgICAgICAgICAgICAgIHZjcHVfc2No
ZWR1bGVfbG9ja19pcnEoc3ZjLT52Y3B1KTsNCisgICAgICAgICAgICAgICAgICogbXVzdCBuZXZl
ciBsb2NrIGNzY2hlZF9wcml2LmxvY2sgaWYgd2UncmUgaG9sZGluZyBhIHJ1bnF1ZXVlIGxvY2su
DQorICAgICAgICAgICAgICAgICAqIEFsc28sIGNhbGxpbmcgdmNwdV9zY2hlZHVsZV9sb2NrKCkg
aXMgZW5vdWdoLCBzaW5jZSBJUlFzIGhhdmUgYWxyZWFkeQ0KKyAgICAgICAgICAgICAgICAgKiBi
ZWVuIGRpc2FibGVkLiAqLw0KKyAgICAgICAgICAgICAgICB2Y3B1X3NjaGVkdWxlX2xvY2soc3Zj
LT52Y3B1KTsNCiANCiAgICAgICAgICAgICAgICAgQlVHX09OKHN2Yy0+cnFkICE9IFJRRChvcHMs
IHN2Yy0+dmNwdS0+cHJvY2Vzc29yKSk7DQogDQogICAgICAgICAgICAgICAgIHN2Yy0+d2VpZ2h0
ID0gc2RvbS0+d2VpZ2h0Ow0KICAgICAgICAgICAgICAgICB1cGRhdGVfbWF4X3dlaWdodChzdmMt
PnJxZCwgc3ZjLT53ZWlnaHQsIG9sZF93ZWlnaHQpOw0KIA0KLSAgICAgICAgICAgICAgICB2Y3B1
X3NjaGVkdWxlX3VubG9ja19pcnEoc3ZjLT52Y3B1KTsNCisgICAgICAgICAgICAgICAgdmNwdV9z
Y2hlZHVsZV91bmxvY2soc3ZjLT52Y3B1KTsNCiAgICAgICAgICAgICB9DQotDQotICAgICAgICAg
ICAgc3Bpbl91bmxvY2tfaXJxcmVzdG9yZSgmcHJ2LT5sb2NrLCBmbGFncyk7DQogICAgICAgICB9
DQogICAgIH0NCiANCisgICAgc3Bpbl91bmxvY2tfaXJxcmVzdG9yZSgmcHJ2LT5sb2NrLCBmbGFn
cyk7DQorDQogICAgIHJldHVybiAwOw0KIH0NCiANCmRpZmYgLXIgMTQ1MmZiMjQ4Y2Q1IHhlbi9j
b21tb24vc2NoZWRfc2VkZi5jDQotLS0gYS94ZW4vY29tbW9uL3NjaGVkX3NlZGYuYwlGcmkgRGVj
IDE2IDE1OjQ1OjQwIDIwMTEgKzAxMDANCisrKyBiL3hlbi9jb21tb24vc2NoZWRfc2VkZi5jCUZy
aSBEZWMgMTYgMTc6NDk6NDYgMjAxMSArMDEwMA0KQEAgLTYxLDYgKzYxLDExIEBAIHN0cnVjdCBz
ZWRmX2RvbV9pbmZvIHsNCiAgICAgc3RydWN0IGRvbWFpbiAgKmRvbWFpbjsNCiB9Ow0KIA0KK3N0
cnVjdCBzZWRmX3ByaXZfaW5mbyB7DQorICAgIC8qIGxvY2sgZm9yIHRoZSB3aG9sZSBwbHVnZ2Fi
bGUgc2NoZWR1bGVyLCBuZXN0cyBpbnNpZGUgY3B1cG9vbF9sb2NrICovDQorICAgIHNwaW5sb2Nr
X3QgbG9jazsNCit9Ow0KKw0KIHN0cnVjdCBzZWRmX3ZjcHVfaW5mbyB7DQogICAgIHN0cnVjdCB2
Y3B1ICp2Y3B1Ow0KICAgICBzdHJ1Y3QgbGlzdF9oZWFkIGxpc3Q7DQpAQCAtMTE1LDYgKzEyMCw4
IEBAIHN0cnVjdCBzZWRmX2NwdV9pbmZvIHsNCiAgICAgc190aW1lX3QgICAgICAgICBjdXJyZW50
X3NsaWNlX2V4cGlyZXM7DQogfTsNCiANCisjZGVmaW5lIFNFREZfUFJJVihfb3BzKSBcDQorICAg
ICgoc3RydWN0IHNlZGZfcHJpdl9pbmZvICopKChfb3BzKS0+c2NoZWRfZGF0YSkpDQogI2RlZmlu
ZSBFRE9NX0lORk8oZCkgICAoKHN0cnVjdCBzZWRmX3ZjcHVfaW5mbyAqKSgoZCktPnNjaGVkX3By
aXYpKQ0KICNkZWZpbmUgQ1BVX0lORk8oY3B1KSAgXA0KICAgICAoKHN0cnVjdCBzZWRmX2NwdV9p
bmZvICopcGVyX2NwdShzY2hlZHVsZV9kYXRhLCBjcHUpLnNjaGVkX3ByaXYpDQpAQCAtNzcyLDYg
Kzc3OSwzMSBAQCBzdGF0aWMgc3RydWN0IHRhc2tfc2xpY2Ugc2VkZl9kb19leHRyYV9zDQogfQ0K
IA0KIA0KK3N0YXRpYyBpbnQgc2VkZl9pbml0KHN0cnVjdCBzY2hlZHVsZXIgKm9wcykNCit7DQor
ICAgIHN0cnVjdCBzZWRmX3ByaXZfaW5mbyAqcHJ2Ow0KKw0KKyAgICBwcnYgPSB4emFsbG9jKHN0
cnVjdCBzZWRmX3ByaXZfaW5mbyk7DQorICAgIGlmICggcHJ2ID09IE5VTEwgKQ0KKyAgICAgICAg
cmV0dXJuIC1FTk9NRU07DQorDQorICAgIG9wcy0+c2NoZWRfZGF0YSA9IHBydjsNCisgICAgc3Bp
bl9sb2NrX2luaXQoJnBydi0+bG9jayk7DQorDQorICAgIHJldHVybiAwOw0KK30NCisNCisNCitz
dGF0aWMgdm9pZCBzZWRmX2RlaW5pdChjb25zdCBzdHJ1Y3Qgc2NoZWR1bGVyICpvcHMpDQorew0K
KyAgICBzdHJ1Y3Qgc2VkZl9wcml2X2luZm8gKnBydjsNCisNCisgICAgcHJ2ID0gU0VERl9QUklW
KG9wcyk7DQorICAgIGlmICggcHJ2ICE9IE5VTEwgKQ0KKyAgICAgICAgeGZyZWUocHJ2KTsNCit9
DQorDQorDQogLyogTWFpbiBzY2hlZHVsaW5nIGZ1bmN0aW9uDQogICAgUmVhc29ucyBmb3IgY2Fs
bGluZyB0aGlzIGZ1bmN0aW9uIGFyZToNCiAgICAtdGltZXNsaWNlIGZvciB0aGUgY3VycmVudCBw
ZXJpb2QgdXNlZCB1cA0KQEAgLTEzMjAsMjIgKzEzNTIsMTUgQEAgc3RhdGljIHZvaWQgc2VkZl9k
dW1wX2NwdV9zdGF0ZShjb25zdCBzdA0KIA0KIA0KIC8qIEFkanVzdHMgcGVyaW9kcyBhbmQgc2xp
Y2VzIG9mIHRoZSBkb21haW5zIGFjY29yZGluZ2x5IHRvIHRoZWlyIHdlaWdodHMuICovDQotc3Rh
dGljIGludCBzZWRmX2FkanVzdF93ZWlnaHRzKHN0cnVjdCBjcHVwb29sICpjLCBzdHJ1Y3QgeGVu
X2RvbWN0bF9zY2hlZHVsZXJfb3AgKmNtZCkNCitzdGF0aWMgaW50IHNlZGZfYWRqdXN0X3dlaWdo
dHMoc3RydWN0IGNwdXBvb2wgKmMsIGludCBucl9jcHVzLCBpbnQgKnN1bXcsIHNfdGltZV90ICpz
dW10KQ0KIHsNCiAgICAgc3RydWN0IHZjcHUgKnA7DQogICAgIHN0cnVjdCBkb21haW4gICAgICAq
ZDsNCi0gICAgdW5zaWduZWQgaW50ICAgICAgICBjcHUsIG5yX2NwdXMgPSBjcHVtYXNrX2xhc3Qo
JmNwdV9vbmxpbmVfbWFwKSArIDE7DQotICAgIGludCAgICAgICAgICAgICAgICAqc3VtdyA9IHh6
YWxsb2NfYXJyYXkoaW50LCBucl9jcHVzKTsNCi0gICAgc190aW1lX3QgICAgICAgICAgICpzdW10
ID0geHphbGxvY19hcnJheShzX3RpbWVfdCwgbnJfY3B1cyk7DQorICAgIHVuc2lnbmVkIGludCAg
ICAgICAgY3B1Ow0KIA0KLSAgICBpZiAoICFzdW13IHx8ICFzdW10ICkNCi0gICAgew0KLSAgICAg
ICAgeGZyZWUoc3VtdCk7DQotICAgICAgICB4ZnJlZShzdW13KTsNCi0gICAgICAgIHJldHVybiAt
RU5PTUVNOw0KLSAgICB9DQotDQotICAgIC8qIFN1bSBhY3Jvc3MgYWxsIHdlaWdodHMuICovDQor
ICAgIC8qIFN1bSBhY3Jvc3MgYWxsIHdlaWdodHMuIE5vdGljZSB0aGF0IG5vIHJ1bnEgbG9ja2lu
ZyBpcyBuZWVkZWQNCisgICAgICogaGVyZTogdGhlIGNhbGxlciBob2xkcyBzZWRmX3ByaXZfaW5m
by5sb2NrIGFuZCB3ZSdyZSBub3QgY2hhbmdpbmcNCisgICAgICogYW55dGhpbmcgdGhhdCBpcyBh
Y2Nlc3NlZCBkdXJpbmcgc2NoZWR1bGluZy4gKi8NCiAgICAgcmN1X3JlYWRfbG9jaygmZG9tbGlz
dF9yZWFkX2xvY2spOw0KICAgICBmb3JfZWFjaF9kb21haW5faW5fY3B1cG9vbCggZCwgYyApDQog
ICAgIHsNCkBAIC0xMzY1LDcgKzEzOTAsOSBAQCBzdGF0aWMgaW50IHNlZGZfYWRqdXN0X3dlaWdo
dHMoc3RydWN0IGNwDQogICAgIH0NCiAgICAgcmN1X3JlYWRfdW5sb2NrKCZkb21saXN0X3JlYWRf
bG9jayk7DQogDQotICAgIC8qIEFkanVzdCBhbGwgc2xpY2VzIChhbmQgcGVyaW9kcykgdG8gdGhl
IG5ldyB3ZWlnaHQuICovDQorICAgIC8qIEFkanVzdCBhbGwgc2xpY2VzIChhbmQgcGVyaW9kcykg
dG8gdGhlIG5ldyB3ZWlnaHQuIFVubGlrZSBhYm92ZSwgd2UNCisgICAgICogbmVlZCB0byB0YWtl
IHRociBydW5xIGxvY2sgZm9yIHRoZSB2YXJpb3VzIFZDUFVzOiB3ZSdyZSBtb2R5ZmluZw0KKyAg
ICAgKiBzbGljZSBhbmQgcGVyaW9kIHdoaWNoIGFyZSByZWZlcmVuY2VkIGR1cmluZyBzY2hlZHVs
aW5nLiAqLw0KICAgICByY3VfcmVhZF9sb2NrKCZkb21saXN0X3JlYWRfbG9jayk7DQogICAgIGZv
cl9lYWNoX2RvbWFpbl9pbl9jcHVwb29sKCBkLCBjICkNCiAgICAgew0KQEAgLTEzNzUsMjAgKzE0
MDIsMjAgQEAgc3RhdGljIGludCBzZWRmX2FkanVzdF93ZWlnaHRzKHN0cnVjdCBjcA0KICAgICAg
ICAgICAgICAgICBjb250aW51ZTsNCiAgICAgICAgICAgICBpZiAoIEVET01fSU5GTyhwKS0+d2Vp
Z2h0ICkNCiAgICAgICAgICAgICB7DQorICAgICAgICAgICAgICAgIC8qIEludGVycnVwdHMgYWxy
ZWFkeSBvZmYgKi8NCisgICAgICAgICAgICAgICAgdmNwdV9zY2hlZHVsZV9sb2NrKHApOw0KICAg
ICAgICAgICAgICAgICBFRE9NX0lORk8ocCktPnBlcmlvZF9vcmlnID0gDQogICAgICAgICAgICAg
ICAgICAgICBFRE9NX0lORk8ocCktPnBlcmlvZCAgPSBXRUlHSFRfUEVSSU9EOw0KICAgICAgICAg
ICAgICAgICBFRE9NX0lORk8ocCktPnNsaWNlX29yaWcgID0NCiAgICAgICAgICAgICAgICAgICAg
IEVET01fSU5GTyhwKS0+c2xpY2UgICA9IA0KICAgICAgICAgICAgICAgICAgICAgKEVET01fSU5G
TyhwKS0+d2VpZ2h0ICoNCiAgICAgICAgICAgICAgICAgICAgICAoV0VJR0hUX1BFUklPRCAtIFdF
SUdIVF9TQUZFVFkgLSBzdW10W2NwdV0pKSAvIHN1bXdbY3B1XTsNCisgICAgICAgICAgICAgICAg
dmNwdV9zY2hlZHVsZV91bmxvY2socCk7DQogICAgICAgICAgICAgfQ0KICAgICAgICAgfQ0KICAg
ICB9DQogICAgIHJjdV9yZWFkX3VubG9jaygmZG9tbGlzdF9yZWFkX2xvY2spOw0KIA0KLSAgICB4
ZnJlZShzdW10KTsNCi0gICAgeGZyZWUoc3Vtdyk7DQotDQogICAgIHJldHVybiAwOw0KIH0NCiAN
CkBAIC0xMzk2LDE5ICsxNDIzLDQ1IEBAIHN0YXRpYyBpbnQgc2VkZl9hZGp1c3Rfd2VpZ2h0cyhz
dHJ1Y3QgY3ANCiAvKiBzZXQgb3IgZmV0Y2ggZG9tYWluIHNjaGVkdWxpbmcgcGFyYW1ldGVycyAq
Lw0KIHN0YXRpYyBpbnQgc2VkZl9hZGp1c3QoY29uc3Qgc3RydWN0IHNjaGVkdWxlciAqb3BzLCBz
dHJ1Y3QgZG9tYWluICpwLCBzdHJ1Y3QgeGVuX2RvbWN0bF9zY2hlZHVsZXJfb3AgKm9wKQ0KIHsN
CisgICAgc3RydWN0IHNlZGZfcHJpdl9pbmZvICpwcnYgPSBTRURGX1BSSVYob3BzKTsNCisgICAg
dW5zaWduZWQgbG9uZyBmbGFnczsNCisgICAgdW5zaWduZWQgaW50IG5yX2NwdXMgPSBjcHVtYXNr
X2xhc3QoJmNwdV9vbmxpbmVfbWFwKSArIDE7DQorICAgIGludCAqc3VtdyA9IHh6YWxsb2NfYXJy
YXkoaW50LCBucl9jcHVzKTsNCisgICAgc190aW1lX3QgKnN1bXQgPSB4emFsbG9jX2FycmF5KHNf
dGltZV90LCBucl9jcHVzKTsNCiAgICAgc3RydWN0IHZjcHUgKnY7DQotICAgIGludCByYzsNCisg
ICAgaW50IHJjID0gMDsNCiANCiAgICAgUFJJTlQoMiwic2VkZl9hZGp1c3Qgd2FzIGNhbGxlZCwg
ZG9tYWluLWlkICVpIG5ldyBwZXJpb2QgJSJQUkl1NjQiICINCiAgICAgICAgICAgIm5ldyBzbGlj
ZSAlIlBSSXU2NCJcbmxhdGVuY3kgJSJQUkl1NjQiIGV4dHJhOiVzXG4iLA0KICAgICAgICAgICBw
LT5kb21haW5faWQsIG9wLT51LnNlZGYucGVyaW9kLCBvcC0+dS5zZWRmLnNsaWNlLA0KICAgICAg
ICAgICBvcC0+dS5zZWRmLmxhdGVuY3ksIChvcC0+dS5zZWRmLmV4dHJhdGltZSk/InllcyI6Im5v
Iik7DQogDQorICAgIC8qIFNlcmlhbGl6ZSBhZ2FpbnN0IHRoZSBwbHVnZ2FibGUgc2NoZWR1bGVy
IGxvY2sgdG8gcHJvdGVjdCBmcm9tDQorICAgICAqIGNvbmN1cnJlbnQgdXBkYXRlcy4gV2UgbmVl
ZCB0byB0YWtlIHRoZSBydW5xIGxvY2sgZm9yIHRoZSBWQ1BVcw0KKyAgICAgKiBhcyB3ZWxsLCBz
aW5jZSB3ZSBhcmUgdG91Y2hpbmcgZXh0cmF3ZWlnaHQsIHdlaWdodCwgc2xpY2UgYW5kDQorICAg
ICAqIHBlcmlvZC4gQXMgaW4gc2NoZWRfY3JlZGl0Mi5jLCBydW5xIGxvY2tzIG5lc3QgaW5zaWRl
IHRoZQ0KKyAgICAgKiBwbHVnZ2FibGUgc2NoZWR1bGVyIGxvY2suICovDQorICAgIHNwaW5fbG9j
a19pcnFzYXZlKCZwcnYtPmxvY2ssIGZsYWdzKTsNCisNCiAgICAgaWYgKCBvcC0+Y21kID09IFhF
Tl9ET01DVExfU0NIRURPUF9wdXRpbmZvICkNCiAgICAgew0KKyAgICAgICAgLyogVGhlc2UgYXJl
IHVzZWQgaW4gc2VkZl9hZGp1c3Rfd2VpZ2h0cygpIGJ1dCBoYXZlIHRvIGJlIGFsbG9jYXRlZCBp
bg0KKyAgICAgICAgICogdGhpcyBmdW5jdGlvbiwgYXMgd2UgbmVlZCB0byBhdm9pZCBuZXN0aW5n
IHhtZW1fcG9vbF9hbGxvYydzIGxvY2sNCisgICAgICAgICAqIHdpdGhpbiBvdXIgcHJ2LT5sb2Nr
LiAqLw0KKyAgICAgICAgaWYgKCAhc3VtdyB8fCAhc3VtdCApDQorICAgICAgICB7DQorICAgICAg
ICAgICAgLyogQ2hlY2sgZm9yIGVycm9ycyBoZXJlLCB0aGUgX2dldGluZm8gYnJhbmNoIGRvZXNu
J3QgY2FyZSAqLw0KKyAgICAgICAgICAgIHJjID0gLUVOT01FTTsNCisgICAgICAgICAgICBnb3Rv
IG91dDsNCisgICAgICAgIH0NCisNCiAgICAgICAgIC8qIENoZWNrIGZvciBzYW5lIHBhcmFtZXRl
cnMuICovDQogICAgICAgICBpZiAoICFvcC0+dS5zZWRmLnBlcmlvZCAmJiAhb3AtPnUuc2VkZi53
ZWlnaHQgKQ0KLSAgICAgICAgICAgIHJldHVybiAtRUlOVkFMOw0KKyAgICAgICAgew0KKyAgICAg
ICAgICAgIHJjID0gLUVJTlZBTDsNCisgICAgICAgICAgICBnb3RvIG91dDsNCisgICAgICAgIH0N
CisNCiAgICAgICAgIGlmICggb3AtPnUuc2VkZi53ZWlnaHQgKQ0KICAgICAgICAgew0KICAgICAg
ICAgICAgIGlmICggKG9wLT51LnNlZGYuZXh0cmF0aW1lICYgRVhUUkFfQVdBUkUpICYmDQpAQCAt
MTQxNyw1OSArMTQ3MCw3OCBAQCBzdGF0aWMgaW50IHNlZGZfYWRqdXN0KGNvbnN0IHN0cnVjdCBz
Y2hlDQogICAgICAgICAgICAgICAgIC8qIFdlaWdodC1kcml2ZW4gZG9tYWlucyB3aXRoIGV4dHJh
dGltZSBvbmx5LiAqLw0KICAgICAgICAgICAgICAgICBmb3JfZWFjaF92Y3B1ICggcCwgdiApDQog
ICAgICAgICAgICAgICAgIHsNCisgICAgICAgICAgICAgICAgICAgIC8qIChIZXJlIGFuZCBldmVy
eXdoZXJlIGluIHRoZSBmb2xsb3dpbmcpIElSUXMgYXJlIGFscmVhZHkgb2ZmLA0KKyAgICAgICAg
ICAgICAgICAgICAgICogaGVuY2UgdmNwdV9zcGluX2xvY2soKSBpcyB0aGUgb25lLiAqLw0KKyAg
ICAgICAgICAgICAgICAgICAgdmNwdV9zY2hlZHVsZV9sb2NrKHYpOw0KICAgICAgICAgICAgICAg
ICAgICAgRURPTV9JTkZPKHYpLT5leHRyYXdlaWdodCA9IG9wLT51LnNlZGYud2VpZ2h0Ow0KICAg
ICAgICAgICAgICAgICAgICAgRURPTV9JTkZPKHYpLT53ZWlnaHQgPSAwOw0KICAgICAgICAgICAg
ICAgICAgICAgRURPTV9JTkZPKHYpLT5zbGljZSA9IDA7DQogICAgICAgICAgICAgICAgICAgICBF
RE9NX0lORk8odiktPnBlcmlvZCA9IFdFSUdIVF9QRVJJT0Q7DQorICAgICAgICAgICAgICAgICAg
ICB2Y3B1X3NjaGVkdWxlX3VubG9jayh2KTsNCiAgICAgICAgICAgICAgICAgfQ0KICAgICAgICAg
ICAgIH0NCiAgICAgICAgICAgICBlbHNlDQogICAgICAgICAgICAgew0KICAgICAgICAgICAgICAg
ICAvKiBXZWlnaHQtZHJpdmVuIGRvbWFpbnMgd2l0aCByZWFsLXRpbWUgZXhlY3V0aW9uLiAqLw0K
LSAgICAgICAgICAgICAgICBmb3JfZWFjaF92Y3B1ICggcCwgdiApDQorICAgICAgICAgICAgICAg
IGZvcl9lYWNoX3ZjcHUgKCBwLCB2ICkgew0KKyAgICAgICAgICAgICAgICAgICAgdmNwdV9zY2hl
ZHVsZV9sb2NrKHYpOw0KICAgICAgICAgICAgICAgICAgICAgRURPTV9JTkZPKHYpLT53ZWlnaHQg
PSBvcC0+dS5zZWRmLndlaWdodDsNCisgICAgICAgICAgICAgICAgICAgIHZjcHVfc2NoZWR1bGVf
dW5sb2NrKHYpOw0KKyAgICAgICAgICAgICAgICB9DQogICAgICAgICAgICAgfQ0KICAgICAgICAg
fQ0KICAgICAgICAgZWxzZQ0KICAgICAgICAgew0KKyAgICAgICAgICAgIC8qDQorICAgICAgICAg
ICAgICogU2FuaXR5IGNoZWNraW5nOiBub3RlIHRoYXQgZGlzYWJsaW5nIGV4dHJhIHdlaWdodCBy
ZXF1aXJlcw0KKyAgICAgICAgICAgICAqIHRoYXQgd2Ugc2V0IGEgbm9uLXplcm8gc2xpY2UuDQor
ICAgICAgICAgICAgICovDQorICAgICAgICAgICAgaWYgKCAob3AtPnUuc2VkZi5wZXJpb2QgPiBQ
RVJJT0RfTUFYKSB8fA0KKyAgICAgICAgICAgICAgICAgKG9wLT51LnNlZGYucGVyaW9kIDwgUEVS
SU9EX01JTikgfHwNCisgICAgICAgICAgICAgICAgIChvcC0+dS5zZWRmLnNsaWNlICA+IG9wLT51
LnNlZGYucGVyaW9kKSB8fA0KKyAgICAgICAgICAgICAgICAgKG9wLT51LnNlZGYuc2xpY2UgIDwg
U0xJQ0VfTUlOKSApDQorICAgICAgICAgICAgew0KKyAgICAgICAgICAgICAgICByYyA9IC1FSU5W
QUw7DQorICAgICAgICAgICAgICAgIGdvdG8gb3V0Ow0KKyAgICAgICAgICAgIH0NCisNCiAgICAg
ICAgICAgICAvKiBUaW1lLWRyaXZlbiBkb21haW5zLiAqLw0KICAgICAgICAgICAgIGZvcl9lYWNo
X3ZjcHUgKCBwLCB2ICkNCiAgICAgICAgICAgICB7DQotICAgICAgICAgICAgICAgIC8qDQotICAg
ICAgICAgICAgICAgICAqIFNhbml0eSBjaGVja2luZzogbm90ZSB0aGF0IGRpc2FibGluZyBleHRy
YSB3ZWlnaHQgcmVxdWlyZXMNCi0gICAgICAgICAgICAgICAgICogdGhhdCB3ZSBzZXQgYSBub24t
emVybyBzbGljZS4NCi0gICAgICAgICAgICAgICAgICovDQotICAgICAgICAgICAgICAgIGlmICgg
KG9wLT51LnNlZGYucGVyaW9kID4gUEVSSU9EX01BWCkgfHwNCi0gICAgICAgICAgICAgICAgICAg
ICAob3AtPnUuc2VkZi5wZXJpb2QgPCBQRVJJT0RfTUlOKSB8fA0KLSAgICAgICAgICAgICAgICAg
ICAgIChvcC0+dS5zZWRmLnNsaWNlICA+IG9wLT51LnNlZGYucGVyaW9kKSB8fA0KLSAgICAgICAg
ICAgICAgICAgICAgIChvcC0+dS5zZWRmLnNsaWNlICA8IFNMSUNFX01JTikgKQ0KLSAgICAgICAg
ICAgICAgICAgICAgcmV0dXJuIC1FSU5WQUw7DQorICAgICAgICAgICAgICAgIHZjcHVfc2NoZWR1
bGVfbG9jayh2KTsNCiAgICAgICAgICAgICAgICAgRURPTV9JTkZPKHYpLT53ZWlnaHQgPSAwOw0K
ICAgICAgICAgICAgICAgICBFRE9NX0lORk8odiktPmV4dHJhd2VpZ2h0ID0gMDsNCiAgICAgICAg
ICAgICAgICAgRURPTV9JTkZPKHYpLT5wZXJpb2Rfb3JpZyA9IA0KICAgICAgICAgICAgICAgICAg
ICAgRURPTV9JTkZPKHYpLT5wZXJpb2QgID0gb3AtPnUuc2VkZi5wZXJpb2Q7DQogICAgICAgICAg
ICAgICAgIEVET01fSU5GTyh2KS0+c2xpY2Vfb3JpZyAgPSANCiAgICAgICAgICAgICAgICAgICAg
IEVET01fSU5GTyh2KS0+c2xpY2UgICA9IG9wLT51LnNlZGYuc2xpY2U7DQorICAgICAgICAgICAg
ICAgIHZjcHVfc2NoZWR1bGVfdW5sb2NrKHYpOw0KICAgICAgICAgICAgIH0NCiAgICAgICAgIH0N
CiANCi0gICAgICAgIHJjID0gc2VkZl9hZGp1c3Rfd2VpZ2h0cyhwLT5jcHVwb29sLCBvcCk7DQor
ICAgICAgICByYyA9IHNlZGZfYWRqdXN0X3dlaWdodHMocC0+Y3B1cG9vbCwgbnJfY3B1cywgc3Vt
dywgc3VtdCk7DQogICAgICAgICBpZiAoIHJjICkNCi0gICAgICAgICAgICByZXR1cm4gcmM7DQor
ICAgICAgICAgICAgZ290byBvdXQ7DQogDQogICAgICAgICBmb3JfZWFjaF92Y3B1ICggcCwgdiAp
DQogICAgICAgICB7DQorICAgICAgICAgICAgdmNwdV9zY2hlZHVsZV9sb2NrKHYpOw0KICAgICAg
ICAgICAgIEVET01fSU5GTyh2KS0+c3RhdHVzICA9IA0KICAgICAgICAgICAgICAgICAoRURPTV9J
TkZPKHYpLT5zdGF0dXMgJg0KICAgICAgICAgICAgICAgICAgfkVYVFJBX0FXQVJFKSB8IChvcC0+
dS5zZWRmLmV4dHJhdGltZSAmIEVYVFJBX0FXQVJFKTsNCiAgICAgICAgICAgICBFRE9NX0lORk8o
diktPmxhdGVuY3kgPSBvcC0+dS5zZWRmLmxhdGVuY3k7DQogICAgICAgICAgICAgZXh0cmFxX2No
ZWNrKHYpOw0KKyAgICAgICAgICAgIHZjcHVfc2NoZWR1bGVfdW5sb2NrKHYpOw0KICAgICAgICAg
fQ0KICAgICB9DQogICAgIGVsc2UgaWYgKCBvcC0+Y21kID09IFhFTl9ET01DVExfU0NIRURPUF9n
ZXRpbmZvICkNCiAgICAgew0KICAgICAgICAgaWYgKCBwLT52Y3B1WzBdID09IE5VTEwgKQ0KLSAg
ICAgICAgICAgIHJldHVybiAtRUlOVkFMOw0KKyAgICAgICAgew0KKyAgICAgICAgICAgIHJjID0g
LUVJTlZBTDsNCisgICAgICAgICAgICBnb3RvIG91dDsNCisgICAgICAgIH0NCisNCiAgICAgICAg
IG9wLT51LnNlZGYucGVyaW9kICAgID0gRURPTV9JTkZPKHAtPnZjcHVbMF0pLT5wZXJpb2Q7DQog
ICAgICAgICBvcC0+dS5zZWRmLnNsaWNlICAgICA9IEVET01fSU5GTyhwLT52Y3B1WzBdKS0+c2xp
Y2U7DQogICAgICAgICBvcC0+dS5zZWRmLmV4dHJhdGltZSA9IEVET01fSU5GTyhwLT52Y3B1WzBd
KS0+c3RhdHVzICYgRVhUUkFfQVdBUkU7DQpAQCAtMTQ3NywxNCArMTU0OSwyMyBAQCBzdGF0aWMg
aW50IHNlZGZfYWRqdXN0KGNvbnN0IHN0cnVjdCBzY2hlDQogICAgICAgICBvcC0+dS5zZWRmLndl
aWdodCAgICA9IEVET01fSU5GTyhwLT52Y3B1WzBdKS0+d2VpZ2h0Ow0KICAgICB9DQogDQotICAg
IFBSSU5UKDIsInNlZGZfYWRqdXN0X2ZpbmlzaGVkXG4iKTsNCi0gICAgcmV0dXJuIDA7DQorb3V0
Og0KKyAgICBzcGluX3VubG9ja19pcnFyZXN0b3JlKCZwcnYtPmxvY2ssIGZsYWdzKTsNCisNCisg
ICAgeGZyZWUoc3VtdCk7DQorICAgIHhmcmVlKHN1bXcpOw0KKw0KKyAgICBQUklOVCgyLCJzZWRm
X2FkanVzdF9maW5pc2hlZCB3aXRoIHJldHVybiBjb2RlICVkXG4iLCByYyk7DQorICAgIHJldHVy
biByYzsNCiB9DQogDQorc3RhdGljIHN0cnVjdCBzZWRmX3ByaXZfaW5mbyBfc2VkZl9wcml2Ow0K
Kw0KIGNvbnN0IHN0cnVjdCBzY2hlZHVsZXIgc2NoZWRfc2VkZl9kZWYgPSB7DQotICAgIC5uYW1l
ICAgICA9ICJTaW1wbGUgRURGIFNjaGVkdWxlciIsDQotICAgIC5vcHRfbmFtZSA9ICJzZWRmIiwN
Ci0gICAgLnNjaGVkX2lkID0gWEVOX1NDSEVEVUxFUl9TRURGLA0KKyAgICAubmFtZSAgICAgICAg
ICAgPSAiU2ltcGxlIEVERiBTY2hlZHVsZXIiLA0KKyAgICAub3B0X25hbWUgICAgICAgPSAic2Vk
ZiIsDQorICAgIC5zY2hlZF9pZCAgICAgICA9IFhFTl9TQ0hFRFVMRVJfU0VERiwNCisgICAgLnNj
aGVkX2RhdGEgICAgID0gJl9zZWRmX3ByaXYsDQogICAgIA0KICAgICAuaW5pdF9kb21haW4gICAg
PSBzZWRmX2luaXRfZG9tYWluLA0KICAgICAuZGVzdHJveV9kb21haW4gPSBzZWRmX2Rlc3Ryb3lf
ZG9tYWluLA0KQEAgLTE0OTgsNiArMTU3OSw5IEBAIGNvbnN0IHN0cnVjdCBzY2hlZHVsZXIgc2No
ZWRfc2VkZl9kZWYgPSANCiAgICAgLmFsbG9jX2RvbWRhdGEgID0gc2VkZl9hbGxvY19kb21kYXRh
LA0KICAgICAuZnJlZV9kb21kYXRhICAgPSBzZWRmX2ZyZWVfZG9tZGF0YSwNCiANCisgICAgLmlu
aXQgICAgICAgICAgID0gc2VkZl9pbml0LA0KKyAgICAuZGVpbml0ICAgICAgICAgPSBzZWRmX2Rl
aW5pdCwNCisNCiAgICAgLmRvX3NjaGVkdWxlICAgID0gc2VkZl9kb19zY2hlZHVsZSwNCiAgICAg
LnBpY2tfY3B1ICAgICAgID0gc2VkZl9waWNrX2NwdSwNCiAgICAgLmR1bXBfY3B1X3N0YXRlID0g
c2VkZl9kdW1wX2NwdV9zdGF0ZSwNCmRpZmYgLXIgMTQ1MmZiMjQ4Y2Q1IHhlbi9jb21tb24vc2No
ZWR1bGUuYw0KLS0tIGEveGVuL2NvbW1vbi9zY2hlZHVsZS5jCUZyaSBEZWMgMTYgMTU6NDU6NDAg
MjAxMSArMDEwMA0KKysrIGIveGVuL2NvbW1vbi9zY2hlZHVsZS5jCUZyaSBEZWMgMTYgMTc6NDk6
NDYgMjAxMSArMDEwMA0KQEAgLTEwMDUsNyArMTAwNSw2IEBAIGludCBzY2hlZF9pZCh2b2lkKQ0K
IC8qIEFkanVzdCBzY2hlZHVsaW5nIHBhcmFtZXRlciBmb3IgYSBnaXZlbiBkb21haW4uICovDQog
bG9uZyBzY2hlZF9hZGp1c3Qoc3RydWN0IGRvbWFpbiAqZCwgc3RydWN0IHhlbl9kb21jdGxfc2No
ZWR1bGVyX29wICpvcCkNCiB7DQotICAgIHN0cnVjdCB2Y3B1ICp2Ow0KICAgICBsb25nIHJldDsN
CiAgICAgDQogICAgIGlmICggKG9wLT5zY2hlZF9pZCAhPSBET00yT1AoZCktPnNjaGVkX2lkKSB8
fA0KQEAgLTEwMTMsNDAgKzEwMTIsMTEgQEAgbG9uZyBzY2hlZF9hZGp1c3Qoc3RydWN0IGRvbWFp
biAqZCwgc3RydQ0KICAgICAgICAgICAob3AtPmNtZCAhPSBYRU5fRE9NQ1RMX1NDSEVET1BfZ2V0
aW5mbykpICkNCiAgICAgICAgIHJldHVybiAtRUlOVkFMOw0KIA0KLSAgICAvKg0KLSAgICAgKiBN
b3N0IFZDUFVzIHdlIGNhbiBzaW1wbHkgcGF1c2UuIElmIHdlIGFyZSBhZGp1c3RpbmcgdGhpcyBW
Q1BVIHRoZW4NCi0gICAgICogd2UgYWNxdWlyZSB0aGUgbG9jYWwgc2NoZWR1bGVfbG9jayB0byBn
dWFyZCBhZ2FpbnN0IGNvbmN1cnJlbnQgdXBkYXRlcy4NCi0gICAgICoNCi0gICAgICogV2Ugb25s
eSBhY3F1aXJlIHRoZSBsb2NhbCBzY2hlZHVsZSBsb2NrIGFmdGVyIHdlIGhhdmUgcGF1c2VkIGFs
bCBvdGhlcg0KLSAgICAgKiBWQ1BVcyBpbiB0aGlzIGRvbWFpbi4gVGhlcmUgYXJlIHR3byByZWFz
b25zIGZvciB0aGlzOg0KLSAgICAgKiAxLSBXZSBkb24ndCB3YW50IHRvIGhvbGQgdXAgaW50ZXJy
dXB0cyBhcyBwYXVzaW5nIGEgVkNQVSBjYW4NCi0gICAgICogICAgdHJpZ2dlciBhIHRsYiBzaG9v
dGRvd24uDQotICAgICAqIDItIFBhdXNpbmcgb3RoZXIgVkNQVXMgaW52b2x2ZXMgYnJpZWZseSBs
b2NraW5nIHRoZSBzY2hlZHVsZQ0KLSAgICAgKiAgICBsb2NrIG9mIHRoZSBDUFUgdGhleSBhcmUg
cnVubmluZyBvbi4gVGhpcyBDUFUgY291bGQgYmUgdGhlDQotICAgICAqICAgIHNhbWUgYXMgb3Vy
cy4NCi0gICAgICovDQotDQotICAgIGZvcl9lYWNoX3ZjcHUgKCBkLCB2ICkNCi0gICAgew0KLSAg
ICAgICAgaWYgKCB2ICE9IGN1cnJlbnQgKQ0KLSAgICAgICAgICAgIHZjcHVfcGF1c2Uodik7DQot
ICAgIH0NCi0NCi0gICAgaWYgKCBkID09IGN1cnJlbnQtPmRvbWFpbiApDQotICAgICAgICB2Y3B1
X3NjaGVkdWxlX2xvY2tfaXJxKGN1cnJlbnQpOw0KLQ0KKyAgICAvKiBOQjogdGhlIHBsdWdnYWJs
ZSBzY2hlZHVsZXIgY29kZSBuZWVkcyB0byB0YWtlIGNhcmUNCisgICAgICogb2YgbG9ja2luZyBi
eSBpdHNlbGYuICovDQogICAgIGlmICggKHJldCA9IFNDSEVEX09QKERPTTJPUChkKSwgYWRqdXN0
LCBkLCBvcCkpID09IDAgKQ0KICAgICAgICAgVFJBQ0VfMUQoVFJDX1NDSEVEX0FESkRPTSwgZC0+
ZG9tYWluX2lkKTsNCiANCi0gICAgaWYgKCBkID09IGN1cnJlbnQtPmRvbWFpbiApDQotICAgICAg
ICB2Y3B1X3NjaGVkdWxlX3VubG9ja19pcnEoY3VycmVudCk7DQotDQotICAgIGZvcl9lYWNoX3Zj
cHUgKCBkLCB2ICkNCi0gICAgew0KLSAgICAgICAgaWYgKCB2ICE9IGN1cnJlbnQgKQ0KLSAgICAg
ICAgICAgIHZjcHVfdW5wYXVzZSh2KTsNCi0gICAgfQ0KLQ0KICAgICByZXR1cm4gcmV0Ow0KIH0N
CiANCg==


--=-2gDoRwjHAIAVny3ceOG+--

--=-s6aQxhtWfeniZORipy49
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEABECAAYFAk7rd5gACgkQk4XaBE3IOsRF4ACeJ7pXxiy0P4aZa825gcDm0HXx
v4cAoJH8+VULHbpCzzh5USbGN7Xwzupv
=FzAW
-----END PGP SIGNATURE-----

--=-s6aQxhtWfeniZORipy49--



--===============0469156300206918351==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============0469156300206918351==--



From xen-devel-bounces@lists.xensource.com Fri Dec 16 16:54:27 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 16:54:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rbb2s-0005yP-6p; Fri, 16 Dec 2011 16:54:06 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1Rbb2q-0005yK-C2
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 16:54:04 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-4.tower-182.messagelabs.com!1324054436!7581068!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=1.1 required=7.0 tests=BODY_RANDOM_LONG,DIET_1
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14913 invoked from network); 16 Dec 2011 16:53:56 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-4.tower-182.messagelabs.com with SMTP;
	16 Dec 2011 16:53:56 -0000
Received: from [62.94.142.93] (account d.faggioli@sssup.it HELO [192.168.0.40])
	by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 73976478; Fri, 16 Dec 2011 17:53:54 +0100
Message-ID: <1324054424.2599.13.camel@Solace>
From: Dario Faggioli <raistlin@linux.it>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Fri, 16 Dec 2011 17:53:44 +0100
X-Mailer: Evolution 3.0.3-3+b1 
Mime-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCHv2] Rework locking for sched_adjust.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0469156300206918351=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--===============0469156300206918351==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-s6aQxhtWfeniZORipy49"


--=-s6aQxhtWfeniZORipy49
Content-Type: multipart/mixed; boundary="=-2gDoRwjHAIAVny3ceOG+"


--=-2gDoRwjHAIAVny3ceOG+
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

[Re-posting as the patch was damaged in the previous message]

Hi everyone,

Here it is v2 of the lock reworking around and within sched-adjust.

With respect to the first posting [1]:
 - I _did_not_ move the per-pluggable scheduler lock toward schedule.c,
   as agreed with George during review;
 - I fixed the bug in sedf spotted by Juergen the way he suggested;
 - I've finally been able to test it under all the three schedulers,=20
   and it is doing its job, at least here;

Notice the series "collapsed" in one signle patch, as it was being hard
to find a breakdown of it that does not introduce regressions and/or
transient deadlock situations worse than the ones it's trying to cure...
I hope it's still readable and comfortable to review. :-)

Thanks to everyone who provided his feedback on the first version of
this.

Regards,
Dario

[1]
http://xen.1045712.n5.nabble.com/RFC-RFT-PATCH-0-of-3-rework-locking-in-sch=
ed-adjust-td5016899.html

--
 xen/common/sched_credit.c  |   10 ++++++--
 xen/common/sched_credit2.c |   21 ++++++++++---------
 xen/common/sched_sedf.c    |  156
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++=
++++++++++++++++++++++++++++++++++++++++++++-------------------------------=
----
 xen/common/schedule.c      |   34 +-------------------------------
 4 files changed, 140 insertions(+), 81 deletions(-)

--

# HG changeset patch
# Parent 1452fb248cd513832cfbbd1100b9b72a0dde7ea6
Rework locking for sched_adjust.

The main idea is to move (as much as possible) locking logic
from generic code to the various pluggable schedulers.

While at it, the following is also accomplished:
 - pausing all the non-current VCPUs of a domain while changing its
   scheduling parameters is not effective in avoiding races and it is
   prone to deadlock, so that is removed.
 - sedf needs a global lock for preventing races while adjusting
   domains' scheduling parameters (as it is for credit and credit2),
   so that is added.

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>

diff -r 1452fb248cd5 xen/common/sched_credit.c
--- a/xen/common/sched_credit.c	Fri Dec 16 15:45:40 2011 +0100
+++ b/xen/common/sched_credit.c	Fri Dec 16 17:49:46 2011 +0100
@@ -161,6 +161,7 @@ struct csched_dom {
  * System-wide private data
  */
 struct csched_private {
+    /* lock for the whole pluggable scheduler, nests inside cpupool_lock *=
/
     spinlock_t lock;
     struct list_head active_sdom;
     uint32_t ncpus;
@@ -800,6 +801,10 @@ csched_dom_cntl(
     struct csched_private *prv =3D CSCHED_PRIV(ops);
     unsigned long flags;
=20
+    /* Protect both get and put branches with the pluggable scheduler
+     * lock. Runq lock not needed anywhere in here. */
+    spin_lock_irqsave(&prv->lock, flags);
+
     if ( op->cmd =3D=3D XEN_DOMCTL_SCHEDOP_getinfo )
     {
         op->u.credit.weight =3D sdom->weight;
@@ -809,8 +814,6 @@ csched_dom_cntl(
     {
         ASSERT(op->cmd =3D=3D XEN_DOMCTL_SCHEDOP_putinfo);
=20
-        spin_lock_irqsave(&prv->lock, flags);
-
         if ( op->u.credit.weight !=3D 0 )
         {
             if ( !list_empty(&sdom->active_sdom_elem) )
@@ -824,9 +827,10 @@ csched_dom_cntl(
         if ( op->u.credit.cap !=3D (uint16_t)~0U )
             sdom->cap =3D op->u.credit.cap;
=20
-        spin_unlock_irqrestore(&prv->lock, flags);
     }
=20
+    spin_unlock_irqrestore(&prv->lock, flags);
+
     return 0;
 }
=20
diff -r 1452fb248cd5 xen/common/sched_credit2.c
--- a/xen/common/sched_credit2.c	Fri Dec 16 15:45:40 2011 +0100
+++ b/xen/common/sched_credit2.c	Fri Dec 16 17:49:46 2011 +0100
@@ -1384,6 +1384,10 @@ csched_dom_cntl(
     struct csched_private *prv =3D CSCHED_PRIV(ops);
     unsigned long flags;
=20
+    /* Must hold csched_priv lock to read and update sdom,
+     * runq lock to update csvcs. */
+    spin_lock_irqsave(&prv->lock, flags);
+
     if ( op->cmd =3D=3D XEN_DOMCTL_SCHEDOP_getinfo )
     {
         op->u.credit2.weight =3D sdom->weight;
@@ -1397,10 +1401,6 @@ csched_dom_cntl(
             struct list_head *iter;
             int old_weight;
=20
-            /* Must hold csched_priv lock to update sdom, runq lock to
-             * update csvcs. */
-            spin_lock_irqsave(&prv->lock, flags);
-
             old_weight =3D sdom->weight;
=20
             sdom->weight =3D op->u.credit2.weight;
@@ -1411,22 +1411,23 @@ csched_dom_cntl(
                 struct csched_vcpu *svc =3D list_entry(iter, struct csched=
_vcpu, sdom_elem);
=20
                 /* NB: Locking order is important here.  Because we grab t=
his lock here, we
-                 * must never lock csched_priv.lock if we're holding a run=
queue
-                 * lock. */
-                vcpu_schedule_lock_irq(svc->vcpu);
+                 * must never lock csched_priv.lock if we're holding a run=
queue lock.
+                 * Also, calling vcpu_schedule_lock() is enough, since IRQ=
s have already
+                 * been disabled. */
+                vcpu_schedule_lock(svc->vcpu);
=20
                 BUG_ON(svc->rqd !=3D RQD(ops, svc->vcpu->processor));
=20
                 svc->weight =3D sdom->weight;
                 update_max_weight(svc->rqd, svc->weight, old_weight);
=20
-                vcpu_schedule_unlock_irq(svc->vcpu);
+                vcpu_schedule_unlock(svc->vcpu);
             }
-
-            spin_unlock_irqrestore(&prv->lock, flags);
         }
     }
=20
+    spin_unlock_irqrestore(&prv->lock, flags);
+
     return 0;
 }
=20
diff -r 1452fb248cd5 xen/common/sched_sedf.c
--- a/xen/common/sched_sedf.c	Fri Dec 16 15:45:40 2011 +0100
+++ b/xen/common/sched_sedf.c	Fri Dec 16 17:49:46 2011 +0100
@@ -61,6 +61,11 @@ struct sedf_dom_info {
     struct domain  *domain;
 };
=20
+struct sedf_priv_info {
+    /* lock for the whole pluggable scheduler, nests inside cpupool_lock *=
/
+    spinlock_t lock;
+};
+
 struct sedf_vcpu_info {
     struct vcpu *vcpu;
     struct list_head list;
@@ -115,6 +120,8 @@ struct sedf_cpu_info {
     s_time_t         current_slice_expires;
 };
=20
+#define SEDF_PRIV(_ops) \
+    ((struct sedf_priv_info *)((_ops)->sched_data))
 #define EDOM_INFO(d)   ((struct sedf_vcpu_info *)((d)->sched_priv))
 #define CPU_INFO(cpu)  \
     ((struct sedf_cpu_info *)per_cpu(schedule_data, cpu).sched_priv)
@@ -772,6 +779,31 @@ static struct task_slice sedf_do_extra_s
 }
=20
=20
+static int sedf_init(struct scheduler *ops)
+{
+    struct sedf_priv_info *prv;
+
+    prv =3D xzalloc(struct sedf_priv_info);
+    if ( prv =3D=3D NULL )
+        return -ENOMEM;
+
+    ops->sched_data =3D prv;
+    spin_lock_init(&prv->lock);
+
+    return 0;
+}
+
+
+static void sedf_deinit(const struct scheduler *ops)
+{
+    struct sedf_priv_info *prv;
+
+    prv =3D SEDF_PRIV(ops);
+    if ( prv !=3D NULL )
+        xfree(prv);
+}
+
+
 /* Main scheduling function
    Reasons for calling this function are:
    -timeslice for the current period used up
@@ -1320,22 +1352,15 @@ static void sedf_dump_cpu_state(const st
=20
=20
 /* Adjusts periods and slices of the domains accordingly to their weights.=
 */
-static int sedf_adjust_weights(struct cpupool *c, struct xen_domctl_schedu=
ler_op *cmd)
+static int sedf_adjust_weights(struct cpupool *c, int nr_cpus, int *sumw, =
s_time_t *sumt)
 {
     struct vcpu *p;
     struct domain      *d;
-    unsigned int        cpu, nr_cpus =3D cpumask_last(&cpu_online_map) + 1=
;
-    int                *sumw =3D xzalloc_array(int, nr_cpus);
-    s_time_t           *sumt =3D xzalloc_array(s_time_t, nr_cpus);
+    unsigned int        cpu;
=20
-    if ( !sumw || !sumt )
-    {
-        xfree(sumt);
-        xfree(sumw);
-        return -ENOMEM;
-    }
-
-    /* Sum across all weights. */
+    /* Sum across all weights. Notice that no runq locking is needed
+     * here: the caller holds sedf_priv_info.lock and we're not changing
+     * anything that is accessed during scheduling. */
     rcu_read_lock(&domlist_read_lock);
     for_each_domain_in_cpupool( d, c )
     {
@@ -1365,7 +1390,9 @@ static int sedf_adjust_weights(struct cp
     }
     rcu_read_unlock(&domlist_read_lock);
=20
-    /* Adjust all slices (and periods) to the new weight. */
+    /* Adjust all slices (and periods) to the new weight. Unlike above, we
+     * need to take thr runq lock for the various VCPUs: we're modyfing
+     * slice and period which are referenced during scheduling. */
     rcu_read_lock(&domlist_read_lock);
     for_each_domain_in_cpupool( d, c )
     {
@@ -1375,20 +1402,20 @@ static int sedf_adjust_weights(struct cp
                 continue;
             if ( EDOM_INFO(p)->weight )
             {
+                /* Interrupts already off */
+                vcpu_schedule_lock(p);
                 EDOM_INFO(p)->period_orig =3D=20
                     EDOM_INFO(p)->period  =3D WEIGHT_PERIOD;
                 EDOM_INFO(p)->slice_orig  =3D
                     EDOM_INFO(p)->slice   =3D=20
                     (EDOM_INFO(p)->weight *
                      (WEIGHT_PERIOD - WEIGHT_SAFETY - sumt[cpu])) / sumw[c=
pu];
+                vcpu_schedule_unlock(p);
             }
         }
     }
     rcu_read_unlock(&domlist_read_lock);
=20
-    xfree(sumt);
-    xfree(sumw);
-
     return 0;
 }
=20
@@ -1396,19 +1423,45 @@ static int sedf_adjust_weights(struct cp
 /* set or fetch domain scheduling parameters */
 static int sedf_adjust(const struct scheduler *ops, struct domain *p, stru=
ct xen_domctl_scheduler_op *op)
 {
+    struct sedf_priv_info *prv =3D SEDF_PRIV(ops);
+    unsigned long flags;
+    unsigned int nr_cpus =3D cpumask_last(&cpu_online_map) + 1;
+    int *sumw =3D xzalloc_array(int, nr_cpus);
+    s_time_t *sumt =3D xzalloc_array(s_time_t, nr_cpus);
     struct vcpu *v;
-    int rc;
+    int rc =3D 0;
=20
     PRINT(2,"sedf_adjust was called, domain-id %i new period %"PRIu64" "
           "new slice %"PRIu64"\nlatency %"PRIu64" extra:%s\n",
           p->domain_id, op->u.sedf.period, op->u.sedf.slice,
           op->u.sedf.latency, (op->u.sedf.extratime)?"yes":"no");
=20
+    /* Serialize against the pluggable scheduler lock to protect from
+     * concurrent updates. We need to take the runq lock for the VCPUs
+     * as well, since we are touching extraweight, weight, slice and
+     * period. As in sched_credit2.c, runq locks nest inside the
+     * pluggable scheduler lock. */
+    spin_lock_irqsave(&prv->lock, flags);
+
     if ( op->cmd =3D=3D XEN_DOMCTL_SCHEDOP_putinfo )
     {
+        /* These are used in sedf_adjust_weights() but have to be allocate=
d in
+         * this function, as we need to avoid nesting xmem_pool_alloc's lo=
ck
+         * within our prv->lock. */
+        if ( !sumw || !sumt )
+        {
+            /* Check for errors here, the _getinfo branch doesn't care */
+            rc =3D -ENOMEM;
+            goto out;
+        }
+
         /* Check for sane parameters. */
         if ( !op->u.sedf.period && !op->u.sedf.weight )
-            return -EINVAL;
+        {
+            rc =3D -EINVAL;
+            goto out;
+        }
+
         if ( op->u.sedf.weight )
         {
             if ( (op->u.sedf.extratime & EXTRA_AWARE) &&
@@ -1417,59 +1470,78 @@ static int sedf_adjust(const struct sche
                 /* Weight-driven domains with extratime only. */
                 for_each_vcpu ( p, v )
                 {
+                    /* (Here and everywhere in the following) IRQs are alr=
eady off,
+                     * hence vcpu_spin_lock() is the one. */
+                    vcpu_schedule_lock(v);
                     EDOM_INFO(v)->extraweight =3D op->u.sedf.weight;
                     EDOM_INFO(v)->weight =3D 0;
                     EDOM_INFO(v)->slice =3D 0;
                     EDOM_INFO(v)->period =3D WEIGHT_PERIOD;
+                    vcpu_schedule_unlock(v);
                 }
             }
             else
             {
                 /* Weight-driven domains with real-time execution. */
-                for_each_vcpu ( p, v )
+                for_each_vcpu ( p, v ) {
+                    vcpu_schedule_lock(v);
                     EDOM_INFO(v)->weight =3D op->u.sedf.weight;
+                    vcpu_schedule_unlock(v);
+                }
             }
         }
         else
         {
+            /*
+             * Sanity checking: note that disabling extra weight requires
+             * that we set a non-zero slice.
+             */
+            if ( (op->u.sedf.period > PERIOD_MAX) ||
+                 (op->u.sedf.period < PERIOD_MIN) ||
+                 (op->u.sedf.slice  > op->u.sedf.period) ||
+                 (op->u.sedf.slice  < SLICE_MIN) )
+            {
+                rc =3D -EINVAL;
+                goto out;
+            }
+
             /* Time-driven domains. */
             for_each_vcpu ( p, v )
             {
-                /*
-                 * Sanity checking: note that disabling extra weight requi=
res
-                 * that we set a non-zero slice.
-                 */
-                if ( (op->u.sedf.period > PERIOD_MAX) ||
-                     (op->u.sedf.period < PERIOD_MIN) ||
-                     (op->u.sedf.slice  > op->u.sedf.period) ||
-                     (op->u.sedf.slice  < SLICE_MIN) )
-                    return -EINVAL;
+                vcpu_schedule_lock(v);
                 EDOM_INFO(v)->weight =3D 0;
                 EDOM_INFO(v)->extraweight =3D 0;
                 EDOM_INFO(v)->period_orig =3D=20
                     EDOM_INFO(v)->period  =3D op->u.sedf.period;
                 EDOM_INFO(v)->slice_orig  =3D=20
                     EDOM_INFO(v)->slice   =3D op->u.sedf.slice;
+                vcpu_schedule_unlock(v);
             }
         }
=20
-        rc =3D sedf_adjust_weights(p->cpupool, op);
+        rc =3D sedf_adjust_weights(p->cpupool, nr_cpus, sumw, sumt);
         if ( rc )
-            return rc;
+            goto out;
=20
         for_each_vcpu ( p, v )
         {
+            vcpu_schedule_lock(v);
             EDOM_INFO(v)->status  =3D=20
                 (EDOM_INFO(v)->status &
                  ~EXTRA_AWARE) | (op->u.sedf.extratime & EXTRA_AWARE);
             EDOM_INFO(v)->latency =3D op->u.sedf.latency;
             extraq_check(v);
+            vcpu_schedule_unlock(v);
         }
     }
     else if ( op->cmd =3D=3D XEN_DOMCTL_SCHEDOP_getinfo )
     {
         if ( p->vcpu[0] =3D=3D NULL )
-            return -EINVAL;
+        {
+            rc =3D -EINVAL;
+            goto out;
+        }
+
         op->u.sedf.period    =3D EDOM_INFO(p->vcpu[0])->period;
         op->u.sedf.slice     =3D EDOM_INFO(p->vcpu[0])->slice;
         op->u.sedf.extratime =3D EDOM_INFO(p->vcpu[0])->status & EXTRA_AWA=
RE;
@@ -1477,14 +1549,23 @@ static int sedf_adjust(const struct sche
         op->u.sedf.weight    =3D EDOM_INFO(p->vcpu[0])->weight;
     }
=20
-    PRINT(2,"sedf_adjust_finished\n");
-    return 0;
+out:
+    spin_unlock_irqrestore(&prv->lock, flags);
+
+    xfree(sumt);
+    xfree(sumw);
+
+    PRINT(2,"sedf_adjust_finished with return code %d\n", rc);
+    return rc;
 }
=20
+static struct sedf_priv_info _sedf_priv;
+
 const struct scheduler sched_sedf_def =3D {
-    .name     =3D "Simple EDF Scheduler",
-    .opt_name =3D "sedf",
-    .sched_id =3D XEN_SCHEDULER_SEDF,
+    .name           =3D "Simple EDF Scheduler",
+    .opt_name       =3D "sedf",
+    .sched_id       =3D XEN_SCHEDULER_SEDF,
+    .sched_data     =3D &_sedf_priv,
    =20
     .init_domain    =3D sedf_init_domain,
     .destroy_domain =3D sedf_destroy_domain,
@@ -1498,6 +1579,9 @@ const struct scheduler sched_sedf_def =3D=20
     .alloc_domdata  =3D sedf_alloc_domdata,
     .free_domdata   =3D sedf_free_domdata,
=20
+    .init           =3D sedf_init,
+    .deinit         =3D sedf_deinit,
+
     .do_schedule    =3D sedf_do_schedule,
     .pick_cpu       =3D sedf_pick_cpu,
     .dump_cpu_state =3D sedf_dump_cpu_state,
diff -r 1452fb248cd5 xen/common/schedule.c
--- a/xen/common/schedule.c	Fri Dec 16 15:45:40 2011 +0100
+++ b/xen/common/schedule.c	Fri Dec 16 17:49:46 2011 +0100
@@ -1005,7 +1005,6 @@ int sched_id(void)
 /* Adjust scheduling parameter for a given domain. */
 long sched_adjust(struct domain *d, struct xen_domctl_scheduler_op *op)
 {
-    struct vcpu *v;
     long ret;
    =20
     if ( (op->sched_id !=3D DOM2OP(d)->sched_id) ||
@@ -1013,40 +1012,11 @@ long sched_adjust(struct domain *d, stru
           (op->cmd !=3D XEN_DOMCTL_SCHEDOP_getinfo)) )
         return -EINVAL;
=20
-    /*
-     * Most VCPUs we can simply pause. If we are adjusting this VCPU then
-     * we acquire the local schedule_lock to guard against concurrent upda=
tes.
-     *
-     * We only acquire the local schedule lock after we have paused all ot=
her
-     * VCPUs in this domain. There are two reasons for this:
-     * 1- We don't want to hold up interrupts as pausing a VCPU can
-     *    trigger a tlb shootdown.
-     * 2- Pausing other VCPUs involves briefly locking the schedule
-     *    lock of the CPU they are running on. This CPU could be the
-     *    same as ours.
-     */
-
-    for_each_vcpu ( d, v )
-    {
-        if ( v !=3D current )
-            vcpu_pause(v);
-    }
-
-    if ( d =3D=3D current->domain )
-        vcpu_schedule_lock_irq(current);
-
+    /* NB: the pluggable scheduler code needs to take care
+     * of locking by itself. */
     if ( (ret =3D SCHED_OP(DOM2OP(d), adjust, d, op)) =3D=3D 0 )
         TRACE_1D(TRC_SCHED_ADJDOM, d->domain_id);
=20
-    if ( d =3D=3D current->domain )
-        vcpu_schedule_unlock_irq(current);
-
-    for_each_vcpu ( d, v )
-    {
-        if ( v !=3D current )
-            vcpu_unpause(v);
-    }
-
     return ret;
 }
=20
--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-------------------------------------------------------------------
Dario Faggioli, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
PhD Candidate, ReTiS Lab, Scuola Superiore Sant'Anna, Pisa (Italy)


--=-2gDoRwjHAIAVny3ceOG+
Content-Disposition: attachment; filename="rework-locking-for-sched-adjust.patch"
Content-Transfer-Encoding: base64
Content-Type: text/x-patch; name="rework-locking-for-sched-adjust.patch";
	charset="UTF-8"

IyBIRyBjaGFuZ2VzZXQgcGF0Y2gNCiMgUGFyZW50IDE0NTJmYjI0OGNkNTEzODMyY2ZiYmQxMTAw
YjliNzJhMGRkZTdlYTYNClJld29yayBsb2NraW5nIGZvciBzY2hlZF9hZGp1c3QuDQoNClRoZSBt
YWluIGlkZWEgaXMgdG8gbW92ZSAoYXMgbXVjaCBhcyBwb3NzaWJsZSkgbG9ja2luZyBsb2dpYw0K
ZnJvbSBnZW5lcmljIGNvZGUgdG8gdGhlIHZhcmlvdXMgcGx1Z2dhYmxlIHNjaGVkdWxlcnMuDQoN
CldoaWxlIGF0IGl0LCB0aGUgZm9sbG93aW5nIGlzIGFsc28gYWNjb21wbGlzaGVkOg0KIC0gcGF1
c2luZyBhbGwgdGhlIG5vbi1jdXJyZW50IFZDUFVzIG9mIGEgZG9tYWluIHdoaWxlIGNoYW5naW5n
IGl0cw0KICAgc2NoZWR1bGluZyBwYXJhbWV0ZXJzIGlzIG5vdCBlZmZlY3RpdmUgaW4gYXZvaWRp
bmcgcmFjZXMgYW5kIGl0IGlzDQogICBwcm9uZSB0byBkZWFkbG9jaywgc28gdGhhdCBpcyByZW1v
dmVkLg0KIC0gc2VkZiBuZWVkcyBhIGdsb2JhbCBsb2NrIGZvciBwcmV2ZW50aW5nIHJhY2VzIHdo
aWxlIGFkanVzdGluZw0KICAgZG9tYWlucycgc2NoZWR1bGluZyBwYXJhbWV0ZXJzIChhcyBpdCBp
cyBmb3IgY3JlZGl0IGFuZCBjcmVkaXQyKSwNCiAgIHNvIHRoYXQgaXMgYWRkZWQuDQoNClNpZ25l
ZC1vZmYtYnk6IERhcmlvIEZhZ2dpb2xpIDxkYXJpby5mYWdnaW9saUBjaXRyaXguY29tPg0KDQpk
aWZmIC1yIDE0NTJmYjI0OGNkNSB4ZW4vY29tbW9uL3NjaGVkX2NyZWRpdC5jDQotLS0gYS94ZW4v
Y29tbW9uL3NjaGVkX2NyZWRpdC5jCUZyaSBEZWMgMTYgMTU6NDU6NDAgMjAxMSArMDEwMA0KKysr
IGIveGVuL2NvbW1vbi9zY2hlZF9jcmVkaXQuYwlGcmkgRGVjIDE2IDE3OjQ5OjQ2IDIwMTEgKzAx
MDANCkBAIC0xNjEsNiArMTYxLDcgQEAgc3RydWN0IGNzY2hlZF9kb20gew0KICAqIFN5c3RlbS13
aWRlIHByaXZhdGUgZGF0YQ0KICAqLw0KIHN0cnVjdCBjc2NoZWRfcHJpdmF0ZSB7DQorICAgIC8q
IGxvY2sgZm9yIHRoZSB3aG9sZSBwbHVnZ2FibGUgc2NoZWR1bGVyLCBuZXN0cyBpbnNpZGUgY3B1
cG9vbF9sb2NrICovDQogICAgIHNwaW5sb2NrX3QgbG9jazsNCiAgICAgc3RydWN0IGxpc3RfaGVh
ZCBhY3RpdmVfc2RvbTsNCiAgICAgdWludDMyX3QgbmNwdXM7DQpAQCAtODAwLDYgKzgwMSwxMCBA
QCBjc2NoZWRfZG9tX2NudGwoDQogICAgIHN0cnVjdCBjc2NoZWRfcHJpdmF0ZSAqcHJ2ID0gQ1ND
SEVEX1BSSVYob3BzKTsNCiAgICAgdW5zaWduZWQgbG9uZyBmbGFnczsNCiANCisgICAgLyogUHJv
dGVjdCBib3RoIGdldCBhbmQgcHV0IGJyYW5jaGVzIHdpdGggdGhlIHBsdWdnYWJsZSBzY2hlZHVs
ZXINCisgICAgICogbG9jay4gUnVucSBsb2NrIG5vdCBuZWVkZWQgYW55d2hlcmUgaW4gaGVyZS4g
Ki8NCisgICAgc3Bpbl9sb2NrX2lycXNhdmUoJnBydi0+bG9jaywgZmxhZ3MpOw0KKw0KICAgICBp
ZiAoIG9wLT5jbWQgPT0gWEVOX0RPTUNUTF9TQ0hFRE9QX2dldGluZm8gKQ0KICAgICB7DQogICAg
ICAgICBvcC0+dS5jcmVkaXQud2VpZ2h0ID0gc2RvbS0+d2VpZ2h0Ow0KQEAgLTgwOSw4ICs4MTQs
NiBAQCBjc2NoZWRfZG9tX2NudGwoDQogICAgIHsNCiAgICAgICAgIEFTU0VSVChvcC0+Y21kID09
IFhFTl9ET01DVExfU0NIRURPUF9wdXRpbmZvKTsNCiANCi0gICAgICAgIHNwaW5fbG9ja19pcnFz
YXZlKCZwcnYtPmxvY2ssIGZsYWdzKTsNCi0NCiAgICAgICAgIGlmICggb3AtPnUuY3JlZGl0Lndl
aWdodCAhPSAwICkNCiAgICAgICAgIHsNCiAgICAgICAgICAgICBpZiAoICFsaXN0X2VtcHR5KCZz
ZG9tLT5hY3RpdmVfc2RvbV9lbGVtKSApDQpAQCAtODI0LDkgKzgyNywxMCBAQCBjc2NoZWRfZG9t
X2NudGwoDQogICAgICAgICBpZiAoIG9wLT51LmNyZWRpdC5jYXAgIT0gKHVpbnQxNl90KX4wVSAp
DQogICAgICAgICAgICAgc2RvbS0+Y2FwID0gb3AtPnUuY3JlZGl0LmNhcDsNCiANCi0gICAgICAg
IHNwaW5fdW5sb2NrX2lycXJlc3RvcmUoJnBydi0+bG9jaywgZmxhZ3MpOw0KICAgICB9DQogDQor
ICAgIHNwaW5fdW5sb2NrX2lycXJlc3RvcmUoJnBydi0+bG9jaywgZmxhZ3MpOw0KKw0KICAgICBy
ZXR1cm4gMDsNCiB9DQogDQpkaWZmIC1yIDE0NTJmYjI0OGNkNSB4ZW4vY29tbW9uL3NjaGVkX2Ny
ZWRpdDIuYw0KLS0tIGEveGVuL2NvbW1vbi9zY2hlZF9jcmVkaXQyLmMJRnJpIERlYyAxNiAxNTo0
NTo0MCAyMDExICswMTAwDQorKysgYi94ZW4vY29tbW9uL3NjaGVkX2NyZWRpdDIuYwlGcmkgRGVj
IDE2IDE3OjQ5OjQ2IDIwMTEgKzAxMDANCkBAIC0xMzg0LDYgKzEzODQsMTAgQEAgY3NjaGVkX2Rv
bV9jbnRsKA0KICAgICBzdHJ1Y3QgY3NjaGVkX3ByaXZhdGUgKnBydiA9IENTQ0hFRF9QUklWKG9w
cyk7DQogICAgIHVuc2lnbmVkIGxvbmcgZmxhZ3M7DQogDQorICAgIC8qIE11c3QgaG9sZCBjc2No
ZWRfcHJpdiBsb2NrIHRvIHJlYWQgYW5kIHVwZGF0ZSBzZG9tLA0KKyAgICAgKiBydW5xIGxvY2sg
dG8gdXBkYXRlIGNzdmNzLiAqLw0KKyAgICBzcGluX2xvY2tfaXJxc2F2ZSgmcHJ2LT5sb2NrLCBm
bGFncyk7DQorDQogICAgIGlmICggb3AtPmNtZCA9PSBYRU5fRE9NQ1RMX1NDSEVET1BfZ2V0aW5m
byApDQogICAgIHsNCiAgICAgICAgIG9wLT51LmNyZWRpdDIud2VpZ2h0ID0gc2RvbS0+d2VpZ2h0
Ow0KQEAgLTEzOTcsMTAgKzE0MDEsNiBAQCBjc2NoZWRfZG9tX2NudGwoDQogICAgICAgICAgICAg
c3RydWN0IGxpc3RfaGVhZCAqaXRlcjsNCiAgICAgICAgICAgICBpbnQgb2xkX3dlaWdodDsNCiAN
Ci0gICAgICAgICAgICAvKiBNdXN0IGhvbGQgY3NjaGVkX3ByaXYgbG9jayB0byB1cGRhdGUgc2Rv
bSwgcnVucSBsb2NrIHRvDQotICAgICAgICAgICAgICogdXBkYXRlIGNzdmNzLiAqLw0KLSAgICAg
ICAgICAgIHNwaW5fbG9ja19pcnFzYXZlKCZwcnYtPmxvY2ssIGZsYWdzKTsNCi0NCiAgICAgICAg
ICAgICBvbGRfd2VpZ2h0ID0gc2RvbS0+d2VpZ2h0Ow0KIA0KICAgICAgICAgICAgIHNkb20tPndl
aWdodCA9IG9wLT51LmNyZWRpdDIud2VpZ2h0Ow0KQEAgLTE0MTEsMjIgKzE0MTEsMjMgQEAgY3Nj
aGVkX2RvbV9jbnRsKA0KICAgICAgICAgICAgICAgICBzdHJ1Y3QgY3NjaGVkX3ZjcHUgKnN2YyA9
IGxpc3RfZW50cnkoaXRlciwgc3RydWN0IGNzY2hlZF92Y3B1LCBzZG9tX2VsZW0pOw0KIA0KICAg
ICAgICAgICAgICAgICAvKiBOQjogTG9ja2luZyBvcmRlciBpcyBpbXBvcnRhbnQgaGVyZS4gIEJl
Y2F1c2Ugd2UgZ3JhYiB0aGlzIGxvY2sgaGVyZSwgd2UNCi0gICAgICAgICAgICAgICAgICogbXVz
dCBuZXZlciBsb2NrIGNzY2hlZF9wcml2LmxvY2sgaWYgd2UncmUgaG9sZGluZyBhIHJ1bnF1ZXVl
DQotICAgICAgICAgICAgICAgICAqIGxvY2suICovDQotICAgICAgICAgICAgICAgIHZjcHVfc2No
ZWR1bGVfbG9ja19pcnEoc3ZjLT52Y3B1KTsNCisgICAgICAgICAgICAgICAgICogbXVzdCBuZXZl
ciBsb2NrIGNzY2hlZF9wcml2LmxvY2sgaWYgd2UncmUgaG9sZGluZyBhIHJ1bnF1ZXVlIGxvY2su
DQorICAgICAgICAgICAgICAgICAqIEFsc28sIGNhbGxpbmcgdmNwdV9zY2hlZHVsZV9sb2NrKCkg
aXMgZW5vdWdoLCBzaW5jZSBJUlFzIGhhdmUgYWxyZWFkeQ0KKyAgICAgICAgICAgICAgICAgKiBi
ZWVuIGRpc2FibGVkLiAqLw0KKyAgICAgICAgICAgICAgICB2Y3B1X3NjaGVkdWxlX2xvY2soc3Zj
LT52Y3B1KTsNCiANCiAgICAgICAgICAgICAgICAgQlVHX09OKHN2Yy0+cnFkICE9IFJRRChvcHMs
IHN2Yy0+dmNwdS0+cHJvY2Vzc29yKSk7DQogDQogICAgICAgICAgICAgICAgIHN2Yy0+d2VpZ2h0
ID0gc2RvbS0+d2VpZ2h0Ow0KICAgICAgICAgICAgICAgICB1cGRhdGVfbWF4X3dlaWdodChzdmMt
PnJxZCwgc3ZjLT53ZWlnaHQsIG9sZF93ZWlnaHQpOw0KIA0KLSAgICAgICAgICAgICAgICB2Y3B1
X3NjaGVkdWxlX3VubG9ja19pcnEoc3ZjLT52Y3B1KTsNCisgICAgICAgICAgICAgICAgdmNwdV9z
Y2hlZHVsZV91bmxvY2soc3ZjLT52Y3B1KTsNCiAgICAgICAgICAgICB9DQotDQotICAgICAgICAg
ICAgc3Bpbl91bmxvY2tfaXJxcmVzdG9yZSgmcHJ2LT5sb2NrLCBmbGFncyk7DQogICAgICAgICB9
DQogICAgIH0NCiANCisgICAgc3Bpbl91bmxvY2tfaXJxcmVzdG9yZSgmcHJ2LT5sb2NrLCBmbGFn
cyk7DQorDQogICAgIHJldHVybiAwOw0KIH0NCiANCmRpZmYgLXIgMTQ1MmZiMjQ4Y2Q1IHhlbi9j
b21tb24vc2NoZWRfc2VkZi5jDQotLS0gYS94ZW4vY29tbW9uL3NjaGVkX3NlZGYuYwlGcmkgRGVj
IDE2IDE1OjQ1OjQwIDIwMTEgKzAxMDANCisrKyBiL3hlbi9jb21tb24vc2NoZWRfc2VkZi5jCUZy
aSBEZWMgMTYgMTc6NDk6NDYgMjAxMSArMDEwMA0KQEAgLTYxLDYgKzYxLDExIEBAIHN0cnVjdCBz
ZWRmX2RvbV9pbmZvIHsNCiAgICAgc3RydWN0IGRvbWFpbiAgKmRvbWFpbjsNCiB9Ow0KIA0KK3N0
cnVjdCBzZWRmX3ByaXZfaW5mbyB7DQorICAgIC8qIGxvY2sgZm9yIHRoZSB3aG9sZSBwbHVnZ2Fi
bGUgc2NoZWR1bGVyLCBuZXN0cyBpbnNpZGUgY3B1cG9vbF9sb2NrICovDQorICAgIHNwaW5sb2Nr
X3QgbG9jazsNCit9Ow0KKw0KIHN0cnVjdCBzZWRmX3ZjcHVfaW5mbyB7DQogICAgIHN0cnVjdCB2
Y3B1ICp2Y3B1Ow0KICAgICBzdHJ1Y3QgbGlzdF9oZWFkIGxpc3Q7DQpAQCAtMTE1LDYgKzEyMCw4
IEBAIHN0cnVjdCBzZWRmX2NwdV9pbmZvIHsNCiAgICAgc190aW1lX3QgICAgICAgICBjdXJyZW50
X3NsaWNlX2V4cGlyZXM7DQogfTsNCiANCisjZGVmaW5lIFNFREZfUFJJVihfb3BzKSBcDQorICAg
ICgoc3RydWN0IHNlZGZfcHJpdl9pbmZvICopKChfb3BzKS0+c2NoZWRfZGF0YSkpDQogI2RlZmlu
ZSBFRE9NX0lORk8oZCkgICAoKHN0cnVjdCBzZWRmX3ZjcHVfaW5mbyAqKSgoZCktPnNjaGVkX3By
aXYpKQ0KICNkZWZpbmUgQ1BVX0lORk8oY3B1KSAgXA0KICAgICAoKHN0cnVjdCBzZWRmX2NwdV9p
bmZvICopcGVyX2NwdShzY2hlZHVsZV9kYXRhLCBjcHUpLnNjaGVkX3ByaXYpDQpAQCAtNzcyLDYg
Kzc3OSwzMSBAQCBzdGF0aWMgc3RydWN0IHRhc2tfc2xpY2Ugc2VkZl9kb19leHRyYV9zDQogfQ0K
IA0KIA0KK3N0YXRpYyBpbnQgc2VkZl9pbml0KHN0cnVjdCBzY2hlZHVsZXIgKm9wcykNCit7DQor
ICAgIHN0cnVjdCBzZWRmX3ByaXZfaW5mbyAqcHJ2Ow0KKw0KKyAgICBwcnYgPSB4emFsbG9jKHN0
cnVjdCBzZWRmX3ByaXZfaW5mbyk7DQorICAgIGlmICggcHJ2ID09IE5VTEwgKQ0KKyAgICAgICAg
cmV0dXJuIC1FTk9NRU07DQorDQorICAgIG9wcy0+c2NoZWRfZGF0YSA9IHBydjsNCisgICAgc3Bp
bl9sb2NrX2luaXQoJnBydi0+bG9jayk7DQorDQorICAgIHJldHVybiAwOw0KK30NCisNCisNCitz
dGF0aWMgdm9pZCBzZWRmX2RlaW5pdChjb25zdCBzdHJ1Y3Qgc2NoZWR1bGVyICpvcHMpDQorew0K
KyAgICBzdHJ1Y3Qgc2VkZl9wcml2X2luZm8gKnBydjsNCisNCisgICAgcHJ2ID0gU0VERl9QUklW
KG9wcyk7DQorICAgIGlmICggcHJ2ICE9IE5VTEwgKQ0KKyAgICAgICAgeGZyZWUocHJ2KTsNCit9
DQorDQorDQogLyogTWFpbiBzY2hlZHVsaW5nIGZ1bmN0aW9uDQogICAgUmVhc29ucyBmb3IgY2Fs
bGluZyB0aGlzIGZ1bmN0aW9uIGFyZToNCiAgICAtdGltZXNsaWNlIGZvciB0aGUgY3VycmVudCBw
ZXJpb2QgdXNlZCB1cA0KQEAgLTEzMjAsMjIgKzEzNTIsMTUgQEAgc3RhdGljIHZvaWQgc2VkZl9k
dW1wX2NwdV9zdGF0ZShjb25zdCBzdA0KIA0KIA0KIC8qIEFkanVzdHMgcGVyaW9kcyBhbmQgc2xp
Y2VzIG9mIHRoZSBkb21haW5zIGFjY29yZGluZ2x5IHRvIHRoZWlyIHdlaWdodHMuICovDQotc3Rh
dGljIGludCBzZWRmX2FkanVzdF93ZWlnaHRzKHN0cnVjdCBjcHVwb29sICpjLCBzdHJ1Y3QgeGVu
X2RvbWN0bF9zY2hlZHVsZXJfb3AgKmNtZCkNCitzdGF0aWMgaW50IHNlZGZfYWRqdXN0X3dlaWdo
dHMoc3RydWN0IGNwdXBvb2wgKmMsIGludCBucl9jcHVzLCBpbnQgKnN1bXcsIHNfdGltZV90ICpz
dW10KQ0KIHsNCiAgICAgc3RydWN0IHZjcHUgKnA7DQogICAgIHN0cnVjdCBkb21haW4gICAgICAq
ZDsNCi0gICAgdW5zaWduZWQgaW50ICAgICAgICBjcHUsIG5yX2NwdXMgPSBjcHVtYXNrX2xhc3Qo
JmNwdV9vbmxpbmVfbWFwKSArIDE7DQotICAgIGludCAgICAgICAgICAgICAgICAqc3VtdyA9IHh6
YWxsb2NfYXJyYXkoaW50LCBucl9jcHVzKTsNCi0gICAgc190aW1lX3QgICAgICAgICAgICpzdW10
ID0geHphbGxvY19hcnJheShzX3RpbWVfdCwgbnJfY3B1cyk7DQorICAgIHVuc2lnbmVkIGludCAg
ICAgICAgY3B1Ow0KIA0KLSAgICBpZiAoICFzdW13IHx8ICFzdW10ICkNCi0gICAgew0KLSAgICAg
ICAgeGZyZWUoc3VtdCk7DQotICAgICAgICB4ZnJlZShzdW13KTsNCi0gICAgICAgIHJldHVybiAt
RU5PTUVNOw0KLSAgICB9DQotDQotICAgIC8qIFN1bSBhY3Jvc3MgYWxsIHdlaWdodHMuICovDQor
ICAgIC8qIFN1bSBhY3Jvc3MgYWxsIHdlaWdodHMuIE5vdGljZSB0aGF0IG5vIHJ1bnEgbG9ja2lu
ZyBpcyBuZWVkZWQNCisgICAgICogaGVyZTogdGhlIGNhbGxlciBob2xkcyBzZWRmX3ByaXZfaW5m
by5sb2NrIGFuZCB3ZSdyZSBub3QgY2hhbmdpbmcNCisgICAgICogYW55dGhpbmcgdGhhdCBpcyBh
Y2Nlc3NlZCBkdXJpbmcgc2NoZWR1bGluZy4gKi8NCiAgICAgcmN1X3JlYWRfbG9jaygmZG9tbGlz
dF9yZWFkX2xvY2spOw0KICAgICBmb3JfZWFjaF9kb21haW5faW5fY3B1cG9vbCggZCwgYyApDQog
ICAgIHsNCkBAIC0xMzY1LDcgKzEzOTAsOSBAQCBzdGF0aWMgaW50IHNlZGZfYWRqdXN0X3dlaWdo
dHMoc3RydWN0IGNwDQogICAgIH0NCiAgICAgcmN1X3JlYWRfdW5sb2NrKCZkb21saXN0X3JlYWRf
bG9jayk7DQogDQotICAgIC8qIEFkanVzdCBhbGwgc2xpY2VzIChhbmQgcGVyaW9kcykgdG8gdGhl
IG5ldyB3ZWlnaHQuICovDQorICAgIC8qIEFkanVzdCBhbGwgc2xpY2VzIChhbmQgcGVyaW9kcykg
dG8gdGhlIG5ldyB3ZWlnaHQuIFVubGlrZSBhYm92ZSwgd2UNCisgICAgICogbmVlZCB0byB0YWtl
IHRociBydW5xIGxvY2sgZm9yIHRoZSB2YXJpb3VzIFZDUFVzOiB3ZSdyZSBtb2R5ZmluZw0KKyAg
ICAgKiBzbGljZSBhbmQgcGVyaW9kIHdoaWNoIGFyZSByZWZlcmVuY2VkIGR1cmluZyBzY2hlZHVs
aW5nLiAqLw0KICAgICByY3VfcmVhZF9sb2NrKCZkb21saXN0X3JlYWRfbG9jayk7DQogICAgIGZv
cl9lYWNoX2RvbWFpbl9pbl9jcHVwb29sKCBkLCBjICkNCiAgICAgew0KQEAgLTEzNzUsMjAgKzE0
MDIsMjAgQEAgc3RhdGljIGludCBzZWRmX2FkanVzdF93ZWlnaHRzKHN0cnVjdCBjcA0KICAgICAg
ICAgICAgICAgICBjb250aW51ZTsNCiAgICAgICAgICAgICBpZiAoIEVET01fSU5GTyhwKS0+d2Vp
Z2h0ICkNCiAgICAgICAgICAgICB7DQorICAgICAgICAgICAgICAgIC8qIEludGVycnVwdHMgYWxy
ZWFkeSBvZmYgKi8NCisgICAgICAgICAgICAgICAgdmNwdV9zY2hlZHVsZV9sb2NrKHApOw0KICAg
ICAgICAgICAgICAgICBFRE9NX0lORk8ocCktPnBlcmlvZF9vcmlnID0gDQogICAgICAgICAgICAg
ICAgICAgICBFRE9NX0lORk8ocCktPnBlcmlvZCAgPSBXRUlHSFRfUEVSSU9EOw0KICAgICAgICAg
ICAgICAgICBFRE9NX0lORk8ocCktPnNsaWNlX29yaWcgID0NCiAgICAgICAgICAgICAgICAgICAg
IEVET01fSU5GTyhwKS0+c2xpY2UgICA9IA0KICAgICAgICAgICAgICAgICAgICAgKEVET01fSU5G
TyhwKS0+d2VpZ2h0ICoNCiAgICAgICAgICAgICAgICAgICAgICAoV0VJR0hUX1BFUklPRCAtIFdF
SUdIVF9TQUZFVFkgLSBzdW10W2NwdV0pKSAvIHN1bXdbY3B1XTsNCisgICAgICAgICAgICAgICAg
dmNwdV9zY2hlZHVsZV91bmxvY2socCk7DQogICAgICAgICAgICAgfQ0KICAgICAgICAgfQ0KICAg
ICB9DQogICAgIHJjdV9yZWFkX3VubG9jaygmZG9tbGlzdF9yZWFkX2xvY2spOw0KIA0KLSAgICB4
ZnJlZShzdW10KTsNCi0gICAgeGZyZWUoc3Vtdyk7DQotDQogICAgIHJldHVybiAwOw0KIH0NCiAN
CkBAIC0xMzk2LDE5ICsxNDIzLDQ1IEBAIHN0YXRpYyBpbnQgc2VkZl9hZGp1c3Rfd2VpZ2h0cyhz
dHJ1Y3QgY3ANCiAvKiBzZXQgb3IgZmV0Y2ggZG9tYWluIHNjaGVkdWxpbmcgcGFyYW1ldGVycyAq
Lw0KIHN0YXRpYyBpbnQgc2VkZl9hZGp1c3QoY29uc3Qgc3RydWN0IHNjaGVkdWxlciAqb3BzLCBz
dHJ1Y3QgZG9tYWluICpwLCBzdHJ1Y3QgeGVuX2RvbWN0bF9zY2hlZHVsZXJfb3AgKm9wKQ0KIHsN
CisgICAgc3RydWN0IHNlZGZfcHJpdl9pbmZvICpwcnYgPSBTRURGX1BSSVYob3BzKTsNCisgICAg
dW5zaWduZWQgbG9uZyBmbGFnczsNCisgICAgdW5zaWduZWQgaW50IG5yX2NwdXMgPSBjcHVtYXNr
X2xhc3QoJmNwdV9vbmxpbmVfbWFwKSArIDE7DQorICAgIGludCAqc3VtdyA9IHh6YWxsb2NfYXJy
YXkoaW50LCBucl9jcHVzKTsNCisgICAgc190aW1lX3QgKnN1bXQgPSB4emFsbG9jX2FycmF5KHNf
dGltZV90LCBucl9jcHVzKTsNCiAgICAgc3RydWN0IHZjcHUgKnY7DQotICAgIGludCByYzsNCisg
ICAgaW50IHJjID0gMDsNCiANCiAgICAgUFJJTlQoMiwic2VkZl9hZGp1c3Qgd2FzIGNhbGxlZCwg
ZG9tYWluLWlkICVpIG5ldyBwZXJpb2QgJSJQUkl1NjQiICINCiAgICAgICAgICAgIm5ldyBzbGlj
ZSAlIlBSSXU2NCJcbmxhdGVuY3kgJSJQUkl1NjQiIGV4dHJhOiVzXG4iLA0KICAgICAgICAgICBw
LT5kb21haW5faWQsIG9wLT51LnNlZGYucGVyaW9kLCBvcC0+dS5zZWRmLnNsaWNlLA0KICAgICAg
ICAgICBvcC0+dS5zZWRmLmxhdGVuY3ksIChvcC0+dS5zZWRmLmV4dHJhdGltZSk/InllcyI6Im5v
Iik7DQogDQorICAgIC8qIFNlcmlhbGl6ZSBhZ2FpbnN0IHRoZSBwbHVnZ2FibGUgc2NoZWR1bGVy
IGxvY2sgdG8gcHJvdGVjdCBmcm9tDQorICAgICAqIGNvbmN1cnJlbnQgdXBkYXRlcy4gV2UgbmVl
ZCB0byB0YWtlIHRoZSBydW5xIGxvY2sgZm9yIHRoZSBWQ1BVcw0KKyAgICAgKiBhcyB3ZWxsLCBz
aW5jZSB3ZSBhcmUgdG91Y2hpbmcgZXh0cmF3ZWlnaHQsIHdlaWdodCwgc2xpY2UgYW5kDQorICAg
ICAqIHBlcmlvZC4gQXMgaW4gc2NoZWRfY3JlZGl0Mi5jLCBydW5xIGxvY2tzIG5lc3QgaW5zaWRl
IHRoZQ0KKyAgICAgKiBwbHVnZ2FibGUgc2NoZWR1bGVyIGxvY2suICovDQorICAgIHNwaW5fbG9j
a19pcnFzYXZlKCZwcnYtPmxvY2ssIGZsYWdzKTsNCisNCiAgICAgaWYgKCBvcC0+Y21kID09IFhF
Tl9ET01DVExfU0NIRURPUF9wdXRpbmZvICkNCiAgICAgew0KKyAgICAgICAgLyogVGhlc2UgYXJl
IHVzZWQgaW4gc2VkZl9hZGp1c3Rfd2VpZ2h0cygpIGJ1dCBoYXZlIHRvIGJlIGFsbG9jYXRlZCBp
bg0KKyAgICAgICAgICogdGhpcyBmdW5jdGlvbiwgYXMgd2UgbmVlZCB0byBhdm9pZCBuZXN0aW5n
IHhtZW1fcG9vbF9hbGxvYydzIGxvY2sNCisgICAgICAgICAqIHdpdGhpbiBvdXIgcHJ2LT5sb2Nr
LiAqLw0KKyAgICAgICAgaWYgKCAhc3VtdyB8fCAhc3VtdCApDQorICAgICAgICB7DQorICAgICAg
ICAgICAgLyogQ2hlY2sgZm9yIGVycm9ycyBoZXJlLCB0aGUgX2dldGluZm8gYnJhbmNoIGRvZXNu
J3QgY2FyZSAqLw0KKyAgICAgICAgICAgIHJjID0gLUVOT01FTTsNCisgICAgICAgICAgICBnb3Rv
IG91dDsNCisgICAgICAgIH0NCisNCiAgICAgICAgIC8qIENoZWNrIGZvciBzYW5lIHBhcmFtZXRl
cnMuICovDQogICAgICAgICBpZiAoICFvcC0+dS5zZWRmLnBlcmlvZCAmJiAhb3AtPnUuc2VkZi53
ZWlnaHQgKQ0KLSAgICAgICAgICAgIHJldHVybiAtRUlOVkFMOw0KKyAgICAgICAgew0KKyAgICAg
ICAgICAgIHJjID0gLUVJTlZBTDsNCisgICAgICAgICAgICBnb3RvIG91dDsNCisgICAgICAgIH0N
CisNCiAgICAgICAgIGlmICggb3AtPnUuc2VkZi53ZWlnaHQgKQ0KICAgICAgICAgew0KICAgICAg
ICAgICAgIGlmICggKG9wLT51LnNlZGYuZXh0cmF0aW1lICYgRVhUUkFfQVdBUkUpICYmDQpAQCAt
MTQxNyw1OSArMTQ3MCw3OCBAQCBzdGF0aWMgaW50IHNlZGZfYWRqdXN0KGNvbnN0IHN0cnVjdCBz
Y2hlDQogICAgICAgICAgICAgICAgIC8qIFdlaWdodC1kcml2ZW4gZG9tYWlucyB3aXRoIGV4dHJh
dGltZSBvbmx5LiAqLw0KICAgICAgICAgICAgICAgICBmb3JfZWFjaF92Y3B1ICggcCwgdiApDQog
ICAgICAgICAgICAgICAgIHsNCisgICAgICAgICAgICAgICAgICAgIC8qIChIZXJlIGFuZCBldmVy
eXdoZXJlIGluIHRoZSBmb2xsb3dpbmcpIElSUXMgYXJlIGFscmVhZHkgb2ZmLA0KKyAgICAgICAg
ICAgICAgICAgICAgICogaGVuY2UgdmNwdV9zcGluX2xvY2soKSBpcyB0aGUgb25lLiAqLw0KKyAg
ICAgICAgICAgICAgICAgICAgdmNwdV9zY2hlZHVsZV9sb2NrKHYpOw0KICAgICAgICAgICAgICAg
ICAgICAgRURPTV9JTkZPKHYpLT5leHRyYXdlaWdodCA9IG9wLT51LnNlZGYud2VpZ2h0Ow0KICAg
ICAgICAgICAgICAgICAgICAgRURPTV9JTkZPKHYpLT53ZWlnaHQgPSAwOw0KICAgICAgICAgICAg
ICAgICAgICAgRURPTV9JTkZPKHYpLT5zbGljZSA9IDA7DQogICAgICAgICAgICAgICAgICAgICBF
RE9NX0lORk8odiktPnBlcmlvZCA9IFdFSUdIVF9QRVJJT0Q7DQorICAgICAgICAgICAgICAgICAg
ICB2Y3B1X3NjaGVkdWxlX3VubG9jayh2KTsNCiAgICAgICAgICAgICAgICAgfQ0KICAgICAgICAg
ICAgIH0NCiAgICAgICAgICAgICBlbHNlDQogICAgICAgICAgICAgew0KICAgICAgICAgICAgICAg
ICAvKiBXZWlnaHQtZHJpdmVuIGRvbWFpbnMgd2l0aCByZWFsLXRpbWUgZXhlY3V0aW9uLiAqLw0K
LSAgICAgICAgICAgICAgICBmb3JfZWFjaF92Y3B1ICggcCwgdiApDQorICAgICAgICAgICAgICAg
IGZvcl9lYWNoX3ZjcHUgKCBwLCB2ICkgew0KKyAgICAgICAgICAgICAgICAgICAgdmNwdV9zY2hl
ZHVsZV9sb2NrKHYpOw0KICAgICAgICAgICAgICAgICAgICAgRURPTV9JTkZPKHYpLT53ZWlnaHQg
PSBvcC0+dS5zZWRmLndlaWdodDsNCisgICAgICAgICAgICAgICAgICAgIHZjcHVfc2NoZWR1bGVf
dW5sb2NrKHYpOw0KKyAgICAgICAgICAgICAgICB9DQogICAgICAgICAgICAgfQ0KICAgICAgICAg
fQ0KICAgICAgICAgZWxzZQ0KICAgICAgICAgew0KKyAgICAgICAgICAgIC8qDQorICAgICAgICAg
ICAgICogU2FuaXR5IGNoZWNraW5nOiBub3RlIHRoYXQgZGlzYWJsaW5nIGV4dHJhIHdlaWdodCBy
ZXF1aXJlcw0KKyAgICAgICAgICAgICAqIHRoYXQgd2Ugc2V0IGEgbm9uLXplcm8gc2xpY2UuDQor
ICAgICAgICAgICAgICovDQorICAgICAgICAgICAgaWYgKCAob3AtPnUuc2VkZi5wZXJpb2QgPiBQ
RVJJT0RfTUFYKSB8fA0KKyAgICAgICAgICAgICAgICAgKG9wLT51LnNlZGYucGVyaW9kIDwgUEVS
SU9EX01JTikgfHwNCisgICAgICAgICAgICAgICAgIChvcC0+dS5zZWRmLnNsaWNlICA+IG9wLT51
LnNlZGYucGVyaW9kKSB8fA0KKyAgICAgICAgICAgICAgICAgKG9wLT51LnNlZGYuc2xpY2UgIDwg
U0xJQ0VfTUlOKSApDQorICAgICAgICAgICAgew0KKyAgICAgICAgICAgICAgICByYyA9IC1FSU5W
QUw7DQorICAgICAgICAgICAgICAgIGdvdG8gb3V0Ow0KKyAgICAgICAgICAgIH0NCisNCiAgICAg
ICAgICAgICAvKiBUaW1lLWRyaXZlbiBkb21haW5zLiAqLw0KICAgICAgICAgICAgIGZvcl9lYWNo
X3ZjcHUgKCBwLCB2ICkNCiAgICAgICAgICAgICB7DQotICAgICAgICAgICAgICAgIC8qDQotICAg
ICAgICAgICAgICAgICAqIFNhbml0eSBjaGVja2luZzogbm90ZSB0aGF0IGRpc2FibGluZyBleHRy
YSB3ZWlnaHQgcmVxdWlyZXMNCi0gICAgICAgICAgICAgICAgICogdGhhdCB3ZSBzZXQgYSBub24t
emVybyBzbGljZS4NCi0gICAgICAgICAgICAgICAgICovDQotICAgICAgICAgICAgICAgIGlmICgg
KG9wLT51LnNlZGYucGVyaW9kID4gUEVSSU9EX01BWCkgfHwNCi0gICAgICAgICAgICAgICAgICAg
ICAob3AtPnUuc2VkZi5wZXJpb2QgPCBQRVJJT0RfTUlOKSB8fA0KLSAgICAgICAgICAgICAgICAg
ICAgIChvcC0+dS5zZWRmLnNsaWNlICA+IG9wLT51LnNlZGYucGVyaW9kKSB8fA0KLSAgICAgICAg
ICAgICAgICAgICAgIChvcC0+dS5zZWRmLnNsaWNlICA8IFNMSUNFX01JTikgKQ0KLSAgICAgICAg
ICAgICAgICAgICAgcmV0dXJuIC1FSU5WQUw7DQorICAgICAgICAgICAgICAgIHZjcHVfc2NoZWR1
bGVfbG9jayh2KTsNCiAgICAgICAgICAgICAgICAgRURPTV9JTkZPKHYpLT53ZWlnaHQgPSAwOw0K
ICAgICAgICAgICAgICAgICBFRE9NX0lORk8odiktPmV4dHJhd2VpZ2h0ID0gMDsNCiAgICAgICAg
ICAgICAgICAgRURPTV9JTkZPKHYpLT5wZXJpb2Rfb3JpZyA9IA0KICAgICAgICAgICAgICAgICAg
ICAgRURPTV9JTkZPKHYpLT5wZXJpb2QgID0gb3AtPnUuc2VkZi5wZXJpb2Q7DQogICAgICAgICAg
ICAgICAgIEVET01fSU5GTyh2KS0+c2xpY2Vfb3JpZyAgPSANCiAgICAgICAgICAgICAgICAgICAg
IEVET01fSU5GTyh2KS0+c2xpY2UgICA9IG9wLT51LnNlZGYuc2xpY2U7DQorICAgICAgICAgICAg
ICAgIHZjcHVfc2NoZWR1bGVfdW5sb2NrKHYpOw0KICAgICAgICAgICAgIH0NCiAgICAgICAgIH0N
CiANCi0gICAgICAgIHJjID0gc2VkZl9hZGp1c3Rfd2VpZ2h0cyhwLT5jcHVwb29sLCBvcCk7DQor
ICAgICAgICByYyA9IHNlZGZfYWRqdXN0X3dlaWdodHMocC0+Y3B1cG9vbCwgbnJfY3B1cywgc3Vt
dywgc3VtdCk7DQogICAgICAgICBpZiAoIHJjICkNCi0gICAgICAgICAgICByZXR1cm4gcmM7DQor
ICAgICAgICAgICAgZ290byBvdXQ7DQogDQogICAgICAgICBmb3JfZWFjaF92Y3B1ICggcCwgdiAp
DQogICAgICAgICB7DQorICAgICAgICAgICAgdmNwdV9zY2hlZHVsZV9sb2NrKHYpOw0KICAgICAg
ICAgICAgIEVET01fSU5GTyh2KS0+c3RhdHVzICA9IA0KICAgICAgICAgICAgICAgICAoRURPTV9J
TkZPKHYpLT5zdGF0dXMgJg0KICAgICAgICAgICAgICAgICAgfkVYVFJBX0FXQVJFKSB8IChvcC0+
dS5zZWRmLmV4dHJhdGltZSAmIEVYVFJBX0FXQVJFKTsNCiAgICAgICAgICAgICBFRE9NX0lORk8o
diktPmxhdGVuY3kgPSBvcC0+dS5zZWRmLmxhdGVuY3k7DQogICAgICAgICAgICAgZXh0cmFxX2No
ZWNrKHYpOw0KKyAgICAgICAgICAgIHZjcHVfc2NoZWR1bGVfdW5sb2NrKHYpOw0KICAgICAgICAg
fQ0KICAgICB9DQogICAgIGVsc2UgaWYgKCBvcC0+Y21kID09IFhFTl9ET01DVExfU0NIRURPUF9n
ZXRpbmZvICkNCiAgICAgew0KICAgICAgICAgaWYgKCBwLT52Y3B1WzBdID09IE5VTEwgKQ0KLSAg
ICAgICAgICAgIHJldHVybiAtRUlOVkFMOw0KKyAgICAgICAgew0KKyAgICAgICAgICAgIHJjID0g
LUVJTlZBTDsNCisgICAgICAgICAgICBnb3RvIG91dDsNCisgICAgICAgIH0NCisNCiAgICAgICAg
IG9wLT51LnNlZGYucGVyaW9kICAgID0gRURPTV9JTkZPKHAtPnZjcHVbMF0pLT5wZXJpb2Q7DQog
ICAgICAgICBvcC0+dS5zZWRmLnNsaWNlICAgICA9IEVET01fSU5GTyhwLT52Y3B1WzBdKS0+c2xp
Y2U7DQogICAgICAgICBvcC0+dS5zZWRmLmV4dHJhdGltZSA9IEVET01fSU5GTyhwLT52Y3B1WzBd
KS0+c3RhdHVzICYgRVhUUkFfQVdBUkU7DQpAQCAtMTQ3NywxNCArMTU0OSwyMyBAQCBzdGF0aWMg
aW50IHNlZGZfYWRqdXN0KGNvbnN0IHN0cnVjdCBzY2hlDQogICAgICAgICBvcC0+dS5zZWRmLndl
aWdodCAgICA9IEVET01fSU5GTyhwLT52Y3B1WzBdKS0+d2VpZ2h0Ow0KICAgICB9DQogDQotICAg
IFBSSU5UKDIsInNlZGZfYWRqdXN0X2ZpbmlzaGVkXG4iKTsNCi0gICAgcmV0dXJuIDA7DQorb3V0
Og0KKyAgICBzcGluX3VubG9ja19pcnFyZXN0b3JlKCZwcnYtPmxvY2ssIGZsYWdzKTsNCisNCisg
ICAgeGZyZWUoc3VtdCk7DQorICAgIHhmcmVlKHN1bXcpOw0KKw0KKyAgICBQUklOVCgyLCJzZWRm
X2FkanVzdF9maW5pc2hlZCB3aXRoIHJldHVybiBjb2RlICVkXG4iLCByYyk7DQorICAgIHJldHVy
biByYzsNCiB9DQogDQorc3RhdGljIHN0cnVjdCBzZWRmX3ByaXZfaW5mbyBfc2VkZl9wcml2Ow0K
Kw0KIGNvbnN0IHN0cnVjdCBzY2hlZHVsZXIgc2NoZWRfc2VkZl9kZWYgPSB7DQotICAgIC5uYW1l
ICAgICA9ICJTaW1wbGUgRURGIFNjaGVkdWxlciIsDQotICAgIC5vcHRfbmFtZSA9ICJzZWRmIiwN
Ci0gICAgLnNjaGVkX2lkID0gWEVOX1NDSEVEVUxFUl9TRURGLA0KKyAgICAubmFtZSAgICAgICAg
ICAgPSAiU2ltcGxlIEVERiBTY2hlZHVsZXIiLA0KKyAgICAub3B0X25hbWUgICAgICAgPSAic2Vk
ZiIsDQorICAgIC5zY2hlZF9pZCAgICAgICA9IFhFTl9TQ0hFRFVMRVJfU0VERiwNCisgICAgLnNj
aGVkX2RhdGEgICAgID0gJl9zZWRmX3ByaXYsDQogICAgIA0KICAgICAuaW5pdF9kb21haW4gICAg
PSBzZWRmX2luaXRfZG9tYWluLA0KICAgICAuZGVzdHJveV9kb21haW4gPSBzZWRmX2Rlc3Ryb3lf
ZG9tYWluLA0KQEAgLTE0OTgsNiArMTU3OSw5IEBAIGNvbnN0IHN0cnVjdCBzY2hlZHVsZXIgc2No
ZWRfc2VkZl9kZWYgPSANCiAgICAgLmFsbG9jX2RvbWRhdGEgID0gc2VkZl9hbGxvY19kb21kYXRh
LA0KICAgICAuZnJlZV9kb21kYXRhICAgPSBzZWRmX2ZyZWVfZG9tZGF0YSwNCiANCisgICAgLmlu
aXQgICAgICAgICAgID0gc2VkZl9pbml0LA0KKyAgICAuZGVpbml0ICAgICAgICAgPSBzZWRmX2Rl
aW5pdCwNCisNCiAgICAgLmRvX3NjaGVkdWxlICAgID0gc2VkZl9kb19zY2hlZHVsZSwNCiAgICAg
LnBpY2tfY3B1ICAgICAgID0gc2VkZl9waWNrX2NwdSwNCiAgICAgLmR1bXBfY3B1X3N0YXRlID0g
c2VkZl9kdW1wX2NwdV9zdGF0ZSwNCmRpZmYgLXIgMTQ1MmZiMjQ4Y2Q1IHhlbi9jb21tb24vc2No
ZWR1bGUuYw0KLS0tIGEveGVuL2NvbW1vbi9zY2hlZHVsZS5jCUZyaSBEZWMgMTYgMTU6NDU6NDAg
MjAxMSArMDEwMA0KKysrIGIveGVuL2NvbW1vbi9zY2hlZHVsZS5jCUZyaSBEZWMgMTYgMTc6NDk6
NDYgMjAxMSArMDEwMA0KQEAgLTEwMDUsNyArMTAwNSw2IEBAIGludCBzY2hlZF9pZCh2b2lkKQ0K
IC8qIEFkanVzdCBzY2hlZHVsaW5nIHBhcmFtZXRlciBmb3IgYSBnaXZlbiBkb21haW4uICovDQog
bG9uZyBzY2hlZF9hZGp1c3Qoc3RydWN0IGRvbWFpbiAqZCwgc3RydWN0IHhlbl9kb21jdGxfc2No
ZWR1bGVyX29wICpvcCkNCiB7DQotICAgIHN0cnVjdCB2Y3B1ICp2Ow0KICAgICBsb25nIHJldDsN
CiAgICAgDQogICAgIGlmICggKG9wLT5zY2hlZF9pZCAhPSBET00yT1AoZCktPnNjaGVkX2lkKSB8
fA0KQEAgLTEwMTMsNDAgKzEwMTIsMTEgQEAgbG9uZyBzY2hlZF9hZGp1c3Qoc3RydWN0IGRvbWFp
biAqZCwgc3RydQ0KICAgICAgICAgICAob3AtPmNtZCAhPSBYRU5fRE9NQ1RMX1NDSEVET1BfZ2V0
aW5mbykpICkNCiAgICAgICAgIHJldHVybiAtRUlOVkFMOw0KIA0KLSAgICAvKg0KLSAgICAgKiBN
b3N0IFZDUFVzIHdlIGNhbiBzaW1wbHkgcGF1c2UuIElmIHdlIGFyZSBhZGp1c3RpbmcgdGhpcyBW
Q1BVIHRoZW4NCi0gICAgICogd2UgYWNxdWlyZSB0aGUgbG9jYWwgc2NoZWR1bGVfbG9jayB0byBn
dWFyZCBhZ2FpbnN0IGNvbmN1cnJlbnQgdXBkYXRlcy4NCi0gICAgICoNCi0gICAgICogV2Ugb25s
eSBhY3F1aXJlIHRoZSBsb2NhbCBzY2hlZHVsZSBsb2NrIGFmdGVyIHdlIGhhdmUgcGF1c2VkIGFs
bCBvdGhlcg0KLSAgICAgKiBWQ1BVcyBpbiB0aGlzIGRvbWFpbi4gVGhlcmUgYXJlIHR3byByZWFz
b25zIGZvciB0aGlzOg0KLSAgICAgKiAxLSBXZSBkb24ndCB3YW50IHRvIGhvbGQgdXAgaW50ZXJy
dXB0cyBhcyBwYXVzaW5nIGEgVkNQVSBjYW4NCi0gICAgICogICAgdHJpZ2dlciBhIHRsYiBzaG9v
dGRvd24uDQotICAgICAqIDItIFBhdXNpbmcgb3RoZXIgVkNQVXMgaW52b2x2ZXMgYnJpZWZseSBs
b2NraW5nIHRoZSBzY2hlZHVsZQ0KLSAgICAgKiAgICBsb2NrIG9mIHRoZSBDUFUgdGhleSBhcmUg
cnVubmluZyBvbi4gVGhpcyBDUFUgY291bGQgYmUgdGhlDQotICAgICAqICAgIHNhbWUgYXMgb3Vy
cy4NCi0gICAgICovDQotDQotICAgIGZvcl9lYWNoX3ZjcHUgKCBkLCB2ICkNCi0gICAgew0KLSAg
ICAgICAgaWYgKCB2ICE9IGN1cnJlbnQgKQ0KLSAgICAgICAgICAgIHZjcHVfcGF1c2Uodik7DQot
ICAgIH0NCi0NCi0gICAgaWYgKCBkID09IGN1cnJlbnQtPmRvbWFpbiApDQotICAgICAgICB2Y3B1
X3NjaGVkdWxlX2xvY2tfaXJxKGN1cnJlbnQpOw0KLQ0KKyAgICAvKiBOQjogdGhlIHBsdWdnYWJs
ZSBzY2hlZHVsZXIgY29kZSBuZWVkcyB0byB0YWtlIGNhcmUNCisgICAgICogb2YgbG9ja2luZyBi
eSBpdHNlbGYuICovDQogICAgIGlmICggKHJldCA9IFNDSEVEX09QKERPTTJPUChkKSwgYWRqdXN0
LCBkLCBvcCkpID09IDAgKQ0KICAgICAgICAgVFJBQ0VfMUQoVFJDX1NDSEVEX0FESkRPTSwgZC0+
ZG9tYWluX2lkKTsNCiANCi0gICAgaWYgKCBkID09IGN1cnJlbnQtPmRvbWFpbiApDQotICAgICAg
ICB2Y3B1X3NjaGVkdWxlX3VubG9ja19pcnEoY3VycmVudCk7DQotDQotICAgIGZvcl9lYWNoX3Zj
cHUgKCBkLCB2ICkNCi0gICAgew0KLSAgICAgICAgaWYgKCB2ICE9IGN1cnJlbnQgKQ0KLSAgICAg
ICAgICAgIHZjcHVfdW5wYXVzZSh2KTsNCi0gICAgfQ0KLQ0KICAgICByZXR1cm4gcmV0Ow0KIH0N
CiANCg==


--=-2gDoRwjHAIAVny3ceOG+--

--=-s6aQxhtWfeniZORipy49
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEABECAAYFAk7rd5gACgkQk4XaBE3IOsRF4ACeJ7pXxiy0P4aZa825gcDm0HXx
v4cAoJH8+VULHbpCzzh5USbGN7Xwzupv
=FzAW
-----END PGP SIGNATURE-----

--=-s6aQxhtWfeniZORipy49--



--===============0469156300206918351==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============0469156300206918351==--



From xen-devel-bounces@lists.xensource.com Fri Dec 16 16:56:12 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 16: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.xensource.com>)
	id 1Rbb4V-00064g-25; Fri, 16 Dec 2011 16:55:47 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Boris.Ostrovsky@amd.com>) id 1Rbb4T-000648-51
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 16:55:45 +0000
X-Env-Sender: Boris.Ostrovsky@amd.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1324054537!7520774!1
X-Originating-IP: [216.32.181.185]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25944 invoked from network); 16 Dec 2011 16:55:38 -0000
Received: from ch1ehsobe005.messaging.microsoft.com (HELO
	ch1outboundpool.messaging.microsoft.com) (216.32.181.185)
	by server-7.tower-182.messagelabs.com with AES128-SHA encrypted SMTP;
	16 Dec 2011 16:55:38 -0000
Received: from mail91-ch1-R.bigfish.com (10.43.68.242) by
	CH1EHSOBE014.bigfish.com (10.43.70.64) with Microsoft SMTP Server id
	14.1.225.23; Fri, 16 Dec 2011 16:55:35 +0000
Received: from mail91-ch1 (localhost [127.0.0.1])	by mail91-ch1-R.bigfish.com
	(Postfix) with ESMTP id 4E149280085;
	Fri, 16 Dec 2011 16:55:45 +0000 (UTC)
X-SpamScore: -10
X-BigFish: VPS-10(zzbb2dI1432N98dKzz1202hzz8275bhz2dh668h839h)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
Received: from mail91-ch1 (localhost.localdomain [127.0.0.1]) by mail91-ch1
	(MessageSwitch) id 1324054543184059_28655;
	Fri, 16 Dec 2011 16:55:43 +0000 (UTC)
Received: from CH1EHSMHS029.bigfish.com (snatpool1.int.messaging.microsoft.com
	[10.43.68.247])	by mail91-ch1.bigfish.com (Postfix) with ESMTP id
	1E05C4A0042;	Fri, 16 Dec 2011 16:55:43 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	CH1EHSMHS029.bigfish.com (10.43.70.29) with Microsoft SMTP Server id
	14.1.225.23; Fri, 16 Dec 2011 16:55:32 +0000
X-WSS-ID: 0LWB30I-01-A0N-02
X-M-MSG: 
Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com
	[163.181.249.73])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 22E0A1028065;	Fri, 16 Dec 2011 10:55:29 -0600 (CST)
Received: from sausexhtp01.amd.com (163.181.3.165) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Fri, 16 Dec 2011 10:55:50 -0600
Received: from [10.234.222.67] (10.234.222.67) by sausexhtp01.amd.com
	(163.181.3.165) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 16 Dec 2011 10:55:31 -0600
Message-ID: <4EEB7802.4060803@amd.com>
Date: Fri, 16 Dec 2011 11:55:30 -0500
From: Boris Ostrovsky <boris.ostrovsky@amd.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.23) Gecko/20110920 SUSE/3.1.15 Thunderbird/3.1.15
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <4EEB70910200007800068852@nat28.tlf.novell.com>
In-Reply-To: <4EEB70910200007800068852@nat28.tlf.novell.com>
X-OriginatorOrg: amd.com
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	wei.huang2@amd.com
Subject: Re: [Xen-devel] [PATCH] x86/AMD: fold redundant parameters of
	cpu_has_amd_erratum()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 12/16/11 10:23, Jan Beulich wrote:
> The boolean 'osvw' indicator and 'osvw_id' can be folded - the function
> can as well distinguish the non-OSVW case by checking for a negative
> 'osvw_id'. That way the whole variable argument list processing is only
> needed on the legacy code path.
>
> Signed-off-by: Jan Beulich<jbeulich@suse.com>

Acked-by: Boris Ostrovsky <boris.ostrovsky@amd.com>

>
> --- a/xen/arch/x86/cpu/amd.c
> +++ b/xen/arch/x86/cpu/amd.c
> @@ -186,7 +186,7 @@ static void __devinit set_cpuidmask(cons
>    * Check for the presence of an AMD erratum. Arguments are defined in amd.h
>    * for each known erratum. Return 1 if erratum is found.
>    */
> -int cpu_has_amd_erratum(const struct cpuinfo_x86 *cpu, int osvw, ...)
> +int cpu_has_amd_erratum(const struct cpuinfo_x86 *cpu, int osvw_id, ...)
>   {
>   	va_list ap;
>   	u32 range;
> @@ -195,27 +195,24 @@ int cpu_has_amd_erratum(const struct cpu
>   	if (cpu->x86_vendor != X86_VENDOR_AMD)
>   		return 0;
>
> -	va_start(ap, osvw);
> +	if (osvw_id>= 0&&  cpu_has(cpu, X86_FEATURE_OSVW)) {
> +		u64 osvw_len;
>
> -	if (osvw) {
> -		u16 osvw_id = va_arg(ap, int);
> +		rdmsrl(MSR_AMD_OSVW_ID_LENGTH, osvw_len);
>
> -		if (cpu_has(cpu, X86_FEATURE_OSVW)) {
> -			u64 osvw_len;
> -			rdmsrl(MSR_AMD_OSVW_ID_LENGTH, osvw_len);
> -
> -			if (osvw_id<  osvw_len) {
> -				u64 osvw_bits;
> -				rdmsrl(MSR_AMD_OSVW_STATUS + (osvw_id>>  6),
> -				       osvw_bits);
> +		if (osvw_id<  osvw_len) {
> +			u64 osvw_bits;
>
> -				va_end(ap);
> -				return (osvw_bits>>  (osvw_id&  0x3f))&  0x01;
> -			}
> +			rdmsrl(MSR_AMD_OSVW_STATUS + (osvw_id>>  6),
> +			       osvw_bits);
> +
> +			return (osvw_bits>>  (osvw_id&  0x3f))&  1;
>   		}
>   	}
>
>   	/* OSVW unavailable or ID unknown, match family-model-stepping range */
> +	va_start(ap, osvw_id);
> +
>   	ms = (cpu->x86_model<<  4) | cpu->x86_mask;
>   	while ((range = va_arg(ap, int))) {
>   		if ((cpu->x86 == AMD_MODEL_RANGE_FAMILY(range))&&
> --- a/xen/include/asm-x86/amd.h
> +++ b/xen/include/asm-x86/amd.h
> @@ -119,8 +119,8 @@
>    *
>    */
>
> -#define AMD_LEGACY_ERRATUM(...)         0 /* legacy */, __VA_ARGS__, 0
> -#define AMD_OSVW_ERRATUM(osvw_id, ...)  1 /* osvw */, osvw_id, __VA_ARGS__, 0
> +#define AMD_LEGACY_ERRATUM(...)         -1 /* legacy */, __VA_ARGS__, 0
> +#define AMD_OSVW_ERRATUM(osvw_id, ...)  osvw_id, __VA_ARGS__, 0
>   #define AMD_MODEL_RANGE(f, m_start, s_start, m_end, s_end)              \
>       ((f<<  24) | (m_start<<  16) | (s_start<<  12) | (m_end<<  4) | (s_end))
>   #define AMD_MODEL_RANGE_FAMILY(range)   (((range)>>  24)&  0xff)
>
>
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 16:56:12 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 16: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.xensource.com>)
	id 1Rbb4V-00064g-25; Fri, 16 Dec 2011 16:55:47 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Boris.Ostrovsky@amd.com>) id 1Rbb4T-000648-51
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 16:55:45 +0000
X-Env-Sender: Boris.Ostrovsky@amd.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1324054537!7520774!1
X-Originating-IP: [216.32.181.185]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25944 invoked from network); 16 Dec 2011 16:55:38 -0000
Received: from ch1ehsobe005.messaging.microsoft.com (HELO
	ch1outboundpool.messaging.microsoft.com) (216.32.181.185)
	by server-7.tower-182.messagelabs.com with AES128-SHA encrypted SMTP;
	16 Dec 2011 16:55:38 -0000
Received: from mail91-ch1-R.bigfish.com (10.43.68.242) by
	CH1EHSOBE014.bigfish.com (10.43.70.64) with Microsoft SMTP Server id
	14.1.225.23; Fri, 16 Dec 2011 16:55:35 +0000
Received: from mail91-ch1 (localhost [127.0.0.1])	by mail91-ch1-R.bigfish.com
	(Postfix) with ESMTP id 4E149280085;
	Fri, 16 Dec 2011 16:55:45 +0000 (UTC)
X-SpamScore: -10
X-BigFish: VPS-10(zzbb2dI1432N98dKzz1202hzz8275bhz2dh668h839h)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
Received: from mail91-ch1 (localhost.localdomain [127.0.0.1]) by mail91-ch1
	(MessageSwitch) id 1324054543184059_28655;
	Fri, 16 Dec 2011 16:55:43 +0000 (UTC)
Received: from CH1EHSMHS029.bigfish.com (snatpool1.int.messaging.microsoft.com
	[10.43.68.247])	by mail91-ch1.bigfish.com (Postfix) with ESMTP id
	1E05C4A0042;	Fri, 16 Dec 2011 16:55:43 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	CH1EHSMHS029.bigfish.com (10.43.70.29) with Microsoft SMTP Server id
	14.1.225.23; Fri, 16 Dec 2011 16:55:32 +0000
X-WSS-ID: 0LWB30I-01-A0N-02
X-M-MSG: 
Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com
	[163.181.249.73])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 22E0A1028065;	Fri, 16 Dec 2011 10:55:29 -0600 (CST)
Received: from sausexhtp01.amd.com (163.181.3.165) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Fri, 16 Dec 2011 10:55:50 -0600
Received: from [10.234.222.67] (10.234.222.67) by sausexhtp01.amd.com
	(163.181.3.165) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 16 Dec 2011 10:55:31 -0600
Message-ID: <4EEB7802.4060803@amd.com>
Date: Fri, 16 Dec 2011 11:55:30 -0500
From: Boris Ostrovsky <boris.ostrovsky@amd.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.23) Gecko/20110920 SUSE/3.1.15 Thunderbird/3.1.15
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <4EEB70910200007800068852@nat28.tlf.novell.com>
In-Reply-To: <4EEB70910200007800068852@nat28.tlf.novell.com>
X-OriginatorOrg: amd.com
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	wei.huang2@amd.com
Subject: Re: [Xen-devel] [PATCH] x86/AMD: fold redundant parameters of
	cpu_has_amd_erratum()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 12/16/11 10:23, Jan Beulich wrote:
> The boolean 'osvw' indicator and 'osvw_id' can be folded - the function
> can as well distinguish the non-OSVW case by checking for a negative
> 'osvw_id'. That way the whole variable argument list processing is only
> needed on the legacy code path.
>
> Signed-off-by: Jan Beulich<jbeulich@suse.com>

Acked-by: Boris Ostrovsky <boris.ostrovsky@amd.com>

>
> --- a/xen/arch/x86/cpu/amd.c
> +++ b/xen/arch/x86/cpu/amd.c
> @@ -186,7 +186,7 @@ static void __devinit set_cpuidmask(cons
>    * Check for the presence of an AMD erratum. Arguments are defined in amd.h
>    * for each known erratum. Return 1 if erratum is found.
>    */
> -int cpu_has_amd_erratum(const struct cpuinfo_x86 *cpu, int osvw, ...)
> +int cpu_has_amd_erratum(const struct cpuinfo_x86 *cpu, int osvw_id, ...)
>   {
>   	va_list ap;
>   	u32 range;
> @@ -195,27 +195,24 @@ int cpu_has_amd_erratum(const struct cpu
>   	if (cpu->x86_vendor != X86_VENDOR_AMD)
>   		return 0;
>
> -	va_start(ap, osvw);
> +	if (osvw_id>= 0&&  cpu_has(cpu, X86_FEATURE_OSVW)) {
> +		u64 osvw_len;
>
> -	if (osvw) {
> -		u16 osvw_id = va_arg(ap, int);
> +		rdmsrl(MSR_AMD_OSVW_ID_LENGTH, osvw_len);
>
> -		if (cpu_has(cpu, X86_FEATURE_OSVW)) {
> -			u64 osvw_len;
> -			rdmsrl(MSR_AMD_OSVW_ID_LENGTH, osvw_len);
> -
> -			if (osvw_id<  osvw_len) {
> -				u64 osvw_bits;
> -				rdmsrl(MSR_AMD_OSVW_STATUS + (osvw_id>>  6),
> -				       osvw_bits);
> +		if (osvw_id<  osvw_len) {
> +			u64 osvw_bits;
>
> -				va_end(ap);
> -				return (osvw_bits>>  (osvw_id&  0x3f))&  0x01;
> -			}
> +			rdmsrl(MSR_AMD_OSVW_STATUS + (osvw_id>>  6),
> +			       osvw_bits);
> +
> +			return (osvw_bits>>  (osvw_id&  0x3f))&  1;
>   		}
>   	}
>
>   	/* OSVW unavailable or ID unknown, match family-model-stepping range */
> +	va_start(ap, osvw_id);
> +
>   	ms = (cpu->x86_model<<  4) | cpu->x86_mask;
>   	while ((range = va_arg(ap, int))) {
>   		if ((cpu->x86 == AMD_MODEL_RANGE_FAMILY(range))&&
> --- a/xen/include/asm-x86/amd.h
> +++ b/xen/include/asm-x86/amd.h
> @@ -119,8 +119,8 @@
>    *
>    */
>
> -#define AMD_LEGACY_ERRATUM(...)         0 /* legacy */, __VA_ARGS__, 0
> -#define AMD_OSVW_ERRATUM(osvw_id, ...)  1 /* osvw */, osvw_id, __VA_ARGS__, 0
> +#define AMD_LEGACY_ERRATUM(...)         -1 /* legacy */, __VA_ARGS__, 0
> +#define AMD_OSVW_ERRATUM(osvw_id, ...)  osvw_id, __VA_ARGS__, 0
>   #define AMD_MODEL_RANGE(f, m_start, s_start, m_end, s_end)              \
>       ((f<<  24) | (m_start<<  16) | (s_start<<  12) | (m_end<<  4) | (s_end))
>   #define AMD_MODEL_RANGE_FAMILY(range)   (((range)>>  24)&  0xff)
>
>
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 16:56:55 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 16:56:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rbb5L-00068U-H3; Fri, 16 Dec 2011 16:56:39 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Neal.Taylor@ca.com>) id 1Rbb5K-000686-CG
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 16:56:38 +0000
X-Env-Sender: Neal.Taylor@ca.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1324054589!266868!1
X-Originating-IP: [74.125.149.203]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12688 invoked from network); 16 Dec 2011 16:56:31 -0000
Received: from na3sys009aog110.obsmtp.com (HELO na3sys009aog110.obsmtp.com)
	(74.125.149.203)
	by server-16.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 16 Dec 2011 16:56:31 -0000
Received: from USILMS191.ca.com ([141.202.246.45]) (using TLSv1) by
	na3sys009aob110.postini.com ([74.125.148.12]) with SMTP
	ID DSNKTut4POv1LwQT38IsgDe2kDfuG/pId8dT@postini.com;
	Fri, 16 Dec 2011 08:56:30 PST
Received: from USILMS171.ca.com (141.202.6.21) by USILMS191.ca.com
	(141.202.246.45) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Fri, 16 Dec 2011 11:56:27 -0500
Received: from USILMS110A.ca.com ([169.254.1.109]) by USILMS171.ca.com
	([141.202.6.21]) with mapi id 14.01.0289.001;
	Fri, 16 Dec 2011 11:56:27 -0500
From: "Taylor, Neal E" <Neal.Taylor@ca.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Thread-Topic: patch "[PATCH] xen/swiotlb: Use page alignment for early
	buffer allocation." failed to apply to 3.1-stable tree
Thread-Index: AQHMu39EqhS6jdpwjEafu8REQ03Ud5Xdo1+ggAFNCgD//78B4A==
Date: Fri, 16 Dec 2011 16:56:27 +0000
Message-ID: <3E243B26F475504B9BB0BCC9728B0DA629E1B140@USILMS110A.ca.com>
References: <13239908451694@kroah.org>
	<3E243B26F475504B9BB0BCC9728B0DA629E1AC69@USILMS110A.ca.com>
	<20111216154554.GG31755@phenom.dumpdata.com>
In-Reply-To: <20111216154554.GG31755@phenom.dumpdata.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [138.42.46.105]
MIME-Version: 1.0
Cc: "gregkh@suse.de" <gregkh@suse.de>, "Kalev, Leonid" <Leonid.Kalev@ca.com>,
	xen-devel <xen-devel@lists.xensource.com>,
	"stable@vger.kernel.org" <stable@vger.kernel.org>
Subject: Re: [Xen-devel] patch "[PATCH] xen/swiotlb: Use page alignment for
 early buffer allocation." failed to apply to 3.1-stable tree
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Clean 3.1.5 + this patch and clean 3.0.4 + this patch tested on the server that exhibited the symptom. They boot then PCI devices recognize they can and then do use DMA.

Neal

-----Original Message-----
From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@oracle.com] 
Sent: Friday, December 16, 2011 7:46 AM
To: Taylor, Neal E
Cc: stable@vger.kernel.org; gregkh@suse.de; Kalev, Leonid; xen-devel
Subject: Re: patch "[PATCH] xen/swiotlb: Use page alignment for early buffer allocation." failed to apply to 3.1-stable tree

On Fri, Dec 16, 2011 at 12:58:55AM +0000, Taylor, Neal E wrote:
> Konrad,
> 
> This patch applies and compiles on 3.1.5 and 3.0.4. I'll test tomorrow.

OK. I've tested it on 3.1.5 and 3.0.6 as well. If I recall you mentioned
that you had tested the 3.0.4 + this patch yesterday (thought you
probably had tons of debugging patches too). Is that you are testing a clean
version of 3.0.4 with this patch? Or are you testing both trees on your box?

Thanks!
> 
> Neal
> 
> diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
> index 8e964b9..5c8e445 100644
> --- a/drivers/xen/swiotlb-xen.c
> +++ b/drivers/xen/swiotlb-xen.c
> @@ -166,7 +166,8 @@ retry:
>         /*
>          * Get IO TLB memory from any location.
>          */
> -       xen_io_tlb_start = alloc_bootmem(bytes);
> +       xen_io_tlb_start = alloc_bootmem_pages(PAGE_ALIGN(bytes));
> +
>         if (!xen_io_tlb_start)
>                 panic("Cannot allocate SWIOTLB buffer");
> 
> -----Original Message-----
> From: gregkh@suse.de [mailto:gregkh@suse.de] 
> Sent: Thursday, December 15, 2011 3:14 PM
> To: konrad.wilk@oracle.com; Kalev, Leonid; Taylor, Neal E
> Cc: stable@vger.kernel.org
> Subject: patch "[PATCH] xen/swiotlb: Use page alignment for early buffer allocation." failed to apply to 3.1-stable tree
> 
> 
> The patch below does not apply to the 3.1-stable tree.
> If someone wants it applied there, or to any other stable or longterm
> tree, then please email the backport, including the original git commit
> id to <stable@vger.kernel.org>.
> 
> thanks,
> 
> greg k-h
> 
> ------------------ original commit in Linus's tree ------------------
> 
> >From 63a741757d15320a25ebf5778f8651cce2ed0611 Mon Sep 17 00:00:00 2001
> From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> Date: Thu, 15 Dec 2011 11:28:46 -0500
> Subject: [PATCH] xen/swiotlb: Use page alignment for early buffer allocation.
> 
> This fixes an odd bug found on a Dell PowerEdge 1850/0RC130
> (BIOS A05 01/09/2006) where all of the modules doing pci_set_dma_mask
> would fail with:
> 
> ata_piix 0000:00:1f.1: enabling device (0005 -> 0007)
> ata_piix 0000:00:1f.1: can't derive routing for PCI INT A
> ata_piix 0000:00:1f.1: BMDMA: failed to set dma mask, falling back to PIO
> 
> The issue was the Xen-SWIOTLB was allocated such as that the end of
> buffer was stradling a page (and also above 4GB). The fix was
> spotted by Kalev Leonid  which was to piggyback on git commit
> e79f86b2ef9c0a8c47225217c1018b7d3d90101c "swiotlb: Use page alignment
> for early buffer allocation" which:
> 
> 	We could call free_bootmem_late() if swiotlb is not used, and
> 	it will shrink to page alignment.
> 
> 	So alloc them with page alignment at first, to avoid lose two pages
> 
> And doing that fixes the outstanding issue.
> 
> CC: stable@kernel.org
> Suggested-by: "Kalev, Leonid" <Leonid.Kalev@ca.com>
> Reported-and-Tested-by: "Taylor, Neal E" <Neal.Taylor@ca.com>
> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> 
> diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
> index 8e964b9..284798a 100644
> --- a/drivers/xen/swiotlb-xen.c
> +++ b/drivers/xen/swiotlb-xen.c
> @@ -166,7 +166,7 @@ retry:
>  	/*
>  	 * Get IO TLB memory from any location.
>  	 */
> -	xen_io_tlb_start = alloc_bootmem(bytes);
> +	xen_io_tlb_start = alloc_bootmem_pages(PAGE_ALIGN(bytes));
>  	if (!xen_io_tlb_start) {
>  		m = "Cannot allocate Xen-SWIOTLB buffer!\n";
>  		goto error;
> @@ -179,7 +179,7 @@ retry:
>  			       bytes,
>  			       xen_io_tlb_nslabs);
>  	if (rc) {
> -		free_bootmem(__pa(xen_io_tlb_start), bytes);
> +		free_bootmem(__pa(xen_io_tlb_start), PAGE_ALIGN(bytes));
>  		m = "Failed to get contiguous memory for DMA from Xen!\n"\
>  		    "You either: don't have the permissions, do not have"\
>  		    " enough free memory under 4GB, or the hypervisor memory"\

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 16:56:55 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 16:56:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rbb5L-00068U-H3; Fri, 16 Dec 2011 16:56:39 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Neal.Taylor@ca.com>) id 1Rbb5K-000686-CG
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 16:56:38 +0000
X-Env-Sender: Neal.Taylor@ca.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1324054589!266868!1
X-Originating-IP: [74.125.149.203]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12688 invoked from network); 16 Dec 2011 16:56:31 -0000
Received: from na3sys009aog110.obsmtp.com (HELO na3sys009aog110.obsmtp.com)
	(74.125.149.203)
	by server-16.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 16 Dec 2011 16:56:31 -0000
Received: from USILMS191.ca.com ([141.202.246.45]) (using TLSv1) by
	na3sys009aob110.postini.com ([74.125.148.12]) with SMTP
	ID DSNKTut4POv1LwQT38IsgDe2kDfuG/pId8dT@postini.com;
	Fri, 16 Dec 2011 08:56:30 PST
Received: from USILMS171.ca.com (141.202.6.21) by USILMS191.ca.com
	(141.202.246.45) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Fri, 16 Dec 2011 11:56:27 -0500
Received: from USILMS110A.ca.com ([169.254.1.109]) by USILMS171.ca.com
	([141.202.6.21]) with mapi id 14.01.0289.001;
	Fri, 16 Dec 2011 11:56:27 -0500
From: "Taylor, Neal E" <Neal.Taylor@ca.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Thread-Topic: patch "[PATCH] xen/swiotlb: Use page alignment for early
	buffer allocation." failed to apply to 3.1-stable tree
Thread-Index: AQHMu39EqhS6jdpwjEafu8REQ03Ud5Xdo1+ggAFNCgD//78B4A==
Date: Fri, 16 Dec 2011 16:56:27 +0000
Message-ID: <3E243B26F475504B9BB0BCC9728B0DA629E1B140@USILMS110A.ca.com>
References: <13239908451694@kroah.org>
	<3E243B26F475504B9BB0BCC9728B0DA629E1AC69@USILMS110A.ca.com>
	<20111216154554.GG31755@phenom.dumpdata.com>
In-Reply-To: <20111216154554.GG31755@phenom.dumpdata.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [138.42.46.105]
MIME-Version: 1.0
Cc: "gregkh@suse.de" <gregkh@suse.de>, "Kalev, Leonid" <Leonid.Kalev@ca.com>,
	xen-devel <xen-devel@lists.xensource.com>,
	"stable@vger.kernel.org" <stable@vger.kernel.org>
Subject: Re: [Xen-devel] patch "[PATCH] xen/swiotlb: Use page alignment for
 early buffer allocation." failed to apply to 3.1-stable tree
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Clean 3.1.5 + this patch and clean 3.0.4 + this patch tested on the server that exhibited the symptom. They boot then PCI devices recognize they can and then do use DMA.

Neal

-----Original Message-----
From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@oracle.com] 
Sent: Friday, December 16, 2011 7:46 AM
To: Taylor, Neal E
Cc: stable@vger.kernel.org; gregkh@suse.de; Kalev, Leonid; xen-devel
Subject: Re: patch "[PATCH] xen/swiotlb: Use page alignment for early buffer allocation." failed to apply to 3.1-stable tree

On Fri, Dec 16, 2011 at 12:58:55AM +0000, Taylor, Neal E wrote:
> Konrad,
> 
> This patch applies and compiles on 3.1.5 and 3.0.4. I'll test tomorrow.

OK. I've tested it on 3.1.5 and 3.0.6 as well. If I recall you mentioned
that you had tested the 3.0.4 + this patch yesterday (thought you
probably had tons of debugging patches too). Is that you are testing a clean
version of 3.0.4 with this patch? Or are you testing both trees on your box?

Thanks!
> 
> Neal
> 
> diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
> index 8e964b9..5c8e445 100644
> --- a/drivers/xen/swiotlb-xen.c
> +++ b/drivers/xen/swiotlb-xen.c
> @@ -166,7 +166,8 @@ retry:
>         /*
>          * Get IO TLB memory from any location.
>          */
> -       xen_io_tlb_start = alloc_bootmem(bytes);
> +       xen_io_tlb_start = alloc_bootmem_pages(PAGE_ALIGN(bytes));
> +
>         if (!xen_io_tlb_start)
>                 panic("Cannot allocate SWIOTLB buffer");
> 
> -----Original Message-----
> From: gregkh@suse.de [mailto:gregkh@suse.de] 
> Sent: Thursday, December 15, 2011 3:14 PM
> To: konrad.wilk@oracle.com; Kalev, Leonid; Taylor, Neal E
> Cc: stable@vger.kernel.org
> Subject: patch "[PATCH] xen/swiotlb: Use page alignment for early buffer allocation." failed to apply to 3.1-stable tree
> 
> 
> The patch below does not apply to the 3.1-stable tree.
> If someone wants it applied there, or to any other stable or longterm
> tree, then please email the backport, including the original git commit
> id to <stable@vger.kernel.org>.
> 
> thanks,
> 
> greg k-h
> 
> ------------------ original commit in Linus's tree ------------------
> 
> >From 63a741757d15320a25ebf5778f8651cce2ed0611 Mon Sep 17 00:00:00 2001
> From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> Date: Thu, 15 Dec 2011 11:28:46 -0500
> Subject: [PATCH] xen/swiotlb: Use page alignment for early buffer allocation.
> 
> This fixes an odd bug found on a Dell PowerEdge 1850/0RC130
> (BIOS A05 01/09/2006) where all of the modules doing pci_set_dma_mask
> would fail with:
> 
> ata_piix 0000:00:1f.1: enabling device (0005 -> 0007)
> ata_piix 0000:00:1f.1: can't derive routing for PCI INT A
> ata_piix 0000:00:1f.1: BMDMA: failed to set dma mask, falling back to PIO
> 
> The issue was the Xen-SWIOTLB was allocated such as that the end of
> buffer was stradling a page (and also above 4GB). The fix was
> spotted by Kalev Leonid  which was to piggyback on git commit
> e79f86b2ef9c0a8c47225217c1018b7d3d90101c "swiotlb: Use page alignment
> for early buffer allocation" which:
> 
> 	We could call free_bootmem_late() if swiotlb is not used, and
> 	it will shrink to page alignment.
> 
> 	So alloc them with page alignment at first, to avoid lose two pages
> 
> And doing that fixes the outstanding issue.
> 
> CC: stable@kernel.org
> Suggested-by: "Kalev, Leonid" <Leonid.Kalev@ca.com>
> Reported-and-Tested-by: "Taylor, Neal E" <Neal.Taylor@ca.com>
> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> 
> diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
> index 8e964b9..284798a 100644
> --- a/drivers/xen/swiotlb-xen.c
> +++ b/drivers/xen/swiotlb-xen.c
> @@ -166,7 +166,7 @@ retry:
>  	/*
>  	 * Get IO TLB memory from any location.
>  	 */
> -	xen_io_tlb_start = alloc_bootmem(bytes);
> +	xen_io_tlb_start = alloc_bootmem_pages(PAGE_ALIGN(bytes));
>  	if (!xen_io_tlb_start) {
>  		m = "Cannot allocate Xen-SWIOTLB buffer!\n";
>  		goto error;
> @@ -179,7 +179,7 @@ retry:
>  			       bytes,
>  			       xen_io_tlb_nslabs);
>  	if (rc) {
> -		free_bootmem(__pa(xen_io_tlb_start), bytes);
> +		free_bootmem(__pa(xen_io_tlb_start), PAGE_ALIGN(bytes));
>  		m = "Failed to get contiguous memory for DMA from Xen!\n"\
>  		    "You either: don't have the permissions, do not have"\
>  		    " enough free memory under 4GB, or the hypervisor memory"\

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 17:02:41 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 17:02:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbbAq-0006Ze-AE; Fri, 16 Dec 2011 17:02:20 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RbbAp-0006ZK-2X
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 17:02:19 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-13.tower-21.messagelabs.com!1324054932!6584589!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzMzExNDY=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzMzExNDY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27130 invoked from network); 16 Dec 2011 17:02:13 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-13.tower-21.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 16 Dec 2011 17:02:13 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1324054932; l=458;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=CvVpOwotpECB7LsX31TQWTa3G5g=;
	b=sF4B87jWlN/9VHdtYwcaByWLbQEIIiKsnhoO170J5LBa0rYucFcggaTZAp54PU8A6Oq
	ahc7Cn0SgFq/obfEhlPJUkkjtkXoJ7pDl7iOIzSJK2wEM5u14XfVdUYgngnS8KRGgTxeD
	YLxKfgSOf8AoMz7rX/ClbW776hRuSE5R8J0=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFPjzEQG5of
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-112-083.pools.arcor-ip.net [88.65.112.83])
	by smtp.strato.de (fruni mo36) (RZmta 26.15 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id x044a7nBGEGIiy ;
	Fri, 16 Dec 2011 18:01:55 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id B105218637; Fri, 16 Dec 2011 18:01:54 +0100 (CET)
Date: Fri, 16 Dec 2011 18:01:54 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20111216170154.GA25941@aepfle.de>
References: <4EEA4877.8010307@canonical.com>
	<1323982417.20936.898.camel@dagon.hellion.org.uk>
	<4EEB0CE9.4040405@canonical.com>
	<1324027918.20077.530.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1324027918.20077.530.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefan Bader <stefan.bader@canonical.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] xenbus and the message of doom
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Dec 16, Ian Campbell wrote:

> I think (or hope!) that Olaf tested with the most recent version of C
> xenstored which did not support this new message and so I presume that
> it correct returns an error for an unknown message but that doesn't help
> us with the older C xenstored which you have.

I just checked a SLES10SP3 host (xen 3.2.3) with a SLES11SP2 hvm guest
and it booted fine.

So I suspect EC2 is broken in this case.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 17:02:41 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 17:02:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbbAq-0006Ze-AE; Fri, 16 Dec 2011 17:02:20 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RbbAp-0006ZK-2X
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 17:02:19 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-13.tower-21.messagelabs.com!1324054932!6584589!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzMzExNDY=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzMzExNDY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27130 invoked from network); 16 Dec 2011 17:02:13 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-13.tower-21.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 16 Dec 2011 17:02:13 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1324054932; l=458;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=CvVpOwotpECB7LsX31TQWTa3G5g=;
	b=sF4B87jWlN/9VHdtYwcaByWLbQEIIiKsnhoO170J5LBa0rYucFcggaTZAp54PU8A6Oq
	ahc7Cn0SgFq/obfEhlPJUkkjtkXoJ7pDl7iOIzSJK2wEM5u14XfVdUYgngnS8KRGgTxeD
	YLxKfgSOf8AoMz7rX/ClbW776hRuSE5R8J0=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFPjzEQG5of
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-112-083.pools.arcor-ip.net [88.65.112.83])
	by smtp.strato.de (fruni mo36) (RZmta 26.15 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id x044a7nBGEGIiy ;
	Fri, 16 Dec 2011 18:01:55 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id B105218637; Fri, 16 Dec 2011 18:01:54 +0100 (CET)
Date: Fri, 16 Dec 2011 18:01:54 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20111216170154.GA25941@aepfle.de>
References: <4EEA4877.8010307@canonical.com>
	<1323982417.20936.898.camel@dagon.hellion.org.uk>
	<4EEB0CE9.4040405@canonical.com>
	<1324027918.20077.530.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1324027918.20077.530.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefan Bader <stefan.bader@canonical.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] xenbus and the message of doom
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Dec 16, Ian Campbell wrote:

> I think (or hope!) that Olaf tested with the most recent version of C
> xenstored which did not support this new message and so I presume that
> it correct returns an error for an unknown message but that doesn't help
> us with the older C xenstored which you have.

I just checked a SLES10SP3 host (xen 3.2.3) with a SLES11SP2 hvm guest
and it booted fine.

So I suspect EC2 is broken in this case.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 17:02:57 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 17:02:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbbB9-0006bd-Ny; Fri, 16 Dec 2011 17:02:39 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RbbB7-0006b2-JZ
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 17:02:37 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1324054951!7699480!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjU3OQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2973 invoked from network); 16 Dec 2011 17:02:31 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Dec 2011 17:02:31 -0000
X-IronPort-AV: E=Sophos;i="4.71,364,1320624000"; 
   d="scan'208";a="9521252"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Dec 2011 17:02:31 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 16 Dec 2011 17:02:31 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RbbB0-00071X-VC;
	Fri, 16 Dec 2011 17:02:30 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RbbB0-0005M2-ND;
	Fri, 16 Dec 2011 17:02:30 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10517-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 16 Dec 2011 17:02:30 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10517: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10517 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10517/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-win7-amd64  7 windows-install            fail pass in 10515
 test-amd64-i386-win-vcpus1    7 windows-install             fail pass in 10515
 test-amd64-amd64-xl-win7-amd64  7 windows-install           fail pass in 10515
 test-amd64-i386-xl-credit2    7 debian-install     fail in 10515 pass in 10517
 test-amd64-amd64-xl-sedf      5 xen-boot           fail in 10515 pass in 10517

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop           fail in 10515 never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check      fail in 10515 never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop          fail in 10515 never pass
 test-amd64-i386-xend-winxpsp3  7 windows-install      fail in 10515 like 10491

version targeted for testing:
 xen                  01c8b27e3d7d
baseline version:
 xen                  03138a08366b

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Christoph Egger <Christoph.Egger@amd.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Liu, Jinsong <jinsong.liu@intel.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-unstable
+ revision=01c8b27e3d7d
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-unstable 01c8b27e3d7d
+ branch=xen-unstable
+ revision=01c8b27e3d7d
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ : xen@xenbits.xensource.com
+ : xen@xenbits.xensource.com:git/linux-pvops
+ : master
+ : tested/2.6.39.x
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r 01c8b27e3d7d ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 9 changesets with 20 changes to 16 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 17:02:57 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 17:02:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbbB9-0006bd-Ny; Fri, 16 Dec 2011 17:02:39 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RbbB7-0006b2-JZ
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 17:02:37 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1324054951!7699480!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjU3OQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2973 invoked from network); 16 Dec 2011 17:02:31 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Dec 2011 17:02:31 -0000
X-IronPort-AV: E=Sophos;i="4.71,364,1320624000"; 
   d="scan'208";a="9521252"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Dec 2011 17:02:31 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 16 Dec 2011 17:02:31 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RbbB0-00071X-VC;
	Fri, 16 Dec 2011 17:02:30 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RbbB0-0005M2-ND;
	Fri, 16 Dec 2011 17:02:30 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10517-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 16 Dec 2011 17:02:30 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10517: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10517 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10517/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-win7-amd64  7 windows-install            fail pass in 10515
 test-amd64-i386-win-vcpus1    7 windows-install             fail pass in 10515
 test-amd64-amd64-xl-win7-amd64  7 windows-install           fail pass in 10515
 test-amd64-i386-xl-credit2    7 debian-install     fail in 10515 pass in 10517
 test-amd64-amd64-xl-sedf      5 xen-boot           fail in 10515 pass in 10517

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop           fail in 10515 never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check      fail in 10515 never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop          fail in 10515 never pass
 test-amd64-i386-xend-winxpsp3  7 windows-install      fail in 10515 like 10491

version targeted for testing:
 xen                  01c8b27e3d7d
baseline version:
 xen                  03138a08366b

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Christoph Egger <Christoph.Egger@amd.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Liu, Jinsong <jinsong.liu@intel.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-unstable
+ revision=01c8b27e3d7d
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-unstable 01c8b27e3d7d
+ branch=xen-unstable
+ revision=01c8b27e3d7d
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ : xen@xenbits.xensource.com
+ : xen@xenbits.xensource.com:git/linux-pvops
+ : master
+ : tested/2.6.39.x
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r 01c8b27e3d7d ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 9 changesets with 20 changes to 16 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 17:04:39 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 17:04:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbbCt-0006mU-7L; Fri, 16 Dec 2011 17:04:27 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RbbCr-0006lb-Fn
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 17:04:25 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-10.tower-21.messagelabs.com!1324055058!8265451!1
X-Originating-IP: [208.97.132.119]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xMTkgPT4gMTc0NjE=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8801 invoked from network); 16 Dec 2011 17:04:19 -0000
Received: from caiajhbdcbbj.dreamhost.com (HELO homiemail-a22.g.dreamhost.com)
	(208.97.132.119) by server-10.tower-21.messagelabs.com with SMTP;
	16 Dec 2011 17:04:19 -0000
Received: from homiemail-a22.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a22.g.dreamhost.com (Postfix) with ESMTP id 13DF01A8069;
	Fri, 16 Dec 2011 09:04:18 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=UpBsePVHC3emLYRwU89AL1Hh++0kRR7t7tNZXKFhWk0U
	PHBi76+PdAyqgVgoojqYUCEWgMBS1K5xkm5fCOOXcsVH4N9Q48lk+L/C18tds1Qt
	KRAnJYxcWrNMIx9qQGWc3KORN3WCQoUJ31kmN+7oTEHaNMMGT/1eFtxhJjzyE5M=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=poJRD4QzMzxuc7wtrF2Lm4lRXME=; b=rIU8Ge7H
	x+J5lAjsIqX3t8hjx63GKFk6mMurBOkVc5aerLNgiPWAuxUJYePBkHHT+8geuHEX
	+vDPBceXB/yhET1jZXRBAY9FutuvtZoz8omACA3XnYnjdp3wNVoCEzfLFKesm6LT
	H5HVSsWfFXqET/eBOhSwhcRfdgN0pdzFZuM=
Received: from webmail.lagarcavilla.org (ahfbbjcaiaae.dreamhost.com
	[75.119.208.4]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a22.g.dreamhost.com (Postfix) with ESMTPA id BC7F51A8061; 
	Fri, 16 Dec 2011 09:04:17 -0800 (PST)
Received: from 190.18.220.100 (proxying for 190.18.220.100)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Fri, 16 Dec 2011 09:04:18 -0800
Message-ID: <b9da75173754803d676d0f4c3c4c3a47.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20111216164033.GA25508@aepfle.de>
References: <mailman.4227.1323785898.12970.xen-devel@lists.xensource.com>
	<3d5947b7ee3b2fdda393744f59d55b76.squirrel@webmail.lagarcavilla.org>
	<20111216164033.GA25508@aepfle.de>
Date: Fri, 16 Dec 2011 09:04:18 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Olaf Hering" <olaf@aepfle.de>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, tim@xen.org, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH] mem_event: use wait queue when ring is full
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> On Thu, Dec 15, Andres Lagar-Cavilla wrote:
>
>> > - How many requests should foreign vcpus place in the ring if the
>> guest
>> >   has more vcpus than available slots in the ring? Just a single one
>> so
>> >   that foreigners can also make some progress?
>> The idea is that foreign vcpus can place as many events as they want as
>> long as each guest vcpu that is not blocked on a men event has room to
>> send one men event. When we reach that border condition, no more foreign
>> men events.
>>
>> The case for which there are way too many guest vcpus needs to be
>> handled,
>> either by capping the max number of vcpus for domains using a men event,
>> or by growing the ring size.
>
> Right now the ring is one page, so it can not hold more than 64 entries.
> If that ever changes, the accounting can be adjusted.
>
>> > - Should access and paging have the same rules for accounting?
>> Absolutely.
>>
>> And both should use wait queues in extreme cases in which a guest vcpu
>> with a single action generates multiple memory events. Given that when
>> we
>> hit a border condition the guest vcpu will place one event and be
>> flagged
>> VPF_mem_event_paused (or whatever that flag is named), if a guest vcpu
>> generates another event when flagged, that's our queue for putting the
>> vcpu on a wait queue.
>
> An extra flag is not needed.
Can you elaborate? Which flag is not needed? And why?

>
> Below is an incremental patch (on top of v6) which does some accounting.
> Its just compile tested.
>
> Olaf
>
>
> diff -r 5d5d10e1568b xen/arch/x86/mm/mem_event.c
> --- a/xen/arch/x86/mm/mem_event.c
> +++ b/xen/arch/x86/mm/mem_event.c
> @@ -114,6 +114,19 @@ static int mem_event_enable(
>
>      med->pause_flag = pause_flag;
>
> +    /*
> +     * Configure ring accounting:
> +     * Each guest vcpu should be able to place at least one request.
> +     * If there are more vcpus than available slots in the ring, not all
> vcpus
> +     * can place requests in the ring anyway.  A minimum (arbitrary)
> number of
> +     * foreign requests will be allowed in this case.
> +     */
> +    if ( d->max_vcpus < RING_SIZE(&med->front_ring) )
> +        med->max_foreign = RING_SIZE(&med->front_ring) - d->max_vcpus;
> +    if ( med->max_foreign < 13 )
> +        med->max_foreign = 13;
Magic number! Why?

More generally, does this patch apply on top of a previous patch? What's
the context here?

Thanks
Andres

> +    med->max_target = RING_SIZE(&med->front_ring) - med->max_foreign;
> +
>      init_waitqueue_head(&med->wq);
>
>      /* Wake any VCPUs waiting for the ring to appear */
> @@ -147,23 +160,28 @@ static int mem_event_disable(struct mem_
>
>  static int _mem_event_put_request(struct domain *d,
>                                    struct mem_event_domain *med,
> -                                  mem_event_request_t *req)
> +                                  mem_event_request_t *req,
> +                                  int *done)
>  {
>      mem_event_front_ring_t *front_ring;
> -    int free_req, claimed_req;
> +    int free_req, claimed_req, ret;
>      RING_IDX req_prod;
>
> +    if ( *done )
> +        return 1;
> +
>      mem_event_ring_lock(med);
>
> -    free_req = RING_FREE_REQUESTS(&med->front_ring);
> +    front_ring = &med->front_ring;
> +
>      /* Foreign requests must succeed because their vcpus can not sleep */
>      claimed_req = med->foreign_producers;
> +    free_req = RING_FREE_REQUESTS(front_ring);
>      if ( !free_req || ( current->domain == d && free_req <= claimed_req )
> ) {
>          mem_event_ring_unlock(med);
>          return 0;
>      }
>
> -    front_ring = &med->front_ring;
>      req_prod = front_ring->req_prod_pvt;
>
>      if ( current->domain != d )
> @@ -176,9 +194,18 @@ static int _mem_event_put_request(struct
>      memcpy(RING_GET_REQUEST(front_ring, req_prod), req, sizeof(*req));
>      req_prod++;
>
> +    ret = 1;
> +    *done = 1;
> +    free_req--;
> +
>      /* Update accounting */
>      if ( current->domain == d )
> +    {
>          med->target_producers--;
> +        /* Ring is full, no more requests from this vcpu, go to sleep */
> +        if ( free_req < med->max_target )
> +            ret = 0;
> +    }
>      else
>          med->foreign_producers--;
>
> @@ -190,19 +217,20 @@ static int _mem_event_put_request(struct
>
>      notify_via_xen_event_channel(d, med->xen_port);
>
> -    return 1;
> +    return ret;
>  }
>
>  void mem_event_put_request(struct domain *d, struct mem_event_domain
> *med,
>                             mem_event_request_t *req)
>  {
> +    int done = 0;
>      /* Go to sleep if request came from guest */
>      if (current->domain == d) {
> -        wait_event(med->wq, _mem_event_put_request(d, med, req));
> +        wait_event(med->wq, _mem_event_put_request(d, med, req, &done));
>          return;
>      }
>      /* Ring was full anyway, unable to sleep in non-guest context */
> -    if (!_mem_event_put_request(d, med, req))
> +    if (!_mem_event_put_request(d, med, req, &done))
>          printk("Failed to put memreq: d %u t %x f %x gfn %lx\n",
> d->domain_id,
>                  req->type, req->flags, (unsigned long)req->gfn);
>  }
> @@ -341,7 +369,8 @@ int mem_event_claim_slot(struct domain *
>          med->target_producers++;
>          ring_full = 0;
>      }
> -    else if ( med->foreign_producers + med->target_producers + 1 <
> free_req )
> +    else if ( med->foreign_producers + med->target_producers < free_req
> &&
> +              med->foreign_producers < med->max_foreign )
>      {
>          med->foreign_producers++;
>          ring_full = 0;
> diff -r 5d5d10e1568b xen/include/xen/sched.h
> --- a/xen/include/xen/sched.h
> +++ b/xen/include/xen/sched.h
> @@ -184,8 +184,11 @@ struct mem_event_domain
>  {
>      /* ring lock */
>      spinlock_t ring_lock;
> -    unsigned short foreign_producers;
> -    unsigned short target_producers;
> +    /* The ring has 64 entries */
> +    unsigned char foreign_producers;
> +    unsigned char max_foreign;
> +    unsigned char target_producers;
> +    unsigned char max_target;
>      /* shared page */
>      mem_event_shared_page_t *shared_page;
>      /* shared ring page */
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 17:04:39 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 17:04:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbbCt-0006mU-7L; Fri, 16 Dec 2011 17:04:27 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RbbCr-0006lb-Fn
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 17:04:25 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-10.tower-21.messagelabs.com!1324055058!8265451!1
X-Originating-IP: [208.97.132.119]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xMTkgPT4gMTc0NjE=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8801 invoked from network); 16 Dec 2011 17:04:19 -0000
Received: from caiajhbdcbbj.dreamhost.com (HELO homiemail-a22.g.dreamhost.com)
	(208.97.132.119) by server-10.tower-21.messagelabs.com with SMTP;
	16 Dec 2011 17:04:19 -0000
Received: from homiemail-a22.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a22.g.dreamhost.com (Postfix) with ESMTP id 13DF01A8069;
	Fri, 16 Dec 2011 09:04:18 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=UpBsePVHC3emLYRwU89AL1Hh++0kRR7t7tNZXKFhWk0U
	PHBi76+PdAyqgVgoojqYUCEWgMBS1K5xkm5fCOOXcsVH4N9Q48lk+L/C18tds1Qt
	KRAnJYxcWrNMIx9qQGWc3KORN3WCQoUJ31kmN+7oTEHaNMMGT/1eFtxhJjzyE5M=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=poJRD4QzMzxuc7wtrF2Lm4lRXME=; b=rIU8Ge7H
	x+J5lAjsIqX3t8hjx63GKFk6mMurBOkVc5aerLNgiPWAuxUJYePBkHHT+8geuHEX
	+vDPBceXB/yhET1jZXRBAY9FutuvtZoz8omACA3XnYnjdp3wNVoCEzfLFKesm6LT
	H5HVSsWfFXqET/eBOhSwhcRfdgN0pdzFZuM=
Received: from webmail.lagarcavilla.org (ahfbbjcaiaae.dreamhost.com
	[75.119.208.4]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a22.g.dreamhost.com (Postfix) with ESMTPA id BC7F51A8061; 
	Fri, 16 Dec 2011 09:04:17 -0800 (PST)
Received: from 190.18.220.100 (proxying for 190.18.220.100)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Fri, 16 Dec 2011 09:04:18 -0800
Message-ID: <b9da75173754803d676d0f4c3c4c3a47.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20111216164033.GA25508@aepfle.de>
References: <mailman.4227.1323785898.12970.xen-devel@lists.xensource.com>
	<3d5947b7ee3b2fdda393744f59d55b76.squirrel@webmail.lagarcavilla.org>
	<20111216164033.GA25508@aepfle.de>
Date: Fri, 16 Dec 2011 09:04:18 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Olaf Hering" <olaf@aepfle.de>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, tim@xen.org, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH] mem_event: use wait queue when ring is full
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> On Thu, Dec 15, Andres Lagar-Cavilla wrote:
>
>> > - How many requests should foreign vcpus place in the ring if the
>> guest
>> >   has more vcpus than available slots in the ring? Just a single one
>> so
>> >   that foreigners can also make some progress?
>> The idea is that foreign vcpus can place as many events as they want as
>> long as each guest vcpu that is not blocked on a men event has room to
>> send one men event. When we reach that border condition, no more foreign
>> men events.
>>
>> The case for which there are way too many guest vcpus needs to be
>> handled,
>> either by capping the max number of vcpus for domains using a men event,
>> or by growing the ring size.
>
> Right now the ring is one page, so it can not hold more than 64 entries.
> If that ever changes, the accounting can be adjusted.
>
>> > - Should access and paging have the same rules for accounting?
>> Absolutely.
>>
>> And both should use wait queues in extreme cases in which a guest vcpu
>> with a single action generates multiple memory events. Given that when
>> we
>> hit a border condition the guest vcpu will place one event and be
>> flagged
>> VPF_mem_event_paused (or whatever that flag is named), if a guest vcpu
>> generates another event when flagged, that's our queue for putting the
>> vcpu on a wait queue.
>
> An extra flag is not needed.
Can you elaborate? Which flag is not needed? And why?

>
> Below is an incremental patch (on top of v6) which does some accounting.
> Its just compile tested.
>
> Olaf
>
>
> diff -r 5d5d10e1568b xen/arch/x86/mm/mem_event.c
> --- a/xen/arch/x86/mm/mem_event.c
> +++ b/xen/arch/x86/mm/mem_event.c
> @@ -114,6 +114,19 @@ static int mem_event_enable(
>
>      med->pause_flag = pause_flag;
>
> +    /*
> +     * Configure ring accounting:
> +     * Each guest vcpu should be able to place at least one request.
> +     * If there are more vcpus than available slots in the ring, not all
> vcpus
> +     * can place requests in the ring anyway.  A minimum (arbitrary)
> number of
> +     * foreign requests will be allowed in this case.
> +     */
> +    if ( d->max_vcpus < RING_SIZE(&med->front_ring) )
> +        med->max_foreign = RING_SIZE(&med->front_ring) - d->max_vcpus;
> +    if ( med->max_foreign < 13 )
> +        med->max_foreign = 13;
Magic number! Why?

More generally, does this patch apply on top of a previous patch? What's
the context here?

Thanks
Andres

> +    med->max_target = RING_SIZE(&med->front_ring) - med->max_foreign;
> +
>      init_waitqueue_head(&med->wq);
>
>      /* Wake any VCPUs waiting for the ring to appear */
> @@ -147,23 +160,28 @@ static int mem_event_disable(struct mem_
>
>  static int _mem_event_put_request(struct domain *d,
>                                    struct mem_event_domain *med,
> -                                  mem_event_request_t *req)
> +                                  mem_event_request_t *req,
> +                                  int *done)
>  {
>      mem_event_front_ring_t *front_ring;
> -    int free_req, claimed_req;
> +    int free_req, claimed_req, ret;
>      RING_IDX req_prod;
>
> +    if ( *done )
> +        return 1;
> +
>      mem_event_ring_lock(med);
>
> -    free_req = RING_FREE_REQUESTS(&med->front_ring);
> +    front_ring = &med->front_ring;
> +
>      /* Foreign requests must succeed because their vcpus can not sleep */
>      claimed_req = med->foreign_producers;
> +    free_req = RING_FREE_REQUESTS(front_ring);
>      if ( !free_req || ( current->domain == d && free_req <= claimed_req )
> ) {
>          mem_event_ring_unlock(med);
>          return 0;
>      }
>
> -    front_ring = &med->front_ring;
>      req_prod = front_ring->req_prod_pvt;
>
>      if ( current->domain != d )
> @@ -176,9 +194,18 @@ static int _mem_event_put_request(struct
>      memcpy(RING_GET_REQUEST(front_ring, req_prod), req, sizeof(*req));
>      req_prod++;
>
> +    ret = 1;
> +    *done = 1;
> +    free_req--;
> +
>      /* Update accounting */
>      if ( current->domain == d )
> +    {
>          med->target_producers--;
> +        /* Ring is full, no more requests from this vcpu, go to sleep */
> +        if ( free_req < med->max_target )
> +            ret = 0;
> +    }
>      else
>          med->foreign_producers--;
>
> @@ -190,19 +217,20 @@ static int _mem_event_put_request(struct
>
>      notify_via_xen_event_channel(d, med->xen_port);
>
> -    return 1;
> +    return ret;
>  }
>
>  void mem_event_put_request(struct domain *d, struct mem_event_domain
> *med,
>                             mem_event_request_t *req)
>  {
> +    int done = 0;
>      /* Go to sleep if request came from guest */
>      if (current->domain == d) {
> -        wait_event(med->wq, _mem_event_put_request(d, med, req));
> +        wait_event(med->wq, _mem_event_put_request(d, med, req, &done));
>          return;
>      }
>      /* Ring was full anyway, unable to sleep in non-guest context */
> -    if (!_mem_event_put_request(d, med, req))
> +    if (!_mem_event_put_request(d, med, req, &done))
>          printk("Failed to put memreq: d %u t %x f %x gfn %lx\n",
> d->domain_id,
>                  req->type, req->flags, (unsigned long)req->gfn);
>  }
> @@ -341,7 +369,8 @@ int mem_event_claim_slot(struct domain *
>          med->target_producers++;
>          ring_full = 0;
>      }
> -    else if ( med->foreign_producers + med->target_producers + 1 <
> free_req )
> +    else if ( med->foreign_producers + med->target_producers < free_req
> &&
> +              med->foreign_producers < med->max_foreign )
>      {
>          med->foreign_producers++;
>          ring_full = 0;
> diff -r 5d5d10e1568b xen/include/xen/sched.h
> --- a/xen/include/xen/sched.h
> +++ b/xen/include/xen/sched.h
> @@ -184,8 +184,11 @@ struct mem_event_domain
>  {
>      /* ring lock */
>      spinlock_t ring_lock;
> -    unsigned short foreign_producers;
> -    unsigned short target_producers;
> +    /* The ring has 64 entries */
> +    unsigned char foreign_producers;
> +    unsigned char max_foreign;
> +    unsigned char target_producers;
> +    unsigned char max_target;
>      /* shared page */
>      mem_event_shared_page_t *shared_page;
>      /* shared ring page */
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 17:17:10 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 17:17:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbbOy-0007Qd-Ly; Fri, 16 Dec 2011 17:16:56 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Huang2@amd.com>) id 1RbbOx-0007QV-4v
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 17:16:55 +0000
X-Env-Sender: Wei.Huang2@amd.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1324055808!5857850!1
X-Originating-IP: [213.199.154.144]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3528 invoked from network); 16 Dec 2011 17:16:48 -0000
Received: from db3ehsobe006.messaging.microsoft.com (HELO
	DB3EHSOBE006.bigfish.com) (213.199.154.144)
	by server-13.tower-174.messagelabs.com with AES128-SHA encrypted SMTP;
	16 Dec 2011 17:16:48 -0000
Received: from mail52-db3-R.bigfish.com (10.3.81.249) by
	DB3EHSOBE006.bigfish.com (10.3.84.26) with Microsoft SMTP Server id
	14.1.225.23; Fri, 16 Dec 2011 17:16:47 +0000
Received: from mail52-db3 (localhost [127.0.0.1])	by mail52-db3-R.bigfish.com
	(Postfix) with ESMTP id 12D09240345;
	Fri, 16 Dec 2011 17:16:57 +0000 (UTC)
X-SpamScore: -11
X-BigFish: VPS-11(zzbb2dI9371I1432N98dKzz1202hzz8275bhz2dh668h839h)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
Received: from mail52-db3 (localhost.localdomain [127.0.0.1]) by mail52-db3
	(MessageSwitch) id 1324055816765173_8681;
	Fri, 16 Dec 2011 17:16:56 +0000 (UTC)
Received: from DB3EHSMHS019.bigfish.com (unknown [10.3.81.248])	by
	mail52-db3.bigfish.com (Postfix) with ESMTP id AB5F144004F;
	Fri, 16 Dec 2011 17:16:56 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	DB3EHSMHS019.bigfish.com (10.3.87.119) with Microsoft SMTP Server id
	14.1.225.23; Fri, 16 Dec 2011 17:16:44 +0000
X-WSS-ID: 0LWB3ZU-02-7MR-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp02.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2CFB7C8090;	Fri, 16 Dec 2011 11:16:41 -0600 (CST)
Received: from sausexhtp02.amd.com (163.181.3.152) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Fri, 16 Dec 2011 11:17:02 -0600
Received: from [10.236.49.124] (10.236.49.124) by sausexhtp02.amd.com
	(163.181.3.152) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 16 Dec 2011 11:16:43 -0600
Message-ID: <4EEB7CFC.70105@amd.com>
Date: Fri, 16 Dec 2011 11:16:44 -0600
From: Wei Huang <wei.huang2@amd.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:8.0) Gecko/20111124 Thunderbird/8.0
MIME-Version: 1.0
To: Boris Ostrovsky <boris.ostrovsky@amd.com>
References: <4EEB70910200007800068852@nat28.tlf.novell.com>
	<4EEB7802.4060803@amd.com>
In-Reply-To: <4EEB7802.4060803@amd.com>
X-OriginatorOrg: amd.com
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH] x86/AMD: fold redundant parameters of
	cpu_has_amd_erratum()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Acked-by: Wei Huang <wei.huang2@amd.com>

On 12/16/2011 10:55 AM, Boris Ostrovsky wrote:
> On 12/16/11 10:23, Jan Beulich wrote:
>> The boolean 'osvw' indicator and 'osvw_id' can be folded - the function
>> can as well distinguish the non-OSVW case by checking for a negative
>> 'osvw_id'. That way the whole variable argument list processing is only
>> needed on the legacy code path.
>>
>> Signed-off-by: Jan Beulich<jbeulich@suse.com>
>
> Acked-by: Boris Ostrovsky <boris.ostrovsky@amd.com>
>
>>
>> --- a/xen/arch/x86/cpu/amd.c
>> +++ b/xen/arch/x86/cpu/amd.c
>> @@ -186,7 +186,7 @@ static void __devinit set_cpuidmask(cons
>>    * Check for the presence of an AMD erratum. Arguments are defined 
>> in amd.h
>>    * for each known erratum. Return 1 if erratum is found.
>>    */
>> -int cpu_has_amd_erratum(const struct cpuinfo_x86 *cpu, int osvw, ...)
>> +int cpu_has_amd_erratum(const struct cpuinfo_x86 *cpu, int osvw_id, 
>> ...)
>>   {
>>       va_list ap;
>>       u32 range;
>> @@ -195,27 +195,24 @@ int cpu_has_amd_erratum(const struct cpu
>>       if (cpu->x86_vendor != X86_VENDOR_AMD)
>>           return 0;
>>
>> -    va_start(ap, osvw);
>> +    if (osvw_id>= 0&&  cpu_has(cpu, X86_FEATURE_OSVW)) {
>> +        u64 osvw_len;
>>
>> -    if (osvw) {
>> -        u16 osvw_id = va_arg(ap, int);
>> +        rdmsrl(MSR_AMD_OSVW_ID_LENGTH, osvw_len);
>>
>> -        if (cpu_has(cpu, X86_FEATURE_OSVW)) {
>> -            u64 osvw_len;
>> -            rdmsrl(MSR_AMD_OSVW_ID_LENGTH, osvw_len);
>> -
>> -            if (osvw_id<  osvw_len) {
>> -                u64 osvw_bits;
>> -                rdmsrl(MSR_AMD_OSVW_STATUS + (osvw_id>>  6),
>> -                       osvw_bits);
>> +        if (osvw_id<  osvw_len) {
>> +            u64 osvw_bits;
>>
>> -                va_end(ap);
>> -                return (osvw_bits>>  (osvw_id&  0x3f))&  0x01;
>> -            }
>> +            rdmsrl(MSR_AMD_OSVW_STATUS + (osvw_id>>  6),
>> +                   osvw_bits);
>> +
>> +            return (osvw_bits>>  (osvw_id&  0x3f))&  1;
>>           }
>>       }
>>
>>       /* OSVW unavailable or ID unknown, match family-model-stepping 
>> range */
>> +    va_start(ap, osvw_id);
>> +
>>       ms = (cpu->x86_model<<  4) | cpu->x86_mask;
>>       while ((range = va_arg(ap, int))) {
>>           if ((cpu->x86 == AMD_MODEL_RANGE_FAMILY(range))&&
>> --- a/xen/include/asm-x86/amd.h
>> +++ b/xen/include/asm-x86/amd.h
>> @@ -119,8 +119,8 @@
>>    *
>>    */
>>
>> -#define AMD_LEGACY_ERRATUM(...)         0 /* legacy */, __VA_ARGS__, 0
>> -#define AMD_OSVW_ERRATUM(osvw_id, ...)  1 /* osvw */, osvw_id, 
>> __VA_ARGS__, 0
>> +#define AMD_LEGACY_ERRATUM(...)         -1 /* legacy */, __VA_ARGS__, 0
>> +#define AMD_OSVW_ERRATUM(osvw_id, ...)  osvw_id, __VA_ARGS__, 0
>>   #define AMD_MODEL_RANGE(f, m_start, s_start, m_end, 
>> s_end)              \
>>       ((f<<  24) | (m_start<<  16) | (s_start<<  12) | (m_end<<  4) | 
>> (s_end))
>>   #define AMD_MODEL_RANGE_FAMILY(range)   (((range)>>  24)&  0xff)
>>
>>
>>
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 17:17:10 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 17:17:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbbOy-0007Qd-Ly; Fri, 16 Dec 2011 17:16:56 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Huang2@amd.com>) id 1RbbOx-0007QV-4v
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 17:16:55 +0000
X-Env-Sender: Wei.Huang2@amd.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1324055808!5857850!1
X-Originating-IP: [213.199.154.144]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3528 invoked from network); 16 Dec 2011 17:16:48 -0000
Received: from db3ehsobe006.messaging.microsoft.com (HELO
	DB3EHSOBE006.bigfish.com) (213.199.154.144)
	by server-13.tower-174.messagelabs.com with AES128-SHA encrypted SMTP;
	16 Dec 2011 17:16:48 -0000
Received: from mail52-db3-R.bigfish.com (10.3.81.249) by
	DB3EHSOBE006.bigfish.com (10.3.84.26) with Microsoft SMTP Server id
	14.1.225.23; Fri, 16 Dec 2011 17:16:47 +0000
Received: from mail52-db3 (localhost [127.0.0.1])	by mail52-db3-R.bigfish.com
	(Postfix) with ESMTP id 12D09240345;
	Fri, 16 Dec 2011 17:16:57 +0000 (UTC)
X-SpamScore: -11
X-BigFish: VPS-11(zzbb2dI9371I1432N98dKzz1202hzz8275bhz2dh668h839h)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
Received: from mail52-db3 (localhost.localdomain [127.0.0.1]) by mail52-db3
	(MessageSwitch) id 1324055816765173_8681;
	Fri, 16 Dec 2011 17:16:56 +0000 (UTC)
Received: from DB3EHSMHS019.bigfish.com (unknown [10.3.81.248])	by
	mail52-db3.bigfish.com (Postfix) with ESMTP id AB5F144004F;
	Fri, 16 Dec 2011 17:16:56 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	DB3EHSMHS019.bigfish.com (10.3.87.119) with Microsoft SMTP Server id
	14.1.225.23; Fri, 16 Dec 2011 17:16:44 +0000
X-WSS-ID: 0LWB3ZU-02-7MR-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp02.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2CFB7C8090;	Fri, 16 Dec 2011 11:16:41 -0600 (CST)
Received: from sausexhtp02.amd.com (163.181.3.152) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Fri, 16 Dec 2011 11:17:02 -0600
Received: from [10.236.49.124] (10.236.49.124) by sausexhtp02.amd.com
	(163.181.3.152) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 16 Dec 2011 11:16:43 -0600
Message-ID: <4EEB7CFC.70105@amd.com>
Date: Fri, 16 Dec 2011 11:16:44 -0600
From: Wei Huang <wei.huang2@amd.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:8.0) Gecko/20111124 Thunderbird/8.0
MIME-Version: 1.0
To: Boris Ostrovsky <boris.ostrovsky@amd.com>
References: <4EEB70910200007800068852@nat28.tlf.novell.com>
	<4EEB7802.4060803@amd.com>
In-Reply-To: <4EEB7802.4060803@amd.com>
X-OriginatorOrg: amd.com
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH] x86/AMD: fold redundant parameters of
	cpu_has_amd_erratum()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Acked-by: Wei Huang <wei.huang2@amd.com>

On 12/16/2011 10:55 AM, Boris Ostrovsky wrote:
> On 12/16/11 10:23, Jan Beulich wrote:
>> The boolean 'osvw' indicator and 'osvw_id' can be folded - the function
>> can as well distinguish the non-OSVW case by checking for a negative
>> 'osvw_id'. That way the whole variable argument list processing is only
>> needed on the legacy code path.
>>
>> Signed-off-by: Jan Beulich<jbeulich@suse.com>
>
> Acked-by: Boris Ostrovsky <boris.ostrovsky@amd.com>
>
>>
>> --- a/xen/arch/x86/cpu/amd.c
>> +++ b/xen/arch/x86/cpu/amd.c
>> @@ -186,7 +186,7 @@ static void __devinit set_cpuidmask(cons
>>    * Check for the presence of an AMD erratum. Arguments are defined 
>> in amd.h
>>    * for each known erratum. Return 1 if erratum is found.
>>    */
>> -int cpu_has_amd_erratum(const struct cpuinfo_x86 *cpu, int osvw, ...)
>> +int cpu_has_amd_erratum(const struct cpuinfo_x86 *cpu, int osvw_id, 
>> ...)
>>   {
>>       va_list ap;
>>       u32 range;
>> @@ -195,27 +195,24 @@ int cpu_has_amd_erratum(const struct cpu
>>       if (cpu->x86_vendor != X86_VENDOR_AMD)
>>           return 0;
>>
>> -    va_start(ap, osvw);
>> +    if (osvw_id>= 0&&  cpu_has(cpu, X86_FEATURE_OSVW)) {
>> +        u64 osvw_len;
>>
>> -    if (osvw) {
>> -        u16 osvw_id = va_arg(ap, int);
>> +        rdmsrl(MSR_AMD_OSVW_ID_LENGTH, osvw_len);
>>
>> -        if (cpu_has(cpu, X86_FEATURE_OSVW)) {
>> -            u64 osvw_len;
>> -            rdmsrl(MSR_AMD_OSVW_ID_LENGTH, osvw_len);
>> -
>> -            if (osvw_id<  osvw_len) {
>> -                u64 osvw_bits;
>> -                rdmsrl(MSR_AMD_OSVW_STATUS + (osvw_id>>  6),
>> -                       osvw_bits);
>> +        if (osvw_id<  osvw_len) {
>> +            u64 osvw_bits;
>>
>> -                va_end(ap);
>> -                return (osvw_bits>>  (osvw_id&  0x3f))&  0x01;
>> -            }
>> +            rdmsrl(MSR_AMD_OSVW_STATUS + (osvw_id>>  6),
>> +                   osvw_bits);
>> +
>> +            return (osvw_bits>>  (osvw_id&  0x3f))&  1;
>>           }
>>       }
>>
>>       /* OSVW unavailable or ID unknown, match family-model-stepping 
>> range */
>> +    va_start(ap, osvw_id);
>> +
>>       ms = (cpu->x86_model<<  4) | cpu->x86_mask;
>>       while ((range = va_arg(ap, int))) {
>>           if ((cpu->x86 == AMD_MODEL_RANGE_FAMILY(range))&&
>> --- a/xen/include/asm-x86/amd.h
>> +++ b/xen/include/asm-x86/amd.h
>> @@ -119,8 +119,8 @@
>>    *
>>    */
>>
>> -#define AMD_LEGACY_ERRATUM(...)         0 /* legacy */, __VA_ARGS__, 0
>> -#define AMD_OSVW_ERRATUM(osvw_id, ...)  1 /* osvw */, osvw_id, 
>> __VA_ARGS__, 0
>> +#define AMD_LEGACY_ERRATUM(...)         -1 /* legacy */, __VA_ARGS__, 0
>> +#define AMD_OSVW_ERRATUM(osvw_id, ...)  osvw_id, __VA_ARGS__, 0
>>   #define AMD_MODEL_RANGE(f, m_start, s_start, m_end, 
>> s_end)              \
>>       ((f<<  24) | (m_start<<  16) | (s_start<<  12) | (m_end<<  4) | 
>> (s_end))
>>   #define AMD_MODEL_RANGE_FAMILY(range)   (((range)>>  24)&  0xff)
>>
>>
>>
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 17:34:19 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 17:34:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbbfT-0007l4-Ih; Fri, 16 Dec 2011 17:33:59 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RbbfR-0007kw-SX
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 17:33:58 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-14.tower-174.messagelabs.com!1324056830!5668094!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.5 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMDM3MTY=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMDM3MTY=\n,BODY_RANDOM_LONG
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22566 invoked from network); 16 Dec 2011 17:33:50 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-14.tower-174.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 16 Dec 2011 17:33:50 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1324056829; l=1688;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=z5FDXSJg/cO7oNtaspfuKErzocw=;
	b=s1qVgEg+h3kcQXfKutE3ojw+Rk0vzM0OChzF/DV9ZTYvdvk9hNaAHAOzdt/+0/PFQqa
	Jxr5slRGXj5eg4bkHb6puQ0Etl412EwcmpXv2IYmqPws4YZlrP/sWv0yuXpHcggdqPsRC
	epw9BKx09823rUHq1SxlOIBVjDmrXfUC05A=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFPjzEQG5of
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-112-083.pools.arcor-ip.net [88.65.112.83])
	by smtp.strato.de (fruni mo12) (RZmta 26.15 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id N0333anBGEgcgm ;
	Fri, 16 Dec 2011 18:33:24 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 4FB5918637; Fri, 16 Dec 2011 18:33:24 +0100 (CET)
Date: Fri, 16 Dec 2011 18:33:24 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20111216173323.GA26588@aepfle.de>
References: <mailman.4227.1323785898.12970.xen-devel@lists.xensource.com>
	<3d5947b7ee3b2fdda393744f59d55b76.squirrel@webmail.lagarcavilla.org>
	<20111216164033.GA25508@aepfle.de>
	<b9da75173754803d676d0f4c3c4c3a47.squirrel@webmail.lagarcavilla.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <b9da75173754803d676d0f4c3c4c3a47.squirrel@webmail.lagarcavilla.org>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: xen-devel@lists.xensource.com, tim@xen.org, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH] mem_event: use wait queue when ring is full
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Dec 16, Andres Lagar-Cavilla wrote:

> >> And both should use wait queues in extreme cases in which a guest
> >> vcpu with a single action generates multiple memory events. Given
> >> that when we hit a border condition the guest vcpu will place one
> >> event and be flagged VPF_mem_event_paused (or whatever that flag is
> >> named), if a guest vcpu generates another event when flagged,
> >> that's our queue for putting the vcpu on a wait queue.
> >
> > An extra flag is not needed.
> Can you elaborate? Which flag is not needed? And why?

The flag you mentioned in your earlier reply, VPF_mem_event_paused.
Since the vcpu is preempted, a new pause_flag will be no gain.

> > +    /*
> > +     * Configure ring accounting:
> > +     * Each guest vcpu should be able to place at least one request.
> > +     * If there are more vcpus than available slots in the ring, not all vcpus
> > +     * can place requests in the ring anyway.  A minimum (arbitrary) number of
> > +     * foreign requests will be allowed in this case.
> > +     */
> > +    if ( d->max_vcpus < RING_SIZE(&med->front_ring) )
> > +        med->max_foreign = RING_SIZE(&med->front_ring) - d->max_vcpus;
> > +    if ( med->max_foreign < 13 )
> > +        med->max_foreign = 13;
> Magic number! Why?

Yes, an arbitrary number of slots for foreign requests.
Which amount is correct? 1? 5? 10?
1 is probably closer to the goal of 'let each vcpu put at least one
request'.

> More generally, does this patch apply on top of a previous patch? What's
> the context here?

As I said, its on top of v6 of my patch. I will send out the full patch
later, but I wont be able to actually test the newer version this year.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 17:34:19 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 17:34:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbbfT-0007l4-Ih; Fri, 16 Dec 2011 17:33:59 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RbbfR-0007kw-SX
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 17:33:58 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-14.tower-174.messagelabs.com!1324056830!5668094!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.5 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMDM3MTY=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMDM3MTY=\n,BODY_RANDOM_LONG
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22566 invoked from network); 16 Dec 2011 17:33:50 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-14.tower-174.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 16 Dec 2011 17:33:50 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1324056829; l=1688;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=z5FDXSJg/cO7oNtaspfuKErzocw=;
	b=s1qVgEg+h3kcQXfKutE3ojw+Rk0vzM0OChzF/DV9ZTYvdvk9hNaAHAOzdt/+0/PFQqa
	Jxr5slRGXj5eg4bkHb6puQ0Etl412EwcmpXv2IYmqPws4YZlrP/sWv0yuXpHcggdqPsRC
	epw9BKx09823rUHq1SxlOIBVjDmrXfUC05A=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFPjzEQG5of
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-112-083.pools.arcor-ip.net [88.65.112.83])
	by smtp.strato.de (fruni mo12) (RZmta 26.15 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id N0333anBGEgcgm ;
	Fri, 16 Dec 2011 18:33:24 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 4FB5918637; Fri, 16 Dec 2011 18:33:24 +0100 (CET)
Date: Fri, 16 Dec 2011 18:33:24 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20111216173323.GA26588@aepfle.de>
References: <mailman.4227.1323785898.12970.xen-devel@lists.xensource.com>
	<3d5947b7ee3b2fdda393744f59d55b76.squirrel@webmail.lagarcavilla.org>
	<20111216164033.GA25508@aepfle.de>
	<b9da75173754803d676d0f4c3c4c3a47.squirrel@webmail.lagarcavilla.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <b9da75173754803d676d0f4c3c4c3a47.squirrel@webmail.lagarcavilla.org>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: xen-devel@lists.xensource.com, tim@xen.org, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH] mem_event: use wait queue when ring is full
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Dec 16, Andres Lagar-Cavilla wrote:

> >> And both should use wait queues in extreme cases in which a guest
> >> vcpu with a single action generates multiple memory events. Given
> >> that when we hit a border condition the guest vcpu will place one
> >> event and be flagged VPF_mem_event_paused (or whatever that flag is
> >> named), if a guest vcpu generates another event when flagged,
> >> that's our queue for putting the vcpu on a wait queue.
> >
> > An extra flag is not needed.
> Can you elaborate? Which flag is not needed? And why?

The flag you mentioned in your earlier reply, VPF_mem_event_paused.
Since the vcpu is preempted, a new pause_flag will be no gain.

> > +    /*
> > +     * Configure ring accounting:
> > +     * Each guest vcpu should be able to place at least one request.
> > +     * If there are more vcpus than available slots in the ring, not all vcpus
> > +     * can place requests in the ring anyway.  A minimum (arbitrary) number of
> > +     * foreign requests will be allowed in this case.
> > +     */
> > +    if ( d->max_vcpus < RING_SIZE(&med->front_ring) )
> > +        med->max_foreign = RING_SIZE(&med->front_ring) - d->max_vcpus;
> > +    if ( med->max_foreign < 13 )
> > +        med->max_foreign = 13;
> Magic number! Why?

Yes, an arbitrary number of slots for foreign requests.
Which amount is correct? 1? 5? 10?
1 is probably closer to the goal of 'let each vcpu put at least one
request'.

> More generally, does this patch apply on top of a previous patch? What's
> the context here?

As I said, its on top of v6 of my patch. I will send out the full patch
later, but I wont be able to actually test the newer version this year.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 17:39:23 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 17:39:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbbkQ-0007tH-AT; Fri, 16 Dec 2011 17:39:06 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1RbbkO-0007t9-BS
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 17:39:04 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1324057135!7752519!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjI0MzY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13406 invoked from network); 16 Dec 2011 17:38:56 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Dec 2011 17:38:56 -0000
X-IronPort-AV: E=Sophos;i="4.71,364,1320642000"; 
	d="cfg'?scan'208";a="174488527"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Dec 2011 12:38:55 -0500
Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX01.citrite.net
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Fri, 16 Dec 2011
	12:38:54 -0500
Message-ID: <4EEB822C.7010809@citrix.com>
Date: Fri, 16 Dec 2011 17:38:52 +0000
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20111110 Icedove/3.0.11
MIME-Version: 1.0
To: Catalin Marinas <catalin.marinas@arm.com>
References: <alpine.DEB.2.00.1111281009090.31179@kaball-desktop>
	<201111292129.20444.arnd@arndb.de>
	<alpine.DEB.2.00.1111301053300.31179@kaball-desktop>
	<CAHkRjk48jHO19H04rf8252+v04hk9qSdKBrfYCqJsZyamVhMEw@mail.gmail.com>
	<4EEB673D.3040608@citrix.com> <20111216165420.GE6342@arm.com>
In-Reply-To: <20111216165420.GE6342@arm.com>
Content-Type: multipart/mixed; boundary="------------090403070505020406040906"
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>, Arnd Bergmann <arnd@arndb.de>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [ANNOUNCE] Xen port to Cortex-A15 / ARMv7 with virt
 extensions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--------------090403070505020406040906
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit

On 16/12/11 16:54, Catalin Marinas wrote:
> On Fri, Dec 16, 2011 at 03:43:57PM +0000, David Vrabel wrote:
>> On 30/11/11 14:11, Catalin Marinas wrote:
>>> On 30 November 2011 11:39, Stefano Stabellini
>>> <stefano.stabellini@eu.citrix.com> wrote:
>>>> A git branch is available here (not ready for submission):
>>>>
>>>> git://xenbits.xen.org/people/sstabellini/linux-pvhvm.git arm
>>>>
>>>> the branch above is based on git://linux-arm.org/linux-2.6.git arm-lpae,
>>>> even though guests don't really need lpae support to run on Xen.
>>>
>>> Indeed, you don't really need LPAE. What you may need though is
>>> generic timers support for A15, it would allow less Hypervisor traps.
>>> For up-to-date architecture patches (well, development tree, not
>>> guaranteed to be stable), I would recommend this (they get into
>>> mainline at some point):
>>>
>>> http://git.kernel.org/?p=linux/kernel/git/cmarinas/linux-arm-arch.git;a=summary
>>>
>>> Either use master or just cherry-pick the branches that you are interested in.
>>
>> Which branches are required for the Versatile Express with the
>> Cortex-A15? I merged linux-arm-arch/arm-arch/vexpress in
> 
> That's the branch if you only need VE and A15 support
> 
>> but I get a
>> instruction fault immediately after branching to __mmap_switched.
>>
>> Is it not setting up the MMU correctly?
> 
> Do you run this on a software model? What config options do you use? You
> would need to enable VEXPRESS_EXTENDED_MEMORY_MAP and
> ARCH_VEXPRESS_CA15X4.

The envelope model, yes.  Both those options are enabled.  I've also
attached the complete config and the model configuration.

I took a closer look at the diffs between what Stefano had in his tree
(which included a bunch of LPAE support which I don't have enabled) and
the kernel boots the addition of some isb's when the MMU is switched on.

These were added by: "ARM: LPAE: add ISBs around MMU enabling code"
(commit 1c553c2 in your tree) which is think is only present in the LPAE
branch.  Is this patch not actually specific to LPAE?  Are there other
similar patches?

diff --git a/arch/arm/kernel/head.S b/arch/arm/kernel/head.S
index 566c54c..b4e84e2 100644
--- a/arch/arm/kernel/head.S
+++ b/arch/arm/kernel/head.S
@@ -400,8 +400,10 @@ ENDPROC(__enable_mmu)
        .align  5
 __turn_mmu_on:
        mov     r0, r0
+        isb
        mcr     p15, 0, r0, c1, c0, 0           @ write control reg
        mrc     p15, 0, r3, c0, c0, 0           @ read id reg
+        isb
        mov     r3, r3
        mov     r3, r13
        mov     pc, r3

David

--------------090403070505020406040906
Content-Type: text/plain; name=".config"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename=".config"

#
# Automatically generated file; DO NOT EDIT.
# Linux/arm 3.2.0-rc1 Kernel Configuration
#
CONFIG_ARM=y
CONFIG_SYS_SUPPORTS_APM_EMULATION=y
CONFIG_HAVE_SCHED_CLOCK=y
# CONFIG_ARCH_USES_GETTIMEOFFSET is not set
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_KTIME_SCALAR=y
CONFIG_HAVE_PROC_CPU=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_HAVE_LATENCYTOP_SUPPORT=y
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_TRACE_IRQFLAGS_SUPPORT=y
CONFIG_HARDIRQS_SW_RESEND=y
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_RWSEM_GENERIC_SPINLOCK=y
CONFIG_ARCH_HAS_CPU_IDLE_WAIT=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_VECTORS_BASE=0xffff0000
CONFIG_ARM_PATCH_PHYS_VIRT=y
CONFIG_NEED_MACH_MEMORY_H=y
CONFIG_GENERIC_BUG=y
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_HAVE_IRQ_WORK=y

#
# General setup
#
CONFIG_EXPERIMENTAL=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
CONFIG_LOCALVERSION=""
# CONFIG_LOCALVERSION_AUTO is not set
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_KERNEL_GZIP=y
# CONFIG_KERNEL_LZMA is not set
# CONFIG_KERNEL_LZO is not set
CONFIG_DEFAULT_HOSTNAME="(none)"
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
# CONFIG_POSIX_MQUEUE is not set
# CONFIG_BSD_PROCESS_ACCT is not set
# CONFIG_FHANDLE is not set
# CONFIG_TASKSTATS is not set
# CONFIG_AUDIT is not set
CONFIG_HAVE_GENERIC_HARDIRQS=y

#
# IRQ subsystem
#
CONFIG_GENERIC_HARDIRQS=y
CONFIG_HAVE_SPARSE_IRQ=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_IRQ_DOMAIN=y
CONFIG_SPARSE_IRQ=y

#
# RCU Subsystem
#
CONFIG_TINY_RCU=y
# CONFIG_PREEMPT_RCU is not set
# CONFIG_RCU_TRACE is not set
# CONFIG_TREE_RCU_TRACE is not set
# CONFIG_IKCONFIG is not set
CONFIG_LOG_BUF_SHIFT=14
# CONFIG_CGROUPS is not set
CONFIG_NAMESPACES=y
CONFIG_UTS_NS=y
CONFIG_IPC_NS=y
CONFIG_USER_NS=y
CONFIG_PID_NS=y
CONFIG_NET_NS=y
# CONFIG_SCHED_AUTOGROUP is not set
# CONFIG_SYSFS_DEPRECATED is not set
# CONFIG_RELAY is not set
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=""
CONFIG_RD_GZIP=y
CONFIG_RD_BZIP2=y
CONFIG_RD_LZMA=y
CONFIG_RD_XZ=y
CONFIG_RD_LZO=y
CONFIG_CC_OPTIMIZE_FOR_SIZE=y
CONFIG_SYSCTL=y
CONFIG_ANON_INODES=y
# CONFIG_EXPERT is not set
CONFIG_UID16=y
# CONFIG_SYSCTL_SYSCALL is not set
CONFIG_KALLSYMS=y
# CONFIG_KALLSYMS_ALL is not set
CONFIG_HOTPLUG=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_SIGNALFD=y
CONFIG_TIMERFD=y
CONFIG_EVENTFD=y
CONFIG_SHMEM=y
CONFIG_AIO=y
# CONFIG_EMBEDDED is not set
CONFIG_HAVE_PERF_EVENTS=y
CONFIG_PERF_USE_VMALLOC=y

#
# Kernel Performance Events And Counters
#
# CONFIG_PERF_EVENTS is not set
# CONFIG_PERF_COUNTERS is not set
CONFIG_VM_EVENT_COUNTERS=y
CONFIG_COMPAT_BRK=y
CONFIG_SLAB=y
# CONFIG_SLUB is not set
# CONFIG_PROFILING is not set
CONFIG_HAVE_OPROFILE=y
CONFIG_HAVE_KPROBES=y
CONFIG_HAVE_KRETPROBES=y
CONFIG_HAVE_REGS_AND_STACK_ACCESS_API=y
CONFIG_HAVE_CLK=y
CONFIG_HAVE_DMA_API_DEBUG=y

#
# GCOV-based kernel profiling
#
# CONFIG_GCOV_KERNEL is not set
CONFIG_HAVE_GENERIC_DMA_COHERENT=y
CONFIG_SLABINFO=y
CONFIG_RT_MUTEXES=y
CONFIG_BASE_SMALL=0
# CONFIG_MODULES is not set
CONFIG_BLOCK=y
CONFIG_LBDAF=y
CONFIG_BLK_DEV_BSG=y
# CONFIG_BLK_DEV_BSGLIB is not set
# CONFIG_BLK_DEV_INTEGRITY is not set

#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_DEADLINE=y
CONFIG_IOSCHED_CFQ=y
# CONFIG_DEFAULT_DEADLINE is not set
CONFIG_DEFAULT_CFQ=y
# CONFIG_DEFAULT_NOOP is not set
CONFIG_DEFAULT_IOSCHED="cfq"
# CONFIG_INLINE_SPIN_TRYLOCK is not set
# CONFIG_INLINE_SPIN_TRYLOCK_BH is not set
# CONFIG_INLINE_SPIN_LOCK is not set
# CONFIG_INLINE_SPIN_LOCK_BH is not set
# CONFIG_INLINE_SPIN_LOCK_IRQ is not set
# CONFIG_INLINE_SPIN_LOCK_IRQSAVE is not set
CONFIG_INLINE_SPIN_UNLOCK=y
# CONFIG_INLINE_SPIN_UNLOCK_BH is not set
CONFIG_INLINE_SPIN_UNLOCK_IRQ=y
# CONFIG_INLINE_SPIN_UNLOCK_IRQRESTORE is not set
# CONFIG_INLINE_READ_TRYLOCK is not set
# CONFIG_INLINE_READ_LOCK is not set
# CONFIG_INLINE_READ_LOCK_BH is not set
# CONFIG_INLINE_READ_LOCK_IRQ is not set
# CONFIG_INLINE_READ_LOCK_IRQSAVE is not set
CONFIG_INLINE_READ_UNLOCK=y
# CONFIG_INLINE_READ_UNLOCK_BH is not set
CONFIG_INLINE_READ_UNLOCK_IRQ=y
# CONFIG_INLINE_READ_UNLOCK_IRQRESTORE is not set
# CONFIG_INLINE_WRITE_TRYLOCK is not set
# CONFIG_INLINE_WRITE_LOCK is not set
# CONFIG_INLINE_WRITE_LOCK_BH is not set
# CONFIG_INLINE_WRITE_LOCK_IRQ is not set
# CONFIG_INLINE_WRITE_LOCK_IRQSAVE is not set
CONFIG_INLINE_WRITE_UNLOCK=y
# CONFIG_INLINE_WRITE_UNLOCK_BH is not set
CONFIG_INLINE_WRITE_UNLOCK_IRQ=y
# CONFIG_INLINE_WRITE_UNLOCK_IRQRESTORE is not set
# CONFIG_MUTEX_SPIN_ON_OWNER is not set
CONFIG_FREEZER=y

#
# System Type
#
CONFIG_MMU=y
# CONFIG_ARCH_INTEGRATOR is not set
# CONFIG_ARCH_REALVIEW is not set
# CONFIG_ARCH_VERSATILE is not set
CONFIG_ARCH_VEXPRESS=y
# CONFIG_ARCH_AT91 is not set
# CONFIG_ARCH_BCMRING is not set
# CONFIG_ARCH_HIGHBANK is not set
# CONFIG_ARCH_CLPS711X is not set
# CONFIG_ARCH_CNS3XXX is not set
# CONFIG_ARCH_GEMINI is not set
# CONFIG_ARCH_PRIMA2 is not set
# CONFIG_ARCH_EBSA110 is not set
# CONFIG_ARCH_EP93XX is not set
# CONFIG_ARCH_FOOTBRIDGE is not set
# CONFIG_ARCH_MXC is not set
# CONFIG_ARCH_MXS is not set
# CONFIG_ARCH_NETX is not set
# CONFIG_ARCH_H720X is not set
# CONFIG_ARCH_IOP13XX is not set
# CONFIG_ARCH_IOP32X is not set
# CONFIG_ARCH_IOP33X is not set
# CONFIG_ARCH_IXP23XX is not set
# CONFIG_ARCH_IXP2000 is not set
# CONFIG_ARCH_IXP4XX is not set
# CONFIG_ARCH_DOVE is not set
# CONFIG_ARCH_KIRKWOOD is not set
# CONFIG_ARCH_LPC32XX is not set
# CONFIG_ARCH_MV78XX0 is not set
# CONFIG_ARCH_ORION5X is not set
# CONFIG_ARCH_MMP is not set
# CONFIG_ARCH_KS8695 is not set
# CONFIG_ARCH_W90X900 is not set
# CONFIG_ARCH_TEGRA is not set
# CONFIG_ARCH_PICOXCELL is not set
# CONFIG_ARCH_PNX4008 is not set
# CONFIG_ARCH_PXA is not set
# CONFIG_ARCH_MSM is not set
# CONFIG_ARCH_SHMOBILE is not set
# CONFIG_ARCH_RPC is not set
# CONFIG_ARCH_SA1100 is not set
# CONFIG_ARCH_S3C2410 is not set
# CONFIG_ARCH_S3C64XX is not set
# CONFIG_ARCH_S5P64X0 is not set
# CONFIG_ARCH_S5PC100 is not set
# CONFIG_ARCH_S5PV210 is not set
# CONFIG_ARCH_EXYNOS is not set
# CONFIG_ARCH_SHARK is not set
# CONFIG_ARCH_TCC_926 is not set
# CONFIG_ARCH_U300 is not set
# CONFIG_ARCH_U8500 is not set
# CONFIG_ARCH_NOMADIK is not set
# CONFIG_ARCH_DAVINCI is not set
# CONFIG_ARCH_OMAP is not set
# CONFIG_PLAT_SPEAR is not set
# CONFIG_ARCH_VT8500 is not set
# CONFIG_ARCH_ZYNQ is not set

#
# System MMU
#

#
# Versatile Express platform type
#
# CONFIG_VEXPRESS_ORIGINAL_MEMORY_MAP is not set
CONFIG_VEXPRESS_EXTENDED_MEMORY_MAP=y
CONFIG_ARCH_VEXPRESS_CA15X4=y
# CONFIG_ARCH_VEXPRESS_CA5S is not set
CONFIG_PLAT_VERSATILE_CLCD=y
CONFIG_PLAT_VERSATILE_SCHED_CLOCK=y
CONFIG_PLAT_VERSATILE=y
CONFIG_ARM_TIMER_SP804=y

#
# Processor Type
#
CONFIG_CPU_V7=y
CONFIG_CPU_32v6K=y
CONFIG_CPU_32v7=y
CONFIG_CPU_ABRT_EV7=y
CONFIG_CPU_PABRT_V7=y
CONFIG_CPU_CACHE_V7=y
CONFIG_CPU_CACHE_VIPT=y
CONFIG_CPU_COPY_V6=y
CONFIG_CPU_TLB_V7=y
CONFIG_CPU_HAS_ASID=y
CONFIG_CPU_CP15=y
CONFIG_CPU_CP15_MMU=y

#
# Processor Features
#
CONFIG_ARM_THUMB=y
# CONFIG_ARM_THUMBEE is not set
# CONFIG_SWP_EMULATE is not set
# CONFIG_CPU_ICACHE_DISABLE is not set
# CONFIG_CPU_DCACHE_DISABLE is not set
# CONFIG_CPU_BPREDICT_DISABLE is not set
CONFIG_ARM_L1_CACHE_SHIFT=5
CONFIG_ARM_DMA_MEM_BUFFERABLE=y
CONFIG_CPU_HAS_PMU=y
CONFIG_MULTI_IRQ_HANDLER=y
# CONFIG_ARM_ERRATA_430973 is not set
# CONFIG_ARM_ERRATA_458693 is not set
# CONFIG_ARM_ERRATA_460075 is not set
# CONFIG_ARM_ERRATA_743622 is not set
# CONFIG_ARM_ERRATA_754322 is not set
CONFIG_ARM_GIC=y
CONFIG_ICST=y

#
# Bus support
#
CONFIG_ARM_AMBA=y
# CONFIG_PCI_SYSCALL is not set
# CONFIG_ARCH_SUPPORTS_MSI is not set
# CONFIG_PCI_PRI is not set
# CONFIG_PCCARD is not set

#
# Kernel Features
#
CONFIG_TICK_ONESHOT=y
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y
CONFIG_GENERIC_CLOCKEVENTS_BUILD=y
# CONFIG_SMP is not set
CONFIG_ARM_ARCH_TIMER=y
CONFIG_VMSPLIT_3G=y
# CONFIG_VMSPLIT_2G is not set
# CONFIG_VMSPLIT_1G is not set
CONFIG_PAGE_OFFSET=0xC0000000
CONFIG_PREEMPT_NONE=y
# CONFIG_PREEMPT_VOLUNTARY is not set
# CONFIG_PREEMPT is not set
CONFIG_HZ=100
# CONFIG_THUMB2_KERNEL is not set
CONFIG_AEABI=y
CONFIG_OABI_COMPAT=y
# CONFIG_ARCH_SPARSEMEM_DEFAULT is not set
# CONFIG_ARCH_SELECT_MEMORY_MODEL is not set
CONFIG_HAVE_ARCH_PFN_VALID=y
CONFIG_HIGHMEM=y
CONFIG_HIGHPTE=y
CONFIG_SELECT_MEMORY_MODEL=y
CONFIG_FLATMEM_MANUAL=y
CONFIG_FLATMEM=y
CONFIG_FLAT_NODE_MEM_MAP=y
CONFIG_HAVE_MEMBLOCK=y
CONFIG_PAGEFLAGS_EXTENDED=y
CONFIG_SPLIT_PTLOCK_CPUS=4
# CONFIG_COMPACTION is not set
# CONFIG_PHYS_ADDR_T_64BIT is not set
CONFIG_ZONE_DMA_FLAG=0
CONFIG_BOUNCE=y
CONFIG_VIRT_TO_BUS=y
# CONFIG_KSM is not set
CONFIG_DEFAULT_MMAP_MIN_ADDR=4096
CONFIG_NEED_PER_CPU_KM=y
# CONFIG_CLEANCACHE is not set
CONFIG_FORCE_MAX_ZONEORDER=11
CONFIG_ALIGNMENT_TRAP=y
# CONFIG_UACCESS_WITH_MEMCPY is not set
# CONFIG_SECCOMP is not set
# CONFIG_CC_STACKPROTECTOR is not set
# CONFIG_DEPRECATED_PARAM_STRUCT is not set

#
# Boot options
#
# CONFIG_USE_OF is not set
CONFIG_ZBOOT_ROM_TEXT=0x0
CONFIG_ZBOOT_ROM_BSS=0x0
CONFIG_CMDLINE="console=hvc0 earlyprintk=xen"
CONFIG_CMDLINE_FROM_BOOTLOADER=y
# CONFIG_CMDLINE_EXTEND is not set
# CONFIG_CMDLINE_FORCE is not set
# CONFIG_XIP_KERNEL is not set
# CONFIG_KEXEC is not set
# CONFIG_CRASH_DUMP is not set
# CONFIG_AUTO_ZRELADDR is not set

#
# CPU Power Management
#
# CONFIG_CPU_IDLE is not set

#
# Floating point emulation
#

#
# At least one emulation must be selected
#
# CONFIG_FPE_NWFPE is not set
# CONFIG_FPE_FASTFPE is not set
# CONFIG_VFP is not set

#
# Userspace binary formats
#
CONFIG_BINFMT_ELF=y
CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS=y
CONFIG_HAVE_AOUT=y
# CONFIG_BINFMT_AOUT is not set
# CONFIG_BINFMT_MISC is not set

#
# Power management options
#
CONFIG_SUSPEND=y
CONFIG_SUSPEND_FREEZER=y
CONFIG_PM_SLEEP=y
# CONFIG_PM_RUNTIME is not set
CONFIG_PM=y
# CONFIG_PM_DEBUG is not set
# CONFIG_APM_EMULATION is not set
CONFIG_PM_CLK=y
CONFIG_CPU_PM=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARM_CPU_SUSPEND=y
CONFIG_NET=y

#
# Networking options
#
CONFIG_PACKET=y
CONFIG_UNIX=y
CONFIG_XFRM=y
# CONFIG_XFRM_USER is not set
# CONFIG_XFRM_SUB_POLICY is not set
# CONFIG_XFRM_MIGRATE is not set
# CONFIG_XFRM_STATISTICS is not set
# CONFIG_NET_KEY is not set
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
# CONFIG_IP_ADVANCED_ROUTER is not set
CONFIG_IP_PNP=y
# CONFIG_IP_PNP_DHCP is not set
CONFIG_IP_PNP_BOOTP=y
# CONFIG_IP_PNP_RARP is not set
# CONFIG_NET_IPIP is not set
# CONFIG_NET_IPGRE_DEMUX is not set
# CONFIG_IP_MROUTE is not set
# CONFIG_ARPD is not set
# CONFIG_SYN_COOKIES is not set
# CONFIG_INET_AH is not set
# CONFIG_INET_ESP is not set
# CONFIG_INET_IPCOMP is not set
# CONFIG_INET_XFRM_TUNNEL is not set
# CONFIG_INET_TUNNEL is not set
CONFIG_INET_XFRM_MODE_TRANSPORT=y
CONFIG_INET_XFRM_MODE_TUNNEL=y
CONFIG_INET_XFRM_MODE_BEET=y
CONFIG_INET_LRO=y
# CONFIG_INET_DIAG is not set
# CONFIG_TCP_CONG_ADVANCED is not set
CONFIG_TCP_CONG_CUBIC=y
CONFIG_DEFAULT_TCP_CONG="cubic"
# CONFIG_TCP_MD5SIG is not set
# CONFIG_IPV6 is not set
# CONFIG_NETWORK_SECMARK is not set
# CONFIG_NETWORK_PHY_TIMESTAMPING is not set
# CONFIG_NETFILTER is not set
# CONFIG_IP_DCCP is not set
# CONFIG_IP_SCTP is not set
# CONFIG_RDS is not set
# CONFIG_TIPC is not set
# CONFIG_ATM is not set
# CONFIG_L2TP is not set
# CONFIG_BRIDGE is not set
# CONFIG_NET_DSA is not set
# CONFIG_VLAN_8021Q is not set
# CONFIG_DECNET is not set
# CONFIG_LLC2 is not set
# CONFIG_IPX is not set
# CONFIG_ATALK is not set
# CONFIG_X25 is not set
# CONFIG_LAPB is not set
# CONFIG_ECONET is not set
# CONFIG_WAN_ROUTER is not set
# CONFIG_PHONET is not set
# CONFIG_IEEE802154 is not set
# CONFIG_NET_SCHED is not set
# CONFIG_DCB is not set
# CONFIG_BATMAN_ADV is not set

#
# Network testing
#
# CONFIG_NET_PKTGEN is not set
# CONFIG_HAMRADIO is not set
# CONFIG_CAN is not set
# CONFIG_IRDA is not set
# CONFIG_BT is not set
# CONFIG_AF_RXRPC is not set
CONFIG_WIRELESS=y
# CONFIG_CFG80211 is not set
# CONFIG_LIB80211 is not set

#
# CFG80211 needs to be enabled for MAC80211
#
# CONFIG_WIMAX is not set
# CONFIG_RFKILL is not set
# CONFIG_NET_9P is not set
# CONFIG_CAIF is not set
# CONFIG_CEPH_LIB is not set
# CONFIG_NFC is not set

#
# Device Drivers
#

#
# Generic Driver Options
#
CONFIG_UEVENT_HELPER_PATH=""
# CONFIG_DEVTMPFS is not set
CONFIG_STANDALONE=y
CONFIG_PREVENT_FIRMWARE_BUILD=y
CONFIG_FW_LOADER=y
CONFIG_FIRMWARE_IN_KERNEL=y
CONFIG_EXTRA_FIRMWARE=""
# CONFIG_DEBUG_DRIVER is not set
# CONFIG_DEBUG_DEVRES is not set
# CONFIG_SYS_HYPERVISOR is not set
# CONFIG_CONNECTOR is not set
CONFIG_MTD=y
# CONFIG_MTD_REDBOOT_PARTS is not set
CONFIG_MTD_CMDLINE_PARTS=y
# CONFIG_MTD_AFS_PARTS is not set
# CONFIG_MTD_AR7_PARTS is not set

#
# User Modules And Translation Layers
#
CONFIG_MTD_CHAR=y
CONFIG_MTD_BLKDEVS=y
CONFIG_MTD_BLOCK=y
# CONFIG_FTL is not set
# CONFIG_NFTL is not set
# CONFIG_INFTL is not set
# CONFIG_RFD_FTL is not set
# CONFIG_SSFDC is not set
# CONFIG_SM_FTL is not set
# CONFIG_MTD_OOPS is not set
# CONFIG_MTD_SWAP is not set

#
# RAM/ROM/Flash chip drivers
#
CONFIG_MTD_CFI=y
# CONFIG_MTD_JEDECPROBE is not set
CONFIG_MTD_GEN_PROBE=y
CONFIG_MTD_CFI_ADV_OPTIONS=y
CONFIG_MTD_CFI_NOSWAP=y
# CONFIG_MTD_CFI_BE_BYTE_SWAP is not set
# CONFIG_MTD_CFI_LE_BYTE_SWAP is not set
# CONFIG_MTD_CFI_GEOMETRY is not set
CONFIG_MTD_MAP_BANK_WIDTH_1=y
CONFIG_MTD_MAP_BANK_WIDTH_2=y
CONFIG_MTD_MAP_BANK_WIDTH_4=y
# CONFIG_MTD_MAP_BANK_WIDTH_8 is not set
# CONFIG_MTD_MAP_BANK_WIDTH_16 is not set
# CONFIG_MTD_MAP_BANK_WIDTH_32 is not set
CONFIG_MTD_CFI_I1=y
CONFIG_MTD_CFI_I2=y
# CONFIG_MTD_CFI_I4 is not set
# CONFIG_MTD_CFI_I8 is not set
# CONFIG_MTD_OTP is not set
CONFIG_MTD_CFI_INTELEXT=y
# CONFIG_MTD_CFI_AMDSTD is not set
# CONFIG_MTD_CFI_STAA is not set
CONFIG_MTD_CFI_UTIL=y
# CONFIG_MTD_RAM is not set
# CONFIG_MTD_ROM is not set
# CONFIG_MTD_ABSENT is not set

#
# Mapping drivers for chip access
#
# CONFIG_MTD_COMPLEX_MAPPINGS is not set
# CONFIG_MTD_PHYSMAP is not set
# CONFIG_MTD_PLATRAM is not set

#
# Self-contained MTD device drivers
#
# CONFIG_MTD_SLRAM is not set
# CONFIG_MTD_PHRAM is not set
# CONFIG_MTD_MTDRAM is not set
# CONFIG_MTD_BLOCK2MTD is not set

#
# Disk-On-Chip Device Drivers
#
# CONFIG_MTD_DOC2000 is not set
# CONFIG_MTD_DOC2001 is not set
# CONFIG_MTD_DOC2001PLUS is not set
# CONFIG_MTD_DOCG3 is not set
# CONFIG_MTD_NAND is not set
# CONFIG_MTD_ONENAND is not set

#
# LPDDR flash memory drivers
#
# CONFIG_MTD_LPDDR is not set
# CONFIG_MTD_UBI is not set
# CONFIG_PARPORT is not set
CONFIG_BLK_DEV=y
# CONFIG_BLK_DEV_COW_COMMON is not set
# CONFIG_BLK_DEV_LOOP is not set

#
# DRBD disabled because PROC_FS, INET or CONNECTOR not selected
#
# CONFIG_BLK_DEV_NBD is not set
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_COUNT=16
CONFIG_BLK_DEV_RAM_SIZE=4096
# CONFIG_BLK_DEV_XIP is not set
# CONFIG_CDROM_PKTCDVD is not set
# CONFIG_ATA_OVER_ETH is not set
# CONFIG_BLK_DEV_RBD is not set
# CONFIG_SENSORS_LIS3LV02D is not set
# CONFIG_MISC_DEVICES is not set

#
# SCSI device support
#
CONFIG_SCSI_MOD=y
# CONFIG_RAID_ATTRS is not set
CONFIG_SCSI=y
CONFIG_SCSI_DMA=y
# CONFIG_SCSI_TGT is not set
# CONFIG_SCSI_NETLINK is not set
CONFIG_SCSI_PROC_FS=y

#
# SCSI support type (disk, tape, CD-ROM)
#
CONFIG_BLK_DEV_SD=y
# CONFIG_CHR_DEV_ST is not set
# CONFIG_CHR_DEV_OSST is not set
# CONFIG_BLK_DEV_SR is not set
# CONFIG_CHR_DEV_SG is not set
# CONFIG_CHR_DEV_SCH is not set
# CONFIG_SCSI_MULTI_LUN is not set
# CONFIG_SCSI_CONSTANTS is not set
# CONFIG_SCSI_LOGGING is not set
# CONFIG_SCSI_SCAN_ASYNC is not set

#
# SCSI Transports
#
# CONFIG_SCSI_SPI_ATTRS is not set
# CONFIG_SCSI_FC_ATTRS is not set
# CONFIG_SCSI_ISCSI_ATTRS is not set
# CONFIG_SCSI_SAS_ATTRS is not set
# CONFIG_SCSI_SAS_LIBSAS is not set
# CONFIG_SCSI_SRP_ATTRS is not set
CONFIG_SCSI_LOWLEVEL=y
# CONFIG_ISCSI_TCP is not set
# CONFIG_ISCSI_BOOT_SYSFS is not set
# CONFIG_LIBFC is not set
# CONFIG_LIBFCOE is not set
# CONFIG_SCSI_DEBUG is not set
# CONFIG_SCSI_DH is not set
# CONFIG_SCSI_OSD_INITIATOR is not set
CONFIG_HAVE_PATA_PLATFORM=y
CONFIG_ATA=y
# CONFIG_ATA_NONSTANDARD is not set
CONFIG_ATA_VERBOSE_ERROR=y
CONFIG_SATA_PMP=y

#
# Controllers with non-SFF native interface
#
# CONFIG_SATA_AHCI_PLATFORM is not set
CONFIG_ATA_SFF=y

#
# SFF controllers with custom DMA interface
#
# CONFIG_ATA_BMDMA is not set

#
# PIO-only SFF controllers
#
# CONFIG_PATA_PLATFORM is not set

#
# Generic fallback / legacy drivers
#
# CONFIG_MD is not set
# CONFIG_TARGET_CORE is not set
CONFIG_NETDEVICES=y
CONFIG_NET_CORE=y
# CONFIG_BONDING is not set
# CONFIG_DUMMY is not set
# CONFIG_EQUALIZER is not set
CONFIG_MII=y
# CONFIG_MACVLAN is not set
# CONFIG_NETCONSOLE is not set
# CONFIG_NETPOLL is not set
# CONFIG_NET_POLL_CONTROLLER is not set
# CONFIG_TUN is not set
# CONFIG_VETH is not set

#
# CAIF transport drivers
#
# CONFIG_ETHERNET is not set
# CONFIG_PHYLIB is not set
# CONFIG_PPP is not set
# CONFIG_SLIP is not set
CONFIG_WLAN=y
# CONFIG_HOSTAP is not set

#
# Enable WiMAX (Networking options) to see the WiMAX drivers
#
# CONFIG_WAN is not set
# CONFIG_ISDN is not set
# CONFIG_PHONE is not set

#
# Input device support
#
CONFIG_INPUT=y
# CONFIG_INPUT_FF_MEMLESS is not set
# CONFIG_INPUT_POLLDEV is not set
# CONFIG_INPUT_SPARSEKMAP is not set

#
# Userland interfaces
#
CONFIG_INPUT_MOUSEDEV=y
CONFIG_INPUT_MOUSEDEV_PSAUX=y
CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024
CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768
# CONFIG_INPUT_JOYDEV is not set
CONFIG_INPUT_EVDEV=y
# CONFIG_INPUT_EVBUG is not set

#
# Input Device Drivers
#
CONFIG_INPUT_KEYBOARD=y
# CONFIG_KEYBOARD_ADP5588 is not set
# CONFIG_KEYBOARD_ADP5589 is not set
CONFIG_KEYBOARD_ATKBD=y
# CONFIG_KEYBOARD_QT1070 is not set
# CONFIG_KEYBOARD_QT2160 is not set
# CONFIG_KEYBOARD_LKKBD is not set
# CONFIG_KEYBOARD_TCA6416 is not set
# CONFIG_KEYBOARD_MAX7359 is not set
# CONFIG_KEYBOARD_MCS is not set
# CONFIG_KEYBOARD_MPR121 is not set
# CONFIG_KEYBOARD_NEWTON is not set
# CONFIG_KEYBOARD_OPENCORES is not set
# CONFIG_KEYBOARD_STOWAWAY is not set
# CONFIG_KEYBOARD_SUNKBD is not set
# CONFIG_KEYBOARD_XTKBD is not set
CONFIG_INPUT_MOUSE=y
CONFIG_MOUSE_PS2=y
CONFIG_MOUSE_PS2_ALPS=y
CONFIG_MOUSE_PS2_LOGIPS2PP=y
CONFIG_MOUSE_PS2_SYNAPTICS=y
CONFIG_MOUSE_PS2_TRACKPOINT=y
# CONFIG_MOUSE_PS2_ELANTECH is not set
# CONFIG_MOUSE_PS2_SENTELIC is not set
# CONFIG_MOUSE_PS2_TOUCHKIT is not set
# CONFIG_MOUSE_SERIAL is not set
# CONFIG_MOUSE_APPLETOUCH is not set
# CONFIG_MOUSE_BCM5974 is not set
# CONFIG_MOUSE_VSXXXAA is not set
# CONFIG_MOUSE_SYNAPTICS_I2C is not set
# CONFIG_INPUT_JOYSTICK is not set
# CONFIG_INPUT_TABLET is not set
# CONFIG_INPUT_TOUCHSCREEN is not set
# CONFIG_INPUT_MISC is not set

#
# Hardware I/O ports
#
CONFIG_SERIO=y
# CONFIG_SERIO_SERPORT is not set
CONFIG_SERIO_AMBAKMI=y
CONFIG_SERIO_LIBPS2=y
# CONFIG_SERIO_RAW is not set
# CONFIG_SERIO_ALTERA_PS2 is not set
# CONFIG_SERIO_PS2MULT is not set
# CONFIG_GAMEPORT is not set

#
# Character devices
#
CONFIG_VT=y
CONFIG_CONSOLE_TRANSLATIONS=y
CONFIG_VT_CONSOLE=y
CONFIG_VT_CONSOLE_SLEEP=y
CONFIG_HW_CONSOLE=y
# CONFIG_VT_HW_CONSOLE_BINDING is not set
CONFIG_UNIX98_PTYS=y
# CONFIG_DEVPTS_MULTIPLE_INSTANCES is not set
CONFIG_LEGACY_PTYS=y
CONFIG_LEGACY_PTY_COUNT=16
# CONFIG_SERIAL_NONSTANDARD is not set
# CONFIG_N_GSM is not set
# CONFIG_TRACE_SINK is not set
CONFIG_DEVKMEM=y

#
# Serial drivers
#
CONFIG_SERIAL_8250=y
# CONFIG_SERIAL_8250_CONSOLE is not set
CONFIG_SERIAL_8250_NR_UARTS=4
CONFIG_SERIAL_8250_RUNTIME_UARTS=4
CONFIG_SERIAL_8250_EXTENDED=y
CONFIG_SERIAL_8250_MANY_PORTS=y
CONFIG_SERIAL_8250_SHARE_IRQ=y
# CONFIG_SERIAL_8250_DETECT_IRQ is not set
CONFIG_SERIAL_8250_RSA=y

#
# Non-8250 serial port support
#
# CONFIG_SERIAL_AMBA_PL010 is not set
CONFIG_SERIAL_AMBA_PL011=y
CONFIG_SERIAL_AMBA_PL011_CONSOLE=y
CONFIG_SERIAL_CORE=y
CONFIG_SERIAL_CORE_CONSOLE=y
# CONFIG_SERIAL_TIMBERDALE is not set
# CONFIG_SERIAL_ALTERA_JTAGUART is not set
# CONFIG_SERIAL_ALTERA_UART is not set
# CONFIG_SERIAL_XILINX_PS_UART is not set
# CONFIG_HVC_DCC is not set
# CONFIG_IPMI_HANDLER is not set
CONFIG_HW_RANDOM=y
# CONFIG_HW_RANDOM_TIMERIOMEM is not set
# CONFIG_R3964 is not set
# CONFIG_RAW_DRIVER is not set
# CONFIG_TCG_TPM is not set
# CONFIG_RAMOOPS is not set
CONFIG_I2C=y
CONFIG_I2C_BOARDINFO=y
CONFIG_I2C_COMPAT=y
CONFIG_I2C_CHARDEV=y
# CONFIG_I2C_MUX is not set
CONFIG_I2C_HELPER_AUTO=y

#
# I2C Hardware Bus support
#

#
# I2C system bus drivers (mostly embedded / system-on-chip)
#
# CONFIG_I2C_DESIGNWARE_PLATFORM is not set
# CONFIG_I2C_OCORES is not set
# CONFIG_I2C_PCA_PLATFORM is not set
# CONFIG_I2C_PXA_PCI is not set
# CONFIG_I2C_SIMTEC is not set
# CONFIG_I2C_VERSATILE is not set
# CONFIG_I2C_XILINX is not set

#
# External I2C/SMBus adapter drivers
#
# CONFIG_I2C_PARPORT_LIGHT is not set
# CONFIG_I2C_TAOS_EVM is not set

#
# Other I2C/SMBus bus drivers
#
# CONFIG_I2C_DEBUG_CORE is not set
# CONFIG_I2C_DEBUG_ALGO is not set
# CONFIG_I2C_DEBUG_BUS is not set
# CONFIG_SPI is not set

#
# PPS support
#
# CONFIG_PPS is not set

#
# PPS generators support
#

#
# PTP clock support
#

#
# Enable Device Drivers -> PPS to see the PTP clock options.
#
# CONFIG_PINCTRL is not set
CONFIG_ARCH_WANT_OPTIONAL_GPIOLIB=y
# CONFIG_GPIOLIB is not set
# CONFIG_W1 is not set
# CONFIG_POWER_SUPPLY is not set
# CONFIG_HWMON is not set
# CONFIG_THERMAL is not set
# CONFIG_WATCHDOG is not set
CONFIG_SSB_POSSIBLE=y

#
# Sonics Silicon Backplane
#
# CONFIG_SSB is not set
CONFIG_BCMA_POSSIBLE=y

#
# Broadcom specific AMBA
#
# CONFIG_BCMA is not set

#
# Multifunction device drivers
#
# CONFIG_MFD_CORE is not set
# CONFIG_MFD_88PM860X is not set
# CONFIG_MFD_SM501 is not set
# CONFIG_HTC_PASIC3 is not set
# CONFIG_TPS6105X is not set
# CONFIG_TPS6507X is not set
# CONFIG_TWL4030_CORE is not set
# CONFIG_MFD_STMPE is not set
# CONFIG_MFD_TC3589X is not set
# CONFIG_MFD_TMIO is not set
# CONFIG_MFD_T7L66XB is not set
# CONFIG_MFD_TC6387XB is not set
# CONFIG_PMIC_DA903X is not set
# CONFIG_PMIC_ADP5520 is not set
# CONFIG_MFD_MAX8925 is not set
# CONFIG_MFD_MAX8997 is not set
# CONFIG_MFD_MAX8998 is not set
# CONFIG_MFD_WM8400 is not set
# CONFIG_MFD_WM831X_I2C is not set
# CONFIG_MFD_WM8350_I2C is not set
# CONFIG_MFD_WM8994 is not set
# CONFIG_MFD_PCF50633 is not set
# CONFIG_ABX500_CORE is not set
# CONFIG_MFD_WL1273_CORE is not set
# CONFIG_REGULATOR is not set
# CONFIG_MEDIA_SUPPORT is not set

#
# Graphics support
#
# CONFIG_DRM is not set
# CONFIG_VGASTATE is not set
# CONFIG_VIDEO_OUTPUT_CONTROL is not set
CONFIG_FB=y
# CONFIG_FIRMWARE_EDID is not set
# CONFIG_FB_DDC is not set
# CONFIG_FB_BOOT_VESA_SUPPORT is not set
CONFIG_FB_CFB_FILLRECT=y
CONFIG_FB_CFB_COPYAREA=y
CONFIG_FB_CFB_IMAGEBLIT=y
# CONFIG_FB_CFB_REV_PIXELS_IN_BYTE is not set
# CONFIG_FB_SYS_FILLRECT is not set
# CONFIG_FB_SYS_COPYAREA is not set
# CONFIG_FB_SYS_IMAGEBLIT is not set
# CONFIG_FB_FOREIGN_ENDIAN is not set
# CONFIG_FB_SYS_FOPS is not set
# CONFIG_FB_WMT_GE_ROPS is not set
# CONFIG_FB_SVGALIB is not set
# CONFIG_FB_MACMODES is not set
# CONFIG_FB_BACKLIGHT is not set
# CONFIG_FB_MODE_HELPERS is not set
# CONFIG_FB_TILEBLITTING is not set

#
# Frame buffer hardware drivers
#
CONFIG_FB_ARMCLCD=y
# CONFIG_FB_S1D13XXX is not set
# CONFIG_FB_VIRTUAL is not set
# CONFIG_FB_METRONOME is not set
# CONFIG_FB_BROADSHEET is not set
# CONFIG_BACKLIGHT_LCD_SUPPORT is not set

#
# Display device support
#
# CONFIG_DISPLAY_SUPPORT is not set

#
# Console display driver support
#
CONFIG_DUMMY_CONSOLE=y
CONFIG_FRAMEBUFFER_CONSOLE=y
# CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY is not set
# CONFIG_FRAMEBUFFER_CONSOLE_ROTATION is not set
CONFIG_FONTS=y
# CONFIG_FONT_8x8 is not set
# CONFIG_FONT_8x16 is not set
# CONFIG_FONT_6x11 is not set
# CONFIG_FONT_7x14 is not set
# CONFIG_FONT_PEARL_8x8 is not set
CONFIG_FONT_ACORN_8x8=y
# CONFIG_FONT_MINI_4x6 is not set
# CONFIG_FONT_SUN8x16 is not set
# CONFIG_FONT_SUN12x22 is not set
# CONFIG_FONT_10x18 is not set
# CONFIG_LOGO is not set
CONFIG_SOUND=y
CONFIG_SOUND_OSS_CORE=y
CONFIG_SOUND_OSS_CORE_PRECLAIM=y
CONFIG_SND=y
CONFIG_SND_TIMER=y
CONFIG_SND_PCM=y
# CONFIG_SND_SEQUENCER is not set
CONFIG_SND_OSSEMUL=y
CONFIG_SND_MIXER_OSS=y
CONFIG_SND_PCM_OSS=y
CONFIG_SND_PCM_OSS_PLUGINS=y
# CONFIG_SND_HRTIMER is not set
# CONFIG_SND_DYNAMIC_MINORS is not set
CONFIG_SND_SUPPORT_OLD_API=y
CONFIG_SND_VERBOSE_PROCFS=y
# CONFIG_SND_VERBOSE_PRINTK is not set
# CONFIG_SND_DEBUG is not set
CONFIG_SND_VMASTER=y
# CONFIG_SND_RAWMIDI_SEQ is not set
# CONFIG_SND_OPL3_LIB_SEQ is not set
# CONFIG_SND_OPL4_LIB_SEQ is not set
# CONFIG_SND_SBAWE_SEQ is not set
# CONFIG_SND_EMU10K1_SEQ is not set
CONFIG_SND_AC97_CODEC=y
CONFIG_SND_DRIVERS=y
# CONFIG_SND_DUMMY is not set
# CONFIG_SND_ALOOP is not set
# CONFIG_SND_MTPAV is not set
# CONFIG_SND_SERIAL_U16550 is not set
# CONFIG_SND_MPU401 is not set
# CONFIG_SND_AC97_POWER_SAVE is not set
CONFIG_SND_ARM=y
CONFIG_SND_ARMAACI=y
# CONFIG_SND_SOC is not set
# CONFIG_SOUND_PRIME is not set
CONFIG_AC97_BUS=y
CONFIG_HID_SUPPORT=y
CONFIG_HID=y
# CONFIG_HIDRAW is not set
# CONFIG_HID_PID is not set

#
# Special HID drivers
#
CONFIG_USB_SUPPORT=y
CONFIG_USB_ARCH_HAS_HCD=y
# CONFIG_USB_ARCH_HAS_OHCI is not set
# CONFIG_USB_ARCH_HAS_EHCI is not set
# CONFIG_USB_ARCH_HAS_XHCI is not set
# CONFIG_USB is not set

#
# NOTE: USB_STORAGE depends on SCSI but BLK_DEV_SD may
#
# CONFIG_USB_GADGET is not set

#
# OTG and related infrastructure
#
CONFIG_MMC=y
# CONFIG_MMC_DEBUG is not set
# CONFIG_MMC_UNSAFE_RESUME is not set
# CONFIG_MMC_CLKGATE is not set

#
# MMC/SD/SDIO Card Drivers
#
CONFIG_MMC_BLOCK=y
CONFIG_MMC_BLOCK_MINORS=8
CONFIG_MMC_BLOCK_BOUNCE=y
# CONFIG_SDIO_UART is not set
# CONFIG_MMC_TEST is not set

#
# MMC/SD/SDIO Host Controller Drivers
#
CONFIG_MMC_ARMMMCI=y
CONFIG_MMC_SDHCI=y
CONFIG_MMC_SDHCI_PLTFM=y
# CONFIG_MMC_SDHCI_PXAV3 is not set
# CONFIG_MMC_SDHCI_PXAV2 is not set
CONFIG_MMC_DW=y
CONFIG_MMC_DW_IDMAC=y
# CONFIG_MEMSTICK is not set
# CONFIG_NEW_LEDS is not set
# CONFIG_ACCESSIBILITY is not set
CONFIG_RTC_LIB=y
# CONFIG_RTC_CLASS is not set
# CONFIG_DMADEVICES is not set
# CONFIG_AUXDISPLAY is not set
# CONFIG_UIO is not set

#
# Virtio drivers
#
# CONFIG_VIRTIO_BALLOON is not set
# CONFIG_VIRTIO_MMIO is not set
# CONFIG_STAGING is not set
CONFIG_CLKDEV_LOOKUP=y
CONFIG_HAVE_MACH_CLKDEV=y

#
# Hardware Spinlock drivers
#
CONFIG_CLKSRC_MMIO=y
CONFIG_IOMMU_SUPPORT=y
# CONFIG_VIRT_DRIVERS is not set

#
# File systems
#
CONFIG_EXT2_FS=y
# CONFIG_EXT2_FS_XATTR is not set
# CONFIG_EXT2_FS_XIP is not set
CONFIG_EXT3_FS=y
CONFIG_EXT3_DEFAULTS_TO_ORDERED=y
CONFIG_EXT3_FS_XATTR=y
# CONFIG_EXT3_FS_POSIX_ACL is not set
# CONFIG_EXT3_FS_SECURITY is not set
# CONFIG_EXT4_FS is not set
CONFIG_JBD=y
# CONFIG_JBD_DEBUG is not set
CONFIG_FS_MBCACHE=y
# CONFIG_REISERFS_FS is not set
# CONFIG_JFS_FS is not set
# CONFIG_XFS_FS is not set
# CONFIG_GFS2_FS is not set
# CONFIG_BTRFS_FS is not set
# CONFIG_NILFS2_FS is not set
CONFIG_FS_POSIX_ACL=y
CONFIG_EXPORTFS=y
CONFIG_FILE_LOCKING=y
CONFIG_FSNOTIFY=y
CONFIG_DNOTIFY=y
CONFIG_INOTIFY_USER=y
# CONFIG_FANOTIFY is not set
# CONFIG_QUOTA is not set
# CONFIG_QUOTACTL is not set
# CONFIG_AUTOFS4_FS is not set
# CONFIG_FUSE_FS is not set
CONFIG_GENERIC_ACL=y

#
# Caches
#
# CONFIG_FSCACHE is not set

#
# CD-ROM/DVD Filesystems
#
# CONFIG_ISO9660_FS is not set
# CONFIG_UDF_FS is not set

#
# DOS/FAT/NT Filesystems
#
CONFIG_FAT_FS=y
# CONFIG_MSDOS_FS is not set
CONFIG_VFAT_FS=y
CONFIG_FAT_DEFAULT_CODEPAGE=437
CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1"
# CONFIG_NTFS_FS is not set

#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
CONFIG_PROC_SYSCTL=y
CONFIG_PROC_PAGE_MONITOR=y
CONFIG_SYSFS=y
CONFIG_TMPFS=y
CONFIG_TMPFS_POSIX_ACL=y
CONFIG_TMPFS_XATTR=y
# CONFIG_HUGETLB_PAGE is not set
# CONFIG_CONFIGFS_FS is not set
CONFIG_MISC_FILESYSTEMS=y
# CONFIG_ADFS_FS is not set
# CONFIG_AFFS_FS is not set
# CONFIG_HFS_FS is not set
# CONFIG_HFSPLUS_FS is not set
# CONFIG_BEFS_FS is not set
# CONFIG_BFS_FS is not set
# CONFIG_EFS_FS is not set
CONFIG_JFFS2_FS=y
CONFIG_JFFS2_FS_DEBUG=0
CONFIG_JFFS2_FS_WRITEBUFFER=y
# CONFIG_JFFS2_FS_WBUF_VERIFY is not set
# CONFIG_JFFS2_SUMMARY is not set
# CONFIG_JFFS2_FS_XATTR is not set
# CONFIG_JFFS2_COMPRESSION_OPTIONS is not set
CONFIG_JFFS2_ZLIB=y
# CONFIG_JFFS2_LZO is not set
CONFIG_JFFS2_RTIME=y
# CONFIG_JFFS2_RUBIN is not set
# CONFIG_LOGFS is not set
CONFIG_CRAMFS=y
# CONFIG_SQUASHFS is not set
# CONFIG_VXFS_FS is not set
CONFIG_MINIX_FS=y
# CONFIG_OMFS_FS is not set
# CONFIG_HPFS_FS is not set
# CONFIG_QNX4FS_FS is not set
CONFIG_ROMFS_FS=y
CONFIG_ROMFS_BACKED_BY_BLOCK=y
# CONFIG_ROMFS_BACKED_BY_MTD is not set
# CONFIG_ROMFS_BACKED_BY_BOTH is not set
CONFIG_ROMFS_ON_BLOCK=y
# CONFIG_PSTORE is not set
# CONFIG_SYSV_FS is not set
# CONFIG_UFS_FS is not set
CONFIG_NETWORK_FILESYSTEMS=y
CONFIG_NFS_FS=y
CONFIG_NFS_V3=y
# CONFIG_NFS_V3_ACL is not set
# CONFIG_NFS_V4 is not set
CONFIG_ROOT_NFS=y
CONFIG_NFSD=y
CONFIG_NFSD_V3=y
# CONFIG_NFSD_V3_ACL is not set
# CONFIG_NFSD_V4 is not set
CONFIG_LOCKD=y
CONFIG_LOCKD_V4=y
CONFIG_NFS_COMMON=y
CONFIG_SUNRPC=y
# CONFIG_CEPH_FS is not set
# CONFIG_CIFS is not set
# CONFIG_NCP_FS is not set
# CONFIG_CODA_FS is not set
# CONFIG_AFS_FS is not set

#
# Partition Types
#
CONFIG_PARTITION_ADVANCED=y
# CONFIG_ACORN_PARTITION is not set
# CONFIG_OSF_PARTITION is not set
# CONFIG_AMIGA_PARTITION is not set
# CONFIG_ATARI_PARTITION is not set
# CONFIG_MAC_PARTITION is not set
CONFIG_MSDOS_PARTITION=y
# CONFIG_BSD_DISKLABEL is not set
# CONFIG_MINIX_SUBPARTITION is not set
# CONFIG_SOLARIS_X86_PARTITION is not set
# CONFIG_UNIXWARE_DISKLABEL is not set
# CONFIG_LDM_PARTITION is not set
# CONFIG_SGI_PARTITION is not set
# CONFIG_ULTRIX_PARTITION is not set
# CONFIG_SUN_PARTITION is not set
# CONFIG_KARMA_PARTITION is not set
# CONFIG_EFI_PARTITION is not set
# CONFIG_SYSV68_PARTITION is not set
CONFIG_NLS=y
CONFIG_NLS_DEFAULT="iso8859-1"
# CONFIG_NLS_CODEPAGE_437 is not set
# CONFIG_NLS_CODEPAGE_737 is not set
# CONFIG_NLS_CODEPAGE_775 is not set
CONFIG_NLS_CODEPAGE_850=y
# CONFIG_NLS_CODEPAGE_852 is not set
# CONFIG_NLS_CODEPAGE_855 is not set
# CONFIG_NLS_CODEPAGE_857 is not set
# CONFIG_NLS_CODEPAGE_860 is not set
# CONFIG_NLS_CODEPAGE_861 is not set
# CONFIG_NLS_CODEPAGE_862 is not set
# CONFIG_NLS_CODEPAGE_863 is not set
# CONFIG_NLS_CODEPAGE_864 is not set
# CONFIG_NLS_CODEPAGE_865 is not set
# CONFIG_NLS_CODEPAGE_866 is not set
# CONFIG_NLS_CODEPAGE_869 is not set
# CONFIG_NLS_CODEPAGE_936 is not set
# CONFIG_NLS_CODEPAGE_950 is not set
# CONFIG_NLS_CODEPAGE_932 is not set
# CONFIG_NLS_CODEPAGE_949 is not set
# CONFIG_NLS_CODEPAGE_874 is not set
# CONFIG_NLS_ISO8859_8 is not set
# CONFIG_NLS_CODEPAGE_1250 is not set
# CONFIG_NLS_CODEPAGE_1251 is not set
# CONFIG_NLS_ASCII is not set
CONFIG_NLS_ISO8859_1=y
# CONFIG_NLS_ISO8859_2 is not set
# CONFIG_NLS_ISO8859_3 is not set
# CONFIG_NLS_ISO8859_4 is not set
# CONFIG_NLS_ISO8859_5 is not set
# CONFIG_NLS_ISO8859_6 is not set
# CONFIG_NLS_ISO8859_7 is not set
# CONFIG_NLS_ISO8859_9 is not set
# CONFIG_NLS_ISO8859_13 is not set
# CONFIG_NLS_ISO8859_14 is not set
# CONFIG_NLS_ISO8859_15 is not set
# CONFIG_NLS_KOI8_R is not set
# CONFIG_NLS_KOI8_U is not set
# CONFIG_NLS_UTF8 is not set

#
# Kernel hacking
#
# CONFIG_PRINTK_TIME is not set
CONFIG_DEFAULT_MESSAGE_LOGLEVEL=4
CONFIG_ENABLE_WARN_DEPRECATED=y
CONFIG_ENABLE_MUST_CHECK=y
CONFIG_FRAME_WARN=1024
CONFIG_MAGIC_SYSRQ=y
# CONFIG_STRIP_ASM_SYMS is not set
# CONFIG_UNUSED_SYMBOLS is not set
CONFIG_DEBUG_FS=y
# CONFIG_HEADERS_CHECK is not set
# CONFIG_DEBUG_SECTION_MISMATCH is not set
CONFIG_DEBUG_KERNEL=y
# CONFIG_DEBUG_SHIRQ is not set
# CONFIG_LOCKUP_DETECTOR is not set
# CONFIG_HARDLOCKUP_DETECTOR is not set
# CONFIG_DETECT_HUNG_TASK is not set
CONFIG_SCHED_DEBUG=y
# CONFIG_SCHEDSTATS is not set
# CONFIG_TIMER_STATS is not set
# CONFIG_DEBUG_OBJECTS is not set
# CONFIG_DEBUG_SLAB is not set
# CONFIG_DEBUG_KMEMLEAK is not set
# CONFIG_DEBUG_RT_MUTEXES is not set
# CONFIG_RT_MUTEX_TESTER is not set
# CONFIG_DEBUG_SPINLOCK is not set
# CONFIG_DEBUG_MUTEXES is not set
# CONFIG_DEBUG_LOCK_ALLOC is not set
# CONFIG_PROVE_LOCKING is not set
# CONFIG_SPARSE_RCU_POINTER is not set
# CONFIG_LOCK_STAT is not set
# CONFIG_DEBUG_ATOMIC_SLEEP is not set
# CONFIG_DEBUG_LOCKING_API_SELFTESTS is not set
# CONFIG_DEBUG_STACK_USAGE is not set
# CONFIG_DEBUG_KOBJECT is not set
# CONFIG_DEBUG_HIGHMEM is not set
CONFIG_DEBUG_BUGVERBOSE=y
CONFIG_DEBUG_INFO=y
# CONFIG_DEBUG_INFO_REDUCED is not set
# CONFIG_DEBUG_VM is not set
# CONFIG_DEBUG_WRITECOUNT is not set
CONFIG_DEBUG_MEMORY_INIT=y
# CONFIG_DEBUG_LIST is not set
# CONFIG_TEST_LIST_SORT is not set
# CONFIG_DEBUG_SG is not set
# CONFIG_DEBUG_NOTIFIERS is not set
# CONFIG_DEBUG_CREDENTIALS is not set
# CONFIG_BOOT_PRINTK_DELAY is not set
# CONFIG_RCU_TORTURE_TEST is not set
# CONFIG_BACKTRACE_SELF_TEST is not set
# CONFIG_DEBUG_BLOCK_EXT_DEVT is not set
# CONFIG_DEBUG_FORCE_WEAK_PER_CPU is not set
# CONFIG_LKDTM is not set
# CONFIG_FAULT_INJECTION is not set
# CONFIG_LATENCYTOP is not set
# CONFIG_SYSCTL_SYSCALL_CHECK is not set
# CONFIG_DEBUG_PAGEALLOC is not set
CONFIG_HAVE_FUNCTION_TRACER=y
CONFIG_HAVE_FUNCTION_GRAPH_TRACER=y
CONFIG_HAVE_DYNAMIC_FTRACE=y
CONFIG_HAVE_FTRACE_MCOUNT_RECORD=y
CONFIG_HAVE_C_RECORDMCOUNT=y
CONFIG_TRACING_SUPPORT=y
CONFIG_FTRACE=y
# CONFIG_FUNCTION_TRACER is not set
# CONFIG_IRQSOFF_TRACER is not set
# CONFIG_SCHED_TRACER is not set
# CONFIG_ENABLE_DEFAULT_TRACERS is not set
CONFIG_BRANCH_PROFILE_NONE=y
# CONFIG_PROFILE_ANNOTATED_BRANCHES is not set
# CONFIG_PROFILE_ALL_BRANCHES is not set
# CONFIG_STACK_TRACER is not set
# CONFIG_BLK_DEV_IO_TRACE is not set
# CONFIG_DYNAMIC_DEBUG is not set
# CONFIG_DMA_API_DEBUG is not set
# CONFIG_ATOMIC64_SELFTEST is not set
# CONFIG_SAMPLES is not set
CONFIG_HAVE_ARCH_KGDB=y
# CONFIG_KGDB is not set
# CONFIG_TEST_KSTRTOX is not set
# CONFIG_STRICT_DEVMEM is not set
CONFIG_ARM_UNWIND=y
CONFIG_DEBUG_USER=y
CONFIG_DEBUG_LL=y
CONFIG_DEBUG_LL_UART_NONE=y
# CONFIG_DEBUG_ICEDCC is not set
CONFIG_EARLY_PRINTK=y
# CONFIG_OC_ETM is not set

#
# Security options
#
# CONFIG_KEYS is not set
# CONFIG_SECURITY_DMESG_RESTRICT is not set
# CONFIG_SECURITY is not set
# CONFIG_SECURITYFS is not set
CONFIG_DEFAULT_SECURITY_DAC=y
CONFIG_DEFAULT_SECURITY=""
CONFIG_CRYPTO=y

#
# Crypto core or helper
#
CONFIG_CRYPTO_ALGAPI=y
CONFIG_CRYPTO_ALGAPI2=y
CONFIG_CRYPTO_AEAD2=y
CONFIG_CRYPTO_BLKCIPHER=y
CONFIG_CRYPTO_BLKCIPHER2=y
CONFIG_CRYPTO_HASH=y
CONFIG_CRYPTO_HASH2=y
CONFIG_CRYPTO_RNG=y
CONFIG_CRYPTO_RNG2=y
CONFIG_CRYPTO_PCOMP2=y
CONFIG_CRYPTO_MANAGER=y
CONFIG_CRYPTO_MANAGER2=y
# CONFIG_CRYPTO_USER is not set
CONFIG_CRYPTO_MANAGER_DISABLE_TESTS=y
# CONFIG_CRYPTO_GF128MUL is not set
# CONFIG_CRYPTO_NULL is not set
CONFIG_CRYPTO_WORKQUEUE=y
# CONFIG_CRYPTO_CRYPTD is not set
# CONFIG_CRYPTO_AUTHENC is not set

#
# Authenticated Encryption with Associated Data
#
# CONFIG_CRYPTO_CCM is not set
# CONFIG_CRYPTO_GCM is not set
# CONFIG_CRYPTO_SEQIV is not set

#
# Block modes
#
CONFIG_CRYPTO_CBC=y
# CONFIG_CRYPTO_CTR is not set
# CONFIG_CRYPTO_CTS is not set
# CONFIG_CRYPTO_ECB is not set
# CONFIG_CRYPTO_LRW is not set
# CONFIG_CRYPTO_PCBC is not set
# CONFIG_CRYPTO_XTS is not set

#
# Hash modes
#
# CONFIG_CRYPTO_HMAC is not set
# CONFIG_CRYPTO_XCBC is not set
# CONFIG_CRYPTO_VMAC is not set

#
# Digest
#
# CONFIG_CRYPTO_CRC32C is not set
# CONFIG_CRYPTO_GHASH is not set
# CONFIG_CRYPTO_MD4 is not set
CONFIG_CRYPTO_MD5=y
# CONFIG_CRYPTO_MICHAEL_MIC is not set
# CONFIG_CRYPTO_RMD128 is not set
# CONFIG_CRYPTO_RMD160 is not set
# CONFIG_CRYPTO_RMD256 is not set
# CONFIG_CRYPTO_RMD320 is not set
# CONFIG_CRYPTO_SHA1 is not set
# CONFIG_CRYPTO_SHA256 is not set
# CONFIG_CRYPTO_SHA512 is not set
# CONFIG_CRYPTO_TGR192 is not set
# CONFIG_CRYPTO_WP512 is not set

#
# Ciphers
#
CONFIG_CRYPTO_AES=y
# CONFIG_CRYPTO_ANUBIS is not set
# CONFIG_CRYPTO_ARC4 is not set
# CONFIG_CRYPTO_BLOWFISH is not set
# CONFIG_CRYPTO_CAMELLIA is not set
# CONFIG_CRYPTO_CAST5 is not set
# CONFIG_CRYPTO_CAST6 is not set
CONFIG_CRYPTO_DES=y
# CONFIG_CRYPTO_FCRYPT is not set
# CONFIG_CRYPTO_KHAZAD is not set
# CONFIG_CRYPTO_SALSA20 is not set
# CONFIG_CRYPTO_SEED is not set
# CONFIG_CRYPTO_SERPENT is not set
# CONFIG_CRYPTO_TEA is not set
# CONFIG_CRYPTO_TWOFISH is not set

#
# Compression
#
# CONFIG_CRYPTO_DEFLATE is not set
# CONFIG_CRYPTO_ZLIB is not set
# CONFIG_CRYPTO_LZO is not set

#
# Random Number Generation
#
CONFIG_CRYPTO_ANSI_CPRNG=y
# CONFIG_CRYPTO_USER_API_HASH is not set
# CONFIG_CRYPTO_USER_API_SKCIPHER is not set
CONFIG_CRYPTO_HW=y
# CONFIG_BINARY_PRINTF is not set

#
# Library routines
#
CONFIG_BITREVERSE=y
# CONFIG_CRC_CCITT is not set
# CONFIG_CRC16 is not set
# CONFIG_CRC_T10DIF is not set
# CONFIG_CRC_ITU_T is not set
CONFIG_CRC32=y
# CONFIG_CRC7 is not set
# CONFIG_LIBCRC32C is not set
# CONFIG_CRC8 is not set
CONFIG_ZLIB_INFLATE=y
CONFIG_ZLIB_DEFLATE=y
CONFIG_LZO_DECOMPRESS=y
CONFIG_XZ_DEC=y
CONFIG_XZ_DEC_X86=y
CONFIG_XZ_DEC_POWERPC=y
CONFIG_XZ_DEC_IA64=y
CONFIG_XZ_DEC_ARM=y
CONFIG_XZ_DEC_ARMTHUMB=y
CONFIG_XZ_DEC_SPARC=y
CONFIG_XZ_DEC_BCJ=y
# CONFIG_XZ_DEC_TEST is not set
CONFIG_DECOMPRESS_GZIP=y
CONFIG_DECOMPRESS_BZIP2=y
CONFIG_DECOMPRESS_LZMA=y
CONFIG_DECOMPRESS_XZ=y
CONFIG_DECOMPRESS_LZO=y
CONFIG_HAS_IOMEM=y
CONFIG_HAS_IOPORT=y
CONFIG_HAS_DMA=y
CONFIG_NLATTR=y
# CONFIG_AVERAGE is not set
# CONFIG_CORDIC is not set

--------------090403070505020406040906
Content-Type: text/plain; name="fm.cfg"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="fm.cfg"

cluster.cpuID=0x410fc0f0 
cluster.multiprocessor_extensions=1 
cluster.vmsa.separate_tlbs=1 
cluster.implements_ple_like_a8=0 
cluster.vmsa.implements_fcse=0 
cluster.vmsa.main_tlb_size=512 
cluster.vmsa.main_tlb_lockable_entries=4 
cluster.vmsa.instruction_tlb_size=32 
cluster.implements_virtualization=1 
cluster.implements_lpae=1 
cluster.use_Cortex-A15_peripherals=1 
cluster.delayed_CP15_operations=1 
cluster.num_cores=1 
cluster.cpu0.implements_fused_mac=1 
cluster.cpu0.implements_sdiv_udiv=1 
cluster.cpu0.l1icache-size_bytes=32768 
cluster.cpu0.l1icache-associativity=2 
cluster.cpu0.l1icache-linelength_bytes=64 
cluster.cpu0.l1dcache-size_bytes=32768 
cluster.cpu0.l1dcache-associativity=2 
cluster.cpu0.l1dcache-linelength_bytes=64 
cluster.cpu0.l2dcache-size_bytes=0x00200000 
cluster.cpu0.l2dcache-associativity=16 
cluster.cpu0.l2dcache-linelength_bytes=64

--------------090403070505020406040906
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--------------090403070505020406040906--


From xen-devel-bounces@lists.xensource.com Fri Dec 16 17:39:23 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 17:39:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbbkQ-0007tH-AT; Fri, 16 Dec 2011 17:39:06 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1RbbkO-0007t9-BS
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 17:39:04 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1324057135!7752519!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjI0MzY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13406 invoked from network); 16 Dec 2011 17:38:56 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Dec 2011 17:38:56 -0000
X-IronPort-AV: E=Sophos;i="4.71,364,1320642000"; 
	d="cfg'?scan'208";a="174488527"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Dec 2011 12:38:55 -0500
Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX01.citrite.net
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Fri, 16 Dec 2011
	12:38:54 -0500
Message-ID: <4EEB822C.7010809@citrix.com>
Date: Fri, 16 Dec 2011 17:38:52 +0000
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20111110 Icedove/3.0.11
MIME-Version: 1.0
To: Catalin Marinas <catalin.marinas@arm.com>
References: <alpine.DEB.2.00.1111281009090.31179@kaball-desktop>
	<201111292129.20444.arnd@arndb.de>
	<alpine.DEB.2.00.1111301053300.31179@kaball-desktop>
	<CAHkRjk48jHO19H04rf8252+v04hk9qSdKBrfYCqJsZyamVhMEw@mail.gmail.com>
	<4EEB673D.3040608@citrix.com> <20111216165420.GE6342@arm.com>
In-Reply-To: <20111216165420.GE6342@arm.com>
Content-Type: multipart/mixed; boundary="------------090403070505020406040906"
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>, Arnd Bergmann <arnd@arndb.de>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [ANNOUNCE] Xen port to Cortex-A15 / ARMv7 with virt
 extensions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--------------090403070505020406040906
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit

On 16/12/11 16:54, Catalin Marinas wrote:
> On Fri, Dec 16, 2011 at 03:43:57PM +0000, David Vrabel wrote:
>> On 30/11/11 14:11, Catalin Marinas wrote:
>>> On 30 November 2011 11:39, Stefano Stabellini
>>> <stefano.stabellini@eu.citrix.com> wrote:
>>>> A git branch is available here (not ready for submission):
>>>>
>>>> git://xenbits.xen.org/people/sstabellini/linux-pvhvm.git arm
>>>>
>>>> the branch above is based on git://linux-arm.org/linux-2.6.git arm-lpae,
>>>> even though guests don't really need lpae support to run on Xen.
>>>
>>> Indeed, you don't really need LPAE. What you may need though is
>>> generic timers support for A15, it would allow less Hypervisor traps.
>>> For up-to-date architecture patches (well, development tree, not
>>> guaranteed to be stable), I would recommend this (they get into
>>> mainline at some point):
>>>
>>> http://git.kernel.org/?p=linux/kernel/git/cmarinas/linux-arm-arch.git;a=summary
>>>
>>> Either use master or just cherry-pick the branches that you are interested in.
>>
>> Which branches are required for the Versatile Express with the
>> Cortex-A15? I merged linux-arm-arch/arm-arch/vexpress in
> 
> That's the branch if you only need VE and A15 support
> 
>> but I get a
>> instruction fault immediately after branching to __mmap_switched.
>>
>> Is it not setting up the MMU correctly?
> 
> Do you run this on a software model? What config options do you use? You
> would need to enable VEXPRESS_EXTENDED_MEMORY_MAP and
> ARCH_VEXPRESS_CA15X4.

The envelope model, yes.  Both those options are enabled.  I've also
attached the complete config and the model configuration.

I took a closer look at the diffs between what Stefano had in his tree
(which included a bunch of LPAE support which I don't have enabled) and
the kernel boots the addition of some isb's when the MMU is switched on.

These were added by: "ARM: LPAE: add ISBs around MMU enabling code"
(commit 1c553c2 in your tree) which is think is only present in the LPAE
branch.  Is this patch not actually specific to LPAE?  Are there other
similar patches?

diff --git a/arch/arm/kernel/head.S b/arch/arm/kernel/head.S
index 566c54c..b4e84e2 100644
--- a/arch/arm/kernel/head.S
+++ b/arch/arm/kernel/head.S
@@ -400,8 +400,10 @@ ENDPROC(__enable_mmu)
        .align  5
 __turn_mmu_on:
        mov     r0, r0
+        isb
        mcr     p15, 0, r0, c1, c0, 0           @ write control reg
        mrc     p15, 0, r3, c0, c0, 0           @ read id reg
+        isb
        mov     r3, r3
        mov     r3, r13
        mov     pc, r3

David

--------------090403070505020406040906
Content-Type: text/plain; name=".config"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename=".config"

#
# Automatically generated file; DO NOT EDIT.
# Linux/arm 3.2.0-rc1 Kernel Configuration
#
CONFIG_ARM=y
CONFIG_SYS_SUPPORTS_APM_EMULATION=y
CONFIG_HAVE_SCHED_CLOCK=y
# CONFIG_ARCH_USES_GETTIMEOFFSET is not set
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_KTIME_SCALAR=y
CONFIG_HAVE_PROC_CPU=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_HAVE_LATENCYTOP_SUPPORT=y
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_TRACE_IRQFLAGS_SUPPORT=y
CONFIG_HARDIRQS_SW_RESEND=y
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_RWSEM_GENERIC_SPINLOCK=y
CONFIG_ARCH_HAS_CPU_IDLE_WAIT=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_VECTORS_BASE=0xffff0000
CONFIG_ARM_PATCH_PHYS_VIRT=y
CONFIG_NEED_MACH_MEMORY_H=y
CONFIG_GENERIC_BUG=y
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_HAVE_IRQ_WORK=y

#
# General setup
#
CONFIG_EXPERIMENTAL=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
CONFIG_LOCALVERSION=""
# CONFIG_LOCALVERSION_AUTO is not set
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_KERNEL_GZIP=y
# CONFIG_KERNEL_LZMA is not set
# CONFIG_KERNEL_LZO is not set
CONFIG_DEFAULT_HOSTNAME="(none)"
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
# CONFIG_POSIX_MQUEUE is not set
# CONFIG_BSD_PROCESS_ACCT is not set
# CONFIG_FHANDLE is not set
# CONFIG_TASKSTATS is not set
# CONFIG_AUDIT is not set
CONFIG_HAVE_GENERIC_HARDIRQS=y

#
# IRQ subsystem
#
CONFIG_GENERIC_HARDIRQS=y
CONFIG_HAVE_SPARSE_IRQ=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_IRQ_DOMAIN=y
CONFIG_SPARSE_IRQ=y

#
# RCU Subsystem
#
CONFIG_TINY_RCU=y
# CONFIG_PREEMPT_RCU is not set
# CONFIG_RCU_TRACE is not set
# CONFIG_TREE_RCU_TRACE is not set
# CONFIG_IKCONFIG is not set
CONFIG_LOG_BUF_SHIFT=14
# CONFIG_CGROUPS is not set
CONFIG_NAMESPACES=y
CONFIG_UTS_NS=y
CONFIG_IPC_NS=y
CONFIG_USER_NS=y
CONFIG_PID_NS=y
CONFIG_NET_NS=y
# CONFIG_SCHED_AUTOGROUP is not set
# CONFIG_SYSFS_DEPRECATED is not set
# CONFIG_RELAY is not set
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=""
CONFIG_RD_GZIP=y
CONFIG_RD_BZIP2=y
CONFIG_RD_LZMA=y
CONFIG_RD_XZ=y
CONFIG_RD_LZO=y
CONFIG_CC_OPTIMIZE_FOR_SIZE=y
CONFIG_SYSCTL=y
CONFIG_ANON_INODES=y
# CONFIG_EXPERT is not set
CONFIG_UID16=y
# CONFIG_SYSCTL_SYSCALL is not set
CONFIG_KALLSYMS=y
# CONFIG_KALLSYMS_ALL is not set
CONFIG_HOTPLUG=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_SIGNALFD=y
CONFIG_TIMERFD=y
CONFIG_EVENTFD=y
CONFIG_SHMEM=y
CONFIG_AIO=y
# CONFIG_EMBEDDED is not set
CONFIG_HAVE_PERF_EVENTS=y
CONFIG_PERF_USE_VMALLOC=y

#
# Kernel Performance Events And Counters
#
# CONFIG_PERF_EVENTS is not set
# CONFIG_PERF_COUNTERS is not set
CONFIG_VM_EVENT_COUNTERS=y
CONFIG_COMPAT_BRK=y
CONFIG_SLAB=y
# CONFIG_SLUB is not set
# CONFIG_PROFILING is not set
CONFIG_HAVE_OPROFILE=y
CONFIG_HAVE_KPROBES=y
CONFIG_HAVE_KRETPROBES=y
CONFIG_HAVE_REGS_AND_STACK_ACCESS_API=y
CONFIG_HAVE_CLK=y
CONFIG_HAVE_DMA_API_DEBUG=y

#
# GCOV-based kernel profiling
#
# CONFIG_GCOV_KERNEL is not set
CONFIG_HAVE_GENERIC_DMA_COHERENT=y
CONFIG_SLABINFO=y
CONFIG_RT_MUTEXES=y
CONFIG_BASE_SMALL=0
# CONFIG_MODULES is not set
CONFIG_BLOCK=y
CONFIG_LBDAF=y
CONFIG_BLK_DEV_BSG=y
# CONFIG_BLK_DEV_BSGLIB is not set
# CONFIG_BLK_DEV_INTEGRITY is not set

#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_DEADLINE=y
CONFIG_IOSCHED_CFQ=y
# CONFIG_DEFAULT_DEADLINE is not set
CONFIG_DEFAULT_CFQ=y
# CONFIG_DEFAULT_NOOP is not set
CONFIG_DEFAULT_IOSCHED="cfq"
# CONFIG_INLINE_SPIN_TRYLOCK is not set
# CONFIG_INLINE_SPIN_TRYLOCK_BH is not set
# CONFIG_INLINE_SPIN_LOCK is not set
# CONFIG_INLINE_SPIN_LOCK_BH is not set
# CONFIG_INLINE_SPIN_LOCK_IRQ is not set
# CONFIG_INLINE_SPIN_LOCK_IRQSAVE is not set
CONFIG_INLINE_SPIN_UNLOCK=y
# CONFIG_INLINE_SPIN_UNLOCK_BH is not set
CONFIG_INLINE_SPIN_UNLOCK_IRQ=y
# CONFIG_INLINE_SPIN_UNLOCK_IRQRESTORE is not set
# CONFIG_INLINE_READ_TRYLOCK is not set
# CONFIG_INLINE_READ_LOCK is not set
# CONFIG_INLINE_READ_LOCK_BH is not set
# CONFIG_INLINE_READ_LOCK_IRQ is not set
# CONFIG_INLINE_READ_LOCK_IRQSAVE is not set
CONFIG_INLINE_READ_UNLOCK=y
# CONFIG_INLINE_READ_UNLOCK_BH is not set
CONFIG_INLINE_READ_UNLOCK_IRQ=y
# CONFIG_INLINE_READ_UNLOCK_IRQRESTORE is not set
# CONFIG_INLINE_WRITE_TRYLOCK is not set
# CONFIG_INLINE_WRITE_LOCK is not set
# CONFIG_INLINE_WRITE_LOCK_BH is not set
# CONFIG_INLINE_WRITE_LOCK_IRQ is not set
# CONFIG_INLINE_WRITE_LOCK_IRQSAVE is not set
CONFIG_INLINE_WRITE_UNLOCK=y
# CONFIG_INLINE_WRITE_UNLOCK_BH is not set
CONFIG_INLINE_WRITE_UNLOCK_IRQ=y
# CONFIG_INLINE_WRITE_UNLOCK_IRQRESTORE is not set
# CONFIG_MUTEX_SPIN_ON_OWNER is not set
CONFIG_FREEZER=y

#
# System Type
#
CONFIG_MMU=y
# CONFIG_ARCH_INTEGRATOR is not set
# CONFIG_ARCH_REALVIEW is not set
# CONFIG_ARCH_VERSATILE is not set
CONFIG_ARCH_VEXPRESS=y
# CONFIG_ARCH_AT91 is not set
# CONFIG_ARCH_BCMRING is not set
# CONFIG_ARCH_HIGHBANK is not set
# CONFIG_ARCH_CLPS711X is not set
# CONFIG_ARCH_CNS3XXX is not set
# CONFIG_ARCH_GEMINI is not set
# CONFIG_ARCH_PRIMA2 is not set
# CONFIG_ARCH_EBSA110 is not set
# CONFIG_ARCH_EP93XX is not set
# CONFIG_ARCH_FOOTBRIDGE is not set
# CONFIG_ARCH_MXC is not set
# CONFIG_ARCH_MXS is not set
# CONFIG_ARCH_NETX is not set
# CONFIG_ARCH_H720X is not set
# CONFIG_ARCH_IOP13XX is not set
# CONFIG_ARCH_IOP32X is not set
# CONFIG_ARCH_IOP33X is not set
# CONFIG_ARCH_IXP23XX is not set
# CONFIG_ARCH_IXP2000 is not set
# CONFIG_ARCH_IXP4XX is not set
# CONFIG_ARCH_DOVE is not set
# CONFIG_ARCH_KIRKWOOD is not set
# CONFIG_ARCH_LPC32XX is not set
# CONFIG_ARCH_MV78XX0 is not set
# CONFIG_ARCH_ORION5X is not set
# CONFIG_ARCH_MMP is not set
# CONFIG_ARCH_KS8695 is not set
# CONFIG_ARCH_W90X900 is not set
# CONFIG_ARCH_TEGRA is not set
# CONFIG_ARCH_PICOXCELL is not set
# CONFIG_ARCH_PNX4008 is not set
# CONFIG_ARCH_PXA is not set
# CONFIG_ARCH_MSM is not set
# CONFIG_ARCH_SHMOBILE is not set
# CONFIG_ARCH_RPC is not set
# CONFIG_ARCH_SA1100 is not set
# CONFIG_ARCH_S3C2410 is not set
# CONFIG_ARCH_S3C64XX is not set
# CONFIG_ARCH_S5P64X0 is not set
# CONFIG_ARCH_S5PC100 is not set
# CONFIG_ARCH_S5PV210 is not set
# CONFIG_ARCH_EXYNOS is not set
# CONFIG_ARCH_SHARK is not set
# CONFIG_ARCH_TCC_926 is not set
# CONFIG_ARCH_U300 is not set
# CONFIG_ARCH_U8500 is not set
# CONFIG_ARCH_NOMADIK is not set
# CONFIG_ARCH_DAVINCI is not set
# CONFIG_ARCH_OMAP is not set
# CONFIG_PLAT_SPEAR is not set
# CONFIG_ARCH_VT8500 is not set
# CONFIG_ARCH_ZYNQ is not set

#
# System MMU
#

#
# Versatile Express platform type
#
# CONFIG_VEXPRESS_ORIGINAL_MEMORY_MAP is not set
CONFIG_VEXPRESS_EXTENDED_MEMORY_MAP=y
CONFIG_ARCH_VEXPRESS_CA15X4=y
# CONFIG_ARCH_VEXPRESS_CA5S is not set
CONFIG_PLAT_VERSATILE_CLCD=y
CONFIG_PLAT_VERSATILE_SCHED_CLOCK=y
CONFIG_PLAT_VERSATILE=y
CONFIG_ARM_TIMER_SP804=y

#
# Processor Type
#
CONFIG_CPU_V7=y
CONFIG_CPU_32v6K=y
CONFIG_CPU_32v7=y
CONFIG_CPU_ABRT_EV7=y
CONFIG_CPU_PABRT_V7=y
CONFIG_CPU_CACHE_V7=y
CONFIG_CPU_CACHE_VIPT=y
CONFIG_CPU_COPY_V6=y
CONFIG_CPU_TLB_V7=y
CONFIG_CPU_HAS_ASID=y
CONFIG_CPU_CP15=y
CONFIG_CPU_CP15_MMU=y

#
# Processor Features
#
CONFIG_ARM_THUMB=y
# CONFIG_ARM_THUMBEE is not set
# CONFIG_SWP_EMULATE is not set
# CONFIG_CPU_ICACHE_DISABLE is not set
# CONFIG_CPU_DCACHE_DISABLE is not set
# CONFIG_CPU_BPREDICT_DISABLE is not set
CONFIG_ARM_L1_CACHE_SHIFT=5
CONFIG_ARM_DMA_MEM_BUFFERABLE=y
CONFIG_CPU_HAS_PMU=y
CONFIG_MULTI_IRQ_HANDLER=y
# CONFIG_ARM_ERRATA_430973 is not set
# CONFIG_ARM_ERRATA_458693 is not set
# CONFIG_ARM_ERRATA_460075 is not set
# CONFIG_ARM_ERRATA_743622 is not set
# CONFIG_ARM_ERRATA_754322 is not set
CONFIG_ARM_GIC=y
CONFIG_ICST=y

#
# Bus support
#
CONFIG_ARM_AMBA=y
# CONFIG_PCI_SYSCALL is not set
# CONFIG_ARCH_SUPPORTS_MSI is not set
# CONFIG_PCI_PRI is not set
# CONFIG_PCCARD is not set

#
# Kernel Features
#
CONFIG_TICK_ONESHOT=y
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y
CONFIG_GENERIC_CLOCKEVENTS_BUILD=y
# CONFIG_SMP is not set
CONFIG_ARM_ARCH_TIMER=y
CONFIG_VMSPLIT_3G=y
# CONFIG_VMSPLIT_2G is not set
# CONFIG_VMSPLIT_1G is not set
CONFIG_PAGE_OFFSET=0xC0000000
CONFIG_PREEMPT_NONE=y
# CONFIG_PREEMPT_VOLUNTARY is not set
# CONFIG_PREEMPT is not set
CONFIG_HZ=100
# CONFIG_THUMB2_KERNEL is not set
CONFIG_AEABI=y
CONFIG_OABI_COMPAT=y
# CONFIG_ARCH_SPARSEMEM_DEFAULT is not set
# CONFIG_ARCH_SELECT_MEMORY_MODEL is not set
CONFIG_HAVE_ARCH_PFN_VALID=y
CONFIG_HIGHMEM=y
CONFIG_HIGHPTE=y
CONFIG_SELECT_MEMORY_MODEL=y
CONFIG_FLATMEM_MANUAL=y
CONFIG_FLATMEM=y
CONFIG_FLAT_NODE_MEM_MAP=y
CONFIG_HAVE_MEMBLOCK=y
CONFIG_PAGEFLAGS_EXTENDED=y
CONFIG_SPLIT_PTLOCK_CPUS=4
# CONFIG_COMPACTION is not set
# CONFIG_PHYS_ADDR_T_64BIT is not set
CONFIG_ZONE_DMA_FLAG=0
CONFIG_BOUNCE=y
CONFIG_VIRT_TO_BUS=y
# CONFIG_KSM is not set
CONFIG_DEFAULT_MMAP_MIN_ADDR=4096
CONFIG_NEED_PER_CPU_KM=y
# CONFIG_CLEANCACHE is not set
CONFIG_FORCE_MAX_ZONEORDER=11
CONFIG_ALIGNMENT_TRAP=y
# CONFIG_UACCESS_WITH_MEMCPY is not set
# CONFIG_SECCOMP is not set
# CONFIG_CC_STACKPROTECTOR is not set
# CONFIG_DEPRECATED_PARAM_STRUCT is not set

#
# Boot options
#
# CONFIG_USE_OF is not set
CONFIG_ZBOOT_ROM_TEXT=0x0
CONFIG_ZBOOT_ROM_BSS=0x0
CONFIG_CMDLINE="console=hvc0 earlyprintk=xen"
CONFIG_CMDLINE_FROM_BOOTLOADER=y
# CONFIG_CMDLINE_EXTEND is not set
# CONFIG_CMDLINE_FORCE is not set
# CONFIG_XIP_KERNEL is not set
# CONFIG_KEXEC is not set
# CONFIG_CRASH_DUMP is not set
# CONFIG_AUTO_ZRELADDR is not set

#
# CPU Power Management
#
# CONFIG_CPU_IDLE is not set

#
# Floating point emulation
#

#
# At least one emulation must be selected
#
# CONFIG_FPE_NWFPE is not set
# CONFIG_FPE_FASTFPE is not set
# CONFIG_VFP is not set

#
# Userspace binary formats
#
CONFIG_BINFMT_ELF=y
CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS=y
CONFIG_HAVE_AOUT=y
# CONFIG_BINFMT_AOUT is not set
# CONFIG_BINFMT_MISC is not set

#
# Power management options
#
CONFIG_SUSPEND=y
CONFIG_SUSPEND_FREEZER=y
CONFIG_PM_SLEEP=y
# CONFIG_PM_RUNTIME is not set
CONFIG_PM=y
# CONFIG_PM_DEBUG is not set
# CONFIG_APM_EMULATION is not set
CONFIG_PM_CLK=y
CONFIG_CPU_PM=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARM_CPU_SUSPEND=y
CONFIG_NET=y

#
# Networking options
#
CONFIG_PACKET=y
CONFIG_UNIX=y
CONFIG_XFRM=y
# CONFIG_XFRM_USER is not set
# CONFIG_XFRM_SUB_POLICY is not set
# CONFIG_XFRM_MIGRATE is not set
# CONFIG_XFRM_STATISTICS is not set
# CONFIG_NET_KEY is not set
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
# CONFIG_IP_ADVANCED_ROUTER is not set
CONFIG_IP_PNP=y
# CONFIG_IP_PNP_DHCP is not set
CONFIG_IP_PNP_BOOTP=y
# CONFIG_IP_PNP_RARP is not set
# CONFIG_NET_IPIP is not set
# CONFIG_NET_IPGRE_DEMUX is not set
# CONFIG_IP_MROUTE is not set
# CONFIG_ARPD is not set
# CONFIG_SYN_COOKIES is not set
# CONFIG_INET_AH is not set
# CONFIG_INET_ESP is not set
# CONFIG_INET_IPCOMP is not set
# CONFIG_INET_XFRM_TUNNEL is not set
# CONFIG_INET_TUNNEL is not set
CONFIG_INET_XFRM_MODE_TRANSPORT=y
CONFIG_INET_XFRM_MODE_TUNNEL=y
CONFIG_INET_XFRM_MODE_BEET=y
CONFIG_INET_LRO=y
# CONFIG_INET_DIAG is not set
# CONFIG_TCP_CONG_ADVANCED is not set
CONFIG_TCP_CONG_CUBIC=y
CONFIG_DEFAULT_TCP_CONG="cubic"
# CONFIG_TCP_MD5SIG is not set
# CONFIG_IPV6 is not set
# CONFIG_NETWORK_SECMARK is not set
# CONFIG_NETWORK_PHY_TIMESTAMPING is not set
# CONFIG_NETFILTER is not set
# CONFIG_IP_DCCP is not set
# CONFIG_IP_SCTP is not set
# CONFIG_RDS is not set
# CONFIG_TIPC is not set
# CONFIG_ATM is not set
# CONFIG_L2TP is not set
# CONFIG_BRIDGE is not set
# CONFIG_NET_DSA is not set
# CONFIG_VLAN_8021Q is not set
# CONFIG_DECNET is not set
# CONFIG_LLC2 is not set
# CONFIG_IPX is not set
# CONFIG_ATALK is not set
# CONFIG_X25 is not set
# CONFIG_LAPB is not set
# CONFIG_ECONET is not set
# CONFIG_WAN_ROUTER is not set
# CONFIG_PHONET is not set
# CONFIG_IEEE802154 is not set
# CONFIG_NET_SCHED is not set
# CONFIG_DCB is not set
# CONFIG_BATMAN_ADV is not set

#
# Network testing
#
# CONFIG_NET_PKTGEN is not set
# CONFIG_HAMRADIO is not set
# CONFIG_CAN is not set
# CONFIG_IRDA is not set
# CONFIG_BT is not set
# CONFIG_AF_RXRPC is not set
CONFIG_WIRELESS=y
# CONFIG_CFG80211 is not set
# CONFIG_LIB80211 is not set

#
# CFG80211 needs to be enabled for MAC80211
#
# CONFIG_WIMAX is not set
# CONFIG_RFKILL is not set
# CONFIG_NET_9P is not set
# CONFIG_CAIF is not set
# CONFIG_CEPH_LIB is not set
# CONFIG_NFC is not set

#
# Device Drivers
#

#
# Generic Driver Options
#
CONFIG_UEVENT_HELPER_PATH=""
# CONFIG_DEVTMPFS is not set
CONFIG_STANDALONE=y
CONFIG_PREVENT_FIRMWARE_BUILD=y
CONFIG_FW_LOADER=y
CONFIG_FIRMWARE_IN_KERNEL=y
CONFIG_EXTRA_FIRMWARE=""
# CONFIG_DEBUG_DRIVER is not set
# CONFIG_DEBUG_DEVRES is not set
# CONFIG_SYS_HYPERVISOR is not set
# CONFIG_CONNECTOR is not set
CONFIG_MTD=y
# CONFIG_MTD_REDBOOT_PARTS is not set
CONFIG_MTD_CMDLINE_PARTS=y
# CONFIG_MTD_AFS_PARTS is not set
# CONFIG_MTD_AR7_PARTS is not set

#
# User Modules And Translation Layers
#
CONFIG_MTD_CHAR=y
CONFIG_MTD_BLKDEVS=y
CONFIG_MTD_BLOCK=y
# CONFIG_FTL is not set
# CONFIG_NFTL is not set
# CONFIG_INFTL is not set
# CONFIG_RFD_FTL is not set
# CONFIG_SSFDC is not set
# CONFIG_SM_FTL is not set
# CONFIG_MTD_OOPS is not set
# CONFIG_MTD_SWAP is not set

#
# RAM/ROM/Flash chip drivers
#
CONFIG_MTD_CFI=y
# CONFIG_MTD_JEDECPROBE is not set
CONFIG_MTD_GEN_PROBE=y
CONFIG_MTD_CFI_ADV_OPTIONS=y
CONFIG_MTD_CFI_NOSWAP=y
# CONFIG_MTD_CFI_BE_BYTE_SWAP is not set
# CONFIG_MTD_CFI_LE_BYTE_SWAP is not set
# CONFIG_MTD_CFI_GEOMETRY is not set
CONFIG_MTD_MAP_BANK_WIDTH_1=y
CONFIG_MTD_MAP_BANK_WIDTH_2=y
CONFIG_MTD_MAP_BANK_WIDTH_4=y
# CONFIG_MTD_MAP_BANK_WIDTH_8 is not set
# CONFIG_MTD_MAP_BANK_WIDTH_16 is not set
# CONFIG_MTD_MAP_BANK_WIDTH_32 is not set
CONFIG_MTD_CFI_I1=y
CONFIG_MTD_CFI_I2=y
# CONFIG_MTD_CFI_I4 is not set
# CONFIG_MTD_CFI_I8 is not set
# CONFIG_MTD_OTP is not set
CONFIG_MTD_CFI_INTELEXT=y
# CONFIG_MTD_CFI_AMDSTD is not set
# CONFIG_MTD_CFI_STAA is not set
CONFIG_MTD_CFI_UTIL=y
# CONFIG_MTD_RAM is not set
# CONFIG_MTD_ROM is not set
# CONFIG_MTD_ABSENT is not set

#
# Mapping drivers for chip access
#
# CONFIG_MTD_COMPLEX_MAPPINGS is not set
# CONFIG_MTD_PHYSMAP is not set
# CONFIG_MTD_PLATRAM is not set

#
# Self-contained MTD device drivers
#
# CONFIG_MTD_SLRAM is not set
# CONFIG_MTD_PHRAM is not set
# CONFIG_MTD_MTDRAM is not set
# CONFIG_MTD_BLOCK2MTD is not set

#
# Disk-On-Chip Device Drivers
#
# CONFIG_MTD_DOC2000 is not set
# CONFIG_MTD_DOC2001 is not set
# CONFIG_MTD_DOC2001PLUS is not set
# CONFIG_MTD_DOCG3 is not set
# CONFIG_MTD_NAND is not set
# CONFIG_MTD_ONENAND is not set

#
# LPDDR flash memory drivers
#
# CONFIG_MTD_LPDDR is not set
# CONFIG_MTD_UBI is not set
# CONFIG_PARPORT is not set
CONFIG_BLK_DEV=y
# CONFIG_BLK_DEV_COW_COMMON is not set
# CONFIG_BLK_DEV_LOOP is not set

#
# DRBD disabled because PROC_FS, INET or CONNECTOR not selected
#
# CONFIG_BLK_DEV_NBD is not set
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_COUNT=16
CONFIG_BLK_DEV_RAM_SIZE=4096
# CONFIG_BLK_DEV_XIP is not set
# CONFIG_CDROM_PKTCDVD is not set
# CONFIG_ATA_OVER_ETH is not set
# CONFIG_BLK_DEV_RBD is not set
# CONFIG_SENSORS_LIS3LV02D is not set
# CONFIG_MISC_DEVICES is not set

#
# SCSI device support
#
CONFIG_SCSI_MOD=y
# CONFIG_RAID_ATTRS is not set
CONFIG_SCSI=y
CONFIG_SCSI_DMA=y
# CONFIG_SCSI_TGT is not set
# CONFIG_SCSI_NETLINK is not set
CONFIG_SCSI_PROC_FS=y

#
# SCSI support type (disk, tape, CD-ROM)
#
CONFIG_BLK_DEV_SD=y
# CONFIG_CHR_DEV_ST is not set
# CONFIG_CHR_DEV_OSST is not set
# CONFIG_BLK_DEV_SR is not set
# CONFIG_CHR_DEV_SG is not set
# CONFIG_CHR_DEV_SCH is not set
# CONFIG_SCSI_MULTI_LUN is not set
# CONFIG_SCSI_CONSTANTS is not set
# CONFIG_SCSI_LOGGING is not set
# CONFIG_SCSI_SCAN_ASYNC is not set

#
# SCSI Transports
#
# CONFIG_SCSI_SPI_ATTRS is not set
# CONFIG_SCSI_FC_ATTRS is not set
# CONFIG_SCSI_ISCSI_ATTRS is not set
# CONFIG_SCSI_SAS_ATTRS is not set
# CONFIG_SCSI_SAS_LIBSAS is not set
# CONFIG_SCSI_SRP_ATTRS is not set
CONFIG_SCSI_LOWLEVEL=y
# CONFIG_ISCSI_TCP is not set
# CONFIG_ISCSI_BOOT_SYSFS is not set
# CONFIG_LIBFC is not set
# CONFIG_LIBFCOE is not set
# CONFIG_SCSI_DEBUG is not set
# CONFIG_SCSI_DH is not set
# CONFIG_SCSI_OSD_INITIATOR is not set
CONFIG_HAVE_PATA_PLATFORM=y
CONFIG_ATA=y
# CONFIG_ATA_NONSTANDARD is not set
CONFIG_ATA_VERBOSE_ERROR=y
CONFIG_SATA_PMP=y

#
# Controllers with non-SFF native interface
#
# CONFIG_SATA_AHCI_PLATFORM is not set
CONFIG_ATA_SFF=y

#
# SFF controllers with custom DMA interface
#
# CONFIG_ATA_BMDMA is not set

#
# PIO-only SFF controllers
#
# CONFIG_PATA_PLATFORM is not set

#
# Generic fallback / legacy drivers
#
# CONFIG_MD is not set
# CONFIG_TARGET_CORE is not set
CONFIG_NETDEVICES=y
CONFIG_NET_CORE=y
# CONFIG_BONDING is not set
# CONFIG_DUMMY is not set
# CONFIG_EQUALIZER is not set
CONFIG_MII=y
# CONFIG_MACVLAN is not set
# CONFIG_NETCONSOLE is not set
# CONFIG_NETPOLL is not set
# CONFIG_NET_POLL_CONTROLLER is not set
# CONFIG_TUN is not set
# CONFIG_VETH is not set

#
# CAIF transport drivers
#
# CONFIG_ETHERNET is not set
# CONFIG_PHYLIB is not set
# CONFIG_PPP is not set
# CONFIG_SLIP is not set
CONFIG_WLAN=y
# CONFIG_HOSTAP is not set

#
# Enable WiMAX (Networking options) to see the WiMAX drivers
#
# CONFIG_WAN is not set
# CONFIG_ISDN is not set
# CONFIG_PHONE is not set

#
# Input device support
#
CONFIG_INPUT=y
# CONFIG_INPUT_FF_MEMLESS is not set
# CONFIG_INPUT_POLLDEV is not set
# CONFIG_INPUT_SPARSEKMAP is not set

#
# Userland interfaces
#
CONFIG_INPUT_MOUSEDEV=y
CONFIG_INPUT_MOUSEDEV_PSAUX=y
CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024
CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768
# CONFIG_INPUT_JOYDEV is not set
CONFIG_INPUT_EVDEV=y
# CONFIG_INPUT_EVBUG is not set

#
# Input Device Drivers
#
CONFIG_INPUT_KEYBOARD=y
# CONFIG_KEYBOARD_ADP5588 is not set
# CONFIG_KEYBOARD_ADP5589 is not set
CONFIG_KEYBOARD_ATKBD=y
# CONFIG_KEYBOARD_QT1070 is not set
# CONFIG_KEYBOARD_QT2160 is not set
# CONFIG_KEYBOARD_LKKBD is not set
# CONFIG_KEYBOARD_TCA6416 is not set
# CONFIG_KEYBOARD_MAX7359 is not set
# CONFIG_KEYBOARD_MCS is not set
# CONFIG_KEYBOARD_MPR121 is not set
# CONFIG_KEYBOARD_NEWTON is not set
# CONFIG_KEYBOARD_OPENCORES is not set
# CONFIG_KEYBOARD_STOWAWAY is not set
# CONFIG_KEYBOARD_SUNKBD is not set
# CONFIG_KEYBOARD_XTKBD is not set
CONFIG_INPUT_MOUSE=y
CONFIG_MOUSE_PS2=y
CONFIG_MOUSE_PS2_ALPS=y
CONFIG_MOUSE_PS2_LOGIPS2PP=y
CONFIG_MOUSE_PS2_SYNAPTICS=y
CONFIG_MOUSE_PS2_TRACKPOINT=y
# CONFIG_MOUSE_PS2_ELANTECH is not set
# CONFIG_MOUSE_PS2_SENTELIC is not set
# CONFIG_MOUSE_PS2_TOUCHKIT is not set
# CONFIG_MOUSE_SERIAL is not set
# CONFIG_MOUSE_APPLETOUCH is not set
# CONFIG_MOUSE_BCM5974 is not set
# CONFIG_MOUSE_VSXXXAA is not set
# CONFIG_MOUSE_SYNAPTICS_I2C is not set
# CONFIG_INPUT_JOYSTICK is not set
# CONFIG_INPUT_TABLET is not set
# CONFIG_INPUT_TOUCHSCREEN is not set
# CONFIG_INPUT_MISC is not set

#
# Hardware I/O ports
#
CONFIG_SERIO=y
# CONFIG_SERIO_SERPORT is not set
CONFIG_SERIO_AMBAKMI=y
CONFIG_SERIO_LIBPS2=y
# CONFIG_SERIO_RAW is not set
# CONFIG_SERIO_ALTERA_PS2 is not set
# CONFIG_SERIO_PS2MULT is not set
# CONFIG_GAMEPORT is not set

#
# Character devices
#
CONFIG_VT=y
CONFIG_CONSOLE_TRANSLATIONS=y
CONFIG_VT_CONSOLE=y
CONFIG_VT_CONSOLE_SLEEP=y
CONFIG_HW_CONSOLE=y
# CONFIG_VT_HW_CONSOLE_BINDING is not set
CONFIG_UNIX98_PTYS=y
# CONFIG_DEVPTS_MULTIPLE_INSTANCES is not set
CONFIG_LEGACY_PTYS=y
CONFIG_LEGACY_PTY_COUNT=16
# CONFIG_SERIAL_NONSTANDARD is not set
# CONFIG_N_GSM is not set
# CONFIG_TRACE_SINK is not set
CONFIG_DEVKMEM=y

#
# Serial drivers
#
CONFIG_SERIAL_8250=y
# CONFIG_SERIAL_8250_CONSOLE is not set
CONFIG_SERIAL_8250_NR_UARTS=4
CONFIG_SERIAL_8250_RUNTIME_UARTS=4
CONFIG_SERIAL_8250_EXTENDED=y
CONFIG_SERIAL_8250_MANY_PORTS=y
CONFIG_SERIAL_8250_SHARE_IRQ=y
# CONFIG_SERIAL_8250_DETECT_IRQ is not set
CONFIG_SERIAL_8250_RSA=y

#
# Non-8250 serial port support
#
# CONFIG_SERIAL_AMBA_PL010 is not set
CONFIG_SERIAL_AMBA_PL011=y
CONFIG_SERIAL_AMBA_PL011_CONSOLE=y
CONFIG_SERIAL_CORE=y
CONFIG_SERIAL_CORE_CONSOLE=y
# CONFIG_SERIAL_TIMBERDALE is not set
# CONFIG_SERIAL_ALTERA_JTAGUART is not set
# CONFIG_SERIAL_ALTERA_UART is not set
# CONFIG_SERIAL_XILINX_PS_UART is not set
# CONFIG_HVC_DCC is not set
# CONFIG_IPMI_HANDLER is not set
CONFIG_HW_RANDOM=y
# CONFIG_HW_RANDOM_TIMERIOMEM is not set
# CONFIG_R3964 is not set
# CONFIG_RAW_DRIVER is not set
# CONFIG_TCG_TPM is not set
# CONFIG_RAMOOPS is not set
CONFIG_I2C=y
CONFIG_I2C_BOARDINFO=y
CONFIG_I2C_COMPAT=y
CONFIG_I2C_CHARDEV=y
# CONFIG_I2C_MUX is not set
CONFIG_I2C_HELPER_AUTO=y

#
# I2C Hardware Bus support
#

#
# I2C system bus drivers (mostly embedded / system-on-chip)
#
# CONFIG_I2C_DESIGNWARE_PLATFORM is not set
# CONFIG_I2C_OCORES is not set
# CONFIG_I2C_PCA_PLATFORM is not set
# CONFIG_I2C_PXA_PCI is not set
# CONFIG_I2C_SIMTEC is not set
# CONFIG_I2C_VERSATILE is not set
# CONFIG_I2C_XILINX is not set

#
# External I2C/SMBus adapter drivers
#
# CONFIG_I2C_PARPORT_LIGHT is not set
# CONFIG_I2C_TAOS_EVM is not set

#
# Other I2C/SMBus bus drivers
#
# CONFIG_I2C_DEBUG_CORE is not set
# CONFIG_I2C_DEBUG_ALGO is not set
# CONFIG_I2C_DEBUG_BUS is not set
# CONFIG_SPI is not set

#
# PPS support
#
# CONFIG_PPS is not set

#
# PPS generators support
#

#
# PTP clock support
#

#
# Enable Device Drivers -> PPS to see the PTP clock options.
#
# CONFIG_PINCTRL is not set
CONFIG_ARCH_WANT_OPTIONAL_GPIOLIB=y
# CONFIG_GPIOLIB is not set
# CONFIG_W1 is not set
# CONFIG_POWER_SUPPLY is not set
# CONFIG_HWMON is not set
# CONFIG_THERMAL is not set
# CONFIG_WATCHDOG is not set
CONFIG_SSB_POSSIBLE=y

#
# Sonics Silicon Backplane
#
# CONFIG_SSB is not set
CONFIG_BCMA_POSSIBLE=y

#
# Broadcom specific AMBA
#
# CONFIG_BCMA is not set

#
# Multifunction device drivers
#
# CONFIG_MFD_CORE is not set
# CONFIG_MFD_88PM860X is not set
# CONFIG_MFD_SM501 is not set
# CONFIG_HTC_PASIC3 is not set
# CONFIG_TPS6105X is not set
# CONFIG_TPS6507X is not set
# CONFIG_TWL4030_CORE is not set
# CONFIG_MFD_STMPE is not set
# CONFIG_MFD_TC3589X is not set
# CONFIG_MFD_TMIO is not set
# CONFIG_MFD_T7L66XB is not set
# CONFIG_MFD_TC6387XB is not set
# CONFIG_PMIC_DA903X is not set
# CONFIG_PMIC_ADP5520 is not set
# CONFIG_MFD_MAX8925 is not set
# CONFIG_MFD_MAX8997 is not set
# CONFIG_MFD_MAX8998 is not set
# CONFIG_MFD_WM8400 is not set
# CONFIG_MFD_WM831X_I2C is not set
# CONFIG_MFD_WM8350_I2C is not set
# CONFIG_MFD_WM8994 is not set
# CONFIG_MFD_PCF50633 is not set
# CONFIG_ABX500_CORE is not set
# CONFIG_MFD_WL1273_CORE is not set
# CONFIG_REGULATOR is not set
# CONFIG_MEDIA_SUPPORT is not set

#
# Graphics support
#
# CONFIG_DRM is not set
# CONFIG_VGASTATE is not set
# CONFIG_VIDEO_OUTPUT_CONTROL is not set
CONFIG_FB=y
# CONFIG_FIRMWARE_EDID is not set
# CONFIG_FB_DDC is not set
# CONFIG_FB_BOOT_VESA_SUPPORT is not set
CONFIG_FB_CFB_FILLRECT=y
CONFIG_FB_CFB_COPYAREA=y
CONFIG_FB_CFB_IMAGEBLIT=y
# CONFIG_FB_CFB_REV_PIXELS_IN_BYTE is not set
# CONFIG_FB_SYS_FILLRECT is not set
# CONFIG_FB_SYS_COPYAREA is not set
# CONFIG_FB_SYS_IMAGEBLIT is not set
# CONFIG_FB_FOREIGN_ENDIAN is not set
# CONFIG_FB_SYS_FOPS is not set
# CONFIG_FB_WMT_GE_ROPS is not set
# CONFIG_FB_SVGALIB is not set
# CONFIG_FB_MACMODES is not set
# CONFIG_FB_BACKLIGHT is not set
# CONFIG_FB_MODE_HELPERS is not set
# CONFIG_FB_TILEBLITTING is not set

#
# Frame buffer hardware drivers
#
CONFIG_FB_ARMCLCD=y
# CONFIG_FB_S1D13XXX is not set
# CONFIG_FB_VIRTUAL is not set
# CONFIG_FB_METRONOME is not set
# CONFIG_FB_BROADSHEET is not set
# CONFIG_BACKLIGHT_LCD_SUPPORT is not set

#
# Display device support
#
# CONFIG_DISPLAY_SUPPORT is not set

#
# Console display driver support
#
CONFIG_DUMMY_CONSOLE=y
CONFIG_FRAMEBUFFER_CONSOLE=y
# CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY is not set
# CONFIG_FRAMEBUFFER_CONSOLE_ROTATION is not set
CONFIG_FONTS=y
# CONFIG_FONT_8x8 is not set
# CONFIG_FONT_8x16 is not set
# CONFIG_FONT_6x11 is not set
# CONFIG_FONT_7x14 is not set
# CONFIG_FONT_PEARL_8x8 is not set
CONFIG_FONT_ACORN_8x8=y
# CONFIG_FONT_MINI_4x6 is not set
# CONFIG_FONT_SUN8x16 is not set
# CONFIG_FONT_SUN12x22 is not set
# CONFIG_FONT_10x18 is not set
# CONFIG_LOGO is not set
CONFIG_SOUND=y
CONFIG_SOUND_OSS_CORE=y
CONFIG_SOUND_OSS_CORE_PRECLAIM=y
CONFIG_SND=y
CONFIG_SND_TIMER=y
CONFIG_SND_PCM=y
# CONFIG_SND_SEQUENCER is not set
CONFIG_SND_OSSEMUL=y
CONFIG_SND_MIXER_OSS=y
CONFIG_SND_PCM_OSS=y
CONFIG_SND_PCM_OSS_PLUGINS=y
# CONFIG_SND_HRTIMER is not set
# CONFIG_SND_DYNAMIC_MINORS is not set
CONFIG_SND_SUPPORT_OLD_API=y
CONFIG_SND_VERBOSE_PROCFS=y
# CONFIG_SND_VERBOSE_PRINTK is not set
# CONFIG_SND_DEBUG is not set
CONFIG_SND_VMASTER=y
# CONFIG_SND_RAWMIDI_SEQ is not set
# CONFIG_SND_OPL3_LIB_SEQ is not set
# CONFIG_SND_OPL4_LIB_SEQ is not set
# CONFIG_SND_SBAWE_SEQ is not set
# CONFIG_SND_EMU10K1_SEQ is not set
CONFIG_SND_AC97_CODEC=y
CONFIG_SND_DRIVERS=y
# CONFIG_SND_DUMMY is not set
# CONFIG_SND_ALOOP is not set
# CONFIG_SND_MTPAV is not set
# CONFIG_SND_SERIAL_U16550 is not set
# CONFIG_SND_MPU401 is not set
# CONFIG_SND_AC97_POWER_SAVE is not set
CONFIG_SND_ARM=y
CONFIG_SND_ARMAACI=y
# CONFIG_SND_SOC is not set
# CONFIG_SOUND_PRIME is not set
CONFIG_AC97_BUS=y
CONFIG_HID_SUPPORT=y
CONFIG_HID=y
# CONFIG_HIDRAW is not set
# CONFIG_HID_PID is not set

#
# Special HID drivers
#
CONFIG_USB_SUPPORT=y
CONFIG_USB_ARCH_HAS_HCD=y
# CONFIG_USB_ARCH_HAS_OHCI is not set
# CONFIG_USB_ARCH_HAS_EHCI is not set
# CONFIG_USB_ARCH_HAS_XHCI is not set
# CONFIG_USB is not set

#
# NOTE: USB_STORAGE depends on SCSI but BLK_DEV_SD may
#
# CONFIG_USB_GADGET is not set

#
# OTG and related infrastructure
#
CONFIG_MMC=y
# CONFIG_MMC_DEBUG is not set
# CONFIG_MMC_UNSAFE_RESUME is not set
# CONFIG_MMC_CLKGATE is not set

#
# MMC/SD/SDIO Card Drivers
#
CONFIG_MMC_BLOCK=y
CONFIG_MMC_BLOCK_MINORS=8
CONFIG_MMC_BLOCK_BOUNCE=y
# CONFIG_SDIO_UART is not set
# CONFIG_MMC_TEST is not set

#
# MMC/SD/SDIO Host Controller Drivers
#
CONFIG_MMC_ARMMMCI=y
CONFIG_MMC_SDHCI=y
CONFIG_MMC_SDHCI_PLTFM=y
# CONFIG_MMC_SDHCI_PXAV3 is not set
# CONFIG_MMC_SDHCI_PXAV2 is not set
CONFIG_MMC_DW=y
CONFIG_MMC_DW_IDMAC=y
# CONFIG_MEMSTICK is not set
# CONFIG_NEW_LEDS is not set
# CONFIG_ACCESSIBILITY is not set
CONFIG_RTC_LIB=y
# CONFIG_RTC_CLASS is not set
# CONFIG_DMADEVICES is not set
# CONFIG_AUXDISPLAY is not set
# CONFIG_UIO is not set

#
# Virtio drivers
#
# CONFIG_VIRTIO_BALLOON is not set
# CONFIG_VIRTIO_MMIO is not set
# CONFIG_STAGING is not set
CONFIG_CLKDEV_LOOKUP=y
CONFIG_HAVE_MACH_CLKDEV=y

#
# Hardware Spinlock drivers
#
CONFIG_CLKSRC_MMIO=y
CONFIG_IOMMU_SUPPORT=y
# CONFIG_VIRT_DRIVERS is not set

#
# File systems
#
CONFIG_EXT2_FS=y
# CONFIG_EXT2_FS_XATTR is not set
# CONFIG_EXT2_FS_XIP is not set
CONFIG_EXT3_FS=y
CONFIG_EXT3_DEFAULTS_TO_ORDERED=y
CONFIG_EXT3_FS_XATTR=y
# CONFIG_EXT3_FS_POSIX_ACL is not set
# CONFIG_EXT3_FS_SECURITY is not set
# CONFIG_EXT4_FS is not set
CONFIG_JBD=y
# CONFIG_JBD_DEBUG is not set
CONFIG_FS_MBCACHE=y
# CONFIG_REISERFS_FS is not set
# CONFIG_JFS_FS is not set
# CONFIG_XFS_FS is not set
# CONFIG_GFS2_FS is not set
# CONFIG_BTRFS_FS is not set
# CONFIG_NILFS2_FS is not set
CONFIG_FS_POSIX_ACL=y
CONFIG_EXPORTFS=y
CONFIG_FILE_LOCKING=y
CONFIG_FSNOTIFY=y
CONFIG_DNOTIFY=y
CONFIG_INOTIFY_USER=y
# CONFIG_FANOTIFY is not set
# CONFIG_QUOTA is not set
# CONFIG_QUOTACTL is not set
# CONFIG_AUTOFS4_FS is not set
# CONFIG_FUSE_FS is not set
CONFIG_GENERIC_ACL=y

#
# Caches
#
# CONFIG_FSCACHE is not set

#
# CD-ROM/DVD Filesystems
#
# CONFIG_ISO9660_FS is not set
# CONFIG_UDF_FS is not set

#
# DOS/FAT/NT Filesystems
#
CONFIG_FAT_FS=y
# CONFIG_MSDOS_FS is not set
CONFIG_VFAT_FS=y
CONFIG_FAT_DEFAULT_CODEPAGE=437
CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1"
# CONFIG_NTFS_FS is not set

#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
CONFIG_PROC_SYSCTL=y
CONFIG_PROC_PAGE_MONITOR=y
CONFIG_SYSFS=y
CONFIG_TMPFS=y
CONFIG_TMPFS_POSIX_ACL=y
CONFIG_TMPFS_XATTR=y
# CONFIG_HUGETLB_PAGE is not set
# CONFIG_CONFIGFS_FS is not set
CONFIG_MISC_FILESYSTEMS=y
# CONFIG_ADFS_FS is not set
# CONFIG_AFFS_FS is not set
# CONFIG_HFS_FS is not set
# CONFIG_HFSPLUS_FS is not set
# CONFIG_BEFS_FS is not set
# CONFIG_BFS_FS is not set
# CONFIG_EFS_FS is not set
CONFIG_JFFS2_FS=y
CONFIG_JFFS2_FS_DEBUG=0
CONFIG_JFFS2_FS_WRITEBUFFER=y
# CONFIG_JFFS2_FS_WBUF_VERIFY is not set
# CONFIG_JFFS2_SUMMARY is not set
# CONFIG_JFFS2_FS_XATTR is not set
# CONFIG_JFFS2_COMPRESSION_OPTIONS is not set
CONFIG_JFFS2_ZLIB=y
# CONFIG_JFFS2_LZO is not set
CONFIG_JFFS2_RTIME=y
# CONFIG_JFFS2_RUBIN is not set
# CONFIG_LOGFS is not set
CONFIG_CRAMFS=y
# CONFIG_SQUASHFS is not set
# CONFIG_VXFS_FS is not set
CONFIG_MINIX_FS=y
# CONFIG_OMFS_FS is not set
# CONFIG_HPFS_FS is not set
# CONFIG_QNX4FS_FS is not set
CONFIG_ROMFS_FS=y
CONFIG_ROMFS_BACKED_BY_BLOCK=y
# CONFIG_ROMFS_BACKED_BY_MTD is not set
# CONFIG_ROMFS_BACKED_BY_BOTH is not set
CONFIG_ROMFS_ON_BLOCK=y
# CONFIG_PSTORE is not set
# CONFIG_SYSV_FS is not set
# CONFIG_UFS_FS is not set
CONFIG_NETWORK_FILESYSTEMS=y
CONFIG_NFS_FS=y
CONFIG_NFS_V3=y
# CONFIG_NFS_V3_ACL is not set
# CONFIG_NFS_V4 is not set
CONFIG_ROOT_NFS=y
CONFIG_NFSD=y
CONFIG_NFSD_V3=y
# CONFIG_NFSD_V3_ACL is not set
# CONFIG_NFSD_V4 is not set
CONFIG_LOCKD=y
CONFIG_LOCKD_V4=y
CONFIG_NFS_COMMON=y
CONFIG_SUNRPC=y
# CONFIG_CEPH_FS is not set
# CONFIG_CIFS is not set
# CONFIG_NCP_FS is not set
# CONFIG_CODA_FS is not set
# CONFIG_AFS_FS is not set

#
# Partition Types
#
CONFIG_PARTITION_ADVANCED=y
# CONFIG_ACORN_PARTITION is not set
# CONFIG_OSF_PARTITION is not set
# CONFIG_AMIGA_PARTITION is not set
# CONFIG_ATARI_PARTITION is not set
# CONFIG_MAC_PARTITION is not set
CONFIG_MSDOS_PARTITION=y
# CONFIG_BSD_DISKLABEL is not set
# CONFIG_MINIX_SUBPARTITION is not set
# CONFIG_SOLARIS_X86_PARTITION is not set
# CONFIG_UNIXWARE_DISKLABEL is not set
# CONFIG_LDM_PARTITION is not set
# CONFIG_SGI_PARTITION is not set
# CONFIG_ULTRIX_PARTITION is not set
# CONFIG_SUN_PARTITION is not set
# CONFIG_KARMA_PARTITION is not set
# CONFIG_EFI_PARTITION is not set
# CONFIG_SYSV68_PARTITION is not set
CONFIG_NLS=y
CONFIG_NLS_DEFAULT="iso8859-1"
# CONFIG_NLS_CODEPAGE_437 is not set
# CONFIG_NLS_CODEPAGE_737 is not set
# CONFIG_NLS_CODEPAGE_775 is not set
CONFIG_NLS_CODEPAGE_850=y
# CONFIG_NLS_CODEPAGE_852 is not set
# CONFIG_NLS_CODEPAGE_855 is not set
# CONFIG_NLS_CODEPAGE_857 is not set
# CONFIG_NLS_CODEPAGE_860 is not set
# CONFIG_NLS_CODEPAGE_861 is not set
# CONFIG_NLS_CODEPAGE_862 is not set
# CONFIG_NLS_CODEPAGE_863 is not set
# CONFIG_NLS_CODEPAGE_864 is not set
# CONFIG_NLS_CODEPAGE_865 is not set
# CONFIG_NLS_CODEPAGE_866 is not set
# CONFIG_NLS_CODEPAGE_869 is not set
# CONFIG_NLS_CODEPAGE_936 is not set
# CONFIG_NLS_CODEPAGE_950 is not set
# CONFIG_NLS_CODEPAGE_932 is not set
# CONFIG_NLS_CODEPAGE_949 is not set
# CONFIG_NLS_CODEPAGE_874 is not set
# CONFIG_NLS_ISO8859_8 is not set
# CONFIG_NLS_CODEPAGE_1250 is not set
# CONFIG_NLS_CODEPAGE_1251 is not set
# CONFIG_NLS_ASCII is not set
CONFIG_NLS_ISO8859_1=y
# CONFIG_NLS_ISO8859_2 is not set
# CONFIG_NLS_ISO8859_3 is not set
# CONFIG_NLS_ISO8859_4 is not set
# CONFIG_NLS_ISO8859_5 is not set
# CONFIG_NLS_ISO8859_6 is not set
# CONFIG_NLS_ISO8859_7 is not set
# CONFIG_NLS_ISO8859_9 is not set
# CONFIG_NLS_ISO8859_13 is not set
# CONFIG_NLS_ISO8859_14 is not set
# CONFIG_NLS_ISO8859_15 is not set
# CONFIG_NLS_KOI8_R is not set
# CONFIG_NLS_KOI8_U is not set
# CONFIG_NLS_UTF8 is not set

#
# Kernel hacking
#
# CONFIG_PRINTK_TIME is not set
CONFIG_DEFAULT_MESSAGE_LOGLEVEL=4
CONFIG_ENABLE_WARN_DEPRECATED=y
CONFIG_ENABLE_MUST_CHECK=y
CONFIG_FRAME_WARN=1024
CONFIG_MAGIC_SYSRQ=y
# CONFIG_STRIP_ASM_SYMS is not set
# CONFIG_UNUSED_SYMBOLS is not set
CONFIG_DEBUG_FS=y
# CONFIG_HEADERS_CHECK is not set
# CONFIG_DEBUG_SECTION_MISMATCH is not set
CONFIG_DEBUG_KERNEL=y
# CONFIG_DEBUG_SHIRQ is not set
# CONFIG_LOCKUP_DETECTOR is not set
# CONFIG_HARDLOCKUP_DETECTOR is not set
# CONFIG_DETECT_HUNG_TASK is not set
CONFIG_SCHED_DEBUG=y
# CONFIG_SCHEDSTATS is not set
# CONFIG_TIMER_STATS is not set
# CONFIG_DEBUG_OBJECTS is not set
# CONFIG_DEBUG_SLAB is not set
# CONFIG_DEBUG_KMEMLEAK is not set
# CONFIG_DEBUG_RT_MUTEXES is not set
# CONFIG_RT_MUTEX_TESTER is not set
# CONFIG_DEBUG_SPINLOCK is not set
# CONFIG_DEBUG_MUTEXES is not set
# CONFIG_DEBUG_LOCK_ALLOC is not set
# CONFIG_PROVE_LOCKING is not set
# CONFIG_SPARSE_RCU_POINTER is not set
# CONFIG_LOCK_STAT is not set
# CONFIG_DEBUG_ATOMIC_SLEEP is not set
# CONFIG_DEBUG_LOCKING_API_SELFTESTS is not set
# CONFIG_DEBUG_STACK_USAGE is not set
# CONFIG_DEBUG_KOBJECT is not set
# CONFIG_DEBUG_HIGHMEM is not set
CONFIG_DEBUG_BUGVERBOSE=y
CONFIG_DEBUG_INFO=y
# CONFIG_DEBUG_INFO_REDUCED is not set
# CONFIG_DEBUG_VM is not set
# CONFIG_DEBUG_WRITECOUNT is not set
CONFIG_DEBUG_MEMORY_INIT=y
# CONFIG_DEBUG_LIST is not set
# CONFIG_TEST_LIST_SORT is not set
# CONFIG_DEBUG_SG is not set
# CONFIG_DEBUG_NOTIFIERS is not set
# CONFIG_DEBUG_CREDENTIALS is not set
# CONFIG_BOOT_PRINTK_DELAY is not set
# CONFIG_RCU_TORTURE_TEST is not set
# CONFIG_BACKTRACE_SELF_TEST is not set
# CONFIG_DEBUG_BLOCK_EXT_DEVT is not set
# CONFIG_DEBUG_FORCE_WEAK_PER_CPU is not set
# CONFIG_LKDTM is not set
# CONFIG_FAULT_INJECTION is not set
# CONFIG_LATENCYTOP is not set
# CONFIG_SYSCTL_SYSCALL_CHECK is not set
# CONFIG_DEBUG_PAGEALLOC is not set
CONFIG_HAVE_FUNCTION_TRACER=y
CONFIG_HAVE_FUNCTION_GRAPH_TRACER=y
CONFIG_HAVE_DYNAMIC_FTRACE=y
CONFIG_HAVE_FTRACE_MCOUNT_RECORD=y
CONFIG_HAVE_C_RECORDMCOUNT=y
CONFIG_TRACING_SUPPORT=y
CONFIG_FTRACE=y
# CONFIG_FUNCTION_TRACER is not set
# CONFIG_IRQSOFF_TRACER is not set
# CONFIG_SCHED_TRACER is not set
# CONFIG_ENABLE_DEFAULT_TRACERS is not set
CONFIG_BRANCH_PROFILE_NONE=y
# CONFIG_PROFILE_ANNOTATED_BRANCHES is not set
# CONFIG_PROFILE_ALL_BRANCHES is not set
# CONFIG_STACK_TRACER is not set
# CONFIG_BLK_DEV_IO_TRACE is not set
# CONFIG_DYNAMIC_DEBUG is not set
# CONFIG_DMA_API_DEBUG is not set
# CONFIG_ATOMIC64_SELFTEST is not set
# CONFIG_SAMPLES is not set
CONFIG_HAVE_ARCH_KGDB=y
# CONFIG_KGDB is not set
# CONFIG_TEST_KSTRTOX is not set
# CONFIG_STRICT_DEVMEM is not set
CONFIG_ARM_UNWIND=y
CONFIG_DEBUG_USER=y
CONFIG_DEBUG_LL=y
CONFIG_DEBUG_LL_UART_NONE=y
# CONFIG_DEBUG_ICEDCC is not set
CONFIG_EARLY_PRINTK=y
# CONFIG_OC_ETM is not set

#
# Security options
#
# CONFIG_KEYS is not set
# CONFIG_SECURITY_DMESG_RESTRICT is not set
# CONFIG_SECURITY is not set
# CONFIG_SECURITYFS is not set
CONFIG_DEFAULT_SECURITY_DAC=y
CONFIG_DEFAULT_SECURITY=""
CONFIG_CRYPTO=y

#
# Crypto core or helper
#
CONFIG_CRYPTO_ALGAPI=y
CONFIG_CRYPTO_ALGAPI2=y
CONFIG_CRYPTO_AEAD2=y
CONFIG_CRYPTO_BLKCIPHER=y
CONFIG_CRYPTO_BLKCIPHER2=y
CONFIG_CRYPTO_HASH=y
CONFIG_CRYPTO_HASH2=y
CONFIG_CRYPTO_RNG=y
CONFIG_CRYPTO_RNG2=y
CONFIG_CRYPTO_PCOMP2=y
CONFIG_CRYPTO_MANAGER=y
CONFIG_CRYPTO_MANAGER2=y
# CONFIG_CRYPTO_USER is not set
CONFIG_CRYPTO_MANAGER_DISABLE_TESTS=y
# CONFIG_CRYPTO_GF128MUL is not set
# CONFIG_CRYPTO_NULL is not set
CONFIG_CRYPTO_WORKQUEUE=y
# CONFIG_CRYPTO_CRYPTD is not set
# CONFIG_CRYPTO_AUTHENC is not set

#
# Authenticated Encryption with Associated Data
#
# CONFIG_CRYPTO_CCM is not set
# CONFIG_CRYPTO_GCM is not set
# CONFIG_CRYPTO_SEQIV is not set

#
# Block modes
#
CONFIG_CRYPTO_CBC=y
# CONFIG_CRYPTO_CTR is not set
# CONFIG_CRYPTO_CTS is not set
# CONFIG_CRYPTO_ECB is not set
# CONFIG_CRYPTO_LRW is not set
# CONFIG_CRYPTO_PCBC is not set
# CONFIG_CRYPTO_XTS is not set

#
# Hash modes
#
# CONFIG_CRYPTO_HMAC is not set
# CONFIG_CRYPTO_XCBC is not set
# CONFIG_CRYPTO_VMAC is not set

#
# Digest
#
# CONFIG_CRYPTO_CRC32C is not set
# CONFIG_CRYPTO_GHASH is not set
# CONFIG_CRYPTO_MD4 is not set
CONFIG_CRYPTO_MD5=y
# CONFIG_CRYPTO_MICHAEL_MIC is not set
# CONFIG_CRYPTO_RMD128 is not set
# CONFIG_CRYPTO_RMD160 is not set
# CONFIG_CRYPTO_RMD256 is not set
# CONFIG_CRYPTO_RMD320 is not set
# CONFIG_CRYPTO_SHA1 is not set
# CONFIG_CRYPTO_SHA256 is not set
# CONFIG_CRYPTO_SHA512 is not set
# CONFIG_CRYPTO_TGR192 is not set
# CONFIG_CRYPTO_WP512 is not set

#
# Ciphers
#
CONFIG_CRYPTO_AES=y
# CONFIG_CRYPTO_ANUBIS is not set
# CONFIG_CRYPTO_ARC4 is not set
# CONFIG_CRYPTO_BLOWFISH is not set
# CONFIG_CRYPTO_CAMELLIA is not set
# CONFIG_CRYPTO_CAST5 is not set
# CONFIG_CRYPTO_CAST6 is not set
CONFIG_CRYPTO_DES=y
# CONFIG_CRYPTO_FCRYPT is not set
# CONFIG_CRYPTO_KHAZAD is not set
# CONFIG_CRYPTO_SALSA20 is not set
# CONFIG_CRYPTO_SEED is not set
# CONFIG_CRYPTO_SERPENT is not set
# CONFIG_CRYPTO_TEA is not set
# CONFIG_CRYPTO_TWOFISH is not set

#
# Compression
#
# CONFIG_CRYPTO_DEFLATE is not set
# CONFIG_CRYPTO_ZLIB is not set
# CONFIG_CRYPTO_LZO is not set

#
# Random Number Generation
#
CONFIG_CRYPTO_ANSI_CPRNG=y
# CONFIG_CRYPTO_USER_API_HASH is not set
# CONFIG_CRYPTO_USER_API_SKCIPHER is not set
CONFIG_CRYPTO_HW=y
# CONFIG_BINARY_PRINTF is not set

#
# Library routines
#
CONFIG_BITREVERSE=y
# CONFIG_CRC_CCITT is not set
# CONFIG_CRC16 is not set
# CONFIG_CRC_T10DIF is not set
# CONFIG_CRC_ITU_T is not set
CONFIG_CRC32=y
# CONFIG_CRC7 is not set
# CONFIG_LIBCRC32C is not set
# CONFIG_CRC8 is not set
CONFIG_ZLIB_INFLATE=y
CONFIG_ZLIB_DEFLATE=y
CONFIG_LZO_DECOMPRESS=y
CONFIG_XZ_DEC=y
CONFIG_XZ_DEC_X86=y
CONFIG_XZ_DEC_POWERPC=y
CONFIG_XZ_DEC_IA64=y
CONFIG_XZ_DEC_ARM=y
CONFIG_XZ_DEC_ARMTHUMB=y
CONFIG_XZ_DEC_SPARC=y
CONFIG_XZ_DEC_BCJ=y
# CONFIG_XZ_DEC_TEST is not set
CONFIG_DECOMPRESS_GZIP=y
CONFIG_DECOMPRESS_BZIP2=y
CONFIG_DECOMPRESS_LZMA=y
CONFIG_DECOMPRESS_XZ=y
CONFIG_DECOMPRESS_LZO=y
CONFIG_HAS_IOMEM=y
CONFIG_HAS_IOPORT=y
CONFIG_HAS_DMA=y
CONFIG_NLATTR=y
# CONFIG_AVERAGE is not set
# CONFIG_CORDIC is not set

--------------090403070505020406040906
Content-Type: text/plain; name="fm.cfg"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="fm.cfg"

cluster.cpuID=0x410fc0f0 
cluster.multiprocessor_extensions=1 
cluster.vmsa.separate_tlbs=1 
cluster.implements_ple_like_a8=0 
cluster.vmsa.implements_fcse=0 
cluster.vmsa.main_tlb_size=512 
cluster.vmsa.main_tlb_lockable_entries=4 
cluster.vmsa.instruction_tlb_size=32 
cluster.implements_virtualization=1 
cluster.implements_lpae=1 
cluster.use_Cortex-A15_peripherals=1 
cluster.delayed_CP15_operations=1 
cluster.num_cores=1 
cluster.cpu0.implements_fused_mac=1 
cluster.cpu0.implements_sdiv_udiv=1 
cluster.cpu0.l1icache-size_bytes=32768 
cluster.cpu0.l1icache-associativity=2 
cluster.cpu0.l1icache-linelength_bytes=64 
cluster.cpu0.l1dcache-size_bytes=32768 
cluster.cpu0.l1dcache-associativity=2 
cluster.cpu0.l1dcache-linelength_bytes=64 
cluster.cpu0.l2dcache-size_bytes=0x00200000 
cluster.cpu0.l2dcache-associativity=16 
cluster.cpu0.l2dcache-linelength_bytes=64

--------------090403070505020406040906
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--------------090403070505020406040906--


From xen-devel-bounces@lists.xensource.com Fri Dec 16 18:00:01 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 18:00:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rbc4H-00088z-QN; Fri, 16 Dec 2011 17:59:37 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Huang2@amd.com>) id 1Rbc4G-00088c-No
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 17:59:36 +0000
X-Env-Sender: Wei.Huang2@amd.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1324058369!5872965!1
X-Originating-IP: [216.32.180.16]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29669 invoked from network); 16 Dec 2011 17:59:30 -0000
Received: from va3ehsobe006.messaging.microsoft.com (HELO
	VA3EHSOBE007.bigfish.com) (216.32.180.16)
	by server-6.tower-174.messagelabs.com with AES128-SHA encrypted SMTP;
	16 Dec 2011 17:59:30 -0000
Received: from mail64-va3-R.bigfish.com (10.7.14.244) by
	VA3EHSOBE007.bigfish.com (10.7.40.11) with Microsoft SMTP Server id
	14.1.225.23; Fri, 16 Dec 2011 17:59:27 +0000
Received: from mail64-va3 (localhost [127.0.0.1])	by mail64-va3-R.bigfish.com
	(Postfix) with ESMTP id 70CED2C03C3;
	Fri, 16 Dec 2011 17:59:37 +0000 (UTC)
X-SpamScore: -16
X-BigFish: VPS-16(zzbb2dI9371I328cM1432N98dKzz1202hzz8275bh8275dhz2dh668h839h61h)
X-Spam-TCS-SCL: 0:0
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
X-FB-SS: 0,
Received: from mail64-va3 (localhost.localdomain [127.0.0.1]) by mail64-va3
	(MessageSwitch) id 1324058356618689_18417;
	Fri, 16 Dec 2011 17:59:16 +0000 (UTC)
Received: from VA3EHSMHS023.bigfish.com (unknown [10.7.14.254])	by
	mail64-va3.bigfish.com (Postfix) with ESMTP id 90384100051;
	Fri, 16 Dec 2011 17:59:16 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	VA3EHSMHS023.bigfish.com (10.7.99.33) with Microsoft SMTP Server id
	14.1.225.23; Fri, 16 Dec 2011 17:59:03 +0000
X-WSS-ID: 0LWB5YD-02-ADS-02
X-M-MSG: 
Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com
	[163.181.249.73])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp02.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 27977C808C;	Fri, 16 Dec 2011 11:59:01 -0600 (CST)
Received: from sausexhtp01.amd.com (163.181.3.165) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Fri, 16 Dec 2011 11:59:23 -0600
Received: from [10.236.49.124] (10.236.49.124) by sausexhtp01.amd.com
	(163.181.3.165) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 16 Dec 2011 11:59:03 -0600
Message-ID: <4EEB86E8.3090004@amd.com>
Date: Fri, 16 Dec 2011 11:59:04 -0600
From: Wei Huang <wei.huang2@amd.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:8.0) Gecko/20111124 Thunderbird/8.0
MIME-Version: 1.0
To: Keir Fraser <keir.xen@gmail.com>
References: <CB110AD1.27676%keir.xen@gmail.com>
In-Reply-To: <CB110AD1.27676%keir.xen@gmail.com>
X-OriginatorOrg: amd.com
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH] x86: convert BUG_ON()s to WARN_ON()s in
	read_descriptor()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi Keir,

The public errata doc has been updated. You can find Erratum 700 info 
using the following steps:

1. Go to http://support.amd.com/us/psearch/Pages/psearch.aspx?type=2.7
2. Search with Product Type = "Processor", Product = "Any", Keyword = 
"Revision Guide".
3. Click on Technical Documents tab and 33610 is the one you are looking 
for.

Hope this helps...

-Wei

On 12/16/2011 08:48 AM, Keir Fraser wrote:
> On 16/12/2011 14:44, "Jan Beulich"<JBeulich@suse.com>  wrote:
>
>>>>> On 16.12.11 at 10:09, Keir Fraser<keir.xen@gmail.com>  wrote:
>>> On 15/12/2011 10:25, "Jan Beulich"<JBeulich@suse.com>  wrote:
>>>
>>>> In the light of AMD erratum #700, and given that these checks happen
>>>> for debugging purposes only and also only in debug builds of the
>>>> hypervisor, make the failures non-fatal.
>>> I think the changeset comment should have a brief description of erratum
>>> #700.
>> I'd do this, but ...
>>
>>> I also some reference should be made in a comment above the first
>>> WARN_ON, explaining why they are now WARN_Ons (again, with reference to #700
>>> and its symptoms).
>> ... I now think that these should never have been BUG_ON()s in the
>> first place (despite probably having been the one who introduced
>> them).
>>
>> Additionally, on a second look, check_descriptor() would not allow any
>> of the affected selector types to be installed into a descriptor table,
>> and we clearly don't put in any such descriptors ourselves, so from the
>> perspective of the erratum we're okay without the patch.
>>
>> So if you prefer them to stay BUG_ON(), I think I'll just withdraw the
>> patch.
> If the erratum cannot affect us then they may as well stay as BUG_ON and we
> sidestep the whole thing.
>
>   -- Keir
>
>> Jan
>>
>>> Apart from that:
>>> Acked-by: Keir Fraser<keir@xen.org>
>>>
>>>> Signed-off-by: Jan Beulich<jbeulich@suse.com>
>>>>
>>>> --- a/xen/arch/x86/traps.c
>>>> +++ b/xen/arch/x86/traps.c
>>>> @@ -1544,11 +1544,11 @@ static int read_descriptor(unsigned int
>>>>               asm volatile (
>>>>                   "larl %2,%0 ; setz %1"
>>>>                   : "=r" (a), "=qm" (valid) : "rm" (sel));
>>>> -            BUG_ON(valid&&  ((a&  0x00f0ff00) != *ar));
>>>> +            WARN_ON(valid&&  ((a&  0x00f0ff00) != *ar));
>>>>               asm volatile (
>>>>                   "lsll %2,%0 ; setz %1"
>>>>                   : "=r" (l), "=qm" (valid) : "rm" (sel));
>>>> -            BUG_ON(valid&&  (l != *limit));
>>>> +            WARN_ON(valid&&  (l != *limit));
>>>>           }
>>>>   #endif
>>>>       }
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Xen-devel mailing list
>>>> Xen-devel@lists.xensource.com
>>>> http://lists.xensource.com/xen-devel
>>
>>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 18:00:01 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 18:00:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rbc4H-00088z-QN; Fri, 16 Dec 2011 17:59:37 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Huang2@amd.com>) id 1Rbc4G-00088c-No
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 17:59:36 +0000
X-Env-Sender: Wei.Huang2@amd.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1324058369!5872965!1
X-Originating-IP: [216.32.180.16]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29669 invoked from network); 16 Dec 2011 17:59:30 -0000
Received: from va3ehsobe006.messaging.microsoft.com (HELO
	VA3EHSOBE007.bigfish.com) (216.32.180.16)
	by server-6.tower-174.messagelabs.com with AES128-SHA encrypted SMTP;
	16 Dec 2011 17:59:30 -0000
Received: from mail64-va3-R.bigfish.com (10.7.14.244) by
	VA3EHSOBE007.bigfish.com (10.7.40.11) with Microsoft SMTP Server id
	14.1.225.23; Fri, 16 Dec 2011 17:59:27 +0000
Received: from mail64-va3 (localhost [127.0.0.1])	by mail64-va3-R.bigfish.com
	(Postfix) with ESMTP id 70CED2C03C3;
	Fri, 16 Dec 2011 17:59:37 +0000 (UTC)
X-SpamScore: -16
X-BigFish: VPS-16(zzbb2dI9371I328cM1432N98dKzz1202hzz8275bh8275dhz2dh668h839h61h)
X-Spam-TCS-SCL: 0:0
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
X-FB-SS: 0,
Received: from mail64-va3 (localhost.localdomain [127.0.0.1]) by mail64-va3
	(MessageSwitch) id 1324058356618689_18417;
	Fri, 16 Dec 2011 17:59:16 +0000 (UTC)
Received: from VA3EHSMHS023.bigfish.com (unknown [10.7.14.254])	by
	mail64-va3.bigfish.com (Postfix) with ESMTP id 90384100051;
	Fri, 16 Dec 2011 17:59:16 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	VA3EHSMHS023.bigfish.com (10.7.99.33) with Microsoft SMTP Server id
	14.1.225.23; Fri, 16 Dec 2011 17:59:03 +0000
X-WSS-ID: 0LWB5YD-02-ADS-02
X-M-MSG: 
Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com
	[163.181.249.73])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp02.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 27977C808C;	Fri, 16 Dec 2011 11:59:01 -0600 (CST)
Received: from sausexhtp01.amd.com (163.181.3.165) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Fri, 16 Dec 2011 11:59:23 -0600
Received: from [10.236.49.124] (10.236.49.124) by sausexhtp01.amd.com
	(163.181.3.165) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 16 Dec 2011 11:59:03 -0600
Message-ID: <4EEB86E8.3090004@amd.com>
Date: Fri, 16 Dec 2011 11:59:04 -0600
From: Wei Huang <wei.huang2@amd.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:8.0) Gecko/20111124 Thunderbird/8.0
MIME-Version: 1.0
To: Keir Fraser <keir.xen@gmail.com>
References: <CB110AD1.27676%keir.xen@gmail.com>
In-Reply-To: <CB110AD1.27676%keir.xen@gmail.com>
X-OriginatorOrg: amd.com
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH] x86: convert BUG_ON()s to WARN_ON()s in
	read_descriptor()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi Keir,

The public errata doc has been updated. You can find Erratum 700 info 
using the following steps:

1. Go to http://support.amd.com/us/psearch/Pages/psearch.aspx?type=2.7
2. Search with Product Type = "Processor", Product = "Any", Keyword = 
"Revision Guide".
3. Click on Technical Documents tab and 33610 is the one you are looking 
for.

Hope this helps...

-Wei

On 12/16/2011 08:48 AM, Keir Fraser wrote:
> On 16/12/2011 14:44, "Jan Beulich"<JBeulich@suse.com>  wrote:
>
>>>>> On 16.12.11 at 10:09, Keir Fraser<keir.xen@gmail.com>  wrote:
>>> On 15/12/2011 10:25, "Jan Beulich"<JBeulich@suse.com>  wrote:
>>>
>>>> In the light of AMD erratum #700, and given that these checks happen
>>>> for debugging purposes only and also only in debug builds of the
>>>> hypervisor, make the failures non-fatal.
>>> I think the changeset comment should have a brief description of erratum
>>> #700.
>> I'd do this, but ...
>>
>>> I also some reference should be made in a comment above the first
>>> WARN_ON, explaining why they are now WARN_Ons (again, with reference to #700
>>> and its symptoms).
>> ... I now think that these should never have been BUG_ON()s in the
>> first place (despite probably having been the one who introduced
>> them).
>>
>> Additionally, on a second look, check_descriptor() would not allow any
>> of the affected selector types to be installed into a descriptor table,
>> and we clearly don't put in any such descriptors ourselves, so from the
>> perspective of the erratum we're okay without the patch.
>>
>> So if you prefer them to stay BUG_ON(), I think I'll just withdraw the
>> patch.
> If the erratum cannot affect us then they may as well stay as BUG_ON and we
> sidestep the whole thing.
>
>   -- Keir
>
>> Jan
>>
>>> Apart from that:
>>> Acked-by: Keir Fraser<keir@xen.org>
>>>
>>>> Signed-off-by: Jan Beulich<jbeulich@suse.com>
>>>>
>>>> --- a/xen/arch/x86/traps.c
>>>> +++ b/xen/arch/x86/traps.c
>>>> @@ -1544,11 +1544,11 @@ static int read_descriptor(unsigned int
>>>>               asm volatile (
>>>>                   "larl %2,%0 ; setz %1"
>>>>                   : "=r" (a), "=qm" (valid) : "rm" (sel));
>>>> -            BUG_ON(valid&&  ((a&  0x00f0ff00) != *ar));
>>>> +            WARN_ON(valid&&  ((a&  0x00f0ff00) != *ar));
>>>>               asm volatile (
>>>>                   "lsll %2,%0 ; setz %1"
>>>>                   : "=r" (l), "=qm" (valid) : "rm" (sel));
>>>> -            BUG_ON(valid&&  (l != *limit));
>>>> +            WARN_ON(valid&&  (l != *limit));
>>>>           }
>>>>   #endif
>>>>       }
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Xen-devel mailing list
>>>> Xen-devel@lists.xensource.com
>>>> http://lists.xensource.com/xen-devel
>>
>>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 18:02:58 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 18:02:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rbc78-0008PL-Ea; Fri, 16 Dec 2011 18:02:34 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1Rbc75-0008Oc-Ok
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 18:02:32 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1324058542!7588095!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=1.4 required=7.0 tests=BODY_RANDOM_LONG,DIET_1,
	RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9270 invoked from network); 16 Dec 2011 18:02:24 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Dec 2011 18:02:24 -0000
Received: by iagw33 with SMTP id w33so12829786iag.30
	for <xen-devel@lists.xensource.com>;
	Fri, 16 Dec 2011 10:02:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=6/RRM6+Gf153Gs7iqje/oKFOZPbVmV+fu5XRLxP1x14=;
	b=NOKoyiywvC5tFXbMoq4jxJGuoy+EwmccfbYh7Pq1Ynyr+OkWaN9WWvZxSD2Mq1aBC0
	8Ckw71Eu1p9IrUcAXWtTr7GtcfFLZrsDCNT1kYJnHbj/TXj/8QsiH09+FlCwRB4CjwHB
	heiUpV31KgBSps8jockh+2CXsyRlcUkxj/FJg=
MIME-Version: 1.0
Received: by 10.50.169.71 with SMTP id ac7mr9731555igc.18.1324058542503; Fri,
	16 Dec 2011 10:02:22 -0800 (PST)
Received: by 10.231.146.21 with HTTP; Fri, 16 Dec 2011 10:02:22 -0800 (PST)
In-Reply-To: <1324054424.2599.13.camel@Solace>
References: <1324054424.2599.13.camel@Solace>
Date: Fri, 16 Dec 2011 18:02:22 +0000
X-Google-Sender-Auth: Dzta4qoiK3hU4CzjcW4ZdC4BEEw
Message-ID: <CAFLBxZbaGiOV-2rBiKZxe6vfLYeG9F1Qer4SoZ945uMzrn6NOQ@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Dario Faggioli <raistlin@linux.it>
Cc: Juergen Gross <juergen.gross@ts.fujitsu.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCHv2] Rework locking for sched_adjust.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Acked-by: George Dunlap <george.dunlap@eu.citrix.com>

On Fri, Dec 16, 2011 at 4:53 PM, Dario Faggioli <raistlin@linux.it> wrote:
> [Re-posting as the patch was damaged in the previous message]
>
> Hi everyone,
>
> Here it is v2 of the lock reworking around and within sched-adjust.
>
> With respect to the first posting [1]:
> =A0- I _did_not_ move the per-pluggable scheduler lock toward schedule.c,
> =A0 as agreed with George during review;
> =A0- I fixed the bug in sedf spotted by Juergen the way he suggested;
> =A0- I've finally been able to test it under all the three schedulers,
> =A0 and it is doing its job, at least here;
>
> Notice the series "collapsed" in one signle patch, as it was being hard
> to find a breakdown of it that does not introduce regressions and/or
> transient deadlock situations worse than the ones it's trying to cure...
> I hope it's still readable and comfortable to review. :-)
>
> Thanks to everyone who provided his feedback on the first version of
> this.
>
> Regards,
> Dario
>
> [1]
> http://xen.1045712.n5.nabble.com/RFC-RFT-PATCH-0-of-3-rework-locking-in-s=
ched-adjust-td5016899.html
>
> --
> =A0xen/common/sched_credit.c =A0| =A0 10 ++++++--
> =A0xen/common/sched_credit2.c | =A0 21 ++++++++++---------
> =A0xen/common/sched_sedf.c =A0 =A0| =A0156
> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++=
++++++++++++++++++++++++++++++++++++++++++++++-----------------------------=
------
> =A0xen/common/schedule.c =A0 =A0 =A0| =A0 34 +---------------------------=
----
> =A04 files changed, 140 insertions(+), 81 deletions(-)
>
> --
>
> # HG changeset patch
> # Parent 1452fb248cd513832cfbbd1100b9b72a0dde7ea6
> Rework locking for sched_adjust.
>
> The main idea is to move (as much as possible) locking logic
> from generic code to the various pluggable schedulers.
>
> While at it, the following is also accomplished:
> =A0- pausing all the non-current VCPUs of a domain while changing its
> =A0 scheduling parameters is not effective in avoiding races and it is
> =A0 prone to deadlock, so that is removed.
> =A0- sedf needs a global lock for preventing races while adjusting
> =A0 domains' scheduling parameters (as it is for credit and credit2),
> =A0 so that is added.
>
> Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
>
> diff -r 1452fb248cd5 xen/common/sched_credit.c
> --- a/xen/common/sched_credit.c Fri Dec 16 15:45:40 2011 +0100
> +++ b/xen/common/sched_credit.c Fri Dec 16 17:49:46 2011 +0100
> @@ -161,6 +161,7 @@ struct csched_dom {
> =A0* System-wide private data
> =A0*/
> =A0struct csched_private {
> + =A0 =A0/* lock for the whole pluggable scheduler, nests inside cpupool_=
lock */
> =A0 =A0 spinlock_t lock;
> =A0 =A0 struct list_head active_sdom;
> =A0 =A0 uint32_t ncpus;
> @@ -800,6 +801,10 @@ csched_dom_cntl(
> =A0 =A0 struct csched_private *prv =3D CSCHED_PRIV(ops);
> =A0 =A0 unsigned long flags;
>
> + =A0 =A0/* Protect both get and put branches with the pluggable scheduler
> + =A0 =A0 * lock. Runq lock not needed anywhere in here. */
> + =A0 =A0spin_lock_irqsave(&prv->lock, flags);
> +
> =A0 =A0 if ( op->cmd =3D=3D XEN_DOMCTL_SCHEDOP_getinfo )
> =A0 =A0 {
> =A0 =A0 =A0 =A0 op->u.credit.weight =3D sdom->weight;
> @@ -809,8 +814,6 @@ csched_dom_cntl(
> =A0 =A0 {
> =A0 =A0 =A0 =A0 ASSERT(op->cmd =3D=3D XEN_DOMCTL_SCHEDOP_putinfo);
>
> - =A0 =A0 =A0 =A0spin_lock_irqsave(&prv->lock, flags);
> -
> =A0 =A0 =A0 =A0 if ( op->u.credit.weight !=3D 0 )
> =A0 =A0 =A0 =A0 {
> =A0 =A0 =A0 =A0 =A0 =A0 if ( !list_empty(&sdom->active_sdom_elem) )
> @@ -824,9 +827,10 @@ csched_dom_cntl(
> =A0 =A0 =A0 =A0 if ( op->u.credit.cap !=3D (uint16_t)~0U )
> =A0 =A0 =A0 =A0 =A0 =A0 sdom->cap =3D op->u.credit.cap;
>
> - =A0 =A0 =A0 =A0spin_unlock_irqrestore(&prv->lock, flags);
> =A0 =A0 }
>
> + =A0 =A0spin_unlock_irqrestore(&prv->lock, flags);
> +
> =A0 =A0 return 0;
> =A0}
>
> diff -r 1452fb248cd5 xen/common/sched_credit2.c
> --- a/xen/common/sched_credit2.c =A0 =A0 =A0 =A0Fri Dec 16 15:45:40 2011 =
+0100
> +++ b/xen/common/sched_credit2.c =A0 =A0 =A0 =A0Fri Dec 16 17:49:46 2011 =
+0100
> @@ -1384,6 +1384,10 @@ csched_dom_cntl(
> =A0 =A0 struct csched_private *prv =3D CSCHED_PRIV(ops);
> =A0 =A0 unsigned long flags;
>
> + =A0 =A0/* Must hold csched_priv lock to read and update sdom,
> + =A0 =A0 * runq lock to update csvcs. */
> + =A0 =A0spin_lock_irqsave(&prv->lock, flags);
> +
> =A0 =A0 if ( op->cmd =3D=3D XEN_DOMCTL_SCHEDOP_getinfo )
> =A0 =A0 {
> =A0 =A0 =A0 =A0 op->u.credit2.weight =3D sdom->weight;
> @@ -1397,10 +1401,6 @@ csched_dom_cntl(
> =A0 =A0 =A0 =A0 =A0 =A0 struct list_head *iter;
> =A0 =A0 =A0 =A0 =A0 =A0 int old_weight;
>
> - =A0 =A0 =A0 =A0 =A0 =A0/* Must hold csched_priv lock to update sdom, ru=
nq lock to
> - =A0 =A0 =A0 =A0 =A0 =A0 * update csvcs. */
> - =A0 =A0 =A0 =A0 =A0 =A0spin_lock_irqsave(&prv->lock, flags);
> -
> =A0 =A0 =A0 =A0 =A0 =A0 old_weight =3D sdom->weight;
>
> =A0 =A0 =A0 =A0 =A0 =A0 sdom->weight =3D op->u.credit2.weight;
> @@ -1411,22 +1411,23 @@ csched_dom_cntl(
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 struct csched_vcpu *svc =3D list_entry(it=
er, struct csched_vcpu, sdom_elem);
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* NB: Locking order is important here. =
=A0Because we grab this lock here, we
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 * must never lock csched_priv.lock if w=
e're holding a runqueue
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 * lock. */
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0vcpu_schedule_lock_irq(svc->vcpu);
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 * must never lock csched_priv.lock if w=
e're holding a runqueue lock.
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 * Also, calling vcpu_schedule_lock() is=
 enough, since IRQs have already
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 * been disabled. */
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0vcpu_schedule_lock(svc->vcpu);
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 BUG_ON(svc->rqd !=3D RQD(ops, svc->vcpu->=
processor));
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 svc->weight =3D sdom->weight;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 update_max_weight(svc->rqd, svc->weight, =
old_weight);
>
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0vcpu_schedule_unlock_irq(svc->vcpu);
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0vcpu_schedule_unlock(svc->vcpu);
> =A0 =A0 =A0 =A0 =A0 =A0 }
> -
> - =A0 =A0 =A0 =A0 =A0 =A0spin_unlock_irqrestore(&prv->lock, flags);
> =A0 =A0 =A0 =A0 }
> =A0 =A0 }
>
> + =A0 =A0spin_unlock_irqrestore(&prv->lock, flags);
> +
> =A0 =A0 return 0;
> =A0}
>
> diff -r 1452fb248cd5 xen/common/sched_sedf.c
> --- a/xen/common/sched_sedf.c =A0 Fri Dec 16 15:45:40 2011 +0100
> +++ b/xen/common/sched_sedf.c =A0 Fri Dec 16 17:49:46 2011 +0100
> @@ -61,6 +61,11 @@ struct sedf_dom_info {
> =A0 =A0 struct domain =A0*domain;
> =A0};
>
> +struct sedf_priv_info {
> + =A0 =A0/* lock for the whole pluggable scheduler, nests inside cpupool_=
lock */
> + =A0 =A0spinlock_t lock;
> +};
> +
> =A0struct sedf_vcpu_info {
> =A0 =A0 struct vcpu *vcpu;
> =A0 =A0 struct list_head list;
> @@ -115,6 +120,8 @@ struct sedf_cpu_info {
> =A0 =A0 s_time_t =A0 =A0 =A0 =A0 current_slice_expires;
> =A0};
>
> +#define SEDF_PRIV(_ops) \
> + =A0 =A0((struct sedf_priv_info *)((_ops)->sched_data))
> =A0#define EDOM_INFO(d) =A0 ((struct sedf_vcpu_info *)((d)->sched_priv))
> =A0#define CPU_INFO(cpu) =A0\
> =A0 =A0 ((struct sedf_cpu_info *)per_cpu(schedule_data, cpu).sched_priv)
> @@ -772,6 +779,31 @@ static struct task_slice sedf_do_extra_s
> =A0}
>
>
> +static int sedf_init(struct scheduler *ops)
> +{
> + =A0 =A0struct sedf_priv_info *prv;
> +
> + =A0 =A0prv =3D xzalloc(struct sedf_priv_info);
> + =A0 =A0if ( prv =3D=3D NULL )
> + =A0 =A0 =A0 =A0return -ENOMEM;
> +
> + =A0 =A0ops->sched_data =3D prv;
> + =A0 =A0spin_lock_init(&prv->lock);
> +
> + =A0 =A0return 0;
> +}
> +
> +
> +static void sedf_deinit(const struct scheduler *ops)
> +{
> + =A0 =A0struct sedf_priv_info *prv;
> +
> + =A0 =A0prv =3D SEDF_PRIV(ops);
> + =A0 =A0if ( prv !=3D NULL )
> + =A0 =A0 =A0 =A0xfree(prv);
> +}
> +
> +
> =A0/* Main scheduling function
> =A0 =A0Reasons for calling this function are:
> =A0 =A0-timeslice for the current period used up
> @@ -1320,22 +1352,15 @@ static void sedf_dump_cpu_state(const st
>
>
> =A0/* Adjusts periods and slices of the domains accordingly to their weig=
hts. */
> -static int sedf_adjust_weights(struct cpupool *c, struct xen_domctl_sche=
duler_op *cmd)
> +static int sedf_adjust_weights(struct cpupool *c, int nr_cpus, int *sumw=
, s_time_t *sumt)
> =A0{
> =A0 =A0 struct vcpu *p;
> =A0 =A0 struct domain =A0 =A0 =A0*d;
> - =A0 =A0unsigned int =A0 =A0 =A0 =A0cpu, nr_cpus =3D cpumask_last(&cpu_o=
nline_map) + 1;
> - =A0 =A0int =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0*sumw =3D xzalloc_array(int, =
nr_cpus);
> - =A0 =A0s_time_t =A0 =A0 =A0 =A0 =A0 *sumt =3D xzalloc_array(s_time_t, n=
r_cpus);
> + =A0 =A0unsigned int =A0 =A0 =A0 =A0cpu;
>
> - =A0 =A0if ( !sumw || !sumt )
> - =A0 =A0{
> - =A0 =A0 =A0 =A0xfree(sumt);
> - =A0 =A0 =A0 =A0xfree(sumw);
> - =A0 =A0 =A0 =A0return -ENOMEM;
> - =A0 =A0}
> -
> - =A0 =A0/* Sum across all weights. */
> + =A0 =A0/* Sum across all weights. Notice that no runq locking is needed
> + =A0 =A0 * here: the caller holds sedf_priv_info.lock and we're not chan=
ging
> + =A0 =A0 * anything that is accessed during scheduling. */
> =A0 =A0 rcu_read_lock(&domlist_read_lock);
> =A0 =A0 for_each_domain_in_cpupool( d, c )
> =A0 =A0 {
> @@ -1365,7 +1390,9 @@ static int sedf_adjust_weights(struct cp
> =A0 =A0 }
> =A0 =A0 rcu_read_unlock(&domlist_read_lock);
>
> - =A0 =A0/* Adjust all slices (and periods) to the new weight. */
> + =A0 =A0/* Adjust all slices (and periods) to the new weight. Unlike abo=
ve, we
> + =A0 =A0 * need to take thr runq lock for the various VCPUs: we're modyf=
ing
> + =A0 =A0 * slice and period which are referenced during scheduling. */
> =A0 =A0 rcu_read_lock(&domlist_read_lock);
> =A0 =A0 for_each_domain_in_cpupool( d, c )
> =A0 =A0 {
> @@ -1375,20 +1402,20 @@ static int sedf_adjust_weights(struct cp
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 continue;
> =A0 =A0 =A0 =A0 =A0 =A0 if ( EDOM_INFO(p)->weight )
> =A0 =A0 =A0 =A0 =A0 =A0 {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/* Interrupts already off */
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0vcpu_schedule_lock(p);
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 EDOM_INFO(p)->period_orig =3D
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 EDOM_INFO(p)->period =A0=3D WEIGH=
T_PERIOD;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 EDOM_INFO(p)->slice_orig =A0=3D
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 EDOM_INFO(p)->slice =A0 =3D
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (EDOM_INFO(p)->weight *
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(WEIGHT_PERIOD - WEIGHT_SAFETY=
 - sumt[cpu])) / sumw[cpu];
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0vcpu_schedule_unlock(p);
> =A0 =A0 =A0 =A0 =A0 =A0 }
> =A0 =A0 =A0 =A0 }
> =A0 =A0 }
> =A0 =A0 rcu_read_unlock(&domlist_read_lock);
>
> - =A0 =A0xfree(sumt);
> - =A0 =A0xfree(sumw);
> -
> =A0 =A0 return 0;
> =A0}
>
> @@ -1396,19 +1423,45 @@ static int sedf_adjust_weights(struct cp
> =A0/* set or fetch domain scheduling parameters */
> =A0static int sedf_adjust(const struct scheduler *ops, struct domain *p, =
struct xen_domctl_scheduler_op *op)
> =A0{
> + =A0 =A0struct sedf_priv_info *prv =3D SEDF_PRIV(ops);
> + =A0 =A0unsigned long flags;
> + =A0 =A0unsigned int nr_cpus =3D cpumask_last(&cpu_online_map) + 1;
> + =A0 =A0int *sumw =3D xzalloc_array(int, nr_cpus);
> + =A0 =A0s_time_t *sumt =3D xzalloc_array(s_time_t, nr_cpus);
> =A0 =A0 struct vcpu *v;
> - =A0 =A0int rc;
> + =A0 =A0int rc =3D 0;
>
> =A0 =A0 PRINT(2,"sedf_adjust was called, domain-id %i new period %"PRIu64=
" "
> =A0 =A0 =A0 =A0 =A0 "new slice %"PRIu64"\nlatency %"PRIu64" extra:%s\n",
> =A0 =A0 =A0 =A0 =A0 p->domain_id, op->u.sedf.period, op->u.sedf.slice,
> =A0 =A0 =A0 =A0 =A0 op->u.sedf.latency, (op->u.sedf.extratime)?"yes":"no"=
);
>
> + =A0 =A0/* Serialize against the pluggable scheduler lock to protect from
> + =A0 =A0 * concurrent updates. We need to take the runq lock for the VCP=
Us
> + =A0 =A0 * as well, since we are touching extraweight, weight, slice and
> + =A0 =A0 * period. As in sched_credit2.c, runq locks nest inside the
> + =A0 =A0 * pluggable scheduler lock. */
> + =A0 =A0spin_lock_irqsave(&prv->lock, flags);
> +
> =A0 =A0 if ( op->cmd =3D=3D XEN_DOMCTL_SCHEDOP_putinfo )
> =A0 =A0 {
> + =A0 =A0 =A0 =A0/* These are used in sedf_adjust_weights() but have to b=
e allocated in
> + =A0 =A0 =A0 =A0 * this function, as we need to avoid nesting xmem_pool_=
alloc's lock
> + =A0 =A0 =A0 =A0 * within our prv->lock. */
> + =A0 =A0 =A0 =A0if ( !sumw || !sumt )
> + =A0 =A0 =A0 =A0{
> + =A0 =A0 =A0 =A0 =A0 =A0/* Check for errors here, the _getinfo branch do=
esn't care */
> + =A0 =A0 =A0 =A0 =A0 =A0rc =3D -ENOMEM;
> + =A0 =A0 =A0 =A0 =A0 =A0goto out;
> + =A0 =A0 =A0 =A0}
> +
> =A0 =A0 =A0 =A0 /* Check for sane parameters. */
> =A0 =A0 =A0 =A0 if ( !op->u.sedf.period && !op->u.sedf.weight )
> - =A0 =A0 =A0 =A0 =A0 =A0return -EINVAL;
> + =A0 =A0 =A0 =A0{
> + =A0 =A0 =A0 =A0 =A0 =A0rc =3D -EINVAL;
> + =A0 =A0 =A0 =A0 =A0 =A0goto out;
> + =A0 =A0 =A0 =A0}
> +
> =A0 =A0 =A0 =A0 if ( op->u.sedf.weight )
> =A0 =A0 =A0 =A0 {
> =A0 =A0 =A0 =A0 =A0 =A0 if ( (op->u.sedf.extratime & EXTRA_AWARE) &&
> @@ -1417,59 +1470,78 @@ static int sedf_adjust(const struct sche
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* Weight-driven domains with extratime o=
nly. */
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 for_each_vcpu ( p, v )
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/* (Here and everywhere in the f=
ollowing) IRQs are already off,
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 * hence vcpu_spin_lock() is the=
 one. */
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0vcpu_schedule_lock(v);
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 EDOM_INFO(v)->extraweight =3D op-=
>u.sedf.weight;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 EDOM_INFO(v)->weight =3D 0;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 EDOM_INFO(v)->slice =3D 0;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 EDOM_INFO(v)->period =3D WEIGHT_P=
ERIOD;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0vcpu_schedule_unlock(v);
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 }
> =A0 =A0 =A0 =A0 =A0 =A0 }
> =A0 =A0 =A0 =A0 =A0 =A0 else
> =A0 =A0 =A0 =A0 =A0 =A0 {
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* Weight-driven domains with real-time e=
xecution. */
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0for_each_vcpu ( p, v )
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0for_each_vcpu ( p, v ) {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0vcpu_schedule_lock(v);
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 EDOM_INFO(v)->weight =3D op->u.se=
df.weight;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0vcpu_schedule_unlock(v);
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0}
> =A0 =A0 =A0 =A0 =A0 =A0 }
> =A0 =A0 =A0 =A0 }
> =A0 =A0 =A0 =A0 else
> =A0 =A0 =A0 =A0 {
> + =A0 =A0 =A0 =A0 =A0 =A0/*
> + =A0 =A0 =A0 =A0 =A0 =A0 * Sanity checking: note that disabling extra we=
ight requires
> + =A0 =A0 =A0 =A0 =A0 =A0 * that we set a non-zero slice.
> + =A0 =A0 =A0 =A0 =A0 =A0 */
> + =A0 =A0 =A0 =A0 =A0 =A0if ( (op->u.sedf.period > PERIOD_MAX) ||
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (op->u.sedf.period < PERIOD_MIN) ||
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (op->u.sedf.slice =A0> op->u.sedf.perio=
d) ||
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (op->u.sedf.slice =A0< SLICE_MIN) )
> + =A0 =A0 =A0 =A0 =A0 =A0{
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0rc =3D -EINVAL;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0goto out;
> + =A0 =A0 =A0 =A0 =A0 =A0}
> +
> =A0 =A0 =A0 =A0 =A0 =A0 /* Time-driven domains. */
> =A0 =A0 =A0 =A0 =A0 =A0 for_each_vcpu ( p, v )
> =A0 =A0 =A0 =A0 =A0 =A0 {
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/*
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 * Sanity checking: note that disabling =
extra weight requires
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 * that we set a non-zero slice.
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 */
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if ( (op->u.sedf.period > PERIOD_MAX) ||
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (op->u.sedf.period < PERIOD_MIN=
) ||
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (op->u.sedf.slice =A0> op->u.se=
df.period) ||
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (op->u.sedf.slice =A0< SLICE_MI=
N) )
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0return -EINVAL;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0vcpu_schedule_lock(v);
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 EDOM_INFO(v)->weight =3D 0;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 EDOM_INFO(v)->extraweight =3D 0;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 EDOM_INFO(v)->period_orig =3D
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 EDOM_INFO(v)->period =A0=3D op->u=
.sedf.period;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 EDOM_INFO(v)->slice_orig =A0=3D
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 EDOM_INFO(v)->slice =A0 =3D op->u=
.sedf.slice;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0vcpu_schedule_unlock(v);
> =A0 =A0 =A0 =A0 =A0 =A0 }
> =A0 =A0 =A0 =A0 }
>
> - =A0 =A0 =A0 =A0rc =3D sedf_adjust_weights(p->cpupool, op);
> + =A0 =A0 =A0 =A0rc =3D sedf_adjust_weights(p->cpupool, nr_cpus, sumw, su=
mt);
> =A0 =A0 =A0 =A0 if ( rc )
> - =A0 =A0 =A0 =A0 =A0 =A0return rc;
> + =A0 =A0 =A0 =A0 =A0 =A0goto out;
>
> =A0 =A0 =A0 =A0 for_each_vcpu ( p, v )
> =A0 =A0 =A0 =A0 {
> + =A0 =A0 =A0 =A0 =A0 =A0vcpu_schedule_lock(v);
> =A0 =A0 =A0 =A0 =A0 =A0 EDOM_INFO(v)->status =A0=3D
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (EDOM_INFO(v)->status &
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0~EXTRA_AWARE) | (op->u.sedf.extratime =
& EXTRA_AWARE);
> =A0 =A0 =A0 =A0 =A0 =A0 EDOM_INFO(v)->latency =3D op->u.sedf.latency;
> =A0 =A0 =A0 =A0 =A0 =A0 extraq_check(v);
> + =A0 =A0 =A0 =A0 =A0 =A0vcpu_schedule_unlock(v);
> =A0 =A0 =A0 =A0 }
> =A0 =A0 }
> =A0 =A0 else if ( op->cmd =3D=3D XEN_DOMCTL_SCHEDOP_getinfo )
> =A0 =A0 {
> =A0 =A0 =A0 =A0 if ( p->vcpu[0] =3D=3D NULL )
> - =A0 =A0 =A0 =A0 =A0 =A0return -EINVAL;
> + =A0 =A0 =A0 =A0{
> + =A0 =A0 =A0 =A0 =A0 =A0rc =3D -EINVAL;
> + =A0 =A0 =A0 =A0 =A0 =A0goto out;
> + =A0 =A0 =A0 =A0}
> +
> =A0 =A0 =A0 =A0 op->u.sedf.period =A0 =A0=3D EDOM_INFO(p->vcpu[0])->perio=
d;
> =A0 =A0 =A0 =A0 op->u.sedf.slice =A0 =A0 =3D EDOM_INFO(p->vcpu[0])->slice;
> =A0 =A0 =A0 =A0 op->u.sedf.extratime =3D EDOM_INFO(p->vcpu[0])->status & =
EXTRA_AWARE;
> @@ -1477,14 +1549,23 @@ static int sedf_adjust(const struct sche
> =A0 =A0 =A0 =A0 op->u.sedf.weight =A0 =A0=3D EDOM_INFO(p->vcpu[0])->weigh=
t;
> =A0 =A0 }
>
> - =A0 =A0PRINT(2,"sedf_adjust_finished\n");
> - =A0 =A0return 0;
> +out:
> + =A0 =A0spin_unlock_irqrestore(&prv->lock, flags);
> +
> + =A0 =A0xfree(sumt);
> + =A0 =A0xfree(sumw);
> +
> + =A0 =A0PRINT(2,"sedf_adjust_finished with return code %d\n", rc);
> + =A0 =A0return rc;
> =A0}
>
> +static struct sedf_priv_info _sedf_priv;
> +
> =A0const struct scheduler sched_sedf_def =3D {
> - =A0 =A0.name =A0 =A0 =3D "Simple EDF Scheduler",
> - =A0 =A0.opt_name =3D "sedf",
> - =A0 =A0.sched_id =3D XEN_SCHEDULER_SEDF,
> + =A0 =A0.name =A0 =A0 =A0 =A0 =A0 =3D "Simple EDF Scheduler",
> + =A0 =A0.opt_name =A0 =A0 =A0 =3D "sedf",
> + =A0 =A0.sched_id =A0 =A0 =A0 =3D XEN_SCHEDULER_SEDF,
> + =A0 =A0.sched_data =A0 =A0 =3D &_sedf_priv,
>
> =A0 =A0 .init_domain =A0 =A0=3D sedf_init_domain,
> =A0 =A0 .destroy_domain =3D sedf_destroy_domain,
> @@ -1498,6 +1579,9 @@ const struct scheduler sched_sedf_def =3D
> =A0 =A0 .alloc_domdata =A0=3D sedf_alloc_domdata,
> =A0 =A0 .free_domdata =A0 =3D sedf_free_domdata,
>
> + =A0 =A0.init =A0 =A0 =A0 =A0 =A0 =3D sedf_init,
> + =A0 =A0.deinit =A0 =A0 =A0 =A0 =3D sedf_deinit,
> +
> =A0 =A0 .do_schedule =A0 =A0=3D sedf_do_schedule,
> =A0 =A0 .pick_cpu =A0 =A0 =A0 =3D sedf_pick_cpu,
> =A0 =A0 .dump_cpu_state =3D sedf_dump_cpu_state,
> diff -r 1452fb248cd5 xen/common/schedule.c
> --- a/xen/common/schedule.c =A0 =A0 Fri Dec 16 15:45:40 2011 +0100
> +++ b/xen/common/schedule.c =A0 =A0 Fri Dec 16 17:49:46 2011 +0100
> @@ -1005,7 +1005,6 @@ int sched_id(void)
> =A0/* Adjust scheduling parameter for a given domain. */
> =A0long sched_adjust(struct domain *d, struct xen_domctl_scheduler_op *op)
> =A0{
> - =A0 =A0struct vcpu *v;
> =A0 =A0 long ret;
>
> =A0 =A0 if ( (op->sched_id !=3D DOM2OP(d)->sched_id) ||
> @@ -1013,40 +1012,11 @@ long sched_adjust(struct domain *d, stru
> =A0 =A0 =A0 =A0 =A0 (op->cmd !=3D XEN_DOMCTL_SCHEDOP_getinfo)) )
> =A0 =A0 =A0 =A0 return -EINVAL;
>
> - =A0 =A0/*
> - =A0 =A0 * Most VCPUs we can simply pause. If we are adjusting this VCPU=
 then
> - =A0 =A0 * we acquire the local schedule_lock to guard against concurren=
t updates.
> - =A0 =A0 *
> - =A0 =A0 * We only acquire the local schedule lock after we have paused =
all other
> - =A0 =A0 * VCPUs in this domain. There are two reasons for this:
> - =A0 =A0 * 1- We don't want to hold up interrupts as pausing a VCPU can
> - =A0 =A0 * =A0 =A0trigger a tlb shootdown.
> - =A0 =A0 * 2- Pausing other VCPUs involves briefly locking the schedule
> - =A0 =A0 * =A0 =A0lock of the CPU they are running on. This CPU could be=
 the
> - =A0 =A0 * =A0 =A0same as ours.
> - =A0 =A0 */
> -
> - =A0 =A0for_each_vcpu ( d, v )
> - =A0 =A0{
> - =A0 =A0 =A0 =A0if ( v !=3D current )
> - =A0 =A0 =A0 =A0 =A0 =A0vcpu_pause(v);
> - =A0 =A0}
> -
> - =A0 =A0if ( d =3D=3D current->domain )
> - =A0 =A0 =A0 =A0vcpu_schedule_lock_irq(current);
> -
> + =A0 =A0/* NB: the pluggable scheduler code needs to take care
> + =A0 =A0 * of locking by itself. */
> =A0 =A0 if ( (ret =3D SCHED_OP(DOM2OP(d), adjust, d, op)) =3D=3D 0 )
> =A0 =A0 =A0 =A0 TRACE_1D(TRC_SCHED_ADJDOM, d->domain_id);
>
> - =A0 =A0if ( d =3D=3D current->domain )
> - =A0 =A0 =A0 =A0vcpu_schedule_unlock_irq(current);
> -
> - =A0 =A0for_each_vcpu ( d, v )
> - =A0 =A0{
> - =A0 =A0 =A0 =A0if ( v !=3D current )
> - =A0 =A0 =A0 =A0 =A0 =A0vcpu_unpause(v);
> - =A0 =A0}
> -
> =A0 =A0 return ret;
> =A0}
>
> --
> <<This happens because I choose it to happen!>> (Raistlin Majere)
> -------------------------------------------------------------------
> Dario Faggioli, http://retis.sssup.it/people/faggioli
> Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
> PhD Candidate, ReTiS Lab, Scuola Superiore Sant'Anna, Pisa (Italy)
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 18:02:58 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 18:02:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rbc78-0008PL-Ea; Fri, 16 Dec 2011 18:02:34 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1Rbc75-0008Oc-Ok
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 18:02:32 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1324058542!7588095!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=1.4 required=7.0 tests=BODY_RANDOM_LONG,DIET_1,
	RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9270 invoked from network); 16 Dec 2011 18:02:24 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Dec 2011 18:02:24 -0000
Received: by iagw33 with SMTP id w33so12829786iag.30
	for <xen-devel@lists.xensource.com>;
	Fri, 16 Dec 2011 10:02:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=6/RRM6+Gf153Gs7iqje/oKFOZPbVmV+fu5XRLxP1x14=;
	b=NOKoyiywvC5tFXbMoq4jxJGuoy+EwmccfbYh7Pq1Ynyr+OkWaN9WWvZxSD2Mq1aBC0
	8Ckw71Eu1p9IrUcAXWtTr7GtcfFLZrsDCNT1kYJnHbj/TXj/8QsiH09+FlCwRB4CjwHB
	heiUpV31KgBSps8jockh+2CXsyRlcUkxj/FJg=
MIME-Version: 1.0
Received: by 10.50.169.71 with SMTP id ac7mr9731555igc.18.1324058542503; Fri,
	16 Dec 2011 10:02:22 -0800 (PST)
Received: by 10.231.146.21 with HTTP; Fri, 16 Dec 2011 10:02:22 -0800 (PST)
In-Reply-To: <1324054424.2599.13.camel@Solace>
References: <1324054424.2599.13.camel@Solace>
Date: Fri, 16 Dec 2011 18:02:22 +0000
X-Google-Sender-Auth: Dzta4qoiK3hU4CzjcW4ZdC4BEEw
Message-ID: <CAFLBxZbaGiOV-2rBiKZxe6vfLYeG9F1Qer4SoZ945uMzrn6NOQ@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Dario Faggioli <raistlin@linux.it>
Cc: Juergen Gross <juergen.gross@ts.fujitsu.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCHv2] Rework locking for sched_adjust.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Acked-by: George Dunlap <george.dunlap@eu.citrix.com>

On Fri, Dec 16, 2011 at 4:53 PM, Dario Faggioli <raistlin@linux.it> wrote:
> [Re-posting as the patch was damaged in the previous message]
>
> Hi everyone,
>
> Here it is v2 of the lock reworking around and within sched-adjust.
>
> With respect to the first posting [1]:
> =A0- I _did_not_ move the per-pluggable scheduler lock toward schedule.c,
> =A0 as agreed with George during review;
> =A0- I fixed the bug in sedf spotted by Juergen the way he suggested;
> =A0- I've finally been able to test it under all the three schedulers,
> =A0 and it is doing its job, at least here;
>
> Notice the series "collapsed" in one signle patch, as it was being hard
> to find a breakdown of it that does not introduce regressions and/or
> transient deadlock situations worse than the ones it's trying to cure...
> I hope it's still readable and comfortable to review. :-)
>
> Thanks to everyone who provided his feedback on the first version of
> this.
>
> Regards,
> Dario
>
> [1]
> http://xen.1045712.n5.nabble.com/RFC-RFT-PATCH-0-of-3-rework-locking-in-s=
ched-adjust-td5016899.html
>
> --
> =A0xen/common/sched_credit.c =A0| =A0 10 ++++++--
> =A0xen/common/sched_credit2.c | =A0 21 ++++++++++---------
> =A0xen/common/sched_sedf.c =A0 =A0| =A0156
> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++=
++++++++++++++++++++++++++++++++++++++++++++++-----------------------------=
------
> =A0xen/common/schedule.c =A0 =A0 =A0| =A0 34 +---------------------------=
----
> =A04 files changed, 140 insertions(+), 81 deletions(-)
>
> --
>
> # HG changeset patch
> # Parent 1452fb248cd513832cfbbd1100b9b72a0dde7ea6
> Rework locking for sched_adjust.
>
> The main idea is to move (as much as possible) locking logic
> from generic code to the various pluggable schedulers.
>
> While at it, the following is also accomplished:
> =A0- pausing all the non-current VCPUs of a domain while changing its
> =A0 scheduling parameters is not effective in avoiding races and it is
> =A0 prone to deadlock, so that is removed.
> =A0- sedf needs a global lock for preventing races while adjusting
> =A0 domains' scheduling parameters (as it is for credit and credit2),
> =A0 so that is added.
>
> Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
>
> diff -r 1452fb248cd5 xen/common/sched_credit.c
> --- a/xen/common/sched_credit.c Fri Dec 16 15:45:40 2011 +0100
> +++ b/xen/common/sched_credit.c Fri Dec 16 17:49:46 2011 +0100
> @@ -161,6 +161,7 @@ struct csched_dom {
> =A0* System-wide private data
> =A0*/
> =A0struct csched_private {
> + =A0 =A0/* lock for the whole pluggable scheduler, nests inside cpupool_=
lock */
> =A0 =A0 spinlock_t lock;
> =A0 =A0 struct list_head active_sdom;
> =A0 =A0 uint32_t ncpus;
> @@ -800,6 +801,10 @@ csched_dom_cntl(
> =A0 =A0 struct csched_private *prv =3D CSCHED_PRIV(ops);
> =A0 =A0 unsigned long flags;
>
> + =A0 =A0/* Protect both get and put branches with the pluggable scheduler
> + =A0 =A0 * lock. Runq lock not needed anywhere in here. */
> + =A0 =A0spin_lock_irqsave(&prv->lock, flags);
> +
> =A0 =A0 if ( op->cmd =3D=3D XEN_DOMCTL_SCHEDOP_getinfo )
> =A0 =A0 {
> =A0 =A0 =A0 =A0 op->u.credit.weight =3D sdom->weight;
> @@ -809,8 +814,6 @@ csched_dom_cntl(
> =A0 =A0 {
> =A0 =A0 =A0 =A0 ASSERT(op->cmd =3D=3D XEN_DOMCTL_SCHEDOP_putinfo);
>
> - =A0 =A0 =A0 =A0spin_lock_irqsave(&prv->lock, flags);
> -
> =A0 =A0 =A0 =A0 if ( op->u.credit.weight !=3D 0 )
> =A0 =A0 =A0 =A0 {
> =A0 =A0 =A0 =A0 =A0 =A0 if ( !list_empty(&sdom->active_sdom_elem) )
> @@ -824,9 +827,10 @@ csched_dom_cntl(
> =A0 =A0 =A0 =A0 if ( op->u.credit.cap !=3D (uint16_t)~0U )
> =A0 =A0 =A0 =A0 =A0 =A0 sdom->cap =3D op->u.credit.cap;
>
> - =A0 =A0 =A0 =A0spin_unlock_irqrestore(&prv->lock, flags);
> =A0 =A0 }
>
> + =A0 =A0spin_unlock_irqrestore(&prv->lock, flags);
> +
> =A0 =A0 return 0;
> =A0}
>
> diff -r 1452fb248cd5 xen/common/sched_credit2.c
> --- a/xen/common/sched_credit2.c =A0 =A0 =A0 =A0Fri Dec 16 15:45:40 2011 =
+0100
> +++ b/xen/common/sched_credit2.c =A0 =A0 =A0 =A0Fri Dec 16 17:49:46 2011 =
+0100
> @@ -1384,6 +1384,10 @@ csched_dom_cntl(
> =A0 =A0 struct csched_private *prv =3D CSCHED_PRIV(ops);
> =A0 =A0 unsigned long flags;
>
> + =A0 =A0/* Must hold csched_priv lock to read and update sdom,
> + =A0 =A0 * runq lock to update csvcs. */
> + =A0 =A0spin_lock_irqsave(&prv->lock, flags);
> +
> =A0 =A0 if ( op->cmd =3D=3D XEN_DOMCTL_SCHEDOP_getinfo )
> =A0 =A0 {
> =A0 =A0 =A0 =A0 op->u.credit2.weight =3D sdom->weight;
> @@ -1397,10 +1401,6 @@ csched_dom_cntl(
> =A0 =A0 =A0 =A0 =A0 =A0 struct list_head *iter;
> =A0 =A0 =A0 =A0 =A0 =A0 int old_weight;
>
> - =A0 =A0 =A0 =A0 =A0 =A0/* Must hold csched_priv lock to update sdom, ru=
nq lock to
> - =A0 =A0 =A0 =A0 =A0 =A0 * update csvcs. */
> - =A0 =A0 =A0 =A0 =A0 =A0spin_lock_irqsave(&prv->lock, flags);
> -
> =A0 =A0 =A0 =A0 =A0 =A0 old_weight =3D sdom->weight;
>
> =A0 =A0 =A0 =A0 =A0 =A0 sdom->weight =3D op->u.credit2.weight;
> @@ -1411,22 +1411,23 @@ csched_dom_cntl(
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 struct csched_vcpu *svc =3D list_entry(it=
er, struct csched_vcpu, sdom_elem);
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* NB: Locking order is important here. =
=A0Because we grab this lock here, we
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 * must never lock csched_priv.lock if w=
e're holding a runqueue
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 * lock. */
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0vcpu_schedule_lock_irq(svc->vcpu);
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 * must never lock csched_priv.lock if w=
e're holding a runqueue lock.
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 * Also, calling vcpu_schedule_lock() is=
 enough, since IRQs have already
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 * been disabled. */
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0vcpu_schedule_lock(svc->vcpu);
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 BUG_ON(svc->rqd !=3D RQD(ops, svc->vcpu->=
processor));
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 svc->weight =3D sdom->weight;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 update_max_weight(svc->rqd, svc->weight, =
old_weight);
>
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0vcpu_schedule_unlock_irq(svc->vcpu);
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0vcpu_schedule_unlock(svc->vcpu);
> =A0 =A0 =A0 =A0 =A0 =A0 }
> -
> - =A0 =A0 =A0 =A0 =A0 =A0spin_unlock_irqrestore(&prv->lock, flags);
> =A0 =A0 =A0 =A0 }
> =A0 =A0 }
>
> + =A0 =A0spin_unlock_irqrestore(&prv->lock, flags);
> +
> =A0 =A0 return 0;
> =A0}
>
> diff -r 1452fb248cd5 xen/common/sched_sedf.c
> --- a/xen/common/sched_sedf.c =A0 Fri Dec 16 15:45:40 2011 +0100
> +++ b/xen/common/sched_sedf.c =A0 Fri Dec 16 17:49:46 2011 +0100
> @@ -61,6 +61,11 @@ struct sedf_dom_info {
> =A0 =A0 struct domain =A0*domain;
> =A0};
>
> +struct sedf_priv_info {
> + =A0 =A0/* lock for the whole pluggable scheduler, nests inside cpupool_=
lock */
> + =A0 =A0spinlock_t lock;
> +};
> +
> =A0struct sedf_vcpu_info {
> =A0 =A0 struct vcpu *vcpu;
> =A0 =A0 struct list_head list;
> @@ -115,6 +120,8 @@ struct sedf_cpu_info {
> =A0 =A0 s_time_t =A0 =A0 =A0 =A0 current_slice_expires;
> =A0};
>
> +#define SEDF_PRIV(_ops) \
> + =A0 =A0((struct sedf_priv_info *)((_ops)->sched_data))
> =A0#define EDOM_INFO(d) =A0 ((struct sedf_vcpu_info *)((d)->sched_priv))
> =A0#define CPU_INFO(cpu) =A0\
> =A0 =A0 ((struct sedf_cpu_info *)per_cpu(schedule_data, cpu).sched_priv)
> @@ -772,6 +779,31 @@ static struct task_slice sedf_do_extra_s
> =A0}
>
>
> +static int sedf_init(struct scheduler *ops)
> +{
> + =A0 =A0struct sedf_priv_info *prv;
> +
> + =A0 =A0prv =3D xzalloc(struct sedf_priv_info);
> + =A0 =A0if ( prv =3D=3D NULL )
> + =A0 =A0 =A0 =A0return -ENOMEM;
> +
> + =A0 =A0ops->sched_data =3D prv;
> + =A0 =A0spin_lock_init(&prv->lock);
> +
> + =A0 =A0return 0;
> +}
> +
> +
> +static void sedf_deinit(const struct scheduler *ops)
> +{
> + =A0 =A0struct sedf_priv_info *prv;
> +
> + =A0 =A0prv =3D SEDF_PRIV(ops);
> + =A0 =A0if ( prv !=3D NULL )
> + =A0 =A0 =A0 =A0xfree(prv);
> +}
> +
> +
> =A0/* Main scheduling function
> =A0 =A0Reasons for calling this function are:
> =A0 =A0-timeslice for the current period used up
> @@ -1320,22 +1352,15 @@ static void sedf_dump_cpu_state(const st
>
>
> =A0/* Adjusts periods and slices of the domains accordingly to their weig=
hts. */
> -static int sedf_adjust_weights(struct cpupool *c, struct xen_domctl_sche=
duler_op *cmd)
> +static int sedf_adjust_weights(struct cpupool *c, int nr_cpus, int *sumw=
, s_time_t *sumt)
> =A0{
> =A0 =A0 struct vcpu *p;
> =A0 =A0 struct domain =A0 =A0 =A0*d;
> - =A0 =A0unsigned int =A0 =A0 =A0 =A0cpu, nr_cpus =3D cpumask_last(&cpu_o=
nline_map) + 1;
> - =A0 =A0int =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0*sumw =3D xzalloc_array(int, =
nr_cpus);
> - =A0 =A0s_time_t =A0 =A0 =A0 =A0 =A0 *sumt =3D xzalloc_array(s_time_t, n=
r_cpus);
> + =A0 =A0unsigned int =A0 =A0 =A0 =A0cpu;
>
> - =A0 =A0if ( !sumw || !sumt )
> - =A0 =A0{
> - =A0 =A0 =A0 =A0xfree(sumt);
> - =A0 =A0 =A0 =A0xfree(sumw);
> - =A0 =A0 =A0 =A0return -ENOMEM;
> - =A0 =A0}
> -
> - =A0 =A0/* Sum across all weights. */
> + =A0 =A0/* Sum across all weights. Notice that no runq locking is needed
> + =A0 =A0 * here: the caller holds sedf_priv_info.lock and we're not chan=
ging
> + =A0 =A0 * anything that is accessed during scheduling. */
> =A0 =A0 rcu_read_lock(&domlist_read_lock);
> =A0 =A0 for_each_domain_in_cpupool( d, c )
> =A0 =A0 {
> @@ -1365,7 +1390,9 @@ static int sedf_adjust_weights(struct cp
> =A0 =A0 }
> =A0 =A0 rcu_read_unlock(&domlist_read_lock);
>
> - =A0 =A0/* Adjust all slices (and periods) to the new weight. */
> + =A0 =A0/* Adjust all slices (and periods) to the new weight. Unlike abo=
ve, we
> + =A0 =A0 * need to take thr runq lock for the various VCPUs: we're modyf=
ing
> + =A0 =A0 * slice and period which are referenced during scheduling. */
> =A0 =A0 rcu_read_lock(&domlist_read_lock);
> =A0 =A0 for_each_domain_in_cpupool( d, c )
> =A0 =A0 {
> @@ -1375,20 +1402,20 @@ static int sedf_adjust_weights(struct cp
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 continue;
> =A0 =A0 =A0 =A0 =A0 =A0 if ( EDOM_INFO(p)->weight )
> =A0 =A0 =A0 =A0 =A0 =A0 {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/* Interrupts already off */
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0vcpu_schedule_lock(p);
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 EDOM_INFO(p)->period_orig =3D
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 EDOM_INFO(p)->period =A0=3D WEIGH=
T_PERIOD;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 EDOM_INFO(p)->slice_orig =A0=3D
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 EDOM_INFO(p)->slice =A0 =3D
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (EDOM_INFO(p)->weight *
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(WEIGHT_PERIOD - WEIGHT_SAFETY=
 - sumt[cpu])) / sumw[cpu];
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0vcpu_schedule_unlock(p);
> =A0 =A0 =A0 =A0 =A0 =A0 }
> =A0 =A0 =A0 =A0 }
> =A0 =A0 }
> =A0 =A0 rcu_read_unlock(&domlist_read_lock);
>
> - =A0 =A0xfree(sumt);
> - =A0 =A0xfree(sumw);
> -
> =A0 =A0 return 0;
> =A0}
>
> @@ -1396,19 +1423,45 @@ static int sedf_adjust_weights(struct cp
> =A0/* set or fetch domain scheduling parameters */
> =A0static int sedf_adjust(const struct scheduler *ops, struct domain *p, =
struct xen_domctl_scheduler_op *op)
> =A0{
> + =A0 =A0struct sedf_priv_info *prv =3D SEDF_PRIV(ops);
> + =A0 =A0unsigned long flags;
> + =A0 =A0unsigned int nr_cpus =3D cpumask_last(&cpu_online_map) + 1;
> + =A0 =A0int *sumw =3D xzalloc_array(int, nr_cpus);
> + =A0 =A0s_time_t *sumt =3D xzalloc_array(s_time_t, nr_cpus);
> =A0 =A0 struct vcpu *v;
> - =A0 =A0int rc;
> + =A0 =A0int rc =3D 0;
>
> =A0 =A0 PRINT(2,"sedf_adjust was called, domain-id %i new period %"PRIu64=
" "
> =A0 =A0 =A0 =A0 =A0 "new slice %"PRIu64"\nlatency %"PRIu64" extra:%s\n",
> =A0 =A0 =A0 =A0 =A0 p->domain_id, op->u.sedf.period, op->u.sedf.slice,
> =A0 =A0 =A0 =A0 =A0 op->u.sedf.latency, (op->u.sedf.extratime)?"yes":"no"=
);
>
> + =A0 =A0/* Serialize against the pluggable scheduler lock to protect from
> + =A0 =A0 * concurrent updates. We need to take the runq lock for the VCP=
Us
> + =A0 =A0 * as well, since we are touching extraweight, weight, slice and
> + =A0 =A0 * period. As in sched_credit2.c, runq locks nest inside the
> + =A0 =A0 * pluggable scheduler lock. */
> + =A0 =A0spin_lock_irqsave(&prv->lock, flags);
> +
> =A0 =A0 if ( op->cmd =3D=3D XEN_DOMCTL_SCHEDOP_putinfo )
> =A0 =A0 {
> + =A0 =A0 =A0 =A0/* These are used in sedf_adjust_weights() but have to b=
e allocated in
> + =A0 =A0 =A0 =A0 * this function, as we need to avoid nesting xmem_pool_=
alloc's lock
> + =A0 =A0 =A0 =A0 * within our prv->lock. */
> + =A0 =A0 =A0 =A0if ( !sumw || !sumt )
> + =A0 =A0 =A0 =A0{
> + =A0 =A0 =A0 =A0 =A0 =A0/* Check for errors here, the _getinfo branch do=
esn't care */
> + =A0 =A0 =A0 =A0 =A0 =A0rc =3D -ENOMEM;
> + =A0 =A0 =A0 =A0 =A0 =A0goto out;
> + =A0 =A0 =A0 =A0}
> +
> =A0 =A0 =A0 =A0 /* Check for sane parameters. */
> =A0 =A0 =A0 =A0 if ( !op->u.sedf.period && !op->u.sedf.weight )
> - =A0 =A0 =A0 =A0 =A0 =A0return -EINVAL;
> + =A0 =A0 =A0 =A0{
> + =A0 =A0 =A0 =A0 =A0 =A0rc =3D -EINVAL;
> + =A0 =A0 =A0 =A0 =A0 =A0goto out;
> + =A0 =A0 =A0 =A0}
> +
> =A0 =A0 =A0 =A0 if ( op->u.sedf.weight )
> =A0 =A0 =A0 =A0 {
> =A0 =A0 =A0 =A0 =A0 =A0 if ( (op->u.sedf.extratime & EXTRA_AWARE) &&
> @@ -1417,59 +1470,78 @@ static int sedf_adjust(const struct sche
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* Weight-driven domains with extratime o=
nly. */
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 for_each_vcpu ( p, v )
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/* (Here and everywhere in the f=
ollowing) IRQs are already off,
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 * hence vcpu_spin_lock() is the=
 one. */
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0vcpu_schedule_lock(v);
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 EDOM_INFO(v)->extraweight =3D op-=
>u.sedf.weight;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 EDOM_INFO(v)->weight =3D 0;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 EDOM_INFO(v)->slice =3D 0;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 EDOM_INFO(v)->period =3D WEIGHT_P=
ERIOD;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0vcpu_schedule_unlock(v);
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 }
> =A0 =A0 =A0 =A0 =A0 =A0 }
> =A0 =A0 =A0 =A0 =A0 =A0 else
> =A0 =A0 =A0 =A0 =A0 =A0 {
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* Weight-driven domains with real-time e=
xecution. */
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0for_each_vcpu ( p, v )
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0for_each_vcpu ( p, v ) {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0vcpu_schedule_lock(v);
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 EDOM_INFO(v)->weight =3D op->u.se=
df.weight;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0vcpu_schedule_unlock(v);
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0}
> =A0 =A0 =A0 =A0 =A0 =A0 }
> =A0 =A0 =A0 =A0 }
> =A0 =A0 =A0 =A0 else
> =A0 =A0 =A0 =A0 {
> + =A0 =A0 =A0 =A0 =A0 =A0/*
> + =A0 =A0 =A0 =A0 =A0 =A0 * Sanity checking: note that disabling extra we=
ight requires
> + =A0 =A0 =A0 =A0 =A0 =A0 * that we set a non-zero slice.
> + =A0 =A0 =A0 =A0 =A0 =A0 */
> + =A0 =A0 =A0 =A0 =A0 =A0if ( (op->u.sedf.period > PERIOD_MAX) ||
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (op->u.sedf.period < PERIOD_MIN) ||
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (op->u.sedf.slice =A0> op->u.sedf.perio=
d) ||
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (op->u.sedf.slice =A0< SLICE_MIN) )
> + =A0 =A0 =A0 =A0 =A0 =A0{
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0rc =3D -EINVAL;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0goto out;
> + =A0 =A0 =A0 =A0 =A0 =A0}
> +
> =A0 =A0 =A0 =A0 =A0 =A0 /* Time-driven domains. */
> =A0 =A0 =A0 =A0 =A0 =A0 for_each_vcpu ( p, v )
> =A0 =A0 =A0 =A0 =A0 =A0 {
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/*
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 * Sanity checking: note that disabling =
extra weight requires
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 * that we set a non-zero slice.
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 */
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if ( (op->u.sedf.period > PERIOD_MAX) ||
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (op->u.sedf.period < PERIOD_MIN=
) ||
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (op->u.sedf.slice =A0> op->u.se=
df.period) ||
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (op->u.sedf.slice =A0< SLICE_MI=
N) )
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0return -EINVAL;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0vcpu_schedule_lock(v);
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 EDOM_INFO(v)->weight =3D 0;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 EDOM_INFO(v)->extraweight =3D 0;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 EDOM_INFO(v)->period_orig =3D
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 EDOM_INFO(v)->period =A0=3D op->u=
.sedf.period;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 EDOM_INFO(v)->slice_orig =A0=3D
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 EDOM_INFO(v)->slice =A0 =3D op->u=
.sedf.slice;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0vcpu_schedule_unlock(v);
> =A0 =A0 =A0 =A0 =A0 =A0 }
> =A0 =A0 =A0 =A0 }
>
> - =A0 =A0 =A0 =A0rc =3D sedf_adjust_weights(p->cpupool, op);
> + =A0 =A0 =A0 =A0rc =3D sedf_adjust_weights(p->cpupool, nr_cpus, sumw, su=
mt);
> =A0 =A0 =A0 =A0 if ( rc )
> - =A0 =A0 =A0 =A0 =A0 =A0return rc;
> + =A0 =A0 =A0 =A0 =A0 =A0goto out;
>
> =A0 =A0 =A0 =A0 for_each_vcpu ( p, v )
> =A0 =A0 =A0 =A0 {
> + =A0 =A0 =A0 =A0 =A0 =A0vcpu_schedule_lock(v);
> =A0 =A0 =A0 =A0 =A0 =A0 EDOM_INFO(v)->status =A0=3D
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (EDOM_INFO(v)->status &
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0~EXTRA_AWARE) | (op->u.sedf.extratime =
& EXTRA_AWARE);
> =A0 =A0 =A0 =A0 =A0 =A0 EDOM_INFO(v)->latency =3D op->u.sedf.latency;
> =A0 =A0 =A0 =A0 =A0 =A0 extraq_check(v);
> + =A0 =A0 =A0 =A0 =A0 =A0vcpu_schedule_unlock(v);
> =A0 =A0 =A0 =A0 }
> =A0 =A0 }
> =A0 =A0 else if ( op->cmd =3D=3D XEN_DOMCTL_SCHEDOP_getinfo )
> =A0 =A0 {
> =A0 =A0 =A0 =A0 if ( p->vcpu[0] =3D=3D NULL )
> - =A0 =A0 =A0 =A0 =A0 =A0return -EINVAL;
> + =A0 =A0 =A0 =A0{
> + =A0 =A0 =A0 =A0 =A0 =A0rc =3D -EINVAL;
> + =A0 =A0 =A0 =A0 =A0 =A0goto out;
> + =A0 =A0 =A0 =A0}
> +
> =A0 =A0 =A0 =A0 op->u.sedf.period =A0 =A0=3D EDOM_INFO(p->vcpu[0])->perio=
d;
> =A0 =A0 =A0 =A0 op->u.sedf.slice =A0 =A0 =3D EDOM_INFO(p->vcpu[0])->slice;
> =A0 =A0 =A0 =A0 op->u.sedf.extratime =3D EDOM_INFO(p->vcpu[0])->status & =
EXTRA_AWARE;
> @@ -1477,14 +1549,23 @@ static int sedf_adjust(const struct sche
> =A0 =A0 =A0 =A0 op->u.sedf.weight =A0 =A0=3D EDOM_INFO(p->vcpu[0])->weigh=
t;
> =A0 =A0 }
>
> - =A0 =A0PRINT(2,"sedf_adjust_finished\n");
> - =A0 =A0return 0;
> +out:
> + =A0 =A0spin_unlock_irqrestore(&prv->lock, flags);
> +
> + =A0 =A0xfree(sumt);
> + =A0 =A0xfree(sumw);
> +
> + =A0 =A0PRINT(2,"sedf_adjust_finished with return code %d\n", rc);
> + =A0 =A0return rc;
> =A0}
>
> +static struct sedf_priv_info _sedf_priv;
> +
> =A0const struct scheduler sched_sedf_def =3D {
> - =A0 =A0.name =A0 =A0 =3D "Simple EDF Scheduler",
> - =A0 =A0.opt_name =3D "sedf",
> - =A0 =A0.sched_id =3D XEN_SCHEDULER_SEDF,
> + =A0 =A0.name =A0 =A0 =A0 =A0 =A0 =3D "Simple EDF Scheduler",
> + =A0 =A0.opt_name =A0 =A0 =A0 =3D "sedf",
> + =A0 =A0.sched_id =A0 =A0 =A0 =3D XEN_SCHEDULER_SEDF,
> + =A0 =A0.sched_data =A0 =A0 =3D &_sedf_priv,
>
> =A0 =A0 .init_domain =A0 =A0=3D sedf_init_domain,
> =A0 =A0 .destroy_domain =3D sedf_destroy_domain,
> @@ -1498,6 +1579,9 @@ const struct scheduler sched_sedf_def =3D
> =A0 =A0 .alloc_domdata =A0=3D sedf_alloc_domdata,
> =A0 =A0 .free_domdata =A0 =3D sedf_free_domdata,
>
> + =A0 =A0.init =A0 =A0 =A0 =A0 =A0 =3D sedf_init,
> + =A0 =A0.deinit =A0 =A0 =A0 =A0 =3D sedf_deinit,
> +
> =A0 =A0 .do_schedule =A0 =A0=3D sedf_do_schedule,
> =A0 =A0 .pick_cpu =A0 =A0 =A0 =3D sedf_pick_cpu,
> =A0 =A0 .dump_cpu_state =3D sedf_dump_cpu_state,
> diff -r 1452fb248cd5 xen/common/schedule.c
> --- a/xen/common/schedule.c =A0 =A0 Fri Dec 16 15:45:40 2011 +0100
> +++ b/xen/common/schedule.c =A0 =A0 Fri Dec 16 17:49:46 2011 +0100
> @@ -1005,7 +1005,6 @@ int sched_id(void)
> =A0/* Adjust scheduling parameter for a given domain. */
> =A0long sched_adjust(struct domain *d, struct xen_domctl_scheduler_op *op)
> =A0{
> - =A0 =A0struct vcpu *v;
> =A0 =A0 long ret;
>
> =A0 =A0 if ( (op->sched_id !=3D DOM2OP(d)->sched_id) ||
> @@ -1013,40 +1012,11 @@ long sched_adjust(struct domain *d, stru
> =A0 =A0 =A0 =A0 =A0 (op->cmd !=3D XEN_DOMCTL_SCHEDOP_getinfo)) )
> =A0 =A0 =A0 =A0 return -EINVAL;
>
> - =A0 =A0/*
> - =A0 =A0 * Most VCPUs we can simply pause. If we are adjusting this VCPU=
 then
> - =A0 =A0 * we acquire the local schedule_lock to guard against concurren=
t updates.
> - =A0 =A0 *
> - =A0 =A0 * We only acquire the local schedule lock after we have paused =
all other
> - =A0 =A0 * VCPUs in this domain. There are two reasons for this:
> - =A0 =A0 * 1- We don't want to hold up interrupts as pausing a VCPU can
> - =A0 =A0 * =A0 =A0trigger a tlb shootdown.
> - =A0 =A0 * 2- Pausing other VCPUs involves briefly locking the schedule
> - =A0 =A0 * =A0 =A0lock of the CPU they are running on. This CPU could be=
 the
> - =A0 =A0 * =A0 =A0same as ours.
> - =A0 =A0 */
> -
> - =A0 =A0for_each_vcpu ( d, v )
> - =A0 =A0{
> - =A0 =A0 =A0 =A0if ( v !=3D current )
> - =A0 =A0 =A0 =A0 =A0 =A0vcpu_pause(v);
> - =A0 =A0}
> -
> - =A0 =A0if ( d =3D=3D current->domain )
> - =A0 =A0 =A0 =A0vcpu_schedule_lock_irq(current);
> -
> + =A0 =A0/* NB: the pluggable scheduler code needs to take care
> + =A0 =A0 * of locking by itself. */
> =A0 =A0 if ( (ret =3D SCHED_OP(DOM2OP(d), adjust, d, op)) =3D=3D 0 )
> =A0 =A0 =A0 =A0 TRACE_1D(TRC_SCHED_ADJDOM, d->domain_id);
>
> - =A0 =A0if ( d =3D=3D current->domain )
> - =A0 =A0 =A0 =A0vcpu_schedule_unlock_irq(current);
> -
> - =A0 =A0for_each_vcpu ( d, v )
> - =A0 =A0{
> - =A0 =A0 =A0 =A0if ( v !=3D current )
> - =A0 =A0 =A0 =A0 =A0 =A0vcpu_unpause(v);
> - =A0 =A0}
> -
> =A0 =A0 return ret;
> =A0}
>
> --
> <<This happens because I choose it to happen!>> (Raistlin Majere)
> -------------------------------------------------------------------
> Dario Faggioli, http://retis.sssup.it/people/faggioli
> Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
> PhD Candidate, ReTiS Lab, Scuola Superiore Sant'Anna, Pisa (Italy)
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 18:06:53 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 18:06:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbcAv-0000Cf-9o; Fri, 16 Dec 2011 18:06:29 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1RbcAt-0000CI-Rt
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 18:06:28 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1324058779!5845596!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=0.9 required=7.0 tests=DIET_1,RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19805 invoked from network); 16 Dec 2011 18:06:21 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Dec 2011 18:06:21 -0000
Received: by iagw33 with SMTP id w33so12851041iag.30
	for <xen-devel@lists.xensource.com>;
	Fri, 16 Dec 2011 10:06:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=6P+lGZapcBVR4CjBr5dqgYhQxPiJjRRvKOr8OSGI8AY=;
	b=WncZX8uWj6vintV7Cq+F8Gwan07WMtMcDtXd1FQsLnlholJ6zB3c0WWpwfyednqXyL
	iV7552T0Nph6jSHyKROcHw8z+eoZB3ZIUYFQPQnT4Y8Jjr0B/IM2wGlenLMSmYIHYWzl
	mDGSAOpPPL46XZ3yjFErBy/y8qJcA9X7ZWj08=
MIME-Version: 1.0
Received: by 10.50.181.161 with SMTP id dx1mr9673919igc.90.1324058779255; Fri,
	16 Dec 2011 10:06:19 -0800 (PST)
Received: by 10.231.146.21 with HTTP; Fri, 16 Dec 2011 10:06:19 -0800 (PST)
In-Reply-To: <1324052965.2599.8.camel@Solace>
References: <1324052965.2599.8.camel@Solace>
Date: Fri, 16 Dec 2011 18:06:19 +0000
X-Google-Sender-Auth: MYbILtSkXY8ziNikvhu7zGsWTFI
Message-ID: <CAFLBxZa586C7D=2zW-NTsA5jxroRcWEoCk7YNg9KBdJwMoGZwQ@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Dario Faggioli <dario.faggioli@citrix.com>
Cc: Keir Fraser <keir@xen.org>, xen-devel@lists.xensource.com,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH] All domains (including dom0) should be best
 effort upon creation.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Dec 16, 2011 at 4:29 PM, Dario Faggioli
<dario.faggioli@citrix.com> wrote:
> All domains (including dom0) should be best effort upon creation.
>
> In the sedf scheduler, while trying to guarantee to dom0 the proper
> amount of CPU time for being able to do its job, we end up allocating
> 75% CPU-share to each and every of its VCPUs. This, combined with the
> fact that such a scheduler has no load balancing logic at all (and
> thus *all* dom0's VCPUs just rise and stay on physical CPU #0), means
> that for example on a 12-cores system we're trying to exploit
> 75x12=3D900% of what we have on a PCPU, which is definitely too much!
>
> Moreover, even if a cleverer mechanism for distributing VCPUs among
> the available PCPUs (if not a proper load balancer) will be put in
> place some day, it will still be difficult to decide how much guaranteed
> CPU bandwidth each of the dom0's VCPUs should be provided with, without
> posing the system at risk of livelock or starvation, even during
> boot time.
>
> Therefore, since sedf is capable of some form of best-effort
> scheduling, the best thing we can do is ask for this behaviour for
> dom0, as it is for all other domains, right upon creation. It will
> then be the sysadmin's job to modify dom0's scheduling parameters
> to better fit his particular needs, maybe after spreading the load
> a bit by pinning VCPUs on PCPUs, or using cpupools, etc.
>
> Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>

Looks reasonable to me.

Acked-by: George Dunlap <george.dunlap@eu.citrix.com>


>
>
> diff -r 01c8b27e3d7d xen/common/sched_sedf.c
> --- a/xen/common/sched_sedf.c =A0 Thu Dec 15 16:56:21 2011 +0000
> +++ b/xen/common/sched_sedf.c =A0 Fri Dec 16 16:05:37 2011 +0100
> @@ -359,19 +359,9 @@ static void *sedf_alloc_vdata(const stru
> =A0 =A0 inf->latency =A0 =A0 =3D 0;
> =A0 =A0 inf->status =A0 =A0 =A0=3D EXTRA_AWARE | SEDF_ASLEEP;
> =A0 =A0 inf->extraweight =3D 1;
> -
> - =A0 =A0if ( v->domain->domain_id =3D=3D 0 )
> - =A0 =A0{
> - =A0 =A0 =A0 =A0/* Domain0 gets 75% guaranteed (15ms every 20ms). */
> - =A0 =A0 =A0 =A0inf->period =A0 =A0=3D MILLISECS(20);
> - =A0 =A0 =A0 =A0inf->slice =A0 =A0 =3D MILLISECS(15);
> - =A0 =A0}
> - =A0 =A0else
> - =A0 =A0{
> - =A0 =A0 =A0 =A0/* Best-effort extratime only. */
> - =A0 =A0 =A0 =A0inf->period =A0 =A0=3D WEIGHT_PERIOD;
> - =A0 =A0 =A0 =A0inf->slice =A0 =A0 =3D 0;
> - =A0 =A0}
> + =A0 =A0/* Upon creation all domain are best-effort. */
> + =A0 =A0inf->period =A0 =A0 =A0=3D WEIGHT_PERIOD;
> + =A0 =A0inf->slice =A0 =A0 =A0 =3D 0;
>
> =A0 =A0 inf->period_orig =3D inf->period; inf->slice_orig =3D inf->slice;
> =A0 =A0 INIT_LIST_HEAD(&(inf->list));
>
> --
> <<This happens because I choose it to happen!>> (Raistlin Majere)
> -------------------------------------------------------------------
> Dario Faggioli, http://retis.sssup.it/people/faggioli
> Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
> PhD Candidate, ReTiS Lab, Scuola Superiore Sant'Anna, Pisa (Italy)
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 18:06:53 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 18:06:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbcAv-0000Cf-9o; Fri, 16 Dec 2011 18:06:29 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1RbcAt-0000CI-Rt
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 18:06:28 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1324058779!5845596!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=0.9 required=7.0 tests=DIET_1,RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19805 invoked from network); 16 Dec 2011 18:06:21 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Dec 2011 18:06:21 -0000
Received: by iagw33 with SMTP id w33so12851041iag.30
	for <xen-devel@lists.xensource.com>;
	Fri, 16 Dec 2011 10:06:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=6P+lGZapcBVR4CjBr5dqgYhQxPiJjRRvKOr8OSGI8AY=;
	b=WncZX8uWj6vintV7Cq+F8Gwan07WMtMcDtXd1FQsLnlholJ6zB3c0WWpwfyednqXyL
	iV7552T0Nph6jSHyKROcHw8z+eoZB3ZIUYFQPQnT4Y8Jjr0B/IM2wGlenLMSmYIHYWzl
	mDGSAOpPPL46XZ3yjFErBy/y8qJcA9X7ZWj08=
MIME-Version: 1.0
Received: by 10.50.181.161 with SMTP id dx1mr9673919igc.90.1324058779255; Fri,
	16 Dec 2011 10:06:19 -0800 (PST)
Received: by 10.231.146.21 with HTTP; Fri, 16 Dec 2011 10:06:19 -0800 (PST)
In-Reply-To: <1324052965.2599.8.camel@Solace>
References: <1324052965.2599.8.camel@Solace>
Date: Fri, 16 Dec 2011 18:06:19 +0000
X-Google-Sender-Auth: MYbILtSkXY8ziNikvhu7zGsWTFI
Message-ID: <CAFLBxZa586C7D=2zW-NTsA5jxroRcWEoCk7YNg9KBdJwMoGZwQ@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Dario Faggioli <dario.faggioli@citrix.com>
Cc: Keir Fraser <keir@xen.org>, xen-devel@lists.xensource.com,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH] All domains (including dom0) should be best
 effort upon creation.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Dec 16, 2011 at 4:29 PM, Dario Faggioli
<dario.faggioli@citrix.com> wrote:
> All domains (including dom0) should be best effort upon creation.
>
> In the sedf scheduler, while trying to guarantee to dom0 the proper
> amount of CPU time for being able to do its job, we end up allocating
> 75% CPU-share to each and every of its VCPUs. This, combined with the
> fact that such a scheduler has no load balancing logic at all (and
> thus *all* dom0's VCPUs just rise and stay on physical CPU #0), means
> that for example on a 12-cores system we're trying to exploit
> 75x12=3D900% of what we have on a PCPU, which is definitely too much!
>
> Moreover, even if a cleverer mechanism for distributing VCPUs among
> the available PCPUs (if not a proper load balancer) will be put in
> place some day, it will still be difficult to decide how much guaranteed
> CPU bandwidth each of the dom0's VCPUs should be provided with, without
> posing the system at risk of livelock or starvation, even during
> boot time.
>
> Therefore, since sedf is capable of some form of best-effort
> scheduling, the best thing we can do is ask for this behaviour for
> dom0, as it is for all other domains, right upon creation. It will
> then be the sysadmin's job to modify dom0's scheduling parameters
> to better fit his particular needs, maybe after spreading the load
> a bit by pinning VCPUs on PCPUs, or using cpupools, etc.
>
> Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>

Looks reasonable to me.

Acked-by: George Dunlap <george.dunlap@eu.citrix.com>


>
>
> diff -r 01c8b27e3d7d xen/common/sched_sedf.c
> --- a/xen/common/sched_sedf.c =A0 Thu Dec 15 16:56:21 2011 +0000
> +++ b/xen/common/sched_sedf.c =A0 Fri Dec 16 16:05:37 2011 +0100
> @@ -359,19 +359,9 @@ static void *sedf_alloc_vdata(const stru
> =A0 =A0 inf->latency =A0 =A0 =3D 0;
> =A0 =A0 inf->status =A0 =A0 =A0=3D EXTRA_AWARE | SEDF_ASLEEP;
> =A0 =A0 inf->extraweight =3D 1;
> -
> - =A0 =A0if ( v->domain->domain_id =3D=3D 0 )
> - =A0 =A0{
> - =A0 =A0 =A0 =A0/* Domain0 gets 75% guaranteed (15ms every 20ms). */
> - =A0 =A0 =A0 =A0inf->period =A0 =A0=3D MILLISECS(20);
> - =A0 =A0 =A0 =A0inf->slice =A0 =A0 =3D MILLISECS(15);
> - =A0 =A0}
> - =A0 =A0else
> - =A0 =A0{
> - =A0 =A0 =A0 =A0/* Best-effort extratime only. */
> - =A0 =A0 =A0 =A0inf->period =A0 =A0=3D WEIGHT_PERIOD;
> - =A0 =A0 =A0 =A0inf->slice =A0 =A0 =3D 0;
> - =A0 =A0}
> + =A0 =A0/* Upon creation all domain are best-effort. */
> + =A0 =A0inf->period =A0 =A0 =A0=3D WEIGHT_PERIOD;
> + =A0 =A0inf->slice =A0 =A0 =A0 =3D 0;
>
> =A0 =A0 inf->period_orig =3D inf->period; inf->slice_orig =3D inf->slice;
> =A0 =A0 INIT_LIST_HEAD(&(inf->list));
>
> --
> <<This happens because I choose it to happen!>> (Raistlin Majere)
> -------------------------------------------------------------------
> Dario Faggioli, http://retis.sssup.it/people/faggioli
> Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
> PhD Candidate, ReTiS Lab, Scuola Superiore Sant'Anna, Pisa (Italy)
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 18:47:16 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 18:47:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rbcnu-0000cs-CI; Fri, 16 Dec 2011 18:46:46 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Rbcns-0000cn-M0
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 18:46:44 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1324061179!49636607!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjU3OQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2933 invoked from network); 16 Dec 2011 18:46:19 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Dec 2011 18:46:19 -0000
X-IronPort-AV: E=Sophos;i="4.71,364,1320624000"; 
   d="scan'208";a="9522673"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Dec 2011 18:46:38 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 16 Dec 2011 18:46:38 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Rbcnl-0007ay-VC; Fri, 16 Dec 2011 18:46:37 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rbcnl-00023k-Ty;
	Fri, 16 Dec 2011 18:46:37 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20203.37389.843395.656684@mariner.uk.xensource.com>
Date: Fri, 16 Dec 2011 18:46:37 +0000
To: Ian Campbell <ian.campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <f4586d1a539c869e31fa.1323792781@cosworth.uk.xensource.com>
References: <patchbomb.1323792779@cosworth.uk.xensource.com>
	<f4586d1a539c869e31fa.1323792781@cosworth.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Olaf Hering <olaf@aepfle.de>, xen-devel@lists.xensource.com,
	Vincent Hanquez <Vincent.Hanquez@eu.citrix.com>,
	Jonathan Ludlam <Jonathan.Ludlam@eu.citrix.com>, konrad.wilk@oracle.com
Subject: Re: [Xen-devel] [PATCH 2 of 4 V2] Linux/xencommons: Use oxenstored
 by default when available
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("[Xen-devel] [PATCH 2 of 4 V2] Linux/xencommons: Use oxenstored by default when available"):
> Linux/xencommons: Use oxenstored by default when available

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 18:47:16 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 18:47:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rbcnu-0000cs-CI; Fri, 16 Dec 2011 18:46:46 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Rbcns-0000cn-M0
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 18:46:44 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1324061179!49636607!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjU3OQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2933 invoked from network); 16 Dec 2011 18:46:19 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Dec 2011 18:46:19 -0000
X-IronPort-AV: E=Sophos;i="4.71,364,1320624000"; 
   d="scan'208";a="9522673"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Dec 2011 18:46:38 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 16 Dec 2011 18:46:38 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Rbcnl-0007ay-VC; Fri, 16 Dec 2011 18:46:37 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rbcnl-00023k-Ty;
	Fri, 16 Dec 2011 18:46:37 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20203.37389.843395.656684@mariner.uk.xensource.com>
Date: Fri, 16 Dec 2011 18:46:37 +0000
To: Ian Campbell <ian.campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <f4586d1a539c869e31fa.1323792781@cosworth.uk.xensource.com>
References: <patchbomb.1323792779@cosworth.uk.xensource.com>
	<f4586d1a539c869e31fa.1323792781@cosworth.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Olaf Hering <olaf@aepfle.de>, xen-devel@lists.xensource.com,
	Vincent Hanquez <Vincent.Hanquez@eu.citrix.com>,
	Jonathan Ludlam <Jonathan.Ludlam@eu.citrix.com>, konrad.wilk@oracle.com
Subject: Re: [Xen-devel] [PATCH 2 of 4 V2] Linux/xencommons: Use oxenstored
 by default when available
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("[Xen-devel] [PATCH 2 of 4 V2] Linux/xencommons: Use oxenstored by default when available"):
> Linux/xencommons: Use oxenstored by default when available

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 19:35:41 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 19:35:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbdYi-00019O-76; Fri, 16 Dec 2011 19:35:08 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1RbdYg-00019J-Ij
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 19:35:06 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-8.tower-27.messagelabs.com!1324063993!56516260!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 668 invoked from network); 16 Dec 2011 19:33:14 -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; 16 Dec 2011 19:33:14 -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
	pBGJZ0r0026896
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Fri, 16 Dec 2011 14:35:00 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pBGJZ0Si026894;
	Fri, 16 Dec 2011 14:35:00 -0500
Date: Fri, 16 Dec 2011 15:35:00 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Message-ID: <20111216193459.GA26802@andromeda.dapyr.net>
References: <20111128152031.GB9655@andromeda.dapyr.net>
	<1322498951-4392-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1322498951-4392-8-git-send-email-dgdegra@tycho.nsa.gov>
	<20111214185618.GC24598@phenom.dumpdata.com>
	<4EE8FE60.30602@tycho.nsa.gov>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4EE8FE60.30602@tycho.nsa.gov>
User-Agent: Mutt/1.5.9i
Cc: Ian.Campbell@citrix.com, xen-devel@lists.xensource.com,
	david.vrabel@citrix.com, JBeulich@suse.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH 07/12] xen/event: Add reference counting to
	event channels
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Dec 14, 2011 at 02:52:00PM -0500, Daniel De Graaf wrote:
> On 12/14/2011 01:56 PM, Konrad Rzeszutek Wilk wrote:
> > On Mon, Nov 28, 2011 at 11:49:06AM -0500, Daniel De Graaf wrote:
> >> Event channels exposed to userspace by the evtchn module may be used by
> >> other modules in an asynchronous manner, which requires that reference
> >> counting be used to prevent the event channel from being closed before
> >> the signals are delivered.
> >>
> >> The reference count on new event channels defaults to -1 which indicates
> >> the event channel is not referenced outside the kernel; evtchn_get fails
> >> if called on such an event channel. The event channels made visible to
> >> userspace by evtchn have a normal reference count.
> > 
> > So I've 7 through 12 in my branch now. (7,8 and 9 are in the #linux-next
> > and the 10-12 are in the #testing).
> > 
> > The other 1-6 you have might need to be parceled out (especially the netback
> > one which usually goes through David Miller). Also I have to double-check -
> > but did somebody review those 1-6 patches?
> > 
> 
> The last review I've seen of these patches is this thread:
> 
> http://lists.xen.org/archives/html/xen-devel/2011-10/threads.html#01484
> 
> I'll post a v3 for those in a bit incorporating the comments in that
> thread; the netback one was (unofficially?) acked by David Miller. I don't

Yup. I see it now. Thx
> see which of the other patches need to be parceled out as the files they
> touch look like they are still being committed with only Xen developer
> sign-offs.
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 19:35:41 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 19:35:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbdYi-00019O-76; Fri, 16 Dec 2011 19:35:08 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1RbdYg-00019J-Ij
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 19:35:06 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-8.tower-27.messagelabs.com!1324063993!56516260!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 668 invoked from network); 16 Dec 2011 19:33:14 -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; 16 Dec 2011 19:33:14 -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
	pBGJZ0r0026896
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Fri, 16 Dec 2011 14:35:00 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pBGJZ0Si026894;
	Fri, 16 Dec 2011 14:35:00 -0500
Date: Fri, 16 Dec 2011 15:35:00 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Message-ID: <20111216193459.GA26802@andromeda.dapyr.net>
References: <20111128152031.GB9655@andromeda.dapyr.net>
	<1322498951-4392-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1322498951-4392-8-git-send-email-dgdegra@tycho.nsa.gov>
	<20111214185618.GC24598@phenom.dumpdata.com>
	<4EE8FE60.30602@tycho.nsa.gov>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4EE8FE60.30602@tycho.nsa.gov>
User-Agent: Mutt/1.5.9i
Cc: Ian.Campbell@citrix.com, xen-devel@lists.xensource.com,
	david.vrabel@citrix.com, JBeulich@suse.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH 07/12] xen/event: Add reference counting to
	event channels
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Dec 14, 2011 at 02:52:00PM -0500, Daniel De Graaf wrote:
> On 12/14/2011 01:56 PM, Konrad Rzeszutek Wilk wrote:
> > On Mon, Nov 28, 2011 at 11:49:06AM -0500, Daniel De Graaf wrote:
> >> Event channels exposed to userspace by the evtchn module may be used by
> >> other modules in an asynchronous manner, which requires that reference
> >> counting be used to prevent the event channel from being closed before
> >> the signals are delivered.
> >>
> >> The reference count on new event channels defaults to -1 which indicates
> >> the event channel is not referenced outside the kernel; evtchn_get fails
> >> if called on such an event channel. The event channels made visible to
> >> userspace by evtchn have a normal reference count.
> > 
> > So I've 7 through 12 in my branch now. (7,8 and 9 are in the #linux-next
> > and the 10-12 are in the #testing).
> > 
> > The other 1-6 you have might need to be parceled out (especially the netback
> > one which usually goes through David Miller). Also I have to double-check -
> > but did somebody review those 1-6 patches?
> > 
> 
> The last review I've seen of these patches is this thread:
> 
> http://lists.xen.org/archives/html/xen-devel/2011-10/threads.html#01484
> 
> I'll post a v3 for those in a bit incorporating the comments in that
> thread; the netback one was (unofficially?) acked by David Miller. I don't

Yup. I see it now. Thx
> see which of the other patches need to be parceled out as the files they
> touch look like they are still being committed with only Xen developer
> sign-offs.
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 19:57:06 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 19: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.xensource.com>)
	id 1RbdtQ-0001KZ-4o; Fri, 16 Dec 2011 19:56:32 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1RbdtO-0001KU-NH
	for Xen-devel@lists.xensource.com; Fri, 16 Dec 2011 19:56:31 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-9.tower-174.messagelabs.com!1324065381!5893118!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31004 invoked from network); 16 Dec 2011 19:56:23 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-9.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 16 Dec 2011 19:56:23 -0000
Received: from andromeda.dapyr.net (darnok@localhost [127.0.0.1])
	by andromeda.dapyr.net (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id
	pBGJuK56027674
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Fri, 16 Dec 2011 14:56:20 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pBGJuK9I027672;
	Fri, 16 Dec 2011 14:56:20 -0500
Date: Fri, 16 Dec 2011 15:56:20 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Message-ID: <20111216195620.GB26802@andromeda.dapyr.net>
References: <1323893534-436-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1323893534-436-2-git-send-email-dgdegra@tycho.nsa.gov>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1323893534-436-2-git-send-email-dgdegra@tycho.nsa.gov>
User-Agent: Mutt/1.5.9i
Cc: Xen-devel@lists.xensource.com, konrad.wilk@oracle.com
Subject: Re: [Xen-devel] [PATCH 1/6] xenbus: Support HVM backends
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Dec 14, 2011 at 03:12:09PM -0500, Daniel De Graaf wrote:
> Add HVM implementations of xenbus_(map,unmap)_ring_v(alloc,free) so
> that ring mappings can be done without using GNTMAP_contains_pte which
> is not supported on HVM.
> 
> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
> ---
>  drivers/xen/xenbus/xenbus_client.c |  155 +++++++++++++++++++++++++++++-------
>  1 files changed, 125 insertions(+), 30 deletions(-)
> 
> diff --git a/drivers/xen/xenbus/xenbus_client.c b/drivers/xen/xenbus/xenbus_client.c
> index 1906125..ecd695d 100644
> --- a/drivers/xen/xenbus/xenbus_client.c
> +++ b/drivers/xen/xenbus/xenbus_client.c
> @@ -32,16 +32,27 @@
>  
>  #include <linux/slab.h>
>  #include <linux/types.h>
> +#include <linux/spinlock.h>
>  #include <linux/vmalloc.h>
>  #include <linux/export.h>
>  #include <asm/xen/hypervisor.h>
>  #include <asm/xen/page.h>
>  #include <xen/interface/xen.h>
>  #include <xen/interface/event_channel.h>
> +#include <xen/balloon.h>
>  #include <xen/events.h>
>  #include <xen/grant_table.h>
>  #include <xen/xenbus.h>
>  
> +struct xenbus_map_node {
> +	struct list_head next;
> +	struct page *page;
> +	grant_handle_t handle;
> +};
> +
> +static DEFINE_SPINLOCK(xenbus_valloc_lock);
> +static LIST_HEAD(xenbus_valloc_pages);

Could we use this for what the PV version of xenbus_unmap_ring_vfree
does? (where it uses the vmlist_lock to look for the appropiate vaddr).

Could the vmlist_lock be removed and instead we can use this structure
for both PV and HVM?

> +
>  const char *xenbus_strstate(enum xenbus_state state)
>  {
>  	static const char *const name[] = {
> @@ -420,21 +431,8 @@ int xenbus_free_evtchn(struct xenbus_device *dev, int port)
>  EXPORT_SYMBOL_GPL(xenbus_free_evtchn);
>  
>  
> -/**
> - * xenbus_map_ring_valloc
> - * @dev: xenbus device
> - * @gnt_ref: grant reference
> - * @vaddr: pointer to address to be filled out by mapping
> - *
> - * Based on Rusty Russell's skeleton driver's map_page.
> - * Map a page of memory into this domain from another domain's grant table.
> - * xenbus_map_ring_valloc allocates a page of virtual address space, maps the
> - * page to that address, and sets *vaddr to that address.
> - * Returns 0 on success, and GNTST_* (see xen/include/interface/grant_table.h)
> - * or -ENOMEM on error. If an error is returned, device will switch to
> - * XenbusStateClosing and the error message will be saved in XenStore.
> - */
> -int xenbus_map_ring_valloc(struct xenbus_device *dev, int gnt_ref, void **vaddr)
> +static int xenbus_map_ring_valloc_pv(struct xenbus_device *dev,
> +                                     int gnt_ref, void **vaddr)
>  {
>  	struct gnttab_map_grant_ref op = {
>  		.flags = GNTMAP_host_map | GNTMAP_contains_pte,
> @@ -469,6 +467,64 @@ int xenbus_map_ring_valloc(struct xenbus_device *dev, int gnt_ref, void **vaddr)
>  	*vaddr = area->addr;
>  	return 0;
>  }
> +
> +static int xenbus_map_ring_valloc_hvm(struct xenbus_device *dev,
> +                                     int gnt_ref, void **vaddr)
> +{
> +	struct xenbus_map_node *node;
> +	int err;
> +	void *addr;
> +
> +	*vaddr = NULL;
> +
> +	node = kzalloc(sizeof(*node), GFP_KERNEL);
> +	if (!node)
> +		return -ENOMEM;
> +
> +	err = alloc_xenballooned_pages(1, &node->page, false /* lowmem */);
> +	if (err)
> +		goto out_err;
> +
> +	addr = pfn_to_kaddr(page_to_pfn(node->page));
> +
> +	err = xenbus_map_ring(dev, gnt_ref, &node->handle, addr);
> +	if (err)
> +		goto out_err;
> +
> +	spin_lock(&xenbus_valloc_lock);
> +	list_add(&node->next, &xenbus_valloc_pages);
> +	spin_unlock(&xenbus_valloc_lock);
> +
> +	*vaddr = addr;
> +	return 0;
> +
> + out_err:
> +	free_xenballooned_pages(1, &node->page);
> +	kfree(node);
> +	return err;
> +}
> +
> +/**
> + * xenbus_map_ring_valloc
> + * @dev: xenbus device
> + * @gnt_ref: grant reference
> + * @vaddr: pointer to address to be filled out by mapping
> + *
> + * Based on Rusty Russell's skeleton driver's map_page.
> + * Map a page of memory into this domain from another domain's grant table.
> + * xenbus_map_ring_valloc allocates a page of virtual address space, maps the
> + * page to that address, and sets *vaddr to that address.
> + * Returns 0 on success, and GNTST_* (see xen/include/interface/grant_table.h)
> + * or -ENOMEM on error. If an error is returned, device will switch to
> + * XenbusStateClosing and the error message will be saved in XenStore.
> + */
> +int xenbus_map_ring_valloc(struct xenbus_device *dev, int gnt_ref, void **vaddr)
> +{
> +	if (xen_pv_domain())
> +		return xenbus_map_ring_valloc_pv(dev, gnt_ref, vaddr);
> +	else
> +		return xenbus_map_ring_valloc_hvm(dev, gnt_ref, vaddr);

This could be done in a similar way which Annie's granttable v2 patches are done.

Meaning define something like:

struct xenbus_ring_ops {
	int (*map)(struct xenbus_device *dev, int gnt, void *vaddr);
	...

And then define two variants of it (PV and HVM):

struct xenbus_ring_ops pv_ring_ops = {
	.map = xenbus_map_ring_valloc_pv;
	..
}

have a static to which either one will be assigned:

static struct xenbus_ring_ops *ring_ops;

And in the init function:

void __init xenbus_ring_ops_init(void)
{
	if (xen_hvm_domain)
		ring_ops = hvm_ring_ops;
	else
	...

And then xenbus_init() calls the xenbus_rings_ops_init().

Then these 'xenbus_map_ring_valloc' end up just using the
ring_ops->map call.

> +}
>  EXPORT_SYMBOL_GPL(xenbus_map_ring_valloc);
>  
>  
> @@ -510,20 +566,7 @@ int xenbus_map_ring(struct xenbus_device *dev, int gnt_ref,
>  }
>  EXPORT_SYMBOL_GPL(xenbus_map_ring);
>  
> -
> -/**
> - * xenbus_unmap_ring_vfree
> - * @dev: xenbus device
> - * @vaddr: addr to unmap
> - *
> - * Based on Rusty Russell's skeleton driver's unmap_page.
> - * Unmap a page of memory in this domain that was imported from another domain.
> - * Use xenbus_unmap_ring_vfree if you mapped in your memory with
> - * xenbus_map_ring_valloc (it will free the virtual address space).
> - * Returns 0 on success and returns GNTST_* on error
> - * (see xen/include/interface/grant_table.h).
> - */
> -int xenbus_unmap_ring_vfree(struct xenbus_device *dev, void *vaddr)
> +static int xenbus_unmap_ring_vfree_pv(struct xenbus_device *dev, void *vaddr)
>  {
>  	struct vm_struct *area;
>  	struct gnttab_unmap_grant_ref op = {
> @@ -566,8 +609,60 @@ int xenbus_unmap_ring_vfree(struct xenbus_device *dev, void *vaddr)
>  
>  	return op.status;
>  }
> -EXPORT_SYMBOL_GPL(xenbus_unmap_ring_vfree);
>  
> +static int xenbus_unmap_ring_vfree_hvm(struct xenbus_device *dev, void *vaddr)
> +{
> +	int rv;
> +	struct xenbus_map_node *node;
> +	void *addr;
> +
> +	spin_lock(&xenbus_valloc_lock);
> +	list_for_each_entry(node, &xenbus_valloc_pages, next) {
> +		addr = pfn_to_kaddr(page_to_pfn(node->page));
> +		if (addr == vaddr) {
> +			list_del(&node->next);
> +			goto found;
> +		}
> +	}
> +	node = NULL;
> + found:
> +	spin_unlock(&xenbus_valloc_lock);
> +
> +	if (!node) {
> +		xenbus_dev_error(dev, -ENOENT,
> +				 "can't find mapped virtual address %p", vaddr);
> +		return -ENOENT;
> +	}
> +
> +	rv = xenbus_unmap_ring(dev, node->handle, addr);
> +
> +	if (!rv)
> +		free_xenballooned_pages(1, &node->page);

else
	WARN_ON("Leaking %p \n", vaddr);

> +
> +	kfree(node);
> +	return rv;
> +}
> +
> +/**
> + * xenbus_unmap_ring_vfree
> + * @dev: xenbus device
> + * @vaddr: addr to unmap
> + *
> + * Based on Rusty Russell's skeleton driver's unmap_page.
> + * Unmap a page of memory in this domain that was imported from another domain.
> + * Use xenbus_unmap_ring_vfree if you mapped in your memory with
> + * xenbus_map_ring_valloc (it will free the virtual address space).
> + * Returns 0 on success and returns GNTST_* on error

Well, that is not true anymore. You are also returning -ENOENT.

> + * (see xen/include/interface/grant_table.h).
> + */
> +int xenbus_unmap_ring_vfree(struct xenbus_device *dev, void *vaddr)
> +{
> +	if (xen_pv_domain())
> +		return xenbus_unmap_ring_vfree_pv(dev, vaddr);
> +	else
> +		return xenbus_unmap_ring_vfree_hvm(dev, vaddr);
> +}
> +EXPORT_SYMBOL_GPL(xenbus_unmap_ring_vfree);
>  
>  /**
>   * xenbus_unmap_ring
> -- 
> 1.7.7.4
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 19:57:06 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 19: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.xensource.com>)
	id 1RbdtQ-0001KZ-4o; Fri, 16 Dec 2011 19:56:32 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1RbdtO-0001KU-NH
	for Xen-devel@lists.xensource.com; Fri, 16 Dec 2011 19:56:31 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-9.tower-174.messagelabs.com!1324065381!5893118!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31004 invoked from network); 16 Dec 2011 19:56:23 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-9.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 16 Dec 2011 19:56:23 -0000
Received: from andromeda.dapyr.net (darnok@localhost [127.0.0.1])
	by andromeda.dapyr.net (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id
	pBGJuK56027674
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Fri, 16 Dec 2011 14:56:20 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pBGJuK9I027672;
	Fri, 16 Dec 2011 14:56:20 -0500
Date: Fri, 16 Dec 2011 15:56:20 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Message-ID: <20111216195620.GB26802@andromeda.dapyr.net>
References: <1323893534-436-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1323893534-436-2-git-send-email-dgdegra@tycho.nsa.gov>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1323893534-436-2-git-send-email-dgdegra@tycho.nsa.gov>
User-Agent: Mutt/1.5.9i
Cc: Xen-devel@lists.xensource.com, konrad.wilk@oracle.com
Subject: Re: [Xen-devel] [PATCH 1/6] xenbus: Support HVM backends
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Dec 14, 2011 at 03:12:09PM -0500, Daniel De Graaf wrote:
> Add HVM implementations of xenbus_(map,unmap)_ring_v(alloc,free) so
> that ring mappings can be done without using GNTMAP_contains_pte which
> is not supported on HVM.
> 
> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
> ---
>  drivers/xen/xenbus/xenbus_client.c |  155 +++++++++++++++++++++++++++++-------
>  1 files changed, 125 insertions(+), 30 deletions(-)
> 
> diff --git a/drivers/xen/xenbus/xenbus_client.c b/drivers/xen/xenbus/xenbus_client.c
> index 1906125..ecd695d 100644
> --- a/drivers/xen/xenbus/xenbus_client.c
> +++ b/drivers/xen/xenbus/xenbus_client.c
> @@ -32,16 +32,27 @@
>  
>  #include <linux/slab.h>
>  #include <linux/types.h>
> +#include <linux/spinlock.h>
>  #include <linux/vmalloc.h>
>  #include <linux/export.h>
>  #include <asm/xen/hypervisor.h>
>  #include <asm/xen/page.h>
>  #include <xen/interface/xen.h>
>  #include <xen/interface/event_channel.h>
> +#include <xen/balloon.h>
>  #include <xen/events.h>
>  #include <xen/grant_table.h>
>  #include <xen/xenbus.h>
>  
> +struct xenbus_map_node {
> +	struct list_head next;
> +	struct page *page;
> +	grant_handle_t handle;
> +};
> +
> +static DEFINE_SPINLOCK(xenbus_valloc_lock);
> +static LIST_HEAD(xenbus_valloc_pages);

Could we use this for what the PV version of xenbus_unmap_ring_vfree
does? (where it uses the vmlist_lock to look for the appropiate vaddr).

Could the vmlist_lock be removed and instead we can use this structure
for both PV and HVM?

> +
>  const char *xenbus_strstate(enum xenbus_state state)
>  {
>  	static const char *const name[] = {
> @@ -420,21 +431,8 @@ int xenbus_free_evtchn(struct xenbus_device *dev, int port)
>  EXPORT_SYMBOL_GPL(xenbus_free_evtchn);
>  
>  
> -/**
> - * xenbus_map_ring_valloc
> - * @dev: xenbus device
> - * @gnt_ref: grant reference
> - * @vaddr: pointer to address to be filled out by mapping
> - *
> - * Based on Rusty Russell's skeleton driver's map_page.
> - * Map a page of memory into this domain from another domain's grant table.
> - * xenbus_map_ring_valloc allocates a page of virtual address space, maps the
> - * page to that address, and sets *vaddr to that address.
> - * Returns 0 on success, and GNTST_* (see xen/include/interface/grant_table.h)
> - * or -ENOMEM on error. If an error is returned, device will switch to
> - * XenbusStateClosing and the error message will be saved in XenStore.
> - */
> -int xenbus_map_ring_valloc(struct xenbus_device *dev, int gnt_ref, void **vaddr)
> +static int xenbus_map_ring_valloc_pv(struct xenbus_device *dev,
> +                                     int gnt_ref, void **vaddr)
>  {
>  	struct gnttab_map_grant_ref op = {
>  		.flags = GNTMAP_host_map | GNTMAP_contains_pte,
> @@ -469,6 +467,64 @@ int xenbus_map_ring_valloc(struct xenbus_device *dev, int gnt_ref, void **vaddr)
>  	*vaddr = area->addr;
>  	return 0;
>  }
> +
> +static int xenbus_map_ring_valloc_hvm(struct xenbus_device *dev,
> +                                     int gnt_ref, void **vaddr)
> +{
> +	struct xenbus_map_node *node;
> +	int err;
> +	void *addr;
> +
> +	*vaddr = NULL;
> +
> +	node = kzalloc(sizeof(*node), GFP_KERNEL);
> +	if (!node)
> +		return -ENOMEM;
> +
> +	err = alloc_xenballooned_pages(1, &node->page, false /* lowmem */);
> +	if (err)
> +		goto out_err;
> +
> +	addr = pfn_to_kaddr(page_to_pfn(node->page));
> +
> +	err = xenbus_map_ring(dev, gnt_ref, &node->handle, addr);
> +	if (err)
> +		goto out_err;
> +
> +	spin_lock(&xenbus_valloc_lock);
> +	list_add(&node->next, &xenbus_valloc_pages);
> +	spin_unlock(&xenbus_valloc_lock);
> +
> +	*vaddr = addr;
> +	return 0;
> +
> + out_err:
> +	free_xenballooned_pages(1, &node->page);
> +	kfree(node);
> +	return err;
> +}
> +
> +/**
> + * xenbus_map_ring_valloc
> + * @dev: xenbus device
> + * @gnt_ref: grant reference
> + * @vaddr: pointer to address to be filled out by mapping
> + *
> + * Based on Rusty Russell's skeleton driver's map_page.
> + * Map a page of memory into this domain from another domain's grant table.
> + * xenbus_map_ring_valloc allocates a page of virtual address space, maps the
> + * page to that address, and sets *vaddr to that address.
> + * Returns 0 on success, and GNTST_* (see xen/include/interface/grant_table.h)
> + * or -ENOMEM on error. If an error is returned, device will switch to
> + * XenbusStateClosing and the error message will be saved in XenStore.
> + */
> +int xenbus_map_ring_valloc(struct xenbus_device *dev, int gnt_ref, void **vaddr)
> +{
> +	if (xen_pv_domain())
> +		return xenbus_map_ring_valloc_pv(dev, gnt_ref, vaddr);
> +	else
> +		return xenbus_map_ring_valloc_hvm(dev, gnt_ref, vaddr);

This could be done in a similar way which Annie's granttable v2 patches are done.

Meaning define something like:

struct xenbus_ring_ops {
	int (*map)(struct xenbus_device *dev, int gnt, void *vaddr);
	...

And then define two variants of it (PV and HVM):

struct xenbus_ring_ops pv_ring_ops = {
	.map = xenbus_map_ring_valloc_pv;
	..
}

have a static to which either one will be assigned:

static struct xenbus_ring_ops *ring_ops;

And in the init function:

void __init xenbus_ring_ops_init(void)
{
	if (xen_hvm_domain)
		ring_ops = hvm_ring_ops;
	else
	...

And then xenbus_init() calls the xenbus_rings_ops_init().

Then these 'xenbus_map_ring_valloc' end up just using the
ring_ops->map call.

> +}
>  EXPORT_SYMBOL_GPL(xenbus_map_ring_valloc);
>  
>  
> @@ -510,20 +566,7 @@ int xenbus_map_ring(struct xenbus_device *dev, int gnt_ref,
>  }
>  EXPORT_SYMBOL_GPL(xenbus_map_ring);
>  
> -
> -/**
> - * xenbus_unmap_ring_vfree
> - * @dev: xenbus device
> - * @vaddr: addr to unmap
> - *
> - * Based on Rusty Russell's skeleton driver's unmap_page.
> - * Unmap a page of memory in this domain that was imported from another domain.
> - * Use xenbus_unmap_ring_vfree if you mapped in your memory with
> - * xenbus_map_ring_valloc (it will free the virtual address space).
> - * Returns 0 on success and returns GNTST_* on error
> - * (see xen/include/interface/grant_table.h).
> - */
> -int xenbus_unmap_ring_vfree(struct xenbus_device *dev, void *vaddr)
> +static int xenbus_unmap_ring_vfree_pv(struct xenbus_device *dev, void *vaddr)
>  {
>  	struct vm_struct *area;
>  	struct gnttab_unmap_grant_ref op = {
> @@ -566,8 +609,60 @@ int xenbus_unmap_ring_vfree(struct xenbus_device *dev, void *vaddr)
>  
>  	return op.status;
>  }
> -EXPORT_SYMBOL_GPL(xenbus_unmap_ring_vfree);
>  
> +static int xenbus_unmap_ring_vfree_hvm(struct xenbus_device *dev, void *vaddr)
> +{
> +	int rv;
> +	struct xenbus_map_node *node;
> +	void *addr;
> +
> +	spin_lock(&xenbus_valloc_lock);
> +	list_for_each_entry(node, &xenbus_valloc_pages, next) {
> +		addr = pfn_to_kaddr(page_to_pfn(node->page));
> +		if (addr == vaddr) {
> +			list_del(&node->next);
> +			goto found;
> +		}
> +	}
> +	node = NULL;
> + found:
> +	spin_unlock(&xenbus_valloc_lock);
> +
> +	if (!node) {
> +		xenbus_dev_error(dev, -ENOENT,
> +				 "can't find mapped virtual address %p", vaddr);
> +		return -ENOENT;
> +	}
> +
> +	rv = xenbus_unmap_ring(dev, node->handle, addr);
> +
> +	if (!rv)
> +		free_xenballooned_pages(1, &node->page);

else
	WARN_ON("Leaking %p \n", vaddr);

> +
> +	kfree(node);
> +	return rv;
> +}
> +
> +/**
> + * xenbus_unmap_ring_vfree
> + * @dev: xenbus device
> + * @vaddr: addr to unmap
> + *
> + * Based on Rusty Russell's skeleton driver's unmap_page.
> + * Unmap a page of memory in this domain that was imported from another domain.
> + * Use xenbus_unmap_ring_vfree if you mapped in your memory with
> + * xenbus_map_ring_valloc (it will free the virtual address space).
> + * Returns 0 on success and returns GNTST_* on error

Well, that is not true anymore. You are also returning -ENOENT.

> + * (see xen/include/interface/grant_table.h).
> + */
> +int xenbus_unmap_ring_vfree(struct xenbus_device *dev, void *vaddr)
> +{
> +	if (xen_pv_domain())
> +		return xenbus_unmap_ring_vfree_pv(dev, vaddr);
> +	else
> +		return xenbus_unmap_ring_vfree_hvm(dev, vaddr);
> +}
> +EXPORT_SYMBOL_GPL(xenbus_unmap_ring_vfree);
>  
>  /**
>   * xenbus_unmap_ring
> -- 
> 1.7.7.4
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 20:09:46 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 20:09:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rbe5g-0001gq-HO; Fri, 16 Dec 2011 20:09:12 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1Rbe5f-0001gl-9S
	for Xen-devel@lists.xensource.com; Fri, 16 Dec 2011 20:09:11 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-9.tower-174.messagelabs.com!1324066143!5893986!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24208 invoked from network); 16 Dec 2011 20:09:04 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-9.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 16 Dec 2011 20:09:04 -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
	pBGK92H1029113
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Fri, 16 Dec 2011 15:09:02 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pBGK92od029111;
	Fri, 16 Dec 2011 15:09:02 -0500
Date: Fri, 16 Dec 2011 16:09:02 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Message-ID: <20111216200902.GC26802@andromeda.dapyr.net>
References: <1323893534-436-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1323893534-436-3-git-send-email-dgdegra@tycho.nsa.gov>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1323893534-436-3-git-send-email-dgdegra@tycho.nsa.gov>
User-Agent: Mutt/1.5.9i
Cc: Xen-devel@lists.xensource.com, konrad.wilk@oracle.com
Subject: Re: [Xen-devel] [PATCH 2/6] xenbus: Use grant-table wrapper
	functions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Dec 14, 2011 at 03:12:10PM -0500, Daniel De Graaf wrote:
> For xenbus_{map,unmap}_ring to work on HVM, the grant table operations
> must be set up using the gnttab_set_{map,unmap}_op functions instead of
> directly populating the fields of gnttab_map_grant_ref. These functions
> simply populate the structure on paravirtualized Xen; however, on HVM
> they must call __pa() on vaddr when populating op->host_addr because the
> hypervisor cannot directly interpret guest-virtual addresses.

OK, this is a nice cleanup too.
> 
> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
> ---
>  drivers/xen/xenbus/xenbus_client.c |   17 +++++++----------
>  1 files changed, 7 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/xen/xenbus/xenbus_client.c b/drivers/xen/xenbus/xenbus_client.c
> index ecd695d..8a23f1a 100644
> --- a/drivers/xen/xenbus/xenbus_client.c
> +++ b/drivers/xen/xenbus/xenbus_client.c
> @@ -545,12 +545,10 @@ EXPORT_SYMBOL_GPL(xenbus_map_ring_valloc);
>  int xenbus_map_ring(struct xenbus_device *dev, int gnt_ref,
>  		    grant_handle_t *handle, void *vaddr)
>  {
> -	struct gnttab_map_grant_ref op = {
> -		.host_addr = (unsigned long)vaddr,
> -		.flags     = GNTMAP_host_map,
> -		.ref       = gnt_ref,
> -		.dom       = dev->otherend_id,
> -	};
> +	struct gnttab_map_grant_ref op;
> +
> +	gnttab_set_map_op(&op, (phys_addr_t)vaddr, GNTMAP_host_map, gnt_ref,
> +	                  dev->otherend_id);
>  
>  	if (HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, &op, 1))
>  		BUG();
> @@ -677,10 +675,9 @@ EXPORT_SYMBOL_GPL(xenbus_unmap_ring_vfree);
>  int xenbus_unmap_ring(struct xenbus_device *dev,
>  		      grant_handle_t handle, void *vaddr)
>  {
> -	struct gnttab_unmap_grant_ref op = {
> -		.host_addr = (unsigned long)vaddr,
> -		.handle    = handle,
> -	};
> +	struct gnttab_unmap_grant_ref op;
> +
> +	gnttab_set_unmap_op(&op, (phys_addr_t)vaddr, GNTMAP_host_map, handle);

>  
>  	if (HYPERVISOR_grant_table_op(GNTTABOP_unmap_grant_ref, &op, 1))
>  		BUG();
> -- 
> 1.7.7.4
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 20:09:46 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 20:09:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rbe5g-0001gq-HO; Fri, 16 Dec 2011 20:09:12 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1Rbe5f-0001gl-9S
	for Xen-devel@lists.xensource.com; Fri, 16 Dec 2011 20:09:11 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-9.tower-174.messagelabs.com!1324066143!5893986!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24208 invoked from network); 16 Dec 2011 20:09:04 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-9.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 16 Dec 2011 20:09:04 -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
	pBGK92H1029113
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Fri, 16 Dec 2011 15:09:02 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pBGK92od029111;
	Fri, 16 Dec 2011 15:09:02 -0500
Date: Fri, 16 Dec 2011 16:09:02 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Message-ID: <20111216200902.GC26802@andromeda.dapyr.net>
References: <1323893534-436-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1323893534-436-3-git-send-email-dgdegra@tycho.nsa.gov>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1323893534-436-3-git-send-email-dgdegra@tycho.nsa.gov>
User-Agent: Mutt/1.5.9i
Cc: Xen-devel@lists.xensource.com, konrad.wilk@oracle.com
Subject: Re: [Xen-devel] [PATCH 2/6] xenbus: Use grant-table wrapper
	functions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Dec 14, 2011 at 03:12:10PM -0500, Daniel De Graaf wrote:
> For xenbus_{map,unmap}_ring to work on HVM, the grant table operations
> must be set up using the gnttab_set_{map,unmap}_op functions instead of
> directly populating the fields of gnttab_map_grant_ref. These functions
> simply populate the structure on paravirtualized Xen; however, on HVM
> they must call __pa() on vaddr when populating op->host_addr because the
> hypervisor cannot directly interpret guest-virtual addresses.

OK, this is a nice cleanup too.
> 
> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
> ---
>  drivers/xen/xenbus/xenbus_client.c |   17 +++++++----------
>  1 files changed, 7 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/xen/xenbus/xenbus_client.c b/drivers/xen/xenbus/xenbus_client.c
> index ecd695d..8a23f1a 100644
> --- a/drivers/xen/xenbus/xenbus_client.c
> +++ b/drivers/xen/xenbus/xenbus_client.c
> @@ -545,12 +545,10 @@ EXPORT_SYMBOL_GPL(xenbus_map_ring_valloc);
>  int xenbus_map_ring(struct xenbus_device *dev, int gnt_ref,
>  		    grant_handle_t *handle, void *vaddr)
>  {
> -	struct gnttab_map_grant_ref op = {
> -		.host_addr = (unsigned long)vaddr,
> -		.flags     = GNTMAP_host_map,
> -		.ref       = gnt_ref,
> -		.dom       = dev->otherend_id,
> -	};
> +	struct gnttab_map_grant_ref op;
> +
> +	gnttab_set_map_op(&op, (phys_addr_t)vaddr, GNTMAP_host_map, gnt_ref,
> +	                  dev->otherend_id);
>  
>  	if (HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, &op, 1))
>  		BUG();
> @@ -677,10 +675,9 @@ EXPORT_SYMBOL_GPL(xenbus_unmap_ring_vfree);
>  int xenbus_unmap_ring(struct xenbus_device *dev,
>  		      grant_handle_t handle, void *vaddr)
>  {
> -	struct gnttab_unmap_grant_ref op = {
> -		.host_addr = (unsigned long)vaddr,
> -		.handle    = handle,
> -	};
> +	struct gnttab_unmap_grant_ref op;
> +
> +	gnttab_set_unmap_op(&op, (phys_addr_t)vaddr, GNTMAP_host_map, handle);

>  
>  	if (HYPERVISOR_grant_table_op(GNTTABOP_unmap_grant_ref, &op, 1))
>  		BUG();
> -- 
> 1.7.7.4
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 20:18:28 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 20: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.xensource.com>)
	id 1RbeEH-0001qr-II; Fri, 16 Dec 2011 20:18:05 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1RbeEG-0001qm-0M
	for Xen-devel@lists.xensource.com; Fri, 16 Dec 2011 20:18:04 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-7.tower-174.messagelabs.com!1324066676!5886425!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5460 invoked from network); 16 Dec 2011 20:17:57 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-7.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 16 Dec 2011 20:17:57 -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
	pBGKHtQb029505
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Fri, 16 Dec 2011 15:17:55 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pBGKHt8F029503;
	Fri, 16 Dec 2011 15:17:55 -0500
Date: Fri, 16 Dec 2011 16:17:55 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Message-ID: <20111216201755.GD26802@andromeda.dapyr.net>
References: <1323893534-436-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1323893534-436-5-git-send-email-dgdegra@tycho.nsa.gov>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1323893534-436-5-git-send-email-dgdegra@tycho.nsa.gov>
User-Agent: Mutt/1.5.9i
Cc: Xen-devel@lists.xensource.com, konrad.wilk@oracle.com
Subject: Re: [Xen-devel] [PATCH 4/6] xen/blkback: use grant-table.c
	hypercall wrappers
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Dec 14, 2011 at 03:12:12PM -0500, Daniel De Graaf wrote:
> Now that the grant table hypercall wrappers support mappings without
> GNTMAP_contains_pte, they should be used instead of invoking the
> hypercalls manually.

Nice.. and it removes a bunch of duplicate code.
> 
> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
> ---
>  drivers/block/xen-blkback/blkback.c |   29 ++++-------------------------
>  1 files changed, 4 insertions(+), 25 deletions(-)
> 
> diff --git a/drivers/block/xen-blkback/blkback.c b/drivers/block/xen-blkback/blkback.c
> index 15ec4db..1e256dc 100644
> --- a/drivers/block/xen-blkback/blkback.c
> +++ b/drivers/block/xen-blkback/blkback.c
> @@ -324,6 +324,7 @@ struct seg_buf {
>  static void xen_blkbk_unmap(struct pending_req *req)
>  {
>  	struct gnttab_unmap_grant_ref unmap[BLKIF_MAX_SEGMENTS_PER_REQUEST];
> +	struct page *pages[BLKIF_MAX_SEGMENTS_PER_REQUEST];
>  	unsigned int i, invcount = 0;
>  	grant_handle_t handle;
>  	int ret;
> @@ -335,25 +336,12 @@ static void xen_blkbk_unmap(struct pending_req *req)
>  		gnttab_set_unmap_op(&unmap[invcount], vaddr(req, i),
>  				    GNTMAP_host_map, handle);
>  		pending_handle(req, i) = BLKBACK_INVALID_HANDLE;
> +		pages[invcount] = virt_to_page(vaddr(req, i));
>  		invcount++;
>  	}
>  
> -	ret = HYPERVISOR_grant_table_op(
> -		GNTTABOP_unmap_grant_ref, unmap, invcount);
> +	ret = gnttab_unmap_refs(unmap, pages, invcount, false);
>  	BUG_ON(ret);
> -	/*
> -	 * Note, we use invcount, so nr->pages, so we can't index
> -	 * using vaddr(req, i).
> -	 */
> -	for (i = 0; i < invcount; i++) {
> -		ret = m2p_remove_override(
> -			virt_to_page(unmap[i].host_addr), false);
> -		if (ret) {
> -			pr_alert(DRV_PFX "Failed to remove M2P override for %lx\n",
> -				 (unsigned long)unmap[i].host_addr);
> -			continue;
> -		}
> -	}
>  }
>  
>  static int xen_blkbk_map(struct blkif_request *req,
> @@ -381,7 +369,7 @@ static int xen_blkbk_map(struct blkif_request *req,
>  				  pending_req->blkif->domid);
>  	}
>  
> -	ret = HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, map, nseg);
> +	ret = gnttab_map_refs(map, NULL, &blkbk->pending_page(pending_req, 0), nseg);
>  	BUG_ON(ret);
>  
>  	/*
> @@ -401,15 +389,6 @@ static int xen_blkbk_map(struct blkif_request *req,
>  		if (ret)
>  			continue;
>  
> -		ret = m2p_add_override(PFN_DOWN(map[i].dev_bus_addr),
> -			blkbk->pending_page(pending_req, i), NULL);
> -		if (ret) {
> -			pr_alert(DRV_PFX "Failed to install M2P override for %lx (ret: %d)\n",
> -				 (unsigned long)map[i].dev_bus_addr, ret);
> -			/* We could switch over to GNTTABOP_copy */
> -			continue;
> -		}
> -
>  		seg[i].buf  = map[i].dev_bus_addr |
>  			(req->u.rw.seg[i].first_sect << 9);
>  	}
> -- 
> 1.7.7.4
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 20:18:28 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 20: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.xensource.com>)
	id 1RbeEH-0001qr-II; Fri, 16 Dec 2011 20:18:05 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1RbeEG-0001qm-0M
	for Xen-devel@lists.xensource.com; Fri, 16 Dec 2011 20:18:04 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-7.tower-174.messagelabs.com!1324066676!5886425!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5460 invoked from network); 16 Dec 2011 20:17:57 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-7.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 16 Dec 2011 20:17:57 -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
	pBGKHtQb029505
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Fri, 16 Dec 2011 15:17:55 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pBGKHt8F029503;
	Fri, 16 Dec 2011 15:17:55 -0500
Date: Fri, 16 Dec 2011 16:17:55 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Message-ID: <20111216201755.GD26802@andromeda.dapyr.net>
References: <1323893534-436-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1323893534-436-5-git-send-email-dgdegra@tycho.nsa.gov>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1323893534-436-5-git-send-email-dgdegra@tycho.nsa.gov>
User-Agent: Mutt/1.5.9i
Cc: Xen-devel@lists.xensource.com, konrad.wilk@oracle.com
Subject: Re: [Xen-devel] [PATCH 4/6] xen/blkback: use grant-table.c
	hypercall wrappers
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Dec 14, 2011 at 03:12:12PM -0500, Daniel De Graaf wrote:
> Now that the grant table hypercall wrappers support mappings without
> GNTMAP_contains_pte, they should be used instead of invoking the
> hypercalls manually.

Nice.. and it removes a bunch of duplicate code.
> 
> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
> ---
>  drivers/block/xen-blkback/blkback.c |   29 ++++-------------------------
>  1 files changed, 4 insertions(+), 25 deletions(-)
> 
> diff --git a/drivers/block/xen-blkback/blkback.c b/drivers/block/xen-blkback/blkback.c
> index 15ec4db..1e256dc 100644
> --- a/drivers/block/xen-blkback/blkback.c
> +++ b/drivers/block/xen-blkback/blkback.c
> @@ -324,6 +324,7 @@ struct seg_buf {
>  static void xen_blkbk_unmap(struct pending_req *req)
>  {
>  	struct gnttab_unmap_grant_ref unmap[BLKIF_MAX_SEGMENTS_PER_REQUEST];
> +	struct page *pages[BLKIF_MAX_SEGMENTS_PER_REQUEST];
>  	unsigned int i, invcount = 0;
>  	grant_handle_t handle;
>  	int ret;
> @@ -335,25 +336,12 @@ static void xen_blkbk_unmap(struct pending_req *req)
>  		gnttab_set_unmap_op(&unmap[invcount], vaddr(req, i),
>  				    GNTMAP_host_map, handle);
>  		pending_handle(req, i) = BLKBACK_INVALID_HANDLE;
> +		pages[invcount] = virt_to_page(vaddr(req, i));
>  		invcount++;
>  	}
>  
> -	ret = HYPERVISOR_grant_table_op(
> -		GNTTABOP_unmap_grant_ref, unmap, invcount);
> +	ret = gnttab_unmap_refs(unmap, pages, invcount, false);
>  	BUG_ON(ret);
> -	/*
> -	 * Note, we use invcount, so nr->pages, so we can't index
> -	 * using vaddr(req, i).
> -	 */
> -	for (i = 0; i < invcount; i++) {
> -		ret = m2p_remove_override(
> -			virt_to_page(unmap[i].host_addr), false);
> -		if (ret) {
> -			pr_alert(DRV_PFX "Failed to remove M2P override for %lx\n",
> -				 (unsigned long)unmap[i].host_addr);
> -			continue;
> -		}
> -	}
>  }
>  
>  static int xen_blkbk_map(struct blkif_request *req,
> @@ -381,7 +369,7 @@ static int xen_blkbk_map(struct blkif_request *req,
>  				  pending_req->blkif->domid);
>  	}
>  
> -	ret = HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, map, nseg);
> +	ret = gnttab_map_refs(map, NULL, &blkbk->pending_page(pending_req, 0), nseg);
>  	BUG_ON(ret);
>  
>  	/*
> @@ -401,15 +389,6 @@ static int xen_blkbk_map(struct blkif_request *req,
>  		if (ret)
>  			continue;
>  
> -		ret = m2p_add_override(PFN_DOWN(map[i].dev_bus_addr),
> -			blkbk->pending_page(pending_req, i), NULL);
> -		if (ret) {
> -			pr_alert(DRV_PFX "Failed to install M2P override for %lx (ret: %d)\n",
> -				 (unsigned long)map[i].dev_bus_addr, ret);
> -			/* We could switch over to GNTTABOP_copy */
> -			continue;
> -		}
> -
>  		seg[i].buf  = map[i].dev_bus_addr |
>  			(req->u.rw.seg[i].first_sect << 9);
>  	}
> -- 
> 1.7.7.4
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 20:20:50 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 20:20:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbeGU-0001y3-8B; Fri, 16 Dec 2011 20:20:22 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1RbeGS-0001xj-Ve
	for Xen-devel@lists.xensource.com; Fri, 16 Dec 2011 20:20:21 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-7.tower-174.messagelabs.com!1324066813!5886573!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10415 invoked from network); 16 Dec 2011 20:20:14 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-7.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 16 Dec 2011 20:20:14 -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
	pBGKKC9H029667
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Fri, 16 Dec 2011 15:20:12 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pBGKKC0F029665;
	Fri, 16 Dec 2011 15:20:12 -0500
Date: Fri, 16 Dec 2011 16:20:12 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Message-ID: <20111216202012.GE26802@andromeda.dapyr.net>
References: <1323893534-436-1-git-send-email-dgdegra@tycho.nsa.gov>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1323893534-436-1-git-send-email-dgdegra@tycho.nsa.gov>
User-Agent: Mutt/1.5.9i
Cc: Xen-devel@lists.xensource.com, konrad.wilk@oracle.com
Subject: Re: [Xen-devel] [PATCH v3 0/6] xen/{net,
	blk}back support for running in HVM
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> [PATCH 1/6] xenbus: Support HVM backends
> [PATCH 2/6] xenbus: Use grant-table wrapper functions
> [PATCH 3/6] xen/grant-table: Support mappings required by blkback
> [PATCH 4/6] xen/blkback: use grant-table.c hypercall wrappers
> [PATCH 5/6] xen/netback: Enable netback on HVM guests
> [PATCH 6/6] xen/blkback: Enable blkback on HVM guests

2-6 look good to me.

The #1 just needs adressing some of the things I pointed out.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 20:20:50 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 20:20:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbeGU-0001y3-8B; Fri, 16 Dec 2011 20:20:22 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1RbeGS-0001xj-Ve
	for Xen-devel@lists.xensource.com; Fri, 16 Dec 2011 20:20:21 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-7.tower-174.messagelabs.com!1324066813!5886573!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10415 invoked from network); 16 Dec 2011 20:20:14 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-7.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 16 Dec 2011 20:20:14 -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
	pBGKKC9H029667
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Fri, 16 Dec 2011 15:20:12 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pBGKKC0F029665;
	Fri, 16 Dec 2011 15:20:12 -0500
Date: Fri, 16 Dec 2011 16:20:12 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Message-ID: <20111216202012.GE26802@andromeda.dapyr.net>
References: <1323893534-436-1-git-send-email-dgdegra@tycho.nsa.gov>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1323893534-436-1-git-send-email-dgdegra@tycho.nsa.gov>
User-Agent: Mutt/1.5.9i
Cc: Xen-devel@lists.xensource.com, konrad.wilk@oracle.com
Subject: Re: [Xen-devel] [PATCH v3 0/6] xen/{net,
	blk}back support for running in HVM
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> [PATCH 1/6] xenbus: Support HVM backends
> [PATCH 2/6] xenbus: Use grant-table wrapper functions
> [PATCH 3/6] xen/grant-table: Support mappings required by blkback
> [PATCH 4/6] xen/blkback: use grant-table.c hypercall wrappers
> [PATCH 5/6] xen/netback: Enable netback on HVM guests
> [PATCH 6/6] xen/blkback: Enable blkback on HVM guests

2-6 look good to me.

The #1 just needs adressing some of the things I pointed out.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 21:10:14 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 21:10:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rbf2D-0002gX-W2; Fri, 16 Dec 2011 21:09:41 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1Rbf2D-0002fs-36
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 21:09:41 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-15.tower-27.messagelabs.com!1324069754!59281023!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.6 required=7.0 tests=BODY_RANDOM_LONG,
  BODY_VIRGIN
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28330 invoked from network); 16 Dec 2011 21:09:16 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-15.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 16 Dec 2011 21:09:16 -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
	pBGL9MbC002404
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Fri, 16 Dec 2011 16:09:23 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pBGL9MsQ002402;
	Fri, 16 Dec 2011 16:09:22 -0500
Date: Fri, 16 Dec 2011 17:09:22 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: William Cohen <wcohen@redhat.com>
Message-ID: <20111216210922.GA2295@andromeda.dapyr.net>
References: <4ED4069E.7030307@redhat.com>
	<20111128224545.GA7821@andromeda.dapyr.net>
	<4ED54E66.7040209@redhat.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4ED54E66.7040209@redhat.com>
User-Agent: Mutt/1.5.9i
Cc: xen-devel@lists.xensource.com,
	oprofile-list <oprofile-list@lists.sourceforge.net>
Subject: Re: [Xen-devel] xenoprof patch for oprofile-0.9.7
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Nov 29, 2011 at 04:28:06PM -0500, William Cohen wrote:
> On 11/28/2011 05:45 PM, Konrad Rzeszutek Wilk wrote:
> > On Mon, Nov 28, 2011 at 05:09:34PM -0500, William Cohen wrote:
> >> I am rebasing Fedora rawhide oprofile package to oprofile-0.9.7. The xenoprof patches on http://xenoprof.sourceforge.net/#download look a bit dated. The newest version is for oprofile-0.9.5. 
> > 
> > There was one posted some time ago.. Ah:
> > http://www.flyn.org/patches/linux-xen-passive-oprofile/linux-3.0-xen-passive-oprofile.patch.gz
> > 
> > I think that ones works , thought I haven't had a chance to test it
> > myself.
> >>
> >> I massaged the patch oprofile-0.9.5-xen.patch to apply to oprofile-.0.9.7. Attached is that updated patch. Does this look reasonable? Is there a desire to get this into upstream oprofile? Or should the xenoprof patch be dropped?
> > 
> > Well, the desire is to get a performance tool in upstream that works
> > with Xen very very very much.
> > 
> > The upstream is using the 'perf' framework which is different from oprofile
> > and there hasn't been any patches to take advantage of it.
> > 
> > So to answer your question:
> >  1). Its awesome you have posted a patch. Will need to spend some time
> >      with it and and with the version that was posted to see if there is
> >      something missing. Sadly, the kernel patch is not very
> >      upstream-compatible as is. But it will get to folks be able to
> >      do some perf analysis instead of using benchmark tools.
> 
> If anyone can exercise the patch and verify that it works well with the current upstream xen, that would be greatly appreciated.

So I tried to do it today but running in trouble of compiling it on
Fedora Core 16. You wouldn't have any patches floating around to make it
compile? (I used first a virgin 0.9.7 version).

Thanks!
> 
> > 
> >  2). In the future we need to work out the optimal performance tool. It
> >      might be oprofile or it might be perf (or it might be both?!). Or
> >      it might something that has not yet been posted?
> > 
> > You wouldn't by any chance be interested in looking at the performance
> > "stuff" and figure out what is the best route/tools to use with upstream
> > kernels?
> 
> There has been some discussion for oprofile to make use of the perf interfaces in future versions of oprofile. The ARM oprofile kernel driver already uses the underlying perf support in the newer kernels. Making oprofile use the perf interface directly would allow normal users to use oprofile to see what is going on with their software and it would allow better cooperative resource allocation of the performance monitoring units.  Also perf allow keeping events on a per thread basis so there would be some hope that different virtual machines could use the counters concurrently.
> 
> perf hasn't been ideal. One of the common use cases would be using perf within a virtual machine, but perf didn't handle that case for the performance monitoring hardware. in the past perf claimed it programmed the performance monitoring hardware, but gave bogus measurements. Newer kernels in guest virtual machine now indicate can't hardware perf events are "<not supported>".  
> 
> -Will
> 
> 
> -Will
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 21:10:14 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 21:10:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rbf2D-0002gX-W2; Fri, 16 Dec 2011 21:09:41 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1Rbf2D-0002fs-36
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 21:09:41 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-15.tower-27.messagelabs.com!1324069754!59281023!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.6 required=7.0 tests=BODY_RANDOM_LONG,
  BODY_VIRGIN
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28330 invoked from network); 16 Dec 2011 21:09:16 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-15.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 16 Dec 2011 21:09:16 -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
	pBGL9MbC002404
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Fri, 16 Dec 2011 16:09:23 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pBGL9MsQ002402;
	Fri, 16 Dec 2011 16:09:22 -0500
Date: Fri, 16 Dec 2011 17:09:22 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: William Cohen <wcohen@redhat.com>
Message-ID: <20111216210922.GA2295@andromeda.dapyr.net>
References: <4ED4069E.7030307@redhat.com>
	<20111128224545.GA7821@andromeda.dapyr.net>
	<4ED54E66.7040209@redhat.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4ED54E66.7040209@redhat.com>
User-Agent: Mutt/1.5.9i
Cc: xen-devel@lists.xensource.com,
	oprofile-list <oprofile-list@lists.sourceforge.net>
Subject: Re: [Xen-devel] xenoprof patch for oprofile-0.9.7
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Nov 29, 2011 at 04:28:06PM -0500, William Cohen wrote:
> On 11/28/2011 05:45 PM, Konrad Rzeszutek Wilk wrote:
> > On Mon, Nov 28, 2011 at 05:09:34PM -0500, William Cohen wrote:
> >> I am rebasing Fedora rawhide oprofile package to oprofile-0.9.7. The xenoprof patches on http://xenoprof.sourceforge.net/#download look a bit dated. The newest version is for oprofile-0.9.5. 
> > 
> > There was one posted some time ago.. Ah:
> > http://www.flyn.org/patches/linux-xen-passive-oprofile/linux-3.0-xen-passive-oprofile.patch.gz
> > 
> > I think that ones works , thought I haven't had a chance to test it
> > myself.
> >>
> >> I massaged the patch oprofile-0.9.5-xen.patch to apply to oprofile-.0.9.7. Attached is that updated patch. Does this look reasonable? Is there a desire to get this into upstream oprofile? Or should the xenoprof patch be dropped?
> > 
> > Well, the desire is to get a performance tool in upstream that works
> > with Xen very very very much.
> > 
> > The upstream is using the 'perf' framework which is different from oprofile
> > and there hasn't been any patches to take advantage of it.
> > 
> > So to answer your question:
> >  1). Its awesome you have posted a patch. Will need to spend some time
> >      with it and and with the version that was posted to see if there is
> >      something missing. Sadly, the kernel patch is not very
> >      upstream-compatible as is. But it will get to folks be able to
> >      do some perf analysis instead of using benchmark tools.
> 
> If anyone can exercise the patch and verify that it works well with the current upstream xen, that would be greatly appreciated.

So I tried to do it today but running in trouble of compiling it on
Fedora Core 16. You wouldn't have any patches floating around to make it
compile? (I used first a virgin 0.9.7 version).

Thanks!
> 
> > 
> >  2). In the future we need to work out the optimal performance tool. It
> >      might be oprofile or it might be perf (or it might be both?!). Or
> >      it might something that has not yet been posted?
> > 
> > You wouldn't by any chance be interested in looking at the performance
> > "stuff" and figure out what is the best route/tools to use with upstream
> > kernels?
> 
> There has been some discussion for oprofile to make use of the perf interfaces in future versions of oprofile. The ARM oprofile kernel driver already uses the underlying perf support in the newer kernels. Making oprofile use the perf interface directly would allow normal users to use oprofile to see what is going on with their software and it would allow better cooperative resource allocation of the performance monitoring units.  Also perf allow keeping events on a per thread basis so there would be some hope that different virtual machines could use the counters concurrently.
> 
> perf hasn't been ideal. One of the common use cases would be using perf within a virtual machine, but perf didn't handle that case for the performance monitoring hardware. in the past perf claimed it programmed the performance monitoring hardware, but gave bogus measurements. Newer kernels in guest virtual machine now indicate can't hardware perf events are "<not supported>".  
> 
> -Will
> 
> 
> -Will
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 21:27:50 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 21:27:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbfJD-00038d-K3; Fri, 16 Dec 2011 21:27:15 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <sandr8@gmail.com>) id 1RbfJC-00038X-KX
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 21:27:14 +0000
X-Env-Sender: sandr8@gmail.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1324070827!7612144!1
X-Originating-IP: [209.85.213.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13228 invoked from network); 16 Dec 2011 21:27:08 -0000
Received: from mail-yx0-f171.google.com (HELO mail-yx0-f171.google.com)
	(209.85.213.171)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Dec 2011 21:27:08 -0000
Received: by yenr9 with SMTP id r9so50790809yen.30
	for <xen-devel@lists.xensource.com>;
	Fri, 16 Dec 2011 13:27:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:reply-to:in-reply-to:references:from:date:message-id
	:subject:to:cc:content-type:content-transfer-encoding;
	bh=Wnd02NoxK60MJMutYk5J1/HwJivRsKxvT7AWnlxZY20=;
	b=A0Rs4ckMMekrrRxbEAjO62tqr0qFr++hxo6T7+b+JNCkEQ9rOzFsoHn9cvdG8Ymh1q
	bAmrt9bc9Bgo6j+l5T5nQi1fq4t7B71em3NXidJHs4U1j3QGis7aDv9zdY4EpfeCApz7
	4WYMpnvGp01xT1kCg4/vsjlMftXZeck5iYFw4=
Received: by 10.236.114.132 with SMTP id c4mr14257834yhh.104.1324070827220;
	Fri, 16 Dec 2011 13:27:07 -0800 (PST)
MIME-Version: 1.0
Received: by 10.236.60.132 with HTTP; Fri, 16 Dec 2011 13:26:36 -0800 (PST)
In-Reply-To: <20111216170154.GA25941@aepfle.de>
References: <4EEA4877.8010307@canonical.com>
	<1323982417.20936.898.camel@dagon.hellion.org.uk>
	<4EEB0CE9.4040405@canonical.com>
	<1324027918.20077.530.camel@zakaz.uk.xensource.com>
	<20111216170154.GA25941@aepfle.de>
From: Alessandro Salvatori <sandr8@gmail.com>
Date: Fri, 16 Dec 2011 13:26:36 -0800
Message-ID: <CAJeBh4tehYht9xw_y-6ns6hoD_2hirj837xQmMA8qxpBTZTpiA@mail.gmail.com>
To: Olaf Hering <olaf@aepfle.de>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefan Bader <stefan.bader@canonical.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] xenbus and the message of doom
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: sandr8@gmail.com
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

by backing out  ddacf5ef684a655abe2bb50c4b2a5b72ae0d5e05, 3.2.0-rc5
boots just fine.

-Alessandro-
=A0Here i am, A young man,
=A0A crashing computer program,
=A0Here is a pen, write out my name...

(from: The Servant - Orchestra)



On Fri, Dec 16, 2011 at 09:01, Olaf Hering <olaf@aepfle.de> wrote:
> On Fri, Dec 16, Ian Campbell wrote:
>
>> I think (or hope!) that Olaf tested with the most recent version of C
>> xenstored which did not support this new message and so I presume that
>> it correct returns an error for an unknown message but that doesn't help
>> us with the older C xenstored which you have.
>
> I just checked a SLES10SP3 host (xen 3.2.3) with a SLES11SP2 hvm guest
> and it booted fine.
>
> So I suspect EC2 is broken in this case.
>
> Olaf
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 21:27:50 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 21:27:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbfJD-00038d-K3; Fri, 16 Dec 2011 21:27:15 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <sandr8@gmail.com>) id 1RbfJC-00038X-KX
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 21:27:14 +0000
X-Env-Sender: sandr8@gmail.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1324070827!7612144!1
X-Originating-IP: [209.85.213.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13228 invoked from network); 16 Dec 2011 21:27:08 -0000
Received: from mail-yx0-f171.google.com (HELO mail-yx0-f171.google.com)
	(209.85.213.171)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Dec 2011 21:27:08 -0000
Received: by yenr9 with SMTP id r9so50790809yen.30
	for <xen-devel@lists.xensource.com>;
	Fri, 16 Dec 2011 13:27:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:reply-to:in-reply-to:references:from:date:message-id
	:subject:to:cc:content-type:content-transfer-encoding;
	bh=Wnd02NoxK60MJMutYk5J1/HwJivRsKxvT7AWnlxZY20=;
	b=A0Rs4ckMMekrrRxbEAjO62tqr0qFr++hxo6T7+b+JNCkEQ9rOzFsoHn9cvdG8Ymh1q
	bAmrt9bc9Bgo6j+l5T5nQi1fq4t7B71em3NXidJHs4U1j3QGis7aDv9zdY4EpfeCApz7
	4WYMpnvGp01xT1kCg4/vsjlMftXZeck5iYFw4=
Received: by 10.236.114.132 with SMTP id c4mr14257834yhh.104.1324070827220;
	Fri, 16 Dec 2011 13:27:07 -0800 (PST)
MIME-Version: 1.0
Received: by 10.236.60.132 with HTTP; Fri, 16 Dec 2011 13:26:36 -0800 (PST)
In-Reply-To: <20111216170154.GA25941@aepfle.de>
References: <4EEA4877.8010307@canonical.com>
	<1323982417.20936.898.camel@dagon.hellion.org.uk>
	<4EEB0CE9.4040405@canonical.com>
	<1324027918.20077.530.camel@zakaz.uk.xensource.com>
	<20111216170154.GA25941@aepfle.de>
From: Alessandro Salvatori <sandr8@gmail.com>
Date: Fri, 16 Dec 2011 13:26:36 -0800
Message-ID: <CAJeBh4tehYht9xw_y-6ns6hoD_2hirj837xQmMA8qxpBTZTpiA@mail.gmail.com>
To: Olaf Hering <olaf@aepfle.de>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefan Bader <stefan.bader@canonical.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] xenbus and the message of doom
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: sandr8@gmail.com
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

by backing out  ddacf5ef684a655abe2bb50c4b2a5b72ae0d5e05, 3.2.0-rc5
boots just fine.

-Alessandro-
=A0Here i am, A young man,
=A0A crashing computer program,
=A0Here is a pen, write out my name...

(from: The Servant - Orchestra)



On Fri, Dec 16, 2011 at 09:01, Olaf Hering <olaf@aepfle.de> wrote:
> On Fri, Dec 16, Ian Campbell wrote:
>
>> I think (or hope!) that Olaf tested with the most recent version of C
>> xenstored which did not support this new message and so I presume that
>> it correct returns an error for an unknown message but that doesn't help
>> us with the older C xenstored which you have.
>
> I just checked a SLES10SP3 host (xen 3.2.3) with a SLES11SP2 hvm guest
> and it booted fine.
>
> So I suspect EC2 is broken in this case.
>
> Olaf
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 21:35:31 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 21:35:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbfQk-0003Rh-I7; Fri, 16 Dec 2011 21:35:02 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RbfQi-0003Rc-Bv
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 21:35:00 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1324071292!7794657!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDQ2MDg3\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24613 invoked from network); 16 Dec 2011 21:34:54 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-12.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 16 Dec 2011 21:34:54 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pBGLYj5b008218
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 16 Dec 2011 21:34:45 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pBGLYfCv010164
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 16 Dec 2011 21:34:42 GMT
Received: from abhmt110.oracle.com (abhmt110.oracle.com [141.146.116.62])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pBGLYdtH010812; Fri, 16 Dec 2011 15:34:39 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 16 Dec 2011 13:34:39 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 7AC6140196; Fri, 16 Dec 2011 16:33:45 -0500 (EST)
Date: Fri, 16 Dec 2011 16:33:45 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: ke.yu@intel.com, kevin.tian@intel.com, linux-kernel@vger.kernel.org,
	linux-acpi@vger.kernel.org, lenb@kernel.org, rjw@sisk.pl
Message-ID: <20111216213345.GA9832@phenom.dumpdata.com>
References: <1322673664-14642-1-git-send-email-konrad.wilk@oracle.com>
	<1322673664-14642-2-git-send-email-konrad.wilk@oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1322673664-14642-2-git-send-email-konrad.wilk@oracle.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090205.4EEBB976.0106,ss=1,re=0.000,fgs=0
Cc: jeremy@goop.org, xen-devel@lists.xensource.com, Ian.Campbell@citrix.com,
	mike.mcclurg@citrix.com, stefan.bader@canonical.com,
	konrad@kernel.org, liang.tang@oracle.com
Subject: Re: [Xen-devel] [PATCH 1/8] ACPI: processor: export necessary
	interfaces
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Nov 30, 2011 at 12:20:57PM -0500, Konrad Rzeszutek Wilk wrote:
> From: Kevin Tian <kevin.tian@intel.com>
> 
> This patch export some necessary functions which parse processor
> power management information. The Xen ACPI processor driver uses them.

I was wondering if it could be done by moving a bunch of these
functions in the processor_perflib.c, but there is a lot of code
that would have to be moved. Way too much.

Perhaps another, and a nicer way would be to:

 1). Create a processor_driver_lib.c which would have the "generic" code
 2). In the processor_driver just keep the essential notifications, and
     the hotplug code
 3). The introduce the other user of the acpi_processor_[add|remove|notify]
     calls as a seperate library?

Thoughts?
> 
> Signed-off-by: Yu Ke <ke.yu@intel.com>
> Signed-off-by: Tian Kevin <kevin.tian@intel.com>
> Signed-off-by: Tang Liang <liang.tang@oracle.com>
> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> ---
>  drivers/acpi/processor_driver.c  |   11 +++--------
>  drivers/acpi/processor_perflib.c |    4 ++--
>  include/acpi/processor.h         |   10 +++++++++-
>  3 files changed, 14 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/acpi/processor_driver.c b/drivers/acpi/processor_driver.c
> index 9d7bc9f..211c078 100644
> --- a/drivers/acpi/processor_driver.c
> +++ b/drivers/acpi/processor_driver.c
> @@ -79,9 +79,6 @@ MODULE_AUTHOR("Paul Diefenbaugh");
>  MODULE_DESCRIPTION("ACPI Processor Driver");
>  MODULE_LICENSE("GPL");
>  
> -static int acpi_processor_add(struct acpi_device *device);
> -static int acpi_processor_remove(struct acpi_device *device, int type);
> -static void acpi_processor_notify(struct acpi_device *device, u32 event);
>  static acpi_status acpi_processor_hotadd_init(acpi_handle handle, int *p_cpu);
>  static int acpi_processor_handle_eject(struct acpi_processor *pr);
>  
> @@ -378,7 +375,7 @@ static int acpi_processor_get_info(struct acpi_device *device)
>  
>  static DEFINE_PER_CPU(void *, processor_device_array);
>  
> -static void acpi_processor_notify(struct acpi_device *device, u32 event)
> +void acpi_processor_notify(struct acpi_device *device, u32 event)
>  {
>  	struct acpi_processor *pr = acpi_driver_data(device);
>  	int saved;
> @@ -442,7 +439,7 @@ static struct notifier_block acpi_cpu_notifier =
>  	    .notifier_call = acpi_cpu_soft_notify,
>  };
>  
> -static int __cpuinit acpi_processor_add(struct acpi_device *device)
> +int __cpuinit acpi_processor_add(struct acpi_device *device)
>  {
>  	struct acpi_processor *pr = NULL;
>  	int result = 0;
> @@ -545,7 +542,7 @@ err_free_cpumask:
>  	return result;
>  }
>  
> -static int acpi_processor_remove(struct acpi_device *device, int type)
> +int acpi_processor_remove(struct acpi_device *device, int type)
>  {
>  	struct acpi_processor *pr = NULL;
>  
> @@ -758,7 +755,6 @@ static int acpi_processor_handle_eject(struct acpi_processor *pr)
>  }
>  #endif
>  
> -static
>  void acpi_processor_install_hotplug_notify(void)
>  {
>  #ifdef CONFIG_ACPI_HOTPLUG_CPU
> @@ -771,7 +767,6 @@ void acpi_processor_install_hotplug_notify(void)
>  	register_hotcpu_notifier(&acpi_cpu_notifier);
>  }
>  
> -static
>  void acpi_processor_uninstall_hotplug_notify(void)
>  {
>  #ifdef CONFIG_ACPI_HOTPLUG_CPU
> diff --git a/drivers/acpi/processor_perflib.c b/drivers/acpi/processor_perflib.c
> index 85b3237..22c6195 100644
> --- a/drivers/acpi/processor_perflib.c
> +++ b/drivers/acpi/processor_perflib.c
> @@ -386,7 +386,7 @@ static int acpi_processor_get_performance_states(struct acpi_processor *pr)
>  	return result;
>  }
>  
> -static int acpi_processor_get_performance_info(struct acpi_processor *pr)
> +int acpi_processor_get_performance_info(struct acpi_processor *pr)
>  {
>  	int result = 0;
>  	acpi_status status = AE_OK;
> @@ -492,7 +492,7 @@ int acpi_processor_notify_smm(struct module *calling_module)
>  
>  EXPORT_SYMBOL(acpi_processor_notify_smm);
>  
> -static int acpi_processor_get_psd(struct acpi_processor	*pr)
> +int acpi_processor_get_psd(struct acpi_processor	*pr)
>  {
>  	int result = 0;
>  	acpi_status status = AE_OK;
> diff --git a/include/acpi/processor.h b/include/acpi/processor.h
> index 610f6fb..12657bb 100644
> --- a/include/acpi/processor.h
> +++ b/include/acpi/processor.h
> @@ -239,6 +239,12 @@ extern void acpi_processor_unregister_performance(struct
>           if a _PPC object exists, rmmod is disallowed then */
>  int acpi_processor_notify_smm(struct module *calling_module);
>  
> +void acpi_processor_install_hotplug_notify(void);
> +void acpi_processor_uninstall_hotplug_notify(void);
> +
> +int acpi_processor_add(struct acpi_device *device);
> +int acpi_processor_remove(struct acpi_device *device, int type);
> +void acpi_processor_notify(struct acpi_device *device, u32 event);
>  /* for communication between multiple parts of the processor kernel module */
>  DECLARE_PER_CPU(struct acpi_processor *, processors);
>  extern struct acpi_processor_errata errata;
> @@ -278,7 +284,9 @@ static inline void acpi_processor_ffh_cstate_enter(struct acpi_processor_cx
>  void acpi_processor_ppc_init(void);
>  void acpi_processor_ppc_exit(void);
>  int acpi_processor_ppc_has_changed(struct acpi_processor *pr, int event_flag);
> -extern int acpi_processor_get_bios_limit(int cpu, unsigned int *limit);
> +int acpi_processor_get_performance_info(struct acpi_processor *pr);
> +int acpi_processor_get_psd(struct acpi_processor *pr);
> +int acpi_processor_get_bios_limit(int cpu, unsigned int *limit);
>  #else
>  static inline void acpi_processor_ppc_init(void)
>  {
> -- 
> 1.7.7.3

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 21:35:31 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 21:35:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbfQk-0003Rh-I7; Fri, 16 Dec 2011 21:35:02 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RbfQi-0003Rc-Bv
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 21:35:00 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1324071292!7794657!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDQ2MDg3\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24613 invoked from network); 16 Dec 2011 21:34:54 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-12.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 16 Dec 2011 21:34:54 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pBGLYj5b008218
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 16 Dec 2011 21:34:45 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pBGLYfCv010164
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 16 Dec 2011 21:34:42 GMT
Received: from abhmt110.oracle.com (abhmt110.oracle.com [141.146.116.62])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pBGLYdtH010812; Fri, 16 Dec 2011 15:34:39 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 16 Dec 2011 13:34:39 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 7AC6140196; Fri, 16 Dec 2011 16:33:45 -0500 (EST)
Date: Fri, 16 Dec 2011 16:33:45 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: ke.yu@intel.com, kevin.tian@intel.com, linux-kernel@vger.kernel.org,
	linux-acpi@vger.kernel.org, lenb@kernel.org, rjw@sisk.pl
Message-ID: <20111216213345.GA9832@phenom.dumpdata.com>
References: <1322673664-14642-1-git-send-email-konrad.wilk@oracle.com>
	<1322673664-14642-2-git-send-email-konrad.wilk@oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1322673664-14642-2-git-send-email-konrad.wilk@oracle.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090205.4EEBB976.0106,ss=1,re=0.000,fgs=0
Cc: jeremy@goop.org, xen-devel@lists.xensource.com, Ian.Campbell@citrix.com,
	mike.mcclurg@citrix.com, stefan.bader@canonical.com,
	konrad@kernel.org, liang.tang@oracle.com
Subject: Re: [Xen-devel] [PATCH 1/8] ACPI: processor: export necessary
	interfaces
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Nov 30, 2011 at 12:20:57PM -0500, Konrad Rzeszutek Wilk wrote:
> From: Kevin Tian <kevin.tian@intel.com>
> 
> This patch export some necessary functions which parse processor
> power management information. The Xen ACPI processor driver uses them.

I was wondering if it could be done by moving a bunch of these
functions in the processor_perflib.c, but there is a lot of code
that would have to be moved. Way too much.

Perhaps another, and a nicer way would be to:

 1). Create a processor_driver_lib.c which would have the "generic" code
 2). In the processor_driver just keep the essential notifications, and
     the hotplug code
 3). The introduce the other user of the acpi_processor_[add|remove|notify]
     calls as a seperate library?

Thoughts?
> 
> Signed-off-by: Yu Ke <ke.yu@intel.com>
> Signed-off-by: Tian Kevin <kevin.tian@intel.com>
> Signed-off-by: Tang Liang <liang.tang@oracle.com>
> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> ---
>  drivers/acpi/processor_driver.c  |   11 +++--------
>  drivers/acpi/processor_perflib.c |    4 ++--
>  include/acpi/processor.h         |   10 +++++++++-
>  3 files changed, 14 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/acpi/processor_driver.c b/drivers/acpi/processor_driver.c
> index 9d7bc9f..211c078 100644
> --- a/drivers/acpi/processor_driver.c
> +++ b/drivers/acpi/processor_driver.c
> @@ -79,9 +79,6 @@ MODULE_AUTHOR("Paul Diefenbaugh");
>  MODULE_DESCRIPTION("ACPI Processor Driver");
>  MODULE_LICENSE("GPL");
>  
> -static int acpi_processor_add(struct acpi_device *device);
> -static int acpi_processor_remove(struct acpi_device *device, int type);
> -static void acpi_processor_notify(struct acpi_device *device, u32 event);
>  static acpi_status acpi_processor_hotadd_init(acpi_handle handle, int *p_cpu);
>  static int acpi_processor_handle_eject(struct acpi_processor *pr);
>  
> @@ -378,7 +375,7 @@ static int acpi_processor_get_info(struct acpi_device *device)
>  
>  static DEFINE_PER_CPU(void *, processor_device_array);
>  
> -static void acpi_processor_notify(struct acpi_device *device, u32 event)
> +void acpi_processor_notify(struct acpi_device *device, u32 event)
>  {
>  	struct acpi_processor *pr = acpi_driver_data(device);
>  	int saved;
> @@ -442,7 +439,7 @@ static struct notifier_block acpi_cpu_notifier =
>  	    .notifier_call = acpi_cpu_soft_notify,
>  };
>  
> -static int __cpuinit acpi_processor_add(struct acpi_device *device)
> +int __cpuinit acpi_processor_add(struct acpi_device *device)
>  {
>  	struct acpi_processor *pr = NULL;
>  	int result = 0;
> @@ -545,7 +542,7 @@ err_free_cpumask:
>  	return result;
>  }
>  
> -static int acpi_processor_remove(struct acpi_device *device, int type)
> +int acpi_processor_remove(struct acpi_device *device, int type)
>  {
>  	struct acpi_processor *pr = NULL;
>  
> @@ -758,7 +755,6 @@ static int acpi_processor_handle_eject(struct acpi_processor *pr)
>  }
>  #endif
>  
> -static
>  void acpi_processor_install_hotplug_notify(void)
>  {
>  #ifdef CONFIG_ACPI_HOTPLUG_CPU
> @@ -771,7 +767,6 @@ void acpi_processor_install_hotplug_notify(void)
>  	register_hotcpu_notifier(&acpi_cpu_notifier);
>  }
>  
> -static
>  void acpi_processor_uninstall_hotplug_notify(void)
>  {
>  #ifdef CONFIG_ACPI_HOTPLUG_CPU
> diff --git a/drivers/acpi/processor_perflib.c b/drivers/acpi/processor_perflib.c
> index 85b3237..22c6195 100644
> --- a/drivers/acpi/processor_perflib.c
> +++ b/drivers/acpi/processor_perflib.c
> @@ -386,7 +386,7 @@ static int acpi_processor_get_performance_states(struct acpi_processor *pr)
>  	return result;
>  }
>  
> -static int acpi_processor_get_performance_info(struct acpi_processor *pr)
> +int acpi_processor_get_performance_info(struct acpi_processor *pr)
>  {
>  	int result = 0;
>  	acpi_status status = AE_OK;
> @@ -492,7 +492,7 @@ int acpi_processor_notify_smm(struct module *calling_module)
>  
>  EXPORT_SYMBOL(acpi_processor_notify_smm);
>  
> -static int acpi_processor_get_psd(struct acpi_processor	*pr)
> +int acpi_processor_get_psd(struct acpi_processor	*pr)
>  {
>  	int result = 0;
>  	acpi_status status = AE_OK;
> diff --git a/include/acpi/processor.h b/include/acpi/processor.h
> index 610f6fb..12657bb 100644
> --- a/include/acpi/processor.h
> +++ b/include/acpi/processor.h
> @@ -239,6 +239,12 @@ extern void acpi_processor_unregister_performance(struct
>           if a _PPC object exists, rmmod is disallowed then */
>  int acpi_processor_notify_smm(struct module *calling_module);
>  
> +void acpi_processor_install_hotplug_notify(void);
> +void acpi_processor_uninstall_hotplug_notify(void);
> +
> +int acpi_processor_add(struct acpi_device *device);
> +int acpi_processor_remove(struct acpi_device *device, int type);
> +void acpi_processor_notify(struct acpi_device *device, u32 event);
>  /* for communication between multiple parts of the processor kernel module */
>  DECLARE_PER_CPU(struct acpi_processor *, processors);
>  extern struct acpi_processor_errata errata;
> @@ -278,7 +284,9 @@ static inline void acpi_processor_ffh_cstate_enter(struct acpi_processor_cx
>  void acpi_processor_ppc_init(void);
>  void acpi_processor_ppc_exit(void);
>  int acpi_processor_ppc_has_changed(struct acpi_processor *pr, int event_flag);
> -extern int acpi_processor_get_bios_limit(int cpu, unsigned int *limit);
> +int acpi_processor_get_performance_info(struct acpi_processor *pr);
> +int acpi_processor_get_psd(struct acpi_processor *pr);
> +int acpi_processor_get_bios_limit(int cpu, unsigned int *limit);
>  #else
>  static inline void acpi_processor_ppc_init(void)
>  {
> -- 
> 1.7.7.3

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 21:37:56 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 21:37:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbfTB-0003XP-4Q; Fri, 16 Dec 2011 21:37:33 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RbfTA-0003X6-5T
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 21:37:32 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1324071444!7544654!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDQ2MDg3\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31355 invoked from network); 16 Dec 2011 21:37:25 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-15.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 16 Dec 2011 21:37:25 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pBGLbFYq010971
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 16 Dec 2011 21:37:15 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pBGLbELm025891
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 16 Dec 2011 21:37:14 GMT
Received: from abhmt108.oracle.com (abhmt108.oracle.com [141.146.116.60])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pBGLbCAd005915; Fri, 16 Dec 2011 15:37:12 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 16 Dec 2011 13:37:12 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 91ADB40196; Fri, 16 Dec 2011 16:36:18 -0500 (EST)
Date: Fri, 16 Dec 2011 16:36:18 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: ke.yu@intel.com, kevin.tian@intel.com, linux-kernel@vger.kernel.org,
	linux-acpi@vger.kernel.org, lenb@kernel.org, rjw@sisk.pl
Message-ID: <20111216213618.GB9832@phenom.dumpdata.com>
References: <1322673664-14642-1-git-send-email-konrad.wilk@oracle.com>
	<1322673664-14642-5-git-send-email-konrad.wilk@oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1322673664-14642-5-git-send-email-konrad.wilk@oracle.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090205.4EEBBA0D.0085,ss=1,re=0.000,fgs=0
Cc: jeremy@goop.org, xen-devel@lists.xensource.com, Ian.Campbell@citrix.com,
	mike.mcclurg@citrix.com, stefan.bader@canonical.com,
	konrad@kernel.org, liang.tang@oracle.com
Subject: Re: [Xen-devel] [PATCH 4/8] ACPI: processor: Don't setup cpu idle
 driver and handler when we do not want them.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Nov 30, 2011 at 12:21:00PM -0500, Konrad Rzeszutek Wilk wrote:
> From: Kevin Tian <kevin.tian@intel.com>
> 
> This patch inhibits processing of the CPU idle handler if it is not
> set to the appropiate one. This is needed by the Xen processor driver
> which, while still needing processor details, wants to use the default_idle
> call (which makes a yield hypercall).

Which I think is not required anymore with the d91ee5863b71e8c90eaf6035bff3078a85e2e7b5
(cpuidle: replace xen access to x86 pm_idle and default_idle) and
62027aea23fcd14478abdddd3b74a4e0f5fb2984
(cpuidle: create bootparam "cpuidle.off=1")

Liang, can you double-check that please?

> 
> Signed-off-by: Yu Ke <ke.yu@intel.com>
> Signed-off-by: Tian Kevin <kevin.tian@intel.com>
> Signed-off-by: Tang Liang <liang.tang@oracle.com>
> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> ---
>  drivers/acpi/processor_idle.c |    8 +++++---
>  1 files changed, 5 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/acpi/processor_idle.c b/drivers/acpi/processor_idle.c
> index d88974a..0ad347f 100644
> --- a/drivers/acpi/processor_idle.c
> +++ b/drivers/acpi/processor_idle.c
> @@ -1127,7 +1127,7 @@ int acpi_processor_hotplug(struct acpi_processor *pr)
>  	cpuidle_pause_and_lock();
>  	cpuidle_disable_device(&pr->power.dev);
>  	acpi_processor_get_power_info(pr);
> -	if (pr->flags.power) {
> +	if (pr->flags.power  && (cpuidle_get_driver() == &acpi_idle_driver)) {
>  		acpi_processor_setup_cpuidle_cx(pr);
>  		ret = cpuidle_enable_device(&pr->power.dev);
>  	}
> @@ -1183,7 +1183,8 @@ int acpi_processor_cst_has_changed(struct acpi_processor *pr)
>  			if (!_pr || !_pr->flags.power_setup_done)
>  				continue;
>  			acpi_processor_get_power_info(_pr);
> -			if (_pr->flags.power) {
> +			if (_pr->flags.power && (cpuidle_get_driver()
> +						== &acpi_idle_driver)) {
>  				acpi_processor_setup_cpuidle_cx(_pr);
>  				cpuidle_enable_device(&_pr->power.dev);
>  			}
> @@ -1237,7 +1238,8 @@ int __cpuinit acpi_processor_power_init(struct acpi_processor *pr,
>  	 * Note that we use previously set idle handler will be used on
>  	 * platforms that only support C1.
>  	 */
> -	if (pr->flags.power) {
> +	if (pr->flags.power && (__acpi_processor_register_driver ==
> +				acpi_processor_register_driver)) {
>  		/* Register acpi_idle_driver if not already registered */
>  		if (!acpi_processor_registered) {
>  			acpi_processor_setup_cpuidle_states(pr);
> -- 
> 1.7.7.3

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 21:37:56 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 21:37:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbfTB-0003XP-4Q; Fri, 16 Dec 2011 21:37:33 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RbfTA-0003X6-5T
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 21:37:32 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1324071444!7544654!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDQ2MDg3\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31355 invoked from network); 16 Dec 2011 21:37:25 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-15.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 16 Dec 2011 21:37:25 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pBGLbFYq010971
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 16 Dec 2011 21:37:15 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pBGLbELm025891
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 16 Dec 2011 21:37:14 GMT
Received: from abhmt108.oracle.com (abhmt108.oracle.com [141.146.116.60])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pBGLbCAd005915; Fri, 16 Dec 2011 15:37:12 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 16 Dec 2011 13:37:12 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 91ADB40196; Fri, 16 Dec 2011 16:36:18 -0500 (EST)
Date: Fri, 16 Dec 2011 16:36:18 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: ke.yu@intel.com, kevin.tian@intel.com, linux-kernel@vger.kernel.org,
	linux-acpi@vger.kernel.org, lenb@kernel.org, rjw@sisk.pl
Message-ID: <20111216213618.GB9832@phenom.dumpdata.com>
References: <1322673664-14642-1-git-send-email-konrad.wilk@oracle.com>
	<1322673664-14642-5-git-send-email-konrad.wilk@oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1322673664-14642-5-git-send-email-konrad.wilk@oracle.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090205.4EEBBA0D.0085,ss=1,re=0.000,fgs=0
Cc: jeremy@goop.org, xen-devel@lists.xensource.com, Ian.Campbell@citrix.com,
	mike.mcclurg@citrix.com, stefan.bader@canonical.com,
	konrad@kernel.org, liang.tang@oracle.com
Subject: Re: [Xen-devel] [PATCH 4/8] ACPI: processor: Don't setup cpu idle
 driver and handler when we do not want them.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Nov 30, 2011 at 12:21:00PM -0500, Konrad Rzeszutek Wilk wrote:
> From: Kevin Tian <kevin.tian@intel.com>
> 
> This patch inhibits processing of the CPU idle handler if it is not
> set to the appropiate one. This is needed by the Xen processor driver
> which, while still needing processor details, wants to use the default_idle
> call (which makes a yield hypercall).

Which I think is not required anymore with the d91ee5863b71e8c90eaf6035bff3078a85e2e7b5
(cpuidle: replace xen access to x86 pm_idle and default_idle) and
62027aea23fcd14478abdddd3b74a4e0f5fb2984
(cpuidle: create bootparam "cpuidle.off=1")

Liang, can you double-check that please?

> 
> Signed-off-by: Yu Ke <ke.yu@intel.com>
> Signed-off-by: Tian Kevin <kevin.tian@intel.com>
> Signed-off-by: Tang Liang <liang.tang@oracle.com>
> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> ---
>  drivers/acpi/processor_idle.c |    8 +++++---
>  1 files changed, 5 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/acpi/processor_idle.c b/drivers/acpi/processor_idle.c
> index d88974a..0ad347f 100644
> --- a/drivers/acpi/processor_idle.c
> +++ b/drivers/acpi/processor_idle.c
> @@ -1127,7 +1127,7 @@ int acpi_processor_hotplug(struct acpi_processor *pr)
>  	cpuidle_pause_and_lock();
>  	cpuidle_disable_device(&pr->power.dev);
>  	acpi_processor_get_power_info(pr);
> -	if (pr->flags.power) {
> +	if (pr->flags.power  && (cpuidle_get_driver() == &acpi_idle_driver)) {
>  		acpi_processor_setup_cpuidle_cx(pr);
>  		ret = cpuidle_enable_device(&pr->power.dev);
>  	}
> @@ -1183,7 +1183,8 @@ int acpi_processor_cst_has_changed(struct acpi_processor *pr)
>  			if (!_pr || !_pr->flags.power_setup_done)
>  				continue;
>  			acpi_processor_get_power_info(_pr);
> -			if (_pr->flags.power) {
> +			if (_pr->flags.power && (cpuidle_get_driver()
> +						== &acpi_idle_driver)) {
>  				acpi_processor_setup_cpuidle_cx(_pr);
>  				cpuidle_enable_device(&_pr->power.dev);
>  			}
> @@ -1237,7 +1238,8 @@ int __cpuinit acpi_processor_power_init(struct acpi_processor *pr,
>  	 * Note that we use previously set idle handler will be used on
>  	 * platforms that only support C1.
>  	 */
> -	if (pr->flags.power) {
> +	if (pr->flags.power && (__acpi_processor_register_driver ==
> +				acpi_processor_register_driver)) {
>  		/* Register acpi_idle_driver if not already registered */
>  		if (!acpi_processor_registered) {
>  			acpi_processor_setup_cpuidle_states(pr);
> -- 
> 1.7.7.3

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 21:54:50 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 21:54:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbfjY-0003md-PY; Fri, 16 Dec 2011 21:54:28 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RbfjX-0003mY-46
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 21:54:27 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1324072460!7543938!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjU3OQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24481 invoked from network); 16 Dec 2011 21:54:20 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Dec 2011 21:54:20 -0000
X-IronPort-AV: E=Sophos;i="4.71,365,1320624000"; 
   d="scan'208";a="9523984"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Dec 2011 21:54:19 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 16 Dec 2011 21:54:19 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RbfjP-0000Ad-LI;
	Fri, 16 Dec 2011 21:54:19 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RbfjP-0004c0-CC;
	Fri, 16 Dec 2011 21:54:19 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10522-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 16 Dec 2011 21:54:19 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10522: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10522 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10522/

Regressions :-(

Tests which did not succeed and are blocking:
 test-i386-i386-pv             5 xen-boot                  fail REGR. vs. 10517

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-sedf     14 guest-localmigrate/x10       fail   like 10504
 test-amd64-i386-win-vcpus1    7 windows-install              fail   like 10517
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass

version targeted for testing:
 xen                  1452fb248cd5
baseline version:
 xen                  01c8b27e3d7d

------------------------------------------------------------
People who touched revisions under test:
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            fail    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   24417:1452fb248cd5
tag:         tip
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Dec 16 15:45:40 2011 +0100
    
    x86/emulator: workaround for AMD erratum 573
    
    The only cases where we might end up emulating fsincos (as any other
    x87 operations without memory operands) are
    - when a HVM guest is in real mode (not applicable on AMD)
    - between two half page table updates in PAE mode (unlikely, and not
      doing the emulation here does affect only performance, not
      correctness)
    - when a guest maliciously (or erroneously) modifies an (MMIO or page
      table update) instruction under emulation (unspecified behavior)
    
    Hence, in order to avoid the erratum to cause harm to the entire host,
    don't emulate fsincos on the affected AMD CPU families.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24416:01c8b27e3d7d
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Thu Dec 15 16:56:21 2011 +0000
    
    libxl: remove stubdom device model save file when destroying stubdom
    
    /var/lib/xen/qemu-save.<domid> is created when the stub domain is started
    (connected to a stubdom console) and is used to save the device model state on
    suspend/migrate but never cleaned up.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
========================================
commit 54e24021005458ad0a361c1d83011b751726a94b
Author: Ian Jackson <ian.jackson@eu.citrix.com>
Date:   Thu Dec 8 16:38:06 2011 +0000

    qemu_get_timer: Provide a comment about the behaviour on ts==NULL
    
    Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 21:54:50 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 21:54:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbfjY-0003md-PY; Fri, 16 Dec 2011 21:54:28 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RbfjX-0003mY-46
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 21:54:27 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1324072460!7543938!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjU3OQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24481 invoked from network); 16 Dec 2011 21:54:20 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Dec 2011 21:54:20 -0000
X-IronPort-AV: E=Sophos;i="4.71,365,1320624000"; 
   d="scan'208";a="9523984"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Dec 2011 21:54:19 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 16 Dec 2011 21:54:19 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RbfjP-0000Ad-LI;
	Fri, 16 Dec 2011 21:54:19 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RbfjP-0004c0-CC;
	Fri, 16 Dec 2011 21:54:19 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10522-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 16 Dec 2011 21:54:19 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10522: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10522 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10522/

Regressions :-(

Tests which did not succeed and are blocking:
 test-i386-i386-pv             5 xen-boot                  fail REGR. vs. 10517

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-sedf     14 guest-localmigrate/x10       fail   like 10504
 test-amd64-i386-win-vcpus1    7 windows-install              fail   like 10517
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass

version targeted for testing:
 xen                  1452fb248cd5
baseline version:
 xen                  01c8b27e3d7d

------------------------------------------------------------
People who touched revisions under test:
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            fail    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   24417:1452fb248cd5
tag:         tip
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Dec 16 15:45:40 2011 +0100
    
    x86/emulator: workaround for AMD erratum 573
    
    The only cases where we might end up emulating fsincos (as any other
    x87 operations without memory operands) are
    - when a HVM guest is in real mode (not applicable on AMD)
    - between two half page table updates in PAE mode (unlikely, and not
      doing the emulation here does affect only performance, not
      correctness)
    - when a guest maliciously (or erroneously) modifies an (MMIO or page
      table update) instruction under emulation (unspecified behavior)
    
    Hence, in order to avoid the erratum to cause harm to the entire host,
    don't emulate fsincos on the affected AMD CPU families.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24416:01c8b27e3d7d
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Thu Dec 15 16:56:21 2011 +0000
    
    libxl: remove stubdom device model save file when destroying stubdom
    
    /var/lib/xen/qemu-save.<domid> is created when the stub domain is started
    (connected to a stubdom console) and is used to save the device model state on
    suspend/migrate but never cleaned up.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
========================================
commit 54e24021005458ad0a361c1d83011b751726a94b
Author: Ian Jackson <ian.jackson@eu.citrix.com>
Date:   Thu Dec 8 16:38:06 2011 +0000

    qemu_get_timer: Provide a comment about the behaviour on ts==NULL
    
    Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 22:05:25 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 22:05:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rbftn-00048t-4M; Fri, 16 Dec 2011 22:05:03 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Rbftl-00048o-CN
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 22:05:01 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1324073094!7770571!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ0MzA3NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19482 invoked from network); 16 Dec 2011 22:04:55 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-15.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 16 Dec 2011 22:04:55 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pBGM4kMb021675
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 16 Dec 2011 22:04:48 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pBGM4ftQ021350
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 16 Dec 2011 22:04:44 GMT
Received: from abhmt118.oracle.com (abhmt118.oracle.com [141.146.116.70])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pBGM4fM6005528; Fri, 16 Dec 2011 16:04:41 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 16 Dec 2011 14:04:36 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 85CBA40196; Fri, 16 Dec 2011 17:03:42 -0500 (EST)
Date: Fri, 16 Dec 2011 17:03:42 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: ke.yu@intel.com, kevin.tian@intel.com, linux-kernel@vger.kernel.org,
	linux-acpi@vger.kernel.org, lenb@kernel.org, rjw@sisk.pl
Message-ID: <20111216220342.GC9832@phenom.dumpdata.com>
References: <1322673664-14642-1-git-send-email-konrad.wilk@oracle.com>
	<1322673664-14642-4-git-send-email-konrad.wilk@oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1322673664-14642-4-git-send-email-konrad.wilk@oracle.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090207.4EEBC080.0113,ss=1,re=0.000,fgs=0
Cc: jeremy@goop.org, xen-devel@lists.xensource.com, Ian.Campbell@citrix.com,
	mike.mcclurg@citrix.com, stefan.bader@canonical.com,
	konrad@kernel.org, liang.tang@oracle.com
Subject: Re: [Xen-devel] [PATCH 3/8] ACPI: processor: add
 __acpi_processor_[un]register_driver helpers.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Nov 30, 2011 at 12:20:59PM -0500, Konrad Rzeszutek Wilk wrote:
> From: Tang Liang <liang.tang@oracle.com>
> 
> This patch implement __acpi_processor_[un]register_driver helper,
> so we can registry override processor driver function. Specifically
> the Xen processor driver.

Liang,

Is the reason we are doing this b/c we need to call acpi_bus_register_driver
and inhibit the registration of 'acpi_processor_driver' ?

And the reason we don't want 'acpi_processor_driver' to run is b/c of what?
If the cpuidle is disabled what is the harm of running the 'acpi_processor_driver'
driver?

> 
> By default the values are set to the native one.
> 
> Signed-off-by: Tang Liang <liang.tang@oracle.com>
> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> ---
>  drivers/acpi/processor_driver.c |   35 +++++++++++++++++++++++++++++------
>  include/acpi/processor.h        |    6 +++++-
>  2 files changed, 34 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/acpi/processor_driver.c b/drivers/acpi/processor_driver.c
> index 211c078..55f0b89 100644
> --- a/drivers/acpi/processor_driver.c
> +++ b/drivers/acpi/processor_driver.c
> @@ -90,6 +90,11 @@ static const struct acpi_device_id processor_device_ids[] = {
>  };
>  MODULE_DEVICE_TABLE(acpi, processor_device_ids);
>  
> +int (*__acpi_processor_register_driver)(void) = acpi_processor_register_driver;
> +void (*__acpi_processor_unregister_driver)(void) \
> +	= acpi_processor_unregister_driver;
> +
> +
>  static struct acpi_driver acpi_processor_driver = {
>  	.name = "processor",
>  	.class = ACPI_PROCESSOR_CLASS,
> @@ -779,6 +784,22 @@ void acpi_processor_uninstall_hotplug_notify(void)
>  	unregister_hotcpu_notifier(&acpi_cpu_notifier);
>  }
>  
> +int acpi_processor_register_driver(void)
> +{
> +	int result = 0;
> +
> +	result = acpi_bus_register_driver(&acpi_processor_driver);
> +	return result;
> +}
> +
> +void acpi_processor_unregister_driver(void)
> +{
> +	acpi_bus_unregister_driver(&acpi_processor_driver);
> +
> +	cpuidle_unregister_driver(&acpi_idle_driver);
> +
> +	return;
> +}
>  /*
>   * We keep the driver loaded even when ACPI is not running.
>   * This is needed for the powernow-k8 driver, that works even without
> @@ -794,9 +815,11 @@ static int __init acpi_processor_init(void)
>  
>  	memset(&errata, 0, sizeof(errata));
>  
> -	result = acpi_bus_register_driver(&acpi_processor_driver);
> -	if (result < 0)
> -		return result;
> +	if (__acpi_processor_register_driver) {
> +		result = __acpi_processor_register_driver();
> +		if (result < 0)
> +			return result;
> +	}
>  
>  	acpi_processor_install_hotplug_notify();
>  
> @@ -809,6 +832,7 @@ static int __init acpi_processor_init(void)
>  	return 0;
>  }
>  
> +
>  static void __exit acpi_processor_exit(void)
>  {
>  	if (acpi_disabled)
> @@ -820,9 +844,8 @@ static void __exit acpi_processor_exit(void)
>  
>  	acpi_processor_uninstall_hotplug_notify();
>  
> -	acpi_bus_unregister_driver(&acpi_processor_driver);
> -
> -	cpuidle_unregister_driver(&acpi_idle_driver);
> +	if (__acpi_processor_unregister_driver)
> +		__acpi_processor_unregister_driver();
>  
>  	return;
>  }
> diff --git a/include/acpi/processor.h b/include/acpi/processor.h
> index bd99fb6..969cbc9 100644
> --- a/include/acpi/processor.h
> +++ b/include/acpi/processor.h
> @@ -225,6 +225,9 @@ struct acpi_processor_errata {
>  	} piix4;
>  };
>  
> +extern int (*__acpi_processor_register_driver)(void);
> +extern void (*__acpi_processor_unregister_driver)(void);
> +
>  extern int acpi_processor_preregister_performance(struct
>  						  acpi_processor_performance
>  						  __percpu *performance);
> @@ -242,7 +245,8 @@ int acpi_processor_notify_smm(struct module *calling_module);
>  
>  void acpi_processor_install_hotplug_notify(void);
>  void acpi_processor_uninstall_hotplug_notify(void);
> -
> +int acpi_processor_register_driver(void);
> +void acpi_processor_unregister_driver(void);
>  int acpi_processor_add(struct acpi_device *device);
>  int acpi_processor_remove(struct acpi_device *device, int type);
>  void acpi_processor_notify(struct acpi_device *device, u32 event);
> -- 
> 1.7.7.3

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 22:05:25 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 22:05:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rbftn-00048t-4M; Fri, 16 Dec 2011 22:05:03 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Rbftl-00048o-CN
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 22:05:01 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1324073094!7770571!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ0MzA3NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19482 invoked from network); 16 Dec 2011 22:04:55 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-15.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 16 Dec 2011 22:04:55 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pBGM4kMb021675
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 16 Dec 2011 22:04:48 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pBGM4ftQ021350
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 16 Dec 2011 22:04:44 GMT
Received: from abhmt118.oracle.com (abhmt118.oracle.com [141.146.116.70])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pBGM4fM6005528; Fri, 16 Dec 2011 16:04:41 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 16 Dec 2011 14:04:36 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 85CBA40196; Fri, 16 Dec 2011 17:03:42 -0500 (EST)
Date: Fri, 16 Dec 2011 17:03:42 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: ke.yu@intel.com, kevin.tian@intel.com, linux-kernel@vger.kernel.org,
	linux-acpi@vger.kernel.org, lenb@kernel.org, rjw@sisk.pl
Message-ID: <20111216220342.GC9832@phenom.dumpdata.com>
References: <1322673664-14642-1-git-send-email-konrad.wilk@oracle.com>
	<1322673664-14642-4-git-send-email-konrad.wilk@oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1322673664-14642-4-git-send-email-konrad.wilk@oracle.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090207.4EEBC080.0113,ss=1,re=0.000,fgs=0
Cc: jeremy@goop.org, xen-devel@lists.xensource.com, Ian.Campbell@citrix.com,
	mike.mcclurg@citrix.com, stefan.bader@canonical.com,
	konrad@kernel.org, liang.tang@oracle.com
Subject: Re: [Xen-devel] [PATCH 3/8] ACPI: processor: add
 __acpi_processor_[un]register_driver helpers.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Nov 30, 2011 at 12:20:59PM -0500, Konrad Rzeszutek Wilk wrote:
> From: Tang Liang <liang.tang@oracle.com>
> 
> This patch implement __acpi_processor_[un]register_driver helper,
> so we can registry override processor driver function. Specifically
> the Xen processor driver.

Liang,

Is the reason we are doing this b/c we need to call acpi_bus_register_driver
and inhibit the registration of 'acpi_processor_driver' ?

And the reason we don't want 'acpi_processor_driver' to run is b/c of what?
If the cpuidle is disabled what is the harm of running the 'acpi_processor_driver'
driver?

> 
> By default the values are set to the native one.
> 
> Signed-off-by: Tang Liang <liang.tang@oracle.com>
> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> ---
>  drivers/acpi/processor_driver.c |   35 +++++++++++++++++++++++++++++------
>  include/acpi/processor.h        |    6 +++++-
>  2 files changed, 34 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/acpi/processor_driver.c b/drivers/acpi/processor_driver.c
> index 211c078..55f0b89 100644
> --- a/drivers/acpi/processor_driver.c
> +++ b/drivers/acpi/processor_driver.c
> @@ -90,6 +90,11 @@ static const struct acpi_device_id processor_device_ids[] = {
>  };
>  MODULE_DEVICE_TABLE(acpi, processor_device_ids);
>  
> +int (*__acpi_processor_register_driver)(void) = acpi_processor_register_driver;
> +void (*__acpi_processor_unregister_driver)(void) \
> +	= acpi_processor_unregister_driver;
> +
> +
>  static struct acpi_driver acpi_processor_driver = {
>  	.name = "processor",
>  	.class = ACPI_PROCESSOR_CLASS,
> @@ -779,6 +784,22 @@ void acpi_processor_uninstall_hotplug_notify(void)
>  	unregister_hotcpu_notifier(&acpi_cpu_notifier);
>  }
>  
> +int acpi_processor_register_driver(void)
> +{
> +	int result = 0;
> +
> +	result = acpi_bus_register_driver(&acpi_processor_driver);
> +	return result;
> +}
> +
> +void acpi_processor_unregister_driver(void)
> +{
> +	acpi_bus_unregister_driver(&acpi_processor_driver);
> +
> +	cpuidle_unregister_driver(&acpi_idle_driver);
> +
> +	return;
> +}
>  /*
>   * We keep the driver loaded even when ACPI is not running.
>   * This is needed for the powernow-k8 driver, that works even without
> @@ -794,9 +815,11 @@ static int __init acpi_processor_init(void)
>  
>  	memset(&errata, 0, sizeof(errata));
>  
> -	result = acpi_bus_register_driver(&acpi_processor_driver);
> -	if (result < 0)
> -		return result;
> +	if (__acpi_processor_register_driver) {
> +		result = __acpi_processor_register_driver();
> +		if (result < 0)
> +			return result;
> +	}
>  
>  	acpi_processor_install_hotplug_notify();
>  
> @@ -809,6 +832,7 @@ static int __init acpi_processor_init(void)
>  	return 0;
>  }
>  
> +
>  static void __exit acpi_processor_exit(void)
>  {
>  	if (acpi_disabled)
> @@ -820,9 +844,8 @@ static void __exit acpi_processor_exit(void)
>  
>  	acpi_processor_uninstall_hotplug_notify();
>  
> -	acpi_bus_unregister_driver(&acpi_processor_driver);
> -
> -	cpuidle_unregister_driver(&acpi_idle_driver);
> +	if (__acpi_processor_unregister_driver)
> +		__acpi_processor_unregister_driver();
>  
>  	return;
>  }
> diff --git a/include/acpi/processor.h b/include/acpi/processor.h
> index bd99fb6..969cbc9 100644
> --- a/include/acpi/processor.h
> +++ b/include/acpi/processor.h
> @@ -225,6 +225,9 @@ struct acpi_processor_errata {
>  	} piix4;
>  };
>  
> +extern int (*__acpi_processor_register_driver)(void);
> +extern void (*__acpi_processor_unregister_driver)(void);
> +
>  extern int acpi_processor_preregister_performance(struct
>  						  acpi_processor_performance
>  						  __percpu *performance);
> @@ -242,7 +245,8 @@ int acpi_processor_notify_smm(struct module *calling_module);
>  
>  void acpi_processor_install_hotplug_notify(void);
>  void acpi_processor_uninstall_hotplug_notify(void);
> -
> +int acpi_processor_register_driver(void);
> +void acpi_processor_unregister_driver(void);
>  int acpi_processor_add(struct acpi_device *device);
>  int acpi_processor_remove(struct acpi_device *device, int type);
>  void acpi_processor_notify(struct acpi_device *device, u32 event);
> -- 
> 1.7.7.3

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 22:23:18 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 22:23:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbgB5-0004Kp-1v; Fri, 16 Dec 2011 22:22:55 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RbgB4-0004Kj-E3
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 22:22:54 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1324074167!8185736!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDQ3NDYx\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11768 invoked from network); 16 Dec 2011 22:22:48 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-11.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Dec 2011 22:22:48 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pBGMMdTU026322
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 16 Dec 2011 22:22:40 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pBGMMaAC013153
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 16 Dec 2011 22:22:37 GMT
Received: from abhmt116.oracle.com (abhmt116.oracle.com [141.146.116.68])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pBGMMY20031564; Fri, 16 Dec 2011 16:22:35 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 16 Dec 2011 14:22:34 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 245BE40196; Fri, 16 Dec 2011 17:21:41 -0500 (EST)
Date: Fri, 16 Dec 2011 17:21:41 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: liang tang <liang.tang@oracle.com>
Message-ID: <20111216222140.GD9832@phenom.dumpdata.com>
References: <1322673664-14642-1-git-send-email-konrad.wilk@oracle.com>
	<1322673664-14642-6-git-send-email-konrad.wilk@oracle.com>
	<4ED755D70200007800064987@nat28.tlf.novell.com>
	<20111212172941.GA8619@phenom.dumpdata.com>
	<4EE710A00200007800067274@nat28.tlf.novell.com>
	<4EE71A62.9050700@oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4EE71A62.9050700@oracle.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090202.4EEBC4B1.002D,ss=1,re=0.000,fgs=0
Cc: jeremy@goop.org, xen-devel@lists.xensource.com,
	Jan Beulich <JBeulich@suse.com>, linux-acpi@vger.kernel.org,
	mike.mcclurg@citrix.com, kevin.tian@intel.com,
	stefan.bader@canonical.com, linux-kernel@vger.kernel.org,
	rjw@sisk.pl, konrad@kernel.org, ke.yu@intel.com, lenb@kernel.org,
	Ian.Campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH 5/8] ACPI: add processor driver for Xen
 virtual CPUs.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Dec 13, 2011 at 05:26:58PM +0800, liang tang wrote:
> On 2011-12-13 15:45, Jan Beulich wrote:
> >>>>On 12.12.11 at 18:29, Konrad Rzeszutek Wilk<konrad.wilk@oracle.com>  wrote:
> >>On Thu, Dec 01, 2011 at 09:24:23AM +0000, Jan Beulich wrote:
> >>>>>>On 30.11.11 at 18:21, Konrad Rzeszutek Wilk<konrad.wilk@oracle.com>  wrote:
> >>>>--- a/drivers/acpi/Makefile
> >>>>+++ b/drivers/acpi/Makefile
> >>>>@@ -66,6 +66,7 @@ obj-$(CONFIG_ACPI_CUSTOM_METHOD)+= custom_method.o
> >>>>  # processor has its own "processor." module_param namespace
> >>>>  processor-y			:= processor_driver.o processor_throttling.o
> >>>>  processor-y			+= processor_idle.o processor_thermal.o
> >>>>+processor-y			+= processor_xen.o
> >>>This should minimally be processor-$(CONFIG_XEN), with other things
> >>>adjusted as necessary.
> >>I was under the impression that this was required to get the
> >>processor_xen.ko
> >>to be a module. Otherwise it would only compile as built-in.
> >processor_xen.ko? Why not have all the code go into processor.ko?
> >(And the original construct didn't aim in that direction either.)
> >
> >Jan
> >
> the code about driver function which kernel
> require(drivers/acpi/processor_xen.c )  build into processor.ko.
> the code which have more relation with xen
> (drivers/xen/acpi_processor.c)  did not build into processor.ko.

I am not sure if I understand you. Are you saying that the bulk of
'acpi_processor' (in the drivers/xen directory) should not be built in
processor.o and that the config options will do that?

But the config option is for the drivers/acpi directory..

So if I enable CONFIG_ACPI_PROCESSOR and CONFIG_ACPI_PROCESSOR_XEN
then the build will stick processor_xen.o in to the processor.ko file.

And if I select CONFIG_ACPI_PROCESSOR and unselect CONFIG_ACPI_PROCESSOR_XEN
then I still get some of the processor_xen.o stuck in processor.ko file?
(Granted, there is not much that gets stuck in b/c the majority of the code
is guarded by a big #if defined(CONFIG_ACPI_PROCESSOR_XEN..) so the compiler
might not stick anything in there)


Is there a way to make it so there are _two_ modules:
 - processor.ko
 - processor-xen.ko [which uses some code from processor.ko]

And they both can work together? Well, .. such that processor.ko
does not really do anything since there are no cpuidle enabled, and
the processor-xen.ko just deals with the parsing of ACPI Pxx states.

And since cpuidle is disabled, there won't be any notify events sent anyhow
so that could be removed (ah wait. the processor_xen.c does call
processor_cntl_xen_notify(..PM_INIT) to pipe the data up.. so that is
needed).

In which case the processor-xen.ko only does one thing - parses the 
'struct acpi_processor' data and pipes it up the hypervisor.

Would this be feasible?

> liang

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 22:23:18 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 22:23:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbgB5-0004Kp-1v; Fri, 16 Dec 2011 22:22:55 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RbgB4-0004Kj-E3
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 22:22:54 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1324074167!8185736!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDQ3NDYx\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11768 invoked from network); 16 Dec 2011 22:22:48 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-11.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Dec 2011 22:22:48 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pBGMMdTU026322
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 16 Dec 2011 22:22:40 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pBGMMaAC013153
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 16 Dec 2011 22:22:37 GMT
Received: from abhmt116.oracle.com (abhmt116.oracle.com [141.146.116.68])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pBGMMY20031564; Fri, 16 Dec 2011 16:22:35 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 16 Dec 2011 14:22:34 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 245BE40196; Fri, 16 Dec 2011 17:21:41 -0500 (EST)
Date: Fri, 16 Dec 2011 17:21:41 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: liang tang <liang.tang@oracle.com>
Message-ID: <20111216222140.GD9832@phenom.dumpdata.com>
References: <1322673664-14642-1-git-send-email-konrad.wilk@oracle.com>
	<1322673664-14642-6-git-send-email-konrad.wilk@oracle.com>
	<4ED755D70200007800064987@nat28.tlf.novell.com>
	<20111212172941.GA8619@phenom.dumpdata.com>
	<4EE710A00200007800067274@nat28.tlf.novell.com>
	<4EE71A62.9050700@oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4EE71A62.9050700@oracle.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090202.4EEBC4B1.002D,ss=1,re=0.000,fgs=0
Cc: jeremy@goop.org, xen-devel@lists.xensource.com,
	Jan Beulich <JBeulich@suse.com>, linux-acpi@vger.kernel.org,
	mike.mcclurg@citrix.com, kevin.tian@intel.com,
	stefan.bader@canonical.com, linux-kernel@vger.kernel.org,
	rjw@sisk.pl, konrad@kernel.org, ke.yu@intel.com, lenb@kernel.org,
	Ian.Campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH 5/8] ACPI: add processor driver for Xen
 virtual CPUs.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Dec 13, 2011 at 05:26:58PM +0800, liang tang wrote:
> On 2011-12-13 15:45, Jan Beulich wrote:
> >>>>On 12.12.11 at 18:29, Konrad Rzeszutek Wilk<konrad.wilk@oracle.com>  wrote:
> >>On Thu, Dec 01, 2011 at 09:24:23AM +0000, Jan Beulich wrote:
> >>>>>>On 30.11.11 at 18:21, Konrad Rzeszutek Wilk<konrad.wilk@oracle.com>  wrote:
> >>>>--- a/drivers/acpi/Makefile
> >>>>+++ b/drivers/acpi/Makefile
> >>>>@@ -66,6 +66,7 @@ obj-$(CONFIG_ACPI_CUSTOM_METHOD)+= custom_method.o
> >>>>  # processor has its own "processor." module_param namespace
> >>>>  processor-y			:= processor_driver.o processor_throttling.o
> >>>>  processor-y			+= processor_idle.o processor_thermal.o
> >>>>+processor-y			+= processor_xen.o
> >>>This should minimally be processor-$(CONFIG_XEN), with other things
> >>>adjusted as necessary.
> >>I was under the impression that this was required to get the
> >>processor_xen.ko
> >>to be a module. Otherwise it would only compile as built-in.
> >processor_xen.ko? Why not have all the code go into processor.ko?
> >(And the original construct didn't aim in that direction either.)
> >
> >Jan
> >
> the code about driver function which kernel
> require(drivers/acpi/processor_xen.c )  build into processor.ko.
> the code which have more relation with xen
> (drivers/xen/acpi_processor.c)  did not build into processor.ko.

I am not sure if I understand you. Are you saying that the bulk of
'acpi_processor' (in the drivers/xen directory) should not be built in
processor.o and that the config options will do that?

But the config option is for the drivers/acpi directory..

So if I enable CONFIG_ACPI_PROCESSOR and CONFIG_ACPI_PROCESSOR_XEN
then the build will stick processor_xen.o in to the processor.ko file.

And if I select CONFIG_ACPI_PROCESSOR and unselect CONFIG_ACPI_PROCESSOR_XEN
then I still get some of the processor_xen.o stuck in processor.ko file?
(Granted, there is not much that gets stuck in b/c the majority of the code
is guarded by a big #if defined(CONFIG_ACPI_PROCESSOR_XEN..) so the compiler
might not stick anything in there)


Is there a way to make it so there are _two_ modules:
 - processor.ko
 - processor-xen.ko [which uses some code from processor.ko]

And they both can work together? Well, .. such that processor.ko
does not really do anything since there are no cpuidle enabled, and
the processor-xen.ko just deals with the parsing of ACPI Pxx states.

And since cpuidle is disabled, there won't be any notify events sent anyhow
so that could be removed (ah wait. the processor_xen.c does call
processor_cntl_xen_notify(..PM_INIT) to pipe the data up.. so that is
needed).

In which case the processor-xen.ko only does one thing - parses the 
'struct acpi_processor' data and pipes it up the hypervisor.

Would this be feasible?

> liang

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 22:40:15 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 22:40:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbgRR-0004dz-LM; Fri, 16 Dec 2011 22:39:49 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RbgRQ-0004du-3S
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 22:39:48 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1324075180!7596207!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDQ2MDg3\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8873 invoked from network); 16 Dec 2011 22:39:41 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-9.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Dec 2011 22:39:41 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pBGMdH2F009561
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 16 Dec 2011 22:39:18 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pBGMdGnu008959
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 16 Dec 2011 22:39:16 GMT
Received: from abhmt102.oracle.com (abhmt102.oracle.com [141.146.116.54])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pBGMdGGL023479; Fri, 16 Dec 2011 16:39:16 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 16 Dec 2011 14:39:15 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id F283B400BD; Fri, 16 Dec 2011 17:38:20 -0500 (EST)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: linux-kernel@vger.kernel.org, rjw@sisk.pl, x86@kernel.org,
	len.brown@intel.com, joseph.cihula@intel.com,
	linux-pm@lists.linux-foundation.org, tboot-devel@lists.sourceforge.net, 
	linux-acpi@vger.kernel.org, liang.tang@oracle.com
Date: Fri, 16 Dec 2011 17:38:13 -0500
Message-Id: <1324075099-11397-2-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.4
In-Reply-To: <1324075099-11397-1-git-send-email-konrad.wilk@oracle.com>
References: <1324075099-11397-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090202.4EEBC897.00A9,ss=1,re=0.000,fgs=0
Cc: Shane Wang <shane.wang@intel.com>, Thomas Gleixner <tglx@linutronix.de>,
	xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, hpa@zytor.com
Subject: [Xen-devel] [PATCH 1/7] x86, acpi,
	tboot: Have a ACPI os prepare sleep instead of calling tboot_sleep.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Tang Liang <liang.tang@oracle.com>

The ACPI suspend path makes a call to tboot_sleep right before
it writes the PM1A, PM1B values. We replace the direct call to
tboot via an registration callback similar to __acpi_register_gsi.

CC: Thomas Gleixner <tglx@linutronix.de>
CC: "H. Peter Anvin" <hpa@zytor.com>
CC: x86@kernel.org
CC: Len Brown <len.brown@intel.com>
CC: Joseph Cihula <joseph.cihula@intel.com>
CC: Shane Wang <shane.wang@intel.com>
CC: xen-devel@lists.xensource.com
CC: linux-pm@lists.linux-foundation.org
CC: tboot-devel@lists.sourceforge.net
CC: linux-acpi@vger.kernel.org
[v1: Added __attribute__ ((unused))]
[v2: Introduced a wrapper instead of changing tboot_sleep return values]
[v3: Added return value AE_CTRL_SKIP for acpi_os_sleep_prepare]
Signed-off-by: Tang Liang <liang.tang@oracle.com>
[v1: Fix compile issues on IA64 and PPC64]
[v2: Fix where __acpi_os_prepare_sleep==NULL and did not go in sleep properly]
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 arch/x86/kernel/tboot.c       |    8 ++++++++
 drivers/acpi/acpica/hwsleep.c |   10 +++++++---
 drivers/acpi/osl.c            |   24 ++++++++++++++++++++++++
 include/acpi/acexcep.h        |    1 +
 include/linux/acpi.h          |   10 ++++++++++
 include/linux/tboot.h         |    1 -
 6 files changed, 50 insertions(+), 4 deletions(-)

diff --git a/arch/x86/kernel/tboot.c b/arch/x86/kernel/tboot.c
index e2410e2..1a4ab7d 100644
--- a/arch/x86/kernel/tboot.c
+++ b/arch/x86/kernel/tboot.c
@@ -297,6 +297,12 @@ void tboot_sleep(u8 sleep_state, u32 pm1a_control, u32 pm1b_control)
 
 	tboot_shutdown(acpi_shutdown_map[sleep_state]);
 }
+static int tboot_sleep_wrapper(u8 sleep_state, u32 pm1a_control,
+			       u32 pm1b_control)
+{
+	tboot_sleep(sleep_state, pm1a_control, pm1b_control);
+	return 0;
+}
 
 static atomic_t ap_wfs_count;
 
@@ -345,6 +351,8 @@ static __init int tboot_late_init(void)
 
 	atomic_set(&ap_wfs_count, 0);
 	register_hotcpu_notifier(&tboot_cpu_notifier);
+
+	acpi_os_set_prepare_sleep(&tboot_sleep_wrapper);
 	return 0;
 }
 
diff --git a/drivers/acpi/acpica/hwsleep.c b/drivers/acpi/acpica/hwsleep.c
index d52da30..992359a 100644
--- a/drivers/acpi/acpica/hwsleep.c
+++ b/drivers/acpi/acpica/hwsleep.c
@@ -43,9 +43,9 @@
  */
 
 #include <acpi/acpi.h>
+#include <linux/acpi.h>
 #include "accommon.h"
 #include "actables.h"
-#include <linux/tboot.h>
 #include <linux/module.h>
 
 #define _COMPONENT          ACPI_HARDWARE
@@ -344,8 +344,12 @@ acpi_status asmlinkage acpi_enter_sleep_state(u8 sleep_state)
 
 	ACPI_FLUSH_CPU_CACHE();
 
-	tboot_sleep(sleep_state, pm1a_control, pm1b_control);
-
+	status = acpi_os_prepare_sleep(sleep_state, pm1a_control,
+				       pm1b_control);
+	if (ACPI_SKIP(status))
+		return_ACPI_STATUS(AE_OK);
+	if (ACPI_FAILURE(status))
+		return_ACPI_STATUS(status);
 	/* Write #2: Write both SLP_TYP + SLP_EN */
 
 	status = acpi_hw_write_pm1_control(pm1a_control, pm1b_control);
diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c
index f31c5c5..f3aae4b 100644
--- a/drivers/acpi/osl.c
+++ b/drivers/acpi/osl.c
@@ -76,6 +76,9 @@ EXPORT_SYMBOL(acpi_in_debugger);
 extern char line_buf[80];
 #endif				/*ENABLE_DEBUGGER */
 
+static int (*__acpi_os_prepare_sleep)(u8 sleep_state, u32 pm1a_ctrl,
+				      u32 pm1b_ctrl);
+
 static acpi_osd_handler acpi_irq_handler;
 static void *acpi_irq_context;
 static struct workqueue_struct *kacpid_wq;
@@ -1659,3 +1662,24 @@ acpi_status acpi_os_terminate(void)
 
 	return AE_OK;
 }
+
+acpi_status acpi_os_prepare_sleep(u8 sleep_state, u32 pm1a_control,
+				  u32 pm1b_control)
+{
+	int rc = 0;
+	if (__acpi_os_prepare_sleep)
+		rc = __acpi_os_prepare_sleep(sleep_state,
+					     pm1a_control, pm1b_control);
+	if (rc < 0)
+		return AE_ERROR;
+	else if (rc > 0)
+		return AE_CTRL_SKIP;
+
+	return AE_OK;
+}
+
+void acpi_os_set_prepare_sleep(int (*func)(u8 sleep_state,
+			       u32 pm1a_ctrl, u32 pm1b_ctrl))
+{
+	__acpi_os_prepare_sleep = func;
+}
diff --git a/include/acpi/acexcep.h b/include/acpi/acexcep.h
index 5b6c391..fa0d22c 100644
--- a/include/acpi/acexcep.h
+++ b/include/acpi/acexcep.h
@@ -57,6 +57,7 @@
 #define ACPI_SUCCESS(a)                 (!(a))
 #define ACPI_FAILURE(a)                 (a)
 
+#define ACPI_SKIP(a)                    (a == AE_CTRL_SKIP)
 #define AE_OK                           (acpi_status) 0x0000
 
 /*
diff --git a/include/linux/acpi.h b/include/linux/acpi.h
index 6001b4da..fccd017 100644
--- a/include/linux/acpi.h
+++ b/include/linux/acpi.h
@@ -359,4 +359,14 @@ static inline int suspend_nvs_register(unsigned long a, unsigned long b)
 }
 #endif
 
+#ifdef CONFIG_ACPI
+void acpi_os_set_prepare_sleep(int (*func)(u8 sleep_state,
+			       u32 pm1a_ctrl,  u32 pm1b_ctrl));
+
+acpi_status acpi_os_prepare_sleep(u8 sleep_state,
+				  u32 pm1a_control, u32 pm1b_control);
+#else
+#define acpi_os_set_prepare_sleep(func, pm1a_ctrl, pm1b_ctrl) do { } while (0)
+#endif
+
 #endif	/*_LINUX_ACPI_H*/
diff --git a/include/linux/tboot.h b/include/linux/tboot.h
index 1dba6ee..c75128b 100644
--- a/include/linux/tboot.h
+++ b/include/linux/tboot.h
@@ -143,7 +143,6 @@ static inline int tboot_enabled(void)
 
 extern void tboot_probe(void);
 extern void tboot_shutdown(u32 shutdown_type);
-extern void tboot_sleep(u8 sleep_state, u32 pm1a_control, u32 pm1b_control);
 extern struct acpi_table_header *tboot_get_dmar_table(
 				      struct acpi_table_header *dmar_tbl);
 extern int tboot_force_iommu(void);
-- 
1.7.7.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 22:40:15 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 22:40:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbgRR-0004dz-LM; Fri, 16 Dec 2011 22:39:49 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RbgRQ-0004du-3S
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 22:39:48 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1324075180!7596207!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDQ2MDg3\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8873 invoked from network); 16 Dec 2011 22:39:41 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-9.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Dec 2011 22:39:41 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pBGMdH2F009561
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 16 Dec 2011 22:39:18 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pBGMdGnu008959
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 16 Dec 2011 22:39:16 GMT
Received: from abhmt102.oracle.com (abhmt102.oracle.com [141.146.116.54])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pBGMdGGL023479; Fri, 16 Dec 2011 16:39:16 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 16 Dec 2011 14:39:15 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id F283B400BD; Fri, 16 Dec 2011 17:38:20 -0500 (EST)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: linux-kernel@vger.kernel.org, rjw@sisk.pl, x86@kernel.org,
	len.brown@intel.com, joseph.cihula@intel.com,
	linux-pm@lists.linux-foundation.org, tboot-devel@lists.sourceforge.net, 
	linux-acpi@vger.kernel.org, liang.tang@oracle.com
Date: Fri, 16 Dec 2011 17:38:13 -0500
Message-Id: <1324075099-11397-2-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.4
In-Reply-To: <1324075099-11397-1-git-send-email-konrad.wilk@oracle.com>
References: <1324075099-11397-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090202.4EEBC897.00A9,ss=1,re=0.000,fgs=0
Cc: Shane Wang <shane.wang@intel.com>, Thomas Gleixner <tglx@linutronix.de>,
	xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, hpa@zytor.com
Subject: [Xen-devel] [PATCH 1/7] x86, acpi,
	tboot: Have a ACPI os prepare sleep instead of calling tboot_sleep.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Tang Liang <liang.tang@oracle.com>

The ACPI suspend path makes a call to tboot_sleep right before
it writes the PM1A, PM1B values. We replace the direct call to
tboot via an registration callback similar to __acpi_register_gsi.

CC: Thomas Gleixner <tglx@linutronix.de>
CC: "H. Peter Anvin" <hpa@zytor.com>
CC: x86@kernel.org
CC: Len Brown <len.brown@intel.com>
CC: Joseph Cihula <joseph.cihula@intel.com>
CC: Shane Wang <shane.wang@intel.com>
CC: xen-devel@lists.xensource.com
CC: linux-pm@lists.linux-foundation.org
CC: tboot-devel@lists.sourceforge.net
CC: linux-acpi@vger.kernel.org
[v1: Added __attribute__ ((unused))]
[v2: Introduced a wrapper instead of changing tboot_sleep return values]
[v3: Added return value AE_CTRL_SKIP for acpi_os_sleep_prepare]
Signed-off-by: Tang Liang <liang.tang@oracle.com>
[v1: Fix compile issues on IA64 and PPC64]
[v2: Fix where __acpi_os_prepare_sleep==NULL and did not go in sleep properly]
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 arch/x86/kernel/tboot.c       |    8 ++++++++
 drivers/acpi/acpica/hwsleep.c |   10 +++++++---
 drivers/acpi/osl.c            |   24 ++++++++++++++++++++++++
 include/acpi/acexcep.h        |    1 +
 include/linux/acpi.h          |   10 ++++++++++
 include/linux/tboot.h         |    1 -
 6 files changed, 50 insertions(+), 4 deletions(-)

diff --git a/arch/x86/kernel/tboot.c b/arch/x86/kernel/tboot.c
index e2410e2..1a4ab7d 100644
--- a/arch/x86/kernel/tboot.c
+++ b/arch/x86/kernel/tboot.c
@@ -297,6 +297,12 @@ void tboot_sleep(u8 sleep_state, u32 pm1a_control, u32 pm1b_control)
 
 	tboot_shutdown(acpi_shutdown_map[sleep_state]);
 }
+static int tboot_sleep_wrapper(u8 sleep_state, u32 pm1a_control,
+			       u32 pm1b_control)
+{
+	tboot_sleep(sleep_state, pm1a_control, pm1b_control);
+	return 0;
+}
 
 static atomic_t ap_wfs_count;
 
@@ -345,6 +351,8 @@ static __init int tboot_late_init(void)
 
 	atomic_set(&ap_wfs_count, 0);
 	register_hotcpu_notifier(&tboot_cpu_notifier);
+
+	acpi_os_set_prepare_sleep(&tboot_sleep_wrapper);
 	return 0;
 }
 
diff --git a/drivers/acpi/acpica/hwsleep.c b/drivers/acpi/acpica/hwsleep.c
index d52da30..992359a 100644
--- a/drivers/acpi/acpica/hwsleep.c
+++ b/drivers/acpi/acpica/hwsleep.c
@@ -43,9 +43,9 @@
  */
 
 #include <acpi/acpi.h>
+#include <linux/acpi.h>
 #include "accommon.h"
 #include "actables.h"
-#include <linux/tboot.h>
 #include <linux/module.h>
 
 #define _COMPONENT          ACPI_HARDWARE
@@ -344,8 +344,12 @@ acpi_status asmlinkage acpi_enter_sleep_state(u8 sleep_state)
 
 	ACPI_FLUSH_CPU_CACHE();
 
-	tboot_sleep(sleep_state, pm1a_control, pm1b_control);
-
+	status = acpi_os_prepare_sleep(sleep_state, pm1a_control,
+				       pm1b_control);
+	if (ACPI_SKIP(status))
+		return_ACPI_STATUS(AE_OK);
+	if (ACPI_FAILURE(status))
+		return_ACPI_STATUS(status);
 	/* Write #2: Write both SLP_TYP + SLP_EN */
 
 	status = acpi_hw_write_pm1_control(pm1a_control, pm1b_control);
diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c
index f31c5c5..f3aae4b 100644
--- a/drivers/acpi/osl.c
+++ b/drivers/acpi/osl.c
@@ -76,6 +76,9 @@ EXPORT_SYMBOL(acpi_in_debugger);
 extern char line_buf[80];
 #endif				/*ENABLE_DEBUGGER */
 
+static int (*__acpi_os_prepare_sleep)(u8 sleep_state, u32 pm1a_ctrl,
+				      u32 pm1b_ctrl);
+
 static acpi_osd_handler acpi_irq_handler;
 static void *acpi_irq_context;
 static struct workqueue_struct *kacpid_wq;
@@ -1659,3 +1662,24 @@ acpi_status acpi_os_terminate(void)
 
 	return AE_OK;
 }
+
+acpi_status acpi_os_prepare_sleep(u8 sleep_state, u32 pm1a_control,
+				  u32 pm1b_control)
+{
+	int rc = 0;
+	if (__acpi_os_prepare_sleep)
+		rc = __acpi_os_prepare_sleep(sleep_state,
+					     pm1a_control, pm1b_control);
+	if (rc < 0)
+		return AE_ERROR;
+	else if (rc > 0)
+		return AE_CTRL_SKIP;
+
+	return AE_OK;
+}
+
+void acpi_os_set_prepare_sleep(int (*func)(u8 sleep_state,
+			       u32 pm1a_ctrl, u32 pm1b_ctrl))
+{
+	__acpi_os_prepare_sleep = func;
+}
diff --git a/include/acpi/acexcep.h b/include/acpi/acexcep.h
index 5b6c391..fa0d22c 100644
--- a/include/acpi/acexcep.h
+++ b/include/acpi/acexcep.h
@@ -57,6 +57,7 @@
 #define ACPI_SUCCESS(a)                 (!(a))
 #define ACPI_FAILURE(a)                 (a)
 
+#define ACPI_SKIP(a)                    (a == AE_CTRL_SKIP)
 #define AE_OK                           (acpi_status) 0x0000
 
 /*
diff --git a/include/linux/acpi.h b/include/linux/acpi.h
index 6001b4da..fccd017 100644
--- a/include/linux/acpi.h
+++ b/include/linux/acpi.h
@@ -359,4 +359,14 @@ static inline int suspend_nvs_register(unsigned long a, unsigned long b)
 }
 #endif
 
+#ifdef CONFIG_ACPI
+void acpi_os_set_prepare_sleep(int (*func)(u8 sleep_state,
+			       u32 pm1a_ctrl,  u32 pm1b_ctrl));
+
+acpi_status acpi_os_prepare_sleep(u8 sleep_state,
+				  u32 pm1a_control, u32 pm1b_control);
+#else
+#define acpi_os_set_prepare_sleep(func, pm1a_ctrl, pm1b_ctrl) do { } while (0)
+#endif
+
 #endif	/*_LINUX_ACPI_H*/
diff --git a/include/linux/tboot.h b/include/linux/tboot.h
index 1dba6ee..c75128b 100644
--- a/include/linux/tboot.h
+++ b/include/linux/tboot.h
@@ -143,7 +143,6 @@ static inline int tboot_enabled(void)
 
 extern void tboot_probe(void);
 extern void tboot_shutdown(u32 shutdown_type);
-extern void tboot_sleep(u8 sleep_state, u32 pm1a_control, u32 pm1b_control);
 extern struct acpi_table_header *tboot_get_dmar_table(
 				      struct acpi_table_header *dmar_tbl);
 extern int tboot_force_iommu(void);
-- 
1.7.7.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 23:39:14 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 23:39:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbhMN-0005CO-Be; Fri, 16 Dec 2011 23:38:39 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <xen-devel.GarveyPatrickD@OrdinaryAmerican.net>)
	id 1RbhMM-0005CJ-Cm
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 23:38:38 +0000
X-Env-Sender: xen-devel.GarveyPatrickD@OrdinaryAmerican.net
X-Msg-Ref: server-13.tower-27.messagelabs.com!1324078689!52537936!1
X-Originating-IP: [216.75.62.102]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18774 invoked from network); 16 Dec 2011 23:38:10 -0000
Received: from gourmet7.spamgourmet.com (HELO gourmet8.spamgourmet.com)
	(216.75.62.102) by server-13.tower-27.messagelabs.com with SMTP;
	16 Dec 2011 23:38:10 -0000
Received: from spamgourmet by gourmet7.spamgourmet.com with local (Exim 4.69)
	(envelope-from <xen-devel.GarveyPatrickD@OrdinaryAmerican.net>)
	id 1RbhMH-0001cV-Ds
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 23:38:33 +0000
Received: from mail-tul01m020-f176.google.com ([209.85.214.176])
	by gourmet7.spamgourmet.com with esmtp (Exim 4.69)
	(envelope-from <xen-devel.GarveyPatrickD@OrdinaryAmerican.net>)
	id 1RbhMH-0001cB-6x for
	+xen-devel+GarveyPatrickD+fbe7693c78.xen-devel#lists.xensource.com@spamgourmet.com;
	Fri, 16 Dec 2011 23:38:33 +0000
Received: by obcwn14 with SMTP id wn14so618251obc.7 for
	<+xen-devel+GarveyPatrickD+fbe7693c78.xen-devel#lists.xensource.com@spamgourmet.com>;
	Fri, 16 Dec 2011 15:38:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=y2E6zEgJ+K3PG/3QlhAg8sPcs9/4HntEzGGML9ZaNGM=;
	b=H8ay9PpgmqTqonDRFB7CKz14N+wUQpADf/LhDdC6CpC4KDTdA8He/M40KCDr/Q8FGJ
	WnRqlizUN3DqEwUTPGNU2b16crpdSESH2gWS4/0CxfzL5IcwB1k273S+tl5LewQqI4bG
	BDv3lJfMzOw/zctPEuJkbBgaTkQBjI7h24k3g=
MIME-Version: 1.0
Received: by 10.182.11.72 with SMTP id o8mr5277993obb.36.1324078712809; Fri,
	16 Dec 2011 15:38:32 -0800 (PST)
Received: by 10.182.16.163 with HTTP; Fri, 16 Dec 2011 15:38:32 -0800 (PST)
Date: Fri, 16 Dec 2011 15:38:32 -0800
Message-ID: <CACm5R6RY6oxN5KT_VjjvPwsbczBMhficjG0WQBrxffcU0jOuQA@mail.gmail.com>
From: xen-devel.GarveyPatrickD@OrdinaryAmerican.net
To: xen-devel@lists.xensource.com
X-Spamgourmet: 
Subject: [Xen-devel] OCaml Tutorial
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

It appears the OCaml Tutorial < www.ocaml-tutorial.org > referenced in
our XAPI Developer Guide wiki article <
http://wiki.xen.org/wiki/XAPI_Developer_Guide > is not reliably
accessible.  Can one of our experienced OCaml programmers suggest an
alternative that provides a sufficient tutorial for Xen users of
OCaml?  Is < http://mirror.ocamlcore.org/ocaml-tutorial.org/ >
sufficient?


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 16 23:39:14 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 Dec 2011 23:39:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbhMN-0005CO-Be; Fri, 16 Dec 2011 23:38:39 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <xen-devel.GarveyPatrickD@OrdinaryAmerican.net>)
	id 1RbhMM-0005CJ-Cm
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 23:38:38 +0000
X-Env-Sender: xen-devel.GarveyPatrickD@OrdinaryAmerican.net
X-Msg-Ref: server-13.tower-27.messagelabs.com!1324078689!52537936!1
X-Originating-IP: [216.75.62.102]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18774 invoked from network); 16 Dec 2011 23:38:10 -0000
Received: from gourmet7.spamgourmet.com (HELO gourmet8.spamgourmet.com)
	(216.75.62.102) by server-13.tower-27.messagelabs.com with SMTP;
	16 Dec 2011 23:38:10 -0000
Received: from spamgourmet by gourmet7.spamgourmet.com with local (Exim 4.69)
	(envelope-from <xen-devel.GarveyPatrickD@OrdinaryAmerican.net>)
	id 1RbhMH-0001cV-Ds
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 23:38:33 +0000
Received: from mail-tul01m020-f176.google.com ([209.85.214.176])
	by gourmet7.spamgourmet.com with esmtp (Exim 4.69)
	(envelope-from <xen-devel.GarveyPatrickD@OrdinaryAmerican.net>)
	id 1RbhMH-0001cB-6x for
	+xen-devel+GarveyPatrickD+fbe7693c78.xen-devel#lists.xensource.com@spamgourmet.com;
	Fri, 16 Dec 2011 23:38:33 +0000
Received: by obcwn14 with SMTP id wn14so618251obc.7 for
	<+xen-devel+GarveyPatrickD+fbe7693c78.xen-devel#lists.xensource.com@spamgourmet.com>;
	Fri, 16 Dec 2011 15:38:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=y2E6zEgJ+K3PG/3QlhAg8sPcs9/4HntEzGGML9ZaNGM=;
	b=H8ay9PpgmqTqonDRFB7CKz14N+wUQpADf/LhDdC6CpC4KDTdA8He/M40KCDr/Q8FGJ
	WnRqlizUN3DqEwUTPGNU2b16crpdSESH2gWS4/0CxfzL5IcwB1k273S+tl5LewQqI4bG
	BDv3lJfMzOw/zctPEuJkbBgaTkQBjI7h24k3g=
MIME-Version: 1.0
Received: by 10.182.11.72 with SMTP id o8mr5277993obb.36.1324078712809; Fri,
	16 Dec 2011 15:38:32 -0800 (PST)
Received: by 10.182.16.163 with HTTP; Fri, 16 Dec 2011 15:38:32 -0800 (PST)
Date: Fri, 16 Dec 2011 15:38:32 -0800
Message-ID: <CACm5R6RY6oxN5KT_VjjvPwsbczBMhficjG0WQBrxffcU0jOuQA@mail.gmail.com>
From: xen-devel.GarveyPatrickD@OrdinaryAmerican.net
To: xen-devel@lists.xensource.com
X-Spamgourmet: 
Subject: [Xen-devel] OCaml Tutorial
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

It appears the OCaml Tutorial < www.ocaml-tutorial.org > referenced in
our XAPI Developer Guide wiki article <
http://wiki.xen.org/wiki/XAPI_Developer_Guide > is not reliably
accessible.  Can one of our experienced OCaml programmers suggest an
alternative that provides a sufficient tutorial for Xen users of
OCaml?  Is < http://mirror.ocamlcore.org/ocaml-tutorial.org/ >
sufficient?


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Dec 17 02:02:12 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 17 Dec 2011 02: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.xensource.com>)
	id 1Rbjah-0002JR-FJ; Sat, 17 Dec 2011 02:01:35 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Rbjaf-0002JK-EA
	for xen-devel@lists.xensource.com; Sat, 17 Dec 2011 02:01:33 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1324087273!59294368!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjcxMg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7044 invoked from network); 17 Dec 2011 02:01:13 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Dec 2011 02:01:13 -0000
X-IronPort-AV: E=Sophos;i="4.71,366,1320624000"; 
   d="scan'208";a="9525566"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Dec 2011 02:01:31 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sat, 17 Dec 2011 02:01:31 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1Rbjad-0001bx-8f;
	Sat, 17 Dec 2011 02:01:31 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Rbjad-0006u4-81;
	Sat, 17 Dec 2011 02:01:31 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10524-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 17 Dec 2011 02:01:31 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10524: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10524 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10524/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass

version targeted for testing:
 xen                  a4bff36780a3
baseline version:
 xen                  01c8b27e3d7d

------------------------------------------------------------
People who touched revisions under test:
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-unstable
+ revision=a4bff36780a3
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-unstable a4bff36780a3
+ branch=xen-unstable
+ revision=a4bff36780a3
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ : xen@xenbits.xensource.com
+ : xen@xenbits.xensource.com:git/linux-pvops
+ : master
+ : tested/2.6.39.x
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r a4bff36780a3 ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 2 changesets with 6 changes to 6 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Dec 17 02:02:12 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 17 Dec 2011 02: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.xensource.com>)
	id 1Rbjah-0002JR-FJ; Sat, 17 Dec 2011 02:01:35 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Rbjaf-0002JK-EA
	for xen-devel@lists.xensource.com; Sat, 17 Dec 2011 02:01:33 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1324087273!59294368!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjcxMg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7044 invoked from network); 17 Dec 2011 02:01:13 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Dec 2011 02:01:13 -0000
X-IronPort-AV: E=Sophos;i="4.71,366,1320624000"; 
   d="scan'208";a="9525566"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Dec 2011 02:01:31 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sat, 17 Dec 2011 02:01:31 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1Rbjad-0001bx-8f;
	Sat, 17 Dec 2011 02:01:31 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Rbjad-0006u4-81;
	Sat, 17 Dec 2011 02:01:31 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10524-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 17 Dec 2011 02:01:31 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10524: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10524 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10524/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass

version targeted for testing:
 xen                  a4bff36780a3
baseline version:
 xen                  01c8b27e3d7d

------------------------------------------------------------
People who touched revisions under test:
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-unstable
+ revision=a4bff36780a3
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-unstable a4bff36780a3
+ branch=xen-unstable
+ revision=a4bff36780a3
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ : xen@xenbits.xensource.com
+ : xen@xenbits.xensource.com:git/linux-pvops
+ : master
+ : tested/2.6.39.x
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r a4bff36780a3 ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 2 changesets with 6 changes to 6 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Dec 17 03:01:31 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 17 Dec 2011 03: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.xensource.com>)
	id 1RbkWC-0003Bk-3y; Sat, 17 Dec 2011 03:01:00 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <amscanne@gridcentric.ca>) id 1RbkWA-0003Ac-9i
	for xen-devel@lists.xensource.com; Sat, 17 Dec 2011 03:00:58 +0000
X-Env-Sender: amscanne@gridcentric.ca
X-Msg-Ref: server-8.tower-21.messagelabs.com!1324090850!8536409!1
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24670 invoked from network); 17 Dec 2011 03:00:51 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Dec 2011 03:00:51 -0000
Received: by wgbds11 with SMTP id ds11so6118930wgb.24
	for <xen-devel@lists.xensource.com>;
	Fri, 16 Dec 2011 19:00:50 -0800 (PST)
Received: by 10.180.104.70 with SMTP id gc6mr15726524wib.42.1324090849216;
	Fri, 16 Dec 2011 19:00:49 -0800 (PST)
MIME-Version: 1.0
Received: by 10.223.120.68 with HTTP; Fri, 16 Dec 2011 19:00:28 -0800 (PST)
In-Reply-To: <20111202165003.GA7807@andromeda.dapyr.net>
References: <patchbomb.1322772713@xdev.gridcentric.ca>
	<1170bc32db41a7ae1e95.1322772715@xdev.gridcentric.ca>
	<20111202013430.GB636@andromeda.dapyr.net>
	<8940966a49442039be1480307f59656b.squirrel@webmail.lagarcavilla.org>
	<20111202165003.GA7807@andromeda.dapyr.net>
From: Adin Scannell <adin@gridcentric.ca>
Date: Fri, 16 Dec 2011 22:00:28 -0500
X-Google-Sender-Auth: qxy-PIaDzyjcCcoDrp3OmLN3gwI
Message-ID: <CAAJKtqpiJMY7syLMec5=wHp7L1aiY9cLzgCunw1JUCNF8NWV6Q@mail.gmail.com>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
Cc: olaf@aepfle.de, xen-devel@lists.xensource.com, andres@gridcentric.ca,
	jonathan.ludlam@eu.citrix.com,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>,
	jbeulich@suse.com, mike.mcclurg@citrix.com
Subject: Re: [Xen-devel] [PATCH 2 of 2] xenpaging: handle GNTST_eagain in
 kernel drivers
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

I had a chance to get a environment up and running with the Kernel
tip, so I've ported these patches.  As a requisite, I had to create a
patch that implements MMAP_BATCH_V2 first.  I'll be posting the set to
the mailing list very shortly for comment.

I wanted to revive this thread so there was a bit of context.

Cheers,
-Adin

On Fri, Dec 2, 2011 at 11:50 AM, Konrad Rzeszutek Wilk
<konrad@darnok.org> wrote:
> On Fri, Dec 02, 2011 at 07:27:20AM -0800, Andres Lagar-Cavilla wrote:
>> > On Thu, Dec 01, 2011 at 03:51:55PM -0500, Andres Lagar-Cavilla wrote:
>> >> =A0drivers/xen/blkback/blkback.c =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 6 +=
+-
>> >> =A0drivers/xen/blkback/interface.c =A0 =A0 =A0 =A0 =A0 =A0| =A0 9 +++-
>> >> =A0drivers/xen/core/gnttab.c =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0=
 4 +-
>> >> =A0drivers/xen/gntdev/gntdev.c =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A049
>> >> +++++++++++++++++------------
>> >> =A0drivers/xen/netback/interface.c =A0 =A0 =A0 =A0 =A0 =A0| =A0 5 +-
>> >> =A0drivers/xen/netback/netback.c =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A016 +=
+++++---
>> >> =A0drivers/xen/scsiback/interface.c =A0 =A0 =A0 =A0 =A0 | =A010 +++---
>> >> =A0drivers/xen/scsiback/scsiback.c =A0 =A0 =A0 =A0 =A0 =A0| =A0 4 +-
>> >> =A0drivers/xen/tpmback/interface.c =A0 =A0 =A0 =A0 =A0 =A0| =A0 7 +--
>> >> =A0drivers/xen/tpmback/tpmback.c =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A020 +=
+++-------
>> >> =A0drivers/xen/usbback/interface.c =A0 =A0 =A0 =A0 =A0 =A0| =A016 +++=
+----
>> >> =A0drivers/xen/usbback/usbback.c =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 4 +-
>> >> =A0drivers/xen/xenbus/xenbus_backend_client.c | =A010 +++---
>> >> =A0include/xen/gnttab.h =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |=
 =A037 ++++++++++++++++++++++
>> >> =A014 files changed, 126 insertions(+), 71 deletions(-)
>> >>
>> >>
>> >> Handle GNTST_eagain status from GNTTABOP_map_grant_ref and
>> >> GNTTABOP_copy operations properly to allow usage of xenpaging without
>> >> causing crashes or data corruption.
>> >>
>> >> Replace all relevant HYPERVISOR_grant_table_op() calls with a retry
>> >> loop. This loop is implemented as a macro to allow different
>> >> GNTTABOP_* args. It will sleep up to 33 seconds and wait for the
>> >> page to be paged in again.
>> >>
>> >> All ->status checks were updated to use the GNTST_* namespace. All
>> >> return values are converted from GNTST_* namespace to 0/-EINVAL, since
>> >> all callers did not use the actual return value.
>> >
>> > Any plans to do this for the pvops tree?
>> Slowly but surely. Working with XCP presently, so pvops is not at the top
>> of my stack. Do you want to get at a specific merge window?
>
> Its more of a review concern. Meaning that if you send for the upstream
> kernel lots of folks are going to be looking at it. So the patches
> will change - which means that the version upstream can be very
> different from the one that you have for XCP - so in the end you will
> have to deal with two different code-bases to maintain.
>
> That can get a bit difficult to manage.
>
> Granted not all of those drivers are in the upstream kernel so might not
> make any difference.
>
>>
>> Andres
>> >
>> >>
>> >> Signed-off-by: Olaf Hering <olaf@aepfle.de>
>> >> Acked-by: Patrick Colp <pjcolp@cs.ubc.ca>
>> >>
>> >> This is a port from xenlinux 2.6.18 to the 2.6.32 xcp tree
>> >> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
>> >>
>> >> diff -r df9e25a0189b -r 1170bc32db41 drivers/xen/blkback/blkback.c
>> >> --- a/drivers/xen/blkback/blkback.c
>> >> +++ b/drivers/xen/blkback/blkback.c
>> >> @@ -701,11 +701,13 @@ static void dispatch_rw_block_io(blkif_t
>> >> =A0 =A0BUG_ON(ret);
>> >>
>> >> =A0 =A0for (i =3D 0; i < nseg; i++) {
>> >> - =A0 =A0 =A0 =A0 =A0if (unlikely(map[i].status !=3D 0)) {
>> >> + =A0 =A0 =A0 =A0 =A0if (unlikely(map[i].status =3D=3D GNTST_eagain))
>> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0gnttab_check_GNTST_eagain_do_whi=
le(GNTTABOP_map_grant_ref, &map[i]);
>> >> + =A0 =A0 =A0 =A0 =A0if (unlikely(map[i].status !=3D GNTST_okay)) {
>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0DPRINTK("grant map of dom %u g=
ref %u failed: status %d\n",
>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0blkif->domid, =
req->seg[i].gref, map[i].status);
>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0map[i].handle =3D BLKBACK_INVA=
LID_HANDLE;
>> >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ret |=3D 1;
>> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ret =3D 1;
>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0continue;
>> >> =A0 =A0 =A0 =A0 =A0 =A0}
>> >>
>> >> diff -r df9e25a0189b -r 1170bc32db41 drivers/xen/blkback/interface.c
>> >> --- a/drivers/xen/blkback/interface.c
>> >> +++ b/drivers/xen/blkback/interface.c
>> >> @@ -95,7 +95,7 @@ static int map_frontend_pages(blkif_t *b
>> >> =A0 =A0struct vm_struct *area =3D blkif->blk_ring_area;
>> >> =A0 =A0struct gnttab_map_grant_ref op[BLKIF_MAX_RING_PAGES];
>> >> =A0 =A0unsigned int i;
>> >> - =A0int status =3D 0;
>> >> + =A0int status =3D GNTST_okay;
>> >>
>> >> =A0 =A0for (i =3D 0; i < nr_shared_pages; i++) {
>> >> =A0 =A0 =A0 =A0 =A0 =A0unsigned long addr =3D (unsigned long)area->ad=
dr +
>> >> @@ -110,7 +110,10 @@ static int map_frontend_pages(blkif_t *b
>> >> =A0 =A0 =A0 =A0 =A0 =A0BUG();
>> >>
>> >> =A0 =A0for (i =3D 0; i < nr_shared_pages; i++) {
>> >> - =A0 =A0 =A0 =A0 =A0if ((status =3D op[i].status) !=3D 0) {
>> >> + =A0 =A0 =A0 =A0 =A0if (op[i].status =3D=3D GNTST_eagain)
>> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0gnttab_check_GNTST_eagain_do_whi=
le(GNTTABOP_map_grant_ref, &op[i]);
>> >> + =A0 =A0 =A0 =A0 =A0if (op[i].status !=3D GNTST_okay) {
>> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0status =3D op[i].status;
>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0blkif->shmem_handle[i] =3D INV=
ALID_GRANT_HANDLE;
>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0continue;
>> >> =A0 =A0 =A0 =A0 =A0 =A0}
>> >> @@ -120,7 +123,7 @@ static int map_frontend_pages(blkif_t *b
>> >>
>> >> =A0 =A0blkif->nr_shared_pages =3D nr_shared_pages;
>> >>
>> >> - =A0if (status !=3D 0) {
>> >> + =A0if (status !=3D GNTST_okay) {
>> >> =A0 =A0 =A0 =A0 =A0 =A0DPRINTK(" Grant table operation failure !\n");
>> >> =A0 =A0 =A0 =A0 =A0 =A0unmap_frontend_pages(blkif);
>> >> =A0 =A0}
>> >> diff -r df9e25a0189b -r 1170bc32db41 drivers/xen/core/gnttab.c
>> >> --- a/drivers/xen/core/gnttab.c
>> >> +++ b/drivers/xen/core/gnttab.c
>> >> @@ -773,7 +773,7 @@ static int gnttab_map(unsigned int start
>> >> =A0 =A0 =A0 =A0 =A0 =A0return -ENOSYS;
>> >> =A0 =A0}
>> >>
>> >> - =A0BUG_ON(rc || setup.status);
>> >> + =A0BUG_ON(rc || (setup.status !=3D GNTST_okay));
>> >>
>> >> =A0 =A0if (shared.raw =3D=3D NULL)
>> >> =A0 =A0 =A0 =A0 =A0 =A0shared.raw =3D arch_gnttab_alloc_shared(gframe=
s);
>> >> @@ -901,7 +901,7 @@ int gnttab_copy_grant_page(grant_ref_t r
>> >> =A0 =A0err =3D HYPERVISOR_grant_table_op(GNTTABOP_unmap_and_replace,
>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0&unmap, 1);
>> >> =A0 =A0BUG_ON(err);
>> >> - =A0BUG_ON(unmap.status);
>> >> + =A0BUG_ON(unmap.status !=3D GNTST_okay);
>> >>
>> >> =A0 =A0write_sequnlock_irq(&gnttab_dma_lock);
>> >>
>> >> diff -r df9e25a0189b -r 1170bc32db41 drivers/xen/gntdev/gntdev.c
>> >> --- a/drivers/xen/gntdev/gntdev.c
>> >> +++ b/drivers/xen/gntdev/gntdev.c
>> >> @@ -503,7 +503,7 @@ static int gntdev_mmap (struct file *fli
>> >> =A0 =A0uint64_t ptep;
>> >> =A0 =A0int ret;
>> >> =A0 =A0int flags;
>> >> - =A0int i;
>> >> + =A0int i, exit_ret;
>> >> =A0 =A0struct page *page;
>> >> =A0 =A0gntdev_file_private_data_t *private_data =3D flip->private_dat=
a;
>> >>
>> >> @@ -578,6 +578,7 @@ static int gntdev_mmap (struct file *fli
>> >> =A0 =A0vma->vm_mm->context.has_foreign_mappings =3D 1;
>> >> =A0#endif
>> >>
>> >> + =A0exit_ret =3D -ENOMEM;
>> >> =A0 =A0for (i =3D 0; i < size; ++i) {
>> >>
>> >> =A0 =A0 =A0 =A0 =A0 =A0flags =3D GNTMAP_host_map;
>> >> @@ -598,14 +599,18 @@ static int gntdev_mmap (struct file *fli
>> >> =A0 =A0 =A0 =A0 =A0 =A0ret =3D HYPERVISOR_grant_table_op(GNTTABOP_map=
_grant_ref,
>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0&op, 1);
>> >> =A0 =A0 =A0 =A0 =A0 =A0BUG_ON(ret);
>> >> - =A0 =A0 =A0 =A0 =A0if (op.status) {
>> >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0printk(KERN_ERR "Error mapping t=
he grant reference "
>> >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 "into the kernel (%=
d). domid =3D %d; ref =3D %d\n",
>> >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 op.status,
>> >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 private_data->grant=
s[slot_index+i]
>> >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 .u.valid.domid,
>> >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 private_data->grant=
s[slot_index+i]
>> >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 .u.valid.ref);
>> >> + =A0 =A0 =A0 =A0 =A0if (op.status !=3D GNTST_okay) {
>> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (op.status !=3D GNTST_eagain)
>> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0printk(KERN_ERR =
"Error mapping the grant reference "
>> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 "into the kernel (%d). domid =3D %d; ref =3D %d\n",
>> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 op.status,
>> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 private_data->grants[slot_index+i]
>> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 .u.valid.domid,
>> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 private_data->grants[slot_index+i]
>> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 .u.valid.ref);
>> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0else
>> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/* Propagate ins=
tead of trying to fix it up */
>> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0exit_ret =3D -EA=
GAIN;
>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0goto undo_map_out;
>> >> =A0 =A0 =A0 =A0 =A0 =A0}
>> >>
>> >> @@ -674,14 +679,17 @@ static int gntdev_mmap (struct file *fli
>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ret =3D HYPERVISOR_grant_table=
_op(GNTTABOP_map_grant_ref,
>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0&op, 1);
>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0BUG_ON(ret);
>> >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (op.status) {
>> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (op.status !=3D GNTST_okay) {
>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0printk(KERN_ER=
R "Error mapping the grant "
>> >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 "re=
ference into user space (%d). domid "
>> >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 "=
=3D %d; ref =3D %d\n", op.status,
>> >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 pri=
vate_data->grants[slot_index+i].u
>> >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 .va=
lid.domid,
>> >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 pri=
vate_data->grants[slot_index+i].u
>> >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 .va=
lid.ref);
>> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 "reference into user space (%d). domid "
>> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 "=3D %d; ref =3D %d\n", op.status,
>> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 private_data->grants[slot_index+i].u
>> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 .valid.domid,
>> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 private_data->grants[slot_index+i].u
>> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 .valid.ref);
>> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/* GNTST_eagain =
(i.e. page paged out) sohuld never happen
>> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 * once we've ma=
pped into kernel space */
>> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0BUG_ON(op.status=
 =3D=3D GNTST_eagain);
>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0goto undo_map_=
out;
>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0}
>> >>
>> >> @@ -705,9 +713,10 @@ static int gntdev_mmap (struct file *fli
>> >> =A0 =A0 =A0 =A0 =A0 =A0}
>> >>
>> >> =A0 =A0}
>> >> + =A0exit_ret =3D 0;
>> >>
>> >> =A0 =A0up_write(&private_data->grants_sem);
>> >> - =A0return 0;
>> >> + =A0return exit_ret;
>> >>
>> >> =A0undo_map_out:
>> >> =A0 =A0/* If we have a mapping failure, the unmapping will be taken c=
are of
>> >> @@ -725,7 +734,7 @@ undo_map_out:
>> >>
>> >> =A0 =A0up_write(&private_data->grants_sem);
>> >>
>> >> - =A0return -ENOMEM;
>> >> + =A0return exit_ret;
>> >> =A0}
>> >>
>> >> =A0static pte_t gntdev_clear_pte(struct vm_area_struct *vma, unsigned=
 long
>> >> addr,
>> >> @@ -777,7 +786,7 @@ static pte_t gntdev_clear_pte(struct vm_
>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ret =3D HYPERVISOR_grant_table=
_op(
>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0GNTTABOP_unmap=
_grant_ref, &op, 1);
>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0BUG_ON(ret);
>> >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (op.status)
>> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (op.status !=3D GNTST_okay)
>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0printk("User u=
nmap grant status =3D %d\n",
>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 o=
p.status);
>> >> =A0 =A0 =A0 =A0 =A0 =A0} else {
>> >> @@ -794,7 +803,7 @@ static pte_t gntdev_clear_pte(struct vm_
>> >> =A0 =A0 =A0 =A0 =A0 =A0ret =3D HYPERVISOR_grant_table_op(GNTTABOP_unm=
ap_grant_ref,
>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0&op, 1);
>> >> =A0 =A0 =A0 =A0 =A0 =A0BUG_ON(ret);
>> >> - =A0 =A0 =A0 =A0 =A0if (op.status)
>> >> + =A0 =A0 =A0 =A0 =A0if (op.status !=3D GNTST_okay)
>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0printk("Kernel unmap grant sta=
tus =3D %d\n", op.status);
>> >>
>> >>
>> >> diff -r df9e25a0189b -r 1170bc32db41 drivers/xen/netback/interface.c
>> >> --- a/drivers/xen/netback/interface.c
>> >> +++ b/drivers/xen/netback/interface.c
>> >> @@ -381,10 +381,9 @@ static int map_frontend_pages(struct xen
>> >> =A0 =A0gnttab_set_map_op(&op, (unsigned long)comms->ring_area->addr,
>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0GNTMAP_host_map, ring_ref,=
 domid);
>> >>
>> >> - =A0if (HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, &op, 1))
>> >> - =A0 =A0 =A0 =A0 =A0BUG();
>> >> + =A0gnttab_check_GNTST_eagain_do_while(GNTTABOP_map_grant_ref, &op);
>> >>
>> >> - =A0if (op.status) {
>> >> + =A0if (op.status !=3D GNTST_okay) {
>> >> =A0 =A0 =A0 =A0 =A0 =A0DPRINTK(" Gnttab failure mapping ring_ref!\n");
>> >> =A0 =A0 =A0 =A0 =A0 =A0free_vm_area(comms->ring_area);
>> >> =A0 =A0 =A0 =A0 =A0 =A0return op.status;
>> >> diff -r df9e25a0189b -r 1170bc32db41 drivers/xen/netback/netback.c
>> >> --- a/drivers/xen/netback/netback.c
>> >> +++ b/drivers/xen/netback/netback.c
>> >> @@ -419,11 +419,13 @@ static int netbk_check_gop(int nr_copy_s
>> >>
>> >> =A0 =A0for (i =3D 0; i < nr_copy_slots; i++) {
>> >> =A0 =A0 =A0 =A0 =A0 =A0copy_op =3D npo->copy + npo->copy_cons++;
>> >> + =A0 =A0 =A0 =A0 =A0if (copy_op->status =3D=3D GNTST_eagain)
>> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0gnttab_check_GNTST_eagain_while(=
GNTTABOP_copy, copy_op);
>> >> =A0 =A0 =A0 =A0 =A0 =A0if (copy_op->status !=3D GNTST_okay) {
>> >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0DPRINTK("Bad sta=
tus %d from copy to DOM%d.\n",
>> >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
copy_op->status, domid);
>> >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0status =3D NETIF=
_RSP_ERROR;
>> >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0}
>> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0DPRINTK("Bad status %d from copy=
 to DOM%d.\n",
>> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0copy_op->status,=
 domid);
>> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0status =3D NETIF_RSP_ERROR;
>> >> + =A0 =A0 =A0 =A0 =A0}
>> >> =A0 =A0}
>> >>
>> >> =A0 =A0return status;
>> >> @@ -1020,7 +1022,11 @@ static int netbk_tx_check_mop(struct xen
>> >>
>> >> =A0 =A0/* Check status of header. */
>> >> =A0 =A0err =3D mop->status;
>> >> - =A0if (unlikely(err)) {
>> >> + =A0if (err =3D=3D GNTST_eagain) {
>> >> + =A0 =A0 =A0 =A0 =A0gnttab_check_GNTST_eagain_do_while(GNTTABOP_map_=
grant_ref, mop);
>> >> + =A0 =A0 =A0 =A0 =A0err =3D mop->status;
>> >> + =A0}
>> >> + =A0if (unlikely(err !=3D GNTST_okay)) {
>> >> =A0 =A0 =A0 =A0 =A0 =A0pending_ring_idx_t index;
>> >> =A0 =A0 =A0 =A0 =A0 =A0index =3D pending_index(netbk->pending_prod++);
>> >> =A0 =A0 =A0 =A0 =A0 =A0txp =3D &pending_tx_info[pending_idx].req;
>> >> diff -r df9e25a0189b -r 1170bc32db41 drivers/xen/scsiback/interface.c
>> >> --- a/drivers/xen/scsiback/interface.c
>> >> +++ b/drivers/xen/scsiback/interface.c
>> >> @@ -69,18 +69,18 @@ static int map_frontend_page( struct vsc
>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0GNTMAP_host_ma=
p, ring_ref,
>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0info->domid);
>> >>
>> >> - =A0err =3D HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, &op, 1=
);
>> >> - =A0BUG_ON(err);
>> >> + =A0gnttab_check_GNTST_eagain_do_while(GNTTABOP_map_grant_ref, &op);
>> >>
>> >> - =A0if (op.status) {
>> >> - =A0 =A0 =A0 =A0 =A0printk(KERN_ERR "scsiback: Grant table operation=
 failure !\n");
>> >> + =A0if (op.status !=3D GNTST_okay) {
>> >> + =A0 =A0 =A0 =A0 =A0printk(KERN_ERR "scsiback: Grant table operation=
 failure %d!\n",
>> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(int) op.status);
>> >> =A0 =A0 =A0 =A0 =A0 =A0return op.status;
>> >> =A0 =A0}
>> >>
>> >> =A0 =A0info->shmem_ref =A0 =A0=3D ring_ref;
>> >> =A0 =A0info->shmem_handle =3D op.handle;
>> >>
>> >> - =A0return (GNTST_okay);
>> >> + =A0return 0;
>> >> =A0}
>> >>
>> >> =A0static void unmap_frontend_page(struct vscsibk_info *info)
>> >> diff -r df9e25a0189b -r 1170bc32db41 drivers/xen/scsiback/scsiback.c
>> >> --- a/drivers/xen/scsiback/scsiback.c
>> >> +++ b/drivers/xen/scsiback/scsiback.c
>> >> @@ -287,7 +287,9 @@ static int scsiback_gnttab_data_map(vscs
>> >> =A0 =A0 =A0 =A0 =A0 =A0for_each_sg (pending_req->sgl, sg, nr_segments=
, i) {
>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0struct page *pg;
>> >>
>> >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (unlikely(map[i].status !=3D =
0)) {
>> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (unlikely(map[i].status =3D=
=3D GNTST_eagain))
>> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0gnttab_check_GNT=
ST_eagain_while(GNTTABOP_map_grant_ref, &map[i]);
>> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (unlikely(map[i].status !=3D =
GNTST_okay)) {
>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0printk(KERN_ER=
R "scsiback: invalid buffer -- could not remap
>> >> it\n");
>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0map[i].handle =
=3D SCSIBACK_INVALID_HANDLE;
>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0err |=3D 1;
>> >> diff -r df9e25a0189b -r 1170bc32db41 drivers/xen/tpmback/interface.c
>> >> --- a/drivers/xen/tpmback/interface.c
>> >> +++ b/drivers/xen/tpmback/interface.c
>> >> @@ -86,11 +86,10 @@ static int map_frontend_page(tpmif_t *tp
>> >> =A0 =A0gnttab_set_map_op(&op, (unsigned long)tpmif->tx_area->addr,
>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0GNTMAP_host_map, shared_pa=
ge, tpmif->domid);
>> >>
>> >> - =A0if (HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, &op, 1))
>> >> - =A0 =A0 =A0 =A0 =A0BUG();
>> >> + =A0gnttab_check_GNTST_eagain_do_while(GNTTABOP_map_grant_ref, &op);
>> >>
>> >> - =A0if (op.status) {
>> >> - =A0 =A0 =A0 =A0 =A0DPRINTK(" Grant table operation failure !\n");
>> >> + =A0if (op.status !=3D GNTST_okay) {
>> >> + =A0 =A0 =A0 =A0 =A0DPRINTK(" Grant table operation failure %d!\n", =
(int) op.status);
>> >> =A0 =A0 =A0 =A0 =A0 =A0return op.status;
>> >> =A0 =A0}
>> >>
>> >> diff -r df9e25a0189b -r 1170bc32db41 drivers/xen/tpmback/tpmback.c
>> >> --- a/drivers/xen/tpmback/tpmback.c
>> >> +++ b/drivers/xen/tpmback/tpmback.c
>> >> @@ -256,15 +256,13 @@ int _packet_write(struct packet *pak,
>> >> =A0 =A0 =A0 =A0 =A0 =A0gnttab_set_map_op(&map_op, idx_to_kaddr(tpmif,=
 i),
>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0GNTMAP_hos=
t_map, tx->ref, tpmif->domid);
>> >>
>> >> - =A0 =A0 =A0 =A0 =A0if (unlikely(HYPERVISOR_grant_table_op(GNTTABOP_=
map_grant_ref,
>> >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 &map_op, 1))) {
>> >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0BUG();
>> >> - =A0 =A0 =A0 =A0 =A0}
>> >> + =A0 =A0 =A0 =A0 =A0gnttab_check_GNTST_eagain_do_while(GNTTABOP_map_=
grant_ref, &map_op);
>> >>
>> >> =A0 =A0 =A0 =A0 =A0 =A0handle =3D map_op.handle;
>> >>
>> >> - =A0 =A0 =A0 =A0 =A0if (map_op.status) {
>> >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0DPRINTK(" Grant table operation =
failure !\n");
>> >> + =A0 =A0 =A0 =A0 =A0if (map_op.status !=3D GNTST_okay) {
>> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0DPRINTK(" Grant table operation =
failure %d!\n",
>> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0(int) map_op.status);
>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0return 0;
>> >> =A0 =A0 =A0 =A0 =A0 =A0}
>> >>
>> >> @@ -394,13 +392,11 @@ static int packet_read_shmem(struct pack
>> >> =A0 =A0 =A0 =A0 =A0 =A0gnttab_set_map_op(&map_op, idx_to_kaddr(tpmif,=
 i),
>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0GNTMAP_hos=
t_map, tx->ref, tpmif->domid);
>> >>
>> >> - =A0 =A0 =A0 =A0 =A0if (unlikely(HYPERVISOR_grant_table_op(GNTTABOP_=
map_grant_ref,
>> >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 &map_op, 1))) {
>> >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0BUG();
>> >> - =A0 =A0 =A0 =A0 =A0}
>> >> + =A0 =A0 =A0 =A0 =A0gnttab_check_GNTST_eagain_do_while(GNTTABOP_map_=
grant_ref, &map_op);
>> >>
>> >> - =A0 =A0 =A0 =A0 =A0if (map_op.status) {
>> >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0DPRINTK(" Grant table operation =
failure !\n");
>> >> + =A0 =A0 =A0 =A0 =A0if (map_op.status !=3D GNTST_okay) {
>> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0DPRINTK(" Grant table operation =
failure %d!\n",
>> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0(int) map_op.status);
>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0return -EFAULT;
>> >> =A0 =A0 =A0 =A0 =A0 =A0}
>> >>
>> >> diff -r df9e25a0189b -r 1170bc32db41 drivers/xen/usbback/interface.c
>> >> --- a/drivers/xen/usbback/interface.c
>> >> +++ b/drivers/xen/usbback/interface.c
>> >> @@ -109,11 +109,11 @@ static int map_frontend_pages(usbif_t *u
>> >> =A0 =A0gnttab_set_map_op(&op, (unsigned long)usbif->urb_ring_area->ad=
dr,
>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0GNTMAP_host_map, urb_ring_=
ref, usbif->domid);
>> >>
>> >> - =A0if (HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, &op, 1))
>> >> - =A0 =A0 =A0 =A0 =A0BUG();
>> >> + =A0gnttab_check_GNTST_eagain_do_while(GNTTABOP_map_grant_ref, &op);
>> >>
>> >> - =A0if (op.status) {
>> >> - =A0 =A0 =A0 =A0 =A0printk(KERN_ERR "grant table failure mapping urb=
_ring_ref\n");
>> >> + =A0if (op.status !=3D GNTST_okay) {
>> >> + =A0 =A0 =A0 =A0 =A0printk(KERN_ERR "grant table failure mapping urb=
_ring_ref %d\n",
>> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(int) op.status);
>> >> =A0 =A0 =A0 =A0 =A0 =A0return op.status;
>> >> =A0 =A0}
>> >>
>> >> @@ -123,17 +123,17 @@ static int map_frontend_pages(usbif_t *u
>> >> =A0 =A0gnttab_set_map_op(&op, (unsigned long)usbif->conn_ring_area->a=
ddr,
>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0GNTMAP_host_map, conn_ring=
_ref, usbif->domid);
>> >>
>> >> - =A0if (HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, &op, 1))
>> >> - =A0 =A0 =A0 =A0 =A0BUG();
>> >> + =A0gnttab_check_GNTST_eagain_do_while(GNTTABOP_map_grant_ref, &op);
>> >>
>> >> - =A0if (op.status) {
>> >> + =A0if (op.status !=3D GNTST_okay) {
>> >> =A0 =A0 =A0 =A0 =A0 =A0struct gnttab_unmap_grant_ref unop;
>> >> =A0 =A0 =A0 =A0 =A0 =A0gnttab_set_unmap_op(&unop,
>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(unsigned long=
) usbif->urb_ring_area->addr,
>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0GNTMAP_host_ma=
p, usbif->urb_shmem_handle);
>> >> =A0 =A0 =A0 =A0 =A0 =A0VOID(HYPERVISOR_grant_table_op(GNTTABOP_unmap_=
grant_ref, &unop,
>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A01));
>> >> - =A0 =A0 =A0 =A0 =A0printk(KERN_ERR "grant table failure mapping con=
n_ring_ref\n");
>> >> + =A0 =A0 =A0 =A0 =A0printk(KERN_ERR "grant table failure mapping con=
n_ring_ref %d\n",
>> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(int) op.status);
>> >> =A0 =A0 =A0 =A0 =A0 =A0return op.status;
>> >> =A0 =A0}
>> >>
>> >> diff -r df9e25a0189b -r 1170bc32db41 drivers/xen/usbback/usbback.c
>> >> --- a/drivers/xen/usbback/usbback.c
>> >> +++ b/drivers/xen/usbback/usbback.c
>> >> @@ -428,7 +428,9 @@ static int usbbk_gnttab_map(usbif_t *usb
>> >> =A0 =A0 =A0 =A0 =A0 =A0BUG_ON(ret);
>> >>
>> >> =A0 =A0 =A0 =A0 =A0 =A0for (i =3D 0; i < nr_segs; i++) {
>> >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (unlikely(map[i].status !=3D =
0)) {
>> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (unlikely(map[i].status =3D=
=3D GNTST_eagain))
>> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0gnttab_check_GNT=
ST_eagain_while(GNTTABOP_map_grant_ref, &map[i]);
>> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (unlikely(map[i].status !=3D =
GNTST_okay)) {
>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0printk(KERN_ER=
R "usbback: invalid buffer -- could not remap it\n");
>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0map[i].handle =
=3D USBBACK_INVALID_HANDLE;
>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ret |=3D 1;
>> >> diff -r df9e25a0189b -r 1170bc32db41
>> >> drivers/xen/xenbus/xenbus_backend_client.c
>> >> --- a/drivers/xen/xenbus/xenbus_backend_client.c
>> >> +++ b/drivers/xen/xenbus/xenbus_backend_client.c
>> >> @@ -48,8 +48,7 @@ struct vm_struct *xenbus_map_ring_valloc
>> >> =A0 =A0gnttab_set_map_op(&op, (unsigned long)area->addr, GNTMAP_host_=
map,
>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0gnt_ref, dev->otherend_id);
>> >>
>> >> - =A0if (HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, &op, 1))
>> >> - =A0 =A0 =A0 =A0 =A0BUG();
>> >> + =A0gnttab_check_GNTST_eagain_do_while(GNTTABOP_map_grant_ref, &op);
>> >>
>> >> =A0 =A0if (op.status !=3D GNTST_okay) {
>> >> =A0 =A0 =A0 =A0 =A0 =A0free_vm_area(area);
>> >> @@ -75,15 +74,16 @@ int xenbus_map_ring(struct xenbus_device
>> >>
>> >> =A0 =A0gnttab_set_map_op(&op, (unsigned long)vaddr, GNTMAP_host_map,
>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0gnt_ref, dev->otherend_id);
>> >> - =A0if (HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, &op, 1))
>> >> - =A0 =A0 =A0 =A0 =A0BUG();
>> >> + =A0gnttab_check_GNTST_eagain_do_while(GNTTABOP_map_grant_ref, &op);
>> >>
>> >> =A0 =A0if (op.status !=3D GNTST_okay) {
>> >> =A0 =A0 =A0 =A0 =A0 =A0xenbus_dev_fatal(dev, op.status,
>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 "mapping in s=
hared page %d from domain %d",
>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 gnt_ref, dev-=
>otherend_id);
>> >> - =A0} else
>> >> + =A0} else {
>> >> =A0 =A0 =A0 =A0 =A0 =A0*handle =3D op.handle;
>> >> + =A0 =A0 =A0 =A0 =A0return 0;
>> >> + =A0}
>> >>
>> >> =A0 =A0return op.status;
>> >> =A0}
>> >> diff -r df9e25a0189b -r 1170bc32db41 include/xen/gnttab.h
>> >> --- a/include/xen/gnttab.h
>> >> +++ b/include/xen/gnttab.h
>> >> @@ -187,4 +187,41 @@ gnttab_set_replace_op(struct gnttab_unma
>> >> =A0 =A0unmap->handle =3D handle;
>> >> =A0}
>> >>
>> >> +#define gnttab_check_GNTST_eagain_while(__HCop, __HCarg_p) =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0\
>> >> +do { =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0\
>> >> + =A0u8 __hc_delay =3D 1; =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 =A0 =A0 =A0\
>> >> + =A0int __ret; =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0\
>> >> + =A0while (unlikely((__HCarg_p)->status =3D=3D GNTST_eagain && __hc_=
delay))
>> >> { =A0\
>> >> + =A0 =A0 =A0 =A0 =A0msleep(__hc_delay++); =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 \
>> >> + =A0 =A0 =A0 =A0 =A0__ret =3D HYPERVISOR_grant_table_op(__HCop, (__H=
Carg_p), 1); =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0\
>> >> + =A0 =A0 =A0 =A0 =A0BUG_ON(__ret); =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0\
>> >> + =A0} =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 \
>> >> + =A0if (__hc_delay =3D=3D 0) { =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0\
>> >> + =A0 =A0 =A0 =A0 =A0printk(KERN_ERR "%s: %s gnt busy\n", __func__, c=
urrent->comm); =A0 =A0 =A0 =A0 =A0\
>> >> + =A0 =A0 =A0 =A0 =A0(__HCarg_p)->status =3D GNTST_bad_page; =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 \
>> >> + =A0} =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 \
>> >> + =A0if ((__HCarg_p)->status !=3D GNTST_okay) =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0\
>> >> + =A0 =A0 =A0 =A0 =A0printk(KERN_ERR "%s: %s gnt status %x\n", =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 \
>> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0__func__, current->comm, (__HCar=
g_p)->status); =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0\
>> >> +} while(0)
>> >> +
>> >> +#define gnttab_check_GNTST_eagain_do_while(__HCop, __HCarg_p) =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 \
>> >> +do { =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0\
>> >> + =A0u8 __hc_delay =3D 1; =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0\
>> >> + =A0int __ret; =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0\
>> >> + =A0do { =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0\
>> >> + =A0 =A0 =A0 =A0 =A0__ret =3D HYPERVISOR_grant_table_op(__HCop, (__H=
Carg_p), 1); =A0 =A0 =A0 =A0 =A0 =A0 =A0\
>> >> + =A0 =A0 =A0 =A0 =A0BUG_ON(__ret); =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0\
>> >> + =A0 =A0 =A0 =A0 =A0if ((__HCarg_p)->status =3D=3D GNTST_eagain) =A0=
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0\
>> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0msleep(__hc_delay++); =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 \
>> >> + =A0} while ((__HCarg_p)->status =3D=3D GNTST_eagain && __hc_delay);=
 =A0 =A0 =A0 =A0 =A0 =A0\
>> >> + =A0if (__hc_delay =3D=3D 0) { =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0\
>> >> + =A0 =A0 =A0 =A0 =A0printk(KERN_ERR "%s: %s gnt busy\n", __func__, c=
urrent->comm); =A0\
>> >> + =A0 =A0 =A0 =A0 =A0(__HCarg_p)->status =3D GNTST_bad_page; =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 \
>> >> + =A0} =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 \
>> >> + =A0if ((__HCarg_p)->status !=3D GNTST_okay) =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0\
>> >> + =A0 =A0 =A0 =A0 =A0printk(KERN_ERR "%s: %s gnt status %x\n", =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 \
>> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0__func__, current->comm, (__HCar=
g_p)->status); =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0\
>> >> +} while(0)
>> >> +
>> >> =A0#endif /* __ASM_GNTTAB_H__ */
>> >>
>> >> _______________________________________________
>> >> Xen-devel mailing list
>> >> Xen-devel@lists.xensource.com
>> >> http://lists.xensource.com/xen-devel
>> >
>>
>>
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Dec 17 03:01:31 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 17 Dec 2011 03: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.xensource.com>)
	id 1RbkWC-0003Bk-3y; Sat, 17 Dec 2011 03:01:00 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <amscanne@gridcentric.ca>) id 1RbkWA-0003Ac-9i
	for xen-devel@lists.xensource.com; Sat, 17 Dec 2011 03:00:58 +0000
X-Env-Sender: amscanne@gridcentric.ca
X-Msg-Ref: server-8.tower-21.messagelabs.com!1324090850!8536409!1
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24670 invoked from network); 17 Dec 2011 03:00:51 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Dec 2011 03:00:51 -0000
Received: by wgbds11 with SMTP id ds11so6118930wgb.24
	for <xen-devel@lists.xensource.com>;
	Fri, 16 Dec 2011 19:00:50 -0800 (PST)
Received: by 10.180.104.70 with SMTP id gc6mr15726524wib.42.1324090849216;
	Fri, 16 Dec 2011 19:00:49 -0800 (PST)
MIME-Version: 1.0
Received: by 10.223.120.68 with HTTP; Fri, 16 Dec 2011 19:00:28 -0800 (PST)
In-Reply-To: <20111202165003.GA7807@andromeda.dapyr.net>
References: <patchbomb.1322772713@xdev.gridcentric.ca>
	<1170bc32db41a7ae1e95.1322772715@xdev.gridcentric.ca>
	<20111202013430.GB636@andromeda.dapyr.net>
	<8940966a49442039be1480307f59656b.squirrel@webmail.lagarcavilla.org>
	<20111202165003.GA7807@andromeda.dapyr.net>
From: Adin Scannell <adin@gridcentric.ca>
Date: Fri, 16 Dec 2011 22:00:28 -0500
X-Google-Sender-Auth: qxy-PIaDzyjcCcoDrp3OmLN3gwI
Message-ID: <CAAJKtqpiJMY7syLMec5=wHp7L1aiY9cLzgCunw1JUCNF8NWV6Q@mail.gmail.com>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
Cc: olaf@aepfle.de, xen-devel@lists.xensource.com, andres@gridcentric.ca,
	jonathan.ludlam@eu.citrix.com,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>,
	jbeulich@suse.com, mike.mcclurg@citrix.com
Subject: Re: [Xen-devel] [PATCH 2 of 2] xenpaging: handle GNTST_eagain in
 kernel drivers
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

I had a chance to get a environment up and running with the Kernel
tip, so I've ported these patches.  As a requisite, I had to create a
patch that implements MMAP_BATCH_V2 first.  I'll be posting the set to
the mailing list very shortly for comment.

I wanted to revive this thread so there was a bit of context.

Cheers,
-Adin

On Fri, Dec 2, 2011 at 11:50 AM, Konrad Rzeszutek Wilk
<konrad@darnok.org> wrote:
> On Fri, Dec 02, 2011 at 07:27:20AM -0800, Andres Lagar-Cavilla wrote:
>> > On Thu, Dec 01, 2011 at 03:51:55PM -0500, Andres Lagar-Cavilla wrote:
>> >> =A0drivers/xen/blkback/blkback.c =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 6 +=
+-
>> >> =A0drivers/xen/blkback/interface.c =A0 =A0 =A0 =A0 =A0 =A0| =A0 9 +++-
>> >> =A0drivers/xen/core/gnttab.c =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0=
 4 +-
>> >> =A0drivers/xen/gntdev/gntdev.c =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A049
>> >> +++++++++++++++++------------
>> >> =A0drivers/xen/netback/interface.c =A0 =A0 =A0 =A0 =A0 =A0| =A0 5 +-
>> >> =A0drivers/xen/netback/netback.c =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A016 +=
+++++---
>> >> =A0drivers/xen/scsiback/interface.c =A0 =A0 =A0 =A0 =A0 | =A010 +++---
>> >> =A0drivers/xen/scsiback/scsiback.c =A0 =A0 =A0 =A0 =A0 =A0| =A0 4 +-
>> >> =A0drivers/xen/tpmback/interface.c =A0 =A0 =A0 =A0 =A0 =A0| =A0 7 +--
>> >> =A0drivers/xen/tpmback/tpmback.c =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A020 +=
+++-------
>> >> =A0drivers/xen/usbback/interface.c =A0 =A0 =A0 =A0 =A0 =A0| =A016 +++=
+----
>> >> =A0drivers/xen/usbback/usbback.c =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 4 +-
>> >> =A0drivers/xen/xenbus/xenbus_backend_client.c | =A010 +++---
>> >> =A0include/xen/gnttab.h =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |=
 =A037 ++++++++++++++++++++++
>> >> =A014 files changed, 126 insertions(+), 71 deletions(-)
>> >>
>> >>
>> >> Handle GNTST_eagain status from GNTTABOP_map_grant_ref and
>> >> GNTTABOP_copy operations properly to allow usage of xenpaging without
>> >> causing crashes or data corruption.
>> >>
>> >> Replace all relevant HYPERVISOR_grant_table_op() calls with a retry
>> >> loop. This loop is implemented as a macro to allow different
>> >> GNTTABOP_* args. It will sleep up to 33 seconds and wait for the
>> >> page to be paged in again.
>> >>
>> >> All ->status checks were updated to use the GNTST_* namespace. All
>> >> return values are converted from GNTST_* namespace to 0/-EINVAL, since
>> >> all callers did not use the actual return value.
>> >
>> > Any plans to do this for the pvops tree?
>> Slowly but surely. Working with XCP presently, so pvops is not at the top
>> of my stack. Do you want to get at a specific merge window?
>
> Its more of a review concern. Meaning that if you send for the upstream
> kernel lots of folks are going to be looking at it. So the patches
> will change - which means that the version upstream can be very
> different from the one that you have for XCP - so in the end you will
> have to deal with two different code-bases to maintain.
>
> That can get a bit difficult to manage.
>
> Granted not all of those drivers are in the upstream kernel so might not
> make any difference.
>
>>
>> Andres
>> >
>> >>
>> >> Signed-off-by: Olaf Hering <olaf@aepfle.de>
>> >> Acked-by: Patrick Colp <pjcolp@cs.ubc.ca>
>> >>
>> >> This is a port from xenlinux 2.6.18 to the 2.6.32 xcp tree
>> >> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
>> >>
>> >> diff -r df9e25a0189b -r 1170bc32db41 drivers/xen/blkback/blkback.c
>> >> --- a/drivers/xen/blkback/blkback.c
>> >> +++ b/drivers/xen/blkback/blkback.c
>> >> @@ -701,11 +701,13 @@ static void dispatch_rw_block_io(blkif_t
>> >> =A0 =A0BUG_ON(ret);
>> >>
>> >> =A0 =A0for (i =3D 0; i < nseg; i++) {
>> >> - =A0 =A0 =A0 =A0 =A0if (unlikely(map[i].status !=3D 0)) {
>> >> + =A0 =A0 =A0 =A0 =A0if (unlikely(map[i].status =3D=3D GNTST_eagain))
>> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0gnttab_check_GNTST_eagain_do_whi=
le(GNTTABOP_map_grant_ref, &map[i]);
>> >> + =A0 =A0 =A0 =A0 =A0if (unlikely(map[i].status !=3D GNTST_okay)) {
>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0DPRINTK("grant map of dom %u g=
ref %u failed: status %d\n",
>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0blkif->domid, =
req->seg[i].gref, map[i].status);
>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0map[i].handle =3D BLKBACK_INVA=
LID_HANDLE;
>> >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ret |=3D 1;
>> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ret =3D 1;
>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0continue;
>> >> =A0 =A0 =A0 =A0 =A0 =A0}
>> >>
>> >> diff -r df9e25a0189b -r 1170bc32db41 drivers/xen/blkback/interface.c
>> >> --- a/drivers/xen/blkback/interface.c
>> >> +++ b/drivers/xen/blkback/interface.c
>> >> @@ -95,7 +95,7 @@ static int map_frontend_pages(blkif_t *b
>> >> =A0 =A0struct vm_struct *area =3D blkif->blk_ring_area;
>> >> =A0 =A0struct gnttab_map_grant_ref op[BLKIF_MAX_RING_PAGES];
>> >> =A0 =A0unsigned int i;
>> >> - =A0int status =3D 0;
>> >> + =A0int status =3D GNTST_okay;
>> >>
>> >> =A0 =A0for (i =3D 0; i < nr_shared_pages; i++) {
>> >> =A0 =A0 =A0 =A0 =A0 =A0unsigned long addr =3D (unsigned long)area->ad=
dr +
>> >> @@ -110,7 +110,10 @@ static int map_frontend_pages(blkif_t *b
>> >> =A0 =A0 =A0 =A0 =A0 =A0BUG();
>> >>
>> >> =A0 =A0for (i =3D 0; i < nr_shared_pages; i++) {
>> >> - =A0 =A0 =A0 =A0 =A0if ((status =3D op[i].status) !=3D 0) {
>> >> + =A0 =A0 =A0 =A0 =A0if (op[i].status =3D=3D GNTST_eagain)
>> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0gnttab_check_GNTST_eagain_do_whi=
le(GNTTABOP_map_grant_ref, &op[i]);
>> >> + =A0 =A0 =A0 =A0 =A0if (op[i].status !=3D GNTST_okay) {
>> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0status =3D op[i].status;
>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0blkif->shmem_handle[i] =3D INV=
ALID_GRANT_HANDLE;
>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0continue;
>> >> =A0 =A0 =A0 =A0 =A0 =A0}
>> >> @@ -120,7 +123,7 @@ static int map_frontend_pages(blkif_t *b
>> >>
>> >> =A0 =A0blkif->nr_shared_pages =3D nr_shared_pages;
>> >>
>> >> - =A0if (status !=3D 0) {
>> >> + =A0if (status !=3D GNTST_okay) {
>> >> =A0 =A0 =A0 =A0 =A0 =A0DPRINTK(" Grant table operation failure !\n");
>> >> =A0 =A0 =A0 =A0 =A0 =A0unmap_frontend_pages(blkif);
>> >> =A0 =A0}
>> >> diff -r df9e25a0189b -r 1170bc32db41 drivers/xen/core/gnttab.c
>> >> --- a/drivers/xen/core/gnttab.c
>> >> +++ b/drivers/xen/core/gnttab.c
>> >> @@ -773,7 +773,7 @@ static int gnttab_map(unsigned int start
>> >> =A0 =A0 =A0 =A0 =A0 =A0return -ENOSYS;
>> >> =A0 =A0}
>> >>
>> >> - =A0BUG_ON(rc || setup.status);
>> >> + =A0BUG_ON(rc || (setup.status !=3D GNTST_okay));
>> >>
>> >> =A0 =A0if (shared.raw =3D=3D NULL)
>> >> =A0 =A0 =A0 =A0 =A0 =A0shared.raw =3D arch_gnttab_alloc_shared(gframe=
s);
>> >> @@ -901,7 +901,7 @@ int gnttab_copy_grant_page(grant_ref_t r
>> >> =A0 =A0err =3D HYPERVISOR_grant_table_op(GNTTABOP_unmap_and_replace,
>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0&unmap, 1);
>> >> =A0 =A0BUG_ON(err);
>> >> - =A0BUG_ON(unmap.status);
>> >> + =A0BUG_ON(unmap.status !=3D GNTST_okay);
>> >>
>> >> =A0 =A0write_sequnlock_irq(&gnttab_dma_lock);
>> >>
>> >> diff -r df9e25a0189b -r 1170bc32db41 drivers/xen/gntdev/gntdev.c
>> >> --- a/drivers/xen/gntdev/gntdev.c
>> >> +++ b/drivers/xen/gntdev/gntdev.c
>> >> @@ -503,7 +503,7 @@ static int gntdev_mmap (struct file *fli
>> >> =A0 =A0uint64_t ptep;
>> >> =A0 =A0int ret;
>> >> =A0 =A0int flags;
>> >> - =A0int i;
>> >> + =A0int i, exit_ret;
>> >> =A0 =A0struct page *page;
>> >> =A0 =A0gntdev_file_private_data_t *private_data =3D flip->private_dat=
a;
>> >>
>> >> @@ -578,6 +578,7 @@ static int gntdev_mmap (struct file *fli
>> >> =A0 =A0vma->vm_mm->context.has_foreign_mappings =3D 1;
>> >> =A0#endif
>> >>
>> >> + =A0exit_ret =3D -ENOMEM;
>> >> =A0 =A0for (i =3D 0; i < size; ++i) {
>> >>
>> >> =A0 =A0 =A0 =A0 =A0 =A0flags =3D GNTMAP_host_map;
>> >> @@ -598,14 +599,18 @@ static int gntdev_mmap (struct file *fli
>> >> =A0 =A0 =A0 =A0 =A0 =A0ret =3D HYPERVISOR_grant_table_op(GNTTABOP_map=
_grant_ref,
>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0&op, 1);
>> >> =A0 =A0 =A0 =A0 =A0 =A0BUG_ON(ret);
>> >> - =A0 =A0 =A0 =A0 =A0if (op.status) {
>> >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0printk(KERN_ERR "Error mapping t=
he grant reference "
>> >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 "into the kernel (%=
d). domid =3D %d; ref =3D %d\n",
>> >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 op.status,
>> >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 private_data->grant=
s[slot_index+i]
>> >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 .u.valid.domid,
>> >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 private_data->grant=
s[slot_index+i]
>> >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 .u.valid.ref);
>> >> + =A0 =A0 =A0 =A0 =A0if (op.status !=3D GNTST_okay) {
>> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (op.status !=3D GNTST_eagain)
>> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0printk(KERN_ERR =
"Error mapping the grant reference "
>> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 "into the kernel (%d). domid =3D %d; ref =3D %d\n",
>> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 op.status,
>> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 private_data->grants[slot_index+i]
>> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 .u.valid.domid,
>> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 private_data->grants[slot_index+i]
>> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 .u.valid.ref);
>> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0else
>> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/* Propagate ins=
tead of trying to fix it up */
>> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0exit_ret =3D -EA=
GAIN;
>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0goto undo_map_out;
>> >> =A0 =A0 =A0 =A0 =A0 =A0}
>> >>
>> >> @@ -674,14 +679,17 @@ static int gntdev_mmap (struct file *fli
>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ret =3D HYPERVISOR_grant_table=
_op(GNTTABOP_map_grant_ref,
>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0&op, 1);
>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0BUG_ON(ret);
>> >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (op.status) {
>> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (op.status !=3D GNTST_okay) {
>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0printk(KERN_ER=
R "Error mapping the grant "
>> >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 "re=
ference into user space (%d). domid "
>> >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 "=
=3D %d; ref =3D %d\n", op.status,
>> >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 pri=
vate_data->grants[slot_index+i].u
>> >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 .va=
lid.domid,
>> >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 pri=
vate_data->grants[slot_index+i].u
>> >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 .va=
lid.ref);
>> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 "reference into user space (%d). domid "
>> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 "=3D %d; ref =3D %d\n", op.status,
>> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 private_data->grants[slot_index+i].u
>> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 .valid.domid,
>> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 private_data->grants[slot_index+i].u
>> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 .valid.ref);
>> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/* GNTST_eagain =
(i.e. page paged out) sohuld never happen
>> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 * once we've ma=
pped into kernel space */
>> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0BUG_ON(op.status=
 =3D=3D GNTST_eagain);
>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0goto undo_map_=
out;
>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0}
>> >>
>> >> @@ -705,9 +713,10 @@ static int gntdev_mmap (struct file *fli
>> >> =A0 =A0 =A0 =A0 =A0 =A0}
>> >>
>> >> =A0 =A0}
>> >> + =A0exit_ret =3D 0;
>> >>
>> >> =A0 =A0up_write(&private_data->grants_sem);
>> >> - =A0return 0;
>> >> + =A0return exit_ret;
>> >>
>> >> =A0undo_map_out:
>> >> =A0 =A0/* If we have a mapping failure, the unmapping will be taken c=
are of
>> >> @@ -725,7 +734,7 @@ undo_map_out:
>> >>
>> >> =A0 =A0up_write(&private_data->grants_sem);
>> >>
>> >> - =A0return -ENOMEM;
>> >> + =A0return exit_ret;
>> >> =A0}
>> >>
>> >> =A0static pte_t gntdev_clear_pte(struct vm_area_struct *vma, unsigned=
 long
>> >> addr,
>> >> @@ -777,7 +786,7 @@ static pte_t gntdev_clear_pte(struct vm_
>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ret =3D HYPERVISOR_grant_table=
_op(
>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0GNTTABOP_unmap=
_grant_ref, &op, 1);
>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0BUG_ON(ret);
>> >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (op.status)
>> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (op.status !=3D GNTST_okay)
>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0printk("User u=
nmap grant status =3D %d\n",
>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 o=
p.status);
>> >> =A0 =A0 =A0 =A0 =A0 =A0} else {
>> >> @@ -794,7 +803,7 @@ static pte_t gntdev_clear_pte(struct vm_
>> >> =A0 =A0 =A0 =A0 =A0 =A0ret =3D HYPERVISOR_grant_table_op(GNTTABOP_unm=
ap_grant_ref,
>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0&op, 1);
>> >> =A0 =A0 =A0 =A0 =A0 =A0BUG_ON(ret);
>> >> - =A0 =A0 =A0 =A0 =A0if (op.status)
>> >> + =A0 =A0 =A0 =A0 =A0if (op.status !=3D GNTST_okay)
>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0printk("Kernel unmap grant sta=
tus =3D %d\n", op.status);
>> >>
>> >>
>> >> diff -r df9e25a0189b -r 1170bc32db41 drivers/xen/netback/interface.c
>> >> --- a/drivers/xen/netback/interface.c
>> >> +++ b/drivers/xen/netback/interface.c
>> >> @@ -381,10 +381,9 @@ static int map_frontend_pages(struct xen
>> >> =A0 =A0gnttab_set_map_op(&op, (unsigned long)comms->ring_area->addr,
>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0GNTMAP_host_map, ring_ref,=
 domid);
>> >>
>> >> - =A0if (HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, &op, 1))
>> >> - =A0 =A0 =A0 =A0 =A0BUG();
>> >> + =A0gnttab_check_GNTST_eagain_do_while(GNTTABOP_map_grant_ref, &op);
>> >>
>> >> - =A0if (op.status) {
>> >> + =A0if (op.status !=3D GNTST_okay) {
>> >> =A0 =A0 =A0 =A0 =A0 =A0DPRINTK(" Gnttab failure mapping ring_ref!\n");
>> >> =A0 =A0 =A0 =A0 =A0 =A0free_vm_area(comms->ring_area);
>> >> =A0 =A0 =A0 =A0 =A0 =A0return op.status;
>> >> diff -r df9e25a0189b -r 1170bc32db41 drivers/xen/netback/netback.c
>> >> --- a/drivers/xen/netback/netback.c
>> >> +++ b/drivers/xen/netback/netback.c
>> >> @@ -419,11 +419,13 @@ static int netbk_check_gop(int nr_copy_s
>> >>
>> >> =A0 =A0for (i =3D 0; i < nr_copy_slots; i++) {
>> >> =A0 =A0 =A0 =A0 =A0 =A0copy_op =3D npo->copy + npo->copy_cons++;
>> >> + =A0 =A0 =A0 =A0 =A0if (copy_op->status =3D=3D GNTST_eagain)
>> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0gnttab_check_GNTST_eagain_while(=
GNTTABOP_copy, copy_op);
>> >> =A0 =A0 =A0 =A0 =A0 =A0if (copy_op->status !=3D GNTST_okay) {
>> >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0DPRINTK("Bad sta=
tus %d from copy to DOM%d.\n",
>> >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
copy_op->status, domid);
>> >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0status =3D NETIF=
_RSP_ERROR;
>> >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0}
>> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0DPRINTK("Bad status %d from copy=
 to DOM%d.\n",
>> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0copy_op->status,=
 domid);
>> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0status =3D NETIF_RSP_ERROR;
>> >> + =A0 =A0 =A0 =A0 =A0}
>> >> =A0 =A0}
>> >>
>> >> =A0 =A0return status;
>> >> @@ -1020,7 +1022,11 @@ static int netbk_tx_check_mop(struct xen
>> >>
>> >> =A0 =A0/* Check status of header. */
>> >> =A0 =A0err =3D mop->status;
>> >> - =A0if (unlikely(err)) {
>> >> + =A0if (err =3D=3D GNTST_eagain) {
>> >> + =A0 =A0 =A0 =A0 =A0gnttab_check_GNTST_eagain_do_while(GNTTABOP_map_=
grant_ref, mop);
>> >> + =A0 =A0 =A0 =A0 =A0err =3D mop->status;
>> >> + =A0}
>> >> + =A0if (unlikely(err !=3D GNTST_okay)) {
>> >> =A0 =A0 =A0 =A0 =A0 =A0pending_ring_idx_t index;
>> >> =A0 =A0 =A0 =A0 =A0 =A0index =3D pending_index(netbk->pending_prod++);
>> >> =A0 =A0 =A0 =A0 =A0 =A0txp =3D &pending_tx_info[pending_idx].req;
>> >> diff -r df9e25a0189b -r 1170bc32db41 drivers/xen/scsiback/interface.c
>> >> --- a/drivers/xen/scsiback/interface.c
>> >> +++ b/drivers/xen/scsiback/interface.c
>> >> @@ -69,18 +69,18 @@ static int map_frontend_page( struct vsc
>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0GNTMAP_host_ma=
p, ring_ref,
>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0info->domid);
>> >>
>> >> - =A0err =3D HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, &op, 1=
);
>> >> - =A0BUG_ON(err);
>> >> + =A0gnttab_check_GNTST_eagain_do_while(GNTTABOP_map_grant_ref, &op);
>> >>
>> >> - =A0if (op.status) {
>> >> - =A0 =A0 =A0 =A0 =A0printk(KERN_ERR "scsiback: Grant table operation=
 failure !\n");
>> >> + =A0if (op.status !=3D GNTST_okay) {
>> >> + =A0 =A0 =A0 =A0 =A0printk(KERN_ERR "scsiback: Grant table operation=
 failure %d!\n",
>> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(int) op.status);
>> >> =A0 =A0 =A0 =A0 =A0 =A0return op.status;
>> >> =A0 =A0}
>> >>
>> >> =A0 =A0info->shmem_ref =A0 =A0=3D ring_ref;
>> >> =A0 =A0info->shmem_handle =3D op.handle;
>> >>
>> >> - =A0return (GNTST_okay);
>> >> + =A0return 0;
>> >> =A0}
>> >>
>> >> =A0static void unmap_frontend_page(struct vscsibk_info *info)
>> >> diff -r df9e25a0189b -r 1170bc32db41 drivers/xen/scsiback/scsiback.c
>> >> --- a/drivers/xen/scsiback/scsiback.c
>> >> +++ b/drivers/xen/scsiback/scsiback.c
>> >> @@ -287,7 +287,9 @@ static int scsiback_gnttab_data_map(vscs
>> >> =A0 =A0 =A0 =A0 =A0 =A0for_each_sg (pending_req->sgl, sg, nr_segments=
, i) {
>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0struct page *pg;
>> >>
>> >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (unlikely(map[i].status !=3D =
0)) {
>> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (unlikely(map[i].status =3D=
=3D GNTST_eagain))
>> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0gnttab_check_GNT=
ST_eagain_while(GNTTABOP_map_grant_ref, &map[i]);
>> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (unlikely(map[i].status !=3D =
GNTST_okay)) {
>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0printk(KERN_ER=
R "scsiback: invalid buffer -- could not remap
>> >> it\n");
>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0map[i].handle =
=3D SCSIBACK_INVALID_HANDLE;
>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0err |=3D 1;
>> >> diff -r df9e25a0189b -r 1170bc32db41 drivers/xen/tpmback/interface.c
>> >> --- a/drivers/xen/tpmback/interface.c
>> >> +++ b/drivers/xen/tpmback/interface.c
>> >> @@ -86,11 +86,10 @@ static int map_frontend_page(tpmif_t *tp
>> >> =A0 =A0gnttab_set_map_op(&op, (unsigned long)tpmif->tx_area->addr,
>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0GNTMAP_host_map, shared_pa=
ge, tpmif->domid);
>> >>
>> >> - =A0if (HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, &op, 1))
>> >> - =A0 =A0 =A0 =A0 =A0BUG();
>> >> + =A0gnttab_check_GNTST_eagain_do_while(GNTTABOP_map_grant_ref, &op);
>> >>
>> >> - =A0if (op.status) {
>> >> - =A0 =A0 =A0 =A0 =A0DPRINTK(" Grant table operation failure !\n");
>> >> + =A0if (op.status !=3D GNTST_okay) {
>> >> + =A0 =A0 =A0 =A0 =A0DPRINTK(" Grant table operation failure %d!\n", =
(int) op.status);
>> >> =A0 =A0 =A0 =A0 =A0 =A0return op.status;
>> >> =A0 =A0}
>> >>
>> >> diff -r df9e25a0189b -r 1170bc32db41 drivers/xen/tpmback/tpmback.c
>> >> --- a/drivers/xen/tpmback/tpmback.c
>> >> +++ b/drivers/xen/tpmback/tpmback.c
>> >> @@ -256,15 +256,13 @@ int _packet_write(struct packet *pak,
>> >> =A0 =A0 =A0 =A0 =A0 =A0gnttab_set_map_op(&map_op, idx_to_kaddr(tpmif,=
 i),
>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0GNTMAP_hos=
t_map, tx->ref, tpmif->domid);
>> >>
>> >> - =A0 =A0 =A0 =A0 =A0if (unlikely(HYPERVISOR_grant_table_op(GNTTABOP_=
map_grant_ref,
>> >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 &map_op, 1))) {
>> >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0BUG();
>> >> - =A0 =A0 =A0 =A0 =A0}
>> >> + =A0 =A0 =A0 =A0 =A0gnttab_check_GNTST_eagain_do_while(GNTTABOP_map_=
grant_ref, &map_op);
>> >>
>> >> =A0 =A0 =A0 =A0 =A0 =A0handle =3D map_op.handle;
>> >>
>> >> - =A0 =A0 =A0 =A0 =A0if (map_op.status) {
>> >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0DPRINTK(" Grant table operation =
failure !\n");
>> >> + =A0 =A0 =A0 =A0 =A0if (map_op.status !=3D GNTST_okay) {
>> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0DPRINTK(" Grant table operation =
failure %d!\n",
>> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0(int) map_op.status);
>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0return 0;
>> >> =A0 =A0 =A0 =A0 =A0 =A0}
>> >>
>> >> @@ -394,13 +392,11 @@ static int packet_read_shmem(struct pack
>> >> =A0 =A0 =A0 =A0 =A0 =A0gnttab_set_map_op(&map_op, idx_to_kaddr(tpmif,=
 i),
>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0GNTMAP_hos=
t_map, tx->ref, tpmif->domid);
>> >>
>> >> - =A0 =A0 =A0 =A0 =A0if (unlikely(HYPERVISOR_grant_table_op(GNTTABOP_=
map_grant_ref,
>> >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 &map_op, 1))) {
>> >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0BUG();
>> >> - =A0 =A0 =A0 =A0 =A0}
>> >> + =A0 =A0 =A0 =A0 =A0gnttab_check_GNTST_eagain_do_while(GNTTABOP_map_=
grant_ref, &map_op);
>> >>
>> >> - =A0 =A0 =A0 =A0 =A0if (map_op.status) {
>> >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0DPRINTK(" Grant table operation =
failure !\n");
>> >> + =A0 =A0 =A0 =A0 =A0if (map_op.status !=3D GNTST_okay) {
>> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0DPRINTK(" Grant table operation =
failure %d!\n",
>> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0(int) map_op.status);
>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0return -EFAULT;
>> >> =A0 =A0 =A0 =A0 =A0 =A0}
>> >>
>> >> diff -r df9e25a0189b -r 1170bc32db41 drivers/xen/usbback/interface.c
>> >> --- a/drivers/xen/usbback/interface.c
>> >> +++ b/drivers/xen/usbback/interface.c
>> >> @@ -109,11 +109,11 @@ static int map_frontend_pages(usbif_t *u
>> >> =A0 =A0gnttab_set_map_op(&op, (unsigned long)usbif->urb_ring_area->ad=
dr,
>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0GNTMAP_host_map, urb_ring_=
ref, usbif->domid);
>> >>
>> >> - =A0if (HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, &op, 1))
>> >> - =A0 =A0 =A0 =A0 =A0BUG();
>> >> + =A0gnttab_check_GNTST_eagain_do_while(GNTTABOP_map_grant_ref, &op);
>> >>
>> >> - =A0if (op.status) {
>> >> - =A0 =A0 =A0 =A0 =A0printk(KERN_ERR "grant table failure mapping urb=
_ring_ref\n");
>> >> + =A0if (op.status !=3D GNTST_okay) {
>> >> + =A0 =A0 =A0 =A0 =A0printk(KERN_ERR "grant table failure mapping urb=
_ring_ref %d\n",
>> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(int) op.status);
>> >> =A0 =A0 =A0 =A0 =A0 =A0return op.status;
>> >> =A0 =A0}
>> >>
>> >> @@ -123,17 +123,17 @@ static int map_frontend_pages(usbif_t *u
>> >> =A0 =A0gnttab_set_map_op(&op, (unsigned long)usbif->conn_ring_area->a=
ddr,
>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0GNTMAP_host_map, conn_ring=
_ref, usbif->domid);
>> >>
>> >> - =A0if (HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, &op, 1))
>> >> - =A0 =A0 =A0 =A0 =A0BUG();
>> >> + =A0gnttab_check_GNTST_eagain_do_while(GNTTABOP_map_grant_ref, &op);
>> >>
>> >> - =A0if (op.status) {
>> >> + =A0if (op.status !=3D GNTST_okay) {
>> >> =A0 =A0 =A0 =A0 =A0 =A0struct gnttab_unmap_grant_ref unop;
>> >> =A0 =A0 =A0 =A0 =A0 =A0gnttab_set_unmap_op(&unop,
>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(unsigned long=
) usbif->urb_ring_area->addr,
>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0GNTMAP_host_ma=
p, usbif->urb_shmem_handle);
>> >> =A0 =A0 =A0 =A0 =A0 =A0VOID(HYPERVISOR_grant_table_op(GNTTABOP_unmap_=
grant_ref, &unop,
>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A01));
>> >> - =A0 =A0 =A0 =A0 =A0printk(KERN_ERR "grant table failure mapping con=
n_ring_ref\n");
>> >> + =A0 =A0 =A0 =A0 =A0printk(KERN_ERR "grant table failure mapping con=
n_ring_ref %d\n",
>> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(int) op.status);
>> >> =A0 =A0 =A0 =A0 =A0 =A0return op.status;
>> >> =A0 =A0}
>> >>
>> >> diff -r df9e25a0189b -r 1170bc32db41 drivers/xen/usbback/usbback.c
>> >> --- a/drivers/xen/usbback/usbback.c
>> >> +++ b/drivers/xen/usbback/usbback.c
>> >> @@ -428,7 +428,9 @@ static int usbbk_gnttab_map(usbif_t *usb
>> >> =A0 =A0 =A0 =A0 =A0 =A0BUG_ON(ret);
>> >>
>> >> =A0 =A0 =A0 =A0 =A0 =A0for (i =3D 0; i < nr_segs; i++) {
>> >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (unlikely(map[i].status !=3D =
0)) {
>> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (unlikely(map[i].status =3D=
=3D GNTST_eagain))
>> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0gnttab_check_GNT=
ST_eagain_while(GNTTABOP_map_grant_ref, &map[i]);
>> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (unlikely(map[i].status !=3D =
GNTST_okay)) {
>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0printk(KERN_ER=
R "usbback: invalid buffer -- could not remap it\n");
>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0map[i].handle =
=3D USBBACK_INVALID_HANDLE;
>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ret |=3D 1;
>> >> diff -r df9e25a0189b -r 1170bc32db41
>> >> drivers/xen/xenbus/xenbus_backend_client.c
>> >> --- a/drivers/xen/xenbus/xenbus_backend_client.c
>> >> +++ b/drivers/xen/xenbus/xenbus_backend_client.c
>> >> @@ -48,8 +48,7 @@ struct vm_struct *xenbus_map_ring_valloc
>> >> =A0 =A0gnttab_set_map_op(&op, (unsigned long)area->addr, GNTMAP_host_=
map,
>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0gnt_ref, dev->otherend_id);
>> >>
>> >> - =A0if (HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, &op, 1))
>> >> - =A0 =A0 =A0 =A0 =A0BUG();
>> >> + =A0gnttab_check_GNTST_eagain_do_while(GNTTABOP_map_grant_ref, &op);
>> >>
>> >> =A0 =A0if (op.status !=3D GNTST_okay) {
>> >> =A0 =A0 =A0 =A0 =A0 =A0free_vm_area(area);
>> >> @@ -75,15 +74,16 @@ int xenbus_map_ring(struct xenbus_device
>> >>
>> >> =A0 =A0gnttab_set_map_op(&op, (unsigned long)vaddr, GNTMAP_host_map,
>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0gnt_ref, dev->otherend_id);
>> >> - =A0if (HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, &op, 1))
>> >> - =A0 =A0 =A0 =A0 =A0BUG();
>> >> + =A0gnttab_check_GNTST_eagain_do_while(GNTTABOP_map_grant_ref, &op);
>> >>
>> >> =A0 =A0if (op.status !=3D GNTST_okay) {
>> >> =A0 =A0 =A0 =A0 =A0 =A0xenbus_dev_fatal(dev, op.status,
>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 "mapping in s=
hared page %d from domain %d",
>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 gnt_ref, dev-=
>otherend_id);
>> >> - =A0} else
>> >> + =A0} else {
>> >> =A0 =A0 =A0 =A0 =A0 =A0*handle =3D op.handle;
>> >> + =A0 =A0 =A0 =A0 =A0return 0;
>> >> + =A0}
>> >>
>> >> =A0 =A0return op.status;
>> >> =A0}
>> >> diff -r df9e25a0189b -r 1170bc32db41 include/xen/gnttab.h
>> >> --- a/include/xen/gnttab.h
>> >> +++ b/include/xen/gnttab.h
>> >> @@ -187,4 +187,41 @@ gnttab_set_replace_op(struct gnttab_unma
>> >> =A0 =A0unmap->handle =3D handle;
>> >> =A0}
>> >>
>> >> +#define gnttab_check_GNTST_eagain_while(__HCop, __HCarg_p) =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0\
>> >> +do { =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0\
>> >> + =A0u8 __hc_delay =3D 1; =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 =A0 =A0 =A0\
>> >> + =A0int __ret; =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0\
>> >> + =A0while (unlikely((__HCarg_p)->status =3D=3D GNTST_eagain && __hc_=
delay))
>> >> { =A0\
>> >> + =A0 =A0 =A0 =A0 =A0msleep(__hc_delay++); =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 \
>> >> + =A0 =A0 =A0 =A0 =A0__ret =3D HYPERVISOR_grant_table_op(__HCop, (__H=
Carg_p), 1); =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0\
>> >> + =A0 =A0 =A0 =A0 =A0BUG_ON(__ret); =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0\
>> >> + =A0} =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 \
>> >> + =A0if (__hc_delay =3D=3D 0) { =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0\
>> >> + =A0 =A0 =A0 =A0 =A0printk(KERN_ERR "%s: %s gnt busy\n", __func__, c=
urrent->comm); =A0 =A0 =A0 =A0 =A0\
>> >> + =A0 =A0 =A0 =A0 =A0(__HCarg_p)->status =3D GNTST_bad_page; =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 \
>> >> + =A0} =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 \
>> >> + =A0if ((__HCarg_p)->status !=3D GNTST_okay) =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0\
>> >> + =A0 =A0 =A0 =A0 =A0printk(KERN_ERR "%s: %s gnt status %x\n", =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 \
>> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0__func__, current->comm, (__HCar=
g_p)->status); =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0\
>> >> +} while(0)
>> >> +
>> >> +#define gnttab_check_GNTST_eagain_do_while(__HCop, __HCarg_p) =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 \
>> >> +do { =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0\
>> >> + =A0u8 __hc_delay =3D 1; =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0\
>> >> + =A0int __ret; =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0\
>> >> + =A0do { =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0\
>> >> + =A0 =A0 =A0 =A0 =A0__ret =3D HYPERVISOR_grant_table_op(__HCop, (__H=
Carg_p), 1); =A0 =A0 =A0 =A0 =A0 =A0 =A0\
>> >> + =A0 =A0 =A0 =A0 =A0BUG_ON(__ret); =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0\
>> >> + =A0 =A0 =A0 =A0 =A0if ((__HCarg_p)->status =3D=3D GNTST_eagain) =A0=
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0\
>> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0msleep(__hc_delay++); =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 \
>> >> + =A0} while ((__HCarg_p)->status =3D=3D GNTST_eagain && __hc_delay);=
 =A0 =A0 =A0 =A0 =A0 =A0\
>> >> + =A0if (__hc_delay =3D=3D 0) { =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0\
>> >> + =A0 =A0 =A0 =A0 =A0printk(KERN_ERR "%s: %s gnt busy\n", __func__, c=
urrent->comm); =A0\
>> >> + =A0 =A0 =A0 =A0 =A0(__HCarg_p)->status =3D GNTST_bad_page; =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 \
>> >> + =A0} =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 \
>> >> + =A0if ((__HCarg_p)->status !=3D GNTST_okay) =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0\
>> >> + =A0 =A0 =A0 =A0 =A0printk(KERN_ERR "%s: %s gnt status %x\n", =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 \
>> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0__func__, current->comm, (__HCar=
g_p)->status); =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0\
>> >> +} while(0)
>> >> +
>> >> =A0#endif /* __ASM_GNTTAB_H__ */
>> >>
>> >> _______________________________________________
>> >> Xen-devel mailing list
>> >> Xen-devel@lists.xensource.com
>> >> http://lists.xensource.com/xen-devel
>> >
>>
>>
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Dec 17 03:24:53 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 17 Dec 2011 03: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.xensource.com>)
	id 1Rbksi-0003TR-PU; Sat, 17 Dec 2011 03:24:16 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <hui.lv@intel.com>) id 1Rbksh-0003TJ-8E
	for xen-devel@lists.xensource.com; Sat, 17 Dec 2011 03:24:15 +0000
X-Env-Sender: hui.lv@intel.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1324092247!8456880!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMjg5MTY4\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30658 invoked from network); 17 Dec 2011 03:24:08 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-12.tower-21.messagelabs.com with SMTP;
	17 Dec 2011 03:24:08 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga101.jf.intel.com with ESMTP; 16 Dec 2011 19:24:06 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.67,352,1309762800"; d="scan'208,217";a="87529338"
Received: from pgsmsx601.gar.corp.intel.com ([10.221.43.69])
	by orsmga001.jf.intel.com with ESMTP; 16 Dec 2011 19:24:05 -0800
Received: from pgsmsx151.gar.corp.intel.com (172.30.236.41) by
	pgsmsx601.gar.corp.intel.com (10.221.43.69) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Sat, 17 Dec 2011 11:24:04 +0800
Received: from shsmsx602.ccr.corp.intel.com (10.239.4.104) by
	PGSMSX151.gar.corp.intel.com (172.30.236.41) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Sat, 17 Dec 2011 11:24:03 +0800
Received: from shsmsx502.ccr.corp.intel.com ([10.239.4.96]) by
	SHSMSX602.ccr.corp.intel.com ([10.239.4.104]) with mapi;
	Sat, 17 Dec 2011 11:24:03 +0800
From: "Lv, Hui" <hui.lv@intel.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"keir@xen.org" <keir@xen.org>, George Dunlap <George.Dunlap@eu.citrix.com>
Date: Sat, 17 Dec 2011 11:24:02 +0800
Thread-Topic: [PATCH v2] xen/credit scheduler; Use delay to control
	scheduling frequency
Thread-Index: Acy8a1J98NIQa/LRTpOgi509iCZVqg==
Message-ID: <C10D3FB0CD45994C8A51FEC1227CE22F37CC284376@shsmsx502.ccr.corp.intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "Duan, Jiangang" <jiangang.duan@intel.com>, "Yu,
	Zhidong" <zhidong.yu@intel.com>, "Dong,
	Eddie" <eddie.dong@intel.com>, "Tian,
	Kevin" <kevin.tian@intel.com>, "Lv, Hui" <hui.lv@intel.com>
Subject: [Xen-devel] [PATCH v2] xen/credit scheduler;
 Use delay to control scheduling frequency
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============2275392909118189727=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============2275392909118189727==
Content-Language: en-US
Content-Type: multipart/alternative;
	boundary="_000_C10D3FB0CD45994C8A51FEC1227CE22F37CC284376shsmsx502ccrc_"

--_000_C10D3FB0CD45994C8A51FEC1227CE22F37CC284376shsmsx502ccrc_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

The delay method for credit scheduler can do as well as SRC patch (previous=
 one) to gain significant performance boost without obvious drawbacks.

1. Basically, the "delay method" can achieve nearly the same benefits as my=
 previous SRC patch, 11% overall performance boost for SPECvirt than origin=
al credit scheduler.
2. We have tried 1ms delay and 10ms delay, there is no big difference betwe=
en these two configurations. (1ms is enough to achieve a good performance)
3. We have compared different load level response time/latency (low, high, =
peak), "delay method" didn't bring very much response time increase.
4. 1ms delay can reduce 30% context switch at peak performance, where produ=
ces the benefits. ("int sched_ratelimit_us =3D 1000" is the recommended set=
ting)


Signed-off-by: Hui Lv <hui.lv@intel.com<mailto:hui.lv@intel.com>>
Signed-off-by: George Dunlap <George.Dunlap@eu.citrix.com<mailto:George.Dun=
lap@eu.citrix.com>>

diff -r 1c58bb664d8d xen/common/sched_credit.c
--- a/xen/common/sched_credit.c Thu Dec 08 17:15:16 2011 +0000
+++ b/xen/common/sched_credit.c Fri Dec 16 15:08:09 2011 -0500
@@ -110,6 +110,9 @@ boolean_param("sched_credit_default_yiel
 static int __read_mostly sched_credit_tslice_ms =3D CSCHED_DEFAULT_TSLICE_=
MS;
 integer_param("sched_credit_tslice_ms", sched_credit_tslice_ms);

+/* Scheduler generic parameters
+*/
+extern int sched_ratelimit_us;
 /*
  * Physical CPU
  */
@@ -1297,10 +1300,15 @@ csched_schedule(
     struct csched_private *prv =3D CSCHED_PRIV(ops);
     struct csched_vcpu *snext;
     struct task_slice ret;
+    s_time_t runtime, tslice;

     CSCHED_STAT_CRANK(schedule);
     CSCHED_VCPU_CHECK(current);

+    runtime =3D now - current->runstate.state_entry_time;
+    if ( runtime < 0 ) /* Does this ever happen? */
+        runtime =3D 0;
+
     if ( !is_idle_vcpu(scurr->vcpu) )
     {
         /* Update credits of a non-idle VCPU. */
@@ -1313,6 +1321,41 @@ csched_schedule(
         scurr->pri =3D CSCHED_PRI_IDLE;
     }

+    /* Choices, choices:
+     * - If we have a tasklet, we need to run the idle vcpu no matter what=
.
+     * - If sched rate limiting is in effect, and the current vcpu has
+     *   run for less than that amount of time, continue the current one,
+     *   but with a shorter timeslice and return it immediately
+     * - Otherwise, chose the one with the highest priority (which may
+     *   be the one currently running)
+     * - If the currently running one is TS_OVER, see if there
+     *   is a higher priority one waiting on the runqueue of another
+     *   cpu and steal it.
+     */
+
+    /* If we have schedule rate limiting enabled, check to see
+     * how long we've run for. */
+    if ( sched_ratelimit_us
+         && !tasklet_work_scheduled
+         && vcpu_runnable(current)
+         && !is_idle_vcpu(current)
+         && runtime < MICROSECS(sched_ratelimit_us) )
+    {
+        snext =3D scurr;
+        snext->start_time +=3D now;
+        perfc_incr(delay_ms);
+        tslice =3D MICROSECS(sched_ratelimit_us);
+        ret.migrated =3D 0;
+        goto out;
+    }
+    else
+    {
+        /*
+         * Select next runnable local VCPU (ie top of local runq)
+        */
+        tslice =3D MILLISECS(prv->tslice_ms);
+    }
+
     /*
      * Select next runnable local VCPU (ie top of local runq)
      */
@@ -1367,11 +1410,12 @@ csched_schedule(
     if ( !is_idle_vcpu(snext->vcpu) )
         snext->start_time +=3D now;

+out:
     /*
      * Return task to run next...
      */
     ret.time =3D (is_idle_vcpu(snext->vcpu) ?
-                -1 : MILLISECS(prv->tslice_ms));
+                -1 : tslice);
     ret.task =3D snext->vcpu;

     CSCHED_VCPU_CHECK(ret.task);
diff -r 1c58bb664d8d xen/common/schedule.c
--- a/xen/common/schedule.c     Thu Dec 08 17:15:16 2011 +0000
+++ b/xen/common/schedule.c     Fri Dec 16 15:08:09 2011 -0500
@@ -47,6 +47,10 @@ string_param("sched", opt_sched);
 bool_t sched_smt_power_savings =3D 0;
 boolean_param("sched_smt_power_savings", sched_smt_power_savings);

+/* Default scheduling rate limit: 1ms */
+int sched_ratelimit_us =3D 1000;
+integer_param("sched_ratelimit_us", sched_ratelimit_us);
+
 /* Various timer handlers. */
 static void s_timer_fn(void *unused);
 static void vcpu_periodic_timer_fn(void *data);
diff -r 1c58bb664d8d xen/include/xen/perfc_defn.h
--- a/xen/include/xen/perfc_defn.h      Thu Dec 08 17:15:16 2011 +0000
+++ b/xen/include/xen/perfc_defn.h      Fri Dec 16 15:08:09 2011 -0500
@@ -16,6 +16,7 @@ PERFCOUNTER(sched_irq,              "sch
 PERFCOUNTER(sched_run,              "sched: runs through scheduler")
 PERFCOUNTER(sched_ctx,              "sched: context switches")

+PERFCOUNTER(delay_ms,              "csched: delay")
 PERFCOUNTER(vcpu_check,             "csched: vcpu_check")
 PERFCOUNTER(schedule,               "csched: schedule")
 PERFCOUNTER(acct_run,               "csched: acct_run")


--_000_C10D3FB0CD45994C8A51FEC1227CE22F37CC284376shsmsx502ccrc_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3D"Generator" content=3D"Microsoft Exchange Server">
<!-- converted from rtf -->
<style><!-- .EmailQuote { margin-left: 1pt; padding-left: 4pt; border-left:=
 #800000 2px solid; } --></style>
</head>
<body>
<font face=3D"Calibri, sans-serif" size=3D"2">
<div>The delay method for credit scheduler can do as well as SRC patch (pre=
vious one) to gain significant performance boost without obvious drawbacks.=
</div>
<div><font face=3D"Times New Roman, serif">&nbsp;</font></div>
<div>1. Basically, the &quot;delay method&quot; can achieve nearly the same=
 benefits as my previous SRC patch, 11% overall performance boost for SPECv=
irt than original credit scheduler.</div>
<div>2.<font color=3D"#1F497D"> </font>We have tried 1ms delay and 10ms del=
ay, there is no big difference between these two configurations. (1ms is en=
ough to achieve a good performance) </div>
<div>3. We have compared different load level response time/latency (low, h=
igh, peak), &quot;delay method&quot; didn't bring very much response time i=
ncrease.</div>
<div>4. 1ms delay can reduce 30% context switch at peak performance, where =
produces the benefits. (<font face=3D"Courier New, monospace">&#8220;</font=
>int sched_ratelimit_us =3D 1000&#8221; is the recommended setting)</div>
<div style=3D"text-align: justify; "><font face=3D"Times New Roman, serif">=
&nbsp;</font></div>
<div style=3D"text-align: justify; "><font face=3D"Times New Roman, serif">=
&nbsp;</font></div>
<div>Signed-off-by: Hui Lv &lt;<a href=3D"mailto:hui.lv@intel.com"><font co=
lor=3D"#0000FF"><u>hui.lv@intel.com</u></font></a>&gt;</div>
<div style=3D"text-align: justify; ">Signed-off-by: George Dunlap &lt;<a hr=
ef=3D"mailto:George.Dunlap@eu.citrix.com"><font color=3D"#0000FF"><u>George=
.Dunlap@eu.citrix.com</u></font></a>&gt;</div>
<div style=3D"text-align: justify; ">&nbsp;</div>
<div style=3D"text-align: justify; ">diff -r 1c58bb664d8d xen/common/sched_=
credit.c</div>
<div style=3D"text-align: justify; ">--- a/xen/common/sched_credit.c Thu De=
c 08 17:15:16 2011 &#43;0000</div>
<div style=3D"text-align: justify; ">&#43;&#43;&#43; b/xen/common/sched_cre=
dit.c Fri Dec 16 15:08:09 2011 -0500</div>
<div style=3D"text-align: justify; ">@@ -110,6 &#43;110,9 @@ boolean_param(=
&quot;sched_credit_default_yiel</div>
<div style=3D"text-align: justify; "> static int __read_mostly sched_credit=
_tslice_ms =3D CSCHED_DEFAULT_TSLICE_MS;</div>
<div style=3D"text-align: justify; "> integer_param(&quot;sched_credit_tsli=
ce_ms&quot;, sched_credit_tslice_ms);</div>
<div style=3D"text-align: justify; ">&nbsp;</div>
<div style=3D"text-align: justify; ">&#43;/* Scheduler generic parameters</=
div>
<div style=3D"text-align: justify; ">&#43;*/</div>
<div style=3D"text-align: justify; ">&#43;extern int sched_ratelimit_us;</d=
iv>
<div style=3D"text-align: justify; "> /*</div>
<div style=3D"text-align: justify; ">&nbsp; * Physical CPU</div>
<div style=3D"text-align: justify; ">&nbsp; */</div>
<div style=3D"text-align: justify; ">@@ -1297,10 &#43;1300,15 @@ csched_sch=
edule(</div>
<div style=3D"text-align: justify; ">&nbsp;&nbsp;&nbsp;&nbsp; struct csched=
_private *prv =3D CSCHED_PRIV(ops);</div>
<div style=3D"text-align: justify; ">&nbsp;&nbsp;&nbsp;&nbsp; struct csched=
_vcpu *snext;</div>
<div style=3D"text-align: justify; ">&nbsp;&nbsp;&nbsp;&nbsp; struct task_s=
lice ret;</div>
<div style=3D"text-align: justify; ">&#43;&nbsp;&nbsp;&nbsp; s_time_t runti=
me, tslice;</div>
<div style=3D"text-align: justify; ">&nbsp;</div>
<div style=3D"text-align: justify; ">&nbsp;&nbsp;&nbsp;&nbsp; CSCHED_STAT_C=
RANK(schedule);</div>
<div style=3D"text-align: justify; ">&nbsp;&nbsp;&nbsp;&nbsp; CSCHED_VCPU_C=
HECK(current);</div>
<div style=3D"text-align: justify; ">&nbsp;</div>
<div style=3D"text-align: justify; ">&#43;&nbsp;&nbsp;&nbsp; runtime =3D no=
w - current-&gt;runstate.state_entry_time;</div>
<div style=3D"text-align: justify; ">&#43;&nbsp;&nbsp;&nbsp; if ( runtime &=
lt; 0 ) /* Does this ever happen? */</div>
<div style=3D"text-align: justify; ">&#43;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp; runtime =3D 0;</div>
<div style=3D"text-align: justify; ">&#43;</div>
<div style=3D"text-align: justify; ">&nbsp;&nbsp;&nbsp;&nbsp; if ( !is_idle=
_vcpu(scurr-&gt;vcpu) )</div>
<div style=3D"text-align: justify; ">&nbsp;&nbsp;&nbsp;&nbsp; {</div>
<div style=3D"text-align: justify; ">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp; /* Update credits of a non-idle VCPU. */</div>
<div style=3D"text-align: justify; ">@@ -1313,6 &#43;1321,41 @@ csched_sche=
dule(</div>
<div style=3D"text-align: justify; ">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp; scurr-&gt;pri =3D CSCHED_PRI_IDLE;</div>
<div style=3D"text-align: justify; ">&nbsp;&nbsp;&nbsp;&nbsp; }</div>
<div style=3D"text-align: justify; ">&nbsp;</div>
<div style=3D"text-align: justify; ">&#43;&nbsp;&nbsp;&nbsp; /* Choices, ch=
oices:</div>
<div style=3D"text-align: justify; ">&#43;&nbsp;&nbsp;&nbsp;&nbsp; * - If w=
e have a tasklet, we need to run the idle vcpu no matter what.</div>
<div style=3D"text-align: justify; ">&#43;&nbsp;&nbsp;&nbsp;&nbsp; * - If s=
ched rate limiting is in effect, and the current vcpu has</div>
<div style=3D"text-align: justify; ">&#43;&nbsp;&nbsp;&nbsp;&nbsp; *&nbsp;&=
nbsp; run for less than that amount of time, continue the current one,</div=
>
<div style=3D"text-align: justify; ">&#43;&nbsp;&nbsp;&nbsp;&nbsp; *&nbsp;&=
nbsp; but with a shorter timeslice and return it immediately</div>
<div style=3D"text-align: justify; ">&#43;&nbsp;&nbsp;&nbsp;&nbsp; * - Othe=
rwise, chose the one with the highest priority (which may</div>
<div style=3D"text-align: justify; ">&#43;&nbsp;&nbsp;&nbsp;&nbsp; *&nbsp;&=
nbsp; be the one currently running)</div>
<div style=3D"text-align: justify; ">&#43;&nbsp;&nbsp;&nbsp;&nbsp; * - If t=
he currently running one is TS_OVER, see if there</div>
<div style=3D"text-align: justify; ">&#43;&nbsp;&nbsp;&nbsp;&nbsp; *&nbsp;&=
nbsp; is a higher priority one waiting on the runqueue of another</div>
<div style=3D"text-align: justify; ">&#43;&nbsp;&nbsp;&nbsp;&nbsp; *&nbsp;&=
nbsp; cpu and steal it.</div>
<div style=3D"text-align: justify; ">&#43;&nbsp;&nbsp;&nbsp;&nbsp; */</div>
<div style=3D"text-align: justify; ">&#43;</div>
<div style=3D"text-align: justify; ">&#43;&nbsp;&nbsp;&nbsp; /* If we have =
schedule rate limiting enabled, check to see</div>
<div style=3D"text-align: justify; ">&#43;&nbsp;&nbsp;&nbsp;&nbsp; * how lo=
ng we've run for. */&nbsp; </div>
<div style=3D"text-align: justify; ">&#43;&nbsp;&nbsp;&nbsp; if ( sched_rat=
elimit_us</div>
<div style=3D"text-align: justify; ">&#43;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp; &amp;&amp; !tasklet_work_scheduled</div>
<div style=3D"text-align: justify; ">&#43;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp; &amp;&amp; vcpu_runnable(current)</div>
<div style=3D"text-align: justify; ">&#43;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp; &amp;&amp; !is_idle_vcpu(current)</div>
<div style=3D"text-align: justify; ">&#43;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp; &amp;&amp; runtime &lt; MICROSECS(sched_ratelimit_us) )</di=
v>
<div style=3D"text-align: justify; ">&#43;&nbsp;&nbsp;&nbsp; {</div>
<div style=3D"text-align: justify; ">&#43;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp; snext =3D scurr;</div>
<div style=3D"text-align: justify; ">&#43;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp; snext-&gt;start_time &#43;=3D now;</div>
<div style=3D"text-align: justify; ">&#43;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp; perfc_incr(delay_ms);</div>
<div style=3D"text-align: justify; ">&#43;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp; tslice =3D MICROSECS(sched_ratelimit_us);</div>
<div style=3D"text-align: justify; ">&#43;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp; ret.migrated =3D 0;</div>
<div style=3D"text-align: justify; ">&#43;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp; goto out;</div>
<div style=3D"text-align: justify; ">&#43;&nbsp;&nbsp;&nbsp; }</div>
<div style=3D"text-align: justify; ">&#43;&nbsp;&nbsp;&nbsp; else</div>
<div style=3D"text-align: justify; ">&#43;&nbsp;&nbsp;&nbsp; {</div>
<div style=3D"text-align: justify; ">&#43;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp; /*</div>
<div style=3D"text-align: justify; ">&#43;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp; * Select next runnable local VCPU (ie top of local runq)</d=
iv>
<div style=3D"text-align: justify; ">&#43;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp; */</div>
<div style=3D"text-align: justify; ">&#43;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp; tslice =3D MILLISECS(prv-&gt;tslice_ms);</div>
<div style=3D"text-align: justify; ">&#43;&nbsp;&nbsp;&nbsp; }</div>
<div style=3D"text-align: justify; ">&#43;&nbsp;&nbsp;&nbsp; </div>
<div style=3D"text-align: justify; ">&nbsp;&nbsp;&nbsp;&nbsp; /*</div>
<div style=3D"text-align: justify; ">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; * Selec=
t next runnable local VCPU (ie top of local runq)</div>
<div style=3D"text-align: justify; ">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; */</div=
>
<div style=3D"text-align: justify; ">@@ -1367,11 &#43;1410,12 @@ csched_sch=
edule(</div>
<div style=3D"text-align: justify; ">&nbsp;&nbsp;&nbsp;&nbsp; if ( !is_idle=
_vcpu(snext-&gt;vcpu) )</div>
<div style=3D"text-align: justify; ">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp; snext-&gt;start_time &#43;=3D now;</div>
<div style=3D"text-align: justify; ">&nbsp;</div>
<div style=3D"text-align: justify; ">&#43;out:</div>
<div style=3D"text-align: justify; ">&nbsp;&nbsp;&nbsp;&nbsp; /*</div>
<div style=3D"text-align: justify; ">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; * Retur=
n task to run next...</div>
<div style=3D"text-align: justify; ">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; */</div=
>
<div style=3D"text-align: justify; ">&nbsp;&nbsp;&nbsp;&nbsp; ret.time =3D =
(is_idle_vcpu(snext-&gt;vcpu) ?</div>
<div style=3D"text-align: justify; ">-&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -1 : MILLISECS(prv-&g=
t;tslice_ms));</div>
<div style=3D"text-align: justify; ">&#43;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -1 : tslice);</di=
v>
<div style=3D"text-align: justify; ">&nbsp;&nbsp;&nbsp;&nbsp; ret.task =3D =
snext-&gt;vcpu;</div>
<div style=3D"text-align: justify; ">&nbsp;</div>
<div style=3D"text-align: justify; ">&nbsp;&nbsp;&nbsp;&nbsp; CSCHED_VCPU_C=
HECK(ret.task);</div>
<div style=3D"text-align: justify; ">diff -r 1c58bb664d8d xen/common/schedu=
le.c</div>
<div style=3D"text-align: justify; ">--- a/xen/common/schedule.c&nbsp;&nbsp=
;&nbsp;&nbsp; Thu Dec 08 17:15:16 2011 &#43;0000</div>
<div style=3D"text-align: justify; ">&#43;&#43;&#43; b/xen/common/schedule.=
c&nbsp;&nbsp;&nbsp;&nbsp; Fri Dec 16 15:08:09 2011 -0500</div>
<div style=3D"text-align: justify; ">@@ -47,6 &#43;47,10 @@ string_param(&q=
uot;sched&quot;, opt_sched);</div>
<div style=3D"text-align: justify; "> bool_t sched_smt_power_savings =3D 0;=
</div>
<div style=3D"text-align: justify; "> boolean_param(&quot;sched_smt_power_s=
avings&quot;, sched_smt_power_savings);</div>
<div style=3D"text-align: justify; ">&nbsp;</div>
<div style=3D"text-align: justify; ">&#43;/* Default scheduling rate limit:=
 1ms */</div>
<div style=3D"text-align: justify; ">&#43;int sched_ratelimit_us =3D 1000;<=
/div>
<div style=3D"text-align: justify; ">&#43;integer_param(&quot;sched_ratelim=
it_us&quot;, sched_ratelimit_us);</div>
<div style=3D"text-align: justify; ">&#43;</div>
<div style=3D"text-align: justify; "> /* Various timer handlers. */</div>
<div style=3D"text-align: justify; "> static void s_timer_fn(void *unused);=
</div>
<div style=3D"text-align: justify; "> static void vcpu_periodic_timer_fn(vo=
id *data);</div>
<div style=3D"text-align: justify; ">diff -r 1c58bb664d8d xen/include/xen/p=
erfc_defn.h</div>
<div style=3D"text-align: justify; ">--- a/xen/include/xen/perfc_defn.h&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp; Thu Dec 08 17:15:16 2011 &#43;0000</div>
<div style=3D"text-align: justify; ">&#43;&#43;&#43; b/xen/include/xen/perf=
c_defn.h&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Fri Dec 16 15:08:09 2011 -0500</div>
<div style=3D"text-align: justify; ">@@ -16,6 &#43;16,7 @@ PERFCOUNTER(sche=
d_irq,&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp; &quot;sch</div>
<div style=3D"text-align: justify; "> PERFCOUNTER(sched_run,&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &quot;sched=
: runs through scheduler&quot;)</div>
<div style=3D"text-align: justify; "> PERFCOUNTER(sched_ctx,&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &quot;sched=
: context switches&quot;)</div>
<div style=3D"text-align: justify; ">&nbsp;</div>
<div style=3D"text-align: justify; ">&#43;PERFCOUNTER(delay_ms,&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &quot;cs=
ched: delay&quot;)</div>
<div style=3D"text-align: justify; "> PERFCOUNTER(vcpu_check,&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &quot;csched: vc=
pu_check&quot;)</div>
<div style=3D"text-align: justify; "> PERFCOUNTER(schedule,&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &quot;=
csched: schedule&quot;)</div>
<div style=3D"text-align: justify; "> PERFCOUNTER(acct_run,&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &quot;=
csched: acct_run&quot;)</div>
<div style=3D"text-align: justify; "><font face=3D"Times New Roman, serif">=
&nbsp;</font></div>
</font>
</body>
</html>

--_000_C10D3FB0CD45994C8A51FEC1227CE22F37CC284376shsmsx502ccrc_--


--===============2275392909118189727==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============2275392909118189727==--


From xen-devel-bounces@lists.xensource.com Sat Dec 17 03:24:53 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 17 Dec 2011 03: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.xensource.com>)
	id 1Rbksi-0003TR-PU; Sat, 17 Dec 2011 03:24:16 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <hui.lv@intel.com>) id 1Rbksh-0003TJ-8E
	for xen-devel@lists.xensource.com; Sat, 17 Dec 2011 03:24:15 +0000
X-Env-Sender: hui.lv@intel.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1324092247!8456880!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMjg5MTY4\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30658 invoked from network); 17 Dec 2011 03:24:08 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-12.tower-21.messagelabs.com with SMTP;
	17 Dec 2011 03:24:08 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga101.jf.intel.com with ESMTP; 16 Dec 2011 19:24:06 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.67,352,1309762800"; d="scan'208,217";a="87529338"
Received: from pgsmsx601.gar.corp.intel.com ([10.221.43.69])
	by orsmga001.jf.intel.com with ESMTP; 16 Dec 2011 19:24:05 -0800
Received: from pgsmsx151.gar.corp.intel.com (172.30.236.41) by
	pgsmsx601.gar.corp.intel.com (10.221.43.69) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Sat, 17 Dec 2011 11:24:04 +0800
Received: from shsmsx602.ccr.corp.intel.com (10.239.4.104) by
	PGSMSX151.gar.corp.intel.com (172.30.236.41) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Sat, 17 Dec 2011 11:24:03 +0800
Received: from shsmsx502.ccr.corp.intel.com ([10.239.4.96]) by
	SHSMSX602.ccr.corp.intel.com ([10.239.4.104]) with mapi;
	Sat, 17 Dec 2011 11:24:03 +0800
From: "Lv, Hui" <hui.lv@intel.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"keir@xen.org" <keir@xen.org>, George Dunlap <George.Dunlap@eu.citrix.com>
Date: Sat, 17 Dec 2011 11:24:02 +0800
Thread-Topic: [PATCH v2] xen/credit scheduler; Use delay to control
	scheduling frequency
Thread-Index: Acy8a1J98NIQa/LRTpOgi509iCZVqg==
Message-ID: <C10D3FB0CD45994C8A51FEC1227CE22F37CC284376@shsmsx502.ccr.corp.intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "Duan, Jiangang" <jiangang.duan@intel.com>, "Yu,
	Zhidong" <zhidong.yu@intel.com>, "Dong,
	Eddie" <eddie.dong@intel.com>, "Tian,
	Kevin" <kevin.tian@intel.com>, "Lv, Hui" <hui.lv@intel.com>
Subject: [Xen-devel] [PATCH v2] xen/credit scheduler;
 Use delay to control scheduling frequency
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============2275392909118189727=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============2275392909118189727==
Content-Language: en-US
Content-Type: multipart/alternative;
	boundary="_000_C10D3FB0CD45994C8A51FEC1227CE22F37CC284376shsmsx502ccrc_"

--_000_C10D3FB0CD45994C8A51FEC1227CE22F37CC284376shsmsx502ccrc_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

The delay method for credit scheduler can do as well as SRC patch (previous=
 one) to gain significant performance boost without obvious drawbacks.

1. Basically, the "delay method" can achieve nearly the same benefits as my=
 previous SRC patch, 11% overall performance boost for SPECvirt than origin=
al credit scheduler.
2. We have tried 1ms delay and 10ms delay, there is no big difference betwe=
en these two configurations. (1ms is enough to achieve a good performance)
3. We have compared different load level response time/latency (low, high, =
peak), "delay method" didn't bring very much response time increase.
4. 1ms delay can reduce 30% context switch at peak performance, where produ=
ces the benefits. ("int sched_ratelimit_us =3D 1000" is the recommended set=
ting)


Signed-off-by: Hui Lv <hui.lv@intel.com<mailto:hui.lv@intel.com>>
Signed-off-by: George Dunlap <George.Dunlap@eu.citrix.com<mailto:George.Dun=
lap@eu.citrix.com>>

diff -r 1c58bb664d8d xen/common/sched_credit.c
--- a/xen/common/sched_credit.c Thu Dec 08 17:15:16 2011 +0000
+++ b/xen/common/sched_credit.c Fri Dec 16 15:08:09 2011 -0500
@@ -110,6 +110,9 @@ boolean_param("sched_credit_default_yiel
 static int __read_mostly sched_credit_tslice_ms =3D CSCHED_DEFAULT_TSLICE_=
MS;
 integer_param("sched_credit_tslice_ms", sched_credit_tslice_ms);

+/* Scheduler generic parameters
+*/
+extern int sched_ratelimit_us;
 /*
  * Physical CPU
  */
@@ -1297,10 +1300,15 @@ csched_schedule(
     struct csched_private *prv =3D CSCHED_PRIV(ops);
     struct csched_vcpu *snext;
     struct task_slice ret;
+    s_time_t runtime, tslice;

     CSCHED_STAT_CRANK(schedule);
     CSCHED_VCPU_CHECK(current);

+    runtime =3D now - current->runstate.state_entry_time;
+    if ( runtime < 0 ) /* Does this ever happen? */
+        runtime =3D 0;
+
     if ( !is_idle_vcpu(scurr->vcpu) )
     {
         /* Update credits of a non-idle VCPU. */
@@ -1313,6 +1321,41 @@ csched_schedule(
         scurr->pri =3D CSCHED_PRI_IDLE;
     }

+    /* Choices, choices:
+     * - If we have a tasklet, we need to run the idle vcpu no matter what=
.
+     * - If sched rate limiting is in effect, and the current vcpu has
+     *   run for less than that amount of time, continue the current one,
+     *   but with a shorter timeslice and return it immediately
+     * - Otherwise, chose the one with the highest priority (which may
+     *   be the one currently running)
+     * - If the currently running one is TS_OVER, see if there
+     *   is a higher priority one waiting on the runqueue of another
+     *   cpu and steal it.
+     */
+
+    /* If we have schedule rate limiting enabled, check to see
+     * how long we've run for. */
+    if ( sched_ratelimit_us
+         && !tasklet_work_scheduled
+         && vcpu_runnable(current)
+         && !is_idle_vcpu(current)
+         && runtime < MICROSECS(sched_ratelimit_us) )
+    {
+        snext =3D scurr;
+        snext->start_time +=3D now;
+        perfc_incr(delay_ms);
+        tslice =3D MICROSECS(sched_ratelimit_us);
+        ret.migrated =3D 0;
+        goto out;
+    }
+    else
+    {
+        /*
+         * Select next runnable local VCPU (ie top of local runq)
+        */
+        tslice =3D MILLISECS(prv->tslice_ms);
+    }
+
     /*
      * Select next runnable local VCPU (ie top of local runq)
      */
@@ -1367,11 +1410,12 @@ csched_schedule(
     if ( !is_idle_vcpu(snext->vcpu) )
         snext->start_time +=3D now;

+out:
     /*
      * Return task to run next...
      */
     ret.time =3D (is_idle_vcpu(snext->vcpu) ?
-                -1 : MILLISECS(prv->tslice_ms));
+                -1 : tslice);
     ret.task =3D snext->vcpu;

     CSCHED_VCPU_CHECK(ret.task);
diff -r 1c58bb664d8d xen/common/schedule.c
--- a/xen/common/schedule.c     Thu Dec 08 17:15:16 2011 +0000
+++ b/xen/common/schedule.c     Fri Dec 16 15:08:09 2011 -0500
@@ -47,6 +47,10 @@ string_param("sched", opt_sched);
 bool_t sched_smt_power_savings =3D 0;
 boolean_param("sched_smt_power_savings", sched_smt_power_savings);

+/* Default scheduling rate limit: 1ms */
+int sched_ratelimit_us =3D 1000;
+integer_param("sched_ratelimit_us", sched_ratelimit_us);
+
 /* Various timer handlers. */
 static void s_timer_fn(void *unused);
 static void vcpu_periodic_timer_fn(void *data);
diff -r 1c58bb664d8d xen/include/xen/perfc_defn.h
--- a/xen/include/xen/perfc_defn.h      Thu Dec 08 17:15:16 2011 +0000
+++ b/xen/include/xen/perfc_defn.h      Fri Dec 16 15:08:09 2011 -0500
@@ -16,6 +16,7 @@ PERFCOUNTER(sched_irq,              "sch
 PERFCOUNTER(sched_run,              "sched: runs through scheduler")
 PERFCOUNTER(sched_ctx,              "sched: context switches")

+PERFCOUNTER(delay_ms,              "csched: delay")
 PERFCOUNTER(vcpu_check,             "csched: vcpu_check")
 PERFCOUNTER(schedule,               "csched: schedule")
 PERFCOUNTER(acct_run,               "csched: acct_run")


--_000_C10D3FB0CD45994C8A51FEC1227CE22F37CC284376shsmsx502ccrc_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3D"Generator" content=3D"Microsoft Exchange Server">
<!-- converted from rtf -->
<style><!-- .EmailQuote { margin-left: 1pt; padding-left: 4pt; border-left:=
 #800000 2px solid; } --></style>
</head>
<body>
<font face=3D"Calibri, sans-serif" size=3D"2">
<div>The delay method for credit scheduler can do as well as SRC patch (pre=
vious one) to gain significant performance boost without obvious drawbacks.=
</div>
<div><font face=3D"Times New Roman, serif">&nbsp;</font></div>
<div>1. Basically, the &quot;delay method&quot; can achieve nearly the same=
 benefits as my previous SRC patch, 11% overall performance boost for SPECv=
irt than original credit scheduler.</div>
<div>2.<font color=3D"#1F497D"> </font>We have tried 1ms delay and 10ms del=
ay, there is no big difference between these two configurations. (1ms is en=
ough to achieve a good performance) </div>
<div>3. We have compared different load level response time/latency (low, h=
igh, peak), &quot;delay method&quot; didn't bring very much response time i=
ncrease.</div>
<div>4. 1ms delay can reduce 30% context switch at peak performance, where =
produces the benefits. (<font face=3D"Courier New, monospace">&#8220;</font=
>int sched_ratelimit_us =3D 1000&#8221; is the recommended setting)</div>
<div style=3D"text-align: justify; "><font face=3D"Times New Roman, serif">=
&nbsp;</font></div>
<div style=3D"text-align: justify; "><font face=3D"Times New Roman, serif">=
&nbsp;</font></div>
<div>Signed-off-by: Hui Lv &lt;<a href=3D"mailto:hui.lv@intel.com"><font co=
lor=3D"#0000FF"><u>hui.lv@intel.com</u></font></a>&gt;</div>
<div style=3D"text-align: justify; ">Signed-off-by: George Dunlap &lt;<a hr=
ef=3D"mailto:George.Dunlap@eu.citrix.com"><font color=3D"#0000FF"><u>George=
.Dunlap@eu.citrix.com</u></font></a>&gt;</div>
<div style=3D"text-align: justify; ">&nbsp;</div>
<div style=3D"text-align: justify; ">diff -r 1c58bb664d8d xen/common/sched_=
credit.c</div>
<div style=3D"text-align: justify; ">--- a/xen/common/sched_credit.c Thu De=
c 08 17:15:16 2011 &#43;0000</div>
<div style=3D"text-align: justify; ">&#43;&#43;&#43; b/xen/common/sched_cre=
dit.c Fri Dec 16 15:08:09 2011 -0500</div>
<div style=3D"text-align: justify; ">@@ -110,6 &#43;110,9 @@ boolean_param(=
&quot;sched_credit_default_yiel</div>
<div style=3D"text-align: justify; "> static int __read_mostly sched_credit=
_tslice_ms =3D CSCHED_DEFAULT_TSLICE_MS;</div>
<div style=3D"text-align: justify; "> integer_param(&quot;sched_credit_tsli=
ce_ms&quot;, sched_credit_tslice_ms);</div>
<div style=3D"text-align: justify; ">&nbsp;</div>
<div style=3D"text-align: justify; ">&#43;/* Scheduler generic parameters</=
div>
<div style=3D"text-align: justify; ">&#43;*/</div>
<div style=3D"text-align: justify; ">&#43;extern int sched_ratelimit_us;</d=
iv>
<div style=3D"text-align: justify; "> /*</div>
<div style=3D"text-align: justify; ">&nbsp; * Physical CPU</div>
<div style=3D"text-align: justify; ">&nbsp; */</div>
<div style=3D"text-align: justify; ">@@ -1297,10 &#43;1300,15 @@ csched_sch=
edule(</div>
<div style=3D"text-align: justify; ">&nbsp;&nbsp;&nbsp;&nbsp; struct csched=
_private *prv =3D CSCHED_PRIV(ops);</div>
<div style=3D"text-align: justify; ">&nbsp;&nbsp;&nbsp;&nbsp; struct csched=
_vcpu *snext;</div>
<div style=3D"text-align: justify; ">&nbsp;&nbsp;&nbsp;&nbsp; struct task_s=
lice ret;</div>
<div style=3D"text-align: justify; ">&#43;&nbsp;&nbsp;&nbsp; s_time_t runti=
me, tslice;</div>
<div style=3D"text-align: justify; ">&nbsp;</div>
<div style=3D"text-align: justify; ">&nbsp;&nbsp;&nbsp;&nbsp; CSCHED_STAT_C=
RANK(schedule);</div>
<div style=3D"text-align: justify; ">&nbsp;&nbsp;&nbsp;&nbsp; CSCHED_VCPU_C=
HECK(current);</div>
<div style=3D"text-align: justify; ">&nbsp;</div>
<div style=3D"text-align: justify; ">&#43;&nbsp;&nbsp;&nbsp; runtime =3D no=
w - current-&gt;runstate.state_entry_time;</div>
<div style=3D"text-align: justify; ">&#43;&nbsp;&nbsp;&nbsp; if ( runtime &=
lt; 0 ) /* Does this ever happen? */</div>
<div style=3D"text-align: justify; ">&#43;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp; runtime =3D 0;</div>
<div style=3D"text-align: justify; ">&#43;</div>
<div style=3D"text-align: justify; ">&nbsp;&nbsp;&nbsp;&nbsp; if ( !is_idle=
_vcpu(scurr-&gt;vcpu) )</div>
<div style=3D"text-align: justify; ">&nbsp;&nbsp;&nbsp;&nbsp; {</div>
<div style=3D"text-align: justify; ">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp; /* Update credits of a non-idle VCPU. */</div>
<div style=3D"text-align: justify; ">@@ -1313,6 &#43;1321,41 @@ csched_sche=
dule(</div>
<div style=3D"text-align: justify; ">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp; scurr-&gt;pri =3D CSCHED_PRI_IDLE;</div>
<div style=3D"text-align: justify; ">&nbsp;&nbsp;&nbsp;&nbsp; }</div>
<div style=3D"text-align: justify; ">&nbsp;</div>
<div style=3D"text-align: justify; ">&#43;&nbsp;&nbsp;&nbsp; /* Choices, ch=
oices:</div>
<div style=3D"text-align: justify; ">&#43;&nbsp;&nbsp;&nbsp;&nbsp; * - If w=
e have a tasklet, we need to run the idle vcpu no matter what.</div>
<div style=3D"text-align: justify; ">&#43;&nbsp;&nbsp;&nbsp;&nbsp; * - If s=
ched rate limiting is in effect, and the current vcpu has</div>
<div style=3D"text-align: justify; ">&#43;&nbsp;&nbsp;&nbsp;&nbsp; *&nbsp;&=
nbsp; run for less than that amount of time, continue the current one,</div=
>
<div style=3D"text-align: justify; ">&#43;&nbsp;&nbsp;&nbsp;&nbsp; *&nbsp;&=
nbsp; but with a shorter timeslice and return it immediately</div>
<div style=3D"text-align: justify; ">&#43;&nbsp;&nbsp;&nbsp;&nbsp; * - Othe=
rwise, chose the one with the highest priority (which may</div>
<div style=3D"text-align: justify; ">&#43;&nbsp;&nbsp;&nbsp;&nbsp; *&nbsp;&=
nbsp; be the one currently running)</div>
<div style=3D"text-align: justify; ">&#43;&nbsp;&nbsp;&nbsp;&nbsp; * - If t=
he currently running one is TS_OVER, see if there</div>
<div style=3D"text-align: justify; ">&#43;&nbsp;&nbsp;&nbsp;&nbsp; *&nbsp;&=
nbsp; is a higher priority one waiting on the runqueue of another</div>
<div style=3D"text-align: justify; ">&#43;&nbsp;&nbsp;&nbsp;&nbsp; *&nbsp;&=
nbsp; cpu and steal it.</div>
<div style=3D"text-align: justify; ">&#43;&nbsp;&nbsp;&nbsp;&nbsp; */</div>
<div style=3D"text-align: justify; ">&#43;</div>
<div style=3D"text-align: justify; ">&#43;&nbsp;&nbsp;&nbsp; /* If we have =
schedule rate limiting enabled, check to see</div>
<div style=3D"text-align: justify; ">&#43;&nbsp;&nbsp;&nbsp;&nbsp; * how lo=
ng we've run for. */&nbsp; </div>
<div style=3D"text-align: justify; ">&#43;&nbsp;&nbsp;&nbsp; if ( sched_rat=
elimit_us</div>
<div style=3D"text-align: justify; ">&#43;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp; &amp;&amp; !tasklet_work_scheduled</div>
<div style=3D"text-align: justify; ">&#43;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp; &amp;&amp; vcpu_runnable(current)</div>
<div style=3D"text-align: justify; ">&#43;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp; &amp;&amp; !is_idle_vcpu(current)</div>
<div style=3D"text-align: justify; ">&#43;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp; &amp;&amp; runtime &lt; MICROSECS(sched_ratelimit_us) )</di=
v>
<div style=3D"text-align: justify; ">&#43;&nbsp;&nbsp;&nbsp; {</div>
<div style=3D"text-align: justify; ">&#43;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp; snext =3D scurr;</div>
<div style=3D"text-align: justify; ">&#43;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp; snext-&gt;start_time &#43;=3D now;</div>
<div style=3D"text-align: justify; ">&#43;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp; perfc_incr(delay_ms);</div>
<div style=3D"text-align: justify; ">&#43;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp; tslice =3D MICROSECS(sched_ratelimit_us);</div>
<div style=3D"text-align: justify; ">&#43;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp; ret.migrated =3D 0;</div>
<div style=3D"text-align: justify; ">&#43;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp; goto out;</div>
<div style=3D"text-align: justify; ">&#43;&nbsp;&nbsp;&nbsp; }</div>
<div style=3D"text-align: justify; ">&#43;&nbsp;&nbsp;&nbsp; else</div>
<div style=3D"text-align: justify; ">&#43;&nbsp;&nbsp;&nbsp; {</div>
<div style=3D"text-align: justify; ">&#43;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp; /*</div>
<div style=3D"text-align: justify; ">&#43;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp; * Select next runnable local VCPU (ie top of local runq)</d=
iv>
<div style=3D"text-align: justify; ">&#43;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp; */</div>
<div style=3D"text-align: justify; ">&#43;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp; tslice =3D MILLISECS(prv-&gt;tslice_ms);</div>
<div style=3D"text-align: justify; ">&#43;&nbsp;&nbsp;&nbsp; }</div>
<div style=3D"text-align: justify; ">&#43;&nbsp;&nbsp;&nbsp; </div>
<div style=3D"text-align: justify; ">&nbsp;&nbsp;&nbsp;&nbsp; /*</div>
<div style=3D"text-align: justify; ">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; * Selec=
t next runnable local VCPU (ie top of local runq)</div>
<div style=3D"text-align: justify; ">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; */</div=
>
<div style=3D"text-align: justify; ">@@ -1367,11 &#43;1410,12 @@ csched_sch=
edule(</div>
<div style=3D"text-align: justify; ">&nbsp;&nbsp;&nbsp;&nbsp; if ( !is_idle=
_vcpu(snext-&gt;vcpu) )</div>
<div style=3D"text-align: justify; ">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp; snext-&gt;start_time &#43;=3D now;</div>
<div style=3D"text-align: justify; ">&nbsp;</div>
<div style=3D"text-align: justify; ">&#43;out:</div>
<div style=3D"text-align: justify; ">&nbsp;&nbsp;&nbsp;&nbsp; /*</div>
<div style=3D"text-align: justify; ">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; * Retur=
n task to run next...</div>
<div style=3D"text-align: justify; ">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; */</div=
>
<div style=3D"text-align: justify; ">&nbsp;&nbsp;&nbsp;&nbsp; ret.time =3D =
(is_idle_vcpu(snext-&gt;vcpu) ?</div>
<div style=3D"text-align: justify; ">-&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -1 : MILLISECS(prv-&g=
t;tslice_ms));</div>
<div style=3D"text-align: justify; ">&#43;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -1 : tslice);</di=
v>
<div style=3D"text-align: justify; ">&nbsp;&nbsp;&nbsp;&nbsp; ret.task =3D =
snext-&gt;vcpu;</div>
<div style=3D"text-align: justify; ">&nbsp;</div>
<div style=3D"text-align: justify; ">&nbsp;&nbsp;&nbsp;&nbsp; CSCHED_VCPU_C=
HECK(ret.task);</div>
<div style=3D"text-align: justify; ">diff -r 1c58bb664d8d xen/common/schedu=
le.c</div>
<div style=3D"text-align: justify; ">--- a/xen/common/schedule.c&nbsp;&nbsp=
;&nbsp;&nbsp; Thu Dec 08 17:15:16 2011 &#43;0000</div>
<div style=3D"text-align: justify; ">&#43;&#43;&#43; b/xen/common/schedule.=
c&nbsp;&nbsp;&nbsp;&nbsp; Fri Dec 16 15:08:09 2011 -0500</div>
<div style=3D"text-align: justify; ">@@ -47,6 &#43;47,10 @@ string_param(&q=
uot;sched&quot;, opt_sched);</div>
<div style=3D"text-align: justify; "> bool_t sched_smt_power_savings =3D 0;=
</div>
<div style=3D"text-align: justify; "> boolean_param(&quot;sched_smt_power_s=
avings&quot;, sched_smt_power_savings);</div>
<div style=3D"text-align: justify; ">&nbsp;</div>
<div style=3D"text-align: justify; ">&#43;/* Default scheduling rate limit:=
 1ms */</div>
<div style=3D"text-align: justify; ">&#43;int sched_ratelimit_us =3D 1000;<=
/div>
<div style=3D"text-align: justify; ">&#43;integer_param(&quot;sched_ratelim=
it_us&quot;, sched_ratelimit_us);</div>
<div style=3D"text-align: justify; ">&#43;</div>
<div style=3D"text-align: justify; "> /* Various timer handlers. */</div>
<div style=3D"text-align: justify; "> static void s_timer_fn(void *unused);=
</div>
<div style=3D"text-align: justify; "> static void vcpu_periodic_timer_fn(vo=
id *data);</div>
<div style=3D"text-align: justify; ">diff -r 1c58bb664d8d xen/include/xen/p=
erfc_defn.h</div>
<div style=3D"text-align: justify; ">--- a/xen/include/xen/perfc_defn.h&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp; Thu Dec 08 17:15:16 2011 &#43;0000</div>
<div style=3D"text-align: justify; ">&#43;&#43;&#43; b/xen/include/xen/perf=
c_defn.h&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Fri Dec 16 15:08:09 2011 -0500</div>
<div style=3D"text-align: justify; ">@@ -16,6 &#43;16,7 @@ PERFCOUNTER(sche=
d_irq,&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp; &quot;sch</div>
<div style=3D"text-align: justify; "> PERFCOUNTER(sched_run,&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &quot;sched=
: runs through scheduler&quot;)</div>
<div style=3D"text-align: justify; "> PERFCOUNTER(sched_ctx,&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &quot;sched=
: context switches&quot;)</div>
<div style=3D"text-align: justify; ">&nbsp;</div>
<div style=3D"text-align: justify; ">&#43;PERFCOUNTER(delay_ms,&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &quot;cs=
ched: delay&quot;)</div>
<div style=3D"text-align: justify; "> PERFCOUNTER(vcpu_check,&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &quot;csched: vc=
pu_check&quot;)</div>
<div style=3D"text-align: justify; "> PERFCOUNTER(schedule,&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &quot;=
csched: schedule&quot;)</div>
<div style=3D"text-align: justify; "> PERFCOUNTER(acct_run,&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &quot;=
csched: acct_run&quot;)</div>
<div style=3D"text-align: justify; "><font face=3D"Times New Roman, serif">=
&nbsp;</font></div>
</font>
</body>
</html>

--_000_C10D3FB0CD45994C8A51FEC1227CE22F37CC284376shsmsx502ccrc_--


--===============2275392909118189727==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============2275392909118189727==--


From xen-devel-bounces@lists.xensource.com Sat Dec 17 03:50:52 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 17 Dec 2011 03:50:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RblHs-0003mX-21; Sat, 17 Dec 2011 03:50:16 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <amscanne@gridcentric.ca>) id 1RblHq-0003mS-Um
	for xen-devel@lists.xensource.com; Sat, 17 Dec 2011 03:50:15 +0000
X-Env-Sender: amscanne@gridcentric.ca
X-Msg-Ref: server-6.tower-216.messagelabs.com!1324093808!7784775!1
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29155 invoked from network); 17 Dec 2011 03:50:09 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Dec 2011 03:50:09 -0000
Received: by wgbds11 with SMTP id ds11so6148346wgb.24
	for <xen-devel@lists.xensource.com>;
	Fri, 16 Dec 2011 19:50:08 -0800 (PST)
Received: by 10.180.4.167 with SMTP id l7mr15968967wil.51.1324093808450; Fri,
	16 Dec 2011 19:50:08 -0800 (PST)
MIME-Version: 1.0
Received: by 10.223.120.68 with HTTP; Fri, 16 Dec 2011 19:49:47 -0800 (PST)
In-Reply-To: <1324092141-9730-1-git-send-email-adin@scannell.ca>
References: <1324092141-9730-1-git-send-email-adin@scannell.ca>
From: Adin Scannell <adin@gridcentric.com>
Date: Fri, 16 Dec 2011 22:49:47 -0500
X-Google-Sender-Auth: v1hZca81al-Q4q2DHlhQyeRlODk
Message-ID: <CAAJKtqrqmrq6G1SrMM=RWEUPZPVpwt-BTQQyjN5jDqLHB=uAww@mail.gmail.com>
To: Adin Scannell <adin@scannell.ca>
Cc: konrad@darnok.org, andres@gridcentric.ca, xen-devel@lists.xensource.com,
	olaf@aepfle.de, JBeulich@suse.com
Subject: Re: [Xen-devel] [PATCH] Add necessary bits to pvops Linux for
	mapping paged-out pages
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> (My apologies if anyone/everyone receives this set of patches more than once,
> I've had some trouble with both my connection dying and guilt freaking out
> while I'm sending, leaving things in a bit of an unknown state.)

In my frustration, things got manual.  This e-mail should be titled
[PATCH 0 of 3].

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Dec 17 03:50:52 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 17 Dec 2011 03:50:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RblHs-0003mX-21; Sat, 17 Dec 2011 03:50:16 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <amscanne@gridcentric.ca>) id 1RblHq-0003mS-Um
	for xen-devel@lists.xensource.com; Sat, 17 Dec 2011 03:50:15 +0000
X-Env-Sender: amscanne@gridcentric.ca
X-Msg-Ref: server-6.tower-216.messagelabs.com!1324093808!7784775!1
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29155 invoked from network); 17 Dec 2011 03:50:09 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Dec 2011 03:50:09 -0000
Received: by wgbds11 with SMTP id ds11so6148346wgb.24
	for <xen-devel@lists.xensource.com>;
	Fri, 16 Dec 2011 19:50:08 -0800 (PST)
Received: by 10.180.4.167 with SMTP id l7mr15968967wil.51.1324093808450; Fri,
	16 Dec 2011 19:50:08 -0800 (PST)
MIME-Version: 1.0
Received: by 10.223.120.68 with HTTP; Fri, 16 Dec 2011 19:49:47 -0800 (PST)
In-Reply-To: <1324092141-9730-1-git-send-email-adin@scannell.ca>
References: <1324092141-9730-1-git-send-email-adin@scannell.ca>
From: Adin Scannell <adin@gridcentric.com>
Date: Fri, 16 Dec 2011 22:49:47 -0500
X-Google-Sender-Auth: v1hZca81al-Q4q2DHlhQyeRlODk
Message-ID: <CAAJKtqrqmrq6G1SrMM=RWEUPZPVpwt-BTQQyjN5jDqLHB=uAww@mail.gmail.com>
To: Adin Scannell <adin@scannell.ca>
Cc: konrad@darnok.org, andres@gridcentric.ca, xen-devel@lists.xensource.com,
	olaf@aepfle.de, JBeulich@suse.com
Subject: Re: [Xen-devel] [PATCH] Add necessary bits to pvops Linux for
	mapping paged-out pages
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> (My apologies if anyone/everyone receives this set of patches more than once,
> I've had some trouble with both my connection dying and guilt freaking out
> while I'm sending, leaving things in a bit of an unknown state.)

In my frustration, things got manual.  This e-mail should be titled
[PATCH 0 of 3].

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Dec 17 07:02:59 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 17 Dec 2011 07:02:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RboHP-0005Qf-JR; Sat, 17 Dec 2011 07:01:59 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RboHN-0005Qa-Ln
	for xen-devel@lists.xensource.com; Sat, 17 Dec 2011 07:01:57 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1324105275!47109229!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjcxMg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19184 invoked from network); 17 Dec 2011 07:01:15 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Dec 2011 07:01:15 -0000
X-IronPort-AV: E=Sophos;i="4.71,367,1320624000"; 
   d="scan'208";a="9526518"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Dec 2011 07:01:55 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sat, 17 Dec 2011 07:01:55 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RboHL-0003JD-JG;
	Sat, 17 Dec 2011 07:01:55 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RboHL-0006JJ-F5;
	Sat, 17 Dec 2011 07:01:55 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10528-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 17 Dec 2011 07:01:55 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10528: tolerable FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10528 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10528/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf      5 xen-boot                    fail pass in 10524
 test-i386-i386-win            7 windows-install             fail pass in 10524

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-i386-i386-win           16 leak-check/check      fail in 10524 never pass

version targeted for testing:
 xen                  a4bff36780a3
baseline version:
 xen                  a4bff36780a3

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Dec 17 07:02:59 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 17 Dec 2011 07:02:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RboHP-0005Qf-JR; Sat, 17 Dec 2011 07:01:59 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RboHN-0005Qa-Ln
	for xen-devel@lists.xensource.com; Sat, 17 Dec 2011 07:01:57 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1324105275!47109229!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjcxMg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19184 invoked from network); 17 Dec 2011 07:01:15 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Dec 2011 07:01:15 -0000
X-IronPort-AV: E=Sophos;i="4.71,367,1320624000"; 
   d="scan'208";a="9526518"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Dec 2011 07:01:55 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sat, 17 Dec 2011 07:01:55 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RboHL-0003JD-JG;
	Sat, 17 Dec 2011 07:01:55 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RboHL-0006JJ-F5;
	Sat, 17 Dec 2011 07:01:55 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10528-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 17 Dec 2011 07:01:55 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10528: tolerable FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10528 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10528/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf      5 xen-boot                    fail pass in 10524
 test-i386-i386-win            7 windows-install             fail pass in 10524

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-i386-i386-win           16 leak-check/check      fail in 10524 never pass

version targeted for testing:
 xen                  a4bff36780a3
baseline version:
 xen                  a4bff36780a3

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Dec 17 09:17:40 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 17 Dec 2011 09:17:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbqNw-0006qm-SD; Sat, 17 Dec 2011 09:16:52 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <gbtux@126.com>) id 1RbqNu-0006qf-Ht
	for xen-devel@lists.xensource.com; Sat, 17 Dec 2011 09:16:51 +0000
X-Env-Sender: gbtux@126.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1324113399!5859922!1
X-Originating-IP: [220.181.15.34]
X-SpamReason: No, hits=1.4 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMjAuMTgxLjE1LjM0ID0+IDY1NzI=\n,sa_preprocessor: 
	QmFkIElQOiAyMjAuMTgxLjE1LjM0ID0+IDY1NzI=\n, BODY_RANDOM_LONG, HTML_40_50,
	HTML_MESSAGE,MIME_BASE64_TEXT
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23074 invoked from network); 17 Dec 2011 09:16:41 -0000
Received: from m15-34.126.com (HELO m15-34.126.com) (220.181.15.34)
	by server-3.tower-174.messagelabs.com with SMTP;
	17 Dec 2011 09:16:41 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=126.com;
	s=s110527; h=Received:Date:From:To:Cc:Message-ID:In-Reply-To:
	References:Subject:MIME-Version:Content-Type; bh=zL8DAN+lROk93Zu
	+s8CzxsASYb7zZA3yukZzyPaRVVw=; b=mUOsZZj40UmyF2LZSonaqL7hD0jD7z1
	GHd1Ha1Q7IslQyUwHpxwCp4aiSDFxeiuU2n9JSLHWEUtQdX3Y0MghthD5nrlYQ4w
	PMzfG7apZgL/kevfNBLDjIog+7Naqo2K4rqbKKUp1ZRpy+lMs0UnkpYSCLTYZi+7
	EJSkW4Be9N9Y=
Received: from gbtux ( [124.16.139.196] ) by ajax-webmail-wmsvr34 (Coremail)
	; Sat, 17 Dec 2011 17:16:25 +0800 (CST)
Date: Sat, 17 Dec 2011 17:16:25 +0800 (CST)
From: gavin  <gbtux@126.com>
To: "George Dunlap" <George.Dunlap@eu.citrix.com>
Message-ID: <35e4701f.ca5a.1344b4ed98e.Coremail.gbtux@126.com>
In-Reply-To: <CAFLBxZaBiwEvz-dgPzgBQQTj2xMi8m+QnZ3M+uoqw4AKmb0ZvA@mail.gmail.com>
References: <CAFLBxZaBiwEvz-dgPzgBQQTj2xMi8m+QnZ3M+uoqw4AKmb0ZvA@mail.gmail.com>
	<26c93838.3b3fb.13445de0e67.Coremail.gbtux@126.com>
	<CAFLBxZYM-8vEc5Egmv+iXqMDUE_UJcgHbwr7=71H-kFowTzXWA@mail.gmail.com>
	<676b608e.2fb26.13447553671.Coremail.gbtux@126.com>
MIME-Version: 1.0
X-Originating-IP: [124.16.139.196]
X-Priority: 3
X-Mailer: Coremail Webmail Server Version SP_ntes V3.5 build
	111202(16086.4213.4207) Copyright (c) 2002-2011 www.mailtech.cn 126com
X-CM-CTRLDATA: HR/Dk2Zvb3Rlcl9odG09NjIyMDo4MQ==
X-CM-TRANSID: IsqowEApCEXsXexOEDIcAA--.3273W
X-CM-SenderInfo: pjew35a6rslhhfrp/1tbiHQ8ZnEihT4TjtAAAsi
X-Coremail-Antispam: 1U5529EdanIXcx71UUUUU7vcSsGvfC2KfnxnUU==
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] A question on the credit scheduler
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3832773490774469895=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============3832773490774469895==
Content-Type: multipart/alternative; 
	boundary="----=_Part_151475_544120518.1324113385869"

------=_Part_151475_544120518.1324113385869
Content-Type: text/plain; charset=GBK
Content-Transfer-Encoding: base64

CkF0IDIwMTEtMTItMTYgMjM6NTg6MjYsIkdlb3JnZSBEdW5sYXAiIDxHZW9yZ2UuRHVubGFwQGV1
LmNpdHJpeC5jb20+IHdyb3RlOgo+MjAxMS8xMi8xNiBnYXZpbiA8Z2J0dXhAMTI2LmNvbT46Cj4+
IEF0IDIwMTEtMTItMTYgMTk6MDQ6MTksIkdlb3JnZSBEdW5sYXAiIDxHZW9yZ2UuRHVubGFwQGV1
LmNpdHJpeC5jb20+IHdyb3RlOgo+Pgo+Pj4yMDExLzEyLzE2IHpoaWthaSA8Z2J0dXhAMTI2LmNv
bT46Cj4+Pj4gSGkgQWxsLAo+Pj4+Cj4+Pj4gSW4gdGhlIGNyZWRpdCBzY2hlZHVsZXIsIHRoZSBz
Y2hlZHVsaW5nIGRlY2lzaW9uIGZ1bmN0aW9uIGNzY2hlZF9zY2hlZHVsZSgpCj4+Pj4gaXMgY2Fs
bGVkIGluIHRoZSBzY2hlZHVsZSBmdW5jdGlvbiBpbiBzY2hlZHVsZXIuYywgc3VjaCBhcyB0aGUg
Zm9sbG93aW5nLgo+Pj4+IG5leHRfc2xpY2UgPSBzY2hlZC0+ZG9fc2NoZWR1bGUoc2NoZWQsIG5v
dywgdGFza2xldF93b3JrX3NjaGVkdWxlZCk7Cj4+Pj4KPj4+PiBCdXQsIGhvdyBvZnRlbiB0aGUg
Y3NjaGVkX3NjaGVkdWxlKCkgaXMgY2FsbGVkIGFuZCB0byBydW4/IERvZXMgdGhpcwo+Pj4+IGZy
ZXF1ZW5jeSBoYXZlIHNvbWV0aGluZyB0byBkbyB3aXRoIHRoZSBzbGljZSBvZiBjcmVkaXQgc2No
ZWR1bGVyIHRoYXQgaXMKPj4+PiAzMG1zPwo+Pj4KPj4+VGhlIHNjaGVkdWxlciBydW5zIHdoZW5l
dmVyIHRoZSBTQ0hFRFVMRV9TT0ZUSVJRIGlzIHJhaXNlZC4gIElmIHlvdQo+Pj5ncmVwIHRocm91
Z2ggdGhlIHNvdXJjZSBjb2RlIGZybyB0aGF0IHN0cmluZywgeW91IGNhbiBmaW5kIGFsbCB0aGUK
Pj4+cGxhY2VzIHdoZXJlIGl0J3MgcmFpc2VkLgo+Pj4KPj4+U29tZSBleGFtcGxlcyBpbmNsdWRl
Ogo+Pj4qIFdoZW4gdGhlIDMwbXMgdGltZXNsaWNlIGlzIGZpbmlzaGVkCj4+PiogV2hlbiBhIHNs
ZWVwaW5nIHZjcHUgb2YgaGlnaGVyIHByaW9yaXR5IHRoYW4gd2hhdCdzIGN1cnJlbnRseSBydW5u
aW5nIHdha2VzIHVwCj4+PiogV2hlbiBhIHZjcHUgYmxvY2tzCj4+PiogV2hlbiBhIHZjcHUgaXMg
bWlncmF0ZWQgZnJvbSBvbmUgY3B1IHRvIGFub3RoZXIKPj4+Cj4+PjMwbXMgaXMgYWN0dWFsbHkg
YSBwcmV0dHkgbG9uZyB0aW1lOyBpbiB0eXBpY2FsIHdvcmtsb2FkcywgdmNwdXMgYmxvY2sKPj4+
b3IgYXJlIHByZWVtcHRlZCBieSBvdGhlciB3YWtpbmcgdmNwdXMgd2l0aG91dCB1c2luZyB1cCB0
aGVpciBmdWxsCj4+PnRpbWVzbGljZS4KPj4KPj4gVGhhbmsgeW91IHZlcnkgbXVjaCBmb3IgeW91
ciByZXBseS4KPj4KPj4gU28sIHRoZSB2Y3B1IGlzIHZlcnkgbGlrZWx5IHRvIGJlIHByZWVtcHRl
ZCB3aGVuZXZlciB0aGUgU0NIRURVTEVfU09GVElSUSBpcwo+PiByYWlzZWQuCj4KPkl0IGRlcGVu
ZHM7IGlmIHlvdSBoYXZlIGEgY3B1LWJ1cm5pbmcgdmNwdSBydW5uaW5nIG9uIGEgY3B1IGFsbCBi
eQo+aXRzZWxmLCB0aGVuIGFmdGVyIGl0cyAzMG1zIHRpbWVzbGljZSwgWGVuIHdpbGwgaGF2ZSBu
byBvbmUgZWxzZSB0bwo+cnVuLCBhbmQgc28gd2lsbCBsZXQgaXQgcnVuIGFnYWluLgo+Cj5CdXQg
eWVzLCBpZiB0aGVyZSBhcmUgb3RoZXIgdmNwdXMgb24gdGhlIHJ1bnF1ZXVlLCBvciB0aGUgaG9z
dCBpcwo+bW9kZXJhdGVseSBidXN5LCBpdCdzIGxpa2VseSB0aGF0IFNDSEVEVUxFX1NPRlRJUlEg
d2lsbCBjYXVzZSBhCj5jb250ZXh0LXN3aXRjaC4KPgo+PiBBbmQgd2UgY2Fubm90IGZpbmQgYSBz
bWFsbCB0aW1lc2xpY2UsIHN1Y2ggYXMgYShtcyksIHdoaWNoIG1ha2VzIHRoZQo+PiB0aW1lIGFu
eSB2Y3B1IHNwZW5kaW5nIG9uIHJ1bm5pbmcgcGhhc2UgaXMgayphKG1zKSwgayBpcyBpbnRlZ2Vy
IGhlcmUuIFRoZXJlCj4+IGlzIG5vIHN1Y2ggYSBzbWFsbCB0aW1lc2xpY2UuIElzIGl0IHJpZ2h0
Pwo+Cj5JJ20gc29ycnksIEkgZG9uJ3QgcmVhbGx5IHVuZGVyc3RhbmQgeW91ciBxdWVzdGlvbi4g
IFBlcmhhcHMgaWYgeW91Cj50b2xkIG1lIHdoYXQgeW91J3JlIHRyeWluZyB0byBhY2NvbXBsaXNo
PwoKSSB0cnkgdG8gZGVzY3JpYmUgbXkgaWRlYSBhcyB0aGUgZm9sbG93aW5nIGNsZWFybHkuIEJ1
dCBJIHJlYWxseSBkb24ndCBrbm93IGlmIGl0IHdpbGwgd29yay4gUGxlYXNlIGdpdmUgbWUgc29t
ZSBhZHZpY2UgaWYgcG9zc2libGUuCgpBY2NvcmRpbmcgdG8gdGhlIGNyZWRpdCBzY2hlZHVsZXIg
aW4gWGVuLCBhIHZDUFUgY2FuIHJ1biBhIDMwbXMgdGltZXNsaWNlIHdoZW4gaXQgaXMgc2NoZWR1
bGVkIG9uIHRoZSBwaHlzaWNhbCBDUFUuIEFuZCwgYSB2Q1BVIHdpdGggdGhlIEJPT1NUIHByaW9y
aXR5IHdpbGwgcHJlZW1wdCB0aGUgcnVubmluZyBvbmUgYW5kIHJ1biBhZGRpdGlvbmFsIDEwbXMu
IFNvLCB3aGF0IEkgdGhpbmsgaXMgaWYgd2UgbW9uaXRvciB0aGUgcGh5c2ljYWwgQ1BVIGV2ZXJ5
IDEwbXMgYW5kIHdlIGNhbiBnZXQgdGhlIG1hcHBpbmcgaW5mb3JtYXRpb24gb2YgYSBwaHlzaWNh
bCBDUFUgYW5kIGEgdkNQVS4gQW5kIGFsc28sIHdlIGNhbiBnZXQgdGhlIHVuLW1hcHBpbmcgaW5m
b3JtYXRpb24gdGhhdCBhIHBoeXNpY2FsIENQVSBpc26hr3QgbWFwcGVkIHRvIGFueSB2Q1BVLiBU
aHVzLCB3ZSBjYW4gZ2V0IHRoZSBDUFUgdXNhZ2UgYnkgY2FsY3VsYXRpbmcgdGhlIHByb3BvcnRp
b24gb2YgdGhlIG1hcHBpbmcgaW5mb3JtYXRpb24gdG8gdGhlIHRvdGFsIHRpbWUgd2hlbiB3ZSBt
b25pdG9yZWQuIAoKRm9yIGV4YW1wbGUsIGlmIHdlIG1vbml0b3IgdGhlIHBoeXNpY2FsIENQVXMg
ZXZlcnkgMTBtcyBhbmQgd2UgY2FuIGdldCAxMDAgcGFpcnMgb2YgcENQVSBhbmQgdkNQVSBpbiBh
IHNlY29uZCwgc3VjaCBhcyAocENQVV9pZCwgdkNQVV9pZCkuIElmIHRoZXJlIGlzIDYwIG1hcHBp
bmcgcGFpcnMgdGhhdCB0aGUgcENQVSBpcyBtYXBwZWQgdG8gYSB2YWxpZCB2UENVLCBhbmQgNDAg
dW4tbWFwcGluZyBwYWlycyB0aGF0IHdlIGNhbm5vdCBmaW5kIHRoZSBwQ1BVIHRvIGJlIG1hcHBl
ZCBhIHZhbGlkIHZDUFUuIFNvLCB3ZSBjYW4gZ2V0IHRoZSB1c2FnZSBvZiB0aGUgcGh5c2ljYWwg
Q1BVcyB0aGF0IGlzIDYwJS4KCkhlcmUsIHdlIG1vbml0b3IgdGhlIHBoeXNpY2FsIENQVXMgZXZl
cnkgMTBtcy4gV2UgYWxzbyBjYW4gbW9uaXRvciB0aGVtIG9uY2UgbGVzcyB0aGFuIHRoZSAxMG1z
IGludGVydmFsLCBzdWNoIGFzIDFtcyBpbnRlcnZhbC4gV2hhdGV2ZXIgaW50ZXJ2YWwgd2UgY2hv
b3NlLCB3ZSBtdXN0IG1ha2Ugc3VyZSBubyBDUFUgY29udGVudCBzd2l0Y2ggaW4gdGhlIGludGVy
dmFsIG9yIHRoZSBjb250ZXh0IHN3aXRjaCBhbHdheXMgb2NjdXIgYXQgdGhlIGVkZ2Ugb2YgaW50
ZXJ2YWwuIE9ubHkgaW4gdGhpcyBjb25kaXRpb24sIGNhbiB0aGlzIGlkZWEgd29yay4gCgpTbywg
SSBhbSBub3Qgc3VyZSB3aGV0aGVyIHdlIGNhbiBmaW5kIHN1Y2ggYSB0aW1lIGludGVydmFsIHRo
YXQgY2FuIG1lZXQgdGhpcyBjb25kaXRpb24uIEluIG90aGVyIHdvcmRzLCB3aGV0aGVyIHdlIGNh
biBmaW5kIHN1Y2ggYSB0aW1lIGludGVydmFsIHRoYXQgZW5zdXJlcyBhbGwgdGhlIENQVSBjb250
ZW50IHN3aXRjaCBvY2N1ciBhdCB0aGUgZWRnZSBvZiBpbnRlcnZhbC4KCgoKClRoYW5rIHlvdSB2
ZXJ5IG11Y2guCgpHYXZpbgoKCj4gLUdlb3JnZQo+Cj5fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fXwo+WGVuLWRldmVsIG1haWxpbmcgbGlzdAo+WGVuLWRldmVs
QGxpc3RzLnhlbnNvdXJjZS5jb20KPmh0dHA6Ly9saXN0cy54ZW5zb3VyY2UuY29tL3hlbi1kZXZl
bAo=
------=_Part_151475_544120518.1324113385869
Content-Type: text/html; charset=GBK
Content-Transfer-Encoding: base64

PGRpdiBzdHlsZT0ibGluZS1oZWlnaHQ6MS43O2NvbG9yOiMwMDAwMDA7Zm9udC1zaXplOjE0cHg7
Zm9udC1mYW1pbHk6YXJpYWwiPjxwcmU+PGJyPkF0Jm5ic3A7MjAxMS0xMi0xNiZuYnNwOzIzOjU4
OjI2LCJHZW9yZ2UmbmJzcDtEdW5sYXAiJm5ic3A7Jmx0O0dlb3JnZS5EdW5sYXBAZXUuY2l0cml4
LmNvbSZndDsmbmJzcDt3cm90ZToKJmd0OzIwMTEvMTIvMTYmbmJzcDtnYXZpbiZuYnNwOyZsdDtn
YnR1eEAxMjYuY29tJmd0OzoKJmd0OyZndDsmbmJzcDtBdCZuYnNwOzIwMTEtMTItMTYmbmJzcDsx
OTowNDoxOSwiR2VvcmdlJm5ic3A7RHVubGFwIiZuYnNwOyZsdDtHZW9yZ2UuRHVubGFwQGV1LmNp
dHJpeC5jb20mZ3Q7Jm5ic3A7d3JvdGU6CiZndDsmZ3Q7CiZndDsmZ3Q7Jmd0OzIwMTEvMTIvMTYm
bmJzcDt6aGlrYWkmbmJzcDsmbHQ7Z2J0dXhAMTI2LmNvbSZndDs6CiZndDsmZ3Q7Jmd0OyZndDsm
bmJzcDtIaSZuYnNwO0FsbCwKJmd0OyZndDsmZ3Q7Jmd0OwomZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7
SW4mbmJzcDt0aGUmbmJzcDtjcmVkaXQmbmJzcDtzY2hlZHVsZXIsJm5ic3A7dGhlJm5ic3A7c2No
ZWR1bGluZyZuYnNwO2RlY2lzaW9uJm5ic3A7ZnVuY3Rpb24mbmJzcDtjc2NoZWRfc2NoZWR1bGUo
KQomZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7aXMmbmJzcDtjYWxsZWQmbmJzcDtpbiZuYnNwO3RoZSZu
YnNwO3NjaGVkdWxlJm5ic3A7ZnVuY3Rpb24mbmJzcDtpbiZuYnNwO3NjaGVkdWxlci5jLCZuYnNw
O3N1Y2gmbmJzcDthcyZuYnNwO3RoZSZuYnNwO2ZvbGxvd2luZy4KJmd0OyZndDsmZ3Q7Jmd0OyZu
YnNwO25leHRfc2xpY2UmbmJzcDs9Jm5ic3A7c2NoZWQtJmd0O2RvX3NjaGVkdWxlKHNjaGVkLCZu
YnNwO25vdywmbmJzcDt0YXNrbGV0X3dvcmtfc2NoZWR1bGVkKTsKJmd0OyZndDsmZ3Q7Jmd0Owom
Z3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7QnV0LCZuYnNwO2hvdyZuYnNwO29mdGVuJm5ic3A7dGhlJm5i
c3A7Y3NjaGVkX3NjaGVkdWxlKCkmbmJzcDtpcyZuYnNwO2NhbGxlZCZuYnNwO2FuZCZuYnNwO3Rv
Jm5ic3A7cnVuPyZuYnNwO0RvZXMmbmJzcDt0aGlzCiZndDsmZ3Q7Jmd0OyZndDsmbmJzcDtmcmVx
dWVuY3kmbmJzcDtoYXZlJm5ic3A7c29tZXRoaW5nJm5ic3A7dG8mbmJzcDtkbyZuYnNwO3dpdGgm
bmJzcDt0aGUmbmJzcDtzbGljZSZuYnNwO29mJm5ic3A7Y3JlZGl0Jm5ic3A7c2NoZWR1bGVyJm5i
c3A7dGhhdCZuYnNwO2lzCiZndDsmZ3Q7Jmd0OyZndDsmbmJzcDszMG1zPwomZ3Q7Jmd0OyZndDsK
Jmd0OyZndDsmZ3Q7VGhlJm5ic3A7c2NoZWR1bGVyJm5ic3A7cnVucyZuYnNwO3doZW5ldmVyJm5i
c3A7dGhlJm5ic3A7U0NIRURVTEVfU09GVElSUSZuYnNwO2lzJm5ic3A7cmFpc2VkLiZuYnNwOyZu
YnNwO0lmJm5ic3A7eW91CiZndDsmZ3Q7Jmd0O2dyZXAmbmJzcDt0aHJvdWdoJm5ic3A7dGhlJm5i
c3A7c291cmNlJm5ic3A7Y29kZSZuYnNwO2ZybyZuYnNwO3RoYXQmbmJzcDtzdHJpbmcsJm5ic3A7
eW91Jm5ic3A7Y2FuJm5ic3A7ZmluZCZuYnNwO2FsbCZuYnNwO3RoZQomZ3Q7Jmd0OyZndDtwbGFj
ZXMmbmJzcDt3aGVyZSZuYnNwO2l0J3MmbmJzcDtyYWlzZWQuCiZndDsmZ3Q7Jmd0OwomZ3Q7Jmd0
OyZndDtTb21lJm5ic3A7ZXhhbXBsZXMmbmJzcDtpbmNsdWRlOgomZ3Q7Jmd0OyZndDsqJm5ic3A7
V2hlbiZuYnNwO3RoZSZuYnNwOzMwbXMmbmJzcDt0aW1lc2xpY2UmbmJzcDtpcyZuYnNwO2Zpbmlz
aGVkCiZndDsmZ3Q7Jmd0OyombmJzcDtXaGVuJm5ic3A7YSZuYnNwO3NsZWVwaW5nJm5ic3A7dmNw
dSZuYnNwO29mJm5ic3A7aGlnaGVyJm5ic3A7cHJpb3JpdHkmbmJzcDt0aGFuJm5ic3A7d2hhdCdz
Jm5ic3A7Y3VycmVudGx5Jm5ic3A7cnVubmluZyZuYnNwO3dha2VzJm5ic3A7dXAKJmd0OyZndDsm
Z3Q7KiZuYnNwO1doZW4mbmJzcDthJm5ic3A7dmNwdSZuYnNwO2Jsb2NrcwomZ3Q7Jmd0OyZndDsq
Jm5ic3A7V2hlbiZuYnNwO2EmbmJzcDt2Y3B1Jm5ic3A7aXMmbmJzcDttaWdyYXRlZCZuYnNwO2Zy
b20mbmJzcDtvbmUmbmJzcDtjcHUmbmJzcDt0byZuYnNwO2Fub3RoZXIKJmd0OyZndDsmZ3Q7CiZn
dDsmZ3Q7Jmd0OzMwbXMmbmJzcDtpcyZuYnNwO2FjdHVhbGx5Jm5ic3A7YSZuYnNwO3ByZXR0eSZu
YnNwO2xvbmcmbmJzcDt0aW1lOyZuYnNwO2luJm5ic3A7dHlwaWNhbCZuYnNwO3dvcmtsb2Fkcywm
bmJzcDt2Y3B1cyZuYnNwO2Jsb2NrCiZndDsmZ3Q7Jmd0O29yJm5ic3A7YXJlJm5ic3A7cHJlZW1w
dGVkJm5ic3A7YnkmbmJzcDtvdGhlciZuYnNwO3dha2luZyZuYnNwO3ZjcHVzJm5ic3A7d2l0aG91
dCZuYnNwO3VzaW5nJm5ic3A7dXAmbmJzcDt0aGVpciZuYnNwO2Z1bGwKJmd0OyZndDsmZ3Q7dGlt
ZXNsaWNlLgomZ3Q7Jmd0OwomZ3Q7Jmd0OyZuYnNwO1RoYW5rJm5ic3A7eW91Jm5ic3A7dmVyeSZu
YnNwO211Y2gmbmJzcDtmb3ImbmJzcDt5b3VyJm5ic3A7cmVwbHkuCiZndDsmZ3Q7CiZndDsmZ3Q7
Jm5ic3A7U28sJm5ic3A7dGhlJm5ic3A7dmNwdSZuYnNwO2lzJm5ic3A7dmVyeSZuYnNwO2xpa2Vs
eSZuYnNwO3RvJm5ic3A7YmUmbmJzcDtwcmVlbXB0ZWQmbmJzcDt3aGVuZXZlciZuYnNwO3RoZSZu
YnNwO1NDSEVEVUxFX1NPRlRJUlEmbmJzcDtpcwomZ3Q7Jmd0OyZuYnNwO3JhaXNlZC4KJmd0Owom
Z3Q7SXQmbmJzcDtkZXBlbmRzOyZuYnNwO2lmJm5ic3A7eW91Jm5ic3A7aGF2ZSZuYnNwO2EmbmJz
cDtjcHUtYnVybmluZyZuYnNwO3ZjcHUmbmJzcDtydW5uaW5nJm5ic3A7b24mbmJzcDthJm5ic3A7
Y3B1Jm5ic3A7YWxsJm5ic3A7YnkKJmd0O2l0c2VsZiwmbmJzcDt0aGVuJm5ic3A7YWZ0ZXImbmJz
cDtpdHMmbmJzcDszMG1zJm5ic3A7dGltZXNsaWNlLCZuYnNwO1hlbiZuYnNwO3dpbGwmbmJzcDto
YXZlJm5ic3A7bm8mbmJzcDtvbmUmbmJzcDtlbHNlJm5ic3A7dG8KJmd0O3J1biwmbmJzcDthbmQm
bmJzcDtzbyZuYnNwO3dpbGwmbmJzcDtsZXQmbmJzcDtpdCZuYnNwO3J1biZuYnNwO2FnYWluLgom
Z3Q7CiZndDtCdXQmbmJzcDt5ZXMsJm5ic3A7aWYmbmJzcDt0aGVyZSZuYnNwO2FyZSZuYnNwO290
aGVyJm5ic3A7dmNwdXMmbmJzcDtvbiZuYnNwO3RoZSZuYnNwO3J1bnF1ZXVlLCZuYnNwO29yJm5i
c3A7dGhlJm5ic3A7aG9zdCZuYnNwO2lzCiZndDttb2RlcmF0ZWx5Jm5ic3A7YnVzeSwmbmJzcDtp
dCdzJm5ic3A7bGlrZWx5Jm5ic3A7dGhhdCZuYnNwO1NDSEVEVUxFX1NPRlRJUlEmbmJzcDt3aWxs
Jm5ic3A7Y2F1c2UmbmJzcDthCiZndDtjb250ZXh0LXN3aXRjaC4KJmd0OwomZ3Q7Jmd0OyZuYnNw
O0FuZCZuYnNwO3dlJm5ic3A7Y2Fubm90Jm5ic3A7ZmluZCZuYnNwO2EmbmJzcDtzbWFsbCZuYnNw
O3RpbWVzbGljZSwmbmJzcDtzdWNoJm5ic3A7YXMmbmJzcDthKG1zKSwmbmJzcDt3aGljaCZuYnNw
O21ha2VzJm5ic3A7dGhlCiZndDsmZ3Q7Jm5ic3A7dGltZSZuYnNwO2FueSZuYnNwO3ZjcHUmbmJz
cDtzcGVuZGluZyZuYnNwO29uJm5ic3A7cnVubmluZyZuYnNwO3BoYXNlJm5ic3A7aXMmbmJzcDtr
KmEobXMpLCZuYnNwO2smbmJzcDtpcyZuYnNwO2ludGVnZXImbmJzcDtoZXJlLiZuYnNwO1RoZXJl
CiZndDsmZ3Q7Jm5ic3A7aXMmbmJzcDtubyZuYnNwO3N1Y2gmbmJzcDthJm5ic3A7c21hbGwmbmJz
cDt0aW1lc2xpY2UuJm5ic3A7SXMmbmJzcDtpdCZuYnNwO3JpZ2h0PwomZ3Q7CiZndDtJJ20mbmJz
cDtzb3JyeSwmbmJzcDtJJm5ic3A7ZG9uJ3QmbmJzcDtyZWFsbHkmbmJzcDt1bmRlcnN0YW5kJm5i
c3A7eW91ciZuYnNwO3F1ZXN0aW9uLiZuYnNwOyZuYnNwO1BlcmhhcHMmbmJzcDtpZiZuYnNwO3lv
dQomZ3Q7dG9sZCZuYnNwO21lJm5ic3A7d2hhdCZuYnNwO3lvdSdyZSZuYnNwO3RyeWluZyZuYnNw
O3RvJm5ic3A7YWNjb21wbGlzaD88L3ByZT48cHJlPjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IGxhbmc9IkVOLVVTIj5JIHRyeSB0byBkZXNjcmliZSBteSBpZGVhIGFzIHRoZSBmb2xsb3dpbmcg
Y2xlYXJseS4gQnV0IEkgcmVhbGx5IGRvbid0IGtub3cgaWYgaXQgd2lsbCB3b3JrLiBQbGVhc2Ug
Z2l2ZSBtZSBzb21lIGFkdmljZSBpZiBwb3NzaWJsZS48L3NwYW4+PC9wPjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5BY2NvcmRpbmcgdG8gdGhlIGNyZWRpdCBzY2hlZHVs
ZXIgaW4gWGVuLCBhIHZDUFUgY2FuIHJ1biBhIDMwbXMgdGltZXNsaWNlIHdoZW4gaXQgaXMgc2No
ZWR1bGVkIG9uIHRoZSBwaHlzaWNhbCBDUFUuIEFuZCwgYSB2Q1BVIHdpdGggdGhlIEJPT1NUIHBy
aW9yaXR5IHdpbGwgcHJlZW1wdCB0aGUgcnVubmluZyBvbmUgYW5kIHJ1biBhZGRpdGlvbmFsIDEw
bXMuIFNvLCB3aGF0IEkgdGhpbmsgaXMgaWYgd2UgbW9uaXRvciB0aGUgcGh5c2ljYWwgQ1BVIGV2
ZXJ5IDEwbXMgYW5kIHdlIGNhbiBnZXQgdGhlIG1hcHBpbmcgaW5mb3JtYXRpb24gb2YgYSBwaHlz
aWNhbCBDUFUgYW5kIGEgdkNQVS4gQW5kIGFsc28sIHdlIGNhbiBnZXQgdGhlIHVuLW1hcHBpbmcg
aW5mb3JtYXRpb24gdGhhdCBhIHBoeXNpY2FsIENQVSBpc26hr3QgbWFwcGVkIHRvIGFueSB2Q1BV
LiBUaHVzLCB3ZSBjYW4gZ2V0IHRoZSBDUFUgdXNhZ2UgYnkgY2FsY3VsYXRpbmcgdGhlIHByb3Bv
cnRpb24gb2YgdGhlIG1hcHBpbmcgaW5mb3JtYXRpb24gdG8gdGhlIHRvdGFsIHRpbWUgd2hlbiB3
ZSBtb25pdG9yZWQuIDwvc3Bhbj48L3A+PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i
RU4tVVMiPkZvciBleGFtcGxlLCBpZiB3ZSBtb25pdG9yIHRoZSBwaHlzaWNhbCBDUFVzIGV2ZXJ5
IDEwbXMgYW5kIHdlIGNhbiBnZXQgMTAwIHBhaXJzIG9mIHBDUFUgYW5kIHZDUFUgaW4gYSBzZWNv
bmQsIHN1Y2ggYXMgKHBDUFVfaWQsIHZDUFVfaWQpLiBJZiB0aGVyZSBpcyA2MCBtYXBwaW5nIHBh
aXJzIHRoYXQgdGhlIHBDUFUgaXMgbWFwcGVkIHRvIGEgdmFsaWQgdlBDVSwgYW5kIDQwIHVuLW1h
cHBpbmcgcGFpcnMgdGhhdCB3ZSBjYW5ub3QgZmluZCB0aGUgcENQVSB0byBiZSBtYXBwZWQgYSB2
YWxpZCB2Q1BVLiBTbywgd2UgY2FuIGdldCB0aGUgdXNhZ2Ugb2YgdGhlIHBoeXNpY2FsIENQVXMg
dGhhdCBpcyA2MCUuPC9zcGFuPjwvcD48cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF
Ti1VUyI+SGVyZSwgd2UgbW9uaXRvciB0aGUgcGh5c2ljYWwgQ1BVcyBldmVyeSAxMG1zLiBXZSBh
bHNvIGNhbiBtb25pdG9yIHRoZW0gb25jZSBsZXNzIHRoYW4gdGhlIDEwbXMgaW50ZXJ2YWwsIHN1
Y2ggYXMgMW1zIGludGVydmFsLiBXaGF0ZXZlciBpbnRlcnZhbCB3ZSBjaG9vc2UsIHdlIG11c3Qg
bWFrZSBzdXJlIDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOnJlZCI+bm8g
Q1BVIGNvbnRlbnQgc3dpdGNoIGluIHRoZSBpbnRlcnZhbDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1V
UyI+IG9yIHRoZSA8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpyZWQiPmNv
bnRleHQgc3dpdGNoIGFsd2F5cyBvY2N1ciBhdCB0aGUgZWRnZSBvZiBpbnRlcnZhbDwvc3Bhbj48
c3BhbiBsYW5nPSJFTi1VUyI+LiBPbmx5IGluIHRoaXMgY29uZGl0aW9uLCBjYW4gdGhpcyBpZGVh
IHdvcmsuIDwvc3Bhbj48L3A+PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi
PlNvLCBJIGFtIG5vdCBzdXJlIHdoZXRoZXIgd2UgY2FuIDxzcGFuIHN0eWxlPSJjb2xvcjogcmdi
KDI1NSwgMCwgMCk7ICI+ZmluZCBzdWNoIGEgdGltZSBpbnRlcnZhbDwvc3Bhbj4gdGhhdCBjYW4g
bWVldCB0aGlzIGNvbmRpdGlvbi4gSW4gb3RoZXIgd29yZHMsIHdoZXRoZXIgd2UgY2FuIGZpbmQg
c3VjaCBhIHRpbWUgaW50ZXJ2YWwgdGhhdCA8c3BhbiBjbGFzcz0iIiBpZD0idHJhbl8xXzIiPmVu
c3VyZXM8L3NwYW4+IGFsbCB0aGUgQ1BVIGNvbnRlbnQgc3dpdGNoIG9jY3VyIGF0IHRoZSBlZGdl
IG9mIGludGVydmFsLjwvc3Bhbj48L3A+PC9wcmU+PHByZT48cCBjbGFzcz0iTXNvTm9ybWFsIj48
YnI+PC9wPjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rIHlvdSB2ZXJ5IG11Y2guPC9wPjxwIGNs
YXNzPSJNc29Ob3JtYWwiPkdhdmluPC9wPjwvcHJlPjxwcmU+CiZndDsmbmJzcDstR2VvcmdlCiZn
dDsKJmd0O19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCiZn
dDtYZW4tZGV2ZWwmbmJzcDttYWlsaW5nJm5ic3A7bGlzdAomZ3Q7WGVuLWRldmVsQGxpc3RzLnhl
bnNvdXJjZS5jb20KJmd0O2h0dHA6Ly9saXN0cy54ZW5zb3VyY2UuY29tL3hlbi1kZXZlbAo8L3By
ZT48L2Rpdj48YnI+PGJyPjxzcGFuIHRpdGxlPSJuZXRlYXNlZm9vdGVyIj48c3BhbiBpZD0ibmV0
ZWFzZV9tYWlsX2Zvb3RlciI+PC9zcGFuPjwvc3Bhbj4=
------=_Part_151475_544120518.1324113385869--



--===============3832773490774469895==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============3832773490774469895==--



From xen-devel-bounces@lists.xensource.com Sat Dec 17 09:17:40 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 17 Dec 2011 09:17:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbqNw-0006qm-SD; Sat, 17 Dec 2011 09:16:52 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <gbtux@126.com>) id 1RbqNu-0006qf-Ht
	for xen-devel@lists.xensource.com; Sat, 17 Dec 2011 09:16:51 +0000
X-Env-Sender: gbtux@126.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1324113399!5859922!1
X-Originating-IP: [220.181.15.34]
X-SpamReason: No, hits=1.4 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMjAuMTgxLjE1LjM0ID0+IDY1NzI=\n,sa_preprocessor: 
	QmFkIElQOiAyMjAuMTgxLjE1LjM0ID0+IDY1NzI=\n, BODY_RANDOM_LONG, HTML_40_50,
	HTML_MESSAGE,MIME_BASE64_TEXT
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23074 invoked from network); 17 Dec 2011 09:16:41 -0000
Received: from m15-34.126.com (HELO m15-34.126.com) (220.181.15.34)
	by server-3.tower-174.messagelabs.com with SMTP;
	17 Dec 2011 09:16:41 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=126.com;
	s=s110527; h=Received:Date:From:To:Cc:Message-ID:In-Reply-To:
	References:Subject:MIME-Version:Content-Type; bh=zL8DAN+lROk93Zu
	+s8CzxsASYb7zZA3yukZzyPaRVVw=; b=mUOsZZj40UmyF2LZSonaqL7hD0jD7z1
	GHd1Ha1Q7IslQyUwHpxwCp4aiSDFxeiuU2n9JSLHWEUtQdX3Y0MghthD5nrlYQ4w
	PMzfG7apZgL/kevfNBLDjIog+7Naqo2K4rqbKKUp1ZRpy+lMs0UnkpYSCLTYZi+7
	EJSkW4Be9N9Y=
Received: from gbtux ( [124.16.139.196] ) by ajax-webmail-wmsvr34 (Coremail)
	; Sat, 17 Dec 2011 17:16:25 +0800 (CST)
Date: Sat, 17 Dec 2011 17:16:25 +0800 (CST)
From: gavin  <gbtux@126.com>
To: "George Dunlap" <George.Dunlap@eu.citrix.com>
Message-ID: <35e4701f.ca5a.1344b4ed98e.Coremail.gbtux@126.com>
In-Reply-To: <CAFLBxZaBiwEvz-dgPzgBQQTj2xMi8m+QnZ3M+uoqw4AKmb0ZvA@mail.gmail.com>
References: <CAFLBxZaBiwEvz-dgPzgBQQTj2xMi8m+QnZ3M+uoqw4AKmb0ZvA@mail.gmail.com>
	<26c93838.3b3fb.13445de0e67.Coremail.gbtux@126.com>
	<CAFLBxZYM-8vEc5Egmv+iXqMDUE_UJcgHbwr7=71H-kFowTzXWA@mail.gmail.com>
	<676b608e.2fb26.13447553671.Coremail.gbtux@126.com>
MIME-Version: 1.0
X-Originating-IP: [124.16.139.196]
X-Priority: 3
X-Mailer: Coremail Webmail Server Version SP_ntes V3.5 build
	111202(16086.4213.4207) Copyright (c) 2002-2011 www.mailtech.cn 126com
X-CM-CTRLDATA: HR/Dk2Zvb3Rlcl9odG09NjIyMDo4MQ==
X-CM-TRANSID: IsqowEApCEXsXexOEDIcAA--.3273W
X-CM-SenderInfo: pjew35a6rslhhfrp/1tbiHQ8ZnEihT4TjtAAAsi
X-Coremail-Antispam: 1U5529EdanIXcx71UUUUU7vcSsGvfC2KfnxnUU==
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] A question on the credit scheduler
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3832773490774469895=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============3832773490774469895==
Content-Type: multipart/alternative; 
	boundary="----=_Part_151475_544120518.1324113385869"

------=_Part_151475_544120518.1324113385869
Content-Type: text/plain; charset=GBK
Content-Transfer-Encoding: base64

CkF0IDIwMTEtMTItMTYgMjM6NTg6MjYsIkdlb3JnZSBEdW5sYXAiIDxHZW9yZ2UuRHVubGFwQGV1
LmNpdHJpeC5jb20+IHdyb3RlOgo+MjAxMS8xMi8xNiBnYXZpbiA8Z2J0dXhAMTI2LmNvbT46Cj4+
IEF0IDIwMTEtMTItMTYgMTk6MDQ6MTksIkdlb3JnZSBEdW5sYXAiIDxHZW9yZ2UuRHVubGFwQGV1
LmNpdHJpeC5jb20+IHdyb3RlOgo+Pgo+Pj4yMDExLzEyLzE2IHpoaWthaSA8Z2J0dXhAMTI2LmNv
bT46Cj4+Pj4gSGkgQWxsLAo+Pj4+Cj4+Pj4gSW4gdGhlIGNyZWRpdCBzY2hlZHVsZXIsIHRoZSBz
Y2hlZHVsaW5nIGRlY2lzaW9uIGZ1bmN0aW9uIGNzY2hlZF9zY2hlZHVsZSgpCj4+Pj4gaXMgY2Fs
bGVkIGluIHRoZSBzY2hlZHVsZSBmdW5jdGlvbiBpbiBzY2hlZHVsZXIuYywgc3VjaCBhcyB0aGUg
Zm9sbG93aW5nLgo+Pj4+IG5leHRfc2xpY2UgPSBzY2hlZC0+ZG9fc2NoZWR1bGUoc2NoZWQsIG5v
dywgdGFza2xldF93b3JrX3NjaGVkdWxlZCk7Cj4+Pj4KPj4+PiBCdXQsIGhvdyBvZnRlbiB0aGUg
Y3NjaGVkX3NjaGVkdWxlKCkgaXMgY2FsbGVkIGFuZCB0byBydW4/IERvZXMgdGhpcwo+Pj4+IGZy
ZXF1ZW5jeSBoYXZlIHNvbWV0aGluZyB0byBkbyB3aXRoIHRoZSBzbGljZSBvZiBjcmVkaXQgc2No
ZWR1bGVyIHRoYXQgaXMKPj4+PiAzMG1zPwo+Pj4KPj4+VGhlIHNjaGVkdWxlciBydW5zIHdoZW5l
dmVyIHRoZSBTQ0hFRFVMRV9TT0ZUSVJRIGlzIHJhaXNlZC4gIElmIHlvdQo+Pj5ncmVwIHRocm91
Z2ggdGhlIHNvdXJjZSBjb2RlIGZybyB0aGF0IHN0cmluZywgeW91IGNhbiBmaW5kIGFsbCB0aGUK
Pj4+cGxhY2VzIHdoZXJlIGl0J3MgcmFpc2VkLgo+Pj4KPj4+U29tZSBleGFtcGxlcyBpbmNsdWRl
Ogo+Pj4qIFdoZW4gdGhlIDMwbXMgdGltZXNsaWNlIGlzIGZpbmlzaGVkCj4+PiogV2hlbiBhIHNs
ZWVwaW5nIHZjcHUgb2YgaGlnaGVyIHByaW9yaXR5IHRoYW4gd2hhdCdzIGN1cnJlbnRseSBydW5u
aW5nIHdha2VzIHVwCj4+PiogV2hlbiBhIHZjcHUgYmxvY2tzCj4+PiogV2hlbiBhIHZjcHUgaXMg
bWlncmF0ZWQgZnJvbSBvbmUgY3B1IHRvIGFub3RoZXIKPj4+Cj4+PjMwbXMgaXMgYWN0dWFsbHkg
YSBwcmV0dHkgbG9uZyB0aW1lOyBpbiB0eXBpY2FsIHdvcmtsb2FkcywgdmNwdXMgYmxvY2sKPj4+
b3IgYXJlIHByZWVtcHRlZCBieSBvdGhlciB3YWtpbmcgdmNwdXMgd2l0aG91dCB1c2luZyB1cCB0
aGVpciBmdWxsCj4+PnRpbWVzbGljZS4KPj4KPj4gVGhhbmsgeW91IHZlcnkgbXVjaCBmb3IgeW91
ciByZXBseS4KPj4KPj4gU28sIHRoZSB2Y3B1IGlzIHZlcnkgbGlrZWx5IHRvIGJlIHByZWVtcHRl
ZCB3aGVuZXZlciB0aGUgU0NIRURVTEVfU09GVElSUSBpcwo+PiByYWlzZWQuCj4KPkl0IGRlcGVu
ZHM7IGlmIHlvdSBoYXZlIGEgY3B1LWJ1cm5pbmcgdmNwdSBydW5uaW5nIG9uIGEgY3B1IGFsbCBi
eQo+aXRzZWxmLCB0aGVuIGFmdGVyIGl0cyAzMG1zIHRpbWVzbGljZSwgWGVuIHdpbGwgaGF2ZSBu
byBvbmUgZWxzZSB0bwo+cnVuLCBhbmQgc28gd2lsbCBsZXQgaXQgcnVuIGFnYWluLgo+Cj5CdXQg
eWVzLCBpZiB0aGVyZSBhcmUgb3RoZXIgdmNwdXMgb24gdGhlIHJ1bnF1ZXVlLCBvciB0aGUgaG9z
dCBpcwo+bW9kZXJhdGVseSBidXN5LCBpdCdzIGxpa2VseSB0aGF0IFNDSEVEVUxFX1NPRlRJUlEg
d2lsbCBjYXVzZSBhCj5jb250ZXh0LXN3aXRjaC4KPgo+PiBBbmQgd2UgY2Fubm90IGZpbmQgYSBz
bWFsbCB0aW1lc2xpY2UsIHN1Y2ggYXMgYShtcyksIHdoaWNoIG1ha2VzIHRoZQo+PiB0aW1lIGFu
eSB2Y3B1IHNwZW5kaW5nIG9uIHJ1bm5pbmcgcGhhc2UgaXMgayphKG1zKSwgayBpcyBpbnRlZ2Vy
IGhlcmUuIFRoZXJlCj4+IGlzIG5vIHN1Y2ggYSBzbWFsbCB0aW1lc2xpY2UuIElzIGl0IHJpZ2h0
Pwo+Cj5JJ20gc29ycnksIEkgZG9uJ3QgcmVhbGx5IHVuZGVyc3RhbmQgeW91ciBxdWVzdGlvbi4g
IFBlcmhhcHMgaWYgeW91Cj50b2xkIG1lIHdoYXQgeW91J3JlIHRyeWluZyB0byBhY2NvbXBsaXNo
PwoKSSB0cnkgdG8gZGVzY3JpYmUgbXkgaWRlYSBhcyB0aGUgZm9sbG93aW5nIGNsZWFybHkuIEJ1
dCBJIHJlYWxseSBkb24ndCBrbm93IGlmIGl0IHdpbGwgd29yay4gUGxlYXNlIGdpdmUgbWUgc29t
ZSBhZHZpY2UgaWYgcG9zc2libGUuCgpBY2NvcmRpbmcgdG8gdGhlIGNyZWRpdCBzY2hlZHVsZXIg
aW4gWGVuLCBhIHZDUFUgY2FuIHJ1biBhIDMwbXMgdGltZXNsaWNlIHdoZW4gaXQgaXMgc2NoZWR1
bGVkIG9uIHRoZSBwaHlzaWNhbCBDUFUuIEFuZCwgYSB2Q1BVIHdpdGggdGhlIEJPT1NUIHByaW9y
aXR5IHdpbGwgcHJlZW1wdCB0aGUgcnVubmluZyBvbmUgYW5kIHJ1biBhZGRpdGlvbmFsIDEwbXMu
IFNvLCB3aGF0IEkgdGhpbmsgaXMgaWYgd2UgbW9uaXRvciB0aGUgcGh5c2ljYWwgQ1BVIGV2ZXJ5
IDEwbXMgYW5kIHdlIGNhbiBnZXQgdGhlIG1hcHBpbmcgaW5mb3JtYXRpb24gb2YgYSBwaHlzaWNh
bCBDUFUgYW5kIGEgdkNQVS4gQW5kIGFsc28sIHdlIGNhbiBnZXQgdGhlIHVuLW1hcHBpbmcgaW5m
b3JtYXRpb24gdGhhdCBhIHBoeXNpY2FsIENQVSBpc26hr3QgbWFwcGVkIHRvIGFueSB2Q1BVLiBU
aHVzLCB3ZSBjYW4gZ2V0IHRoZSBDUFUgdXNhZ2UgYnkgY2FsY3VsYXRpbmcgdGhlIHByb3BvcnRp
b24gb2YgdGhlIG1hcHBpbmcgaW5mb3JtYXRpb24gdG8gdGhlIHRvdGFsIHRpbWUgd2hlbiB3ZSBt
b25pdG9yZWQuIAoKRm9yIGV4YW1wbGUsIGlmIHdlIG1vbml0b3IgdGhlIHBoeXNpY2FsIENQVXMg
ZXZlcnkgMTBtcyBhbmQgd2UgY2FuIGdldCAxMDAgcGFpcnMgb2YgcENQVSBhbmQgdkNQVSBpbiBh
IHNlY29uZCwgc3VjaCBhcyAocENQVV9pZCwgdkNQVV9pZCkuIElmIHRoZXJlIGlzIDYwIG1hcHBp
bmcgcGFpcnMgdGhhdCB0aGUgcENQVSBpcyBtYXBwZWQgdG8gYSB2YWxpZCB2UENVLCBhbmQgNDAg
dW4tbWFwcGluZyBwYWlycyB0aGF0IHdlIGNhbm5vdCBmaW5kIHRoZSBwQ1BVIHRvIGJlIG1hcHBl
ZCBhIHZhbGlkIHZDUFUuIFNvLCB3ZSBjYW4gZ2V0IHRoZSB1c2FnZSBvZiB0aGUgcGh5c2ljYWwg
Q1BVcyB0aGF0IGlzIDYwJS4KCkhlcmUsIHdlIG1vbml0b3IgdGhlIHBoeXNpY2FsIENQVXMgZXZl
cnkgMTBtcy4gV2UgYWxzbyBjYW4gbW9uaXRvciB0aGVtIG9uY2UgbGVzcyB0aGFuIHRoZSAxMG1z
IGludGVydmFsLCBzdWNoIGFzIDFtcyBpbnRlcnZhbC4gV2hhdGV2ZXIgaW50ZXJ2YWwgd2UgY2hv
b3NlLCB3ZSBtdXN0IG1ha2Ugc3VyZSBubyBDUFUgY29udGVudCBzd2l0Y2ggaW4gdGhlIGludGVy
dmFsIG9yIHRoZSBjb250ZXh0IHN3aXRjaCBhbHdheXMgb2NjdXIgYXQgdGhlIGVkZ2Ugb2YgaW50
ZXJ2YWwuIE9ubHkgaW4gdGhpcyBjb25kaXRpb24sIGNhbiB0aGlzIGlkZWEgd29yay4gCgpTbywg
SSBhbSBub3Qgc3VyZSB3aGV0aGVyIHdlIGNhbiBmaW5kIHN1Y2ggYSB0aW1lIGludGVydmFsIHRo
YXQgY2FuIG1lZXQgdGhpcyBjb25kaXRpb24uIEluIG90aGVyIHdvcmRzLCB3aGV0aGVyIHdlIGNh
biBmaW5kIHN1Y2ggYSB0aW1lIGludGVydmFsIHRoYXQgZW5zdXJlcyBhbGwgdGhlIENQVSBjb250
ZW50IHN3aXRjaCBvY2N1ciBhdCB0aGUgZWRnZSBvZiBpbnRlcnZhbC4KCgoKClRoYW5rIHlvdSB2
ZXJ5IG11Y2guCgpHYXZpbgoKCj4gLUdlb3JnZQo+Cj5fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fXwo+WGVuLWRldmVsIG1haWxpbmcgbGlzdAo+WGVuLWRldmVs
QGxpc3RzLnhlbnNvdXJjZS5jb20KPmh0dHA6Ly9saXN0cy54ZW5zb3VyY2UuY29tL3hlbi1kZXZl
bAo=
------=_Part_151475_544120518.1324113385869
Content-Type: text/html; charset=GBK
Content-Transfer-Encoding: base64

PGRpdiBzdHlsZT0ibGluZS1oZWlnaHQ6MS43O2NvbG9yOiMwMDAwMDA7Zm9udC1zaXplOjE0cHg7
Zm9udC1mYW1pbHk6YXJpYWwiPjxwcmU+PGJyPkF0Jm5ic3A7MjAxMS0xMi0xNiZuYnNwOzIzOjU4
OjI2LCJHZW9yZ2UmbmJzcDtEdW5sYXAiJm5ic3A7Jmx0O0dlb3JnZS5EdW5sYXBAZXUuY2l0cml4
LmNvbSZndDsmbmJzcDt3cm90ZToKJmd0OzIwMTEvMTIvMTYmbmJzcDtnYXZpbiZuYnNwOyZsdDtn
YnR1eEAxMjYuY29tJmd0OzoKJmd0OyZndDsmbmJzcDtBdCZuYnNwOzIwMTEtMTItMTYmbmJzcDsx
OTowNDoxOSwiR2VvcmdlJm5ic3A7RHVubGFwIiZuYnNwOyZsdDtHZW9yZ2UuRHVubGFwQGV1LmNp
dHJpeC5jb20mZ3Q7Jm5ic3A7d3JvdGU6CiZndDsmZ3Q7CiZndDsmZ3Q7Jmd0OzIwMTEvMTIvMTYm
bmJzcDt6aGlrYWkmbmJzcDsmbHQ7Z2J0dXhAMTI2LmNvbSZndDs6CiZndDsmZ3Q7Jmd0OyZndDsm
bmJzcDtIaSZuYnNwO0FsbCwKJmd0OyZndDsmZ3Q7Jmd0OwomZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7
SW4mbmJzcDt0aGUmbmJzcDtjcmVkaXQmbmJzcDtzY2hlZHVsZXIsJm5ic3A7dGhlJm5ic3A7c2No
ZWR1bGluZyZuYnNwO2RlY2lzaW9uJm5ic3A7ZnVuY3Rpb24mbmJzcDtjc2NoZWRfc2NoZWR1bGUo
KQomZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7aXMmbmJzcDtjYWxsZWQmbmJzcDtpbiZuYnNwO3RoZSZu
YnNwO3NjaGVkdWxlJm5ic3A7ZnVuY3Rpb24mbmJzcDtpbiZuYnNwO3NjaGVkdWxlci5jLCZuYnNw
O3N1Y2gmbmJzcDthcyZuYnNwO3RoZSZuYnNwO2ZvbGxvd2luZy4KJmd0OyZndDsmZ3Q7Jmd0OyZu
YnNwO25leHRfc2xpY2UmbmJzcDs9Jm5ic3A7c2NoZWQtJmd0O2RvX3NjaGVkdWxlKHNjaGVkLCZu
YnNwO25vdywmbmJzcDt0YXNrbGV0X3dvcmtfc2NoZWR1bGVkKTsKJmd0OyZndDsmZ3Q7Jmd0Owom
Z3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7QnV0LCZuYnNwO2hvdyZuYnNwO29mdGVuJm5ic3A7dGhlJm5i
c3A7Y3NjaGVkX3NjaGVkdWxlKCkmbmJzcDtpcyZuYnNwO2NhbGxlZCZuYnNwO2FuZCZuYnNwO3Rv
Jm5ic3A7cnVuPyZuYnNwO0RvZXMmbmJzcDt0aGlzCiZndDsmZ3Q7Jmd0OyZndDsmbmJzcDtmcmVx
dWVuY3kmbmJzcDtoYXZlJm5ic3A7c29tZXRoaW5nJm5ic3A7dG8mbmJzcDtkbyZuYnNwO3dpdGgm
bmJzcDt0aGUmbmJzcDtzbGljZSZuYnNwO29mJm5ic3A7Y3JlZGl0Jm5ic3A7c2NoZWR1bGVyJm5i
c3A7dGhhdCZuYnNwO2lzCiZndDsmZ3Q7Jmd0OyZndDsmbmJzcDszMG1zPwomZ3Q7Jmd0OyZndDsK
Jmd0OyZndDsmZ3Q7VGhlJm5ic3A7c2NoZWR1bGVyJm5ic3A7cnVucyZuYnNwO3doZW5ldmVyJm5i
c3A7dGhlJm5ic3A7U0NIRURVTEVfU09GVElSUSZuYnNwO2lzJm5ic3A7cmFpc2VkLiZuYnNwOyZu
YnNwO0lmJm5ic3A7eW91CiZndDsmZ3Q7Jmd0O2dyZXAmbmJzcDt0aHJvdWdoJm5ic3A7dGhlJm5i
c3A7c291cmNlJm5ic3A7Y29kZSZuYnNwO2ZybyZuYnNwO3RoYXQmbmJzcDtzdHJpbmcsJm5ic3A7
eW91Jm5ic3A7Y2FuJm5ic3A7ZmluZCZuYnNwO2FsbCZuYnNwO3RoZQomZ3Q7Jmd0OyZndDtwbGFj
ZXMmbmJzcDt3aGVyZSZuYnNwO2l0J3MmbmJzcDtyYWlzZWQuCiZndDsmZ3Q7Jmd0OwomZ3Q7Jmd0
OyZndDtTb21lJm5ic3A7ZXhhbXBsZXMmbmJzcDtpbmNsdWRlOgomZ3Q7Jmd0OyZndDsqJm5ic3A7
V2hlbiZuYnNwO3RoZSZuYnNwOzMwbXMmbmJzcDt0aW1lc2xpY2UmbmJzcDtpcyZuYnNwO2Zpbmlz
aGVkCiZndDsmZ3Q7Jmd0OyombmJzcDtXaGVuJm5ic3A7YSZuYnNwO3NsZWVwaW5nJm5ic3A7dmNw
dSZuYnNwO29mJm5ic3A7aGlnaGVyJm5ic3A7cHJpb3JpdHkmbmJzcDt0aGFuJm5ic3A7d2hhdCdz
Jm5ic3A7Y3VycmVudGx5Jm5ic3A7cnVubmluZyZuYnNwO3dha2VzJm5ic3A7dXAKJmd0OyZndDsm
Z3Q7KiZuYnNwO1doZW4mbmJzcDthJm5ic3A7dmNwdSZuYnNwO2Jsb2NrcwomZ3Q7Jmd0OyZndDsq
Jm5ic3A7V2hlbiZuYnNwO2EmbmJzcDt2Y3B1Jm5ic3A7aXMmbmJzcDttaWdyYXRlZCZuYnNwO2Zy
b20mbmJzcDtvbmUmbmJzcDtjcHUmbmJzcDt0byZuYnNwO2Fub3RoZXIKJmd0OyZndDsmZ3Q7CiZn
dDsmZ3Q7Jmd0OzMwbXMmbmJzcDtpcyZuYnNwO2FjdHVhbGx5Jm5ic3A7YSZuYnNwO3ByZXR0eSZu
YnNwO2xvbmcmbmJzcDt0aW1lOyZuYnNwO2luJm5ic3A7dHlwaWNhbCZuYnNwO3dvcmtsb2Fkcywm
bmJzcDt2Y3B1cyZuYnNwO2Jsb2NrCiZndDsmZ3Q7Jmd0O29yJm5ic3A7YXJlJm5ic3A7cHJlZW1w
dGVkJm5ic3A7YnkmbmJzcDtvdGhlciZuYnNwO3dha2luZyZuYnNwO3ZjcHVzJm5ic3A7d2l0aG91
dCZuYnNwO3VzaW5nJm5ic3A7dXAmbmJzcDt0aGVpciZuYnNwO2Z1bGwKJmd0OyZndDsmZ3Q7dGlt
ZXNsaWNlLgomZ3Q7Jmd0OwomZ3Q7Jmd0OyZuYnNwO1RoYW5rJm5ic3A7eW91Jm5ic3A7dmVyeSZu
YnNwO211Y2gmbmJzcDtmb3ImbmJzcDt5b3VyJm5ic3A7cmVwbHkuCiZndDsmZ3Q7CiZndDsmZ3Q7
Jm5ic3A7U28sJm5ic3A7dGhlJm5ic3A7dmNwdSZuYnNwO2lzJm5ic3A7dmVyeSZuYnNwO2xpa2Vs
eSZuYnNwO3RvJm5ic3A7YmUmbmJzcDtwcmVlbXB0ZWQmbmJzcDt3aGVuZXZlciZuYnNwO3RoZSZu
YnNwO1NDSEVEVUxFX1NPRlRJUlEmbmJzcDtpcwomZ3Q7Jmd0OyZuYnNwO3JhaXNlZC4KJmd0Owom
Z3Q7SXQmbmJzcDtkZXBlbmRzOyZuYnNwO2lmJm5ic3A7eW91Jm5ic3A7aGF2ZSZuYnNwO2EmbmJz
cDtjcHUtYnVybmluZyZuYnNwO3ZjcHUmbmJzcDtydW5uaW5nJm5ic3A7b24mbmJzcDthJm5ic3A7
Y3B1Jm5ic3A7YWxsJm5ic3A7YnkKJmd0O2l0c2VsZiwmbmJzcDt0aGVuJm5ic3A7YWZ0ZXImbmJz
cDtpdHMmbmJzcDszMG1zJm5ic3A7dGltZXNsaWNlLCZuYnNwO1hlbiZuYnNwO3dpbGwmbmJzcDto
YXZlJm5ic3A7bm8mbmJzcDtvbmUmbmJzcDtlbHNlJm5ic3A7dG8KJmd0O3J1biwmbmJzcDthbmQm
bmJzcDtzbyZuYnNwO3dpbGwmbmJzcDtsZXQmbmJzcDtpdCZuYnNwO3J1biZuYnNwO2FnYWluLgom
Z3Q7CiZndDtCdXQmbmJzcDt5ZXMsJm5ic3A7aWYmbmJzcDt0aGVyZSZuYnNwO2FyZSZuYnNwO290
aGVyJm5ic3A7dmNwdXMmbmJzcDtvbiZuYnNwO3RoZSZuYnNwO3J1bnF1ZXVlLCZuYnNwO29yJm5i
c3A7dGhlJm5ic3A7aG9zdCZuYnNwO2lzCiZndDttb2RlcmF0ZWx5Jm5ic3A7YnVzeSwmbmJzcDtp
dCdzJm5ic3A7bGlrZWx5Jm5ic3A7dGhhdCZuYnNwO1NDSEVEVUxFX1NPRlRJUlEmbmJzcDt3aWxs
Jm5ic3A7Y2F1c2UmbmJzcDthCiZndDtjb250ZXh0LXN3aXRjaC4KJmd0OwomZ3Q7Jmd0OyZuYnNw
O0FuZCZuYnNwO3dlJm5ic3A7Y2Fubm90Jm5ic3A7ZmluZCZuYnNwO2EmbmJzcDtzbWFsbCZuYnNw
O3RpbWVzbGljZSwmbmJzcDtzdWNoJm5ic3A7YXMmbmJzcDthKG1zKSwmbmJzcDt3aGljaCZuYnNw
O21ha2VzJm5ic3A7dGhlCiZndDsmZ3Q7Jm5ic3A7dGltZSZuYnNwO2FueSZuYnNwO3ZjcHUmbmJz
cDtzcGVuZGluZyZuYnNwO29uJm5ic3A7cnVubmluZyZuYnNwO3BoYXNlJm5ic3A7aXMmbmJzcDtr
KmEobXMpLCZuYnNwO2smbmJzcDtpcyZuYnNwO2ludGVnZXImbmJzcDtoZXJlLiZuYnNwO1RoZXJl
CiZndDsmZ3Q7Jm5ic3A7aXMmbmJzcDtubyZuYnNwO3N1Y2gmbmJzcDthJm5ic3A7c21hbGwmbmJz
cDt0aW1lc2xpY2UuJm5ic3A7SXMmbmJzcDtpdCZuYnNwO3JpZ2h0PwomZ3Q7CiZndDtJJ20mbmJz
cDtzb3JyeSwmbmJzcDtJJm5ic3A7ZG9uJ3QmbmJzcDtyZWFsbHkmbmJzcDt1bmRlcnN0YW5kJm5i
c3A7eW91ciZuYnNwO3F1ZXN0aW9uLiZuYnNwOyZuYnNwO1BlcmhhcHMmbmJzcDtpZiZuYnNwO3lv
dQomZ3Q7dG9sZCZuYnNwO21lJm5ic3A7d2hhdCZuYnNwO3lvdSdyZSZuYnNwO3RyeWluZyZuYnNw
O3RvJm5ic3A7YWNjb21wbGlzaD88L3ByZT48cHJlPjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IGxhbmc9IkVOLVVTIj5JIHRyeSB0byBkZXNjcmliZSBteSBpZGVhIGFzIHRoZSBmb2xsb3dpbmcg
Y2xlYXJseS4gQnV0IEkgcmVhbGx5IGRvbid0IGtub3cgaWYgaXQgd2lsbCB3b3JrLiBQbGVhc2Ug
Z2l2ZSBtZSBzb21lIGFkdmljZSBpZiBwb3NzaWJsZS48L3NwYW4+PC9wPjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5BY2NvcmRpbmcgdG8gdGhlIGNyZWRpdCBzY2hlZHVs
ZXIgaW4gWGVuLCBhIHZDUFUgY2FuIHJ1biBhIDMwbXMgdGltZXNsaWNlIHdoZW4gaXQgaXMgc2No
ZWR1bGVkIG9uIHRoZSBwaHlzaWNhbCBDUFUuIEFuZCwgYSB2Q1BVIHdpdGggdGhlIEJPT1NUIHBy
aW9yaXR5IHdpbGwgcHJlZW1wdCB0aGUgcnVubmluZyBvbmUgYW5kIHJ1biBhZGRpdGlvbmFsIDEw
bXMuIFNvLCB3aGF0IEkgdGhpbmsgaXMgaWYgd2UgbW9uaXRvciB0aGUgcGh5c2ljYWwgQ1BVIGV2
ZXJ5IDEwbXMgYW5kIHdlIGNhbiBnZXQgdGhlIG1hcHBpbmcgaW5mb3JtYXRpb24gb2YgYSBwaHlz
aWNhbCBDUFUgYW5kIGEgdkNQVS4gQW5kIGFsc28sIHdlIGNhbiBnZXQgdGhlIHVuLW1hcHBpbmcg
aW5mb3JtYXRpb24gdGhhdCBhIHBoeXNpY2FsIENQVSBpc26hr3QgbWFwcGVkIHRvIGFueSB2Q1BV
LiBUaHVzLCB3ZSBjYW4gZ2V0IHRoZSBDUFUgdXNhZ2UgYnkgY2FsY3VsYXRpbmcgdGhlIHByb3Bv
cnRpb24gb2YgdGhlIG1hcHBpbmcgaW5mb3JtYXRpb24gdG8gdGhlIHRvdGFsIHRpbWUgd2hlbiB3
ZSBtb25pdG9yZWQuIDwvc3Bhbj48L3A+PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i
RU4tVVMiPkZvciBleGFtcGxlLCBpZiB3ZSBtb25pdG9yIHRoZSBwaHlzaWNhbCBDUFVzIGV2ZXJ5
IDEwbXMgYW5kIHdlIGNhbiBnZXQgMTAwIHBhaXJzIG9mIHBDUFUgYW5kIHZDUFUgaW4gYSBzZWNv
bmQsIHN1Y2ggYXMgKHBDUFVfaWQsIHZDUFVfaWQpLiBJZiB0aGVyZSBpcyA2MCBtYXBwaW5nIHBh
aXJzIHRoYXQgdGhlIHBDUFUgaXMgbWFwcGVkIHRvIGEgdmFsaWQgdlBDVSwgYW5kIDQwIHVuLW1h
cHBpbmcgcGFpcnMgdGhhdCB3ZSBjYW5ub3QgZmluZCB0aGUgcENQVSB0byBiZSBtYXBwZWQgYSB2
YWxpZCB2Q1BVLiBTbywgd2UgY2FuIGdldCB0aGUgdXNhZ2Ugb2YgdGhlIHBoeXNpY2FsIENQVXMg
dGhhdCBpcyA2MCUuPC9zcGFuPjwvcD48cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF
Ti1VUyI+SGVyZSwgd2UgbW9uaXRvciB0aGUgcGh5c2ljYWwgQ1BVcyBldmVyeSAxMG1zLiBXZSBh
bHNvIGNhbiBtb25pdG9yIHRoZW0gb25jZSBsZXNzIHRoYW4gdGhlIDEwbXMgaW50ZXJ2YWwsIHN1
Y2ggYXMgMW1zIGludGVydmFsLiBXaGF0ZXZlciBpbnRlcnZhbCB3ZSBjaG9vc2UsIHdlIG11c3Qg
bWFrZSBzdXJlIDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOnJlZCI+bm8g
Q1BVIGNvbnRlbnQgc3dpdGNoIGluIHRoZSBpbnRlcnZhbDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1V
UyI+IG9yIHRoZSA8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpyZWQiPmNv
bnRleHQgc3dpdGNoIGFsd2F5cyBvY2N1ciBhdCB0aGUgZWRnZSBvZiBpbnRlcnZhbDwvc3Bhbj48
c3BhbiBsYW5nPSJFTi1VUyI+LiBPbmx5IGluIHRoaXMgY29uZGl0aW9uLCBjYW4gdGhpcyBpZGVh
IHdvcmsuIDwvc3Bhbj48L3A+PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi
PlNvLCBJIGFtIG5vdCBzdXJlIHdoZXRoZXIgd2UgY2FuIDxzcGFuIHN0eWxlPSJjb2xvcjogcmdi
KDI1NSwgMCwgMCk7ICI+ZmluZCBzdWNoIGEgdGltZSBpbnRlcnZhbDwvc3Bhbj4gdGhhdCBjYW4g
bWVldCB0aGlzIGNvbmRpdGlvbi4gSW4gb3RoZXIgd29yZHMsIHdoZXRoZXIgd2UgY2FuIGZpbmQg
c3VjaCBhIHRpbWUgaW50ZXJ2YWwgdGhhdCA8c3BhbiBjbGFzcz0iIiBpZD0idHJhbl8xXzIiPmVu
c3VyZXM8L3NwYW4+IGFsbCB0aGUgQ1BVIGNvbnRlbnQgc3dpdGNoIG9jY3VyIGF0IHRoZSBlZGdl
IG9mIGludGVydmFsLjwvc3Bhbj48L3A+PC9wcmU+PHByZT48cCBjbGFzcz0iTXNvTm9ybWFsIj48
YnI+PC9wPjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rIHlvdSB2ZXJ5IG11Y2guPC9wPjxwIGNs
YXNzPSJNc29Ob3JtYWwiPkdhdmluPC9wPjwvcHJlPjxwcmU+CiZndDsmbmJzcDstR2VvcmdlCiZn
dDsKJmd0O19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCiZn
dDtYZW4tZGV2ZWwmbmJzcDttYWlsaW5nJm5ic3A7bGlzdAomZ3Q7WGVuLWRldmVsQGxpc3RzLnhl
bnNvdXJjZS5jb20KJmd0O2h0dHA6Ly9saXN0cy54ZW5zb3VyY2UuY29tL3hlbi1kZXZlbAo8L3By
ZT48L2Rpdj48YnI+PGJyPjxzcGFuIHRpdGxlPSJuZXRlYXNlZm9vdGVyIj48c3BhbiBpZD0ibmV0
ZWFzZV9tYWlsX2Zvb3RlciI+PC9zcGFuPjwvc3Bhbj4=
------=_Part_151475_544120518.1324113385869--



--===============3832773490774469895==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============3832773490774469895==--



From xen-devel-bounces@lists.xensource.com Sat Dec 17 10:35:39 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 17 Dec 2011 10:35:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbrbS-0007of-Mc; Sat, 17 Dec 2011 10:34:54 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pasik@iki.fi>)
	id 1RbrbR-0007oS-Ax; Sat, 17 Dec 2011 10:34:53 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-5.tower-182.messagelabs.com!1324118086!7667481!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiAzODc4ODM=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1099 invoked from network); 17 Dec 2011 10:34:47 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-5.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Dec 2011 10:34:47 -0000
X-Originating-Ip: [194.89.68.22]
Received: from ydin.reaktio.net (reaktio.net [194.89.68.22])
	by smtp.tele.fi (Postfix) with ESMTP id 6019D19E8;
	Sat, 17 Dec 2011 12:34:45 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 12A4C20056; Sat, 17 Dec 2011 12:34:45 +0200 (EET)
Date: Sat, 17 Dec 2011 12:34:44 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: xen-devel.GarveyPatrickD@OrdinaryAmerican.net
Message-ID: <20111217103444.GB12984@reaktio.net>
References: <CACm5R6RY6oxN5KT_VjjvPwsbczBMhficjG0WQBrxffcU0jOuQA@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CACm5R6RY6oxN5KT_VjjvPwsbczBMhficjG0WQBrxffcU0jOuQA@mail.gmail.com>
User-Agent: Mutt/1.5.18 (2008-05-17)
Cc: xen-devel@lists.xensource.com, xen-api@lists.xensource.com
Subject: Re: [Xen-devel] OCaml Tutorial
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Dec 16, 2011 at 03:38:32PM -0800, xen-devel.GarveyPatrickD@OrdinaryAmerican.net wrote:
> It appears the OCaml Tutorial < www.ocaml-tutorial.org > referenced in
> our XAPI Developer Guide wiki article <
> http://wiki.xen.org/wiki/XAPI_Developer_Guide > is not reliably
> accessible.  Can one of our experienced OCaml programmers suggest an
> alternative that provides a sufficient tutorial for Xen users of
> OCaml?  Is < http://mirror.ocamlcore.org/ocaml-tutorial.org/ >
> sufficient?
> 

I added xen-api mailinglist to the CC list..

-- Pasi


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Dec 17 10:35:39 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 17 Dec 2011 10:35:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbrbS-0007of-Mc; Sat, 17 Dec 2011 10:34:54 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pasik@iki.fi>)
	id 1RbrbR-0007oS-Ax; Sat, 17 Dec 2011 10:34:53 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-5.tower-182.messagelabs.com!1324118086!7667481!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiAzODc4ODM=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1099 invoked from network); 17 Dec 2011 10:34:47 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-5.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Dec 2011 10:34:47 -0000
X-Originating-Ip: [194.89.68.22]
Received: from ydin.reaktio.net (reaktio.net [194.89.68.22])
	by smtp.tele.fi (Postfix) with ESMTP id 6019D19E8;
	Sat, 17 Dec 2011 12:34:45 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 12A4C20056; Sat, 17 Dec 2011 12:34:45 +0200 (EET)
Date: Sat, 17 Dec 2011 12:34:44 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: xen-devel.GarveyPatrickD@OrdinaryAmerican.net
Message-ID: <20111217103444.GB12984@reaktio.net>
References: <CACm5R6RY6oxN5KT_VjjvPwsbczBMhficjG0WQBrxffcU0jOuQA@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CACm5R6RY6oxN5KT_VjjvPwsbczBMhficjG0WQBrxffcU0jOuQA@mail.gmail.com>
User-Agent: Mutt/1.5.18 (2008-05-17)
Cc: xen-devel@lists.xensource.com, xen-api@lists.xensource.com
Subject: Re: [Xen-devel] OCaml Tutorial
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Dec 16, 2011 at 03:38:32PM -0800, xen-devel.GarveyPatrickD@OrdinaryAmerican.net wrote:
> It appears the OCaml Tutorial < www.ocaml-tutorial.org > referenced in
> our XAPI Developer Guide wiki article <
> http://wiki.xen.org/wiki/XAPI_Developer_Guide > is not reliably
> accessible.  Can one of our experienced OCaml programmers suggest an
> alternative that provides a sufficient tutorial for Xen users of
> OCaml?  Is < http://mirror.ocamlcore.org/ocaml-tutorial.org/ >
> sufficient?
> 

I added xen-api mailinglist to the CC list..

-- Pasi


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Dec 17 11:34:59 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 17 Dec 2011 11:34:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbsWq-0008MP-F8; Sat, 17 Dec 2011 11:34:12 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <quartex73@gmail.com>) id 1RbsWo-0008MK-IK
	for xen-devel@lists.xensource.com; Sat, 17 Dec 2011 11:34:10 +0000
X-Env-Sender: quartex73@gmail.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1324121643!7763505!1
X-Originating-IP: [209.85.160.171]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26016 invoked from network); 17 Dec 2011 11:34:04 -0000
Received: from mail-gy0-f171.google.com (HELO mail-gy0-f171.google.com)
	(209.85.160.171)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Dec 2011 11:34:04 -0000
Received: by ghy10 with SMTP id 10so38363866ghy.30
	for <xen-devel@lists.xensource.com>;
	Sat, 17 Dec 2011 03:34:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=8hyGtcDLrb8F5aBQqFi7JxfhrJcMkEvwLOj4WXJO5Ak=;
	b=XMeLLn/yGqppV36f/iB/S87u+SYxBGqwNj65UU6Qxu2rNWvpjDoE3rJ7AyH70EkBZx
	QvP3zsj59ibTYRkFddqa9RnMBTeDXEZcBG1HoMSr5DRSQ/m6bJlVmXWGt5caaR7jC2Lt
	mSMTiWoP5k56U6j9qwDBQpKwoOSelUa/e08bs=
MIME-Version: 1.0
Received: by 10.236.46.72 with SMTP id q48mr16987366yhb.80.1324121642892; Sat,
	17 Dec 2011 03:34:02 -0800 (PST)
Received: by 10.146.58.7 with HTTP; Sat, 17 Dec 2011 03:34:02 -0800 (PST)
In-Reply-To: <20111214220015.GF25896@andromeda.dapyr.net>
References: <CAMhBqqiLc1994GUKtA7UY52pR29nktmFy+XiwTwpZb_E+fwFRQ@mail.gmail.com>
	<CAMhBqqgu6v8NB-X0dNdfrzd12=Y2i==fYCCC2Z+MkDupqqKAOg@mail.gmail.com>
	<20111202195727.GA18758@andromeda.dapyr.net>
	<CAMhBqqgJ0Q3BZDuK3KEEGuDS2eGBZq89E7_Kbv+VNTYxZJLAAA@mail.gmail.com>
	<20111214194029.GB17432@andromeda.dapyr.net>
	<CAMhBqqj-3cjgiQsahL8BJHyJbCfYu+8dQx546XLf8Ht+6LiF0w@mail.gmail.com>
	<20111214220015.GF25896@andromeda.dapyr.net>
Date: Sat, 17 Dec 2011 12:34:02 +0100
Message-ID: <CAMhBqqiu5zmQ5XkE_2EkbqUDXJTZXh_dtx8Y5bss0a+x1XthMg@mail.gmail.com>
From: Quartexx <quartex73@gmail.com>
To: xen-devel@lists.xensource.com
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>
Subject: Re: [Xen-devel] xen 4.0.1 w/2.6.32.47 hangs at boot
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

2011/12/14 Konrad Rzeszutek Wilk <konrad@darnok.org> wrote:
> Ok, but you have a serial console, so you should be able to trigger
> Alt-SysRQ using the serial console. I think it is something like 'send
> break'. You should Google for it thought.

I can successfully trigger Alt-SysRQ using the serial console with a
non xen environment.
But I was not able to trigger Alt-SysRQ with xen using the serial
console.  Probably something related to hvc0?  Would be great to make
it work.


>  I would hazzard a guess that it is something with the 3ware driver.

I moved the box from datacenter to the office.  I did reboot a lot of
times and no issue anymore.
I noticed that when the box was in datacenter, 3ware battery
temperature state flapping from normal to high (there are three
states: normal, high and very high).  Just guessing: if reboot happen
when in high temperature state then it hangs. Probably with a poweroff
battery state resets and this explain why never hang at first boot.
Just a guess... or maybe an electrical contact gone away moving the
box.
Maybe you have a better explanation for this strange behaviour
Thanks

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Dec 17 11:34:59 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 17 Dec 2011 11:34:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbsWq-0008MP-F8; Sat, 17 Dec 2011 11:34:12 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <quartex73@gmail.com>) id 1RbsWo-0008MK-IK
	for xen-devel@lists.xensource.com; Sat, 17 Dec 2011 11:34:10 +0000
X-Env-Sender: quartex73@gmail.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1324121643!7763505!1
X-Originating-IP: [209.85.160.171]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26016 invoked from network); 17 Dec 2011 11:34:04 -0000
Received: from mail-gy0-f171.google.com (HELO mail-gy0-f171.google.com)
	(209.85.160.171)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Dec 2011 11:34:04 -0000
Received: by ghy10 with SMTP id 10so38363866ghy.30
	for <xen-devel@lists.xensource.com>;
	Sat, 17 Dec 2011 03:34:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=8hyGtcDLrb8F5aBQqFi7JxfhrJcMkEvwLOj4WXJO5Ak=;
	b=XMeLLn/yGqppV36f/iB/S87u+SYxBGqwNj65UU6Qxu2rNWvpjDoE3rJ7AyH70EkBZx
	QvP3zsj59ibTYRkFddqa9RnMBTeDXEZcBG1HoMSr5DRSQ/m6bJlVmXWGt5caaR7jC2Lt
	mSMTiWoP5k56U6j9qwDBQpKwoOSelUa/e08bs=
MIME-Version: 1.0
Received: by 10.236.46.72 with SMTP id q48mr16987366yhb.80.1324121642892; Sat,
	17 Dec 2011 03:34:02 -0800 (PST)
Received: by 10.146.58.7 with HTTP; Sat, 17 Dec 2011 03:34:02 -0800 (PST)
In-Reply-To: <20111214220015.GF25896@andromeda.dapyr.net>
References: <CAMhBqqiLc1994GUKtA7UY52pR29nktmFy+XiwTwpZb_E+fwFRQ@mail.gmail.com>
	<CAMhBqqgu6v8NB-X0dNdfrzd12=Y2i==fYCCC2Z+MkDupqqKAOg@mail.gmail.com>
	<20111202195727.GA18758@andromeda.dapyr.net>
	<CAMhBqqgJ0Q3BZDuK3KEEGuDS2eGBZq89E7_Kbv+VNTYxZJLAAA@mail.gmail.com>
	<20111214194029.GB17432@andromeda.dapyr.net>
	<CAMhBqqj-3cjgiQsahL8BJHyJbCfYu+8dQx546XLf8Ht+6LiF0w@mail.gmail.com>
	<20111214220015.GF25896@andromeda.dapyr.net>
Date: Sat, 17 Dec 2011 12:34:02 +0100
Message-ID: <CAMhBqqiu5zmQ5XkE_2EkbqUDXJTZXh_dtx8Y5bss0a+x1XthMg@mail.gmail.com>
From: Quartexx <quartex73@gmail.com>
To: xen-devel@lists.xensource.com
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>
Subject: Re: [Xen-devel] xen 4.0.1 w/2.6.32.47 hangs at boot
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

2011/12/14 Konrad Rzeszutek Wilk <konrad@darnok.org> wrote:
> Ok, but you have a serial console, so you should be able to trigger
> Alt-SysRQ using the serial console. I think it is something like 'send
> break'. You should Google for it thought.

I can successfully trigger Alt-SysRQ using the serial console with a
non xen environment.
But I was not able to trigger Alt-SysRQ with xen using the serial
console.  Probably something related to hvc0?  Would be great to make
it work.


>  I would hazzard a guess that it is something with the 3ware driver.

I moved the box from datacenter to the office.  I did reboot a lot of
times and no issue anymore.
I noticed that when the box was in datacenter, 3ware battery
temperature state flapping from normal to high (there are three
states: normal, high and very high).  Just guessing: if reboot happen
when in high temperature state then it hangs. Probably with a poweroff
battery state resets and this explain why never hang at first boot.
Just a guess... or maybe an electrical contact gone away moving the
box.
Maybe you have a better explanation for this strange behaviour
Thanks

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Dec 17 14:17:17 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 17 Dec 2011 14:17:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rbv3w-0001Rb-Qz; Sat, 17 Dec 2011 14:16:32 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.r.wilk@gmail.com>) id 1Rbv3v-0001RW-Dn
	for xen-devel@lists.xensource.com; Sat, 17 Dec 2011 14:16:31 +0000
X-Env-Sender: konrad.r.wilk@gmail.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1324131370!59332235!1
X-Originating-IP: [209.85.216.50]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27215 invoked from network); 17 Dec 2011 14:16:11 -0000
Received: from mail-qw0-f50.google.com (HELO mail-qw0-f50.google.com)
	(209.85.216.50)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Dec 2011 14:16:11 -0000
Received: by qaea17 with SMTP id a17so15908329qae.9
	for <xen-devel@lists.xensource.com>;
	Sat, 17 Dec 2011 06:16:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:date:from:to:cc:subject:message-id:references:mime-version
	:content-type:content-disposition:in-reply-to:user-agent;
	bh=dKuOMDHBtHKfukh/YP94rIyohB2IWoASMaOVpPSXlE4=;
	b=FjgnCm1hO4QAw5XsOJLPOoB3F0aPGhesHUwEQEZoVwe2wtPDt3kZ1dp3o6lgGBzPjK
	yqOpuQzEGcOq8f93Bf6qoYD64i9/mOC6AIK5xPqVgY8j5MpVhY9MJxjQnHUWwkWL+G9b
	M4iE0FQN5n3aBYG8zH3yWl5kY0xMp82Gq8fNE=
Received: by 10.224.102.2 with SMTP id e2mr192835qao.31.1324131388951;
	Sat, 17 Dec 2011 06:16:28 -0800 (PST)
Received: from konrad-lan (209-6-85-33.c3-0.smr-ubr2.sbo-smr.ma.cable.rcn.com.
	[209.6.85.33])
	by mx.google.com with ESMTPS id r10sm26567786qaz.7.2011.12.17.06.16.27
	(version=TLSv1/SSLv3 cipher=OTHER);
	Sat, 17 Dec 2011 06:16:28 -0800 (PST)
Date: Sat, 17 Dec 2011 09:16:20 -0500
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Adin Scannell <adin@scannell.ca>
Message-ID: <20111217141619.GA14816@konrad-lan>
References: <1324092141-9730-1-git-send-email-adin@scannell.ca>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1324092141-9730-1-git-send-email-adin@scannell.ca>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com, olaf@aepfle.de,
	JBeulich@suse.com, adin@gridcentric.com
Subject: Re: [Xen-devel] [PATCH] Add necessary bits to pvops Linux for
 mapping paged-out pages
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Dec 16, 2011 at 10:22:18PM -0500, Adin Scannell wrote:
> I've ported a couple of patches to the Linux pvops kernel that are necessary
> for correctly running domains with paging.  In a nutshell: in the case of a
> foreign attempt to map a paged-out page, the correct error code will now be
> propogated up to libxc, which will already handle it correctly.
> 
> This required an implementation of mmap_batch_v2.
> 
> I've tested it using a highly-paged domain and everything looks okay (qemu will
> receive the appropriate error via the mmap_batch_v2 and retry).

Please re-run these patches against scripts/checkpath.pl

Also do re-base them on my #linux-next branch (git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
#linux-next). I am a bit worried how they are going to work with Daniel's HVM
patches which I was planning to put in my branch shorlty:

http://old-list-archives.xen.org/archives/html/xen-devel/2011-10/msg01487.html

> 
> (My apologies if anyone/everyone receives this set of patches more than once,
> I've had some trouble with both my connection dying and guilt freaking out
> while I'm sending, leaving things in a bit of an unknown state.)

Next time please also send them to konrad.wilk@oracle.com.

Thanks!
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Dec 17 14:17:17 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 17 Dec 2011 14:17:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rbv3w-0001Rb-Qz; Sat, 17 Dec 2011 14:16:32 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.r.wilk@gmail.com>) id 1Rbv3v-0001RW-Dn
	for xen-devel@lists.xensource.com; Sat, 17 Dec 2011 14:16:31 +0000
X-Env-Sender: konrad.r.wilk@gmail.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1324131370!59332235!1
X-Originating-IP: [209.85.216.50]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27215 invoked from network); 17 Dec 2011 14:16:11 -0000
Received: from mail-qw0-f50.google.com (HELO mail-qw0-f50.google.com)
	(209.85.216.50)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Dec 2011 14:16:11 -0000
Received: by qaea17 with SMTP id a17so15908329qae.9
	for <xen-devel@lists.xensource.com>;
	Sat, 17 Dec 2011 06:16:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:date:from:to:cc:subject:message-id:references:mime-version
	:content-type:content-disposition:in-reply-to:user-agent;
	bh=dKuOMDHBtHKfukh/YP94rIyohB2IWoASMaOVpPSXlE4=;
	b=FjgnCm1hO4QAw5XsOJLPOoB3F0aPGhesHUwEQEZoVwe2wtPDt3kZ1dp3o6lgGBzPjK
	yqOpuQzEGcOq8f93Bf6qoYD64i9/mOC6AIK5xPqVgY8j5MpVhY9MJxjQnHUWwkWL+G9b
	M4iE0FQN5n3aBYG8zH3yWl5kY0xMp82Gq8fNE=
Received: by 10.224.102.2 with SMTP id e2mr192835qao.31.1324131388951;
	Sat, 17 Dec 2011 06:16:28 -0800 (PST)
Received: from konrad-lan (209-6-85-33.c3-0.smr-ubr2.sbo-smr.ma.cable.rcn.com.
	[209.6.85.33])
	by mx.google.com with ESMTPS id r10sm26567786qaz.7.2011.12.17.06.16.27
	(version=TLSv1/SSLv3 cipher=OTHER);
	Sat, 17 Dec 2011 06:16:28 -0800 (PST)
Date: Sat, 17 Dec 2011 09:16:20 -0500
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Adin Scannell <adin@scannell.ca>
Message-ID: <20111217141619.GA14816@konrad-lan>
References: <1324092141-9730-1-git-send-email-adin@scannell.ca>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1324092141-9730-1-git-send-email-adin@scannell.ca>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com, olaf@aepfle.de,
	JBeulich@suse.com, adin@gridcentric.com
Subject: Re: [Xen-devel] [PATCH] Add necessary bits to pvops Linux for
 mapping paged-out pages
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Dec 16, 2011 at 10:22:18PM -0500, Adin Scannell wrote:
> I've ported a couple of patches to the Linux pvops kernel that are necessary
> for correctly running domains with paging.  In a nutshell: in the case of a
> foreign attempt to map a paged-out page, the correct error code will now be
> propogated up to libxc, which will already handle it correctly.
> 
> This required an implementation of mmap_batch_v2.
> 
> I've tested it using a highly-paged domain and everything looks okay (qemu will
> receive the appropriate error via the mmap_batch_v2 and retry).

Please re-run these patches against scripts/checkpath.pl

Also do re-base them on my #linux-next branch (git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
#linux-next). I am a bit worried how they are going to work with Daniel's HVM
patches which I was planning to put in my branch shorlty:

http://old-list-archives.xen.org/archives/html/xen-devel/2011-10/msg01487.html

> 
> (My apologies if anyone/everyone receives this set of patches more than once,
> I've had some trouble with both my connection dying and guilt freaking out
> while I'm sending, leaving things in a bit of an unknown state.)

Next time please also send them to konrad.wilk@oracle.com.

Thanks!
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Dec 17 14:17:45 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 17 Dec 2011 14:17:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rbv4T-0001Sk-8V; Sat, 17 Dec 2011 14:17:05 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.r.wilk@gmail.com>) id 1Rbv4S-0001ST-D7
	for xen-devel@lists.xensource.com; Sat, 17 Dec 2011 14:17:04 +0000
X-Env-Sender: konrad.r.wilk@gmail.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1324131417!8340031!1
X-Originating-IP: [209.85.216.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27532 invoked from network); 17 Dec 2011 14:16:58 -0000
Received: from mail-qy0-f171.google.com (HELO mail-qy0-f171.google.com)
	(209.85.216.171)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Dec 2011 14:16:58 -0000
Received: by qcsc20 with SMTP id c20so29218314qcs.30
	for <xen-devel@lists.xensource.com>;
	Sat, 17 Dec 2011 06:16:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:date:from:to:cc:subject:message-id:references:mime-version
	:content-type:content-disposition:in-reply-to:user-agent;
	bh=lfWM6eb+FWnidnDxtCW+9RlJA98Fg1Zu+AL4oVEudTo=;
	b=jQfreOhmLUtMKQZVxyRkYBN0BF1MzePU+rBKUHFpQ4/x7cI6hk+yg+O0Jd783uzF9D
	HYOaHRothF2lxwGosEGZNITXYkDBbsNsZA/eZZJMURbavC54pl6Ovl/UIkSxhy2rxKBj
	mqHbEaUMjsrJSF4JF+bVuOPWbmuX6ybpIrR2k=
Received: by 10.229.107.34 with SMTP id z34mr3161942qco.0.1324131417172;
	Sat, 17 Dec 2011 06:16:57 -0800 (PST)
Received: from konrad-lan (209-6-85-33.c3-0.smr-ubr2.sbo-smr.ma.cable.rcn.com.
	[209.6.85.33])
	by mx.google.com with ESMTPS id eb5sm26562240qab.10.2011.12.17.06.16.55
	(version=TLSv1/SSLv3 cipher=OTHER);
	Sat, 17 Dec 2011 06:16:56 -0800 (PST)
Date: Sat, 17 Dec 2011 09:16:53 -0500
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Adin Scannell <adin@scannell.ca>
Message-ID: <20111217141652.GB14816@konrad-lan>
References: <1324092141-9730-1-git-send-email-adin@scannell.ca>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1324092141-9730-1-git-send-email-adin@scannell.ca>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com, olaf@aepfle.de,
	JBeulich@suse.com, adin@gridcentric.com
Subject: Re: [Xen-devel] [PATCH] Add necessary bits to pvops Linux for
 mapping paged-out pages
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Dec 16, 2011 at 10:22:18PM -0500, Adin Scannell wrote:
> I've ported a couple of patches to the Linux pvops kernel that are necessary
> for correctly running domains with paging.  In a nutshell: in the case of a
> foreign attempt to map a paged-out page, the correct error code will now be
> propogated up to libxc, which will already handle it correctly.
> 
> This required an implementation of mmap_batch_v2.
> 
> I've tested it using a highly-paged domain and everything looks okay (qemu will
> receive the appropriate error via the mmap_batch_v2 and retry).
> 
> (My apologies if anyone/everyone receives this set of patches more than once,
> I've had some trouble with both my connection dying and guilt freaking out
> while I'm sending, leaving things in a bit of an unknown state.)


Ah, and also please CC LKML mailing list. Thanks.
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Dec 17 14:17:45 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 17 Dec 2011 14:17:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rbv4T-0001Sk-8V; Sat, 17 Dec 2011 14:17:05 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.r.wilk@gmail.com>) id 1Rbv4S-0001ST-D7
	for xen-devel@lists.xensource.com; Sat, 17 Dec 2011 14:17:04 +0000
X-Env-Sender: konrad.r.wilk@gmail.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1324131417!8340031!1
X-Originating-IP: [209.85.216.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27532 invoked from network); 17 Dec 2011 14:16:58 -0000
Received: from mail-qy0-f171.google.com (HELO mail-qy0-f171.google.com)
	(209.85.216.171)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Dec 2011 14:16:58 -0000
Received: by qcsc20 with SMTP id c20so29218314qcs.30
	for <xen-devel@lists.xensource.com>;
	Sat, 17 Dec 2011 06:16:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:date:from:to:cc:subject:message-id:references:mime-version
	:content-type:content-disposition:in-reply-to:user-agent;
	bh=lfWM6eb+FWnidnDxtCW+9RlJA98Fg1Zu+AL4oVEudTo=;
	b=jQfreOhmLUtMKQZVxyRkYBN0BF1MzePU+rBKUHFpQ4/x7cI6hk+yg+O0Jd783uzF9D
	HYOaHRothF2lxwGosEGZNITXYkDBbsNsZA/eZZJMURbavC54pl6Ovl/UIkSxhy2rxKBj
	mqHbEaUMjsrJSF4JF+bVuOPWbmuX6ybpIrR2k=
Received: by 10.229.107.34 with SMTP id z34mr3161942qco.0.1324131417172;
	Sat, 17 Dec 2011 06:16:57 -0800 (PST)
Received: from konrad-lan (209-6-85-33.c3-0.smr-ubr2.sbo-smr.ma.cable.rcn.com.
	[209.6.85.33])
	by mx.google.com with ESMTPS id eb5sm26562240qab.10.2011.12.17.06.16.55
	(version=TLSv1/SSLv3 cipher=OTHER);
	Sat, 17 Dec 2011 06:16:56 -0800 (PST)
Date: Sat, 17 Dec 2011 09:16:53 -0500
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Adin Scannell <adin@scannell.ca>
Message-ID: <20111217141652.GB14816@konrad-lan>
References: <1324092141-9730-1-git-send-email-adin@scannell.ca>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1324092141-9730-1-git-send-email-adin@scannell.ca>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com, olaf@aepfle.de,
	JBeulich@suse.com, adin@gridcentric.com
Subject: Re: [Xen-devel] [PATCH] Add necessary bits to pvops Linux for
 mapping paged-out pages
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Dec 16, 2011 at 10:22:18PM -0500, Adin Scannell wrote:
> I've ported a couple of patches to the Linux pvops kernel that are necessary
> for correctly running domains with paging.  In a nutshell: in the case of a
> foreign attempt to map a paged-out page, the correct error code will now be
> propogated up to libxc, which will already handle it correctly.
> 
> This required an implementation of mmap_batch_v2.
> 
> I've tested it using a highly-paged domain and everything looks okay (qemu will
> receive the appropriate error via the mmap_batch_v2 and retry).
> 
> (My apologies if anyone/everyone receives this set of patches more than once,
> I've had some trouble with both my connection dying and guilt freaking out
> while I'm sending, leaving things in a bit of an unknown state.)


Ah, and also please CC LKML mailing list. Thanks.
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Dec 17 14:19:41 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 17 Dec 2011 14:19:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rbv6S-0001b2-PX; Sat, 17 Dec 2011 14:19:08 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.r.wilk@gmail.com>) id 1Rbv6R-0001ap-90
	for xen-devel@lists.xensource.com; Sat, 17 Dec 2011 14:19:07 +0000
X-Env-Sender: konrad.r.wilk@gmail.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1324131511!45281431!1
X-Originating-IP: [209.85.216.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25149 invoked from network); 17 Dec 2011 14:18:32 -0000
Received: from mail-qw0-f43.google.com (HELO mail-qw0-f43.google.com)
	(209.85.216.43)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Dec 2011 14:18:32 -0000
Received: by qabg27 with SMTP id g27so11373158qab.9
	for <xen-devel@lists.xensource.com>;
	Sat, 17 Dec 2011 06:19:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:date:from:to:cc:subject:message-id:references:mime-version
	:content-type:content-disposition:in-reply-to:user-agent;
	bh=JmlVwfpYtOpmmb3W5iLR9HlMQQnrAoyCRlyQptjNoac=;
	b=PNPXXwjX9dFrUz8Ul6sa7zwHNsXqNrAcpo5k1kl+qPzpyB3+lBWK7Pdsx/8dhvga7o
	QRiv39/4wWN1DXYAogRbKvbBmOlW15HW7Nl+o1wdJ2RxYxXh3KTmb+3Nb0M/hctEfXzX
	lzfpDPplpSR9RW7dze9Hmmm5+kJkPDZnbliOk=
Received: by 10.224.34.17 with SMTP id j17mr17297349qad.22.1324131542050;
	Sat, 17 Dec 2011 06:19:02 -0800 (PST)
Received: from konrad-lan (209-6-85-33.c3-0.smr-ubr2.sbo-smr.ma.cable.rcn.com.
	[209.6.85.33])
	by mx.google.com with ESMTPS id ed2sm26552263qab.15.2011.12.17.06.19.01
	(version=TLSv1/SSLv3 cipher=OTHER);
	Sat, 17 Dec 2011 06:19:01 -0800 (PST)
Date: Sat, 17 Dec 2011 09:18:58 -0500
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Quartexx <quartex73@gmail.com>
Message-ID: <20111217141858.GC14816@konrad-lan>
References: <CAMhBqqiLc1994GUKtA7UY52pR29nktmFy+XiwTwpZb_E+fwFRQ@mail.gmail.com>
	<CAMhBqqgu6v8NB-X0dNdfrzd12=Y2i==fYCCC2Z+MkDupqqKAOg@mail.gmail.com>
	<20111202195727.GA18758@andromeda.dapyr.net>
	<CAMhBqqgJ0Q3BZDuK3KEEGuDS2eGBZq89E7_Kbv+VNTYxZJLAAA@mail.gmail.com>
	<20111214194029.GB17432@andromeda.dapyr.net>
	<CAMhBqqj-3cjgiQsahL8BJHyJbCfYu+8dQx546XLf8Ht+6LiF0w@mail.gmail.com>
	<20111214220015.GF25896@andromeda.dapyr.net>
	<CAMhBqqiu5zmQ5XkE_2EkbqUDXJTZXh_dtx8Y5bss0a+x1XthMg@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAMhBqqiu5zmQ5XkE_2EkbqUDXJTZXh_dtx8Y5bss0a+x1XthMg@mail.gmail.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] xen 4.0.1 w/2.6.32.47 hangs at boot
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Sat, Dec 17, 2011 at 12:34:02PM +0100, Quartexx wrote:
> 2011/12/14 Konrad Rzeszutek Wilk <konrad@darnok.org> wrote:
> > Ok, but you have a serial console, so you should be able to trigger
> > Alt-SysRQ using the serial console. I think it is something like 'send
> > break'. You should Google for it thought.
> 
> I can successfully trigger Alt-SysRQ using the serial console with a
> non xen environment.
> But I was not able to trigger Alt-SysRQ with xen using the serial
> console.  Probably something related to hvc0?  Would be great to make
> it work.

You could just have the serial console be passed in the dom0 and
not have the Xen hypervisor use it. That would allow you to trigger the
dom0 Alt-SysRQ
> 
> 
> >  I would hazzard a guess that it is something with the 3ware driver.
> 
> I moved the box from datacenter to the office.  I did reboot a lot of
> times and no issue anymore.
> I noticed that when the box was in datacenter, 3ware battery
> temperature state flapping from normal to high (there are three
> states: normal, high and very high).  Just guessing: if reboot happen

Wow. You might want to get a refund from your datacenter if they are
running at those temperatures.
> when in high temperature state then it hangs. Probably with a poweroff
> battery state resets and this explain why never hang at first boot.
> Just a guess... or maybe an electrical contact gone away moving the
> box.
> Maybe you have a better explanation for this strange behaviour
> Thanks
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Dec 17 14:19:41 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 17 Dec 2011 14:19:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rbv6S-0001b2-PX; Sat, 17 Dec 2011 14:19:08 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.r.wilk@gmail.com>) id 1Rbv6R-0001ap-90
	for xen-devel@lists.xensource.com; Sat, 17 Dec 2011 14:19:07 +0000
X-Env-Sender: konrad.r.wilk@gmail.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1324131511!45281431!1
X-Originating-IP: [209.85.216.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25149 invoked from network); 17 Dec 2011 14:18:32 -0000
Received: from mail-qw0-f43.google.com (HELO mail-qw0-f43.google.com)
	(209.85.216.43)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Dec 2011 14:18:32 -0000
Received: by qabg27 with SMTP id g27so11373158qab.9
	for <xen-devel@lists.xensource.com>;
	Sat, 17 Dec 2011 06:19:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:date:from:to:cc:subject:message-id:references:mime-version
	:content-type:content-disposition:in-reply-to:user-agent;
	bh=JmlVwfpYtOpmmb3W5iLR9HlMQQnrAoyCRlyQptjNoac=;
	b=PNPXXwjX9dFrUz8Ul6sa7zwHNsXqNrAcpo5k1kl+qPzpyB3+lBWK7Pdsx/8dhvga7o
	QRiv39/4wWN1DXYAogRbKvbBmOlW15HW7Nl+o1wdJ2RxYxXh3KTmb+3Nb0M/hctEfXzX
	lzfpDPplpSR9RW7dze9Hmmm5+kJkPDZnbliOk=
Received: by 10.224.34.17 with SMTP id j17mr17297349qad.22.1324131542050;
	Sat, 17 Dec 2011 06:19:02 -0800 (PST)
Received: from konrad-lan (209-6-85-33.c3-0.smr-ubr2.sbo-smr.ma.cable.rcn.com.
	[209.6.85.33])
	by mx.google.com with ESMTPS id ed2sm26552263qab.15.2011.12.17.06.19.01
	(version=TLSv1/SSLv3 cipher=OTHER);
	Sat, 17 Dec 2011 06:19:01 -0800 (PST)
Date: Sat, 17 Dec 2011 09:18:58 -0500
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Quartexx <quartex73@gmail.com>
Message-ID: <20111217141858.GC14816@konrad-lan>
References: <CAMhBqqiLc1994GUKtA7UY52pR29nktmFy+XiwTwpZb_E+fwFRQ@mail.gmail.com>
	<CAMhBqqgu6v8NB-X0dNdfrzd12=Y2i==fYCCC2Z+MkDupqqKAOg@mail.gmail.com>
	<20111202195727.GA18758@andromeda.dapyr.net>
	<CAMhBqqgJ0Q3BZDuK3KEEGuDS2eGBZq89E7_Kbv+VNTYxZJLAAA@mail.gmail.com>
	<20111214194029.GB17432@andromeda.dapyr.net>
	<CAMhBqqj-3cjgiQsahL8BJHyJbCfYu+8dQx546XLf8Ht+6LiF0w@mail.gmail.com>
	<20111214220015.GF25896@andromeda.dapyr.net>
	<CAMhBqqiu5zmQ5XkE_2EkbqUDXJTZXh_dtx8Y5bss0a+x1XthMg@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAMhBqqiu5zmQ5XkE_2EkbqUDXJTZXh_dtx8Y5bss0a+x1XthMg@mail.gmail.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] xen 4.0.1 w/2.6.32.47 hangs at boot
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Sat, Dec 17, 2011 at 12:34:02PM +0100, Quartexx wrote:
> 2011/12/14 Konrad Rzeszutek Wilk <konrad@darnok.org> wrote:
> > Ok, but you have a serial console, so you should be able to trigger
> > Alt-SysRQ using the serial console. I think it is something like 'send
> > break'. You should Google for it thought.
> 
> I can successfully trigger Alt-SysRQ using the serial console with a
> non xen environment.
> But I was not able to trigger Alt-SysRQ with xen using the serial
> console.  Probably something related to hvc0?  Would be great to make
> it work.

You could just have the serial console be passed in the dom0 and
not have the Xen hypervisor use it. That would allow you to trigger the
dom0 Alt-SysRQ
> 
> 
> >  I would hazzard a guess that it is something with the 3ware driver.
> 
> I moved the box from datacenter to the office.  I did reboot a lot of
> times and no issue anymore.
> I noticed that when the box was in datacenter, 3ware battery
> temperature state flapping from normal to high (there are three
> states: normal, high and very high).  Just guessing: if reboot happen

Wow. You might want to get a refund from your datacenter if they are
running at those temperatures.
> when in high temperature state then it hangs. Probably with a poweroff
> battery state resets and this explain why never hang at first boot.
> Just a guess... or maybe an electrical contact gone away moving the
> box.
> Maybe you have a better explanation for this strange behaviour
> Thanks
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Dec 17 14:30:55 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 17 Dec 2011 14:30:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbvHS-0001ur-Vw; Sat, 17 Dec 2011 14:30:30 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.r.wilk@gmail.com>) id 1RbvHR-0001ud-0E
	for xen-devel@lists.xensource.com; Sat, 17 Dec 2011 14:30:29 +0000
X-Env-Sender: konrad.r.wilk@gmail.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1324132220!7667125!1
X-Originating-IP: [209.85.216.50]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17111 invoked from network); 17 Dec 2011 14:30:21 -0000
Received: from mail-qw0-f50.google.com (HELO mail-qw0-f50.google.com)
	(209.85.216.50)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Dec 2011 14:30:21 -0000
Received: by qaea17 with SMTP id a17so15949029qae.9
	for <xen-devel@lists.xensource.com>;
	Sat, 17 Dec 2011 06:30:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:date:from:to:cc:subject:message-id:references:mime-version
	:content-type:content-disposition:in-reply-to:user-agent;
	bh=Vn1gi8HRAmbVlkzgnN85Yi4EzyA+N+jtZrPu8IOGJaM=;
	b=gVkvfJ783TBLs24qP/bVZenKJeXFjcPUwIQpz0UUX6Ptn8OSbceNAWWiGeNLNB+TpR
	erEIOG/X4iMWsEKb7ySVNK8LzeMYSr/l9+AMX8vqb6ZAIwlum3viKO40+l+utTRy2vav
	XQgyB+NT3Rsa8swwe9g9lS+5wdlqt+PjdLAy0=
Received: by 10.224.72.148 with SMTP id m20mr17129365qaj.26.1324132220132;
	Sat, 17 Dec 2011 06:30:20 -0800 (PST)
Received: from konrad-lan (209-6-85-33.c3-0.smr-ubr2.sbo-smr.ma.cable.rcn.com.
	[209.6.85.33])
	by mx.google.com with ESMTPS id el7sm26603118qab.16.2011.12.17.06.30.18
	(version=TLSv1/SSLv3 cipher=OTHER);
	Sat, 17 Dec 2011 06:30:19 -0800 (PST)
Date: Sat, 17 Dec 2011 09:30:16 -0500
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Adin Scannell <adin@scannell.ca>
Message-ID: <20111217143015.GD14816@konrad-lan>
References: <1324092141-9730-1-git-send-email-adin@scannell.ca>
	<1324092141-9730-3-git-send-email-adin@scannell.ca>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1324092141-9730-3-git-send-email-adin@scannell.ca>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com, olaf@aepfle.de,
	JBeulich@suse.com, adin@gridcentric.com
Subject: Re: [Xen-devel] [PATCH 2/3] Handle GNTST_eagain in kernel drivers
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Dec 16, 2011 at 10:22:20PM -0500, Adin Scannell wrote:
> Handle GNTST_eagain status from GNTTABOP_map_grant_ref and
> GNTTABOP_copy operations properly to allow usage of xenpaging without
> causing crashes or data corruption.
> 
> Replace all relevant HYPERVISOR_grant_table_op() calls with a retry
> loop. This loop is implemented as a macro to allow different
> GNTTABOP_* args. It will sleep up to 33 seconds and wait for the
> page to be paged in again.
> 
> All ->status checks were updated to use the GNTST_* namespace. All
> return values are converted from GNTST_* namespace to 0/-EINVAL, since
> all callers did not use the actual return value.
> 
> Signed-off-by: Olaf Hering <olaf@aepfle.de>
> Acked-by: Patrick Colp <pjcolp@cs.ubc.ca>
> 
> This is a port to the mainline Linux tree.  This required dropping many backend
> drivers which have not yet made it in.  Additionally, several of the referenced
> functions have moved and/or been refactored.  I attempted to minimize changes
> while keeping the same semantics.
> 
> Signed-off-by: Adin Scannell <adin@scannell.ca>
> 
> Index: linux/drivers/block/xen-blkback/blkback.c
> ===================================================================
> ---
>  drivers/block/xen-blkback/blkback.c |    4 ++-
>  drivers/xen/grant-table.c           |    7 ++++-
>  drivers/xen/xenbus/xenbus_client.c  |    4 +++
>  include/xen/grant_table.h           |   39 +++++++++++++++++++++++++++++++++++
>  include/xen/interface/grant_table.h |    6 ++++-

>  5 files changed, 56 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/block/xen-blkback/blkback.c b/drivers/block/xen-blkback/blkback.c
> index 15ec4db..d3fb290 100644
> --- a/drivers/block/xen-blkback/blkback.c
> +++ b/drivers/block/xen-blkback/blkback.c
> @@ -390,7 +390,9 @@ static int xen_blkbk_map(struct blkif_request *req,
>  	 * the page from the other domain.
>  	 */
>  	for (i = 0; i < nseg; i++) {
> -		if (unlikely(map[i].status != 0)) {
> +		if (unlikely(map[i].status == GNTST_eagain))
> +			gnttab_check_GNTST_eagain_do_while(GNTTABOP_map_grant_ref, &map[i]);
> +		if (unlikely(map[i].status != GNTST_okay)) {
>  			pr_debug(DRV_PFX "invalid buffer -- could not remap it\n");
>  			map[i].handle = BLKBACK_INVALID_HANDLE;
>  			ret |= 1;

> diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
> index bf1c094..48826c3 100644
> --- a/drivers/xen/grant-table.c
> +++ b/drivers/xen/grant-table.c
> @@ -464,9 +464,12 @@ int gnttab_map_refs(struct gnttab_map_grant_ref *map_ops,
>  
>  	for (i = 0; i < count; i++) {
>  		/* Do not add to override if the map failed. */
> -		if (map_ops[i].status)
> +		if (map_ops[i].status != GNTST_okay && map_ops[i].status != GNTST_eagain)
>  			continue;
>  
> +		if (map_ops[i].status == GNTST_eagain)
> +			return -EAGAIN;
> +
>  		if (map_ops[i].flags & GNTMAP_contains_pte) {
>  			pte = (pte_t *) (mfn_to_virt(PFN_DOWN(map_ops[i].host_addr)) +
>  				(map_ops[i].host_addr & ~PAGE_MASK));
> @@ -565,7 +568,7 @@ static int gnttab_map(unsigned int start_idx, unsigned int end_idx)
>  		return -ENOSYS;
>  	}
>  
> -	BUG_ON(rc || setup.status);
> +	BUG_ON(rc || (setup.status != GNTST_okay));
>  
>  	rc = arch_gnttab_map_shared(frames, nr_gframes, gnttab_max_grant_frames(),
>  				    &shared);
> diff --git a/drivers/xen/xenbus/xenbus_client.c b/drivers/xen/xenbus/xenbus_client.c
> index 1906125..d123c78 100644
> --- a/drivers/xen/xenbus/xenbus_client.c
> +++ b/drivers/xen/xenbus/xenbus_client.c
> @@ -455,6 +455,8 @@ int xenbus_map_ring_valloc(struct xenbus_device *dev, int gnt_ref, void **vaddr)
>  	if (HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, &op, 1))
>  		BUG();
>  
> +	if (op.status == GNTST_eagain)
> +		gnttab_check_GNTST_eagain_do_while(GNTTABOP_map_grant_ref, (&op));
>  	if (op.status != GNTST_okay) {
>  		free_vm_area(area);
>  		xenbus_dev_fatal(dev, op.status,
> @@ -499,6 +501,8 @@ int xenbus_map_ring(struct xenbus_device *dev, int gnt_ref,
>  	if (HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, &op, 1))
>  		BUG();
>  
> +	if (op.status == GNTST_eagain)
> +		gnttab_check_GNTST_eagain_do_while(GNTTABOP_map_grant_ref, (&op));
>  	if (op.status != GNTST_okay) {
>  		xenbus_dev_fatal(dev, op.status,
>  				 "mapping in shared page %d from domain %d",
> diff --git a/include/xen/grant_table.h b/include/xen/grant_table.h
> index 11e2dfc..46fac85 100644
> --- a/include/xen/grant_table.h
> +++ b/include/xen/grant_table.h
> @@ -37,6 +37,8 @@
>  #ifndef __ASM_GNTTAB_H__
>  #define __ASM_GNTTAB_H__
>  
> +#include <linux/delay.h>
> +
>  #include <asm/page.h>
>  
>  #include <xen/interface/xen.h>
> @@ -160,4 +162,41 @@ int gnttab_map_refs(struct gnttab_map_grant_ref *map_ops,
>  int gnttab_unmap_refs(struct gnttab_unmap_grant_ref *unmap_ops,
>  		      struct page **pages, unsigned int count);
>  
> +#define gnttab_check_GNTST_eagain_while(__HCop, __HCarg_p)					\

So why does this have to be a macro? What is the advantage of that
versus making this a function?

> +do {																		\
> +	u8 __hc_delay = 1;														\
> +	int __ret;																\
> +	while (unlikely((__HCarg_p)->status == GNTST_eagain && __hc_delay)) {	\
> +		msleep(__hc_delay++);												\

Ugh. Not sure what happend to this, but there are tons of '\' at the
end.

So why msleep? Why not go for a proper yield? Call the safe_halt()
function?

> +		__ret = HYPERVISOR_grant_table_op(__HCop, (__HCarg_p), 1);			\
> +		BUG_ON(__ret);														\
> +	}																		\
> +	if (__hc_delay == 0) {													\

So this would happen if we rolled over __hc_delay, so did this more than
255 times? Presumarily this can happen if the swapper in dom0 crashes..

I would recommend you use 'WARN' here and include tons of details.
This is a pretty serious issues, is it not?

> +		printk(KERN_ERR "%s: gnt busy\n", __func__,);						\
> +		(__HCarg_p)->status = GNTST_bad_page;								\
> +	}																		\
> +	if ((__HCarg_p)->status != GNTST_okay)									\
> +		printk(KERN_ERR "%s: gnt status %x\n", 								\
> +			__func__, (__HCarg_p)->status);									\

Use GNTTABOP_error_msgs. Also should we continue? What is the
impact if we do continue? The times this is hit is if the status
is not GNTS_okay and if it is not GNTS_eagain - so what are the
situations in which this happens and what can the domain do
to recover? Should there be some helpfull message instead of
just "gnt status: X" ?

> +} while(0)
> +
> +#define gnttab_check_GNTST_eagain_do_while(__HCop, __HCarg_p)			\
> +do {																	\
> +	u8 __hc_delay = 1;													\
> +	int __ret;															\
> +	do {																\
> +		__ret = HYPERVISOR_grant_table_op(__HCop, (__HCarg_p), 1);		\
> +		BUG_ON(__ret);													\
> +		if ((__HCarg_p)->status == GNTST_eagain)						\
> +			msleep(__hc_delay++);										\
> +	} while ((__HCarg_p)->status == GNTST_eagain && __hc_delay);		\
> +	if (__hc_delay == 0) {												\
> +		printk(KERN_ERR "%s: gnt busy\n", __func__);					\
> +		(__HCarg_p)->status = GNTST_bad_page;							\
> +	}																	\
> +	if ((__HCarg_p)->status != GNTST_okay)								\
> +		printk(KERN_ERR "%s: gnt status %x\n", 							\
> +			__func__, (__HCarg_p)->status);								\
> +} while(0)
> +
>  #endif /* __ASM_GNTTAB_H__ */
> diff --git a/include/xen/interface/grant_table.h b/include/xen/interface/grant_table.h
> index 39e5717..ba04080 100644
> --- a/include/xen/interface/grant_table.h
> +++ b/include/xen/interface/grant_table.h
> @@ -363,6 +363,8 @@ DEFINE_GUEST_HANDLE_STRUCT(gnttab_query_size);
>  #define GNTST_permission_denied (-8) /* Not enough privilege for operation.  */
>  #define GNTST_bad_page         (-9) /* Specified page was invalid for op.    */
>  #define GNTST_bad_copy_arg    (-10) /* copy arguments cross page boundary */
> +#define GNTST_address_too_big (-11) /* transfer page address too large.      */
> +#define GNTST_eagain          (-12) /* Could not map at the moment. Retry.   */
>  
>  #define GNTTABOP_error_msgs {                   \
>      "okay",                                     \
> @@ -375,7 +377,9 @@ DEFINE_GUEST_HANDLE_STRUCT(gnttab_query_size);
>      "no spare translation slot in the I/O MMU", \
>      "permission denied",                        \
>      "bad page",                                 \
> -    "copy arguments cross page boundary"        \
> +    "copy arguments cross page boundary",       \
> +    "page address size too large",              \
> +    "could not map at the moment, retry"        \
>  }
>  
>  #endif /* __XEN_PUBLIC_GRANT_TABLE_H__ */
> -- 
> 1.6.2.5
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Dec 17 14:30:55 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 17 Dec 2011 14:30:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbvHS-0001ur-Vw; Sat, 17 Dec 2011 14:30:30 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.r.wilk@gmail.com>) id 1RbvHR-0001ud-0E
	for xen-devel@lists.xensource.com; Sat, 17 Dec 2011 14:30:29 +0000
X-Env-Sender: konrad.r.wilk@gmail.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1324132220!7667125!1
X-Originating-IP: [209.85.216.50]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17111 invoked from network); 17 Dec 2011 14:30:21 -0000
Received: from mail-qw0-f50.google.com (HELO mail-qw0-f50.google.com)
	(209.85.216.50)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Dec 2011 14:30:21 -0000
Received: by qaea17 with SMTP id a17so15949029qae.9
	for <xen-devel@lists.xensource.com>;
	Sat, 17 Dec 2011 06:30:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:date:from:to:cc:subject:message-id:references:mime-version
	:content-type:content-disposition:in-reply-to:user-agent;
	bh=Vn1gi8HRAmbVlkzgnN85Yi4EzyA+N+jtZrPu8IOGJaM=;
	b=gVkvfJ783TBLs24qP/bVZenKJeXFjcPUwIQpz0UUX6Ptn8OSbceNAWWiGeNLNB+TpR
	erEIOG/X4iMWsEKb7ySVNK8LzeMYSr/l9+AMX8vqb6ZAIwlum3viKO40+l+utTRy2vav
	XQgyB+NT3Rsa8swwe9g9lS+5wdlqt+PjdLAy0=
Received: by 10.224.72.148 with SMTP id m20mr17129365qaj.26.1324132220132;
	Sat, 17 Dec 2011 06:30:20 -0800 (PST)
Received: from konrad-lan (209-6-85-33.c3-0.smr-ubr2.sbo-smr.ma.cable.rcn.com.
	[209.6.85.33])
	by mx.google.com with ESMTPS id el7sm26603118qab.16.2011.12.17.06.30.18
	(version=TLSv1/SSLv3 cipher=OTHER);
	Sat, 17 Dec 2011 06:30:19 -0800 (PST)
Date: Sat, 17 Dec 2011 09:30:16 -0500
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Adin Scannell <adin@scannell.ca>
Message-ID: <20111217143015.GD14816@konrad-lan>
References: <1324092141-9730-1-git-send-email-adin@scannell.ca>
	<1324092141-9730-3-git-send-email-adin@scannell.ca>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1324092141-9730-3-git-send-email-adin@scannell.ca>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com, olaf@aepfle.de,
	JBeulich@suse.com, adin@gridcentric.com
Subject: Re: [Xen-devel] [PATCH 2/3] Handle GNTST_eagain in kernel drivers
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Dec 16, 2011 at 10:22:20PM -0500, Adin Scannell wrote:
> Handle GNTST_eagain status from GNTTABOP_map_grant_ref and
> GNTTABOP_copy operations properly to allow usage of xenpaging without
> causing crashes or data corruption.
> 
> Replace all relevant HYPERVISOR_grant_table_op() calls with a retry
> loop. This loop is implemented as a macro to allow different
> GNTTABOP_* args. It will sleep up to 33 seconds and wait for the
> page to be paged in again.
> 
> All ->status checks were updated to use the GNTST_* namespace. All
> return values are converted from GNTST_* namespace to 0/-EINVAL, since
> all callers did not use the actual return value.
> 
> Signed-off-by: Olaf Hering <olaf@aepfle.de>
> Acked-by: Patrick Colp <pjcolp@cs.ubc.ca>
> 
> This is a port to the mainline Linux tree.  This required dropping many backend
> drivers which have not yet made it in.  Additionally, several of the referenced
> functions have moved and/or been refactored.  I attempted to minimize changes
> while keeping the same semantics.
> 
> Signed-off-by: Adin Scannell <adin@scannell.ca>
> 
> Index: linux/drivers/block/xen-blkback/blkback.c
> ===================================================================
> ---
>  drivers/block/xen-blkback/blkback.c |    4 ++-
>  drivers/xen/grant-table.c           |    7 ++++-
>  drivers/xen/xenbus/xenbus_client.c  |    4 +++
>  include/xen/grant_table.h           |   39 +++++++++++++++++++++++++++++++++++
>  include/xen/interface/grant_table.h |    6 ++++-

>  5 files changed, 56 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/block/xen-blkback/blkback.c b/drivers/block/xen-blkback/blkback.c
> index 15ec4db..d3fb290 100644
> --- a/drivers/block/xen-blkback/blkback.c
> +++ b/drivers/block/xen-blkback/blkback.c
> @@ -390,7 +390,9 @@ static int xen_blkbk_map(struct blkif_request *req,
>  	 * the page from the other domain.
>  	 */
>  	for (i = 0; i < nseg; i++) {
> -		if (unlikely(map[i].status != 0)) {
> +		if (unlikely(map[i].status == GNTST_eagain))
> +			gnttab_check_GNTST_eagain_do_while(GNTTABOP_map_grant_ref, &map[i]);
> +		if (unlikely(map[i].status != GNTST_okay)) {
>  			pr_debug(DRV_PFX "invalid buffer -- could not remap it\n");
>  			map[i].handle = BLKBACK_INVALID_HANDLE;
>  			ret |= 1;

> diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
> index bf1c094..48826c3 100644
> --- a/drivers/xen/grant-table.c
> +++ b/drivers/xen/grant-table.c
> @@ -464,9 +464,12 @@ int gnttab_map_refs(struct gnttab_map_grant_ref *map_ops,
>  
>  	for (i = 0; i < count; i++) {
>  		/* Do not add to override if the map failed. */
> -		if (map_ops[i].status)
> +		if (map_ops[i].status != GNTST_okay && map_ops[i].status != GNTST_eagain)
>  			continue;
>  
> +		if (map_ops[i].status == GNTST_eagain)
> +			return -EAGAIN;
> +
>  		if (map_ops[i].flags & GNTMAP_contains_pte) {
>  			pte = (pte_t *) (mfn_to_virt(PFN_DOWN(map_ops[i].host_addr)) +
>  				(map_ops[i].host_addr & ~PAGE_MASK));
> @@ -565,7 +568,7 @@ static int gnttab_map(unsigned int start_idx, unsigned int end_idx)
>  		return -ENOSYS;
>  	}
>  
> -	BUG_ON(rc || setup.status);
> +	BUG_ON(rc || (setup.status != GNTST_okay));
>  
>  	rc = arch_gnttab_map_shared(frames, nr_gframes, gnttab_max_grant_frames(),
>  				    &shared);
> diff --git a/drivers/xen/xenbus/xenbus_client.c b/drivers/xen/xenbus/xenbus_client.c
> index 1906125..d123c78 100644
> --- a/drivers/xen/xenbus/xenbus_client.c
> +++ b/drivers/xen/xenbus/xenbus_client.c
> @@ -455,6 +455,8 @@ int xenbus_map_ring_valloc(struct xenbus_device *dev, int gnt_ref, void **vaddr)
>  	if (HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, &op, 1))
>  		BUG();
>  
> +	if (op.status == GNTST_eagain)
> +		gnttab_check_GNTST_eagain_do_while(GNTTABOP_map_grant_ref, (&op));
>  	if (op.status != GNTST_okay) {
>  		free_vm_area(area);
>  		xenbus_dev_fatal(dev, op.status,
> @@ -499,6 +501,8 @@ int xenbus_map_ring(struct xenbus_device *dev, int gnt_ref,
>  	if (HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, &op, 1))
>  		BUG();
>  
> +	if (op.status == GNTST_eagain)
> +		gnttab_check_GNTST_eagain_do_while(GNTTABOP_map_grant_ref, (&op));
>  	if (op.status != GNTST_okay) {
>  		xenbus_dev_fatal(dev, op.status,
>  				 "mapping in shared page %d from domain %d",
> diff --git a/include/xen/grant_table.h b/include/xen/grant_table.h
> index 11e2dfc..46fac85 100644
> --- a/include/xen/grant_table.h
> +++ b/include/xen/grant_table.h
> @@ -37,6 +37,8 @@
>  #ifndef __ASM_GNTTAB_H__
>  #define __ASM_GNTTAB_H__
>  
> +#include <linux/delay.h>
> +
>  #include <asm/page.h>
>  
>  #include <xen/interface/xen.h>
> @@ -160,4 +162,41 @@ int gnttab_map_refs(struct gnttab_map_grant_ref *map_ops,
>  int gnttab_unmap_refs(struct gnttab_unmap_grant_ref *unmap_ops,
>  		      struct page **pages, unsigned int count);
>  
> +#define gnttab_check_GNTST_eagain_while(__HCop, __HCarg_p)					\

So why does this have to be a macro? What is the advantage of that
versus making this a function?

> +do {																		\
> +	u8 __hc_delay = 1;														\
> +	int __ret;																\
> +	while (unlikely((__HCarg_p)->status == GNTST_eagain && __hc_delay)) {	\
> +		msleep(__hc_delay++);												\

Ugh. Not sure what happend to this, but there are tons of '\' at the
end.

So why msleep? Why not go for a proper yield? Call the safe_halt()
function?

> +		__ret = HYPERVISOR_grant_table_op(__HCop, (__HCarg_p), 1);			\
> +		BUG_ON(__ret);														\
> +	}																		\
> +	if (__hc_delay == 0) {													\

So this would happen if we rolled over __hc_delay, so did this more than
255 times? Presumarily this can happen if the swapper in dom0 crashes..

I would recommend you use 'WARN' here and include tons of details.
This is a pretty serious issues, is it not?

> +		printk(KERN_ERR "%s: gnt busy\n", __func__,);						\
> +		(__HCarg_p)->status = GNTST_bad_page;								\
> +	}																		\
> +	if ((__HCarg_p)->status != GNTST_okay)									\
> +		printk(KERN_ERR "%s: gnt status %x\n", 								\
> +			__func__, (__HCarg_p)->status);									\

Use GNTTABOP_error_msgs. Also should we continue? What is the
impact if we do continue? The times this is hit is if the status
is not GNTS_okay and if it is not GNTS_eagain - so what are the
situations in which this happens and what can the domain do
to recover? Should there be some helpfull message instead of
just "gnt status: X" ?

> +} while(0)
> +
> +#define gnttab_check_GNTST_eagain_do_while(__HCop, __HCarg_p)			\
> +do {																	\
> +	u8 __hc_delay = 1;													\
> +	int __ret;															\
> +	do {																\
> +		__ret = HYPERVISOR_grant_table_op(__HCop, (__HCarg_p), 1);		\
> +		BUG_ON(__ret);													\
> +		if ((__HCarg_p)->status == GNTST_eagain)						\
> +			msleep(__hc_delay++);										\
> +	} while ((__HCarg_p)->status == GNTST_eagain && __hc_delay);		\
> +	if (__hc_delay == 0) {												\
> +		printk(KERN_ERR "%s: gnt busy\n", __func__);					\
> +		(__HCarg_p)->status = GNTST_bad_page;							\
> +	}																	\
> +	if ((__HCarg_p)->status != GNTST_okay)								\
> +		printk(KERN_ERR "%s: gnt status %x\n", 							\
> +			__func__, (__HCarg_p)->status);								\
> +} while(0)
> +
>  #endif /* __ASM_GNTTAB_H__ */
> diff --git a/include/xen/interface/grant_table.h b/include/xen/interface/grant_table.h
> index 39e5717..ba04080 100644
> --- a/include/xen/interface/grant_table.h
> +++ b/include/xen/interface/grant_table.h
> @@ -363,6 +363,8 @@ DEFINE_GUEST_HANDLE_STRUCT(gnttab_query_size);
>  #define GNTST_permission_denied (-8) /* Not enough privilege for operation.  */
>  #define GNTST_bad_page         (-9) /* Specified page was invalid for op.    */
>  #define GNTST_bad_copy_arg    (-10) /* copy arguments cross page boundary */
> +#define GNTST_address_too_big (-11) /* transfer page address too large.      */
> +#define GNTST_eagain          (-12) /* Could not map at the moment. Retry.   */
>  
>  #define GNTTABOP_error_msgs {                   \
>      "okay",                                     \
> @@ -375,7 +377,9 @@ DEFINE_GUEST_HANDLE_STRUCT(gnttab_query_size);
>      "no spare translation slot in the I/O MMU", \
>      "permission denied",                        \
>      "bad page",                                 \
> -    "copy arguments cross page boundary"        \
> +    "copy arguments cross page boundary",       \
> +    "page address size too large",              \
> +    "could not map at the moment, retry"        \
>  }
>  
>  #endif /* __XEN_PUBLIC_GRANT_TABLE_H__ */
> -- 
> 1.6.2.5
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Dec 17 14:40:47 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 17 Dec 2011 14:40:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbvQx-0002At-2c; Sat, 17 Dec 2011 14:40:19 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.r.wilk@gmail.com>) id 1RbvQw-0002Al-60
	for xen-devel@lists.xensource.com; Sat, 17 Dec 2011 14:40:18 +0000
X-Env-Sender: konrad.r.wilk@gmail.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1324132808!8341340!1
X-Originating-IP: [209.85.216.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15574 invoked from network); 17 Dec 2011 14:40:10 -0000
Received: from mail-qw0-f43.google.com (HELO mail-qw0-f43.google.com)
	(209.85.216.43)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Dec 2011 14:40:10 -0000
Received: by qabg27 with SMTP id g27so11433648qab.9
	for <xen-devel@lists.xensource.com>;
	Sat, 17 Dec 2011 06:40:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:date:from:to:cc:subject:message-id:references:mime-version
	:content-type:content-disposition:in-reply-to:user-agent;
	bh=hRHDXE9FZ2PS20jgbQLXryaxwaElKqhs7Vl10Nowhco=;
	b=UhxSif9BccRWJvwDeKvKMbSgRMyUzgQtskuVQltEFCxZ3dmv6EkN5qVhO758NDNger
	woYBfFawlgKK4jmgIFU5xNXbUlTVAxx8T2JYwM+Pb3upRe3rxVufMW0lgh6pNbGtTz3v
	+FabXGUSkRbhF5v6MXGM04vEVrC3oL1AriNeI=
Received: by 10.224.33.202 with SMTP id i10mr17324894qad.91.1324132807578;
	Sat, 17 Dec 2011 06:40:07 -0800 (PST)
Received: from konrad-lan (209-6-85-33.c3-0.smr-ubr2.sbo-smr.ma.cable.rcn.com.
	[209.6.85.33])
	by mx.google.com with ESMTPS id dj9sm26649293qab.18.2011.12.17.06.40.06
	(version=TLSv1/SSLv3 cipher=OTHER);
	Sat, 17 Dec 2011 06:40:07 -0800 (PST)
Date: Sat, 17 Dec 2011 09:40:04 -0500
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Adin Scannell <adin@scannell.ca>
Message-ID: <20111217144003.GE14816@konrad-lan>
References: <1324092141-9730-1-git-send-email-adin@scannell.ca>
	<1324092141-9730-4-git-send-email-adin@scannell.ca>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1324092141-9730-4-git-send-email-adin@scannell.ca>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com, olaf@aepfle.de,
	JBeulich@suse.com, adin@gridcentric.com
Subject: Re: [Xen-devel] [PATCH 3/3] Port of mmap_batch_v2 to support paging
	in Xen
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Dec 16, 2011 at 10:22:21PM -0500, Adin Scannell wrote:
> This wasn't ported from any patch, but was rewritten based on the XCP 2.6.32
> tree.  The code structure is significantly different and this patch mirrors the
> existing Linux code.
> 
> The primary reason for need the V2 interface is to support foreign mappings
> (i.e. qemu) of paged-out pages.  The libxc code will already retry mappings
> when an ENOENT is returned.  The V2 interface provides a richer error value,
> so the user-space code is capable of handling these errors specifically.

Can you give more details on how to use paged-out pages. Perhaps a
pointer to the xen's docs?

> 
> Signed-off-by: Adin Scannell <adin@scannell.ca>
> 
> Index: linux/drivers/xen/xenfs/privcmd.c
> ===================================================================
> ---
>  drivers/xen/xenfs/privcmd.c |   90 ++++++++++++++++++++++++++++++++++++++++++-

So that file just moved to drivers/xen/privcmd.c

>  include/xen/privcmd.h       |   10 +++++
>  2 files changed, 99 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/xen/xenfs/privcmd.c b/drivers/xen/xenfs/privcmd.c
> index dbd3b16..21cbb5a 100644
> --- a/drivers/xen/xenfs/privcmd.c
> +++ b/drivers/xen/xenfs/privcmd.c
> @@ -70,7 +70,7 @@ static void free_page_list(struct list_head *pages)
>   */
>  static int gather_array(struct list_head *pagelist,
>  			unsigned nelem, size_t size,
> -			void __user *data)
> +			const void __user *data)
>  {
>  	unsigned pageidx;
>  	void *pagedata;
> @@ -245,6 +245,15 @@ struct mmap_batch_state {
>  	xen_pfn_t __user *user;
>  };
>  
> +struct mmap_batch_v2_state {
> +	domid_t domain;
> +	unsigned long va;
> +	struct vm_area_struct *vma;
> +	int paged_out;

Should this be unsigned int?
> +
> +	int __user *err;
> +};
> +
>  static int mmap_batch_fn(void *data, void *state)
>  {
>  	xen_pfn_t *mfnp = data;
> @@ -260,6 +269,20 @@ static int mmap_batch_fn(void *data, void *state)
>  	return 0;
>  }
>  
> +static int mmap_batch_v2_fn(void *data, void *state)
> +{
> +	xen_pfn_t *mfnp = data;
> +	struct mmap_batch_v2_state *st = state;
> +
> +	int rc = xen_remap_domain_mfn_range(st->vma, st->va & PAGE_MASK, *mfnp, 1,
> +				       st->vma->vm_page_prot, st->domain);

You don't want to check that st is not NULL?

> +	if ( rc == -ENOENT )

This is the wrong style. Please fix.

> +		st->paged_out++;

Is it possible that this ends overflowing and hitting 0?

> +	st->va += PAGE_SIZE;
> +
> +	return put_user(rc, st->err++);
> +}
> +
>  static int mmap_return_errors(void *data, void *state)
>  {
>  	xen_pfn_t *mfnp = data;
> @@ -332,6 +355,67 @@ out:
>  	return ret;
>  }
>  
> +static long privcmd_ioctl_mmap_batch_v2(void __user *udata)
> +{
> +	int ret;
> +	struct privcmd_mmapbatch_v2 m;
> +	struct mm_struct *mm = current->mm;
> +	struct vm_area_struct *vma = NULL;
> +	unsigned long nr_pages;
> +	LIST_HEAD(pagelist);
> +	struct mmap_batch_v2_state state;
> +
> +	if (!xen_initial_domain())
> +		return -EPERM;
> +
> +	if (copy_from_user(&m, udata, sizeof(m)))
> +		return -EFAULT;
> +
> +	nr_pages = m.num;
> +	if ((m.num <= 0) || (nr_pages > (ULONG_MAX >> PAGE_SHIFT)))

Just make it nr_pages instead of m.num.

> +		return -EINVAL;
> +
> +	ret = gather_array(&pagelist, m.num, sizeof(xen_pfn_t),


nr_pages.
> +			   m.arr);
> +
> +	if (ret || list_empty(&pagelist))
> +		goto out;
> +
> +	down_write(&mm->mmap_sem);
> +
> +	vma = find_vma(mm, m.addr);
> +	ret = -EINVAL;
> +	/* We allow multiple shots here, because this interface
> +	 * is used by libxc and mappings for specific pages will
> +	 * be retried when pages are paged-out (ENOENT). */
> +	if (!vma ||
> +	    vma->vm_ops != &privcmd_vm_ops ||
> +	    (m.addr < vma->vm_start) ||
> +	    ((m.addr + (nr_pages << PAGE_SHIFT)) > vma->vm_end)) {
> +		up_write(&mm->mmap_sem);
> +		goto out;
> +	}
> +
> +	state.domain = m.dom;

Should you check the m.dom for incorrect ones? Like -1? or DOMID_IO?

> +	state.vma = vma;
> +	state.va = m.addr;
> +	state.err = m.err;
> +	state.paged_out = 0;
> +
> +	up_write(&mm->mmap_sem);
> +
> +	ret = traverse_pages(m.num, sizeof(xen_pfn_t),
> +			     &pagelist, mmap_batch_v2_fn, &state);
> +
> +out:
> +	free_page_list(&pagelist);
> +
> +	if ( (ret == 0) && (state.paged_out > 0) )
> +		return -ENOENT;
> +        else
> +		return ret;
> +}
> +
>  static long privcmd_ioctl(struct file *file,
>  			  unsigned int cmd, unsigned long data)
>  {
> @@ -351,6 +435,10 @@ static long privcmd_ioctl(struct file *file,
>  		ret = privcmd_ioctl_mmap_batch(udata);
>  		break;
>  
> +	case IOCTL_PRIVCMD_MMAPBATCH_V2:
> +		ret = privcmd_ioctl_mmap_batch_v2(udata);
> +		break;
> +
>  	default:
>  		ret = -EINVAL;
>  		break;
> diff --git a/include/xen/privcmd.h b/include/xen/privcmd.h
> index 17857fb..39b92b1 100644
> --- a/include/xen/privcmd.h
> +++ b/include/xen/privcmd.h
> @@ -62,6 +62,14 @@ struct privcmd_mmapbatch {
>  	xen_pfn_t __user *arr; /* array of mfns - top nibble set on err */
>  };
>  
> +struct privcmd_mmapbatch_v2 {
> +	int num;          /* number of pages to populate */
> +	domid_t dom;      /* target domain */
> +	__u64 addr;       /* virtual address */
> +	const xen_pfn_t __user *arr; /* array of mfns */
> +	int __user *err;  /* array of error codes */
> +};
> +
>  /*
>   * @cmd: IOCTL_PRIVCMD_HYPERCALL
>   * @arg: &privcmd_hypercall_t
> @@ -73,5 +81,7 @@ struct privcmd_mmapbatch {
>  	_IOC(_IOC_NONE, 'P', 2, sizeof(struct privcmd_mmap))
>  #define IOCTL_PRIVCMD_MMAPBATCH					\
>  	_IOC(_IOC_NONE, 'P', 3, sizeof(struct privcmd_mmapbatch))
> +#define IOCTL_PRIVCMD_MMAPBATCH_V2				\
> +	_IOC(_IOC_NONE, 'P', 4, sizeof(struct privcmd_mmapbatch_v2))
>  
>  #endif /* __LINUX_PUBLIC_PRIVCMD_H__ */
> -- 
> 1.6.2.5
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Dec 17 14:40:47 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 17 Dec 2011 14:40:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbvQx-0002At-2c; Sat, 17 Dec 2011 14:40:19 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.r.wilk@gmail.com>) id 1RbvQw-0002Al-60
	for xen-devel@lists.xensource.com; Sat, 17 Dec 2011 14:40:18 +0000
X-Env-Sender: konrad.r.wilk@gmail.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1324132808!8341340!1
X-Originating-IP: [209.85.216.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15574 invoked from network); 17 Dec 2011 14:40:10 -0000
Received: from mail-qw0-f43.google.com (HELO mail-qw0-f43.google.com)
	(209.85.216.43)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Dec 2011 14:40:10 -0000
Received: by qabg27 with SMTP id g27so11433648qab.9
	for <xen-devel@lists.xensource.com>;
	Sat, 17 Dec 2011 06:40:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:date:from:to:cc:subject:message-id:references:mime-version
	:content-type:content-disposition:in-reply-to:user-agent;
	bh=hRHDXE9FZ2PS20jgbQLXryaxwaElKqhs7Vl10Nowhco=;
	b=UhxSif9BccRWJvwDeKvKMbSgRMyUzgQtskuVQltEFCxZ3dmv6EkN5qVhO758NDNger
	woYBfFawlgKK4jmgIFU5xNXbUlTVAxx8T2JYwM+Pb3upRe3rxVufMW0lgh6pNbGtTz3v
	+FabXGUSkRbhF5v6MXGM04vEVrC3oL1AriNeI=
Received: by 10.224.33.202 with SMTP id i10mr17324894qad.91.1324132807578;
	Sat, 17 Dec 2011 06:40:07 -0800 (PST)
Received: from konrad-lan (209-6-85-33.c3-0.smr-ubr2.sbo-smr.ma.cable.rcn.com.
	[209.6.85.33])
	by mx.google.com with ESMTPS id dj9sm26649293qab.18.2011.12.17.06.40.06
	(version=TLSv1/SSLv3 cipher=OTHER);
	Sat, 17 Dec 2011 06:40:07 -0800 (PST)
Date: Sat, 17 Dec 2011 09:40:04 -0500
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Adin Scannell <adin@scannell.ca>
Message-ID: <20111217144003.GE14816@konrad-lan>
References: <1324092141-9730-1-git-send-email-adin@scannell.ca>
	<1324092141-9730-4-git-send-email-adin@scannell.ca>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1324092141-9730-4-git-send-email-adin@scannell.ca>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com, olaf@aepfle.de,
	JBeulich@suse.com, adin@gridcentric.com
Subject: Re: [Xen-devel] [PATCH 3/3] Port of mmap_batch_v2 to support paging
	in Xen
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Dec 16, 2011 at 10:22:21PM -0500, Adin Scannell wrote:
> This wasn't ported from any patch, but was rewritten based on the XCP 2.6.32
> tree.  The code structure is significantly different and this patch mirrors the
> existing Linux code.
> 
> The primary reason for need the V2 interface is to support foreign mappings
> (i.e. qemu) of paged-out pages.  The libxc code will already retry mappings
> when an ENOENT is returned.  The V2 interface provides a richer error value,
> so the user-space code is capable of handling these errors specifically.

Can you give more details on how to use paged-out pages. Perhaps a
pointer to the xen's docs?

> 
> Signed-off-by: Adin Scannell <adin@scannell.ca>
> 
> Index: linux/drivers/xen/xenfs/privcmd.c
> ===================================================================
> ---
>  drivers/xen/xenfs/privcmd.c |   90 ++++++++++++++++++++++++++++++++++++++++++-

So that file just moved to drivers/xen/privcmd.c

>  include/xen/privcmd.h       |   10 +++++
>  2 files changed, 99 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/xen/xenfs/privcmd.c b/drivers/xen/xenfs/privcmd.c
> index dbd3b16..21cbb5a 100644
> --- a/drivers/xen/xenfs/privcmd.c
> +++ b/drivers/xen/xenfs/privcmd.c
> @@ -70,7 +70,7 @@ static void free_page_list(struct list_head *pages)
>   */
>  static int gather_array(struct list_head *pagelist,
>  			unsigned nelem, size_t size,
> -			void __user *data)
> +			const void __user *data)
>  {
>  	unsigned pageidx;
>  	void *pagedata;
> @@ -245,6 +245,15 @@ struct mmap_batch_state {
>  	xen_pfn_t __user *user;
>  };
>  
> +struct mmap_batch_v2_state {
> +	domid_t domain;
> +	unsigned long va;
> +	struct vm_area_struct *vma;
> +	int paged_out;

Should this be unsigned int?
> +
> +	int __user *err;
> +};
> +
>  static int mmap_batch_fn(void *data, void *state)
>  {
>  	xen_pfn_t *mfnp = data;
> @@ -260,6 +269,20 @@ static int mmap_batch_fn(void *data, void *state)
>  	return 0;
>  }
>  
> +static int mmap_batch_v2_fn(void *data, void *state)
> +{
> +	xen_pfn_t *mfnp = data;
> +	struct mmap_batch_v2_state *st = state;
> +
> +	int rc = xen_remap_domain_mfn_range(st->vma, st->va & PAGE_MASK, *mfnp, 1,
> +				       st->vma->vm_page_prot, st->domain);

You don't want to check that st is not NULL?

> +	if ( rc == -ENOENT )

This is the wrong style. Please fix.

> +		st->paged_out++;

Is it possible that this ends overflowing and hitting 0?

> +	st->va += PAGE_SIZE;
> +
> +	return put_user(rc, st->err++);
> +}
> +
>  static int mmap_return_errors(void *data, void *state)
>  {
>  	xen_pfn_t *mfnp = data;
> @@ -332,6 +355,67 @@ out:
>  	return ret;
>  }
>  
> +static long privcmd_ioctl_mmap_batch_v2(void __user *udata)
> +{
> +	int ret;
> +	struct privcmd_mmapbatch_v2 m;
> +	struct mm_struct *mm = current->mm;
> +	struct vm_area_struct *vma = NULL;
> +	unsigned long nr_pages;
> +	LIST_HEAD(pagelist);
> +	struct mmap_batch_v2_state state;
> +
> +	if (!xen_initial_domain())
> +		return -EPERM;
> +
> +	if (copy_from_user(&m, udata, sizeof(m)))
> +		return -EFAULT;
> +
> +	nr_pages = m.num;
> +	if ((m.num <= 0) || (nr_pages > (ULONG_MAX >> PAGE_SHIFT)))

Just make it nr_pages instead of m.num.

> +		return -EINVAL;
> +
> +	ret = gather_array(&pagelist, m.num, sizeof(xen_pfn_t),


nr_pages.
> +			   m.arr);
> +
> +	if (ret || list_empty(&pagelist))
> +		goto out;
> +
> +	down_write(&mm->mmap_sem);
> +
> +	vma = find_vma(mm, m.addr);
> +	ret = -EINVAL;
> +	/* We allow multiple shots here, because this interface
> +	 * is used by libxc and mappings for specific pages will
> +	 * be retried when pages are paged-out (ENOENT). */
> +	if (!vma ||
> +	    vma->vm_ops != &privcmd_vm_ops ||
> +	    (m.addr < vma->vm_start) ||
> +	    ((m.addr + (nr_pages << PAGE_SHIFT)) > vma->vm_end)) {
> +		up_write(&mm->mmap_sem);
> +		goto out;
> +	}
> +
> +	state.domain = m.dom;

Should you check the m.dom for incorrect ones? Like -1? or DOMID_IO?

> +	state.vma = vma;
> +	state.va = m.addr;
> +	state.err = m.err;
> +	state.paged_out = 0;
> +
> +	up_write(&mm->mmap_sem);
> +
> +	ret = traverse_pages(m.num, sizeof(xen_pfn_t),
> +			     &pagelist, mmap_batch_v2_fn, &state);
> +
> +out:
> +	free_page_list(&pagelist);
> +
> +	if ( (ret == 0) && (state.paged_out > 0) )
> +		return -ENOENT;
> +        else
> +		return ret;
> +}
> +
>  static long privcmd_ioctl(struct file *file,
>  			  unsigned int cmd, unsigned long data)
>  {
> @@ -351,6 +435,10 @@ static long privcmd_ioctl(struct file *file,
>  		ret = privcmd_ioctl_mmap_batch(udata);
>  		break;
>  
> +	case IOCTL_PRIVCMD_MMAPBATCH_V2:
> +		ret = privcmd_ioctl_mmap_batch_v2(udata);
> +		break;
> +
>  	default:
>  		ret = -EINVAL;
>  		break;
> diff --git a/include/xen/privcmd.h b/include/xen/privcmd.h
> index 17857fb..39b92b1 100644
> --- a/include/xen/privcmd.h
> +++ b/include/xen/privcmd.h
> @@ -62,6 +62,14 @@ struct privcmd_mmapbatch {
>  	xen_pfn_t __user *arr; /* array of mfns - top nibble set on err */
>  };
>  
> +struct privcmd_mmapbatch_v2 {
> +	int num;          /* number of pages to populate */
> +	domid_t dom;      /* target domain */
> +	__u64 addr;       /* virtual address */
> +	const xen_pfn_t __user *arr; /* array of mfns */
> +	int __user *err;  /* array of error codes */
> +};
> +
>  /*
>   * @cmd: IOCTL_PRIVCMD_HYPERCALL
>   * @arg: &privcmd_hypercall_t
> @@ -73,5 +81,7 @@ struct privcmd_mmapbatch {
>  	_IOC(_IOC_NONE, 'P', 2, sizeof(struct privcmd_mmap))
>  #define IOCTL_PRIVCMD_MMAPBATCH					\
>  	_IOC(_IOC_NONE, 'P', 3, sizeof(struct privcmd_mmapbatch))
> +#define IOCTL_PRIVCMD_MMAPBATCH_V2				\
> +	_IOC(_IOC_NONE, 'P', 4, sizeof(struct privcmd_mmapbatch_v2))
>  
>  #endif /* __LINUX_PUBLIC_PRIVCMD_H__ */
> -- 
> 1.6.2.5
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Dec 17 16:52:27 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 17 Dec 2011 16:52:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbxU5-0003Q3-4Z; Sat, 17 Dec 2011 16:51:41 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <amscanne@gridcentric.ca>) id 1RbxU3-0003Py-Ay
	for xen-devel@lists.xensource.com; Sat, 17 Dec 2011 16:51:39 +0000
X-Env-Sender: amscanne@gridcentric.ca
X-Msg-Ref: server-15.tower-21.messagelabs.com!1324140692!8618153!1
X-Originating-IP: [209.85.212.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10030 invoked from network); 17 Dec 2011 16:51:32 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Dec 2011 16:51:32 -0000
Received: by wico1 with SMTP id o1so1008497wic.30
	for <xen-devel@lists.xensource.com>;
	Sat, 17 Dec 2011 08:51:32 -0800 (PST)
Received: by 10.216.137.232 with SMTP id y82mr2402505wei.0.1324140692480; Sat,
	17 Dec 2011 08:51:32 -0800 (PST)
MIME-Version: 1.0
Received: by 10.223.120.68 with HTTP; Sat, 17 Dec 2011 08:51:11 -0800 (PST)
In-Reply-To: <20111217144003.GE14816@konrad-lan>
References: <1324092141-9730-1-git-send-email-adin@scannell.ca>
	<1324092141-9730-4-git-send-email-adin@scannell.ca>
	<20111217144003.GE14816@konrad-lan>
From: Adin Scannell <adin@gridcentric.com>
Date: Sat, 17 Dec 2011 11:51:11 -0500
X-Google-Sender-Auth: 6XIgalpeDn7Bfq2Tr_nV61ghPnQ
Message-ID: <CAAJKtqrcMv+XfN_-X8O-FqbifOZOqp8i3FQa5qPg+05-PiZtqg@mail.gmail.com>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
Cc: olaf@aepfle.de, xen-devel@lists.xensource.com,
	Adin Scannell <adin@scannell.ca>, konrad.wilk@oracle.com,
	andres@gridcentric.ca, JBeulich@suse.com
Subject: Re: [Xen-devel] [PATCH 3/3] Port of mmap_batch_v2 to support paging
	in Xen
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi Konrad,

Thanks for the quick turnaround. I'll incorporate your feedback and
resend. Some NOTES are inline below.

On Sat, Dec 17, 2011 at 9:40 AM, Konrad Rzeszutek Wilk
<konrad@darnok.org> wrote:
> On Fri, Dec 16, 2011 at 10:22:21PM -0500, Adin Scannell wrote:
>> This wasn't ported from any patch, but was rewritten based on the XCP 2.=
6.32
>> tree. =A0The code structure is significantly different and this patch mi=
rrors the
>> existing Linux code.
>>
>> The primary reason for need the V2 interface is to support foreign mappi=
ngs
>> (i.e. qemu) of paged-out pages. =A0The libxc code will already retry map=
pings
>> when an ENOENT is returned. =A0The V2 interface provides a richer error =
value,
>> so the user-space code is capable of handling these errors specifically.
>
> Can you give more details on how to use paged-out pages. Perhaps a
> pointer to the xen's docs?

Hrm, in usual fashion the docs are a bit lacking.

Simply: the kernel has to do nothing to support paging (other than the
backend drivers which need to handle the grant EAGAIN case -- other
patch).  The only reason the V2 interface is needed here is to pass
back full error codes from the mmu_update()'s. Xen and libxc have a
mutual understanding that when you receive an ENOENT error code, you
back off and try again.

>>
>> Signed-off-by: Adin Scannell <adin@scannell.ca>
>>
>> Index: linux/drivers/xen/xenfs/privcmd.c
>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>> ---
>> =A0drivers/xen/xenfs/privcmd.c | =A0 90 ++++++++++++++++++++++++++++++++=
++++++++++-
>
> So that file just moved to drivers/xen/privcmd.c

Of course it has :)

>> =A0include/xen/privcmd.h =A0 =A0 =A0 | =A0 10 +++++
>> =A02 files changed, 99 insertions(+), 1 deletions(-)
>>
>> diff --git a/drivers/xen/xenfs/privcmd.c b/drivers/xen/xenfs/privcmd.c
>> index dbd3b16..21cbb5a 100644
>> --- a/drivers/xen/xenfs/privcmd.c
>> +++ b/drivers/xen/xenfs/privcmd.c
>> @@ -70,7 +70,7 @@ static void free_page_list(struct list_head *pages)
>> =A0 */
>> =A0static int gather_array(struct list_head *pagelist,
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 unsigned nelem, size_t size,
>> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 void __user *data)
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 const void __user *data)
>> =A0{
>> =A0 =A0 =A0 unsigned pageidx;
>> =A0 =A0 =A0 void *pagedata;
>> @@ -245,6 +245,15 @@ struct mmap_batch_state {
>> =A0 =A0 =A0 xen_pfn_t __user *user;
>> =A0};
>>
>> +struct mmap_batch_v2_state {
>> + =A0 =A0 domid_t domain;
>> + =A0 =A0 unsigned long va;
>> + =A0 =A0 struct vm_area_struct *vma;
>> + =A0 =A0 int paged_out;
>
> Should this be unsigned int?

Noted below.

>> +
>> + =A0 =A0 int __user *err;
>> +};
>> +
>> =A0static int mmap_batch_fn(void *data, void *state)
>> =A0{
>> =A0 =A0 =A0 xen_pfn_t *mfnp =3D data;
>> @@ -260,6 +269,20 @@ static int mmap_batch_fn(void *data, void *state)
>> =A0 =A0 =A0 return 0;
>> =A0}
>>
>> +static int mmap_batch_v2_fn(void *data, void *state)
>> +{
>> + =A0 =A0 xen_pfn_t *mfnp =3D data;
>> + =A0 =A0 struct mmap_batch_v2_state *st =3D state;
>> +
>> + =A0 =A0 int rc =3D xen_remap_domain_mfn_range(st->vma, st->va & PAGE_M=
ASK, *mfnp, 1,
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0st->vma->vm_page_prot, st->domain);
>
> You don't want to check that st is not NULL?

This could be an assertion as it's only used in the
ioctl_mmap_batch_v2 function where it's guaranteed to pass in a
non-null state.

I'll add an additional patch to the queue that adds these assertions
to both mmap_batch_fn and mmap_batch_fn_v2.

>> + =A0 =A0 =A0 =A0 =A0 =A0 st->paged_out++;
> Is it possible that this ends overflowing and hitting 0?

I don't think this is an issue practically, as the only way to trigger
this would be to be on a 64bit machine and map an ungodly number of
pages with a single mmap_batch (MAX_INT).  For correctness though, I
can update this variable and the err variable in mmap_batch_state
which suffers from the same problem -- turn them into unsigned long.
This will be included in the additional patch.

>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0m.arr);
>> +
>> + =A0 =A0 if (ret || list_empty(&pagelist))
>> + =A0 =A0 =A0 =A0 =A0 =A0 goto out;
>> +
>> + =A0 =A0 down_write(&mm->mmap_sem);
>> +
>> + =A0 =A0 vma =3D find_vma(mm, m.addr);
>> + =A0 =A0 ret =3D -EINVAL;
>> + =A0 =A0 /* We allow multiple shots here, because this interface
>> + =A0 =A0 =A0* is used by libxc and mappings for specific pages will
>> + =A0 =A0 =A0* be retried when pages are paged-out (ENOENT). */
>> + =A0 =A0 if (!vma ||
>> + =A0 =A0 =A0 =A0 vma->vm_ops !=3D &privcmd_vm_ops ||
>> + =A0 =A0 =A0 =A0 (m.addr < vma->vm_start) ||
>> + =A0 =A0 =A0 =A0 ((m.addr + (nr_pages << PAGE_SHIFT)) > vma->vm_end)) {
>> + =A0 =A0 =A0 =A0 =A0 =A0 up_write(&mm->mmap_sem);
>> + =A0 =A0 =A0 =A0 =A0 =A0 goto out;
>> + =A0 =A0 }
>> +
>> + =A0 =A0 state.domain =3D m.dom;
>
> Should you check the m.dom for incorrect ones? Like -1? or DOMID_IO?

I followed the example for mmap_batch, which just tries the call and
returns whatever error Xen gives.  I think that's the right approach
for these.

Cheers!
-Adin

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Dec 17 16:52:27 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 17 Dec 2011 16:52:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbxU5-0003Q3-4Z; Sat, 17 Dec 2011 16:51:41 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <amscanne@gridcentric.ca>) id 1RbxU3-0003Py-Ay
	for xen-devel@lists.xensource.com; Sat, 17 Dec 2011 16:51:39 +0000
X-Env-Sender: amscanne@gridcentric.ca
X-Msg-Ref: server-15.tower-21.messagelabs.com!1324140692!8618153!1
X-Originating-IP: [209.85.212.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10030 invoked from network); 17 Dec 2011 16:51:32 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Dec 2011 16:51:32 -0000
Received: by wico1 with SMTP id o1so1008497wic.30
	for <xen-devel@lists.xensource.com>;
	Sat, 17 Dec 2011 08:51:32 -0800 (PST)
Received: by 10.216.137.232 with SMTP id y82mr2402505wei.0.1324140692480; Sat,
	17 Dec 2011 08:51:32 -0800 (PST)
MIME-Version: 1.0
Received: by 10.223.120.68 with HTTP; Sat, 17 Dec 2011 08:51:11 -0800 (PST)
In-Reply-To: <20111217144003.GE14816@konrad-lan>
References: <1324092141-9730-1-git-send-email-adin@scannell.ca>
	<1324092141-9730-4-git-send-email-adin@scannell.ca>
	<20111217144003.GE14816@konrad-lan>
From: Adin Scannell <adin@gridcentric.com>
Date: Sat, 17 Dec 2011 11:51:11 -0500
X-Google-Sender-Auth: 6XIgalpeDn7Bfq2Tr_nV61ghPnQ
Message-ID: <CAAJKtqrcMv+XfN_-X8O-FqbifOZOqp8i3FQa5qPg+05-PiZtqg@mail.gmail.com>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
Cc: olaf@aepfle.de, xen-devel@lists.xensource.com,
	Adin Scannell <adin@scannell.ca>, konrad.wilk@oracle.com,
	andres@gridcentric.ca, JBeulich@suse.com
Subject: Re: [Xen-devel] [PATCH 3/3] Port of mmap_batch_v2 to support paging
	in Xen
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi Konrad,

Thanks for the quick turnaround. I'll incorporate your feedback and
resend. Some NOTES are inline below.

On Sat, Dec 17, 2011 at 9:40 AM, Konrad Rzeszutek Wilk
<konrad@darnok.org> wrote:
> On Fri, Dec 16, 2011 at 10:22:21PM -0500, Adin Scannell wrote:
>> This wasn't ported from any patch, but was rewritten based on the XCP 2.=
6.32
>> tree. =A0The code structure is significantly different and this patch mi=
rrors the
>> existing Linux code.
>>
>> The primary reason for need the V2 interface is to support foreign mappi=
ngs
>> (i.e. qemu) of paged-out pages. =A0The libxc code will already retry map=
pings
>> when an ENOENT is returned. =A0The V2 interface provides a richer error =
value,
>> so the user-space code is capable of handling these errors specifically.
>
> Can you give more details on how to use paged-out pages. Perhaps a
> pointer to the xen's docs?

Hrm, in usual fashion the docs are a bit lacking.

Simply: the kernel has to do nothing to support paging (other than the
backend drivers which need to handle the grant EAGAIN case -- other
patch).  The only reason the V2 interface is needed here is to pass
back full error codes from the mmu_update()'s. Xen and libxc have a
mutual understanding that when you receive an ENOENT error code, you
back off and try again.

>>
>> Signed-off-by: Adin Scannell <adin@scannell.ca>
>>
>> Index: linux/drivers/xen/xenfs/privcmd.c
>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>> ---
>> =A0drivers/xen/xenfs/privcmd.c | =A0 90 ++++++++++++++++++++++++++++++++=
++++++++++-
>
> So that file just moved to drivers/xen/privcmd.c

Of course it has :)

>> =A0include/xen/privcmd.h =A0 =A0 =A0 | =A0 10 +++++
>> =A02 files changed, 99 insertions(+), 1 deletions(-)
>>
>> diff --git a/drivers/xen/xenfs/privcmd.c b/drivers/xen/xenfs/privcmd.c
>> index dbd3b16..21cbb5a 100644
>> --- a/drivers/xen/xenfs/privcmd.c
>> +++ b/drivers/xen/xenfs/privcmd.c
>> @@ -70,7 +70,7 @@ static void free_page_list(struct list_head *pages)
>> =A0 */
>> =A0static int gather_array(struct list_head *pagelist,
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 unsigned nelem, size_t size,
>> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 void __user *data)
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 const void __user *data)
>> =A0{
>> =A0 =A0 =A0 unsigned pageidx;
>> =A0 =A0 =A0 void *pagedata;
>> @@ -245,6 +245,15 @@ struct mmap_batch_state {
>> =A0 =A0 =A0 xen_pfn_t __user *user;
>> =A0};
>>
>> +struct mmap_batch_v2_state {
>> + =A0 =A0 domid_t domain;
>> + =A0 =A0 unsigned long va;
>> + =A0 =A0 struct vm_area_struct *vma;
>> + =A0 =A0 int paged_out;
>
> Should this be unsigned int?

Noted below.

>> +
>> + =A0 =A0 int __user *err;
>> +};
>> +
>> =A0static int mmap_batch_fn(void *data, void *state)
>> =A0{
>> =A0 =A0 =A0 xen_pfn_t *mfnp =3D data;
>> @@ -260,6 +269,20 @@ static int mmap_batch_fn(void *data, void *state)
>> =A0 =A0 =A0 return 0;
>> =A0}
>>
>> +static int mmap_batch_v2_fn(void *data, void *state)
>> +{
>> + =A0 =A0 xen_pfn_t *mfnp =3D data;
>> + =A0 =A0 struct mmap_batch_v2_state *st =3D state;
>> +
>> + =A0 =A0 int rc =3D xen_remap_domain_mfn_range(st->vma, st->va & PAGE_M=
ASK, *mfnp, 1,
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0st->vma->vm_page_prot, st->domain);
>
> You don't want to check that st is not NULL?

This could be an assertion as it's only used in the
ioctl_mmap_batch_v2 function where it's guaranteed to pass in a
non-null state.

I'll add an additional patch to the queue that adds these assertions
to both mmap_batch_fn and mmap_batch_fn_v2.

>> + =A0 =A0 =A0 =A0 =A0 =A0 st->paged_out++;
> Is it possible that this ends overflowing and hitting 0?

I don't think this is an issue practically, as the only way to trigger
this would be to be on a 64bit machine and map an ungodly number of
pages with a single mmap_batch (MAX_INT).  For correctness though, I
can update this variable and the err variable in mmap_batch_state
which suffers from the same problem -- turn them into unsigned long.
This will be included in the additional patch.

>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0m.arr);
>> +
>> + =A0 =A0 if (ret || list_empty(&pagelist))
>> + =A0 =A0 =A0 =A0 =A0 =A0 goto out;
>> +
>> + =A0 =A0 down_write(&mm->mmap_sem);
>> +
>> + =A0 =A0 vma =3D find_vma(mm, m.addr);
>> + =A0 =A0 ret =3D -EINVAL;
>> + =A0 =A0 /* We allow multiple shots here, because this interface
>> + =A0 =A0 =A0* is used by libxc and mappings for specific pages will
>> + =A0 =A0 =A0* be retried when pages are paged-out (ENOENT). */
>> + =A0 =A0 if (!vma ||
>> + =A0 =A0 =A0 =A0 vma->vm_ops !=3D &privcmd_vm_ops ||
>> + =A0 =A0 =A0 =A0 (m.addr < vma->vm_start) ||
>> + =A0 =A0 =A0 =A0 ((m.addr + (nr_pages << PAGE_SHIFT)) > vma->vm_end)) {
>> + =A0 =A0 =A0 =A0 =A0 =A0 up_write(&mm->mmap_sem);
>> + =A0 =A0 =A0 =A0 =A0 =A0 goto out;
>> + =A0 =A0 }
>> +
>> + =A0 =A0 state.domain =3D m.dom;
>
> Should you check the m.dom for incorrect ones? Like -1? or DOMID_IO?

I followed the example for mmap_batch, which just tries the call and
returns whatever error Xen gives.  I think that's the right approach
for these.

Cheers!
-Adin

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Dec 17 16:54:44 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 17 Dec 2011 16:54:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbxWT-0003Uh-MZ; Sat, 17 Dec 2011 16:54:09 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <amscanne@gridcentric.ca>) id 1RbxWS-0003UV-Gt
	for xen-devel@lists.xensource.com; Sat, 17 Dec 2011 16:54:08 +0000
X-Env-Sender: amscanne@gridcentric.ca
X-Msg-Ref: server-6.tower-182.messagelabs.com!1324140842!7668177!1
X-Originating-IP: [74.125.82.41]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24746 invoked from network); 17 Dec 2011 16:54:02 -0000
Received: from mail-ww0-f41.google.com (HELO mail-ww0-f41.google.com)
	(74.125.82.41)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Dec 2011 16:54:02 -0000
Received: by wgbdt12 with SMTP id dt12so5861665wgb.0
	for <xen-devel@lists.xensource.com>;
	Sat, 17 Dec 2011 08:54:02 -0800 (PST)
Received: by 10.180.104.70 with SMTP id gc6mr18277447wib.42.1324140842171;
	Sat, 17 Dec 2011 08:54:02 -0800 (PST)
MIME-Version: 1.0
Received: by 10.223.120.68 with HTTP; Sat, 17 Dec 2011 08:53:40 -0800 (PST)
In-Reply-To: <20111217143015.GD14816@konrad-lan>
References: <1324092141-9730-1-git-send-email-adin@scannell.ca>
	<1324092141-9730-3-git-send-email-adin@scannell.ca>
	<20111217143015.GD14816@konrad-lan>
From: Adin Scannell <adin@gridcentric.com>
Date: Sat, 17 Dec 2011 11:53:40 -0500
X-Google-Sender-Auth: en8JjT9s9zxZro3I4vmie3HYQXw
Message-ID: <CAAJKtqqOH6f1cQn76HWP_cP4Wn-yhw0ePrUgdNb9X5cnbA-O2w@mail.gmail.com>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
Cc: olaf@aepfle.de, xen-devel@lists.xensource.com,
	Adin Scannell <adin@scannell.ca>, konrad.wilk@oracle.com,
	andres@gridcentric.ca, JBeulich@suse.com
Subject: Re: [Xen-devel] [PATCH 2/3] Handle GNTST_eagain in kernel drivers
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Sat, Dec 17, 2011 at 9:30 AM, Konrad Rzeszutek Wilk
<konrad@darnok.org> wrote:
>> +#define gnttab_check_GNTST_eagain_while(__HCop, __HCarg_p) =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 >
> So why does this have to be a macro? What is the advantage of that
> versus making this a function?

I just wanted to minimize changes in the patch from the known XCP
version.  I'm personally not a fan of big macros like this.

> So why msleep? Why not go for a proper yield? Call the safe_halt()
> function?

Yes, this is something that should be revisited.

Since it looks like Daniel's HVM patches are going to conflict with
this anyways, I'll revisit this patch independently from the other two
and see what I can do about making it nicer and addressing the other
bits of feedback you've given.

> Use GNTTABOP_error_msgs. Also should we continue? What is the
> impact if we do continue? The times this is hit is if the status
> is not GNTS_okay and if it is not GNTS_eagain - so what are the
> situations in which this happens and what can the domain do
> to recover? Should there be some helpfull message instead of
> just "gnt status: X" ?

In all the cases this macro is called, the caller still needs to check
op.status and handle any errors appropriately.  The point of the macro
is to reasonably get you from eagain =3D> !eagain, whatever the result
may be.  If I turn this into a function, those semantics will still
apply.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Dec 17 16:54:44 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 17 Dec 2011 16:54:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RbxWT-0003Uh-MZ; Sat, 17 Dec 2011 16:54:09 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <amscanne@gridcentric.ca>) id 1RbxWS-0003UV-Gt
	for xen-devel@lists.xensource.com; Sat, 17 Dec 2011 16:54:08 +0000
X-Env-Sender: amscanne@gridcentric.ca
X-Msg-Ref: server-6.tower-182.messagelabs.com!1324140842!7668177!1
X-Originating-IP: [74.125.82.41]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24746 invoked from network); 17 Dec 2011 16:54:02 -0000
Received: from mail-ww0-f41.google.com (HELO mail-ww0-f41.google.com)
	(74.125.82.41)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Dec 2011 16:54:02 -0000
Received: by wgbdt12 with SMTP id dt12so5861665wgb.0
	for <xen-devel@lists.xensource.com>;
	Sat, 17 Dec 2011 08:54:02 -0800 (PST)
Received: by 10.180.104.70 with SMTP id gc6mr18277447wib.42.1324140842171;
	Sat, 17 Dec 2011 08:54:02 -0800 (PST)
MIME-Version: 1.0
Received: by 10.223.120.68 with HTTP; Sat, 17 Dec 2011 08:53:40 -0800 (PST)
In-Reply-To: <20111217143015.GD14816@konrad-lan>
References: <1324092141-9730-1-git-send-email-adin@scannell.ca>
	<1324092141-9730-3-git-send-email-adin@scannell.ca>
	<20111217143015.GD14816@konrad-lan>
From: Adin Scannell <adin@gridcentric.com>
Date: Sat, 17 Dec 2011 11:53:40 -0500
X-Google-Sender-Auth: en8JjT9s9zxZro3I4vmie3HYQXw
Message-ID: <CAAJKtqqOH6f1cQn76HWP_cP4Wn-yhw0ePrUgdNb9X5cnbA-O2w@mail.gmail.com>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
Cc: olaf@aepfle.de, xen-devel@lists.xensource.com,
	Adin Scannell <adin@scannell.ca>, konrad.wilk@oracle.com,
	andres@gridcentric.ca, JBeulich@suse.com
Subject: Re: [Xen-devel] [PATCH 2/3] Handle GNTST_eagain in kernel drivers
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Sat, Dec 17, 2011 at 9:30 AM, Konrad Rzeszutek Wilk
<konrad@darnok.org> wrote:
>> +#define gnttab_check_GNTST_eagain_while(__HCop, __HCarg_p) =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 >
> So why does this have to be a macro? What is the advantage of that
> versus making this a function?

I just wanted to minimize changes in the patch from the known XCP
version.  I'm personally not a fan of big macros like this.

> So why msleep? Why not go for a proper yield? Call the safe_halt()
> function?

Yes, this is something that should be revisited.

Since it looks like Daniel's HVM patches are going to conflict with
this anyways, I'll revisit this patch independently from the other two
and see what I can do about making it nicer and addressing the other
bits of feedback you've given.

> Use GNTTABOP_error_msgs. Also should we continue? What is the
> impact if we do continue? The times this is hit is if the status
> is not GNTS_okay and if it is not GNTS_eagain - so what are the
> situations in which this happens and what can the domain do
> to recover? Should there be some helpfull message instead of
> just "gnt status: X" ?

In all the cases this macro is called, the caller still needs to check
op.status and handle any errors appropriately.  The point of the macro
is to reasonably get you from eagain =3D> !eagain, whatever the result
may be.  If I turn this into a function, those semantics will still
apply.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Dec 17 21:32:43 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 17 Dec 2011 21: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.xensource.com>)
	id 1Rc1rD-0005Fu-9f; Sat, 17 Dec 2011 21:31:51 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Rc1rB-0005Fp-9S
	for xen-devel@lists.xensource.com; Sat, 17 Dec 2011 21:31:49 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1324157501!7871489!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ0NTk1OQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25490 invoked from network); 17 Dec 2011 21:31:42 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-5.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Dec 2011 21:31:42 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pBHLUndh007856
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sat, 17 Dec 2011 21:30:50 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pBHLUl6M005331
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Sat, 17 Dec 2011 21:30:48 GMT
Received: from abhmt107.oracle.com (abhmt107.oracle.com [141.146.116.59])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pBHLUkvI014417; Sat, 17 Dec 2011 15:30:46 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Sat, 17 Dec 2011 13:30:46 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 541B040196; Sat, 17 Dec 2011 16:29:51 -0500 (EST)
Date: Sat, 17 Dec 2011 16:29:51 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Adin Scannell <adin@gridcentric.com>
Message-ID: <20111217212951.GA17479@phenom.dumpdata.com>
References: <1324092141-9730-1-git-send-email-adin@scannell.ca>
	<1324092141-9730-4-git-send-email-adin@scannell.ca>
	<20111217144003.GE14816@konrad-lan>
	<CAAJKtqrcMv+XfN_-X8O-FqbifOZOqp8i3FQa5qPg+05-PiZtqg@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAAJKtqrcMv+XfN_-X8O-FqbifOZOqp8i3FQa5qPg+05-PiZtqg@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090206.4EED0A0B.0044,ss=1,re=0.000,fgs=0
Cc: olaf@aepfle.de, xen-devel@lists.xensource.com,
	Adin Scannell <adin@scannell.ca>, andres@gridcentric.ca,
	JBeulich@suse.com, Konrad Rzeszutek Wilk <konrad@darnok.org>
Subject: Re: [Xen-devel] [PATCH 3/3] Port of mmap_batch_v2 to support paging
	in Xen
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Sat, Dec 17, 2011 at 11:51:11AM -0500, Adin Scannell wrote:
> Hi Konrad,
> =

> Thanks for the quick turnaround. I'll incorporate your feedback and
> resend. Some NOTES are inline below.
> =

> On Sat, Dec 17, 2011 at 9:40 AM, Konrad Rzeszutek Wilk
> <konrad@darnok.org> wrote:
> > On Fri, Dec 16, 2011 at 10:22:21PM -0500, Adin Scannell wrote:
> >> This wasn't ported from any patch, but was rewritten based on the XCP =
2.6.32
> >> tree. =A0The code structure is significantly different and this patch =
mirrors the
> >> existing Linux code.
> >>
> >> The primary reason for need the V2 interface is to support foreign map=
pings
> >> (i.e. qemu) of paged-out pages. =A0The libxc code will already retry m=
appings
> >> when an ENOENT is returned. =A0The V2 interface provides a richer erro=
r value,
> >> so the user-space code is capable of handling these errors specificall=
y.
> >
> > Can you give more details on how to use paged-out pages. Perhaps a
> > pointer to the xen's docs?
> =

> Hrm, in usual fashion the docs are a bit lacking.
> =

> Simply: the kernel has to do nothing to support paging (other than the
> backend drivers which need to handle the grant EAGAIN case -- other
> patch).  The only reason the V2 interface is needed here is to pass

Hm I did not see the netback one? Should that also incorporate this?

> back full error codes from the mmu_update()'s. Xen and libxc have a
> mutual understanding that when you receive an ENOENT error code, you
> back off and try again.

What you described is pretty good. Please do include it in the git
description. Thx

> =

> >>
> >> Signed-off-by: Adin Scannell <adin@scannell.ca>
> >>
> >> Index: linux/drivers/xen/xenfs/privcmd.c
> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> >> ---
> >> =A0drivers/xen/xenfs/privcmd.c | =A0 90 ++++++++++++++++++++++++++++++=
++++++++++++-
> >
> > So that file just moved to drivers/xen/privcmd.c
> =

> Of course it has :)

Well, we can't have it easy can we! :-)
> =

> >> =A0include/xen/privcmd.h =A0 =A0 =A0 | =A0 10 +++++
> >> =A02 files changed, 99 insertions(+), 1 deletions(-)
> >>
> >> diff --git a/drivers/xen/xenfs/privcmd.c b/drivers/xen/xenfs/privcmd.c
> >> index dbd3b16..21cbb5a 100644
> >> --- a/drivers/xen/xenfs/privcmd.c
> >> +++ b/drivers/xen/xenfs/privcmd.c
> >> @@ -70,7 +70,7 @@ static void free_page_list(struct list_head *pages)
> >> =A0 */
> >> =A0static int gather_array(struct list_head *pagelist,
> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 unsigned nelem, size_t siz=
e,
> >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 void __user *data)
> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 const void __user *data)
> >> =A0{
> >> =A0 =A0 =A0 unsigned pageidx;
> >> =A0 =A0 =A0 void *pagedata;
> >> @@ -245,6 +245,15 @@ struct mmap_batch_state {
> >> =A0 =A0 =A0 xen_pfn_t __user *user;
> >> =A0};
> >>
> >> +struct mmap_batch_v2_state {
> >> + =A0 =A0 domid_t domain;
> >> + =A0 =A0 unsigned long va;
> >> + =A0 =A0 struct vm_area_struct *vma;
> >> + =A0 =A0 int paged_out;
> >
> > Should this be unsigned int?
> =

> Noted below.
> =

> >> +
> >> + =A0 =A0 int __user *err;
> >> +};
> >> +
> >> =A0static int mmap_batch_fn(void *data, void *state)
> >> =A0{
> >> =A0 =A0 =A0 xen_pfn_t *mfnp =3D data;
> >> @@ -260,6 +269,20 @@ static int mmap_batch_fn(void *data, void *state)
> >> =A0 =A0 =A0 return 0;
> >> =A0}
> >>
> >> +static int mmap_batch_v2_fn(void *data, void *state)
> >> +{
> >> + =A0 =A0 xen_pfn_t *mfnp =3D data;
> >> + =A0 =A0 struct mmap_batch_v2_state *st =3D state;
> >> +
> >> + =A0 =A0 int rc =3D xen_remap_domain_mfn_range(st->vma, st->va & PAGE=
_MASK, *mfnp, 1,
> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0st->vma->vm_page_prot, st->domain);
> >
> > You don't want to check that st is not NULL?
> =

> This could be an assertion as it's only used in the
> ioctl_mmap_batch_v2 function where it's guaranteed to pass in a
> non-null state.
> =

> I'll add an additional patch to the queue that adds these assertions
> to both mmap_batch_fn and mmap_batch_fn_v2.
> =

> >> + =A0 =A0 =A0 =A0 =A0 =A0 st->paged_out++;
> > Is it possible that this ends overflowing and hitting 0?
> =

> I don't think this is an issue practically, as the only way to trigger
> this would be to be on a 64bit machine and map an ungodly number of
> pages with a single mmap_batch (MAX_INT).  For correctness though, I
> can update this variable and the err variable in mmap_batch_state
> which suffers from the same problem -- turn them into unsigned long.
> This will be included in the additional patch.
> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0m.arr);
> >> +
> >> + =A0 =A0 if (ret || list_empty(&pagelist))
> >> + =A0 =A0 =A0 =A0 =A0 =A0 goto out;
> >> +
> >> + =A0 =A0 down_write(&mm->mmap_sem);
> >> +
> >> + =A0 =A0 vma =3D find_vma(mm, m.addr);
> >> + =A0 =A0 ret =3D -EINVAL;
> >> + =A0 =A0 /* We allow multiple shots here, because this interface
> >> + =A0 =A0 =A0* is used by libxc and mappings for specific pages will
> >> + =A0 =A0 =A0* be retried when pages are paged-out (ENOENT). */
> >> + =A0 =A0 if (!vma ||
> >> + =A0 =A0 =A0 =A0 vma->vm_ops !=3D &privcmd_vm_ops ||
> >> + =A0 =A0 =A0 =A0 (m.addr < vma->vm_start) ||
> >> + =A0 =A0 =A0 =A0 ((m.addr + (nr_pages << PAGE_SHIFT)) > vma->vm_end))=
 {
> >> + =A0 =A0 =A0 =A0 =A0 =A0 up_write(&mm->mmap_sem);
> >> + =A0 =A0 =A0 =A0 =A0 =A0 goto out;
> >> + =A0 =A0 }
> >> +
> >> + =A0 =A0 state.domain =3D m.dom;
> >
> > Should you check the m.dom for incorrect ones? Like -1? or DOMID_IO?
> =

> I followed the example for mmap_batch, which just tries the call and
> returns whatever error Xen gives.  I think that's the right approach
> for these.

OK. I think a another patch to actually check for that in every other
ioclt in this code might be worth it.
> =

> Cheers!
> -Adin

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Dec 17 21:32:43 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 17 Dec 2011 21: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.xensource.com>)
	id 1Rc1rD-0005Fu-9f; Sat, 17 Dec 2011 21:31:51 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Rc1rB-0005Fp-9S
	for xen-devel@lists.xensource.com; Sat, 17 Dec 2011 21:31:49 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1324157501!7871489!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ0NTk1OQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25490 invoked from network); 17 Dec 2011 21:31:42 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-5.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Dec 2011 21:31:42 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pBHLUndh007856
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sat, 17 Dec 2011 21:30:50 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pBHLUl6M005331
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Sat, 17 Dec 2011 21:30:48 GMT
Received: from abhmt107.oracle.com (abhmt107.oracle.com [141.146.116.59])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pBHLUkvI014417; Sat, 17 Dec 2011 15:30:46 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Sat, 17 Dec 2011 13:30:46 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 541B040196; Sat, 17 Dec 2011 16:29:51 -0500 (EST)
Date: Sat, 17 Dec 2011 16:29:51 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Adin Scannell <adin@gridcentric.com>
Message-ID: <20111217212951.GA17479@phenom.dumpdata.com>
References: <1324092141-9730-1-git-send-email-adin@scannell.ca>
	<1324092141-9730-4-git-send-email-adin@scannell.ca>
	<20111217144003.GE14816@konrad-lan>
	<CAAJKtqrcMv+XfN_-X8O-FqbifOZOqp8i3FQa5qPg+05-PiZtqg@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAAJKtqrcMv+XfN_-X8O-FqbifOZOqp8i3FQa5qPg+05-PiZtqg@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090206.4EED0A0B.0044,ss=1,re=0.000,fgs=0
Cc: olaf@aepfle.de, xen-devel@lists.xensource.com,
	Adin Scannell <adin@scannell.ca>, andres@gridcentric.ca,
	JBeulich@suse.com, Konrad Rzeszutek Wilk <konrad@darnok.org>
Subject: Re: [Xen-devel] [PATCH 3/3] Port of mmap_batch_v2 to support paging
	in Xen
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Sat, Dec 17, 2011 at 11:51:11AM -0500, Adin Scannell wrote:
> Hi Konrad,
> =

> Thanks for the quick turnaround. I'll incorporate your feedback and
> resend. Some NOTES are inline below.
> =

> On Sat, Dec 17, 2011 at 9:40 AM, Konrad Rzeszutek Wilk
> <konrad@darnok.org> wrote:
> > On Fri, Dec 16, 2011 at 10:22:21PM -0500, Adin Scannell wrote:
> >> This wasn't ported from any patch, but was rewritten based on the XCP =
2.6.32
> >> tree. =A0The code structure is significantly different and this patch =
mirrors the
> >> existing Linux code.
> >>
> >> The primary reason for need the V2 interface is to support foreign map=
pings
> >> (i.e. qemu) of paged-out pages. =A0The libxc code will already retry m=
appings
> >> when an ENOENT is returned. =A0The V2 interface provides a richer erro=
r value,
> >> so the user-space code is capable of handling these errors specificall=
y.
> >
> > Can you give more details on how to use paged-out pages. Perhaps a
> > pointer to the xen's docs?
> =

> Hrm, in usual fashion the docs are a bit lacking.
> =

> Simply: the kernel has to do nothing to support paging (other than the
> backend drivers which need to handle the grant EAGAIN case -- other
> patch).  The only reason the V2 interface is needed here is to pass

Hm I did not see the netback one? Should that also incorporate this?

> back full error codes from the mmu_update()'s. Xen and libxc have a
> mutual understanding that when you receive an ENOENT error code, you
> back off and try again.

What you described is pretty good. Please do include it in the git
description. Thx

> =

> >>
> >> Signed-off-by: Adin Scannell <adin@scannell.ca>
> >>
> >> Index: linux/drivers/xen/xenfs/privcmd.c
> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> >> ---
> >> =A0drivers/xen/xenfs/privcmd.c | =A0 90 ++++++++++++++++++++++++++++++=
++++++++++++-
> >
> > So that file just moved to drivers/xen/privcmd.c
> =

> Of course it has :)

Well, we can't have it easy can we! :-)
> =

> >> =A0include/xen/privcmd.h =A0 =A0 =A0 | =A0 10 +++++
> >> =A02 files changed, 99 insertions(+), 1 deletions(-)
> >>
> >> diff --git a/drivers/xen/xenfs/privcmd.c b/drivers/xen/xenfs/privcmd.c
> >> index dbd3b16..21cbb5a 100644
> >> --- a/drivers/xen/xenfs/privcmd.c
> >> +++ b/drivers/xen/xenfs/privcmd.c
> >> @@ -70,7 +70,7 @@ static void free_page_list(struct list_head *pages)
> >> =A0 */
> >> =A0static int gather_array(struct list_head *pagelist,
> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 unsigned nelem, size_t siz=
e,
> >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 void __user *data)
> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 const void __user *data)
> >> =A0{
> >> =A0 =A0 =A0 unsigned pageidx;
> >> =A0 =A0 =A0 void *pagedata;
> >> @@ -245,6 +245,15 @@ struct mmap_batch_state {
> >> =A0 =A0 =A0 xen_pfn_t __user *user;
> >> =A0};
> >>
> >> +struct mmap_batch_v2_state {
> >> + =A0 =A0 domid_t domain;
> >> + =A0 =A0 unsigned long va;
> >> + =A0 =A0 struct vm_area_struct *vma;
> >> + =A0 =A0 int paged_out;
> >
> > Should this be unsigned int?
> =

> Noted below.
> =

> >> +
> >> + =A0 =A0 int __user *err;
> >> +};
> >> +
> >> =A0static int mmap_batch_fn(void *data, void *state)
> >> =A0{
> >> =A0 =A0 =A0 xen_pfn_t *mfnp =3D data;
> >> @@ -260,6 +269,20 @@ static int mmap_batch_fn(void *data, void *state)
> >> =A0 =A0 =A0 return 0;
> >> =A0}
> >>
> >> +static int mmap_batch_v2_fn(void *data, void *state)
> >> +{
> >> + =A0 =A0 xen_pfn_t *mfnp =3D data;
> >> + =A0 =A0 struct mmap_batch_v2_state *st =3D state;
> >> +
> >> + =A0 =A0 int rc =3D xen_remap_domain_mfn_range(st->vma, st->va & PAGE=
_MASK, *mfnp, 1,
> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0st->vma->vm_page_prot, st->domain);
> >
> > You don't want to check that st is not NULL?
> =

> This could be an assertion as it's only used in the
> ioctl_mmap_batch_v2 function where it's guaranteed to pass in a
> non-null state.
> =

> I'll add an additional patch to the queue that adds these assertions
> to both mmap_batch_fn and mmap_batch_fn_v2.
> =

> >> + =A0 =A0 =A0 =A0 =A0 =A0 st->paged_out++;
> > Is it possible that this ends overflowing and hitting 0?
> =

> I don't think this is an issue practically, as the only way to trigger
> this would be to be on a 64bit machine and map an ungodly number of
> pages with a single mmap_batch (MAX_INT).  For correctness though, I
> can update this variable and the err variable in mmap_batch_state
> which suffers from the same problem -- turn them into unsigned long.
> This will be included in the additional patch.
> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0m.arr);
> >> +
> >> + =A0 =A0 if (ret || list_empty(&pagelist))
> >> + =A0 =A0 =A0 =A0 =A0 =A0 goto out;
> >> +
> >> + =A0 =A0 down_write(&mm->mmap_sem);
> >> +
> >> + =A0 =A0 vma =3D find_vma(mm, m.addr);
> >> + =A0 =A0 ret =3D -EINVAL;
> >> + =A0 =A0 /* We allow multiple shots here, because this interface
> >> + =A0 =A0 =A0* is used by libxc and mappings for specific pages will
> >> + =A0 =A0 =A0* be retried when pages are paged-out (ENOENT). */
> >> + =A0 =A0 if (!vma ||
> >> + =A0 =A0 =A0 =A0 vma->vm_ops !=3D &privcmd_vm_ops ||
> >> + =A0 =A0 =A0 =A0 (m.addr < vma->vm_start) ||
> >> + =A0 =A0 =A0 =A0 ((m.addr + (nr_pages << PAGE_SHIFT)) > vma->vm_end))=
 {
> >> + =A0 =A0 =A0 =A0 =A0 =A0 up_write(&mm->mmap_sem);
> >> + =A0 =A0 =A0 =A0 =A0 =A0 goto out;
> >> + =A0 =A0 }
> >> +
> >> + =A0 =A0 state.domain =3D m.dom;
> >
> > Should you check the m.dom for incorrect ones? Like -1? or DOMID_IO?
> =

> I followed the example for mmap_batch, which just tries the call and
> returns whatever error Xen gives.  I think that's the right approach
> for these.

OK. I think a another patch to actually check for that in every other
ioclt in this code might be worth it.
> =

> Cheers!
> -Adin

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Dec 17 21:33:56 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 17 Dec 2011 21:33:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rc1sZ-0005Iv-QR; Sat, 17 Dec 2011 21:33:15 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Rc1sX-0005Im-T0
	for xen-devel@lists.xensource.com; Sat, 17 Dec 2011 21:33:14 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1324157550!47154676!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDQ4OTY5\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11301 invoked from network); 17 Dec 2011 21:32:31 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-5.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Dec 2011 21:32:31 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pBHLWLdG018339
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sat, 17 Dec 2011 21:32:22 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pBHLWKH4006114
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Sat, 17 Dec 2011 21:32:21 GMT
Received: from abhmt107.oracle.com (abhmt107.oracle.com [141.146.116.59])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pBHLWKlO020750; Sat, 17 Dec 2011 15:32:20 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Sat, 17 Dec 2011 13:32:20 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id B07EF40196; Sat, 17 Dec 2011 16:31:25 -0500 (EST)
Date: Sat, 17 Dec 2011 16:31:25 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Adin Scannell <adin@gridcentric.com>
Message-ID: <20111217213125.GB17479@phenom.dumpdata.com>
References: <1324092141-9730-1-git-send-email-adin@scannell.ca>
	<1324092141-9730-3-git-send-email-adin@scannell.ca>
	<20111217143015.GD14816@konrad-lan>
	<CAAJKtqqOH6f1cQn76HWP_cP4Wn-yhw0ePrUgdNb9X5cnbA-O2w@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAAJKtqqOH6f1cQn76HWP_cP4Wn-yhw0ePrUgdNb9X5cnbA-O2w@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090201.4EED0A66.0061,ss=1,re=0.000,fgs=0
Cc: olaf@aepfle.de, xen-devel@lists.xensource.com,
	Adin Scannell <adin@scannell.ca>, andres@gridcentric.ca,
	JBeulich@suse.com, Konrad Rzeszutek Wilk <konrad@darnok.org>
Subject: Re: [Xen-devel] [PATCH 2/3] Handle GNTST_eagain in kernel drivers
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Sat, Dec 17, 2011 at 11:53:40AM -0500, Adin Scannell wrote:
> On Sat, Dec 17, 2011 at 9:30 AM, Konrad Rzeszutek Wilk
> <konrad@darnok.org> wrote:
> >> +#define gnttab_check_GNTST_eagain_while(__HCop, __HCarg_p) =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 >
> > So why does this have to be a macro? What is the advantage of that
> > versus making this a function?
> =

> I just wanted to minimize changes in the patch from the known XCP
> version.  I'm personally not a fan of big macros like this.
> =

> > So why msleep? Why not go for a proper yield? Call the safe_halt()
> > function?
> =

> Yes, this is something that should be revisited.
> =

> Since it looks like Daniel's HVM patches are going to conflict with
> this anyways, I'll revisit this patch independently from the other two
> and see what I can do about making it nicer and addressing the other
> bits of feedback you've given.

OK. Thanks.
> =

> > Use GNTTABOP_error_msgs. Also should we continue? What is the
> > impact if we do continue? The times this is hit is if the status
> > is not GNTS_okay and if it is not GNTS_eagain - so what are the
> > situations in which this happens and what can the domain do
> > to recover? Should there be some helpfull message instead of
> > just "gnt status: X" ?
> =

> In all the cases this macro is called, the caller still needs to check
> op.status and handle any errors appropriately.  The point of the macro
> is to reasonably get you from eagain =3D> !eagain, whatever the result
> may be.  If I turn this into a function, those semantics will still
> apply.

OK, it sounds as the 'printk' is not really neccessary as it will be the
responsibility of the caller to figure out what to do (which might
be very well doing a printk, or maybe not?)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Dec 17 21:33:56 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 17 Dec 2011 21:33:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rc1sZ-0005Iv-QR; Sat, 17 Dec 2011 21:33:15 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Rc1sX-0005Im-T0
	for xen-devel@lists.xensource.com; Sat, 17 Dec 2011 21:33:14 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1324157550!47154676!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDQ4OTY5\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11301 invoked from network); 17 Dec 2011 21:32:31 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-5.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Dec 2011 21:32:31 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pBHLWLdG018339
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sat, 17 Dec 2011 21:32:22 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pBHLWKH4006114
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Sat, 17 Dec 2011 21:32:21 GMT
Received: from abhmt107.oracle.com (abhmt107.oracle.com [141.146.116.59])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pBHLWKlO020750; Sat, 17 Dec 2011 15:32:20 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Sat, 17 Dec 2011 13:32:20 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id B07EF40196; Sat, 17 Dec 2011 16:31:25 -0500 (EST)
Date: Sat, 17 Dec 2011 16:31:25 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Adin Scannell <adin@gridcentric.com>
Message-ID: <20111217213125.GB17479@phenom.dumpdata.com>
References: <1324092141-9730-1-git-send-email-adin@scannell.ca>
	<1324092141-9730-3-git-send-email-adin@scannell.ca>
	<20111217143015.GD14816@konrad-lan>
	<CAAJKtqqOH6f1cQn76HWP_cP4Wn-yhw0ePrUgdNb9X5cnbA-O2w@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAAJKtqqOH6f1cQn76HWP_cP4Wn-yhw0ePrUgdNb9X5cnbA-O2w@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090201.4EED0A66.0061,ss=1,re=0.000,fgs=0
Cc: olaf@aepfle.de, xen-devel@lists.xensource.com,
	Adin Scannell <adin@scannell.ca>, andres@gridcentric.ca,
	JBeulich@suse.com, Konrad Rzeszutek Wilk <konrad@darnok.org>
Subject: Re: [Xen-devel] [PATCH 2/3] Handle GNTST_eagain in kernel drivers
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Sat, Dec 17, 2011 at 11:53:40AM -0500, Adin Scannell wrote:
> On Sat, Dec 17, 2011 at 9:30 AM, Konrad Rzeszutek Wilk
> <konrad@darnok.org> wrote:
> >> +#define gnttab_check_GNTST_eagain_while(__HCop, __HCarg_p) =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 >
> > So why does this have to be a macro? What is the advantage of that
> > versus making this a function?
> =

> I just wanted to minimize changes in the patch from the known XCP
> version.  I'm personally not a fan of big macros like this.
> =

> > So why msleep? Why not go for a proper yield? Call the safe_halt()
> > function?
> =

> Yes, this is something that should be revisited.
> =

> Since it looks like Daniel's HVM patches are going to conflict with
> this anyways, I'll revisit this patch independently from the other two
> and see what I can do about making it nicer and addressing the other
> bits of feedback you've given.

OK. Thanks.
> =

> > Use GNTTABOP_error_msgs. Also should we continue? What is the
> > impact if we do continue? The times this is hit is if the status
> > is not GNTS_okay and if it is not GNTS_eagain - so what are the
> > situations in which this happens and what can the domain do
> > to recover? Should there be some helpfull message instead of
> > just "gnt status: X" ?
> =

> In all the cases this macro is called, the caller still needs to check
> op.status and handle any errors appropriately.  The point of the macro
> is to reasonably get you from eagain =3D> !eagain, whatever the result
> may be.  If I turn this into a function, those semantics will still
> apply.

OK, it sounds as the 'printk' is not really neccessary as it will be the
responsibility of the caller to figure out what to do (which might
be very well doing a printk, or maybe not?)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Dec 17 21:48:15 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 17 Dec 2011 21: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.xensource.com>)
	id 1Rc26V-0005Zw-7U; Sat, 17 Dec 2011 21:47:39 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Rc26T-0005Zr-Ih
	for xen-devel@lists.xensource.com; Sat, 17 Dec 2011 21:47:37 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1324158450!9201223!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDQ4OTY5\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30955 invoked from network); 17 Dec 2011 21:47:31 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-2.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Dec 2011 21:47:31 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pBHLlQki028017
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sat, 17 Dec 2011 21:47:27 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pBHLlOr9024901
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Sat, 17 Dec 2011 21:47:24 GMT
Received: from abhmt114.oracle.com (abhmt114.oracle.com [141.146.116.66])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pBHLlL4Z019651; Sat, 17 Dec 2011 15:47:21 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Sat, 17 Dec 2011 13:47:21 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 9D6F440196; Sat, 17 Dec 2011 16:46:26 -0500 (EST)
Date: Sat, 17 Dec 2011 16:46:26 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ferenc Wagner <wferi@niif.hu>
Message-ID: <20111217214626.GA17841@phenom.dumpdata.com>
References: <ce19ea02-45e6-465a-a4c8-b5d74bf8c2ad@default>
	<20111010155319.GA29140@phenom.oracle.com>
	<4E934EC9.5030909@goop.org> <87vcppbvc4.fsf@tac.ki.iif.hu>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <87vcppbvc4.fsf@tac.ki.iif.hu>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090204.4EED0DF0.0086,ss=1,re=0.000,fgs=0
Cc: linux-kernel@vger.kernel.org, Jeremy Fitzhardinge <jeremy@goop.org>,
	xen-devel@lists.xensource.com, Zhenzhong Duan <zhenzhong.duan@oracle.com>,
	linux-x86_64@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH] cpu idle ticks show twice in xen pvm guest
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Dec 09, 2011 at 04:47:39PM +0100, Ferenc Wagner wrote:
> Jeremy Fitzhardinge <jeremy@goop.org> writes:
> 
> >> On Wed, Oct 05, 2011 at 10:11:58PM -0700, Zhenzhong Duan wrote:
> >>
> >>> Run below test on xen pvm.
> >>> # x=$(cat /proc/stat | grep cpu0 | awk '{print $5}') && sleep 60  \
> >>> && y=$(cat /proc/stat | grep cpu0 | awk '{print $5}') \
> >>> && echo -e  "X:$x\nY:$y\nIDLE:" $(echo "scale=3; ($y-$x)/6000*100" | bc)
> >>>
> >>> @ X:58562301
> >>> @ Y:58574282
> >>> @ IDLE: 199.600
> >>>
> >>> Normal idle percent should be around 100%.
> >>> xen_timer_interrupt called account_idle_ticks to account hypervisor stolen idle ticks 
> >>> but these ticks will be accounted again when idle ticks restarted.
> >>>
> >>> Signed-off-by: Zhenzhong Duan <zhenzhong.duan@oracle.com>
> >>> Signed-off-by: Joe Jin <joe.jin@oracle.com>
> >
> > Does this affect the accounting of stolen ticks?  If it does, that's not
> > necessarily a showstopper for this patch, but we'll need to do some more
> > thinking about it.  Certainly, accurate accounting for idleness is
> > important.
> 
> Please see also http://thread.gmane.org/gmane.linux.kernel/734441, where
> I found that the counter doubling isn't always present under 2.6.26.
> However, after going to 2.6.32 (Debian lenny-backports kernel, 4th of
> April on the graph below) that instability seems to disappear.  Please
> note that the following graph shows halved idle and iowait percentages.
> 

What happenend in Feb?

> 
> (I haven't collected steal values, so the numbers don't sum up to 100%.)
> I'd be grateful if this discrepancy could be cleared up eventually!
> It's heartening to see some progress after more than three years. :)
> 
> Actually, as Munin doesn't half the idle and iowait values, but
> truncates the (then overflowing) graph at 100%, I was rather surprised
> to see iowait completely disappear after the kernel upgrade, and
> concluded that it was somehow converted into buggy-looping in blkfront.
> Now I see this isn't the case, but the steadily increasing system CPU
> usage between reboots is still a mystery.  I'll start a separate thread
> for that, just wanted to provide some motivation for this topic.

Did you add more memory in the system?
> --
> Thanks,
> Feri.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Dec 17 21:48:15 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 17 Dec 2011 21: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.xensource.com>)
	id 1Rc26V-0005Zw-7U; Sat, 17 Dec 2011 21:47:39 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Rc26T-0005Zr-Ih
	for xen-devel@lists.xensource.com; Sat, 17 Dec 2011 21:47:37 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1324158450!9201223!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDQ4OTY5\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30955 invoked from network); 17 Dec 2011 21:47:31 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-2.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Dec 2011 21:47:31 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pBHLlQki028017
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sat, 17 Dec 2011 21:47:27 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pBHLlOr9024901
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Sat, 17 Dec 2011 21:47:24 GMT
Received: from abhmt114.oracle.com (abhmt114.oracle.com [141.146.116.66])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pBHLlL4Z019651; Sat, 17 Dec 2011 15:47:21 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Sat, 17 Dec 2011 13:47:21 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 9D6F440196; Sat, 17 Dec 2011 16:46:26 -0500 (EST)
Date: Sat, 17 Dec 2011 16:46:26 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ferenc Wagner <wferi@niif.hu>
Message-ID: <20111217214626.GA17841@phenom.dumpdata.com>
References: <ce19ea02-45e6-465a-a4c8-b5d74bf8c2ad@default>
	<20111010155319.GA29140@phenom.oracle.com>
	<4E934EC9.5030909@goop.org> <87vcppbvc4.fsf@tac.ki.iif.hu>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <87vcppbvc4.fsf@tac.ki.iif.hu>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090204.4EED0DF0.0086,ss=1,re=0.000,fgs=0
Cc: linux-kernel@vger.kernel.org, Jeremy Fitzhardinge <jeremy@goop.org>,
	xen-devel@lists.xensource.com, Zhenzhong Duan <zhenzhong.duan@oracle.com>,
	linux-x86_64@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH] cpu idle ticks show twice in xen pvm guest
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Dec 09, 2011 at 04:47:39PM +0100, Ferenc Wagner wrote:
> Jeremy Fitzhardinge <jeremy@goop.org> writes:
> 
> >> On Wed, Oct 05, 2011 at 10:11:58PM -0700, Zhenzhong Duan wrote:
> >>
> >>> Run below test on xen pvm.
> >>> # x=$(cat /proc/stat | grep cpu0 | awk '{print $5}') && sleep 60  \
> >>> && y=$(cat /proc/stat | grep cpu0 | awk '{print $5}') \
> >>> && echo -e  "X:$x\nY:$y\nIDLE:" $(echo "scale=3; ($y-$x)/6000*100" | bc)
> >>>
> >>> @ X:58562301
> >>> @ Y:58574282
> >>> @ IDLE: 199.600
> >>>
> >>> Normal idle percent should be around 100%.
> >>> xen_timer_interrupt called account_idle_ticks to account hypervisor stolen idle ticks 
> >>> but these ticks will be accounted again when idle ticks restarted.
> >>>
> >>> Signed-off-by: Zhenzhong Duan <zhenzhong.duan@oracle.com>
> >>> Signed-off-by: Joe Jin <joe.jin@oracle.com>
> >
> > Does this affect the accounting of stolen ticks?  If it does, that's not
> > necessarily a showstopper for this patch, but we'll need to do some more
> > thinking about it.  Certainly, accurate accounting for idleness is
> > important.
> 
> Please see also http://thread.gmane.org/gmane.linux.kernel/734441, where
> I found that the counter doubling isn't always present under 2.6.26.
> However, after going to 2.6.32 (Debian lenny-backports kernel, 4th of
> April on the graph below) that instability seems to disappear.  Please
> note that the following graph shows halved idle and iowait percentages.
> 

What happenend in Feb?

> 
> (I haven't collected steal values, so the numbers don't sum up to 100%.)
> I'd be grateful if this discrepancy could be cleared up eventually!
> It's heartening to see some progress after more than three years. :)
> 
> Actually, as Munin doesn't half the idle and iowait values, but
> truncates the (then overflowing) graph at 100%, I was rather surprised
> to see iowait completely disappear after the kernel upgrade, and
> concluded that it was somehow converted into buggy-looping in blkfront.
> Now I see this isn't the case, but the steadily increasing system CPU
> usage between reboots is still a mystery.  I'll start a separate thread
> for that, just wanted to provide some motivation for this topic.

Did you add more memory in the system?
> --
> Thanks,
> Feri.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Dec 17 22:13:28 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 17 Dec 2011 22:13:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rc2V0-0005ut-MU; Sat, 17 Dec 2011 22:12:58 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <carsten@schiers.de>) id 1Rc2Uy-0005ul-Oh
	for xen-devel@lists.xensource.com; Sat, 17 Dec 2011 22:12:57 +0000
X-Env-Sender: carsten@schiers.de
X-Msg-Ref: server-9.tower-174.messagelabs.com!1324159970!5975320!1
X-Originating-IP: [194.117.254.36]
X-SpamReason: No, hits=0.2 required=7.0 tests=FROM_EXCESS_QP,
	MIME_QP_LONG_LINE,SUBJECT_EXCESS_QP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16900 invoked from network); 17 Dec 2011 22:12:50 -0000
Received: from www.zeus06.de (HELO mail.zeus06.de) (194.117.254.36)
	by server-9.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Dec 2011 22:12:50 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=mail.zeus06.de; h=subject
	:from:to:cc:date:mime-version:content-type
	:content-transfer-encoding:in-reply-to:references:message-id; s=
	beta; bh=1/qHIMw5r8dc2O8bh/WqcAlkSfV9VLoP4MjWNLqv/e0=; b=eeOVcIe
	x7cJSCuvOvhz1oxyDyzpF1i8AvLZJbWf/KB/7FF/dUhlzj6XoiZc0xgBG3LV+dWg
	7evsnBeeNDBzGVtbEjAGmnfqYWTpDe5Aqh2D1RoJtc33dKIzzql+xAGzxsgyoRxM
	b1i9ut7KZ80t7DhC7u5lDIhA1AT7xxuVrzmw=
Received: (qmail 26821 invoked from network); 17 Dec 2011 23:12:49 +0100
Received: from unknown (HELO uhura.zz) (l3s6271p1@46.59.180.176)
	by mail.zeus06.de with ESMTPA; 17 Dec 2011 23:12:49 +0100
Received: from localhost (localhost [127.0.0.1])
	by uhura.zz (Postfix) with ESMTP id 5B5BC2C526;
	Sat, 17 Dec 2011 23:12:49 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at schiers.de
Received: from uhura.zz ([127.0.0.1])
	by localhost (uhura.space.zz [127.0.0.1]) (amavisd-new, port 10024)
	with LMTP id o-if9ZQh-Fg4; Sat, 17 Dec 2011 23:12:46 +0100 (CET)
Received: from uhura.space.zz (localhost [127.0.0.1])
	by uhura.zz (Postfix) with ESMTP id 1181B2C525;
	Sat, 17 Dec 2011 23:12:46 +0100 (CET)
From: =?iso-8859-1?Q?Carsten_Schiers?= <carsten@schiers.de>
To: =?iso-8859-1?Q?Konrad_Rzeszutek_Wilk?= <konrad.wilk@oracle.com>
Date: Sat, 17 Dec 2011 23:12:45 +0100
Mime-Version: 1.0
In-Reply-To: <20111216161922.GH31755@phenom.dumpdata.com>
References: <20111214220700.GA9926@phenom.dumpdata.com>
X-Priority: 3 (Normal)
X-Mailer: Zarafa 7.0.2-29470
Thread-Index: Acy9CPeOXaz3nbqdQNKSCjk6Z7V1+g==
Message-Id: <zarafa.4eed13dd.0c2e.0c908eda504bffd9@uhura.space.zz>
Cc: =?iso-8859-1?Q?linux=40eikelenboom=2Eit?= <linux@eikelenboom.it>,
	=?iso-8859-1?Q?xen-devel?= <xen-devel@lists.xensource.com>,
	=?iso-8859-1?Q?lersek=40redhat=2Ecom?= <lersek@redhat.com>,
	=?iso-8859-1?Q?zhenzhong=2Eduan=40oracle=2Ecom?=
	<zhenzhong.duan@oracle.com>,
	=?iso-8859-1?Q?Ian_Campbell?= <ian.campbell@citrix.com>
Subject: Re: [Xen-devel]
 =?iso-8859-1?q?Load_increase_after_memory_upgrade_=28?=
 =?iso-8859-1?q?part2=29?=
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

OK, double checked. Both PCI cards enabled, running, working, but nothing b=
ut "SWIOTLB is 0% full". Any chance
to check that the patch is working? Does it print out something else with y=
our setting? BR, Carsten.

-----Urspr=FCngliche Nachricht-----
Von: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-bounces@lists.=
xensource.com] Im Auftrag von Konrad Rzeszutek Wilk
Gesendet: Freitag, 16. Dezember 2011 17:19
An: Carsten Schiers
Cc: linux@eikelenboom.it; xen-devel; lersek@redhat.com; zhenzhong.duan@orac=
le.com; Ian Campbell
Betreff: Re: [Xen-devel] Load increase after memory upgrade (part2)

On Fri, Dec 16, 2011 at 04:51:47PM +0100, Carsten Schiers wrote:
> > And you are using swiotlb=3Dforce on the 2.6.34 classic kernel and pass=
ing in your budget-av card in it?
> =

> Yes, two of them with swiotlb=3D32,force.
> =

> =

> > Could you append the dmesg output please?
> =

> Attached. You find a "normal" boot after the one with the patched kernel.

Uh, what happens when you run the driver, meaning capture stuff. I remember=
 with the pvops you had about ~30K or so of bounces, but not sure about the=
 bootup?

Thanks for being willing to be a guinea pig while trying to fix this.
> =

> Carsten.
> =

> =




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Dec 17 22:13:28 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 17 Dec 2011 22:13:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rc2V0-0005ut-MU; Sat, 17 Dec 2011 22:12:58 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <carsten@schiers.de>) id 1Rc2Uy-0005ul-Oh
	for xen-devel@lists.xensource.com; Sat, 17 Dec 2011 22:12:57 +0000
X-Env-Sender: carsten@schiers.de
X-Msg-Ref: server-9.tower-174.messagelabs.com!1324159970!5975320!1
X-Originating-IP: [194.117.254.36]
X-SpamReason: No, hits=0.2 required=7.0 tests=FROM_EXCESS_QP,
	MIME_QP_LONG_LINE,SUBJECT_EXCESS_QP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16900 invoked from network); 17 Dec 2011 22:12:50 -0000
Received: from www.zeus06.de (HELO mail.zeus06.de) (194.117.254.36)
	by server-9.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Dec 2011 22:12:50 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=mail.zeus06.de; h=subject
	:from:to:cc:date:mime-version:content-type
	:content-transfer-encoding:in-reply-to:references:message-id; s=
	beta; bh=1/qHIMw5r8dc2O8bh/WqcAlkSfV9VLoP4MjWNLqv/e0=; b=eeOVcIe
	x7cJSCuvOvhz1oxyDyzpF1i8AvLZJbWf/KB/7FF/dUhlzj6XoiZc0xgBG3LV+dWg
	7evsnBeeNDBzGVtbEjAGmnfqYWTpDe5Aqh2D1RoJtc33dKIzzql+xAGzxsgyoRxM
	b1i9ut7KZ80t7DhC7u5lDIhA1AT7xxuVrzmw=
Received: (qmail 26821 invoked from network); 17 Dec 2011 23:12:49 +0100
Received: from unknown (HELO uhura.zz) (l3s6271p1@46.59.180.176)
	by mail.zeus06.de with ESMTPA; 17 Dec 2011 23:12:49 +0100
Received: from localhost (localhost [127.0.0.1])
	by uhura.zz (Postfix) with ESMTP id 5B5BC2C526;
	Sat, 17 Dec 2011 23:12:49 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at schiers.de
Received: from uhura.zz ([127.0.0.1])
	by localhost (uhura.space.zz [127.0.0.1]) (amavisd-new, port 10024)
	with LMTP id o-if9ZQh-Fg4; Sat, 17 Dec 2011 23:12:46 +0100 (CET)
Received: from uhura.space.zz (localhost [127.0.0.1])
	by uhura.zz (Postfix) with ESMTP id 1181B2C525;
	Sat, 17 Dec 2011 23:12:46 +0100 (CET)
From: =?iso-8859-1?Q?Carsten_Schiers?= <carsten@schiers.de>
To: =?iso-8859-1?Q?Konrad_Rzeszutek_Wilk?= <konrad.wilk@oracle.com>
Date: Sat, 17 Dec 2011 23:12:45 +0100
Mime-Version: 1.0
In-Reply-To: <20111216161922.GH31755@phenom.dumpdata.com>
References: <20111214220700.GA9926@phenom.dumpdata.com>
X-Priority: 3 (Normal)
X-Mailer: Zarafa 7.0.2-29470
Thread-Index: Acy9CPeOXaz3nbqdQNKSCjk6Z7V1+g==
Message-Id: <zarafa.4eed13dd.0c2e.0c908eda504bffd9@uhura.space.zz>
Cc: =?iso-8859-1?Q?linux=40eikelenboom=2Eit?= <linux@eikelenboom.it>,
	=?iso-8859-1?Q?xen-devel?= <xen-devel@lists.xensource.com>,
	=?iso-8859-1?Q?lersek=40redhat=2Ecom?= <lersek@redhat.com>,
	=?iso-8859-1?Q?zhenzhong=2Eduan=40oracle=2Ecom?=
	<zhenzhong.duan@oracle.com>,
	=?iso-8859-1?Q?Ian_Campbell?= <ian.campbell@citrix.com>
Subject: Re: [Xen-devel]
 =?iso-8859-1?q?Load_increase_after_memory_upgrade_=28?=
 =?iso-8859-1?q?part2=29?=
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

OK, double checked. Both PCI cards enabled, running, working, but nothing b=
ut "SWIOTLB is 0% full". Any chance
to check that the patch is working? Does it print out something else with y=
our setting? BR, Carsten.

-----Urspr=FCngliche Nachricht-----
Von: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-bounces@lists.=
xensource.com] Im Auftrag von Konrad Rzeszutek Wilk
Gesendet: Freitag, 16. Dezember 2011 17:19
An: Carsten Schiers
Cc: linux@eikelenboom.it; xen-devel; lersek@redhat.com; zhenzhong.duan@orac=
le.com; Ian Campbell
Betreff: Re: [Xen-devel] Load increase after memory upgrade (part2)

On Fri, Dec 16, 2011 at 04:51:47PM +0100, Carsten Schiers wrote:
> > And you are using swiotlb=3Dforce on the 2.6.34 classic kernel and pass=
ing in your budget-av card in it?
> =

> Yes, two of them with swiotlb=3D32,force.
> =

> =

> > Could you append the dmesg output please?
> =

> Attached. You find a "normal" boot after the one with the patched kernel.

Uh, what happens when you run the driver, meaning capture stuff. I remember=
 with the pvops you had about ~30K or so of bounces, but not sure about the=
 bootup?

Thanks for being willing to be a guinea pig while trying to fix this.
> =

> Carsten.
> =

> =




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Dec 18 00:20:11 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 18 Dec 2011 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.xensource.com>)
	id 1Rc4TL-00074R-5z; Sun, 18 Dec 2011 00:19:23 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1Rc4TJ-00074M-Ll
	for xen-devel@lists.xensource.com; Sun, 18 Dec 2011 00:19:21 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-4.tower-27.messagelabs.com!1324167525!52868622!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 522 invoked from network); 18 Dec 2011 00:18:45 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-4.tower-27.messagelabs.com with AES256-SHA encrypted SMTP;
	18 Dec 2011 00:18:45 -0000
Received: from 207-71-ftth.onsneteindhoven.nl ([88.159.71.207]:52340
	helo=[172.16.1.20])
	by smtp.eikelenboom.it with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32)
	(Exim 4.72) (envelope-from <linux@eikelenboom.it>)
	id 1Rc4Qk-0007hD-3W; Sun, 18 Dec 2011 01:16:42 +0100
Date: Sun, 18 Dec 2011 01:19:16 +0100
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <783969451.20111218011916@eikelenboom.it>
To: Carsten Schiers <carsten@schiers.de>
In-Reply-To: <zarafa.4eed13dd.0c2e.0c908eda504bffd9@uhura.space.zz>
References: <20111214220700.GA9926@phenom.dumpdata.com>
	<zarafa.4eed13dd.0c2e.0c908eda504bffd9@uhura.space.zz>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>,
	xen-devel <xen-devel@lists.xensource.com>, lersek@redhat.com,
	zhenzhong.duan@oracle.com, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] Load increase after memory upgrade (part2)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

I also have done some experiments with the patch, in domU i also get the 0%=
 full for my usb controllers with video grabbers , in dom0 my i get 12% ful=
l, both my realtek 8169 ethernet controllers seem to use the bounce bufferi=
ng ...
And that with a iommu (amd) ? it all seems kind of strange, although it is =
also working ...
I'm not having much time now, hoping to get back with a full report soon.

--
Sander

Saturday, December 17, 2011, 11:12:45 PM, you wrote:

> OK, double checked. Both PCI cards enabled, running, working, but nothing=
 but "SWIOTLB is 0% full". Any chance
> to check that the patch is working? Does it print out something else with=
 your setting? BR, Carsten.

> -----Urspr=FCngliche Nachricht-----
> Von: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-bounces@list=
s.xensource.com] Im Auftrag von Konrad Rzeszutek Wilk
> Gesendet: Freitag, 16. Dezember 2011 17:19
> An: Carsten Schiers
> Cc: linux@eikelenboom.it; xen-devel; lersek@redhat.com; zhenzhong.duan@or=
acle.com; Ian Campbell
> Betreff: Re: [Xen-devel] Load increase after memory upgrade (part2)

> On Fri, Dec 16, 2011 at 04:51:47PM +0100, Carsten Schiers wrote:
>> > And you are using swiotlb=3Dforce on the 2.6.34 classic kernel and pas=
sing in your budget-av card in it?
>> =

>> Yes, two of them with swiotlb=3D32,force.
>> =

>> =

>> > Could you append the dmesg output please?
>> =

>> Attached. You find a "normal" boot after the one with the patched kernel.

> Uh, what happens when you run the driver, meaning capture stuff. I rememb=
er with the pvops you had about ~30K or so of bounces, but not sure about t=
he bootup?

> Thanks for being willing to be a guinea pig while trying to fix this.
>> =

>> Carsten.
>> =

>> =




> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel




-- =

Best regards,
 Sander                            mailto:linux@eikelenboom.it


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Dec 18 00:20:11 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 18 Dec 2011 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.xensource.com>)
	id 1Rc4TL-00074R-5z; Sun, 18 Dec 2011 00:19:23 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1Rc4TJ-00074M-Ll
	for xen-devel@lists.xensource.com; Sun, 18 Dec 2011 00:19:21 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-4.tower-27.messagelabs.com!1324167525!52868622!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 522 invoked from network); 18 Dec 2011 00:18:45 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-4.tower-27.messagelabs.com with AES256-SHA encrypted SMTP;
	18 Dec 2011 00:18:45 -0000
Received: from 207-71-ftth.onsneteindhoven.nl ([88.159.71.207]:52340
	helo=[172.16.1.20])
	by smtp.eikelenboom.it with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32)
	(Exim 4.72) (envelope-from <linux@eikelenboom.it>)
	id 1Rc4Qk-0007hD-3W; Sun, 18 Dec 2011 01:16:42 +0100
Date: Sun, 18 Dec 2011 01:19:16 +0100
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <783969451.20111218011916@eikelenboom.it>
To: Carsten Schiers <carsten@schiers.de>
In-Reply-To: <zarafa.4eed13dd.0c2e.0c908eda504bffd9@uhura.space.zz>
References: <20111214220700.GA9926@phenom.dumpdata.com>
	<zarafa.4eed13dd.0c2e.0c908eda504bffd9@uhura.space.zz>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>,
	xen-devel <xen-devel@lists.xensource.com>, lersek@redhat.com,
	zhenzhong.duan@oracle.com, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] Load increase after memory upgrade (part2)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

I also have done some experiments with the patch, in domU i also get the 0%=
 full for my usb controllers with video grabbers , in dom0 my i get 12% ful=
l, both my realtek 8169 ethernet controllers seem to use the bounce bufferi=
ng ...
And that with a iommu (amd) ? it all seems kind of strange, although it is =
also working ...
I'm not having much time now, hoping to get back with a full report soon.

--
Sander

Saturday, December 17, 2011, 11:12:45 PM, you wrote:

> OK, double checked. Both PCI cards enabled, running, working, but nothing=
 but "SWIOTLB is 0% full". Any chance
> to check that the patch is working? Does it print out something else with=
 your setting? BR, Carsten.

> -----Urspr=FCngliche Nachricht-----
> Von: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-bounces@list=
s.xensource.com] Im Auftrag von Konrad Rzeszutek Wilk
> Gesendet: Freitag, 16. Dezember 2011 17:19
> An: Carsten Schiers
> Cc: linux@eikelenboom.it; xen-devel; lersek@redhat.com; zhenzhong.duan@or=
acle.com; Ian Campbell
> Betreff: Re: [Xen-devel] Load increase after memory upgrade (part2)

> On Fri, Dec 16, 2011 at 04:51:47PM +0100, Carsten Schiers wrote:
>> > And you are using swiotlb=3Dforce on the 2.6.34 classic kernel and pas=
sing in your budget-av card in it?
>> =

>> Yes, two of them with swiotlb=3D32,force.
>> =

>> =

>> > Could you append the dmesg output please?
>> =

>> Attached. You find a "normal" boot after the one with the patched kernel.

> Uh, what happens when you run the driver, meaning capture stuff. I rememb=
er with the pvops you had about ~30K or so of bounces, but not sure about t=
he bootup?

> Thanks for being willing to be a guinea pig while trying to fix this.
>> =

>> Carsten.
>> =

>> =




> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel




-- =

Best regards,
 Sander                            mailto:linux@eikelenboom.it


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Dec 18 03:47:39 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 18 Dec 2011 03:47:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rc7i7-0003oO-Lr; Sun, 18 Dec 2011 03:46:51 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Rc7i6-0003oJ-3I
	for xen-devel@lists.xensource.com; Sun, 18 Dec 2011 03:46:50 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1324180003!7163220!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzAzNQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26630 invoked from network); 18 Dec 2011 03:46:43 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Dec 2011 03:46:43 -0000
X-IronPort-AV: E=Sophos;i="4.71,370,1320624000"; 
   d="scan'208";a="9531990"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Dec 2011 03:46:42 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sun, 18 Dec 2011 03:46:42 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1Rc7hy-0001da-Gq;
	Sun, 18 Dec 2011 03:46:42 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Rc7hy-00051n-AY;
	Sun, 18 Dec 2011 03:46:42 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10529-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 18 Dec 2011 03:46:42 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10529: tolerable FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10529 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10529/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 build-amd64                   4 xen-build                   fail pass in 10528
 build-amd64-oldkern           4 xen-build                   fail pass in 10528
 build-amd64-pvops             4 kernel-build                fail pass in 10528
 test-amd64-amd64-xl-sedf      5 xen-boot           fail in 10528 pass in 10524
 test-i386-i386-win            7 windows-install    fail in 10528 pass in 10529

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf-pin  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win       1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-xl-pcipt-intel  9 guest-start        fail in 10528 never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2       fail in 10528 never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2         fail in 10528 never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop           fail in 10528 never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check      fail in 10528 never pass
 test-amd64-i386-win          16 leak-check/check      fail in 10528 never pass
 test-amd64-amd64-xl-win      13 guest-stop            fail in 10528 never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop           fail in 10528 never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop            fail in 10528 never pass
 test-amd64-amd64-win         16 leak-check/check      fail in 10528 never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop          fail in 10528 never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check     fail in 10528 never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop      fail in 10528 never pass

version targeted for testing:
 xen                  a4bff36780a3
baseline version:
 xen                  a4bff36780a3

jobs:
 build-amd64                                                  fail    
 build-i386                                                   pass    
 build-amd64-oldkern                                          fail    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            fail    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          blocked 
 test-amd64-i386-xl                                           blocked 
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-amd64-xl-win7-amd64                               blocked 
 test-amd64-i386-xl-win7-amd64                                blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-amd64-xl-pcipt-intel                              blocked 
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        blocked 
 test-amd64-i386-pair                                         blocked 
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 blocked 
 test-amd64-amd64-pv                                          blocked 
 test-amd64-i386-pv                                           blocked 
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     blocked 
 test-amd64-i386-win-vcpus1                                   blocked 
 test-amd64-i386-xl-win-vcpus1                                blocked 
 test-amd64-i386-xl-winxpsp3-vcpus1                           blocked 
 test-amd64-amd64-win                                         blocked 
 test-amd64-i386-win                                          blocked 
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      blocked 
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-xl-winxpsp3                                 blocked 
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Dec 18 03:47:39 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 18 Dec 2011 03:47:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rc7i7-0003oO-Lr; Sun, 18 Dec 2011 03:46:51 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Rc7i6-0003oJ-3I
	for xen-devel@lists.xensource.com; Sun, 18 Dec 2011 03:46:50 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1324180003!7163220!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzAzNQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26630 invoked from network); 18 Dec 2011 03:46:43 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Dec 2011 03:46:43 -0000
X-IronPort-AV: E=Sophos;i="4.71,370,1320624000"; 
   d="scan'208";a="9531990"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Dec 2011 03:46:42 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sun, 18 Dec 2011 03:46:42 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1Rc7hy-0001da-Gq;
	Sun, 18 Dec 2011 03:46:42 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Rc7hy-00051n-AY;
	Sun, 18 Dec 2011 03:46:42 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10529-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 18 Dec 2011 03:46:42 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10529: tolerable FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10529 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10529/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 build-amd64                   4 xen-build                   fail pass in 10528
 build-amd64-oldkern           4 xen-build                   fail pass in 10528
 build-amd64-pvops             4 kernel-build                fail pass in 10528
 test-amd64-amd64-xl-sedf      5 xen-boot           fail in 10528 pass in 10524
 test-i386-i386-win            7 windows-install    fail in 10528 pass in 10529

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf-pin  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win       1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-xl-pcipt-intel  9 guest-start        fail in 10528 never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2       fail in 10528 never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2         fail in 10528 never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop           fail in 10528 never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check      fail in 10528 never pass
 test-amd64-i386-win          16 leak-check/check      fail in 10528 never pass
 test-amd64-amd64-xl-win      13 guest-stop            fail in 10528 never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop           fail in 10528 never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop            fail in 10528 never pass
 test-amd64-amd64-win         16 leak-check/check      fail in 10528 never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop          fail in 10528 never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check     fail in 10528 never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop      fail in 10528 never pass

version targeted for testing:
 xen                  a4bff36780a3
baseline version:
 xen                  a4bff36780a3

jobs:
 build-amd64                                                  fail    
 build-i386                                                   pass    
 build-amd64-oldkern                                          fail    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            fail    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          blocked 
 test-amd64-i386-xl                                           blocked 
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-amd64-xl-win7-amd64                               blocked 
 test-amd64-i386-xl-win7-amd64                                blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-amd64-xl-pcipt-intel                              blocked 
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        blocked 
 test-amd64-i386-pair                                         blocked 
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 blocked 
 test-amd64-amd64-pv                                          blocked 
 test-amd64-i386-pv                                           blocked 
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     blocked 
 test-amd64-i386-win-vcpus1                                   blocked 
 test-amd64-i386-xl-win-vcpus1                                blocked 
 test-amd64-i386-xl-winxpsp3-vcpus1                           blocked 
 test-amd64-amd64-win                                         blocked 
 test-amd64-i386-win                                          blocked 
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      blocked 
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-xl-winxpsp3                                 blocked 
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Dec 18 04:33:37 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 18 Dec 2011 04:33:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rc8Qh-0004FG-9I; Sun, 18 Dec 2011 04:32:55 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <xen-devel.GarveyPatrickD@OrdinaryAmerican.net>)
	id 1Rc8Qf-0004F7-2e
	for xen-devel@lists.xensource.com; Sun, 18 Dec 2011 04:32:53 +0000
X-Env-Sender: xen-devel.GarveyPatrickD@OrdinaryAmerican.net
X-Msg-Ref: server-3.tower-174.messagelabs.com!1324182766!5916529!1
X-Originating-IP: [216.75.62.102]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14043 invoked from network); 18 Dec 2011 04:32:46 -0000
Received: from gourmet7.spamgourmet.com (HELO gourmet8.spamgourmet.com)
	(216.75.62.102) by server-3.tower-174.messagelabs.com with SMTP;
	18 Dec 2011 04:32:46 -0000
Received: from spamgourmet by gourmet7.spamgourmet.com with local (Exim 4.69)
	(envelope-from <xen-devel.GarveyPatrickD@OrdinaryAmerican.net>)
	id 1Rc8QX-0007J0-A4
	for xen-devel@lists.xensource.com; Sun, 18 Dec 2011 04:32:45 +0000
Received: from mail-tul01m020-f176.google.com ([209.85.214.176])
	by gourmet7.spamgourmet.com with esmtp (Exim 4.69)
	(envelope-from <xen-devel.GarveyPatrickD@OrdinaryAmerican.net>)
	id 1Rc8QX-0007Iv-48 for
	+xen-devel+GarveyPatrickD+fbe7693c78.xen-devel#lists.xensource.com@spamgourmet.com;
	Sun, 18 Dec 2011 04:32:45 +0000
Received: by obcwn14 with SMTP id wn14so1072295obc.7 for
	<+xen-devel+GarveyPatrickD+fbe7693c78.xen-devel#lists.xensource.com@spamgourmet.com>;
	Sat, 17 Dec 2011 20:32:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=mtr9zTnmSTCkYXV7kXwn2DsuErZhfC0eHqvdYvIY9xg=;
	b=X5fZV7On4zl8SVqFXN+T0fUWh03o1wvWzvwHUEUETOFwwsFxsfg+wehFYM5Z6jvXEx
	SaZyFluVelx3bbVS69QhlDJ9sLV+Lo9mzOLwbj28/by93pJDmVwsxa5A2LEcOf2ibhpH
	SbaZ1zZMDciHAe2ETZdgJToxx2yxeX1VSOl2Y=
MIME-Version: 1.0
Received: by 10.182.11.72 with SMTP id o8mr7381050obb.36.1324182763972; Sat,
	17 Dec 2011 20:32:43 -0800 (PST)
Received: by 10.182.16.163 with HTTP; Sat, 17 Dec 2011 20:32:43 -0800 (PST)
Date: Sat, 17 Dec 2011 20:32:43 -0800
Message-ID: <CACm5R6QfJw6wPCGVhevgm1kuVOLaoLTzb7ewhA5Ku47SBnzf4A@mail.gmail.com>
From: xen-devel.GarveyPatrickD@OrdinaryAmerican.net
To: xen-devel@lists.xensource.com
X-Spamgourmet: 
Subject: [Xen-devel] Wiki Speedy Deletion Categories and Templates
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Does the Xen.org need:
http://wiki.xen.org/wiki/Category:Speedy_deletion
http://wiki.xen.org/wiki/Category:Speedy_deletion_templates
http://wiki.xen.org/wiki/Template:Speedy_deletion_templates
http://wiki.xen.org/wiki/Template:Db_doc
http://wiki.xen.org/wiki/Template:Db-g1
http://wiki.xen.org/wiki/Template:Db-g3

I would like to suggest we don't have sufficient staff to make
distinguishing Speedy Deletions from Deletions a cost-effective use of
our time.

May I suggest these pages be deleted, themselves?

(Just trying to make this new wiki clean from the beginning so keeping
it clean will be easier.)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Dec 18 04:33:37 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 18 Dec 2011 04:33:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rc8Qh-0004FG-9I; Sun, 18 Dec 2011 04:32:55 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <xen-devel.GarveyPatrickD@OrdinaryAmerican.net>)
	id 1Rc8Qf-0004F7-2e
	for xen-devel@lists.xensource.com; Sun, 18 Dec 2011 04:32:53 +0000
X-Env-Sender: xen-devel.GarveyPatrickD@OrdinaryAmerican.net
X-Msg-Ref: server-3.tower-174.messagelabs.com!1324182766!5916529!1
X-Originating-IP: [216.75.62.102]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14043 invoked from network); 18 Dec 2011 04:32:46 -0000
Received: from gourmet7.spamgourmet.com (HELO gourmet8.spamgourmet.com)
	(216.75.62.102) by server-3.tower-174.messagelabs.com with SMTP;
	18 Dec 2011 04:32:46 -0000
Received: from spamgourmet by gourmet7.spamgourmet.com with local (Exim 4.69)
	(envelope-from <xen-devel.GarveyPatrickD@OrdinaryAmerican.net>)
	id 1Rc8QX-0007J0-A4
	for xen-devel@lists.xensource.com; Sun, 18 Dec 2011 04:32:45 +0000
Received: from mail-tul01m020-f176.google.com ([209.85.214.176])
	by gourmet7.spamgourmet.com with esmtp (Exim 4.69)
	(envelope-from <xen-devel.GarveyPatrickD@OrdinaryAmerican.net>)
	id 1Rc8QX-0007Iv-48 for
	+xen-devel+GarveyPatrickD+fbe7693c78.xen-devel#lists.xensource.com@spamgourmet.com;
	Sun, 18 Dec 2011 04:32:45 +0000
Received: by obcwn14 with SMTP id wn14so1072295obc.7 for
	<+xen-devel+GarveyPatrickD+fbe7693c78.xen-devel#lists.xensource.com@spamgourmet.com>;
	Sat, 17 Dec 2011 20:32:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=mtr9zTnmSTCkYXV7kXwn2DsuErZhfC0eHqvdYvIY9xg=;
	b=X5fZV7On4zl8SVqFXN+T0fUWh03o1wvWzvwHUEUETOFwwsFxsfg+wehFYM5Z6jvXEx
	SaZyFluVelx3bbVS69QhlDJ9sLV+Lo9mzOLwbj28/by93pJDmVwsxa5A2LEcOf2ibhpH
	SbaZ1zZMDciHAe2ETZdgJToxx2yxeX1VSOl2Y=
MIME-Version: 1.0
Received: by 10.182.11.72 with SMTP id o8mr7381050obb.36.1324182763972; Sat,
	17 Dec 2011 20:32:43 -0800 (PST)
Received: by 10.182.16.163 with HTTP; Sat, 17 Dec 2011 20:32:43 -0800 (PST)
Date: Sat, 17 Dec 2011 20:32:43 -0800
Message-ID: <CACm5R6QfJw6wPCGVhevgm1kuVOLaoLTzb7ewhA5Ku47SBnzf4A@mail.gmail.com>
From: xen-devel.GarveyPatrickD@OrdinaryAmerican.net
To: xen-devel@lists.xensource.com
X-Spamgourmet: 
Subject: [Xen-devel] Wiki Speedy Deletion Categories and Templates
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Does the Xen.org need:
http://wiki.xen.org/wiki/Category:Speedy_deletion
http://wiki.xen.org/wiki/Category:Speedy_deletion_templates
http://wiki.xen.org/wiki/Template:Speedy_deletion_templates
http://wiki.xen.org/wiki/Template:Db_doc
http://wiki.xen.org/wiki/Template:Db-g1
http://wiki.xen.org/wiki/Template:Db-g3

I would like to suggest we don't have sufficient staff to make
distinguishing Speedy Deletions from Deletions a cost-effective use of
our time.

May I suggest these pages be deleted, themselves?

(Just trying to make this new wiki clean from the beginning so keeping
it clean will be easier.)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Dec 18 12:50:15 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 18 Dec 2011 12: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.xensource.com>)
	id 1RcGBI-0007bm-98; Sun, 18 Dec 2011 12:49:32 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RcGBH-0007be-2p
	for xen-devel@lists.xensource.com; Sun, 18 Dec 2011 12:49:31 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1324212562!8305109!1
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8122 invoked from network); 18 Dec 2011 12:49:25 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Dec 2011 12:49:25 -0000
Received: by werg1 with SMTP id g1so3226097wer.30
	for <xen-devel@lists.xensource.com>;
	Sun, 18 Dec 2011 04:49:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:message-id:user-agent:date:from:to;
	bh=4wXRRmJfkceM8qbwXn+THnehlvaReVR67VB8tL97EM4=;
	b=VI/EQRP59OgdO9UlJ9WS+Xc0PM4ro+9hzaMS+7fcrLte96gDg03HLLDLEAQIptZDlv
	rTsH1bb2E0MNViwso+OuM0iqVX7ViRHp6vm4MOi5uGg8I19KOgfcj+oVxJgA3uc9hBab
	+V0eJ8WWo5x7jBukjGHJcHL3edIT8xeoPeW+0=
Received: by 10.216.139.15 with SMTP id b15mr5549750wej.15.1324212561847;
	Sun, 18 Dec 2011 04:49:21 -0800 (PST)
Received: from alpine.localdomain (234.Red-80-25-94.staticIP.rima-tde.net.
	[80.25.94.234]) by mx.google.com with ESMTPS id
	et20sm21847393wbb.15.2011.12.18.04.49.18
	(version=TLSv1/SSLv3 cipher=OTHER);
	Sun, 18 Dec 2011 04:49:19 -0800 (PST)
MIME-Version: 1.0
Message-Id: <patchbomb.1324212500@alpine.localdomain>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Sun, 18 Dec 2011 13:48:20 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 0 of 5] build: various fixes for building with
	uclibc
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This patch contains various fixes to the build system to allow
building xen under uclibc. Has been tested with uclibc 0.9.32 and
gcc 4.6.2, from Alpine Linux 2.3.2.

Please review, Roger.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Dec 18 12:50:15 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 18 Dec 2011 12: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.xensource.com>)
	id 1RcGBI-0007bm-98; Sun, 18 Dec 2011 12:49:32 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RcGBH-0007be-2p
	for xen-devel@lists.xensource.com; Sun, 18 Dec 2011 12:49:31 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1324212562!8305109!1
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8122 invoked from network); 18 Dec 2011 12:49:25 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Dec 2011 12:49:25 -0000
Received: by werg1 with SMTP id g1so3226097wer.30
	for <xen-devel@lists.xensource.com>;
	Sun, 18 Dec 2011 04:49:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:message-id:user-agent:date:from:to;
	bh=4wXRRmJfkceM8qbwXn+THnehlvaReVR67VB8tL97EM4=;
	b=VI/EQRP59OgdO9UlJ9WS+Xc0PM4ro+9hzaMS+7fcrLte96gDg03HLLDLEAQIptZDlv
	rTsH1bb2E0MNViwso+OuM0iqVX7ViRHp6vm4MOi5uGg8I19KOgfcj+oVxJgA3uc9hBab
	+V0eJ8WWo5x7jBukjGHJcHL3edIT8xeoPeW+0=
Received: by 10.216.139.15 with SMTP id b15mr5549750wej.15.1324212561847;
	Sun, 18 Dec 2011 04:49:21 -0800 (PST)
Received: from alpine.localdomain (234.Red-80-25-94.staticIP.rima-tde.net.
	[80.25.94.234]) by mx.google.com with ESMTPS id
	et20sm21847393wbb.15.2011.12.18.04.49.18
	(version=TLSv1/SSLv3 cipher=OTHER);
	Sun, 18 Dec 2011 04:49:19 -0800 (PST)
MIME-Version: 1.0
Message-Id: <patchbomb.1324212500@alpine.localdomain>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Sun, 18 Dec 2011 13:48:20 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 0 of 5] build: various fixes for building with
	uclibc
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This patch contains various fixes to the build system to allow
building xen under uclibc. Has been tested with uclibc 0.9.32 and
gcc 4.6.2, from Alpine Linux 2.3.2.

Please review, Roger.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Dec 18 12:50:16 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 18 Dec 2011 12:50:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RcGBR-0007d7-SC; Sun, 18 Dec 2011 12:49:41 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RcGBQ-0007c4-Ad
	for xen-devel@lists.xensource.com; Sun, 18 Dec 2011 12:49:40 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1324212565!7905446!3
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11556 invoked from network); 18 Dec 2011 12:49:34 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Dec 2011 12:49:34 -0000
Received: by mail-ww0-f43.google.com with SMTP id ds11so7713360wgb.24
	for <xen-devel@lists.xensource.com>;
	Sun, 18 Dec 2011 04:49:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=JeqX3siSyZGqjKARt4dNJUCnzr2tv6M/ADckrvGw/sc=;
	b=hTj9NDnqnf5YmY7N7gCZwd/ObCbFTVHK8HF/ePzncOny5AMy29oLgYfklUtzcncvEA
	mg5sVXtbwAavtTX3/Nq/cnsOd9ZHDKXeUi7j7B5pqWGojF8TJlH8ynwhfBjOc/0aJdxh
	rQfP3/+h56q/+D5qwCtxhGUlRIvgi//Y6VE9I=
Received: by 10.227.209.66 with SMTP id gf2mr9606826wbb.20.1324212574129;
	Sun, 18 Dec 2011 04:49:34 -0800 (PST)
Received: from alpine.localdomain (234.Red-80-25-94.staticIP.rima-tde.net.
	[80.25.94.234]) by mx.google.com with ESMTPS id
	et20sm21847393wbb.15.2011.12.18.04.49.31
	(version=TLSv1/SSLv3 cipher=OTHER);
	Sun, 18 Dec 2011 04:49:32 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 7bcb3a61ce8846f8e7834d14c460c0f4b4869222
Message-Id: <7bcb3a61ce8846f8e783.1324212504@alpine.localdomain>
In-Reply-To: <patchbomb.1324212500@alpine.localdomain>
References: <patchbomb.1324212500@alpine.localdomain>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Sun, 18 Dec 2011 13:48:24 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 4 of 5] blktap2: remove HAVE_BYTESWAP_H checking,
 since it's defined by qemu
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1324171782 -3600
# Node ID 7bcb3a61ce8846f8e7834d14c460c0f4b4869222
# Parent  c0d5aa328f1ab24aad5880e720852b6dc8ffd4fb
blktap2: remove HAVE_BYTESWAP_H checking, since it's defined by qemu

blktap2 was using defines set by qemu, even when the qemu config file
is not included. Remove this checkings, and instead check if the file
has been included before defining the necessary macros.

The output error is:

bswap.h:23:0: error: "bswap_16" redefined [-Werror]
/usr/include/byteswap.h:30:0: note: this is the location of the
previous definition
bswap.h:31:0: error: "bswap_32" redefined [-Werror]
/usr/include/byteswap.h:33:0: note: this is the location of the
previous definition
bswap.h:41:0: error: "bswap_64" redefined [-Werror]
/usr/include/byteswap.h:37:0: note: this is the location of the
previous definition
cc1: all warnings being treated as errors

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r c0d5aa328f1a -r 7bcb3a61ce88 tools/blktap2/drivers/bswap.h
--- a/tools/blktap2/drivers/bswap.h	Sun Dec 18 02:29:42 2011 +0100
+++ b/tools/blktap2/drivers/bswap.h	Sun Dec 18 02:29:42 2011 +0100
@@ -15,9 +15,7 @@
 #define bswap_64(x) swap64(x)
 #else
 
-#ifdef HAVE_BYTESWAP_H
-#include <byteswap.h>
-#else
+#ifndef _BYTESWAP_H
 
 #define bswap_16(x) \
 ({ \
@@ -51,7 +49,7 @@
 		(uint64_t)(((uint64_t)(__x) & (uint64_t)0xff00000000000000ULL) >> 56) )); \
 })
 
-#endif /* !HAVE_BYTESWAP_H */
+#endif /* !_BYTESWAP_H */
 
 static inline uint16_t bswap16(uint16_t x)
 {

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Dec 18 12:50:16 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 18 Dec 2011 12:50:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RcGBM-0007c9-23; Sun, 18 Dec 2011 12:49:36 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RcGBK-0007bg-NL
	for xen-devel@lists.xensource.com; Sun, 18 Dec 2011 12:49:34 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1324212562!8305109!2
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8170 invoked from network); 18 Dec 2011 12:49:28 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Dec 2011 12:49:28 -0000
Received: by mail-we0-f171.google.com with SMTP id g1so3226097wer.30
	for <xen-devel@lists.xensource.com>;
	Sun, 18 Dec 2011 04:49:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=Whpo7pnhkv25gtXirWqQIJYzqhyQAfs4p4xjyld32Wg=;
	b=k+WNJolD6R6pnzQ+PhOKPdA/pMQyWNtFMd0WA+EW2n14xKKwLVq8BmDiyAtqfPgTKF
	TevFAc3dCKGkyL/mcJ9joVB6apA7izAqOE+4Af/MQrCz8vdvbUgHzGUa59Cw/DJqzlun
	i9uu0NQuVXRluoA3bEyB0FEGM8MLk0M4MSbDw=
Received: by 10.216.138.159 with SMTP id a31mr2945758wej.20.1324212568655;
	Sun, 18 Dec 2011 04:49:28 -0800 (PST)
Received: from alpine.localdomain (234.Red-80-25-94.staticIP.rima-tde.net.
	[80.25.94.234]) by mx.google.com with ESMTPS id
	et20sm21847393wbb.15.2011.12.18.04.49.25
	(version=TLSv1/SSLv3 cipher=OTHER);
	Sun, 18 Dec 2011 04:49:27 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: c54c326d6fdf26d311c872479b769b3a8cd560cf
Message-Id: <c54c326d6fdf26d311c8.1324212502@alpine.localdomain>
In-Reply-To: <patchbomb.1324212500@alpine.localdomain>
References: <patchbomb.1324212500@alpine.localdomain>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Sun, 18 Dec 2011 13:48:22 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 2 of 5] build: detect uclibc
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1324171782 -3600
# Node ID c54c326d6fdf26d311c872479b769b3a8cd560cf
# Parent  eed78eb655c40b0ac9af1b14c1cc03204f696b0b
build: detect uclibc

Detect uclibc build environment and define CONFIG_UCLIBC accordingly.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r eed78eb655c4 -r c54c326d6fdf Config.mk
--- a/Config.mk	Sun Dec 18 02:29:42 2011 +0100
+++ b/Config.mk	Sun Dec 18 02:29:42 2011 +0100
@@ -18,6 +18,8 @@ XEN_TARGET_ARCH     ?= $(XEN_COMPILE_ARC
 XEN_OS              ?= $(shell uname -s)
 
 CONFIG_$(XEN_OS) := y
+CONFIG_UCLIBC    := $(shell gcc -dumpmachine | grep -c uclibc \
+                      | sed -e s/[^0]/y/ -e s/0/n/)
 
 SHELL     ?= /bin/sh
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Dec 18 12:50:16 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 18 Dec 2011 12:50:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RcGBM-0007c9-23; Sun, 18 Dec 2011 12:49:36 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RcGBK-0007bg-NL
	for xen-devel@lists.xensource.com; Sun, 18 Dec 2011 12:49:34 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1324212562!8305109!2
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8170 invoked from network); 18 Dec 2011 12:49:28 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Dec 2011 12:49:28 -0000
Received: by mail-we0-f171.google.com with SMTP id g1so3226097wer.30
	for <xen-devel@lists.xensource.com>;
	Sun, 18 Dec 2011 04:49:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=Whpo7pnhkv25gtXirWqQIJYzqhyQAfs4p4xjyld32Wg=;
	b=k+WNJolD6R6pnzQ+PhOKPdA/pMQyWNtFMd0WA+EW2n14xKKwLVq8BmDiyAtqfPgTKF
	TevFAc3dCKGkyL/mcJ9joVB6apA7izAqOE+4Af/MQrCz8vdvbUgHzGUa59Cw/DJqzlun
	i9uu0NQuVXRluoA3bEyB0FEGM8MLk0M4MSbDw=
Received: by 10.216.138.159 with SMTP id a31mr2945758wej.20.1324212568655;
	Sun, 18 Dec 2011 04:49:28 -0800 (PST)
Received: from alpine.localdomain (234.Red-80-25-94.staticIP.rima-tde.net.
	[80.25.94.234]) by mx.google.com with ESMTPS id
	et20sm21847393wbb.15.2011.12.18.04.49.25
	(version=TLSv1/SSLv3 cipher=OTHER);
	Sun, 18 Dec 2011 04:49:27 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: c54c326d6fdf26d311c872479b769b3a8cd560cf
Message-Id: <c54c326d6fdf26d311c8.1324212502@alpine.localdomain>
In-Reply-To: <patchbomb.1324212500@alpine.localdomain>
References: <patchbomb.1324212500@alpine.localdomain>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Sun, 18 Dec 2011 13:48:22 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 2 of 5] build: detect uclibc
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1324171782 -3600
# Node ID c54c326d6fdf26d311c872479b769b3a8cd560cf
# Parent  eed78eb655c40b0ac9af1b14c1cc03204f696b0b
build: detect uclibc

Detect uclibc build environment and define CONFIG_UCLIBC accordingly.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r eed78eb655c4 -r c54c326d6fdf Config.mk
--- a/Config.mk	Sun Dec 18 02:29:42 2011 +0100
+++ b/Config.mk	Sun Dec 18 02:29:42 2011 +0100
@@ -18,6 +18,8 @@ XEN_TARGET_ARCH     ?= $(XEN_COMPILE_ARC
 XEN_OS              ?= $(shell uname -s)
 
 CONFIG_$(XEN_OS) := y
+CONFIG_UCLIBC    := $(shell gcc -dumpmachine | grep -c uclibc \
+                      | sed -e s/[^0]/y/ -e s/0/n/)
 
 SHELL     ?= /bin/sh
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Dec 18 12:50:16 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 18 Dec 2011 12:50:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RcGBR-0007d7-SC; Sun, 18 Dec 2011 12:49:41 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RcGBQ-0007c4-Ad
	for xen-devel@lists.xensource.com; Sun, 18 Dec 2011 12:49:40 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1324212565!7905446!3
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11556 invoked from network); 18 Dec 2011 12:49:34 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Dec 2011 12:49:34 -0000
Received: by mail-ww0-f43.google.com with SMTP id ds11so7713360wgb.24
	for <xen-devel@lists.xensource.com>;
	Sun, 18 Dec 2011 04:49:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=JeqX3siSyZGqjKARt4dNJUCnzr2tv6M/ADckrvGw/sc=;
	b=hTj9NDnqnf5YmY7N7gCZwd/ObCbFTVHK8HF/ePzncOny5AMy29oLgYfklUtzcncvEA
	mg5sVXtbwAavtTX3/Nq/cnsOd9ZHDKXeUi7j7B5pqWGojF8TJlH8ynwhfBjOc/0aJdxh
	rQfP3/+h56q/+D5qwCtxhGUlRIvgi//Y6VE9I=
Received: by 10.227.209.66 with SMTP id gf2mr9606826wbb.20.1324212574129;
	Sun, 18 Dec 2011 04:49:34 -0800 (PST)
Received: from alpine.localdomain (234.Red-80-25-94.staticIP.rima-tde.net.
	[80.25.94.234]) by mx.google.com with ESMTPS id
	et20sm21847393wbb.15.2011.12.18.04.49.31
	(version=TLSv1/SSLv3 cipher=OTHER);
	Sun, 18 Dec 2011 04:49:32 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 7bcb3a61ce8846f8e7834d14c460c0f4b4869222
Message-Id: <7bcb3a61ce8846f8e783.1324212504@alpine.localdomain>
In-Reply-To: <patchbomb.1324212500@alpine.localdomain>
References: <patchbomb.1324212500@alpine.localdomain>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Sun, 18 Dec 2011 13:48:24 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 4 of 5] blktap2: remove HAVE_BYTESWAP_H checking,
 since it's defined by qemu
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1324171782 -3600
# Node ID 7bcb3a61ce8846f8e7834d14c460c0f4b4869222
# Parent  c0d5aa328f1ab24aad5880e720852b6dc8ffd4fb
blktap2: remove HAVE_BYTESWAP_H checking, since it's defined by qemu

blktap2 was using defines set by qemu, even when the qemu config file
is not included. Remove this checkings, and instead check if the file
has been included before defining the necessary macros.

The output error is:

bswap.h:23:0: error: "bswap_16" redefined [-Werror]
/usr/include/byteswap.h:30:0: note: this is the location of the
previous definition
bswap.h:31:0: error: "bswap_32" redefined [-Werror]
/usr/include/byteswap.h:33:0: note: this is the location of the
previous definition
bswap.h:41:0: error: "bswap_64" redefined [-Werror]
/usr/include/byteswap.h:37:0: note: this is the location of the
previous definition
cc1: all warnings being treated as errors

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r c0d5aa328f1a -r 7bcb3a61ce88 tools/blktap2/drivers/bswap.h
--- a/tools/blktap2/drivers/bswap.h	Sun Dec 18 02:29:42 2011 +0100
+++ b/tools/blktap2/drivers/bswap.h	Sun Dec 18 02:29:42 2011 +0100
@@ -15,9 +15,7 @@
 #define bswap_64(x) swap64(x)
 #else
 
-#ifdef HAVE_BYTESWAP_H
-#include <byteswap.h>
-#else
+#ifndef _BYTESWAP_H
 
 #define bswap_16(x) \
 ({ \
@@ -51,7 +49,7 @@
 		(uint64_t)(((uint64_t)(__x) & (uint64_t)0xff00000000000000ULL) >> 56) )); \
 })
 
-#endif /* !HAVE_BYTESWAP_H */
+#endif /* !_BYTESWAP_H */
 
 static inline uint16_t bswap16(uint16_t x)
 {

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Dec 18 12:50:16 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 18 Dec 2011 12:50:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RcGBU-0007df-9Z; Sun, 18 Dec 2011 12:49:44 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RcGBS-0007cI-Uw
	for xen-devel@lists.xensource.com; Sun, 18 Dec 2011 12:49:43 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1324212562!8305109!3
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP,UPPERCASE_25_50
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8251 invoked from network); 18 Dec 2011 12:49:37 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Dec 2011 12:49:37 -0000
Received: by mail-we0-f171.google.com with SMTP id g1so3226097wer.30
	for <xen-devel@lists.xensource.com>;
	Sun, 18 Dec 2011 04:49:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=yvJ6Rr7g31oUGS+BhOzAQddok5oCBEfa5RvW4xSpvWo=;
	b=d2rUepBILzkZHKpqObS+5UNqKjDHXyn4VlMxArk7c26+dikm1xlwv97DROXXJA0KUG
	s2vS0+ovEeVODD+71dLaA59L7HBL/Y8SKHaOirrfzhN5J91LlmKh/Lhg64+QRYJx89Jg
	PJRuBlXz7Tp4gaE8eh0LhrMDrOB4gImqaxV6Q=
Received: by 10.216.132.8 with SMTP id n8mr2970832wei.35.1324212576986;
	Sun, 18 Dec 2011 04:49:36 -0800 (PST)
Received: from alpine.localdomain (234.Red-80-25-94.staticIP.rima-tde.net.
	[80.25.94.234]) by mx.google.com with ESMTPS id
	et20sm21847393wbb.15.2011.12.18.04.49.34
	(version=TLSv1/SSLv3 cipher=OTHER);
	Sun, 18 Dec 2011 04:49:35 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 6780cbdfa64b148b0c372a4f82448f707ad2be59
Message-Id: <6780cbdfa64b148b0c37.1324212505@alpine.localdomain>
In-Reply-To: <patchbomb.1324212500@alpine.localdomain>
References: <patchbomb.1324212500@alpine.localdomain>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Sun, 18 Dec 2011 13:48:25 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 5 of 5] libxl: fix link issue on uclibc when
	using yajl
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1324171782 -3600
# Node ID 6780cbdfa64b148b0c372a4f82448f707ad2be59
# Parent  7bcb3a61ce8846f8e7834d14c460c0f4b4869222
libxl: fix link issue on uclibc when using yajl

yajl makes use of the isnan isinf functions. On Glibc, these are
provided by libc, but on uClibc you need to link with -lm (like the
spec says), so ensure we do so.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 7bcb3a61ce88 -r 6780cbdfa64b tools/libxl/Makefile
--- a/tools/libxl/Makefile	Sun Dec 18 02:29:42 2011 +0100
+++ b/tools/libxl/Makefile	Sun Dec 18 02:29:42 2011 +0100
@@ -24,6 +24,10 @@ LIBXL_LIBS = $(LDLIBS_libxenctrl) $(LDLI
 
 LIBXLU_LIBS =
 
+XL_LIBS =
+
+TESTIDL_LIBS =
+
 LIBXL_OBJS-y = osdeps.o libxl_paths.o libxl_bootloader.o flexarray.o
 ifeq ($(LIBXL_BLKTAP),y)
 LIBXL_OBJS-y += libxl_blktap2.o
@@ -35,6 +39,12 @@ LIBXL_OBJS-$(CONFIG_IA64) += libxl_nocpu
 
 LIBXL_LIBS += -lyajl
 
+ifeq ($(CONFIG_UCLIBC),y)
+LIBXL_LIBS += -lm
+XL_LIBS += -lm
+TESTIDL_LIBS += -lm
+endif
+
 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 \
@@ -127,10 +137,10 @@ libxlutil.a: $(LIBXLU_OBJS)
 	$(AR) rcs libxlutil.a $^
 
 xl: $(XL_OBJS) libxlutil.so libxenlight.so
-	$(CC) $(LDFLAGS) -o $@ $(XL_OBJS) libxlutil.so $(LDLIBS_libxenlight) $(LDLIBS_libxenctrl) $(APPEND_LDFLAGS)
+	$(CC) $(LDFLAGS) -o $@ $(XL_OBJS) libxlutil.so $(LDLIBS_libxenlight) $(LDLIBS_libxenctrl) $(XL_LIBS) $(APPEND_LDFLAGS)
 
 testidl: testidl.o libxlutil.so libxenlight.so
-	$(CC) $(LDFLAGS) -o $@ testidl.o libxlutil.so $(LDLIBS_libxenlight) $(LDLIBS_libxenctrl) $(APPEND_LDFLAGS)
+	$(CC) $(LDFLAGS) -o $@ testidl.o libxlutil.so $(LDLIBS_libxenlight) $(LDLIBS_libxenctrl) $(TESTIDL_LIBS) $(APPEND_LDFLAGS)
 
 .PHONY: install
 install: all

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Dec 18 12:50:16 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 18 Dec 2011 12:50:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RcGBO-0007cT-Em; Sun, 18 Dec 2011 12:49:38 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RcGBN-0007bl-En
	for xen-devel@lists.xensource.com; Sun, 18 Dec 2011 12:49:37 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1324212565!7905446!2
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11536 invoked from network); 18 Dec 2011 12:49:31 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Dec 2011 12:49:31 -0000
Received: by mail-ww0-f43.google.com with SMTP id ds11so7713360wgb.24
	for <xen-devel@lists.xensource.com>;
	Sun, 18 Dec 2011 04:49:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=krGjsylC6lkPJiXS8cMBkxFIRbhlzDkbHZVzm5plwmk=;
	b=EI56N4Zcj4G1Sl3FkEcYdS7Hx0LNGnxawSGjuiiBBhkG4rjwnCDDpkSn1SBB/gxa0m
	/5Gw6tGSLi9DTWQga432itjDi+U8F5v1W8NX8/xTDtx06ZKBDsh0Ydf5hqYmLW8M8zss
	IF3mIx6d651msR/+GurEyAZNyjL5KwSlecizk=
Received: by 10.180.102.4 with SMTP id fk4mr21882639wib.15.1324212571389;
	Sun, 18 Dec 2011 04:49:31 -0800 (PST)
Received: from alpine.localdomain (234.Red-80-25-94.staticIP.rima-tde.net.
	[80.25.94.234]) by mx.google.com with ESMTPS id
	et20sm21847393wbb.15.2011.12.18.04.49.28
	(version=TLSv1/SSLv3 cipher=OTHER);
	Sun, 18 Dec 2011 04:49:29 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: c0d5aa328f1ab24aad5880e720852b6dc8ffd4fb
Message-Id: <c0d5aa328f1ab24aad58.1324212503@alpine.localdomain>
In-Reply-To: <patchbomb.1324212500@alpine.localdomain>
References: <patchbomb.1324212500@alpine.localdomain>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Sun, 18 Dec 2011 13:48:23 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 3 of 5] blktap2: fix vhd compilation under uclibc
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1324171782 -3600
# Node ID c0d5aa328f1ab24aad5880e720852b6dc8ffd4fb
# Parent  c54c326d6fdf26d311c872479b769b3a8cd560cf
blktap2: fix vhd compilation under uclibc

blktap2 was not compiled succesfully under uclibc, with the following
error:

gcc     -o vhd-util vhd-util.o -Llib -lvhd
lib/libvhd.so: undefined reference to `libiconv_open'
lib/libvhd.so: undefined reference to `libiconv_close'
lib/libvhd.so: undefined reference to `libiconv'

This patchs add the flag -liconv when blktap2/vhd is compiled on
uclibc.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r c54c326d6fdf -r c0d5aa328f1a tools/blktap2/drivers/Makefile
--- a/tools/blktap2/drivers/Makefile	Sun Dec 18 02:29:42 2011 +0100
+++ b/tools/blktap2/drivers/Makefile	Sun Dec 18 02:29:42 2011 +0100
@@ -24,6 +24,10 @@ endif
 
 VHDLIBS    := -L$(LIBVHDDIR) -lvhd
 
+ifeq ($(CONFIG_UCLIBC),y)
+VHDLIBS    += -liconv
+endif
+
 REMUS-OBJS  := block-remus.o
 REMUS-OBJS  += hashtable.o
 REMUS-OBJS  += hashtable_itr.o
diff -r c54c326d6fdf -r c0d5aa328f1a tools/blktap2/vhd/Makefile
--- a/tools/blktap2/vhd/Makefile	Sun Dec 18 02:29:42 2011 +0100
+++ b/tools/blktap2/vhd/Makefile	Sun Dec 18 02:29:42 2011 +0100
@@ -23,6 +23,10 @@ endif
 
 LIBS              := -Llib -lvhd
 
+ifeq ($(CONFIG_UCLIBC),y)
+LIBS              += -liconv
+endif
+
 all: subdirs-all build
 
 build: $(IBIN)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Dec 18 12:50:16 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 18 Dec 2011 12:50:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RcGBJ-0007bx-LO; Sun, 18 Dec 2011 12:49:33 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RcGBI-0007bf-2L
	for xen-devel@lists.xensource.com; Sun, 18 Dec 2011 12:49:32 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1324212565!7905446!1
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11432 invoked from network); 18 Dec 2011 12:49:26 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Dec 2011 12:49:26 -0000
Received: by wgbds11 with SMTP id ds11so7713360wgb.24
	for <xen-devel@lists.xensource.com>;
	Sun, 18 Dec 2011 04:49:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=ebwZwPtLBos8+l+OdAup0PJOY4p29tsKMcu28xEGkCA=;
	b=qnzKzyGF6NmcQ6WjrfxSKef2OvJBUPuu5T/UNgCe1CCzUm6gHK8F9b3AjKAwOKaRO/
	VvM2MPDmzbM2nxzgZXKnkmNjS5UM1wjdQMN+bHewW90Yva3CvWJ2RGjeeqOwnjZd/Bgm
	TQkkqDlGHXwORplif2PPVXrP4JiKfHPE3ex5A=
Received: by 10.227.197.78 with SMTP id ej14mr9761466wbb.2.1324212565746;
	Sun, 18 Dec 2011 04:49:25 -0800 (PST)
Received: from alpine.localdomain (234.Red-80-25-94.staticIP.rima-tde.net.
	[80.25.94.234]) by mx.google.com with ESMTPS id
	et20sm21847393wbb.15.2011.12.18.04.49.21
	(version=TLSv1/SSLv3 cipher=OTHER);
	Sun, 18 Dec 2011 04:49:24 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: eed78eb655c40b0ac9af1b14c1cc03204f696b0b
Message-Id: <eed78eb655c40b0ac9af.1324212501@alpine.localdomain>
In-Reply-To: <patchbomb.1324212500@alpine.localdomain>
References: <patchbomb.1324212500@alpine.localdomain>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Sun, 18 Dec 2011 13:48:21 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 1 of 5] blktap: remove HAVE_BYTESWAP_H checking,
 since it's defined by qemu
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1324171782 -3600
# Node ID eed78eb655c40b0ac9af1b14c1cc03204f696b0b
# Parent  b783e76e63a99c9d87fca4974492f60af99a2e7a
blktap: remove HAVE_BYTESWAP_H checking, since it's defined by qemu

blktap was using defines set by qemu, even when the qemu config file
is not included. Remove this checkings, and instead check if the file
has been included before defining the necessary macros.

The output error is:

In file included from block-qcow.c:37:0:
bswap.h:23:0: error: "bswap_16" redefined [-Werror]
/usr/include/byteswap.h:30:0: note: this is the location of the
previous definition
bswap.h:31:0: error: "bswap_32" redefined [-Werror]
/usr/include/byteswap.h:33:0: note: this is the location of the
previous definition
bswap.h:41:0: error: "bswap_64" redefined [-Werror]
/usr/include/byteswap.h:37:0: note: this is the location of the
previous definition
cc1: all warnings being treated as errors

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r b783e76e63a9 -r eed78eb655c4 tools/blktap/drivers/bswap.h
--- a/tools/blktap/drivers/bswap.h	Sun Dec 18 02:29:42 2011 +0100
+++ b/tools/blktap/drivers/bswap.h	Sun Dec 18 02:29:42 2011 +0100
@@ -15,9 +15,7 @@
 #define bswap_64(x) swap64(x)
 #else
 
-#ifdef HAVE_BYTESWAP_H
-#include <byteswap.h>
-#else
+#ifndef _BYTESWAP_H
 
 #define bswap_16(x) \
 ({ \
@@ -51,7 +49,7 @@
 		(uint64_t)(((uint64_t)(__x) & (uint64_t)0xff00000000000000ULL) >> 56) )); \
 })
 
-#endif /* !HAVE_BYTESWAP_H */
+#endif /* !_BYTESWAP_H */
 
 static inline uint16_t bswap16(uint16_t x)
 {

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Dec 18 12:50:16 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 18 Dec 2011 12:50:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RcGBU-0007df-9Z; Sun, 18 Dec 2011 12:49:44 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RcGBS-0007cI-Uw
	for xen-devel@lists.xensource.com; Sun, 18 Dec 2011 12:49:43 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1324212562!8305109!3
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP,UPPERCASE_25_50
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8251 invoked from network); 18 Dec 2011 12:49:37 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Dec 2011 12:49:37 -0000
Received: by mail-we0-f171.google.com with SMTP id g1so3226097wer.30
	for <xen-devel@lists.xensource.com>;
	Sun, 18 Dec 2011 04:49:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=yvJ6Rr7g31oUGS+BhOzAQddok5oCBEfa5RvW4xSpvWo=;
	b=d2rUepBILzkZHKpqObS+5UNqKjDHXyn4VlMxArk7c26+dikm1xlwv97DROXXJA0KUG
	s2vS0+ovEeVODD+71dLaA59L7HBL/Y8SKHaOirrfzhN5J91LlmKh/Lhg64+QRYJx89Jg
	PJRuBlXz7Tp4gaE8eh0LhrMDrOB4gImqaxV6Q=
Received: by 10.216.132.8 with SMTP id n8mr2970832wei.35.1324212576986;
	Sun, 18 Dec 2011 04:49:36 -0800 (PST)
Received: from alpine.localdomain (234.Red-80-25-94.staticIP.rima-tde.net.
	[80.25.94.234]) by mx.google.com with ESMTPS id
	et20sm21847393wbb.15.2011.12.18.04.49.34
	(version=TLSv1/SSLv3 cipher=OTHER);
	Sun, 18 Dec 2011 04:49:35 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 6780cbdfa64b148b0c372a4f82448f707ad2be59
Message-Id: <6780cbdfa64b148b0c37.1324212505@alpine.localdomain>
In-Reply-To: <patchbomb.1324212500@alpine.localdomain>
References: <patchbomb.1324212500@alpine.localdomain>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Sun, 18 Dec 2011 13:48:25 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 5 of 5] libxl: fix link issue on uclibc when
	using yajl
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1324171782 -3600
# Node ID 6780cbdfa64b148b0c372a4f82448f707ad2be59
# Parent  7bcb3a61ce8846f8e7834d14c460c0f4b4869222
libxl: fix link issue on uclibc when using yajl

yajl makes use of the isnan isinf functions. On Glibc, these are
provided by libc, but on uClibc you need to link with -lm (like the
spec says), so ensure we do so.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 7bcb3a61ce88 -r 6780cbdfa64b tools/libxl/Makefile
--- a/tools/libxl/Makefile	Sun Dec 18 02:29:42 2011 +0100
+++ b/tools/libxl/Makefile	Sun Dec 18 02:29:42 2011 +0100
@@ -24,6 +24,10 @@ LIBXL_LIBS = $(LDLIBS_libxenctrl) $(LDLI
 
 LIBXLU_LIBS =
 
+XL_LIBS =
+
+TESTIDL_LIBS =
+
 LIBXL_OBJS-y = osdeps.o libxl_paths.o libxl_bootloader.o flexarray.o
 ifeq ($(LIBXL_BLKTAP),y)
 LIBXL_OBJS-y += libxl_blktap2.o
@@ -35,6 +39,12 @@ LIBXL_OBJS-$(CONFIG_IA64) += libxl_nocpu
 
 LIBXL_LIBS += -lyajl
 
+ifeq ($(CONFIG_UCLIBC),y)
+LIBXL_LIBS += -lm
+XL_LIBS += -lm
+TESTIDL_LIBS += -lm
+endif
+
 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 \
@@ -127,10 +137,10 @@ libxlutil.a: $(LIBXLU_OBJS)
 	$(AR) rcs libxlutil.a $^
 
 xl: $(XL_OBJS) libxlutil.so libxenlight.so
-	$(CC) $(LDFLAGS) -o $@ $(XL_OBJS) libxlutil.so $(LDLIBS_libxenlight) $(LDLIBS_libxenctrl) $(APPEND_LDFLAGS)
+	$(CC) $(LDFLAGS) -o $@ $(XL_OBJS) libxlutil.so $(LDLIBS_libxenlight) $(LDLIBS_libxenctrl) $(XL_LIBS) $(APPEND_LDFLAGS)
 
 testidl: testidl.o libxlutil.so libxenlight.so
-	$(CC) $(LDFLAGS) -o $@ testidl.o libxlutil.so $(LDLIBS_libxenlight) $(LDLIBS_libxenctrl) $(APPEND_LDFLAGS)
+	$(CC) $(LDFLAGS) -o $@ testidl.o libxlutil.so $(LDLIBS_libxenlight) $(LDLIBS_libxenctrl) $(TESTIDL_LIBS) $(APPEND_LDFLAGS)
 
 .PHONY: install
 install: all

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Dec 18 12:50:16 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 18 Dec 2011 12:50:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RcGBO-0007cT-Em; Sun, 18 Dec 2011 12:49:38 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RcGBN-0007bl-En
	for xen-devel@lists.xensource.com; Sun, 18 Dec 2011 12:49:37 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1324212565!7905446!2
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11536 invoked from network); 18 Dec 2011 12:49:31 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Dec 2011 12:49:31 -0000
Received: by mail-ww0-f43.google.com with SMTP id ds11so7713360wgb.24
	for <xen-devel@lists.xensource.com>;
	Sun, 18 Dec 2011 04:49:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=krGjsylC6lkPJiXS8cMBkxFIRbhlzDkbHZVzm5plwmk=;
	b=EI56N4Zcj4G1Sl3FkEcYdS7Hx0LNGnxawSGjuiiBBhkG4rjwnCDDpkSn1SBB/gxa0m
	/5Gw6tGSLi9DTWQga432itjDi+U8F5v1W8NX8/xTDtx06ZKBDsh0Ydf5hqYmLW8M8zss
	IF3mIx6d651msR/+GurEyAZNyjL5KwSlecizk=
Received: by 10.180.102.4 with SMTP id fk4mr21882639wib.15.1324212571389;
	Sun, 18 Dec 2011 04:49:31 -0800 (PST)
Received: from alpine.localdomain (234.Red-80-25-94.staticIP.rima-tde.net.
	[80.25.94.234]) by mx.google.com with ESMTPS id
	et20sm21847393wbb.15.2011.12.18.04.49.28
	(version=TLSv1/SSLv3 cipher=OTHER);
	Sun, 18 Dec 2011 04:49:29 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: c0d5aa328f1ab24aad5880e720852b6dc8ffd4fb
Message-Id: <c0d5aa328f1ab24aad58.1324212503@alpine.localdomain>
In-Reply-To: <patchbomb.1324212500@alpine.localdomain>
References: <patchbomb.1324212500@alpine.localdomain>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Sun, 18 Dec 2011 13:48:23 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 3 of 5] blktap2: fix vhd compilation under uclibc
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1324171782 -3600
# Node ID c0d5aa328f1ab24aad5880e720852b6dc8ffd4fb
# Parent  c54c326d6fdf26d311c872479b769b3a8cd560cf
blktap2: fix vhd compilation under uclibc

blktap2 was not compiled succesfully under uclibc, with the following
error:

gcc     -o vhd-util vhd-util.o -Llib -lvhd
lib/libvhd.so: undefined reference to `libiconv_open'
lib/libvhd.so: undefined reference to `libiconv_close'
lib/libvhd.so: undefined reference to `libiconv'

This patchs add the flag -liconv when blktap2/vhd is compiled on
uclibc.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r c54c326d6fdf -r c0d5aa328f1a tools/blktap2/drivers/Makefile
--- a/tools/blktap2/drivers/Makefile	Sun Dec 18 02:29:42 2011 +0100
+++ b/tools/blktap2/drivers/Makefile	Sun Dec 18 02:29:42 2011 +0100
@@ -24,6 +24,10 @@ endif
 
 VHDLIBS    := -L$(LIBVHDDIR) -lvhd
 
+ifeq ($(CONFIG_UCLIBC),y)
+VHDLIBS    += -liconv
+endif
+
 REMUS-OBJS  := block-remus.o
 REMUS-OBJS  += hashtable.o
 REMUS-OBJS  += hashtable_itr.o
diff -r c54c326d6fdf -r c0d5aa328f1a tools/blktap2/vhd/Makefile
--- a/tools/blktap2/vhd/Makefile	Sun Dec 18 02:29:42 2011 +0100
+++ b/tools/blktap2/vhd/Makefile	Sun Dec 18 02:29:42 2011 +0100
@@ -23,6 +23,10 @@ endif
 
 LIBS              := -Llib -lvhd
 
+ifeq ($(CONFIG_UCLIBC),y)
+LIBS              += -liconv
+endif
+
 all: subdirs-all build
 
 build: $(IBIN)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Dec 18 12:50:16 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 18 Dec 2011 12:50:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RcGBJ-0007bx-LO; Sun, 18 Dec 2011 12:49:33 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RcGBI-0007bf-2L
	for xen-devel@lists.xensource.com; Sun, 18 Dec 2011 12:49:32 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1324212565!7905446!1
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11432 invoked from network); 18 Dec 2011 12:49:26 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Dec 2011 12:49:26 -0000
Received: by wgbds11 with SMTP id ds11so7713360wgb.24
	for <xen-devel@lists.xensource.com>;
	Sun, 18 Dec 2011 04:49:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=ebwZwPtLBos8+l+OdAup0PJOY4p29tsKMcu28xEGkCA=;
	b=qnzKzyGF6NmcQ6WjrfxSKef2OvJBUPuu5T/UNgCe1CCzUm6gHK8F9b3AjKAwOKaRO/
	VvM2MPDmzbM2nxzgZXKnkmNjS5UM1wjdQMN+bHewW90Yva3CvWJ2RGjeeqOwnjZd/Bgm
	TQkkqDlGHXwORplif2PPVXrP4JiKfHPE3ex5A=
Received: by 10.227.197.78 with SMTP id ej14mr9761466wbb.2.1324212565746;
	Sun, 18 Dec 2011 04:49:25 -0800 (PST)
Received: from alpine.localdomain (234.Red-80-25-94.staticIP.rima-tde.net.
	[80.25.94.234]) by mx.google.com with ESMTPS id
	et20sm21847393wbb.15.2011.12.18.04.49.21
	(version=TLSv1/SSLv3 cipher=OTHER);
	Sun, 18 Dec 2011 04:49:24 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: eed78eb655c40b0ac9af1b14c1cc03204f696b0b
Message-Id: <eed78eb655c40b0ac9af.1324212501@alpine.localdomain>
In-Reply-To: <patchbomb.1324212500@alpine.localdomain>
References: <patchbomb.1324212500@alpine.localdomain>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Sun, 18 Dec 2011 13:48:21 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 1 of 5] blktap: remove HAVE_BYTESWAP_H checking,
 since it's defined by qemu
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1324171782 -3600
# Node ID eed78eb655c40b0ac9af1b14c1cc03204f696b0b
# Parent  b783e76e63a99c9d87fca4974492f60af99a2e7a
blktap: remove HAVE_BYTESWAP_H checking, since it's defined by qemu

blktap was using defines set by qemu, even when the qemu config file
is not included. Remove this checkings, and instead check if the file
has been included before defining the necessary macros.

The output error is:

In file included from block-qcow.c:37:0:
bswap.h:23:0: error: "bswap_16" redefined [-Werror]
/usr/include/byteswap.h:30:0: note: this is the location of the
previous definition
bswap.h:31:0: error: "bswap_32" redefined [-Werror]
/usr/include/byteswap.h:33:0: note: this is the location of the
previous definition
bswap.h:41:0: error: "bswap_64" redefined [-Werror]
/usr/include/byteswap.h:37:0: note: this is the location of the
previous definition
cc1: all warnings being treated as errors

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r b783e76e63a9 -r eed78eb655c4 tools/blktap/drivers/bswap.h
--- a/tools/blktap/drivers/bswap.h	Sun Dec 18 02:29:42 2011 +0100
+++ b/tools/blktap/drivers/bswap.h	Sun Dec 18 02:29:42 2011 +0100
@@ -15,9 +15,7 @@
 #define bswap_64(x) swap64(x)
 #else
 
-#ifdef HAVE_BYTESWAP_H
-#include <byteswap.h>
-#else
+#ifndef _BYTESWAP_H
 
 #define bswap_16(x) \
 ({ \
@@ -51,7 +49,7 @@
 		(uint64_t)(((uint64_t)(__x) & (uint64_t)0xff00000000000000ULL) >> 56) )); \
 })
 
-#endif /* !HAVE_BYTESWAP_H */
+#endif /* !_BYTESWAP_H */
 
 static inline uint16_t bswap16(uint16_t x)
 {

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Dec 18 13:26:37 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 18 Dec 2011 13:26:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RcGkp-0000Dj-9F; Sun, 18 Dec 2011 13:26:15 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RcGko-0000De-BA
	for xen-devel@lists.xensource.com; Sun, 18 Dec 2011 13:26:14 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1324214766!7735316!1
X-Originating-IP: [209.85.210.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29738 invoked from network); 18 Dec 2011 13:26:08 -0000
Received: from mail-pz0-f43.google.com (HELO mail-pz0-f43.google.com)
	(209.85.210.43)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Dec 2011 13:26:08 -0000
Received: by daec6 with SMTP id c6so22249529dae.30
	for <xen-devel@lists.xensource.com>;
	Sun, 18 Dec 2011 05:26:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=uyPrW3TlzAL9DDOI4XbNLFfKY+Yzm56AIHW/nDxUL6Q=;
	b=hAPMztE9TdMcsENH9lYeCN2O/hxIT9RVr5a/ye5eEpyfblERmLPHSgFlEZfYHF4f/Z
	IzZh3kQaVGV28eKphhKrOstYFvvpeGcIM7LrP2APbS08w75pzSKq9Bpgriyepg56tEQl
	HGVV22sRm+QdFQPEInDvvdescSWCd+vwQBLfE=
MIME-Version: 1.0
Received: by 10.68.75.135 with SMTP id c7mr31318128pbw.112.1324214765891; Sun,
	18 Dec 2011 05:26:05 -0800 (PST)
Received: by 10.142.47.17 with HTTP; Sun, 18 Dec 2011 05:26:05 -0800 (PST)
In-Reply-To: <CB10F665.361A4%keir@xen.org>
References: <CAPLaKK7J312vgixP-SpH6VkrUF_WvdFpB7X72viNpiJXyU5UJg@mail.gmail.com>
	<CB10F665.361A4%keir@xen.org>
Date: Sun, 18 Dec 2011 14:26:05 +0100
X-Google-Sender-Auth: qhvXwVwC7AosgmqdNFeR2claaQw
Message-ID: <CAPLaKK6Bv4f605TruaU8JCnBSWeBVg4o7q+o4Pwp1XVmk-GQdg@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Keir Fraser <keir@xen.org>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] ipxe: fix compilation issues with some gcc
	versions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

2011/12/16 Keir Fraser <keir@xen.org>:
> Perhaps we should pick a recent commit hash to clone, then? There's plenty
> going on in there development-wise, which would surely have warranted a
> release or two; it just looks like they couldn't be arsed to tag releases.
> Hanging on to a two-year-old version and building up a backport queue
> doesn't make sense. At the very least we should do this in xen-unstable, and
> get some testing done of recent ipxe upstream.

That's fine, I agree that we should pick a most recent ipxe version
for unstable, if not things like this are going to happen every now
and then and we will end up with a massive queue of patches. But in
the meantime, is it possible to apply this patch to xen-4.1 and
possibly xen-4.0?

Thanks, Roger.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Dec 18 13:26:37 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 18 Dec 2011 13:26:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RcGkp-0000Dj-9F; Sun, 18 Dec 2011 13:26:15 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RcGko-0000De-BA
	for xen-devel@lists.xensource.com; Sun, 18 Dec 2011 13:26:14 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1324214766!7735316!1
X-Originating-IP: [209.85.210.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29738 invoked from network); 18 Dec 2011 13:26:08 -0000
Received: from mail-pz0-f43.google.com (HELO mail-pz0-f43.google.com)
	(209.85.210.43)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Dec 2011 13:26:08 -0000
Received: by daec6 with SMTP id c6so22249529dae.30
	for <xen-devel@lists.xensource.com>;
	Sun, 18 Dec 2011 05:26:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=uyPrW3TlzAL9DDOI4XbNLFfKY+Yzm56AIHW/nDxUL6Q=;
	b=hAPMztE9TdMcsENH9lYeCN2O/hxIT9RVr5a/ye5eEpyfblERmLPHSgFlEZfYHF4f/Z
	IzZh3kQaVGV28eKphhKrOstYFvvpeGcIM7LrP2APbS08w75pzSKq9Bpgriyepg56tEQl
	HGVV22sRm+QdFQPEInDvvdescSWCd+vwQBLfE=
MIME-Version: 1.0
Received: by 10.68.75.135 with SMTP id c7mr31318128pbw.112.1324214765891; Sun,
	18 Dec 2011 05:26:05 -0800 (PST)
Received: by 10.142.47.17 with HTTP; Sun, 18 Dec 2011 05:26:05 -0800 (PST)
In-Reply-To: <CB10F665.361A4%keir@xen.org>
References: <CAPLaKK7J312vgixP-SpH6VkrUF_WvdFpB7X72viNpiJXyU5UJg@mail.gmail.com>
	<CB10F665.361A4%keir@xen.org>
Date: Sun, 18 Dec 2011 14:26:05 +0100
X-Google-Sender-Auth: qhvXwVwC7AosgmqdNFeR2claaQw
Message-ID: <CAPLaKK6Bv4f605TruaU8JCnBSWeBVg4o7q+o4Pwp1XVmk-GQdg@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Keir Fraser <keir@xen.org>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] ipxe: fix compilation issues with some gcc
	versions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

2011/12/16 Keir Fraser <keir@xen.org>:
> Perhaps we should pick a recent commit hash to clone, then? There's plenty
> going on in there development-wise, which would surely have warranted a
> release or two; it just looks like they couldn't be arsed to tag releases.
> Hanging on to a two-year-old version and building up a backport queue
> doesn't make sense. At the very least we should do this in xen-unstable, and
> get some testing done of recent ipxe upstream.

That's fine, I agree that we should pick a most recent ipxe version
for unstable, if not things like this are going to happen every now
and then and we will end up with a massive queue of patches. But in
the meantime, is it possible to apply this patch to xen-4.1 and
possibly xen-4.0?

Thanks, Roger.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Dec 18 14:56:56 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 18 Dec 2011 14: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.xensource.com>)
	id 1RcI9w-0001GF-KH; Sun, 18 Dec 2011 14:56:16 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RcI9v-0001G7-HM
	for xen-devel@lists.xensource.com; Sun, 18 Dec 2011 14:56:15 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1324220168!5950752!1
X-Originating-IP: [74.125.82.41]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1754 invoked from network); 18 Dec 2011 14:56:09 -0000
Received: from mail-ww0-f41.google.com (HELO mail-ww0-f41.google.com)
	(74.125.82.41)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Dec 2011 14:56:09 -0000
Received: by wgbdt12 with SMTP id dt12so7143710wgb.0
	for <xen-devel@lists.xensource.com>;
	Sun, 18 Dec 2011 06:56:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=xDifaC3mQFPXKoSQhlisCenbVOMP5bdZ9w0NDKaAnXw=;
	b=lm3/Y1rZ8fcIHim68NBfH5ykt1bFeoFIPIvUA4MaXZ6+VOqfHSlQARSeQnmiKNRSnV
	HKpsDj/84ikQLCWCIjPhHIxChXhwd8NnzRuacVWRMCnqtstS84OV1XrnHmMA3Jm0SXmU
	6NV+0RZbD5fjXtLB4igeAoBwrUveYoKsikjms=
Received: by 10.180.91.137 with SMTP id ce9mr22812993wib.5.1324220168703;
	Sun, 18 Dec 2011 06:56:08 -0800 (PST)
Received: from [192.168.1.3] (host81-152-17-11.range81-152.btcentralplus.com.
	[81.152.17.11])
	by mx.google.com with ESMTPS id fo18sm874212wbb.12.2011.12.18.06.56.06
	(version=SSLv3 cipher=OTHER); Sun, 18 Dec 2011 06:56:07 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Sun, 18 Dec 2011 14:56:02 +0000
From: Keir Fraser <keir@xen.org>
To: Roger Pau =?ISO-8859-1?B?TW9ubuk=?= <roger.pau@entel.upc.edu>
Message-ID: <CB13AF82.3631C%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH] ipxe: fix compilation issues with some gcc
	versions
Thread-Index: Acy9lSjZuzAUhYIWeEisnV06HhQ6yA==
In-Reply-To: <CAPLaKK6Bv4f605TruaU8JCnBSWeBVg4o7q+o4Pwp1XVmk-GQdg@mail.gmail.com>
Mime-version: 1.0
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] ipxe: fix compilation issues with some gcc
 versions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 18/12/2011 13:26, "Roger Pau Monn=E9" <roger.pau@entel.upc.edu> wrote:

> 2011/12/16 Keir Fraser <keir@xen.org>:
>> Perhaps we should pick a recent commit hash to clone, then? There's plen=
ty
>> going on in there development-wise, which would surely have warranted a
>> release or two; it just looks like they couldn't be arsed to tag release=
s.
>> Hanging on to a two-year-old version and building up a backport queue
>> doesn't make sense. At the very least we should do this in xen-unstable,=
 and
>> get some testing done of recent ipxe upstream.
> =

> That's fine, I agree that we should pick a most recent ipxe version
> for unstable, if not things like this are going to happen every now
> and then and we will end up with a massive queue of patches. But in
> the meantime, is it possible to apply this patch to xen-4.1 and
> possibly xen-4.0?

Done for 4.1. In 4.0 it looks like we have the generated code checked in, so
this fix is not necessary there.

 -- Keir

> Thanks, Roger.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Dec 18 14:56:56 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 18 Dec 2011 14: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.xensource.com>)
	id 1RcI9w-0001GF-KH; Sun, 18 Dec 2011 14:56:16 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RcI9v-0001G7-HM
	for xen-devel@lists.xensource.com; Sun, 18 Dec 2011 14:56:15 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1324220168!5950752!1
X-Originating-IP: [74.125.82.41]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1754 invoked from network); 18 Dec 2011 14:56:09 -0000
Received: from mail-ww0-f41.google.com (HELO mail-ww0-f41.google.com)
	(74.125.82.41)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Dec 2011 14:56:09 -0000
Received: by wgbdt12 with SMTP id dt12so7143710wgb.0
	for <xen-devel@lists.xensource.com>;
	Sun, 18 Dec 2011 06:56:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=xDifaC3mQFPXKoSQhlisCenbVOMP5bdZ9w0NDKaAnXw=;
	b=lm3/Y1rZ8fcIHim68NBfH5ykt1bFeoFIPIvUA4MaXZ6+VOqfHSlQARSeQnmiKNRSnV
	HKpsDj/84ikQLCWCIjPhHIxChXhwd8NnzRuacVWRMCnqtstS84OV1XrnHmMA3Jm0SXmU
	6NV+0RZbD5fjXtLB4igeAoBwrUveYoKsikjms=
Received: by 10.180.91.137 with SMTP id ce9mr22812993wib.5.1324220168703;
	Sun, 18 Dec 2011 06:56:08 -0800 (PST)
Received: from [192.168.1.3] (host81-152-17-11.range81-152.btcentralplus.com.
	[81.152.17.11])
	by mx.google.com with ESMTPS id fo18sm874212wbb.12.2011.12.18.06.56.06
	(version=SSLv3 cipher=OTHER); Sun, 18 Dec 2011 06:56:07 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Sun, 18 Dec 2011 14:56:02 +0000
From: Keir Fraser <keir@xen.org>
To: Roger Pau =?ISO-8859-1?B?TW9ubuk=?= <roger.pau@entel.upc.edu>
Message-ID: <CB13AF82.3631C%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH] ipxe: fix compilation issues with some gcc
	versions
Thread-Index: Acy9lSjZuzAUhYIWeEisnV06HhQ6yA==
In-Reply-To: <CAPLaKK6Bv4f605TruaU8JCnBSWeBVg4o7q+o4Pwp1XVmk-GQdg@mail.gmail.com>
Mime-version: 1.0
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] ipxe: fix compilation issues with some gcc
 versions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 18/12/2011 13:26, "Roger Pau Monn=E9" <roger.pau@entel.upc.edu> wrote:

> 2011/12/16 Keir Fraser <keir@xen.org>:
>> Perhaps we should pick a recent commit hash to clone, then? There's plen=
ty
>> going on in there development-wise, which would surely have warranted a
>> release or two; it just looks like they couldn't be arsed to tag release=
s.
>> Hanging on to a two-year-old version and building up a backport queue
>> doesn't make sense. At the very least we should do this in xen-unstable,=
 and
>> get some testing done of recent ipxe upstream.
> =

> That's fine, I agree that we should pick a most recent ipxe version
> for unstable, if not things like this are going to happen every now
> and then and we will end up with a massive queue of patches. But in
> the meantime, is it possible to apply this patch to xen-4.1 and
> possibly xen-4.0?

Done for 4.1. In 4.0 it looks like we have the generated code checked in, so
this fix is not necessary there.

 -- Keir

> Thanks, Roger.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Dec 18 15:33:52 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 18 Dec 2011 15: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.xensource.com>)
	id 1RcIjr-0001gX-LP; Sun, 18 Dec 2011 15:33:23 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <avi@redhat.com>) id 1RcIjq-0001g5-5e
	for xen-devel@lists.xensource.com; Sun, 18 Dec 2011 15:33:22 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1324222395!7926812!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDYzNzE=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4378 invoked from network); 18 Dec 2011 15:33:15 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-8.tower-216.messagelabs.com with SMTP;
	18 Dec 2011 15:33:15 -0000
Received: from int-mx12.intmail.prod.int.phx2.redhat.com
	(int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id pBIFXCZU009717
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sun, 18 Dec 2011 10:33:12 -0500
Received: from cleopatra.tlv.redhat.com (cleopatra.tlv.redhat.com
	[10.35.255.11])
	by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id pBIFXB4G011048; Sun, 18 Dec 2011 10:33:12 -0500
Received: from s01.tlv.redhat.com (s01.tlv.redhat.com [10.35.255.8])
	by cleopatra.tlv.redhat.com (Postfix) with ESMTP id 901EA250BA0;
	Sun, 18 Dec 2011 17:33:04 +0200 (IST)
From: Avi Kivity <avi@redhat.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Sun, 18 Dec 2011 17:32:48 +0200
Message-Id: <1324222368-25156-3-git-send-email-avi@redhat.com>
In-Reply-To: <1324222368-25156-1-git-send-email-avi@redhat.com>
References: <1324222368-25156-1-git-send-email-avi@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.25
Cc: xen-devel@lists.xensource.com, qemu-devel@nongnu.org
Subject: [Xen-devel] [PATCH 2/2] xen: convert to memory API
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Undo the private implementation of qemu_ram_alloc(); use the global one
(which calls right back into xen_ram_alloc()).

Signed-off-by: Avi Kivity <avi@redhat.com>
---
 xen-all.c |   41 ++++++++++++++++++++++-------------------
 1 files changed, 22 insertions(+), 19 deletions(-)

diff --git a/xen-all.c b/xen-all.c
index b441fc1..bd89889 100644
--- a/xen-all.c
+++ b/xen-all.c
@@ -16,6 +16,7 @@
 #include "range.h"
 #include "xen-mapcache.h"
 #include "trace.h"
+#include "exec-memory.h"
 
 #include <xen/hvm/ioreq.h>
 #include <xen/hvm/params.h>
@@ -31,6 +32,8 @@
     do { } while (0)
 #endif
 
+static MemoryRegion ram_memory, ram_640k, ram_lo, ram_hi;
+
 /* Compatibility with older version */
 #if __XEN_LATEST_INTERFACE_VERSION__ < 0x0003020a
 static inline uint32_t xen_vcpu_eport(shared_iopage_t *shared_page, int i)
@@ -137,27 +140,18 @@ static void xen_set_irq(void *opaque, int irq, int level)
 
 static void xen_ram_init(ram_addr_t ram_size)
 {
-    RAMBlock *new_block;
+    MemoryRegion *sysmem = get_system_memory();
     ram_addr_t below_4g_mem_size, above_4g_mem_size = 0;
+    ram_addr_t block_len;
 
-    new_block = g_malloc0(sizeof (*new_block));
-    pstrcpy(new_block->idstr, sizeof (new_block->idstr), "xen.ram");
-    new_block->host = NULL;
-    new_block->offset = 0;
-    new_block->length = ram_size;
+    block_len = ram_size;
     if (ram_size >= HVM_BELOW_4G_RAM_END) {
         /* Xen does not allocate the memory continuously, and keep a hole at
          * HVM_BELOW_4G_MMIO_START of HVM_BELOW_4G_MMIO_LENGTH
          */
-        new_block->length += HVM_BELOW_4G_MMIO_LENGTH;
+        block_len += HVM_BELOW_4G_MMIO_LENGTH;
     }
-
-    QLIST_INSERT_HEAD(&ram_list.blocks, new_block, next);
-
-    ram_list.phys_dirty = g_realloc(ram_list.phys_dirty,
-                                       new_block->length >> TARGET_PAGE_BITS);
-    memset(ram_list.phys_dirty + (new_block->offset >> TARGET_PAGE_BITS),
-           0xff, new_block->length >> TARGET_PAGE_BITS);
+    memory_region_init_ram(&ram_memory, NULL, "xen.ram", block_len);
 
     if (ram_size >= HVM_BELOW_4G_RAM_END) {
         above_4g_mem_size = ram_size - HVM_BELOW_4G_RAM_END;
@@ -166,18 +160,23 @@ static void xen_ram_init(ram_addr_t ram_size)
         below_4g_mem_size = ram_size;
     }
 
-    cpu_register_physical_memory(0, 0xa0000, 0);
+    memory_region_init_alias(&ram_640k, "xen.ram.640k",
+                             &ram_memory, 0, 0xa0000);
+    memory_region_add_subregion(sysmem, 0, &ram_640k);
     /* Skip of the VGA IO memory space, it will be registered later by the VGA
      * emulated device.
      *
      * The area between 0xc0000 and 0x100000 will be used by SeaBIOS to load
      * the Options ROM, so it is registered here as RAM.
      */
-    cpu_register_physical_memory(0xc0000, below_4g_mem_size - 0xc0000,
-                                 0xc0000);
+    memory_region_init_alias(&ram_lo, "xen.ram.lo",
+                             &ram_memory, 0xc0000, below_4g_mem_size - 0xc0000);
+    memory_region_add_subregion(sysmem, 0xc0000, &ram_lo);
     if (above_4g_mem_size > 0) {
-        cpu_register_physical_memory(0x100000000ULL, above_4g_mem_size,
-                                     0x100000000ULL);
+        memory_region_init_alias(&ram_hi, "xen.ram.hi",
+                                 &ram_memory, 0x100000000ULL,
+                                 above_4g_mem_size);
+        memory_region_add_subregion(sysmem, 0x100000000ULL, &ram_hi);
     }
 }
 
@@ -187,6 +186,10 @@ void xen_ram_alloc(ram_addr_t ram_addr, ram_addr_t size, MemoryRegion *mr)
     xen_pfn_t *pfn_list;
     int i;
 
+    if (mr == &ram_memory) {
+        return;
+    }
+
     trace_xen_ram_alloc(ram_addr, size);
 
     nr_pfn = size >> TARGET_PAGE_BITS;
-- 
1.7.7.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Dec 18 15:33:52 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 18 Dec 2011 15: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.xensource.com>)
	id 1RcIjr-0001gX-LP; Sun, 18 Dec 2011 15:33:23 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <avi@redhat.com>) id 1RcIjq-0001g5-5e
	for xen-devel@lists.xensource.com; Sun, 18 Dec 2011 15:33:22 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1324222395!7926812!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDYzNzE=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4378 invoked from network); 18 Dec 2011 15:33:15 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-8.tower-216.messagelabs.com with SMTP;
	18 Dec 2011 15:33:15 -0000
Received: from int-mx12.intmail.prod.int.phx2.redhat.com
	(int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id pBIFXCZU009717
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sun, 18 Dec 2011 10:33:12 -0500
Received: from cleopatra.tlv.redhat.com (cleopatra.tlv.redhat.com
	[10.35.255.11])
	by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id pBIFXB4G011048; Sun, 18 Dec 2011 10:33:12 -0500
Received: from s01.tlv.redhat.com (s01.tlv.redhat.com [10.35.255.8])
	by cleopatra.tlv.redhat.com (Postfix) with ESMTP id 901EA250BA0;
	Sun, 18 Dec 2011 17:33:04 +0200 (IST)
From: Avi Kivity <avi@redhat.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Sun, 18 Dec 2011 17:32:48 +0200
Message-Id: <1324222368-25156-3-git-send-email-avi@redhat.com>
In-Reply-To: <1324222368-25156-1-git-send-email-avi@redhat.com>
References: <1324222368-25156-1-git-send-email-avi@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.25
Cc: xen-devel@lists.xensource.com, qemu-devel@nongnu.org
Subject: [Xen-devel] [PATCH 2/2] xen: convert to memory API
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Undo the private implementation of qemu_ram_alloc(); use the global one
(which calls right back into xen_ram_alloc()).

Signed-off-by: Avi Kivity <avi@redhat.com>
---
 xen-all.c |   41 ++++++++++++++++++++++-------------------
 1 files changed, 22 insertions(+), 19 deletions(-)

diff --git a/xen-all.c b/xen-all.c
index b441fc1..bd89889 100644
--- a/xen-all.c
+++ b/xen-all.c
@@ -16,6 +16,7 @@
 #include "range.h"
 #include "xen-mapcache.h"
 #include "trace.h"
+#include "exec-memory.h"
 
 #include <xen/hvm/ioreq.h>
 #include <xen/hvm/params.h>
@@ -31,6 +32,8 @@
     do { } while (0)
 #endif
 
+static MemoryRegion ram_memory, ram_640k, ram_lo, ram_hi;
+
 /* Compatibility with older version */
 #if __XEN_LATEST_INTERFACE_VERSION__ < 0x0003020a
 static inline uint32_t xen_vcpu_eport(shared_iopage_t *shared_page, int i)
@@ -137,27 +140,18 @@ static void xen_set_irq(void *opaque, int irq, int level)
 
 static void xen_ram_init(ram_addr_t ram_size)
 {
-    RAMBlock *new_block;
+    MemoryRegion *sysmem = get_system_memory();
     ram_addr_t below_4g_mem_size, above_4g_mem_size = 0;
+    ram_addr_t block_len;
 
-    new_block = g_malloc0(sizeof (*new_block));
-    pstrcpy(new_block->idstr, sizeof (new_block->idstr), "xen.ram");
-    new_block->host = NULL;
-    new_block->offset = 0;
-    new_block->length = ram_size;
+    block_len = ram_size;
     if (ram_size >= HVM_BELOW_4G_RAM_END) {
         /* Xen does not allocate the memory continuously, and keep a hole at
          * HVM_BELOW_4G_MMIO_START of HVM_BELOW_4G_MMIO_LENGTH
          */
-        new_block->length += HVM_BELOW_4G_MMIO_LENGTH;
+        block_len += HVM_BELOW_4G_MMIO_LENGTH;
     }
-
-    QLIST_INSERT_HEAD(&ram_list.blocks, new_block, next);
-
-    ram_list.phys_dirty = g_realloc(ram_list.phys_dirty,
-                                       new_block->length >> TARGET_PAGE_BITS);
-    memset(ram_list.phys_dirty + (new_block->offset >> TARGET_PAGE_BITS),
-           0xff, new_block->length >> TARGET_PAGE_BITS);
+    memory_region_init_ram(&ram_memory, NULL, "xen.ram", block_len);
 
     if (ram_size >= HVM_BELOW_4G_RAM_END) {
         above_4g_mem_size = ram_size - HVM_BELOW_4G_RAM_END;
@@ -166,18 +160,23 @@ static void xen_ram_init(ram_addr_t ram_size)
         below_4g_mem_size = ram_size;
     }
 
-    cpu_register_physical_memory(0, 0xa0000, 0);
+    memory_region_init_alias(&ram_640k, "xen.ram.640k",
+                             &ram_memory, 0, 0xa0000);
+    memory_region_add_subregion(sysmem, 0, &ram_640k);
     /* Skip of the VGA IO memory space, it will be registered later by the VGA
      * emulated device.
      *
      * The area between 0xc0000 and 0x100000 will be used by SeaBIOS to load
      * the Options ROM, so it is registered here as RAM.
      */
-    cpu_register_physical_memory(0xc0000, below_4g_mem_size - 0xc0000,
-                                 0xc0000);
+    memory_region_init_alias(&ram_lo, "xen.ram.lo",
+                             &ram_memory, 0xc0000, below_4g_mem_size - 0xc0000);
+    memory_region_add_subregion(sysmem, 0xc0000, &ram_lo);
     if (above_4g_mem_size > 0) {
-        cpu_register_physical_memory(0x100000000ULL, above_4g_mem_size,
-                                     0x100000000ULL);
+        memory_region_init_alias(&ram_hi, "xen.ram.hi",
+                                 &ram_memory, 0x100000000ULL,
+                                 above_4g_mem_size);
+        memory_region_add_subregion(sysmem, 0x100000000ULL, &ram_hi);
     }
 }
 
@@ -187,6 +186,10 @@ void xen_ram_alloc(ram_addr_t ram_addr, ram_addr_t size, MemoryRegion *mr)
     xen_pfn_t *pfn_list;
     int i;
 
+    if (mr == &ram_memory) {
+        return;
+    }
+
     trace_xen_ram_alloc(ram_addr, size);
 
     nr_pfn = size >> TARGET_PAGE_BITS;
-- 
1.7.7.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Dec 18 15:33:52 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 18 Dec 2011 15: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.xensource.com>)
	id 1RcIjo-0001gH-8D; Sun, 18 Dec 2011 15:33:20 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <avi@redhat.com>) id 1RcIjm-0001fx-SQ
	for xen-devel@lists.xensource.com; Sun, 18 Dec 2011 15:33:19 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1324222363!45351098!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDYzNzE=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30023 invoked from network); 18 Dec 2011 15:32:43 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-12.tower-27.messagelabs.com with SMTP;
	18 Dec 2011 15:32:43 -0000
Received: from int-mx09.intmail.prod.int.phx2.redhat.com
	(int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id pBIFXBxh026579
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sun, 18 Dec 2011 10:33:11 -0500
Received: from cleopatra.tlv.redhat.com (cleopatra.tlv.redhat.com
	[10.35.255.11])
	by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id pBIFXAtd013156; Sun, 18 Dec 2011 10:33:10 -0500
Received: from s01.tlv.redhat.com (s01.tlv.redhat.com [10.35.255.8])
	by cleopatra.tlv.redhat.com (Postfix) with ESMTP id 89988250B9F;
	Sun, 18 Dec 2011 17:33:04 +0200 (IST)
From: Avi Kivity <avi@redhat.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Sun, 18 Dec 2011 17:32:47 +0200
Message-Id: <1324222368-25156-2-git-send-email-avi@redhat.com>
In-Reply-To: <1324222368-25156-1-git-send-email-avi@redhat.com>
References: <1324222368-25156-1-git-send-email-avi@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
Cc: xen-devel@lists.xensource.com, qemu-devel@nongnu.org
Subject: [Xen-devel] [PATCH 1/2] memory,
	xen: pass MemoryRegion to xen_ram_alloc()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Currently xen_ram_alloc() relies on ram_addr, which is going away.
Give it something else to use as a cookie.

Signed-off-by: Avi Kivity <avi@redhat.com>
---
 exec-obsolete.h |    7 +++++--
 exec.c          |   10 ++++++----
 hw/xen.h        |    4 +++-
 memory.c        |    6 +++---
 xen-all.c       |    2 +-
 xen-stub.c      |    3 ++-
 6 files changed, 20 insertions(+), 12 deletions(-)

diff --git a/exec-obsolete.h b/exec-obsolete.h
index bf0dea5..1d0b610 100644
--- a/exec-obsolete.h
+++ b/exec-obsolete.h
@@ -25,9 +25,12 @@
 
 #ifndef CONFIG_USER_ONLY
 
+#include "memory.h"
+
 ram_addr_t qemu_ram_alloc_from_ptr(DeviceState *dev, const char *name,
-                        ram_addr_t size, void *host);
-ram_addr_t qemu_ram_alloc(DeviceState *dev, const char *name, ram_addr_t size);
+                        ram_addr_t size, void *host, MemoryRegion *mr);
+ram_addr_t qemu_ram_alloc(DeviceState *dev, const char *name, ram_addr_t size,
+                          MemoryRegion *mr);
 void qemu_ram_free(ram_addr_t addr);
 void qemu_ram_free_from_ptr(ram_addr_t addr);
 
diff --git a/exec.c b/exec.c
index 8fbf7e4..05336a5 100644
--- a/exec.c
+++ b/exec.c
@@ -2918,7 +2918,8 @@ static ram_addr_t last_ram_offset(void)
 }
 
 ram_addr_t qemu_ram_alloc_from_ptr(DeviceState *dev, const char *name,
-                                   ram_addr_t size, void *host)
+                                   ram_addr_t size, void *host,
+                                   MemoryRegion *mr)
 {
     RAMBlock *new_block, *block;
 
@@ -2974,7 +2975,7 @@ ram_addr_t qemu_ram_alloc_from_ptr(DeviceState *dev, const char *name,
             }
 #else
             if (xen_enabled()) {
-                xen_ram_alloc(new_block->offset, size);
+                xen_ram_alloc(new_block->offset, size, mr);
             } else {
                 new_block->host = qemu_vmalloc(size);
             }
@@ -2997,9 +2998,10 @@ ram_addr_t qemu_ram_alloc_from_ptr(DeviceState *dev, const char *name,
     return new_block->offset;
 }
 
-ram_addr_t qemu_ram_alloc(DeviceState *dev, const char *name, ram_addr_t size)
+ram_addr_t qemu_ram_alloc(DeviceState *dev, const char *name, ram_addr_t size,
+                          MemoryRegion *mr)
 {
-    return qemu_ram_alloc_from_ptr(dev, name, size, NULL);
+    return qemu_ram_alloc_from_ptr(dev, name, size, NULL, mr);
 }
 
 void qemu_ram_free_from_ptr(ram_addr_t addr)
diff --git a/hw/xen.h b/hw/xen.h
index 2162111..f9f66e8 100644
--- a/hw/xen.h
+++ b/hw/xen.h
@@ -44,7 +44,9 @@ void xen_vcpu_init(void);
 void xenstore_store_pv_console_info(int i, struct CharDriverState *chr);
 
 #if defined(NEED_CPU_H) && !defined(CONFIG_USER_ONLY)
-void xen_ram_alloc(ram_addr_t ram_addr, ram_addr_t size);
+struct MemoryRegion;
+void xen_ram_alloc(ram_addr_t ram_addr, ram_addr_t size,
+                   struct MemoryRegion *mr);
 #endif
 
 #if defined(CONFIG_XEN) && CONFIG_XEN_CTRL_INTERFACE_VERSION < 400
diff --git a/memory.c b/memory.c
index d2ba9c4..cbd6988 100644
--- a/memory.c
+++ b/memory.c
@@ -985,7 +985,7 @@ void memory_region_init_ram(MemoryRegion *mr,
     memory_region_init(mr, name, size);
     mr->terminates = true;
     mr->destructor = memory_region_destructor_ram;
-    mr->ram_addr = qemu_ram_alloc(dev, name, size);
+    mr->ram_addr = qemu_ram_alloc(dev, name, size, mr);
     mr->backend_registered = true;
 }
 
@@ -998,7 +998,7 @@ void memory_region_init_ram_ptr(MemoryRegion *mr,
     memory_region_init(mr, name, size);
     mr->terminates = true;
     mr->destructor = memory_region_destructor_ram_from_ptr;
-    mr->ram_addr = qemu_ram_alloc_from_ptr(dev, name, size, ptr);
+    mr->ram_addr = qemu_ram_alloc_from_ptr(dev, name, size, ptr, mr);
     mr->backend_registered = true;
 }
 
@@ -1025,7 +1025,7 @@ void memory_region_init_rom_device(MemoryRegion *mr,
     mr->opaque = opaque;
     mr->terminates = true;
     mr->destructor = memory_region_destructor_rom_device;
-    mr->ram_addr = qemu_ram_alloc(dev, name, size);
+    mr->ram_addr = qemu_ram_alloc(dev, name, size, mr);
     mr->ram_addr |= cpu_register_io_memory(memory_region_read_thunk,
                                            memory_region_write_thunk,
                                            mr,
diff --git a/xen-all.c b/xen-all.c
index b5e28ab..b441fc1 100644
--- a/xen-all.c
+++ b/xen-all.c
@@ -181,7 +181,7 @@ static void xen_ram_init(ram_addr_t ram_size)
     }
 }
 
-void xen_ram_alloc(ram_addr_t ram_addr, ram_addr_t size)
+void xen_ram_alloc(ram_addr_t ram_addr, ram_addr_t size, MemoryRegion *mr)
 {
     unsigned long nr_pfn;
     xen_pfn_t *pfn_list;
diff --git a/xen-stub.c b/xen-stub.c
index efe2ab5..5fa400f 100644
--- a/xen-stub.c
+++ b/xen-stub.c
@@ -8,6 +8,7 @@
 
 #include "qemu-common.h"
 #include "hw/xen.h"
+#include "memory.h"
 
 void xenstore_store_pv_console_info(int i, CharDriverState *chr)
 {
@@ -30,7 +31,7 @@ void xen_cmos_set_s3_resume(void *opaque, int irq, int level)
 {
 }
 
-void xen_ram_alloc(ram_addr_t ram_addr, ram_addr_t size)
+void xen_ram_alloc(ram_addr_t ram_addr, ram_addr_t size, MemoryRegion *mr)
 {
 }
 
-- 
1.7.7.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Dec 18 15:33:52 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 18 Dec 2011 15: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.xensource.com>)
	id 1RcIjo-0001gH-8D; Sun, 18 Dec 2011 15:33:20 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <avi@redhat.com>) id 1RcIjm-0001fx-SQ
	for xen-devel@lists.xensource.com; Sun, 18 Dec 2011 15:33:19 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1324222363!45351098!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDYzNzE=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30023 invoked from network); 18 Dec 2011 15:32:43 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-12.tower-27.messagelabs.com with SMTP;
	18 Dec 2011 15:32:43 -0000
Received: from int-mx09.intmail.prod.int.phx2.redhat.com
	(int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id pBIFXBxh026579
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sun, 18 Dec 2011 10:33:11 -0500
Received: from cleopatra.tlv.redhat.com (cleopatra.tlv.redhat.com
	[10.35.255.11])
	by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id pBIFXAtd013156; Sun, 18 Dec 2011 10:33:10 -0500
Received: from s01.tlv.redhat.com (s01.tlv.redhat.com [10.35.255.8])
	by cleopatra.tlv.redhat.com (Postfix) with ESMTP id 89988250B9F;
	Sun, 18 Dec 2011 17:33:04 +0200 (IST)
From: Avi Kivity <avi@redhat.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Sun, 18 Dec 2011 17:32:47 +0200
Message-Id: <1324222368-25156-2-git-send-email-avi@redhat.com>
In-Reply-To: <1324222368-25156-1-git-send-email-avi@redhat.com>
References: <1324222368-25156-1-git-send-email-avi@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
Cc: xen-devel@lists.xensource.com, qemu-devel@nongnu.org
Subject: [Xen-devel] [PATCH 1/2] memory,
	xen: pass MemoryRegion to xen_ram_alloc()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Currently xen_ram_alloc() relies on ram_addr, which is going away.
Give it something else to use as a cookie.

Signed-off-by: Avi Kivity <avi@redhat.com>
---
 exec-obsolete.h |    7 +++++--
 exec.c          |   10 ++++++----
 hw/xen.h        |    4 +++-
 memory.c        |    6 +++---
 xen-all.c       |    2 +-
 xen-stub.c      |    3 ++-
 6 files changed, 20 insertions(+), 12 deletions(-)

diff --git a/exec-obsolete.h b/exec-obsolete.h
index bf0dea5..1d0b610 100644
--- a/exec-obsolete.h
+++ b/exec-obsolete.h
@@ -25,9 +25,12 @@
 
 #ifndef CONFIG_USER_ONLY
 
+#include "memory.h"
+
 ram_addr_t qemu_ram_alloc_from_ptr(DeviceState *dev, const char *name,
-                        ram_addr_t size, void *host);
-ram_addr_t qemu_ram_alloc(DeviceState *dev, const char *name, ram_addr_t size);
+                        ram_addr_t size, void *host, MemoryRegion *mr);
+ram_addr_t qemu_ram_alloc(DeviceState *dev, const char *name, ram_addr_t size,
+                          MemoryRegion *mr);
 void qemu_ram_free(ram_addr_t addr);
 void qemu_ram_free_from_ptr(ram_addr_t addr);
 
diff --git a/exec.c b/exec.c
index 8fbf7e4..05336a5 100644
--- a/exec.c
+++ b/exec.c
@@ -2918,7 +2918,8 @@ static ram_addr_t last_ram_offset(void)
 }
 
 ram_addr_t qemu_ram_alloc_from_ptr(DeviceState *dev, const char *name,
-                                   ram_addr_t size, void *host)
+                                   ram_addr_t size, void *host,
+                                   MemoryRegion *mr)
 {
     RAMBlock *new_block, *block;
 
@@ -2974,7 +2975,7 @@ ram_addr_t qemu_ram_alloc_from_ptr(DeviceState *dev, const char *name,
             }
 #else
             if (xen_enabled()) {
-                xen_ram_alloc(new_block->offset, size);
+                xen_ram_alloc(new_block->offset, size, mr);
             } else {
                 new_block->host = qemu_vmalloc(size);
             }
@@ -2997,9 +2998,10 @@ ram_addr_t qemu_ram_alloc_from_ptr(DeviceState *dev, const char *name,
     return new_block->offset;
 }
 
-ram_addr_t qemu_ram_alloc(DeviceState *dev, const char *name, ram_addr_t size)
+ram_addr_t qemu_ram_alloc(DeviceState *dev, const char *name, ram_addr_t size,
+                          MemoryRegion *mr)
 {
-    return qemu_ram_alloc_from_ptr(dev, name, size, NULL);
+    return qemu_ram_alloc_from_ptr(dev, name, size, NULL, mr);
 }
 
 void qemu_ram_free_from_ptr(ram_addr_t addr)
diff --git a/hw/xen.h b/hw/xen.h
index 2162111..f9f66e8 100644
--- a/hw/xen.h
+++ b/hw/xen.h
@@ -44,7 +44,9 @@ void xen_vcpu_init(void);
 void xenstore_store_pv_console_info(int i, struct CharDriverState *chr);
 
 #if defined(NEED_CPU_H) && !defined(CONFIG_USER_ONLY)
-void xen_ram_alloc(ram_addr_t ram_addr, ram_addr_t size);
+struct MemoryRegion;
+void xen_ram_alloc(ram_addr_t ram_addr, ram_addr_t size,
+                   struct MemoryRegion *mr);
 #endif
 
 #if defined(CONFIG_XEN) && CONFIG_XEN_CTRL_INTERFACE_VERSION < 400
diff --git a/memory.c b/memory.c
index d2ba9c4..cbd6988 100644
--- a/memory.c
+++ b/memory.c
@@ -985,7 +985,7 @@ void memory_region_init_ram(MemoryRegion *mr,
     memory_region_init(mr, name, size);
     mr->terminates = true;
     mr->destructor = memory_region_destructor_ram;
-    mr->ram_addr = qemu_ram_alloc(dev, name, size);
+    mr->ram_addr = qemu_ram_alloc(dev, name, size, mr);
     mr->backend_registered = true;
 }
 
@@ -998,7 +998,7 @@ void memory_region_init_ram_ptr(MemoryRegion *mr,
     memory_region_init(mr, name, size);
     mr->terminates = true;
     mr->destructor = memory_region_destructor_ram_from_ptr;
-    mr->ram_addr = qemu_ram_alloc_from_ptr(dev, name, size, ptr);
+    mr->ram_addr = qemu_ram_alloc_from_ptr(dev, name, size, ptr, mr);
     mr->backend_registered = true;
 }
 
@@ -1025,7 +1025,7 @@ void memory_region_init_rom_device(MemoryRegion *mr,
     mr->opaque = opaque;
     mr->terminates = true;
     mr->destructor = memory_region_destructor_rom_device;
-    mr->ram_addr = qemu_ram_alloc(dev, name, size);
+    mr->ram_addr = qemu_ram_alloc(dev, name, size, mr);
     mr->ram_addr |= cpu_register_io_memory(memory_region_read_thunk,
                                            memory_region_write_thunk,
                                            mr,
diff --git a/xen-all.c b/xen-all.c
index b5e28ab..b441fc1 100644
--- a/xen-all.c
+++ b/xen-all.c
@@ -181,7 +181,7 @@ static void xen_ram_init(ram_addr_t ram_size)
     }
 }
 
-void xen_ram_alloc(ram_addr_t ram_addr, ram_addr_t size)
+void xen_ram_alloc(ram_addr_t ram_addr, ram_addr_t size, MemoryRegion *mr)
 {
     unsigned long nr_pfn;
     xen_pfn_t *pfn_list;
diff --git a/xen-stub.c b/xen-stub.c
index efe2ab5..5fa400f 100644
--- a/xen-stub.c
+++ b/xen-stub.c
@@ -8,6 +8,7 @@
 
 #include "qemu-common.h"
 #include "hw/xen.h"
+#include "memory.h"
 
 void xenstore_store_pv_console_info(int i, CharDriverState *chr)
 {
@@ -30,7 +31,7 @@ void xen_cmos_set_s3_resume(void *opaque, int irq, int level)
 {
 }
 
-void xen_ram_alloc(ram_addr_t ram_addr, ram_addr_t size)
+void xen_ram_alloc(ram_addr_t ram_addr, ram_addr_t size, MemoryRegion *mr)
 {
 }
 
-- 
1.7.7.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Dec 18 15:33:53 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 18 Dec 2011 15:33:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RcIjk-0001g6-SM; Sun, 18 Dec 2011 15:33:16 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <avi@redhat.com>) id 1RcIjj-0001fw-Ka
	for xen-devel@lists.xensource.com; Sun, 18 Dec 2011 15:33:15 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1324222369!52650749!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDYzNzE=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9624 invoked from network); 18 Dec 2011 15:32:50 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-13.tower-27.messagelabs.com with SMTP;
	18 Dec 2011 15:32: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 pBIFX96R026573
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sun, 18 Dec 2011 10:33:10 -0500
Received: from cleopatra.tlv.redhat.com (cleopatra.tlv.redhat.com
	[10.35.255.11])
	by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id pBIFX8hl013149; Sun, 18 Dec 2011 10:33:09 -0500
Received: from s01.tlv.redhat.com (s01.tlv.redhat.com [10.35.255.8])
	by cleopatra.tlv.redhat.com (Postfix) with ESMTP id 7B572250B9E;
	Sun, 18 Dec 2011 17:33:01 +0200 (IST)
From: Avi Kivity <avi@redhat.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Sun, 18 Dec 2011 17:32:46 +0200
Message-Id: <1324222368-25156-1-git-send-email-avi@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
Cc: xen-devel@lists.xensource.com, qemu-devel@nongnu.org
Subject: [Xen-devel] [PATCH 0/2] xen: convert to memory API
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

I missed Xen while converting stuff to the memory API, as it's not in hw/.

Here comes the first simple patches; expect more as ram_addr_t is retired.
Please review & test (build tested only here).

Also in

  git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git memory/xen

(includes a patchset not yet merged upstream)

Avi Kivity (2):
  memory, xen: pass MemoryRegion to xen_ram_alloc()
  xen: convert to memory API

 exec-obsolete.h |    7 +++++--
 exec.c          |   10 ++++++----
 hw/xen.h        |    4 +++-
 memory.c        |    6 +++---
 xen-all.c       |   43 +++++++++++++++++++++++--------------------
 xen-stub.c      |    3 ++-
 6 files changed, 42 insertions(+), 31 deletions(-)

-- 
1.7.7.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Dec 18 15:33:53 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 18 Dec 2011 15:33:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RcIjk-0001g6-SM; Sun, 18 Dec 2011 15:33:16 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <avi@redhat.com>) id 1RcIjj-0001fw-Ka
	for xen-devel@lists.xensource.com; Sun, 18 Dec 2011 15:33:15 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1324222369!52650749!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDYzNzE=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9624 invoked from network); 18 Dec 2011 15:32:50 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-13.tower-27.messagelabs.com with SMTP;
	18 Dec 2011 15:32: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 pBIFX96R026573
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sun, 18 Dec 2011 10:33:10 -0500
Received: from cleopatra.tlv.redhat.com (cleopatra.tlv.redhat.com
	[10.35.255.11])
	by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id pBIFX8hl013149; Sun, 18 Dec 2011 10:33:09 -0500
Received: from s01.tlv.redhat.com (s01.tlv.redhat.com [10.35.255.8])
	by cleopatra.tlv.redhat.com (Postfix) with ESMTP id 7B572250B9E;
	Sun, 18 Dec 2011 17:33:01 +0200 (IST)
From: Avi Kivity <avi@redhat.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Sun, 18 Dec 2011 17:32:46 +0200
Message-Id: <1324222368-25156-1-git-send-email-avi@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
Cc: xen-devel@lists.xensource.com, qemu-devel@nongnu.org
Subject: [Xen-devel] [PATCH 0/2] xen: convert to memory API
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

I missed Xen while converting stuff to the memory API, as it's not in hw/.

Here comes the first simple patches; expect more as ram_addr_t is retired.
Please review & test (build tested only here).

Also in

  git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git memory/xen

(includes a patchset not yet merged upstream)

Avi Kivity (2):
  memory, xen: pass MemoryRegion to xen_ram_alloc()
  xen: convert to memory API

 exec-obsolete.h |    7 +++++--
 exec.c          |   10 ++++++----
 hw/xen.h        |    4 +++-
 memory.c        |    6 +++---
 xen-all.c       |   43 +++++++++++++++++++++++--------------------
 xen-stub.c      |    3 ++-
 6 files changed, 42 insertions(+), 31 deletions(-)

-- 
1.7.7.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Dec 18 15:44:24 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 18 Dec 2011 15: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.xensource.com>)
	id 1RcIu7-00028N-QC; Sun, 18 Dec 2011 15:43:59 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <peter.maydell@linaro.org>) id 1RcIu7-00028I-3C
	for xen-devel@lists.xensource.com; Sun, 18 Dec 2011 15:43:59 +0000
X-Env-Sender: peter.maydell@linaro.org
X-Msg-Ref: server-8.tower-174.messagelabs.com!1324223031!5994766!1
X-Originating-IP: [209.85.216.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22939 invoked from network); 18 Dec 2011 15:43:53 -0000
Received: from mail-qy0-f171.google.com (HELO mail-qy0-f171.google.com)
	(209.85.216.171)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Dec 2011 15:43:53 -0000
Received: by qcsc20 with SMTP id c20so36203315qcs.30
	for <xen-devel@lists.xensource.com>;
	Sun, 18 Dec 2011 07:43:51 -0800 (PST)
MIME-Version: 1.0
Received: by 10.229.76.215 with SMTP id d23mr4269876qck.45.1324223031646; Sun,
	18 Dec 2011 07:43:51 -0800 (PST)
Received: by 10.229.211.4 with HTTP; Sun, 18 Dec 2011 07:43:51 -0800 (PST)
In-Reply-To: <1324222368-25156-1-git-send-email-avi@redhat.com>
References: <1324222368-25156-1-git-send-email-avi@redhat.com>
Date: Sun, 18 Dec 2011 15:43:51 +0000
Message-ID: <CAFEAcA-1dhOZreqYCv4UxBqdwTiu7Bj81NKhcOND2Egd_rKu1Q@mail.gmail.com>
From: Peter Maydell <peter.maydell@linaro.org>
To: Avi Kivity <avi@redhat.com>
Cc: xen-devel@lists.xensource.com, qemu-devel@nongnu.org,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH 0/2] xen: convert to memory API
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 18 December 2011 15:32, Avi Kivity <avi@redhat.com> wrote:
> I missed Xen while converting stuff to the memory API, as it's not in hw/.
>
> Here comes the first simple patches; expect more as ram_addr_t is retired.

Er, ram_addr_t is going away? Can you elaborate?

-- PMM

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Dec 18 15:44:24 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 18 Dec 2011 15: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.xensource.com>)
	id 1RcIu7-00028N-QC; Sun, 18 Dec 2011 15:43:59 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <peter.maydell@linaro.org>) id 1RcIu7-00028I-3C
	for xen-devel@lists.xensource.com; Sun, 18 Dec 2011 15:43:59 +0000
X-Env-Sender: peter.maydell@linaro.org
X-Msg-Ref: server-8.tower-174.messagelabs.com!1324223031!5994766!1
X-Originating-IP: [209.85.216.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22939 invoked from network); 18 Dec 2011 15:43:53 -0000
Received: from mail-qy0-f171.google.com (HELO mail-qy0-f171.google.com)
	(209.85.216.171)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Dec 2011 15:43:53 -0000
Received: by qcsc20 with SMTP id c20so36203315qcs.30
	for <xen-devel@lists.xensource.com>;
	Sun, 18 Dec 2011 07:43:51 -0800 (PST)
MIME-Version: 1.0
Received: by 10.229.76.215 with SMTP id d23mr4269876qck.45.1324223031646; Sun,
	18 Dec 2011 07:43:51 -0800 (PST)
Received: by 10.229.211.4 with HTTP; Sun, 18 Dec 2011 07:43:51 -0800 (PST)
In-Reply-To: <1324222368-25156-1-git-send-email-avi@redhat.com>
References: <1324222368-25156-1-git-send-email-avi@redhat.com>
Date: Sun, 18 Dec 2011 15:43:51 +0000
Message-ID: <CAFEAcA-1dhOZreqYCv4UxBqdwTiu7Bj81NKhcOND2Egd_rKu1Q@mail.gmail.com>
From: Peter Maydell <peter.maydell@linaro.org>
To: Avi Kivity <avi@redhat.com>
Cc: xen-devel@lists.xensource.com, qemu-devel@nongnu.org,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH 0/2] xen: convert to memory API
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 18 December 2011 15:32, Avi Kivity <avi@redhat.com> wrote:
> I missed Xen while converting stuff to the memory API, as it's not in hw/.
>
> Here comes the first simple patches; expect more as ram_addr_t is retired.

Er, ram_addr_t is going away? Can you elaborate?

-- PMM

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Dec 18 15:55:07 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 18 Dec 2011 15:55:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RcJ4Q-0002IT-Ui; Sun, 18 Dec 2011 15:54:38 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RcJ4P-0002IO-KB
	for xen-devel@lists.xensource.com; Sun, 18 Dec 2011 15:54:37 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1324223669!6019064!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzAzNw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 445 invoked from network); 18 Dec 2011 15:54:30 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Dec 2011 15:54:30 -0000
X-IronPort-AV: E=Sophos;i="4.71,371,1320624000"; 
   d="scan'208";a="9539892"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Dec 2011 15:54:28 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sun, 18 Dec 2011 15:54:28 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RcJ4G-0005fg-3S;
	Sun, 18 Dec 2011 15:54:28 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RcJ4F-0003sI-NQ;
	Sun, 18 Dec 2011 15:54:27 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10530-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 18 Dec 2011 15:54:27 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing test] 10530: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10530 xen-4.1-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10530/

Regressions :-(

Tests which did not succeed and are blocking,including tests which could not be run:
 build-i386                    4 xen-build                 fail REGR. vs. 10501
 build-amd64-oldkern           4 xen-build                 fail REGR. vs. 10501
 build-amd64                   4 xen-build                 fail REGR. vs. 10501
 build-amd64-pvops             4 kernel-build              fail REGR. vs. 10501

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pv             1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf-pin  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl             1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pair           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-win         1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win       1 xen-build-check(1)           blocked  n/a
 test-i386-i386-win            1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-winxpsp3    1 xen-build-check(1)           blocked  n/a

version targeted for testing:
 xen                  e2af3c4e4c1d
baseline version:
 xen                  bb365e21314d

------------------------------------------------------------
People who touched revisions under test:
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  George Dunlap <george.dunlap@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Keir Fraser <keir@xen.org>
  Liu, Jinsong <jinsong.liu@intel.com>
  Paul Durrant <paul.durrant@citrix.com>
  Tim Deegan <tim@xen.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  fail    
 build-i386                                                   fail    
 build-amd64-oldkern                                          fail    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            fail    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          blocked 
 test-amd64-i386-xl                                           blocked 
 test-i386-i386-xl                                            blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-amd64-xl-win7-amd64                               blocked 
 test-amd64-i386-xl-win7-amd64                                blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-amd64-xl-pcipt-intel                              blocked 
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        blocked 
 test-amd64-i386-pair                                         blocked 
 test-i386-i386-pair                                          blocked 
 test-amd64-amd64-xl-sedf-pin                                 blocked 
 test-amd64-amd64-pv                                          blocked 
 test-amd64-i386-pv                                           blocked 
 test-i386-i386-pv                                            blocked 
 test-amd64-amd64-xl-sedf                                     blocked 
 test-amd64-i386-win-vcpus1                                   blocked 
 test-amd64-i386-xl-win-vcpus1                                blocked 
 test-amd64-i386-xl-winxpsp3-vcpus1                           blocked 
 test-amd64-amd64-win                                         blocked 
 test-amd64-i386-win                                          blocked 
 test-i386-i386-win                                           blocked 
 test-amd64-amd64-xl-win                                      blocked 
 test-i386-i386-xl-win                                        blocked 
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-xl-winxpsp3                                 blocked 
 test-i386-i386-xl-winxpsp3                                   blocked 


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   23205:e2af3c4e4c1d
tag:         tip
user:        Liu, Jinsong <jinsong.liu@intel.com>
date:        Sun Dec 18 14:48:28 2011 +0000
    
    X86-MCE: fix a bug of xen-mceinj tool
    
    Fix a bug of xen-mceinj tool which used to test mce by software way.
    
    Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
    Committed-by: Keir Fraser <keir@xen.org>
    xen-unstable changeset:   24429:9587ccc2ae31
    xen-unstable date:        Sun Dec 18 14:40:00 2011 +0000
    
    
changeset:   23204:6ccf1820fb94
user:        Paul Durrant <paul.durrant@citrix.com>
date:        Sun Dec 18 14:47:23 2011 +0000
    
    Allow VMs to query their own grant table version.
    
    Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    xen-unstable changeset:   24427:931bf1105730
    xen-unstable date:        Sun Dec 18 14:38:32 2011 +0000
    
    
changeset:   23203:c62738ea1bb4
user:        Jan Beulich <jbeulich@suse.com>
date:        Sun Dec 18 14:45:44 2011 +0000
    
    x86/AMD: use correct shift count when merging model and stepping
    
    ... for legacy errata matching.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    xen-unstable changeset:   24412:99caac2e35df
    xen-unstable date:        Thu Dec 15 14:28:45 2011 +0100
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   23202:bb365e21314d
user:        Tim Deegan <tim@xen.org>
date:        Thu Dec 15 11:20:19 2011 +0000
    
    x86/mm/p2m: fix pod locking
    
    The path p2m-lookup -> p2m-pt->get_entry -> 1GB PoD superpage ->
    pod_demand_populate ends in the pod code performing a p2m_set_entry with
    no locks held (in order to split the 1GB superpage into 512 2MB ones)
    
    Further, it calls p2m_unlock after that, which will break the spinlock.
    
    This patch attempts to fix that.
    
    Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
    Acked-by: George Dunlap <george.dunlap@eu.citrix.com>
    Acked-by: Tim Deegan <tim@xen.org>
    xen-unstable changeset:   24189:7da681c490e0
    xen-unstable date:        Thu Nov 24 15:20:57 2011 +0000
    
    
========================================
commit 3981d218912e186cb4205ee6732f446c177a36a2
Author: Jean Guyader <jean.guyader@eu.citrix.com>
Date:   Tue Nov 22 18:49:15 2011 +0000

    qemu-xen: Don't redefine libpci (3.1.7) defines.
    
    These values are already defined by the libpci heders in the version
    3.1.7.
    
    PCI_STATUS_66MHZ
    PCI_STATUS_RESERVED2
    PCI_STATUS_FAST_BACK
    PCI_MSIX_TABSIZE
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    (cherry picked from commit 174d92a73a5d5e67c49501383a519021b72a2468)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Dec 18 15:55:07 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 18 Dec 2011 15:55:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RcJ4Q-0002IT-Ui; Sun, 18 Dec 2011 15:54:38 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RcJ4P-0002IO-KB
	for xen-devel@lists.xensource.com; Sun, 18 Dec 2011 15:54:37 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1324223669!6019064!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzAzNw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 445 invoked from network); 18 Dec 2011 15:54:30 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Dec 2011 15:54:30 -0000
X-IronPort-AV: E=Sophos;i="4.71,371,1320624000"; 
   d="scan'208";a="9539892"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Dec 2011 15:54:28 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sun, 18 Dec 2011 15:54:28 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RcJ4G-0005fg-3S;
	Sun, 18 Dec 2011 15:54:28 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RcJ4F-0003sI-NQ;
	Sun, 18 Dec 2011 15:54:27 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10530-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 18 Dec 2011 15:54:27 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing test] 10530: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10530 xen-4.1-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10530/

Regressions :-(

Tests which did not succeed and are blocking,including tests which could not be run:
 build-i386                    4 xen-build                 fail REGR. vs. 10501
 build-amd64-oldkern           4 xen-build                 fail REGR. vs. 10501
 build-amd64                   4 xen-build                 fail REGR. vs. 10501
 build-amd64-pvops             4 kernel-build              fail REGR. vs. 10501

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pv             1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf-pin  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl             1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pair           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-win         1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win       1 xen-build-check(1)           blocked  n/a
 test-i386-i386-win            1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-winxpsp3    1 xen-build-check(1)           blocked  n/a

version targeted for testing:
 xen                  e2af3c4e4c1d
baseline version:
 xen                  bb365e21314d

------------------------------------------------------------
People who touched revisions under test:
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  George Dunlap <george.dunlap@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Keir Fraser <keir@xen.org>
  Liu, Jinsong <jinsong.liu@intel.com>
  Paul Durrant <paul.durrant@citrix.com>
  Tim Deegan <tim@xen.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  fail    
 build-i386                                                   fail    
 build-amd64-oldkern                                          fail    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            fail    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          blocked 
 test-amd64-i386-xl                                           blocked 
 test-i386-i386-xl                                            blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-amd64-xl-win7-amd64                               blocked 
 test-amd64-i386-xl-win7-amd64                                blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-amd64-xl-pcipt-intel                              blocked 
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        blocked 
 test-amd64-i386-pair                                         blocked 
 test-i386-i386-pair                                          blocked 
 test-amd64-amd64-xl-sedf-pin                                 blocked 
 test-amd64-amd64-pv                                          blocked 
 test-amd64-i386-pv                                           blocked 
 test-i386-i386-pv                                            blocked 
 test-amd64-amd64-xl-sedf                                     blocked 
 test-amd64-i386-win-vcpus1                                   blocked 
 test-amd64-i386-xl-win-vcpus1                                blocked 
 test-amd64-i386-xl-winxpsp3-vcpus1                           blocked 
 test-amd64-amd64-win                                         blocked 
 test-amd64-i386-win                                          blocked 
 test-i386-i386-win                                           blocked 
 test-amd64-amd64-xl-win                                      blocked 
 test-i386-i386-xl-win                                        blocked 
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-xl-winxpsp3                                 blocked 
 test-i386-i386-xl-winxpsp3                                   blocked 


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   23205:e2af3c4e4c1d
tag:         tip
user:        Liu, Jinsong <jinsong.liu@intel.com>
date:        Sun Dec 18 14:48:28 2011 +0000
    
    X86-MCE: fix a bug of xen-mceinj tool
    
    Fix a bug of xen-mceinj tool which used to test mce by software way.
    
    Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
    Committed-by: Keir Fraser <keir@xen.org>
    xen-unstable changeset:   24429:9587ccc2ae31
    xen-unstable date:        Sun Dec 18 14:40:00 2011 +0000
    
    
changeset:   23204:6ccf1820fb94
user:        Paul Durrant <paul.durrant@citrix.com>
date:        Sun Dec 18 14:47:23 2011 +0000
    
    Allow VMs to query their own grant table version.
    
    Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    xen-unstable changeset:   24427:931bf1105730
    xen-unstable date:        Sun Dec 18 14:38:32 2011 +0000
    
    
changeset:   23203:c62738ea1bb4
user:        Jan Beulich <jbeulich@suse.com>
date:        Sun Dec 18 14:45:44 2011 +0000
    
    x86/AMD: use correct shift count when merging model and stepping
    
    ... for legacy errata matching.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    xen-unstable changeset:   24412:99caac2e35df
    xen-unstable date:        Thu Dec 15 14:28:45 2011 +0100
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   23202:bb365e21314d
user:        Tim Deegan <tim@xen.org>
date:        Thu Dec 15 11:20:19 2011 +0000
    
    x86/mm/p2m: fix pod locking
    
    The path p2m-lookup -> p2m-pt->get_entry -> 1GB PoD superpage ->
    pod_demand_populate ends in the pod code performing a p2m_set_entry with
    no locks held (in order to split the 1GB superpage into 512 2MB ones)
    
    Further, it calls p2m_unlock after that, which will break the spinlock.
    
    This patch attempts to fix that.
    
    Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
    Acked-by: George Dunlap <george.dunlap@eu.citrix.com>
    Acked-by: Tim Deegan <tim@xen.org>
    xen-unstable changeset:   24189:7da681c490e0
    xen-unstable date:        Thu Nov 24 15:20:57 2011 +0000
    
    
========================================
commit 3981d218912e186cb4205ee6732f446c177a36a2
Author: Jean Guyader <jean.guyader@eu.citrix.com>
Date:   Tue Nov 22 18:49:15 2011 +0000

    qemu-xen: Don't redefine libpci (3.1.7) defines.
    
    These values are already defined by the libpci heders in the version
    3.1.7.
    
    PCI_STATUS_66MHZ
    PCI_STATUS_RESERVED2
    PCI_STATUS_FAST_BACK
    PCI_MSIX_TABSIZE
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    (cherry picked from commit 174d92a73a5d5e67c49501383a519021b72a2468)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Dec 18 15:57:46 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 18 Dec 2011 15:57:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RcJ72-0002Q9-Md; Sun, 18 Dec 2011 15:57:20 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <avi@redhat.com>) id 1RcJ71-0002Pq-BI
	for xen-devel@lists.xensource.com; Sun, 18 Dec 2011 15:57:19 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1324223831!7736972!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDYzNzE=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11301 invoked from network); 18 Dec 2011 15:57:12 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-2.tower-182.messagelabs.com with SMTP;
	18 Dec 2011 15:57:12 -0000
Received: from int-mx12.intmail.prod.int.phx2.redhat.com
	(int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id pBIFv8MV014575
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sun, 18 Dec 2011 10:57:08 -0500
Received: from balrog.usersys.redhat.com (dhcp-4-24.tlv.redhat.com
	[10.35.4.24])
	by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id pBIFv6wf016097; Sun, 18 Dec 2011 10:57:06 -0500
Message-ID: <4EEE0D51.5010403@redhat.com>
Date: Sun, 18 Dec 2011 17:57:05 +0200
From: Avi Kivity <avi@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:8.0) Gecko/20111115 Thunderbird/8.0
MIME-Version: 1.0
To: Peter Maydell <peter.maydell@linaro.org>
References: <1324222368-25156-1-git-send-email-avi@redhat.com>
	<CAFEAcA-1dhOZreqYCv4UxBqdwTiu7Bj81NKhcOND2Egd_rKu1Q@mail.gmail.com>
In-Reply-To: <CAFEAcA-1dhOZreqYCv4UxBqdwTiu7Bj81NKhcOND2Egd_rKu1Q@mail.gmail.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.25
Cc: xen-devel@lists.xensource.com, qemu-devel@nongnu.org,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH 0/2] xen: convert to memory API
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 12/18/2011 05:43 PM, Peter Maydell wrote:
> On 18 December 2011 15:32, Avi Kivity <avi@redhat.com> wrote:
> > I missed Xen while converting stuff to the memory API, as it's not in hw/.
> >
> > Here comes the first simple patches; expect more as ram_addr_t is retired.
>
> Er, ram_addr_t is going away? Can you elaborate?
>

Nothing dramatic.  Uses of ram_addr_t to denote RAM will be replaced by
a (MemoryRegion *, offset) pair.  The type of the offset will be called
ram_addr_t.

-- 
error compiling committee.c: too many arguments to function


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Dec 18 15:57:46 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 18 Dec 2011 15:57:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RcJ72-0002Q9-Md; Sun, 18 Dec 2011 15:57:20 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <avi@redhat.com>) id 1RcJ71-0002Pq-BI
	for xen-devel@lists.xensource.com; Sun, 18 Dec 2011 15:57:19 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1324223831!7736972!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDYzNzE=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11301 invoked from network); 18 Dec 2011 15:57:12 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-2.tower-182.messagelabs.com with SMTP;
	18 Dec 2011 15:57:12 -0000
Received: from int-mx12.intmail.prod.int.phx2.redhat.com
	(int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id pBIFv8MV014575
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sun, 18 Dec 2011 10:57:08 -0500
Received: from balrog.usersys.redhat.com (dhcp-4-24.tlv.redhat.com
	[10.35.4.24])
	by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id pBIFv6wf016097; Sun, 18 Dec 2011 10:57:06 -0500
Message-ID: <4EEE0D51.5010403@redhat.com>
Date: Sun, 18 Dec 2011 17:57:05 +0200
From: Avi Kivity <avi@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:8.0) Gecko/20111115 Thunderbird/8.0
MIME-Version: 1.0
To: Peter Maydell <peter.maydell@linaro.org>
References: <1324222368-25156-1-git-send-email-avi@redhat.com>
	<CAFEAcA-1dhOZreqYCv4UxBqdwTiu7Bj81NKhcOND2Egd_rKu1Q@mail.gmail.com>
In-Reply-To: <CAFEAcA-1dhOZreqYCv4UxBqdwTiu7Bj81NKhcOND2Egd_rKu1Q@mail.gmail.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.25
Cc: xen-devel@lists.xensource.com, qemu-devel@nongnu.org,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH 0/2] xen: convert to memory API
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 12/18/2011 05:43 PM, Peter Maydell wrote:
> On 18 December 2011 15:32, Avi Kivity <avi@redhat.com> wrote:
> > I missed Xen while converting stuff to the memory API, as it's not in hw/.
> >
> > Here comes the first simple patches; expect more as ram_addr_t is retired.
>
> Er, ram_addr_t is going away? Can you elaborate?
>

Nothing dramatic.  Uses of ram_addr_t to denote RAM will be replaced by
a (MemoryRegion *, offset) pair.  The type of the offset will be called
ram_addr_t.

-- 
error compiling committee.c: too many arguments to function


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Dec 18 17:42:41 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 18 Dec 2011 17:42:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RcKkN-0003YE-QX; Sun, 18 Dec 2011 17:42:03 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <avi@redhat.com>) id 1RcKkL-0003Y9-MH
	for xen-devel@lists.xensource.com; Sun, 18 Dec 2011 17:42:02 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1324230115!7853710!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDYzNzE=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11283 invoked from network); 18 Dec 2011 17:41:55 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-11.tower-216.messagelabs.com with SMTP;
	18 Dec 2011 17:41:55 -0000
Received: from int-mx01.intmail.prod.int.phx2.redhat.com
	(int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id pBIHfoet021459
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sun, 18 Dec 2011 12:41:50 -0500
Received: from balrog.usersys.redhat.com (dhcp-4-24.tlv.redhat.com
	[10.35.4.24])
	by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP
	id pBIHfki1025777; Sun, 18 Dec 2011 12:41:47 -0500
Message-ID: <4EEE25DA.2080400@redhat.com>
Date: Sun, 18 Dec 2011 19:41:46 +0200
From: Avi Kivity <avi@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:8.0) Gecko/20111115 Thunderbird/8.0
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <1323467645-24271-1-git-send-email-anthony.perard@citrix.com>
	<1323467645-24271-6-git-send-email-anthony.perard@citrix.com>
	<4EE3382D.80903@web.de>
	<alpine.DEB.2.00.1112121259180.3517@kaball-desktop>
	<4EE609BF.1070307@siemens.com>
	<alpine.DEB.2.00.1112121438410.3517@kaball-desktop>
	<4EE617BA.4030102@siemens.com>
	<alpine.DEB.2.00.1112121527130.3517@kaball-desktop>
In-Reply-To: <alpine.DEB.2.00.1112121527130.3517@kaball-desktop>
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.11
Cc: Anthony Perard <anthony.perard@citrix.com>,
	Jan Kiszka <jan.kiszka@siemens.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	QEMU-devel <qemu-devel@nongnu.org>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH V2 5/5] vga-cirrus: Workaround
 during restore when using Xen.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 12/12/2011 05:32 PM, Stefano Stabellini wrote:
> > Really, I think this is something inherently incompatible with the
> > current memory API. If Xen has this unfixable special "requirement"
> > (it's rather a design issue IMHO), adjust the API and adapt all devices.
> > Hot-fixing only a single one this way is no good idea long term.
>
> Fair enough.
> What about introducing a type of savevm state that is going to be
> restored before machine->init?
> This way we could save and restore our physmap and we could handle
> memory maps and allocations transparently.

There is no guarantee there is a physical mapping for the framebuffer. 
A guest could unmap the framebuffer, and its display should still be
valid.  It can even update it by using the cirrus bitblt functions.

I suggest doing the following:

1. keep cirrus code unchanged
2. when the framebuffer is first mapped into physical memory (as known
by your CPUPhysMemoryClient), copy it into a temporary buffer, map the
guest memory into memory_region_get_ram_ptr(), and copy the temporary
buffer into memory_region_get_ram_ptr()
3. when the framebuffer is unmapped, do the reverse: copy the
framebuffer out, mmap() some anonymous memory into
memory_region_get_ram_ptr(), and copy the temporary buffer into
memory_region_get_ram_ptr()

We can later add optimizations to avoid the copy, but correctness before
performance.  I think currently a guest moving its cirrus BAR will
break, no?

-- 
error compiling committee.c: too many arguments to function


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Dec 18 17:42:41 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 18 Dec 2011 17:42:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RcKkN-0003YE-QX; Sun, 18 Dec 2011 17:42:03 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <avi@redhat.com>) id 1RcKkL-0003Y9-MH
	for xen-devel@lists.xensource.com; Sun, 18 Dec 2011 17:42:02 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1324230115!7853710!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDYzNzE=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11283 invoked from network); 18 Dec 2011 17:41:55 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-11.tower-216.messagelabs.com with SMTP;
	18 Dec 2011 17:41:55 -0000
Received: from int-mx01.intmail.prod.int.phx2.redhat.com
	(int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id pBIHfoet021459
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sun, 18 Dec 2011 12:41:50 -0500
Received: from balrog.usersys.redhat.com (dhcp-4-24.tlv.redhat.com
	[10.35.4.24])
	by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP
	id pBIHfki1025777; Sun, 18 Dec 2011 12:41:47 -0500
Message-ID: <4EEE25DA.2080400@redhat.com>
Date: Sun, 18 Dec 2011 19:41:46 +0200
From: Avi Kivity <avi@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:8.0) Gecko/20111115 Thunderbird/8.0
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <1323467645-24271-1-git-send-email-anthony.perard@citrix.com>
	<1323467645-24271-6-git-send-email-anthony.perard@citrix.com>
	<4EE3382D.80903@web.de>
	<alpine.DEB.2.00.1112121259180.3517@kaball-desktop>
	<4EE609BF.1070307@siemens.com>
	<alpine.DEB.2.00.1112121438410.3517@kaball-desktop>
	<4EE617BA.4030102@siemens.com>
	<alpine.DEB.2.00.1112121527130.3517@kaball-desktop>
In-Reply-To: <alpine.DEB.2.00.1112121527130.3517@kaball-desktop>
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.11
Cc: Anthony Perard <anthony.perard@citrix.com>,
	Jan Kiszka <jan.kiszka@siemens.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	QEMU-devel <qemu-devel@nongnu.org>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH V2 5/5] vga-cirrus: Workaround
 during restore when using Xen.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 12/12/2011 05:32 PM, Stefano Stabellini wrote:
> > Really, I think this is something inherently incompatible with the
> > current memory API. If Xen has this unfixable special "requirement"
> > (it's rather a design issue IMHO), adjust the API and adapt all devices.
> > Hot-fixing only a single one this way is no good idea long term.
>
> Fair enough.
> What about introducing a type of savevm state that is going to be
> restored before machine->init?
> This way we could save and restore our physmap and we could handle
> memory maps and allocations transparently.

There is no guarantee there is a physical mapping for the framebuffer. 
A guest could unmap the framebuffer, and its display should still be
valid.  It can even update it by using the cirrus bitblt functions.

I suggest doing the following:

1. keep cirrus code unchanged
2. when the framebuffer is first mapped into physical memory (as known
by your CPUPhysMemoryClient), copy it into a temporary buffer, map the
guest memory into memory_region_get_ram_ptr(), and copy the temporary
buffer into memory_region_get_ram_ptr()
3. when the framebuffer is unmapped, do the reverse: copy the
framebuffer out, mmap() some anonymous memory into
memory_region_get_ram_ptr(), and copy the temporary buffer into
memory_region_get_ram_ptr()

We can later add optimizations to avoid the copy, but correctness before
performance.  I think currently a guest moving its cirrus BAR will
break, no?

-- 
error compiling committee.c: too many arguments to function


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Dec 18 17:44:13 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 18 Dec 2011 17:44:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RcKlw-0003bm-AN; Sun, 18 Dec 2011 17:43:40 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <avi@redhat.com>) id 1RcKlu-0003bY-F5
	for xen-devel@lists.xensource.com; Sun, 18 Dec 2011 17:43:38 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1324230185!45357465!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDYzNzE=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21931 invoked from network); 18 Dec 2011 17:43:06 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-12.tower-27.messagelabs.com with SMTP;
	18 Dec 2011 17:43:06 -0000
Received: from int-mx12.intmail.prod.int.phx2.redhat.com
	(int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id pBIHhX29002037
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sun, 18 Dec 2011 12:43:34 -0500
Received: from balrog.usersys.redhat.com (dhcp-4-24.tlv.redhat.com
	[10.35.4.24])
	by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id pBIHhVke005138; Sun, 18 Dec 2011 12:43:32 -0500
Message-ID: <4EEE2643.1070504@redhat.com>
Date: Sun, 18 Dec 2011 19:43:31 +0200
From: Avi Kivity <avi@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:8.0) Gecko/20111115 Thunderbird/8.0
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <1323467645-24271-1-git-send-email-anthony.perard@citrix.com>
	<1323467645-24271-6-git-send-email-anthony.perard@citrix.com>
	<4EE3382D.80903@web.de>
	<alpine.DEB.2.00.1112121259180.3517@kaball-desktop>
	<4EE609BF.1070307@siemens.com>
	<alpine.DEB.2.00.1112121438410.3517@kaball-desktop>
	<4EE617BA.4030102@siemens.com>
	<alpine.DEB.2.00.1112121527130.3517@kaball-desktop>
	<alpine.DEB.2.00.1112131141170.3517@kaball-desktop>
In-Reply-To: <alpine.DEB.2.00.1112131141170.3517@kaball-desktop>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.25
Cc: Anthony Perard <anthony.perard@citrix.com>,
	Jan Kiszka <jan.kiszka@siemens.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	QEMU-devel <qemu-devel@nongnu.org>
Subject: Re: [Xen-devel] [Qemu-devel] early_savevm
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 12/13/2011 01:55 PM, Stefano Stabellini wrote:
> A bit more context to my suggestion:
>
> - we open the save state file and check the magic number and the
> version number before machine->init();
>
> - we add a new set of entries to the save state file that contains
> early_savevm functions: they are called before machine->init();
>
> - after reaching the end of the early_savevm functions we stop parsing
> the save state file and we call machine->init();
>
> - after machine->init() is completed we continue parsing the save state
> file as usual.

I think this is fragile.  In the general case you can't describe the
framebuffer BAR with just a single number, it may be partially obscured
by another BAR.  It's better to fix this behind the scenes.

-- 
error compiling committee.c: too many arguments to function


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Dec 18 17:44:13 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 18 Dec 2011 17:44:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RcKlw-0003bm-AN; Sun, 18 Dec 2011 17:43:40 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <avi@redhat.com>) id 1RcKlu-0003bY-F5
	for xen-devel@lists.xensource.com; Sun, 18 Dec 2011 17:43:38 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1324230185!45357465!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDYzNzE=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21931 invoked from network); 18 Dec 2011 17:43:06 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-12.tower-27.messagelabs.com with SMTP;
	18 Dec 2011 17:43:06 -0000
Received: from int-mx12.intmail.prod.int.phx2.redhat.com
	(int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id pBIHhX29002037
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sun, 18 Dec 2011 12:43:34 -0500
Received: from balrog.usersys.redhat.com (dhcp-4-24.tlv.redhat.com
	[10.35.4.24])
	by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id pBIHhVke005138; Sun, 18 Dec 2011 12:43:32 -0500
Message-ID: <4EEE2643.1070504@redhat.com>
Date: Sun, 18 Dec 2011 19:43:31 +0200
From: Avi Kivity <avi@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:8.0) Gecko/20111115 Thunderbird/8.0
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <1323467645-24271-1-git-send-email-anthony.perard@citrix.com>
	<1323467645-24271-6-git-send-email-anthony.perard@citrix.com>
	<4EE3382D.80903@web.de>
	<alpine.DEB.2.00.1112121259180.3517@kaball-desktop>
	<4EE609BF.1070307@siemens.com>
	<alpine.DEB.2.00.1112121438410.3517@kaball-desktop>
	<4EE617BA.4030102@siemens.com>
	<alpine.DEB.2.00.1112121527130.3517@kaball-desktop>
	<alpine.DEB.2.00.1112131141170.3517@kaball-desktop>
In-Reply-To: <alpine.DEB.2.00.1112131141170.3517@kaball-desktop>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.25
Cc: Anthony Perard <anthony.perard@citrix.com>,
	Jan Kiszka <jan.kiszka@siemens.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	QEMU-devel <qemu-devel@nongnu.org>
Subject: Re: [Xen-devel] [Qemu-devel] early_savevm
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 12/13/2011 01:55 PM, Stefano Stabellini wrote:
> A bit more context to my suggestion:
>
> - we open the save state file and check the magic number and the
> version number before machine->init();
>
> - we add a new set of entries to the save state file that contains
> early_savevm functions: they are called before machine->init();
>
> - after reaching the end of the early_savevm functions we stop parsing
> the save state file and we call machine->init();
>
> - after machine->init() is completed we continue parsing the save state
> file as usual.

I think this is fragile.  In the general case you can't describe the
framebuffer BAR with just a single number, it may be partially obscured
by another BAR.  It's better to fix this behind the scenes.

-- 
error compiling committee.c: too many arguments to function


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Dec 18 17:45:36 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 18 Dec 2011 17:45:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RcKnN-0003hQ-QK; Sun, 18 Dec 2011 17:45:09 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <avi@redhat.com>) id 1RcKnM-0003gm-0M
	for xen-devel@lists.xensource.com; Sun, 18 Dec 2011 17:45:08 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1324230301!7740699!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDYzNzE=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4222 invoked from network); 18 Dec 2011 17:45:01 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-4.tower-182.messagelabs.com with SMTP;
	18 Dec 2011 17:45:01 -0000
Received: from int-mx12.intmail.prod.int.phx2.redhat.com
	(int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id pBIHiwQa000368
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sun, 18 Dec 2011 12:44:58 -0500
Received: from balrog.usersys.redhat.com (dhcp-4-24.tlv.redhat.com
	[10.35.4.24])
	by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id pBIHit8s005308; Sun, 18 Dec 2011 12:44:56 -0500
Message-ID: <4EEE2697.5020602@redhat.com>
Date: Sun, 18 Dec 2011 19:44:55 +0200
From: Avi Kivity <avi@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:8.0) Gecko/20111115 Thunderbird/8.0
MIME-Version: 1.0
To: Anthony Liguori <anthony@codemonkey.ws>
References: <1323467645-24271-1-git-send-email-anthony.perard@citrix.com>
	<1323467645-24271-2-git-send-email-anthony.perard@citrix.com>
	<4EEA0E72.20105@codemonkey.ws>
In-Reply-To: <4EEA0E72.20105@codemonkey.ws>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.25
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	QEMU-devel <qemu-devel@nongnu.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH V2 1/5] vl.c: Do not save RAM
 state when Xen is used.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 12/15/2011 05:12 PM, Anthony Liguori wrote:
> On 12/09/2011 03:54 PM, Anthony PERARD wrote:
>> In Xen case, the guest RAM is not handle by QEMU, and it is saved by
>> Xen tools.
>> So, we just avoid to register the RAM save state handler.
>>
>> -    register_savevm_live(NULL, "ram", 0, 4, NULL, ram_save_live, NULL,
>> -                         ram_load, NULL);
>> +    if (!xen_enabled()) {
>> +        register_savevm_live(NULL, "ram", 0, 4, NULL, ram_save_live,
>> NULL,
>> +                             ram_load, NULL);
>> +    }
>
> Why don't you just unregister the section in the xen initialization
> code?  That way we don't have xen_enabled()'s sprinkled all over the
> place.

It's better to see them up front, having the magical string "ram"
connect the two is hard to follow.

-- 
error compiling committee.c: too many arguments to function


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Dec 18 17:45:36 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 18 Dec 2011 17:45:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RcKnN-0003hQ-QK; Sun, 18 Dec 2011 17:45:09 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <avi@redhat.com>) id 1RcKnM-0003gm-0M
	for xen-devel@lists.xensource.com; Sun, 18 Dec 2011 17:45:08 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1324230301!7740699!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDYzNzE=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4222 invoked from network); 18 Dec 2011 17:45:01 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-4.tower-182.messagelabs.com with SMTP;
	18 Dec 2011 17:45:01 -0000
Received: from int-mx12.intmail.prod.int.phx2.redhat.com
	(int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id pBIHiwQa000368
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sun, 18 Dec 2011 12:44:58 -0500
Received: from balrog.usersys.redhat.com (dhcp-4-24.tlv.redhat.com
	[10.35.4.24])
	by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id pBIHit8s005308; Sun, 18 Dec 2011 12:44:56 -0500
Message-ID: <4EEE2697.5020602@redhat.com>
Date: Sun, 18 Dec 2011 19:44:55 +0200
From: Avi Kivity <avi@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:8.0) Gecko/20111115 Thunderbird/8.0
MIME-Version: 1.0
To: Anthony Liguori <anthony@codemonkey.ws>
References: <1323467645-24271-1-git-send-email-anthony.perard@citrix.com>
	<1323467645-24271-2-git-send-email-anthony.perard@citrix.com>
	<4EEA0E72.20105@codemonkey.ws>
In-Reply-To: <4EEA0E72.20105@codemonkey.ws>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.25
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	QEMU-devel <qemu-devel@nongnu.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH V2 1/5] vl.c: Do not save RAM
 state when Xen is used.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 12/15/2011 05:12 PM, Anthony Liguori wrote:
> On 12/09/2011 03:54 PM, Anthony PERARD wrote:
>> In Xen case, the guest RAM is not handle by QEMU, and it is saved by
>> Xen tools.
>> So, we just avoid to register the RAM save state handler.
>>
>> -    register_savevm_live(NULL, "ram", 0, 4, NULL, ram_save_live, NULL,
>> -                         ram_load, NULL);
>> +    if (!xen_enabled()) {
>> +        register_savevm_live(NULL, "ram", 0, 4, NULL, ram_save_live,
>> NULL,
>> +                             ram_load, NULL);
>> +    }
>
> Why don't you just unregister the section in the xen initialization
> code?  That way we don't have xen_enabled()'s sprinkled all over the
> place.

It's better to see them up front, having the magical string "ram"
connect the two is hard to follow.

-- 
error compiling committee.c: too many arguments to function


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Dec 18 18:12:29 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 18 Dec 2011 18: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.xensource.com>)
	id 1RcLDR-0004BH-83; Sun, 18 Dec 2011 18:12:05 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RcLDP-0004BC-II
	for xen-devel@lists.xensource.com; Sun, 18 Dec 2011 18:12:03 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1324231917!6025844!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzAzNw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2063 invoked from network); 18 Dec 2011 18:11:57 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Dec 2011 18:11:57 -0000
X-IronPort-AV: E=Sophos;i="4.71,372,1320624000"; 
   d="scan'208";a="9540964"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Dec 2011 18:11:57 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sun, 18 Dec 2011 18:11:57 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RcLDI-0006QY-Ls;
	Sun, 18 Dec 2011 18:11:56 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RcLDI-0005C9-FN;
	Sun, 18 Dec 2011 18:11:56 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10531-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 18 Dec 2011 18:11:56 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10531: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10531 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10531/

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. 10528
 test-amd64-amd64-xl-win7-amd64  7 windows-install         fail REGR. vs. 10528

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-amd64-xl-sedf-pin 12 guest-saverestore.2       fail REGR. vs. 10528
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass

version targeted for testing:
 xen                  e3daa5b58464
baseline version:
 xen                  a4bff36780a3

------------------------------------------------------------
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>
  Keir Fraser <keir@xen.org>
  Liu, Jinsong <jinsong.liu@intel.com>
  Paul Durrant <paul.durrant@citrix.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   24430:e3daa5b58464
tag:         tip
user:        Paul Durrant <paul.durrant@citrix.com>
date:        Sun Dec 18 14:40:39 2011 +0000
    
    hvmloader: Re-name xenstore key used to save VM generation ID buffer address.
    
    Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
    
    
changeset:   24429:9587ccc2ae31
user:        Liu, Jinsong <jinsong.liu@intel.com>
date:        Sun Dec 18 14:40:00 2011 +0000
    
    X86-MCE: fix a bug of xen-mceinj tool
    
    Fix a bug of xen-mceinj tool which used to test mce by software way.
    
    Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24428:5b4b7e565ab8
user:        Paul Durrant <paul.durrant@citrix.com>
date:        Sun Dec 18 14:39:14 2011 +0000
    
    Fix grant_table v2 status mapping.
    
    Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24427:931bf1105730
user:        Paul Durrant <paul.durrant@citrix.com>
date:        Sun Dec 18 14:38:32 2011 +0000
    
    Allow VMs to query their own grant table version.
    
    Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24426:45e4b947873e
user:        Daniel De Graaf <dgdegra@tycho.nsa.gov>
date:        Sun Dec 18 14:35:03 2011 +0000
    
    xl.pod.1: improve documentation of FLASK commands
    
    Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
    
    
changeset:   24425:053a44894279
user:        Daniel De Graaf <dgdegra@tycho.nsa.gov>
date:        Sun Dec 18 14:34:42 2011 +0000
    
    xsm: add checks on PCI configuration access
    
    PCI configuration access is allowed to any privileged domain
    regardless of I/O port access restrictions; add XSM hooks for these
    accesses.
    
    Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
    
    
changeset:   24424:9ba6ddcd02c4
user:        Daniel De Graaf <dgdegra@tycho.nsa.gov>
date:        Sun Dec 18 14:34:12 2011 +0000
    
    xsm: fix up dummy ops
    
    Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
    
    
changeset:   24423:069c08b7de46
user:        Daniel De Graaf <dgdegra@tycho.nsa.gov>
date:        Sun Dec 18 14:33:48 2011 +0000
    
    xsm: Add missing access checks
    
    Actions requiring IS_PRIV should also require some XSM access control
    in order for XSM to be useful in confining multiple privileged
    domains. Add XSM hooks for new hypercalls and sub-commands that are
    under IS_PRIV but not currently under any access checks.
    
    Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
    
    
changeset:   24422:5ce5aca98404
user:        Daniel De Graaf <dgdegra@tycho.nsa.gov>
date:        Sun Dec 18 14:33:19 2011 +0000
    
    xsm: add remote_remap permission
    
    The mmu_update hypercall can be used to manipulate the page tables of
    a remote domain. Add a check for this in the XSM hook in addition to
    the existing check on mapping pages of a remote domain.
    
    Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
    
    
changeset:   24421:31f09a4c5772
user:        Daniel De Graaf <dgdegra@tycho.nsa.gov>
date:        Sun Dec 18 14:32:49 2011 +0000
    
    xsm: only log dummy override if not setting up dummy_xsm_ops
    
    The log messages from dummy overrides appear on every boot with XSM
    enabled, and are just noise when filling in the dummy_xsm_ops
    structure.
    
    Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
    
    
changeset:   24420:3a27ab1ba08c
user:        Daniel De Graaf <dgdegra@tycho.nsa.gov>
date:        Sun Dec 18 14:32:26 2011 +0000
    
    xsm/flask: report memory and IO ranges in audit messages
    
    This information is useful when determining the cause of an AVC denial
    caused by missing label on device memory or IRQs.
    
    Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
    
    
changeset:   24419:a854e1660c47
user:        Daniel De Graaf <dgdegra@tycho.nsa.gov>
date:        Sun Dec 18 14:32:06 2011 +0000
    
    xsm/flask: Add missing unlock on error path
    
    Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
    
    
changeset:   24418:a4bff36780a3
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Fri Dec 16 18:46:27 2011 +0000
    
    Linux/xencommons: Use oxenstored by default when available
    
    oxenstored is an ocaml implementation of the xenstore daemon. It is faster,
    more scalable and more reliable than the C xenstored.
    
    In particular the transaction model in oxenstored does not involve taking a
    complete copy of the database and aborting on any (even non-conflicting) other
    change.
    
    There is a paper on the design and implementation of oxenstored at
    http://gazagnaire.org/pub/GH09.pdf which includes a performance evaluation and
    comparison with the C daemon etc.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
========================================
commit 54e24021005458ad0a361c1d83011b751726a94b
Author: Ian Jackson <ian.jackson@eu.citrix.com>
Date:   Thu Dec 8 16:38:06 2011 +0000

    qemu_get_timer: Provide a comment about the behaviour on ts==NULL
    
    Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Dec 18 18:12:29 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 18 Dec 2011 18: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.xensource.com>)
	id 1RcLDR-0004BH-83; Sun, 18 Dec 2011 18:12:05 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RcLDP-0004BC-II
	for xen-devel@lists.xensource.com; Sun, 18 Dec 2011 18:12:03 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1324231917!6025844!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzAzNw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2063 invoked from network); 18 Dec 2011 18:11:57 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Dec 2011 18:11:57 -0000
X-IronPort-AV: E=Sophos;i="4.71,372,1320624000"; 
   d="scan'208";a="9540964"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Dec 2011 18:11:57 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sun, 18 Dec 2011 18:11:57 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RcLDI-0006QY-Ls;
	Sun, 18 Dec 2011 18:11:56 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RcLDI-0005C9-FN;
	Sun, 18 Dec 2011 18:11:56 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10531-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 18 Dec 2011 18:11:56 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10531: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10531 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10531/

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. 10528
 test-amd64-amd64-xl-win7-amd64  7 windows-install         fail REGR. vs. 10528

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-amd64-xl-sedf-pin 12 guest-saverestore.2       fail REGR. vs. 10528
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass

version targeted for testing:
 xen                  e3daa5b58464
baseline version:
 xen                  a4bff36780a3

------------------------------------------------------------
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>
  Keir Fraser <keir@xen.org>
  Liu, Jinsong <jinsong.liu@intel.com>
  Paul Durrant <paul.durrant@citrix.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   24430:e3daa5b58464
tag:         tip
user:        Paul Durrant <paul.durrant@citrix.com>
date:        Sun Dec 18 14:40:39 2011 +0000
    
    hvmloader: Re-name xenstore key used to save VM generation ID buffer address.
    
    Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
    
    
changeset:   24429:9587ccc2ae31
user:        Liu, Jinsong <jinsong.liu@intel.com>
date:        Sun Dec 18 14:40:00 2011 +0000
    
    X86-MCE: fix a bug of xen-mceinj tool
    
    Fix a bug of xen-mceinj tool which used to test mce by software way.
    
    Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24428:5b4b7e565ab8
user:        Paul Durrant <paul.durrant@citrix.com>
date:        Sun Dec 18 14:39:14 2011 +0000
    
    Fix grant_table v2 status mapping.
    
    Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24427:931bf1105730
user:        Paul Durrant <paul.durrant@citrix.com>
date:        Sun Dec 18 14:38:32 2011 +0000
    
    Allow VMs to query their own grant table version.
    
    Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24426:45e4b947873e
user:        Daniel De Graaf <dgdegra@tycho.nsa.gov>
date:        Sun Dec 18 14:35:03 2011 +0000
    
    xl.pod.1: improve documentation of FLASK commands
    
    Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
    
    
changeset:   24425:053a44894279
user:        Daniel De Graaf <dgdegra@tycho.nsa.gov>
date:        Sun Dec 18 14:34:42 2011 +0000
    
    xsm: add checks on PCI configuration access
    
    PCI configuration access is allowed to any privileged domain
    regardless of I/O port access restrictions; add XSM hooks for these
    accesses.
    
    Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
    
    
changeset:   24424:9ba6ddcd02c4
user:        Daniel De Graaf <dgdegra@tycho.nsa.gov>
date:        Sun Dec 18 14:34:12 2011 +0000
    
    xsm: fix up dummy ops
    
    Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
    
    
changeset:   24423:069c08b7de46
user:        Daniel De Graaf <dgdegra@tycho.nsa.gov>
date:        Sun Dec 18 14:33:48 2011 +0000
    
    xsm: Add missing access checks
    
    Actions requiring IS_PRIV should also require some XSM access control
    in order for XSM to be useful in confining multiple privileged
    domains. Add XSM hooks for new hypercalls and sub-commands that are
    under IS_PRIV but not currently under any access checks.
    
    Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
    
    
changeset:   24422:5ce5aca98404
user:        Daniel De Graaf <dgdegra@tycho.nsa.gov>
date:        Sun Dec 18 14:33:19 2011 +0000
    
    xsm: add remote_remap permission
    
    The mmu_update hypercall can be used to manipulate the page tables of
    a remote domain. Add a check for this in the XSM hook in addition to
    the existing check on mapping pages of a remote domain.
    
    Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
    
    
changeset:   24421:31f09a4c5772
user:        Daniel De Graaf <dgdegra@tycho.nsa.gov>
date:        Sun Dec 18 14:32:49 2011 +0000
    
    xsm: only log dummy override if not setting up dummy_xsm_ops
    
    The log messages from dummy overrides appear on every boot with XSM
    enabled, and are just noise when filling in the dummy_xsm_ops
    structure.
    
    Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
    
    
changeset:   24420:3a27ab1ba08c
user:        Daniel De Graaf <dgdegra@tycho.nsa.gov>
date:        Sun Dec 18 14:32:26 2011 +0000
    
    xsm/flask: report memory and IO ranges in audit messages
    
    This information is useful when determining the cause of an AVC denial
    caused by missing label on device memory or IRQs.
    
    Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
    
    
changeset:   24419:a854e1660c47
user:        Daniel De Graaf <dgdegra@tycho.nsa.gov>
date:        Sun Dec 18 14:32:06 2011 +0000
    
    xsm/flask: Add missing unlock on error path
    
    Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
    
    
changeset:   24418:a4bff36780a3
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Fri Dec 16 18:46:27 2011 +0000
    
    Linux/xencommons: Use oxenstored by default when available
    
    oxenstored is an ocaml implementation of the xenstore daemon. It is faster,
    more scalable and more reliable than the C xenstored.
    
    In particular the transaction model in oxenstored does not involve taking a
    complete copy of the database and aborting on any (even non-conflicting) other
    change.
    
    There is a paper on the design and implementation of oxenstored at
    http://gazagnaire.org/pub/GH09.pdf which includes a performance evaluation and
    comparison with the C daemon etc.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
========================================
commit 54e24021005458ad0a361c1d83011b751726a94b
Author: Ian Jackson <ian.jackson@eu.citrix.com>
Date:   Thu Dec 8 16:38:06 2011 +0000

    qemu_get_timer: Provide a comment about the behaviour on ts==NULL
    
    Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Dec 18 23:20:51 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 18 Dec 2011 23:20:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RcQ1X-00063m-J6; Sun, 18 Dec 2011 23:20:07 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RcQ1W-00063h-6Q
	for xen-devel@lists.xensource.com; Sun, 18 Dec 2011 23:20:06 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1324250399!7769855!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzA0MA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11664 invoked from network); 18 Dec 2011 23:19:59 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Dec 2011 23:19:59 -0000
X-IronPort-AV: E=Sophos;i="4.71,373,1320624000"; 
   d="scan'208";a="9542614"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Dec 2011 23:19:59 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sun, 18 Dec 2011 23:19:59 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RcQ1P-00086A-40;
	Sun, 18 Dec 2011 23:19:59 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RcQ1O-0001Ye-U2;
	Sun, 18 Dec 2011 23:19:59 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10532-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 18 Dec 2011 23:19:58 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.0-testing test] 10532: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10532 xen-4.0-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10532/

Regressions :-(

Tests which did not succeed and are blocking,including tests which could not be run:
 test-amd64-amd64-win          7 windows-install           fail REGR. vs. 10369

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  8 debian-fixup                fail never pass
 test-amd64-amd64-xl          15 guest-stop                   fail   never pass
 test-amd64-amd64-xl-sedf-pin  5 xen-boot                  fail REGR. vs. 10369
 test-amd64-i386-xl-multivcpu 15 guest-stop                   fail   never pass
 test-i386-i386-xl            15 guest-stop                   fail   never pass
 test-amd64-i386-xl           15 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64  8 guest-saverestore            fail never pass
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 10369
 test-amd64-i386-xl-win7-amd64  8 guest-saverestore            fail  never pass
 test-amd64-i386-xl-credit2   14 guest-localmigrate/x10   fail blocked in 10369
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-rhel6hvm-amd  7 redhat-install               fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-rhel6hvm-intel  7 redhat-install               fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-win-vcpus1  7 windows-install              fail  never pass
 test-i386-i386-xl-winxpsp3    7 windows-install              fail   never pass
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install          fail never pass
 test-amd64-amd64-xl-win       7 windows-install              fail   never pass
 test-i386-i386-xl-win         7 windows-install              fail   never pass

version targeted for testing:
 xen                  5d372b8bccef
baseline version:
 xen                  beabf510c4a1

------------------------------------------------------------
People who touched revisions under test:
  Jan Beulich <jbeulich@novell.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Paul Durrant <paul.durrant@citrix.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          fail    
 test-amd64-i386-xl                                           fail    
 test-i386-i386-xl                                            fail    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   21556:5d372b8bccef
tag:         tip
user:        Paul Durrant <paul.durrant@citrix.com>
date:        Sun Dec 18 14:51:04 2011 +0000
    
    Allow VMs to query their own grant table version.
    
    Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    xen-unstable changeset:   24427:931bf1105730
    xen-unstable date:        Sun Dec 18 14:38:32 2011 +0000
    
    
changeset:   21555:47bec9555bb4
user:        Jan Beulich <jbeulich@suse.com>
date:        Sun Dec 18 14:49:59 2011 +0000
    
    x86/AMD: use correct shift count when merging model and stepping
    
    ... for legacy errata matching.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    xen-unstable changeset:   24412:99caac2e35df
    xen-unstable date:        Thu Dec 15 14:28:45 2011 +0100
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   21554:beabf510c4a1
user:        Keir Fraser <keir@xen.org>
date:        Tue Dec 06 10:54:42 2011 +0000
    
    tools/libxc: Fix x86_32 build breakage in previous changeset.
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    xen-unstable changeset:   24345:491c3ebf1d37
    xen-unstable date:        Fri Dec 02 08:40:02 2011 -0800
    
    
    tools/x86_64: Fix cpuid() inline asm to not clobber stack's red zone
    
    Pushing stuff onto the stack on x86-64 when we do not specify
    -mno-red-zone is unsafe. Since the complicated asm is due to register
    pressure on i386, we simply implement an all-new simpler alternative
    for x86-64.
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    Acked-by: Jan Beulich <jbeulich@novell.com>
    xen-unstable changeset:   24344:72f4e4cb7440
    xen-unstable date:        Fri Dec 02 06:31:14 2011 -0800
    
    
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Dec 18 23:20:51 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 18 Dec 2011 23:20:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RcQ1X-00063m-J6; Sun, 18 Dec 2011 23:20:07 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RcQ1W-00063h-6Q
	for xen-devel@lists.xensource.com; Sun, 18 Dec 2011 23:20:06 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1324250399!7769855!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzA0MA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11664 invoked from network); 18 Dec 2011 23:19:59 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Dec 2011 23:19:59 -0000
X-IronPort-AV: E=Sophos;i="4.71,373,1320624000"; 
   d="scan'208";a="9542614"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Dec 2011 23:19:59 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sun, 18 Dec 2011 23:19:59 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RcQ1P-00086A-40;
	Sun, 18 Dec 2011 23:19:59 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RcQ1O-0001Ye-U2;
	Sun, 18 Dec 2011 23:19:59 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10532-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 18 Dec 2011 23:19:58 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.0-testing test] 10532: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10532 xen-4.0-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10532/

Regressions :-(

Tests which did not succeed and are blocking,including tests which could not be run:
 test-amd64-amd64-win          7 windows-install           fail REGR. vs. 10369

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  8 debian-fixup                fail never pass
 test-amd64-amd64-xl          15 guest-stop                   fail   never pass
 test-amd64-amd64-xl-sedf-pin  5 xen-boot                  fail REGR. vs. 10369
 test-amd64-i386-xl-multivcpu 15 guest-stop                   fail   never pass
 test-i386-i386-xl            15 guest-stop                   fail   never pass
 test-amd64-i386-xl           15 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64  8 guest-saverestore            fail never pass
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 10369
 test-amd64-i386-xl-win7-amd64  8 guest-saverestore            fail  never pass
 test-amd64-i386-xl-credit2   14 guest-localmigrate/x10   fail blocked in 10369
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-rhel6hvm-amd  7 redhat-install               fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-rhel6hvm-intel  7 redhat-install               fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-win-vcpus1  7 windows-install              fail  never pass
 test-i386-i386-xl-winxpsp3    7 windows-install              fail   never pass
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install          fail never pass
 test-amd64-amd64-xl-win       7 windows-install              fail   never pass
 test-i386-i386-xl-win         7 windows-install              fail   never pass

version targeted for testing:
 xen                  5d372b8bccef
baseline version:
 xen                  beabf510c4a1

------------------------------------------------------------
People who touched revisions under test:
  Jan Beulich <jbeulich@novell.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Paul Durrant <paul.durrant@citrix.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          fail    
 test-amd64-i386-xl                                           fail    
 test-i386-i386-xl                                            fail    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   21556:5d372b8bccef
tag:         tip
user:        Paul Durrant <paul.durrant@citrix.com>
date:        Sun Dec 18 14:51:04 2011 +0000
    
    Allow VMs to query their own grant table version.
    
    Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    xen-unstable changeset:   24427:931bf1105730
    xen-unstable date:        Sun Dec 18 14:38:32 2011 +0000
    
    
changeset:   21555:47bec9555bb4
user:        Jan Beulich <jbeulich@suse.com>
date:        Sun Dec 18 14:49:59 2011 +0000
    
    x86/AMD: use correct shift count when merging model and stepping
    
    ... for legacy errata matching.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    xen-unstable changeset:   24412:99caac2e35df
    xen-unstable date:        Thu Dec 15 14:28:45 2011 +0100
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   21554:beabf510c4a1
user:        Keir Fraser <keir@xen.org>
date:        Tue Dec 06 10:54:42 2011 +0000
    
    tools/libxc: Fix x86_32 build breakage in previous changeset.
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    xen-unstable changeset:   24345:491c3ebf1d37
    xen-unstable date:        Fri Dec 02 08:40:02 2011 -0800
    
    
    tools/x86_64: Fix cpuid() inline asm to not clobber stack's red zone
    
    Pushing stuff onto the stack on x86-64 when we do not specify
    -mno-red-zone is unsafe. Since the complicated asm is due to register
    pressure on i386, we simply implement an all-new simpler alternative
    for x86-64.
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    Acked-by: Jan Beulich <jbeulich@novell.com>
    xen-unstable changeset:   24344:72f4e4cb7440
    xen-unstable date:        Fri Dec 02 06:31:14 2011 -0800
    
    
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 01:27:30 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 01:27:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RcS03-0002UK-97; Mon, 19 Dec 2011 01:26:43 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RcS00-0002UF-QE
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 01:26:41 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1324257963!52937868!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzA0MA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18208 invoked from network); 19 Dec 2011 01:26:04 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Dec 2011 01:26:04 -0000
X-IronPort-AV: E=Sophos;i="4.71,373,1320624000"; 
   d="scan'208";a="9543518"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Dec 2011 01:26:38 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 19 Dec 2011 01:26:38 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RcRzy-0000ME-7O;
	Mon, 19 Dec 2011 01:26:38 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RcRzx-0002i6-Sp;
	Mon, 19 Dec 2011 01:26:37 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10533-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 19 Dec 2011 01:26:37 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing test] 10533: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10533 xen-4.1-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10533/

Regressions :-(

Tests which did not succeed and are blocking,including tests which could not be run:
 test-amd64-i386-xend-winxpsp3 14 guest-start.2            fail REGR. vs. 10501
 test-i386-i386-win            7 windows-install           fail REGR. vs. 10501

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  14dbd6be46c8
baseline version:
 xen                  bb365e21314d

------------------------------------------------------------
People who touched revisions under test:
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  George Dunlap <george.dunlap@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Keir Fraser <keir@xen.org>
  Liu, Jinsong <jinsong.liu@intel.com>
  Paul Durrant <paul.durrant@citrix.com>
  Roger Pau Monne <roger.pau@entel.upc.edu>
  Tim Deegan <tim@xen.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   23206:14dbd6be46c8
tag:         tip
user:        Roger Pau Monne <roger.pau@entel.upc.edu>
date:        Sun Dec 18 14:52:52 2011 +0000
    
    ipxe: fix compilation issues with some gcc versions
    
    Backported some changes from current ipxe, to fix a issue with some
    new versions of gcc that add -fPIC by default, and compilation fails
    with the following error:
    
    arch/i386/core/cpu.c: In function 'get_cpuinfo':
    arch/i386/include/bits/cpu.h:79:2: error: inconsistent operand
    constraints in an 'asm'
    arch/i386/include/bits/cpu.h:79:2: error: inconsistent operand
    constraints in an 'asm'
    arch/i386/include/bits/cpu.h:79:2: error: inconsistent operand
    constraints in an 'asm'
    arch/i386/include/bits/cpu.h:79:2: error: inconsistent operand
    constraints in an 'asm'
    
    Two patches from ipxe git have been added. The problem is reproducible
    with at least this version of gcc:
    
    Using built-in specs.
    COLLECT_GCC=gcc
    COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-alpine-linux-uclibc/4.6.2/lto-wrapper
    Target: x86_64-alpine-linux-uclibc
    Configured with:
    /home/buildozer/aports/main/gcc/src/gcc-4.6.2/configure --prefix=/usr
    --mandir=/usr/share/man --infodir=/usr/share/info
    --build=x86_64-alpine-linux-uclibc --host=x86_64-alpine-linux-uclibc
    --target=x86_64-alpine-linux-uclibc --with-pkgversion='Alpine
    4.6.2-r1' --disable-altivec --disable-checking --disable-fixed-point
    --disable-libssp --disable-libstdcxx-pch --disable-multilib
    --disable-nls --disable-werror --enable-__cxa_atexit --enable-cld
    --enable-esp --enable-cloog-backend
    --enable-languages=c,c++,objc,java,go --enable-shared
    --enable-target-optspace --enable-tls --enable-threads
    --with-dynamic-linker=ld64-uClibc.so.0.9.32
    --with-dynamic-linker-prefix=/lib --with-system-zlib
    --without-system-libunwind
    Thread model: posix
    gcc version 4.6.2 (Alpine 4.6.2-r1)
    
    Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   23205:e2af3c4e4c1d
user:        Liu, Jinsong <jinsong.liu@intel.com>
date:        Sun Dec 18 14:48:28 2011 +0000
    
    X86-MCE: fix a bug of xen-mceinj tool
    
    Fix a bug of xen-mceinj tool which used to test mce by software way.
    
    Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
    Committed-by: Keir Fraser <keir@xen.org>
    xen-unstable changeset:   24429:9587ccc2ae31
    xen-unstable date:        Sun Dec 18 14:40:00 2011 +0000
    
    
changeset:   23204:6ccf1820fb94
user:        Paul Durrant <paul.durrant@citrix.com>
date:        Sun Dec 18 14:47:23 2011 +0000
    
    Allow VMs to query their own grant table version.
    
    Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    xen-unstable changeset:   24427:931bf1105730
    xen-unstable date:        Sun Dec 18 14:38:32 2011 +0000
    
    
changeset:   23203:c62738ea1bb4
user:        Jan Beulich <jbeulich@suse.com>
date:        Sun Dec 18 14:45:44 2011 +0000
    
    x86/AMD: use correct shift count when merging model and stepping
    
    ... for legacy errata matching.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    xen-unstable changeset:   24412:99caac2e35df
    xen-unstable date:        Thu Dec 15 14:28:45 2011 +0100
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   23202:bb365e21314d
user:        Tim Deegan <tim@xen.org>
date:        Thu Dec 15 11:20:19 2011 +0000
    
    x86/mm/p2m: fix pod locking
    
    The path p2m-lookup -> p2m-pt->get_entry -> 1GB PoD superpage ->
    pod_demand_populate ends in the pod code performing a p2m_set_entry with
    no locks held (in order to split the 1GB superpage into 512 2MB ones)
    
    Further, it calls p2m_unlock after that, which will break the spinlock.
    
    This patch attempts to fix that.
    
    Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
    Acked-by: George Dunlap <george.dunlap@eu.citrix.com>
    Acked-by: Tim Deegan <tim@xen.org>
    xen-unstable changeset:   24189:7da681c490e0
    xen-unstable date:        Thu Nov 24 15:20:57 2011 +0000
    
    
========================================
commit 3981d218912e186cb4205ee6732f446c177a36a2
Author: Jean Guyader <jean.guyader@eu.citrix.com>
Date:   Tue Nov 22 18:49:15 2011 +0000

    qemu-xen: Don't redefine libpci (3.1.7) defines.
    
    These values are already defined by the libpci heders in the version
    3.1.7.
    
    PCI_STATUS_66MHZ
    PCI_STATUS_RESERVED2
    PCI_STATUS_FAST_BACK
    PCI_MSIX_TABSIZE
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    (cherry picked from commit 174d92a73a5d5e67c49501383a519021b72a2468)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 01:27:30 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 01:27:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RcS03-0002UK-97; Mon, 19 Dec 2011 01:26:43 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RcS00-0002UF-QE
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 01:26:41 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1324257963!52937868!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzA0MA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18208 invoked from network); 19 Dec 2011 01:26:04 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Dec 2011 01:26:04 -0000
X-IronPort-AV: E=Sophos;i="4.71,373,1320624000"; 
   d="scan'208";a="9543518"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Dec 2011 01:26:38 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 19 Dec 2011 01:26:38 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RcRzy-0000ME-7O;
	Mon, 19 Dec 2011 01:26:38 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RcRzx-0002i6-Sp;
	Mon, 19 Dec 2011 01:26:37 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10533-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 19 Dec 2011 01:26:37 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing test] 10533: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10533 xen-4.1-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10533/

Regressions :-(

Tests which did not succeed and are blocking,including tests which could not be run:
 test-amd64-i386-xend-winxpsp3 14 guest-start.2            fail REGR. vs. 10501
 test-i386-i386-win            7 windows-install           fail REGR. vs. 10501

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  14dbd6be46c8
baseline version:
 xen                  bb365e21314d

------------------------------------------------------------
People who touched revisions under test:
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  George Dunlap <george.dunlap@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Keir Fraser <keir@xen.org>
  Liu, Jinsong <jinsong.liu@intel.com>
  Paul Durrant <paul.durrant@citrix.com>
  Roger Pau Monne <roger.pau@entel.upc.edu>
  Tim Deegan <tim@xen.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   23206:14dbd6be46c8
tag:         tip
user:        Roger Pau Monne <roger.pau@entel.upc.edu>
date:        Sun Dec 18 14:52:52 2011 +0000
    
    ipxe: fix compilation issues with some gcc versions
    
    Backported some changes from current ipxe, to fix a issue with some
    new versions of gcc that add -fPIC by default, and compilation fails
    with the following error:
    
    arch/i386/core/cpu.c: In function 'get_cpuinfo':
    arch/i386/include/bits/cpu.h:79:2: error: inconsistent operand
    constraints in an 'asm'
    arch/i386/include/bits/cpu.h:79:2: error: inconsistent operand
    constraints in an 'asm'
    arch/i386/include/bits/cpu.h:79:2: error: inconsistent operand
    constraints in an 'asm'
    arch/i386/include/bits/cpu.h:79:2: error: inconsistent operand
    constraints in an 'asm'
    
    Two patches from ipxe git have been added. The problem is reproducible
    with at least this version of gcc:
    
    Using built-in specs.
    COLLECT_GCC=gcc
    COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-alpine-linux-uclibc/4.6.2/lto-wrapper
    Target: x86_64-alpine-linux-uclibc
    Configured with:
    /home/buildozer/aports/main/gcc/src/gcc-4.6.2/configure --prefix=/usr
    --mandir=/usr/share/man --infodir=/usr/share/info
    --build=x86_64-alpine-linux-uclibc --host=x86_64-alpine-linux-uclibc
    --target=x86_64-alpine-linux-uclibc --with-pkgversion='Alpine
    4.6.2-r1' --disable-altivec --disable-checking --disable-fixed-point
    --disable-libssp --disable-libstdcxx-pch --disable-multilib
    --disable-nls --disable-werror --enable-__cxa_atexit --enable-cld
    --enable-esp --enable-cloog-backend
    --enable-languages=c,c++,objc,java,go --enable-shared
    --enable-target-optspace --enable-tls --enable-threads
    --with-dynamic-linker=ld64-uClibc.so.0.9.32
    --with-dynamic-linker-prefix=/lib --with-system-zlib
    --without-system-libunwind
    Thread model: posix
    gcc version 4.6.2 (Alpine 4.6.2-r1)
    
    Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   23205:e2af3c4e4c1d
user:        Liu, Jinsong <jinsong.liu@intel.com>
date:        Sun Dec 18 14:48:28 2011 +0000
    
    X86-MCE: fix a bug of xen-mceinj tool
    
    Fix a bug of xen-mceinj tool which used to test mce by software way.
    
    Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
    Committed-by: Keir Fraser <keir@xen.org>
    xen-unstable changeset:   24429:9587ccc2ae31
    xen-unstable date:        Sun Dec 18 14:40:00 2011 +0000
    
    
changeset:   23204:6ccf1820fb94
user:        Paul Durrant <paul.durrant@citrix.com>
date:        Sun Dec 18 14:47:23 2011 +0000
    
    Allow VMs to query their own grant table version.
    
    Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    xen-unstable changeset:   24427:931bf1105730
    xen-unstable date:        Sun Dec 18 14:38:32 2011 +0000
    
    
changeset:   23203:c62738ea1bb4
user:        Jan Beulich <jbeulich@suse.com>
date:        Sun Dec 18 14:45:44 2011 +0000
    
    x86/AMD: use correct shift count when merging model and stepping
    
    ... for legacy errata matching.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    xen-unstable changeset:   24412:99caac2e35df
    xen-unstable date:        Thu Dec 15 14:28:45 2011 +0100
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   23202:bb365e21314d
user:        Tim Deegan <tim@xen.org>
date:        Thu Dec 15 11:20:19 2011 +0000
    
    x86/mm/p2m: fix pod locking
    
    The path p2m-lookup -> p2m-pt->get_entry -> 1GB PoD superpage ->
    pod_demand_populate ends in the pod code performing a p2m_set_entry with
    no locks held (in order to split the 1GB superpage into 512 2MB ones)
    
    Further, it calls p2m_unlock after that, which will break the spinlock.
    
    This patch attempts to fix that.
    
    Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
    Acked-by: George Dunlap <george.dunlap@eu.citrix.com>
    Acked-by: Tim Deegan <tim@xen.org>
    xen-unstable changeset:   24189:7da681c490e0
    xen-unstable date:        Thu Nov 24 15:20:57 2011 +0000
    
    
========================================
commit 3981d218912e186cb4205ee6732f446c177a36a2
Author: Jean Guyader <jean.guyader@eu.citrix.com>
Date:   Tue Nov 22 18:49:15 2011 +0000

    qemu-xen: Don't redefine libpci (3.1.7) defines.
    
    These values are already defined by the libpci heders in the version
    3.1.7.
    
    PCI_STATUS_66MHZ
    PCI_STATUS_RESERVED2
    PCI_STATUS_FAST_BACK
    PCI_MSIX_TABSIZE
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    (cherry picked from commit 174d92a73a5d5e67c49501383a519021b72a2468)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 02:47:04 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 02:47:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RcTF2-0003H0-IT; Mon, 19 Dec 2011 02:46:16 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zhourj@UFL.EDU>) id 1RcTF1-0003Gs-EU
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 02:46:15 +0000
X-Env-Sender: zhourj@UFL.EDU
X-Msg-Ref: server-3.tower-27.messagelabs.com!1324262727!49517275!1
X-Originating-IP: [128.227.74.71]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAxMjguMjI3Ljc0LjcxID0+IDYzNDgz\n,sa_preprocessor: 
	QmFkIElQOiAxMjguMjI3Ljc0LjcxID0+IDYzNDgz\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28196 invoked from network); 19 Dec 2011 02:45:28 -0000
Received: from smtp04.osg.ufl.edu (HELO smtp.ufl.edu) (128.227.74.71)
	by server-3.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Dec 2011 02:45:28 -0000
Received: from vpn-158.acis.ufl.edu (vpn-158.acis.ufl.edu [10.228.144.158])
	(authenticated bits=0)
	by smtp.ufl.edu (8.14.0/8.14.0/3.0.0) with ESMTP id pBJ2kBif015260
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT)
	for <xen-devel@lists.xensource.com>; Sun, 18 Dec 2011 21:46:11 -0500
From: ruijin zhou <zhourj@UFL.EDU>
Date: Sun, 18 Dec 2011 21:46:10 -0500
Message-Id: <D14C52F5-9E35-43F1-9D0E-10336DB51BBD@UFL.EDU>
To: xen-devel@lists.xensource.com
Mime-Version: 1.0 (Apple Message framework v1251.1)
X-Mailer: Apple Mail (2.1251.1)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.5.7110, 1.0.211,
	0.0.0000
	definitions=2011-12-19_01:2011-12-19, 2011-12-19,
	1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0
	ipscore=0 suspectscore=1
	phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0
	reason=mlx
	engine=6.0.2-1012030000 definitions=main-1112180359
X-Spam-Level: *
X-UFL-Spam-Level: *
Subject: [Xen-devel] CrossPoolMigration
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi, Guys,

I recently found the following links about cross-pool migration:

http://wiki.xen.org/wiki/CrossPoolMigration

http://wiki.xen.org/wiki/CrossPoolMigrationv2

I am interested in the research topic of live storage migration. And, I want to build something on Xen. 

However, in recent Xen release I cannot find any code about live storage Migration. I found the above links, which have a 'to do list'. It seems that it just started.

Does anyone know when will we have the code for storage migration?

Thank you very much.

Best,
Ruijin
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 02:47:04 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 02:47:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RcTF2-0003H0-IT; Mon, 19 Dec 2011 02:46:16 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zhourj@UFL.EDU>) id 1RcTF1-0003Gs-EU
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 02:46:15 +0000
X-Env-Sender: zhourj@UFL.EDU
X-Msg-Ref: server-3.tower-27.messagelabs.com!1324262727!49517275!1
X-Originating-IP: [128.227.74.71]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAxMjguMjI3Ljc0LjcxID0+IDYzNDgz\n,sa_preprocessor: 
	QmFkIElQOiAxMjguMjI3Ljc0LjcxID0+IDYzNDgz\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28196 invoked from network); 19 Dec 2011 02:45:28 -0000
Received: from smtp04.osg.ufl.edu (HELO smtp.ufl.edu) (128.227.74.71)
	by server-3.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Dec 2011 02:45:28 -0000
Received: from vpn-158.acis.ufl.edu (vpn-158.acis.ufl.edu [10.228.144.158])
	(authenticated bits=0)
	by smtp.ufl.edu (8.14.0/8.14.0/3.0.0) with ESMTP id pBJ2kBif015260
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT)
	for <xen-devel@lists.xensource.com>; Sun, 18 Dec 2011 21:46:11 -0500
From: ruijin zhou <zhourj@UFL.EDU>
Date: Sun, 18 Dec 2011 21:46:10 -0500
Message-Id: <D14C52F5-9E35-43F1-9D0E-10336DB51BBD@UFL.EDU>
To: xen-devel@lists.xensource.com
Mime-Version: 1.0 (Apple Message framework v1251.1)
X-Mailer: Apple Mail (2.1251.1)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.5.7110, 1.0.211,
	0.0.0000
	definitions=2011-12-19_01:2011-12-19, 2011-12-19,
	1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0
	ipscore=0 suspectscore=1
	phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0
	reason=mlx
	engine=6.0.2-1012030000 definitions=main-1112180359
X-Spam-Level: *
X-UFL-Spam-Level: *
Subject: [Xen-devel] CrossPoolMigration
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi, Guys,

I recently found the following links about cross-pool migration:

http://wiki.xen.org/wiki/CrossPoolMigration

http://wiki.xen.org/wiki/CrossPoolMigrationv2

I am interested in the research topic of live storage migration. And, I want to build something on Xen. 

However, in recent Xen release I cannot find any code about live storage Migration. I found the above links, which have a 'to do list'. It seems that it just started.

Does anyone know when will we have the code for storage migration?

Thank you very much.

Best,
Ruijin
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 03:00:28 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 03:00:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RcTS7-0003SQ-TH; Mon, 19 Dec 2011 02:59:47 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RcTS5-0003Ry-VM
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 02:59:46 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1324263578!7235477!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzA0MA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15724 invoked from network); 19 Dec 2011 02:59:38 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Dec 2011 02:59:38 -0000
X-IronPort-AV: E=Sophos;i="4.71,374,1320624000"; 
   d="scan'208";a="9544320"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Dec 2011 02:59:37 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 19 Dec 2011 02:59:37 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RcTRx-0000s4-EH;
	Mon, 19 Dec 2011 02:59:37 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RcTRx-0008LC-84;
	Mon, 19 Dec 2011 02:59:37 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10534-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 19 Dec 2011 02:59:37 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10534: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10534 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10534/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass

version targeted for testing:
 xen                  e3daa5b58464
baseline version:
 xen                  a4bff36780a3

------------------------------------------------------------
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>
  Keir Fraser <keir@xen.org>
  Liu, Jinsong <jinsong.liu@intel.com>
  Paul Durrant <paul.durrant@citrix.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-unstable
+ revision=e3daa5b58464
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-unstable e3daa5b58464
+ branch=xen-unstable
+ revision=e3daa5b58464
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ : xen@xenbits.xensource.com
+ : xen@xenbits.xensource.com:git/linux-pvops
+ : master
+ : tested/2.6.39.x
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r e3daa5b58464 ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 12 changesets with 43 changes to 28 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 03:00:28 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 03:00:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RcTS7-0003SQ-TH; Mon, 19 Dec 2011 02:59:47 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RcTS5-0003Ry-VM
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 02:59:46 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1324263578!7235477!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzA0MA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15724 invoked from network); 19 Dec 2011 02:59:38 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Dec 2011 02:59:38 -0000
X-IronPort-AV: E=Sophos;i="4.71,374,1320624000"; 
   d="scan'208";a="9544320"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Dec 2011 02:59:37 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 19 Dec 2011 02:59:37 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RcTRx-0000s4-EH;
	Mon, 19 Dec 2011 02:59:37 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RcTRx-0008LC-84;
	Mon, 19 Dec 2011 02:59:37 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10534-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 19 Dec 2011 02:59:37 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10534: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10534 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10534/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass

version targeted for testing:
 xen                  e3daa5b58464
baseline version:
 xen                  a4bff36780a3

------------------------------------------------------------
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>
  Keir Fraser <keir@xen.org>
  Liu, Jinsong <jinsong.liu@intel.com>
  Paul Durrant <paul.durrant@citrix.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-unstable
+ revision=e3daa5b58464
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-unstable e3daa5b58464
+ branch=xen-unstable
+ revision=e3daa5b58464
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ : xen@xenbits.xensource.com
+ : xen@xenbits.xensource.com:git/linux-pvops
+ : master
+ : tested/2.6.39.x
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r e3daa5b58464 ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 12 changesets with 43 changes to 28 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 05:44:08 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 05: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.xensource.com>)
	id 1RcW0M-0005Hj-Hn; Mon, 19 Dec 2011 05:43:18 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <kevin.tian@intel.com>) id 1RcW0K-0005Hb-Pn
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 05:43:17 +0000
X-Env-Sender: kevin.tian@intel.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1324273389!7902869!1
X-Originating-IP: [134.134.136.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjQgPT4gMzE3NTg3\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26807 invoked from network); 19 Dec 2011 05:43:10 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-14.tower-21.messagelabs.com with SMTP;
	19 Dec 2011 05:43:10 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga102.jf.intel.com with ESMTP; 18 Dec 2011 21:43:08 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.67,352,1309762800"; d="scan'208";a="87960811"
Received: from pgsmsx602.gar.corp.intel.com ([10.221.43.81])
	by orsmga001.jf.intel.com with ESMTP; 18 Dec 2011 21:43:06 -0800
Received: from shsmsx602.ccr.corp.intel.com (10.239.4.104) by
	pgsmsx602.gar.corp.intel.com (10.221.43.81) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Mon, 19 Dec 2011 13:43:05 +0800
Received: from shsmsx502.ccr.corp.intel.com ([10.239.4.96]) by
	SHSMSX602.ccr.corp.intel.com ([10.239.4.104]) with mapi;
	Mon, 19 Dec 2011 13:43:02 +0800
From: "Tian, Kevin" <kevin.tian@intel.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, "Yu, Ke"
	<ke.yu@intel.com>, "linux-kernel@vger.kernel.org"
	<linux-kernel@vger.kernel.org>, "linux-acpi@vger.kernel.org"
	<linux-acpi@vger.kernel.org>, "lenb@kernel.org" <lenb@kernel.org>,
	"rjw@sisk.pl" <rjw@sisk.pl>
Date: Mon, 19 Dec 2011 13:43:01 +0800
Thread-Topic: [PATCH 1/8] ACPI: processor: export necessary interfaces
Thread-Index: Acy8Oo4bmV5Q5o5cT8KAf9OCCD0+AwB1Tntg
Message-ID: <625BA99ED14B2D499DC4E29D8138F1506E01AABC72@shsmsx502.ccr.corp.intel.com>
References: <1322673664-14642-1-git-send-email-konrad.wilk@oracle.com>
	<1322673664-14642-2-git-send-email-konrad.wilk@oracle.com>
	<20111216213345.GA9832@phenom.dumpdata.com>
In-Reply-To: <20111216213345.GA9832@phenom.dumpdata.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "jeremy@goop.org" <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>,
	"mike.mcclurg@citrix.com" <mike.mcclurg@citrix.com>,
	"stefan.bader@canonical.com" <stefan.bader@canonical.com>,
	"konrad@kernel.org" <konrad@kernel.org>,
	"liang.tang@oracle.com" <liang.tang@oracle.com>
Subject: Re: [Xen-devel] [PATCH 1/8] ACPI: processor: export necessary
	interfaces
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@oracle.com]
> Sent: Saturday, December 17, 2011 5:34 AM
> 
> On Wed, Nov 30, 2011 at 12:20:57PM -0500, Konrad Rzeszutek Wilk wrote:
> > From: Kevin Tian <kevin.tian@intel.com>
> >
> > This patch export some necessary functions which parse processor
> > power management information. The Xen ACPI processor driver uses them.
> 
> I was wondering if it could be done by moving a bunch of these
> functions in the processor_perflib.c, but there is a lot of code
> that would have to be moved. Way too much.
> 
> Perhaps another, and a nicer way would be to:
> 
>  1). Create a processor_driver_lib.c which would have the "generic" code
>  2). In the processor_driver just keep the essential notifications, andk
>      the hotplug code
>  3). The introduce the other user of the acpi_processor_[add|remove|notify]
>      calls as a seperate library?
> 
> Thoughts?

that's a cleaner approach in the long term view IMO, though it incurs more changes
into current code base. 

Thanks
Kevin

> >
> > Signed-off-by: Yu Ke <ke.yu@intel.com>
> > Signed-off-by: Tian Kevin <kevin.tian@intel.com>
> > Signed-off-by: Tang Liang <liang.tang@oracle.com>
> > Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > ---
> >  drivers/acpi/processor_driver.c  |   11 +++--------
> >  drivers/acpi/processor_perflib.c |    4 ++--
> >  include/acpi/processor.h         |   10 +++++++++-
> >  3 files changed, 14 insertions(+), 11 deletions(-)
> >
> > diff --git a/drivers/acpi/processor_driver.c b/drivers/acpi/processor_driver.c
> > index 9d7bc9f..211c078 100644
> > --- a/drivers/acpi/processor_driver.c
> > +++ b/drivers/acpi/processor_driver.c
> > @@ -79,9 +79,6 @@ MODULE_AUTHOR("Paul Diefenbaugh");
> >  MODULE_DESCRIPTION("ACPI Processor Driver");
> >  MODULE_LICENSE("GPL");
> >
> > -static int acpi_processor_add(struct acpi_device *device);
> > -static int acpi_processor_remove(struct acpi_device *device, int type);
> > -static void acpi_processor_notify(struct acpi_device *device, u32 event);
> >  static acpi_status acpi_processor_hotadd_init(acpi_handle handle, int
> *p_cpu);
> >  static int acpi_processor_handle_eject(struct acpi_processor *pr);
> >
> > @@ -378,7 +375,7 @@ static int acpi_processor_get_info(struct acpi_device
> *device)
> >
> >  static DEFINE_PER_CPU(void *, processor_device_array);
> >
> > -static void acpi_processor_notify(struct acpi_device *device, u32 event)
> > +void acpi_processor_notify(struct acpi_device *device, u32 event)
> >  {
> >  	struct acpi_processor *pr = acpi_driver_data(device);
> >  	int saved;
> > @@ -442,7 +439,7 @@ static struct notifier_block acpi_cpu_notifier =
> >  	    .notifier_call = acpi_cpu_soft_notify,
> >  };
> >
> > -static int __cpuinit acpi_processor_add(struct acpi_device *device)
> > +int __cpuinit acpi_processor_add(struct acpi_device *device)
> >  {
> >  	struct acpi_processor *pr = NULL;
> >  	int result = 0;
> > @@ -545,7 +542,7 @@ err_free_cpumask:
> >  	return result;
> >  }
> >
> > -static int acpi_processor_remove(struct acpi_device *device, int type)
> > +int acpi_processor_remove(struct acpi_device *device, int type)
> >  {
> >  	struct acpi_processor *pr = NULL;
> >
> > @@ -758,7 +755,6 @@ static int acpi_processor_handle_eject(struct
> acpi_processor *pr)
> >  }
> >  #endif
> >
> > -static
> >  void acpi_processor_install_hotplug_notify(void)
> >  {
> >  #ifdef CONFIG_ACPI_HOTPLUG_CPU
> > @@ -771,7 +767,6 @@ void acpi_processor_install_hotplug_notify(void)
> >  	register_hotcpu_notifier(&acpi_cpu_notifier);
> >  }
> >
> > -static
> >  void acpi_processor_uninstall_hotplug_notify(void)
> >  {
> >  #ifdef CONFIG_ACPI_HOTPLUG_CPU
> > diff --git a/drivers/acpi/processor_perflib.c b/drivers/acpi/processor_perflib.c
> > index 85b3237..22c6195 100644
> > --- a/drivers/acpi/processor_perflib.c
> > +++ b/drivers/acpi/processor_perflib.c
> > @@ -386,7 +386,7 @@ static int
> acpi_processor_get_performance_states(struct acpi_processor *pr)
> >  	return result;
> >  }
> >
> > -static int acpi_processor_get_performance_info(struct acpi_processor *pr)
> > +int acpi_processor_get_performance_info(struct acpi_processor *pr)
> >  {
> >  	int result = 0;
> >  	acpi_status status = AE_OK;
> > @@ -492,7 +492,7 @@ int acpi_processor_notify_smm(struct module
> *calling_module)
> >
> >  EXPORT_SYMBOL(acpi_processor_notify_smm);
> >
> > -static int acpi_processor_get_psd(struct acpi_processor	*pr)
> > +int acpi_processor_get_psd(struct acpi_processor	*pr)
> >  {
> >  	int result = 0;
> >  	acpi_status status = AE_OK;
> > diff --git a/include/acpi/processor.h b/include/acpi/processor.h
> > index 610f6fb..12657bb 100644
> > --- a/include/acpi/processor.h
> > +++ b/include/acpi/processor.h
> > @@ -239,6 +239,12 @@ extern void
> acpi_processor_unregister_performance(struct
> >           if a _PPC object exists, rmmod is disallowed then */
> >  int acpi_processor_notify_smm(struct module *calling_module);
> >
> > +void acpi_processor_install_hotplug_notify(void);
> > +void acpi_processor_uninstall_hotplug_notify(void);
> > +
> > +int acpi_processor_add(struct acpi_device *device);
> > +int acpi_processor_remove(struct acpi_device *device, int type);
> > +void acpi_processor_notify(struct acpi_device *device, u32 event);
> >  /* for communication between multiple parts of the processor kernel
> module */
> >  DECLARE_PER_CPU(struct acpi_processor *, processors);
> >  extern struct acpi_processor_errata errata;
> > @@ -278,7 +284,9 @@ static inline void
> acpi_processor_ffh_cstate_enter(struct acpi_processor_cx
> >  void acpi_processor_ppc_init(void);
> >  void acpi_processor_ppc_exit(void);
> >  int acpi_processor_ppc_has_changed(struct acpi_processor *pr, int
> event_flag);
> > -extern int acpi_processor_get_bios_limit(int cpu, unsigned int *limit);
> > +int acpi_processor_get_performance_info(struct acpi_processor *pr);
> > +int acpi_processor_get_psd(struct acpi_processor *pr);
> > +int acpi_processor_get_bios_limit(int cpu, unsigned int *limit);
> >  #else
> >  static inline void acpi_processor_ppc_init(void)
> >  {
> > --
> > 1.7.7.3

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 05:44:08 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 05: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.xensource.com>)
	id 1RcW0M-0005Hj-Hn; Mon, 19 Dec 2011 05:43:18 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <kevin.tian@intel.com>) id 1RcW0K-0005Hb-Pn
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 05:43:17 +0000
X-Env-Sender: kevin.tian@intel.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1324273389!7902869!1
X-Originating-IP: [134.134.136.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjQgPT4gMzE3NTg3\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26807 invoked from network); 19 Dec 2011 05:43:10 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-14.tower-21.messagelabs.com with SMTP;
	19 Dec 2011 05:43:10 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga102.jf.intel.com with ESMTP; 18 Dec 2011 21:43:08 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.67,352,1309762800"; d="scan'208";a="87960811"
Received: from pgsmsx602.gar.corp.intel.com ([10.221.43.81])
	by orsmga001.jf.intel.com with ESMTP; 18 Dec 2011 21:43:06 -0800
Received: from shsmsx602.ccr.corp.intel.com (10.239.4.104) by
	pgsmsx602.gar.corp.intel.com (10.221.43.81) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Mon, 19 Dec 2011 13:43:05 +0800
Received: from shsmsx502.ccr.corp.intel.com ([10.239.4.96]) by
	SHSMSX602.ccr.corp.intel.com ([10.239.4.104]) with mapi;
	Mon, 19 Dec 2011 13:43:02 +0800
From: "Tian, Kevin" <kevin.tian@intel.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, "Yu, Ke"
	<ke.yu@intel.com>, "linux-kernel@vger.kernel.org"
	<linux-kernel@vger.kernel.org>, "linux-acpi@vger.kernel.org"
	<linux-acpi@vger.kernel.org>, "lenb@kernel.org" <lenb@kernel.org>,
	"rjw@sisk.pl" <rjw@sisk.pl>
Date: Mon, 19 Dec 2011 13:43:01 +0800
Thread-Topic: [PATCH 1/8] ACPI: processor: export necessary interfaces
Thread-Index: Acy8Oo4bmV5Q5o5cT8KAf9OCCD0+AwB1Tntg
Message-ID: <625BA99ED14B2D499DC4E29D8138F1506E01AABC72@shsmsx502.ccr.corp.intel.com>
References: <1322673664-14642-1-git-send-email-konrad.wilk@oracle.com>
	<1322673664-14642-2-git-send-email-konrad.wilk@oracle.com>
	<20111216213345.GA9832@phenom.dumpdata.com>
In-Reply-To: <20111216213345.GA9832@phenom.dumpdata.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "jeremy@goop.org" <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>,
	"mike.mcclurg@citrix.com" <mike.mcclurg@citrix.com>,
	"stefan.bader@canonical.com" <stefan.bader@canonical.com>,
	"konrad@kernel.org" <konrad@kernel.org>,
	"liang.tang@oracle.com" <liang.tang@oracle.com>
Subject: Re: [Xen-devel] [PATCH 1/8] ACPI: processor: export necessary
	interfaces
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@oracle.com]
> Sent: Saturday, December 17, 2011 5:34 AM
> 
> On Wed, Nov 30, 2011 at 12:20:57PM -0500, Konrad Rzeszutek Wilk wrote:
> > From: Kevin Tian <kevin.tian@intel.com>
> >
> > This patch export some necessary functions which parse processor
> > power management information. The Xen ACPI processor driver uses them.
> 
> I was wondering if it could be done by moving a bunch of these
> functions in the processor_perflib.c, but there is a lot of code
> that would have to be moved. Way too much.
> 
> Perhaps another, and a nicer way would be to:
> 
>  1). Create a processor_driver_lib.c which would have the "generic" code
>  2). In the processor_driver just keep the essential notifications, andk
>      the hotplug code
>  3). The introduce the other user of the acpi_processor_[add|remove|notify]
>      calls as a seperate library?
> 
> Thoughts?

that's a cleaner approach in the long term view IMO, though it incurs more changes
into current code base. 

Thanks
Kevin

> >
> > Signed-off-by: Yu Ke <ke.yu@intel.com>
> > Signed-off-by: Tian Kevin <kevin.tian@intel.com>
> > Signed-off-by: Tang Liang <liang.tang@oracle.com>
> > Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > ---
> >  drivers/acpi/processor_driver.c  |   11 +++--------
> >  drivers/acpi/processor_perflib.c |    4 ++--
> >  include/acpi/processor.h         |   10 +++++++++-
> >  3 files changed, 14 insertions(+), 11 deletions(-)
> >
> > diff --git a/drivers/acpi/processor_driver.c b/drivers/acpi/processor_driver.c
> > index 9d7bc9f..211c078 100644
> > --- a/drivers/acpi/processor_driver.c
> > +++ b/drivers/acpi/processor_driver.c
> > @@ -79,9 +79,6 @@ MODULE_AUTHOR("Paul Diefenbaugh");
> >  MODULE_DESCRIPTION("ACPI Processor Driver");
> >  MODULE_LICENSE("GPL");
> >
> > -static int acpi_processor_add(struct acpi_device *device);
> > -static int acpi_processor_remove(struct acpi_device *device, int type);
> > -static void acpi_processor_notify(struct acpi_device *device, u32 event);
> >  static acpi_status acpi_processor_hotadd_init(acpi_handle handle, int
> *p_cpu);
> >  static int acpi_processor_handle_eject(struct acpi_processor *pr);
> >
> > @@ -378,7 +375,7 @@ static int acpi_processor_get_info(struct acpi_device
> *device)
> >
> >  static DEFINE_PER_CPU(void *, processor_device_array);
> >
> > -static void acpi_processor_notify(struct acpi_device *device, u32 event)
> > +void acpi_processor_notify(struct acpi_device *device, u32 event)
> >  {
> >  	struct acpi_processor *pr = acpi_driver_data(device);
> >  	int saved;
> > @@ -442,7 +439,7 @@ static struct notifier_block acpi_cpu_notifier =
> >  	    .notifier_call = acpi_cpu_soft_notify,
> >  };
> >
> > -static int __cpuinit acpi_processor_add(struct acpi_device *device)
> > +int __cpuinit acpi_processor_add(struct acpi_device *device)
> >  {
> >  	struct acpi_processor *pr = NULL;
> >  	int result = 0;
> > @@ -545,7 +542,7 @@ err_free_cpumask:
> >  	return result;
> >  }
> >
> > -static int acpi_processor_remove(struct acpi_device *device, int type)
> > +int acpi_processor_remove(struct acpi_device *device, int type)
> >  {
> >  	struct acpi_processor *pr = NULL;
> >
> > @@ -758,7 +755,6 @@ static int acpi_processor_handle_eject(struct
> acpi_processor *pr)
> >  }
> >  #endif
> >
> > -static
> >  void acpi_processor_install_hotplug_notify(void)
> >  {
> >  #ifdef CONFIG_ACPI_HOTPLUG_CPU
> > @@ -771,7 +767,6 @@ void acpi_processor_install_hotplug_notify(void)
> >  	register_hotcpu_notifier(&acpi_cpu_notifier);
> >  }
> >
> > -static
> >  void acpi_processor_uninstall_hotplug_notify(void)
> >  {
> >  #ifdef CONFIG_ACPI_HOTPLUG_CPU
> > diff --git a/drivers/acpi/processor_perflib.c b/drivers/acpi/processor_perflib.c
> > index 85b3237..22c6195 100644
> > --- a/drivers/acpi/processor_perflib.c
> > +++ b/drivers/acpi/processor_perflib.c
> > @@ -386,7 +386,7 @@ static int
> acpi_processor_get_performance_states(struct acpi_processor *pr)
> >  	return result;
> >  }
> >
> > -static int acpi_processor_get_performance_info(struct acpi_processor *pr)
> > +int acpi_processor_get_performance_info(struct acpi_processor *pr)
> >  {
> >  	int result = 0;
> >  	acpi_status status = AE_OK;
> > @@ -492,7 +492,7 @@ int acpi_processor_notify_smm(struct module
> *calling_module)
> >
> >  EXPORT_SYMBOL(acpi_processor_notify_smm);
> >
> > -static int acpi_processor_get_psd(struct acpi_processor	*pr)
> > +int acpi_processor_get_psd(struct acpi_processor	*pr)
> >  {
> >  	int result = 0;
> >  	acpi_status status = AE_OK;
> > diff --git a/include/acpi/processor.h b/include/acpi/processor.h
> > index 610f6fb..12657bb 100644
> > --- a/include/acpi/processor.h
> > +++ b/include/acpi/processor.h
> > @@ -239,6 +239,12 @@ extern void
> acpi_processor_unregister_performance(struct
> >           if a _PPC object exists, rmmod is disallowed then */
> >  int acpi_processor_notify_smm(struct module *calling_module);
> >
> > +void acpi_processor_install_hotplug_notify(void);
> > +void acpi_processor_uninstall_hotplug_notify(void);
> > +
> > +int acpi_processor_add(struct acpi_device *device);
> > +int acpi_processor_remove(struct acpi_device *device, int type);
> > +void acpi_processor_notify(struct acpi_device *device, u32 event);
> >  /* for communication between multiple parts of the processor kernel
> module */
> >  DECLARE_PER_CPU(struct acpi_processor *, processors);
> >  extern struct acpi_processor_errata errata;
> > @@ -278,7 +284,9 @@ static inline void
> acpi_processor_ffh_cstate_enter(struct acpi_processor_cx
> >  void acpi_processor_ppc_init(void);
> >  void acpi_processor_ppc_exit(void);
> >  int acpi_processor_ppc_has_changed(struct acpi_processor *pr, int
> event_flag);
> > -extern int acpi_processor_get_bios_limit(int cpu, unsigned int *limit);
> > +int acpi_processor_get_performance_info(struct acpi_processor *pr);
> > +int acpi_processor_get_psd(struct acpi_processor *pr);
> > +int acpi_processor_get_bios_limit(int cpu, unsigned int *limit);
> >  #else
> >  static inline void acpi_processor_ppc_init(void)
> >  {
> > --
> > 1.7.7.3

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 05:49:46 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 05:49:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RcW60-0005QY-Go; Mon, 19 Dec 2011 05:49:08 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <kevin.tian@intel.com>) id 1RcW5y-0005QR-8S
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 05:49:06 +0000
X-Env-Sender: kevin.tian@intel.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1324273739!8567430!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDI5OTU0OA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8367 invoked from network); 19 Dec 2011 05:48:59 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-6.tower-21.messagelabs.com with SMTP;
	19 Dec 2011 05:48:59 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga102.fm.intel.com with ESMTP; 18 Dec 2011 21:48:59 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="103673926"
Received: from pgsmsx601.gar.corp.intel.com ([10.221.43.69])
	by fmsmga002.fm.intel.com with ESMTP; 18 Dec 2011 21:48:56 -0800
Received: from pgsmsx104.gar.corp.intel.com (10.221.44.91) by
	pgsmsx601.gar.corp.intel.com (10.221.43.69) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Mon, 19 Dec 2011 13:48:04 +0800
Received: from shsmsx602.ccr.corp.intel.com (10.239.4.104) by
	PGSMSX104.gar.corp.intel.com (10.221.44.91) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Mon, 19 Dec 2011 13:48:03 +0800
Received: from shsmsx502.ccr.corp.intel.com ([10.239.4.96]) by
	SHSMSX602.ccr.corp.intel.com ([10.239.4.104]) with mapi;
	Mon, 19 Dec 2011 13:48:02 +0800
From: "Tian, Kevin" <kevin.tian@intel.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, "Yu, Ke"
	<ke.yu@intel.com>, "linux-kernel@vger.kernel.org"
	<linux-kernel@vger.kernel.org>, "linux-acpi@vger.kernel.org"
	<linux-acpi@vger.kernel.org>, "lenb@kernel.org" <lenb@kernel.org>,
	"rjw@sisk.pl" <rjw@sisk.pl>
Date: Mon, 19 Dec 2011 13:48:01 +0800
Thread-Topic: [PATCH 3/8] ACPI: processor: add
	__acpi_processor_[un]register_driver helpers.
Thread-Index: Acy8Pr/Z5B3Lv9T5RuGe8oomEBprNwB0p2vQ
Message-ID: <625BA99ED14B2D499DC4E29D8138F1506E01AABC7A@shsmsx502.ccr.corp.intel.com>
References: <1322673664-14642-1-git-send-email-konrad.wilk@oracle.com>
	<1322673664-14642-4-git-send-email-konrad.wilk@oracle.com>
	<20111216220342.GC9832@phenom.dumpdata.com>
In-Reply-To: <20111216220342.GC9832@phenom.dumpdata.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "jeremy@goop.org" <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>,
	"mike.mcclurg@citrix.com" <mike.mcclurg@citrix.com>,
	"stefan.bader@canonical.com" <stefan.bader@canonical.com>,
	"konrad@kernel.org" <konrad@kernel.org>,
	"liang.tang@oracle.com" <liang.tang@oracle.com>
Subject: Re: [Xen-devel] [PATCH 3/8] ACPI: processor: add
 __acpi_processor_[un]register_driver helpers.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@oracle.com]
> Sent: Saturday, December 17, 2011 6:04 AM
> 
> On Wed, Nov 30, 2011 at 12:20:59PM -0500, Konrad Rzeszutek Wilk wrote:
> > From: Tang Liang <liang.tang@oracle.com>
> >
> > This patch implement __acpi_processor_[un]register_driver helper,
> > so we can registry override processor driver function. Specifically
> > the Xen processor driver.
> 
> Liang,
> 
> Is the reason we are doing this b/c we need to call acpi_bus_register_driver
> and inhibit the registration of 'acpi_processor_driver' ?
> 
> And the reason we don't want 'acpi_processor_driver' to run is b/c of what?
> If the cpuidle is disabled what is the harm of running the
> 'acpi_processor_driver'
> driver?

IIRC, the reason why we want a Xen specific driver is because current driver
is integrated with OS logic too tightly, e.g. the various checks on VCPU related
structures. Long time ago the 1st version in Xen was to use same driver, by
adding various tweaking lines inside which makes it completely messed. Then
later it's found that it's clearer to create a Xen specific wrapping driver, by 
invoking some exported functions from existing one.

Thanks
Kevin

> 
> >
> > By default the values are set to the native one.
> >
> > Signed-off-by: Tang Liang <liang.tang@oracle.com>
> > Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > ---
> >  drivers/acpi/processor_driver.c |   35
> +++++++++++++++++++++++++++++------
> >  include/acpi/processor.h        |    6 +++++-
> >  2 files changed, 34 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/acpi/processor_driver.c b/drivers/acpi/processor_driver.c
> > index 211c078..55f0b89 100644
> > --- a/drivers/acpi/processor_driver.c
> > +++ b/drivers/acpi/processor_driver.c
> > @@ -90,6 +90,11 @@ static const struct acpi_device_id
> processor_device_ids[] = {
> >  };
> >  MODULE_DEVICE_TABLE(acpi, processor_device_ids);
> >
> > +int (*__acpi_processor_register_driver)(void) =
> acpi_processor_register_driver;
> > +void (*__acpi_processor_unregister_driver)(void) \
> > +	= acpi_processor_unregister_driver;
> > +
> > +
> >  static struct acpi_driver acpi_processor_driver = {
> >  	.name = "processor",
> >  	.class = ACPI_PROCESSOR_CLASS,
> > @@ -779,6 +784,22 @@ void acpi_processor_uninstall_hotplug_notify(void)
> >  	unregister_hotcpu_notifier(&acpi_cpu_notifier);
> >  }
> >
> > +int acpi_processor_register_driver(void)
> > +{
> > +	int result = 0;
> > +
> > +	result = acpi_bus_register_driver(&acpi_processor_driver);
> > +	return result;
> > +}
> > +
> > +void acpi_processor_unregister_driver(void)
> > +{
> > +	acpi_bus_unregister_driver(&acpi_processor_driver);
> > +
> > +	cpuidle_unregister_driver(&acpi_idle_driver);
> > +
> > +	return;
> > +}
> >  /*
> >   * We keep the driver loaded even when ACPI is not running.
> >   * This is needed for the powernow-k8 driver, that works even without
> > @@ -794,9 +815,11 @@ static int __init acpi_processor_init(void)
> >
> >  	memset(&errata, 0, sizeof(errata));
> >
> > -	result = acpi_bus_register_driver(&acpi_processor_driver);
> > -	if (result < 0)
> > -		return result;
> > +	if (__acpi_processor_register_driver) {
> > +		result = __acpi_processor_register_driver();
> > +		if (result < 0)
> > +			return result;
> > +	}
> >
> >  	acpi_processor_install_hotplug_notify();
> >
> > @@ -809,6 +832,7 @@ static int __init acpi_processor_init(void)
> >  	return 0;
> >  }
> >
> > +
> >  static void __exit acpi_processor_exit(void)
> >  {
> >  	if (acpi_disabled)
> > @@ -820,9 +844,8 @@ static void __exit acpi_processor_exit(void)
> >
> >  	acpi_processor_uninstall_hotplug_notify();
> >
> > -	acpi_bus_unregister_driver(&acpi_processor_driver);
> > -
> > -	cpuidle_unregister_driver(&acpi_idle_driver);
> > +	if (__acpi_processor_unregister_driver)
> > +		__acpi_processor_unregister_driver();
> >
> >  	return;
> >  }
> > diff --git a/include/acpi/processor.h b/include/acpi/processor.h
> > index bd99fb6..969cbc9 100644
> > --- a/include/acpi/processor.h
> > +++ b/include/acpi/processor.h
> > @@ -225,6 +225,9 @@ struct acpi_processor_errata {
> >  	} piix4;
> >  };
> >
> > +extern int (*__acpi_processor_register_driver)(void);
> > +extern void (*__acpi_processor_unregister_driver)(void);
> > +
> >  extern int acpi_processor_preregister_performance(struct
> >  						  acpi_processor_performance
> >  						  __percpu *performance);
> > @@ -242,7 +245,8 @@ int acpi_processor_notify_smm(struct module
> *calling_module);
> >
> >  void acpi_processor_install_hotplug_notify(void);
> >  void acpi_processor_uninstall_hotplug_notify(void);
> > -
> > +int acpi_processor_register_driver(void);
> > +void acpi_processor_unregister_driver(void);
> >  int acpi_processor_add(struct acpi_device *device);
> >  int acpi_processor_remove(struct acpi_device *device, int type);
> >  void acpi_processor_notify(struct acpi_device *device, u32 event);
> > --
> > 1.7.7.3

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 05:49:46 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 05:49:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RcW60-0005QY-Go; Mon, 19 Dec 2011 05:49:08 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <kevin.tian@intel.com>) id 1RcW5y-0005QR-8S
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 05:49:06 +0000
X-Env-Sender: kevin.tian@intel.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1324273739!8567430!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDI5OTU0OA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8367 invoked from network); 19 Dec 2011 05:48:59 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-6.tower-21.messagelabs.com with SMTP;
	19 Dec 2011 05:48:59 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga102.fm.intel.com with ESMTP; 18 Dec 2011 21:48:59 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="103673926"
Received: from pgsmsx601.gar.corp.intel.com ([10.221.43.69])
	by fmsmga002.fm.intel.com with ESMTP; 18 Dec 2011 21:48:56 -0800
Received: from pgsmsx104.gar.corp.intel.com (10.221.44.91) by
	pgsmsx601.gar.corp.intel.com (10.221.43.69) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Mon, 19 Dec 2011 13:48:04 +0800
Received: from shsmsx602.ccr.corp.intel.com (10.239.4.104) by
	PGSMSX104.gar.corp.intel.com (10.221.44.91) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Mon, 19 Dec 2011 13:48:03 +0800
Received: from shsmsx502.ccr.corp.intel.com ([10.239.4.96]) by
	SHSMSX602.ccr.corp.intel.com ([10.239.4.104]) with mapi;
	Mon, 19 Dec 2011 13:48:02 +0800
From: "Tian, Kevin" <kevin.tian@intel.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, "Yu, Ke"
	<ke.yu@intel.com>, "linux-kernel@vger.kernel.org"
	<linux-kernel@vger.kernel.org>, "linux-acpi@vger.kernel.org"
	<linux-acpi@vger.kernel.org>, "lenb@kernel.org" <lenb@kernel.org>,
	"rjw@sisk.pl" <rjw@sisk.pl>
Date: Mon, 19 Dec 2011 13:48:01 +0800
Thread-Topic: [PATCH 3/8] ACPI: processor: add
	__acpi_processor_[un]register_driver helpers.
Thread-Index: Acy8Pr/Z5B3Lv9T5RuGe8oomEBprNwB0p2vQ
Message-ID: <625BA99ED14B2D499DC4E29D8138F1506E01AABC7A@shsmsx502.ccr.corp.intel.com>
References: <1322673664-14642-1-git-send-email-konrad.wilk@oracle.com>
	<1322673664-14642-4-git-send-email-konrad.wilk@oracle.com>
	<20111216220342.GC9832@phenom.dumpdata.com>
In-Reply-To: <20111216220342.GC9832@phenom.dumpdata.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "jeremy@goop.org" <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>,
	"mike.mcclurg@citrix.com" <mike.mcclurg@citrix.com>,
	"stefan.bader@canonical.com" <stefan.bader@canonical.com>,
	"konrad@kernel.org" <konrad@kernel.org>,
	"liang.tang@oracle.com" <liang.tang@oracle.com>
Subject: Re: [Xen-devel] [PATCH 3/8] ACPI: processor: add
 __acpi_processor_[un]register_driver helpers.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@oracle.com]
> Sent: Saturday, December 17, 2011 6:04 AM
> 
> On Wed, Nov 30, 2011 at 12:20:59PM -0500, Konrad Rzeszutek Wilk wrote:
> > From: Tang Liang <liang.tang@oracle.com>
> >
> > This patch implement __acpi_processor_[un]register_driver helper,
> > so we can registry override processor driver function. Specifically
> > the Xen processor driver.
> 
> Liang,
> 
> Is the reason we are doing this b/c we need to call acpi_bus_register_driver
> and inhibit the registration of 'acpi_processor_driver' ?
> 
> And the reason we don't want 'acpi_processor_driver' to run is b/c of what?
> If the cpuidle is disabled what is the harm of running the
> 'acpi_processor_driver'
> driver?

IIRC, the reason why we want a Xen specific driver is because current driver
is integrated with OS logic too tightly, e.g. the various checks on VCPU related
structures. Long time ago the 1st version in Xen was to use same driver, by
adding various tweaking lines inside which makes it completely messed. Then
later it's found that it's clearer to create a Xen specific wrapping driver, by 
invoking some exported functions from existing one.

Thanks
Kevin

> 
> >
> > By default the values are set to the native one.
> >
> > Signed-off-by: Tang Liang <liang.tang@oracle.com>
> > Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > ---
> >  drivers/acpi/processor_driver.c |   35
> +++++++++++++++++++++++++++++------
> >  include/acpi/processor.h        |    6 +++++-
> >  2 files changed, 34 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/acpi/processor_driver.c b/drivers/acpi/processor_driver.c
> > index 211c078..55f0b89 100644
> > --- a/drivers/acpi/processor_driver.c
> > +++ b/drivers/acpi/processor_driver.c
> > @@ -90,6 +90,11 @@ static const struct acpi_device_id
> processor_device_ids[] = {
> >  };
> >  MODULE_DEVICE_TABLE(acpi, processor_device_ids);
> >
> > +int (*__acpi_processor_register_driver)(void) =
> acpi_processor_register_driver;
> > +void (*__acpi_processor_unregister_driver)(void) \
> > +	= acpi_processor_unregister_driver;
> > +
> > +
> >  static struct acpi_driver acpi_processor_driver = {
> >  	.name = "processor",
> >  	.class = ACPI_PROCESSOR_CLASS,
> > @@ -779,6 +784,22 @@ void acpi_processor_uninstall_hotplug_notify(void)
> >  	unregister_hotcpu_notifier(&acpi_cpu_notifier);
> >  }
> >
> > +int acpi_processor_register_driver(void)
> > +{
> > +	int result = 0;
> > +
> > +	result = acpi_bus_register_driver(&acpi_processor_driver);
> > +	return result;
> > +}
> > +
> > +void acpi_processor_unregister_driver(void)
> > +{
> > +	acpi_bus_unregister_driver(&acpi_processor_driver);
> > +
> > +	cpuidle_unregister_driver(&acpi_idle_driver);
> > +
> > +	return;
> > +}
> >  /*
> >   * We keep the driver loaded even when ACPI is not running.
> >   * This is needed for the powernow-k8 driver, that works even without
> > @@ -794,9 +815,11 @@ static int __init acpi_processor_init(void)
> >
> >  	memset(&errata, 0, sizeof(errata));
> >
> > -	result = acpi_bus_register_driver(&acpi_processor_driver);
> > -	if (result < 0)
> > -		return result;
> > +	if (__acpi_processor_register_driver) {
> > +		result = __acpi_processor_register_driver();
> > +		if (result < 0)
> > +			return result;
> > +	}
> >
> >  	acpi_processor_install_hotplug_notify();
> >
> > @@ -809,6 +832,7 @@ static int __init acpi_processor_init(void)
> >  	return 0;
> >  }
> >
> > +
> >  static void __exit acpi_processor_exit(void)
> >  {
> >  	if (acpi_disabled)
> > @@ -820,9 +844,8 @@ static void __exit acpi_processor_exit(void)
> >
> >  	acpi_processor_uninstall_hotplug_notify();
> >
> > -	acpi_bus_unregister_driver(&acpi_processor_driver);
> > -
> > -	cpuidle_unregister_driver(&acpi_idle_driver);
> > +	if (__acpi_processor_unregister_driver)
> > +		__acpi_processor_unregister_driver();
> >
> >  	return;
> >  }
> > diff --git a/include/acpi/processor.h b/include/acpi/processor.h
> > index bd99fb6..969cbc9 100644
> > --- a/include/acpi/processor.h
> > +++ b/include/acpi/processor.h
> > @@ -225,6 +225,9 @@ struct acpi_processor_errata {
> >  	} piix4;
> >  };
> >
> > +extern int (*__acpi_processor_register_driver)(void);
> > +extern void (*__acpi_processor_unregister_driver)(void);
> > +
> >  extern int acpi_processor_preregister_performance(struct
> >  						  acpi_processor_performance
> >  						  __percpu *performance);
> > @@ -242,7 +245,8 @@ int acpi_processor_notify_smm(struct module
> *calling_module);
> >
> >  void acpi_processor_install_hotplug_notify(void);
> >  void acpi_processor_uninstall_hotplug_notify(void);
> > -
> > +int acpi_processor_register_driver(void);
> > +void acpi_processor_unregister_driver(void);
> >  int acpi_processor_add(struct acpi_device *device);
> >  int acpi_processor_remove(struct acpi_device *device, int type);
> >  void acpi_processor_notify(struct acpi_device *device, u32 event);
> > --
> > 1.7.7.3

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 06:53:28 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 06:53:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RcX5g-0005zn-8s; Mon, 19 Dec 2011 06:52:52 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RcX5f-0005zg-12
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 06:52:51 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1324277563!7794916!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzA0MA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8068 invoked from network); 19 Dec 2011 06:52:44 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Dec 2011 06:52:44 -0000
X-IronPort-AV: E=Sophos;i="4.71,374,1320624000"; 
   d="scan'208";a="9545461"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Dec 2011 06:52:42 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 19 Dec 2011 06:52:42 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RcX5W-0002CA-IJ;
	Mon, 19 Dec 2011 06:52:42 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RcX5W-0001IH-Gn;
	Mon, 19 Dec 2011 06:52:42 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10539-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 19 Dec 2011 06:52:42 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.0-testing test] 10539: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10539 xen-4.0-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10539/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  8 debian-fixup                fail never pass
 test-amd64-amd64-xl          15 guest-stop                   fail   never pass
 test-amd64-amd64-xl-sedf-pin 15 guest-stop                   fail   never pass
 test-amd64-i386-xl-multivcpu 15 guest-stop                   fail   never pass
 test-i386-i386-xl            15 guest-stop                   fail   never pass
 test-amd64-i386-xl           15 guest-stop                   fail   never pass
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 10369
 test-amd64-i386-xl-credit2    5 xen-boot                     fail   like 10369
 test-amd64-amd64-xl-win7-amd64  8 guest-saverestore            fail never pass
 test-amd64-i386-xl-win7-amd64  8 guest-saverestore            fail  never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-rhel6hvm-intel  7 redhat-install               fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-rhel6hvm-amd  7 redhat-install               fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-i386-i386-xl-winxpsp3    7 windows-install              fail   never pass
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1  7 windows-install              fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install          fail never pass
 test-amd64-amd64-xl-win       7 windows-install              fail   never pass
 test-i386-i386-xl-win         7 windows-install              fail   never pass

version targeted for testing:
 xen                  5d372b8bccef
baseline version:
 xen                  beabf510c4a1

------------------------------------------------------------
People who touched revisions under test:
  Jan Beulich <jbeulich@novell.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Paul Durrant <paul.durrant@citrix.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          fail    
 test-amd64-i386-xl                                           fail    
 test-i386-i386-xl                                            fail    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-4.0-testing
+ revision=5d372b8bccef
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-4.0-testing 5d372b8bccef
+ branch=xen-4.0-testing
+ revision=5d372b8bccef
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ : xen@xenbits.xensource.com
+ : xen@xenbits.xensource.com:git/linux-pvops
+ : master
+ : tested/2.6.39.x
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-4.0-testing.hg
+ hg push -r 5d372b8bccef ssh://xen@xenbits.xensource.com/HG/xen-4.0-testing.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-4.0-testing.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 2 changesets with 3 changes to 3 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 06:53:28 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 06:53:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RcX5g-0005zn-8s; Mon, 19 Dec 2011 06:52:52 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RcX5f-0005zg-12
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 06:52:51 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1324277563!7794916!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzA0MA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8068 invoked from network); 19 Dec 2011 06:52:44 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Dec 2011 06:52:44 -0000
X-IronPort-AV: E=Sophos;i="4.71,374,1320624000"; 
   d="scan'208";a="9545461"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Dec 2011 06:52:42 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 19 Dec 2011 06:52:42 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RcX5W-0002CA-IJ;
	Mon, 19 Dec 2011 06:52:42 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RcX5W-0001IH-Gn;
	Mon, 19 Dec 2011 06:52:42 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10539-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 19 Dec 2011 06:52:42 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.0-testing test] 10539: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10539 xen-4.0-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10539/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  8 debian-fixup                fail never pass
 test-amd64-amd64-xl          15 guest-stop                   fail   never pass
 test-amd64-amd64-xl-sedf-pin 15 guest-stop                   fail   never pass
 test-amd64-i386-xl-multivcpu 15 guest-stop                   fail   never pass
 test-i386-i386-xl            15 guest-stop                   fail   never pass
 test-amd64-i386-xl           15 guest-stop                   fail   never pass
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 10369
 test-amd64-i386-xl-credit2    5 xen-boot                     fail   like 10369
 test-amd64-amd64-xl-win7-amd64  8 guest-saverestore            fail never pass
 test-amd64-i386-xl-win7-amd64  8 guest-saverestore            fail  never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-rhel6hvm-intel  7 redhat-install               fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-rhel6hvm-amd  7 redhat-install               fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-i386-i386-xl-winxpsp3    7 windows-install              fail   never pass
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1  7 windows-install              fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install          fail never pass
 test-amd64-amd64-xl-win       7 windows-install              fail   never pass
 test-i386-i386-xl-win         7 windows-install              fail   never pass

version targeted for testing:
 xen                  5d372b8bccef
baseline version:
 xen                  beabf510c4a1

------------------------------------------------------------
People who touched revisions under test:
  Jan Beulich <jbeulich@novell.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Paul Durrant <paul.durrant@citrix.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          fail    
 test-amd64-i386-xl                                           fail    
 test-i386-i386-xl                                            fail    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-4.0-testing
+ revision=5d372b8bccef
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-4.0-testing 5d372b8bccef
+ branch=xen-4.0-testing
+ revision=5d372b8bccef
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ : xen@xenbits.xensource.com
+ : xen@xenbits.xensource.com:git/linux-pvops
+ : master
+ : tested/2.6.39.x
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-4.0-testing.hg
+ hg push -r 5d372b8bccef ssh://xen@xenbits.xensource.com/HG/xen-4.0-testing.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-4.0-testing.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 2 changesets with 3 changes to 3 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 07:53:08 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 07: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.xensource.com>)
	id 1RcY1S-0006YZ-Rh; Mon, 19 Dec 2011 07:52:34 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RcY1R-0006YU-1B
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 07:52:33 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1324281146!7777824!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21126 invoked from network); 19 Dec 2011 07:52:26 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-9.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 19 Dec 2011 07:52:26 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 19 Dec 2011 07:52:25 +0000
Message-Id: <4EEEFB440200007800068C54@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 19 Dec 2011 07:52:20 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "dbrace" <dab@hp.com>
References: <4EDFDF0D.2020104@hp.com>
	<4EE628D80200007800066F9E@nat28.tlf.novell.com>
	<4EE943BA.6010202@hp.com>
In-Reply-To: <4EE943BA.6010202@hp.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com,
	"scameron@beardog.cce.hp.com" <scameron@beardog.cce.hp.com>
Subject: Re: [Xen-devel] kmap_atomic issue with SLES11SP1 32bit XEN driver
 code
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 15.12.11 at 01:47, dbrace <dab@hp.com> wrote:
>> >... without knowing where you got physical_address from it's impossible
>>>to tell whether your problem is that under Xen physical and machine
>>>(sometimes called "bus") addresses being distinct (end hence you're
> ??possibly lacking a translation between the two).
> 
> 
> Is there a way to tell from the address is this is happening?

Not really - these are distinct address spaces, and hence generally
any address can be valid in both. Seeing the initial memory map(s)
one may be able to disambiguate a few regions, but that's only
those where the machine memory really represents MMIO of some
sort.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 07:53:08 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 07: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.xensource.com>)
	id 1RcY1S-0006YZ-Rh; Mon, 19 Dec 2011 07:52:34 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RcY1R-0006YU-1B
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 07:52:33 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1324281146!7777824!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21126 invoked from network); 19 Dec 2011 07:52:26 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-9.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 19 Dec 2011 07:52:26 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 19 Dec 2011 07:52:25 +0000
Message-Id: <4EEEFB440200007800068C54@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 19 Dec 2011 07:52:20 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "dbrace" <dab@hp.com>
References: <4EDFDF0D.2020104@hp.com>
	<4EE628D80200007800066F9E@nat28.tlf.novell.com>
	<4EE943BA.6010202@hp.com>
In-Reply-To: <4EE943BA.6010202@hp.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com,
	"scameron@beardog.cce.hp.com" <scameron@beardog.cce.hp.com>
Subject: Re: [Xen-devel] kmap_atomic issue with SLES11SP1 32bit XEN driver
 code
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 15.12.11 at 01:47, dbrace <dab@hp.com> wrote:
>> >... without knowing where you got physical_address from it's impossible
>>>to tell whether your problem is that under Xen physical and machine
>>>(sometimes called "bus") addresses being distinct (end hence you're
> ??possibly lacking a translation between the two).
> 
> 
> Is there a way to tell from the address is this is happening?

Not really - these are distinct address spaces, and hence generally
any address can be valid in both. Seeing the initial memory map(s)
one may be able to disambiguate a few regions, but that's only
those where the machine memory really represents MMIO of some
sort.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 08:22:51 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 08:22:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RcYUG-0007Gy-I9; Mon, 19 Dec 2011 08:22:20 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pasik@iki.fi>)
	id 1RcYUD-0007Gg-DT; Mon, 19 Dec 2011 08:22:17 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-11.tower-174.messagelabs.com!1324282930!6073935!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiAzNzcxODc=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14633 invoked from network); 19 Dec 2011 08:22:10 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-11.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 19 Dec 2011 08:22:10 -0000
X-Originating-Ip: [194.89.68.22]
Received: from ydin.reaktio.net (reaktio.net [194.89.68.22])
	by smtp.tele.fi (Postfix) with ESMTP id C45412274;
	Mon, 19 Dec 2011 10:22:08 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id ED96E20056; Mon, 19 Dec 2011 10:22:07 +0200 (EET)
Date: Mon, 19 Dec 2011 10:22:07 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: ruijin zhou <zhourj@UFL.EDU>
Message-ID: <20111219082207.GE12984@reaktio.net>
References: <D14C52F5-9E35-43F1-9D0E-10336DB51BBD@UFL.EDU>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <D14C52F5-9E35-43F1-9D0E-10336DB51BBD@UFL.EDU>
User-Agent: Mutt/1.5.18 (2008-05-17)
Cc: xen-devel@lists.xensource.com, xen-api@lists.xensource.com
Subject: Re: [Xen-devel] CrossPoolMigration
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Sun, Dec 18, 2011 at 09:46:10PM -0500, ruijin zhou wrote:
> Hi, Guys,
> 

Hello,

> I recently found the following links about cross-pool migration:
> 
> http://wiki.xen.org/wiki/CrossPoolMigration
> 
> http://wiki.xen.org/wiki/CrossPoolMigrationv2
> 
> I am interested in the research topic of live storage migration. And, I want to build something on Xen. 
> 
> However, in recent Xen release I cannot find any code about live storage Migration. I found the above links, which have a 'to do list'. It seems that it just started.
> 
> Does anyone know when will we have the code for storage migration?
> 
> Thank you very much.
> 

I added xen-api mailinglist to CC ..

-- Pasi


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 08:22:51 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 08:22:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RcYUG-0007Gy-I9; Mon, 19 Dec 2011 08:22:20 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pasik@iki.fi>)
	id 1RcYUD-0007Gg-DT; Mon, 19 Dec 2011 08:22:17 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-11.tower-174.messagelabs.com!1324282930!6073935!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiAzNzcxODc=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14633 invoked from network); 19 Dec 2011 08:22:10 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-11.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 19 Dec 2011 08:22:10 -0000
X-Originating-Ip: [194.89.68.22]
Received: from ydin.reaktio.net (reaktio.net [194.89.68.22])
	by smtp.tele.fi (Postfix) with ESMTP id C45412274;
	Mon, 19 Dec 2011 10:22:08 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id ED96E20056; Mon, 19 Dec 2011 10:22:07 +0200 (EET)
Date: Mon, 19 Dec 2011 10:22:07 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: ruijin zhou <zhourj@UFL.EDU>
Message-ID: <20111219082207.GE12984@reaktio.net>
References: <D14C52F5-9E35-43F1-9D0E-10336DB51BBD@UFL.EDU>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <D14C52F5-9E35-43F1-9D0E-10336DB51BBD@UFL.EDU>
User-Agent: Mutt/1.5.18 (2008-05-17)
Cc: xen-devel@lists.xensource.com, xen-api@lists.xensource.com
Subject: Re: [Xen-devel] CrossPoolMigration
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Sun, Dec 18, 2011 at 09:46:10PM -0500, ruijin zhou wrote:
> Hi, Guys,
> 

Hello,

> I recently found the following links about cross-pool migration:
> 
> http://wiki.xen.org/wiki/CrossPoolMigration
> 
> http://wiki.xen.org/wiki/CrossPoolMigrationv2
> 
> I am interested in the research topic of live storage migration. And, I want to build something on Xen. 
> 
> However, in recent Xen release I cannot find any code about live storage Migration. I found the above links, which have a 'to do list'. It seems that it just started.
> 
> Does anyone know when will we have the code for storage migration?
> 
> Thank you very much.
> 

I added xen-api mailinglist to CC ..

-- Pasi


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 08:25:17 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 08:25:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RcYWa-0007NY-16; Mon, 19 Dec 2011 08:24:44 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pankaj.kumarbiswas@citrix.com>) id 1RcYWX-0007N7-Sl
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 08:24:42 +0000
X-Env-Sender: pankaj.kumarbiswas@citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1324283071!7259650!1
X-Originating-IP: [203.166.19.134]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjAzLjE2Ni4xOS4xMzQgPT4gNDEwNTE=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32180 invoked from network); 19 Dec 2011 08:24:34 -0000
Received: from smtp.citrix.com.au (HELO SMTP.CITRIX.COM.AU) (203.166.19.134)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Dec 2011 08:24:34 -0000
X-IronPort-AV: E=Sophos;i="4.71,375,1320624000"; d="scan'208,217";a="9654754"
Received: from banpmailmx02.citrite.net ([10.103.128.74])
	by SYDPIPO01.CITRIX.COM.AU with ESMTP/TLS/RC4-MD5;
	19 Dec 2011 08:24:30 +0000
Received: from BANPMAILBOX01.citrite.net ([10.103.128.71]) by
	BANPMAILMX02.citrite.net ([10.103.128.74]) with mapi; Mon, 19 Dec 2011
	13:54:29 +0530
From: Pankaj Kumar Biswas <pankaj.kumarbiswas@citrix.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Mon, 19 Dec 2011 13:54:28 +0530
Thread-Topic: Re: vbd-unplug timeout issue
Thread-Index: Acy+J3MqZjM35/weQmq+g5zYuLirDA==
Message-ID: <64FB1554ABC9B44FAA773FBD6CB889C2F91230D411@BANPMAILBOX01.citrite.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Subject: Re: [Xen-devel] vbd-unplug timeout issue
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3399945208348102147=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============3399945208348102147==
Content-Language: en-US
Content-Type: multipart/alternative;
	boundary="_000_64FB1554ABC9B44FAA773FBD6CB889C2F91230D411BANPMAILBOX01_"

--_000_64FB1554ABC9B44FAA773FBD6CB889C2F91230D411BANPMAILBOX01_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


Hi Team,


While running "xe vbd-unplug" command against VBD which is used by VM, it s=
hould return an error. On XenServer 6.0, when I am doing it, I will get an =
error at 1st time, but when I do it again, it does not return error for 120=
0 seconds (20 minutes). I am getting timeout error after 1200 seconds.



The error message on console Is::



   The server failed to handle your request, due to an internal error.

   The given message may give details useful for debugging the problem.

   message: Watch.Timeout(1200.)





In logs:



[20111214T00:49:27.381Z|debug|iida-dl018|611167 unix-RPC||cli] Xapi_cli.exc=
eption_handler: Got exception DEVICE_DETACH_REJECTED: [ VBD; OpaqueRef:2d1d=
0de6-be4c-c214-cade-d8e11d0e2365; 16 Device in use; refusing to close ]


Dec 14 09:49:27 iida-dl018 xapi: [error|iida-dl018|611167 unix-RPC|VBD.unpl=
ug R:72e01c62a8be|xapi] Xapi_vbd.destroy_vbd got an error (frontend (domid=
=3D1 | kind=3Dvbd | devid=3D51712); backend (domid=3D0 | kind=3Dvbd | devid=
=3D51712)) 16 Device in use; refusing to close

Dec 14 10:09:42 iida-dl018 xapi: [error|iida-dl018|611175 unix-RPC|VBD.unpl=
ug R:88079c7cb782|xenops] watch: timeout while watching xenstore after 1200=
.000000 seconds



On XenServer 5.6 (Midnight Ride), I do not see this issue. Is there any cha=
nge in the xapi?? What is the possible cause of the failure??

Is any work-around for this ??


Thanks & Regards,
PANKAJ KUMAR BISWAS


--_000_64FB1554ABC9B44FAA773FBD6CB889C2F91230D411BANPMAILBOX01_
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=3DGenerator content=3D"Micros=
oft Word 14 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
	{font-family:Cambria;
	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;}
/* 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;}
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.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
span.PlainTextChar
	{mso-style-name:"Plain Text Char";
	mso-style-priority:99;
	mso-style-link:"Plain Text";
	font-family:"Calibri","sans-serif";}
.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=3DEN-US link=3Dblue vli=
nk=3Dpurple><div class=3DWordSection1><p class=3DMsoNormal><o:p>&nbsp;</o:p=
></p><p class=3DMsoNormal>Hi Team,<o:p></o:p></p><p class=3DMsoNormal><o:p>=
&nbsp;</o:p></p><p class=3DMsoPlainText>While running &quot;xe vbd-unplug&q=
uot; command against VBD which is used by VM, it should return an error. On=
 XenServer 6.0, when I am doing it, I will get an error at 1st time, but wh=
en I do it again, it does not return error for 1200 seconds (20 minutes). I=
 am getting timeout error after 1200 seconds.<o:p></o:p></p><p class=3DMsoP=
lainText><o:p>&nbsp;</o:p></p><p class=3DMsoPlainText>The error message on =
console Is::<o:p></o:p></p><p class=3DMsoPlainText><o:p>&nbsp;</o:p></p><p =
class=3DMsoPlainText>&nbsp;&nbsp; The server failed to handle your request,=
 due to an internal error.&nbsp; <o:p></o:p></p><p class=3DMsoPlainText>&nb=
sp;&nbsp;&nbsp;The given message may give details useful for debugging the =
problem.<o:p></o:p></p><p class=3DMsoPlainText>&nbsp;&nbsp; message: Watch.=
Timeout(1200.)<o:p></o:p></p><p class=3DMsoPlainText><o:p>&nbsp;</o:p></p><=
p class=3DMsoPlainText><o:p>&nbsp;</o:p></p><p class=3DMsoPlainText>In logs=
:<o:p></o:p></p><p class=3DMsoPlainText><o:p>&nbsp;</o:p></p><p class=3DMso=
PlainText>[20111214T00:49:27.381Z|debug|iida-dl018|611167 unix-RPC||cli] Xa=
pi_cli.exception_handler: Got exception <b>DEVICE_DETACH_REJECTED</b>: [ VB=
D; OpaqueRef:2d1d0de6-be4c-c214-cade-d8e11d0e2365; 16 Device in use; refusi=
ng to close ]<o:p></o:p></p><p class=3DMsoPlainText><o:p>&nbsp;</o:p></p><p=
 class=3DMsoNormal>Dec 14 09:49:27 iida-dl018 xapi: [error|iida-dl018|61116=
7 unix-RPC|VBD.unplug R:72e01c62a8be|xapi] Xapi_vbd.destroy_vbd got an erro=
r (frontend (domid=3D1 | kind=3Dvbd | devid=3D51712); backend (domid=3D0 | =
kind=3Dvbd | devid=3D51712)) 16 <b>Device in use</b>; <b>refusing to close<=
/b> <o:p></o:p></p><p class=3DMsoNormal><o:p>&nbsp;</o:p></p><p class=3DMso=
Normal>Dec 14 10:09:42 iida-dl018 xapi: [error|iida-dl018|611175 unix-RPC|V=
BD.unplug R:88079c7cb782|xenops] <b>watch: timeout while watching xenstore =
after 1200.000000 seconds<o:p></o:p></b></p><p class=3DMsoPlainText><o:p>&n=
bsp;</o:p></p><p class=3DMsoPlainText>On XenServer 5.6 (Midnight Ride), I d=
o not see this issue. Is there any change in the xapi?? What is the possibl=
e cause of the failure??<o:p></o:p></p><p class=3DMsoPlainText>Is any work-=
around for this ??<o:p></o:p></p><p class=3DMsoNormal><o:p>&nbsp;</o:p></p>=
<p class=3DMsoNormal><o:p>&nbsp;</o:p></p><p class=3DMsoNormal><b><span sty=
le=3D'font-family:"Cambria","serif"'>Thanks &amp; Regards,<o:p></o:p></span=
></b></p><p class=3DMsoNormal><b><span style=3D'font-family:"Cambria","seri=
f"'>PANKAJ KUMAR BISWAS<o:p></o:p></span></b></p><p class=3DMsoNormal><b><s=
pan style=3D'font-family:"Cambria","serif"'><o:p>&nbsp;</o:p></span></b></p=
></div></body></html>=

--_000_64FB1554ABC9B44FAA773FBD6CB889C2F91230D411BANPMAILBOX01_--


--===============3399945208348102147==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============3399945208348102147==--


From xen-devel-bounces@lists.xensource.com Mon Dec 19 08:25:17 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 08:25:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RcYWa-0007NY-16; Mon, 19 Dec 2011 08:24:44 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pankaj.kumarbiswas@citrix.com>) id 1RcYWX-0007N7-Sl
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 08:24:42 +0000
X-Env-Sender: pankaj.kumarbiswas@citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1324283071!7259650!1
X-Originating-IP: [203.166.19.134]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjAzLjE2Ni4xOS4xMzQgPT4gNDEwNTE=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32180 invoked from network); 19 Dec 2011 08:24:34 -0000
Received: from smtp.citrix.com.au (HELO SMTP.CITRIX.COM.AU) (203.166.19.134)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Dec 2011 08:24:34 -0000
X-IronPort-AV: E=Sophos;i="4.71,375,1320624000"; d="scan'208,217";a="9654754"
Received: from banpmailmx02.citrite.net ([10.103.128.74])
	by SYDPIPO01.CITRIX.COM.AU with ESMTP/TLS/RC4-MD5;
	19 Dec 2011 08:24:30 +0000
Received: from BANPMAILBOX01.citrite.net ([10.103.128.71]) by
	BANPMAILMX02.citrite.net ([10.103.128.74]) with mapi; Mon, 19 Dec 2011
	13:54:29 +0530
From: Pankaj Kumar Biswas <pankaj.kumarbiswas@citrix.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Mon, 19 Dec 2011 13:54:28 +0530
Thread-Topic: Re: vbd-unplug timeout issue
Thread-Index: Acy+J3MqZjM35/weQmq+g5zYuLirDA==
Message-ID: <64FB1554ABC9B44FAA773FBD6CB889C2F91230D411@BANPMAILBOX01.citrite.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Subject: Re: [Xen-devel] vbd-unplug timeout issue
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3399945208348102147=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============3399945208348102147==
Content-Language: en-US
Content-Type: multipart/alternative;
	boundary="_000_64FB1554ABC9B44FAA773FBD6CB889C2F91230D411BANPMAILBOX01_"

--_000_64FB1554ABC9B44FAA773FBD6CB889C2F91230D411BANPMAILBOX01_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


Hi Team,


While running "xe vbd-unplug" command against VBD which is used by VM, it s=
hould return an error. On XenServer 6.0, when I am doing it, I will get an =
error at 1st time, but when I do it again, it does not return error for 120=
0 seconds (20 minutes). I am getting timeout error after 1200 seconds.



The error message on console Is::



   The server failed to handle your request, due to an internal error.

   The given message may give details useful for debugging the problem.

   message: Watch.Timeout(1200.)





In logs:



[20111214T00:49:27.381Z|debug|iida-dl018|611167 unix-RPC||cli] Xapi_cli.exc=
eption_handler: Got exception DEVICE_DETACH_REJECTED: [ VBD; OpaqueRef:2d1d=
0de6-be4c-c214-cade-d8e11d0e2365; 16 Device in use; refusing to close ]


Dec 14 09:49:27 iida-dl018 xapi: [error|iida-dl018|611167 unix-RPC|VBD.unpl=
ug R:72e01c62a8be|xapi] Xapi_vbd.destroy_vbd got an error (frontend (domid=
=3D1 | kind=3Dvbd | devid=3D51712); backend (domid=3D0 | kind=3Dvbd | devid=
=3D51712)) 16 Device in use; refusing to close

Dec 14 10:09:42 iida-dl018 xapi: [error|iida-dl018|611175 unix-RPC|VBD.unpl=
ug R:88079c7cb782|xenops] watch: timeout while watching xenstore after 1200=
.000000 seconds



On XenServer 5.6 (Midnight Ride), I do not see this issue. Is there any cha=
nge in the xapi?? What is the possible cause of the failure??

Is any work-around for this ??


Thanks & Regards,
PANKAJ KUMAR BISWAS


--_000_64FB1554ABC9B44FAA773FBD6CB889C2F91230D411BANPMAILBOX01_
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=3DGenerator content=3D"Micros=
oft Word 14 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
	{font-family:Cambria;
	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;}
/* 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;}
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.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
span.PlainTextChar
	{mso-style-name:"Plain Text Char";
	mso-style-priority:99;
	mso-style-link:"Plain Text";
	font-family:"Calibri","sans-serif";}
.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=3DEN-US link=3Dblue vli=
nk=3Dpurple><div class=3DWordSection1><p class=3DMsoNormal><o:p>&nbsp;</o:p=
></p><p class=3DMsoNormal>Hi Team,<o:p></o:p></p><p class=3DMsoNormal><o:p>=
&nbsp;</o:p></p><p class=3DMsoPlainText>While running &quot;xe vbd-unplug&q=
uot; command against VBD which is used by VM, it should return an error. On=
 XenServer 6.0, when I am doing it, I will get an error at 1st time, but wh=
en I do it again, it does not return error for 1200 seconds (20 minutes). I=
 am getting timeout error after 1200 seconds.<o:p></o:p></p><p class=3DMsoP=
lainText><o:p>&nbsp;</o:p></p><p class=3DMsoPlainText>The error message on =
console Is::<o:p></o:p></p><p class=3DMsoPlainText><o:p>&nbsp;</o:p></p><p =
class=3DMsoPlainText>&nbsp;&nbsp; The server failed to handle your request,=
 due to an internal error.&nbsp; <o:p></o:p></p><p class=3DMsoPlainText>&nb=
sp;&nbsp;&nbsp;The given message may give details useful for debugging the =
problem.<o:p></o:p></p><p class=3DMsoPlainText>&nbsp;&nbsp; message: Watch.=
Timeout(1200.)<o:p></o:p></p><p class=3DMsoPlainText><o:p>&nbsp;</o:p></p><=
p class=3DMsoPlainText><o:p>&nbsp;</o:p></p><p class=3DMsoPlainText>In logs=
:<o:p></o:p></p><p class=3DMsoPlainText><o:p>&nbsp;</o:p></p><p class=3DMso=
PlainText>[20111214T00:49:27.381Z|debug|iida-dl018|611167 unix-RPC||cli] Xa=
pi_cli.exception_handler: Got exception <b>DEVICE_DETACH_REJECTED</b>: [ VB=
D; OpaqueRef:2d1d0de6-be4c-c214-cade-d8e11d0e2365; 16 Device in use; refusi=
ng to close ]<o:p></o:p></p><p class=3DMsoPlainText><o:p>&nbsp;</o:p></p><p=
 class=3DMsoNormal>Dec 14 09:49:27 iida-dl018 xapi: [error|iida-dl018|61116=
7 unix-RPC|VBD.unplug R:72e01c62a8be|xapi] Xapi_vbd.destroy_vbd got an erro=
r (frontend (domid=3D1 | kind=3Dvbd | devid=3D51712); backend (domid=3D0 | =
kind=3Dvbd | devid=3D51712)) 16 <b>Device in use</b>; <b>refusing to close<=
/b> <o:p></o:p></p><p class=3DMsoNormal><o:p>&nbsp;</o:p></p><p class=3DMso=
Normal>Dec 14 10:09:42 iida-dl018 xapi: [error|iida-dl018|611175 unix-RPC|V=
BD.unplug R:88079c7cb782|xenops] <b>watch: timeout while watching xenstore =
after 1200.000000 seconds<o:p></o:p></b></p><p class=3DMsoPlainText><o:p>&n=
bsp;</o:p></p><p class=3DMsoPlainText>On XenServer 5.6 (Midnight Ride), I d=
o not see this issue. Is there any change in the xapi?? What is the possibl=
e cause of the failure??<o:p></o:p></p><p class=3DMsoPlainText>Is any work-=
around for this ??<o:p></o:p></p><p class=3DMsoNormal><o:p>&nbsp;</o:p></p>=
<p class=3DMsoNormal><o:p>&nbsp;</o:p></p><p class=3DMsoNormal><b><span sty=
le=3D'font-family:"Cambria","serif"'>Thanks &amp; Regards,<o:p></o:p></span=
></b></p><p class=3DMsoNormal><b><span style=3D'font-family:"Cambria","seri=
f"'>PANKAJ KUMAR BISWAS<o:p></o:p></span></b></p><p class=3DMsoNormal><b><s=
pan style=3D'font-family:"Cambria","serif"'><o:p>&nbsp;</o:p></span></b></p=
></div></body></html>=

--_000_64FB1554ABC9B44FAA773FBD6CB889C2F91230D411BANPMAILBOX01_--


--===============3399945208348102147==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============3399945208348102147==--


From xen-devel-bounces@lists.xensource.com Mon Dec 19 08:25:29 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 08: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.xensource.com>)
	id 1RcYWu-0007QF-TP; Mon, 19 Dec 2011 08:25:04 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RcYWt-0007PL-G2
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 08:25:03 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1324283096!7917719!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13271 invoked from network); 19 Dec 2011 08:24:57 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-14.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 19 Dec 2011 08:24:57 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 19 Dec 2011 08:24:56 +0000
Message-Id: <4EEF02E20200007800068C60@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 19 Dec 2011 08:24:50 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Hui Lv" <hui.lv@intel.com>
References: <C10D3FB0CD45994C8A51FEC1227CE22F37CC284376@shsmsx502.ccr.corp.intel.com>
In-Reply-To: <C10D3FB0CD45994C8A51FEC1227CE22F37CC284376@shsmsx502.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Kevin Tian <kevin.tian@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"keir@xen.org" <keir@xen.org>, George Dunlap <George.Dunlap@eu.citrix.com>,
	Eddie Dong <eddie.dong@intel.com>, Jiangang Duan <jiangang.duan@intel.com>,
	Zhidong Yu <zhidong.yu@intel.com>
Subject: Re: [Xen-devel] [PATCH v2] xen/credit scheduler;
 Use delay to control scheduling frequency
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 17.12.11 at 04:24, "Lv, Hui" <hui.lv@intel.com> wrote:
> The delay method for credit scheduler can do as well as SRC patch (previous 
> one) to gain significant performance boost without obvious drawbacks.
> 
> 1. Basically, the "delay method" can achieve nearly the same benefits as my 
> previous SRC patch, 11% overall performance boost for SPECvirt than original 
> credit scheduler.
> 2. We have tried 1ms delay and 10ms delay, there is no big difference 
> between these two configurations. (1ms is enough to achieve a good 
> performance)
> 3. We have compared different load level response time/latency (low, high, 
> peak), "delay method" didn't bring very much response time increase.
> 4. 1ms delay can reduce 30% context switch at peak performance, where 
> produces the benefits. ("int sched_ratelimit_us = 1000" is the recommended 
> setting)
> 
> 
> Signed-off-by: Hui Lv <hui.lv@intel.com<mailto:hui.lv@intel.com>>
> Signed-off-by: George Dunlap 
> <George.Dunlap@eu.citrix.com<mailto:George.Dunlap@eu.citrix.com>>
> 
> diff -r 1c58bb664d8d xen/common/sched_credit.c
> --- a/xen/common/sched_credit.c Thu Dec 08 17:15:16 2011 +0000
> +++ b/xen/common/sched_credit.c Fri Dec 16 15:08:09 2011 -0500
> @@ -110,6 +110,9 @@ boolean_param("sched_credit_default_yiel
>  static int __read_mostly sched_credit_tslice_ms = CSCHED_DEFAULT_TSLICE_MS;
>  integer_param("sched_credit_tslice_ms", sched_credit_tslice_ms);
> 
> +/* Scheduler generic parameters
> +*/
> +extern int sched_ratelimit_us;
>  /*
>   * Physical CPU
>   */
> @@ -1297,10 +1300,15 @@ csched_schedule(
>      struct csched_private *prv = CSCHED_PRIV(ops);
>      struct csched_vcpu *snext;
>      struct task_slice ret;
> +    s_time_t runtime, tslice;
> 
>      CSCHED_STAT_CRANK(schedule);
>      CSCHED_VCPU_CHECK(current);
> 
> +    runtime = now - current->runstate.state_entry_time;
> +    if ( runtime < 0 ) /* Does this ever happen? */
> +        runtime = 0;
> +
>      if ( !is_idle_vcpu(scurr->vcpu) )
>      {
>          /* Update credits of a non-idle VCPU. */
> @@ -1313,6 +1321,41 @@ csched_schedule(
>          scurr->pri = CSCHED_PRI_IDLE;
>      }
> 
> +    /* Choices, choices:
> +     * - If we have a tasklet, we need to run the idle vcpu no matter what.
> +     * - If sched rate limiting is in effect, and the current vcpu has
> +     *   run for less than that amount of time, continue the current one,
> +     *   but with a shorter timeslice and return it immediately
> +     * - Otherwise, chose the one with the highest priority (which may
> +     *   be the one currently running)
> +     * - If the currently running one is TS_OVER, see if there
> +     *   is a higher priority one waiting on the runqueue of another
> +     *   cpu and steal it.
> +     */
> +
> +    /* If we have schedule rate limiting enabled, check to see
> +     * how long we've run for. */
> +    if ( sched_ratelimit_us
> +         && !tasklet_work_scheduled

How about making the checking order match the description above
(which might also be slightly faster given that tasklet_work_scheduled
is a function parameter [in a register or written recently], and [given
the default value you're picking] you expect sched_ratelimit_us to be
non-zero generally)?

> +         && vcpu_runnable(current)
> +         && !is_idle_vcpu(current)
> +         && runtime < MICROSECS(sched_ratelimit_us) )
> +    {
> +        snext = scurr;
> +        snext->start_time += now;
> +        perfc_incr(delay_ms);
> +        tslice = MICROSECS(sched_ratelimit_us);

So if there happens to be a VM with 

MILLISECS(prv->tslice_ms) < MICROSECS(sched_ratelimit_us)

it'd get *more* time than allowed/intended through this mechanism.

Jan

> +        ret.migrated = 0;
> +        goto out;
> +    }
> +    else
> +    {
> +        /*
> +         * Select next runnable local VCPU (ie top of local runq)
> +        */
> +        tslice = MILLISECS(prv->tslice_ms);
> +    }
> +
>      /*
>       * Select next runnable local VCPU (ie top of local runq)
>       */
> @@ -1367,11 +1410,12 @@ csched_schedule(
>      if ( !is_idle_vcpu(snext->vcpu) )
>          snext->start_time += now;
> 
> +out:
>      /*
>       * Return task to run next...
>       */
>      ret.time = (is_idle_vcpu(snext->vcpu) ?
> -                -1 : MILLISECS(prv->tslice_ms));
> +                -1 : tslice);
>      ret.task = snext->vcpu;
> 
>      CSCHED_VCPU_CHECK(ret.task);
> diff -r 1c58bb664d8d xen/common/schedule.c
> --- a/xen/common/schedule.c     Thu Dec 08 17:15:16 2011 +0000
> +++ b/xen/common/schedule.c     Fri Dec 16 15:08:09 2011 -0500
> @@ -47,6 +47,10 @@ string_param("sched", opt_sched);
>  bool_t sched_smt_power_savings = 0;
>  boolean_param("sched_smt_power_savings", sched_smt_power_savings);
> 
> +/* Default scheduling rate limit: 1ms */
> +int sched_ratelimit_us = 1000;
> +integer_param("sched_ratelimit_us", sched_ratelimit_us);
> +
>  /* Various timer handlers. */
>  static void s_timer_fn(void *unused);
>  static void vcpu_periodic_timer_fn(void *data);
> diff -r 1c58bb664d8d xen/include/xen/perfc_defn.h
> --- a/xen/include/xen/perfc_defn.h      Thu Dec 08 17:15:16 2011 +0000
> +++ b/xen/include/xen/perfc_defn.h      Fri Dec 16 15:08:09 2011 -0500
> @@ -16,6 +16,7 @@ PERFCOUNTER(sched_irq,              "sch
>  PERFCOUNTER(sched_run,              "sched: runs through scheduler")
>  PERFCOUNTER(sched_ctx,              "sched: context switches")
> 
> +PERFCOUNTER(delay_ms,              "csched: delay")
>  PERFCOUNTER(vcpu_check,             "csched: vcpu_check")
>  PERFCOUNTER(schedule,               "csched: schedule")
>  PERFCOUNTER(acct_run,               "csched: acct_run")



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 08:25:29 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 08: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.xensource.com>)
	id 1RcYWu-0007QF-TP; Mon, 19 Dec 2011 08:25:04 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RcYWt-0007PL-G2
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 08:25:03 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1324283096!7917719!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13271 invoked from network); 19 Dec 2011 08:24:57 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-14.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 19 Dec 2011 08:24:57 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 19 Dec 2011 08:24:56 +0000
Message-Id: <4EEF02E20200007800068C60@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 19 Dec 2011 08:24:50 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Hui Lv" <hui.lv@intel.com>
References: <C10D3FB0CD45994C8A51FEC1227CE22F37CC284376@shsmsx502.ccr.corp.intel.com>
In-Reply-To: <C10D3FB0CD45994C8A51FEC1227CE22F37CC284376@shsmsx502.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Kevin Tian <kevin.tian@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"keir@xen.org" <keir@xen.org>, George Dunlap <George.Dunlap@eu.citrix.com>,
	Eddie Dong <eddie.dong@intel.com>, Jiangang Duan <jiangang.duan@intel.com>,
	Zhidong Yu <zhidong.yu@intel.com>
Subject: Re: [Xen-devel] [PATCH v2] xen/credit scheduler;
 Use delay to control scheduling frequency
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 17.12.11 at 04:24, "Lv, Hui" <hui.lv@intel.com> wrote:
> The delay method for credit scheduler can do as well as SRC patch (previous 
> one) to gain significant performance boost without obvious drawbacks.
> 
> 1. Basically, the "delay method" can achieve nearly the same benefits as my 
> previous SRC patch, 11% overall performance boost for SPECvirt than original 
> credit scheduler.
> 2. We have tried 1ms delay and 10ms delay, there is no big difference 
> between these two configurations. (1ms is enough to achieve a good 
> performance)
> 3. We have compared different load level response time/latency (low, high, 
> peak), "delay method" didn't bring very much response time increase.
> 4. 1ms delay can reduce 30% context switch at peak performance, where 
> produces the benefits. ("int sched_ratelimit_us = 1000" is the recommended 
> setting)
> 
> 
> Signed-off-by: Hui Lv <hui.lv@intel.com<mailto:hui.lv@intel.com>>
> Signed-off-by: George Dunlap 
> <George.Dunlap@eu.citrix.com<mailto:George.Dunlap@eu.citrix.com>>
> 
> diff -r 1c58bb664d8d xen/common/sched_credit.c
> --- a/xen/common/sched_credit.c Thu Dec 08 17:15:16 2011 +0000
> +++ b/xen/common/sched_credit.c Fri Dec 16 15:08:09 2011 -0500
> @@ -110,6 +110,9 @@ boolean_param("sched_credit_default_yiel
>  static int __read_mostly sched_credit_tslice_ms = CSCHED_DEFAULT_TSLICE_MS;
>  integer_param("sched_credit_tslice_ms", sched_credit_tslice_ms);
> 
> +/* Scheduler generic parameters
> +*/
> +extern int sched_ratelimit_us;
>  /*
>   * Physical CPU
>   */
> @@ -1297,10 +1300,15 @@ csched_schedule(
>      struct csched_private *prv = CSCHED_PRIV(ops);
>      struct csched_vcpu *snext;
>      struct task_slice ret;
> +    s_time_t runtime, tslice;
> 
>      CSCHED_STAT_CRANK(schedule);
>      CSCHED_VCPU_CHECK(current);
> 
> +    runtime = now - current->runstate.state_entry_time;
> +    if ( runtime < 0 ) /* Does this ever happen? */
> +        runtime = 0;
> +
>      if ( !is_idle_vcpu(scurr->vcpu) )
>      {
>          /* Update credits of a non-idle VCPU. */
> @@ -1313,6 +1321,41 @@ csched_schedule(
>          scurr->pri = CSCHED_PRI_IDLE;
>      }
> 
> +    /* Choices, choices:
> +     * - If we have a tasklet, we need to run the idle vcpu no matter what.
> +     * - If sched rate limiting is in effect, and the current vcpu has
> +     *   run for less than that amount of time, continue the current one,
> +     *   but with a shorter timeslice and return it immediately
> +     * - Otherwise, chose the one with the highest priority (which may
> +     *   be the one currently running)
> +     * - If the currently running one is TS_OVER, see if there
> +     *   is a higher priority one waiting on the runqueue of another
> +     *   cpu and steal it.
> +     */
> +
> +    /* If we have schedule rate limiting enabled, check to see
> +     * how long we've run for. */
> +    if ( sched_ratelimit_us
> +         && !tasklet_work_scheduled

How about making the checking order match the description above
(which might also be slightly faster given that tasklet_work_scheduled
is a function parameter [in a register or written recently], and [given
the default value you're picking] you expect sched_ratelimit_us to be
non-zero generally)?

> +         && vcpu_runnable(current)
> +         && !is_idle_vcpu(current)
> +         && runtime < MICROSECS(sched_ratelimit_us) )
> +    {
> +        snext = scurr;
> +        snext->start_time += now;
> +        perfc_incr(delay_ms);
> +        tslice = MICROSECS(sched_ratelimit_us);

So if there happens to be a VM with 

MILLISECS(prv->tslice_ms) < MICROSECS(sched_ratelimit_us)

it'd get *more* time than allowed/intended through this mechanism.

Jan

> +        ret.migrated = 0;
> +        goto out;
> +    }
> +    else
> +    {
> +        /*
> +         * Select next runnable local VCPU (ie top of local runq)
> +        */
> +        tslice = MILLISECS(prv->tslice_ms);
> +    }
> +
>      /*
>       * Select next runnable local VCPU (ie top of local runq)
>       */
> @@ -1367,11 +1410,12 @@ csched_schedule(
>      if ( !is_idle_vcpu(snext->vcpu) )
>          snext->start_time += now;
> 
> +out:
>      /*
>       * Return task to run next...
>       */
>      ret.time = (is_idle_vcpu(snext->vcpu) ?
> -                -1 : MILLISECS(prv->tslice_ms));
> +                -1 : tslice);
>      ret.task = snext->vcpu;
> 
>      CSCHED_VCPU_CHECK(ret.task);
> diff -r 1c58bb664d8d xen/common/schedule.c
> --- a/xen/common/schedule.c     Thu Dec 08 17:15:16 2011 +0000
> +++ b/xen/common/schedule.c     Fri Dec 16 15:08:09 2011 -0500
> @@ -47,6 +47,10 @@ string_param("sched", opt_sched);
>  bool_t sched_smt_power_savings = 0;
>  boolean_param("sched_smt_power_savings", sched_smt_power_savings);
> 
> +/* Default scheduling rate limit: 1ms */
> +int sched_ratelimit_us = 1000;
> +integer_param("sched_ratelimit_us", sched_ratelimit_us);
> +
>  /* Various timer handlers. */
>  static void s_timer_fn(void *unused);
>  static void vcpu_periodic_timer_fn(void *data);
> diff -r 1c58bb664d8d xen/include/xen/perfc_defn.h
> --- a/xen/include/xen/perfc_defn.h      Thu Dec 08 17:15:16 2011 +0000
> +++ b/xen/include/xen/perfc_defn.h      Fri Dec 16 15:08:09 2011 -0500
> @@ -16,6 +16,7 @@ PERFCOUNTER(sched_irq,              "sch
>  PERFCOUNTER(sched_run,              "sched: runs through scheduler")
>  PERFCOUNTER(sched_ctx,              "sched: context switches")
> 
> +PERFCOUNTER(delay_ms,              "csched: delay")
>  PERFCOUNTER(vcpu_check,             "csched: vcpu_check")
>  PERFCOUNTER(schedule,               "csched: schedule")
>  PERFCOUNTER(acct_run,               "csched: acct_run")



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 09:01:16 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 09:01:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RcZ5E-0007zv-BR; Mon, 19 Dec 2011 09:00:32 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RcZ5C-0007zc-QX
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 09:00:31 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1324285187!47263205!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzA0MA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17562 invoked from network); 19 Dec 2011 08:59:47 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Dec 2011 08:59:47 -0000
X-IronPort-AV: E=Sophos;i="4.71,375,1320624000"; 
   d="scan'208";a="9547250"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Dec 2011 09:00:28 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 19 Dec 2011 09:00:28 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RcZ5A-0002tB-Ck;
	Mon, 19 Dec 2011 09:00:28 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RcZ5A-00026C-7T;
	Mon, 19 Dec 2011 09:00:28 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10541-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 19 Dec 2011 09:00:28 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing test] 10541: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10541 xen-4.1-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10541/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 10501
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  14dbd6be46c8
baseline version:
 xen                  bb365e21314d

------------------------------------------------------------
People who touched revisions under test:
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  George Dunlap <george.dunlap@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Keir Fraser <keir@xen.org>
  Liu, Jinsong <jinsong.liu@intel.com>
  Paul Durrant <paul.durrant@citrix.com>
  Roger Pau Monne <roger.pau@entel.upc.edu>
  Tim Deegan <tim@xen.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-4.1-testing
+ revision=14dbd6be46c8
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-4.1-testing 14dbd6be46c8
+ branch=xen-4.1-testing
+ revision=14dbd6be46c8
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ : xen@xenbits.xensource.com
+ : xen@xenbits.xensource.com:git/linux-pvops
+ : master
+ : tested/2.6.39.x
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-4.1-testing.hg
+ hg push -r 14dbd6be46c8 ssh://xen@xenbits.xensource.com/HG/xen-4.1-testing.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-4.1-testing.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 4 changesets with 7 changes to 7 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 09:01:16 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 09:01:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RcZ5E-0007zv-BR; Mon, 19 Dec 2011 09:00:32 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RcZ5C-0007zc-QX
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 09:00:31 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1324285187!47263205!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzA0MA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17562 invoked from network); 19 Dec 2011 08:59:47 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Dec 2011 08:59:47 -0000
X-IronPort-AV: E=Sophos;i="4.71,375,1320624000"; 
   d="scan'208";a="9547250"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Dec 2011 09:00:28 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 19 Dec 2011 09:00:28 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RcZ5A-0002tB-Ck;
	Mon, 19 Dec 2011 09:00:28 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RcZ5A-00026C-7T;
	Mon, 19 Dec 2011 09:00:28 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10541-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 19 Dec 2011 09:00:28 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing test] 10541: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10541 xen-4.1-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10541/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 10501
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  14dbd6be46c8
baseline version:
 xen                  bb365e21314d

------------------------------------------------------------
People who touched revisions under test:
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  George Dunlap <george.dunlap@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Keir Fraser <keir@xen.org>
  Liu, Jinsong <jinsong.liu@intel.com>
  Paul Durrant <paul.durrant@citrix.com>
  Roger Pau Monne <roger.pau@entel.upc.edu>
  Tim Deegan <tim@xen.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-4.1-testing
+ revision=14dbd6be46c8
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-4.1-testing 14dbd6be46c8
+ branch=xen-4.1-testing
+ revision=14dbd6be46c8
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ : xen@xenbits.xensource.com
+ : xen@xenbits.xensource.com:git/linux-pvops
+ : master
+ : tested/2.6.39.x
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-4.1-testing.hg
+ hg push -r 14dbd6be46c8 ssh://xen@xenbits.xensource.com/HG/xen-4.1-testing.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-4.1-testing.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 4 changesets with 7 changes to 7 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 09:02:32 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 09:02:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RcZ6P-00088E-R4; Mon, 19 Dec 2011 09:01:45 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RcZ6O-00087o-HO
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 09:01:44 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1324285296!6079354!1
X-Originating-IP: [209.85.210.43]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28469 invoked from network); 19 Dec 2011 09:01:37 -0000
Received: from mail-pz0-f43.google.com (HELO mail-pz0-f43.google.com)
	(209.85.210.43)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Dec 2011 09:01:37 -0000
Received: by daec6 with SMTP id c6so24790343dae.30
	for <xen-devel@lists.xensource.com>;
	Mon, 19 Dec 2011 01:01:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=P5YfdMl99N+8oRBiqGN0w6VlkFy7liaJyi7CDbk6VTU=;
	b=t+udt46Iz+TRvPww8oyyp4IoS18G4GbiMdRBWnvh/hdGZvSB5d9CQNXZYkKJ7SCQHM
	v3UoK0UnShP7dplvkwzc0X0ZNKEeoBpRQjvr/H71FebmN/i8pY7DqvdIDKRVZoJVy69D
	d2zRhcTt715DdjDpJMKqKJV71v5FBksJrjTdQ=
MIME-Version: 1.0
Received: by 10.68.189.133 with SMTP id gi5mr18762978pbc.27.1324285295651;
	Mon, 19 Dec 2011 01:01:35 -0800 (PST)
Received: by 10.142.47.17 with HTTP; Mon, 19 Dec 2011 01:01:35 -0800 (PST)
In-Reply-To: <1324033955.20077.584.camel@zakaz.uk.xensource.com>
References: <patchbomb.1323768375@loki.upc.es>
	<35c322e6020501447936.1323768387@loki.upc.es>
	<20199.26896.928532.781947@mariner.uk.xensource.com>
	<CAPLaKK6wqa+VAxgzLWudQ2C2kaoXww9KK3BQhU4fKmoCAMFCzQ@mail.gmail.com>
	<1323860097.20077.394.camel@zakaz.uk.xensource.com>
	<CAPLaKK7Wv2HeRbg5Ze=B8DFe=wbzq=V35s6WVFXqrynh0ikRTw@mail.gmail.com>
	<20200.36683.601224.172611@mariner.uk.xensource.com>
	<CAPLaKK5h2PJko6o4v3usJkfttfdFqp9L6DEnfs0YYSSBWS63Eg@mail.gmail.com>
	<1323865369.20077.412.camel@zakaz.uk.xensource.com>
	<20202.12827.152139.501847@mariner.uk.xensource.com>
	<1324033955.20077.584.camel@zakaz.uk.xensource.com>
Date: Mon, 19 Dec 2011 10:01:35 +0100
X-Google-Sender-Auth: UWS_nuYAd2k-joWDWj-Uzj5kIP8
Message-ID: <CAPLaKK6Jb8qz1xGGaovTfYA02FcOdskMXfQqzSeTs6QBUpgDHA@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 12 of 14 v4] libxl: set frontend status to 6
 on domain destroy
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

MjAxMS8xMi8xNiBJYW4gQ2FtcGJlbGwgPElhbi5DYW1wYmVsbEBjaXRyaXguY29tPjoKPiBPbiBU
aHUsIDIwMTEtMTItMTUgYXQgMTc6NDQgKzAwMDAsIElhbiBKYWNrc29uIHdyb3RlOgo+PiBJIGhh
dmUgYmVlbiB0aGlua2luZyBhYm91dCB0aGlzIHdob2xlIGFyZWEuCj4+Cj4+IE9yaWdpbmFsbHkg
bXkgb3BpbmlvbiB3YXMgdGhhdCB0aGUgYmxvY2sgYW5kIG5ldHdvcmsgc2V0dXAgc2NyaXB0cwo+
PiAoZWcsIHNldHRpbmcgdXAgbG9vcGJhY2sgZGV2aWNlcyBvciBpc2NzaSBvciBicmlkZ2luZyB3
aGF0ZXZlcikgc2hvdWxkCj4+IGJlIGV4ZWN1dGVkIGRpcmVjdGx5IGJ5IHhsLiDCoFRoaXMgbmF0
dXJhbGx5IGdpdmVzIHRoZSBiZXN0IGVycm9yCj4+IGhhbmRsaW5nIGFuZCBtYWtlcyBsb2dnaW5n
IGVhc2llc3QuCj4+Cj4+IEhvd2V2ZXIsIGlmIHdlIGFyZSBzZXJpb3VzIGFib3V0IHN1cHBvcnRp
bmcgZHJpdmVyIGRvbWFpbnMsIG9yIGluZGVlZAo+PiBhbnkga2luZCBvZiBiYWNrZW5kIG5vdCBy
dW5uaW5nIGluIHRoZSBzYW1lIGRvbWFpbiBhcyBsaWJ4bCwgdGhlbgo+PiBzb21ldGhpbmcgaW4g
dGhlIGRyaXZlciBkb21haW4gbmVlZHMgdG8gYmUgcmVzcG9uc2libGUgZm9yIGV4ZWN1dGluZwo+
PiB0aGVzZSBzY3JpcHRzIChvciBlcXVpdmFsZW50KS4KPj4KPj4gVGhlIG9idmlvdXMgd2F5IHRv
IGNvbW11bmljYXRlIHRoaXMgaW5mb3JtYXRpb24gdG8gdGhlIGRyaXZlciBkb21haW4KPj4gaXMg
dmlhIHhlbnN0b3JlLgo+Pgo+PiBXaGF0IHdlIHNob3VsZCBiZSBkaXNjdXNzaW5nIGlzIGV4YWN0
bHkgaG93IHRoZSBkcml2ZXIgZG9tYWluCj4+IHRyYW5zbGF0ZXMgdGhhdCBpbnRvIHNjcmlwdCBl
eGVjdXRpb24uIMKgQ3VycmVudGx5IG9uIExpbnV4IHRoaXMgaXMKPj4gbW9zdGx5IGRvbmUgd2l0
aCB1ZGV2LCBhbmQgQUlVSSBvbiBCU0QgdXNpbmcgeGVuYmFja2VuZGQuCj4KPiB4ZW5iYWNrZW5k
ZCBpcyAoQUZBSUspIHdhdGNoaW5nIGZvciBldmVudHMgKGUuZy4gY3JlYXRpb24gYW5kIGRlbGV0
aW9uCj4gb2YgYmFja2VuZCBzdGF0ZSBub2RlcykgaW4geGVuc3RvcmUgc28gYXQgbGVhc3QgaW4g
Y29uY2VwdCBpdCBpcwo+IHBvcnRhYmxlIHRvIGFsbCBPU2VzLCB3aGVyZWFzIHVkZXYgaXMgcHJl
dHR5IExpbnV4IHNwZWNpZmljLgo+Cj4gT25lIG5pY2UgZWZmZWN0IG9mIHRoZSB1ZGV2IGFwcHJv
YWNoIGlzIHRoYXQgeW91IGdldCBhbiBleHBsaWNpdCBldmVudAo+IGUuZy4gd2hlbiBhIGJsb2Nr
IGRldmljZSBpcyB0b3JuIGRvd24uIFRoaXMgbWFrZXMgaXQgdHJpdmlhbCB0byBhdm9pZAo+IHBy
b2JsZW1zIGxpa2UgcmFjaW5nIHRvIHRlYXJkb3duIGEgbG9vcGJhY2sgZGV2aWNlLgoKSSBhZ3Jl
ZSB0aGF0IGV4ZWN1dGluZyBzY3JpcHRzIGZyb20geGwgaXMgbXVjaCBtb3JlIGNvbWZvcnRhYmxl
LCBhbmQKaXQgd291bGQgYmUgZ29vZCB0byBkbyBpdCB0aGF0IHdheSB3aGVuZXZlciBwb3NzaWJs
ZS4gSXQgYWxsb3dzIGVhc2llcgplcnJvciBkZXRlY3Rpb24gYW5kIGNvbnRyb2wgb2Ygd2hlbiBo
b3RwbHVnIHNjcmlwdHMgYXJlIGV4ZWN1dGVkLgoKPiBTaW5jZSB4ZW5iYWNrZW5kZCBpcyBtb3N0
bHkgaW5mZXJyaW5nIHRoaW5ncyBieSB3YXRjaGluZyB0aGUgYmFja2VuZAo+IG5vZGVzIHVzZWQg
YnkgdGhlIGtlcm5lbCBzaWRlIGRyaXZlcnMgaXQgc3RydWdnbGVzIGR1ZSB0byB0aGUgbW9kZWwK
PiB3aGVyZSB3ZSBybSB0aGUgYmFja2VuZCdzIHhlbnN0b3JlIGRpcmVjdG9yeSBvbiBkZXN0cm95
IHdoaWNoIG51a2VzCj4gc3RhdGUgcmVxdWlyZWQgYnkgeGVuYmFja2VuZGQuCj4gVGhlIHhlbmJh
Y2tlbmRkIG1vZGVsIHNlZW1zIHNsaWdodGx5IHByZWZlcmFibGUgdG8gbWUsIGl0J3Mgc2ltcGxl
ciB0bwo+IHNldHVwIGFuZCBtb3JlIHBvcnRhYmxlLiBEb2luZyB0aGluZ3MgZGlmZmVyZW50bHkg
b24gZGlmZmVyZW50IE9TZXMKPiBkb2Vzbid0IGhlbHAgd2l0aCB0aGUgY29uZnVzaW9uIGhlcmUh
Cgp4ZW5iYWNrZW5kIGlzIGEgcXVpdGUgc2ltcGxlIGltcGxlbWVudGF0aW9uLCBpdCBvbmx5IHdh
dGNoZXMgYmFja2VuZApjaGFuZ2VzIGFuZCByZWFjdHMgdXBvbiB0aGVtLiBJdCBpcyBlYXN5IHRv
IGltcGxlbWVudCwgYnV0IGl0IGlzCmRpZmZpY3VsdCB0byBkZWJ1Zywgc2luY2UgaG90cGx1ZyBl
eGVjdXRpb24gaXMgdGllZCB0byB4ZW5zdG9yZQpldmVudHMsIGFuZCByaWdodCBub3cgdGhlcmUn
cyBubyB3YXkgdG8gc3luY2hyb25pemUgdGhlIHRvb2xzdGFjayB3aXRoCnhlbmJhY2tlbmQgKHhl
bmJhY2tlbmQgaXMgb25seSBzeW5jaHJvbml6ZWQgd2l0aCB0aGUga2VybmVsKS4KCj4gUGVyaGFw
cyB0aGUgY29yZSBmdW5jdGlvbmFsaXR5IGNvdWxkIGJlIGluIGxpYnhsIHN1Y2ggdGhhdCBhIHRv
b2xzdGFjawo+IGNhbiBjaG9vc2UgdG8gaW50ZWdyYXRlIHRoZSBmdW5jdGlvbmFsaXR5IG9yIHJ1
biBpdCBhcyBhIHNlcGFyYXRlIGRhZW1vbgo+IGFzIG5lY2Vzc2FyeT8KCkl0IHdvdWxkIGJlIGlu
dGVyZXN0aW5nIHRvIGltcGxlbWVudCBhbGwgaG90cGx1ZyBjYWxsIGZ1bmN0aW9ucyBpbnRvCmxp
YnhsLCBhbmQgaGF2ZSBhIGNvbmZpZ3VyYXRpb24gb3B0aW9uIGF0IHhsLmNvbmYgdGhhdCBzcGVj
aWZpZXMgaWYKaG90cGx1ZyBzY3JpcHRzIHNob3VsZCBiZSBleGVjdXRlZCBmcm9tIHhsIGRpcmVj
dGx5IG9yIGRlbGVnYXRlIHRoZQpleGVjdXRpb24gdG8geGVuYmFja2VuZCwgdGhhdCBzaG91bGQg
YmUgcmV3cml0dGVuIHRvIHVzZSB0aGUgc2FtZQpsaWJ4bCBmdW5jdGlvbnMsIHRvIGF2b2lkIGhh
dmluZyBkdXBsaWNhdGUgY29kZS4KCj4gVGhlIG1haW4gaXNzdWUgd2l0aCB0aGUgeGVuYmFja2Vu
ZGQgbW9kZWwgaXMgdGhlIG1hbm5lciBpbiB3aGljaCBpdCBoYXMKPiB0byBndWVzcyB3aGF0IGlz
IGdvaW5nIG9uIGFuZCB0cnkgdG8gc3luY2hyb25pc2Ugd2l0aCB3aGF0IHRoZSBkcml2ZXJzCj4g
YXJlIGdvaW5nLiBUaGlzIGRvZXMgYWxzbyBlZmZlY3QgdGhlIHVkZXYgZHJpdmVuIHdheSBvZiBk
b2luZyB0aGluZ3MgdG9vCj4gc2luY2UgdGhlIHNjcmlwdHMgb2Z0ZW4gd2FudCB0byBsb29rIGlu
IHhlbnN0b3JlIGZvciBwYXJhbWV0ZXJzIGFuZCBvbgo+IGRlc3Ryb3kgdGhleSBhcmUgb2Z0ZW4g
bWlzc2luZy4KPgo+IFdlIGN1cnJlbnRseSBnZXQgdGhpcyB3cm9uZyB1bmRlciBMaW51eCBhdCB0
aGUgbWludXRlIGFuZCB0aGUgbmV0d29yawo+IHRlYXJkb3duIGhvdHBsdWcgc2NyaXB0IGRvZXNu
J3Qgd29yayByaWdodCBiZWNhdXNlIHRoZSBuZWNlc3NhcnkgYml0cwo+IGFyZSBnb25lIGZyb20g
eGVuc3RvcmUuIFdlIG1vc3RseSBnZXQgYXdheSB3aXRoIHRoaXMgZm9yIGJyaWRnaW5nIHNpbmNl
Cj4gdGhlIGRldmljZSBpcyBhdXRvbWF0aWNhbGx5IHJlbW92ZSBmcm9tIHRoZSBicmlkZ2UgYnV0
IGZvciB2c3dpdGNoIHdlIGRvCj4gbmVlZCB0byBhY3R1YWxseSBkbyBzb21lIHJlY29uZmlndXJh
dGlvbiBhdCB0aGlzIHBvaW50LiBXZSBhbHNvIGFwcGVhcgo+IHRvIGxlYWsgaXB0YWJsZXMgcnVs
ZXMgdW5kZXIgc29tZSBjaXJjdW1zdGFuY2VzLgo+Cj4gUGVyaGFwcyB3ZSB3b3VsZCBiZSBiZXR0
ZXIgb2ZmIHNwbGl0dGluZyB0aGUgaG90cGx1ZyBzdHVmZiBpbnRvIGl0cyBvd24KPiBwbGFjZSBp
biB4ZW5zdG9yZSBhbmQgaGF2ZSB0aGUgdG9vbHN0YWNrIGV4cGxpY2l0bHkgdHJpZ2dlciBldmVu
dHMgYXQKPiB0aGUgcmlnaHQgdGltZSBieSB3cml0aW5nIHRvIGl0PyBUaGlzIGNvdWxkIGJlIGNv
bXBhdGlibGUgd2l0aCBleGlzdGluZwo+IHNjcmlwdHMgc2luY2UgdGhleSB1c2UgYW4gZW52aXJv
bm1lbnQgdmFyaWFibGUgdG8gZmluZCB0aGVpciB4ZW5zdG9yZQo+IGJhc2UgcGF0aC4KCkN1cnJl
bnRseSB0aGUgb25seSBwb3NzaWJsZSB3YXkgdG8gc3luY2hyb25pemUgeGVuYmFja2VuZCBhbmQg
dGhlCnRvb2xzdGFjayBpcyB0byB3YXRjaCB0aGUgaG90cGx1Zy1zdGF0dXMgeGVuYmFja2VuZCBl
bnRyeSwgSSd2ZSBwb3N0ZWQKYSBwYXRjaCBhIGxvbmcgdGltZSBhZ28sIHRoYXQgdHJpZWQgdG8g
c3luY2hyb25pemUgeGwgYW5kIHhlbmJhY2tlbmQKdXNpbmcgdGhlIGhvdHBsdWctc3RhdHVzIHhl
bnN0b3JlIGVudHJ5LgoKPiBXZSBuZWVkIHRvIGJlIGF3YXJlIHRoYXQgdGhlIHNjcmlwdCBtb2Rl
bHMgKG9yIGF0IGxlYXN0IHRoZSBzZXF1ZW5jaW5nCj4gd3J0IHRoZSB4ZW5zdG9yZSBzdGF0ZSB0
cmFuc2l0aW9ucykgdmFyeSBzbGlnaHRseSB3aXRoIHRoZSBkZXZpY2UgdHlwZQo+IHNpbmNlIGZv
ciBibG9jayBkZXZpY2VzIHlvdSB0eXBpY2FsbHkgbmVlZCB0byBydW4gdGhlIGhvdHBsdWcgc2Ny
aXB0Cj4gYmVmb3JlIGNyZWF0aW5nIHRoZSBiYWNrZW5kIHdoZXJlYXMgd2l0aCBuZXR3b3JrIGRl
dmljZXMgeW91IGNyZWF0ZSB0aGUKPiBkZXZpY2UgZmlyc3QgYW5kIHRoZW4gcnVuIHRoZSBzY3Jp
cHQgdG8gY29uZmlndXJlIGl0LiB2aWNlIHZlcnNhIGZvcgo+IGRlc3Ryb3kuCgpJIHRoaW5rIHRo
YXQgdGhlIGVhc2llciB3YXkgdG8gZGVhbCB3aXRoIGhvdHBsdWcgc2NyaXB0cyBpcyB0byBleGVj
dXRlCnRoZW0gd2hlbiBiYWNrZW5kIHN0YXRlIGlzIDIsIHRoYXQgaXMgdHJ1ZSBmb3IgYm90aCBu
ZXR3b3JrIGFuZCBibG9jawpzY3JpcHRzIChhdCBsZWFzdCBvbiBOZXRCU0QpLgoKPiBXZSBhbHNv
IG5lZWQgdG8gY29uc2lkZXIgTmV0d29yayB0YXAgZGV2aWNlcy4gTm90IGFsbCB0YXAgZGV2aWNl
cyBhcmUKPiBwYXJ0IG9mIFhlbidzIHdvcmxkIHdoaWNoIGlzIGEgd3JpbmtsZSB3aGljaCBuZWVk
cyB0aG91Z2h0Lgo+Cj4gSSB0cmllZCB0byB3cml0ZSBkb3duIG15IHVuZGVyc3RhbmRpbmcgb2Yg
dGhlIGV2ZW50cyBhbmQgc2VxdWVuY2luZwo+IHVuZGVyIExpbnV4IGJ1dCB0aGF0IG1vc3RseSBz
aG93ZWQgdGhlIGdhcHMgaW4gbXkgdW5kZXJzdGFuZGluZy4uLgo+Cj4gQUlVSSBYQ1AgZG9lcyBh
IGxvdCBtb3JlIG9mIHRoaXMgc3R1ZmYgdmlhIHhlbnN0b3JlZCBhbmQgaGF2ZSBiZWVuCj4gKHN1
Y2Nlc3NmdWxseSkgcGxheWluZyB3aXRoIGRyaXZlciBkb21haW5zIC0tIHdlIHNob3VsZCBhc2sg
Zm9yIHRoZWlyCj4gaW5wdXQuCj4KCkFmdGVyIGFsbCB0aGlzLCB3aGF0IHNlZW1zIG1vc3Qgc3Vp
dGFibGUgdG8gbWUgaXMgdG8gaGF2ZSBob3RwbHVnCnNjcmlwdCBjYWxsaW5nIGZ1bmN0aW9ucyBp
bnNpZGUgbGlieGwsIG1vZGlmeSB4ZW5iYWNrZW5kIHRvIHVzZSBsaWJ4bApBUEksIGFuZCBnaXZl
IHRoZSB1c2VyIHRoZSBvcHRpb24gdG8gZXhlY3V0ZSBob3RwbHVnIHNjcmlwdHMgZGlyZWN0bHkK
ZnJvbSB4bCAoY2FsbGluZyBsaWJ4bCBob3RwbHVnIGZ1bmN0aW9ucykgb3IgZGVsZWdhdGUgdGhl
IHdvcmsgdG8KeGVuYmFja2VuZCAod3JpdGluZyBhIHZhbHVlIHRvIHhlbnN0b3JlIHRoYXQgeGVu
YmFja2VuZCBjYW4gdXNlIHRvCnN5bmNocm9uaXplIGFuZCB0cmlnZ2VycyBleGVjdXRpb24pLgoK
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVs
IG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuc291cmNlLmNvbQpodHRwOi8vbGlzdHMu
eGVuc291cmNlLmNvbS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Mon Dec 19 09:02:32 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 09:02:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RcZ6P-00088E-R4; Mon, 19 Dec 2011 09:01:45 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RcZ6O-00087o-HO
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 09:01:44 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1324285296!6079354!1
X-Originating-IP: [209.85.210.43]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28469 invoked from network); 19 Dec 2011 09:01:37 -0000
Received: from mail-pz0-f43.google.com (HELO mail-pz0-f43.google.com)
	(209.85.210.43)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Dec 2011 09:01:37 -0000
Received: by daec6 with SMTP id c6so24790343dae.30
	for <xen-devel@lists.xensource.com>;
	Mon, 19 Dec 2011 01:01:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=P5YfdMl99N+8oRBiqGN0w6VlkFy7liaJyi7CDbk6VTU=;
	b=t+udt46Iz+TRvPww8oyyp4IoS18G4GbiMdRBWnvh/hdGZvSB5d9CQNXZYkKJ7SCQHM
	v3UoK0UnShP7dplvkwzc0X0ZNKEeoBpRQjvr/H71FebmN/i8pY7DqvdIDKRVZoJVy69D
	d2zRhcTt715DdjDpJMKqKJV71v5FBksJrjTdQ=
MIME-Version: 1.0
Received: by 10.68.189.133 with SMTP id gi5mr18762978pbc.27.1324285295651;
	Mon, 19 Dec 2011 01:01:35 -0800 (PST)
Received: by 10.142.47.17 with HTTP; Mon, 19 Dec 2011 01:01:35 -0800 (PST)
In-Reply-To: <1324033955.20077.584.camel@zakaz.uk.xensource.com>
References: <patchbomb.1323768375@loki.upc.es>
	<35c322e6020501447936.1323768387@loki.upc.es>
	<20199.26896.928532.781947@mariner.uk.xensource.com>
	<CAPLaKK6wqa+VAxgzLWudQ2C2kaoXww9KK3BQhU4fKmoCAMFCzQ@mail.gmail.com>
	<1323860097.20077.394.camel@zakaz.uk.xensource.com>
	<CAPLaKK7Wv2HeRbg5Ze=B8DFe=wbzq=V35s6WVFXqrynh0ikRTw@mail.gmail.com>
	<20200.36683.601224.172611@mariner.uk.xensource.com>
	<CAPLaKK5h2PJko6o4v3usJkfttfdFqp9L6DEnfs0YYSSBWS63Eg@mail.gmail.com>
	<1323865369.20077.412.camel@zakaz.uk.xensource.com>
	<20202.12827.152139.501847@mariner.uk.xensource.com>
	<1324033955.20077.584.camel@zakaz.uk.xensource.com>
Date: Mon, 19 Dec 2011 10:01:35 +0100
X-Google-Sender-Auth: UWS_nuYAd2k-joWDWj-Uzj5kIP8
Message-ID: <CAPLaKK6Jb8qz1xGGaovTfYA02FcOdskMXfQqzSeTs6QBUpgDHA@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 12 of 14 v4] libxl: set frontend status to 6
 on domain destroy
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

MjAxMS8xMi8xNiBJYW4gQ2FtcGJlbGwgPElhbi5DYW1wYmVsbEBjaXRyaXguY29tPjoKPiBPbiBU
aHUsIDIwMTEtMTItMTUgYXQgMTc6NDQgKzAwMDAsIElhbiBKYWNrc29uIHdyb3RlOgo+PiBJIGhh
dmUgYmVlbiB0aGlua2luZyBhYm91dCB0aGlzIHdob2xlIGFyZWEuCj4+Cj4+IE9yaWdpbmFsbHkg
bXkgb3BpbmlvbiB3YXMgdGhhdCB0aGUgYmxvY2sgYW5kIG5ldHdvcmsgc2V0dXAgc2NyaXB0cwo+
PiAoZWcsIHNldHRpbmcgdXAgbG9vcGJhY2sgZGV2aWNlcyBvciBpc2NzaSBvciBicmlkZ2luZyB3
aGF0ZXZlcikgc2hvdWxkCj4+IGJlIGV4ZWN1dGVkIGRpcmVjdGx5IGJ5IHhsLiDCoFRoaXMgbmF0
dXJhbGx5IGdpdmVzIHRoZSBiZXN0IGVycm9yCj4+IGhhbmRsaW5nIGFuZCBtYWtlcyBsb2dnaW5n
IGVhc2llc3QuCj4+Cj4+IEhvd2V2ZXIsIGlmIHdlIGFyZSBzZXJpb3VzIGFib3V0IHN1cHBvcnRp
bmcgZHJpdmVyIGRvbWFpbnMsIG9yIGluZGVlZAo+PiBhbnkga2luZCBvZiBiYWNrZW5kIG5vdCBy
dW5uaW5nIGluIHRoZSBzYW1lIGRvbWFpbiBhcyBsaWJ4bCwgdGhlbgo+PiBzb21ldGhpbmcgaW4g
dGhlIGRyaXZlciBkb21haW4gbmVlZHMgdG8gYmUgcmVzcG9uc2libGUgZm9yIGV4ZWN1dGluZwo+
PiB0aGVzZSBzY3JpcHRzIChvciBlcXVpdmFsZW50KS4KPj4KPj4gVGhlIG9idmlvdXMgd2F5IHRv
IGNvbW11bmljYXRlIHRoaXMgaW5mb3JtYXRpb24gdG8gdGhlIGRyaXZlciBkb21haW4KPj4gaXMg
dmlhIHhlbnN0b3JlLgo+Pgo+PiBXaGF0IHdlIHNob3VsZCBiZSBkaXNjdXNzaW5nIGlzIGV4YWN0
bHkgaG93IHRoZSBkcml2ZXIgZG9tYWluCj4+IHRyYW5zbGF0ZXMgdGhhdCBpbnRvIHNjcmlwdCBl
eGVjdXRpb24uIMKgQ3VycmVudGx5IG9uIExpbnV4IHRoaXMgaXMKPj4gbW9zdGx5IGRvbmUgd2l0
aCB1ZGV2LCBhbmQgQUlVSSBvbiBCU0QgdXNpbmcgeGVuYmFja2VuZGQuCj4KPiB4ZW5iYWNrZW5k
ZCBpcyAoQUZBSUspIHdhdGNoaW5nIGZvciBldmVudHMgKGUuZy4gY3JlYXRpb24gYW5kIGRlbGV0
aW9uCj4gb2YgYmFja2VuZCBzdGF0ZSBub2RlcykgaW4geGVuc3RvcmUgc28gYXQgbGVhc3QgaW4g
Y29uY2VwdCBpdCBpcwo+IHBvcnRhYmxlIHRvIGFsbCBPU2VzLCB3aGVyZWFzIHVkZXYgaXMgcHJl
dHR5IExpbnV4IHNwZWNpZmljLgo+Cj4gT25lIG5pY2UgZWZmZWN0IG9mIHRoZSB1ZGV2IGFwcHJv
YWNoIGlzIHRoYXQgeW91IGdldCBhbiBleHBsaWNpdCBldmVudAo+IGUuZy4gd2hlbiBhIGJsb2Nr
IGRldmljZSBpcyB0b3JuIGRvd24uIFRoaXMgbWFrZXMgaXQgdHJpdmlhbCB0byBhdm9pZAo+IHBy
b2JsZW1zIGxpa2UgcmFjaW5nIHRvIHRlYXJkb3duIGEgbG9vcGJhY2sgZGV2aWNlLgoKSSBhZ3Jl
ZSB0aGF0IGV4ZWN1dGluZyBzY3JpcHRzIGZyb20geGwgaXMgbXVjaCBtb3JlIGNvbWZvcnRhYmxl
LCBhbmQKaXQgd291bGQgYmUgZ29vZCB0byBkbyBpdCB0aGF0IHdheSB3aGVuZXZlciBwb3NzaWJs
ZS4gSXQgYWxsb3dzIGVhc2llcgplcnJvciBkZXRlY3Rpb24gYW5kIGNvbnRyb2wgb2Ygd2hlbiBo
b3RwbHVnIHNjcmlwdHMgYXJlIGV4ZWN1dGVkLgoKPiBTaW5jZSB4ZW5iYWNrZW5kZCBpcyBtb3N0
bHkgaW5mZXJyaW5nIHRoaW5ncyBieSB3YXRjaGluZyB0aGUgYmFja2VuZAo+IG5vZGVzIHVzZWQg
YnkgdGhlIGtlcm5lbCBzaWRlIGRyaXZlcnMgaXQgc3RydWdnbGVzIGR1ZSB0byB0aGUgbW9kZWwK
PiB3aGVyZSB3ZSBybSB0aGUgYmFja2VuZCdzIHhlbnN0b3JlIGRpcmVjdG9yeSBvbiBkZXN0cm95
IHdoaWNoIG51a2VzCj4gc3RhdGUgcmVxdWlyZWQgYnkgeGVuYmFja2VuZGQuCj4gVGhlIHhlbmJh
Y2tlbmRkIG1vZGVsIHNlZW1zIHNsaWdodGx5IHByZWZlcmFibGUgdG8gbWUsIGl0J3Mgc2ltcGxl
ciB0bwo+IHNldHVwIGFuZCBtb3JlIHBvcnRhYmxlLiBEb2luZyB0aGluZ3MgZGlmZmVyZW50bHkg
b24gZGlmZmVyZW50IE9TZXMKPiBkb2Vzbid0IGhlbHAgd2l0aCB0aGUgY29uZnVzaW9uIGhlcmUh
Cgp4ZW5iYWNrZW5kIGlzIGEgcXVpdGUgc2ltcGxlIGltcGxlbWVudGF0aW9uLCBpdCBvbmx5IHdh
dGNoZXMgYmFja2VuZApjaGFuZ2VzIGFuZCByZWFjdHMgdXBvbiB0aGVtLiBJdCBpcyBlYXN5IHRv
IGltcGxlbWVudCwgYnV0IGl0IGlzCmRpZmZpY3VsdCB0byBkZWJ1Zywgc2luY2UgaG90cGx1ZyBl
eGVjdXRpb24gaXMgdGllZCB0byB4ZW5zdG9yZQpldmVudHMsIGFuZCByaWdodCBub3cgdGhlcmUn
cyBubyB3YXkgdG8gc3luY2hyb25pemUgdGhlIHRvb2xzdGFjayB3aXRoCnhlbmJhY2tlbmQgKHhl
bmJhY2tlbmQgaXMgb25seSBzeW5jaHJvbml6ZWQgd2l0aCB0aGUga2VybmVsKS4KCj4gUGVyaGFw
cyB0aGUgY29yZSBmdW5jdGlvbmFsaXR5IGNvdWxkIGJlIGluIGxpYnhsIHN1Y2ggdGhhdCBhIHRv
b2xzdGFjawo+IGNhbiBjaG9vc2UgdG8gaW50ZWdyYXRlIHRoZSBmdW5jdGlvbmFsaXR5IG9yIHJ1
biBpdCBhcyBhIHNlcGFyYXRlIGRhZW1vbgo+IGFzIG5lY2Vzc2FyeT8KCkl0IHdvdWxkIGJlIGlu
dGVyZXN0aW5nIHRvIGltcGxlbWVudCBhbGwgaG90cGx1ZyBjYWxsIGZ1bmN0aW9ucyBpbnRvCmxp
YnhsLCBhbmQgaGF2ZSBhIGNvbmZpZ3VyYXRpb24gb3B0aW9uIGF0IHhsLmNvbmYgdGhhdCBzcGVj
aWZpZXMgaWYKaG90cGx1ZyBzY3JpcHRzIHNob3VsZCBiZSBleGVjdXRlZCBmcm9tIHhsIGRpcmVj
dGx5IG9yIGRlbGVnYXRlIHRoZQpleGVjdXRpb24gdG8geGVuYmFja2VuZCwgdGhhdCBzaG91bGQg
YmUgcmV3cml0dGVuIHRvIHVzZSB0aGUgc2FtZQpsaWJ4bCBmdW5jdGlvbnMsIHRvIGF2b2lkIGhh
dmluZyBkdXBsaWNhdGUgY29kZS4KCj4gVGhlIG1haW4gaXNzdWUgd2l0aCB0aGUgeGVuYmFja2Vu
ZGQgbW9kZWwgaXMgdGhlIG1hbm5lciBpbiB3aGljaCBpdCBoYXMKPiB0byBndWVzcyB3aGF0IGlz
IGdvaW5nIG9uIGFuZCB0cnkgdG8gc3luY2hyb25pc2Ugd2l0aCB3aGF0IHRoZSBkcml2ZXJzCj4g
YXJlIGdvaW5nLiBUaGlzIGRvZXMgYWxzbyBlZmZlY3QgdGhlIHVkZXYgZHJpdmVuIHdheSBvZiBk
b2luZyB0aGluZ3MgdG9vCj4gc2luY2UgdGhlIHNjcmlwdHMgb2Z0ZW4gd2FudCB0byBsb29rIGlu
IHhlbnN0b3JlIGZvciBwYXJhbWV0ZXJzIGFuZCBvbgo+IGRlc3Ryb3kgdGhleSBhcmUgb2Z0ZW4g
bWlzc2luZy4KPgo+IFdlIGN1cnJlbnRseSBnZXQgdGhpcyB3cm9uZyB1bmRlciBMaW51eCBhdCB0
aGUgbWludXRlIGFuZCB0aGUgbmV0d29yawo+IHRlYXJkb3duIGhvdHBsdWcgc2NyaXB0IGRvZXNu
J3Qgd29yayByaWdodCBiZWNhdXNlIHRoZSBuZWNlc3NhcnkgYml0cwo+IGFyZSBnb25lIGZyb20g
eGVuc3RvcmUuIFdlIG1vc3RseSBnZXQgYXdheSB3aXRoIHRoaXMgZm9yIGJyaWRnaW5nIHNpbmNl
Cj4gdGhlIGRldmljZSBpcyBhdXRvbWF0aWNhbGx5IHJlbW92ZSBmcm9tIHRoZSBicmlkZ2UgYnV0
IGZvciB2c3dpdGNoIHdlIGRvCj4gbmVlZCB0byBhY3R1YWxseSBkbyBzb21lIHJlY29uZmlndXJh
dGlvbiBhdCB0aGlzIHBvaW50LiBXZSBhbHNvIGFwcGVhcgo+IHRvIGxlYWsgaXB0YWJsZXMgcnVs
ZXMgdW5kZXIgc29tZSBjaXJjdW1zdGFuY2VzLgo+Cj4gUGVyaGFwcyB3ZSB3b3VsZCBiZSBiZXR0
ZXIgb2ZmIHNwbGl0dGluZyB0aGUgaG90cGx1ZyBzdHVmZiBpbnRvIGl0cyBvd24KPiBwbGFjZSBp
biB4ZW5zdG9yZSBhbmQgaGF2ZSB0aGUgdG9vbHN0YWNrIGV4cGxpY2l0bHkgdHJpZ2dlciBldmVu
dHMgYXQKPiB0aGUgcmlnaHQgdGltZSBieSB3cml0aW5nIHRvIGl0PyBUaGlzIGNvdWxkIGJlIGNv
bXBhdGlibGUgd2l0aCBleGlzdGluZwo+IHNjcmlwdHMgc2luY2UgdGhleSB1c2UgYW4gZW52aXJv
bm1lbnQgdmFyaWFibGUgdG8gZmluZCB0aGVpciB4ZW5zdG9yZQo+IGJhc2UgcGF0aC4KCkN1cnJl
bnRseSB0aGUgb25seSBwb3NzaWJsZSB3YXkgdG8gc3luY2hyb25pemUgeGVuYmFja2VuZCBhbmQg
dGhlCnRvb2xzdGFjayBpcyB0byB3YXRjaCB0aGUgaG90cGx1Zy1zdGF0dXMgeGVuYmFja2VuZCBl
bnRyeSwgSSd2ZSBwb3N0ZWQKYSBwYXRjaCBhIGxvbmcgdGltZSBhZ28sIHRoYXQgdHJpZWQgdG8g
c3luY2hyb25pemUgeGwgYW5kIHhlbmJhY2tlbmQKdXNpbmcgdGhlIGhvdHBsdWctc3RhdHVzIHhl
bnN0b3JlIGVudHJ5LgoKPiBXZSBuZWVkIHRvIGJlIGF3YXJlIHRoYXQgdGhlIHNjcmlwdCBtb2Rl
bHMgKG9yIGF0IGxlYXN0IHRoZSBzZXF1ZW5jaW5nCj4gd3J0IHRoZSB4ZW5zdG9yZSBzdGF0ZSB0
cmFuc2l0aW9ucykgdmFyeSBzbGlnaHRseSB3aXRoIHRoZSBkZXZpY2UgdHlwZQo+IHNpbmNlIGZv
ciBibG9jayBkZXZpY2VzIHlvdSB0eXBpY2FsbHkgbmVlZCB0byBydW4gdGhlIGhvdHBsdWcgc2Ny
aXB0Cj4gYmVmb3JlIGNyZWF0aW5nIHRoZSBiYWNrZW5kIHdoZXJlYXMgd2l0aCBuZXR3b3JrIGRl
dmljZXMgeW91IGNyZWF0ZSB0aGUKPiBkZXZpY2UgZmlyc3QgYW5kIHRoZW4gcnVuIHRoZSBzY3Jp
cHQgdG8gY29uZmlndXJlIGl0LiB2aWNlIHZlcnNhIGZvcgo+IGRlc3Ryb3kuCgpJIHRoaW5rIHRo
YXQgdGhlIGVhc2llciB3YXkgdG8gZGVhbCB3aXRoIGhvdHBsdWcgc2NyaXB0cyBpcyB0byBleGVj
dXRlCnRoZW0gd2hlbiBiYWNrZW5kIHN0YXRlIGlzIDIsIHRoYXQgaXMgdHJ1ZSBmb3IgYm90aCBu
ZXR3b3JrIGFuZCBibG9jawpzY3JpcHRzIChhdCBsZWFzdCBvbiBOZXRCU0QpLgoKPiBXZSBhbHNv
IG5lZWQgdG8gY29uc2lkZXIgTmV0d29yayB0YXAgZGV2aWNlcy4gTm90IGFsbCB0YXAgZGV2aWNl
cyBhcmUKPiBwYXJ0IG9mIFhlbidzIHdvcmxkIHdoaWNoIGlzIGEgd3JpbmtsZSB3aGljaCBuZWVk
cyB0aG91Z2h0Lgo+Cj4gSSB0cmllZCB0byB3cml0ZSBkb3duIG15IHVuZGVyc3RhbmRpbmcgb2Yg
dGhlIGV2ZW50cyBhbmQgc2VxdWVuY2luZwo+IHVuZGVyIExpbnV4IGJ1dCB0aGF0IG1vc3RseSBz
aG93ZWQgdGhlIGdhcHMgaW4gbXkgdW5kZXJzdGFuZGluZy4uLgo+Cj4gQUlVSSBYQ1AgZG9lcyBh
IGxvdCBtb3JlIG9mIHRoaXMgc3R1ZmYgdmlhIHhlbnN0b3JlZCBhbmQgaGF2ZSBiZWVuCj4gKHN1
Y2Nlc3NmdWxseSkgcGxheWluZyB3aXRoIGRyaXZlciBkb21haW5zIC0tIHdlIHNob3VsZCBhc2sg
Zm9yIHRoZWlyCj4gaW5wdXQuCj4KCkFmdGVyIGFsbCB0aGlzLCB3aGF0IHNlZW1zIG1vc3Qgc3Vp
dGFibGUgdG8gbWUgaXMgdG8gaGF2ZSBob3RwbHVnCnNjcmlwdCBjYWxsaW5nIGZ1bmN0aW9ucyBp
bnNpZGUgbGlieGwsIG1vZGlmeSB4ZW5iYWNrZW5kIHRvIHVzZSBsaWJ4bApBUEksIGFuZCBnaXZl
IHRoZSB1c2VyIHRoZSBvcHRpb24gdG8gZXhlY3V0ZSBob3RwbHVnIHNjcmlwdHMgZGlyZWN0bHkK
ZnJvbSB4bCAoY2FsbGluZyBsaWJ4bCBob3RwbHVnIGZ1bmN0aW9ucykgb3IgZGVsZWdhdGUgdGhl
IHdvcmsgdG8KeGVuYmFja2VuZCAod3JpdGluZyBhIHZhbHVlIHRvIHhlbnN0b3JlIHRoYXQgeGVu
YmFja2VuZCBjYW4gdXNlIHRvCnN5bmNocm9uaXplIGFuZCB0cmlnZ2VycyBleGVjdXRpb24pLgoK
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVs
IG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuc291cmNlLmNvbQpodHRwOi8vbGlzdHMu
eGVuc291cmNlLmNvbS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Mon Dec 19 09:28:34 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 09:28:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RcZVv-00008i-Du; Mon, 19 Dec 2011 09:28:07 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <hramrach@gmail.com>) id 1RcZVt-00008d-JV
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 09:28:05 +0000
X-Env-Sender: hramrach@gmail.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1324286877!7992928!1
X-Originating-IP: [209.85.160.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16592 invoked from network); 19 Dec 2011 09:27:59 -0000
Received: from mail-pw0-f43.google.com (HELO mail-pw0-f43.google.com)
	(209.85.160.43)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Dec 2011 09:27:59 -0000
Received: by pbbb11 with SMTP id b11so19527223pbb.30
	for <xen-devel@lists.xensource.com>;
	Mon, 19 Dec 2011 01:27:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:from:date:x-google-sender-auth:message-id
	:subject:to:content-type;
	bh=Z79+tC5KmxHwFyTP/7sxATqiZ4UQ86t0UecHA2ahJ8k=;
	b=MVkFaZBVZtI9fO0FZ9Wjg/GiEYX3eKorhfk/5w67Ec+++eNZij2KJ0pDgcc/bZtpbK
	V3/IzPnhtHYLBOVFeYxxJTqHler2PhcnHXFknAeQWk3wEY5dNajKj55jI6aJL+rnW/lh
	aCoGTWtoMg6rqXLyPqjNxJDhePQhyZej5MowU=
Received: by 10.68.212.200 with SMTP id nm8mr37755927pbc.28.1324286877214;
	Mon, 19 Dec 2011 01:27:57 -0800 (PST)
MIME-Version: 1.0
Received: by 10.143.60.18 with HTTP; Mon, 19 Dec 2011 01:27:36 -0800 (PST)
From: Michal Suchanek <hramrach@centrum.cz>
Date: Mon, 19 Dec 2011 10:27:36 +0100
X-Google-Sender-Auth: tI4ZD4kY2F7ohyJGyo7_mjwQDZ8
Message-ID: <CAOMqctShNFqe47w1orEPMCqvDORy5yxh=Gy33e02fyQYrz4nkw@mail.gmail.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] UDP checksums broken in Dom0 -> DomU vif transfer
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hello,

when I boot DomU which uses DHCP to configure IPv4 address it does
never get a lease.

The packets travel to Dom0 where the dhcp server receives them, sends
a reply, that travels to DomU where dhclient receives it, says the
checksum is invalid, and discards it.

The problem is documented here:

http://old-list-archives.xen.org/archives/html/xen-users/2006-02/msg00152.html
http://old-list-archives.xen.org/archives/html/xen-devel/2011-04/msg01235.html
http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1655

The fix is to turn off UDP checksum offloading on the vif interface in
Dom0 as documented in the above mail:

I edited /etc/xen/scripts/network-bridge,
adding this command to the end of the op_start() function:

        add_to_bridge2 ${bridge} ${pdev}
        do_ifup ${netdev}
+       # disable ip checksum offloading for veth device
+       ethtool -K ${netdev} tx off
    else
        # old style without ${vdev}

Note: I am not sure which path is taken through the script, I set the
parameter manually with ethtool before I found this patch.

It some solutions suggest to turn off UDP checksum offloading in the
DomU as well but it does not seem to be necessary since the packets
would travel to the dhcp server and it would reply to them.

Some people say this is working for them.

I suspect this is because some Linux distributions already carry this patch.

Any reason why this can't be fixed in Xen upstream?

This issue is years old and has been discovered, solved, re-discovered
and re-solved numerous times already.

Thanks

Michal

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 09:28:34 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 09:28:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RcZVv-00008i-Du; Mon, 19 Dec 2011 09:28:07 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <hramrach@gmail.com>) id 1RcZVt-00008d-JV
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 09:28:05 +0000
X-Env-Sender: hramrach@gmail.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1324286877!7992928!1
X-Originating-IP: [209.85.160.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16592 invoked from network); 19 Dec 2011 09:27:59 -0000
Received: from mail-pw0-f43.google.com (HELO mail-pw0-f43.google.com)
	(209.85.160.43)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Dec 2011 09:27:59 -0000
Received: by pbbb11 with SMTP id b11so19527223pbb.30
	for <xen-devel@lists.xensource.com>;
	Mon, 19 Dec 2011 01:27:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:from:date:x-google-sender-auth:message-id
	:subject:to:content-type;
	bh=Z79+tC5KmxHwFyTP/7sxATqiZ4UQ86t0UecHA2ahJ8k=;
	b=MVkFaZBVZtI9fO0FZ9Wjg/GiEYX3eKorhfk/5w67Ec+++eNZij2KJ0pDgcc/bZtpbK
	V3/IzPnhtHYLBOVFeYxxJTqHler2PhcnHXFknAeQWk3wEY5dNajKj55jI6aJL+rnW/lh
	aCoGTWtoMg6rqXLyPqjNxJDhePQhyZej5MowU=
Received: by 10.68.212.200 with SMTP id nm8mr37755927pbc.28.1324286877214;
	Mon, 19 Dec 2011 01:27:57 -0800 (PST)
MIME-Version: 1.0
Received: by 10.143.60.18 with HTTP; Mon, 19 Dec 2011 01:27:36 -0800 (PST)
From: Michal Suchanek <hramrach@centrum.cz>
Date: Mon, 19 Dec 2011 10:27:36 +0100
X-Google-Sender-Auth: tI4ZD4kY2F7ohyJGyo7_mjwQDZ8
Message-ID: <CAOMqctShNFqe47w1orEPMCqvDORy5yxh=Gy33e02fyQYrz4nkw@mail.gmail.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] UDP checksums broken in Dom0 -> DomU vif transfer
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hello,

when I boot DomU which uses DHCP to configure IPv4 address it does
never get a lease.

The packets travel to Dom0 where the dhcp server receives them, sends
a reply, that travels to DomU where dhclient receives it, says the
checksum is invalid, and discards it.

The problem is documented here:

http://old-list-archives.xen.org/archives/html/xen-users/2006-02/msg00152.html
http://old-list-archives.xen.org/archives/html/xen-devel/2011-04/msg01235.html
http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1655

The fix is to turn off UDP checksum offloading on the vif interface in
Dom0 as documented in the above mail:

I edited /etc/xen/scripts/network-bridge,
adding this command to the end of the op_start() function:

        add_to_bridge2 ${bridge} ${pdev}
        do_ifup ${netdev}
+       # disable ip checksum offloading for veth device
+       ethtool -K ${netdev} tx off
    else
        # old style without ${vdev}

Note: I am not sure which path is taken through the script, I set the
parameter manually with ethtool before I found this patch.

It some solutions suggest to turn off UDP checksum offloading in the
DomU as well but it does not seem to be necessary since the packets
would travel to the dhcp server and it would reply to them.

Some people say this is working for them.

I suspect this is because some Linux distributions already carry this patch.

Any reason why this can't be fixed in Xen upstream?

This issue is years old and has been discovered, solved, re-discovered
and re-solved numerous times already.

Thanks

Michal

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 09:48:50 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 09:48:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RcZpY-0000NQ-9G; Mon, 19 Dec 2011 09:48:24 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RcZpX-0000NL-E4
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 09:48:23 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1324288096!7798226!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzA0OQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31312 invoked from network); 19 Dec 2011 09:48:17 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Dec 2011 09:48:17 -0000
X-IronPort-AV: E=Sophos;i="4.71,375,1320624000"; 
   d="scan'208";a="9548452"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Dec 2011 09:48:16 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 19 Dec 2011 09:48:16 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau Monne <roger.pau@entel.upc.edu>
Date: Mon, 19 Dec 2011 09:48:16 +0000
In-Reply-To: <eed78eb655c40b0ac9af.1324212501@alpine.localdomain>
References: <patchbomb.1324212500@alpine.localdomain>
	<eed78eb655c40b0ac9af.1324212501@alpine.localdomain>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1324288096.9236.6.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 1 of 5] blktap: remove HAVE_BYTESWAP_H
 checking, since it's defined by qemu
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Sun, 2011-12-18 at 12:48 +0000, Roger Pau Monne wrote:
> # HG changeset patch
> # User Roger Pau Monne <roger.pau@entel.upc.edu>
> # Date 1324171782 -3600
> # Node ID eed78eb655c40b0ac9af1b14c1cc03204f696b0b
> # Parent  b783e76e63a99c9d87fca4974492f60af99a2e7a
> blktap: remove HAVE_BYTESWAP_H checking, since it's defined by qemu
> 
> blktap was using defines set by qemu, even when the qemu config file
> is not included. Remove this checkings, and instead check if the file
> has been included before defining the necessary macros.
> 
> The output error is:
> 
> In file included from block-qcow.c:37:0:
> bswap.h:23:0: error: "bswap_16" redefined [-Werror]
> /usr/include/byteswap.h:30:0: note: this is the location of the
> previous definition
> bswap.h:31:0: error: "bswap_32" redefined [-Werror]
> /usr/include/byteswap.h:33:0: note: this is the location of the
> previous definition
> bswap.h:41:0: error: "bswap_64" redefined [-Werror]
> /usr/include/byteswap.h:37:0: note: this is the location of the
> previous definition
> cc1: all warnings being treated as errors
> 
> Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>
> 
> diff -r b783e76e63a9 -r eed78eb655c4 tools/blktap/drivers/bswap.h
> --- a/tools/blktap/drivers/bswap.h	Sun Dec 18 02:29:42 2011 +0100
> +++ b/tools/blktap/drivers/bswap.h	Sun Dec 18 02:29:42 2011 +0100
> @@ -15,9 +15,7 @@
>  #define bswap_64(x) swap64(x)
>  #else
>  
> -#ifdef HAVE_BYTESWAP_H
> -#include <byteswap.h>
> -#else
> +#ifndef _BYTESWAP_H

This is basically saying "if the user hasn't already include byteswap.h"
but it seems to rely on that header using the precise guard _BYTESWAP_H
which I presume can differ across platforms. I don't think this is a
viable approach.

Given that we have our own definitions of these things any why not just
remove the ifdef and single the other #include of byteswap.h and always
use the ones we defined?

The other alternative is to remove our own version and always include
byteswap.h.

The right answer depends on how standardised byteswap.h is. It seems to
be in glibc but is it in uclibc and the BSD libcs? I can't find a
definitive reference but it seems like it is specified by POSIX?

Ian.

>  
>  #define bswap_16(x) \
>  ({ \
> @@ -51,7 +49,7 @@
>  		(uint64_t)(((uint64_t)(__x) & (uint64_t)0xff00000000000000ULL) >> 56) )); \
>  })
>  
> -#endif /* !HAVE_BYTESWAP_H */
> +#endif /* !_BYTESWAP_H */
>  
>  static inline uint16_t bswap16(uint16_t x)
>  {
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 09:48:50 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 09:48:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RcZpY-0000NQ-9G; Mon, 19 Dec 2011 09:48:24 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RcZpX-0000NL-E4
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 09:48:23 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1324288096!7798226!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzA0OQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31312 invoked from network); 19 Dec 2011 09:48:17 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Dec 2011 09:48:17 -0000
X-IronPort-AV: E=Sophos;i="4.71,375,1320624000"; 
   d="scan'208";a="9548452"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Dec 2011 09:48:16 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 19 Dec 2011 09:48:16 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau Monne <roger.pau@entel.upc.edu>
Date: Mon, 19 Dec 2011 09:48:16 +0000
In-Reply-To: <eed78eb655c40b0ac9af.1324212501@alpine.localdomain>
References: <patchbomb.1324212500@alpine.localdomain>
	<eed78eb655c40b0ac9af.1324212501@alpine.localdomain>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1324288096.9236.6.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 1 of 5] blktap: remove HAVE_BYTESWAP_H
 checking, since it's defined by qemu
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Sun, 2011-12-18 at 12:48 +0000, Roger Pau Monne wrote:
> # HG changeset patch
> # User Roger Pau Monne <roger.pau@entel.upc.edu>
> # Date 1324171782 -3600
> # Node ID eed78eb655c40b0ac9af1b14c1cc03204f696b0b
> # Parent  b783e76e63a99c9d87fca4974492f60af99a2e7a
> blktap: remove HAVE_BYTESWAP_H checking, since it's defined by qemu
> 
> blktap was using defines set by qemu, even when the qemu config file
> is not included. Remove this checkings, and instead check if the file
> has been included before defining the necessary macros.
> 
> The output error is:
> 
> In file included from block-qcow.c:37:0:
> bswap.h:23:0: error: "bswap_16" redefined [-Werror]
> /usr/include/byteswap.h:30:0: note: this is the location of the
> previous definition
> bswap.h:31:0: error: "bswap_32" redefined [-Werror]
> /usr/include/byteswap.h:33:0: note: this is the location of the
> previous definition
> bswap.h:41:0: error: "bswap_64" redefined [-Werror]
> /usr/include/byteswap.h:37:0: note: this is the location of the
> previous definition
> cc1: all warnings being treated as errors
> 
> Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>
> 
> diff -r b783e76e63a9 -r eed78eb655c4 tools/blktap/drivers/bswap.h
> --- a/tools/blktap/drivers/bswap.h	Sun Dec 18 02:29:42 2011 +0100
> +++ b/tools/blktap/drivers/bswap.h	Sun Dec 18 02:29:42 2011 +0100
> @@ -15,9 +15,7 @@
>  #define bswap_64(x) swap64(x)
>  #else
>  
> -#ifdef HAVE_BYTESWAP_H
> -#include <byteswap.h>
> -#else
> +#ifndef _BYTESWAP_H

This is basically saying "if the user hasn't already include byteswap.h"
but it seems to rely on that header using the precise guard _BYTESWAP_H
which I presume can differ across platforms. I don't think this is a
viable approach.

Given that we have our own definitions of these things any why not just
remove the ifdef and single the other #include of byteswap.h and always
use the ones we defined?

The other alternative is to remove our own version and always include
byteswap.h.

The right answer depends on how standardised byteswap.h is. It seems to
be in glibc but is it in uclibc and the BSD libcs? I can't find a
definitive reference but it seems like it is specified by POSIX?

Ian.

>  
>  #define bswap_16(x) \
>  ({ \
> @@ -51,7 +49,7 @@
>  		(uint64_t)(((uint64_t)(__x) & (uint64_t)0xff00000000000000ULL) >> 56) )); \
>  })
>  
> -#endif /* !HAVE_BYTESWAP_H */
> +#endif /* !_BYTESWAP_H */
>  
>  static inline uint16_t bswap16(uint16_t x)
>  {
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 09:55:17 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 09: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.xensource.com>)
	id 1RcZvp-0000Xi-A1; Mon, 19 Dec 2011 09:54:53 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RcZvn-0000Xd-6c
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 09:54:51 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1324288364!48843391!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzA0OQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28240 invoked from network); 19 Dec 2011 09:52:44 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Dec 2011 09:52:44 -0000
X-IronPort-AV: E=Sophos;i="4.71,375,1320624000"; 
   d="scan'208";a="9548722"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Dec 2011 09:54:50 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 19 Dec 2011 09:54:49 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau Monne <roger.pau@entel.upc.edu>
Date: Mon, 19 Dec 2011 09:54:49 +0000
In-Reply-To: <6780cbdfa64b148b0c37.1324212505@alpine.localdomain>
References: <patchbomb.1324212500@alpine.localdomain>
	<6780cbdfa64b148b0c37.1324212505@alpine.localdomain>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1324288489.9236.9.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 5 of 5] libxl: fix link issue on uclibc when
 using yajl
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Sun, 2011-12-18 at 12:48 +0000, Roger Pau Monne wrote:
> # HG changeset patch
> # User Roger Pau Monne <roger.pau@entel.upc.edu>
> # Date 1324171782 -3600
> # Node ID 6780cbdfa64b148b0c372a4f82448f707ad2be59
> # Parent  7bcb3a61ce8846f8e7834d14c460c0f4b4869222
> libxl: fix link issue on uclibc when using yajl
> 
> yajl makes use of the isnan isinf functions. On Glibc, these are
> provided by libc, but on uClibc you need to link with -lm (like the
> spec says), so ensure we do so.

If libyajl needs those symbols then it should link against libm itself
and not rely ion the application to do so. There should be no need for
an application using liyajl to do this itself when linking dynamically.

I suspect this is a bug in libyajl.

(if adding -lm were correct then it would be better to just do it
unconditionally)

Ian.

> 
> Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>
> 
> diff -r 7bcb3a61ce88 -r 6780cbdfa64b tools/libxl/Makefile
> --- a/tools/libxl/Makefile	Sun Dec 18 02:29:42 2011 +0100
> +++ b/tools/libxl/Makefile	Sun Dec 18 02:29:42 2011 +0100
> @@ -24,6 +24,10 @@ LIBXL_LIBS = $(LDLIBS_libxenctrl) $(LDLI
>  
>  LIBXLU_LIBS =
>  
> +XL_LIBS =
> +
> +TESTIDL_LIBS =
> +
>  LIBXL_OBJS-y = osdeps.o libxl_paths.o libxl_bootloader.o flexarray.o
>  ifeq ($(LIBXL_BLKTAP),y)
>  LIBXL_OBJS-y += libxl_blktap2.o
> @@ -35,6 +39,12 @@ LIBXL_OBJS-$(CONFIG_IA64) += libxl_nocpu
>  
>  LIBXL_LIBS += -lyajl
>  
> +ifeq ($(CONFIG_UCLIBC),y)
> +LIBXL_LIBS += -lm
> +XL_LIBS += -lm
> +TESTIDL_LIBS += -lm
> +endif
> +
>  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 \
> @@ -127,10 +137,10 @@ libxlutil.a: $(LIBXLU_OBJS)
>  	$(AR) rcs libxlutil.a $^
>  
>  xl: $(XL_OBJS) libxlutil.so libxenlight.so
> -	$(CC) $(LDFLAGS) -o $@ $(XL_OBJS) libxlutil.so $(LDLIBS_libxenlight) $(LDLIBS_libxenctrl) $(APPEND_LDFLAGS)
> +	$(CC) $(LDFLAGS) -o $@ $(XL_OBJS) libxlutil.so $(LDLIBS_libxenlight) $(LDLIBS_libxenctrl) $(XL_LIBS) $(APPEND_LDFLAGS)
>  
>  testidl: testidl.o libxlutil.so libxenlight.so
> -	$(CC) $(LDFLAGS) -o $@ testidl.o libxlutil.so $(LDLIBS_libxenlight) $(LDLIBS_libxenctrl) $(APPEND_LDFLAGS)
> +	$(CC) $(LDFLAGS) -o $@ testidl.o libxlutil.so $(LDLIBS_libxenlight) $(LDLIBS_libxenctrl) $(TESTIDL_LIBS) $(APPEND_LDFLAGS)
>  
>  .PHONY: install
>  install: all
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 09:55:17 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 09: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.xensource.com>)
	id 1RcZvp-0000Xi-A1; Mon, 19 Dec 2011 09:54:53 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RcZvn-0000Xd-6c
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 09:54:51 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1324288364!48843391!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzA0OQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28240 invoked from network); 19 Dec 2011 09:52:44 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Dec 2011 09:52:44 -0000
X-IronPort-AV: E=Sophos;i="4.71,375,1320624000"; 
   d="scan'208";a="9548722"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Dec 2011 09:54:50 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 19 Dec 2011 09:54:49 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau Monne <roger.pau@entel.upc.edu>
Date: Mon, 19 Dec 2011 09:54:49 +0000
In-Reply-To: <6780cbdfa64b148b0c37.1324212505@alpine.localdomain>
References: <patchbomb.1324212500@alpine.localdomain>
	<6780cbdfa64b148b0c37.1324212505@alpine.localdomain>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1324288489.9236.9.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 5 of 5] libxl: fix link issue on uclibc when
 using yajl
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Sun, 2011-12-18 at 12:48 +0000, Roger Pau Monne wrote:
> # HG changeset patch
> # User Roger Pau Monne <roger.pau@entel.upc.edu>
> # Date 1324171782 -3600
> # Node ID 6780cbdfa64b148b0c372a4f82448f707ad2be59
> # Parent  7bcb3a61ce8846f8e7834d14c460c0f4b4869222
> libxl: fix link issue on uclibc when using yajl
> 
> yajl makes use of the isnan isinf functions. On Glibc, these are
> provided by libc, but on uClibc you need to link with -lm (like the
> spec says), so ensure we do so.

If libyajl needs those symbols then it should link against libm itself
and not rely ion the application to do so. There should be no need for
an application using liyajl to do this itself when linking dynamically.

I suspect this is a bug in libyajl.

(if adding -lm were correct then it would be better to just do it
unconditionally)

Ian.

> 
> Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>
> 
> diff -r 7bcb3a61ce88 -r 6780cbdfa64b tools/libxl/Makefile
> --- a/tools/libxl/Makefile	Sun Dec 18 02:29:42 2011 +0100
> +++ b/tools/libxl/Makefile	Sun Dec 18 02:29:42 2011 +0100
> @@ -24,6 +24,10 @@ LIBXL_LIBS = $(LDLIBS_libxenctrl) $(LDLI
>  
>  LIBXLU_LIBS =
>  
> +XL_LIBS =
> +
> +TESTIDL_LIBS =
> +
>  LIBXL_OBJS-y = osdeps.o libxl_paths.o libxl_bootloader.o flexarray.o
>  ifeq ($(LIBXL_BLKTAP),y)
>  LIBXL_OBJS-y += libxl_blktap2.o
> @@ -35,6 +39,12 @@ LIBXL_OBJS-$(CONFIG_IA64) += libxl_nocpu
>  
>  LIBXL_LIBS += -lyajl
>  
> +ifeq ($(CONFIG_UCLIBC),y)
> +LIBXL_LIBS += -lm
> +XL_LIBS += -lm
> +TESTIDL_LIBS += -lm
> +endif
> +
>  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 \
> @@ -127,10 +137,10 @@ libxlutil.a: $(LIBXLU_OBJS)
>  	$(AR) rcs libxlutil.a $^
>  
>  xl: $(XL_OBJS) libxlutil.so libxenlight.so
> -	$(CC) $(LDFLAGS) -o $@ $(XL_OBJS) libxlutil.so $(LDLIBS_libxenlight) $(LDLIBS_libxenctrl) $(APPEND_LDFLAGS)
> +	$(CC) $(LDFLAGS) -o $@ $(XL_OBJS) libxlutil.so $(LDLIBS_libxenlight) $(LDLIBS_libxenctrl) $(XL_LIBS) $(APPEND_LDFLAGS)
>  
>  testidl: testidl.o libxlutil.so libxenlight.so
> -	$(CC) $(LDFLAGS) -o $@ testidl.o libxlutil.so $(LDLIBS_libxenlight) $(LDLIBS_libxenctrl) $(APPEND_LDFLAGS)
> +	$(CC) $(LDFLAGS) -o $@ testidl.o libxlutil.so $(LDLIBS_libxenlight) $(LDLIBS_libxenctrl) $(TESTIDL_LIBS) $(APPEND_LDFLAGS)
>  
>  .PHONY: install
>  install: all
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 09:59:05 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 09:59:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RcZzW-0000fL-Ut; Mon, 19 Dec 2011 09:58:42 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RcZzW-0000f8-Gn
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 09:58:42 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1324288675!47275505!1
X-Originating-IP: [209.85.160.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6846 invoked from network); 19 Dec 2011 09:57:57 -0000
Received: from mail-pw0-f43.google.com (HELO mail-pw0-f43.google.com)
	(209.85.160.43)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Dec 2011 09:57:57 -0000
Received: by pbbb11 with SMTP id b11so19591573pbb.30
	for <xen-devel@lists.xensource.com>;
	Mon, 19 Dec 2011 01:58:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=eZw/U7OLowG2AM+E9TA4Y9vZdkbxWV699Zw7nK3Cx7k=;
	b=SOe1ZRdEJtfc0+b6fZ+Skg/3MSBpo656L/z/GOFDzWFVlz8qJEOJxlmK6lIY7K4MAJ
	fcHyi7PNXNRnqel1cSrf/IO9eQc8MZDpNb3p+FFhYAijSSq6UdbW1/+zQ8vSizKD7am/
	37cPgCtWg3QdqgLIbh7homZNTSr4f4IFigOnA=
MIME-Version: 1.0
Received: by 10.68.190.226 with SMTP id gt2mr4208537pbc.112.1324288716192;
	Mon, 19 Dec 2011 01:58:36 -0800 (PST)
Received: by 10.142.47.17 with HTTP; Mon, 19 Dec 2011 01:58:36 -0800 (PST)
In-Reply-To: <1324288096.9236.6.camel@zakaz.uk.xensource.com>
References: <patchbomb.1324212500@alpine.localdomain>
	<eed78eb655c40b0ac9af.1324212501@alpine.localdomain>
	<1324288096.9236.6.camel@zakaz.uk.xensource.com>
Date: Mon, 19 Dec 2011 10:58:36 +0100
X-Google-Sender-Auth: ZhrJ5BVBE2jFfXyzvHasDw7n5qc
Message-ID: <CAPLaKK7gEUv9bavavzyYjREPDZJepMkK+-Ap78xzHjPy4SvZ3g@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 1 of 5] blktap: remove HAVE_BYTESWAP_H
 checking, since it's defined by qemu
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

MjAxMS8xMi8xOSBJYW4gQ2FtcGJlbGwgPElhbi5DYW1wYmVsbEBjaXRyaXguY29tPjoKPiBPbiBT
dW4sIDIwMTEtMTItMTggYXQgMTI6NDggKzAwMDAsIFJvZ2VyIFBhdSBNb25uZSB3cm90ZToKPj4g
IyBIRyBjaGFuZ2VzZXQgcGF0Y2gKPj4gIyBVc2VyIFJvZ2VyIFBhdSBNb25uZSA8cm9nZXIucGF1
QGVudGVsLnVwYy5lZHU+Cj4+ICMgRGF0ZSAxMzI0MTcxNzgyIC0zNjAwCj4+ICMgTm9kZSBJRCBl
ZWQ3OGViNjU1YzQwYjBhYzlhZjFiMTRjMWNjMDMyMDRmNjk2YjBiCj4+ICMgUGFyZW50IMKgYjc4
M2U3NmU2M2E5OWM5ZDg3ZmNhNDk3NDQ5MmY2MGFmOTlhMmU3YQo+PiBibGt0YXA6IHJlbW92ZSBI
QVZFX0JZVEVTV0FQX0ggY2hlY2tpbmcsIHNpbmNlIGl0J3MgZGVmaW5lZCBieSBxZW11Cj4+Cj4+
IGJsa3RhcCB3YXMgdXNpbmcgZGVmaW5lcyBzZXQgYnkgcWVtdSwgZXZlbiB3aGVuIHRoZSBxZW11
IGNvbmZpZyBmaWxlCj4+IGlzIG5vdCBpbmNsdWRlZC4gUmVtb3ZlIHRoaXMgY2hlY2tpbmdzLCBh
bmQgaW5zdGVhZCBjaGVjayBpZiB0aGUgZmlsZQo+PiBoYXMgYmVlbiBpbmNsdWRlZCBiZWZvcmUg
ZGVmaW5pbmcgdGhlIG5lY2Vzc2FyeSBtYWNyb3MuCj4+Cj4+IFRoZSBvdXRwdXQgZXJyb3IgaXM6
Cj4+Cj4+IEluIGZpbGUgaW5jbHVkZWQgZnJvbSBibG9jay1xY293LmM6Mzc6MDoKPj4gYnN3YXAu
aDoyMzowOiBlcnJvcjogImJzd2FwXzE2IiByZWRlZmluZWQgWy1XZXJyb3JdCj4+IC91c3IvaW5j
bHVkZS9ieXRlc3dhcC5oOjMwOjA6IG5vdGU6IHRoaXMgaXMgdGhlIGxvY2F0aW9uIG9mIHRoZQo+
PiBwcmV2aW91cyBkZWZpbml0aW9uCj4+IGJzd2FwLmg6MzE6MDogZXJyb3I6ICJic3dhcF8zMiIg
cmVkZWZpbmVkIFstV2Vycm9yXQo+PiAvdXNyL2luY2x1ZGUvYnl0ZXN3YXAuaDozMzowOiBub3Rl
OiB0aGlzIGlzIHRoZSBsb2NhdGlvbiBvZiB0aGUKPj4gcHJldmlvdXMgZGVmaW5pdGlvbgo+PiBi
c3dhcC5oOjQxOjA6IGVycm9yOiAiYnN3YXBfNjQiIHJlZGVmaW5lZCBbLVdlcnJvcl0KPj4gL3Vz
ci9pbmNsdWRlL2J5dGVzd2FwLmg6Mzc6MDogbm90ZTogdGhpcyBpcyB0aGUgbG9jYXRpb24gb2Yg
dGhlCj4+IHByZXZpb3VzIGRlZmluaXRpb24KPj4gY2MxOiBhbGwgd2FybmluZ3MgYmVpbmcgdHJl
YXRlZCBhcyBlcnJvcnMKPj4KPj4gU2lnbmVkLW9mZi1ieTogUm9nZXIgUGF1IE1vbm5lIDxyb2dl
ci5wYXVAZW50ZWwudXBjLmVkdT4KPj4KPj4gZGlmZiAtciBiNzgzZTc2ZTYzYTkgLXIgZWVkNzhl
YjY1NWM0IHRvb2xzL2Jsa3RhcC9kcml2ZXJzL2Jzd2FwLmgKPj4gLS0tIGEvdG9vbHMvYmxrdGFw
L2RyaXZlcnMvYnN3YXAuaCDCoCDCoFN1biBEZWMgMTggMDI6Mjk6NDIgMjAxMSArMDEwMAo+PiAr
KysgYi90b29scy9ibGt0YXAvZHJpdmVycy9ic3dhcC5oIMKgIMKgU3VuIERlYyAxOCAwMjoyOTo0
MiAyMDExICswMTAwCj4+IEBAIC0xNSw5ICsxNSw3IEBACj4+IMKgI2RlZmluZSBic3dhcF82NCh4
KSBzd2FwNjQoeCkKPj4gwqAjZWxzZQo+Pgo+PiAtI2lmZGVmIEhBVkVfQllURVNXQVBfSAo+PiAt
I2luY2x1ZGUgPGJ5dGVzd2FwLmg+Cj4+IC0jZWxzZQo+PiArI2lmbmRlZiBfQllURVNXQVBfSAo+
Cj4gVGhpcyBpcyBiYXNpY2FsbHkgc2F5aW5nICJpZiB0aGUgdXNlciBoYXNuJ3QgYWxyZWFkeSBp
bmNsdWRlIGJ5dGVzd2FwLmgiCj4gYnV0IGl0IHNlZW1zIHRvIHJlbHkgb24gdGhhdCBoZWFkZXIg
dXNpbmcgdGhlIHByZWNpc2UgZ3VhcmQgX0JZVEVTV0FQX0gKPiB3aGljaCBJIHByZXN1bWUgY2Fu
IGRpZmZlciBhY3Jvc3MgcGxhdGZvcm1zLiBJIGRvbid0IHRoaW5rIHRoaXMgaXMgYQo+IHZpYWJs
ZSBhcHByb2FjaC4KCkZyb20gd2hhdCBJIHNhdyBfQllURVNXQVBfSCBpcyBkZWZpbmVkIGluIHVj
bGliYyBhbmQgZ2xpYmMgKFNvbGFyaXMKYW5kIE5ldEJTRCBoYXZlIHRoZWlyIG93biBwcmVwcm9j
ZXNzb3IgbG9naWMsIHNvIHRoaXMgZG9lc24ndCBhcHBseSB0bwp0aGVtKS4gSXQncyBqdXN0IGEg
c2FmZWd1YXJkIHRoYXQgYXZvaWRzIHJlZGVmaW5pbmcgdGhlIG1hY3JvcyBpZgpzb21lb25lIGhh
cyBpbmNsdWRlZCBieXRlc3dhcC5oIGJlaGluZCBvdXIgYmFja3MuCgo+IEdpdmVuIHRoYXQgd2Ug
aGF2ZSBvdXIgb3duIGRlZmluaXRpb25zIG9mIHRoZXNlIHRoaW5ncyBhbnkgd2h5IG5vdCBqdXN0
Cj4gcmVtb3ZlIHRoZSBpZmRlZiBhbmQgc2luZ2xlIHRoZSBvdGhlciAjaW5jbHVkZSBvZiBieXRl
c3dhcC5oIGFuZCBhbHdheXMKPiB1c2UgdGhlIG9uZXMgd2UgZGVmaW5lZD8KPgo+IFRoZSBvdGhl
ciBhbHRlcm5hdGl2ZSBpcyB0byByZW1vdmUgb3VyIG93biB2ZXJzaW9uIGFuZCBhbHdheXMgaW5j
bHVkZQo+IGJ5dGVzd2FwLmguCj4KPiBUaGUgcmlnaHQgYW5zd2VyIGRlcGVuZHMgb24gaG93IHN0
YW5kYXJkaXNlZCBieXRlc3dhcC5oIGlzLiBJdCBzZWVtcyB0bwo+IGJlIGluIGdsaWJjIGJ1dCBp
cyBpdCBpbiB1Y2xpYmMgYW5kIHRoZSBCU0QgbGliY3M/IEkgY2FuJ3QgZmluZCBhCj4gZGVmaW5p
dGl2ZSByZWZlcmVuY2UgYnV0IGl0IHNlZW1zIGxpa2UgaXQgaXMgc3BlY2lmaWVkIGJ5IFBPU0lY
PwoKVGhlIHNvbHV0aW9ucyBJIHNlZSBhcmU6CgogKiBDaGVjayBpZiBieXRlc3dhcC5oIGhhcyBi
ZWVuIGluY2x1ZGVkICh0aGlzIHBhdGNoKS4KICogdW5kZWYgYnN3YXBfKiBmdW5jdGlvbnMgYW5k
IGRlZmluZSBvdXIgb3duLgogKiBJbmNsdWRlIGJ5dGVzd2FwLmguCgpfX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhl
bi1kZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tCmh0dHA6Ly9saXN0cy54ZW5zb3VyY2UuY29tL3hl
bi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Mon Dec 19 09:59:05 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 09:59:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RcZzW-0000fL-Ut; Mon, 19 Dec 2011 09:58:42 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RcZzW-0000f8-Gn
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 09:58:42 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1324288675!47275505!1
X-Originating-IP: [209.85.160.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6846 invoked from network); 19 Dec 2011 09:57:57 -0000
Received: from mail-pw0-f43.google.com (HELO mail-pw0-f43.google.com)
	(209.85.160.43)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Dec 2011 09:57:57 -0000
Received: by pbbb11 with SMTP id b11so19591573pbb.30
	for <xen-devel@lists.xensource.com>;
	Mon, 19 Dec 2011 01:58:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=eZw/U7OLowG2AM+E9TA4Y9vZdkbxWV699Zw7nK3Cx7k=;
	b=SOe1ZRdEJtfc0+b6fZ+Skg/3MSBpo656L/z/GOFDzWFVlz8qJEOJxlmK6lIY7K4MAJ
	fcHyi7PNXNRnqel1cSrf/IO9eQc8MZDpNb3p+FFhYAijSSq6UdbW1/+zQ8vSizKD7am/
	37cPgCtWg3QdqgLIbh7homZNTSr4f4IFigOnA=
MIME-Version: 1.0
Received: by 10.68.190.226 with SMTP id gt2mr4208537pbc.112.1324288716192;
	Mon, 19 Dec 2011 01:58:36 -0800 (PST)
Received: by 10.142.47.17 with HTTP; Mon, 19 Dec 2011 01:58:36 -0800 (PST)
In-Reply-To: <1324288096.9236.6.camel@zakaz.uk.xensource.com>
References: <patchbomb.1324212500@alpine.localdomain>
	<eed78eb655c40b0ac9af.1324212501@alpine.localdomain>
	<1324288096.9236.6.camel@zakaz.uk.xensource.com>
Date: Mon, 19 Dec 2011 10:58:36 +0100
X-Google-Sender-Auth: ZhrJ5BVBE2jFfXyzvHasDw7n5qc
Message-ID: <CAPLaKK7gEUv9bavavzyYjREPDZJepMkK+-Ap78xzHjPy4SvZ3g@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 1 of 5] blktap: remove HAVE_BYTESWAP_H
 checking, since it's defined by qemu
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

MjAxMS8xMi8xOSBJYW4gQ2FtcGJlbGwgPElhbi5DYW1wYmVsbEBjaXRyaXguY29tPjoKPiBPbiBT
dW4sIDIwMTEtMTItMTggYXQgMTI6NDggKzAwMDAsIFJvZ2VyIFBhdSBNb25uZSB3cm90ZToKPj4g
IyBIRyBjaGFuZ2VzZXQgcGF0Y2gKPj4gIyBVc2VyIFJvZ2VyIFBhdSBNb25uZSA8cm9nZXIucGF1
QGVudGVsLnVwYy5lZHU+Cj4+ICMgRGF0ZSAxMzI0MTcxNzgyIC0zNjAwCj4+ICMgTm9kZSBJRCBl
ZWQ3OGViNjU1YzQwYjBhYzlhZjFiMTRjMWNjMDMyMDRmNjk2YjBiCj4+ICMgUGFyZW50IMKgYjc4
M2U3NmU2M2E5OWM5ZDg3ZmNhNDk3NDQ5MmY2MGFmOTlhMmU3YQo+PiBibGt0YXA6IHJlbW92ZSBI
QVZFX0JZVEVTV0FQX0ggY2hlY2tpbmcsIHNpbmNlIGl0J3MgZGVmaW5lZCBieSBxZW11Cj4+Cj4+
IGJsa3RhcCB3YXMgdXNpbmcgZGVmaW5lcyBzZXQgYnkgcWVtdSwgZXZlbiB3aGVuIHRoZSBxZW11
IGNvbmZpZyBmaWxlCj4+IGlzIG5vdCBpbmNsdWRlZC4gUmVtb3ZlIHRoaXMgY2hlY2tpbmdzLCBh
bmQgaW5zdGVhZCBjaGVjayBpZiB0aGUgZmlsZQo+PiBoYXMgYmVlbiBpbmNsdWRlZCBiZWZvcmUg
ZGVmaW5pbmcgdGhlIG5lY2Vzc2FyeSBtYWNyb3MuCj4+Cj4+IFRoZSBvdXRwdXQgZXJyb3IgaXM6
Cj4+Cj4+IEluIGZpbGUgaW5jbHVkZWQgZnJvbSBibG9jay1xY293LmM6Mzc6MDoKPj4gYnN3YXAu
aDoyMzowOiBlcnJvcjogImJzd2FwXzE2IiByZWRlZmluZWQgWy1XZXJyb3JdCj4+IC91c3IvaW5j
bHVkZS9ieXRlc3dhcC5oOjMwOjA6IG5vdGU6IHRoaXMgaXMgdGhlIGxvY2F0aW9uIG9mIHRoZQo+
PiBwcmV2aW91cyBkZWZpbml0aW9uCj4+IGJzd2FwLmg6MzE6MDogZXJyb3I6ICJic3dhcF8zMiIg
cmVkZWZpbmVkIFstV2Vycm9yXQo+PiAvdXNyL2luY2x1ZGUvYnl0ZXN3YXAuaDozMzowOiBub3Rl
OiB0aGlzIGlzIHRoZSBsb2NhdGlvbiBvZiB0aGUKPj4gcHJldmlvdXMgZGVmaW5pdGlvbgo+PiBi
c3dhcC5oOjQxOjA6IGVycm9yOiAiYnN3YXBfNjQiIHJlZGVmaW5lZCBbLVdlcnJvcl0KPj4gL3Vz
ci9pbmNsdWRlL2J5dGVzd2FwLmg6Mzc6MDogbm90ZTogdGhpcyBpcyB0aGUgbG9jYXRpb24gb2Yg
dGhlCj4+IHByZXZpb3VzIGRlZmluaXRpb24KPj4gY2MxOiBhbGwgd2FybmluZ3MgYmVpbmcgdHJl
YXRlZCBhcyBlcnJvcnMKPj4KPj4gU2lnbmVkLW9mZi1ieTogUm9nZXIgUGF1IE1vbm5lIDxyb2dl
ci5wYXVAZW50ZWwudXBjLmVkdT4KPj4KPj4gZGlmZiAtciBiNzgzZTc2ZTYzYTkgLXIgZWVkNzhl
YjY1NWM0IHRvb2xzL2Jsa3RhcC9kcml2ZXJzL2Jzd2FwLmgKPj4gLS0tIGEvdG9vbHMvYmxrdGFw
L2RyaXZlcnMvYnN3YXAuaCDCoCDCoFN1biBEZWMgMTggMDI6Mjk6NDIgMjAxMSArMDEwMAo+PiAr
KysgYi90b29scy9ibGt0YXAvZHJpdmVycy9ic3dhcC5oIMKgIMKgU3VuIERlYyAxOCAwMjoyOTo0
MiAyMDExICswMTAwCj4+IEBAIC0xNSw5ICsxNSw3IEBACj4+IMKgI2RlZmluZSBic3dhcF82NCh4
KSBzd2FwNjQoeCkKPj4gwqAjZWxzZQo+Pgo+PiAtI2lmZGVmIEhBVkVfQllURVNXQVBfSAo+PiAt
I2luY2x1ZGUgPGJ5dGVzd2FwLmg+Cj4+IC0jZWxzZQo+PiArI2lmbmRlZiBfQllURVNXQVBfSAo+
Cj4gVGhpcyBpcyBiYXNpY2FsbHkgc2F5aW5nICJpZiB0aGUgdXNlciBoYXNuJ3QgYWxyZWFkeSBp
bmNsdWRlIGJ5dGVzd2FwLmgiCj4gYnV0IGl0IHNlZW1zIHRvIHJlbHkgb24gdGhhdCBoZWFkZXIg
dXNpbmcgdGhlIHByZWNpc2UgZ3VhcmQgX0JZVEVTV0FQX0gKPiB3aGljaCBJIHByZXN1bWUgY2Fu
IGRpZmZlciBhY3Jvc3MgcGxhdGZvcm1zLiBJIGRvbid0IHRoaW5rIHRoaXMgaXMgYQo+IHZpYWJs
ZSBhcHByb2FjaC4KCkZyb20gd2hhdCBJIHNhdyBfQllURVNXQVBfSCBpcyBkZWZpbmVkIGluIHVj
bGliYyBhbmQgZ2xpYmMgKFNvbGFyaXMKYW5kIE5ldEJTRCBoYXZlIHRoZWlyIG93biBwcmVwcm9j
ZXNzb3IgbG9naWMsIHNvIHRoaXMgZG9lc24ndCBhcHBseSB0bwp0aGVtKS4gSXQncyBqdXN0IGEg
c2FmZWd1YXJkIHRoYXQgYXZvaWRzIHJlZGVmaW5pbmcgdGhlIG1hY3JvcyBpZgpzb21lb25lIGhh
cyBpbmNsdWRlZCBieXRlc3dhcC5oIGJlaGluZCBvdXIgYmFja3MuCgo+IEdpdmVuIHRoYXQgd2Ug
aGF2ZSBvdXIgb3duIGRlZmluaXRpb25zIG9mIHRoZXNlIHRoaW5ncyBhbnkgd2h5IG5vdCBqdXN0
Cj4gcmVtb3ZlIHRoZSBpZmRlZiBhbmQgc2luZ2xlIHRoZSBvdGhlciAjaW5jbHVkZSBvZiBieXRl
c3dhcC5oIGFuZCBhbHdheXMKPiB1c2UgdGhlIG9uZXMgd2UgZGVmaW5lZD8KPgo+IFRoZSBvdGhl
ciBhbHRlcm5hdGl2ZSBpcyB0byByZW1vdmUgb3VyIG93biB2ZXJzaW9uIGFuZCBhbHdheXMgaW5j
bHVkZQo+IGJ5dGVzd2FwLmguCj4KPiBUaGUgcmlnaHQgYW5zd2VyIGRlcGVuZHMgb24gaG93IHN0
YW5kYXJkaXNlZCBieXRlc3dhcC5oIGlzLiBJdCBzZWVtcyB0bwo+IGJlIGluIGdsaWJjIGJ1dCBp
cyBpdCBpbiB1Y2xpYmMgYW5kIHRoZSBCU0QgbGliY3M/IEkgY2FuJ3QgZmluZCBhCj4gZGVmaW5p
dGl2ZSByZWZlcmVuY2UgYnV0IGl0IHNlZW1zIGxpa2UgaXQgaXMgc3BlY2lmaWVkIGJ5IFBPU0lY
PwoKVGhlIHNvbHV0aW9ucyBJIHNlZSBhcmU6CgogKiBDaGVjayBpZiBieXRlc3dhcC5oIGhhcyBi
ZWVuIGluY2x1ZGVkICh0aGlzIHBhdGNoKS4KICogdW5kZWYgYnN3YXBfKiBmdW5jdGlvbnMgYW5k
IGRlZmluZSBvdXIgb3duLgogKiBJbmNsdWRlIGJ5dGVzd2FwLmguCgpfX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhl
bi1kZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tCmh0dHA6Ly9saXN0cy54ZW5zb3VyY2UuY29tL3hl
bi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Mon Dec 19 10:00:19 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 10:00:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rca0h-0000kC-E7; Mon, 19 Dec 2011 09:59:55 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <nenolod@dereferenced.org>) id 1Rca0f-0000jA-Rz
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 09:59:54 +0000
X-Env-Sender: nenolod@dereferenced.org
X-Msg-Ref: server-16.tower-216.messagelabs.com!1324288635!7846958!1
X-Originating-IP: [209.85.210.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23974 invoked from network); 19 Dec 2011 09:57:17 -0000
Received: from mail-pz0-f43.google.com (HELO mail-pz0-f43.google.com)
	(209.85.210.43)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Dec 2011 09:57:17 -0000
Received: by daec6 with SMTP id c6so24917416dae.30
	for <xen-devel@lists.xensource.com>;
	Mon, 19 Dec 2011 01:57:14 -0800 (PST)
MIME-Version: 1.0
Received: by 10.68.73.105 with SMTP id k9mr37331032pbv.121.1324288634457; Mon,
	19 Dec 2011 01:57:14 -0800 (PST)
Received: by 10.143.142.18 with HTTP; Mon, 19 Dec 2011 01:57:14 -0800 (PST)
In-Reply-To: <1324288096.9236.6.camel@zakaz.uk.xensource.com>
References: <patchbomb.1324212500@alpine.localdomain>
	<eed78eb655c40b0ac9af.1324212501@alpine.localdomain>
	<1324288096.9236.6.camel@zakaz.uk.xensource.com>
Date: Mon, 19 Dec 2011 03:57:14 -0600
Message-ID: <CA+T2pCHkJW=Lv0GqnL3B+o9JqUXdnB9CArkpRLRqS8t3v4AHoQ@mail.gmail.com>
From: William Pitcock <nenolod@dereferenced.org>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Roger Pau Monne <roger.pau@entel.upc.edu>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 1 of 5] blktap: remove HAVE_BYTESWAP_H
 checking, since it's defined by qemu
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi,

On Mon, Dec 19, 2011 at 3:48 AM, Ian Campbell <Ian.Campbell@citrix.com> wro=
te:
> On Sun, 2011-12-18 at 12:48 +0000, Roger Pau Monne wrote:
>> # HG changeset patch
>> # User Roger Pau Monne <roger.pau@entel.upc.edu>
>> # Date 1324171782 -3600
>> # Node ID eed78eb655c40b0ac9af1b14c1cc03204f696b0b
>> # Parent =A0b783e76e63a99c9d87fca4974492f60af99a2e7a
>> blktap: remove HAVE_BYTESWAP_H checking, since it's defined by qemu
>>
>> blktap was using defines set by qemu, even when the qemu config file
>> is not included. Remove this checkings, and instead check if the file
>> has been included before defining the necessary macros.
>>
>> The output error is:
>>
>> In file included from block-qcow.c:37:0:
>> bswap.h:23:0: error: "bswap_16" redefined [-Werror]
>> /usr/include/byteswap.h:30:0: note: this is the location of the
>> previous definition
>> bswap.h:31:0: error: "bswap_32" redefined [-Werror]
>> /usr/include/byteswap.h:33:0: note: this is the location of the
>> previous definition
>> bswap.h:41:0: error: "bswap_64" redefined [-Werror]
>> /usr/include/byteswap.h:37:0: note: this is the location of the
>> previous definition
>> cc1: all warnings being treated as errors
>>
>> Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>
>>
>> diff -r b783e76e63a9 -r eed78eb655c4 tools/blktap/drivers/bswap.h
>> --- a/tools/blktap/drivers/bswap.h =A0 =A0Sun Dec 18 02:29:42 2011 +0100
>> +++ b/tools/blktap/drivers/bswap.h =A0 =A0Sun Dec 18 02:29:42 2011 +0100
>> @@ -15,9 +15,7 @@
>> =A0#define bswap_64(x) swap64(x)
>> =A0#else
>>
>> -#ifdef HAVE_BYTESWAP_H
>> -#include <byteswap.h>
>> -#else
>> +#ifndef _BYTESWAP_H
>
> This is basically saying "if the user hasn't already include byteswap.h"
> but it seems to rely on that header using the precise guard _BYTESWAP_H
> which I presume can differ across platforms. I don't think this is a
> viable approach.
>
> Given that we have our own definitions of these things any why not just
> remove the ifdef and single the other #include of byteswap.h and always
> use the ones we defined?
>
> The other alternative is to remove our own version and always include
> byteswap.h.
>
> The right answer depends on how standardised byteswap.h is. It seems to
> be in glibc but is it in uclibc and the BSD libcs? I can't find a
> definitive reference but it seems like it is specified by POSIX?

uClibc 0.9.32 and later have byteswap.h.  Not sure about earlier versions.
byteswap.h is a GNU-ism though, and not in any of the BSDs as a result.

We should just ship these definitions directly in Xen and not depend on it.

William

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 10:00:19 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 10:00:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rca0h-0000kC-E7; Mon, 19 Dec 2011 09:59:55 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <nenolod@dereferenced.org>) id 1Rca0f-0000jA-Rz
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 09:59:54 +0000
X-Env-Sender: nenolod@dereferenced.org
X-Msg-Ref: server-16.tower-216.messagelabs.com!1324288635!7846958!1
X-Originating-IP: [209.85.210.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23974 invoked from network); 19 Dec 2011 09:57:17 -0000
Received: from mail-pz0-f43.google.com (HELO mail-pz0-f43.google.com)
	(209.85.210.43)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Dec 2011 09:57:17 -0000
Received: by daec6 with SMTP id c6so24917416dae.30
	for <xen-devel@lists.xensource.com>;
	Mon, 19 Dec 2011 01:57:14 -0800 (PST)
MIME-Version: 1.0
Received: by 10.68.73.105 with SMTP id k9mr37331032pbv.121.1324288634457; Mon,
	19 Dec 2011 01:57:14 -0800 (PST)
Received: by 10.143.142.18 with HTTP; Mon, 19 Dec 2011 01:57:14 -0800 (PST)
In-Reply-To: <1324288096.9236.6.camel@zakaz.uk.xensource.com>
References: <patchbomb.1324212500@alpine.localdomain>
	<eed78eb655c40b0ac9af.1324212501@alpine.localdomain>
	<1324288096.9236.6.camel@zakaz.uk.xensource.com>
Date: Mon, 19 Dec 2011 03:57:14 -0600
Message-ID: <CA+T2pCHkJW=Lv0GqnL3B+o9JqUXdnB9CArkpRLRqS8t3v4AHoQ@mail.gmail.com>
From: William Pitcock <nenolod@dereferenced.org>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Roger Pau Monne <roger.pau@entel.upc.edu>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 1 of 5] blktap: remove HAVE_BYTESWAP_H
 checking, since it's defined by qemu
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi,

On Mon, Dec 19, 2011 at 3:48 AM, Ian Campbell <Ian.Campbell@citrix.com> wro=
te:
> On Sun, 2011-12-18 at 12:48 +0000, Roger Pau Monne wrote:
>> # HG changeset patch
>> # User Roger Pau Monne <roger.pau@entel.upc.edu>
>> # Date 1324171782 -3600
>> # Node ID eed78eb655c40b0ac9af1b14c1cc03204f696b0b
>> # Parent =A0b783e76e63a99c9d87fca4974492f60af99a2e7a
>> blktap: remove HAVE_BYTESWAP_H checking, since it's defined by qemu
>>
>> blktap was using defines set by qemu, even when the qemu config file
>> is not included. Remove this checkings, and instead check if the file
>> has been included before defining the necessary macros.
>>
>> The output error is:
>>
>> In file included from block-qcow.c:37:0:
>> bswap.h:23:0: error: "bswap_16" redefined [-Werror]
>> /usr/include/byteswap.h:30:0: note: this is the location of the
>> previous definition
>> bswap.h:31:0: error: "bswap_32" redefined [-Werror]
>> /usr/include/byteswap.h:33:0: note: this is the location of the
>> previous definition
>> bswap.h:41:0: error: "bswap_64" redefined [-Werror]
>> /usr/include/byteswap.h:37:0: note: this is the location of the
>> previous definition
>> cc1: all warnings being treated as errors
>>
>> Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>
>>
>> diff -r b783e76e63a9 -r eed78eb655c4 tools/blktap/drivers/bswap.h
>> --- a/tools/blktap/drivers/bswap.h =A0 =A0Sun Dec 18 02:29:42 2011 +0100
>> +++ b/tools/blktap/drivers/bswap.h =A0 =A0Sun Dec 18 02:29:42 2011 +0100
>> @@ -15,9 +15,7 @@
>> =A0#define bswap_64(x) swap64(x)
>> =A0#else
>>
>> -#ifdef HAVE_BYTESWAP_H
>> -#include <byteswap.h>
>> -#else
>> +#ifndef _BYTESWAP_H
>
> This is basically saying "if the user hasn't already include byteswap.h"
> but it seems to rely on that header using the precise guard _BYTESWAP_H
> which I presume can differ across platforms. I don't think this is a
> viable approach.
>
> Given that we have our own definitions of these things any why not just
> remove the ifdef and single the other #include of byteswap.h and always
> use the ones we defined?
>
> The other alternative is to remove our own version and always include
> byteswap.h.
>
> The right answer depends on how standardised byteswap.h is. It seems to
> be in glibc but is it in uclibc and the BSD libcs? I can't find a
> definitive reference but it seems like it is specified by POSIX?

uClibc 0.9.32 and later have byteswap.h.  Not sure about earlier versions.
byteswap.h is a GNU-ism though, and not in any of the BSDs as a result.

We should just ship these definitions directly in Xen and not depend on it.

William

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 10:02:17 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 10: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.xensource.com>)
	id 1Rca2f-0000zq-VL; Mon, 19 Dec 2011 10:01:57 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1Rca2e-0000zR-3b
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 10:01:56 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1324288907!6099650!1
X-Originating-IP: [209.85.160.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26115 invoked from network); 19 Dec 2011 10:01:49 -0000
Received: from mail-pw0-f43.google.com (HELO mail-pw0-f43.google.com)
	(209.85.160.43)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Dec 2011 10:01:49 -0000
Received: by pbbb11 with SMTP id b11so19598290pbb.30
	for <xen-devel@lists.xensource.com>;
	Mon, 19 Dec 2011 02:01:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=Ev7fCj30KRCt/6Ur64L+VR68YVefOImJlO25nAsOdCM=;
	b=CsZbHU17B9vcBVIFTNq4H6LDjuaUYN1HZgPJYjIqCCeKkwzlPrdiIY7fPyDQciRYSy
	+2I3jNPUGy/lVsk4LN8KXh6P4XDfcWoFWaRCydYGU/AZudZtv9pqdEFBInp7EBVdJZ8m
	K1hdm4MdSX3lmLiyKDyRV/hPSeKJaPn2meoGg=
MIME-Version: 1.0
Received: by 10.68.212.68 with SMTP id ni4mr37905756pbc.44.1324288907549; Mon,
	19 Dec 2011 02:01:47 -0800 (PST)
Received: by 10.142.47.17 with HTTP; Mon, 19 Dec 2011 02:01:47 -0800 (PST)
In-Reply-To: <1324288489.9236.9.camel@zakaz.uk.xensource.com>
References: <patchbomb.1324212500@alpine.localdomain>
	<6780cbdfa64b148b0c37.1324212505@alpine.localdomain>
	<1324288489.9236.9.camel@zakaz.uk.xensource.com>
Date: Mon, 19 Dec 2011 11:01:47 +0100
X-Google-Sender-Auth: fzrwQac6WEb6VXsnDdRV63sjGfs
Message-ID: <CAPLaKK7i18GeQZ8T_u6coYU68eC+fkk_bq3=gzO9rmeCZmrk2Q@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 5 of 5] libxl: fix link issue on uclibc when
 using yajl
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

MjAxMS8xMi8xOSBJYW4gQ2FtcGJlbGwgPElhbi5DYW1wYmVsbEBjaXRyaXguY29tPjoKPiBPbiBT
dW4sIDIwMTEtMTItMTggYXQgMTI6NDggKzAwMDAsIFJvZ2VyIFBhdSBNb25uZSB3cm90ZToKPj4g
IyBIRyBjaGFuZ2VzZXQgcGF0Y2gKPj4gIyBVc2VyIFJvZ2VyIFBhdSBNb25uZSA8cm9nZXIucGF1
QGVudGVsLnVwYy5lZHU+Cj4+ICMgRGF0ZSAxMzI0MTcxNzgyIC0zNjAwCj4+ICMgTm9kZSBJRCA2
NzgwY2JkZmE2NGIxNDhiMGMzNzJhNGY4MjQ0OGY3MDdhZDJiZTU5Cj4+ICMgUGFyZW50IMKgN2Jj
YjNhNjFjZTg4NDZmOGU3ODM0ZDE0YzQ2MGMwZjRiNDg2OTIyMgo+PiBsaWJ4bDogZml4IGxpbmsg
aXNzdWUgb24gdWNsaWJjIHdoZW4gdXNpbmcgeWFqbAo+Pgo+PiB5YWpsIG1ha2VzIHVzZSBvZiB0
aGUgaXNuYW4gaXNpbmYgZnVuY3Rpb25zLiBPbiBHbGliYywgdGhlc2UgYXJlCj4+IHByb3ZpZGVk
IGJ5IGxpYmMsIGJ1dCBvbiB1Q2xpYmMgeW91IG5lZWQgdG8gbGluayB3aXRoIC1sbSAobGlrZSB0
aGUKPj4gc3BlYyBzYXlzKSwgc28gZW5zdXJlIHdlIGRvIHNvLgo+Cj4gSWYgbGlieWFqbCBuZWVk
cyB0aG9zZSBzeW1ib2xzIHRoZW4gaXQgc2hvdWxkIGxpbmsgYWdhaW5zdCBsaWJtIGl0c2VsZgo+
IGFuZCBub3QgcmVseSBpb24gdGhlIGFwcGxpY2F0aW9uIHRvIGRvIHNvLiBUaGVyZSBzaG91bGQg
YmUgbm8gbmVlZCBmb3IKPiBhbiBhcHBsaWNhdGlvbiB1c2luZyBsaXlhamwgdG8gZG8gdGhpcyBp
dHNlbGYgd2hlbiBsaW5raW5nIGR5bmFtaWNhbGx5LgoKSSd2ZSBjb21waWxlZCB5YWpsIHdpdGgg
LWxtLCBidXQgdGhlIHNhbWUgZXJyb3IgY29tZXMgdXAgd2hlbgpjb21waWxpbmcgbGlieGwgaWYg
LWxtIGlzIG5vdCBhZGRlZCBhbHNvLiBXaWxsIGxvb2sgaW50byBpdCBkZWVwbHkuCgo+IEkgc3Vz
cGVjdCB0aGlzIGlzIGEgYnVnIGluIGxpYnlhamwuCgpQcm9iYWJseQoKPiAoaWYgYWRkaW5nIC1s
bSB3ZXJlIGNvcnJlY3QgdGhlbiBpdCB3b3VsZCBiZSBiZXR0ZXIgdG8ganVzdCBkbyBpdAo+IHVu
Y29uZGl0aW9uYWxseSkKPgo+IElhbi4KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhl
bnNvdXJjZS5jb20KaHR0cDovL2xpc3RzLnhlbnNvdXJjZS5jb20veGVuLWRldmVsCg==

From xen-devel-bounces@lists.xensource.com Mon Dec 19 10:02:17 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 10: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.xensource.com>)
	id 1Rca2f-0000zq-VL; Mon, 19 Dec 2011 10:01:57 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1Rca2e-0000zR-3b
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 10:01:56 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1324288907!6099650!1
X-Originating-IP: [209.85.160.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26115 invoked from network); 19 Dec 2011 10:01:49 -0000
Received: from mail-pw0-f43.google.com (HELO mail-pw0-f43.google.com)
	(209.85.160.43)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Dec 2011 10:01:49 -0000
Received: by pbbb11 with SMTP id b11so19598290pbb.30
	for <xen-devel@lists.xensource.com>;
	Mon, 19 Dec 2011 02:01:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=Ev7fCj30KRCt/6Ur64L+VR68YVefOImJlO25nAsOdCM=;
	b=CsZbHU17B9vcBVIFTNq4H6LDjuaUYN1HZgPJYjIqCCeKkwzlPrdiIY7fPyDQciRYSy
	+2I3jNPUGy/lVsk4LN8KXh6P4XDfcWoFWaRCydYGU/AZudZtv9pqdEFBInp7EBVdJZ8m
	K1hdm4MdSX3lmLiyKDyRV/hPSeKJaPn2meoGg=
MIME-Version: 1.0
Received: by 10.68.212.68 with SMTP id ni4mr37905756pbc.44.1324288907549; Mon,
	19 Dec 2011 02:01:47 -0800 (PST)
Received: by 10.142.47.17 with HTTP; Mon, 19 Dec 2011 02:01:47 -0800 (PST)
In-Reply-To: <1324288489.9236.9.camel@zakaz.uk.xensource.com>
References: <patchbomb.1324212500@alpine.localdomain>
	<6780cbdfa64b148b0c37.1324212505@alpine.localdomain>
	<1324288489.9236.9.camel@zakaz.uk.xensource.com>
Date: Mon, 19 Dec 2011 11:01:47 +0100
X-Google-Sender-Auth: fzrwQac6WEb6VXsnDdRV63sjGfs
Message-ID: <CAPLaKK7i18GeQZ8T_u6coYU68eC+fkk_bq3=gzO9rmeCZmrk2Q@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 5 of 5] libxl: fix link issue on uclibc when
 using yajl
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

MjAxMS8xMi8xOSBJYW4gQ2FtcGJlbGwgPElhbi5DYW1wYmVsbEBjaXRyaXguY29tPjoKPiBPbiBT
dW4sIDIwMTEtMTItMTggYXQgMTI6NDggKzAwMDAsIFJvZ2VyIFBhdSBNb25uZSB3cm90ZToKPj4g
IyBIRyBjaGFuZ2VzZXQgcGF0Y2gKPj4gIyBVc2VyIFJvZ2VyIFBhdSBNb25uZSA8cm9nZXIucGF1
QGVudGVsLnVwYy5lZHU+Cj4+ICMgRGF0ZSAxMzI0MTcxNzgyIC0zNjAwCj4+ICMgTm9kZSBJRCA2
NzgwY2JkZmE2NGIxNDhiMGMzNzJhNGY4MjQ0OGY3MDdhZDJiZTU5Cj4+ICMgUGFyZW50IMKgN2Jj
YjNhNjFjZTg4NDZmOGU3ODM0ZDE0YzQ2MGMwZjRiNDg2OTIyMgo+PiBsaWJ4bDogZml4IGxpbmsg
aXNzdWUgb24gdWNsaWJjIHdoZW4gdXNpbmcgeWFqbAo+Pgo+PiB5YWpsIG1ha2VzIHVzZSBvZiB0
aGUgaXNuYW4gaXNpbmYgZnVuY3Rpb25zLiBPbiBHbGliYywgdGhlc2UgYXJlCj4+IHByb3ZpZGVk
IGJ5IGxpYmMsIGJ1dCBvbiB1Q2xpYmMgeW91IG5lZWQgdG8gbGluayB3aXRoIC1sbSAobGlrZSB0
aGUKPj4gc3BlYyBzYXlzKSwgc28gZW5zdXJlIHdlIGRvIHNvLgo+Cj4gSWYgbGlieWFqbCBuZWVk
cyB0aG9zZSBzeW1ib2xzIHRoZW4gaXQgc2hvdWxkIGxpbmsgYWdhaW5zdCBsaWJtIGl0c2VsZgo+
IGFuZCBub3QgcmVseSBpb24gdGhlIGFwcGxpY2F0aW9uIHRvIGRvIHNvLiBUaGVyZSBzaG91bGQg
YmUgbm8gbmVlZCBmb3IKPiBhbiBhcHBsaWNhdGlvbiB1c2luZyBsaXlhamwgdG8gZG8gdGhpcyBp
dHNlbGYgd2hlbiBsaW5raW5nIGR5bmFtaWNhbGx5LgoKSSd2ZSBjb21waWxlZCB5YWpsIHdpdGgg
LWxtLCBidXQgdGhlIHNhbWUgZXJyb3IgY29tZXMgdXAgd2hlbgpjb21waWxpbmcgbGlieGwgaWYg
LWxtIGlzIG5vdCBhZGRlZCBhbHNvLiBXaWxsIGxvb2sgaW50byBpdCBkZWVwbHkuCgo+IEkgc3Vz
cGVjdCB0aGlzIGlzIGEgYnVnIGluIGxpYnlhamwuCgpQcm9iYWJseQoKPiAoaWYgYWRkaW5nIC1s
bSB3ZXJlIGNvcnJlY3QgdGhlbiBpdCB3b3VsZCBiZSBiZXR0ZXIgdG8ganVzdCBkbyBpdAo+IHVu
Y29uZGl0aW9uYWxseSkKPgo+IElhbi4KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhl
bnNvdXJjZS5jb20KaHR0cDovL2xpc3RzLnhlbnNvdXJjZS5jb20veGVuLWRldmVsCg==

From xen-devel-bounces@lists.xensource.com Mon Dec 19 10:06:22 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 10:06:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rca6g-0001FX-Qm; Mon, 19 Dec 2011 10:06:06 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rca6f-0001FN-57
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 10:06:05 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1324289159!7275971!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzA0OQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17097 invoked from network); 19 Dec 2011 10:05:59 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Dec 2011 10:05:59 -0000
X-IronPort-AV: E=Sophos;i="4.71,375,1320624000"; 
   d="scan'208";a="9549048"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Dec 2011 10:05:58 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 19 Dec 2011 10:05:58 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau Monne <roger.pau@entel.upc.edu>
Date: Mon, 19 Dec 2011 10:05:58 +0000
In-Reply-To: <c0d5aa328f1ab24aad58.1324212503@alpine.localdomain>
References: <patchbomb.1324212500@alpine.localdomain>
	<c0d5aa328f1ab24aad58.1324212503@alpine.localdomain>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1324289158.9236.14.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 3 of 5] blktap2: fix vhd compilation under
 uclibc
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Sun, 2011-12-18 at 12:48 +0000, Roger Pau Monne wrote:
> # HG changeset patch
> # User Roger Pau Monne <roger.pau@entel.upc.edu>
> # Date 1324171782 -3600
> # Node ID c0d5aa328f1ab24aad5880e720852b6dc8ffd4fb
> # Parent  c54c326d6fdf26d311c872479b769b3a8cd560cf
> blktap2: fix vhd compilation under uclibc
> 
> blktap2 was not compiled succesfully under uclibc, with the following
> error:
> 
> gcc     -o vhd-util vhd-util.o -Llib -lvhd
> lib/libvhd.so: undefined reference to `libiconv_open'
> lib/libvhd.so: undefined reference to `libiconv_close'
> lib/libvhd.so: undefined reference to `libiconv'
> 
> This patchs add the flag -liconv when blktap2/vhd is compiled on
> uclibc.

Since it is libvhd which uses these symbols it should be libvhd and not
the utilities which links against it.

Can we not directly check for the need for libiconv instead of infering
it from the use of uclibc?

Does the standard say one way or the other if this library needs to be
explicitly linked?

If uclibc is using http://www.haible.de/bruno/packages-libiconv.html
then
http://stackoverflow.com/questions/4709178/how-do-i-link-glibcs-implementation-of-iconv suggests -DLIBICONV_PLUG which from looking at the source seems like it might work -- all seems a little bit backwards though.

Ian.

> 
> Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>
> 
> diff -r c54c326d6fdf -r c0d5aa328f1a tools/blktap2/drivers/Makefile
> --- a/tools/blktap2/drivers/Makefile	Sun Dec 18 02:29:42 2011 +0100
> +++ b/tools/blktap2/drivers/Makefile	Sun Dec 18 02:29:42 2011 +0100
> @@ -24,6 +24,10 @@ endif
>  
>  VHDLIBS    := -L$(LIBVHDDIR) -lvhd
>  
> +ifeq ($(CONFIG_UCLIBC),y)
> +VHDLIBS    += -liconv
> +endif
> +
>  REMUS-OBJS  := block-remus.o
>  REMUS-OBJS  += hashtable.o
>  REMUS-OBJS  += hashtable_itr.o
> diff -r c54c326d6fdf -r c0d5aa328f1a tools/blktap2/vhd/Makefile
> --- a/tools/blktap2/vhd/Makefile	Sun Dec 18 02:29:42 2011 +0100
> +++ b/tools/blktap2/vhd/Makefile	Sun Dec 18 02:29:42 2011 +0100
> @@ -23,6 +23,10 @@ endif
>  
>  LIBS              := -Llib -lvhd
>  
> +ifeq ($(CONFIG_UCLIBC),y)
> +LIBS              += -liconv
> +endif
> +
>  all: subdirs-all build
>  
>  build: $(IBIN)
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 10:06:22 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 10:06:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rca6g-0001FX-Qm; Mon, 19 Dec 2011 10:06:06 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rca6f-0001FN-57
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 10:06:05 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1324289159!7275971!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzA0OQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17097 invoked from network); 19 Dec 2011 10:05:59 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Dec 2011 10:05:59 -0000
X-IronPort-AV: E=Sophos;i="4.71,375,1320624000"; 
   d="scan'208";a="9549048"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Dec 2011 10:05:58 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 19 Dec 2011 10:05:58 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau Monne <roger.pau@entel.upc.edu>
Date: Mon, 19 Dec 2011 10:05:58 +0000
In-Reply-To: <c0d5aa328f1ab24aad58.1324212503@alpine.localdomain>
References: <patchbomb.1324212500@alpine.localdomain>
	<c0d5aa328f1ab24aad58.1324212503@alpine.localdomain>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1324289158.9236.14.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 3 of 5] blktap2: fix vhd compilation under
 uclibc
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Sun, 2011-12-18 at 12:48 +0000, Roger Pau Monne wrote:
> # HG changeset patch
> # User Roger Pau Monne <roger.pau@entel.upc.edu>
> # Date 1324171782 -3600
> # Node ID c0d5aa328f1ab24aad5880e720852b6dc8ffd4fb
> # Parent  c54c326d6fdf26d311c872479b769b3a8cd560cf
> blktap2: fix vhd compilation under uclibc
> 
> blktap2 was not compiled succesfully under uclibc, with the following
> error:
> 
> gcc     -o vhd-util vhd-util.o -Llib -lvhd
> lib/libvhd.so: undefined reference to `libiconv_open'
> lib/libvhd.so: undefined reference to `libiconv_close'
> lib/libvhd.so: undefined reference to `libiconv'
> 
> This patchs add the flag -liconv when blktap2/vhd is compiled on
> uclibc.

Since it is libvhd which uses these symbols it should be libvhd and not
the utilities which links against it.

Can we not directly check for the need for libiconv instead of infering
it from the use of uclibc?

Does the standard say one way or the other if this library needs to be
explicitly linked?

If uclibc is using http://www.haible.de/bruno/packages-libiconv.html
then
http://stackoverflow.com/questions/4709178/how-do-i-link-glibcs-implementation-of-iconv suggests -DLIBICONV_PLUG which from looking at the source seems like it might work -- all seems a little bit backwards though.

Ian.

> 
> Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>
> 
> diff -r c54c326d6fdf -r c0d5aa328f1a tools/blktap2/drivers/Makefile
> --- a/tools/blktap2/drivers/Makefile	Sun Dec 18 02:29:42 2011 +0100
> +++ b/tools/blktap2/drivers/Makefile	Sun Dec 18 02:29:42 2011 +0100
> @@ -24,6 +24,10 @@ endif
>  
>  VHDLIBS    := -L$(LIBVHDDIR) -lvhd
>  
> +ifeq ($(CONFIG_UCLIBC),y)
> +VHDLIBS    += -liconv
> +endif
> +
>  REMUS-OBJS  := block-remus.o
>  REMUS-OBJS  += hashtable.o
>  REMUS-OBJS  += hashtable_itr.o
> diff -r c54c326d6fdf -r c0d5aa328f1a tools/blktap2/vhd/Makefile
> --- a/tools/blktap2/vhd/Makefile	Sun Dec 18 02:29:42 2011 +0100
> +++ b/tools/blktap2/vhd/Makefile	Sun Dec 18 02:29:42 2011 +0100
> @@ -23,6 +23,10 @@ endif
>  
>  LIBS              := -Llib -lvhd
>  
> +ifeq ($(CONFIG_UCLIBC),y)
> +LIBS              += -liconv
> +endif
> +
>  all: subdirs-all build
>  
>  build: $(IBIN)
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 10:07:41 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 10:07:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rca7y-0001K9-AM; Mon, 19 Dec 2011 10:07:26 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <nenolod@dereferenced.org>) id 1Rca7w-0001Jp-KH
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 10:07:24 +0000
X-Env-Sender: nenolod@dereferenced.org
X-Msg-Ref: server-16.tower-182.messagelabs.com!1324289236!494382!1
X-Originating-IP: [209.85.210.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6503 invoked from network); 19 Dec 2011 10:07:18 -0000
Received: from mail-pz0-f43.google.com (HELO mail-pz0-f43.google.com)
	(209.85.210.43)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Dec 2011 10:07:18 -0000
Received: by daec6 with SMTP id c6so24940554dae.30
	for <xen-devel@lists.xensource.com>;
	Mon, 19 Dec 2011 02:07:16 -0800 (PST)
MIME-Version: 1.0
Received: by 10.68.191.8 with SMTP id gu8mr38014428pbc.36.1324289236215; Mon,
	19 Dec 2011 02:07:16 -0800 (PST)
Received: by 10.143.142.18 with HTTP; Mon, 19 Dec 2011 02:07:16 -0800 (PST)
In-Reply-To: <c0d5aa328f1ab24aad58.1324212503@alpine.localdomain>
References: <patchbomb.1324212500@alpine.localdomain>
	<c0d5aa328f1ab24aad58.1324212503@alpine.localdomain>
Date: Mon, 19 Dec 2011 04:07:16 -0600
Message-ID: <CA+T2pCE_L0Gfyb0xu4=bd-yCAz=+Z_4Ugyd-EoO4m=+jz5MPGA@mail.gmail.com>
From: William Pitcock <nenolod@dereferenced.org>
To: Roger Pau Monne <roger.pau@entel.upc.edu>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 3 of 5] blktap2: fix vhd compilation under
	uclibc
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi,

On Sun, Dec 18, 2011 at 6:48 AM, Roger Pau Monne
<roger.pau@entel.upc.edu> wrote:
> # HG changeset patch
> # User Roger Pau Monne <roger.pau@entel.upc.edu>
> # Date 1324171782 -3600
> # Node ID c0d5aa328f1ab24aad5880e720852b6dc8ffd4fb
> # Parent =A0c54c326d6fdf26d311c872479b769b3a8cd560cf
> blktap2: fix vhd compilation under uclibc
>
> blktap2 was not compiled succesfully under uclibc, with the following
> error:

This description is wrong; it is a linktime symbol binding error, not
a compilation error.

>
> gcc =A0 =A0 -o vhd-util vhd-util.o -Llib -lvhd
> lib/libvhd.so: undefined reference to `libiconv_open'
> lib/libvhd.so: undefined reference to `libiconv_close'
> lib/libvhd.so: undefined reference to `libiconv'
>
> This patchs add the flag -liconv when blktap2/vhd is compiled on
> uclibc.
>
> Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>
>
> diff -r c54c326d6fdf -r c0d5aa328f1a tools/blktap2/drivers/Makefile
> --- a/tools/blktap2/drivers/Makefile =A0 =A0Sun Dec 18 02:29:42 2011 +0100
> +++ b/tools/blktap2/drivers/Makefile =A0 =A0Sun Dec 18 02:29:42 2011 +0100
> @@ -24,6 +24,10 @@ endif
>
> =A0VHDLIBS =A0 =A0:=3D -L$(LIBVHDDIR) -lvhd
>
> +ifeq ($(CONFIG_UCLIBC),y)
> +VHDLIBS =A0 =A0+=3D -liconv
> +endif

I don't like this really.  I think it is wrong to imply that
$(CONFIG_UCLIBC) needs -liconv, as it is possible to build uClibc with
iconv support.  The real check here should be if we are running with
GNU libiconv I think.  Which makes me wonder why CONFIG_UCLIBC is
necessary at all.

> +
> =A0REMUS-OBJS =A0:=3D block-remus.o
> =A0REMUS-OBJS =A0+=3D hashtable.o
> =A0REMUS-OBJS =A0+=3D hashtable_itr.o
> diff -r c54c326d6fdf -r c0d5aa328f1a tools/blktap2/vhd/Makefile
> --- a/tools/blktap2/vhd/Makefile =A0 =A0 =A0 =A0Sun Dec 18 02:29:42 2011 =
+0100
> +++ b/tools/blktap2/vhd/Makefile =A0 =A0 =A0 =A0Sun Dec 18 02:29:42 2011 =
+0100
> @@ -23,6 +23,10 @@ endif
>
> =A0LIBS =A0 =A0 =A0 =A0 =A0 =A0 =A0:=3D -Llib -lvhd
>
> +ifeq ($(CONFIG_UCLIBC),y)
> +LIBS =A0 =A0 =A0 =A0 =A0 =A0 =A0+=3D -liconv
> +endif
> +
> =A0all: subdirs-all build
>
> =A0build: $(IBIN)
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 10:07:41 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 10:07:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rca7y-0001K9-AM; Mon, 19 Dec 2011 10:07:26 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <nenolod@dereferenced.org>) id 1Rca7w-0001Jp-KH
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 10:07:24 +0000
X-Env-Sender: nenolod@dereferenced.org
X-Msg-Ref: server-16.tower-182.messagelabs.com!1324289236!494382!1
X-Originating-IP: [209.85.210.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6503 invoked from network); 19 Dec 2011 10:07:18 -0000
Received: from mail-pz0-f43.google.com (HELO mail-pz0-f43.google.com)
	(209.85.210.43)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Dec 2011 10:07:18 -0000
Received: by daec6 with SMTP id c6so24940554dae.30
	for <xen-devel@lists.xensource.com>;
	Mon, 19 Dec 2011 02:07:16 -0800 (PST)
MIME-Version: 1.0
Received: by 10.68.191.8 with SMTP id gu8mr38014428pbc.36.1324289236215; Mon,
	19 Dec 2011 02:07:16 -0800 (PST)
Received: by 10.143.142.18 with HTTP; Mon, 19 Dec 2011 02:07:16 -0800 (PST)
In-Reply-To: <c0d5aa328f1ab24aad58.1324212503@alpine.localdomain>
References: <patchbomb.1324212500@alpine.localdomain>
	<c0d5aa328f1ab24aad58.1324212503@alpine.localdomain>
Date: Mon, 19 Dec 2011 04:07:16 -0600
Message-ID: <CA+T2pCE_L0Gfyb0xu4=bd-yCAz=+Z_4Ugyd-EoO4m=+jz5MPGA@mail.gmail.com>
From: William Pitcock <nenolod@dereferenced.org>
To: Roger Pau Monne <roger.pau@entel.upc.edu>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 3 of 5] blktap2: fix vhd compilation under
	uclibc
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi,

On Sun, Dec 18, 2011 at 6:48 AM, Roger Pau Monne
<roger.pau@entel.upc.edu> wrote:
> # HG changeset patch
> # User Roger Pau Monne <roger.pau@entel.upc.edu>
> # Date 1324171782 -3600
> # Node ID c0d5aa328f1ab24aad5880e720852b6dc8ffd4fb
> # Parent =A0c54c326d6fdf26d311c872479b769b3a8cd560cf
> blktap2: fix vhd compilation under uclibc
>
> blktap2 was not compiled succesfully under uclibc, with the following
> error:

This description is wrong; it is a linktime symbol binding error, not
a compilation error.

>
> gcc =A0 =A0 -o vhd-util vhd-util.o -Llib -lvhd
> lib/libvhd.so: undefined reference to `libiconv_open'
> lib/libvhd.so: undefined reference to `libiconv_close'
> lib/libvhd.so: undefined reference to `libiconv'
>
> This patchs add the flag -liconv when blktap2/vhd is compiled on
> uclibc.
>
> Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>
>
> diff -r c54c326d6fdf -r c0d5aa328f1a tools/blktap2/drivers/Makefile
> --- a/tools/blktap2/drivers/Makefile =A0 =A0Sun Dec 18 02:29:42 2011 +0100
> +++ b/tools/blktap2/drivers/Makefile =A0 =A0Sun Dec 18 02:29:42 2011 +0100
> @@ -24,6 +24,10 @@ endif
>
> =A0VHDLIBS =A0 =A0:=3D -L$(LIBVHDDIR) -lvhd
>
> +ifeq ($(CONFIG_UCLIBC),y)
> +VHDLIBS =A0 =A0+=3D -liconv
> +endif

I don't like this really.  I think it is wrong to imply that
$(CONFIG_UCLIBC) needs -liconv, as it is possible to build uClibc with
iconv support.  The real check here should be if we are running with
GNU libiconv I think.  Which makes me wonder why CONFIG_UCLIBC is
necessary at all.

> +
> =A0REMUS-OBJS =A0:=3D block-remus.o
> =A0REMUS-OBJS =A0+=3D hashtable.o
> =A0REMUS-OBJS =A0+=3D hashtable_itr.o
> diff -r c54c326d6fdf -r c0d5aa328f1a tools/blktap2/vhd/Makefile
> --- a/tools/blktap2/vhd/Makefile =A0 =A0 =A0 =A0Sun Dec 18 02:29:42 2011 =
+0100
> +++ b/tools/blktap2/vhd/Makefile =A0 =A0 =A0 =A0Sun Dec 18 02:29:42 2011 =
+0100
> @@ -23,6 +23,10 @@ endif
>
> =A0LIBS =A0 =A0 =A0 =A0 =A0 =A0 =A0:=3D -Llib -lvhd
>
> +ifeq ($(CONFIG_UCLIBC),y)
> +LIBS =A0 =A0 =A0 =A0 =A0 =A0 =A0+=3D -liconv
> +endif
> +
> =A0all: subdirs-all build
>
> =A0build: $(IBIN)
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 10:08:38 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 10:08:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rca8p-0001Of-PH; Mon, 19 Dec 2011 10:08:19 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rca8n-0001O4-UL
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 10:08:18 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1324289291!7822118!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzA0OQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24496 invoked from network); 19 Dec 2011 10:08:12 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Dec 2011 10:08:12 -0000
X-IronPort-AV: E=Sophos;i="4.71,375,1320624000"; 
   d="scan'208";a="9549217"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Dec 2011 10:08:11 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 19 Dec 2011 10:08:11 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau =?ISO-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
Date: Mon, 19 Dec 2011 10:08:11 +0000
In-Reply-To: <CAPLaKK7gEUv9bavavzyYjREPDZJepMkK+-Ap78xzHjPy4SvZ3g@mail.gmail.com>
References: <patchbomb.1324212500@alpine.localdomain>
	<eed78eb655c40b0ac9af.1324212501@alpine.localdomain>
	<1324288096.9236.6.camel@zakaz.uk.xensource.com>
	<CAPLaKK7gEUv9bavavzyYjREPDZJepMkK+-Ap78xzHjPy4SvZ3g@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1324289291.9236.16.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 1 of 5] blktap: remove HAVE_BYTESWAP_H
 checking, since it's defined by qemu
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gTW9uLCAyMDExLTEyLTE5IGF0IDA5OjU4ICswMDAwLCBSb2dlciBQYXUgTW9ubsOpIHdyb3Rl
Ogo+IDIwMTEvMTIvMTkgSWFuIENhbXBiZWxsIDxJYW4uQ2FtcGJlbGxAY2l0cml4LmNvbT46Cj4g
PiBPbiBTdW4sIDIwMTEtMTItMTggYXQgMTI6NDggKzAwMDAsIFJvZ2VyIFBhdSBNb25uZSB3cm90
ZToKPiA+PiAjIEhHIGNoYW5nZXNldCBwYXRjaAo+ID4+ICMgVXNlciBSb2dlciBQYXUgTW9ubmUg
PHJvZ2VyLnBhdUBlbnRlbC51cGMuZWR1Pgo+ID4+ICMgRGF0ZSAxMzI0MTcxNzgyIC0zNjAwCj4g
Pj4gIyBOb2RlIElEIGVlZDc4ZWI2NTVjNDBiMGFjOWFmMWIxNGMxY2MwMzIwNGY2OTZiMGIKPiA+
PiAjIFBhcmVudCAgYjc4M2U3NmU2M2E5OWM5ZDg3ZmNhNDk3NDQ5MmY2MGFmOTlhMmU3YQo+ID4+
IGJsa3RhcDogcmVtb3ZlIEhBVkVfQllURVNXQVBfSCBjaGVja2luZywgc2luY2UgaXQncyBkZWZp
bmVkIGJ5IHFlbXUKPiA+Pgo+ID4+IGJsa3RhcCB3YXMgdXNpbmcgZGVmaW5lcyBzZXQgYnkgcWVt
dSwgZXZlbiB3aGVuIHRoZSBxZW11IGNvbmZpZyBmaWxlCj4gPj4gaXMgbm90IGluY2x1ZGVkLiBS
ZW1vdmUgdGhpcyBjaGVja2luZ3MsIGFuZCBpbnN0ZWFkIGNoZWNrIGlmIHRoZSBmaWxlCj4gPj4g
aGFzIGJlZW4gaW5jbHVkZWQgYmVmb3JlIGRlZmluaW5nIHRoZSBuZWNlc3NhcnkgbWFjcm9zLgo+
ID4+Cj4gPj4gVGhlIG91dHB1dCBlcnJvciBpczoKPiA+Pgo+ID4+IEluIGZpbGUgaW5jbHVkZWQg
ZnJvbSBibG9jay1xY293LmM6Mzc6MDoKPiA+PiBic3dhcC5oOjIzOjA6IGVycm9yOiAiYnN3YXBf
MTYiIHJlZGVmaW5lZCBbLVdlcnJvcl0KPiA+PiAvdXNyL2luY2x1ZGUvYnl0ZXN3YXAuaDozMDow
OiBub3RlOiB0aGlzIGlzIHRoZSBsb2NhdGlvbiBvZiB0aGUKPiA+PiBwcmV2aW91cyBkZWZpbml0
aW9uCj4gPj4gYnN3YXAuaDozMTowOiBlcnJvcjogImJzd2FwXzMyIiByZWRlZmluZWQgWy1XZXJy
b3JdCj4gPj4gL3Vzci9pbmNsdWRlL2J5dGVzd2FwLmg6MzM6MDogbm90ZTogdGhpcyBpcyB0aGUg
bG9jYXRpb24gb2YgdGhlCj4gPj4gcHJldmlvdXMgZGVmaW5pdGlvbgo+ID4+IGJzd2FwLmg6NDE6
MDogZXJyb3I6ICJic3dhcF82NCIgcmVkZWZpbmVkIFstV2Vycm9yXQo+ID4+IC91c3IvaW5jbHVk
ZS9ieXRlc3dhcC5oOjM3OjA6IG5vdGU6IHRoaXMgaXMgdGhlIGxvY2F0aW9uIG9mIHRoZQo+ID4+
IHByZXZpb3VzIGRlZmluaXRpb24KPiA+PiBjYzE6IGFsbCB3YXJuaW5ncyBiZWluZyB0cmVhdGVk
IGFzIGVycm9ycwo+ID4+Cj4gPj4gU2lnbmVkLW9mZi1ieTogUm9nZXIgUGF1IE1vbm5lIDxyb2dl
ci5wYXVAZW50ZWwudXBjLmVkdT4KPiA+Pgo+ID4+IGRpZmYgLXIgYjc4M2U3NmU2M2E5IC1yIGVl
ZDc4ZWI2NTVjNCB0b29scy9ibGt0YXAvZHJpdmVycy9ic3dhcC5oCj4gPj4gLS0tIGEvdG9vbHMv
YmxrdGFwL2RyaXZlcnMvYnN3YXAuaCAgICBTdW4gRGVjIDE4IDAyOjI5OjQyIDIwMTEgKzAxMDAK
PiA+PiArKysgYi90b29scy9ibGt0YXAvZHJpdmVycy9ic3dhcC5oICAgIFN1biBEZWMgMTggMDI6
Mjk6NDIgMjAxMSArMDEwMAo+ID4+IEBAIC0xNSw5ICsxNSw3IEBACj4gPj4gICNkZWZpbmUgYnN3
YXBfNjQoeCkgc3dhcDY0KHgpCj4gPj4gICNlbHNlCj4gPj4KPiA+PiAtI2lmZGVmIEhBVkVfQllU
RVNXQVBfSAo+ID4+IC0jaW5jbHVkZSA8Ynl0ZXN3YXAuaD4KPiA+PiAtI2Vsc2UKPiA+PiArI2lm
bmRlZiBfQllURVNXQVBfSAo+ID4KPiA+IFRoaXMgaXMgYmFzaWNhbGx5IHNheWluZyAiaWYgdGhl
IHVzZXIgaGFzbid0IGFscmVhZHkgaW5jbHVkZSBieXRlc3dhcC5oIgo+ID4gYnV0IGl0IHNlZW1z
IHRvIHJlbHkgb24gdGhhdCBoZWFkZXIgdXNpbmcgdGhlIHByZWNpc2UgZ3VhcmQgX0JZVEVTV0FQ
X0gKPiA+IHdoaWNoIEkgcHJlc3VtZSBjYW4gZGlmZmVyIGFjcm9zcyBwbGF0Zm9ybXMuIEkgZG9u
J3QgdGhpbmsgdGhpcyBpcyBhCj4gPiB2aWFibGUgYXBwcm9hY2guCj4gCj4gRnJvbSB3aGF0IEkg
c2F3IF9CWVRFU1dBUF9IIGlzIGRlZmluZWQgaW4gdWNsaWJjIGFuZCBnbGliYyAoU29sYXJpcwo+
IGFuZCBOZXRCU0QgaGF2ZSB0aGVpciBvd24gcHJlcHJvY2Vzc29yIGxvZ2ljLCBzbyB0aGlzIGRv
ZXNuJ3QgYXBwbHkgdG8KPiB0aGVtKS4gSXQncyBqdXN0IGEgc2FmZWd1YXJkIHRoYXQgYXZvaWRz
IHJlZGVmaW5pbmcgdGhlIG1hY3JvcyBpZgo+IHNvbWVvbmUgaGFzIGluY2x1ZGVkIGJ5dGVzd2Fw
LmggYmVoaW5kIG91ciBiYWNrcy4KCkl0J3Mgbm90IGFuIGVmZmVjdGl2ZSBzYWZlZ3VhcmQgdGhv
dWdoLgoKPiA+IEdpdmVuIHRoYXQgd2UgaGF2ZSBvdXIgb3duIGRlZmluaXRpb25zIG9mIHRoZXNl
IHRoaW5ncyBhbnkgd2h5IG5vdCBqdXN0Cj4gPiByZW1vdmUgdGhlIGlmZGVmIGFuZCBzaW5nbGUg
dGhlIG90aGVyICNpbmNsdWRlIG9mIGJ5dGVzd2FwLmggYW5kIGFsd2F5cwo+ID4gdXNlIHRoZSBv
bmVzIHdlIGRlZmluZWQ/Cj4gPgo+ID4gVGhlIG90aGVyIGFsdGVybmF0aXZlIGlzIHRvIHJlbW92
ZSBvdXIgb3duIHZlcnNpb24gYW5kIGFsd2F5cyBpbmNsdWRlCj4gPiBieXRlc3dhcC5oLgo+ID4K
PiA+IFRoZSByaWdodCBhbnN3ZXIgZGVwZW5kcyBvbiBob3cgc3RhbmRhcmRpc2VkIGJ5dGVzd2Fw
LmggaXMuIEl0IHNlZW1zIHRvCj4gPiBiZSBpbiBnbGliYyBidXQgaXMgaXQgaW4gdWNsaWJjIGFu
ZCB0aGUgQlNEIGxpYmNzPyBJIGNhbid0IGZpbmQgYQo+ID4gZGVmaW5pdGl2ZSByZWZlcmVuY2Ug
YnV0IGl0IHNlZW1zIGxpa2UgaXQgaXMgc3BlY2lmaWVkIGJ5IFBPU0lYPwo+IAo+IFRoZSBzb2x1
dGlvbnMgSSBzZWUgYXJlOgo+IAo+ICAqIENoZWNrIGlmIGJ5dGVzd2FwLmggaGFzIGJlZW4gaW5j
bHVkZWQgKHRoaXMgcGF0Y2gpLgo+ICAqIHVuZGVmIGJzd2FwXyogZnVuY3Rpb25zIGFuZCBkZWZp
bmUgb3VyIG93bi4KPiAgKiBJbmNsdWRlIGJ5dGVzd2FwLmguCgogICAqIE5ldmVyIGluY2x1ZGUg
Ynl0ZXN3YXAuaCBhbmQgdXNlIG91ciBvd24gYnN3YXBfKiBmdW5jdGlvbnMgd2hpY2ggd2UKICAg
ICBhbHJlYWR5IGRlZmluZS4KCkkgdGhpbmsgdGhpcyBpcyB0aGUgY29ycmVjdCBvcHRpb24uIE5v
IG5lZWQgdG8gdW5kZWYgc3R1ZmYuIFRoZXJlIGlzCm9ubHkgb25lIG90aGVyIGluY2x1ZGUgb2Yg
Ynl0ZXN3YXAuaCBpbiBibGt0YXAuCgpJYW4uCgoKCl9fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxp
c3RzLnhlbnNvdXJjZS5jb20KaHR0cDovL2xpc3RzLnhlbnNvdXJjZS5jb20veGVuLWRldmVsCg==

From xen-devel-bounces@lists.xensource.com Mon Dec 19 10:08:38 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 10:08:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rca8p-0001Of-PH; Mon, 19 Dec 2011 10:08:19 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rca8n-0001O4-UL
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 10:08:18 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1324289291!7822118!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzA0OQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24496 invoked from network); 19 Dec 2011 10:08:12 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Dec 2011 10:08:12 -0000
X-IronPort-AV: E=Sophos;i="4.71,375,1320624000"; 
   d="scan'208";a="9549217"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Dec 2011 10:08:11 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 19 Dec 2011 10:08:11 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau =?ISO-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
Date: Mon, 19 Dec 2011 10:08:11 +0000
In-Reply-To: <CAPLaKK7gEUv9bavavzyYjREPDZJepMkK+-Ap78xzHjPy4SvZ3g@mail.gmail.com>
References: <patchbomb.1324212500@alpine.localdomain>
	<eed78eb655c40b0ac9af.1324212501@alpine.localdomain>
	<1324288096.9236.6.camel@zakaz.uk.xensource.com>
	<CAPLaKK7gEUv9bavavzyYjREPDZJepMkK+-Ap78xzHjPy4SvZ3g@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1324289291.9236.16.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 1 of 5] blktap: remove HAVE_BYTESWAP_H
 checking, since it's defined by qemu
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gTW9uLCAyMDExLTEyLTE5IGF0IDA5OjU4ICswMDAwLCBSb2dlciBQYXUgTW9ubsOpIHdyb3Rl
Ogo+IDIwMTEvMTIvMTkgSWFuIENhbXBiZWxsIDxJYW4uQ2FtcGJlbGxAY2l0cml4LmNvbT46Cj4g
PiBPbiBTdW4sIDIwMTEtMTItMTggYXQgMTI6NDggKzAwMDAsIFJvZ2VyIFBhdSBNb25uZSB3cm90
ZToKPiA+PiAjIEhHIGNoYW5nZXNldCBwYXRjaAo+ID4+ICMgVXNlciBSb2dlciBQYXUgTW9ubmUg
PHJvZ2VyLnBhdUBlbnRlbC51cGMuZWR1Pgo+ID4+ICMgRGF0ZSAxMzI0MTcxNzgyIC0zNjAwCj4g
Pj4gIyBOb2RlIElEIGVlZDc4ZWI2NTVjNDBiMGFjOWFmMWIxNGMxY2MwMzIwNGY2OTZiMGIKPiA+
PiAjIFBhcmVudCAgYjc4M2U3NmU2M2E5OWM5ZDg3ZmNhNDk3NDQ5MmY2MGFmOTlhMmU3YQo+ID4+
IGJsa3RhcDogcmVtb3ZlIEhBVkVfQllURVNXQVBfSCBjaGVja2luZywgc2luY2UgaXQncyBkZWZp
bmVkIGJ5IHFlbXUKPiA+Pgo+ID4+IGJsa3RhcCB3YXMgdXNpbmcgZGVmaW5lcyBzZXQgYnkgcWVt
dSwgZXZlbiB3aGVuIHRoZSBxZW11IGNvbmZpZyBmaWxlCj4gPj4gaXMgbm90IGluY2x1ZGVkLiBS
ZW1vdmUgdGhpcyBjaGVja2luZ3MsIGFuZCBpbnN0ZWFkIGNoZWNrIGlmIHRoZSBmaWxlCj4gPj4g
aGFzIGJlZW4gaW5jbHVkZWQgYmVmb3JlIGRlZmluaW5nIHRoZSBuZWNlc3NhcnkgbWFjcm9zLgo+
ID4+Cj4gPj4gVGhlIG91dHB1dCBlcnJvciBpczoKPiA+Pgo+ID4+IEluIGZpbGUgaW5jbHVkZWQg
ZnJvbSBibG9jay1xY293LmM6Mzc6MDoKPiA+PiBic3dhcC5oOjIzOjA6IGVycm9yOiAiYnN3YXBf
MTYiIHJlZGVmaW5lZCBbLVdlcnJvcl0KPiA+PiAvdXNyL2luY2x1ZGUvYnl0ZXN3YXAuaDozMDow
OiBub3RlOiB0aGlzIGlzIHRoZSBsb2NhdGlvbiBvZiB0aGUKPiA+PiBwcmV2aW91cyBkZWZpbml0
aW9uCj4gPj4gYnN3YXAuaDozMTowOiBlcnJvcjogImJzd2FwXzMyIiByZWRlZmluZWQgWy1XZXJy
b3JdCj4gPj4gL3Vzci9pbmNsdWRlL2J5dGVzd2FwLmg6MzM6MDogbm90ZTogdGhpcyBpcyB0aGUg
bG9jYXRpb24gb2YgdGhlCj4gPj4gcHJldmlvdXMgZGVmaW5pdGlvbgo+ID4+IGJzd2FwLmg6NDE6
MDogZXJyb3I6ICJic3dhcF82NCIgcmVkZWZpbmVkIFstV2Vycm9yXQo+ID4+IC91c3IvaW5jbHVk
ZS9ieXRlc3dhcC5oOjM3OjA6IG5vdGU6IHRoaXMgaXMgdGhlIGxvY2F0aW9uIG9mIHRoZQo+ID4+
IHByZXZpb3VzIGRlZmluaXRpb24KPiA+PiBjYzE6IGFsbCB3YXJuaW5ncyBiZWluZyB0cmVhdGVk
IGFzIGVycm9ycwo+ID4+Cj4gPj4gU2lnbmVkLW9mZi1ieTogUm9nZXIgUGF1IE1vbm5lIDxyb2dl
ci5wYXVAZW50ZWwudXBjLmVkdT4KPiA+Pgo+ID4+IGRpZmYgLXIgYjc4M2U3NmU2M2E5IC1yIGVl
ZDc4ZWI2NTVjNCB0b29scy9ibGt0YXAvZHJpdmVycy9ic3dhcC5oCj4gPj4gLS0tIGEvdG9vbHMv
YmxrdGFwL2RyaXZlcnMvYnN3YXAuaCAgICBTdW4gRGVjIDE4IDAyOjI5OjQyIDIwMTEgKzAxMDAK
PiA+PiArKysgYi90b29scy9ibGt0YXAvZHJpdmVycy9ic3dhcC5oICAgIFN1biBEZWMgMTggMDI6
Mjk6NDIgMjAxMSArMDEwMAo+ID4+IEBAIC0xNSw5ICsxNSw3IEBACj4gPj4gICNkZWZpbmUgYnN3
YXBfNjQoeCkgc3dhcDY0KHgpCj4gPj4gICNlbHNlCj4gPj4KPiA+PiAtI2lmZGVmIEhBVkVfQllU
RVNXQVBfSAo+ID4+IC0jaW5jbHVkZSA8Ynl0ZXN3YXAuaD4KPiA+PiAtI2Vsc2UKPiA+PiArI2lm
bmRlZiBfQllURVNXQVBfSAo+ID4KPiA+IFRoaXMgaXMgYmFzaWNhbGx5IHNheWluZyAiaWYgdGhl
IHVzZXIgaGFzbid0IGFscmVhZHkgaW5jbHVkZSBieXRlc3dhcC5oIgo+ID4gYnV0IGl0IHNlZW1z
IHRvIHJlbHkgb24gdGhhdCBoZWFkZXIgdXNpbmcgdGhlIHByZWNpc2UgZ3VhcmQgX0JZVEVTV0FQ
X0gKPiA+IHdoaWNoIEkgcHJlc3VtZSBjYW4gZGlmZmVyIGFjcm9zcyBwbGF0Zm9ybXMuIEkgZG9u
J3QgdGhpbmsgdGhpcyBpcyBhCj4gPiB2aWFibGUgYXBwcm9hY2guCj4gCj4gRnJvbSB3aGF0IEkg
c2F3IF9CWVRFU1dBUF9IIGlzIGRlZmluZWQgaW4gdWNsaWJjIGFuZCBnbGliYyAoU29sYXJpcwo+
IGFuZCBOZXRCU0QgaGF2ZSB0aGVpciBvd24gcHJlcHJvY2Vzc29yIGxvZ2ljLCBzbyB0aGlzIGRv
ZXNuJ3QgYXBwbHkgdG8KPiB0aGVtKS4gSXQncyBqdXN0IGEgc2FmZWd1YXJkIHRoYXQgYXZvaWRz
IHJlZGVmaW5pbmcgdGhlIG1hY3JvcyBpZgo+IHNvbWVvbmUgaGFzIGluY2x1ZGVkIGJ5dGVzd2Fw
LmggYmVoaW5kIG91ciBiYWNrcy4KCkl0J3Mgbm90IGFuIGVmZmVjdGl2ZSBzYWZlZ3VhcmQgdGhv
dWdoLgoKPiA+IEdpdmVuIHRoYXQgd2UgaGF2ZSBvdXIgb3duIGRlZmluaXRpb25zIG9mIHRoZXNl
IHRoaW5ncyBhbnkgd2h5IG5vdCBqdXN0Cj4gPiByZW1vdmUgdGhlIGlmZGVmIGFuZCBzaW5nbGUg
dGhlIG90aGVyICNpbmNsdWRlIG9mIGJ5dGVzd2FwLmggYW5kIGFsd2F5cwo+ID4gdXNlIHRoZSBv
bmVzIHdlIGRlZmluZWQ/Cj4gPgo+ID4gVGhlIG90aGVyIGFsdGVybmF0aXZlIGlzIHRvIHJlbW92
ZSBvdXIgb3duIHZlcnNpb24gYW5kIGFsd2F5cyBpbmNsdWRlCj4gPiBieXRlc3dhcC5oLgo+ID4K
PiA+IFRoZSByaWdodCBhbnN3ZXIgZGVwZW5kcyBvbiBob3cgc3RhbmRhcmRpc2VkIGJ5dGVzd2Fw
LmggaXMuIEl0IHNlZW1zIHRvCj4gPiBiZSBpbiBnbGliYyBidXQgaXMgaXQgaW4gdWNsaWJjIGFu
ZCB0aGUgQlNEIGxpYmNzPyBJIGNhbid0IGZpbmQgYQo+ID4gZGVmaW5pdGl2ZSByZWZlcmVuY2Ug
YnV0IGl0IHNlZW1zIGxpa2UgaXQgaXMgc3BlY2lmaWVkIGJ5IFBPU0lYPwo+IAo+IFRoZSBzb2x1
dGlvbnMgSSBzZWUgYXJlOgo+IAo+ICAqIENoZWNrIGlmIGJ5dGVzd2FwLmggaGFzIGJlZW4gaW5j
bHVkZWQgKHRoaXMgcGF0Y2gpLgo+ICAqIHVuZGVmIGJzd2FwXyogZnVuY3Rpb25zIGFuZCBkZWZp
bmUgb3VyIG93bi4KPiAgKiBJbmNsdWRlIGJ5dGVzd2FwLmguCgogICAqIE5ldmVyIGluY2x1ZGUg
Ynl0ZXN3YXAuaCBhbmQgdXNlIG91ciBvd24gYnN3YXBfKiBmdW5jdGlvbnMgd2hpY2ggd2UKICAg
ICBhbHJlYWR5IGRlZmluZS4KCkkgdGhpbmsgdGhpcyBpcyB0aGUgY29ycmVjdCBvcHRpb24uIE5v
IG5lZWQgdG8gdW5kZWYgc3R1ZmYuIFRoZXJlIGlzCm9ubHkgb25lIG90aGVyIGluY2x1ZGUgb2Yg
Ynl0ZXN3YXAuaCBpbiBibGt0YXAuCgpJYW4uCgoKCl9fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxp
c3RzLnhlbnNvdXJjZS5jb20KaHR0cDovL2xpc3RzLnhlbnNvdXJjZS5jb20veGVuLWRldmVsCg==

From xen-devel-bounces@lists.xensource.com Mon Dec 19 10:08:43 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 10:08:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rca92-0001Qx-Bk; Mon, 19 Dec 2011 10:08:32 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <nenolod@dereferenced.org>) id 1Rca91-0001Pk-9v
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 10:08:31 +0000
X-Env-Sender: nenolod@dereferenced.org
X-Msg-Ref: server-14.tower-174.messagelabs.com!1324289303!5885161!1
X-Originating-IP: [209.85.160.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12065 invoked from network); 19 Dec 2011 10:08:25 -0000
Received: from mail-pw0-f43.google.com (HELO mail-pw0-f43.google.com)
	(209.85.160.43)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Dec 2011 10:08:25 -0000
Received: by pbbb11 with SMTP id b11so19611970pbb.30
	for <xen-devel@lists.xensource.com>;
	Mon, 19 Dec 2011 02:08:23 -0800 (PST)
MIME-Version: 1.0
Received: by 10.68.191.8 with SMTP id gu8mr38019295pbc.36.1324289302896; Mon,
	19 Dec 2011 02:08:22 -0800 (PST)
Received: by 10.143.142.18 with HTTP; Mon, 19 Dec 2011 02:08:22 -0800 (PST)
In-Reply-To: <c54c326d6fdf26d311c8.1324212502@alpine.localdomain>
References: <patchbomb.1324212500@alpine.localdomain>
	<c54c326d6fdf26d311c8.1324212502@alpine.localdomain>
Date: Mon, 19 Dec 2011 04:08:22 -0600
Message-ID: <CA+T2pCGfKKfX=b29q51LY-QifE73jgWdQssz8D_QtUJLJnTHcw@mail.gmail.com>
From: William Pitcock <nenolod@dereferenced.org>
To: Roger Pau Monne <roger.pau@entel.upc.edu>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 2 of 5] build: detect uclibc
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi,

On Sun, Dec 18, 2011 at 6:48 AM, Roger Pau Monne
<roger.pau@entel.upc.edu> wrote:
> # HG changeset patch
> # User Roger Pau Monne <roger.pau@entel.upc.edu>
> # Date 1324171782 -3600
> # Node ID c54c326d6fdf26d311c872479b769b3a8cd560cf
> # Parent =A0eed78eb655c40b0ac9af1b14c1cc03204f696b0b
> build: detect uclibc
>
> Detect uclibc build environment and define CONFIG_UCLIBC accordingly.
>
> Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>
>
> diff -r eed78eb655c4 -r c54c326d6fdf Config.mk
> --- a/Config.mk Sun Dec 18 02:29:42 2011 +0100
> +++ b/Config.mk Sun Dec 18 02:29:42 2011 +0100
> @@ -18,6 +18,8 @@ XEN_TARGET_ARCH =A0 =A0 ?=3D $(XEN_COMPILE_ARC
> =A0XEN_OS =A0 =A0 =A0 =A0 =A0 =A0 =A0?=3D $(shell uname -s)
>
> =A0CONFIG_$(XEN_OS) :=3D y
> +CONFIG_UCLIBC =A0 =A0:=3D $(shell gcc -dumpmachine | grep -c uclibc \
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| sed -e s/[^0]/y/ -e s/0/n/)

I don't like this approach as it introduces an explicit dependency on
gcc just to find out if we're on uclibc or not.  Please find a
different way to do this.  Checking for
/usr/include/bits/uClibc_config.h should be sufficient, e.g.

$(shell test -f /usr/include/bits/uClibc_config.h && echo 'y' || echo 'n')

This approach would be cleaner, please use it instead.

William

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 10:08:43 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 10:08:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rca92-0001Qx-Bk; Mon, 19 Dec 2011 10:08:32 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <nenolod@dereferenced.org>) id 1Rca91-0001Pk-9v
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 10:08:31 +0000
X-Env-Sender: nenolod@dereferenced.org
X-Msg-Ref: server-14.tower-174.messagelabs.com!1324289303!5885161!1
X-Originating-IP: [209.85.160.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12065 invoked from network); 19 Dec 2011 10:08:25 -0000
Received: from mail-pw0-f43.google.com (HELO mail-pw0-f43.google.com)
	(209.85.160.43)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Dec 2011 10:08:25 -0000
Received: by pbbb11 with SMTP id b11so19611970pbb.30
	for <xen-devel@lists.xensource.com>;
	Mon, 19 Dec 2011 02:08:23 -0800 (PST)
MIME-Version: 1.0
Received: by 10.68.191.8 with SMTP id gu8mr38019295pbc.36.1324289302896; Mon,
	19 Dec 2011 02:08:22 -0800 (PST)
Received: by 10.143.142.18 with HTTP; Mon, 19 Dec 2011 02:08:22 -0800 (PST)
In-Reply-To: <c54c326d6fdf26d311c8.1324212502@alpine.localdomain>
References: <patchbomb.1324212500@alpine.localdomain>
	<c54c326d6fdf26d311c8.1324212502@alpine.localdomain>
Date: Mon, 19 Dec 2011 04:08:22 -0600
Message-ID: <CA+T2pCGfKKfX=b29q51LY-QifE73jgWdQssz8D_QtUJLJnTHcw@mail.gmail.com>
From: William Pitcock <nenolod@dereferenced.org>
To: Roger Pau Monne <roger.pau@entel.upc.edu>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 2 of 5] build: detect uclibc
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi,

On Sun, Dec 18, 2011 at 6:48 AM, Roger Pau Monne
<roger.pau@entel.upc.edu> wrote:
> # HG changeset patch
> # User Roger Pau Monne <roger.pau@entel.upc.edu>
> # Date 1324171782 -3600
> # Node ID c54c326d6fdf26d311c872479b769b3a8cd560cf
> # Parent =A0eed78eb655c40b0ac9af1b14c1cc03204f696b0b
> build: detect uclibc
>
> Detect uclibc build environment and define CONFIG_UCLIBC accordingly.
>
> Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>
>
> diff -r eed78eb655c4 -r c54c326d6fdf Config.mk
> --- a/Config.mk Sun Dec 18 02:29:42 2011 +0100
> +++ b/Config.mk Sun Dec 18 02:29:42 2011 +0100
> @@ -18,6 +18,8 @@ XEN_TARGET_ARCH =A0 =A0 ?=3D $(XEN_COMPILE_ARC
> =A0XEN_OS =A0 =A0 =A0 =A0 =A0 =A0 =A0?=3D $(shell uname -s)
>
> =A0CONFIG_$(XEN_OS) :=3D y
> +CONFIG_UCLIBC =A0 =A0:=3D $(shell gcc -dumpmachine | grep -c uclibc \
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| sed -e s/[^0]/y/ -e s/0/n/)

I don't like this approach as it introduces an explicit dependency on
gcc just to find out if we're on uclibc or not.  Please find a
different way to do this.  Checking for
/usr/include/bits/uClibc_config.h should be sufficient, e.g.

$(shell test -f /usr/include/bits/uClibc_config.h && echo 'y' || echo 'n')

This approach would be cleaner, please use it instead.

William

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 10:33:51 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 10: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.xensource.com>)
	id 1RcaXC-00020h-Ri; Mon, 19 Dec 2011 10:33:30 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <liang.tang@oracle.com>) id 1RcaXC-00020c-0o
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 10:33:30 +0000
X-Env-Sender: liang.tang@oracle.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1324290802!7997392!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDQ5OTU4\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10819 invoked from network); 19 Dec 2011 10:33:23 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-12.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 19 Dec 2011 10:33:23 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pBJAXFiS003402
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 19 Dec 2011 10:33:16 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pBJAXATN010586
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 19 Dec 2011 10:33:11 GMT
Received: from abhmt118.oracle.com (abhmt118.oracle.com [141.146.116.70])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pBJAX8MP013099; Mon, 19 Dec 2011 04:33:08 -0600
Received: from [10.182.38.104] (/10.182.38.104)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 19 Dec 2011 02:33:08 -0800
Message-ID: <4EEF12DD.2020308@oracle.com>
Date: Mon, 19 Dec 2011 18:33:01 +0800
From: liang tang <liang.tang@oracle.com>
Organization: Oracle Corporation
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.9.2.23) Gecko/20110920 Thunderbird/3.1.15
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <1322673664-14642-1-git-send-email-konrad.wilk@oracle.com>
	<1322673664-14642-5-git-send-email-konrad.wilk@oracle.com>
	<20111216213618.GB9832@phenom.dumpdata.com>
In-Reply-To: <20111216213618.GB9832@phenom.dumpdata.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090207.4EEF12ED.00BB,ss=1,re=0.000,fgs=0
Cc: jeremy@goop.org, xen-devel@lists.xensource.com, Ian.Campbell@citrix.com,
	konrad@kernel.org, mike.mcclurg@citrix.com,
	stefan.bader@canonical.com, rjw@sisk.pl,
	linux-acpi@vger.kernel.org, lenb@kernel.org
Subject: Re: [Xen-devel] [PATCH 4/8] ACPI: processor: Don't setup cpu idle
 driver and handler when we do not want them.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 2011-12-17 5:36, Konrad Rzeszutek Wilk wrote:
> On Wed, Nov 30, 2011 at 12:21:00PM -0500, Konrad Rzeszutek Wilk wrote:
>> From: Kevin Tian<kevin.tian@intel.com>
>>
>> This patch inhibits processing of the CPU idle handler if it is not
>> set to the appropiate one. This is needed by the Xen processor driver
>> which, while still needing processor details, wants to use the default_idle
>> call (which makes a yield hypercall).
> Which I think is not required anymore with the d91ee5863b71e8c90eaf6035bff3078a85e2e7b5
> (cpuidle: replace xen access to x86 pm_idle and default_idle) and
> 62027aea23fcd14478abdddd3b74a4e0f5fb2984
> (cpuidle: create bootparam "cpuidle.off=1")
>
> Liang, can you double-check that please?
>
Hi,Konrad
I just read the code ,I think  don't need that code too. I will double 
check tomorrow.
thanks
liang

>> Signed-off-by: Yu Ke<ke.yu@intel.com>
>> Signed-off-by: Tian Kevin<kevin.tian@intel.com>
>> Signed-off-by: Tang Liang<liang.tang@oracle.com>
>> Signed-off-by: Konrad Rzeszutek Wilk<konrad.wilk@oracle.com>
>> ---
>>   drivers/acpi/processor_idle.c |    8 +++++---
>>   1 files changed, 5 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/acpi/processor_idle.c b/drivers/acpi/processor_idle.c
>> index d88974a..0ad347f 100644
>> --- a/drivers/acpi/processor_idle.c
>> +++ b/drivers/acpi/processor_idle.c
>> @@ -1127,7 +1127,7 @@ int acpi_processor_hotplug(struct acpi_processor *pr)
>>   	cpuidle_pause_and_lock();
>>   	cpuidle_disable_device(&pr->power.dev);
>>   	acpi_processor_get_power_info(pr);
>> -	if (pr->flags.power) {
>> +	if (pr->flags.power&&  (cpuidle_get_driver() ==&acpi_idle_driver)) {
>>   		acpi_processor_setup_cpuidle_cx(pr);
>>   		ret = cpuidle_enable_device(&pr->power.dev);
>>   	}
>> @@ -1183,7 +1183,8 @@ int acpi_processor_cst_has_changed(struct acpi_processor *pr)
>>   			if (!_pr || !_pr->flags.power_setup_done)
>>   				continue;
>>   			acpi_processor_get_power_info(_pr);
>> -			if (_pr->flags.power) {
>> +			if (_pr->flags.power&&  (cpuidle_get_driver()
>> +						==&acpi_idle_driver)) {
>>   				acpi_processor_setup_cpuidle_cx(_pr);
>>   				cpuidle_enable_device(&_pr->power.dev);
>>   			}
>> @@ -1237,7 +1238,8 @@ int __cpuinit acpi_processor_power_init(struct acpi_processor *pr,
>>   	 * Note that we use previously set idle handler will be used on
>>   	 * platforms that only support C1.
>>   	 */
>> -	if (pr->flags.power) {
>> +	if (pr->flags.power&&  (__acpi_processor_register_driver ==
>> +				acpi_processor_register_driver)) {
>>   		/* Register acpi_idle_driver if not already registered */
>>   		if (!acpi_processor_registered) {
>>   			acpi_processor_setup_cpuidle_states(pr);
>> -- 
>> 1.7.7.3

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 10:33:51 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 10: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.xensource.com>)
	id 1RcaXC-00020h-Ri; Mon, 19 Dec 2011 10:33:30 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <liang.tang@oracle.com>) id 1RcaXC-00020c-0o
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 10:33:30 +0000
X-Env-Sender: liang.tang@oracle.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1324290802!7997392!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDQ5OTU4\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10819 invoked from network); 19 Dec 2011 10:33:23 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-12.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 19 Dec 2011 10:33:23 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pBJAXFiS003402
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 19 Dec 2011 10:33:16 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pBJAXATN010586
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 19 Dec 2011 10:33:11 GMT
Received: from abhmt118.oracle.com (abhmt118.oracle.com [141.146.116.70])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pBJAX8MP013099; Mon, 19 Dec 2011 04:33:08 -0600
Received: from [10.182.38.104] (/10.182.38.104)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 19 Dec 2011 02:33:08 -0800
Message-ID: <4EEF12DD.2020308@oracle.com>
Date: Mon, 19 Dec 2011 18:33:01 +0800
From: liang tang <liang.tang@oracle.com>
Organization: Oracle Corporation
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.9.2.23) Gecko/20110920 Thunderbird/3.1.15
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <1322673664-14642-1-git-send-email-konrad.wilk@oracle.com>
	<1322673664-14642-5-git-send-email-konrad.wilk@oracle.com>
	<20111216213618.GB9832@phenom.dumpdata.com>
In-Reply-To: <20111216213618.GB9832@phenom.dumpdata.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090207.4EEF12ED.00BB,ss=1,re=0.000,fgs=0
Cc: jeremy@goop.org, xen-devel@lists.xensource.com, Ian.Campbell@citrix.com,
	konrad@kernel.org, mike.mcclurg@citrix.com,
	stefan.bader@canonical.com, rjw@sisk.pl,
	linux-acpi@vger.kernel.org, lenb@kernel.org
Subject: Re: [Xen-devel] [PATCH 4/8] ACPI: processor: Don't setup cpu idle
 driver and handler when we do not want them.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 2011-12-17 5:36, Konrad Rzeszutek Wilk wrote:
> On Wed, Nov 30, 2011 at 12:21:00PM -0500, Konrad Rzeszutek Wilk wrote:
>> From: Kevin Tian<kevin.tian@intel.com>
>>
>> This patch inhibits processing of the CPU idle handler if it is not
>> set to the appropiate one. This is needed by the Xen processor driver
>> which, while still needing processor details, wants to use the default_idle
>> call (which makes a yield hypercall).
> Which I think is not required anymore with the d91ee5863b71e8c90eaf6035bff3078a85e2e7b5
> (cpuidle: replace xen access to x86 pm_idle and default_idle) and
> 62027aea23fcd14478abdddd3b74a4e0f5fb2984
> (cpuidle: create bootparam "cpuidle.off=1")
>
> Liang, can you double-check that please?
>
Hi,Konrad
I just read the code ,I think  don't need that code too. I will double 
check tomorrow.
thanks
liang

>> Signed-off-by: Yu Ke<ke.yu@intel.com>
>> Signed-off-by: Tian Kevin<kevin.tian@intel.com>
>> Signed-off-by: Tang Liang<liang.tang@oracle.com>
>> Signed-off-by: Konrad Rzeszutek Wilk<konrad.wilk@oracle.com>
>> ---
>>   drivers/acpi/processor_idle.c |    8 +++++---
>>   1 files changed, 5 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/acpi/processor_idle.c b/drivers/acpi/processor_idle.c
>> index d88974a..0ad347f 100644
>> --- a/drivers/acpi/processor_idle.c
>> +++ b/drivers/acpi/processor_idle.c
>> @@ -1127,7 +1127,7 @@ int acpi_processor_hotplug(struct acpi_processor *pr)
>>   	cpuidle_pause_and_lock();
>>   	cpuidle_disable_device(&pr->power.dev);
>>   	acpi_processor_get_power_info(pr);
>> -	if (pr->flags.power) {
>> +	if (pr->flags.power&&  (cpuidle_get_driver() ==&acpi_idle_driver)) {
>>   		acpi_processor_setup_cpuidle_cx(pr);
>>   		ret = cpuidle_enable_device(&pr->power.dev);
>>   	}
>> @@ -1183,7 +1183,8 @@ int acpi_processor_cst_has_changed(struct acpi_processor *pr)
>>   			if (!_pr || !_pr->flags.power_setup_done)
>>   				continue;
>>   			acpi_processor_get_power_info(_pr);
>> -			if (_pr->flags.power) {
>> +			if (_pr->flags.power&&  (cpuidle_get_driver()
>> +						==&acpi_idle_driver)) {
>>   				acpi_processor_setup_cpuidle_cx(_pr);
>>   				cpuidle_enable_device(&_pr->power.dev);
>>   			}
>> @@ -1237,7 +1238,8 @@ int __cpuinit acpi_processor_power_init(struct acpi_processor *pr,
>>   	 * Note that we use previously set idle handler will be used on
>>   	 * platforms that only support C1.
>>   	 */
>> -	if (pr->flags.power) {
>> +	if (pr->flags.power&&  (__acpi_processor_register_driver ==
>> +				acpi_processor_register_driver)) {
>>   		/* Register acpi_idle_driver if not already registered */
>>   		if (!acpi_processor_registered) {
>>   			acpi_processor_setup_cpuidle_states(pr);
>> -- 
>> 1.7.7.3

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 10:33:55 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 10:33:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RcaXN-00021C-9O; Mon, 19 Dec 2011 10:33:41 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RcaXM-00020s-09
	for Xen-devel@lists.xensource.com; Mon, 19 Dec 2011 10:33:40 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1324290812!6064638!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzA0OQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2558 invoked from network); 19 Dec 2011 10:33:33 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Dec 2011 10:33:33 -0000
X-IronPort-AV: E=Sophos;i="4.71,375,1320624000"; 
   d="scan'208";a="9550143"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Dec 2011 10:33:32 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 19 Dec 2011 10:33:32 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Date: Mon, 19 Dec 2011 10:33:32 +0000
In-Reply-To: <1323893534-436-6-git-send-email-dgdegra@tycho.nsa.gov>
References: <1323893534-436-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1323893534-436-6-git-send-email-dgdegra@tycho.nsa.gov>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1324290812.9236.22.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH 5/6] xen/netback: Enable netback on HVM
 guests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2011-12-14 at 20:12 +0000, Daniel De Graaf wrote:
> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

(which I've said before, please always retain Acks etc across postings
so people don't waste their time re-reviewing things.)

We previously (http://marc.info/?l=xen-devel&m=131944893321681&w=2)
agreed with Dave Miller that this could go via Konrad's tree which could
have been very usefully noted here also.

> ---
>  drivers/net/xen-netback/netback.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
> index 0cb594c..951c713 100644
> --- a/drivers/net/xen-netback/netback.c
> +++ b/drivers/net/xen-netback/netback.c
> @@ -1638,7 +1638,7 @@ static int __init netback_init(void)
>  	int rc = 0;
>  	int group;
>  
> -	if (!xen_pv_domain())
> +	if (!xen_domain())
>  		return -ENODEV;
>  
>  	xen_netbk_group_nr = num_online_cpus();



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 10:33:55 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 10:33:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RcaXN-00021C-9O; Mon, 19 Dec 2011 10:33:41 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RcaXM-00020s-09
	for Xen-devel@lists.xensource.com; Mon, 19 Dec 2011 10:33:40 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1324290812!6064638!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzA0OQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2558 invoked from network); 19 Dec 2011 10:33:33 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Dec 2011 10:33:33 -0000
X-IronPort-AV: E=Sophos;i="4.71,375,1320624000"; 
   d="scan'208";a="9550143"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Dec 2011 10:33:32 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 19 Dec 2011 10:33:32 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Date: Mon, 19 Dec 2011 10:33:32 +0000
In-Reply-To: <1323893534-436-6-git-send-email-dgdegra@tycho.nsa.gov>
References: <1323893534-436-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1323893534-436-6-git-send-email-dgdegra@tycho.nsa.gov>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1324290812.9236.22.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH 5/6] xen/netback: Enable netback on HVM
 guests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2011-12-14 at 20:12 +0000, Daniel De Graaf wrote:
> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

(which I've said before, please always retain Acks etc across postings
so people don't waste their time re-reviewing things.)

We previously (http://marc.info/?l=xen-devel&m=131944893321681&w=2)
agreed with Dave Miller that this could go via Konrad's tree which could
have been very usefully noted here also.

> ---
>  drivers/net/xen-netback/netback.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
> index 0cb594c..951c713 100644
> --- a/drivers/net/xen-netback/netback.c
> +++ b/drivers/net/xen-netback/netback.c
> @@ -1638,7 +1638,7 @@ static int __init netback_init(void)
>  	int rc = 0;
>  	int group;
>  
> -	if (!xen_pv_domain())
> +	if (!xen_domain())
>  		return -ENODEV;
>  
>  	xen_netbk_group_nr = num_online_cpus();



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 10:37:38 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 10:37:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rcaax-0002Eg-Uz; Mon, 19 Dec 2011 10:37:23 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1Rcaav-0002E0-I0
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 10:37:21 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1324291035!7755730!1
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4150 invoked from network); 19 Dec 2011 10:37:15 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Dec 2011 10:37:15 -0000
Received: by wgbds11 with SMTP id ds11so8774925wgb.24
	for <xen-devel@lists.xensource.com>;
	Mon, 19 Dec 2011 02:37:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=beekYXnfV5mx59h8jzl08nLMxuqFnDh6BOrvzoDcMe8=;
	b=Ba3CpeJxgEe70vZe1QJedH95VAMWoobbzfxciDDzBzua0j3meLLmXhBcF31VYGGZDI
	0AL4cZDC7j6c/lKcEV4bxwFmqsmYZn8IIGhPzFSb60vfCVJN3TgVQA0icQsBWJ9j2Pbr
	DFvZU4n8x6rjPNn3sZDXMJM8hzGDsAWYpK8Gs=
MIME-Version: 1.0
Received: by 10.180.8.162 with SMTP id s2mr5313641wia.29.1324291034734; Mon,
	19 Dec 2011 02:37:14 -0800 (PST)
Received: by 10.216.0.212 with HTTP; Mon, 19 Dec 2011 02:37:14 -0800 (PST)
In-Reply-To: <35e4701f.ca5a.1344b4ed98e.Coremail.gbtux@126.com>
References: <26c93838.3b3fb.13445de0e67.Coremail.gbtux@126.com>
	<CAFLBxZYM-8vEc5Egmv+iXqMDUE_UJcgHbwr7=71H-kFowTzXWA@mail.gmail.com>
	<676b608e.2fb26.13447553671.Coremail.gbtux@126.com>
	<CAFLBxZaBiwEvz-dgPzgBQQTj2xMi8m+QnZ3M+uoqw4AKmb0ZvA@mail.gmail.com>
	<35e4701f.ca5a.1344b4ed98e.Coremail.gbtux@126.com>
Date: Mon, 19 Dec 2011 10:37:14 +0000
X-Google-Sender-Auth: pDGLKIh_J-7rBpMUSQYITDpLMM4
Message-ID: <CAFLBxZZP=K504L86WDJ-F+9SuTf7aKU_C=i8nLZwqDuejoVGag@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: gavin <gbtux@126.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] A question on the credit scheduler
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

2011/12/17 gavin <gbtux@126.com>:
>
> At=A02011-12-16=A023:58:26,"George=A0Dunlap"=A0<George.Dunlap@eu.citrix.c=
om>=A0wrote:
>>2011/12/16=A0gavin=A0<gbtux@126.com>:
>>>=A0At=A02011-12-16=A019:04:19,"George=A0Dunlap"=A0<George.Dunlap@eu.citr=
ix.com>=A0wrote:
>>>
>>>>2011/12/16=A0zhikai=A0<gbtux@126.com>:
>>>>>=A0Hi=A0All,
>>>>>
>>>>>=A0In=A0the=A0credit=A0scheduler,=A0the=A0scheduling=A0decision=A0func=
tion=A0csched_schedule()
>>>>>=A0is=A0called=A0in=A0the=A0schedule=A0function=A0in=A0scheduler.c,=A0=
such=A0as=A0the=A0following.
>>>>>=A0next_slice=A0=3D=A0sched->do_schedule(sched,=A0now,=A0tasklet_work_=
scheduled);
>>>>>
>>>>>=A0But,=A0how=A0often=A0the=A0csched_schedule()=A0is=A0called=A0and=A0=
to=A0run?=A0Does=A0this
>>>>>=A0frequency=A0have=A0something=A0to=A0do=A0with=A0the=A0slice=A0of=A0=
credit=A0scheduler=A0that=A0is
>>>>>=A030ms?
>>>>
>>>>The=A0scheduler=A0runs=A0whenever=A0the=A0SCHEDULE_SOFTIRQ=A0is=A0raise=
d.=A0=A0If=A0you
>>>>grep=A0through=A0the=A0source=A0code=A0fro=A0that=A0string,=A0you=A0can=
=A0find=A0all=A0the
>>>>places=A0where=A0it's=A0raised.
>>>>
>>>>Some=A0examples=A0include:
>>>>*=A0When=A0the=A030ms=A0timeslice=A0is=A0finished
>>>>*=A0When=A0a=A0sleeping=A0vcpu=A0of=A0higher=A0priority=A0than=A0what's=
=A0currently=A0running=A0wakes=A0up
>>>>*=A0When=A0a=A0vcpu=A0blocks
>>>>*=A0When=A0a=A0vcpu=A0is=A0migrated=A0from=A0one=A0cpu=A0to=A0another
>>>>
>>>>30ms=A0is=A0actually=A0a=A0pretty=A0long=A0time;=A0in=A0typical=A0workl=
oads,=A0vcpus=A0block
>>>>or=A0are=A0preempted=A0by=A0other=A0waking=A0vcpus=A0without=A0using=A0=
up=A0their=A0full
>>>>timeslice.
>>>
>>>=A0Thank=A0you=A0very=A0much=A0for=A0your=A0reply.
>>>
>>>=A0So,=A0the=A0vcpu=A0is=A0very=A0likely=A0to=A0be=A0preempted=A0wheneve=
r=A0the=A0SCHEDULE_SOFTIRQ=A0is
>>>=A0raised.
>>
>>It=A0depends;=A0if=A0you=A0have=A0a=A0cpu-burning=A0vcpu=A0running=A0on=
=A0a=A0cpu=A0all=A0by
>>itself,=A0then=A0after=A0its=A030ms=A0timeslice,=A0Xen=A0will=A0have=A0no=
=A0one=A0else=A0to
>>run,=A0and=A0so=A0will=A0let=A0it=A0run=A0again.
>>
>>But=A0yes,=A0if=A0there=A0are=A0other=A0vcpus=A0on=A0the=A0runqueue,=A0or=
=A0the=A0host=A0is
>>moderately=A0busy,=A0it's=A0likely=A0that=A0SCHEDULE_SOFTIRQ=A0will=A0cau=
se=A0a
>>context-switch.
>>
>>>=A0And=A0we=A0cannot=A0find=A0a=A0small=A0timeslice,=A0such=A0as=A0a(ms)=
,=A0which=A0makes=A0the
>>>=A0time=A0any=A0vcpu=A0spending=A0on=A0running=A0phase=A0is=A0k*a(ms),=
=A0k=A0is=A0integer=A0here.=A0There
>>>=A0is=A0no=A0such=A0a=A0small=A0timeslice.=A0Is=A0it=A0right?
>>
>>I'm=A0sorry,=A0I=A0don't=A0really=A0understand=A0your=A0question.=A0=A0Pe=
rhaps=A0if=A0you
>>told=A0me=A0what=A0you're=A0trying=A0to=A0accomplish?
>
> I try to describe my idea as the following clearly. But I really don't kn=
ow
> if it will work. Please give me some advice if possible.
>
> According to the credit scheduler in Xen, a vCPU can run a 30ms timeslice
> when it is scheduled on the physical CPU. And, a vCPU with the BOOST
> priority will preempt the running one and run additional 10ms. So, what I
> think is if we monitor the physical CPU every 10ms and we can get the
> mapping information of a physical CPU and a vCPU. And also, we can get the
> un-mapping information that a physical CPU isn=92t mapped to any vCPU. Th=
us,
> we can get the CPU usage by calculating the proportion of the mapping
> information to the total time when we monitored.
>
> For example, if we monitor the physical CPUs every 10ms and we can get 100
> pairs of pCPU and vCPU in a second, such as (pCPU_id, vCPU_id). If there =
is
> 60 mapping pairs that the pCPU is mapped to a valid vPCU, and 40 un-mappi=
ng
> pairs that we cannot find the pCPU to be mapped a valid vCPU. So, we can =
get
> the usage of the physical CPUs that is 60%.
>
> Here, we monitor the physical CPUs every 10ms. We also can monitor them o=
nce
> less than the 10ms interval, such as 1ms interval. Whatever interval we
> choose, we must make sure no CPU content switch in the interval or the
> context switch always occur at the edge of interval. Only in this conditi=
on,
> can this idea work.
>
> So, I am not sure whether we can find such a time interval that can meet
> this condition. In other words, whether we can find such a time interval
> that ensures all the CPU content switch occur at the edge of interval.

You still haven't described exactly what it is you're trying to
accomplish: what is your end goal?  It seems to be related somehow to
measuring how busy the system is (i.e., the number of active pcpus and
idle pcpus); but as I don't know what you want to do with that
information, I can't tell you the best way to get it.

Regarding a map of pcpus to vcpus, that already exists.  The
scheduling code will keep track of the currently running vcpu here:
  per_cpu(schedule_data, pcpu_id).curr

You can see examples of the above structure used in
xen/common/sched_credit2.c.  If "is_idle(per_cpu(schedule_data,
pcpu).curr)" is false, then the cpu is running a vcpu; if it is true,
then the pcpu is idle (although it may be running a tasklet).

Additionally, if all you want is the number of non-idle cpus, the
credit1 scheduler keeps track of the idle and non-idle cpus in
prv->idlers.  You could easily use "cpumask_weight(&prv->idlers)" to
find out how many idle cpus there are at any given time.  If you know
how many online cpus there are, that will give you the busy-ness of
the system.

So now that you have this instantaneous percentage, what do you want
to do with it?

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 10:37:38 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 10:37:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rcaax-0002Eg-Uz; Mon, 19 Dec 2011 10:37:23 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1Rcaav-0002E0-I0
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 10:37:21 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1324291035!7755730!1
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4150 invoked from network); 19 Dec 2011 10:37:15 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Dec 2011 10:37:15 -0000
Received: by wgbds11 with SMTP id ds11so8774925wgb.24
	for <xen-devel@lists.xensource.com>;
	Mon, 19 Dec 2011 02:37:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=beekYXnfV5mx59h8jzl08nLMxuqFnDh6BOrvzoDcMe8=;
	b=Ba3CpeJxgEe70vZe1QJedH95VAMWoobbzfxciDDzBzua0j3meLLmXhBcF31VYGGZDI
	0AL4cZDC7j6c/lKcEV4bxwFmqsmYZn8IIGhPzFSb60vfCVJN3TgVQA0icQsBWJ9j2Pbr
	DFvZU4n8x6rjPNn3sZDXMJM8hzGDsAWYpK8Gs=
MIME-Version: 1.0
Received: by 10.180.8.162 with SMTP id s2mr5313641wia.29.1324291034734; Mon,
	19 Dec 2011 02:37:14 -0800 (PST)
Received: by 10.216.0.212 with HTTP; Mon, 19 Dec 2011 02:37:14 -0800 (PST)
In-Reply-To: <35e4701f.ca5a.1344b4ed98e.Coremail.gbtux@126.com>
References: <26c93838.3b3fb.13445de0e67.Coremail.gbtux@126.com>
	<CAFLBxZYM-8vEc5Egmv+iXqMDUE_UJcgHbwr7=71H-kFowTzXWA@mail.gmail.com>
	<676b608e.2fb26.13447553671.Coremail.gbtux@126.com>
	<CAFLBxZaBiwEvz-dgPzgBQQTj2xMi8m+QnZ3M+uoqw4AKmb0ZvA@mail.gmail.com>
	<35e4701f.ca5a.1344b4ed98e.Coremail.gbtux@126.com>
Date: Mon, 19 Dec 2011 10:37:14 +0000
X-Google-Sender-Auth: pDGLKIh_J-7rBpMUSQYITDpLMM4
Message-ID: <CAFLBxZZP=K504L86WDJ-F+9SuTf7aKU_C=i8nLZwqDuejoVGag@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: gavin <gbtux@126.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] A question on the credit scheduler
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

2011/12/17 gavin <gbtux@126.com>:
>
> At=A02011-12-16=A023:58:26,"George=A0Dunlap"=A0<George.Dunlap@eu.citrix.c=
om>=A0wrote:
>>2011/12/16=A0gavin=A0<gbtux@126.com>:
>>>=A0At=A02011-12-16=A019:04:19,"George=A0Dunlap"=A0<George.Dunlap@eu.citr=
ix.com>=A0wrote:
>>>
>>>>2011/12/16=A0zhikai=A0<gbtux@126.com>:
>>>>>=A0Hi=A0All,
>>>>>
>>>>>=A0In=A0the=A0credit=A0scheduler,=A0the=A0scheduling=A0decision=A0func=
tion=A0csched_schedule()
>>>>>=A0is=A0called=A0in=A0the=A0schedule=A0function=A0in=A0scheduler.c,=A0=
such=A0as=A0the=A0following.
>>>>>=A0next_slice=A0=3D=A0sched->do_schedule(sched,=A0now,=A0tasklet_work_=
scheduled);
>>>>>
>>>>>=A0But,=A0how=A0often=A0the=A0csched_schedule()=A0is=A0called=A0and=A0=
to=A0run?=A0Does=A0this
>>>>>=A0frequency=A0have=A0something=A0to=A0do=A0with=A0the=A0slice=A0of=A0=
credit=A0scheduler=A0that=A0is
>>>>>=A030ms?
>>>>
>>>>The=A0scheduler=A0runs=A0whenever=A0the=A0SCHEDULE_SOFTIRQ=A0is=A0raise=
d.=A0=A0If=A0you
>>>>grep=A0through=A0the=A0source=A0code=A0fro=A0that=A0string,=A0you=A0can=
=A0find=A0all=A0the
>>>>places=A0where=A0it's=A0raised.
>>>>
>>>>Some=A0examples=A0include:
>>>>*=A0When=A0the=A030ms=A0timeslice=A0is=A0finished
>>>>*=A0When=A0a=A0sleeping=A0vcpu=A0of=A0higher=A0priority=A0than=A0what's=
=A0currently=A0running=A0wakes=A0up
>>>>*=A0When=A0a=A0vcpu=A0blocks
>>>>*=A0When=A0a=A0vcpu=A0is=A0migrated=A0from=A0one=A0cpu=A0to=A0another
>>>>
>>>>30ms=A0is=A0actually=A0a=A0pretty=A0long=A0time;=A0in=A0typical=A0workl=
oads,=A0vcpus=A0block
>>>>or=A0are=A0preempted=A0by=A0other=A0waking=A0vcpus=A0without=A0using=A0=
up=A0their=A0full
>>>>timeslice.
>>>
>>>=A0Thank=A0you=A0very=A0much=A0for=A0your=A0reply.
>>>
>>>=A0So,=A0the=A0vcpu=A0is=A0very=A0likely=A0to=A0be=A0preempted=A0wheneve=
r=A0the=A0SCHEDULE_SOFTIRQ=A0is
>>>=A0raised.
>>
>>It=A0depends;=A0if=A0you=A0have=A0a=A0cpu-burning=A0vcpu=A0running=A0on=
=A0a=A0cpu=A0all=A0by
>>itself,=A0then=A0after=A0its=A030ms=A0timeslice,=A0Xen=A0will=A0have=A0no=
=A0one=A0else=A0to
>>run,=A0and=A0so=A0will=A0let=A0it=A0run=A0again.
>>
>>But=A0yes,=A0if=A0there=A0are=A0other=A0vcpus=A0on=A0the=A0runqueue,=A0or=
=A0the=A0host=A0is
>>moderately=A0busy,=A0it's=A0likely=A0that=A0SCHEDULE_SOFTIRQ=A0will=A0cau=
se=A0a
>>context-switch.
>>
>>>=A0And=A0we=A0cannot=A0find=A0a=A0small=A0timeslice,=A0such=A0as=A0a(ms)=
,=A0which=A0makes=A0the
>>>=A0time=A0any=A0vcpu=A0spending=A0on=A0running=A0phase=A0is=A0k*a(ms),=
=A0k=A0is=A0integer=A0here.=A0There
>>>=A0is=A0no=A0such=A0a=A0small=A0timeslice.=A0Is=A0it=A0right?
>>
>>I'm=A0sorry,=A0I=A0don't=A0really=A0understand=A0your=A0question.=A0=A0Pe=
rhaps=A0if=A0you
>>told=A0me=A0what=A0you're=A0trying=A0to=A0accomplish?
>
> I try to describe my idea as the following clearly. But I really don't kn=
ow
> if it will work. Please give me some advice if possible.
>
> According to the credit scheduler in Xen, a vCPU can run a 30ms timeslice
> when it is scheduled on the physical CPU. And, a vCPU with the BOOST
> priority will preempt the running one and run additional 10ms. So, what I
> think is if we monitor the physical CPU every 10ms and we can get the
> mapping information of a physical CPU and a vCPU. And also, we can get the
> un-mapping information that a physical CPU isn=92t mapped to any vCPU. Th=
us,
> we can get the CPU usage by calculating the proportion of the mapping
> information to the total time when we monitored.
>
> For example, if we monitor the physical CPUs every 10ms and we can get 100
> pairs of pCPU and vCPU in a second, such as (pCPU_id, vCPU_id). If there =
is
> 60 mapping pairs that the pCPU is mapped to a valid vPCU, and 40 un-mappi=
ng
> pairs that we cannot find the pCPU to be mapped a valid vCPU. So, we can =
get
> the usage of the physical CPUs that is 60%.
>
> Here, we monitor the physical CPUs every 10ms. We also can monitor them o=
nce
> less than the 10ms interval, such as 1ms interval. Whatever interval we
> choose, we must make sure no CPU content switch in the interval or the
> context switch always occur at the edge of interval. Only in this conditi=
on,
> can this idea work.
>
> So, I am not sure whether we can find such a time interval that can meet
> this condition. In other words, whether we can find such a time interval
> that ensures all the CPU content switch occur at the edge of interval.

You still haven't described exactly what it is you're trying to
accomplish: what is your end goal?  It seems to be related somehow to
measuring how busy the system is (i.e., the number of active pcpus and
idle pcpus); but as I don't know what you want to do with that
information, I can't tell you the best way to get it.

Regarding a map of pcpus to vcpus, that already exists.  The
scheduling code will keep track of the currently running vcpu here:
  per_cpu(schedule_data, pcpu_id).curr

You can see examples of the above structure used in
xen/common/sched_credit2.c.  If "is_idle(per_cpu(schedule_data,
pcpu).curr)" is false, then the cpu is running a vcpu; if it is true,
then the pcpu is idle (although it may be running a tasklet).

Additionally, if all you want is the number of non-idle cpus, the
credit1 scheduler keeps track of the idle and non-idle cpus in
prv->idlers.  You could easily use "cpumask_weight(&prv->idlers)" to
find out how many idle cpus there are at any given time.  If you know
how many online cpus there are, that will give you the busy-ness of
the system.

So now that you have this instantaneous percentage, what do you want
to do with it?

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 10:43:44 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 10: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.xensource.com>)
	id 1Rcagt-0002T4-Pu; Mon, 19 Dec 2011 10:43:31 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Rcags-0002Su-EV
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 10:43:30 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1324291404!7754846!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzA0OQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28060 invoked from network); 19 Dec 2011 10:43:24 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Dec 2011 10:43:24 -0000
X-IronPort-AV: E=Sophos;i="4.71,375,1320624000"; 
   d="scan'208";a="9550465"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Dec 2011 10:43:24 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 19 Dec 2011 10:43:24 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1Rcagl-0003Lc-UE;
	Mon, 19 Dec 2011 10:43:23 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Rcagl-00081h-Rn;
	Mon, 19 Dec 2011 10:43:23 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10545-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 19 Dec 2011 10:43:23 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10545: tolerable FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10545 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10545/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf     13 guest-localmigrate.2        fail pass in 10534

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass

version targeted for testing:
 xen                  e3daa5b58464
baseline version:
 xen                  e3daa5b58464

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 10:43:44 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 10: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.xensource.com>)
	id 1Rcagt-0002T4-Pu; Mon, 19 Dec 2011 10:43:31 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Rcags-0002Su-EV
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 10:43:30 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1324291404!7754846!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzA0OQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28060 invoked from network); 19 Dec 2011 10:43:24 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Dec 2011 10:43:24 -0000
X-IronPort-AV: E=Sophos;i="4.71,375,1320624000"; 
   d="scan'208";a="9550465"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Dec 2011 10:43:24 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 19 Dec 2011 10:43:24 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1Rcagl-0003Lc-UE;
	Mon, 19 Dec 2011 10:43:23 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Rcagl-00081h-Rn;
	Mon, 19 Dec 2011 10:43:23 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10545-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 19 Dec 2011 10:43:23 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10545: tolerable FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10545 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10545/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf     13 guest-localmigrate.2        fail pass in 10534

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass

version targeted for testing:
 xen                  e3daa5b58464
baseline version:
 xen                  e3daa5b58464

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 10:54:48 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 10:54:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RcarU-0002dX-VN; Mon, 19 Dec 2011 10:54:28 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1RcarT-0002dS-Mj
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 10:54:28 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1324292061!2511678!1
X-Originating-IP: [209.85.212.171]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12642 invoked from network); 19 Dec 2011 10:54:21 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Dec 2011 10:54:21 -0000
Received: by wico1 with SMTP id o1so2407599wic.30
	for <xen-devel@lists.xensource.com>;
	Mon, 19 Dec 2011 02:54:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=KlaRZpg0n1gkjenzIOX1TdDw9RSF+PzmhMUpuaEixyM=;
	b=AV6pgfWKIj6XwSeE7rh9j3HPq4iOo+8OE/pYbCfRViZXynZxO2pa8vefkY4hxSeZIs
	lCP4/UUHjwNeSwCFmgIMNnPAHBvN69AMt1KfTLawVNPils4T5BtqJ2h/Hu5+T5/448/k
	utBL2kG7NeJTnYiYvZO5Cv8owhIlk6rrlFR7I=
MIME-Version: 1.0
Received: by 10.180.8.162 with SMTP id s2mr5393646wia.29.1324292061261; Mon,
	19 Dec 2011 02:54:21 -0800 (PST)
Received: by 10.216.0.212 with HTTP; Mon, 19 Dec 2011 02:54:21 -0800 (PST)
In-Reply-To: <C10D3FB0CD45994C8A51FEC1227CE22F37CC284376@shsmsx502.ccr.corp.intel.com>
References: <Acy8a1J98NIQa/LRTpOgi509iCZVqg==>
	<C10D3FB0CD45994C8A51FEC1227CE22F37CC284376@shsmsx502.ccr.corp.intel.com>
Date: Mon, 19 Dec 2011 10:54:21 +0000
X-Google-Sender-Auth: AMDND20rTU5ROejH_e5MwizEg3E
Message-ID: <CAFLBxZYSbT05USq9kf0WsELU8OzkzV80iO7uuyUyQaGFS2sxkA@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: "Lv, Hui" <hui.lv@intel.com>
Cc: "Tian, Kevin" <kevin.tian@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"keir@xen.org" <keir@xen.org>, "Dong, Eddie" <eddie.dong@intel.com>, "Duan,
	Jiangang" <jiangang.duan@intel.com>, "Yu, Zhidong" <zhidong.yu@intel.com>
Subject: Re: [Xen-devel] [PATCH v2] xen/credit scheduler;
 Use delay to control scheduling frequency
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hui,

Unfortunately your mailer is mangling the patch:

 static int __read_mostly sched_credit_tslice_ms =3D3D CSCHED_DEFAULT_TSLIC=
E_=3D
MS;

Try using "hg email", or sending it as an attachment.

 -George

On Sat, Dec 17, 2011 at 3:24 AM, Lv, Hui <hui.lv@intel.com> wrote:
> The delay method for credit scheduler can do as well as SRC patch (previo=
us
> one) to gain significant performance boost without obvious drawbacks.
>
> 1. Basically, the "delay method" can achieve nearly the same benefits as =
my
> previous SRC patch, 11% overall performance boost for SPECvirt than origi=
nal
> credit scheduler.
> 2. We have tried 1ms delay and 10ms delay, there is no big difference
> between these two configurations. (1ms is enough to achieve a good
> performance)
> 3. We have compared different load level response time/latency (low, high,
> peak), "delay method" didn't bring very much response time increase.
> 4. 1ms delay can reduce 30% context switch at peak performance, where
> produces the benefits. (=93int sched_ratelimit_us =3D 1000=94 is the reco=
mmended
> setting)
>
>
> Signed-off-by: Hui Lv <hui.lv@intel.com>
> Signed-off-by: George Dunlap <George.Dunlap@eu.citrix.com>
>
> diff -r 1c58bb664d8d xen/common/sched_credit.c
> --- a/xen/common/sched_credit.c Thu Dec 08 17:15:16 2011 +0000
> +++ b/xen/common/sched_credit.c Fri Dec 16 15:08:09 2011 -0500
> @@ -110,6 +110,9 @@ boolean_param("sched_credit_default_yiel
> static int __read_mostly sched_credit_tslice_ms =3D CSCHED_DEFAULT_TSLICE=
_MS;
> integer_param("sched_credit_tslice_ms", sched_credit_tslice_ms);
>
> +/* Scheduler generic parameters
> +*/
> +extern int sched_ratelimit_us;
> /*
> =A0 * Physical CPU
> =A0 */
> @@ -1297,10 +1300,15 @@ csched_schedule(
> =A0=A0=A0=A0 struct csched_private *prv =3D CSCHED_PRIV(ops);
> =A0=A0=A0=A0 struct csched_vcpu *snext;
> =A0=A0=A0=A0 struct task_slice ret;
> +=A0=A0=A0 s_time_t runtime, tslice;
>
> =A0=A0=A0=A0 CSCHED_STAT_CRANK(schedule);
> =A0=A0=A0=A0 CSCHED_VCPU_CHECK(current);
>
> +=A0=A0=A0 runtime =3D now - current->runstate.state_entry_time;
> +=A0=A0=A0 if ( runtime < 0 ) /* Does this ever happen? */
> +=A0=A0=A0=A0=A0=A0=A0 runtime =3D 0;
> +
> =A0=A0=A0=A0 if ( !is_idle_vcpu(scurr->vcpu) )
> =A0=A0=A0=A0 {
> =A0=A0=A0=A0=A0=A0=A0=A0 /* Update credits of a non-idle VCPU. */
> @@ -1313,6 +1321,41 @@ csched_schedule(
> =A0=A0=A0=A0=A0=A0=A0=A0 scurr->pri =3D CSCHED_PRI_IDLE;
> =A0=A0=A0=A0 }
>
> +=A0=A0=A0 /* Choices, choices:
> +=A0=A0=A0=A0 * - If we have a tasklet, we need to run the idle vcpu no m=
atter what.
> +=A0=A0=A0=A0 * - If sched rate limiting is in effect, and the current vc=
pu has
> +=A0=A0=A0=A0 *=A0=A0 run for less than that amount of time, continue the=
 current one,
> +=A0=A0=A0=A0 *=A0=A0 but with a shorter timeslice and return it immediat=
ely
> +=A0=A0=A0=A0 * - Otherwise, chose the one with the highest priority (whi=
ch may
> +=A0=A0=A0=A0 *=A0=A0 be the one currently running)
> +=A0=A0=A0=A0 * - If the currently running one is TS_OVER, see if there
> +=A0=A0=A0=A0 *=A0=A0 is a higher priority one waiting on the runqueue of=
 another
> +=A0=A0=A0=A0 *=A0=A0 cpu and steal it.
> +=A0=A0=A0=A0 */
> +
> +=A0=A0=A0 /* If we have schedule rate limiting enabled, check to see
> +=A0=A0=A0=A0 * how long we've run for. */
> +=A0=A0=A0 if ( sched_ratelimit_us
> +=A0=A0=A0=A0=A0=A0=A0=A0 && !tasklet_work_scheduled
> +=A0=A0=A0=A0=A0=A0=A0=A0 && vcpu_runnable(current)
> +=A0=A0=A0=A0=A0=A0=A0=A0 && !is_idle_vcpu(current)
> +=A0=A0=A0=A0=A0=A0=A0=A0 && runtime < MICROSECS(sched_ratelimit_us) )
> +=A0=A0=A0 {
> +=A0=A0=A0=A0=A0=A0=A0 snext =3D scurr;
> +=A0=A0=A0=A0=A0=A0=A0 snext->start_time +=3D now;
> +=A0=A0=A0=A0=A0=A0=A0 perfc_incr(delay_ms);
> +=A0=A0=A0=A0=A0=A0=A0 tslice =3D MICROSECS(sched_ratelimit_us);
> +=A0=A0=A0=A0=A0=A0=A0 ret.migrated =3D 0;
> +=A0=A0=A0=A0=A0=A0=A0 goto out;
> +=A0=A0=A0 }
> +=A0=A0=A0 else
> +=A0=A0=A0 {
> +=A0=A0=A0=A0=A0=A0=A0 /*
> +=A0=A0=A0=A0=A0=A0=A0=A0 * Select next runnable local VCPU (ie top of lo=
cal runq)
> +=A0=A0=A0=A0=A0=A0=A0 */
> +=A0=A0=A0=A0=A0=A0=A0 tslice =3D MILLISECS(prv->tslice_ms);
> +=A0=A0=A0 }
> +
> =A0=A0=A0=A0 /*
> =A0=A0=A0=A0=A0 * Select next runnable local VCPU (ie top of local runq)
> =A0=A0=A0=A0=A0 */
> @@ -1367,11 +1410,12 @@ csched_schedule(
> =A0=A0=A0=A0 if ( !is_idle_vcpu(snext->vcpu) )
> =A0=A0=A0=A0=A0=A0=A0=A0 snext->start_time +=3D now;
>
> +out:
> =A0=A0=A0=A0 /*
> =A0=A0=A0=A0=A0 * Return task to run next...
> =A0=A0=A0=A0=A0 */
> =A0=A0=A0=A0 ret.time =3D (is_idle_vcpu(snext->vcpu) ?
> -=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 -1 : MILLISECS(prv->tslice=
_ms));
> +=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 -1 : tslice);
> =A0=A0=A0=A0 ret.task =3D snext->vcpu;
>
> =A0=A0=A0=A0 CSCHED_VCPU_CHECK(ret.task);
> diff -r 1c58bb664d8d xen/common/schedule.c
> --- a/xen/common/schedule.c=A0=A0=A0=A0 Thu Dec 08 17:15:16 2011 +0000
> +++ b/xen/common/schedule.c=A0=A0=A0=A0 Fri Dec 16 15:08:09 2011 -0500
> @@ -47,6 +47,10 @@ string_param("sched", opt_sched);
> bool_t sched_smt_power_savings =3D 0;
> boolean_param("sched_smt_power_savings", sched_smt_power_savings);
>
> +/* Default scheduling rate limit: 1ms */
> +int sched_ratelimit_us =3D 1000;
> +integer_param("sched_ratelimit_us", sched_ratelimit_us);
> +
> /* Various timer handlers. */
> static void s_timer_fn(void *unused);
> static void vcpu_periodic_timer_fn(void *data);
> diff -r 1c58bb664d8d xen/include/xen/perfc_defn.h
> --- a/xen/include/xen/perfc_defn.h=A0=A0=A0=A0=A0 Thu Dec 08 17:15:16 201=
1 +0000
> +++ b/xen/include/xen/perfc_defn.h=A0=A0=A0=A0=A0 Fri Dec 16 15:08:09 201=
1 -0500
> @@ -16,6 +16,7 @@ PERFCOUNTER(sched_irq,=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0 "sch
> PERFCOUNTER(sched_run,=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 "sched: run=
s through scheduler")
> PERFCOUNTER(sched_ctx,=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 "sched: con=
text switches")
>
> +PERFCOUNTER(delay_ms,=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 "csched: de=
lay")
> PERFCOUNTER(vcpu_check,=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 "csched: vcpu=
_check")
> PERFCOUNTER(schedule,=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 "csched: =
schedule")
> PERFCOUNTER(acct_run,=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 "csched: =
acct_run")
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 10:54:48 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 10:54:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RcarU-0002dX-VN; Mon, 19 Dec 2011 10:54:28 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1RcarT-0002dS-Mj
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 10:54:28 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1324292061!2511678!1
X-Originating-IP: [209.85.212.171]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12642 invoked from network); 19 Dec 2011 10:54:21 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Dec 2011 10:54:21 -0000
Received: by wico1 with SMTP id o1so2407599wic.30
	for <xen-devel@lists.xensource.com>;
	Mon, 19 Dec 2011 02:54:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=KlaRZpg0n1gkjenzIOX1TdDw9RSF+PzmhMUpuaEixyM=;
	b=AV6pgfWKIj6XwSeE7rh9j3HPq4iOo+8OE/pYbCfRViZXynZxO2pa8vefkY4hxSeZIs
	lCP4/UUHjwNeSwCFmgIMNnPAHBvN69AMt1KfTLawVNPils4T5BtqJ2h/Hu5+T5/448/k
	utBL2kG7NeJTnYiYvZO5Cv8owhIlk6rrlFR7I=
MIME-Version: 1.0
Received: by 10.180.8.162 with SMTP id s2mr5393646wia.29.1324292061261; Mon,
	19 Dec 2011 02:54:21 -0800 (PST)
Received: by 10.216.0.212 with HTTP; Mon, 19 Dec 2011 02:54:21 -0800 (PST)
In-Reply-To: <C10D3FB0CD45994C8A51FEC1227CE22F37CC284376@shsmsx502.ccr.corp.intel.com>
References: <Acy8a1J98NIQa/LRTpOgi509iCZVqg==>
	<C10D3FB0CD45994C8A51FEC1227CE22F37CC284376@shsmsx502.ccr.corp.intel.com>
Date: Mon, 19 Dec 2011 10:54:21 +0000
X-Google-Sender-Auth: AMDND20rTU5ROejH_e5MwizEg3E
Message-ID: <CAFLBxZYSbT05USq9kf0WsELU8OzkzV80iO7uuyUyQaGFS2sxkA@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: "Lv, Hui" <hui.lv@intel.com>
Cc: "Tian, Kevin" <kevin.tian@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"keir@xen.org" <keir@xen.org>, "Dong, Eddie" <eddie.dong@intel.com>, "Duan,
	Jiangang" <jiangang.duan@intel.com>, "Yu, Zhidong" <zhidong.yu@intel.com>
Subject: Re: [Xen-devel] [PATCH v2] xen/credit scheduler;
 Use delay to control scheduling frequency
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hui,

Unfortunately your mailer is mangling the patch:

 static int __read_mostly sched_credit_tslice_ms =3D3D CSCHED_DEFAULT_TSLIC=
E_=3D
MS;

Try using "hg email", or sending it as an attachment.

 -George

On Sat, Dec 17, 2011 at 3:24 AM, Lv, Hui <hui.lv@intel.com> wrote:
> The delay method for credit scheduler can do as well as SRC patch (previo=
us
> one) to gain significant performance boost without obvious drawbacks.
>
> 1. Basically, the "delay method" can achieve nearly the same benefits as =
my
> previous SRC patch, 11% overall performance boost for SPECvirt than origi=
nal
> credit scheduler.
> 2. We have tried 1ms delay and 10ms delay, there is no big difference
> between these two configurations. (1ms is enough to achieve a good
> performance)
> 3. We have compared different load level response time/latency (low, high,
> peak), "delay method" didn't bring very much response time increase.
> 4. 1ms delay can reduce 30% context switch at peak performance, where
> produces the benefits. (=93int sched_ratelimit_us =3D 1000=94 is the reco=
mmended
> setting)
>
>
> Signed-off-by: Hui Lv <hui.lv@intel.com>
> Signed-off-by: George Dunlap <George.Dunlap@eu.citrix.com>
>
> diff -r 1c58bb664d8d xen/common/sched_credit.c
> --- a/xen/common/sched_credit.c Thu Dec 08 17:15:16 2011 +0000
> +++ b/xen/common/sched_credit.c Fri Dec 16 15:08:09 2011 -0500
> @@ -110,6 +110,9 @@ boolean_param("sched_credit_default_yiel
> static int __read_mostly sched_credit_tslice_ms =3D CSCHED_DEFAULT_TSLICE=
_MS;
> integer_param("sched_credit_tslice_ms", sched_credit_tslice_ms);
>
> +/* Scheduler generic parameters
> +*/
> +extern int sched_ratelimit_us;
> /*
> =A0 * Physical CPU
> =A0 */
> @@ -1297,10 +1300,15 @@ csched_schedule(
> =A0=A0=A0=A0 struct csched_private *prv =3D CSCHED_PRIV(ops);
> =A0=A0=A0=A0 struct csched_vcpu *snext;
> =A0=A0=A0=A0 struct task_slice ret;
> +=A0=A0=A0 s_time_t runtime, tslice;
>
> =A0=A0=A0=A0 CSCHED_STAT_CRANK(schedule);
> =A0=A0=A0=A0 CSCHED_VCPU_CHECK(current);
>
> +=A0=A0=A0 runtime =3D now - current->runstate.state_entry_time;
> +=A0=A0=A0 if ( runtime < 0 ) /* Does this ever happen? */
> +=A0=A0=A0=A0=A0=A0=A0 runtime =3D 0;
> +
> =A0=A0=A0=A0 if ( !is_idle_vcpu(scurr->vcpu) )
> =A0=A0=A0=A0 {
> =A0=A0=A0=A0=A0=A0=A0=A0 /* Update credits of a non-idle VCPU. */
> @@ -1313,6 +1321,41 @@ csched_schedule(
> =A0=A0=A0=A0=A0=A0=A0=A0 scurr->pri =3D CSCHED_PRI_IDLE;
> =A0=A0=A0=A0 }
>
> +=A0=A0=A0 /* Choices, choices:
> +=A0=A0=A0=A0 * - If we have a tasklet, we need to run the idle vcpu no m=
atter what.
> +=A0=A0=A0=A0 * - If sched rate limiting is in effect, and the current vc=
pu has
> +=A0=A0=A0=A0 *=A0=A0 run for less than that amount of time, continue the=
 current one,
> +=A0=A0=A0=A0 *=A0=A0 but with a shorter timeslice and return it immediat=
ely
> +=A0=A0=A0=A0 * - Otherwise, chose the one with the highest priority (whi=
ch may
> +=A0=A0=A0=A0 *=A0=A0 be the one currently running)
> +=A0=A0=A0=A0 * - If the currently running one is TS_OVER, see if there
> +=A0=A0=A0=A0 *=A0=A0 is a higher priority one waiting on the runqueue of=
 another
> +=A0=A0=A0=A0 *=A0=A0 cpu and steal it.
> +=A0=A0=A0=A0 */
> +
> +=A0=A0=A0 /* If we have schedule rate limiting enabled, check to see
> +=A0=A0=A0=A0 * how long we've run for. */
> +=A0=A0=A0 if ( sched_ratelimit_us
> +=A0=A0=A0=A0=A0=A0=A0=A0 && !tasklet_work_scheduled
> +=A0=A0=A0=A0=A0=A0=A0=A0 && vcpu_runnable(current)
> +=A0=A0=A0=A0=A0=A0=A0=A0 && !is_idle_vcpu(current)
> +=A0=A0=A0=A0=A0=A0=A0=A0 && runtime < MICROSECS(sched_ratelimit_us) )
> +=A0=A0=A0 {
> +=A0=A0=A0=A0=A0=A0=A0 snext =3D scurr;
> +=A0=A0=A0=A0=A0=A0=A0 snext->start_time +=3D now;
> +=A0=A0=A0=A0=A0=A0=A0 perfc_incr(delay_ms);
> +=A0=A0=A0=A0=A0=A0=A0 tslice =3D MICROSECS(sched_ratelimit_us);
> +=A0=A0=A0=A0=A0=A0=A0 ret.migrated =3D 0;
> +=A0=A0=A0=A0=A0=A0=A0 goto out;
> +=A0=A0=A0 }
> +=A0=A0=A0 else
> +=A0=A0=A0 {
> +=A0=A0=A0=A0=A0=A0=A0 /*
> +=A0=A0=A0=A0=A0=A0=A0=A0 * Select next runnable local VCPU (ie top of lo=
cal runq)
> +=A0=A0=A0=A0=A0=A0=A0 */
> +=A0=A0=A0=A0=A0=A0=A0 tslice =3D MILLISECS(prv->tslice_ms);
> +=A0=A0=A0 }
> +
> =A0=A0=A0=A0 /*
> =A0=A0=A0=A0=A0 * Select next runnable local VCPU (ie top of local runq)
> =A0=A0=A0=A0=A0 */
> @@ -1367,11 +1410,12 @@ csched_schedule(
> =A0=A0=A0=A0 if ( !is_idle_vcpu(snext->vcpu) )
> =A0=A0=A0=A0=A0=A0=A0=A0 snext->start_time +=3D now;
>
> +out:
> =A0=A0=A0=A0 /*
> =A0=A0=A0=A0=A0 * Return task to run next...
> =A0=A0=A0=A0=A0 */
> =A0=A0=A0=A0 ret.time =3D (is_idle_vcpu(snext->vcpu) ?
> -=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 -1 : MILLISECS(prv->tslice=
_ms));
> +=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 -1 : tslice);
> =A0=A0=A0=A0 ret.task =3D snext->vcpu;
>
> =A0=A0=A0=A0 CSCHED_VCPU_CHECK(ret.task);
> diff -r 1c58bb664d8d xen/common/schedule.c
> --- a/xen/common/schedule.c=A0=A0=A0=A0 Thu Dec 08 17:15:16 2011 +0000
> +++ b/xen/common/schedule.c=A0=A0=A0=A0 Fri Dec 16 15:08:09 2011 -0500
> @@ -47,6 +47,10 @@ string_param("sched", opt_sched);
> bool_t sched_smt_power_savings =3D 0;
> boolean_param("sched_smt_power_savings", sched_smt_power_savings);
>
> +/* Default scheduling rate limit: 1ms */
> +int sched_ratelimit_us =3D 1000;
> +integer_param("sched_ratelimit_us", sched_ratelimit_us);
> +
> /* Various timer handlers. */
> static void s_timer_fn(void *unused);
> static void vcpu_periodic_timer_fn(void *data);
> diff -r 1c58bb664d8d xen/include/xen/perfc_defn.h
> --- a/xen/include/xen/perfc_defn.h=A0=A0=A0=A0=A0 Thu Dec 08 17:15:16 201=
1 +0000
> +++ b/xen/include/xen/perfc_defn.h=A0=A0=A0=A0=A0 Fri Dec 16 15:08:09 201=
1 -0500
> @@ -16,6 +16,7 @@ PERFCOUNTER(sched_irq,=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0 "sch
> PERFCOUNTER(sched_run,=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 "sched: run=
s through scheduler")
> PERFCOUNTER(sched_ctx,=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 "sched: con=
text switches")
>
> +PERFCOUNTER(delay_ms,=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 "csched: de=
lay")
> PERFCOUNTER(vcpu_check,=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 "csched: vcpu=
_check")
> PERFCOUNTER(schedule,=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 "csched: =
schedule")
> PERFCOUNTER(acct_run,=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 "csched: =
acct_run")
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 11:26:56 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 11:26:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RcbMR-0002zH-Pt; Mon, 19 Dec 2011 11:26:27 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RcbMP-0002zB-F4
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 11:26:25 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1324293977!8011132!1
X-Originating-IP: [209.85.210.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19942 invoked from network); 19 Dec 2011 11:26:19 -0000
Received: from mail-pz0-f43.google.com (HELO mail-pz0-f43.google.com)
	(209.85.210.43)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Dec 2011 11:26:19 -0000
Received: by daec6 with SMTP id c6so25098579dae.30
	for <xen-devel@lists.xensource.com>;
	Mon, 19 Dec 2011 03:26:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=TUP3fompXYKVkIm+BpB4dtc/m1afO8rQ15/uJOn9Q/w=;
	b=I71FwitZ2IE9RMXLosL3ZBu7edaoyJKQcAJ1179h1JG+RPc+vAMbaRvo9uc2EeMkvS
	GlHro8NOymZJQxpaYu8Sogc9LM5RwbMyzqh/bq5I+jhkpnfHNZJvGxfiQsTZkKPhCaWG
	Vqe2ffT7Fo2pc6sCpMFjgPcPcy2U0hcOrqbnE=
MIME-Version: 1.0
Received: by 10.68.74.70 with SMTP id r6mr37735828pbv.78.1324293977340; Mon,
	19 Dec 2011 03:26:17 -0800 (PST)
Received: by 10.142.47.17 with HTTP; Mon, 19 Dec 2011 03:26:17 -0800 (PST)
In-Reply-To: <1324289291.9236.16.camel@zakaz.uk.xensource.com>
References: <patchbomb.1324212500@alpine.localdomain>
	<eed78eb655c40b0ac9af.1324212501@alpine.localdomain>
	<1324288096.9236.6.camel@zakaz.uk.xensource.com>
	<CAPLaKK7gEUv9bavavzyYjREPDZJepMkK+-Ap78xzHjPy4SvZ3g@mail.gmail.com>
	<1324289291.9236.16.camel@zakaz.uk.xensource.com>
Date: Mon, 19 Dec 2011 12:26:17 +0100
X-Google-Sender-Auth: 3OOt0zyubCKH8BrMmlwQg4Y7P0M
Message-ID: <CAPLaKK6=O_h+OxOc_qDLUkw22hV2t6t9wfXOKVuoJf+Ny5+P9g@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 1 of 5] blktap: remove HAVE_BYTESWAP_H
 checking, since it's defined by qemu
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

2011/12/19 Ian Campbell <Ian.Campbell@citrix.com>:
> I think this is the correct option. No need to undef stuff. There is
> only one other include of byteswap.h in blktap.
>

On uclibc, byteswap.h gets included by default, because _GNU_SOURCE
implies _BSD_SOURCE there. One solution is to add _POSIX_SOURCE, which
prevents the addition of _BSD_SOURCE.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 11:26:56 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 11:26:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RcbMR-0002zH-Pt; Mon, 19 Dec 2011 11:26:27 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RcbMP-0002zB-F4
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 11:26:25 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1324293977!8011132!1
X-Originating-IP: [209.85.210.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19942 invoked from network); 19 Dec 2011 11:26:19 -0000
Received: from mail-pz0-f43.google.com (HELO mail-pz0-f43.google.com)
	(209.85.210.43)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Dec 2011 11:26:19 -0000
Received: by daec6 with SMTP id c6so25098579dae.30
	for <xen-devel@lists.xensource.com>;
	Mon, 19 Dec 2011 03:26:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=TUP3fompXYKVkIm+BpB4dtc/m1afO8rQ15/uJOn9Q/w=;
	b=I71FwitZ2IE9RMXLosL3ZBu7edaoyJKQcAJ1179h1JG+RPc+vAMbaRvo9uc2EeMkvS
	GlHro8NOymZJQxpaYu8Sogc9LM5RwbMyzqh/bq5I+jhkpnfHNZJvGxfiQsTZkKPhCaWG
	Vqe2ffT7Fo2pc6sCpMFjgPcPcy2U0hcOrqbnE=
MIME-Version: 1.0
Received: by 10.68.74.70 with SMTP id r6mr37735828pbv.78.1324293977340; Mon,
	19 Dec 2011 03:26:17 -0800 (PST)
Received: by 10.142.47.17 with HTTP; Mon, 19 Dec 2011 03:26:17 -0800 (PST)
In-Reply-To: <1324289291.9236.16.camel@zakaz.uk.xensource.com>
References: <patchbomb.1324212500@alpine.localdomain>
	<eed78eb655c40b0ac9af.1324212501@alpine.localdomain>
	<1324288096.9236.6.camel@zakaz.uk.xensource.com>
	<CAPLaKK7gEUv9bavavzyYjREPDZJepMkK+-Ap78xzHjPy4SvZ3g@mail.gmail.com>
	<1324289291.9236.16.camel@zakaz.uk.xensource.com>
Date: Mon, 19 Dec 2011 12:26:17 +0100
X-Google-Sender-Auth: 3OOt0zyubCKH8BrMmlwQg4Y7P0M
Message-ID: <CAPLaKK6=O_h+OxOc_qDLUkw22hV2t6t9wfXOKVuoJf+Ny5+P9g@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 1 of 5] blktap: remove HAVE_BYTESWAP_H
 checking, since it's defined by qemu
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

2011/12/19 Ian Campbell <Ian.Campbell@citrix.com>:
> I think this is the correct option. No need to undef stuff. There is
> only one other include of byteswap.h in blktap.
>

On uclibc, byteswap.h gets included by default, because _GNU_SOURCE
implies _BSD_SOURCE there. One solution is to add _POSIX_SOURCE, which
prevents the addition of _BSD_SOURCE.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 11:28:11 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 11: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.xensource.com>)
	id 1RcbNn-00034K-DZ; Mon, 19 Dec 2011 11:27:51 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RcbNl-00033z-Po
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 11:27:49 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1324294032!57261920!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzA0OQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15402 invoked from network); 19 Dec 2011 11:27:12 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Dec 2011 11:27:12 -0000
X-IronPort-AV: E=Sophos;i="4.71,375,1320624000"; 
   d="scan'208";a="9551892"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Dec 2011 11:27:48 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 19 Dec 2011 11:27:48 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau =?ISO-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
Date: Mon, 19 Dec 2011 11:27:48 +0000
In-Reply-To: <CAPLaKK6=O_h+OxOc_qDLUkw22hV2t6t9wfXOKVuoJf+Ny5+P9g@mail.gmail.com>
References: <patchbomb.1324212500@alpine.localdomain>
	<eed78eb655c40b0ac9af.1324212501@alpine.localdomain>
	<1324288096.9236.6.camel@zakaz.uk.xensource.com>
	<CAPLaKK7gEUv9bavavzyYjREPDZJepMkK+-Ap78xzHjPy4SvZ3g@mail.gmail.com>
	<1324289291.9236.16.camel@zakaz.uk.xensource.com>
	<CAPLaKK6=O_h+OxOc_qDLUkw22hV2t6t9wfXOKVuoJf+Ny5+P9g@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1324294068.9236.28.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 1 of 5] blktap: remove HAVE_BYTESWAP_H
 checking, since it's defined by qemu
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gTW9uLCAyMDExLTEyLTE5IGF0IDExOjI2ICswMDAwLCBSb2dlciBQYXUgTW9ubsOpIHdyb3Rl
Ogo+IDIwMTEvMTIvMTkgSWFuIENhbXBiZWxsIDxJYW4uQ2FtcGJlbGxAY2l0cml4LmNvbT46Cj4g
PiBJIHRoaW5rIHRoaXMgaXMgdGhlIGNvcnJlY3Qgb3B0aW9uLiBObyBuZWVkIHRvIHVuZGVmIHN0
dWZmLiBUaGVyZSBpcwo+ID4gb25seSBvbmUgb3RoZXIgaW5jbHVkZSBvZiBieXRlc3dhcC5oIGlu
IGJsa3RhcC4KPiA+Cj4gCj4gT24gdWNsaWJjLCBieXRlc3dhcC5oIGdldHMgaW5jbHVkZWQgYnkg
ZGVmYXVsdCwgYmVjYXVzZSBfR05VX1NPVVJDRQo+IGltcGxpZXMgX0JTRF9TT1VSQ0UgdGhlcmUu
IE9uZSBzb2x1dGlvbiBpcyB0byBhZGQgX1BPU0lYX1NPVVJDRSwgd2hpY2gKPiBwcmV2ZW50cyB0
aGUgYWRkaXRpb24gb2YgX0JTRF9TT1VSQ0UuCgpXaGF0IHBhdGggb2YgaW5jbHVkZXMgbGVhZHMg
dG8gdGhlIGluY2x1c2lvbiBvZiBieXRlc3dhcC5oPwoKSWFuLgoKCgoKX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApY
ZW4tZGV2ZWxAbGlzdHMueGVuc291cmNlLmNvbQpodHRwOi8vbGlzdHMueGVuc291cmNlLmNvbS94
ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Mon Dec 19 11:28:11 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 11: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.xensource.com>)
	id 1RcbNn-00034K-DZ; Mon, 19 Dec 2011 11:27:51 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RcbNl-00033z-Po
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 11:27:49 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1324294032!57261920!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzA0OQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15402 invoked from network); 19 Dec 2011 11:27:12 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Dec 2011 11:27:12 -0000
X-IronPort-AV: E=Sophos;i="4.71,375,1320624000"; 
   d="scan'208";a="9551892"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Dec 2011 11:27:48 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 19 Dec 2011 11:27:48 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau =?ISO-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
Date: Mon, 19 Dec 2011 11:27:48 +0000
In-Reply-To: <CAPLaKK6=O_h+OxOc_qDLUkw22hV2t6t9wfXOKVuoJf+Ny5+P9g@mail.gmail.com>
References: <patchbomb.1324212500@alpine.localdomain>
	<eed78eb655c40b0ac9af.1324212501@alpine.localdomain>
	<1324288096.9236.6.camel@zakaz.uk.xensource.com>
	<CAPLaKK7gEUv9bavavzyYjREPDZJepMkK+-Ap78xzHjPy4SvZ3g@mail.gmail.com>
	<1324289291.9236.16.camel@zakaz.uk.xensource.com>
	<CAPLaKK6=O_h+OxOc_qDLUkw22hV2t6t9wfXOKVuoJf+Ny5+P9g@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1324294068.9236.28.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 1 of 5] blktap: remove HAVE_BYTESWAP_H
 checking, since it's defined by qemu
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gTW9uLCAyMDExLTEyLTE5IGF0IDExOjI2ICswMDAwLCBSb2dlciBQYXUgTW9ubsOpIHdyb3Rl
Ogo+IDIwMTEvMTIvMTkgSWFuIENhbXBiZWxsIDxJYW4uQ2FtcGJlbGxAY2l0cml4LmNvbT46Cj4g
PiBJIHRoaW5rIHRoaXMgaXMgdGhlIGNvcnJlY3Qgb3B0aW9uLiBObyBuZWVkIHRvIHVuZGVmIHN0
dWZmLiBUaGVyZSBpcwo+ID4gb25seSBvbmUgb3RoZXIgaW5jbHVkZSBvZiBieXRlc3dhcC5oIGlu
IGJsa3RhcC4KPiA+Cj4gCj4gT24gdWNsaWJjLCBieXRlc3dhcC5oIGdldHMgaW5jbHVkZWQgYnkg
ZGVmYXVsdCwgYmVjYXVzZSBfR05VX1NPVVJDRQo+IGltcGxpZXMgX0JTRF9TT1VSQ0UgdGhlcmUu
IE9uZSBzb2x1dGlvbiBpcyB0byBhZGQgX1BPU0lYX1NPVVJDRSwgd2hpY2gKPiBwcmV2ZW50cyB0
aGUgYWRkaXRpb24gb2YgX0JTRF9TT1VSQ0UuCgpXaGF0IHBhdGggb2YgaW5jbHVkZXMgbGVhZHMg
dG8gdGhlIGluY2x1c2lvbiBvZiBieXRlc3dhcC5oPwoKSWFuLgoKCgoKX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApY
ZW4tZGV2ZWxAbGlzdHMueGVuc291cmNlLmNvbQpodHRwOi8vbGlzdHMueGVuc291cmNlLmNvbS94
ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Mon Dec 19 11:33:08 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 11:33:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RcbSb-0003Q5-Db; Mon, 19 Dec 2011 11:32:49 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1RcbSZ-0003Px-C2
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 11:32:47 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1324294347!59490647!1
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26077 invoked from network); 19 Dec 2011 11:32:27 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Dec 2011 11:32:27 -0000
Received: by wgbds11 with SMTP id ds11so8866962wgb.24
	for <xen-devel@lists.xensource.com>;
	Mon, 19 Dec 2011 03:32:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=gT4FrXBe1Zn5btlQlLAspOgFIDVzDhb6EHBzZcv45ss=;
	b=QnIqRAcCMHxL3qS9bWn/yjhPz5cMuyMfMnu71udY4HKJLV0qTmguUZ9Bk+SuVbhfmn
	yhYM72NiYJnGP2aHbNP0BsI4aCHp+L4uVtYewY3+Ybl7AmJH2xtS9BpQbQdKWhrkI7zp
	pwWAeI4SB9RCeQfjXSzPIqPW0q4TBzz0kDpZQ=
MIME-Version: 1.0
Received: by 10.227.203.78 with SMTP id fh14mr11741392wbb.12.1324294366064;
	Mon, 19 Dec 2011 03:32:46 -0800 (PST)
Received: by 10.216.0.212 with HTTP; Mon, 19 Dec 2011 03:32:45 -0800 (PST)
In-Reply-To: <4EEF02E20200007800068C60@nat28.tlf.novell.com>
References: <C10D3FB0CD45994C8A51FEC1227CE22F37CC284376@shsmsx502.ccr.corp.intel.com>
	<4EEF02E20200007800068C60@nat28.tlf.novell.com>
Date: Mon, 19 Dec 2011 11:32:45 +0000
X-Google-Sender-Auth: Q6nA18c3gkeYo67VlMo5K3ds3_I
Message-ID: <CAFLBxZb3Yc7G4QzEXKdfrVkoz1XGv09zTxCQCC4Dnkr-6M5K5Q@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: Kevin Tian <kevin.tian@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"keir@xen.org" <keir@xen.org>, Eddie Dong <eddie.dong@intel.com>,
	Hui Lv <hui.lv@intel.com>, Jiangang Duan <jiangang.duan@intel.com>,
	Zhidong Yu <zhidong.yu@intel.com>
Subject: Re: [Xen-devel] [PATCH v2] xen/credit scheduler;
 Use delay to control scheduling frequency
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Dec 19, 2011 at 8:24 AM, Jan Beulich <JBeulich@suse.com> wrote:
>> + =A0 =A0 =A0 =A0 && vcpu_runnable(current)
>> + =A0 =A0 =A0 =A0 && !is_idle_vcpu(current)
>> + =A0 =A0 =A0 =A0 && runtime < MICROSECS(sched_ratelimit_us) )
>> + =A0 =A0{
>> + =A0 =A0 =A0 =A0snext =3D scurr;
>> + =A0 =A0 =A0 =A0snext->start_time +=3D now;
>> + =A0 =A0 =A0 =A0perfc_incr(delay_ms);
>> + =A0 =A0 =A0 =A0tslice =3D MICROSECS(sched_ratelimit_us);
>
> So if there happens to be a VM with
>
> MILLISECS(prv->tslice_ms) < MICROSECS(sched_ratelimit_us)
>
> it'd get *more* time than allowed/intended through this mechanism.

Yeah, if you set your default timeslice to 1ms, and then set your
minimum scheduling rate to 5ms, you're going to get weird results. :-)

The way it stands now, the ratelimit value will override the timeslice
value.  It had to be one way or the other; do you think the timeslice
value should be the priority?

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 11:33:08 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 11:33:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RcbSb-0003Q5-Db; Mon, 19 Dec 2011 11:32:49 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1RcbSZ-0003Px-C2
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 11:32:47 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1324294347!59490647!1
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26077 invoked from network); 19 Dec 2011 11:32:27 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Dec 2011 11:32:27 -0000
Received: by wgbds11 with SMTP id ds11so8866962wgb.24
	for <xen-devel@lists.xensource.com>;
	Mon, 19 Dec 2011 03:32:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=gT4FrXBe1Zn5btlQlLAspOgFIDVzDhb6EHBzZcv45ss=;
	b=QnIqRAcCMHxL3qS9bWn/yjhPz5cMuyMfMnu71udY4HKJLV0qTmguUZ9Bk+SuVbhfmn
	yhYM72NiYJnGP2aHbNP0BsI4aCHp+L4uVtYewY3+Ybl7AmJH2xtS9BpQbQdKWhrkI7zp
	pwWAeI4SB9RCeQfjXSzPIqPW0q4TBzz0kDpZQ=
MIME-Version: 1.0
Received: by 10.227.203.78 with SMTP id fh14mr11741392wbb.12.1324294366064;
	Mon, 19 Dec 2011 03:32:46 -0800 (PST)
Received: by 10.216.0.212 with HTTP; Mon, 19 Dec 2011 03:32:45 -0800 (PST)
In-Reply-To: <4EEF02E20200007800068C60@nat28.tlf.novell.com>
References: <C10D3FB0CD45994C8A51FEC1227CE22F37CC284376@shsmsx502.ccr.corp.intel.com>
	<4EEF02E20200007800068C60@nat28.tlf.novell.com>
Date: Mon, 19 Dec 2011 11:32:45 +0000
X-Google-Sender-Auth: Q6nA18c3gkeYo67VlMo5K3ds3_I
Message-ID: <CAFLBxZb3Yc7G4QzEXKdfrVkoz1XGv09zTxCQCC4Dnkr-6M5K5Q@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: Kevin Tian <kevin.tian@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"keir@xen.org" <keir@xen.org>, Eddie Dong <eddie.dong@intel.com>,
	Hui Lv <hui.lv@intel.com>, Jiangang Duan <jiangang.duan@intel.com>,
	Zhidong Yu <zhidong.yu@intel.com>
Subject: Re: [Xen-devel] [PATCH v2] xen/credit scheduler;
 Use delay to control scheduling frequency
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Dec 19, 2011 at 8:24 AM, Jan Beulich <JBeulich@suse.com> wrote:
>> + =A0 =A0 =A0 =A0 && vcpu_runnable(current)
>> + =A0 =A0 =A0 =A0 && !is_idle_vcpu(current)
>> + =A0 =A0 =A0 =A0 && runtime < MICROSECS(sched_ratelimit_us) )
>> + =A0 =A0{
>> + =A0 =A0 =A0 =A0snext =3D scurr;
>> + =A0 =A0 =A0 =A0snext->start_time +=3D now;
>> + =A0 =A0 =A0 =A0perfc_incr(delay_ms);
>> + =A0 =A0 =A0 =A0tslice =3D MICROSECS(sched_ratelimit_us);
>
> So if there happens to be a VM with
>
> MILLISECS(prv->tslice_ms) < MICROSECS(sched_ratelimit_us)
>
> it'd get *more* time than allowed/intended through this mechanism.

Yeah, if you set your default timeslice to 1ms, and then set your
minimum scheduling rate to 5ms, you're going to get weird results. :-)

The way it stands now, the ratelimit value will override the timeslice
value.  It had to be one way or the other; do you think the timeslice
value should be the priority?

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 11:38:40 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 11:38:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RcbXw-0003b2-5G; Mon, 19 Dec 2011 11:38:20 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RcbXu-0003as-Ob
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 11:38:18 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1324294692!6113839!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzA0OQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2151 invoked from network); 19 Dec 2011 11:38:12 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Dec 2011 11:38:12 -0000
X-IronPort-AV: E=Sophos;i="4.71,375,1320624000"; 
   d="scan'208";a="9552172"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Dec 2011 11:38:12 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 19 Dec 2011 11:38:12 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau =?ISO-8859-1?Q?Monn=E9?= <royger@gmail.com>
Date: Mon, 19 Dec 2011 11:38:12 +0000
In-Reply-To: <CAPLaKK771o2-_c=3huGH8ei3jAvL26en=Lu+QCuvdMFbZTi24Q@mail.gmail.com>
References: <patchbomb.1324212500@alpine.localdomain>
	<eed78eb655c40b0ac9af.1324212501@alpine.localdomain>
	<1324288096.9236.6.camel@zakaz.uk.xensource.com>
	<CAPLaKK7gEUv9bavavzyYjREPDZJepMkK+-Ap78xzHjPy4SvZ3g@mail.gmail.com>
	<1324289291.9236.16.camel@zakaz.uk.xensource.com>
	<CAPLaKK6=O_h+OxOc_qDLUkw22hV2t6t9wfXOKVuoJf+Ny5+P9g@mail.gmail.com>
	<1324294068.9236.28.camel@zakaz.uk.xensource.com>
	<CAPLaKK771o2-_c=3huGH8ei3jAvL26en=Lu+QCuvdMFbZTi24Q@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1324294692.9236.30.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 1 of 5] blktap: remove HAVE_BYTESWAP_H
 checking, since it's defined by qemu
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gTW9uLCAyMDExLTEyLTE5IGF0IDExOjI4ICswMDAwLCBSb2dlciBQYXUgTW9ubsOpIHdyb3Rl
Ogo+IDIwMTEvMTIvMTkgSWFuIENhbXBiZWxsIDxJYW4uQ2FtcGJlbGxAY2l0cml4LmNvbT46Cj4g
PiBPbiBNb24sIDIwMTEtMTItMTkgYXQgMTE6MjYgKzAwMDAsIFJvZ2VyIFBhdSBNb25uw6kgd3Jv
dGU6Cj4gPj4gMjAxMS8xMi8xOSBJYW4gQ2FtcGJlbGwgPElhbi5DYW1wYmVsbEBjaXRyaXguY29t
PjoKPiA+PiA+IEkgdGhpbmsgdGhpcyBpcyB0aGUgY29ycmVjdCBvcHRpb24uIE5vIG5lZWQgdG8g
dW5kZWYgc3R1ZmYuIFRoZXJlIGlzCj4gPj4gPiBvbmx5IG9uZSBvdGhlciBpbmNsdWRlIG9mIGJ5
dGVzd2FwLmggaW4gYmxrdGFwLgo+ID4+ID4KPiA+Pgo+ID4+IE9uIHVjbGliYywgYnl0ZXN3YXAu
aCBnZXRzIGluY2x1ZGVkIGJ5IGRlZmF1bHQsIGJlY2F1c2UgX0dOVV9TT1VSQ0UKPiA+PiBpbXBs
aWVzIF9CU0RfU09VUkNFIHRoZXJlLiBPbmUgc29sdXRpb24gaXMgdG8gYWRkIF9QT1NJWF9TT1VS
Q0UsIHdoaWNoCj4gPj4gcHJldmVudHMgdGhlIGFkZGl0aW9uIG9mIF9CU0RfU09VUkNFLgo+ID4K
PiA+IFdoYXQgcGF0aCBvZiBpbmNsdWRlcyBsZWFkcyB0byB0aGUgaW5jbHVzaW9uIG9mIGJ5dGVz
d2FwLmg/Cj4gCj4gVGhpcyBvbmU6Cj4gCj4gc3RkbGliLmggLT4gc3lzL3R5cGVzLmggLT4gZW5k
aWFuLmggLT4gKGJlY2FzdWUgX19VU0VfQlNEIGlzIGRlZmluZWQpIGJ5dGVzd2FwLmgKCkhybSA6
LS8KClNvIG9uIHRoZSBmbGlwIHNpZGUgd2hpY2ggcGxhdGZvcm1zIGRvbid0IGhhdmUgdGhpcyBo
ZWFkZXIgYXQgYWxsPyAKCldpbGxpYW0gc3VnZ2VzdGVkIEJTRCBkb2Vzbid0IGJ1dCB0aGUgdXNl
IG9mIF9fVVNFX0JTRCBzZWVtcyB0byBzdWdnZXN0Cm90aGVyd2lzZT8KCkRvZXMgTmV0QlNEIGhh
dmUgYnl0ZXN3YXAuaD8KCklhbi4KCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVu
c291cmNlLmNvbQpodHRwOi8vbGlzdHMueGVuc291cmNlLmNvbS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Mon Dec 19 11:38:40 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 11:38:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RcbXw-0003b2-5G; Mon, 19 Dec 2011 11:38:20 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RcbXu-0003as-Ob
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 11:38:18 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1324294692!6113839!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzA0OQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2151 invoked from network); 19 Dec 2011 11:38:12 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Dec 2011 11:38:12 -0000
X-IronPort-AV: E=Sophos;i="4.71,375,1320624000"; 
   d="scan'208";a="9552172"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Dec 2011 11:38:12 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 19 Dec 2011 11:38:12 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau =?ISO-8859-1?Q?Monn=E9?= <royger@gmail.com>
Date: Mon, 19 Dec 2011 11:38:12 +0000
In-Reply-To: <CAPLaKK771o2-_c=3huGH8ei3jAvL26en=Lu+QCuvdMFbZTi24Q@mail.gmail.com>
References: <patchbomb.1324212500@alpine.localdomain>
	<eed78eb655c40b0ac9af.1324212501@alpine.localdomain>
	<1324288096.9236.6.camel@zakaz.uk.xensource.com>
	<CAPLaKK7gEUv9bavavzyYjREPDZJepMkK+-Ap78xzHjPy4SvZ3g@mail.gmail.com>
	<1324289291.9236.16.camel@zakaz.uk.xensource.com>
	<CAPLaKK6=O_h+OxOc_qDLUkw22hV2t6t9wfXOKVuoJf+Ny5+P9g@mail.gmail.com>
	<1324294068.9236.28.camel@zakaz.uk.xensource.com>
	<CAPLaKK771o2-_c=3huGH8ei3jAvL26en=Lu+QCuvdMFbZTi24Q@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1324294692.9236.30.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 1 of 5] blktap: remove HAVE_BYTESWAP_H
 checking, since it's defined by qemu
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gTW9uLCAyMDExLTEyLTE5IGF0IDExOjI4ICswMDAwLCBSb2dlciBQYXUgTW9ubsOpIHdyb3Rl
Ogo+IDIwMTEvMTIvMTkgSWFuIENhbXBiZWxsIDxJYW4uQ2FtcGJlbGxAY2l0cml4LmNvbT46Cj4g
PiBPbiBNb24sIDIwMTEtMTItMTkgYXQgMTE6MjYgKzAwMDAsIFJvZ2VyIFBhdSBNb25uw6kgd3Jv
dGU6Cj4gPj4gMjAxMS8xMi8xOSBJYW4gQ2FtcGJlbGwgPElhbi5DYW1wYmVsbEBjaXRyaXguY29t
PjoKPiA+PiA+IEkgdGhpbmsgdGhpcyBpcyB0aGUgY29ycmVjdCBvcHRpb24uIE5vIG5lZWQgdG8g
dW5kZWYgc3R1ZmYuIFRoZXJlIGlzCj4gPj4gPiBvbmx5IG9uZSBvdGhlciBpbmNsdWRlIG9mIGJ5
dGVzd2FwLmggaW4gYmxrdGFwLgo+ID4+ID4KPiA+Pgo+ID4+IE9uIHVjbGliYywgYnl0ZXN3YXAu
aCBnZXRzIGluY2x1ZGVkIGJ5IGRlZmF1bHQsIGJlY2F1c2UgX0dOVV9TT1VSQ0UKPiA+PiBpbXBs
aWVzIF9CU0RfU09VUkNFIHRoZXJlLiBPbmUgc29sdXRpb24gaXMgdG8gYWRkIF9QT1NJWF9TT1VS
Q0UsIHdoaWNoCj4gPj4gcHJldmVudHMgdGhlIGFkZGl0aW9uIG9mIF9CU0RfU09VUkNFLgo+ID4K
PiA+IFdoYXQgcGF0aCBvZiBpbmNsdWRlcyBsZWFkcyB0byB0aGUgaW5jbHVzaW9uIG9mIGJ5dGVz
d2FwLmg/Cj4gCj4gVGhpcyBvbmU6Cj4gCj4gc3RkbGliLmggLT4gc3lzL3R5cGVzLmggLT4gZW5k
aWFuLmggLT4gKGJlY2FzdWUgX19VU0VfQlNEIGlzIGRlZmluZWQpIGJ5dGVzd2FwLmgKCkhybSA6
LS8KClNvIG9uIHRoZSBmbGlwIHNpZGUgd2hpY2ggcGxhdGZvcm1zIGRvbid0IGhhdmUgdGhpcyBo
ZWFkZXIgYXQgYWxsPyAKCldpbGxpYW0gc3VnZ2VzdGVkIEJTRCBkb2Vzbid0IGJ1dCB0aGUgdXNl
IG9mIF9fVVNFX0JTRCBzZWVtcyB0byBzdWdnZXN0Cm90aGVyd2lzZT8KCkRvZXMgTmV0QlNEIGhh
dmUgYnl0ZXN3YXAuaD8KCklhbi4KCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVu
c291cmNlLmNvbQpodHRwOi8vbGlzdHMueGVuc291cmNlLmNvbS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Mon Dec 19 11:40:44 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 11:40:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rcba0-0003hV-Mf; Mon, 19 Dec 2011 11:40:28 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RcbZz-0003hG-9y
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 11:40:28 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-8.tower-21.messagelabs.com!1324294814!8741280!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMDEyMDM=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMDEyMDM=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11931 invoked from network); 19 Dec 2011 11:40:15 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-8.tower-21.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 19 Dec 2011 11:40:15 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1324294814; l=18494;
	s=domk; d=aepfle.de;
	h=To:From:Date:Subject:Content-Transfer-Encoding:MIME-Version:
	Content-Type:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=UeTvWN4sNhs4peSxiPerTRBkDzw=;
	b=uXmNOanD8l9JV3T1GcCht+H84uiQp5SA4PSYN8SQosGYn1bbKuzVvYt09K/mR+IyjIJ
	zpG/GV5EDGqQ1ACtovBMWgdrQk9Mgc8QEqmSct/2EScrXsH57STCQz3uEIgWm6KULUzZ5
	puR49UOFqNYuVTMP5OdU9mabbqd2Iqpzu3o=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lq3c7pG0Q=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-074-029.pools.arcor-ip.net [84.57.74.29])
	by post.strato.de (mrclete mo7) (RZmta 26.15 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id 606c1bnBJAWH9G
	for <xen-devel@lists.xensource.com>;
	Mon, 19 Dec 2011 12:39:48 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id E6A4618636
	for <xen-devel@lists.xensource.com>;
	Mon, 19 Dec 2011 12:39:47 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: d910d738f31b4ee1a6b0727ac0a66cff4c8933b0
Message-Id: <d910d738f31b4ee1a6b0.1324294786@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Mon, 19 Dec 2011 12:39:46 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH] mem_event: use wait queue when ring is full
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1324294734 -3600
# Node ID d910d738f31b4ee1a6b0727ac0a66cff4c8933b0
# Parent  03138a08366b895d79e143119d4c9c72833cdbcd
mem_event: use wait queue when ring is full

This change is based on an idea/patch from Adin Scannell.

If the ring is full, put the current vcpu to sleep if it belongs to the
target domain. The wakeup happens in the p2m_*_resume functions. Wakeup
will take the number of free slots into account.

A request from foreign domain has to succeed once a slot was claimed
because such vcpus can not sleep.

This change fixes also a bug in p2m_mem_paging_drop_page(). Up to now a
full ring will lead to harmless inconsistency in the pager.

v7:
  - add ring accounting so that each vcpu can place at least one request

v6:
  - take foreign requests into account before calling wake_up_nr()
  - call wake_up_nr() outside of ring lock
 - rename ->bit to ->pause_flag
 - update comment in mem_event_enable()

v5:
  - rename mem_event_check_ring() to mem_event_claim_slot()
  - rename mem_event_put_req_producers() to mem_event_release_slot()
  - add local/foreign request accounting
  - keep room for at least one guest request

v4:
 - fix off-by-one bug in _mem_event_put_request
 - add mem_event_wake_requesters() and use wake_up_nr()
 - rename mem_event_mark_and_pause() and mem_event_mark_and_pause() functions
 - req_producers counts foreign request producers, rename member

v3:
 - rename ->mem_event_bit to ->bit
 - remove me_ from new VPF_ defines

v2:
 - p2m_mem_paging_populate: move vcpu_pause after put_request, otherwise the
   vcpu will not wake_up after a wait_event because the pause_count was
   increased twice. Fixes guest hangs.
 - update free space check in _mem_event_put_request()
 - simplify mem_event_put_request()

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 03138a08366b -r d910d738f31b xen/arch/x86/hvm/hvm.c
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -4172,8 +4172,8 @@ static int hvm_memory_event_traps(long p
     if ( (p & HVMPME_onchangeonly) && (value == old) )
         return 1;
     
-    rc = mem_event_check_ring(d, &d->mem_event->access);
-    if ( rc )
+    rc = mem_event_claim_slot(d, &d->mem_event->access);
+    if ( rc < 0 )
         return rc;
     
     memset(&req, 0, sizeof(req));
diff -r 03138a08366b -r d910d738f31b xen/arch/x86/mm/mem_event.c
--- a/xen/arch/x86/mm/mem_event.c
+++ b/xen/arch/x86/mm/mem_event.c
@@ -23,6 +23,7 @@
 
 #include <asm/domain.h>
 #include <xen/event.h>
+#include <xen/wait.h>
 #include <asm/p2m.h>
 #include <asm/mem_event.h>
 #include <asm/mem_paging.h>
@@ -41,6 +42,7 @@ static int mem_event_enable(
     struct domain *d,
     xen_domctl_mem_event_op_t *mec,
     struct mem_event_domain *med,
+    int pause_flag,
     xen_event_channel_notification_t notification_fn)
 {
     int rc;
@@ -110,8 +112,25 @@ static int mem_event_enable(
 
     mem_event_ring_lock_init(med);
 
-    /* Wake any VCPUs paused for memory events */
-    mem_event_unpause_vcpus(d);
+    med->pause_flag = pause_flag;
+
+    /*
+     * Configure ring accounting:
+     * Each guest vcpu should be able to place at least one request.
+     * If there are more vcpus than available slots in the ring, not all vcpus
+     * can place requests in the ring anyway.  A minimum (arbitrary) number of
+     * foreign requests will be allowed in this case.
+     */
+    if ( d->max_vcpus < RING_SIZE(&med->front_ring) )
+        med->max_foreign = RING_SIZE(&med->front_ring) - d->max_vcpus;
+    if ( med->max_foreign < 13 )
+        med->max_foreign = 13;
+    med->max_target = RING_SIZE(&med->front_ring) - med->max_foreign;
+
+    init_waitqueue_head(&med->wq);
+
+    /* Wake any VCPUs waiting for the ring to appear */
+    mem_event_wake_waiters(d, med);
 
     return 0;
 
@@ -127,6 +146,9 @@ static int mem_event_enable(
 
 static int mem_event_disable(struct mem_event_domain *med)
 {
+    if (!list_empty(&med->wq.list))
+        return -EBUSY;
+
     unmap_domain_page(med->ring_page);
     med->ring_page = NULL;
 
@@ -136,14 +158,30 @@ static int mem_event_disable(struct mem_
     return 0;
 }
 
-void mem_event_put_request(struct domain *d, struct mem_event_domain *med, mem_event_request_t *req)
+static int _mem_event_put_request(struct domain *d,
+                                  struct mem_event_domain *med,
+                                  mem_event_request_t *req,
+                                  int *done)
 {
     mem_event_front_ring_t *front_ring;
+    int free_req, claimed_req, ret;
     RING_IDX req_prod;
 
+    if ( *done )
+        return 1;
+
     mem_event_ring_lock(med);
 
     front_ring = &med->front_ring;
+
+    /* Foreign requests must succeed because their vcpus can not sleep */
+    claimed_req = med->foreign_producers;
+    free_req = RING_FREE_REQUESTS(front_ring);
+    if ( !free_req || ( current->domain == d && free_req <= claimed_req ) ) {
+        mem_event_ring_unlock(med);
+        return 0;
+    }
+
     req_prod = front_ring->req_prod_pvt;
 
     if ( current->domain != d )
@@ -156,14 +194,45 @@ void mem_event_put_request(struct domain
     memcpy(RING_GET_REQUEST(front_ring, req_prod), req, sizeof(*req));
     req_prod++;
 
+    ret = 1;
+    *done = 1;
+    free_req--;
+
+    /* Update accounting */
+    if ( current->domain == d )
+    {
+        med->target_producers--;
+        /* Ring is full, no more requests from this vcpu, go to sleep */
+        if ( free_req < med->max_target )
+            ret = 0;
+    }
+    else
+        med->foreign_producers--;
+
     /* Update ring */
-    med->req_producers--;
     front_ring->req_prod_pvt = req_prod;
     RING_PUSH_REQUESTS(front_ring);
 
     mem_event_ring_unlock(med);
 
     notify_via_xen_event_channel(d, med->xen_port);
+
+    return ret;
+}
+
+void mem_event_put_request(struct domain *d, struct mem_event_domain *med,
+                           mem_event_request_t *req)
+{
+    int done = 0;
+    /* Go to sleep if request came from guest */
+    if (current->domain == d) {
+        wait_event(med->wq, _mem_event_put_request(d, med, req, &done));
+        return;
+    }
+    /* Ring was full anyway, unable to sleep in non-guest context */
+    if (!_mem_event_put_request(d, med, req, &done))
+        printk("Failed to put memreq: d %u t %x f %x gfn %lx\n", d->domain_id,
+                req->type, req->flags, (unsigned long)req->gfn);
 }
 
 int mem_event_get_response(struct mem_event_domain *med, mem_event_response_t *rsp)
@@ -195,32 +264,97 @@ int mem_event_get_response(struct mem_ev
     return 1;
 }
 
-void mem_event_unpause_vcpus(struct domain *d)
+/**
+ * mem_event_wake_requesters - Wake vcpus waiting for room in the ring
+ * @d: guest domain
+ * @med: mem_event ring
+ *
+ * mem_event_wake_requesters() will wakeup vcpus waiting for room in the
+ * ring. Only as many as can place another request in the ring will
+ * resume execution.
+ */
+void mem_event_wake_requesters(struct mem_event_domain *med)
+{
+    int free_req;
+
+    mem_event_ring_lock(med);
+    free_req = RING_FREE_REQUESTS(&med->front_ring);
+    free_req -= med->foreign_producers;
+    mem_event_ring_unlock(med);
+
+    if ( free_req )
+        wake_up_nr(&med->wq, free_req);
+}
+
+/**
+ * mem_event_wake_waiters - Wake all vcpus waiting for the ring
+ * @d: guest domain
+ * @med: mem_event ring
+ *
+ * mem_event_wake_waiters() will wakeup all vcpus waiting for the ring to
+ * become available.
+ */
+void mem_event_wake_waiters(struct domain *d, struct mem_event_domain *med)
 {
     struct vcpu *v;
 
     for_each_vcpu ( d, v )
-        if ( test_and_clear_bit(_VPF_mem_event, &v->pause_flags) )
+        if ( test_and_clear_bit(med->pause_flag, &v->pause_flags) )
             vcpu_wake(v);
 }
 
-void mem_event_mark_and_pause(struct vcpu *v)
+/**
+ * mem_event_mark_and_sleep - Put vcpu to sleep
+ * @v: guest vcpu
+ * @med: mem_event ring
+ *
+ * mem_event_mark_and_sleep() tags vcpu and put it to sleep.
+ * The vcpu will resume execution in mem_event_wake_waiters().
+ */
+void mem_event_mark_and_sleep(struct vcpu *v, struct mem_event_domain *med)
 {
-    set_bit(_VPF_mem_event, &v->pause_flags);
+    set_bit(med->pause_flag, &v->pause_flags);
     vcpu_sleep_nosync(v);
 }
 
-void mem_event_put_req_producers(struct mem_event_domain *med)
+/**
+ * mem_event_release_slot - Release a claimed slot
+ * @med: mem_event ring
+ *
+ * mem_event_release_slot() releases a claimed slot in the mem_event ring.
+ */
+void mem_event_release_slot(struct domain *d, struct mem_event_domain *med)
 {
     mem_event_ring_lock(med);
-    med->req_producers--;
+    if ( current->domain == d )
+        med->target_producers--;
+    else
+        med->foreign_producers--;
     mem_event_ring_unlock(med);
 }
 
-int mem_event_check_ring(struct domain *d, struct mem_event_domain *med)
+/**
+ * mem_event_claim_slot - Check state of a mem_event ring
+ * @d: guest domain
+ * @med: mem_event ring
+ *
+ * Return codes: < 0: the ring is not yet configured
+ *                 0: the ring has some room
+ *               > 0: the ring is full
+ *
+ * mem_event_claim_slot() checks the state of the given mem_event ring.
+ * If the current vcpu belongs to the guest domain, the function assumes that
+ * mem_event_put_request() will sleep until the ring has room again.
+ * A guest can always place at least one request.
+ *
+ * If the current vcpu does not belong to the target domain the caller must try
+ * again until there is room. A slot is claimed and the caller can place a
+ * request. If the caller does not need to send a request, the claimed slot has
+ * to be released with mem_event_release_slot().
+ */
+int mem_event_claim_slot(struct domain *d, struct mem_event_domain *med)
 {
-    struct vcpu *curr = current;
-    int free_requests;
+    int free_req;
     int ring_full = 1;
 
     if ( !med->ring_page )
@@ -228,15 +362,19 @@ int mem_event_check_ring(struct domain *
 
     mem_event_ring_lock(med);
 
-    free_requests = RING_FREE_REQUESTS(&med->front_ring);
-    if ( med->req_producers < free_requests )
+    free_req = RING_FREE_REQUESTS(&med->front_ring);
+
+    if ( current->domain == d )
     {
-        med->req_producers++;
+        med->target_producers++;
         ring_full = 0;
     }
-
-    if ( ring_full && (curr->domain == d) )
-        mem_event_mark_and_pause(curr);
+    else if ( med->foreign_producers + med->target_producers < free_req &&
+              med->foreign_producers < med->max_foreign )
+    {
+        med->foreign_producers++;
+        ring_full = 0;
+    }
 
     mem_event_ring_unlock(med);
 
@@ -316,7 +454,7 @@ int mem_event_domctl(struct domain *d, x
             if ( p2m->pod.entry_count )
                 break;
 
-            rc = mem_event_enable(d, mec, med, mem_paging_notification);
+            rc = mem_event_enable(d, mec, med, _VPF_mem_paging, mem_paging_notification);
         }
         break;
 
@@ -355,7 +493,7 @@ int mem_event_domctl(struct domain *d, x
             if ( boot_cpu_data.x86_vendor != X86_VENDOR_INTEL )
                 break;
 
-            rc = mem_event_enable(d, mec, med, mem_access_notification);
+            rc = mem_event_enable(d, mec, med, _VPF_mem_access, mem_access_notification);
         }
         break;
 
diff -r 03138a08366b -r d910d738f31b xen/arch/x86/mm/mem_sharing.c
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -253,18 +253,10 @@ static void mem_sharing_audit(void)
 #endif
 
 
-static struct page_info* mem_sharing_alloc_page(struct domain *d, 
-                                                unsigned long gfn)
+static void mem_sharing_notify_helper(struct domain *d, unsigned long gfn)
 {
-    struct page_info* page;
     struct vcpu *v = current;
-    mem_event_request_t req;
-
-    page = alloc_domheap_page(d, 0); 
-    if(page != NULL) return page;
-
-    memset(&req, 0, sizeof(req));
-    req.type = MEM_EVENT_TYPE_SHARED;
+    mem_event_request_t req = { .type = MEM_EVENT_TYPE_SHARED };
 
     if ( v->domain != d )
     {
@@ -275,20 +267,18 @@ static struct page_info* mem_sharing_all
         gdprintk(XENLOG_ERR, 
                  "Failed alloc on unshare path for foreign (%d) lookup\n",
                  d->domain_id);
-        return page;
+        return;
     }
 
-    vcpu_pause_nosync(v);
-    req.flags |= MEM_EVENT_FLAG_VCPU_PAUSED;
+    if (mem_event_claim_slot(d, &d->mem_event->share) < 0)
+        return;
 
-    if(mem_event_check_ring(d, &d->mem_event->share)) return page;
-
+    req.flags = MEM_EVENT_FLAG_VCPU_PAUSED;
     req.gfn = gfn;
     req.p2mt = p2m_ram_shared;
     req.vcpu_id = v->vcpu_id;
     mem_event_put_request(d, &d->mem_event->share, &req);
-
-    return page;
+    vcpu_pause_nosync(v);
 }
 
 unsigned int mem_sharing_get_nr_saved_mfns(void)
@@ -656,7 +646,7 @@ gfn_found:
     if(ret == 0) goto private_page_found;
         
     old_page = page;
-    page = mem_sharing_alloc_page(d, gfn);
+    page = alloc_domheap_page(d, 0);
     if(!page) 
     {
         /* We've failed to obtain memory for private page. Need to re-add the
@@ -664,6 +654,7 @@ gfn_found:
         list_add(&gfn_info->list, &hash_entry->gfns);
         put_gfn(d, gfn);
         shr_unlock();
+        mem_sharing_notify_helper(d, gfn);
         return -ENOMEM;
     }
 
diff -r 03138a08366b -r d910d738f31b xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -861,20 +861,12 @@ int p2m_mem_paging_evict(struct domain *
  */
 void p2m_mem_paging_drop_page(struct domain *d, unsigned long gfn)
 {
-    struct vcpu *v = current;
-    mem_event_request_t req;
+    mem_event_request_t req = { .type = MEM_EVENT_TYPE_PAGING, .gfn = gfn };
 
-    /* Check that there's space on the ring for this request */
-    if ( mem_event_check_ring(d, &d->mem_event->paging) == 0)
-    {
-        /* Send release notification to pager */
-        memset(&req, 0, sizeof(req));
-        req.flags |= MEM_EVENT_FLAG_DROP_PAGE;
-        req.gfn = gfn;
-        req.vcpu_id = v->vcpu_id;
+    /* Send release notification to pager */
+    req.flags = MEM_EVENT_FLAG_DROP_PAGE;
 
-        mem_event_put_request(d, &d->mem_event->paging, &req);
-    }
+    mem_event_put_request(d, &d->mem_event->paging, &req);
 }
 
 /**
@@ -908,7 +900,7 @@ void p2m_mem_paging_populate(struct doma
     struct p2m_domain *p2m = p2m_get_hostp2m(d);
 
     /* Check that there's space on the ring for this request */
-    if ( mem_event_check_ring(d, &d->mem_event->paging) )
+    if ( mem_event_claim_slot(d, &d->mem_event->paging) )
         return;
 
     memset(&req, 0, sizeof(req));
@@ -938,7 +930,7 @@ void p2m_mem_paging_populate(struct doma
     else if ( p2mt != p2m_ram_paging_out && p2mt != p2m_ram_paged )
     {
         /* gfn is already on its way back and vcpu is not paused */
-        mem_event_put_req_producers(&d->mem_event->paging);
+        mem_event_release_slot(d, &d->mem_event->paging);
         return;
     }
 
@@ -1080,8 +1072,8 @@ void p2m_mem_paging_resume(struct domain
             vcpu_unpause(d->vcpu[rsp.vcpu_id]);
     }
 
-    /* Unpause any domains that were paused because the ring was full */
-    mem_event_unpause_vcpus(d);
+    /* Wake vcpus waiting for room in the ring */
+    mem_event_wake_requesters(&d->mem_event->paging);
 }
 
 bool_t p2m_mem_access_check(unsigned long gpa, bool_t gla_valid, unsigned long gla, 
@@ -1115,7 +1107,7 @@ bool_t p2m_mem_access_check(unsigned lon
     p2m_unlock(p2m);
 
     /* Otherwise, check if there is a memory event listener, and send the message along */
-    res = mem_event_check_ring(d, &d->mem_event->access);
+    res = mem_event_claim_slot(d, &d->mem_event->access);
     if ( res < 0 ) 
     {
         /* No listener */
@@ -1125,7 +1117,7 @@ bool_t p2m_mem_access_check(unsigned lon
                    "Memory access permissions failure, no mem_event listener: pausing VCPU %d, dom %d\n",
                    v->vcpu_id, d->domain_id);
 
-            mem_event_mark_and_pause(v);
+            mem_event_mark_and_sleep(v, &d->mem_event->access);
         }
         else
         {
@@ -1186,9 +1178,11 @@ void p2m_mem_access_resume(struct domain
             vcpu_unpause(d->vcpu[rsp.vcpu_id]);
     }
 
-    /* Unpause any domains that were paused because the ring was full or no listener 
-     * was available */
-    mem_event_unpause_vcpus(d);
+    /* Wake vcpus waiting for room in the ring */
+    mem_event_wake_requesters(&d->mem_event->access);
+
+    /* Unpause all vcpus that were paused because no listener was available */
+    mem_event_wake_waiters(d, &d->mem_event->access);
 }
 
 
diff -r 03138a08366b -r d910d738f31b xen/include/asm-x86/mem_event.h
--- a/xen/include/asm-x86/mem_event.h
+++ b/xen/include/asm-x86/mem_event.h
@@ -24,13 +24,13 @@
 #ifndef __MEM_EVENT_H__
 #define __MEM_EVENT_H__
 
-/* Pauses VCPU while marking pause flag for mem event */
-void mem_event_mark_and_pause(struct vcpu *v);
-int mem_event_check_ring(struct domain *d, struct mem_event_domain *med);
-void mem_event_put_req_producers(struct mem_event_domain *med);
+int mem_event_claim_slot(struct domain *d, struct mem_event_domain *med);
+void mem_event_release_slot(struct domain *d, struct mem_event_domain *med);
 void mem_event_put_request(struct domain *d, struct mem_event_domain *med, mem_event_request_t *req);
 int mem_event_get_response(struct mem_event_domain *med, mem_event_response_t *rsp);
-void mem_event_unpause_vcpus(struct domain *d);
+void mem_event_wake_requesters(struct mem_event_domain *med);
+void mem_event_wake_waiters(struct domain *d, struct mem_event_domain *med);
+void mem_event_mark_and_sleep(struct vcpu *v, struct mem_event_domain *med);
 
 int mem_event_domctl(struct domain *d, xen_domctl_mem_event_op_t *mec,
                      XEN_GUEST_HANDLE(void) u_domctl);
diff -r 03138a08366b -r d910d738f31b xen/include/xen/sched.h
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -14,6 +14,7 @@
 #include <xen/nodemask.h>
 #include <xen/radix-tree.h>
 #include <xen/multicall.h>
+#include <xen/wait.h>
 #include <public/xen.h>
 #include <public/domctl.h>
 #include <public/sysctl.h>
@@ -183,7 +184,11 @@ struct mem_event_domain
 {
     /* ring lock */
     spinlock_t ring_lock;
-    unsigned int req_producers;
+    /* The ring has 64 entries */
+    unsigned char foreign_producers;
+    unsigned char max_foreign;
+    unsigned char target_producers;
+    unsigned char max_target;
     /* shared page */
     mem_event_shared_page_t *shared_page;
     /* shared ring page */
@@ -192,6 +197,10 @@ struct mem_event_domain
     mem_event_front_ring_t front_ring;
     /* event channel port (vcpu0 only) */
     int xen_port;
+    /* mem_event bit for vcpu->pause_flags */
+    int pause_flag;
+    /* list of vcpus waiting for room in the ring */
+    struct waitqueue_head wq;
 };
 
 struct mem_event_per_domain
@@ -615,9 +624,12 @@ static inline struct domain *next_domain
  /* VCPU affinity has changed: migrating to a new CPU. */
 #define _VPF_migrating       3
 #define VPF_migrating        (1UL<<_VPF_migrating)
- /* VCPU is blocked on memory-event ring. */
-#define _VPF_mem_event       4
-#define VPF_mem_event        (1UL<<_VPF_mem_event)
+ /* VCPU is blocked due to missing mem_paging ring. */
+#define _VPF_mem_paging      4
+#define VPF_mem_paging       (1UL<<_VPF_mem_paging)
+ /* VCPU is blocked due to missing mem_access ring. */
+#define _VPF_mem_access      5
+#define VPF_mem_access       (1UL<<_VPF_mem_access)
 
 static inline int vcpu_runnable(struct vcpu *v)
 {

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 11:40:44 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 11:40:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rcba0-0003hV-Mf; Mon, 19 Dec 2011 11:40:28 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RcbZz-0003hG-9y
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 11:40:28 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-8.tower-21.messagelabs.com!1324294814!8741280!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMDEyMDM=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMDEyMDM=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11931 invoked from network); 19 Dec 2011 11:40:15 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-8.tower-21.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 19 Dec 2011 11:40:15 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1324294814; l=18494;
	s=domk; d=aepfle.de;
	h=To:From:Date:Subject:Content-Transfer-Encoding:MIME-Version:
	Content-Type:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=UeTvWN4sNhs4peSxiPerTRBkDzw=;
	b=uXmNOanD8l9JV3T1GcCht+H84uiQp5SA4PSYN8SQosGYn1bbKuzVvYt09K/mR+IyjIJ
	zpG/GV5EDGqQ1ACtovBMWgdrQk9Mgc8QEqmSct/2EScrXsH57STCQz3uEIgWm6KULUzZ5
	puR49UOFqNYuVTMP5OdU9mabbqd2Iqpzu3o=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lq3c7pG0Q=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-074-029.pools.arcor-ip.net [84.57.74.29])
	by post.strato.de (mrclete mo7) (RZmta 26.15 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id 606c1bnBJAWH9G
	for <xen-devel@lists.xensource.com>;
	Mon, 19 Dec 2011 12:39:48 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id E6A4618636
	for <xen-devel@lists.xensource.com>;
	Mon, 19 Dec 2011 12:39:47 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: d910d738f31b4ee1a6b0727ac0a66cff4c8933b0
Message-Id: <d910d738f31b4ee1a6b0.1324294786@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Mon, 19 Dec 2011 12:39:46 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH] mem_event: use wait queue when ring is full
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1324294734 -3600
# Node ID d910d738f31b4ee1a6b0727ac0a66cff4c8933b0
# Parent  03138a08366b895d79e143119d4c9c72833cdbcd
mem_event: use wait queue when ring is full

This change is based on an idea/patch from Adin Scannell.

If the ring is full, put the current vcpu to sleep if it belongs to the
target domain. The wakeup happens in the p2m_*_resume functions. Wakeup
will take the number of free slots into account.

A request from foreign domain has to succeed once a slot was claimed
because such vcpus can not sleep.

This change fixes also a bug in p2m_mem_paging_drop_page(). Up to now a
full ring will lead to harmless inconsistency in the pager.

v7:
  - add ring accounting so that each vcpu can place at least one request

v6:
  - take foreign requests into account before calling wake_up_nr()
  - call wake_up_nr() outside of ring lock
 - rename ->bit to ->pause_flag
 - update comment in mem_event_enable()

v5:
  - rename mem_event_check_ring() to mem_event_claim_slot()
  - rename mem_event_put_req_producers() to mem_event_release_slot()
  - add local/foreign request accounting
  - keep room for at least one guest request

v4:
 - fix off-by-one bug in _mem_event_put_request
 - add mem_event_wake_requesters() and use wake_up_nr()
 - rename mem_event_mark_and_pause() and mem_event_mark_and_pause() functions
 - req_producers counts foreign request producers, rename member

v3:
 - rename ->mem_event_bit to ->bit
 - remove me_ from new VPF_ defines

v2:
 - p2m_mem_paging_populate: move vcpu_pause after put_request, otherwise the
   vcpu will not wake_up after a wait_event because the pause_count was
   increased twice. Fixes guest hangs.
 - update free space check in _mem_event_put_request()
 - simplify mem_event_put_request()

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 03138a08366b -r d910d738f31b xen/arch/x86/hvm/hvm.c
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -4172,8 +4172,8 @@ static int hvm_memory_event_traps(long p
     if ( (p & HVMPME_onchangeonly) && (value == old) )
         return 1;
     
-    rc = mem_event_check_ring(d, &d->mem_event->access);
-    if ( rc )
+    rc = mem_event_claim_slot(d, &d->mem_event->access);
+    if ( rc < 0 )
         return rc;
     
     memset(&req, 0, sizeof(req));
diff -r 03138a08366b -r d910d738f31b xen/arch/x86/mm/mem_event.c
--- a/xen/arch/x86/mm/mem_event.c
+++ b/xen/arch/x86/mm/mem_event.c
@@ -23,6 +23,7 @@
 
 #include <asm/domain.h>
 #include <xen/event.h>
+#include <xen/wait.h>
 #include <asm/p2m.h>
 #include <asm/mem_event.h>
 #include <asm/mem_paging.h>
@@ -41,6 +42,7 @@ static int mem_event_enable(
     struct domain *d,
     xen_domctl_mem_event_op_t *mec,
     struct mem_event_domain *med,
+    int pause_flag,
     xen_event_channel_notification_t notification_fn)
 {
     int rc;
@@ -110,8 +112,25 @@ static int mem_event_enable(
 
     mem_event_ring_lock_init(med);
 
-    /* Wake any VCPUs paused for memory events */
-    mem_event_unpause_vcpus(d);
+    med->pause_flag = pause_flag;
+
+    /*
+     * Configure ring accounting:
+     * Each guest vcpu should be able to place at least one request.
+     * If there are more vcpus than available slots in the ring, not all vcpus
+     * can place requests in the ring anyway.  A minimum (arbitrary) number of
+     * foreign requests will be allowed in this case.
+     */
+    if ( d->max_vcpus < RING_SIZE(&med->front_ring) )
+        med->max_foreign = RING_SIZE(&med->front_ring) - d->max_vcpus;
+    if ( med->max_foreign < 13 )
+        med->max_foreign = 13;
+    med->max_target = RING_SIZE(&med->front_ring) - med->max_foreign;
+
+    init_waitqueue_head(&med->wq);
+
+    /* Wake any VCPUs waiting for the ring to appear */
+    mem_event_wake_waiters(d, med);
 
     return 0;
 
@@ -127,6 +146,9 @@ static int mem_event_enable(
 
 static int mem_event_disable(struct mem_event_domain *med)
 {
+    if (!list_empty(&med->wq.list))
+        return -EBUSY;
+
     unmap_domain_page(med->ring_page);
     med->ring_page = NULL;
 
@@ -136,14 +158,30 @@ static int mem_event_disable(struct mem_
     return 0;
 }
 
-void mem_event_put_request(struct domain *d, struct mem_event_domain *med, mem_event_request_t *req)
+static int _mem_event_put_request(struct domain *d,
+                                  struct mem_event_domain *med,
+                                  mem_event_request_t *req,
+                                  int *done)
 {
     mem_event_front_ring_t *front_ring;
+    int free_req, claimed_req, ret;
     RING_IDX req_prod;
 
+    if ( *done )
+        return 1;
+
     mem_event_ring_lock(med);
 
     front_ring = &med->front_ring;
+
+    /* Foreign requests must succeed because their vcpus can not sleep */
+    claimed_req = med->foreign_producers;
+    free_req = RING_FREE_REQUESTS(front_ring);
+    if ( !free_req || ( current->domain == d && free_req <= claimed_req ) ) {
+        mem_event_ring_unlock(med);
+        return 0;
+    }
+
     req_prod = front_ring->req_prod_pvt;
 
     if ( current->domain != d )
@@ -156,14 +194,45 @@ void mem_event_put_request(struct domain
     memcpy(RING_GET_REQUEST(front_ring, req_prod), req, sizeof(*req));
     req_prod++;
 
+    ret = 1;
+    *done = 1;
+    free_req--;
+
+    /* Update accounting */
+    if ( current->domain == d )
+    {
+        med->target_producers--;
+        /* Ring is full, no more requests from this vcpu, go to sleep */
+        if ( free_req < med->max_target )
+            ret = 0;
+    }
+    else
+        med->foreign_producers--;
+
     /* Update ring */
-    med->req_producers--;
     front_ring->req_prod_pvt = req_prod;
     RING_PUSH_REQUESTS(front_ring);
 
     mem_event_ring_unlock(med);
 
     notify_via_xen_event_channel(d, med->xen_port);
+
+    return ret;
+}
+
+void mem_event_put_request(struct domain *d, struct mem_event_domain *med,
+                           mem_event_request_t *req)
+{
+    int done = 0;
+    /* Go to sleep if request came from guest */
+    if (current->domain == d) {
+        wait_event(med->wq, _mem_event_put_request(d, med, req, &done));
+        return;
+    }
+    /* Ring was full anyway, unable to sleep in non-guest context */
+    if (!_mem_event_put_request(d, med, req, &done))
+        printk("Failed to put memreq: d %u t %x f %x gfn %lx\n", d->domain_id,
+                req->type, req->flags, (unsigned long)req->gfn);
 }
 
 int mem_event_get_response(struct mem_event_domain *med, mem_event_response_t *rsp)
@@ -195,32 +264,97 @@ int mem_event_get_response(struct mem_ev
     return 1;
 }
 
-void mem_event_unpause_vcpus(struct domain *d)
+/**
+ * mem_event_wake_requesters - Wake vcpus waiting for room in the ring
+ * @d: guest domain
+ * @med: mem_event ring
+ *
+ * mem_event_wake_requesters() will wakeup vcpus waiting for room in the
+ * ring. Only as many as can place another request in the ring will
+ * resume execution.
+ */
+void mem_event_wake_requesters(struct mem_event_domain *med)
+{
+    int free_req;
+
+    mem_event_ring_lock(med);
+    free_req = RING_FREE_REQUESTS(&med->front_ring);
+    free_req -= med->foreign_producers;
+    mem_event_ring_unlock(med);
+
+    if ( free_req )
+        wake_up_nr(&med->wq, free_req);
+}
+
+/**
+ * mem_event_wake_waiters - Wake all vcpus waiting for the ring
+ * @d: guest domain
+ * @med: mem_event ring
+ *
+ * mem_event_wake_waiters() will wakeup all vcpus waiting for the ring to
+ * become available.
+ */
+void mem_event_wake_waiters(struct domain *d, struct mem_event_domain *med)
 {
     struct vcpu *v;
 
     for_each_vcpu ( d, v )
-        if ( test_and_clear_bit(_VPF_mem_event, &v->pause_flags) )
+        if ( test_and_clear_bit(med->pause_flag, &v->pause_flags) )
             vcpu_wake(v);
 }
 
-void mem_event_mark_and_pause(struct vcpu *v)
+/**
+ * mem_event_mark_and_sleep - Put vcpu to sleep
+ * @v: guest vcpu
+ * @med: mem_event ring
+ *
+ * mem_event_mark_and_sleep() tags vcpu and put it to sleep.
+ * The vcpu will resume execution in mem_event_wake_waiters().
+ */
+void mem_event_mark_and_sleep(struct vcpu *v, struct mem_event_domain *med)
 {
-    set_bit(_VPF_mem_event, &v->pause_flags);
+    set_bit(med->pause_flag, &v->pause_flags);
     vcpu_sleep_nosync(v);
 }
 
-void mem_event_put_req_producers(struct mem_event_domain *med)
+/**
+ * mem_event_release_slot - Release a claimed slot
+ * @med: mem_event ring
+ *
+ * mem_event_release_slot() releases a claimed slot in the mem_event ring.
+ */
+void mem_event_release_slot(struct domain *d, struct mem_event_domain *med)
 {
     mem_event_ring_lock(med);
-    med->req_producers--;
+    if ( current->domain == d )
+        med->target_producers--;
+    else
+        med->foreign_producers--;
     mem_event_ring_unlock(med);
 }
 
-int mem_event_check_ring(struct domain *d, struct mem_event_domain *med)
+/**
+ * mem_event_claim_slot - Check state of a mem_event ring
+ * @d: guest domain
+ * @med: mem_event ring
+ *
+ * Return codes: < 0: the ring is not yet configured
+ *                 0: the ring has some room
+ *               > 0: the ring is full
+ *
+ * mem_event_claim_slot() checks the state of the given mem_event ring.
+ * If the current vcpu belongs to the guest domain, the function assumes that
+ * mem_event_put_request() will sleep until the ring has room again.
+ * A guest can always place at least one request.
+ *
+ * If the current vcpu does not belong to the target domain the caller must try
+ * again until there is room. A slot is claimed and the caller can place a
+ * request. If the caller does not need to send a request, the claimed slot has
+ * to be released with mem_event_release_slot().
+ */
+int mem_event_claim_slot(struct domain *d, struct mem_event_domain *med)
 {
-    struct vcpu *curr = current;
-    int free_requests;
+    int free_req;
     int ring_full = 1;
 
     if ( !med->ring_page )
@@ -228,15 +362,19 @@ int mem_event_check_ring(struct domain *
 
     mem_event_ring_lock(med);
 
-    free_requests = RING_FREE_REQUESTS(&med->front_ring);
-    if ( med->req_producers < free_requests )
+    free_req = RING_FREE_REQUESTS(&med->front_ring);
+
+    if ( current->domain == d )
     {
-        med->req_producers++;
+        med->target_producers++;
         ring_full = 0;
     }
-
-    if ( ring_full && (curr->domain == d) )
-        mem_event_mark_and_pause(curr);
+    else if ( med->foreign_producers + med->target_producers < free_req &&
+              med->foreign_producers < med->max_foreign )
+    {
+        med->foreign_producers++;
+        ring_full = 0;
+    }
 
     mem_event_ring_unlock(med);
 
@@ -316,7 +454,7 @@ int mem_event_domctl(struct domain *d, x
             if ( p2m->pod.entry_count )
                 break;
 
-            rc = mem_event_enable(d, mec, med, mem_paging_notification);
+            rc = mem_event_enable(d, mec, med, _VPF_mem_paging, mem_paging_notification);
         }
         break;
 
@@ -355,7 +493,7 @@ int mem_event_domctl(struct domain *d, x
             if ( boot_cpu_data.x86_vendor != X86_VENDOR_INTEL )
                 break;
 
-            rc = mem_event_enable(d, mec, med, mem_access_notification);
+            rc = mem_event_enable(d, mec, med, _VPF_mem_access, mem_access_notification);
         }
         break;
 
diff -r 03138a08366b -r d910d738f31b xen/arch/x86/mm/mem_sharing.c
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -253,18 +253,10 @@ static void mem_sharing_audit(void)
 #endif
 
 
-static struct page_info* mem_sharing_alloc_page(struct domain *d, 
-                                                unsigned long gfn)
+static void mem_sharing_notify_helper(struct domain *d, unsigned long gfn)
 {
-    struct page_info* page;
     struct vcpu *v = current;
-    mem_event_request_t req;
-
-    page = alloc_domheap_page(d, 0); 
-    if(page != NULL) return page;
-
-    memset(&req, 0, sizeof(req));
-    req.type = MEM_EVENT_TYPE_SHARED;
+    mem_event_request_t req = { .type = MEM_EVENT_TYPE_SHARED };
 
     if ( v->domain != d )
     {
@@ -275,20 +267,18 @@ static struct page_info* mem_sharing_all
         gdprintk(XENLOG_ERR, 
                  "Failed alloc on unshare path for foreign (%d) lookup\n",
                  d->domain_id);
-        return page;
+        return;
     }
 
-    vcpu_pause_nosync(v);
-    req.flags |= MEM_EVENT_FLAG_VCPU_PAUSED;
+    if (mem_event_claim_slot(d, &d->mem_event->share) < 0)
+        return;
 
-    if(mem_event_check_ring(d, &d->mem_event->share)) return page;
-
+    req.flags = MEM_EVENT_FLAG_VCPU_PAUSED;
     req.gfn = gfn;
     req.p2mt = p2m_ram_shared;
     req.vcpu_id = v->vcpu_id;
     mem_event_put_request(d, &d->mem_event->share, &req);
-
-    return page;
+    vcpu_pause_nosync(v);
 }
 
 unsigned int mem_sharing_get_nr_saved_mfns(void)
@@ -656,7 +646,7 @@ gfn_found:
     if(ret == 0) goto private_page_found;
         
     old_page = page;
-    page = mem_sharing_alloc_page(d, gfn);
+    page = alloc_domheap_page(d, 0);
     if(!page) 
     {
         /* We've failed to obtain memory for private page. Need to re-add the
@@ -664,6 +654,7 @@ gfn_found:
         list_add(&gfn_info->list, &hash_entry->gfns);
         put_gfn(d, gfn);
         shr_unlock();
+        mem_sharing_notify_helper(d, gfn);
         return -ENOMEM;
     }
 
diff -r 03138a08366b -r d910d738f31b xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -861,20 +861,12 @@ int p2m_mem_paging_evict(struct domain *
  */
 void p2m_mem_paging_drop_page(struct domain *d, unsigned long gfn)
 {
-    struct vcpu *v = current;
-    mem_event_request_t req;
+    mem_event_request_t req = { .type = MEM_EVENT_TYPE_PAGING, .gfn = gfn };
 
-    /* Check that there's space on the ring for this request */
-    if ( mem_event_check_ring(d, &d->mem_event->paging) == 0)
-    {
-        /* Send release notification to pager */
-        memset(&req, 0, sizeof(req));
-        req.flags |= MEM_EVENT_FLAG_DROP_PAGE;
-        req.gfn = gfn;
-        req.vcpu_id = v->vcpu_id;
+    /* Send release notification to pager */
+    req.flags = MEM_EVENT_FLAG_DROP_PAGE;
 
-        mem_event_put_request(d, &d->mem_event->paging, &req);
-    }
+    mem_event_put_request(d, &d->mem_event->paging, &req);
 }
 
 /**
@@ -908,7 +900,7 @@ void p2m_mem_paging_populate(struct doma
     struct p2m_domain *p2m = p2m_get_hostp2m(d);
 
     /* Check that there's space on the ring for this request */
-    if ( mem_event_check_ring(d, &d->mem_event->paging) )
+    if ( mem_event_claim_slot(d, &d->mem_event->paging) )
         return;
 
     memset(&req, 0, sizeof(req));
@@ -938,7 +930,7 @@ void p2m_mem_paging_populate(struct doma
     else if ( p2mt != p2m_ram_paging_out && p2mt != p2m_ram_paged )
     {
         /* gfn is already on its way back and vcpu is not paused */
-        mem_event_put_req_producers(&d->mem_event->paging);
+        mem_event_release_slot(d, &d->mem_event->paging);
         return;
     }
 
@@ -1080,8 +1072,8 @@ void p2m_mem_paging_resume(struct domain
             vcpu_unpause(d->vcpu[rsp.vcpu_id]);
     }
 
-    /* Unpause any domains that were paused because the ring was full */
-    mem_event_unpause_vcpus(d);
+    /* Wake vcpus waiting for room in the ring */
+    mem_event_wake_requesters(&d->mem_event->paging);
 }
 
 bool_t p2m_mem_access_check(unsigned long gpa, bool_t gla_valid, unsigned long gla, 
@@ -1115,7 +1107,7 @@ bool_t p2m_mem_access_check(unsigned lon
     p2m_unlock(p2m);
 
     /* Otherwise, check if there is a memory event listener, and send the message along */
-    res = mem_event_check_ring(d, &d->mem_event->access);
+    res = mem_event_claim_slot(d, &d->mem_event->access);
     if ( res < 0 ) 
     {
         /* No listener */
@@ -1125,7 +1117,7 @@ bool_t p2m_mem_access_check(unsigned lon
                    "Memory access permissions failure, no mem_event listener: pausing VCPU %d, dom %d\n",
                    v->vcpu_id, d->domain_id);
 
-            mem_event_mark_and_pause(v);
+            mem_event_mark_and_sleep(v, &d->mem_event->access);
         }
         else
         {
@@ -1186,9 +1178,11 @@ void p2m_mem_access_resume(struct domain
             vcpu_unpause(d->vcpu[rsp.vcpu_id]);
     }
 
-    /* Unpause any domains that were paused because the ring was full or no listener 
-     * was available */
-    mem_event_unpause_vcpus(d);
+    /* Wake vcpus waiting for room in the ring */
+    mem_event_wake_requesters(&d->mem_event->access);
+
+    /* Unpause all vcpus that were paused because no listener was available */
+    mem_event_wake_waiters(d, &d->mem_event->access);
 }
 
 
diff -r 03138a08366b -r d910d738f31b xen/include/asm-x86/mem_event.h
--- a/xen/include/asm-x86/mem_event.h
+++ b/xen/include/asm-x86/mem_event.h
@@ -24,13 +24,13 @@
 #ifndef __MEM_EVENT_H__
 #define __MEM_EVENT_H__
 
-/* Pauses VCPU while marking pause flag for mem event */
-void mem_event_mark_and_pause(struct vcpu *v);
-int mem_event_check_ring(struct domain *d, struct mem_event_domain *med);
-void mem_event_put_req_producers(struct mem_event_domain *med);
+int mem_event_claim_slot(struct domain *d, struct mem_event_domain *med);
+void mem_event_release_slot(struct domain *d, struct mem_event_domain *med);
 void mem_event_put_request(struct domain *d, struct mem_event_domain *med, mem_event_request_t *req);
 int mem_event_get_response(struct mem_event_domain *med, mem_event_response_t *rsp);
-void mem_event_unpause_vcpus(struct domain *d);
+void mem_event_wake_requesters(struct mem_event_domain *med);
+void mem_event_wake_waiters(struct domain *d, struct mem_event_domain *med);
+void mem_event_mark_and_sleep(struct vcpu *v, struct mem_event_domain *med);
 
 int mem_event_domctl(struct domain *d, xen_domctl_mem_event_op_t *mec,
                      XEN_GUEST_HANDLE(void) u_domctl);
diff -r 03138a08366b -r d910d738f31b xen/include/xen/sched.h
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -14,6 +14,7 @@
 #include <xen/nodemask.h>
 #include <xen/radix-tree.h>
 #include <xen/multicall.h>
+#include <xen/wait.h>
 #include <public/xen.h>
 #include <public/domctl.h>
 #include <public/sysctl.h>
@@ -183,7 +184,11 @@ struct mem_event_domain
 {
     /* ring lock */
     spinlock_t ring_lock;
-    unsigned int req_producers;
+    /* The ring has 64 entries */
+    unsigned char foreign_producers;
+    unsigned char max_foreign;
+    unsigned char target_producers;
+    unsigned char max_target;
     /* shared page */
     mem_event_shared_page_t *shared_page;
     /* shared ring page */
@@ -192,6 +197,10 @@ struct mem_event_domain
     mem_event_front_ring_t front_ring;
     /* event channel port (vcpu0 only) */
     int xen_port;
+    /* mem_event bit for vcpu->pause_flags */
+    int pause_flag;
+    /* list of vcpus waiting for room in the ring */
+    struct waitqueue_head wq;
 };
 
 struct mem_event_per_domain
@@ -615,9 +624,12 @@ static inline struct domain *next_domain
  /* VCPU affinity has changed: migrating to a new CPU. */
 #define _VPF_migrating       3
 #define VPF_migrating        (1UL<<_VPF_migrating)
- /* VCPU is blocked on memory-event ring. */
-#define _VPF_mem_event       4
-#define VPF_mem_event        (1UL<<_VPF_mem_event)
+ /* VCPU is blocked due to missing mem_paging ring. */
+#define _VPF_mem_paging      4
+#define VPF_mem_paging       (1UL<<_VPF_mem_paging)
+ /* VCPU is blocked due to missing mem_access ring. */
+#define _VPF_mem_access      5
+#define VPF_mem_access       (1UL<<_VPF_mem_access)
 
 static inline int vcpu_runnable(struct vcpu *v)
 {

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 11:46:41 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 11:46:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rcbfb-0003wC-Os; Mon, 19 Dec 2011 11:46:15 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1Rcbfa-0003w7-6I
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 11:46:14 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1324295166!8016305!1
X-Originating-IP: [209.85.160.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16745 invoked from network); 19 Dec 2011 11:46:07 -0000
Received: from mail-pw0-f43.google.com (HELO mail-pw0-f43.google.com)
	(209.85.160.43)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Dec 2011 11:46:07 -0000
Received: by pbbb11 with SMTP id b11so19785742pbb.30
	for <xen-devel@lists.xensource.com>;
	Mon, 19 Dec 2011 03:46:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=NYHOE/QF39NR1pZj//jnJYLrhk6g+mZvF4oGtorY1M0=;
	b=Q+QtbrMOdEF3/pxehhIdZB6eye0QhWOSJVqcaU3Y6GMoipike5tnk7oRr1smn3RfNW
	FdsG8rtLqe+x5gKz0z/EEI+4+SjYBvnpOiJhBvTxNnIGW9qwS8fOsX1oUI6BVMhPHpIR
	PlJF47Wcbi06+rSAfUUemw8Cn8LnpFbNKpc6c=
MIME-Version: 1.0
Received: by 10.68.212.68 with SMTP id ni4mr38344552pbc.44.1324295165899; Mon,
	19 Dec 2011 03:46:05 -0800 (PST)
Received: by 10.142.47.17 with HTTP; Mon, 19 Dec 2011 03:46:05 -0800 (PST)
In-Reply-To: <1324294692.9236.30.camel@zakaz.uk.xensource.com>
References: <patchbomb.1324212500@alpine.localdomain>
	<eed78eb655c40b0ac9af.1324212501@alpine.localdomain>
	<1324288096.9236.6.camel@zakaz.uk.xensource.com>
	<CAPLaKK7gEUv9bavavzyYjREPDZJepMkK+-Ap78xzHjPy4SvZ3g@mail.gmail.com>
	<1324289291.9236.16.camel@zakaz.uk.xensource.com>
	<CAPLaKK6=O_h+OxOc_qDLUkw22hV2t6t9wfXOKVuoJf+Ny5+P9g@mail.gmail.com>
	<1324294068.9236.28.camel@zakaz.uk.xensource.com>
	<CAPLaKK771o2-_c=3huGH8ei3jAvL26en=Lu+QCuvdMFbZTi24Q@mail.gmail.com>
	<1324294692.9236.30.camel@zakaz.uk.xensource.com>
Date: Mon, 19 Dec 2011 12:46:05 +0100
X-Google-Sender-Auth: rEIrBEL9W1U-5qzOAv5wpMYyg-g
Message-ID: <CAPLaKK6uCbRDGVXowjX30iCdTQuDZfwQ0U0i5apL7SHu7ye=ug@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 1 of 5] blktap: remove HAVE_BYTESWAP_H
 checking, since it's defined by qemu
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

MjAxMS8xMi8xOSBJYW4gQ2FtcGJlbGwgPElhbi5DYW1wYmVsbEBjaXRyaXguY29tPjoKPiBPbiBN
b24sIDIwMTEtMTItMTkgYXQgMTE6MjggKzAwMDAsIFJvZ2VyIFBhdSBNb25uw6kgd3JvdGU6Cj4+
IDIwMTEvMTIvMTkgSWFuIENhbXBiZWxsIDxJYW4uQ2FtcGJlbGxAY2l0cml4LmNvbT46Cj4+ID4g
T24gTW9uLCAyMDExLTEyLTE5IGF0IDExOjI2ICswMDAwLCBSb2dlciBQYXUgTW9ubsOpIHdyb3Rl
Ogo+PiA+PiAyMDExLzEyLzE5IElhbiBDYW1wYmVsbCA8SWFuLkNhbXBiZWxsQGNpdHJpeC5jb20+
Ogo+PiA+PiA+IEkgdGhpbmsgdGhpcyBpcyB0aGUgY29ycmVjdCBvcHRpb24uIE5vIG5lZWQgdG8g
dW5kZWYgc3R1ZmYuIFRoZXJlIGlzCj4+ID4+ID4gb25seSBvbmUgb3RoZXIgaW5jbHVkZSBvZiBi
eXRlc3dhcC5oIGluIGJsa3RhcC4KPj4gPj4gPgo+PiA+Pgo+PiA+PiBPbiB1Y2xpYmMsIGJ5dGVz
d2FwLmggZ2V0cyBpbmNsdWRlZCBieSBkZWZhdWx0LCBiZWNhdXNlIF9HTlVfU09VUkNFCj4+ID4+
IGltcGxpZXMgX0JTRF9TT1VSQ0UgdGhlcmUuIE9uZSBzb2x1dGlvbiBpcyB0byBhZGQgX1BPU0lY
X1NPVVJDRSwgd2hpY2gKPj4gPj4gcHJldmVudHMgdGhlIGFkZGl0aW9uIG9mIF9CU0RfU09VUkNF
Lgo+PiA+Cj4+ID4gV2hhdCBwYXRoIG9mIGluY2x1ZGVzIGxlYWRzIHRvIHRoZSBpbmNsdXNpb24g
b2YgYnl0ZXN3YXAuaD8KPj4KPj4gVGhpcyBvbmU6Cj4+Cj4+IHN0ZGxpYi5oIC0+IHN5cy90eXBl
cy5oIC0+IGVuZGlhbi5oIC0+IChiZWNhc3VlIF9fVVNFX0JTRCBpcyBkZWZpbmVkKSBieXRlc3dh
cC5oCj4KPiBIcm0gOi0vCj4KPiBTbyBvbiB0aGUgZmxpcCBzaWRlIHdoaWNoIHBsYXRmb3JtcyBk
b24ndCBoYXZlIHRoaXMgaGVhZGVyIGF0IGFsbD8KPgo+IFdpbGxpYW0gc3VnZ2VzdGVkIEJTRCBk
b2Vzbid0IGJ1dCB0aGUgdXNlIG9mIF9fVVNFX0JTRCBzZWVtcyB0byBzdWdnZXN0Cj4gb3RoZXJ3
aXNlPwo+Cj4gRG9lcyBOZXRCU0QgaGF2ZSBieXRlc3dhcC5oPwoKCk5vcGUsIGJ1dCBOZXRCU0Qg
aGFzIGl0J3Mgb3duIHByZXByb2Nlc3NvciBjYXNlOgoKI2lmIGRlZmluZWQoX19OZXRCU0RfXykK
I2luY2x1ZGUgPHN5cy9lbmRpYW4uaD4KI2luY2x1ZGUgPHN5cy90eXBlcy5oPgoKRG9lc24ndCBo
YXZlIGJ5dGVzd2FwLmggcGVyIHNlLCBidXQgdGhlIGZ1bmN0aW9ucyBhcmUgdGhlcmUuIE5ldEJT
RAphbmQgT3BlbkJTRCBhcmUgY292ZXJlZCwgYmVjYXVzZSB0aGV5IGhhdmUgdGhlaXIgc3BlY2lm
aWMgY2FzZXMsIHNvCm9ubHkgU29sYXJpcyBhbmQgTGludXggYXJlIGxlZnQgdG8gdGhpcyBjYXNl
LgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRl
dmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuc291cmNlLmNvbQpodHRwOi8vbGlz
dHMueGVuc291cmNlLmNvbS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Mon Dec 19 11:46:41 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 11:46:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rcbfb-0003wC-Os; Mon, 19 Dec 2011 11:46:15 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1Rcbfa-0003w7-6I
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 11:46:14 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1324295166!8016305!1
X-Originating-IP: [209.85.160.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16745 invoked from network); 19 Dec 2011 11:46:07 -0000
Received: from mail-pw0-f43.google.com (HELO mail-pw0-f43.google.com)
	(209.85.160.43)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Dec 2011 11:46:07 -0000
Received: by pbbb11 with SMTP id b11so19785742pbb.30
	for <xen-devel@lists.xensource.com>;
	Mon, 19 Dec 2011 03:46:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=NYHOE/QF39NR1pZj//jnJYLrhk6g+mZvF4oGtorY1M0=;
	b=Q+QtbrMOdEF3/pxehhIdZB6eye0QhWOSJVqcaU3Y6GMoipike5tnk7oRr1smn3RfNW
	FdsG8rtLqe+x5gKz0z/EEI+4+SjYBvnpOiJhBvTxNnIGW9qwS8fOsX1oUI6BVMhPHpIR
	PlJF47Wcbi06+rSAfUUemw8Cn8LnpFbNKpc6c=
MIME-Version: 1.0
Received: by 10.68.212.68 with SMTP id ni4mr38344552pbc.44.1324295165899; Mon,
	19 Dec 2011 03:46:05 -0800 (PST)
Received: by 10.142.47.17 with HTTP; Mon, 19 Dec 2011 03:46:05 -0800 (PST)
In-Reply-To: <1324294692.9236.30.camel@zakaz.uk.xensource.com>
References: <patchbomb.1324212500@alpine.localdomain>
	<eed78eb655c40b0ac9af.1324212501@alpine.localdomain>
	<1324288096.9236.6.camel@zakaz.uk.xensource.com>
	<CAPLaKK7gEUv9bavavzyYjREPDZJepMkK+-Ap78xzHjPy4SvZ3g@mail.gmail.com>
	<1324289291.9236.16.camel@zakaz.uk.xensource.com>
	<CAPLaKK6=O_h+OxOc_qDLUkw22hV2t6t9wfXOKVuoJf+Ny5+P9g@mail.gmail.com>
	<1324294068.9236.28.camel@zakaz.uk.xensource.com>
	<CAPLaKK771o2-_c=3huGH8ei3jAvL26en=Lu+QCuvdMFbZTi24Q@mail.gmail.com>
	<1324294692.9236.30.camel@zakaz.uk.xensource.com>
Date: Mon, 19 Dec 2011 12:46:05 +0100
X-Google-Sender-Auth: rEIrBEL9W1U-5qzOAv5wpMYyg-g
Message-ID: <CAPLaKK6uCbRDGVXowjX30iCdTQuDZfwQ0U0i5apL7SHu7ye=ug@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 1 of 5] blktap: remove HAVE_BYTESWAP_H
 checking, since it's defined by qemu
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

MjAxMS8xMi8xOSBJYW4gQ2FtcGJlbGwgPElhbi5DYW1wYmVsbEBjaXRyaXguY29tPjoKPiBPbiBN
b24sIDIwMTEtMTItMTkgYXQgMTE6MjggKzAwMDAsIFJvZ2VyIFBhdSBNb25uw6kgd3JvdGU6Cj4+
IDIwMTEvMTIvMTkgSWFuIENhbXBiZWxsIDxJYW4uQ2FtcGJlbGxAY2l0cml4LmNvbT46Cj4+ID4g
T24gTW9uLCAyMDExLTEyLTE5IGF0IDExOjI2ICswMDAwLCBSb2dlciBQYXUgTW9ubsOpIHdyb3Rl
Ogo+PiA+PiAyMDExLzEyLzE5IElhbiBDYW1wYmVsbCA8SWFuLkNhbXBiZWxsQGNpdHJpeC5jb20+
Ogo+PiA+PiA+IEkgdGhpbmsgdGhpcyBpcyB0aGUgY29ycmVjdCBvcHRpb24uIE5vIG5lZWQgdG8g
dW5kZWYgc3R1ZmYuIFRoZXJlIGlzCj4+ID4+ID4gb25seSBvbmUgb3RoZXIgaW5jbHVkZSBvZiBi
eXRlc3dhcC5oIGluIGJsa3RhcC4KPj4gPj4gPgo+PiA+Pgo+PiA+PiBPbiB1Y2xpYmMsIGJ5dGVz
d2FwLmggZ2V0cyBpbmNsdWRlZCBieSBkZWZhdWx0LCBiZWNhdXNlIF9HTlVfU09VUkNFCj4+ID4+
IGltcGxpZXMgX0JTRF9TT1VSQ0UgdGhlcmUuIE9uZSBzb2x1dGlvbiBpcyB0byBhZGQgX1BPU0lY
X1NPVVJDRSwgd2hpY2gKPj4gPj4gcHJldmVudHMgdGhlIGFkZGl0aW9uIG9mIF9CU0RfU09VUkNF
Lgo+PiA+Cj4+ID4gV2hhdCBwYXRoIG9mIGluY2x1ZGVzIGxlYWRzIHRvIHRoZSBpbmNsdXNpb24g
b2YgYnl0ZXN3YXAuaD8KPj4KPj4gVGhpcyBvbmU6Cj4+Cj4+IHN0ZGxpYi5oIC0+IHN5cy90eXBl
cy5oIC0+IGVuZGlhbi5oIC0+IChiZWNhc3VlIF9fVVNFX0JTRCBpcyBkZWZpbmVkKSBieXRlc3dh
cC5oCj4KPiBIcm0gOi0vCj4KPiBTbyBvbiB0aGUgZmxpcCBzaWRlIHdoaWNoIHBsYXRmb3JtcyBk
b24ndCBoYXZlIHRoaXMgaGVhZGVyIGF0IGFsbD8KPgo+IFdpbGxpYW0gc3VnZ2VzdGVkIEJTRCBk
b2Vzbid0IGJ1dCB0aGUgdXNlIG9mIF9fVVNFX0JTRCBzZWVtcyB0byBzdWdnZXN0Cj4gb3RoZXJ3
aXNlPwo+Cj4gRG9lcyBOZXRCU0QgaGF2ZSBieXRlc3dhcC5oPwoKCk5vcGUsIGJ1dCBOZXRCU0Qg
aGFzIGl0J3Mgb3duIHByZXByb2Nlc3NvciBjYXNlOgoKI2lmIGRlZmluZWQoX19OZXRCU0RfXykK
I2luY2x1ZGUgPHN5cy9lbmRpYW4uaD4KI2luY2x1ZGUgPHN5cy90eXBlcy5oPgoKRG9lc24ndCBo
YXZlIGJ5dGVzd2FwLmggcGVyIHNlLCBidXQgdGhlIGZ1bmN0aW9ucyBhcmUgdGhlcmUuIE5ldEJT
RAphbmQgT3BlbkJTRCBhcmUgY292ZXJlZCwgYmVjYXVzZSB0aGV5IGhhdmUgdGhlaXIgc3BlY2lm
aWMgY2FzZXMsIHNvCm9ubHkgU29sYXJpcyBhbmQgTGludXggYXJlIGxlZnQgdG8gdGhpcyBjYXNl
LgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRl
dmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuc291cmNlLmNvbQpodHRwOi8vbGlz
dHMueGVuc291cmNlLmNvbS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Mon Dec 19 11:55:20 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 11: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.xensource.com>)
	id 1Rcbo5-0004J4-Oa; Mon, 19 Dec 2011 11:55:01 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rcbo4-0004Id-9S
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 11:55:00 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1324295693!8804996!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzA0OQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32675 invoked from network); 19 Dec 2011 11:54:53 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Dec 2011 11:54:53 -0000
X-IronPort-AV: E=Sophos;i="4.71,375,1320624000"; 
   d="scan'208";a="9552584"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Dec 2011 11:49:53 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 19 Dec 2011 11:49:53 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau =?ISO-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
Date: Mon, 19 Dec 2011 11:49:52 +0000
In-Reply-To: <CAPLaKK6uCbRDGVXowjX30iCdTQuDZfwQ0U0i5apL7SHu7ye=ug@mail.gmail.com>
References: <patchbomb.1324212500@alpine.localdomain>
	<eed78eb655c40b0ac9af.1324212501@alpine.localdomain>
	<1324288096.9236.6.camel@zakaz.uk.xensource.com>
	<CAPLaKK7gEUv9bavavzyYjREPDZJepMkK+-Ap78xzHjPy4SvZ3g@mail.gmail.com>
	<1324289291.9236.16.camel@zakaz.uk.xensource.com>
	<CAPLaKK6=O_h+OxOc_qDLUkw22hV2t6t9wfXOKVuoJf+Ny5+P9g@mail.gmail.com>
	<1324294068.9236.28.camel@zakaz.uk.xensource.com>
	<CAPLaKK771o2-_c=3huGH8ei3jAvL26en=Lu+QCuvdMFbZTi24Q@mail.gmail.com>
	<1324294692.9236.30.camel@zakaz.uk.xensource.com>
	<CAPLaKK6uCbRDGVXowjX30iCdTQuDZfwQ0U0i5apL7SHu7ye=ug@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1324295392.9236.32.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 1 of 5] blktap: remove HAVE_BYTESWAP_H
 checking, since it's defined by qemu
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gTW9uLCAyMDExLTEyLTE5IGF0IDExOjQ2ICswMDAwLCBSb2dlciBQYXUgTW9ubsOpIHdyb3Rl
Ogo+IDIwMTEvMTIvMTkgSWFuIENhbXBiZWxsIDxJYW4uQ2FtcGJlbGxAY2l0cml4LmNvbT46Cj4g
PiBPbiBNb24sIDIwMTEtMTItMTkgYXQgMTE6MjggKzAwMDAsIFJvZ2VyIFBhdSBNb25uw6kgd3Jv
dGU6Cj4gPj4gMjAxMS8xMi8xOSBJYW4gQ2FtcGJlbGwgPElhbi5DYW1wYmVsbEBjaXRyaXguY29t
PjoKPiA+PiA+IE9uIE1vbiwgMjAxMS0xMi0xOSBhdCAxMToyNiArMDAwMCwgUm9nZXIgUGF1IE1v
bm7DqSB3cm90ZToKPiA+PiA+PiAyMDExLzEyLzE5IElhbiBDYW1wYmVsbCA8SWFuLkNhbXBiZWxs
QGNpdHJpeC5jb20+Ogo+ID4+ID4+ID4gSSB0aGluayB0aGlzIGlzIHRoZSBjb3JyZWN0IG9wdGlv
bi4gTm8gbmVlZCB0byB1bmRlZiBzdHVmZi4gVGhlcmUgaXMKPiA+PiA+PiA+IG9ubHkgb25lIG90
aGVyIGluY2x1ZGUgb2YgYnl0ZXN3YXAuaCBpbiBibGt0YXAuCj4gPj4gPj4gPgo+ID4+ID4+Cj4g
Pj4gPj4gT24gdWNsaWJjLCBieXRlc3dhcC5oIGdldHMgaW5jbHVkZWQgYnkgZGVmYXVsdCwgYmVj
YXVzZSBfR05VX1NPVVJDRQo+ID4+ID4+IGltcGxpZXMgX0JTRF9TT1VSQ0UgdGhlcmUuIE9uZSBz
b2x1dGlvbiBpcyB0byBhZGQgX1BPU0lYX1NPVVJDRSwgd2hpY2gKPiA+PiA+PiBwcmV2ZW50cyB0
aGUgYWRkaXRpb24gb2YgX0JTRF9TT1VSQ0UuCj4gPj4gPgo+ID4+ID4gV2hhdCBwYXRoIG9mIGlu
Y2x1ZGVzIGxlYWRzIHRvIHRoZSBpbmNsdXNpb24gb2YgYnl0ZXN3YXAuaD8KPiA+Pgo+ID4+IFRo
aXMgb25lOgo+ID4+Cj4gPj4gc3RkbGliLmggLT4gc3lzL3R5cGVzLmggLT4gZW5kaWFuLmggLT4g
KGJlY2FzdWUgX19VU0VfQlNEIGlzIGRlZmluZWQpIGJ5dGVzd2FwLmgKPiA+Cj4gPiBIcm0gOi0v
Cj4gPgo+ID4gU28gb24gdGhlIGZsaXAgc2lkZSB3aGljaCBwbGF0Zm9ybXMgZG9uJ3QgaGF2ZSB0
aGlzIGhlYWRlciBhdCBhbGw/Cj4gPgo+ID4gV2lsbGlhbSBzdWdnZXN0ZWQgQlNEIGRvZXNuJ3Qg
YnV0IHRoZSB1c2Ugb2YgX19VU0VfQlNEIHNlZW1zIHRvIHN1Z2dlc3QKPiA+IG90aGVyd2lzZT8K
PiA+Cj4gPiBEb2VzIE5ldEJTRCBoYXZlIGJ5dGVzd2FwLmg/Cj4gCj4gCj4gTm9wZSwgYnV0IE5l
dEJTRCBoYXMgaXQncyBvd24gcHJlcHJvY2Vzc29yIGNhc2U6Cj4gCj4gI2lmIGRlZmluZWQoX19O
ZXRCU0RfXykKPiAjaW5jbHVkZSA8c3lzL2VuZGlhbi5oPgo+ICNpbmNsdWRlIDxzeXMvdHlwZXMu
aD4KPiAKPiBEb2Vzbid0IGhhdmUgYnl0ZXN3YXAuaCBwZXIgc2UsIGJ1dCB0aGUgZnVuY3Rpb25z
IGFyZSB0aGVyZS4gTmV0QlNECj4gYW5kIE9wZW5CU0QgYXJlIGNvdmVyZWQsIGJlY2F1c2UgdGhl
eSBoYXZlIHRoZWlyIHNwZWNpZmljIGNhc2VzLCBzbwo+IG9ubHkgU29sYXJpcyBhbmQgTGludXgg
YXJlIGxlZnQgdG8gdGhpcyBjYXNlLgoKU29sYXJpcyBpc24ndCBhbiBpc3N1ZSB0aGVzZSBkYXlz
LgoKU28sIEkgdGhpbmsgdGhlIGFwcHJvYWNoIHVzZWQgYnkgdG9vbHMvYmxrdGFwMi9pbmNsdWRl
L2xpYnZoZC5oIHNob3VsZApiZSB1c2VkIGluIHRvb2xzL2Jsa3RhcDIvZHJpdmVycy9ic3dhcC5o
IHRvby4gaS5lLiAjaW5jbHVkZSBieXRlc3dhcC5oCmZvciBMaW51eCBhbmQgcmVtb3ZlIHRoZSBs
b2NhbCBkZWZpbml0aW9ucyBvZiB0aGUgc3dhcCBmdW5jdGlvbnMvbWFjcm9zLgoKSWFuLgoKCgpf
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwg
bWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tCmh0dHA6Ly9saXN0cy54
ZW5zb3VyY2UuY29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Mon Dec 19 11:55:20 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 11: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.xensource.com>)
	id 1Rcbo5-0004J4-Oa; Mon, 19 Dec 2011 11:55:01 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rcbo4-0004Id-9S
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 11:55:00 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1324295693!8804996!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzA0OQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32675 invoked from network); 19 Dec 2011 11:54:53 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Dec 2011 11:54:53 -0000
X-IronPort-AV: E=Sophos;i="4.71,375,1320624000"; 
   d="scan'208";a="9552584"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Dec 2011 11:49:53 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 19 Dec 2011 11:49:53 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau =?ISO-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
Date: Mon, 19 Dec 2011 11:49:52 +0000
In-Reply-To: <CAPLaKK6uCbRDGVXowjX30iCdTQuDZfwQ0U0i5apL7SHu7ye=ug@mail.gmail.com>
References: <patchbomb.1324212500@alpine.localdomain>
	<eed78eb655c40b0ac9af.1324212501@alpine.localdomain>
	<1324288096.9236.6.camel@zakaz.uk.xensource.com>
	<CAPLaKK7gEUv9bavavzyYjREPDZJepMkK+-Ap78xzHjPy4SvZ3g@mail.gmail.com>
	<1324289291.9236.16.camel@zakaz.uk.xensource.com>
	<CAPLaKK6=O_h+OxOc_qDLUkw22hV2t6t9wfXOKVuoJf+Ny5+P9g@mail.gmail.com>
	<1324294068.9236.28.camel@zakaz.uk.xensource.com>
	<CAPLaKK771o2-_c=3huGH8ei3jAvL26en=Lu+QCuvdMFbZTi24Q@mail.gmail.com>
	<1324294692.9236.30.camel@zakaz.uk.xensource.com>
	<CAPLaKK6uCbRDGVXowjX30iCdTQuDZfwQ0U0i5apL7SHu7ye=ug@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1324295392.9236.32.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 1 of 5] blktap: remove HAVE_BYTESWAP_H
 checking, since it's defined by qemu
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gTW9uLCAyMDExLTEyLTE5IGF0IDExOjQ2ICswMDAwLCBSb2dlciBQYXUgTW9ubsOpIHdyb3Rl
Ogo+IDIwMTEvMTIvMTkgSWFuIENhbXBiZWxsIDxJYW4uQ2FtcGJlbGxAY2l0cml4LmNvbT46Cj4g
PiBPbiBNb24sIDIwMTEtMTItMTkgYXQgMTE6MjggKzAwMDAsIFJvZ2VyIFBhdSBNb25uw6kgd3Jv
dGU6Cj4gPj4gMjAxMS8xMi8xOSBJYW4gQ2FtcGJlbGwgPElhbi5DYW1wYmVsbEBjaXRyaXguY29t
PjoKPiA+PiA+IE9uIE1vbiwgMjAxMS0xMi0xOSBhdCAxMToyNiArMDAwMCwgUm9nZXIgUGF1IE1v
bm7DqSB3cm90ZToKPiA+PiA+PiAyMDExLzEyLzE5IElhbiBDYW1wYmVsbCA8SWFuLkNhbXBiZWxs
QGNpdHJpeC5jb20+Ogo+ID4+ID4+ID4gSSB0aGluayB0aGlzIGlzIHRoZSBjb3JyZWN0IG9wdGlv
bi4gTm8gbmVlZCB0byB1bmRlZiBzdHVmZi4gVGhlcmUgaXMKPiA+PiA+PiA+IG9ubHkgb25lIG90
aGVyIGluY2x1ZGUgb2YgYnl0ZXN3YXAuaCBpbiBibGt0YXAuCj4gPj4gPj4gPgo+ID4+ID4+Cj4g
Pj4gPj4gT24gdWNsaWJjLCBieXRlc3dhcC5oIGdldHMgaW5jbHVkZWQgYnkgZGVmYXVsdCwgYmVj
YXVzZSBfR05VX1NPVVJDRQo+ID4+ID4+IGltcGxpZXMgX0JTRF9TT1VSQ0UgdGhlcmUuIE9uZSBz
b2x1dGlvbiBpcyB0byBhZGQgX1BPU0lYX1NPVVJDRSwgd2hpY2gKPiA+PiA+PiBwcmV2ZW50cyB0
aGUgYWRkaXRpb24gb2YgX0JTRF9TT1VSQ0UuCj4gPj4gPgo+ID4+ID4gV2hhdCBwYXRoIG9mIGlu
Y2x1ZGVzIGxlYWRzIHRvIHRoZSBpbmNsdXNpb24gb2YgYnl0ZXN3YXAuaD8KPiA+Pgo+ID4+IFRo
aXMgb25lOgo+ID4+Cj4gPj4gc3RkbGliLmggLT4gc3lzL3R5cGVzLmggLT4gZW5kaWFuLmggLT4g
KGJlY2FzdWUgX19VU0VfQlNEIGlzIGRlZmluZWQpIGJ5dGVzd2FwLmgKPiA+Cj4gPiBIcm0gOi0v
Cj4gPgo+ID4gU28gb24gdGhlIGZsaXAgc2lkZSB3aGljaCBwbGF0Zm9ybXMgZG9uJ3QgaGF2ZSB0
aGlzIGhlYWRlciBhdCBhbGw/Cj4gPgo+ID4gV2lsbGlhbSBzdWdnZXN0ZWQgQlNEIGRvZXNuJ3Qg
YnV0IHRoZSB1c2Ugb2YgX19VU0VfQlNEIHNlZW1zIHRvIHN1Z2dlc3QKPiA+IG90aGVyd2lzZT8K
PiA+Cj4gPiBEb2VzIE5ldEJTRCBoYXZlIGJ5dGVzd2FwLmg/Cj4gCj4gCj4gTm9wZSwgYnV0IE5l
dEJTRCBoYXMgaXQncyBvd24gcHJlcHJvY2Vzc29yIGNhc2U6Cj4gCj4gI2lmIGRlZmluZWQoX19O
ZXRCU0RfXykKPiAjaW5jbHVkZSA8c3lzL2VuZGlhbi5oPgo+ICNpbmNsdWRlIDxzeXMvdHlwZXMu
aD4KPiAKPiBEb2Vzbid0IGhhdmUgYnl0ZXN3YXAuaCBwZXIgc2UsIGJ1dCB0aGUgZnVuY3Rpb25z
IGFyZSB0aGVyZS4gTmV0QlNECj4gYW5kIE9wZW5CU0QgYXJlIGNvdmVyZWQsIGJlY2F1c2UgdGhl
eSBoYXZlIHRoZWlyIHNwZWNpZmljIGNhc2VzLCBzbwo+IG9ubHkgU29sYXJpcyBhbmQgTGludXgg
YXJlIGxlZnQgdG8gdGhpcyBjYXNlLgoKU29sYXJpcyBpc24ndCBhbiBpc3N1ZSB0aGVzZSBkYXlz
LgoKU28sIEkgdGhpbmsgdGhlIGFwcHJvYWNoIHVzZWQgYnkgdG9vbHMvYmxrdGFwMi9pbmNsdWRl
L2xpYnZoZC5oIHNob3VsZApiZSB1c2VkIGluIHRvb2xzL2Jsa3RhcDIvZHJpdmVycy9ic3dhcC5o
IHRvby4gaS5lLiAjaW5jbHVkZSBieXRlc3dhcC5oCmZvciBMaW51eCBhbmQgcmVtb3ZlIHRoZSBs
b2NhbCBkZWZpbml0aW9ucyBvZiB0aGUgc3dhcCBmdW5jdGlvbnMvbWFjcm9zLgoKSWFuLgoKCgpf
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwg
bWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tCmh0dHA6Ly9saXN0cy54
ZW5zb3VyY2UuY29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Mon Dec 19 12:04:45 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 12:04:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RcbxI-0004y8-5W; Mon, 19 Dec 2011 12:04:32 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RcbxG-0004xt-30
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 12:04:30 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1324296261!5930046!1
X-Originating-IP: [209.85.210.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29852 invoked from network); 19 Dec 2011 12:04:23 -0000
Received: from mail-pz0-f43.google.com (HELO mail-pz0-f43.google.com)
	(209.85.210.43)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Dec 2011 12:04:23 -0000
Received: by daec6 with SMTP id c6so25167421dae.30
	for <xen-devel@lists.xensource.com>;
	Mon, 19 Dec 2011 04:04:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=geVIn0ylFruyGakyqHbLLAy3DQpZ8wDvvveiASuYT6M=;
	b=wNdmUifZ0gBTFoJ9v+n4dOABLUMFXAUw+6zEhGfnJ4Cx128hOkEOxcYUHvKe1ynQm9
	vOMe7O7TDQLLuahjatvXyTOcxD+2+hvepbhwcrYTjERW/Q/tafe9RAMxb9JHlo3JSv2p
	pgBWfZf/76/p8YF6VmlCJVj/irlObGt2PTleI=
MIME-Version: 1.0
Received: by 10.68.190.232 with SMTP id gt8mr37896662pbc.61.1324296261041;
	Mon, 19 Dec 2011 04:04:21 -0800 (PST)
Received: by 10.142.47.17 with HTTP; Mon, 19 Dec 2011 04:04:20 -0800 (PST)
In-Reply-To: <1324295392.9236.32.camel@zakaz.uk.xensource.com>
References: <patchbomb.1324212500@alpine.localdomain>
	<eed78eb655c40b0ac9af.1324212501@alpine.localdomain>
	<1324288096.9236.6.camel@zakaz.uk.xensource.com>
	<CAPLaKK7gEUv9bavavzyYjREPDZJepMkK+-Ap78xzHjPy4SvZ3g@mail.gmail.com>
	<1324289291.9236.16.camel@zakaz.uk.xensource.com>
	<CAPLaKK6=O_h+OxOc_qDLUkw22hV2t6t9wfXOKVuoJf+Ny5+P9g@mail.gmail.com>
	<1324294068.9236.28.camel@zakaz.uk.xensource.com>
	<CAPLaKK771o2-_c=3huGH8ei3jAvL26en=Lu+QCuvdMFbZTi24Q@mail.gmail.com>
	<1324294692.9236.30.camel@zakaz.uk.xensource.com>
	<CAPLaKK6uCbRDGVXowjX30iCdTQuDZfwQ0U0i5apL7SHu7ye=ug@mail.gmail.com>
	<1324295392.9236.32.camel@zakaz.uk.xensource.com>
Date: Mon, 19 Dec 2011 13:04:20 +0100
X-Google-Sender-Auth: l3XMonV-zcvSrFHU9TKYbirZXRY
Message-ID: <CAPLaKK5aNB70bXqL1-FxCpanMM92WnuVNbs6UV7gu7LA8L363g@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 1 of 5] blktap: remove HAVE_BYTESWAP_H
 checking, since it's defined by qemu
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

2011/12/19 Ian Campbell <Ian.Campbell@citrix.com>:
> So, I think the approach used by tools/blktap2/include/libvhd.h should
> be used in tools/blktap2/drivers/bswap.h too. i.e. #include byteswap.h
> for Linux and remove the local definitions of the swap functions/macros.

Ok, I've included endian.h and byteswap.h just like libvhd.h does.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 12:04:45 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 12:04:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RcbxI-0004y8-5W; Mon, 19 Dec 2011 12:04:32 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RcbxG-0004xt-30
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 12:04:30 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1324296261!5930046!1
X-Originating-IP: [209.85.210.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29852 invoked from network); 19 Dec 2011 12:04:23 -0000
Received: from mail-pz0-f43.google.com (HELO mail-pz0-f43.google.com)
	(209.85.210.43)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Dec 2011 12:04:23 -0000
Received: by daec6 with SMTP id c6so25167421dae.30
	for <xen-devel@lists.xensource.com>;
	Mon, 19 Dec 2011 04:04:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=geVIn0ylFruyGakyqHbLLAy3DQpZ8wDvvveiASuYT6M=;
	b=wNdmUifZ0gBTFoJ9v+n4dOABLUMFXAUw+6zEhGfnJ4Cx128hOkEOxcYUHvKe1ynQm9
	vOMe7O7TDQLLuahjatvXyTOcxD+2+hvepbhwcrYTjERW/Q/tafe9RAMxb9JHlo3JSv2p
	pgBWfZf/76/p8YF6VmlCJVj/irlObGt2PTleI=
MIME-Version: 1.0
Received: by 10.68.190.232 with SMTP id gt8mr37896662pbc.61.1324296261041;
	Mon, 19 Dec 2011 04:04:21 -0800 (PST)
Received: by 10.142.47.17 with HTTP; Mon, 19 Dec 2011 04:04:20 -0800 (PST)
In-Reply-To: <1324295392.9236.32.camel@zakaz.uk.xensource.com>
References: <patchbomb.1324212500@alpine.localdomain>
	<eed78eb655c40b0ac9af.1324212501@alpine.localdomain>
	<1324288096.9236.6.camel@zakaz.uk.xensource.com>
	<CAPLaKK7gEUv9bavavzyYjREPDZJepMkK+-Ap78xzHjPy4SvZ3g@mail.gmail.com>
	<1324289291.9236.16.camel@zakaz.uk.xensource.com>
	<CAPLaKK6=O_h+OxOc_qDLUkw22hV2t6t9wfXOKVuoJf+Ny5+P9g@mail.gmail.com>
	<1324294068.9236.28.camel@zakaz.uk.xensource.com>
	<CAPLaKK771o2-_c=3huGH8ei3jAvL26en=Lu+QCuvdMFbZTi24Q@mail.gmail.com>
	<1324294692.9236.30.camel@zakaz.uk.xensource.com>
	<CAPLaKK6uCbRDGVXowjX30iCdTQuDZfwQ0U0i5apL7SHu7ye=ug@mail.gmail.com>
	<1324295392.9236.32.camel@zakaz.uk.xensource.com>
Date: Mon, 19 Dec 2011 13:04:20 +0100
X-Google-Sender-Auth: l3XMonV-zcvSrFHU9TKYbirZXRY
Message-ID: <CAPLaKK5aNB70bXqL1-FxCpanMM92WnuVNbs6UV7gu7LA8L363g@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 1 of 5] blktap: remove HAVE_BYTESWAP_H
 checking, since it's defined by qemu
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

2011/12/19 Ian Campbell <Ian.Campbell@citrix.com>:
> So, I think the approach used by tools/blktap2/include/libvhd.h should
> be used in tools/blktap2/drivers/bswap.h too. i.e. #include byteswap.h
> for Linux and remove the local definitions of the swap functions/macros.

Ok, I've included endian.h and byteswap.h just like libvhd.h does.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 12:05:10 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 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.xensource.com>)
	id 1Rcbxi-00050O-JS; Mon, 19 Dec 2011 12:04:58 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Rcbxh-0004zp-AR
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 12:04:57 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1324296271!49864930!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26170 invoked from network); 19 Dec 2011 12:04:31 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-11.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 19 Dec 2011 12:04:31 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 19 Dec 2011 12:04:52 +0000
Message-Id: <4EEF36A60200007800068D43@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 19 Dec 2011 12:05:42 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "George Dunlap" <George.Dunlap@eu.citrix.com>
References: <C10D3FB0CD45994C8A51FEC1227CE22F37CC284376@shsmsx502.ccr.corp.intel.com>
	<4EEF02E20200007800068C60@nat28.tlf.novell.com>
	<CAFLBxZb3Yc7G4QzEXKdfrVkoz1XGv09zTxCQCC4Dnkr-6M5K5Q@mail.gmail.com>
In-Reply-To: <CAFLBxZb3Yc7G4QzEXKdfrVkoz1XGv09zTxCQCC4Dnkr-6M5K5Q@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Kevin Tian <kevin.tian@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"keir@xen.org" <keir@xen.org>, Eddie Dong <eddie.dong@intel.com>,
	Hui Lv <hui.lv@intel.com>, Jiangang Duan <jiangang.duan@intel.com>,
	Zhidong Yu <zhidong.yu@intel.com>
Subject: Re: [Xen-devel] [PATCH v2] xen/credit scheduler;
 Use delay to control scheduling frequency
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 19.12.11 at 12:32, George Dunlap <George.Dunlap@eu.citrix.com> wrote:
> On Mon, Dec 19, 2011 at 8:24 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>> +         && vcpu_runnable(current)
>>> +         && !is_idle_vcpu(current)
>>> +         && runtime < MICROSECS(sched_ratelimit_us) )
>>> +    {
>>> +        snext = scurr;
>>> +        snext->start_time += now;
>>> +        perfc_incr(delay_ms);
>>> +        tslice = MICROSECS(sched_ratelimit_us);
>>
>> So if there happens to be a VM with
>>
>> MILLISECS(prv->tslice_ms) < MICROSECS(sched_ratelimit_us)
>>
>> it'd get *more* time than allowed/intended through this mechanism.
> 
> Yeah, if you set your default timeslice to 1ms, and then set your
> minimum scheduling rate to 5ms, you're going to get weird results. :-)
> 
> The way it stands now, the ratelimit value will override the timeslice
> value.  It had to be one way or the other; do you think the timeslice
> value should be the priority?

The minimum of both should be used, I would think.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 12:05:10 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 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.xensource.com>)
	id 1Rcbxi-00050O-JS; Mon, 19 Dec 2011 12:04:58 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Rcbxh-0004zp-AR
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 12:04:57 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1324296271!49864930!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26170 invoked from network); 19 Dec 2011 12:04:31 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-11.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 19 Dec 2011 12:04:31 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 19 Dec 2011 12:04:52 +0000
Message-Id: <4EEF36A60200007800068D43@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 19 Dec 2011 12:05:42 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "George Dunlap" <George.Dunlap@eu.citrix.com>
References: <C10D3FB0CD45994C8A51FEC1227CE22F37CC284376@shsmsx502.ccr.corp.intel.com>
	<4EEF02E20200007800068C60@nat28.tlf.novell.com>
	<CAFLBxZb3Yc7G4QzEXKdfrVkoz1XGv09zTxCQCC4Dnkr-6M5K5Q@mail.gmail.com>
In-Reply-To: <CAFLBxZb3Yc7G4QzEXKdfrVkoz1XGv09zTxCQCC4Dnkr-6M5K5Q@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Kevin Tian <kevin.tian@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"keir@xen.org" <keir@xen.org>, Eddie Dong <eddie.dong@intel.com>,
	Hui Lv <hui.lv@intel.com>, Jiangang Duan <jiangang.duan@intel.com>,
	Zhidong Yu <zhidong.yu@intel.com>
Subject: Re: [Xen-devel] [PATCH v2] xen/credit scheduler;
 Use delay to control scheduling frequency
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 19.12.11 at 12:32, George Dunlap <George.Dunlap@eu.citrix.com> wrote:
> On Mon, Dec 19, 2011 at 8:24 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>> +         && vcpu_runnable(current)
>>> +         && !is_idle_vcpu(current)
>>> +         && runtime < MICROSECS(sched_ratelimit_us) )
>>> +    {
>>> +        snext = scurr;
>>> +        snext->start_time += now;
>>> +        perfc_incr(delay_ms);
>>> +        tslice = MICROSECS(sched_ratelimit_us);
>>
>> So if there happens to be a VM with
>>
>> MILLISECS(prv->tslice_ms) < MICROSECS(sched_ratelimit_us)
>>
>> it'd get *more* time than allowed/intended through this mechanism.
> 
> Yeah, if you set your default timeslice to 1ms, and then set your
> minimum scheduling rate to 5ms, you're going to get weird results. :-)
> 
> The way it stands now, the ratelimit value will override the timeslice
> value.  It had to be one way or the other; do you think the timeslice
> value should be the priority?

The minimum of both should be used, I would think.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 12:30:39 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 12:30:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RccMH-0005af-U6; Mon, 19 Dec 2011 12:30:21 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RccMG-0005aX-IH
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 12:30:20 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1324297812!7773709!1
X-Originating-IP: [209.85.160.43]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4757 invoked from network); 19 Dec 2011 12:30:14 -0000
Received: from mail-pw0-f43.google.com (HELO mail-pw0-f43.google.com)
	(209.85.160.43)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Dec 2011 12:30:14 -0000
Received: by pbbb11 with SMTP id b11so19862143pbb.30
	for <xen-devel@lists.xensource.com>;
	Mon, 19 Dec 2011 04:30:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=wHNEm7KIQ8KhYcUkn3OiK2OgREByLHLGTVIeN96hvPY=;
	b=v8tXeUROEAGl1A0pJYbW3P+zzcVICldddXYfhX0z9098tChkD2r4d212WmVmFUSCL/
	dh0BsO/df9P4bf2Vn+y6t4m3wTE++ZT1URh1L+jcwmvZ9FZ/MQu6k7CSO+EHBjoFxlwx
	iohPSXLTHQHf8awyJipjdVxXxGTz7O8i//z3U=
MIME-Version: 1.0
Received: by 10.68.190.226 with SMTP id gt2mr4834876pbc.112.1324297812024;
	Mon, 19 Dec 2011 04:30:12 -0800 (PST)
Received: by 10.142.47.17 with HTTP; Mon, 19 Dec 2011 04:30:11 -0800 (PST)
In-Reply-To: <CA+T2pCE_L0Gfyb0xu4=bd-yCAz=+Z_4Ugyd-EoO4m=+jz5MPGA@mail.gmail.com>
References: <patchbomb.1324212500@alpine.localdomain>
	<c0d5aa328f1ab24aad58.1324212503@alpine.localdomain>
	<CA+T2pCE_L0Gfyb0xu4=bd-yCAz=+Z_4Ugyd-EoO4m=+jz5MPGA@mail.gmail.com>
Date: Mon, 19 Dec 2011 13:30:11 +0100
X-Google-Sender-Auth: rNtVZh2by_CZcTZO0jzL0Mkwpw8
Message-ID: <CAPLaKK5gYZ+KDsJW4+FSkP=nqDJmaO3W72pfkbg8m25fYu+_1Q@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: William Pitcock <nenolod@dereferenced.org>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 3 of 5] blktap2: fix vhd compilation under
	uclibc
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

What's strange is that libvhd (which uses iconv) compiles and links
fine, but vhd-util that uses libvhd complains about undefined
references to iconv, when vhd-util doesn't use iconv.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 12:30:39 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 12:30:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RccMH-0005af-U6; Mon, 19 Dec 2011 12:30:21 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RccMG-0005aX-IH
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 12:30:20 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1324297812!7773709!1
X-Originating-IP: [209.85.160.43]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4757 invoked from network); 19 Dec 2011 12:30:14 -0000
Received: from mail-pw0-f43.google.com (HELO mail-pw0-f43.google.com)
	(209.85.160.43)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Dec 2011 12:30:14 -0000
Received: by pbbb11 with SMTP id b11so19862143pbb.30
	for <xen-devel@lists.xensource.com>;
	Mon, 19 Dec 2011 04:30:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=wHNEm7KIQ8KhYcUkn3OiK2OgREByLHLGTVIeN96hvPY=;
	b=v8tXeUROEAGl1A0pJYbW3P+zzcVICldddXYfhX0z9098tChkD2r4d212WmVmFUSCL/
	dh0BsO/df9P4bf2Vn+y6t4m3wTE++ZT1URh1L+jcwmvZ9FZ/MQu6k7CSO+EHBjoFxlwx
	iohPSXLTHQHf8awyJipjdVxXxGTz7O8i//z3U=
MIME-Version: 1.0
Received: by 10.68.190.226 with SMTP id gt2mr4834876pbc.112.1324297812024;
	Mon, 19 Dec 2011 04:30:12 -0800 (PST)
Received: by 10.142.47.17 with HTTP; Mon, 19 Dec 2011 04:30:11 -0800 (PST)
In-Reply-To: <CA+T2pCE_L0Gfyb0xu4=bd-yCAz=+Z_4Ugyd-EoO4m=+jz5MPGA@mail.gmail.com>
References: <patchbomb.1324212500@alpine.localdomain>
	<c0d5aa328f1ab24aad58.1324212503@alpine.localdomain>
	<CA+T2pCE_L0Gfyb0xu4=bd-yCAz=+Z_4Ugyd-EoO4m=+jz5MPGA@mail.gmail.com>
Date: Mon, 19 Dec 2011 13:30:11 +0100
X-Google-Sender-Auth: rNtVZh2by_CZcTZO0jzL0Mkwpw8
Message-ID: <CAPLaKK5gYZ+KDsJW4+FSkP=nqDJmaO3W72pfkbg8m25fYu+_1Q@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: William Pitcock <nenolod@dereferenced.org>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 3 of 5] blktap2: fix vhd compilation under
	uclibc
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

What's strange is that libvhd (which uses iconv) compiles and links
fine, but vhd-util that uses libvhd complains about undefined
references to iconv, when vhd-util doesn't use iconv.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 13:27:36 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 13: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.xensource.com>)
	id 1RcdEx-00064f-Uy; Mon, 19 Dec 2011 13:26:51 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RcdEw-00064a-VT
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 13:26:51 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1324301204!6122866!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzA0OQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29568 invoked from network); 19 Dec 2011 13:26:44 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Dec 2011 13:26:44 -0000
X-IronPort-AV: E=Sophos;i="4.71,376,1320624000"; 
   d="scan'208";a="9555241"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Dec 2011 13:26:44 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 19 Dec 2011 13:26:44 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau =?ISO-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
Date: Mon, 19 Dec 2011 13:26:43 +0000
In-Reply-To: <CAPLaKK5gYZ+KDsJW4+FSkP=nqDJmaO3W72pfkbg8m25fYu+_1Q@mail.gmail.com>
References: <patchbomb.1324212500@alpine.localdomain>
	<c0d5aa328f1ab24aad58.1324212503@alpine.localdomain>
	<CA+T2pCE_L0Gfyb0xu4=bd-yCAz=+Z_4Ugyd-EoO4m=+jz5MPGA@mail.gmail.com>
	<CAPLaKK5gYZ+KDsJW4+FSkP=nqDJmaO3W72pfkbg8m25fYu+_1Q@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1324301203.9236.40.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: William Pitcock <nenolod@dereferenced.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 3 of 5] blktap2: fix vhd compilation under
 uclibc
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gTW9uLCAyMDExLTEyLTE5IGF0IDEyOjMwICswMDAwLCBSb2dlciBQYXUgTW9ubsOpIHdyb3Rl
Ogo+IFdoYXQncyBzdHJhbmdlIGlzIHRoYXQgbGlidmhkICh3aGljaCB1c2VzIGljb252KSBjb21w
aWxlcyBhbmQgbGlua3MKPiBmaW5lLAoKbGlidmhkIG5lZWRzIC1saWNvbnYgYnV0IGl0IHdpbGwg
Y29tcGlsZSBhbmQgbGluayB3aXRob3V0IGl0IGZpbmUuIEl0IGlzCm9ubHkgd2hlbiB5b3UgdHJ5
IHRvIGxpbmsgc29tZXRoaW5nIGFnYWluc3QgdGhhdCBsaWJyYXJ5IHRoYXQgdGhlCnByb2JsZW0g
d2lsbCBtYW5pZmVzdCBpdHNlbGYuCgo+ICBidXQgdmhkLXV0aWwgdGhhdCB1c2VzIGxpYnZoZCBj
b21wbGFpbnMgYWJvdXQgdW5kZWZpbmVkCj4gcmVmZXJlbmNlcyB0byBpY29udiwgd2hlbiB2aGQt
dXRpbCBkb2Vzbid0IHVzZSBpY29udi4KClJpZ2h0LgoKSWFuLgoKCl9fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVu
LWRldmVsQGxpc3RzLnhlbnNvdXJjZS5jb20KaHR0cDovL2xpc3RzLnhlbnNvdXJjZS5jb20veGVu
LWRldmVsCg==

From xen-devel-bounces@lists.xensource.com Mon Dec 19 13:27:36 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 13: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.xensource.com>)
	id 1RcdEx-00064f-Uy; Mon, 19 Dec 2011 13:26:51 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RcdEw-00064a-VT
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 13:26:51 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1324301204!6122866!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzA0OQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29568 invoked from network); 19 Dec 2011 13:26:44 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Dec 2011 13:26:44 -0000
X-IronPort-AV: E=Sophos;i="4.71,376,1320624000"; 
   d="scan'208";a="9555241"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Dec 2011 13:26:44 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 19 Dec 2011 13:26:44 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau =?ISO-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
Date: Mon, 19 Dec 2011 13:26:43 +0000
In-Reply-To: <CAPLaKK5gYZ+KDsJW4+FSkP=nqDJmaO3W72pfkbg8m25fYu+_1Q@mail.gmail.com>
References: <patchbomb.1324212500@alpine.localdomain>
	<c0d5aa328f1ab24aad58.1324212503@alpine.localdomain>
	<CA+T2pCE_L0Gfyb0xu4=bd-yCAz=+Z_4Ugyd-EoO4m=+jz5MPGA@mail.gmail.com>
	<CAPLaKK5gYZ+KDsJW4+FSkP=nqDJmaO3W72pfkbg8m25fYu+_1Q@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1324301203.9236.40.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: William Pitcock <nenolod@dereferenced.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 3 of 5] blktap2: fix vhd compilation under
 uclibc
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gTW9uLCAyMDExLTEyLTE5IGF0IDEyOjMwICswMDAwLCBSb2dlciBQYXUgTW9ubsOpIHdyb3Rl
Ogo+IFdoYXQncyBzdHJhbmdlIGlzIHRoYXQgbGlidmhkICh3aGljaCB1c2VzIGljb252KSBjb21w
aWxlcyBhbmQgbGlua3MKPiBmaW5lLAoKbGlidmhkIG5lZWRzIC1saWNvbnYgYnV0IGl0IHdpbGwg
Y29tcGlsZSBhbmQgbGluayB3aXRob3V0IGl0IGZpbmUuIEl0IGlzCm9ubHkgd2hlbiB5b3UgdHJ5
IHRvIGxpbmsgc29tZXRoaW5nIGFnYWluc3QgdGhhdCBsaWJyYXJ5IHRoYXQgdGhlCnByb2JsZW0g
d2lsbCBtYW5pZmVzdCBpdHNlbGYuCgo+ICBidXQgdmhkLXV0aWwgdGhhdCB1c2VzIGxpYnZoZCBj
b21wbGFpbnMgYWJvdXQgdW5kZWZpbmVkCj4gcmVmZXJlbmNlcyB0byBpY29udiwgd2hlbiB2aGQt
dXRpbCBkb2Vzbid0IHVzZSBpY29udi4KClJpZ2h0LgoKSWFuLgoKCl9fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVu
LWRldmVsQGxpc3RzLnhlbnNvdXJjZS5jb20KaHR0cDovL2xpc3RzLnhlbnNvdXJjZS5jb20veGVu
LWRldmVsCg==

From xen-devel-bounces@lists.xensource.com Mon Dec 19 13:31:25 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 13:31:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RcdIp-0006FP-KE; Mon, 19 Dec 2011 13:30:51 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RcdIn-0006FC-UV
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 13:30:50 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1324301441!6122476!1
X-Originating-IP: [209.85.210.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20829 invoked from network); 19 Dec 2011 13:30:43 -0000
Received: from mail-pz0-f43.google.com (HELO mail-pz0-f43.google.com)
	(209.85.210.43)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Dec 2011 13:30:43 -0000
Received: by daec6 with SMTP id c6so25338290dae.30
	for <xen-devel@lists.xensource.com>;
	Mon, 19 Dec 2011 05:30:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=s8aDD8E2p2g6+/E8qaI1OGgC0wEh1/muq6Ul+w1bwNc=;
	b=bXLfaN6kpqtt27f/0fsOJis0gdBEKXMekUU4soG/WWCROky3b7yr3DAnt2aUHAK4hH
	g5ti4uVuWuZ/DGDcB15F3CRbAeSg8gbAFISYzszeZ9SvHuYufqR4LabOiaR/3eZKjjOd
	ub6K1TuVk7ZxIuMjUbVNdkrYh0683IwrFxU0U=
MIME-Version: 1.0
Received: by 10.68.72.164 with SMTP id e4mr38231833pbv.95.1324301441219; Mon,
	19 Dec 2011 05:30:41 -0800 (PST)
Received: by 10.142.47.17 with HTTP; Mon, 19 Dec 2011 05:30:41 -0800 (PST)
In-Reply-To: <1324301203.9236.40.camel@zakaz.uk.xensource.com>
References: <patchbomb.1324212500@alpine.localdomain>
	<c0d5aa328f1ab24aad58.1324212503@alpine.localdomain>
	<CA+T2pCE_L0Gfyb0xu4=bd-yCAz=+Z_4Ugyd-EoO4m=+jz5MPGA@mail.gmail.com>
	<CAPLaKK5gYZ+KDsJW4+FSkP=nqDJmaO3W72pfkbg8m25fYu+_1Q@mail.gmail.com>
	<1324301203.9236.40.camel@zakaz.uk.xensource.com>
Date: Mon, 19 Dec 2011 14:30:41 +0100
X-Google-Sender-Auth: oVMJ32firf7353MNpicutA-m2bg
Message-ID: <CAPLaKK6NhoXTiaFWb9aTcuapaqtNVcKo==7=xXP8wf5N66kFUw@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: William Pitcock <nenolod@dereferenced.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 3 of 5] blktap2: fix vhd compilation under
	uclibc
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

MjAxMS8xMi8xOSBJYW4gQ2FtcGJlbGwgPElhbi5DYW1wYmVsbEBjaXRyaXguY29tPjoKPiBPbiBN
b24sIDIwMTEtMTItMTkgYXQgMTI6MzAgKzAwMDAsIFJvZ2VyIFBhdSBNb25uw6kgd3JvdGU6Cj4+
IFdoYXQncyBzdHJhbmdlIGlzIHRoYXQgbGlidmhkICh3aGljaCB1c2VzIGljb252KSBjb21waWxl
cyBhbmQgbGlua3MKPj4gZmluZSwKPgo+IGxpYnZoZCBuZWVkcyAtbGljb252IGJ1dCBpdCB3aWxs
IGNvbXBpbGUgYW5kIGxpbmsgd2l0aG91dCBpdCBmaW5lLiBJdCBpcwo+IG9ubHkgd2hlbiB5b3Ug
dHJ5IHRvIGxpbmsgc29tZXRoaW5nIGFnYWluc3QgdGhhdCBsaWJyYXJ5IHRoYXQgdGhlCj4gcHJv
YmxlbSB3aWxsIG1hbmlmZXN0IGl0c2VsZi4KPgo+PiDCoGJ1dCB2aGQtdXRpbCB0aGF0IHVzZXMg
bGlidmhkIGNvbXBsYWlucyBhYm91dCB1bmRlZmluZWQKPj4gcmVmZXJlbmNlcyB0byBpY29udiwg
d2hlbiB2aGQtdXRpbCBkb2Vzbid0IHVzZSBpY29udi4KPgo+IFJpZ2h0Lgo+Cj4gSWFuLgoKSSBo
YXZlIGEgZXhwcmVzc2lvbiB0aGF0IGNoZWNrcyBmb3IgbGliaWNvbnYsIGJ1dCBpdCB3aWxsIG9u
bHkgZGV0ZWN0Cml0IGlmIGxkY29uZmlnIGlzIHByZXNlbnQsIGlmIHRoZSBzeXN0ZW0gZG9lc24n
dCBoYXZlIGxkY29uZmlnCihOZXRCU0QpLCBsaWJpY29udiB3aWxsIG5vdCBiZSBkZXRlY3RlZCBl
dmVuIGlmIGl0IGlzIHByZXNlbnQ6Cgp3aGljaCBsZGNvbmZpZyAyPiYxID4vZGV2L251bGwgJiYg
KGxkY29uZmlnIC1wIHwgZ3JlcCAtcSBsaWJpY29udiAmJgplY2hvICd5JyB8fCBlY2hvICduJykg
fHwgZWNobyAnbicKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbnNvdXJjZS5jb20K
aHR0cDovL2xpc3RzLnhlbnNvdXJjZS5jb20veGVuLWRldmVsCg==

From xen-devel-bounces@lists.xensource.com Mon Dec 19 13:31:25 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 13:31:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RcdIp-0006FP-KE; Mon, 19 Dec 2011 13:30:51 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RcdIn-0006FC-UV
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 13:30:50 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1324301441!6122476!1
X-Originating-IP: [209.85.210.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20829 invoked from network); 19 Dec 2011 13:30:43 -0000
Received: from mail-pz0-f43.google.com (HELO mail-pz0-f43.google.com)
	(209.85.210.43)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Dec 2011 13:30:43 -0000
Received: by daec6 with SMTP id c6so25338290dae.30
	for <xen-devel@lists.xensource.com>;
	Mon, 19 Dec 2011 05:30:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=s8aDD8E2p2g6+/E8qaI1OGgC0wEh1/muq6Ul+w1bwNc=;
	b=bXLfaN6kpqtt27f/0fsOJis0gdBEKXMekUU4soG/WWCROky3b7yr3DAnt2aUHAK4hH
	g5ti4uVuWuZ/DGDcB15F3CRbAeSg8gbAFISYzszeZ9SvHuYufqR4LabOiaR/3eZKjjOd
	ub6K1TuVk7ZxIuMjUbVNdkrYh0683IwrFxU0U=
MIME-Version: 1.0
Received: by 10.68.72.164 with SMTP id e4mr38231833pbv.95.1324301441219; Mon,
	19 Dec 2011 05:30:41 -0800 (PST)
Received: by 10.142.47.17 with HTTP; Mon, 19 Dec 2011 05:30:41 -0800 (PST)
In-Reply-To: <1324301203.9236.40.camel@zakaz.uk.xensource.com>
References: <patchbomb.1324212500@alpine.localdomain>
	<c0d5aa328f1ab24aad58.1324212503@alpine.localdomain>
	<CA+T2pCE_L0Gfyb0xu4=bd-yCAz=+Z_4Ugyd-EoO4m=+jz5MPGA@mail.gmail.com>
	<CAPLaKK5gYZ+KDsJW4+FSkP=nqDJmaO3W72pfkbg8m25fYu+_1Q@mail.gmail.com>
	<1324301203.9236.40.camel@zakaz.uk.xensource.com>
Date: Mon, 19 Dec 2011 14:30:41 +0100
X-Google-Sender-Auth: oVMJ32firf7353MNpicutA-m2bg
Message-ID: <CAPLaKK6NhoXTiaFWb9aTcuapaqtNVcKo==7=xXP8wf5N66kFUw@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: William Pitcock <nenolod@dereferenced.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 3 of 5] blktap2: fix vhd compilation under
	uclibc
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

MjAxMS8xMi8xOSBJYW4gQ2FtcGJlbGwgPElhbi5DYW1wYmVsbEBjaXRyaXguY29tPjoKPiBPbiBN
b24sIDIwMTEtMTItMTkgYXQgMTI6MzAgKzAwMDAsIFJvZ2VyIFBhdSBNb25uw6kgd3JvdGU6Cj4+
IFdoYXQncyBzdHJhbmdlIGlzIHRoYXQgbGlidmhkICh3aGljaCB1c2VzIGljb252KSBjb21waWxl
cyBhbmQgbGlua3MKPj4gZmluZSwKPgo+IGxpYnZoZCBuZWVkcyAtbGljb252IGJ1dCBpdCB3aWxs
IGNvbXBpbGUgYW5kIGxpbmsgd2l0aG91dCBpdCBmaW5lLiBJdCBpcwo+IG9ubHkgd2hlbiB5b3Ug
dHJ5IHRvIGxpbmsgc29tZXRoaW5nIGFnYWluc3QgdGhhdCBsaWJyYXJ5IHRoYXQgdGhlCj4gcHJv
YmxlbSB3aWxsIG1hbmlmZXN0IGl0c2VsZi4KPgo+PiDCoGJ1dCB2aGQtdXRpbCB0aGF0IHVzZXMg
bGlidmhkIGNvbXBsYWlucyBhYm91dCB1bmRlZmluZWQKPj4gcmVmZXJlbmNlcyB0byBpY29udiwg
d2hlbiB2aGQtdXRpbCBkb2Vzbid0IHVzZSBpY29udi4KPgo+IFJpZ2h0Lgo+Cj4gSWFuLgoKSSBo
YXZlIGEgZXhwcmVzc2lvbiB0aGF0IGNoZWNrcyBmb3IgbGliaWNvbnYsIGJ1dCBpdCB3aWxsIG9u
bHkgZGV0ZWN0Cml0IGlmIGxkY29uZmlnIGlzIHByZXNlbnQsIGlmIHRoZSBzeXN0ZW0gZG9lc24n
dCBoYXZlIGxkY29uZmlnCihOZXRCU0QpLCBsaWJpY29udiB3aWxsIG5vdCBiZSBkZXRlY3RlZCBl
dmVuIGlmIGl0IGlzIHByZXNlbnQ6Cgp3aGljaCBsZGNvbmZpZyAyPiYxID4vZGV2L251bGwgJiYg
KGxkY29uZmlnIC1wIHwgZ3JlcCAtcSBsaWJpY29udiAmJgplY2hvICd5JyB8fCBlY2hvICduJykg
fHwgZWNobyAnbicKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbnNvdXJjZS5jb20K
aHR0cDovL2xpc3RzLnhlbnNvdXJjZS5jb20veGVuLWRldmVsCg==

From xen-devel-bounces@lists.xensource.com Mon Dec 19 13:43:39 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 13: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.xensource.com>)
	id 1RcdUk-0006U2-T4; Mon, 19 Dec 2011 13:43:10 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RcdUi-0006Tx-Te
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 13:43:09 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1324302182!6125576!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzA0OQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24255 invoked from network); 19 Dec 2011 13:43:02 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Dec 2011 13:43:02 -0000
X-IronPort-AV: E=Sophos;i="4.71,376,1320624000"; 
   d="scan'208";a="9555725"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Dec 2011 13:43:02 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 19 Dec 2011 13:43:02 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau =?ISO-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
Date: Mon, 19 Dec 2011 13:43:02 +0000
In-Reply-To: <CAPLaKK6NhoXTiaFWb9aTcuapaqtNVcKo==7=xXP8wf5N66kFUw@mail.gmail.com>
References: <patchbomb.1324212500@alpine.localdomain>
	<c0d5aa328f1ab24aad58.1324212503@alpine.localdomain>
	<CA+T2pCE_L0Gfyb0xu4=bd-yCAz=+Z_4Ugyd-EoO4m=+jz5MPGA@mail.gmail.com>
	<CAPLaKK5gYZ+KDsJW4+FSkP=nqDJmaO3W72pfkbg8m25fYu+_1Q@mail.gmail.com>
	<1324301203.9236.40.camel@zakaz.uk.xensource.com>
	<CAPLaKK6NhoXTiaFWb9aTcuapaqtNVcKo==7=xXP8wf5N66kFUw@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1324302182.9236.51.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: William Pitcock <nenolod@dereferenced.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 3 of 5] blktap2: fix vhd compilation under
 uclibc
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gTW9uLCAyMDExLTEyLTE5IGF0IDEzOjMwICswMDAwLCBSb2dlciBQYXUgTW9ubsOpIHdyb3Rl
Ogo+IDIwMTEvMTIvMTkgSWFuIENhbXBiZWxsIDxJYW4uQ2FtcGJlbGxAY2l0cml4LmNvbT46Cj4g
PiBPbiBNb24sIDIwMTEtMTItMTkgYXQgMTI6MzAgKzAwMDAsIFJvZ2VyIFBhdSBNb25uw6kgd3Jv
dGU6Cj4gPj4gV2hhdCdzIHN0cmFuZ2UgaXMgdGhhdCBsaWJ2aGQgKHdoaWNoIHVzZXMgaWNvbnYp
IGNvbXBpbGVzIGFuZCBsaW5rcwo+ID4+IGZpbmUsCj4gPgo+ID4gbGlidmhkIG5lZWRzIC1saWNv
bnYgYnV0IGl0IHdpbGwgY29tcGlsZSBhbmQgbGluayB3aXRob3V0IGl0IGZpbmUuIEl0IGlzCj4g
PiBvbmx5IHdoZW4geW91IHRyeSB0byBsaW5rIHNvbWV0aGluZyBhZ2FpbnN0IHRoYXQgbGlicmFy
eSB0aGF0IHRoZQo+ID4gcHJvYmxlbSB3aWxsIG1hbmlmZXN0IGl0c2VsZi4KPiA+Cj4gPj4gIGJ1
dCB2aGQtdXRpbCB0aGF0IHVzZXMgbGlidmhkIGNvbXBsYWlucyBhYm91dCB1bmRlZmluZWQKPiA+
PiByZWZlcmVuY2VzIHRvIGljb252LCB3aGVuIHZoZC11dGlsIGRvZXNuJ3QgdXNlIGljb252Lgo+
ID4KPiA+IFJpZ2h0Lgo+ID4KPiA+IElhbi4KPiAKPiBJIGhhdmUgYSBleHByZXNzaW9uIHRoYXQg
Y2hlY2tzIGZvciBsaWJpY29udiwgYnV0IGl0IHdpbGwgb25seSBkZXRlY3QKPiBpdCBpZiBsZGNv
bmZpZyBpcyBwcmVzZW50LCBpZiB0aGUgc3lzdGVtIGRvZXNuJ3QgaGF2ZSBsZGNvbmZpZwo+IChO
ZXRCU0QpLCBsaWJpY29udiB3aWxsIG5vdCBiZSBkZXRlY3RlZCBldmVuIGlmIGl0IGlzIHByZXNl
bnQ6Cj4gCj4gd2hpY2ggbGRjb25maWcgMj4mMSA+L2Rldi9udWxsICYmIChsZGNvbmZpZyAtcCB8
IGdyZXAgLXEgbGliaWNvbnYgJiYKPiBlY2hvICd5JyB8fCBlY2hvICduJykgfHwgZWNobyAnbicK
ClVyZ2gsIHN1cmVseSB0aGVyZSdzIGEgYmV0dGVyIHdheSEKClBlcmhhcHMgZ3JlcHBpbmcgZm9y
IExJQklDT05WX1BMVUcgb3IgbGliaWNvbnZfb3BlbiBvciBzb21ldGhpbmcgdW5pcXVlCmluIGlj
b252Lmggd291bGQgYmUgYmV0dGVyPwoKQlRXIGRpZCB5b3UgdHJ5IGRlZmluaW5nIExJQklDT05W
X1BMVUc/CgpJYW4uCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuc291cmNlLmNv
bQpodHRwOi8vbGlzdHMueGVuc291cmNlLmNvbS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Mon Dec 19 13:43:39 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 13: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.xensource.com>)
	id 1RcdUk-0006U2-T4; Mon, 19 Dec 2011 13:43:10 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RcdUi-0006Tx-Te
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 13:43:09 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1324302182!6125576!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzA0OQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24255 invoked from network); 19 Dec 2011 13:43:02 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Dec 2011 13:43:02 -0000
X-IronPort-AV: E=Sophos;i="4.71,376,1320624000"; 
   d="scan'208";a="9555725"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Dec 2011 13:43:02 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 19 Dec 2011 13:43:02 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau =?ISO-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
Date: Mon, 19 Dec 2011 13:43:02 +0000
In-Reply-To: <CAPLaKK6NhoXTiaFWb9aTcuapaqtNVcKo==7=xXP8wf5N66kFUw@mail.gmail.com>
References: <patchbomb.1324212500@alpine.localdomain>
	<c0d5aa328f1ab24aad58.1324212503@alpine.localdomain>
	<CA+T2pCE_L0Gfyb0xu4=bd-yCAz=+Z_4Ugyd-EoO4m=+jz5MPGA@mail.gmail.com>
	<CAPLaKK5gYZ+KDsJW4+FSkP=nqDJmaO3W72pfkbg8m25fYu+_1Q@mail.gmail.com>
	<1324301203.9236.40.camel@zakaz.uk.xensource.com>
	<CAPLaKK6NhoXTiaFWb9aTcuapaqtNVcKo==7=xXP8wf5N66kFUw@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1324302182.9236.51.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: William Pitcock <nenolod@dereferenced.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 3 of 5] blktap2: fix vhd compilation under
 uclibc
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gTW9uLCAyMDExLTEyLTE5IGF0IDEzOjMwICswMDAwLCBSb2dlciBQYXUgTW9ubsOpIHdyb3Rl
Ogo+IDIwMTEvMTIvMTkgSWFuIENhbXBiZWxsIDxJYW4uQ2FtcGJlbGxAY2l0cml4LmNvbT46Cj4g
PiBPbiBNb24sIDIwMTEtMTItMTkgYXQgMTI6MzAgKzAwMDAsIFJvZ2VyIFBhdSBNb25uw6kgd3Jv
dGU6Cj4gPj4gV2hhdCdzIHN0cmFuZ2UgaXMgdGhhdCBsaWJ2aGQgKHdoaWNoIHVzZXMgaWNvbnYp
IGNvbXBpbGVzIGFuZCBsaW5rcwo+ID4+IGZpbmUsCj4gPgo+ID4gbGlidmhkIG5lZWRzIC1saWNv
bnYgYnV0IGl0IHdpbGwgY29tcGlsZSBhbmQgbGluayB3aXRob3V0IGl0IGZpbmUuIEl0IGlzCj4g
PiBvbmx5IHdoZW4geW91IHRyeSB0byBsaW5rIHNvbWV0aGluZyBhZ2FpbnN0IHRoYXQgbGlicmFy
eSB0aGF0IHRoZQo+ID4gcHJvYmxlbSB3aWxsIG1hbmlmZXN0IGl0c2VsZi4KPiA+Cj4gPj4gIGJ1
dCB2aGQtdXRpbCB0aGF0IHVzZXMgbGlidmhkIGNvbXBsYWlucyBhYm91dCB1bmRlZmluZWQKPiA+
PiByZWZlcmVuY2VzIHRvIGljb252LCB3aGVuIHZoZC11dGlsIGRvZXNuJ3QgdXNlIGljb252Lgo+
ID4KPiA+IFJpZ2h0Lgo+ID4KPiA+IElhbi4KPiAKPiBJIGhhdmUgYSBleHByZXNzaW9uIHRoYXQg
Y2hlY2tzIGZvciBsaWJpY29udiwgYnV0IGl0IHdpbGwgb25seSBkZXRlY3QKPiBpdCBpZiBsZGNv
bmZpZyBpcyBwcmVzZW50LCBpZiB0aGUgc3lzdGVtIGRvZXNuJ3QgaGF2ZSBsZGNvbmZpZwo+IChO
ZXRCU0QpLCBsaWJpY29udiB3aWxsIG5vdCBiZSBkZXRlY3RlZCBldmVuIGlmIGl0IGlzIHByZXNl
bnQ6Cj4gCj4gd2hpY2ggbGRjb25maWcgMj4mMSA+L2Rldi9udWxsICYmIChsZGNvbmZpZyAtcCB8
IGdyZXAgLXEgbGliaWNvbnYgJiYKPiBlY2hvICd5JyB8fCBlY2hvICduJykgfHwgZWNobyAnbicK
ClVyZ2gsIHN1cmVseSB0aGVyZSdzIGEgYmV0dGVyIHdheSEKClBlcmhhcHMgZ3JlcHBpbmcgZm9y
IExJQklDT05WX1BMVUcgb3IgbGliaWNvbnZfb3BlbiBvciBzb21ldGhpbmcgdW5pcXVlCmluIGlj
b252Lmggd291bGQgYmUgYmV0dGVyPwoKQlRXIGRpZCB5b3UgdHJ5IGRlZmluaW5nIExJQklDT05W
X1BMVUc/CgpJYW4uCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuc291cmNlLmNv
bQpodHRwOi8vbGlzdHMueGVuc291cmNlLmNvbS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Mon Dec 19 13:57:20 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 13:57:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rcdhx-0006id-QG; Mon, 19 Dec 2011 13:56:49 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <hui.lv@intel.com>) id 1Rcdhw-0006iY-M8
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 13:56:48 +0000
X-Env-Sender: hui.lv@intel.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1324302966!51213905!1
X-Originating-IP: [143.182.124.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjEyMzM1\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9301 invoked from network); 19 Dec 2011 13:56:07 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-6.tower-27.messagelabs.com with SMTP;
	19 Dec 2011 13:56:07 -0000
Received: from azsmga002.ch.intel.com ([10.2.17.35])
	by azsmga101.ch.intel.com with ESMTP; 19 Dec 2011 05:56:46 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="48587733"
Received: from pgsmsx601.gar.corp.intel.com ([10.221.43.69])
	by AZSMGA002.ch.intel.com with ESMTP; 19 Dec 2011 05:56:45 -0800
Received: from pgsmsx151.gar.corp.intel.com (172.30.236.41) by
	pgsmsx601.gar.corp.intel.com (10.221.43.69) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Mon, 19 Dec 2011 21:56:45 +0800
Received: from shsmsx602.ccr.corp.intel.com (10.239.4.104) by
	PGSMSX151.gar.corp.intel.com (172.30.236.41) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Mon, 19 Dec 2011 21:56:44 +0800
Received: from shsmsx502.ccr.corp.intel.com ([10.239.4.96]) by
	SHSMSX602.ccr.corp.intel.com ([10.239.4.104]) with mapi;
	Mon, 19 Dec 2011 21:56:43 +0800
From: "Lv, Hui" <hui.lv@intel.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Mon, 19 Dec 2011 21:56:42 +0800
Thread-Topic: [Xen-devel] [PATCH v2] xen/credit scheduler; Use delay to
	control scheduling frequency
Thread-Index: Acy+J7hCdCE1iUccTyq4M5VbDWzbpQAK6kOw
Message-ID: <C10D3FB0CD45994C8A51FEC1227CE22F39412A9701@shsmsx502.ccr.corp.intel.com>
References: <C10D3FB0CD45994C8A51FEC1227CE22F37CC284376@shsmsx502.ccr.corp.intel.com>
	<4EEF02E20200007800068C60@nat28.tlf.novell.com>
In-Reply-To: <4EEF02E20200007800068C60@nat28.tlf.novell.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	"'xen-devel@lists.xensource.com'" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH v2] xen/credit scheduler;
 Use delay to control scheduling frequency
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> > +    /* If we have schedule rate limiting enabled, check to see
> > +     * how long we've run for. */
> > +    if ( sched_ratelimit_us
> > +         && !tasklet_work_scheduled
> 
> How about making the checking order match the description above (which
> might also be slightly faster given that tasklet_work_scheduled is a function
> parameter [in a register or written recently], and [given the default value
> you're picking] you expect sched_ratelimit_us to be non-zero generally)?
> 
Thanks, agree this.

> > +         && vcpu_runnable(current)
> > +         && !is_idle_vcpu(current)
> > +         && runtime < MICROSECS(sched_ratelimit_us) )
> > +    {
> > +        snext = scurr;
> > +        snext->start_time += now;
> > +        perfc_incr(delay_ms);
> > +        tslice = MICROSECS(sched_ratelimit_us);
> 
> So if there happens to be a VM with
> 
> MILLISECS(prv->tslice_ms) < MICROSECS(sched_ratelimit_us)
> 
> it'd get *more* time than allowed/intended through this mechanism.

First, it does not make sense to set prv->tslice_ms < sched_ratelimit_us. If people really need an extreme smaller time slice(1ms, for example), remember to set sched_ratelimit_us smaller than prv->tslice_ms or zero.
If people forgot to do so, I think sched_ratelimit_us is higher priority to be considered (instead of minimum of both), although this is not the "right"xe configuration.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 13:57:20 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 13:57:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rcdhx-0006id-QG; Mon, 19 Dec 2011 13:56:49 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <hui.lv@intel.com>) id 1Rcdhw-0006iY-M8
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 13:56:48 +0000
X-Env-Sender: hui.lv@intel.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1324302966!51213905!1
X-Originating-IP: [143.182.124.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjEyMzM1\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9301 invoked from network); 19 Dec 2011 13:56:07 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-6.tower-27.messagelabs.com with SMTP;
	19 Dec 2011 13:56:07 -0000
Received: from azsmga002.ch.intel.com ([10.2.17.35])
	by azsmga101.ch.intel.com with ESMTP; 19 Dec 2011 05:56:46 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="48587733"
Received: from pgsmsx601.gar.corp.intel.com ([10.221.43.69])
	by AZSMGA002.ch.intel.com with ESMTP; 19 Dec 2011 05:56:45 -0800
Received: from pgsmsx151.gar.corp.intel.com (172.30.236.41) by
	pgsmsx601.gar.corp.intel.com (10.221.43.69) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Mon, 19 Dec 2011 21:56:45 +0800
Received: from shsmsx602.ccr.corp.intel.com (10.239.4.104) by
	PGSMSX151.gar.corp.intel.com (172.30.236.41) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Mon, 19 Dec 2011 21:56:44 +0800
Received: from shsmsx502.ccr.corp.intel.com ([10.239.4.96]) by
	SHSMSX602.ccr.corp.intel.com ([10.239.4.104]) with mapi;
	Mon, 19 Dec 2011 21:56:43 +0800
From: "Lv, Hui" <hui.lv@intel.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Mon, 19 Dec 2011 21:56:42 +0800
Thread-Topic: [Xen-devel] [PATCH v2] xen/credit scheduler; Use delay to
	control scheduling frequency
Thread-Index: Acy+J7hCdCE1iUccTyq4M5VbDWzbpQAK6kOw
Message-ID: <C10D3FB0CD45994C8A51FEC1227CE22F39412A9701@shsmsx502.ccr.corp.intel.com>
References: <C10D3FB0CD45994C8A51FEC1227CE22F37CC284376@shsmsx502.ccr.corp.intel.com>
	<4EEF02E20200007800068C60@nat28.tlf.novell.com>
In-Reply-To: <4EEF02E20200007800068C60@nat28.tlf.novell.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	"'xen-devel@lists.xensource.com'" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH v2] xen/credit scheduler;
 Use delay to control scheduling frequency
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> > +    /* If we have schedule rate limiting enabled, check to see
> > +     * how long we've run for. */
> > +    if ( sched_ratelimit_us
> > +         && !tasklet_work_scheduled
> 
> How about making the checking order match the description above (which
> might also be slightly faster given that tasklet_work_scheduled is a function
> parameter [in a register or written recently], and [given the default value
> you're picking] you expect sched_ratelimit_us to be non-zero generally)?
> 
Thanks, agree this.

> > +         && vcpu_runnable(current)
> > +         && !is_idle_vcpu(current)
> > +         && runtime < MICROSECS(sched_ratelimit_us) )
> > +    {
> > +        snext = scurr;
> > +        snext->start_time += now;
> > +        perfc_incr(delay_ms);
> > +        tslice = MICROSECS(sched_ratelimit_us);
> 
> So if there happens to be a VM with
> 
> MILLISECS(prv->tslice_ms) < MICROSECS(sched_ratelimit_us)
> 
> it'd get *more* time than allowed/intended through this mechanism.

First, it does not make sense to set prv->tslice_ms < sched_ratelimit_us. If people really need an extreme smaller time slice(1ms, for example), remember to set sched_ratelimit_us smaller than prv->tslice_ms or zero.
If people forgot to do so, I think sched_ratelimit_us is higher priority to be considered (instead of minimum of both), although this is not the "right"xe configuration.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 14:00:05 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 14: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.xensource.com>)
	id 1Rcdkl-0006os-DJ; Mon, 19 Dec 2011 13:59:43 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1Rcdkj-0006oL-Kf
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 13:59:41 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1324303174!7922338!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17587 invoked from network); 19 Dec 2011 13:59:35 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Dec 2011 13:59:35 -0000
Received: by iagw33 with SMTP id w33so32199882iag.30
	for <xen-devel@lists.xensource.com>;
	Mon, 19 Dec 2011 05:59:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=ZRswKxMoCpdS6AE292u4AyuEwpCwycrGWKvxxQ56GsE=;
	b=FKG6sQ+Ls3muNA8gBXkdf8+hRrAnxFA9RT6vhdFoDOrbwe5yudjtXHYc6yDR2dYyDv
	lUeJknA6vOQKMLdPpKDUuOTR/wDLtLzaUEDRMHef3SyOuzfXk7NkbyzLT2bNZiH8K8TS
	wWwzaCFG7qfQajTyukC4lGvEL9QLwGYpOP+k4=
MIME-Version: 1.0
Received: by 10.50.41.130 with SMTP id f2mr27020612igl.75.1324303173837; Mon,
	19 Dec 2011 05:59:33 -0800 (PST)
Received: by 10.231.146.21 with HTTP; Mon, 19 Dec 2011 05:59:33 -0800 (PST)
In-Reply-To: <4EEF36A60200007800068D43@nat28.tlf.novell.com>
References: <C10D3FB0CD45994C8A51FEC1227CE22F37CC284376@shsmsx502.ccr.corp.intel.com>
	<4EEF02E20200007800068C60@nat28.tlf.novell.com>
	<CAFLBxZb3Yc7G4QzEXKdfrVkoz1XGv09zTxCQCC4Dnkr-6M5K5Q@mail.gmail.com>
	<4EEF36A60200007800068D43@nat28.tlf.novell.com>
Date: Mon, 19 Dec 2011 13:59:33 +0000
X-Google-Sender-Auth: 6o6D4f9KxBacwj_hrBt1hRhpfZI
Message-ID: <CAFLBxZahyAJ5Y7+eGGCkoOKZZGQ4rYwdZutyjAMH2CcQhDkcZw@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: Kevin Tian <kevin.tian@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"keir@xen.org" <keir@xen.org>, Eddie Dong <eddie.dong@intel.com>,
	Hui Lv <hui.lv@intel.com>, Jiangang Duan <jiangang.duan@intel.com>,
	Zhidong Yu <zhidong.yu@intel.com>
Subject: Re: [Xen-devel] [PATCH v2] xen/credit scheduler;
 Use delay to control scheduling frequency
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Dec 19, 2011 at 12:05 PM, Jan Beulich <JBeulich@suse.com> wrote:
>> The way it stands now, the ratelimit value will override the timeslice
>> value. =A0It had to be one way or the other; do you think the timeslice
>> value should be the priority?
>
> The minimum of both should be used, I would think.

What do you mean?  You mean in the assignment above?

That won't have any effect other than increasing interrupts and trips
through the scheduler.  Suppose the following set of events:
* timeslice is set to 1ms, ratelimit_us to 5000.
* a vcpu V is chosen; it's set to run with 1ms timeout.
* 1ms later, we go through the scheduler; the ratelimit code
determines that it hasn't run for long enough (only 1ms), so choses it
to run again (with a 1ms timeslice)
* Repeat until V has run for 5ms.

So although the timeslice is set to 1ms, and interrupts are happening
after 1ms, the ratelimit is overriding the 1ms of the timeslice and
making it 5ms.  Fundamentally, one of the two parameters must override
the other.  With this patch the way it is now, ratelimit will override
timeslice.  if you want the timeslice to override ratelimit, then
there will have to be more code to make that happen.

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 14:00:05 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 14: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.xensource.com>)
	id 1Rcdkl-0006os-DJ; Mon, 19 Dec 2011 13:59:43 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1Rcdkj-0006oL-Kf
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 13:59:41 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1324303174!7922338!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17587 invoked from network); 19 Dec 2011 13:59:35 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Dec 2011 13:59:35 -0000
Received: by iagw33 with SMTP id w33so32199882iag.30
	for <xen-devel@lists.xensource.com>;
	Mon, 19 Dec 2011 05:59:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=ZRswKxMoCpdS6AE292u4AyuEwpCwycrGWKvxxQ56GsE=;
	b=FKG6sQ+Ls3muNA8gBXkdf8+hRrAnxFA9RT6vhdFoDOrbwe5yudjtXHYc6yDR2dYyDv
	lUeJknA6vOQKMLdPpKDUuOTR/wDLtLzaUEDRMHef3SyOuzfXk7NkbyzLT2bNZiH8K8TS
	wWwzaCFG7qfQajTyukC4lGvEL9QLwGYpOP+k4=
MIME-Version: 1.0
Received: by 10.50.41.130 with SMTP id f2mr27020612igl.75.1324303173837; Mon,
	19 Dec 2011 05:59:33 -0800 (PST)
Received: by 10.231.146.21 with HTTP; Mon, 19 Dec 2011 05:59:33 -0800 (PST)
In-Reply-To: <4EEF36A60200007800068D43@nat28.tlf.novell.com>
References: <C10D3FB0CD45994C8A51FEC1227CE22F37CC284376@shsmsx502.ccr.corp.intel.com>
	<4EEF02E20200007800068C60@nat28.tlf.novell.com>
	<CAFLBxZb3Yc7G4QzEXKdfrVkoz1XGv09zTxCQCC4Dnkr-6M5K5Q@mail.gmail.com>
	<4EEF36A60200007800068D43@nat28.tlf.novell.com>
Date: Mon, 19 Dec 2011 13:59:33 +0000
X-Google-Sender-Auth: 6o6D4f9KxBacwj_hrBt1hRhpfZI
Message-ID: <CAFLBxZahyAJ5Y7+eGGCkoOKZZGQ4rYwdZutyjAMH2CcQhDkcZw@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: Kevin Tian <kevin.tian@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"keir@xen.org" <keir@xen.org>, Eddie Dong <eddie.dong@intel.com>,
	Hui Lv <hui.lv@intel.com>, Jiangang Duan <jiangang.duan@intel.com>,
	Zhidong Yu <zhidong.yu@intel.com>
Subject: Re: [Xen-devel] [PATCH v2] xen/credit scheduler;
 Use delay to control scheduling frequency
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Dec 19, 2011 at 12:05 PM, Jan Beulich <JBeulich@suse.com> wrote:
>> The way it stands now, the ratelimit value will override the timeslice
>> value. =A0It had to be one way or the other; do you think the timeslice
>> value should be the priority?
>
> The minimum of both should be used, I would think.

What do you mean?  You mean in the assignment above?

That won't have any effect other than increasing interrupts and trips
through the scheduler.  Suppose the following set of events:
* timeslice is set to 1ms, ratelimit_us to 5000.
* a vcpu V is chosen; it's set to run with 1ms timeout.
* 1ms later, we go through the scheduler; the ratelimit code
determines that it hasn't run for long enough (only 1ms), so choses it
to run again (with a 1ms timeslice)
* Repeat until V has run for 5ms.

So although the timeslice is set to 1ms, and interrupts are happening
after 1ms, the ratelimit is overriding the 1ms of the timeslice and
making it 5ms.  Fundamentally, one of the two parameters must override
the other.  With this patch the way it is now, ratelimit will override
timeslice.  if you want the timeslice to override ratelimit, then
there will have to be more code to make that happen.

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 14:14:26 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 14:14:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rcdyk-0007DF-Nm; Mon, 19 Dec 2011 14:14:10 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <avi@redhat.com>) id 1Rcdyk-0007Bs-6G
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 14:14:10 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1324304043!7791163!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDY0OTI=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 751 invoked from network); 19 Dec 2011 14:14:03 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-7.tower-182.messagelabs.com with SMTP;
	19 Dec 2011 14:14:03 -0000
Received: from int-mx01.intmail.prod.int.phx2.redhat.com
	(int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id pBJEE1R0024932
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 19 Dec 2011 09:14:01 -0500
Received: from cleopatra.tlv.redhat.com (cleopatra.tlv.redhat.com
	[10.35.255.11])
	by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP
	id pBJEE0N3009673; Mon, 19 Dec 2011 09:14:01 -0500
Received: from s01.tlv.redhat.com (s01.tlv.redhat.com [10.35.255.8])
	by cleopatra.tlv.redhat.com (Postfix) with ESMTP id 8E83D250BA1;
	Mon, 19 Dec 2011 16:13:54 +0200 (IST)
From: Avi Kivity <avi@redhat.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	qemu-devel@nongnu.org, "Michael S. Tsirkin" <mst@redhat.com>
Date: Mon, 19 Dec 2011 16:13:23 +0200
Message-Id: <1324304024-11220-3-git-send-email-avi@redhat.com>
In-Reply-To: <1324304024-11220-1-git-send-email-avi@redhat.com>
References: <1324304024-11220-1-git-send-email-avi@redhat.com>
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.11
Cc: xen-devel@lists.xensource.com, kvm@vger.kernel.org
Subject: [Xen-devel] [PATCH 02/23] sysbus: add sysbus_address_space()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Given a bus device, retrieves the memory address space for its bus.

Signed-off-by: Avi Kivity <avi@redhat.com>
---
 hw/sysbus.c |    5 +++++
 hw/sysbus.h |    1 +
 2 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/hw/sysbus.c b/hw/sysbus.c
index b315a8c..492a7c6 100644
--- a/hw/sysbus.c
+++ b/hw/sysbus.c
@@ -277,3 +277,8 @@ void sysbus_del_io(SysBusDevice *dev, MemoryRegion *mem)
 {
     memory_region_del_subregion(get_system_io(), mem);
 }
+
+MemoryRegion *sysbus_address_space(SysBusDevice *dev)
+{
+    return get_system_memory();
+}
diff --git a/hw/sysbus.h b/hw/sysbus.h
index 9bac582..7cecf98 100644
--- a/hw/sysbus.h
+++ b/hw/sysbus.h
@@ -62,6 +62,7 @@ void sysbus_del_memory(SysBusDevice *dev, MemoryRegion *mem);
 void sysbus_add_io(SysBusDevice *dev, target_phys_addr_t addr,
                    MemoryRegion *mem);
 void sysbus_del_io(SysBusDevice *dev, MemoryRegion *mem);
+MemoryRegion *sysbus_address_space(SysBusDevice *dev);
 
 /* Legacy helper function for creating devices.  */
 DeviceState *sysbus_create_varargs(const char *name,
-- 
1.7.7.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 14:14:26 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 14:14:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rcdyp-0007GX-EV; Mon, 19 Dec 2011 14:14:15 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <avi@redhat.com>) id 1Rcdym-0007C5-LL
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 14:14:12 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1324304045!6066911!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDY0OTI=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14304 invoked from network); 19 Dec 2011 14:14:06 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-3.tower-174.messagelabs.com with SMTP;
	19 Dec 2011 14:14:06 -0000
Received: from int-mx09.intmail.prod.int.phx2.redhat.com
	(int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id pBJEE4Df004323
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 19 Dec 2011 09:14:04 -0500
Received: from cleopatra.tlv.redhat.com (cleopatra.tlv.redhat.com
	[10.35.255.11])
	by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id pBJEE0hI006981; Mon, 19 Dec 2011 09:14:03 -0500
Received: from s01.tlv.redhat.com (s01.tlv.redhat.com [10.35.255.8])
	by cleopatra.tlv.redhat.com (Postfix) with ESMTP id B8FF3250BAF;
	Mon, 19 Dec 2011 16:13:54 +0200 (IST)
From: Avi Kivity <avi@redhat.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	qemu-devel@nongnu.org, "Michael S. Tsirkin" <mst@redhat.com>
Date: Mon, 19 Dec 2011 16:13:37 +0200
Message-Id: <1324304024-11220-17-git-send-email-avi@redhat.com>
In-Reply-To: <1324304024-11220-1-git-send-email-avi@redhat.com>
References: <1324304024-11220-1-git-send-email-avi@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
Cc: xen-devel@lists.xensource.com, kvm@vger.kernel.org
Subject: [Xen-devel] [PATCH 16/23] memory: temporarily add
	memory_region_get_ram_addr()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a layering violation, but needed while the code contains
naked calls to qemu_get_ram_ptr() and the like.

Signed-off-by: Avi Kivity <avi@redhat.com>
---
 memory.c |    6 ++++++
 memory.h |   10 ++++++++++
 2 files changed, 16 insertions(+), 0 deletions(-)

diff --git a/memory.c b/memory.c
index 2dcbf80..41a106a 100644
--- a/memory.c
+++ b/memory.c
@@ -1376,6 +1376,12 @@ void memory_region_del_subregion(MemoryRegion *mr,
     memory_region_update_topology();
 }
 
+ram_addr_t memory_region_get_ram_addr(MemoryRegion *mr)
+{
+    assert(mr->backend_registered);
+    return mr->ram_addr;
+}
+
 static int cmp_flatrange_addr(const void *_addr, const void *_fr)
 {
     const AddrRange *addr = _addr;
diff --git a/memory.h b/memory.h
index b7d39ed..1e44d86 100644
--- a/memory.h
+++ b/memory.h
@@ -557,6 +557,16 @@ void memory_region_add_subregion_overlap(MemoryRegion *mr,
                                          target_phys_addr_t offset,
                                          MemoryRegion *subregion,
                                          unsigned priority);
+
+/**
+ * memory_region_get_ram_addr: Get the ram address associated with a memory
+ *                             region
+ *
+ * DO NOT USE THIS FUCNTION.  This is a temporary workaround while the Xen
+ * code is being reworked.
+ */
+ram_addr_t memory_region_get_ram_addr(MemoryRegion *mr);
+
 /**
  * memory_region_del_subregion: Remove a subregion.
  *
-- 
1.7.7.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 14:14:26 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 14:14:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rcdyj-0007Cs-TX; Mon, 19 Dec 2011 14:14:09 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <avi@redhat.com>) id 1Rcdyi-0007Br-F4
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 14:14:08 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1324304041!6130640!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDY0OTI=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25209 invoked from network); 19 Dec 2011 14:14:02 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-11.tower-174.messagelabs.com with SMTP;
	19 Dec 2011 14:14:02 -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 pBJEDvls024919
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 19 Dec 2011 09:13:57 -0500
Received: from cleopatra.tlv.redhat.com (cleopatra.tlv.redhat.com
	[10.35.255.11])
	by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id pBJEDuMA015662; Mon, 19 Dec 2011 09:13:57 -0500
Received: from s01.tlv.redhat.com (s01.tlv.redhat.com [10.35.255.8])
	by cleopatra.tlv.redhat.com (Postfix) with ESMTP id 7B3E7250B9E;
	Mon, 19 Dec 2011 16:13:52 +0200 (IST)
From: Avi Kivity <avi@redhat.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	qemu-devel@nongnu.org, "Michael S. Tsirkin" <mst@redhat.com>
Date: Mon, 19 Dec 2011 16:13:21 +0200
Message-Id: <1324304024-11220-1-git-send-email-avi@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
Cc: xen-devel@lists.xensource.com, kvm@vger.kernel.org
Subject: [Xen-devel] [PATCH 00/23] Remove cpu_get_physical_page_desc()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

cpu_get_physical_page_desc() exposes the internals of the memory core to
callers; as such it prevents the refactoring planned there.  This patchset
converts all callers memory API equivalents and removes the function.

The conversion leaves a lot of potential for further cleanups; the
MemoryListener API (which replaces CPUPhysMemoryClient) guarantees matched
range_add and range_del calls, so the need to handle splitting is removed.
This is left for later.

Please review and test, especially the vhost and Xen parts, which I only
build tested.

Also available from:

  git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git memory/page_desc

Avi Kivity (23):
  memory: introduce memory_region_find()
  sysbus: add sysbus_address_space()
  memory: add memory_region_is_ram()
  framebuffer: drop use of cpu_get_physical_page_desc()
  memory: add memory_region_is_rom()
  loader: remove calls to cpu_get_physical_page_desc()
  framebuffer: drop use of cpu_physical_sync_dirty_bitmap()
  memory: replace cpu_physical_sync_dirty_bitmap() with a memory API
  memory: add API for observing updates to the physical memory map
  memory: add memory_region_is_logging()
  kvm: switch kvm slots to use host virtual address instead of
    ram_addr_t
  fixup: listener fixes
  kvm: convert to MemoryListener API
  vhost: convert to MemoryListener API
  xen, vga: add API for registering the framebuffer
  memory: temporarily add memory_region_get_ram_addr()
  xen: convert to MemoryListener API
  memory: remove CPUPhysMemoryClient
  kvm: avoid cpu_get_physical_page_desc()
  vhost: avoid cpu_get_physical_page_desc()
  virtio-balloon: avoid cpu_get_physical_page_desc()
  sparc: avoid cpu_get_physical_page_desc()
  Remove cpu_get_physical_page_desc()

 arch_init.c               |    6 +-
 cpu-all.h                 |    9 --
 cpu-common.h              |   24 ------
 exec.c                    |  175 +---------------------------------------
 hw/framebuffer.c          |   32 +++----
 hw/framebuffer.h          |    3 +
 hw/loader.c               |    9 +-
 hw/milkymist-vgafb.c      |    2 +-
 hw/omap_lcdc.c            |    4 +-
 hw/pl110.c                |    2 +-
 hw/pxa2xx_lcd.c           |   10 ++-
 hw/sysbus.c               |    5 +
 hw/sysbus.h               |    1 +
 hw/vga.c                  |    2 +
 hw/vhost.c                |  167 ++++++++++++++++++++++++++++++---------
 hw/vhost.h                |    5 +-
 hw/virtio-balloon.c       |   14 +++-
 hw/xen.h                  |    3 +
 kvm-all.c                 |  151 +++++++++++++++++++++--------------
 kvm.h                     |    4 +-
 memory.c                  |  193 ++++++++++++++++++++++++++++++++++++++++++---
 memory.h                  |  127 +++++++++++++++++++++++++++++
 target-i386/kvm.c         |    7 +-
 target-sparc/mmu_helper.c |    5 +-
 trace-events              |    2 +-
 xen-all.c                 |  143 ++++++++++++++++++++-------------
 xen-stub.c                |    4 +
 27 files changed, 695 insertions(+), 414 deletions(-)

-- 
1.7.7.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 14:14:26 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 14:14:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rcdyp-0007GX-EV; Mon, 19 Dec 2011 14:14:15 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <avi@redhat.com>) id 1Rcdym-0007C5-LL
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 14:14:12 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1324304045!6066911!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDY0OTI=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14304 invoked from network); 19 Dec 2011 14:14:06 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-3.tower-174.messagelabs.com with SMTP;
	19 Dec 2011 14:14:06 -0000
Received: from int-mx09.intmail.prod.int.phx2.redhat.com
	(int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id pBJEE4Df004323
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 19 Dec 2011 09:14:04 -0500
Received: from cleopatra.tlv.redhat.com (cleopatra.tlv.redhat.com
	[10.35.255.11])
	by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id pBJEE0hI006981; Mon, 19 Dec 2011 09:14:03 -0500
Received: from s01.tlv.redhat.com (s01.tlv.redhat.com [10.35.255.8])
	by cleopatra.tlv.redhat.com (Postfix) with ESMTP id B8FF3250BAF;
	Mon, 19 Dec 2011 16:13:54 +0200 (IST)
From: Avi Kivity <avi@redhat.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	qemu-devel@nongnu.org, "Michael S. Tsirkin" <mst@redhat.com>
Date: Mon, 19 Dec 2011 16:13:37 +0200
Message-Id: <1324304024-11220-17-git-send-email-avi@redhat.com>
In-Reply-To: <1324304024-11220-1-git-send-email-avi@redhat.com>
References: <1324304024-11220-1-git-send-email-avi@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
Cc: xen-devel@lists.xensource.com, kvm@vger.kernel.org
Subject: [Xen-devel] [PATCH 16/23] memory: temporarily add
	memory_region_get_ram_addr()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a layering violation, but needed while the code contains
naked calls to qemu_get_ram_ptr() and the like.

Signed-off-by: Avi Kivity <avi@redhat.com>
---
 memory.c |    6 ++++++
 memory.h |   10 ++++++++++
 2 files changed, 16 insertions(+), 0 deletions(-)

diff --git a/memory.c b/memory.c
index 2dcbf80..41a106a 100644
--- a/memory.c
+++ b/memory.c
@@ -1376,6 +1376,12 @@ void memory_region_del_subregion(MemoryRegion *mr,
     memory_region_update_topology();
 }
 
+ram_addr_t memory_region_get_ram_addr(MemoryRegion *mr)
+{
+    assert(mr->backend_registered);
+    return mr->ram_addr;
+}
+
 static int cmp_flatrange_addr(const void *_addr, const void *_fr)
 {
     const AddrRange *addr = _addr;
diff --git a/memory.h b/memory.h
index b7d39ed..1e44d86 100644
--- a/memory.h
+++ b/memory.h
@@ -557,6 +557,16 @@ void memory_region_add_subregion_overlap(MemoryRegion *mr,
                                          target_phys_addr_t offset,
                                          MemoryRegion *subregion,
                                          unsigned priority);
+
+/**
+ * memory_region_get_ram_addr: Get the ram address associated with a memory
+ *                             region
+ *
+ * DO NOT USE THIS FUCNTION.  This is a temporary workaround while the Xen
+ * code is being reworked.
+ */
+ram_addr_t memory_region_get_ram_addr(MemoryRegion *mr);
+
 /**
  * memory_region_del_subregion: Remove a subregion.
  *
-- 
1.7.7.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 14:14:26 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 14:14:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rcdyj-0007Cs-TX; Mon, 19 Dec 2011 14:14:09 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <avi@redhat.com>) id 1Rcdyi-0007Br-F4
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 14:14:08 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1324304041!6130640!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDY0OTI=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25209 invoked from network); 19 Dec 2011 14:14:02 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-11.tower-174.messagelabs.com with SMTP;
	19 Dec 2011 14:14:02 -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 pBJEDvls024919
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 19 Dec 2011 09:13:57 -0500
Received: from cleopatra.tlv.redhat.com (cleopatra.tlv.redhat.com
	[10.35.255.11])
	by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id pBJEDuMA015662; Mon, 19 Dec 2011 09:13:57 -0500
Received: from s01.tlv.redhat.com (s01.tlv.redhat.com [10.35.255.8])
	by cleopatra.tlv.redhat.com (Postfix) with ESMTP id 7B3E7250B9E;
	Mon, 19 Dec 2011 16:13:52 +0200 (IST)
From: Avi Kivity <avi@redhat.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	qemu-devel@nongnu.org, "Michael S. Tsirkin" <mst@redhat.com>
Date: Mon, 19 Dec 2011 16:13:21 +0200
Message-Id: <1324304024-11220-1-git-send-email-avi@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
Cc: xen-devel@lists.xensource.com, kvm@vger.kernel.org
Subject: [Xen-devel] [PATCH 00/23] Remove cpu_get_physical_page_desc()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

cpu_get_physical_page_desc() exposes the internals of the memory core to
callers; as such it prevents the refactoring planned there.  This patchset
converts all callers memory API equivalents and removes the function.

The conversion leaves a lot of potential for further cleanups; the
MemoryListener API (which replaces CPUPhysMemoryClient) guarantees matched
range_add and range_del calls, so the need to handle splitting is removed.
This is left for later.

Please review and test, especially the vhost and Xen parts, which I only
build tested.

Also available from:

  git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git memory/page_desc

Avi Kivity (23):
  memory: introduce memory_region_find()
  sysbus: add sysbus_address_space()
  memory: add memory_region_is_ram()
  framebuffer: drop use of cpu_get_physical_page_desc()
  memory: add memory_region_is_rom()
  loader: remove calls to cpu_get_physical_page_desc()
  framebuffer: drop use of cpu_physical_sync_dirty_bitmap()
  memory: replace cpu_physical_sync_dirty_bitmap() with a memory API
  memory: add API for observing updates to the physical memory map
  memory: add memory_region_is_logging()
  kvm: switch kvm slots to use host virtual address instead of
    ram_addr_t
  fixup: listener fixes
  kvm: convert to MemoryListener API
  vhost: convert to MemoryListener API
  xen, vga: add API for registering the framebuffer
  memory: temporarily add memory_region_get_ram_addr()
  xen: convert to MemoryListener API
  memory: remove CPUPhysMemoryClient
  kvm: avoid cpu_get_physical_page_desc()
  vhost: avoid cpu_get_physical_page_desc()
  virtio-balloon: avoid cpu_get_physical_page_desc()
  sparc: avoid cpu_get_physical_page_desc()
  Remove cpu_get_physical_page_desc()

 arch_init.c               |    6 +-
 cpu-all.h                 |    9 --
 cpu-common.h              |   24 ------
 exec.c                    |  175 +---------------------------------------
 hw/framebuffer.c          |   32 +++----
 hw/framebuffer.h          |    3 +
 hw/loader.c               |    9 +-
 hw/milkymist-vgafb.c      |    2 +-
 hw/omap_lcdc.c            |    4 +-
 hw/pl110.c                |    2 +-
 hw/pxa2xx_lcd.c           |   10 ++-
 hw/sysbus.c               |    5 +
 hw/sysbus.h               |    1 +
 hw/vga.c                  |    2 +
 hw/vhost.c                |  167 ++++++++++++++++++++++++++++++---------
 hw/vhost.h                |    5 +-
 hw/virtio-balloon.c       |   14 +++-
 hw/xen.h                  |    3 +
 kvm-all.c                 |  151 +++++++++++++++++++++--------------
 kvm.h                     |    4 +-
 memory.c                  |  193 ++++++++++++++++++++++++++++++++++++++++++---
 memory.h                  |  127 +++++++++++++++++++++++++++++
 target-i386/kvm.c         |    7 +-
 target-sparc/mmu_helper.c |    5 +-
 trace-events              |    2 +-
 xen-all.c                 |  143 ++++++++++++++++++++-------------
 xen-stub.c                |    4 +
 27 files changed, 695 insertions(+), 414 deletions(-)

-- 
1.7.7.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 14:14:26 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 14:14:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rcdyk-0007DF-Nm; Mon, 19 Dec 2011 14:14:10 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <avi@redhat.com>) id 1Rcdyk-0007Bs-6G
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 14:14:10 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1324304043!7791163!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDY0OTI=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 751 invoked from network); 19 Dec 2011 14:14:03 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-7.tower-182.messagelabs.com with SMTP;
	19 Dec 2011 14:14:03 -0000
Received: from int-mx01.intmail.prod.int.phx2.redhat.com
	(int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id pBJEE1R0024932
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 19 Dec 2011 09:14:01 -0500
Received: from cleopatra.tlv.redhat.com (cleopatra.tlv.redhat.com
	[10.35.255.11])
	by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP
	id pBJEE0N3009673; Mon, 19 Dec 2011 09:14:01 -0500
Received: from s01.tlv.redhat.com (s01.tlv.redhat.com [10.35.255.8])
	by cleopatra.tlv.redhat.com (Postfix) with ESMTP id 8E83D250BA1;
	Mon, 19 Dec 2011 16:13:54 +0200 (IST)
From: Avi Kivity <avi@redhat.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	qemu-devel@nongnu.org, "Michael S. Tsirkin" <mst@redhat.com>
Date: Mon, 19 Dec 2011 16:13:23 +0200
Message-Id: <1324304024-11220-3-git-send-email-avi@redhat.com>
In-Reply-To: <1324304024-11220-1-git-send-email-avi@redhat.com>
References: <1324304024-11220-1-git-send-email-avi@redhat.com>
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.11
Cc: xen-devel@lists.xensource.com, kvm@vger.kernel.org
Subject: [Xen-devel] [PATCH 02/23] sysbus: add sysbus_address_space()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Given a bus device, retrieves the memory address space for its bus.

Signed-off-by: Avi Kivity <avi@redhat.com>
---
 hw/sysbus.c |    5 +++++
 hw/sysbus.h |    1 +
 2 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/hw/sysbus.c b/hw/sysbus.c
index b315a8c..492a7c6 100644
--- a/hw/sysbus.c
+++ b/hw/sysbus.c
@@ -277,3 +277,8 @@ void sysbus_del_io(SysBusDevice *dev, MemoryRegion *mem)
 {
     memory_region_del_subregion(get_system_io(), mem);
 }
+
+MemoryRegion *sysbus_address_space(SysBusDevice *dev)
+{
+    return get_system_memory();
+}
diff --git a/hw/sysbus.h b/hw/sysbus.h
index 9bac582..7cecf98 100644
--- a/hw/sysbus.h
+++ b/hw/sysbus.h
@@ -62,6 +62,7 @@ void sysbus_del_memory(SysBusDevice *dev, MemoryRegion *mem);
 void sysbus_add_io(SysBusDevice *dev, target_phys_addr_t addr,
                    MemoryRegion *mem);
 void sysbus_del_io(SysBusDevice *dev, MemoryRegion *mem);
+MemoryRegion *sysbus_address_space(SysBusDevice *dev);
 
 /* Legacy helper function for creating devices.  */
 DeviceState *sysbus_create_varargs(const char *name,
-- 
1.7.7.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 14:14:26 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 14:14:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rcdym-0007Dr-5D; Mon, 19 Dec 2011 14:14:12 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <avi@redhat.com>) id 1Rcdyk-0007Bu-IS
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 14:14:10 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1324304043!5941157!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDY0OTI=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11347 invoked from network); 19 Dec 2011 14:14:04 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-15.tower-174.messagelabs.com with SMTP;
	19 Dec 2011 14:14:04 -0000
Received: from int-mx01.intmail.prod.int.phx2.redhat.com
	(int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id pBJEE2ln008945
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 19 Dec 2011 09:14:02 -0500
Received: from cleopatra.tlv.redhat.com (cleopatra.tlv.redhat.com
	[10.35.255.11])
	by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP
	id pBJEE0N5009673; Mon, 19 Dec 2011 09:14:01 -0500
Received: from s01.tlv.redhat.com (s01.tlv.redhat.com [10.35.255.8])
	by cleopatra.tlv.redhat.com (Postfix) with ESMTP id 9F6E1250BA4;
	Mon, 19 Dec 2011 16:13:54 +0200 (IST)
From: Avi Kivity <avi@redhat.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	qemu-devel@nongnu.org, "Michael S. Tsirkin" <mst@redhat.com>
Date: Mon, 19 Dec 2011 16:13:26 +0200
Message-Id: <1324304024-11220-6-git-send-email-avi@redhat.com>
In-Reply-To: <1324304024-11220-1-git-send-email-avi@redhat.com>
References: <1324304024-11220-1-git-send-email-avi@redhat.com>
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.11
Cc: xen-devel@lists.xensource.com, kvm@vger.kernel.org
Subject: [Xen-devel] [PATCH 05/23] memory: add memory_region_is_rom()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Signed-off-by: Avi Kivity <avi@redhat.com>
---
 memory.c |    5 +++++
 memory.h |    9 +++++++++
 2 files changed, 14 insertions(+), 0 deletions(-)

diff --git a/memory.c b/memory.c
index 6fd31d4..c57b7de 100644
--- a/memory.c
+++ b/memory.c
@@ -1073,6 +1073,11 @@ bool memory_region_is_ram(MemoryRegion *mr)
     return mr->ram;
 }
 
+bool memory_region_is_rom(MemoryRegion *mr)
+{
+    return mr->ram && mr->readonly;
+}
+
 void memory_region_set_offset(MemoryRegion *mr, target_phys_addr_t offset)
 {
     mr->offset = offset;
diff --git a/memory.h b/memory.h
index 13f88c0..42546c4 100644
--- a/memory.h
+++ b/memory.h
@@ -294,6 +294,15 @@ uint64_t memory_region_size(MemoryRegion *mr);
 bool memory_region_is_ram(MemoryRegion *mr);
 
 /**
+ * memory_region_is_rom: check whether a memory region is ROM
+ *
+ * Returns %true is a memory region is read-only memory.
+ *
+ * @mr: the memory region being queried
+ */
+bool memory_region_is_rom(MemoryRegion *mr);
+
+/**
  * memory_region_get_ram_ptr: Get a pointer into a RAM memory region.
  *
  * Returns a host pointer to a RAM memory region (created with
-- 
1.7.7.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 14:14:26 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 14:14:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rcdym-0007Dr-5D; Mon, 19 Dec 2011 14:14:12 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <avi@redhat.com>) id 1Rcdyk-0007Bu-IS
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 14:14:10 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1324304043!5941157!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDY0OTI=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11347 invoked from network); 19 Dec 2011 14:14:04 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-15.tower-174.messagelabs.com with SMTP;
	19 Dec 2011 14:14:04 -0000
Received: from int-mx01.intmail.prod.int.phx2.redhat.com
	(int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id pBJEE2ln008945
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 19 Dec 2011 09:14:02 -0500
Received: from cleopatra.tlv.redhat.com (cleopatra.tlv.redhat.com
	[10.35.255.11])
	by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP
	id pBJEE0N5009673; Mon, 19 Dec 2011 09:14:01 -0500
Received: from s01.tlv.redhat.com (s01.tlv.redhat.com [10.35.255.8])
	by cleopatra.tlv.redhat.com (Postfix) with ESMTP id 9F6E1250BA4;
	Mon, 19 Dec 2011 16:13:54 +0200 (IST)
From: Avi Kivity <avi@redhat.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	qemu-devel@nongnu.org, "Michael S. Tsirkin" <mst@redhat.com>
Date: Mon, 19 Dec 2011 16:13:26 +0200
Message-Id: <1324304024-11220-6-git-send-email-avi@redhat.com>
In-Reply-To: <1324304024-11220-1-git-send-email-avi@redhat.com>
References: <1324304024-11220-1-git-send-email-avi@redhat.com>
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.11
Cc: xen-devel@lists.xensource.com, kvm@vger.kernel.org
Subject: [Xen-devel] [PATCH 05/23] memory: add memory_region_is_rom()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Signed-off-by: Avi Kivity <avi@redhat.com>
---
 memory.c |    5 +++++
 memory.h |    9 +++++++++
 2 files changed, 14 insertions(+), 0 deletions(-)

diff --git a/memory.c b/memory.c
index 6fd31d4..c57b7de 100644
--- a/memory.c
+++ b/memory.c
@@ -1073,6 +1073,11 @@ bool memory_region_is_ram(MemoryRegion *mr)
     return mr->ram;
 }
 
+bool memory_region_is_rom(MemoryRegion *mr)
+{
+    return mr->ram && mr->readonly;
+}
+
 void memory_region_set_offset(MemoryRegion *mr, target_phys_addr_t offset)
 {
     mr->offset = offset;
diff --git a/memory.h b/memory.h
index 13f88c0..42546c4 100644
--- a/memory.h
+++ b/memory.h
@@ -294,6 +294,15 @@ uint64_t memory_region_size(MemoryRegion *mr);
 bool memory_region_is_ram(MemoryRegion *mr);
 
 /**
+ * memory_region_is_rom: check whether a memory region is ROM
+ *
+ * Returns %true is a memory region is read-only memory.
+ *
+ * @mr: the memory region being queried
+ */
+bool memory_region_is_rom(MemoryRegion *mr);
+
+/**
  * memory_region_get_ram_ptr: Get a pointer into a RAM memory region.
  *
  * Returns a host pointer to a RAM memory region (created with
-- 
1.7.7.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 14:14:26 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 14:14:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rcdyh-0007C9-UX; Mon, 19 Dec 2011 14:14:07 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <avi@redhat.com>) id 1Rcdyg-0007Bv-0T
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 14:14:06 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1324304019!52771615!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDY0OTI=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11448 invoked from network); 19 Dec 2011 14:13:40 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-13.tower-27.messagelabs.com with SMTP;
	19 Dec 2011 14:13:40 -0000
Received: from int-mx12.intmail.prod.int.phx2.redhat.com
	(int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id pBJEDxKw008933
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 19 Dec 2011 09:13:59 -0500
Received: from cleopatra.tlv.redhat.com (cleopatra.tlv.redhat.com
	[10.35.255.11])
	by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id pBJEDwM4032280; Mon, 19 Dec 2011 09:13:58 -0500
Received: from s01.tlv.redhat.com (s01.tlv.redhat.com [10.35.255.8])
	by cleopatra.tlv.redhat.com (Postfix) with ESMTP id 8BF08250BA0;
	Mon, 19 Dec 2011 16:13:54 +0200 (IST)
From: Avi Kivity <avi@redhat.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	qemu-devel@nongnu.org, "Michael S. Tsirkin" <mst@redhat.com>
Date: Mon, 19 Dec 2011 16:13:22 +0200
Message-Id: <1324304024-11220-2-git-send-email-avi@redhat.com>
In-Reply-To: <1324304024-11220-1-git-send-email-avi@redhat.com>
References: <1324304024-11220-1-git-send-email-avi@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.25
Cc: xen-devel@lists.xensource.com, kvm@vger.kernel.org
Subject: [Xen-devel] [PATCH 01/23] memory: introduce memory_region_find()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Given an address space (represented by the top-level memory region),
returns the memory region that maps a given range.  Useful for implementing
DMA.

The implementation is a simplistic binary search.  Once we have a tree
representation this can be optimized.

Signed-off-by: Avi Kivity <avi@redhat.com>
---
 memory.c |   62 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 memory.h |   32 ++++++++++++++++++++++++++++++++
 2 files changed, 94 insertions(+), 0 deletions(-)

diff --git a/memory.c b/memory.c
index cbd6988..d8b7c27 100644
--- a/memory.c
+++ b/memory.c
@@ -514,6 +514,20 @@ static void as_io_ioeventfd_del(AddressSpace *as, MemoryRegionIoeventfd *fd)
     .ops = &address_space_ops_io,
 };
 
+static AddressSpace *memory_region_to_address_space(MemoryRegion *mr)
+{
+    while (mr->parent) {
+        mr = mr->parent;
+    }
+    if (mr == address_space_memory.root) {
+        return &address_space_memory;
+    }
+    if (mr == address_space_io.root) {
+        return &address_space_io;
+    }
+    abort();
+}
+
 /* Render a memory region into the global view.  Ranges in @view obscure
  * ranges in @mr.
  */
@@ -1309,6 +1323,54 @@ void memory_region_del_subregion(MemoryRegion *mr,
     memory_region_update_topology();
 }
 
+static int cmp_flatrange_addr(const void *_addr, const void *_fr)
+{
+    const AddrRange *addr = _addr;
+    const FlatRange *fr = _fr;
+
+    if (int128_le(addrrange_end(*addr), fr->addr.start)) {
+        return -1;
+    } else if (int128_ge(addr->start, addrrange_end(fr->addr))) {
+        return 1;
+    }
+    return 0;
+}
+
+static FlatRange *address_space_lookup(AddressSpace *as, AddrRange addr)
+{
+    return bsearch(&addr, as->current_map.ranges, as->current_map.nr,
+                   sizeof(FlatRange), cmp_flatrange_addr);
+}
+
+MemoryRegionSection memory_region_find(MemoryRegion *address_space,
+                                       target_phys_addr_t addr, uint64_t size)
+{
+    AddressSpace *as = memory_region_to_address_space(address_space);
+    AddrRange range = addrrange_make(int128_make64(addr),
+                                     int128_make64(size));
+    FlatRange *fr = address_space_lookup(as, range);
+    MemoryRegionSection ret = { .mr = NULL };
+
+    if (!fr) {
+        return ret;
+    }
+
+    while (fr > as->current_map.ranges
+           && addrrange_intersects(fr[-1].addr, range)) {
+        --fr;
+    }
+
+    ret.mr = fr->mr;
+    range = addrrange_intersection(range, fr->addr);
+    ret.offset_within_region = fr->offset_in_region;
+    ret.offset_within_region += int128_get64(int128_sub(range.start,
+                                                        fr->addr.start));
+    ret.size = int128_get64(range.size);
+    ret.offset_within_address_space = int128_get64(range.start);
+    return ret;
+}
+
+
 void set_system_memory_map(MemoryRegion *mr)
 {
     address_space_memory.root = mr;
diff --git a/memory.h b/memory.h
index beae127..1d5c414 100644
--- a/memory.h
+++ b/memory.h
@@ -146,6 +146,24 @@ struct MemoryRegionPortio {
 
 #define PORTIO_END_OF_LIST() { }
 
+typedef struct MemoryRegionSection MemoryRegionSection;
+
+/**
+ * MemoryRegionSection: describes a fragment of a #MemoryRegion
+ *
+ * @mr: the region, or %NULL if empty
+ * @offset_within_region: the beginning of the section, relative to @mr's start
+ * @size: the size of the section; will not exceed @mr's boundaries
+ * @offset_within_address_space: the address of the first byte of the section
+ *     relative to the region's address space
+ */
+struct MemoryRegionSection {
+    MemoryRegion *mr;
+    target_phys_addr_t offset_within_region;
+    uint64_t size;
+    target_phys_addr_t offset_within_address_space;
+};
+
 /**
  * memory_region_init: Initialize a memory region
  *
@@ -502,6 +520,20 @@ void memory_region_del_subregion(MemoryRegion *mr,
                                  MemoryRegion *subregion);
 
 /**
+ * memory_region_find: locate a MemoryRegion in an address space
+ *
+ * Locates the first #MemoryRegion within an address space given by
+ * @address_space that overlaps the range given by @addr and @size.
+ *
+ * @address_space: a top-level (i.e. parentless) region that contains
+ *       the region to be found
+ * @addr: start of the area within @address_space to be searched
+ * @size: size of the area to be searched
+ */
+MemoryRegionSection memory_region_find(MemoryRegion *address_space,
+                                       target_phys_addr_t addr, uint64_t size);
+
+/**
  * memory_region_transaction_begin: Start a transaction.
  *
  * During a transaction, changes will be accumulated and made visible
-- 
1.7.7.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 14:14:26 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 14:14:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rcdyh-0007C9-UX; Mon, 19 Dec 2011 14:14:07 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <avi@redhat.com>) id 1Rcdyg-0007Bv-0T
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 14:14:06 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1324304019!52771615!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDY0OTI=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11448 invoked from network); 19 Dec 2011 14:13:40 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-13.tower-27.messagelabs.com with SMTP;
	19 Dec 2011 14:13:40 -0000
Received: from int-mx12.intmail.prod.int.phx2.redhat.com
	(int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id pBJEDxKw008933
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 19 Dec 2011 09:13:59 -0500
Received: from cleopatra.tlv.redhat.com (cleopatra.tlv.redhat.com
	[10.35.255.11])
	by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id pBJEDwM4032280; Mon, 19 Dec 2011 09:13:58 -0500
Received: from s01.tlv.redhat.com (s01.tlv.redhat.com [10.35.255.8])
	by cleopatra.tlv.redhat.com (Postfix) with ESMTP id 8BF08250BA0;
	Mon, 19 Dec 2011 16:13:54 +0200 (IST)
From: Avi Kivity <avi@redhat.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	qemu-devel@nongnu.org, "Michael S. Tsirkin" <mst@redhat.com>
Date: Mon, 19 Dec 2011 16:13:22 +0200
Message-Id: <1324304024-11220-2-git-send-email-avi@redhat.com>
In-Reply-To: <1324304024-11220-1-git-send-email-avi@redhat.com>
References: <1324304024-11220-1-git-send-email-avi@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.25
Cc: xen-devel@lists.xensource.com, kvm@vger.kernel.org
Subject: [Xen-devel] [PATCH 01/23] memory: introduce memory_region_find()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Given an address space (represented by the top-level memory region),
returns the memory region that maps a given range.  Useful for implementing
DMA.

The implementation is a simplistic binary search.  Once we have a tree
representation this can be optimized.

Signed-off-by: Avi Kivity <avi@redhat.com>
---
 memory.c |   62 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 memory.h |   32 ++++++++++++++++++++++++++++++++
 2 files changed, 94 insertions(+), 0 deletions(-)

diff --git a/memory.c b/memory.c
index cbd6988..d8b7c27 100644
--- a/memory.c
+++ b/memory.c
@@ -514,6 +514,20 @@ static void as_io_ioeventfd_del(AddressSpace *as, MemoryRegionIoeventfd *fd)
     .ops = &address_space_ops_io,
 };
 
+static AddressSpace *memory_region_to_address_space(MemoryRegion *mr)
+{
+    while (mr->parent) {
+        mr = mr->parent;
+    }
+    if (mr == address_space_memory.root) {
+        return &address_space_memory;
+    }
+    if (mr == address_space_io.root) {
+        return &address_space_io;
+    }
+    abort();
+}
+
 /* Render a memory region into the global view.  Ranges in @view obscure
  * ranges in @mr.
  */
@@ -1309,6 +1323,54 @@ void memory_region_del_subregion(MemoryRegion *mr,
     memory_region_update_topology();
 }
 
+static int cmp_flatrange_addr(const void *_addr, const void *_fr)
+{
+    const AddrRange *addr = _addr;
+    const FlatRange *fr = _fr;
+
+    if (int128_le(addrrange_end(*addr), fr->addr.start)) {
+        return -1;
+    } else if (int128_ge(addr->start, addrrange_end(fr->addr))) {
+        return 1;
+    }
+    return 0;
+}
+
+static FlatRange *address_space_lookup(AddressSpace *as, AddrRange addr)
+{
+    return bsearch(&addr, as->current_map.ranges, as->current_map.nr,
+                   sizeof(FlatRange), cmp_flatrange_addr);
+}
+
+MemoryRegionSection memory_region_find(MemoryRegion *address_space,
+                                       target_phys_addr_t addr, uint64_t size)
+{
+    AddressSpace *as = memory_region_to_address_space(address_space);
+    AddrRange range = addrrange_make(int128_make64(addr),
+                                     int128_make64(size));
+    FlatRange *fr = address_space_lookup(as, range);
+    MemoryRegionSection ret = { .mr = NULL };
+
+    if (!fr) {
+        return ret;
+    }
+
+    while (fr > as->current_map.ranges
+           && addrrange_intersects(fr[-1].addr, range)) {
+        --fr;
+    }
+
+    ret.mr = fr->mr;
+    range = addrrange_intersection(range, fr->addr);
+    ret.offset_within_region = fr->offset_in_region;
+    ret.offset_within_region += int128_get64(int128_sub(range.start,
+                                                        fr->addr.start));
+    ret.size = int128_get64(range.size);
+    ret.offset_within_address_space = int128_get64(range.start);
+    return ret;
+}
+
+
 void set_system_memory_map(MemoryRegion *mr)
 {
     address_space_memory.root = mr;
diff --git a/memory.h b/memory.h
index beae127..1d5c414 100644
--- a/memory.h
+++ b/memory.h
@@ -146,6 +146,24 @@ struct MemoryRegionPortio {
 
 #define PORTIO_END_OF_LIST() { }
 
+typedef struct MemoryRegionSection MemoryRegionSection;
+
+/**
+ * MemoryRegionSection: describes a fragment of a #MemoryRegion
+ *
+ * @mr: the region, or %NULL if empty
+ * @offset_within_region: the beginning of the section, relative to @mr's start
+ * @size: the size of the section; will not exceed @mr's boundaries
+ * @offset_within_address_space: the address of the first byte of the section
+ *     relative to the region's address space
+ */
+struct MemoryRegionSection {
+    MemoryRegion *mr;
+    target_phys_addr_t offset_within_region;
+    uint64_t size;
+    target_phys_addr_t offset_within_address_space;
+};
+
 /**
  * memory_region_init: Initialize a memory region
  *
@@ -502,6 +520,20 @@ void memory_region_del_subregion(MemoryRegion *mr,
                                  MemoryRegion *subregion);
 
 /**
+ * memory_region_find: locate a MemoryRegion in an address space
+ *
+ * Locates the first #MemoryRegion within an address space given by
+ * @address_space that overlaps the range given by @addr and @size.
+ *
+ * @address_space: a top-level (i.e. parentless) region that contains
+ *       the region to be found
+ * @addr: start of the area within @address_space to be searched
+ * @size: size of the area to be searched
+ */
+MemoryRegionSection memory_region_find(MemoryRegion *address_space,
+                                       target_phys_addr_t addr, uint64_t size);
+
+/**
  * memory_region_transaction_begin: Start a transaction.
  *
  * During a transaction, changes will be accumulated and made visible
-- 
1.7.7.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 14:14:26 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 14:14:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rcdyj-0007Ck-GG; Mon, 19 Dec 2011 14:14:09 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <avi@redhat.com>) id 1Rcdyi-0007C8-1U
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 14:14:08 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1324303920!48892058!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDY0OTI=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12388 invoked from network); 19 Dec 2011 14:12:00 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-14.tower-27.messagelabs.com with SMTP;
	19 Dec 2011 14:12:00 -0000
Received: from int-mx01.intmail.prod.int.phx2.redhat.com
	(int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id pBJEE4D7024952
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 19 Dec 2011 09:14:04 -0500
Received: from cleopatra.tlv.redhat.com (cleopatra.tlv.redhat.com
	[10.35.255.11])
	by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP
	id pBJEE0N9009673; Mon, 19 Dec 2011 09:14:03 -0500
Received: from s01.tlv.redhat.com (s01.tlv.redhat.com [10.35.255.8])
	by cleopatra.tlv.redhat.com (Postfix) with ESMTP id B56E2250BAD;
	Mon, 19 Dec 2011 16:13:54 +0200 (IST)
From: Avi Kivity <avi@redhat.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	qemu-devel@nongnu.org, "Michael S. Tsirkin" <mst@redhat.com>
Date: Mon, 19 Dec 2011 16:13:35 +0200
Message-Id: <1324304024-11220-15-git-send-email-avi@redhat.com>
In-Reply-To: <1324304024-11220-1-git-send-email-avi@redhat.com>
References: <1324304024-11220-1-git-send-email-avi@redhat.com>
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.11
Cc: xen-devel@lists.xensource.com, kvm@vger.kernel.org
Subject: [Xen-devel] [PATCH 14/23] vhost: convert to MemoryListener API
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Drop the use of cpu_register_phys_memory_client() in favour of the new
MemoryListener API.  The new API simplifies the caller, since there is no
need to deal with splitting and merging slots; however this is not exploited
in this patch.

Signed-off-by: Avi Kivity <avi@redhat.com>
---
 hw/vhost.c |  126 ++++++++++++++++++++++++++++++++++++++++++++---------------
 hw/vhost.h |    3 +-
 2 files changed, 96 insertions(+), 33 deletions(-)

diff --git a/hw/vhost.c b/hw/vhost.c
index 0870cb7..a1c5e4c 100644
--- a/hw/vhost.c
+++ b/hw/vhost.c
@@ -57,12 +57,12 @@ static void vhost_dev_sync_region(struct vhost_dev *dev,
     }
 }
 
-static int vhost_client_sync_dirty_bitmap(CPUPhysMemoryClient *client,
-                                          target_phys_addr_t start_addr,
-                                          target_phys_addr_t end_addr)
+static int vhost_sync_dirty_bitmap(struct vhost_dev *dev,
+                                   target_phys_addr_t start_addr,
+                                   target_phys_addr_t end_addr)
 {
-    struct vhost_dev *dev = container_of(client, struct vhost_dev, client);
     int i;
+
     if (!dev->log_enabled || !dev->started) {
         return 0;
     }
@@ -81,6 +81,17 @@ static int vhost_client_sync_dirty_bitmap(CPUPhysMemoryClient *client,
     return 0;
 }
 
+static void vhost_log_sync(MemoryListener *listener,
+                          MemoryRegionSection *section)
+{
+    struct vhost_dev *dev = container_of(listener, struct vhost_dev,
+                                         memory_listener);
+    target_phys_addr_t start_addr = section->offset_within_address_space;
+    target_phys_addr_t end_addr = start_addr + section->size;
+
+    vhost_sync_dirty_bitmap(dev, start_addr, end_addr);
+}
+
 /* Assign/unassign. Keep an unsorted array of non-overlapping
  * memory regions in dev->mem. */
 static void vhost_dev_unassign_memory(struct vhost_dev *dev,
@@ -259,8 +270,7 @@ static inline void vhost_dev_log_resize(struct vhost_dev* dev, uint64_t size)
     log_base = (uint64_t)(unsigned long)log;
     r = ioctl(dev->control, VHOST_SET_LOG_BASE, &log_base);
     assert(r >= 0);
-    vhost_client_sync_dirty_bitmap(&dev->client, 0,
-                                   (target_phys_addr_t)~0x0ull);
+    vhost_sync_dirty_bitmap(dev, 0, (target_phys_addr_t)~0x0ull);
     if (dev->log) {
         g_free(dev->log);
     }
@@ -335,31 +345,37 @@ static bool vhost_dev_cmp_memory(struct vhost_dev *dev,
     return uaddr != reg->userspace_addr + start_addr - reg->guest_phys_addr;
 }
 
-static void vhost_client_set_memory(CPUPhysMemoryClient *client,
-                                    target_phys_addr_t start_addr,
-                                    ram_addr_t size,
-                                    ram_addr_t phys_offset,
-                                    bool log_dirty)
+static void vhost_set_memory(MemoryListener *listener,
+                             MemoryRegionSection *section,
+                             bool add)
 {
-    struct vhost_dev *dev = container_of(client, struct vhost_dev, client);
-    ram_addr_t flags = phys_offset & ~TARGET_PAGE_MASK;
+    struct vhost_dev *dev = container_of(listener, struct vhost_dev,
+                                         memory_listener);
+    target_phys_addr_t start_addr = section->offset_within_address_space;
+    ram_addr_t size = section->size;
+    bool log_dirty = memory_region_is_logging(section->mr);
     int s = offsetof(struct vhost_memory, regions) +
         (dev->mem->nregions + 1) * sizeof dev->mem->regions[0];
     uint64_t log_size;
     int r;
+    void *ram;
+
+    if (!memory_region_is_ram(section->mr)) {
+        return;
+    }
 
     dev->mem = g_realloc(dev->mem, s);
 
     if (log_dirty) {
-        flags = IO_MEM_UNASSIGNED;
+        add = false;
     }
 
     assert(size);
 
     /* Optimize no-change case. At least cirrus_vga does this a lot at this time. */
-    if (flags == IO_MEM_RAM) {
-        if (!vhost_dev_cmp_memory(dev, start_addr, size,
-                                  (uintptr_t)qemu_get_ram_ptr(phys_offset))) {
+    ram = memory_region_get_ram_ptr(section->mr);
+    if (add) {
+        if (!vhost_dev_cmp_memory(dev, start_addr, size, (uintptr_t)ram)) {
             /* Region exists with same address. Nothing to do. */
             return;
         }
@@ -371,10 +387,9 @@ static void vhost_client_set_memory(CPUPhysMemoryClient *client,
     }
 
     vhost_dev_unassign_memory(dev, start_addr, size);
-    if (flags == IO_MEM_RAM) {
+    if (add) {
         /* Add given mapping, merging adjacent regions if any */
-        vhost_dev_assign_memory(dev, start_addr, size,
-                                (uintptr_t)qemu_get_ram_ptr(phys_offset));
+        vhost_dev_assign_memory(dev, start_addr, size, (uintptr_t)ram);
     } else {
         /* Remove old mapping for this memory, if any. */
         vhost_dev_unassign_memory(dev, start_addr, size);
@@ -410,6 +425,18 @@ static void vhost_client_set_memory(CPUPhysMemoryClient *client,
     }
 }
 
+static void vhost_region_add(MemoryListener *listener,
+                             MemoryRegionSection *section)
+{
+    vhost_set_memory(listener, section, true);
+}
+
+static void vhost_region_del(MemoryListener *listener,
+                             MemoryRegionSection *section)
+{
+    vhost_set_memory(listener, section, false);
+}
+
 static int vhost_virtqueue_set_addr(struct vhost_dev *dev,
                                     struct vhost_virtqueue *vq,
                                     unsigned idx, bool enable_log)
@@ -467,10 +494,10 @@ static int vhost_dev_set_log(struct vhost_dev *dev, bool enable_log)
     return r;
 }
 
-static int vhost_client_migration_log(CPUPhysMemoryClient *client,
-                                      int enable)
+static int vhost_migration_log(MemoryListener *listener, int enable)
 {
-    struct vhost_dev *dev = container_of(client, struct vhost_dev, client);
+    struct vhost_dev *dev = container_of(listener, struct vhost_dev,
+                                         memory_listener);
     int r;
     if (!!enable == dev->log_enabled) {
         return 0;
@@ -500,6 +527,38 @@ static int vhost_client_migration_log(CPUPhysMemoryClient *client,
     return 0;
 }
 
+static void vhost_log_global_start(MemoryListener *listener)
+{
+    int r;
+
+    r = vhost_migration_log(listener, true);
+    if (r < 0) {
+        abort();
+    }
+}
+
+static void vhost_log_global_stop(MemoryListener *listener)
+{
+    int r;
+
+    r = vhost_migration_log(listener, false);
+    if (r < 0) {
+        abort();
+    }
+}
+
+static void vhost_log_start(MemoryListener *listener,
+                            MemoryRegionSection *section)
+{
+    /* FIXME: implement */
+}
+
+static void vhost_log_stop(MemoryListener *listener,
+                           MemoryRegionSection *section)
+{
+    /* FIXME: implement */
+}
+
 static int vhost_virtqueue_init(struct vhost_dev *dev,
                                 struct VirtIODevice *vdev,
                                 struct vhost_virtqueue *vq,
@@ -645,17 +704,21 @@ int vhost_dev_init(struct vhost_dev *hdev, int devfd, bool force)
     }
     hdev->features = features;
 
-    hdev->client.set_memory = vhost_client_set_memory;
-    hdev->client.sync_dirty_bitmap = vhost_client_sync_dirty_bitmap;
-    hdev->client.migration_log = vhost_client_migration_log;
-    hdev->client.log_start = NULL;
-    hdev->client.log_stop = NULL;
+    hdev->memory_listener = (MemoryListener) {
+        .region_add = vhost_region_add,
+        .region_del = vhost_region_del,
+        .log_start = vhost_log_start,
+        .log_stop = vhost_log_stop,
+        .log_sync = vhost_log_sync,
+        .log_global_start = vhost_log_global_start,
+        .log_global_stop = vhost_log_global_stop,
+    };
     hdev->mem = g_malloc0(offsetof(struct vhost_memory, regions));
     hdev->log = NULL;
     hdev->log_size = 0;
     hdev->log_enabled = false;
     hdev->started = false;
-    cpu_register_phys_memory_client(&hdev->client);
+    memory_listener_register(&hdev->memory_listener);
     hdev->force = force;
     return 0;
 fail:
@@ -666,7 +729,7 @@ int vhost_dev_init(struct vhost_dev *hdev, int devfd, bool force)
 
 void vhost_dev_cleanup(struct vhost_dev *hdev)
 {
-    cpu_unregister_phys_memory_client(&hdev->client);
+    memory_listener_unregister(&hdev->memory_listener);
     g_free(hdev->mem);
     close(hdev->control);
 }
@@ -808,8 +871,7 @@ void vhost_dev_stop(struct vhost_dev *hdev, VirtIODevice *vdev)
                                 hdev->vqs + i,
                                 i);
     }
-    vhost_client_sync_dirty_bitmap(&hdev->client, 0,
-                                   (target_phys_addr_t)~0x0ull);
+    vhost_sync_dirty_bitmap(hdev, 0, (target_phys_addr_t)~0x0ull);
     r = vdev->binding->set_guest_notifiers(vdev->binding_opaque, false);
     if (r < 0) {
         fprintf(stderr, "vhost guest notifier cleanup failed: %d\n", r);
diff --git a/hw/vhost.h b/hw/vhost.h
index c9452f0..d1824ec 100644
--- a/hw/vhost.h
+++ b/hw/vhost.h
@@ -3,6 +3,7 @@
 
 #include "hw/hw.h"
 #include "hw/virtio.h"
+#include "memory.h"
 
 /* Generic structures common for any vhost based device. */
 struct vhost_virtqueue {
@@ -26,7 +27,7 @@ typedef unsigned long vhost_log_chunk_t;
 
 struct vhost_memory;
 struct vhost_dev {
-    CPUPhysMemoryClient client;
+    MemoryListener memory_listener;
     int control;
     struct vhost_memory *mem;
     struct vhost_virtqueue *vqs;
-- 
1.7.7.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 14:14:26 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 14:14:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rcdyj-0007Ck-GG; Mon, 19 Dec 2011 14:14:09 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <avi@redhat.com>) id 1Rcdyi-0007C8-1U
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 14:14:08 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1324303920!48892058!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDY0OTI=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12388 invoked from network); 19 Dec 2011 14:12:00 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-14.tower-27.messagelabs.com with SMTP;
	19 Dec 2011 14:12:00 -0000
Received: from int-mx01.intmail.prod.int.phx2.redhat.com
	(int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id pBJEE4D7024952
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 19 Dec 2011 09:14:04 -0500
Received: from cleopatra.tlv.redhat.com (cleopatra.tlv.redhat.com
	[10.35.255.11])
	by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP
	id pBJEE0N9009673; Mon, 19 Dec 2011 09:14:03 -0500
Received: from s01.tlv.redhat.com (s01.tlv.redhat.com [10.35.255.8])
	by cleopatra.tlv.redhat.com (Postfix) with ESMTP id B56E2250BAD;
	Mon, 19 Dec 2011 16:13:54 +0200 (IST)
From: Avi Kivity <avi@redhat.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	qemu-devel@nongnu.org, "Michael S. Tsirkin" <mst@redhat.com>
Date: Mon, 19 Dec 2011 16:13:35 +0200
Message-Id: <1324304024-11220-15-git-send-email-avi@redhat.com>
In-Reply-To: <1324304024-11220-1-git-send-email-avi@redhat.com>
References: <1324304024-11220-1-git-send-email-avi@redhat.com>
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.11
Cc: xen-devel@lists.xensource.com, kvm@vger.kernel.org
Subject: [Xen-devel] [PATCH 14/23] vhost: convert to MemoryListener API
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Drop the use of cpu_register_phys_memory_client() in favour of the new
MemoryListener API.  The new API simplifies the caller, since there is no
need to deal with splitting and merging slots; however this is not exploited
in this patch.

Signed-off-by: Avi Kivity <avi@redhat.com>
---
 hw/vhost.c |  126 ++++++++++++++++++++++++++++++++++++++++++++---------------
 hw/vhost.h |    3 +-
 2 files changed, 96 insertions(+), 33 deletions(-)

diff --git a/hw/vhost.c b/hw/vhost.c
index 0870cb7..a1c5e4c 100644
--- a/hw/vhost.c
+++ b/hw/vhost.c
@@ -57,12 +57,12 @@ static void vhost_dev_sync_region(struct vhost_dev *dev,
     }
 }
 
-static int vhost_client_sync_dirty_bitmap(CPUPhysMemoryClient *client,
-                                          target_phys_addr_t start_addr,
-                                          target_phys_addr_t end_addr)
+static int vhost_sync_dirty_bitmap(struct vhost_dev *dev,
+                                   target_phys_addr_t start_addr,
+                                   target_phys_addr_t end_addr)
 {
-    struct vhost_dev *dev = container_of(client, struct vhost_dev, client);
     int i;
+
     if (!dev->log_enabled || !dev->started) {
         return 0;
     }
@@ -81,6 +81,17 @@ static int vhost_client_sync_dirty_bitmap(CPUPhysMemoryClient *client,
     return 0;
 }
 
+static void vhost_log_sync(MemoryListener *listener,
+                          MemoryRegionSection *section)
+{
+    struct vhost_dev *dev = container_of(listener, struct vhost_dev,
+                                         memory_listener);
+    target_phys_addr_t start_addr = section->offset_within_address_space;
+    target_phys_addr_t end_addr = start_addr + section->size;
+
+    vhost_sync_dirty_bitmap(dev, start_addr, end_addr);
+}
+
 /* Assign/unassign. Keep an unsorted array of non-overlapping
  * memory regions in dev->mem. */
 static void vhost_dev_unassign_memory(struct vhost_dev *dev,
@@ -259,8 +270,7 @@ static inline void vhost_dev_log_resize(struct vhost_dev* dev, uint64_t size)
     log_base = (uint64_t)(unsigned long)log;
     r = ioctl(dev->control, VHOST_SET_LOG_BASE, &log_base);
     assert(r >= 0);
-    vhost_client_sync_dirty_bitmap(&dev->client, 0,
-                                   (target_phys_addr_t)~0x0ull);
+    vhost_sync_dirty_bitmap(dev, 0, (target_phys_addr_t)~0x0ull);
     if (dev->log) {
         g_free(dev->log);
     }
@@ -335,31 +345,37 @@ static bool vhost_dev_cmp_memory(struct vhost_dev *dev,
     return uaddr != reg->userspace_addr + start_addr - reg->guest_phys_addr;
 }
 
-static void vhost_client_set_memory(CPUPhysMemoryClient *client,
-                                    target_phys_addr_t start_addr,
-                                    ram_addr_t size,
-                                    ram_addr_t phys_offset,
-                                    bool log_dirty)
+static void vhost_set_memory(MemoryListener *listener,
+                             MemoryRegionSection *section,
+                             bool add)
 {
-    struct vhost_dev *dev = container_of(client, struct vhost_dev, client);
-    ram_addr_t flags = phys_offset & ~TARGET_PAGE_MASK;
+    struct vhost_dev *dev = container_of(listener, struct vhost_dev,
+                                         memory_listener);
+    target_phys_addr_t start_addr = section->offset_within_address_space;
+    ram_addr_t size = section->size;
+    bool log_dirty = memory_region_is_logging(section->mr);
     int s = offsetof(struct vhost_memory, regions) +
         (dev->mem->nregions + 1) * sizeof dev->mem->regions[0];
     uint64_t log_size;
     int r;
+    void *ram;
+
+    if (!memory_region_is_ram(section->mr)) {
+        return;
+    }
 
     dev->mem = g_realloc(dev->mem, s);
 
     if (log_dirty) {
-        flags = IO_MEM_UNASSIGNED;
+        add = false;
     }
 
     assert(size);
 
     /* Optimize no-change case. At least cirrus_vga does this a lot at this time. */
-    if (flags == IO_MEM_RAM) {
-        if (!vhost_dev_cmp_memory(dev, start_addr, size,
-                                  (uintptr_t)qemu_get_ram_ptr(phys_offset))) {
+    ram = memory_region_get_ram_ptr(section->mr);
+    if (add) {
+        if (!vhost_dev_cmp_memory(dev, start_addr, size, (uintptr_t)ram)) {
             /* Region exists with same address. Nothing to do. */
             return;
         }
@@ -371,10 +387,9 @@ static void vhost_client_set_memory(CPUPhysMemoryClient *client,
     }
 
     vhost_dev_unassign_memory(dev, start_addr, size);
-    if (flags == IO_MEM_RAM) {
+    if (add) {
         /* Add given mapping, merging adjacent regions if any */
-        vhost_dev_assign_memory(dev, start_addr, size,
-                                (uintptr_t)qemu_get_ram_ptr(phys_offset));
+        vhost_dev_assign_memory(dev, start_addr, size, (uintptr_t)ram);
     } else {
         /* Remove old mapping for this memory, if any. */
         vhost_dev_unassign_memory(dev, start_addr, size);
@@ -410,6 +425,18 @@ static void vhost_client_set_memory(CPUPhysMemoryClient *client,
     }
 }
 
+static void vhost_region_add(MemoryListener *listener,
+                             MemoryRegionSection *section)
+{
+    vhost_set_memory(listener, section, true);
+}
+
+static void vhost_region_del(MemoryListener *listener,
+                             MemoryRegionSection *section)
+{
+    vhost_set_memory(listener, section, false);
+}
+
 static int vhost_virtqueue_set_addr(struct vhost_dev *dev,
                                     struct vhost_virtqueue *vq,
                                     unsigned idx, bool enable_log)
@@ -467,10 +494,10 @@ static int vhost_dev_set_log(struct vhost_dev *dev, bool enable_log)
     return r;
 }
 
-static int vhost_client_migration_log(CPUPhysMemoryClient *client,
-                                      int enable)
+static int vhost_migration_log(MemoryListener *listener, int enable)
 {
-    struct vhost_dev *dev = container_of(client, struct vhost_dev, client);
+    struct vhost_dev *dev = container_of(listener, struct vhost_dev,
+                                         memory_listener);
     int r;
     if (!!enable == dev->log_enabled) {
         return 0;
@@ -500,6 +527,38 @@ static int vhost_client_migration_log(CPUPhysMemoryClient *client,
     return 0;
 }
 
+static void vhost_log_global_start(MemoryListener *listener)
+{
+    int r;
+
+    r = vhost_migration_log(listener, true);
+    if (r < 0) {
+        abort();
+    }
+}
+
+static void vhost_log_global_stop(MemoryListener *listener)
+{
+    int r;
+
+    r = vhost_migration_log(listener, false);
+    if (r < 0) {
+        abort();
+    }
+}
+
+static void vhost_log_start(MemoryListener *listener,
+                            MemoryRegionSection *section)
+{
+    /* FIXME: implement */
+}
+
+static void vhost_log_stop(MemoryListener *listener,
+                           MemoryRegionSection *section)
+{
+    /* FIXME: implement */
+}
+
 static int vhost_virtqueue_init(struct vhost_dev *dev,
                                 struct VirtIODevice *vdev,
                                 struct vhost_virtqueue *vq,
@@ -645,17 +704,21 @@ int vhost_dev_init(struct vhost_dev *hdev, int devfd, bool force)
     }
     hdev->features = features;
 
-    hdev->client.set_memory = vhost_client_set_memory;
-    hdev->client.sync_dirty_bitmap = vhost_client_sync_dirty_bitmap;
-    hdev->client.migration_log = vhost_client_migration_log;
-    hdev->client.log_start = NULL;
-    hdev->client.log_stop = NULL;
+    hdev->memory_listener = (MemoryListener) {
+        .region_add = vhost_region_add,
+        .region_del = vhost_region_del,
+        .log_start = vhost_log_start,
+        .log_stop = vhost_log_stop,
+        .log_sync = vhost_log_sync,
+        .log_global_start = vhost_log_global_start,
+        .log_global_stop = vhost_log_global_stop,
+    };
     hdev->mem = g_malloc0(offsetof(struct vhost_memory, regions));
     hdev->log = NULL;
     hdev->log_size = 0;
     hdev->log_enabled = false;
     hdev->started = false;
-    cpu_register_phys_memory_client(&hdev->client);
+    memory_listener_register(&hdev->memory_listener);
     hdev->force = force;
     return 0;
 fail:
@@ -666,7 +729,7 @@ int vhost_dev_init(struct vhost_dev *hdev, int devfd, bool force)
 
 void vhost_dev_cleanup(struct vhost_dev *hdev)
 {
-    cpu_unregister_phys_memory_client(&hdev->client);
+    memory_listener_unregister(&hdev->memory_listener);
     g_free(hdev->mem);
     close(hdev->control);
 }
@@ -808,8 +871,7 @@ void vhost_dev_stop(struct vhost_dev *hdev, VirtIODevice *vdev)
                                 hdev->vqs + i,
                                 i);
     }
-    vhost_client_sync_dirty_bitmap(&hdev->client, 0,
-                                   (target_phys_addr_t)~0x0ull);
+    vhost_sync_dirty_bitmap(hdev, 0, (target_phys_addr_t)~0x0ull);
     r = vdev->binding->set_guest_notifiers(vdev->binding_opaque, false);
     if (r < 0) {
         fprintf(stderr, "vhost guest notifier cleanup failed: %d\n", r);
diff --git a/hw/vhost.h b/hw/vhost.h
index c9452f0..d1824ec 100644
--- a/hw/vhost.h
+++ b/hw/vhost.h
@@ -3,6 +3,7 @@
 
 #include "hw/hw.h"
 #include "hw/virtio.h"
+#include "memory.h"
 
 /* Generic structures common for any vhost based device. */
 struct vhost_virtqueue {
@@ -26,7 +27,7 @@ typedef unsigned long vhost_log_chunk_t;
 
 struct vhost_memory;
 struct vhost_dev {
-    CPUPhysMemoryClient client;
+    MemoryListener memory_listener;
     int control;
     struct vhost_memory *mem;
     struct vhost_virtqueue *vqs;
-- 
1.7.7.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 14:14:26 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 14:14:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rcdyk-0007D2-9m; Mon, 19 Dec 2011 14:14:10 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <avi@redhat.com>) id 1Rcdyi-0007Bt-JX
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 14:14:08 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1324304002!51217478!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDY0OTI=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20328 invoked from network); 19 Dec 2011 14:13:23 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-6.tower-27.messagelabs.com with SMTP;
	19 Dec 2011 14:13:23 -0000
Received: from int-mx12.intmail.prod.int.phx2.redhat.com
	(int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id pBJEE1kI008939
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 19 Dec 2011 09:14:01 -0500
Received: from cleopatra.tlv.redhat.com (cleopatra.tlv.redhat.com
	[10.35.255.11])
	by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id pBJEE07e032288; Mon, 19 Dec 2011 09:14:01 -0500
Received: from s01.tlv.redhat.com (s01.tlv.redhat.com [10.35.255.8])
	by cleopatra.tlv.redhat.com (Postfix) with ESMTP id 9091A250BA2;
	Mon, 19 Dec 2011 16:13:54 +0200 (IST)
From: Avi Kivity <avi@redhat.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	qemu-devel@nongnu.org, "Michael S. Tsirkin" <mst@redhat.com>
Date: Mon, 19 Dec 2011 16:13:24 +0200
Message-Id: <1324304024-11220-4-git-send-email-avi@redhat.com>
In-Reply-To: <1324304024-11220-1-git-send-email-avi@redhat.com>
References: <1324304024-11220-1-git-send-email-avi@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.25
Cc: xen-devel@lists.xensource.com, kvm@vger.kernel.org
Subject: [Xen-devel] [PATCH 03/23] memory: add memory_region_is_ram()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Signed-off-by: Avi Kivity <avi@redhat.com>
---
 memory.c |    8 ++++++++
 memory.h |   10 ++++++++++
 2 files changed, 18 insertions(+), 0 deletions(-)

diff --git a/memory.c b/memory.c
index d8b7c27..6fd31d4 100644
--- a/memory.c
+++ b/memory.c
@@ -831,6 +831,7 @@ void memory_region_init(MemoryRegion *mr,
     mr->addr = 0;
     mr->offset = 0;
     mr->terminates = false;
+    mr->ram = false;
     mr->readable = true;
     mr->readonly = false;
     mr->destructor = memory_region_destructor_none;
@@ -997,6 +998,7 @@ void memory_region_init_ram(MemoryRegion *mr,
                             uint64_t size)
 {
     memory_region_init(mr, name, size);
+    mr->ram = true;
     mr->terminates = true;
     mr->destructor = memory_region_destructor_ram;
     mr->ram_addr = qemu_ram_alloc(dev, name, size, mr);
@@ -1010,6 +1012,7 @@ void memory_region_init_ram_ptr(MemoryRegion *mr,
                                 void *ptr)
 {
     memory_region_init(mr, name, size);
+    mr->ram = true;
     mr->terminates = true;
     mr->destructor = memory_region_destructor_ram_from_ptr;
     mr->ram_addr = qemu_ram_alloc_from_ptr(dev, name, size, ptr, mr);
@@ -1065,6 +1068,11 @@ uint64_t memory_region_size(MemoryRegion *mr)
     return int128_get64(mr->size);
 }
 
+bool memory_region_is_ram(MemoryRegion *mr)
+{
+    return mr->ram;
+}
+
 void memory_region_set_offset(MemoryRegion *mr, target_phys_addr_t offset)
 {
     mr->offset = offset;
diff --git a/memory.h b/memory.h
index 1d5c414..13f88c0 100644
--- a/memory.h
+++ b/memory.h
@@ -122,6 +122,7 @@ struct MemoryRegion {
     IORange iorange;
     bool terminates;
     bool readable;
+    bool ram;
     bool readonly; /* For RAM regions */
     MemoryRegion *alias;
     target_phys_addr_t alias_offset;
@@ -284,6 +285,15 @@ void memory_region_destroy(MemoryRegion *mr);
 uint64_t memory_region_size(MemoryRegion *mr);
 
 /**
+ * memory_region_is_ram: check whether a memory region is random access
+ *
+ * Returns %true is a memory region is random access.
+ *
+ * @mr: the memory region being queried
+ */
+bool memory_region_is_ram(MemoryRegion *mr);
+
+/**
  * memory_region_get_ram_ptr: Get a pointer into a RAM memory region.
  *
  * Returns a host pointer to a RAM memory region (created with
-- 
1.7.7.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 14:14:26 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 14:14:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rcdyk-0007D2-9m; Mon, 19 Dec 2011 14:14:10 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <avi@redhat.com>) id 1Rcdyi-0007Bt-JX
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 14:14:08 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1324304002!51217478!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDY0OTI=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20328 invoked from network); 19 Dec 2011 14:13:23 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-6.tower-27.messagelabs.com with SMTP;
	19 Dec 2011 14:13:23 -0000
Received: from int-mx12.intmail.prod.int.phx2.redhat.com
	(int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id pBJEE1kI008939
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 19 Dec 2011 09:14:01 -0500
Received: from cleopatra.tlv.redhat.com (cleopatra.tlv.redhat.com
	[10.35.255.11])
	by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id pBJEE07e032288; Mon, 19 Dec 2011 09:14:01 -0500
Received: from s01.tlv.redhat.com (s01.tlv.redhat.com [10.35.255.8])
	by cleopatra.tlv.redhat.com (Postfix) with ESMTP id 9091A250BA2;
	Mon, 19 Dec 2011 16:13:54 +0200 (IST)
From: Avi Kivity <avi@redhat.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	qemu-devel@nongnu.org, "Michael S. Tsirkin" <mst@redhat.com>
Date: Mon, 19 Dec 2011 16:13:24 +0200
Message-Id: <1324304024-11220-4-git-send-email-avi@redhat.com>
In-Reply-To: <1324304024-11220-1-git-send-email-avi@redhat.com>
References: <1324304024-11220-1-git-send-email-avi@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.25
Cc: xen-devel@lists.xensource.com, kvm@vger.kernel.org
Subject: [Xen-devel] [PATCH 03/23] memory: add memory_region_is_ram()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Signed-off-by: Avi Kivity <avi@redhat.com>
---
 memory.c |    8 ++++++++
 memory.h |   10 ++++++++++
 2 files changed, 18 insertions(+), 0 deletions(-)

diff --git a/memory.c b/memory.c
index d8b7c27..6fd31d4 100644
--- a/memory.c
+++ b/memory.c
@@ -831,6 +831,7 @@ void memory_region_init(MemoryRegion *mr,
     mr->addr = 0;
     mr->offset = 0;
     mr->terminates = false;
+    mr->ram = false;
     mr->readable = true;
     mr->readonly = false;
     mr->destructor = memory_region_destructor_none;
@@ -997,6 +998,7 @@ void memory_region_init_ram(MemoryRegion *mr,
                             uint64_t size)
 {
     memory_region_init(mr, name, size);
+    mr->ram = true;
     mr->terminates = true;
     mr->destructor = memory_region_destructor_ram;
     mr->ram_addr = qemu_ram_alloc(dev, name, size, mr);
@@ -1010,6 +1012,7 @@ void memory_region_init_ram_ptr(MemoryRegion *mr,
                                 void *ptr)
 {
     memory_region_init(mr, name, size);
+    mr->ram = true;
     mr->terminates = true;
     mr->destructor = memory_region_destructor_ram_from_ptr;
     mr->ram_addr = qemu_ram_alloc_from_ptr(dev, name, size, ptr, mr);
@@ -1065,6 +1068,11 @@ uint64_t memory_region_size(MemoryRegion *mr)
     return int128_get64(mr->size);
 }
 
+bool memory_region_is_ram(MemoryRegion *mr)
+{
+    return mr->ram;
+}
+
 void memory_region_set_offset(MemoryRegion *mr, target_phys_addr_t offset)
 {
     mr->offset = offset;
diff --git a/memory.h b/memory.h
index 1d5c414..13f88c0 100644
--- a/memory.h
+++ b/memory.h
@@ -122,6 +122,7 @@ struct MemoryRegion {
     IORange iorange;
     bool terminates;
     bool readable;
+    bool ram;
     bool readonly; /* For RAM regions */
     MemoryRegion *alias;
     target_phys_addr_t alias_offset;
@@ -284,6 +285,15 @@ void memory_region_destroy(MemoryRegion *mr);
 uint64_t memory_region_size(MemoryRegion *mr);
 
 /**
+ * memory_region_is_ram: check whether a memory region is random access
+ *
+ * Returns %true is a memory region is random access.
+ *
+ * @mr: the memory region being queried
+ */
+bool memory_region_is_ram(MemoryRegion *mr);
+
+/**
  * memory_region_get_ram_ptr: Get a pointer into a RAM memory region.
  *
  * Returns a host pointer to a RAM memory region (created with
-- 
1.7.7.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 14:14:27 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 14:14:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rcdyq-0007HX-Gf; Mon, 19 Dec 2011 14:14:16 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <avi@redhat.com>) id 1Rcdym-0007C6-QG
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 14:14:13 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1324304045!7864112!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDY0OTI=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16990 invoked from network); 19 Dec 2011 14:14:06 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-3.tower-182.messagelabs.com with SMTP;
	19 Dec 2011 14:14:06 -0000
Received: from int-mx12.intmail.prod.int.phx2.redhat.com
	(int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id pBJEE3kp008955
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 19 Dec 2011 09:14:04 -0500
Received: from cleopatra.tlv.redhat.com (cleopatra.tlv.redhat.com
	[10.35.255.11])
	by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id pBJEE07k032288; Mon, 19 Dec 2011 09:14:03 -0500
Received: from s01.tlv.redhat.com (s01.tlv.redhat.com [10.35.255.8])
	by cleopatra.tlv.redhat.com (Postfix) with ESMTP id B37D6250BAC;
	Mon, 19 Dec 2011 16:13:54 +0200 (IST)
From: Avi Kivity <avi@redhat.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	qemu-devel@nongnu.org, "Michael S. Tsirkin" <mst@redhat.com>
Date: Mon, 19 Dec 2011 16:13:34 +0200
Message-Id: <1324304024-11220-14-git-send-email-avi@redhat.com>
In-Reply-To: <1324304024-11220-1-git-send-email-avi@redhat.com>
References: <1324304024-11220-1-git-send-email-avi@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.25
Cc: xen-devel@lists.xensource.com, kvm@vger.kernel.org
Subject: [Xen-devel] [PATCH 13/23] kvm: convert to MemoryListener API
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Drop the use of cpu_register_phys_memory_client() in favour of the new
MemoryListener API.  The new API simplifies the caller, since there is no
need to deal with splitting and merging slots; however this is not exploited
in this patch.

Signed-off-by: Avi Kivity <avi@redhat.com>
---
 kvm-all.c |  107 ++++++++++++++++++++++++++++++++++++++++---------------------
 1 files changed, 70 insertions(+), 37 deletions(-)

diff --git a/kvm-all.c b/kvm-all.c
index 4f58ae8..138e0a2 100644
--- a/kvm-all.c
+++ b/kvm-all.c
@@ -27,6 +27,7 @@
 #include "gdbstub.h"
 #include "kvm.h"
 #include "bswap.h"
+#include "memory.h"
 
 /* This check must be after config-host.h is included */
 #ifdef CONFIG_EVENTFD
@@ -289,16 +290,28 @@ static int kvm_dirty_pages_log_change(target_phys_addr_t phys_addr,
     return kvm_slot_dirty_pages_log_change(mem, log_dirty);
 }
 
-static int kvm_log_start(CPUPhysMemoryClient *client,
-                         target_phys_addr_t phys_addr, ram_addr_t size)
+static void kvm_log_start(MemoryListener *listener,
+                          MemoryRegionSection *section)
 {
-    return kvm_dirty_pages_log_change(phys_addr, size, true);
+    int r;
+
+    r = kvm_dirty_pages_log_change(section->offset_within_address_space,
+                                   section->size, true);
+    if (r < 0) {
+        abort();
+    }
 }
 
-static int kvm_log_stop(CPUPhysMemoryClient *client,
-                        target_phys_addr_t phys_addr, ram_addr_t size)
+static void kvm_log_stop(MemoryListener *listener,
+                          MemoryRegionSection *section)
 {
-    return kvm_dirty_pages_log_change(phys_addr, size, false);
+    int r;
+
+    r = kvm_dirty_pages_log_change(section->offset_within_address_space,
+                                   section->size, false);
+    if (r < 0) {
+        abort();
+    }
 }
 
 static int kvm_set_migration_log(int enable)
@@ -519,13 +532,15 @@ static int kvm_check_many_ioeventfds(void)
     return NULL;
 }
 
-static void kvm_set_phys_mem(target_phys_addr_t start_addr, ram_addr_t size,
-                             ram_addr_t phys_offset, bool log_dirty)
+static void kvm_set_phys_mem(MemoryRegionSection *section, bool add)
 {
     KVMState *s = kvm_state;
-    ram_addr_t flags = phys_offset & ~TARGET_PAGE_MASK;
     KVMSlot *mem, old;
     int err;
+    MemoryRegion *mr = section->mr;
+    bool log_dirty = memory_region_is_logging(mr);
+    target_phys_addr_t start_addr = section->offset_within_address_space;
+    ram_addr_t size = section->size;
     void *ram = NULL;
 
     /* kvm works in page size chunks, but the function may be called
@@ -533,20 +548,19 @@ static void kvm_set_phys_mem(target_phys_addr_t start_addr, ram_addr_t size,
     size = TARGET_PAGE_ALIGN(size);
     start_addr = TARGET_PAGE_ALIGN(start_addr);
 
-    /* KVM does not support read-only slots */
-    phys_offset &= ~IO_MEM_ROM;
-
-    if ((phys_offset & ~TARGET_PAGE_MASK) == IO_MEM_RAM) {
-        ram = qemu_safe_ram_ptr(phys_offset);
+    if (!memory_region_is_ram(mr)) {
+        return;
     }
 
+    ram = memory_region_get_ram_ptr(mr) + section->offset_within_region;
+
     while (1) {
         mem = kvm_lookup_overlapping_slot(s, start_addr, start_addr + size);
         if (!mem) {
             break;
         }
 
-        if (flags < IO_MEM_UNASSIGNED && start_addr >= mem->start_addr &&
+        if (add && start_addr >= mem->start_addr &&
             (start_addr + size <= mem->start_addr + mem->memory_size) &&
             (ram - start_addr == mem->ram - mem->start_addr)) {
             /* The new slot fits into the existing one and comes with
@@ -575,8 +589,7 @@ static void kvm_set_phys_mem(target_phys_addr_t start_addr, ram_addr_t size,
          * slot comes around later, we will fail (not seen in practice so far)
          * - and actually require a recent KVM version. */
         if (s->broken_set_mem_region &&
-            old.start_addr == start_addr && old.memory_size < size &&
-            flags < IO_MEM_UNASSIGNED) {
+            old.start_addr == start_addr && old.memory_size < size && add) {
             mem = kvm_alloc_slot(s);
             mem->memory_size = old.memory_size;
             mem->start_addr = old.start_addr;
@@ -591,7 +604,6 @@ static void kvm_set_phys_mem(target_phys_addr_t start_addr, ram_addr_t size,
             }
 
             start_addr += old.memory_size;
-            phys_offset += old.memory_size;
             ram += old.memory_size;
             size -= old.memory_size;
             continue;
@@ -642,8 +654,7 @@ static void kvm_set_phys_mem(target_phys_addr_t start_addr, ram_addr_t size,
     if (!size) {
         return;
     }
-    /* KVM does not need to know about this memory */
-    if (flags >= IO_MEM_UNASSIGNED) {
+    if (!add) {
         return;
     }
     mem = kvm_alloc_slot(s);
@@ -660,33 +671,55 @@ static void kvm_set_phys_mem(target_phys_addr_t start_addr, ram_addr_t size,
     }
 }
 
-static void kvm_client_set_memory(struct CPUPhysMemoryClient *client,
-                                  target_phys_addr_t start_addr,
-                                  ram_addr_t size, ram_addr_t phys_offset,
-                                  bool log_dirty)
+static void kvm_region_add(MemoryListener *listener,
+                           MemoryRegionSection *section)
+{
+    kvm_set_phys_mem(section, true);
+}
+
+static void kvm_region_del(MemoryListener *listener,
+                           MemoryRegionSection *section)
 {
-    kvm_set_phys_mem(start_addr, size, phys_offset, log_dirty);
+    kvm_set_phys_mem(section, false);
+}
+
+static void kvm_log_sync(MemoryListener *listener,
+                         MemoryRegionSection *section)
+{
+    target_phys_addr_t start = section->offset_within_address_space;
+    target_phys_addr_t end = start + section->size;
+    int r;
+
+    r = kvm_physical_sync_dirty_bitmap(start, end);
+    if (r < 0) {
+        abort();
+    }
 }
 
-static int kvm_client_sync_dirty_bitmap(struct CPUPhysMemoryClient *client,
-                                        target_phys_addr_t start_addr,
-                                        target_phys_addr_t end_addr)
+static void kvm_log_global_start(struct MemoryListener *listener)
 {
-    return kvm_physical_sync_dirty_bitmap(start_addr, end_addr);
+    int r;
+
+    r = kvm_set_migration_log(1);
+    assert(r >= 0);
 }
 
-static int kvm_client_migration_log(struct CPUPhysMemoryClient *client,
-                                    int enable)
+static void kvm_log_global_stop(struct MemoryListener *listener)
 {
-    return kvm_set_migration_log(enable);
+    int r;
+
+    r = kvm_set_migration_log(0);
+    assert(r >= 0);
 }
 
-static CPUPhysMemoryClient kvm_cpu_phys_memory_client = {
-    .set_memory = kvm_client_set_memory,
-    .sync_dirty_bitmap = kvm_client_sync_dirty_bitmap,
-    .migration_log = kvm_client_migration_log,
+static MemoryListener kvm_memory_listener = {
+    .region_add = kvm_region_add,
+    .region_del = kvm_region_del,
     .log_start = kvm_log_start,
     .log_stop = kvm_log_stop,
+    .log_sync = kvm_log_sync,
+    .log_global_start = kvm_log_global_start,
+    .log_global_stop = kvm_log_global_stop,
 };
 
 static void kvm_handle_interrupt(CPUState *env, int mask)
@@ -794,7 +827,7 @@ int kvm_init(void)
     }
 
     kvm_state = s;
-    cpu_register_phys_memory_client(&kvm_cpu_phys_memory_client);
+    memory_listener_register(&kvm_memory_listener);
 
     s->many_ioeventfds = kvm_check_many_ioeventfds();
 
-- 
1.7.7.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 14:14:27 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 14:14:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rcdyq-0007HX-Gf; Mon, 19 Dec 2011 14:14:16 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <avi@redhat.com>) id 1Rcdym-0007C6-QG
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 14:14:13 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1324304045!7864112!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDY0OTI=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16990 invoked from network); 19 Dec 2011 14:14:06 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-3.tower-182.messagelabs.com with SMTP;
	19 Dec 2011 14:14:06 -0000
Received: from int-mx12.intmail.prod.int.phx2.redhat.com
	(int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id pBJEE3kp008955
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 19 Dec 2011 09:14:04 -0500
Received: from cleopatra.tlv.redhat.com (cleopatra.tlv.redhat.com
	[10.35.255.11])
	by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id pBJEE07k032288; Mon, 19 Dec 2011 09:14:03 -0500
Received: from s01.tlv.redhat.com (s01.tlv.redhat.com [10.35.255.8])
	by cleopatra.tlv.redhat.com (Postfix) with ESMTP id B37D6250BAC;
	Mon, 19 Dec 2011 16:13:54 +0200 (IST)
From: Avi Kivity <avi@redhat.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	qemu-devel@nongnu.org, "Michael S. Tsirkin" <mst@redhat.com>
Date: Mon, 19 Dec 2011 16:13:34 +0200
Message-Id: <1324304024-11220-14-git-send-email-avi@redhat.com>
In-Reply-To: <1324304024-11220-1-git-send-email-avi@redhat.com>
References: <1324304024-11220-1-git-send-email-avi@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.25
Cc: xen-devel@lists.xensource.com, kvm@vger.kernel.org
Subject: [Xen-devel] [PATCH 13/23] kvm: convert to MemoryListener API
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Drop the use of cpu_register_phys_memory_client() in favour of the new
MemoryListener API.  The new API simplifies the caller, since there is no
need to deal with splitting and merging slots; however this is not exploited
in this patch.

Signed-off-by: Avi Kivity <avi@redhat.com>
---
 kvm-all.c |  107 ++++++++++++++++++++++++++++++++++++++++---------------------
 1 files changed, 70 insertions(+), 37 deletions(-)

diff --git a/kvm-all.c b/kvm-all.c
index 4f58ae8..138e0a2 100644
--- a/kvm-all.c
+++ b/kvm-all.c
@@ -27,6 +27,7 @@
 #include "gdbstub.h"
 #include "kvm.h"
 #include "bswap.h"
+#include "memory.h"
 
 /* This check must be after config-host.h is included */
 #ifdef CONFIG_EVENTFD
@@ -289,16 +290,28 @@ static int kvm_dirty_pages_log_change(target_phys_addr_t phys_addr,
     return kvm_slot_dirty_pages_log_change(mem, log_dirty);
 }
 
-static int kvm_log_start(CPUPhysMemoryClient *client,
-                         target_phys_addr_t phys_addr, ram_addr_t size)
+static void kvm_log_start(MemoryListener *listener,
+                          MemoryRegionSection *section)
 {
-    return kvm_dirty_pages_log_change(phys_addr, size, true);
+    int r;
+
+    r = kvm_dirty_pages_log_change(section->offset_within_address_space,
+                                   section->size, true);
+    if (r < 0) {
+        abort();
+    }
 }
 
-static int kvm_log_stop(CPUPhysMemoryClient *client,
-                        target_phys_addr_t phys_addr, ram_addr_t size)
+static void kvm_log_stop(MemoryListener *listener,
+                          MemoryRegionSection *section)
 {
-    return kvm_dirty_pages_log_change(phys_addr, size, false);
+    int r;
+
+    r = kvm_dirty_pages_log_change(section->offset_within_address_space,
+                                   section->size, false);
+    if (r < 0) {
+        abort();
+    }
 }
 
 static int kvm_set_migration_log(int enable)
@@ -519,13 +532,15 @@ static int kvm_check_many_ioeventfds(void)
     return NULL;
 }
 
-static void kvm_set_phys_mem(target_phys_addr_t start_addr, ram_addr_t size,
-                             ram_addr_t phys_offset, bool log_dirty)
+static void kvm_set_phys_mem(MemoryRegionSection *section, bool add)
 {
     KVMState *s = kvm_state;
-    ram_addr_t flags = phys_offset & ~TARGET_PAGE_MASK;
     KVMSlot *mem, old;
     int err;
+    MemoryRegion *mr = section->mr;
+    bool log_dirty = memory_region_is_logging(mr);
+    target_phys_addr_t start_addr = section->offset_within_address_space;
+    ram_addr_t size = section->size;
     void *ram = NULL;
 
     /* kvm works in page size chunks, but the function may be called
@@ -533,20 +548,19 @@ static void kvm_set_phys_mem(target_phys_addr_t start_addr, ram_addr_t size,
     size = TARGET_PAGE_ALIGN(size);
     start_addr = TARGET_PAGE_ALIGN(start_addr);
 
-    /* KVM does not support read-only slots */
-    phys_offset &= ~IO_MEM_ROM;
-
-    if ((phys_offset & ~TARGET_PAGE_MASK) == IO_MEM_RAM) {
-        ram = qemu_safe_ram_ptr(phys_offset);
+    if (!memory_region_is_ram(mr)) {
+        return;
     }
 
+    ram = memory_region_get_ram_ptr(mr) + section->offset_within_region;
+
     while (1) {
         mem = kvm_lookup_overlapping_slot(s, start_addr, start_addr + size);
         if (!mem) {
             break;
         }
 
-        if (flags < IO_MEM_UNASSIGNED && start_addr >= mem->start_addr &&
+        if (add && start_addr >= mem->start_addr &&
             (start_addr + size <= mem->start_addr + mem->memory_size) &&
             (ram - start_addr == mem->ram - mem->start_addr)) {
             /* The new slot fits into the existing one and comes with
@@ -575,8 +589,7 @@ static void kvm_set_phys_mem(target_phys_addr_t start_addr, ram_addr_t size,
          * slot comes around later, we will fail (not seen in practice so far)
          * - and actually require a recent KVM version. */
         if (s->broken_set_mem_region &&
-            old.start_addr == start_addr && old.memory_size < size &&
-            flags < IO_MEM_UNASSIGNED) {
+            old.start_addr == start_addr && old.memory_size < size && add) {
             mem = kvm_alloc_slot(s);
             mem->memory_size = old.memory_size;
             mem->start_addr = old.start_addr;
@@ -591,7 +604,6 @@ static void kvm_set_phys_mem(target_phys_addr_t start_addr, ram_addr_t size,
             }
 
             start_addr += old.memory_size;
-            phys_offset += old.memory_size;
             ram += old.memory_size;
             size -= old.memory_size;
             continue;
@@ -642,8 +654,7 @@ static void kvm_set_phys_mem(target_phys_addr_t start_addr, ram_addr_t size,
     if (!size) {
         return;
     }
-    /* KVM does not need to know about this memory */
-    if (flags >= IO_MEM_UNASSIGNED) {
+    if (!add) {
         return;
     }
     mem = kvm_alloc_slot(s);
@@ -660,33 +671,55 @@ static void kvm_set_phys_mem(target_phys_addr_t start_addr, ram_addr_t size,
     }
 }
 
-static void kvm_client_set_memory(struct CPUPhysMemoryClient *client,
-                                  target_phys_addr_t start_addr,
-                                  ram_addr_t size, ram_addr_t phys_offset,
-                                  bool log_dirty)
+static void kvm_region_add(MemoryListener *listener,
+                           MemoryRegionSection *section)
+{
+    kvm_set_phys_mem(section, true);
+}
+
+static void kvm_region_del(MemoryListener *listener,
+                           MemoryRegionSection *section)
 {
-    kvm_set_phys_mem(start_addr, size, phys_offset, log_dirty);
+    kvm_set_phys_mem(section, false);
+}
+
+static void kvm_log_sync(MemoryListener *listener,
+                         MemoryRegionSection *section)
+{
+    target_phys_addr_t start = section->offset_within_address_space;
+    target_phys_addr_t end = start + section->size;
+    int r;
+
+    r = kvm_physical_sync_dirty_bitmap(start, end);
+    if (r < 0) {
+        abort();
+    }
 }
 
-static int kvm_client_sync_dirty_bitmap(struct CPUPhysMemoryClient *client,
-                                        target_phys_addr_t start_addr,
-                                        target_phys_addr_t end_addr)
+static void kvm_log_global_start(struct MemoryListener *listener)
 {
-    return kvm_physical_sync_dirty_bitmap(start_addr, end_addr);
+    int r;
+
+    r = kvm_set_migration_log(1);
+    assert(r >= 0);
 }
 
-static int kvm_client_migration_log(struct CPUPhysMemoryClient *client,
-                                    int enable)
+static void kvm_log_global_stop(struct MemoryListener *listener)
 {
-    return kvm_set_migration_log(enable);
+    int r;
+
+    r = kvm_set_migration_log(0);
+    assert(r >= 0);
 }
 
-static CPUPhysMemoryClient kvm_cpu_phys_memory_client = {
-    .set_memory = kvm_client_set_memory,
-    .sync_dirty_bitmap = kvm_client_sync_dirty_bitmap,
-    .migration_log = kvm_client_migration_log,
+static MemoryListener kvm_memory_listener = {
+    .region_add = kvm_region_add,
+    .region_del = kvm_region_del,
     .log_start = kvm_log_start,
     .log_stop = kvm_log_stop,
+    .log_sync = kvm_log_sync,
+    .log_global_start = kvm_log_global_start,
+    .log_global_stop = kvm_log_global_stop,
 };
 
 static void kvm_handle_interrupt(CPUState *env, int mask)
@@ -794,7 +827,7 @@ int kvm_init(void)
     }
 
     kvm_state = s;
-    cpu_register_phys_memory_client(&kvm_cpu_phys_memory_client);
+    memory_listener_register(&kvm_memory_listener);
 
     s->many_ioeventfds = kvm_check_many_ioeventfds();
 
-- 
1.7.7.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 14:14:27 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 14:14:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rcdys-0007Jt-SF; Mon, 19 Dec 2011 14:14:18 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <avi@redhat.com>) id 1Rcdyo-0007Cj-Qb
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 14:14:15 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1324304048!6066920!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDY0OTI=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14470 invoked from network); 19 Dec 2011 14:14:08 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-3.tower-174.messagelabs.com with SMTP;
	19 Dec 2011 14:14:08 -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 pBJEE6qK008977
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 19 Dec 2011 09:14:06 -0500
Received: from cleopatra.tlv.redhat.com (cleopatra.tlv.redhat.com
	[10.35.255.11])
	by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id pBJEE59a007015; Mon, 19 Dec 2011 09:14:05 -0500
Received: from s01.tlv.redhat.com (s01.tlv.redhat.com [10.35.255.8])
	by cleopatra.tlv.redhat.com (Postfix) with ESMTP id CDCBD250BB6;
	Mon, 19 Dec 2011 16:13:54 +0200 (IST)
From: Avi Kivity <avi@redhat.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	qemu-devel@nongnu.org, "Michael S. Tsirkin" <mst@redhat.com>
Date: Mon, 19 Dec 2011 16:13:44 +0200
Message-Id: <1324304024-11220-24-git-send-email-avi@redhat.com>
In-Reply-To: <1324304024-11220-1-git-send-email-avi@redhat.com>
References: <1324304024-11220-1-git-send-email-avi@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
Cc: xen-devel@lists.xensource.com, kvm@vger.kernel.org
Subject: [Xen-devel] [PATCH 23/23] Remove cpu_get_physical_page_desc()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

No longer used.

Signed-off-by: Avi Kivity <avi@redhat.com>
---
 cpu-common.h |    1 -
 exec.c       |   11 -----------
 2 files changed, 0 insertions(+), 12 deletions(-)

diff --git a/cpu-common.h b/cpu-common.h
index eee2faf..3fe44d2 100644
--- a/cpu-common.h
+++ b/cpu-common.h
@@ -38,7 +38,6 @@ typedef unsigned long ram_addr_t;
 typedef void CPUWriteMemoryFunc(void *opaque, target_phys_addr_t addr, uint32_t value);
 typedef uint32_t CPUReadMemoryFunc(void *opaque, target_phys_addr_t addr);
 
-ram_addr_t cpu_get_physical_page_desc(target_phys_addr_t addr);
 void qemu_ram_remap(ram_addr_t addr, ram_addr_t length);
 /* This should only be used for ram local to a device.  */
 void *qemu_get_ram_ptr(ram_addr_t addr);
diff --git a/exec.c b/exec.c
index e1f7462..b02199b 100644
--- a/exec.c
+++ b/exec.c
@@ -2595,17 +2595,6 @@ void cpu_register_physical_memory_log(target_phys_addr_t start_addr,
     }
 }
 
-/* XXX: temporary until new memory mapping API */
-ram_addr_t cpu_get_physical_page_desc(target_phys_addr_t addr)
-{
-    PhysPageDesc *p;
-
-    p = phys_page_find(addr >> TARGET_PAGE_BITS);
-    if (!p)
-        return IO_MEM_UNASSIGNED;
-    return p->phys_offset;
-}
-
 void qemu_register_coalesced_mmio(target_phys_addr_t addr, ram_addr_t size)
 {
     if (kvm_enabled())
-- 
1.7.7.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 14:14:27 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 14:14:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rcdys-0007Jt-SF; Mon, 19 Dec 2011 14:14:18 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <avi@redhat.com>) id 1Rcdyo-0007Cj-Qb
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 14:14:15 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1324304048!6066920!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDY0OTI=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14470 invoked from network); 19 Dec 2011 14:14:08 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-3.tower-174.messagelabs.com with SMTP;
	19 Dec 2011 14:14:08 -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 pBJEE6qK008977
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 19 Dec 2011 09:14:06 -0500
Received: from cleopatra.tlv.redhat.com (cleopatra.tlv.redhat.com
	[10.35.255.11])
	by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id pBJEE59a007015; Mon, 19 Dec 2011 09:14:05 -0500
Received: from s01.tlv.redhat.com (s01.tlv.redhat.com [10.35.255.8])
	by cleopatra.tlv.redhat.com (Postfix) with ESMTP id CDCBD250BB6;
	Mon, 19 Dec 2011 16:13:54 +0200 (IST)
From: Avi Kivity <avi@redhat.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	qemu-devel@nongnu.org, "Michael S. Tsirkin" <mst@redhat.com>
Date: Mon, 19 Dec 2011 16:13:44 +0200
Message-Id: <1324304024-11220-24-git-send-email-avi@redhat.com>
In-Reply-To: <1324304024-11220-1-git-send-email-avi@redhat.com>
References: <1324304024-11220-1-git-send-email-avi@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
Cc: xen-devel@lists.xensource.com, kvm@vger.kernel.org
Subject: [Xen-devel] [PATCH 23/23] Remove cpu_get_physical_page_desc()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

No longer used.

Signed-off-by: Avi Kivity <avi@redhat.com>
---
 cpu-common.h |    1 -
 exec.c       |   11 -----------
 2 files changed, 0 insertions(+), 12 deletions(-)

diff --git a/cpu-common.h b/cpu-common.h
index eee2faf..3fe44d2 100644
--- a/cpu-common.h
+++ b/cpu-common.h
@@ -38,7 +38,6 @@ typedef unsigned long ram_addr_t;
 typedef void CPUWriteMemoryFunc(void *opaque, target_phys_addr_t addr, uint32_t value);
 typedef uint32_t CPUReadMemoryFunc(void *opaque, target_phys_addr_t addr);
 
-ram_addr_t cpu_get_physical_page_desc(target_phys_addr_t addr);
 void qemu_ram_remap(ram_addr_t addr, ram_addr_t length);
 /* This should only be used for ram local to a device.  */
 void *qemu_get_ram_ptr(ram_addr_t addr);
diff --git a/exec.c b/exec.c
index e1f7462..b02199b 100644
--- a/exec.c
+++ b/exec.c
@@ -2595,17 +2595,6 @@ void cpu_register_physical_memory_log(target_phys_addr_t start_addr,
     }
 }
 
-/* XXX: temporary until new memory mapping API */
-ram_addr_t cpu_get_physical_page_desc(target_phys_addr_t addr)
-{
-    PhysPageDesc *p;
-
-    p = phys_page_find(addr >> TARGET_PAGE_BITS);
-    if (!p)
-        return IO_MEM_UNASSIGNED;
-    return p->phys_offset;
-}
-
 void qemu_register_coalesced_mmio(target_phys_addr_t addr, ram_addr_t size)
 {
     if (kvm_enabled())
-- 
1.7.7.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 14:14:27 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 14:14:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rcdyr-0007IA-AZ; Mon, 19 Dec 2011 14:14:17 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <avi@redhat.com>) id 1Rcdyn-0007CN-Rc
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 14:14:14 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1324304046!6138635!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDY0OTI=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13613 invoked from network); 19 Dec 2011 14:14:07 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-5.tower-174.messagelabs.com with SMTP;
	19 Dec 2011 14:14:07 -0000
Received: from int-mx01.intmail.prod.int.phx2.redhat.com
	(int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id pBJEE5QZ012055
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 19 Dec 2011 09:14:05 -0500
Received: from cleopatra.tlv.redhat.com (cleopatra.tlv.redhat.com
	[10.35.255.11])
	by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP
	id pBJEE0NB009673; Mon, 19 Dec 2011 09:14:04 -0500
Received: from s01.tlv.redhat.com (s01.tlv.redhat.com [10.35.255.8])
	by cleopatra.tlv.redhat.com (Postfix) with ESMTP id C0CE7250BB2;
	Mon, 19 Dec 2011 16:13:54 +0200 (IST)
From: Avi Kivity <avi@redhat.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	qemu-devel@nongnu.org, "Michael S. Tsirkin" <mst@redhat.com>
Date: Mon, 19 Dec 2011 16:13:40 +0200
Message-Id: <1324304024-11220-20-git-send-email-avi@redhat.com>
In-Reply-To: <1324304024-11220-1-git-send-email-avi@redhat.com>
References: <1324304024-11220-1-git-send-email-avi@redhat.com>
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.11
Cc: xen-devel@lists.xensource.com, kvm@vger.kernel.org
Subject: [Xen-devel] [PATCH 19/23] kvm: avoid cpu_get_physical_page_desc()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This reaches into the innards of the memory core, which are being
changed.  Switch to a memory API version.

Signed-off-by: Avi Kivity <avi@redhat.com>
---
 kvm-all.c |   27 ++++++++++-----------------
 1 files changed, 10 insertions(+), 17 deletions(-)

diff --git a/kvm-all.c b/kvm-all.c
index 138e0a2..d94710c 100644
--- a/kvm-all.c
+++ b/kvm-all.c
@@ -340,16 +340,12 @@ static int kvm_set_migration_log(int enable)
 }
 
 /* get kvm's dirty pages bitmap and update qemu's */
-static int kvm_get_dirty_pages_log_range(unsigned long start_addr,
-                                         unsigned long *bitmap,
-                                         unsigned long offset,
-                                         unsigned long mem_size)
+static int kvm_get_dirty_pages_log_range(MemoryRegionSection *section,
+                                         unsigned long *bitmap)
 {
     unsigned int i, j;
     unsigned long page_number, addr, addr1, c;
-    ram_addr_t ram_addr;
-    unsigned int len = ((mem_size / TARGET_PAGE_SIZE) + HOST_LONG_BITS - 1) /
-        HOST_LONG_BITS;
+    unsigned int len = ((section->size / TARGET_PAGE_SIZE) + HOST_LONG_BITS - 1) / HOST_LONG_BITS;
 
     /*
      * bitmap-traveling is faster than memory-traveling (for addr...)
@@ -363,9 +359,8 @@ static int kvm_get_dirty_pages_log_range(unsigned long start_addr,
                 c &= ~(1ul << j);
                 page_number = i * HOST_LONG_BITS + j;
                 addr1 = page_number * TARGET_PAGE_SIZE;
-                addr = offset + addr1;
-                ram_addr = cpu_get_physical_page_desc(addr);
-                cpu_physical_memory_set_dirty(ram_addr);
+                addr = section->offset_within_region + addr1;
+                memory_region_set_dirty(section->mr, addr);
             } while (c != 0);
         }
     }
@@ -382,14 +377,15 @@ static int kvm_get_dirty_pages_log_range(unsigned long start_addr,
  * @start_add: start of logged region.
  * @end_addr: end of logged region.
  */
-static int kvm_physical_sync_dirty_bitmap(target_phys_addr_t start_addr,
-                                          target_phys_addr_t end_addr)
+static int kvm_physical_sync_dirty_bitmap(MemoryRegionSection *section)
 {
     KVMState *s = kvm_state;
     unsigned long size, allocated_size = 0;
     KVMDirtyLog d;
     KVMSlot *mem;
     int ret = 0;
+    target_phys_addr_t start_addr = section->offset_within_address_space;
+    target_phys_addr_t end_addr = start_addr + section->size;
 
     d.dirty_bitmap = NULL;
     while (start_addr < end_addr) {
@@ -428,8 +424,7 @@ static int kvm_physical_sync_dirty_bitmap(target_phys_addr_t start_addr,
             break;
         }
 
-        kvm_get_dirty_pages_log_range(mem->start_addr, d.dirty_bitmap,
-                                      mem->start_addr, mem->memory_size);
+        kvm_get_dirty_pages_log_range(section, d.dirty_bitmap);
         start_addr = mem->start_addr + mem->memory_size;
     }
     g_free(d.dirty_bitmap);
@@ -686,11 +681,9 @@ static void kvm_region_del(MemoryListener *listener,
 static void kvm_log_sync(MemoryListener *listener,
                          MemoryRegionSection *section)
 {
-    target_phys_addr_t start = section->offset_within_address_space;
-    target_phys_addr_t end = start + section->size;
     int r;
 
-    r = kvm_physical_sync_dirty_bitmap(start, end);
+    r = kvm_physical_sync_dirty_bitmap(section);
     if (r < 0) {
         abort();
     }
-- 
1.7.7.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 14:14:27 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 14:14:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rcdyr-0007IA-AZ; Mon, 19 Dec 2011 14:14:17 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <avi@redhat.com>) id 1Rcdyn-0007CN-Rc
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 14:14:14 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1324304046!6138635!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDY0OTI=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13613 invoked from network); 19 Dec 2011 14:14:07 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-5.tower-174.messagelabs.com with SMTP;
	19 Dec 2011 14:14:07 -0000
Received: from int-mx01.intmail.prod.int.phx2.redhat.com
	(int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id pBJEE5QZ012055
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 19 Dec 2011 09:14:05 -0500
Received: from cleopatra.tlv.redhat.com (cleopatra.tlv.redhat.com
	[10.35.255.11])
	by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP
	id pBJEE0NB009673; Mon, 19 Dec 2011 09:14:04 -0500
Received: from s01.tlv.redhat.com (s01.tlv.redhat.com [10.35.255.8])
	by cleopatra.tlv.redhat.com (Postfix) with ESMTP id C0CE7250BB2;
	Mon, 19 Dec 2011 16:13:54 +0200 (IST)
From: Avi Kivity <avi@redhat.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	qemu-devel@nongnu.org, "Michael S. Tsirkin" <mst@redhat.com>
Date: Mon, 19 Dec 2011 16:13:40 +0200
Message-Id: <1324304024-11220-20-git-send-email-avi@redhat.com>
In-Reply-To: <1324304024-11220-1-git-send-email-avi@redhat.com>
References: <1324304024-11220-1-git-send-email-avi@redhat.com>
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.11
Cc: xen-devel@lists.xensource.com, kvm@vger.kernel.org
Subject: [Xen-devel] [PATCH 19/23] kvm: avoid cpu_get_physical_page_desc()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This reaches into the innards of the memory core, which are being
changed.  Switch to a memory API version.

Signed-off-by: Avi Kivity <avi@redhat.com>
---
 kvm-all.c |   27 ++++++++++-----------------
 1 files changed, 10 insertions(+), 17 deletions(-)

diff --git a/kvm-all.c b/kvm-all.c
index 138e0a2..d94710c 100644
--- a/kvm-all.c
+++ b/kvm-all.c
@@ -340,16 +340,12 @@ static int kvm_set_migration_log(int enable)
 }
 
 /* get kvm's dirty pages bitmap and update qemu's */
-static int kvm_get_dirty_pages_log_range(unsigned long start_addr,
-                                         unsigned long *bitmap,
-                                         unsigned long offset,
-                                         unsigned long mem_size)
+static int kvm_get_dirty_pages_log_range(MemoryRegionSection *section,
+                                         unsigned long *bitmap)
 {
     unsigned int i, j;
     unsigned long page_number, addr, addr1, c;
-    ram_addr_t ram_addr;
-    unsigned int len = ((mem_size / TARGET_PAGE_SIZE) + HOST_LONG_BITS - 1) /
-        HOST_LONG_BITS;
+    unsigned int len = ((section->size / TARGET_PAGE_SIZE) + HOST_LONG_BITS - 1) / HOST_LONG_BITS;
 
     /*
      * bitmap-traveling is faster than memory-traveling (for addr...)
@@ -363,9 +359,8 @@ static int kvm_get_dirty_pages_log_range(unsigned long start_addr,
                 c &= ~(1ul << j);
                 page_number = i * HOST_LONG_BITS + j;
                 addr1 = page_number * TARGET_PAGE_SIZE;
-                addr = offset + addr1;
-                ram_addr = cpu_get_physical_page_desc(addr);
-                cpu_physical_memory_set_dirty(ram_addr);
+                addr = section->offset_within_region + addr1;
+                memory_region_set_dirty(section->mr, addr);
             } while (c != 0);
         }
     }
@@ -382,14 +377,15 @@ static int kvm_get_dirty_pages_log_range(unsigned long start_addr,
  * @start_add: start of logged region.
  * @end_addr: end of logged region.
  */
-static int kvm_physical_sync_dirty_bitmap(target_phys_addr_t start_addr,
-                                          target_phys_addr_t end_addr)
+static int kvm_physical_sync_dirty_bitmap(MemoryRegionSection *section)
 {
     KVMState *s = kvm_state;
     unsigned long size, allocated_size = 0;
     KVMDirtyLog d;
     KVMSlot *mem;
     int ret = 0;
+    target_phys_addr_t start_addr = section->offset_within_address_space;
+    target_phys_addr_t end_addr = start_addr + section->size;
 
     d.dirty_bitmap = NULL;
     while (start_addr < end_addr) {
@@ -428,8 +424,7 @@ static int kvm_physical_sync_dirty_bitmap(target_phys_addr_t start_addr,
             break;
         }
 
-        kvm_get_dirty_pages_log_range(mem->start_addr, d.dirty_bitmap,
-                                      mem->start_addr, mem->memory_size);
+        kvm_get_dirty_pages_log_range(section, d.dirty_bitmap);
         start_addr = mem->start_addr + mem->memory_size;
     }
     g_free(d.dirty_bitmap);
@@ -686,11 +681,9 @@ static void kvm_region_del(MemoryListener *listener,
 static void kvm_log_sync(MemoryListener *listener,
                          MemoryRegionSection *section)
 {
-    target_phys_addr_t start = section->offset_within_address_space;
-    target_phys_addr_t end = start + section->size;
     int r;
 
-    r = kvm_physical_sync_dirty_bitmap(start, end);
+    r = kvm_physical_sync_dirty_bitmap(section);
     if (r < 0) {
         abort();
     }
-- 
1.7.7.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 14:14:27 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 14:14:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rcdyn-0007ER-18; Mon, 19 Dec 2011 14:14:13 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <avi@redhat.com>) id 1Rcdyl-0007Bx-5h
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 14:14:11 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1324304043!7924872!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDY0OTI=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13311 invoked from network); 19 Dec 2011 14:14:04 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-10.tower-216.messagelabs.com with SMTP;
	19 Dec 2011 14:14:04 -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 pBJEE16t012031
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 19 Dec 2011 09:14:01 -0500
Received: from cleopatra.tlv.redhat.com (cleopatra.tlv.redhat.com
	[10.35.255.11])
	by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id pBJEE0hC006981; Mon, 19 Dec 2011 09:14:01 -0500
Received: from s01.tlv.redhat.com (s01.tlv.redhat.com [10.35.255.8])
	by cleopatra.tlv.redhat.com (Postfix) with ESMTP id 9D3D6250BA3;
	Mon, 19 Dec 2011 16:13:54 +0200 (IST)
From: Avi Kivity <avi@redhat.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	qemu-devel@nongnu.org, "Michael S. Tsirkin" <mst@redhat.com>
Date: Mon, 19 Dec 2011 16:13:25 +0200
Message-Id: <1324304024-11220-5-git-send-email-avi@redhat.com>
In-Reply-To: <1324304024-11220-1-git-send-email-avi@redhat.com>
References: <1324304024-11220-1-git-send-email-avi@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
Cc: xen-devel@lists.xensource.com, kvm@vger.kernel.org
Subject: [Xen-devel] [PATCH 04/23] framebuffer: drop use of
	cpu_get_physical_page_desc()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

cpu_get_physical_page_desc() is tied into the memory core's
innards, replace it with uses of the API.

Signed-off-by: Avi Kivity <avi@redhat.com>
---
 hw/framebuffer.c     |   30 +++++++++++++-----------------
 hw/framebuffer.h     |    3 +++
 hw/milkymist-vgafb.c |    2 +-
 hw/omap_lcdc.c       |    4 +++-
 hw/pl110.c           |    2 +-
 hw/pxa2xx_lcd.c      |   10 ++++++----
 6 files changed, 27 insertions(+), 24 deletions(-)

diff --git a/hw/framebuffer.c b/hw/framebuffer.c
index 56cf16e..3f4e773 100644
--- a/hw/framebuffer.c
+++ b/hw/framebuffer.c
@@ -22,6 +22,7 @@
    
 void framebuffer_update_display(
     DisplayState *ds,
+    MemoryRegion *address_space,
     target_phys_addr_t base,
     int cols, /* Width in pixels.  */
     int rows, /* Leight in pixels.  */
@@ -42,27 +43,21 @@ void framebuffer_update_display(
     int dirty;
     int i;
     ram_addr_t addr;
-    ram_addr_t pd;
-    ram_addr_t pd2;
+    MemoryRegionSection mem_section;
+    MemoryRegion *mem;
 
     i = *first_row;
     *first_row = -1;
     src_len = src_width * rows;
 
     cpu_physical_sync_dirty_bitmap(base, base + src_len);
-    pd = cpu_get_physical_page_desc(base);
-    pd2 = cpu_get_physical_page_desc(base + src_len - 1);
-    /* We should reall check that this is a continuous ram region.
-       Instead we just check that the first and last pages are
-       both ram, and the right distance apart.  */
-    if ((pd & ~TARGET_PAGE_MASK) > IO_MEM_ROM
-        || (pd2 & ~TARGET_PAGE_MASK) > IO_MEM_ROM) {
-        return;
-    }
-    pd = (pd & TARGET_PAGE_MASK) + (base & ~TARGET_PAGE_MASK);
-    if (((pd + src_len - 1) & TARGET_PAGE_MASK) != (pd2 & TARGET_PAGE_MASK)) {
+    mem_section = memory_region_find(address_space, base, src_len);
+    if (mem_section.size != src_len || !memory_region_is_ram(mem_section.mr)) {
         return;
     }
+    mem = mem_section.mr;
+    assert(mem);
+    assert(mem_section.offset_within_address_space == base);
 
     src_base = cpu_physical_memory_map(base, &src_len, 0);
     /* If we can't map the framebuffer then bail.  We could try harder,
@@ -82,7 +77,7 @@ void framebuffer_update_display(
         dest -= dest_row_pitch * (rows - 1);
     }
     first = -1;
-    addr = pd;
+    addr = mem_section.offset_within_region;
 
     addr += i * src_width;
     src += i * src_width;
@@ -93,8 +88,8 @@ void framebuffer_update_display(
         dirty = 0;
         dirty_offset = 0;
         while (addr + dirty_offset < TARGET_PAGE_ALIGN(addr + src_width)) {
-            dirty |= cpu_physical_memory_get_dirty(addr + dirty_offset,
-                                                   VGA_DIRTY_FLAG);
+            dirty |= memory_region_get_dirty(mem, addr + dirty_offset,
+                                             DIRTY_MEMORY_VGA);
             dirty_offset += TARGET_PAGE_SIZE;
         }
 
@@ -112,7 +107,8 @@ void framebuffer_update_display(
     if (first < 0) {
         return;
     }
-    cpu_physical_memory_reset_dirty(pd, pd + src_len, VGA_DIRTY_FLAG);
+    memory_region_reset_dirty(mem, mem_section.offset_within_region, src_len,
+                              DIRTY_MEMORY_VGA);
     *first_row = first;
     *last_row = last;
     return;
diff --git a/hw/framebuffer.h b/hw/framebuffer.h
index a3a2146..527a6b8 100644
--- a/hw/framebuffer.h
+++ b/hw/framebuffer.h
@@ -1,12 +1,15 @@
 #ifndef QEMU_FRAMEBUFFER_H
 #define QEMU_FRAMEBUFFER_H
 
+#include "memory.h"
+
 /* Framebuffer device helper routines.  */
 
 typedef void (*drawfn)(void *, uint8_t *, const uint8_t *, int, int);
 
 void framebuffer_update_display(
     DisplayState *ds,
+    MemoryRegion *address_space,
     target_phys_addr_t base,
     int cols,
     int rows,
diff --git a/hw/milkymist-vgafb.c b/hw/milkymist-vgafb.c
index 01cd309..108115e 100644
--- a/hw/milkymist-vgafb.c
+++ b/hw/milkymist-vgafb.c
@@ -120,7 +120,7 @@ static void vgafb_update_display(void *opaque)
         break;
     }
 
-    framebuffer_update_display(s->ds,
+    framebuffer_update_display(s->ds, sysbus_address_space(&s->busdev),
                                s->regs[R_BASEADDRESS] + s->fb_offset,
                                s->regs[R_HRES],
                                s->regs[R_VRES],
diff --git a/hw/omap_lcdc.c b/hw/omap_lcdc.c
index 8484f70..f265306 100644
--- a/hw/omap_lcdc.c
+++ b/hw/omap_lcdc.c
@@ -22,6 +22,7 @@
 #include "framebuffer.h"
 
 struct omap_lcd_panel_s {
+    MemoryRegion *sysmem;
     MemoryRegion iomem;
     qemu_irq irq;
     DisplayState *state;
@@ -211,7 +212,7 @@ static void omap_update_display(void *opaque)
 
     step = width * bpp >> 3;
     linesize = ds_get_linesize(omap_lcd->state);
-    framebuffer_update_display(omap_lcd->state,
+    framebuffer_update_display(omap_lcd->state, omap_lcd->sysmem,
                                frame_base, width, height,
                                step, linesize, 0,
                                omap_lcd->invalidate,
@@ -440,6 +441,7 @@ struct omap_lcd_panel_s *omap_lcdc_init(MemoryRegion *sysmem,
 
     s->irq = irq;
     s->dma = dma;
+    s->sysmem = sysmem;
     omap_lcdc_reset(s);
 
     memory_region_init_io(&s->iomem, &omap_lcdc_ops, s, "omap.lcdc", 0x100);
diff --git a/hw/pl110.c b/hw/pl110.c
index cc1eb6d..303a9bc 100644
--- a/hw/pl110.c
+++ b/hw/pl110.c
@@ -229,7 +229,7 @@ static void pl110_update_display(void *opaque)
     }
     dest_width *= s->cols;
     first = 0;
-    framebuffer_update_display(s->ds,
+    framebuffer_update_display(s->ds, sysbus_address_space(&s->busdev),
                                s->upbase, s->cols, s->rows,
                                src_width, dest_width, 0,
                                s->invalidate,
diff --git a/hw/pxa2xx_lcd.c b/hw/pxa2xx_lcd.c
index fd23d63..5dd4ef0 100644
--- a/hw/pxa2xx_lcd.c
+++ b/hw/pxa2xx_lcd.c
@@ -30,6 +30,7 @@ struct DMAChannel {
 };
 
 struct PXA2xxLCDState {
+    MemoryRegion *sysmem;
     MemoryRegion iomem;
     qemu_irq irq;
     int irqlevel;
@@ -681,7 +682,7 @@ static void pxa2xx_lcdc_dma0_redraw_rot0(PXA2xxLCDState *s,
 
     dest_width = s->xres * s->dest_width;
     *miny = 0;
-    framebuffer_update_display(s->ds,
+    framebuffer_update_display(s->ds, s->sysmem,
                                addr, s->xres, s->yres,
                                src_width, dest_width, s->dest_width,
                                s->invalidated,
@@ -708,7 +709,7 @@ static void pxa2xx_lcdc_dma0_redraw_rot90(PXA2xxLCDState *s,
 
     dest_width = s->yres * s->dest_width;
     *miny = 0;
-    framebuffer_update_display(s->ds,
+    framebuffer_update_display(s->ds, s->sysmem,
                                addr, s->xres, s->yres,
                                src_width, s->dest_width, -dest_width,
                                s->invalidated,
@@ -739,7 +740,7 @@ static void pxa2xx_lcdc_dma0_redraw_rot180(PXA2xxLCDState *s,
 
     dest_width = s->xres * s->dest_width;
     *miny = 0;
-    framebuffer_update_display(s->ds,
+    framebuffer_update_display(s->ds, s->sysmem,
                                addr, s->xres, s->yres,
                                src_width, -dest_width, -s->dest_width,
                                s->invalidated,
@@ -769,7 +770,7 @@ static void pxa2xx_lcdc_dma0_redraw_rot270(PXA2xxLCDState *s,
 
     dest_width = s->yres * s->dest_width;
     *miny = 0;
-    framebuffer_update_display(s->ds,
+    framebuffer_update_display(s->ds, s->sysmem,
                                addr, s->xres, s->yres,
                                src_width, -s->dest_width, dest_width,
                                s->invalidated,
@@ -985,6 +986,7 @@ static int pxa2xx_lcdc_post_load(void *opaque, int version_id)
     s = (PXA2xxLCDState *) g_malloc0(sizeof(PXA2xxLCDState));
     s->invalidated = 1;
     s->irq = irq;
+    s->sysmem = sysmem;
 
     pxa2xx_lcdc_orientation(s, graphic_rotate);
 
-- 
1.7.7.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 14:14:27 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 14:14:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rcdyn-0007ER-18; Mon, 19 Dec 2011 14:14:13 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <avi@redhat.com>) id 1Rcdyl-0007Bx-5h
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 14:14:11 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1324304043!7924872!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDY0OTI=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13311 invoked from network); 19 Dec 2011 14:14:04 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-10.tower-216.messagelabs.com with SMTP;
	19 Dec 2011 14:14:04 -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 pBJEE16t012031
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 19 Dec 2011 09:14:01 -0500
Received: from cleopatra.tlv.redhat.com (cleopatra.tlv.redhat.com
	[10.35.255.11])
	by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id pBJEE0hC006981; Mon, 19 Dec 2011 09:14:01 -0500
Received: from s01.tlv.redhat.com (s01.tlv.redhat.com [10.35.255.8])
	by cleopatra.tlv.redhat.com (Postfix) with ESMTP id 9D3D6250BA3;
	Mon, 19 Dec 2011 16:13:54 +0200 (IST)
From: Avi Kivity <avi@redhat.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	qemu-devel@nongnu.org, "Michael S. Tsirkin" <mst@redhat.com>
Date: Mon, 19 Dec 2011 16:13:25 +0200
Message-Id: <1324304024-11220-5-git-send-email-avi@redhat.com>
In-Reply-To: <1324304024-11220-1-git-send-email-avi@redhat.com>
References: <1324304024-11220-1-git-send-email-avi@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
Cc: xen-devel@lists.xensource.com, kvm@vger.kernel.org
Subject: [Xen-devel] [PATCH 04/23] framebuffer: drop use of
	cpu_get_physical_page_desc()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

cpu_get_physical_page_desc() is tied into the memory core's
innards, replace it with uses of the API.

Signed-off-by: Avi Kivity <avi@redhat.com>
---
 hw/framebuffer.c     |   30 +++++++++++++-----------------
 hw/framebuffer.h     |    3 +++
 hw/milkymist-vgafb.c |    2 +-
 hw/omap_lcdc.c       |    4 +++-
 hw/pl110.c           |    2 +-
 hw/pxa2xx_lcd.c      |   10 ++++++----
 6 files changed, 27 insertions(+), 24 deletions(-)

diff --git a/hw/framebuffer.c b/hw/framebuffer.c
index 56cf16e..3f4e773 100644
--- a/hw/framebuffer.c
+++ b/hw/framebuffer.c
@@ -22,6 +22,7 @@
    
 void framebuffer_update_display(
     DisplayState *ds,
+    MemoryRegion *address_space,
     target_phys_addr_t base,
     int cols, /* Width in pixels.  */
     int rows, /* Leight in pixels.  */
@@ -42,27 +43,21 @@ void framebuffer_update_display(
     int dirty;
     int i;
     ram_addr_t addr;
-    ram_addr_t pd;
-    ram_addr_t pd2;
+    MemoryRegionSection mem_section;
+    MemoryRegion *mem;
 
     i = *first_row;
     *first_row = -1;
     src_len = src_width * rows;
 
     cpu_physical_sync_dirty_bitmap(base, base + src_len);
-    pd = cpu_get_physical_page_desc(base);
-    pd2 = cpu_get_physical_page_desc(base + src_len - 1);
-    /* We should reall check that this is a continuous ram region.
-       Instead we just check that the first and last pages are
-       both ram, and the right distance apart.  */
-    if ((pd & ~TARGET_PAGE_MASK) > IO_MEM_ROM
-        || (pd2 & ~TARGET_PAGE_MASK) > IO_MEM_ROM) {
-        return;
-    }
-    pd = (pd & TARGET_PAGE_MASK) + (base & ~TARGET_PAGE_MASK);
-    if (((pd + src_len - 1) & TARGET_PAGE_MASK) != (pd2 & TARGET_PAGE_MASK)) {
+    mem_section = memory_region_find(address_space, base, src_len);
+    if (mem_section.size != src_len || !memory_region_is_ram(mem_section.mr)) {
         return;
     }
+    mem = mem_section.mr;
+    assert(mem);
+    assert(mem_section.offset_within_address_space == base);
 
     src_base = cpu_physical_memory_map(base, &src_len, 0);
     /* If we can't map the framebuffer then bail.  We could try harder,
@@ -82,7 +77,7 @@ void framebuffer_update_display(
         dest -= dest_row_pitch * (rows - 1);
     }
     first = -1;
-    addr = pd;
+    addr = mem_section.offset_within_region;
 
     addr += i * src_width;
     src += i * src_width;
@@ -93,8 +88,8 @@ void framebuffer_update_display(
         dirty = 0;
         dirty_offset = 0;
         while (addr + dirty_offset < TARGET_PAGE_ALIGN(addr + src_width)) {
-            dirty |= cpu_physical_memory_get_dirty(addr + dirty_offset,
-                                                   VGA_DIRTY_FLAG);
+            dirty |= memory_region_get_dirty(mem, addr + dirty_offset,
+                                             DIRTY_MEMORY_VGA);
             dirty_offset += TARGET_PAGE_SIZE;
         }
 
@@ -112,7 +107,8 @@ void framebuffer_update_display(
     if (first < 0) {
         return;
     }
-    cpu_physical_memory_reset_dirty(pd, pd + src_len, VGA_DIRTY_FLAG);
+    memory_region_reset_dirty(mem, mem_section.offset_within_region, src_len,
+                              DIRTY_MEMORY_VGA);
     *first_row = first;
     *last_row = last;
     return;
diff --git a/hw/framebuffer.h b/hw/framebuffer.h
index a3a2146..527a6b8 100644
--- a/hw/framebuffer.h
+++ b/hw/framebuffer.h
@@ -1,12 +1,15 @@
 #ifndef QEMU_FRAMEBUFFER_H
 #define QEMU_FRAMEBUFFER_H
 
+#include "memory.h"
+
 /* Framebuffer device helper routines.  */
 
 typedef void (*drawfn)(void *, uint8_t *, const uint8_t *, int, int);
 
 void framebuffer_update_display(
     DisplayState *ds,
+    MemoryRegion *address_space,
     target_phys_addr_t base,
     int cols,
     int rows,
diff --git a/hw/milkymist-vgafb.c b/hw/milkymist-vgafb.c
index 01cd309..108115e 100644
--- a/hw/milkymist-vgafb.c
+++ b/hw/milkymist-vgafb.c
@@ -120,7 +120,7 @@ static void vgafb_update_display(void *opaque)
         break;
     }
 
-    framebuffer_update_display(s->ds,
+    framebuffer_update_display(s->ds, sysbus_address_space(&s->busdev),
                                s->regs[R_BASEADDRESS] + s->fb_offset,
                                s->regs[R_HRES],
                                s->regs[R_VRES],
diff --git a/hw/omap_lcdc.c b/hw/omap_lcdc.c
index 8484f70..f265306 100644
--- a/hw/omap_lcdc.c
+++ b/hw/omap_lcdc.c
@@ -22,6 +22,7 @@
 #include "framebuffer.h"
 
 struct omap_lcd_panel_s {
+    MemoryRegion *sysmem;
     MemoryRegion iomem;
     qemu_irq irq;
     DisplayState *state;
@@ -211,7 +212,7 @@ static void omap_update_display(void *opaque)
 
     step = width * bpp >> 3;
     linesize = ds_get_linesize(omap_lcd->state);
-    framebuffer_update_display(omap_lcd->state,
+    framebuffer_update_display(omap_lcd->state, omap_lcd->sysmem,
                                frame_base, width, height,
                                step, linesize, 0,
                                omap_lcd->invalidate,
@@ -440,6 +441,7 @@ struct omap_lcd_panel_s *omap_lcdc_init(MemoryRegion *sysmem,
 
     s->irq = irq;
     s->dma = dma;
+    s->sysmem = sysmem;
     omap_lcdc_reset(s);
 
     memory_region_init_io(&s->iomem, &omap_lcdc_ops, s, "omap.lcdc", 0x100);
diff --git a/hw/pl110.c b/hw/pl110.c
index cc1eb6d..303a9bc 100644
--- a/hw/pl110.c
+++ b/hw/pl110.c
@@ -229,7 +229,7 @@ static void pl110_update_display(void *opaque)
     }
     dest_width *= s->cols;
     first = 0;
-    framebuffer_update_display(s->ds,
+    framebuffer_update_display(s->ds, sysbus_address_space(&s->busdev),
                                s->upbase, s->cols, s->rows,
                                src_width, dest_width, 0,
                                s->invalidate,
diff --git a/hw/pxa2xx_lcd.c b/hw/pxa2xx_lcd.c
index fd23d63..5dd4ef0 100644
--- a/hw/pxa2xx_lcd.c
+++ b/hw/pxa2xx_lcd.c
@@ -30,6 +30,7 @@ struct DMAChannel {
 };
 
 struct PXA2xxLCDState {
+    MemoryRegion *sysmem;
     MemoryRegion iomem;
     qemu_irq irq;
     int irqlevel;
@@ -681,7 +682,7 @@ static void pxa2xx_lcdc_dma0_redraw_rot0(PXA2xxLCDState *s,
 
     dest_width = s->xres * s->dest_width;
     *miny = 0;
-    framebuffer_update_display(s->ds,
+    framebuffer_update_display(s->ds, s->sysmem,
                                addr, s->xres, s->yres,
                                src_width, dest_width, s->dest_width,
                                s->invalidated,
@@ -708,7 +709,7 @@ static void pxa2xx_lcdc_dma0_redraw_rot90(PXA2xxLCDState *s,
 
     dest_width = s->yres * s->dest_width;
     *miny = 0;
-    framebuffer_update_display(s->ds,
+    framebuffer_update_display(s->ds, s->sysmem,
                                addr, s->xres, s->yres,
                                src_width, s->dest_width, -dest_width,
                                s->invalidated,
@@ -739,7 +740,7 @@ static void pxa2xx_lcdc_dma0_redraw_rot180(PXA2xxLCDState *s,
 
     dest_width = s->xres * s->dest_width;
     *miny = 0;
-    framebuffer_update_display(s->ds,
+    framebuffer_update_display(s->ds, s->sysmem,
                                addr, s->xres, s->yres,
                                src_width, -dest_width, -s->dest_width,
                                s->invalidated,
@@ -769,7 +770,7 @@ static void pxa2xx_lcdc_dma0_redraw_rot270(PXA2xxLCDState *s,
 
     dest_width = s->yres * s->dest_width;
     *miny = 0;
-    framebuffer_update_display(s->ds,
+    framebuffer_update_display(s->ds, s->sysmem,
                                addr, s->xres, s->yres,
                                src_width, -s->dest_width, dest_width,
                                s->invalidated,
@@ -985,6 +986,7 @@ static int pxa2xx_lcdc_post_load(void *opaque, int version_id)
     s = (PXA2xxLCDState *) g_malloc0(sizeof(PXA2xxLCDState));
     s->invalidated = 1;
     s->irq = irq;
+    s->sysmem = sysmem;
 
     pxa2xx_lcdc_orientation(s, graphic_rotate);
 
-- 
1.7.7.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 14:14:27 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 14:14:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rcdym-0007E7-HR; Mon, 19 Dec 2011 14:14:12 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <avi@redhat.com>) id 1Rcdyl-0007Bw-5c
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 14:14:11 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1324304044!8037571!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDY0OTI=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32376 invoked from network); 19 Dec 2011 14:14:04 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-8.tower-216.messagelabs.com with SMTP;
	19 Dec 2011 14:14:04 -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 pBJEE2Ri004304
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 19 Dec 2011 09:14:02 -0500
Received: from cleopatra.tlv.redhat.com (cleopatra.tlv.redhat.com
	[10.35.255.11])
	by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id pBJEE0hE006981; Mon, 19 Dec 2011 09:14:02 -0500
Received: from s01.tlv.redhat.com (s01.tlv.redhat.com [10.35.255.8])
	by cleopatra.tlv.redhat.com (Postfix) with ESMTP id A7704250BA7;
	Mon, 19 Dec 2011 16:13:54 +0200 (IST)
From: Avi Kivity <avi@redhat.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	qemu-devel@nongnu.org, "Michael S. Tsirkin" <mst@redhat.com>
Date: Mon, 19 Dec 2011 16:13:29 +0200
Message-Id: <1324304024-11220-9-git-send-email-avi@redhat.com>
In-Reply-To: <1324304024-11220-1-git-send-email-avi@redhat.com>
References: <1324304024-11220-1-git-send-email-avi@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
Cc: xen-devel@lists.xensource.com, kvm@vger.kernel.org
Subject: [Xen-devel] [PATCH 08/23] memory: replace
	cpu_physical_sync_dirty_bitmap() with a memory API
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

The function is still used as the implementation.

Signed-off-by: Avi Kivity <avi@redhat.com>
---
 arch_init.c     |    6 ++----
 cpu-all.h       |    3 ---
 exec-obsolete.h |    3 +++
 memory.c        |    4 ++++
 memory.h        |   10 ++++++++++
 5 files changed, 19 insertions(+), 7 deletions(-)

diff --git a/arch_init.c b/arch_init.c
index a411fdf..ceef26e 100644
--- a/arch_init.c
+++ b/arch_init.c
@@ -41,6 +41,7 @@
 #include "net.h"
 #include "gdbstub.h"
 #include "hw/smbios.h"
+#include "exec-memory.h"
 
 #ifdef TARGET_SPARC
 int graphic_width = 1024;
@@ -263,10 +264,7 @@ int ram_save_live(Monitor *mon, QEMUFile *f, int stage, void *opaque)
         return 0;
     }
 
-    if (cpu_physical_sync_dirty_bitmap(0, TARGET_PHYS_ADDR_MAX) != 0) {
-        qemu_file_set_error(f, -EINVAL);
-        return -EINVAL;
-    }
+    memory_global_sync_dirty_bitmap(get_system_memory());
 
     if (stage == 1) {
         RAMBlock *block;
diff --git a/cpu-all.h b/cpu-all.h
index 9d78715..f2c5382 100644
--- a/cpu-all.h
+++ b/cpu-all.h
@@ -569,9 +569,6 @@ int cpu_physical_memory_set_dirty_tracking(int enable);
 
 int cpu_physical_memory_get_dirty_tracking(void);
 
-int cpu_physical_sync_dirty_bitmap(target_phys_addr_t start_addr,
-                                   target_phys_addr_t end_addr);
-
 int cpu_physical_log_start(target_phys_addr_t start_addr,
                            ram_addr_t size);
 
diff --git a/exec-obsolete.h b/exec-obsolete.h
index 1d0b610..aa0a04d 100644
--- a/exec-obsolete.h
+++ b/exec-obsolete.h
@@ -64,6 +64,9 @@ static inline void cpu_register_physical_memory(target_phys_addr_t start_addr,
 void qemu_register_coalesced_mmio(target_phys_addr_t addr, ram_addr_t size);
 void qemu_unregister_coalesced_mmio(target_phys_addr_t addr, ram_addr_t size);
 
+int cpu_physical_sync_dirty_bitmap(target_phys_addr_t start_addr,
+                                   target_phys_addr_t end_addr);
+
 #endif
 
 #endif
diff --git a/memory.c b/memory.c
index c57b7de..639f3b1 100644
--- a/memory.c
+++ b/memory.c
@@ -1383,6 +1383,10 @@ MemoryRegionSection memory_region_find(MemoryRegion *address_space,
     return ret;
 }
 
+void memory_global_sync_dirty_bitmap(MemoryRegion *address_space)
+{
+    cpu_physical_sync_dirty_bitmap(0, TARGET_PHYS_ADDR_MAX);
+}
 
 void set_system_memory_map(MemoryRegion *mr)
 {
diff --git a/memory.h b/memory.h
index 42546c4..3e27593 100644
--- a/memory.h
+++ b/memory.h
@@ -552,6 +552,16 @@ void memory_region_del_subregion(MemoryRegion *mr,
 MemoryRegionSection memory_region_find(MemoryRegion *address_space,
                                        target_phys_addr_t addr, uint64_t size);
 
+
+/**
+ * memory_global_sync_dirty_bitmap: synchronize the dirty log for all memory
+ *
+ * Synchronizes the dirty page log for an entire address space.
+ * @address_space: a top-level (i.e. parentless) region that contains the
+ *       memory being synchronized
+ */
+void memory_global_sync_dirty_bitmap(MemoryRegion *address_space);
+
 /**
  * memory_region_transaction_begin: Start a transaction.
  *
-- 
1.7.7.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 14:14:27 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 14:14:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rcdym-0007E7-HR; Mon, 19 Dec 2011 14:14:12 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <avi@redhat.com>) id 1Rcdyl-0007Bw-5c
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 14:14:11 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1324304044!8037571!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDY0OTI=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32376 invoked from network); 19 Dec 2011 14:14:04 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-8.tower-216.messagelabs.com with SMTP;
	19 Dec 2011 14:14:04 -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 pBJEE2Ri004304
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 19 Dec 2011 09:14:02 -0500
Received: from cleopatra.tlv.redhat.com (cleopatra.tlv.redhat.com
	[10.35.255.11])
	by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id pBJEE0hE006981; Mon, 19 Dec 2011 09:14:02 -0500
Received: from s01.tlv.redhat.com (s01.tlv.redhat.com [10.35.255.8])
	by cleopatra.tlv.redhat.com (Postfix) with ESMTP id A7704250BA7;
	Mon, 19 Dec 2011 16:13:54 +0200 (IST)
From: Avi Kivity <avi@redhat.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	qemu-devel@nongnu.org, "Michael S. Tsirkin" <mst@redhat.com>
Date: Mon, 19 Dec 2011 16:13:29 +0200
Message-Id: <1324304024-11220-9-git-send-email-avi@redhat.com>
In-Reply-To: <1324304024-11220-1-git-send-email-avi@redhat.com>
References: <1324304024-11220-1-git-send-email-avi@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
Cc: xen-devel@lists.xensource.com, kvm@vger.kernel.org
Subject: [Xen-devel] [PATCH 08/23] memory: replace
	cpu_physical_sync_dirty_bitmap() with a memory API
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

The function is still used as the implementation.

Signed-off-by: Avi Kivity <avi@redhat.com>
---
 arch_init.c     |    6 ++----
 cpu-all.h       |    3 ---
 exec-obsolete.h |    3 +++
 memory.c        |    4 ++++
 memory.h        |   10 ++++++++++
 5 files changed, 19 insertions(+), 7 deletions(-)

diff --git a/arch_init.c b/arch_init.c
index a411fdf..ceef26e 100644
--- a/arch_init.c
+++ b/arch_init.c
@@ -41,6 +41,7 @@
 #include "net.h"
 #include "gdbstub.h"
 #include "hw/smbios.h"
+#include "exec-memory.h"
 
 #ifdef TARGET_SPARC
 int graphic_width = 1024;
@@ -263,10 +264,7 @@ int ram_save_live(Monitor *mon, QEMUFile *f, int stage, void *opaque)
         return 0;
     }
 
-    if (cpu_physical_sync_dirty_bitmap(0, TARGET_PHYS_ADDR_MAX) != 0) {
-        qemu_file_set_error(f, -EINVAL);
-        return -EINVAL;
-    }
+    memory_global_sync_dirty_bitmap(get_system_memory());
 
     if (stage == 1) {
         RAMBlock *block;
diff --git a/cpu-all.h b/cpu-all.h
index 9d78715..f2c5382 100644
--- a/cpu-all.h
+++ b/cpu-all.h
@@ -569,9 +569,6 @@ int cpu_physical_memory_set_dirty_tracking(int enable);
 
 int cpu_physical_memory_get_dirty_tracking(void);
 
-int cpu_physical_sync_dirty_bitmap(target_phys_addr_t start_addr,
-                                   target_phys_addr_t end_addr);
-
 int cpu_physical_log_start(target_phys_addr_t start_addr,
                            ram_addr_t size);
 
diff --git a/exec-obsolete.h b/exec-obsolete.h
index 1d0b610..aa0a04d 100644
--- a/exec-obsolete.h
+++ b/exec-obsolete.h
@@ -64,6 +64,9 @@ static inline void cpu_register_physical_memory(target_phys_addr_t start_addr,
 void qemu_register_coalesced_mmio(target_phys_addr_t addr, ram_addr_t size);
 void qemu_unregister_coalesced_mmio(target_phys_addr_t addr, ram_addr_t size);
 
+int cpu_physical_sync_dirty_bitmap(target_phys_addr_t start_addr,
+                                   target_phys_addr_t end_addr);
+
 #endif
 
 #endif
diff --git a/memory.c b/memory.c
index c57b7de..639f3b1 100644
--- a/memory.c
+++ b/memory.c
@@ -1383,6 +1383,10 @@ MemoryRegionSection memory_region_find(MemoryRegion *address_space,
     return ret;
 }
 
+void memory_global_sync_dirty_bitmap(MemoryRegion *address_space)
+{
+    cpu_physical_sync_dirty_bitmap(0, TARGET_PHYS_ADDR_MAX);
+}
 
 void set_system_memory_map(MemoryRegion *mr)
 {
diff --git a/memory.h b/memory.h
index 42546c4..3e27593 100644
--- a/memory.h
+++ b/memory.h
@@ -552,6 +552,16 @@ void memory_region_del_subregion(MemoryRegion *mr,
 MemoryRegionSection memory_region_find(MemoryRegion *address_space,
                                        target_phys_addr_t addr, uint64_t size);
 
+
+/**
+ * memory_global_sync_dirty_bitmap: synchronize the dirty log for all memory
+ *
+ * Synchronizes the dirty page log for an entire address space.
+ * @address_space: a top-level (i.e. parentless) region that contains the
+ *       memory being synchronized
+ */
+void memory_global_sync_dirty_bitmap(MemoryRegion *address_space);
+
 /**
  * memory_region_transaction_begin: Start a transaction.
  *
-- 
1.7.7.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 14:14:28 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 14:14:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rcdyo-0007Fo-J4; Mon, 19 Dec 2011 14:14:14 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <avi@redhat.com>) id 1Rcdym-0007CZ-0g
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 14:14:12 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1324303992!61338014!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDY0OTI=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2340 invoked from network); 19 Dec 2011 14:13:12 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-7.tower-27.messagelabs.com with SMTP;
	19 Dec 2011 14:13:12 -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 pBJEE5m1008973
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 19 Dec 2011 09:14:05 -0500
Received: from cleopatra.tlv.redhat.com (cleopatra.tlv.redhat.com
	[10.35.255.11])
	by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id pBJEE0hK006981; Mon, 19 Dec 2011 09:14:04 -0500
Received: from s01.tlv.redhat.com (s01.tlv.redhat.com [10.35.255.8])
	by cleopatra.tlv.redhat.com (Postfix) with ESMTP id C2A0E250BB3;
	Mon, 19 Dec 2011 16:13:54 +0200 (IST)
From: Avi Kivity <avi@redhat.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	qemu-devel@nongnu.org, "Michael S. Tsirkin" <mst@redhat.com>
Date: Mon, 19 Dec 2011 16:13:41 +0200
Message-Id: <1324304024-11220-21-git-send-email-avi@redhat.com>
In-Reply-To: <1324304024-11220-1-git-send-email-avi@redhat.com>
References: <1324304024-11220-1-git-send-email-avi@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
Cc: xen-devel@lists.xensource.com, kvm@vger.kernel.org
Subject: [Xen-devel] [PATCH 20/23] vhost: avoid cpu_get_physical_page_desc()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This reaches into the innards of the memory core, which are being
changed.  Switch to a memory API version.

Signed-off-by: Avi Kivity <avi@redhat.com>
---
 hw/vhost.c |   47 +++++++++++++++++++++++++++++++++++++++--------
 hw/vhost.h |    2 ++
 2 files changed, 41 insertions(+), 8 deletions(-)

diff --git a/hw/vhost.c b/hw/vhost.c
index a1c5e4c..cd56e75 100644
--- a/hw/vhost.c
+++ b/hw/vhost.c
@@ -17,6 +17,7 @@
 #include <linux/vhost.h>
 
 static void vhost_dev_sync_region(struct vhost_dev *dev,
+                                  MemoryRegionSection *section,
                                   uint64_t mfirst, uint64_t mlast,
                                   uint64_t rfirst, uint64_t rlast)
 {
@@ -49,8 +50,8 @@ static void vhost_dev_sync_region(struct vhost_dev *dev,
                 ffsll(log) : ffs(log))) {
             ram_addr_t ram_addr;
             bit -= 1;
-            ram_addr = cpu_get_physical_page_desc(addr + bit * VHOST_LOG_PAGE);
-            cpu_physical_memory_set_dirty(ram_addr);
+            ram_addr = section->offset_within_region + bit * VHOST_LOG_PAGE;
+            memory_region_set_dirty(section->mr, ram_addr);
             log &= ~(0x1ull << bit);
         }
         addr += VHOST_LOG_CHUNK;
@@ -58,6 +59,7 @@ static void vhost_dev_sync_region(struct vhost_dev *dev,
 }
 
 static int vhost_sync_dirty_bitmap(struct vhost_dev *dev,
+                                   MemoryRegionSection *section,
                                    target_phys_addr_t start_addr,
                                    target_phys_addr_t end_addr)
 {
@@ -68,14 +70,14 @@ static int vhost_sync_dirty_bitmap(struct vhost_dev *dev,
     }
     for (i = 0; i < dev->mem->nregions; ++i) {
         struct vhost_memory_region *reg = dev->mem->regions + i;
-        vhost_dev_sync_region(dev, start_addr, end_addr,
+        vhost_dev_sync_region(dev, section, start_addr, end_addr,
                               reg->guest_phys_addr,
                               range_get_last(reg->guest_phys_addr,
                                              reg->memory_size));
     }
     for (i = 0; i < dev->nvqs; ++i) {
         struct vhost_virtqueue *vq = dev->vqs + i;
-        vhost_dev_sync_region(dev, start_addr, end_addr, vq->used_phys,
+        vhost_dev_sync_region(dev, section, start_addr, end_addr, vq->used_phys,
                               range_get_last(vq->used_phys, vq->used_size));
     }
     return 0;
@@ -89,7 +91,7 @@ static void vhost_log_sync(MemoryListener *listener,
     target_phys_addr_t start_addr = section->offset_within_address_space;
     target_phys_addr_t end_addr = start_addr + section->size;
 
-    vhost_sync_dirty_bitmap(dev, start_addr, end_addr);
+    vhost_sync_dirty_bitmap(dev, section, start_addr, end_addr);
 }
 
 /* Assign/unassign. Keep an unsorted array of non-overlapping
@@ -261,7 +263,7 @@ static inline void vhost_dev_log_resize(struct vhost_dev* dev, uint64_t size)
 {
     vhost_log_chunk_t *log;
     uint64_t log_base;
-    int r;
+    int r, i;
     if (size) {
         log = g_malloc0(size * sizeof *log);
     } else {
@@ -270,7 +272,10 @@ static inline void vhost_dev_log_resize(struct vhost_dev* dev, uint64_t size)
     log_base = (uint64_t)(unsigned long)log;
     r = ioctl(dev->control, VHOST_SET_LOG_BASE, &log_base);
     assert(r >= 0);
-    vhost_sync_dirty_bitmap(dev, 0, (target_phys_addr_t)~0x0ull);
+    for (i = 0; i < dev->n_mem_sections; ++i) {
+        vhost_sync_dirty_bitmap(dev, &dev->mem_sections[i],
+                                0, (target_phys_addr_t)~0x0ull);
+    }
     if (dev->log) {
         g_free(dev->log);
     }
@@ -428,13 +433,33 @@ static void vhost_set_memory(MemoryListener *listener,
 static void vhost_region_add(MemoryListener *listener,
                              MemoryRegionSection *section)
 {
+    struct vhost_dev *dev = container_of(listener, struct vhost_dev,
+                                         memory_listener);
+
+    ++dev->n_mem_sections;
+    dev->mem_sections = g_renew(MemoryRegionSection, dev->mem_sections,
+                                dev->n_mem_sections);
+    dev->mem_sections[dev->n_mem_sections - 1] = *section;
     vhost_set_memory(listener, section, true);
 }
 
 static void vhost_region_del(MemoryListener *listener,
                              MemoryRegionSection *section)
 {
+    struct vhost_dev *dev = container_of(listener, struct vhost_dev,
+                                         memory_listener);
+    int i;
+
     vhost_set_memory(listener, section, false);
+    for (i = 0; i < dev->n_mem_sections; ++i) {
+        if (dev->mem_sections[i].offset_within_address_space
+            == section->offset_within_address_space) {
+            --dev->n_mem_sections;
+            memmove(&dev->mem_sections[i], &dev->mem_sections[i+1],
+                    dev->n_mem_sections - i);
+            break;
+        }
+    }
 }
 
 static int vhost_virtqueue_set_addr(struct vhost_dev *dev,
@@ -714,6 +739,8 @@ int vhost_dev_init(struct vhost_dev *hdev, int devfd, bool force)
         .log_global_stop = vhost_log_global_stop,
     };
     hdev->mem = g_malloc0(offsetof(struct vhost_memory, regions));
+    hdev->n_mem_sections = 0;
+    hdev->mem_sections = NULL;
     hdev->log = NULL;
     hdev->log_size = 0;
     hdev->log_enabled = false;
@@ -731,6 +758,7 @@ void vhost_dev_cleanup(struct vhost_dev *hdev)
 {
     memory_listener_unregister(&hdev->memory_listener);
     g_free(hdev->mem);
+    g_free(hdev->mem_sections);
     close(hdev->control);
 }
 
@@ -871,7 +899,10 @@ void vhost_dev_stop(struct vhost_dev *hdev, VirtIODevice *vdev)
                                 hdev->vqs + i,
                                 i);
     }
-    vhost_sync_dirty_bitmap(hdev, 0, (target_phys_addr_t)~0x0ull);
+    for (i = 0; i < hdev->n_mem_sections; ++i) {
+        vhost_sync_dirty_bitmap(hdev, &hdev->mem_sections[i],
+                                0, (target_phys_addr_t)~0x0ull);
+    }
     r = vdev->binding->set_guest_notifiers(vdev->binding_opaque, false);
     if (r < 0) {
         fprintf(stderr, "vhost guest notifier cleanup failed: %d\n", r);
diff --git a/hw/vhost.h b/hw/vhost.h
index d1824ec..80e64df 100644
--- a/hw/vhost.h
+++ b/hw/vhost.h
@@ -30,6 +30,8 @@ struct vhost_dev {
     MemoryListener memory_listener;
     int control;
     struct vhost_memory *mem;
+    int n_mem_sections;
+    MemoryRegionSection *mem_sections;
     struct vhost_virtqueue *vqs;
     int nvqs;
     unsigned long long features;
-- 
1.7.7.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 14:14:28 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 14:14:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rcdyo-0007Fo-J4; Mon, 19 Dec 2011 14:14:14 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <avi@redhat.com>) id 1Rcdym-0007CZ-0g
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 14:14:12 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1324303992!61338014!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDY0OTI=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2340 invoked from network); 19 Dec 2011 14:13:12 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-7.tower-27.messagelabs.com with SMTP;
	19 Dec 2011 14:13:12 -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 pBJEE5m1008973
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 19 Dec 2011 09:14:05 -0500
Received: from cleopatra.tlv.redhat.com (cleopatra.tlv.redhat.com
	[10.35.255.11])
	by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id pBJEE0hK006981; Mon, 19 Dec 2011 09:14:04 -0500
Received: from s01.tlv.redhat.com (s01.tlv.redhat.com [10.35.255.8])
	by cleopatra.tlv.redhat.com (Postfix) with ESMTP id C2A0E250BB3;
	Mon, 19 Dec 2011 16:13:54 +0200 (IST)
From: Avi Kivity <avi@redhat.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	qemu-devel@nongnu.org, "Michael S. Tsirkin" <mst@redhat.com>
Date: Mon, 19 Dec 2011 16:13:41 +0200
Message-Id: <1324304024-11220-21-git-send-email-avi@redhat.com>
In-Reply-To: <1324304024-11220-1-git-send-email-avi@redhat.com>
References: <1324304024-11220-1-git-send-email-avi@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
Cc: xen-devel@lists.xensource.com, kvm@vger.kernel.org
Subject: [Xen-devel] [PATCH 20/23] vhost: avoid cpu_get_physical_page_desc()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This reaches into the innards of the memory core, which are being
changed.  Switch to a memory API version.

Signed-off-by: Avi Kivity <avi@redhat.com>
---
 hw/vhost.c |   47 +++++++++++++++++++++++++++++++++++++++--------
 hw/vhost.h |    2 ++
 2 files changed, 41 insertions(+), 8 deletions(-)

diff --git a/hw/vhost.c b/hw/vhost.c
index a1c5e4c..cd56e75 100644
--- a/hw/vhost.c
+++ b/hw/vhost.c
@@ -17,6 +17,7 @@
 #include <linux/vhost.h>
 
 static void vhost_dev_sync_region(struct vhost_dev *dev,
+                                  MemoryRegionSection *section,
                                   uint64_t mfirst, uint64_t mlast,
                                   uint64_t rfirst, uint64_t rlast)
 {
@@ -49,8 +50,8 @@ static void vhost_dev_sync_region(struct vhost_dev *dev,
                 ffsll(log) : ffs(log))) {
             ram_addr_t ram_addr;
             bit -= 1;
-            ram_addr = cpu_get_physical_page_desc(addr + bit * VHOST_LOG_PAGE);
-            cpu_physical_memory_set_dirty(ram_addr);
+            ram_addr = section->offset_within_region + bit * VHOST_LOG_PAGE;
+            memory_region_set_dirty(section->mr, ram_addr);
             log &= ~(0x1ull << bit);
         }
         addr += VHOST_LOG_CHUNK;
@@ -58,6 +59,7 @@ static void vhost_dev_sync_region(struct vhost_dev *dev,
 }
 
 static int vhost_sync_dirty_bitmap(struct vhost_dev *dev,
+                                   MemoryRegionSection *section,
                                    target_phys_addr_t start_addr,
                                    target_phys_addr_t end_addr)
 {
@@ -68,14 +70,14 @@ static int vhost_sync_dirty_bitmap(struct vhost_dev *dev,
     }
     for (i = 0; i < dev->mem->nregions; ++i) {
         struct vhost_memory_region *reg = dev->mem->regions + i;
-        vhost_dev_sync_region(dev, start_addr, end_addr,
+        vhost_dev_sync_region(dev, section, start_addr, end_addr,
                               reg->guest_phys_addr,
                               range_get_last(reg->guest_phys_addr,
                                              reg->memory_size));
     }
     for (i = 0; i < dev->nvqs; ++i) {
         struct vhost_virtqueue *vq = dev->vqs + i;
-        vhost_dev_sync_region(dev, start_addr, end_addr, vq->used_phys,
+        vhost_dev_sync_region(dev, section, start_addr, end_addr, vq->used_phys,
                               range_get_last(vq->used_phys, vq->used_size));
     }
     return 0;
@@ -89,7 +91,7 @@ static void vhost_log_sync(MemoryListener *listener,
     target_phys_addr_t start_addr = section->offset_within_address_space;
     target_phys_addr_t end_addr = start_addr + section->size;
 
-    vhost_sync_dirty_bitmap(dev, start_addr, end_addr);
+    vhost_sync_dirty_bitmap(dev, section, start_addr, end_addr);
 }
 
 /* Assign/unassign. Keep an unsorted array of non-overlapping
@@ -261,7 +263,7 @@ static inline void vhost_dev_log_resize(struct vhost_dev* dev, uint64_t size)
 {
     vhost_log_chunk_t *log;
     uint64_t log_base;
-    int r;
+    int r, i;
     if (size) {
         log = g_malloc0(size * sizeof *log);
     } else {
@@ -270,7 +272,10 @@ static inline void vhost_dev_log_resize(struct vhost_dev* dev, uint64_t size)
     log_base = (uint64_t)(unsigned long)log;
     r = ioctl(dev->control, VHOST_SET_LOG_BASE, &log_base);
     assert(r >= 0);
-    vhost_sync_dirty_bitmap(dev, 0, (target_phys_addr_t)~0x0ull);
+    for (i = 0; i < dev->n_mem_sections; ++i) {
+        vhost_sync_dirty_bitmap(dev, &dev->mem_sections[i],
+                                0, (target_phys_addr_t)~0x0ull);
+    }
     if (dev->log) {
         g_free(dev->log);
     }
@@ -428,13 +433,33 @@ static void vhost_set_memory(MemoryListener *listener,
 static void vhost_region_add(MemoryListener *listener,
                              MemoryRegionSection *section)
 {
+    struct vhost_dev *dev = container_of(listener, struct vhost_dev,
+                                         memory_listener);
+
+    ++dev->n_mem_sections;
+    dev->mem_sections = g_renew(MemoryRegionSection, dev->mem_sections,
+                                dev->n_mem_sections);
+    dev->mem_sections[dev->n_mem_sections - 1] = *section;
     vhost_set_memory(listener, section, true);
 }
 
 static void vhost_region_del(MemoryListener *listener,
                              MemoryRegionSection *section)
 {
+    struct vhost_dev *dev = container_of(listener, struct vhost_dev,
+                                         memory_listener);
+    int i;
+
     vhost_set_memory(listener, section, false);
+    for (i = 0; i < dev->n_mem_sections; ++i) {
+        if (dev->mem_sections[i].offset_within_address_space
+            == section->offset_within_address_space) {
+            --dev->n_mem_sections;
+            memmove(&dev->mem_sections[i], &dev->mem_sections[i+1],
+                    dev->n_mem_sections - i);
+            break;
+        }
+    }
 }
 
 static int vhost_virtqueue_set_addr(struct vhost_dev *dev,
@@ -714,6 +739,8 @@ int vhost_dev_init(struct vhost_dev *hdev, int devfd, bool force)
         .log_global_stop = vhost_log_global_stop,
     };
     hdev->mem = g_malloc0(offsetof(struct vhost_memory, regions));
+    hdev->n_mem_sections = 0;
+    hdev->mem_sections = NULL;
     hdev->log = NULL;
     hdev->log_size = 0;
     hdev->log_enabled = false;
@@ -731,6 +758,7 @@ void vhost_dev_cleanup(struct vhost_dev *hdev)
 {
     memory_listener_unregister(&hdev->memory_listener);
     g_free(hdev->mem);
+    g_free(hdev->mem_sections);
     close(hdev->control);
 }
 
@@ -871,7 +899,10 @@ void vhost_dev_stop(struct vhost_dev *hdev, VirtIODevice *vdev)
                                 hdev->vqs + i,
                                 i);
     }
-    vhost_sync_dirty_bitmap(hdev, 0, (target_phys_addr_t)~0x0ull);
+    for (i = 0; i < hdev->n_mem_sections; ++i) {
+        vhost_sync_dirty_bitmap(hdev, &hdev->mem_sections[i],
+                                0, (target_phys_addr_t)~0x0ull);
+    }
     r = vdev->binding->set_guest_notifiers(vdev->binding_opaque, false);
     if (r < 0) {
         fprintf(stderr, "vhost guest notifier cleanup failed: %d\n", r);
diff --git a/hw/vhost.h b/hw/vhost.h
index d1824ec..80e64df 100644
--- a/hw/vhost.h
+++ b/hw/vhost.h
@@ -30,6 +30,8 @@ struct vhost_dev {
     MemoryListener memory_listener;
     int control;
     struct vhost_memory *mem;
+    int n_mem_sections;
+    MemoryRegionSection *mem_sections;
     struct vhost_virtqueue *vqs;
     int nvqs;
     unsigned long long features;
-- 
1.7.7.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 14:14:29 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 14:14:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rcdyo-0007FQ-5j; Mon, 19 Dec 2011 14:14:14 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <avi@redhat.com>) id 1Rcdyl-0007C3-Uo
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 14:14:12 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1324304045!6130672!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDY0OTI=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23761 invoked from network); 19 Dec 2011 14:14:05 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-7.tower-174.messagelabs.com with SMTP;
	19 Dec 2011 14:14:05 -0000
Received: from int-mx01.intmail.prod.int.phx2.redhat.com
	(int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id pBJEE3qB024948
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 19 Dec 2011 09:14:03 -0500
Received: from cleopatra.tlv.redhat.com (cleopatra.tlv.redhat.com
	[10.35.255.11])
	by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP
	id pBJEE0N7009673; Mon, 19 Dec 2011 09:14:02 -0500
Received: from s01.tlv.redhat.com (s01.tlv.redhat.com [10.35.255.8])
	by cleopatra.tlv.redhat.com (Postfix) with ESMTP id AAAB5250BA8;
	Mon, 19 Dec 2011 16:13:54 +0200 (IST)
From: Avi Kivity <avi@redhat.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	qemu-devel@nongnu.org, "Michael S. Tsirkin" <mst@redhat.com>
Date: Mon, 19 Dec 2011 16:13:30 +0200
Message-Id: <1324304024-11220-10-git-send-email-avi@redhat.com>
In-Reply-To: <1324304024-11220-1-git-send-email-avi@redhat.com>
References: <1324304024-11220-1-git-send-email-avi@redhat.com>
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.11
Cc: xen-devel@lists.xensource.com, kvm@vger.kernel.org
Subject: [Xen-devel] [PATCH 09/23] memory: add API for observing updates to
	the physical memory map
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Add an API that allows a client to observe changes in the global
memory map:
 - region added (possibly with logging enabled)
 - region removed (possibly with logging enabled)
 - logging started on a region
 - logging stopped on a region
 - global logging started
 - global logging removed

This API will eventually replace cpu_register_physical_memory_client().

Signed-off-by: Avi Kivity <avi@redhat.com>
---
 exec.c   |    5 +++
 memory.c |   92 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 memory.h |   47 +++++++++++++++++++++++++++++++
 3 files changed, 144 insertions(+), 0 deletions(-)

diff --git a/exec.c b/exec.c
index 32782b4..36b61c9 100644
--- a/exec.c
+++ b/exec.c
@@ -1762,6 +1762,11 @@ static int cpu_notify_sync_dirty_bitmap(target_phys_addr_t start,
 static int cpu_notify_migration_log(int enable)
 {
     CPUPhysMemoryClient *client;
+    if (enable) {
+        memory_global_dirty_log_start();
+    } else {
+        memory_global_dirty_log_stop();
+    }
     QLIST_FOREACH(client, &memory_client_list, list) {
         int r = client->migration_log(client, enable);
         if (r < 0)
diff --git a/memory.c b/memory.c
index 639f3b1..ee9053a 100644
--- a/memory.c
+++ b/memory.c
@@ -22,6 +22,10 @@
 #include "exec-obsolete.h"
 
 unsigned memory_region_transaction_depth = 0;
+static bool global_dirty_log = false;
+
+static QLIST_HEAD(, MemoryListener) memory_listeners
+    = QLIST_HEAD_INITIALIZER(memory_listeners);
 
 typedef struct AddrRange AddrRange;
 
@@ -692,6 +696,32 @@ static void address_space_update_ioeventfds(AddressSpace *as)
     as->ioeventfd_nb = ioeventfd_nb;
 }
 
+typedef void ListenerCallback(MemoryListener *listener,
+                              MemoryRegionSection *mrs);
+
+/* Want "void (&MemoryListener::*callback)(const MemoryRegionSection& s)" */
+static void memory_listener_update_region(FlatRange *fr, AddressSpace *as,
+                                          size_t callback_offset)
+{
+    MemoryRegionSection section = {
+        .mr = fr->mr,
+        .address_space = as->root,
+        .offset_within_region = fr->offset_in_region,
+        .size = int128_get64(fr->addr.size),
+        .offset_within_region = int128_get64(fr->addr.start),
+    };
+    MemoryListener *listener;
+
+    QLIST_FOREACH(listener, &memory_listeners, link) {
+        ListenerCallback *callback
+            = *(ListenerCallback *)((void *)listener + callback_offset);
+        callback(listener, &section);
+    }
+}
+
+#define MEMORY_LISTENER_UPDATE_REGION(fr, as, callback) \
+    memory_listener_update_region(fr, as, offsetof(MemoryListener, callback))
+
 static void address_space_update_topology_pass(AddressSpace *as,
                                                FlatView old_view,
                                                FlatView new_view,
@@ -724,6 +754,7 @@ static void address_space_update_topology_pass(AddressSpace *as,
             /* In old, but (not in new, or in new but attributes changed). */
 
             if (!adding) {
+                MEMORY_LISTENER_UPDATE_REGION(frold, as, region_del);
                 as->ops->range_del(as, frold);
             }
 
@@ -733,9 +764,11 @@ static void address_space_update_topology_pass(AddressSpace *as,
 
             if (adding) {
                 if (frold->dirty_log_mask && !frnew->dirty_log_mask) {
+                    MEMORY_LISTENER_UPDATE_REGION(frold, as, log_stop);
                     as->ops->log_stop(as, frnew);
                 } else if (frnew->dirty_log_mask && !frold->dirty_log_mask) {
                     as->ops->log_start(as, frnew);
+                    MEMORY_LISTENER_UPDATE_REGION(frold, as, log_start);
                 }
             }
 
@@ -746,6 +779,7 @@ static void address_space_update_topology_pass(AddressSpace *as,
 
             if (adding) {
                 as->ops->range_add(as, frnew);
+                MEMORY_LISTENER_UPDATE_REGION(frold, as, region_add);
             }
 
             ++inew;
@@ -1385,7 +1419,65 @@ MemoryRegionSection memory_region_find(MemoryRegion *address_space,
 
 void memory_global_sync_dirty_bitmap(MemoryRegion *address_space)
 {
+    AddressSpace *as = memory_region_to_address_space(address_space);
+    FlatRange *fr;
+
     cpu_physical_sync_dirty_bitmap(0, TARGET_PHYS_ADDR_MAX);
+    FOR_EACH_FLAT_RANGE(fr, &as->current_map) {
+        MEMORY_LISTENER_UPDATE_REGION(fr, as, log_sync);
+    }
+}
+
+void memory_global_dirty_log_start(void)
+{
+    MemoryListener *listener;
+
+    global_dirty_log = true;
+    QLIST_FOREACH(listener, &memory_listeners, link) {
+        listener->log_global_start(listener);
+    }
+}
+
+void memory_global_dirty_log_stop(void)
+{
+    MemoryListener *listener;
+
+    global_dirty_log = false;
+    QLIST_FOREACH(listener, &memory_listeners, link) {
+        listener->log_global_stop(listener);
+    }
+}
+
+static void listener_add_address_space(MemoryListener *listener,
+                                       AddressSpace *as)
+{
+    FlatRange *fr;
+
+    if (global_dirty_log) {
+        listener->log_global_start(listener);
+    }
+    FOR_EACH_FLAT_RANGE(fr, &as->current_map) {
+        MemoryRegionSection section = {
+            .mr = fr->mr,
+            .address_space = as->root,
+            .offset_within_region = fr->offset_in_region,
+            .size = int128_get64(fr->addr.size),
+            .offset_within_region = int128_get64(fr->addr.start),
+        };
+        listener->region_add(listener, &section);
+    }
+}
+
+void memory_listener_register(MemoryListener *listener)
+{
+    QLIST_INSERT_HEAD(&memory_listeners, listener, link);
+    listener_add_address_space(listener, &address_space_memory);
+    listener_add_address_space(listener, &address_space_io);
+}
+
+void memory_listener_unregister(MemoryListener *listener)
+{
+    QLIST_REMOVE(listener, link);
 }
 
 void set_system_memory_map(MemoryRegion *mr)
diff --git a/memory.h b/memory.h
index 3e27593..6b50f6b 100644
--- a/memory.h
+++ b/memory.h
@@ -153,6 +153,7 @@ typedef struct MemoryRegionSection MemoryRegionSection;
  * MemoryRegionSection: describes a fragment of a #MemoryRegion
  *
  * @mr: the region, or %NULL if empty
+ * @address_space: the address space the region is mapped in
  * @offset_within_region: the beginning of the section, relative to @mr's start
  * @size: the size of the section; will not exceed @mr's boundaries
  * @offset_within_address_space: the address of the first byte of the section
@@ -160,11 +161,31 @@ typedef struct MemoryRegionSection MemoryRegionSection;
  */
 struct MemoryRegionSection {
     MemoryRegion *mr;
+    MemoryRegion *address_space;
     target_phys_addr_t offset_within_region;
     uint64_t size;
     target_phys_addr_t offset_within_address_space;
 };
 
+typedef struct MemoryListener MemoryListener;
+
+/**
+ * MemoryListener: callbacks structure for updates to the physical memory map
+ *
+ * Allows a component to adjust to changes in the guest-visible memory map.
+ * Use with memory_listener_register() and memory_listener_unregister().
+ */
+struct MemoryListener {
+    void (*region_add)(MemoryListener *listener, MemoryRegionSection *section);
+    void (*region_del)(MemoryListener *listener, MemoryRegionSection *section);
+    void (*log_start)(MemoryListener *listener, MemoryRegionSection *section);
+    void (*log_stop)(MemoryListener *listener, MemoryRegionSection *section);
+    void (*log_sync)(MemoryListener *listener, MemoryRegionSection *section);
+    void (*log_global_start)(MemoryListener *listener);
+    void (*log_global_stop)(MemoryListener *listener);
+    QLIST_ENTRY(MemoryListener) link;
+};
+
 /**
  * memory_region_init: Initialize a memory region
  *
@@ -576,6 +597,32 @@ void memory_region_transaction_begin(void);
  */
 void memory_region_transaction_commit(void);
 
+/**
+ * memory_listener_register: register callbacks to be called when memory
+ *                           sections are mapped or unmapped into an address
+ *                           space
+ *
+ * @listener: an object containing the callbacks to be called
+ */
+void memory_listener_register(MemoryListener *listener);
+
+/**
+ * memory_listener_unregister: undo the effect of memory_listener_register()
+ *
+ * @listener: an object containing the callbacks to be removed
+ */
+void memory_listener_unregister(MemoryListener *listener);
+
+/**
+ * memory_global_dirty_log_start: begin dirty logging for all regions
+ */
+void memory_global_dirty_log_start(void);
+
+/**
+ * memory_global_dirty_log_stop: begin dirty logging for all regions
+ */
+void memory_global_dirty_log_stop(void);
+
 void mtree_info(fprintf_function mon_printf, void *f);
 
 #endif
-- 
1.7.7.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 14:14:29 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 14:14:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rcdyo-0007FQ-5j; Mon, 19 Dec 2011 14:14:14 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <avi@redhat.com>) id 1Rcdyl-0007C3-Uo
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 14:14:12 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1324304045!6130672!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDY0OTI=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23761 invoked from network); 19 Dec 2011 14:14:05 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-7.tower-174.messagelabs.com with SMTP;
	19 Dec 2011 14:14:05 -0000
Received: from int-mx01.intmail.prod.int.phx2.redhat.com
	(int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id pBJEE3qB024948
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 19 Dec 2011 09:14:03 -0500
Received: from cleopatra.tlv.redhat.com (cleopatra.tlv.redhat.com
	[10.35.255.11])
	by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP
	id pBJEE0N7009673; Mon, 19 Dec 2011 09:14:02 -0500
Received: from s01.tlv.redhat.com (s01.tlv.redhat.com [10.35.255.8])
	by cleopatra.tlv.redhat.com (Postfix) with ESMTP id AAAB5250BA8;
	Mon, 19 Dec 2011 16:13:54 +0200 (IST)
From: Avi Kivity <avi@redhat.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	qemu-devel@nongnu.org, "Michael S. Tsirkin" <mst@redhat.com>
Date: Mon, 19 Dec 2011 16:13:30 +0200
Message-Id: <1324304024-11220-10-git-send-email-avi@redhat.com>
In-Reply-To: <1324304024-11220-1-git-send-email-avi@redhat.com>
References: <1324304024-11220-1-git-send-email-avi@redhat.com>
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.11
Cc: xen-devel@lists.xensource.com, kvm@vger.kernel.org
Subject: [Xen-devel] [PATCH 09/23] memory: add API for observing updates to
	the physical memory map
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Add an API that allows a client to observe changes in the global
memory map:
 - region added (possibly with logging enabled)
 - region removed (possibly with logging enabled)
 - logging started on a region
 - logging stopped on a region
 - global logging started
 - global logging removed

This API will eventually replace cpu_register_physical_memory_client().

Signed-off-by: Avi Kivity <avi@redhat.com>
---
 exec.c   |    5 +++
 memory.c |   92 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 memory.h |   47 +++++++++++++++++++++++++++++++
 3 files changed, 144 insertions(+), 0 deletions(-)

diff --git a/exec.c b/exec.c
index 32782b4..36b61c9 100644
--- a/exec.c
+++ b/exec.c
@@ -1762,6 +1762,11 @@ static int cpu_notify_sync_dirty_bitmap(target_phys_addr_t start,
 static int cpu_notify_migration_log(int enable)
 {
     CPUPhysMemoryClient *client;
+    if (enable) {
+        memory_global_dirty_log_start();
+    } else {
+        memory_global_dirty_log_stop();
+    }
     QLIST_FOREACH(client, &memory_client_list, list) {
         int r = client->migration_log(client, enable);
         if (r < 0)
diff --git a/memory.c b/memory.c
index 639f3b1..ee9053a 100644
--- a/memory.c
+++ b/memory.c
@@ -22,6 +22,10 @@
 #include "exec-obsolete.h"
 
 unsigned memory_region_transaction_depth = 0;
+static bool global_dirty_log = false;
+
+static QLIST_HEAD(, MemoryListener) memory_listeners
+    = QLIST_HEAD_INITIALIZER(memory_listeners);
 
 typedef struct AddrRange AddrRange;
 
@@ -692,6 +696,32 @@ static void address_space_update_ioeventfds(AddressSpace *as)
     as->ioeventfd_nb = ioeventfd_nb;
 }
 
+typedef void ListenerCallback(MemoryListener *listener,
+                              MemoryRegionSection *mrs);
+
+/* Want "void (&MemoryListener::*callback)(const MemoryRegionSection& s)" */
+static void memory_listener_update_region(FlatRange *fr, AddressSpace *as,
+                                          size_t callback_offset)
+{
+    MemoryRegionSection section = {
+        .mr = fr->mr,
+        .address_space = as->root,
+        .offset_within_region = fr->offset_in_region,
+        .size = int128_get64(fr->addr.size),
+        .offset_within_region = int128_get64(fr->addr.start),
+    };
+    MemoryListener *listener;
+
+    QLIST_FOREACH(listener, &memory_listeners, link) {
+        ListenerCallback *callback
+            = *(ListenerCallback *)((void *)listener + callback_offset);
+        callback(listener, &section);
+    }
+}
+
+#define MEMORY_LISTENER_UPDATE_REGION(fr, as, callback) \
+    memory_listener_update_region(fr, as, offsetof(MemoryListener, callback))
+
 static void address_space_update_topology_pass(AddressSpace *as,
                                                FlatView old_view,
                                                FlatView new_view,
@@ -724,6 +754,7 @@ static void address_space_update_topology_pass(AddressSpace *as,
             /* In old, but (not in new, or in new but attributes changed). */
 
             if (!adding) {
+                MEMORY_LISTENER_UPDATE_REGION(frold, as, region_del);
                 as->ops->range_del(as, frold);
             }
 
@@ -733,9 +764,11 @@ static void address_space_update_topology_pass(AddressSpace *as,
 
             if (adding) {
                 if (frold->dirty_log_mask && !frnew->dirty_log_mask) {
+                    MEMORY_LISTENER_UPDATE_REGION(frold, as, log_stop);
                     as->ops->log_stop(as, frnew);
                 } else if (frnew->dirty_log_mask && !frold->dirty_log_mask) {
                     as->ops->log_start(as, frnew);
+                    MEMORY_LISTENER_UPDATE_REGION(frold, as, log_start);
                 }
             }
 
@@ -746,6 +779,7 @@ static void address_space_update_topology_pass(AddressSpace *as,
 
             if (adding) {
                 as->ops->range_add(as, frnew);
+                MEMORY_LISTENER_UPDATE_REGION(frold, as, region_add);
             }
 
             ++inew;
@@ -1385,7 +1419,65 @@ MemoryRegionSection memory_region_find(MemoryRegion *address_space,
 
 void memory_global_sync_dirty_bitmap(MemoryRegion *address_space)
 {
+    AddressSpace *as = memory_region_to_address_space(address_space);
+    FlatRange *fr;
+
     cpu_physical_sync_dirty_bitmap(0, TARGET_PHYS_ADDR_MAX);
+    FOR_EACH_FLAT_RANGE(fr, &as->current_map) {
+        MEMORY_LISTENER_UPDATE_REGION(fr, as, log_sync);
+    }
+}
+
+void memory_global_dirty_log_start(void)
+{
+    MemoryListener *listener;
+
+    global_dirty_log = true;
+    QLIST_FOREACH(listener, &memory_listeners, link) {
+        listener->log_global_start(listener);
+    }
+}
+
+void memory_global_dirty_log_stop(void)
+{
+    MemoryListener *listener;
+
+    global_dirty_log = false;
+    QLIST_FOREACH(listener, &memory_listeners, link) {
+        listener->log_global_stop(listener);
+    }
+}
+
+static void listener_add_address_space(MemoryListener *listener,
+                                       AddressSpace *as)
+{
+    FlatRange *fr;
+
+    if (global_dirty_log) {
+        listener->log_global_start(listener);
+    }
+    FOR_EACH_FLAT_RANGE(fr, &as->current_map) {
+        MemoryRegionSection section = {
+            .mr = fr->mr,
+            .address_space = as->root,
+            .offset_within_region = fr->offset_in_region,
+            .size = int128_get64(fr->addr.size),
+            .offset_within_region = int128_get64(fr->addr.start),
+        };
+        listener->region_add(listener, &section);
+    }
+}
+
+void memory_listener_register(MemoryListener *listener)
+{
+    QLIST_INSERT_HEAD(&memory_listeners, listener, link);
+    listener_add_address_space(listener, &address_space_memory);
+    listener_add_address_space(listener, &address_space_io);
+}
+
+void memory_listener_unregister(MemoryListener *listener)
+{
+    QLIST_REMOVE(listener, link);
 }
 
 void set_system_memory_map(MemoryRegion *mr)
diff --git a/memory.h b/memory.h
index 3e27593..6b50f6b 100644
--- a/memory.h
+++ b/memory.h
@@ -153,6 +153,7 @@ typedef struct MemoryRegionSection MemoryRegionSection;
  * MemoryRegionSection: describes a fragment of a #MemoryRegion
  *
  * @mr: the region, or %NULL if empty
+ * @address_space: the address space the region is mapped in
  * @offset_within_region: the beginning of the section, relative to @mr's start
  * @size: the size of the section; will not exceed @mr's boundaries
  * @offset_within_address_space: the address of the first byte of the section
@@ -160,11 +161,31 @@ typedef struct MemoryRegionSection MemoryRegionSection;
  */
 struct MemoryRegionSection {
     MemoryRegion *mr;
+    MemoryRegion *address_space;
     target_phys_addr_t offset_within_region;
     uint64_t size;
     target_phys_addr_t offset_within_address_space;
 };
 
+typedef struct MemoryListener MemoryListener;
+
+/**
+ * MemoryListener: callbacks structure for updates to the physical memory map
+ *
+ * Allows a component to adjust to changes in the guest-visible memory map.
+ * Use with memory_listener_register() and memory_listener_unregister().
+ */
+struct MemoryListener {
+    void (*region_add)(MemoryListener *listener, MemoryRegionSection *section);
+    void (*region_del)(MemoryListener *listener, MemoryRegionSection *section);
+    void (*log_start)(MemoryListener *listener, MemoryRegionSection *section);
+    void (*log_stop)(MemoryListener *listener, MemoryRegionSection *section);
+    void (*log_sync)(MemoryListener *listener, MemoryRegionSection *section);
+    void (*log_global_start)(MemoryListener *listener);
+    void (*log_global_stop)(MemoryListener *listener);
+    QLIST_ENTRY(MemoryListener) link;
+};
+
 /**
  * memory_region_init: Initialize a memory region
  *
@@ -576,6 +597,32 @@ void memory_region_transaction_begin(void);
  */
 void memory_region_transaction_commit(void);
 
+/**
+ * memory_listener_register: register callbacks to be called when memory
+ *                           sections are mapped or unmapped into an address
+ *                           space
+ *
+ * @listener: an object containing the callbacks to be called
+ */
+void memory_listener_register(MemoryListener *listener);
+
+/**
+ * memory_listener_unregister: undo the effect of memory_listener_register()
+ *
+ * @listener: an object containing the callbacks to be removed
+ */
+void memory_listener_unregister(MemoryListener *listener);
+
+/**
+ * memory_global_dirty_log_start: begin dirty logging for all regions
+ */
+void memory_global_dirty_log_start(void);
+
+/**
+ * memory_global_dirty_log_stop: begin dirty logging for all regions
+ */
+void memory_global_dirty_log_stop(void);
+
 void mtree_info(fprintf_function mon_printf, void *f);
 
 #endif
-- 
1.7.7.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 14:14:29 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 14:14:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rcdyp-0007G8-0U; Mon, 19 Dec 2011 14:14:15 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <avi@redhat.com>) id 1Rcdym-0007C4-EY
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 14:14:12 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1324304044!8529882!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDY0OTI=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24286 invoked from network); 19 Dec 2011 14:14:04 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-10.tower-21.messagelabs.com with SMTP;
	19 Dec 2011 14:14:04 -0000
Received: from int-mx12.intmail.prod.int.phx2.redhat.com
	(int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id pBJEE2h6024938
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 19 Dec 2011 09:14:02 -0500
Received: from cleopatra.tlv.redhat.com (cleopatra.tlv.redhat.com
	[10.35.255.11])
	by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id pBJEE07g032288; Mon, 19 Dec 2011 09:14:01 -0500
Received: from s01.tlv.redhat.com (s01.tlv.redhat.com [10.35.255.8])
	by cleopatra.tlv.redhat.com (Postfix) with ESMTP id A1696250BA5;
	Mon, 19 Dec 2011 16:13:54 +0200 (IST)
From: Avi Kivity <avi@redhat.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	qemu-devel@nongnu.org, "Michael S. Tsirkin" <mst@redhat.com>
Date: Mon, 19 Dec 2011 16:13:27 +0200
Message-Id: <1324304024-11220-7-git-send-email-avi@redhat.com>
In-Reply-To: <1324304024-11220-1-git-send-email-avi@redhat.com>
References: <1324304024-11220-1-git-send-email-avi@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.25
Cc: xen-devel@lists.xensource.com, kvm@vger.kernel.org
Subject: [Xen-devel] [PATCH 06/23] loader: remove calls to
	cpu_get_physical_page_desc()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

cpu_get_physical_page_desc() is tied into the memory core's
innards, replace it with uses of the API.

Signed-off-by: Avi Kivity <avi@redhat.com>
---
 hw/loader.c |    9 +++++----
 1 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/hw/loader.c b/hw/loader.c
index 9bbcddd..7af5411 100644
--- a/hw/loader.c
+++ b/hw/loader.c
@@ -49,6 +49,8 @@
 #include "uboot_image.h"
 #include "loader.h"
 #include "fw_cfg.h"
+#include "memory.h"
+#include "exec-memory.h"
 
 #include <zlib.h>
 
@@ -674,7 +676,7 @@ static void rom_reset(void *unused)
 int rom_load_all(void)
 {
     target_phys_addr_t addr = 0;
-    int memtype;
+    MemoryRegionSection section;
     Rom *rom;
 
     QTAILQ_FOREACH(rom, &roms, next) {
@@ -690,9 +692,8 @@ int rom_load_all(void)
         }
         addr  = rom->addr;
         addr += rom->romsize;
-        memtype = cpu_get_physical_page_desc(rom->addr) & (3 << IO_MEM_SHIFT);
-        if (memtype == IO_MEM_ROM)
-            rom->isrom = 1;
+        section = memory_region_find(get_system_memory(), rom->addr, 1);
+        rom->isrom = section.mr && memory_region_is_rom(section.mr);
     }
     qemu_register_reset(rom_reset, NULL);
     roms_loaded = 1;
-- 
1.7.7.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 14:14:29 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 14:14:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rcdyp-0007G8-0U; Mon, 19 Dec 2011 14:14:15 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <avi@redhat.com>) id 1Rcdym-0007C4-EY
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 14:14:12 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1324304044!8529882!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDY0OTI=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24286 invoked from network); 19 Dec 2011 14:14:04 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-10.tower-21.messagelabs.com with SMTP;
	19 Dec 2011 14:14:04 -0000
Received: from int-mx12.intmail.prod.int.phx2.redhat.com
	(int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id pBJEE2h6024938
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 19 Dec 2011 09:14:02 -0500
Received: from cleopatra.tlv.redhat.com (cleopatra.tlv.redhat.com
	[10.35.255.11])
	by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id pBJEE07g032288; Mon, 19 Dec 2011 09:14:01 -0500
Received: from s01.tlv.redhat.com (s01.tlv.redhat.com [10.35.255.8])
	by cleopatra.tlv.redhat.com (Postfix) with ESMTP id A1696250BA5;
	Mon, 19 Dec 2011 16:13:54 +0200 (IST)
From: Avi Kivity <avi@redhat.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	qemu-devel@nongnu.org, "Michael S. Tsirkin" <mst@redhat.com>
Date: Mon, 19 Dec 2011 16:13:27 +0200
Message-Id: <1324304024-11220-7-git-send-email-avi@redhat.com>
In-Reply-To: <1324304024-11220-1-git-send-email-avi@redhat.com>
References: <1324304024-11220-1-git-send-email-avi@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.25
Cc: xen-devel@lists.xensource.com, kvm@vger.kernel.org
Subject: [Xen-devel] [PATCH 06/23] loader: remove calls to
	cpu_get_physical_page_desc()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

cpu_get_physical_page_desc() is tied into the memory core's
innards, replace it with uses of the API.

Signed-off-by: Avi Kivity <avi@redhat.com>
---
 hw/loader.c |    9 +++++----
 1 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/hw/loader.c b/hw/loader.c
index 9bbcddd..7af5411 100644
--- a/hw/loader.c
+++ b/hw/loader.c
@@ -49,6 +49,8 @@
 #include "uboot_image.h"
 #include "loader.h"
 #include "fw_cfg.h"
+#include "memory.h"
+#include "exec-memory.h"
 
 #include <zlib.h>
 
@@ -674,7 +676,7 @@ static void rom_reset(void *unused)
 int rom_load_all(void)
 {
     target_phys_addr_t addr = 0;
-    int memtype;
+    MemoryRegionSection section;
     Rom *rom;
 
     QTAILQ_FOREACH(rom, &roms, next) {
@@ -690,9 +692,8 @@ int rom_load_all(void)
         }
         addr  = rom->addr;
         addr += rom->romsize;
-        memtype = cpu_get_physical_page_desc(rom->addr) & (3 << IO_MEM_SHIFT);
-        if (memtype == IO_MEM_ROM)
-            rom->isrom = 1;
+        section = memory_region_find(get_system_memory(), rom->addr, 1);
+        rom->isrom = section.mr && memory_region_is_rom(section.mr);
     }
     qemu_register_reset(rom_reset, NULL);
     roms_loaded = 1;
-- 
1.7.7.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 14:14:29 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 14:14:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rcdyn-0007F8-Nd; Mon, 19 Dec 2011 14:14:13 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <avi@redhat.com>) id 1Rcdyl-0007C2-Mw
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 14:14:11 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1324304044!8039463!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDY0OTI=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27730 invoked from network); 19 Dec 2011 14:14:05 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-9.tower-216.messagelabs.com with SMTP;
	19 Dec 2011 14:14:05 -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 pBJEE2p8004308
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 19 Dec 2011 09:14:02 -0500
Received: from cleopatra.tlv.redhat.com (cleopatra.tlv.redhat.com
	[10.35.255.11])
	by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id pBJEE1G8015710; Mon, 19 Dec 2011 09:14:02 -0500
Received: from s01.tlv.redhat.com (s01.tlv.redhat.com [10.35.255.8])
	by cleopatra.tlv.redhat.com (Postfix) with ESMTP id A4CEB250BA6;
	Mon, 19 Dec 2011 16:13:54 +0200 (IST)
From: Avi Kivity <avi@redhat.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	qemu-devel@nongnu.org, "Michael S. Tsirkin" <mst@redhat.com>
Date: Mon, 19 Dec 2011 16:13:28 +0200
Message-Id: <1324304024-11220-8-git-send-email-avi@redhat.com>
In-Reply-To: <1324304024-11220-1-git-send-email-avi@redhat.com>
References: <1324304024-11220-1-git-send-email-avi@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
Cc: xen-devel@lists.xensource.com, kvm@vger.kernel.org
Subject: [Xen-devel] [PATCH 07/23] framebuffer: drop use of
	cpu_physical_sync_dirty_bitmap()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Replace with memory API equivalent.

Signed-off-by: Avi Kivity <avi@redhat.com>
---
 hw/framebuffer.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/hw/framebuffer.c b/hw/framebuffer.c
index 3f4e773..b43bcdf 100644
--- a/hw/framebuffer.c
+++ b/hw/framebuffer.c
@@ -50,7 +50,6 @@ void framebuffer_update_display(
     *first_row = -1;
     src_len = src_width * rows;
 
-    cpu_physical_sync_dirty_bitmap(base, base + src_len);
     mem_section = memory_region_find(address_space, base, src_len);
     if (mem_section.size != src_len || !memory_region_is_ram(mem_section.mr)) {
         return;
@@ -59,6 +58,7 @@ void framebuffer_update_display(
     assert(mem);
     assert(mem_section.offset_within_address_space == base);
 
+    memory_region_sync_dirty_bitmap(mem);
     src_base = cpu_physical_memory_map(base, &src_len, 0);
     /* If we can't map the framebuffer then bail.  We could try harder,
        but it's not really worth it as dirty flag tracking will probably
-- 
1.7.7.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 14:14:29 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 14:14:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rcdyn-0007F8-Nd; Mon, 19 Dec 2011 14:14:13 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <avi@redhat.com>) id 1Rcdyl-0007C2-Mw
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 14:14:11 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1324304044!8039463!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDY0OTI=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27730 invoked from network); 19 Dec 2011 14:14:05 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-9.tower-216.messagelabs.com with SMTP;
	19 Dec 2011 14:14:05 -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 pBJEE2p8004308
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 19 Dec 2011 09:14:02 -0500
Received: from cleopatra.tlv.redhat.com (cleopatra.tlv.redhat.com
	[10.35.255.11])
	by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id pBJEE1G8015710; Mon, 19 Dec 2011 09:14:02 -0500
Received: from s01.tlv.redhat.com (s01.tlv.redhat.com [10.35.255.8])
	by cleopatra.tlv.redhat.com (Postfix) with ESMTP id A4CEB250BA6;
	Mon, 19 Dec 2011 16:13:54 +0200 (IST)
From: Avi Kivity <avi@redhat.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	qemu-devel@nongnu.org, "Michael S. Tsirkin" <mst@redhat.com>
Date: Mon, 19 Dec 2011 16:13:28 +0200
Message-Id: <1324304024-11220-8-git-send-email-avi@redhat.com>
In-Reply-To: <1324304024-11220-1-git-send-email-avi@redhat.com>
References: <1324304024-11220-1-git-send-email-avi@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
Cc: xen-devel@lists.xensource.com, kvm@vger.kernel.org
Subject: [Xen-devel] [PATCH 07/23] framebuffer: drop use of
	cpu_physical_sync_dirty_bitmap()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Replace with memory API equivalent.

Signed-off-by: Avi Kivity <avi@redhat.com>
---
 hw/framebuffer.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/hw/framebuffer.c b/hw/framebuffer.c
index 3f4e773..b43bcdf 100644
--- a/hw/framebuffer.c
+++ b/hw/framebuffer.c
@@ -50,7 +50,6 @@ void framebuffer_update_display(
     *first_row = -1;
     src_len = src_width * rows;
 
-    cpu_physical_sync_dirty_bitmap(base, base + src_len);
     mem_section = memory_region_find(address_space, base, src_len);
     if (mem_section.size != src_len || !memory_region_is_ram(mem_section.mr)) {
         return;
@@ -59,6 +58,7 @@ void framebuffer_update_display(
     assert(mem);
     assert(mem_section.offset_within_address_space == base);
 
+    memory_region_sync_dirty_bitmap(mem);
     src_base = cpu_physical_memory_map(base, &src_len, 0);
     /* If we can't map the framebuffer then bail.  We could try harder,
        but it's not really worth it as dirty flag tracking will probably
-- 
1.7.7.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 14:14:29 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 14:14:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rcdyq-0007Hp-U2; Mon, 19 Dec 2011 14:14:16 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <avi@redhat.com>) id 1Rcdyn-0007CE-Fo
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 14:14:13 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1324304046!8009610!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDY0OTI=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6723 invoked from network); 19 Dec 2011 14:14:07 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-6.tower-216.messagelabs.com with SMTP;
	19 Dec 2011 14:14: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 pBJEE41V012049
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 19 Dec 2011 09:14:04 -0500
Received: from cleopatra.tlv.redhat.com (cleopatra.tlv.redhat.com
	[10.35.255.11])
	by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id pBJEE31Y006999; Mon, 19 Dec 2011 09:14:04 -0500
Received: from s01.tlv.redhat.com (s01.tlv.redhat.com [10.35.255.8])
	by cleopatra.tlv.redhat.com (Postfix) with ESMTP id B74EB250BAE;
	Mon, 19 Dec 2011 16:13:54 +0200 (IST)
From: Avi Kivity <avi@redhat.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	qemu-devel@nongnu.org, "Michael S. Tsirkin" <mst@redhat.com>
Date: Mon, 19 Dec 2011 16:13:36 +0200
Message-Id: <1324304024-11220-16-git-send-email-avi@redhat.com>
In-Reply-To: <1324304024-11220-1-git-send-email-avi@redhat.com>
References: <1324304024-11220-1-git-send-email-avi@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
Cc: xen-devel@lists.xensource.com, kvm@vger.kernel.org
Subject: [Xen-devel] [PATCH 15/23] xen,
	vga: add API for registering the framebuffer
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Xen currently uses the name of a memory region to determine whether it
is the framebuffer.  Replace with an explicit API.

Signed-off-by: Avi Kivity <avi@redhat.com>
---
 hw/vga.c   |    2 ++
 hw/xen.h   |    3 +++
 xen-all.c  |    6 ++++++
 xen-stub.c |    4 ++++
 4 files changed, 15 insertions(+), 0 deletions(-)

diff --git a/hw/vga.c b/hw/vga.c
index ca79aa1..7e1dd5a 100644
--- a/hw/vga.c
+++ b/hw/vga.c
@@ -28,6 +28,7 @@
 #include "vga_int.h"
 #include "pixel_ops.h"
 #include "qemu-timer.h"
+#include "xen.h"
 
 //#define DEBUG_VGA
 //#define DEBUG_VGA_MEM
@@ -2222,6 +2223,7 @@ void vga_common_init(VGACommonState *s, int vga_ram_size)
     s->is_vbe_vmstate = 0;
 #endif
     memory_region_init_ram(&s->vram, NULL, "vga.vram", vga_ram_size);
+    xen_register_framebuffer(&s->vram);
     s->vram_ptr = memory_region_get_ram_ptr(&s->vram);
     s->vram_size = vga_ram_size;
     s->get_bpp = vga_get_bpp;
diff --git a/hw/xen.h b/hw/xen.h
index f9f66e8..b46879c 100644
--- a/hw/xen.h
+++ b/hw/xen.h
@@ -49,6 +49,9 @@ void xen_ram_alloc(ram_addr_t ram_addr, ram_addr_t size,
                    struct MemoryRegion *mr);
 #endif
 
+struct MemoryRegion;
+void xen_register_framebuffer(struct MemoryRegion *mr);
+
 #if defined(CONFIG_XEN) && CONFIG_XEN_CTRL_INTERFACE_VERSION < 400
 #  define HVM_MAX_VCPUS 32
 #endif
diff --git a/xen-all.c b/xen-all.c
index bd89889..51315ce 100644
--- a/xen-all.c
+++ b/xen-all.c
@@ -33,6 +33,7 @@
 #endif
 
 static MemoryRegion ram_memory, ram_640k, ram_lo, ram_hi;
+static MemoryRegion *framebuffer;
 
 /* Compatibility with older version */
 #if __XEN_LATEST_INTERFACE_VERSION__ < 0x0003020a
@@ -982,3 +983,8 @@ void destroy_hvm_domain(void)
         xc_interface_close(xc_handle);
     }
 }
+
+void xen_register_framebuffer(MemoryRegion *mr)
+{
+    framebuffer = mr;
+}
diff --git a/xen-stub.c b/xen-stub.c
index 5fa400f..d403d86 100644
--- a/xen-stub.c
+++ b/xen-stub.c
@@ -44,3 +44,7 @@ int xen_init(void)
 {
     return -ENOSYS;
 }
+
+void xen_register_framebuffer(MemoryRegion *mr)
+{
+}
-- 
1.7.7.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 14:14:29 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 14:14:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rcdyq-0007Hp-U2; Mon, 19 Dec 2011 14:14:16 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <avi@redhat.com>) id 1Rcdyn-0007CE-Fo
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 14:14:13 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1324304046!8009610!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDY0OTI=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6723 invoked from network); 19 Dec 2011 14:14:07 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-6.tower-216.messagelabs.com with SMTP;
	19 Dec 2011 14:14: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 pBJEE41V012049
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 19 Dec 2011 09:14:04 -0500
Received: from cleopatra.tlv.redhat.com (cleopatra.tlv.redhat.com
	[10.35.255.11])
	by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id pBJEE31Y006999; Mon, 19 Dec 2011 09:14:04 -0500
Received: from s01.tlv.redhat.com (s01.tlv.redhat.com [10.35.255.8])
	by cleopatra.tlv.redhat.com (Postfix) with ESMTP id B74EB250BAE;
	Mon, 19 Dec 2011 16:13:54 +0200 (IST)
From: Avi Kivity <avi@redhat.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	qemu-devel@nongnu.org, "Michael S. Tsirkin" <mst@redhat.com>
Date: Mon, 19 Dec 2011 16:13:36 +0200
Message-Id: <1324304024-11220-16-git-send-email-avi@redhat.com>
In-Reply-To: <1324304024-11220-1-git-send-email-avi@redhat.com>
References: <1324304024-11220-1-git-send-email-avi@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
Cc: xen-devel@lists.xensource.com, kvm@vger.kernel.org
Subject: [Xen-devel] [PATCH 15/23] xen,
	vga: add API for registering the framebuffer
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Xen currently uses the name of a memory region to determine whether it
is the framebuffer.  Replace with an explicit API.

Signed-off-by: Avi Kivity <avi@redhat.com>
---
 hw/vga.c   |    2 ++
 hw/xen.h   |    3 +++
 xen-all.c  |    6 ++++++
 xen-stub.c |    4 ++++
 4 files changed, 15 insertions(+), 0 deletions(-)

diff --git a/hw/vga.c b/hw/vga.c
index ca79aa1..7e1dd5a 100644
--- a/hw/vga.c
+++ b/hw/vga.c
@@ -28,6 +28,7 @@
 #include "vga_int.h"
 #include "pixel_ops.h"
 #include "qemu-timer.h"
+#include "xen.h"
 
 //#define DEBUG_VGA
 //#define DEBUG_VGA_MEM
@@ -2222,6 +2223,7 @@ void vga_common_init(VGACommonState *s, int vga_ram_size)
     s->is_vbe_vmstate = 0;
 #endif
     memory_region_init_ram(&s->vram, NULL, "vga.vram", vga_ram_size);
+    xen_register_framebuffer(&s->vram);
     s->vram_ptr = memory_region_get_ram_ptr(&s->vram);
     s->vram_size = vga_ram_size;
     s->get_bpp = vga_get_bpp;
diff --git a/hw/xen.h b/hw/xen.h
index f9f66e8..b46879c 100644
--- a/hw/xen.h
+++ b/hw/xen.h
@@ -49,6 +49,9 @@ void xen_ram_alloc(ram_addr_t ram_addr, ram_addr_t size,
                    struct MemoryRegion *mr);
 #endif
 
+struct MemoryRegion;
+void xen_register_framebuffer(struct MemoryRegion *mr);
+
 #if defined(CONFIG_XEN) && CONFIG_XEN_CTRL_INTERFACE_VERSION < 400
 #  define HVM_MAX_VCPUS 32
 #endif
diff --git a/xen-all.c b/xen-all.c
index bd89889..51315ce 100644
--- a/xen-all.c
+++ b/xen-all.c
@@ -33,6 +33,7 @@
 #endif
 
 static MemoryRegion ram_memory, ram_640k, ram_lo, ram_hi;
+static MemoryRegion *framebuffer;
 
 /* Compatibility with older version */
 #if __XEN_LATEST_INTERFACE_VERSION__ < 0x0003020a
@@ -982,3 +983,8 @@ void destroy_hvm_domain(void)
         xc_interface_close(xc_handle);
     }
 }
+
+void xen_register_framebuffer(MemoryRegion *mr)
+{
+    framebuffer = mr;
+}
diff --git a/xen-stub.c b/xen-stub.c
index 5fa400f..d403d86 100644
--- a/xen-stub.c
+++ b/xen-stub.c
@@ -44,3 +44,7 @@ int xen_init(void)
 {
     return -ENOSYS;
 }
+
+void xen_register_framebuffer(MemoryRegion *mr)
+{
+}
-- 
1.7.7.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 14:14:29 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 14:14:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rcdyp-0007Gp-So; Mon, 19 Dec 2011 14:14:15 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <avi@redhat.com>) id 1Rcdym-0007C7-Sf
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 14:14:13 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1324304045!8037989!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDY0OTI=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5600 invoked from network); 19 Dec 2011 14:14:06 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-7.tower-21.messagelabs.com with SMTP;
	19 Dec 2011 14:14:06 -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 pBJEE3rT004316
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 19 Dec 2011 09:14:03 -0500
Received: from cleopatra.tlv.redhat.com (cleopatra.tlv.redhat.com
	[10.35.255.11])
	by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id pBJEE1GA015710; Mon, 19 Dec 2011 09:14:03 -0500
Received: from s01.tlv.redhat.com (s01.tlv.redhat.com [10.35.255.8])
	by cleopatra.tlv.redhat.com (Postfix) with ESMTP id B124D250BAB;
	Mon, 19 Dec 2011 16:13:54 +0200 (IST)
From: Avi Kivity <avi@redhat.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	qemu-devel@nongnu.org, "Michael S. Tsirkin" <mst@redhat.com>
Date: Mon, 19 Dec 2011 16:13:33 +0200
Message-Id: <1324304024-11220-13-git-send-email-avi@redhat.com>
In-Reply-To: <1324304024-11220-1-git-send-email-avi@redhat.com>
References: <1324304024-11220-1-git-send-email-avi@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
Cc: xen-devel@lists.xensource.com, kvm@vger.kernel.org
Subject: [Xen-devel] [PATCH 12/23] fixup: listener fixes
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

---
 memory.c |    7 ++++---
 1 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/memory.c b/memory.c
index c08186d..2dcbf80 100644
--- a/memory.c
+++ b/memory.c
@@ -708,13 +708,13 @@ static void memory_listener_update_region(FlatRange *fr, AddressSpace *as,
         .address_space = as->root,
         .offset_within_region = fr->offset_in_region,
         .size = int128_get64(fr->addr.size),
-        .offset_within_region = int128_get64(fr->addr.start),
+        .offset_within_address_space = int128_get64(fr->addr.start),
     };
     MemoryListener *listener;
 
     QLIST_FOREACH(listener, &memory_listeners, link) {
         ListenerCallback *callback
-            = *(ListenerCallback *)((void *)listener + callback_offset);
+            = *(ListenerCallback **)((void *)listener + callback_offset);
         callback(listener, &section);
     }
 }
@@ -1149,6 +1149,7 @@ void memory_region_sync_dirty_bitmap(MemoryRegion *mr)
 
     FOR_EACH_FLAT_RANGE(fr, &address_space_memory.current_map) {
         if (fr->mr == mr) {
+            MEMORY_LISTENER_UPDATE_REGION(fr, &address_space_memory, log_sync);
             cpu_physical_sync_dirty_bitmap(int128_get64(fr->addr.start),
                                            int128_get64(addrrange_end(fr->addr)));
         }
@@ -1467,7 +1468,7 @@ static void listener_add_address_space(MemoryListener *listener,
             .address_space = as->root,
             .offset_within_region = fr->offset_in_region,
             .size = int128_get64(fr->addr.size),
-            .offset_within_region = int128_get64(fr->addr.start),
+            .offset_within_address_space = int128_get64(fr->addr.start),
         };
         listener->region_add(listener, &section);
     }
-- 
1.7.7.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 14:14:29 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 14:14:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rcdyp-0007Gp-So; Mon, 19 Dec 2011 14:14:15 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <avi@redhat.com>) id 1Rcdym-0007C7-Sf
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 14:14:13 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1324304045!8037989!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDY0OTI=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5600 invoked from network); 19 Dec 2011 14:14:06 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-7.tower-21.messagelabs.com with SMTP;
	19 Dec 2011 14:14:06 -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 pBJEE3rT004316
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 19 Dec 2011 09:14:03 -0500
Received: from cleopatra.tlv.redhat.com (cleopatra.tlv.redhat.com
	[10.35.255.11])
	by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id pBJEE1GA015710; Mon, 19 Dec 2011 09:14:03 -0500
Received: from s01.tlv.redhat.com (s01.tlv.redhat.com [10.35.255.8])
	by cleopatra.tlv.redhat.com (Postfix) with ESMTP id B124D250BAB;
	Mon, 19 Dec 2011 16:13:54 +0200 (IST)
From: Avi Kivity <avi@redhat.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	qemu-devel@nongnu.org, "Michael S. Tsirkin" <mst@redhat.com>
Date: Mon, 19 Dec 2011 16:13:33 +0200
Message-Id: <1324304024-11220-13-git-send-email-avi@redhat.com>
In-Reply-To: <1324304024-11220-1-git-send-email-avi@redhat.com>
References: <1324304024-11220-1-git-send-email-avi@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
Cc: xen-devel@lists.xensource.com, kvm@vger.kernel.org
Subject: [Xen-devel] [PATCH 12/23] fixup: listener fixes
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

---
 memory.c |    7 ++++---
 1 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/memory.c b/memory.c
index c08186d..2dcbf80 100644
--- a/memory.c
+++ b/memory.c
@@ -708,13 +708,13 @@ static void memory_listener_update_region(FlatRange *fr, AddressSpace *as,
         .address_space = as->root,
         .offset_within_region = fr->offset_in_region,
         .size = int128_get64(fr->addr.size),
-        .offset_within_region = int128_get64(fr->addr.start),
+        .offset_within_address_space = int128_get64(fr->addr.start),
     };
     MemoryListener *listener;
 
     QLIST_FOREACH(listener, &memory_listeners, link) {
         ListenerCallback *callback
-            = *(ListenerCallback *)((void *)listener + callback_offset);
+            = *(ListenerCallback **)((void *)listener + callback_offset);
         callback(listener, &section);
     }
 }
@@ -1149,6 +1149,7 @@ void memory_region_sync_dirty_bitmap(MemoryRegion *mr)
 
     FOR_EACH_FLAT_RANGE(fr, &address_space_memory.current_map) {
         if (fr->mr == mr) {
+            MEMORY_LISTENER_UPDATE_REGION(fr, &address_space_memory, log_sync);
             cpu_physical_sync_dirty_bitmap(int128_get64(fr->addr.start),
                                            int128_get64(addrrange_end(fr->addr)));
         }
@@ -1467,7 +1468,7 @@ static void listener_add_address_space(MemoryListener *listener,
             .address_space = as->root,
             .offset_within_region = fr->offset_in_region,
             .size = int128_get64(fr->addr.size),
-            .offset_within_region = int128_get64(fr->addr.start),
+            .offset_within_address_space = int128_get64(fr->addr.start),
         };
         listener->region_add(listener, &section);
     }
-- 
1.7.7.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 14:14:31 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 14:14:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rcdys-0007J6-3a; Mon, 19 Dec 2011 14:14:18 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <avi@redhat.com>) id 1Rcdyn-0007CT-U3
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 14:14:14 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1324304046!8037994!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDY0OTI=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5652 invoked from network); 19 Dec 2011 14:14:07 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-7.tower-21.messagelabs.com with SMTP;
	19 Dec 2011 14:14:07 -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 pBJEE4YD008966
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 19 Dec 2011 09:14:04 -0500
Received: from cleopatra.tlv.redhat.com (cleopatra.tlv.redhat.com
	[10.35.255.11])
	by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id pBJEE1GC015710; Mon, 19 Dec 2011 09:14:04 -0500
Received: from s01.tlv.redhat.com (s01.tlv.redhat.com [10.35.255.8])
	by cleopatra.tlv.redhat.com (Postfix) with ESMTP id BCBB4250BB0;
	Mon, 19 Dec 2011 16:13:54 +0200 (IST)
From: Avi Kivity <avi@redhat.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	qemu-devel@nongnu.org, "Michael S. Tsirkin" <mst@redhat.com>
Date: Mon, 19 Dec 2011 16:13:38 +0200
Message-Id: <1324304024-11220-18-git-send-email-avi@redhat.com>
In-Reply-To: <1324304024-11220-1-git-send-email-avi@redhat.com>
References: <1324304024-11220-1-git-send-email-avi@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
Cc: xen-devel@lists.xensource.com, kvm@vger.kernel.org
Subject: [Xen-devel] [PATCH 17/23] xen: convert to MemoryListener API
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Signed-off-by: Avi Kivity <avi@redhat.com>
---
 trace-events |    2 +-
 xen-all.c    |  137 ++++++++++++++++++++++++++++++++++------------------------
 2 files changed, 81 insertions(+), 58 deletions(-)

diff --git a/trace-events b/trace-events
index bf1cf57..728df97 100644
--- a/trace-events
+++ b/trace-events
@@ -464,7 +464,7 @@ mipsnet_irq(uint32_t isr, uint32_t intctl) "set irq to %d (%02x)"
 
 # xen-all.c
 xen_ram_alloc(unsigned long ram_addr, unsigned long size) "requested: %#lx, size %#lx"
-xen_client_set_memory(uint64_t start_addr, unsigned long size, unsigned long phys_offset, bool log_dirty) "%#"PRIx64" size %#lx, offset %#lx, log_dirty %i"
+xen_client_set_memory(uint64_t start_addr, unsigned long size, bool log_dirty) "%#"PRIx64" size %#lx, log_dirty %i"
 
 # xen-mapcache.c
 xen_map_cache(uint64_t phys_addr) "want %#"PRIx64
diff --git a/xen-all.c b/xen-all.c
index 51315ce..e662dc5 100644
--- a/xen-all.c
+++ b/xen-all.c
@@ -63,6 +63,7 @@ static inline uint32_t xen_vcpu_eport(shared_iopage_t *shared_page, int i)
 typedef struct XenPhysmap {
     target_phys_addr_t start_addr;
     ram_addr_t size;
+    MemoryRegion *mr;
     target_phys_addr_t phys_offset;
 
     QLIST_ENTRY(XenPhysmap) list;
@@ -80,8 +81,9 @@ static inline uint32_t xen_vcpu_eport(shared_iopage_t *shared_page, int i)
     int send_vcpu;
 
     struct xs_handle *xenstore;
-    CPUPhysMemoryClient client;
+    MemoryListener memory_listener;
     QLIST_HEAD(, XenPhysmap) physmap;
+    target_phys_addr_t free_phys_offset;
     const XenPhysmap *log_for_dirtybit;
 
     Notifier exit;
@@ -226,13 +228,14 @@ void xen_ram_alloc(ram_addr_t ram_addr, ram_addr_t size, MemoryRegion *mr)
 static int xen_add_to_physmap(XenIOState *state,
                               target_phys_addr_t start_addr,
                               ram_addr_t size,
-                              target_phys_addr_t phys_offset)
+                              MemoryRegion *mr,
+                              target_phys_addr_t offset_within_region)
 {
     unsigned long i = 0;
     int rc = 0;
     XenPhysmap *physmap = NULL;
     target_phys_addr_t pfn, start_gpfn;
-    RAMBlock *block;
+    target_phys_addr_t phys_offset = memory_region_get_ram_addr(mr);
 
     if (get_physmapping(state, start_addr, size)) {
         return 0;
@@ -245,17 +248,13 @@ static int xen_add_to_physmap(XenIOState *state,
      * the linear framebuffer to be that region.
      * Avoid tracking any regions that is not videoram and avoid tracking
      * the legacy vga region. */
-    QLIST_FOREACH(block, &ram_list.blocks, next) {
-        if (!strcmp(block->idstr, "vga.vram") && block->offset == phys_offset
-                && start_addr > 0xbffff) {
-            goto go_physmap;
-        }
+    if (mr == framebuffer && start_addr > 0xbffff) {
+        goto go_physmap;
     }
     return -1;
 
 go_physmap:
-    DPRINTF("mapping vram to %llx - %llx, from %llx\n",
-            start_addr, start_addr + size, phys_offset);
+    DPRINTF("mapping vram to %llx - %llx\n", start_addr, start_addr + size);
 
     pfn = phys_offset >> TARGET_PAGE_BITS;
     start_gpfn = start_addr >> TARGET_PAGE_BITS;
@@ -347,49 +346,62 @@ static int xen_remove_from_physmap(XenIOState *state,
 }
 #endif
 
-static void xen_client_set_memory(struct CPUPhysMemoryClient *client,
-                                  target_phys_addr_t start_addr,
-                                  ram_addr_t size,
-                                  ram_addr_t phys_offset,
-                                  bool log_dirty)
+static void xen_set_memory(struct MemoryListener *listener,
+                           MemoryRegionSection *section,
+                           bool add)
 {
-    XenIOState *state = container_of(client, XenIOState, client);
-    ram_addr_t flags = phys_offset & ~TARGET_PAGE_MASK;
+    XenIOState *state = container_of(listener, XenIOState, memory_listener);
+    target_phys_addr_t start_addr = section->offset_within_address_space;
+    ram_addr_t size = section->size;
+    bool log_dirty = memory_region_is_logging(section->mr);
     hvmmem_type_t mem_type;
 
-    if (!(start_addr != phys_offset
-          && ( (log_dirty && flags < IO_MEM_UNASSIGNED)
-               || (!log_dirty && flags == IO_MEM_UNASSIGNED)))) {
+    if (!memory_region_is_ram(section->mr)) {
+        return;
+    }
+
+    if (!(section->mr != &ram_memory
+          && ( (log_dirty && add) || (!log_dirty && !add)))) {
         return;
     }
 
-    trace_xen_client_set_memory(start_addr, size, phys_offset, log_dirty);
+    trace_xen_client_set_memory(start_addr, size, log_dirty);
 
     start_addr &= TARGET_PAGE_MASK;
     size = TARGET_PAGE_ALIGN(size);
-    phys_offset &= TARGET_PAGE_MASK;
-
-    switch (flags) {
-    case IO_MEM_RAM:
-        xen_add_to_physmap(state, start_addr, size, phys_offset);
-        break;
-    case IO_MEM_ROM:
-        mem_type = HVMMEM_ram_ro;
-        if (xc_hvm_set_mem_type(xen_xc, xen_domid, mem_type,
-                                start_addr >> TARGET_PAGE_BITS,
-                                size >> TARGET_PAGE_BITS)) {
-            DPRINTF("xc_hvm_set_mem_type error, addr: "TARGET_FMT_plx"\n",
-                    start_addr);
+
+    if (add) {
+        if (!memory_region_is_rom(section->mr)) {
+            xen_add_to_physmap(state, start_addr, size,
+                               section->mr, section->offset_within_region);
+        } else {
+            mem_type = HVMMEM_ram_ro;
+            if (xc_hvm_set_mem_type(xen_xc, xen_domid, mem_type,
+                                    start_addr >> TARGET_PAGE_BITS,
+                                    size >> TARGET_PAGE_BITS)) {
+                DPRINTF("xc_hvm_set_mem_type error, addr: "TARGET_FMT_plx"\n",
+                        start_addr);
+            }
         }
-        break;
-    case IO_MEM_UNASSIGNED:
+    } else {
         if (xen_remove_from_physmap(state, start_addr, size) < 0) {
             DPRINTF("physmapping does not exist at "TARGET_FMT_plx"\n", start_addr);
         }
-        break;
     }
 }
 
+static void xen_region_add(MemoryListener *listener,
+                           MemoryRegionSection *section)
+{
+    xen_set_memory(listener, section, true);
+}
+
+static void xen_region_del(MemoryListener *listener,
+                           MemoryRegionSection *section)
+{
+    xen_set_memory(listener, section, false);
+}
+
 static int xen_sync_dirty_bitmap(XenIOState *state,
                                  target_phys_addr_t start_addr,
                                  ram_addr_t size)
@@ -433,43 +445,54 @@ static int xen_sync_dirty_bitmap(XenIOState *state,
     return 0;
 }
 
-static int xen_log_start(CPUPhysMemoryClient *client, target_phys_addr_t phys_addr, ram_addr_t size)
+static void xen_log_start(MemoryListener *listener,
+                          MemoryRegionSection *section)
 {
-    XenIOState *state = container_of(client, XenIOState, client);
+    XenIOState *state = container_of(listener, XenIOState, memory_listener);
+    int r;
 
-    return xen_sync_dirty_bitmap(state, phys_addr, size);
+    r = xen_sync_dirty_bitmap(state, section->offset_within_address_space,
+                              section->size);
+    assert(r >= 0);
 }
 
-static int xen_log_stop(CPUPhysMemoryClient *client, target_phys_addr_t phys_addr, ram_addr_t size)
+static void xen_log_stop(MemoryListener *listener, MemoryRegionSection *section)
 {
-    XenIOState *state = container_of(client, XenIOState, client);
+    XenIOState *state = container_of(listener, XenIOState, memory_listener);
+    int r;
 
     state->log_for_dirtybit = NULL;
     /* Disable dirty bit tracking */
-    return xc_hvm_track_dirty_vram(xen_xc, xen_domid, 0, 0, NULL);
+    r = xc_hvm_track_dirty_vram(xen_xc, xen_domid, 0, 0, NULL);
+    assert(r >= 0);
 }
 
-static int xen_client_sync_dirty_bitmap(struct CPUPhysMemoryClient *client,
-                                        target_phys_addr_t start_addr,
-                                        target_phys_addr_t end_addr)
+static void xen_log_sync(MemoryListener *listener, MemoryRegionSection *section)
 {
-    XenIOState *state = container_of(client, XenIOState, client);
+    XenIOState *state = container_of(listener, XenIOState, memory_listener);
+    int r;
 
-    return xen_sync_dirty_bitmap(state, start_addr, end_addr - start_addr);
+    r = xen_sync_dirty_bitmap(state, section->offset_within_address_space,
+                              section->size);
+    assert(r >= 0);
 }
 
-static int xen_client_migration_log(struct CPUPhysMemoryClient *client,
-                                    int enable)
+static void xen_log_global_start(MemoryListener *listener)
+{
+}
+
+static void xen_log_global_stop(MemoryListener *listener)
 {
-    return 0;
 }
 
-static CPUPhysMemoryClient xen_cpu_phys_memory_client = {
-    .set_memory = xen_client_set_memory,
-    .sync_dirty_bitmap = xen_client_sync_dirty_bitmap,
-    .migration_log = xen_client_migration_log,
+static MemoryListener xen_memory_listener = {
+    .region_add = xen_region_add,
+    .region_del = xen_region_del,
     .log_start = xen_log_start,
     .log_stop = xen_log_stop,
+    .log_sync = xen_log_sync,
+    .log_global_start = xen_log_global_start,
+    .log_global_stop = xen_log_global_stop,
 };
 
 /* VCPU Operations, MMIO, IO ring ... */
@@ -947,9 +970,9 @@ int xen_hvm_init(void)
 
     qemu_add_vm_change_state_handler(xen_hvm_change_state_handler, state);
 
-    state->client = xen_cpu_phys_memory_client;
+    state->memory_listener = xen_memory_listener;
     QLIST_INIT(&state->physmap);
-    cpu_register_phys_memory_client(&state->client);
+    memory_listener_register(&state->memory_listener);
     state->log_for_dirtybit = NULL;
 
     /* Initialize backend core & drivers */
-- 
1.7.7.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 14:14:31 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 14:14:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rcdys-0007J6-3a; Mon, 19 Dec 2011 14:14:18 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <avi@redhat.com>) id 1Rcdyn-0007CT-U3
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 14:14:14 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1324304046!8037994!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDY0OTI=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5652 invoked from network); 19 Dec 2011 14:14:07 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-7.tower-21.messagelabs.com with SMTP;
	19 Dec 2011 14:14:07 -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 pBJEE4YD008966
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 19 Dec 2011 09:14:04 -0500
Received: from cleopatra.tlv.redhat.com (cleopatra.tlv.redhat.com
	[10.35.255.11])
	by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id pBJEE1GC015710; Mon, 19 Dec 2011 09:14:04 -0500
Received: from s01.tlv.redhat.com (s01.tlv.redhat.com [10.35.255.8])
	by cleopatra.tlv.redhat.com (Postfix) with ESMTP id BCBB4250BB0;
	Mon, 19 Dec 2011 16:13:54 +0200 (IST)
From: Avi Kivity <avi@redhat.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	qemu-devel@nongnu.org, "Michael S. Tsirkin" <mst@redhat.com>
Date: Mon, 19 Dec 2011 16:13:38 +0200
Message-Id: <1324304024-11220-18-git-send-email-avi@redhat.com>
In-Reply-To: <1324304024-11220-1-git-send-email-avi@redhat.com>
References: <1324304024-11220-1-git-send-email-avi@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
Cc: xen-devel@lists.xensource.com, kvm@vger.kernel.org
Subject: [Xen-devel] [PATCH 17/23] xen: convert to MemoryListener API
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Signed-off-by: Avi Kivity <avi@redhat.com>
---
 trace-events |    2 +-
 xen-all.c    |  137 ++++++++++++++++++++++++++++++++++------------------------
 2 files changed, 81 insertions(+), 58 deletions(-)

diff --git a/trace-events b/trace-events
index bf1cf57..728df97 100644
--- a/trace-events
+++ b/trace-events
@@ -464,7 +464,7 @@ mipsnet_irq(uint32_t isr, uint32_t intctl) "set irq to %d (%02x)"
 
 # xen-all.c
 xen_ram_alloc(unsigned long ram_addr, unsigned long size) "requested: %#lx, size %#lx"
-xen_client_set_memory(uint64_t start_addr, unsigned long size, unsigned long phys_offset, bool log_dirty) "%#"PRIx64" size %#lx, offset %#lx, log_dirty %i"
+xen_client_set_memory(uint64_t start_addr, unsigned long size, bool log_dirty) "%#"PRIx64" size %#lx, log_dirty %i"
 
 # xen-mapcache.c
 xen_map_cache(uint64_t phys_addr) "want %#"PRIx64
diff --git a/xen-all.c b/xen-all.c
index 51315ce..e662dc5 100644
--- a/xen-all.c
+++ b/xen-all.c
@@ -63,6 +63,7 @@ static inline uint32_t xen_vcpu_eport(shared_iopage_t *shared_page, int i)
 typedef struct XenPhysmap {
     target_phys_addr_t start_addr;
     ram_addr_t size;
+    MemoryRegion *mr;
     target_phys_addr_t phys_offset;
 
     QLIST_ENTRY(XenPhysmap) list;
@@ -80,8 +81,9 @@ static inline uint32_t xen_vcpu_eport(shared_iopage_t *shared_page, int i)
     int send_vcpu;
 
     struct xs_handle *xenstore;
-    CPUPhysMemoryClient client;
+    MemoryListener memory_listener;
     QLIST_HEAD(, XenPhysmap) physmap;
+    target_phys_addr_t free_phys_offset;
     const XenPhysmap *log_for_dirtybit;
 
     Notifier exit;
@@ -226,13 +228,14 @@ void xen_ram_alloc(ram_addr_t ram_addr, ram_addr_t size, MemoryRegion *mr)
 static int xen_add_to_physmap(XenIOState *state,
                               target_phys_addr_t start_addr,
                               ram_addr_t size,
-                              target_phys_addr_t phys_offset)
+                              MemoryRegion *mr,
+                              target_phys_addr_t offset_within_region)
 {
     unsigned long i = 0;
     int rc = 0;
     XenPhysmap *physmap = NULL;
     target_phys_addr_t pfn, start_gpfn;
-    RAMBlock *block;
+    target_phys_addr_t phys_offset = memory_region_get_ram_addr(mr);
 
     if (get_physmapping(state, start_addr, size)) {
         return 0;
@@ -245,17 +248,13 @@ static int xen_add_to_physmap(XenIOState *state,
      * the linear framebuffer to be that region.
      * Avoid tracking any regions that is not videoram and avoid tracking
      * the legacy vga region. */
-    QLIST_FOREACH(block, &ram_list.blocks, next) {
-        if (!strcmp(block->idstr, "vga.vram") && block->offset == phys_offset
-                && start_addr > 0xbffff) {
-            goto go_physmap;
-        }
+    if (mr == framebuffer && start_addr > 0xbffff) {
+        goto go_physmap;
     }
     return -1;
 
 go_physmap:
-    DPRINTF("mapping vram to %llx - %llx, from %llx\n",
-            start_addr, start_addr + size, phys_offset);
+    DPRINTF("mapping vram to %llx - %llx\n", start_addr, start_addr + size);
 
     pfn = phys_offset >> TARGET_PAGE_BITS;
     start_gpfn = start_addr >> TARGET_PAGE_BITS;
@@ -347,49 +346,62 @@ static int xen_remove_from_physmap(XenIOState *state,
 }
 #endif
 
-static void xen_client_set_memory(struct CPUPhysMemoryClient *client,
-                                  target_phys_addr_t start_addr,
-                                  ram_addr_t size,
-                                  ram_addr_t phys_offset,
-                                  bool log_dirty)
+static void xen_set_memory(struct MemoryListener *listener,
+                           MemoryRegionSection *section,
+                           bool add)
 {
-    XenIOState *state = container_of(client, XenIOState, client);
-    ram_addr_t flags = phys_offset & ~TARGET_PAGE_MASK;
+    XenIOState *state = container_of(listener, XenIOState, memory_listener);
+    target_phys_addr_t start_addr = section->offset_within_address_space;
+    ram_addr_t size = section->size;
+    bool log_dirty = memory_region_is_logging(section->mr);
     hvmmem_type_t mem_type;
 
-    if (!(start_addr != phys_offset
-          && ( (log_dirty && flags < IO_MEM_UNASSIGNED)
-               || (!log_dirty && flags == IO_MEM_UNASSIGNED)))) {
+    if (!memory_region_is_ram(section->mr)) {
+        return;
+    }
+
+    if (!(section->mr != &ram_memory
+          && ( (log_dirty && add) || (!log_dirty && !add)))) {
         return;
     }
 
-    trace_xen_client_set_memory(start_addr, size, phys_offset, log_dirty);
+    trace_xen_client_set_memory(start_addr, size, log_dirty);
 
     start_addr &= TARGET_PAGE_MASK;
     size = TARGET_PAGE_ALIGN(size);
-    phys_offset &= TARGET_PAGE_MASK;
-
-    switch (flags) {
-    case IO_MEM_RAM:
-        xen_add_to_physmap(state, start_addr, size, phys_offset);
-        break;
-    case IO_MEM_ROM:
-        mem_type = HVMMEM_ram_ro;
-        if (xc_hvm_set_mem_type(xen_xc, xen_domid, mem_type,
-                                start_addr >> TARGET_PAGE_BITS,
-                                size >> TARGET_PAGE_BITS)) {
-            DPRINTF("xc_hvm_set_mem_type error, addr: "TARGET_FMT_plx"\n",
-                    start_addr);
+
+    if (add) {
+        if (!memory_region_is_rom(section->mr)) {
+            xen_add_to_physmap(state, start_addr, size,
+                               section->mr, section->offset_within_region);
+        } else {
+            mem_type = HVMMEM_ram_ro;
+            if (xc_hvm_set_mem_type(xen_xc, xen_domid, mem_type,
+                                    start_addr >> TARGET_PAGE_BITS,
+                                    size >> TARGET_PAGE_BITS)) {
+                DPRINTF("xc_hvm_set_mem_type error, addr: "TARGET_FMT_plx"\n",
+                        start_addr);
+            }
         }
-        break;
-    case IO_MEM_UNASSIGNED:
+    } else {
         if (xen_remove_from_physmap(state, start_addr, size) < 0) {
             DPRINTF("physmapping does not exist at "TARGET_FMT_plx"\n", start_addr);
         }
-        break;
     }
 }
 
+static void xen_region_add(MemoryListener *listener,
+                           MemoryRegionSection *section)
+{
+    xen_set_memory(listener, section, true);
+}
+
+static void xen_region_del(MemoryListener *listener,
+                           MemoryRegionSection *section)
+{
+    xen_set_memory(listener, section, false);
+}
+
 static int xen_sync_dirty_bitmap(XenIOState *state,
                                  target_phys_addr_t start_addr,
                                  ram_addr_t size)
@@ -433,43 +445,54 @@ static int xen_sync_dirty_bitmap(XenIOState *state,
     return 0;
 }
 
-static int xen_log_start(CPUPhysMemoryClient *client, target_phys_addr_t phys_addr, ram_addr_t size)
+static void xen_log_start(MemoryListener *listener,
+                          MemoryRegionSection *section)
 {
-    XenIOState *state = container_of(client, XenIOState, client);
+    XenIOState *state = container_of(listener, XenIOState, memory_listener);
+    int r;
 
-    return xen_sync_dirty_bitmap(state, phys_addr, size);
+    r = xen_sync_dirty_bitmap(state, section->offset_within_address_space,
+                              section->size);
+    assert(r >= 0);
 }
 
-static int xen_log_stop(CPUPhysMemoryClient *client, target_phys_addr_t phys_addr, ram_addr_t size)
+static void xen_log_stop(MemoryListener *listener, MemoryRegionSection *section)
 {
-    XenIOState *state = container_of(client, XenIOState, client);
+    XenIOState *state = container_of(listener, XenIOState, memory_listener);
+    int r;
 
     state->log_for_dirtybit = NULL;
     /* Disable dirty bit tracking */
-    return xc_hvm_track_dirty_vram(xen_xc, xen_domid, 0, 0, NULL);
+    r = xc_hvm_track_dirty_vram(xen_xc, xen_domid, 0, 0, NULL);
+    assert(r >= 0);
 }
 
-static int xen_client_sync_dirty_bitmap(struct CPUPhysMemoryClient *client,
-                                        target_phys_addr_t start_addr,
-                                        target_phys_addr_t end_addr)
+static void xen_log_sync(MemoryListener *listener, MemoryRegionSection *section)
 {
-    XenIOState *state = container_of(client, XenIOState, client);
+    XenIOState *state = container_of(listener, XenIOState, memory_listener);
+    int r;
 
-    return xen_sync_dirty_bitmap(state, start_addr, end_addr - start_addr);
+    r = xen_sync_dirty_bitmap(state, section->offset_within_address_space,
+                              section->size);
+    assert(r >= 0);
 }
 
-static int xen_client_migration_log(struct CPUPhysMemoryClient *client,
-                                    int enable)
+static void xen_log_global_start(MemoryListener *listener)
+{
+}
+
+static void xen_log_global_stop(MemoryListener *listener)
 {
-    return 0;
 }
 
-static CPUPhysMemoryClient xen_cpu_phys_memory_client = {
-    .set_memory = xen_client_set_memory,
-    .sync_dirty_bitmap = xen_client_sync_dirty_bitmap,
-    .migration_log = xen_client_migration_log,
+static MemoryListener xen_memory_listener = {
+    .region_add = xen_region_add,
+    .region_del = xen_region_del,
     .log_start = xen_log_start,
     .log_stop = xen_log_stop,
+    .log_sync = xen_log_sync,
+    .log_global_start = xen_log_global_start,
+    .log_global_stop = xen_log_global_stop,
 };
 
 /* VCPU Operations, MMIO, IO ring ... */
@@ -947,9 +970,9 @@ int xen_hvm_init(void)
 
     qemu_add_vm_change_state_handler(xen_hvm_change_state_handler, state);
 
-    state->client = xen_cpu_phys_memory_client;
+    state->memory_listener = xen_memory_listener;
     QLIST_INIT(&state->physmap);
-    cpu_register_phys_memory_client(&state->client);
+    memory_listener_register(&state->memory_listener);
     state->log_for_dirtybit = NULL;
 
     /* Initialize backend core & drivers */
-- 
1.7.7.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 14:14:36 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 14:14:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rcdyr-0007Ig-Mv; Mon, 19 Dec 2011 14:14:17 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <avi@redhat.com>) id 1Rcdyn-0007CY-Tk
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 14:14:14 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1324304047!7864116!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDY0OTI=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17100 invoked from network); 19 Dec 2011 14:14:07 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-3.tower-182.messagelabs.com with SMTP;
	19 Dec 2011 14:14:07 -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 pBJEE59n024960
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 19 Dec 2011 09:14:05 -0500
Received: from cleopatra.tlv.redhat.com (cleopatra.tlv.redhat.com
	[10.35.255.11])
	by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id pBJEE1GE015710; Mon, 19 Dec 2011 09:14:05 -0500
Received: from s01.tlv.redhat.com (s01.tlv.redhat.com [10.35.255.8])
	by cleopatra.tlv.redhat.com (Postfix) with ESMTP id CBBE1250BB5;
	Mon, 19 Dec 2011 16:13:54 +0200 (IST)
From: Avi Kivity <avi@redhat.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	qemu-devel@nongnu.org, "Michael S. Tsirkin" <mst@redhat.com>
Date: Mon, 19 Dec 2011 16:13:43 +0200
Message-Id: <1324304024-11220-23-git-send-email-avi@redhat.com>
In-Reply-To: <1324304024-11220-1-git-send-email-avi@redhat.com>
References: <1324304024-11220-1-git-send-email-avi@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
Cc: xen-devel@lists.xensource.com, kvm@vger.kernel.org
Subject: [Xen-devel] [PATCH 22/23] sparc: avoid cpu_get_physical_page_desc()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This reaches into the innards of the memory core, which are being
changed.  Switch to a memory API version.

Signed-off-by: Avi Kivity <avi@redhat.com>
---
 target-sparc/mmu_helper.c |    5 ++++-
 1 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/target-sparc/mmu_helper.c b/target-sparc/mmu_helper.c
index 8cdc224..eec8947 100644
--- a/target-sparc/mmu_helper.c
+++ b/target-sparc/mmu_helper.c
@@ -19,6 +19,7 @@
 
 #include "cpu.h"
 #include "trace.h"
+#include "exec-memory.h"
 
 /* Sparc MMU emulation */
 
@@ -839,13 +840,15 @@ target_phys_addr_t cpu_get_phys_page_debug(CPUState *env, target_ulong addr)
 {
     target_phys_addr_t phys_addr;
     int mmu_idx = cpu_mmu_index(env);
+    MemoryRegionSection section;
 
     if (cpu_sparc_get_phys_page(env, &phys_addr, addr, 2, mmu_idx) != 0) {
         if (cpu_sparc_get_phys_page(env, &phys_addr, addr, 0, mmu_idx) != 0) {
             return -1;
         }
     }
-    if (cpu_get_physical_page_desc(phys_addr) == IO_MEM_UNASSIGNED) {
+    section = memory_region_find(get_system_memory(), phys_addr, 1);
+    if (!section.mr) {
         return -1;
     }
     return phys_addr;
-- 
1.7.7.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 14:14:36 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 14:14:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rcdyr-0007Ig-Mv; Mon, 19 Dec 2011 14:14:17 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <avi@redhat.com>) id 1Rcdyn-0007CY-Tk
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 14:14:14 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1324304047!7864116!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDY0OTI=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17100 invoked from network); 19 Dec 2011 14:14:07 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-3.tower-182.messagelabs.com with SMTP;
	19 Dec 2011 14:14:07 -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 pBJEE59n024960
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 19 Dec 2011 09:14:05 -0500
Received: from cleopatra.tlv.redhat.com (cleopatra.tlv.redhat.com
	[10.35.255.11])
	by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id pBJEE1GE015710; Mon, 19 Dec 2011 09:14:05 -0500
Received: from s01.tlv.redhat.com (s01.tlv.redhat.com [10.35.255.8])
	by cleopatra.tlv.redhat.com (Postfix) with ESMTP id CBBE1250BB5;
	Mon, 19 Dec 2011 16:13:54 +0200 (IST)
From: Avi Kivity <avi@redhat.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	qemu-devel@nongnu.org, "Michael S. Tsirkin" <mst@redhat.com>
Date: Mon, 19 Dec 2011 16:13:43 +0200
Message-Id: <1324304024-11220-23-git-send-email-avi@redhat.com>
In-Reply-To: <1324304024-11220-1-git-send-email-avi@redhat.com>
References: <1324304024-11220-1-git-send-email-avi@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
Cc: xen-devel@lists.xensource.com, kvm@vger.kernel.org
Subject: [Xen-devel] [PATCH 22/23] sparc: avoid cpu_get_physical_page_desc()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This reaches into the innards of the memory core, which are being
changed.  Switch to a memory API version.

Signed-off-by: Avi Kivity <avi@redhat.com>
---
 target-sparc/mmu_helper.c |    5 ++++-
 1 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/target-sparc/mmu_helper.c b/target-sparc/mmu_helper.c
index 8cdc224..eec8947 100644
--- a/target-sparc/mmu_helper.c
+++ b/target-sparc/mmu_helper.c
@@ -19,6 +19,7 @@
 
 #include "cpu.h"
 #include "trace.h"
+#include "exec-memory.h"
 
 /* Sparc MMU emulation */
 
@@ -839,13 +840,15 @@ target_phys_addr_t cpu_get_phys_page_debug(CPUState *env, target_ulong addr)
 {
     target_phys_addr_t phys_addr;
     int mmu_idx = cpu_mmu_index(env);
+    MemoryRegionSection section;
 
     if (cpu_sparc_get_phys_page(env, &phys_addr, addr, 2, mmu_idx) != 0) {
         if (cpu_sparc_get_phys_page(env, &phys_addr, addr, 0, mmu_idx) != 0) {
             return -1;
         }
     }
-    if (cpu_get_physical_page_desc(phys_addr) == IO_MEM_UNASSIGNED) {
+    section = memory_region_find(get_system_memory(), phys_addr, 1);
+    if (!section.mr) {
         return -1;
     }
     return phys_addr;
-- 
1.7.7.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 14:14:37 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 14:14:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rcdys-0007JX-Fy; Mon, 19 Dec 2011 14:14:18 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <avi@redhat.com>) id 1Rcdyo-0007Ce-60
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 14:14:14 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1324304047!8827144!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDY0OTI=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23946 invoked from network); 19 Dec 2011 14:14:07 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-3.tower-21.messagelabs.com with SMTP;
	19 Dec 2011 14:14: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 pBJEE5Km012057
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 19 Dec 2011 09:14:05 -0500
Received: from cleopatra.tlv.redhat.com (cleopatra.tlv.redhat.com
	[10.35.255.11])
	by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id pBJEE31a006999; Mon, 19 Dec 2011 09:14:04 -0500
Received: from s01.tlv.redhat.com (s01.tlv.redhat.com [10.35.255.8])
	by cleopatra.tlv.redhat.com (Postfix) with ESMTP id C4DFE250BB4;
	Mon, 19 Dec 2011 16:13:54 +0200 (IST)
From: Avi Kivity <avi@redhat.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	qemu-devel@nongnu.org, "Michael S. Tsirkin" <mst@redhat.com>
Date: Mon, 19 Dec 2011 16:13:42 +0200
Message-Id: <1324304024-11220-22-git-send-email-avi@redhat.com>
In-Reply-To: <1324304024-11220-1-git-send-email-avi@redhat.com>
References: <1324304024-11220-1-git-send-email-avi@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
Cc: xen-devel@lists.xensource.com, kvm@vger.kernel.org
Subject: [Xen-devel] [PATCH 21/23] virtio-balloon: avoid
	cpu_get_physical_page_desc()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This reaches into the innards of the memory core, which are being
changed.  Switch to a memory API version.

Signed-off-by: Avi Kivity <avi@redhat.com>
---
 hw/virtio-balloon.c |   14 ++++++++++----
 1 files changed, 10 insertions(+), 4 deletions(-)

diff --git a/hw/virtio-balloon.c b/hw/virtio-balloon.c
index e24a2bf..bb4a8dd 100644
--- a/hw/virtio-balloon.c
+++ b/hw/virtio-balloon.c
@@ -21,6 +21,7 @@
 #include "balloon.h"
 #include "virtio-balloon.h"
 #include "kvm.h"
+#include "exec-memory.h"
 
 #if defined(__linux__)
 #include <sys/mman.h>
@@ -70,6 +71,7 @@ static void virtio_balloon_handle_output(VirtIODevice *vdev, VirtQueue *vq)
 {
     VirtIOBalloon *s = to_virtio_balloon(vdev);
     VirtQueueElement elem;
+    MemoryRegionSection section;
 
     while (virtqueue_pop(vq, &elem)) {
         size_t offset = 0;
@@ -82,13 +84,17 @@ static void virtio_balloon_handle_output(VirtIODevice *vdev, VirtQueue *vq)
             pa = (ram_addr_t)ldl_p(&pfn) << VIRTIO_BALLOON_PFN_SHIFT;
             offset += 4;
 
-            addr = cpu_get_physical_page_desc(pa);
-            if ((addr & ~TARGET_PAGE_MASK) != IO_MEM_RAM)
+            /* FIXME: remove get_system_memory(), but how? */
+            section = memory_region_find(get_system_memory(), pa, 1);
+            if (!section.mr || !memory_region_is_ram(section.mr))
                 continue;
 
-            /* Using qemu_get_ram_ptr is bending the rules a bit, but
+            /* Using memory_region_get_ram_ptr is bending the rules a bit, but
                should be OK because we only want a single page.  */
-            balloon_page(qemu_get_ram_ptr(addr), !!(vq == s->dvq));
+            addr -= section.offset_within_address_space;
+            addr += section.offset_within_region;
+            balloon_page(memory_region_get_ram_ptr(section.mr) + addr,
+                         !!(vq == s->dvq));
         }
 
         virtqueue_push(vq, &elem, offset);
-- 
1.7.7.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 14:14:37 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 14:14:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rcdys-0007JX-Fy; Mon, 19 Dec 2011 14:14:18 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <avi@redhat.com>) id 1Rcdyo-0007Ce-60
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 14:14:14 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1324304047!8827144!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDY0OTI=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23946 invoked from network); 19 Dec 2011 14:14:07 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-3.tower-21.messagelabs.com with SMTP;
	19 Dec 2011 14:14: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 pBJEE5Km012057
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 19 Dec 2011 09:14:05 -0500
Received: from cleopatra.tlv.redhat.com (cleopatra.tlv.redhat.com
	[10.35.255.11])
	by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id pBJEE31a006999; Mon, 19 Dec 2011 09:14:04 -0500
Received: from s01.tlv.redhat.com (s01.tlv.redhat.com [10.35.255.8])
	by cleopatra.tlv.redhat.com (Postfix) with ESMTP id C4DFE250BB4;
	Mon, 19 Dec 2011 16:13:54 +0200 (IST)
From: Avi Kivity <avi@redhat.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	qemu-devel@nongnu.org, "Michael S. Tsirkin" <mst@redhat.com>
Date: Mon, 19 Dec 2011 16:13:42 +0200
Message-Id: <1324304024-11220-22-git-send-email-avi@redhat.com>
In-Reply-To: <1324304024-11220-1-git-send-email-avi@redhat.com>
References: <1324304024-11220-1-git-send-email-avi@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
Cc: xen-devel@lists.xensource.com, kvm@vger.kernel.org
Subject: [Xen-devel] [PATCH 21/23] virtio-balloon: avoid
	cpu_get_physical_page_desc()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This reaches into the innards of the memory core, which are being
changed.  Switch to a memory API version.

Signed-off-by: Avi Kivity <avi@redhat.com>
---
 hw/virtio-balloon.c |   14 ++++++++++----
 1 files changed, 10 insertions(+), 4 deletions(-)

diff --git a/hw/virtio-balloon.c b/hw/virtio-balloon.c
index e24a2bf..bb4a8dd 100644
--- a/hw/virtio-balloon.c
+++ b/hw/virtio-balloon.c
@@ -21,6 +21,7 @@
 #include "balloon.h"
 #include "virtio-balloon.h"
 #include "kvm.h"
+#include "exec-memory.h"
 
 #if defined(__linux__)
 #include <sys/mman.h>
@@ -70,6 +71,7 @@ static void virtio_balloon_handle_output(VirtIODevice *vdev, VirtQueue *vq)
 {
     VirtIOBalloon *s = to_virtio_balloon(vdev);
     VirtQueueElement elem;
+    MemoryRegionSection section;
 
     while (virtqueue_pop(vq, &elem)) {
         size_t offset = 0;
@@ -82,13 +84,17 @@ static void virtio_balloon_handle_output(VirtIODevice *vdev, VirtQueue *vq)
             pa = (ram_addr_t)ldl_p(&pfn) << VIRTIO_BALLOON_PFN_SHIFT;
             offset += 4;
 
-            addr = cpu_get_physical_page_desc(pa);
-            if ((addr & ~TARGET_PAGE_MASK) != IO_MEM_RAM)
+            /* FIXME: remove get_system_memory(), but how? */
+            section = memory_region_find(get_system_memory(), pa, 1);
+            if (!section.mr || !memory_region_is_ram(section.mr))
                 continue;
 
-            /* Using qemu_get_ram_ptr is bending the rules a bit, but
+            /* Using memory_region_get_ram_ptr is bending the rules a bit, but
                should be OK because we only want a single page.  */
-            balloon_page(qemu_get_ram_ptr(addr), !!(vq == s->dvq));
+            addr -= section.offset_within_address_space;
+            addr += section.offset_within_region;
+            balloon_page(memory_region_get_ram_ptr(section.mr) + addr,
+                         !!(vq == s->dvq));
         }
 
         virtqueue_push(vq, &elem, offset);
-- 
1.7.7.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 14:15:06 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 14:15:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rcdzb-000832-GI; Mon, 19 Dec 2011 14:15:03 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <avi@redhat.com>) id 1Rcdza-0007xF-HP
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 14:15:02 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1324304047!7886940!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDY0OTI=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11820 invoked from network); 19 Dec 2011 14:14:07 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-16.tower-216.messagelabs.com with SMTP;
	19 Dec 2011 14:14:07 -0000
Received: from int-mx12.intmail.prod.int.phx2.redhat.com
	(int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id pBJEE5Ej012053
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 19 Dec 2011 09:14:05 -0500
Received: from cleopatra.tlv.redhat.com (cleopatra.tlv.redhat.com
	[10.35.255.11])
	by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id pBJEE07m032288; Mon, 19 Dec 2011 09:14:04 -0500
Received: from s01.tlv.redhat.com (s01.tlv.redhat.com [10.35.255.8])
	by cleopatra.tlv.redhat.com (Postfix) with ESMTP id BEA65250BB1;
	Mon, 19 Dec 2011 16:13:54 +0200 (IST)
From: Avi Kivity <avi@redhat.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	qemu-devel@nongnu.org, "Michael S. Tsirkin" <mst@redhat.com>
Date: Mon, 19 Dec 2011 16:13:39 +0200
Message-Id: <1324304024-11220-19-git-send-email-avi@redhat.com>
In-Reply-To: <1324304024-11220-1-git-send-email-avi@redhat.com>
References: <1324304024-11220-1-git-send-email-avi@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.25
Cc: xen-devel@lists.xensource.com, kvm@vger.kernel.org
Subject: [Xen-devel] [PATCH 18/23] memory: remove CPUPhysMemoryClient
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

No longer used.

Signed-off-by: Avi Kivity <avi@redhat.com>
---
 cpu-all.h       |    6 --
 cpu-common.h    |   23 --------
 exec-obsolete.h |    3 -
 exec.c          |  169 ++-----------------------------------------------------
 memory.c        |   12 ----
 5 files changed, 5 insertions(+), 208 deletions(-)

diff --git a/cpu-all.h b/cpu-all.h
index f2c5382..734833a 100644
--- a/cpu-all.h
+++ b/cpu-all.h
@@ -569,12 +569,6 @@ int cpu_physical_memory_set_dirty_tracking(int enable);
 
 int cpu_physical_memory_get_dirty_tracking(void);
 
-int cpu_physical_log_start(target_phys_addr_t start_addr,
-                           ram_addr_t size);
-
-int cpu_physical_log_stop(target_phys_addr_t start_addr,
-                          ram_addr_t size);
-
 void dump_exec_info(FILE *f, fprintf_function cpu_fprintf);
 #endif /* !CONFIG_USER_ONLY */
 
diff --git a/cpu-common.h b/cpu-common.h
index 8295e4f..eee2faf 100644
--- a/cpu-common.h
+++ b/cpu-common.h
@@ -71,29 +71,6 @@ void cpu_physical_memory_unmap(void *buffer, target_phys_addr_t len,
 void *cpu_register_map_client(void *opaque, void (*callback)(void *opaque));
 void cpu_unregister_map_client(void *cookie);
 
-struct CPUPhysMemoryClient;
-typedef struct CPUPhysMemoryClient CPUPhysMemoryClient;
-struct CPUPhysMemoryClient {
-    void (*set_memory)(struct CPUPhysMemoryClient *client,
-                       target_phys_addr_t start_addr,
-                       ram_addr_t size,
-                       ram_addr_t phys_offset,
-                       bool log_dirty);
-    int (*sync_dirty_bitmap)(struct CPUPhysMemoryClient *client,
-                             target_phys_addr_t start_addr,
-                             target_phys_addr_t end_addr);
-    int (*migration_log)(struct CPUPhysMemoryClient *client,
-                         int enable);
-    int (*log_start)(struct CPUPhysMemoryClient *client,
-                     target_phys_addr_t phys_addr, ram_addr_t size);
-    int (*log_stop)(struct CPUPhysMemoryClient *client,
-                    target_phys_addr_t phys_addr, ram_addr_t size);
-    QLIST_ENTRY(CPUPhysMemoryClient) list;
-};
-
-void cpu_register_phys_memory_client(CPUPhysMemoryClient *);
-void cpu_unregister_phys_memory_client(CPUPhysMemoryClient *);
-
 /* Coalesced MMIO regions are areas where write operations can be reordered.
  * This usually implies that write operations are side-effect free.  This allows
  * batching which can make a major impact on performance when using
diff --git a/exec-obsolete.h b/exec-obsolete.h
index aa0a04d..1d0b610 100644
--- a/exec-obsolete.h
+++ b/exec-obsolete.h
@@ -64,9 +64,6 @@ static inline void cpu_register_physical_memory(target_phys_addr_t start_addr,
 void qemu_register_coalesced_mmio(target_phys_addr_t addr, ram_addr_t size);
 void qemu_unregister_coalesced_mmio(target_phys_addr_t addr, ram_addr_t size);
 
-int cpu_physical_sync_dirty_bitmap(target_phys_addr_t start_addr,
-                                   target_phys_addr_t end_addr);
-
 #endif
 
 #endif
diff --git a/exec.c b/exec.c
index 36b61c9..e1f7462 100644
--- a/exec.c
+++ b/exec.c
@@ -1732,129 +1732,6 @@ void cpu_exit(CPUState *env)
     { 0, NULL, NULL },
 };
 
-#ifndef CONFIG_USER_ONLY
-static QLIST_HEAD(memory_client_list, CPUPhysMemoryClient) memory_client_list
-    = QLIST_HEAD_INITIALIZER(memory_client_list);
-
-static void cpu_notify_set_memory(target_phys_addr_t start_addr,
-                                  ram_addr_t size,
-                                  ram_addr_t phys_offset,
-                                  bool log_dirty)
-{
-    CPUPhysMemoryClient *client;
-    QLIST_FOREACH(client, &memory_client_list, list) {
-        client->set_memory(client, start_addr, size, phys_offset, log_dirty);
-    }
-}
-
-static int cpu_notify_sync_dirty_bitmap(target_phys_addr_t start,
-                                        target_phys_addr_t end)
-{
-    CPUPhysMemoryClient *client;
-    QLIST_FOREACH(client, &memory_client_list, list) {
-        int r = client->sync_dirty_bitmap(client, start, end);
-        if (r < 0)
-            return r;
-    }
-    return 0;
-}
-
-static int cpu_notify_migration_log(int enable)
-{
-    CPUPhysMemoryClient *client;
-    if (enable) {
-        memory_global_dirty_log_start();
-    } else {
-        memory_global_dirty_log_stop();
-    }
-    QLIST_FOREACH(client, &memory_client_list, list) {
-        int r = client->migration_log(client, enable);
-        if (r < 0)
-            return r;
-    }
-    return 0;
-}
-
-struct last_map {
-    target_phys_addr_t start_addr;
-    ram_addr_t size;
-    ram_addr_t phys_offset;
-};
-
-/* The l1_phys_map provides the upper P_L1_BITs of the guest physical
- * address.  Each intermediate table provides the next L2_BITs of guest
- * physical address space.  The number of levels vary based on host and
- * guest configuration, making it efficient to build the final guest
- * physical address by seeding the L1 offset and shifting and adding in
- * each L2 offset as we recurse through them. */
-static void phys_page_for_each_1(CPUPhysMemoryClient *client, int level,
-                                 void **lp, target_phys_addr_t addr,
-                                 struct last_map *map)
-{
-    int i;
-
-    if (*lp == NULL) {
-        return;
-    }
-    if (level == 0) {
-        PhysPageDesc *pd = *lp;
-        addr <<= L2_BITS + TARGET_PAGE_BITS;
-        for (i = 0; i < L2_SIZE; ++i) {
-            if (pd[i].phys_offset != IO_MEM_UNASSIGNED) {
-                target_phys_addr_t start_addr = addr | i << TARGET_PAGE_BITS;
-
-                if (map->size &&
-                    start_addr == map->start_addr + map->size &&
-                    pd[i].phys_offset == map->phys_offset + map->size) {
-
-                    map->size += TARGET_PAGE_SIZE;
-                    continue;
-                } else if (map->size) {
-                    client->set_memory(client, map->start_addr,
-                                       map->size, map->phys_offset, false);
-                }
-
-                map->start_addr = start_addr;
-                map->size = TARGET_PAGE_SIZE;
-                map->phys_offset = pd[i].phys_offset;
-            }
-        }
-    } else {
-        void **pp = *lp;
-        for (i = 0; i < L2_SIZE; ++i) {
-            phys_page_for_each_1(client, level - 1, pp + i,
-                                 (addr << L2_BITS) | i, map);
-        }
-    }
-}
-
-static void phys_page_for_each(CPUPhysMemoryClient *client)
-{
-    int i;
-    struct last_map map = { };
-
-    for (i = 0; i < P_L1_SIZE; ++i) {
-        phys_page_for_each_1(client, P_L1_SHIFT / L2_BITS - 1,
-                             l1_phys_map + i, i, &map);
-    }
-    if (map.size) {
-        client->set_memory(client, map.start_addr, map.size, map.phys_offset,
-                           false);
-    }
-}
-
-void cpu_register_phys_memory_client(CPUPhysMemoryClient *client)
-{
-    QLIST_INSERT_HEAD(&memory_client_list, client, list);
-    phys_page_for_each(client);
-}
-
-void cpu_unregister_phys_memory_client(CPUPhysMemoryClient *client)
-{
-    QLIST_REMOVE(client, list);
-}
-#endif
-
 static int cmp1(const char *s1, int n, const char *s2)
 {
     if (strlen(s2) != n)
@@ -2131,7 +2008,11 @@ int cpu_physical_memory_set_dirty_tracking(int enable)
 {
     int ret = 0;
     in_migration = enable;
-    ret = cpu_notify_migration_log(!!enable);
+    if (enable) {
+        memory_global_dirty_log_start();
+    } else {
+        memory_global_dirty_log_stop();
+    }
     return ret;
 }
 
@@ -2140,45 +2021,6 @@ int cpu_physical_memory_get_dirty_tracking(void)
     return in_migration;
 }
 
-int cpu_physical_sync_dirty_bitmap(target_phys_addr_t start_addr,
-                                   target_phys_addr_t end_addr)
-{
-    int ret;
-
-    ret = cpu_notify_sync_dirty_bitmap(start_addr, end_addr);
-    return ret;
-}
-
-int cpu_physical_log_start(target_phys_addr_t start_addr,
-                           ram_addr_t size)
-{
-    CPUPhysMemoryClient *client;
-    QLIST_FOREACH(client, &memory_client_list, list) {
-        if (client->log_start) {
-            int r = client->log_start(client, start_addr, size);
-            if (r < 0) {
-                return r;
-            }
-        }
-    }
-    return 0;
-}
-
-int cpu_physical_log_stop(target_phys_addr_t start_addr,
-                          ram_addr_t size)
-{
-    CPUPhysMemoryClient *client;
-    QLIST_FOREACH(client, &memory_client_list, list) {
-        if (client->log_stop) {
-            int r = client->log_stop(client, start_addr, size);
-            if (r < 0) {
-                return r;
-            }
-        }
-    }
-    return 0;
-}
-
 static inline void tlb_update_dirty(CPUTLBEntry *tlb_entry)
 {
     ram_addr_t ram_addr;
@@ -2681,7 +2523,6 @@ void cpu_register_physical_memory_log(target_phys_addr_t start_addr,
     subpage_t *subpage;
 
     assert(size);
-    cpu_notify_set_memory(start_addr, size, phys_offset, log_dirty);
 
     if (phys_offset == IO_MEM_UNASSIGNED) {
         region_offset = start_addr;
diff --git a/memory.c b/memory.c
index 41a106a..520e37b 100644
--- a/memory.c
+++ b/memory.c
@@ -337,11 +337,6 @@ static void as_memory_range_add(AddressSpace *as, FlatRange *fr)
 
 static void as_memory_range_del(AddressSpace *as, FlatRange *fr)
 {
-    if (fr->dirty_log_mask) {
-        Int128 end = addrrange_end(fr->addr);
-        cpu_physical_sync_dirty_bitmap(int128_get64(fr->addr.start),
-                                       int128_get64(end));
-    }
     cpu_register_physical_memory(int128_get64(fr->addr.start),
                                  int128_get64(fr->addr.size),
                                  IO_MEM_UNASSIGNED);
@@ -349,14 +344,10 @@ static void as_memory_range_del(AddressSpace *as, FlatRange *fr)
 
 static void as_memory_log_start(AddressSpace *as, FlatRange *fr)
 {
-    cpu_physical_log_start(int128_get64(fr->addr.start),
-                           int128_get64(fr->addr.size));
 }
 
 static void as_memory_log_stop(AddressSpace *as, FlatRange *fr)
 {
-    cpu_physical_log_stop(int128_get64(fr->addr.start),
-                          int128_get64(fr->addr.size));
 }
 
 static void as_memory_ioeventfd_add(AddressSpace *as, MemoryRegionIoeventfd *fd)
@@ -1150,8 +1141,6 @@ void memory_region_sync_dirty_bitmap(MemoryRegion *mr)
     FOR_EACH_FLAT_RANGE(fr, &address_space_memory.current_map) {
         if (fr->mr == mr) {
             MEMORY_LISTENER_UPDATE_REGION(fr, &address_space_memory, log_sync);
-            cpu_physical_sync_dirty_bitmap(int128_get64(fr->addr.start),
-                                           int128_get64(addrrange_end(fr->addr)));
         }
     }
 }
@@ -1434,7 +1423,6 @@ void memory_global_sync_dirty_bitmap(MemoryRegion *address_space)
     AddressSpace *as = memory_region_to_address_space(address_space);
     FlatRange *fr;
 
-    cpu_physical_sync_dirty_bitmap(0, TARGET_PHYS_ADDR_MAX);
     FOR_EACH_FLAT_RANGE(fr, &as->current_map) {
         MEMORY_LISTENER_UPDATE_REGION(fr, as, log_sync);
     }
-- 
1.7.7.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 14:15:06 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 14:15:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rcdzb-000832-GI; Mon, 19 Dec 2011 14:15:03 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <avi@redhat.com>) id 1Rcdza-0007xF-HP
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 14:15:02 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1324304047!7886940!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDY0OTI=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11820 invoked from network); 19 Dec 2011 14:14:07 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-16.tower-216.messagelabs.com with SMTP;
	19 Dec 2011 14:14:07 -0000
Received: from int-mx12.intmail.prod.int.phx2.redhat.com
	(int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id pBJEE5Ej012053
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 19 Dec 2011 09:14:05 -0500
Received: from cleopatra.tlv.redhat.com (cleopatra.tlv.redhat.com
	[10.35.255.11])
	by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id pBJEE07m032288; Mon, 19 Dec 2011 09:14:04 -0500
Received: from s01.tlv.redhat.com (s01.tlv.redhat.com [10.35.255.8])
	by cleopatra.tlv.redhat.com (Postfix) with ESMTP id BEA65250BB1;
	Mon, 19 Dec 2011 16:13:54 +0200 (IST)
From: Avi Kivity <avi@redhat.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	qemu-devel@nongnu.org, "Michael S. Tsirkin" <mst@redhat.com>
Date: Mon, 19 Dec 2011 16:13:39 +0200
Message-Id: <1324304024-11220-19-git-send-email-avi@redhat.com>
In-Reply-To: <1324304024-11220-1-git-send-email-avi@redhat.com>
References: <1324304024-11220-1-git-send-email-avi@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.25
Cc: xen-devel@lists.xensource.com, kvm@vger.kernel.org
Subject: [Xen-devel] [PATCH 18/23] memory: remove CPUPhysMemoryClient
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

No longer used.

Signed-off-by: Avi Kivity <avi@redhat.com>
---
 cpu-all.h       |    6 --
 cpu-common.h    |   23 --------
 exec-obsolete.h |    3 -
 exec.c          |  169 ++-----------------------------------------------------
 memory.c        |   12 ----
 5 files changed, 5 insertions(+), 208 deletions(-)

diff --git a/cpu-all.h b/cpu-all.h
index f2c5382..734833a 100644
--- a/cpu-all.h
+++ b/cpu-all.h
@@ -569,12 +569,6 @@ int cpu_physical_memory_set_dirty_tracking(int enable);
 
 int cpu_physical_memory_get_dirty_tracking(void);
 
-int cpu_physical_log_start(target_phys_addr_t start_addr,
-                           ram_addr_t size);
-
-int cpu_physical_log_stop(target_phys_addr_t start_addr,
-                          ram_addr_t size);
-
 void dump_exec_info(FILE *f, fprintf_function cpu_fprintf);
 #endif /* !CONFIG_USER_ONLY */
 
diff --git a/cpu-common.h b/cpu-common.h
index 8295e4f..eee2faf 100644
--- a/cpu-common.h
+++ b/cpu-common.h
@@ -71,29 +71,6 @@ void cpu_physical_memory_unmap(void *buffer, target_phys_addr_t len,
 void *cpu_register_map_client(void *opaque, void (*callback)(void *opaque));
 void cpu_unregister_map_client(void *cookie);
 
-struct CPUPhysMemoryClient;
-typedef struct CPUPhysMemoryClient CPUPhysMemoryClient;
-struct CPUPhysMemoryClient {
-    void (*set_memory)(struct CPUPhysMemoryClient *client,
-                       target_phys_addr_t start_addr,
-                       ram_addr_t size,
-                       ram_addr_t phys_offset,
-                       bool log_dirty);
-    int (*sync_dirty_bitmap)(struct CPUPhysMemoryClient *client,
-                             target_phys_addr_t start_addr,
-                             target_phys_addr_t end_addr);
-    int (*migration_log)(struct CPUPhysMemoryClient *client,
-                         int enable);
-    int (*log_start)(struct CPUPhysMemoryClient *client,
-                     target_phys_addr_t phys_addr, ram_addr_t size);
-    int (*log_stop)(struct CPUPhysMemoryClient *client,
-                    target_phys_addr_t phys_addr, ram_addr_t size);
-    QLIST_ENTRY(CPUPhysMemoryClient) list;
-};
-
-void cpu_register_phys_memory_client(CPUPhysMemoryClient *);
-void cpu_unregister_phys_memory_client(CPUPhysMemoryClient *);
-
 /* Coalesced MMIO regions are areas where write operations can be reordered.
  * This usually implies that write operations are side-effect free.  This allows
  * batching which can make a major impact on performance when using
diff --git a/exec-obsolete.h b/exec-obsolete.h
index aa0a04d..1d0b610 100644
--- a/exec-obsolete.h
+++ b/exec-obsolete.h
@@ -64,9 +64,6 @@ static inline void cpu_register_physical_memory(target_phys_addr_t start_addr,
 void qemu_register_coalesced_mmio(target_phys_addr_t addr, ram_addr_t size);
 void qemu_unregister_coalesced_mmio(target_phys_addr_t addr, ram_addr_t size);
 
-int cpu_physical_sync_dirty_bitmap(target_phys_addr_t start_addr,
-                                   target_phys_addr_t end_addr);
-
 #endif
 
 #endif
diff --git a/exec.c b/exec.c
index 36b61c9..e1f7462 100644
--- a/exec.c
+++ b/exec.c
@@ -1732,129 +1732,6 @@ void cpu_exit(CPUState *env)
     { 0, NULL, NULL },
 };
 
-#ifndef CONFIG_USER_ONLY
-static QLIST_HEAD(memory_client_list, CPUPhysMemoryClient) memory_client_list
-    = QLIST_HEAD_INITIALIZER(memory_client_list);
-
-static void cpu_notify_set_memory(target_phys_addr_t start_addr,
-                                  ram_addr_t size,
-                                  ram_addr_t phys_offset,
-                                  bool log_dirty)
-{
-    CPUPhysMemoryClient *client;
-    QLIST_FOREACH(client, &memory_client_list, list) {
-        client->set_memory(client, start_addr, size, phys_offset, log_dirty);
-    }
-}
-
-static int cpu_notify_sync_dirty_bitmap(target_phys_addr_t start,
-                                        target_phys_addr_t end)
-{
-    CPUPhysMemoryClient *client;
-    QLIST_FOREACH(client, &memory_client_list, list) {
-        int r = client->sync_dirty_bitmap(client, start, end);
-        if (r < 0)
-            return r;
-    }
-    return 0;
-}
-
-static int cpu_notify_migration_log(int enable)
-{
-    CPUPhysMemoryClient *client;
-    if (enable) {
-        memory_global_dirty_log_start();
-    } else {
-        memory_global_dirty_log_stop();
-    }
-    QLIST_FOREACH(client, &memory_client_list, list) {
-        int r = client->migration_log(client, enable);
-        if (r < 0)
-            return r;
-    }
-    return 0;
-}
-
-struct last_map {
-    target_phys_addr_t start_addr;
-    ram_addr_t size;
-    ram_addr_t phys_offset;
-};
-
-/* The l1_phys_map provides the upper P_L1_BITs of the guest physical
- * address.  Each intermediate table provides the next L2_BITs of guest
- * physical address space.  The number of levels vary based on host and
- * guest configuration, making it efficient to build the final guest
- * physical address by seeding the L1 offset and shifting and adding in
- * each L2 offset as we recurse through them. */
-static void phys_page_for_each_1(CPUPhysMemoryClient *client, int level,
-                                 void **lp, target_phys_addr_t addr,
-                                 struct last_map *map)
-{
-    int i;
-
-    if (*lp == NULL) {
-        return;
-    }
-    if (level == 0) {
-        PhysPageDesc *pd = *lp;
-        addr <<= L2_BITS + TARGET_PAGE_BITS;
-        for (i = 0; i < L2_SIZE; ++i) {
-            if (pd[i].phys_offset != IO_MEM_UNASSIGNED) {
-                target_phys_addr_t start_addr = addr | i << TARGET_PAGE_BITS;
-
-                if (map->size &&
-                    start_addr == map->start_addr + map->size &&
-                    pd[i].phys_offset == map->phys_offset + map->size) {
-
-                    map->size += TARGET_PAGE_SIZE;
-                    continue;
-                } else if (map->size) {
-                    client->set_memory(client, map->start_addr,
-                                       map->size, map->phys_offset, false);
-                }
-
-                map->start_addr = start_addr;
-                map->size = TARGET_PAGE_SIZE;
-                map->phys_offset = pd[i].phys_offset;
-            }
-        }
-    } else {
-        void **pp = *lp;
-        for (i = 0; i < L2_SIZE; ++i) {
-            phys_page_for_each_1(client, level - 1, pp + i,
-                                 (addr << L2_BITS) | i, map);
-        }
-    }
-}
-
-static void phys_page_for_each(CPUPhysMemoryClient *client)
-{
-    int i;
-    struct last_map map = { };
-
-    for (i = 0; i < P_L1_SIZE; ++i) {
-        phys_page_for_each_1(client, P_L1_SHIFT / L2_BITS - 1,
-                             l1_phys_map + i, i, &map);
-    }
-    if (map.size) {
-        client->set_memory(client, map.start_addr, map.size, map.phys_offset,
-                           false);
-    }
-}
-
-void cpu_register_phys_memory_client(CPUPhysMemoryClient *client)
-{
-    QLIST_INSERT_HEAD(&memory_client_list, client, list);
-    phys_page_for_each(client);
-}
-
-void cpu_unregister_phys_memory_client(CPUPhysMemoryClient *client)
-{
-    QLIST_REMOVE(client, list);
-}
-#endif
-
 static int cmp1(const char *s1, int n, const char *s2)
 {
     if (strlen(s2) != n)
@@ -2131,7 +2008,11 @@ int cpu_physical_memory_set_dirty_tracking(int enable)
 {
     int ret = 0;
     in_migration = enable;
-    ret = cpu_notify_migration_log(!!enable);
+    if (enable) {
+        memory_global_dirty_log_start();
+    } else {
+        memory_global_dirty_log_stop();
+    }
     return ret;
 }
 
@@ -2140,45 +2021,6 @@ int cpu_physical_memory_get_dirty_tracking(void)
     return in_migration;
 }
 
-int cpu_physical_sync_dirty_bitmap(target_phys_addr_t start_addr,
-                                   target_phys_addr_t end_addr)
-{
-    int ret;
-
-    ret = cpu_notify_sync_dirty_bitmap(start_addr, end_addr);
-    return ret;
-}
-
-int cpu_physical_log_start(target_phys_addr_t start_addr,
-                           ram_addr_t size)
-{
-    CPUPhysMemoryClient *client;
-    QLIST_FOREACH(client, &memory_client_list, list) {
-        if (client->log_start) {
-            int r = client->log_start(client, start_addr, size);
-            if (r < 0) {
-                return r;
-            }
-        }
-    }
-    return 0;
-}
-
-int cpu_physical_log_stop(target_phys_addr_t start_addr,
-                          ram_addr_t size)
-{
-    CPUPhysMemoryClient *client;
-    QLIST_FOREACH(client, &memory_client_list, list) {
-        if (client->log_stop) {
-            int r = client->log_stop(client, start_addr, size);
-            if (r < 0) {
-                return r;
-            }
-        }
-    }
-    return 0;
-}
-
 static inline void tlb_update_dirty(CPUTLBEntry *tlb_entry)
 {
     ram_addr_t ram_addr;
@@ -2681,7 +2523,6 @@ void cpu_register_physical_memory_log(target_phys_addr_t start_addr,
     subpage_t *subpage;
 
     assert(size);
-    cpu_notify_set_memory(start_addr, size, phys_offset, log_dirty);
 
     if (phys_offset == IO_MEM_UNASSIGNED) {
         region_offset = start_addr;
diff --git a/memory.c b/memory.c
index 41a106a..520e37b 100644
--- a/memory.c
+++ b/memory.c
@@ -337,11 +337,6 @@ static void as_memory_range_add(AddressSpace *as, FlatRange *fr)
 
 static void as_memory_range_del(AddressSpace *as, FlatRange *fr)
 {
-    if (fr->dirty_log_mask) {
-        Int128 end = addrrange_end(fr->addr);
-        cpu_physical_sync_dirty_bitmap(int128_get64(fr->addr.start),
-                                       int128_get64(end));
-    }
     cpu_register_physical_memory(int128_get64(fr->addr.start),
                                  int128_get64(fr->addr.size),
                                  IO_MEM_UNASSIGNED);
@@ -349,14 +344,10 @@ static void as_memory_range_del(AddressSpace *as, FlatRange *fr)
 
 static void as_memory_log_start(AddressSpace *as, FlatRange *fr)
 {
-    cpu_physical_log_start(int128_get64(fr->addr.start),
-                           int128_get64(fr->addr.size));
 }
 
 static void as_memory_log_stop(AddressSpace *as, FlatRange *fr)
 {
-    cpu_physical_log_stop(int128_get64(fr->addr.start),
-                          int128_get64(fr->addr.size));
 }
 
 static void as_memory_ioeventfd_add(AddressSpace *as, MemoryRegionIoeventfd *fd)
@@ -1150,8 +1141,6 @@ void memory_region_sync_dirty_bitmap(MemoryRegion *mr)
     FOR_EACH_FLAT_RANGE(fr, &address_space_memory.current_map) {
         if (fr->mr == mr) {
             MEMORY_LISTENER_UPDATE_REGION(fr, &address_space_memory, log_sync);
-            cpu_physical_sync_dirty_bitmap(int128_get64(fr->addr.start),
-                                           int128_get64(addrrange_end(fr->addr)));
         }
     }
 }
@@ -1434,7 +1423,6 @@ void memory_global_sync_dirty_bitmap(MemoryRegion *address_space)
     AddressSpace *as = memory_region_to_address_space(address_space);
     FlatRange *fr;
 
-    cpu_physical_sync_dirty_bitmap(0, TARGET_PHYS_ADDR_MAX);
     FOR_EACH_FLAT_RANGE(fr, &as->current_map) {
         MEMORY_LISTENER_UPDATE_REGION(fr, as, log_sync);
     }
-- 
1.7.7.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 14:17:30 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 14:17:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rce1v-0001EB-Ak; Mon, 19 Dec 2011 14:17:27 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <avi@redhat.com>) id 1Rce1t-0001Ax-Tv
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 14:17:26 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1324304237!7431532!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDY0OTI=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8329 invoked from network); 19 Dec 2011 14:17:18 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-13.tower-216.messagelabs.com with SMTP;
	19 Dec 2011 14:17:18 -0000
Received: from int-mx12.intmail.prod.int.phx2.redhat.com
	(int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id pBJEE2u1012042
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 19 Dec 2011 09:14:02 -0500
Received: from cleopatra.tlv.redhat.com (cleopatra.tlv.redhat.com
	[10.35.255.11])
	by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id pBJEE07i032288; Mon, 19 Dec 2011 09:14:02 -0500
Received: from s01.tlv.redhat.com (s01.tlv.redhat.com [10.35.255.8])
	by cleopatra.tlv.redhat.com (Postfix) with ESMTP id ACFA5250BA9;
	Mon, 19 Dec 2011 16:13:54 +0200 (IST)
From: Avi Kivity <avi@redhat.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	qemu-devel@nongnu.org, "Michael S. Tsirkin" <mst@redhat.com>
Date: Mon, 19 Dec 2011 16:13:31 +0200
Message-Id: <1324304024-11220-11-git-send-email-avi@redhat.com>
In-Reply-To: <1324304024-11220-1-git-send-email-avi@redhat.com>
References: <1324304024-11220-1-git-send-email-avi@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.25
Cc: xen-devel@lists.xensource.com, kvm@vger.kernel.org
Subject: [Xen-devel] [PATCH 10/23] memory: add memory_region_is_logging()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Signed-off-by: Avi Kivity <avi@redhat.com>
---
 memory.c |    5 +++++
 memory.h |    9 +++++++++
 2 files changed, 14 insertions(+), 0 deletions(-)

diff --git a/memory.c b/memory.c
index ee9053a..2e5ff43 100644
--- a/memory.c
+++ b/memory.c
@@ -1107,6 +1107,11 @@ bool memory_region_is_ram(MemoryRegion *mr)
     return mr->ram;
 }
 
+bool memory_region_is_logging(MemoryRegion *mr)
+{
+    return mr->dirty_log_mask;
+}
+
 bool memory_region_is_rom(MemoryRegion *mr)
 {
     return mr->ram && mr->readonly;
diff --git a/memory.h b/memory.h
index 6b50f6b..b7d39ed 100644
--- a/memory.h
+++ b/memory.h
@@ -315,6 +315,15 @@ uint64_t memory_region_size(MemoryRegion *mr);
 bool memory_region_is_ram(MemoryRegion *mr);
 
 /**
+ * memory_region_is_logging: return whether a memory region is logging writes
+ *
+ * Returns %true if the memory region is logging writes
+ *
+ * @mr: the memory region being queried
+ */
+bool memory_region_is_logging(MemoryRegion *mr);
+
+/**
  * memory_region_is_rom: check whether a memory region is ROM
  *
  * Returns %true is a memory region is read-only memory.
-- 
1.7.7.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 14:17:30 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 14:17:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rce1v-0001EB-Ak; Mon, 19 Dec 2011 14:17:27 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <avi@redhat.com>) id 1Rce1t-0001Ax-Tv
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 14:17:26 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1324304237!7431532!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDY0OTI=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8329 invoked from network); 19 Dec 2011 14:17:18 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-13.tower-216.messagelabs.com with SMTP;
	19 Dec 2011 14:17:18 -0000
Received: from int-mx12.intmail.prod.int.phx2.redhat.com
	(int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id pBJEE2u1012042
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 19 Dec 2011 09:14:02 -0500
Received: from cleopatra.tlv.redhat.com (cleopatra.tlv.redhat.com
	[10.35.255.11])
	by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id pBJEE07i032288; Mon, 19 Dec 2011 09:14:02 -0500
Received: from s01.tlv.redhat.com (s01.tlv.redhat.com [10.35.255.8])
	by cleopatra.tlv.redhat.com (Postfix) with ESMTP id ACFA5250BA9;
	Mon, 19 Dec 2011 16:13:54 +0200 (IST)
From: Avi Kivity <avi@redhat.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	qemu-devel@nongnu.org, "Michael S. Tsirkin" <mst@redhat.com>
Date: Mon, 19 Dec 2011 16:13:31 +0200
Message-Id: <1324304024-11220-11-git-send-email-avi@redhat.com>
In-Reply-To: <1324304024-11220-1-git-send-email-avi@redhat.com>
References: <1324304024-11220-1-git-send-email-avi@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.25
Cc: xen-devel@lists.xensource.com, kvm@vger.kernel.org
Subject: [Xen-devel] [PATCH 10/23] memory: add memory_region_is_logging()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Signed-off-by: Avi Kivity <avi@redhat.com>
---
 memory.c |    5 +++++
 memory.h |    9 +++++++++
 2 files changed, 14 insertions(+), 0 deletions(-)

diff --git a/memory.c b/memory.c
index ee9053a..2e5ff43 100644
--- a/memory.c
+++ b/memory.c
@@ -1107,6 +1107,11 @@ bool memory_region_is_ram(MemoryRegion *mr)
     return mr->ram;
 }
 
+bool memory_region_is_logging(MemoryRegion *mr)
+{
+    return mr->dirty_log_mask;
+}
+
 bool memory_region_is_rom(MemoryRegion *mr)
 {
     return mr->ram && mr->readonly;
diff --git a/memory.h b/memory.h
index 6b50f6b..b7d39ed 100644
--- a/memory.h
+++ b/memory.h
@@ -315,6 +315,15 @@ uint64_t memory_region_size(MemoryRegion *mr);
 bool memory_region_is_ram(MemoryRegion *mr);
 
 /**
+ * memory_region_is_logging: return whether a memory region is logging writes
+ *
+ * Returns %true if the memory region is logging writes
+ *
+ * @mr: the memory region being queried
+ */
+bool memory_region_is_logging(MemoryRegion *mr);
+
+/**
  * memory_region_is_rom: check whether a memory region is ROM
  *
  * Returns %true is a memory region is read-only memory.
-- 
1.7.7.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 14:18:23 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 14:18:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rce2m-0001hj-09; Mon, 19 Dec 2011 14:18:20 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1Rce2k-0001gq-1R
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 14:18:18 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-8.tower-27.messagelabs.com!1324304184!56763801!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18436 invoked from network); 19 Dec 2011 14:16:25 -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; 19 Dec 2011 14:16: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
	pBJEHQJn027978
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Mon, 19 Dec 2011 09:17:26 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pBJEHL7T027976;
	Mon, 19 Dec 2011 09:17:21 -0500
Date: Mon, 19 Dec 2011 10:17:21 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: "Tian, Kevin" <kevin.tian@intel.com>
Message-ID: <20111219141721.GA27772@andromeda.dapyr.net>
References: <1322673664-14642-1-git-send-email-konrad.wilk@oracle.com>
	<1322673664-14642-2-git-send-email-konrad.wilk@oracle.com>
	<20111216213345.GA9832@phenom.dumpdata.com>
	<625BA99ED14B2D499DC4E29D8138F1506E01AABC72@shsmsx502.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <625BA99ED14B2D499DC4E29D8138F1506E01AABC72@shsmsx502.ccr.corp.intel.com>
User-Agent: Mutt/1.5.9i
Cc: "jeremy@goop.org" <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"mike.mcclurg@citrix.com" <mike.mcclurg@citrix.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"stefan.bader@canonical.com" <stefan.bader@canonical.com>,
	"rjw@sisk.pl" <rjw@sisk.pl>,
	"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
	"liang.tang@oracle.com" <liang.tang@oracle.com>, "Yu,
	Ke" <ke.yu@intel.com>, "konrad@kernel.org" <konrad@kernel.org>,
	"lenb@kernel.org" <lenb@kernel.org>
Subject: Re: [Xen-devel] [PATCH 1/8] ACPI: processor: export necessary
	interfaces
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Dec 19, 2011 at 01:43:01PM +0800, Tian, Kevin wrote:
> > From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@oracle.com]
> > Sent: Saturday, December 17, 2011 5:34 AM
> > 
> > On Wed, Nov 30, 2011 at 12:20:57PM -0500, Konrad Rzeszutek Wilk wrote:
> > > From: Kevin Tian <kevin.tian@intel.com>
> > >
> > > This patch export some necessary functions which parse processor
> > > power management information. The Xen ACPI processor driver uses them.
> > 
> > I was wondering if it could be done by moving a bunch of these
> > functions in the processor_perflib.c, but there is a lot of code
> > that would have to be moved. Way too much.
> > 
> > Perhaps another, and a nicer way would be to:
> > 
> >  1). Create a processor_driver_lib.c which would have the "generic" code
> >  2). In the processor_driver just keep the essential notifications, andk
> >      the hotplug code
> >  3). The introduce the other user of the acpi_processor_[add|remove|notify]
> >      calls as a seperate library?
> > 
> > Thoughts?
> 
> that's a cleaner approach in the long term view IMO, though it incurs more changes
> into current code base. 

Well, upstream kernels are focused on the long term view. So that sounds
like agreement.
> 
> Thanks
> Kevin
> 
> > >
> > > Signed-off-by: Yu Ke <ke.yu@intel.com>
> > > Signed-off-by: Tian Kevin <kevin.tian@intel.com>
> > > Signed-off-by: Tang Liang <liang.tang@oracle.com>
> > > Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > > ---
> > >  drivers/acpi/processor_driver.c  |   11 +++--------
> > >  drivers/acpi/processor_perflib.c |    4 ++--
> > >  include/acpi/processor.h         |   10 +++++++++-
> > >  3 files changed, 14 insertions(+), 11 deletions(-)
> > >
> > > diff --git a/drivers/acpi/processor_driver.c b/drivers/acpi/processor_driver.c
> > > index 9d7bc9f..211c078 100644
> > > --- a/drivers/acpi/processor_driver.c
> > > +++ b/drivers/acpi/processor_driver.c
> > > @@ -79,9 +79,6 @@ MODULE_AUTHOR("Paul Diefenbaugh");
> > >  MODULE_DESCRIPTION("ACPI Processor Driver");
> > >  MODULE_LICENSE("GPL");
> > >
> > > -static int acpi_processor_add(struct acpi_device *device);
> > > -static int acpi_processor_remove(struct acpi_device *device, int type);
> > > -static void acpi_processor_notify(struct acpi_device *device, u32 event);
> > >  static acpi_status acpi_processor_hotadd_init(acpi_handle handle, int
> > *p_cpu);
> > >  static int acpi_processor_handle_eject(struct acpi_processor *pr);
> > >
> > > @@ -378,7 +375,7 @@ static int acpi_processor_get_info(struct acpi_device
> > *device)
> > >
> > >  static DEFINE_PER_CPU(void *, processor_device_array);
> > >
> > > -static void acpi_processor_notify(struct acpi_device *device, u32 event)
> > > +void acpi_processor_notify(struct acpi_device *device, u32 event)
> > >  {
> > >  	struct acpi_processor *pr = acpi_driver_data(device);
> > >  	int saved;
> > > @@ -442,7 +439,7 @@ static struct notifier_block acpi_cpu_notifier =
> > >  	    .notifier_call = acpi_cpu_soft_notify,
> > >  };
> > >
> > > -static int __cpuinit acpi_processor_add(struct acpi_device *device)
> > > +int __cpuinit acpi_processor_add(struct acpi_device *device)
> > >  {
> > >  	struct acpi_processor *pr = NULL;
> > >  	int result = 0;
> > > @@ -545,7 +542,7 @@ err_free_cpumask:
> > >  	return result;
> > >  }
> > >
> > > -static int acpi_processor_remove(struct acpi_device *device, int type)
> > > +int acpi_processor_remove(struct acpi_device *device, int type)
> > >  {
> > >  	struct acpi_processor *pr = NULL;
> > >
> > > @@ -758,7 +755,6 @@ static int acpi_processor_handle_eject(struct
> > acpi_processor *pr)
> > >  }
> > >  #endif
> > >
> > > -static
> > >  void acpi_processor_install_hotplug_notify(void)
> > >  {
> > >  #ifdef CONFIG_ACPI_HOTPLUG_CPU
> > > @@ -771,7 +767,6 @@ void acpi_processor_install_hotplug_notify(void)
> > >  	register_hotcpu_notifier(&acpi_cpu_notifier);
> > >  }
> > >
> > > -static
> > >  void acpi_processor_uninstall_hotplug_notify(void)
> > >  {
> > >  #ifdef CONFIG_ACPI_HOTPLUG_CPU
> > > diff --git a/drivers/acpi/processor_perflib.c b/drivers/acpi/processor_perflib.c
> > > index 85b3237..22c6195 100644
> > > --- a/drivers/acpi/processor_perflib.c
> > > +++ b/drivers/acpi/processor_perflib.c
> > > @@ -386,7 +386,7 @@ static int
> > acpi_processor_get_performance_states(struct acpi_processor *pr)
> > >  	return result;
> > >  }
> > >
> > > -static int acpi_processor_get_performance_info(struct acpi_processor *pr)
> > > +int acpi_processor_get_performance_info(struct acpi_processor *pr)
> > >  {
> > >  	int result = 0;
> > >  	acpi_status status = AE_OK;
> > > @@ -492,7 +492,7 @@ int acpi_processor_notify_smm(struct module
> > *calling_module)
> > >
> > >  EXPORT_SYMBOL(acpi_processor_notify_smm);
> > >
> > > -static int acpi_processor_get_psd(struct acpi_processor	*pr)
> > > +int acpi_processor_get_psd(struct acpi_processor	*pr)
> > >  {
> > >  	int result = 0;
> > >  	acpi_status status = AE_OK;
> > > diff --git a/include/acpi/processor.h b/include/acpi/processor.h
> > > index 610f6fb..12657bb 100644
> > > --- a/include/acpi/processor.h
> > > +++ b/include/acpi/processor.h
> > > @@ -239,6 +239,12 @@ extern void
> > acpi_processor_unregister_performance(struct
> > >           if a _PPC object exists, rmmod is disallowed then */
> > >  int acpi_processor_notify_smm(struct module *calling_module);
> > >
> > > +void acpi_processor_install_hotplug_notify(void);
> > > +void acpi_processor_uninstall_hotplug_notify(void);
> > > +
> > > +int acpi_processor_add(struct acpi_device *device);
> > > +int acpi_processor_remove(struct acpi_device *device, int type);
> > > +void acpi_processor_notify(struct acpi_device *device, u32 event);
> > >  /* for communication between multiple parts of the processor kernel
> > module */
> > >  DECLARE_PER_CPU(struct acpi_processor *, processors);
> > >  extern struct acpi_processor_errata errata;
> > > @@ -278,7 +284,9 @@ static inline void
> > acpi_processor_ffh_cstate_enter(struct acpi_processor_cx
> > >  void acpi_processor_ppc_init(void);
> > >  void acpi_processor_ppc_exit(void);
> > >  int acpi_processor_ppc_has_changed(struct acpi_processor *pr, int
> > event_flag);
> > > -extern int acpi_processor_get_bios_limit(int cpu, unsigned int *limit);
> > > +int acpi_processor_get_performance_info(struct acpi_processor *pr);
> > > +int acpi_processor_get_psd(struct acpi_processor *pr);
> > > +int acpi_processor_get_bios_limit(int cpu, unsigned int *limit);
> > >  #else
> > >  static inline void acpi_processor_ppc_init(void)
> > >  {
> > > --
> > > 1.7.7.3
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 14:18:23 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 14:18:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rce2m-0001hj-09; Mon, 19 Dec 2011 14:18:20 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1Rce2k-0001gq-1R
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 14:18:18 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-8.tower-27.messagelabs.com!1324304184!56763801!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18436 invoked from network); 19 Dec 2011 14:16:25 -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; 19 Dec 2011 14:16: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
	pBJEHQJn027978
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Mon, 19 Dec 2011 09:17:26 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pBJEHL7T027976;
	Mon, 19 Dec 2011 09:17:21 -0500
Date: Mon, 19 Dec 2011 10:17:21 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: "Tian, Kevin" <kevin.tian@intel.com>
Message-ID: <20111219141721.GA27772@andromeda.dapyr.net>
References: <1322673664-14642-1-git-send-email-konrad.wilk@oracle.com>
	<1322673664-14642-2-git-send-email-konrad.wilk@oracle.com>
	<20111216213345.GA9832@phenom.dumpdata.com>
	<625BA99ED14B2D499DC4E29D8138F1506E01AABC72@shsmsx502.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <625BA99ED14B2D499DC4E29D8138F1506E01AABC72@shsmsx502.ccr.corp.intel.com>
User-Agent: Mutt/1.5.9i
Cc: "jeremy@goop.org" <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"mike.mcclurg@citrix.com" <mike.mcclurg@citrix.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"stefan.bader@canonical.com" <stefan.bader@canonical.com>,
	"rjw@sisk.pl" <rjw@sisk.pl>,
	"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
	"liang.tang@oracle.com" <liang.tang@oracle.com>, "Yu,
	Ke" <ke.yu@intel.com>, "konrad@kernel.org" <konrad@kernel.org>,
	"lenb@kernel.org" <lenb@kernel.org>
Subject: Re: [Xen-devel] [PATCH 1/8] ACPI: processor: export necessary
	interfaces
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Dec 19, 2011 at 01:43:01PM +0800, Tian, Kevin wrote:
> > From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@oracle.com]
> > Sent: Saturday, December 17, 2011 5:34 AM
> > 
> > On Wed, Nov 30, 2011 at 12:20:57PM -0500, Konrad Rzeszutek Wilk wrote:
> > > From: Kevin Tian <kevin.tian@intel.com>
> > >
> > > This patch export some necessary functions which parse processor
> > > power management information. The Xen ACPI processor driver uses them.
> > 
> > I was wondering if it could be done by moving a bunch of these
> > functions in the processor_perflib.c, but there is a lot of code
> > that would have to be moved. Way too much.
> > 
> > Perhaps another, and a nicer way would be to:
> > 
> >  1). Create a processor_driver_lib.c which would have the "generic" code
> >  2). In the processor_driver just keep the essential notifications, andk
> >      the hotplug code
> >  3). The introduce the other user of the acpi_processor_[add|remove|notify]
> >      calls as a seperate library?
> > 
> > Thoughts?
> 
> that's a cleaner approach in the long term view IMO, though it incurs more changes
> into current code base. 

Well, upstream kernels are focused on the long term view. So that sounds
like agreement.
> 
> Thanks
> Kevin
> 
> > >
> > > Signed-off-by: Yu Ke <ke.yu@intel.com>
> > > Signed-off-by: Tian Kevin <kevin.tian@intel.com>
> > > Signed-off-by: Tang Liang <liang.tang@oracle.com>
> > > Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > > ---
> > >  drivers/acpi/processor_driver.c  |   11 +++--------
> > >  drivers/acpi/processor_perflib.c |    4 ++--
> > >  include/acpi/processor.h         |   10 +++++++++-
> > >  3 files changed, 14 insertions(+), 11 deletions(-)
> > >
> > > diff --git a/drivers/acpi/processor_driver.c b/drivers/acpi/processor_driver.c
> > > index 9d7bc9f..211c078 100644
> > > --- a/drivers/acpi/processor_driver.c
> > > +++ b/drivers/acpi/processor_driver.c
> > > @@ -79,9 +79,6 @@ MODULE_AUTHOR("Paul Diefenbaugh");
> > >  MODULE_DESCRIPTION("ACPI Processor Driver");
> > >  MODULE_LICENSE("GPL");
> > >
> > > -static int acpi_processor_add(struct acpi_device *device);
> > > -static int acpi_processor_remove(struct acpi_device *device, int type);
> > > -static void acpi_processor_notify(struct acpi_device *device, u32 event);
> > >  static acpi_status acpi_processor_hotadd_init(acpi_handle handle, int
> > *p_cpu);
> > >  static int acpi_processor_handle_eject(struct acpi_processor *pr);
> > >
> > > @@ -378,7 +375,7 @@ static int acpi_processor_get_info(struct acpi_device
> > *device)
> > >
> > >  static DEFINE_PER_CPU(void *, processor_device_array);
> > >
> > > -static void acpi_processor_notify(struct acpi_device *device, u32 event)
> > > +void acpi_processor_notify(struct acpi_device *device, u32 event)
> > >  {
> > >  	struct acpi_processor *pr = acpi_driver_data(device);
> > >  	int saved;
> > > @@ -442,7 +439,7 @@ static struct notifier_block acpi_cpu_notifier =
> > >  	    .notifier_call = acpi_cpu_soft_notify,
> > >  };
> > >
> > > -static int __cpuinit acpi_processor_add(struct acpi_device *device)
> > > +int __cpuinit acpi_processor_add(struct acpi_device *device)
> > >  {
> > >  	struct acpi_processor *pr = NULL;
> > >  	int result = 0;
> > > @@ -545,7 +542,7 @@ err_free_cpumask:
> > >  	return result;
> > >  }
> > >
> > > -static int acpi_processor_remove(struct acpi_device *device, int type)
> > > +int acpi_processor_remove(struct acpi_device *device, int type)
> > >  {
> > >  	struct acpi_processor *pr = NULL;
> > >
> > > @@ -758,7 +755,6 @@ static int acpi_processor_handle_eject(struct
> > acpi_processor *pr)
> > >  }
> > >  #endif
> > >
> > > -static
> > >  void acpi_processor_install_hotplug_notify(void)
> > >  {
> > >  #ifdef CONFIG_ACPI_HOTPLUG_CPU
> > > @@ -771,7 +767,6 @@ void acpi_processor_install_hotplug_notify(void)
> > >  	register_hotcpu_notifier(&acpi_cpu_notifier);
> > >  }
> > >
> > > -static
> > >  void acpi_processor_uninstall_hotplug_notify(void)
> > >  {
> > >  #ifdef CONFIG_ACPI_HOTPLUG_CPU
> > > diff --git a/drivers/acpi/processor_perflib.c b/drivers/acpi/processor_perflib.c
> > > index 85b3237..22c6195 100644
> > > --- a/drivers/acpi/processor_perflib.c
> > > +++ b/drivers/acpi/processor_perflib.c
> > > @@ -386,7 +386,7 @@ static int
> > acpi_processor_get_performance_states(struct acpi_processor *pr)
> > >  	return result;
> > >  }
> > >
> > > -static int acpi_processor_get_performance_info(struct acpi_processor *pr)
> > > +int acpi_processor_get_performance_info(struct acpi_processor *pr)
> > >  {
> > >  	int result = 0;
> > >  	acpi_status status = AE_OK;
> > > @@ -492,7 +492,7 @@ int acpi_processor_notify_smm(struct module
> > *calling_module)
> > >
> > >  EXPORT_SYMBOL(acpi_processor_notify_smm);
> > >
> > > -static int acpi_processor_get_psd(struct acpi_processor	*pr)
> > > +int acpi_processor_get_psd(struct acpi_processor	*pr)
> > >  {
> > >  	int result = 0;
> > >  	acpi_status status = AE_OK;
> > > diff --git a/include/acpi/processor.h b/include/acpi/processor.h
> > > index 610f6fb..12657bb 100644
> > > --- a/include/acpi/processor.h
> > > +++ b/include/acpi/processor.h
> > > @@ -239,6 +239,12 @@ extern void
> > acpi_processor_unregister_performance(struct
> > >           if a _PPC object exists, rmmod is disallowed then */
> > >  int acpi_processor_notify_smm(struct module *calling_module);
> > >
> > > +void acpi_processor_install_hotplug_notify(void);
> > > +void acpi_processor_uninstall_hotplug_notify(void);
> > > +
> > > +int acpi_processor_add(struct acpi_device *device);
> > > +int acpi_processor_remove(struct acpi_device *device, int type);
> > > +void acpi_processor_notify(struct acpi_device *device, u32 event);
> > >  /* for communication between multiple parts of the processor kernel
> > module */
> > >  DECLARE_PER_CPU(struct acpi_processor *, processors);
> > >  extern struct acpi_processor_errata errata;
> > > @@ -278,7 +284,9 @@ static inline void
> > acpi_processor_ffh_cstate_enter(struct acpi_processor_cx
> > >  void acpi_processor_ppc_init(void);
> > >  void acpi_processor_ppc_exit(void);
> > >  int acpi_processor_ppc_has_changed(struct acpi_processor *pr, int
> > event_flag);
> > > -extern int acpi_processor_get_bios_limit(int cpu, unsigned int *limit);
> > > +int acpi_processor_get_performance_info(struct acpi_processor *pr);
> > > +int acpi_processor_get_psd(struct acpi_processor *pr);
> > > +int acpi_processor_get_bios_limit(int cpu, unsigned int *limit);
> > >  #else
> > >  static inline void acpi_processor_ppc_init(void)
> > >  {
> > > --
> > > 1.7.7.3
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 14:26:51 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 14:26:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RceAw-0002oW-1j; Mon, 19 Dec 2011 14:26:46 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1RceAu-0002oN-N6
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 14:26:45 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-3.tower-21.messagelabs.com!1324304796!8829059!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8477 invoked from network); 19 Dec 2011 14:26:37 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-3.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 19 Dec 2011 14:26:37 -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
	pBJEQQeg028446
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Mon, 19 Dec 2011 09:26:26 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pBJEQQDM028444;
	Mon, 19 Dec 2011 09:26:26 -0500
Date: Mon, 19 Dec 2011 10:26:26 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: "Tian, Kevin" <kevin.tian@intel.com>
Message-ID: <20111219142626.GB27772@andromeda.dapyr.net>
References: <1322673664-14642-1-git-send-email-konrad.wilk@oracle.com>
	<1322673664-14642-4-git-send-email-konrad.wilk@oracle.com>
	<20111216220342.GC9832@phenom.dumpdata.com>
	<625BA99ED14B2D499DC4E29D8138F1506E01AABC7A@shsmsx502.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <625BA99ED14B2D499DC4E29D8138F1506E01AABC7A@shsmsx502.ccr.corp.intel.com>
User-Agent: Mutt/1.5.9i
Cc: "jeremy@goop.org" <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"mike.mcclurg@citrix.com" <mike.mcclurg@citrix.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"stefan.bader@canonical.com" <stefan.bader@canonical.com>,
	"rjw@sisk.pl" <rjw@sisk.pl>,
	"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
	"liang.tang@oracle.com" <liang.tang@oracle.com>, "Yu,
	Ke" <ke.yu@intel.com>, "konrad@kernel.org" <konrad@kernel.org>,
	"lenb@kernel.org" <lenb@kernel.org>
Subject: Re: [Xen-devel] [PATCH 3/8] ACPI: processor: add
	__acpi_processor_[un]register_driver helpers.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Dec 19, 2011 at 01:48:01PM +0800, Tian, Kevin wrote:
> > From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@oracle.com]
> > Sent: Saturday, December 17, 2011 6:04 AM
> > 
> > On Wed, Nov 30, 2011 at 12:20:59PM -0500, Konrad Rzeszutek Wilk wrote:
> > > From: Tang Liang <liang.tang@oracle.com>
> > >
> > > This patch implement __acpi_processor_[un]register_driver helper,
> > > so we can registry override processor driver function. Specifically
> > > the Xen processor driver.
> > 
> > Liang,
> > 
> > Is the reason we are doing this b/c we need to call acpi_bus_register_driver
> > and inhibit the registration of 'acpi_processor_driver' ?
> > 
> > And the reason we don't want 'acpi_processor_driver' to run is b/c of what?
> > If the cpuidle is disabled what is the harm of running the
> > 'acpi_processor_driver'
> > driver?
> 
> IIRC, the reason why we want a Xen specific driver is because current driver
> is integrated with OS logic too tightly, e.g. the various checks on VCPU related
> structures. Long time ago the 1st version in Xen was to use same driver, by
> adding various tweaking lines inside which makes it completely messed. Then
> later it's found that it's clearer to create a Xen specific wrapping driver, by 
> invoking some exported functions from existing one.

What I am asking is does it matter "if the current driver is integrated
with OS logic to tighly" - as it is not running anyhow (b/c cpuidle is
disabled).

And if Xen specific driver can run along-side the generic one - since
the generic one is not doing any work (b/c cpuidle is disabled).

That is what I am trying to figure out - since this patch purpose is to
thwart the generic driver from running and allowing the xen one to run.
> 
> Thanks
> Kevin
> 
> > 
> > >
> > > By default the values are set to the native one.
> > >
> > > Signed-off-by: Tang Liang <liang.tang@oracle.com>
> > > Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > > ---
> > >  drivers/acpi/processor_driver.c |   35
> > +++++++++++++++++++++++++++++------
> > >  include/acpi/processor.h        |    6 +++++-
> > >  2 files changed, 34 insertions(+), 7 deletions(-)
> > >
> > > diff --git a/drivers/acpi/processor_driver.c b/drivers/acpi/processor_driver.c
> > > index 211c078..55f0b89 100644
> > > --- a/drivers/acpi/processor_driver.c
> > > +++ b/drivers/acpi/processor_driver.c
> > > @@ -90,6 +90,11 @@ static const struct acpi_device_id
> > processor_device_ids[] = {
> > >  };
> > >  MODULE_DEVICE_TABLE(acpi, processor_device_ids);
> > >
> > > +int (*__acpi_processor_register_driver)(void) =
> > acpi_processor_register_driver;
> > > +void (*__acpi_processor_unregister_driver)(void) \
> > > +	= acpi_processor_unregister_driver;
> > > +
> > > +
> > >  static struct acpi_driver acpi_processor_driver = {
> > >  	.name = "processor",
> > >  	.class = ACPI_PROCESSOR_CLASS,
> > > @@ -779,6 +784,22 @@ void acpi_processor_uninstall_hotplug_notify(void)
> > >  	unregister_hotcpu_notifier(&acpi_cpu_notifier);
> > >  }
> > >
> > > +int acpi_processor_register_driver(void)
> > > +{
> > > +	int result = 0;
> > > +
> > > +	result = acpi_bus_register_driver(&acpi_processor_driver);
> > > +	return result;
> > > +}
> > > +
> > > +void acpi_processor_unregister_driver(void)
> > > +{
> > > +	acpi_bus_unregister_driver(&acpi_processor_driver);
> > > +
> > > +	cpuidle_unregister_driver(&acpi_idle_driver);
> > > +
> > > +	return;
> > > +}
> > >  /*
> > >   * We keep the driver loaded even when ACPI is not running.
> > >   * This is needed for the powernow-k8 driver, that works even without
> > > @@ -794,9 +815,11 @@ static int __init acpi_processor_init(void)
> > >
> > >  	memset(&errata, 0, sizeof(errata));
> > >
> > > -	result = acpi_bus_register_driver(&acpi_processor_driver);
> > > -	if (result < 0)
> > > -		return result;
> > > +	if (__acpi_processor_register_driver) {
> > > +		result = __acpi_processor_register_driver();
> > > +		if (result < 0)
> > > +			return result;
> > > +	}
> > >
> > >  	acpi_processor_install_hotplug_notify();
> > >
> > > @@ -809,6 +832,7 @@ static int __init acpi_processor_init(void)
> > >  	return 0;
> > >  }
> > >
> > > +
> > >  static void __exit acpi_processor_exit(void)
> > >  {
> > >  	if (acpi_disabled)
> > > @@ -820,9 +844,8 @@ static void __exit acpi_processor_exit(void)
> > >
> > >  	acpi_processor_uninstall_hotplug_notify();
> > >
> > > -	acpi_bus_unregister_driver(&acpi_processor_driver);
> > > -
> > > -	cpuidle_unregister_driver(&acpi_idle_driver);
> > > +	if (__acpi_processor_unregister_driver)
> > > +		__acpi_processor_unregister_driver();
> > >
> > >  	return;
> > >  }
> > > diff --git a/include/acpi/processor.h b/include/acpi/processor.h
> > > index bd99fb6..969cbc9 100644
> > > --- a/include/acpi/processor.h
> > > +++ b/include/acpi/processor.h
> > > @@ -225,6 +225,9 @@ struct acpi_processor_errata {
> > >  	} piix4;
> > >  };
> > >
> > > +extern int (*__acpi_processor_register_driver)(void);
> > > +extern void (*__acpi_processor_unregister_driver)(void);
> > > +
> > >  extern int acpi_processor_preregister_performance(struct
> > >  						  acpi_processor_performance
> > >  						  __percpu *performance);
> > > @@ -242,7 +245,8 @@ int acpi_processor_notify_smm(struct module
> > *calling_module);
> > >
> > >  void acpi_processor_install_hotplug_notify(void);
> > >  void acpi_processor_uninstall_hotplug_notify(void);
> > > -
> > > +int acpi_processor_register_driver(void);
> > > +void acpi_processor_unregister_driver(void);
> > >  int acpi_processor_add(struct acpi_device *device);
> > >  int acpi_processor_remove(struct acpi_device *device, int type);
> > >  void acpi_processor_notify(struct acpi_device *device, u32 event);
> > > --
> > > 1.7.7.3
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 14:26:51 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 14:26:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RceAw-0002oW-1j; Mon, 19 Dec 2011 14:26:46 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1RceAu-0002oN-N6
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 14:26:45 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-3.tower-21.messagelabs.com!1324304796!8829059!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8477 invoked from network); 19 Dec 2011 14:26:37 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-3.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 19 Dec 2011 14:26:37 -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
	pBJEQQeg028446
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Mon, 19 Dec 2011 09:26:26 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pBJEQQDM028444;
	Mon, 19 Dec 2011 09:26:26 -0500
Date: Mon, 19 Dec 2011 10:26:26 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: "Tian, Kevin" <kevin.tian@intel.com>
Message-ID: <20111219142626.GB27772@andromeda.dapyr.net>
References: <1322673664-14642-1-git-send-email-konrad.wilk@oracle.com>
	<1322673664-14642-4-git-send-email-konrad.wilk@oracle.com>
	<20111216220342.GC9832@phenom.dumpdata.com>
	<625BA99ED14B2D499DC4E29D8138F1506E01AABC7A@shsmsx502.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <625BA99ED14B2D499DC4E29D8138F1506E01AABC7A@shsmsx502.ccr.corp.intel.com>
User-Agent: Mutt/1.5.9i
Cc: "jeremy@goop.org" <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"mike.mcclurg@citrix.com" <mike.mcclurg@citrix.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"stefan.bader@canonical.com" <stefan.bader@canonical.com>,
	"rjw@sisk.pl" <rjw@sisk.pl>,
	"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
	"liang.tang@oracle.com" <liang.tang@oracle.com>, "Yu,
	Ke" <ke.yu@intel.com>, "konrad@kernel.org" <konrad@kernel.org>,
	"lenb@kernel.org" <lenb@kernel.org>
Subject: Re: [Xen-devel] [PATCH 3/8] ACPI: processor: add
	__acpi_processor_[un]register_driver helpers.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Dec 19, 2011 at 01:48:01PM +0800, Tian, Kevin wrote:
> > From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@oracle.com]
> > Sent: Saturday, December 17, 2011 6:04 AM
> > 
> > On Wed, Nov 30, 2011 at 12:20:59PM -0500, Konrad Rzeszutek Wilk wrote:
> > > From: Tang Liang <liang.tang@oracle.com>
> > >
> > > This patch implement __acpi_processor_[un]register_driver helper,
> > > so we can registry override processor driver function. Specifically
> > > the Xen processor driver.
> > 
> > Liang,
> > 
> > Is the reason we are doing this b/c we need to call acpi_bus_register_driver
> > and inhibit the registration of 'acpi_processor_driver' ?
> > 
> > And the reason we don't want 'acpi_processor_driver' to run is b/c of what?
> > If the cpuidle is disabled what is the harm of running the
> > 'acpi_processor_driver'
> > driver?
> 
> IIRC, the reason why we want a Xen specific driver is because current driver
> is integrated with OS logic too tightly, e.g. the various checks on VCPU related
> structures. Long time ago the 1st version in Xen was to use same driver, by
> adding various tweaking lines inside which makes it completely messed. Then
> later it's found that it's clearer to create a Xen specific wrapping driver, by 
> invoking some exported functions from existing one.

What I am asking is does it matter "if the current driver is integrated
with OS logic to tighly" - as it is not running anyhow (b/c cpuidle is
disabled).

And if Xen specific driver can run along-side the generic one - since
the generic one is not doing any work (b/c cpuidle is disabled).

That is what I am trying to figure out - since this patch purpose is to
thwart the generic driver from running and allowing the xen one to run.
> 
> Thanks
> Kevin
> 
> > 
> > >
> > > By default the values are set to the native one.
> > >
> > > Signed-off-by: Tang Liang <liang.tang@oracle.com>
> > > Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > > ---
> > >  drivers/acpi/processor_driver.c |   35
> > +++++++++++++++++++++++++++++------
> > >  include/acpi/processor.h        |    6 +++++-
> > >  2 files changed, 34 insertions(+), 7 deletions(-)
> > >
> > > diff --git a/drivers/acpi/processor_driver.c b/drivers/acpi/processor_driver.c
> > > index 211c078..55f0b89 100644
> > > --- a/drivers/acpi/processor_driver.c
> > > +++ b/drivers/acpi/processor_driver.c
> > > @@ -90,6 +90,11 @@ static const struct acpi_device_id
> > processor_device_ids[] = {
> > >  };
> > >  MODULE_DEVICE_TABLE(acpi, processor_device_ids);
> > >
> > > +int (*__acpi_processor_register_driver)(void) =
> > acpi_processor_register_driver;
> > > +void (*__acpi_processor_unregister_driver)(void) \
> > > +	= acpi_processor_unregister_driver;
> > > +
> > > +
> > >  static struct acpi_driver acpi_processor_driver = {
> > >  	.name = "processor",
> > >  	.class = ACPI_PROCESSOR_CLASS,
> > > @@ -779,6 +784,22 @@ void acpi_processor_uninstall_hotplug_notify(void)
> > >  	unregister_hotcpu_notifier(&acpi_cpu_notifier);
> > >  }
> > >
> > > +int acpi_processor_register_driver(void)
> > > +{
> > > +	int result = 0;
> > > +
> > > +	result = acpi_bus_register_driver(&acpi_processor_driver);
> > > +	return result;
> > > +}
> > > +
> > > +void acpi_processor_unregister_driver(void)
> > > +{
> > > +	acpi_bus_unregister_driver(&acpi_processor_driver);
> > > +
> > > +	cpuidle_unregister_driver(&acpi_idle_driver);
> > > +
> > > +	return;
> > > +}
> > >  /*
> > >   * We keep the driver loaded even when ACPI is not running.
> > >   * This is needed for the powernow-k8 driver, that works even without
> > > @@ -794,9 +815,11 @@ static int __init acpi_processor_init(void)
> > >
> > >  	memset(&errata, 0, sizeof(errata));
> > >
> > > -	result = acpi_bus_register_driver(&acpi_processor_driver);
> > > -	if (result < 0)
> > > -		return result;
> > > +	if (__acpi_processor_register_driver) {
> > > +		result = __acpi_processor_register_driver();
> > > +		if (result < 0)
> > > +			return result;
> > > +	}
> > >
> > >  	acpi_processor_install_hotplug_notify();
> > >
> > > @@ -809,6 +832,7 @@ static int __init acpi_processor_init(void)
> > >  	return 0;
> > >  }
> > >
> > > +
> > >  static void __exit acpi_processor_exit(void)
> > >  {
> > >  	if (acpi_disabled)
> > > @@ -820,9 +844,8 @@ static void __exit acpi_processor_exit(void)
> > >
> > >  	acpi_processor_uninstall_hotplug_notify();
> > >
> > > -	acpi_bus_unregister_driver(&acpi_processor_driver);
> > > -
> > > -	cpuidle_unregister_driver(&acpi_idle_driver);
> > > +	if (__acpi_processor_unregister_driver)
> > > +		__acpi_processor_unregister_driver();
> > >
> > >  	return;
> > >  }
> > > diff --git a/include/acpi/processor.h b/include/acpi/processor.h
> > > index bd99fb6..969cbc9 100644
> > > --- a/include/acpi/processor.h
> > > +++ b/include/acpi/processor.h
> > > @@ -225,6 +225,9 @@ struct acpi_processor_errata {
> > >  	} piix4;
> > >  };
> > >
> > > +extern int (*__acpi_processor_register_driver)(void);
> > > +extern void (*__acpi_processor_unregister_driver)(void);
> > > +
> > >  extern int acpi_processor_preregister_performance(struct
> > >  						  acpi_processor_performance
> > >  						  __percpu *performance);
> > > @@ -242,7 +245,8 @@ int acpi_processor_notify_smm(struct module
> > *calling_module);
> > >
> > >  void acpi_processor_install_hotplug_notify(void);
> > >  void acpi_processor_uninstall_hotplug_notify(void);
> > > -
> > > +int acpi_processor_register_driver(void);
> > > +void acpi_processor_unregister_driver(void);
> > >  int acpi_processor_add(struct acpi_device *device);
> > >  int acpi_processor_remove(struct acpi_device *device, int type);
> > >  void acpi_processor_notify(struct acpi_device *device, u32 event);
> > > --
> > > 1.7.7.3
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 14:27:17 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 14: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.xensource.com>)
	id 1RceBI-0002qg-FC; Mon, 19 Dec 2011 14:27:08 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1RceBH-0002qD-Gx
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 14:27:07 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-10.tower-216.messagelabs.com!1324304820!7926794!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31420 invoked from network); 19 Dec 2011 14:27:01 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-10.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 19 Dec 2011 14:27:01 -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
	pBJEQkUm028481
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Mon, 19 Dec 2011 09:26:46 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pBJEQkEX028479;
	Mon, 19 Dec 2011 09:26:46 -0500
Date: Mon, 19 Dec 2011 10:26:45 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: liang tang <liang.tang@oracle.com>
Message-ID: <20111219142645.GC27772@andromeda.dapyr.net>
References: <1322673664-14642-1-git-send-email-konrad.wilk@oracle.com>
	<1322673664-14642-5-git-send-email-konrad.wilk@oracle.com>
	<20111216213618.GB9832@phenom.dumpdata.com>
	<4EEF12DD.2020308@oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4EEF12DD.2020308@oracle.com>
User-Agent: Mutt/1.5.9i
Cc: jeremy@goop.org, xen-devel@lists.xensource.com, Ian.Campbell@citrix.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	mike.mcclurg@citrix.com, linux-acpi@vger.kernel.org,
	stefan.bader@canonical.com, rjw@sisk.pl, konrad@kernel.org, lenb@kernel.org
Subject: Re: [Xen-devel] [PATCH 4/8] ACPI: processor: Don't setup cpu idle
	driver and handler when we do not want them.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Dec 19, 2011 at 06:33:01PM +0800, liang tang wrote:
> On 2011-12-17 5:36, Konrad Rzeszutek Wilk wrote:
> >On Wed, Nov 30, 2011 at 12:21:00PM -0500, Konrad Rzeszutek Wilk wrote:
> >>From: Kevin Tian<kevin.tian@intel.com>
> >>
> >>This patch inhibits processing of the CPU idle handler if it is not
> >>set to the appropiate one. This is needed by the Xen processor driver
> >>which, while still needing processor details, wants to use the 
> >>default_idle
> >>call (which makes a yield hypercall).
> >Which I think is not required anymore with the 
> >d91ee5863b71e8c90eaf6035bff3078a85e2e7b5
> >(cpuidle: replace xen access to x86 pm_idle and default_idle) and
> >62027aea23fcd14478abdddd3b74a4e0f5fb2984
> >(cpuidle: create bootparam "cpuidle.off=1")
> >
> >Liang, can you double-check that please?
> >
> Hi,Konrad
> I just read the code ,I think  don't need that code too. I will double 
> check tomorrow.

Great! Thanks!

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 14:27:17 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 14: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.xensource.com>)
	id 1RceBI-0002qg-FC; Mon, 19 Dec 2011 14:27:08 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1RceBH-0002qD-Gx
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 14:27:07 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-10.tower-216.messagelabs.com!1324304820!7926794!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31420 invoked from network); 19 Dec 2011 14:27:01 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-10.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 19 Dec 2011 14:27:01 -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
	pBJEQkUm028481
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Mon, 19 Dec 2011 09:26:46 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pBJEQkEX028479;
	Mon, 19 Dec 2011 09:26:46 -0500
Date: Mon, 19 Dec 2011 10:26:45 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: liang tang <liang.tang@oracle.com>
Message-ID: <20111219142645.GC27772@andromeda.dapyr.net>
References: <1322673664-14642-1-git-send-email-konrad.wilk@oracle.com>
	<1322673664-14642-5-git-send-email-konrad.wilk@oracle.com>
	<20111216213618.GB9832@phenom.dumpdata.com>
	<4EEF12DD.2020308@oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4EEF12DD.2020308@oracle.com>
User-Agent: Mutt/1.5.9i
Cc: jeremy@goop.org, xen-devel@lists.xensource.com, Ian.Campbell@citrix.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	mike.mcclurg@citrix.com, linux-acpi@vger.kernel.org,
	stefan.bader@canonical.com, rjw@sisk.pl, konrad@kernel.org, lenb@kernel.org
Subject: Re: [Xen-devel] [PATCH 4/8] ACPI: processor: Don't setup cpu idle
	driver and handler when we do not want them.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Dec 19, 2011 at 06:33:01PM +0800, liang tang wrote:
> On 2011-12-17 5:36, Konrad Rzeszutek Wilk wrote:
> >On Wed, Nov 30, 2011 at 12:21:00PM -0500, Konrad Rzeszutek Wilk wrote:
> >>From: Kevin Tian<kevin.tian@intel.com>
> >>
> >>This patch inhibits processing of the CPU idle handler if it is not
> >>set to the appropiate one. This is needed by the Xen processor driver
> >>which, while still needing processor details, wants to use the 
> >>default_idle
> >>call (which makes a yield hypercall).
> >Which I think is not required anymore with the 
> >d91ee5863b71e8c90eaf6035bff3078a85e2e7b5
> >(cpuidle: replace xen access to x86 pm_idle and default_idle) and
> >62027aea23fcd14478abdddd3b74a4e0f5fb2984
> >(cpuidle: create bootparam "cpuidle.off=1")
> >
> >Liang, can you double-check that please?
> >
> Hi,Konrad
> I just read the code ,I think  don't need that code too. I will double 
> check tomorrow.

Great! Thanks!

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 14:28:31 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 14:28:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RceCU-0002z0-8F; Mon, 19 Dec 2011 14:28:22 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <avi@redhat.com>) id 1RceCS-0002yI-E1
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 14:28:20 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1324304045!7886932!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDY0OTI=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11642 invoked from network); 19 Dec 2011 14:14:05 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-16.tower-216.messagelabs.com with SMTP;
	19 Dec 2011 14:14:05 -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 pBJEE3Cc004314
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 19 Dec 2011 09:14:03 -0500
Received: from cleopatra.tlv.redhat.com (cleopatra.tlv.redhat.com
	[10.35.255.11])
	by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id pBJEE0hG006981; Mon, 19 Dec 2011 09:14:02 -0500
Received: from s01.tlv.redhat.com (s01.tlv.redhat.com [10.35.255.8])
	by cleopatra.tlv.redhat.com (Postfix) with ESMTP id AEFDE250BAA;
	Mon, 19 Dec 2011 16:13:54 +0200 (IST)
From: Avi Kivity <avi@redhat.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	qemu-devel@nongnu.org, "Michael S. Tsirkin" <mst@redhat.com>
Date: Mon, 19 Dec 2011 16:13:32 +0200
Message-Id: <1324304024-11220-12-git-send-email-avi@redhat.com>
In-Reply-To: <1324304024-11220-1-git-send-email-avi@redhat.com>
References: <1324304024-11220-1-git-send-email-avi@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
Cc: xen-devel@lists.xensource.com, kvm@vger.kernel.org
Subject: [Xen-devel] [PATCH 11/23] kvm: switch kvm slots to use host virtual
	address instead of ram_addr_t
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This simplifies a later switch to the memory API in slot management.

Signed-off-by: Avi Kivity <avi@redhat.com>
---
 kvm-all.c         |   29 +++++++++++++++++------------
 kvm.h             |    4 ++--
 memory.c          |    6 +++---
 target-i386/kvm.c |    7 +++----
 4 files changed, 25 insertions(+), 21 deletions(-)

diff --git a/kvm-all.c b/kvm-all.c
index 4c466d6..4f58ae8 100644
--- a/kvm-all.c
+++ b/kvm-all.c
@@ -50,7 +50,7 @@
 {
     target_phys_addr_t start_addr;
     ram_addr_t memory_size;
-    ram_addr_t phys_offset;
+    void *ram;
     int slot;
     int flags;
 } KVMSlot;
@@ -146,17 +146,16 @@ struct KVMState
     return found;
 }
 
-int kvm_physical_memory_addr_from_ram(KVMState *s, ram_addr_t ram_addr,
-                                      target_phys_addr_t *phys_addr)
+int kvm_physical_memory_addr_from_host(KVMState *s, void *ram,
+                                       target_phys_addr_t *phys_addr)
 {
     int i;
 
     for (i = 0; i < ARRAY_SIZE(s->slots); i++) {
         KVMSlot *mem = &s->slots[i];
 
-        if (ram_addr >= mem->phys_offset &&
-            ram_addr < mem->phys_offset + mem->memory_size) {
-            *phys_addr = mem->start_addr + (ram_addr - mem->phys_offset);
+        if (ram >= mem->ram && ram < mem->ram + mem->memory_size) {
+            *phys_addr = mem->start_addr + (ram - mem->ram);
             return 1;
         }
     }
@@ -171,7 +170,7 @@ static int kvm_set_user_memory_region(KVMState *s, KVMSlot *slot)
     mem.slot = slot->slot;
     mem.guest_phys_addr = slot->start_addr;
     mem.memory_size = slot->memory_size;
-    mem.userspace_addr = (unsigned long)qemu_safe_ram_ptr(slot->phys_offset);
+    mem.userspace_addr = (unsigned long)slot->ram;
     mem.flags = slot->flags;
     if (s->migration_log) {
         mem.flags |= KVM_MEM_LOG_DIRTY_PAGES;
@@ -527,6 +526,7 @@ static void kvm_set_phys_mem(target_phys_addr_t start_addr, ram_addr_t size,
     ram_addr_t flags = phys_offset & ~TARGET_PAGE_MASK;
     KVMSlot *mem, old;
     int err;
+    void *ram = NULL;
 
     /* kvm works in page size chunks, but the function may be called
        with sub-page size and unaligned start address. */
@@ -536,6 +536,10 @@ static void kvm_set_phys_mem(target_phys_addr_t start_addr, ram_addr_t size,
     /* KVM does not support read-only slots */
     phys_offset &= ~IO_MEM_ROM;
 
+    if ((phys_offset & ~TARGET_PAGE_MASK) == IO_MEM_RAM) {
+        ram = qemu_safe_ram_ptr(phys_offset);
+    }
+
     while (1) {
         mem = kvm_lookup_overlapping_slot(s, start_addr, start_addr + size);
         if (!mem) {
@@ -544,7 +548,7 @@ static void kvm_set_phys_mem(target_phys_addr_t start_addr, ram_addr_t size,
 
         if (flags < IO_MEM_UNASSIGNED && start_addr >= mem->start_addr &&
             (start_addr + size <= mem->start_addr + mem->memory_size) &&
-            (phys_offset - start_addr == mem->phys_offset - mem->start_addr)) {
+            (ram - start_addr == mem->ram - mem->start_addr)) {
             /* The new slot fits into the existing one and comes with
              * identical parameters - update flags and done. */
             kvm_slot_dirty_pages_log_change(mem, log_dirty);
@@ -576,7 +580,7 @@ static void kvm_set_phys_mem(target_phys_addr_t start_addr, ram_addr_t size,
             mem = kvm_alloc_slot(s);
             mem->memory_size = old.memory_size;
             mem->start_addr = old.start_addr;
-            mem->phys_offset = old.phys_offset;
+            mem->ram = old.ram;
             mem->flags = kvm_mem_flags(s, log_dirty);
 
             err = kvm_set_user_memory_region(s, mem);
@@ -588,6 +592,7 @@ static void kvm_set_phys_mem(target_phys_addr_t start_addr, ram_addr_t size,
 
             start_addr += old.memory_size;
             phys_offset += old.memory_size;
+            ram += old.memory_size;
             size -= old.memory_size;
             continue;
         }
@@ -597,7 +602,7 @@ static void kvm_set_phys_mem(target_phys_addr_t start_addr, ram_addr_t size,
             mem = kvm_alloc_slot(s);
             mem->memory_size = start_addr - old.start_addr;
             mem->start_addr = old.start_addr;
-            mem->phys_offset = old.phys_offset;
+            mem->ram = old.ram;
             mem->flags =  kvm_mem_flags(s, log_dirty);
 
             err = kvm_set_user_memory_region(s, mem);
@@ -621,7 +626,7 @@ static void kvm_set_phys_mem(target_phys_addr_t start_addr, ram_addr_t size,
             mem->start_addr = start_addr + size;
             size_delta = mem->start_addr - old.start_addr;
             mem->memory_size = old.memory_size - size_delta;
-            mem->phys_offset = old.phys_offset + size_delta;
+            mem->ram = old.ram + size_delta;
             mem->flags = kvm_mem_flags(s, log_dirty);
 
             err = kvm_set_user_memory_region(s, mem);
@@ -644,7 +649,7 @@ static void kvm_set_phys_mem(target_phys_addr_t start_addr, ram_addr_t size,
     mem = kvm_alloc_slot(s);
     mem->memory_size = size;
     mem->start_addr = start_addr;
-    mem->phys_offset = phys_offset;
+    mem->ram = ram;
     mem->flags = kvm_mem_flags(s, log_dirty);
 
     err = kvm_set_user_memory_region(s, mem);
diff --git a/kvm.h b/kvm.h
index 243b063..c1de81a 100644
--- a/kvm.h
+++ b/kvm.h
@@ -188,8 +188,8 @@ static inline void cpu_synchronize_post_init(CPUState *env)
 
 
 #if !defined(CONFIG_USER_ONLY)
-int kvm_physical_memory_addr_from_ram(KVMState *s, ram_addr_t ram_addr,
-                                      target_phys_addr_t *phys_addr);
+int kvm_physical_memory_addr_from_host(KVMState *s, void *ram_addr,
+                                       target_phys_addr_t *phys_addr);
 #endif
 
 #endif
diff --git a/memory.c b/memory.c
index 2e5ff43..c08186d 100644
--- a/memory.c
+++ b/memory.c
@@ -764,11 +764,11 @@ static void address_space_update_topology_pass(AddressSpace *as,
 
             if (adding) {
                 if (frold->dirty_log_mask && !frnew->dirty_log_mask) {
-                    MEMORY_LISTENER_UPDATE_REGION(frold, as, log_stop);
+                    MEMORY_LISTENER_UPDATE_REGION(frnew, as, log_stop);
                     as->ops->log_stop(as, frnew);
                 } else if (frnew->dirty_log_mask && !frold->dirty_log_mask) {
                     as->ops->log_start(as, frnew);
-                    MEMORY_LISTENER_UPDATE_REGION(frold, as, log_start);
+                    MEMORY_LISTENER_UPDATE_REGION(frnew, as, log_start);
                 }
             }
 
@@ -779,7 +779,7 @@ static void address_space_update_topology_pass(AddressSpace *as,
 
             if (adding) {
                 as->ops->range_add(as, frnew);
-                MEMORY_LISTENER_UPDATE_REGION(frold, as, region_add);
+                MEMORY_LISTENER_UPDATE_REGION(frnew, as, region_add);
             }
 
             ++inew;
diff --git a/target-i386/kvm.c b/target-i386/kvm.c
index 5bfc21f..74d81ef 100644
--- a/target-i386/kvm.c
+++ b/target-i386/kvm.c
@@ -253,8 +253,7 @@ int kvm_arch_on_sigbus_vcpu(CPUState *env, int code, void *addr)
     if ((env->mcg_cap & MCG_SER_P) && addr
         && (code == BUS_MCEERR_AR || code == BUS_MCEERR_AO)) {
         if (qemu_ram_addr_from_host(addr, &ram_addr) ||
-            !kvm_physical_memory_addr_from_ram(env->kvm_state, ram_addr,
-                                               &paddr)) {
+            !kvm_physical_memory_addr_from_host(env->kvm_state, addr, &paddr)) {
             fprintf(stderr, "Hardware memory error for memory used by "
                     "QEMU itself instead of guest system!\n");
             /* Hope we are lucky for AO MCE */
@@ -286,8 +285,8 @@ int kvm_arch_on_sigbus(int code, void *addr)
 
         /* Hope we are lucky for AO MCE */
         if (qemu_ram_addr_from_host(addr, &ram_addr) ||
-            !kvm_physical_memory_addr_from_ram(first_cpu->kvm_state, ram_addr,
-                                               &paddr)) {
+            !kvm_physical_memory_addr_from_host(first_cpu->kvm_state, addr,
+                                                &paddr)) {
             fprintf(stderr, "Hardware memory error for memory used by "
                     "QEMU itself instead of guest system!: %p\n", addr);
             return 0;
-- 
1.7.7.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 14:28:31 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 14:28:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RceCU-0002z0-8F; Mon, 19 Dec 2011 14:28:22 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <avi@redhat.com>) id 1RceCS-0002yI-E1
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 14:28:20 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1324304045!7886932!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDY0OTI=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11642 invoked from network); 19 Dec 2011 14:14:05 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-16.tower-216.messagelabs.com with SMTP;
	19 Dec 2011 14:14:05 -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 pBJEE3Cc004314
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 19 Dec 2011 09:14:03 -0500
Received: from cleopatra.tlv.redhat.com (cleopatra.tlv.redhat.com
	[10.35.255.11])
	by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id pBJEE0hG006981; Mon, 19 Dec 2011 09:14:02 -0500
Received: from s01.tlv.redhat.com (s01.tlv.redhat.com [10.35.255.8])
	by cleopatra.tlv.redhat.com (Postfix) with ESMTP id AEFDE250BAA;
	Mon, 19 Dec 2011 16:13:54 +0200 (IST)
From: Avi Kivity <avi@redhat.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	qemu-devel@nongnu.org, "Michael S. Tsirkin" <mst@redhat.com>
Date: Mon, 19 Dec 2011 16:13:32 +0200
Message-Id: <1324304024-11220-12-git-send-email-avi@redhat.com>
In-Reply-To: <1324304024-11220-1-git-send-email-avi@redhat.com>
References: <1324304024-11220-1-git-send-email-avi@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
Cc: xen-devel@lists.xensource.com, kvm@vger.kernel.org
Subject: [Xen-devel] [PATCH 11/23] kvm: switch kvm slots to use host virtual
	address instead of ram_addr_t
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This simplifies a later switch to the memory API in slot management.

Signed-off-by: Avi Kivity <avi@redhat.com>
---
 kvm-all.c         |   29 +++++++++++++++++------------
 kvm.h             |    4 ++--
 memory.c          |    6 +++---
 target-i386/kvm.c |    7 +++----
 4 files changed, 25 insertions(+), 21 deletions(-)

diff --git a/kvm-all.c b/kvm-all.c
index 4c466d6..4f58ae8 100644
--- a/kvm-all.c
+++ b/kvm-all.c
@@ -50,7 +50,7 @@
 {
     target_phys_addr_t start_addr;
     ram_addr_t memory_size;
-    ram_addr_t phys_offset;
+    void *ram;
     int slot;
     int flags;
 } KVMSlot;
@@ -146,17 +146,16 @@ struct KVMState
     return found;
 }
 
-int kvm_physical_memory_addr_from_ram(KVMState *s, ram_addr_t ram_addr,
-                                      target_phys_addr_t *phys_addr)
+int kvm_physical_memory_addr_from_host(KVMState *s, void *ram,
+                                       target_phys_addr_t *phys_addr)
 {
     int i;
 
     for (i = 0; i < ARRAY_SIZE(s->slots); i++) {
         KVMSlot *mem = &s->slots[i];
 
-        if (ram_addr >= mem->phys_offset &&
-            ram_addr < mem->phys_offset + mem->memory_size) {
-            *phys_addr = mem->start_addr + (ram_addr - mem->phys_offset);
+        if (ram >= mem->ram && ram < mem->ram + mem->memory_size) {
+            *phys_addr = mem->start_addr + (ram - mem->ram);
             return 1;
         }
     }
@@ -171,7 +170,7 @@ static int kvm_set_user_memory_region(KVMState *s, KVMSlot *slot)
     mem.slot = slot->slot;
     mem.guest_phys_addr = slot->start_addr;
     mem.memory_size = slot->memory_size;
-    mem.userspace_addr = (unsigned long)qemu_safe_ram_ptr(slot->phys_offset);
+    mem.userspace_addr = (unsigned long)slot->ram;
     mem.flags = slot->flags;
     if (s->migration_log) {
         mem.flags |= KVM_MEM_LOG_DIRTY_PAGES;
@@ -527,6 +526,7 @@ static void kvm_set_phys_mem(target_phys_addr_t start_addr, ram_addr_t size,
     ram_addr_t flags = phys_offset & ~TARGET_PAGE_MASK;
     KVMSlot *mem, old;
     int err;
+    void *ram = NULL;
 
     /* kvm works in page size chunks, but the function may be called
        with sub-page size and unaligned start address. */
@@ -536,6 +536,10 @@ static void kvm_set_phys_mem(target_phys_addr_t start_addr, ram_addr_t size,
     /* KVM does not support read-only slots */
     phys_offset &= ~IO_MEM_ROM;
 
+    if ((phys_offset & ~TARGET_PAGE_MASK) == IO_MEM_RAM) {
+        ram = qemu_safe_ram_ptr(phys_offset);
+    }
+
     while (1) {
         mem = kvm_lookup_overlapping_slot(s, start_addr, start_addr + size);
         if (!mem) {
@@ -544,7 +548,7 @@ static void kvm_set_phys_mem(target_phys_addr_t start_addr, ram_addr_t size,
 
         if (flags < IO_MEM_UNASSIGNED && start_addr >= mem->start_addr &&
             (start_addr + size <= mem->start_addr + mem->memory_size) &&
-            (phys_offset - start_addr == mem->phys_offset - mem->start_addr)) {
+            (ram - start_addr == mem->ram - mem->start_addr)) {
             /* The new slot fits into the existing one and comes with
              * identical parameters - update flags and done. */
             kvm_slot_dirty_pages_log_change(mem, log_dirty);
@@ -576,7 +580,7 @@ static void kvm_set_phys_mem(target_phys_addr_t start_addr, ram_addr_t size,
             mem = kvm_alloc_slot(s);
             mem->memory_size = old.memory_size;
             mem->start_addr = old.start_addr;
-            mem->phys_offset = old.phys_offset;
+            mem->ram = old.ram;
             mem->flags = kvm_mem_flags(s, log_dirty);
 
             err = kvm_set_user_memory_region(s, mem);
@@ -588,6 +592,7 @@ static void kvm_set_phys_mem(target_phys_addr_t start_addr, ram_addr_t size,
 
             start_addr += old.memory_size;
             phys_offset += old.memory_size;
+            ram += old.memory_size;
             size -= old.memory_size;
             continue;
         }
@@ -597,7 +602,7 @@ static void kvm_set_phys_mem(target_phys_addr_t start_addr, ram_addr_t size,
             mem = kvm_alloc_slot(s);
             mem->memory_size = start_addr - old.start_addr;
             mem->start_addr = old.start_addr;
-            mem->phys_offset = old.phys_offset;
+            mem->ram = old.ram;
             mem->flags =  kvm_mem_flags(s, log_dirty);
 
             err = kvm_set_user_memory_region(s, mem);
@@ -621,7 +626,7 @@ static void kvm_set_phys_mem(target_phys_addr_t start_addr, ram_addr_t size,
             mem->start_addr = start_addr + size;
             size_delta = mem->start_addr - old.start_addr;
             mem->memory_size = old.memory_size - size_delta;
-            mem->phys_offset = old.phys_offset + size_delta;
+            mem->ram = old.ram + size_delta;
             mem->flags = kvm_mem_flags(s, log_dirty);
 
             err = kvm_set_user_memory_region(s, mem);
@@ -644,7 +649,7 @@ static void kvm_set_phys_mem(target_phys_addr_t start_addr, ram_addr_t size,
     mem = kvm_alloc_slot(s);
     mem->memory_size = size;
     mem->start_addr = start_addr;
-    mem->phys_offset = phys_offset;
+    mem->ram = ram;
     mem->flags = kvm_mem_flags(s, log_dirty);
 
     err = kvm_set_user_memory_region(s, mem);
diff --git a/kvm.h b/kvm.h
index 243b063..c1de81a 100644
--- a/kvm.h
+++ b/kvm.h
@@ -188,8 +188,8 @@ static inline void cpu_synchronize_post_init(CPUState *env)
 
 
 #if !defined(CONFIG_USER_ONLY)
-int kvm_physical_memory_addr_from_ram(KVMState *s, ram_addr_t ram_addr,
-                                      target_phys_addr_t *phys_addr);
+int kvm_physical_memory_addr_from_host(KVMState *s, void *ram_addr,
+                                       target_phys_addr_t *phys_addr);
 #endif
 
 #endif
diff --git a/memory.c b/memory.c
index 2e5ff43..c08186d 100644
--- a/memory.c
+++ b/memory.c
@@ -764,11 +764,11 @@ static void address_space_update_topology_pass(AddressSpace *as,
 
             if (adding) {
                 if (frold->dirty_log_mask && !frnew->dirty_log_mask) {
-                    MEMORY_LISTENER_UPDATE_REGION(frold, as, log_stop);
+                    MEMORY_LISTENER_UPDATE_REGION(frnew, as, log_stop);
                     as->ops->log_stop(as, frnew);
                 } else if (frnew->dirty_log_mask && !frold->dirty_log_mask) {
                     as->ops->log_start(as, frnew);
-                    MEMORY_LISTENER_UPDATE_REGION(frold, as, log_start);
+                    MEMORY_LISTENER_UPDATE_REGION(frnew, as, log_start);
                 }
             }
 
@@ -779,7 +779,7 @@ static void address_space_update_topology_pass(AddressSpace *as,
 
             if (adding) {
                 as->ops->range_add(as, frnew);
-                MEMORY_LISTENER_UPDATE_REGION(frold, as, region_add);
+                MEMORY_LISTENER_UPDATE_REGION(frnew, as, region_add);
             }
 
             ++inew;
diff --git a/target-i386/kvm.c b/target-i386/kvm.c
index 5bfc21f..74d81ef 100644
--- a/target-i386/kvm.c
+++ b/target-i386/kvm.c
@@ -253,8 +253,7 @@ int kvm_arch_on_sigbus_vcpu(CPUState *env, int code, void *addr)
     if ((env->mcg_cap & MCG_SER_P) && addr
         && (code == BUS_MCEERR_AR || code == BUS_MCEERR_AO)) {
         if (qemu_ram_addr_from_host(addr, &ram_addr) ||
-            !kvm_physical_memory_addr_from_ram(env->kvm_state, ram_addr,
-                                               &paddr)) {
+            !kvm_physical_memory_addr_from_host(env->kvm_state, addr, &paddr)) {
             fprintf(stderr, "Hardware memory error for memory used by "
                     "QEMU itself instead of guest system!\n");
             /* Hope we are lucky for AO MCE */
@@ -286,8 +285,8 @@ int kvm_arch_on_sigbus(int code, void *addr)
 
         /* Hope we are lucky for AO MCE */
         if (qemu_ram_addr_from_host(addr, &ram_addr) ||
-            !kvm_physical_memory_addr_from_ram(first_cpu->kvm_state, ram_addr,
-                                               &paddr)) {
+            !kvm_physical_memory_addr_from_host(first_cpu->kvm_state, addr,
+                                                &paddr)) {
             fprintf(stderr, "Hardware memory error for memory used by "
                     "QEMU itself instead of guest system!: %p\n", addr);
             return 0;
-- 
1.7.7.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 14:32:06 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 14:32:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RceFu-0003Ux-67; Mon, 19 Dec 2011 14:31:54 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1RceFt-0003U8-4P
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 14:31:53 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-6.tower-27.messagelabs.com!1324305064!51220361!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21342 invoked from network); 19 Dec 2011 14:31:06 -0000
Received: from unknown (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-6.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Dec 2011 14:31:06 -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
	pBJEThWJ028676
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Mon, 19 Dec 2011 09:29:44 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pBJEThuX028674;
	Mon, 19 Dec 2011 09:29:43 -0500
Date: Mon, 19 Dec 2011 10:29:43 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Michal Suchanek <hramrach@centrum.cz>
Message-ID: <20111219142943.GD27772@andromeda.dapyr.net>
References: <CAOMqctShNFqe47w1orEPMCqvDORy5yxh=Gy33e02fyQYrz4nkw@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAOMqctShNFqe47w1orEPMCqvDORy5yxh=Gy33e02fyQYrz4nkw@mail.gmail.com>
User-Agent: Mutt/1.5.9i
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] UDP checksums broken in Dom0 -> DomU vif transfer
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Dec 19, 2011 at 10:27:36AM +0100, Michal Suchanek wrote:
> Hello,
> 
> when I boot DomU which uses DHCP to configure IPv4 address it does

You didn't say what version of DomU you are running? Is it 3.1?
> never get a lease.
> 
> The packets travel to Dom0 where the dhcp server receives them, sends
> a reply, that travels to DomU where dhclient receives it, says the
> checksum is invalid, and discards it.
> 
> The problem is documented here:
> 
> http://old-list-archives.xen.org/archives/html/xen-users/2006-02/msg00152.html
> http://old-list-archives.xen.org/archives/html/xen-devel/2011-04/msg01235.html
> http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1655
> 
> The fix is to turn off UDP checksum offloading on the vif interface in
> Dom0 as documented in the above mail:
> 
> I edited /etc/xen/scripts/network-bridge,
> adding this command to the end of the op_start() function:
> 
>         add_to_bridge2 ${bridge} ${pdev}
>         do_ifup ${netdev}
> +       # disable ip checksum offloading for veth device
> +       ethtool -K ${netdev} tx off
>     else
>         # old style without ${vdev}
> 
> Note: I am not sure which path is taken through the script, I set the
> parameter manually with ethtool before I found this patch.
> 
> It some solutions suggest to turn off UDP checksum offloading in the
> DomU as well but it does not seem to be necessary since the packets
> would travel to the dhcp server and it would reply to them.
> 
> Some people say this is working for them.
> 
> I suspect this is because some Linux distributions already carry this patch.
> 
> Any reason why this can't be fixed in Xen upstream?

It should be fixed in the kernel and I think it is fixed. Did you have
this problem with a 3.1 or 3.0 kernel?
> 
> This issue is years old and has been discovered, solved, re-discovered
> and re-solved numerous times already.
> 
> Thanks
> 
> Michal
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 14:32:06 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 14:32:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RceFu-0003Ux-67; Mon, 19 Dec 2011 14:31:54 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1RceFt-0003U8-4P
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 14:31:53 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-6.tower-27.messagelabs.com!1324305064!51220361!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21342 invoked from network); 19 Dec 2011 14:31:06 -0000
Received: from unknown (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-6.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Dec 2011 14:31:06 -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
	pBJEThWJ028676
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Mon, 19 Dec 2011 09:29:44 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pBJEThuX028674;
	Mon, 19 Dec 2011 09:29:43 -0500
Date: Mon, 19 Dec 2011 10:29:43 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Michal Suchanek <hramrach@centrum.cz>
Message-ID: <20111219142943.GD27772@andromeda.dapyr.net>
References: <CAOMqctShNFqe47w1orEPMCqvDORy5yxh=Gy33e02fyQYrz4nkw@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAOMqctShNFqe47w1orEPMCqvDORy5yxh=Gy33e02fyQYrz4nkw@mail.gmail.com>
User-Agent: Mutt/1.5.9i
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] UDP checksums broken in Dom0 -> DomU vif transfer
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Dec 19, 2011 at 10:27:36AM +0100, Michal Suchanek wrote:
> Hello,
> 
> when I boot DomU which uses DHCP to configure IPv4 address it does

You didn't say what version of DomU you are running? Is it 3.1?
> never get a lease.
> 
> The packets travel to Dom0 where the dhcp server receives them, sends
> a reply, that travels to DomU where dhclient receives it, says the
> checksum is invalid, and discards it.
> 
> The problem is documented here:
> 
> http://old-list-archives.xen.org/archives/html/xen-users/2006-02/msg00152.html
> http://old-list-archives.xen.org/archives/html/xen-devel/2011-04/msg01235.html
> http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1655
> 
> The fix is to turn off UDP checksum offloading on the vif interface in
> Dom0 as documented in the above mail:
> 
> I edited /etc/xen/scripts/network-bridge,
> adding this command to the end of the op_start() function:
> 
>         add_to_bridge2 ${bridge} ${pdev}
>         do_ifup ${netdev}
> +       # disable ip checksum offloading for veth device
> +       ethtool -K ${netdev} tx off
>     else
>         # old style without ${vdev}
> 
> Note: I am not sure which path is taken through the script, I set the
> parameter manually with ethtool before I found this patch.
> 
> It some solutions suggest to turn off UDP checksum offloading in the
> DomU as well but it does not seem to be necessary since the packets
> would travel to the dhcp server and it would reply to them.
> 
> Some people say this is working for them.
> 
> I suspect this is because some Linux distributions already carry this patch.
> 
> Any reason why this can't be fixed in Xen upstream?

It should be fixed in the kernel and I think it is fixed. Did you have
this problem with a 3.1 or 3.0 kernel?
> 
> This issue is years old and has been discovered, solved, re-discovered
> and re-solved numerous times already.
> 
> Thanks
> 
> Michal
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 14:32:47 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 14:32:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RceGZ-0003bZ-KS; Mon, 19 Dec 2011 14:32:35 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <peter.maydell@linaro.org>) id 1RceGY-0003aV-CD
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 14:32:34 +0000
X-Env-Sender: peter.maydell@linaro.org
X-Msg-Ref: server-5.tower-27.messagelabs.com!1324305107!47327954!1
X-Originating-IP: [209.85.216.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7958 invoked from network); 19 Dec 2011 14:31:48 -0000
Received: from mail-qy0-f171.google.com (HELO mail-qy0-f171.google.com)
	(209.85.216.171)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Dec 2011 14:31:48 -0000
Received: by qcsc20 with SMTP id c20so42095720qcs.30
	for <xen-devel@lists.xensource.com>;
	Mon, 19 Dec 2011 06:32:28 -0800 (PST)
MIME-Version: 1.0
Received: by 10.224.203.202 with SMTP id fj10mr24872113qab.66.1324305148520;
	Mon, 19 Dec 2011 06:32:28 -0800 (PST)
Received: by 10.229.211.4 with HTTP; Mon, 19 Dec 2011 06:32:28 -0800 (PST)
In-Reply-To: <1324304024-11220-13-git-send-email-avi@redhat.com>
References: <1324304024-11220-1-git-send-email-avi@redhat.com>
	<1324304024-11220-13-git-send-email-avi@redhat.com>
Date: Mon, 19 Dec 2011 14:32:28 +0000
Message-ID: <CAFEAcA8b=HNN3t-GsN6J0HoHMp7+ubBiwirb1-j8=x_Qm-bOPA@mail.gmail.com>
From: Peter Maydell <peter.maydell@linaro.org>
To: Avi Kivity <avi@redhat.com>
Cc: xen-devel@lists.xensource.com, "Michael S. Tsirkin" <mst@redhat.com>,
	qemu-devel@nongnu.org, kvm@vger.kernel.org,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH 12/23] fixup: listener fixes
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gMTkgRGVjZW1iZXIgMjAxMSAxNDoxMywgQXZpIEtpdml0eSA8YXZpQHJlZGhhdC5jb20+IHdy
b3RlOgo+IC0tLQoKVGhpcyBpcyBhIHJhdGhlciB1bmluZm9ybWF0aXZlIGNvbW1pdCBtZXNzYWdl
IC0tIHdhcyB0aGlzIHBhdGNoCmludGVuZGVkIHRvIGJlIGluIHRoaXMgc2VyaWVzPwoKLS0gUE1N
Cgo+IMKgbWVtb3J5LmMgfCDCoCDCoDcgKysrKy0tLQo+IMKgMSBmaWxlcyBjaGFuZ2VkLCA0IGlu
c2VydGlvbnMoKyksIDMgZGVsZXRpb25zKC0pCj4KPiBkaWZmIC0tZ2l0IGEvbWVtb3J5LmMgYi9t
ZW1vcnkuYwo+IGluZGV4IGMwODE4NmQuLjJkY2JmODAgMTAwNjQ0Cj4gLS0tIGEvbWVtb3J5LmMK
PiArKysgYi9tZW1vcnkuYwo+IEBAIC03MDgsMTMgKzcwOCwxMyBAQCBzdGF0aWMgdm9pZCBtZW1v
cnlfbGlzdGVuZXJfdXBkYXRlX3JlZ2lvbihGbGF0UmFuZ2UgKmZyLCBBZGRyZXNzU3BhY2UgKmFz
LAo+IMKgIMKgIMKgIMKgIC5hZGRyZXNzX3NwYWNlID0gYXMtPnJvb3QsCj4gwqAgwqAgwqAgwqAg
Lm9mZnNldF93aXRoaW5fcmVnaW9uID0gZnItPm9mZnNldF9pbl9yZWdpb24sCj4gwqAgwqAgwqAg
wqAgLnNpemUgPSBpbnQxMjhfZ2V0NjQoZnItPmFkZHIuc2l6ZSksCj4gLSDCoCDCoCDCoCDCoC5v
ZmZzZXRfd2l0aGluX3JlZ2lvbiA9IGludDEyOF9nZXQ2NChmci0+YWRkci5zdGFydCksCj4gKyDC
oCDCoCDCoCDCoC5vZmZzZXRfd2l0aGluX2FkZHJlc3Nfc3BhY2UgPSBpbnQxMjhfZ2V0NjQoZnIt
PmFkZHIuc3RhcnQpLAo+IMKgIMKgIH07Cj4gwqAgwqAgTWVtb3J5TGlzdGVuZXIgKmxpc3RlbmVy
Owo+Cj4gwqAgwqAgUUxJU1RfRk9SRUFDSChsaXN0ZW5lciwgJm1lbW9yeV9saXN0ZW5lcnMsIGxp
bmspIHsKPiDCoCDCoCDCoCDCoCBMaXN0ZW5lckNhbGxiYWNrICpjYWxsYmFjawo+IC0gwqAgwqAg
wqAgwqAgwqAgwqA9ICooTGlzdGVuZXJDYWxsYmFjayAqKSgodm9pZCAqKWxpc3RlbmVyICsgY2Fs
bGJhY2tfb2Zmc2V0KTsKPiArIMKgIMKgIMKgIMKgIMKgIMKgPSAqKExpc3RlbmVyQ2FsbGJhY2sg
KiopKCh2b2lkICopbGlzdGVuZXIgKyBjYWxsYmFja19vZmZzZXQpOwo+IMKgIMKgIMKgIMKgIGNh
bGxiYWNrKGxpc3RlbmVyLCAmc2VjdGlvbik7Cj4gwqAgwqAgfQo+IMKgfQo+IEBAIC0xMTQ5LDYg
KzExNDksNyBAQCB2b2lkIG1lbW9yeV9yZWdpb25fc3luY19kaXJ0eV9iaXRtYXAoTWVtb3J5UmVn
aW9uICptcikKPgo+IMKgIMKgIEZPUl9FQUNIX0ZMQVRfUkFOR0UoZnIsICZhZGRyZXNzX3NwYWNl
X21lbW9yeS5jdXJyZW50X21hcCkgewo+IMKgIMKgIMKgIMKgIGlmIChmci0+bXIgPT0gbXIpIHsK
PiArIMKgIMKgIMKgIMKgIMKgIMKgTUVNT1JZX0xJU1RFTkVSX1VQREFURV9SRUdJT04oZnIsICZh
ZGRyZXNzX3NwYWNlX21lbW9yeSwgbG9nX3N5bmMpOwo+IMKgIMKgIMKgIMKgIMKgIMKgIGNwdV9w
aHlzaWNhbF9zeW5jX2RpcnR5X2JpdG1hcChpbnQxMjhfZ2V0NjQoZnItPmFkZHIuc3RhcnQpLAo+
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgaW50MTI4X2dldDY0KGFkZHJyYW5nZV9lbmQoZnItPmFkZHIpKSk7Cj4gwqAgwqAg
wqAgwqAgfQo+IEBAIC0xNDY3LDcgKzE0NjgsNyBAQCBzdGF0aWMgdm9pZCBsaXN0ZW5lcl9hZGRf
YWRkcmVzc19zcGFjZShNZW1vcnlMaXN0ZW5lciAqbGlzdGVuZXIsCj4gwqAgwqAgwqAgwqAgwqAg
wqAgLmFkZHJlc3Nfc3BhY2UgPSBhcy0+cm9vdCwKPiDCoCDCoCDCoCDCoCDCoCDCoCAub2Zmc2V0
X3dpdGhpbl9yZWdpb24gPSBmci0+b2Zmc2V0X2luX3JlZ2lvbiwKPiDCoCDCoCDCoCDCoCDCoCDC
oCAuc2l6ZSA9IGludDEyOF9nZXQ2NChmci0+YWRkci5zaXplKSwKPiAtIMKgIMKgIMKgIMKgIMKg
IMKgLm9mZnNldF93aXRoaW5fcmVnaW9uID0gaW50MTI4X2dldDY0KGZyLT5hZGRyLnN0YXJ0KSwK
PiArIMKgIMKgIMKgIMKgIMKgIMKgLm9mZnNldF93aXRoaW5fYWRkcmVzc19zcGFjZSA9IGludDEy
OF9nZXQ2NChmci0+YWRkci5zdGFydCksCj4gwqAgwqAgwqAgwqAgfTsKPiDCoCDCoCDCoCDCoCBs
aXN0ZW5lci0+cmVnaW9uX2FkZChsaXN0ZW5lciwgJnNlY3Rpb24pOwo+IMKgIMKgIH0KPiAtLQo+
IDEuNy43LjEKPgo+CgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29t
Cmh0dHA6Ly9saXN0cy54ZW5zb3VyY2UuY29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Mon Dec 19 14:32:47 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 14:32:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RceGZ-0003bZ-KS; Mon, 19 Dec 2011 14:32:35 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <peter.maydell@linaro.org>) id 1RceGY-0003aV-CD
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 14:32:34 +0000
X-Env-Sender: peter.maydell@linaro.org
X-Msg-Ref: server-5.tower-27.messagelabs.com!1324305107!47327954!1
X-Originating-IP: [209.85.216.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7958 invoked from network); 19 Dec 2011 14:31:48 -0000
Received: from mail-qy0-f171.google.com (HELO mail-qy0-f171.google.com)
	(209.85.216.171)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Dec 2011 14:31:48 -0000
Received: by qcsc20 with SMTP id c20so42095720qcs.30
	for <xen-devel@lists.xensource.com>;
	Mon, 19 Dec 2011 06:32:28 -0800 (PST)
MIME-Version: 1.0
Received: by 10.224.203.202 with SMTP id fj10mr24872113qab.66.1324305148520;
	Mon, 19 Dec 2011 06:32:28 -0800 (PST)
Received: by 10.229.211.4 with HTTP; Mon, 19 Dec 2011 06:32:28 -0800 (PST)
In-Reply-To: <1324304024-11220-13-git-send-email-avi@redhat.com>
References: <1324304024-11220-1-git-send-email-avi@redhat.com>
	<1324304024-11220-13-git-send-email-avi@redhat.com>
Date: Mon, 19 Dec 2011 14:32:28 +0000
Message-ID: <CAFEAcA8b=HNN3t-GsN6J0HoHMp7+ubBiwirb1-j8=x_Qm-bOPA@mail.gmail.com>
From: Peter Maydell <peter.maydell@linaro.org>
To: Avi Kivity <avi@redhat.com>
Cc: xen-devel@lists.xensource.com, "Michael S. Tsirkin" <mst@redhat.com>,
	qemu-devel@nongnu.org, kvm@vger.kernel.org,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH 12/23] fixup: listener fixes
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gMTkgRGVjZW1iZXIgMjAxMSAxNDoxMywgQXZpIEtpdml0eSA8YXZpQHJlZGhhdC5jb20+IHdy
b3RlOgo+IC0tLQoKVGhpcyBpcyBhIHJhdGhlciB1bmluZm9ybWF0aXZlIGNvbW1pdCBtZXNzYWdl
IC0tIHdhcyB0aGlzIHBhdGNoCmludGVuZGVkIHRvIGJlIGluIHRoaXMgc2VyaWVzPwoKLS0gUE1N
Cgo+IMKgbWVtb3J5LmMgfCDCoCDCoDcgKysrKy0tLQo+IMKgMSBmaWxlcyBjaGFuZ2VkLCA0IGlu
c2VydGlvbnMoKyksIDMgZGVsZXRpb25zKC0pCj4KPiBkaWZmIC0tZ2l0IGEvbWVtb3J5LmMgYi9t
ZW1vcnkuYwo+IGluZGV4IGMwODE4NmQuLjJkY2JmODAgMTAwNjQ0Cj4gLS0tIGEvbWVtb3J5LmMK
PiArKysgYi9tZW1vcnkuYwo+IEBAIC03MDgsMTMgKzcwOCwxMyBAQCBzdGF0aWMgdm9pZCBtZW1v
cnlfbGlzdGVuZXJfdXBkYXRlX3JlZ2lvbihGbGF0UmFuZ2UgKmZyLCBBZGRyZXNzU3BhY2UgKmFz
LAo+IMKgIMKgIMKgIMKgIC5hZGRyZXNzX3NwYWNlID0gYXMtPnJvb3QsCj4gwqAgwqAgwqAgwqAg
Lm9mZnNldF93aXRoaW5fcmVnaW9uID0gZnItPm9mZnNldF9pbl9yZWdpb24sCj4gwqAgwqAgwqAg
wqAgLnNpemUgPSBpbnQxMjhfZ2V0NjQoZnItPmFkZHIuc2l6ZSksCj4gLSDCoCDCoCDCoCDCoC5v
ZmZzZXRfd2l0aGluX3JlZ2lvbiA9IGludDEyOF9nZXQ2NChmci0+YWRkci5zdGFydCksCj4gKyDC
oCDCoCDCoCDCoC5vZmZzZXRfd2l0aGluX2FkZHJlc3Nfc3BhY2UgPSBpbnQxMjhfZ2V0NjQoZnIt
PmFkZHIuc3RhcnQpLAo+IMKgIMKgIH07Cj4gwqAgwqAgTWVtb3J5TGlzdGVuZXIgKmxpc3RlbmVy
Owo+Cj4gwqAgwqAgUUxJU1RfRk9SRUFDSChsaXN0ZW5lciwgJm1lbW9yeV9saXN0ZW5lcnMsIGxp
bmspIHsKPiDCoCDCoCDCoCDCoCBMaXN0ZW5lckNhbGxiYWNrICpjYWxsYmFjawo+IC0gwqAgwqAg
wqAgwqAgwqAgwqA9ICooTGlzdGVuZXJDYWxsYmFjayAqKSgodm9pZCAqKWxpc3RlbmVyICsgY2Fs
bGJhY2tfb2Zmc2V0KTsKPiArIMKgIMKgIMKgIMKgIMKgIMKgPSAqKExpc3RlbmVyQ2FsbGJhY2sg
KiopKCh2b2lkICopbGlzdGVuZXIgKyBjYWxsYmFja19vZmZzZXQpOwo+IMKgIMKgIMKgIMKgIGNh
bGxiYWNrKGxpc3RlbmVyLCAmc2VjdGlvbik7Cj4gwqAgwqAgfQo+IMKgfQo+IEBAIC0xMTQ5LDYg
KzExNDksNyBAQCB2b2lkIG1lbW9yeV9yZWdpb25fc3luY19kaXJ0eV9iaXRtYXAoTWVtb3J5UmVn
aW9uICptcikKPgo+IMKgIMKgIEZPUl9FQUNIX0ZMQVRfUkFOR0UoZnIsICZhZGRyZXNzX3NwYWNl
X21lbW9yeS5jdXJyZW50X21hcCkgewo+IMKgIMKgIMKgIMKgIGlmIChmci0+bXIgPT0gbXIpIHsK
PiArIMKgIMKgIMKgIMKgIMKgIMKgTUVNT1JZX0xJU1RFTkVSX1VQREFURV9SRUdJT04oZnIsICZh
ZGRyZXNzX3NwYWNlX21lbW9yeSwgbG9nX3N5bmMpOwo+IMKgIMKgIMKgIMKgIMKgIMKgIGNwdV9w
aHlzaWNhbF9zeW5jX2RpcnR5X2JpdG1hcChpbnQxMjhfZ2V0NjQoZnItPmFkZHIuc3RhcnQpLAo+
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgaW50MTI4X2dldDY0KGFkZHJyYW5nZV9lbmQoZnItPmFkZHIpKSk7Cj4gwqAgwqAg
wqAgwqAgfQo+IEBAIC0xNDY3LDcgKzE0NjgsNyBAQCBzdGF0aWMgdm9pZCBsaXN0ZW5lcl9hZGRf
YWRkcmVzc19zcGFjZShNZW1vcnlMaXN0ZW5lciAqbGlzdGVuZXIsCj4gwqAgwqAgwqAgwqAgwqAg
wqAgLmFkZHJlc3Nfc3BhY2UgPSBhcy0+cm9vdCwKPiDCoCDCoCDCoCDCoCDCoCDCoCAub2Zmc2V0
X3dpdGhpbl9yZWdpb24gPSBmci0+b2Zmc2V0X2luX3JlZ2lvbiwKPiDCoCDCoCDCoCDCoCDCoCDC
oCAuc2l6ZSA9IGludDEyOF9nZXQ2NChmci0+YWRkci5zaXplKSwKPiAtIMKgIMKgIMKgIMKgIMKg
IMKgLm9mZnNldF93aXRoaW5fcmVnaW9uID0gaW50MTI4X2dldDY0KGZyLT5hZGRyLnN0YXJ0KSwK
PiArIMKgIMKgIMKgIMKgIMKgIMKgLm9mZnNldF93aXRoaW5fYWRkcmVzc19zcGFjZSA9IGludDEy
OF9nZXQ2NChmci0+YWRkci5zdGFydCksCj4gwqAgwqAgwqAgwqAgfTsKPiDCoCDCoCDCoCDCoCBs
aXN0ZW5lci0+cmVnaW9uX2FkZChsaXN0ZW5lciwgJnNlY3Rpb24pOwo+IMKgIMKgIH0KPiAtLQo+
IDEuNy43LjEKPgo+CgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29t
Cmh0dHA6Ly9saXN0cy54ZW5zb3VyY2UuY29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Mon Dec 19 14:43:26 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 14:43:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RceQt-00042y-HD; Mon, 19 Dec 2011 14:43:15 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RceQs-00042q-Jn
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 14:43:14 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1324305786!8806662!1
X-Originating-IP: [209.85.210.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20120 invoked from network); 19 Dec 2011 14:43:08 -0000
Received: from mail-pz0-f43.google.com (HELO mail-pz0-f43.google.com)
	(209.85.210.43)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Dec 2011 14:43:08 -0000
Received: by daec6 with SMTP id c6so25491304dae.30
	for <xen-devel@lists.xensource.com>;
	Mon, 19 Dec 2011 06:43:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=b4dald0prh1DPa56OTW/OdQDn42LIAnb+ZKAYEqBaBE=;
	b=bYYChJW2CYDqu+DkTEuR+D3S3bZZslhs0Ucu8Iq3MbKmu9RcnkOu36P1XrF5McJfOJ
	9bYxC3kUienVjTC1mIcLGxfyrWZAZge35opyRt6rkNwugj77TtJKd/20iHfj7upw7zKW
	TJnenm1JBsOKXX8rWzne8vbKLP3tGhlabClug=
MIME-Version: 1.0
Received: by 10.68.212.68 with SMTP id ni4mr39096677pbc.44.1324305786453; Mon,
	19 Dec 2011 06:43:06 -0800 (PST)
Received: by 10.142.47.17 with HTTP; Mon, 19 Dec 2011 06:43:06 -0800 (PST)
In-Reply-To: <1324302182.9236.51.camel@zakaz.uk.xensource.com>
References: <patchbomb.1324212500@alpine.localdomain>
	<c0d5aa328f1ab24aad58.1324212503@alpine.localdomain>
	<CA+T2pCE_L0Gfyb0xu4=bd-yCAz=+Z_4Ugyd-EoO4m=+jz5MPGA@mail.gmail.com>
	<CAPLaKK5gYZ+KDsJW4+FSkP=nqDJmaO3W72pfkbg8m25fYu+_1Q@mail.gmail.com>
	<1324301203.9236.40.camel@zakaz.uk.xensource.com>
	<CAPLaKK6NhoXTiaFWb9aTcuapaqtNVcKo==7=xXP8wf5N66kFUw@mail.gmail.com>
	<1324302182.9236.51.camel@zakaz.uk.xensource.com>
Date: Mon, 19 Dec 2011 15:43:06 +0100
X-Google-Sender-Auth: RttlY0SI6kcKx3AvIwldZizZKGA
Message-ID: <CAPLaKK4xpN5Ro6medFjwBmg9zjs2pYHThmgP=NvdoJt+N=t1rA@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: William Pitcock <nenolod@dereferenced.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 3 of 5] blktap2: fix vhd compilation under
	uclibc
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

MjAxMS8xMi8xOSBJYW4gQ2FtcGJlbGwgPElhbi5DYW1wYmVsbEBjaXRyaXguY29tPjoKPiBPbiBN
b24sIDIwMTEtMTItMTkgYXQgMTM6MzAgKzAwMDAsIFJvZ2VyIFBhdSBNb25uw6kgd3JvdGU6Cj4+
IDIwMTEvMTIvMTkgSWFuIENhbXBiZWxsIDxJYW4uQ2FtcGJlbGxAY2l0cml4LmNvbT46Cj4+ID4g
T24gTW9uLCAyMDExLTEyLTE5IGF0IDEyOjMwICswMDAwLCBSb2dlciBQYXUgTW9ubsOpIHdyb3Rl
Ogo+PiA+PiBXaGF0J3Mgc3RyYW5nZSBpcyB0aGF0IGxpYnZoZCAod2hpY2ggdXNlcyBpY29udikg
Y29tcGlsZXMgYW5kIGxpbmtzCj4+ID4+IGZpbmUsCj4+ID4KPj4gPiBsaWJ2aGQgbmVlZHMgLWxp
Y29udiBidXQgaXQgd2lsbCBjb21waWxlIGFuZCBsaW5rIHdpdGhvdXQgaXQgZmluZS4gSXQgaXMK
Pj4gPiBvbmx5IHdoZW4geW91IHRyeSB0byBsaW5rIHNvbWV0aGluZyBhZ2FpbnN0IHRoYXQgbGli
cmFyeSB0aGF0IHRoZQo+PiA+IHByb2JsZW0gd2lsbCBtYW5pZmVzdCBpdHNlbGYuCj4+ID4KPj4g
Pj4gwqBidXQgdmhkLXV0aWwgdGhhdCB1c2VzIGxpYnZoZCBjb21wbGFpbnMgYWJvdXQgdW5kZWZp
bmVkCj4+ID4+IHJlZmVyZW5jZXMgdG8gaWNvbnYsIHdoZW4gdmhkLXV0aWwgZG9lc24ndCB1c2Ug
aWNvbnYuCj4+ID4KPj4gPiBSaWdodC4KPj4gPgo+PiA+IElhbi4KPj4KPj4gSSBoYXZlIGEgZXhw
cmVzc2lvbiB0aGF0IGNoZWNrcyBmb3IgbGliaWNvbnYsIGJ1dCBpdCB3aWxsIG9ubHkgZGV0ZWN0
Cj4+IGl0IGlmIGxkY29uZmlnIGlzIHByZXNlbnQsIGlmIHRoZSBzeXN0ZW0gZG9lc24ndCBoYXZl
IGxkY29uZmlnCj4+IChOZXRCU0QpLCBsaWJpY29udiB3aWxsIG5vdCBiZSBkZXRlY3RlZCBldmVu
IGlmIGl0IGlzIHByZXNlbnQ6Cj4+Cj4+IHdoaWNoIGxkY29uZmlnIDI+JjEgPi9kZXYvbnVsbCAm
JiAobGRjb25maWcgLXAgfCBncmVwIC1xIGxpYmljb252ICYmCj4+IGVjaG8gJ3knIHx8IGVjaG8g
J24nKSB8fCBlY2hvICduJwo+Cj4gVXJnaCwgc3VyZWx5IHRoZXJlJ3MgYSBiZXR0ZXIgd2F5IQo+
Cj4gUGVyaGFwcyBncmVwcGluZyBmb3IgTElCSUNPTlZfUExVRyBvciBsaWJpY29udl9vcGVuIG9y
IHNvbWV0aGluZyB1bmlxdWUKPiBpbiBpY29udi5oIHdvdWxkIGJlIGJldHRlcj8KCmdyZXAgLXEg
TElCSUNPTlZfUExVRyAvdXNyL2luY2x1ZGUvaWNvbnYuaCAmJiBlY2hvICd5JyB8fCBlY2hvICdu
JwoKRG9lcyB0aGUgam9iLCBidXQgSSBkb24ndCBrbm93IGhvdyByZWxpYWJsZSBpdCBpcyB0byBy
ZWx5IG9uCkxJQklDT05WX1BMVUcuIFRlc3RlZCBvbiBOZXRCU0QsIERlYmlhbiA2LjAuMyBhbmQg
QWxwaW5lIDIuMy4yIHdpdGgKc3VjY2Vzcy4KCj4gQlRXIGRpZCB5b3UgdHJ5IGRlZmluaW5nIExJ
QklDT05WX1BMVUc/CgpMSUJJQ09OVl9QTFVHIHNob3VsZCBub3QgYmUgZGVmaW5lZCwgYmVjYXVz
ZSB0aGF0IHByZXZlbnRzIGljb252IGZyb20KZGVmaW5pbmcgaWNvbnZfb3BlbiwgaWNvbnZfY2xv
c2UuLi4gYXMgYWxpYXMgdG8gbGliaWNvbnZfb3BlbiwKbGliaWNvbnZfY2xvc2UuLi4gYW5kIGxp
YnZoZCB1c2VzIHRoaXMgZnVuY3Rpb25zLgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMu
eGVuc291cmNlLmNvbQpodHRwOi8vbGlzdHMueGVuc291cmNlLmNvbS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Mon Dec 19 14:43:26 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 14:43:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RceQt-00042y-HD; Mon, 19 Dec 2011 14:43:15 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RceQs-00042q-Jn
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 14:43:14 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1324305786!8806662!1
X-Originating-IP: [209.85.210.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20120 invoked from network); 19 Dec 2011 14:43:08 -0000
Received: from mail-pz0-f43.google.com (HELO mail-pz0-f43.google.com)
	(209.85.210.43)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Dec 2011 14:43:08 -0000
Received: by daec6 with SMTP id c6so25491304dae.30
	for <xen-devel@lists.xensource.com>;
	Mon, 19 Dec 2011 06:43:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=b4dald0prh1DPa56OTW/OdQDn42LIAnb+ZKAYEqBaBE=;
	b=bYYChJW2CYDqu+DkTEuR+D3S3bZZslhs0Ucu8Iq3MbKmu9RcnkOu36P1XrF5McJfOJ
	9bYxC3kUienVjTC1mIcLGxfyrWZAZge35opyRt6rkNwugj77TtJKd/20iHfj7upw7zKW
	TJnenm1JBsOKXX8rWzne8vbKLP3tGhlabClug=
MIME-Version: 1.0
Received: by 10.68.212.68 with SMTP id ni4mr39096677pbc.44.1324305786453; Mon,
	19 Dec 2011 06:43:06 -0800 (PST)
Received: by 10.142.47.17 with HTTP; Mon, 19 Dec 2011 06:43:06 -0800 (PST)
In-Reply-To: <1324302182.9236.51.camel@zakaz.uk.xensource.com>
References: <patchbomb.1324212500@alpine.localdomain>
	<c0d5aa328f1ab24aad58.1324212503@alpine.localdomain>
	<CA+T2pCE_L0Gfyb0xu4=bd-yCAz=+Z_4Ugyd-EoO4m=+jz5MPGA@mail.gmail.com>
	<CAPLaKK5gYZ+KDsJW4+FSkP=nqDJmaO3W72pfkbg8m25fYu+_1Q@mail.gmail.com>
	<1324301203.9236.40.camel@zakaz.uk.xensource.com>
	<CAPLaKK6NhoXTiaFWb9aTcuapaqtNVcKo==7=xXP8wf5N66kFUw@mail.gmail.com>
	<1324302182.9236.51.camel@zakaz.uk.xensource.com>
Date: Mon, 19 Dec 2011 15:43:06 +0100
X-Google-Sender-Auth: RttlY0SI6kcKx3AvIwldZizZKGA
Message-ID: <CAPLaKK4xpN5Ro6medFjwBmg9zjs2pYHThmgP=NvdoJt+N=t1rA@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: William Pitcock <nenolod@dereferenced.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 3 of 5] blktap2: fix vhd compilation under
	uclibc
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

MjAxMS8xMi8xOSBJYW4gQ2FtcGJlbGwgPElhbi5DYW1wYmVsbEBjaXRyaXguY29tPjoKPiBPbiBN
b24sIDIwMTEtMTItMTkgYXQgMTM6MzAgKzAwMDAsIFJvZ2VyIFBhdSBNb25uw6kgd3JvdGU6Cj4+
IDIwMTEvMTIvMTkgSWFuIENhbXBiZWxsIDxJYW4uQ2FtcGJlbGxAY2l0cml4LmNvbT46Cj4+ID4g
T24gTW9uLCAyMDExLTEyLTE5IGF0IDEyOjMwICswMDAwLCBSb2dlciBQYXUgTW9ubsOpIHdyb3Rl
Ogo+PiA+PiBXaGF0J3Mgc3RyYW5nZSBpcyB0aGF0IGxpYnZoZCAod2hpY2ggdXNlcyBpY29udikg
Y29tcGlsZXMgYW5kIGxpbmtzCj4+ID4+IGZpbmUsCj4+ID4KPj4gPiBsaWJ2aGQgbmVlZHMgLWxp
Y29udiBidXQgaXQgd2lsbCBjb21waWxlIGFuZCBsaW5rIHdpdGhvdXQgaXQgZmluZS4gSXQgaXMK
Pj4gPiBvbmx5IHdoZW4geW91IHRyeSB0byBsaW5rIHNvbWV0aGluZyBhZ2FpbnN0IHRoYXQgbGli
cmFyeSB0aGF0IHRoZQo+PiA+IHByb2JsZW0gd2lsbCBtYW5pZmVzdCBpdHNlbGYuCj4+ID4KPj4g
Pj4gwqBidXQgdmhkLXV0aWwgdGhhdCB1c2VzIGxpYnZoZCBjb21wbGFpbnMgYWJvdXQgdW5kZWZp
bmVkCj4+ID4+IHJlZmVyZW5jZXMgdG8gaWNvbnYsIHdoZW4gdmhkLXV0aWwgZG9lc24ndCB1c2Ug
aWNvbnYuCj4+ID4KPj4gPiBSaWdodC4KPj4gPgo+PiA+IElhbi4KPj4KPj4gSSBoYXZlIGEgZXhw
cmVzc2lvbiB0aGF0IGNoZWNrcyBmb3IgbGliaWNvbnYsIGJ1dCBpdCB3aWxsIG9ubHkgZGV0ZWN0
Cj4+IGl0IGlmIGxkY29uZmlnIGlzIHByZXNlbnQsIGlmIHRoZSBzeXN0ZW0gZG9lc24ndCBoYXZl
IGxkY29uZmlnCj4+IChOZXRCU0QpLCBsaWJpY29udiB3aWxsIG5vdCBiZSBkZXRlY3RlZCBldmVu
IGlmIGl0IGlzIHByZXNlbnQ6Cj4+Cj4+IHdoaWNoIGxkY29uZmlnIDI+JjEgPi9kZXYvbnVsbCAm
JiAobGRjb25maWcgLXAgfCBncmVwIC1xIGxpYmljb252ICYmCj4+IGVjaG8gJ3knIHx8IGVjaG8g
J24nKSB8fCBlY2hvICduJwo+Cj4gVXJnaCwgc3VyZWx5IHRoZXJlJ3MgYSBiZXR0ZXIgd2F5IQo+
Cj4gUGVyaGFwcyBncmVwcGluZyBmb3IgTElCSUNPTlZfUExVRyBvciBsaWJpY29udl9vcGVuIG9y
IHNvbWV0aGluZyB1bmlxdWUKPiBpbiBpY29udi5oIHdvdWxkIGJlIGJldHRlcj8KCmdyZXAgLXEg
TElCSUNPTlZfUExVRyAvdXNyL2luY2x1ZGUvaWNvbnYuaCAmJiBlY2hvICd5JyB8fCBlY2hvICdu
JwoKRG9lcyB0aGUgam9iLCBidXQgSSBkb24ndCBrbm93IGhvdyByZWxpYWJsZSBpdCBpcyB0byBy
ZWx5IG9uCkxJQklDT05WX1BMVUcuIFRlc3RlZCBvbiBOZXRCU0QsIERlYmlhbiA2LjAuMyBhbmQg
QWxwaW5lIDIuMy4yIHdpdGgKc3VjY2Vzcy4KCj4gQlRXIGRpZCB5b3UgdHJ5IGRlZmluaW5nIExJ
QklDT05WX1BMVUc/CgpMSUJJQ09OVl9QTFVHIHNob3VsZCBub3QgYmUgZGVmaW5lZCwgYmVjYXVz
ZSB0aGF0IHByZXZlbnRzIGljb252IGZyb20KZGVmaW5pbmcgaWNvbnZfb3BlbiwgaWNvbnZfY2xv
c2UuLi4gYXMgYWxpYXMgdG8gbGliaWNvbnZfb3BlbiwKbGliaWNvbnZfY2xvc2UuLi4gYW5kIGxp
YnZoZCB1c2VzIHRoaXMgZnVuY3Rpb25zLgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMu
eGVuc291cmNlLmNvbQpodHRwOi8vbGlzdHMueGVuc291cmNlLmNvbS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Mon Dec 19 14:50:35 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 14:50:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RceXl-0004Zy-Ds; Mon, 19 Dec 2011 14:50:21 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony@codemonkey.ws>) id 1RceXj-0004Zt-PK
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 14:50:20 +0000
X-Env-Sender: anthony@codemonkey.ws
X-Msg-Ref: server-6.tower-216.messagelabs.com!1324306212!8014837!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6912 invoked from network); 19 Dec 2011 14:50:13 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Dec 2011 14:50:13 -0000
Received: by iagw33 with SMTP id w33so32342032iag.30
	for <xen-devel@lists.xensource.com>;
	Mon, 19 Dec 2011 06:50:12 -0800 (PST)
Received: by 10.50.183.133 with SMTP id em5mr27171833igc.73.1324306211951;
	Mon, 19 Dec 2011 06:50:11 -0800 (PST)
Received: from [192.168.0.103] (cpe-70-123-132-139.austin.res.rr.com.
	[70.123.132.139])
	by mx.google.com with ESMTPS id mb4sm31941886igc.1.2011.12.19.06.50.08
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 19 Dec 2011 06:50:10 -0800 (PST)
Message-ID: <4EEF4F1E.9080104@codemonkey.ws>
Date: Mon, 19 Dec 2011 08:50:06 -0600
From: Anthony Liguori <anthony@codemonkey.ws>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.23) Gecko/20110922 Lightning/1.0b2 Thunderbird/3.1.15
MIME-Version: 1.0
To: Avi Kivity <avi@redhat.com>
References: <1324304024-11220-1-git-send-email-avi@redhat.com>
	<1324304024-11220-2-git-send-email-avi@redhat.com>
In-Reply-To: <1324304024-11220-2-git-send-email-avi@redhat.com>
Cc: xen-devel@lists.xensource.com, "Michael S. Tsirkin" <mst@redhat.com>,
	qemu-devel@nongnu.org, kvm@vger.kernel.org,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH 01/23] memory: introduce
	memory_region_find()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 12/19/2011 08:13 AM, Avi Kivity wrote:
> Given an address space (represented by the top-level memory region),
> returns the memory region that maps a given range.  Useful for implementing
> DMA.
>
> The implementation is a simplistic binary search.  Once we have a tree
> representation this can be optimized.
>
> Signed-off-by: Avi Kivity<avi@redhat.com>
> ---
>   memory.c |   62 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>   memory.h |   32 ++++++++++++++++++++++++++++++++
>   2 files changed, 94 insertions(+), 0 deletions(-)
>
> diff --git a/memory.c b/memory.c
> index cbd6988..d8b7c27 100644
> --- a/memory.c
> +++ b/memory.c
> @@ -514,6 +514,20 @@ static void as_io_ioeventfd_del(AddressSpace *as, MemoryRegionIoeventfd *fd)
>       .ops =&address_space_ops_io,
>   };
>
> +static AddressSpace *memory_region_to_address_space(MemoryRegion *mr)
> +{
> +    while (mr->parent) {
> +        mr = mr->parent;
> +    }
> +    if (mr == address_space_memory.root) {
> +        return&address_space_memory;
> +    }
> +    if (mr == address_space_io.root) {
> +        return&address_space_io;
> +    }
> +    abort();
> +}
> +
>   /* Render a memory region into the global view.  Ranges in @view obscure
>    * ranges in @mr.
>    */
> @@ -1309,6 +1323,54 @@ void memory_region_del_subregion(MemoryRegion *mr,
>       memory_region_update_topology();
>   }
>
> +static int cmp_flatrange_addr(const void *_addr, const void *_fr)
> +{
> +    const AddrRange *addr = _addr;
> +    const FlatRange *fr = _fr;

Please don't prefix with an underscore.

> +
> +    if (int128_le(addrrange_end(*addr), fr->addr.start)) {
> +        return -1;
> +    } else if (int128_ge(addr->start, addrrange_end(fr->addr))) {
> +        return 1;
> +    }
> +    return 0;
> +}
> +
> +static FlatRange *address_space_lookup(AddressSpace *as, AddrRange addr)
> +{
> +    return bsearch(&addr, as->current_map.ranges, as->current_map.nr,
> +                   sizeof(FlatRange), cmp_flatrange_addr);
> +}
> +
> +MemoryRegionSection memory_region_find(MemoryRegion *address_space,
> +                                       target_phys_addr_t addr, uint64_t size)
> +{
> +    AddressSpace *as = memory_region_to_address_space(address_space);
> +    AddrRange range = addrrange_make(int128_make64(addr),
> +                                     int128_make64(size));
> +    FlatRange *fr = address_space_lookup(as, range);
> +    MemoryRegionSection ret = { .mr = NULL };
> +
> +    if (!fr) {
> +        return ret;
> +    }
> +
> +    while (fr>  as->current_map.ranges
> +&&  addrrange_intersects(fr[-1].addr, range)) {
> +        --fr;
> +    }
> +
> +    ret.mr = fr->mr;
> +    range = addrrange_intersection(range, fr->addr);
> +    ret.offset_within_region = fr->offset_in_region;
> +    ret.offset_within_region += int128_get64(int128_sub(range.start,
> +                                                        fr->addr.start));
> +    ret.size = int128_get64(range.size);
> +    ret.offset_within_address_space = int128_get64(range.start);
> +    return ret;
> +}
> +
> +
>   void set_system_memory_map(MemoryRegion *mr)
>   {
>       address_space_memory.root = mr;
> diff --git a/memory.h b/memory.h
> index beae127..1d5c414 100644
> --- a/memory.h
> +++ b/memory.h
> @@ -146,6 +146,24 @@ struct MemoryRegionPortio {
>
>   #define PORTIO_END_OF_LIST() { }
>
> +typedef struct MemoryRegionSection MemoryRegionSection;
> +
> +/**
> + * MemoryRegionSection: describes a fragment of a #MemoryRegion
> + *
> + * @mr: the region, or %NULL if empty
> + * @offset_within_region: the beginning of the section, relative to @mr's start
> + * @size: the size of the section; will not exceed @mr's boundaries
> + * @offset_within_address_space: the address of the first byte of the section
> + *     relative to the region's address space
> + */
> +struct MemoryRegionSection {
> +    MemoryRegion *mr;
> +    target_phys_addr_t offset_within_region;
> +    uint64_t size;
> +    target_phys_addr_t offset_within_address_space;
> +};
> +
>   /**
>    * memory_region_init: Initialize a memory region
>    *
> @@ -502,6 +520,20 @@ void memory_region_del_subregion(MemoryRegion *mr,
>                                    MemoryRegion *subregion);
>
>   /**
> + * memory_region_find: locate a MemoryRegion in an address space
> + *
> + * Locates the first #MemoryRegion within an address space given by
> + * @address_space that overlaps the range given by @addr and @size.
> + *
> + * @address_space: a top-level (i.e. parentless) region that contains
> + *       the region to be found
> + * @addr: start of the area within @address_space to be searched
> + * @size: size of the area to be searched
> + */
> +MemoryRegionSection memory_region_find(MemoryRegion *address_space,
> +                                       target_phys_addr_t addr, uint64_t size);

Returning structs by value is a bit unexpected.

Otherwise, the patch looks good.

Regards,

Anthony Liguori

> +
> +/**
>    * memory_region_transaction_begin: Start a transaction.
>    *
>    * During a transaction, changes will be accumulated and made visible


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 14:50:35 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 14:50:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RceXl-0004Zy-Ds; Mon, 19 Dec 2011 14:50:21 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony@codemonkey.ws>) id 1RceXj-0004Zt-PK
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 14:50:20 +0000
X-Env-Sender: anthony@codemonkey.ws
X-Msg-Ref: server-6.tower-216.messagelabs.com!1324306212!8014837!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6912 invoked from network); 19 Dec 2011 14:50:13 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Dec 2011 14:50:13 -0000
Received: by iagw33 with SMTP id w33so32342032iag.30
	for <xen-devel@lists.xensource.com>;
	Mon, 19 Dec 2011 06:50:12 -0800 (PST)
Received: by 10.50.183.133 with SMTP id em5mr27171833igc.73.1324306211951;
	Mon, 19 Dec 2011 06:50:11 -0800 (PST)
Received: from [192.168.0.103] (cpe-70-123-132-139.austin.res.rr.com.
	[70.123.132.139])
	by mx.google.com with ESMTPS id mb4sm31941886igc.1.2011.12.19.06.50.08
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 19 Dec 2011 06:50:10 -0800 (PST)
Message-ID: <4EEF4F1E.9080104@codemonkey.ws>
Date: Mon, 19 Dec 2011 08:50:06 -0600
From: Anthony Liguori <anthony@codemonkey.ws>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.23) Gecko/20110922 Lightning/1.0b2 Thunderbird/3.1.15
MIME-Version: 1.0
To: Avi Kivity <avi@redhat.com>
References: <1324304024-11220-1-git-send-email-avi@redhat.com>
	<1324304024-11220-2-git-send-email-avi@redhat.com>
In-Reply-To: <1324304024-11220-2-git-send-email-avi@redhat.com>
Cc: xen-devel@lists.xensource.com, "Michael S. Tsirkin" <mst@redhat.com>,
	qemu-devel@nongnu.org, kvm@vger.kernel.org,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH 01/23] memory: introduce
	memory_region_find()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 12/19/2011 08:13 AM, Avi Kivity wrote:
> Given an address space (represented by the top-level memory region),
> returns the memory region that maps a given range.  Useful for implementing
> DMA.
>
> The implementation is a simplistic binary search.  Once we have a tree
> representation this can be optimized.
>
> Signed-off-by: Avi Kivity<avi@redhat.com>
> ---
>   memory.c |   62 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>   memory.h |   32 ++++++++++++++++++++++++++++++++
>   2 files changed, 94 insertions(+), 0 deletions(-)
>
> diff --git a/memory.c b/memory.c
> index cbd6988..d8b7c27 100644
> --- a/memory.c
> +++ b/memory.c
> @@ -514,6 +514,20 @@ static void as_io_ioeventfd_del(AddressSpace *as, MemoryRegionIoeventfd *fd)
>       .ops =&address_space_ops_io,
>   };
>
> +static AddressSpace *memory_region_to_address_space(MemoryRegion *mr)
> +{
> +    while (mr->parent) {
> +        mr = mr->parent;
> +    }
> +    if (mr == address_space_memory.root) {
> +        return&address_space_memory;
> +    }
> +    if (mr == address_space_io.root) {
> +        return&address_space_io;
> +    }
> +    abort();
> +}
> +
>   /* Render a memory region into the global view.  Ranges in @view obscure
>    * ranges in @mr.
>    */
> @@ -1309,6 +1323,54 @@ void memory_region_del_subregion(MemoryRegion *mr,
>       memory_region_update_topology();
>   }
>
> +static int cmp_flatrange_addr(const void *_addr, const void *_fr)
> +{
> +    const AddrRange *addr = _addr;
> +    const FlatRange *fr = _fr;

Please don't prefix with an underscore.

> +
> +    if (int128_le(addrrange_end(*addr), fr->addr.start)) {
> +        return -1;
> +    } else if (int128_ge(addr->start, addrrange_end(fr->addr))) {
> +        return 1;
> +    }
> +    return 0;
> +}
> +
> +static FlatRange *address_space_lookup(AddressSpace *as, AddrRange addr)
> +{
> +    return bsearch(&addr, as->current_map.ranges, as->current_map.nr,
> +                   sizeof(FlatRange), cmp_flatrange_addr);
> +}
> +
> +MemoryRegionSection memory_region_find(MemoryRegion *address_space,
> +                                       target_phys_addr_t addr, uint64_t size)
> +{
> +    AddressSpace *as = memory_region_to_address_space(address_space);
> +    AddrRange range = addrrange_make(int128_make64(addr),
> +                                     int128_make64(size));
> +    FlatRange *fr = address_space_lookup(as, range);
> +    MemoryRegionSection ret = { .mr = NULL };
> +
> +    if (!fr) {
> +        return ret;
> +    }
> +
> +    while (fr>  as->current_map.ranges
> +&&  addrrange_intersects(fr[-1].addr, range)) {
> +        --fr;
> +    }
> +
> +    ret.mr = fr->mr;
> +    range = addrrange_intersection(range, fr->addr);
> +    ret.offset_within_region = fr->offset_in_region;
> +    ret.offset_within_region += int128_get64(int128_sub(range.start,
> +                                                        fr->addr.start));
> +    ret.size = int128_get64(range.size);
> +    ret.offset_within_address_space = int128_get64(range.start);
> +    return ret;
> +}
> +
> +
>   void set_system_memory_map(MemoryRegion *mr)
>   {
>       address_space_memory.root = mr;
> diff --git a/memory.h b/memory.h
> index beae127..1d5c414 100644
> --- a/memory.h
> +++ b/memory.h
> @@ -146,6 +146,24 @@ struct MemoryRegionPortio {
>
>   #define PORTIO_END_OF_LIST() { }
>
> +typedef struct MemoryRegionSection MemoryRegionSection;
> +
> +/**
> + * MemoryRegionSection: describes a fragment of a #MemoryRegion
> + *
> + * @mr: the region, or %NULL if empty
> + * @offset_within_region: the beginning of the section, relative to @mr's start
> + * @size: the size of the section; will not exceed @mr's boundaries
> + * @offset_within_address_space: the address of the first byte of the section
> + *     relative to the region's address space
> + */
> +struct MemoryRegionSection {
> +    MemoryRegion *mr;
> +    target_phys_addr_t offset_within_region;
> +    uint64_t size;
> +    target_phys_addr_t offset_within_address_space;
> +};
> +
>   /**
>    * memory_region_init: Initialize a memory region
>    *
> @@ -502,6 +520,20 @@ void memory_region_del_subregion(MemoryRegion *mr,
>                                    MemoryRegion *subregion);
>
>   /**
> + * memory_region_find: locate a MemoryRegion in an address space
> + *
> + * Locates the first #MemoryRegion within an address space given by
> + * @address_space that overlaps the range given by @addr and @size.
> + *
> + * @address_space: a top-level (i.e. parentless) region that contains
> + *       the region to be found
> + * @addr: start of the area within @address_space to be searched
> + * @size: size of the area to be searched
> + */
> +MemoryRegionSection memory_region_find(MemoryRegion *address_space,
> +                                       target_phys_addr_t addr, uint64_t size);

Returning structs by value is a bit unexpected.

Otherwise, the patch looks good.

Regards,

Anthony Liguori

> +
> +/**
>    * memory_region_transaction_begin: Start a transaction.
>    *
>    * During a transaction, changes will be accumulated and made visible


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 14:54:55 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 14:54:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rcec0-0004kg-4E; Mon, 19 Dec 2011 14:54:44 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony@codemonkey.ws>) id 1Rceby-0004kN-6T
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 14:54:42 +0000
X-Env-Sender: anthony@codemonkey.ws
X-Msg-Ref: server-5.tower-182.messagelabs.com!1324306474!7881705!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28200 invoked from network); 19 Dec 2011 14:54:36 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Dec 2011 14:54:36 -0000
Received: by iagw33 with SMTP id w33so32354921iag.30
	for <xen-devel@lists.xensource.com>;
	Mon, 19 Dec 2011 06:54:34 -0800 (PST)
Received: by 10.50.236.40 with SMTP id ur8mr27333567igc.91.1324306473161;
	Mon, 19 Dec 2011 06:54:33 -0800 (PST)
Received: from [192.168.0.103] (cpe-70-123-132-139.austin.res.rr.com.
	[70.123.132.139])
	by mx.google.com with ESMTPS id d19sm68353274ibh.8.2011.12.19.06.54.30
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 19 Dec 2011 06:54:31 -0800 (PST)
Message-ID: <4EEF5024.4060409@codemonkey.ws>
Date: Mon, 19 Dec 2011 08:54:28 -0600
From: Anthony Liguori <anthony@codemonkey.ws>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.23) Gecko/20110922 Lightning/1.0b2 Thunderbird/3.1.15
MIME-Version: 1.0
To: Avi Kivity <avi@redhat.com>
References: <1324304024-11220-1-git-send-email-avi@redhat.com>
In-Reply-To: <1324304024-11220-1-git-send-email-avi@redhat.com>
Cc: xen-devel@lists.xensource.com, "Michael S. Tsirkin" <mst@redhat.com>,
	qemu-devel@nongnu.org, kvm@vger.kernel.org,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH 00/23] Remove
	cpu_get_physical_page_desc()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 12/19/2011 08:13 AM, Avi Kivity wrote:
> cpu_get_physical_page_desc() exposes the internals of the memory core to
> callers; as such it prevents the refactoring planned there.  This patchset
> converts all callers memory API equivalents and removes the function.
>
> The conversion leaves a lot of potential for further cleanups; the
> MemoryListener API (which replaces CPUPhysMemoryClient) guarantees matched
> range_add and range_del calls, so the need to handle splitting is removed.
> This is left for later.
>
> Please review and test, especially the vhost and Xen parts, which I only
> build tested.

Other than the few style comments, the whole series looks reasonable to me.

Regards,

Anthony Liguori

>
> Also available from:
>
>    git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git memory/page_desc
>
> Avi Kivity (23):
>    memory: introduce memory_region_find()
>    sysbus: add sysbus_address_space()
>    memory: add memory_region_is_ram()
>    framebuffer: drop use of cpu_get_physical_page_desc()
>    memory: add memory_region_is_rom()
>    loader: remove calls to cpu_get_physical_page_desc()
>    framebuffer: drop use of cpu_physical_sync_dirty_bitmap()
>    memory: replace cpu_physical_sync_dirty_bitmap() with a memory API
>    memory: add API for observing updates to the physical memory map
>    memory: add memory_region_is_logging()
>    kvm: switch kvm slots to use host virtual address instead of
>      ram_addr_t
>    fixup: listener fixes
>    kvm: convert to MemoryListener API
>    vhost: convert to MemoryListener API
>    xen, vga: add API for registering the framebuffer
>    memory: temporarily add memory_region_get_ram_addr()
>    xen: convert to MemoryListener API
>    memory: remove CPUPhysMemoryClient
>    kvm: avoid cpu_get_physical_page_desc()
>    vhost: avoid cpu_get_physical_page_desc()
>    virtio-balloon: avoid cpu_get_physical_page_desc()
>    sparc: avoid cpu_get_physical_page_desc()
>    Remove cpu_get_physical_page_desc()
>
>   arch_init.c               |    6 +-
>   cpu-all.h                 |    9 --
>   cpu-common.h              |   24 ------
>   exec.c                    |  175 +---------------------------------------
>   hw/framebuffer.c          |   32 +++----
>   hw/framebuffer.h          |    3 +
>   hw/loader.c               |    9 +-
>   hw/milkymist-vgafb.c      |    2 +-
>   hw/omap_lcdc.c            |    4 +-
>   hw/pl110.c                |    2 +-
>   hw/pxa2xx_lcd.c           |   10 ++-
>   hw/sysbus.c               |    5 +
>   hw/sysbus.h               |    1 +
>   hw/vga.c                  |    2 +
>   hw/vhost.c                |  167 ++++++++++++++++++++++++++++++---------
>   hw/vhost.h                |    5 +-
>   hw/virtio-balloon.c       |   14 +++-
>   hw/xen.h                  |    3 +
>   kvm-all.c                 |  151 +++++++++++++++++++++--------------
>   kvm.h                     |    4 +-
>   memory.c                  |  193 ++++++++++++++++++++++++++++++++++++++++++---
>   memory.h                  |  127 +++++++++++++++++++++++++++++
>   target-i386/kvm.c         |    7 +-
>   target-sparc/mmu_helper.c |    5 +-
>   trace-events              |    2 +-
>   xen-all.c                 |  143 ++++++++++++++++++++-------------
>   xen-stub.c                |    4 +
>   27 files changed, 695 insertions(+), 414 deletions(-)
>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 14:54:55 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 14:54:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rcec0-0004kg-4E; Mon, 19 Dec 2011 14:54:44 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony@codemonkey.ws>) id 1Rceby-0004kN-6T
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 14:54:42 +0000
X-Env-Sender: anthony@codemonkey.ws
X-Msg-Ref: server-5.tower-182.messagelabs.com!1324306474!7881705!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28200 invoked from network); 19 Dec 2011 14:54:36 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Dec 2011 14:54:36 -0000
Received: by iagw33 with SMTP id w33so32354921iag.30
	for <xen-devel@lists.xensource.com>;
	Mon, 19 Dec 2011 06:54:34 -0800 (PST)
Received: by 10.50.236.40 with SMTP id ur8mr27333567igc.91.1324306473161;
	Mon, 19 Dec 2011 06:54:33 -0800 (PST)
Received: from [192.168.0.103] (cpe-70-123-132-139.austin.res.rr.com.
	[70.123.132.139])
	by mx.google.com with ESMTPS id d19sm68353274ibh.8.2011.12.19.06.54.30
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 19 Dec 2011 06:54:31 -0800 (PST)
Message-ID: <4EEF5024.4060409@codemonkey.ws>
Date: Mon, 19 Dec 2011 08:54:28 -0600
From: Anthony Liguori <anthony@codemonkey.ws>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.23) Gecko/20110922 Lightning/1.0b2 Thunderbird/3.1.15
MIME-Version: 1.0
To: Avi Kivity <avi@redhat.com>
References: <1324304024-11220-1-git-send-email-avi@redhat.com>
In-Reply-To: <1324304024-11220-1-git-send-email-avi@redhat.com>
Cc: xen-devel@lists.xensource.com, "Michael S. Tsirkin" <mst@redhat.com>,
	qemu-devel@nongnu.org, kvm@vger.kernel.org,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH 00/23] Remove
	cpu_get_physical_page_desc()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 12/19/2011 08:13 AM, Avi Kivity wrote:
> cpu_get_physical_page_desc() exposes the internals of the memory core to
> callers; as such it prevents the refactoring planned there.  This patchset
> converts all callers memory API equivalents and removes the function.
>
> The conversion leaves a lot of potential for further cleanups; the
> MemoryListener API (which replaces CPUPhysMemoryClient) guarantees matched
> range_add and range_del calls, so the need to handle splitting is removed.
> This is left for later.
>
> Please review and test, especially the vhost and Xen parts, which I only
> build tested.

Other than the few style comments, the whole series looks reasonable to me.

Regards,

Anthony Liguori

>
> Also available from:
>
>    git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git memory/page_desc
>
> Avi Kivity (23):
>    memory: introduce memory_region_find()
>    sysbus: add sysbus_address_space()
>    memory: add memory_region_is_ram()
>    framebuffer: drop use of cpu_get_physical_page_desc()
>    memory: add memory_region_is_rom()
>    loader: remove calls to cpu_get_physical_page_desc()
>    framebuffer: drop use of cpu_physical_sync_dirty_bitmap()
>    memory: replace cpu_physical_sync_dirty_bitmap() with a memory API
>    memory: add API for observing updates to the physical memory map
>    memory: add memory_region_is_logging()
>    kvm: switch kvm slots to use host virtual address instead of
>      ram_addr_t
>    fixup: listener fixes
>    kvm: convert to MemoryListener API
>    vhost: convert to MemoryListener API
>    xen, vga: add API for registering the framebuffer
>    memory: temporarily add memory_region_get_ram_addr()
>    xen: convert to MemoryListener API
>    memory: remove CPUPhysMemoryClient
>    kvm: avoid cpu_get_physical_page_desc()
>    vhost: avoid cpu_get_physical_page_desc()
>    virtio-balloon: avoid cpu_get_physical_page_desc()
>    sparc: avoid cpu_get_physical_page_desc()
>    Remove cpu_get_physical_page_desc()
>
>   arch_init.c               |    6 +-
>   cpu-all.h                 |    9 --
>   cpu-common.h              |   24 ------
>   exec.c                    |  175 +---------------------------------------
>   hw/framebuffer.c          |   32 +++----
>   hw/framebuffer.h          |    3 +
>   hw/loader.c               |    9 +-
>   hw/milkymist-vgafb.c      |    2 +-
>   hw/omap_lcdc.c            |    4 +-
>   hw/pl110.c                |    2 +-
>   hw/pxa2xx_lcd.c           |   10 ++-
>   hw/sysbus.c               |    5 +
>   hw/sysbus.h               |    1 +
>   hw/vga.c                  |    2 +
>   hw/vhost.c                |  167 ++++++++++++++++++++++++++++++---------
>   hw/vhost.h                |    5 +-
>   hw/virtio-balloon.c       |   14 +++-
>   hw/xen.h                  |    3 +
>   kvm-all.c                 |  151 +++++++++++++++++++++--------------
>   kvm.h                     |    4 +-
>   memory.c                  |  193 ++++++++++++++++++++++++++++++++++++++++++---
>   memory.h                  |  127 +++++++++++++++++++++++++++++
>   target-i386/kvm.c         |    7 +-
>   target-sparc/mmu_helper.c |    5 +-
>   trace-events              |    2 +-
>   xen-all.c                 |  143 ++++++++++++++++++++-------------
>   xen-stub.c                |    4 +
>   27 files changed, 695 insertions(+), 414 deletions(-)
>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 14:55:15 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 14:55:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RcecK-0004mX-HW; Mon, 19 Dec 2011 14:55:04 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1RcecJ-0004m2-KF
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 14:55:03 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-11.tower-21.messagelabs.com!1324306495!8435893!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28560 invoked from network); 19 Dec 2011 14:54:57 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-11.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 19 Dec 2011 14:54:57 -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
	pBJEsdAX029781
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Mon, 19 Dec 2011 09:54:40 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pBJEsdXM029779;
	Mon, 19 Dec 2011 09:54:39 -0500
Date: Mon, 19 Dec 2011 10:54:39 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Carsten Schiers <carsten@schiers.de>
Message-ID: <20111219145439.GA28969@andromeda.dapyr.net>
References: <20111214220700.GA9926@phenom.dumpdata.com>
	<zarafa.4eed13dd.0c2e.0c908eda504bffd9@uhura.space.zz>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <zarafa.4eed13dd.0c2e.0c908eda504bffd9@uhura.space.zz>
User-Agent: Mutt/1.5.9i
Cc: xen-devel <xen-devel@lists.xensource.com>,
	Ian Campbell <ian.campbell@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"zhenzhong.duan@oracle.com" <zhenzhong.duan@oracle.com>,
	"linux@eikelenboom.it" <linux@eikelenboom.it>,
	"lersek@redhat.com" <lersek@redhat.com>
Subject: Re: [Xen-devel] Load increase after memory upgrade (part2)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Sat, Dec 17, 2011 at 11:12:45PM +0100, Carsten Schiers wrote:
> OK, double checked. Both PCI cards enabled, running, working, but nothing but "SWIOTLB is 0% full". Any chance
> to check that the patch is working? Does it print out something else with your setting? BR, Carsten.

Hm, and with the pvops you got some numbers along with tons of 'bounce'.

The one thing that I neglected in this patch is the alloc_coherent
part.. which I don't thing is that important as we did show that the
alloc buffers are used.

I don't have anything concrete yet, but after the holidays should have a
better idea of what is happening. Thanks for  being willing to test
this!
> 
> -----Urspr?ngliche Nachricht-----
> Von: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-bounces@lists.xensource.com] Im Auftrag von Konrad Rzeszutek Wilk
> Gesendet: Freitag, 16. Dezember 2011 17:19
> An: Carsten Schiers
> Cc: linux@eikelenboom.it; xen-devel; lersek@redhat.com; zhenzhong.duan@oracle.com; Ian Campbell
> Betreff: Re: [Xen-devel] Load increase after memory upgrade (part2)
> 
> On Fri, Dec 16, 2011 at 04:51:47PM +0100, Carsten Schiers wrote:
> > > And you are using swiotlb=force on the 2.6.34 classic kernel and passing in your budget-av card in it?
> > 
> > Yes, two of them with swiotlb=32,force.
> > 
> > 
> > > Could you append the dmesg output please?
> > 
> > Attached. You find a "normal" boot after the one with the patched kernel.
> 
> Uh, what happens when you run the driver, meaning capture stuff. I remember with the pvops you had about ~30K or so of bounces, but not sure about the bootup?
> 
> Thanks for being willing to be a guinea pig while trying to fix this.
> > 
> > Carsten.
> > 
> > 
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 14:55:15 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 14:55:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RcecK-0004mX-HW; Mon, 19 Dec 2011 14:55:04 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1RcecJ-0004m2-KF
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 14:55:03 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-11.tower-21.messagelabs.com!1324306495!8435893!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28560 invoked from network); 19 Dec 2011 14:54:57 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-11.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 19 Dec 2011 14:54:57 -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
	pBJEsdAX029781
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Mon, 19 Dec 2011 09:54:40 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pBJEsdXM029779;
	Mon, 19 Dec 2011 09:54:39 -0500
Date: Mon, 19 Dec 2011 10:54:39 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Carsten Schiers <carsten@schiers.de>
Message-ID: <20111219145439.GA28969@andromeda.dapyr.net>
References: <20111214220700.GA9926@phenom.dumpdata.com>
	<zarafa.4eed13dd.0c2e.0c908eda504bffd9@uhura.space.zz>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <zarafa.4eed13dd.0c2e.0c908eda504bffd9@uhura.space.zz>
User-Agent: Mutt/1.5.9i
Cc: xen-devel <xen-devel@lists.xensource.com>,
	Ian Campbell <ian.campbell@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"zhenzhong.duan@oracle.com" <zhenzhong.duan@oracle.com>,
	"linux@eikelenboom.it" <linux@eikelenboom.it>,
	"lersek@redhat.com" <lersek@redhat.com>
Subject: Re: [Xen-devel] Load increase after memory upgrade (part2)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Sat, Dec 17, 2011 at 11:12:45PM +0100, Carsten Schiers wrote:
> OK, double checked. Both PCI cards enabled, running, working, but nothing but "SWIOTLB is 0% full". Any chance
> to check that the patch is working? Does it print out something else with your setting? BR, Carsten.

Hm, and with the pvops you got some numbers along with tons of 'bounce'.

The one thing that I neglected in this patch is the alloc_coherent
part.. which I don't thing is that important as we did show that the
alloc buffers are used.

I don't have anything concrete yet, but after the holidays should have a
better idea of what is happening. Thanks for  being willing to test
this!
> 
> -----Urspr?ngliche Nachricht-----
> Von: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-bounces@lists.xensource.com] Im Auftrag von Konrad Rzeszutek Wilk
> Gesendet: Freitag, 16. Dezember 2011 17:19
> An: Carsten Schiers
> Cc: linux@eikelenboom.it; xen-devel; lersek@redhat.com; zhenzhong.duan@oracle.com; Ian Campbell
> Betreff: Re: [Xen-devel] Load increase after memory upgrade (part2)
> 
> On Fri, Dec 16, 2011 at 04:51:47PM +0100, Carsten Schiers wrote:
> > > And you are using swiotlb=force on the 2.6.34 classic kernel and passing in your budget-av card in it?
> > 
> > Yes, two of them with swiotlb=32,force.
> > 
> > 
> > > Could you append the dmesg output please?
> > 
> > Attached. You find a "normal" boot after the one with the patched kernel.
> 
> Uh, what happens when you run the driver, meaning capture stuff. I remember with the pvops you had about ~30K or so of bounces, but not sure about the bootup?
> 
> Thanks for being willing to be a guinea pig while trying to fix this.
> > 
> > Carsten.
> > 
> > 
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 14:56:29 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 14:56:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rceda-0004vt-6A; Mon, 19 Dec 2011 14:56:22 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1RcedY-0004uu-36
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 14:56:20 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-6.tower-21.messagelabs.com!1324306572!8644354!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29656 invoked from network); 19 Dec 2011 14:56:13 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-6.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 19 Dec 2011 14:56:13 -0000
Received: from andromeda.dapyr.net (darnok@localhost [127.0.0.1])
	by andromeda.dapyr.net (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id
	pBJEu9HV029831
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Mon, 19 Dec 2011 09:56:09 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pBJEu9Gm029829;
	Mon, 19 Dec 2011 09:56:09 -0500
Date: Mon, 19 Dec 2011 10:56:09 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Sander Eikelenboom <linux@eikelenboom.it>
Message-ID: <20111219145609.GB28969@andromeda.dapyr.net>
References: <20111214220700.GA9926@phenom.dumpdata.com>
	<zarafa.4eed13dd.0c2e.0c908eda504bffd9@uhura.space.zz>
	<783969451.20111218011916@eikelenboom.it>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <783969451.20111218011916@eikelenboom.it>
User-Agent: Mutt/1.5.9i
Cc: xen-devel <xen-devel@lists.xensource.com>,
	Ian Campbell <ian.campbell@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Carsten Schiers <carsten@schiers.de>, zhenzhong.duan@oracle.com,
	lersek@redhat.com
Subject: Re: [Xen-devel] Load increase after memory upgrade (part2)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Sun, Dec 18, 2011 at 01:19:16AM +0100, Sander Eikelenboom wrote:
> I also have done some experiments with the patch, in domU i also get the 0% full for my usb controllers with video grabbers , in dom0 my i get 12% full, both my realtek 8169 ethernet controllers seem to use the bounce buffering ...
> And that with a iommu (amd) ? it all seems kind of strange, although it is also working ...
> I'm not having much time now, hoping to get back with a full report soon.

Hm, so domU nothing, but dom0 it reports. Maybe the patch is incorrect
when running as PV guest .. Will look in more details after the
holidays. Thanks for being willing to try it out.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 14:56:29 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 14:56:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rceda-0004vt-6A; Mon, 19 Dec 2011 14:56:22 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1RcedY-0004uu-36
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 14:56:20 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-6.tower-21.messagelabs.com!1324306572!8644354!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29656 invoked from network); 19 Dec 2011 14:56:13 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-6.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 19 Dec 2011 14:56:13 -0000
Received: from andromeda.dapyr.net (darnok@localhost [127.0.0.1])
	by andromeda.dapyr.net (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id
	pBJEu9HV029831
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Mon, 19 Dec 2011 09:56:09 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pBJEu9Gm029829;
	Mon, 19 Dec 2011 09:56:09 -0500
Date: Mon, 19 Dec 2011 10:56:09 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Sander Eikelenboom <linux@eikelenboom.it>
Message-ID: <20111219145609.GB28969@andromeda.dapyr.net>
References: <20111214220700.GA9926@phenom.dumpdata.com>
	<zarafa.4eed13dd.0c2e.0c908eda504bffd9@uhura.space.zz>
	<783969451.20111218011916@eikelenboom.it>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <783969451.20111218011916@eikelenboom.it>
User-Agent: Mutt/1.5.9i
Cc: xen-devel <xen-devel@lists.xensource.com>,
	Ian Campbell <ian.campbell@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Carsten Schiers <carsten@schiers.de>, zhenzhong.duan@oracle.com,
	lersek@redhat.com
Subject: Re: [Xen-devel] Load increase after memory upgrade (part2)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Sun, Dec 18, 2011 at 01:19:16AM +0100, Sander Eikelenboom wrote:
> I also have done some experiments with the patch, in domU i also get the 0% full for my usb controllers with video grabbers , in dom0 my i get 12% full, both my realtek 8169 ethernet controllers seem to use the bounce buffering ...
> And that with a iommu (amd) ? it all seems kind of strange, although it is also working ...
> I'm not having much time now, hoping to get back with a full report soon.

Hm, so domU nothing, but dom0 it reports. Maybe the patch is incorrect
when running as PV guest .. Will look in more details after the
holidays. Thanks for being willing to try it out.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 14:59:16 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 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.xensource.com>)
	id 1RcegB-0005E0-Ps; Mon, 19 Dec 2011 14:59:03 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Rceg9-0005DS-7s
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 14:59:01 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1324306734!7326556!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5837 invoked from network); 19 Dec 2011 14:58:55 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-13.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 19 Dec 2011 14:58:55 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 19 Dec 2011 14:58:54 +0000
Message-Id: <4EEF5F720200007800068DB3@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 19 Dec 2011 14:59:46 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "George Dunlap" <George.Dunlap@eu.citrix.com>
References: <C10D3FB0CD45994C8A51FEC1227CE22F37CC284376@shsmsx502.ccr.corp.intel.com>
	<4EEF02E20200007800068C60@nat28.tlf.novell.com>
	<CAFLBxZb3Yc7G4QzEXKdfrVkoz1XGv09zTxCQCC4Dnkr-6M5K5Q@mail.gmail.com>
	<4EEF36A60200007800068D43@nat28.tlf.novell.com>
	<CAFLBxZahyAJ5Y7+eGGCkoOKZZGQ4rYwdZutyjAMH2CcQhDkcZw@mail.gmail.com>
In-Reply-To: <CAFLBxZahyAJ5Y7+eGGCkoOKZZGQ4rYwdZutyjAMH2CcQhDkcZw@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Kevin Tian <kevin.tian@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"keir@xen.org" <keir@xen.org>, Eddie Dong <eddie.dong@intel.com>,
	Hui Lv <hui.lv@intel.com>, Jiangang Duan <jiangang.duan@intel.com>,
	Zhidong Yu <zhidong.yu@intel.com>
Subject: Re: [Xen-devel] [PATCH v2] xen/credit scheduler;
 Use delay to control scheduling frequency
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 19.12.11 at 14:59, George Dunlap <George.Dunlap@eu.citrix.com> wrote:
> On Mon, Dec 19, 2011 at 12:05 PM, Jan Beulich <JBeulich@suse.com> wrote:
>>> The way it stands now, the ratelimit value will override the timeslice
>>> value.  It had to be one way or the other; do you think the timeslice
>>> value should be the priority?
>>
>> The minimum of both should be used, I would think.
> 
> What do you mean?  You mean in the assignment above?

Yes, I had thought that this would suffice. But ...

> That won't have any effect other than increasing interrupts and trips
> through the scheduler.  Suppose the following set of events:
> * timeslice is set to 1ms, ratelimit_us to 5000.
> * a vcpu V is chosen; it's set to run with 1ms timeout.
> * 1ms later, we go through the scheduler; the ratelimit code
> determines that it hasn't run for long enough (only 1ms), so choses it
> to run again (with a 1ms timeslice)
> * Repeat until V has run for 5ms.

... if that's what's happening, the whole thing looks bogus to me.
Clearly the rate limit code should not force the time slice to be
extended.

> So although the timeslice is set to 1ms, and interrupts are happening
> after 1ms, the ratelimit is overriding the 1ms of the timeslice and
> making it 5ms.  Fundamentally, one of the two parameters must override
> the other.  With this patch the way it is now, ratelimit will override
> timeslice.  if you want the timeslice to override ratelimit, then
> there will have to be more code to make that happen.

Overriding the rate limit by the time slice isn't the right thing either,
as that (the way I "read" it) means there's no rate limiting at all.
What "rate limit" to me means is preventing quickly switching away
from a vCPU recently scheduled without extending its (remaining)
time slice, i.e. in any place a respective evaluation is done the
shorter of the two should be used.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 14:59:16 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 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.xensource.com>)
	id 1RcegB-0005E0-Ps; Mon, 19 Dec 2011 14:59:03 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Rceg9-0005DS-7s
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 14:59:01 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1324306734!7326556!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5837 invoked from network); 19 Dec 2011 14:58:55 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-13.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 19 Dec 2011 14:58:55 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 19 Dec 2011 14:58:54 +0000
Message-Id: <4EEF5F720200007800068DB3@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 19 Dec 2011 14:59:46 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "George Dunlap" <George.Dunlap@eu.citrix.com>
References: <C10D3FB0CD45994C8A51FEC1227CE22F37CC284376@shsmsx502.ccr.corp.intel.com>
	<4EEF02E20200007800068C60@nat28.tlf.novell.com>
	<CAFLBxZb3Yc7G4QzEXKdfrVkoz1XGv09zTxCQCC4Dnkr-6M5K5Q@mail.gmail.com>
	<4EEF36A60200007800068D43@nat28.tlf.novell.com>
	<CAFLBxZahyAJ5Y7+eGGCkoOKZZGQ4rYwdZutyjAMH2CcQhDkcZw@mail.gmail.com>
In-Reply-To: <CAFLBxZahyAJ5Y7+eGGCkoOKZZGQ4rYwdZutyjAMH2CcQhDkcZw@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Kevin Tian <kevin.tian@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"keir@xen.org" <keir@xen.org>, Eddie Dong <eddie.dong@intel.com>,
	Hui Lv <hui.lv@intel.com>, Jiangang Duan <jiangang.duan@intel.com>,
	Zhidong Yu <zhidong.yu@intel.com>
Subject: Re: [Xen-devel] [PATCH v2] xen/credit scheduler;
 Use delay to control scheduling frequency
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 19.12.11 at 14:59, George Dunlap <George.Dunlap@eu.citrix.com> wrote:
> On Mon, Dec 19, 2011 at 12:05 PM, Jan Beulich <JBeulich@suse.com> wrote:
>>> The way it stands now, the ratelimit value will override the timeslice
>>> value.  It had to be one way or the other; do you think the timeslice
>>> value should be the priority?
>>
>> The minimum of both should be used, I would think.
> 
> What do you mean?  You mean in the assignment above?

Yes, I had thought that this would suffice. But ...

> That won't have any effect other than increasing interrupts and trips
> through the scheduler.  Suppose the following set of events:
> * timeslice is set to 1ms, ratelimit_us to 5000.
> * a vcpu V is chosen; it's set to run with 1ms timeout.
> * 1ms later, we go through the scheduler; the ratelimit code
> determines that it hasn't run for long enough (only 1ms), so choses it
> to run again (with a 1ms timeslice)
> * Repeat until V has run for 5ms.

... if that's what's happening, the whole thing looks bogus to me.
Clearly the rate limit code should not force the time slice to be
extended.

> So although the timeslice is set to 1ms, and interrupts are happening
> after 1ms, the ratelimit is overriding the 1ms of the timeslice and
> making it 5ms.  Fundamentally, one of the two parameters must override
> the other.  With this patch the way it is now, ratelimit will override
> timeslice.  if you want the timeslice to override ratelimit, then
> there will have to be more code to make that happen.

Overriding the rate limit by the time slice isn't the right thing either,
as that (the way I "read" it) means there's no rate limiting at all.
What "rate limit" to me means is preventing quickly switching away
from a vCPU recently scheduled without extending its (remaining)
time slice, i.e. in any place a respective evaluation is done the
shorter of the two should be used.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 15:04:30 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 15:04:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RcelF-0005ab-IO; Mon, 19 Dec 2011 15:04:17 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <avi@redhat.com>) id 1RcelE-0005aF-2k
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 15:04:16 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1324307049!7862050!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDY0OTI=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22860 invoked from network); 19 Dec 2011 15:04:09 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-6.tower-182.messagelabs.com with SMTP;
	19 Dec 2011 15:04:09 -0000
Received: from int-mx10.intmail.prod.int.phx2.redhat.com
	(int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id pBJF46cv025274
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 19 Dec 2011 10:04:06 -0500
Received: from balrog.usersys.redhat.com (dhcp-4-24.tlv.redhat.com
	[10.35.4.24])
	by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id pBJF4389003877; Mon, 19 Dec 2011 10:04:04 -0500
Message-ID: <4EEF5263.8070004@redhat.com>
Date: Mon, 19 Dec 2011 17:04:03 +0200
From: Avi Kivity <avi@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:8.0) Gecko/20111115 Thunderbird/8.0
MIME-Version: 1.0
To: Anthony Liguori <anthony@codemonkey.ws>
References: <1324304024-11220-1-git-send-email-avi@redhat.com>
	<1324304024-11220-2-git-send-email-avi@redhat.com>
	<4EEF4F1E.9080104@codemonkey.ws>
In-Reply-To: <4EEF4F1E.9080104@codemonkey.ws>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
Cc: xen-devel@lists.xensource.com, "Michael S. Tsirkin" <mst@redhat.com>,
	qemu-devel@nongnu.org, kvm@vger.kernel.org,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH 01/23] memory: introduce
	memory_region_find()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 12/19/2011 04:50 PM, Anthony Liguori wrote:
>> +static int cmp_flatrange_addr(const void *_addr, const void *_fr)
>> +{
>> +    const AddrRange *addr = _addr;
>> +    const FlatRange *fr = _fr;
>
>
> Please don't prefix with an underscore.

Why not?  It's legal according to the standards, if that's your concern
(only _[_A-Z]+ are reserved).

>> @@ -502,6 +520,20 @@ void memory_region_del_subregion(MemoryRegion *mr,
>>                                    MemoryRegion *subregion);
>>
>>   /**
>> + * memory_region_find: locate a MemoryRegion in an address space
>> + *
>> + * Locates the first #MemoryRegion within an address space given by
>> + * @address_space that overlaps the range given by @addr and @size.
>> + *
>> + * @address_space: a top-level (i.e. parentless) region that contains
>> + *       the region to be found
>> + * @addr: start of the area within @address_space to be searched
>> + * @size: size of the area to be searched
>> + */
>> +MemoryRegionSection memory_region_find(MemoryRegion *address_space,
>> +                                       target_phys_addr_t addr,
>> uint64_t size);
>
>
> Returning structs by value is a bit unexpected.

It's just prejudice, here's the call sequence:

  127a63:       48 89 c6                mov    %rax,%rsi
  127a66:       48 8d 45 b0             lea    -0x50(%rbp),%rax
  127a6a:       b9 01 00 00 00          mov    $0x1,%ecx
  127a6f:       48 89 da                mov    %rbx,%rdx
  127a72:       48 89 c7                mov    %rax,%rdi
  127a75:       e8 89 46 15 00          callq  27c103 <memory_region_find>

The return value is passed via %rax, so no performance penalty.  On the
other hand, it's clear that it is a return value, unlike a pointer
parameter.

-- 
error compiling committee.c: too many arguments to function


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 15:04:30 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 15:04:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RcelF-0005ab-IO; Mon, 19 Dec 2011 15:04:17 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <avi@redhat.com>) id 1RcelE-0005aF-2k
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 15:04:16 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1324307049!7862050!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDY0OTI=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22860 invoked from network); 19 Dec 2011 15:04:09 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-6.tower-182.messagelabs.com with SMTP;
	19 Dec 2011 15:04:09 -0000
Received: from int-mx10.intmail.prod.int.phx2.redhat.com
	(int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id pBJF46cv025274
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 19 Dec 2011 10:04:06 -0500
Received: from balrog.usersys.redhat.com (dhcp-4-24.tlv.redhat.com
	[10.35.4.24])
	by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id pBJF4389003877; Mon, 19 Dec 2011 10:04:04 -0500
Message-ID: <4EEF5263.8070004@redhat.com>
Date: Mon, 19 Dec 2011 17:04:03 +0200
From: Avi Kivity <avi@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:8.0) Gecko/20111115 Thunderbird/8.0
MIME-Version: 1.0
To: Anthony Liguori <anthony@codemonkey.ws>
References: <1324304024-11220-1-git-send-email-avi@redhat.com>
	<1324304024-11220-2-git-send-email-avi@redhat.com>
	<4EEF4F1E.9080104@codemonkey.ws>
In-Reply-To: <4EEF4F1E.9080104@codemonkey.ws>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
Cc: xen-devel@lists.xensource.com, "Michael S. Tsirkin" <mst@redhat.com>,
	qemu-devel@nongnu.org, kvm@vger.kernel.org,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH 01/23] memory: introduce
	memory_region_find()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 12/19/2011 04:50 PM, Anthony Liguori wrote:
>> +static int cmp_flatrange_addr(const void *_addr, const void *_fr)
>> +{
>> +    const AddrRange *addr = _addr;
>> +    const FlatRange *fr = _fr;
>
>
> Please don't prefix with an underscore.

Why not?  It's legal according to the standards, if that's your concern
(only _[_A-Z]+ are reserved).

>> @@ -502,6 +520,20 @@ void memory_region_del_subregion(MemoryRegion *mr,
>>                                    MemoryRegion *subregion);
>>
>>   /**
>> + * memory_region_find: locate a MemoryRegion in an address space
>> + *
>> + * Locates the first #MemoryRegion within an address space given by
>> + * @address_space that overlaps the range given by @addr and @size.
>> + *
>> + * @address_space: a top-level (i.e. parentless) region that contains
>> + *       the region to be found
>> + * @addr: start of the area within @address_space to be searched
>> + * @size: size of the area to be searched
>> + */
>> +MemoryRegionSection memory_region_find(MemoryRegion *address_space,
>> +                                       target_phys_addr_t addr,
>> uint64_t size);
>
>
> Returning structs by value is a bit unexpected.

It's just prejudice, here's the call sequence:

  127a63:       48 89 c6                mov    %rax,%rsi
  127a66:       48 8d 45 b0             lea    -0x50(%rbp),%rax
  127a6a:       b9 01 00 00 00          mov    $0x1,%ecx
  127a6f:       48 89 da                mov    %rbx,%rdx
  127a72:       48 89 c7                mov    %rax,%rdi
  127a75:       e8 89 46 15 00          callq  27c103 <memory_region_find>

The return value is passed via %rax, so no performance penalty.  On the
other hand, it's clear that it is a return value, unlike a pointer
parameter.

-- 
error compiling committee.c: too many arguments to function


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 15:10:38 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 15:10:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RcerA-0005mE-Ht; Mon, 19 Dec 2011 15:10:24 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony@codemonkey.ws>) id 1Rcer8-0005lz-Lc
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 15:10:22 +0000
X-Env-Sender: anthony@codemonkey.ws
X-Msg-Ref: server-12.tower-216.messagelabs.com!1324307414!8041144!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21353 invoked from network); 19 Dec 2011 15:10:16 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Dec 2011 15:10:16 -0000
Received: by iagw33 with SMTP id w33so32395573iag.30
	for <xen-devel@lists.xensource.com>;
	Mon, 19 Dec 2011 07:10:14 -0800 (PST)
Received: by 10.50.158.227 with SMTP id wx3mr28114580igb.52.1324307414436;
	Mon, 19 Dec 2011 07:10:14 -0800 (PST)
Received: from [192.168.0.103] (cpe-70-123-132-139.austin.res.rr.com.
	[70.123.132.139])
	by mx.google.com with ESMTPS id wn1sm31989627igc.3.2011.12.19.07.10.10
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 19 Dec 2011 07:10:12 -0800 (PST)
Message-ID: <4EEF53D1.5040302@codemonkey.ws>
Date: Mon, 19 Dec 2011 09:10:09 -0600
From: Anthony Liguori <anthony@codemonkey.ws>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.23) Gecko/20110922 Lightning/1.0b2 Thunderbird/3.1.15
MIME-Version: 1.0
To: Avi Kivity <avi@redhat.com>
References: <1324304024-11220-1-git-send-email-avi@redhat.com>	<1324304024-11220-2-git-send-email-avi@redhat.com>	<4EEF4F1E.9080104@codemonkey.ws>
	<4EEF5263.8070004@redhat.com>
In-Reply-To: <4EEF5263.8070004@redhat.com>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	xen-devel@lists.xensource.com, qemu-devel@nongnu.org,
	kvm@vger.kernel.org, "Michael S. Tsirkin" <mst@redhat.com>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH 01/23] memory: introduce
	memory_region_find()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="windows-1252"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 12/19/2011 09:04 AM, Avi Kivity wrote:
> On 12/19/2011 04:50 PM, Anthony Liguori wrote:
>>> +static int cmp_flatrange_addr(const void *_addr, const void *_fr)
>>> +{
>>> +    const AddrRange *addr =3D _addr;
>>> +    const FlatRange *fr =3D _fr;
>>
>>
>> Please don't prefix with an underscore.
>
> Why not?  It's legal according to the standards, if that's your concern
> (only _[_A-Z]+ are reserved).

http://www.gnu.org/s/hello/manual/libc/Reserved-Names.html

"In addition to the names documented in this manual, reserved names include=
 all =

external identifiers (global functions and variables) that begin with an =

underscore (=91_=92)"

Now that might just mean that you're shadowing a global name, so maybe that=
's =

okay, but I think it's easier to just enforce a consistent rule of, "don't =
start =

identifiers with an underscore".

>
>>> @@ -502,6 +520,20 @@ void memory_region_del_subregion(MemoryRegion *mr,
>>>                                     MemoryRegion *subregion);
>>>
>>>    /**
>>> + * memory_region_find: locate a MemoryRegion in an address space
>>> + *
>>> + * Locates the first #MemoryRegion within an address space given by
>>> + * @address_space that overlaps the range given by @addr and @size.
>>> + *
>>> + * @address_space: a top-level (i.e. parentless) region that contains
>>> + *       the region to be found
>>> + * @addr: start of the area within @address_space to be searched
>>> + * @size: size of the area to be searched
>>> + */
>>> +MemoryRegionSection memory_region_find(MemoryRegion *address_space,
>>> +                                       target_phys_addr_t addr,
>>> uint64_t size);
>>
>>
>> Returning structs by value is a bit unexpected.
>
> It's just prejudice, here's the call sequence:

It's not about whether it's fast or slow.  It's just unexpected.

Instead of returning a NULL pointer on error, you set .mr to NULL if an err=
or =

occurs (which isn't documented by the comment btw).  Returning a pointer, o=
r =

taking a pointer and returning a 0/-1 return value makes for a more consist=
ent =

semantic with the rest of the code base.

Regards,

Anthony Liguori

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 15:10:38 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 15:10:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RcerA-0005mE-Ht; Mon, 19 Dec 2011 15:10:24 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony@codemonkey.ws>) id 1Rcer8-0005lz-Lc
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 15:10:22 +0000
X-Env-Sender: anthony@codemonkey.ws
X-Msg-Ref: server-12.tower-216.messagelabs.com!1324307414!8041144!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21353 invoked from network); 19 Dec 2011 15:10:16 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Dec 2011 15:10:16 -0000
Received: by iagw33 with SMTP id w33so32395573iag.30
	for <xen-devel@lists.xensource.com>;
	Mon, 19 Dec 2011 07:10:14 -0800 (PST)
Received: by 10.50.158.227 with SMTP id wx3mr28114580igb.52.1324307414436;
	Mon, 19 Dec 2011 07:10:14 -0800 (PST)
Received: from [192.168.0.103] (cpe-70-123-132-139.austin.res.rr.com.
	[70.123.132.139])
	by mx.google.com with ESMTPS id wn1sm31989627igc.3.2011.12.19.07.10.10
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 19 Dec 2011 07:10:12 -0800 (PST)
Message-ID: <4EEF53D1.5040302@codemonkey.ws>
Date: Mon, 19 Dec 2011 09:10:09 -0600
From: Anthony Liguori <anthony@codemonkey.ws>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.23) Gecko/20110922 Lightning/1.0b2 Thunderbird/3.1.15
MIME-Version: 1.0
To: Avi Kivity <avi@redhat.com>
References: <1324304024-11220-1-git-send-email-avi@redhat.com>	<1324304024-11220-2-git-send-email-avi@redhat.com>	<4EEF4F1E.9080104@codemonkey.ws>
	<4EEF5263.8070004@redhat.com>
In-Reply-To: <4EEF5263.8070004@redhat.com>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	xen-devel@lists.xensource.com, qemu-devel@nongnu.org,
	kvm@vger.kernel.org, "Michael S. Tsirkin" <mst@redhat.com>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH 01/23] memory: introduce
	memory_region_find()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="windows-1252"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 12/19/2011 09:04 AM, Avi Kivity wrote:
> On 12/19/2011 04:50 PM, Anthony Liguori wrote:
>>> +static int cmp_flatrange_addr(const void *_addr, const void *_fr)
>>> +{
>>> +    const AddrRange *addr =3D _addr;
>>> +    const FlatRange *fr =3D _fr;
>>
>>
>> Please don't prefix with an underscore.
>
> Why not?  It's legal according to the standards, if that's your concern
> (only _[_A-Z]+ are reserved).

http://www.gnu.org/s/hello/manual/libc/Reserved-Names.html

"In addition to the names documented in this manual, reserved names include=
 all =

external identifiers (global functions and variables) that begin with an =

underscore (=91_=92)"

Now that might just mean that you're shadowing a global name, so maybe that=
's =

okay, but I think it's easier to just enforce a consistent rule of, "don't =
start =

identifiers with an underscore".

>
>>> @@ -502,6 +520,20 @@ void memory_region_del_subregion(MemoryRegion *mr,
>>>                                     MemoryRegion *subregion);
>>>
>>>    /**
>>> + * memory_region_find: locate a MemoryRegion in an address space
>>> + *
>>> + * Locates the first #MemoryRegion within an address space given by
>>> + * @address_space that overlaps the range given by @addr and @size.
>>> + *
>>> + * @address_space: a top-level (i.e. parentless) region that contains
>>> + *       the region to be found
>>> + * @addr: start of the area within @address_space to be searched
>>> + * @size: size of the area to be searched
>>> + */
>>> +MemoryRegionSection memory_region_find(MemoryRegion *address_space,
>>> +                                       target_phys_addr_t addr,
>>> uint64_t size);
>>
>>
>> Returning structs by value is a bit unexpected.
>
> It's just prejudice, here's the call sequence:

It's not about whether it's fast or slow.  It's just unexpected.

Instead of returning a NULL pointer on error, you set .mr to NULL if an err=
or =

occurs (which isn't documented by the comment btw).  Returning a pointer, o=
r =

taking a pointer and returning a 0/-1 return value makes for a more consist=
ent =

semantic with the rest of the code base.

Regards,

Anthony Liguori

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 15:17:39 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 15:17:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rcexu-0005z9-Fu; Mon, 19 Dec 2011 15:17:22 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <avi@redhat.com>) id 1Rcexs-0005z1-JL
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 15:17:20 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1324307788!57899688!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDY0OTI=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23671 invoked from network); 19 Dec 2011 15:16:28 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-2.tower-27.messagelabs.com with SMTP;
	19 Dec 2011 15:16:28 -0000
Received: from int-mx09.intmail.prod.int.phx2.redhat.com
	(int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id pBJEmTYH022933
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 19 Dec 2011 09:48:29 -0500
Received: from balrog.usersys.redhat.com (dhcp-4-24.tlv.redhat.com
	[10.35.4.24])
	by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id pBJEmRF6020889; Mon, 19 Dec 2011 09:48:27 -0500
Message-ID: <4EEF4EBA.9040407@redhat.com>
Date: Mon, 19 Dec 2011 16:48:26 +0200
From: Avi Kivity <avi@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:8.0) Gecko/20111115 Thunderbird/8.0
MIME-Version: 1.0
To: Peter Maydell <peter.maydell@linaro.org>
References: <1324304024-11220-1-git-send-email-avi@redhat.com>
	<1324304024-11220-13-git-send-email-avi@redhat.com>
	<CAFEAcA8b=HNN3t-GsN6J0HoHMp7+ubBiwirb1-j8=x_Qm-bOPA@mail.gmail.com>
In-Reply-To: <CAFEAcA8b=HNN3t-GsN6J0HoHMp7+ubBiwirb1-j8=x_Qm-bOPA@mail.gmail.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
Cc: xen-devel@lists.xensource.com, "Michael S. Tsirkin" <mst@redhat.com>,
	qemu-devel@nongnu.org, kvm@vger.kernel.org,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH 12/23] fixup: listener fixes
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 12/19/2011 04:32 PM, Peter Maydell wrote:
> On 19 December 2011 14:13, Avi Kivity <avi@redhat.com> wrote:
> > ---
>
> This is a rather uninformative commit message -- was this patch
> intended to be in this series?
>

It was intended to be merged into patch 9.  Will fix for the next round.

-- 
error compiling committee.c: too many arguments to function


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 15:17:39 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 15:17:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rcexu-0005z9-Fu; Mon, 19 Dec 2011 15:17:22 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <avi@redhat.com>) id 1Rcexs-0005z1-JL
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 15:17:20 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1324307788!57899688!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDY0OTI=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23671 invoked from network); 19 Dec 2011 15:16:28 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-2.tower-27.messagelabs.com with SMTP;
	19 Dec 2011 15:16:28 -0000
Received: from int-mx09.intmail.prod.int.phx2.redhat.com
	(int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id pBJEmTYH022933
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 19 Dec 2011 09:48:29 -0500
Received: from balrog.usersys.redhat.com (dhcp-4-24.tlv.redhat.com
	[10.35.4.24])
	by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id pBJEmRF6020889; Mon, 19 Dec 2011 09:48:27 -0500
Message-ID: <4EEF4EBA.9040407@redhat.com>
Date: Mon, 19 Dec 2011 16:48:26 +0200
From: Avi Kivity <avi@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:8.0) Gecko/20111115 Thunderbird/8.0
MIME-Version: 1.0
To: Peter Maydell <peter.maydell@linaro.org>
References: <1324304024-11220-1-git-send-email-avi@redhat.com>
	<1324304024-11220-13-git-send-email-avi@redhat.com>
	<CAFEAcA8b=HNN3t-GsN6J0HoHMp7+ubBiwirb1-j8=x_Qm-bOPA@mail.gmail.com>
In-Reply-To: <CAFEAcA8b=HNN3t-GsN6J0HoHMp7+ubBiwirb1-j8=x_Qm-bOPA@mail.gmail.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
Cc: xen-devel@lists.xensource.com, "Michael S. Tsirkin" <mst@redhat.com>,
	qemu-devel@nongnu.org, kvm@vger.kernel.org,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH 12/23] fixup: listener fixes
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 12/19/2011 04:32 PM, Peter Maydell wrote:
> On 19 December 2011 14:13, Avi Kivity <avi@redhat.com> wrote:
> > ---
>
> This is a rather uninformative commit message -- was this patch
> intended to be in this series?
>

It was intended to be merged into patch 9.  Will fix for the next round.

-- 
error compiling committee.c: too many arguments to function


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 15:18:07 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 15:18:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RceyO-00060h-TM; Mon, 19 Dec 2011 15:17:52 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <avi@redhat.com>) id 1RceyN-00060P-9k
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 15:17:51 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1324307864!2095322!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDY0OTI=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11558 invoked from network); 19 Dec 2011 15:17:44 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-16.tower-21.messagelabs.com with SMTP;
	19 Dec 2011 15:17:44 -0000
Received: from int-mx01.intmail.prod.int.phx2.redhat.com
	(int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id pBJFHfU3026317
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 19 Dec 2011 10:17:41 -0500
Received: from balrog.usersys.redhat.com (dhcp-4-24.tlv.redhat.com
	[10.35.4.24])
	by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP
	id pBJFHcc2002258; Mon, 19 Dec 2011 10:17:39 -0500
Message-ID: <4EEF5591.2010207@redhat.com>
Date: Mon, 19 Dec 2011 17:17:37 +0200
From: Avi Kivity <avi@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:8.0) Gecko/20111115 Thunderbird/8.0
MIME-Version: 1.0
To: Anthony Liguori <anthony@codemonkey.ws>
References: <1324304024-11220-1-git-send-email-avi@redhat.com>	<1324304024-11220-2-git-send-email-avi@redhat.com>	<4EEF4F1E.9080104@codemonkey.ws>
	<4EEF5263.8070004@redhat.com> <4EEF53D1.5040302@codemonkey.ws>
In-Reply-To: <4EEF53D1.5040302@codemonkey.ws>
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.11
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	xen-devel@lists.xensource.com, qemu-devel@nongnu.org,
	kvm@vger.kernel.org, "Michael S. Tsirkin" <mst@redhat.com>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH 01/23] memory: introduce
	memory_region_find()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 12/19/2011 05:10 PM, Anthony Liguori wrote:
> On 12/19/2011 09:04 AM, Avi Kivity wrote:
>> On 12/19/2011 04:50 PM, Anthony Liguori wrote:
>>>> +static int cmp_flatrange_addr(const void *_addr, const void *_fr)
>>>> +{
>>>> +    const AddrRange *addr =3D _addr;
>>>> +    const FlatRange *fr =3D _fr;
>>>
>>>
>>> Please don't prefix with an underscore.
>>
>> Why not?  It's legal according to the standards, if that's your concern
>> (only _[_A-Z]+ are reserved).
>
> http://www.gnu.org/s/hello/manual/libc/Reserved-Names.html
>
> "In addition to the names documented in this manual, reserved names
> include all external identifiers (global functions and variables) that
> begin with an underscore (=91_=92)"
>
> Now that might just mean that you're shadowing a global name, so maybe
> that's okay, but I think it's easier to just enforce a consistent rule
> of, "don't start identifiers with an underscore".

I rather like the pattern

   void callback(void *_foo)
   {
         Foo *foo =3D _foo;

         ...
   }

If the consensus is that we don't want it, I'll change it, but I do
think it's useful.

>>>> +MemoryRegionSection memory_region_find(MemoryRegion *address_space,
>>>> +                                       target_phys_addr_t addr,
>>>> uint64_t size);
>>>
>>>
>>> Returning structs by value is a bit unexpected.
>>
>> It's just prejudice, here's the call sequence:
>
> It's not about whether it's fast or slow.  It's just unexpected.

It's plain C, I don't see why it's so unexpected.

>
> Instead of returning a NULL pointer on error, you set .mr to NULL if
> an error occurs (which isn't documented by the comment btw). =

> Returning a pointer, or taking a pointer and returning a 0/-1 return
> value makes for a more consistent semantic with the rest of the code
> base.
>

How can I return a pointer?  If I allocate it, someone has to free it. =

If I pass it as a parameter, we end up with a silly looking calling
convention.  If I return an error code, the caller has to set up an
additional variable.

The natural check is section.size which is always meaningful -
memory_region_find() returns a subrange of the input, which may be
zero.  You're right that I should document it (and I should use it
consistently).

-- =

error compiling committee.c: too many arguments to function


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 15:18:07 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 15:18:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RceyO-00060h-TM; Mon, 19 Dec 2011 15:17:52 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <avi@redhat.com>) id 1RceyN-00060P-9k
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 15:17:51 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1324307864!2095322!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDY0OTI=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11558 invoked from network); 19 Dec 2011 15:17:44 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-16.tower-21.messagelabs.com with SMTP;
	19 Dec 2011 15:17:44 -0000
Received: from int-mx01.intmail.prod.int.phx2.redhat.com
	(int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id pBJFHfU3026317
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 19 Dec 2011 10:17:41 -0500
Received: from balrog.usersys.redhat.com (dhcp-4-24.tlv.redhat.com
	[10.35.4.24])
	by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP
	id pBJFHcc2002258; Mon, 19 Dec 2011 10:17:39 -0500
Message-ID: <4EEF5591.2010207@redhat.com>
Date: Mon, 19 Dec 2011 17:17:37 +0200
From: Avi Kivity <avi@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:8.0) Gecko/20111115 Thunderbird/8.0
MIME-Version: 1.0
To: Anthony Liguori <anthony@codemonkey.ws>
References: <1324304024-11220-1-git-send-email-avi@redhat.com>	<1324304024-11220-2-git-send-email-avi@redhat.com>	<4EEF4F1E.9080104@codemonkey.ws>
	<4EEF5263.8070004@redhat.com> <4EEF53D1.5040302@codemonkey.ws>
In-Reply-To: <4EEF53D1.5040302@codemonkey.ws>
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.11
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	xen-devel@lists.xensource.com, qemu-devel@nongnu.org,
	kvm@vger.kernel.org, "Michael S. Tsirkin" <mst@redhat.com>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH 01/23] memory: introduce
	memory_region_find()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 12/19/2011 05:10 PM, Anthony Liguori wrote:
> On 12/19/2011 09:04 AM, Avi Kivity wrote:
>> On 12/19/2011 04:50 PM, Anthony Liguori wrote:
>>>> +static int cmp_flatrange_addr(const void *_addr, const void *_fr)
>>>> +{
>>>> +    const AddrRange *addr =3D _addr;
>>>> +    const FlatRange *fr =3D _fr;
>>>
>>>
>>> Please don't prefix with an underscore.
>>
>> Why not?  It's legal according to the standards, if that's your concern
>> (only _[_A-Z]+ are reserved).
>
> http://www.gnu.org/s/hello/manual/libc/Reserved-Names.html
>
> "In addition to the names documented in this manual, reserved names
> include all external identifiers (global functions and variables) that
> begin with an underscore (=91_=92)"
>
> Now that might just mean that you're shadowing a global name, so maybe
> that's okay, but I think it's easier to just enforce a consistent rule
> of, "don't start identifiers with an underscore".

I rather like the pattern

   void callback(void *_foo)
   {
         Foo *foo =3D _foo;

         ...
   }

If the consensus is that we don't want it, I'll change it, but I do
think it's useful.

>>>> +MemoryRegionSection memory_region_find(MemoryRegion *address_space,
>>>> +                                       target_phys_addr_t addr,
>>>> uint64_t size);
>>>
>>>
>>> Returning structs by value is a bit unexpected.
>>
>> It's just prejudice, here's the call sequence:
>
> It's not about whether it's fast or slow.  It's just unexpected.

It's plain C, I don't see why it's so unexpected.

>
> Instead of returning a NULL pointer on error, you set .mr to NULL if
> an error occurs (which isn't documented by the comment btw). =

> Returning a pointer, or taking a pointer and returning a 0/-1 return
> value makes for a more consistent semantic with the rest of the code
> base.
>

How can I return a pointer?  If I allocate it, someone has to free it. =

If I pass it as a parameter, we end up with a silly looking calling
convention.  If I return an error code, the caller has to set up an
additional variable.

The natural check is section.size which is always meaningful -
memory_region_find() returns a subrange of the input, which may be
zero.  You're right that I should document it (and I should use it
consistently).

-- =

error compiling committee.c: too many arguments to function


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 15:21:03 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 15:21:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rcf1F-0006DK-G1; Mon, 19 Dec 2011 15:20:49 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <hramrach@gmail.com>) id 1Rcf1E-0006Cv-Bn
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 15:20:48 +0000
X-Env-Sender: hramrach@gmail.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1324308039!6111987!1
X-Originating-IP: [209.85.160.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25960 invoked from network); 19 Dec 2011 15:20:41 -0000
Received: from mail-pw0-f43.google.com (HELO mail-pw0-f43.google.com)
	(209.85.160.43)
	by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Dec 2011 15:20:41 -0000
Received: by pbbb11 with SMTP id b11so20184569pbb.30
	for <xen-devel@lists.xensource.com>;
	Mon, 19 Dec 2011 07:20:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:from:date
	:x-google-sender-auth:message-id:subject:to:cc:content-type
	:content-transfer-encoding;
	bh=jXVLCTWePP9OB7DU+2Io6idiINk7UCXgWT1W046Hk4Q=;
	b=ldEFYVS7NV3xshH5qYk0QGOmTqi18FWaJq6aAohxFwj50OGJQmXHlWheLVDwcm64oK
	xZr1tO1IEVSTG0XpZGOAoEYYxrGQ2ifaKbmKPW3eDNbc8jHv4ja4uIloirmfJnAb2SNO
	JHXWYnnJtp7x2al1UnLDY/uTE5Xf/Jga+Y2B4=
Received: by 10.68.212.200 with SMTP id nm8mr39248593pbc.28.1324308038346;
	Mon, 19 Dec 2011 07:20:38 -0800 (PST)
MIME-Version: 1.0
Received: by 10.143.60.18 with HTTP; Mon, 19 Dec 2011 07:20:17 -0800 (PST)
In-Reply-To: <20111219142943.GD27772@andromeda.dapyr.net>
References: <CAOMqctShNFqe47w1orEPMCqvDORy5yxh=Gy33e02fyQYrz4nkw@mail.gmail.com>
	<20111219142943.GD27772@andromeda.dapyr.net>
From: Michal Suchanek <hramrach@centrum.cz>
Date: Mon, 19 Dec 2011 16:20:17 +0100
X-Google-Sender-Auth: x0_tvwrpWl8HDMfFSqLUIB__xFw
Message-ID: <CAOMqctSW87AmM8UTC34_ZwDhipnZUMmxyxiBix+EMAmi7hn1hg@mail.gmail.com>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] UDP checksums broken in Dom0 -> DomU vif transfer
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gMTkgRGVjZW1iZXIgMjAxMSAxNToyOSwgS29ucmFkIFJ6ZXN6dXRlayBXaWxrIDxrb25yYWRA
ZGFybm9rLm9yZz4gd3JvdGU6Cj4gT24gTW9uLCBEZWMgMTksIDIwMTEgYXQgMTA6Mjc6MzZBTSAr
MDEwMCwgTWljaGFsIFN1Y2hhbmVrIHdyb3RlOgo+PiBIZWxsbywKPj4KPj4gd2hlbiBJIGJvb3Qg
RG9tVSB3aGljaCB1c2VzIERIQ1AgdG8gY29uZmlndXJlIElQdjQgYWRkcmVzcyBpdCBkb2VzCj4K
PiBZb3UgZGlkbid0IHNheSB3aGF0IHZlcnNpb24gb2YgRG9tVSB5b3UgYXJlIHJ1bm5pbmc/IElz
IGl0IDMuMT8KCkkgaGF2ZSB0aGlzIHByb2JsZW0gaW4gMi42LjMyIGFuZCAzLjEga2VybmVscy4K
Cj4+IG5ldmVyIGdldCBhIGxlYXNlLgo+Pgo+PiBUaGUgcGFja2V0cyB0cmF2ZWwgdG8gRG9tMCB3
aGVyZSB0aGUgZGhjcCBzZXJ2ZXIgcmVjZWl2ZXMgdGhlbSwgc2VuZHMKPj4gYSByZXBseSwgdGhh
dCB0cmF2ZWxzIHRvIERvbVUgd2hlcmUgZGhjbGllbnQgcmVjZWl2ZXMgaXQsIHNheXMgdGhlCj4+
IGNoZWNrc3VtIGlzIGludmFsaWQsIGFuZCBkaXNjYXJkcyBpdC4KPj4KPj4gVGhlIHByb2JsZW0g
aXMgZG9jdW1lbnRlZCBoZXJlOgo+Pgo+PiBodHRwOi8vb2xkLWxpc3QtYXJjaGl2ZXMueGVuLm9y
Zy9hcmNoaXZlcy9odG1sL3hlbi11c2Vycy8yMDA2LTAyL21zZzAwMTUyLmh0bWwKPj4gaHR0cDov
L29sZC1saXN0LWFyY2hpdmVzLnhlbi5vcmcvYXJjaGl2ZXMvaHRtbC94ZW4tZGV2ZWwvMjAxMS0w
NC9tc2cwMTIzNS5odG1sCj4+IGh0dHA6Ly9idWd6aWxsYS54ZW5zb3VyY2UuY29tL2J1Z3ppbGxh
L3Nob3dfYnVnLmNnaT9pZD0xNjU1Cj4+Cj4+IFRoZSBmaXggaXMgdG8gdHVybiBvZmYgVURQIGNo
ZWNrc3VtIG9mZmxvYWRpbmcgb24gdGhlIHZpZiBpbnRlcmZhY2UgaW4KPj4gRG9tMCBhcyBkb2N1
bWVudGVkIGluIHRoZSBhYm92ZSBtYWlsOgo+Pgo+PiBJIGVkaXRlZCAvZXRjL3hlbi9zY3JpcHRz
L25ldHdvcmstYnJpZGdlLAo+PiBhZGRpbmcgdGhpcyBjb21tYW5kIHRvIHRoZSBlbmQgb2YgdGhl
IG9wX3N0YXJ0KCkgZnVuY3Rpb246Cj4+Cj4+IMKgIMKgIMKgIMKgIGFkZF90b19icmlkZ2UyICR7
YnJpZGdlfSAke3BkZXZ9Cj4+IMKgIMKgIMKgIMKgIGRvX2lmdXAgJHtuZXRkZXZ9Cj4+ICsgwqAg
wqAgwqAgIyBkaXNhYmxlIGlwIGNoZWNrc3VtIG9mZmxvYWRpbmcgZm9yIHZldGggZGV2aWNlCj4+
ICsgwqAgwqAgwqAgZXRodG9vbCAtSyAke25ldGRldn0gdHggb2ZmCj4+IMKgIMKgIGVsc2UKPj4g
wqAgwqAgwqAgwqAgIyBvbGQgc3R5bGUgd2l0aG91dCAke3ZkZXZ9Cj4+Cj4+IE5vdGU6IEkgYW0g
bm90IHN1cmUgd2hpY2ggcGF0aCBpcyB0YWtlbiB0aHJvdWdoIHRoZSBzY3JpcHQsIEkgc2V0IHRo
ZQo+PiBwYXJhbWV0ZXIgbWFudWFsbHkgd2l0aCBldGh0b29sIGJlZm9yZSBJIGZvdW5kIHRoaXMg
cGF0Y2guCj4+Cj4+IEl0IHNvbWUgc29sdXRpb25zIHN1Z2dlc3QgdG8gdHVybiBvZmYgVURQIGNo
ZWNrc3VtIG9mZmxvYWRpbmcgaW4gdGhlCj4+IERvbVUgYXMgd2VsbCBidXQgaXQgZG9lcyBub3Qg
c2VlbSB0byBiZSBuZWNlc3Nhcnkgc2luY2UgdGhlIHBhY2tldHMKPj4gd291bGQgdHJhdmVsIHRv
IHRoZSBkaGNwIHNlcnZlciBhbmQgaXQgd291bGQgcmVwbHkgdG8gdGhlbS4KPj4KPj4gU29tZSBw
ZW9wbGUgc2F5IHRoaXMgaXMgd29ya2luZyBmb3IgdGhlbS4KPj4KPj4gSSBzdXNwZWN0IHRoaXMg
aXMgYmVjYXVzZSBzb21lIExpbnV4IGRpc3RyaWJ1dGlvbnMgYWxyZWFkeSBjYXJyeSB0aGlzIHBh
dGNoLgo+Pgo+PiBBbnkgcmVhc29uIHdoeSB0aGlzIGNhbid0IGJlIGZpeGVkIGluIFhlbiB1cHN0
cmVhbT8KPgo+IEl0IHNob3VsZCBiZSBmaXhlZCBpbiB0aGUga2VybmVsIGFuZCBJIHRoaW5rIGl0
IGlzIGZpeGVkLiBEaWQgeW91IGhhdmUKPiB0aGlzIHByb2JsZW0gd2l0aCBhIDMuMSBvciAzLjAg
a2VybmVsPwoKQXBwYXJlbnRseSBpdCBpcyBub3QgZml4ZWQuCgpEbyB5b3UgaGF2ZSBoYXNoIG9m
IHRoZSBMaW51eCB1cHN0cmVhbSBjb21taXQgdGhhdCBmaXhlcyBpdD8KClRoYW5rcwoKTWljaGFs
CgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2
ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tCmh0dHA6Ly9saXN0
cy54ZW5zb3VyY2UuY29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Mon Dec 19 15:21:03 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 15:21:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rcf1F-0006DK-G1; Mon, 19 Dec 2011 15:20:49 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <hramrach@gmail.com>) id 1Rcf1E-0006Cv-Bn
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 15:20:48 +0000
X-Env-Sender: hramrach@gmail.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1324308039!6111987!1
X-Originating-IP: [209.85.160.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25960 invoked from network); 19 Dec 2011 15:20:41 -0000
Received: from mail-pw0-f43.google.com (HELO mail-pw0-f43.google.com)
	(209.85.160.43)
	by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Dec 2011 15:20:41 -0000
Received: by pbbb11 with SMTP id b11so20184569pbb.30
	for <xen-devel@lists.xensource.com>;
	Mon, 19 Dec 2011 07:20:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:from:date
	:x-google-sender-auth:message-id:subject:to:cc:content-type
	:content-transfer-encoding;
	bh=jXVLCTWePP9OB7DU+2Io6idiINk7UCXgWT1W046Hk4Q=;
	b=ldEFYVS7NV3xshH5qYk0QGOmTqi18FWaJq6aAohxFwj50OGJQmXHlWheLVDwcm64oK
	xZr1tO1IEVSTG0XpZGOAoEYYxrGQ2ifaKbmKPW3eDNbc8jHv4ja4uIloirmfJnAb2SNO
	JHXWYnnJtp7x2al1UnLDY/uTE5Xf/Jga+Y2B4=
Received: by 10.68.212.200 with SMTP id nm8mr39248593pbc.28.1324308038346;
	Mon, 19 Dec 2011 07:20:38 -0800 (PST)
MIME-Version: 1.0
Received: by 10.143.60.18 with HTTP; Mon, 19 Dec 2011 07:20:17 -0800 (PST)
In-Reply-To: <20111219142943.GD27772@andromeda.dapyr.net>
References: <CAOMqctShNFqe47w1orEPMCqvDORy5yxh=Gy33e02fyQYrz4nkw@mail.gmail.com>
	<20111219142943.GD27772@andromeda.dapyr.net>
From: Michal Suchanek <hramrach@centrum.cz>
Date: Mon, 19 Dec 2011 16:20:17 +0100
X-Google-Sender-Auth: x0_tvwrpWl8HDMfFSqLUIB__xFw
Message-ID: <CAOMqctSW87AmM8UTC34_ZwDhipnZUMmxyxiBix+EMAmi7hn1hg@mail.gmail.com>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] UDP checksums broken in Dom0 -> DomU vif transfer
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gMTkgRGVjZW1iZXIgMjAxMSAxNToyOSwgS29ucmFkIFJ6ZXN6dXRlayBXaWxrIDxrb25yYWRA
ZGFybm9rLm9yZz4gd3JvdGU6Cj4gT24gTW9uLCBEZWMgMTksIDIwMTEgYXQgMTA6Mjc6MzZBTSAr
MDEwMCwgTWljaGFsIFN1Y2hhbmVrIHdyb3RlOgo+PiBIZWxsbywKPj4KPj4gd2hlbiBJIGJvb3Qg
RG9tVSB3aGljaCB1c2VzIERIQ1AgdG8gY29uZmlndXJlIElQdjQgYWRkcmVzcyBpdCBkb2VzCj4K
PiBZb3UgZGlkbid0IHNheSB3aGF0IHZlcnNpb24gb2YgRG9tVSB5b3UgYXJlIHJ1bm5pbmc/IElz
IGl0IDMuMT8KCkkgaGF2ZSB0aGlzIHByb2JsZW0gaW4gMi42LjMyIGFuZCAzLjEga2VybmVscy4K
Cj4+IG5ldmVyIGdldCBhIGxlYXNlLgo+Pgo+PiBUaGUgcGFja2V0cyB0cmF2ZWwgdG8gRG9tMCB3
aGVyZSB0aGUgZGhjcCBzZXJ2ZXIgcmVjZWl2ZXMgdGhlbSwgc2VuZHMKPj4gYSByZXBseSwgdGhh
dCB0cmF2ZWxzIHRvIERvbVUgd2hlcmUgZGhjbGllbnQgcmVjZWl2ZXMgaXQsIHNheXMgdGhlCj4+
IGNoZWNrc3VtIGlzIGludmFsaWQsIGFuZCBkaXNjYXJkcyBpdC4KPj4KPj4gVGhlIHByb2JsZW0g
aXMgZG9jdW1lbnRlZCBoZXJlOgo+Pgo+PiBodHRwOi8vb2xkLWxpc3QtYXJjaGl2ZXMueGVuLm9y
Zy9hcmNoaXZlcy9odG1sL3hlbi11c2Vycy8yMDA2LTAyL21zZzAwMTUyLmh0bWwKPj4gaHR0cDov
L29sZC1saXN0LWFyY2hpdmVzLnhlbi5vcmcvYXJjaGl2ZXMvaHRtbC94ZW4tZGV2ZWwvMjAxMS0w
NC9tc2cwMTIzNS5odG1sCj4+IGh0dHA6Ly9idWd6aWxsYS54ZW5zb3VyY2UuY29tL2J1Z3ppbGxh
L3Nob3dfYnVnLmNnaT9pZD0xNjU1Cj4+Cj4+IFRoZSBmaXggaXMgdG8gdHVybiBvZmYgVURQIGNo
ZWNrc3VtIG9mZmxvYWRpbmcgb24gdGhlIHZpZiBpbnRlcmZhY2UgaW4KPj4gRG9tMCBhcyBkb2N1
bWVudGVkIGluIHRoZSBhYm92ZSBtYWlsOgo+Pgo+PiBJIGVkaXRlZCAvZXRjL3hlbi9zY3JpcHRz
L25ldHdvcmstYnJpZGdlLAo+PiBhZGRpbmcgdGhpcyBjb21tYW5kIHRvIHRoZSBlbmQgb2YgdGhl
IG9wX3N0YXJ0KCkgZnVuY3Rpb246Cj4+Cj4+IMKgIMKgIMKgIMKgIGFkZF90b19icmlkZ2UyICR7
YnJpZGdlfSAke3BkZXZ9Cj4+IMKgIMKgIMKgIMKgIGRvX2lmdXAgJHtuZXRkZXZ9Cj4+ICsgwqAg
wqAgwqAgIyBkaXNhYmxlIGlwIGNoZWNrc3VtIG9mZmxvYWRpbmcgZm9yIHZldGggZGV2aWNlCj4+
ICsgwqAgwqAgwqAgZXRodG9vbCAtSyAke25ldGRldn0gdHggb2ZmCj4+IMKgIMKgIGVsc2UKPj4g
wqAgwqAgwqAgwqAgIyBvbGQgc3R5bGUgd2l0aG91dCAke3ZkZXZ9Cj4+Cj4+IE5vdGU6IEkgYW0g
bm90IHN1cmUgd2hpY2ggcGF0aCBpcyB0YWtlbiB0aHJvdWdoIHRoZSBzY3JpcHQsIEkgc2V0IHRo
ZQo+PiBwYXJhbWV0ZXIgbWFudWFsbHkgd2l0aCBldGh0b29sIGJlZm9yZSBJIGZvdW5kIHRoaXMg
cGF0Y2guCj4+Cj4+IEl0IHNvbWUgc29sdXRpb25zIHN1Z2dlc3QgdG8gdHVybiBvZmYgVURQIGNo
ZWNrc3VtIG9mZmxvYWRpbmcgaW4gdGhlCj4+IERvbVUgYXMgd2VsbCBidXQgaXQgZG9lcyBub3Qg
c2VlbSB0byBiZSBuZWNlc3Nhcnkgc2luY2UgdGhlIHBhY2tldHMKPj4gd291bGQgdHJhdmVsIHRv
IHRoZSBkaGNwIHNlcnZlciBhbmQgaXQgd291bGQgcmVwbHkgdG8gdGhlbS4KPj4KPj4gU29tZSBw
ZW9wbGUgc2F5IHRoaXMgaXMgd29ya2luZyBmb3IgdGhlbS4KPj4KPj4gSSBzdXNwZWN0IHRoaXMg
aXMgYmVjYXVzZSBzb21lIExpbnV4IGRpc3RyaWJ1dGlvbnMgYWxyZWFkeSBjYXJyeSB0aGlzIHBh
dGNoLgo+Pgo+PiBBbnkgcmVhc29uIHdoeSB0aGlzIGNhbid0IGJlIGZpeGVkIGluIFhlbiB1cHN0
cmVhbT8KPgo+IEl0IHNob3VsZCBiZSBmaXhlZCBpbiB0aGUga2VybmVsIGFuZCBJIHRoaW5rIGl0
IGlzIGZpeGVkLiBEaWQgeW91IGhhdmUKPiB0aGlzIHByb2JsZW0gd2l0aCBhIDMuMSBvciAzLjAg
a2VybmVsPwoKQXBwYXJlbnRseSBpdCBpcyBub3QgZml4ZWQuCgpEbyB5b3UgaGF2ZSBoYXNoIG9m
IHRoZSBMaW51eCB1cHN0cmVhbSBjb21taXQgdGhhdCBmaXhlcyBpdD8KClRoYW5rcwoKTWljaGFs
CgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2
ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tCmh0dHA6Ly9saXN0
cy54ZW5zb3VyY2UuY29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Mon Dec 19 15:25:37 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 15:25:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rcf5g-0006cm-Tg; Mon, 19 Dec 2011 15:25:24 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony@codemonkey.ws>) id 1Rcf5f-0006cN-RO
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 15:25:24 +0000
X-Env-Sender: anthony@codemonkey.ws
X-Msg-Ref: server-4.tower-27.messagelabs.com!1324308281!53043445!1
X-Originating-IP: [209.85.160.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31272 invoked from network); 19 Dec 2011 15:24:42 -0000
Received: from mail-gy0-f171.google.com (HELO mail-gy0-f171.google.com)
	(209.85.160.171)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Dec 2011 15:24:42 -0000
Received: by ghy10 with SMTP id 10so68519430ghy.30
	for <xen-devel@lists.xensource.com>;
	Mon, 19 Dec 2011 07:25:16 -0800 (PST)
Received: by 10.50.12.161 with SMTP id z1mr27810804igb.85.1324308316290;
	Mon, 19 Dec 2011 07:25:16 -0800 (PST)
Received: from [192.168.0.103] (cpe-70-123-132-139.austin.res.rr.com.
	[70.123.132.139])
	by mx.google.com with ESMTPS id lu10sm31586650igc.0.2011.12.19.07.25.13
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 19 Dec 2011 07:25:15 -0800 (PST)
Message-ID: <4EEF5757.6040607@codemonkey.ws>
Date: Mon, 19 Dec 2011 09:25:11 -0600
From: Anthony Liguori <anthony@codemonkey.ws>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.23) Gecko/20110922 Lightning/1.0b2 Thunderbird/3.1.15
MIME-Version: 1.0
To: Avi Kivity <avi@redhat.com>
References: <1324304024-11220-1-git-send-email-avi@redhat.com>	<1324304024-11220-2-git-send-email-avi@redhat.com>	<4EEF4F1E.9080104@codemonkey.ws>	<4EEF5263.8070004@redhat.com>
	<4EEF53D1.5040302@codemonkey.ws> <4EEF5591.2010207@redhat.com>
In-Reply-To: <4EEF5591.2010207@redhat.com>
Cc: xen-devel@lists.xensource.com, "Michael S. Tsirkin" <mst@redhat.com>,
	qemu-devel@nongnu.org, kvm@vger.kernel.org,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH 01/23] memory: introduce
	memory_region_find()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="windows-1252"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 12/19/2011 09:17 AM, Avi Kivity wrote:
> On 12/19/2011 05:10 PM, Anthony Liguori wrote:
>> On 12/19/2011 09:04 AM, Avi Kivity wrote:
>>> On 12/19/2011 04:50 PM, Anthony Liguori wrote:
>>>>> +static int cmp_flatrange_addr(const void *_addr, const void *_fr)
>>>>> +{
>>>>> +    const AddrRange *addr =3D _addr;
>>>>> +    const FlatRange *fr =3D _fr;
>>>>
>>>>
>>>> Please don't prefix with an underscore.
>>>
>>> Why not?  It's legal according to the standards, if that's your concern
>>> (only _[_A-Z]+ are reserved).
>>
>> http://www.gnu.org/s/hello/manual/libc/Reserved-Names.html
>>
>> "In addition to the names documented in this manual, reserved names
>> include all external identifiers (global functions and variables) that
>> begin with an underscore (=91_=92)"
>>
>> Now that might just mean that you're shadowing a global name, so maybe
>> that's okay, but I think it's easier to just enforce a consistent rule
>> of, "don't start identifiers with an underscore".
>
> I rather like the pattern
>
>     void callback(void *_foo)
>     {
>           Foo *foo =3D _foo;
>
>           ...
>     }
>
> If the consensus is that we don't want it, I'll change it, but I do
> think it's useful.

I dislike enforcing coding style but it's a necessary evil. I greater prefe=
r =

simple rules to subtle ones as it creates less confusion so I'd prefer you =

change this.

>
>>>>> +MemoryRegionSection memory_region_find(MemoryRegion *address_space,
>>>>> +                                       target_phys_addr_t addr,
>>>>> uint64_t size);
>>>>
>>>>
>>>> Returning structs by value is a bit unexpected.
>>>
>>> It's just prejudice, here's the call sequence:
>>
>> It's not about whether it's fast or slow.  It's just unexpected.
>
> It's plain C, I don't see why it's so unexpected.
>
>>
>> Instead of returning a NULL pointer on error, you set .mr to NULL if
>> an error occurs (which isn't documented by the comment btw).
>> Returning a pointer, or taking a pointer and returning a 0/-1 return
>> value makes for a more consistent semantic with the rest of the code
>> base.
>>
>
> How can I return a pointer?  If I allocate it, someone has to free it.
> If I pass it as a parameter, we end up with a silly looking calling
> convention.  If I return an error code, the caller has to set up an
> additional variable.
>
> The natural check is section.size which is always meaningful -
> memory_region_find() returns a subrange of the input, which may be
> zero.  You're right that I should document it (and I should use it
> consistently).

I'm not going to make a fuss over something like this so if you really pref=
er =

this style, I'm not going to object strongly.

But it should be at least be documented and used consistently.

Regards,

Anthony Liguori



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 15:25:37 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 15:25:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rcf5g-0006cm-Tg; Mon, 19 Dec 2011 15:25:24 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony@codemonkey.ws>) id 1Rcf5f-0006cN-RO
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 15:25:24 +0000
X-Env-Sender: anthony@codemonkey.ws
X-Msg-Ref: server-4.tower-27.messagelabs.com!1324308281!53043445!1
X-Originating-IP: [209.85.160.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31272 invoked from network); 19 Dec 2011 15:24:42 -0000
Received: from mail-gy0-f171.google.com (HELO mail-gy0-f171.google.com)
	(209.85.160.171)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Dec 2011 15:24:42 -0000
Received: by ghy10 with SMTP id 10so68519430ghy.30
	for <xen-devel@lists.xensource.com>;
	Mon, 19 Dec 2011 07:25:16 -0800 (PST)
Received: by 10.50.12.161 with SMTP id z1mr27810804igb.85.1324308316290;
	Mon, 19 Dec 2011 07:25:16 -0800 (PST)
Received: from [192.168.0.103] (cpe-70-123-132-139.austin.res.rr.com.
	[70.123.132.139])
	by mx.google.com with ESMTPS id lu10sm31586650igc.0.2011.12.19.07.25.13
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 19 Dec 2011 07:25:15 -0800 (PST)
Message-ID: <4EEF5757.6040607@codemonkey.ws>
Date: Mon, 19 Dec 2011 09:25:11 -0600
From: Anthony Liguori <anthony@codemonkey.ws>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.23) Gecko/20110922 Lightning/1.0b2 Thunderbird/3.1.15
MIME-Version: 1.0
To: Avi Kivity <avi@redhat.com>
References: <1324304024-11220-1-git-send-email-avi@redhat.com>	<1324304024-11220-2-git-send-email-avi@redhat.com>	<4EEF4F1E.9080104@codemonkey.ws>	<4EEF5263.8070004@redhat.com>
	<4EEF53D1.5040302@codemonkey.ws> <4EEF5591.2010207@redhat.com>
In-Reply-To: <4EEF5591.2010207@redhat.com>
Cc: xen-devel@lists.xensource.com, "Michael S. Tsirkin" <mst@redhat.com>,
	qemu-devel@nongnu.org, kvm@vger.kernel.org,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH 01/23] memory: introduce
	memory_region_find()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="windows-1252"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 12/19/2011 09:17 AM, Avi Kivity wrote:
> On 12/19/2011 05:10 PM, Anthony Liguori wrote:
>> On 12/19/2011 09:04 AM, Avi Kivity wrote:
>>> On 12/19/2011 04:50 PM, Anthony Liguori wrote:
>>>>> +static int cmp_flatrange_addr(const void *_addr, const void *_fr)
>>>>> +{
>>>>> +    const AddrRange *addr =3D _addr;
>>>>> +    const FlatRange *fr =3D _fr;
>>>>
>>>>
>>>> Please don't prefix with an underscore.
>>>
>>> Why not?  It's legal according to the standards, if that's your concern
>>> (only _[_A-Z]+ are reserved).
>>
>> http://www.gnu.org/s/hello/manual/libc/Reserved-Names.html
>>
>> "In addition to the names documented in this manual, reserved names
>> include all external identifiers (global functions and variables) that
>> begin with an underscore (=91_=92)"
>>
>> Now that might just mean that you're shadowing a global name, so maybe
>> that's okay, but I think it's easier to just enforce a consistent rule
>> of, "don't start identifiers with an underscore".
>
> I rather like the pattern
>
>     void callback(void *_foo)
>     {
>           Foo *foo =3D _foo;
>
>           ...
>     }
>
> If the consensus is that we don't want it, I'll change it, but I do
> think it's useful.

I dislike enforcing coding style but it's a necessary evil. I greater prefe=
r =

simple rules to subtle ones as it creates less confusion so I'd prefer you =

change this.

>
>>>>> +MemoryRegionSection memory_region_find(MemoryRegion *address_space,
>>>>> +                                       target_phys_addr_t addr,
>>>>> uint64_t size);
>>>>
>>>>
>>>> Returning structs by value is a bit unexpected.
>>>
>>> It's just prejudice, here's the call sequence:
>>
>> It's not about whether it's fast or slow.  It's just unexpected.
>
> It's plain C, I don't see why it's so unexpected.
>
>>
>> Instead of returning a NULL pointer on error, you set .mr to NULL if
>> an error occurs (which isn't documented by the comment btw).
>> Returning a pointer, or taking a pointer and returning a 0/-1 return
>> value makes for a more consistent semantic with the rest of the code
>> base.
>>
>
> How can I return a pointer?  If I allocate it, someone has to free it.
> If I pass it as a parameter, we end up with a silly looking calling
> convention.  If I return an error code, the caller has to set up an
> additional variable.
>
> The natural check is section.size which is always meaningful -
> memory_region_find() returns a subrange of the input, which may be
> zero.  You're right that I should document it (and I should use it
> consistently).

I'm not going to make a fuss over something like this so if you really pref=
er =

this style, I'm not going to object strongly.

But it should be at least be documented and used consistently.

Regards,

Anthony Liguori



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 15:26:25 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 15:26:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rcf6V-0006jr-Is; Mon, 19 Dec 2011 15:26:15 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <hui.lv@intel.com>) id 1Rcf6T-0006iv-Fy
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 15:26:13 +0000
X-Env-Sender: hui.lv@intel.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1324308366!2535571!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDI5ODkwNA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17600 invoked from network); 19 Dec 2011 15:26:07 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-4.tower-21.messagelabs.com with SMTP;
	19 Dec 2011 15:26:07 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga102.fm.intel.com with ESMTP; 19 Dec 2011 07:26:05 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="97935261"
Received: from pgsmsx603.gar.corp.intel.com ([10.221.43.87])
	by fmsmga001.fm.intel.com with ESMTP; 19 Dec 2011 07:26:04 -0800
Received: from pgsmsx104.gar.corp.intel.com (10.221.44.91) by
	pgsmsx603.gar.corp.intel.com (10.221.43.87) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Mon, 19 Dec 2011 23:25:05 +0800
Received: from shsmsx601.ccr.corp.intel.com (10.239.4.112) by
	PGSMSX104.gar.corp.intel.com (10.221.44.91) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Mon, 19 Dec 2011 23:25:04 +0800
Received: from shsmsx502.ccr.corp.intel.com ([10.239.4.96]) by
	shsmsx601.ccr.corp.intel.com ([10.239.4.112]) with mapi;
	Mon, 19 Dec 2011 23:25:03 +0800
From: "Lv, Hui" <hui.lv@intel.com>
To: Jan Beulich <JBeulich@suse.com>, George Dunlap
	<George.Dunlap@eu.citrix.com>
Date: Mon, 19 Dec 2011 23:25:02 +0800
Thread-Topic: [Xen-devel] [PATCH v2] xen/credit scheduler; Use delay to
	control scheduling frequency
Thread-Index: Acy+Xr08AkCsIXLkQ9+yhvoU2aN8sAAAhtFw
Message-ID: <C10D3FB0CD45994C8A51FEC1227CE22F39412A972F@shsmsx502.ccr.corp.intel.com>
References: <C10D3FB0CD45994C8A51FEC1227CE22F37CC284376@shsmsx502.ccr.corp.intel.com>
	<4EEF02E20200007800068C60@nat28.tlf.novell.com>
	<CAFLBxZb3Yc7G4QzEXKdfrVkoz1XGv09zTxCQCC4Dnkr-6M5K5Q@mail.gmail.com>
	<4EEF36A60200007800068D43@nat28.tlf.novell.com>
	<CAFLBxZahyAJ5Y7+eGGCkoOKZZGQ4rYwdZutyjAMH2CcQhDkcZw@mail.gmail.com>
	<4EEF5F720200007800068DB3@nat28.tlf.novell.com>
In-Reply-To: <4EEF5F720200007800068DB3@nat28.tlf.novell.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "Tian, Kevin" <kevin.tian@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"keir@xen.org" <keir@xen.org>, "Dong, Eddie" <eddie.dong@intel.com>, "Duan,
	Jiangang" <jiangang.duan@intel.com>, "Yu, Zhidong" <zhidong.yu@intel.com>
Subject: Re: [Xen-devel] [PATCH v2] xen/credit scheduler;
 Use delay to control scheduling frequency
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


> Overriding the rate limit by the time slice isn't the right thing either, as that
> (the way I "read" it) means there's no rate limiting at all.
> What "rate limit" to me means is preventing quickly switching away from a
> vCPU recently scheduled without extending its (remaining) time slice, i.e. in any
> place a respective evaluation is done the shorter of the two should be used.
> 
> Jan

So the basic thing is to avoid "time slice" < "rate limit", happen.
I really don't understand why people want a 1ms time slice, but set the rate_limit to 5000(us), that is insubstantial.

If, this unfortunately happens, I prefer to put "rate_limit" at higher priority, which means extending the running time slice.
Some warnings should be put before the parameter of sched_ratelimit_us to avoid this.
Is this reasonable?


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 15:26:25 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 15:26:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rcf6V-0006jr-Is; Mon, 19 Dec 2011 15:26:15 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <hui.lv@intel.com>) id 1Rcf6T-0006iv-Fy
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 15:26:13 +0000
X-Env-Sender: hui.lv@intel.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1324308366!2535571!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDI5ODkwNA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17600 invoked from network); 19 Dec 2011 15:26:07 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-4.tower-21.messagelabs.com with SMTP;
	19 Dec 2011 15:26:07 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga102.fm.intel.com with ESMTP; 19 Dec 2011 07:26:05 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="97935261"
Received: from pgsmsx603.gar.corp.intel.com ([10.221.43.87])
	by fmsmga001.fm.intel.com with ESMTP; 19 Dec 2011 07:26:04 -0800
Received: from pgsmsx104.gar.corp.intel.com (10.221.44.91) by
	pgsmsx603.gar.corp.intel.com (10.221.43.87) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Mon, 19 Dec 2011 23:25:05 +0800
Received: from shsmsx601.ccr.corp.intel.com (10.239.4.112) by
	PGSMSX104.gar.corp.intel.com (10.221.44.91) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Mon, 19 Dec 2011 23:25:04 +0800
Received: from shsmsx502.ccr.corp.intel.com ([10.239.4.96]) by
	shsmsx601.ccr.corp.intel.com ([10.239.4.112]) with mapi;
	Mon, 19 Dec 2011 23:25:03 +0800
From: "Lv, Hui" <hui.lv@intel.com>
To: Jan Beulich <JBeulich@suse.com>, George Dunlap
	<George.Dunlap@eu.citrix.com>
Date: Mon, 19 Dec 2011 23:25:02 +0800
Thread-Topic: [Xen-devel] [PATCH v2] xen/credit scheduler; Use delay to
	control scheduling frequency
Thread-Index: Acy+Xr08AkCsIXLkQ9+yhvoU2aN8sAAAhtFw
Message-ID: <C10D3FB0CD45994C8A51FEC1227CE22F39412A972F@shsmsx502.ccr.corp.intel.com>
References: <C10D3FB0CD45994C8A51FEC1227CE22F37CC284376@shsmsx502.ccr.corp.intel.com>
	<4EEF02E20200007800068C60@nat28.tlf.novell.com>
	<CAFLBxZb3Yc7G4QzEXKdfrVkoz1XGv09zTxCQCC4Dnkr-6M5K5Q@mail.gmail.com>
	<4EEF36A60200007800068D43@nat28.tlf.novell.com>
	<CAFLBxZahyAJ5Y7+eGGCkoOKZZGQ4rYwdZutyjAMH2CcQhDkcZw@mail.gmail.com>
	<4EEF5F720200007800068DB3@nat28.tlf.novell.com>
In-Reply-To: <4EEF5F720200007800068DB3@nat28.tlf.novell.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "Tian, Kevin" <kevin.tian@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"keir@xen.org" <keir@xen.org>, "Dong, Eddie" <eddie.dong@intel.com>, "Duan,
	Jiangang" <jiangang.duan@intel.com>, "Yu, Zhidong" <zhidong.yu@intel.com>
Subject: Re: [Xen-devel] [PATCH v2] xen/credit scheduler;
 Use delay to control scheduling frequency
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


> Overriding the rate limit by the time slice isn't the right thing either, as that
> (the way I "read" it) means there's no rate limiting at all.
> What "rate limit" to me means is preventing quickly switching away from a
> vCPU recently scheduled without extending its (remaining) time slice, i.e. in any
> place a respective evaluation is done the shorter of the two should be used.
> 
> Jan

So the basic thing is to avoid "time slice" < "rate limit", happen.
I really don't understand why people want a 1ms time slice, but set the rate_limit to 5000(us), that is insubstantial.

If, this unfortunately happens, I prefer to put "rate_limit" at higher priority, which means extending the running time slice.
Some warnings should be put before the parameter of sched_ratelimit_us to avoid this.
Is this reasonable?


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 15:28:27 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 15: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.xensource.com>)
	id 1Rcf8R-0006yn-4X; Mon, 19 Dec 2011 15:28:15 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <avi@redhat.com>) id 1Rcf8Q-0006yP-9d
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 15:28:14 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1324308469!49900286!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDY0OTI=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27966 invoked from network); 19 Dec 2011 15:27:50 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-11.tower-27.messagelabs.com with SMTP;
	19 Dec 2011 15:27:50 -0000
Received: from int-mx01.intmail.prod.int.phx2.redhat.com
	(int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id pBJFS59M000491
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 19 Dec 2011 10:28:05 -0500
Received: from balrog.usersys.redhat.com (dhcp-4-24.tlv.redhat.com
	[10.35.4.24])
	by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP
	id pBJFS2gI006331; Mon, 19 Dec 2011 10:28:03 -0500
Message-ID: <4EEF5802.5090902@redhat.com>
Date: Mon, 19 Dec 2011 17:28:02 +0200
From: Avi Kivity <avi@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:8.0) Gecko/20111115 Thunderbird/8.0
MIME-Version: 1.0
To: Anthony Liguori <anthony@codemonkey.ws>
References: <1324304024-11220-1-git-send-email-avi@redhat.com>	<1324304024-11220-2-git-send-email-avi@redhat.com>	<4EEF4F1E.9080104@codemonkey.ws>	<4EEF5263.8070004@redhat.com>
	<4EEF53D1.5040302@codemonkey.ws> <4EEF5591.2010207@redhat.com>
	<4EEF5757.6040607@codemonkey.ws>
In-Reply-To: <4EEF5757.6040607@codemonkey.ws>
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.11
Cc: xen-devel@lists.xensource.com, "Michael S. Tsirkin" <mst@redhat.com>,
	qemu-devel@nongnu.org, kvm@vger.kernel.org,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH 01/23] memory: introduce
	memory_region_find()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 12/19/2011 05:25 PM, Anthony Liguori wrote:
>> I rather like the pattern
>>
>>     void callback(void *_foo)
>>     {
>>           Foo *foo = _foo;
>>
>>           ...
>>     }
>>
>> If the consensus is that we don't want it, I'll change it, but I do
>> think it's useful.
>
>
> I dislike enforcing coding style but it's a necessary evil. I greater
> prefer simple rules to subtle ones as it creates less confusion so I'd
> prefer you change this.

Okay.

>> How can I return a pointer?  If I allocate it, someone has to free it.
>> If I pass it as a parameter, we end up with a silly looking calling
>> convention.  If I return an error code, the caller has to set up an
>> additional variable.
>>
>> The natural check is section.size which is always meaningful -
>> memory_region_find() returns a subrange of the input, which may be
>> zero.  You're right that I should document it (and I should use it
>> consistently).
>
> I'm not going to make a fuss over something like this so if you really
> prefer this style, I'm not going to object strongly.
>
> But it should be at least be documented and used consistently.

Will update both.

-- 
error compiling committee.c: too many arguments to function


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 15:28:27 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 15: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.xensource.com>)
	id 1Rcf8R-0006yn-4X; Mon, 19 Dec 2011 15:28:15 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <avi@redhat.com>) id 1Rcf8Q-0006yP-9d
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 15:28:14 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1324308469!49900286!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDY0OTI=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27966 invoked from network); 19 Dec 2011 15:27:50 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-11.tower-27.messagelabs.com with SMTP;
	19 Dec 2011 15:27:50 -0000
Received: from int-mx01.intmail.prod.int.phx2.redhat.com
	(int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id pBJFS59M000491
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 19 Dec 2011 10:28:05 -0500
Received: from balrog.usersys.redhat.com (dhcp-4-24.tlv.redhat.com
	[10.35.4.24])
	by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP
	id pBJFS2gI006331; Mon, 19 Dec 2011 10:28:03 -0500
Message-ID: <4EEF5802.5090902@redhat.com>
Date: Mon, 19 Dec 2011 17:28:02 +0200
From: Avi Kivity <avi@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:8.0) Gecko/20111115 Thunderbird/8.0
MIME-Version: 1.0
To: Anthony Liguori <anthony@codemonkey.ws>
References: <1324304024-11220-1-git-send-email-avi@redhat.com>	<1324304024-11220-2-git-send-email-avi@redhat.com>	<4EEF4F1E.9080104@codemonkey.ws>	<4EEF5263.8070004@redhat.com>
	<4EEF53D1.5040302@codemonkey.ws> <4EEF5591.2010207@redhat.com>
	<4EEF5757.6040607@codemonkey.ws>
In-Reply-To: <4EEF5757.6040607@codemonkey.ws>
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.11
Cc: xen-devel@lists.xensource.com, "Michael S. Tsirkin" <mst@redhat.com>,
	qemu-devel@nongnu.org, kvm@vger.kernel.org,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH 01/23] memory: introduce
	memory_region_find()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 12/19/2011 05:25 PM, Anthony Liguori wrote:
>> I rather like the pattern
>>
>>     void callback(void *_foo)
>>     {
>>           Foo *foo = _foo;
>>
>>           ...
>>     }
>>
>> If the consensus is that we don't want it, I'll change it, but I do
>> think it's useful.
>
>
> I dislike enforcing coding style but it's a necessary evil. I greater
> prefer simple rules to subtle ones as it creates less confusion so I'd
> prefer you change this.

Okay.

>> How can I return a pointer?  If I allocate it, someone has to free it.
>> If I pass it as a parameter, we end up with a silly looking calling
>> convention.  If I return an error code, the caller has to set up an
>> additional variable.
>>
>> The natural check is section.size which is always meaningful -
>> memory_region_find() returns a subrange of the input, which may be
>> zero.  You're right that I should document it (and I should use it
>> consistently).
>
> I'm not going to make a fuss over something like this so if you really
> prefer this style, I'm not going to object strongly.
>
> But it should be at least be documented and used consistently.

Will update both.

-- 
error compiling committee.c: too many arguments to function


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 15:37:36 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 15: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.xensource.com>)
	id 1RcfHE-0007lz-SK; Mon, 19 Dec 2011 15:37:20 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RcfHD-0007lc-NJ
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 15:37:19 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1324309033!8778826!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15423 invoked from network); 19 Dec 2011 15:37:13 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-8.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 19 Dec 2011 15:37:13 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 19 Dec 2011 15:37:13 +0000
Message-Id: <4EEF686E0200007800068DCC@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 19 Dec 2011 15:38:06 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "George Dunlap" <George.Dunlap@eu.citrix.com>, "Hui Lv" <hui.lv@intel.com>
References: <C10D3FB0CD45994C8A51FEC1227CE22F37CC284376@shsmsx502.ccr.corp.intel.com>
	<4EEF02E20200007800068C60@nat28.tlf.novell.com>
	<CAFLBxZb3Yc7G4QzEXKdfrVkoz1XGv09zTxCQCC4Dnkr-6M5K5Q@mail.gmail.com>
	<4EEF36A60200007800068D43@nat28.tlf.novell.com>
	<CAFLBxZahyAJ5Y7+eGGCkoOKZZGQ4rYwdZutyjAMH2CcQhDkcZw@mail.gmail.com>
	<4EEF5F720200007800068DB3@nat28.tlf.novell.com>
	<C10D3FB0CD45994C8A51FEC1227CE22F39412A972F@shsmsx502.ccr.corp.intel.com>
In-Reply-To: <C10D3FB0CD45994C8A51FEC1227CE22F39412A972F@shsmsx502.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Kevin Tian <kevin.tian@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"keir@xen.org" <keir@xen.org>, Eddie Dong <eddie.dong@intel.com>,
	Jiangang Duan <jiangang.duan@intel.com>, Zhidong Yu <zhidong.yu@intel.com>
Subject: Re: [Xen-devel] [PATCH v2] xen/credit scheduler;
 Use delay to control scheduling frequency
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 19.12.11 at 16:25, "Lv, Hui" <hui.lv@intel.com> wrote:
>> Overriding the rate limit by the time slice isn't the right thing either, as 
> that
>> (the way I "read" it) means there's no rate limiting at all.
>> What "rate limit" to me means is preventing quickly switching away from a
>> vCPU recently scheduled without extending its (remaining) time slice, i.e. 
> in any
>> place a respective evaluation is done the shorter of the two should be used.
>> 
>> Jan
> 
> So the basic thing is to avoid "time slice" < "rate limit", happen.
> I really don't understand why people want a 1ms time slice, but set the 
> rate_limit to 5000(us), that is insubstantial.

So if someone set the (global) rate limit value to 5000us and then,
days or weeks later, migrates a VM with a 3ms time slice to that
host, why should this be an admin mistake? To me, the rate limit is a
performance improvement, while the time slice may be (an indirect
result of) a to be enforced policy.

Jan

> If, this unfortunately happens, I prefer to put "rate_limit" at higher 
> priority, which means extending the running time slice.
> Some warnings should be put before the parameter of sched_ratelimit_us to 
> avoid this.
> Is this reasonable?




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 15:37:36 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 15: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.xensource.com>)
	id 1RcfHE-0007lz-SK; Mon, 19 Dec 2011 15:37:20 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RcfHD-0007lc-NJ
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 15:37:19 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1324309033!8778826!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15423 invoked from network); 19 Dec 2011 15:37:13 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-8.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 19 Dec 2011 15:37:13 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 19 Dec 2011 15:37:13 +0000
Message-Id: <4EEF686E0200007800068DCC@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 19 Dec 2011 15:38:06 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "George Dunlap" <George.Dunlap@eu.citrix.com>, "Hui Lv" <hui.lv@intel.com>
References: <C10D3FB0CD45994C8A51FEC1227CE22F37CC284376@shsmsx502.ccr.corp.intel.com>
	<4EEF02E20200007800068C60@nat28.tlf.novell.com>
	<CAFLBxZb3Yc7G4QzEXKdfrVkoz1XGv09zTxCQCC4Dnkr-6M5K5Q@mail.gmail.com>
	<4EEF36A60200007800068D43@nat28.tlf.novell.com>
	<CAFLBxZahyAJ5Y7+eGGCkoOKZZGQ4rYwdZutyjAMH2CcQhDkcZw@mail.gmail.com>
	<4EEF5F720200007800068DB3@nat28.tlf.novell.com>
	<C10D3FB0CD45994C8A51FEC1227CE22F39412A972F@shsmsx502.ccr.corp.intel.com>
In-Reply-To: <C10D3FB0CD45994C8A51FEC1227CE22F39412A972F@shsmsx502.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Kevin Tian <kevin.tian@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"keir@xen.org" <keir@xen.org>, Eddie Dong <eddie.dong@intel.com>,
	Jiangang Duan <jiangang.duan@intel.com>, Zhidong Yu <zhidong.yu@intel.com>
Subject: Re: [Xen-devel] [PATCH v2] xen/credit scheduler;
 Use delay to control scheduling frequency
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 19.12.11 at 16:25, "Lv, Hui" <hui.lv@intel.com> wrote:
>> Overriding the rate limit by the time slice isn't the right thing either, as 
> that
>> (the way I "read" it) means there's no rate limiting at all.
>> What "rate limit" to me means is preventing quickly switching away from a
>> vCPU recently scheduled without extending its (remaining) time slice, i.e. 
> in any
>> place a respective evaluation is done the shorter of the two should be used.
>> 
>> Jan
> 
> So the basic thing is to avoid "time slice" < "rate limit", happen.
> I really don't understand why people want a 1ms time slice, but set the 
> rate_limit to 5000(us), that is insubstantial.

So if someone set the (global) rate limit value to 5000us and then,
days or weeks later, migrates a VM with a 3ms time slice to that
host, why should this be an admin mistake? To me, the rate limit is a
performance improvement, while the time slice may be (an indirect
result of) a to be enforced policy.

Jan

> If, this unfortunately happens, I prefer to put "rate_limit" at higher 
> priority, which means extending the running time slice.
> Some warnings should be put before the parameter of sched_ratelimit_us to 
> avoid this.
> Is this reasonable?




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 15:45:39 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 15:45:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RcfP2-00083z-ST; Mon, 19 Dec 2011 15:45:24 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RcfP1-00083g-FS
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 15:45:23 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1324309476!47410227!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzA0OQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6420 invoked from network); 19 Dec 2011 15:44:36 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Dec 2011 15:44:36 -0000
X-IronPort-AV: E=Sophos;i="4.71,376,1320624000"; 
   d="scan'208";a="9560162"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Dec 2011 15:45:17 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 19 Dec 2011 15:45:17 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RcfOu-0005DF-O7;
	Mon, 19 Dec 2011 15:45:16 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RcfOu-0007Ep-C8;
	Mon, 19 Dec 2011 15:45:16 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10554-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 19 Dec 2011 15:45:16 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10554: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10554 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10554/

Regressions :-(

Tests which did not succeed and are blocking,including tests which could not be run:
 test-amd64-i386-xl-win-vcpus1 12 guest-localmigrate/x10   fail REGR. vs. 10545

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-i386-xl-win7-amd64  7 windows-install              fail  like 10531
 test-amd64-amd64-xl-sedf     14 guest-localmigrate/x10    fail REGR. vs. 10534
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64  7 windows-install              fail like 10531
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass

version targeted for testing:
 xen                  a4bffc85bb71
baseline version:
 xen                  e3daa5b58464

------------------------------------------------------------
People who touched revisions under test:
  Boris Ostrovsky <boris.ostrovsky@amd.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Paul Durrant <paul.durrant@citrix.com>
  Wei Huang <wei.huang2@amd.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   24431:a4bffc85bb71
tag:         tip
user:        Jan Beulich <jbeulich@suse.com>
date:        Mon Dec 19 09:37:52 2011 +0100
    
    x86/AMD: fold redundant parameters of cpu_has_amd_erratum()
    
    The boolean 'osvw' indicator and 'osvw_id' can be folded - the function
    can as well distinguish the non-OSVW case by checking for a negative
    'osvw_id'. That way the whole variable argument list processing is only
    needed on the legacy code path.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Boris Ostrovsky <boris.ostrovsky@amd.com>
    Acked-by: Wei Huang <wei.huang2@amd.com>
    
    
changeset:   24430:e3daa5b58464
user:        Paul Durrant <paul.durrant@citrix.com>
date:        Sun Dec 18 14:40:39 2011 +0000
    
    hvmloader: Re-name xenstore key used to save VM generation ID buffer address.
    
    Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
    
    
========================================
commit 54e24021005458ad0a361c1d83011b751726a94b
Author: Ian Jackson <ian.jackson@eu.citrix.com>
Date:   Thu Dec 8 16:38:06 2011 +0000

    qemu_get_timer: Provide a comment about the behaviour on ts==NULL
    
    Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 15:45:39 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 15:45:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RcfP2-00083z-ST; Mon, 19 Dec 2011 15:45:24 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RcfP1-00083g-FS
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 15:45:23 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1324309476!47410227!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzA0OQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6420 invoked from network); 19 Dec 2011 15:44:36 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Dec 2011 15:44:36 -0000
X-IronPort-AV: E=Sophos;i="4.71,376,1320624000"; 
   d="scan'208";a="9560162"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Dec 2011 15:45:17 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 19 Dec 2011 15:45:17 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RcfOu-0005DF-O7;
	Mon, 19 Dec 2011 15:45:16 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RcfOu-0007Ep-C8;
	Mon, 19 Dec 2011 15:45:16 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10554-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 19 Dec 2011 15:45:16 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10554: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10554 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10554/

Regressions :-(

Tests which did not succeed and are blocking,including tests which could not be run:
 test-amd64-i386-xl-win-vcpus1 12 guest-localmigrate/x10   fail REGR. vs. 10545

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-i386-xl-win7-amd64  7 windows-install              fail  like 10531
 test-amd64-amd64-xl-sedf     14 guest-localmigrate/x10    fail REGR. vs. 10534
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64  7 windows-install              fail like 10531
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass

version targeted for testing:
 xen                  a4bffc85bb71
baseline version:
 xen                  e3daa5b58464

------------------------------------------------------------
People who touched revisions under test:
  Boris Ostrovsky <boris.ostrovsky@amd.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Paul Durrant <paul.durrant@citrix.com>
  Wei Huang <wei.huang2@amd.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   24431:a4bffc85bb71
tag:         tip
user:        Jan Beulich <jbeulich@suse.com>
date:        Mon Dec 19 09:37:52 2011 +0100
    
    x86/AMD: fold redundant parameters of cpu_has_amd_erratum()
    
    The boolean 'osvw' indicator and 'osvw_id' can be folded - the function
    can as well distinguish the non-OSVW case by checking for a negative
    'osvw_id'. That way the whole variable argument list processing is only
    needed on the legacy code path.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Boris Ostrovsky <boris.ostrovsky@amd.com>
    Acked-by: Wei Huang <wei.huang2@amd.com>
    
    
changeset:   24430:e3daa5b58464
user:        Paul Durrant <paul.durrant@citrix.com>
date:        Sun Dec 18 14:40:39 2011 +0000
    
    hvmloader: Re-name xenstore key used to save VM generation ID buffer address.
    
    Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
    
    
========================================
commit 54e24021005458ad0a361c1d83011b751726a94b
Author: Ian Jackson <ian.jackson@eu.citrix.com>
Date:   Thu Dec 8 16:38:06 2011 +0000

    qemu_get_timer: Provide a comment about the behaviour on ts==NULL
    
    Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 15:53:10 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 15: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.xensource.com>)
	id 1RcfWL-0008FG-Uz; Mon, 19 Dec 2011 15:52:57 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <avi@redhat.com>) id 1RcfWK-0008F5-KZ
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 15:52:56 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1324309969!8027006!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDY0OTI=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1682 invoked from network); 19 Dec 2011 15:52:50 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-4.tower-216.messagelabs.com with SMTP;
	19 Dec 2011 15:52: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 pBJFqk08006946
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 19 Dec 2011 10:52:46 -0500
Received: from balrog.usersys.redhat.com (dhcp-4-24.tlv.redhat.com
	[10.35.4.24])
	by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id pBJFqg2j012775; Mon, 19 Dec 2011 10:52:43 -0500
Message-ID: <4EEF5DCA.8060506@redhat.com>
Date: Mon, 19 Dec 2011 17:52:42 +0200
From: Avi Kivity <avi@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:8.0) Gecko/20111115 Thunderbird/8.0
MIME-Version: 1.0
To: Anthony Liguori <anthony@codemonkey.ws>
References: <1324304024-11220-1-git-send-email-avi@redhat.com>	<1324304024-11220-2-git-send-email-avi@redhat.com>	<4EEF4F1E.9080104@codemonkey.ws>	<4EEF5263.8070004@redhat.com>
	<4EEF53D1.5040302@codemonkey.ws> <4EEF5591.2010207@redhat.com>
	<4EEF5757.6040607@codemonkey.ws> <4EEF5802.5090902@redhat.com>
In-Reply-To: <4EEF5802.5090902@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
Cc: xen-devel@lists.xensource.com, "Michael S. Tsirkin" <mst@redhat.com>,
	qemu-devel@nongnu.org, kvm@vger.kernel.org,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH 01/23] memory: introduce
	memory_region_find()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 12/19/2011 05:28 PM, Avi Kivity wrote:
> >
> > But it should be at least be documented and used consistently.
>
> Will update both.

Updated patchset in qemu-kvm.git page_desc.  Will refrain from reposting
until some time has passed for review.

-- 
error compiling committee.c: too many arguments to function


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 15:53:10 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 15: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.xensource.com>)
	id 1RcfWL-0008FG-Uz; Mon, 19 Dec 2011 15:52:57 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <avi@redhat.com>) id 1RcfWK-0008F5-KZ
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 15:52:56 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1324309969!8027006!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDY0OTI=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1682 invoked from network); 19 Dec 2011 15:52:50 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-4.tower-216.messagelabs.com with SMTP;
	19 Dec 2011 15:52: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 pBJFqk08006946
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 19 Dec 2011 10:52:46 -0500
Received: from balrog.usersys.redhat.com (dhcp-4-24.tlv.redhat.com
	[10.35.4.24])
	by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id pBJFqg2j012775; Mon, 19 Dec 2011 10:52:43 -0500
Message-ID: <4EEF5DCA.8060506@redhat.com>
Date: Mon, 19 Dec 2011 17:52:42 +0200
From: Avi Kivity <avi@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:8.0) Gecko/20111115 Thunderbird/8.0
MIME-Version: 1.0
To: Anthony Liguori <anthony@codemonkey.ws>
References: <1324304024-11220-1-git-send-email-avi@redhat.com>	<1324304024-11220-2-git-send-email-avi@redhat.com>	<4EEF4F1E.9080104@codemonkey.ws>	<4EEF5263.8070004@redhat.com>
	<4EEF53D1.5040302@codemonkey.ws> <4EEF5591.2010207@redhat.com>
	<4EEF5757.6040607@codemonkey.ws> <4EEF5802.5090902@redhat.com>
In-Reply-To: <4EEF5802.5090902@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
Cc: xen-devel@lists.xensource.com, "Michael S. Tsirkin" <mst@redhat.com>,
	qemu-devel@nongnu.org, kvm@vger.kernel.org,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH 01/23] memory: introduce
	memory_region_find()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 12/19/2011 05:28 PM, Avi Kivity wrote:
> >
> > But it should be at least be documented and used consistently.
>
> Will update both.

Updated patchset in qemu-kvm.git page_desc.  Will refrain from reposting
until some time has passed for review.

-- 
error compiling committee.c: too many arguments to function


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 15:58:41 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 15:58:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rcfbb-0008O5-N7; Mon, 19 Dec 2011 15:58:23 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <anthony@overnetdata.com>) id 1RcfbZ-0008Nx-Ty
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 15:58:22 +0000
X-Env-Sender: anthony@overnetdata.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1324310293!7866054!1
X-Originating-IP: [81.137.131.225]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31663 invoked from network); 19 Dec 2011 15:58:13 -0000
Received: from host81-137-131-225.in-addr.btopenworld.com (HELO
	zimbra.overnetdata.com) (81.137.131.225)
	by server-10.tower-182.messagelabs.com with SMTP;
	19 Dec 2011 15:58:13 -0000
Received: from localhost (localhost.localdomain [127.0.0.1])
	by zimbra.overnetdata.com (Postfix) with ESMTP id D2FB6160CB1;
	Mon, 19 Dec 2011 15:33:04 +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 WXQuA017Yfqu; Mon, 19 Dec 2011 15:32:50 +0000 (GMT)
Received: from [192.168.1.56] (unknown [192.168.1.56])
	by zimbra.overnetdata.com (Postfix) with ESMTPSA id C043F160CAE;
	Mon, 19 Dec 2011 15:32:50 +0000 (GMT)
Message-ID: <4EEF5923.1050307@overnetdata.com>
Date: Mon, 19 Dec 2011 15:32:51 +0000
From: Anthony Wright <anthony@overnetdata.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
References: <4EE0A6C7.9080603@overnetdata.com>
	<20111214213819.GD25896@andromeda.dapyr.net>
	<4EEA1818.6060106@overnetdata.com>
	<20111215211218.GA15407@andromeda.dapyr.net>
In-Reply-To: <20111215211218.GA15407@andromeda.dapyr.net>
X-Enigmail-Version: 1.3.4
Content-Type: multipart/mixed; boundary="------------040702030303010803030607"
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] VGA Passthrough crashes machine
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a multi-part message in MIME format.
--------------040702030303010803030607
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

On 15/12/2011 21:12, Konrad Rzeszutek Wilk wrote:
> On Thu, Dec 15, 2011 at 03:54:00PM +0000, Anthony Wright wrote:
>> On 14/12/2011 21:38, Konrad Rzeszutek Wilk wrote:
>>> On Thu, Dec 08, 2011 at 12:00:07PM +0000, Anthony Wright wrote:
>>>> I've just had my first attempt at getting VGA passthrough to work, and
>>>> it crashed the machine. I'm trying to understand whether this is a
>>>> problem with my hardware, configuration or a software problem.
>>>>
>>>> I'm running Xen 4.1.2 with Linux 3.1.2
>>>>
>>>>
>>>> The CPU is an Intel Core i5-650
>>>> http://ark.intel.com/products/43546/Intel-Core-i5-650-Processor-%284M-Cache-3_20-GHz%29
>>> And what is your motherboard? Does it have VT-d?
>> That was the important question... I'd missed the BIOS option to enable
>> VT-d which was disabled by default. I enabled the BIOS option and
>> everything worked, and it's very cool. :-)
>>
>> This does beg a couple of other questions though....
>>
>> Shouldn't I get a nice(ish) error message if I try to start a VGA
>> passthrough VM on hardware that doesn't support it rather than crashing
>> the machine?
>
> There is this http://wiki.xen.org/xenwiki/VTdHowTo which gives you a
> nice idea of what works.
Unfortunately I spoke a little too soon. I'm running with a Windows 7
Pro, 32 bit iso image, to install a new version of windows into the VM.
It seems to start nicely and I get a pulsing windows logo on the screen,
but it never progresses to the next page, and the VM consumes a huge
amount of CPU. If I run it purely in a VNC session, everything runs
smoothly and quickly. We noticed that there are a lot of VT-d features
disabled, and wondered if this might be the cause. The motherboard is an
intel DQ57TM, and the processor is an Intel Core i5-650, I have enabled
VT-d and FLR within the motherboard which seem to be the only relevant
motherboard switches.

Inside xl dmesg all the additional VT-d features are not enabled (Snoop
Control, Dom0 DMA Passthrough, Queued Invalidation, Interrupt Remapping,
Shared EPT tables) and I wondered if this was the problem. I tried
starting with iommu=1 on the xen command line and without it. The output
from xl dmesg is very similar and the VM behaves the same in both cases,
but I get a number of iommu.c errors messages when the 'iommu=1'
parameter is present. In both cases Xen also outputs a number of mm.c
errors which is similar to a problem I reported a while ago. I have
attach xl dmesg logs from both cases.

>> Can I tell whether hardware will support VGA passthrough without trying
>> to start a VM that uses it?
>>
>> Also when I shut down the VM I have to use 'xl destroy' as I'm testing
>> with Windows. After issuing the 'xl destroy' there is a long pause and
>> then the error:
>>
>>     libxl: error: libxl_device.c:470:libxl__wait_for_device_model Device
>> Model not ready
>>     libxl: error: libxl_pci.c:892:do_pci_remove Device Model didn't
>> respond in time
>>
>> If I pass through more than one device, I get the pause and the message
>> for each device.
> Hm, it looks to be sending 'pci-rem' to the XenStore, but I am not sure
> if QEMU understands it. Did you compile Xen 4.1.2 by yourself? Did it
> compile with CONFIG_PASSTHROUGH?
>
> You should see some messages in the qemu.log about hot-remove and such.
Yes I compiled Xen 4.1.2 by myself, but I don't know is
CONFIG_PASSTHROUGH is enabled or not - there's no mention of it in the
build logs. I see a hot-remove entry in the qemu log, and have attached
the whole log as it's not very long.

Anthony.

--------------040702030303010803030607
Content-Type: text/plain;
 name="qemu-dm-16-2.log"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="qemu-dm-16-2.log"

domid: 1
Using file /dev/Master/Disk-root-16-0001 in read-write mode
Strip off blktap sub-type prefix to /workspace/agent/appliance/861ae470cd891983dbad195388406b86/1/win7-pro-32.iso (drv 'aio')
Using file /workspace/agent/appliance/861ae470cd891983dbad195388406b86/1/win7-pro-32.iso in read-only mode
Watching /local/domain/0/device-model/1/logdirty/cmd
Watching /local/domain/0/device-model/1/command
Watching /local/domain/1/cpu
char device redirected to /dev/pts/2
qemu_map_cache_init nr_buckets = 4000 size 327680
shared page at pfn feffd
buffered io page at pfn feffb
Guest uuid = 8c233cf4-fd06-4471-a242-0795bb7ca56e
Register xen platform.
Done register platform.
platform_fixed_ioport: changed ro/rw state of ROM memory area. now is rw state.
xs_read(/local/domain/0/device-model/1/xen_extended_power_mgmt): read error
xs_read(): vncpasswd get error. /vm/8c233cf4-fd06-4471-a242-0795bb7ca56e/vncpasswd.
medium change watch on `hdb' (index: 1): aio:/workspace/agent/appliance/861ae470cd891983dbad195388406b86/1/win7-pro-32.iso
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
Log-dirty: no command yet.
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
vcpu-set: watch node error.
xs_read(/local/domain/1/log-throttling): read error
qemu: ignoring not-understood drive `/local/domain/1/log-throttling'
medium change watch on `/local/domain/1/log-throttling' - unknown device, ignored
dm-command: hot insert pass-through pci dev 
register_real_device: Assigning real physical device 00:02.0 ...
pt_iomul_init: Error: pt_iomul_init can't open file /dev/xen/pci_iomul: No such file or directory: 0x0:0x2.0x0
pt_register_regions: IO region registered (size=0x00400000 base_addr=0xfe000004)
pt_register_regions: IO region registered (size=0x10000000 base_addr=0xd000000c)
pt_register_regions: IO region registered (size=0x00000008 base_addr=0x0000f161)
setup_vga_pt: vga bios checksum is adjusted!
pt_msi_setup: msi mapped with pirq 37
pci_intx: intx=1
register_real_device: Real physical device 00:02.0 registered successfuly!
IRQ type = MSI-INTx
igd_pci_read: pci_config_read: 0:0.0: addr=0 len=2 val=ffff8086
igd_pci_read: pci_config_read: 0:0.0: addr=2 len=2 val=ffff0040
pt_iomem_map: e_phys=e0000000 maddr=d0000000 type=8 len=268435456 index=2 first_map=1
pt_iomem_map: e_phys=f1000000 maddr=fe000000 type=0 len=4194304 index=0 first_map=1
pt_ioport_map: e_phys=c330 pio_base=f160 len=8 index=4 first_map=1
igd_pci_read: pci_config_read: 0:0.0: addr=0 len=2 val=ffff8086
igd_pci_read: pci_config_read: 0:0.0: addr=2 len=2 val=ffff0040
igd_pci_read: pci_config_read: 0:0.0: addr=0 len=2 val=ffff8086
igd_pci_read: pci_config_read: 0:0.0: addr=2 len=2 val=ffff0040
igd_pci_read: pci_config_read: 0:0.0: addr=52 len=2 val=ffff0b50
platform_fixed_ioport: changed ro/rw state of ROM memory area. now is rw state.
igd_pci_read: pci_config_read: 0:0.0: addr=0 len=4 val=408086
platform_fixed_ioport: changed ro/rw state of ROM memory area. now is ro state.
igd_pci_read: pci_config_read: 0:0.0: addr=2 len=2 val=ffff0040
igd_pci_read: pci_config_read: 0:0.0: addr=0 len=4 val=408086
igd_pci_read: pci_config_read: 0:0.0: addr=0 len=4 val=408086
igd_pci_read: pci_config_read: 0:0.0: addr=0 len=4 val=408086
igd_pci_read: pci_config_read: 0:0.0: addr=0 len=4 val=408086
igd_pci_read: pci_config_read: 0:0.0: addr=0 len=4 val=408086
igd_pci_read: pci_config_read: 0:0.0: addr=0 len=4 val=408086
igd_pci_read: pci_config_read: 0:0.0: addr=0 len=4 val=408086
igd_pci_read: pci_config_read: 0:0.0: addr=0 len=4 val=408086
igd_pci_read: pci_config_read: 0:0.0: addr=0 len=4 val=408086
igd_pci_read: pci_config_read: 0:0.0: addr=0 len=4 val=408086
igd_pci_read: pci_config_read: 0:0.0: addr=0 len=4 val=408086
igd_pci_read: pci_config_read: 0:0.0: addr=0 len=4 val=408086
igd_pci_read: pci_config_read: 0:0.0: addr=0 len=4 val=408086
igd_pci_read: pci_config_read: 0:0.0: addr=0 len=4 val=408086
igd_pci_read: pci_config_read: 0:0.0: addr=0 len=4 val=408086
igd_pci_read: pci_config_read: 0:0.0: addr=0 len=4 val=408086
igd_pci_read: pci_config_read: 0:0.0: addr=0 len=4 val=408086
igd_pci_read: pci_config_read: 0:0.0: addr=0 len=4 val=408086
igd_pci_read: pci_config_read: 0:0.0: addr=0 len=2 val=ffff8086
igd_pci_read: pci_config_read: 0:0.0: addr=0 len=2 val=ffff8086
igd_pci_read: pci_config_read: 0:0.0: addr=2 len=2 val=ffff0040
pt_iomem_map: e_phys=ffffffff maddr=fe000000 type=0 len=4194304 index=0 first_map=0
pt_iomem_map: e_phys=ffffffff maddr=d0000000 type=8 len=268435456 index=2 first_map=0
pt_ioport_map: e_phys=ffff pio_base=f160 len=8 index=4 first_map=0
pt_iomem_map: e_phys=f1000000 maddr=fe000000 type=0 len=4194304 index=0 first_map=0
pt_iomem_map: e_phys=e0000000 maddr=d0000000 type=8 len=268435456 index=2 first_map=0
pt_ioport_map: e_phys=c330 pio_base=f160 len=8 index=4 first_map=0
igd_pci_read: pci_config_read: 0:0.0: addr=0 len=4 val=408086
igd_pci_read: pci_config_read: 0:0.0: addr=0 len=4 val=408086
igd_pci_read: pci_config_read: 0:0.0: addr=0 len=4 val=408086
igd_pci_read: pci_config_read: 0:0.0: addr=0 len=4 val=408086
igd_pci_read: pci_config_read: 0:0.0: addr=0 len=4 val=408086
igd_pci_read: pci_config_read: 0:0.0: addr=0 len=4 val=408086
igd_pci_read: pci_config_read: 0:0.0: addr=0 len=4 val=408086
igd_pci_read: pci_config_read: 0:0.0: addr=0 len=4 val=408086
igd_pci_read: pci_config_read: 0:0.0: addr=0 len=4 val=408086
igd_pci_read: pci_config_read: 0:0.0: addr=0 len=4 val=408086
igd_pci_read: pci_config_read: 0:0.0: addr=0 len=4 val=408086
igd_pci_read: pci_config_read: 0:0.0: addr=0 len=4 val=408086
igd_pci_read: pci_config_read: 0:0.0: addr=0 len=4 val=408086
igd_pci_read: pci_config_read: 0:0.0: addr=0 len=4 val=408086
igd_pci_read: pci_config_read: 0:0.0: addr=0 len=2 val=ffff8086
igd_pci_read: pci_config_read: 0:0.0: addr=2 len=2 val=ffff0040
igd_pci_read: pci_config_read: 0:0.0: addr=0 len=2 val=ffff8086
igd_pci_read: pci_config_read: 0:0.0: addr=2 len=2 val=ffff0040
igd_pci_read: pci_config_read: 0:0.0: addr=0 len=2 val=ffff8086
igd_pci_read: pci_config_read: 0:0.0: addr=0 len=2 val=ffff8086
igd_pci_read: pci_config_read: 0:0.0: addr=2 len=2 val=ffff0040
igd_pci_read: pci_config_read: 0:0.0: addr=0 len=4 val=408086
igd_pci_read: pci_config_read: 0:0.0: addr=0 len=4 val=408086
igd_pci_read: pci_config_read: 0:0.0: addr=0 len=4 val=408086
igd_pci_read: pci_config_read: 0:0.0: addr=0 len=4 val=408086
igd_pci_read: pci_config_read: 0:0.0: addr=0 len=4 val=408086
igd_pci_read: pci_config_read: 0:0.0: addr=0 len=4 val=408086
igd_pci_read: pci_config_read: 0:0.0: addr=0 len=4 val=408086
igd_pci_read: pci_config_read: 0:0.0: addr=0 len=4 val=408086
igd_pci_read: pci_config_read: 0:0.0: addr=0 len=4 val=408086
igd_pci_read: pci_config_read: 0:0.0: addr=0 len=4 val=408086
igd_pci_read: pci_config_read: 0:0.0: addr=0 len=4 val=408086
igd_pci_read: pci_config_read: 0:0.0: addr=0 len=4 val=408086
igd_pci_read: pci_config_read: 0:0.0: addr=0 len=4 val=408086
igd_pci_read: pci_config_read: 0:0.0: addr=0 len=4 val=408086
dm-command: hot remove pass-through pci dev 
generate a sci for PHP.
deassert due to disable GPE bit.
igd_pci_read: pci_config_read: 0:0.0: addr=0 len=2 val=ffff8086
igd_pci_read: pci_config_read: 0:0.0: addr=0 len=2 val=ffff8086
igd_pci_read: pci_config_read: 0:0.0: addr=2 len=2 val=ffff0040

--------------040702030303010803030607
Content-Type: text/plain;
 name="xl-dmesg-blank"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="xl-dmesg-blank"

 __  __            _  _    _   ____  
 \ \/ /___ _ __   | || |  / | |___ \ 
  \  // _ \ '_ \  | || |_ | |   __) |
  /  \  __/ | | | |__   _|| |_ / __/ 
 /_/\_\___|_| |_|    |_|(_)_(_)_____|
                                     
(XEN) Xen version 4.1.2 (@[unknown]) (gcc version 4.4.3 (GCC) ) Thu Dec  8 10:35:43 GMT 2011
(XEN) Latest ChangeSet: unavailable
(XEN) Bootloader: GNU GRUB 0.97
(XEN) Command line: dom0_mem=800M sched=credit
(XEN) Video information:
(XEN)  VGA is text mode 80x25, font 8x16
(XEN)  VBE/DDC methods: none; EDID transfer time: 0 seconds
(XEN)  EDID info not retrieved because no DDC retrieval method detected
(XEN) Disc information:
(XEN)  Found 2 MBR signatures
(XEN)  Found 2 EDD information structures
(XEN) Xen-e820 RAM map:
(XEN)  0000000000000000 - 000000000009c000 (usable)
(XEN)  000000000009c000 - 00000000000a0000 (reserved)
(XEN)  00000000000e0000 - 0000000000100000 (reserved)
(XEN)  0000000000100000 - 00000000cb40c000 (usable)
(XEN)  00000000cb40c000 - 00000000cb44f000 (ACPI NVS)
(XEN)  00000000cb44f000 - 00000000cb4dd000 (reserved)
(XEN)  00000000cb4dd000 - 00000000cb4f1000 (ACPI NVS)
(XEN)  00000000cb4f1000 - 00000000cb4f3000 (usable)
(XEN)  00000000cb4f3000 - 00000000cb5f9000 (reserved)
(XEN)  00000000cb5f9000 - 00000000cb5fa000 (usable)
(XEN)  00000000cb5fa000 - 00000000cb5ff000 (reserved)
(XEN)  00000000cb5ff000 - 00000000cb600000 (ACPI NVS)
(XEN)  00000000cb600000 - 00000000cb608000 (ACPI data)
(XEN)  00000000cb608000 - 00000000cb609000 (ACPI NVS)
(XEN)  00000000cb609000 - 00000000cb60b000 (ACPI data)
(XEN)  00000000cb60b000 - 00000000cb624000 (ACPI NVS)
(XEN)  00000000cb624000 - 00000000cb645000 (reserved)
(XEN)  00000000cb645000 - 00000000cb688000 (ACPI NVS)
(XEN)  00000000cb688000 - 00000000cb800000 (usable)
(XEN)  00000000cdc00000 - 00000000d0000000 (reserved)
(XEN)  00000000e0000000 - 00000000e4000000 (reserved)
(XEN)  00000000fed1c000 - 00000000fed40000 (reserved)
(XEN)  00000000ff000000 - 0000000100000000 (reserved)
(XEN)  0000000100000000 - 00000001fc000000 (usable)
(XEN)  00000001fc000000 - 0000000200000000 (reserved)
(XEN)  0000000200000000 - 000000022c000000 (usable)
(XEN) System RAM: 7989MB (8180876kB)
(XEN) ACPI: RSDP 000F0410, 0024 (r2  INTEL)
(XEN) ACPI: XSDT CB609E18, 005C (r1 INTEL  DQ57TM    1072009 MSFT    10013)
(XEN) ACPI: FACP CB607D98, 00F4 (r4 INTEL  DQ57TM    1072009 MSFT    10013)
(XEN) ACPI: DSDT CB600018, 6CEA (r1 INTEL  DQ57TM          0 INTL 20051117)
(XEN) ACPI: FACS CB608E40, 0040
(XEN) ACPI: APIC CB607F18, 00CC (r2 INTEL  DQ57TM    1072009 MSFT    10013)
(XEN) ACPI: SSDT CB607C18, 014E (r1 INTEL  DQ57TM          1 MSFT  3000001)
(XEN) ACPI: MCFG CB60AF18, 003C (r1 INTEL  DQ57TM    1072009 MSFT       97)
(XEN) ACPI: ASF! CB609C18, 00A0 (r32 INTEL  DQ57TM          1 TFSM    F4240)
(XEN) ACPI: TCPA CB60AE98, 0032 (r2 INTEL  DQ57TM          1 MSFT  1000013)
(XEN) ACPI: DMAR CB609B18, 00B8 (r1 INTEL  DQ57TM          1 INTL        1)
(XEN) Xen heap: 9MB (9784kB)
(XEN) Domain heap initialised
(XEN) ACPI: 32/64X FACS address mismatch in FADT - cb608f40/00000000cb608e40, using 32
(XEN) Processor #0 6:5 APIC version 21
(XEN) Processor #1 6:5 APIC version 21
(XEN) Processor #4 6:5 APIC version 21
(XEN) Processor #5 6:5 APIC version 21
(XEN) IOAPIC[0]: apic_id 0, version 32, address 0xfec00000, GSI 0-23
(XEN) Enabling APIC mode:  Flat.  Using 1 I/O APICs
(XEN) Table is not found!
(XEN) Using scheduler: SMP Credit Scheduler (credit)
(XEN) Detected 3192.077 MHz processor.
(XEN) Intel VT-d Snoop Control not enabled.
(XEN) Intel VT-d Dom0 DMA Passthrough not enabled.
(XEN) Intel VT-d Queued Invalidation not enabled.
(XEN) Intel VT-d Interrupt Remapping not enabled.
(XEN) Intel VT-d Shared EPT tables not enabled.
(XEN) I/O virtualisation enabled
(XEN)  - Dom0 mode: Relaxed
(XEN) Enabled directed EOI with ioapic_ack_old on!
(XEN) ENABLING IO-APIC IRQs
(XEN)  -> Using old ACK method
(XEN) Platform timer is 3.579MHz ACPI PM Timer
(XEN) Allocated console ring of 16 KiB.
(XEN) VMX: Supported advanced features:
(XEN)  - APIC MMIO access virtualisation
(XEN)  - APIC TPR shadow
(XEN)  - Extended Page Tables (EPT)
(XEN)  - Virtual-Processor Identifiers (VPID)
(XEN)  - Virtual NMI
(XEN)  - MSR direct-access bitmap
(XEN)  - Unrestricted Guest
(XEN) EPT supports 2MB super page.
(XEN) HVM: ASIDs enabled.
(XEN) HVM: VMX enabled
(XEN) HVM: Hardware Assisted Paging detected.
(XEN) Brought up 4 CPUs
(XEN) *** LOADING DOMAIN 0 ***
(XEN)  Xen  kernel: 32-bit, PAE, lsb
(XEN)  Dom0 kernel: 32-bit, PAE, lsb, paddr 0x1000000 -> 0x1b76000
(XEN) PHYSICAL MEMORY ARRANGEMENT:
(XEN)  Dom0 alloc.:   0000000224000000->0000000226000000 (194067 pages to be allocated)
(XEN)  Init. ramdisk: 000000022b613000->000000022bfffb85
(XEN) VIRTUAL MEMORY ARRANGEMENT:
(XEN)  Loaded kernel: c1000000->c1b76000
(XEN)  Init. ramdisk: c1b76000->c2562b85
(XEN)  Phys-Mach map: c2563000->c262b000
(XEN)  Start info:    c262b000->c262b47c
(XEN)  Page tables:   c262c000->c2645000
(XEN)  Boot stack:    c2645000->c2646000
(XEN)  TOTAL:         c0000000->c2800000
(XEN)  ENTRY ADDRESS: c1779000
(XEN) Dom0 has maximum 4 VCPUs
(XEN) Scrubbing Free RAM: .......................................................................done.
(XEN) Xen trace buffers: disabled
(XEN) Std. Loglevel: Errors and warnings
(XEN) Guest Loglevel: Nothing (Rate-limited: Errors and warnings)
(XEN) Xen is relinquishing VGA console.
(XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch input to Xen)
(XEN) Freed 176kB init memory.
(XEN) mm.c:907:d0 Error getting mfn 2409c (pfn 55555555) from L1 entry 000000002409c023 for l1e_owner=0, pg_owner=0
(XEN) mm.c:907:d0 Error getting mfn 2409d (pfn 55555555) from L1 entry 000000002409d023 for l1e_owner=0, pg_owner=0
(XEN) mm.c:907:d0 Error getting mfn 2409e (pfn 55555555) from L1 entry 000000002409e023 for l1e_owner=0, pg_owner=0
(XEN) mm.c:907:d0 Error getting mfn 2409f (pfn 55555555) from L1 entry 000000002409f023 for l1e_owner=0, pg_owner=0

--------------040702030303010803030607
Content-Type: text/plain;
 name="xl-dmesg-iommu"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="xl-dmesg-iommu"

 __  __            _  _    _   ____  
 \ \/ /___ _ __   | || |  / | |___ \ 
  \  // _ \ '_ \  | || |_ | |   __) |
  /  \  __/ | | | |__   _|| |_ / __/ 
 /_/\_\___|_| |_|    |_|(_)_(_)_____|
                                     
(XEN) Xen version 4.1.2 (@[unknown]) (gcc version 4.4.3 (GCC) ) Thu Dec  8 10:35:43 GMT 2011
(XEN) Latest ChangeSet: unavailable
(XEN) Bootloader: GNU GRUB 0.97
(XEN) Command line: dom0_mem=800M sched=credit iommu=1
(XEN) Video information:
(XEN)  VGA is text mode 80x25, font 8x16
(XEN)  VBE/DDC methods: none; EDID transfer time: 0 seconds
(XEN)  EDID info not retrieved because no DDC retrieval method detected
(XEN) Disc information:
(XEN)  Found 2 MBR signatures
(XEN)  Found 2 EDD information structures
(XEN) Xen-e820 RAM map:
(XEN)  0000000000000000 - 000000000009c000 (usable)
(XEN)  000000000009c000 - 00000000000a0000 (reserved)
(XEN)  00000000000e0000 - 0000000000100000 (reserved)
(XEN)  0000000000100000 - 00000000cb40c000 (usable)
(XEN)  00000000cb40c000 - 00000000cb44f000 (ACPI NVS)
(XEN)  00000000cb44f000 - 00000000cb4dd000 (reserved)
(XEN)  00000000cb4dd000 - 00000000cb4f1000 (ACPI NVS)
(XEN)  00000000cb4f1000 - 00000000cb4f3000 (usable)
(XEN)  00000000cb4f3000 - 00000000cb5f9000 (reserved)
(XEN)  00000000cb5f9000 - 00000000cb5fa000 (usable)
(XEN)  00000000cb5fa000 - 00000000cb5ff000 (reserved)
(XEN)  00000000cb5ff000 - 00000000cb600000 (ACPI NVS)
(XEN)  00000000cb600000 - 00000000cb608000 (ACPI data)
(XEN)  00000000cb608000 - 00000000cb609000 (ACPI NVS)
(XEN)  00000000cb609000 - 00000000cb60b000 (ACPI data)
(XEN)  00000000cb60b000 - 00000000cb624000 (ACPI NVS)
(XEN)  00000000cb624000 - 00000000cb645000 (reserved)
(XEN)  00000000cb645000 - 00000000cb688000 (ACPI NVS)
(XEN)  00000000cb688000 - 00000000cb800000 (usable)
(XEN)  00000000cdc00000 - 00000000d0000000 (reserved)
(XEN)  00000000e0000000 - 00000000e4000000 (reserved)
(XEN)  00000000fed1c000 - 00000000fed40000 (reserved)
(XEN)  00000000ff000000 - 0000000100000000 (reserved)
(XEN)  0000000100000000 - 00000001fc000000 (usable)
(XEN)  00000001fc000000 - 0000000200000000 (reserved)
(XEN)  0000000200000000 - 000000022c000000 (usable)
(XEN) System RAM: 7989MB (8180876kB)
(XEN) ACPI: RSDP 000F0410, 0024 (r2  INTEL)
(XEN) ACPI: XSDT CB609E18, 005C (r1 INTEL  DQ57TM    1072009 MSFT    10013)
(XEN) ACPI: FACP CB607D98, 00F4 (r4 INTEL  DQ57TM    1072009 MSFT    10013)
(XEN) ACPI: DSDT CB600018, 6CEA (r1 INTEL  DQ57TM          0 INTL 20051117)
(XEN) ACPI: FACS CB608E40, 0040
(XEN) ACPI: APIC CB607F18, 00CC (r2 INTEL  DQ57TM    1072009 MSFT    10013)
(XEN) ACPI: SSDT CB607C18, 014E (r1 INTEL  DQ57TM          1 MSFT  3000001)
(XEN) ACPI: MCFG CB60AF18, 003C (r1 INTEL  DQ57TM    1072009 MSFT       97)
(XEN) ACPI: ASF! CB609C18, 00A0 (r32 INTEL  DQ57TM          1 TFSM    F4240)
(XEN) ACPI: TCPA CB60AE98, 0032 (r2 INTEL  DQ57TM          1 MSFT  1000013)
(XEN) ACPI: DMAR CB609B18, 00B8 (r1 INTEL  DQ57TM          1 INTL        1)
(XEN) Xen heap: 9MB (9784kB)
(XEN) Domain heap initialised
(XEN) ACPI: 32/64X FACS address mismatch in FADT - cb608f40/00000000cb608e40, using 32
(XEN) Processor #0 6:5 APIC version 21
(XEN) Processor #1 6:5 APIC version 21
(XEN) Processor #4 6:5 APIC version 21
(XEN) Processor #5 6:5 APIC version 21
(XEN) IOAPIC[0]: apic_id 0, version 32, address 0xfec00000, GSI 0-23
(XEN) Enabling APIC mode:  Flat.  Using 1 I/O APICs
(XEN) Table is not found!
(XEN) Using scheduler: SMP Credit Scheduler (credit)
(XEN) Detected 3192.100 MHz processor.
(XEN) Intel VT-d Snoop Control not enabled.
(XEN) Intel VT-d Dom0 DMA Passthrough not enabled.
(XEN) Intel VT-d Queued Invalidation not enabled.
(XEN) Intel VT-d Interrupt Remapping not enabled.
(XEN) Intel VT-d Shared EPT tables not enabled.
(XEN) I/O virtualisation enabled
(XEN)  - Dom0 mode: Relaxed
(XEN) Enabled directed EOI with ioapic_ack_old on!
(XEN) ENABLING IO-APIC IRQs
(XEN)  -> Using old ACK method
(XEN) Platform timer is 3.579MHz ACPI PM Timer
(XEN) Allocated console ring of 16 KiB.
(XEN) VMX: Supported advanced features:
(XEN)  - APIC MMIO access virtualisation
(XEN)  - APIC TPR shadow
(XEN)  - Extended Page Tables (EPT)
(XEN)  - Virtual-Processor Identifiers (VPID)
(XEN)  - Virtual NMI
(XEN)  - MSR direct-access bitmap
(XEN)  - Unrestricted Guest
(XEN) EPT supports 2MB super page.
(XEN) HVM: ASIDs enabled.
(XEN) HVM: VMX enabled
(XEN) HVM: Hardware Assisted Paging detected.
(XEN) Brought up 4 CPUs
(XEN) *** LOADING DOMAIN 0 ***
(XEN)  Xen  kernel: 32-bit, PAE, lsb
(XEN)  Dom0 kernel: 32-bit, PAE, lsb, paddr 0x1000000 -> 0x1b76000
(XEN) PHYSICAL MEMORY ARRANGEMENT:
(XEN)  Dom0 alloc.:   0000000224000000->0000000226000000 (194067 pages to be allocated)
(XEN)  Init. ramdisk: 000000022b613000->000000022bfffb85
(XEN) VIRTUAL MEMORY ARRANGEMENT:
(XEN)  Loaded kernel: c1000000->c1b76000
(XEN)  Init. ramdisk: c1b76000->c2562b85
(XEN)  Phys-Mach map: c2563000->c262b000
(XEN)  Start info:    c262b000->c262b47c
(XEN)  Page tables:   c262c000->c2645000
(XEN)  Boot stack:    c2645000->c2646000
(XEN)  TOTAL:         c0000000->c2800000
(XEN)  ENTRY ADDRESS: c1779000
(XEN) Dom0 has maximum 4 VCPUs
(XEN) [VT-D]iommu.c:853: iommu_fault_status: Fault Overflow
(XEN) [VT-D]iommu.c:856: iommu_fault_status: Primary Pending Fault
(XEN) [VT-D]iommu.c:831: DMAR:[DMA Write] Request device [00:02.0] fault addr 400000000, iommu reg = fff16000
(XEN) DMAR:[fault reason 05h] PTE Write access is not set
(XEN) Scrubbing Free RAM: .......................................................................done.
(XEN) Xen trace buffers: disabled
(XEN) Std. Loglevel: Errors and warnings
(XEN) Guest Loglevel: Nothing (Rate-limited: Errors and warnings)
(XEN) Xen is relinquishing VGA console.
(XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch input to Xen)
(XEN) Freed 176kB init memory.
(XEN) mm.c:907:d0 Error getting mfn 2409c (pfn 55555555) from L1 entry 000000002409c023 for l1e_owner=0, pg_owner=0
(XEN) mm.c:907:d0 Error getting mfn 2409d (pfn 55555555) from L1 entry 000000002409d023 for l1e_owner=0, pg_owner=0
(XEN) mm.c:907:d0 Error getting mfn 2409e (pfn 55555555) from L1 entry 000000002409e023 for l1e_owner=0, pg_owner=0
(XEN) mm.c:907:d0 Error getting mfn 2409f (pfn 55555555) from L1 entry 000000002409f023 for l1e_owner=0, pg_owner=0

--------------040702030303010803030607
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--------------040702030303010803030607--


From xen-devel-bounces@lists.xensource.com Mon Dec 19 15:58:41 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 15:58:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rcfbb-0008O5-N7; Mon, 19 Dec 2011 15:58:23 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <anthony@overnetdata.com>) id 1RcfbZ-0008Nx-Ty
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 15:58:22 +0000
X-Env-Sender: anthony@overnetdata.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1324310293!7866054!1
X-Originating-IP: [81.137.131.225]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31663 invoked from network); 19 Dec 2011 15:58:13 -0000
Received: from host81-137-131-225.in-addr.btopenworld.com (HELO
	zimbra.overnetdata.com) (81.137.131.225)
	by server-10.tower-182.messagelabs.com with SMTP;
	19 Dec 2011 15:58:13 -0000
Received: from localhost (localhost.localdomain [127.0.0.1])
	by zimbra.overnetdata.com (Postfix) with ESMTP id D2FB6160CB1;
	Mon, 19 Dec 2011 15:33:04 +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 WXQuA017Yfqu; Mon, 19 Dec 2011 15:32:50 +0000 (GMT)
Received: from [192.168.1.56] (unknown [192.168.1.56])
	by zimbra.overnetdata.com (Postfix) with ESMTPSA id C043F160CAE;
	Mon, 19 Dec 2011 15:32:50 +0000 (GMT)
Message-ID: <4EEF5923.1050307@overnetdata.com>
Date: Mon, 19 Dec 2011 15:32:51 +0000
From: Anthony Wright <anthony@overnetdata.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
References: <4EE0A6C7.9080603@overnetdata.com>
	<20111214213819.GD25896@andromeda.dapyr.net>
	<4EEA1818.6060106@overnetdata.com>
	<20111215211218.GA15407@andromeda.dapyr.net>
In-Reply-To: <20111215211218.GA15407@andromeda.dapyr.net>
X-Enigmail-Version: 1.3.4
Content-Type: multipart/mixed; boundary="------------040702030303010803030607"
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] VGA Passthrough crashes machine
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a multi-part message in MIME format.
--------------040702030303010803030607
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

On 15/12/2011 21:12, Konrad Rzeszutek Wilk wrote:
> On Thu, Dec 15, 2011 at 03:54:00PM +0000, Anthony Wright wrote:
>> On 14/12/2011 21:38, Konrad Rzeszutek Wilk wrote:
>>> On Thu, Dec 08, 2011 at 12:00:07PM +0000, Anthony Wright wrote:
>>>> I've just had my first attempt at getting VGA passthrough to work, and
>>>> it crashed the machine. I'm trying to understand whether this is a
>>>> problem with my hardware, configuration or a software problem.
>>>>
>>>> I'm running Xen 4.1.2 with Linux 3.1.2
>>>>
>>>>
>>>> The CPU is an Intel Core i5-650
>>>> http://ark.intel.com/products/43546/Intel-Core-i5-650-Processor-%284M-Cache-3_20-GHz%29
>>> And what is your motherboard? Does it have VT-d?
>> That was the important question... I'd missed the BIOS option to enable
>> VT-d which was disabled by default. I enabled the BIOS option and
>> everything worked, and it's very cool. :-)
>>
>> This does beg a couple of other questions though....
>>
>> Shouldn't I get a nice(ish) error message if I try to start a VGA
>> passthrough VM on hardware that doesn't support it rather than crashing
>> the machine?
>
> There is this http://wiki.xen.org/xenwiki/VTdHowTo which gives you a
> nice idea of what works.
Unfortunately I spoke a little too soon. I'm running with a Windows 7
Pro, 32 bit iso image, to install a new version of windows into the VM.
It seems to start nicely and I get a pulsing windows logo on the screen,
but it never progresses to the next page, and the VM consumes a huge
amount of CPU. If I run it purely in a VNC session, everything runs
smoothly and quickly. We noticed that there are a lot of VT-d features
disabled, and wondered if this might be the cause. The motherboard is an
intel DQ57TM, and the processor is an Intel Core i5-650, I have enabled
VT-d and FLR within the motherboard which seem to be the only relevant
motherboard switches.

Inside xl dmesg all the additional VT-d features are not enabled (Snoop
Control, Dom0 DMA Passthrough, Queued Invalidation, Interrupt Remapping,
Shared EPT tables) and I wondered if this was the problem. I tried
starting with iommu=1 on the xen command line and without it. The output
from xl dmesg is very similar and the VM behaves the same in both cases,
but I get a number of iommu.c errors messages when the 'iommu=1'
parameter is present. In both cases Xen also outputs a number of mm.c
errors which is similar to a problem I reported a while ago. I have
attach xl dmesg logs from both cases.

>> Can I tell whether hardware will support VGA passthrough without trying
>> to start a VM that uses it?
>>
>> Also when I shut down the VM I have to use 'xl destroy' as I'm testing
>> with Windows. After issuing the 'xl destroy' there is a long pause and
>> then the error:
>>
>>     libxl: error: libxl_device.c:470:libxl__wait_for_device_model Device
>> Model not ready
>>     libxl: error: libxl_pci.c:892:do_pci_remove Device Model didn't
>> respond in time
>>
>> If I pass through more than one device, I get the pause and the message
>> for each device.
> Hm, it looks to be sending 'pci-rem' to the XenStore, but I am not sure
> if QEMU understands it. Did you compile Xen 4.1.2 by yourself? Did it
> compile with CONFIG_PASSTHROUGH?
>
> You should see some messages in the qemu.log about hot-remove and such.
Yes I compiled Xen 4.1.2 by myself, but I don't know is
CONFIG_PASSTHROUGH is enabled or not - there's no mention of it in the
build logs. I see a hot-remove entry in the qemu log, and have attached
the whole log as it's not very long.

Anthony.

--------------040702030303010803030607
Content-Type: text/plain;
 name="qemu-dm-16-2.log"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="qemu-dm-16-2.log"

domid: 1
Using file /dev/Master/Disk-root-16-0001 in read-write mode
Strip off blktap sub-type prefix to /workspace/agent/appliance/861ae470cd891983dbad195388406b86/1/win7-pro-32.iso (drv 'aio')
Using file /workspace/agent/appliance/861ae470cd891983dbad195388406b86/1/win7-pro-32.iso in read-only mode
Watching /local/domain/0/device-model/1/logdirty/cmd
Watching /local/domain/0/device-model/1/command
Watching /local/domain/1/cpu
char device redirected to /dev/pts/2
qemu_map_cache_init nr_buckets = 4000 size 327680
shared page at pfn feffd
buffered io page at pfn feffb
Guest uuid = 8c233cf4-fd06-4471-a242-0795bb7ca56e
Register xen platform.
Done register platform.
platform_fixed_ioport: changed ro/rw state of ROM memory area. now is rw state.
xs_read(/local/domain/0/device-model/1/xen_extended_power_mgmt): read error
xs_read(): vncpasswd get error. /vm/8c233cf4-fd06-4471-a242-0795bb7ca56e/vncpasswd.
medium change watch on `hdb' (index: 1): aio:/workspace/agent/appliance/861ae470cd891983dbad195388406b86/1/win7-pro-32.iso
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
Log-dirty: no command yet.
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
vcpu-set: watch node error.
xs_read(/local/domain/1/log-throttling): read error
qemu: ignoring not-understood drive `/local/domain/1/log-throttling'
medium change watch on `/local/domain/1/log-throttling' - unknown device, ignored
dm-command: hot insert pass-through pci dev 
register_real_device: Assigning real physical device 00:02.0 ...
pt_iomul_init: Error: pt_iomul_init can't open file /dev/xen/pci_iomul: No such file or directory: 0x0:0x2.0x0
pt_register_regions: IO region registered (size=0x00400000 base_addr=0xfe000004)
pt_register_regions: IO region registered (size=0x10000000 base_addr=0xd000000c)
pt_register_regions: IO region registered (size=0x00000008 base_addr=0x0000f161)
setup_vga_pt: vga bios checksum is adjusted!
pt_msi_setup: msi mapped with pirq 37
pci_intx: intx=1
register_real_device: Real physical device 00:02.0 registered successfuly!
IRQ type = MSI-INTx
igd_pci_read: pci_config_read: 0:0.0: addr=0 len=2 val=ffff8086
igd_pci_read: pci_config_read: 0:0.0: addr=2 len=2 val=ffff0040
pt_iomem_map: e_phys=e0000000 maddr=d0000000 type=8 len=268435456 index=2 first_map=1
pt_iomem_map: e_phys=f1000000 maddr=fe000000 type=0 len=4194304 index=0 first_map=1
pt_ioport_map: e_phys=c330 pio_base=f160 len=8 index=4 first_map=1
igd_pci_read: pci_config_read: 0:0.0: addr=0 len=2 val=ffff8086
igd_pci_read: pci_config_read: 0:0.0: addr=2 len=2 val=ffff0040
igd_pci_read: pci_config_read: 0:0.0: addr=0 len=2 val=ffff8086
igd_pci_read: pci_config_read: 0:0.0: addr=2 len=2 val=ffff0040
igd_pci_read: pci_config_read: 0:0.0: addr=52 len=2 val=ffff0b50
platform_fixed_ioport: changed ro/rw state of ROM memory area. now is rw state.
igd_pci_read: pci_config_read: 0:0.0: addr=0 len=4 val=408086
platform_fixed_ioport: changed ro/rw state of ROM memory area. now is ro state.
igd_pci_read: pci_config_read: 0:0.0: addr=2 len=2 val=ffff0040
igd_pci_read: pci_config_read: 0:0.0: addr=0 len=4 val=408086
igd_pci_read: pci_config_read: 0:0.0: addr=0 len=4 val=408086
igd_pci_read: pci_config_read: 0:0.0: addr=0 len=4 val=408086
igd_pci_read: pci_config_read: 0:0.0: addr=0 len=4 val=408086
igd_pci_read: pci_config_read: 0:0.0: addr=0 len=4 val=408086
igd_pci_read: pci_config_read: 0:0.0: addr=0 len=4 val=408086
igd_pci_read: pci_config_read: 0:0.0: addr=0 len=4 val=408086
igd_pci_read: pci_config_read: 0:0.0: addr=0 len=4 val=408086
igd_pci_read: pci_config_read: 0:0.0: addr=0 len=4 val=408086
igd_pci_read: pci_config_read: 0:0.0: addr=0 len=4 val=408086
igd_pci_read: pci_config_read: 0:0.0: addr=0 len=4 val=408086
igd_pci_read: pci_config_read: 0:0.0: addr=0 len=4 val=408086
igd_pci_read: pci_config_read: 0:0.0: addr=0 len=4 val=408086
igd_pci_read: pci_config_read: 0:0.0: addr=0 len=4 val=408086
igd_pci_read: pci_config_read: 0:0.0: addr=0 len=4 val=408086
igd_pci_read: pci_config_read: 0:0.0: addr=0 len=4 val=408086
igd_pci_read: pci_config_read: 0:0.0: addr=0 len=4 val=408086
igd_pci_read: pci_config_read: 0:0.0: addr=0 len=4 val=408086
igd_pci_read: pci_config_read: 0:0.0: addr=0 len=2 val=ffff8086
igd_pci_read: pci_config_read: 0:0.0: addr=0 len=2 val=ffff8086
igd_pci_read: pci_config_read: 0:0.0: addr=2 len=2 val=ffff0040
pt_iomem_map: e_phys=ffffffff maddr=fe000000 type=0 len=4194304 index=0 first_map=0
pt_iomem_map: e_phys=ffffffff maddr=d0000000 type=8 len=268435456 index=2 first_map=0
pt_ioport_map: e_phys=ffff pio_base=f160 len=8 index=4 first_map=0
pt_iomem_map: e_phys=f1000000 maddr=fe000000 type=0 len=4194304 index=0 first_map=0
pt_iomem_map: e_phys=e0000000 maddr=d0000000 type=8 len=268435456 index=2 first_map=0
pt_ioport_map: e_phys=c330 pio_base=f160 len=8 index=4 first_map=0
igd_pci_read: pci_config_read: 0:0.0: addr=0 len=4 val=408086
igd_pci_read: pci_config_read: 0:0.0: addr=0 len=4 val=408086
igd_pci_read: pci_config_read: 0:0.0: addr=0 len=4 val=408086
igd_pci_read: pci_config_read: 0:0.0: addr=0 len=4 val=408086
igd_pci_read: pci_config_read: 0:0.0: addr=0 len=4 val=408086
igd_pci_read: pci_config_read: 0:0.0: addr=0 len=4 val=408086
igd_pci_read: pci_config_read: 0:0.0: addr=0 len=4 val=408086
igd_pci_read: pci_config_read: 0:0.0: addr=0 len=4 val=408086
igd_pci_read: pci_config_read: 0:0.0: addr=0 len=4 val=408086
igd_pci_read: pci_config_read: 0:0.0: addr=0 len=4 val=408086
igd_pci_read: pci_config_read: 0:0.0: addr=0 len=4 val=408086
igd_pci_read: pci_config_read: 0:0.0: addr=0 len=4 val=408086
igd_pci_read: pci_config_read: 0:0.0: addr=0 len=4 val=408086
igd_pci_read: pci_config_read: 0:0.0: addr=0 len=4 val=408086
igd_pci_read: pci_config_read: 0:0.0: addr=0 len=2 val=ffff8086
igd_pci_read: pci_config_read: 0:0.0: addr=2 len=2 val=ffff0040
igd_pci_read: pci_config_read: 0:0.0: addr=0 len=2 val=ffff8086
igd_pci_read: pci_config_read: 0:0.0: addr=2 len=2 val=ffff0040
igd_pci_read: pci_config_read: 0:0.0: addr=0 len=2 val=ffff8086
igd_pci_read: pci_config_read: 0:0.0: addr=0 len=2 val=ffff8086
igd_pci_read: pci_config_read: 0:0.0: addr=2 len=2 val=ffff0040
igd_pci_read: pci_config_read: 0:0.0: addr=0 len=4 val=408086
igd_pci_read: pci_config_read: 0:0.0: addr=0 len=4 val=408086
igd_pci_read: pci_config_read: 0:0.0: addr=0 len=4 val=408086
igd_pci_read: pci_config_read: 0:0.0: addr=0 len=4 val=408086
igd_pci_read: pci_config_read: 0:0.0: addr=0 len=4 val=408086
igd_pci_read: pci_config_read: 0:0.0: addr=0 len=4 val=408086
igd_pci_read: pci_config_read: 0:0.0: addr=0 len=4 val=408086
igd_pci_read: pci_config_read: 0:0.0: addr=0 len=4 val=408086
igd_pci_read: pci_config_read: 0:0.0: addr=0 len=4 val=408086
igd_pci_read: pci_config_read: 0:0.0: addr=0 len=4 val=408086
igd_pci_read: pci_config_read: 0:0.0: addr=0 len=4 val=408086
igd_pci_read: pci_config_read: 0:0.0: addr=0 len=4 val=408086
igd_pci_read: pci_config_read: 0:0.0: addr=0 len=4 val=408086
igd_pci_read: pci_config_read: 0:0.0: addr=0 len=4 val=408086
dm-command: hot remove pass-through pci dev 
generate a sci for PHP.
deassert due to disable GPE bit.
igd_pci_read: pci_config_read: 0:0.0: addr=0 len=2 val=ffff8086
igd_pci_read: pci_config_read: 0:0.0: addr=0 len=2 val=ffff8086
igd_pci_read: pci_config_read: 0:0.0: addr=2 len=2 val=ffff0040

--------------040702030303010803030607
Content-Type: text/plain;
 name="xl-dmesg-blank"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="xl-dmesg-blank"

 __  __            _  _    _   ____  
 \ \/ /___ _ __   | || |  / | |___ \ 
  \  // _ \ '_ \  | || |_ | |   __) |
  /  \  __/ | | | |__   _|| |_ / __/ 
 /_/\_\___|_| |_|    |_|(_)_(_)_____|
                                     
(XEN) Xen version 4.1.2 (@[unknown]) (gcc version 4.4.3 (GCC) ) Thu Dec  8 10:35:43 GMT 2011
(XEN) Latest ChangeSet: unavailable
(XEN) Bootloader: GNU GRUB 0.97
(XEN) Command line: dom0_mem=800M sched=credit
(XEN) Video information:
(XEN)  VGA is text mode 80x25, font 8x16
(XEN)  VBE/DDC methods: none; EDID transfer time: 0 seconds
(XEN)  EDID info not retrieved because no DDC retrieval method detected
(XEN) Disc information:
(XEN)  Found 2 MBR signatures
(XEN)  Found 2 EDD information structures
(XEN) Xen-e820 RAM map:
(XEN)  0000000000000000 - 000000000009c000 (usable)
(XEN)  000000000009c000 - 00000000000a0000 (reserved)
(XEN)  00000000000e0000 - 0000000000100000 (reserved)
(XEN)  0000000000100000 - 00000000cb40c000 (usable)
(XEN)  00000000cb40c000 - 00000000cb44f000 (ACPI NVS)
(XEN)  00000000cb44f000 - 00000000cb4dd000 (reserved)
(XEN)  00000000cb4dd000 - 00000000cb4f1000 (ACPI NVS)
(XEN)  00000000cb4f1000 - 00000000cb4f3000 (usable)
(XEN)  00000000cb4f3000 - 00000000cb5f9000 (reserved)
(XEN)  00000000cb5f9000 - 00000000cb5fa000 (usable)
(XEN)  00000000cb5fa000 - 00000000cb5ff000 (reserved)
(XEN)  00000000cb5ff000 - 00000000cb600000 (ACPI NVS)
(XEN)  00000000cb600000 - 00000000cb608000 (ACPI data)
(XEN)  00000000cb608000 - 00000000cb609000 (ACPI NVS)
(XEN)  00000000cb609000 - 00000000cb60b000 (ACPI data)
(XEN)  00000000cb60b000 - 00000000cb624000 (ACPI NVS)
(XEN)  00000000cb624000 - 00000000cb645000 (reserved)
(XEN)  00000000cb645000 - 00000000cb688000 (ACPI NVS)
(XEN)  00000000cb688000 - 00000000cb800000 (usable)
(XEN)  00000000cdc00000 - 00000000d0000000 (reserved)
(XEN)  00000000e0000000 - 00000000e4000000 (reserved)
(XEN)  00000000fed1c000 - 00000000fed40000 (reserved)
(XEN)  00000000ff000000 - 0000000100000000 (reserved)
(XEN)  0000000100000000 - 00000001fc000000 (usable)
(XEN)  00000001fc000000 - 0000000200000000 (reserved)
(XEN)  0000000200000000 - 000000022c000000 (usable)
(XEN) System RAM: 7989MB (8180876kB)
(XEN) ACPI: RSDP 000F0410, 0024 (r2  INTEL)
(XEN) ACPI: XSDT CB609E18, 005C (r1 INTEL  DQ57TM    1072009 MSFT    10013)
(XEN) ACPI: FACP CB607D98, 00F4 (r4 INTEL  DQ57TM    1072009 MSFT    10013)
(XEN) ACPI: DSDT CB600018, 6CEA (r1 INTEL  DQ57TM          0 INTL 20051117)
(XEN) ACPI: FACS CB608E40, 0040
(XEN) ACPI: APIC CB607F18, 00CC (r2 INTEL  DQ57TM    1072009 MSFT    10013)
(XEN) ACPI: SSDT CB607C18, 014E (r1 INTEL  DQ57TM          1 MSFT  3000001)
(XEN) ACPI: MCFG CB60AF18, 003C (r1 INTEL  DQ57TM    1072009 MSFT       97)
(XEN) ACPI: ASF! CB609C18, 00A0 (r32 INTEL  DQ57TM          1 TFSM    F4240)
(XEN) ACPI: TCPA CB60AE98, 0032 (r2 INTEL  DQ57TM          1 MSFT  1000013)
(XEN) ACPI: DMAR CB609B18, 00B8 (r1 INTEL  DQ57TM          1 INTL        1)
(XEN) Xen heap: 9MB (9784kB)
(XEN) Domain heap initialised
(XEN) ACPI: 32/64X FACS address mismatch in FADT - cb608f40/00000000cb608e40, using 32
(XEN) Processor #0 6:5 APIC version 21
(XEN) Processor #1 6:5 APIC version 21
(XEN) Processor #4 6:5 APIC version 21
(XEN) Processor #5 6:5 APIC version 21
(XEN) IOAPIC[0]: apic_id 0, version 32, address 0xfec00000, GSI 0-23
(XEN) Enabling APIC mode:  Flat.  Using 1 I/O APICs
(XEN) Table is not found!
(XEN) Using scheduler: SMP Credit Scheduler (credit)
(XEN) Detected 3192.077 MHz processor.
(XEN) Intel VT-d Snoop Control not enabled.
(XEN) Intel VT-d Dom0 DMA Passthrough not enabled.
(XEN) Intel VT-d Queued Invalidation not enabled.
(XEN) Intel VT-d Interrupt Remapping not enabled.
(XEN) Intel VT-d Shared EPT tables not enabled.
(XEN) I/O virtualisation enabled
(XEN)  - Dom0 mode: Relaxed
(XEN) Enabled directed EOI with ioapic_ack_old on!
(XEN) ENABLING IO-APIC IRQs
(XEN)  -> Using old ACK method
(XEN) Platform timer is 3.579MHz ACPI PM Timer
(XEN) Allocated console ring of 16 KiB.
(XEN) VMX: Supported advanced features:
(XEN)  - APIC MMIO access virtualisation
(XEN)  - APIC TPR shadow
(XEN)  - Extended Page Tables (EPT)
(XEN)  - Virtual-Processor Identifiers (VPID)
(XEN)  - Virtual NMI
(XEN)  - MSR direct-access bitmap
(XEN)  - Unrestricted Guest
(XEN) EPT supports 2MB super page.
(XEN) HVM: ASIDs enabled.
(XEN) HVM: VMX enabled
(XEN) HVM: Hardware Assisted Paging detected.
(XEN) Brought up 4 CPUs
(XEN) *** LOADING DOMAIN 0 ***
(XEN)  Xen  kernel: 32-bit, PAE, lsb
(XEN)  Dom0 kernel: 32-bit, PAE, lsb, paddr 0x1000000 -> 0x1b76000
(XEN) PHYSICAL MEMORY ARRANGEMENT:
(XEN)  Dom0 alloc.:   0000000224000000->0000000226000000 (194067 pages to be allocated)
(XEN)  Init. ramdisk: 000000022b613000->000000022bfffb85
(XEN) VIRTUAL MEMORY ARRANGEMENT:
(XEN)  Loaded kernel: c1000000->c1b76000
(XEN)  Init. ramdisk: c1b76000->c2562b85
(XEN)  Phys-Mach map: c2563000->c262b000
(XEN)  Start info:    c262b000->c262b47c
(XEN)  Page tables:   c262c000->c2645000
(XEN)  Boot stack:    c2645000->c2646000
(XEN)  TOTAL:         c0000000->c2800000
(XEN)  ENTRY ADDRESS: c1779000
(XEN) Dom0 has maximum 4 VCPUs
(XEN) Scrubbing Free RAM: .......................................................................done.
(XEN) Xen trace buffers: disabled
(XEN) Std. Loglevel: Errors and warnings
(XEN) Guest Loglevel: Nothing (Rate-limited: Errors and warnings)
(XEN) Xen is relinquishing VGA console.
(XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch input to Xen)
(XEN) Freed 176kB init memory.
(XEN) mm.c:907:d0 Error getting mfn 2409c (pfn 55555555) from L1 entry 000000002409c023 for l1e_owner=0, pg_owner=0
(XEN) mm.c:907:d0 Error getting mfn 2409d (pfn 55555555) from L1 entry 000000002409d023 for l1e_owner=0, pg_owner=0
(XEN) mm.c:907:d0 Error getting mfn 2409e (pfn 55555555) from L1 entry 000000002409e023 for l1e_owner=0, pg_owner=0
(XEN) mm.c:907:d0 Error getting mfn 2409f (pfn 55555555) from L1 entry 000000002409f023 for l1e_owner=0, pg_owner=0

--------------040702030303010803030607
Content-Type: text/plain;
 name="xl-dmesg-iommu"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="xl-dmesg-iommu"

 __  __            _  _    _   ____  
 \ \/ /___ _ __   | || |  / | |___ \ 
  \  // _ \ '_ \  | || |_ | |   __) |
  /  \  __/ | | | |__   _|| |_ / __/ 
 /_/\_\___|_| |_|    |_|(_)_(_)_____|
                                     
(XEN) Xen version 4.1.2 (@[unknown]) (gcc version 4.4.3 (GCC) ) Thu Dec  8 10:35:43 GMT 2011
(XEN) Latest ChangeSet: unavailable
(XEN) Bootloader: GNU GRUB 0.97
(XEN) Command line: dom0_mem=800M sched=credit iommu=1
(XEN) Video information:
(XEN)  VGA is text mode 80x25, font 8x16
(XEN)  VBE/DDC methods: none; EDID transfer time: 0 seconds
(XEN)  EDID info not retrieved because no DDC retrieval method detected
(XEN) Disc information:
(XEN)  Found 2 MBR signatures
(XEN)  Found 2 EDD information structures
(XEN) Xen-e820 RAM map:
(XEN)  0000000000000000 - 000000000009c000 (usable)
(XEN)  000000000009c000 - 00000000000a0000 (reserved)
(XEN)  00000000000e0000 - 0000000000100000 (reserved)
(XEN)  0000000000100000 - 00000000cb40c000 (usable)
(XEN)  00000000cb40c000 - 00000000cb44f000 (ACPI NVS)
(XEN)  00000000cb44f000 - 00000000cb4dd000 (reserved)
(XEN)  00000000cb4dd000 - 00000000cb4f1000 (ACPI NVS)
(XEN)  00000000cb4f1000 - 00000000cb4f3000 (usable)
(XEN)  00000000cb4f3000 - 00000000cb5f9000 (reserved)
(XEN)  00000000cb5f9000 - 00000000cb5fa000 (usable)
(XEN)  00000000cb5fa000 - 00000000cb5ff000 (reserved)
(XEN)  00000000cb5ff000 - 00000000cb600000 (ACPI NVS)
(XEN)  00000000cb600000 - 00000000cb608000 (ACPI data)
(XEN)  00000000cb608000 - 00000000cb609000 (ACPI NVS)
(XEN)  00000000cb609000 - 00000000cb60b000 (ACPI data)
(XEN)  00000000cb60b000 - 00000000cb624000 (ACPI NVS)
(XEN)  00000000cb624000 - 00000000cb645000 (reserved)
(XEN)  00000000cb645000 - 00000000cb688000 (ACPI NVS)
(XEN)  00000000cb688000 - 00000000cb800000 (usable)
(XEN)  00000000cdc00000 - 00000000d0000000 (reserved)
(XEN)  00000000e0000000 - 00000000e4000000 (reserved)
(XEN)  00000000fed1c000 - 00000000fed40000 (reserved)
(XEN)  00000000ff000000 - 0000000100000000 (reserved)
(XEN)  0000000100000000 - 00000001fc000000 (usable)
(XEN)  00000001fc000000 - 0000000200000000 (reserved)
(XEN)  0000000200000000 - 000000022c000000 (usable)
(XEN) System RAM: 7989MB (8180876kB)
(XEN) ACPI: RSDP 000F0410, 0024 (r2  INTEL)
(XEN) ACPI: XSDT CB609E18, 005C (r1 INTEL  DQ57TM    1072009 MSFT    10013)
(XEN) ACPI: FACP CB607D98, 00F4 (r4 INTEL  DQ57TM    1072009 MSFT    10013)
(XEN) ACPI: DSDT CB600018, 6CEA (r1 INTEL  DQ57TM          0 INTL 20051117)
(XEN) ACPI: FACS CB608E40, 0040
(XEN) ACPI: APIC CB607F18, 00CC (r2 INTEL  DQ57TM    1072009 MSFT    10013)
(XEN) ACPI: SSDT CB607C18, 014E (r1 INTEL  DQ57TM          1 MSFT  3000001)
(XEN) ACPI: MCFG CB60AF18, 003C (r1 INTEL  DQ57TM    1072009 MSFT       97)
(XEN) ACPI: ASF! CB609C18, 00A0 (r32 INTEL  DQ57TM          1 TFSM    F4240)
(XEN) ACPI: TCPA CB60AE98, 0032 (r2 INTEL  DQ57TM          1 MSFT  1000013)
(XEN) ACPI: DMAR CB609B18, 00B8 (r1 INTEL  DQ57TM          1 INTL        1)
(XEN) Xen heap: 9MB (9784kB)
(XEN) Domain heap initialised
(XEN) ACPI: 32/64X FACS address mismatch in FADT - cb608f40/00000000cb608e40, using 32
(XEN) Processor #0 6:5 APIC version 21
(XEN) Processor #1 6:5 APIC version 21
(XEN) Processor #4 6:5 APIC version 21
(XEN) Processor #5 6:5 APIC version 21
(XEN) IOAPIC[0]: apic_id 0, version 32, address 0xfec00000, GSI 0-23
(XEN) Enabling APIC mode:  Flat.  Using 1 I/O APICs
(XEN) Table is not found!
(XEN) Using scheduler: SMP Credit Scheduler (credit)
(XEN) Detected 3192.100 MHz processor.
(XEN) Intel VT-d Snoop Control not enabled.
(XEN) Intel VT-d Dom0 DMA Passthrough not enabled.
(XEN) Intel VT-d Queued Invalidation not enabled.
(XEN) Intel VT-d Interrupt Remapping not enabled.
(XEN) Intel VT-d Shared EPT tables not enabled.
(XEN) I/O virtualisation enabled
(XEN)  - Dom0 mode: Relaxed
(XEN) Enabled directed EOI with ioapic_ack_old on!
(XEN) ENABLING IO-APIC IRQs
(XEN)  -> Using old ACK method
(XEN) Platform timer is 3.579MHz ACPI PM Timer
(XEN) Allocated console ring of 16 KiB.
(XEN) VMX: Supported advanced features:
(XEN)  - APIC MMIO access virtualisation
(XEN)  - APIC TPR shadow
(XEN)  - Extended Page Tables (EPT)
(XEN)  - Virtual-Processor Identifiers (VPID)
(XEN)  - Virtual NMI
(XEN)  - MSR direct-access bitmap
(XEN)  - Unrestricted Guest
(XEN) EPT supports 2MB super page.
(XEN) HVM: ASIDs enabled.
(XEN) HVM: VMX enabled
(XEN) HVM: Hardware Assisted Paging detected.
(XEN) Brought up 4 CPUs
(XEN) *** LOADING DOMAIN 0 ***
(XEN)  Xen  kernel: 32-bit, PAE, lsb
(XEN)  Dom0 kernel: 32-bit, PAE, lsb, paddr 0x1000000 -> 0x1b76000
(XEN) PHYSICAL MEMORY ARRANGEMENT:
(XEN)  Dom0 alloc.:   0000000224000000->0000000226000000 (194067 pages to be allocated)
(XEN)  Init. ramdisk: 000000022b613000->000000022bfffb85
(XEN) VIRTUAL MEMORY ARRANGEMENT:
(XEN)  Loaded kernel: c1000000->c1b76000
(XEN)  Init. ramdisk: c1b76000->c2562b85
(XEN)  Phys-Mach map: c2563000->c262b000
(XEN)  Start info:    c262b000->c262b47c
(XEN)  Page tables:   c262c000->c2645000
(XEN)  Boot stack:    c2645000->c2646000
(XEN)  TOTAL:         c0000000->c2800000
(XEN)  ENTRY ADDRESS: c1779000
(XEN) Dom0 has maximum 4 VCPUs
(XEN) [VT-D]iommu.c:853: iommu_fault_status: Fault Overflow
(XEN) [VT-D]iommu.c:856: iommu_fault_status: Primary Pending Fault
(XEN) [VT-D]iommu.c:831: DMAR:[DMA Write] Request device [00:02.0] fault addr 400000000, iommu reg = fff16000
(XEN) DMAR:[fault reason 05h] PTE Write access is not set
(XEN) Scrubbing Free RAM: .......................................................................done.
(XEN) Xen trace buffers: disabled
(XEN) Std. Loglevel: Errors and warnings
(XEN) Guest Loglevel: Nothing (Rate-limited: Errors and warnings)
(XEN) Xen is relinquishing VGA console.
(XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch input to Xen)
(XEN) Freed 176kB init memory.
(XEN) mm.c:907:d0 Error getting mfn 2409c (pfn 55555555) from L1 entry 000000002409c023 for l1e_owner=0, pg_owner=0
(XEN) mm.c:907:d0 Error getting mfn 2409d (pfn 55555555) from L1 entry 000000002409d023 for l1e_owner=0, pg_owner=0
(XEN) mm.c:907:d0 Error getting mfn 2409e (pfn 55555555) from L1 entry 000000002409e023 for l1e_owner=0, pg_owner=0
(XEN) mm.c:907:d0 Error getting mfn 2409f (pfn 55555555) from L1 entry 000000002409f023 for l1e_owner=0, pg_owner=0

--------------040702030303010803030607
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--------------040702030303010803030607--


From xen-devel-bounces@lists.xensource.com Mon Dec 19 16:09:48 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 16:09:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RcfmN-0000iw-3G; Mon, 19 Dec 2011 16:09:31 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1RcfmM-0000in-31
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 16:09:30 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1324310962!7867680!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7424 invoked from network); 19 Dec 2011 16:09:23 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Dec 2011 16:09:23 -0000
Received: by iagw33 with SMTP id w33so32562390iag.30
	for <xen-devel@lists.xensource.com>;
	Mon, 19 Dec 2011 08:09:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=bird5zSE9UutLhR3EH4a0odt32oXo0yXFrBHK02KuAc=;
	b=uwAlci5RjVSB4B2oYmLmRYgPTg5P3ewlUdQVRVaftDyFughJhJ3qSvEJNM+y8fxBKO
	4x/Ddu3nspaUKqQYmEw07UOBM631bviD+n4OA6rKF7IwoieG7XNYhNVzXmvHoanrTQ1B
	yN7FUcgEFPYj0CnlbOHnXHx72U3/h7/y9WvhE=
MIME-Version: 1.0
Received: by 10.50.216.234 with SMTP id ot10mr27976208igc.15.1324310962225;
	Mon, 19 Dec 2011 08:09:22 -0800 (PST)
Received: by 10.231.146.21 with HTTP; Mon, 19 Dec 2011 08:09:21 -0800 (PST)
In-Reply-To: <CAFLBxZah=GegCYJf4TCc5awEyHwRU9hz0xzyAqokaDLs5i7Xfg@mail.gmail.com>
References: <4EBA58F2020000780005FCCC@nat28.tlf.novell.com>
	<CAFQ2Z+d_Oq+6L9x=V9mPJ2jTSOa5k5k2Cpgyd9rYBsrOcMeFQw@mail.gmail.com>
	<CAFLBxZah=GegCYJf4TCc5awEyHwRU9hz0xzyAqokaDLs5i7Xfg@mail.gmail.com>
Date: Mon, 19 Dec 2011 16:09:21 +0000
X-Google-Sender-Auth: SvQMd8N5EECwnDOKEncJIn3jlD4
Message-ID: <CAFLBxZY5tjCaG3c6CpQXHg7cTKkK4--tGFF1pX7pMkvyScLe6w@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: Yang Z Zhang <yang.z.zhang@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Haitao Shan <haitao.shan@intel.com>
Subject: Re: [Xen-devel] [PATCH] x86/cpuidle: add Westmere-EX support to hw
 residencies reading logic
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ping?

On Wed, Dec 14, 2011 at 4:12 PM, George Dunlap
<George.Dunlap@eu.citrix.com> wrote:
> Should this be back-ported to 4.1?
> =A0-George
>
> On Wed, Nov 30, 2011 at 6:13 AM, Haitao Shan <maillists.shan@gmail.com> w=
rote:
>> ACK!
>> Thanks Jan for making the cpu model list more complete.
>>
>> Shan Haitao
>>
>> 2011/11/9 Jan Beulich <JBeulich@suse.com>:
>>> This is in accordance with
>>> http://software.intel.com/en-us/articles/intel-processor-identification=
-with-cpuid-model-and-family-numbers/
>>>
>>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>>>
>>> --- a/xen/arch/x86/acpi/cpu_idle.c
>>> +++ b/xen/arch/x86/acpi/cpu_idle.c
>>> @@ -120,6 +120,7 @@ static void do_get_hw_residencies(void *
>>> =A0 =A0 /* Westmere */
>>> =A0 =A0 case 0x25:
>>> =A0 =A0 case 0x2C:
>>> + =A0 =A0case 0x2F:
>>> =A0 =A0 =A0 =A0 GET_PC3_RES(hw_res->pc3);
>>> =A0 =A0 =A0 =A0 GET_PC6_RES(hw_res->pc6);
>>> =A0 =A0 =A0 =A0 GET_PC7_RES(hw_res->pc7);
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Xen-devel mailing list
>>> Xen-devel@lists.xensource.com
>>> http://lists.xensource.com/xen-devel
>>>
>>>
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 16:09:48 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 16:09:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RcfmN-0000iw-3G; Mon, 19 Dec 2011 16:09:31 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1RcfmM-0000in-31
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 16:09:30 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1324310962!7867680!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7424 invoked from network); 19 Dec 2011 16:09:23 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Dec 2011 16:09:23 -0000
Received: by iagw33 with SMTP id w33so32562390iag.30
	for <xen-devel@lists.xensource.com>;
	Mon, 19 Dec 2011 08:09:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=bird5zSE9UutLhR3EH4a0odt32oXo0yXFrBHK02KuAc=;
	b=uwAlci5RjVSB4B2oYmLmRYgPTg5P3ewlUdQVRVaftDyFughJhJ3qSvEJNM+y8fxBKO
	4x/Ddu3nspaUKqQYmEw07UOBM631bviD+n4OA6rKF7IwoieG7XNYhNVzXmvHoanrTQ1B
	yN7FUcgEFPYj0CnlbOHnXHx72U3/h7/y9WvhE=
MIME-Version: 1.0
Received: by 10.50.216.234 with SMTP id ot10mr27976208igc.15.1324310962225;
	Mon, 19 Dec 2011 08:09:22 -0800 (PST)
Received: by 10.231.146.21 with HTTP; Mon, 19 Dec 2011 08:09:21 -0800 (PST)
In-Reply-To: <CAFLBxZah=GegCYJf4TCc5awEyHwRU9hz0xzyAqokaDLs5i7Xfg@mail.gmail.com>
References: <4EBA58F2020000780005FCCC@nat28.tlf.novell.com>
	<CAFQ2Z+d_Oq+6L9x=V9mPJ2jTSOa5k5k2Cpgyd9rYBsrOcMeFQw@mail.gmail.com>
	<CAFLBxZah=GegCYJf4TCc5awEyHwRU9hz0xzyAqokaDLs5i7Xfg@mail.gmail.com>
Date: Mon, 19 Dec 2011 16:09:21 +0000
X-Google-Sender-Auth: SvQMd8N5EECwnDOKEncJIn3jlD4
Message-ID: <CAFLBxZY5tjCaG3c6CpQXHg7cTKkK4--tGFF1pX7pMkvyScLe6w@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: Yang Z Zhang <yang.z.zhang@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Haitao Shan <haitao.shan@intel.com>
Subject: Re: [Xen-devel] [PATCH] x86/cpuidle: add Westmere-EX support to hw
 residencies reading logic
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ping?

On Wed, Dec 14, 2011 at 4:12 PM, George Dunlap
<George.Dunlap@eu.citrix.com> wrote:
> Should this be back-ported to 4.1?
> =A0-George
>
> On Wed, Nov 30, 2011 at 6:13 AM, Haitao Shan <maillists.shan@gmail.com> w=
rote:
>> ACK!
>> Thanks Jan for making the cpu model list more complete.
>>
>> Shan Haitao
>>
>> 2011/11/9 Jan Beulich <JBeulich@suse.com>:
>>> This is in accordance with
>>> http://software.intel.com/en-us/articles/intel-processor-identification=
-with-cpuid-model-and-family-numbers/
>>>
>>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>>>
>>> --- a/xen/arch/x86/acpi/cpu_idle.c
>>> +++ b/xen/arch/x86/acpi/cpu_idle.c
>>> @@ -120,6 +120,7 @@ static void do_get_hw_residencies(void *
>>> =A0 =A0 /* Westmere */
>>> =A0 =A0 case 0x25:
>>> =A0 =A0 case 0x2C:
>>> + =A0 =A0case 0x2F:
>>> =A0 =A0 =A0 =A0 GET_PC3_RES(hw_res->pc3);
>>> =A0 =A0 =A0 =A0 GET_PC6_RES(hw_res->pc6);
>>> =A0 =A0 =A0 =A0 GET_PC7_RES(hw_res->pc7);
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Xen-devel mailing list
>>> Xen-devel@lists.xensource.com
>>> http://lists.xensource.com/xen-devel
>>>
>>>
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 16:14:11 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 16: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.xensource.com>)
	id 1Rcfqc-0000rJ-RJ; Mon, 19 Dec 2011 16:13:54 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@cs.ubc.ca>) id 1Rcfqa-0000rB-GR
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 16:13:52 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-13.tower-27.messagelabs.com!1324311204!52791501!1
X-Originating-IP: [142.103.6.52]
X-SpamReason: No, hits=1.7 required=7.0 tests=BODY_RANDOM_LONG,
	HTML_20_30,HTML_MESSAGE,RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1886 invoked from network); 19 Dec 2011 16:13:25 -0000
Received: from smtp.cs.ubc.ca (HELO smtp.cs.ubc.ca) (142.103.6.52)
	by server-13.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Dec 2011 16:13:25 -0000
Received: from mail-ey0-f171.google.com (mail-ey0-f171.google.com
	[209.85.215.171]) (authenticated bits=0)
	by smtp.cs.ubc.ca (8.14.3/8.13.6) with ESMTP id pBJGDjhj023305
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL)
	for <xen-devel@lists.xensource.com>; Mon, 19 Dec 2011 08:13:46 -0800
Received: by eaad11 with SMTP id d11so20447554eaa.30
	for <xen-devel@lists.xensource.com>;
	Mon, 19 Dec 2011 08:13:44 -0800 (PST)
Received: by 10.205.125.144 with SMTP id gs16mr1826050bkc.137.1324311224320;
	Mon, 19 Dec 2011 08:13:44 -0800 (PST)
MIME-Version: 1.0
Received: by 10.205.42.5 with HTTP; Mon, 19 Dec 2011 08:13:03 -0800 (PST)
In-Reply-To: <CAFLBxZZP=K504L86WDJ-F+9SuTf7aKU_C=i8nLZwqDuejoVGag@mail.gmail.com>
References: <26c93838.3b3fb.13445de0e67.Coremail.gbtux@126.com>
	<CAFLBxZYM-8vEc5Egmv+iXqMDUE_UJcgHbwr7=71H-kFowTzXWA@mail.gmail.com>
	<676b608e.2fb26.13447553671.Coremail.gbtux@126.com>
	<CAFLBxZaBiwEvz-dgPzgBQQTj2xMi8m+QnZ3M+uoqw4AKmb0ZvA@mail.gmail.com>
	<35e4701f.ca5a.1344b4ed98e.Coremail.gbtux@126.com>
	<CAFLBxZZP=K504L86WDJ-F+9SuTf7aKU_C=i8nLZwqDuejoVGag@mail.gmail.com>
From: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Date: Mon, 19 Dec 2011 10:13:03 -0600
Message-ID: <CAP8mzPMrAa=WzzdxqoHM=9Cpm1rqTgQB2OU96xtj2eODWQq_Ew@mail.gmail.com>
To: George Dunlap <George.Dunlap@eu.citrix.com>
Cc: gavin <gbtux@126.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] A question on the credit scheduler
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: rshriram@cs.ubc.ca
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6443486809938595629=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============6443486809938595629==
Content-Type: multipart/alternative; boundary=000e0ce0d27e19034804b4743cab

--000e0ce0d27e19034804b4743cab
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

On Mon, Dec 19, 2011 at 4:37 AM, George Dunlap
<George.Dunlap@eu.citrix.com>wrote:

> 2011/12/17 gavin <gbtux@126.com>:
> >
> > At 2011-12-16 23:58:26,"George Dunlap" <George.Dunlap@eu.citrix.com
> > wrote:
> >>2011/12/16 gavin <gbtux@126.com>:
> >>> At 2011-12-16 19:04:19,"George Dunlap" <George.Dunlap@eu.citrix.com
> > wrote:
> >>>
> >>>>2011/12/16 zhikai <gbtux@126.com>:
> >>>>> Hi All,
> >>>>>
>
> >>>>> In the credit scheduler, the scheduling decision function csched_sc=
hedule()
>
> >>>>> is called in the schedule function in scheduler.c, such as the foll=
owing.
> >>>>> next_slice =3D sched->do_schedule(sched, now, tasklet_work_schedule=
d);
> >>>>>
> >>>>> But, how often the csched_schedule() is called and to run? Does thi=
s
>
> >>>>> frequency have something to do with the slice of credit scheduler t=
hat is
> >>>>> 30ms?
> >>>>
> >>>>The scheduler runs whenever the SCHEDULE_SOFTIRQ is raised.  If you
> >>>>grep through the source code fro that string, you can find all the
> >>>>places where it's raised.
> >>>>
> >>>>Some examples include:
> >>>>* When the 30ms timeslice is finished
>
> >>>>* When a sleeping vcpu of higher priority than what's currently runni=
ng wakes up
> >>>>* When a vcpu blocks
> >>>>* When a vcpu is migrated from one cpu to another
> >>>>
> >>>>30ms is actually a pretty long time; in typical workloads, vcpus bloc=
k
> >>>>or are preempted by other waking vcpus without using up their full
> >>>>timeslice.
> >>>
> >>> Thank you very much for your reply.
> >>>
>
> >>> So, the vcpu is very likely to be preempted whenever the SCHEDULE_SOF=
TIRQ is
> >>> raised.
> >>
> >>It depends; if you have a cpu-burning vcpu running on a cpu all by
> >>itself, then after its 30ms timeslice, Xen will have no one else to
> >>run, and so will let it run again.
> >>
> >>But yes, if there are other vcpus on the runqueue, or the host is
> >>moderately busy, it's likely that SCHEDULE_SOFTIRQ will cause a
> >>context-switch.
> >>
> >>> And we cannot find a small timeslice, such as a(ms), which makes the
>
> >>> time any vcpu spending on running phase is k*a(ms), k is integer here=
. There
> >>> is no such a small timeslice. Is it right?
> >>
> >>I'm sorry, I don't really understand your question.  Perhaps if you
> >>told me what you're trying to accomplish?
> >
> > I try to describe my idea as the following clearly. But I really don't
> know
> > if it will work. Please give me some advice if possible.
> >
> > According to the credit scheduler in Xen, a vCPU can run a 30ms timesli=
ce
> > when it is scheduled on the physical CPU. And, a vCPU with the BOOST
> > priority will preempt the running one and run additional 10ms. So, what=
 I
> > think is if we monitor the physical CPU every 10ms and we can get the
> > mapping information of a physical CPU and a vCPU. And also, we can get
> the
> > un-mapping information that a physical CPU isn=92t mapped to any vCPU.
> Thus,
> > we can get the CPU usage by calculating the proportion of the mapping
> > information to the total time when we monitored.
> >
> > For example, if we monitor the physical CPUs every 10ms and we can get
> 100
> > pairs of pCPU and vCPU in a second, such as (pCPU_id, vCPU_id). If ther=
e
> is
> > 60 mapping pairs that the pCPU is mapped to a valid vPCU, and 40
> un-mapping
> > pairs that we cannot find the pCPU to be mapped a valid vCPU. So, we ca=
n
> get
> > the usage of the physical CPUs that is 60%.
> >
> > Here, we monitor the physical CPUs every 10ms. We also can monitor them
> once
> > less than the 10ms interval, such as 1ms interval. Whatever interval we
> > choose, we must make sure no CPU content switch in the interval or the
> > context switch always occur at the edge of interval. Only in this
> condition,
> > can this idea work.
> >
> > So, I am not sure whether we can find such a time interval that can mee=
t
> > this condition. In other words, whether we can find such a time interva=
l
> > that ensures all the CPU content switch occur at the edge of interval.
>
> You still haven't described exactly what it is you're trying to
> accomplish: what is your end goal?  It seems to be related somehow to
> measuring how busy the system is (i.e., the number of active pcpus and
> idle pcpus); but as I don't know what you want to do with that
> information, I can't tell you the best way to get it.
>
> Regarding a map of pcpus to vcpus, that already exists.  The
> scheduling code will keep track of the currently running vcpu here:
>  per_cpu(schedule_data, pcpu_id).curr
>
> You can see examples of the above structure used in
> xen/common/sched_credit2.c.  If "is_idle(per_cpu(schedule_data,
> pcpu).curr)" is false, then the cpu is running a vcpu; if it is true,
> then the pcpu is idle (although it may be running a tasklet).
>
> Additionally, if all you want is the number of non-idle cpus, the
> credit1 scheduler keeps track of the idle and non-idle cpus in
> prv->idlers.  You could easily use "cpumask_weight(&prv->idlers)" to
> find out how many idle cpus there are at any given time.  If you know
> how many online cpus there are, that will give you the busy-ness of
> the system.
>
> So now that you have this instantaneous percentage, what do you want
> to do with it?
>
>
A tangential question:
 When you pin a pcpu to a vcpu (e.g. xm vcpu-pin 0 0 0),  are the soft irqs
for that cpu still raised ? (Lets assume for the sake of simplicity that
there
are 2 cpus in the system and 2 domains - a dom0 and a domU, each pinned
to one CPU).
 Do the vcpu pauses (and subsequent resumes with no context switch etc)
still happen due to the irqs or the scheduler code? Or will the scheduler
be effectively disabled in this scenario ?

shriram


 -George
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>

--000e0ce0d27e19034804b4743cab
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote">On Mon, Dec 19, 2011 at 4:37 AM, George Dunlap <=
span dir=3D"ltr">&lt;<a href=3D"mailto:George.Dunlap@eu.citrix.com">George.=
Dunlap@eu.citrix.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex=
">

2011/12/17 gavin &lt;<a href=3D"mailto:gbtux@126.com">gbtux@126.com</a>&gt;=
:<br>
<div><div class=3D"h5">&gt;<br>
&gt; At=A02011-12-16=A023:58:26,&quot;George=A0Dunlap&quot;=A0&lt;<a href=
=3D"mailto:George.Dunlap@eu.citrix.com">George.Dunlap@eu.citrix.com</a>&gt;=
=A0wrote:<br>
&gt;&gt;2011/12/16=A0gavin=A0&lt;<a href=3D"mailto:gbtux@126.com">gbtux@126=
.com</a>&gt;:<br>
&gt;&gt;&gt;=A0At=A02011-12-16=A019:04:19,&quot;George=A0Dunlap&quot;=A0&lt=
;<a href=3D"mailto:George.Dunlap@eu.citrix.com">George.Dunlap@eu.citrix.com=
</a>&gt;=A0wrote:<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;2011/12/16=A0zhikai=A0&lt;<a href=3D"mailto:gbtux@126.com">=
gbtux@126.com</a>&gt;:<br>
&gt;&gt;&gt;&gt;&gt;=A0Hi=A0All,<br>
&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;=A0In=A0the=A0credit=A0scheduler,=A0the=A0scheduling=A0=
decision=A0function=A0csched_schedule()<br>
&gt;&gt;&gt;&gt;&gt;=A0is=A0called=A0in=A0the=A0schedule=A0function=A0in=A0=
scheduler.c,=A0such=A0as=A0the=A0following.<br>
&gt;&gt;&gt;&gt;&gt;=A0next_slice=A0=3D=A0sched-&gt;do_schedule(sched,=A0no=
w,=A0tasklet_work_scheduled);<br>
&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;=A0But,=A0how=A0often=A0the=A0csched_schedule()=A0is=A0=
called=A0and=A0to=A0run?=A0Does=A0this<br>
&gt;&gt;&gt;&gt;&gt;=A0frequency=A0have=A0something=A0to=A0do=A0with=A0the=
=A0slice=A0of=A0credit=A0scheduler=A0that=A0is<br>
&gt;&gt;&gt;&gt;&gt;=A030ms?<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;The=A0scheduler=A0runs=A0whenever=A0the=A0SCHEDULE_SOFTIRQ=
=A0is=A0raised.=A0=A0If=A0you<br>
&gt;&gt;&gt;&gt;grep=A0through=A0the=A0source=A0code=A0fro=A0that=A0string,=
=A0you=A0can=A0find=A0all=A0the<br>
&gt;&gt;&gt;&gt;places=A0where=A0it&#39;s=A0raised.<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;Some=A0examples=A0include:<br>
&gt;&gt;&gt;&gt;*=A0When=A0the=A030ms=A0timeslice=A0is=A0finished<br>
&gt;&gt;&gt;&gt;*=A0When=A0a=A0sleeping=A0vcpu=A0of=A0higher=A0priority=A0t=
han=A0what&#39;s=A0currently=A0running=A0wakes=A0up<br>
&gt;&gt;&gt;&gt;*=A0When=A0a=A0vcpu=A0blocks<br>
&gt;&gt;&gt;&gt;*=A0When=A0a=A0vcpu=A0is=A0migrated=A0from=A0one=A0cpu=A0to=
=A0another<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;30ms=A0is=A0actually=A0a=A0pretty=A0long=A0time;=A0in=A0typ=
ical=A0workloads,=A0vcpus=A0block<br>
&gt;&gt;&gt;&gt;or=A0are=A0preempted=A0by=A0other=A0waking=A0vcpus=A0withou=
t=A0using=A0up=A0their=A0full<br>
&gt;&gt;&gt;&gt;timeslice.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;=A0Thank=A0you=A0very=A0much=A0for=A0your=A0reply.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;=A0So,=A0the=A0vcpu=A0is=A0very=A0likely=A0to=A0be=A0preempted=
=A0whenever=A0the=A0SCHEDULE_SOFTIRQ=A0is<br>
&gt;&gt;&gt;=A0raised.<br>
&gt;&gt;<br>
&gt;&gt;It=A0depends;=A0if=A0you=A0have=A0a=A0cpu-burning=A0vcpu=A0running=
=A0on=A0a=A0cpu=A0all=A0by<br>
&gt;&gt;itself,=A0then=A0after=A0its=A030ms=A0timeslice,=A0Xen=A0will=A0hav=
e=A0no=A0one=A0else=A0to<br>
&gt;&gt;run,=A0and=A0so=A0will=A0let=A0it=A0run=A0again.<br>
&gt;&gt;<br>
&gt;&gt;But=A0yes,=A0if=A0there=A0are=A0other=A0vcpus=A0on=A0the=A0runqueue=
,=A0or=A0the=A0host=A0is<br>
&gt;&gt;moderately=A0busy,=A0it&#39;s=A0likely=A0that=A0SCHEDULE_SOFTIRQ=A0=
will=A0cause=A0a<br>
&gt;&gt;context-switch.<br>
&gt;&gt;<br>
&gt;&gt;&gt;=A0And=A0we=A0cannot=A0find=A0a=A0small=A0timeslice,=A0such=A0a=
s=A0a(ms),=A0which=A0makes=A0the<br>
&gt;&gt;&gt;=A0time=A0any=A0vcpu=A0spending=A0on=A0running=A0phase=A0is=A0k=
*a(ms),=A0k=A0is=A0integer=A0here.=A0There<br>
&gt;&gt;&gt;=A0is=A0no=A0such=A0a=A0small=A0timeslice.=A0Is=A0it=A0right?<b=
r>
&gt;&gt;<br>
&gt;&gt;I&#39;m=A0sorry,=A0I=A0don&#39;t=A0really=A0understand=A0your=A0que=
stion.=A0=A0Perhaps=A0if=A0you<br>
&gt;&gt;told=A0me=A0what=A0you&#39;re=A0trying=A0to=A0accomplish?<br>
&gt;<br>
&gt; I try to describe my idea as the following clearly. But I really don&#=
39;t know<br>
&gt; if it will work. Please give me some advice if possible.<br>
&gt;<br>
&gt; According to the credit scheduler in Xen, a vCPU can run a 30ms timesl=
ice<br>
&gt; when it is scheduled on the physical CPU. And, a vCPU with the BOOST<b=
r>
&gt; priority will preempt the running one and run additional 10ms. So, wha=
t I<br>
&gt; think is if we monitor the physical CPU every 10ms and we can get the<=
br>
&gt; mapping information of a physical CPU and a vCPU. And also, we can get=
 the<br>
&gt; un-mapping information that a physical CPU isn=92t mapped to any vCPU.=
 Thus,<br>
&gt; we can get the CPU usage by calculating the proportion of the mapping<=
br>
&gt; information to the total time when we monitored.<br>
&gt;<br>
&gt; For example, if we monitor the physical CPUs every 10ms and we can get=
 100<br>
&gt; pairs of pCPU and vCPU in a second, such as (pCPU_id, vCPU_id). If the=
re is<br>
&gt; 60 mapping pairs that the pCPU is mapped to a valid vPCU, and 40 un-ma=
pping<br>
&gt; pairs that we cannot find the pCPU to be mapped a valid vCPU. So, we c=
an get<br>
&gt; the usage of the physical CPUs that is 60%.<br>
&gt;<br>
&gt; Here, we monitor the physical CPUs every 10ms. We also can monitor the=
m once<br>
&gt; less than the 10ms interval, such as 1ms interval. Whatever interval w=
e<br>
&gt; choose, we must make sure no CPU content switch in the interval or the=
<br>
&gt; context switch always occur at the edge of interval. Only in this cond=
ition,<br>
&gt; can this idea work.<br>
&gt;<br>
&gt; So, I am not sure whether we can find such a time interval that can me=
et<br>
&gt; this condition. In other words, whether we can find such a time interv=
al<br>
&gt; that ensures all the CPU content switch occur at the edge of interval.=
<br>
<br>
</div></div>You still haven&#39;t described exactly what it is you&#39;re t=
rying to<br>
accomplish: what is your end goal? =A0It seems to be related somehow to<br>
measuring how busy the system is (i.e., the number of active pcpus and<br>
idle pcpus); but as I don&#39;t know what you want to do with that<br>
information, I can&#39;t tell you the best way to get it.<br>
<br>
Regarding a map of pcpus to vcpus, that already exists. =A0The<br>
scheduling code will keep track of the currently running vcpu here:<br>
 =A0per_cpu(schedule_data, pcpu_id).curr<br>
<br>
You can see examples of the above structure used in<br>
xen/common/sched_credit2.c. =A0If &quot;is_idle(per_cpu(schedule_data,<br>
pcpu).curr)&quot; is false, then the cpu is running a vcpu; if it is true,<=
br>
then the pcpu is idle (although it may be running a tasklet).<br>
<br>
Additionally, if all you want is the number of non-idle cpus, the<br>
credit1 scheduler keeps track of the idle and non-idle cpus in<br>
prv-&gt;idlers. =A0You could easily use &quot;cpumask_weight(&amp;prv-&gt;i=
dlers)&quot; to<br>
find out how many idle cpus there are at any given time. =A0If you know<br>
how many online cpus there are, that will give you the busy-ness of<br>
the system.<br>
<br>
So now that you have this instantaneous percentage, what do you want<br>
to do with it?<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br></div></div></blockquote><div><=
br>A tangential question:<br>=A0When you pin a pcpu to a vcpu (e.g. xm vcpu=
-pin 0 0 0),=A0 are the soft irqs<br>for that cpu still raised ? (Lets assu=
me for the sake of simplicity that there<br>

are 2 cpus in the system and 2 domains - a dom0 and a domU, each pinned<br>=
to one CPU).<br>=A0Do the vcpu pauses (and subsequent resumes with no conte=
xt switch etc)<br>still happen due to the irqs or the scheduler code? Or wi=
ll the scheduler<br>

be effectively disabled in this scenario ?<br><br>shriram<br><br><br></div>=
<blockquote class=3D"gmail_quote" style=3D"margin:0pt 0pt 0pt 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex"><div class=3D"HOEnZb"><di=
v class=3D"h5">


=A0-George<br>
<br>
_______________________________________________<br>
Xen-devel mailing list<br>
<a href=3D"mailto:Xen-devel@lists.xensource.com">Xen-devel@lists.xensource.=
com</a><br>
<a href=3D"http://lists.xensource.com/xen-devel" target=3D"_blank">http://l=
ists.xensource.com/xen-devel</a><br>
</div></div></blockquote></div><br>

--000e0ce0d27e19034804b4743cab--


--===============6443486809938595629==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============6443486809938595629==--


From xen-devel-bounces@lists.xensource.com Mon Dec 19 16:14:11 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 16: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.xensource.com>)
	id 1Rcfqc-0000rJ-RJ; Mon, 19 Dec 2011 16:13:54 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@cs.ubc.ca>) id 1Rcfqa-0000rB-GR
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 16:13:52 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-13.tower-27.messagelabs.com!1324311204!52791501!1
X-Originating-IP: [142.103.6.52]
X-SpamReason: No, hits=1.7 required=7.0 tests=BODY_RANDOM_LONG,
	HTML_20_30,HTML_MESSAGE,RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1886 invoked from network); 19 Dec 2011 16:13:25 -0000
Received: from smtp.cs.ubc.ca (HELO smtp.cs.ubc.ca) (142.103.6.52)
	by server-13.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Dec 2011 16:13:25 -0000
Received: from mail-ey0-f171.google.com (mail-ey0-f171.google.com
	[209.85.215.171]) (authenticated bits=0)
	by smtp.cs.ubc.ca (8.14.3/8.13.6) with ESMTP id pBJGDjhj023305
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL)
	for <xen-devel@lists.xensource.com>; Mon, 19 Dec 2011 08:13:46 -0800
Received: by eaad11 with SMTP id d11so20447554eaa.30
	for <xen-devel@lists.xensource.com>;
	Mon, 19 Dec 2011 08:13:44 -0800 (PST)
Received: by 10.205.125.144 with SMTP id gs16mr1826050bkc.137.1324311224320;
	Mon, 19 Dec 2011 08:13:44 -0800 (PST)
MIME-Version: 1.0
Received: by 10.205.42.5 with HTTP; Mon, 19 Dec 2011 08:13:03 -0800 (PST)
In-Reply-To: <CAFLBxZZP=K504L86WDJ-F+9SuTf7aKU_C=i8nLZwqDuejoVGag@mail.gmail.com>
References: <26c93838.3b3fb.13445de0e67.Coremail.gbtux@126.com>
	<CAFLBxZYM-8vEc5Egmv+iXqMDUE_UJcgHbwr7=71H-kFowTzXWA@mail.gmail.com>
	<676b608e.2fb26.13447553671.Coremail.gbtux@126.com>
	<CAFLBxZaBiwEvz-dgPzgBQQTj2xMi8m+QnZ3M+uoqw4AKmb0ZvA@mail.gmail.com>
	<35e4701f.ca5a.1344b4ed98e.Coremail.gbtux@126.com>
	<CAFLBxZZP=K504L86WDJ-F+9SuTf7aKU_C=i8nLZwqDuejoVGag@mail.gmail.com>
From: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Date: Mon, 19 Dec 2011 10:13:03 -0600
Message-ID: <CAP8mzPMrAa=WzzdxqoHM=9Cpm1rqTgQB2OU96xtj2eODWQq_Ew@mail.gmail.com>
To: George Dunlap <George.Dunlap@eu.citrix.com>
Cc: gavin <gbtux@126.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] A question on the credit scheduler
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: rshriram@cs.ubc.ca
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6443486809938595629=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============6443486809938595629==
Content-Type: multipart/alternative; boundary=000e0ce0d27e19034804b4743cab

--000e0ce0d27e19034804b4743cab
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

On Mon, Dec 19, 2011 at 4:37 AM, George Dunlap
<George.Dunlap@eu.citrix.com>wrote:

> 2011/12/17 gavin <gbtux@126.com>:
> >
> > At 2011-12-16 23:58:26,"George Dunlap" <George.Dunlap@eu.citrix.com
> > wrote:
> >>2011/12/16 gavin <gbtux@126.com>:
> >>> At 2011-12-16 19:04:19,"George Dunlap" <George.Dunlap@eu.citrix.com
> > wrote:
> >>>
> >>>>2011/12/16 zhikai <gbtux@126.com>:
> >>>>> Hi All,
> >>>>>
>
> >>>>> In the credit scheduler, the scheduling decision function csched_sc=
hedule()
>
> >>>>> is called in the schedule function in scheduler.c, such as the foll=
owing.
> >>>>> next_slice =3D sched->do_schedule(sched, now, tasklet_work_schedule=
d);
> >>>>>
> >>>>> But, how often the csched_schedule() is called and to run? Does thi=
s
>
> >>>>> frequency have something to do with the slice of credit scheduler t=
hat is
> >>>>> 30ms?
> >>>>
> >>>>The scheduler runs whenever the SCHEDULE_SOFTIRQ is raised.  If you
> >>>>grep through the source code fro that string, you can find all the
> >>>>places where it's raised.
> >>>>
> >>>>Some examples include:
> >>>>* When the 30ms timeslice is finished
>
> >>>>* When a sleeping vcpu of higher priority than what's currently runni=
ng wakes up
> >>>>* When a vcpu blocks
> >>>>* When a vcpu is migrated from one cpu to another
> >>>>
> >>>>30ms is actually a pretty long time; in typical workloads, vcpus bloc=
k
> >>>>or are preempted by other waking vcpus without using up their full
> >>>>timeslice.
> >>>
> >>> Thank you very much for your reply.
> >>>
>
> >>> So, the vcpu is very likely to be preempted whenever the SCHEDULE_SOF=
TIRQ is
> >>> raised.
> >>
> >>It depends; if you have a cpu-burning vcpu running on a cpu all by
> >>itself, then after its 30ms timeslice, Xen will have no one else to
> >>run, and so will let it run again.
> >>
> >>But yes, if there are other vcpus on the runqueue, or the host is
> >>moderately busy, it's likely that SCHEDULE_SOFTIRQ will cause a
> >>context-switch.
> >>
> >>> And we cannot find a small timeslice, such as a(ms), which makes the
>
> >>> time any vcpu spending on running phase is k*a(ms), k is integer here=
. There
> >>> is no such a small timeslice. Is it right?
> >>
> >>I'm sorry, I don't really understand your question.  Perhaps if you
> >>told me what you're trying to accomplish?
> >
> > I try to describe my idea as the following clearly. But I really don't
> know
> > if it will work. Please give me some advice if possible.
> >
> > According to the credit scheduler in Xen, a vCPU can run a 30ms timesli=
ce
> > when it is scheduled on the physical CPU. And, a vCPU with the BOOST
> > priority will preempt the running one and run additional 10ms. So, what=
 I
> > think is if we monitor the physical CPU every 10ms and we can get the
> > mapping information of a physical CPU and a vCPU. And also, we can get
> the
> > un-mapping information that a physical CPU isn=92t mapped to any vCPU.
> Thus,
> > we can get the CPU usage by calculating the proportion of the mapping
> > information to the total time when we monitored.
> >
> > For example, if we monitor the physical CPUs every 10ms and we can get
> 100
> > pairs of pCPU and vCPU in a second, such as (pCPU_id, vCPU_id). If ther=
e
> is
> > 60 mapping pairs that the pCPU is mapped to a valid vPCU, and 40
> un-mapping
> > pairs that we cannot find the pCPU to be mapped a valid vCPU. So, we ca=
n
> get
> > the usage of the physical CPUs that is 60%.
> >
> > Here, we monitor the physical CPUs every 10ms. We also can monitor them
> once
> > less than the 10ms interval, such as 1ms interval. Whatever interval we
> > choose, we must make sure no CPU content switch in the interval or the
> > context switch always occur at the edge of interval. Only in this
> condition,
> > can this idea work.
> >
> > So, I am not sure whether we can find such a time interval that can mee=
t
> > this condition. In other words, whether we can find such a time interva=
l
> > that ensures all the CPU content switch occur at the edge of interval.
>
> You still haven't described exactly what it is you're trying to
> accomplish: what is your end goal?  It seems to be related somehow to
> measuring how busy the system is (i.e., the number of active pcpus and
> idle pcpus); but as I don't know what you want to do with that
> information, I can't tell you the best way to get it.
>
> Regarding a map of pcpus to vcpus, that already exists.  The
> scheduling code will keep track of the currently running vcpu here:
>  per_cpu(schedule_data, pcpu_id).curr
>
> You can see examples of the above structure used in
> xen/common/sched_credit2.c.  If "is_idle(per_cpu(schedule_data,
> pcpu).curr)" is false, then the cpu is running a vcpu; if it is true,
> then the pcpu is idle (although it may be running a tasklet).
>
> Additionally, if all you want is the number of non-idle cpus, the
> credit1 scheduler keeps track of the idle and non-idle cpus in
> prv->idlers.  You could easily use "cpumask_weight(&prv->idlers)" to
> find out how many idle cpus there are at any given time.  If you know
> how many online cpus there are, that will give you the busy-ness of
> the system.
>
> So now that you have this instantaneous percentage, what do you want
> to do with it?
>
>
A tangential question:
 When you pin a pcpu to a vcpu (e.g. xm vcpu-pin 0 0 0),  are the soft irqs
for that cpu still raised ? (Lets assume for the sake of simplicity that
there
are 2 cpus in the system and 2 domains - a dom0 and a domU, each pinned
to one CPU).
 Do the vcpu pauses (and subsequent resumes with no context switch etc)
still happen due to the irqs or the scheduler code? Or will the scheduler
be effectively disabled in this scenario ?

shriram


 -George
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>

--000e0ce0d27e19034804b4743cab
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote">On Mon, Dec 19, 2011 at 4:37 AM, George Dunlap <=
span dir=3D"ltr">&lt;<a href=3D"mailto:George.Dunlap@eu.citrix.com">George.=
Dunlap@eu.citrix.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex=
">

2011/12/17 gavin &lt;<a href=3D"mailto:gbtux@126.com">gbtux@126.com</a>&gt;=
:<br>
<div><div class=3D"h5">&gt;<br>
&gt; At=A02011-12-16=A023:58:26,&quot;George=A0Dunlap&quot;=A0&lt;<a href=
=3D"mailto:George.Dunlap@eu.citrix.com">George.Dunlap@eu.citrix.com</a>&gt;=
=A0wrote:<br>
&gt;&gt;2011/12/16=A0gavin=A0&lt;<a href=3D"mailto:gbtux@126.com">gbtux@126=
.com</a>&gt;:<br>
&gt;&gt;&gt;=A0At=A02011-12-16=A019:04:19,&quot;George=A0Dunlap&quot;=A0&lt=
;<a href=3D"mailto:George.Dunlap@eu.citrix.com">George.Dunlap@eu.citrix.com=
</a>&gt;=A0wrote:<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;2011/12/16=A0zhikai=A0&lt;<a href=3D"mailto:gbtux@126.com">=
gbtux@126.com</a>&gt;:<br>
&gt;&gt;&gt;&gt;&gt;=A0Hi=A0All,<br>
&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;=A0In=A0the=A0credit=A0scheduler,=A0the=A0scheduling=A0=
decision=A0function=A0csched_schedule()<br>
&gt;&gt;&gt;&gt;&gt;=A0is=A0called=A0in=A0the=A0schedule=A0function=A0in=A0=
scheduler.c,=A0such=A0as=A0the=A0following.<br>
&gt;&gt;&gt;&gt;&gt;=A0next_slice=A0=3D=A0sched-&gt;do_schedule(sched,=A0no=
w,=A0tasklet_work_scheduled);<br>
&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;=A0But,=A0how=A0often=A0the=A0csched_schedule()=A0is=A0=
called=A0and=A0to=A0run?=A0Does=A0this<br>
&gt;&gt;&gt;&gt;&gt;=A0frequency=A0have=A0something=A0to=A0do=A0with=A0the=
=A0slice=A0of=A0credit=A0scheduler=A0that=A0is<br>
&gt;&gt;&gt;&gt;&gt;=A030ms?<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;The=A0scheduler=A0runs=A0whenever=A0the=A0SCHEDULE_SOFTIRQ=
=A0is=A0raised.=A0=A0If=A0you<br>
&gt;&gt;&gt;&gt;grep=A0through=A0the=A0source=A0code=A0fro=A0that=A0string,=
=A0you=A0can=A0find=A0all=A0the<br>
&gt;&gt;&gt;&gt;places=A0where=A0it&#39;s=A0raised.<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;Some=A0examples=A0include:<br>
&gt;&gt;&gt;&gt;*=A0When=A0the=A030ms=A0timeslice=A0is=A0finished<br>
&gt;&gt;&gt;&gt;*=A0When=A0a=A0sleeping=A0vcpu=A0of=A0higher=A0priority=A0t=
han=A0what&#39;s=A0currently=A0running=A0wakes=A0up<br>
&gt;&gt;&gt;&gt;*=A0When=A0a=A0vcpu=A0blocks<br>
&gt;&gt;&gt;&gt;*=A0When=A0a=A0vcpu=A0is=A0migrated=A0from=A0one=A0cpu=A0to=
=A0another<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;30ms=A0is=A0actually=A0a=A0pretty=A0long=A0time;=A0in=A0typ=
ical=A0workloads,=A0vcpus=A0block<br>
&gt;&gt;&gt;&gt;or=A0are=A0preempted=A0by=A0other=A0waking=A0vcpus=A0withou=
t=A0using=A0up=A0their=A0full<br>
&gt;&gt;&gt;&gt;timeslice.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;=A0Thank=A0you=A0very=A0much=A0for=A0your=A0reply.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;=A0So,=A0the=A0vcpu=A0is=A0very=A0likely=A0to=A0be=A0preempted=
=A0whenever=A0the=A0SCHEDULE_SOFTIRQ=A0is<br>
&gt;&gt;&gt;=A0raised.<br>
&gt;&gt;<br>
&gt;&gt;It=A0depends;=A0if=A0you=A0have=A0a=A0cpu-burning=A0vcpu=A0running=
=A0on=A0a=A0cpu=A0all=A0by<br>
&gt;&gt;itself,=A0then=A0after=A0its=A030ms=A0timeslice,=A0Xen=A0will=A0hav=
e=A0no=A0one=A0else=A0to<br>
&gt;&gt;run,=A0and=A0so=A0will=A0let=A0it=A0run=A0again.<br>
&gt;&gt;<br>
&gt;&gt;But=A0yes,=A0if=A0there=A0are=A0other=A0vcpus=A0on=A0the=A0runqueue=
,=A0or=A0the=A0host=A0is<br>
&gt;&gt;moderately=A0busy,=A0it&#39;s=A0likely=A0that=A0SCHEDULE_SOFTIRQ=A0=
will=A0cause=A0a<br>
&gt;&gt;context-switch.<br>
&gt;&gt;<br>
&gt;&gt;&gt;=A0And=A0we=A0cannot=A0find=A0a=A0small=A0timeslice,=A0such=A0a=
s=A0a(ms),=A0which=A0makes=A0the<br>
&gt;&gt;&gt;=A0time=A0any=A0vcpu=A0spending=A0on=A0running=A0phase=A0is=A0k=
*a(ms),=A0k=A0is=A0integer=A0here.=A0There<br>
&gt;&gt;&gt;=A0is=A0no=A0such=A0a=A0small=A0timeslice.=A0Is=A0it=A0right?<b=
r>
&gt;&gt;<br>
&gt;&gt;I&#39;m=A0sorry,=A0I=A0don&#39;t=A0really=A0understand=A0your=A0que=
stion.=A0=A0Perhaps=A0if=A0you<br>
&gt;&gt;told=A0me=A0what=A0you&#39;re=A0trying=A0to=A0accomplish?<br>
&gt;<br>
&gt; I try to describe my idea as the following clearly. But I really don&#=
39;t know<br>
&gt; if it will work. Please give me some advice if possible.<br>
&gt;<br>
&gt; According to the credit scheduler in Xen, a vCPU can run a 30ms timesl=
ice<br>
&gt; when it is scheduled on the physical CPU. And, a vCPU with the BOOST<b=
r>
&gt; priority will preempt the running one and run additional 10ms. So, wha=
t I<br>
&gt; think is if we monitor the physical CPU every 10ms and we can get the<=
br>
&gt; mapping information of a physical CPU and a vCPU. And also, we can get=
 the<br>
&gt; un-mapping information that a physical CPU isn=92t mapped to any vCPU.=
 Thus,<br>
&gt; we can get the CPU usage by calculating the proportion of the mapping<=
br>
&gt; information to the total time when we monitored.<br>
&gt;<br>
&gt; For example, if we monitor the physical CPUs every 10ms and we can get=
 100<br>
&gt; pairs of pCPU and vCPU in a second, such as (pCPU_id, vCPU_id). If the=
re is<br>
&gt; 60 mapping pairs that the pCPU is mapped to a valid vPCU, and 40 un-ma=
pping<br>
&gt; pairs that we cannot find the pCPU to be mapped a valid vCPU. So, we c=
an get<br>
&gt; the usage of the physical CPUs that is 60%.<br>
&gt;<br>
&gt; Here, we monitor the physical CPUs every 10ms. We also can monitor the=
m once<br>
&gt; less than the 10ms interval, such as 1ms interval. Whatever interval w=
e<br>
&gt; choose, we must make sure no CPU content switch in the interval or the=
<br>
&gt; context switch always occur at the edge of interval. Only in this cond=
ition,<br>
&gt; can this idea work.<br>
&gt;<br>
&gt; So, I am not sure whether we can find such a time interval that can me=
et<br>
&gt; this condition. In other words, whether we can find such a time interv=
al<br>
&gt; that ensures all the CPU content switch occur at the edge of interval.=
<br>
<br>
</div></div>You still haven&#39;t described exactly what it is you&#39;re t=
rying to<br>
accomplish: what is your end goal? =A0It seems to be related somehow to<br>
measuring how busy the system is (i.e., the number of active pcpus and<br>
idle pcpus); but as I don&#39;t know what you want to do with that<br>
information, I can&#39;t tell you the best way to get it.<br>
<br>
Regarding a map of pcpus to vcpus, that already exists. =A0The<br>
scheduling code will keep track of the currently running vcpu here:<br>
 =A0per_cpu(schedule_data, pcpu_id).curr<br>
<br>
You can see examples of the above structure used in<br>
xen/common/sched_credit2.c. =A0If &quot;is_idle(per_cpu(schedule_data,<br>
pcpu).curr)&quot; is false, then the cpu is running a vcpu; if it is true,<=
br>
then the pcpu is idle (although it may be running a tasklet).<br>
<br>
Additionally, if all you want is the number of non-idle cpus, the<br>
credit1 scheduler keeps track of the idle and non-idle cpus in<br>
prv-&gt;idlers. =A0You could easily use &quot;cpumask_weight(&amp;prv-&gt;i=
dlers)&quot; to<br>
find out how many idle cpus there are at any given time. =A0If you know<br>
how many online cpus there are, that will give you the busy-ness of<br>
the system.<br>
<br>
So now that you have this instantaneous percentage, what do you want<br>
to do with it?<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br></div></div></blockquote><div><=
br>A tangential question:<br>=A0When you pin a pcpu to a vcpu (e.g. xm vcpu=
-pin 0 0 0),=A0 are the soft irqs<br>for that cpu still raised ? (Lets assu=
me for the sake of simplicity that there<br>

are 2 cpus in the system and 2 domains - a dom0 and a domU, each pinned<br>=
to one CPU).<br>=A0Do the vcpu pauses (and subsequent resumes with no conte=
xt switch etc)<br>still happen due to the irqs or the scheduler code? Or wi=
ll the scheduler<br>

be effectively disabled in this scenario ?<br><br>shriram<br><br><br></div>=
<blockquote class=3D"gmail_quote" style=3D"margin:0pt 0pt 0pt 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex"><div class=3D"HOEnZb"><di=
v class=3D"h5">


=A0-George<br>
<br>
_______________________________________________<br>
Xen-devel mailing list<br>
<a href=3D"mailto:Xen-devel@lists.xensource.com">Xen-devel@lists.xensource.=
com</a><br>
<a href=3D"http://lists.xensource.com/xen-devel" target=3D"_blank">http://l=
ists.xensource.com/xen-devel</a><br>
</div></div></blockquote></div><br>

--000e0ce0d27e19034804b4743cab--


--===============6443486809938595629==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============6443486809938595629==--


From xen-devel-bounces@lists.xensource.com Mon Dec 19 16:39:39 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 16: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.xensource.com>)
	id 1RcgF4-0001Bu-1r; Mon, 19 Dec 2011 16:39:10 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RcgF3-0001Bp-35
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 16:39:09 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1324312741!8059100!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3405 invoked from network); 19 Dec 2011 16:39:02 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-8.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 19 Dec 2011 16:39:02 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 19 Dec 2011 16:39:01 +0000
Message-Id: <4EEF76EA0200007800068E16@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 19 Dec 2011 16:39:54 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "George Dunlap" <George.Dunlap@eu.citrix.com>
References: <4EBA58F2020000780005FCCC@nat28.tlf.novell.com>
	<CAFQ2Z+d_Oq+6L9x=V9mPJ2jTSOa5k5k2Cpgyd9rYBsrOcMeFQw@mail.gmail.com>
	<CAFLBxZah=GegCYJf4TCc5awEyHwRU9hz0xzyAqokaDLs5i7Xfg@mail.gmail.com>
	<CAFLBxZY5tjCaG3c6CpQXHg7cTKkK4--tGFF1pX7pMkvyScLe6w@mail.gmail.com>
In-Reply-To: <CAFLBxZY5tjCaG3c6CpQXHg7cTKkK4--tGFF1pX7pMkvyScLe6w@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Yang Z Zhang <yang.z.zhang@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Haitao Shan <haitao.shan@intel.com>
Subject: Re: [Xen-devel] [PATCH] x86/cpuidle: add Westmere-EX support to hw
 residencies reading logic
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 19.12.11 at 17:09, George Dunlap <George.Dunlap@eu.citrix.com> wrote:
> Ping?

Oops - was the original question directed to me, and overlooked it?

Anyway - it can easily be backported, but I don't view it as a critical fix.

Jan

> On Wed, Dec 14, 2011 at 4:12 PM, George Dunlap
> <George.Dunlap@eu.citrix.com> wrote:
>> Should this be back-ported to 4.1?
>>  -George
>>
>> On Wed, Nov 30, 2011 at 6:13 AM, Haitao Shan <maillists.shan@gmail.com> wrote:
>>> ACK!
>>> Thanks Jan for making the cpu model list more complete.
>>>
>>> Shan Haitao
>>>
>>> 2011/11/9 Jan Beulich <JBeulich@suse.com>:
>>>> This is in accordance with
>>>> 
> http://software.intel.com/en-us/articles/intel-processor-identification-with-cpuid 
> -model-and-family-numbers/
>>>>
>>>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>>>>
>>>> --- a/xen/arch/x86/acpi/cpu_idle.c
>>>> +++ b/xen/arch/x86/acpi/cpu_idle.c
>>>> @@ -120,6 +120,7 @@ static void do_get_hw_residencies(void *
>>>>     /* Westmere */
>>>>     case 0x25:
>>>>     case 0x2C:
>>>> +    case 0x2F:
>>>>         GET_PC3_RES(hw_res->pc3);
>>>>         GET_PC6_RES(hw_res->pc6);
>>>>         GET_PC7_RES(hw_res->pc7);
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Xen-devel mailing list
>>>> Xen-devel@lists.xensource.com 
>>>> http://lists.xensource.com/xen-devel 
>>>>
>>>>
>>>
>>> _______________________________________________
>>> Xen-devel mailing list
>>> Xen-devel@lists.xensource.com 
>>> http://lists.xensource.com/xen-devel 




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 16:39:39 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 16: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.xensource.com>)
	id 1RcgF4-0001Bu-1r; Mon, 19 Dec 2011 16:39:10 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RcgF3-0001Bp-35
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 16:39:09 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1324312741!8059100!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3405 invoked from network); 19 Dec 2011 16:39:02 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-8.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 19 Dec 2011 16:39:02 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 19 Dec 2011 16:39:01 +0000
Message-Id: <4EEF76EA0200007800068E16@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 19 Dec 2011 16:39:54 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "George Dunlap" <George.Dunlap@eu.citrix.com>
References: <4EBA58F2020000780005FCCC@nat28.tlf.novell.com>
	<CAFQ2Z+d_Oq+6L9x=V9mPJ2jTSOa5k5k2Cpgyd9rYBsrOcMeFQw@mail.gmail.com>
	<CAFLBxZah=GegCYJf4TCc5awEyHwRU9hz0xzyAqokaDLs5i7Xfg@mail.gmail.com>
	<CAFLBxZY5tjCaG3c6CpQXHg7cTKkK4--tGFF1pX7pMkvyScLe6w@mail.gmail.com>
In-Reply-To: <CAFLBxZY5tjCaG3c6CpQXHg7cTKkK4--tGFF1pX7pMkvyScLe6w@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Yang Z Zhang <yang.z.zhang@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Haitao Shan <haitao.shan@intel.com>
Subject: Re: [Xen-devel] [PATCH] x86/cpuidle: add Westmere-EX support to hw
 residencies reading logic
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 19.12.11 at 17:09, George Dunlap <George.Dunlap@eu.citrix.com> wrote:
> Ping?

Oops - was the original question directed to me, and overlooked it?

Anyway - it can easily be backported, but I don't view it as a critical fix.

Jan

> On Wed, Dec 14, 2011 at 4:12 PM, George Dunlap
> <George.Dunlap@eu.citrix.com> wrote:
>> Should this be back-ported to 4.1?
>>  -George
>>
>> On Wed, Nov 30, 2011 at 6:13 AM, Haitao Shan <maillists.shan@gmail.com> wrote:
>>> ACK!
>>> Thanks Jan for making the cpu model list more complete.
>>>
>>> Shan Haitao
>>>
>>> 2011/11/9 Jan Beulich <JBeulich@suse.com>:
>>>> This is in accordance with
>>>> 
> http://software.intel.com/en-us/articles/intel-processor-identification-with-cpuid 
> -model-and-family-numbers/
>>>>
>>>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>>>>
>>>> --- a/xen/arch/x86/acpi/cpu_idle.c
>>>> +++ b/xen/arch/x86/acpi/cpu_idle.c
>>>> @@ -120,6 +120,7 @@ static void do_get_hw_residencies(void *
>>>>     /* Westmere */
>>>>     case 0x25:
>>>>     case 0x2C:
>>>> +    case 0x2F:
>>>>         GET_PC3_RES(hw_res->pc3);
>>>>         GET_PC6_RES(hw_res->pc6);
>>>>         GET_PC7_RES(hw_res->pc7);
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Xen-devel mailing list
>>>> Xen-devel@lists.xensource.com 
>>>> http://lists.xensource.com/xen-devel 
>>>>
>>>>
>>>
>>> _______________________________________________
>>> Xen-devel mailing list
>>> Xen-devel@lists.xensource.com 
>>> http://lists.xensource.com/xen-devel 




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 16:46:08 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 16:46:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RcgLR-0001L3-Sw; Mon, 19 Dec 2011 16:45:45 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1RcgLQ-0001Ku-84
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 16:45:44 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1324313136!8849717!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjM2NDM=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16610 invoked from network); 19 Dec 2011 16:45: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;
	19 Dec 2011 16:45:38 -0000
X-IronPort-AV: E=Sophos;i="4.71,377,1320642000"; d="scan'208";a="174709681"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Dec 2011 11:45:10 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Mon, 19 Dec 2011 11:45:10 -0500
Received: from [10.80.2.24] (elijah.uk.xensource.com [10.80.2.24])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pBJGj6pg026808;
	Mon, 19 Dec 2011 08:45:07 -0800
From: George Dunlap <george.dunlap@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
In-Reply-To: <4EEF686E0200007800068DCC@nat28.tlf.novell.com>
References: <C10D3FB0CD45994C8A51FEC1227CE22F37CC284376@shsmsx502.ccr.corp.intel.com>
	<4EEF02E20200007800068C60@nat28.tlf.novell.com>
	<CAFLBxZb3Yc7G4QzEXKdfrVkoz1XGv09zTxCQCC4Dnkr-6M5K5Q@mail.gmail.com>
	<4EEF36A60200007800068D43@nat28.tlf.novell.com>
	<CAFLBxZahyAJ5Y7+eGGCkoOKZZGQ4rYwdZutyjAMH2CcQhDkcZw@mail.gmail.com>
	<4EEF5F720200007800068DB3@nat28.tlf.novell.com>
	<C10D3FB0CD45994C8A51FEC1227CE22F39412A972F@shsmsx502.ccr.corp.intel.com>
	<4EEF686E0200007800068DCC@nat28.tlf.novell.com>
Date: Mon, 19 Dec 2011 16:48:48 +0000
Message-ID: <1324313328.2143.74.camel@elijah>
MIME-Version: 1.0
X-Mailer: Evolution 2.28.3 
Cc: Kevin Tian <kevin.tian@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Keir
	\(Xen.org\)" <keir@xen.org>, George Dunlap <George.Dunlap@eu.citrix.com>,
	Eddie Dong <eddie.dong@intel.com>, Hui Lv <hui.lv@intel.com>,
	Jiangang Duan <jiangang.duan@intel.com>, Zhidong Yu <zhidong.yu@intel.com>
Subject: Re: [Xen-devel] [PATCH v2] xen/credit scheduler;
 Use delay to control scheduling frequency
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2011-12-19 at 15:38 +0000, Jan Beulich wrote:
> >>> On 19.12.11 at 16:25, "Lv, Hui" <hui.lv@intel.com> wrote:
> >> Overriding the rate limit by the time slice isn't the right thing either, as 
> > that
> >> (the way I "read" it) means there's no rate limiting at all.
> >> What "rate limit" to me means is preventing quickly switching away from a
> >> vCPU recently scheduled without extending its (remaining) time slice, i.e. 
> > in any
> >> place a respective evaluation is done the shorter of the two should be used.
> >> 
> >> Jan
> > 
> > So the basic thing is to avoid "time slice" < "rate limit", happen.
> > I really don't understand why people want a 1ms time slice, but set the 
> > rate_limit to 5000(us), that is insubstantial.
> 
> So if someone set the (global) rate limit value to 5000us and then,
> days or weeks later, migrates a VM with a 3ms time slice to that
> host, why should this be an admin mistake? To me, the rate limit is a
> performance improvement, while the time slice may be (an indirect
> result of) a to be enforced policy.

Right now the timeslice is effectively global.  There's a per-scheduler
variable, but it's only set from the boot-time option.  Before 4.2 I'm
going to add some code that will allow that to be changed on a scheduler
granularity; but there was never a plan to make it per-VM.

It would make sense, in theory, to let the VM run for the rest of its
timeslice; but there's not an easy way at the moment to get that
information from an already-running vcpu.  The timescales we're talking
about here are so small that it doesn't seem worth the extra
complication to me.

We're really bike-shedding at this point.  I don't think
functionality-wise it matters either way, and the code is simpler the
way it is.  I think we should just leave it.

 -George


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 16:46:08 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 16:46:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RcgLR-0001L3-Sw; Mon, 19 Dec 2011 16:45:45 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1RcgLQ-0001Ku-84
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 16:45:44 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1324313136!8849717!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjM2NDM=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16610 invoked from network); 19 Dec 2011 16:45: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;
	19 Dec 2011 16:45:38 -0000
X-IronPort-AV: E=Sophos;i="4.71,377,1320642000"; d="scan'208";a="174709681"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Dec 2011 11:45:10 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Mon, 19 Dec 2011 11:45:10 -0500
Received: from [10.80.2.24] (elijah.uk.xensource.com [10.80.2.24])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pBJGj6pg026808;
	Mon, 19 Dec 2011 08:45:07 -0800
From: George Dunlap <george.dunlap@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
In-Reply-To: <4EEF686E0200007800068DCC@nat28.tlf.novell.com>
References: <C10D3FB0CD45994C8A51FEC1227CE22F37CC284376@shsmsx502.ccr.corp.intel.com>
	<4EEF02E20200007800068C60@nat28.tlf.novell.com>
	<CAFLBxZb3Yc7G4QzEXKdfrVkoz1XGv09zTxCQCC4Dnkr-6M5K5Q@mail.gmail.com>
	<4EEF36A60200007800068D43@nat28.tlf.novell.com>
	<CAFLBxZahyAJ5Y7+eGGCkoOKZZGQ4rYwdZutyjAMH2CcQhDkcZw@mail.gmail.com>
	<4EEF5F720200007800068DB3@nat28.tlf.novell.com>
	<C10D3FB0CD45994C8A51FEC1227CE22F39412A972F@shsmsx502.ccr.corp.intel.com>
	<4EEF686E0200007800068DCC@nat28.tlf.novell.com>
Date: Mon, 19 Dec 2011 16:48:48 +0000
Message-ID: <1324313328.2143.74.camel@elijah>
MIME-Version: 1.0
X-Mailer: Evolution 2.28.3 
Cc: Kevin Tian <kevin.tian@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Keir
	\(Xen.org\)" <keir@xen.org>, George Dunlap <George.Dunlap@eu.citrix.com>,
	Eddie Dong <eddie.dong@intel.com>, Hui Lv <hui.lv@intel.com>,
	Jiangang Duan <jiangang.duan@intel.com>, Zhidong Yu <zhidong.yu@intel.com>
Subject: Re: [Xen-devel] [PATCH v2] xen/credit scheduler;
 Use delay to control scheduling frequency
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2011-12-19 at 15:38 +0000, Jan Beulich wrote:
> >>> On 19.12.11 at 16:25, "Lv, Hui" <hui.lv@intel.com> wrote:
> >> Overriding the rate limit by the time slice isn't the right thing either, as 
> > that
> >> (the way I "read" it) means there's no rate limiting at all.
> >> What "rate limit" to me means is preventing quickly switching away from a
> >> vCPU recently scheduled without extending its (remaining) time slice, i.e. 
> > in any
> >> place a respective evaluation is done the shorter of the two should be used.
> >> 
> >> Jan
> > 
> > So the basic thing is to avoid "time slice" < "rate limit", happen.
> > I really don't understand why people want a 1ms time slice, but set the 
> > rate_limit to 5000(us), that is insubstantial.
> 
> So if someone set the (global) rate limit value to 5000us and then,
> days or weeks later, migrates a VM with a 3ms time slice to that
> host, why should this be an admin mistake? To me, the rate limit is a
> performance improvement, while the time slice may be (an indirect
> result of) a to be enforced policy.

Right now the timeslice is effectively global.  There's a per-scheduler
variable, but it's only set from the boot-time option.  Before 4.2 I'm
going to add some code that will allow that to be changed on a scheduler
granularity; but there was never a plan to make it per-VM.

It would make sense, in theory, to let the VM run for the rest of its
timeslice; but there's not an easy way at the moment to get that
information from an already-running vcpu.  The timescales we're talking
about here are so small that it doesn't seem worth the extra
complication to me.

We're really bike-shedding at this point.  I don't think
functionality-wise it matters either way, and the code is simpler the
way it is.  I think we should just leave it.

 -George


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 17:03:57 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 17:03:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RcgcZ-0002AM-DK; Mon, 19 Dec 2011 17:03:27 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RcgcY-0002AG-Ku
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 17:03:26 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1324314163!47352018!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29351 invoked from network); 19 Dec 2011 17:02:43 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-5.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 19 Dec 2011 17:02:43 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 19 Dec 2011 17:03:23 +0000
Message-Id: <4EEF7CA00200007800068E3D@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 19 Dec 2011 17:04:16 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "George Dunlap" <george.dunlap@citrix.com>, <George.Dunlap@eu.citrix.com>
References: <C10D3FB0CD45994C8A51FEC1227CE22F37CC284376@shsmsx502.ccr.corp.intel.com>
	<4EEF02E20200007800068C60@nat28.tlf.novell.com>
	<CAFLBxZb3Yc7G4QzEXKdfrVkoz1XGv09zTxCQCC4Dnkr-6M5K5Q@mail.gmail.com>
	<4EEF36A60200007800068D43@nat28.tlf.novell.com>
	<CAFLBxZahyAJ5Y7+eGGCkoOKZZGQ4rYwdZutyjAMH2CcQhDkcZw@mail.gmail.com>
	<4EEF5F720200007800068DB3@nat28.tlf.novell.com>
	<C10D3FB0CD45994C8A51FEC1227CE22F39412A972F@shsmsx502.ccr.corp.intel.com>
	<4EEF686E0200007800068DCC@nat28.tlf.novell.com>
	<1324313328.2143.74.camel@elijah>
In-Reply-To: <1324313328.2143.74.camel@elijah>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Kevin Tian <kevin.tian@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Keir\(Xen.org\)" <keir@xen.org>,
	Eddie Dong <eddie.dong@intel.com>, Hui Lv <hui.lv@intel.com>,
	Jiangang Duan <jiangang.duan@intel.com>, Zhidong Yu <zhidong.yu@intel.com>
Subject: Re: [Xen-devel] [PATCH v2] xen/credit scheduler;
 Use delay to control scheduling frequency
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 19.12.11 at 17:48, George Dunlap <george.dunlap@citrix.com> wrote:
> On Mon, 2011-12-19 at 15:38 +0000, Jan Beulich wrote:
>> >>> On 19.12.11 at 16:25, "Lv, Hui" <hui.lv@intel.com> wrote:
>> >> Overriding the rate limit by the time slice isn't the right thing either, 
> as 
>> > that
>> >> (the way I "read" it) means there's no rate limiting at all.
>> >> What "rate limit" to me means is preventing quickly switching away from a
>> >> vCPU recently scheduled without extending its (remaining) time slice, i.e. 
>> > in any
>> >> place a respective evaluation is done the shorter of the two should be 
> used.
>> >> 
>> >> Jan
>> > 
>> > So the basic thing is to avoid "time slice" < "rate limit", happen.
>> > I really don't understand why people want a 1ms time slice, but set the 
>> > rate_limit to 5000(us), that is insubstantial.
>> 
>> So if someone set the (global) rate limit value to 5000us and then,
>> days or weeks later, migrates a VM with a 3ms time slice to that
>> host, why should this be an admin mistake? To me, the rate limit is a
>> performance improvement, while the time slice may be (an indirect
>> result of) a to be enforced policy.
> 
> Right now the timeslice is effectively global.  There's a per-scheduler
> variable, but it's only set from the boot-time option.  Before 4.2 I'm
> going to add some code that will allow that to be changed on a scheduler
> granularity; but there was never a plan to make it per-VM.

Oh, okay, I missed that point. In that case just warning about the
two values having a bad relation would seem fine.

Sorry for the noise then.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 17:03:57 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 17:03:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RcgcZ-0002AM-DK; Mon, 19 Dec 2011 17:03:27 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RcgcY-0002AG-Ku
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 17:03:26 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1324314163!47352018!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29351 invoked from network); 19 Dec 2011 17:02:43 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-5.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 19 Dec 2011 17:02:43 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 19 Dec 2011 17:03:23 +0000
Message-Id: <4EEF7CA00200007800068E3D@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 19 Dec 2011 17:04:16 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "George Dunlap" <george.dunlap@citrix.com>, <George.Dunlap@eu.citrix.com>
References: <C10D3FB0CD45994C8A51FEC1227CE22F37CC284376@shsmsx502.ccr.corp.intel.com>
	<4EEF02E20200007800068C60@nat28.tlf.novell.com>
	<CAFLBxZb3Yc7G4QzEXKdfrVkoz1XGv09zTxCQCC4Dnkr-6M5K5Q@mail.gmail.com>
	<4EEF36A60200007800068D43@nat28.tlf.novell.com>
	<CAFLBxZahyAJ5Y7+eGGCkoOKZZGQ4rYwdZutyjAMH2CcQhDkcZw@mail.gmail.com>
	<4EEF5F720200007800068DB3@nat28.tlf.novell.com>
	<C10D3FB0CD45994C8A51FEC1227CE22F39412A972F@shsmsx502.ccr.corp.intel.com>
	<4EEF686E0200007800068DCC@nat28.tlf.novell.com>
	<1324313328.2143.74.camel@elijah>
In-Reply-To: <1324313328.2143.74.camel@elijah>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Kevin Tian <kevin.tian@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Keir\(Xen.org\)" <keir@xen.org>,
	Eddie Dong <eddie.dong@intel.com>, Hui Lv <hui.lv@intel.com>,
	Jiangang Duan <jiangang.duan@intel.com>, Zhidong Yu <zhidong.yu@intel.com>
Subject: Re: [Xen-devel] [PATCH v2] xen/credit scheduler;
 Use delay to control scheduling frequency
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 19.12.11 at 17:48, George Dunlap <george.dunlap@citrix.com> wrote:
> On Mon, 2011-12-19 at 15:38 +0000, Jan Beulich wrote:
>> >>> On 19.12.11 at 16:25, "Lv, Hui" <hui.lv@intel.com> wrote:
>> >> Overriding the rate limit by the time slice isn't the right thing either, 
> as 
>> > that
>> >> (the way I "read" it) means there's no rate limiting at all.
>> >> What "rate limit" to me means is preventing quickly switching away from a
>> >> vCPU recently scheduled without extending its (remaining) time slice, i.e. 
>> > in any
>> >> place a respective evaluation is done the shorter of the two should be 
> used.
>> >> 
>> >> Jan
>> > 
>> > So the basic thing is to avoid "time slice" < "rate limit", happen.
>> > I really don't understand why people want a 1ms time slice, but set the 
>> > rate_limit to 5000(us), that is insubstantial.
>> 
>> So if someone set the (global) rate limit value to 5000us and then,
>> days or weeks later, migrates a VM with a 3ms time slice to that
>> host, why should this be an admin mistake? To me, the rate limit is a
>> performance improvement, while the time slice may be (an indirect
>> result of) a to be enforced policy.
> 
> Right now the timeslice is effectively global.  There's a per-scheduler
> variable, but it's only set from the boot-time option.  Before 4.2 I'm
> going to add some code that will allow that to be changed on a scheduler
> granularity; but there was never a plan to make it per-VM.

Oh, okay, I missed that point. In that case just warning about the
two values having a bad relation would seem fine.

Sorry for the noise then.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 17:28:45 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 17:28:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rch0d-0002NO-KQ; Mon, 19 Dec 2011 17:28:19 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1Rch0c-0002NJ-G0
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 17:28:18 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1324315692!8054184!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzA0OQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7495 invoked from network); 19 Dec 2011 17:28:12 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Dec 2011 17:28:12 -0000
X-IronPort-AV: E=Sophos;i="4.71,377,1320624000"; 
   d="scan'208";a="9562871"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Dec 2011 17:28:11 +0000
Received: from dhcp-3-28.uk.xensource.com (10.80.3.28) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 19 Dec 2011 17:28:11 +0000
Date: Mon, 19 Dec 2011 17:27:55 +0000
From: Anthony PERARD <anthony.perard@citrix.com>
X-X-Sender: anthony@perard.uk.xensource.com
To: Luiz Capitulino <lcapitulino@redhat.com>
In-Reply-To: <20111215143131.75239a3e@doriath>
Message-ID: <alpine.DEB.2.00.1112191637230.11530@perard.uk.xensource.com>
References: <1323467645-24271-1-git-send-email-anthony.perard@citrix.com>
	<1323467645-24271-4-git-send-email-anthony.perard@citrix.com>
	<4EEA0EB8.4020203@codemonkey.ws> <20111215143131.75239a3e@doriath>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Xen Devel <xen-devel@lists.xensource.com>,
	QEMU-devel <qemu-devel@nongnu.org>,
	Anthony Liguori <anthony@codemonkey.ws>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH V2 3/5] Introduce premigrate
	RunState.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 15 Dec 2011, Luiz Capitulino wrote:

> On Thu, 15 Dec 2011 09:14:00 -0600
> Anthony Liguori <anthony@codemonkey.ws> wrote:
>
> > On 12/09/2011 03:54 PM, Anthony PERARD wrote:
> > > This new state will be used by Xen functions to know QEMU will wait for a
> > > migration. This is important to know for memory related function because the
> > > memory is already allocated and reallocated them will not works.
>
> How is premigrate different from inmigrate? It looks like the same thing to me.

The inmigrate state is used during machine initilisation. So this state
replace the prelauch state (during machine.init) when a migration will be done.

inmigrate is set only when the initilisation of the machine is over.

Regards,

-- 
Anthony PERARD

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 17:28:45 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 17:28:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rch0d-0002NO-KQ; Mon, 19 Dec 2011 17:28:19 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1Rch0c-0002NJ-G0
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 17:28:18 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1324315692!8054184!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzA0OQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7495 invoked from network); 19 Dec 2011 17:28:12 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Dec 2011 17:28:12 -0000
X-IronPort-AV: E=Sophos;i="4.71,377,1320624000"; 
   d="scan'208";a="9562871"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Dec 2011 17:28:11 +0000
Received: from dhcp-3-28.uk.xensource.com (10.80.3.28) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 19 Dec 2011 17:28:11 +0000
Date: Mon, 19 Dec 2011 17:27:55 +0000
From: Anthony PERARD <anthony.perard@citrix.com>
X-X-Sender: anthony@perard.uk.xensource.com
To: Luiz Capitulino <lcapitulino@redhat.com>
In-Reply-To: <20111215143131.75239a3e@doriath>
Message-ID: <alpine.DEB.2.00.1112191637230.11530@perard.uk.xensource.com>
References: <1323467645-24271-1-git-send-email-anthony.perard@citrix.com>
	<1323467645-24271-4-git-send-email-anthony.perard@citrix.com>
	<4EEA0EB8.4020203@codemonkey.ws> <20111215143131.75239a3e@doriath>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Xen Devel <xen-devel@lists.xensource.com>,
	QEMU-devel <qemu-devel@nongnu.org>,
	Anthony Liguori <anthony@codemonkey.ws>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH V2 3/5] Introduce premigrate
	RunState.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 15 Dec 2011, Luiz Capitulino wrote:

> On Thu, 15 Dec 2011 09:14:00 -0600
> Anthony Liguori <anthony@codemonkey.ws> wrote:
>
> > On 12/09/2011 03:54 PM, Anthony PERARD wrote:
> > > This new state will be used by Xen functions to know QEMU will wait for a
> > > migration. This is important to know for memory related function because the
> > > memory is already allocated and reallocated them will not works.
>
> How is premigrate different from inmigrate? It looks like the same thing to me.

The inmigrate state is used during machine initilisation. So this state
replace the prelauch state (during machine.init) when a migration will be done.

inmigrate is set only when the initilisation of the machine is over.

Regards,

-- 
Anthony PERARD

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 17:52:46 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 17:52:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RchNm-0002jY-O0; Mon, 19 Dec 2011 17:52:14 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RchNl-0002jT-5C
	for Xen-devel@lists.xensource.com; Mon, 19 Dec 2011 17:52:13 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-6.tower-182.messagelabs.com!1324317126!7884775!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31495 invoked from network); 19 Dec 2011 17:52:06 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-6.tower-182.messagelabs.com with SMTP;
	19 Dec 2011 17:52:06 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea01.nsa.gov (8.12.10/8.12.10) with ESMTP id
	pBJHpFws008481; Mon, 19 Dec 2011 17:51:15 GMT
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id pBJHpCc7015423; 
	Mon, 19 Dec 2011 12:51:14 -0500
Message-ID: <4EEF7993.2060301@tycho.nsa.gov>
Date: Mon, 19 Dec 2011 12:51:15 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:8.0) Gecko/20111115 Thunderbird/8.0
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
References: <1323893534-436-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1323893534-436-2-git-send-email-dgdegra@tycho.nsa.gov>
	<20111216195620.GB26802@andromeda.dapyr.net>
In-Reply-To: <20111216195620.GB26802@andromeda.dapyr.net>
Cc: Xen-devel@lists.xensource.com, konrad.wilk@oracle.com
Subject: Re: [Xen-devel] [PATCH 1/6] xenbus: Support HVM backends
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 12/16/2011 02:56 PM, Konrad Rzeszutek Wilk wrote:
> On Wed, Dec 14, 2011 at 03:12:09PM -0500, Daniel De Graaf wrote:
>> Add HVM implementations of xenbus_(map,unmap)_ring_v(alloc,free) so
>> that ring mappings can be done without using GNTMAP_contains_pte which
>> is not supported on HVM.
>>
>> Signed-off-by: Daniel De Graaf<dgdegra@tycho.nsa.gov>
>> ---
>>   drivers/xen/xenbus/xenbus_client.c |  155 +++++++++++++++++++++++++++++-------
>>   1 files changed, 125 insertions(+), 30 deletions(-)
>>
>> diff --git a/drivers/xen/xenbus/xenbus_client.c b/drivers/xen/xenbus/xenbus_client.c
>> index 1906125..ecd695d 100644
>> --- a/drivers/xen/xenbus/xenbus_client.c
>> +++ b/drivers/xen/xenbus/xenbus_client.c
>> @@ -32,16 +32,27 @@
>>
>>   #include<linux/slab.h>
>>   #include<linux/types.h>
>> +#include<linux/spinlock.h>
>>   #include<linux/vmalloc.h>
>>   #include<linux/export.h>
>>   #include<asm/xen/hypervisor.h>
>>   #include<asm/xen/page.h>
>>   #include<xen/interface/xen.h>
>>   #include<xen/interface/event_channel.h>
>> +#include<xen/balloon.h>
>>   #include<xen/events.h>
>>   #include<xen/grant_table.h>
>>   #include<xen/xenbus.h>
>>
>> +struct xenbus_map_node {
>> +	struct list_head next;
>> +	struct page *page;
>> +	grant_handle_t handle;
>> +};
>> +
>> +static DEFINE_SPINLOCK(xenbus_valloc_lock);
>> +static LIST_HEAD(xenbus_valloc_pages);
>
> Could we use this for what the PV version of xenbus_unmap_ring_vfree
> does? (where it uses the vmlist_lock to look for the appropiate vaddr).
>
> Could the vmlist_lock be removed and instead we can use this structure
> for both PV and HVM?

Yes, the next version will do this.

[...]
>> +
>> +/**
>> + * xenbus_map_ring_valloc
>> + * @dev: xenbus device
>> + * @gnt_ref: grant reference
>> + * @vaddr: pointer to address to be filled out by mapping
>> + *
>> + * Based on Rusty Russell's skeleton driver's map_page.
>> + * Map a page of memory into this domain from another domain's grant table.
>> + * xenbus_map_ring_valloc allocates a page of virtual address space, maps the
>> + * page to that address, and sets *vaddr to that address.
>> + * Returns 0 on success, and GNTST_* (see xen/include/interface/grant_table.h)
>> + * or -ENOMEM on error. If an error is returned, device will switch to
>> + * XenbusStateClosing and the error message will be saved in XenStore.
>> + */
>> +int xenbus_map_ring_valloc(struct xenbus_device *dev, int gnt_ref, void **vaddr)
>> +{
>> +	if (xen_pv_domain())
>> +		return xenbus_map_ring_valloc_pv(dev, gnt_ref, vaddr);
>> +	else
>> +		return xenbus_map_ring_valloc_hvm(dev, gnt_ref, vaddr);
>
> This could be done in a similar way which Annie's granttable v2 patches are done.
>
> Meaning define something like:
>
> struct xenbus_ring_ops {
> 	int (*map)(struct xenbus_device *dev, int gnt, void *vaddr);
> 	...
>
> And then define two variants of it (PV and HVM):
>
> struct xenbus_ring_ops pv_ring_ops = {
> 	.map = xenbus_map_ring_valloc_pv;
> 	..
> }
>
> have a static to which either one will be assigned:
>
> static struct xenbus_ring_ops *ring_ops;
>
> And in the init function:
>
> void __init xenbus_ring_ops_init(void)
> {
> 	if (xen_hvm_domain)
> 		ring_ops = hvm_ring_ops;
> 	else
> 	...
>
> And then xenbus_init() calls the xenbus_rings_ops_init().
>
> Then these 'xenbus_map_ring_valloc' end up just using the
> ring_ops->map call.

Is the reason for doing this just to avoid overhead? The overhead from
an indirect function call is much higher than from an integer comparison
(which is what xen_pv_domain resolves to). In this case, the _pv and _hvm
functions are both inlined into the dispatch function.

[...]
>> +static int xenbus_unmap_ring_vfree_hvm(struct xenbus_device *dev, void *vaddr)
>> +{
>> +	int rv;
>> +	struct xenbus_map_node *node;
>> +	void *addr;
>> +
>> +	spin_lock(&xenbus_valloc_lock);
>> +	list_for_each_entry(node,&xenbus_valloc_pages, next) {
>> +		addr = pfn_to_kaddr(page_to_pfn(node->page));
>> +		if (addr == vaddr) {
>> +			list_del(&node->next);
>> +			goto found;
>> +		}
>> +	}
>> +	node = NULL;
>> + found:
>> +	spin_unlock(&xenbus_valloc_lock);
>> +
>> +	if (!node) {
>> +		xenbus_dev_error(dev, -ENOENT,
>> +				 "can't find mapped virtual address %p", vaddr);
>> +		return -ENOENT;
>> +	}
>> +
>> +	rv = xenbus_unmap_ring(dev, node->handle, addr);
>> +
>> +	if (!rv)
>> +		free_xenballooned_pages(1,&node->page);
>
> else
> 	WARN_ON("Leaking %p \n", vaddr);

We do already get a warning from the xenbus_dev_error inside xenbus_unmap_ring
which is similar to the error path in the _pv version; added anyway since
triggering either of these indicates hypervisor/kernel state desynchronization.

>> +
>> +	kfree(node);
>> +	return rv;
>> +}
>> +
>> +/**
>> + * xenbus_unmap_ring_vfree
>> + * @dev: xenbus device
>> + * @vaddr: addr to unmap
>> + *
>> + * Based on Rusty Russell's skeleton driver's unmap_page.
>> + * Unmap a page of memory in this domain that was imported from another domain.
>> + * Use xenbus_unmap_ring_vfree if you mapped in your memory with
>> + * xenbus_map_ring_valloc (it will free the virtual address space).
>> + * Returns 0 on success and returns GNTST_* on error
>
> Well, that is not true anymore. You are also returning -ENOENT.

Will fix to return GNTST_bad_virt_addr like the PV version.

>> + * (see xen/include/interface/grant_table.h).
>> + */
>> +int xenbus_unmap_ring_vfree(struct xenbus_device *dev, void *vaddr)
>> +{
>> +	if (xen_pv_domain())
>> +		return xenbus_unmap_ring_vfree_pv(dev, vaddr);
>> +	else
>> +		return xenbus_unmap_ring_vfree_hvm(dev, vaddr);
>> +}
>> +EXPORT_SYMBOL_GPL(xenbus_unmap_ring_vfree);
>>
>>   /**
>>    * xenbus_unmap_ring
>> --
>> 1.7.7.4
>>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 17:52:46 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 17:52:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RchNm-0002jY-O0; Mon, 19 Dec 2011 17:52:14 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RchNl-0002jT-5C
	for Xen-devel@lists.xensource.com; Mon, 19 Dec 2011 17:52:13 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-6.tower-182.messagelabs.com!1324317126!7884775!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31495 invoked from network); 19 Dec 2011 17:52:06 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-6.tower-182.messagelabs.com with SMTP;
	19 Dec 2011 17:52:06 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea01.nsa.gov (8.12.10/8.12.10) with ESMTP id
	pBJHpFws008481; Mon, 19 Dec 2011 17:51:15 GMT
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id pBJHpCc7015423; 
	Mon, 19 Dec 2011 12:51:14 -0500
Message-ID: <4EEF7993.2060301@tycho.nsa.gov>
Date: Mon, 19 Dec 2011 12:51:15 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:8.0) Gecko/20111115 Thunderbird/8.0
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
References: <1323893534-436-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1323893534-436-2-git-send-email-dgdegra@tycho.nsa.gov>
	<20111216195620.GB26802@andromeda.dapyr.net>
In-Reply-To: <20111216195620.GB26802@andromeda.dapyr.net>
Cc: Xen-devel@lists.xensource.com, konrad.wilk@oracle.com
Subject: Re: [Xen-devel] [PATCH 1/6] xenbus: Support HVM backends
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 12/16/2011 02:56 PM, Konrad Rzeszutek Wilk wrote:
> On Wed, Dec 14, 2011 at 03:12:09PM -0500, Daniel De Graaf wrote:
>> Add HVM implementations of xenbus_(map,unmap)_ring_v(alloc,free) so
>> that ring mappings can be done without using GNTMAP_contains_pte which
>> is not supported on HVM.
>>
>> Signed-off-by: Daniel De Graaf<dgdegra@tycho.nsa.gov>
>> ---
>>   drivers/xen/xenbus/xenbus_client.c |  155 +++++++++++++++++++++++++++++-------
>>   1 files changed, 125 insertions(+), 30 deletions(-)
>>
>> diff --git a/drivers/xen/xenbus/xenbus_client.c b/drivers/xen/xenbus/xenbus_client.c
>> index 1906125..ecd695d 100644
>> --- a/drivers/xen/xenbus/xenbus_client.c
>> +++ b/drivers/xen/xenbus/xenbus_client.c
>> @@ -32,16 +32,27 @@
>>
>>   #include<linux/slab.h>
>>   #include<linux/types.h>
>> +#include<linux/spinlock.h>
>>   #include<linux/vmalloc.h>
>>   #include<linux/export.h>
>>   #include<asm/xen/hypervisor.h>
>>   #include<asm/xen/page.h>
>>   #include<xen/interface/xen.h>
>>   #include<xen/interface/event_channel.h>
>> +#include<xen/balloon.h>
>>   #include<xen/events.h>
>>   #include<xen/grant_table.h>
>>   #include<xen/xenbus.h>
>>
>> +struct xenbus_map_node {
>> +	struct list_head next;
>> +	struct page *page;
>> +	grant_handle_t handle;
>> +};
>> +
>> +static DEFINE_SPINLOCK(xenbus_valloc_lock);
>> +static LIST_HEAD(xenbus_valloc_pages);
>
> Could we use this for what the PV version of xenbus_unmap_ring_vfree
> does? (where it uses the vmlist_lock to look for the appropiate vaddr).
>
> Could the vmlist_lock be removed and instead we can use this structure
> for both PV and HVM?

Yes, the next version will do this.

[...]
>> +
>> +/**
>> + * xenbus_map_ring_valloc
>> + * @dev: xenbus device
>> + * @gnt_ref: grant reference
>> + * @vaddr: pointer to address to be filled out by mapping
>> + *
>> + * Based on Rusty Russell's skeleton driver's map_page.
>> + * Map a page of memory into this domain from another domain's grant table.
>> + * xenbus_map_ring_valloc allocates a page of virtual address space, maps the
>> + * page to that address, and sets *vaddr to that address.
>> + * Returns 0 on success, and GNTST_* (see xen/include/interface/grant_table.h)
>> + * or -ENOMEM on error. If an error is returned, device will switch to
>> + * XenbusStateClosing and the error message will be saved in XenStore.
>> + */
>> +int xenbus_map_ring_valloc(struct xenbus_device *dev, int gnt_ref, void **vaddr)
>> +{
>> +	if (xen_pv_domain())
>> +		return xenbus_map_ring_valloc_pv(dev, gnt_ref, vaddr);
>> +	else
>> +		return xenbus_map_ring_valloc_hvm(dev, gnt_ref, vaddr);
>
> This could be done in a similar way which Annie's granttable v2 patches are done.
>
> Meaning define something like:
>
> struct xenbus_ring_ops {
> 	int (*map)(struct xenbus_device *dev, int gnt, void *vaddr);
> 	...
>
> And then define two variants of it (PV and HVM):
>
> struct xenbus_ring_ops pv_ring_ops = {
> 	.map = xenbus_map_ring_valloc_pv;
> 	..
> }
>
> have a static to which either one will be assigned:
>
> static struct xenbus_ring_ops *ring_ops;
>
> And in the init function:
>
> void __init xenbus_ring_ops_init(void)
> {
> 	if (xen_hvm_domain)
> 		ring_ops = hvm_ring_ops;
> 	else
> 	...
>
> And then xenbus_init() calls the xenbus_rings_ops_init().
>
> Then these 'xenbus_map_ring_valloc' end up just using the
> ring_ops->map call.

Is the reason for doing this just to avoid overhead? The overhead from
an indirect function call is much higher than from an integer comparison
(which is what xen_pv_domain resolves to). In this case, the _pv and _hvm
functions are both inlined into the dispatch function.

[...]
>> +static int xenbus_unmap_ring_vfree_hvm(struct xenbus_device *dev, void *vaddr)
>> +{
>> +	int rv;
>> +	struct xenbus_map_node *node;
>> +	void *addr;
>> +
>> +	spin_lock(&xenbus_valloc_lock);
>> +	list_for_each_entry(node,&xenbus_valloc_pages, next) {
>> +		addr = pfn_to_kaddr(page_to_pfn(node->page));
>> +		if (addr == vaddr) {
>> +			list_del(&node->next);
>> +			goto found;
>> +		}
>> +	}
>> +	node = NULL;
>> + found:
>> +	spin_unlock(&xenbus_valloc_lock);
>> +
>> +	if (!node) {
>> +		xenbus_dev_error(dev, -ENOENT,
>> +				 "can't find mapped virtual address %p", vaddr);
>> +		return -ENOENT;
>> +	}
>> +
>> +	rv = xenbus_unmap_ring(dev, node->handle, addr);
>> +
>> +	if (!rv)
>> +		free_xenballooned_pages(1,&node->page);
>
> else
> 	WARN_ON("Leaking %p \n", vaddr);

We do already get a warning from the xenbus_dev_error inside xenbus_unmap_ring
which is similar to the error path in the _pv version; added anyway since
triggering either of these indicates hypervisor/kernel state desynchronization.

>> +
>> +	kfree(node);
>> +	return rv;
>> +}
>> +
>> +/**
>> + * xenbus_unmap_ring_vfree
>> + * @dev: xenbus device
>> + * @vaddr: addr to unmap
>> + *
>> + * Based on Rusty Russell's skeleton driver's unmap_page.
>> + * Unmap a page of memory in this domain that was imported from another domain.
>> + * Use xenbus_unmap_ring_vfree if you mapped in your memory with
>> + * xenbus_map_ring_valloc (it will free the virtual address space).
>> + * Returns 0 on success and returns GNTST_* on error
>
> Well, that is not true anymore. You are also returning -ENOENT.

Will fix to return GNTST_bad_virt_addr like the PV version.

>> + * (see xen/include/interface/grant_table.h).
>> + */
>> +int xenbus_unmap_ring_vfree(struct xenbus_device *dev, void *vaddr)
>> +{
>> +	if (xen_pv_domain())
>> +		return xenbus_unmap_ring_vfree_pv(dev, vaddr);
>> +	else
>> +		return xenbus_unmap_ring_vfree_hvm(dev, vaddr);
>> +}
>> +EXPORT_SYMBOL_GPL(xenbus_unmap_ring_vfree);
>>
>>   /**
>>    * xenbus_unmap_ring
>> --
>> 1.7.7.4
>>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 17:54:28 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 17: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.xensource.com>)
	id 1RchPW-0002nS-4i; Mon, 19 Dec 2011 17:54:02 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wferi@niif.hu>) id 1RchPU-0002nC-HT
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 17:54:00 +0000
X-Env-Sender: wferi@niif.hu
X-Msg-Ref: server-13.tower-174.messagelabs.com!1324317234!6148155!1
X-Originating-IP: [193.6.222.43]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11299 invoked from network); 19 Dec 2011 17:53:54 -0000
Received: from tac.ki.iif.hu (HELO tac.ki.iif.hu) (193.6.222.43)
	by server-13.tower-174.messagelabs.com with AES256-SHA encrypted SMTP;
	19 Dec 2011 17:53:54 -0000
Received: from wferi by tac.ki.iif.hu with local (Exim 4.72)
	(envelope-from <wferi@niif.hu>)
	id 1RchP8-0004cK-2s; Mon, 19 Dec 2011 18:53:38 +0100
From: Ferenc Wagner <wferi@niif.hu>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <ce19ea02-45e6-465a-a4c8-b5d74bf8c2ad@default>
	<20111010155319.GA29140@phenom.oracle.com> <4E934EC9.5030909@goop.org>
	<87vcppbvc4.fsf@tac.ki.iif.hu>
	<20111217214626.GA17841@phenom.dumpdata.com>
Date: Mon, 19 Dec 2011 18:53:38 +0100
In-Reply-To: <20111217214626.GA17841@phenom.dumpdata.com> (Konrad Rzeszutek
	Wilk's message of "Sat, 17 Dec 2011 16:46:26 -0500")
Message-ID: <878vm8bg7x.fsf@tac.ki.iif.hu>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux)
MIME-Version: 1.0
Cc: linux-kernel@vger.kernel.org, Jeremy Fitzhardinge <jeremy@goop.org>,
	xen-devel@lists.xensource.com, Zhenzhong Duan <zhenzhong.duan@oracle.com>,
	linux-x86_64@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH] cpu idle ticks show twice in xen pvm guest
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> writes:

> On Fri, Dec 09, 2011 at 04:47:39PM +0100, Ferenc Wagner wrote:
>
>> Jeremy Fitzhardinge <jeremy@goop.org> writes:
>> 
>>>> On Wed, Oct 05, 2011 at 10:11:58PM -0700, Zhenzhong Duan wrote:
>>>>
>>>>> Run below test on xen pvm.
>>>>> # x=$(cat /proc/stat | grep cpu0 | awk '{print $5}') && sleep 60  \
>>>>> && y=$(cat /proc/stat | grep cpu0 | awk '{print $5}') \
>>>>> && echo -e  "X:$x\nY:$y\nIDLE:" $(echo "scale=3; ($y-$x)/6000*100" | bc)
>>>>>
>>>>> @ X:58562301
>>>>> @ Y:58574282
>>>>> @ IDLE: 199.600
>>>>>
>>>>> Normal idle percent should be around 100%.
>>>>> xen_timer_interrupt called account_idle_ticks to account hypervisor stolen idle ticks 
>>>>> but these ticks will be accounted again when idle ticks restarted.
>>>>>
>>>>> Signed-off-by: Zhenzhong Duan <zhenzhong.duan@oracle.com>
>>>>> Signed-off-by: Joe Jin <joe.jin@oracle.com>
>>>
>>> Does this affect the accounting of stolen ticks?  If it does, that's not
>>> necessarily a showstopper for this patch, but we'll need to do some more
>>> thinking about it.  Certainly, accurate accounting for idleness is
>>> important.
>> 
>> Please see also http://thread.gmane.org/gmane.linux.kernel/734441, where
>> I found that the counter doubling isn't always present under 2.6.26.
>> However, after going to 2.6.32 (Debian lenny-backports kernel, 4th of
>> April on the graph below) that instability seems to disappear.  Please
>> note that the following graph shows halved idle and iowait percentages.
>
> What happenend in Feb?

Probably a live migration or a reboot, I can't remember.  See
http://article.gmane.org/gmane.comp.emulators.xen.devel/57771, where I
described a very similar occurence in detail.

>> (I haven't collected steal values, so the numbers don't sum up to 100%.)
>> I'd be grateful if this discrepancy could be cleared up eventually!
>> It's heartening to see some progress after more than three years. :)
>> 
>> Actually, as Munin doesn't half the idle and iowait values, but
>> truncates the (then overflowing) graph at 100%, I was rather surprised
>> to see iowait completely disappear after the kernel upgrade, and
>> concluded that it was somehow converted into buggy-looping in blkfront.
>> Now I see this isn't the case, but the steadily increasing system CPU
>> usage between reboots is still a mystery.  I'll start a separate thread
>> for that, just wanted to provide some motivation for this topic.
>
> Did you add more memory in the system?

I didn't.  Neither in February (when idle and iowait accounting
temporarily doubled), nor in April (since when the accounting is stable
and the system CPU usage is growing between reboots under the new
kernel).
-- 
Thanks,
Feri.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 17:54:28 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 17: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.xensource.com>)
	id 1RchPW-0002nS-4i; Mon, 19 Dec 2011 17:54:02 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wferi@niif.hu>) id 1RchPU-0002nC-HT
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 17:54:00 +0000
X-Env-Sender: wferi@niif.hu
X-Msg-Ref: server-13.tower-174.messagelabs.com!1324317234!6148155!1
X-Originating-IP: [193.6.222.43]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11299 invoked from network); 19 Dec 2011 17:53:54 -0000
Received: from tac.ki.iif.hu (HELO tac.ki.iif.hu) (193.6.222.43)
	by server-13.tower-174.messagelabs.com with AES256-SHA encrypted SMTP;
	19 Dec 2011 17:53:54 -0000
Received: from wferi by tac.ki.iif.hu with local (Exim 4.72)
	(envelope-from <wferi@niif.hu>)
	id 1RchP8-0004cK-2s; Mon, 19 Dec 2011 18:53:38 +0100
From: Ferenc Wagner <wferi@niif.hu>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <ce19ea02-45e6-465a-a4c8-b5d74bf8c2ad@default>
	<20111010155319.GA29140@phenom.oracle.com> <4E934EC9.5030909@goop.org>
	<87vcppbvc4.fsf@tac.ki.iif.hu>
	<20111217214626.GA17841@phenom.dumpdata.com>
Date: Mon, 19 Dec 2011 18:53:38 +0100
In-Reply-To: <20111217214626.GA17841@phenom.dumpdata.com> (Konrad Rzeszutek
	Wilk's message of "Sat, 17 Dec 2011 16:46:26 -0500")
Message-ID: <878vm8bg7x.fsf@tac.ki.iif.hu>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux)
MIME-Version: 1.0
Cc: linux-kernel@vger.kernel.org, Jeremy Fitzhardinge <jeremy@goop.org>,
	xen-devel@lists.xensource.com, Zhenzhong Duan <zhenzhong.duan@oracle.com>,
	linux-x86_64@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH] cpu idle ticks show twice in xen pvm guest
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> writes:

> On Fri, Dec 09, 2011 at 04:47:39PM +0100, Ferenc Wagner wrote:
>
>> Jeremy Fitzhardinge <jeremy@goop.org> writes:
>> 
>>>> On Wed, Oct 05, 2011 at 10:11:58PM -0700, Zhenzhong Duan wrote:
>>>>
>>>>> Run below test on xen pvm.
>>>>> # x=$(cat /proc/stat | grep cpu0 | awk '{print $5}') && sleep 60  \
>>>>> && y=$(cat /proc/stat | grep cpu0 | awk '{print $5}') \
>>>>> && echo -e  "X:$x\nY:$y\nIDLE:" $(echo "scale=3; ($y-$x)/6000*100" | bc)
>>>>>
>>>>> @ X:58562301
>>>>> @ Y:58574282
>>>>> @ IDLE: 199.600
>>>>>
>>>>> Normal idle percent should be around 100%.
>>>>> xen_timer_interrupt called account_idle_ticks to account hypervisor stolen idle ticks 
>>>>> but these ticks will be accounted again when idle ticks restarted.
>>>>>
>>>>> Signed-off-by: Zhenzhong Duan <zhenzhong.duan@oracle.com>
>>>>> Signed-off-by: Joe Jin <joe.jin@oracle.com>
>>>
>>> Does this affect the accounting of stolen ticks?  If it does, that's not
>>> necessarily a showstopper for this patch, but we'll need to do some more
>>> thinking about it.  Certainly, accurate accounting for idleness is
>>> important.
>> 
>> Please see also http://thread.gmane.org/gmane.linux.kernel/734441, where
>> I found that the counter doubling isn't always present under 2.6.26.
>> However, after going to 2.6.32 (Debian lenny-backports kernel, 4th of
>> April on the graph below) that instability seems to disappear.  Please
>> note that the following graph shows halved idle and iowait percentages.
>
> What happenend in Feb?

Probably a live migration or a reboot, I can't remember.  See
http://article.gmane.org/gmane.comp.emulators.xen.devel/57771, where I
described a very similar occurence in detail.

>> (I haven't collected steal values, so the numbers don't sum up to 100%.)
>> I'd be grateful if this discrepancy could be cleared up eventually!
>> It's heartening to see some progress after more than three years. :)
>> 
>> Actually, as Munin doesn't half the idle and iowait values, but
>> truncates the (then overflowing) graph at 100%, I was rather surprised
>> to see iowait completely disappear after the kernel upgrade, and
>> concluded that it was somehow converted into buggy-looping in blkfront.
>> Now I see this isn't the case, but the steadily increasing system CPU
>> usage between reboots is still a mystery.  I'll start a separate thread
>> for that, just wanted to provide some motivation for this topic.
>
> Did you add more memory in the system?

I didn't.  Neither in February (when idle and iowait accounting
temporarily doubled), nor in April (since when the accounting is stable
and the system CPU usage is growing between reboots under the new
kernel).
-- 
Thanks,
Feri.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 17:55:16 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 17:55:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RchQI-0002qt-JR; Mon, 19 Dec 2011 17:54:50 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RchQH-0002qV-1w
	for Xen-devel@lists.xensource.com; Mon, 19 Dec 2011 17:54:49 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-12.tower-27.messagelabs.com!1324317253!45501298!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28999 invoked from network); 19 Dec 2011 17:54:13 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-12.tower-27.messagelabs.com with SMTP;
	19 Dec 2011 17:54:13 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea01.nsa.gov (8.12.10/8.12.10) with ESMTP id
	pBJHshws008716; Mon, 19 Dec 2011 17:54:43 GMT
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id pBJHsh5J015558; 
	Mon, 19 Dec 2011 12:54:43 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: konrad.wilk@oracle.com
Date: Mon, 19 Dec 2011 12:54:39 -0500
Message-Id: <1324317279-11181-1-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.4
In-Reply-To: <4EEF7993.2060301@tycho.nsa.gov>
References: <4EEF7993.2060301@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>, Xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 1/6 v2] xenbus: Support HVM backends
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Add HVM implementations of xenbus_(map,unmap)_ring_v(alloc,free) so
that ring mappings can be done without using GNTMAP_contains_pte which
is not supported on HVM. This also removes the need to use vmlist_lock
on PV by tracking the allocated xenbus rings.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 drivers/xen/xenbus/xenbus_client.c |  209 +++++++++++++++++++++++++++---------
 1 files changed, 160 insertions(+), 49 deletions(-)

diff --git a/drivers/xen/xenbus/xenbus_client.c b/drivers/xen/xenbus/xenbus_client.c
index 1906125..367decf 100644
--- a/drivers/xen/xenbus/xenbus_client.c
+++ b/drivers/xen/xenbus/xenbus_client.c
@@ -32,16 +32,30 @@
 
 #include <linux/slab.h>
 #include <linux/types.h>
+#include <linux/spinlock.h>
 #include <linux/vmalloc.h>
 #include <linux/export.h>
 #include <asm/xen/hypervisor.h>
 #include <asm/xen/page.h>
 #include <xen/interface/xen.h>
 #include <xen/interface/event_channel.h>
+#include <xen/balloon.h>
 #include <xen/events.h>
 #include <xen/grant_table.h>
 #include <xen/xenbus.h>
 
+struct xenbus_map_node {
+	struct list_head next;
+	union {
+		struct vm_struct *area; /* PV */
+		struct page *page;     /* HVM */
+	};
+	grant_handle_t handle;
+};
+
+static DEFINE_SPINLOCK(xenbus_valloc_lock);
+static LIST_HEAD(xenbus_valloc_pages);
+
 const char *xenbus_strstate(enum xenbus_state state)
 {
 	static const char *const name[] = {
@@ -420,35 +434,29 @@ int xenbus_free_evtchn(struct xenbus_device *dev, int port)
 EXPORT_SYMBOL_GPL(xenbus_free_evtchn);
 
 
-/**
- * xenbus_map_ring_valloc
- * @dev: xenbus device
- * @gnt_ref: grant reference
- * @vaddr: pointer to address to be filled out by mapping
- *
- * Based on Rusty Russell's skeleton driver's map_page.
- * Map a page of memory into this domain from another domain's grant table.
- * xenbus_map_ring_valloc allocates a page of virtual address space, maps the
- * page to that address, and sets *vaddr to that address.
- * Returns 0 on success, and GNTST_* (see xen/include/interface/grant_table.h)
- * or -ENOMEM on error. If an error is returned, device will switch to
- * XenbusStateClosing and the error message will be saved in XenStore.
- */
-int xenbus_map_ring_valloc(struct xenbus_device *dev, int gnt_ref, void **vaddr)
+static int xenbus_map_ring_valloc_pv(struct xenbus_device *dev,
+				     int gnt_ref, void **vaddr)
 {
 	struct gnttab_map_grant_ref op = {
 		.flags = GNTMAP_host_map | GNTMAP_contains_pte,
 		.ref   = gnt_ref,
 		.dom   = dev->otherend_id,
 	};
+	struct xenbus_map_node *node;
 	struct vm_struct *area;
 	pte_t *pte;
 
 	*vaddr = NULL;
 
+	node = kzalloc(sizeof(*node), GFP_KERNEL);
+	if (!node)
+		return -ENOMEM;
+
 	area = alloc_vm_area(PAGE_SIZE, &pte);
-	if (!area)
+	if (!area) {
+		kfree(node);
 		return -ENOMEM;
+	}
 
 	op.host_addr = arbitrary_virt_to_machine(pte).maddr;
 
@@ -457,18 +465,81 @@ int xenbus_map_ring_valloc(struct xenbus_device *dev, int gnt_ref, void **vaddr)
 
 	if (op.status != GNTST_okay) {
 		free_vm_area(area);
+		kfree(node);
 		xenbus_dev_fatal(dev, op.status,
 				 "mapping in shared page %d from domain %d",
 				 gnt_ref, dev->otherend_id);
 		return op.status;
 	}
 
-	/* Stuff the handle in an unused field */
-	area->phys_addr = (unsigned long)op.handle;
+	node->handle = op.handle;
+	node->area = area;
+
+	spin_lock(&xenbus_valloc_lock);
+	list_add(&node->next, &xenbus_valloc_pages);
+	spin_unlock(&xenbus_valloc_lock);
 
 	*vaddr = area->addr;
 	return 0;
 }
+
+static int xenbus_map_ring_valloc_hvm(struct xenbus_device *dev,
+				      int gnt_ref, void **vaddr)
+{
+	struct xenbus_map_node *node;
+	int err;
+	void *addr;
+
+	*vaddr = NULL;
+
+	node = kzalloc(sizeof(*node), GFP_KERNEL);
+	if (!node)
+		return -ENOMEM;
+
+	err = alloc_xenballooned_pages(1, &node->page, false /* lowmem */);
+	if (err)
+		goto out_err;
+
+	addr = pfn_to_kaddr(page_to_pfn(node->page));
+
+	err = xenbus_map_ring(dev, gnt_ref, &node->handle, addr);
+	if (err)
+		goto out_err;
+
+	spin_lock(&xenbus_valloc_lock);
+	list_add(&node->next, &xenbus_valloc_pages);
+	spin_unlock(&xenbus_valloc_lock);
+
+	*vaddr = addr;
+	return 0;
+
+ out_err:
+	free_xenballooned_pages(1, &node->page);
+	kfree(node);
+	return err;
+}
+
+/**
+ * xenbus_map_ring_valloc
+ * @dev: xenbus device
+ * @gnt_ref: grant reference
+ * @vaddr: pointer to address to be filled out by mapping
+ *
+ * Based on Rusty Russell's skeleton driver's map_page.
+ * Map a page of memory into this domain from another domain's grant table.
+ * xenbus_map_ring_valloc allocates a page of virtual address space, maps the
+ * page to that address, and sets *vaddr to that address.
+ * Returns 0 on success, and GNTST_* (see xen/include/interface/grant_table.h)
+ * or -ENOMEM on error. If an error is returned, device will switch to
+ * XenbusStateClosing and the error message will be saved in XenStore.
+ */
+int xenbus_map_ring_valloc(struct xenbus_device *dev, int gnt_ref, void **vaddr)
+{
+	if (xen_pv_domain())
+		return xenbus_map_ring_valloc_pv(dev, gnt_ref, vaddr);
+	else
+		return xenbus_map_ring_valloc_hvm(dev, gnt_ref, vaddr);
+}
 EXPORT_SYMBOL_GPL(xenbus_map_ring_valloc);
 
 
@@ -510,47 +581,32 @@ int xenbus_map_ring(struct xenbus_device *dev, int gnt_ref,
 }
 EXPORT_SYMBOL_GPL(xenbus_map_ring);
 
-
-/**
- * xenbus_unmap_ring_vfree
- * @dev: xenbus device
- * @vaddr: addr to unmap
- *
- * Based on Rusty Russell's skeleton driver's unmap_page.
- * Unmap a page of memory in this domain that was imported from another domain.
- * Use xenbus_unmap_ring_vfree if you mapped in your memory with
- * xenbus_map_ring_valloc (it will free the virtual address space).
- * Returns 0 on success and returns GNTST_* on error
- * (see xen/include/interface/grant_table.h).
- */
-int xenbus_unmap_ring_vfree(struct xenbus_device *dev, void *vaddr)
+static int xenbus_unmap_ring_vfree_pv(struct xenbus_device *dev, void *vaddr)
 {
-	struct vm_struct *area;
+	struct xenbus_map_node *node;
 	struct gnttab_unmap_grant_ref op = {
 		.host_addr = (unsigned long)vaddr,
 	};
 	unsigned int level;
 
-	/* It'd be nice if linux/vmalloc.h provided a find_vm_area(void *addr)
-	 * method so that we don't have to muck with vmalloc internals here.
-	 * We could force the user to hang on to their struct vm_struct from
-	 * xenbus_map_ring_valloc, but these 6 lines considerably simplify
-	 * this API.
-	 */
-	read_lock(&vmlist_lock);
-	for (area = vmlist; area != NULL; area = area->next) {
-		if (area->addr == vaddr)
-			break;
+	spin_lock(&xenbus_valloc_lock);
+	list_for_each_entry(node, &xenbus_valloc_pages, next) {
+		if (node->area->addr == vaddr) {
+			list_del(&node->next);
+			goto found;
+		}
 	}
-	read_unlock(&vmlist_lock);
+	node = NULL;
+ found:
+	spin_unlock(&xenbus_valloc_lock);
 
-	if (!area) {
+	if (!node) {
 		xenbus_dev_error(dev, -ENOENT,
 				 "can't find mapped virtual address %p", vaddr);
 		return GNTST_bad_virt_addr;
 	}
 
-	op.handle = (grant_handle_t)area->phys_addr;
+	op.handle = node->handle;
 	op.host_addr = arbitrary_virt_to_machine(
 		lookup_address((unsigned long)vaddr, &level)).maddr;
 
@@ -558,16 +614,71 @@ int xenbus_unmap_ring_vfree(struct xenbus_device *dev, void *vaddr)
 		BUG();
 
 	if (op.status == GNTST_okay)
-		free_vm_area(area);
+		free_vm_area(node->area);
 	else
 		xenbus_dev_error(dev, op.status,
 				 "unmapping page at handle %d error %d",
-				 (int16_t)area->phys_addr, op.status);
+				 node->handle, op.status);
 
+	kfree(node);
 	return op.status;
 }
-EXPORT_SYMBOL_GPL(xenbus_unmap_ring_vfree);
 
+static int xenbus_unmap_ring_vfree_hvm(struct xenbus_device *dev, void *vaddr)
+{
+	int rv;
+	struct xenbus_map_node *node;
+	void *addr;
+
+	spin_lock(&xenbus_valloc_lock);
+	list_for_each_entry(node, &xenbus_valloc_pages, next) {
+		addr = pfn_to_kaddr(page_to_pfn(node->page));
+		if (addr == vaddr) {
+			list_del(&node->next);
+			goto found;
+		}
+	}
+	node = NULL;
+ found:
+	spin_unlock(&xenbus_valloc_lock);
+
+	if (!node) {
+		xenbus_dev_error(dev, -ENOENT,
+				 "can't find mapped virtual address %p", vaddr);
+		return GNTST_bad_virt_addr;
+	}
+
+	rv = xenbus_unmap_ring(dev, node->handle, addr);
+
+	if (!rv)
+		free_xenballooned_pages(1, &node->page);
+	else
+		WARN(1, "Leaking %p\n", vaddr);
+
+	kfree(node);
+	return rv;
+}
+
+/**
+ * xenbus_unmap_ring_vfree
+ * @dev: xenbus device
+ * @vaddr: addr to unmap
+ *
+ * Based on Rusty Russell's skeleton driver's unmap_page.
+ * Unmap a page of memory in this domain that was imported from another domain.
+ * Use xenbus_unmap_ring_vfree if you mapped in your memory with
+ * xenbus_map_ring_valloc (it will free the virtual address space).
+ * Returns 0 on success and returns GNTST_* on error
+ * (see xen/include/interface/grant_table.h).
+ */
+int xenbus_unmap_ring_vfree(struct xenbus_device *dev, void *vaddr)
+{
+	if (xen_pv_domain())
+		return xenbus_unmap_ring_vfree_pv(dev, vaddr);
+	else
+		return xenbus_unmap_ring_vfree_hvm(dev, vaddr);
+}
+EXPORT_SYMBOL_GPL(xenbus_unmap_ring_vfree);
 
 /**
  * xenbus_unmap_ring
-- 
1.7.7.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 17:55:16 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 17:55:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RchQI-0002qt-JR; Mon, 19 Dec 2011 17:54:50 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RchQH-0002qV-1w
	for Xen-devel@lists.xensource.com; Mon, 19 Dec 2011 17:54:49 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-12.tower-27.messagelabs.com!1324317253!45501298!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28999 invoked from network); 19 Dec 2011 17:54:13 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-12.tower-27.messagelabs.com with SMTP;
	19 Dec 2011 17:54:13 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea01.nsa.gov (8.12.10/8.12.10) with ESMTP id
	pBJHshws008716; Mon, 19 Dec 2011 17:54:43 GMT
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id pBJHsh5J015558; 
	Mon, 19 Dec 2011 12:54:43 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: konrad.wilk@oracle.com
Date: Mon, 19 Dec 2011 12:54:39 -0500
Message-Id: <1324317279-11181-1-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.4
In-Reply-To: <4EEF7993.2060301@tycho.nsa.gov>
References: <4EEF7993.2060301@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>, Xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 1/6 v2] xenbus: Support HVM backends
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Add HVM implementations of xenbus_(map,unmap)_ring_v(alloc,free) so
that ring mappings can be done without using GNTMAP_contains_pte which
is not supported on HVM. This also removes the need to use vmlist_lock
on PV by tracking the allocated xenbus rings.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 drivers/xen/xenbus/xenbus_client.c |  209 +++++++++++++++++++++++++++---------
 1 files changed, 160 insertions(+), 49 deletions(-)

diff --git a/drivers/xen/xenbus/xenbus_client.c b/drivers/xen/xenbus/xenbus_client.c
index 1906125..367decf 100644
--- a/drivers/xen/xenbus/xenbus_client.c
+++ b/drivers/xen/xenbus/xenbus_client.c
@@ -32,16 +32,30 @@
 
 #include <linux/slab.h>
 #include <linux/types.h>
+#include <linux/spinlock.h>
 #include <linux/vmalloc.h>
 #include <linux/export.h>
 #include <asm/xen/hypervisor.h>
 #include <asm/xen/page.h>
 #include <xen/interface/xen.h>
 #include <xen/interface/event_channel.h>
+#include <xen/balloon.h>
 #include <xen/events.h>
 #include <xen/grant_table.h>
 #include <xen/xenbus.h>
 
+struct xenbus_map_node {
+	struct list_head next;
+	union {
+		struct vm_struct *area; /* PV */
+		struct page *page;     /* HVM */
+	};
+	grant_handle_t handle;
+};
+
+static DEFINE_SPINLOCK(xenbus_valloc_lock);
+static LIST_HEAD(xenbus_valloc_pages);
+
 const char *xenbus_strstate(enum xenbus_state state)
 {
 	static const char *const name[] = {
@@ -420,35 +434,29 @@ int xenbus_free_evtchn(struct xenbus_device *dev, int port)
 EXPORT_SYMBOL_GPL(xenbus_free_evtchn);
 
 
-/**
- * xenbus_map_ring_valloc
- * @dev: xenbus device
- * @gnt_ref: grant reference
- * @vaddr: pointer to address to be filled out by mapping
- *
- * Based on Rusty Russell's skeleton driver's map_page.
- * Map a page of memory into this domain from another domain's grant table.
- * xenbus_map_ring_valloc allocates a page of virtual address space, maps the
- * page to that address, and sets *vaddr to that address.
- * Returns 0 on success, and GNTST_* (see xen/include/interface/grant_table.h)
- * or -ENOMEM on error. If an error is returned, device will switch to
- * XenbusStateClosing and the error message will be saved in XenStore.
- */
-int xenbus_map_ring_valloc(struct xenbus_device *dev, int gnt_ref, void **vaddr)
+static int xenbus_map_ring_valloc_pv(struct xenbus_device *dev,
+				     int gnt_ref, void **vaddr)
 {
 	struct gnttab_map_grant_ref op = {
 		.flags = GNTMAP_host_map | GNTMAP_contains_pte,
 		.ref   = gnt_ref,
 		.dom   = dev->otherend_id,
 	};
+	struct xenbus_map_node *node;
 	struct vm_struct *area;
 	pte_t *pte;
 
 	*vaddr = NULL;
 
+	node = kzalloc(sizeof(*node), GFP_KERNEL);
+	if (!node)
+		return -ENOMEM;
+
 	area = alloc_vm_area(PAGE_SIZE, &pte);
-	if (!area)
+	if (!area) {
+		kfree(node);
 		return -ENOMEM;
+	}
 
 	op.host_addr = arbitrary_virt_to_machine(pte).maddr;
 
@@ -457,18 +465,81 @@ int xenbus_map_ring_valloc(struct xenbus_device *dev, int gnt_ref, void **vaddr)
 
 	if (op.status != GNTST_okay) {
 		free_vm_area(area);
+		kfree(node);
 		xenbus_dev_fatal(dev, op.status,
 				 "mapping in shared page %d from domain %d",
 				 gnt_ref, dev->otherend_id);
 		return op.status;
 	}
 
-	/* Stuff the handle in an unused field */
-	area->phys_addr = (unsigned long)op.handle;
+	node->handle = op.handle;
+	node->area = area;
+
+	spin_lock(&xenbus_valloc_lock);
+	list_add(&node->next, &xenbus_valloc_pages);
+	spin_unlock(&xenbus_valloc_lock);
 
 	*vaddr = area->addr;
 	return 0;
 }
+
+static int xenbus_map_ring_valloc_hvm(struct xenbus_device *dev,
+				      int gnt_ref, void **vaddr)
+{
+	struct xenbus_map_node *node;
+	int err;
+	void *addr;
+
+	*vaddr = NULL;
+
+	node = kzalloc(sizeof(*node), GFP_KERNEL);
+	if (!node)
+		return -ENOMEM;
+
+	err = alloc_xenballooned_pages(1, &node->page, false /* lowmem */);
+	if (err)
+		goto out_err;
+
+	addr = pfn_to_kaddr(page_to_pfn(node->page));
+
+	err = xenbus_map_ring(dev, gnt_ref, &node->handle, addr);
+	if (err)
+		goto out_err;
+
+	spin_lock(&xenbus_valloc_lock);
+	list_add(&node->next, &xenbus_valloc_pages);
+	spin_unlock(&xenbus_valloc_lock);
+
+	*vaddr = addr;
+	return 0;
+
+ out_err:
+	free_xenballooned_pages(1, &node->page);
+	kfree(node);
+	return err;
+}
+
+/**
+ * xenbus_map_ring_valloc
+ * @dev: xenbus device
+ * @gnt_ref: grant reference
+ * @vaddr: pointer to address to be filled out by mapping
+ *
+ * Based on Rusty Russell's skeleton driver's map_page.
+ * Map a page of memory into this domain from another domain's grant table.
+ * xenbus_map_ring_valloc allocates a page of virtual address space, maps the
+ * page to that address, and sets *vaddr to that address.
+ * Returns 0 on success, and GNTST_* (see xen/include/interface/grant_table.h)
+ * or -ENOMEM on error. If an error is returned, device will switch to
+ * XenbusStateClosing and the error message will be saved in XenStore.
+ */
+int xenbus_map_ring_valloc(struct xenbus_device *dev, int gnt_ref, void **vaddr)
+{
+	if (xen_pv_domain())
+		return xenbus_map_ring_valloc_pv(dev, gnt_ref, vaddr);
+	else
+		return xenbus_map_ring_valloc_hvm(dev, gnt_ref, vaddr);
+}
 EXPORT_SYMBOL_GPL(xenbus_map_ring_valloc);
 
 
@@ -510,47 +581,32 @@ int xenbus_map_ring(struct xenbus_device *dev, int gnt_ref,
 }
 EXPORT_SYMBOL_GPL(xenbus_map_ring);
 
-
-/**
- * xenbus_unmap_ring_vfree
- * @dev: xenbus device
- * @vaddr: addr to unmap
- *
- * Based on Rusty Russell's skeleton driver's unmap_page.
- * Unmap a page of memory in this domain that was imported from another domain.
- * Use xenbus_unmap_ring_vfree if you mapped in your memory with
- * xenbus_map_ring_valloc (it will free the virtual address space).
- * Returns 0 on success and returns GNTST_* on error
- * (see xen/include/interface/grant_table.h).
- */
-int xenbus_unmap_ring_vfree(struct xenbus_device *dev, void *vaddr)
+static int xenbus_unmap_ring_vfree_pv(struct xenbus_device *dev, void *vaddr)
 {
-	struct vm_struct *area;
+	struct xenbus_map_node *node;
 	struct gnttab_unmap_grant_ref op = {
 		.host_addr = (unsigned long)vaddr,
 	};
 	unsigned int level;
 
-	/* It'd be nice if linux/vmalloc.h provided a find_vm_area(void *addr)
-	 * method so that we don't have to muck with vmalloc internals here.
-	 * We could force the user to hang on to their struct vm_struct from
-	 * xenbus_map_ring_valloc, but these 6 lines considerably simplify
-	 * this API.
-	 */
-	read_lock(&vmlist_lock);
-	for (area = vmlist; area != NULL; area = area->next) {
-		if (area->addr == vaddr)
-			break;
+	spin_lock(&xenbus_valloc_lock);
+	list_for_each_entry(node, &xenbus_valloc_pages, next) {
+		if (node->area->addr == vaddr) {
+			list_del(&node->next);
+			goto found;
+		}
 	}
-	read_unlock(&vmlist_lock);
+	node = NULL;
+ found:
+	spin_unlock(&xenbus_valloc_lock);
 
-	if (!area) {
+	if (!node) {
 		xenbus_dev_error(dev, -ENOENT,
 				 "can't find mapped virtual address %p", vaddr);
 		return GNTST_bad_virt_addr;
 	}
 
-	op.handle = (grant_handle_t)area->phys_addr;
+	op.handle = node->handle;
 	op.host_addr = arbitrary_virt_to_machine(
 		lookup_address((unsigned long)vaddr, &level)).maddr;
 
@@ -558,16 +614,71 @@ int xenbus_unmap_ring_vfree(struct xenbus_device *dev, void *vaddr)
 		BUG();
 
 	if (op.status == GNTST_okay)
-		free_vm_area(area);
+		free_vm_area(node->area);
 	else
 		xenbus_dev_error(dev, op.status,
 				 "unmapping page at handle %d error %d",
-				 (int16_t)area->phys_addr, op.status);
+				 node->handle, op.status);
 
+	kfree(node);
 	return op.status;
 }
-EXPORT_SYMBOL_GPL(xenbus_unmap_ring_vfree);
 
+static int xenbus_unmap_ring_vfree_hvm(struct xenbus_device *dev, void *vaddr)
+{
+	int rv;
+	struct xenbus_map_node *node;
+	void *addr;
+
+	spin_lock(&xenbus_valloc_lock);
+	list_for_each_entry(node, &xenbus_valloc_pages, next) {
+		addr = pfn_to_kaddr(page_to_pfn(node->page));
+		if (addr == vaddr) {
+			list_del(&node->next);
+			goto found;
+		}
+	}
+	node = NULL;
+ found:
+	spin_unlock(&xenbus_valloc_lock);
+
+	if (!node) {
+		xenbus_dev_error(dev, -ENOENT,
+				 "can't find mapped virtual address %p", vaddr);
+		return GNTST_bad_virt_addr;
+	}
+
+	rv = xenbus_unmap_ring(dev, node->handle, addr);
+
+	if (!rv)
+		free_xenballooned_pages(1, &node->page);
+	else
+		WARN(1, "Leaking %p\n", vaddr);
+
+	kfree(node);
+	return rv;
+}
+
+/**
+ * xenbus_unmap_ring_vfree
+ * @dev: xenbus device
+ * @vaddr: addr to unmap
+ *
+ * Based on Rusty Russell's skeleton driver's unmap_page.
+ * Unmap a page of memory in this domain that was imported from another domain.
+ * Use xenbus_unmap_ring_vfree if you mapped in your memory with
+ * xenbus_map_ring_valloc (it will free the virtual address space).
+ * Returns 0 on success and returns GNTST_* on error
+ * (see xen/include/interface/grant_table.h).
+ */
+int xenbus_unmap_ring_vfree(struct xenbus_device *dev, void *vaddr)
+{
+	if (xen_pv_domain())
+		return xenbus_unmap_ring_vfree_pv(dev, vaddr);
+	else
+		return xenbus_unmap_ring_vfree_hvm(dev, vaddr);
+}
+EXPORT_SYMBOL_GPL(xenbus_unmap_ring_vfree);
 
 /**
  * xenbus_unmap_ring
-- 
1.7.7.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 18:19:14 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 18:19:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RchnZ-0003UX-2L; Mon, 19 Dec 2011 18:18:53 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RchnX-0003UP-Jm
	for Xen-devel@lists.xensource.com; Mon, 19 Dec 2011 18:18:51 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1324318723!6162590!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ0Njk1NQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29679 invoked from network); 19 Dec 2011 18:18:44 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-6.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Dec 2011 18:18:44 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pBJIHtAL032057
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 19 Dec 2011 18:17:56 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pBJIHr9C010846
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 19 Dec 2011 18:17:54 GMT
Received: from abhmt112.oracle.com (abhmt112.oracle.com [141.146.116.64])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pBJIHrB7022428; Mon, 19 Dec 2011 12:17:53 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 19 Dec 2011 10:17:53 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id A9DE9417B3; Mon, 19 Dec 2011 13:16:55 -0500 (EST)
Date: Mon, 19 Dec 2011 13:16:55 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Message-ID: <20111219181655.GA3832@phenom.dumpdata.com>
References: <1323893534-436-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1323893534-436-2-git-send-email-dgdegra@tycho.nsa.gov>
	<20111216195620.GB26802@andromeda.dapyr.net>
	<4EEF7993.2060301@tycho.nsa.gov>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4EEF7993.2060301@tycho.nsa.gov>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090208.4EEF7FD4.00BC,ss=1,re=0.000,fgs=0
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>, Xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 1/6] xenbus: Support HVM backends
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Dec 19, 2011 at 12:51:15PM -0500, Daniel De Graaf wrote:
> On 12/16/2011 02:56 PM, Konrad Rzeszutek Wilk wrote:
> >On Wed, Dec 14, 2011 at 03:12:09PM -0500, Daniel De Graaf wrote:
> >>Add HVM implementations of xenbus_(map,unmap)_ring_v(alloc,free) so
> >>that ring mappings can be done without using GNTMAP_contains_pte which
> >>is not supported on HVM.
> >>
> >>Signed-off-by: Daniel De Graaf<dgdegra@tycho.nsa.gov>
> >>---
> >>  drivers/xen/xenbus/xenbus_client.c |  155 +++++++++++++++++++++++++++++-------
> >>  1 files changed, 125 insertions(+), 30 deletions(-)
> >>
> >>diff --git a/drivers/xen/xenbus/xenbus_client.c b/drivers/xen/xenbus/xenbus_client.c
> >>index 1906125..ecd695d 100644
> >>--- a/drivers/xen/xenbus/xenbus_client.c
> >>+++ b/drivers/xen/xenbus/xenbus_client.c
> >>@@ -32,16 +32,27 @@
> >>
> >>  #include<linux/slab.h>
> >>  #include<linux/types.h>
> >>+#include<linux/spinlock.h>
> >>  #include<linux/vmalloc.h>
> >>  #include<linux/export.h>
> >>  #include<asm/xen/hypervisor.h>
> >>  #include<asm/xen/page.h>
> >>  #include<xen/interface/xen.h>
> >>  #include<xen/interface/event_channel.h>
> >>+#include<xen/balloon.h>
> >>  #include<xen/events.h>
> >>  #include<xen/grant_table.h>
> >>  #include<xen/xenbus.h>
> >>
> >>+struct xenbus_map_node {
> >>+	struct list_head next;
> >>+	struct page *page;
> >>+	grant_handle_t handle;
> >>+};
> >>+
> >>+static DEFINE_SPINLOCK(xenbus_valloc_lock);
> >>+static LIST_HEAD(xenbus_valloc_pages);
> >
> >Could we use this for what the PV version of xenbus_unmap_ring_vfree
> >does? (where it uses the vmlist_lock to look for the appropiate vaddr).
> >
> >Could the vmlist_lock be removed and instead we can use this structure
> >for both PV and HVM?
> 
> Yes, the next version will do this.
> 
> [...]
> >>+
> >>+/**
> >>+ * xenbus_map_ring_valloc
> >>+ * @dev: xenbus device
> >>+ * @gnt_ref: grant reference
> >>+ * @vaddr: pointer to address to be filled out by mapping
> >>+ *
> >>+ * Based on Rusty Russell's skeleton driver's map_page.
> >>+ * Map a page of memory into this domain from another domain's grant table.
> >>+ * xenbus_map_ring_valloc allocates a page of virtual address space, maps the
> >>+ * page to that address, and sets *vaddr to that address.
> >>+ * Returns 0 on success, and GNTST_* (see xen/include/interface/grant_table.h)
> >>+ * or -ENOMEM on error. If an error is returned, device will switch to
> >>+ * XenbusStateClosing and the error message will be saved in XenStore.
> >>+ */
> >>+int xenbus_map_ring_valloc(struct xenbus_device *dev, int gnt_ref, void **vaddr)
> >>+{
> >>+	if (xen_pv_domain())
> >>+		return xenbus_map_ring_valloc_pv(dev, gnt_ref, vaddr);
> >>+	else
> >>+		return xenbus_map_ring_valloc_hvm(dev, gnt_ref, vaddr);
> >
> >This could be done in a similar way which Annie's granttable v2 patches are done.
> >
> >Meaning define something like:
> >
> >struct xenbus_ring_ops {
> >	int (*map)(struct xenbus_device *dev, int gnt, void *vaddr);
> >	...
> >
> >And then define two variants of it (PV and HVM):
> >
> >struct xenbus_ring_ops pv_ring_ops = {
> >	.map = xenbus_map_ring_valloc_pv;
> >	..
> >}
> >
> >have a static to which either one will be assigned:
> >
> >static struct xenbus_ring_ops *ring_ops;
> >
> >And in the init function:
> >
> >void __init xenbus_ring_ops_init(void)
> >{
> >	if (xen_hvm_domain)
> >		ring_ops = hvm_ring_ops;
> >	else
> >	...
> >
> >And then xenbus_init() calls the xenbus_rings_ops_init().
> >
> >Then these 'xenbus_map_ring_valloc' end up just using the
> >ring_ops->map call.
> 
> Is the reason for doing this just to avoid overhead? The overhead from
> an indirect function call is much higher than from an integer comparison
> (which is what xen_pv_domain resolves to). In this case, the _pv and _hvm
> functions are both inlined into the dispatch function.

Do we care about that? How often are these calls made?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 18:19:14 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 18:19:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RchnZ-0003UX-2L; Mon, 19 Dec 2011 18:18:53 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RchnX-0003UP-Jm
	for Xen-devel@lists.xensource.com; Mon, 19 Dec 2011 18:18:51 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1324318723!6162590!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ0Njk1NQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29679 invoked from network); 19 Dec 2011 18:18:44 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-6.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Dec 2011 18:18:44 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pBJIHtAL032057
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 19 Dec 2011 18:17:56 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pBJIHr9C010846
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 19 Dec 2011 18:17:54 GMT
Received: from abhmt112.oracle.com (abhmt112.oracle.com [141.146.116.64])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pBJIHrB7022428; Mon, 19 Dec 2011 12:17:53 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 19 Dec 2011 10:17:53 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id A9DE9417B3; Mon, 19 Dec 2011 13:16:55 -0500 (EST)
Date: Mon, 19 Dec 2011 13:16:55 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Message-ID: <20111219181655.GA3832@phenom.dumpdata.com>
References: <1323893534-436-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1323893534-436-2-git-send-email-dgdegra@tycho.nsa.gov>
	<20111216195620.GB26802@andromeda.dapyr.net>
	<4EEF7993.2060301@tycho.nsa.gov>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4EEF7993.2060301@tycho.nsa.gov>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090208.4EEF7FD4.00BC,ss=1,re=0.000,fgs=0
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>, Xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 1/6] xenbus: Support HVM backends
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Dec 19, 2011 at 12:51:15PM -0500, Daniel De Graaf wrote:
> On 12/16/2011 02:56 PM, Konrad Rzeszutek Wilk wrote:
> >On Wed, Dec 14, 2011 at 03:12:09PM -0500, Daniel De Graaf wrote:
> >>Add HVM implementations of xenbus_(map,unmap)_ring_v(alloc,free) so
> >>that ring mappings can be done without using GNTMAP_contains_pte which
> >>is not supported on HVM.
> >>
> >>Signed-off-by: Daniel De Graaf<dgdegra@tycho.nsa.gov>
> >>---
> >>  drivers/xen/xenbus/xenbus_client.c |  155 +++++++++++++++++++++++++++++-------
> >>  1 files changed, 125 insertions(+), 30 deletions(-)
> >>
> >>diff --git a/drivers/xen/xenbus/xenbus_client.c b/drivers/xen/xenbus/xenbus_client.c
> >>index 1906125..ecd695d 100644
> >>--- a/drivers/xen/xenbus/xenbus_client.c
> >>+++ b/drivers/xen/xenbus/xenbus_client.c
> >>@@ -32,16 +32,27 @@
> >>
> >>  #include<linux/slab.h>
> >>  #include<linux/types.h>
> >>+#include<linux/spinlock.h>
> >>  #include<linux/vmalloc.h>
> >>  #include<linux/export.h>
> >>  #include<asm/xen/hypervisor.h>
> >>  #include<asm/xen/page.h>
> >>  #include<xen/interface/xen.h>
> >>  #include<xen/interface/event_channel.h>
> >>+#include<xen/balloon.h>
> >>  #include<xen/events.h>
> >>  #include<xen/grant_table.h>
> >>  #include<xen/xenbus.h>
> >>
> >>+struct xenbus_map_node {
> >>+	struct list_head next;
> >>+	struct page *page;
> >>+	grant_handle_t handle;
> >>+};
> >>+
> >>+static DEFINE_SPINLOCK(xenbus_valloc_lock);
> >>+static LIST_HEAD(xenbus_valloc_pages);
> >
> >Could we use this for what the PV version of xenbus_unmap_ring_vfree
> >does? (where it uses the vmlist_lock to look for the appropiate vaddr).
> >
> >Could the vmlist_lock be removed and instead we can use this structure
> >for both PV and HVM?
> 
> Yes, the next version will do this.
> 
> [...]
> >>+
> >>+/**
> >>+ * xenbus_map_ring_valloc
> >>+ * @dev: xenbus device
> >>+ * @gnt_ref: grant reference
> >>+ * @vaddr: pointer to address to be filled out by mapping
> >>+ *
> >>+ * Based on Rusty Russell's skeleton driver's map_page.
> >>+ * Map a page of memory into this domain from another domain's grant table.
> >>+ * xenbus_map_ring_valloc allocates a page of virtual address space, maps the
> >>+ * page to that address, and sets *vaddr to that address.
> >>+ * Returns 0 on success, and GNTST_* (see xen/include/interface/grant_table.h)
> >>+ * or -ENOMEM on error. If an error is returned, device will switch to
> >>+ * XenbusStateClosing and the error message will be saved in XenStore.
> >>+ */
> >>+int xenbus_map_ring_valloc(struct xenbus_device *dev, int gnt_ref, void **vaddr)
> >>+{
> >>+	if (xen_pv_domain())
> >>+		return xenbus_map_ring_valloc_pv(dev, gnt_ref, vaddr);
> >>+	else
> >>+		return xenbus_map_ring_valloc_hvm(dev, gnt_ref, vaddr);
> >
> >This could be done in a similar way which Annie's granttable v2 patches are done.
> >
> >Meaning define something like:
> >
> >struct xenbus_ring_ops {
> >	int (*map)(struct xenbus_device *dev, int gnt, void *vaddr);
> >	...
> >
> >And then define two variants of it (PV and HVM):
> >
> >struct xenbus_ring_ops pv_ring_ops = {
> >	.map = xenbus_map_ring_valloc_pv;
> >	..
> >}
> >
> >have a static to which either one will be assigned:
> >
> >static struct xenbus_ring_ops *ring_ops;
> >
> >And in the init function:
> >
> >void __init xenbus_ring_ops_init(void)
> >{
> >	if (xen_hvm_domain)
> >		ring_ops = hvm_ring_ops;
> >	else
> >	...
> >
> >And then xenbus_init() calls the xenbus_rings_ops_init().
> >
> >Then these 'xenbus_map_ring_valloc' end up just using the
> >ring_ops->map call.
> 
> Is the reason for doing this just to avoid overhead? The overhead from
> an indirect function call is much higher than from an integer comparison
> (which is what xen_pv_domain resolves to). In this case, the _pv and _hvm
> functions are both inlined into the dispatch function.

Do we care about that? How often are these calls made?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 18:35:05 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 18:35:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rci2q-0003pD-IO; Mon, 19 Dec 2011 18:34:40 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1Rci2p-0003p8-5b
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 18:34:39 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-11.tower-216.messagelabs.com!1324319672!7992387!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10011 invoked from network); 19 Dec 2011 18:34:32 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-11.tower-216.messagelabs.com with SMTP;
	19 Dec 2011 18:34:32 -0000
Received: from [62.94.181.91] (account d.faggioli@sssup.it HELO [192.168.0.40])
	by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 74030753; Mon, 19 Dec 2011 19:34:31 +0100
Message-ID: <1324319661.2599.28.camel@Solace>
From: Dario Faggioli <raistlin@linux.it>
To: xen-devel@lists.xensource.com
Date: Mon, 19 Dec 2011 19:34:21 +0100
X-Mailer: Evolution 3.0.3-3+b1 
Mime-Version: 1.0
Cc: Wei Wang2 <wei.wang2@amd.com>,
	"allen.m.kay@intel.com" <allen.m.kay@intel.com>,
	Tim Deegan <tim@xen.org>, Jan Beulich <JBeulich@suse.com>
Subject: [Xen-devel] [PATCH 0 of 3] Deal with IOMMU faults in softirq
	context.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============2650221521348332798=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--===============2650221521348332798==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-uPzGRdN53Jz9tbzNc/9w"


--=-uPzGRdN53Jz9tbzNc/9w
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hello everyone,

As already discussed here [1], dealing with IOMMU faults in interrupt
context may cause nasty things to happen, up to being used as a form of
DoS attack, e.g., by generating a "storm" of IOMMU faults that will
livelock a pCPU.

To avoid this, IOMMU faults handling is being moved from interrupt to
softirq context. Basically, the inerrupt handler of the IRQ originated
by an IOMMU (page) fault will raise a softirq-tasklet which will then
deal with the actual fault records by clearing the logs and re-enabling
interrupts from the offending IOMMU(s). A single tasklet is being used
even if there are more than just one IOMMU in the system, as the event
should be rare enough.

The series introduces the described mechanism for both Intel VT-d and
AMD-Vi, and has been tested on both platforms with an hacked DomU bnx2
network driver which was generating I/O page faults upon request.

Thanks and Regards,
Dario

[1] http://old-list-archives.xen.org/archives/html/xen-devel/2011-08/msg006=
38.html

--
0 iommu-fault-tasklet_vtd.patch
1 iommu-fault-tasklet_amd.patch
--
 xen/drivers/passthrough/amd/iommu_init.c |  45 +++++++++++++++++++++++++++=
+++++++++++++++---
 xen/drivers/passthrough/vtd/iommu.c      |  35 +++++++++++++++++++++++++++=
+++++---
 2 files changed, 74 insertions(+), 6 deletions(-)

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-------------------------------------------------------------------
Dario Faggioli, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
PhD Candidate, ReTiS Lab, Scuola Superiore Sant'Anna, Pisa (Italy)


--=-uPzGRdN53Jz9tbzNc/9w
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEABECAAYFAk7vg60ACgkQk4XaBE3IOsRlRwCeNIZWx5iU7tsYcHsZWw8r5bfn
fYwAnAgC95waYk9h4wL4psSAcA+tvAj4
=qYN3
-----END PGP SIGNATURE-----

--=-uPzGRdN53Jz9tbzNc/9w--



--===============2650221521348332798==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============2650221521348332798==--



From xen-devel-bounces@lists.xensource.com Mon Dec 19 18:35:05 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 18:35:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rci2q-0003pD-IO; Mon, 19 Dec 2011 18:34:40 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1Rci2p-0003p8-5b
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 18:34:39 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-11.tower-216.messagelabs.com!1324319672!7992387!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10011 invoked from network); 19 Dec 2011 18:34:32 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-11.tower-216.messagelabs.com with SMTP;
	19 Dec 2011 18:34:32 -0000
Received: from [62.94.181.91] (account d.faggioli@sssup.it HELO [192.168.0.40])
	by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 74030753; Mon, 19 Dec 2011 19:34:31 +0100
Message-ID: <1324319661.2599.28.camel@Solace>
From: Dario Faggioli <raistlin@linux.it>
To: xen-devel@lists.xensource.com
Date: Mon, 19 Dec 2011 19:34:21 +0100
X-Mailer: Evolution 3.0.3-3+b1 
Mime-Version: 1.0
Cc: Wei Wang2 <wei.wang2@amd.com>,
	"allen.m.kay@intel.com" <allen.m.kay@intel.com>,
	Tim Deegan <tim@xen.org>, Jan Beulich <JBeulich@suse.com>
Subject: [Xen-devel] [PATCH 0 of 3] Deal with IOMMU faults in softirq
	context.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============2650221521348332798=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--===============2650221521348332798==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-uPzGRdN53Jz9tbzNc/9w"


--=-uPzGRdN53Jz9tbzNc/9w
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hello everyone,

As already discussed here [1], dealing with IOMMU faults in interrupt
context may cause nasty things to happen, up to being used as a form of
DoS attack, e.g., by generating a "storm" of IOMMU faults that will
livelock a pCPU.

To avoid this, IOMMU faults handling is being moved from interrupt to
softirq context. Basically, the inerrupt handler of the IRQ originated
by an IOMMU (page) fault will raise a softirq-tasklet which will then
deal with the actual fault records by clearing the logs and re-enabling
interrupts from the offending IOMMU(s). A single tasklet is being used
even if there are more than just one IOMMU in the system, as the event
should be rare enough.

The series introduces the described mechanism for both Intel VT-d and
AMD-Vi, and has been tested on both platforms with an hacked DomU bnx2
network driver which was generating I/O page faults upon request.

Thanks and Regards,
Dario

[1] http://old-list-archives.xen.org/archives/html/xen-devel/2011-08/msg006=
38.html

--
0 iommu-fault-tasklet_vtd.patch
1 iommu-fault-tasklet_amd.patch
--
 xen/drivers/passthrough/amd/iommu_init.c |  45 +++++++++++++++++++++++++++=
+++++++++++++++---
 xen/drivers/passthrough/vtd/iommu.c      |  35 +++++++++++++++++++++++++++=
+++++---
 2 files changed, 74 insertions(+), 6 deletions(-)

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-------------------------------------------------------------------
Dario Faggioli, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
PhD Candidate, ReTiS Lab, Scuola Superiore Sant'Anna, Pisa (Italy)


--=-uPzGRdN53Jz9tbzNc/9w
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEABECAAYFAk7vg60ACgkQk4XaBE3IOsRlRwCeNIZWx5iU7tsYcHsZWw8r5bfn
fYwAnAgC95waYk9h4wL4psSAcA+tvAj4
=qYN3
-----END PGP SIGNATURE-----

--=-uPzGRdN53Jz9tbzNc/9w--



--===============2650221521348332798==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============2650221521348332798==--



From xen-devel-bounces@lists.xensource.com Mon Dec 19 18:47:35 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 18: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.xensource.com>)
	id 1RciEx-0003zv-Sf; Mon, 19 Dec 2011 18:47:11 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RciEw-0003zq-Lh
	for Xen-devel@lists.xensource.com; Mon, 19 Dec 2011 18:47:10 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-9.tower-182.messagelabs.com!1324320423!7877560!1
X-Originating-IP: [63.239.65.40]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21466 invoked from network); 19 Dec 2011 18:47:04 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-9.tower-182.messagelabs.com with SMTP;
	19 Dec 2011 18:47:04 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea02.nsa.gov (8.12.10/8.12.10) with ESMTP id
	pBJIk50f026478; Mon, 19 Dec 2011 18:46:05 GMT
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id pBJIk48r018344; 
	Mon, 19 Dec 2011 13:46:04 -0500
Message-ID: <4EEF866F.1030002@tycho.nsa.gov>
Date: Mon, 19 Dec 2011 13:46:07 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:8.0) Gecko/20111115 Thunderbird/8.0
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <1323893534-436-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1323893534-436-2-git-send-email-dgdegra@tycho.nsa.gov>
	<20111216195620.GB26802@andromeda.dapyr.net>
	<4EEF7993.2060301@tycho.nsa.gov>
	<20111219181655.GA3832@phenom.dumpdata.com>
In-Reply-To: <20111219181655.GA3832@phenom.dumpdata.com>
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>, Xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 1/6] xenbus: Support HVM backends
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 12/19/2011 01:16 PM, Konrad Rzeszutek Wilk wrote:
> On Mon, Dec 19, 2011 at 12:51:15PM -0500, Daniel De Graaf wrote:
>> On 12/16/2011 02:56 PM, Konrad Rzeszutek Wilk wrote:
>>> On Wed, Dec 14, 2011 at 03:12:09PM -0500, Daniel De Graaf wrote:
>>>> Add HVM implementations of xenbus_(map,unmap)_ring_v(alloc,free) so
>>>> that ring mappings can be done without using GNTMAP_contains_pte which
>>>> is not supported on HVM.
>>>>
>>>> Signed-off-by: Daniel De Graaf<dgdegra@tycho.nsa.gov>
>>>> ---
>>>>   drivers/xen/xenbus/xenbus_client.c |  155 +++++++++++++++++++++++++++++-------
>>>>   1 files changed, 125 insertions(+), 30 deletions(-)
>>>>
>>>> diff --git a/drivers/xen/xenbus/xenbus_client.c b/drivers/xen/xenbus/xenbus_client.c
>>>> index 1906125..ecd695d 100644
>>>> --- a/drivers/xen/xenbus/xenbus_client.c
>>>> +++ b/drivers/xen/xenbus/xenbus_client.c
>>>> @@ -32,16 +32,27 @@
>>>>
>>>>   #include<linux/slab.h>
>>>>   #include<linux/types.h>
>>>> +#include<linux/spinlock.h>
>>>>   #include<linux/vmalloc.h>
>>>>   #include<linux/export.h>
>>>>   #include<asm/xen/hypervisor.h>
>>>>   #include<asm/xen/page.h>
>>>>   #include<xen/interface/xen.h>
>>>>   #include<xen/interface/event_channel.h>
>>>> +#include<xen/balloon.h>
>>>>   #include<xen/events.h>
>>>>   #include<xen/grant_table.h>
>>>>   #include<xen/xenbus.h>
>>>>
>>>> +struct xenbus_map_node {
>>>> +	struct list_head next;
>>>> +	struct page *page;
>>>> +	grant_handle_t handle;
>>>> +};
>>>> +
>>>> +static DEFINE_SPINLOCK(xenbus_valloc_lock);
>>>> +static LIST_HEAD(xenbus_valloc_pages);
>>>
>>> Could we use this for what the PV version of xenbus_unmap_ring_vfree
>>> does? (where it uses the vmlist_lock to look for the appropiate vaddr).
>>>
>>> Could the vmlist_lock be removed and instead we can use this structure
>>> for both PV and HVM?
>>
>> Yes, the next version will do this.
>>
>> [...]
>>>> +
>>>> +/**
>>>> + * xenbus_map_ring_valloc
>>>> + * @dev: xenbus device
>>>> + * @gnt_ref: grant reference
>>>> + * @vaddr: pointer to address to be filled out by mapping
>>>> + *
>>>> + * Based on Rusty Russell's skeleton driver's map_page.
>>>> + * Map a page of memory into this domain from another domain's grant table.
>>>> + * xenbus_map_ring_valloc allocates a page of virtual address space, maps the
>>>> + * page to that address, and sets *vaddr to that address.
>>>> + * Returns 0 on success, and GNTST_* (see xen/include/interface/grant_table.h)
>>>> + * or -ENOMEM on error. If an error is returned, device will switch to
>>>> + * XenbusStateClosing and the error message will be saved in XenStore.
>>>> + */
>>>> +int xenbus_map_ring_valloc(struct xenbus_device *dev, int gnt_ref, void **vaddr)
>>>> +{
>>>> +	if (xen_pv_domain())
>>>> +		return xenbus_map_ring_valloc_pv(dev, gnt_ref, vaddr);
>>>> +	else
>>>> +		return xenbus_map_ring_valloc_hvm(dev, gnt_ref, vaddr);
>>>
>>> This could be done in a similar way which Annie's granttable v2 patches are done.
>>>
>>> Meaning define something like:
>>>
>>> struct xenbus_ring_ops {
>>> 	int (*map)(struct xenbus_device *dev, int gnt, void *vaddr);
>>> 	...
>>>
>>> And then define two variants of it (PV and HVM):
>>>
>>> struct xenbus_ring_ops pv_ring_ops = {
>>> 	.map = xenbus_map_ring_valloc_pv;
>>> 	..
>>> }
>>>
>>> have a static to which either one will be assigned:
>>>
>>> static struct xenbus_ring_ops *ring_ops;
>>>
>>> And in the init function:
>>>
>>> void __init xenbus_ring_ops_init(void)
>>> {
>>> 	if (xen_hvm_domain)
>>> 		ring_ops = hvm_ring_ops;
>>> 	else
>>> 	...
>>>
>>> And then xenbus_init() calls the xenbus_rings_ops_init().
>>>
>>> Then these 'xenbus_map_ring_valloc' end up just using the
>>> ring_ops->map call.
>>
>> Is the reason for doing this just to avoid overhead? The overhead from
>> an indirect function call is much higher than from an integer comparison
>> (which is what xen_pv_domain resolves to). In this case, the _pv and _hvm
>> functions are both inlined into the dispatch function.
>
> Do we care about that? How often are these calls made?

Not all that often - domain creation and destruction or device plug/unplug.
So performance doesn't really matter. Is there a reason to prefer an _ops
structure for this instead of direct calls?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 18:47:35 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 18: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.xensource.com>)
	id 1RciEx-0003zv-Sf; Mon, 19 Dec 2011 18:47:11 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RciEw-0003zq-Lh
	for Xen-devel@lists.xensource.com; Mon, 19 Dec 2011 18:47:10 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-9.tower-182.messagelabs.com!1324320423!7877560!1
X-Originating-IP: [63.239.65.40]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21466 invoked from network); 19 Dec 2011 18:47:04 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-9.tower-182.messagelabs.com with SMTP;
	19 Dec 2011 18:47:04 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea02.nsa.gov (8.12.10/8.12.10) with ESMTP id
	pBJIk50f026478; Mon, 19 Dec 2011 18:46:05 GMT
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id pBJIk48r018344; 
	Mon, 19 Dec 2011 13:46:04 -0500
Message-ID: <4EEF866F.1030002@tycho.nsa.gov>
Date: Mon, 19 Dec 2011 13:46:07 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:8.0) Gecko/20111115 Thunderbird/8.0
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <1323893534-436-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1323893534-436-2-git-send-email-dgdegra@tycho.nsa.gov>
	<20111216195620.GB26802@andromeda.dapyr.net>
	<4EEF7993.2060301@tycho.nsa.gov>
	<20111219181655.GA3832@phenom.dumpdata.com>
In-Reply-To: <20111219181655.GA3832@phenom.dumpdata.com>
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>, Xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 1/6] xenbus: Support HVM backends
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 12/19/2011 01:16 PM, Konrad Rzeszutek Wilk wrote:
> On Mon, Dec 19, 2011 at 12:51:15PM -0500, Daniel De Graaf wrote:
>> On 12/16/2011 02:56 PM, Konrad Rzeszutek Wilk wrote:
>>> On Wed, Dec 14, 2011 at 03:12:09PM -0500, Daniel De Graaf wrote:
>>>> Add HVM implementations of xenbus_(map,unmap)_ring_v(alloc,free) so
>>>> that ring mappings can be done without using GNTMAP_contains_pte which
>>>> is not supported on HVM.
>>>>
>>>> Signed-off-by: Daniel De Graaf<dgdegra@tycho.nsa.gov>
>>>> ---
>>>>   drivers/xen/xenbus/xenbus_client.c |  155 +++++++++++++++++++++++++++++-------
>>>>   1 files changed, 125 insertions(+), 30 deletions(-)
>>>>
>>>> diff --git a/drivers/xen/xenbus/xenbus_client.c b/drivers/xen/xenbus/xenbus_client.c
>>>> index 1906125..ecd695d 100644
>>>> --- a/drivers/xen/xenbus/xenbus_client.c
>>>> +++ b/drivers/xen/xenbus/xenbus_client.c
>>>> @@ -32,16 +32,27 @@
>>>>
>>>>   #include<linux/slab.h>
>>>>   #include<linux/types.h>
>>>> +#include<linux/spinlock.h>
>>>>   #include<linux/vmalloc.h>
>>>>   #include<linux/export.h>
>>>>   #include<asm/xen/hypervisor.h>
>>>>   #include<asm/xen/page.h>
>>>>   #include<xen/interface/xen.h>
>>>>   #include<xen/interface/event_channel.h>
>>>> +#include<xen/balloon.h>
>>>>   #include<xen/events.h>
>>>>   #include<xen/grant_table.h>
>>>>   #include<xen/xenbus.h>
>>>>
>>>> +struct xenbus_map_node {
>>>> +	struct list_head next;
>>>> +	struct page *page;
>>>> +	grant_handle_t handle;
>>>> +};
>>>> +
>>>> +static DEFINE_SPINLOCK(xenbus_valloc_lock);
>>>> +static LIST_HEAD(xenbus_valloc_pages);
>>>
>>> Could we use this for what the PV version of xenbus_unmap_ring_vfree
>>> does? (where it uses the vmlist_lock to look for the appropiate vaddr).
>>>
>>> Could the vmlist_lock be removed and instead we can use this structure
>>> for both PV and HVM?
>>
>> Yes, the next version will do this.
>>
>> [...]
>>>> +
>>>> +/**
>>>> + * xenbus_map_ring_valloc
>>>> + * @dev: xenbus device
>>>> + * @gnt_ref: grant reference
>>>> + * @vaddr: pointer to address to be filled out by mapping
>>>> + *
>>>> + * Based on Rusty Russell's skeleton driver's map_page.
>>>> + * Map a page of memory into this domain from another domain's grant table.
>>>> + * xenbus_map_ring_valloc allocates a page of virtual address space, maps the
>>>> + * page to that address, and sets *vaddr to that address.
>>>> + * Returns 0 on success, and GNTST_* (see xen/include/interface/grant_table.h)
>>>> + * or -ENOMEM on error. If an error is returned, device will switch to
>>>> + * XenbusStateClosing and the error message will be saved in XenStore.
>>>> + */
>>>> +int xenbus_map_ring_valloc(struct xenbus_device *dev, int gnt_ref, void **vaddr)
>>>> +{
>>>> +	if (xen_pv_domain())
>>>> +		return xenbus_map_ring_valloc_pv(dev, gnt_ref, vaddr);
>>>> +	else
>>>> +		return xenbus_map_ring_valloc_hvm(dev, gnt_ref, vaddr);
>>>
>>> This could be done in a similar way which Annie's granttable v2 patches are done.
>>>
>>> Meaning define something like:
>>>
>>> struct xenbus_ring_ops {
>>> 	int (*map)(struct xenbus_device *dev, int gnt, void *vaddr);
>>> 	...
>>>
>>> And then define two variants of it (PV and HVM):
>>>
>>> struct xenbus_ring_ops pv_ring_ops = {
>>> 	.map = xenbus_map_ring_valloc_pv;
>>> 	..
>>> }
>>>
>>> have a static to which either one will be assigned:
>>>
>>> static struct xenbus_ring_ops *ring_ops;
>>>
>>> And in the init function:
>>>
>>> void __init xenbus_ring_ops_init(void)
>>> {
>>> 	if (xen_hvm_domain)
>>> 		ring_ops = hvm_ring_ops;
>>> 	else
>>> 	...
>>>
>>> And then xenbus_init() calls the xenbus_rings_ops_init().
>>>
>>> Then these 'xenbus_map_ring_valloc' end up just using the
>>> ring_ops->map call.
>>
>> Is the reason for doing this just to avoid overhead? The overhead from
>> an indirect function call is much higher than from an integer comparison
>> (which is what xen_pv_domain resolves to). In this case, the _pv and _hvm
>> functions are both inlined into the dispatch function.
>
> Do we care about that? How often are these calls made?

Not all that often - domain creation and destruction or device plug/unplug.
So performance doesn't really matter. Is there a reason to prefer an _ops
structure for this instead of direct calls?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 18:52:37 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 18:52:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RciJo-00047y-KL; Mon, 19 Dec 2011 18:52:12 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1RciJm-00047m-Tu
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 18:52:11 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-7.tower-27.messagelabs.com!1324320671!61377493!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29940 invoked from network); 19 Dec 2011 18:51:11 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-7.tower-27.messagelabs.com with SMTP;
	19 Dec 2011 18:51:11 -0000
Received: from [62.94.181.91] (account d.faggioli@sssup.it HELO [192.168.0.40])
	by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 74031040; Mon, 19 Dec 2011 19:52:05 +0100
Message-ID: <1324320715.2599.32.camel@Solace>
From: Dario Faggioli <raistlin@linux.it>
To: xen-devel@lists.xensource.com
Date: Mon, 19 Dec 2011 19:51:55 +0100
In-Reply-To: <1324319661.2599.28.camel@Solace>
References: <1324319661.2599.28.camel@Solace>
X-Mailer: Evolution 3.0.3-3+b1 
Mime-Version: 1.0
Cc: Wei Wang2 <wei.wang2@amd.com>, Tim Deegan <tim@xen.org>,
	"allen.m.kay@intel.com" <allen.m.kay@intel.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: [Xen-devel] PATCH 1 of 2] Move IOMMU faults handling into softirq
	for VT-d.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============5204897851634191203=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--===============5204897851634191203==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-KOxJmKa6mImcn2Kq8wTn"


--=-KOxJmKa6mImcn2Kq8wTn
Content-Type: multipart/mixed; boundary="=-N6yQoollE8RdEVw5lITS"


--=-N6yQoollE8RdEVw5lITS
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Dealing with interrupts from VT-d IOMMU is deferred to a
softirq-tasklet, raised by the actual IRQ handler. Since a new interrupt
is not generated, even if further faults occur, until we cleared all the
pending ones, there's no need to disabling IRQs, as the hardware does it
by its own. Notice that this may cause the log to overflow, but none of
the existing entry will be overwritten.

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>

diff -r a4bffc85bb71 xen/drivers/passthrough/vtd/iommu.c
--- a/xen/drivers/passthrough/vtd/iommu.c	Mon Dec 19 09:37:52 2011 +0100
+++ b/xen/drivers/passthrough/vtd/iommu.c	Mon Dec 19 16:46:14 2011 +0000
@@ -53,6 +53,8 @@ bool_t __read_mostly untrusted_msi;
=20
 int nr_iommus;
=20
+static struct tasklet vtd_fault_tasklet;
+
 static void setup_dom0_device(struct pci_dev *);
 static void setup_dom0_rmrr(struct domain *d);
=20
@@ -918,10 +920,8 @@ static void iommu_fault_status(u32 fault
 }
=20
 #define PRIMARY_FAULT_REG_LEN (16)
-static void iommu_page_fault(int irq, void *dev_id,
-                             struct cpu_user_regs *regs)
+static void __do_iommu_page_fault(struct iommu *iommu)
 {
-    struct iommu *iommu =3D dev_id;
     int reg, fault_index;
     u32 fault_status;
     unsigned long flags;
@@ -996,6 +996,33 @@ clear_overflow:
     }
 }
=20
+static void do_iommu_page_fault(unsigned long data)
+{
+    struct acpi_drhd_unit *drhd;
+
+    if ( list_empty(&acpi_drhd_units) )
+    {
+       INTEL_IOMMU_DEBUG("no device found, something must be very wrong!\n=
");
+       return;
+    }
+
+    /* No matter from whom the interrupt came from, check all the
+     * IOMMUs present in the system. This allows for having just one
+     * tasklet (instead of one per each IOMMU) and should be more than
+     * fine, considering how rare the event of a fault should be. */
+    for_each_drhd_unit ( drhd )
+        __do_iommu_page_fault(drhd->iommu);
+}
+
+static void iommu_page_fault(int irq, void *dev_id,
+                             struct cpu_user_regs *regs)
+{
+    /* Just flag the tasklet as runnable. This is fine, according to VT-d
+     * specs since a new interrupt won't be generated until we clear all
+     * the faults that caused this one to happen. */
+    tasklet_schedule(&vtd_fault_tasklet);
+}
+
 static void dma_msi_unmask(struct irq_desc *desc)
 {
     struct iommu *iommu =3D desc->action->dev_id;
@@ -2144,6 +2171,8 @@ int __init intel_vtd_setup(void)
         iommu->irq =3D ret;
     }
=20
+    softirq_tasklet_init(&vtd_fault_tasklet, do_iommu_page_fault, 0);
+
     if ( !iommu_qinval && iommu_intremap )
     {
         iommu_intremap =3D 0;


--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-------------------------------------------------------------------
Dario Faggioli, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
PhD Candidate, ReTiS Lab, Scuola Superiore Sant'Anna, Pisa (Italy)


--=-N6yQoollE8RdEVw5lITS
Content-Disposition: attachment; filename="iommu-fault-tasklet_vtd.patch"
Content-Transfer-Encoding: base64
Content-Type: text/x-patch; name="iommu-fault-tasklet_vtd.patch"; charset="UTF-8"

IyBIRyBjaGFuZ2VzZXQgcGF0Y2gNCiMgUGFyZW50IGU1YjEyNDg4ZjA3ZWJiOTVlZWM2Y2FmNjE1
MGYwZWRmNTgxNTc0OTQNCg0KZGlmZiAtciBlNWIxMjQ4OGYwN2UgeGVuL2RyaXZlcnMvcGFzc3Ro
cm91Z2gvdnRkL2lvbW11LmMNCi0tLSBhL3hlbi9kcml2ZXJzL3Bhc3N0aHJvdWdoL3Z0ZC9pb21t
dS5jCVR1ZSBEZWMgMTMgMTc6Mjk6MTIgMjAxMSArMDEwMA0KKysrIGIveGVuL2RyaXZlcnMvcGFz
c3Rocm91Z2gvdnRkL2lvbW11LmMJV2VkIERlYyAxNCAxMDowODo0NSAyMDExICswMTAwDQpAQCAt
OTE4LDEwICs5MTgsOSBAQCBzdGF0aWMgdm9pZCBpb21tdV9mYXVsdF9zdGF0dXModTMyIGZhdWx0
DQogfQ0KIA0KICNkZWZpbmUgUFJJTUFSWV9GQVVMVF9SRUdfTEVOICgxNikNCi1zdGF0aWMgdm9p
ZCBpb21tdV9wYWdlX2ZhdWx0KGludCBpcnEsIHZvaWQgKmRldl9pZCwNCi0gICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIHN0cnVjdCBjcHVfdXNlcl9yZWdzICpyZWdzKQ0KK3N0YXRpYyB2b2lk
IGRvX2lvbW11X3BhZ2VfZmF1bHQodW5zaWduZWQgbG9uZyBpb21tdV9wdHIpDQogew0KLSAgICBz
dHJ1Y3QgaW9tbXUgKmlvbW11ID0gZGV2X2lkOw0KKyAgICBzdHJ1Y3QgaW9tbXUgKmlvbW11ID0g
KHN0cnVjdCBpb21tdSopIGlvbW11X3B0cjsNCiAgICAgaW50IHJlZywgZmF1bHRfaW5kZXg7DQog
ICAgIHUzMiBmYXVsdF9zdGF0dXM7DQogICAgIHVuc2lnbmVkIGxvbmcgZmxhZ3M7DQpAQCAtOTk2
LDYgKzk5NSwxNCBAQCBjbGVhcl9vdmVyZmxvdzoNCiAgICAgfQ0KIH0NCiANCitzdGF0aWMgdm9p
ZCBpb21tdV9wYWdlX2ZhdWx0KGludCBpcnEsIHZvaWQgKmRldl9pZCwNCisgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIHN0cnVjdCBjcHVfdXNlcl9yZWdzICpyZWdzKQ0KK3sNCisgICAgc3Ry
dWN0IGlvbW11ICppb21tdSA9IGRldl9pZDsNCisNCisgICAgdGFza2xldF9zY2hlZHVsZSgmaW9t
bXUtPmZhdWx0X3Rhc2tsZXQpOw0KK30NCisNCiBzdGF0aWMgdm9pZCBkbWFfbXNpX3VubWFzayhz
dHJ1Y3QgaXJxX2Rlc2MgKmRlc2MpDQogew0KICAgICBzdHJ1Y3QgaW9tbXUgKmlvbW11ID0gZGVz
Yy0+YWN0aW9uLT5kZXZfaWQ7DQpAQCAtMjE0Miw2ICsyMTQ5LDkgQEAgaW50IF9faW5pdCBpbnRl
bF92dGRfc2V0dXAodm9pZCkNCiAgICAgICAgICAgICBnb3RvIGVycm9yOw0KICAgICAgICAgfQ0K
ICAgICAgICAgaW9tbXUtPmlycSA9IHJldDsNCisNCisgICAgICAgIHNvZnRpcnFfdGFza2xldF9p
bml0KCZpb21tdS0+ZmF1bHRfdGFza2xldCwgZG9faW9tbXVfcGFnZV9mYXVsdCwNCisgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICh1bnNpZ25lZCBsb25nKSBkcmhkLT5pb21tdSk7DQogICAg
IH0NCiANCiAgICAgaWYgKCAhaW9tbXVfcWludmFsICYmIGlvbW11X2ludHJlbWFwICkNCmRpZmYg
LXIgZTViMTI0ODhmMDdlIHhlbi9pbmNsdWRlL3hlbi9pb21tdS5oDQotLS0gYS94ZW4vaW5jbHVk
ZS94ZW4vaW9tbXUuaAlUdWUgRGVjIDEzIDE3OjI5OjEyIDIwMTEgKzAxMDANCisrKyBiL3hlbi9p
bmNsdWRlL3hlbi9pb21tdS5oCVdlZCBEZWMgMTQgMTA6MDg6NDUgMjAxMSArMDEwMA0KQEAgLTYz
LDYgKzYzLDcgQEAgc3RydWN0IGlvbW11IHsNCiAgICAgc3BpbmxvY2tfdCByZWdpc3Rlcl9sb2Nr
OyAvKiBwcm90ZWN0IGlvbW11IHJlZ2lzdGVyIGhhbmRsaW5nICovDQogICAgIHU2NCByb290X21h
ZGRyOyAvKiByb290IGVudHJ5IG1hY2hpbmUgYWRkcmVzcyAqLw0KICAgICBpbnQgaXJxOw0KKyAg
ICBzdHJ1Y3QgdGFza2xldCBmYXVsdF90YXNrbGV0Ow0KICAgICBzdHJ1Y3QgaW50ZWxfaW9tbXUg
KmludGVsOw0KICAgICB1bnNpZ25lZCBsb25nICpkb21pZF9iaXRtYXA7ICAvKiBkb21haW4gaWQg
Yml0bWFwICovDQogICAgIHUxNiAqZG9taWRfbWFwOyAgICAgICAgICAgICAgIC8qIGRvbWFpbiBp
ZCBtYXBwaW5nIGFycmF5ICovDQo=


--=-N6yQoollE8RdEVw5lITS--

--=-KOxJmKa6mImcn2Kq8wTn
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEUEABECAAYFAk7vh8sACgkQk4XaBE3IOsS7IwCfbQkr19Bo/V9bGKdzR0ELBcBJ
i/YAmKHrmsp/3BwsegSYwZ1S3yJGMZI=
=tT6g
-----END PGP SIGNATURE-----

--=-KOxJmKa6mImcn2Kq8wTn--



--===============5204897851634191203==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============5204897851634191203==--



From xen-devel-bounces@lists.xensource.com Mon Dec 19 18:52:37 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 18:52:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RciJo-00047y-KL; Mon, 19 Dec 2011 18:52:12 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1RciJm-00047m-Tu
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 18:52:11 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-7.tower-27.messagelabs.com!1324320671!61377493!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29940 invoked from network); 19 Dec 2011 18:51:11 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-7.tower-27.messagelabs.com with SMTP;
	19 Dec 2011 18:51:11 -0000
Received: from [62.94.181.91] (account d.faggioli@sssup.it HELO [192.168.0.40])
	by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 74031040; Mon, 19 Dec 2011 19:52:05 +0100
Message-ID: <1324320715.2599.32.camel@Solace>
From: Dario Faggioli <raistlin@linux.it>
To: xen-devel@lists.xensource.com
Date: Mon, 19 Dec 2011 19:51:55 +0100
In-Reply-To: <1324319661.2599.28.camel@Solace>
References: <1324319661.2599.28.camel@Solace>
X-Mailer: Evolution 3.0.3-3+b1 
Mime-Version: 1.0
Cc: Wei Wang2 <wei.wang2@amd.com>, Tim Deegan <tim@xen.org>,
	"allen.m.kay@intel.com" <allen.m.kay@intel.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: [Xen-devel] PATCH 1 of 2] Move IOMMU faults handling into softirq
	for VT-d.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============5204897851634191203=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--===============5204897851634191203==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-KOxJmKa6mImcn2Kq8wTn"


--=-KOxJmKa6mImcn2Kq8wTn
Content-Type: multipart/mixed; boundary="=-N6yQoollE8RdEVw5lITS"


--=-N6yQoollE8RdEVw5lITS
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Dealing with interrupts from VT-d IOMMU is deferred to a
softirq-tasklet, raised by the actual IRQ handler. Since a new interrupt
is not generated, even if further faults occur, until we cleared all the
pending ones, there's no need to disabling IRQs, as the hardware does it
by its own. Notice that this may cause the log to overflow, but none of
the existing entry will be overwritten.

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>

diff -r a4bffc85bb71 xen/drivers/passthrough/vtd/iommu.c
--- a/xen/drivers/passthrough/vtd/iommu.c	Mon Dec 19 09:37:52 2011 +0100
+++ b/xen/drivers/passthrough/vtd/iommu.c	Mon Dec 19 16:46:14 2011 +0000
@@ -53,6 +53,8 @@ bool_t __read_mostly untrusted_msi;
=20
 int nr_iommus;
=20
+static struct tasklet vtd_fault_tasklet;
+
 static void setup_dom0_device(struct pci_dev *);
 static void setup_dom0_rmrr(struct domain *d);
=20
@@ -918,10 +920,8 @@ static void iommu_fault_status(u32 fault
 }
=20
 #define PRIMARY_FAULT_REG_LEN (16)
-static void iommu_page_fault(int irq, void *dev_id,
-                             struct cpu_user_regs *regs)
+static void __do_iommu_page_fault(struct iommu *iommu)
 {
-    struct iommu *iommu =3D dev_id;
     int reg, fault_index;
     u32 fault_status;
     unsigned long flags;
@@ -996,6 +996,33 @@ clear_overflow:
     }
 }
=20
+static void do_iommu_page_fault(unsigned long data)
+{
+    struct acpi_drhd_unit *drhd;
+
+    if ( list_empty(&acpi_drhd_units) )
+    {
+       INTEL_IOMMU_DEBUG("no device found, something must be very wrong!\n=
");
+       return;
+    }
+
+    /* No matter from whom the interrupt came from, check all the
+     * IOMMUs present in the system. This allows for having just one
+     * tasklet (instead of one per each IOMMU) and should be more than
+     * fine, considering how rare the event of a fault should be. */
+    for_each_drhd_unit ( drhd )
+        __do_iommu_page_fault(drhd->iommu);
+}
+
+static void iommu_page_fault(int irq, void *dev_id,
+                             struct cpu_user_regs *regs)
+{
+    /* Just flag the tasklet as runnable. This is fine, according to VT-d
+     * specs since a new interrupt won't be generated until we clear all
+     * the faults that caused this one to happen. */
+    tasklet_schedule(&vtd_fault_tasklet);
+}
+
 static void dma_msi_unmask(struct irq_desc *desc)
 {
     struct iommu *iommu =3D desc->action->dev_id;
@@ -2144,6 +2171,8 @@ int __init intel_vtd_setup(void)
         iommu->irq =3D ret;
     }
=20
+    softirq_tasklet_init(&vtd_fault_tasklet, do_iommu_page_fault, 0);
+
     if ( !iommu_qinval && iommu_intremap )
     {
         iommu_intremap =3D 0;


--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-------------------------------------------------------------------
Dario Faggioli, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
PhD Candidate, ReTiS Lab, Scuola Superiore Sant'Anna, Pisa (Italy)


--=-N6yQoollE8RdEVw5lITS
Content-Disposition: attachment; filename="iommu-fault-tasklet_vtd.patch"
Content-Transfer-Encoding: base64
Content-Type: text/x-patch; name="iommu-fault-tasklet_vtd.patch"; charset="UTF-8"

IyBIRyBjaGFuZ2VzZXQgcGF0Y2gNCiMgUGFyZW50IGU1YjEyNDg4ZjA3ZWJiOTVlZWM2Y2FmNjE1
MGYwZWRmNTgxNTc0OTQNCg0KZGlmZiAtciBlNWIxMjQ4OGYwN2UgeGVuL2RyaXZlcnMvcGFzc3Ro
cm91Z2gvdnRkL2lvbW11LmMNCi0tLSBhL3hlbi9kcml2ZXJzL3Bhc3N0aHJvdWdoL3Z0ZC9pb21t
dS5jCVR1ZSBEZWMgMTMgMTc6Mjk6MTIgMjAxMSArMDEwMA0KKysrIGIveGVuL2RyaXZlcnMvcGFz
c3Rocm91Z2gvdnRkL2lvbW11LmMJV2VkIERlYyAxNCAxMDowODo0NSAyMDExICswMTAwDQpAQCAt
OTE4LDEwICs5MTgsOSBAQCBzdGF0aWMgdm9pZCBpb21tdV9mYXVsdF9zdGF0dXModTMyIGZhdWx0
DQogfQ0KIA0KICNkZWZpbmUgUFJJTUFSWV9GQVVMVF9SRUdfTEVOICgxNikNCi1zdGF0aWMgdm9p
ZCBpb21tdV9wYWdlX2ZhdWx0KGludCBpcnEsIHZvaWQgKmRldl9pZCwNCi0gICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIHN0cnVjdCBjcHVfdXNlcl9yZWdzICpyZWdzKQ0KK3N0YXRpYyB2b2lk
IGRvX2lvbW11X3BhZ2VfZmF1bHQodW5zaWduZWQgbG9uZyBpb21tdV9wdHIpDQogew0KLSAgICBz
dHJ1Y3QgaW9tbXUgKmlvbW11ID0gZGV2X2lkOw0KKyAgICBzdHJ1Y3QgaW9tbXUgKmlvbW11ID0g
KHN0cnVjdCBpb21tdSopIGlvbW11X3B0cjsNCiAgICAgaW50IHJlZywgZmF1bHRfaW5kZXg7DQog
ICAgIHUzMiBmYXVsdF9zdGF0dXM7DQogICAgIHVuc2lnbmVkIGxvbmcgZmxhZ3M7DQpAQCAtOTk2
LDYgKzk5NSwxNCBAQCBjbGVhcl9vdmVyZmxvdzoNCiAgICAgfQ0KIH0NCiANCitzdGF0aWMgdm9p
ZCBpb21tdV9wYWdlX2ZhdWx0KGludCBpcnEsIHZvaWQgKmRldl9pZCwNCisgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIHN0cnVjdCBjcHVfdXNlcl9yZWdzICpyZWdzKQ0KK3sNCisgICAgc3Ry
dWN0IGlvbW11ICppb21tdSA9IGRldl9pZDsNCisNCisgICAgdGFza2xldF9zY2hlZHVsZSgmaW9t
bXUtPmZhdWx0X3Rhc2tsZXQpOw0KK30NCisNCiBzdGF0aWMgdm9pZCBkbWFfbXNpX3VubWFzayhz
dHJ1Y3QgaXJxX2Rlc2MgKmRlc2MpDQogew0KICAgICBzdHJ1Y3QgaW9tbXUgKmlvbW11ID0gZGVz
Yy0+YWN0aW9uLT5kZXZfaWQ7DQpAQCAtMjE0Miw2ICsyMTQ5LDkgQEAgaW50IF9faW5pdCBpbnRl
bF92dGRfc2V0dXAodm9pZCkNCiAgICAgICAgICAgICBnb3RvIGVycm9yOw0KICAgICAgICAgfQ0K
ICAgICAgICAgaW9tbXUtPmlycSA9IHJldDsNCisNCisgICAgICAgIHNvZnRpcnFfdGFza2xldF9p
bml0KCZpb21tdS0+ZmF1bHRfdGFza2xldCwgZG9faW9tbXVfcGFnZV9mYXVsdCwNCisgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICh1bnNpZ25lZCBsb25nKSBkcmhkLT5pb21tdSk7DQogICAg
IH0NCiANCiAgICAgaWYgKCAhaW9tbXVfcWludmFsICYmIGlvbW11X2ludHJlbWFwICkNCmRpZmYg
LXIgZTViMTI0ODhmMDdlIHhlbi9pbmNsdWRlL3hlbi9pb21tdS5oDQotLS0gYS94ZW4vaW5jbHVk
ZS94ZW4vaW9tbXUuaAlUdWUgRGVjIDEzIDE3OjI5OjEyIDIwMTEgKzAxMDANCisrKyBiL3hlbi9p
bmNsdWRlL3hlbi9pb21tdS5oCVdlZCBEZWMgMTQgMTA6MDg6NDUgMjAxMSArMDEwMA0KQEAgLTYz
LDYgKzYzLDcgQEAgc3RydWN0IGlvbW11IHsNCiAgICAgc3BpbmxvY2tfdCByZWdpc3Rlcl9sb2Nr
OyAvKiBwcm90ZWN0IGlvbW11IHJlZ2lzdGVyIGhhbmRsaW5nICovDQogICAgIHU2NCByb290X21h
ZGRyOyAvKiByb290IGVudHJ5IG1hY2hpbmUgYWRkcmVzcyAqLw0KICAgICBpbnQgaXJxOw0KKyAg
ICBzdHJ1Y3QgdGFza2xldCBmYXVsdF90YXNrbGV0Ow0KICAgICBzdHJ1Y3QgaW50ZWxfaW9tbXUg
KmludGVsOw0KICAgICB1bnNpZ25lZCBsb25nICpkb21pZF9iaXRtYXA7ICAvKiBkb21haW4gaWQg
Yml0bWFwICovDQogICAgIHUxNiAqZG9taWRfbWFwOyAgICAgICAgICAgICAgIC8qIGRvbWFpbiBp
ZCBtYXBwaW5nIGFycmF5ICovDQo=


--=-N6yQoollE8RdEVw5lITS--

--=-KOxJmKa6mImcn2Kq8wTn
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEUEABECAAYFAk7vh8sACgkQk4XaBE3IOsS7IwCfbQkr19Bo/V9bGKdzR0ELBcBJ
i/YAmKHrmsp/3BwsegSYwZ1S3yJGMZI=
=tT6g
-----END PGP SIGNATURE-----

--=-KOxJmKa6mImcn2Kq8wTn--



--===============5204897851634191203==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============5204897851634191203==--



From xen-devel-bounces@lists.xensource.com Mon Dec 19 18:54:19 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 18:54:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RciLP-0004Cp-3v; Mon, 19 Dec 2011 18:53:51 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1RciLN-0004CY-OU
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 18:53:50 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-6.tower-21.messagelabs.com!1324320822!8672744!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4006 invoked from network); 19 Dec 2011 18:53:43 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-6.tower-21.messagelabs.com with SMTP;
	19 Dec 2011 18:53:43 -0000
Received: from [62.94.181.91] (account d.faggioli@sssup.it HELO [192.168.0.40])
	by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 74031066; Mon, 19 Dec 2011 19:53:42 +0100
Message-ID: <1324320812.2599.34.camel@Solace>
From: Dario Faggioli <raistlin@linux.it>
To: xen-devel@lists.xensource.com
Date: Mon, 19 Dec 2011 19:53:32 +0100
In-Reply-To: <1324319661.2599.28.camel@Solace>
References: <1324319661.2599.28.camel@Solace>
X-Mailer: Evolution 3.0.3-3+b1 
Mime-Version: 1.0
Cc: Wei Wang2 <wei.wang2@amd.com>, Tim Deegan <tim@xen.org>,
	"allen.m.kay@intel.com" <allen.m.kay@intel.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: [Xen-devel] [PATCH 2 of 2] Move IOMMU faults handling into softirq
	for AMD-Vi.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============4826422079005817844=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--===============4826422079005817844==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-8wzlB1E7qvtUZsb481cE"


--=-8wzlB1E7qvtUZsb481cE
Content-Type: multipart/mixed; boundary="=-qLgAQfWdlgT4mNDc0MAK"


--=-qLgAQfWdlgT4mNDc0MAK
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Dealing with interrupts from AMD-Vi IOMMU is deferred to a softirq-tasklet,
raised by the actual IRQ handler. To avoid more interrupts being generated
(because of further faults), they must be masked in the IOMMU within the
low level IRQ handler and enabled back in the tasklet body. Notice that
this may cause the log to overflow, but none of the existing entry will
be overwritten.

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>

diff -r 12cc8fc9a908 xen/drivers/passthrough/amd/iommu_init.c
--- a/xen/drivers/passthrough/amd/iommu_init.c	Mon Dec 19 16:46:14 2011 +00=
00
+++ b/xen/drivers/passthrough/amd/iommu_init.c	Mon Dec 19 16:46:39 2011 +00=
00
@@ -32,6 +32,8 @@
=20
 static int __initdata nr_amd_iommus;
=20
+static struct tasklet amd_iommu_fault_tasklet;
+
 unsigned short ivrs_bdf_entries;
 static struct radix_tree_root ivrs_maps;
 struct list_head amd_iommu_head;
@@ -522,12 +524,10 @@ static void parse_event_log_entry(struct
     }
 }
=20
-static void amd_iommu_page_fault(int irq, void *dev_id,
-                             struct cpu_user_regs *regs)
+static void __do_amd_iommu_page_fault(struct amd_iommu *iommu)
 {
     u32 entry;
     unsigned long flags;
-    struct amd_iommu *iommu =3D dev_id;
=20
     spin_lock_irqsave(&iommu->lock, flags);
     amd_iommu_read_event_log(iommu);
@@ -546,6 +546,43 @@ static void amd_iommu_page_fault(int irq
     spin_unlock_irqrestore(&iommu->lock, flags);
 }
=20
+static void do_amd_iommu_page_fault(unsigned long data)
+{
+    struct amd_iommu *iommu;
+
+    if ( list_empty(&amd_iommu_head) )
+    {
+       AMD_IOMMU_DEBUG("no device found, something must be very wrong!\n")=
;
+       return;
+    }
+
+    /* No matter from whom the interrupt came from, check all the
+     * IOMMUs present in the system. This allows for having just one
+     * tasklet (instead of one per each IOMMU) and should be more than
+     * fine, considering how rare the event of a fault should be. */
+for_each_amd_iommu ( iommu )
+        __do_amd_iommu_page_fault(iommu);
+}
+
+static void amd_iommu_page_fault(int irq, void *dev_id,
+                             struct cpu_user_regs *regs)
+{
+    u32 entry;
+    unsigned long flags;
+    struct amd_iommu *iommu =3D dev_id;
+
+    /* silence interrupts. The tasklet will enable them back */
+    spin_lock_irqsave(&iommu->lock, flags);
+    entry =3D readl(iommu->mmio_base + IOMMU_STATUS_MMIO_OFFSET);
+    iommu_clear_bit(&entry, IOMMU_STATUS_EVENT_LOG_INT_SHIFT);
+    writel(entry, iommu->mmio_base+IOMMU_STATUS_MMIO_OFFSET);
+    spin_unlock_irqrestore(&iommu->lock, flags);
+
+    /* Flag the tasklet as runnable so that it can execute, clear
+     * the log and re-enable interrupts. */
+    tasklet_schedule(&amd_iommu_fault_tasklet);
+}
+
 static int __init set_iommu_interrupt_handler(struct amd_iommu *iommu)
 {
     int irq, ret;
@@ -884,6 +921,8 @@ int __init amd_iommu_init(void)
         if ( amd_iommu_init_one(iommu) !=3D 0 )
             goto error_out;
=20
+    softirq_tasklet_init(&amd_iommu_fault_tasklet, do_amd_iommu_page_fault=
, 0);
+
     return 0;
=20
 error_out:

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-------------------------------------------------------------------
Dario Faggioli, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
PhD Candidate, ReTiS Lab, Scuola Superiore Sant'Anna, Pisa (Italy)


--=-qLgAQfWdlgT4mNDc0MAK
Content-Disposition: attachment; filename="iommu-fault-tasklet_amd.patch"
Content-Transfer-Encoding: base64
Content-Type: text/x-patch; name="iommu-fault-tasklet_amd.patch"; charset="UTF-8"

IyBIRyBjaGFuZ2VzZXQgcGF0Y2gNCiMgUGFyZW50IDEyY2M4ZmM5YTkwODI2ODE2ZjM4M2U4ZDNh
MjZhMGU4ZTBhNzY0NDUNCk1vdmUgSU9NTVUgZmF1bHRzIGhhbmRsaW5nIGludG8gc29mdGlycSBm
b3IgQU1ELVZpLg0KDQpEZWFsaW5nIHdpdGggaW50ZXJydXB0cyBmcm9tIEFNRC1WaSBJT01NVSBp
cyBkZWZlcnJlZCB0byBhIHNvZnRpcnEtdGFza2xldCwNCnJhaXNlZCBieSB0aGUgYWN0dWFsIElS
USBoYW5kbGVyLiBUbyBhdm9pZCBtb3JlIGludGVycnVwdHMgYmVpbmcgZ2VuZXJhdGVkDQooYmVj
YXVzZSBvZiBmdXJ0aGVyIGZhdWx0cyksIHRoZXkgbXVzdCBiZSBtYXNrZWQgaW4gdGhlIElPTU1V
IHdpdGhpbiB0aGUNCmxvdyBsZXZlbCBJUlEgaGFuZGxlciBhbmQgZW5hYmxlZCBiYWNrIGluIHRo
ZSB0YXNrbGV0IGJvZHkuIE5vdGljZSB0aGF0DQp0aGlzIG1heSBjYXVzZSB0aGUgbG9nIHRvIG92
ZXJmbG93LCBidXQgbm9uZSBvZiB0aGUgZXhpc3RpbmcgZW50cnkgd2lsbA0KYmUgb3ZlcndyaXR0
ZW4uDQoNClNpZ25lZC1vZmYtYnk6IERhcmlvIEZhZ2dpb2xpIDxkYXJpby5mYWdnaW9saUBjaXRy
aXguY29tPg0KDQpkaWZmIC1yIDEyY2M4ZmM5YTkwOCB4ZW4vZHJpdmVycy9wYXNzdGhyb3VnaC9h
bWQvaW9tbXVfaW5pdC5jDQotLS0gYS94ZW4vZHJpdmVycy9wYXNzdGhyb3VnaC9hbWQvaW9tbXVf
aW5pdC5jCU1vbiBEZWMgMTkgMTY6NDY6MTQgMjAxMSArMDAwMA0KKysrIGIveGVuL2RyaXZlcnMv
cGFzc3Rocm91Z2gvYW1kL2lvbW11X2luaXQuYwlNb24gRGVjIDE5IDE2OjQ2OjM5IDIwMTEgKzAw
MDANCkBAIC0zMiw2ICszMiw4IEBADQogDQogc3RhdGljIGludCBfX2luaXRkYXRhIG5yX2FtZF9p
b21tdXM7DQogDQorc3RhdGljIHN0cnVjdCB0YXNrbGV0IGFtZF9pb21tdV9mYXVsdF90YXNrbGV0
Ow0KKw0KIHVuc2lnbmVkIHNob3J0IGl2cnNfYmRmX2VudHJpZXM7DQogc3RhdGljIHN0cnVjdCBy
YWRpeF90cmVlX3Jvb3QgaXZyc19tYXBzOw0KIHN0cnVjdCBsaXN0X2hlYWQgYW1kX2lvbW11X2hl
YWQ7DQpAQCAtNTIyLDEyICs1MjQsMTAgQEAgc3RhdGljIHZvaWQgcGFyc2VfZXZlbnRfbG9nX2Vu
dHJ5KHN0cnVjdA0KICAgICB9DQogfQ0KIA0KLXN0YXRpYyB2b2lkIGFtZF9pb21tdV9wYWdlX2Zh
dWx0KGludCBpcnEsIHZvaWQgKmRldl9pZCwNCi0gICAgICAgICAgICAgICAgICAgICAgICAgICAg
IHN0cnVjdCBjcHVfdXNlcl9yZWdzICpyZWdzKQ0KK3N0YXRpYyB2b2lkIF9fZG9fYW1kX2lvbW11
X3BhZ2VfZmF1bHQoc3RydWN0IGFtZF9pb21tdSAqaW9tbXUpDQogew0KICAgICB1MzIgZW50cnk7
DQogICAgIHVuc2lnbmVkIGxvbmcgZmxhZ3M7DQotICAgIHN0cnVjdCBhbWRfaW9tbXUgKmlvbW11
ID0gZGV2X2lkOw0KIA0KICAgICBzcGluX2xvY2tfaXJxc2F2ZSgmaW9tbXUtPmxvY2ssIGZsYWdz
KTsNCiAgICAgYW1kX2lvbW11X3JlYWRfZXZlbnRfbG9nKGlvbW11KTsNCkBAIC01NDYsNiArNTQ2
LDQzIEBAIHN0YXRpYyB2b2lkIGFtZF9pb21tdV9wYWdlX2ZhdWx0KGludCBpcnENCiAgICAgc3Bp
bl91bmxvY2tfaXJxcmVzdG9yZSgmaW9tbXUtPmxvY2ssIGZsYWdzKTsNCiB9DQogDQorc3RhdGlj
IHZvaWQgZG9fYW1kX2lvbW11X3BhZ2VfZmF1bHQodW5zaWduZWQgbG9uZyBkYXRhKQ0KK3sNCisg
ICAgc3RydWN0IGFtZF9pb21tdSAqaW9tbXU7DQorDQorICAgIGlmICggbGlzdF9lbXB0eSgmYW1k
X2lvbW11X2hlYWQpICkNCisgICAgew0KKyAgICAgICBBTURfSU9NTVVfREVCVUcoIm5vIGRldmlj
ZSBmb3VuZCwgc29tZXRoaW5nIG11c3QgYmUgdmVyeSB3cm9uZyFcbiIpOw0KKyAgICAgICByZXR1
cm47DQorICAgIH0NCisNCisgICAgLyogTm8gbWF0dGVyIGZyb20gd2hvbSB0aGUgaW50ZXJydXB0
IGNhbWUgZnJvbSwgY2hlY2sgYWxsIHRoZQ0KKyAgICAgKiBJT01NVXMgcHJlc2VudCBpbiB0aGUg
c3lzdGVtLiBUaGlzIGFsbG93cyBmb3IgaGF2aW5nIGp1c3Qgb25lDQorICAgICAqIHRhc2tsZXQg
KGluc3RlYWQgb2Ygb25lIHBlciBlYWNoIElPTU1VKSBhbmQgc2hvdWxkIGJlIG1vcmUgdGhhbg0K
KyAgICAgKiBmaW5lLCBjb25zaWRlcmluZyBob3cgcmFyZSB0aGUgZXZlbnQgb2YgYSBmYXVsdCBz
aG91bGQgYmUuICovDQorZm9yX2VhY2hfYW1kX2lvbW11ICggaW9tbXUgKQ0KKyAgICAgICAgX19k
b19hbWRfaW9tbXVfcGFnZV9mYXVsdChpb21tdSk7DQorfQ0KKw0KK3N0YXRpYyB2b2lkIGFtZF9p
b21tdV9wYWdlX2ZhdWx0KGludCBpcnEsIHZvaWQgKmRldl9pZCwNCisgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIHN0cnVjdCBjcHVfdXNlcl9yZWdzICpyZWdzKQ0KK3sNCisgICAgdTMyIGVu
dHJ5Ow0KKyAgICB1bnNpZ25lZCBsb25nIGZsYWdzOw0KKyAgICBzdHJ1Y3QgYW1kX2lvbW11ICpp
b21tdSA9IGRldl9pZDsNCisNCisgICAgLyogc2lsZW5jZSBpbnRlcnJ1cHRzLiBUaGUgdGFza2xl
dCB3aWxsIGVuYWJsZSB0aGVtIGJhY2sgKi8NCisgICAgc3Bpbl9sb2NrX2lycXNhdmUoJmlvbW11
LT5sb2NrLCBmbGFncyk7DQorICAgIGVudHJ5ID0gcmVhZGwoaW9tbXUtPm1taW9fYmFzZSArIElP
TU1VX1NUQVRVU19NTUlPX09GRlNFVCk7DQorICAgIGlvbW11X2NsZWFyX2JpdCgmZW50cnksIElP
TU1VX1NUQVRVU19FVkVOVF9MT0dfSU5UX1NISUZUKTsNCisgICAgd3JpdGVsKGVudHJ5LCBpb21t
dS0+bW1pb19iYXNlK0lPTU1VX1NUQVRVU19NTUlPX09GRlNFVCk7DQorICAgIHNwaW5fdW5sb2Nr
X2lycXJlc3RvcmUoJmlvbW11LT5sb2NrLCBmbGFncyk7DQorDQorICAgIC8qIEZsYWcgdGhlIHRh
c2tsZXQgYXMgcnVubmFibGUgc28gdGhhdCBpdCBjYW4gZXhlY3V0ZSwgY2xlYXINCisgICAgICog
dGhlIGxvZyBhbmQgcmUtZW5hYmxlIGludGVycnVwdHMuICovDQorICAgIHRhc2tsZXRfc2NoZWR1
bGUoJmFtZF9pb21tdV9mYXVsdF90YXNrbGV0KTsNCit9DQorDQogc3RhdGljIGludCBfX2luaXQg
c2V0X2lvbW11X2ludGVycnVwdF9oYW5kbGVyKHN0cnVjdCBhbWRfaW9tbXUgKmlvbW11KQ0KIHsN
CiAgICAgaW50IGlycSwgcmV0Ow0KQEAgLTg4NCw2ICs5MjEsOCBAQCBpbnQgX19pbml0IGFtZF9p
b21tdV9pbml0KHZvaWQpDQogICAgICAgICBpZiAoIGFtZF9pb21tdV9pbml0X29uZShpb21tdSkg
IT0gMCApDQogICAgICAgICAgICAgZ290byBlcnJvcl9vdXQ7DQogDQorICAgIHNvZnRpcnFfdGFz
a2xldF9pbml0KCZhbWRfaW9tbXVfZmF1bHRfdGFza2xldCwgZG9fYW1kX2lvbW11X3BhZ2VfZmF1
bHQsIDApOw0KKw0KICAgICByZXR1cm4gMDsNCiANCiBlcnJvcl9vdXQ6DQo=


--=-qLgAQfWdlgT4mNDc0MAK--

--=-8wzlB1E7qvtUZsb481cE
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEABECAAYFAk7viCwACgkQk4XaBE3IOsSVngCfflxdPpMZh8mg7EigPC4VvwQx
4nkAoJtwda4ZGKuGDDbKEzBk+aaEBnSw
=d9H5
-----END PGP SIGNATURE-----

--=-8wzlB1E7qvtUZsb481cE--



--===============4826422079005817844==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============4826422079005817844==--



From xen-devel-bounces@lists.xensource.com Mon Dec 19 18:54:19 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 18:54:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RciLP-0004Cp-3v; Mon, 19 Dec 2011 18:53:51 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1RciLN-0004CY-OU
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 18:53:50 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-6.tower-21.messagelabs.com!1324320822!8672744!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4006 invoked from network); 19 Dec 2011 18:53:43 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-6.tower-21.messagelabs.com with SMTP;
	19 Dec 2011 18:53:43 -0000
Received: from [62.94.181.91] (account d.faggioli@sssup.it HELO [192.168.0.40])
	by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 74031066; Mon, 19 Dec 2011 19:53:42 +0100
Message-ID: <1324320812.2599.34.camel@Solace>
From: Dario Faggioli <raistlin@linux.it>
To: xen-devel@lists.xensource.com
Date: Mon, 19 Dec 2011 19:53:32 +0100
In-Reply-To: <1324319661.2599.28.camel@Solace>
References: <1324319661.2599.28.camel@Solace>
X-Mailer: Evolution 3.0.3-3+b1 
Mime-Version: 1.0
Cc: Wei Wang2 <wei.wang2@amd.com>, Tim Deegan <tim@xen.org>,
	"allen.m.kay@intel.com" <allen.m.kay@intel.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: [Xen-devel] [PATCH 2 of 2] Move IOMMU faults handling into softirq
	for AMD-Vi.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============4826422079005817844=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--===============4826422079005817844==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-8wzlB1E7qvtUZsb481cE"


--=-8wzlB1E7qvtUZsb481cE
Content-Type: multipart/mixed; boundary="=-qLgAQfWdlgT4mNDc0MAK"


--=-qLgAQfWdlgT4mNDc0MAK
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Dealing with interrupts from AMD-Vi IOMMU is deferred to a softirq-tasklet,
raised by the actual IRQ handler. To avoid more interrupts being generated
(because of further faults), they must be masked in the IOMMU within the
low level IRQ handler and enabled back in the tasklet body. Notice that
this may cause the log to overflow, but none of the existing entry will
be overwritten.

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>

diff -r 12cc8fc9a908 xen/drivers/passthrough/amd/iommu_init.c
--- a/xen/drivers/passthrough/amd/iommu_init.c	Mon Dec 19 16:46:14 2011 +00=
00
+++ b/xen/drivers/passthrough/amd/iommu_init.c	Mon Dec 19 16:46:39 2011 +00=
00
@@ -32,6 +32,8 @@
=20
 static int __initdata nr_amd_iommus;
=20
+static struct tasklet amd_iommu_fault_tasklet;
+
 unsigned short ivrs_bdf_entries;
 static struct radix_tree_root ivrs_maps;
 struct list_head amd_iommu_head;
@@ -522,12 +524,10 @@ static void parse_event_log_entry(struct
     }
 }
=20
-static void amd_iommu_page_fault(int irq, void *dev_id,
-                             struct cpu_user_regs *regs)
+static void __do_amd_iommu_page_fault(struct amd_iommu *iommu)
 {
     u32 entry;
     unsigned long flags;
-    struct amd_iommu *iommu =3D dev_id;
=20
     spin_lock_irqsave(&iommu->lock, flags);
     amd_iommu_read_event_log(iommu);
@@ -546,6 +546,43 @@ static void amd_iommu_page_fault(int irq
     spin_unlock_irqrestore(&iommu->lock, flags);
 }
=20
+static void do_amd_iommu_page_fault(unsigned long data)
+{
+    struct amd_iommu *iommu;
+
+    if ( list_empty(&amd_iommu_head) )
+    {
+       AMD_IOMMU_DEBUG("no device found, something must be very wrong!\n")=
;
+       return;
+    }
+
+    /* No matter from whom the interrupt came from, check all the
+     * IOMMUs present in the system. This allows for having just one
+     * tasklet (instead of one per each IOMMU) and should be more than
+     * fine, considering how rare the event of a fault should be. */
+for_each_amd_iommu ( iommu )
+        __do_amd_iommu_page_fault(iommu);
+}
+
+static void amd_iommu_page_fault(int irq, void *dev_id,
+                             struct cpu_user_regs *regs)
+{
+    u32 entry;
+    unsigned long flags;
+    struct amd_iommu *iommu =3D dev_id;
+
+    /* silence interrupts. The tasklet will enable them back */
+    spin_lock_irqsave(&iommu->lock, flags);
+    entry =3D readl(iommu->mmio_base + IOMMU_STATUS_MMIO_OFFSET);
+    iommu_clear_bit(&entry, IOMMU_STATUS_EVENT_LOG_INT_SHIFT);
+    writel(entry, iommu->mmio_base+IOMMU_STATUS_MMIO_OFFSET);
+    spin_unlock_irqrestore(&iommu->lock, flags);
+
+    /* Flag the tasklet as runnable so that it can execute, clear
+     * the log and re-enable interrupts. */
+    tasklet_schedule(&amd_iommu_fault_tasklet);
+}
+
 static int __init set_iommu_interrupt_handler(struct amd_iommu *iommu)
 {
     int irq, ret;
@@ -884,6 +921,8 @@ int __init amd_iommu_init(void)
         if ( amd_iommu_init_one(iommu) !=3D 0 )
             goto error_out;
=20
+    softirq_tasklet_init(&amd_iommu_fault_tasklet, do_amd_iommu_page_fault=
, 0);
+
     return 0;
=20
 error_out:

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-------------------------------------------------------------------
Dario Faggioli, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
PhD Candidate, ReTiS Lab, Scuola Superiore Sant'Anna, Pisa (Italy)


--=-qLgAQfWdlgT4mNDc0MAK
Content-Disposition: attachment; filename="iommu-fault-tasklet_amd.patch"
Content-Transfer-Encoding: base64
Content-Type: text/x-patch; name="iommu-fault-tasklet_amd.patch"; charset="UTF-8"

IyBIRyBjaGFuZ2VzZXQgcGF0Y2gNCiMgUGFyZW50IDEyY2M4ZmM5YTkwODI2ODE2ZjM4M2U4ZDNh
MjZhMGU4ZTBhNzY0NDUNCk1vdmUgSU9NTVUgZmF1bHRzIGhhbmRsaW5nIGludG8gc29mdGlycSBm
b3IgQU1ELVZpLg0KDQpEZWFsaW5nIHdpdGggaW50ZXJydXB0cyBmcm9tIEFNRC1WaSBJT01NVSBp
cyBkZWZlcnJlZCB0byBhIHNvZnRpcnEtdGFza2xldCwNCnJhaXNlZCBieSB0aGUgYWN0dWFsIElS
USBoYW5kbGVyLiBUbyBhdm9pZCBtb3JlIGludGVycnVwdHMgYmVpbmcgZ2VuZXJhdGVkDQooYmVj
YXVzZSBvZiBmdXJ0aGVyIGZhdWx0cyksIHRoZXkgbXVzdCBiZSBtYXNrZWQgaW4gdGhlIElPTU1V
IHdpdGhpbiB0aGUNCmxvdyBsZXZlbCBJUlEgaGFuZGxlciBhbmQgZW5hYmxlZCBiYWNrIGluIHRo
ZSB0YXNrbGV0IGJvZHkuIE5vdGljZSB0aGF0DQp0aGlzIG1heSBjYXVzZSB0aGUgbG9nIHRvIG92
ZXJmbG93LCBidXQgbm9uZSBvZiB0aGUgZXhpc3RpbmcgZW50cnkgd2lsbA0KYmUgb3ZlcndyaXR0
ZW4uDQoNClNpZ25lZC1vZmYtYnk6IERhcmlvIEZhZ2dpb2xpIDxkYXJpby5mYWdnaW9saUBjaXRy
aXguY29tPg0KDQpkaWZmIC1yIDEyY2M4ZmM5YTkwOCB4ZW4vZHJpdmVycy9wYXNzdGhyb3VnaC9h
bWQvaW9tbXVfaW5pdC5jDQotLS0gYS94ZW4vZHJpdmVycy9wYXNzdGhyb3VnaC9hbWQvaW9tbXVf
aW5pdC5jCU1vbiBEZWMgMTkgMTY6NDY6MTQgMjAxMSArMDAwMA0KKysrIGIveGVuL2RyaXZlcnMv
cGFzc3Rocm91Z2gvYW1kL2lvbW11X2luaXQuYwlNb24gRGVjIDE5IDE2OjQ2OjM5IDIwMTEgKzAw
MDANCkBAIC0zMiw2ICszMiw4IEBADQogDQogc3RhdGljIGludCBfX2luaXRkYXRhIG5yX2FtZF9p
b21tdXM7DQogDQorc3RhdGljIHN0cnVjdCB0YXNrbGV0IGFtZF9pb21tdV9mYXVsdF90YXNrbGV0
Ow0KKw0KIHVuc2lnbmVkIHNob3J0IGl2cnNfYmRmX2VudHJpZXM7DQogc3RhdGljIHN0cnVjdCBy
YWRpeF90cmVlX3Jvb3QgaXZyc19tYXBzOw0KIHN0cnVjdCBsaXN0X2hlYWQgYW1kX2lvbW11X2hl
YWQ7DQpAQCAtNTIyLDEyICs1MjQsMTAgQEAgc3RhdGljIHZvaWQgcGFyc2VfZXZlbnRfbG9nX2Vu
dHJ5KHN0cnVjdA0KICAgICB9DQogfQ0KIA0KLXN0YXRpYyB2b2lkIGFtZF9pb21tdV9wYWdlX2Zh
dWx0KGludCBpcnEsIHZvaWQgKmRldl9pZCwNCi0gICAgICAgICAgICAgICAgICAgICAgICAgICAg
IHN0cnVjdCBjcHVfdXNlcl9yZWdzICpyZWdzKQ0KK3N0YXRpYyB2b2lkIF9fZG9fYW1kX2lvbW11
X3BhZ2VfZmF1bHQoc3RydWN0IGFtZF9pb21tdSAqaW9tbXUpDQogew0KICAgICB1MzIgZW50cnk7
DQogICAgIHVuc2lnbmVkIGxvbmcgZmxhZ3M7DQotICAgIHN0cnVjdCBhbWRfaW9tbXUgKmlvbW11
ID0gZGV2X2lkOw0KIA0KICAgICBzcGluX2xvY2tfaXJxc2F2ZSgmaW9tbXUtPmxvY2ssIGZsYWdz
KTsNCiAgICAgYW1kX2lvbW11X3JlYWRfZXZlbnRfbG9nKGlvbW11KTsNCkBAIC01NDYsNiArNTQ2
LDQzIEBAIHN0YXRpYyB2b2lkIGFtZF9pb21tdV9wYWdlX2ZhdWx0KGludCBpcnENCiAgICAgc3Bp
bl91bmxvY2tfaXJxcmVzdG9yZSgmaW9tbXUtPmxvY2ssIGZsYWdzKTsNCiB9DQogDQorc3RhdGlj
IHZvaWQgZG9fYW1kX2lvbW11X3BhZ2VfZmF1bHQodW5zaWduZWQgbG9uZyBkYXRhKQ0KK3sNCisg
ICAgc3RydWN0IGFtZF9pb21tdSAqaW9tbXU7DQorDQorICAgIGlmICggbGlzdF9lbXB0eSgmYW1k
X2lvbW11X2hlYWQpICkNCisgICAgew0KKyAgICAgICBBTURfSU9NTVVfREVCVUcoIm5vIGRldmlj
ZSBmb3VuZCwgc29tZXRoaW5nIG11c3QgYmUgdmVyeSB3cm9uZyFcbiIpOw0KKyAgICAgICByZXR1
cm47DQorICAgIH0NCisNCisgICAgLyogTm8gbWF0dGVyIGZyb20gd2hvbSB0aGUgaW50ZXJydXB0
IGNhbWUgZnJvbSwgY2hlY2sgYWxsIHRoZQ0KKyAgICAgKiBJT01NVXMgcHJlc2VudCBpbiB0aGUg
c3lzdGVtLiBUaGlzIGFsbG93cyBmb3IgaGF2aW5nIGp1c3Qgb25lDQorICAgICAqIHRhc2tsZXQg
KGluc3RlYWQgb2Ygb25lIHBlciBlYWNoIElPTU1VKSBhbmQgc2hvdWxkIGJlIG1vcmUgdGhhbg0K
KyAgICAgKiBmaW5lLCBjb25zaWRlcmluZyBob3cgcmFyZSB0aGUgZXZlbnQgb2YgYSBmYXVsdCBz
aG91bGQgYmUuICovDQorZm9yX2VhY2hfYW1kX2lvbW11ICggaW9tbXUgKQ0KKyAgICAgICAgX19k
b19hbWRfaW9tbXVfcGFnZV9mYXVsdChpb21tdSk7DQorfQ0KKw0KK3N0YXRpYyB2b2lkIGFtZF9p
b21tdV9wYWdlX2ZhdWx0KGludCBpcnEsIHZvaWQgKmRldl9pZCwNCisgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIHN0cnVjdCBjcHVfdXNlcl9yZWdzICpyZWdzKQ0KK3sNCisgICAgdTMyIGVu
dHJ5Ow0KKyAgICB1bnNpZ25lZCBsb25nIGZsYWdzOw0KKyAgICBzdHJ1Y3QgYW1kX2lvbW11ICpp
b21tdSA9IGRldl9pZDsNCisNCisgICAgLyogc2lsZW5jZSBpbnRlcnJ1cHRzLiBUaGUgdGFza2xl
dCB3aWxsIGVuYWJsZSB0aGVtIGJhY2sgKi8NCisgICAgc3Bpbl9sb2NrX2lycXNhdmUoJmlvbW11
LT5sb2NrLCBmbGFncyk7DQorICAgIGVudHJ5ID0gcmVhZGwoaW9tbXUtPm1taW9fYmFzZSArIElP
TU1VX1NUQVRVU19NTUlPX09GRlNFVCk7DQorICAgIGlvbW11X2NsZWFyX2JpdCgmZW50cnksIElP
TU1VX1NUQVRVU19FVkVOVF9MT0dfSU5UX1NISUZUKTsNCisgICAgd3JpdGVsKGVudHJ5LCBpb21t
dS0+bW1pb19iYXNlK0lPTU1VX1NUQVRVU19NTUlPX09GRlNFVCk7DQorICAgIHNwaW5fdW5sb2Nr
X2lycXJlc3RvcmUoJmlvbW11LT5sb2NrLCBmbGFncyk7DQorDQorICAgIC8qIEZsYWcgdGhlIHRh
c2tsZXQgYXMgcnVubmFibGUgc28gdGhhdCBpdCBjYW4gZXhlY3V0ZSwgY2xlYXINCisgICAgICog
dGhlIGxvZyBhbmQgcmUtZW5hYmxlIGludGVycnVwdHMuICovDQorICAgIHRhc2tsZXRfc2NoZWR1
bGUoJmFtZF9pb21tdV9mYXVsdF90YXNrbGV0KTsNCit9DQorDQogc3RhdGljIGludCBfX2luaXQg
c2V0X2lvbW11X2ludGVycnVwdF9oYW5kbGVyKHN0cnVjdCBhbWRfaW9tbXUgKmlvbW11KQ0KIHsN
CiAgICAgaW50IGlycSwgcmV0Ow0KQEAgLTg4NCw2ICs5MjEsOCBAQCBpbnQgX19pbml0IGFtZF9p
b21tdV9pbml0KHZvaWQpDQogICAgICAgICBpZiAoIGFtZF9pb21tdV9pbml0X29uZShpb21tdSkg
IT0gMCApDQogICAgICAgICAgICAgZ290byBlcnJvcl9vdXQ7DQogDQorICAgIHNvZnRpcnFfdGFz
a2xldF9pbml0KCZhbWRfaW9tbXVfZmF1bHRfdGFza2xldCwgZG9fYW1kX2lvbW11X3BhZ2VfZmF1
bHQsIDApOw0KKw0KICAgICByZXR1cm4gMDsNCiANCiBlcnJvcl9vdXQ6DQo=


--=-qLgAQfWdlgT4mNDc0MAK--

--=-8wzlB1E7qvtUZsb481cE
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEABECAAYFAk7viCwACgkQk4XaBE3IOsSVngCfflxdPpMZh8mg7EigPC4VvwQx
4nkAoJtwda4ZGKuGDDbKEzBk+aaEBnSw
=d9H5
-----END PGP SIGNATURE-----

--=-8wzlB1E7qvtUZsb481cE--



--===============4826422079005817844==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============4826422079005817844==--



From xen-devel-bounces@lists.xensource.com Mon Dec 19 19:26:22 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 19:26:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RciqO-0004j2-0N; Mon, 19 Dec 2011 19:25:52 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RciqM-0004ix-T5
	for Xen-devel@lists.xensource.com; Mon, 19 Dec 2011 19:25:51 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1324322743!7883047!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ0Njk1NQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13953 invoked from network); 19 Dec 2011 19:25:44 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-14.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 19 Dec 2011 19:25:44 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pBJJOt5e016434
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 19 Dec 2011 19:24:56 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pBJJOrYS021910
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 19 Dec 2011 19:24:54 GMT
Received: from abhmt110.oracle.com (abhmt110.oracle.com [141.146.116.62])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pBJJOqul032422; Mon, 19 Dec 2011 13:24:53 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 19 Dec 2011 11:24:52 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id ADF87417B3; Mon, 19 Dec 2011 14:23:54 -0500 (EST)
Date: Mon, 19 Dec 2011 14:23:54 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Message-ID: <20111219192354.GA5413@phenom.dumpdata.com>
References: <1323893534-436-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1323893534-436-2-git-send-email-dgdegra@tycho.nsa.gov>
	<20111216195620.GB26802@andromeda.dapyr.net>
	<4EEF7993.2060301@tycho.nsa.gov>
	<20111219181655.GA3832@phenom.dumpdata.com>
	<4EEF866F.1030002@tycho.nsa.gov>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4EEF866F.1030002@tycho.nsa.gov>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A020209.4EEF8F88.0097,ss=1,re=0.000,fgs=0
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>, Xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 1/6] xenbus: Support HVM backends
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> >>>Then these 'xenbus_map_ring_valloc' end up just using the
> >>>ring_ops->map call.
> >>
> >>Is the reason for doing this just to avoid overhead? The overhead from
> >>an indirect function call is much higher than from an integer comparison
> >>(which is what xen_pv_domain resolves to). In this case, the _pv and _hvm
> >>functions are both inlined into the dispatch function.
> >
> >Do we care about that? How often are these calls made?
> 
> Not all that often - domain creation and destruction or device plug/unplug.
> So performance doesn't really matter. Is there a reason to prefer an _ops
> structure for this instead of direct calls?

Looks cleaner and fits the bill of where the rest of the Linux kernel is
going with using func structs for most everything.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 19:26:22 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 19:26:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RciqO-0004j2-0N; Mon, 19 Dec 2011 19:25:52 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RciqM-0004ix-T5
	for Xen-devel@lists.xensource.com; Mon, 19 Dec 2011 19:25:51 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1324322743!7883047!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ0Njk1NQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13953 invoked from network); 19 Dec 2011 19:25:44 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-14.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 19 Dec 2011 19:25:44 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pBJJOt5e016434
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 19 Dec 2011 19:24:56 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pBJJOrYS021910
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 19 Dec 2011 19:24:54 GMT
Received: from abhmt110.oracle.com (abhmt110.oracle.com [141.146.116.62])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pBJJOqul032422; Mon, 19 Dec 2011 13:24:53 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 19 Dec 2011 11:24:52 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id ADF87417B3; Mon, 19 Dec 2011 14:23:54 -0500 (EST)
Date: Mon, 19 Dec 2011 14:23:54 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Message-ID: <20111219192354.GA5413@phenom.dumpdata.com>
References: <1323893534-436-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1323893534-436-2-git-send-email-dgdegra@tycho.nsa.gov>
	<20111216195620.GB26802@andromeda.dapyr.net>
	<4EEF7993.2060301@tycho.nsa.gov>
	<20111219181655.GA3832@phenom.dumpdata.com>
	<4EEF866F.1030002@tycho.nsa.gov>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4EEF866F.1030002@tycho.nsa.gov>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A020209.4EEF8F88.0097,ss=1,re=0.000,fgs=0
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>, Xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 1/6] xenbus: Support HVM backends
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> >>>Then these 'xenbus_map_ring_valloc' end up just using the
> >>>ring_ops->map call.
> >>
> >>Is the reason for doing this just to avoid overhead? The overhead from
> >>an indirect function call is much higher than from an integer comparison
> >>(which is what xen_pv_domain resolves to). In this case, the _pv and _hvm
> >>functions are both inlined into the dispatch function.
> >
> >Do we care about that? How often are these calls made?
> 
> Not all that often - domain creation and destruction or device plug/unplug.
> So performance doesn't really matter. Is there a reason to prefer an _ops
> structure for this instead of direct calls?

Looks cleaner and fits the bill of where the rest of the Linux kernel is
going with using func structs for most everything.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 19:36:01 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 19:36:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rcizm-00050U-Bd; Mon, 19 Dec 2011 19:35:34 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Rcizk-00050P-Jo
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 19:35:32 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1324323296!53072169!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzA0OQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27696 invoked from network); 19 Dec 2011 19:34:56 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Dec 2011 19:34:56 -0000
X-IronPort-AV: E=Sophos;i="4.71,377,1320624000"; 
   d="scan'208";a="9564739"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Dec 2011 19:35:30 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 19 Dec 2011 19:35:30 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1Rcizi-0006Ti-AZ;
	Mon, 19 Dec 2011 19:35:30 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Rcizi-0003hj-9a;
	Mon, 19 Dec 2011 19:35:30 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10555-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 19 Dec 2011 19:35:30 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10555: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10555 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10555/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-sedf     14 guest-localmigrate/x10    fail REGR. vs. 10534
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass

version targeted for testing:
 xen                  a4bffc85bb71
baseline version:
 xen                  e3daa5b58464

------------------------------------------------------------
People who touched revisions under test:
  Boris Ostrovsky <boris.ostrovsky@amd.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Paul Durrant <paul.durrant@citrix.com>
  Wei Huang <wei.huang2@amd.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-unstable
+ revision=a4bffc85bb71
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-unstable a4bffc85bb71
+ branch=xen-unstable
+ revision=a4bffc85bb71
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ : xen@xenbits.xensource.com
+ : xen@xenbits.xensource.com:git/linux-pvops
+ : master
+ : tested/2.6.39.x
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r a4bffc85bb71 ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 1 changesets with 2 changes to 2 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 19:36:01 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 19:36:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rcizm-00050U-Bd; Mon, 19 Dec 2011 19:35:34 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Rcizk-00050P-Jo
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 19:35:32 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1324323296!53072169!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzA0OQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27696 invoked from network); 19 Dec 2011 19:34:56 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Dec 2011 19:34:56 -0000
X-IronPort-AV: E=Sophos;i="4.71,377,1320624000"; 
   d="scan'208";a="9564739"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Dec 2011 19:35:30 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 19 Dec 2011 19:35:30 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1Rcizi-0006Ti-AZ;
	Mon, 19 Dec 2011 19:35:30 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Rcizi-0003hj-9a;
	Mon, 19 Dec 2011 19:35:30 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10555-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 19 Dec 2011 19:35:30 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10555: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10555 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10555/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-sedf     14 guest-localmigrate/x10    fail REGR. vs. 10534
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass

version targeted for testing:
 xen                  a4bffc85bb71
baseline version:
 xen                  e3daa5b58464

------------------------------------------------------------
People who touched revisions under test:
  Boris Ostrovsky <boris.ostrovsky@amd.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Paul Durrant <paul.durrant@citrix.com>
  Wei Huang <wei.huang2@amd.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-unstable
+ revision=a4bffc85bb71
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-unstable a4bffc85bb71
+ branch=xen-unstable
+ revision=a4bffc85bb71
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ : xen@xenbits.xensource.com
+ : xen@xenbits.xensource.com:git/linux-pvops
+ : master
+ : tested/2.6.39.x
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r a4bffc85bb71 ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 1 changesets with 2 changes to 2 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 19:39:02 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 19:39:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rcj2m-00057e-Ve; Mon, 19 Dec 2011 19:38:40 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <rdunlap@xenotime.net>) id 1Rcj2l-00057U-1n
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 19:38:39 +0000
X-Env-Sender: rdunlap@xenotime.net
X-Msg-Ref: server-15.tower-182.messagelabs.com!1324323510!7833103!1
X-Originating-IP: [67.222.38.55]
X-SpamReason: No, hits=3.5 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA2Ny4yMjIuMzguNTUgPT4gMzMwMDQ=\n,sa_preprocessor: 
	QmFkIElQOiA2Ny4yMjIuMzguNTUgPT4gMzMwMDQ=\n, UNIQUE_WORDS,
	UPPERCASE_75_100
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 991 invoked from network); 19 Dec 2011 19:38:30 -0000
Received: from oproxy5-pub.bluehost.com (HELO oproxy5-pub.bluehost.com)
	(67.222.38.55) by server-15.tower-182.messagelabs.com with SMTP;
	19 Dec 2011 19:38:30 -0000
Received: (qmail 16745 invoked by uid 0); 19 Dec 2011 19:31:50 -0000
Received: from unknown (HELO box742.bluehost.com) (66.147.244.242)
	by cpoproxy2.bluehost.com with SMTP; 19 Dec 2011 19:31:50 -0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenotime.net;
	s=default; 
	h=Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID;
	bh=cLp+L9e2czxI57os8kHEYYxgtMG6DKNyh5ed1GALl5o=; 
	b=WQJRO5Z3VRwXZdPm+mXqy2RY41mLu5J2T/QvLf46baWlt1lGRniPVbeIHP9QIJgorgZeTAmk8EKCI7gRYCMoHKB+G53yvNHodVQ1SlWucpTeLGlGGXBAR7rXDAGMorty;
Received: from static-50-53-38-135.bvtn.or.frontiernet.net ([50.53.38.135]
	helo=[192.168.1.3])
	by box742.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256)
	(Exim 4.76) (envelope-from <rdunlap@xenotime.net>)
	id 1RciwA-0003vh-1G; Mon, 19 Dec 2011 12:31:50 -0700
Message-ID: <4EEF9F44.8080707@xenotime.net>
Date: Mon, 19 Dec 2011 12:32:04 -0800
From: Randy Dunlap <rdunlap@xenotime.net>
Organization: YPO4
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.15) Gecko/20110323 Thunderbird/3.1.9
MIME-Version: 1.0
To: Stephen Rothwell <sfr@canb.auug.org.au>
References: <20111219185556.f07c1f43e28cfd594aaa5fe0@canb.auug.org.au>
In-Reply-To: <20111219185556.f07c1f43e28cfd594aaa5fe0@canb.auug.org.au>
Content-Type: multipart/mixed; boundary="------------060000020604020105080200"
X-Identified-User: {1807:box742.bluehost.com:xenotime:xenotime.net}
	{sentby:smtp auth 50.53.38.135 authed with
	rdunlap@xenotime.net}
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	LKML <linux-kernel@vger.kernel.org>,
	Linux Virtualization <virtualization@lists.linux-foundation.org>,
	linux-next@vger.kernel.org
Subject: Re: [Xen-devel] linux-next: Tree for Dec 19 (xen)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a multi-part message in MIME format.
--------------060000020604020105080200
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 12/18/2011 11:55 PM, Stephen Rothwell wrote:
> Hi all,
> 
> Changes since 20111216:


drivers/xen/xenbus/xenbus_dev_frontend.c: In function 'xenbus_init':
drivers/xen/xenbus/xenbus_dev_frontend.c:609:2: error: implicit declaration of function 'xen_domain'

Full randconfig file is attached.

-- 
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***

--------------060000020604020105080200
Content-Type: text/plain;
 name="config-r3441"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename="config-r3441"

IwojIEF1dG9tYXRpY2FsbHkgZ2VuZXJhdGVkIGZpbGU7IERPIE5PVCBFRElULgojIExpbnV4
L3g4Nl82NCAzLjIuMC1yYzYgS2VybmVsIENvbmZpZ3VyYXRpb24KIwpDT05GSUdfNjRCSVQ9
eQojIENPTkZJR19YODZfMzIgaXMgbm90IHNldApDT05GSUdfWDg2XzY0PXkKQ09ORklHX1g4
Nj15CkNPTkZJR19JTlNUUlVDVElPTl9ERUNPREVSPXkKQ09ORklHX09VVFBVVF9GT1JNQVQ9
ImVsZjY0LXg4Ni02NCIKQ09ORklHX0FSQ0hfREVGQ09ORklHPSJhcmNoL3g4Ni9jb25maWdz
L3g4Nl82NF9kZWZjb25maWciCkNPTkZJR19HRU5FUklDX0NNT1NfVVBEQVRFPXkKQ09ORklH
X0NMT0NLU09VUkNFX1dBVENIRE9HPXkKQ09ORklHX0dFTkVSSUNfQ0xPQ0tFVkVOVFM9eQpD
T05GSUdfQVJDSF9DTE9DS1NPVVJDRV9EQVRBPXkKQ09ORklHX0dFTkVSSUNfQ0xPQ0tFVkVO
VFNfQlJPQURDQVNUPXkKQ09ORklHX0xPQ0tERVBfU1VQUE9SVD15CkNPTkZJR19TVEFDS1RS
QUNFX1NVUFBPUlQ9eQpDT05GSUdfSEFWRV9MQVRFTkNZVE9QX1NVUFBPUlQ9eQpDT05GSUdf
TU1VPXkKQ09ORklHX1pPTkVfRE1BPXkKQ09ORklHX05FRURfRE1BX01BUF9TVEFURT15CkNP
TkZJR19ORUVEX1NHX0RNQV9MRU5HVEg9eQpDT05GSUdfR0VORVJJQ19JU0FfRE1BPXkKQ09O
RklHX0dFTkVSSUNfQlVHPXkKQ09ORklHX0dFTkVSSUNfQlVHX1JFTEFUSVZFX1BPSU5URVJT
PXkKQ09ORklHX0dFTkVSSUNfSFdFSUdIVD15CkNPTkZJR19BUkNIX01BWV9IQVZFX1BDX0ZE
Qz15CiMgQ09ORklHX1JXU0VNX0dFTkVSSUNfU1BJTkxPQ0sgaXMgbm90IHNldApDT05GSUdf
UldTRU1fWENIR0FERF9BTEdPUklUSE09eQpDT05GSUdfQVJDSF9IQVNfQ1BVX0lETEVfV0FJ
VD15CkNPTkZJR19HRU5FUklDX0NBTElCUkFURV9ERUxBWT15CkNPTkZJR19HRU5FUklDX1RJ
TUVfVlNZU0NBTEw9eQpDT05GSUdfQVJDSF9IQVNfQ1BVX1JFTEFYPXkKQ09ORklHX0FSQ0hf
SEFTX0RFRkFVTFRfSURMRT15CkNPTkZJR19BUkNIX0hBU19DQUNIRV9MSU5FX1NJWkU9eQpD
T05GSUdfSEFWRV9TRVRVUF9QRVJfQ1BVX0FSRUE9eQpDT05GSUdfTkVFRF9QRVJfQ1BVX0VN
QkVEX0ZJUlNUX0NIVU5LPXkKQ09ORklHX05FRURfUEVSX0NQVV9QQUdFX0ZJUlNUX0NIVU5L
PXkKQ09ORklHX0FSQ0hfSElCRVJOQVRJT05fUE9TU0lCTEU9eQpDT05GSUdfQVJDSF9TVVNQ
RU5EX1BPU1NJQkxFPXkKQ09ORklHX1pPTkVfRE1BMzI9eQpDT05GSUdfQVVESVRfQVJDSD15
CkNPTkZJR19BUkNIX1NVUFBPUlRTX09QVElNSVpFRF9JTkxJTklORz15CkNPTkZJR19BUkNI
X1NVUFBPUlRTX0RFQlVHX1BBR0VBTExPQz15CkNPTkZJR19BUkNIX0hXRUlHSFRfQ0ZMQUdT
PSItZmNhbGwtc2F2ZWQtcmRpIC1mY2FsbC1zYXZlZC1yc2kgLWZjYWxsLXNhdmVkLXJkeCAt
ZmNhbGwtc2F2ZWQtcmN4IC1mY2FsbC1zYXZlZC1yOCAtZmNhbGwtc2F2ZWQtcjkgLWZjYWxs
LXNhdmVkLXIxMCAtZmNhbGwtc2F2ZWQtcjExIgojIENPTkZJR19LVElNRV9TQ0FMQVIgaXMg
bm90IHNldApDT05GSUdfQVJDSF9TVVBQT1JUU19VUFJPQkVTPXkKQ09ORklHX0RFRkNPTkZJ
R19MSVNUPSIvbGliL21vZHVsZXMvJFVOQU1FX1JFTEVBU0UvLmNvbmZpZyIKQ09ORklHX0hB
VkVfSVJRX1dPUks9eQpDT05GSUdfSVJRX1dPUks9eQoKIwojIEdlbmVyYWwgc2V0dXAKIwoj
IENPTkZJR19FWFBFUklNRU5UQUwgaXMgbm90IHNldApDT05GSUdfQlJPS0VOX09OX1NNUD15
CkNPTkZJR19JTklUX0VOVl9BUkdfTElNSVQ9MzIKQ09ORklHX0NST1NTX0NPTVBJTEU9IiIK
Q09ORklHX0xPQ0FMVkVSU0lPTj0iIgpDT05GSUdfTE9DQUxWRVJTSU9OX0FVVE89eQpDT05G
SUdfSEFWRV9LRVJORUxfR1pJUD15CkNPTkZJR19IQVZFX0tFUk5FTF9CWklQMj15CkNPTkZJ
R19IQVZFX0tFUk5FTF9MWk1BPXkKQ09ORklHX0hBVkVfS0VSTkVMX1haPXkKQ09ORklHX0hB
VkVfS0VSTkVMX0xaTz15CiMgQ09ORklHX0tFUk5FTF9HWklQIGlzIG5vdCBzZXQKIyBDT05G
SUdfS0VSTkVMX0JaSVAyIGlzIG5vdCBzZXQKIyBDT05GSUdfS0VSTkVMX0xaTUEgaXMgbm90
IHNldAojIENPTkZJR19LRVJORUxfWFogaXMgbm90IHNldApDT05GSUdfS0VSTkVMX0xaTz15
CkNPTkZJR19ERUZBVUxUX0hPU1ROQU1FPSIobm9uZSkiCiMgQ09ORklHX1NXQVAgaXMgbm90
IHNldApDT05GSUdfU1lTVklQQz15CkNPTkZJR19TWVNWSVBDX1NZU0NUTD15CiMgQ09ORklH
X0JTRF9QUk9DRVNTX0FDQ1QgaXMgbm90IHNldApDT05GSUdfRkhBTkRMRT15CiMgQ09ORklH
X1RBU0tTVEFUUyBpcyBub3Qgc2V0CkNPTkZJR19BVURJVD15CkNPTkZJR19BVURJVFNZU0NB
TEw9eQpDT05GSUdfQVVESVRfV0FUQ0g9eQpDT05GSUdfQVVESVRfVFJFRT15CkNPTkZJR19I
QVZFX0dFTkVSSUNfSEFSRElSUVM9eQoKIwojIElSUSBzdWJzeXN0ZW0KIwpDT05GSUdfR0VO
RVJJQ19IQVJESVJRUz15CkNPTkZJR19IQVZFX1NQQVJTRV9JUlE9eQpDT05GSUdfR0VORVJJ
Q19JUlFfUFJPQkU9eQpDT05GSUdfR0VORVJJQ19JUlFfU0hPVz15CkNPTkZJR19JUlFfRk9S
Q0VEX1RIUkVBRElORz15CkNPTkZJR19TUEFSU0VfSVJRPXkKCiMKIyBSQ1UgU3Vic3lzdGVt
CiMKQ09ORklHX1RJTllfUFJFRU1QVF9SQ1U9eQpDT05GSUdfUFJFRU1QVF9SQ1U9eQpDT05G
SUdfUkNVX1RSQUNFPXkKIyBDT05GSUdfVFJFRV9SQ1VfVFJBQ0UgaXMgbm90IHNldApDT05G
SUdfUkNVX0JPT1NUPXkKQ09ORklHX1JDVV9CT09TVF9QUklPPTEKQ09ORklHX1JDVV9CT09T
VF9ERUxBWT01MDAKIyBDT05GSUdfSUtDT05GSUcgaXMgbm90IHNldApDT05GSUdfTE9HX0JV
Rl9TSElGVD0xNwpDT05GSUdfSEFWRV9VTlNUQUJMRV9TQ0hFRF9DTE9DSz15CkNPTkZJR19D
R1JPVVBTPXkKQ09ORklHX0NHUk9VUF9ERUJVRz15CkNPTkZJR19DR1JPVVBfRlJFRVpFUj15
CiMgQ09ORklHX0NHUk9VUF9ERVZJQ0UgaXMgbm90IHNldApDT05GSUdfQ1BVU0VUUz15CiMg
Q09ORklHX1BST0NfUElEX0NQVVNFVCBpcyBub3Qgc2V0CkNPTkZJR19DR1JPVVBfQ1BVQUND
VD15CkNPTkZJR19SRVNPVVJDRV9DT1VOVEVSUz15CiMgQ09ORklHX0NHUk9VUF9NRU1fUkVT
X0NUTFIgaXMgbm90IHNldApDT05GSUdfQ0dST1VQX1BFUkY9eQpDT05GSUdfQ0dST1VQX1ND
SEVEPXkKQ09ORklHX0ZBSVJfR1JPVVBfU0NIRUQ9eQojIENPTkZJR19CTEtfQ0dST1VQIGlz
IG5vdCBzZXQKIyBDT05GSUdfQ0hFQ0tQT0lOVF9SRVNUT1JFIGlzIG5vdCBzZXQKQ09ORklH
X05BTUVTUEFDRVM9eQpDT05GSUdfVVRTX05TPXkKQ09ORklHX0lQQ19OUz15CiMgQ09ORklH
X1BJRF9OUyBpcyBub3Qgc2V0CiMgQ09ORklHX05FVF9OUyBpcyBub3Qgc2V0CkNPTkZJR19T
Q0hFRF9BVVRPR1JPVVA9eQojIENPTkZJR19TWVNGU19ERVBSRUNBVEVEIGlzIG5vdCBzZXQK
Q09ORklHX1JFTEFZPXkKQ09ORklHX0JMS19ERVZfSU5JVFJEPXkKQ09ORklHX0lOSVRSQU1G
U19TT1VSQ0U9IiIKQ09ORklHX1JEX0daSVA9eQpDT05GSUdfUkRfQlpJUDI9eQpDT05GSUdf
UkRfTFpNQT15CkNPTkZJR19SRF9YWj15CkNPTkZJR19SRF9MWk89eQpDT05GSUdfQ0NfT1BU
SU1JWkVfRk9SX1NJWkU9eQpDT05GSUdfU1lTQ1RMPXkKQ09ORklHX0FOT05fSU5PREVTPXkK
IyBDT05GSUdfRVhQRVJUIGlzIG5vdCBzZXQKQ09ORklHX1VJRDE2PXkKIyBDT05GSUdfU1lT
Q1RMX1NZU0NBTEwgaXMgbm90IHNldApDT05GSUdfS0FMTFNZTVM9eQpDT05GSUdfS0FMTFNZ
TVNfQUxMPXkKQ09ORklHX0hPVFBMVUc9eQpDT05GSUdfUFJJTlRLPXkKQ09ORklHX0JVRz15
CkNPTkZJR19FTEZfQ09SRT15CkNPTkZJR19QQ1NQS1JfUExBVEZPUk09eQpDT05GSUdfSEFW
RV9QQ1NQS1JfUExBVEZPUk09eQpDT05GSUdfQkFTRV9GVUxMPXkKQ09ORklHX0ZVVEVYPXkK
Q09ORklHX0VQT0xMPXkKQ09ORklHX1NJR05BTEZEPXkKQ09ORklHX1RJTUVSRkQ9eQpDT05G
SUdfRVZFTlRGRD15CkNPTkZJR19TSE1FTT15CkNPTkZJR19BSU89eQojIENPTkZJR19FTUJF
RERFRCBpcyBub3Qgc2V0CkNPTkZJR19IQVZFX1BFUkZfRVZFTlRTPXkKCiMKIyBLZXJuZWwg
UGVyZm9ybWFuY2UgRXZlbnRzIEFuZCBDb3VudGVycwojCkNPTkZJR19QRVJGX0VWRU5UUz15
CiMgQ09ORklHX1BFUkZfQ09VTlRFUlMgaXMgbm90IHNldAojIENPTkZJR19ERUJVR19QRVJG
X1VTRV9WTUFMTE9DIGlzIG5vdCBzZXQKQ09ORklHX1ZNX0VWRU5UX0NPVU5URVJTPXkKQ09O
RklHX1NMVUJfREVCVUc9eQpDT05GSUdfQ09NUEFUX0JSSz15CiMgQ09ORklHX1NMQUIgaXMg
bm90IHNldApDT05GSUdfU0xVQj15CkNPTkZJR19QUk9GSUxJTkc9eQpDT05GSUdfVFJBQ0VQ
T0lOVFM9eQpDT05GSUdfT1BST0ZJTEU9bQojIENPTkZJR19PUFJPRklMRV9FVkVOVF9NVUxU
SVBMRVggaXMgbm90IHNldApDT05GSUdfSEFWRV9PUFJPRklMRT15CkNPTkZJR19PUFJPRklM
RV9OTUlfVElNRVI9eQojIENPTkZJR19LUFJPQkVTIGlzIG5vdCBzZXQKQ09ORklHX0pVTVBf
TEFCRUw9eQojIENPTkZJR19VUFJPQkVTIGlzIG5vdCBzZXQKQ09ORklHX0hBVkVfRUZGSUNJ
RU5UX1VOQUxJR05FRF9BQ0NFU1M9eQpDT05GSUdfSEFWRV9JT1JFTUFQX1BST1Q9eQpDT05G
SUdfSEFWRV9LUFJPQkVTPXkKQ09ORklHX0hBVkVfS1JFVFBST0JFUz15CkNPTkZJR19IQVZF
X09QVFBST0JFUz15CkNPTkZJR19IQVZFX0FSQ0hfVFJBQ0VIT09LPXkKQ09ORklHX0hBVkVf
RE1BX0FUVFJTPXkKQ09ORklHX0hBVkVfUkVHU19BTkRfU1RBQ0tfQUNDRVNTX0FQST15CkNP
TkZJR19IQVZFX0RNQV9BUElfREVCVUc9eQpDT05GSUdfSEFWRV9IV19CUkVBS1BPSU5UPXkK
Q09ORklHX0hBVkVfTUlYRURfQlJFQUtQT0lOVFNfUkVHUz15CkNPTkZJR19IQVZFX1VTRVJf
UkVUVVJOX05PVElGSUVSPXkKQ09ORklHX0hBVkVfUEVSRl9FVkVOVFNfTk1JPXkKQ09ORklH
X0hBVkVfQVJDSF9KVU1QX0xBQkVMPXkKQ09ORklHX0FSQ0hfSEFWRV9OTUlfU0FGRV9DTVBY
Q0hHPXkKQ09ORklHX0hBVkVfQUxJR05FRF9TVFJVQ1RfUEFHRT15CkNPTkZJR19IQVZFX0NN
UFhDSEdfTE9DQUw9eQpDT05GSUdfSEFWRV9DTVBYQ0hHX0RPVUJMRT15CgojCiMgR0NPVi1i
YXNlZCBrZXJuZWwgcHJvZmlsaW5nCiMKIyBDT05GSUdfR0NPVl9LRVJORUwgaXMgbm90IHNl
dAojIENPTkZJR19IQVZFX0dFTkVSSUNfRE1BX0NPSEVSRU5UIGlzIG5vdCBzZXQKQ09ORklH
X1NMQUJJTkZPPXkKQ09ORklHX1JUX01VVEVYRVM9eQpDT05GSUdfQkFTRV9TTUFMTD0wCkNP
TkZJR19NT0RVTEVTPXkKIyBDT05GSUdfTU9EVUxFX0ZPUkNFX0xPQUQgaXMgbm90IHNldAoj
IENPTkZJR19NT0RVTEVfVU5MT0FEIGlzIG5vdCBzZXQKQ09ORklHX01PRFZFUlNJT05TPXkK
IyBDT05GSUdfTU9EVUxFX1NSQ1ZFUlNJT05fQUxMIGlzIG5vdCBzZXQKQ09ORklHX0JMT0NL
PXkKQ09ORklHX0JMS19ERVZfQlNHPXkKQ09ORklHX0JMS19ERVZfQlNHTElCPXkKIyBDT05G
SUdfQkxLX0RFVl9JTlRFR1JJVFkgaXMgbm90IHNldApDT05GSUdfQkxPQ0tfQ09NUEFUPXkK
CiMKIyBJTyBTY2hlZHVsZXJzCiMKQ09ORklHX0lPU0NIRURfTk9PUD15CiMgQ09ORklHX0lP
U0NIRURfREVBRExJTkUgaXMgbm90IHNldAojIENPTkZJR19JT1NDSEVEX0NGUSBpcyBub3Qg
c2V0CkNPTkZJR19ERUZBVUxUX05PT1A9eQpDT05GSUdfREVGQVVMVF9JT1NDSEVEPSJub29w
IgojIENPTkZJR19JTkxJTkVfU1BJTl9UUllMT0NLIGlzIG5vdCBzZXQKIyBDT05GSUdfSU5M
SU5FX1NQSU5fVFJZTE9DS19CSCBpcyBub3Qgc2V0CiMgQ09ORklHX0lOTElORV9TUElOX0xP
Q0sgaXMgbm90IHNldAojIENPTkZJR19JTkxJTkVfU1BJTl9MT0NLX0JIIGlzIG5vdCBzZXQK
IyBDT05GSUdfSU5MSU5FX1NQSU5fTE9DS19JUlEgaXMgbm90IHNldAojIENPTkZJR19JTkxJ
TkVfU1BJTl9MT0NLX0lSUVNBVkUgaXMgbm90IHNldAojIENPTkZJR19JTkxJTkVfU1BJTl9V
TkxPQ0sgaXMgbm90IHNldAojIENPTkZJR19JTkxJTkVfU1BJTl9VTkxPQ0tfQkggaXMgbm90
IHNldAojIENPTkZJR19JTkxJTkVfU1BJTl9VTkxPQ0tfSVJRIGlzIG5vdCBzZXQKIyBDT05G
SUdfSU5MSU5FX1NQSU5fVU5MT0NLX0lSUVJFU1RPUkUgaXMgbm90IHNldAojIENPTkZJR19J
TkxJTkVfUkVBRF9UUllMT0NLIGlzIG5vdCBzZXQKIyBDT05GSUdfSU5MSU5FX1JFQURfTE9D
SyBpcyBub3Qgc2V0CiMgQ09ORklHX0lOTElORV9SRUFEX0xPQ0tfQkggaXMgbm90IHNldAoj
IENPTkZJR19JTkxJTkVfUkVBRF9MT0NLX0lSUSBpcyBub3Qgc2V0CiMgQ09ORklHX0lOTElO
RV9SRUFEX0xPQ0tfSVJRU0FWRSBpcyBub3Qgc2V0CiMgQ09ORklHX0lOTElORV9SRUFEX1VO
TE9DSyBpcyBub3Qgc2V0CiMgQ09ORklHX0lOTElORV9SRUFEX1VOTE9DS19CSCBpcyBub3Qg
c2V0CiMgQ09ORklHX0lOTElORV9SRUFEX1VOTE9DS19JUlEgaXMgbm90IHNldAojIENPTkZJ
R19JTkxJTkVfUkVBRF9VTkxPQ0tfSVJRUkVTVE9SRSBpcyBub3Qgc2V0CiMgQ09ORklHX0lO
TElORV9XUklURV9UUllMT0NLIGlzIG5vdCBzZXQKIyBDT05GSUdfSU5MSU5FX1dSSVRFX0xP
Q0sgaXMgbm90IHNldAojIENPTkZJR19JTkxJTkVfV1JJVEVfTE9DS19CSCBpcyBub3Qgc2V0
CiMgQ09ORklHX0lOTElORV9XUklURV9MT0NLX0lSUSBpcyBub3Qgc2V0CiMgQ09ORklHX0lO
TElORV9XUklURV9MT0NLX0lSUVNBVkUgaXMgbm90IHNldAojIENPTkZJR19JTkxJTkVfV1JJ
VEVfVU5MT0NLIGlzIG5vdCBzZXQKIyBDT05GSUdfSU5MSU5FX1dSSVRFX1VOTE9DS19CSCBp
cyBub3Qgc2V0CiMgQ09ORklHX0lOTElORV9XUklURV9VTkxPQ0tfSVJRIGlzIG5vdCBzZXQK
IyBDT05GSUdfSU5MSU5FX1dSSVRFX1VOTE9DS19JUlFSRVNUT1JFIGlzIG5vdCBzZXQKIyBD
T05GSUdfTVVURVhfU1BJTl9PTl9PV05FUiBpcyBub3Qgc2V0CkNPTkZJR19GUkVFWkVSPXkK
CiMKIyBQcm9jZXNzb3IgdHlwZSBhbmQgZmVhdHVyZXMKIwpDT05GSUdfVElDS19PTkVTSE9U
PXkKQ09ORklHX05PX0haPXkKQ09ORklHX0hJR0hfUkVTX1RJTUVSUz15CkNPTkZJR19HRU5F
UklDX0NMT0NLRVZFTlRTX0JVSUxEPXkKQ09ORklHX0dFTkVSSUNfQ0xPQ0tFVkVOVFNfTUlO
X0FESlVTVD15CiMgQ09ORklHX1NNUCBpcyBub3Qgc2V0CkNPTkZJR19YODZfTVBQQVJTRT15
CiMgQ09ORklHX1g4Nl9FWFRFTkRFRF9QTEFURk9STSBpcyBub3Qgc2V0CiMgQ09ORklHX1ND
SEVEX09NSVRfRlJBTUVfUE9JTlRFUiBpcyBub3Qgc2V0CiMgQ09ORklHX0tWTVRPT0xfVEVT
VF9FTkFCTEUgaXMgbm90IHNldApDT05GSUdfUEFSQVZJUlRfR1VFU1Q9eQpDT05GSUdfUEFS
QVZJUlRfVElNRV9BQ0NPVU5USU5HPXkKQ09ORklHX1hFTj15CiMgQ09ORklHX1hFTl9QUklW
SUxFR0VEX0dVRVNUIGlzIG5vdCBzZXQKQ09ORklHX1hFTl9NQVhfRE9NQUlOX01FTU9SWT01
MDAKQ09ORklHX1hFTl9TQVZFX1JFU1RPUkU9eQojIENPTkZJR19YRU5fREVCVUdfRlMgaXMg
bm90IHNldApDT05GSUdfS1ZNX0NMT0NLPXkKIyBDT05GSUdfS1ZNX0dVRVNUIGlzIG5vdCBz
ZXQKQ09ORklHX1BBUkFWSVJUPXkKQ09ORklHX1BBUkFWSVJUX0NMT0NLPXkKQ09ORklHX1BB
UkFWSVJUX0RFQlVHPXkKQ09ORklHX05PX0JPT1RNRU09eQpDT05GSUdfTUVNVEVTVD15CiMg
Q09ORklHX01LOCBpcyBub3Qgc2V0CiMgQ09ORklHX01QU0MgaXMgbm90IHNldAojIENPTkZJ
R19NQ09SRTIgaXMgbm90IHNldAojIENPTkZJR19NQVRPTSBpcyBub3Qgc2V0CkNPTkZJR19H
RU5FUklDX0NQVT15CkNPTkZJR19YODZfSU5URVJOT0RFX0NBQ0hFX1NISUZUPTYKQ09ORklH
X1g4Nl9DTVBYQ0hHPXkKQ09ORklHX1g4Nl9MMV9DQUNIRV9TSElGVD02CkNPTkZJR19YODZf
WEFERD15CkNPTkZJR19YODZfV1BfV09SS1NfT0s9eQpDT05GSUdfWDg2X1RTQz15CkNPTkZJ
R19YODZfQ01QWENIRzY0PXkKQ09ORklHX1g4Nl9DTU9WPXkKQ09ORklHX1g4Nl9NSU5JTVVN
X0NQVV9GQU1JTFk9NjQKQ09ORklHX1g4Nl9ERUJVR0NUTE1TUj15CkNPTkZJR19DUFVfU1VQ
X0lOVEVMPXkKQ09ORklHX0NQVV9TVVBfQU1EPXkKQ09ORklHX0NQVV9TVVBfQ0VOVEFVUj15
CkNPTkZJR19IUEVUX1RJTUVSPXkKQ09ORklHX0RNST15CkNPTkZJR19TV0lPVExCPXkKQ09O
RklHX0lPTU1VX0hFTFBFUj15CkNPTkZJR19OUl9DUFVTPTEKIyBDT05GSUdfSVJRX1RJTUVf
QUNDT1VOVElORyBpcyBub3Qgc2V0CiMgQ09ORklHX1BSRUVNUFRfTk9ORSBpcyBub3Qgc2V0
CiMgQ09ORklHX1BSRUVNUFRfVk9MVU5UQVJZIGlzIG5vdCBzZXQKQ09ORklHX1BSRUVNUFQ9
eQpDT05GSUdfUFJFRU1QVF9DT1VOVD15CkNPTkZJR19YODZfTE9DQUxfQVBJQz15CkNPTkZJ
R19YODZfSU9fQVBJQz15CiMgQ09ORklHX1g4Nl9SRVJPVVRFX0ZPUl9CUk9LRU5fQk9PVF9J
UlFTIGlzIG5vdCBzZXQKIyBDT05GSUdfWDg2X01DRSBpcyBub3Qgc2V0CkNPTkZJR19JOEs9
bQpDT05GSUdfTUlDUk9DT0RFPW0KIyBDT05GSUdfTUlDUk9DT0RFX0lOVEVMIGlzIG5vdCBz
ZXQKIyBDT05GSUdfTUlDUk9DT0RFX0FNRCBpcyBub3Qgc2V0CkNPTkZJR19NSUNST0NPREVf
T0xEX0lOVEVSRkFDRT15CiMgQ09ORklHX1g4Nl9NU1IgaXMgbm90IHNldApDT05GSUdfWDg2
X0NQVUlEPW0KQ09ORklHX0FSQ0hfUEhZU19BRERSX1RfNjRCSVQ9eQpDT05GSUdfQVJDSF9E
TUFfQUREUl9UXzY0QklUPXkKQ09ORklHX0RJUkVDVF9HQlBBR0VTPXkKQ09ORklHX0FSQ0hf
U1BBUlNFTUVNX0VOQUJMRT15CkNPTkZJR19BUkNIX1NQQVJTRU1FTV9ERUZBVUxUPXkKQ09O
RklHX0FSQ0hfU0VMRUNUX01FTU9SWV9NT0RFTD15CkNPTkZJR19BUkNIX01FTU9SWV9QUk9C
RT15CkNPTkZJR19BUkNIX1BST0NfS0NPUkVfVEVYVD15CkNPTkZJR19JTExFR0FMX1BPSU5U
RVJfVkFMVUU9MHhkZWFkMDAwMDAwMDAwMDAwCkNPTkZJR19TRUxFQ1RfTUVNT1JZX01PREVM
PXkKQ09ORklHX1NQQVJTRU1FTV9NQU5VQUw9eQpDT05GSUdfU1BBUlNFTUVNPXkKQ09ORklH
X0hBVkVfTUVNT1JZX1BSRVNFTlQ9eQpDT05GSUdfU1BBUlNFTUVNX0VYVFJFTUU9eQpDT05G
SUdfU1BBUlNFTUVNX1ZNRU1NQVBfRU5BQkxFPXkKQ09ORklHX1NQQVJTRU1FTV9BTExPQ19N
RU1fTUFQX1RPR0VUSEVSPXkKIyBDT05GSUdfU1BBUlNFTUVNX1ZNRU1NQVAgaXMgbm90IHNl
dApDT05GSUdfSEFWRV9NRU1CTE9DSz15CkNPTkZJR19IQVZFX01FTUJMT0NLX05PREVfTUFQ
PXkKQ09ORklHX0FSQ0hfRElTQ0FSRF9NRU1CTE9DSz15CkNPTkZJR19NRU1PUllfSE9UUExV
Rz15CkNPTkZJR19NRU1PUllfSE9UUExVR19TUEFSU0U9eQojIENPTkZJR19NRU1PUllfSE9U
UkVNT1ZFIGlzIG5vdCBzZXQKQ09ORklHX1BBR0VGTEFHU19FWFRFTkRFRD15CkNPTkZJR19T
UExJVF9QVExPQ0tfQ1BVUz05OTk5OTkKQ09ORklHX0NPTVBBQ1RJT049eQpDT05GSUdfTUlH
UkFUSU9OPXkKQ09ORklHX1BIWVNfQUREUl9UXzY0QklUPXkKQ09ORklHX1pPTkVfRE1BX0ZM
QUc9MQpDT05GSUdfQk9VTkNFPXkKQ09ORklHX1ZJUlRfVE9fQlVTPXkKQ09ORklHX01NVV9O
T1RJRklFUj15CkNPTkZJR19LU009eQpDT05GSUdfREVGQVVMVF9NTUFQX01JTl9BRERSPTQw
OTYKIyBDT05GSUdfVFJBTlNQQVJFTlRfSFVHRVBBR0UgaXMgbm90IHNldApDT05GSUdfTkVF
RF9QRVJfQ1BVX0tNPXkKIyBDT05GSUdfQ0xFQU5DQUNIRSBpcyBub3Qgc2V0CkNPTkZJR19Y
ODZfQ0hFQ0tfQklPU19DT1JSVVBUSU9OPXkKIyBDT05GSUdfWDg2X0JPT1RQQVJBTV9NRU1P
UllfQ09SUlVQVElPTl9DSEVDSyBpcyBub3Qgc2V0CkNPTkZJR19YODZfUkVTRVJWRV9MT1c9
NjQKQ09ORklHX01UUlI9eQpDT05GSUdfTVRSUl9TQU5JVElaRVI9eQpDT05GSUdfTVRSUl9T
QU5JVElaRVJfRU5BQkxFX0RFRkFVTFQ9MApDT05GSUdfTVRSUl9TQU5JVElaRVJfU1BBUkVf
UkVHX05SX0RFRkFVTFQ9MQpDT05GSUdfWDg2X1BBVD15CkNPTkZJR19BUkNIX1VTRVNfUEdf
VU5DQUNIRUQ9eQpDT05GSUdfQVJDSF9SQU5ET009eQojIENPTkZJR19TRUNDT01QIGlzIG5v
dCBzZXQKQ09ORklHX0NDX1NUQUNLUFJPVEVDVE9SPXkKIyBDT05GSUdfSFpfMTAwIGlzIG5v
dCBzZXQKIyBDT05GSUdfSFpfMjUwIGlzIG5vdCBzZXQKIyBDT05GSUdfSFpfMzAwIGlzIG5v
dCBzZXQKQ09ORklHX0haXzEwMDA9eQpDT05GSUdfSFo9MTAwMApDT05GSUdfU0NIRURfSFJU
SUNLPXkKQ09ORklHX0tFWEVDPXkKQ09ORklHX0NSQVNIX0RVTVA9eQpDT05GSUdfUEhZU0lD
QUxfU1RBUlQ9MHgxMDAwMDAwCkNPTkZJR19SRUxPQ0FUQUJMRT15CkNPTkZJR19QSFlTSUNB
TF9BTElHTj0weDEwMDAwMDAKQ09ORklHX0NPTVBBVF9WRFNPPXkKIyBDT05GSUdfQ01ETElO
RV9CT09MIGlzIG5vdCBzZXQKQ09ORklHX0FSQ0hfRU5BQkxFX01FTU9SWV9IT1RQTFVHPXkK
Q09ORklHX0FSQ0hfRU5BQkxFX01FTU9SWV9IT1RSRU1PVkU9eQoKIwojIFBvd2VyIG1hbmFn
ZW1lbnQgYW5kIEFDUEkgb3B0aW9ucwojCkNPTkZJR19TVVNQRU5EPXkKQ09ORklHX1NVU1BF
TkRfRlJFRVpFUj15CkNPTkZJR19ISUJFUk5BVEVfQ0FMTEJBQ0tTPXkKQ09ORklHX1BNX1NM
RUVQPXkKQ09ORklHX1BNX1JVTlRJTUU9eQpDT05GSUdfUE09eQpDT05GSUdfUE1fREVCVUc9
eQpDT05GSUdfUE1fQURWQU5DRURfREVCVUc9eQpDT05GSUdfUE1fVEVTVF9TVVNQRU5EPXkK
Q09ORklHX0NBTl9QTV9UUkFDRT15CkNPTkZJR19QTV9UUkFDRT15CkNPTkZJR19QTV9UUkFD
RV9SVEM9eQpDT05GSUdfU0ZJPXkKCiMKIyBDUFUgRnJlcXVlbmN5IHNjYWxpbmcKIwojIENP
TkZJR19DUFVfRlJFUSBpcyBub3Qgc2V0CiMgQ09ORklHX0NQVV9JRExFIGlzIG5vdCBzZXQK
CiMKIyBNZW1vcnkgcG93ZXIgc2F2aW5ncwojCgojCiMgQnVzIG9wdGlvbnMgKFBDSSBldGMu
KQojCiMgQ09ORklHX1BDSSBpcyBub3Qgc2V0CiMgQ09ORklHX0FSQ0hfU1VQUE9SVFNfTVNJ
IGlzIG5vdCBzZXQKQ09ORklHX1BDSV9MQUJFTD15CkNPTkZJR19JU0FfRE1BX0FQST15CkNP
TkZJR19QQ0NBUkQ9bQojIENPTkZJR19QQ01DSUEgaXMgbm90IHNldAoKIwojIFBDLWNhcmQg
YnJpZGdlcwojCgojCiMgRXhlY3V0YWJsZSBmaWxlIGZvcm1hdHMgLyBFbXVsYXRpb25zCiMK
Q09ORklHX0JJTkZNVF9FTEY9eQpDT05GSUdfQ09NUEFUX0JJTkZNVF9FTEY9eQpDT05GSUdf
QVJDSF9CSU5GTVRfRUxGX1JBTkRPTUlaRV9QSUU9eQojIENPTkZJR19DT1JFX0RVTVBfREVG
QVVMVF9FTEZfSEVBREVSUyBpcyBub3Qgc2V0CiMgQ09ORklHX0hBVkVfQU9VVCBpcyBub3Qg
c2V0CiMgQ09ORklHX0JJTkZNVF9NSVNDIGlzIG5vdCBzZXQKQ09ORklHX0lBMzJfRU1VTEFU
SU9OPXkKIyBDT05GSUdfSUEzMl9BT1VUIGlzIG5vdCBzZXQKQ09ORklHX0NPTVBBVD15CkNP
TkZJR19DT01QQVRfRk9SX1U2NF9BTElHTk1FTlQ9eQpDT05GSUdfU1lTVklQQ19DT01QQVQ9
eQpDT05GSUdfS0VZU19DT01QQVQ9eQpDT05GSUdfSEFWRV9URVhUX1BPS0VfU01QPXkKQ09O
RklHX05FVD15CkNPTkZJR19DT01QQVRfTkVUTElOS19NRVNTQUdFUz15CgojCiMgTmV0d29y
a2luZyBvcHRpb25zCiMKQ09ORklHX1BBQ0tFVD1tCkNPTkZJR19VTklYPW0KQ09ORklHX1VO
SVhfRElBRz1tCiMgQ09ORklHX05FVF9LRVkgaXMgbm90IHNldAojIENPTkZJR19JTkVUIGlz
IG5vdCBzZXQKIyBDT05GSUdfTkVUV09SS19TRUNNQVJLIGlzIG5vdCBzZXQKQ09ORklHX05F
VEZJTFRFUj15CkNPTkZJR19ORVRGSUxURVJfREVCVUc9eQpDT05GSUdfTkVURklMVEVSX0FE
VkFOQ0VEPXkKQ09ORklHX0FUTT1tCiMgQ09ORklHX0FUTV9MQU5FIGlzIG5vdCBzZXQKIyBD
T05GSUdfQlJJREdFIGlzIG5vdCBzZXQKIyBDT05GSUdfVkxBTl84MDIxUSBpcyBub3Qgc2V0
CkNPTkZJR19ERUNORVQ9bQpDT05GSUdfTExDPW0KQ09ORklHX0xMQzI9bQpDT05GSUdfSVBY
PW0KQ09ORklHX0lQWF9JTlRFUk49eQpDT05GSUdfQVRBTEs9bQpDT05GSUdfREVWX0FQUExF
VEFMSz1tCkNPTkZJR19JUEREUD1tCiMgQ09ORklHX0lQRERQX0VOQ0FQIGlzIG5vdCBzZXQK
IyBDT05GSUdfSVBERFBfREVDQVAgaXMgbm90IHNldApDT05GSUdfUEhPTkVUPW0KIyBDT05G
SUdfTkVUX1NDSEVEIGlzIG5vdCBzZXQKIyBDT05GSUdfRENCIGlzIG5vdCBzZXQKQ09ORklH
X0ROU19SRVNPTFZFUj1tCkNPTkZJR19CQVRNQU5fQURWPW0KIyBDT05GSUdfQkFUTUFOX0FE
Vl9ERUJVRyBpcyBub3Qgc2V0CkNPTkZJR19PUEVOVlNXSVRDSD1tCkNPTkZJR19ORVRQUklP
X0NHUk9VUD1tCkNPTkZJR19CUUw9eQpDT05GSUdfSEFWRV9CUEZfSklUPXkKQ09ORklHX0JQ
Rl9KSVQ9eQoKIwojIE5ldHdvcmsgdGVzdGluZwojCkNPTkZJR19ORVRfUEtUR0VOPW0KIyBD
T05GSUdfSEFNUkFESU8gaXMgbm90IHNldApDT05GSUdfQ0FOPW0KIyBDT05GSUdfQ0FOX1JB
VyBpcyBub3Qgc2V0CiMgQ09ORklHX0NBTl9CQ00gaXMgbm90IHNldAojIENPTkZJR19DQU5f
R1cgaXMgbm90IHNldAoKIwojIENBTiBEZXZpY2UgRHJpdmVycwojCkNPTkZJR19DQU5fVkNB
Tj1tCiMgQ09ORklHX0NBTl9TTENBTiBpcyBub3Qgc2V0CkNPTkZJR19DQU5fREVWPW0KQ09O
RklHX0NBTl9DQUxDX0JJVFRJTUlORz15CiMgQ09ORklHX0NBTl9NQ1AyNTFYIGlzIG5vdCBz
ZXQKQ09ORklHX0NBTl9TSkExMDAwPW0KIyBDT05GSUdfQ0FOX1NKQTEwMDBfSVNBIGlzIG5v
dCBzZXQKQ09ORklHX0NBTl9TSkExMDAwX1BMQVRGT1JNPW0KQ09ORklHX0NBTl9DX0NBTj1t
CkNPTkZJR19DQU5fQ19DQU5fUExBVEZPUk09bQojIENPTkZJR19DQU5fQ0M3NzAgaXMgbm90
IHNldApDT05GSUdfQ0FOX1NPRlRJTkc9bQojIENPTkZJR19DQU5fREVCVUdfREVWSUNFUyBp
cyBub3Qgc2V0CkNPTkZJR19JUkRBPW0KCiMKIyBJckRBIHByb3RvY29scwojCiMgQ09ORklH
X0lSTEFOIGlzIG5vdCBzZXQKQ09ORklHX0lSQ09NTT1tCkNPTkZJR19JUkRBX1VMVFJBPXkK
CiMKIyBJckRBIG9wdGlvbnMKIwpDT05GSUdfSVJEQV9DQUNIRV9MQVNUX0xTQVA9eQojIENP
TkZJR19JUkRBX0ZBU1RfUlIgaXMgbm90IHNldAojIENPTkZJR19JUkRBX0RFQlVHIGlzIG5v
dCBzZXQKCiMKIyBJbmZyYXJlZC1wb3J0IGRldmljZSBkcml2ZXJzCiMKCiMKIyBTSVIgZGV2
aWNlIGRyaXZlcnMKIwpDT05GSUdfSVJUVFlfU0lSPW0KCiMKIyBEb25nbGUgc3VwcG9ydAoj
CkNPTkZJR19ET05HTEU9eQojIENPTkZJR19FU0lfRE9OR0xFIGlzIG5vdCBzZXQKQ09ORklH
X0FDVElTWVNfRE9OR0xFPW0KQ09ORklHX1RFS1JBTV9ET05HTEU9bQpDT05GSUdfVE9JTTMy
MzJfRE9OR0xFPW0KIyBDT05GSUdfTElURUxJTktfRE9OR0xFIGlzIG5vdCBzZXQKCiMKIyBG
SVIgZGV2aWNlIGRyaXZlcnMKIwpDT05GSUdfTlNDX0ZJUj1tCkNPTkZJR19XSU5CT05EX0ZJ
Uj1tCkNPTkZJR19WSUFfRklSPW0KIyBDT05GSUdfQlQgaXMgbm90IHNldApDT05GSUdfV0lS
RUxFU1M9eQpDT05GSUdfV0VYVF9DT1JFPXkKQ09ORklHX1dFWFRfUFJPQz15CkNPTkZJR19D
Rkc4MDIxMT1tCkNPTkZJR19OTDgwMjExX1RFU1RNT0RFPXkKIyBDT05GSUdfQ0ZHODAyMTFf
REVWRUxPUEVSX1dBUk5JTkdTIGlzIG5vdCBzZXQKIyBDT05GSUdfQ0ZHODAyMTFfUkVHX0RF
QlVHIGlzIG5vdCBzZXQKQ09ORklHX0NGRzgwMjExX0RFRkFVTFRfUFM9eQojIENPTkZJR19D
Rkc4MDIxMV9ERUJVR0ZTIGlzIG5vdCBzZXQKIyBDT05GSUdfQ0ZHODAyMTFfSU5URVJOQUxf
UkVHREIgaXMgbm90IHNldApDT05GSUdfQ0ZHODAyMTFfV0VYVD15CkNPTkZJR19XSVJFTEVT
U19FWFRfU1lTRlM9eQojIENPTkZJR19MSUI4MDIxMSBpcyBub3Qgc2V0CkNPTkZJR19NQUM4
MDIxMT1tCkNPTkZJR19NQUM4MDIxMV9IQVNfUkM9eQpDT05GSUdfTUFDODAyMTFfUkNfTUlO
U1RSRUw9eQpDT05GSUdfTUFDODAyMTFfUkNfTUlOU1RSRUxfSFQ9eQpDT05GSUdfTUFDODAy
MTFfUkNfREVGQVVMVF9NSU5TVFJFTD15CkNPTkZJR19NQUM4MDIxMV9SQ19ERUZBVUxUPSJt
aW5zdHJlbF9odCIKIyBDT05GSUdfTUFDODAyMTFfTEVEUyBpcyBub3Qgc2V0CkNPTkZJR19N
QUM4MDIxMV9ERUJVR0ZTPXkKQ09ORklHX01BQzgwMjExX0RFQlVHX01FTlU9eQojIENPTkZJ
R19NQUM4MDIxMV9OT0lOTElORSBpcyBub3Qgc2V0CiMgQ09ORklHX01BQzgwMjExX1ZFUkJP
U0VfREVCVUcgaXMgbm90IHNldApDT05GSUdfTUFDODAyMTFfSFRfREVCVUc9eQpDT05GSUdf
TUFDODAyMTFfVEtJUF9ERUJVRz15CkNPTkZJR19NQUM4MDIxMV9JQlNTX0RFQlVHPXkKIyBD
T05GSUdfTUFDODAyMTFfVkVSQk9TRV9QU19ERUJVRyBpcyBub3Qgc2V0CkNPTkZJR19NQUM4
MDIxMV9WRVJCT1NFX1RETFNfREVCVUc9eQojIENPTkZJR19NQUM4MDIxMV9ERUJVR19DT1VO
VEVSUyBpcyBub3Qgc2V0CiMgQ09ORklHX1dJTUFYIGlzIG5vdCBzZXQKIyBDT05GSUdfUkZL
SUxMIGlzIG5vdCBzZXQKQ09ORklHX05FVF85UD1tCkNPTkZJR19ORVRfOVBfVklSVElPPW0K
IyBDT05GSUdfTkVUXzlQX0RFQlVHIGlzIG5vdCBzZXQKIyBDT05GSUdfQ0FJRiBpcyBub3Qg
c2V0CgojCiMgRGV2aWNlIERyaXZlcnMKIwoKIwojIEdlbmVyaWMgRHJpdmVyIE9wdGlvbnMK
IwpDT05GSUdfVUVWRU5UX0hFTFBFUl9QQVRIPSIiCiMgQ09ORklHX0RFVlRNUEZTIGlzIG5v
dCBzZXQKQ09ORklHX1NUQU5EQUxPTkU9eQpDT05GSUdfUFJFVkVOVF9GSVJNV0FSRV9CVUlM
RD15CkNPTkZJR19GV19MT0FERVI9eQpDT05GSUdfRklSTVdBUkVfSU5fS0VSTkVMPXkKQ09O
RklHX0VYVFJBX0ZJUk1XQVJFPSIiCiMgQ09ORklHX0RFQlVHX0RSSVZFUiBpcyBub3Qgc2V0
CkNPTkZJR19ERUJVR19ERVZSRVM9eQpDT05GSUdfU1lTX0hZUEVSVklTT1I9eQpDT05GSUdf
UkVHTUFQPXkKQ09ORklHX1JFR01BUF9TUEk9eQojIENPTkZJR19DT05ORUNUT1IgaXMgbm90
IHNldApDT05GSUdfTVREPW0KQ09ORklHX01URF9URVNUUz1tCiMgQ09ORklHX01URF9SRURC
T09UX1BBUlRTIGlzIG5vdCBzZXQKQ09ORklHX01URF9BUjdfUEFSVFM9bQoKIwojIFVzZXIg
TW9kdWxlcyBBbmQgVHJhbnNsYXRpb24gTGF5ZXJzCiMKQ09ORklHX01URF9DSEFSPW0KQ09O
RklHX0hBVkVfTVREX09UUD15CkNPTkZJR19NVERfQkxLREVWUz1tCkNPTkZJR19NVERfQkxP
Q0s9bQojIENPTkZJR19NVERfQkxPQ0tfUk8gaXMgbm90IHNldApDT05GSUdfRlRMPW0KIyBD
T05GSUdfTkZUTCBpcyBub3Qgc2V0CiMgQ09ORklHX0lORlRMIGlzIG5vdCBzZXQKIyBDT05G
SUdfUkZEX0ZUTCBpcyBub3Qgc2V0CkNPTkZJR19TU0ZEQz1tCiMgQ09ORklHX01URF9PT1BT
IGlzIG5vdCBzZXQKCiMKIyBSQU0vUk9NL0ZsYXNoIGNoaXAgZHJpdmVycwojCkNPTkZJR19N
VERfQ0ZJPW0KQ09ORklHX01URF9KRURFQ1BST0JFPW0KQ09ORklHX01URF9HRU5fUFJPQkU9
bQojIENPTkZJR19NVERfQ0ZJX0FEVl9PUFRJT05TIGlzIG5vdCBzZXQKQ09ORklHX01URF9N
QVBfQkFOS19XSURUSF8xPXkKQ09ORklHX01URF9NQVBfQkFOS19XSURUSF8yPXkKQ09ORklH
X01URF9NQVBfQkFOS19XSURUSF80PXkKIyBDT05GSUdfTVREX01BUF9CQU5LX1dJRFRIXzgg
aXMgbm90IHNldAojIENPTkZJR19NVERfTUFQX0JBTktfV0lEVEhfMTYgaXMgbm90IHNldAoj
IENPTkZJR19NVERfTUFQX0JBTktfV0lEVEhfMzIgaXMgbm90IHNldApDT05GSUdfTVREX0NG
SV9JMT15CkNPTkZJR19NVERfQ0ZJX0kyPXkKIyBDT05GSUdfTVREX0NGSV9JNCBpcyBub3Qg
c2V0CiMgQ09ORklHX01URF9DRklfSTggaXMgbm90IHNldAojIENPTkZJR19NVERfQ0ZJX0lO
VEVMRVhUIGlzIG5vdCBzZXQKQ09ORklHX01URF9DRklfQU1EU1REPW0KQ09ORklHX01URF9D
RklfU1RBQT1tCkNPTkZJR19NVERfQ0ZJX1VUSUw9bQojIENPTkZJR19NVERfUkFNIGlzIG5v
dCBzZXQKIyBDT05GSUdfTVREX1JPTSBpcyBub3Qgc2V0CiMgQ09ORklHX01URF9BQlNFTlQg
aXMgbm90IHNldAoKIwojIE1hcHBpbmcgZHJpdmVycyBmb3IgY2hpcCBhY2Nlc3MKIwpDT05G
SUdfTVREX0NPTVBMRVhfTUFQUElOR1M9eQojIENPTkZJR19NVERfUEhZU01BUCBpcyBub3Qg
c2V0CkNPTkZJR19NVERfU0M1MjBDRFA9bQojIENPTkZJR19NVERfTkVUU0M1MjAgaXMgbm90
IHNldApDT05GSUdfTVREX1RTNTUwMD1tCiMgQ09ORklHX01URF9BTUQ3NlhST00gaXMgbm90
IHNldAojIENPTkZJR19NVERfSUNIWFJPTSBpcyBub3Qgc2V0CkNPTkZJR19NVERfU0NCMl9G
TEFTSD1tCkNPTkZJR19NVERfTkVUdGVsPW0KQ09ORklHX01URF9MNDQwR1g9bQojIENPTkZJ
R19NVERfUExBVFJBTSBpcyBub3Qgc2V0CkNPTkZJR19NVERfTEFUQ0hfQUREUj1tCgojCiMg
U2VsZi1jb250YWluZWQgTVREIGRldmljZSBkcml2ZXJzCiMKQ09ORklHX01URF9TU1QyNUw9
bQpDT05GSUdfTVREX1NMUkFNPW0KQ09ORklHX01URF9QSFJBTT1tCkNPTkZJR19NVERfTVRE
UkFNPW0KQ09ORklHX01URFJBTV9UT1RBTF9TSVpFPTQwOTYKQ09ORklHX01URFJBTV9FUkFT
RV9TSVpFPTEyOApDT05GSUdfTVREX0JMT0NLMk1URD1tCgojCiMgRGlzay1Pbi1DaGlwIERl
dmljZSBEcml2ZXJzCiMKIyBDT05GSUdfTVREX0RPQzIwMDAgaXMgbm90IHNldAojIENPTkZJ
R19NVERfRE9DMjAwMSBpcyBub3Qgc2V0CkNPTkZJR19NVERfRE9DMjAwMVBMVVM9bQojIENP
TkZJR19NVERfRE9DRzMgaXMgbm90IHNldApDT05GSUdfTVREX0RPQ1BST0JFPW0KQ09ORklH
X01URF9ET0NFQ0M9bQojIENPTkZJR19NVERfRE9DUFJPQkVfQURWQU5DRUQgaXMgbm90IHNl
dApDT05GSUdfTVREX0RPQ1BST0JFX0FERFJFU1M9MHgwCkNPTkZJR19NVERfTkFORF9FQ0M9
bQpDT05GSUdfTVREX05BTkRfRUNDX1NNQz15CkNPTkZJR19NVERfTkFORD1tCiMgQ09ORklH
X01URF9OQU5EX1ZFUklGWV9XUklURSBpcyBub3Qgc2V0CkNPTkZJR19NVERfTkFORF9CQ0g9
bQpDT05GSUdfTVREX05BTkRfRUNDX0JDSD15CiMgQ09ORklHX01URF9TTV9DT01NT04gaXMg
bm90IHNldAojIENPTkZJR19NVERfTkFORF9NVVNFVU1fSURTIGlzIG5vdCBzZXQKQ09ORklH
X01URF9OQU5EX0lEUz1tCiMgQ09ORklHX01URF9OQU5EX05BTkRTSU0gaXMgbm90IHNldApD
T05GSUdfTVREX05BTkRfUExBVEZPUk09bQpDT05GSUdfTVREX09ORU5BTkQ9bQpDT05GSUdf
TVREX09ORU5BTkRfVkVSSUZZX1dSSVRFPXkKQ09ORklHX01URF9PTkVOQU5EX0dFTkVSSUM9
bQpDT05GSUdfTVREX09ORU5BTkRfT1RQPXkKIyBDT05GSUdfTVREX09ORU5BTkRfMlhfUFJP
R1JBTSBpcyBub3Qgc2V0CiMgQ09ORklHX01URF9PTkVOQU5EX1NJTSBpcyBub3Qgc2V0Cgoj
CiMgTFBERFIgZmxhc2ggbWVtb3J5IGRyaXZlcnMKIwojIENPTkZJR19NVERfTFBERFIgaXMg
bm90IHNldApDT05GSUdfTVREX1VCST1tCkNPTkZJR19NVERfVUJJX1dMX1RIUkVTSE9MRD00
MDk2CkNPTkZJR19NVERfVUJJX0JFQl9SRVNFUlZFPTEKQ09ORklHX01URF9VQklfR0xVRUJJ
PW0KIyBDT05GSUdfTVREX1VCSV9ERUJVRyBpcyBub3Qgc2V0CiMgQ09ORklHX1BBUlBPUlQg
aXMgbm90IHNldApDT05GSUdfQkxLX0RFVj15CkNPTkZJR19CTEtfREVWX0ZEPW0KIyBDT05G
SUdfQkxLX0RFVl9DT1dfQ09NTU9OIGlzIG5vdCBzZXQKQ09ORklHX0JMS19ERVZfTE9PUD1t
CkNPTkZJR19CTEtfREVWX0xPT1BfTUlOX0NPVU5UPTgKIyBDT05GSUdfQkxLX0RFVl9DUllQ
VE9MT09QIGlzIG5vdCBzZXQKCiMKIyBEUkJEIGRpc2FibGVkIGJlY2F1c2UgUFJPQ19GUywg
SU5FVCBvciBDT05ORUNUT1Igbm90IHNlbGVjdGVkCiMKQ09ORklHX0JMS19ERVZfTkJEPW0K
Q09ORklHX0JMS19ERVZfUkFNPW0KQ09ORklHX0JMS19ERVZfUkFNX0NPVU5UPTE2CkNPTkZJ
R19CTEtfREVWX1JBTV9TSVpFPTQwOTYKIyBDT05GSUdfQkxLX0RFVl9YSVAgaXMgbm90IHNl
dAojIENPTkZJR19DRFJPTV9QS1RDRFZEIGlzIG5vdCBzZXQKQ09ORklHX0FUQV9PVkVSX0VU
SD1tCkNPTkZJR19YRU5fQkxLREVWX0ZST05URU5EPW0KIyBDT05GSUdfQkxLX0RFVl9IRCBp
cyBub3Qgc2V0CiMgQ09ORklHX1NFTlNPUlNfTElTM0xWMDJEIGlzIG5vdCBzZXQKIyBDT05G
SUdfTUlTQ19ERVZJQ0VTIGlzIG5vdCBzZXQKQ09ORklHX0hBVkVfSURFPXkKIyBDT05GSUdf
SURFIGlzIG5vdCBzZXQKCiMKIyBTQ1NJIGRldmljZSBzdXBwb3J0CiMKQ09ORklHX1NDU0lf
TU9EPW0KQ09ORklHX1JBSURfQVRUUlM9bQpDT05GSUdfU0NTST1tCkNPTkZJR19TQ1NJX0RN
QT15CkNPTkZJR19TQ1NJX05FVExJTks9eQojIENPTkZJR19TQ1NJX1BST0NfRlMgaXMgbm90
IHNldAoKIwojIFNDU0kgc3VwcG9ydCB0eXBlIChkaXNrLCB0YXBlLCBDRC1ST00pCiMKQ09O
RklHX0JMS19ERVZfU0Q9bQpDT05GSUdfQ0hSX0RFVl9TVD1tCiMgQ09ORklHX0NIUl9ERVZf
T1NTVCBpcyBub3Qgc2V0CkNPTkZJR19CTEtfREVWX1NSPW0KQ09ORklHX0JMS19ERVZfU1Jf
VkVORE9SPXkKQ09ORklHX0NIUl9ERVZfU0c9bQpDT05GSUdfQ0hSX0RFVl9TQ0g9bQojIENP
TkZJR19TQ1NJX01VTFRJX0xVTiBpcyBub3Qgc2V0CiMgQ09ORklHX1NDU0lfQ09OU1RBTlRT
IGlzIG5vdCBzZXQKQ09ORklHX1NDU0lfTE9HR0lORz15CiMgQ09ORklHX1NDU0lfU0NBTl9B
U1lOQyBpcyBub3Qgc2V0CkNPTkZJR19TQ1NJX1dBSVRfU0NBTj1tCgojCiMgU0NTSSBUcmFu
c3BvcnRzCiMKQ09ORklHX1NDU0lfU1BJX0FUVFJTPW0KQ09ORklHX1NDU0lfRkNfQVRUUlM9
bQojIENPTkZJR19TQ1NJX0lTQ1NJX0FUVFJTIGlzIG5vdCBzZXQKQ09ORklHX1NDU0lfU0FT
X0FUVFJTPW0KQ09ORklHX1NDU0lfU0FTX0xJQlNBUz1tCkNPTkZJR19TQ1NJX1NBU19BVEE9
eQpDT05GSUdfU0NTSV9TQVNfSE9TVF9TTVA9eQojIENPTkZJR19TQ1NJX1NSUF9BVFRSUyBp
cyBub3Qgc2V0CiMgQ09ORklHX1NDU0lfTE9XTEVWRUwgaXMgbm90IHNldAojIENPTkZJR19T
Q1NJX0RIIGlzIG5vdCBzZXQKQ09ORklHX1NDU0lfT1NEX0lOSVRJQVRPUj1tCiMgQ09ORklH
X1NDU0lfT1NEX1VMRCBpcyBub3Qgc2V0CkNPTkZJR19TQ1NJX09TRF9EUFJJTlRfU0VOU0U9
MQojIENPTkZJR19TQ1NJX09TRF9ERUJVRyBpcyBub3Qgc2V0CkNPTkZJR19BVEE9bQojIENP
TkZJR19BVEFfTk9OU1RBTkRBUkQgaXMgbm90IHNldApDT05GSUdfQVRBX1ZFUkJPU0VfRVJS
T1I9eQpDT05GSUdfU0FUQV9QTVA9eQoKIwojIENvbnRyb2xsZXJzIHdpdGggbm9uLVNGRiBu
YXRpdmUgaW50ZXJmYWNlCiMKQ09ORklHX1NBVEFfQUhDSV9QTEFURk9STT1tCiMgQ09ORklH
X0FUQV9TRkYgaXMgbm90IHNldApDT05GSUdfTUQ9eQojIENPTkZJR19CTEtfREVWX01EIGlz
IG5vdCBzZXQKQ09ORklHX0JMS19ERVZfRE09bQpDT05GSUdfRE1fREVCVUc9eQpDT05GSUdf
RE1fQ1JZUFQ9bQpDT05GSUdfRE1fU05BUFNIT1Q9bQpDT05GSUdfRE1fTUlSUk9SPW0KIyBD
T05GSUdfRE1fWkVSTyBpcyBub3Qgc2V0CkNPTkZJR19ETV9NVUxUSVBBVEg9bQojIENPTkZJ
R19ETV9NVUxUSVBBVEhfUUwgaXMgbm90IHNldApDT05GSUdfRE1fTVVMVElQQVRIX1NUPW0K
Q09ORklHX1RBUkdFVF9DT1JFPW0KIyBDT05GSUdfVENNX0lCTE9DSyBpcyBub3Qgc2V0CiMg
Q09ORklHX1RDTV9GSUxFSU8gaXMgbm90IHNldApDT05GSUdfVENNX1BTQ1NJPW0KQ09ORklH
X0xPT1BCQUNLX1RBUkdFVD1tCkNPTkZJR19JU0NTSV9UQVJHRVQ9bQojIENPTkZJR19NQUNJ
TlRPU0hfRFJJVkVSUyBpcyBub3Qgc2V0CiMgQ09ORklHX05FVERFVklDRVMgaXMgbm90IHNl
dAojIENPTkZJR19JU0ROIGlzIG5vdCBzZXQKIyBDT05GSUdfUEhPTkUgaXMgbm90IHNldAoK
IwojIElucHV0IGRldmljZSBzdXBwb3J0CiMKQ09ORklHX0lOUFVUPXkKQ09ORklHX0lOUFVU
X0ZGX01FTUxFU1M9bQpDT05GSUdfSU5QVVRfUE9MTERFVj1tCkNPTkZJR19JTlBVVF9TUEFS
U0VLTUFQPW0KCiMKIyBVc2VybGFuZCBpbnRlcmZhY2VzCiMKQ09ORklHX0lOUFVUX01PVVNF
REVWPXkKQ09ORklHX0lOUFVUX01PVVNFREVWX1BTQVVYPXkKQ09ORklHX0lOUFVUX01PVVNF
REVWX1NDUkVFTl9YPTEwMjQKQ09ORklHX0lOUFVUX01PVVNFREVWX1NDUkVFTl9ZPTc2OAoj
IENPTkZJR19JTlBVVF9KT1lERVYgaXMgbm90IHNldApDT05GSUdfSU5QVVRfRVZERVY9bQoj
IENPTkZJR19JTlBVVF9FVkJVRyBpcyBub3Qgc2V0CgojCiMgSW5wdXQgRGV2aWNlIERyaXZl
cnMKIwpDT05GSUdfSU5QVVRfS0VZQk9BUkQ9eQpDT05GSUdfS0VZQk9BUkRfQVRLQkQ9eQpD
T05GSUdfS0VZQk9BUkRfTEtLQkQ9bQpDT05GSUdfS0VZQk9BUkRfTkVXVE9OPW0KQ09ORklH
X0tFWUJPQVJEX09QRU5DT1JFUz1tCiMgQ09ORklHX0tFWUJPQVJEX1NUT1dBV0FZIGlzIG5v
dCBzZXQKIyBDT05GSUdfS0VZQk9BUkRfU1VOS0JEIGlzIG5vdCBzZXQKQ09ORklHX0tFWUJP
QVJEX1hUS0JEPW0KIyBDT05GSUdfSU5QVVRfTU9VU0UgaXMgbm90IHNldApDT05GSUdfSU5Q
VVRfSk9ZU1RJQ0s9eQpDT05GSUdfSk9ZU1RJQ0tfQU5BTE9HPW0KIyBDT05GSUdfSk9ZU1RJ
Q0tfQTNEIGlzIG5vdCBzZXQKIyBDT05GSUdfSk9ZU1RJQ0tfQURJIGlzIG5vdCBzZXQKIyBD
T05GSUdfSk9ZU1RJQ0tfQ09CUkEgaXMgbm90IHNldAojIENPTkZJR19KT1lTVElDS19HRjJL
IGlzIG5vdCBzZXQKIyBDT05GSUdfSk9ZU1RJQ0tfR1JJUCBpcyBub3Qgc2V0CiMgQ09ORklH
X0pPWVNUSUNLX0dSSVBfTVAgaXMgbm90IHNldApDT05GSUdfSk9ZU1RJQ0tfR1VJTExFTU9U
PW0KQ09ORklHX0pPWVNUSUNLX0lOVEVSQUNUPW0KIyBDT05GSUdfSk9ZU1RJQ0tfU0lERVdJ
TkRFUiBpcyBub3Qgc2V0CkNPTkZJR19KT1lTVElDS19UTURDPW0KQ09ORklHX0pPWVNUSUNL
X0lGT1JDRT1tCkNPTkZJR19KT1lTVElDS19JRk9SQ0VfMjMyPXkKIyBDT05GSUdfSk9ZU1RJ
Q0tfV0FSUklPUiBpcyBub3Qgc2V0CkNPTkZJR19KT1lTVElDS19NQUdFTExBTj1tCiMgQ09O
RklHX0pPWVNUSUNLX1NQQUNFT1JCIGlzIG5vdCBzZXQKQ09ORklHX0pPWVNUSUNLX1NQQUNF
QkFMTD1tCkNPTkZJR19KT1lTVElDS19TVElOR0VSPW0KQ09ORklHX0pPWVNUSUNLX1RXSURK
T1k9bQpDT05GSUdfSk9ZU1RJQ0tfWkhFTkhVQT1tCiMgQ09ORklHX0pPWVNUSUNLX0pPWURV
TVAgaXMgbm90IHNldAojIENPTkZJR19JTlBVVF9UQUJMRVQgaXMgbm90IHNldApDT05GSUdf
SU5QVVRfVE9VQ0hTQ1JFRU49eQpDT05GSUdfVE9VQ0hTQ1JFRU5fQURTNzg0Nj1tCiMgQ09O
RklHX1RPVUNIU0NSRUVOX0FENzg3NyBpcyBub3Qgc2V0CkNPTkZJR19UT1VDSFNDUkVFTl9B
RDc4Nzk9bQojIENPTkZJR19UT1VDSFNDUkVFTl9BRDc4NzlfU1BJIGlzIG5vdCBzZXQKIyBD
T05GSUdfVE9VQ0hTQ1JFRU5fRFlOQVBSTyBpcyBub3Qgc2V0CkNPTkZJR19UT1VDSFNDUkVF
Tl9IQU1QU0hJUkU9bQpDT05GSUdfVE9VQ0hTQ1JFRU5fRlVKSVRTVT1tCiMgQ09ORklHX1RP
VUNIU0NSRUVOX0dVTlpFIGlzIG5vdCBzZXQKIyBDT05GSUdfVE9VQ0hTQ1JFRU5fRUxPIGlz
IG5vdCBzZXQKQ09ORklHX1RPVUNIU0NSRUVOX1dBQ09NX1c4MDAxPW0KIyBDT05GSUdfVE9V
Q0hTQ1JFRU5fTVRPVUNIIGlzIG5vdCBzZXQKIyBDT05GSUdfVE9VQ0hTQ1JFRU5fSU5FWElP
IGlzIG5vdCBzZXQKQ09ORklHX1RPVUNIU0NSRUVOX01LNzEyPW0KQ09ORklHX1RPVUNIU0NS
RUVOX1BFTk1PVU5UPW0KIyBDT05GSUdfVE9VQ0hTQ1JFRU5fVE9VQ0hSSUdIVCBpcyBub3Qg
c2V0CiMgQ09ORklHX1RPVUNIU0NSRUVOX1RPVUNIV0lOIGlzIG5vdCBzZXQKQ09ORklHX1RP
VUNIU0NSRUVOX1dNODMxWD1tCiMgQ09ORklHX1RPVUNIU0NSRUVOX1RPVUNISVQyMTMgaXMg
bm90IHNldAojIENPTkZJR19UT1VDSFNDUkVFTl9UU0NfU0VSSU8gaXMgbm90IHNldAojIENP
TkZJR19UT1VDSFNDUkVFTl9UU0MyMDA1IGlzIG5vdCBzZXQKQ09ORklHX0lOUFVUX01JU0M9
eQpDT05GSUdfSU5QVVRfQUQ3MTRYPW0KQ09ORklHX0lOUFVUX0FENzE0WF9TUEk9bQpDT05G
SUdfSU5QVVRfUENTUEtSPW0KQ09ORklHX0lOUFVUX1VJTlBVVD1tCiMgQ09ORklHX0lOUFVU
X1dNODMxWF9PTiBpcyBub3Qgc2V0CiMgQ09ORklHX0lOUFVUX0FEWEwzNFggaXMgbm90IHNl
dAojIENPTkZJR19JTlBVVF9DTUEzMDAwIGlzIG5vdCBzZXQKQ09ORklHX0lOUFVUX1hFTl9L
QkRERVZfRlJPTlRFTkQ9bQoKIwojIEhhcmR3YXJlIEkvTyBwb3J0cwojCkNPTkZJR19TRVJJ
Tz15CkNPTkZJR19TRVJJT19JODA0Mj15CkNPTkZJR19TRVJJT19TRVJQT1JUPW0KQ09ORklH
X1NFUklPX0NUODJDNzEwPW0KQ09ORklHX1NFUklPX0xJQlBTMj15CiMgQ09ORklHX1NFUklP
X1JBVyBpcyBub3Qgc2V0CkNPTkZJR19TRVJJT19BTFRFUkFfUFMyPW0KQ09ORklHX1NFUklP
X1BTMk1VTFQ9bQpDT05GSUdfR0FNRVBPUlQ9bQojIENPTkZJR19HQU1FUE9SVF9OUzU1OCBp
cyBub3Qgc2V0CiMgQ09ORklHX0dBTUVQT1JUX0w0IGlzIG5vdCBzZXQKCiMKIyBDaGFyYWN0
ZXIgZGV2aWNlcwojCkNPTkZJR19WVD15CkNPTkZJR19DT05TT0xFX1RSQU5TTEFUSU9OUz15
CkNPTkZJR19WVF9DT05TT0xFPXkKQ09ORklHX1ZUX0NPTlNPTEVfU0xFRVA9eQpDT05GSUdf
SFdfQ09OU09MRT15CkNPTkZJR19WVF9IV19DT05TT0xFX0JJTkRJTkc9eQpDT05GSUdfVU5J
WDk4X1BUWVM9eQojIENPTkZJR19ERVZQVFNfTVVMVElQTEVfSU5TVEFOQ0VTIGlzIG5vdCBz
ZXQKQ09ORklHX0xFR0FDWV9QVFlTPXkKQ09ORklHX0xFR0FDWV9QVFlfQ09VTlQ9MjU2CkNP
TkZJR19TRVJJQUxfTk9OU1RBTkRBUkQ9eQojIENPTkZJR19OX0hETEMgaXMgbm90IHNldApD
T05GSUdfVFJBQ0VfUk9VVEVSPW0KQ09ORklHX1RSQUNFX1NJTks9bQojIENPTkZJR19ERVZL
TUVNIGlzIG5vdCBzZXQKQ09ORklHX1NUQUxEUlY9eQoKIwojIFNlcmlhbCBkcml2ZXJzCiMK
Q09ORklHX1NFUklBTF84MjUwPW0KQ09ORklHX0ZJWF9FQVJMWUNPTl9NRU09eQpDT05GSUdf
U0VSSUFMXzgyNTBfTlJfVUFSVFM9NApDT05GSUdfU0VSSUFMXzgyNTBfUlVOVElNRV9VQVJU
Uz00CkNPTkZJR19TRVJJQUxfODI1MF9FWFRFTkRFRD15CiMgQ09ORklHX1NFUklBTF84MjUw
X01BTllfUE9SVFMgaXMgbm90IHNldAojIENPTkZJR19TRVJJQUxfODI1MF9TSEFSRV9JUlEg
aXMgbm90IHNldAojIENPTkZJR19TRVJJQUxfODI1MF9ERVRFQ1RfSVJRIGlzIG5vdCBzZXQK
IyBDT05GSUdfU0VSSUFMXzgyNTBfUlNBIGlzIG5vdCBzZXQKCiMKIyBOb24tODI1MCBzZXJp
YWwgcG9ydCBzdXBwb3J0CiMKQ09ORklHX1NFUklBTF9NQVgzMTAwPW0KIyBDT05GSUdfU0VS
SUFMX01BWDMxMDcgaXMgbm90IHNldApDT05GSUdfU0VSSUFMX0NPUkU9bQojIENPTkZJR19T
RVJJQUxfVElNQkVSREFMRSBpcyBub3Qgc2V0CkNPTkZJR19TRVJJQUxfQUxURVJBX0pUQUdV
QVJUPW0KIyBDT05GSUdfU0VSSUFMX0FMVEVSQV9VQVJUIGlzIG5vdCBzZXQKQ09ORklHX1NF
UklBTF9YSUxJTlhfUFNfVUFSVD1tCkNPTkZJR19IVkNfRFJJVkVSPXkKQ09ORklHX0hWQ19J
UlE9eQpDT05GSUdfSFZDX1hFTj15CkNPTkZJR19WSVJUSU9fQ09OU09MRT1tCiMgQ09ORklH
X0lQTUlfSEFORExFUiBpcyBub3Qgc2V0CkNPTkZJR19IV19SQU5ET009bQojIENPTkZJR19I
V19SQU5ET01fVElNRVJJT01FTSBpcyBub3Qgc2V0CkNPTkZJR19IV19SQU5ET01fVklBPW0K
IyBDT05GSUdfSFdfUkFORE9NX1ZJUlRJTyBpcyBub3Qgc2V0CiMgQ09ORklHX05WUkFNIGlz
IG5vdCBzZXQKIyBDT05GSUdfUjM5NjQgaXMgbm90IHNldApDT05GSUdfTVdBVkU9bQojIENP
TkZJR19SQVdfRFJJVkVSIGlzIG5vdCBzZXQKQ09ORklHX0hBTkdDSEVDS19USU1FUj1tCiMg
Q09ORklHX1JBTU9PUFMgaXMgbm90IHNldAojIENPTkZJR19JMkMgaXMgbm90IHNldApDT05G
SUdfU1BJPXkKQ09ORklHX1NQSV9ERUJVRz15CkNPTkZJR19TUElfTUFTVEVSPXkKCiMKIyBT
UEkgTWFzdGVyIENvbnRyb2xsZXIgRHJpdmVycwojCiMgQ09ORklHX1NQSV9BTFRFUkEgaXMg
bm90IHNldApDT05GSUdfU1BJX0JJVEJBTkc9bQojIENPTkZJR19TUElfUFhBMlhYX1BDSSBp
cyBub3Qgc2V0CkNPTkZJR19TUElfREVTSUdOV0FSRT1tCgojCiMgU1BJIFByb3RvY29sIE1h
c3RlcnMKIwojIENPTkZJR19TUElfVExFNjJYMCBpcyBub3Qgc2V0CkNPTkZJR19IU0k9bQpD
T05GSUdfSFNJX0JPQVJESU5GTz15CgojCiMgSFNJIGNsaWVudHMKIwpDT05GSUdfSFNJX0NI
QVI9bQoKIwojIFBQUyBzdXBwb3J0CiMKCiMKIyBQUFMgZ2VuZXJhdG9ycyBzdXBwb3J0CiMK
CiMKIyBQVFAgY2xvY2sgc3VwcG9ydAojCgojCiMgRW5hYmxlIERldmljZSBEcml2ZXJzIC0+
IFBQUyB0byBzZWUgdGhlIFBUUCBjbG9jayBvcHRpb25zLgojCkNPTkZJR19BUkNIX1dBTlRf
T1BUSU9OQUxfR1BJT0xJQj15CiMgQ09ORklHX0dQSU9MSUIgaXMgbm90IHNldApDT05GSUdf
VzE9bQoKIwojIDEtd2lyZSBCdXMgTWFzdGVycwojCkNPTkZJR19XMV9NQVNURVJfRFMxV009
bQoKIwojIDEtd2lyZSBTbGF2ZXMKIwpDT05GSUdfVzFfU0xBVkVfVEhFUk09bQojIENPTkZJ
R19XMV9TTEFWRV9TTUVNIGlzIG5vdCBzZXQKIyBDT05GSUdfVzFfU0xBVkVfRFMyNDA4IGlz
IG5vdCBzZXQKQ09ORklHX1cxX1NMQVZFX0RTMjQyMz1tCiMgQ09ORklHX1cxX1NMQVZFX0RT
MjQzMSBpcyBub3Qgc2V0CkNPTkZJR19XMV9TTEFWRV9EUzI0MzM9bQpDT05GSUdfVzFfU0xB
VkVfRFMyNDMzX0NSQz15CiMgQ09ORklHX1cxX1NMQVZFX0RTMjc2MCBpcyBub3Qgc2V0CiMg
Q09ORklHX1cxX1NMQVZFX0RTMjc4MCBpcyBub3Qgc2V0CiMgQ09ORklHX1cxX1NMQVZFX0JR
MjcwMDAgaXMgbm90IHNldApDT05GSUdfUE9XRVJfU1VQUExZPW0KIyBDT05GSUdfUE9XRVJf
U1VQUExZX0RFQlVHIGlzIG5vdCBzZXQKIyBDT05GSUdfUERBX1BPV0VSIGlzIG5vdCBzZXQK
Q09ORklHX1dNODMxWF9CQUNLVVA9bQojIENPTkZJR19XTTgzMVhfUE9XRVIgaXMgbm90IHNl
dAojIENPTkZJR19URVNUX1BPV0VSIGlzIG5vdCBzZXQKIyBDT05GSUdfQkFUVEVSWV9EUzI3
ODAgaXMgbm90IHNldApDT05GSUdfQkFUVEVSWV9CUTI3eDAwPW0KIyBDT05GSUdfQkFUVEVS
WV9CUTI3WDAwX1BMQVRGT1JNIGlzIG5vdCBzZXQKIyBDT05GSUdfQ0hBUkdFUl9NQVg4OTAz
IGlzIG5vdCBzZXQKQ09ORklHX0hXTU9OPW0KQ09ORklHX0hXTU9OX1ZJRD1tCkNPTkZJR19I
V01PTl9ERUJVR19DSElQPXkKCiMKIyBOYXRpdmUgZHJpdmVycwojCiMgQ09ORklHX1NFTlNP
UlNfRjcxODA1RiBpcyBub3Qgc2V0CkNPTkZJR19TRU5TT1JTX0Y3MTg4MkZHPW0KIyBDT05G
SUdfU0VOU09SU19JVDg3IGlzIG5vdCBzZXQKQ09ORklHX1NFTlNPUlNfTE03MD1tCiMgQ09O
RklHX1NFTlNPUlNfTUFYMTExMSBpcyBub3Qgc2V0CkNPTkZJR19TRU5TT1JTX1BDODczNjA9
bQpDT05GSUdfU0VOU09SU19QQzg3NDI3PW0KQ09ORklHX1NFTlNPUlNfU01TQzQ3TTE9bQpD
T05GSUdfU0VOU09SU19TQ0g1NlhYX0NPTU1PTj1tCkNPTkZJR19TRU5TT1JTX1NDSDU2Mjc9
bQojIENPTkZJR19TRU5TT1JTX1NDSDU2MzYgaXMgbm90IHNldApDT05GSUdfU0VOU09SU19B
RFM3ODcxPW0KIyBDT05GSUdfU0VOU09SU19WSUFfQ1BVVEVNUCBpcyBub3Qgc2V0CiMgQ09O
RklHX1NFTlNPUlNfVlQxMjExIGlzIG5vdCBzZXQKQ09ORklHX1NFTlNPUlNfVzgzNjI3SEY9
bQojIENPTkZJR19TRU5TT1JTX1c4MzYyN0VIRiBpcyBub3Qgc2V0CiMgQ09ORklHX1NFTlNP
UlNfV004MzFYIGlzIG5vdCBzZXQKQ09ORklHX1NFTlNPUlNfQVBQTEVTTUM9bQpDT05GSUdf
VEhFUk1BTD1tCkNPTkZJR19USEVSTUFMX0hXTU9OPXkKQ09ORklHX1dBVENIRE9HPXkKIyBD
T05GSUdfV0FUQ0hET0dfQ09SRSBpcyBub3Qgc2V0CiMgQ09ORklHX1dBVENIRE9HX05PV0FZ
T1VUIGlzIG5vdCBzZXQKCiMKIyBXYXRjaGRvZyBEZXZpY2UgRHJpdmVycwojCkNPTkZJR19T
T0ZUX1dBVENIRE9HPW0KIyBDT05GSUdfV004MzFYX1dBVENIRE9HIGlzIG5vdCBzZXQKIyBD
T05GSUdfQUNRVUlSRV9XRFQgaXMgbm90IHNldAojIENPTkZJR19BRFZBTlRFQ0hfV0RUIGlz
IG5vdCBzZXQKIyBDT05GSUdfU0M1MjBfV0RUIGlzIG5vdCBzZXQKQ09ORklHX1NCQ19GSVRQ
QzJfV0FUQ0hET0c9bQojIENPTkZJR19FVVJPVEVDSF9XRFQgaXMgbm90IHNldApDT05GSUdf
SUI3MDBfV0RUPW0KIyBDT05GSUdfSUJNQVNSIGlzIG5vdCBzZXQKQ09ORklHX1dBRkVSX1dE
VD1tCkNPTkZJR19JVDg3MTJGX1dEVD1tCiMgQ09ORklHX1NDMTIwMF9XRFQgaXMgbm90IHNl
dAojIENPTkZJR19QQzg3NDEzX1dEVCBpcyBub3Qgc2V0CiMgQ09ORklHXzYwWFhfV0RUIGlz
IG5vdCBzZXQKQ09ORklHX1NCQzgzNjBfV0RUPW0KQ09ORklHX0NQVTVfV0RUPW0KQ09ORklH
X1NNU0NfU0NIMzExWF9XRFQ9bQojIENPTkZJR19TTVNDMzdCNzg3X1dEVCBpcyBub3Qgc2V0
CiMgQ09ORklHX1c4MzYyN0hGX1dEVCBpcyBub3Qgc2V0CkNPTkZJR19XODM2OTdIRl9XRFQ9
bQpDT05GSUdfVzgzNjk3VUdfV0RUPW0KQ09ORklHX1c4Mzg3N0ZfV0RUPW0KIyBDT05GSUdf
VzgzOTc3Rl9XRFQgaXMgbm90IHNldAojIENPTkZJR19NQUNIWl9XRFQgaXMgbm90IHNldAoj
IENPTkZJR19TQkNfRVBYX0MzX1dBVENIRE9HIGlzIG5vdCBzZXQKIyBDT05GSUdfWEVOX1dE
VCBpcyBub3Qgc2V0CkNPTkZJR19TU0JfUE9TU0lCTEU9eQoKIwojIFNvbmljcyBTaWxpY29u
IEJhY2twbGFuZQojCiMgQ09ORklHX1NTQiBpcyBub3Qgc2V0CkNPTkZJR19CQ01BX1BPU1NJ
QkxFPXkKCiMKIyBCcm9hZGNvbSBzcGVjaWZpYyBBTUJBCiMKQ09ORklHX0JDTUE9bQpDT05G
SUdfQkNNQV9ERUJVRz15CgojCiMgTXVsdGlmdW5jdGlvbiBkZXZpY2UgZHJpdmVycwojCkNP
TkZJR19NRkRfQ09SRT15CkNPTkZJR19NRkRfU001MDE9bQpDT05GSUdfSFRDX1BBU0lDMz1t
CiMgQ09ORklHX01GRF9UTUlPIGlzIG5vdCBzZXQKQ09ORklHX01GRF9XTTgzMVg9eQpDT05G
SUdfTUZEX1dNODMxWF9TUEk9eQojIENPTkZJR19NRkRfTUMxM1hYWCBpcyBub3Qgc2V0CkNP
TkZJR19BQlg1MDBfQ09SRT15CiMgQ09ORklHX0VaWF9QQ0FQIGlzIG5vdCBzZXQKIyBDT05G
SUdfQUI4NTAwX0NPUkUgaXMgbm90IHNldAojIENPTkZJR19SRUdVTEFUT1IgaXMgbm90IHNl
dAojIENPTkZJR19NRURJQV9TVVBQT1JUIGlzIG5vdCBzZXQKCiMKIyBHcmFwaGljcyBzdXBw
b3J0CiMKIyBDT05GSUdfRFJNIGlzIG5vdCBzZXQKQ09ORklHX1ZHQVNUQVRFPW0KIyBDT05G
SUdfVklERU9fT1VUUFVUX0NPTlRST0wgaXMgbm90IHNldApDT05GSUdfRkI9bQojIENPTkZJ
R19GSVJNV0FSRV9FRElEIGlzIG5vdCBzZXQKIyBDT05GSUdfRkJfRERDIGlzIG5vdCBzZXQK
IyBDT05GSUdfRkJfQk9PVF9WRVNBX1NVUFBPUlQgaXMgbm90IHNldApDT05GSUdfRkJfQ0ZC
X0ZJTExSRUNUPW0KQ09ORklHX0ZCX0NGQl9DT1BZQVJFQT1tCkNPTkZJR19GQl9DRkJfSU1B
R0VCTElUPW0KIyBDT05GSUdfRkJfQ0ZCX1JFVl9QSVhFTFNfSU5fQllURSBpcyBub3Qgc2V0
CkNPTkZJR19GQl9TWVNfRklMTFJFQ1Q9bQpDT05GSUdfRkJfU1lTX0NPUFlBUkVBPW0KQ09O
RklHX0ZCX1NZU19JTUFHRUJMSVQ9bQpDT05GSUdfRkJfRk9SRUlHTl9FTkRJQU49eQojIENP
TkZJR19GQl9CT1RIX0VORElBTiBpcyBub3Qgc2V0CiMgQ09ORklHX0ZCX0JJR19FTkRJQU4g
aXMgbm90IHNldApDT05GSUdfRkJfTElUVExFX0VORElBTj15CkNPTkZJR19GQl9TWVNfRk9Q
Uz1tCiMgQ09ORklHX0ZCX1dNVF9HRV9ST1BTIGlzIG5vdCBzZXQKQ09ORklHX0ZCX0RFRkVS
UkVEX0lPPXkKQ09ORklHX0ZCX0hFQ1VCQT1tCiMgQ09ORklHX0ZCX1NWR0FMSUIgaXMgbm90
IHNldAojIENPTkZJR19GQl9NQUNNT0RFUyBpcyBub3Qgc2V0CiMgQ09ORklHX0ZCX0JBQ0tM
SUdIVCBpcyBub3Qgc2V0CiMgQ09ORklHX0ZCX01PREVfSEVMUEVSUyBpcyBub3Qgc2V0CiMg
Q09ORklHX0ZCX1RJTEVCTElUVElORyBpcyBub3Qgc2V0CgojCiMgRnJhbWUgYnVmZmVyIGhh
cmR3YXJlIGRyaXZlcnMKIwpDT05GSUdfRkJfQVJDPW0KQ09ORklHX0ZCX1ZHQTE2PW0KQ09O
RklHX0ZCX040MTE9bQojIENPTkZJR19GQl9IR0EgaXMgbm90IHNldApDT05GSUdfRkJfUzFE
MTNYWFg9bQpDT05GSUdfRkJfVE1JTz1tCiMgQ09ORklHX0ZCX1RNSU9fQUNDRUxMIGlzIG5v
dCBzZXQKIyBDT05GSUdfRkJfU001MDEgaXMgbm90IHNldAojIENPTkZJR19GQl9WSVJUVUFM
IGlzIG5vdCBzZXQKQ09ORklHX1hFTl9GQkRFVl9GUk9OVEVORD1tCkNPTkZJR19GQl9NRVRS
T05PTUU9bQpDT05GSUdfRkJfQlJPQURTSEVFVD1tCkNPTkZJR19CQUNLTElHSFRfTENEX1NV
UFBPUlQ9eQpDT05GSUdfTENEX0NMQVNTX0RFVklDRT1tCiMgQ09ORklHX0xDRF9MVFYzNTBR
ViBpcyBub3Qgc2V0CkNPTkZJR19MQ0RfSUxJOTMyMD1tCkNPTkZJR19MQ0RfVERPMjRNPW0K
Q09ORklHX0xDRF9WR0cyNDMyQTQ9bQojIENPTkZJR19MQ0RfUExBVEZPUk0gaXMgbm90IHNl
dApDT05GSUdfTENEX1M2RTYzTTA9bQpDT05GSUdfTENEX0xEOTA0MD1tCkNPTkZJR19MQ0Rf
QU1TMzY5RkcwNj1tCkNPTkZJR19CQUNLTElHSFRfQ0xBU1NfREVWSUNFPW0KQ09ORklHX0JB
Q0tMSUdIVF9HRU5FUklDPW0KIyBDT05GSUdfQkFDS0xJR0hUX1NBSEFSQSBpcyBub3Qgc2V0
CiMgQ09ORklHX0JBQ0tMSUdIVF9XTTgzMVggaXMgbm90IHNldAoKIwojIENvbnNvbGUgZGlz
cGxheSBkcml2ZXIgc3VwcG9ydAojCkNPTkZJR19WR0FfQ09OU09MRT15CiMgQ09ORklHX1ZH
QUNPTl9TT0ZUX1NDUk9MTEJBQ0sgaXMgbm90IHNldApDT05GSUdfRFVNTVlfQ09OU09MRT15
CkNPTkZJR19GUkFNRUJVRkZFUl9DT05TT0xFPW0KQ09ORklHX0ZSQU1FQlVGRkVSX0NPTlNP
TEVfREVURUNUX1BSSU1BUlk9eQojIENPTkZJR19GUkFNRUJVRkZFUl9DT05TT0xFX1JPVEFU
SU9OIGlzIG5vdCBzZXQKQ09ORklHX0ZPTlRTPXkKIyBDT05GSUdfRk9OVF84eDggaXMgbm90
IHNldApDT05GSUdfRk9OVF84eDE2PXkKIyBDT05GSUdfRk9OVF82eDExIGlzIG5vdCBzZXQK
IyBDT05GSUdfRk9OVF83eDE0IGlzIG5vdCBzZXQKQ09ORklHX0ZPTlRfUEVBUkxfOHg4PXkK
IyBDT05GSUdfRk9OVF9BQ09STl84eDggaXMgbm90IHNldAojIENPTkZJR19GT05UX01JTklf
NHg2IGlzIG5vdCBzZXQKQ09ORklHX0ZPTlRfU1VOOHgxNj15CkNPTkZJR19GT05UX1NVTjEy
eDIyPXkKQ09ORklHX0ZPTlRfMTB4MTg9eQpDT05GSUdfTE9HTz15CkNPTkZJR19MT0dPX0xJ
TlVYX01PTk89eQpDT05GSUdfTE9HT19MSU5VWF9WR0ExNj15CiMgQ09ORklHX0xPR09fTElO
VVhfQ0xVVDIyNCBpcyBub3Qgc2V0CiMgQ09ORklHX1NPVU5EIGlzIG5vdCBzZXQKQ09ORklH
X0hJRF9TVVBQT1JUPXkKIyBDT05GSUdfSElEIGlzIG5vdCBzZXQKQ09ORklHX0hJRF9CQVRU
RVJZX1NUUkVOR1RIPXkKIyBDT05GSUdfSElEX1BJRCBpcyBub3Qgc2V0CiMgQ09ORklHX1VT
Ql9TVVBQT1JUIGlzIG5vdCBzZXQKQ09ORklHX01NQz1tCkNPTkZJR19NTUNfREVCVUc9eQpD
T05GSUdfTU1DX1VOU0FGRV9SRVNVTUU9eQoKIwojIE1NQy9TRC9TRElPIENhcmQgRHJpdmVy
cwojCkNPTkZJR19NTUNfQkxPQ0s9bQpDT05GSUdfTU1DX0JMT0NLX01JTk9SUz04CiMgQ09O
RklHX01NQ19CTE9DS19CT1VOQ0UgaXMgbm90IHNldAojIENPTkZJR19TRElPX1VBUlQgaXMg
bm90IHNldApDT05GSUdfTU1DX1RFU1Q9bQoKIwojIE1NQy9TRC9TRElPIEhvc3QgQ29udHJv
bGxlciBEcml2ZXJzCiMKIyBDT05GSUdfTU1DX1NESENJIGlzIG5vdCBzZXQKQ09ORklHX01N
Q19XQlNEPW0KQ09ORklHX01NQ19TUEk9bQpDT05GSUdfTUVNU1RJQ0s9bQojIENPTkZJR19N
RU1TVElDS19ERUJVRyBpcyBub3Qgc2V0CgojCiMgTWVtb3J5U3RpY2sgZHJpdmVycwojCkNP
TkZJR19NRU1TVElDS19VTlNBRkVfUkVTVU1FPXkKQ09ORklHX01TUFJPX0JMT0NLPW0KCiMK
IyBNZW1vcnlTdGljayBIb3N0IENvbnRyb2xsZXIgRHJpdmVycwojCkNPTkZJR19ORVdfTEVE
Uz15CkNPTkZJR19MRURTX0NMQVNTPXkKCiMKIyBMRUQgZHJpdmVycwojCkNPTkZJR19MRURT
X0NMRVZPX01BSUw9bQojIENPTkZJR19MRURTX1dNODMxWF9TVEFUVVMgaXMgbm90IHNldAoj
IENPTkZJR19MRURTX0RBQzEyNFMwODUgaXMgbm90IHNldApDT05GSUdfTEVEU19UUklHR0VS
Uz15CgojCiMgTEVEIFRyaWdnZXJzCiMKQ09ORklHX0xFRFNfVFJJR0dFUl9USU1FUj1tCkNP
TkZJR19MRURTX1RSSUdHRVJfSEVBUlRCRUFUPW0KIyBDT05GSUdfTEVEU19UUklHR0VSX0JB
Q0tMSUdIVCBpcyBub3Qgc2V0CiMgQ09ORklHX0xFRFNfVFJJR0dFUl9ERUZBVUxUX09OIGlz
IG5vdCBzZXQKCiMKIyBpcHRhYmxlcyB0cmlnZ2VyIGlzIHVuZGVyIE5ldGZpbHRlciBjb25m
aWcgKExFRCB0YXJnZXQpCiMKQ09ORklHX0FDQ0VTU0lCSUxJVFk9eQojIENPTkZJR19FREFD
IGlzIG5vdCBzZXQKQ09ORklHX1JUQ19MSUI9eQpDT05GSUdfUlRDX0NMQVNTPXkKIyBDT05G
SUdfUlRDX0hDVE9TWVMgaXMgbm90IHNldApDT05GSUdfUlRDX0RFQlVHPXkKCiMKIyBSVEMg
aW50ZXJmYWNlcwojCiMgQ09ORklHX1JUQ19JTlRGX1NZU0ZTIGlzIG5vdCBzZXQKIyBDT05G
SUdfUlRDX0lOVEZfUFJPQyBpcyBub3Qgc2V0CkNPTkZJR19SVENfSU5URl9ERVY9eQojIENP
TkZJR19SVENfSU5URl9ERVZfVUlFX0VNVUwgaXMgbm90IHNldApDT05GSUdfUlRDX0RSVl9U
RVNUPW0KCiMKIyBTUEkgUlRDIGRyaXZlcnMKIwpDT05GSUdfUlRDX0RSVl9NNDFUOTM9bQpD
T05GSUdfUlRDX0RSVl9NNDFUOTQ9bQojIENPTkZJR19SVENfRFJWX0RTMTMwNSBpcyBub3Qg
c2V0CiMgQ09ORklHX1JUQ19EUlZfRFMxMzkwIGlzIG5vdCBzZXQKQ09ORklHX1JUQ19EUlZf
TUFYNjkwMj1tCiMgQ09ORklHX1JUQ19EUlZfUjk3MDEgaXMgbm90IHNldApDT05GSUdfUlRD
X0RSVl9SUzVDMzQ4PW0KIyBDT05GSUdfUlRDX0RSVl9EUzMyMzQgaXMgbm90IHNldApDT05G
SUdfUlRDX0RSVl9QQ0YyMTIzPW0KCiMKIyBQbGF0Zm9ybSBSVEMgZHJpdmVycwojCiMgQ09O
RklHX1JUQ19EUlZfQ01PUyBpcyBub3Qgc2V0CiMgQ09ORklHX1JUQ19EUlZfRFMxMjg2IGlz
IG5vdCBzZXQKIyBDT05GSUdfUlRDX0RSVl9EUzE1MTEgaXMgbm90IHNldApDT05GSUdfUlRD
X0RSVl9EUzE1NTM9bQojIENPTkZJR19SVENfRFJWX0RTMTc0MiBpcyBub3Qgc2V0CkNPTkZJ
R19SVENfRFJWX1NUSzE3VEE4PW0KIyBDT05GSUdfUlRDX0RSVl9NNDhUODYgaXMgbm90IHNl
dAojIENPTkZJR19SVENfRFJWX000OFQzNSBpcyBub3Qgc2V0CiMgQ09ORklHX1JUQ19EUlZf
TTQ4VDU5IGlzIG5vdCBzZXQKIyBDT05GSUdfUlRDX0RSVl9NU002MjQyIGlzIG5vdCBzZXQK
Q09ORklHX1JUQ19EUlZfQlE0ODAyPW0KIyBDT05GSUdfUlRDX0RSVl9SUDVDMDEgaXMgbm90
IHNldAojIENPTkZJR19SVENfRFJWX1YzMDIwIGlzIG5vdCBzZXQKQ09ORklHX1JUQ19EUlZf
V004MzFYPW0KCiMKIyBvbi1DUFUgUlRDIGRyaXZlcnMKIwpDT05GSUdfRE1BREVWSUNFUz15
CiMgQ09ORklHX0RNQURFVklDRVNfREVCVUcgaXMgbm90IHNldAoKIwojIERNQSBEZXZpY2Vz
CiMKIyBDT05GSUdfVElNQl9ETUEgaXMgbm90IHNldApDT05GSUdfQVVYRElTUExBWT15CkNP
TkZJR19VSU89bQpDT05GSUdfVUlPX1BEUlY9bQpDT05GSUdfVUlPX1BEUlZfR0VOSVJRPW0K
Q09ORklHX1ZJUlRJTz1tCkNPTkZJR19WSVJUSU9fUklORz1tCgojCiMgVmlydGlvIGRyaXZl
cnMKIwpDT05GSUdfVklSVElPX0JBTExPT049bQoKIwojIE1pY3Jvc29mdCBIeXBlci1WIGd1
ZXN0IHN1cHBvcnQKIwoKIwojIFhlbiBkcml2ZXIgc3VwcG9ydAojCiMgQ09ORklHX1hFTl9C
QUxMT09OIGlzIG5vdCBzZXQKIyBDT05GSUdfWEVOX0RFVl9FVlRDSE4gaXMgbm90IHNldAoj
IENPTkZJR19YRU5GUyBpcyBub3Qgc2V0CkNPTkZJR19YRU5fU1lTX0hZUEVSVklTT1I9eQpD
T05GSUdfWEVOX1hFTkJVU19GUk9OVEVORD1tCkNPTkZJR19YRU5fR05UREVWPW0KQ09ORklH
X1hFTl9HUkFOVF9ERVZfQUxMT0M9bQpDT05GSUdfWEVOX1BSSVZDTUQ9bQojIENPTkZJR19T
VEFHSU5HIGlzIG5vdCBzZXQKIyBDT05GSUdfWDg2X1BMQVRGT1JNX0RFVklDRVMgaXMgbm90
IHNldAoKIwojIEhhcmR3YXJlIFNwaW5sb2NrIGRyaXZlcnMKIwpDT05GSUdfQ0xLRVZUX0k4
MjUzPXkKQ09ORklHX0k4MjUzX0xPQ0s9eQpDT05GSUdfQ0xLQkxEX0k4MjUzPXkKIyBDT05G
SUdfSU9NTVVfU1VQUE9SVCBpcyBub3Qgc2V0CiMgQ09ORklHX1ZJUlRfRFJJVkVSUyBpcyBu
b3Qgc2V0CiMgQ09ORklHX1BNX0RFVkZSRVEgaXMgbm90IHNldAoKIwojIEZpcm13YXJlIERy
aXZlcnMKIwpDT05GSUdfRUREPW0KIyBDT05GSUdfRUREX09GRiBpcyBub3Qgc2V0CkNPTkZJ
R19GSVJNV0FSRV9NRU1NQVA9eQojIENPTkZJR19ERUxMX1JCVSBpcyBub3Qgc2V0CiMgQ09O
RklHX0RDREJBUyBpcyBub3Qgc2V0CiMgQ09ORklHX0RNSUlEIGlzIG5vdCBzZXQKQ09ORklH
X0RNSV9TWVNGUz1tCkNPTkZJR19JU0NTSV9JQkZUX0ZJTkQ9eQpDT05GSUdfR09PR0xFX0ZJ
Uk1XQVJFPXkKCiMKIyBHb29nbGUgRmlybXdhcmUgRHJpdmVycwojCiMgQ09ORklHX0dPT0dM
RV9NRU1DT05TT0xFIGlzIG5vdCBzZXQKCiMKIyBGaWxlIHN5c3RlbXMKIwojIENPTkZJR19F
WFQyX0ZTIGlzIG5vdCBzZXQKQ09ORklHX0VYVDNfRlM9bQojIENPTkZJR19FWFQzX0RFRkFV
TFRTX1RPX09SREVSRUQgaXMgbm90IHNldAojIENPTkZJR19FWFQzX0ZTX1hBVFRSIGlzIG5v
dCBzZXQKQ09ORklHX0VYVDRfRlM9bQpDT05GSUdfRVhUNF9VU0VfRk9SX0VYVDIzPXkKIyBD
T05GSUdfRVhUNF9GU19YQVRUUiBpcyBub3Qgc2V0CiMgQ09ORklHX0VYVDRfREVCVUcgaXMg
bm90IHNldApDT05GSUdfSkJEPW0KIyBDT05GSUdfSkJEX0RFQlVHIGlzIG5vdCBzZXQKQ09O
RklHX0pCRDI9bQpDT05GSUdfSkJEMl9ERUJVRz15CiMgQ09ORklHX1JFSVNFUkZTX0ZTIGlz
IG5vdCBzZXQKIyBDT05GSUdfSkZTX0ZTIGlzIG5vdCBzZXQKIyBDT05GSUdfWEZTX0ZTIGlz
IG5vdCBzZXQKIyBDT05GSUdfR0ZTMl9GUyBpcyBub3Qgc2V0CiMgQ09ORklHX09DRlMyX0ZT
IGlzIG5vdCBzZXQKQ09ORklHX0ZTX1BPU0lYX0FDTD15CkNPTkZJR19FWFBPUlRGUz15CkNP
TkZJR19GSUxFX0xPQ0tJTkc9eQpDT05GSUdfRlNOT1RJRlk9eQojIENPTkZJR19ETk9USUZZ
IGlzIG5vdCBzZXQKQ09ORklHX0lOT1RJRllfVVNFUj15CkNPTkZJR19GQU5PVElGWT15CiMg
Q09ORklHX1FVT1RBIGlzIG5vdCBzZXQKIyBDT05GSUdfUVVPVEFDVEwgaXMgbm90IHNldAoj
IENPTkZJR19BVVRPRlM0X0ZTIGlzIG5vdCBzZXQKIyBDT05GSUdfRlVTRV9GUyBpcyBub3Qg
c2V0CkNPTkZJR19HRU5FUklDX0FDTD15CgojCiMgQ2FjaGVzCiMKQ09ORklHX0ZTQ0FDSEU9
bQpDT05GSUdfRlNDQUNIRV9TVEFUUz15CiMgQ09ORklHX0ZTQ0FDSEVfSElTVE9HUkFNIGlz
IG5vdCBzZXQKQ09ORklHX0ZTQ0FDSEVfREVCVUc9eQojIENPTkZJR19GU0NBQ0hFX09CSkVD
VF9MSVNUIGlzIG5vdCBzZXQKIyBDT05GSUdfQ0FDSEVGSUxFUyBpcyBub3Qgc2V0CgojCiMg
Q0QtUk9NL0RWRCBGaWxlc3lzdGVtcwojCkNPTkZJR19JU085NjYwX0ZTPW0KIyBDT05GSUdf
Sk9MSUVUIGlzIG5vdCBzZXQKIyBDT05GSUdfWklTT0ZTIGlzIG5vdCBzZXQKQ09ORklHX1VE
Rl9GUz1tCkNPTkZJR19VREZfTkxTPXkKCiMKIyBET1MvRkFUL05UIEZpbGVzeXN0ZW1zCiMK
IyBDT05GSUdfTVNET1NfRlMgaXMgbm90IHNldAojIENPTkZJR19WRkFUX0ZTIGlzIG5vdCBz
ZXQKQ09ORklHX05URlNfRlM9bQpDT05GSUdfTlRGU19ERUJVRz15CiMgQ09ORklHX05URlNf
UlcgaXMgbm90IHNldAoKIwojIFBzZXVkbyBmaWxlc3lzdGVtcwojCkNPTkZJR19QUk9DX0ZT
PXkKQ09ORklHX1BST0NfS0NPUkU9eQojIENPTkZJR19QUk9DX1ZNQ09SRSBpcyBub3Qgc2V0
CkNPTkZJR19QUk9DX1NZU0NUTD15CkNPTkZJR19QUk9DX1BBR0VfTU9OSVRPUj15CkNPTkZJ
R19TWVNGUz15CkNPTkZJR19UTVBGUz15CkNPTkZJR19UTVBGU19QT1NJWF9BQ0w9eQpDT05G
SUdfVE1QRlNfWEFUVFI9eQpDT05GSUdfSFVHRVRMQkZTPXkKQ09ORklHX0hVR0VUTEJfUEFH
RT15CkNPTkZJR19DT05GSUdGU19GUz1tCiMgQ09ORklHX01JU0NfRklMRVNZU1RFTVMgaXMg
bm90IHNldApDT05GSUdfTkVUV09SS19GSUxFU1lTVEVNUz15CkNPTkZJR19OQ1BfRlM9bQpD
T05GSUdfTkNQRlNfUEFDS0VUX1NJR05JTkc9eQpDT05GSUdfTkNQRlNfSU9DVExfTE9DS0lO
Rz15CkNPTkZJR19OQ1BGU19TVFJPTkc9eQojIENPTkZJR19OQ1BGU19ORlNfTlMgaXMgbm90
IHNldApDT05GSUdfTkNQRlNfT1MyX05TPXkKIyBDT05GSUdfTkNQRlNfU01BTExET1MgaXMg
bm90IHNldApDT05GSUdfTkNQRlNfTkxTPXkKIyBDT05GSUdfTkNQRlNfRVhUUkFTIGlzIG5v
dCBzZXQKCiMKIyBQYXJ0aXRpb24gVHlwZXMKIwpDT05GSUdfUEFSVElUSU9OX0FEVkFOQ0VE
PXkKIyBDT05GSUdfQUNPUk5fUEFSVElUSU9OIGlzIG5vdCBzZXQKIyBDT05GSUdfT1NGX1BB
UlRJVElPTiBpcyBub3Qgc2V0CiMgQ09ORklHX0FNSUdBX1BBUlRJVElPTiBpcyBub3Qgc2V0
CkNPTkZJR19BVEFSSV9QQVJUSVRJT049eQpDT05GSUdfTUFDX1BBUlRJVElPTj15CkNPTkZJ
R19NU0RPU19QQVJUSVRJT049eQpDT05GSUdfQlNEX0RJU0tMQUJFTD15CiMgQ09ORklHX01J
TklYX1NVQlBBUlRJVElPTiBpcyBub3Qgc2V0CkNPTkZJR19TT0xBUklTX1g4Nl9QQVJUSVRJ
T049eQpDT05GSUdfVU5JWFdBUkVfRElTS0xBQkVMPXkKQ09ORklHX0xETV9QQVJUSVRJT049
eQojIENPTkZJR19MRE1fREVCVUcgaXMgbm90IHNldApDT05GSUdfU0dJX1BBUlRJVElPTj15
CkNPTkZJR19VTFRSSVhfUEFSVElUSU9OPXkKIyBDT05GSUdfU1VOX1BBUlRJVElPTiBpcyBu
b3Qgc2V0CiMgQ09ORklHX0tBUk1BX1BBUlRJVElPTiBpcyBub3Qgc2V0CiMgQ09ORklHX0VG
SV9QQVJUSVRJT04gaXMgbm90IHNldAojIENPTkZJR19TWVNWNjhfUEFSVElUSU9OIGlzIG5v
dCBzZXQKQ09ORklHX05MUz15CkNPTkZJR19OTFNfREVGQVVMVD0iaXNvODg1OS0xIgpDT05G
SUdfTkxTX0NPREVQQUdFXzQzNz1tCkNPTkZJR19OTFNfQ09ERVBBR0VfNzM3PW0KIyBDT05G
SUdfTkxTX0NPREVQQUdFXzc3NSBpcyBub3Qgc2V0CkNPTkZJR19OTFNfQ09ERVBBR0VfODUw
PW0KIyBDT05GSUdfTkxTX0NPREVQQUdFXzg1MiBpcyBub3Qgc2V0CkNPTkZJR19OTFNfQ09E
RVBBR0VfODU1PW0KIyBDT05GSUdfTkxTX0NPREVQQUdFXzg1NyBpcyBub3Qgc2V0CkNPTkZJ
R19OTFNfQ09ERVBBR0VfODYwPW0KQ09ORklHX05MU19DT0RFUEFHRV84NjE9bQojIENPTkZJ
R19OTFNfQ09ERVBBR0VfODYyIGlzIG5vdCBzZXQKIyBDT05GSUdfTkxTX0NPREVQQUdFXzg2
MyBpcyBub3Qgc2V0CiMgQ09ORklHX05MU19DT0RFUEFHRV84NjQgaXMgbm90IHNldApDT05G
SUdfTkxTX0NPREVQQUdFXzg2NT1tCkNPTkZJR19OTFNfQ09ERVBBR0VfODY2PW0KIyBDT05G
SUdfTkxTX0NPREVQQUdFXzg2OSBpcyBub3Qgc2V0CkNPTkZJR19OTFNfQ09ERVBBR0VfOTM2
PW0KQ09ORklHX05MU19DT0RFUEFHRV85NTA9bQojIENPTkZJR19OTFNfQ09ERVBBR0VfOTMy
IGlzIG5vdCBzZXQKIyBDT05GSUdfTkxTX0NPREVQQUdFXzk0OSBpcyBub3Qgc2V0CkNPTkZJ
R19OTFNfQ09ERVBBR0VfODc0PW0KQ09ORklHX05MU19JU084ODU5Xzg9bQpDT05GSUdfTkxT
X0NPREVQQUdFXzEyNTA9bQpDT05GSUdfTkxTX0NPREVQQUdFXzEyNTE9bQpDT05GSUdfTkxT
X0FTQ0lJPW0KQ09ORklHX05MU19JU084ODU5XzE9bQpDT05GSUdfTkxTX0lTTzg4NTlfMj1t
CkNPTkZJR19OTFNfSVNPODg1OV8zPW0KQ09ORklHX05MU19JU084ODU5XzQ9bQojIENPTkZJ
R19OTFNfSVNPODg1OV81IGlzIG5vdCBzZXQKQ09ORklHX05MU19JU084ODU5XzY9bQpDT05G
SUdfTkxTX0lTTzg4NTlfNz1tCkNPTkZJR19OTFNfSVNPODg1OV85PW0KQ09ORklHX05MU19J
U084ODU5XzEzPW0KIyBDT05GSUdfTkxTX0lTTzg4NTlfMTQgaXMgbm90IHNldAojIENPTkZJ
R19OTFNfSVNPODg1OV8xNSBpcyBub3Qgc2V0CiMgQ09ORklHX05MU19LT0k4X1IgaXMgbm90
IHNldAojIENPTkZJR19OTFNfS09JOF9VIGlzIG5vdCBzZXQKQ09ORklHX05MU19VVEY4PW0K
CiMKIyBLZXJuZWwgaGFja2luZwojCkNPTkZJR19UUkFDRV9JUlFGTEFHU19TVVBQT1JUPXkK
IyBDT05GSUdfUFJJTlRLX1RJTUUgaXMgbm90IHNldApDT05GSUdfREVGQVVMVF9NRVNTQUdF
X0xPR0xFVkVMPTQKQ09ORklHX0VOQUJMRV9XQVJOX0RFUFJFQ0FURUQ9eQojIENPTkZJR19F
TkFCTEVfTVVTVF9DSEVDSyBpcyBub3Qgc2V0CkNPTkZJR19GUkFNRV9XQVJOPTIwNDgKIyBD
T05GSUdfTUFHSUNfU1lTUlEgaXMgbm90IHNldAojIENPTkZJR19TVFJJUF9BU01fU1lNUyBp
cyBub3Qgc2V0CkNPTkZJR19VTlVTRURfU1lNQk9MUz15CkNPTkZJR19ERUJVR19GUz15CkNP
TkZJR19IRUFERVJTX0NIRUNLPXkKIyBDT05GSUdfREVCVUdfU0VDVElPTl9NSVNNQVRDSCBp
cyBub3Qgc2V0CkNPTkZJR19ERUJVR19LRVJORUw9eQpDT05GSUdfREVCVUdfU0hJUlE9eQpD
T05GSUdfTE9DS1VQX0RFVEVDVE9SPXkKQ09ORklHX0hBUkRMT0NLVVBfREVURUNUT1I9eQoj
IENPTkZJR19CT09UUEFSQU1fSEFSRExPQ0tVUF9QQU5JQyBpcyBub3Qgc2V0CkNPTkZJR19C
T09UUEFSQU1fSEFSRExPQ0tVUF9QQU5JQ19WQUxVRT0wCkNPTkZJR19CT09UUEFSQU1fU09G
VExPQ0tVUF9QQU5JQz15CkNPTkZJR19CT09UUEFSQU1fU09GVExPQ0tVUF9QQU5JQ19WQUxV
RT0xCkNPTkZJR19ERVRFQ1RfSFVOR19UQVNLPXkKQ09ORklHX0RFRkFVTFRfSFVOR19UQVNL
X1RJTUVPVVQ9MTIwCkNPTkZJR19CT09UUEFSQU1fSFVOR19UQVNLX1BBTklDPXkKQ09ORklH
X0JPT1RQQVJBTV9IVU5HX1RBU0tfUEFOSUNfVkFMVUU9MQojIENPTkZJR19TQ0hFRF9ERUJV
RyBpcyBub3Qgc2V0CkNPTkZJR19TQ0hFRFNUQVRTPXkKIyBDT05GSUdfVElNRVJfU1RBVFMg
aXMgbm90IHNldApDT05GSUdfREVCVUdfT0JKRUNUUz15CiMgQ09ORklHX0RFQlVHX09CSkVD
VFNfU0VMRlRFU1QgaXMgbm90IHNldAojIENPTkZJR19ERUJVR19PQkpFQ1RTX0ZSRUUgaXMg
bm90IHNldAojIENPTkZJR19ERUJVR19PQkpFQ1RTX1RJTUVSUyBpcyBub3Qgc2V0CkNPTkZJ
R19ERUJVR19PQkpFQ1RTX1dPUks9eQojIENPTkZJR19ERUJVR19PQkpFQ1RTX1JDVV9IRUFE
IGlzIG5vdCBzZXQKQ09ORklHX0RFQlVHX09CSkVDVFNfUEVSQ1BVX0NPVU5URVI9eQpDT05G
SUdfREVCVUdfT0JKRUNUU19FTkFCTEVfREVGQVVMVD0xCkNPTkZJR19TTFVCX0RFQlVHX09O
PXkKIyBDT05GSUdfU0xVQl9TVEFUUyBpcyBub3Qgc2V0CkNPTkZJR19ERUJVR19QUkVFTVBU
PXkKQ09ORklHX0RFQlVHX1JUX01VVEVYRVM9eQpDT05GSUdfREVCVUdfUElfTElTVD15CiMg
Q09ORklHX1JUX01VVEVYX1RFU1RFUiBpcyBub3Qgc2V0CkNPTkZJR19ERUJVR19TUElOTE9D
Sz15CkNPTkZJR19ERUJVR19NVVRFWEVTPXkKQ09ORklHX0RFQlVHX0xPQ0tfQUxMT0M9eQoj
IENPTkZJR19QUk9WRV9MT0NLSU5HIGlzIG5vdCBzZXQKQ09ORklHX1NQQVJTRV9SQ1VfUE9J
TlRFUj15CkNPTkZJR19MT0NLREVQPXkKQ09ORklHX0xPQ0tfU1RBVD15CiMgQ09ORklHX0RF
QlVHX0xPQ0tERVAgaXMgbm90IHNldApDT05GSUdfVFJBQ0VfSVJRRkxBR1M9eQpDT05GSUdf
REVCVUdfQVRPTUlDX1NMRUVQPXkKQ09ORklHX0RFQlVHX0xPQ0tJTkdfQVBJX1NFTEZURVNU
Uz15CkNPTkZJR19TVEFDS1RSQUNFPXkKQ09ORklHX0RFQlVHX1NUQUNLX1VTQUdFPXkKIyBD
T05GSUdfREVCVUdfS09CSkVDVCBpcyBub3Qgc2V0CkNPTkZJR19ERUJVR19CVUdWRVJCT1NF
PXkKIyBDT05GSUdfREVCVUdfSU5GTyBpcyBub3Qgc2V0CkNPTkZJR19ERUJVR19WTT15CiMg
Q09ORklHX0RFQlVHX1ZJUlRVQUwgaXMgbm90IHNldAojIENPTkZJR19ERUJVR19XUklURUNP
VU5UIGlzIG5vdCBzZXQKQ09ORklHX0RFQlVHX01FTU9SWV9JTklUPXkKIyBDT05GSUdfREVC
VUdfTElTVCBpcyBub3Qgc2V0CkNPTkZJR19URVNUX0xJU1RfU09SVD15CiMgQ09ORklHX0RF
QlVHX1NHIGlzIG5vdCBzZXQKIyBDT05GSUdfREVCVUdfTk9USUZJRVJTIGlzIG5vdCBzZXQK
IyBDT05GSUdfREVCVUdfQ1JFREVOVElBTFMgaXMgbm90IHNldApDT05GSUdfQVJDSF9XQU5U
X0ZSQU1FX1BPSU5URVJTPXkKQ09ORklHX0ZSQU1FX1BPSU5URVI9eQojIENPTkZJR19CT09U
X1BSSU5US19ERUxBWSBpcyBub3Qgc2V0CiMgQ09ORklHX1JDVV9UT1JUVVJFX1RFU1QgaXMg
bm90IHNldAojIENPTkZJR19CQUNLVFJBQ0VfU0VMRl9URVNUIGlzIG5vdCBzZXQKQ09ORklH
X0RFQlVHX0JMT0NLX0VYVF9ERVZUPXkKIyBDT05GSUdfREVCVUdfRk9SQ0VfV0VBS19QRVJf
Q1BVIGlzIG5vdCBzZXQKQ09ORklHX0xLRFRNPW0KQ09ORklHX0ZBVUxUX0lOSkVDVElPTj15
CiMgQ09ORklHX0ZBSUxTTEFCIGlzIG5vdCBzZXQKQ09ORklHX0ZBSUxfUEFHRV9BTExPQz15
CkNPTkZJR19GQUlMX01BS0VfUkVRVUVTVD15CkNPTkZJR19GQUlMX0lPX1RJTUVPVVQ9eQpD
T05GSUdfRkFJTF9NTUNfUkVRVUVTVD15CiMgQ09ORklHX0ZBVUxUX0lOSkVDVElPTl9ERUJV
R19GUyBpcyBub3Qgc2V0CiMgQ09ORklHX0xBVEVOQ1lUT1AgaXMgbm90IHNldApDT05GSUdf
U1lTQ1RMX1NZU0NBTExfQ0hFQ0s9eQpDT05GSUdfREVCVUdfUEFHRUFMTE9DPXkKQ09ORklH
X1dBTlRfUEFHRV9ERUJVR19GTEFHUz15CkNPTkZJR19QQUdFX0dVQVJEPXkKQ09ORklHX1VT
RVJfU1RBQ0tUUkFDRV9TVVBQT1JUPXkKQ09ORklHX05PUF9UUkFDRVI9eQpDT05GSUdfSEFW
RV9GVU5DVElPTl9UUkFDRVI9eQpDT05GSUdfSEFWRV9GVU5DVElPTl9HUkFQSF9UUkFDRVI9
eQpDT05GSUdfSEFWRV9GVU5DVElPTl9HUkFQSF9GUF9URVNUPXkKQ09ORklHX0hBVkVfRlVO
Q1RJT05fVFJBQ0VfTUNPVU5UX1RFU1Q9eQpDT05GSUdfSEFWRV9EWU5BTUlDX0ZUUkFDRT15
CkNPTkZJR19IQVZFX0ZUUkFDRV9NQ09VTlRfUkVDT1JEPXkKQ09ORklHX0hBVkVfU1lTQ0FM
TF9UUkFDRVBPSU5UUz15CkNPTkZJR19IQVZFX0NfUkVDT1JETUNPVU5UPXkKQ09ORklHX1RS
QUNFUl9NQVhfVFJBQ0U9eQpDT05GSUdfUklOR19CVUZGRVI9eQpDT05GSUdfRVZFTlRfVFJB
Q0lORz15CiMgQ09ORklHX0VWRU5UX1BPV0VSX1RSQUNJTkdfREVQUkVDQVRFRCBpcyBub3Qg
c2V0CkNPTkZJR19DT05URVhUX1NXSVRDSF9UUkFDRVI9eQpDT05GSUdfUklOR19CVUZGRVJf
QUxMT1dfU1dBUD15CkNPTkZJR19UUkFDSU5HPXkKQ09ORklHX0dFTkVSSUNfVFJBQ0VSPXkK
Q09ORklHX1RSQUNJTkdfU1VQUE9SVD15CkNPTkZJR19GVFJBQ0U9eQojIENPTkZJR19GVU5D
VElPTl9UUkFDRVIgaXMgbm90IHNldApDT05GSUdfSVJRU09GRl9UUkFDRVI9eQojIENPTkZJ
R19QUkVFTVBUX1RSQUNFUiBpcyBub3Qgc2V0CiMgQ09ORklHX1NDSEVEX1RSQUNFUiBpcyBu
b3Qgc2V0CiMgQ09ORklHX0ZUUkFDRV9TWVNDQUxMUyBpcyBub3Qgc2V0CkNPTkZJR19UUkFD
RV9CUkFOQ0hfUFJPRklMSU5HPXkKIyBDT05GSUdfQlJBTkNIX1BST0ZJTEVfTk9ORSBpcyBu
b3Qgc2V0CiMgQ09ORklHX1BST0ZJTEVfQU5OT1RBVEVEX0JSQU5DSEVTIGlzIG5vdCBzZXQK
Q09ORklHX1BST0ZJTEVfQUxMX0JSQU5DSEVTPXkKQ09ORklHX1RSQUNJTkdfQlJBTkNIRVM9
eQpDT05GSUdfQlJBTkNIX1RSQUNFUj15CiMgQ09ORklHX1NUQUNLX1RSQUNFUiBpcyBub3Qg
c2V0CiMgQ09ORklHX0JMS19ERVZfSU9fVFJBQ0UgaXMgbm90IHNldAojIENPTkZJR19VUFJP
QkVfRVZFTlQgaXMgbm90IHNldAojIENPTkZJR19QUk9CRV9FVkVOVFMgaXMgbm90IHNldApD
T05GSUdfRlRSQUNFX1NFTEZURVNUPXkKQ09ORklHX0ZUUkFDRV9TVEFSVFVQX1RFU1Q9eQoj
IENPTkZJR19FVkVOVF9UUkFDRV9URVNUX1NZU0NBTExTIGlzIG5vdCBzZXQKIyBDT05GSUdf
UklOR19CVUZGRVJfQkVOQ0hNQVJLIGlzIG5vdCBzZXQKQ09ORklHX0JVSUxEX0RPQ1NSQz15
CiMgQ09ORklHX0RZTkFNSUNfREVCVUcgaXMgbm90IHNldAojIENPTkZJR19ETUFfQVBJX0RF
QlVHIGlzIG5vdCBzZXQKIyBDT05GSUdfQVRPTUlDNjRfU0VMRlRFU1QgaXMgbm90IHNldApD
T05GSUdfU0FNUExFUz15CkNPTkZJR19TQU1QTEVfVFJBQ0VQT0lOVFM9bQojIENPTkZJR19T
QU1QTEVfVFJBQ0VfRVZFTlRTIGlzIG5vdCBzZXQKIyBDT05GSUdfU0FNUExFX0tPQkpFQ1Qg
aXMgbm90IHNldAojIENPTkZJR19TQU1QTEVfSFdfQlJFQUtQT0lOVCBpcyBub3Qgc2V0CkNP
TkZJR19TQU1QTEVfS0ZJRk89bQpDT05GSUdfSEFWRV9BUkNIX0tHREI9eQpDT05GSUdfSEFW
RV9BUkNIX0tNRU1DSEVDSz15CiMgQ09ORklHX1RFU1RfS1NUUlRPWCBpcyBub3Qgc2V0CkNP
TkZJR19TVFJJQ1RfREVWTUVNPXkKIyBDT05GSUdfWDg2X1ZFUkJPU0VfQk9PVFVQIGlzIG5v
dCBzZXQKQ09ORklHX0VBUkxZX1BSSU5USz15CiMgQ09ORklHX0RFQlVHX1NUQUNLT1ZFUkZM
T1cgaXMgbm90IHNldApDT05GSUdfWDg2X1BURFVNUD15CiMgQ09ORklHX0RFQlVHX1JPREFU
QSBpcyBub3Qgc2V0CkNPTkZJR19ERUJVR19TRVRfTU9EVUxFX1JPTlg9eQpDT05GSUdfREVC
VUdfTlhfVEVTVD1tCiMgQ09ORklHX0lPTU1VX1NUUkVTUyBpcyBub3Qgc2V0CkNPTkZJR19I
QVZFX01NSU9UUkFDRV9TVVBQT1JUPXkKQ09ORklHX0lPX0RFTEFZX1RZUEVfMFg4MD0wCkNP
TkZJR19JT19ERUxBWV9UWVBFXzBYRUQ9MQpDT05GSUdfSU9fREVMQVlfVFlQRV9VREVMQVk9
MgpDT05GSUdfSU9fREVMQVlfVFlQRV9OT05FPTMKQ09ORklHX0lPX0RFTEFZXzBYODA9eQoj
IENPTkZJR19JT19ERUxBWV8wWEVEIGlzIG5vdCBzZXQKIyBDT05GSUdfSU9fREVMQVlfVURF
TEFZIGlzIG5vdCBzZXQKIyBDT05GSUdfSU9fREVMQVlfTk9ORSBpcyBub3Qgc2V0CkNPTkZJ
R19ERUZBVUxUX0lPX0RFTEFZX1RZUEU9MApDT05GSUdfREVCVUdfQk9PVF9QQVJBTVM9eQpD
T05GSUdfQ1BBX0RFQlVHPXkKQ09ORklHX09QVElNSVpFX0lOTElOSU5HPXkKIyBDT05GSUdf
REVCVUdfTk1JX1NFTEZURVNUIGlzIG5vdCBzZXQKCiMKIyBTZWN1cml0eSBvcHRpb25zCiMK
Q09ORklHX0tFWVM9eQojIENPTkZJR19FTkNSWVBURURfS0VZUyBpcyBub3Qgc2V0CiMgQ09O
RklHX0tFWVNfREVCVUdfUFJPQ19LRVlTIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VDVVJJVFlf
RE1FU0dfUkVTVFJJQ1QgaXMgbm90IHNldAojIENPTkZJR19TRUNVUklUWSBpcyBub3Qgc2V0
CkNPTkZJR19TRUNVUklUWUZTPXkKQ09ORklHX0RFRkFVTFRfU0VDVVJJVFlfREFDPXkKQ09O
RklHX0RFRkFVTFRfU0VDVVJJVFk9IiIKQ09ORklHX0NSWVBUTz1tCgojCiMgQ3J5cHRvIGNv
cmUgb3IgaGVscGVyCiMKQ09ORklHX0NSWVBUT19BTEdBUEk9bQpDT05GSUdfQ1JZUFRPX0FM
R0FQSTI9bQpDT05GSUdfQ1JZUFRPX0FFQUQ9bQpDT05GSUdfQ1JZUFRPX0FFQUQyPW0KQ09O
RklHX0NSWVBUT19CTEtDSVBIRVI9bQpDT05GSUdfQ1JZUFRPX0JMS0NJUEhFUjI9bQpDT05G
SUdfQ1JZUFRPX0hBU0g9bQpDT05GSUdfQ1JZUFRPX0hBU0gyPW0KQ09ORklHX0NSWVBUT19S
Tkc9bQpDT05GSUdfQ1JZUFRPX1JORzI9bQpDT05GSUdfQ1JZUFRPX1BDT01QPW0KQ09ORklH
X0NSWVBUT19QQ09NUDI9bQpDT05GSUdfQ1JZUFRPX01BTkFHRVI9bQpDT05GSUdfQ1JZUFRP
X01BTkFHRVIyPW0KIyBDT05GSUdfQ1JZUFRPX1VTRVIgaXMgbm90IHNldApDT05GSUdfQ1JZ
UFRPX01BTkFHRVJfRElTQUJMRV9URVNUUz15CkNPTkZJR19DUllQVE9fR0YxMjhNVUw9bQoj
IENPTkZJR19DUllQVE9fTlVMTCBpcyBub3Qgc2V0CkNPTkZJR19DUllQVE9fV09SS1FVRVVF
PW0KQ09ORklHX0NSWVBUT19DUllQVEQ9bQojIENPTkZJR19DUllQVE9fQVVUSEVOQyBpcyBu
b3Qgc2V0CiMgQ09ORklHX0NSWVBUT19URVNUIGlzIG5vdCBzZXQKCiMKIyBBdXRoZW50aWNh
dGVkIEVuY3J5cHRpb24gd2l0aCBBc3NvY2lhdGVkIERhdGEKIwojIENPTkZJR19DUllQVE9f
Q0NNIGlzIG5vdCBzZXQKIyBDT05GSUdfQ1JZUFRPX0dDTSBpcyBub3Qgc2V0CkNPTkZJR19D
UllQVE9fU0VRSVY9bQoKIwojIEJsb2NrIG1vZGVzCiMKQ09ORklHX0NSWVBUT19DQkM9bQoj
IENPTkZJR19DUllQVE9fQ1RSIGlzIG5vdCBzZXQKQ09ORklHX0NSWVBUT19DVFM9bQojIENP
TkZJR19DUllQVE9fRUNCIGlzIG5vdCBzZXQKIyBDT05GSUdfQ1JZUFRPX1BDQkMgaXMgbm90
IHNldAoKIwojIEhhc2ggbW9kZXMKIwpDT05GSUdfQ1JZUFRPX0hNQUM9bQoKIwojIERpZ2Vz
dAojCkNPTkZJR19DUllQVE9fQ1JDMzJDPW0KQ09ORklHX0NSWVBUT19DUkMzMkNfSU5URUw9
bQpDT05GSUdfQ1JZUFRPX0dIQVNIPW0KQ09ORklHX0NSWVBUT19NRDQ9bQpDT05GSUdfQ1JZ
UFRPX01ENT1tCkNPTkZJR19DUllQVE9fTUlDSEFFTF9NSUM9bQpDT05GSUdfQ1JZUFRPX1JN
RDEyOD1tCkNPTkZJR19DUllQVE9fUk1EMTYwPW0KIyBDT05GSUdfQ1JZUFRPX1JNRDI1NiBp
cyBub3Qgc2V0CkNPTkZJR19DUllQVE9fUk1EMzIwPW0KQ09ORklHX0NSWVBUT19TSEExPW0K
Q09ORklHX0NSWVBUT19TSEExX1NTU0UzPW0KIyBDT05GSUdfQ1JZUFRPX1NIQTI1NiBpcyBu
b3Qgc2V0CkNPTkZJR19DUllQVE9fU0hBNTEyPW0KQ09ORklHX0NSWVBUT19UR1IxOTI9bQoj
IENPTkZJR19DUllQVE9fV1A1MTIgaXMgbm90IHNldApDT05GSUdfQ1JZUFRPX0dIQVNIX0NM
TVVMX05JX0lOVEVMPW0KCiMKIyBDaXBoZXJzCiMKQ09ORklHX0NSWVBUT19BRVM9bQpDT05G
SUdfQ1JZUFRPX0FFU19YODZfNjQ9bQpDT05GSUdfQ1JZUFRPX0FFU19OSV9JTlRFTD1tCkNP
TkZJR19DUllQVE9fQU5VQklTPW0KQ09ORklHX0NSWVBUT19BUkM0PW0KIyBDT05GSUdfQ1JZ
UFRPX0JMT1dGSVNIIGlzIG5vdCBzZXQKIyBDT05GSUdfQ1JZUFRPX0JMT1dGSVNIX1g4Nl82
NCBpcyBub3Qgc2V0CiMgQ09ORklHX0NSWVBUT19DQU1FTExJQSBpcyBub3Qgc2V0CiMgQ09O
RklHX0NSWVBUT19DQVNUNSBpcyBub3Qgc2V0CiMgQ09ORklHX0NSWVBUT19DQVNUNiBpcyBu
b3Qgc2V0CkNPTkZJR19DUllQVE9fREVTPW0KQ09ORklHX0NSWVBUT19GQ1JZUFQ9bQpDT05G
SUdfQ1JZUFRPX0tIQVpBRD1tCiMgQ09ORklHX0NSWVBUT19TRUVEIGlzIG5vdCBzZXQKQ09O
RklHX0NSWVBUT19TRVJQRU5UPW0KIyBDT05GSUdfQ1JZUFRPX1NFUlBFTlRfU1NFMl9YODZf
NjQgaXMgbm90IHNldApDT05GSUdfQ1JZUFRPX1RFQT1tCkNPTkZJR19DUllQVE9fVFdPRklT
SD1tCkNPTkZJR19DUllQVE9fVFdPRklTSF9DT01NT049bQpDT05GSUdfQ1JZUFRPX1RXT0ZJ
U0hfWDg2XzY0PW0KIyBDT05GSUdfQ1JZUFRPX1RXT0ZJU0hfWDg2XzY0XzNXQVkgaXMgbm90
IHNldAoKIwojIENvbXByZXNzaW9uCiMKQ09ORklHX0NSWVBUT19ERUZMQVRFPW0KQ09ORklH
X0NSWVBUT19aTElCPW0KQ09ORklHX0NSWVBUT19MWk89bQoKIwojIFJhbmRvbSBOdW1iZXIg
R2VuZXJhdGlvbgojCkNPTkZJR19DUllQVE9fQU5TSV9DUFJORz1tCiMgQ09ORklHX0NSWVBU
T19VU0VSX0FQSV9IQVNIIGlzIG5vdCBzZXQKIyBDT05GSUdfQ1JZUFRPX1VTRVJfQVBJX1NL
Q0lQSEVSIGlzIG5vdCBzZXQKQ09ORklHX0NSWVBUT19IVz15CiMgQ09ORklHX0NSWVBUT19E
RVZfUEFETE9DSyBpcyBub3Qgc2V0CkNPTkZJR19IQVZFX0tWTT15CiMgQ09ORklHX1ZJUlRV
QUxJWkFUSU9OIGlzIG5vdCBzZXQKQ09ORklHX0JJTkFSWV9QUklOVEY9eQoKIwojIExpYnJh
cnkgcm91dGluZXMKIwpDT05GSUdfQklUUkVWRVJTRT15CkNPTkZJR19HRU5FUklDX0ZJTkRf
RklSU1RfQklUPXkKQ09ORklHX0dFTkVSSUNfUENJX0lPTUFQPXkKQ09ORklHX0dFTkVSSUNf
SU9NQVA9eQpDT05GSUdfQ1JDX0NDSVRUPW0KQ09ORklHX0NSQzE2PW0KQ09ORklHX0NSQ19U
MTBESUY9bQpDT05GSUdfQ1JDX0lUVV9UPW0KQ09ORklHX0NSQzMyPXkKQ09ORklHX0NSQzc9
bQojIENPTkZJR19MSUJDUkMzMkMgaXMgbm90IHNldApDT05GSUdfQ1JDOD1tCkNPTkZJR19a
TElCX0lORkxBVEU9eQpDT05GSUdfWkxJQl9ERUZMQVRFPW0KQ09ORklHX0xaT19DT01QUkVT
Uz15CkNPTkZJR19MWk9fREVDT01QUkVTUz15CkNPTkZJR19YWl9ERUM9eQpDT05GSUdfWFpf
REVDX1g4Nj15CkNPTkZJR19YWl9ERUNfUE9XRVJQQz15CkNPTkZJR19YWl9ERUNfSUE2ND15
CkNPTkZJR19YWl9ERUNfQVJNPXkKQ09ORklHX1haX0RFQ19BUk1USFVNQj15CkNPTkZJR19Y
Wl9ERUNfU1BBUkM9eQpDT05GSUdfWFpfREVDX0JDSj15CiMgQ09ORklHX1haX0RFQ19URVNU
IGlzIG5vdCBzZXQKQ09ORklHX0RFQ09NUFJFU1NfR1pJUD15CkNPTkZJR19ERUNPTVBSRVNT
X0JaSVAyPXkKQ09ORklHX0RFQ09NUFJFU1NfTFpNQT15CkNPTkZJR19ERUNPTVBSRVNTX1ha
PXkKQ09ORklHX0RFQ09NUFJFU1NfTFpPPXkKQ09ORklHX0JDSD1tCkNPTkZJR19IQVNfSU9N
RU09eQpDT05GSUdfSEFTX0lPUE9SVD15CkNPTkZJR19IQVNfRE1BPXkKQ09ORklHX0RRTD15
CkNPTkZJR19OTEFUVFI9eQpDT05GSUdfQVZFUkFHRT15CiMgQ09ORklHX0NPUkRJQyBpcyBu
b3Qgc2V0CkNPTkZJR19NUElMSUI9bQojIENPTkZJR19NUElMSUJfRVhUUkEgaXMgbm90IHNl
dAojIENPTkZJR19ESUdTSUcgaXMgbm90IHNldAo=
--------------060000020604020105080200
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--------------060000020604020105080200--


From xen-devel-bounces@lists.xensource.com Mon Dec 19 19:39:02 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 19:39:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rcj2m-00057e-Ve; Mon, 19 Dec 2011 19:38:40 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <rdunlap@xenotime.net>) id 1Rcj2l-00057U-1n
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 19:38:39 +0000
X-Env-Sender: rdunlap@xenotime.net
X-Msg-Ref: server-15.tower-182.messagelabs.com!1324323510!7833103!1
X-Originating-IP: [67.222.38.55]
X-SpamReason: No, hits=3.5 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA2Ny4yMjIuMzguNTUgPT4gMzMwMDQ=\n,sa_preprocessor: 
	QmFkIElQOiA2Ny4yMjIuMzguNTUgPT4gMzMwMDQ=\n, UNIQUE_WORDS,
	UPPERCASE_75_100
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 991 invoked from network); 19 Dec 2011 19:38:30 -0000
Received: from oproxy5-pub.bluehost.com (HELO oproxy5-pub.bluehost.com)
	(67.222.38.55) by server-15.tower-182.messagelabs.com with SMTP;
	19 Dec 2011 19:38:30 -0000
Received: (qmail 16745 invoked by uid 0); 19 Dec 2011 19:31:50 -0000
Received: from unknown (HELO box742.bluehost.com) (66.147.244.242)
	by cpoproxy2.bluehost.com with SMTP; 19 Dec 2011 19:31:50 -0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenotime.net;
	s=default; 
	h=Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID;
	bh=cLp+L9e2czxI57os8kHEYYxgtMG6DKNyh5ed1GALl5o=; 
	b=WQJRO5Z3VRwXZdPm+mXqy2RY41mLu5J2T/QvLf46baWlt1lGRniPVbeIHP9QIJgorgZeTAmk8EKCI7gRYCMoHKB+G53yvNHodVQ1SlWucpTeLGlGGXBAR7rXDAGMorty;
Received: from static-50-53-38-135.bvtn.or.frontiernet.net ([50.53.38.135]
	helo=[192.168.1.3])
	by box742.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256)
	(Exim 4.76) (envelope-from <rdunlap@xenotime.net>)
	id 1RciwA-0003vh-1G; Mon, 19 Dec 2011 12:31:50 -0700
Message-ID: <4EEF9F44.8080707@xenotime.net>
Date: Mon, 19 Dec 2011 12:32:04 -0800
From: Randy Dunlap <rdunlap@xenotime.net>
Organization: YPO4
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.15) Gecko/20110323 Thunderbird/3.1.9
MIME-Version: 1.0
To: Stephen Rothwell <sfr@canb.auug.org.au>
References: <20111219185556.f07c1f43e28cfd594aaa5fe0@canb.auug.org.au>
In-Reply-To: <20111219185556.f07c1f43e28cfd594aaa5fe0@canb.auug.org.au>
Content-Type: multipart/mixed; boundary="------------060000020604020105080200"
X-Identified-User: {1807:box742.bluehost.com:xenotime:xenotime.net}
	{sentby:smtp auth 50.53.38.135 authed with
	rdunlap@xenotime.net}
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	LKML <linux-kernel@vger.kernel.org>,
	Linux Virtualization <virtualization@lists.linux-foundation.org>,
	linux-next@vger.kernel.org
Subject: Re: [Xen-devel] linux-next: Tree for Dec 19 (xen)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a multi-part message in MIME format.
--------------060000020604020105080200
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 12/18/2011 11:55 PM, Stephen Rothwell wrote:
> Hi all,
> 
> Changes since 20111216:


drivers/xen/xenbus/xenbus_dev_frontend.c: In function 'xenbus_init':
drivers/xen/xenbus/xenbus_dev_frontend.c:609:2: error: implicit declaration of function 'xen_domain'

Full randconfig file is attached.

-- 
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***

--------------060000020604020105080200
Content-Type: text/plain;
 name="config-r3441"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename="config-r3441"

IwojIEF1dG9tYXRpY2FsbHkgZ2VuZXJhdGVkIGZpbGU7IERPIE5PVCBFRElULgojIExpbnV4
L3g4Nl82NCAzLjIuMC1yYzYgS2VybmVsIENvbmZpZ3VyYXRpb24KIwpDT05GSUdfNjRCSVQ9
eQojIENPTkZJR19YODZfMzIgaXMgbm90IHNldApDT05GSUdfWDg2XzY0PXkKQ09ORklHX1g4
Nj15CkNPTkZJR19JTlNUUlVDVElPTl9ERUNPREVSPXkKQ09ORklHX09VVFBVVF9GT1JNQVQ9
ImVsZjY0LXg4Ni02NCIKQ09ORklHX0FSQ0hfREVGQ09ORklHPSJhcmNoL3g4Ni9jb25maWdz
L3g4Nl82NF9kZWZjb25maWciCkNPTkZJR19HRU5FUklDX0NNT1NfVVBEQVRFPXkKQ09ORklH
X0NMT0NLU09VUkNFX1dBVENIRE9HPXkKQ09ORklHX0dFTkVSSUNfQ0xPQ0tFVkVOVFM9eQpD
T05GSUdfQVJDSF9DTE9DS1NPVVJDRV9EQVRBPXkKQ09ORklHX0dFTkVSSUNfQ0xPQ0tFVkVO
VFNfQlJPQURDQVNUPXkKQ09ORklHX0xPQ0tERVBfU1VQUE9SVD15CkNPTkZJR19TVEFDS1RS
QUNFX1NVUFBPUlQ9eQpDT05GSUdfSEFWRV9MQVRFTkNZVE9QX1NVUFBPUlQ9eQpDT05GSUdf
TU1VPXkKQ09ORklHX1pPTkVfRE1BPXkKQ09ORklHX05FRURfRE1BX01BUF9TVEFURT15CkNP
TkZJR19ORUVEX1NHX0RNQV9MRU5HVEg9eQpDT05GSUdfR0VORVJJQ19JU0FfRE1BPXkKQ09O
RklHX0dFTkVSSUNfQlVHPXkKQ09ORklHX0dFTkVSSUNfQlVHX1JFTEFUSVZFX1BPSU5URVJT
PXkKQ09ORklHX0dFTkVSSUNfSFdFSUdIVD15CkNPTkZJR19BUkNIX01BWV9IQVZFX1BDX0ZE
Qz15CiMgQ09ORklHX1JXU0VNX0dFTkVSSUNfU1BJTkxPQ0sgaXMgbm90IHNldApDT05GSUdf
UldTRU1fWENIR0FERF9BTEdPUklUSE09eQpDT05GSUdfQVJDSF9IQVNfQ1BVX0lETEVfV0FJ
VD15CkNPTkZJR19HRU5FUklDX0NBTElCUkFURV9ERUxBWT15CkNPTkZJR19HRU5FUklDX1RJ
TUVfVlNZU0NBTEw9eQpDT05GSUdfQVJDSF9IQVNfQ1BVX1JFTEFYPXkKQ09ORklHX0FSQ0hf
SEFTX0RFRkFVTFRfSURMRT15CkNPTkZJR19BUkNIX0hBU19DQUNIRV9MSU5FX1NJWkU9eQpD
T05GSUdfSEFWRV9TRVRVUF9QRVJfQ1BVX0FSRUE9eQpDT05GSUdfTkVFRF9QRVJfQ1BVX0VN
QkVEX0ZJUlNUX0NIVU5LPXkKQ09ORklHX05FRURfUEVSX0NQVV9QQUdFX0ZJUlNUX0NIVU5L
PXkKQ09ORklHX0FSQ0hfSElCRVJOQVRJT05fUE9TU0lCTEU9eQpDT05GSUdfQVJDSF9TVVNQ
RU5EX1BPU1NJQkxFPXkKQ09ORklHX1pPTkVfRE1BMzI9eQpDT05GSUdfQVVESVRfQVJDSD15
CkNPTkZJR19BUkNIX1NVUFBPUlRTX09QVElNSVpFRF9JTkxJTklORz15CkNPTkZJR19BUkNI
X1NVUFBPUlRTX0RFQlVHX1BBR0VBTExPQz15CkNPTkZJR19BUkNIX0hXRUlHSFRfQ0ZMQUdT
PSItZmNhbGwtc2F2ZWQtcmRpIC1mY2FsbC1zYXZlZC1yc2kgLWZjYWxsLXNhdmVkLXJkeCAt
ZmNhbGwtc2F2ZWQtcmN4IC1mY2FsbC1zYXZlZC1yOCAtZmNhbGwtc2F2ZWQtcjkgLWZjYWxs
LXNhdmVkLXIxMCAtZmNhbGwtc2F2ZWQtcjExIgojIENPTkZJR19LVElNRV9TQ0FMQVIgaXMg
bm90IHNldApDT05GSUdfQVJDSF9TVVBQT1JUU19VUFJPQkVTPXkKQ09ORklHX0RFRkNPTkZJ
R19MSVNUPSIvbGliL21vZHVsZXMvJFVOQU1FX1JFTEVBU0UvLmNvbmZpZyIKQ09ORklHX0hB
VkVfSVJRX1dPUks9eQpDT05GSUdfSVJRX1dPUks9eQoKIwojIEdlbmVyYWwgc2V0dXAKIwoj
IENPTkZJR19FWFBFUklNRU5UQUwgaXMgbm90IHNldApDT05GSUdfQlJPS0VOX09OX1NNUD15
CkNPTkZJR19JTklUX0VOVl9BUkdfTElNSVQ9MzIKQ09ORklHX0NST1NTX0NPTVBJTEU9IiIK
Q09ORklHX0xPQ0FMVkVSU0lPTj0iIgpDT05GSUdfTE9DQUxWRVJTSU9OX0FVVE89eQpDT05G
SUdfSEFWRV9LRVJORUxfR1pJUD15CkNPTkZJR19IQVZFX0tFUk5FTF9CWklQMj15CkNPTkZJ
R19IQVZFX0tFUk5FTF9MWk1BPXkKQ09ORklHX0hBVkVfS0VSTkVMX1haPXkKQ09ORklHX0hB
VkVfS0VSTkVMX0xaTz15CiMgQ09ORklHX0tFUk5FTF9HWklQIGlzIG5vdCBzZXQKIyBDT05G
SUdfS0VSTkVMX0JaSVAyIGlzIG5vdCBzZXQKIyBDT05GSUdfS0VSTkVMX0xaTUEgaXMgbm90
IHNldAojIENPTkZJR19LRVJORUxfWFogaXMgbm90IHNldApDT05GSUdfS0VSTkVMX0xaTz15
CkNPTkZJR19ERUZBVUxUX0hPU1ROQU1FPSIobm9uZSkiCiMgQ09ORklHX1NXQVAgaXMgbm90
IHNldApDT05GSUdfU1lTVklQQz15CkNPTkZJR19TWVNWSVBDX1NZU0NUTD15CiMgQ09ORklH
X0JTRF9QUk9DRVNTX0FDQ1QgaXMgbm90IHNldApDT05GSUdfRkhBTkRMRT15CiMgQ09ORklH
X1RBU0tTVEFUUyBpcyBub3Qgc2V0CkNPTkZJR19BVURJVD15CkNPTkZJR19BVURJVFNZU0NB
TEw9eQpDT05GSUdfQVVESVRfV0FUQ0g9eQpDT05GSUdfQVVESVRfVFJFRT15CkNPTkZJR19I
QVZFX0dFTkVSSUNfSEFSRElSUVM9eQoKIwojIElSUSBzdWJzeXN0ZW0KIwpDT05GSUdfR0VO
RVJJQ19IQVJESVJRUz15CkNPTkZJR19IQVZFX1NQQVJTRV9JUlE9eQpDT05GSUdfR0VORVJJ
Q19JUlFfUFJPQkU9eQpDT05GSUdfR0VORVJJQ19JUlFfU0hPVz15CkNPTkZJR19JUlFfRk9S
Q0VEX1RIUkVBRElORz15CkNPTkZJR19TUEFSU0VfSVJRPXkKCiMKIyBSQ1UgU3Vic3lzdGVt
CiMKQ09ORklHX1RJTllfUFJFRU1QVF9SQ1U9eQpDT05GSUdfUFJFRU1QVF9SQ1U9eQpDT05G
SUdfUkNVX1RSQUNFPXkKIyBDT05GSUdfVFJFRV9SQ1VfVFJBQ0UgaXMgbm90IHNldApDT05G
SUdfUkNVX0JPT1NUPXkKQ09ORklHX1JDVV9CT09TVF9QUklPPTEKQ09ORklHX1JDVV9CT09T
VF9ERUxBWT01MDAKIyBDT05GSUdfSUtDT05GSUcgaXMgbm90IHNldApDT05GSUdfTE9HX0JV
Rl9TSElGVD0xNwpDT05GSUdfSEFWRV9VTlNUQUJMRV9TQ0hFRF9DTE9DSz15CkNPTkZJR19D
R1JPVVBTPXkKQ09ORklHX0NHUk9VUF9ERUJVRz15CkNPTkZJR19DR1JPVVBfRlJFRVpFUj15
CiMgQ09ORklHX0NHUk9VUF9ERVZJQ0UgaXMgbm90IHNldApDT05GSUdfQ1BVU0VUUz15CiMg
Q09ORklHX1BST0NfUElEX0NQVVNFVCBpcyBub3Qgc2V0CkNPTkZJR19DR1JPVVBfQ1BVQUND
VD15CkNPTkZJR19SRVNPVVJDRV9DT1VOVEVSUz15CiMgQ09ORklHX0NHUk9VUF9NRU1fUkVT
X0NUTFIgaXMgbm90IHNldApDT05GSUdfQ0dST1VQX1BFUkY9eQpDT05GSUdfQ0dST1VQX1ND
SEVEPXkKQ09ORklHX0ZBSVJfR1JPVVBfU0NIRUQ9eQojIENPTkZJR19CTEtfQ0dST1VQIGlz
IG5vdCBzZXQKIyBDT05GSUdfQ0hFQ0tQT0lOVF9SRVNUT1JFIGlzIG5vdCBzZXQKQ09ORklH
X05BTUVTUEFDRVM9eQpDT05GSUdfVVRTX05TPXkKQ09ORklHX0lQQ19OUz15CiMgQ09ORklH
X1BJRF9OUyBpcyBub3Qgc2V0CiMgQ09ORklHX05FVF9OUyBpcyBub3Qgc2V0CkNPTkZJR19T
Q0hFRF9BVVRPR1JPVVA9eQojIENPTkZJR19TWVNGU19ERVBSRUNBVEVEIGlzIG5vdCBzZXQK
Q09ORklHX1JFTEFZPXkKQ09ORklHX0JMS19ERVZfSU5JVFJEPXkKQ09ORklHX0lOSVRSQU1G
U19TT1VSQ0U9IiIKQ09ORklHX1JEX0daSVA9eQpDT05GSUdfUkRfQlpJUDI9eQpDT05GSUdf
UkRfTFpNQT15CkNPTkZJR19SRF9YWj15CkNPTkZJR19SRF9MWk89eQpDT05GSUdfQ0NfT1BU
SU1JWkVfRk9SX1NJWkU9eQpDT05GSUdfU1lTQ1RMPXkKQ09ORklHX0FOT05fSU5PREVTPXkK
IyBDT05GSUdfRVhQRVJUIGlzIG5vdCBzZXQKQ09ORklHX1VJRDE2PXkKIyBDT05GSUdfU1lT
Q1RMX1NZU0NBTEwgaXMgbm90IHNldApDT05GSUdfS0FMTFNZTVM9eQpDT05GSUdfS0FMTFNZ
TVNfQUxMPXkKQ09ORklHX0hPVFBMVUc9eQpDT05GSUdfUFJJTlRLPXkKQ09ORklHX0JVRz15
CkNPTkZJR19FTEZfQ09SRT15CkNPTkZJR19QQ1NQS1JfUExBVEZPUk09eQpDT05GSUdfSEFW
RV9QQ1NQS1JfUExBVEZPUk09eQpDT05GSUdfQkFTRV9GVUxMPXkKQ09ORklHX0ZVVEVYPXkK
Q09ORklHX0VQT0xMPXkKQ09ORklHX1NJR05BTEZEPXkKQ09ORklHX1RJTUVSRkQ9eQpDT05G
SUdfRVZFTlRGRD15CkNPTkZJR19TSE1FTT15CkNPTkZJR19BSU89eQojIENPTkZJR19FTUJF
RERFRCBpcyBub3Qgc2V0CkNPTkZJR19IQVZFX1BFUkZfRVZFTlRTPXkKCiMKIyBLZXJuZWwg
UGVyZm9ybWFuY2UgRXZlbnRzIEFuZCBDb3VudGVycwojCkNPTkZJR19QRVJGX0VWRU5UUz15
CiMgQ09ORklHX1BFUkZfQ09VTlRFUlMgaXMgbm90IHNldAojIENPTkZJR19ERUJVR19QRVJG
X1VTRV9WTUFMTE9DIGlzIG5vdCBzZXQKQ09ORklHX1ZNX0VWRU5UX0NPVU5URVJTPXkKQ09O
RklHX1NMVUJfREVCVUc9eQpDT05GSUdfQ09NUEFUX0JSSz15CiMgQ09ORklHX1NMQUIgaXMg
bm90IHNldApDT05GSUdfU0xVQj15CkNPTkZJR19QUk9GSUxJTkc9eQpDT05GSUdfVFJBQ0VQ
T0lOVFM9eQpDT05GSUdfT1BST0ZJTEU9bQojIENPTkZJR19PUFJPRklMRV9FVkVOVF9NVUxU
SVBMRVggaXMgbm90IHNldApDT05GSUdfSEFWRV9PUFJPRklMRT15CkNPTkZJR19PUFJPRklM
RV9OTUlfVElNRVI9eQojIENPTkZJR19LUFJPQkVTIGlzIG5vdCBzZXQKQ09ORklHX0pVTVBf
TEFCRUw9eQojIENPTkZJR19VUFJPQkVTIGlzIG5vdCBzZXQKQ09ORklHX0hBVkVfRUZGSUNJ
RU5UX1VOQUxJR05FRF9BQ0NFU1M9eQpDT05GSUdfSEFWRV9JT1JFTUFQX1BST1Q9eQpDT05G
SUdfSEFWRV9LUFJPQkVTPXkKQ09ORklHX0hBVkVfS1JFVFBST0JFUz15CkNPTkZJR19IQVZF
X09QVFBST0JFUz15CkNPTkZJR19IQVZFX0FSQ0hfVFJBQ0VIT09LPXkKQ09ORklHX0hBVkVf
RE1BX0FUVFJTPXkKQ09ORklHX0hBVkVfUkVHU19BTkRfU1RBQ0tfQUNDRVNTX0FQST15CkNP
TkZJR19IQVZFX0RNQV9BUElfREVCVUc9eQpDT05GSUdfSEFWRV9IV19CUkVBS1BPSU5UPXkK
Q09ORklHX0hBVkVfTUlYRURfQlJFQUtQT0lOVFNfUkVHUz15CkNPTkZJR19IQVZFX1VTRVJf
UkVUVVJOX05PVElGSUVSPXkKQ09ORklHX0hBVkVfUEVSRl9FVkVOVFNfTk1JPXkKQ09ORklH
X0hBVkVfQVJDSF9KVU1QX0xBQkVMPXkKQ09ORklHX0FSQ0hfSEFWRV9OTUlfU0FGRV9DTVBY
Q0hHPXkKQ09ORklHX0hBVkVfQUxJR05FRF9TVFJVQ1RfUEFHRT15CkNPTkZJR19IQVZFX0NN
UFhDSEdfTE9DQUw9eQpDT05GSUdfSEFWRV9DTVBYQ0hHX0RPVUJMRT15CgojCiMgR0NPVi1i
YXNlZCBrZXJuZWwgcHJvZmlsaW5nCiMKIyBDT05GSUdfR0NPVl9LRVJORUwgaXMgbm90IHNl
dAojIENPTkZJR19IQVZFX0dFTkVSSUNfRE1BX0NPSEVSRU5UIGlzIG5vdCBzZXQKQ09ORklH
X1NMQUJJTkZPPXkKQ09ORklHX1JUX01VVEVYRVM9eQpDT05GSUdfQkFTRV9TTUFMTD0wCkNP
TkZJR19NT0RVTEVTPXkKIyBDT05GSUdfTU9EVUxFX0ZPUkNFX0xPQUQgaXMgbm90IHNldAoj
IENPTkZJR19NT0RVTEVfVU5MT0FEIGlzIG5vdCBzZXQKQ09ORklHX01PRFZFUlNJT05TPXkK
IyBDT05GSUdfTU9EVUxFX1NSQ1ZFUlNJT05fQUxMIGlzIG5vdCBzZXQKQ09ORklHX0JMT0NL
PXkKQ09ORklHX0JMS19ERVZfQlNHPXkKQ09ORklHX0JMS19ERVZfQlNHTElCPXkKIyBDT05G
SUdfQkxLX0RFVl9JTlRFR1JJVFkgaXMgbm90IHNldApDT05GSUdfQkxPQ0tfQ09NUEFUPXkK
CiMKIyBJTyBTY2hlZHVsZXJzCiMKQ09ORklHX0lPU0NIRURfTk9PUD15CiMgQ09ORklHX0lP
U0NIRURfREVBRExJTkUgaXMgbm90IHNldAojIENPTkZJR19JT1NDSEVEX0NGUSBpcyBub3Qg
c2V0CkNPTkZJR19ERUZBVUxUX05PT1A9eQpDT05GSUdfREVGQVVMVF9JT1NDSEVEPSJub29w
IgojIENPTkZJR19JTkxJTkVfU1BJTl9UUllMT0NLIGlzIG5vdCBzZXQKIyBDT05GSUdfSU5M
SU5FX1NQSU5fVFJZTE9DS19CSCBpcyBub3Qgc2V0CiMgQ09ORklHX0lOTElORV9TUElOX0xP
Q0sgaXMgbm90IHNldAojIENPTkZJR19JTkxJTkVfU1BJTl9MT0NLX0JIIGlzIG5vdCBzZXQK
IyBDT05GSUdfSU5MSU5FX1NQSU5fTE9DS19JUlEgaXMgbm90IHNldAojIENPTkZJR19JTkxJ
TkVfU1BJTl9MT0NLX0lSUVNBVkUgaXMgbm90IHNldAojIENPTkZJR19JTkxJTkVfU1BJTl9V
TkxPQ0sgaXMgbm90IHNldAojIENPTkZJR19JTkxJTkVfU1BJTl9VTkxPQ0tfQkggaXMgbm90
IHNldAojIENPTkZJR19JTkxJTkVfU1BJTl9VTkxPQ0tfSVJRIGlzIG5vdCBzZXQKIyBDT05G
SUdfSU5MSU5FX1NQSU5fVU5MT0NLX0lSUVJFU1RPUkUgaXMgbm90IHNldAojIENPTkZJR19J
TkxJTkVfUkVBRF9UUllMT0NLIGlzIG5vdCBzZXQKIyBDT05GSUdfSU5MSU5FX1JFQURfTE9D
SyBpcyBub3Qgc2V0CiMgQ09ORklHX0lOTElORV9SRUFEX0xPQ0tfQkggaXMgbm90IHNldAoj
IENPTkZJR19JTkxJTkVfUkVBRF9MT0NLX0lSUSBpcyBub3Qgc2V0CiMgQ09ORklHX0lOTElO
RV9SRUFEX0xPQ0tfSVJRU0FWRSBpcyBub3Qgc2V0CiMgQ09ORklHX0lOTElORV9SRUFEX1VO
TE9DSyBpcyBub3Qgc2V0CiMgQ09ORklHX0lOTElORV9SRUFEX1VOTE9DS19CSCBpcyBub3Qg
c2V0CiMgQ09ORklHX0lOTElORV9SRUFEX1VOTE9DS19JUlEgaXMgbm90IHNldAojIENPTkZJ
R19JTkxJTkVfUkVBRF9VTkxPQ0tfSVJRUkVTVE9SRSBpcyBub3Qgc2V0CiMgQ09ORklHX0lO
TElORV9XUklURV9UUllMT0NLIGlzIG5vdCBzZXQKIyBDT05GSUdfSU5MSU5FX1dSSVRFX0xP
Q0sgaXMgbm90IHNldAojIENPTkZJR19JTkxJTkVfV1JJVEVfTE9DS19CSCBpcyBub3Qgc2V0
CiMgQ09ORklHX0lOTElORV9XUklURV9MT0NLX0lSUSBpcyBub3Qgc2V0CiMgQ09ORklHX0lO
TElORV9XUklURV9MT0NLX0lSUVNBVkUgaXMgbm90IHNldAojIENPTkZJR19JTkxJTkVfV1JJ
VEVfVU5MT0NLIGlzIG5vdCBzZXQKIyBDT05GSUdfSU5MSU5FX1dSSVRFX1VOTE9DS19CSCBp
cyBub3Qgc2V0CiMgQ09ORklHX0lOTElORV9XUklURV9VTkxPQ0tfSVJRIGlzIG5vdCBzZXQK
IyBDT05GSUdfSU5MSU5FX1dSSVRFX1VOTE9DS19JUlFSRVNUT1JFIGlzIG5vdCBzZXQKIyBD
T05GSUdfTVVURVhfU1BJTl9PTl9PV05FUiBpcyBub3Qgc2V0CkNPTkZJR19GUkVFWkVSPXkK
CiMKIyBQcm9jZXNzb3IgdHlwZSBhbmQgZmVhdHVyZXMKIwpDT05GSUdfVElDS19PTkVTSE9U
PXkKQ09ORklHX05PX0haPXkKQ09ORklHX0hJR0hfUkVTX1RJTUVSUz15CkNPTkZJR19HRU5F
UklDX0NMT0NLRVZFTlRTX0JVSUxEPXkKQ09ORklHX0dFTkVSSUNfQ0xPQ0tFVkVOVFNfTUlO
X0FESlVTVD15CiMgQ09ORklHX1NNUCBpcyBub3Qgc2V0CkNPTkZJR19YODZfTVBQQVJTRT15
CiMgQ09ORklHX1g4Nl9FWFRFTkRFRF9QTEFURk9STSBpcyBub3Qgc2V0CiMgQ09ORklHX1ND
SEVEX09NSVRfRlJBTUVfUE9JTlRFUiBpcyBub3Qgc2V0CiMgQ09ORklHX0tWTVRPT0xfVEVT
VF9FTkFCTEUgaXMgbm90IHNldApDT05GSUdfUEFSQVZJUlRfR1VFU1Q9eQpDT05GSUdfUEFS
QVZJUlRfVElNRV9BQ0NPVU5USU5HPXkKQ09ORklHX1hFTj15CiMgQ09ORklHX1hFTl9QUklW
SUxFR0VEX0dVRVNUIGlzIG5vdCBzZXQKQ09ORklHX1hFTl9NQVhfRE9NQUlOX01FTU9SWT01
MDAKQ09ORklHX1hFTl9TQVZFX1JFU1RPUkU9eQojIENPTkZJR19YRU5fREVCVUdfRlMgaXMg
bm90IHNldApDT05GSUdfS1ZNX0NMT0NLPXkKIyBDT05GSUdfS1ZNX0dVRVNUIGlzIG5vdCBz
ZXQKQ09ORklHX1BBUkFWSVJUPXkKQ09ORklHX1BBUkFWSVJUX0NMT0NLPXkKQ09ORklHX1BB
UkFWSVJUX0RFQlVHPXkKQ09ORklHX05PX0JPT1RNRU09eQpDT05GSUdfTUVNVEVTVD15CiMg
Q09ORklHX01LOCBpcyBub3Qgc2V0CiMgQ09ORklHX01QU0MgaXMgbm90IHNldAojIENPTkZJ
R19NQ09SRTIgaXMgbm90IHNldAojIENPTkZJR19NQVRPTSBpcyBub3Qgc2V0CkNPTkZJR19H
RU5FUklDX0NQVT15CkNPTkZJR19YODZfSU5URVJOT0RFX0NBQ0hFX1NISUZUPTYKQ09ORklH
X1g4Nl9DTVBYQ0hHPXkKQ09ORklHX1g4Nl9MMV9DQUNIRV9TSElGVD02CkNPTkZJR19YODZf
WEFERD15CkNPTkZJR19YODZfV1BfV09SS1NfT0s9eQpDT05GSUdfWDg2X1RTQz15CkNPTkZJ
R19YODZfQ01QWENIRzY0PXkKQ09ORklHX1g4Nl9DTU9WPXkKQ09ORklHX1g4Nl9NSU5JTVVN
X0NQVV9GQU1JTFk9NjQKQ09ORklHX1g4Nl9ERUJVR0NUTE1TUj15CkNPTkZJR19DUFVfU1VQ
X0lOVEVMPXkKQ09ORklHX0NQVV9TVVBfQU1EPXkKQ09ORklHX0NQVV9TVVBfQ0VOVEFVUj15
CkNPTkZJR19IUEVUX1RJTUVSPXkKQ09ORklHX0RNST15CkNPTkZJR19TV0lPVExCPXkKQ09O
RklHX0lPTU1VX0hFTFBFUj15CkNPTkZJR19OUl9DUFVTPTEKIyBDT05GSUdfSVJRX1RJTUVf
QUNDT1VOVElORyBpcyBub3Qgc2V0CiMgQ09ORklHX1BSRUVNUFRfTk9ORSBpcyBub3Qgc2V0
CiMgQ09ORklHX1BSRUVNUFRfVk9MVU5UQVJZIGlzIG5vdCBzZXQKQ09ORklHX1BSRUVNUFQ9
eQpDT05GSUdfUFJFRU1QVF9DT1VOVD15CkNPTkZJR19YODZfTE9DQUxfQVBJQz15CkNPTkZJ
R19YODZfSU9fQVBJQz15CiMgQ09ORklHX1g4Nl9SRVJPVVRFX0ZPUl9CUk9LRU5fQk9PVF9J
UlFTIGlzIG5vdCBzZXQKIyBDT05GSUdfWDg2X01DRSBpcyBub3Qgc2V0CkNPTkZJR19JOEs9
bQpDT05GSUdfTUlDUk9DT0RFPW0KIyBDT05GSUdfTUlDUk9DT0RFX0lOVEVMIGlzIG5vdCBz
ZXQKIyBDT05GSUdfTUlDUk9DT0RFX0FNRCBpcyBub3Qgc2V0CkNPTkZJR19NSUNST0NPREVf
T0xEX0lOVEVSRkFDRT15CiMgQ09ORklHX1g4Nl9NU1IgaXMgbm90IHNldApDT05GSUdfWDg2
X0NQVUlEPW0KQ09ORklHX0FSQ0hfUEhZU19BRERSX1RfNjRCSVQ9eQpDT05GSUdfQVJDSF9E
TUFfQUREUl9UXzY0QklUPXkKQ09ORklHX0RJUkVDVF9HQlBBR0VTPXkKQ09ORklHX0FSQ0hf
U1BBUlNFTUVNX0VOQUJMRT15CkNPTkZJR19BUkNIX1NQQVJTRU1FTV9ERUZBVUxUPXkKQ09O
RklHX0FSQ0hfU0VMRUNUX01FTU9SWV9NT0RFTD15CkNPTkZJR19BUkNIX01FTU9SWV9QUk9C
RT15CkNPTkZJR19BUkNIX1BST0NfS0NPUkVfVEVYVD15CkNPTkZJR19JTExFR0FMX1BPSU5U
RVJfVkFMVUU9MHhkZWFkMDAwMDAwMDAwMDAwCkNPTkZJR19TRUxFQ1RfTUVNT1JZX01PREVM
PXkKQ09ORklHX1NQQVJTRU1FTV9NQU5VQUw9eQpDT05GSUdfU1BBUlNFTUVNPXkKQ09ORklH
X0hBVkVfTUVNT1JZX1BSRVNFTlQ9eQpDT05GSUdfU1BBUlNFTUVNX0VYVFJFTUU9eQpDT05G
SUdfU1BBUlNFTUVNX1ZNRU1NQVBfRU5BQkxFPXkKQ09ORklHX1NQQVJTRU1FTV9BTExPQ19N
RU1fTUFQX1RPR0VUSEVSPXkKIyBDT05GSUdfU1BBUlNFTUVNX1ZNRU1NQVAgaXMgbm90IHNl
dApDT05GSUdfSEFWRV9NRU1CTE9DSz15CkNPTkZJR19IQVZFX01FTUJMT0NLX05PREVfTUFQ
PXkKQ09ORklHX0FSQ0hfRElTQ0FSRF9NRU1CTE9DSz15CkNPTkZJR19NRU1PUllfSE9UUExV
Rz15CkNPTkZJR19NRU1PUllfSE9UUExVR19TUEFSU0U9eQojIENPTkZJR19NRU1PUllfSE9U
UkVNT1ZFIGlzIG5vdCBzZXQKQ09ORklHX1BBR0VGTEFHU19FWFRFTkRFRD15CkNPTkZJR19T
UExJVF9QVExPQ0tfQ1BVUz05OTk5OTkKQ09ORklHX0NPTVBBQ1RJT049eQpDT05GSUdfTUlH
UkFUSU9OPXkKQ09ORklHX1BIWVNfQUREUl9UXzY0QklUPXkKQ09ORklHX1pPTkVfRE1BX0ZM
QUc9MQpDT05GSUdfQk9VTkNFPXkKQ09ORklHX1ZJUlRfVE9fQlVTPXkKQ09ORklHX01NVV9O
T1RJRklFUj15CkNPTkZJR19LU009eQpDT05GSUdfREVGQVVMVF9NTUFQX01JTl9BRERSPTQw
OTYKIyBDT05GSUdfVFJBTlNQQVJFTlRfSFVHRVBBR0UgaXMgbm90IHNldApDT05GSUdfTkVF
RF9QRVJfQ1BVX0tNPXkKIyBDT05GSUdfQ0xFQU5DQUNIRSBpcyBub3Qgc2V0CkNPTkZJR19Y
ODZfQ0hFQ0tfQklPU19DT1JSVVBUSU9OPXkKIyBDT05GSUdfWDg2X0JPT1RQQVJBTV9NRU1P
UllfQ09SUlVQVElPTl9DSEVDSyBpcyBub3Qgc2V0CkNPTkZJR19YODZfUkVTRVJWRV9MT1c9
NjQKQ09ORklHX01UUlI9eQpDT05GSUdfTVRSUl9TQU5JVElaRVI9eQpDT05GSUdfTVRSUl9T
QU5JVElaRVJfRU5BQkxFX0RFRkFVTFQ9MApDT05GSUdfTVRSUl9TQU5JVElaRVJfU1BBUkVf
UkVHX05SX0RFRkFVTFQ9MQpDT05GSUdfWDg2X1BBVD15CkNPTkZJR19BUkNIX1VTRVNfUEdf
VU5DQUNIRUQ9eQpDT05GSUdfQVJDSF9SQU5ET009eQojIENPTkZJR19TRUNDT01QIGlzIG5v
dCBzZXQKQ09ORklHX0NDX1NUQUNLUFJPVEVDVE9SPXkKIyBDT05GSUdfSFpfMTAwIGlzIG5v
dCBzZXQKIyBDT05GSUdfSFpfMjUwIGlzIG5vdCBzZXQKIyBDT05GSUdfSFpfMzAwIGlzIG5v
dCBzZXQKQ09ORklHX0haXzEwMDA9eQpDT05GSUdfSFo9MTAwMApDT05GSUdfU0NIRURfSFJU
SUNLPXkKQ09ORklHX0tFWEVDPXkKQ09ORklHX0NSQVNIX0RVTVA9eQpDT05GSUdfUEhZU0lD
QUxfU1RBUlQ9MHgxMDAwMDAwCkNPTkZJR19SRUxPQ0FUQUJMRT15CkNPTkZJR19QSFlTSUNB
TF9BTElHTj0weDEwMDAwMDAKQ09ORklHX0NPTVBBVF9WRFNPPXkKIyBDT05GSUdfQ01ETElO
RV9CT09MIGlzIG5vdCBzZXQKQ09ORklHX0FSQ0hfRU5BQkxFX01FTU9SWV9IT1RQTFVHPXkK
Q09ORklHX0FSQ0hfRU5BQkxFX01FTU9SWV9IT1RSRU1PVkU9eQoKIwojIFBvd2VyIG1hbmFn
ZW1lbnQgYW5kIEFDUEkgb3B0aW9ucwojCkNPTkZJR19TVVNQRU5EPXkKQ09ORklHX1NVU1BF
TkRfRlJFRVpFUj15CkNPTkZJR19ISUJFUk5BVEVfQ0FMTEJBQ0tTPXkKQ09ORklHX1BNX1NM
RUVQPXkKQ09ORklHX1BNX1JVTlRJTUU9eQpDT05GSUdfUE09eQpDT05GSUdfUE1fREVCVUc9
eQpDT05GSUdfUE1fQURWQU5DRURfREVCVUc9eQpDT05GSUdfUE1fVEVTVF9TVVNQRU5EPXkK
Q09ORklHX0NBTl9QTV9UUkFDRT15CkNPTkZJR19QTV9UUkFDRT15CkNPTkZJR19QTV9UUkFD
RV9SVEM9eQpDT05GSUdfU0ZJPXkKCiMKIyBDUFUgRnJlcXVlbmN5IHNjYWxpbmcKIwojIENP
TkZJR19DUFVfRlJFUSBpcyBub3Qgc2V0CiMgQ09ORklHX0NQVV9JRExFIGlzIG5vdCBzZXQK
CiMKIyBNZW1vcnkgcG93ZXIgc2F2aW5ncwojCgojCiMgQnVzIG9wdGlvbnMgKFBDSSBldGMu
KQojCiMgQ09ORklHX1BDSSBpcyBub3Qgc2V0CiMgQ09ORklHX0FSQ0hfU1VQUE9SVFNfTVNJ
IGlzIG5vdCBzZXQKQ09ORklHX1BDSV9MQUJFTD15CkNPTkZJR19JU0FfRE1BX0FQST15CkNP
TkZJR19QQ0NBUkQ9bQojIENPTkZJR19QQ01DSUEgaXMgbm90IHNldAoKIwojIFBDLWNhcmQg
YnJpZGdlcwojCgojCiMgRXhlY3V0YWJsZSBmaWxlIGZvcm1hdHMgLyBFbXVsYXRpb25zCiMK
Q09ORklHX0JJTkZNVF9FTEY9eQpDT05GSUdfQ09NUEFUX0JJTkZNVF9FTEY9eQpDT05GSUdf
QVJDSF9CSU5GTVRfRUxGX1JBTkRPTUlaRV9QSUU9eQojIENPTkZJR19DT1JFX0RVTVBfREVG
QVVMVF9FTEZfSEVBREVSUyBpcyBub3Qgc2V0CiMgQ09ORklHX0hBVkVfQU9VVCBpcyBub3Qg
c2V0CiMgQ09ORklHX0JJTkZNVF9NSVNDIGlzIG5vdCBzZXQKQ09ORklHX0lBMzJfRU1VTEFU
SU9OPXkKIyBDT05GSUdfSUEzMl9BT1VUIGlzIG5vdCBzZXQKQ09ORklHX0NPTVBBVD15CkNP
TkZJR19DT01QQVRfRk9SX1U2NF9BTElHTk1FTlQ9eQpDT05GSUdfU1lTVklQQ19DT01QQVQ9
eQpDT05GSUdfS0VZU19DT01QQVQ9eQpDT05GSUdfSEFWRV9URVhUX1BPS0VfU01QPXkKQ09O
RklHX05FVD15CkNPTkZJR19DT01QQVRfTkVUTElOS19NRVNTQUdFUz15CgojCiMgTmV0d29y
a2luZyBvcHRpb25zCiMKQ09ORklHX1BBQ0tFVD1tCkNPTkZJR19VTklYPW0KQ09ORklHX1VO
SVhfRElBRz1tCiMgQ09ORklHX05FVF9LRVkgaXMgbm90IHNldAojIENPTkZJR19JTkVUIGlz
IG5vdCBzZXQKIyBDT05GSUdfTkVUV09SS19TRUNNQVJLIGlzIG5vdCBzZXQKQ09ORklHX05F
VEZJTFRFUj15CkNPTkZJR19ORVRGSUxURVJfREVCVUc9eQpDT05GSUdfTkVURklMVEVSX0FE
VkFOQ0VEPXkKQ09ORklHX0FUTT1tCiMgQ09ORklHX0FUTV9MQU5FIGlzIG5vdCBzZXQKIyBD
T05GSUdfQlJJREdFIGlzIG5vdCBzZXQKIyBDT05GSUdfVkxBTl84MDIxUSBpcyBub3Qgc2V0
CkNPTkZJR19ERUNORVQ9bQpDT05GSUdfTExDPW0KQ09ORklHX0xMQzI9bQpDT05GSUdfSVBY
PW0KQ09ORklHX0lQWF9JTlRFUk49eQpDT05GSUdfQVRBTEs9bQpDT05GSUdfREVWX0FQUExF
VEFMSz1tCkNPTkZJR19JUEREUD1tCiMgQ09ORklHX0lQRERQX0VOQ0FQIGlzIG5vdCBzZXQK
IyBDT05GSUdfSVBERFBfREVDQVAgaXMgbm90IHNldApDT05GSUdfUEhPTkVUPW0KIyBDT05G
SUdfTkVUX1NDSEVEIGlzIG5vdCBzZXQKIyBDT05GSUdfRENCIGlzIG5vdCBzZXQKQ09ORklH
X0ROU19SRVNPTFZFUj1tCkNPTkZJR19CQVRNQU5fQURWPW0KIyBDT05GSUdfQkFUTUFOX0FE
Vl9ERUJVRyBpcyBub3Qgc2V0CkNPTkZJR19PUEVOVlNXSVRDSD1tCkNPTkZJR19ORVRQUklP
X0NHUk9VUD1tCkNPTkZJR19CUUw9eQpDT05GSUdfSEFWRV9CUEZfSklUPXkKQ09ORklHX0JQ
Rl9KSVQ9eQoKIwojIE5ldHdvcmsgdGVzdGluZwojCkNPTkZJR19ORVRfUEtUR0VOPW0KIyBD
T05GSUdfSEFNUkFESU8gaXMgbm90IHNldApDT05GSUdfQ0FOPW0KIyBDT05GSUdfQ0FOX1JB
VyBpcyBub3Qgc2V0CiMgQ09ORklHX0NBTl9CQ00gaXMgbm90IHNldAojIENPTkZJR19DQU5f
R1cgaXMgbm90IHNldAoKIwojIENBTiBEZXZpY2UgRHJpdmVycwojCkNPTkZJR19DQU5fVkNB
Tj1tCiMgQ09ORklHX0NBTl9TTENBTiBpcyBub3Qgc2V0CkNPTkZJR19DQU5fREVWPW0KQ09O
RklHX0NBTl9DQUxDX0JJVFRJTUlORz15CiMgQ09ORklHX0NBTl9NQ1AyNTFYIGlzIG5vdCBz
ZXQKQ09ORklHX0NBTl9TSkExMDAwPW0KIyBDT05GSUdfQ0FOX1NKQTEwMDBfSVNBIGlzIG5v
dCBzZXQKQ09ORklHX0NBTl9TSkExMDAwX1BMQVRGT1JNPW0KQ09ORklHX0NBTl9DX0NBTj1t
CkNPTkZJR19DQU5fQ19DQU5fUExBVEZPUk09bQojIENPTkZJR19DQU5fQ0M3NzAgaXMgbm90
IHNldApDT05GSUdfQ0FOX1NPRlRJTkc9bQojIENPTkZJR19DQU5fREVCVUdfREVWSUNFUyBp
cyBub3Qgc2V0CkNPTkZJR19JUkRBPW0KCiMKIyBJckRBIHByb3RvY29scwojCiMgQ09ORklH
X0lSTEFOIGlzIG5vdCBzZXQKQ09ORklHX0lSQ09NTT1tCkNPTkZJR19JUkRBX1VMVFJBPXkK
CiMKIyBJckRBIG9wdGlvbnMKIwpDT05GSUdfSVJEQV9DQUNIRV9MQVNUX0xTQVA9eQojIENP
TkZJR19JUkRBX0ZBU1RfUlIgaXMgbm90IHNldAojIENPTkZJR19JUkRBX0RFQlVHIGlzIG5v
dCBzZXQKCiMKIyBJbmZyYXJlZC1wb3J0IGRldmljZSBkcml2ZXJzCiMKCiMKIyBTSVIgZGV2
aWNlIGRyaXZlcnMKIwpDT05GSUdfSVJUVFlfU0lSPW0KCiMKIyBEb25nbGUgc3VwcG9ydAoj
CkNPTkZJR19ET05HTEU9eQojIENPTkZJR19FU0lfRE9OR0xFIGlzIG5vdCBzZXQKQ09ORklH
X0FDVElTWVNfRE9OR0xFPW0KQ09ORklHX1RFS1JBTV9ET05HTEU9bQpDT05GSUdfVE9JTTMy
MzJfRE9OR0xFPW0KIyBDT05GSUdfTElURUxJTktfRE9OR0xFIGlzIG5vdCBzZXQKCiMKIyBG
SVIgZGV2aWNlIGRyaXZlcnMKIwpDT05GSUdfTlNDX0ZJUj1tCkNPTkZJR19XSU5CT05EX0ZJ
Uj1tCkNPTkZJR19WSUFfRklSPW0KIyBDT05GSUdfQlQgaXMgbm90IHNldApDT05GSUdfV0lS
RUxFU1M9eQpDT05GSUdfV0VYVF9DT1JFPXkKQ09ORklHX1dFWFRfUFJPQz15CkNPTkZJR19D
Rkc4MDIxMT1tCkNPTkZJR19OTDgwMjExX1RFU1RNT0RFPXkKIyBDT05GSUdfQ0ZHODAyMTFf
REVWRUxPUEVSX1dBUk5JTkdTIGlzIG5vdCBzZXQKIyBDT05GSUdfQ0ZHODAyMTFfUkVHX0RF
QlVHIGlzIG5vdCBzZXQKQ09ORklHX0NGRzgwMjExX0RFRkFVTFRfUFM9eQojIENPTkZJR19D
Rkc4MDIxMV9ERUJVR0ZTIGlzIG5vdCBzZXQKIyBDT05GSUdfQ0ZHODAyMTFfSU5URVJOQUxf
UkVHREIgaXMgbm90IHNldApDT05GSUdfQ0ZHODAyMTFfV0VYVD15CkNPTkZJR19XSVJFTEVT
U19FWFRfU1lTRlM9eQojIENPTkZJR19MSUI4MDIxMSBpcyBub3Qgc2V0CkNPTkZJR19NQUM4
MDIxMT1tCkNPTkZJR19NQUM4MDIxMV9IQVNfUkM9eQpDT05GSUdfTUFDODAyMTFfUkNfTUlO
U1RSRUw9eQpDT05GSUdfTUFDODAyMTFfUkNfTUlOU1RSRUxfSFQ9eQpDT05GSUdfTUFDODAy
MTFfUkNfREVGQVVMVF9NSU5TVFJFTD15CkNPTkZJR19NQUM4MDIxMV9SQ19ERUZBVUxUPSJt
aW5zdHJlbF9odCIKIyBDT05GSUdfTUFDODAyMTFfTEVEUyBpcyBub3Qgc2V0CkNPTkZJR19N
QUM4MDIxMV9ERUJVR0ZTPXkKQ09ORklHX01BQzgwMjExX0RFQlVHX01FTlU9eQojIENPTkZJ
R19NQUM4MDIxMV9OT0lOTElORSBpcyBub3Qgc2V0CiMgQ09ORklHX01BQzgwMjExX1ZFUkJP
U0VfREVCVUcgaXMgbm90IHNldApDT05GSUdfTUFDODAyMTFfSFRfREVCVUc9eQpDT05GSUdf
TUFDODAyMTFfVEtJUF9ERUJVRz15CkNPTkZJR19NQUM4MDIxMV9JQlNTX0RFQlVHPXkKIyBD
T05GSUdfTUFDODAyMTFfVkVSQk9TRV9QU19ERUJVRyBpcyBub3Qgc2V0CkNPTkZJR19NQUM4
MDIxMV9WRVJCT1NFX1RETFNfREVCVUc9eQojIENPTkZJR19NQUM4MDIxMV9ERUJVR19DT1VO
VEVSUyBpcyBub3Qgc2V0CiMgQ09ORklHX1dJTUFYIGlzIG5vdCBzZXQKIyBDT05GSUdfUkZL
SUxMIGlzIG5vdCBzZXQKQ09ORklHX05FVF85UD1tCkNPTkZJR19ORVRfOVBfVklSVElPPW0K
IyBDT05GSUdfTkVUXzlQX0RFQlVHIGlzIG5vdCBzZXQKIyBDT05GSUdfQ0FJRiBpcyBub3Qg
c2V0CgojCiMgRGV2aWNlIERyaXZlcnMKIwoKIwojIEdlbmVyaWMgRHJpdmVyIE9wdGlvbnMK
IwpDT05GSUdfVUVWRU5UX0hFTFBFUl9QQVRIPSIiCiMgQ09ORklHX0RFVlRNUEZTIGlzIG5v
dCBzZXQKQ09ORklHX1NUQU5EQUxPTkU9eQpDT05GSUdfUFJFVkVOVF9GSVJNV0FSRV9CVUlM
RD15CkNPTkZJR19GV19MT0FERVI9eQpDT05GSUdfRklSTVdBUkVfSU5fS0VSTkVMPXkKQ09O
RklHX0VYVFJBX0ZJUk1XQVJFPSIiCiMgQ09ORklHX0RFQlVHX0RSSVZFUiBpcyBub3Qgc2V0
CkNPTkZJR19ERUJVR19ERVZSRVM9eQpDT05GSUdfU1lTX0hZUEVSVklTT1I9eQpDT05GSUdf
UkVHTUFQPXkKQ09ORklHX1JFR01BUF9TUEk9eQojIENPTkZJR19DT05ORUNUT1IgaXMgbm90
IHNldApDT05GSUdfTVREPW0KQ09ORklHX01URF9URVNUUz1tCiMgQ09ORklHX01URF9SRURC
T09UX1BBUlRTIGlzIG5vdCBzZXQKQ09ORklHX01URF9BUjdfUEFSVFM9bQoKIwojIFVzZXIg
TW9kdWxlcyBBbmQgVHJhbnNsYXRpb24gTGF5ZXJzCiMKQ09ORklHX01URF9DSEFSPW0KQ09O
RklHX0hBVkVfTVREX09UUD15CkNPTkZJR19NVERfQkxLREVWUz1tCkNPTkZJR19NVERfQkxP
Q0s9bQojIENPTkZJR19NVERfQkxPQ0tfUk8gaXMgbm90IHNldApDT05GSUdfRlRMPW0KIyBD
T05GSUdfTkZUTCBpcyBub3Qgc2V0CiMgQ09ORklHX0lORlRMIGlzIG5vdCBzZXQKIyBDT05G
SUdfUkZEX0ZUTCBpcyBub3Qgc2V0CkNPTkZJR19TU0ZEQz1tCiMgQ09ORklHX01URF9PT1BT
IGlzIG5vdCBzZXQKCiMKIyBSQU0vUk9NL0ZsYXNoIGNoaXAgZHJpdmVycwojCkNPTkZJR19N
VERfQ0ZJPW0KQ09ORklHX01URF9KRURFQ1BST0JFPW0KQ09ORklHX01URF9HRU5fUFJPQkU9
bQojIENPTkZJR19NVERfQ0ZJX0FEVl9PUFRJT05TIGlzIG5vdCBzZXQKQ09ORklHX01URF9N
QVBfQkFOS19XSURUSF8xPXkKQ09ORklHX01URF9NQVBfQkFOS19XSURUSF8yPXkKQ09ORklH
X01URF9NQVBfQkFOS19XSURUSF80PXkKIyBDT05GSUdfTVREX01BUF9CQU5LX1dJRFRIXzgg
aXMgbm90IHNldAojIENPTkZJR19NVERfTUFQX0JBTktfV0lEVEhfMTYgaXMgbm90IHNldAoj
IENPTkZJR19NVERfTUFQX0JBTktfV0lEVEhfMzIgaXMgbm90IHNldApDT05GSUdfTVREX0NG
SV9JMT15CkNPTkZJR19NVERfQ0ZJX0kyPXkKIyBDT05GSUdfTVREX0NGSV9JNCBpcyBub3Qg
c2V0CiMgQ09ORklHX01URF9DRklfSTggaXMgbm90IHNldAojIENPTkZJR19NVERfQ0ZJX0lO
VEVMRVhUIGlzIG5vdCBzZXQKQ09ORklHX01URF9DRklfQU1EU1REPW0KQ09ORklHX01URF9D
RklfU1RBQT1tCkNPTkZJR19NVERfQ0ZJX1VUSUw9bQojIENPTkZJR19NVERfUkFNIGlzIG5v
dCBzZXQKIyBDT05GSUdfTVREX1JPTSBpcyBub3Qgc2V0CiMgQ09ORklHX01URF9BQlNFTlQg
aXMgbm90IHNldAoKIwojIE1hcHBpbmcgZHJpdmVycyBmb3IgY2hpcCBhY2Nlc3MKIwpDT05G
SUdfTVREX0NPTVBMRVhfTUFQUElOR1M9eQojIENPTkZJR19NVERfUEhZU01BUCBpcyBub3Qg
c2V0CkNPTkZJR19NVERfU0M1MjBDRFA9bQojIENPTkZJR19NVERfTkVUU0M1MjAgaXMgbm90
IHNldApDT05GSUdfTVREX1RTNTUwMD1tCiMgQ09ORklHX01URF9BTUQ3NlhST00gaXMgbm90
IHNldAojIENPTkZJR19NVERfSUNIWFJPTSBpcyBub3Qgc2V0CkNPTkZJR19NVERfU0NCMl9G
TEFTSD1tCkNPTkZJR19NVERfTkVUdGVsPW0KQ09ORklHX01URF9MNDQwR1g9bQojIENPTkZJ
R19NVERfUExBVFJBTSBpcyBub3Qgc2V0CkNPTkZJR19NVERfTEFUQ0hfQUREUj1tCgojCiMg
U2VsZi1jb250YWluZWQgTVREIGRldmljZSBkcml2ZXJzCiMKQ09ORklHX01URF9TU1QyNUw9
bQpDT05GSUdfTVREX1NMUkFNPW0KQ09ORklHX01URF9QSFJBTT1tCkNPTkZJR19NVERfTVRE
UkFNPW0KQ09ORklHX01URFJBTV9UT1RBTF9TSVpFPTQwOTYKQ09ORklHX01URFJBTV9FUkFT
RV9TSVpFPTEyOApDT05GSUdfTVREX0JMT0NLMk1URD1tCgojCiMgRGlzay1Pbi1DaGlwIERl
dmljZSBEcml2ZXJzCiMKIyBDT05GSUdfTVREX0RPQzIwMDAgaXMgbm90IHNldAojIENPTkZJ
R19NVERfRE9DMjAwMSBpcyBub3Qgc2V0CkNPTkZJR19NVERfRE9DMjAwMVBMVVM9bQojIENP
TkZJR19NVERfRE9DRzMgaXMgbm90IHNldApDT05GSUdfTVREX0RPQ1BST0JFPW0KQ09ORklH
X01URF9ET0NFQ0M9bQojIENPTkZJR19NVERfRE9DUFJPQkVfQURWQU5DRUQgaXMgbm90IHNl
dApDT05GSUdfTVREX0RPQ1BST0JFX0FERFJFU1M9MHgwCkNPTkZJR19NVERfTkFORF9FQ0M9
bQpDT05GSUdfTVREX05BTkRfRUNDX1NNQz15CkNPTkZJR19NVERfTkFORD1tCiMgQ09ORklH
X01URF9OQU5EX1ZFUklGWV9XUklURSBpcyBub3Qgc2V0CkNPTkZJR19NVERfTkFORF9CQ0g9
bQpDT05GSUdfTVREX05BTkRfRUNDX0JDSD15CiMgQ09ORklHX01URF9TTV9DT01NT04gaXMg
bm90IHNldAojIENPTkZJR19NVERfTkFORF9NVVNFVU1fSURTIGlzIG5vdCBzZXQKQ09ORklH
X01URF9OQU5EX0lEUz1tCiMgQ09ORklHX01URF9OQU5EX05BTkRTSU0gaXMgbm90IHNldApD
T05GSUdfTVREX05BTkRfUExBVEZPUk09bQpDT05GSUdfTVREX09ORU5BTkQ9bQpDT05GSUdf
TVREX09ORU5BTkRfVkVSSUZZX1dSSVRFPXkKQ09ORklHX01URF9PTkVOQU5EX0dFTkVSSUM9
bQpDT05GSUdfTVREX09ORU5BTkRfT1RQPXkKIyBDT05GSUdfTVREX09ORU5BTkRfMlhfUFJP
R1JBTSBpcyBub3Qgc2V0CiMgQ09ORklHX01URF9PTkVOQU5EX1NJTSBpcyBub3Qgc2V0Cgoj
CiMgTFBERFIgZmxhc2ggbWVtb3J5IGRyaXZlcnMKIwojIENPTkZJR19NVERfTFBERFIgaXMg
bm90IHNldApDT05GSUdfTVREX1VCST1tCkNPTkZJR19NVERfVUJJX1dMX1RIUkVTSE9MRD00
MDk2CkNPTkZJR19NVERfVUJJX0JFQl9SRVNFUlZFPTEKQ09ORklHX01URF9VQklfR0xVRUJJ
PW0KIyBDT05GSUdfTVREX1VCSV9ERUJVRyBpcyBub3Qgc2V0CiMgQ09ORklHX1BBUlBPUlQg
aXMgbm90IHNldApDT05GSUdfQkxLX0RFVj15CkNPTkZJR19CTEtfREVWX0ZEPW0KIyBDT05G
SUdfQkxLX0RFVl9DT1dfQ09NTU9OIGlzIG5vdCBzZXQKQ09ORklHX0JMS19ERVZfTE9PUD1t
CkNPTkZJR19CTEtfREVWX0xPT1BfTUlOX0NPVU5UPTgKIyBDT05GSUdfQkxLX0RFVl9DUllQ
VE9MT09QIGlzIG5vdCBzZXQKCiMKIyBEUkJEIGRpc2FibGVkIGJlY2F1c2UgUFJPQ19GUywg
SU5FVCBvciBDT05ORUNUT1Igbm90IHNlbGVjdGVkCiMKQ09ORklHX0JMS19ERVZfTkJEPW0K
Q09ORklHX0JMS19ERVZfUkFNPW0KQ09ORklHX0JMS19ERVZfUkFNX0NPVU5UPTE2CkNPTkZJ
R19CTEtfREVWX1JBTV9TSVpFPTQwOTYKIyBDT05GSUdfQkxLX0RFVl9YSVAgaXMgbm90IHNl
dAojIENPTkZJR19DRFJPTV9QS1RDRFZEIGlzIG5vdCBzZXQKQ09ORklHX0FUQV9PVkVSX0VU
SD1tCkNPTkZJR19YRU5fQkxLREVWX0ZST05URU5EPW0KIyBDT05GSUdfQkxLX0RFVl9IRCBp
cyBub3Qgc2V0CiMgQ09ORklHX1NFTlNPUlNfTElTM0xWMDJEIGlzIG5vdCBzZXQKIyBDT05G
SUdfTUlTQ19ERVZJQ0VTIGlzIG5vdCBzZXQKQ09ORklHX0hBVkVfSURFPXkKIyBDT05GSUdf
SURFIGlzIG5vdCBzZXQKCiMKIyBTQ1NJIGRldmljZSBzdXBwb3J0CiMKQ09ORklHX1NDU0lf
TU9EPW0KQ09ORklHX1JBSURfQVRUUlM9bQpDT05GSUdfU0NTST1tCkNPTkZJR19TQ1NJX0RN
QT15CkNPTkZJR19TQ1NJX05FVExJTks9eQojIENPTkZJR19TQ1NJX1BST0NfRlMgaXMgbm90
IHNldAoKIwojIFNDU0kgc3VwcG9ydCB0eXBlIChkaXNrLCB0YXBlLCBDRC1ST00pCiMKQ09O
RklHX0JMS19ERVZfU0Q9bQpDT05GSUdfQ0hSX0RFVl9TVD1tCiMgQ09ORklHX0NIUl9ERVZf
T1NTVCBpcyBub3Qgc2V0CkNPTkZJR19CTEtfREVWX1NSPW0KQ09ORklHX0JMS19ERVZfU1Jf
VkVORE9SPXkKQ09ORklHX0NIUl9ERVZfU0c9bQpDT05GSUdfQ0hSX0RFVl9TQ0g9bQojIENP
TkZJR19TQ1NJX01VTFRJX0xVTiBpcyBub3Qgc2V0CiMgQ09ORklHX1NDU0lfQ09OU1RBTlRT
IGlzIG5vdCBzZXQKQ09ORklHX1NDU0lfTE9HR0lORz15CiMgQ09ORklHX1NDU0lfU0NBTl9B
U1lOQyBpcyBub3Qgc2V0CkNPTkZJR19TQ1NJX1dBSVRfU0NBTj1tCgojCiMgU0NTSSBUcmFu
c3BvcnRzCiMKQ09ORklHX1NDU0lfU1BJX0FUVFJTPW0KQ09ORklHX1NDU0lfRkNfQVRUUlM9
bQojIENPTkZJR19TQ1NJX0lTQ1NJX0FUVFJTIGlzIG5vdCBzZXQKQ09ORklHX1NDU0lfU0FT
X0FUVFJTPW0KQ09ORklHX1NDU0lfU0FTX0xJQlNBUz1tCkNPTkZJR19TQ1NJX1NBU19BVEE9
eQpDT05GSUdfU0NTSV9TQVNfSE9TVF9TTVA9eQojIENPTkZJR19TQ1NJX1NSUF9BVFRSUyBp
cyBub3Qgc2V0CiMgQ09ORklHX1NDU0lfTE9XTEVWRUwgaXMgbm90IHNldAojIENPTkZJR19T
Q1NJX0RIIGlzIG5vdCBzZXQKQ09ORklHX1NDU0lfT1NEX0lOSVRJQVRPUj1tCiMgQ09ORklH
X1NDU0lfT1NEX1VMRCBpcyBub3Qgc2V0CkNPTkZJR19TQ1NJX09TRF9EUFJJTlRfU0VOU0U9
MQojIENPTkZJR19TQ1NJX09TRF9ERUJVRyBpcyBub3Qgc2V0CkNPTkZJR19BVEE9bQojIENP
TkZJR19BVEFfTk9OU1RBTkRBUkQgaXMgbm90IHNldApDT05GSUdfQVRBX1ZFUkJPU0VfRVJS
T1I9eQpDT05GSUdfU0FUQV9QTVA9eQoKIwojIENvbnRyb2xsZXJzIHdpdGggbm9uLVNGRiBu
YXRpdmUgaW50ZXJmYWNlCiMKQ09ORklHX1NBVEFfQUhDSV9QTEFURk9STT1tCiMgQ09ORklH
X0FUQV9TRkYgaXMgbm90IHNldApDT05GSUdfTUQ9eQojIENPTkZJR19CTEtfREVWX01EIGlz
IG5vdCBzZXQKQ09ORklHX0JMS19ERVZfRE09bQpDT05GSUdfRE1fREVCVUc9eQpDT05GSUdf
RE1fQ1JZUFQ9bQpDT05GSUdfRE1fU05BUFNIT1Q9bQpDT05GSUdfRE1fTUlSUk9SPW0KIyBD
T05GSUdfRE1fWkVSTyBpcyBub3Qgc2V0CkNPTkZJR19ETV9NVUxUSVBBVEg9bQojIENPTkZJ
R19ETV9NVUxUSVBBVEhfUUwgaXMgbm90IHNldApDT05GSUdfRE1fTVVMVElQQVRIX1NUPW0K
Q09ORklHX1RBUkdFVF9DT1JFPW0KIyBDT05GSUdfVENNX0lCTE9DSyBpcyBub3Qgc2V0CiMg
Q09ORklHX1RDTV9GSUxFSU8gaXMgbm90IHNldApDT05GSUdfVENNX1BTQ1NJPW0KQ09ORklH
X0xPT1BCQUNLX1RBUkdFVD1tCkNPTkZJR19JU0NTSV9UQVJHRVQ9bQojIENPTkZJR19NQUNJ
TlRPU0hfRFJJVkVSUyBpcyBub3Qgc2V0CiMgQ09ORklHX05FVERFVklDRVMgaXMgbm90IHNl
dAojIENPTkZJR19JU0ROIGlzIG5vdCBzZXQKIyBDT05GSUdfUEhPTkUgaXMgbm90IHNldAoK
IwojIElucHV0IGRldmljZSBzdXBwb3J0CiMKQ09ORklHX0lOUFVUPXkKQ09ORklHX0lOUFVU
X0ZGX01FTUxFU1M9bQpDT05GSUdfSU5QVVRfUE9MTERFVj1tCkNPTkZJR19JTlBVVF9TUEFS
U0VLTUFQPW0KCiMKIyBVc2VybGFuZCBpbnRlcmZhY2VzCiMKQ09ORklHX0lOUFVUX01PVVNF
REVWPXkKQ09ORklHX0lOUFVUX01PVVNFREVWX1BTQVVYPXkKQ09ORklHX0lOUFVUX01PVVNF
REVWX1NDUkVFTl9YPTEwMjQKQ09ORklHX0lOUFVUX01PVVNFREVWX1NDUkVFTl9ZPTc2OAoj
IENPTkZJR19JTlBVVF9KT1lERVYgaXMgbm90IHNldApDT05GSUdfSU5QVVRfRVZERVY9bQoj
IENPTkZJR19JTlBVVF9FVkJVRyBpcyBub3Qgc2V0CgojCiMgSW5wdXQgRGV2aWNlIERyaXZl
cnMKIwpDT05GSUdfSU5QVVRfS0VZQk9BUkQ9eQpDT05GSUdfS0VZQk9BUkRfQVRLQkQ9eQpD
T05GSUdfS0VZQk9BUkRfTEtLQkQ9bQpDT05GSUdfS0VZQk9BUkRfTkVXVE9OPW0KQ09ORklH
X0tFWUJPQVJEX09QRU5DT1JFUz1tCiMgQ09ORklHX0tFWUJPQVJEX1NUT1dBV0FZIGlzIG5v
dCBzZXQKIyBDT05GSUdfS0VZQk9BUkRfU1VOS0JEIGlzIG5vdCBzZXQKQ09ORklHX0tFWUJP
QVJEX1hUS0JEPW0KIyBDT05GSUdfSU5QVVRfTU9VU0UgaXMgbm90IHNldApDT05GSUdfSU5Q
VVRfSk9ZU1RJQ0s9eQpDT05GSUdfSk9ZU1RJQ0tfQU5BTE9HPW0KIyBDT05GSUdfSk9ZU1RJ
Q0tfQTNEIGlzIG5vdCBzZXQKIyBDT05GSUdfSk9ZU1RJQ0tfQURJIGlzIG5vdCBzZXQKIyBD
T05GSUdfSk9ZU1RJQ0tfQ09CUkEgaXMgbm90IHNldAojIENPTkZJR19KT1lTVElDS19HRjJL
IGlzIG5vdCBzZXQKIyBDT05GSUdfSk9ZU1RJQ0tfR1JJUCBpcyBub3Qgc2V0CiMgQ09ORklH
X0pPWVNUSUNLX0dSSVBfTVAgaXMgbm90IHNldApDT05GSUdfSk9ZU1RJQ0tfR1VJTExFTU9U
PW0KQ09ORklHX0pPWVNUSUNLX0lOVEVSQUNUPW0KIyBDT05GSUdfSk9ZU1RJQ0tfU0lERVdJ
TkRFUiBpcyBub3Qgc2V0CkNPTkZJR19KT1lTVElDS19UTURDPW0KQ09ORklHX0pPWVNUSUNL
X0lGT1JDRT1tCkNPTkZJR19KT1lTVElDS19JRk9SQ0VfMjMyPXkKIyBDT05GSUdfSk9ZU1RJ
Q0tfV0FSUklPUiBpcyBub3Qgc2V0CkNPTkZJR19KT1lTVElDS19NQUdFTExBTj1tCiMgQ09O
RklHX0pPWVNUSUNLX1NQQUNFT1JCIGlzIG5vdCBzZXQKQ09ORklHX0pPWVNUSUNLX1NQQUNF
QkFMTD1tCkNPTkZJR19KT1lTVElDS19TVElOR0VSPW0KQ09ORklHX0pPWVNUSUNLX1RXSURK
T1k9bQpDT05GSUdfSk9ZU1RJQ0tfWkhFTkhVQT1tCiMgQ09ORklHX0pPWVNUSUNLX0pPWURV
TVAgaXMgbm90IHNldAojIENPTkZJR19JTlBVVF9UQUJMRVQgaXMgbm90IHNldApDT05GSUdf
SU5QVVRfVE9VQ0hTQ1JFRU49eQpDT05GSUdfVE9VQ0hTQ1JFRU5fQURTNzg0Nj1tCiMgQ09O
RklHX1RPVUNIU0NSRUVOX0FENzg3NyBpcyBub3Qgc2V0CkNPTkZJR19UT1VDSFNDUkVFTl9B
RDc4Nzk9bQojIENPTkZJR19UT1VDSFNDUkVFTl9BRDc4NzlfU1BJIGlzIG5vdCBzZXQKIyBD
T05GSUdfVE9VQ0hTQ1JFRU5fRFlOQVBSTyBpcyBub3Qgc2V0CkNPTkZJR19UT1VDSFNDUkVF
Tl9IQU1QU0hJUkU9bQpDT05GSUdfVE9VQ0hTQ1JFRU5fRlVKSVRTVT1tCiMgQ09ORklHX1RP
VUNIU0NSRUVOX0dVTlpFIGlzIG5vdCBzZXQKIyBDT05GSUdfVE9VQ0hTQ1JFRU5fRUxPIGlz
IG5vdCBzZXQKQ09ORklHX1RPVUNIU0NSRUVOX1dBQ09NX1c4MDAxPW0KIyBDT05GSUdfVE9V
Q0hTQ1JFRU5fTVRPVUNIIGlzIG5vdCBzZXQKIyBDT05GSUdfVE9VQ0hTQ1JFRU5fSU5FWElP
IGlzIG5vdCBzZXQKQ09ORklHX1RPVUNIU0NSRUVOX01LNzEyPW0KQ09ORklHX1RPVUNIU0NS
RUVOX1BFTk1PVU5UPW0KIyBDT05GSUdfVE9VQ0hTQ1JFRU5fVE9VQ0hSSUdIVCBpcyBub3Qg
c2V0CiMgQ09ORklHX1RPVUNIU0NSRUVOX1RPVUNIV0lOIGlzIG5vdCBzZXQKQ09ORklHX1RP
VUNIU0NSRUVOX1dNODMxWD1tCiMgQ09ORklHX1RPVUNIU0NSRUVOX1RPVUNISVQyMTMgaXMg
bm90IHNldAojIENPTkZJR19UT1VDSFNDUkVFTl9UU0NfU0VSSU8gaXMgbm90IHNldAojIENP
TkZJR19UT1VDSFNDUkVFTl9UU0MyMDA1IGlzIG5vdCBzZXQKQ09ORklHX0lOUFVUX01JU0M9
eQpDT05GSUdfSU5QVVRfQUQ3MTRYPW0KQ09ORklHX0lOUFVUX0FENzE0WF9TUEk9bQpDT05G
SUdfSU5QVVRfUENTUEtSPW0KQ09ORklHX0lOUFVUX1VJTlBVVD1tCiMgQ09ORklHX0lOUFVU
X1dNODMxWF9PTiBpcyBub3Qgc2V0CiMgQ09ORklHX0lOUFVUX0FEWEwzNFggaXMgbm90IHNl
dAojIENPTkZJR19JTlBVVF9DTUEzMDAwIGlzIG5vdCBzZXQKQ09ORklHX0lOUFVUX1hFTl9L
QkRERVZfRlJPTlRFTkQ9bQoKIwojIEhhcmR3YXJlIEkvTyBwb3J0cwojCkNPTkZJR19TRVJJ
Tz15CkNPTkZJR19TRVJJT19JODA0Mj15CkNPTkZJR19TRVJJT19TRVJQT1JUPW0KQ09ORklH
X1NFUklPX0NUODJDNzEwPW0KQ09ORklHX1NFUklPX0xJQlBTMj15CiMgQ09ORklHX1NFUklP
X1JBVyBpcyBub3Qgc2V0CkNPTkZJR19TRVJJT19BTFRFUkFfUFMyPW0KQ09ORklHX1NFUklP
X1BTMk1VTFQ9bQpDT05GSUdfR0FNRVBPUlQ9bQojIENPTkZJR19HQU1FUE9SVF9OUzU1OCBp
cyBub3Qgc2V0CiMgQ09ORklHX0dBTUVQT1JUX0w0IGlzIG5vdCBzZXQKCiMKIyBDaGFyYWN0
ZXIgZGV2aWNlcwojCkNPTkZJR19WVD15CkNPTkZJR19DT05TT0xFX1RSQU5TTEFUSU9OUz15
CkNPTkZJR19WVF9DT05TT0xFPXkKQ09ORklHX1ZUX0NPTlNPTEVfU0xFRVA9eQpDT05GSUdf
SFdfQ09OU09MRT15CkNPTkZJR19WVF9IV19DT05TT0xFX0JJTkRJTkc9eQpDT05GSUdfVU5J
WDk4X1BUWVM9eQojIENPTkZJR19ERVZQVFNfTVVMVElQTEVfSU5TVEFOQ0VTIGlzIG5vdCBz
ZXQKQ09ORklHX0xFR0FDWV9QVFlTPXkKQ09ORklHX0xFR0FDWV9QVFlfQ09VTlQ9MjU2CkNP
TkZJR19TRVJJQUxfTk9OU1RBTkRBUkQ9eQojIENPTkZJR19OX0hETEMgaXMgbm90IHNldApD
T05GSUdfVFJBQ0VfUk9VVEVSPW0KQ09ORklHX1RSQUNFX1NJTks9bQojIENPTkZJR19ERVZL
TUVNIGlzIG5vdCBzZXQKQ09ORklHX1NUQUxEUlY9eQoKIwojIFNlcmlhbCBkcml2ZXJzCiMK
Q09ORklHX1NFUklBTF84MjUwPW0KQ09ORklHX0ZJWF9FQVJMWUNPTl9NRU09eQpDT05GSUdf
U0VSSUFMXzgyNTBfTlJfVUFSVFM9NApDT05GSUdfU0VSSUFMXzgyNTBfUlVOVElNRV9VQVJU
Uz00CkNPTkZJR19TRVJJQUxfODI1MF9FWFRFTkRFRD15CiMgQ09ORklHX1NFUklBTF84MjUw
X01BTllfUE9SVFMgaXMgbm90IHNldAojIENPTkZJR19TRVJJQUxfODI1MF9TSEFSRV9JUlEg
aXMgbm90IHNldAojIENPTkZJR19TRVJJQUxfODI1MF9ERVRFQ1RfSVJRIGlzIG5vdCBzZXQK
IyBDT05GSUdfU0VSSUFMXzgyNTBfUlNBIGlzIG5vdCBzZXQKCiMKIyBOb24tODI1MCBzZXJp
YWwgcG9ydCBzdXBwb3J0CiMKQ09ORklHX1NFUklBTF9NQVgzMTAwPW0KIyBDT05GSUdfU0VS
SUFMX01BWDMxMDcgaXMgbm90IHNldApDT05GSUdfU0VSSUFMX0NPUkU9bQojIENPTkZJR19T
RVJJQUxfVElNQkVSREFMRSBpcyBub3Qgc2V0CkNPTkZJR19TRVJJQUxfQUxURVJBX0pUQUdV
QVJUPW0KIyBDT05GSUdfU0VSSUFMX0FMVEVSQV9VQVJUIGlzIG5vdCBzZXQKQ09ORklHX1NF
UklBTF9YSUxJTlhfUFNfVUFSVD1tCkNPTkZJR19IVkNfRFJJVkVSPXkKQ09ORklHX0hWQ19J
UlE9eQpDT05GSUdfSFZDX1hFTj15CkNPTkZJR19WSVJUSU9fQ09OU09MRT1tCiMgQ09ORklH
X0lQTUlfSEFORExFUiBpcyBub3Qgc2V0CkNPTkZJR19IV19SQU5ET009bQojIENPTkZJR19I
V19SQU5ET01fVElNRVJJT01FTSBpcyBub3Qgc2V0CkNPTkZJR19IV19SQU5ET01fVklBPW0K
IyBDT05GSUdfSFdfUkFORE9NX1ZJUlRJTyBpcyBub3Qgc2V0CiMgQ09ORklHX05WUkFNIGlz
IG5vdCBzZXQKIyBDT05GSUdfUjM5NjQgaXMgbm90IHNldApDT05GSUdfTVdBVkU9bQojIENP
TkZJR19SQVdfRFJJVkVSIGlzIG5vdCBzZXQKQ09ORklHX0hBTkdDSEVDS19USU1FUj1tCiMg
Q09ORklHX1JBTU9PUFMgaXMgbm90IHNldAojIENPTkZJR19JMkMgaXMgbm90IHNldApDT05G
SUdfU1BJPXkKQ09ORklHX1NQSV9ERUJVRz15CkNPTkZJR19TUElfTUFTVEVSPXkKCiMKIyBT
UEkgTWFzdGVyIENvbnRyb2xsZXIgRHJpdmVycwojCiMgQ09ORklHX1NQSV9BTFRFUkEgaXMg
bm90IHNldApDT05GSUdfU1BJX0JJVEJBTkc9bQojIENPTkZJR19TUElfUFhBMlhYX1BDSSBp
cyBub3Qgc2V0CkNPTkZJR19TUElfREVTSUdOV0FSRT1tCgojCiMgU1BJIFByb3RvY29sIE1h
c3RlcnMKIwojIENPTkZJR19TUElfVExFNjJYMCBpcyBub3Qgc2V0CkNPTkZJR19IU0k9bQpD
T05GSUdfSFNJX0JPQVJESU5GTz15CgojCiMgSFNJIGNsaWVudHMKIwpDT05GSUdfSFNJX0NI
QVI9bQoKIwojIFBQUyBzdXBwb3J0CiMKCiMKIyBQUFMgZ2VuZXJhdG9ycyBzdXBwb3J0CiMK
CiMKIyBQVFAgY2xvY2sgc3VwcG9ydAojCgojCiMgRW5hYmxlIERldmljZSBEcml2ZXJzIC0+
IFBQUyB0byBzZWUgdGhlIFBUUCBjbG9jayBvcHRpb25zLgojCkNPTkZJR19BUkNIX1dBTlRf
T1BUSU9OQUxfR1BJT0xJQj15CiMgQ09ORklHX0dQSU9MSUIgaXMgbm90IHNldApDT05GSUdf
VzE9bQoKIwojIDEtd2lyZSBCdXMgTWFzdGVycwojCkNPTkZJR19XMV9NQVNURVJfRFMxV009
bQoKIwojIDEtd2lyZSBTbGF2ZXMKIwpDT05GSUdfVzFfU0xBVkVfVEhFUk09bQojIENPTkZJ
R19XMV9TTEFWRV9TTUVNIGlzIG5vdCBzZXQKIyBDT05GSUdfVzFfU0xBVkVfRFMyNDA4IGlz
IG5vdCBzZXQKQ09ORklHX1cxX1NMQVZFX0RTMjQyMz1tCiMgQ09ORklHX1cxX1NMQVZFX0RT
MjQzMSBpcyBub3Qgc2V0CkNPTkZJR19XMV9TTEFWRV9EUzI0MzM9bQpDT05GSUdfVzFfU0xB
VkVfRFMyNDMzX0NSQz15CiMgQ09ORklHX1cxX1NMQVZFX0RTMjc2MCBpcyBub3Qgc2V0CiMg
Q09ORklHX1cxX1NMQVZFX0RTMjc4MCBpcyBub3Qgc2V0CiMgQ09ORklHX1cxX1NMQVZFX0JR
MjcwMDAgaXMgbm90IHNldApDT05GSUdfUE9XRVJfU1VQUExZPW0KIyBDT05GSUdfUE9XRVJf
U1VQUExZX0RFQlVHIGlzIG5vdCBzZXQKIyBDT05GSUdfUERBX1BPV0VSIGlzIG5vdCBzZXQK
Q09ORklHX1dNODMxWF9CQUNLVVA9bQojIENPTkZJR19XTTgzMVhfUE9XRVIgaXMgbm90IHNl
dAojIENPTkZJR19URVNUX1BPV0VSIGlzIG5vdCBzZXQKIyBDT05GSUdfQkFUVEVSWV9EUzI3
ODAgaXMgbm90IHNldApDT05GSUdfQkFUVEVSWV9CUTI3eDAwPW0KIyBDT05GSUdfQkFUVEVS
WV9CUTI3WDAwX1BMQVRGT1JNIGlzIG5vdCBzZXQKIyBDT05GSUdfQ0hBUkdFUl9NQVg4OTAz
IGlzIG5vdCBzZXQKQ09ORklHX0hXTU9OPW0KQ09ORklHX0hXTU9OX1ZJRD1tCkNPTkZJR19I
V01PTl9ERUJVR19DSElQPXkKCiMKIyBOYXRpdmUgZHJpdmVycwojCiMgQ09ORklHX1NFTlNP
UlNfRjcxODA1RiBpcyBub3Qgc2V0CkNPTkZJR19TRU5TT1JTX0Y3MTg4MkZHPW0KIyBDT05G
SUdfU0VOU09SU19JVDg3IGlzIG5vdCBzZXQKQ09ORklHX1NFTlNPUlNfTE03MD1tCiMgQ09O
RklHX1NFTlNPUlNfTUFYMTExMSBpcyBub3Qgc2V0CkNPTkZJR19TRU5TT1JTX1BDODczNjA9
bQpDT05GSUdfU0VOU09SU19QQzg3NDI3PW0KQ09ORklHX1NFTlNPUlNfU01TQzQ3TTE9bQpD
T05GSUdfU0VOU09SU19TQ0g1NlhYX0NPTU1PTj1tCkNPTkZJR19TRU5TT1JTX1NDSDU2Mjc9
bQojIENPTkZJR19TRU5TT1JTX1NDSDU2MzYgaXMgbm90IHNldApDT05GSUdfU0VOU09SU19B
RFM3ODcxPW0KIyBDT05GSUdfU0VOU09SU19WSUFfQ1BVVEVNUCBpcyBub3Qgc2V0CiMgQ09O
RklHX1NFTlNPUlNfVlQxMjExIGlzIG5vdCBzZXQKQ09ORklHX1NFTlNPUlNfVzgzNjI3SEY9
bQojIENPTkZJR19TRU5TT1JTX1c4MzYyN0VIRiBpcyBub3Qgc2V0CiMgQ09ORklHX1NFTlNP
UlNfV004MzFYIGlzIG5vdCBzZXQKQ09ORklHX1NFTlNPUlNfQVBQTEVTTUM9bQpDT05GSUdf
VEhFUk1BTD1tCkNPTkZJR19USEVSTUFMX0hXTU9OPXkKQ09ORklHX1dBVENIRE9HPXkKIyBD
T05GSUdfV0FUQ0hET0dfQ09SRSBpcyBub3Qgc2V0CiMgQ09ORklHX1dBVENIRE9HX05PV0FZ
T1VUIGlzIG5vdCBzZXQKCiMKIyBXYXRjaGRvZyBEZXZpY2UgRHJpdmVycwojCkNPTkZJR19T
T0ZUX1dBVENIRE9HPW0KIyBDT05GSUdfV004MzFYX1dBVENIRE9HIGlzIG5vdCBzZXQKIyBD
T05GSUdfQUNRVUlSRV9XRFQgaXMgbm90IHNldAojIENPTkZJR19BRFZBTlRFQ0hfV0RUIGlz
IG5vdCBzZXQKIyBDT05GSUdfU0M1MjBfV0RUIGlzIG5vdCBzZXQKQ09ORklHX1NCQ19GSVRQ
QzJfV0FUQ0hET0c9bQojIENPTkZJR19FVVJPVEVDSF9XRFQgaXMgbm90IHNldApDT05GSUdf
SUI3MDBfV0RUPW0KIyBDT05GSUdfSUJNQVNSIGlzIG5vdCBzZXQKQ09ORklHX1dBRkVSX1dE
VD1tCkNPTkZJR19JVDg3MTJGX1dEVD1tCiMgQ09ORklHX1NDMTIwMF9XRFQgaXMgbm90IHNl
dAojIENPTkZJR19QQzg3NDEzX1dEVCBpcyBub3Qgc2V0CiMgQ09ORklHXzYwWFhfV0RUIGlz
IG5vdCBzZXQKQ09ORklHX1NCQzgzNjBfV0RUPW0KQ09ORklHX0NQVTVfV0RUPW0KQ09ORklH
X1NNU0NfU0NIMzExWF9XRFQ9bQojIENPTkZJR19TTVNDMzdCNzg3X1dEVCBpcyBub3Qgc2V0
CiMgQ09ORklHX1c4MzYyN0hGX1dEVCBpcyBub3Qgc2V0CkNPTkZJR19XODM2OTdIRl9XRFQ9
bQpDT05GSUdfVzgzNjk3VUdfV0RUPW0KQ09ORklHX1c4Mzg3N0ZfV0RUPW0KIyBDT05GSUdf
VzgzOTc3Rl9XRFQgaXMgbm90IHNldAojIENPTkZJR19NQUNIWl9XRFQgaXMgbm90IHNldAoj
IENPTkZJR19TQkNfRVBYX0MzX1dBVENIRE9HIGlzIG5vdCBzZXQKIyBDT05GSUdfWEVOX1dE
VCBpcyBub3Qgc2V0CkNPTkZJR19TU0JfUE9TU0lCTEU9eQoKIwojIFNvbmljcyBTaWxpY29u
IEJhY2twbGFuZQojCiMgQ09ORklHX1NTQiBpcyBub3Qgc2V0CkNPTkZJR19CQ01BX1BPU1NJ
QkxFPXkKCiMKIyBCcm9hZGNvbSBzcGVjaWZpYyBBTUJBCiMKQ09ORklHX0JDTUE9bQpDT05G
SUdfQkNNQV9ERUJVRz15CgojCiMgTXVsdGlmdW5jdGlvbiBkZXZpY2UgZHJpdmVycwojCkNP
TkZJR19NRkRfQ09SRT15CkNPTkZJR19NRkRfU001MDE9bQpDT05GSUdfSFRDX1BBU0lDMz1t
CiMgQ09ORklHX01GRF9UTUlPIGlzIG5vdCBzZXQKQ09ORklHX01GRF9XTTgzMVg9eQpDT05G
SUdfTUZEX1dNODMxWF9TUEk9eQojIENPTkZJR19NRkRfTUMxM1hYWCBpcyBub3Qgc2V0CkNP
TkZJR19BQlg1MDBfQ09SRT15CiMgQ09ORklHX0VaWF9QQ0FQIGlzIG5vdCBzZXQKIyBDT05G
SUdfQUI4NTAwX0NPUkUgaXMgbm90IHNldAojIENPTkZJR19SRUdVTEFUT1IgaXMgbm90IHNl
dAojIENPTkZJR19NRURJQV9TVVBQT1JUIGlzIG5vdCBzZXQKCiMKIyBHcmFwaGljcyBzdXBw
b3J0CiMKIyBDT05GSUdfRFJNIGlzIG5vdCBzZXQKQ09ORklHX1ZHQVNUQVRFPW0KIyBDT05G
SUdfVklERU9fT1VUUFVUX0NPTlRST0wgaXMgbm90IHNldApDT05GSUdfRkI9bQojIENPTkZJ
R19GSVJNV0FSRV9FRElEIGlzIG5vdCBzZXQKIyBDT05GSUdfRkJfRERDIGlzIG5vdCBzZXQK
IyBDT05GSUdfRkJfQk9PVF9WRVNBX1NVUFBPUlQgaXMgbm90IHNldApDT05GSUdfRkJfQ0ZC
X0ZJTExSRUNUPW0KQ09ORklHX0ZCX0NGQl9DT1BZQVJFQT1tCkNPTkZJR19GQl9DRkJfSU1B
R0VCTElUPW0KIyBDT05GSUdfRkJfQ0ZCX1JFVl9QSVhFTFNfSU5fQllURSBpcyBub3Qgc2V0
CkNPTkZJR19GQl9TWVNfRklMTFJFQ1Q9bQpDT05GSUdfRkJfU1lTX0NPUFlBUkVBPW0KQ09O
RklHX0ZCX1NZU19JTUFHRUJMSVQ9bQpDT05GSUdfRkJfRk9SRUlHTl9FTkRJQU49eQojIENP
TkZJR19GQl9CT1RIX0VORElBTiBpcyBub3Qgc2V0CiMgQ09ORklHX0ZCX0JJR19FTkRJQU4g
aXMgbm90IHNldApDT05GSUdfRkJfTElUVExFX0VORElBTj15CkNPTkZJR19GQl9TWVNfRk9Q
Uz1tCiMgQ09ORklHX0ZCX1dNVF9HRV9ST1BTIGlzIG5vdCBzZXQKQ09ORklHX0ZCX0RFRkVS
UkVEX0lPPXkKQ09ORklHX0ZCX0hFQ1VCQT1tCiMgQ09ORklHX0ZCX1NWR0FMSUIgaXMgbm90
IHNldAojIENPTkZJR19GQl9NQUNNT0RFUyBpcyBub3Qgc2V0CiMgQ09ORklHX0ZCX0JBQ0tM
SUdIVCBpcyBub3Qgc2V0CiMgQ09ORklHX0ZCX01PREVfSEVMUEVSUyBpcyBub3Qgc2V0CiMg
Q09ORklHX0ZCX1RJTEVCTElUVElORyBpcyBub3Qgc2V0CgojCiMgRnJhbWUgYnVmZmVyIGhh
cmR3YXJlIGRyaXZlcnMKIwpDT05GSUdfRkJfQVJDPW0KQ09ORklHX0ZCX1ZHQTE2PW0KQ09O
RklHX0ZCX040MTE9bQojIENPTkZJR19GQl9IR0EgaXMgbm90IHNldApDT05GSUdfRkJfUzFE
MTNYWFg9bQpDT05GSUdfRkJfVE1JTz1tCiMgQ09ORklHX0ZCX1RNSU9fQUNDRUxMIGlzIG5v
dCBzZXQKIyBDT05GSUdfRkJfU001MDEgaXMgbm90IHNldAojIENPTkZJR19GQl9WSVJUVUFM
IGlzIG5vdCBzZXQKQ09ORklHX1hFTl9GQkRFVl9GUk9OVEVORD1tCkNPTkZJR19GQl9NRVRS
T05PTUU9bQpDT05GSUdfRkJfQlJPQURTSEVFVD1tCkNPTkZJR19CQUNLTElHSFRfTENEX1NV
UFBPUlQ9eQpDT05GSUdfTENEX0NMQVNTX0RFVklDRT1tCiMgQ09ORklHX0xDRF9MVFYzNTBR
ViBpcyBub3Qgc2V0CkNPTkZJR19MQ0RfSUxJOTMyMD1tCkNPTkZJR19MQ0RfVERPMjRNPW0K
Q09ORklHX0xDRF9WR0cyNDMyQTQ9bQojIENPTkZJR19MQ0RfUExBVEZPUk0gaXMgbm90IHNl
dApDT05GSUdfTENEX1M2RTYzTTA9bQpDT05GSUdfTENEX0xEOTA0MD1tCkNPTkZJR19MQ0Rf
QU1TMzY5RkcwNj1tCkNPTkZJR19CQUNLTElHSFRfQ0xBU1NfREVWSUNFPW0KQ09ORklHX0JB
Q0tMSUdIVF9HRU5FUklDPW0KIyBDT05GSUdfQkFDS0xJR0hUX1NBSEFSQSBpcyBub3Qgc2V0
CiMgQ09ORklHX0JBQ0tMSUdIVF9XTTgzMVggaXMgbm90IHNldAoKIwojIENvbnNvbGUgZGlz
cGxheSBkcml2ZXIgc3VwcG9ydAojCkNPTkZJR19WR0FfQ09OU09MRT15CiMgQ09ORklHX1ZH
QUNPTl9TT0ZUX1NDUk9MTEJBQ0sgaXMgbm90IHNldApDT05GSUdfRFVNTVlfQ09OU09MRT15
CkNPTkZJR19GUkFNRUJVRkZFUl9DT05TT0xFPW0KQ09ORklHX0ZSQU1FQlVGRkVSX0NPTlNP
TEVfREVURUNUX1BSSU1BUlk9eQojIENPTkZJR19GUkFNRUJVRkZFUl9DT05TT0xFX1JPVEFU
SU9OIGlzIG5vdCBzZXQKQ09ORklHX0ZPTlRTPXkKIyBDT05GSUdfRk9OVF84eDggaXMgbm90
IHNldApDT05GSUdfRk9OVF84eDE2PXkKIyBDT05GSUdfRk9OVF82eDExIGlzIG5vdCBzZXQK
IyBDT05GSUdfRk9OVF83eDE0IGlzIG5vdCBzZXQKQ09ORklHX0ZPTlRfUEVBUkxfOHg4PXkK
IyBDT05GSUdfRk9OVF9BQ09STl84eDggaXMgbm90IHNldAojIENPTkZJR19GT05UX01JTklf
NHg2IGlzIG5vdCBzZXQKQ09ORklHX0ZPTlRfU1VOOHgxNj15CkNPTkZJR19GT05UX1NVTjEy
eDIyPXkKQ09ORklHX0ZPTlRfMTB4MTg9eQpDT05GSUdfTE9HTz15CkNPTkZJR19MT0dPX0xJ
TlVYX01PTk89eQpDT05GSUdfTE9HT19MSU5VWF9WR0ExNj15CiMgQ09ORklHX0xPR09fTElO
VVhfQ0xVVDIyNCBpcyBub3Qgc2V0CiMgQ09ORklHX1NPVU5EIGlzIG5vdCBzZXQKQ09ORklH
X0hJRF9TVVBQT1JUPXkKIyBDT05GSUdfSElEIGlzIG5vdCBzZXQKQ09ORklHX0hJRF9CQVRU
RVJZX1NUUkVOR1RIPXkKIyBDT05GSUdfSElEX1BJRCBpcyBub3Qgc2V0CiMgQ09ORklHX1VT
Ql9TVVBQT1JUIGlzIG5vdCBzZXQKQ09ORklHX01NQz1tCkNPTkZJR19NTUNfREVCVUc9eQpD
T05GSUdfTU1DX1VOU0FGRV9SRVNVTUU9eQoKIwojIE1NQy9TRC9TRElPIENhcmQgRHJpdmVy
cwojCkNPTkZJR19NTUNfQkxPQ0s9bQpDT05GSUdfTU1DX0JMT0NLX01JTk9SUz04CiMgQ09O
RklHX01NQ19CTE9DS19CT1VOQ0UgaXMgbm90IHNldAojIENPTkZJR19TRElPX1VBUlQgaXMg
bm90IHNldApDT05GSUdfTU1DX1RFU1Q9bQoKIwojIE1NQy9TRC9TRElPIEhvc3QgQ29udHJv
bGxlciBEcml2ZXJzCiMKIyBDT05GSUdfTU1DX1NESENJIGlzIG5vdCBzZXQKQ09ORklHX01N
Q19XQlNEPW0KQ09ORklHX01NQ19TUEk9bQpDT05GSUdfTUVNU1RJQ0s9bQojIENPTkZJR19N
RU1TVElDS19ERUJVRyBpcyBub3Qgc2V0CgojCiMgTWVtb3J5U3RpY2sgZHJpdmVycwojCkNP
TkZJR19NRU1TVElDS19VTlNBRkVfUkVTVU1FPXkKQ09ORklHX01TUFJPX0JMT0NLPW0KCiMK
IyBNZW1vcnlTdGljayBIb3N0IENvbnRyb2xsZXIgRHJpdmVycwojCkNPTkZJR19ORVdfTEVE
Uz15CkNPTkZJR19MRURTX0NMQVNTPXkKCiMKIyBMRUQgZHJpdmVycwojCkNPTkZJR19MRURT
X0NMRVZPX01BSUw9bQojIENPTkZJR19MRURTX1dNODMxWF9TVEFUVVMgaXMgbm90IHNldAoj
IENPTkZJR19MRURTX0RBQzEyNFMwODUgaXMgbm90IHNldApDT05GSUdfTEVEU19UUklHR0VS
Uz15CgojCiMgTEVEIFRyaWdnZXJzCiMKQ09ORklHX0xFRFNfVFJJR0dFUl9USU1FUj1tCkNP
TkZJR19MRURTX1RSSUdHRVJfSEVBUlRCRUFUPW0KIyBDT05GSUdfTEVEU19UUklHR0VSX0JB
Q0tMSUdIVCBpcyBub3Qgc2V0CiMgQ09ORklHX0xFRFNfVFJJR0dFUl9ERUZBVUxUX09OIGlz
IG5vdCBzZXQKCiMKIyBpcHRhYmxlcyB0cmlnZ2VyIGlzIHVuZGVyIE5ldGZpbHRlciBjb25m
aWcgKExFRCB0YXJnZXQpCiMKQ09ORklHX0FDQ0VTU0lCSUxJVFk9eQojIENPTkZJR19FREFD
IGlzIG5vdCBzZXQKQ09ORklHX1JUQ19MSUI9eQpDT05GSUdfUlRDX0NMQVNTPXkKIyBDT05G
SUdfUlRDX0hDVE9TWVMgaXMgbm90IHNldApDT05GSUdfUlRDX0RFQlVHPXkKCiMKIyBSVEMg
aW50ZXJmYWNlcwojCiMgQ09ORklHX1JUQ19JTlRGX1NZU0ZTIGlzIG5vdCBzZXQKIyBDT05G
SUdfUlRDX0lOVEZfUFJPQyBpcyBub3Qgc2V0CkNPTkZJR19SVENfSU5URl9ERVY9eQojIENP
TkZJR19SVENfSU5URl9ERVZfVUlFX0VNVUwgaXMgbm90IHNldApDT05GSUdfUlRDX0RSVl9U
RVNUPW0KCiMKIyBTUEkgUlRDIGRyaXZlcnMKIwpDT05GSUdfUlRDX0RSVl9NNDFUOTM9bQpD
T05GSUdfUlRDX0RSVl9NNDFUOTQ9bQojIENPTkZJR19SVENfRFJWX0RTMTMwNSBpcyBub3Qg
c2V0CiMgQ09ORklHX1JUQ19EUlZfRFMxMzkwIGlzIG5vdCBzZXQKQ09ORklHX1JUQ19EUlZf
TUFYNjkwMj1tCiMgQ09ORklHX1JUQ19EUlZfUjk3MDEgaXMgbm90IHNldApDT05GSUdfUlRD
X0RSVl9SUzVDMzQ4PW0KIyBDT05GSUdfUlRDX0RSVl9EUzMyMzQgaXMgbm90IHNldApDT05G
SUdfUlRDX0RSVl9QQ0YyMTIzPW0KCiMKIyBQbGF0Zm9ybSBSVEMgZHJpdmVycwojCiMgQ09O
RklHX1JUQ19EUlZfQ01PUyBpcyBub3Qgc2V0CiMgQ09ORklHX1JUQ19EUlZfRFMxMjg2IGlz
IG5vdCBzZXQKIyBDT05GSUdfUlRDX0RSVl9EUzE1MTEgaXMgbm90IHNldApDT05GSUdfUlRD
X0RSVl9EUzE1NTM9bQojIENPTkZJR19SVENfRFJWX0RTMTc0MiBpcyBub3Qgc2V0CkNPTkZJ
R19SVENfRFJWX1NUSzE3VEE4PW0KIyBDT05GSUdfUlRDX0RSVl9NNDhUODYgaXMgbm90IHNl
dAojIENPTkZJR19SVENfRFJWX000OFQzNSBpcyBub3Qgc2V0CiMgQ09ORklHX1JUQ19EUlZf
TTQ4VDU5IGlzIG5vdCBzZXQKIyBDT05GSUdfUlRDX0RSVl9NU002MjQyIGlzIG5vdCBzZXQK
Q09ORklHX1JUQ19EUlZfQlE0ODAyPW0KIyBDT05GSUdfUlRDX0RSVl9SUDVDMDEgaXMgbm90
IHNldAojIENPTkZJR19SVENfRFJWX1YzMDIwIGlzIG5vdCBzZXQKQ09ORklHX1JUQ19EUlZf
V004MzFYPW0KCiMKIyBvbi1DUFUgUlRDIGRyaXZlcnMKIwpDT05GSUdfRE1BREVWSUNFUz15
CiMgQ09ORklHX0RNQURFVklDRVNfREVCVUcgaXMgbm90IHNldAoKIwojIERNQSBEZXZpY2Vz
CiMKIyBDT05GSUdfVElNQl9ETUEgaXMgbm90IHNldApDT05GSUdfQVVYRElTUExBWT15CkNP
TkZJR19VSU89bQpDT05GSUdfVUlPX1BEUlY9bQpDT05GSUdfVUlPX1BEUlZfR0VOSVJRPW0K
Q09ORklHX1ZJUlRJTz1tCkNPTkZJR19WSVJUSU9fUklORz1tCgojCiMgVmlydGlvIGRyaXZl
cnMKIwpDT05GSUdfVklSVElPX0JBTExPT049bQoKIwojIE1pY3Jvc29mdCBIeXBlci1WIGd1
ZXN0IHN1cHBvcnQKIwoKIwojIFhlbiBkcml2ZXIgc3VwcG9ydAojCiMgQ09ORklHX1hFTl9C
QUxMT09OIGlzIG5vdCBzZXQKIyBDT05GSUdfWEVOX0RFVl9FVlRDSE4gaXMgbm90IHNldAoj
IENPTkZJR19YRU5GUyBpcyBub3Qgc2V0CkNPTkZJR19YRU5fU1lTX0hZUEVSVklTT1I9eQpD
T05GSUdfWEVOX1hFTkJVU19GUk9OVEVORD1tCkNPTkZJR19YRU5fR05UREVWPW0KQ09ORklH
X1hFTl9HUkFOVF9ERVZfQUxMT0M9bQpDT05GSUdfWEVOX1BSSVZDTUQ9bQojIENPTkZJR19T
VEFHSU5HIGlzIG5vdCBzZXQKIyBDT05GSUdfWDg2X1BMQVRGT1JNX0RFVklDRVMgaXMgbm90
IHNldAoKIwojIEhhcmR3YXJlIFNwaW5sb2NrIGRyaXZlcnMKIwpDT05GSUdfQ0xLRVZUX0k4
MjUzPXkKQ09ORklHX0k4MjUzX0xPQ0s9eQpDT05GSUdfQ0xLQkxEX0k4MjUzPXkKIyBDT05G
SUdfSU9NTVVfU1VQUE9SVCBpcyBub3Qgc2V0CiMgQ09ORklHX1ZJUlRfRFJJVkVSUyBpcyBu
b3Qgc2V0CiMgQ09ORklHX1BNX0RFVkZSRVEgaXMgbm90IHNldAoKIwojIEZpcm13YXJlIERy
aXZlcnMKIwpDT05GSUdfRUREPW0KIyBDT05GSUdfRUREX09GRiBpcyBub3Qgc2V0CkNPTkZJ
R19GSVJNV0FSRV9NRU1NQVA9eQojIENPTkZJR19ERUxMX1JCVSBpcyBub3Qgc2V0CiMgQ09O
RklHX0RDREJBUyBpcyBub3Qgc2V0CiMgQ09ORklHX0RNSUlEIGlzIG5vdCBzZXQKQ09ORklH
X0RNSV9TWVNGUz1tCkNPTkZJR19JU0NTSV9JQkZUX0ZJTkQ9eQpDT05GSUdfR09PR0xFX0ZJ
Uk1XQVJFPXkKCiMKIyBHb29nbGUgRmlybXdhcmUgRHJpdmVycwojCiMgQ09ORklHX0dPT0dM
RV9NRU1DT05TT0xFIGlzIG5vdCBzZXQKCiMKIyBGaWxlIHN5c3RlbXMKIwojIENPTkZJR19F
WFQyX0ZTIGlzIG5vdCBzZXQKQ09ORklHX0VYVDNfRlM9bQojIENPTkZJR19FWFQzX0RFRkFV
TFRTX1RPX09SREVSRUQgaXMgbm90IHNldAojIENPTkZJR19FWFQzX0ZTX1hBVFRSIGlzIG5v
dCBzZXQKQ09ORklHX0VYVDRfRlM9bQpDT05GSUdfRVhUNF9VU0VfRk9SX0VYVDIzPXkKIyBD
T05GSUdfRVhUNF9GU19YQVRUUiBpcyBub3Qgc2V0CiMgQ09ORklHX0VYVDRfREVCVUcgaXMg
bm90IHNldApDT05GSUdfSkJEPW0KIyBDT05GSUdfSkJEX0RFQlVHIGlzIG5vdCBzZXQKQ09O
RklHX0pCRDI9bQpDT05GSUdfSkJEMl9ERUJVRz15CiMgQ09ORklHX1JFSVNFUkZTX0ZTIGlz
IG5vdCBzZXQKIyBDT05GSUdfSkZTX0ZTIGlzIG5vdCBzZXQKIyBDT05GSUdfWEZTX0ZTIGlz
IG5vdCBzZXQKIyBDT05GSUdfR0ZTMl9GUyBpcyBub3Qgc2V0CiMgQ09ORklHX09DRlMyX0ZT
IGlzIG5vdCBzZXQKQ09ORklHX0ZTX1BPU0lYX0FDTD15CkNPTkZJR19FWFBPUlRGUz15CkNP
TkZJR19GSUxFX0xPQ0tJTkc9eQpDT05GSUdfRlNOT1RJRlk9eQojIENPTkZJR19ETk9USUZZ
IGlzIG5vdCBzZXQKQ09ORklHX0lOT1RJRllfVVNFUj15CkNPTkZJR19GQU5PVElGWT15CiMg
Q09ORklHX1FVT1RBIGlzIG5vdCBzZXQKIyBDT05GSUdfUVVPVEFDVEwgaXMgbm90IHNldAoj
IENPTkZJR19BVVRPRlM0X0ZTIGlzIG5vdCBzZXQKIyBDT05GSUdfRlVTRV9GUyBpcyBub3Qg
c2V0CkNPTkZJR19HRU5FUklDX0FDTD15CgojCiMgQ2FjaGVzCiMKQ09ORklHX0ZTQ0FDSEU9
bQpDT05GSUdfRlNDQUNIRV9TVEFUUz15CiMgQ09ORklHX0ZTQ0FDSEVfSElTVE9HUkFNIGlz
IG5vdCBzZXQKQ09ORklHX0ZTQ0FDSEVfREVCVUc9eQojIENPTkZJR19GU0NBQ0hFX09CSkVD
VF9MSVNUIGlzIG5vdCBzZXQKIyBDT05GSUdfQ0FDSEVGSUxFUyBpcyBub3Qgc2V0CgojCiMg
Q0QtUk9NL0RWRCBGaWxlc3lzdGVtcwojCkNPTkZJR19JU085NjYwX0ZTPW0KIyBDT05GSUdf
Sk9MSUVUIGlzIG5vdCBzZXQKIyBDT05GSUdfWklTT0ZTIGlzIG5vdCBzZXQKQ09ORklHX1VE
Rl9GUz1tCkNPTkZJR19VREZfTkxTPXkKCiMKIyBET1MvRkFUL05UIEZpbGVzeXN0ZW1zCiMK
IyBDT05GSUdfTVNET1NfRlMgaXMgbm90IHNldAojIENPTkZJR19WRkFUX0ZTIGlzIG5vdCBz
ZXQKQ09ORklHX05URlNfRlM9bQpDT05GSUdfTlRGU19ERUJVRz15CiMgQ09ORklHX05URlNf
UlcgaXMgbm90IHNldAoKIwojIFBzZXVkbyBmaWxlc3lzdGVtcwojCkNPTkZJR19QUk9DX0ZT
PXkKQ09ORklHX1BST0NfS0NPUkU9eQojIENPTkZJR19QUk9DX1ZNQ09SRSBpcyBub3Qgc2V0
CkNPTkZJR19QUk9DX1NZU0NUTD15CkNPTkZJR19QUk9DX1BBR0VfTU9OSVRPUj15CkNPTkZJ
R19TWVNGUz15CkNPTkZJR19UTVBGUz15CkNPTkZJR19UTVBGU19QT1NJWF9BQ0w9eQpDT05G
SUdfVE1QRlNfWEFUVFI9eQpDT05GSUdfSFVHRVRMQkZTPXkKQ09ORklHX0hVR0VUTEJfUEFH
RT15CkNPTkZJR19DT05GSUdGU19GUz1tCiMgQ09ORklHX01JU0NfRklMRVNZU1RFTVMgaXMg
bm90IHNldApDT05GSUdfTkVUV09SS19GSUxFU1lTVEVNUz15CkNPTkZJR19OQ1BfRlM9bQpD
T05GSUdfTkNQRlNfUEFDS0VUX1NJR05JTkc9eQpDT05GSUdfTkNQRlNfSU9DVExfTE9DS0lO
Rz15CkNPTkZJR19OQ1BGU19TVFJPTkc9eQojIENPTkZJR19OQ1BGU19ORlNfTlMgaXMgbm90
IHNldApDT05GSUdfTkNQRlNfT1MyX05TPXkKIyBDT05GSUdfTkNQRlNfU01BTExET1MgaXMg
bm90IHNldApDT05GSUdfTkNQRlNfTkxTPXkKIyBDT05GSUdfTkNQRlNfRVhUUkFTIGlzIG5v
dCBzZXQKCiMKIyBQYXJ0aXRpb24gVHlwZXMKIwpDT05GSUdfUEFSVElUSU9OX0FEVkFOQ0VE
PXkKIyBDT05GSUdfQUNPUk5fUEFSVElUSU9OIGlzIG5vdCBzZXQKIyBDT05GSUdfT1NGX1BB
UlRJVElPTiBpcyBub3Qgc2V0CiMgQ09ORklHX0FNSUdBX1BBUlRJVElPTiBpcyBub3Qgc2V0
CkNPTkZJR19BVEFSSV9QQVJUSVRJT049eQpDT05GSUdfTUFDX1BBUlRJVElPTj15CkNPTkZJ
R19NU0RPU19QQVJUSVRJT049eQpDT05GSUdfQlNEX0RJU0tMQUJFTD15CiMgQ09ORklHX01J
TklYX1NVQlBBUlRJVElPTiBpcyBub3Qgc2V0CkNPTkZJR19TT0xBUklTX1g4Nl9QQVJUSVRJ
T049eQpDT05GSUdfVU5JWFdBUkVfRElTS0xBQkVMPXkKQ09ORklHX0xETV9QQVJUSVRJT049
eQojIENPTkZJR19MRE1fREVCVUcgaXMgbm90IHNldApDT05GSUdfU0dJX1BBUlRJVElPTj15
CkNPTkZJR19VTFRSSVhfUEFSVElUSU9OPXkKIyBDT05GSUdfU1VOX1BBUlRJVElPTiBpcyBu
b3Qgc2V0CiMgQ09ORklHX0tBUk1BX1BBUlRJVElPTiBpcyBub3Qgc2V0CiMgQ09ORklHX0VG
SV9QQVJUSVRJT04gaXMgbm90IHNldAojIENPTkZJR19TWVNWNjhfUEFSVElUSU9OIGlzIG5v
dCBzZXQKQ09ORklHX05MUz15CkNPTkZJR19OTFNfREVGQVVMVD0iaXNvODg1OS0xIgpDT05G
SUdfTkxTX0NPREVQQUdFXzQzNz1tCkNPTkZJR19OTFNfQ09ERVBBR0VfNzM3PW0KIyBDT05G
SUdfTkxTX0NPREVQQUdFXzc3NSBpcyBub3Qgc2V0CkNPTkZJR19OTFNfQ09ERVBBR0VfODUw
PW0KIyBDT05GSUdfTkxTX0NPREVQQUdFXzg1MiBpcyBub3Qgc2V0CkNPTkZJR19OTFNfQ09E
RVBBR0VfODU1PW0KIyBDT05GSUdfTkxTX0NPREVQQUdFXzg1NyBpcyBub3Qgc2V0CkNPTkZJ
R19OTFNfQ09ERVBBR0VfODYwPW0KQ09ORklHX05MU19DT0RFUEFHRV84NjE9bQojIENPTkZJ
R19OTFNfQ09ERVBBR0VfODYyIGlzIG5vdCBzZXQKIyBDT05GSUdfTkxTX0NPREVQQUdFXzg2
MyBpcyBub3Qgc2V0CiMgQ09ORklHX05MU19DT0RFUEFHRV84NjQgaXMgbm90IHNldApDT05G
SUdfTkxTX0NPREVQQUdFXzg2NT1tCkNPTkZJR19OTFNfQ09ERVBBR0VfODY2PW0KIyBDT05G
SUdfTkxTX0NPREVQQUdFXzg2OSBpcyBub3Qgc2V0CkNPTkZJR19OTFNfQ09ERVBBR0VfOTM2
PW0KQ09ORklHX05MU19DT0RFUEFHRV85NTA9bQojIENPTkZJR19OTFNfQ09ERVBBR0VfOTMy
IGlzIG5vdCBzZXQKIyBDT05GSUdfTkxTX0NPREVQQUdFXzk0OSBpcyBub3Qgc2V0CkNPTkZJ
R19OTFNfQ09ERVBBR0VfODc0PW0KQ09ORklHX05MU19JU084ODU5Xzg9bQpDT05GSUdfTkxT
X0NPREVQQUdFXzEyNTA9bQpDT05GSUdfTkxTX0NPREVQQUdFXzEyNTE9bQpDT05GSUdfTkxT
X0FTQ0lJPW0KQ09ORklHX05MU19JU084ODU5XzE9bQpDT05GSUdfTkxTX0lTTzg4NTlfMj1t
CkNPTkZJR19OTFNfSVNPODg1OV8zPW0KQ09ORklHX05MU19JU084ODU5XzQ9bQojIENPTkZJ
R19OTFNfSVNPODg1OV81IGlzIG5vdCBzZXQKQ09ORklHX05MU19JU084ODU5XzY9bQpDT05G
SUdfTkxTX0lTTzg4NTlfNz1tCkNPTkZJR19OTFNfSVNPODg1OV85PW0KQ09ORklHX05MU19J
U084ODU5XzEzPW0KIyBDT05GSUdfTkxTX0lTTzg4NTlfMTQgaXMgbm90IHNldAojIENPTkZJ
R19OTFNfSVNPODg1OV8xNSBpcyBub3Qgc2V0CiMgQ09ORklHX05MU19LT0k4X1IgaXMgbm90
IHNldAojIENPTkZJR19OTFNfS09JOF9VIGlzIG5vdCBzZXQKQ09ORklHX05MU19VVEY4PW0K
CiMKIyBLZXJuZWwgaGFja2luZwojCkNPTkZJR19UUkFDRV9JUlFGTEFHU19TVVBQT1JUPXkK
IyBDT05GSUdfUFJJTlRLX1RJTUUgaXMgbm90IHNldApDT05GSUdfREVGQVVMVF9NRVNTQUdF
X0xPR0xFVkVMPTQKQ09ORklHX0VOQUJMRV9XQVJOX0RFUFJFQ0FURUQ9eQojIENPTkZJR19F
TkFCTEVfTVVTVF9DSEVDSyBpcyBub3Qgc2V0CkNPTkZJR19GUkFNRV9XQVJOPTIwNDgKIyBD
T05GSUdfTUFHSUNfU1lTUlEgaXMgbm90IHNldAojIENPTkZJR19TVFJJUF9BU01fU1lNUyBp
cyBub3Qgc2V0CkNPTkZJR19VTlVTRURfU1lNQk9MUz15CkNPTkZJR19ERUJVR19GUz15CkNP
TkZJR19IRUFERVJTX0NIRUNLPXkKIyBDT05GSUdfREVCVUdfU0VDVElPTl9NSVNNQVRDSCBp
cyBub3Qgc2V0CkNPTkZJR19ERUJVR19LRVJORUw9eQpDT05GSUdfREVCVUdfU0hJUlE9eQpD
T05GSUdfTE9DS1VQX0RFVEVDVE9SPXkKQ09ORklHX0hBUkRMT0NLVVBfREVURUNUT1I9eQoj
IENPTkZJR19CT09UUEFSQU1fSEFSRExPQ0tVUF9QQU5JQyBpcyBub3Qgc2V0CkNPTkZJR19C
T09UUEFSQU1fSEFSRExPQ0tVUF9QQU5JQ19WQUxVRT0wCkNPTkZJR19CT09UUEFSQU1fU09G
VExPQ0tVUF9QQU5JQz15CkNPTkZJR19CT09UUEFSQU1fU09GVExPQ0tVUF9QQU5JQ19WQUxV
RT0xCkNPTkZJR19ERVRFQ1RfSFVOR19UQVNLPXkKQ09ORklHX0RFRkFVTFRfSFVOR19UQVNL
X1RJTUVPVVQ9MTIwCkNPTkZJR19CT09UUEFSQU1fSFVOR19UQVNLX1BBTklDPXkKQ09ORklH
X0JPT1RQQVJBTV9IVU5HX1RBU0tfUEFOSUNfVkFMVUU9MQojIENPTkZJR19TQ0hFRF9ERUJV
RyBpcyBub3Qgc2V0CkNPTkZJR19TQ0hFRFNUQVRTPXkKIyBDT05GSUdfVElNRVJfU1RBVFMg
aXMgbm90IHNldApDT05GSUdfREVCVUdfT0JKRUNUUz15CiMgQ09ORklHX0RFQlVHX09CSkVD
VFNfU0VMRlRFU1QgaXMgbm90IHNldAojIENPTkZJR19ERUJVR19PQkpFQ1RTX0ZSRUUgaXMg
bm90IHNldAojIENPTkZJR19ERUJVR19PQkpFQ1RTX1RJTUVSUyBpcyBub3Qgc2V0CkNPTkZJ
R19ERUJVR19PQkpFQ1RTX1dPUks9eQojIENPTkZJR19ERUJVR19PQkpFQ1RTX1JDVV9IRUFE
IGlzIG5vdCBzZXQKQ09ORklHX0RFQlVHX09CSkVDVFNfUEVSQ1BVX0NPVU5URVI9eQpDT05G
SUdfREVCVUdfT0JKRUNUU19FTkFCTEVfREVGQVVMVD0xCkNPTkZJR19TTFVCX0RFQlVHX09O
PXkKIyBDT05GSUdfU0xVQl9TVEFUUyBpcyBub3Qgc2V0CkNPTkZJR19ERUJVR19QUkVFTVBU
PXkKQ09ORklHX0RFQlVHX1JUX01VVEVYRVM9eQpDT05GSUdfREVCVUdfUElfTElTVD15CiMg
Q09ORklHX1JUX01VVEVYX1RFU1RFUiBpcyBub3Qgc2V0CkNPTkZJR19ERUJVR19TUElOTE9D
Sz15CkNPTkZJR19ERUJVR19NVVRFWEVTPXkKQ09ORklHX0RFQlVHX0xPQ0tfQUxMT0M9eQoj
IENPTkZJR19QUk9WRV9MT0NLSU5HIGlzIG5vdCBzZXQKQ09ORklHX1NQQVJTRV9SQ1VfUE9J
TlRFUj15CkNPTkZJR19MT0NLREVQPXkKQ09ORklHX0xPQ0tfU1RBVD15CiMgQ09ORklHX0RF
QlVHX0xPQ0tERVAgaXMgbm90IHNldApDT05GSUdfVFJBQ0VfSVJRRkxBR1M9eQpDT05GSUdf
REVCVUdfQVRPTUlDX1NMRUVQPXkKQ09ORklHX0RFQlVHX0xPQ0tJTkdfQVBJX1NFTEZURVNU
Uz15CkNPTkZJR19TVEFDS1RSQUNFPXkKQ09ORklHX0RFQlVHX1NUQUNLX1VTQUdFPXkKIyBD
T05GSUdfREVCVUdfS09CSkVDVCBpcyBub3Qgc2V0CkNPTkZJR19ERUJVR19CVUdWRVJCT1NF
PXkKIyBDT05GSUdfREVCVUdfSU5GTyBpcyBub3Qgc2V0CkNPTkZJR19ERUJVR19WTT15CiMg
Q09ORklHX0RFQlVHX1ZJUlRVQUwgaXMgbm90IHNldAojIENPTkZJR19ERUJVR19XUklURUNP
VU5UIGlzIG5vdCBzZXQKQ09ORklHX0RFQlVHX01FTU9SWV9JTklUPXkKIyBDT05GSUdfREVC
VUdfTElTVCBpcyBub3Qgc2V0CkNPTkZJR19URVNUX0xJU1RfU09SVD15CiMgQ09ORklHX0RF
QlVHX1NHIGlzIG5vdCBzZXQKIyBDT05GSUdfREVCVUdfTk9USUZJRVJTIGlzIG5vdCBzZXQK
IyBDT05GSUdfREVCVUdfQ1JFREVOVElBTFMgaXMgbm90IHNldApDT05GSUdfQVJDSF9XQU5U
X0ZSQU1FX1BPSU5URVJTPXkKQ09ORklHX0ZSQU1FX1BPSU5URVI9eQojIENPTkZJR19CT09U
X1BSSU5US19ERUxBWSBpcyBub3Qgc2V0CiMgQ09ORklHX1JDVV9UT1JUVVJFX1RFU1QgaXMg
bm90IHNldAojIENPTkZJR19CQUNLVFJBQ0VfU0VMRl9URVNUIGlzIG5vdCBzZXQKQ09ORklH
X0RFQlVHX0JMT0NLX0VYVF9ERVZUPXkKIyBDT05GSUdfREVCVUdfRk9SQ0VfV0VBS19QRVJf
Q1BVIGlzIG5vdCBzZXQKQ09ORklHX0xLRFRNPW0KQ09ORklHX0ZBVUxUX0lOSkVDVElPTj15
CiMgQ09ORklHX0ZBSUxTTEFCIGlzIG5vdCBzZXQKQ09ORklHX0ZBSUxfUEFHRV9BTExPQz15
CkNPTkZJR19GQUlMX01BS0VfUkVRVUVTVD15CkNPTkZJR19GQUlMX0lPX1RJTUVPVVQ9eQpD
T05GSUdfRkFJTF9NTUNfUkVRVUVTVD15CiMgQ09ORklHX0ZBVUxUX0lOSkVDVElPTl9ERUJV
R19GUyBpcyBub3Qgc2V0CiMgQ09ORklHX0xBVEVOQ1lUT1AgaXMgbm90IHNldApDT05GSUdf
U1lTQ1RMX1NZU0NBTExfQ0hFQ0s9eQpDT05GSUdfREVCVUdfUEFHRUFMTE9DPXkKQ09ORklH
X1dBTlRfUEFHRV9ERUJVR19GTEFHUz15CkNPTkZJR19QQUdFX0dVQVJEPXkKQ09ORklHX1VT
RVJfU1RBQ0tUUkFDRV9TVVBQT1JUPXkKQ09ORklHX05PUF9UUkFDRVI9eQpDT05GSUdfSEFW
RV9GVU5DVElPTl9UUkFDRVI9eQpDT05GSUdfSEFWRV9GVU5DVElPTl9HUkFQSF9UUkFDRVI9
eQpDT05GSUdfSEFWRV9GVU5DVElPTl9HUkFQSF9GUF9URVNUPXkKQ09ORklHX0hBVkVfRlVO
Q1RJT05fVFJBQ0VfTUNPVU5UX1RFU1Q9eQpDT05GSUdfSEFWRV9EWU5BTUlDX0ZUUkFDRT15
CkNPTkZJR19IQVZFX0ZUUkFDRV9NQ09VTlRfUkVDT1JEPXkKQ09ORklHX0hBVkVfU1lTQ0FM
TF9UUkFDRVBPSU5UUz15CkNPTkZJR19IQVZFX0NfUkVDT1JETUNPVU5UPXkKQ09ORklHX1RS
QUNFUl9NQVhfVFJBQ0U9eQpDT05GSUdfUklOR19CVUZGRVI9eQpDT05GSUdfRVZFTlRfVFJB
Q0lORz15CiMgQ09ORklHX0VWRU5UX1BPV0VSX1RSQUNJTkdfREVQUkVDQVRFRCBpcyBub3Qg
c2V0CkNPTkZJR19DT05URVhUX1NXSVRDSF9UUkFDRVI9eQpDT05GSUdfUklOR19CVUZGRVJf
QUxMT1dfU1dBUD15CkNPTkZJR19UUkFDSU5HPXkKQ09ORklHX0dFTkVSSUNfVFJBQ0VSPXkK
Q09ORklHX1RSQUNJTkdfU1VQUE9SVD15CkNPTkZJR19GVFJBQ0U9eQojIENPTkZJR19GVU5D
VElPTl9UUkFDRVIgaXMgbm90IHNldApDT05GSUdfSVJRU09GRl9UUkFDRVI9eQojIENPTkZJ
R19QUkVFTVBUX1RSQUNFUiBpcyBub3Qgc2V0CiMgQ09ORklHX1NDSEVEX1RSQUNFUiBpcyBu
b3Qgc2V0CiMgQ09ORklHX0ZUUkFDRV9TWVNDQUxMUyBpcyBub3Qgc2V0CkNPTkZJR19UUkFD
RV9CUkFOQ0hfUFJPRklMSU5HPXkKIyBDT05GSUdfQlJBTkNIX1BST0ZJTEVfTk9ORSBpcyBu
b3Qgc2V0CiMgQ09ORklHX1BST0ZJTEVfQU5OT1RBVEVEX0JSQU5DSEVTIGlzIG5vdCBzZXQK
Q09ORklHX1BST0ZJTEVfQUxMX0JSQU5DSEVTPXkKQ09ORklHX1RSQUNJTkdfQlJBTkNIRVM9
eQpDT05GSUdfQlJBTkNIX1RSQUNFUj15CiMgQ09ORklHX1NUQUNLX1RSQUNFUiBpcyBub3Qg
c2V0CiMgQ09ORklHX0JMS19ERVZfSU9fVFJBQ0UgaXMgbm90IHNldAojIENPTkZJR19VUFJP
QkVfRVZFTlQgaXMgbm90IHNldAojIENPTkZJR19QUk9CRV9FVkVOVFMgaXMgbm90IHNldApD
T05GSUdfRlRSQUNFX1NFTEZURVNUPXkKQ09ORklHX0ZUUkFDRV9TVEFSVFVQX1RFU1Q9eQoj
IENPTkZJR19FVkVOVF9UUkFDRV9URVNUX1NZU0NBTExTIGlzIG5vdCBzZXQKIyBDT05GSUdf
UklOR19CVUZGRVJfQkVOQ0hNQVJLIGlzIG5vdCBzZXQKQ09ORklHX0JVSUxEX0RPQ1NSQz15
CiMgQ09ORklHX0RZTkFNSUNfREVCVUcgaXMgbm90IHNldAojIENPTkZJR19ETUFfQVBJX0RF
QlVHIGlzIG5vdCBzZXQKIyBDT05GSUdfQVRPTUlDNjRfU0VMRlRFU1QgaXMgbm90IHNldApD
T05GSUdfU0FNUExFUz15CkNPTkZJR19TQU1QTEVfVFJBQ0VQT0lOVFM9bQojIENPTkZJR19T
QU1QTEVfVFJBQ0VfRVZFTlRTIGlzIG5vdCBzZXQKIyBDT05GSUdfU0FNUExFX0tPQkpFQ1Qg
aXMgbm90IHNldAojIENPTkZJR19TQU1QTEVfSFdfQlJFQUtQT0lOVCBpcyBub3Qgc2V0CkNP
TkZJR19TQU1QTEVfS0ZJRk89bQpDT05GSUdfSEFWRV9BUkNIX0tHREI9eQpDT05GSUdfSEFW
RV9BUkNIX0tNRU1DSEVDSz15CiMgQ09ORklHX1RFU1RfS1NUUlRPWCBpcyBub3Qgc2V0CkNP
TkZJR19TVFJJQ1RfREVWTUVNPXkKIyBDT05GSUdfWDg2X1ZFUkJPU0VfQk9PVFVQIGlzIG5v
dCBzZXQKQ09ORklHX0VBUkxZX1BSSU5USz15CiMgQ09ORklHX0RFQlVHX1NUQUNLT1ZFUkZM
T1cgaXMgbm90IHNldApDT05GSUdfWDg2X1BURFVNUD15CiMgQ09ORklHX0RFQlVHX1JPREFU
QSBpcyBub3Qgc2V0CkNPTkZJR19ERUJVR19TRVRfTU9EVUxFX1JPTlg9eQpDT05GSUdfREVC
VUdfTlhfVEVTVD1tCiMgQ09ORklHX0lPTU1VX1NUUkVTUyBpcyBub3Qgc2V0CkNPTkZJR19I
QVZFX01NSU9UUkFDRV9TVVBQT1JUPXkKQ09ORklHX0lPX0RFTEFZX1RZUEVfMFg4MD0wCkNP
TkZJR19JT19ERUxBWV9UWVBFXzBYRUQ9MQpDT05GSUdfSU9fREVMQVlfVFlQRV9VREVMQVk9
MgpDT05GSUdfSU9fREVMQVlfVFlQRV9OT05FPTMKQ09ORklHX0lPX0RFTEFZXzBYODA9eQoj
IENPTkZJR19JT19ERUxBWV8wWEVEIGlzIG5vdCBzZXQKIyBDT05GSUdfSU9fREVMQVlfVURF
TEFZIGlzIG5vdCBzZXQKIyBDT05GSUdfSU9fREVMQVlfTk9ORSBpcyBub3Qgc2V0CkNPTkZJ
R19ERUZBVUxUX0lPX0RFTEFZX1RZUEU9MApDT05GSUdfREVCVUdfQk9PVF9QQVJBTVM9eQpD
T05GSUdfQ1BBX0RFQlVHPXkKQ09ORklHX09QVElNSVpFX0lOTElOSU5HPXkKIyBDT05GSUdf
REVCVUdfTk1JX1NFTEZURVNUIGlzIG5vdCBzZXQKCiMKIyBTZWN1cml0eSBvcHRpb25zCiMK
Q09ORklHX0tFWVM9eQojIENPTkZJR19FTkNSWVBURURfS0VZUyBpcyBub3Qgc2V0CiMgQ09O
RklHX0tFWVNfREVCVUdfUFJPQ19LRVlTIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VDVVJJVFlf
RE1FU0dfUkVTVFJJQ1QgaXMgbm90IHNldAojIENPTkZJR19TRUNVUklUWSBpcyBub3Qgc2V0
CkNPTkZJR19TRUNVUklUWUZTPXkKQ09ORklHX0RFRkFVTFRfU0VDVVJJVFlfREFDPXkKQ09O
RklHX0RFRkFVTFRfU0VDVVJJVFk9IiIKQ09ORklHX0NSWVBUTz1tCgojCiMgQ3J5cHRvIGNv
cmUgb3IgaGVscGVyCiMKQ09ORklHX0NSWVBUT19BTEdBUEk9bQpDT05GSUdfQ1JZUFRPX0FM
R0FQSTI9bQpDT05GSUdfQ1JZUFRPX0FFQUQ9bQpDT05GSUdfQ1JZUFRPX0FFQUQyPW0KQ09O
RklHX0NSWVBUT19CTEtDSVBIRVI9bQpDT05GSUdfQ1JZUFRPX0JMS0NJUEhFUjI9bQpDT05G
SUdfQ1JZUFRPX0hBU0g9bQpDT05GSUdfQ1JZUFRPX0hBU0gyPW0KQ09ORklHX0NSWVBUT19S
Tkc9bQpDT05GSUdfQ1JZUFRPX1JORzI9bQpDT05GSUdfQ1JZUFRPX1BDT01QPW0KQ09ORklH
X0NSWVBUT19QQ09NUDI9bQpDT05GSUdfQ1JZUFRPX01BTkFHRVI9bQpDT05GSUdfQ1JZUFRP
X01BTkFHRVIyPW0KIyBDT05GSUdfQ1JZUFRPX1VTRVIgaXMgbm90IHNldApDT05GSUdfQ1JZ
UFRPX01BTkFHRVJfRElTQUJMRV9URVNUUz15CkNPTkZJR19DUllQVE9fR0YxMjhNVUw9bQoj
IENPTkZJR19DUllQVE9fTlVMTCBpcyBub3Qgc2V0CkNPTkZJR19DUllQVE9fV09SS1FVRVVF
PW0KQ09ORklHX0NSWVBUT19DUllQVEQ9bQojIENPTkZJR19DUllQVE9fQVVUSEVOQyBpcyBu
b3Qgc2V0CiMgQ09ORklHX0NSWVBUT19URVNUIGlzIG5vdCBzZXQKCiMKIyBBdXRoZW50aWNh
dGVkIEVuY3J5cHRpb24gd2l0aCBBc3NvY2lhdGVkIERhdGEKIwojIENPTkZJR19DUllQVE9f
Q0NNIGlzIG5vdCBzZXQKIyBDT05GSUdfQ1JZUFRPX0dDTSBpcyBub3Qgc2V0CkNPTkZJR19D
UllQVE9fU0VRSVY9bQoKIwojIEJsb2NrIG1vZGVzCiMKQ09ORklHX0NSWVBUT19DQkM9bQoj
IENPTkZJR19DUllQVE9fQ1RSIGlzIG5vdCBzZXQKQ09ORklHX0NSWVBUT19DVFM9bQojIENP
TkZJR19DUllQVE9fRUNCIGlzIG5vdCBzZXQKIyBDT05GSUdfQ1JZUFRPX1BDQkMgaXMgbm90
IHNldAoKIwojIEhhc2ggbW9kZXMKIwpDT05GSUdfQ1JZUFRPX0hNQUM9bQoKIwojIERpZ2Vz
dAojCkNPTkZJR19DUllQVE9fQ1JDMzJDPW0KQ09ORklHX0NSWVBUT19DUkMzMkNfSU5URUw9
bQpDT05GSUdfQ1JZUFRPX0dIQVNIPW0KQ09ORklHX0NSWVBUT19NRDQ9bQpDT05GSUdfQ1JZ
UFRPX01ENT1tCkNPTkZJR19DUllQVE9fTUlDSEFFTF9NSUM9bQpDT05GSUdfQ1JZUFRPX1JN
RDEyOD1tCkNPTkZJR19DUllQVE9fUk1EMTYwPW0KIyBDT05GSUdfQ1JZUFRPX1JNRDI1NiBp
cyBub3Qgc2V0CkNPTkZJR19DUllQVE9fUk1EMzIwPW0KQ09ORklHX0NSWVBUT19TSEExPW0K
Q09ORklHX0NSWVBUT19TSEExX1NTU0UzPW0KIyBDT05GSUdfQ1JZUFRPX1NIQTI1NiBpcyBu
b3Qgc2V0CkNPTkZJR19DUllQVE9fU0hBNTEyPW0KQ09ORklHX0NSWVBUT19UR1IxOTI9bQoj
IENPTkZJR19DUllQVE9fV1A1MTIgaXMgbm90IHNldApDT05GSUdfQ1JZUFRPX0dIQVNIX0NM
TVVMX05JX0lOVEVMPW0KCiMKIyBDaXBoZXJzCiMKQ09ORklHX0NSWVBUT19BRVM9bQpDT05G
SUdfQ1JZUFRPX0FFU19YODZfNjQ9bQpDT05GSUdfQ1JZUFRPX0FFU19OSV9JTlRFTD1tCkNP
TkZJR19DUllQVE9fQU5VQklTPW0KQ09ORklHX0NSWVBUT19BUkM0PW0KIyBDT05GSUdfQ1JZ
UFRPX0JMT1dGSVNIIGlzIG5vdCBzZXQKIyBDT05GSUdfQ1JZUFRPX0JMT1dGSVNIX1g4Nl82
NCBpcyBub3Qgc2V0CiMgQ09ORklHX0NSWVBUT19DQU1FTExJQSBpcyBub3Qgc2V0CiMgQ09O
RklHX0NSWVBUT19DQVNUNSBpcyBub3Qgc2V0CiMgQ09ORklHX0NSWVBUT19DQVNUNiBpcyBu
b3Qgc2V0CkNPTkZJR19DUllQVE9fREVTPW0KQ09ORklHX0NSWVBUT19GQ1JZUFQ9bQpDT05G
SUdfQ1JZUFRPX0tIQVpBRD1tCiMgQ09ORklHX0NSWVBUT19TRUVEIGlzIG5vdCBzZXQKQ09O
RklHX0NSWVBUT19TRVJQRU5UPW0KIyBDT05GSUdfQ1JZUFRPX1NFUlBFTlRfU1NFMl9YODZf
NjQgaXMgbm90IHNldApDT05GSUdfQ1JZUFRPX1RFQT1tCkNPTkZJR19DUllQVE9fVFdPRklT
SD1tCkNPTkZJR19DUllQVE9fVFdPRklTSF9DT01NT049bQpDT05GSUdfQ1JZUFRPX1RXT0ZJ
U0hfWDg2XzY0PW0KIyBDT05GSUdfQ1JZUFRPX1RXT0ZJU0hfWDg2XzY0XzNXQVkgaXMgbm90
IHNldAoKIwojIENvbXByZXNzaW9uCiMKQ09ORklHX0NSWVBUT19ERUZMQVRFPW0KQ09ORklH
X0NSWVBUT19aTElCPW0KQ09ORklHX0NSWVBUT19MWk89bQoKIwojIFJhbmRvbSBOdW1iZXIg
R2VuZXJhdGlvbgojCkNPTkZJR19DUllQVE9fQU5TSV9DUFJORz1tCiMgQ09ORklHX0NSWVBU
T19VU0VSX0FQSV9IQVNIIGlzIG5vdCBzZXQKIyBDT05GSUdfQ1JZUFRPX1VTRVJfQVBJX1NL
Q0lQSEVSIGlzIG5vdCBzZXQKQ09ORklHX0NSWVBUT19IVz15CiMgQ09ORklHX0NSWVBUT19E
RVZfUEFETE9DSyBpcyBub3Qgc2V0CkNPTkZJR19IQVZFX0tWTT15CiMgQ09ORklHX1ZJUlRV
QUxJWkFUSU9OIGlzIG5vdCBzZXQKQ09ORklHX0JJTkFSWV9QUklOVEY9eQoKIwojIExpYnJh
cnkgcm91dGluZXMKIwpDT05GSUdfQklUUkVWRVJTRT15CkNPTkZJR19HRU5FUklDX0ZJTkRf
RklSU1RfQklUPXkKQ09ORklHX0dFTkVSSUNfUENJX0lPTUFQPXkKQ09ORklHX0dFTkVSSUNf
SU9NQVA9eQpDT05GSUdfQ1JDX0NDSVRUPW0KQ09ORklHX0NSQzE2PW0KQ09ORklHX0NSQ19U
MTBESUY9bQpDT05GSUdfQ1JDX0lUVV9UPW0KQ09ORklHX0NSQzMyPXkKQ09ORklHX0NSQzc9
bQojIENPTkZJR19MSUJDUkMzMkMgaXMgbm90IHNldApDT05GSUdfQ1JDOD1tCkNPTkZJR19a
TElCX0lORkxBVEU9eQpDT05GSUdfWkxJQl9ERUZMQVRFPW0KQ09ORklHX0xaT19DT01QUkVT
Uz15CkNPTkZJR19MWk9fREVDT01QUkVTUz15CkNPTkZJR19YWl9ERUM9eQpDT05GSUdfWFpf
REVDX1g4Nj15CkNPTkZJR19YWl9ERUNfUE9XRVJQQz15CkNPTkZJR19YWl9ERUNfSUE2ND15
CkNPTkZJR19YWl9ERUNfQVJNPXkKQ09ORklHX1haX0RFQ19BUk1USFVNQj15CkNPTkZJR19Y
Wl9ERUNfU1BBUkM9eQpDT05GSUdfWFpfREVDX0JDSj15CiMgQ09ORklHX1haX0RFQ19URVNU
IGlzIG5vdCBzZXQKQ09ORklHX0RFQ09NUFJFU1NfR1pJUD15CkNPTkZJR19ERUNPTVBSRVNT
X0JaSVAyPXkKQ09ORklHX0RFQ09NUFJFU1NfTFpNQT15CkNPTkZJR19ERUNPTVBSRVNTX1ha
PXkKQ09ORklHX0RFQ09NUFJFU1NfTFpPPXkKQ09ORklHX0JDSD1tCkNPTkZJR19IQVNfSU9N
RU09eQpDT05GSUdfSEFTX0lPUE9SVD15CkNPTkZJR19IQVNfRE1BPXkKQ09ORklHX0RRTD15
CkNPTkZJR19OTEFUVFI9eQpDT05GSUdfQVZFUkFHRT15CiMgQ09ORklHX0NPUkRJQyBpcyBu
b3Qgc2V0CkNPTkZJR19NUElMSUI9bQojIENPTkZJR19NUElMSUJfRVhUUkEgaXMgbm90IHNl
dAojIENPTkZJR19ESUdTSUcgaXMgbm90IHNldAo=
--------------060000020604020105080200
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--------------060000020604020105080200--


From xen-devel-bounces@lists.xensource.com Mon Dec 19 19:44:31 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 19:44:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rcj89-0005LH-04; Mon, 19 Dec 2011 19:44:13 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1Rcj87-0005L3-2i
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 19:44:11 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-3.tower-182.messagelabs.com!1324323843!7904533!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23437 invoked from network); 19 Dec 2011 19:44:04 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-3.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 19 Dec 2011 19:44:04 -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
	pBJJhPSS017264
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Mon, 19 Dec 2011 14:43:25 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pBJJhP58017262;
	Mon, 19 Dec 2011 14:43:25 -0500
Date: Mon, 19 Dec 2011 15:43:25 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Michal Suchanek <hramrach@centrum.cz>, Ian.Campbell@eu.citrix.com
Message-ID: <20111219194324.GA29852@andromeda.dapyr.net>
References: <CAOMqctShNFqe47w1orEPMCqvDORy5yxh=Gy33e02fyQYrz4nkw@mail.gmail.com>
	<20111219142943.GD27772@andromeda.dapyr.net>
	<CAOMqctSW87AmM8UTC34_ZwDhipnZUMmxyxiBix+EMAmi7hn1hg@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAOMqctSW87AmM8UTC34_ZwDhipnZUMmxyxiBix+EMAmi7hn1hg@mail.gmail.com>
User-Agent: Mutt/1.5.9i
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] UDP checksums broken in Dom0 -> DomU vif transfer
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Dec 19, 2011 at 04:20:17PM +0100, Michal Suchanek wrote:
> On 19 December 2011 15:29, Konrad Rzeszutek Wilk <konrad@darnok.org> wrote:
> > On Mon, Dec 19, 2011 at 10:27:36AM +0100, Michal Suchanek wrote:
> >> Hello,
> >>
> >> when I boot DomU which uses DHCP to configure IPv4 address it does
> >
> > You didn't say what version of DomU you are running? Is it 3.1?
> 
> I have this problem in 2.6.32 and 3.1 kernels.

Ok. Lets concentrate on 3.1 then.
> 
> >> never get a lease.
> >>
> >> The packets travel to Dom0 where the dhcp server receives them, sends
> >> a reply, that travels to DomU where dhclient receives it, says the
> >> checksum is invalid, and discards it.
> >>
> >> The problem is documented here:
> >>
> >> http://old-list-archives.xen.org/archives/html/xen-users/2006-02/msg00152.html
> >> http://old-list-archives.xen.org/archives/html/xen-devel/2011-04/msg01235.html
> >> http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1655
> >>
> >> The fix is to turn off UDP checksum offloading on the vif interface in
> >> Dom0 as documented in the above mail:
> >>
> >> I edited /etc/xen/scripts/network-bridge,
> >> adding this command to the end of the op_start() function:
> >>
> >> ?? ?? ?? ?? add_to_bridge2 ${bridge} ${pdev}
> >> ?? ?? ?? ?? do_ifup ${netdev}
> >> + ?? ?? ?? # disable ip checksum offloading for veth device
> >> + ?? ?? ?? ethtool -K ${netdev} tx off
> >> ?? ?? else
> >> ?? ?? ?? ?? # old style without ${vdev}
> >>
> >> Note: I am not sure which path is taken through the script, I set the
> >> parameter manually with ethtool before I found this patch.
> >>
> >> It some solutions suggest to turn off UDP checksum offloading in the
> >> DomU as well but it does not seem to be necessary since the packets
> >> would travel to the dhcp server and it would reply to them.
> >>
> >> Some people say this is working for them.
> >>
> >> I suspect this is because some Linux distributions already carry this patch.
> >>
> >> Any reason why this can't be fixed in Xen upstream?
> >
> > It should be fixed in the kernel and I think it is fixed. Did you have
> > this problem with a 3.1 or 3.0 kernel?
> 
> Apparently it is not fixed.
> 
> Do you have hash of the Linux upstream commit that fixes it?

Ah, my appoligies - we do not have the fix, albeit I thought I saw the
fix some point. Ian might know since he is the maintainer of
xen-netback.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 19:44:31 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 19:44:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rcj89-0005LH-04; Mon, 19 Dec 2011 19:44:13 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1Rcj87-0005L3-2i
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 19:44:11 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-3.tower-182.messagelabs.com!1324323843!7904533!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23437 invoked from network); 19 Dec 2011 19:44:04 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-3.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 19 Dec 2011 19:44:04 -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
	pBJJhPSS017264
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Mon, 19 Dec 2011 14:43:25 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pBJJhP58017262;
	Mon, 19 Dec 2011 14:43:25 -0500
Date: Mon, 19 Dec 2011 15:43:25 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Michal Suchanek <hramrach@centrum.cz>, Ian.Campbell@eu.citrix.com
Message-ID: <20111219194324.GA29852@andromeda.dapyr.net>
References: <CAOMqctShNFqe47w1orEPMCqvDORy5yxh=Gy33e02fyQYrz4nkw@mail.gmail.com>
	<20111219142943.GD27772@andromeda.dapyr.net>
	<CAOMqctSW87AmM8UTC34_ZwDhipnZUMmxyxiBix+EMAmi7hn1hg@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAOMqctSW87AmM8UTC34_ZwDhipnZUMmxyxiBix+EMAmi7hn1hg@mail.gmail.com>
User-Agent: Mutt/1.5.9i
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] UDP checksums broken in Dom0 -> DomU vif transfer
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Dec 19, 2011 at 04:20:17PM +0100, Michal Suchanek wrote:
> On 19 December 2011 15:29, Konrad Rzeszutek Wilk <konrad@darnok.org> wrote:
> > On Mon, Dec 19, 2011 at 10:27:36AM +0100, Michal Suchanek wrote:
> >> Hello,
> >>
> >> when I boot DomU which uses DHCP to configure IPv4 address it does
> >
> > You didn't say what version of DomU you are running? Is it 3.1?
> 
> I have this problem in 2.6.32 and 3.1 kernels.

Ok. Lets concentrate on 3.1 then.
> 
> >> never get a lease.
> >>
> >> The packets travel to Dom0 where the dhcp server receives them, sends
> >> a reply, that travels to DomU where dhclient receives it, says the
> >> checksum is invalid, and discards it.
> >>
> >> The problem is documented here:
> >>
> >> http://old-list-archives.xen.org/archives/html/xen-users/2006-02/msg00152.html
> >> http://old-list-archives.xen.org/archives/html/xen-devel/2011-04/msg01235.html
> >> http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1655
> >>
> >> The fix is to turn off UDP checksum offloading on the vif interface in
> >> Dom0 as documented in the above mail:
> >>
> >> I edited /etc/xen/scripts/network-bridge,
> >> adding this command to the end of the op_start() function:
> >>
> >> ?? ?? ?? ?? add_to_bridge2 ${bridge} ${pdev}
> >> ?? ?? ?? ?? do_ifup ${netdev}
> >> + ?? ?? ?? # disable ip checksum offloading for veth device
> >> + ?? ?? ?? ethtool -K ${netdev} tx off
> >> ?? ?? else
> >> ?? ?? ?? ?? # old style without ${vdev}
> >>
> >> Note: I am not sure which path is taken through the script, I set the
> >> parameter manually with ethtool before I found this patch.
> >>
> >> It some solutions suggest to turn off UDP checksum offloading in the
> >> DomU as well but it does not seem to be necessary since the packets
> >> would travel to the dhcp server and it would reply to them.
> >>
> >> Some people say this is working for them.
> >>
> >> I suspect this is because some Linux distributions already carry this patch.
> >>
> >> Any reason why this can't be fixed in Xen upstream?
> >
> > It should be fixed in the kernel and I think it is fixed. Did you have
> > this problem with a 3.1 or 3.0 kernel?
> 
> Apparently it is not fixed.
> 
> Do you have hash of the Linux upstream commit that fixes it?

Ah, my appoligies - we do not have the fix, albeit I thought I saw the
fix some point. Ian might know since he is the maintainer of
xen-netback.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 19:55:40 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 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.xensource.com>)
	id 1RcjIu-0005pH-VK; Mon, 19 Dec 2011 19:55:20 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RcjIt-0005os-6P
	for Xen-devel@lists.xensource.com; Mon, 19 Dec 2011 19:55:19 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-8.tower-27.messagelabs.com!1324324403!56805502!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3688 invoked from network); 19 Dec 2011 19:53:23 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-8.tower-27.messagelabs.com with SMTP;
	19 Dec 2011 19:53:23 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea01.nsa.gov (8.12.10/8.12.10) with ESMTP id
	pBJJtDws021821; Mon, 19 Dec 2011 19:55:13 GMT
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id pBJJtDJW021983; 
	Mon, 19 Dec 2011 14:55:13 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: konrad.wilk@oracle.com
Date: Mon, 19 Dec 2011 14:55:14 -0500
Message-Id: <1324324514-11010-1-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.4
In-Reply-To: <20111219192354.GA5413@phenom.dumpdata.com>
References: <20111219192354.GA5413@phenom.dumpdata.com>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>, Xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 1/6 v3] xenbus: Support HVM backends
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Add HVM implementations of xenbus_(map,unmap)_ring_v(alloc,free) so
that ring mappings can be done without using GNTMAP_contains_pte which
is not supported on HVM.  This also removes the need to use vmlist_lock
on PV by tracking the allocated xenbus rings.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 drivers/xen/xenbus/xenbus_client.c |  175 +++++++++++++++++++++++++++++++-----
 drivers/xen/xenbus/xenbus_probe.c  |    2 +
 drivers/xen/xenbus/xenbus_probe.h  |    2 +
 3 files changed, 158 insertions(+), 21 deletions(-)

diff --git a/drivers/xen/xenbus/xenbus_client.c b/drivers/xen/xenbus/xenbus_client.c
index 1906125..0b3369d 100644
--- a/drivers/xen/xenbus/xenbus_client.c
+++ b/drivers/xen/xenbus/xenbus_client.c
@@ -32,16 +32,39 @@
 
 #include <linux/slab.h>
 #include <linux/types.h>
+#include <linux/spinlock.h>
 #include <linux/vmalloc.h>
 #include <linux/export.h>
 #include <asm/xen/hypervisor.h>
 #include <asm/xen/page.h>
 #include <xen/interface/xen.h>
 #include <xen/interface/event_channel.h>
+#include <xen/balloon.h>
 #include <xen/events.h>
 #include <xen/grant_table.h>
 #include <xen/xenbus.h>
 
+#include "xenbus_probe.h"
+
+struct xenbus_map_node {
+	struct list_head next;
+	union {
+		struct vm_struct *area; /* PV */
+		struct page *page;     /* HVM */
+	};
+	grant_handle_t handle;
+};
+
+static DEFINE_SPINLOCK(xenbus_valloc_lock);
+static LIST_HEAD(xenbus_valloc_pages);
+
+struct xenbus_ring_ops {
+	int (*map)(struct xenbus_device *dev, int gnt, void **vaddr);
+	int (*unmap)(struct xenbus_device *dev, void *vaddr);
+};
+
+static const struct xenbus_ring_ops *ring_ops __read_mostly;
+
 const char *xenbus_strstate(enum xenbus_state state)
 {
 	static const char *const name[] = {
@@ -436,19 +459,33 @@ EXPORT_SYMBOL_GPL(xenbus_free_evtchn);
  */
 int xenbus_map_ring_valloc(struct xenbus_device *dev, int gnt_ref, void **vaddr)
 {
+	return ring_ops->map(dev, gnt_ref, vaddr);
+}
+EXPORT_SYMBOL_GPL(xenbus_map_ring_valloc);
+
+static int xenbus_map_ring_valloc_pv(struct xenbus_device *dev,
+				     int gnt_ref, void **vaddr)
+{
 	struct gnttab_map_grant_ref op = {
 		.flags = GNTMAP_host_map | GNTMAP_contains_pte,
 		.ref   = gnt_ref,
 		.dom   = dev->otherend_id,
 	};
+	struct xenbus_map_node *node;
 	struct vm_struct *area;
 	pte_t *pte;
 
 	*vaddr = NULL;
 
+	node = kzalloc(sizeof(*node), GFP_KERNEL);
+	if (!node)
+		return -ENOMEM;
+
 	area = alloc_vm_area(PAGE_SIZE, &pte);
-	if (!area)
+	if (!area) {
+		kfree(node);
 		return -ENOMEM;
+	}
 
 	op.host_addr = arbitrary_virt_to_machine(pte).maddr;
 
@@ -457,19 +494,59 @@ int xenbus_map_ring_valloc(struct xenbus_device *dev, int gnt_ref, void **vaddr)
 
 	if (op.status != GNTST_okay) {
 		free_vm_area(area);
+		kfree(node);
 		xenbus_dev_fatal(dev, op.status,
 				 "mapping in shared page %d from domain %d",
 				 gnt_ref, dev->otherend_id);
 		return op.status;
 	}
 
-	/* Stuff the handle in an unused field */
-	area->phys_addr = (unsigned long)op.handle;
+	node->handle = op.handle;
+	node->area = area;
+
+	spin_lock(&xenbus_valloc_lock);
+	list_add(&node->next, &xenbus_valloc_pages);
+	spin_unlock(&xenbus_valloc_lock);
 
 	*vaddr = area->addr;
 	return 0;
 }
-EXPORT_SYMBOL_GPL(xenbus_map_ring_valloc);
+
+static int xenbus_map_ring_valloc_hvm(struct xenbus_device *dev,
+				      int gnt_ref, void **vaddr)
+{
+	struct xenbus_map_node *node;
+	int err;
+	void *addr;
+
+	*vaddr = NULL;
+
+	node = kzalloc(sizeof(*node), GFP_KERNEL);
+	if (!node)
+		return -ENOMEM;
+
+	err = alloc_xenballooned_pages(1, &node->page, false /* lowmem */);
+	if (err)
+		goto out_err;
+
+	addr = pfn_to_kaddr(page_to_pfn(node->page));
+
+	err = xenbus_map_ring(dev, gnt_ref, &node->handle, addr);
+	if (err)
+		goto out_err;
+
+	spin_lock(&xenbus_valloc_lock);
+	list_add(&node->next, &xenbus_valloc_pages);
+	spin_unlock(&xenbus_valloc_lock);
+
+	*vaddr = addr;
+	return 0;
+
+ out_err:
+	free_xenballooned_pages(1, &node->page);
+	kfree(node);
+	return err;
+}
 
 
 /**
@@ -525,32 +602,36 @@ EXPORT_SYMBOL_GPL(xenbus_map_ring);
  */
 int xenbus_unmap_ring_vfree(struct xenbus_device *dev, void *vaddr)
 {
-	struct vm_struct *area;
+	return ring_ops->unmap(dev, vaddr);
+}
+EXPORT_SYMBOL_GPL(xenbus_unmap_ring_vfree);
+
+static int xenbus_unmap_ring_vfree_pv(struct xenbus_device *dev, void *vaddr)
+{
+	struct xenbus_map_node *node;
 	struct gnttab_unmap_grant_ref op = {
 		.host_addr = (unsigned long)vaddr,
 	};
 	unsigned int level;
 
-	/* It'd be nice if linux/vmalloc.h provided a find_vm_area(void *addr)
-	 * method so that we don't have to muck with vmalloc internals here.
-	 * We could force the user to hang on to their struct vm_struct from
-	 * xenbus_map_ring_valloc, but these 6 lines considerably simplify
-	 * this API.
-	 */
-	read_lock(&vmlist_lock);
-	for (area = vmlist; area != NULL; area = area->next) {
-		if (area->addr == vaddr)
-			break;
+	spin_lock(&xenbus_valloc_lock);
+	list_for_each_entry(node, &xenbus_valloc_pages, next) {
+		if (node->area->addr == vaddr) {
+			list_del(&node->next);
+			goto found;
+		}
 	}
-	read_unlock(&vmlist_lock);
+	node = NULL;
+ found:
+	spin_unlock(&xenbus_valloc_lock);
 
-	if (!area) {
+	if (!node) {
 		xenbus_dev_error(dev, -ENOENT,
 				 "can't find mapped virtual address %p", vaddr);
 		return GNTST_bad_virt_addr;
 	}
 
-	op.handle = (grant_handle_t)area->phys_addr;
+	op.handle = node->handle;
 	op.host_addr = arbitrary_virt_to_machine(
 		lookup_address((unsigned long)vaddr, &level)).maddr;
 
@@ -558,16 +639,50 @@ int xenbus_unmap_ring_vfree(struct xenbus_device *dev, void *vaddr)
 		BUG();
 
 	if (op.status == GNTST_okay)
-		free_vm_area(area);
+		free_vm_area(node->area);
 	else
 		xenbus_dev_error(dev, op.status,
 				 "unmapping page at handle %d error %d",
-				 (int16_t)area->phys_addr, op.status);
+				 node->handle, op.status);
 
+	kfree(node);
 	return op.status;
 }
-EXPORT_SYMBOL_GPL(xenbus_unmap_ring_vfree);
 
+static int xenbus_unmap_ring_vfree_hvm(struct xenbus_device *dev, void *vaddr)
+{
+	int rv;
+	struct xenbus_map_node *node;
+	void *addr;
+
+	spin_lock(&xenbus_valloc_lock);
+	list_for_each_entry(node, &xenbus_valloc_pages, next) {
+		addr = pfn_to_kaddr(page_to_pfn(node->page));
+		if (addr == vaddr) {
+			list_del(&node->next);
+			goto found;
+		}
+	}
+	node = NULL;
+ found:
+	spin_unlock(&xenbus_valloc_lock);
+
+	if (!node) {
+		xenbus_dev_error(dev, -ENOENT,
+				 "can't find mapped virtual address %p", vaddr);
+		return GNTST_bad_virt_addr;
+	}
+
+	rv = xenbus_unmap_ring(dev, node->handle, addr);
+
+	if (!rv)
+		free_xenballooned_pages(1, &node->page);
+	else
+		WARN(1, "Leaking %p\n", vaddr);
+
+	kfree(node);
+	return rv;
+}
 
 /**
  * xenbus_unmap_ring
@@ -617,3 +732,21 @@ enum xenbus_state xenbus_read_driver_state(const char *path)
 	return result;
 }
 EXPORT_SYMBOL_GPL(xenbus_read_driver_state);
+
+static const struct xenbus_ring_ops ring_ops_pv = {
+	.map = xenbus_map_ring_valloc_pv,
+	.unmap = xenbus_unmap_ring_vfree_pv,
+};
+
+static const struct xenbus_ring_ops ring_ops_hvm = {
+	.map = xenbus_map_ring_valloc_hvm,
+	.unmap = xenbus_unmap_ring_vfree_hvm,
+};
+
+void __init xenbus_ring_ops_init(void)
+{
+	if (xen_pv_domain())
+		ring_ops = &ring_ops_pv;
+	else
+		ring_ops = &ring_ops_hvm;
+}
diff --git a/drivers/xen/xenbus/xenbus_probe.c b/drivers/xen/xenbus/xenbus_probe.c
index 1b178c6..1c05b25 100644
--- a/drivers/xen/xenbus/xenbus_probe.c
+++ b/drivers/xen/xenbus/xenbus_probe.c
@@ -730,6 +730,8 @@ static int __init xenbus_init(void)
 	if (!xen_domain())
 		return -ENODEV;
 
+	xenbus_ring_ops_init();
+
 	if (xen_hvm_domain()) {
 		uint64_t v = 0;
 		err = hvm_get_parameter(HVM_PARAM_STORE_EVTCHN, &v);
diff --git a/drivers/xen/xenbus/xenbus_probe.h b/drivers/xen/xenbus/xenbus_probe.h
index 9b1de4e..460d784 100644
--- a/drivers/xen/xenbus/xenbus_probe.h
+++ b/drivers/xen/xenbus/xenbus_probe.h
@@ -76,4 +76,6 @@ extern void xenbus_otherend_changed(struct xenbus_watch *watch,
 extern int xenbus_read_otherend_details(struct xenbus_device *xendev,
 					char *id_node, char *path_node);
 
+void xenbus_ring_ops_init(void);
+
 #endif
-- 
1.7.7.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 19:55:40 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 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.xensource.com>)
	id 1RcjIu-0005pH-VK; Mon, 19 Dec 2011 19:55:20 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RcjIt-0005os-6P
	for Xen-devel@lists.xensource.com; Mon, 19 Dec 2011 19:55:19 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-8.tower-27.messagelabs.com!1324324403!56805502!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3688 invoked from network); 19 Dec 2011 19:53:23 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-8.tower-27.messagelabs.com with SMTP;
	19 Dec 2011 19:53:23 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea01.nsa.gov (8.12.10/8.12.10) with ESMTP id
	pBJJtDws021821; Mon, 19 Dec 2011 19:55:13 GMT
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id pBJJtDJW021983; 
	Mon, 19 Dec 2011 14:55:13 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: konrad.wilk@oracle.com
Date: Mon, 19 Dec 2011 14:55:14 -0500
Message-Id: <1324324514-11010-1-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.4
In-Reply-To: <20111219192354.GA5413@phenom.dumpdata.com>
References: <20111219192354.GA5413@phenom.dumpdata.com>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>, Xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 1/6 v3] xenbus: Support HVM backends
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Add HVM implementations of xenbus_(map,unmap)_ring_v(alloc,free) so
that ring mappings can be done without using GNTMAP_contains_pte which
is not supported on HVM.  This also removes the need to use vmlist_lock
on PV by tracking the allocated xenbus rings.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 drivers/xen/xenbus/xenbus_client.c |  175 +++++++++++++++++++++++++++++++-----
 drivers/xen/xenbus/xenbus_probe.c  |    2 +
 drivers/xen/xenbus/xenbus_probe.h  |    2 +
 3 files changed, 158 insertions(+), 21 deletions(-)

diff --git a/drivers/xen/xenbus/xenbus_client.c b/drivers/xen/xenbus/xenbus_client.c
index 1906125..0b3369d 100644
--- a/drivers/xen/xenbus/xenbus_client.c
+++ b/drivers/xen/xenbus/xenbus_client.c
@@ -32,16 +32,39 @@
 
 #include <linux/slab.h>
 #include <linux/types.h>
+#include <linux/spinlock.h>
 #include <linux/vmalloc.h>
 #include <linux/export.h>
 #include <asm/xen/hypervisor.h>
 #include <asm/xen/page.h>
 #include <xen/interface/xen.h>
 #include <xen/interface/event_channel.h>
+#include <xen/balloon.h>
 #include <xen/events.h>
 #include <xen/grant_table.h>
 #include <xen/xenbus.h>
 
+#include "xenbus_probe.h"
+
+struct xenbus_map_node {
+	struct list_head next;
+	union {
+		struct vm_struct *area; /* PV */
+		struct page *page;     /* HVM */
+	};
+	grant_handle_t handle;
+};
+
+static DEFINE_SPINLOCK(xenbus_valloc_lock);
+static LIST_HEAD(xenbus_valloc_pages);
+
+struct xenbus_ring_ops {
+	int (*map)(struct xenbus_device *dev, int gnt, void **vaddr);
+	int (*unmap)(struct xenbus_device *dev, void *vaddr);
+};
+
+static const struct xenbus_ring_ops *ring_ops __read_mostly;
+
 const char *xenbus_strstate(enum xenbus_state state)
 {
 	static const char *const name[] = {
@@ -436,19 +459,33 @@ EXPORT_SYMBOL_GPL(xenbus_free_evtchn);
  */
 int xenbus_map_ring_valloc(struct xenbus_device *dev, int gnt_ref, void **vaddr)
 {
+	return ring_ops->map(dev, gnt_ref, vaddr);
+}
+EXPORT_SYMBOL_GPL(xenbus_map_ring_valloc);
+
+static int xenbus_map_ring_valloc_pv(struct xenbus_device *dev,
+				     int gnt_ref, void **vaddr)
+{
 	struct gnttab_map_grant_ref op = {
 		.flags = GNTMAP_host_map | GNTMAP_contains_pte,
 		.ref   = gnt_ref,
 		.dom   = dev->otherend_id,
 	};
+	struct xenbus_map_node *node;
 	struct vm_struct *area;
 	pte_t *pte;
 
 	*vaddr = NULL;
 
+	node = kzalloc(sizeof(*node), GFP_KERNEL);
+	if (!node)
+		return -ENOMEM;
+
 	area = alloc_vm_area(PAGE_SIZE, &pte);
-	if (!area)
+	if (!area) {
+		kfree(node);
 		return -ENOMEM;
+	}
 
 	op.host_addr = arbitrary_virt_to_machine(pte).maddr;
 
@@ -457,19 +494,59 @@ int xenbus_map_ring_valloc(struct xenbus_device *dev, int gnt_ref, void **vaddr)
 
 	if (op.status != GNTST_okay) {
 		free_vm_area(area);
+		kfree(node);
 		xenbus_dev_fatal(dev, op.status,
 				 "mapping in shared page %d from domain %d",
 				 gnt_ref, dev->otherend_id);
 		return op.status;
 	}
 
-	/* Stuff the handle in an unused field */
-	area->phys_addr = (unsigned long)op.handle;
+	node->handle = op.handle;
+	node->area = area;
+
+	spin_lock(&xenbus_valloc_lock);
+	list_add(&node->next, &xenbus_valloc_pages);
+	spin_unlock(&xenbus_valloc_lock);
 
 	*vaddr = area->addr;
 	return 0;
 }
-EXPORT_SYMBOL_GPL(xenbus_map_ring_valloc);
+
+static int xenbus_map_ring_valloc_hvm(struct xenbus_device *dev,
+				      int gnt_ref, void **vaddr)
+{
+	struct xenbus_map_node *node;
+	int err;
+	void *addr;
+
+	*vaddr = NULL;
+
+	node = kzalloc(sizeof(*node), GFP_KERNEL);
+	if (!node)
+		return -ENOMEM;
+
+	err = alloc_xenballooned_pages(1, &node->page, false /* lowmem */);
+	if (err)
+		goto out_err;
+
+	addr = pfn_to_kaddr(page_to_pfn(node->page));
+
+	err = xenbus_map_ring(dev, gnt_ref, &node->handle, addr);
+	if (err)
+		goto out_err;
+
+	spin_lock(&xenbus_valloc_lock);
+	list_add(&node->next, &xenbus_valloc_pages);
+	spin_unlock(&xenbus_valloc_lock);
+
+	*vaddr = addr;
+	return 0;
+
+ out_err:
+	free_xenballooned_pages(1, &node->page);
+	kfree(node);
+	return err;
+}
 
 
 /**
@@ -525,32 +602,36 @@ EXPORT_SYMBOL_GPL(xenbus_map_ring);
  */
 int xenbus_unmap_ring_vfree(struct xenbus_device *dev, void *vaddr)
 {
-	struct vm_struct *area;
+	return ring_ops->unmap(dev, vaddr);
+}
+EXPORT_SYMBOL_GPL(xenbus_unmap_ring_vfree);
+
+static int xenbus_unmap_ring_vfree_pv(struct xenbus_device *dev, void *vaddr)
+{
+	struct xenbus_map_node *node;
 	struct gnttab_unmap_grant_ref op = {
 		.host_addr = (unsigned long)vaddr,
 	};
 	unsigned int level;
 
-	/* It'd be nice if linux/vmalloc.h provided a find_vm_area(void *addr)
-	 * method so that we don't have to muck with vmalloc internals here.
-	 * We could force the user to hang on to their struct vm_struct from
-	 * xenbus_map_ring_valloc, but these 6 lines considerably simplify
-	 * this API.
-	 */
-	read_lock(&vmlist_lock);
-	for (area = vmlist; area != NULL; area = area->next) {
-		if (area->addr == vaddr)
-			break;
+	spin_lock(&xenbus_valloc_lock);
+	list_for_each_entry(node, &xenbus_valloc_pages, next) {
+		if (node->area->addr == vaddr) {
+			list_del(&node->next);
+			goto found;
+		}
 	}
-	read_unlock(&vmlist_lock);
+	node = NULL;
+ found:
+	spin_unlock(&xenbus_valloc_lock);
 
-	if (!area) {
+	if (!node) {
 		xenbus_dev_error(dev, -ENOENT,
 				 "can't find mapped virtual address %p", vaddr);
 		return GNTST_bad_virt_addr;
 	}
 
-	op.handle = (grant_handle_t)area->phys_addr;
+	op.handle = node->handle;
 	op.host_addr = arbitrary_virt_to_machine(
 		lookup_address((unsigned long)vaddr, &level)).maddr;
 
@@ -558,16 +639,50 @@ int xenbus_unmap_ring_vfree(struct xenbus_device *dev, void *vaddr)
 		BUG();
 
 	if (op.status == GNTST_okay)
-		free_vm_area(area);
+		free_vm_area(node->area);
 	else
 		xenbus_dev_error(dev, op.status,
 				 "unmapping page at handle %d error %d",
-				 (int16_t)area->phys_addr, op.status);
+				 node->handle, op.status);
 
+	kfree(node);
 	return op.status;
 }
-EXPORT_SYMBOL_GPL(xenbus_unmap_ring_vfree);
 
+static int xenbus_unmap_ring_vfree_hvm(struct xenbus_device *dev, void *vaddr)
+{
+	int rv;
+	struct xenbus_map_node *node;
+	void *addr;
+
+	spin_lock(&xenbus_valloc_lock);
+	list_for_each_entry(node, &xenbus_valloc_pages, next) {
+		addr = pfn_to_kaddr(page_to_pfn(node->page));
+		if (addr == vaddr) {
+			list_del(&node->next);
+			goto found;
+		}
+	}
+	node = NULL;
+ found:
+	spin_unlock(&xenbus_valloc_lock);
+
+	if (!node) {
+		xenbus_dev_error(dev, -ENOENT,
+				 "can't find mapped virtual address %p", vaddr);
+		return GNTST_bad_virt_addr;
+	}
+
+	rv = xenbus_unmap_ring(dev, node->handle, addr);
+
+	if (!rv)
+		free_xenballooned_pages(1, &node->page);
+	else
+		WARN(1, "Leaking %p\n", vaddr);
+
+	kfree(node);
+	return rv;
+}
 
 /**
  * xenbus_unmap_ring
@@ -617,3 +732,21 @@ enum xenbus_state xenbus_read_driver_state(const char *path)
 	return result;
 }
 EXPORT_SYMBOL_GPL(xenbus_read_driver_state);
+
+static const struct xenbus_ring_ops ring_ops_pv = {
+	.map = xenbus_map_ring_valloc_pv,
+	.unmap = xenbus_unmap_ring_vfree_pv,
+};
+
+static const struct xenbus_ring_ops ring_ops_hvm = {
+	.map = xenbus_map_ring_valloc_hvm,
+	.unmap = xenbus_unmap_ring_vfree_hvm,
+};
+
+void __init xenbus_ring_ops_init(void)
+{
+	if (xen_pv_domain())
+		ring_ops = &ring_ops_pv;
+	else
+		ring_ops = &ring_ops_hvm;
+}
diff --git a/drivers/xen/xenbus/xenbus_probe.c b/drivers/xen/xenbus/xenbus_probe.c
index 1b178c6..1c05b25 100644
--- a/drivers/xen/xenbus/xenbus_probe.c
+++ b/drivers/xen/xenbus/xenbus_probe.c
@@ -730,6 +730,8 @@ static int __init xenbus_init(void)
 	if (!xen_domain())
 		return -ENODEV;
 
+	xenbus_ring_ops_init();
+
 	if (xen_hvm_domain()) {
 		uint64_t v = 0;
 		err = hvm_get_parameter(HVM_PARAM_STORE_EVTCHN, &v);
diff --git a/drivers/xen/xenbus/xenbus_probe.h b/drivers/xen/xenbus/xenbus_probe.h
index 9b1de4e..460d784 100644
--- a/drivers/xen/xenbus/xenbus_probe.h
+++ b/drivers/xen/xenbus/xenbus_probe.h
@@ -76,4 +76,6 @@ extern void xenbus_otherend_changed(struct xenbus_watch *watch,
 extern int xenbus_read_otherend_details(struct xenbus_device *xendev,
 					char *id_node, char *path_node);
 
+void xenbus_ring_ops_init(void);
+
 #endif
-- 
1.7.7.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 20:48:54 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 20:48:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rck8E-0006ln-3s; Mon, 19 Dec 2011 20:48:22 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1Rck8C-0006lZ-HI
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 20:48:20 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-7.tower-21.messagelabs.com!1324327693!8083166!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32251 invoked from network); 19 Dec 2011 20:48:14 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-7.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 19 Dec 2011 20:48:14 -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
	pBJKm14T021578
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Mon, 19 Dec 2011 15:48:01 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pBJKlvor021567;
	Mon, 19 Dec 2011 15:47:57 -0500
Date: Mon, 19 Dec 2011 16:47:57 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Randy Dunlap <rdunlap@xenotime.net>
Message-ID: <20111219204757.GB29852@andromeda.dapyr.net>
References: <20111219185556.f07c1f43e28cfd594aaa5fe0@canb.auug.org.au>
	<4EEF9F44.8080707@xenotime.net>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4EEF9F44.8080707@xenotime.net>
User-Agent: Mutt/1.5.9i
Cc: Stephen Rothwell <sfr@canb.auug.org.au>,
	Jeremy Fitzhardinge <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	LKML <linux-kernel@vger.kernel.org>,
	Linux Virtualization <virtualization@lists.linux-foundation.org>,
	linux-next@vger.kernel.org
Subject: Re: [Xen-devel] linux-next: Tree for Dec 19 (xen)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Dec 19, 2011 at 12:32:04PM -0800, Randy Dunlap wrote:
> On 12/18/2011 11:55 PM, Stephen Rothwell wrote:
> > Hi all,
> > 
> > Changes since 20111216:
> 
> 
> drivers/xen/xenbus/xenbus_dev_frontend.c: In function 'xenbus_init':
> drivers/xen/xenbus/xenbus_dev_frontend.c:609:2: error: implicit declaration of function 'xen_domain'
> 
> Full randconfig file is attached.

Fixed. Thx!

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 20:48:54 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 20:48:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rck8E-0006ln-3s; Mon, 19 Dec 2011 20:48:22 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1Rck8C-0006lZ-HI
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 20:48:20 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-7.tower-21.messagelabs.com!1324327693!8083166!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32251 invoked from network); 19 Dec 2011 20:48:14 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-7.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 19 Dec 2011 20:48:14 -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
	pBJKm14T021578
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Mon, 19 Dec 2011 15:48:01 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pBJKlvor021567;
	Mon, 19 Dec 2011 15:47:57 -0500
Date: Mon, 19 Dec 2011 16:47:57 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Randy Dunlap <rdunlap@xenotime.net>
Message-ID: <20111219204757.GB29852@andromeda.dapyr.net>
References: <20111219185556.f07c1f43e28cfd594aaa5fe0@canb.auug.org.au>
	<4EEF9F44.8080707@xenotime.net>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4EEF9F44.8080707@xenotime.net>
User-Agent: Mutt/1.5.9i
Cc: Stephen Rothwell <sfr@canb.auug.org.au>,
	Jeremy Fitzhardinge <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	LKML <linux-kernel@vger.kernel.org>,
	Linux Virtualization <virtualization@lists.linux-foundation.org>,
	linux-next@vger.kernel.org
Subject: Re: [Xen-devel] linux-next: Tree for Dec 19 (xen)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Dec 19, 2011 at 12:32:04PM -0800, Randy Dunlap wrote:
> On 12/18/2011 11:55 PM, Stephen Rothwell wrote:
> > Hi all,
> > 
> > Changes since 20111216:
> 
> 
> drivers/xen/xenbus/xenbus_dev_frontend.c: In function 'xenbus_init':
> drivers/xen/xenbus/xenbus_dev_frontend.c:609:2: error: implicit declaration of function 'xen_domain'
> 
> Full randconfig file is attached.

Fixed. Thx!

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 23:42:20 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 23: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.xensource.com>)
	id 1Rcmpp-0007Zi-Ce; Mon, 19 Dec 2011 23:41:33 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <xen-devel.GarveyPatrickD@OrdinaryAmerican.net>)
	id 1Rcmpn-0007Zd-NX
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 23:41:31 +0000
X-Env-Sender: xen-devel.GarveyPatrickD@OrdinaryAmerican.net
X-Msg-Ref: server-2.tower-216.messagelabs.com!1324338084!9419618!1
X-Originating-IP: [216.75.62.102]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17262 invoked from network); 19 Dec 2011 23:41:25 -0000
Received: from gourmet7.spamgourmet.com (HELO gourmet8.spamgourmet.com)
	(216.75.62.102) by server-2.tower-216.messagelabs.com with SMTP;
	19 Dec 2011 23:41:25 -0000
Received: from spamgourmet by gourmet7.spamgourmet.com with local (Exim 4.69)
	(envelope-from <xen-devel.GarveyPatrickD@OrdinaryAmerican.net>)
	id 1Rcmpf-0002HH-J2
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 23:41:23 +0000
Received: from mail-tul01m020-f176.google.com ([209.85.214.176])
	by gourmet7.spamgourmet.com with esmtp (Exim 4.69)
	(envelope-from <xen-devel.GarveyPatrickD@OrdinaryAmerican.net>)
	id 1Rcmpf-0002H3-Cm for
	+xen-devel+GarveyPatrickD+fbe7693c78.xen-devel#lists.xensource.com@spamgourmet.com;
	Mon, 19 Dec 2011 23:41:23 +0000
Received: by obcwn14 with SMTP id wn14so2053770obc.7 for
	<+xen-devel+GarveyPatrickD+fbe7693c78.xen-devel#lists.xensource.com@spamgourmet.com>;
	Mon, 19 Dec 2011 15:41:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=geuktJgYgqOj1L6YWrYLQQ6/JRIzm8eCVoaq1S2jyKQ=;
	b=OaGhkql2zaD5Uk6s8bx+rTfmjDCUowbCCZ/Q9U5z3m4w0y3FcEsl2IBtYXqUEEa8qT
	xxNSqyTO/qGe3ZDwNgGWgVg8NIx1lHoxmPFnKKChRAvIJo7YVjteDJGFrs7aRLEFGnwn
	HzdSsQbdT0Qb3mnyBIh2DsY4DRN5N5aOkIDqk=
MIME-Version: 1.0
Received: by 10.182.159.99 with SMTP id xb3mr11653009obb.8.1324338082569; Mon,
	19 Dec 2011 15:41:22 -0800 (PST)
Received: by 10.182.16.163 with HTTP; Mon, 19 Dec 2011 15:41:22 -0800 (PST)
Date: Mon, 19 Dec 2011 15:41:22 -0800
Message-ID: <CACm5R6R19QZ-8V86sqpqo5A372ox36sqzgLLEEBRDvkSFQBw=A@mail.gmail.com>
From: xen-devel.GarveyPatrickD@OrdinaryAmerican.net
To: xen-devel@lists.xensource.com
X-Spamgourmet: 
Subject: [Xen-devel] PV-GRUB?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

The Xen wiki uses:
"pv-grub" in:
http://wiki.xen.org/wiki/Xen_Common_Problems
http://wiki.xen.org/wiki/Xen_FAQ_Design_and_in_Depth
http://wiki.xen.org/wiki/Xen_PCI_Passthrough
http://wiki.xen.org/wiki/XenUsersQuestions
http://wiki.xen.org/wiki/Xen_Beginners_Guide

"PV-GRUB" in:
http://wiki.xen.org/wiki/PvGrub
http://wiki.xen.org/wiki/PVGrub_HowTo

"PvGRUB" in the title of:
http://wiki.xen.org/wiki/PvGrub
http://wiki.xen.org/wiki/PVGrub_HowTo

It is fairly obvious that /usr/lib/xen/boot/pv-grub-x86_32.gz in
http://wiki.xen.org/wiki/PVGrub_HowTo
is correct, because it specifies a file name where the convention is
all lower case.

I'd like to standardize the others as PV-GRUB, even changing the
copies in the Xen wiki of questions submitted to the mailing list, so
it is easily recognized we are referring to a certain component of
Xen.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 19 23:42:20 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 Dec 2011 23: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.xensource.com>)
	id 1Rcmpp-0007Zi-Ce; Mon, 19 Dec 2011 23:41:33 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <xen-devel.GarveyPatrickD@OrdinaryAmerican.net>)
	id 1Rcmpn-0007Zd-NX
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 23:41:31 +0000
X-Env-Sender: xen-devel.GarveyPatrickD@OrdinaryAmerican.net
X-Msg-Ref: server-2.tower-216.messagelabs.com!1324338084!9419618!1
X-Originating-IP: [216.75.62.102]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17262 invoked from network); 19 Dec 2011 23:41:25 -0000
Received: from gourmet7.spamgourmet.com (HELO gourmet8.spamgourmet.com)
	(216.75.62.102) by server-2.tower-216.messagelabs.com with SMTP;
	19 Dec 2011 23:41:25 -0000
Received: from spamgourmet by gourmet7.spamgourmet.com with local (Exim 4.69)
	(envelope-from <xen-devel.GarveyPatrickD@OrdinaryAmerican.net>)
	id 1Rcmpf-0002HH-J2
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 23:41:23 +0000
Received: from mail-tul01m020-f176.google.com ([209.85.214.176])
	by gourmet7.spamgourmet.com with esmtp (Exim 4.69)
	(envelope-from <xen-devel.GarveyPatrickD@OrdinaryAmerican.net>)
	id 1Rcmpf-0002H3-Cm for
	+xen-devel+GarveyPatrickD+fbe7693c78.xen-devel#lists.xensource.com@spamgourmet.com;
	Mon, 19 Dec 2011 23:41:23 +0000
Received: by obcwn14 with SMTP id wn14so2053770obc.7 for
	<+xen-devel+GarveyPatrickD+fbe7693c78.xen-devel#lists.xensource.com@spamgourmet.com>;
	Mon, 19 Dec 2011 15:41:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=geuktJgYgqOj1L6YWrYLQQ6/JRIzm8eCVoaq1S2jyKQ=;
	b=OaGhkql2zaD5Uk6s8bx+rTfmjDCUowbCCZ/Q9U5z3m4w0y3FcEsl2IBtYXqUEEa8qT
	xxNSqyTO/qGe3ZDwNgGWgVg8NIx1lHoxmPFnKKChRAvIJo7YVjteDJGFrs7aRLEFGnwn
	HzdSsQbdT0Qb3mnyBIh2DsY4DRN5N5aOkIDqk=
MIME-Version: 1.0
Received: by 10.182.159.99 with SMTP id xb3mr11653009obb.8.1324338082569; Mon,
	19 Dec 2011 15:41:22 -0800 (PST)
Received: by 10.182.16.163 with HTTP; Mon, 19 Dec 2011 15:41:22 -0800 (PST)
Date: Mon, 19 Dec 2011 15:41:22 -0800
Message-ID: <CACm5R6R19QZ-8V86sqpqo5A372ox36sqzgLLEEBRDvkSFQBw=A@mail.gmail.com>
From: xen-devel.GarveyPatrickD@OrdinaryAmerican.net
To: xen-devel@lists.xensource.com
X-Spamgourmet: 
Subject: [Xen-devel] PV-GRUB?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

The Xen wiki uses:
"pv-grub" in:
http://wiki.xen.org/wiki/Xen_Common_Problems
http://wiki.xen.org/wiki/Xen_FAQ_Design_and_in_Depth
http://wiki.xen.org/wiki/Xen_PCI_Passthrough
http://wiki.xen.org/wiki/XenUsersQuestions
http://wiki.xen.org/wiki/Xen_Beginners_Guide

"PV-GRUB" in:
http://wiki.xen.org/wiki/PvGrub
http://wiki.xen.org/wiki/PVGrub_HowTo

"PvGRUB" in the title of:
http://wiki.xen.org/wiki/PvGrub
http://wiki.xen.org/wiki/PVGrub_HowTo

It is fairly obvious that /usr/lib/xen/boot/pv-grub-x86_32.gz in
http://wiki.xen.org/wiki/PVGrub_HowTo
is correct, because it specifies a file name where the convention is
all lower case.

I'd like to standardize the others as PV-GRUB, even changing the
copies in the Xen wiki of questions submitted to the mailing list, so
it is easily recognized we are referring to a certain component of
Xen.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 20 00:07:27 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 Dec 2011 00:07:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RcnEO-0008Dd-J6; Tue, 20 Dec 2011 00:06:56 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <samuel.thibault@ens-lyon.org>) id 1RcnEM-0008DX-Rb
	for xen-devel@lists.xensource.com; Tue, 20 Dec 2011 00:06:55 +0000
X-Env-Sender: samuel.thibault@ens-lyon.org
X-Msg-Ref: server-12.tower-182.messagelabs.com!1324339608!7917898!1
X-Originating-IP: [80.67.169.19]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12244 invoked from network); 20 Dec 2011 00:06:48 -0000
Received: from solo.fdn.fr (HELO solo.fdn.fr) (80.67.169.19)
	by server-12.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 20 Dec 2011 00:06:48 -0000
Received: from type.ipv6 (youpi.is-a-geek.org [80.67.176.89])
	(using TLSv1 with cipher AES256-SHA (256/256 bits))
	(Client did not present a certificate)
	by solo.fdn.fr (Postfix) with ESMTPS id 22D2C44791;
	Tue, 20 Dec 2011 01:06:48 +0100 (CET)
Received: from samy by type.ipv6 with local (Exim 4.77)
	(envelope-from <samuel.thibault@ens-lyon.org>)
	id 1RcnEF-0004yH-0u; Tue, 20 Dec 2011 01:06:47 +0100
Date: Tue, 20 Dec 2011 01:06:47 +0100
From: Samuel Thibault <samuel.thibault@ens-lyon.org>
To: xen-devel.GarveyPatrickD@OrdinaryAmerican.net
Message-ID: <20111220000646.GK4082@type.famille.thibault.fr>
Mail-Followup-To: Samuel Thibault <samuel.thibault@ens-lyon.org>,
	xen-devel.GarveyPatrickD@OrdinaryAmerican.net,
	xen-devel@lists.xensource.com
References: <CACm5R6R19QZ-8V86sqpqo5A372ox36sqzgLLEEBRDvkSFQBw=A@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CACm5R6R19QZ-8V86sqpqo5A372ox36sqzgLLEEBRDvkSFQBw=A@mail.gmail.com>
User-Agent: Mutt/1.5.21+34 (58baf7c9f32f) (2010-12-30)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] PV-GRUB?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

xen-devel.GarveyPatrickD@OrdinaryAmerican.net, le Mon 19 Dec 2011 15:41:22 =
-0800, a =E9crit :
> I'd like to standardize the others as PV-GRUB,

This is what I usually used, indeed.

Samuel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 20 00:07:27 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 Dec 2011 00:07:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RcnEO-0008Dd-J6; Tue, 20 Dec 2011 00:06:56 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <samuel.thibault@ens-lyon.org>) id 1RcnEM-0008DX-Rb
	for xen-devel@lists.xensource.com; Tue, 20 Dec 2011 00:06:55 +0000
X-Env-Sender: samuel.thibault@ens-lyon.org
X-Msg-Ref: server-12.tower-182.messagelabs.com!1324339608!7917898!1
X-Originating-IP: [80.67.169.19]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12244 invoked from network); 20 Dec 2011 00:06:48 -0000
Received: from solo.fdn.fr (HELO solo.fdn.fr) (80.67.169.19)
	by server-12.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 20 Dec 2011 00:06:48 -0000
Received: from type.ipv6 (youpi.is-a-geek.org [80.67.176.89])
	(using TLSv1 with cipher AES256-SHA (256/256 bits))
	(Client did not present a certificate)
	by solo.fdn.fr (Postfix) with ESMTPS id 22D2C44791;
	Tue, 20 Dec 2011 01:06:48 +0100 (CET)
Received: from samy by type.ipv6 with local (Exim 4.77)
	(envelope-from <samuel.thibault@ens-lyon.org>)
	id 1RcnEF-0004yH-0u; Tue, 20 Dec 2011 01:06:47 +0100
Date: Tue, 20 Dec 2011 01:06:47 +0100
From: Samuel Thibault <samuel.thibault@ens-lyon.org>
To: xen-devel.GarveyPatrickD@OrdinaryAmerican.net
Message-ID: <20111220000646.GK4082@type.famille.thibault.fr>
Mail-Followup-To: Samuel Thibault <samuel.thibault@ens-lyon.org>,
	xen-devel.GarveyPatrickD@OrdinaryAmerican.net,
	xen-devel@lists.xensource.com
References: <CACm5R6R19QZ-8V86sqpqo5A372ox36sqzgLLEEBRDvkSFQBw=A@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CACm5R6R19QZ-8V86sqpqo5A372ox36sqzgLLEEBRDvkSFQBw=A@mail.gmail.com>
User-Agent: Mutt/1.5.21+34 (58baf7c9f32f) (2010-12-30)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] PV-GRUB?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

xen-devel.GarveyPatrickD@OrdinaryAmerican.net, le Mon 19 Dec 2011 15:41:22 =
-0800, a =E9crit :
> I'd like to standardize the others as PV-GRUB,

This is what I usually used, indeed.

Samuel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 20 02:30:23 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 Dec 2011 02:30:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RcpSU-0004gn-DH; Tue, 20 Dec 2011 02:29:38 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <kevin.tian@intel.com>) id 1RcpSS-0004gi-GG
	for xen-devel@lists.xensource.com; Tue, 20 Dec 2011 02:29:36 +0000
X-Env-Sender: kevin.tian@intel.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1324348169!2606148!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDI5ODYyMQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21361 invoked from network); 20 Dec 2011 02:29:30 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-9.tower-21.messagelabs.com with SMTP;
	20 Dec 2011 02:29:30 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga102.fm.intel.com with ESMTP; 19 Dec 2011 18:29:28 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="98156610"
Received: from pgsmsx602.gar.corp.intel.com ([10.221.43.81])
	by fmsmga001.fm.intel.com with ESMTP; 19 Dec 2011 18:29:26 -0800
Received: from shsmsx601.ccr.corp.intel.com (10.239.4.112) by
	pgsmsx602.gar.corp.intel.com (10.221.43.81) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Tue, 20 Dec 2011 10:29:15 +0800
Received: from shsmsx502.ccr.corp.intel.com ([10.239.4.96]) by
	shsmsx601.ccr.corp.intel.com ([10.239.4.112]) with mapi;
	Tue, 20 Dec 2011 10:29:14 +0800
From: "Tian, Kevin" <kevin.tian@intel.com>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
Date: Tue, 20 Dec 2011 10:29:12 +0800
Thread-Topic: [Xen-devel] [PATCH 3/8] ACPI: processor: add
	__acpi_processor_[un]register_driver helpers.
Thread-Index: Acy+WjcyXbsTIfQ3S1OCQ8XtHWNDEgAY0JcQ
Message-ID: <625BA99ED14B2D499DC4E29D8138F1506E01AAC03A@shsmsx502.ccr.corp.intel.com>
References: <1322673664-14642-1-git-send-email-konrad.wilk@oracle.com>
	<1322673664-14642-4-git-send-email-konrad.wilk@oracle.com>
	<20111216220342.GC9832@phenom.dumpdata.com>
	<625BA99ED14B2D499DC4E29D8138F1506E01AABC7A@shsmsx502.ccr.corp.intel.com>
	<20111219142626.GB27772@andromeda.dapyr.net>
In-Reply-To: <20111219142626.GB27772@andromeda.dapyr.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "jeremy@goop.org" <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"mike.mcclurg@citrix.com" <mike.mcclurg@citrix.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"stefan.bader@canonical.com" <stefan.bader@canonical.com>,
	"rjw@sisk.pl" <rjw@sisk.pl>,
	"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
	"liang.tang@oracle.com" <liang.tang@oracle.com>, "Yu,
	Ke" <ke.yu@intel.com>, "konrad@kernel.org" <konrad@kernel.org>,
	"lenb@kernel.org" <lenb@kernel.org>
Subject: Re: [Xen-devel] [PATCH 3/8] ACPI: processor: add
 __acpi_processor_[un]register_driver helpers.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> From: Konrad Rzeszutek Wilk [mailto:konrad@darnok.org]
> Sent: Monday, December 19, 2011 10:26 PM
> 
> On Mon, Dec 19, 2011 at 01:48:01PM +0800, Tian, Kevin wrote:
> > > From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@oracle.com]
> > > Sent: Saturday, December 17, 2011 6:04 AM
> > >
> > > On Wed, Nov 30, 2011 at 12:20:59PM -0500, Konrad Rzeszutek Wilk wrote:
> > > > From: Tang Liang <liang.tang@oracle.com>
> > > >
> > > > This patch implement __acpi_processor_[un]register_driver helper,
> > > > so we can registry override processor driver function. Specifically
> > > > the Xen processor driver.
> > >
> > > Liang,
> > >
> > > Is the reason we are doing this b/c we need to call acpi_bus_register_driver
> > > and inhibit the registration of 'acpi_processor_driver' ?
> > >
> > > And the reason we don't want 'acpi_processor_driver' to run is b/c of what?
> > > If the cpuidle is disabled what is the harm of running the
> > > 'acpi_processor_driver'
> > > driver?
> >
> > IIRC, the reason why we want a Xen specific driver is because current driver
> > is integrated with OS logic too tightly, e.g. the various checks on VCPU related
> > structures. Long time ago the 1st version in Xen was to use same driver, by
> > adding various tweaking lines inside which makes it completely messed. Then
> > later it's found that it's clearer to create a Xen specific wrapping driver, by
> > invoking some exported functions from existing one.
> 
> What I am asking is does it matter "if the current driver is integrated
> with OS logic to tighly" - as it is not running anyhow (b/c cpuidle is
> disabled).
> 
> And if Xen specific driver can run along-side the generic one - since
> the generic one is not doing any work (b/c cpuidle is disabled).
> 
> That is what I am trying to figure out - since this patch purpose is to
> thwart the generic driver from running and allowing the xen one to run.

It's a separate issue from cpuidle case. Here we're talking about acpi processor
driver, not the acpi cpuidle driver. ACPI processor driver is responsible for 
discovering ACPI processor projects, and then enumerate various methods 
such as _PPC, _CST, etc. under those objects. So far this driver depends on 
VCPU presence in various places, which causes trouble when dom0 is configured
with less VCPU number than physical present one.

One example you can see from acpi_processor_add:

        result = acpi_processor_get_info(device); // call acpi_get_cpuid
        if (result) {
                /* Processor is physically not present */
                return 0;
        }

#ifdef CONFIG_SMP
        if (pr->id >= setup_max_cpus && pr->id != 0)
                return 0;
#endif 

        BUG_ON((pr->id >= nr_cpu_ids) || (pr->id < 0));

The binding between ACPI processor objects and VCPU presence would only parse
partial objects to Xen. And there're various places within driver validating pr->id
making it messy to workaround for Xen within same driver.

That's the major reason for coming up a Xen specific driver, which always parses
all present objects regardless of VCPU presence. :-)

Thanks
Kevin

> >
> > Thanks
> > Kevin
> >
> > >
> > > >
> > > > By default the values are set to the native one.
> > > >
> > > > Signed-off-by: Tang Liang <liang.tang@oracle.com>
> > > > Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > > > ---
> > > >  drivers/acpi/processor_driver.c |   35
> > > +++++++++++++++++++++++++++++------
> > > >  include/acpi/processor.h        |    6 +++++-
> > > >  2 files changed, 34 insertions(+), 7 deletions(-)
> > > >
> > > > diff --git a/drivers/acpi/processor_driver.c
> b/drivers/acpi/processor_driver.c
> > > > index 211c078..55f0b89 100644
> > > > --- a/drivers/acpi/processor_driver.c
> > > > +++ b/drivers/acpi/processor_driver.c
> > > > @@ -90,6 +90,11 @@ static const struct acpi_device_id
> > > processor_device_ids[] = {
> > > >  };
> > > >  MODULE_DEVICE_TABLE(acpi, processor_device_ids);
> > > >
> > > > +int (*__acpi_processor_register_driver)(void) =
> > > acpi_processor_register_driver;
> > > > +void (*__acpi_processor_unregister_driver)(void) \
> > > > +	= acpi_processor_unregister_driver;
> > > > +
> > > > +
> > > >  static struct acpi_driver acpi_processor_driver = {
> > > >  	.name = "processor",
> > > >  	.class = ACPI_PROCESSOR_CLASS,
> > > > @@ -779,6 +784,22 @@ void
> acpi_processor_uninstall_hotplug_notify(void)
> > > >  	unregister_hotcpu_notifier(&acpi_cpu_notifier);
> > > >  }
> > > >
> > > > +int acpi_processor_register_driver(void)
> > > > +{
> > > > +	int result = 0;
> > > > +
> > > > +	result = acpi_bus_register_driver(&acpi_processor_driver);
> > > > +	return result;
> > > > +}
> > > > +
> > > > +void acpi_processor_unregister_driver(void)
> > > > +{
> > > > +	acpi_bus_unregister_driver(&acpi_processor_driver);
> > > > +
> > > > +	cpuidle_unregister_driver(&acpi_idle_driver);
> > > > +
> > > > +	return;
> > > > +}
> > > >  /*
> > > >   * We keep the driver loaded even when ACPI is not running.
> > > >   * This is needed for the powernow-k8 driver, that works even without
> > > > @@ -794,9 +815,11 @@ static int __init acpi_processor_init(void)
> > > >
> > > >  	memset(&errata, 0, sizeof(errata));
> > > >
> > > > -	result = acpi_bus_register_driver(&acpi_processor_driver);
> > > > -	if (result < 0)
> > > > -		return result;
> > > > +	if (__acpi_processor_register_driver) {
> > > > +		result = __acpi_processor_register_driver();
> > > > +		if (result < 0)
> > > > +			return result;
> > > > +	}
> > > >
> > > >  	acpi_processor_install_hotplug_notify();
> > > >
> > > > @@ -809,6 +832,7 @@ static int __init acpi_processor_init(void)
> > > >  	return 0;
> > > >  }
> > > >
> > > > +
> > > >  static void __exit acpi_processor_exit(void)
> > > >  {
> > > >  	if (acpi_disabled)
> > > > @@ -820,9 +844,8 @@ static void __exit acpi_processor_exit(void)
> > > >
> > > >  	acpi_processor_uninstall_hotplug_notify();
> > > >
> > > > -	acpi_bus_unregister_driver(&acpi_processor_driver);
> > > > -
> > > > -	cpuidle_unregister_driver(&acpi_idle_driver);
> > > > +	if (__acpi_processor_unregister_driver)
> > > > +		__acpi_processor_unregister_driver();
> > > >
> > > >  	return;
> > > >  }
> > > > diff --git a/include/acpi/processor.h b/include/acpi/processor.h
> > > > index bd99fb6..969cbc9 100644
> > > > --- a/include/acpi/processor.h
> > > > +++ b/include/acpi/processor.h
> > > > @@ -225,6 +225,9 @@ struct acpi_processor_errata {
> > > >  	} piix4;
> > > >  };
> > > >
> > > > +extern int (*__acpi_processor_register_driver)(void);
> > > > +extern void (*__acpi_processor_unregister_driver)(void);
> > > > +
> > > >  extern int acpi_processor_preregister_performance(struct
> > > >  						  acpi_processor_performance
> > > >  						  __percpu *performance);
> > > > @@ -242,7 +245,8 @@ int acpi_processor_notify_smm(struct module
> > > *calling_module);
> > > >
> > > >  void acpi_processor_install_hotplug_notify(void);
> > > >  void acpi_processor_uninstall_hotplug_notify(void);
> > > > -
> > > > +int acpi_processor_register_driver(void);
> > > > +void acpi_processor_unregister_driver(void);
> > > >  int acpi_processor_add(struct acpi_device *device);
> > > >  int acpi_processor_remove(struct acpi_device *device, int type);
> > > >  void acpi_processor_notify(struct acpi_device *device, u32 event);
> > > > --
> > > > 1.7.7.3
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xensource.com
> > http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 20 02:30:23 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 Dec 2011 02:30:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RcpSU-0004gn-DH; Tue, 20 Dec 2011 02:29:38 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <kevin.tian@intel.com>) id 1RcpSS-0004gi-GG
	for xen-devel@lists.xensource.com; Tue, 20 Dec 2011 02:29:36 +0000
X-Env-Sender: kevin.tian@intel.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1324348169!2606148!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDI5ODYyMQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21361 invoked from network); 20 Dec 2011 02:29:30 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-9.tower-21.messagelabs.com with SMTP;
	20 Dec 2011 02:29:30 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga102.fm.intel.com with ESMTP; 19 Dec 2011 18:29:28 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="98156610"
Received: from pgsmsx602.gar.corp.intel.com ([10.221.43.81])
	by fmsmga001.fm.intel.com with ESMTP; 19 Dec 2011 18:29:26 -0800
Received: from shsmsx601.ccr.corp.intel.com (10.239.4.112) by
	pgsmsx602.gar.corp.intel.com (10.221.43.81) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Tue, 20 Dec 2011 10:29:15 +0800
Received: from shsmsx502.ccr.corp.intel.com ([10.239.4.96]) by
	shsmsx601.ccr.corp.intel.com ([10.239.4.112]) with mapi;
	Tue, 20 Dec 2011 10:29:14 +0800
From: "Tian, Kevin" <kevin.tian@intel.com>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
Date: Tue, 20 Dec 2011 10:29:12 +0800
Thread-Topic: [Xen-devel] [PATCH 3/8] ACPI: processor: add
	__acpi_processor_[un]register_driver helpers.
Thread-Index: Acy+WjcyXbsTIfQ3S1OCQ8XtHWNDEgAY0JcQ
Message-ID: <625BA99ED14B2D499DC4E29D8138F1506E01AAC03A@shsmsx502.ccr.corp.intel.com>
References: <1322673664-14642-1-git-send-email-konrad.wilk@oracle.com>
	<1322673664-14642-4-git-send-email-konrad.wilk@oracle.com>
	<20111216220342.GC9832@phenom.dumpdata.com>
	<625BA99ED14B2D499DC4E29D8138F1506E01AABC7A@shsmsx502.ccr.corp.intel.com>
	<20111219142626.GB27772@andromeda.dapyr.net>
In-Reply-To: <20111219142626.GB27772@andromeda.dapyr.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "jeremy@goop.org" <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"mike.mcclurg@citrix.com" <mike.mcclurg@citrix.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"stefan.bader@canonical.com" <stefan.bader@canonical.com>,
	"rjw@sisk.pl" <rjw@sisk.pl>,
	"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
	"liang.tang@oracle.com" <liang.tang@oracle.com>, "Yu,
	Ke" <ke.yu@intel.com>, "konrad@kernel.org" <konrad@kernel.org>,
	"lenb@kernel.org" <lenb@kernel.org>
Subject: Re: [Xen-devel] [PATCH 3/8] ACPI: processor: add
 __acpi_processor_[un]register_driver helpers.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> From: Konrad Rzeszutek Wilk [mailto:konrad@darnok.org]
> Sent: Monday, December 19, 2011 10:26 PM
> 
> On Mon, Dec 19, 2011 at 01:48:01PM +0800, Tian, Kevin wrote:
> > > From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@oracle.com]
> > > Sent: Saturday, December 17, 2011 6:04 AM
> > >
> > > On Wed, Nov 30, 2011 at 12:20:59PM -0500, Konrad Rzeszutek Wilk wrote:
> > > > From: Tang Liang <liang.tang@oracle.com>
> > > >
> > > > This patch implement __acpi_processor_[un]register_driver helper,
> > > > so we can registry override processor driver function. Specifically
> > > > the Xen processor driver.
> > >
> > > Liang,
> > >
> > > Is the reason we are doing this b/c we need to call acpi_bus_register_driver
> > > and inhibit the registration of 'acpi_processor_driver' ?
> > >
> > > And the reason we don't want 'acpi_processor_driver' to run is b/c of what?
> > > If the cpuidle is disabled what is the harm of running the
> > > 'acpi_processor_driver'
> > > driver?
> >
> > IIRC, the reason why we want a Xen specific driver is because current driver
> > is integrated with OS logic too tightly, e.g. the various checks on VCPU related
> > structures. Long time ago the 1st version in Xen was to use same driver, by
> > adding various tweaking lines inside which makes it completely messed. Then
> > later it's found that it's clearer to create a Xen specific wrapping driver, by
> > invoking some exported functions from existing one.
> 
> What I am asking is does it matter "if the current driver is integrated
> with OS logic to tighly" - as it is not running anyhow (b/c cpuidle is
> disabled).
> 
> And if Xen specific driver can run along-side the generic one - since
> the generic one is not doing any work (b/c cpuidle is disabled).
> 
> That is what I am trying to figure out - since this patch purpose is to
> thwart the generic driver from running and allowing the xen one to run.

It's a separate issue from cpuidle case. Here we're talking about acpi processor
driver, not the acpi cpuidle driver. ACPI processor driver is responsible for 
discovering ACPI processor projects, and then enumerate various methods 
such as _PPC, _CST, etc. under those objects. So far this driver depends on 
VCPU presence in various places, which causes trouble when dom0 is configured
with less VCPU number than physical present one.

One example you can see from acpi_processor_add:

        result = acpi_processor_get_info(device); // call acpi_get_cpuid
        if (result) {
                /* Processor is physically not present */
                return 0;
        }

#ifdef CONFIG_SMP
        if (pr->id >= setup_max_cpus && pr->id != 0)
                return 0;
#endif 

        BUG_ON((pr->id >= nr_cpu_ids) || (pr->id < 0));

The binding between ACPI processor objects and VCPU presence would only parse
partial objects to Xen. And there're various places within driver validating pr->id
making it messy to workaround for Xen within same driver.

That's the major reason for coming up a Xen specific driver, which always parses
all present objects regardless of VCPU presence. :-)

Thanks
Kevin

> >
> > Thanks
> > Kevin
> >
> > >
> > > >
> > > > By default the values are set to the native one.
> > > >
> > > > Signed-off-by: Tang Liang <liang.tang@oracle.com>
> > > > Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > > > ---
> > > >  drivers/acpi/processor_driver.c |   35
> > > +++++++++++++++++++++++++++++------
> > > >  include/acpi/processor.h        |    6 +++++-
> > > >  2 files changed, 34 insertions(+), 7 deletions(-)
> > > >
> > > > diff --git a/drivers/acpi/processor_driver.c
> b/drivers/acpi/processor_driver.c
> > > > index 211c078..55f0b89 100644
> > > > --- a/drivers/acpi/processor_driver.c
> > > > +++ b/drivers/acpi/processor_driver.c
> > > > @@ -90,6 +90,11 @@ static const struct acpi_device_id
> > > processor_device_ids[] = {
> > > >  };
> > > >  MODULE_DEVICE_TABLE(acpi, processor_device_ids);
> > > >
> > > > +int (*__acpi_processor_register_driver)(void) =
> > > acpi_processor_register_driver;
> > > > +void (*__acpi_processor_unregister_driver)(void) \
> > > > +	= acpi_processor_unregister_driver;
> > > > +
> > > > +
> > > >  static struct acpi_driver acpi_processor_driver = {
> > > >  	.name = "processor",
> > > >  	.class = ACPI_PROCESSOR_CLASS,
> > > > @@ -779,6 +784,22 @@ void
> acpi_processor_uninstall_hotplug_notify(void)
> > > >  	unregister_hotcpu_notifier(&acpi_cpu_notifier);
> > > >  }
> > > >
> > > > +int acpi_processor_register_driver(void)
> > > > +{
> > > > +	int result = 0;
> > > > +
> > > > +	result = acpi_bus_register_driver(&acpi_processor_driver);
> > > > +	return result;
> > > > +}
> > > > +
> > > > +void acpi_processor_unregister_driver(void)
> > > > +{
> > > > +	acpi_bus_unregister_driver(&acpi_processor_driver);
> > > > +
> > > > +	cpuidle_unregister_driver(&acpi_idle_driver);
> > > > +
> > > > +	return;
> > > > +}
> > > >  /*
> > > >   * We keep the driver loaded even when ACPI is not running.
> > > >   * This is needed for the powernow-k8 driver, that works even without
> > > > @@ -794,9 +815,11 @@ static int __init acpi_processor_init(void)
> > > >
> > > >  	memset(&errata, 0, sizeof(errata));
> > > >
> > > > -	result = acpi_bus_register_driver(&acpi_processor_driver);
> > > > -	if (result < 0)
> > > > -		return result;
> > > > +	if (__acpi_processor_register_driver) {
> > > > +		result = __acpi_processor_register_driver();
> > > > +		if (result < 0)
> > > > +			return result;
> > > > +	}
> > > >
> > > >  	acpi_processor_install_hotplug_notify();
> > > >
> > > > @@ -809,6 +832,7 @@ static int __init acpi_processor_init(void)
> > > >  	return 0;
> > > >  }
> > > >
> > > > +
> > > >  static void __exit acpi_processor_exit(void)
> > > >  {
> > > >  	if (acpi_disabled)
> > > > @@ -820,9 +844,8 @@ static void __exit acpi_processor_exit(void)
> > > >
> > > >  	acpi_processor_uninstall_hotplug_notify();
> > > >
> > > > -	acpi_bus_unregister_driver(&acpi_processor_driver);
> > > > -
> > > > -	cpuidle_unregister_driver(&acpi_idle_driver);
> > > > +	if (__acpi_processor_unregister_driver)
> > > > +		__acpi_processor_unregister_driver();
> > > >
> > > >  	return;
> > > >  }
> > > > diff --git a/include/acpi/processor.h b/include/acpi/processor.h
> > > > index bd99fb6..969cbc9 100644
> > > > --- a/include/acpi/processor.h
> > > > +++ b/include/acpi/processor.h
> > > > @@ -225,6 +225,9 @@ struct acpi_processor_errata {
> > > >  	} piix4;
> > > >  };
> > > >
> > > > +extern int (*__acpi_processor_register_driver)(void);
> > > > +extern void (*__acpi_processor_unregister_driver)(void);
> > > > +
> > > >  extern int acpi_processor_preregister_performance(struct
> > > >  						  acpi_processor_performance
> > > >  						  __percpu *performance);
> > > > @@ -242,7 +245,8 @@ int acpi_processor_notify_smm(struct module
> > > *calling_module);
> > > >
> > > >  void acpi_processor_install_hotplug_notify(void);
> > > >  void acpi_processor_uninstall_hotplug_notify(void);
> > > > -
> > > > +int acpi_processor_register_driver(void);
> > > > +void acpi_processor_unregister_driver(void);
> > > >  int acpi_processor_add(struct acpi_device *device);
> > > >  int acpi_processor_remove(struct acpi_device *device, int type);
> > > >  void acpi_processor_notify(struct acpi_device *device, u32 event);
> > > > --
> > > > 1.7.7.3
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xensource.com
> > http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 20 04:47:04 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 Dec 2011 04:47:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rcrak-0005Hh-3F; Tue, 20 Dec 2011 04:46:18 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Rcrai-0005HZ-PB
	for xen-devel@lists.xensource.com; Tue, 20 Dec 2011 04:46:16 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1324356369!7864378!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzEwMw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29328 invoked from network); 20 Dec 2011 04:46:09 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Dec 2011 04:46:09 -0000
X-IronPort-AV: E=Sophos;i="4.71,380,1320624000"; 
   d="scan'208";a="9568005"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Dec 2011 04:46:08 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 20 Dec 2011 04:46:08 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1Rcraa-00014y-6L;
	Tue, 20 Dec 2011 04:46:08 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RcraZ-0007ll-Pz;
	Tue, 20 Dec 2011 04:46:08 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10558-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 20 Dec 2011 04:46:07 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10558: tolerable FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10558 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10558/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-credit2   12 guest-saverestore.2         fail pass in 10555
 test-amd64-amd64-xl-sedf      5 xen-boot                    fail pass in 10555

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-sedf    14 guest-localmigrate/x10 fail in 10555 like 10554

version targeted for testing:
 xen                  a4bffc85bb71
baseline version:
 xen                  a4bffc85bb71

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 20 04:47:04 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 Dec 2011 04:47:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rcrak-0005Hh-3F; Tue, 20 Dec 2011 04:46:18 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Rcrai-0005HZ-PB
	for xen-devel@lists.xensource.com; Tue, 20 Dec 2011 04:46:16 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1324356369!7864378!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzEwMw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29328 invoked from network); 20 Dec 2011 04:46:09 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Dec 2011 04:46:09 -0000
X-IronPort-AV: E=Sophos;i="4.71,380,1320624000"; 
   d="scan'208";a="9568005"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Dec 2011 04:46:08 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 20 Dec 2011 04:46:08 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1Rcraa-00014y-6L;
	Tue, 20 Dec 2011 04:46:08 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RcraZ-0007ll-Pz;
	Tue, 20 Dec 2011 04:46:08 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10558-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 20 Dec 2011 04:46:07 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10558: tolerable FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10558 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10558/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-credit2   12 guest-saverestore.2         fail pass in 10555
 test-amd64-amd64-xl-sedf      5 xen-boot                    fail pass in 10555

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-sedf    14 guest-localmigrate/x10 fail in 10555 like 10554

version targeted for testing:
 xen                  a4bffc85bb71
baseline version:
 xen                  a4bffc85bb71

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 20 05:10:31 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 Dec 2011 05:10:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RcrxV-0005hH-4Z; Tue, 20 Dec 2011 05:09:49 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <hui.lv@intel.com>) id 1RcrxT-0005hC-Rs
	for xen-devel@lists.xensource.com; Tue, 20 Dec 2011 05:09:48 +0000
X-Env-Sender: hui.lv@intel.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1324357781!7393305!1
X-Originating-IP: [143.182.124.37]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjEzNjU1\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12166 invoked from network); 20 Dec 2011 05:09:41 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37)
	by server-13.tower-182.messagelabs.com with SMTP;
	20 Dec 2011 05:09:41 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga102.ch.intel.com with ESMTP; 19 Dec 2011 21:09:40 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="87522730"
Received: from unknown (HELO [127.0.0.1]) ([10.239.44.119])
	by azsmga001.ch.intel.com with ESMTP; 19 Dec 2011 21:09:39 -0800
MIME-Version: 1.0
X-Mercurial-Node: 114495d1ff947737518bba3f662f89956265619e
Message-Id: <114495d1ff947737518b.1324332781@wsm-ep-n0>
User-Agent: Mercurial-patchbomb/1.4
Date: Mon, 19 Dec 2011 17:13:01 -0500
From: Hui Lv <hui.lv@intel.com>
To: xen-devel@lists.xensource.com
Cc: George.Dunlap@eu.citrix.com, hui.lv@intel.com
Subject: [Xen-devel] [PATCH] xen/sched_credit: Use delay to control
	scheduling frequency
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

1. Basically, the "delay method" can achieve 11% overall performance boost for SPECvirt than original credit scheduler.
2. We have tried 1ms delay and 10ms delay, there is no big difference between these two configurations. (1ms is enough to achieve a good performance)
3. We have compared different load level response time/latency (low, high, peak), "delay method" didn't bring very much response time increase.
4. 1ms delay can reduce 30% context switch at peak performance, where produces the benefits. (.int sched_ratelimit_us = 1000. is the recommended setting)

Signed-off-by: Hui Lv <hui.lv@intel.com>
Signed-off-by: George Dunlap <George.Dunlap@eu.citrix.com>

diff -r a4bff36780a3 -r 114495d1ff94 xen/common/sched_credit.c
--- a/xen/common/sched_credit.c	Fri Dec 16 18:46:27 2011 +0000
+++ b/xen/common/sched_credit.c	Mon Dec 19 15:58:50 2011 -0500
@@ -110,6 +110,10 @@ boolean_param("sched_credit_default_yiel
 static int __read_mostly sched_credit_tslice_ms = CSCHED_DEFAULT_TSLICE_MS;
 integer_param("sched_credit_tslice_ms", sched_credit_tslice_ms);
 
+/* Scheduler generic parameters
+*/
+extern int sched_ratelimit_us;
+
 /*
  * Physical CPU
  */
@@ -1297,10 +1301,15 @@ csched_schedule(
     struct csched_private *prv = CSCHED_PRIV(ops);
     struct csched_vcpu *snext;
     struct task_slice ret;
+    s_time_t runtime, tslice;
 
     CSCHED_STAT_CRANK(schedule);
     CSCHED_VCPU_CHECK(current);
 
+    runtime = now - current->runstate.state_entry_time;
+    if ( runtime < 0 ) /* Does this ever happen? */
+        runtime = 0;
+
     if ( !is_idle_vcpu(scurr->vcpu) )
     {
         /* Update credits of a non-idle VCPU. */
@@ -1313,6 +1322,41 @@ csched_schedule(
         scurr->pri = CSCHED_PRI_IDLE;
     }
 
+    /* Choices, choices:
+     * - If we have a tasklet, we need to run the idle vcpu no matter what.
+     * - If sched rate limiting is in effect, and the current vcpu has
+     *   run for less than that amount of time, continue the current one,
+     *   but with a shorter timeslice and return it immediately
+     * - Otherwise, chose the one with the highest priority (which may
+     *   be the one currently running)
+     * - If the currently running one is TS_OVER, see if there
+     *   is a higher priority one waiting on the runqueue of another
+     *   cpu and steal it.
+     */
+
+    /* If we have schedule rate limiting enabled, check to see
+     * how long we've run for. */
+    if ( !tasklet_work_scheduled
+         && sched_ratelimit_us
+         && vcpu_runnable(current)
+         && !is_idle_vcpu(current)
+         && runtime < MICROSECS(sched_ratelimit_us) )
+    {
+        snext = scurr;
+        snext->start_time += now;
+        perfc_incr(delay_ms);
+        tslice = MICROSECS(sched_ratelimit_us);
+        ret.migrated = 0;
+        goto out;
+    }
+    else
+    {
+        /*
+         * Select next runnable local VCPU (ie top of local runq)
+        */
+        tslice = MILLISECS(prv->tslice_ms);
+    }
+
     /*
      * Select next runnable local VCPU (ie top of local runq)
      */
@@ -1367,11 +1411,12 @@ csched_schedule(
     if ( !is_idle_vcpu(snext->vcpu) )
         snext->start_time += now;
 
+out:
     /*
      * Return task to run next...
      */
     ret.time = (is_idle_vcpu(snext->vcpu) ?
-                -1 : MILLISECS(prv->tslice_ms));
+                -1 : tslice);
     ret.task = snext->vcpu;
 
     CSCHED_VCPU_CHECK(ret.task);
diff -r a4bff36780a3 -r 114495d1ff94 xen/common/schedule.c
--- a/xen/common/schedule.c	Fri Dec 16 18:46:27 2011 +0000
+++ b/xen/common/schedule.c	Mon Dec 19 15:58:50 2011 -0500
@@ -47,6 +47,12 @@ string_param("sched", opt_sched);
 bool_t sched_smt_power_savings = 0;
 boolean_param("sched_smt_power_savings", sched_smt_power_savings);
 
+/* Default scheduling rate limit: 1ms 
+ * It's not recommended to set this value bigger than "sched_credit_tslice_ms" 
+ * otherwise, something weired may happen
+ * */
+int sched_ratelimit_us = 1000;
+integer_param("sched_ratelimit_us", sched_ratelimit_us);
 /* Various timer handlers. */
 static void s_timer_fn(void *unused);
 static void vcpu_periodic_timer_fn(void *data);
diff -r a4bff36780a3 -r 114495d1ff94 xen/include/xen/perfc_defn.h
--- a/xen/include/xen/perfc_defn.h	Fri Dec 16 18:46:27 2011 +0000
+++ b/xen/include/xen/perfc_defn.h	Mon Dec 19 15:58:50 2011 -0500
@@ -16,6 +16,7 @@ PERFCOUNTER(sched_irq,              "sch
 PERFCOUNTER(sched_run,              "sched: runs through scheduler")
 PERFCOUNTER(sched_ctx,              "sched: context switches")
 
+PERFCOUNTER(delay_ms,               "csched: delay")
 PERFCOUNTER(vcpu_check,             "csched: vcpu_check")
 PERFCOUNTER(schedule,               "csched: schedule")
 PERFCOUNTER(acct_run,               "csched: acct_run")

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 20 05:10:31 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 Dec 2011 05:10:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RcrxV-0005hH-4Z; Tue, 20 Dec 2011 05:09:49 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <hui.lv@intel.com>) id 1RcrxT-0005hC-Rs
	for xen-devel@lists.xensource.com; Tue, 20 Dec 2011 05:09:48 +0000
X-Env-Sender: hui.lv@intel.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1324357781!7393305!1
X-Originating-IP: [143.182.124.37]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjEzNjU1\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12166 invoked from network); 20 Dec 2011 05:09:41 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37)
	by server-13.tower-182.messagelabs.com with SMTP;
	20 Dec 2011 05:09:41 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga102.ch.intel.com with ESMTP; 19 Dec 2011 21:09:40 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="87522730"
Received: from unknown (HELO [127.0.0.1]) ([10.239.44.119])
	by azsmga001.ch.intel.com with ESMTP; 19 Dec 2011 21:09:39 -0800
MIME-Version: 1.0
X-Mercurial-Node: 114495d1ff947737518bba3f662f89956265619e
Message-Id: <114495d1ff947737518b.1324332781@wsm-ep-n0>
User-Agent: Mercurial-patchbomb/1.4
Date: Mon, 19 Dec 2011 17:13:01 -0500
From: Hui Lv <hui.lv@intel.com>
To: xen-devel@lists.xensource.com
Cc: George.Dunlap@eu.citrix.com, hui.lv@intel.com
Subject: [Xen-devel] [PATCH] xen/sched_credit: Use delay to control
	scheduling frequency
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

1. Basically, the "delay method" can achieve 11% overall performance boost for SPECvirt than original credit scheduler.
2. We have tried 1ms delay and 10ms delay, there is no big difference between these two configurations. (1ms is enough to achieve a good performance)
3. We have compared different load level response time/latency (low, high, peak), "delay method" didn't bring very much response time increase.
4. 1ms delay can reduce 30% context switch at peak performance, where produces the benefits. (.int sched_ratelimit_us = 1000. is the recommended setting)

Signed-off-by: Hui Lv <hui.lv@intel.com>
Signed-off-by: George Dunlap <George.Dunlap@eu.citrix.com>

diff -r a4bff36780a3 -r 114495d1ff94 xen/common/sched_credit.c
--- a/xen/common/sched_credit.c	Fri Dec 16 18:46:27 2011 +0000
+++ b/xen/common/sched_credit.c	Mon Dec 19 15:58:50 2011 -0500
@@ -110,6 +110,10 @@ boolean_param("sched_credit_default_yiel
 static int __read_mostly sched_credit_tslice_ms = CSCHED_DEFAULT_TSLICE_MS;
 integer_param("sched_credit_tslice_ms", sched_credit_tslice_ms);
 
+/* Scheduler generic parameters
+*/
+extern int sched_ratelimit_us;
+
 /*
  * Physical CPU
  */
@@ -1297,10 +1301,15 @@ csched_schedule(
     struct csched_private *prv = CSCHED_PRIV(ops);
     struct csched_vcpu *snext;
     struct task_slice ret;
+    s_time_t runtime, tslice;
 
     CSCHED_STAT_CRANK(schedule);
     CSCHED_VCPU_CHECK(current);
 
+    runtime = now - current->runstate.state_entry_time;
+    if ( runtime < 0 ) /* Does this ever happen? */
+        runtime = 0;
+
     if ( !is_idle_vcpu(scurr->vcpu) )
     {
         /* Update credits of a non-idle VCPU. */
@@ -1313,6 +1322,41 @@ csched_schedule(
         scurr->pri = CSCHED_PRI_IDLE;
     }
 
+    /* Choices, choices:
+     * - If we have a tasklet, we need to run the idle vcpu no matter what.
+     * - If sched rate limiting is in effect, and the current vcpu has
+     *   run for less than that amount of time, continue the current one,
+     *   but with a shorter timeslice and return it immediately
+     * - Otherwise, chose the one with the highest priority (which may
+     *   be the one currently running)
+     * - If the currently running one is TS_OVER, see if there
+     *   is a higher priority one waiting on the runqueue of another
+     *   cpu and steal it.
+     */
+
+    /* If we have schedule rate limiting enabled, check to see
+     * how long we've run for. */
+    if ( !tasklet_work_scheduled
+         && sched_ratelimit_us
+         && vcpu_runnable(current)
+         && !is_idle_vcpu(current)
+         && runtime < MICROSECS(sched_ratelimit_us) )
+    {
+        snext = scurr;
+        snext->start_time += now;
+        perfc_incr(delay_ms);
+        tslice = MICROSECS(sched_ratelimit_us);
+        ret.migrated = 0;
+        goto out;
+    }
+    else
+    {
+        /*
+         * Select next runnable local VCPU (ie top of local runq)
+        */
+        tslice = MILLISECS(prv->tslice_ms);
+    }
+
     /*
      * Select next runnable local VCPU (ie top of local runq)
      */
@@ -1367,11 +1411,12 @@ csched_schedule(
     if ( !is_idle_vcpu(snext->vcpu) )
         snext->start_time += now;
 
+out:
     /*
      * Return task to run next...
      */
     ret.time = (is_idle_vcpu(snext->vcpu) ?
-                -1 : MILLISECS(prv->tslice_ms));
+                -1 : tslice);
     ret.task = snext->vcpu;
 
     CSCHED_VCPU_CHECK(ret.task);
diff -r a4bff36780a3 -r 114495d1ff94 xen/common/schedule.c
--- a/xen/common/schedule.c	Fri Dec 16 18:46:27 2011 +0000
+++ b/xen/common/schedule.c	Mon Dec 19 15:58:50 2011 -0500
@@ -47,6 +47,12 @@ string_param("sched", opt_sched);
 bool_t sched_smt_power_savings = 0;
 boolean_param("sched_smt_power_savings", sched_smt_power_savings);
 
+/* Default scheduling rate limit: 1ms 
+ * It's not recommended to set this value bigger than "sched_credit_tslice_ms" 
+ * otherwise, something weired may happen
+ * */
+int sched_ratelimit_us = 1000;
+integer_param("sched_ratelimit_us", sched_ratelimit_us);
 /* Various timer handlers. */
 static void s_timer_fn(void *unused);
 static void vcpu_periodic_timer_fn(void *data);
diff -r a4bff36780a3 -r 114495d1ff94 xen/include/xen/perfc_defn.h
--- a/xen/include/xen/perfc_defn.h	Fri Dec 16 18:46:27 2011 +0000
+++ b/xen/include/xen/perfc_defn.h	Mon Dec 19 15:58:50 2011 -0500
@@ -16,6 +16,7 @@ PERFCOUNTER(sched_irq,              "sch
 PERFCOUNTER(sched_run,              "sched: runs through scheduler")
 PERFCOUNTER(sched_ctx,              "sched: context switches")
 
+PERFCOUNTER(delay_ms,               "csched: delay")
 PERFCOUNTER(vcpu_check,             "csched: vcpu_check")
 PERFCOUNTER(schedule,               "csched: schedule")
 PERFCOUNTER(acct_run,               "csched: acct_run")

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 20 06:27:28 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 Dec 2011 06:27:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RctA5-0006Cw-GS; Tue, 20 Dec 2011 06:26:53 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <liang.tang@oracle.com>) id 1RctA4-0006Co-Cu
	for xen-devel@lists.xensource.com; Tue, 20 Dec 2011 06:26:52 +0000
X-Env-Sender: liang.tang@oracle.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1324362404!8713418!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ0ODMwOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25353 invoked from network); 20 Dec 2011 06:26:45 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-6.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 20 Dec 2011 06:26:45 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pBK6PnVt017533
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 20 Dec 2011 06:25:50 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pBK6Pjnx009463
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 20 Dec 2011 06:25:45 GMT
Received: from abhmt116.oracle.com (abhmt116.oracle.com [141.146.116.68])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pBK6Pf22005928; Tue, 20 Dec 2011 00:25:41 -0600
Received: from [10.182.38.104] (/10.182.38.104)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 19 Dec 2011 22:25:41 -0800
Message-ID: <4EF02A5C.1030803@oracle.com>
Date: Tue, 20 Dec 2011 14:25:32 +0800
From: liang tang <liang.tang@oracle.com>
Organization: Oracle Corporation
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.9.2.23) Gecko/20110920 Thunderbird/3.1.15
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
References: <1322673664-14642-1-git-send-email-konrad.wilk@oracle.com>
	<1322673664-14642-5-git-send-email-konrad.wilk@oracle.com>
	<20111216213618.GB9832@phenom.dumpdata.com>
	<4EEF12DD.2020308@oracle.com>
	<20111219142645.GC27772@andromeda.dapyr.net>
In-Reply-To: <20111219142645.GC27772@andromeda.dapyr.net>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090204.4EF02A6F.00B6,ss=1,re=0.000,fgs=0
Cc: jeremy@goop.org, xen-devel@lists.xensource.com, Ian.Campbell@citrix.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	mike.mcclurg@citrix.com, linux-acpi@vger.kernel.org,
	stefan.bader@canonical.com, rjw@sisk.pl, konrad@kernel.org, lenb@kernel.org
Subject: Re: [Xen-devel] [PATCH 4/8] ACPI: processor: Don't setup cpu idle
 driver and handler when we do not want them.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com



On 2011-12-19 22:26, Konrad Rzeszutek Wilk wrote:
> On Mon, Dec 19, 2011 at 06:33:01PM +0800, liang tang wrote:
>> On 2011-12-17 5:36, Konrad Rzeszutek Wilk wrote:
>>> On Wed, Nov 30, 2011 at 12:21:00PM -0500, Konrad Rzeszutek Wilk wrote:
>>>> From: Kevin Tian<kevin.tian@intel.com>
>>>>
>>>> This patch inhibits processing of the CPU idle handler if it is not
>>>> set to the appropiate one. This is needed by the Xen processor driver
>>>> which, while still needing processor details, wants to use the
>>>> default_idle
>>>> call (which makes a yield hypercall).
>>> Which I think is not required anymore with the
>>> d91ee5863b71e8c90eaf6035bff3078a85e2e7b5
>>> (cpuidle: replace xen access to x86 pm_idle and default_idle) and
>>> 62027aea23fcd14478abdddd3b74a4e0f5fb2984
>>> (cpuidle: create bootparam "cpuidle.off=1")
>>>
>>> Liang, can you double-check that please?
>>>
>> Hi,Konrad
>> I just read the code ,I think  don't need that code too. I will double
>> check tomorrow.
> Great! Thanks!
I have check the code, I think that will be not call. I think we can 
remove this patch .
liang
thanks !

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 20 06:27:28 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 Dec 2011 06:27:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RctA5-0006Cw-GS; Tue, 20 Dec 2011 06:26:53 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <liang.tang@oracle.com>) id 1RctA4-0006Co-Cu
	for xen-devel@lists.xensource.com; Tue, 20 Dec 2011 06:26:52 +0000
X-Env-Sender: liang.tang@oracle.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1324362404!8713418!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ0ODMwOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25353 invoked from network); 20 Dec 2011 06:26:45 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-6.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 20 Dec 2011 06:26:45 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pBK6PnVt017533
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 20 Dec 2011 06:25:50 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pBK6Pjnx009463
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 20 Dec 2011 06:25:45 GMT
Received: from abhmt116.oracle.com (abhmt116.oracle.com [141.146.116.68])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pBK6Pf22005928; Tue, 20 Dec 2011 00:25:41 -0600
Received: from [10.182.38.104] (/10.182.38.104)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 19 Dec 2011 22:25:41 -0800
Message-ID: <4EF02A5C.1030803@oracle.com>
Date: Tue, 20 Dec 2011 14:25:32 +0800
From: liang tang <liang.tang@oracle.com>
Organization: Oracle Corporation
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.9.2.23) Gecko/20110920 Thunderbird/3.1.15
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
References: <1322673664-14642-1-git-send-email-konrad.wilk@oracle.com>
	<1322673664-14642-5-git-send-email-konrad.wilk@oracle.com>
	<20111216213618.GB9832@phenom.dumpdata.com>
	<4EEF12DD.2020308@oracle.com>
	<20111219142645.GC27772@andromeda.dapyr.net>
In-Reply-To: <20111219142645.GC27772@andromeda.dapyr.net>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090204.4EF02A6F.00B6,ss=1,re=0.000,fgs=0
Cc: jeremy@goop.org, xen-devel@lists.xensource.com, Ian.Campbell@citrix.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	mike.mcclurg@citrix.com, linux-acpi@vger.kernel.org,
	stefan.bader@canonical.com, rjw@sisk.pl, konrad@kernel.org, lenb@kernel.org
Subject: Re: [Xen-devel] [PATCH 4/8] ACPI: processor: Don't setup cpu idle
 driver and handler when we do not want them.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com



On 2011-12-19 22:26, Konrad Rzeszutek Wilk wrote:
> On Mon, Dec 19, 2011 at 06:33:01PM +0800, liang tang wrote:
>> On 2011-12-17 5:36, Konrad Rzeszutek Wilk wrote:
>>> On Wed, Nov 30, 2011 at 12:21:00PM -0500, Konrad Rzeszutek Wilk wrote:
>>>> From: Kevin Tian<kevin.tian@intel.com>
>>>>
>>>> This patch inhibits processing of the CPU idle handler if it is not
>>>> set to the appropiate one. This is needed by the Xen processor driver
>>>> which, while still needing processor details, wants to use the
>>>> default_idle
>>>> call (which makes a yield hypercall).
>>> Which I think is not required anymore with the
>>> d91ee5863b71e8c90eaf6035bff3078a85e2e7b5
>>> (cpuidle: replace xen access to x86 pm_idle and default_idle) and
>>> 62027aea23fcd14478abdddd3b74a4e0f5fb2984
>>> (cpuidle: create bootparam "cpuidle.off=1")
>>>
>>> Liang, can you double-check that please?
>>>
>> Hi,Konrad
>> I just read the code ,I think  don't need that code too. I will double
>> check tomorrow.
> Great! Thanks!
I have check the code, I think that will be not call. I think we can 
remove this patch .
liang
thanks !

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 20 07:31:17 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 Dec 2011 07: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.xensource.com>)
	id 1Rcu9k-0006jK-Qd; Tue, 20 Dec 2011 07:30:36 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <gbtux@126.com>) id 1Rcu9i-0006jF-Rk
	for xen-devel@lists.xensource.com; Tue, 20 Dec 2011 07:30:35 +0000
X-Env-Sender: gbtux@126.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1324366224!8007457!1
X-Originating-IP: [220.181.15.49]
X-SpamReason: No, hits=1.4 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMjAuMTgxLjE1LjQ5ID0+IDQ2NTE=\n,sa_preprocessor: 
	QmFkIElQOiAyMjAuMTgxLjE1LjQ5ID0+IDQ2NTE=\n, BODY_RANDOM_LONG, HTML_40_50,
	HTML_MESSAGE,MIME_BASE64_TEXT
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8398 invoked from network); 20 Dec 2011 07:30:25 -0000
Received: from m15-49.126.com (HELO m15-49.126.com) (220.181.15.49)
	by server-10.tower-216.messagelabs.com with SMTP;
	20 Dec 2011 07:30:25 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=126.com;
	s=s110527; h=Received:Date:From:To:Cc:Message-ID:In-Reply-To:
	References:Subject:MIME-Version:Content-Type; bh=r8UOB7gXYgFAWP3
	W+W3A/9Y63X9rCb9aBxEpA8IZoW0=; b=PNhN8K8obt+NQjUgdJcjfmyMVRA6k7o
	eoHutIoozyYbZfffus3gunwrOtDgb39Qpd4+PscXPwYf9X3adXHosuSlZuIs4H3B
	LU13rdt/O3mRGFyUmShuvNl/Tc2h+4p5d0bXTw/wtw3FY93pH+WBxYD4SY05hCu+
	HPPe0trsrotU=
Received: from gbtux ( [124.16.139.196] ) by ajax-webmail-wmsvr49 (Coremail)
	; Tue, 20 Dec 2011 15:30:04 +0800 (CST)
Date: Tue, 20 Dec 2011 15:30:04 +0800 (CST)
From: gavin  <gbtux@126.com>
To: "George Dunlap" <George.Dunlap@eu.citrix.com>
Message-ID: <5097e419.1e4d1.1345a608e69.Coremail.gbtux@126.com>
In-Reply-To: <CAFLBxZZP=K504L86WDJ-F+9SuTf7aKU_C=i8nLZwqDuejoVGag@mail.gmail.com>
References: <CAFLBxZZP=K504L86WDJ-F+9SuTf7aKU_C=i8nLZwqDuejoVGag@mail.gmail.com>
	<26c93838.3b3fb.13445de0e67.Coremail.gbtux@126.com>
	<CAFLBxZYM-8vEc5Egmv+iXqMDUE_UJcgHbwr7=71H-kFowTzXWA@mail.gmail.com>
	<676b608e.2fb26.13447553671.Coremail.gbtux@126.com>
	<CAFLBxZaBiwEvz-dgPzgBQQTj2xMi8m+QnZ3M+uoqw4AKmb0ZvA@mail.gmail.com>
	<35e4701f.ca5a.1344b4ed98e.Coremail.gbtux@126.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; 
	boundary="----=_Part_343555_1040962665.1324366204520"
X-Originating-IP: [124.16.139.196]
X-Priority: 3
X-Mailer: Coremail Webmail Server Version SP_ntes V3.5 build
	111202(16086.4213.4207) Copyright (c) 2002-2011 www.mailtech.cn 126com
X-CM-CTRLDATA: +yLaI2Zvb3Rlcl9odG09MTM0OTI6ODE=
X-CM-TRANSID: McqowEAZQUV_OfBO3bcXAA--.878W
X-CM-SenderInfo: pjew35a6rslhhfrp/1tbiVwEcnE3l6FM+ZAABse
X-Coremail-Antispam: 1U5529EdanIXcx71UUUUU7vcSsGvfC2KfnxnUU==
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] A question on the credit scheduler
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

------=_Part_343555_1040962665.1324366204520
Content-Type: multipart/alternative; 
	boundary="----=_Part_343557_1060246463.1324366204521"

------=_Part_343557_1060246463.1324366204521
Content-Type: text/plain; charset=GBK
Content-Transfer-Encoding: base64

MSkgTXkgb3JpZ2luYWwgZ29hbCBpcyB0byBjYWxjdWxhdGUgdGhlIHVzYWdlIHBlcmNlbnRhZ2Ug
b2YgQ1BVIGluIGEgZGlmZmVyZW50IHdheSBmcm9tIG90aGVyIHRvb2xzLCBzdWNoIGFzIHhlbnRy
YWNlLgoKQmVjYXVzZSB0aGUgYWltIG9mIGFsbCB0aGUgc2NoZWR1bGluZyBpcyB0byBtYXAgdGhl
IHZDUFUgdG8gcENQVSwgd2UgY2FuIGdldCBhIG1hcHBpbmcgc2VxdWVuY2Ugb2YgcENQVSBhbmQg
dkNQVSBieSBtb25pdG9yaW5nIHRoZSBwQ1BVIGluIGEgZml4ZWQgaW50ZXJ2YWwuIAoKRm9yIGV4
YW1wbGUsIGlmIHRoZSBTQ0hFRFVMRV9TT0ZUSVJRIGlzIGp1c3QgcmFpc2VkIHdoZW4gdGhlIHRp
bWVzbGljZSBpcyBmaW5pc2hlZCwgdGhlIHZDUFUgcnVucyBhcyBkZXNjcmliZWQgaW4gdGhlIGZp
Z3VyZSAxICh0d28gcENQVSBhbmQgdGhyZWUgdkNQVSkuIFdlIG1vbml0b3IgYWxsIHRoZSBDUFVz
IG9uY2UgZXZlcnkgdGltZSB0LCB3aGljaCBpcyBlcXVhbCB0byB0aGUgdGltZSBvZiB0aGUgdGlt
ZXNsaWNlIGhlcmUuIEluIHRlbiB0aW1lc2xpY2UgKG1heWJlIDAuMyBzZWNvbmQgaW4gY3JlZGl0
MSksIHdlIGNhbiBnZXQgdGhlIG1hcHBpbmcgc2VxdWVuY2UsIHdoaWNoIGNvbnRhaW5zIDIwIChw
Q1BVLCB2Q1BVKSBwYWlycyBhcyB0aGUgZm9sbG93aW5nLgoKKHBDUFUxLCB2Q1BVMSksIChwQ1BV
MiwgdkNQVTIpLCAocENQVTEsIHZDUFUxKSwgKHBDUFUyLCBub24pLCAocENQVTEsIHZDUFUxKSwg
KHBDUFUyLCB2Q1BVMyksIChwQ1BVMSwgdkNQVTIpLCAocENQVTIsIG5vbiksIChwQ1BVMSwgbm9u
KSwgKHBDUFUyLCB2Q1BVMiksIChwQ1BVMSwgdkNQVTMpLCAocENQVTIsIG5vbiksIChwQ1BVMSwg
dkNQVTMpLCAocENQVTIsIHZDUFUxKSwgKHBDUFUxLCBub24pLCAocENQVTIsIHZDUFUxKSwgKHBD
UFUxLCB2Q1BVMSksIChwQ1BVMiwgbm9uKSwgKHBDUFUxLCBub24pLCAocENQVTIsIHZDUFUyKaGj
CgpJZiB0aGVyZSBpcyBubyB2Q1BVIG1hcHBlZCBvbiB0aGUgcENQVSwgd2UgdXNlIChwQ1BVKiwg
bm9uKSBwYWlyLCB3aGljaCBtZWFucyB0aGUgcENQVSBpcyBpZGxlLiBJbiB0aGUgYWJvdmUgc2Vx
dWVuY2UsIHRoZXJlIGFyZSA3IGlkbGUgcGFpcnMgaW4gdG90YWwuIAoKU28sIGZyb20gdGhlIGFi
b3ZlIG1hcHBpbmcgc2VxdWVuY2UsIHdlIGNhbiBjYWxjdWxhdGUgdGhlIHVzYWdlIHBlcmNlbnRh
Z2Ugb2YgdGhlIENQVSBpbiB0ZW4gdGltZXNsY2llICgwLjMgc2VuY29uZCkuCgpVc2FnZSBQZXJj
ZW50YWdlID0gKDIwLTcpLzIwID0gNjUlIAoKMikgSWYgd2UgY2FuIGdldCBzdWNoIGEgbWFwcGlu
ZyBzZXF1ZW5jZSBvZiBwQ1BVIGFuZCB2Q1BVLCBiZXNpZGVzIGNhbGN1bGF0aW5nIHRoZSB1c2Fn
ZSBwZXJjZW50YWdlIG9mIENQVSwgbWF5YmUgd2UgYWxzbyBjYW4gZmluZCBzb21lbGF3cyBvZiB0
aGUgbWFwcGluZyBzZXF1ZW5jZSBhbmQgdXNlIHRoZSBsYXdzIHRvIGluZmVyIHRoZSBDUFUtYm91
bmQgdGFzayBhbmQgSS9PLWJvdW5kIHRhc2suIAoKSG93ZXZlciwgdGhpcyBpZGVhIG1heSBub3Qg
d29yay4gQmVjYXVzZSB0aGUgU0NIRURVTEVfU09GVElSUSBpcyBub3Qgb25seSByYWlzZWQgd2hl
biB0aGUgdGltZXNsaWNlIGlzIGZpbmlzaGVkLCBidXQgYWxzbyByYWlzZWQgaW4gbWFueSBvdGhl
ciBzaXR1YXRpb25zLCB3ZSBjYW5ub3QgZ2V0IGEgcmVndWxhciBtYXBwaW5nIG9mIHZDUFUgYW5k
IHBDUFUganVzdCBsaWtlIGZpZ3VyZSAxLiBUaGUgbWFwcGluZyBpcyBpcnJlZ3VsYXIgcG9zc2li
bHkgc2hvd24gaW4gZmlndXJlIDIuIEluIHRoZSBmaWd1cmUgMiwgd2UgY2Fubm90IGZpbmQgYSB2
ZXJ5IHByb3BlciB0aW1lIHQgdG8gbW9uaXRvciB0aGUgQ1BVcy4KCgoKLS0KQmVzdCBSZWdhcmRz
LApHYXZpbgoKCgpBdCAyMDExLTEyLTE5IDE4OjM3OjE0LCJHZW9yZ2UgRHVubGFwIiA8R2Vvcmdl
LkR1bmxhcEBldS5jaXRyaXguY29tPiB3cm90ZToKPjIwMTEvMTIvMTcgZ2F2aW4gPGdidHV4QDEy
Ni5jb20+Ogo+Pgo+PiBBdCAyMDExLTEyLTE2IDIzOjU4OjI2LCJHZW9yZ2UgRHVubGFwIiA8R2Vv
cmdlLkR1bmxhcEBldS5jaXRyaXguY29tPiB3cm90ZToKPj4+MjAxMS8xMi8xNiBnYXZpbiA8Z2J0
dXhAMTI2LmNvbT46Cj4+Pj4gQXQgMjAxMS0xMi0xNiAxOTowNDoxOSwiR2VvcmdlIER1bmxhcCIg
PEdlb3JnZS5EdW5sYXBAZXUuY2l0cml4LmNvbT4gd3JvdGU6Cj4+Pj4KPj4+Pj4yMDExLzEyLzE2
IHpoaWthaSA8Z2J0dXhAMTI2LmNvbT46Cj4+Pj4+PiBIaSBBbGwsCj4+Pj4+Pgo+Pj4+Pj4gSW4g
dGhlIGNyZWRpdCBzY2hlZHVsZXIsIHRoZSBzY2hlZHVsaW5nIGRlY2lzaW9uIGZ1bmN0aW9uIGNz
Y2hlZF9zY2hlZHVsZSgpCj4+Pj4+PiBpcyBjYWxsZWQgaW4gdGhlIHNjaGVkdWxlIGZ1bmN0aW9u
IGluIHNjaGVkdWxlci5jLCBzdWNoIGFzIHRoZSBmb2xsb3dpbmcuCj4+Pj4+PiBuZXh0X3NsaWNl
ID0gc2NoZWQtPmRvX3NjaGVkdWxlKHNjaGVkLCBub3csIHRhc2tsZXRfd29ya19zY2hlZHVsZWQp
Owo+Pj4+Pj4KPj4+Pj4+IEJ1dCwgaG93IG9mdGVuIHRoZSBjc2NoZWRfc2NoZWR1bGUoKSBpcyBj
YWxsZWQgYW5kIHRvIHJ1bj8gRG9lcyB0aGlzCj4+Pj4+PiBmcmVxdWVuY3kgaGF2ZSBzb21ldGhp
bmcgdG8gZG8gd2l0aCB0aGUgc2xpY2Ugb2YgY3JlZGl0IHNjaGVkdWxlciB0aGF0IGlzCj4+Pj4+
PiAzMG1zPwo+Pj4+Pgo+Pj4+PlRoZSBzY2hlZHVsZXIgcnVucyB3aGVuZXZlciB0aGUgU0NIRURV
TEVfU09GVElSUSBpcyByYWlzZWQuICBJZiB5b3UKPj4+Pj5ncmVwIHRocm91Z2ggdGhlIHNvdXJj
ZSBjb2RlIGZybyB0aGF0IHN0cmluZywgeW91IGNhbiBmaW5kIGFsbCB0aGUKPj4+Pj5wbGFjZXMg
d2hlcmUgaXQncyByYWlzZWQuCj4+Pj4+Cj4+Pj4+U29tZSBleGFtcGxlcyBpbmNsdWRlOgo+Pj4+
PiogV2hlbiB0aGUgMzBtcyB0aW1lc2xpY2UgaXMgZmluaXNoZWQKPj4+Pj4qIFdoZW4gYSBzbGVl
cGluZyB2Y3B1IG9mIGhpZ2hlciBwcmlvcml0eSB0aGFuIHdoYXQncyBjdXJyZW50bHkgcnVubmlu
ZyB3YWtlcyB1cAo+Pj4+PiogV2hlbiBhIHZjcHUgYmxvY2tzCj4+Pj4+KiBXaGVuIGEgdmNwdSBp
cyBtaWdyYXRlZCBmcm9tIG9uZSBjcHUgdG8gYW5vdGhlcgo+Pj4+Pgo+Pj4+PjMwbXMgaXMgYWN0
dWFsbHkgYSBwcmV0dHkgbG9uZyB0aW1lOyBpbiB0eXBpY2FsIHdvcmtsb2FkcywgdmNwdXMgYmxv
Y2sKPj4+Pj5vciBhcmUgcHJlZW1wdGVkIGJ5IG90aGVyIHdha2luZyB2Y3B1cyB3aXRob3V0IHVz
aW5nIHVwIHRoZWlyIGZ1bGwKPj4+Pj50aW1lc2xpY2UuCj4+Pj4KPj4+PiBUaGFuayB5b3UgdmVy
eSBtdWNoIGZvciB5b3VyIHJlcGx5Lgo+Pj4+Cj4+Pj4gU28sIHRoZSB2Y3B1IGlzIHZlcnkgbGlr
ZWx5IHRvIGJlIHByZWVtcHRlZCB3aGVuZXZlciB0aGUgU0NIRURVTEVfU09GVElSUSBpcwo+Pj4+
IHJhaXNlZC4KPj4+Cj4+Pkl0IGRlcGVuZHM7IGlmIHlvdSBoYXZlIGEgY3B1LWJ1cm5pbmcgdmNw
dSBydW5uaW5nIG9uIGEgY3B1IGFsbCBieQo+Pj5pdHNlbGYsIHRoZW4gYWZ0ZXIgaXRzIDMwbXMg
dGltZXNsaWNlLCBYZW4gd2lsbCBoYXZlIG5vIG9uZSBlbHNlIHRvCj4+PnJ1biwgYW5kIHNvIHdp
bGwgbGV0IGl0IHJ1biBhZ2Fpbi4KPj4+Cj4+PkJ1dCB5ZXMsIGlmIHRoZXJlIGFyZSBvdGhlciB2
Y3B1cyBvbiB0aGUgcnVucXVldWUsIG9yIHRoZSBob3N0IGlzCj4+Pm1vZGVyYXRlbHkgYnVzeSwg
aXQncyBsaWtlbHkgdGhhdCBTQ0hFRFVMRV9TT0ZUSVJRIHdpbGwgY2F1c2UgYQo+Pj5jb250ZXh0
LXN3aXRjaC4KPj4+Cj4+Pj4gQW5kIHdlIGNhbm5vdCBmaW5kIGEgc21hbGwgdGltZXNsaWNlLCBz
dWNoIGFzIGEobXMpLCB3aGljaCBtYWtlcyB0aGUKPj4+PiB0aW1lIGFueSB2Y3B1IHNwZW5kaW5n
IG9uIHJ1bm5pbmcgcGhhc2UgaXMgayphKG1zKSwgayBpcyBpbnRlZ2VyIGhlcmUuIFRoZXJlCj4+
Pj4gaXMgbm8gc3VjaCBhIHNtYWxsIHRpbWVzbGljZS4gSXMgaXQgcmlnaHQ/Cj4+Pgo+Pj5JJ20g
c29ycnksIEkgZG9uJ3QgcmVhbGx5IHVuZGVyc3RhbmQgeW91ciBxdWVzdGlvbi4gIFBlcmhhcHMg
aWYgeW91Cj4+PnRvbGQgbWUgd2hhdCB5b3UncmUgdHJ5aW5nIHRvIGFjY29tcGxpc2g/Cj4+Cj4+
IEkgdHJ5IHRvIGRlc2NyaWJlIG15IGlkZWEgYXMgdGhlIGZvbGxvd2luZyBjbGVhcmx5LiBCdXQg
SSByZWFsbHkgZG9uJ3Qga25vdwo+PiBpZiBpdCB3aWxsIHdvcmsuIFBsZWFzZSBnaXZlIG1lIHNv
bWUgYWR2aWNlIGlmIHBvc3NpYmxlLgo+Pgo+PiBBY2NvcmRpbmcgdG8gdGhlIGNyZWRpdCBzY2hl
ZHVsZXIgaW4gWGVuLCBhIHZDUFUgY2FuIHJ1biBhIDMwbXMgdGltZXNsaWNlCj4+IHdoZW4gaXQg
aXMgc2NoZWR1bGVkIG9uIHRoZSBwaHlzaWNhbCBDUFUuIEFuZCwgYSB2Q1BVIHdpdGggdGhlIEJP
T1NUCj4+IHByaW9yaXR5IHdpbGwgcHJlZW1wdCB0aGUgcnVubmluZyBvbmUgYW5kIHJ1biBhZGRp
dGlvbmFsIDEwbXMuIFNvLCB3aGF0IEkKPj4gdGhpbmsgaXMgaWYgd2UgbW9uaXRvciB0aGUgcGh5
c2ljYWwgQ1BVIGV2ZXJ5IDEwbXMgYW5kIHdlIGNhbiBnZXQgdGhlCj4+IG1hcHBpbmcgaW5mb3Jt
YXRpb24gb2YgYSBwaHlzaWNhbCBDUFUgYW5kIGEgdkNQVS4gQW5kIGFsc28sIHdlIGNhbiBnZXQg
dGhlCj4+IHVuLW1hcHBpbmcgaW5mb3JtYXRpb24gdGhhdCBhIHBoeXNpY2FsIENQVSBpc26hr3Qg
bWFwcGVkIHRvIGFueSB2Q1BVLiBUaHVzLAo+PiB3ZSBjYW4gZ2V0IHRoZSBDUFUgdXNhZ2UgYnkg
Y2FsY3VsYXRpbmcgdGhlIHByb3BvcnRpb24gb2YgdGhlIG1hcHBpbmcKPj4gaW5mb3JtYXRpb24g
dG8gdGhlIHRvdGFsIHRpbWUgd2hlbiB3ZSBtb25pdG9yZWQuCj4+Cj4+IEZvciBleGFtcGxlLCBp
ZiB3ZSBtb25pdG9yIHRoZSBwaHlzaWNhbCBDUFVzIGV2ZXJ5IDEwbXMgYW5kIHdlIGNhbiBnZXQg
MTAwCj4+IHBhaXJzIG9mIHBDUFUgYW5kIHZDUFUgaW4gYSBzZWNvbmQsIHN1Y2ggYXMgKHBDUFVf
aWQsIHZDUFVfaWQpLiBJZiB0aGVyZSBpcwo+PiA2MCBtYXBwaW5nIHBhaXJzIHRoYXQgdGhlIHBD
UFUgaXMgbWFwcGVkIHRvIGEgdmFsaWQgdlBDVSwgYW5kIDQwIHVuLW1hcHBpbmcKPj4gcGFpcnMg
dGhhdCB3ZSBjYW5ub3QgZmluZCB0aGUgcENQVSB0byBiZSBtYXBwZWQgYSB2YWxpZCB2Q1BVLiBT
bywgd2UgY2FuIGdldAo+PiB0aGUgdXNhZ2Ugb2YgdGhlIHBoeXNpY2FsIENQVXMgdGhhdCBpcyA2
MCUuCj4+Cj4+IEhlcmUsIHdlIG1vbml0b3IgdGhlIHBoeXNpY2FsIENQVXMgZXZlcnkgMTBtcy4g
V2UgYWxzbyBjYW4gbW9uaXRvciB0aGVtIG9uY2UKPj4gbGVzcyB0aGFuIHRoZSAxMG1zIGludGVy
dmFsLCBzdWNoIGFzIDFtcyBpbnRlcnZhbC4gV2hhdGV2ZXIgaW50ZXJ2YWwgd2UKPj4gY2hvb3Nl
LCB3ZSBtdXN0IG1ha2Ugc3VyZSBubyBDUFUgY29udGVudCBzd2l0Y2ggaW4gdGhlIGludGVydmFs
IG9yIHRoZQo+PiBjb250ZXh0IHN3aXRjaCBhbHdheXMgb2NjdXIgYXQgdGhlIGVkZ2Ugb2YgaW50
ZXJ2YWwuIE9ubHkgaW4gdGhpcyBjb25kaXRpb24sCj4+IGNhbiB0aGlzIGlkZWEgd29yay4KPj4K
Pj4gU28sIEkgYW0gbm90IHN1cmUgd2hldGhlciB3ZSBjYW4gZmluZCBzdWNoIGEgdGltZSBpbnRl
cnZhbCB0aGF0IGNhbiBtZWV0Cj4+IHRoaXMgY29uZGl0aW9uLiBJbiBvdGhlciB3b3Jkcywgd2hl
dGhlciB3ZSBjYW4gZmluZCBzdWNoIGEgdGltZSBpbnRlcnZhbAo+PiB0aGF0IGVuc3VyZXMgYWxs
IHRoZSBDUFUgY29udGVudCBzd2l0Y2ggb2NjdXIgYXQgdGhlIGVkZ2Ugb2YgaW50ZXJ2YWwuCj4K
PllvdSBzdGlsbCBoYXZlbid0IGRlc2NyaWJlZCBleGFjdGx5IHdoYXQgaXQgaXMgeW91J3JlIHRy
eWluZyB0bwo+YWNjb21wbGlzaDogd2hhdCBpcyB5b3VyIGVuZCBnb2FsPyAgSXQgc2VlbXMgdG8g
YmUgcmVsYXRlZCBzb21laG93IHRvCj5tZWFzdXJpbmcgaG93IGJ1c3kgdGhlIHN5c3RlbSBpcyAo
aS5lLiwgdGhlIG51bWJlciBvZiBhY3RpdmUgcGNwdXMgYW5kCj5pZGxlIHBjcHVzKTsgYnV0IGFz
IEkgZG9uJ3Qga25vdyB3aGF0IHlvdSB3YW50IHRvIGRvIHdpdGggdGhhdAo+aW5mb3JtYXRpb24s
IEkgY2FuJ3QgdGVsbCB5b3UgdGhlIGJlc3Qgd2F5IHRvIGdldCBpdC4KPgo+UmVnYXJkaW5nIGEg
bWFwIG9mIHBjcHVzIHRvIHZjcHVzLCB0aGF0IGFscmVhZHkgZXhpc3RzLiAgVGhlCj5zY2hlZHVs
aW5nIGNvZGUgd2lsbCBrZWVwIHRyYWNrIG9mIHRoZSBjdXJyZW50bHkgcnVubmluZyB2Y3B1IGhl
cmU6Cj4gIHBlcl9jcHUoc2NoZWR1bGVfZGF0YSwgcGNwdV9pZCkuY3Vycgo+Cj5Zb3UgY2FuIHNl
ZSBleGFtcGxlcyBvZiB0aGUgYWJvdmUgc3RydWN0dXJlIHVzZWQgaW4KPnhlbi9jb21tb24vc2No
ZWRfY3JlZGl0Mi5jLiAgSWYgImlzX2lkbGUocGVyX2NwdShzY2hlZHVsZV9kYXRhLAo+cGNwdSku
Y3VycikiIGlzIGZhbHNlLCB0aGVuIHRoZSBjcHUgaXMgcnVubmluZyBhIHZjcHU7IGlmIGl0IGlz
IHRydWUsCj50aGVuIHRoZSBwY3B1IGlzIGlkbGUgKGFsdGhvdWdoIGl0IG1heSBiZSBydW5uaW5n
IGEgdGFza2xldCkuCj4KPkFkZGl0aW9uYWxseSwgaWYgYWxsIHlvdSB3YW50IGlzIHRoZSBudW1i
ZXIgb2Ygbm9uLWlkbGUgY3B1cywgdGhlCj5jcmVkaXQxIHNjaGVkdWxlciBrZWVwcyB0cmFjayBv
ZiB0aGUgaWRsZSBhbmQgbm9uLWlkbGUgY3B1cyBpbgo+cHJ2LT5pZGxlcnMuICBZb3UgY291bGQg
ZWFzaWx5IHVzZSAiY3B1bWFza193ZWlnaHQoJnBydi0+aWRsZXJzKSIgdG8KPmZpbmQgb3V0IGhv
dyBtYW55IGlkbGUgY3B1cyB0aGVyZSBhcmUgYXQgYW55IGdpdmVuIHRpbWUuICBJZiB5b3Uga25v
dwo+aG93IG1hbnkgb25saW5lIGNwdXMgdGhlcmUgYXJlLCB0aGF0IHdpbGwgZ2l2ZSB5b3UgdGhl
IGJ1c3ktbmVzcyBvZgo+dGhlIHN5c3RlbS4KPgo+U28gbm93IHRoYXQgeW91IGhhdmUgdGhpcyBp
bnN0YW50YW5lb3VzIHBlcmNlbnRhZ2UsIHdoYXQgZG8geW91IHdhbnQKPnRvIGRvIHdpdGggaXQ/
Cj4KPiAtR2VvcmdlCj4KPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fCj5YZW4tZGV2ZWwgbWFpbGluZyBsaXN0Cj5YZW4tZGV2ZWxAbGlzdHMueGVuc291cmNl
LmNvbQo+aHR0cDovL2xpc3RzLnhlbnNvdXJjZS5jb20veGVuLWRldmVsCg==
------=_Part_343557_1060246463.1324366204521
Content-Type: text/html; charset=GBK
Content-Transfer-Encoding: base64

PGRpdiBzdHlsZT0ibGluZS1oZWlnaHQ6MS43O2NvbG9yOiMwMDAwMDA7Zm9udC1zaXplOjE0cHg7
Zm9udC1mYW1pbHk6YXJpYWwiPjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT
Ij4xKSBNeSBvcmlnaW5hbCBnb2FsIGlzIHRvIGNhbGN1bGF0ZSB0aGUgdXNhZ2UKcGVyY2VudGFn
ZSBvZiBDUFUgaW4gYSBkaWZmZXJlbnQgd2F5IGZyb20gb3RoZXIgdG9vbHMsIHN1Y2ggYXMgeGVu
dHJhY2UuIDwvc3Bhbj48L3A+Cgo8cCBjbGFzcz0iTXNvTm9ybWFsIj5CZWNhdXNlIHRoZSBhaW0g
b2YgYWxsIHRoZSBzY2hlZHVsaW5nIGlzIHRvCm1hcCB0aGUgdkNQVSB0byBwQ1BVLCB3ZSBjYW4g
Z2V0IGEgbWFwcGluZyBzZXF1ZW5jZSBvZiBwQ1BVIGFuZCB2Q1BVIGJ5IG1vbml0b3JpbmcKdGhl
IHBDUFUgaW4gYSBmaXhlZCBpbnRlcnZhbC4mbmJzcDs8L3A+Cgo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBsYW5nPSJFTi1VUyI+Rm9yIGV4YW1wbGUsIGlmIHRoZSA8YSBuYW1lPSJPTEVfTElO
SzMiPjwvYT48YSBuYW1lPSJPTEVfTElOSzIiPlNDSEVEVUxFX1NPRlRJUlE8L2E+CmlzIGp1c3Qg
cmFpc2VkIHdoZW4gdGhlIHRpbWVzbGljZSBpcyBmaW5pc2hlZCwgdGhlIHZDUFUgcnVucyBhcyBk
ZXNjcmliZWQgaW4KdGhlIGZpZ3VyZSAxICh0d28gcENQVSBhbmQgdGhyZWUgdkNQVSkuIFdlIDwv
c3Bhbj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOnJlZCI+bW9uaXRvciBhbGwg
dGhlIENQVXMgb25jZSBldmVyeSB0aW1lIHQ8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIj4s
IHdoaWNoIGlzIGVxdWFsIHRvIHRoZSB0aW1lIG9mIHRoZSB0aW1lc2xpY2UgaGVyZS4gSW4gdGVu
IHRpbWVzbGljZQoobWF5YmUgMC4zIHNlY29uZCBpbiBjcmVkaXQxKSwgd2UgY2FuIGdldCB0aGUg
bWFwcGluZyBzZXF1ZW5jZSwgd2hpY2ggY29udGFpbnMgMjAKKHBDUFUsIHZDUFUpIHBhaXJzIGFz
IHRoZSBmb2xsb3dpbmcuPC9zcGFuPjwvcD4KCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh
bmc9IkVOLVVTIj4ocENQVTEsIHZDUFUxKSwgKHBDUFUyLCB2Q1BVMiksIChwQ1BVMSwKdkNQVTEp
LCA8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpyZWQiPihwQ1BVMiwgbm9u
KTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+LCAocENQVTEsIHZDUFUxKSwgKHBDUFUyLCB2Q1BV
MyksIChwQ1BVMSwgdkNQVTIpLCA8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xv
cjpyZWQiPihwQ1BVMiwgbm9uKTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+LCA8L3NwYW4+PHNw
YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpyZWQiPihwQ1BVMSwgbm9uKTwvc3Bhbj48c3Bh
biBsYW5nPSJFTi1VUyI+LCAocENQVTIsIHZDUFUyKSwKKHBDUFUxLCB2Q1BVMyksIDwvc3Bhbj48
c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOnJlZCI+KHBDUFUyLCBub24pPC9zcGFuPjxz
cGFuIGxhbmc9IkVOLVVTIj4sIChwQ1BVMSwgdkNQVTMpLCAocENQVTIsIHZDUFUxKSwgPC9zcGFu
PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6cmVkIj4ocENQVTEsIG5vbik8L3NwYW4+
PHNwYW4gbGFuZz0iRU4tVVMiPiwgKHBDUFUyLCB2Q1BVMSksIChwQ1BVMSwKdkNQVTEpLCA8L3Nw
YW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpyZWQiPihwQ1BVMiwgbm9uKTwvc3Bh
bj48c3BhbiBsYW5nPSJFTi1VUyI+LCA8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJj
b2xvcjpyZWQiPihwQ1BVMSwgbm9uKTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+LCAocENQVTIs
IHZDUFUyKTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6y87M5Tttc28tYXNjaWktZm9u
dC1mYW1pbHk6CiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Ozttc28taGFuc2ktZm9udC1mYW1p
bHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij6hozwvc3Bhbj48L3A+Cgo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+SWYgdGhlcmUgaXMgbm8gdkNQVSBtYXBwZWQg
b24gdGhlIHBDUFUsIHdlCnVzZSAocENQVSosIG5vbikgcGFpciwgd2hpY2ggbWVhbnMgdGhlIHBD
UFUgaXMgaWRsZS4gSW4gdGhlIGFib3ZlIHNlcXVlbmNlLAp0aGVyZSBhcmUgNyBpZGxlIHBhaXJz
IGluIHRvdGFsLjwvc3Bhbj4mbmJzcDs8L3A+Cgo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs
YW5nPSJFTi1VUyI+U28sIGZyb20gdGhlIGFib3ZlIG1hcHBpbmcgc2VxdWVuY2UsIHdlIGNhbgpj
YWxjdWxhdGUgdGhlIHVzYWdlIHBlcmNlbnRhZ2Ugb2YgdGhlIENQVSBpbiB0ZW4gdGltZXNsY2ll
ICgwLjMgc2VuY29uZCkuPC9zcGFuPjwvcD4KCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh
bmc9IkVOLVVTIj5Vc2FnZSBQZXJjZW50YWdlID0gKDIwLTcpLzIwID0gNjUlPC9zcGFuPiZuYnNw
OzwvcD4KCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4yKSBJZiB3ZSBj
YW4gZ2V0IHN1Y2ggYSBtYXBwaW5nIHNlcXVlbmNlIG9mCnBDUFUgYW5kIHZDUFUsIGJlc2lkZXMg
Y2FsY3VsYXRpbmcgdGhlIHVzYWdlIHBlcmNlbnRhZ2Ugb2YgQ1BVLCBtYXliZSB3ZSBhbHNvCmNh
biBmaW5kIHNvbWU8L3NwYW4+IDxzcGFuIGlkPSJ0cmFuXzFfNSI+bGF3czwvc3Bhbj4Kb2YgdGhl
IG1hcHBpbmcgc2VxdWVuY2UgYW5kIHVzZSB0aGUgbGF3cyB0byBpbmZlciB0aGUgQ1BVLWJvdW5k
IHRhc2sgYW5kIEkvTy1ib3VuZAp0YXNrLiZuYnNwOzwvcD4KCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIGxhbmc9IkVOLVVTIj5Ib3dldmVyLCB0aGlzIGlkZWEgbWF5IG5vdCB3b3JrLiBCZWNh
dXNlIHRoZQpTQ0hFRFVMRV9TT0ZUSVJRIGlzIG5vdCBvbmx5IHJhaXNlZCB3aGVuIHRoZSB0aW1l
c2xpY2UgaXMgZmluaXNoZWQsIGJ1dCBhbHNvIHJhaXNlZAppbiBtYW55IG90aGVyIHNpdHVhdGlv
bnMsIHdlIGNhbm5vdCBnZXQgYSByZWd1bGFyIG1hcHBpbmcgb2YgdkNQVSBhbmQgcENQVSBqdXN0
Cmxpa2UgZmlndXJlIDEuJm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj5UaGUgbWFwcGlu
ZyBpcyBpcnJlZ3VsYXIgcG9zc2libHkgc2hvd24gaW4KZmlndXJlIDIuIDxhIG5hbWU9Ik9MRV9M
SU5LNSI+PC9hPjxhIG5hbWU9Ik9MRV9MSU5LNCI+SW4gdGhlIGZpZ3VyZSAyLCB3ZSBjYW5ub3Qg
ZmluZCBhIHZlcnkgcHJvcGVyIDwvYT48L3NwYW4+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl
PSJjb2xvcjpyZWQiPnRpbWUgdDwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiPiB0byBtb25p
dG9yIHRoZSBDUFVzLjwvc3Bhbj48L3A+PGJyPjxkaXY+LS08YnI+QmVzdCBSZWdhcmRzLDxkaXY+
R2F2aW48L2Rpdj48L2Rpdj48ZGl2IGlkPSJkaXZOZXRlYXNlTWFpbENhcmQiPjwvZGl2Pjxicj48
cHJlPjxicj5BdCZuYnNwOzIwMTEtMTItMTkmbmJzcDsxODozNzoxNCwiR2VvcmdlJm5ic3A7RHVu
bGFwIiZuYnNwOyZsdDtHZW9yZ2UuRHVubGFwQGV1LmNpdHJpeC5jb20mZ3Q7Jm5ic3A7d3JvdGU6
CiZndDsyMDExLzEyLzE3Jm5ic3A7Z2F2aW4mbmJzcDsmbHQ7Z2J0dXhAMTI2LmNvbSZndDs6CiZn
dDsmZ3Q7CiZndDsmZ3Q7Jm5ic3A7QXQmbmJzcDsyMDExLTEyLTE2Jm5ic3A7MjM6NTg6MjYsIkdl
b3JnZSZuYnNwO0R1bmxhcCImbmJzcDsmbHQ7R2VvcmdlLkR1bmxhcEBldS5jaXRyaXguY29tJmd0
OyZuYnNwO3dyb3RlOgomZ3Q7Jmd0OyZndDsyMDExLzEyLzE2Jm5ic3A7Z2F2aW4mbmJzcDsmbHQ7
Z2J0dXhAMTI2LmNvbSZndDs6CiZndDsmZ3Q7Jmd0OyZndDsmbmJzcDtBdCZuYnNwOzIwMTEtMTIt
MTYmbmJzcDsxOTowNDoxOSwiR2VvcmdlJm5ic3A7RHVubGFwIiZuYnNwOyZsdDtHZW9yZ2UuRHVu
bGFwQGV1LmNpdHJpeC5jb20mZ3Q7Jm5ic3A7d3JvdGU6CiZndDsmZ3Q7Jmd0OyZndDsKJmd0OyZn
dDsmZ3Q7Jmd0OyZndDsyMDExLzEyLzE2Jm5ic3A7emhpa2FpJm5ic3A7Jmx0O2didHV4QDEyNi5j
b20mZ3Q7OgomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDtIaSZuYnNwO0FsbCwKJmd0OyZn
dDsmZ3Q7Jmd0OyZndDsmZ3Q7CiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwO0luJm5ic3A7
dGhlJm5ic3A7Y3JlZGl0Jm5ic3A7c2NoZWR1bGVyLCZuYnNwO3RoZSZuYnNwO3NjaGVkdWxpbmcm
bmJzcDtkZWNpc2lvbiZuYnNwO2Z1bmN0aW9uJm5ic3A7Y3NjaGVkX3NjaGVkdWxlKCkKJmd0OyZn
dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7aXMmbmJzcDtjYWxsZWQmbmJzcDtpbiZuYnNwO3RoZSZu
YnNwO3NjaGVkdWxlJm5ic3A7ZnVuY3Rpb24mbmJzcDtpbiZuYnNwO3NjaGVkdWxlci5jLCZuYnNw
O3N1Y2gmbmJzcDthcyZuYnNwO3RoZSZuYnNwO2ZvbGxvd2luZy4KJmd0OyZndDsmZ3Q7Jmd0OyZn
dDsmZ3Q7Jm5ic3A7bmV4dF9zbGljZSZuYnNwOz0mbmJzcDtzY2hlZC0mZ3Q7ZG9fc2NoZWR1bGUo
c2NoZWQsJm5ic3A7bm93LCZuYnNwO3Rhc2tsZXRfd29ya19zY2hlZHVsZWQpOwomZ3Q7Jmd0OyZn
dDsmZ3Q7Jmd0OyZndDsKJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7QnV0LCZuYnNwO2hv
dyZuYnNwO29mdGVuJm5ic3A7dGhlJm5ic3A7Y3NjaGVkX3NjaGVkdWxlKCkmbmJzcDtpcyZuYnNw
O2NhbGxlZCZuYnNwO2FuZCZuYnNwO3RvJm5ic3A7cnVuPyZuYnNwO0RvZXMmbmJzcDt0aGlzCiZn
dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwO2ZyZXF1ZW5jeSZuYnNwO2hhdmUmbmJzcDtzb21l
dGhpbmcmbmJzcDt0byZuYnNwO2RvJm5ic3A7d2l0aCZuYnNwO3RoZSZuYnNwO3NsaWNlJm5ic3A7
b2YmbmJzcDtjcmVkaXQmbmJzcDtzY2hlZHVsZXImbmJzcDt0aGF0Jm5ic3A7aXMKJmd0OyZndDsm
Z3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7MzBtcz8KJmd0OyZndDsmZ3Q7Jmd0OyZndDsKJmd0OyZndDsm
Z3Q7Jmd0OyZndDtUaGUmbmJzcDtzY2hlZHVsZXImbmJzcDtydW5zJm5ic3A7d2hlbmV2ZXImbmJz
cDt0aGUmbmJzcDtTQ0hFRFVMRV9TT0ZUSVJRJm5ic3A7aXMmbmJzcDtyYWlzZWQuJm5ic3A7Jm5i
c3A7SWYmbmJzcDt5b3UKJmd0OyZndDsmZ3Q7Jmd0OyZndDtncmVwJm5ic3A7dGhyb3VnaCZuYnNw
O3RoZSZuYnNwO3NvdXJjZSZuYnNwO2NvZGUmbmJzcDtmcm8mbmJzcDt0aGF0Jm5ic3A7c3RyaW5n
LCZuYnNwO3lvdSZuYnNwO2NhbiZuYnNwO2ZpbmQmbmJzcDthbGwmbmJzcDt0aGUKJmd0OyZndDsm
Z3Q7Jmd0OyZndDtwbGFjZXMmbmJzcDt3aGVyZSZuYnNwO2l0J3MmbmJzcDtyYWlzZWQuCiZndDsm
Z3Q7Jmd0OyZndDsmZ3Q7CiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7U29tZSZuYnNwO2V4YW1wbGVzJm5i
c3A7aW5jbHVkZToKJmd0OyZndDsmZ3Q7Jmd0OyZndDsqJm5ic3A7V2hlbiZuYnNwO3RoZSZuYnNw
OzMwbXMmbmJzcDt0aW1lc2xpY2UmbmJzcDtpcyZuYnNwO2ZpbmlzaGVkCiZndDsmZ3Q7Jmd0OyZn
dDsmZ3Q7KiZuYnNwO1doZW4mbmJzcDthJm5ic3A7c2xlZXBpbmcmbmJzcDt2Y3B1Jm5ic3A7b2Ym
bmJzcDtoaWdoZXImbmJzcDtwcmlvcml0eSZuYnNwO3RoYW4mbmJzcDt3aGF0J3MmbmJzcDtjdXJy
ZW50bHkmbmJzcDtydW5uaW5nJm5ic3A7d2FrZXMmbmJzcDt1cAomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0
OyombmJzcDtXaGVuJm5ic3A7YSZuYnNwO3ZjcHUmbmJzcDtibG9ja3MKJmd0OyZndDsmZ3Q7Jmd0
OyZndDsqJm5ic3A7V2hlbiZuYnNwO2EmbmJzcDt2Y3B1Jm5ic3A7aXMmbmJzcDttaWdyYXRlZCZu
YnNwO2Zyb20mbmJzcDtvbmUmbmJzcDtjcHUmbmJzcDt0byZuYnNwO2Fub3RoZXIKJmd0OyZndDsm
Z3Q7Jmd0OyZndDsKJmd0OyZndDsmZ3Q7Jmd0OyZndDszMG1zJm5ic3A7aXMmbmJzcDthY3R1YWxs
eSZuYnNwO2EmbmJzcDtwcmV0dHkmbmJzcDtsb25nJm5ic3A7dGltZTsmbmJzcDtpbiZuYnNwO3R5
cGljYWwmbmJzcDt3b3JrbG9hZHMsJm5ic3A7dmNwdXMmbmJzcDtibG9jawomZ3Q7Jmd0OyZndDsm
Z3Q7Jmd0O29yJm5ic3A7YXJlJm5ic3A7cHJlZW1wdGVkJm5ic3A7YnkmbmJzcDtvdGhlciZuYnNw
O3dha2luZyZuYnNwO3ZjcHVzJm5ic3A7d2l0aG91dCZuYnNwO3VzaW5nJm5ic3A7dXAmbmJzcDt0
aGVpciZuYnNwO2Z1bGwKJmd0OyZndDsmZ3Q7Jmd0OyZndDt0aW1lc2xpY2UuCiZndDsmZ3Q7Jmd0
OyZndDsKJmd0OyZndDsmZ3Q7Jmd0OyZuYnNwO1RoYW5rJm5ic3A7eW91Jm5ic3A7dmVyeSZuYnNw
O211Y2gmbmJzcDtmb3ImbmJzcDt5b3VyJm5ic3A7cmVwbHkuCiZndDsmZ3Q7Jmd0OyZndDsKJmd0
OyZndDsmZ3Q7Jmd0OyZuYnNwO1NvLCZuYnNwO3RoZSZuYnNwO3ZjcHUmbmJzcDtpcyZuYnNwO3Zl
cnkmbmJzcDtsaWtlbHkmbmJzcDt0byZuYnNwO2JlJm5ic3A7cHJlZW1wdGVkJm5ic3A7d2hlbmV2
ZXImbmJzcDt0aGUmbmJzcDtTQ0hFRFVMRV9TT0ZUSVJRJm5ic3A7aXMKJmd0OyZndDsmZ3Q7Jmd0
OyZuYnNwO3JhaXNlZC4KJmd0OyZndDsmZ3Q7CiZndDsmZ3Q7Jmd0O0l0Jm5ic3A7ZGVwZW5kczsm
bmJzcDtpZiZuYnNwO3lvdSZuYnNwO2hhdmUmbmJzcDthJm5ic3A7Y3B1LWJ1cm5pbmcmbmJzcDt2
Y3B1Jm5ic3A7cnVubmluZyZuYnNwO29uJm5ic3A7YSZuYnNwO2NwdSZuYnNwO2FsbCZuYnNwO2J5
CiZndDsmZ3Q7Jmd0O2l0c2VsZiwmbmJzcDt0aGVuJm5ic3A7YWZ0ZXImbmJzcDtpdHMmbmJzcDsz
MG1zJm5ic3A7dGltZXNsaWNlLCZuYnNwO1hlbiZuYnNwO3dpbGwmbmJzcDtoYXZlJm5ic3A7bm8m
bmJzcDtvbmUmbmJzcDtlbHNlJm5ic3A7dG8KJmd0OyZndDsmZ3Q7cnVuLCZuYnNwO2FuZCZuYnNw
O3NvJm5ic3A7d2lsbCZuYnNwO2xldCZuYnNwO2l0Jm5ic3A7cnVuJm5ic3A7YWdhaW4uCiZndDsm
Z3Q7Jmd0OwomZ3Q7Jmd0OyZndDtCdXQmbmJzcDt5ZXMsJm5ic3A7aWYmbmJzcDt0aGVyZSZuYnNw
O2FyZSZuYnNwO290aGVyJm5ic3A7dmNwdXMmbmJzcDtvbiZuYnNwO3RoZSZuYnNwO3J1bnF1ZXVl
LCZuYnNwO29yJm5ic3A7dGhlJm5ic3A7aG9zdCZuYnNwO2lzCiZndDsmZ3Q7Jmd0O21vZGVyYXRl
bHkmbmJzcDtidXN5LCZuYnNwO2l0J3MmbmJzcDtsaWtlbHkmbmJzcDt0aGF0Jm5ic3A7U0NIRURV
TEVfU09GVElSUSZuYnNwO3dpbGwmbmJzcDtjYXVzZSZuYnNwO2EKJmd0OyZndDsmZ3Q7Y29udGV4
dC1zd2l0Y2guCiZndDsmZ3Q7Jmd0OwomZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7QW5kJm5ic3A7d2Um
bmJzcDtjYW5ub3QmbmJzcDtmaW5kJm5ic3A7YSZuYnNwO3NtYWxsJm5ic3A7dGltZXNsaWNlLCZu
YnNwO3N1Y2gmbmJzcDthcyZuYnNwO2EobXMpLCZuYnNwO3doaWNoJm5ic3A7bWFrZXMmbmJzcDt0
aGUKJmd0OyZndDsmZ3Q7Jmd0OyZuYnNwO3RpbWUmbmJzcDthbnkmbmJzcDt2Y3B1Jm5ic3A7c3Bl
bmRpbmcmbmJzcDtvbiZuYnNwO3J1bm5pbmcmbmJzcDtwaGFzZSZuYnNwO2lzJm5ic3A7ayphKG1z
KSwmbmJzcDtrJm5ic3A7aXMmbmJzcDtpbnRlZ2VyJm5ic3A7aGVyZS4mbmJzcDtUaGVyZQomZ3Q7
Jmd0OyZndDsmZ3Q7Jm5ic3A7aXMmbmJzcDtubyZuYnNwO3N1Y2gmbmJzcDthJm5ic3A7c21hbGwm
bmJzcDt0aW1lc2xpY2UuJm5ic3A7SXMmbmJzcDtpdCZuYnNwO3JpZ2h0PwomZ3Q7Jmd0OyZndDsK
Jmd0OyZndDsmZ3Q7SSdtJm5ic3A7c29ycnksJm5ic3A7SSZuYnNwO2Rvbid0Jm5ic3A7cmVhbGx5
Jm5ic3A7dW5kZXJzdGFuZCZuYnNwO3lvdXImbmJzcDtxdWVzdGlvbi4mbmJzcDsmbmJzcDtQZXJo
YXBzJm5ic3A7aWYmbmJzcDt5b3UKJmd0OyZndDsmZ3Q7dG9sZCZuYnNwO21lJm5ic3A7d2hhdCZu
YnNwO3lvdSdyZSZuYnNwO3RyeWluZyZuYnNwO3RvJm5ic3A7YWNjb21wbGlzaD8KJmd0OyZndDsK
Jmd0OyZndDsmbmJzcDtJJm5ic3A7dHJ5Jm5ic3A7dG8mbmJzcDtkZXNjcmliZSZuYnNwO215Jm5i
c3A7aWRlYSZuYnNwO2FzJm5ic3A7dGhlJm5ic3A7Zm9sbG93aW5nJm5ic3A7Y2xlYXJseS4mbmJz
cDtCdXQmbmJzcDtJJm5ic3A7cmVhbGx5Jm5ic3A7ZG9uJ3QmbmJzcDtrbm93CiZndDsmZ3Q7Jm5i
c3A7aWYmbmJzcDtpdCZuYnNwO3dpbGwmbmJzcDt3b3JrLiZuYnNwO1BsZWFzZSZuYnNwO2dpdmUm
bmJzcDttZSZuYnNwO3NvbWUmbmJzcDthZHZpY2UmbmJzcDtpZiZuYnNwO3Bvc3NpYmxlLgomZ3Q7
Jmd0OwomZ3Q7Jmd0OyZuYnNwO0FjY29yZGluZyZuYnNwO3RvJm5ic3A7dGhlJm5ic3A7Y3JlZGl0
Jm5ic3A7c2NoZWR1bGVyJm5ic3A7aW4mbmJzcDtYZW4sJm5ic3A7YSZuYnNwO3ZDUFUmbmJzcDtj
YW4mbmJzcDtydW4mbmJzcDthJm5ic3A7MzBtcyZuYnNwO3RpbWVzbGljZQomZ3Q7Jmd0OyZuYnNw
O3doZW4mbmJzcDtpdCZuYnNwO2lzJm5ic3A7c2NoZWR1bGVkJm5ic3A7b24mbmJzcDt0aGUmbmJz
cDtwaHlzaWNhbCZuYnNwO0NQVS4mbmJzcDtBbmQsJm5ic3A7YSZuYnNwO3ZDUFUmbmJzcDt3aXRo
Jm5ic3A7dGhlJm5ic3A7Qk9PU1QKJmd0OyZndDsmbmJzcDtwcmlvcml0eSZuYnNwO3dpbGwmbmJz
cDtwcmVlbXB0Jm5ic3A7dGhlJm5ic3A7cnVubmluZyZuYnNwO29uZSZuYnNwO2FuZCZuYnNwO3J1
biZuYnNwO2FkZGl0aW9uYWwmbmJzcDsxMG1zLiZuYnNwO1NvLCZuYnNwO3doYXQmbmJzcDtJCiZn
dDsmZ3Q7Jm5ic3A7dGhpbmsmbmJzcDtpcyZuYnNwO2lmJm5ic3A7d2UmbmJzcDttb25pdG9yJm5i
c3A7dGhlJm5ic3A7cGh5c2ljYWwmbmJzcDtDUFUmbmJzcDtldmVyeSZuYnNwOzEwbXMmbmJzcDth
bmQmbmJzcDt3ZSZuYnNwO2NhbiZuYnNwO2dldCZuYnNwO3RoZQomZ3Q7Jmd0OyZuYnNwO21hcHBp
bmcmbmJzcDtpbmZvcm1hdGlvbiZuYnNwO29mJm5ic3A7YSZuYnNwO3BoeXNpY2FsJm5ic3A7Q1BV
Jm5ic3A7YW5kJm5ic3A7YSZuYnNwO3ZDUFUuJm5ic3A7QW5kJm5ic3A7YWxzbywmbmJzcDt3ZSZu
YnNwO2NhbiZuYnNwO2dldCZuYnNwO3RoZQomZ3Q7Jmd0OyZuYnNwO3VuLW1hcHBpbmcmbmJzcDtp
bmZvcm1hdGlvbiZuYnNwO3RoYXQmbmJzcDthJm5ic3A7cGh5c2ljYWwmbmJzcDtDUFUmbmJzcDtp
c26hr3QmbmJzcDttYXBwZWQmbmJzcDt0byZuYnNwO2FueSZuYnNwO3ZDUFUuJm5ic3A7VGh1cywK
Jmd0OyZndDsmbmJzcDt3ZSZuYnNwO2NhbiZuYnNwO2dldCZuYnNwO3RoZSZuYnNwO0NQVSZuYnNw
O3VzYWdlJm5ic3A7YnkmbmJzcDtjYWxjdWxhdGluZyZuYnNwO3RoZSZuYnNwO3Byb3BvcnRpb24m
bmJzcDtvZiZuYnNwO3RoZSZuYnNwO21hcHBpbmcKJmd0OyZndDsmbmJzcDtpbmZvcm1hdGlvbiZu
YnNwO3RvJm5ic3A7dGhlJm5ic3A7dG90YWwmbmJzcDt0aW1lJm5ic3A7d2hlbiZuYnNwO3dlJm5i
c3A7bW9uaXRvcmVkLgomZ3Q7Jmd0OwomZ3Q7Jmd0OyZuYnNwO0ZvciZuYnNwO2V4YW1wbGUsJm5i
c3A7aWYmbmJzcDt3ZSZuYnNwO21vbml0b3ImbmJzcDt0aGUmbmJzcDtwaHlzaWNhbCZuYnNwO0NQ
VXMmbmJzcDtldmVyeSZuYnNwOzEwbXMmbmJzcDthbmQmbmJzcDt3ZSZuYnNwO2NhbiZuYnNwO2dl
dCZuYnNwOzEwMAomZ3Q7Jmd0OyZuYnNwO3BhaXJzJm5ic3A7b2YmbmJzcDtwQ1BVJm5ic3A7YW5k
Jm5ic3A7dkNQVSZuYnNwO2luJm5ic3A7YSZuYnNwO3NlY29uZCwmbmJzcDtzdWNoJm5ic3A7YXMm
bmJzcDsocENQVV9pZCwmbmJzcDt2Q1BVX2lkKS4mbmJzcDtJZiZuYnNwO3RoZXJlJm5ic3A7aXMK
Jmd0OyZndDsmbmJzcDs2MCZuYnNwO21hcHBpbmcmbmJzcDtwYWlycyZuYnNwO3RoYXQmbmJzcDt0
aGUmbmJzcDtwQ1BVJm5ic3A7aXMmbmJzcDttYXBwZWQmbmJzcDt0byZuYnNwO2EmbmJzcDt2YWxp
ZCZuYnNwO3ZQQ1UsJm5ic3A7YW5kJm5ic3A7NDAmbmJzcDt1bi1tYXBwaW5nCiZndDsmZ3Q7Jm5i
c3A7cGFpcnMmbmJzcDt0aGF0Jm5ic3A7d2UmbmJzcDtjYW5ub3QmbmJzcDtmaW5kJm5ic3A7dGhl
Jm5ic3A7cENQVSZuYnNwO3RvJm5ic3A7YmUmbmJzcDttYXBwZWQmbmJzcDthJm5ic3A7dmFsaWQm
bmJzcDt2Q1BVLiZuYnNwO1NvLCZuYnNwO3dlJm5ic3A7Y2FuJm5ic3A7Z2V0CiZndDsmZ3Q7Jm5i
c3A7dGhlJm5ic3A7dXNhZ2UmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO3BoeXNpY2FsJm5ic3A7Q1BV
cyZuYnNwO3RoYXQmbmJzcDtpcyZuYnNwOzYwJS4KJmd0OyZndDsKJmd0OyZndDsmbmJzcDtIZXJl
LCZuYnNwO3dlJm5ic3A7bW9uaXRvciZuYnNwO3RoZSZuYnNwO3BoeXNpY2FsJm5ic3A7Q1BVcyZu
YnNwO2V2ZXJ5Jm5ic3A7MTBtcy4mbmJzcDtXZSZuYnNwO2Fsc28mbmJzcDtjYW4mbmJzcDttb25p
dG9yJm5ic3A7dGhlbSZuYnNwO29uY2UKJmd0OyZndDsmbmJzcDtsZXNzJm5ic3A7dGhhbiZuYnNw
O3RoZSZuYnNwOzEwbXMmbmJzcDtpbnRlcnZhbCwmbmJzcDtzdWNoJm5ic3A7YXMmbmJzcDsxbXMm
bmJzcDtpbnRlcnZhbC4mbmJzcDtXaGF0ZXZlciZuYnNwO2ludGVydmFsJm5ic3A7d2UKJmd0OyZn
dDsmbmJzcDtjaG9vc2UsJm5ic3A7d2UmbmJzcDttdXN0Jm5ic3A7bWFrZSZuYnNwO3N1cmUmbmJz
cDtubyZuYnNwO0NQVSZuYnNwO2NvbnRlbnQmbmJzcDtzd2l0Y2gmbmJzcDtpbiZuYnNwO3RoZSZu
YnNwO2ludGVydmFsJm5ic3A7b3ImbmJzcDt0aGUKJmd0OyZndDsmbmJzcDtjb250ZXh0Jm5ic3A7
c3dpdGNoJm5ic3A7YWx3YXlzJm5ic3A7b2NjdXImbmJzcDthdCZuYnNwO3RoZSZuYnNwO2VkZ2Um
bmJzcDtvZiZuYnNwO2ludGVydmFsLiZuYnNwO09ubHkmbmJzcDtpbiZuYnNwO3RoaXMmbmJzcDtj
b25kaXRpb24sCiZndDsmZ3Q7Jm5ic3A7Y2FuJm5ic3A7dGhpcyZuYnNwO2lkZWEmbmJzcDt3b3Jr
LgomZ3Q7Jmd0OwomZ3Q7Jmd0OyZuYnNwO1NvLCZuYnNwO0kmbmJzcDthbSZuYnNwO25vdCZuYnNw
O3N1cmUmbmJzcDt3aGV0aGVyJm5ic3A7d2UmbmJzcDtjYW4mbmJzcDtmaW5kJm5ic3A7c3VjaCZu
YnNwO2EmbmJzcDt0aW1lJm5ic3A7aW50ZXJ2YWwmbmJzcDt0aGF0Jm5ic3A7Y2FuJm5ic3A7bWVl
dAomZ3Q7Jmd0OyZuYnNwO3RoaXMmbmJzcDtjb25kaXRpb24uJm5ic3A7SW4mbmJzcDtvdGhlciZu
YnNwO3dvcmRzLCZuYnNwO3doZXRoZXImbmJzcDt3ZSZuYnNwO2NhbiZuYnNwO2ZpbmQmbmJzcDtz
dWNoJm5ic3A7YSZuYnNwO3RpbWUmbmJzcDtpbnRlcnZhbAomZ3Q7Jmd0OyZuYnNwO3RoYXQmbmJz
cDtlbnN1cmVzJm5ic3A7YWxsJm5ic3A7dGhlJm5ic3A7Q1BVJm5ic3A7Y29udGVudCZuYnNwO3N3
aXRjaCZuYnNwO29jY3VyJm5ic3A7YXQmbmJzcDt0aGUmbmJzcDtlZGdlJm5ic3A7b2YmbmJzcDtp
bnRlcnZhbC4KJmd0OwomZ3Q7WW91Jm5ic3A7c3RpbGwmbmJzcDtoYXZlbid0Jm5ic3A7ZGVzY3Jp
YmVkJm5ic3A7ZXhhY3RseSZuYnNwO3doYXQmbmJzcDtpdCZuYnNwO2lzJm5ic3A7eW91J3JlJm5i
c3A7dHJ5aW5nJm5ic3A7dG8KJmd0O2FjY29tcGxpc2g6Jm5ic3A7d2hhdCZuYnNwO2lzJm5ic3A7
eW91ciZuYnNwO2VuZCZuYnNwO2dvYWw/Jm5ic3A7Jm5ic3A7SXQmbmJzcDtzZWVtcyZuYnNwO3Rv
Jm5ic3A7YmUmbmJzcDtyZWxhdGVkJm5ic3A7c29tZWhvdyZuYnNwO3RvCiZndDttZWFzdXJpbmcm
bmJzcDtob3cmbmJzcDtidXN5Jm5ic3A7dGhlJm5ic3A7c3lzdGVtJm5ic3A7aXMmbmJzcDsoaS5l
LiwmbmJzcDt0aGUmbmJzcDtudW1iZXImbmJzcDtvZiZuYnNwO2FjdGl2ZSZuYnNwO3BjcHVzJm5i
c3A7YW5kCiZndDtpZGxlJm5ic3A7cGNwdXMpOyZuYnNwO2J1dCZuYnNwO2FzJm5ic3A7SSZuYnNw
O2Rvbid0Jm5ic3A7a25vdyZuYnNwO3doYXQmbmJzcDt5b3UmbmJzcDt3YW50Jm5ic3A7dG8mbmJz
cDtkbyZuYnNwO3dpdGgmbmJzcDt0aGF0CiZndDtpbmZvcm1hdGlvbiwmbmJzcDtJJm5ic3A7Y2Fu
J3QmbmJzcDt0ZWxsJm5ic3A7eW91Jm5ic3A7dGhlJm5ic3A7YmVzdCZuYnNwO3dheSZuYnNwO3Rv
Jm5ic3A7Z2V0Jm5ic3A7aXQuCiZndDsKJmd0O1JlZ2FyZGluZyZuYnNwO2EmbmJzcDttYXAmbmJz
cDtvZiZuYnNwO3BjcHVzJm5ic3A7dG8mbmJzcDt2Y3B1cywmbmJzcDt0aGF0Jm5ic3A7YWxyZWFk
eSZuYnNwO2V4aXN0cy4mbmJzcDsmbmJzcDtUaGUKJmd0O3NjaGVkdWxpbmcmbmJzcDtjb2RlJm5i
c3A7d2lsbCZuYnNwO2tlZXAmbmJzcDt0cmFjayZuYnNwO29mJm5ic3A7dGhlJm5ic3A7Y3VycmVu
dGx5Jm5ic3A7cnVubmluZyZuYnNwO3ZjcHUmbmJzcDtoZXJlOgomZ3Q7Jm5ic3A7Jm5ic3A7cGVy
X2NwdShzY2hlZHVsZV9kYXRhLCZuYnNwO3BjcHVfaWQpLmN1cnIKJmd0OwomZ3Q7WW91Jm5ic3A7
Y2FuJm5ic3A7c2VlJm5ic3A7ZXhhbXBsZXMmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO2Fib3ZlJm5i
c3A7c3RydWN0dXJlJm5ic3A7dXNlZCZuYnNwO2luCiZndDt4ZW4vY29tbW9uL3NjaGVkX2NyZWRp
dDIuYy4mbmJzcDsmbmJzcDtJZiZuYnNwOyJpc19pZGxlKHBlcl9jcHUoc2NoZWR1bGVfZGF0YSwK
Jmd0O3BjcHUpLmN1cnIpIiZuYnNwO2lzJm5ic3A7ZmFsc2UsJm5ic3A7dGhlbiZuYnNwO3RoZSZu
YnNwO2NwdSZuYnNwO2lzJm5ic3A7cnVubmluZyZuYnNwO2EmbmJzcDt2Y3B1OyZuYnNwO2lmJm5i
c3A7aXQmbmJzcDtpcyZuYnNwO3RydWUsCiZndDt0aGVuJm5ic3A7dGhlJm5ic3A7cGNwdSZuYnNw
O2lzJm5ic3A7aWRsZSZuYnNwOyhhbHRob3VnaCZuYnNwO2l0Jm5ic3A7bWF5Jm5ic3A7YmUmbmJz
cDtydW5uaW5nJm5ic3A7YSZuYnNwO3Rhc2tsZXQpLgomZ3Q7CiZndDtBZGRpdGlvbmFsbHksJm5i
c3A7aWYmbmJzcDthbGwmbmJzcDt5b3UmbmJzcDt3YW50Jm5ic3A7aXMmbmJzcDt0aGUmbmJzcDtu
dW1iZXImbmJzcDtvZiZuYnNwO25vbi1pZGxlJm5ic3A7Y3B1cywmbmJzcDt0aGUKJmd0O2NyZWRp
dDEmbmJzcDtzY2hlZHVsZXImbmJzcDtrZWVwcyZuYnNwO3RyYWNrJm5ic3A7b2YmbmJzcDt0aGUm
bmJzcDtpZGxlJm5ic3A7YW5kJm5ic3A7bm9uLWlkbGUmbmJzcDtjcHVzJm5ic3A7aW4KJmd0O3By
di0mZ3Q7aWRsZXJzLiZuYnNwOyZuYnNwO1lvdSZuYnNwO2NvdWxkJm5ic3A7ZWFzaWx5Jm5ic3A7
dXNlJm5ic3A7ImNwdW1hc2tfd2VpZ2h0KCZhbXA7cHJ2LSZndDtpZGxlcnMpIiZuYnNwO3RvCiZn
dDtmaW5kJm5ic3A7b3V0Jm5ic3A7aG93Jm5ic3A7bWFueSZuYnNwO2lkbGUmbmJzcDtjcHVzJm5i
c3A7dGhlcmUmbmJzcDthcmUmbmJzcDthdCZuYnNwO2FueSZuYnNwO2dpdmVuJm5ic3A7dGltZS4m
bmJzcDsmbmJzcDtJZiZuYnNwO3lvdSZuYnNwO2tub3cKJmd0O2hvdyZuYnNwO21hbnkmbmJzcDtv
bmxpbmUmbmJzcDtjcHVzJm5ic3A7dGhlcmUmbmJzcDthcmUsJm5ic3A7dGhhdCZuYnNwO3dpbGwm
bmJzcDtnaXZlJm5ic3A7eW91Jm5ic3A7dGhlJm5ic3A7YnVzeS1uZXNzJm5ic3A7b2YKJmd0O3Ro
ZSZuYnNwO3N5c3RlbS4KJmd0OwomZ3Q7U28mbmJzcDtub3cmbmJzcDt0aGF0Jm5ic3A7eW91Jm5i
c3A7aGF2ZSZuYnNwO3RoaXMmbmJzcDtpbnN0YW50YW5lb3VzJm5ic3A7cGVyY2VudGFnZSwmbmJz
cDt3aGF0Jm5ic3A7ZG8mbmJzcDt5b3UmbmJzcDt3YW50CiZndDt0byZuYnNwO2RvJm5ic3A7d2l0
aCZuYnNwO2l0PwomZ3Q7CiZndDsmbmJzcDstR2VvcmdlCiZndDsKJmd0O19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCiZndDtYZW4tZGV2ZWwmbmJzcDttYWls
aW5nJm5ic3A7bGlzdAomZ3Q7WGVuLWRldmVsQGxpc3RzLnhlbnNvdXJjZS5jb20KJmd0O2h0dHA6
Ly9saXN0cy54ZW5zb3VyY2UuY29tL3hlbi1kZXZlbAo8L3ByZT48L2Rpdj48YnI+PGJyPjxzcGFu
IHRpdGxlPSJuZXRlYXNlZm9vdGVyIj48c3BhbiBpZD0ibmV0ZWFzZV9tYWlsX2Zvb3RlciI+PC9z
cGFuPjwvc3Bhbj4=
------=_Part_343557_1060246463.1324366204521--

------=_Part_343555_1040962665.1324366204520
Content-Type: image/jpeg; name="fig1.jpg"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="fig1.jpg"

/9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAMCAgMCAgMDAwMEAwMEBQgFBQQEBQoHBwYIDAoMDAsK
CwsNDhIQDQ4RDgsLEBYQERMUFRUVDA8XGBYUGBIUFRT/2wBDAQMEBAUEBQkFBQkUDQsNFBQUFBQU
FBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBT/wAARCAD/Ah4DASIA
AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA
AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3
ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm
p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA
AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx
BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK
U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3
uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD9U6KK
KACiiigAooooAKK8s/aOuZbT4faS8MrxOfGHhVC0bFSVbX9PVhx2IJBHcEivU6ACiiigAoorivA3
hybRPE/xEvH1SO/XWddivo7eNizWKrpljb+S4zwSbdpcDHEynvkgHa0UUUAFFFcR8TPDUXiT/hFP
N1aDSf7P1+0v088gfaWTfiBeR8zZ469OhoA7eiiigAooooAKK4j4aeGYvDTeLFi1aDVTfa/dX7iH
H+itIEPkNyfmUAHt94cV29ABRRRQAUVxHxM8NReJP+EU83VoNJ/s/X7S/TzyB9pZN+IF5HzNnjr0
6Gu3oAKKKKACiiuI+GnhmLw03ixYtWg1U32v3V+4hx/orSBD5Dcn5lAB7feHFAHb0UUUAFFFcR8T
PDUXiT/hFPN1aDSf7P1+0v088gfaWTfiBeR8zZ469OhoA7eiiigAooooAKK4j4Z+GovDf/CV+Vq0
Grf2hr93fv5BB+zM+zMDcn5lxz069BXb0AFFFFABRXEfEzw1F4k/4RTzdWg0n+z9ftL9PPIH2lk3
4gXkfM2eOvToa7egAooooAKKK4j4Z+GovDf/AAlflatBq39oa/d37+QQfszPszA3J+Zcc9OvQUAd
vRRRQAUUVxHxN8NR+JF8LNLq0GkjTtftL9TPgfaWQsBAuSPmctgdenQ0AdvRRRQAUUUUAFFJketG
aAFooooAKKTI9aMj1oAWiiigAooooAKKKKACiiigAooooAKKKKAPKv2lf+SdaR/2OfhP/wBSHTq9
Vryr9pX/AJJ1pH/Y5+E//Uh06vVaACiiigArifAOkaPpviv4k3Omap/aF7qHiCG51S3xj7DcjSrC
JYffMEVvL/22rtq4fwF/wjv/AAlfxK/sb7T/AGj/AMJBD/bnnZ2/bf7K0/Z5f+z9m+ydP4t9AHcU
UUUAFcP8TtN0PUv+ET/tzUZNONvr9pPY+WM+fdrv8uI8Hhst6dOoruK4f4nz+HYB4T/4SG3uJ9/i
C0TThbkjZenf5TNgj5R82ev0NAHcUUUUAFFFFAHD/DbTdC0688ZnQ9Sk1CS51+efUVkGPs12YoQ8
Q4GQFCHv97rXcVw3w2m8PTXfjMaBDcW8ieIJ01MzkkPe+VDvZMk/LtMeOnIPFdzQAUUUUAcP8TtN
0PUv+ET/ALc1GTTjb6/aT2PljPn3a7/LiPB4bLenTqK7iuH+J8/h2AeE/wDhIbe4n3+ILRNOFuSN
l6d/lM2CPlHzZ6/Q13FABRRRQAVw/wANtN0LTrzxmdD1KTUJLnX559RWQY+zXZihDxDgZAUIe/3u
tdxXDfDabw9Nd+MxoENxbyJ4gnTUzOSQ975UO9kyT8u0x46cg8UAdzRRRQAVw/xO03Q9S/4RP+3N
Rk042+v2k9j5Yz592u/y4jweGy3p06iu4rh/ifP4dgHhP/hIbe4n3+ILRNOFuSNl6d/lM2CPlHzZ
6/Q0AdxRRRQAUUUUAcP8MdN0PTf+Es/sPUZNRNxr93PfeYMeRdts8yIcDhcL69epruK4f4YT+HZx
4s/4R63uINniC7TURcEnfejZ5rLkn5T8uOn0FdxQAUUUUAcP8TtN0PUv+ET/ALc1GTTjb6/aT2Pl
jPn3a7/LiPB4bLenTqK7iuH+J8/h2AeE/wDhIbe4n3+ILRNOFuSNl6d/lM2CPlHzZ6/Q13FABRRR
QAVw/wAMdN0PTf8AhLP7D1GTUTca/dz33mDHkXbbPMiHA4XC+vXqa7iuH+GE/h2ceLP+Eet7iDZ4
gu01EXBJ33o2eay5J+U/Ljp9BQB3FFFFABXEfFHTdD1O08NrrupSabHD4gsJ7NoxnzrtZQYYjweG
bg9PqK7euH+KU3h6Cz8NnxFBcXEba/YJYi3JBS9Mo8hmwR8obr147GgDuKKKKACiiigD4g+LfxS+
IjfGvx/pWmfEDVtA0jR9QtrOzsNPtLEoiNp9pOxLS2zuWMk8nVsYwABiua/4WJ8UP+is+Jv/AAE0
v/5DqX4n/wDJwHxa/wCw3af+mfT6xq/mriTO8xw+bV6NGtJRT0S6H8g8XcRZthM7xNGhiJRgnols
lZGn/wALG+KP/RWfE3/gJpf/AMh0f8LG+KP/AEVnxN/4CaX/APIdZlFfM/6x5t/0ESPjv9bM9/6C
p/ebGmfFn4m6P4p8JPL8Sdb1O2uvEekWFxZ3tpp/lTQ3GoQQSqdlqrD5JWwVYEHBr78yD/8AXr84
J/8AkYPBX/Y3+Hv/AE72lfo+MfnX7twNjMRjstnUxM3KSm1d9rR0/E/pfw2zDFZllFSti6jnJTau
+3LHT72x9LXnem/tB/C3WP7K+wfEvwhfDVrxtN0/7NrtrJ9suh5ebeHEh8yUefDlFy372Pj5hnlo
Pjj4v1jTtA8TaD8OP7f8BeIb3TodM1Oy1YnUfsl1cQxjUbiyNviK2EMjzjbLJKF8rzYoMzG3/RT9
YPbaK+ffDH7Qfje80m18QeJPAegaX4XbxM3hW4n0vxTPfXsd1/ax0lXSB9PhR4jdbSSZlYREttLD
yzaH7QPim3/Z18efEu+8F6PFqXhabWFOi2/iGWWG6i0y4lguX+0myUozNbXBjXymDARbmTe3lgHv
FFeeW3xJ1SD4p+GfA+q+Gvsd3qnhm612fVLa/Wezjnt57OGW0hyqyy4N4GMrxxDb5eAxZ1i9DoAK
KKKACiiigAooooA8q/aV/wCSdaR/2OfhP/1IdOr1WvKf2lf+SdaR/wBjn4T/APUh06vVcigBaKTN
GaAFrifAOr6PqXiv4k22maX/AGfe6f4ghttUuM5+3XJ0qwlWb2xBLbxf9sa7XIrjPBPiGfWvE3xB
s5dJTT49I12KyhuUQqb9G0yxnM7Ej5iGnaLIzxCB2IAB2lFJmjNAC1w3xO13TNBPhP8AtLSI9W+2
a/aWdt5hA+yzvv2TjIPK4PTB5613GQO9ch8QvEOo6B/wjX9m6Yup/btbtrK53RNJ9ngfdvmG37pX
A+Y8DPNAHYUUmaM0ALRSZozQBxHw213TNcu/GaadpEelPYeIJ7O7ZCD9rnWKFmnOAOSGUc5Pyda7
iuO8A+INR1258VpqGmLpq6frc1lassTJ9qgWOJlmO77xJdhuHHy+1dhketAC0UmR60ZHrQBw/wAT
td0zQT4T/tLSI9W+2a/aWdt5hA+yzvv2TjIPK4PTB5613Ncf8QvEOo6B/wAI1/ZumLqf27W7ayud
0TSfZ4H3b5ht+6VwPmPAzzXX5FAC0UUUAFcP8Ntd0zXLvxmmnaRHpT2HiCezu2Qg/a51ihZpzgDk
hlHOT8nWu3yK4/wD4g1HXbnxWmoaYumrYa3NZWrLEyfaoFjiZZju+8SXYbhx8vtQB2NFJmjNAC1w
3xO13TNBPhP+0tIj1b7Zr9pZ23mED7LO+/ZOMg8rg9MHnrXcEgdSK5D4heIdR0D/AIRr+zdMXU/t
2t21lc7omk+zwPu3zDb90rgfMeBnmgDsKKTNGaAFopM0ZoA4f4Y67pmvHxZ/ZukR6T9j1+7s7nyy
D9qnTZvnOAOWyOuTx1rua4/4e+ItQ1//AISX+0tMXTDY63c2VttiaP7RAm3ZMd33i2T8w4OOK6/I
PegBaKKKAOG+J2u6ZoJ8J/2lpEerfbNftLO28wgfZZ337JxkHlcHpg89a7muP+IfiHUdA/4Rr+zd
MXU/t2t21lc7omk+zwPu3zDb90rgfMeBnmuvyKAFopM0ZoAWuG+GOu6Zrx8Wf2bpEek/Y9fu7O58
sg/ap02b5zgDlsjrk8da7jI9a5D4e+IdR1//AISX+0tMXTDY63c2VttiaP7RAm3ZMd33i2T8w4OO
KAOwooooAK4f4o69pugWnhqTU9Ij1dbrX7Czt1lIH2eeSULHOMg8oeR0PuK7iuO+IniDUfD1voD6
bpi6o93rdlZTq0TSeRBJIFkmG3oUHO48DvQB2NFFFABRRRQB+b/xt+IXhfwr+0Z8WbPW/Emk6Pdn
V7OVYNQv4oHZDpGngMFdgSMgjPTIPpXK/wDC5/h9/wBD34a/8HFv/wDF1+o2ASPSlPTrivzzMOCs
BmOKni6spc0ux+VZr4eZZm2MqY2vOSlN302Py4/4XP8AD7/oe/DP/g4t/wD4uj/hc/w+/wCh78M/
+Di3/wDi6/Uj8KPwrz/+IeZZ/PI8r/iFWT/8/J/eflzY/E7wfr/i7wNYaX4q0TVL+bxf4e8u1stR
hllfGrWpOEViTgAk4HABNfqIABz3pGAIx3pRwB/WvtMmyehkmHeGw7bi23r5pL9D9C4fyDD8O4WW
Ewsm4uTlr3aS/Q8L8LfCHxDpvxrkku0tz8O9I1PU/EuiRLKN0eo6hDCjkf8ALRmSWbX5HWQmMLqd
uE3mPbbWvhTYeO/APhfwd8MoPDPk2nheystLn8Z3k8EmnX9lbIkYa3t45/tIuZo1QFJUSOFmlYS3
AhRbn26ivfPqD5z+APwQhmsdR13xn4Y8UaFrreLNX1iHRtb8SyXWnlZ9SnvbScWFvezWQZBNEeUD
LPCZB8wSVk8QfDrxa3w88d/B+18PXF5pvjCbXWj8apc2y2Nhb6tc3NxMZ4GlFwZ4PtUyJHFG8c2y
AtNB5sn2f6NooA8n8R2GvyftM+B9Ug8MahdeG7PwzrGnXeuxz2gt7ee6uLCWJGjacTtxp7glImAM
0XJHmGP1iiigAorG8R+KtD8H2iXmvazp+iWreZtn1G6S3Q+XDJPJhnIHywwzSN6JE7HhSRynij4p
7f8AhHrDwVbaf4v13xHZS6ppKPqP2fTpbCLyfNu3u0jmxF/pNuq+XHIztPHhRGJJYwD0Sivn3Ufj
38SrXVtI0dPhTp9jquoeJpvDMa634mktreZ49JGo/a7eWKxm862fyruJW2q4MUe9Ed5Y4LUP7QHi
pvFnhzw1L4L0dNWn8WP4T1wp4hla3sZf7KGrJNav9iDXSmz3ZDrARMAnKHzQAe8UV5lH8TvEJ+Lf
jTwmPCVveaboGgWeuW11YasGvtQa5e5jit1t5Yo4o2L2VyNzXG3/AFJJG9/K3/hT46PxP+Fng7xk
LH+zB4i0Wy1f7F5vm/Z/tECS+Xv2ru278btozjOB0oA5b9pT/knWkf8AY5+E/wD1IdOr1PcM9RXi
v7Xur3OhfBKXU7a2jurqw8ReHbuG3llMSSyR61ZOqM4VigJUAsFYgEnBxivLF/bG+ICjH/Cu/DR9
z4nuP/kGvEzDOcDlcoxxlRRb2ufOZpxBluTSjDHVVByV1fqfX/HvRxXyF/w2R8Qf+ie+Gf8Awprj
/wCQaP8Ahsj4g/8ARPfDP/hTXH/yDXkf635N/wBBCPE/174e/wCglH13n16Vyfg3UPEF34j8dw61
bGDTbTWY4dEk8sL51mdPs3d8/wAX+kvdLk/3Mdq+bz+2N8QD/wA098Nf+FNcf/INcx4U/bE+I/8A
b/jTzvCOiahEdXjMNvceIp1SxT7DaAwxEWRLIW3S5ODuncYwoJ0jxXk802q603/L82aQ42yGalKO
JVo6vyV0vzaPuXijj3r5C/4bI+IP/RPfDX/hTXH/AMg0f8NkfEH/AKJ74Z/8Ka4/+Qaz/wBbsm/6
CEZ/698Pf9BKPrzOeuK5Lx9c+JbdvDv/AAjcfmbtZtk1L5UO2yO7zj83T+Hkc+lfN4/bH+IIP/JP
PDP/AIU1x/8AINcv4+/bA+IzWujXMfhHRdNS21izeUWniS4JulaURCBs2Y+RmkUsecBcgE4FaU+K
8nqSUIV02y6fG2Q1pqFPEJt6L1Z9zce9HHvXyF/w2R8Qf+ie+Gv/AAprj/5Bo/4bI+IP/RPfDP8A
4U1x/wDINZ/63ZN/0EIj/Xvh5f8AMSj69496OK+Qv+GyPiD/ANE98M/+FNcf/INH/DZHxB/6J74Z
/wDCmuP/AJBo/wBb8m/6CEH+vfD3/QSj6P8AAlx4juLrxR/wkSbIk1qZNKwqDdY+XFsPy9fnMnLc
/pXWjg1+ZWof8FRvE3wj8Y+LNA1z4e2+vXX9o/a43TxM4itYpYIWSCPdZ5Kryeg5ZuOMlT/wWWvP
+iQQf+FO3/yHX7NlfBef5zgqWYYDCudKolKMk46p7btM+to5hhq1KNWE/dkk16NXR+mmPajHtX5l
/wDD5i9/6I/B/wCFO3/yHR/w+Yvf+iPwf+FO3/yHXq/8Q34r/wCgKX3x/wDkjX65Q/mP0I8fXHiS
A+HP+Ebj8zfrVsmpfKh22J3ecfm6fw8jn0rrR+Ffmh4d/wCCpOsfF/4lfDnwtbeA28LJqPinTbW4
vLbxAZy8Us6wtGyfZk3KfMBI3fw1+l/oa+QzfI8wyKssPmNLkm1dLTZtq+jfZm9OpCqrwdx1FFFe
KajcHFcj4FuPEc9z4oHiKPy449alTSvlRd1j5cWw/L1+cyctz+lddnvXwf8AET9uTxT8CPjH8RPB
s/hS38VxWWsLNb3d3rj2/lQzWlvKkKxi3faqh89erNx3PNXr08PDnquyPWyvKcbnOI+qYCnz1LN2
62R94cUce9fnx/w9G8Q/9Et0z/wpJP8A5Eo/4ejeIf8Aolumf+FJJ/8AIlef/bGB/wCfh9p/xDji
n/oDl98f8z9BSAefXsa5Px9c+JLY+HB4cj379Ztk1LKodtid3nH5un8PI59K+Jj/AMFRvEJH/JLd
M/8ACkk/+Q653xj/AMFLvFepRaO9r4DtdLW01S2uJhb+I5CbmMMQYGP2UYRtwz1xjoelNZvgpNJV
DKp4ecTUoOpUwjSSu3ddPmfpTxRx71+fH/D0bxD/ANEt0z/wpJP/AJDo/wCHo3iH/olumf8AhSSf
/IlL+2MD/wA/DVeHHFL1+py++P8AmfoPx70cV+fH/D0bxD/0S3TP/Ckk/wDkSj/h6N4h/wCiW6Z/
4Ukn/wAiUf2xgf8An4H/ABDfin/oDl98f8z7Z8BT+JJz4j/4SSPy9mtXKab8qDdYjb5J+Xr/ABcn
n1rrQMV88fsV/GnVvjt4F8Y6/q9u1ncQ+Kbm1jtftjXSQxG2tpljRyiEKvnYxjqD619DKTz1/GvV
pzjUgpxd09Ufn2Kw1XB154aurTg3Frs07MkoopDWhzHI+PrjxJB/wjn/AAjcfmF9atk1L5UO2xO7
zj83T+Hkc+ldXuGeorxr9qXxlr3w6+HGn+JvD6CabTte037RZvdvardRTXC2/lNIqOQpeaMt8p4B
OCRg+Tr+2N8QFGP+Fd+Gj7nxPcf/ACDXh5hnOByuUY4ypyt7XPnM04hy3Jpxhj6qg5K6v1Pr/j3o
496+Qv8Ahsj4g/8ARPfDP/hTXH/yDR/w2R8Qf+ie+Gv/AAprj/5Bryf9b8m/6CEeJ/r3w9/0Eo+u
geCen1rlPAFx4kuD4i/4SNAmzWrlNN+VBusRt8k/L1/i5PPrXzef2x/iAevw78Nf+FPcH/2xr0f9
k/4k698S/D/jm88RRJb31j4ontVghvWu4oontLW4REdo0O1RcbcbRyDXp4DPMvzOq6WEqc0kr28t
P8z18s4kyvOKroYGspySu15XS/U95ooor3z6cK5H4g3HiS3ttCPhqPzZn1qzS/8AlQ7bEyD7Qfm9
E7jn0rrq5H4haPr+sW2hLoF99hlt9Zs7m9PmmPzbRJAZo+Ac7l42ng0AddRRRQAUhpaKAPxs/b0+
O/xK8J/tc/EHRtC+IXirQ9IsmsFt7DTNbubaCINp9s7bY43CjLu7E4ySxrwL/hpj4w/9FY8c/wDh
S3v/AMdr0T/goqf+M1fib/1007/02WlfOWc1/fPAmV4Ctw5g6lWhCUnBauMW/wAUfLYmco1pJM9J
/wCGmvjF/wBFY8df+FLe/wDx2j/hpr4xf9FY8df+FLe//Ha82z7UZ9q+/wD7Hy3/AKBaf/gEf8jl
9pP+Zn0L8Af2ifitqvx8+GNjffEzxjfWN34q0m2ubW71+7linikvIkkjdGkKsrKzAgg9a/dE1/PX
+zlx+0b8Jen/ACOWi/8ApfBX9Cn8q/jjxgwtDC57ShQgoJ0lokkvil2PoMvk3Sbbvr/kOpa87039
oP4W6x/ZX2D4l+EL4ateNpun/ZtdtZPtl0PLzbw4kPmSjz4couW/ex8fMM8tB8cfF+sadoHibQfh
x/b/AIC8Q3unQ6ZqdlqxOo/ZLq4hjGo3FkbfEVsIZHnG2WSUL5XmxQZmNv8Ahx6Z7bRXz74Y/aD8
b3mk2viDxJ4D0DS/C7eJm8K3E+l+KZ769juv7WOkq6QPp8KPEbraSTMrCIltpYeWbQ/aB8U2/wCz
r48+Jd94L0eLUvC02sKdFt/EMssN1FplxLBcv9pNkpRma2uDGvlMGAi3Mm9vLAPeKK8n8RfFPxf4
NvNKudc8F6faeHJL3TNIvr+314zXAvb2aC3Q2kH2cCa2S4uoo2lmkt5MJMwgIWMS+sUAfPn7UOiQ
XPjP4E6wng/T/GGtab4zme0tLoQpOUGjalO6wSyqVWXdbQyorMiNNBBukiCiRK3hL4d+Lfh+PDfj
YeHbjWtStJvFTXXhWzubZL5LfWtYTUYyskkq27TweTDHJH5ojO+Zo5n8pFn9p8SfD/wt4x1bRtT1
/wAM6PrepaJN9p0u91KwiuJrCXcjeZA7qTE26OM7lIOUU9hXR0AfOXxT8L+Nfihe/Csa14P1hNNj
8WS6pexeG9bTT7vQtPOm3VpEtzdx3sUkk5lu1lkFoWVUWWIGbYr3PV+Jfg5F4VsPCmpeDdPuNRu/
DHiB/EU9jeahJcX2ts+n3NhIrXt1IzvOsNyPLM7lT9mhhLwx4ki9iooA8n8H2GvnxT4z+JWo+GNQ
0u71LRrHS7Pwm89pLqLpYyX0wZ5EnNsks0l86KgmZFWON3lUyPHDb/Zq0PWfC37Pnw40DxFo9xoG
uaL4fstKvbC5lglaOW3hWFmDwySIysY96kNnay7grZUem0UAeFftpf8AJv8AqP8A2G9B/wDTxZ18
uV9R/tpsB+z/AKjkgf8AE70H/wBPFnXy5X4T4jU5zr0HGLej/Q/mjxapVKmJwrhFv3XsvNBRRRX4
57Cr/I/uZ+A/Vq/8j+5hXNeFP+Q/4z/7C0f/AKQWldLXM+EznX/Gntq0f/pBaV6mFo1fY1/dfwro
/wCeJ7WCw9ZUMT7j+BdH/PA6aiiivL9hV/kf3M8b6tX/AJH9zCua+IX/ACALX/sLaZ/6XwV0tcz8
QiBoFrk4/wCJtpf/AKX29ell1CqsbRbi/ij0fdHrZTh6yzDDtwfxx6PujpqKKK8+VCrd+4/uZ5Us
NX5n7j+5hRRRU+wq/wAj+5i+rV/5H9zPgj9pb/kuniv/AH7X/wBJIK80PWvS/wBpX/kuniv/AH7X
/wBJIK80PWv9xfCjEUafBGVRnNJqlHRtdj+yspjJZbhU1/y7h/6ShKKKK/XPreG/5+R+9Hqcr7Ho
v7OP/Jxvwl/7HHRf/S+Gv6FR0r+er9nE/wDGRvwl/wCxx0X/ANL4a/oVHSv4w8ZakKufUnCSa9mt
tftSPosvTVJ37/5C0UUV+DHqDT3r8dP2qrMWH7UnxVjFwt0G1eKXzEPA32Vs+zqeV3bT7r2r9izz
X45/tUQ2kH7UnxVWznNxCdXidnPaRrK2aRen8Lll/DvXzuepvBNJdUfsfhROFPiWEpuy5Zb+h5fR
RRX5l7OfZn9y/W8P/wA/I/egqjrP/HpH/wBfEH/o5KvVR1ogWceTj/Sbf/0cldGHhP2sNOq/M8jN
sVh3gK6VRfC+q7MvUUUVg6c77M9SGLw/Kv3kfvQUUUUvZz7Mv63hv+fkfvR+in/BLv8A5I745/7H
CX/026fX2T3FfG3/AAS8IHwd8c8j/kcJf/Tbp9fZPcV+wYJNYWkn/KvyR/m9xRJSz3HNPT2s/wD0
pi0UUV3nzB85ft2aeL74I6fM14tsbTxRok4jY83BN9FH5Y56jzC/fiM/UfOlfRP7d0FhL8E9Ne8u
WguIfFOiPZxr0ml+3RKUPHTy2kbtyo+h+dq/CPEanOdeg4xb0f6H8z+LNKpUxOFcIt+69l6BRRRX
477Cr/I/uZ+BfVq/8j+5hX0B+w3/AMi/8UP+xw/9xGmV8/19AfsOMBoHxQGR/wAjeP8A00aZX6p4
d0qkMyquUWlyPp/eiftnhTRqU84rOcWl7N7r+9E+mKKKK/oU/qkK4r4neHU8SWnhxH1iHRxZ69Y3
oaY4+0GOUMIF5HzP0HX6Gu1riPijpuh6naeG113UpNNjh8QWE9m0Yz512soMMR4PDNwen1FAHb0U
UUAFIaWkNAH4z/t7/BP4keKf2vPiHq2h/Dnxhrmk3T2DQahpmgXl1bzBdOtVbZJHGyth1ZTg8FSO
1fP/APwzp8Xef+LS+P8A/wAJTUP/AIzX9Cu4jjvSDOecfhX6nlfiXxBk+Dp4HCyioQVleKbt6nDP
B0qknJ3uz+e3/hnT4u/9Ek+IH/hJ6h/8Zo/4Z0+Lv/RJPiB/4Seof/Ga/oW3Ubq9b/iLvFH88P8A
wBEfUKPmfhN8APgD8VNO+Pvwvvb34XeNrCytPFek3Nzd3nhu9hhgijvIneR3eIKqqqkkkgACv3YH
SkyM9aXIAzX5zxBxHj+JsTHF5g05xXKrKysrvb5nXRoxox5YnhPhb4Q+IdN+Nckl2kB+Hekanqfi
XRIllG6PUdQhhRyP+WjMks2vyOshMYXU7cJvMe22tfCmw8d+AfC/g74ZQeGfJtPC9lZaXP4zvJ4J
NOv7K2RIw1vbxz/aRczRqgKSokcLNKwluBCi3Pt1FfOGx85/AH4IQzWOo674z8MeKNC11vFmr6xD
o2t+JZLrTys+pT3tpOLC3vZrIMgmiPKBlnhMg+YJKyeIPh14tb4eeO/g/a+Hri803xhNrrR+NUub
ZbGwt9Wubm4mM8DSi4M8H2qZEjijeObZAWmg82T7P9G0UAeD/FG+8ceIfi34a0qD4Z6xq/grRdTs
b86kmpadFZ31wz7WlnjkufN8iySQ3KRiBpJbqGAqYRArze8UUUAFFFFABRRRQAUUUUAeLftZaJa+
JfhDBpGoCV7G/wDFXhi0uFgneCQxya9YIwWSNldDgnDKQw6ggjNZp/Yj+EmeNN8Tf+Frrf8A8mV0
n7SmR8O9I4/5nPwn/wCpDp1ep4JNZSpwnbmV/UynTp1Lc8U7eR4V/wAMRfCP/oHeJf8Awttc/wDk
yj/hiL4R/wDQO8Tf+Ftrn/yZXu+z3pNnvUewo/yL7kZ/VaH8i+5HhH/DEXwk/wCgd4l/8LbXP/ky
uZ8Kfsg/BHWNd8Z2un2Pil7vStWjs9QWTxfrEYSc2NpMoVhdguPKmhO5iTklc7VUD6e2+9cT4B1b
R9S8V/Em20zS/wCz73T/ABBDa6pcZz9uuTpVhKs3tiCW3i/7Y01QpLaK+5DWHoraC+5Hn3/DEPwj
/wCgd4m/8LbXP/kyj/hiL4R/9A7xN/4W2uf/ACZXu2z3o2e9HsKP8i+5C+q0P5F9yPCP+GIvhH20
7xL/AOFtrn/yZXNeOP2SPgj4dj0SPVdJ8UTJqWrW1hboni/WZB57NujZg15wFZA24cgqCOa+nNtc
R8Ttc03QT4T/ALT0iPV/tmv2lnbeYQPss779k4yDyuD0weetCoUk7qK+5AsPRTuoK/ojgP8AhiL4
R/8AQO8S/wDhba5/8mUf8MRfCP8A6B3ib/wttc/+TK922e9Gz3o9hR/kX3IPqtD+Rfcjwn/hiL4R
/wDQO8Tf+Ftrn/yZR/wxF8I/+gd4m/8AC21z/wCTK922e9G33pewo/yL7kL6rQ/kX3I+SNH/AGEv
2cPiNqviS5fwXquoX2nam+m3tzqHiPVGkeaOKM8N9qJZQrIAW54x0ArWH/BND9m/OP8AhXtxn/sY
tVx/6VV7V8Ntd03XLzxkmnaRHpTWGvz2d2yEf6XOsULNOcAckMo5yfk6125H1ruhiK1OKjCbSXZs
3UYrRLQ+X/8Ah2d+zh/0T6f/AMKPVf8A5Ko/4dnfs4f9E+n/APCj1X/5Kr6gwaMGtfreI/5+S+9h
yx7HylcfsR/s5/B7xN4O8QWngi8s9XXX7JNLuItb1CcR3ok8yFnSS4KlQ0YJyD0HBr6txxXEfE7X
NN0E+FP7S0iPVvtmv2lnbeYQPss779k4yDyuD0weetdxiuapUnVfNUbb8ytth1FFFSMZ1HYV8z3H
7J/wM+NnjPxp4h1Dwxql3ri6zJa6pcDXdQtFluUiiyVjguFTbsMYztB4r6Zxx0rh/hvrema7d+M0
03SY9Kaw1+ezu2jI/wBLnWKFmnOAOSGUc5PydaTSkrNaFQnKm+aDt+Z5N/w7v+An/Qoan/4VWr//
ACXR/wAO7/gJ/wBChqf/AIVWr/8AyXX0hijFRyQ/lRv9bxP/AD8l97Pm/wD4d3/AP/oUNT/DxVq/
/wAl1zvjL9hv9nTwuuiDUvCGsldT1S3063EXibVXHnPkx7t13woKZyOQQMV9Z4Irh/idrum6EfCZ
1LSI9W+2a/aWdt5hA+yzvv2TjIPK4PTB560ckV0QPFYhqzqSt6s8m/4d3/AT/oUNT/8ACq1f/wCS
6P8Ah3f8BP8AoUNT/wDCq1f/AOS6+kMUYo5IfyoPreJ/5+S+9nzf/wAO7/gJ/wBChqf/AIVWr/8A
yXR/w7v+An/Qoan/AOFVq/8A8l19IYoxRyQ/lQfW8T/z8l97PI/2dvAngH4c+HvE+ifD3TbzTNPt
9fuUvkvbua6Z7xI4o3ZZJpJHK7Y41GT/AA9K9cT7vX8TXEfDHXNM14+LP7N0iPSfsev3dnc+WQft
U6bN85wBy2R1yeOtduFIPt6VokrWRzSk5O7f+bH0UUUAeV/H3wx4K8b+HNB0Dx1Y3eoaXqGuWcFq
ljcy2zreZZoX8yJ0dApUnKtkHFcwf2I/hJnjTfE3/ha63/8AJleg/E7XdN0E+FP7S0iPVvtmv2ln
bbyB9lnffsnGQeVwemDz1rtsEms5U4TtzK/qYzpU6lueKbXkeFf8MRfCP/oHeJf/AAttc/8Akyj/
AIYh+Ef/AEDfE3/hba5/8mV7vs96NvvWfsKP8i+5EfVaH8i+5Hgw/Yj+Eh/5h3iUH38ba3/8mV0n
wA8HeCPBOj+KtL8D2eoWtrFr9wmoHVL6e8llvEihidhLPJI5Xy44lGW6L0FepgE9sVxPwz13TdeP
iv8AszSI9J+x6/d2dyYyP9KnTZvnOAOWyOuTx1q40oQ1jFJ+WhcKNOm7wil8juqKQUtamwVw/wAU
pvD0Fn4bPiKC4uI21+wSxFuSCl6ZR5DNgj5Q3Xrx2NdxXD/FHXtN0C08NSanpEerrda/YWduspA+
zzyShY5xkHlDyOh9xQB3FFFFABRRRQB+Vn7WnxW8daH+1B8RdO0vxx4n0rTbS5s47exsNbureCFW
061dgsaOFXLuzHA5LEmvKT8bPiR/0Ufxn/4UV7/8drrv2y/+Tsvif/1+WP8A6arKvHRivy3M69WG
MqRjNpX2TZ/evAmUZdiOHMHUrYeEpON7uMW3q+rR2n/C7fiT/wBFH8Z/+FFe/wDx2j/hdvxJ/wCi
j+M//Civf/jtcXj6UY9xXk/Wa/8Az8f3s/QP7Cyn/oEp/wDgEf8AI9X+GPxm+Ilx8Wvh5bzfEHxZ
c29z4q0e2nt7jXruSKaKS/hjkjdGkKsrIzKQc9a/YE/dGP1r8TvhVn/hcXw0/wCxw0L/ANOVvX7Z
jBJBFfoXD85VMNKU3d3fW/RH8deL2EoYPPaVPDU1BOknaKSV+aXYcOlLXk+j/tNeAdd/4R/7JPr5
/t7Wrjw9p/neFNVh8y/gz58Lb7YeVs2y7mk2qPIuMn9xLs5/QvHvxY8deGfCnjvwtaeGL3wn4mm0
u7g0C7t5odS0/SLieFpLp7rz/KmnFqzubdYowjOQstx5IFz9Mfh57xRXzR4X+LHxTs/C9t4u8R6v
4Q1XRl8Zt4SuNJ0vw7dWVxJ/xPzoy3CXL6hMqYbbcFDC2QDHuBPmC0/xc+Ith+yz8TPH13f+F7rx
X4Ym8RNaGHRLmKxki0q6uICkkJvWctMLORtwlATzkG1/LPmAH0bRXiPiz4heN/AvjzwRo99q/hC/
n1+8g0y18PW9nPDqOs7Ylk1C/hle4KWkVuhmmMDJcZWCNPP826RU9uoAKKKKACiiigAooooA8q/a
V/5J1pH/AGOfhP8A9SHTq9Vryr9pX/knWkf9jn4T/wDUh06vVaACiiigAri/BPiGfWvE3xBs5dJT
T49I12KyhuUQqb9G0yxnM7Ej5iGnaLIzxCB2IHaVyPg6/wDEF54j8dw6zbeTp1prMcOiP5YXzrI6
dZO75/i/0l7tcn+5jtQB11FFFABXH/EPxDqOgf8ACNf2dpi6n9u1u2srndE0n2eB92+YbfulcD5j
wM812Fcj4+uPElv/AMI5/wAI3H5m/WrZNS+VDtsTu84/N0/h5HPpQB11FFFABRRRQBx3gHX9R125
8VpqGlrpq6frc1lassTJ9qgWOJlmO77xJdhuHHy+1djXI+BbjxJPdeKB4ij8uJNamTSvlQbrHy4t
h+Xr85k5bn9K66gAooooA4/4h+IdR0D/AIRr+ztMXU/t2t21lc7omk+zwPu3zDb90rgfMeBnmuwr
kfH1x4kt/wDhHP8AhG4/M361bJqXyodtid3nH5un8PI59K66gAooooAK47wDr+o67c+K01DS101d
P1uaytWWJk+1QLHEyzHd94kuw3Dj5fauxrkfAtx4knuvFA8RR+XEmtTJpXyoN1j5cWw/L1+cyctz
+lAHXUUUUAFcf8Q/EOo6B/wjX9naYup/btbtrK53RNJ9ngfdvmG37pXA+Y8DPNdhXI+PrjxJb/8A
COf8I3H5m/WrZNS+VDtsTu84/N0/h5HPpQB11FFFABRRRQBx/wAPPEOo6/8A8JL/AGjpi6Z9h1u5
srbbE0f2iBNuyY7vvFsn5hwccV2Fcj4BuPElx/wkf/CSR+Xs1q5TTflQbrEbfJPy9f4uTz6111AB
RRRQBx/xD8Q6joH/AAjX9naYup/btbtrK53RNJ9ngfdvmG37pXA+Y8DPNdhXI+PrjxJb/wDCOf8A
CNx+Zv1q2TUvlQ7bE7vOPzdP4eRz6V11ABRRRQAVx/w88Q6jr/8Awkv9o6YumfYdbubK22xNH9og
TbsmO77xbJ+YcHHFdhXI+AbjxJcf8JH/AMJJH5ezWrlNN+VBusRt8k/L1/i5PPrQB11FFFABXHfE
TxBqPh630B9N0xdUe71uysp1aJpPIgkkCyTDb0KDnceB3rsa5H4g3HiS3ttCPhqPzZn1qzS/+VDt
sTIPtB+b0TuOfSgDrqKKKACiiigD80P2pf2YPjB40/aM8eeIvDnw/vNd0LVLi0ls7+DU9PhWRUsL
WFwUmuY3BEkTjlR0yMg15d/wxz8e/wDok+p/+DnSP/k2v18CnOTzS4IryKuVYSvN1Jx1Z+hZfx9x
BleGhg8LX5acFZK3Q/IL/hjj4+f9En1P/wAHOkf/ACbR/wAMcfHz/ok+p/8Ag50j/wCTa/YCisP7
FwP8h6P/ABE7ij/oJ/BH5Q/Db9kX436b8UvAmo6h8Nb3TdO0/wASaVf3l3Pq2lukMEN7DLK5WO7Z
2wiMcKpJ6AV+rXBHBoxg9zSgewr08PhqWFhyUlZN3Pis6zzH5/iFiswnzTSST8l/w7PH/DnwQvtF
+NmoeKZtTt5vCiT3up6VogRttpqF5DaRTypGfkjZTa3kolT5pG1m9BCfO1wfDzwF488CaV4a8CWt
5pFl4E8Mw21paa/b3DzatqFnbqqw2stq8HkwsUVEluFlk3qkhjit2mQ23sdFdZ4J4P8AAH9nuy8F
Saj4l8XeAvBFn8RJvEGr6rHr+iIt7d+Ve3U84U3clrBKGRLl7fGCCkYOQHKKuufBvxVdeGPFfw1s
jpDfDvxZNqkt9rdxdyrq9jFqU8097bxWwhMUzF7icRTtLGIllj3wzmBvtHu9FAHk/wASvC/jf4h6
xZ+Hzpfh/T/BlvrWk6v/AG7/AGzPLqLfYry3vvL+w/ZFjG+W38nd9p+VX8zDEeUfWKKKACiiigAo
oooAKKKKAPKv2lf+SdaR/wBjn4T/APUh06vVa8p/aVI/4V3pHP8AzOfhP/1IdOr1XNAC0UmaM0AL
XI+DrDxBZ+I/Hc2s3Pnadd6zHNoieYG8myGnWSOmP4f9JS7bB/v5711ucVxngnw/Povib4g3kurp
qEer67Few2yOWNgi6ZYwGBgT8pLQNLgY4mB7kkA7SiiigArkfiBo+v6wPDv9g3v2L7LrNtc3/wC9
MfnWa7vNj4B3Zyvyng4rrcj1riviX4dj8RDwtv1iDSPsOvWl8vnHH2opuxAvI+Zs8denQ0AdtRRR
QAUUUUAcj4E0fX9JufFDa5em8ju9amudNHml/JtDHEEj5Hy4ZZDtHHPvXXVxHw68PJ4evPGLprEO
qnUdenvmWE5+yFooV8huThhsz2++OK7bI9aAFooooA5H4gaPr+sDw7/YN79i+y6zbXN/+9MfnWa7
vNj4B3Zyvyng4rrq4n4l+HY/EQ8Lb9Yg0j7Dr1pfL5xx9qKbsQLyPmbPHXp0NdrmgBaKTNGaAFrk
fAmj6/pNz4obXL03kd3rU1zpo80v5NoY4gkfI+XDLIdo459663OK4n4deHk8PXfjF01iHVTqOvT3
zLCc/Yy0UK+Q3Jww2Z7ffHFAHb0UUUAFcj8QNH1/WB4d/sG9+xfZdZtrm/8A3pj86zXd5sfAO7OV
+U8HFdbketcV8S/DkfiIeFt+sQ6R9h160vl844+1FN2IF5HzNnjr06GgDtqKTNGaAFopM0ZoA5L4
f6Pr+jjxF/b179t+1azc3Nh+9Mnk2bbfKj5A24w3yjgZrrq4n4a+HY/Do8U7dYg1f7dr13fN5Jz9
lL7cwNyfmXHPTr0FdrketAC0UmaM0Acl8QNH1/WB4d/sG9+xfZdZtrm//emPzrNd3mx8A7s5X5Tw
cV11cT8S/DkfiIeFt+sQaR9h160vl844+1FN2IF5HzNnjr06Gu1oAWiiigArkfh/o+v6OPEX9vXv
237VrNzc2H70yeTZtt8qPkDbjDfKOBmutrivhp4cj8OjxTs1iHV/t2vXd83knP2UvtzA3J+Zcc9O
vQUAdtRSZozQAtcj8QtH1/WLbQl0C++wy2+s2dzenzTH5tokgM0fAOdy8bTwa63NcV8TvD0fiS08
OI+sQ6OLPXrG+DzHH2gxyhhAvI+Z+g6/Q0AdtRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUU
UUAY3iPxVofg+0S817WdP0S1bzNs+o3SW6Hy4ZJ5MM5A+WGGaRvRInY8KSOU8UfFPb/wj1h4KttP
8X674jspdU0lH1H7Pp0thF5Pm3b3aRzYi/0m3VfLjkZ2njwojEksfAftQ6JBc+M/gTrCeD9P8Ya1
pvjOZ7S0uhCk5QaNqU7rBLKpVZd1tDKisyI00EG6SIKJEreEvh34t+H48N+Nh4duNa1K0m8VNdeF
bO5tkvkt9a1hNRjKySSrbtPB5MMckfmiM75mjmfykWcAtaj8e/iVa6tpGjp8KdPsdV1DxNN4ZjXW
/E0ltbzPHpI1H7XbyxWM3nWz+VdxK21XBij3ojvLHBah/aA8VN4s8OeGpfBejpq0/ix/CeuFPEMr
W9jL/ZQ1ZJrV/sQa6U2e7IdYCJgE5Q+aMr4p+F/GvxQvfhWNa8H6wmmx+LJdUvYvDetpp93oWnnT
bq0iW5u472KSScy3ayyC0LKqLLEDNsV7nq/Evwci8K2HhTUvBun3Go3fhjxA/iKexvNQkuL7W2fT
7mwkVr26kZ3nWG5Hlmdyp+zQwl4Y8SRAFq++Kni5Pin4x8IaZ4KsNUj0bRtO1Sxu110xS3b3s88E
azRPbhYIo2tLp5HWSVxGiGOKV38td/4ZePr7xpF4jsdZ0m30bxD4c1IaXqdtYXjXtp5rWtvdo0E7
RRPIphu4clokIfzFAYKHbi4D4z0288efFO28Bahc+INR0bTtI0rwLLqNlHey/Y5rx1knuRM1tD5k
l++VSSXbFAr5aSQwR6v7O9h4gsfC2tt4m8Mah4e1q71qe9ubrVZ7SS61R5Uika4ZbaedYYkZmtYY
WnmeO3tLdS5AGADB/bN8XWfgD4C3fijUIriex0PxB4d1S4itVVpXjh1uxkdUDMqliEIALAZxkjrX
h/8Aw95+D5x/xTHjjH/XjZf/ACXXov8AwUt/5Mr+IP8A100v/wBOdpX4j44HNfvnhrwXlPFOFxFX
MVK8JJLllbRq/Y8rGYipQklHqfrn/wAPevg9/wBCz45/8AbL/wCS6P8Ah718Hv8AoWfHP/gDZf8A
yXX5F4o21+1f8Qg4Y/ln/wCB/wDAPO+v1vI/XX/h7z8HyP8AkWfHP42Nl/8AJdeyfsj/ABZ8J/HT
SPiF498HprEFprHicNeWmtwRRSQXEWmafBtQRyOGQxxRPktnLsMcCvwm5zX63f8ABH3/AJN08X8f
8zlcf+kFjX5L4jcC5PwxlVPGZepKUpqLvK6s1J9vJHfg8VUrTcZdj7rFLRRX85nrkfevG/2pPGnh
j4beANK8W+Kv7Uks9F12xura10iON7i5ufM2Rx4kZVx+8LEll4U85wD7L05618s/8FI5dPX9mK7W
9jke5bW9LFky9Em+1RkluenlCUd+SPqMq0nGnKS6JnbgKMcRi6VGe0pJP0bMsf8ABTT4bkD/AIpf
xmP+3Wy/+S6X/h5p8Nv+hX8Z/wDgLZf/ACXX5vcUce9fnD4gxl+n3H9px8HuGmk/3n/gS/8AkT9I
f+Hmnw2/6Ffxn/4C2X/yXR/w80+G3/QseM//AAFsv/kuvze496OKX+sGM8vuK/4g7w1/08/8DX/y
J+tH7KnxH8L/ABX8OeNPEXhSDWbaC68TTm8h1uOJJUuTbWzkJ5TuDHsaIjJzksD0r3LrXxv/AMEv
zj4OeOsdf+Ewl6/9g3T6+xgcjuK/RMLUdWhTqS3aT+9H8bZ5hKWAzTE4OhflpzlFX3sm0vyJaKKK
6TxjxP8Aav8AH/hP4T/DXT/GvjE6rJpuga3Y3sNro0Uclxc3HmbI4wJGVcfOWOWXhDg5wD4L/wAP
efg+cf8AFMeOMf8AXjZf/JddX/wVJewT9j/XBexu9y2qaaLJk6JN9pQktz08oSjvyR9R+MOOBzX7
94bcFZTxRhK9XMFK8JJK0raNX7HlYzEVKMko9T9c/wDh718Hv+hZ8c/+ANl/8l0f8Pevg9/0LPjn
/wAAbL/5Lr8i8Uba/aP+IQcMfyz/APA/+Aed9freR+uv/D3n4Pkf8iz45/Gxsv8A5Lr2b9kL4teD
/jb4Q8X+LfBcWtW9je+Jrg3kGuxQxyx3Rt7dmCCJ3Ux7GjIJYnJbPSvwk5zX63f8Eff+TdPF/H/M
5XH/AKQWNfkviNwLk/DGVU8Zl6kpSmou8rqzUntbyR34PFVK03GXY+6xS0UV/OZ64wDFeRftMeKP
DvgbwZofiPxGupTxaZ4g0+ays9JSNp7q7aXy4oh5jKgBMhJLOoAU89j67mvnP9u6XT0+Cemrexu9
y3inRBZFeiTfboiS3PTyhKO/JH1HLiZulRnOO6Tf4HJi6kqOHqVIbpNr5ImH7aOhEDPgXxgD6bdO
/wDkyl/4bR0L/oRfGH/fOnf/ACZXzfRX88vxCzdP4Yfc/wD5I/lN+KmeptclP/wF/wDyR9If8No6
F/0IvjD/AL507/5Mo/4bR0L/AKEXxh/3zp3/AMmV830Uv+IhZv8Ayw+5/wDyQv8AiKuffyU//AX/
APJHsPgL9qvwj4Zu/FMGneD/ABtdSXWtTX92JU039zPMkchQYuxkbWQjr97BOQQOtH7aGhY/5EXx
h/3zp3/yZXyZ4TP/ABP/ABn/ANhaP/0gtK6WuzF8e5tRqKEYw2i9n1in/N5nfjfE3O8PVUIRp/DF
/C/tRTf2u70PpD/htHQv+hF8Yf8AfOnf/JlH/DaOhf8AQi+MP++dO/8Akyvm+iuP/iIWb/yw+5//
ACRwf8RVz7+Sn/4C/wD5I9u8TftK+E/Hms+DLDUPC/jHSwnibTmtrlksDEt1JOsEIlC3Lt5ZedQS
qkjr2NfU+cHn07V+b9wf+Kg8FHH/ADN/h7H/AIN7Sv0eBJAJ5z1FfrfCecYnO8FLE4lLmUmtFZWS
T7vufunA+f4viPLZ4vGpKSm4+6rKyUX1b7ktFFFfbH6INJr4j8Tft9/CT9mv4k+O/BVzpvjDWNSj
1uW9v7mztLV7cXE0cbvHGXuEYhOFOV6hsEjBP22eK/Bz9ud9Ok/a/wDiodMjkit/7UjV1l6mYW0I
mPU8GXzCPYjp0r9F4ByLB8Q51HA45PkcW9HZ3Rx4qpKlT5on6Af8Pevg9/0LPjn/AMAbL/5Lo/4e
9fB//oWfHP8A4A2X/wAl1+Re2jbX9Q/8Qg4Y/ln/AOB/8A8X6/W8j9dT/wAFePg9/wBCz45+n2Gy
/wDkuqyf8FFPg/8AHXxf4H8Jx6N420++uvE2mGymks7NYvtP2hFhEpFwzCMuyhiqkgV+SZ616H+z
j/ycb8JP+xy0X/0vgr57PvC3hzL8qxOMoqfPThKSvPS6Ta6GtLG1ZzjF21Z/QsOlLRRX8dH0IUUU
UAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAc54k+H/hbxjq2janr/AIZ0fW9S0Sb7Tpd7qVhFcTWE
u5G8yB3UmJt0cZ3KQcop7CujoooAKKKKACiiigD5f/4KXH/jCv4g/wDXTS//AE6WlfiMCMe9fvZ+
154Y07xp8Fv+Ef1i2N3o+r+J/DNhe24keMywS67YJIu9CGXKsRlSCM5BBriv+HZv7OH/AET6f/wo
9V/+Sq/XOCOPP9UKFal7D2ntGnva1lY4MThfrDTbtY/EbNGa/bj/AIdm/s4f9E9n/wDCj1X/AOSq
P+HZv7OH/RPZ/wDwo9V/+Sq/Tf8AiN//AFB/+THF/Zr/AJj8SMiv1u/4I/f8m5+L/wDscrj/ANIL
CvSv+HZv7OP/AET6f/wotV/+Sq7b9mn4b+FvhHH8RfB3g3wqfC+g6V4mURhru5uTfNJpenzPcF7h
3brKYsKdv7n13V+e8aeIn+tuXwwX1fk5ZqV732TVvxOvD4T6vJyvfQ9sooor8YPRG4zXyv8A8FJL
+2sv2Y7qO4tFuZLrW9Lht5TjMEn2qNy446lUdO33zX1OeOgryv8AaI8LWHjrwZpPhTWPDzeJNC1z
XLGz1G3WS4iaGES+aJ1kgdHjKPHGdwYDseDis6kfaQce6OrB1/quIp17X5Wn9zufjzj3ox7iv1L/
AOHd3wE/6FDU/wDwqtY/+S6P+Hd3wE/6FDU//Cq1j/5Lr4r/AFa/6efgf08vG5JJfU//ACY/LTHu
KMe9fqX/AMO7vgJ/0KGp/wDhVax/8l0f8O7vgJ/0KGp/+FVrH/yXS/1a/wCnn4D/AOI3/wDUH/5M
cL/wS95+Dvjrp/yOEv4f8S3T6+yAO3evG/2aPh1onws0bxroPh3wzL4a0qHxLcGJJrq7uXvALe3U
XBkuZJGbIVU+U7f3fAzmvZV57EfWvs6FL2NKNO9+VJfcj+ac1xv9o4+vjbcvtJylbtdt2/EfRRRW
55h8h/8ABUq/trP9kHXIri0W5lutT02G3lOMwSC6Ry446lEdO33zX4xAjHvX9AH7RvhPTviD4J0z
wjrnhw+J/D2v63Y2WpWnmTxmKAS+b5wkgdHQo8SHduA7HIOK82/4dm/s4f8ARPp//Cj1X/5Kr9d4
J49/1QoVaPsPac7T3taysefiML9YabdrH4jZozX7cf8ADs39nD/ons//AIUeq/8AyVR/w7N/Zw/6
J7P/AOFHqv8A8lV+mf8AEb/+oP8A8mOP+zX/ADH4kZFfrd/wR+/5Nz8X/wDY5XH/AKQWFelf8Ozf
2cf+ifT/APhRar/8lV237MPwy8PfCHQPGfhvwr4Ubwpotv4luDDCbi6nN2Ps9uv2gvcSOxyFC/Kd
v7vgZzn89408RP8AW3L4YL6vycs1K977Jq34nXh8J9Xk5Xvoe2UUUV+MHoja+cP279QtrL4J6ZHc
Wi3Mtz4p0SG3lbGYJPt0Tlx7lUdO33zX0djHrXl37QPh+08Y+FNH8NajocmvaPrGu2FtfRQzXEEl
vGsomWdJbd0kjaOSKNgwYAd+DWFal7anKnfdNHNiKXt6M6V7cya+8+O6K+nv+GIfhL/0DfEv/hba
3/8AJlH/AAxD8JP+gb4m/wDC21v/AOTK/F34bXd/rH4H89Pwju7/AFr8D5hor6e/4Yh+En/QN8Tf
+Ftrf/yZR/wxD8JP+gb4m/8AC21v/wCTKP8AiG3/AFEfgL/iEf8A1FfgfHfhPH9v+NMEE/2tHken
+gWldNXtvw7/AGPvhprk3iqS/wDC/iHSnt9cuLSJo/F+uxtdxRrGkc7E3nzkqAu7phABwK7D/hiL
4S/9A3xLj/sdtc/+TK6cR4ee3mp/WOkVt2SX6Hbi/Cv6zUU/rVrRitv5YqP6HzFRX09/wxF8JP8A
oG+Jv/C21v8A+TKP+GIfhJ/0DfEv/hba5/8AJlc3/ENv+oj8Di/4hH/1FfgfKtzxr3grnH/FYeHv
/TvaV+kI6DjFfMvij9ln4f8AgLWPBOqaL4Y1zVbpfEunki88UazeRWwSXzVuDE90yHy5I42G9SuQ
MivpofQ1+jcO5L/YWElhefmvJu/qkv0P1vhTh3/VnAywftOe8nK9rbpL9B9FFFfUn2g0jpX4N/ty
31rqH7X3xTltLRbKJdUjhaJcYMiWsKSPwOrurOfdu9fvJzXyzefsefCb9oHxv428XeP/AIdO3iF9
bksjdpqmpWgu4IIoooZvLjnVMlFUblUA7c9cmvsuEeIv9WMyjmHs+eyate25zV6Pt4ct7H4mZozX
7cf8Ozf2cP8Aons//hR6r/8AJVH/AA7N/Zw/6J7P/wCFHqv/AMlV+8f8Rv8A+oP/AMmPM/s1/wAx
+JPXpxXof7ORH/DRnwkx1/4THRf/AEvgr9dD/wAEzv2cBn/i30//AIUWq/8AyVWNrP7DPwW+E2ve
C/EnhL4aSz61a+JdNMcz6zqlwLQC4VvtGw3JU+WVDfOCvHIIrx828YFmeX18EsJb2kJRvfa6tc0p
4Dkkpc2zPruiiiv5tPYCiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigDyr9
pX/knWkf9jn4T/8AUh06vVa8q/aV/wCSdaR/2OfhP/1IdOr1WgAooooAK5Hwdf8AiC88R+O4dZtv
J0601mOHRH8sL51kdOsnd8/xf6S92uT/AHMdq66uR8HWHiCz8R+O5tZufO0671mObRE8wN5NkNOs
kdMfw/6Sl22D/fz3oA66iiigArkfH1x4kt/+Ec/4RuPzN+tWyal8qHbYnd5x+bp/DyOfSuurkfiB
o+v6wPDv9g3v2L7LrNtc3/70x+dZru82PgHdnK/KeDigDrqKKKACiiigDkfAtx4knuvFA8RR+XEm
tTJpXyoN1j5cWw/L1+cyctz+lddXI+BNH1/SbnxQ2uXpvI7vWprnTR5pfybQxxBI+R8uGWQ7Rxz7
111ABRRRQByPj648SW//AAjn/CNx+Zv1q2TUvlQ7bE7vOPzdP4eRz6V11cj8QNH1/WB4d/sG9+xf
ZdZtrm//AHpj86zXd5sfAO7OV+U8HFddQAUUUUAFcj4FuPEk914oHiKPy4k1qZNK+VBusfLi2H5e
vzmTluf0rrq5HwJo+v6Tc+KG1y9N5Hd61Nc6aPNL+TaGOIJHyPlwyyHaOOfegDrqKKKACuR8fXHi
S3/4Rz/hG4/M361bJqXyodtid3nH5un8PI59K66uR+IGj6/rA8O/2De/Yvsus21zf/vTH51mu7zY
+Ad2cr8p4OKAOuooooAKKKKAOR8A3HiS4/4SP/hJI/L2a1cppvyoN1iNvkn5ev8AFyefWuurkfh/
o+v6OPEX9vXv237VrNzc2H70yeTZtt8qPkDbjDfKOBmuuoAKKKKAOR8fXHiS3/4Rz/hG4/M361bJ
qXyodtid3nH5un8PI59K66uR+IGj6/rA8O/2De/Yvsus21zf/vTH51mu7zY+Ad2cr8p4OK66gAoo
ooAK5HwDceJLj/hI/wDhJI/L2a1cppvyoN1iNvkn5ev8XJ59a66uR+H+j6/o48Rf29e/bftWs3Nz
YfvTJ5Nm23yo+QNuMN8o4GaAOuooooAK5H4g3HiS3ttCPhqPzZn1qzS/+VDtsTIPtB+b0TuOfSuu
rkfiFo+v6xbaEugX32GW31mzub0+aY/NtEkBmj4BzuXjaeDQB11FFFABRRRQAUUUUAFFFFABRRRQ
AUUUUAFFFFABRRRQAUUUUAFFFYXizwpp3jXRZtJ1Vbl7GZlZxaXk1pJlSCMSQujjkdjz0NAG7RXl
P/DMXgL/AJ4eIP8Awq9V/wDkmj/hmLwF/wA8PEH/AIVeq/8AyTQAv7Sv/JOtI/7HPwn/AOpDp1eq
145qf7KHw21e3SC+sNbuoUmiuFjl8U6qwEkUiyxv/wAfPVXRGB7FQau/8MxeAv8Anh4g/wDCr1X/
AOSaAPVqK8p/4Zi8Bf8APDxB/wCFXqv/AMk0f8MxeAv+eHiD/wAKvVf/AJJoA9Wri/BPh6fRfE3x
BvJdWTUI9X12K9htkcsbBF0yxgMDAn5SWgaXAxxMD3JPO/8ADMXgL/nh4g/8KvVf/kmqdl+yh8Nt
Pur+a2sNcgmvphcXTp4p1UGaQRpEHb/SeTsjjXPogHagD2KivKf+GYvAX/PDxB/4Veq//JNH/DMX
gL/nh4g/8KvVf/kmgD1auK+JfhxPEQ8K79Yh0j7Dr1pfL5xx9qKbsQLyPmbPHXp0Nc9/wzF4C/54
eIP/AAq9V/8Akmql9+yj8N9T8j7Vp+t3H2eVZ4vN8Uaq3lyL911zc8MMnBoA9horyn/hmLwF/wA8
PEH/AIVeq/8AyTR/wzF4C/54eIP/AAq9V/8AkmgD1aivKf8AhmLwF/zw8Qf+FXqv/wAk0f8ADMXg
L/nh4g/8KvVf/kmgDf8Ah14dTw/eeMXTWIdVOo69NfMsJz9kLRQr5DcnDDZnt98cV29ePWf7KPw3
057hrTT9btmuZTPMYvFGqr5khABdsXPJIAGT6Crf/DMXgL/nh4g/8KvVf/kmgD1aivKf+GYvAX/P
DxB/4Veq/wDyTR/wzF4C/wCeHiD/AMKvVf8A5JoA6H4l+HE8RDwrv1iHSPsOvWl8vnHH2opuxAvI
+Zs8denQ12tePX37KPw31PyPtWn63cfZ5Vni83xRqreXIv3XXNzwwycGrf8AwzF4C/54eIP/AAq9
V/8AkmgD1aivKf8AhmLwF/zw8Qf+FXqv/wAk0f8ADMXgL/nh4g/8KvVf/kmgD1auI+HXh1PD954x
dNYh1U6jr018ywnP2QtFCvkNycMNme33xxWB/wAMxeAv+eHiD/wq9V/+SaqWf7KPw3057hrTT9bt
muZTPMYvFGqr5khABdsXPJIAGT6CgD2GivKf+GYvAX/PDxB/4Veq/wDyTR/wzF4C/wCeHiD/AMKv
Vf8A5JoA9WriviX4cTxEPCu/WIdI+w69aXy+ccfaim7EC8j5mzx16dDXPf8ADMXgL/nh4g/8KvVf
/kmql9+yj8N9T8j7Vp+t3H2eVZ4vN8Uaq3lyL911zc8MMnBoA9horyn/AIZi8Bf88PEH/hV6r/8A
JNH/AAzF4C/54eIP/Cr1X/5JoA9Woryn/hmLwF/zw8Qf+FXqv/yTR/wzF4C/54eIP/Cr1X/5JoA6
H4aeHE8OjxVs1iHV/t2vXd83knP2UvtzA3J+Zcc9OvQV2tePWP7KPw30z7R9l0/W7f7RK08vleKN
VXzJG+87YueWOBk1b/4Zi8Bf88PEH/hV6r/8k0AerUV5T/wzF4C/54eIP/Cr1X/5Jo/4Zi8Bf88P
EH/hV6r/APJNAHQ/Evw4niIeFd+sQ6R9h160vl844+1FN2IF5HzNnjr06Gu1rx6+/ZR+G+p+R9q0
/W7j7PKs8Xm+KNVby5F+665ueGGTg1b/AOGYvAX/ADw8Qf8AhV6r/wDJNAHq1FeU/wDDMXgL/nh4
g/8ACr1X/wCSaP8AhmLwF/zw8Qf+FXqv/wAk0AerVxXw08OJ4dHirZrEOr/bteu75vJOfspfbmBu
T8y456degrnv+GYvAX/PDxB/4Veq/wDyTVSx/ZR+G+mfaPsun63b/aJWnl8rxRqq+ZI33nbFzyxw
MmgD2GivKf8AhmLwF/zw8Qf+FXqv/wAk0f8ADMXgL/nh4g/8KvVf/kmgD1auK+J3h1PElp4cR9Yh
0cWevWN6GmOPtBjlDCBeR8z9B1+hrnv+GYvAX/PDxB/4Veq//JNVL79lL4b6mkK3en63crDKk8Ql
8Uaq2yRTlXGbngg8g9qAPYa4v4t/Fbw58EfAGo+M/F13JYeHdOe3S7uooWmMQmnjgVtigsQHlXOA
TjPBrnf+GYvAX/PDxB/4Veq//JNeX/tL/sP6N8WPgr4g8KeE7i90rX9Re0EF5q/iDUrq2iVLuGSU
tE8zq58tH2gr97byv3gAfQPgX4h+Gfib4dg17wlr1h4i0if7l5p1ws0ee6kg/Kw7qcEdwK6Wvl79
kT9gbwZ+ySJdS07VtW8QeKrqHybvUri4eC3de6pao2zb3HmeYwPRhX1DQAUUUUAFFFFABRRRQAUU
UUAFFFFABRRRQAUUUUAFFFFABRRRQB538WvGOt+HZvB+i+HJLCz1rxTrTaRBqOq2r3dvZbLG7vWk
e3SWJpdy2TRBRLHgyh8sE2Nb+D/jW+8e+C/7R1OKCPUbTU9T0a6e0Vkhnlsb+4snnRGZjGsjW5kE
ZZygcKXfbvap8WvB2t+IpvB+teHI7C81rwtrTavBp2q3T2lve77G7smje4SKVotq3rShhFJkxBMK
H3rb+D/gq+8BeC/7O1OWCTUbvU9T1m6S0Znhglvr+4vXgR2VTIsbXBjEhVC4QMUTdsUA7miiigAr
zzw5451zUfjh458IX9jp9vo2j6No+p6bc28ryXFx9rkv45TMCqqmGsgqou7gbi5L7I/Q68x0Hwn4
qs/2hfGHii7s9Hj8Kap4f0vSrOeHUZXvjLaTXkpaS3NuqKrHUJFyJmI8hDg+aRGAenUUUUAFc34z
TxVcaVFB4SuNHsNSlmAkvtbgluobWIKzFxbxvGZ2LBE2+dEFEhfc3liOTpK4b4uxePbjwbJb/Dld
ITxFcTRxNdazevara25P72SFltrgGfaMRiSNo1Zg7rIEMUgAfB/xrfePfBf9o6nFBHqNpqep6NdP
aKyQzy2N/cWTzojMxjWRrcyCMs5QOFLvt3t3NcN8F/DmreDfhh4f8Paxpuj6PcaVC1jbadoN3cXd
paWUTslnEs9wqyystusKvIyrucOQACBXc0AFFFFAHjo+IvinT/jxpfg691DwxqCarDd3/wDwjmmx
SjUtJ0uHckepT3Ty7JVkm8iHyFt42DXTbJJVtJXf2KvJ9S8L+N/G3xN8LXmt6XoGieHPCetXOr2N
3p+sT315qO6yu7KOOW3e0hS3yl6ZWZZZdrRBAGD+YvrFABRRRQByHxI8cnwJodvPb2X9ra1qN7Bp
elaWJfLN3dTNtUEhWYRRrvnmdEdo4IJpNjCMg1fgh41vviV8GvAXi7U4oINS1/w/p+qXUNorLCks
9tHK6oGZiFDOQASTjGSetJ49+D/hz4k6ppWp6yNYg1LS4bi2s7zRdev9JmSKdoWmjL2k8RdWa3hO
1iRmMEYqr+z/APDi4+D/AMD/AAH4Lvbj7Vf6FotrY3cy3c1yjzpGolMbzfP5W/dsUhQibVVUVQoA
PRKKKKACvEfAPxN8WeNvjN4j0m5vrDw9oOmXtzFaeHNW8LX9tquoWsAWB7yG9lnS3miNyd4NvFMq
wzW3mNHJMAvt1eYy+E/FXjb4haJqfiaz0jRtD8J6ncaloy6VqEt5c6jK9tcWaPciS3iW3VYLqYmJ
DMWkdCJVWEicA9OooooAK88+NPxh0z4L+FrXUr2P7XqOqXqaVpFhll+23rpI6Q7lR2GVikbCJJI+
3ZDFNM8UMnoded/FrwdrfiKbwfrXhyOwvNa8La02rwadqt09pb3u+xu7Jo3uEilaLat60oYRSZMQ
TCh96gGt8LvEFx4p8DaZqd3rWn6/dzeaJr7TNMm02Lesro0TWs0sssEsZUxSRyPvWSNwyoQUXrq4
b4P+Cr7wF4L/ALO1OWCTUbvU9T1m6S0Znhglvr+4vXgR2VTIsbXBjEhVC4QMUTdsXuaACiiigDxG
w8T/ABT074x+D/Duuan4QmsNbstS1e80zT9HuklsbW2EEZjjv3uyLiVbi9s13NaRLJGs74iYJG3t
1cN4a8F31h8TvG3i3UZbcvqkOn6Vp0dqzYXT7VJZVaYMvE5ub2+BKkqYlt+AwcnuaACiiigDzz40
+MNd8EeFrW+0aTT9Oge9SLUdf1a1e7s9DtdkjNeT28csTyRb1iiYiRFhWYzyMIoZK1fhdr2ueJ/A
um6n4i006Zqs3mho/Ie386NZXWG58iQmS386JY5vs8hMkPm+U5LoxOV8YPB2ueKrPw1d6Cmn6hd6
FrUWrtomr3L21lqeyGaOOOaVIpSnlTSxXaN5UmJbSLAU4kS18G/BV98Pvh7p+iahJbm4imup1tbJ
ma20+Ka5lmisbcsqkwW0ciW8Z2RgxwJiOMYRQDuaKKKACvB/Dfxm8Van4z8P3N0ukHwn4j8Wax4Q
s9Mhs5UvrKXTxqWbuS7MxSZZDpUn7kQRlPtKfvH8o+b7xXiPhr4Ao/xkl8eavB/ZEemXl3Pomg6R
r99cae084kSXU5rZ/Lt4rmSOaZTHDFhWuLmR5bh5laEA9uooooAK88+P3jrXPhj8DvHnjDw3ZWGp
a1oGjXWqQW+qSvHbt5MbSMXKKWbCqzBBt3kBd8YbevodeefH/wAH658RPgf478J+HI9PfWfEGjXW
kwHVLp7e3j+0RtC0jukUrfIrs4UIdxULlQdwAKnxF8V+KR4+8M+CvCN3pGjalq2majrMmq61p8uo
wpFZy2UJgFvHcW53O1+jeZ5uFEJXY28MnQfCjx0fif8ACzwb4yFj/Zg8RaLZav8AYvN837P9ogSX
y9+1d23fjdtGcZwOlcr4w8MeN7jxT4N8c6LpegXniTTNGvtJvtB1DWJ7azX7Y9jNJJFeJaSO/lvY
BFVrdPMWYsTGU2N1Xwo8Cn4YfCzwb4NF9/aY8O6LZaR9t8ryvtH2eBIvM2bm27tmdu44zjJ60AZX
xI+Ltn8N/F/w60G40zUL+XxlrMmkRzWdncTJabbSefzHaKJ1GWiRdrsmEaWXOyCUjldK/az+GLxa
dAfHWn+JNU1b+0bvS7Tw1p11d3F9a299JbEwW0Imln2FWXzIwVmFvcTxqIkfy974y+C/FXiu98Aa
j4Rm0iHU/DviB9Rkk1sy+SsUmm31kXCRrmVka8STyt0QkEZXzYtwceWfDP4V/GDwj450zXNR0HwQ
1vYQ+LmWK28U3jtLLrGpx6nEh3aYoVY5IEgZuSVkaQLlBEwB6/oHx8+Hvic6jJpnizT7iwsLKTUn
1RmKadNaxY8+4t7xgILiKEsqzPC7rCzKshRiAasf7RHgeTS7i9a61e2uIZorf+x7rw7qMGrzNIsj
RmHTntxdTKyw3DB44mXbbXBziGUp4ra/s1/ETV/APgbwTrA8MabpumfC3Vvh5qeq2Oq3N3NHLdxW
sKXMFu1pEJVVdPhYo0sZzcSKCfJDS6r/ALPuvWXh5l0D4TfCjwhcTanbyz6Z4Z1a90ecxRW90v2m
LWLKzhmin33CRhFt8CE3amRhc7YwDoJ/2nLRR8Qtbu9a8P8Ah34fab4N0TxToPii8iuJ/Nj1D7cq
S3NufJc/PbRKltGfMfIAffKI4/StS+MnhPSfGSeGLrULhNRM8NrJOmnXMljbXEoUw2896sZt4J5P
Mh2QyyLI/nwbVPnR7vFfGvwR+LHiLSvilprXHhjxBP4q+HWn+DItfvtRmsZrq9iW8W4vZ7WKzdIF
c6lcOI45HwbeNeBKTD3/AIX8J/EXw142129t7TwvHp3i3U7PXNYuZNRuZptMlSws7Se0t4BboLlW
Wx+S5eWAqZ9xgbytkoBvy/HrwLBrt/pdzrn2A2JuRLqd9aT2+ls9urvcxR38iLayywrFOZI0lZ4/
s8+5R5Mm3W+HvxP0H4oWeqXGgvqH/Ervf7PvbfU9Ju9NuLefyYpwjw3UUcgzFPE4O3BDjBNeFW37
MV7oereMZtM+H3wp1TUr+bxBqVr4r8Q2DXOoajLqDXciWV1EtupigVrsQvKLiYyQQMoiXzv3PsHw
V8JeJPBvhW6tPEl55kk1689np/8Aa9zrH9mwFI18j+0LpVuLvdIss2+VQU8/ylykSEgHodFFFABR
RRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFF
FABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUU
AFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQA
UUUUAFFFFABRRRQAUV4l4t+MvjfSPilr/hPR/Cvg+Ww0yy0m9TVfEHjCfTftH9oT3FtBF5a6dMBK
bi1kjC7zu3w4JZyi9poPxCmOlyXfi2HSPB9xZeH7PWtYsZ9ajnm0hpVnM63BCqiwRmBwtxv2yGOb
5UEeWAO5orxzxj+094OsfhL498b+B9V0f4oP4R0yTUrzTPDOt2kzKqo7DzJBIREu2ORiSCxWN9iS
MAh9joAKKK8c+Jfx2v8A4a/GfwJ4Tu/DlvceGPE0ErTeIl1Jlm06Vbm2tI0a08k+YstzqGnwqyyZ
BndnVUiLEA9jorxz4i/Hi+8J/GzwF8OdF8OW+uXGvzBdUv7nUms10iJ4bqaBwghkNw0sem6ltVSo
VrZQ7IJUau08OfFbwR4w0N9c0Hxl4f1vRVvY9NbUdN1SC4txdSNGkduZEcr5rNNCqpncTKgAywyA
dfRXIQfFfwPc+FbPxNF4x0CXw3eef9m1hNUgNnP5KSyTbJg+xvLS3ndsH5VhkJwEbC3PxF0SD+z7
/wDt3QB4cu9Fudc/tSXVkXdaxeQ32mIYKSWwSfc8/mBY8w8MJcqAddRXNwfEHwte6Vr2p2/ifR59
N0Ca4ttXvIr+JodNlgXdPHcOGxE0a8urkFRycVV8C/FbwR8UPt3/AAhvjLw/4t+w7Ptf9hapBe/Z
9+7Z5nlO23dsfGcZ2tjoaAOuorm7L4g+FtQ8Z3/hC08S6RdeK7CEXN5oUN9E99bREIRJJAG3opEs
Z3EAfvE/vDPm3wZ/aQt/jp421m18LweH9X8Gaf8Aa4W1vTPEsN3ewzw3It41uLFE/dRXOy5lglWW
QPFCGYIZAoAPbaK88039oP4W6x/ZX2D4l+EL4ateNpun/ZtdtZPtl0PLzbw4kPmSjz4couW/ex8f
MM8rB8cfF+sadoHibQfhx/b/AIC8Q3unQ6ZqdlqxOo/ZLq4hjGo3FkbfEVsIZHnG2WSUL5XmxQZm
NuAe20V8++GP2g/G95pNr4g8SeA9A0vwu3iZvCtxPpfime+vY7r+1jpKukD6fCjxG62kkzKwiJba
WHlm0P2gfFNv+zr48+Jd94L0eLUvC02sKdFt/EMssN1FplxLBcv9pNkpRma2uDGvlMGAi3Mm9vLA
PeKK5zUvGNl4M8Gpr/jfUdI8KQQQwtqNzc6iq2NpK5VSguZViDL5jBFZlQtlflBOKqax8WPBHh/Q
rTXNT8ZaBpui3lkNSttRvNTgitp7UtCguEkZwrRbrm3XeDtzPEM5dcgHXUV5l8e/jlpXwK8A6vrl
wlvq+u2+mXuo6d4bGo29pd6mtrF5tx5IlYFlij/eSFA7KgJCO21G77U9VstFt0udQvLext3mhtkk
uZVjVpZZFiijBYgFnkdEVerMygZJAoAv0V55rHxk0STwroeq+Ebuw8aTeJb1tL8PDTL9Gs7+6VJp
HDXSb0jijS2uHkcBmCwOqJJLsifgPFXx5+Jfg+LUIL34U2EN/Z3ug2K3MviWQaXfPql9LZg2t0ti
zv5D/ZDKskMbjzpCFKrE1wAfQVFfPvir9oPxv4Pi1DS73wJoEvi+xvNBjksoPFM5sDa6tfS6fayi
6OniTzVuYW8yIwBRGQ6yO2Yx3+s/ELXNM+OHhjwPDoOn3Gi6vo1/q8usyao8dxb/AGSW3ieNbUW7
K+WvLXDGZeDKSAUUSAHodFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRR
RQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAfPmqfBvT/iH+1NrfiHxb
8Nvt2l6do2g/8I/4rvTZt5F/Y313dv8AZykxuostc24OURZPs0qvlNnmcD8ftG1fwz49+JfiWy+H
2oC11f8A4QaHT9Zs5NOVNT1m010eSXjNyssuDeWaYl8gSJaSx+fAPKlr7Bqhq2l2XiDSr3TNTsrf
UdNvIXtrq0u4llhniddrxujAhlZSQVIIIJBoA+V7qz8SeKfgb8f/AArL4a1i5+LvinTJLu+0F4bC
xWQ3th/ZdnPABqFxDHBs09t6vdvLut522gSQofqjSb2bUdLsrq4sLjS554Ulksrto2mt2ZQTG5jd
0LKTglHZcg4YjBOV4K+H/hb4b6TNpvhLw1o/hbTJZjcyWeiWMVnC8pVVMhSNVBYqiDdjOFA7Cuko
AK8I+Mvw81H4nfFvTNFu/Durv4K1PwP4i8Nar4jsbmyRbRtRey2hUkl80sEspBuELqGmh+8PM2e7
0UAfGnin4Y/FzXrPQtb1rwFo/iPx5q3iC8m1a3kmt7jQdOtYtBvNHtoZTNOs82nzXF1Jf+RGjPHH
eXalDN/ruK+Jvw78Xa03ifUfGngXX/E9pqF54GtdKuPie/h4o11B4ieOS1YaWJBHFLDqZTzPIdtj
3KtkFEf9AK5vxr8P/C3xI0mHTfFvhrR/FOmRTC5js9bsYryFJQrKJAkisAwV3G7GcMR3NAHyv488
E6j/AMLB8EeOdV+HFvf65rPxSbWdM8PaxLZNqVtbxeFZIXQTK0sCTmXSluIlWby2aO13ywsC0XK/
FT9n/wAYaroGr28XwfuPE2p+IfCfjO0kuIp9IzaXWr62upaVBcNPdIWazZXd2j8xI5ZMwtLlmH2l
4k8AeFvGOr6NqWveGtH1zU9Em+06XealYRXE1hLuRvMgd1JibdHGdykHKKewrpKAPjP4v2eu+Hbv
xJqtj8LtY0LQm03wBpnh6CKXS1hi1C014yQ2ogju8bYpNQt0Me6KOQW06LcQq0U59e/Z01C7/tHx
xaeJ7PUNK+IWoXtt4g1qxvLS3tovLlt1sbWa3S3vLxEiZNLZSrXLyeZFKxCJJEtev6tpdl4g0q90
zU7K31HTbyF7a6tLuJZYZ4nXa8bowIZWUkFSCCCQayvBXw/8LfDfSZtN8JeGtH8LaZLMbmSz0Sxi
s4XlKqpkKRqoLFUQbsZwoHYUAeL+FPh34ttfGPhPRbnw7cW2m+GfHPiDxfJ4ie5tmsb23vxq/k28
CLKbjz1/tWEOJYY4x5E+2RsR+Z2n7N9hr+leANUt/EXhjUPCt/J4m13UI7PUZ7SZ3gvNTub2Fw1t
PMg+S5VGBYEOj8FdrN6xRQB4P4W+EPiHTfjXJJdpbn4d6Rqep+JdEiWUbo9R1CGFHI/5aMySza/I
6yExhdTtwm8x7ba18KbDx34B8L+DvhlB4Z8m08L2Vlpc/jO8ngk06/srZEjDW9vHP9pFzNGqApKi
Rws0rCW4EKLc+3UUAfOfwB+CEM1jqOu+M/DHijQtdbxZq+sQ6NrfiWS608rPqU97aTiwt72ayDIJ
ojygZZ4TIPmCSsniD4deLW+Hnjv4P2vh64vNN8YTa60fjVLm2WxsLfVrm5uJjPA0ouDPB9qmRI4o
3jm2QFpoPNk+z/RtFAHmPx10nxLqHh3RrjwvZXF1f2Opi5ll0mKwfWLaI288Rk0434+ypOWlRHab
A+zyXQX94yA/O/wY+Gni3wv8TfCnifxF8GfEF9qehWfjHd4i1GXw89/cSX+q/b7HDQ3gCymFruFt
qxxpJeuBtieR1+1qKAPhS/8AgZ8RZ/2cr/wtL8Mf7Y1nXvhPpHgw6bqOpWCxaZqWlrqH76Z/NdTv
a6hktWi8z95GvnG1A8xfaP2t/Dp8YfAfRote8LeH9b1pfE3heRdH1GX7RYC6k1iyhkiE725bymWa
WFpfJ3GOV8x4YofoOub8a/D/AMLfEjSYdN8W+GtH8U6ZFMLmOz1uxivIUlCsokCSKwDBXcbsZwxH
c0AeL2fw78WX2qX3xCPh64sdSj8cDxha+Ery5thfT26+H00WS3aWOV7dJz++njHmtG2IUkkh8x2h
T43WvxB+KHwsmgb4f6wlvd+INClh8O6fqdpba1bW1pqMN3eXM12t8kMTOkBSFLeZnQ+W5kBlZbb6
NooA8c8T/s/adB4JvrHws1w2utqek6wt54j1i91Ga7bTr+G9gtJLu5eaaOBnidBt3rEbiWRYmZmV
7fhnTte8efFPS/HGr+GNR8E2miaNf6Nb6ZrFxaT3l495PZTSTH7LPNFHFGLGNV/eM7tLJlIhEjTe
sUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQB//9k=
------=_Part_343555_1040962665.1324366204520
Content-Type: image/jpeg; name="fig2.jpg"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="fig2.jpg"

/9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAMCAgMCAgMDAwMEAwMEBQgFBQQEBQoHBwYIDAoMDAsK
CwsNDhIQDQ4RDgsLEBYQERMUFRUVDA8XGBYUGBIUFRT/2wBDAQMEBAUEBQkFBQkUDQsNFBQUFBQU
FBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBT/wAARCAEjAh8DASIA
AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA
AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3
ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm
p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA
AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx
BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK
U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3
uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD9U6KK
KACiiigAooooAKKKKAI8Hd2xWYNe0/8AtO6sPttv9tt40llt/NXeiOWCMVzkBijgE8Eo2OhrUK5B
r518U+FdO8QfHHx9oH9rato/iDX/AAtYLY3VheXZNs6y32bgRxyKFRGhgyflXc5TINwwfKcmrWV9
Tsw1GnV5ud2sr6eqX5XZ9Bi8gBP7+PjrlxTluYjIF81CT0AYc18c22oa/wCNJIPsWn+JdCXxpZJ4
f03zNb1A/wBk3tp5P2qVt7riVMXWVk2NL/ZMuC32pq7XxBfSaH8QL3S4dW1KPxPZ63pFloGmSapO
Xn0lkshdy/ZmkIulAe/LXDpI6mNzvBiBTJVnLVI9CplsabUXPV+ndLv0d18mfSUk8cAzI6Rg9Nxx
R50e/Z5ilz/DuGfyrwb9pzW0sP8AhHtOn1q8tGvYLvy9L0zUJdPvrt18lRJaSRg+dcx+ZtjtG+SZ
pwT/AKsVm+L9cuYPihq8H9rX1v4tTX9Kt9D0lL6SMT6U4svtci2YcJOgD3+6YxuU8t8MvkjZbqNN
qxz08EqkIycrXv8Ag0v1ueo618afCmgeLrXw3f6g0Oo3NwloknkObYXDoXSBp8eWkrIAyxswYhlI
B3LnX8dePdK+HmjQ6nq/202ktxFaqbGxmu382Q7Y12xKxG5iFBIwWZVzlgD8t+MNK8HX958WdUOs
3gbTfG+iG8aPxHdRx20byaasrOizhE2utyoYgGMxbVK+UoX2n4++LdK0/wCFmj6lf3S6VZ3Wt6HL
G2pD7I+BqFvMwZZdrIyxo7FWAKhGJA2nGUZztK/yO6eDwqnQUL62UtV1UXp23e99vktaf4/+FbTV
dSsJ49cibS7k2t9dSaHeLa2jbVYmWcxeWiBGVzIzBNjB87SDXReK/iBpfg57eO9F9d3VzuaKz0qx
mvrhkXG5/JhVn2KWQF8bQXQEgsoPz5qOmyePPFHxZfSfEN/qGm22v2tvr3hXTfIlW7sW0+1guQcR
tOrjZNkRtub7NJHGFlO9e/s/iT4c0Dx7qfjTUNYsIfCuvaPYWena19qi+xzT21xfedF527YHAmQh
SQWw+0N5cm0jOeql338rir4PCx5HTu3ZNq+t2k7babt9T1Xw94l0/wAV6THqOnytJbybgVdSkkbK
xV0dDhkdWVlZGAZWUqwBBFVvBvjfRfH2hw6voV9Hf6fLJNHFcRn5ZGikaNyvPzLuRgGGQwGQSCCe
W+FJOp6j458RwIW0jXNWju9NnI5uYFsLSDzVHUoZIZNrdHUB1JR1Y+KfDbxzomla14R1Cw8Xm4Ov
eM9d06S1Gpo9s1u0l9NHFFEG2bmlezkEmDIftCKH8t0SrdSSa/rsc8cHTnGok7NWt/4C21+Fr/5n
1iLqE7j5seF6/MOPrR9pi2qwlTDfdO4YNfCy+I9R03wnp+pat8YrvTdYubnS11rTrMtHJZ3Ul5b+
dHdPcTzx27xobs+QkUAbypNyNHC6L6N8UdHvdA8aW2iQ+Pb7wXpVrplvLov26S+v7m9vZJ7jzlgH
2uNryVNtt+5kFx/rI1CAPteY1pP7PY3qZZRg1++urtba6WXzu3p5eeh9VDkUtNQYRRz079adXWfP
hRRRQAUUUUAFFFFABRRRQBHg7u2KzBr2n/2ndWH223+228aSy2/mrvRHLBGK5yAxRwCeCUbHQ1qF
cg186+KfCuneIPjj4+0D+1tW0fxBr/hawWxurC8uybZ1lvs3AjjkUKiNDBk/Ku5ymQbhg+U5NWsr
6nZhqNOrzc7tZX09Uvyuz6DF5ACf38fHXLinLcxGQL5qEnoAw5r45tr/AF/xpJB9i07xNoS+NbJP
D+m+ZreoH+yb208n7VK291xKmLrKybGl/smXBb7U1dr4gvpND+IF5pcGranH4ns9b0iy8P6ZJqk7
PPpLJZC7l+zNIRdKA9+WuHSR1MbneDECmSrc2qX9f8MehUy2NNqLnq/Tul36O6+TPpKSeOAZkdIw
em44o86Pfs8xS5/h3DP5V4N+05riWH/CPadPrV5aNewXfl6XpmoS6ff3br5KiS0kjB865j8zbHaN
8kzTgn/VCs3xfrtzB8UNYgGrX1v4tTX9Kt9D0lL6SMT6U4svtci2YcJOgD3+6YxuU8t8MvkjZbqN
NqxzU8GpwjJyte/4NL9bnqOtfGnwpoHi618N3+oNDqNzcJaJJ5Dm2Fw6F0gafHlpKyAMsbMGIZSA
dy51/HXj3Svh5o0Op6v9tNpLcRWqmxsZrt/NkO2NdsSsRuYhQSMFmVc5YA/LfjDSfB9/d/FnVDrN
4DpvjfRDeNH4juo47aN5NNWVnRZwibXW5UMQDGYtqlfKAX2n4++LdK0/4WaPqV/dLpVnda5ocsba
kDaPgahbzMGWXayMsaOxVgCoRiQNpxlGc7S/D7zvqYPCqdBQvrZS1XaL07bve+3yWtP8f/Ctpqup
WE8euRNpdybW+upNDvFtbRtqsTLOYvLRAjK5kZgmxg+dpBrovFfxA0vwc9vHei+u7q53NFZ6VYzX
1wyLjc/kwqz7FLIC+NoLoCQWUH581HTpPHfij4svpPiK/wBQ0221+1t9e8Lab5Eq3di2n2sFyDiN
p1cbJsiNtzfZpI4wsp3r39n8SfDmgePdT8aahrFhD4V17R7Cz07WvtUX2Oae2uL7zovO3bA4EyEK
SC2H2hvLk2kZz1Uu+/lcVfB4WPI6d3om1fW7SdttN33PVfD3iXT/ABXpMeo6fK0lvJuBV1KSRsrF
XR0OGR1ZWVkYBlZSrAEEVW8G+N9F8faHDq+hX0d/p8sk0cVxGflkaKRo3K8/Mu5GAYZDAZBIIJ5b
4Uk6nqPjnxHAhbSNc1aO702cjm5gWwtIPNUdShkhk2t0dQHUlHVj4p8NvHOiaVrXhHULDxebg694
z13TpLUamj2zW7SX00cUUQbZuaV7OQSYMh+0Iofy3RKt1JJr+uxzxwdOcaiTs1a3/gLbX4Wv/mfW
IuoTuPmx4Xr8w4+tH2mLarCVMN907hg18LL4j1HTfCen6lq3xiu9N1i5udLXWtOsy0clndSXlv50
d09xPPHbvGhuz5CRQBvKk3I0cLovo3xR0e90DxpbaJD49vvBelWumW8ui/bpL6/ub29knuPOWAfa
42vJU2237mQXH+sjUIA+15jWk/s9jepllGDX766u1trpZfO7enl56H1UORS01BhFHPTv1p1dZ8+F
FFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUU
UUAM6DNZHinxFa+FtGl1G8LC3R44yUXJy7qi8fVhWwTgGuB+OPPw3vh0/wBKsv8A0qirKo3GDkui
Z14OnGviadKezaT9G7HfqcqD6ilpkX+qT6CnGtUcjMbxR4itfCujS6lebhbo8cZKruOXdUXj6sK1
1OQD6iuB+OBJ+HF7kY/0qy/9Koq72Mny0+grJP33Hsl+p1ypRWGhVW7lJfJKLX5sdVLUtNttZ0+5
sb62hvLK5jaGa3uIw8cqMCGRlPDKQSCDwQaujp0oxWvkce2qZheFvDb+GLCS1Orajq8fmloTqciS
SQR4AWISBFaRVx9+UvISSWdjW4QfwpQCD1pCCfpQtNhybk7sfRRRQAUUUUAFFFFABRRRQAUUUUAF
FFFABRRRQAUUUhoAToM1jaX4jttU1vWNMh3G40x4458rjl0Drg9+GFbIzzXn/gcf8XM+Imc/8fNn
/wCkqVlJ8ril1f6M66FKNSnVlLeMU1680V+TZ6FRRRWpyGJpniO01XWdX0yEsbjTHjjnyuBl0Drg
9+GFXNS0221nT7mxvreK8srmNoZ7edA8csbAhkZTwykEgg8EGuM8ED/i5vxEP/TxZ/8ApKld+e39
KyhLmi793+Z14qmqFVKH8sX83FN/izD8K+G38MWElqdW1HVo/NLQnU5EkkgjwAsQcIrSKuPvyl5C
SSzsa3CD+FKAQetIQT9K1WmxySbk7sfRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFF
FABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRXAfGjxdqPgrwhp+oaXIsdzN4k0DTXaRA4MF3q9pa
zjB7mKeQA9iQR0rv6ACiiigBp71wXxy/5Jvff9fVl/6VRV3p714r4+vvEN34c+JUWtwGHTbXxJp0
OhuYwvm2Rg013YEfe/0p7tcnn5cdAKxq/wAKXo/yPQy7/faP+KP5o9pi/wBUn0FPpkX+qT6Cn1qt
jge5wHxz/wCScXv/AF9Wf/pVFXdxfcT6D+VcJ8c/+ScXv/X1Z/8ApVFVzx7e+I7JPC//AAjsTS+b
rVtFqO2NX22R3eaxz0A+Xkcisl/FfovzZ6E/9ypf4p/lA7OiiitjzgooooAKK4/4e3viO9PiX/hI
omi8rW7mLTt0apusht8phjqD83J5NdhQAUUUUAFFcf8AEK98R2R8Nf8ACOxNL5ut20Wo7Y1fbZHd
5rHPQD5eRyK7CgAooooAKKK4/wCHt74jvT4l/wCEiiaLytbuYtO3Rqm6yG3ymGOoPzcnk0AdhRRR
QAUUVx/xCvfEdkfDX/COxNL5ut20Wo7Y1fbZHd5rHPQD5eRyKAOwooooAT1rz/wR/wAlM+In/XzZ
/wDpKlegetef+CP+SmfET/r5s/8A0lSsam8fX9Gejhf4WI/wr/0uB6DRXH/D298R3p8S/wDCRRNF
5Wt3MWnbo1TdZDb5TDHUH5uTya7Ctjzjz7wR/wAlM+In/XzZ/wDpKlegDpXn/gj/AJKZ8RP+vmz/
APSVK9AHSsaXwv1f5s9DH/xo/wCGH/pERaK4/wCIV74jsj4a/wCEdiaXzdbtotR2xq+2yO7zWOeg
Hy8jkV2FbHnhRRRQAUUVx/w9vfEd6fEv/CRRNF5Wt3MWnbo1TdZDb5TDHUH5uTyaAOwooooAKKK4
/wCIV74jsj4a/wCEdiaXzdbtotR2xq+2yO7zWOegHy8jkUAdhRRRQAUUUUAFFJketGaAFooooAKK
TI9aM0ALRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAHlX7Sv/JOtI/7HPwn/wCpDp1eq15V+0r/AMk6
0j/sc/Cf/qQ6dXqtABRRRQA0968X8f6f4hs/DXxIm1m487TrvxHp02iJ5gbyrIQ6cjpj+H/SUu2w
f7+e9e0HvXiHjnw9Po3h74n3kurJqMereJ9OvYbZHLGwRbbTIDAwJ+UloGlwMcTA9yTjV/hS9H+R
6GXf77R/xR/NHt0X+qT6Cn0yL/VJ9BT61WxwPc4D45/8k4vf+vqz/wDSqKr/AI7sPEN/H4Z/4R65
+zeRrFtNqPzhfMshu81OeucrxVD45/8AJOL3/r6s/wD0qiq18QvDs/iKPwqINXj0n7Drdrevvcr9
pRN2YBgjJbPT2rJfxX6L82ehP/cqX+Kf5QO1ooorY84KKKKAOR8B2HiKwufFB1+5+0x3GtTTaYN4
by7IxxBE46YYSHHvXXVxnw88PT+H7rxa0+rx6r/aGuTXsao5b7IjRRKITknBGwnH+1XZ0AFFFFAH
JeP7DxDf/wDCOf8ACPXP2byNatptR+cL5lkN3mpz1zleK62uM+I/h248RDwwINXj0n7Drlrevvcr
9pRN2YBgjJbPT2rs6ACiiigArkfAdh4isLnxQdfuftMdxrU02mDeG8uyMcQROOmGEhx7111cZ8PP
D0/h+68WtPq8eq/2hrk17GqOW+yI0USiE5JwRsJx/tUAdnRRRQAVyXj+w8Q3/wDwjn/CPXP2byNa
tptR+cL5lkN3mpz1zleK62uM+I/h248RDwwINXj0n7Drlrevvcr9pRN2YBgjJbPT2oA7OiiigBPW
vP8AwR/yUz4if9fNn/6SpXoHrXn/AII/5KZ8RP8Ar5s//SVKxqbx9f0Z6OF/hYj/AAr/ANLgangC
w8Q2H/CR/wDCQ3P2nz9auZtO+cN5dkdvlJx0xhuK62uM+HHh248OjxOJ9Xj1b7drl1epsct9mR9u
IDknBXHT3rs62POPPvBH/JTPiJ/182f/AKSpXoA6V5/4I/5KZ8RP+vmz/wDSVK9AHSsaXwv1f5s9
DH/xo/4Yf+kROT8f2HiG/wD+Ec/4R65+zeRrVtNqPzhfMshu81OeucrxXW1xnxH8O3HiIeGBBq8e
k/Ydctb197lftKJuzAMEZLZ6e1dnWx54UUUUAFcl4AsPENh/wkf/AAkNz9p8/WrmbTvnDeXZHb5S
cdMYbiutrjPhx4duPDo8TifV49W+3a5dXqbHLfZkfbiA5JwVx096AOzooooAK5H4haf4i1C20FfD
tx9mli1qzmvj5gTfZLIDOnPXK8Y7111cX8SvD8/iK08PpBq8ekm01yxvXaRyv2hI5QxgGCMl+gHe
gDtKKKKACkPSlpDQB8vfEf8Aaw8UeF/iZ4p8MaJ4K0nU7bQbmG0e9v8AXJbV5ne0guTiNLWQBQLh
VyXySp4HFYX/AA2T8QSf+Sd+Gh/3M9x/8g15/wDFD/k4D4tf9hu0/wDTPp9Y1fgGf8WZpgMyrYah
NKMXZXR/LvE/HGdZXm9fB4aolCL00v0PWf8Ahsn4g/8ARPPDX/hT3H/yDR/w2T8Qv+ieeGv/AAp7
j/5Bryaivnv9eM6/5+L7j5b/AIiRxD/z9X3Hr+k/tk+L28RaBZ6t4B0S30/U9WsdKlnsvEM0ssJu
rmK3V1RrNQ+1pVJG4ZAPOa+tl4X1+tfm/cDOv+Cuv/I4eHun/YXtK/R8H8fSv2Xg/NMVm+AlXxUr
yU2traJJ/qf0BwDnWMz3K54nGyvNTa2tolF/qSUUVyMvxX8EW3im78MS+MdAi8SWfkfadHk1SAXk
HnPFHDvhL718x7iBFyPmaaMDJdc/dn6WddRXnnhb9oT4W+ONdtdE8OfErwf4g1q6LfZ9O0zXrW5u
Jtql22RpIWbCqzHA4Ck9BVqz+N/w61LwdfeLrXx94YuvClhMLa816HWLZ7G2lJQCOScPsRiZYxtJ
B/eJ/eGQDuaKxdN8V6JrR0r+z9Z0+9/tWybUtP8As10kn2y1Hl5uIcE+ZEPPhy65X97Hz8wztUAF
FFFABRRRQAUUUUAeVftK/wDJOtI/7HPwn/6kOnV6rXlX7Sv/ACTvSP8Asc/Cf/qQ6dXqlAC0UUUA
NPevDfGekaPpuhfFe40zVP7QvdQ8Vabc6pb4x9huRaaXEsPvmCK3l/7bV7l614Z4z/4R3+w/iv8A
2N9o/tH/AISnTf7b87O37b9k0vZ5f+z9m+ydP4t9Y1f4UvR/kehl3++0f8UfzPcov9Un0FPpkTAx
pyOgp2R61qjge5wPxz/5Jxe/9fVn/wClUVS/EnR9H1iPwj/a+qf2X9l160urPgH7Tcrv8uH/AIFk
/lUPxyIPw4vcHP8ApVn/AOlUVS/Eo+HfL8I/8JD5/wDyHrT+zvs+f+P35vK3Y/h+9msl/FfovzZ6
E/8AcqX+Kf5QO7ooorY84KKKKAOI+Guj6PpN34zbSdU/tN7zxBPdXy4x9luTFCGh/BVQ/wDAq7eu
H+G3/CO/avGf9gfaPM/4SCf+0/Pzj7b5UO/Zn+Hb5ePfNdvmgBaKTNGaAOJ+J2j6PrH/AAif9r6p
/Zf2XxBaXVnwD9puV3+XD/wLJ/Ku3rh/if8A8I7jwn/wkP2j/kYLT+zvs+f+P35/K3Y/h+9mu4oA
KKKKACuI+Guj6PpN34zbSdU/tN7zxBPdXy4x9luTFCGh/BVQ/wDAq7bNcR8Nv+Ed+1eM/wCwftHm
f8JBP/afn5x9t8qHfsz/AA7fLx75oA7iikzRmgBa4j4naPo+sf8ACJ/2vqn9l/ZfEFpdWfAP2m5X
f5cP/Asn8q7auI+J3/CO48J/8JD9o/5GC0/s77Pn/j9+fyt2P4fvZoA7iikzRmgA9a8/8Ef8lM+I
n/XzZ/8ApKlegetef+CP+SmfET/r5s//AElSsam8fX9Gejhf4WI/wr/0uBa+GOj6Po//AAln9kap
/an2rxBd3V5wB9muW2eZD/wHA/Ou3rh/hh/wjuPFn/CPfaP+Rgu/7R+0Z/4/fk83bn+H7uK7fNbH
nHn/AII/5KZ8RP8Ar5s//SVK9AHSvP8AwR/yUz4if9fNn/6SpXoA6VjS+F+r/NnoY/8AjR/ww/8A
SInE/E7R9H1j/hE/7X1T+y/sviC0urPgH7Tcrv8ALh/4Fk/lXb1w/wAT/wDhHceE/wDhIftH/IwW
n9nfZ8/8fvz+Vux/D97NdvWx54tFFFABXEfDHR9H0f8A4Sz+yNU/tT7V4gu7q84A+zXLbPMh/wCA
4H5122Qa4j4Ynw7jxZ/wj32jP/CQXf8AaP2jP/H78nm7c/w/dxQB3FFFFABXEfFLR9H1m08NrrGq
f2VHb+ILC6tWxnz7lJQYof8AgbcV29cR8Uv+Ed+yeGv+Ei+0eV/wkFh9i+z5z9t80eRux/Du60Ad
vRRRQAUh6UtIelAHwD8Tzn9oD4tjuNbtB/5R9PrG719Z+MP2UPhr4+8W6t4m1jS9X/tnVJI5LyXT
/Eup2KTOkMcKsYoLlIwfLijXIUEhRnNZI/Yi+EuOdN8S/wDhba5/8mV+T5twN/aeNqYxV+Xmd7WP
w7PPDb+2Mwq476xy87vax8xUV9Pf8MRfCT/oG+Jf/C21v/5Mo/4Yi+En/QN8S/8Ahba3/wDJleR/
xDb/AKiPwPB/4hH/ANRf4Hyrc8a94K5x/wAVh4e/9O9pX6QjoOMV4fpP7G3wq0bWNM1WHStblu9N
vIL+2F54s1e6iWeGVZYnMUt0yPtkRGAZSMqOK9vB9j7Zr9G4dyX+wsJLC8/NeTlf1SX6H63wpw7/
AKs4GWD9pz3k5XtbdJW/A+V/BPiDx9e/FjRfh7dfE3xBfazofibWrrXp57DSVt9Q0aCCxntbZWSy
VhLt1XSQ5VYyS+o4fC2xrf8AhNpXgzWf2avgrb+ObG3v9WSbSblI54nkvl8URN5tzIQgMou0ukvH
uWPzLtuzPhBMa9+TSrOHVLjU47G3TUrmGK2nvFiUTSxRtI0cbPjLKjTSlVJwDI5GNxzlWXw+8Laf
4zv/ABfaeGtItfFd/CLa812GxiS+uYgEAjknC73UCKMbSSP3af3Rj6k+0Pnf4aeF/G/xD8J3fh/+
y/D9h4Mt/iZq2r/27/bM8uot9i8W3F95f2H7IsY3y2/k7vtPyq/mYYjyia9iP9jT476I5261Je+N
dNTTW4uGur7Ub57C3Ef3jLcLeWjQpjdKLmEoGEiZ+iPBXw+8L/DfSpdM8JeGdI8LabLMbmSz0Swi
s4XlKqpkKRqoLFUQbsZwoHYUXvw+8Lah4zsPF934a0i68V2EJtrPXZrGJ762iIcGOOcrvRSJZBtB
A/eP/eOQDz/X9Ksof2ufAupx2NumpXPgfxDbT3ixKJpYo9Q0Zo42fGWVGmlKqTgGRyMbjn2Subvf
h94W1DxnYeL7vw1pF14rsITbWeuzWMT31tEQ4Mcc5XeikSyDaCB+8f8AvHPSUAFFFc3408d6N8Pt
Miv9ZnuFjmmFtb21jZz3t3dSlWby4LaBHlmYIkjlY0YqkcjnCoxAB0lFeOP+1j8NFjt2t9U1jU3n
1OXRBBpfhrVL2ZNQjtY7uW0kjhtneOdIZNzROAymOZSA0MqpqxftE+CJbrw3bLdax9s1/U30a0tH
8O6itxFerGJjBdRG332jeSwnH2gR5hzKMxguAD06iuGl+MnhK28ZeI/DN3qFxp+peHNMTWNVnv8A
T7m2sbWyYErO17JGtuVOyTpIf9TN/wA8pNu/4T8UaX448LaP4k0S6+26NrFlDqFjc+W0fnQSoJI3
2uAy5VgcMARnkA0AcD+0p/yTrSOv/I5+E+v/AGMOn16ofY145+1frFt4d+EUOrXplWy0/wAUeGry
cxQvK4ii12wkcqiAs7bVOFUFicAAkgVl/wDDa/wvI4m8Sn3/AOET1Qfzt64q+Mw+Gdq01H1Z5+Jx
+FwjUcRVUW+7se8fNR81eE/8NsfC7/nt4m/8JPVP/kej/htj4Xf89vE3/hJ6p/8AI9c39q4D/n9H
70cn9t5b/wBBEfvR7qeF4r5d+Lfxu8B+HW+JHhyfytD19PENiL1mPOoyraabN5//AAGB4Ysdf3I9
RXVj9tb4XjOJ/Ep/7lPVP/kevlr9qn47fDH4x+D/ABTLPJdeHtQ0DXYf7M1Sbw5qKLd28lpZiU3L
C3/duXdkCtyVt4TjDqTnPHUsTB0sJUjKb0Sve99LfPp5n0nDmcZHPNKH12uvZpq/K1da6Pr1sfev
gTx9ofxE0GPWfD16uoaezmJZ4/u7l6jPtXTk49/TFfHXw3/bw/Zk+GXgXRvDGl+OpxZ6bbrCG/4R
/UQZG6vIf9H6sxZj7k10w/4KXfs6DH/FeT5/7AGpf/I9fbU+H865Fz4Opfr7kv8AIyxVXC+3n9Wl
7l3y3ava+l/O252H7S/xX8MeC/CraJrGpx2WpXb21xDDJgGSNblCzDPXAU/lWtqXxW8GeLvD3hHW
LaBfEmnXniG1sbKeM/LBdndtlB77OenrXyN+1j+0/wDAH9ojwbptjoHjWWXxbZXkf9nK2gakDMJW
VJIci2z82VYAclkUDrXqelftSfCz4T+A/BnhzQLTWL7T9Ou7W1mlvvC+oxeWjEh7hc24zKXbgDli
+ACTivlsbHE5VjXRzGPsuZJxUk4yer6PzuerjsyyGhk+Hp+1tiXOV02rWtHVaX1srfM+wOaPmrwn
/htj4Xf89vE3/hJ6p/8AI9H/AA2x8Lv+e3ib/wAJPVP/AJHrm/tXAf8AP6P3o+L/ALby3/oIj96P
dvmo+avCf+G2Phd/z28Tf+Enqn/yPR/w2x8Lv+e3ib/wk9U/+R6P7VwH/P6P3oP7by3/AKCI/ej0
H4baxo+rXfjNdJ0z+zHs/EE9rfNn/j6uRFCWm/FWQf8AAa7TdngYr5J0j/goz8FtH1TxFYeI9bm8
NXcGpOIYf+Ef1FZbiExRsk8q/Z8q7biMHnCqehFa/wDw8t/ZzH/M+T59f7A1L/5Hr6zDZPmWMpRr
4fDTnCWqahJpryaWp6cK9KcVOElZn1BRXzB/w8u/Zz/6H2f/AMEGpf8AyPR/w8u/Z0/6H2f/AMEG
pf8AyPXV/q9nH/QHU/8AAJf5Fe2p/wAyPafibrOj6P8A8Ip/a+l/2p9q8QWlrZ84+zXLb/Lm/wCA
4P5129fKUv8AwUM+DHjDxP4O8PeFteTxBq+r69ZackF3o97AIvOfyxKryQBQ4ZkAyR96vqwZxXk4
rBYnAz9niqcoSetpJp2+ZpGUZ6xY+iiiuUobnjoa4j4baxpGr3fjNdJ0v+zHs9fntr5s/wDHzciK
EtN+Ksg/4DXbY46n8a+arz9tr4afD7xr4x8L+LbmbQdY0rV3gMNlo95cefGYonSZ3ihZd7B+mc4C
nuKznOFNc03Y6cNhcRjJ+zw8HOXZK7/A+laK+b/+HhfwN/6GXU//AAndR/8AjFH/AA8L+Bv/AEMu
p/8AhO6j/wDGKw+t4f8A5+L70er/AKvZx/0CVP8AwCX+R9I/55rifibrOj6P/wAIn/a+l/2p9q8Q
WlrZ8gfZrlt/lzf8BwfzryQ/8FC/gb28S6n/AOE7qP8A8YrnvF3/AAUP+D8C6P8AYNRuNTzqcCXB
u9Av1+zQkkNMm6Dl142gZJLcUfWqD/5eL7wfD+bRV3hZ2/wy/wAj6xor5v8A+HhfwN/6GXU//Cd1
H/4xR/w8L+Bv/Qy6n/4Tuo//ABij61h/+fi+9B/q9m//AECVP/AJf5H0h+NcB4I/5KZ8Q+3+k2fT
/r1SvL/+HhfwNzx4l1PH/Yu6j/8AGK5Pwx+3P8HdK8aeL9TufEGopZ6nNbPauNCvmLhIFRsqISy4
YH7wGe2axnisPeP7xb912Z6OF4fzdUq6eEnrFfZl/PHyPoX4Za1o+r/8JYNI0s6Z9l1+7trzoftN
yuzzJv8AgWR+VdquTz2ryX9nf41aJ8dPD3iTWvD8UaafZ69caesiW0sDy7Y4pFkkSRFYOySoTx0I
r1tcgYPX2r0IyUlzRPlKtKdGo6VRWktGn0ZwPgj/AJKZ8RP+vmz/APSVK9AHSvP/AAR/yUz4if8A
XzZ/+kqV6AOlZUvhfq/zZ2Y/+NH/AAw/9IicP8TdY0fR/wDhFP7X0s6p9q8QWlrZ8/8AHtctv8ub
/gOD+ddqfY15p8ePijY/CHw3ouv6rZfatLOtWlpcyi1kuHtllYoJUSNWcvuKqoUEkuAOtcn/AMNr
/C8jibxKff8A4RPVB/O3rCtjMPhnatNR9WfP4nH4XCNRxFVRb7ux7x81HzV4T/w2x8Lv+e3ib/wk
9U/+R6P+G2Phd/z28Tf+Enqn/wAj1zf2rgP+f0fvRyf23lv/AEER+9Huo68Zrivhlq+kayPFf9ka
X/Zf2XxBd2t5z/x83K7PMm/4FkflXnv/AA2t8LwP9d4lH/cp6p/8j10nwC+MGmfGTR/E+p6TZNZ2
un67Pp+Hs5rWSXEcMqySRyojh3SZG5XoRXRRxuGxMuSjUUn5M6sPmOExcuTD1VJ9k7nq1LRRXcei
FcR8UtY0fRrTw22saX/asdx4gsLW1XOPIuXlAim/4A3NdvXF/ErxBP4dtPD7waRHqxu9csbJ1kQt
9nSSUKZxgHBTqD2oA7SiiigApDS0hoA/N79q3/go58S/gb+0J4u8CeH9E8LXWkaM1osM+p2lzJcO
ZbSCdizJcIvDSkABegHWvJ/+Hu3xj/6FzwN/4L7z/wCS68t/4KK/8nq/E3/rrp3/AKbLSvnLPNf2
vwZwZw9mGQ4TFYrCRlUlG7bvdv7z5zEYirGrKMZOyPt7/h7x8Yv+hc8D/wDgvvP/AJLo/wCHvHxi
/wChc8D/APgvvP8A5Lr4for7n/iH/C//AEAw/H/M5vrVf+Y/Qr4R/wDBUr4reOfi14G8M6j4f8HR
6brmvWGlXL2tndpKkdxcxxMyM1yyhgHyMqRx0r9Tuh55r+ev9nH/AJOM+Ev/AGOWi/8ApfBX9ChH
Nfyj4p5PgMlzmnh8upKnF002l35pK+voe3gZyqU25O7uPoorzHU/2jPh/o3iFdHvdauLa4l1OHRb
e6fS7v7DdahJcLbraQXnleRNOJWKvFHIzR+VOXCiGUp+Ononp1FeT+Fv2m/AXjC8tYLCfxBbx3N6
2mpfar4U1bT7IXSzGA273VxbRwpL56mAIzhjLiMAuQptW37RPge5+GGvfEJbrWIvCmhTXEGo3Vx4
d1GGaBoH8u4P2d7cTMsT7lkdUKoY5dxHlvtAPTqK88j+O3g19dsNIa91CC6vPsyeZcaNexW9pNcK
jQW13O0IitLlxLDttp2jmJnhGzMsYb0OgD58/as1P+xdX+Ek9/428QeDvC9z4muLDXP7En8hJ7Vt
Jv5S1xKkbSxRIYBumV41hR5Ji0bQxzQ8t4F8WHw/qXw++IPi7Wfs3giysvF+hQeKdYus262sutWh
0aSa6cndFNZWAKXcrFZiYsyvJcR+Z7n48+GKeO/E3gjWm8R6xoz+FNTbVbe000Wphu5Wgktys/nQ
SPt8ma4jxGyHEzHO5Y2TuaAPlP4w/ELQ9Z8T/By98IaxoHhDVNe8fzS6brWu2iSW+u7dAvbX7bFC
lxBLdRMZba1jlLpvJtynmRPAZeg8TeAr74ban4T8beI9Vt9S8vxy/ibxZrFnZNZ2NjEfD9zpMcyw
NLM8UCAWXmM0kgTdNM7RxK3l/RlFAHiXgXxbomu/FP4h/Euw1jT7r4ff8IzpFgvidLpP7Okks59V
nu2SfOx4oku4d0ykxhvMTdvilVLX7Huq2Wtfsp/B+5069t7+3Twnpls0ttKsirLFaxxSxkqSAySI
6MvVWVgcEEV7HRQB4V+2l/yb/qP/AGG9B/8ATxZ18uV9R/tokH9n/Uef+Y3oP/p4s6+XK/BfEn+P
h/R/ofzH4uf7zhP8L/NBRRRX4yfz8FeCfHj/AJJV8Vv+wzYf+i9Or3uvBPjx/wAkq+K3/YZsP/Re
nV+jcAf8j/Df46f/AKdpn3vBv/Izj60//TtM+N6KMUYr/eqHwo/qg6f4Y/8AJSvCH/Yasf8A0ojr
73+IP/IAtf8AsLaZ/wCl8FfBHww/5KV4Q/7DVj/6UR197/EH/kAWv/YW0z/0vgr/AC/+k7/yW+W/
9e4f+nJH4/xr/wAjPLv8X6xOlooor+EZbs/nyXxMKKKKkk+CP2lv+S6eK/8Aftf/AEkgrzQ9a9L/
AGlefjp4r/37X/0kgrzQjmv90/CV/wDGDZT/ANeo/kf2jlH/ACLML/17p/8ApKEooxRiv2A9Q9F/
Zx/5ON+Ev/Y46L/6Xw1/QqOlfz1fs4/8nG/CX/scdF/9L4a/oVB4r+KfGj/kf0f+vUf/AEqR9Jl3
8J+v+QtFFFfgR6g096/Hf9rCW8m/am+KjX0flzDVYFUAf8shY2oiP4xhD+NfsQTX47/tYRXkP7U3
xUW+k8yY6rAykHP7o2NqYh+CFB+FfOZ9/uT9Ufs/hJ/yU0P8MvyPK6KKK/Lz+7AqjrP/AB6R/wDX
xB/6OSr1UdZ/49I/+viD/wBGpXTh/wCLD1X5nj5t/wAi+v8A4Zfky9RRRXO9z1YfCgoopaRZ+if/
AAS7/wCSO+Of+xwl/wDTbp9fZPcV8bf8EvOPg745/wCxwl/9Nun19kZBxzX7Jgf91pf4V+SP81OK
f+R9jv8Ar7U/9KZwHgj/AJKZ8RP+vmz/APSVK9AHSvP/AAR/yUz4if8AXzZ/+kqV6AOldNL4X6v8
2ePj/wCNH/DD/wBIifO/7dM+oQ/BC0Szj8y3l8TaIl623OyH7fCwPt+8WIZ98d6+cK+jv26Yb+b4
IWj2UgS3i8TaI96u7G+H7fCoHv8AvGiOPbPavnGvwvxJ/wB4w/o/0P5S8XP95wv+F/oFFFFfjJ/P
4V9AfsN/8i/8UP8AscP/AHEaZXz/AF9AfsOH/iQfFD/scP8A3EaZX6v4c/8AIzq/4H/6VE/bvCb/
AJHNb/r2/wD0qB9MUUUV/RJ/V4VyPxC1DxFp9toLeHbf7TLLrVnDfDyw+yyaQCd+emF5z2rrq5H4
haf4i1C20FfDtx9mli1qzmvj5gTfZLIDOnPXK8Y70AddRRRQAUUUUAfhn/wUWYf8Nq/E3H/PXTv/
AE2WlfOIr+hXxT+z58LfG+u3Ot+I/hr4Q8QazdFfP1HU9Btbm4m2qEXfI8ZZsKqqMngKB0FZo/ZQ
+CGD/wAWc+H/AP4S9j/8ar91yTxZxuR5dRy6nhYyjTVk23dnmVMDGrNzbtc/n8x7ijHvX9Av/DJ3
wQ/6I38P/wDwl7H/AONUf8MnfBD/AKI38P8A/wAJex/+NV73/Eb8w/6A4f8AgUjL+zYfzM/D79nL
A/aM+EnI/wCRy0X/ANL4K/oTB7V5npP7NPwh8ParZ6lpnwq8E6bqVlMlxa3tp4ds4pYJUYMkiOsY
KspAIIIIIyK9NA/OvyHi3iitxbjY42tTUHGKjZNvZt9fU7sPRVCLgnc+S/AvgrU0+N2n+AZNY8cN
b+Edf1TxJcavd+KNWmXUtPlhtH0+zmR7ggweZdtFGzs6yNoF4NpM9yE6n4HeNPC2l/CX4ZfCvWIo
Nb+IGg6Zo+map4ORYp77S7qzSEPdzwuwEUEEkSzJcnCPiBoGlaa3En0bRXxR1HyR8ANGvvjb4Q1F
7H4geF9U+HVr8RdX1UWOi6c02oCW38Rz6jbKb8XjRbZHW3lx9my0EwCkFllo8UatZaf8A/iz8H7m
8t4Pif4in8XQ6N4VeVRfaiNTvr+aymgjzmSBo7qNnnXMUOyfzXjNvMI/reigD5z+Ovxq8B6h8SvC
fwqvvF2j2OpR+ING1HV7R7tBeIy3cc2m20EYJd55r1LNnURssdqJ3kaHzLd3+jKKKACiiigAoooo
AKKKKAPD/wBr/RrnX/glLpVpdRWF5qHiPw5Zw3U8JnjheTXLFFdowyFwN2SoZc4xuGc15ef2MfiD
nH/C0vDQ/wC5KuP/AJaV7T+0qCPh3pH/AGOXhP8A9SHTq9TwSen515+JwGFxjTxFNSa2ueXi8swe
PkpYqlGbW11sfIn/AAxf8Qv+ip+Gf/CKuP8A5aUf8MX/ABC/6Kn4Z/8ACKuP/lpX17+FH4Vxf2Hl
v/PiP3Hn/wCreTf9AsPuPkL/AIYv+IP/AEVLwyf+5LuP/lpXBa//AME7vFnjvSfGWhXvxc8Prban
qME9w1l4VlaWJ44bUqpB1DEZIhQ7TvJVt2RvAX74wcn36VxXgLSNH03xX8SLjTNTOoXuoa/Fc6pb
hcfYbkaVYRLD75git5f+21dOHy3BYWoqlClGMlazS10d19z1N6ORZZh5c9LDxi9NUuzTX4pM+AP+
HMd5/wBFng/8JNv/AJPo/wCHMd5/0WeD/wAJNv8A5Pr9NfwNHPoa++/1qzz/AKDJ/ez1vY0v5Ufm
ton/AAR/1Lw7rum6rb/GW2e40+6iu41k8JNsZo3V1DAX4OMgZwRx3FepeKv2JPHWp2dlbT/Fjwxb
xtqFrKCfCU8RLRTLMqrnUm3EtGo28ZGcEHmvtfnpiuI+Juj6Rq//AAiZ1fU/7L+y6/aXVngf8fNy
u/y4f+BZP5V8tmc5Z1XjicyftakdE5atJapI4q+WYPEyjOtSi3HZtbHz1/wxf8Qv+ip+Gf8Awirj
/wCWlH/DF/xC/wCip+Gf/CKuP/lpX17+FH4V4P8AYeW/8+I/cef/AKt5P/0Cw+4+Qv8Ahi/4hf8A
RU/DP/hFXH/y0o/4Yv8AiD/0VPwz/wCEVcf/AC0r69/Cj8KP7Dy3/nxH7g/1byb/AKBYfcfmz4n/
AOCUesfEvxbrfiDUPjHpUV5cXCxyR6f4Xdo0McMaAEG/yjYUEqSeuc84Gf8A8OZL3/os0P8A4Sbf
/J9ff/w10bSNJu/GbaTqh1J7zX57q+XH/HrcmKEND+Cqh/4FXbDOe9fd4TiDNcBQhhcLiZQpxVkk
9EuyPahhqNOChCCSSSS7JdPuPzK/4cx3n/RZ4P8Awk2/+T6P+HMd5/0WeD/wk2/+T6/TX8DRz6Gu
z/WvPf8AoMn97K9jS/lR+cXgT/glDc/DL4leCPFUnxcs9QXRtfsNRNlL4eNqbnyLhJvKR/tb4ZvL
wPlPUntX6PdxXEfE3R9H1j/hFDq+qf2X9l8QWl1Z8D/Sbld/lw/8Cyfyrtx+NeHjcwxeYzVXGVXO
SVk3vZdDWMIwVoqw6iiiuEsZivhn4nf8E9tY+K/xX8beMLb4padpsWsan532JtCe+e32wxRhGkF3
FggIPl28AjmvufnHeuI+G2j6RpN14zbSdTOpveeIJ7q+XH/HrcmKEND+Cqh/4FWVSlCrHlqK6OzB
43E4Cqq2FqOE+63Pi/8A4dZeIf8Aor+mf+EfJ/8ALGj/AIdZeIf+iv6Z/wCEfJ/8sa/Qf8KPwrm+
o4b/AJ9o97/WvPP+guf/AIEz89/+HWfiD/or+mH/ALk+T/5Y1m65/wAEt9e8q0if4xaRGJLqIAye
FpIiSHDAL/p53MSo+XjIzyK/Rg5XsSPYVxPxM0bSNY/4RM6xqn9l/ZdftLqz4/4+bld/lw/8Cyfy
prBYaLTVNXInxRndSLhLFzaejV+h8Yf8OsvEP/RX9M/8I+T/AOWNH/DrLxD/ANFf0z/wj5P/AJY1
+g/4UfhS+o4b/n2i/wDWvPP+guf/AIEz8+P+HWXiH/or+mH/ALk+T/5YVhaN/wAE4db1rxFr2jp8
UtPgfSJIo3uG8LSOJt8YcEL9vGzAbHVs4zx0r9IsEE9cVwPgkZ+JnxD/AOvmz/8ASVKyngsMnH92
tX+jO/DcU526VdvFzbUU/i2fNFfqzh/2Q/gHcfs7eB/EmgXfiaz8V3F9r8uom7srQ2qRf6NbQCJo
zJIQwEG4/MfvV7uq4z0riPhno+kaP/wln9kaodU+1a/d3V5gf8e1y2zzIf8AgOB+dduMnsfxr0Yx
UFypWS2PiqtWdepKrUleUndt7tvqcD4I/wCSmfET/r5s/wD0lSvQB0rz/wAEf8lM+In/AF82f/pK
legDpWdL4X6v82dmP/jR/wAMP/SInjv7TfwlvPjN4B07w9p/iO18MXKa1Y6gl3eQGeNzBL5gjMQk
jL7mC/LvXp1FeRH9jH4g5x/wtLw0P+5KuP8A5aV9D/E7RtI1j/hFDq+qf2Z9l1+0urPjP2m5Xf5c
P/Asn8q7XBJ6fnXLicBhcY1LEU1Jra6Pm8XlmCx8lLFUoza2utj5E/4Yv+IX/RU/DP8A4RVx/wDL
Sj/hi/4g/wDRU/DP/hFXH/y0r69/Cj8K4v7Dy3/nxH7jz/8AVvJv+gWH3HyCf2MfiDjI+KXho/Tw
Vcf/AC0r1f8AZm+EGofB7QPFlnqviPT/ABNfatr76jJc6ZZtaRQ4tLa3ERjaWUqwFsGOXPL17KBj
jGB7VxPwy0bSNHPiv+yNU/tT7V4gu7q84x9muW2eZD/wHA/OuvD5dg8JNzoUlFtWul0O7CZTgcDN
1MLRjCT0bS6djuqKKK9I9YK4v4leH5/EVp4fSDV49JNprljeu0jlftCRyhjAMEZL9AO9dpXEfFLR
9H1m08NrrGqf2VHb+ILC6tWxnz7lJQYof+BtxQB29FFFABRRSGgD4L/aC/bn+Ivws+OfjHwdoune
GJdI0aa2it5L+yuZJ38yzt52LMtwqn5pmAAUcAdTXAD/AIKS/FfPGk+Dcen9nXf/AMl15x+2Wc/t
ZfFDH/P5Y/8Aprs68dr83zHMcXRxVSnCo0k9D+1ODOCuHcxyHC4vF4SMqko6tt6v5M+q/wDh5R8W
P+gR4M/8F13/APJdH/Dyj4sf9AjwZ/4Lrv8A+S6+VPwo/CvN/tfHf8/X+H+R9x/xDvhb/oBj98v/
AJI+wvAv/BQv4neI/iH4N0W90nwkNP1fXtP0u4NvY3SyCO4uo4XZGNywDASZGQRx0r9F+V61+Jvw
pP8AxeL4aYH/ADOGhf8Apyt6/bLJJ7Yr7jJK9XFYeU60rtNr8Efyp4pZNgMjzmnhsupKnB002lfd
ykr6t9h9LRXjl/8AtKaTYS6ZeDwr4ou/CeranY6TpXiy0treXTb+a7uoraJ02z+ckBeUsLiWJIZF
QGJ5PNgE30R+PHsdFeJeF/2mo/EMVrfX/wAO/GHhrw/NrLeH31vVH0t7eC/F8dPELpb30sx3XgEA
ZYmXLBiRHlxah/aOtT8FfF3xMufBPiix03w1PqEV5pMx083zrYzPDeSRhLtoisbxXAwZQzeQ5RW3
R7wD2OivMtQ+Ni6Nqmmwat4L8UaRptzNY2N1rN3Dai0sL67aJILR9twZJmMtxBEZbZJoFeQgyjy5
TH6bQAUUUUAFFFFABRRRQB5V+0r/AMk60j/sc/Cf/qQ6dXqteVftK/8AJOtI/wCxz8J/+pDp1eq0
AFFFFABXD+Av+Ed/4Sv4lf2N9p/tH/hIIf7c87O37b/ZWn7PL/2fs32Tp/FvruK4nwDq+j6l4r+J
Ntpml/2fe6f4ghttUuM5+3XJ0qwlWb2xBLbxf9saAO2ooooAK4f4n/8ACO48J/8ACQ/aP+RgtP7O
+z5/4/fn8rdj+H72a7iuI+J2saPo/wDwif8Aa+l/2p9q8QWlrZ8gfZrlt/lzf8BwfzoA7eiiigAo
oooA4f4bf8I79q8Z/wBgfaPM/wCEgn/tPz84+2+VDv2Z/h2+Xj3zXcVxHw11jR9Wu/Ga6Tpf9mPZ
+IJ7W+bOftVyIoS034qyD/gNdvQAUUUUAcP8T/8AhHceE/8AhIftH/IwWn9nfZ8/8fvz+Vux/D97
NdxXEfE7WNH0f/hE/wC19L/tT7V4gtLWz5A+zXLb/Lm/4Dg/nXb0AFFFFABXD/Db/hHftXjP+wPt
Hmf8JBP/AGn5+cfbfKh37M/w7fLx75ruK4j4a6xo+rXfjNdJ0v8Asx7PxBPa3zZz9quRFCWm/FWQ
f8BoA7eiiigArh/if/wjuPCf/CQ/aP8AkYLT+zvs+f8Aj9+fyt2P4fvZruK4j4naxo+j/wDCJ/2v
pf8Aan2rxBaWtnyB9muW3+XN/wABwfzoA7eiiigBPWvP/BH/ACUz4if9fNn/AOkqV6BmvP8AwR/y
Uz4if9fNn/6SpWNTePr+jPRwv8LEf4V/6XAs/DD/AIR3Hiz/AIR77R/yMF3/AGj9oz/x+/J5u3P8
P3cV3FcP8MdY0fWP+Es/sjS/7L+y+ILu1vOQftNyuzzJv+BZH5V2+a2POPP/AAR/yUz4if8AXzZ/
+kqV6AOlef8Agj/kpnxE/wCvmz/9JUr0AdKxpfC/V/mz0Mf/ABo/4Yf+kROI+J//AAjuPCf/AAkP
2j/kYLT+zvs+f+P35/K3Y/h+9mu4riPidrGj6P8A8In/AGvpf9qfavEFpa2fIH2a5bf5c3/AcH86
7etjzwooooAK4f4Yf8I7jxZ/wj32j/kYLv8AtH7Rn/j9+Tzduf4fu4ruK4j4Y6xo+sf8JZ/ZGl/2
X9l8QXdrecg/abldnmTf8CyPyoA7eiiigAriPil/wjv2Tw1/wkX2jyv+EgsPsX2fOftvmjyN2P4d
3Wu3riPilrGj6NaeG21jS/7VjuPEFha2q5x5Fy8oEU3/AABuaAO3ooooAKQ0tFAH45ftreI9L0r9
rj4oQX2o2dlP9rsG8u4nWNip0uzwQCenv7V4t/wmvh8/8x3TP/AyP/4qv3zIpAMnoc187iMkw+Jq
SqybTZ+yZP4oZtkuBpYChTg4QVldan4G/wDCa+Hv+g9pn/gbH/8AFUf8Jr4e/wCg9pv/AIGx/wDx
VfvrijFc3+ruG/mZ7X/EZc8/59Q+5n4bfB/xPo2ofGr4Y21rq9lczv4w0PbFBcI7t/xMbc4ABzwA
T+FfuOAOPajHtRjrwa9vA4OGBpunTe7ufl3E/EuK4pxkcbi4qMlFR02sm3+p8meBP2atJ0f426do
A+G+j2Hgrwb4g1Xxjo2rx6Tboz3F5DafZo/MC7GVJptTURxqskS6TpZcqFiafvvglr+reA/APgL4
Wf8ACLaxc+LPDWmafo2qXNxZXFtpEcNtFHFLeRag0RhnV0QNFDEWmZpY1ljg2ztB7vS16B8kfLvw
B+Gc3j3QdR1HWtf8b2uhReONX1mPwbrmix6VaFhrc+oWM486xivWXLW1z/ripfMbfKrxA8R6Nq1v
8HviT8FxomsT+K/Fs3iZNLvrfTLiTSGh1a7vLiK4lvlQwwLCl2RLHKyzbreQRRTb4DN9RUUAeD/G
e/tvEvj/AMH2Ohab4nn8eeHPEFhc2Vyuk6lHpEVrLLCupSNctGNPlb+zZL1FZ3Z0aR0i2zNg+8UU
UAFFFFABRRRQAUUUUAeVftK/8k60j/sc/Cf/AKkOnV6rXlP7Sv8AyTrSP+xz8J/+pDp1eq5oAWii
igAri/BPiGfWvE3xBs5dJTT49I12KyhuUQqb9G0yxnM7Ej5iGnaLIzxCB2IHZ5rkvB2oeILzxH47
h1m28nTrTWY4dEfywvnWZ06yd3z/ABf6S92uT/cx2oA66iiigArjPiP4iuPDo8MGDSI9W+3a5a2T
70LfZkfdmcYBwVx1967KuS8f6h4hsP8AhHP+EetvtPn61bQ6j8gby7I7vNfnpjC80AddRSZozQAt
FJmjNAHG/DzxDP4guvFqz6RHpX9n65NZRsiFftaLFEwmOQMk7yM/7NdnXI+A9Q8RX9z4pGv232aO
31qaHTDsC+ZZCOIo/HXLGQZ9q62gBaKKKAOM+I/iK48OjwwYNIj1b7drlrZPvQt9mR92ZxgHBXHX
3rs65Hx/qHiGw/4Rz/hHrb7T5+tW0Oo/IG8uyO7zX56YwvNdbmgBaKKKACuM+HniGfxBdeLVn0iP
Sv7P1yayjZEK/a0WKJhMcgZJ3kZ/2a7LNcl4D1DxDf3Piga/b/Zo7fWpodMOwL5lkI4ij8dcsZBn
2oA66iiigArjPiP4iuPDo8MGDSI9W+3a5a2T70LfZkfdmcYBwVx1967OuR+IGoeIbD/hHP8AhHrb
7SZ9atodR+QN5dkd3mvz0xheaAOuopM0ZoAYMjrg1wPgkj/hZnxE5x/pNn/6SpXa317BptpNdXMq
w20KGSWWRgqooGSxJ4AAGSTXj3gD4neFb34n+NYbfX9NuJr66tBbJFexMZj9nRcKA3zHIxxnmuep
OMZwTfX9GezgMNXrYfEzpwbSir2W3vxZ3fw48RT+Ih4nM+kR6T9h1y6sk2IV+0om3E5yBktnr7V2
WK5L4f6h4hvx4i/4SG2+zeTrNzDp3yBfMsht8p+OuctzXRXt5Dp9rPcXEqQW8KGSSWRgqooGSzE8
AADJJroPGSbdkcT4II/4WZ8Q+c/6TZ9/+nVK9BFeKfD34n+FNQ+KHjWG38QaXNNe3VoLZIr2JjMf
s6LhAG+Y5GOM817QGyAefpXNQnCcW4O+r/M9nNsPWw1eMa0HF8sN1b7COQ+I/iK48OjwwYNIj1b7
drlrZPvQt9mR92ZxgHBXHX3rs65Hx/qHiGwHhz/hHrb7T5+tW0Oo/IG8uyO7zX56YwvNdbmuk8YW
iiigArjPhx4iuPEQ8TmfSI9J+w65dWSbEK/aUTbic5AyWz19q7LNcn8P9Q8Q3/8Awkf/AAkNt9m8
jWrmHTvkC+ZZDb5T8dc5bmgDraKKKACuL+JXiCfw7aeH3g0iPVjd65Y2TrIhb7OkkoUzjAOCnUHt
XZ5rkviFqHiLT7bQW8O2/wBplm1qzhvhsD7LJpAJ356YXnPagDrqKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigArm/GnjvRvh9pkV/rM9wsc0wtre2sbOe9u7qUqzeXBbQI8szBEkcrGjFUjk
c4VGI8g/as1P+xdX+Ek9/wCNvEHg7wvc+Jriw1z+xJ/ISe1bSb+UtcSpG0sUSGAbpleNYUeSYtG0
Mc0PLeBfFh8P6l8PviD4u1n7N4IsrLxfoUHinWLrNutrLrVodGkmunJ3RTWVgCl3KxWYmLMryXEf
mAHpL/tY/DRY7drfVNY1N59Tl0QQaX4a1S9mTUI7WO7ltJI4bZ3jnSGTc0TgMpjmUgNDKqasX7RP
giW68N2y3WsfbNf1N9GtLR/DuorcRXqxiYwXURt99o3ksJx9oEeYcyjMYLjyH4w/ELQ9Z8T/AAcv
fCGsaB4Q1TXvH80um61rtoklvru3QL21+2xQpcQS3UTGW2tY5S6bybcp5kTwGXoPE3gK++G2p+E/
G3iPVbfUvL8cv4m8WaxZ2TWdjYxHw/c6THMsDSzPFAgFl5jNJIE3TTO0cSt5YB6TrHx28HaB4q8Q
eHdQvNQtdU0Gzt769RtGvTEY7hxHbLDMIfLuJZpSYo4YWeSSRHRFZ0ZRv+C/HejfEHTJb/Rp7ho4
ZjbXFtfWc9ld2soVW8ue2nRJYWKPG4WRFLJJG4yrqT5DpvxU8I6P40+JnxjuvEWn/wDCr7fwzoun
/wDCVRTCWyuJ7W51SSdIHXP2jb9ttowYt4aV2hUtLHIi6n7L3ivQ/iDo/jnxXpOs6fq9/rXiaW61
RNKukurWykFnaR2tss0ZeN5UsY7HzjFLLGLhrgI5UBVALf7VGqWWh/Ciz1LU7yDT9Os/Fnhe5ubu
6lWOGCJNf09nkd2ICqqgksSAACTWl/w1D8HD/wA1Z8Df+FJZ/wDx2vMP+Clv/JlfxB/66aX/AOnO
0r8RgeAO9fs3AXAWH4ww9atWrum6ckrJJ3ur9TzsVipUGkle5/QZ/wANQfBv/orPgb/wpLP/AOO0
f8NQfBv/AKKz4G/8KSz/APjtfz5c0c1+qf8AEEMB/wBBs/8AwFf5nD/aUv5T+go/tP8Awc/6K14G
/wDCks//AI7T/g94rTxtf+PdXsPFOl+K/Dk+vINGudI1GG8it7ddOsVkhLREhW+0C5cqTn94D0YV
/PmD7V+tv/BH4E/s5+L/APscrj/0gsa/OOOfDrDcJZdDG0cRKo5TUbNJbpu+nodmGxbrzcWraH3Z
RRSGvww9Mbz+leffGPWrjw1omi6x/b9h4a0mw1m0m1e/1K8jtYBZlijo0khCjczRqASMkgDmvQTy
a+W/+Cj+nvffswX0y3Yt0tNa0uZ4yeZwbuOMIPUgyB8f7B9KyqS5IOXZHVg6CxWJp0G7KUkr9rux
7CP2jPhMQCPif4Nwf+pgtP8A45S/8NF/Cf8A6Kf4N/8ACgtP/jlfjPmjNfD/AOstRf8ALpff/wAA
/quPghg2k/r0v/AF/mfsx/w0X8J/+in+Df8AwoLT/wCOUf8ADRnwn/6Kf4N/8KC0/wDjlfjPmjNL
/Wap/wA+l9//AAB/8QPwf/QdL/wBf5n7JfBrxP8A8JdbeLdRg8T6Z4q0x9fnXT7nSdQivI4LfyoS
sJaMkKwJYlScjcD3Fekehr43/wCCX2R8HfHRz/zOEvX/ALBun19kc/lX22HqutRhUa3Sf3o/l7N8
EstzGvgoy5lTnKN+/K2r/Ow+iiiug8o88+Mmtz+GNE0XWT4hsPDGjafrNpNq+oaneR2luLIsUdGk
kIUbmeNQCRkkAc1R/wCGofg4f+as+Bv/AApLP/47Xi//AAVI05739j/xBKl2tstpqWmzujNzODdJ
HsHqQZA+PRD6V+L4PAHev2fgPgHD8X4atXrYh03BpWSTvdeZ52KxUqDSSvc/oM/4ag+Df/RWfA3/
AIUln/8AHaP+GoPg3/0VnwN/4Uln/wDHa/ny5o5r9T/4ghgP+g2f/gK/zOH+0pfyn9BR/af+Dn/R
WvA3/hSWf/x2n/BbxUnjO18Wana+KtL8W6VJr040670fUYr2GC38qHbCXiJCsCWJUnI3A9xX8+YP
tX62/wDBH4E/s5+L/wDscrj/ANILGvzjjnw6w3CWXQxtHESqOU1GzSW6bvp6HZhsW683Fq2h92Uh
paK/DD0xpzXn3xj1i58OaLousDX7Hw3pNhrNpPq19qN4lrALPcVdGdyFG5mQAZGSQK9AbPSvnb9u
vTnvvglYzLdi3Sz8T6JM8ZbmcG/ij2D1IMgfH+wfSuevUdGlKoleyb+45sRVdCjOqleyb+5HpQ/a
G+FTDI+Jfg8g/wDUetP/AI5R/wANC/Cv/opfhD/wfWv/AMcr4por8TfiTUTt9VX/AIG//kT+dH4v
1k7fUl/4G/8A5E+zrn49/Ci9glhm+I/g2WGRSrI2u2hDKRggjzOQRXxz8AfDXwh+GH7RfizXNR+K
HghdF0dyNAEviSz+fzgTkgyZJiQmMk9WOR0qvXwT+0p/yXXxZkfx23/pJBX634XVKPiXxDHKcVT9
iowc1JPmellazSP0ngrxWzDMJ4vLqFL2UKlP3rSvdKUVbZW337XP2U+H/wC0f8PbAeI/+Eh+MXga
58/WbmbTv+Knsm8uyO3yk4k4xhuK6W6/aU+C95bywS/FbwJJFIpR0bxHZEMpGCCPM5BFfz9c0c+9
f2n/AMQQwH/QbP8A8BX+Z9aszmndRP1Q/Zz8I/CbwD+0N4r8QzfErwXceH9HcjQHHiG0cP5wJ3Z8
zrEhMZPdjkdK+xh+0L8LAQP+Fl+Dv/B9a/8Axyvyw/Y0GPhrrH/Yak/9J7eve6/z04l4njwnneNy
WhQ540akoqTlZuzavazsfnnF3jHmE81nSxeHVR01GKfO1oorpyv/AIc+r/F/xo8K+JdR8JWHhL4l
+FTfy69aLcW0GvWpkurclg8KKHJdmJUBQMntXsuDuBJr84Lj/kYPBP8A2OHh3/072lfo9g55PSvp
eG87ln2ElipQ5LScbXvsk+y7n1PCXEUuJ8DLGSpeztJxte+yTvey7ktFFFfWH3A3pXi2i/Grwr8P
tc8WaN4/+JvhPTNZTWZ5rbT9R1+1iuLazkVHgR43dWT5TuAI6MD0Ne0Gvwf/AG67CTTf2wfinFJd
res2pRzCRTkKJLWCQJ9UDBCOxWvuODOHafFGaLL6tRwTTd0rvT1OXEVnRhzJXP2W/wCGoPg3/wBF
Z8Df+FJZ/wDx2j/hqD4N/wDRWfA3/hSWf/x2v58ufejmv6C/4ghgP+g2f/gK/wAzyv7Sl/Kf0F/8
NPfBvP8AyVrwNj/sZLP/AOOVzniv48+CvFl54X0zwX8VvB1xqs2vWIltLXxFaNNdW/mjzYUQSEuz
DgKBk5wK/BftXon7OP8AycZ8JP8AscdF/wDS+CvGzjwfwWWZdiMbHFzk6cZStyrWybtuaU8fKc1H
l3Z/QtRRRX8vHthRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQBw3jz4Yp478TeCNabxHrGjP4U
1NtVt7TTRamG7laCS3Kz+dBI+3yZriPEbIcTMc7ljZO5oooAKKKKACiiigD5f/4KW/8AJlfxA95N
L/8ATnaV+Iw6e9fu1+3J4Mb4j/s46t4TW9Gmtr2t+H9KF6YfOFuZ9asYvM2bl37d+du4ZxjI618j
f8OY73/os0P/AISbf/J9fufh1xxl/CeGr0cZCTc5Jq3ZKx5mLw0q7Ti9j83vxFH4iv0i/wCHMV5/
0WaD/wAJNv8A5Po/4cxXn/RZof8Awk2/+T6/YP8AiM2R/wDPuf3HB/Z1Xuj83cV+t3/BH3/k3Pxe
D/0OVx/6QWNeZ/8ADmS9/wCizQ/+Em3/AMn19RfsO/A+y/Z08GeOvAdp4ofxZe6f4oaS/vDphsVh
ml02wkWJEMsu4CJ4W3bursMfLz+W+IPH+XcU5ZTweDhJSjNSd+yTX6nbhMLKjNyl2PpWiiiv5+PV
G96+Wf8AgpJY2d3+zFeSXN19mlt9b0uW1j/57SfakQp+CPI//AK+piK8L/bB+G+mfF74VWXhDUNa
k8O3eqa5YR6bqK2RvFiu1m3qHiEke5WVHU/OMbge2DlVi5wlBdUztwNeOGxVKvPaMk36J3PyXor7
W/4dYeIf+iv6Z/4R8n/yxo/4dYeIf+iv6Z/4R8n/AMsa/Pf9XcV/Mj+xY+MuRpJezn9x8U0V9rf8
OsPEP/RX9M/8I+T/AOWNH/DrDxD/ANFf0z/wj5P/AJY0f6u4r+ZFf8RmyP8A59z+477/AIJff8kc
8c5/6HCXj/uG6fX2MGBHH/16+ef2LvhJb/BTwZ408OQ+J/8AhK7lPE88l5eLpZ09Ipxa2kZiWMzS
lgFjRt27kuRgY5+hgCD0H5V99h6To0YU3ukl9yP5DzrGwzHM8TjKatGpOUlfs22vzJKKKK6Txz5F
/wCCpVlaXX7IGuyXN39mmt9U06W2j/57yG5RCn4I8j/8Ar8YB096/dz9s/4V6T8bfg7D4H1TXJfD
s2tazY2+nanHZG7EN0Jd674hJHuVlV1+8MbgecYPyJ/w5jvf+izQ/wDhJt/8n1+6+HfHGX8KYWtR
xkZNzaat5aHmYvDSryTj0Pze/EUfiK/SL/hzFef9Fmg/8JNv/k+j/hzFef8ARZof/CTb/wCT6/Xv
+IzZH/z7n9xwf2dV7o/N3Ffrd/wR9/5Nz8Xg/wDQ5XH/AKQWNeZ/8OZL3/os0P8A4Sbf/J9fUX7C
/wAELH9nr4eeL/CFn4pk8WyweKLiS7vW0w2Ijn+y2qGJUMsu4BY0O7dyWIwMc/lviDx/l3FOWU8H
g4SUozUnfsk1+p24TCyozcpdj6Vooor+fj1RpPFfOf7d9nZ3XwU06S5uvs81v4p0SS2T/nvIb6NC
n4I8j/8AAK+jCM14r+1b4H0/4kfDvSPDt5rDaBqF34h01tKvzZG8jjvEmEkYkhEkZZGEbqfnXG7O
eK5sRTdWjOmt2rHJiqTr0KlOO8k1958p0V61/wAMW/EL/oqfhn/wirj/AOWlH/DFvxC/6Kn4Z/8A
CKuP/lpX8+vw9zNu/PE/lt+FWbt39pA8lr4I/aVyfjp4r/37X/0kgr9UD+xf8Qh/zVLw0f8AuSrj
/wCWleQeN/8AgktrHj/xbqXiDUfjBZQ3l8YzJHbeEXWNSkSxjaDqBPRAeSec/Sv3Xwcws/D/AIk/
tfMXzU+SUbR31t/kfccI8DZhkOMqYjEzi1KPKrd+ZP8AQ/MT8RR+Ir9B/C//AASTj8Xf2t/Z/wAa
kf8AsvUJtMuPM8IMuJo8bwP9P5HzDmtv/hzFef8ARZoP/CTb/wCT6/un/iM2R/8APuf3H6r/AGdV
7o8j/YzOfhprH/Yak/8ASe3r3uuo+GX/AATj8WfCjQrrSdJ+LWj3NvPdG7Zr7wdK7hyiJgFdSUYx
GvbqTz6dif2L/iEP+apeGj/3JVx/8tK/zU4z4VxnEPEWOzbCyShWqSmk90pNtXPxHP8Aw6zPNMyq
4ulOKjK1rvySPG7jP9v+Csf9Dh4e6/8AYXtK/R8Due9fF+qfsu+IPCHiDwVe+JPiZo9zYf8ACUaU
8dvp3hCaGWeaK6juI4vMbUZBGGaDaWKNgE8V9ogEDnr7V9Jwrk9fJMFLD4hptyctPNJfofp/BOQY
nhzLp4TFNOTm5admkv0H0UUV9ofoI3Pevwc/bnsrOx/bA+KkdjdfbIW1SOVpMdJHtoXlT/gDs6f8
Br948Zr87Pin/wAE3dO/aR+MfxA8caB8Tn0GC61l7e50258OtcmC6jijSbbL9rj3qWBYfKMbsc4y
f0DgbP8ADcN5vHH4tNwSast9TkxNJ1qfKtz8u/xFH4iv0i/4cxXn/RZoP/CTb/5Po/4cxXn/AEWa
D/wk2/8Ak+v6T/4jNkf/AD7n9x5H9nVe6PzdxzXof7OP/Jxvwk/7HLRf/S+Cvt4f8EZb3/ossP8A
4Sjf/J1WPDf/AATDt/gd8RPAHi/Vfi3/AGhFYeKNLkhs4fCxja4nW6jeOIv9tbYGZAC21sA5wa8L
O/FjJsxyzE4OlTmpVISirrq1Y0p4CpCak3s0fphRRRX8knvBRRRQAUUUUAFFFFABRRRQAUUUUAFF
FFABRRRQAUUUUAFFFFABRRRQB5V+0r/yTrSP+xz8J/8AqQ6dXqteVftK/wDJOtI/7HPwn/6kOnV6
rQAUUUUAFcT4B1fR9S8V/Em20zS/7PvdP8QQ22qXGc/brk6VYSrN7Yglt4v+2NdtXF+CfEM+teJv
iDZy6Smnx6RrsVlDcohU36NpljOZ2JHzENO0WRniEDsQADtKKKKACuI+J2saPo//AAif9r6X/an2
rxBaWtnyB9muW3+XN/wHB/Ou3rjPiP4iuPDo8MGDSI9W+3a5a2T70LfZkfdmcYBwVx196AOzoooo
AKKKKAOI+GusaPq134zXSdL/ALMez8QT2t82c/arkRQlpvxVkH/Aa7euM+HniGfxBdeLVn0iPSv7
P1yayjZEK/a0WKJhMcgZJ3kZ/wBmuzoAKKKKAOI+J2saPo//AAif9r6X/an2rxBaWtnyB9muW3+X
N/wHB/Ou3rjPiP4iuPDo8MGDSI9W+3a5a2T70LfZkfdmcYBwVx1967OgAooooAK4j4a6xo+rXfjN
dJ0v+zHs/EE9rfNnP2q5EUJab8VZB/wGu3rjPh54hn8QXXi1Z9Ij0r+z9cmso2RCv2tFiiYTHIGS
d5Gf9mgDs6KKKACuI+J2saPo/wDwif8Aa+l/2p9q8QWlrZ8gfZrlt/lzf8Bwfzrt64z4j+Irjw6P
DBg0iPVvt2uWtk+9C32ZH3ZnGAcFcdfegDs6KKKACiiigDiPhjrGj6x/wln9kaX/AGX9l8QXdrec
g/abldnmTf8AAsj8q7euM+HHiK48RDxOZ9Ij0n7Drl1ZJsQr9pRNuJzkDJbPX2rs6ACiiigDiPid
rGj6P/wif9r6X/an2rxBaWtnyB9muW3+XN/wHB/Ou3rjPiP4iuPDo8MGDSI9W+3a5a2T70LfZkfd
mcYBwVx1967OgAooooAK4j4Y6xo+sf8ACWf2Rpf9l/ZfEF3a3nIP2m5XZ5k3/Asj8q7euM+HHiK4
8RDxOZ9Ij0n7Drl1ZJsQr9pRNuJzkDJbPX2oA7OiiigAriPilrGj6NaeG21jS/7VjuPEFha2q5x5
Fy8oEU3/AABua7euL+JXiCfw7aeH3g0iPVjd65Y2TrIhb7OkkoUzjAOCnUHtQB2lFFFABRRRQAUU
UUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFYfiqy1vUNDnt9A1W10TVGZfLvbuxN5GgDAtmIS
R5yMj73Gc80AblFeU/8ACF/F/wD6Kh4f/wDCPb/5Oo/4Qv4v/wDRUPD/AP4R7f8AydQAv7Sv/JOt
I/7HPwn/AOpDp1eq14R44+DPxS8d6LbabffFLQ0gg1PT9UUxeEGB82zvIbuIf8fvQvAgPsTXQ/8A
CF/F/wD6Kh4f/wDCPb/5OoA9Woryn/hC/i//ANFQ8P8A/hHt/wDJ1H/CF/F//oqHh/8A8I9v/k6g
D1auR8HX/iC88R+O4dZtvJ0601mOHRH8sL51kdOsnd8/xf6S92uT/cx2rl/+EL+L/wD0VDw//wCE
e3/ydWbpvw6+MVje6tPJ8XdIu1vrlbiOGbwgSlqohij8uP8A03hSYzJz/FI9AHtFFeU/8IX8X/8A
oqHh/wD8I9v/AJOo/wCEL+L/AP0VDw//AOEe3/ydQB6tXJeP7/xDYf8ACOf8I9bfafP1q2h1H5A3
l2R3ea/PTGF5rlv+EL+L/wD0VDw//wCEe3/ydWdq/wAOPjDqgs9nxd0ix+z3KTt9m8JFfOC5zG+b
05Q55HtQB7PRXlP/AAhfxf8A+ioeH/8Awj2/+TqP+EL+L/8A0VDw/wD+Ee3/AMnUAerUV5T/AMIX
8X/+ioeH/wDwj2/+TqP+EL+L/wD0VDw//wCEe3/ydQB1HgO/8RX9z4oGv232aO31qaHTDsC+ZZCO
Io/HXLGQZ9q66vGNJ+HHxh0xr9n+LukXoublrhRceEiRACqjy0xe8INpIH+0a0f+EL+L/wD0VDw/
/wCEe3/ydQB6tRXlP/CF/F//AKKh4f8A/CPb/wCTqP8AhC/i/wD9FQ8P/wDhHt/8nUAdT4/v/ENh
/wAI5/wj1t9p8/WraHUfkDeXZHd5r89MYXmutrxjV/hx8YdUFns+LukWP2e5Sdvs3hIr5wXOY3ze
nKHPI9q0f+EL+L//AEVDw/8A+Ee3/wAnUAerUV5T/wAIX8X/APoqHh//AMI9v/k6j/hC/i//ANFQ
8P8A/hHt/wDJ1AHq1cj4Dv8AxFf3Piga/bfZo7fWpodMOwL5lkI4ij8dcsZBn2rl/wDhC/i//wBF
Q8P/APhHt/8AJ1Z2k/Dj4w6Y1+z/ABd0i9FzctcKLjwkSIAVUeWmL3hBtJA/2jQB7PRXlP8Awhfx
f/6Kh4f/APCPb/5Oo/4Qv4v/APRUPD//AIR7f/J1AHq1cl4/v/ENh/wjn/CPW32nz9atodR+QN5d
kd3mvz0xhea5b/hC/i//ANFQ8P8A/hHt/wDJ1Z2r/Dj4w6oLPZ8XdIsfs9yk7fZvCRXzgucxvm9O
UOeR7UAez0V5T/whfxf/AOioeH//AAj2/wDk6j/hC/i//wBFQ8P/APhHt/8AJ1AHq1FeU/8ACF/F
/wD6Kh4f/wDCPb/5Oo/4Qv4v/wDRUPD/AP4R7f8AydQB1PgC/wDEN/8A8JH/AMJDbfZvI1q5h075
AvmWQ2+U/HXOW5rra8Y0j4b/ABh0v7Zv+LmkXv2i4edftPhIt5IbH7tMXowgxwPetH/hC/i//wBF
Q8P/APhHt/8AJ1AHq1FeU/8ACF/F/wD6Kh4f/wDCPb/5Oo/4Qv4v/wDRUPD/AP4R7f8AydQB1Pj+
/wDENh/wjn/CPW32nz9atodR+QN5dkd3mvz0xhea62vGNX+HHxh1QWez4u6RY/Z7lJ2+zeEivnBc
5jfN6coc8j2rR/4Qv4v/APRUPD//AIR7f/J1AHq1FeU/8IX8X/8AoqHh/wD8I9v/AJOo/wCEL+L/
AP0VDw//AOEe3/ydQB6tXJeAL/xDf/8ACR/8JDbfZvI1q5h075AvmWQ2+U/HXOW5rlv+EL+L/wD0
VDw//wCEe3/ydWdpHw3+MOl/bN/xc0i9+0XDzr9p8JFvJDY/dpi9GEGOB70Aez0V5T/whfxf/wCi
oeH/APwj2/8Ak6j/AIQv4v8A/RUPD/8A4R7f/J1AHq1cj8QtQ8RafbaC3h23+0yy61Zw3w8sPssm
kAnfnphec9q5f/hC/i//ANFQ8P8A/hHt/wDJ1Z2r/Dj4w6olqsfxd0iwMFzHcE23hEgyhWyY2zen
KN0IoA9nqvcXEdtGHlkSFCypukYKCzMFUc9ySAB3JArzH/hC/i//ANFQ8P8A/hHt/wDJ1eB/t1fC
34yeKv2WvGelW/ia08aXF1Jp6R6HonhZ4bq5b+0LYjY4upCu0jeTtI2o2cDkAH2lRXx7+wV8Kf2j
/hv4djj+MPjS1v8ARPJ22nh69H2/UbU443XoYBQMY2ZmGOAUr7CoAKKKKACiiigAooooAKKKKACi
iigAooooAKKKKACiiigAooooA5H4gfECD4f2emH+zNQ17VdXvv7P0zR9M8kXF7OIZZ2RGnkihTbD
bzyEySICIiAS7KrWvAnjax+IPhuDWrCG5tkae4tJ7S7VRNa3VvO9vcwPtZkLRzRSxlkZkYoSjOpV
jxfxzjuNP1b4ZeJf7P1C+0rw34mk1DUzpllNfXEUEmk6jaK6W8CvNL++uoFIjRioYuQERmW1+z1p
N9pXw3ka+sriwfUfEGvaxBBdRNDN9lvNXvLu2Z42AeNmhniYxuFdCxV1VlZQAenUUUUAFcjonxH0
vXPiR4o8FW9tqEeq+HrOwvrua4tGit5EuzcCIQu2PNx9mfcyAoCdu4usip11eO+GL9m/at+IEZ0z
WIoH8J6HbR6hNpF1HYzSwXWpyTRx3TRiGRlS+tjtVyfmcDJjkCAHsVFFFABXN+NvFc3hDSorm10D
WPE99POIINM0SKNppW2sxJkmkjhiUIjnfNIikgIpMjxo3SVw3xc+JTfCzwbLrNvoGseJr6SeO0td
O0bTrq8ZpXOA832aGZ4oEALSSiNyqqQqSSFI3ANXwJ42sfiD4bg1qwhubZGnuLSe0u1UTWt1bzvb
3MD7WZC0c0UsZZGZGKEozqVY9JXmP7OdvFb/AAf0ZY4NXjnaa8lvbjXtKk0q71C9a7ma6vms5Dut
1uZzLcpEcbUnQBUACj06gAooooA88g+L9v8A8JzZ+Hb7w14g0i01G9n0zS9dv4IY7TUbyGKWWSGK
PzTcr+7trllllhSJ1gLJIwkhMnodeD6vqFv4r/aJ8G6p4Z0zxQut6PNe6Rr95qWkalaaaujm3uGd
YHuo0tJGe/j00+ZbFpZFiUhmhRse8UAFFFFAGL4o8UaZ4K0K61fV7v7JYW+0MyxtK7u7hI4o40Be
WV3ZUSNAzu7qqqzMAavw98aWPxK8BeG/F+mRXEGm6/plrq1rHdqqzLFPEsqK4VmAYK4BAJGc4J61
y3xb+HPirx5qnhi60HxNpGk2ejzSXc2la9okup2l3chomtZ2WK7tjut2SRkVmdN7pJtEkMTpU/ZU
0TXPDX7M3wr0rxHH9n1qz8NafBPbGye0e2226BYZIndmEsa7Uckjc6M21AdigHrFFFFABXnmg/Fq
TxT461HQdK8H+ILzRtPvZNPn8Xo9iNJ8+OINKiZuhcSbJCbdikLBZkkQkGNyvodeEaNoejyfG22v
fhz4UuPCtxBqd5J441VvD8+kW2sRNDOqIWlijW/na8aKZLiMSBI4rj98guAlwAe70UUUAFYvijxR
pngrQrrV9Xu/slhb7QzLG0ru7uEjijjQF5ZXdlRI0DO7uqqrMwB2q8R/ab8J2fiSH4dXes6NqGue
FdF8TNf65aaZa3F5K1q2l6hbKrW1sGmuInmuYI5IVR1aORxIpi8ygD1XwtrN34g0K1v7/QtQ8NXU
27fpeqSW73EGGKjebeWWI7gAw2yNwwzg5A2a8x/Z30m+0X4V2treWdxpsH9p6rNplhcxNC1tpcmo
3MmnQiFgGgVLN7ZVgZVaFVWMohQqPTqACiiigDyfRvj0+qeOvD/hyf4e+L9Ij1/7RJp+qahHYpE8
EMRkNxJbC6N5BEcxJma3QpJcQRyCN5AtesV5joek3/iD47eJ/Ed/ZXEOm+H9Mg8O6M1zE0ReWfZe
ajPCQMSwSL/ZcQcklZbG4VVT5jJ6dQAUUUUAcj8QPiBB8P7PTD/Zmoa9qur339n6Zo+meSLi9nEM
s7IjTyRQptht55CZJEBERAJdlVrXgTxtY/EHw3BrVhDc2yNPcWk9pdqomtbq3ne3uYH2syFo5opY
yyMyMUJRnUqx4r9odbi58K6FazWGoXfhefWYD4il0axmvNRtbONJZopbWOBXmEpvIrJPMgRpYlke
WNomjE8Wt8Bo9Ug+FGh22qWH9m/ZPPtLCBrFbF202KeSPT5JLZVRYJZLRLeR4hHF5buy+VFt8tQD
0OiiigArzHRvjrpOs+MrbRU0XWLfTb7U7zQ9N8RTLb/Yb/UbQT/abWNFmNwjR/Y7wb5YY42+zPtd
t8XmenV8z+Dfh34j1L4y6bHpt/5Pwz8H+JtY8RY1fw7c2Wo3GrXov0lt4Z5ZlW4tlbUrqUTrbqm0
W0cclw3nvGAfTFFFFABXJfFP4j6X8IPhz4j8aa1BqF3pWhWcl9cw6XaNc3DogyQiL+rMVRBlnZEV
mHW15R+1ZHcXP7M/xUs7Kw1DVb+/8M6hp9pY6XYzXlxPPPbvDEiRQqznLyKCQMKMsxCqSADf8f8A
xMXwVqulaNY+HdX8XeIdThuLyDSNFNqk32WBoUnnL3U8EQVHubddvmbyZgVVgrld7wn4o0vxx4W0
fxJol19t0bWLKHULG58to/OglQSRvtcBlyrA4YAjPIBryvxv4hTRvin8PfiJNpPiC48L/wDCNavp
8kmn6BfXl5DPdz6VPbpLZQwtcxZjs7jcXiARkCOVZkVuq/Z88Lan4H+Anw18Oa3bfYda0fwzpmn3
1r5iyeTPFaxxyJuQlWwykZUkHHBIoA6vWfFGmaBqOhWN/dfZ7rXL1tP0+MRs3nzrbzXJTIBC/uba
ZstgfJjOSAbOl3k9/bSSz2FzpzrNNEIbloyzKkjIsg8t2G2RVEigkMFdQyo25R4v+0t4csrvxV8F
/Etx4IuPGdx4f8WyTKlhpS3tzAH0q/EW1mG2FTeLY/vZGjiSRIXd0CB1+d/hl4M8I6z498Mw+KfB
Hj/VvDul2Xjn7RaeJPDXiG6spo5tdS/0/wA+K4haO5llthNL+8V5Hljtw+6eO3CgH6AUV8FeFdF8
TQeAfDFn4X0Pxvp/xJ8U/CDWrfWtYvdM1O2u7vxL5Votkb7UbhFCzxyQaisDzygRIyiIpHNEHtL8
LvCPhjwTdQaFZeP9R8OX+tWQkstc+GAk0Fp47a+LG68P2NnYz3EWGhLXHk4M66YRI4tnSMA+so/i
rY3njLxp4V0/SNX1HXPC2mWepz262ywLei6Fz5MVrJO0aSsTaupfcIgzBTIGWQJ3NfCnxB0CY/Dj
4v8AhOL4f+MPD0jfBrQdEsNE0iw1S+SG/gGo406G/gjK3nlNfWUblXZZEMvmZRJwvqmlafoGq/Gn
Wdc8Q+BfEGr+JNU1nTtQ8Ia2NAu4rjT9J/s+xDob90QWES3Cag81lLLE7h5lMEhuQkwB9L0V8Ow/
C1dM8Y/EDxFq8nxWPjozeKLm7bwjoVrDK2lyC9FisOrGzSW8YW72XkWq3kzRXC2wMKLasIPdf2U/
DNp4Z8E68LDwhp/hS1vdZe6R9L0G48P2+p/6Nbxm6TSrhmlscGMwGNj+8NsZxxOKAPbaKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiuR8dfF
bwR8L/sP/CZeMvD/AIS+3b/sn9u6pBZfaNm3f5fmuu7bvTOM43LnqKTwv8V/BHjiztrvw34y0DX7
S6vW023n0rVILlJrpYTO1ujI5DSiFWkKD5gilsYGaAOvoorm/BXxB8L/ABI0qXU/CXibSPFOmxTG
2kvNEv4ryFJQqsYy8bMAwV0O3OcMD3FAHSUUUUAFFUNM1Wy1q3e50+8t763Saa2eS2lWRVlikaKW
MlSQGSRHRl6qysDggir9ABRRRQAUUUUAFFFUNT1Wy0W3S51C8t7G3eaG2SS5lWNWllkWKKMFiAWe
R0RV6szKBkkCgC/RRRQAUUUUAFFFUNX1Wy0DS7zU9TvbfTtNsoXubq8u5VihgiRSzyO7EBVVQSWJ
AABJoAv0UUUAFFFc341+IPhf4b6VFqfi3xNpHhbTZZhbR3mt38VnC8pVmEYeRlBYqjnbnOFJ7GgD
pKKK5vxr8QfC/wAN9Ki1Pxb4m0jwtpsswto7zW7+KzheUqzCMPIygsVRztznCk9jQB0lFeeeIv2g
vhZ4PvVtNe+JfhDRLtvM2wajr1rbufLmkgkwryA/LNDNG3o8TqeVIGrb/FbwRfa7oeiW/jLQLjWd
csl1LStOi1SBrjULVlZ1uIIw+6WIrG7B0BUhGOcA0AddRXOeG/iB4W8Y6trOmaB4m0fW9S0Sb7Nq
llpt/FcTWEu518udEYmJt0cg2sAcow7GujoAKKKoWeq2WpXN/bWt7b3VzYTC3u4oJVdraUxpKI5A
DlGMcsb7Tg7ZEPRgSAX6KK5GX4r+CLbxTd+GJfGOgReJLPyPtOjyapALyDznijh3wl96+Y9xAi5H
zNNGBkuuQDrqK888LftCfC3xxrtronhz4leD/EGtXRb7Pp2ma9a3NxNtUu2yNJCzYVWY4HAUnoKt
Wfxv+HWpeDr7xda+PvDF14UsJhbXmvQ6xbPY20pKARyTh9iMTLGNpIP7xP7wyAdzRVDSNVstf0uz
1PTL231HTb2FLm1vLSVZYZ4nUMkiOpIZWUghgSCCCKv0AFFFFABRRRQAUUUUAFFFFABRRRQAUUUU
AFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAeJftF22t3Xif4KReG9SsNL1p/Gc
32e81Sxe+t4/+JBrBbfCk0LPldwGJFwSDyBtNQnxr8P9T+BFjqGq6R/a/iPUzY+ObjT9NQPreoR+
H7p/tCzAIFUSWCf8sgzKkKgxojRv6r4k+H/hbxjq2janr/hnR9b1LRJvtOl3upWEVxNYS7kbzIHd
SYm3RxncpByinsKPEnw/8LeMdW0bU9f8M6PrepaJN9p0u91KwiuJrCXcjeZA7qTE26OM7lIOUU9h
QB87fBTU/GXxm17w9da/4j8Qa74R1HwzdXHi7QNS0Cyj8Ptf3C2yw2djcPZK19YlZL8iSG4uFZYI
C8zLIPO9J+FGsWXjf4uePfGVje272V7pmkaXpkUcqu19p9u99LHqajIZYJ57u8hiJXbItiZo3kjl
Ujivhb+xbonw51HTLcweEH8N6bZy6b5Ok+EksdT1q1a3e2+z6xd+e6X8TI/mSp5ESyTxxS4UJsPt
XgX4U+CPhf8Abv8AhDfBvh/wl9u2fa/7C0uCy+0bN2zzPKRd23e+M5xubHU0AddXDfGfxrffD/4Y
+INa0eKC48QrCtpolpdoxhutUuHW3sIHwy4WS5lgjLFlVQ5LMgBYdzXN+Nfh94X+JGlRaZ4t8M6R
4p02KYXMdnrdhFeQpKFZRIEkVgGCu43YzhiO5oA+TZvFXjL4I/Cz4uaNo1tr/gi/tfBk/ivw5ceO
zZatfXN1ZQCPV5/9DuZIBvJsJy0pDPd6hdzMkylkHvvw11jxRYfFLxd4N8Q+If8AhJhZaNpOvLet
ZRWvlTXk+oxTW8KRj5bZPsEZjWRpZl8xw80vyleg8Z/BH4d/ErVItT8XeAfDHinUooRbR3mtaNbX
kyRBmYRh5EYhQzuducZYnuat+HfhT4I8H682taD4N0DRNZayj05tR07S4Le5NrGsaR25kRA3lKsM
SqmdoESADCjAB4D8QvjJq/w6s/HF3rPxI/sa00T4saFpFpPqg0+BJNMu4dJnurF2aFQYo4b29kDj
EypAGaUhHJtfCzx38SU1XwVf+KvGdv4hXX/HHiLwhPptpo8NjZQ29k2sSR3CDLzeeH01IwWmMfku
FaN5VNw/v2p/D3wtrPiJNe1Dw1o9/rqQw2y6nc2EUlysUVwtzFGJWUsFSdEmVc4WRVcYYA1gab+z
58LdH/sr7B8NPCFiNJvG1LT/ALNoVrH9juj5ebiHEY8uU+RDl1w37qPn5RgA8/8AiF43+IviLVvh
dZ6OmofCeHXvE11oup22t2Gn6hfzQDSby6Wa3kgup4IsG3cLvDnzFjZkaJHiuMBPE3xbm+MOrxWf
ijR08E+EfEGkeGbufxBqVvanUhNaafLNJLbpppMl3K2oMkXk3dtEZfIXyCFcTe/+JPh/4W8Y6to2
p6/4Z0fW9S0Sb7Tpd7qVhFcTWEu5G8yB3UmJt0cZ3KQcop7Ckvfh94W1DxnYeL7vw1pF14rsITbW
euzWMT31tEQ4Mcc5XeikSyDaCB+8f+8cgHxvq/xF+LWvfC3WfHmk/Efxhpn9k+ANU8S6xGvh/TY9
HttZSCCa0tdPuJ9OP26xOL797DNcApFC32j94jS9V8cvGWn6/wDGfxD4NvvEmn69LoWtfDvXdK0S
4Fm9xot1L4hFvdtDsQTLmBrQsZGZlF7gFUmVT2vwX/ZCsvg14l0C70ybwxp+naBC1taz+HvCy6Zr
GpxCFoEj1W+W4cXqlWE0iiGIPcRQyjZ5ew+lXP7Pnwtu9Ch0Sf4Z+EJ9Fg8vytOfQbVrdNjTum2M
x7Rta6umGBwbiUjmRsgHzF4k+P3xM0/wZ4t1PQde1eSDUvh1rXjXRvEfiTRtLFjIbM2TxyaVa203
nxQSRXrkJqRklT/RiwkKTpJ9ZeH/AA94n0bwrqNvd+Lf7c8SXXmTw6hqGmRLZ2czIAscVtCY3Nsj
gssckzzbSVadjhhz2rfszfCDX9VvdT1P4UeCNS1K9me5ury78OWcs08rsWeR3aMlmZiSWJJJJJrt
v+ET0T/hFf8AhGf7GsP+Eb+x/wBm/wBj/ZU+x/Zdnl/Z/Jxs8rZ8mzG3bxjFAHzD8I/EfxU8d6V8
ILTVPifcJcePfAz+KdTvrLRLGOaxa3XTQkdiGjdEaU6hmd7hLhWMbeTHbBwI8rQf2j/HHijS/APj
S0uNYvIL2bwnYa1Y6XYadB4c0+bVV04zxXBuJTqMs4TUlljktj5K+Zao4cx3Bf6Ji/Z8+Flt9jMP
w18IRfY7KfTbbZoNqvkWs3m+dbpiP5YpPtE+5B8redJkHe2ad7+zN8INQtrG3u/hR4IuoLCE21nD
N4cs3W2iMjymOMGPCKZJZH2jA3SOerEkA8X+G3xO+JOqXOiNefEbR/EGsan448SeBriwh0WFNP0x
rSPVri3mkgSX7QZx9itvka5VTbTIpVpT9qfi7H49/E5f2c9P8WWPxI0/xBr2v/CbV/GJvzpFq9rp
d/pq2CvFbxxFf3rfa7hJvOeVVuIlZYoo1a2b6I+FPwNvvhzo+tXl3feGNW+IN3Nqslp4qh8MtbNb
xXt7Lfm2kU3TyywJdTyP5YnQFdg4YGRj4W/s1eFvBnwksPBniXQ/DHi+4OmWGlavqD+HooV1qKxR
Y7JrqKRpTI0UaRgF3YBlJUICFUA4C98e/EjR/GPj3Vr3xnb3OkaB8RdD8M2GgWmjwwQSWWojR0kF
zKxkldok1IvG0bxfvldn8yJ0t4jQfFPxB8d/FvSorDxf4otYLTxZqcOvaRp+iWh0GHR7R72K38nU
JbJxLPLJFp6TxR3byxvPdLsgMTCD1OP9mb4QQ6VcaYnwn8DpptzNFczWa+HLMQyyxrIscjJ5eGZF
mlCsRkCRwMbjngtN/ZCsdG+Jb+I9Pm8L6fA+vzeIW1W28LLH4oaWW7a8lgOrrcAGB5HeBk+z5a0Z
oCxJMtAHafEm/wBf1v4p+EPA+keJ9Q8IWmpaNq2s3GqaPBaS3jPaT6dDHCPtUE8QiYX8jN+737o4
8Oo3q/kGjRaj8fPH3wC8Ta7rdxYW/if4W6hqOraBZWdnLp12ssuhyXVq6XMEzmCcXAR137tsMYRk
JkMn0n41+H3hf4kaVFpni3wzpHinTYphcx2et2EV5CkoVlEgSRWAYK7jdjOGI7mi9+H3hbUPGdh4
vu/DWkXXiuwhNtZ67NYxPfW0RDgxxzld6KRLINoIH7x/7xyAeQftJeN9W+E3iHRfFd14x8QaX4Gk
0XWrW80jQrTTppzfwafcX8Fyhubdj8tvaX3Bl2mZLMFCjTkr8GdH8T6B8XhY/EXXf+El8XQ+ANJ2
apPHEiT3Rvb86v8AYgkUSiJWOlrJsjVti2PnZbYT7nqelWWtW6W2oWdvfW6TQ3KR3MSyKssUiyxS
AMCAySIjq3VWVSMEA1leNfh94X+JGlRaZ4t8M6R4p02KYXMdnrdhFeQpKFZRIEkVgGCu43YzhiO5
oA+d7O2svCvxN+FEfwO8NaBe6BJ4Z8XTWlnfajcaTYeTLqukSyzWzra3BaJ5nLRBEELRyBom8vyw
3QeC/Bd78N/jD8NYdalt0n1LTPGk8skDMbZNQ1HV7DVPsMUrqplZY1u9pKo0kdpLJ5aBWVPaL34f
eFtQ8Z2Hi+78NaRdeK7CE21nrs1jE99bREODHHOV3opEsg2ggfvH/vHNvxR4T0TxxoV1oniTRtP1
/Rbor9o07VbVLm3l2sHXfG4KthlVhkcFQeooA4D4Lf6T4z+NV/D+8sLzxkv2a6TmKfydG0u1m2MO
G8u4t54WwflkhkQ4ZGA+d/Enx++Jmn+DPFup6Dr2ryQal8Ota8a6N4j8SaNpYsZDZmyeOTSrW2m8
+KCSK9chNSMkqf6MWEhSdJPtHSNKstA0uz0zTLK307TbKFLa1s7SJYoYIkUKkaIoAVVUABQAAAAK
8/1b9mb4Qa/qt7qep/CjwRqWpXsz3N1eXfhyzlmnldizyO7RkszMSSxJJJJNAHm/in4g+O/AWp+L
PC114q/tm/b/AIRF49ZOnQQPYPrWtT6bdLaxBSgihSESW63HnursfOkuFwtW/wBkuXSdO8V/HrQL
PxHo/iLUrDxz517NpkdvBI7SaVp6tNcQwnYs7zRXKyuqoslxFckJHzGnqdl8Efh3pt1fXFr4B8MW
09/pg0S7lg0a2RrnTxGkQtJCEy8AjijTyjldsaDGFAHQeHPCuh+D7R7PQdG0/RLVvL3QadapbofL
hjgjyqAD5YYYY19EiRRwoAAPmz4P/FHx3e694Yn1/wAfaf4rl1Dx/wCIfA+paRp+mQWlrYpZrqtx
FIVDSTpc4sbcKHmKfZ5kDRvL/pL7/wAJtK8Gaz+zV8FbfxzY29/qyTaTcpHPE8l8viiJvNuZCEBl
F2l0l49yx+Zdt2Z8IJjXa/BL4In4ZRX1/r02geIvF9xe6lKviLTtB/s+4S1vb6S/ksyzzzyGJbme
VlHmBcbMqWUu3aWXw+8Laf4zv/F9p4a0i18V38ItrzXYbGJL65iAQCOScLvdQIoxtJI/dp/dGAD5
3+Gnhfxv8Q/Cd34f/svw/YeDLf4matq/9u/2zPLqLfYvFtxfeX9h+yLGN8tv5O77T8qv5mGI8omv
Yj/Y0+O+iOdutSXvjXTU01uLhrq+1G+ewtxH94y3C3lo0KY3Si5hKBhImfojwV8PvC/w30qXTPCX
hnSPC2myzG5ks9EsIrOF5SqqZCkaqCxVEG7GcKB2FF78PvC2oeM7Dxfd+GtIuvFdhCbaz12axie+
toiHBjjnK70UiWQbQQP3j/3jkA6SiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAC
iiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKK
KKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooo
oAKKKKACiiigAooooAKKKKACiiigAooooA//2Q==
------=_Part_343555_1040962665.1324366204520
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

------=_Part_343555_1040962665.1324366204520--



From xen-devel-bounces@lists.xensource.com Tue Dec 20 07:31:17 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 Dec 2011 07: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.xensource.com>)
	id 1Rcu9k-0006jK-Qd; Tue, 20 Dec 2011 07:30:36 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <gbtux@126.com>) id 1Rcu9i-0006jF-Rk
	for xen-devel@lists.xensource.com; Tue, 20 Dec 2011 07:30:35 +0000
X-Env-Sender: gbtux@126.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1324366224!8007457!1
X-Originating-IP: [220.181.15.49]
X-SpamReason: No, hits=1.4 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMjAuMTgxLjE1LjQ5ID0+IDQ2NTE=\n,sa_preprocessor: 
	QmFkIElQOiAyMjAuMTgxLjE1LjQ5ID0+IDQ2NTE=\n, BODY_RANDOM_LONG, HTML_40_50,
	HTML_MESSAGE,MIME_BASE64_TEXT
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8398 invoked from network); 20 Dec 2011 07:30:25 -0000
Received: from m15-49.126.com (HELO m15-49.126.com) (220.181.15.49)
	by server-10.tower-216.messagelabs.com with SMTP;
	20 Dec 2011 07:30:25 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=126.com;
	s=s110527; h=Received:Date:From:To:Cc:Message-ID:In-Reply-To:
	References:Subject:MIME-Version:Content-Type; bh=r8UOB7gXYgFAWP3
	W+W3A/9Y63X9rCb9aBxEpA8IZoW0=; b=PNhN8K8obt+NQjUgdJcjfmyMVRA6k7o
	eoHutIoozyYbZfffus3gunwrOtDgb39Qpd4+PscXPwYf9X3adXHosuSlZuIs4H3B
	LU13rdt/O3mRGFyUmShuvNl/Tc2h+4p5d0bXTw/wtw3FY93pH+WBxYD4SY05hCu+
	HPPe0trsrotU=
Received: from gbtux ( [124.16.139.196] ) by ajax-webmail-wmsvr49 (Coremail)
	; Tue, 20 Dec 2011 15:30:04 +0800 (CST)
Date: Tue, 20 Dec 2011 15:30:04 +0800 (CST)
From: gavin  <gbtux@126.com>
To: "George Dunlap" <George.Dunlap@eu.citrix.com>
Message-ID: <5097e419.1e4d1.1345a608e69.Coremail.gbtux@126.com>
In-Reply-To: <CAFLBxZZP=K504L86WDJ-F+9SuTf7aKU_C=i8nLZwqDuejoVGag@mail.gmail.com>
References: <CAFLBxZZP=K504L86WDJ-F+9SuTf7aKU_C=i8nLZwqDuejoVGag@mail.gmail.com>
	<26c93838.3b3fb.13445de0e67.Coremail.gbtux@126.com>
	<CAFLBxZYM-8vEc5Egmv+iXqMDUE_UJcgHbwr7=71H-kFowTzXWA@mail.gmail.com>
	<676b608e.2fb26.13447553671.Coremail.gbtux@126.com>
	<CAFLBxZaBiwEvz-dgPzgBQQTj2xMi8m+QnZ3M+uoqw4AKmb0ZvA@mail.gmail.com>
	<35e4701f.ca5a.1344b4ed98e.Coremail.gbtux@126.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; 
	boundary="----=_Part_343555_1040962665.1324366204520"
X-Originating-IP: [124.16.139.196]
X-Priority: 3
X-Mailer: Coremail Webmail Server Version SP_ntes V3.5 build
	111202(16086.4213.4207) Copyright (c) 2002-2011 www.mailtech.cn 126com
X-CM-CTRLDATA: +yLaI2Zvb3Rlcl9odG09MTM0OTI6ODE=
X-CM-TRANSID: McqowEAZQUV_OfBO3bcXAA--.878W
X-CM-SenderInfo: pjew35a6rslhhfrp/1tbiVwEcnE3l6FM+ZAABse
X-Coremail-Antispam: 1U5529EdanIXcx71UUUUU7vcSsGvfC2KfnxnUU==
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] A question on the credit scheduler
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

------=_Part_343555_1040962665.1324366204520
Content-Type: multipart/alternative; 
	boundary="----=_Part_343557_1060246463.1324366204521"

------=_Part_343557_1060246463.1324366204521
Content-Type: text/plain; charset=GBK
Content-Transfer-Encoding: base64

MSkgTXkgb3JpZ2luYWwgZ29hbCBpcyB0byBjYWxjdWxhdGUgdGhlIHVzYWdlIHBlcmNlbnRhZ2Ug
b2YgQ1BVIGluIGEgZGlmZmVyZW50IHdheSBmcm9tIG90aGVyIHRvb2xzLCBzdWNoIGFzIHhlbnRy
YWNlLgoKQmVjYXVzZSB0aGUgYWltIG9mIGFsbCB0aGUgc2NoZWR1bGluZyBpcyB0byBtYXAgdGhl
IHZDUFUgdG8gcENQVSwgd2UgY2FuIGdldCBhIG1hcHBpbmcgc2VxdWVuY2Ugb2YgcENQVSBhbmQg
dkNQVSBieSBtb25pdG9yaW5nIHRoZSBwQ1BVIGluIGEgZml4ZWQgaW50ZXJ2YWwuIAoKRm9yIGV4
YW1wbGUsIGlmIHRoZSBTQ0hFRFVMRV9TT0ZUSVJRIGlzIGp1c3QgcmFpc2VkIHdoZW4gdGhlIHRp
bWVzbGljZSBpcyBmaW5pc2hlZCwgdGhlIHZDUFUgcnVucyBhcyBkZXNjcmliZWQgaW4gdGhlIGZp
Z3VyZSAxICh0d28gcENQVSBhbmQgdGhyZWUgdkNQVSkuIFdlIG1vbml0b3IgYWxsIHRoZSBDUFVz
IG9uY2UgZXZlcnkgdGltZSB0LCB3aGljaCBpcyBlcXVhbCB0byB0aGUgdGltZSBvZiB0aGUgdGlt
ZXNsaWNlIGhlcmUuIEluIHRlbiB0aW1lc2xpY2UgKG1heWJlIDAuMyBzZWNvbmQgaW4gY3JlZGl0
MSksIHdlIGNhbiBnZXQgdGhlIG1hcHBpbmcgc2VxdWVuY2UsIHdoaWNoIGNvbnRhaW5zIDIwIChw
Q1BVLCB2Q1BVKSBwYWlycyBhcyB0aGUgZm9sbG93aW5nLgoKKHBDUFUxLCB2Q1BVMSksIChwQ1BV
MiwgdkNQVTIpLCAocENQVTEsIHZDUFUxKSwgKHBDUFUyLCBub24pLCAocENQVTEsIHZDUFUxKSwg
KHBDUFUyLCB2Q1BVMyksIChwQ1BVMSwgdkNQVTIpLCAocENQVTIsIG5vbiksIChwQ1BVMSwgbm9u
KSwgKHBDUFUyLCB2Q1BVMiksIChwQ1BVMSwgdkNQVTMpLCAocENQVTIsIG5vbiksIChwQ1BVMSwg
dkNQVTMpLCAocENQVTIsIHZDUFUxKSwgKHBDUFUxLCBub24pLCAocENQVTIsIHZDUFUxKSwgKHBD
UFUxLCB2Q1BVMSksIChwQ1BVMiwgbm9uKSwgKHBDUFUxLCBub24pLCAocENQVTIsIHZDUFUyKaGj
CgpJZiB0aGVyZSBpcyBubyB2Q1BVIG1hcHBlZCBvbiB0aGUgcENQVSwgd2UgdXNlIChwQ1BVKiwg
bm9uKSBwYWlyLCB3aGljaCBtZWFucyB0aGUgcENQVSBpcyBpZGxlLiBJbiB0aGUgYWJvdmUgc2Vx
dWVuY2UsIHRoZXJlIGFyZSA3IGlkbGUgcGFpcnMgaW4gdG90YWwuIAoKU28sIGZyb20gdGhlIGFi
b3ZlIG1hcHBpbmcgc2VxdWVuY2UsIHdlIGNhbiBjYWxjdWxhdGUgdGhlIHVzYWdlIHBlcmNlbnRh
Z2Ugb2YgdGhlIENQVSBpbiB0ZW4gdGltZXNsY2llICgwLjMgc2VuY29uZCkuCgpVc2FnZSBQZXJj
ZW50YWdlID0gKDIwLTcpLzIwID0gNjUlIAoKMikgSWYgd2UgY2FuIGdldCBzdWNoIGEgbWFwcGlu
ZyBzZXF1ZW5jZSBvZiBwQ1BVIGFuZCB2Q1BVLCBiZXNpZGVzIGNhbGN1bGF0aW5nIHRoZSB1c2Fn
ZSBwZXJjZW50YWdlIG9mIENQVSwgbWF5YmUgd2UgYWxzbyBjYW4gZmluZCBzb21lbGF3cyBvZiB0
aGUgbWFwcGluZyBzZXF1ZW5jZSBhbmQgdXNlIHRoZSBsYXdzIHRvIGluZmVyIHRoZSBDUFUtYm91
bmQgdGFzayBhbmQgSS9PLWJvdW5kIHRhc2suIAoKSG93ZXZlciwgdGhpcyBpZGVhIG1heSBub3Qg
d29yay4gQmVjYXVzZSB0aGUgU0NIRURVTEVfU09GVElSUSBpcyBub3Qgb25seSByYWlzZWQgd2hl
biB0aGUgdGltZXNsaWNlIGlzIGZpbmlzaGVkLCBidXQgYWxzbyByYWlzZWQgaW4gbWFueSBvdGhl
ciBzaXR1YXRpb25zLCB3ZSBjYW5ub3QgZ2V0IGEgcmVndWxhciBtYXBwaW5nIG9mIHZDUFUgYW5k
IHBDUFUganVzdCBsaWtlIGZpZ3VyZSAxLiBUaGUgbWFwcGluZyBpcyBpcnJlZ3VsYXIgcG9zc2li
bHkgc2hvd24gaW4gZmlndXJlIDIuIEluIHRoZSBmaWd1cmUgMiwgd2UgY2Fubm90IGZpbmQgYSB2
ZXJ5IHByb3BlciB0aW1lIHQgdG8gbW9uaXRvciB0aGUgQ1BVcy4KCgoKLS0KQmVzdCBSZWdhcmRz
LApHYXZpbgoKCgpBdCAyMDExLTEyLTE5IDE4OjM3OjE0LCJHZW9yZ2UgRHVubGFwIiA8R2Vvcmdl
LkR1bmxhcEBldS5jaXRyaXguY29tPiB3cm90ZToKPjIwMTEvMTIvMTcgZ2F2aW4gPGdidHV4QDEy
Ni5jb20+Ogo+Pgo+PiBBdCAyMDExLTEyLTE2IDIzOjU4OjI2LCJHZW9yZ2UgRHVubGFwIiA8R2Vv
cmdlLkR1bmxhcEBldS5jaXRyaXguY29tPiB3cm90ZToKPj4+MjAxMS8xMi8xNiBnYXZpbiA8Z2J0
dXhAMTI2LmNvbT46Cj4+Pj4gQXQgMjAxMS0xMi0xNiAxOTowNDoxOSwiR2VvcmdlIER1bmxhcCIg
PEdlb3JnZS5EdW5sYXBAZXUuY2l0cml4LmNvbT4gd3JvdGU6Cj4+Pj4KPj4+Pj4yMDExLzEyLzE2
IHpoaWthaSA8Z2J0dXhAMTI2LmNvbT46Cj4+Pj4+PiBIaSBBbGwsCj4+Pj4+Pgo+Pj4+Pj4gSW4g
dGhlIGNyZWRpdCBzY2hlZHVsZXIsIHRoZSBzY2hlZHVsaW5nIGRlY2lzaW9uIGZ1bmN0aW9uIGNz
Y2hlZF9zY2hlZHVsZSgpCj4+Pj4+PiBpcyBjYWxsZWQgaW4gdGhlIHNjaGVkdWxlIGZ1bmN0aW9u
IGluIHNjaGVkdWxlci5jLCBzdWNoIGFzIHRoZSBmb2xsb3dpbmcuCj4+Pj4+PiBuZXh0X3NsaWNl
ID0gc2NoZWQtPmRvX3NjaGVkdWxlKHNjaGVkLCBub3csIHRhc2tsZXRfd29ya19zY2hlZHVsZWQp
Owo+Pj4+Pj4KPj4+Pj4+IEJ1dCwgaG93IG9mdGVuIHRoZSBjc2NoZWRfc2NoZWR1bGUoKSBpcyBj
YWxsZWQgYW5kIHRvIHJ1bj8gRG9lcyB0aGlzCj4+Pj4+PiBmcmVxdWVuY3kgaGF2ZSBzb21ldGhp
bmcgdG8gZG8gd2l0aCB0aGUgc2xpY2Ugb2YgY3JlZGl0IHNjaGVkdWxlciB0aGF0IGlzCj4+Pj4+
PiAzMG1zPwo+Pj4+Pgo+Pj4+PlRoZSBzY2hlZHVsZXIgcnVucyB3aGVuZXZlciB0aGUgU0NIRURV
TEVfU09GVElSUSBpcyByYWlzZWQuICBJZiB5b3UKPj4+Pj5ncmVwIHRocm91Z2ggdGhlIHNvdXJj
ZSBjb2RlIGZybyB0aGF0IHN0cmluZywgeW91IGNhbiBmaW5kIGFsbCB0aGUKPj4+Pj5wbGFjZXMg
d2hlcmUgaXQncyByYWlzZWQuCj4+Pj4+Cj4+Pj4+U29tZSBleGFtcGxlcyBpbmNsdWRlOgo+Pj4+
PiogV2hlbiB0aGUgMzBtcyB0aW1lc2xpY2UgaXMgZmluaXNoZWQKPj4+Pj4qIFdoZW4gYSBzbGVl
cGluZyB2Y3B1IG9mIGhpZ2hlciBwcmlvcml0eSB0aGFuIHdoYXQncyBjdXJyZW50bHkgcnVubmlu
ZyB3YWtlcyB1cAo+Pj4+PiogV2hlbiBhIHZjcHUgYmxvY2tzCj4+Pj4+KiBXaGVuIGEgdmNwdSBp
cyBtaWdyYXRlZCBmcm9tIG9uZSBjcHUgdG8gYW5vdGhlcgo+Pj4+Pgo+Pj4+PjMwbXMgaXMgYWN0
dWFsbHkgYSBwcmV0dHkgbG9uZyB0aW1lOyBpbiB0eXBpY2FsIHdvcmtsb2FkcywgdmNwdXMgYmxv
Y2sKPj4+Pj5vciBhcmUgcHJlZW1wdGVkIGJ5IG90aGVyIHdha2luZyB2Y3B1cyB3aXRob3V0IHVz
aW5nIHVwIHRoZWlyIGZ1bGwKPj4+Pj50aW1lc2xpY2UuCj4+Pj4KPj4+PiBUaGFuayB5b3UgdmVy
eSBtdWNoIGZvciB5b3VyIHJlcGx5Lgo+Pj4+Cj4+Pj4gU28sIHRoZSB2Y3B1IGlzIHZlcnkgbGlr
ZWx5IHRvIGJlIHByZWVtcHRlZCB3aGVuZXZlciB0aGUgU0NIRURVTEVfU09GVElSUSBpcwo+Pj4+
IHJhaXNlZC4KPj4+Cj4+Pkl0IGRlcGVuZHM7IGlmIHlvdSBoYXZlIGEgY3B1LWJ1cm5pbmcgdmNw
dSBydW5uaW5nIG9uIGEgY3B1IGFsbCBieQo+Pj5pdHNlbGYsIHRoZW4gYWZ0ZXIgaXRzIDMwbXMg
dGltZXNsaWNlLCBYZW4gd2lsbCBoYXZlIG5vIG9uZSBlbHNlIHRvCj4+PnJ1biwgYW5kIHNvIHdp
bGwgbGV0IGl0IHJ1biBhZ2Fpbi4KPj4+Cj4+PkJ1dCB5ZXMsIGlmIHRoZXJlIGFyZSBvdGhlciB2
Y3B1cyBvbiB0aGUgcnVucXVldWUsIG9yIHRoZSBob3N0IGlzCj4+Pm1vZGVyYXRlbHkgYnVzeSwg
aXQncyBsaWtlbHkgdGhhdCBTQ0hFRFVMRV9TT0ZUSVJRIHdpbGwgY2F1c2UgYQo+Pj5jb250ZXh0
LXN3aXRjaC4KPj4+Cj4+Pj4gQW5kIHdlIGNhbm5vdCBmaW5kIGEgc21hbGwgdGltZXNsaWNlLCBz
dWNoIGFzIGEobXMpLCB3aGljaCBtYWtlcyB0aGUKPj4+PiB0aW1lIGFueSB2Y3B1IHNwZW5kaW5n
IG9uIHJ1bm5pbmcgcGhhc2UgaXMgayphKG1zKSwgayBpcyBpbnRlZ2VyIGhlcmUuIFRoZXJlCj4+
Pj4gaXMgbm8gc3VjaCBhIHNtYWxsIHRpbWVzbGljZS4gSXMgaXQgcmlnaHQ/Cj4+Pgo+Pj5JJ20g
c29ycnksIEkgZG9uJ3QgcmVhbGx5IHVuZGVyc3RhbmQgeW91ciBxdWVzdGlvbi4gIFBlcmhhcHMg
aWYgeW91Cj4+PnRvbGQgbWUgd2hhdCB5b3UncmUgdHJ5aW5nIHRvIGFjY29tcGxpc2g/Cj4+Cj4+
IEkgdHJ5IHRvIGRlc2NyaWJlIG15IGlkZWEgYXMgdGhlIGZvbGxvd2luZyBjbGVhcmx5LiBCdXQg
SSByZWFsbHkgZG9uJ3Qga25vdwo+PiBpZiBpdCB3aWxsIHdvcmsuIFBsZWFzZSBnaXZlIG1lIHNv
bWUgYWR2aWNlIGlmIHBvc3NpYmxlLgo+Pgo+PiBBY2NvcmRpbmcgdG8gdGhlIGNyZWRpdCBzY2hl
ZHVsZXIgaW4gWGVuLCBhIHZDUFUgY2FuIHJ1biBhIDMwbXMgdGltZXNsaWNlCj4+IHdoZW4gaXQg
aXMgc2NoZWR1bGVkIG9uIHRoZSBwaHlzaWNhbCBDUFUuIEFuZCwgYSB2Q1BVIHdpdGggdGhlIEJP
T1NUCj4+IHByaW9yaXR5IHdpbGwgcHJlZW1wdCB0aGUgcnVubmluZyBvbmUgYW5kIHJ1biBhZGRp
dGlvbmFsIDEwbXMuIFNvLCB3aGF0IEkKPj4gdGhpbmsgaXMgaWYgd2UgbW9uaXRvciB0aGUgcGh5
c2ljYWwgQ1BVIGV2ZXJ5IDEwbXMgYW5kIHdlIGNhbiBnZXQgdGhlCj4+IG1hcHBpbmcgaW5mb3Jt
YXRpb24gb2YgYSBwaHlzaWNhbCBDUFUgYW5kIGEgdkNQVS4gQW5kIGFsc28sIHdlIGNhbiBnZXQg
dGhlCj4+IHVuLW1hcHBpbmcgaW5mb3JtYXRpb24gdGhhdCBhIHBoeXNpY2FsIENQVSBpc26hr3Qg
bWFwcGVkIHRvIGFueSB2Q1BVLiBUaHVzLAo+PiB3ZSBjYW4gZ2V0IHRoZSBDUFUgdXNhZ2UgYnkg
Y2FsY3VsYXRpbmcgdGhlIHByb3BvcnRpb24gb2YgdGhlIG1hcHBpbmcKPj4gaW5mb3JtYXRpb24g
dG8gdGhlIHRvdGFsIHRpbWUgd2hlbiB3ZSBtb25pdG9yZWQuCj4+Cj4+IEZvciBleGFtcGxlLCBp
ZiB3ZSBtb25pdG9yIHRoZSBwaHlzaWNhbCBDUFVzIGV2ZXJ5IDEwbXMgYW5kIHdlIGNhbiBnZXQg
MTAwCj4+IHBhaXJzIG9mIHBDUFUgYW5kIHZDUFUgaW4gYSBzZWNvbmQsIHN1Y2ggYXMgKHBDUFVf
aWQsIHZDUFVfaWQpLiBJZiB0aGVyZSBpcwo+PiA2MCBtYXBwaW5nIHBhaXJzIHRoYXQgdGhlIHBD
UFUgaXMgbWFwcGVkIHRvIGEgdmFsaWQgdlBDVSwgYW5kIDQwIHVuLW1hcHBpbmcKPj4gcGFpcnMg
dGhhdCB3ZSBjYW5ub3QgZmluZCB0aGUgcENQVSB0byBiZSBtYXBwZWQgYSB2YWxpZCB2Q1BVLiBT
bywgd2UgY2FuIGdldAo+PiB0aGUgdXNhZ2Ugb2YgdGhlIHBoeXNpY2FsIENQVXMgdGhhdCBpcyA2
MCUuCj4+Cj4+IEhlcmUsIHdlIG1vbml0b3IgdGhlIHBoeXNpY2FsIENQVXMgZXZlcnkgMTBtcy4g
V2UgYWxzbyBjYW4gbW9uaXRvciB0aGVtIG9uY2UKPj4gbGVzcyB0aGFuIHRoZSAxMG1zIGludGVy
dmFsLCBzdWNoIGFzIDFtcyBpbnRlcnZhbC4gV2hhdGV2ZXIgaW50ZXJ2YWwgd2UKPj4gY2hvb3Nl
LCB3ZSBtdXN0IG1ha2Ugc3VyZSBubyBDUFUgY29udGVudCBzd2l0Y2ggaW4gdGhlIGludGVydmFs
IG9yIHRoZQo+PiBjb250ZXh0IHN3aXRjaCBhbHdheXMgb2NjdXIgYXQgdGhlIGVkZ2Ugb2YgaW50
ZXJ2YWwuIE9ubHkgaW4gdGhpcyBjb25kaXRpb24sCj4+IGNhbiB0aGlzIGlkZWEgd29yay4KPj4K
Pj4gU28sIEkgYW0gbm90IHN1cmUgd2hldGhlciB3ZSBjYW4gZmluZCBzdWNoIGEgdGltZSBpbnRl
cnZhbCB0aGF0IGNhbiBtZWV0Cj4+IHRoaXMgY29uZGl0aW9uLiBJbiBvdGhlciB3b3Jkcywgd2hl
dGhlciB3ZSBjYW4gZmluZCBzdWNoIGEgdGltZSBpbnRlcnZhbAo+PiB0aGF0IGVuc3VyZXMgYWxs
IHRoZSBDUFUgY29udGVudCBzd2l0Y2ggb2NjdXIgYXQgdGhlIGVkZ2Ugb2YgaW50ZXJ2YWwuCj4K
PllvdSBzdGlsbCBoYXZlbid0IGRlc2NyaWJlZCBleGFjdGx5IHdoYXQgaXQgaXMgeW91J3JlIHRy
eWluZyB0bwo+YWNjb21wbGlzaDogd2hhdCBpcyB5b3VyIGVuZCBnb2FsPyAgSXQgc2VlbXMgdG8g
YmUgcmVsYXRlZCBzb21laG93IHRvCj5tZWFzdXJpbmcgaG93IGJ1c3kgdGhlIHN5c3RlbSBpcyAo
aS5lLiwgdGhlIG51bWJlciBvZiBhY3RpdmUgcGNwdXMgYW5kCj5pZGxlIHBjcHVzKTsgYnV0IGFz
IEkgZG9uJ3Qga25vdyB3aGF0IHlvdSB3YW50IHRvIGRvIHdpdGggdGhhdAo+aW5mb3JtYXRpb24s
IEkgY2FuJ3QgdGVsbCB5b3UgdGhlIGJlc3Qgd2F5IHRvIGdldCBpdC4KPgo+UmVnYXJkaW5nIGEg
bWFwIG9mIHBjcHVzIHRvIHZjcHVzLCB0aGF0IGFscmVhZHkgZXhpc3RzLiAgVGhlCj5zY2hlZHVs
aW5nIGNvZGUgd2lsbCBrZWVwIHRyYWNrIG9mIHRoZSBjdXJyZW50bHkgcnVubmluZyB2Y3B1IGhl
cmU6Cj4gIHBlcl9jcHUoc2NoZWR1bGVfZGF0YSwgcGNwdV9pZCkuY3Vycgo+Cj5Zb3UgY2FuIHNl
ZSBleGFtcGxlcyBvZiB0aGUgYWJvdmUgc3RydWN0dXJlIHVzZWQgaW4KPnhlbi9jb21tb24vc2No
ZWRfY3JlZGl0Mi5jLiAgSWYgImlzX2lkbGUocGVyX2NwdShzY2hlZHVsZV9kYXRhLAo+cGNwdSku
Y3VycikiIGlzIGZhbHNlLCB0aGVuIHRoZSBjcHUgaXMgcnVubmluZyBhIHZjcHU7IGlmIGl0IGlz
IHRydWUsCj50aGVuIHRoZSBwY3B1IGlzIGlkbGUgKGFsdGhvdWdoIGl0IG1heSBiZSBydW5uaW5n
IGEgdGFza2xldCkuCj4KPkFkZGl0aW9uYWxseSwgaWYgYWxsIHlvdSB3YW50IGlzIHRoZSBudW1i
ZXIgb2Ygbm9uLWlkbGUgY3B1cywgdGhlCj5jcmVkaXQxIHNjaGVkdWxlciBrZWVwcyB0cmFjayBv
ZiB0aGUgaWRsZSBhbmQgbm9uLWlkbGUgY3B1cyBpbgo+cHJ2LT5pZGxlcnMuICBZb3UgY291bGQg
ZWFzaWx5IHVzZSAiY3B1bWFza193ZWlnaHQoJnBydi0+aWRsZXJzKSIgdG8KPmZpbmQgb3V0IGhv
dyBtYW55IGlkbGUgY3B1cyB0aGVyZSBhcmUgYXQgYW55IGdpdmVuIHRpbWUuICBJZiB5b3Uga25v
dwo+aG93IG1hbnkgb25saW5lIGNwdXMgdGhlcmUgYXJlLCB0aGF0IHdpbGwgZ2l2ZSB5b3UgdGhl
IGJ1c3ktbmVzcyBvZgo+dGhlIHN5c3RlbS4KPgo+U28gbm93IHRoYXQgeW91IGhhdmUgdGhpcyBp
bnN0YW50YW5lb3VzIHBlcmNlbnRhZ2UsIHdoYXQgZG8geW91IHdhbnQKPnRvIGRvIHdpdGggaXQ/
Cj4KPiAtR2VvcmdlCj4KPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fCj5YZW4tZGV2ZWwgbWFpbGluZyBsaXN0Cj5YZW4tZGV2ZWxAbGlzdHMueGVuc291cmNl
LmNvbQo+aHR0cDovL2xpc3RzLnhlbnNvdXJjZS5jb20veGVuLWRldmVsCg==
------=_Part_343557_1060246463.1324366204521
Content-Type: text/html; charset=GBK
Content-Transfer-Encoding: base64

PGRpdiBzdHlsZT0ibGluZS1oZWlnaHQ6MS43O2NvbG9yOiMwMDAwMDA7Zm9udC1zaXplOjE0cHg7
Zm9udC1mYW1pbHk6YXJpYWwiPjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT
Ij4xKSBNeSBvcmlnaW5hbCBnb2FsIGlzIHRvIGNhbGN1bGF0ZSB0aGUgdXNhZ2UKcGVyY2VudGFn
ZSBvZiBDUFUgaW4gYSBkaWZmZXJlbnQgd2F5IGZyb20gb3RoZXIgdG9vbHMsIHN1Y2ggYXMgeGVu
dHJhY2UuIDwvc3Bhbj48L3A+Cgo8cCBjbGFzcz0iTXNvTm9ybWFsIj5CZWNhdXNlIHRoZSBhaW0g
b2YgYWxsIHRoZSBzY2hlZHVsaW5nIGlzIHRvCm1hcCB0aGUgdkNQVSB0byBwQ1BVLCB3ZSBjYW4g
Z2V0IGEgbWFwcGluZyBzZXF1ZW5jZSBvZiBwQ1BVIGFuZCB2Q1BVIGJ5IG1vbml0b3JpbmcKdGhl
IHBDUFUgaW4gYSBmaXhlZCBpbnRlcnZhbC4mbmJzcDs8L3A+Cgo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBsYW5nPSJFTi1VUyI+Rm9yIGV4YW1wbGUsIGlmIHRoZSA8YSBuYW1lPSJPTEVfTElO
SzMiPjwvYT48YSBuYW1lPSJPTEVfTElOSzIiPlNDSEVEVUxFX1NPRlRJUlE8L2E+CmlzIGp1c3Qg
cmFpc2VkIHdoZW4gdGhlIHRpbWVzbGljZSBpcyBmaW5pc2hlZCwgdGhlIHZDUFUgcnVucyBhcyBk
ZXNjcmliZWQgaW4KdGhlIGZpZ3VyZSAxICh0d28gcENQVSBhbmQgdGhyZWUgdkNQVSkuIFdlIDwv
c3Bhbj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOnJlZCI+bW9uaXRvciBhbGwg
dGhlIENQVXMgb25jZSBldmVyeSB0aW1lIHQ8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIj4s
IHdoaWNoIGlzIGVxdWFsIHRvIHRoZSB0aW1lIG9mIHRoZSB0aW1lc2xpY2UgaGVyZS4gSW4gdGVu
IHRpbWVzbGljZQoobWF5YmUgMC4zIHNlY29uZCBpbiBjcmVkaXQxKSwgd2UgY2FuIGdldCB0aGUg
bWFwcGluZyBzZXF1ZW5jZSwgd2hpY2ggY29udGFpbnMgMjAKKHBDUFUsIHZDUFUpIHBhaXJzIGFz
IHRoZSBmb2xsb3dpbmcuPC9zcGFuPjwvcD4KCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh
bmc9IkVOLVVTIj4ocENQVTEsIHZDUFUxKSwgKHBDUFUyLCB2Q1BVMiksIChwQ1BVMSwKdkNQVTEp
LCA8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpyZWQiPihwQ1BVMiwgbm9u
KTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+LCAocENQVTEsIHZDUFUxKSwgKHBDUFUyLCB2Q1BV
MyksIChwQ1BVMSwgdkNQVTIpLCA8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xv
cjpyZWQiPihwQ1BVMiwgbm9uKTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+LCA8L3NwYW4+PHNw
YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpyZWQiPihwQ1BVMSwgbm9uKTwvc3Bhbj48c3Bh
biBsYW5nPSJFTi1VUyI+LCAocENQVTIsIHZDUFUyKSwKKHBDUFUxLCB2Q1BVMyksIDwvc3Bhbj48
c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOnJlZCI+KHBDUFUyLCBub24pPC9zcGFuPjxz
cGFuIGxhbmc9IkVOLVVTIj4sIChwQ1BVMSwgdkNQVTMpLCAocENQVTIsIHZDUFUxKSwgPC9zcGFu
PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6cmVkIj4ocENQVTEsIG5vbik8L3NwYW4+
PHNwYW4gbGFuZz0iRU4tVVMiPiwgKHBDUFUyLCB2Q1BVMSksIChwQ1BVMSwKdkNQVTEpLCA8L3Nw
YW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpyZWQiPihwQ1BVMiwgbm9uKTwvc3Bh
bj48c3BhbiBsYW5nPSJFTi1VUyI+LCA8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJj
b2xvcjpyZWQiPihwQ1BVMSwgbm9uKTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+LCAocENQVTIs
IHZDUFUyKTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6y87M5Tttc28tYXNjaWktZm9u
dC1mYW1pbHk6CiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Ozttc28taGFuc2ktZm9udC1mYW1p
bHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij6hozwvc3Bhbj48L3A+Cgo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+SWYgdGhlcmUgaXMgbm8gdkNQVSBtYXBwZWQg
b24gdGhlIHBDUFUsIHdlCnVzZSAocENQVSosIG5vbikgcGFpciwgd2hpY2ggbWVhbnMgdGhlIHBD
UFUgaXMgaWRsZS4gSW4gdGhlIGFib3ZlIHNlcXVlbmNlLAp0aGVyZSBhcmUgNyBpZGxlIHBhaXJz
IGluIHRvdGFsLjwvc3Bhbj4mbmJzcDs8L3A+Cgo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs
YW5nPSJFTi1VUyI+U28sIGZyb20gdGhlIGFib3ZlIG1hcHBpbmcgc2VxdWVuY2UsIHdlIGNhbgpj
YWxjdWxhdGUgdGhlIHVzYWdlIHBlcmNlbnRhZ2Ugb2YgdGhlIENQVSBpbiB0ZW4gdGltZXNsY2ll
ICgwLjMgc2VuY29uZCkuPC9zcGFuPjwvcD4KCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh
bmc9IkVOLVVTIj5Vc2FnZSBQZXJjZW50YWdlID0gKDIwLTcpLzIwID0gNjUlPC9zcGFuPiZuYnNw
OzwvcD4KCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4yKSBJZiB3ZSBj
YW4gZ2V0IHN1Y2ggYSBtYXBwaW5nIHNlcXVlbmNlIG9mCnBDUFUgYW5kIHZDUFUsIGJlc2lkZXMg
Y2FsY3VsYXRpbmcgdGhlIHVzYWdlIHBlcmNlbnRhZ2Ugb2YgQ1BVLCBtYXliZSB3ZSBhbHNvCmNh
biBmaW5kIHNvbWU8L3NwYW4+IDxzcGFuIGlkPSJ0cmFuXzFfNSI+bGF3czwvc3Bhbj4Kb2YgdGhl
IG1hcHBpbmcgc2VxdWVuY2UgYW5kIHVzZSB0aGUgbGF3cyB0byBpbmZlciB0aGUgQ1BVLWJvdW5k
IHRhc2sgYW5kIEkvTy1ib3VuZAp0YXNrLiZuYnNwOzwvcD4KCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIGxhbmc9IkVOLVVTIj5Ib3dldmVyLCB0aGlzIGlkZWEgbWF5IG5vdCB3b3JrLiBCZWNh
dXNlIHRoZQpTQ0hFRFVMRV9TT0ZUSVJRIGlzIG5vdCBvbmx5IHJhaXNlZCB3aGVuIHRoZSB0aW1l
c2xpY2UgaXMgZmluaXNoZWQsIGJ1dCBhbHNvIHJhaXNlZAppbiBtYW55IG90aGVyIHNpdHVhdGlv
bnMsIHdlIGNhbm5vdCBnZXQgYSByZWd1bGFyIG1hcHBpbmcgb2YgdkNQVSBhbmQgcENQVSBqdXN0
Cmxpa2UgZmlndXJlIDEuJm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj5UaGUgbWFwcGlu
ZyBpcyBpcnJlZ3VsYXIgcG9zc2libHkgc2hvd24gaW4KZmlndXJlIDIuIDxhIG5hbWU9Ik9MRV9M
SU5LNSI+PC9hPjxhIG5hbWU9Ik9MRV9MSU5LNCI+SW4gdGhlIGZpZ3VyZSAyLCB3ZSBjYW5ub3Qg
ZmluZCBhIHZlcnkgcHJvcGVyIDwvYT48L3NwYW4+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl
PSJjb2xvcjpyZWQiPnRpbWUgdDwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiPiB0byBtb25p
dG9yIHRoZSBDUFVzLjwvc3Bhbj48L3A+PGJyPjxkaXY+LS08YnI+QmVzdCBSZWdhcmRzLDxkaXY+
R2F2aW48L2Rpdj48L2Rpdj48ZGl2IGlkPSJkaXZOZXRlYXNlTWFpbENhcmQiPjwvZGl2Pjxicj48
cHJlPjxicj5BdCZuYnNwOzIwMTEtMTItMTkmbmJzcDsxODozNzoxNCwiR2VvcmdlJm5ic3A7RHVu
bGFwIiZuYnNwOyZsdDtHZW9yZ2UuRHVubGFwQGV1LmNpdHJpeC5jb20mZ3Q7Jm5ic3A7d3JvdGU6
CiZndDsyMDExLzEyLzE3Jm5ic3A7Z2F2aW4mbmJzcDsmbHQ7Z2J0dXhAMTI2LmNvbSZndDs6CiZn
dDsmZ3Q7CiZndDsmZ3Q7Jm5ic3A7QXQmbmJzcDsyMDExLTEyLTE2Jm5ic3A7MjM6NTg6MjYsIkdl
b3JnZSZuYnNwO0R1bmxhcCImbmJzcDsmbHQ7R2VvcmdlLkR1bmxhcEBldS5jaXRyaXguY29tJmd0
OyZuYnNwO3dyb3RlOgomZ3Q7Jmd0OyZndDsyMDExLzEyLzE2Jm5ic3A7Z2F2aW4mbmJzcDsmbHQ7
Z2J0dXhAMTI2LmNvbSZndDs6CiZndDsmZ3Q7Jmd0OyZndDsmbmJzcDtBdCZuYnNwOzIwMTEtMTIt
MTYmbmJzcDsxOTowNDoxOSwiR2VvcmdlJm5ic3A7RHVubGFwIiZuYnNwOyZsdDtHZW9yZ2UuRHVu
bGFwQGV1LmNpdHJpeC5jb20mZ3Q7Jm5ic3A7d3JvdGU6CiZndDsmZ3Q7Jmd0OyZndDsKJmd0OyZn
dDsmZ3Q7Jmd0OyZndDsyMDExLzEyLzE2Jm5ic3A7emhpa2FpJm5ic3A7Jmx0O2didHV4QDEyNi5j
b20mZ3Q7OgomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDtIaSZuYnNwO0FsbCwKJmd0OyZn
dDsmZ3Q7Jmd0OyZndDsmZ3Q7CiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwO0luJm5ic3A7
dGhlJm5ic3A7Y3JlZGl0Jm5ic3A7c2NoZWR1bGVyLCZuYnNwO3RoZSZuYnNwO3NjaGVkdWxpbmcm
bmJzcDtkZWNpc2lvbiZuYnNwO2Z1bmN0aW9uJm5ic3A7Y3NjaGVkX3NjaGVkdWxlKCkKJmd0OyZn
dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7aXMmbmJzcDtjYWxsZWQmbmJzcDtpbiZuYnNwO3RoZSZu
YnNwO3NjaGVkdWxlJm5ic3A7ZnVuY3Rpb24mbmJzcDtpbiZuYnNwO3NjaGVkdWxlci5jLCZuYnNw
O3N1Y2gmbmJzcDthcyZuYnNwO3RoZSZuYnNwO2ZvbGxvd2luZy4KJmd0OyZndDsmZ3Q7Jmd0OyZn
dDsmZ3Q7Jm5ic3A7bmV4dF9zbGljZSZuYnNwOz0mbmJzcDtzY2hlZC0mZ3Q7ZG9fc2NoZWR1bGUo
c2NoZWQsJm5ic3A7bm93LCZuYnNwO3Rhc2tsZXRfd29ya19zY2hlZHVsZWQpOwomZ3Q7Jmd0OyZn
dDsmZ3Q7Jmd0OyZndDsKJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7QnV0LCZuYnNwO2hv
dyZuYnNwO29mdGVuJm5ic3A7dGhlJm5ic3A7Y3NjaGVkX3NjaGVkdWxlKCkmbmJzcDtpcyZuYnNw
O2NhbGxlZCZuYnNwO2FuZCZuYnNwO3RvJm5ic3A7cnVuPyZuYnNwO0RvZXMmbmJzcDt0aGlzCiZn
dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwO2ZyZXF1ZW5jeSZuYnNwO2hhdmUmbmJzcDtzb21l
dGhpbmcmbmJzcDt0byZuYnNwO2RvJm5ic3A7d2l0aCZuYnNwO3RoZSZuYnNwO3NsaWNlJm5ic3A7
b2YmbmJzcDtjcmVkaXQmbmJzcDtzY2hlZHVsZXImbmJzcDt0aGF0Jm5ic3A7aXMKJmd0OyZndDsm
Z3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7MzBtcz8KJmd0OyZndDsmZ3Q7Jmd0OyZndDsKJmd0OyZndDsm
Z3Q7Jmd0OyZndDtUaGUmbmJzcDtzY2hlZHVsZXImbmJzcDtydW5zJm5ic3A7d2hlbmV2ZXImbmJz
cDt0aGUmbmJzcDtTQ0hFRFVMRV9TT0ZUSVJRJm5ic3A7aXMmbmJzcDtyYWlzZWQuJm5ic3A7Jm5i
c3A7SWYmbmJzcDt5b3UKJmd0OyZndDsmZ3Q7Jmd0OyZndDtncmVwJm5ic3A7dGhyb3VnaCZuYnNw
O3RoZSZuYnNwO3NvdXJjZSZuYnNwO2NvZGUmbmJzcDtmcm8mbmJzcDt0aGF0Jm5ic3A7c3RyaW5n
LCZuYnNwO3lvdSZuYnNwO2NhbiZuYnNwO2ZpbmQmbmJzcDthbGwmbmJzcDt0aGUKJmd0OyZndDsm
Z3Q7Jmd0OyZndDtwbGFjZXMmbmJzcDt3aGVyZSZuYnNwO2l0J3MmbmJzcDtyYWlzZWQuCiZndDsm
Z3Q7Jmd0OyZndDsmZ3Q7CiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7U29tZSZuYnNwO2V4YW1wbGVzJm5i
c3A7aW5jbHVkZToKJmd0OyZndDsmZ3Q7Jmd0OyZndDsqJm5ic3A7V2hlbiZuYnNwO3RoZSZuYnNw
OzMwbXMmbmJzcDt0aW1lc2xpY2UmbmJzcDtpcyZuYnNwO2ZpbmlzaGVkCiZndDsmZ3Q7Jmd0OyZn
dDsmZ3Q7KiZuYnNwO1doZW4mbmJzcDthJm5ic3A7c2xlZXBpbmcmbmJzcDt2Y3B1Jm5ic3A7b2Ym
bmJzcDtoaWdoZXImbmJzcDtwcmlvcml0eSZuYnNwO3RoYW4mbmJzcDt3aGF0J3MmbmJzcDtjdXJy
ZW50bHkmbmJzcDtydW5uaW5nJm5ic3A7d2FrZXMmbmJzcDt1cAomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0
OyombmJzcDtXaGVuJm5ic3A7YSZuYnNwO3ZjcHUmbmJzcDtibG9ja3MKJmd0OyZndDsmZ3Q7Jmd0
OyZndDsqJm5ic3A7V2hlbiZuYnNwO2EmbmJzcDt2Y3B1Jm5ic3A7aXMmbmJzcDttaWdyYXRlZCZu
YnNwO2Zyb20mbmJzcDtvbmUmbmJzcDtjcHUmbmJzcDt0byZuYnNwO2Fub3RoZXIKJmd0OyZndDsm
Z3Q7Jmd0OyZndDsKJmd0OyZndDsmZ3Q7Jmd0OyZndDszMG1zJm5ic3A7aXMmbmJzcDthY3R1YWxs
eSZuYnNwO2EmbmJzcDtwcmV0dHkmbmJzcDtsb25nJm5ic3A7dGltZTsmbmJzcDtpbiZuYnNwO3R5
cGljYWwmbmJzcDt3b3JrbG9hZHMsJm5ic3A7dmNwdXMmbmJzcDtibG9jawomZ3Q7Jmd0OyZndDsm
Z3Q7Jmd0O29yJm5ic3A7YXJlJm5ic3A7cHJlZW1wdGVkJm5ic3A7YnkmbmJzcDtvdGhlciZuYnNw
O3dha2luZyZuYnNwO3ZjcHVzJm5ic3A7d2l0aG91dCZuYnNwO3VzaW5nJm5ic3A7dXAmbmJzcDt0
aGVpciZuYnNwO2Z1bGwKJmd0OyZndDsmZ3Q7Jmd0OyZndDt0aW1lc2xpY2UuCiZndDsmZ3Q7Jmd0
OyZndDsKJmd0OyZndDsmZ3Q7Jmd0OyZuYnNwO1RoYW5rJm5ic3A7eW91Jm5ic3A7dmVyeSZuYnNw
O211Y2gmbmJzcDtmb3ImbmJzcDt5b3VyJm5ic3A7cmVwbHkuCiZndDsmZ3Q7Jmd0OyZndDsKJmd0
OyZndDsmZ3Q7Jmd0OyZuYnNwO1NvLCZuYnNwO3RoZSZuYnNwO3ZjcHUmbmJzcDtpcyZuYnNwO3Zl
cnkmbmJzcDtsaWtlbHkmbmJzcDt0byZuYnNwO2JlJm5ic3A7cHJlZW1wdGVkJm5ic3A7d2hlbmV2
ZXImbmJzcDt0aGUmbmJzcDtTQ0hFRFVMRV9TT0ZUSVJRJm5ic3A7aXMKJmd0OyZndDsmZ3Q7Jmd0
OyZuYnNwO3JhaXNlZC4KJmd0OyZndDsmZ3Q7CiZndDsmZ3Q7Jmd0O0l0Jm5ic3A7ZGVwZW5kczsm
bmJzcDtpZiZuYnNwO3lvdSZuYnNwO2hhdmUmbmJzcDthJm5ic3A7Y3B1LWJ1cm5pbmcmbmJzcDt2
Y3B1Jm5ic3A7cnVubmluZyZuYnNwO29uJm5ic3A7YSZuYnNwO2NwdSZuYnNwO2FsbCZuYnNwO2J5
CiZndDsmZ3Q7Jmd0O2l0c2VsZiwmbmJzcDt0aGVuJm5ic3A7YWZ0ZXImbmJzcDtpdHMmbmJzcDsz
MG1zJm5ic3A7dGltZXNsaWNlLCZuYnNwO1hlbiZuYnNwO3dpbGwmbmJzcDtoYXZlJm5ic3A7bm8m
bmJzcDtvbmUmbmJzcDtlbHNlJm5ic3A7dG8KJmd0OyZndDsmZ3Q7cnVuLCZuYnNwO2FuZCZuYnNw
O3NvJm5ic3A7d2lsbCZuYnNwO2xldCZuYnNwO2l0Jm5ic3A7cnVuJm5ic3A7YWdhaW4uCiZndDsm
Z3Q7Jmd0OwomZ3Q7Jmd0OyZndDtCdXQmbmJzcDt5ZXMsJm5ic3A7aWYmbmJzcDt0aGVyZSZuYnNw
O2FyZSZuYnNwO290aGVyJm5ic3A7dmNwdXMmbmJzcDtvbiZuYnNwO3RoZSZuYnNwO3J1bnF1ZXVl
LCZuYnNwO29yJm5ic3A7dGhlJm5ic3A7aG9zdCZuYnNwO2lzCiZndDsmZ3Q7Jmd0O21vZGVyYXRl
bHkmbmJzcDtidXN5LCZuYnNwO2l0J3MmbmJzcDtsaWtlbHkmbmJzcDt0aGF0Jm5ic3A7U0NIRURV
TEVfU09GVElSUSZuYnNwO3dpbGwmbmJzcDtjYXVzZSZuYnNwO2EKJmd0OyZndDsmZ3Q7Y29udGV4
dC1zd2l0Y2guCiZndDsmZ3Q7Jmd0OwomZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7QW5kJm5ic3A7d2Um
bmJzcDtjYW5ub3QmbmJzcDtmaW5kJm5ic3A7YSZuYnNwO3NtYWxsJm5ic3A7dGltZXNsaWNlLCZu
YnNwO3N1Y2gmbmJzcDthcyZuYnNwO2EobXMpLCZuYnNwO3doaWNoJm5ic3A7bWFrZXMmbmJzcDt0
aGUKJmd0OyZndDsmZ3Q7Jmd0OyZuYnNwO3RpbWUmbmJzcDthbnkmbmJzcDt2Y3B1Jm5ic3A7c3Bl
bmRpbmcmbmJzcDtvbiZuYnNwO3J1bm5pbmcmbmJzcDtwaGFzZSZuYnNwO2lzJm5ic3A7ayphKG1z
KSwmbmJzcDtrJm5ic3A7aXMmbmJzcDtpbnRlZ2VyJm5ic3A7aGVyZS4mbmJzcDtUaGVyZQomZ3Q7
Jmd0OyZndDsmZ3Q7Jm5ic3A7aXMmbmJzcDtubyZuYnNwO3N1Y2gmbmJzcDthJm5ic3A7c21hbGwm
bmJzcDt0aW1lc2xpY2UuJm5ic3A7SXMmbmJzcDtpdCZuYnNwO3JpZ2h0PwomZ3Q7Jmd0OyZndDsK
Jmd0OyZndDsmZ3Q7SSdtJm5ic3A7c29ycnksJm5ic3A7SSZuYnNwO2Rvbid0Jm5ic3A7cmVhbGx5
Jm5ic3A7dW5kZXJzdGFuZCZuYnNwO3lvdXImbmJzcDtxdWVzdGlvbi4mbmJzcDsmbmJzcDtQZXJo
YXBzJm5ic3A7aWYmbmJzcDt5b3UKJmd0OyZndDsmZ3Q7dG9sZCZuYnNwO21lJm5ic3A7d2hhdCZu
YnNwO3lvdSdyZSZuYnNwO3RyeWluZyZuYnNwO3RvJm5ic3A7YWNjb21wbGlzaD8KJmd0OyZndDsK
Jmd0OyZndDsmbmJzcDtJJm5ic3A7dHJ5Jm5ic3A7dG8mbmJzcDtkZXNjcmliZSZuYnNwO215Jm5i
c3A7aWRlYSZuYnNwO2FzJm5ic3A7dGhlJm5ic3A7Zm9sbG93aW5nJm5ic3A7Y2xlYXJseS4mbmJz
cDtCdXQmbmJzcDtJJm5ic3A7cmVhbGx5Jm5ic3A7ZG9uJ3QmbmJzcDtrbm93CiZndDsmZ3Q7Jm5i
c3A7aWYmbmJzcDtpdCZuYnNwO3dpbGwmbmJzcDt3b3JrLiZuYnNwO1BsZWFzZSZuYnNwO2dpdmUm
bmJzcDttZSZuYnNwO3NvbWUmbmJzcDthZHZpY2UmbmJzcDtpZiZuYnNwO3Bvc3NpYmxlLgomZ3Q7
Jmd0OwomZ3Q7Jmd0OyZuYnNwO0FjY29yZGluZyZuYnNwO3RvJm5ic3A7dGhlJm5ic3A7Y3JlZGl0
Jm5ic3A7c2NoZWR1bGVyJm5ic3A7aW4mbmJzcDtYZW4sJm5ic3A7YSZuYnNwO3ZDUFUmbmJzcDtj
YW4mbmJzcDtydW4mbmJzcDthJm5ic3A7MzBtcyZuYnNwO3RpbWVzbGljZQomZ3Q7Jmd0OyZuYnNw
O3doZW4mbmJzcDtpdCZuYnNwO2lzJm5ic3A7c2NoZWR1bGVkJm5ic3A7b24mbmJzcDt0aGUmbmJz
cDtwaHlzaWNhbCZuYnNwO0NQVS4mbmJzcDtBbmQsJm5ic3A7YSZuYnNwO3ZDUFUmbmJzcDt3aXRo
Jm5ic3A7dGhlJm5ic3A7Qk9PU1QKJmd0OyZndDsmbmJzcDtwcmlvcml0eSZuYnNwO3dpbGwmbmJz
cDtwcmVlbXB0Jm5ic3A7dGhlJm5ic3A7cnVubmluZyZuYnNwO29uZSZuYnNwO2FuZCZuYnNwO3J1
biZuYnNwO2FkZGl0aW9uYWwmbmJzcDsxMG1zLiZuYnNwO1NvLCZuYnNwO3doYXQmbmJzcDtJCiZn
dDsmZ3Q7Jm5ic3A7dGhpbmsmbmJzcDtpcyZuYnNwO2lmJm5ic3A7d2UmbmJzcDttb25pdG9yJm5i
c3A7dGhlJm5ic3A7cGh5c2ljYWwmbmJzcDtDUFUmbmJzcDtldmVyeSZuYnNwOzEwbXMmbmJzcDth
bmQmbmJzcDt3ZSZuYnNwO2NhbiZuYnNwO2dldCZuYnNwO3RoZQomZ3Q7Jmd0OyZuYnNwO21hcHBp
bmcmbmJzcDtpbmZvcm1hdGlvbiZuYnNwO29mJm5ic3A7YSZuYnNwO3BoeXNpY2FsJm5ic3A7Q1BV
Jm5ic3A7YW5kJm5ic3A7YSZuYnNwO3ZDUFUuJm5ic3A7QW5kJm5ic3A7YWxzbywmbmJzcDt3ZSZu
YnNwO2NhbiZuYnNwO2dldCZuYnNwO3RoZQomZ3Q7Jmd0OyZuYnNwO3VuLW1hcHBpbmcmbmJzcDtp
bmZvcm1hdGlvbiZuYnNwO3RoYXQmbmJzcDthJm5ic3A7cGh5c2ljYWwmbmJzcDtDUFUmbmJzcDtp
c26hr3QmbmJzcDttYXBwZWQmbmJzcDt0byZuYnNwO2FueSZuYnNwO3ZDUFUuJm5ic3A7VGh1cywK
Jmd0OyZndDsmbmJzcDt3ZSZuYnNwO2NhbiZuYnNwO2dldCZuYnNwO3RoZSZuYnNwO0NQVSZuYnNw
O3VzYWdlJm5ic3A7YnkmbmJzcDtjYWxjdWxhdGluZyZuYnNwO3RoZSZuYnNwO3Byb3BvcnRpb24m
bmJzcDtvZiZuYnNwO3RoZSZuYnNwO21hcHBpbmcKJmd0OyZndDsmbmJzcDtpbmZvcm1hdGlvbiZu
YnNwO3RvJm5ic3A7dGhlJm5ic3A7dG90YWwmbmJzcDt0aW1lJm5ic3A7d2hlbiZuYnNwO3dlJm5i
c3A7bW9uaXRvcmVkLgomZ3Q7Jmd0OwomZ3Q7Jmd0OyZuYnNwO0ZvciZuYnNwO2V4YW1wbGUsJm5i
c3A7aWYmbmJzcDt3ZSZuYnNwO21vbml0b3ImbmJzcDt0aGUmbmJzcDtwaHlzaWNhbCZuYnNwO0NQ
VXMmbmJzcDtldmVyeSZuYnNwOzEwbXMmbmJzcDthbmQmbmJzcDt3ZSZuYnNwO2NhbiZuYnNwO2dl
dCZuYnNwOzEwMAomZ3Q7Jmd0OyZuYnNwO3BhaXJzJm5ic3A7b2YmbmJzcDtwQ1BVJm5ic3A7YW5k
Jm5ic3A7dkNQVSZuYnNwO2luJm5ic3A7YSZuYnNwO3NlY29uZCwmbmJzcDtzdWNoJm5ic3A7YXMm
bmJzcDsocENQVV9pZCwmbmJzcDt2Q1BVX2lkKS4mbmJzcDtJZiZuYnNwO3RoZXJlJm5ic3A7aXMK
Jmd0OyZndDsmbmJzcDs2MCZuYnNwO21hcHBpbmcmbmJzcDtwYWlycyZuYnNwO3RoYXQmbmJzcDt0
aGUmbmJzcDtwQ1BVJm5ic3A7aXMmbmJzcDttYXBwZWQmbmJzcDt0byZuYnNwO2EmbmJzcDt2YWxp
ZCZuYnNwO3ZQQ1UsJm5ic3A7YW5kJm5ic3A7NDAmbmJzcDt1bi1tYXBwaW5nCiZndDsmZ3Q7Jm5i
c3A7cGFpcnMmbmJzcDt0aGF0Jm5ic3A7d2UmbmJzcDtjYW5ub3QmbmJzcDtmaW5kJm5ic3A7dGhl
Jm5ic3A7cENQVSZuYnNwO3RvJm5ic3A7YmUmbmJzcDttYXBwZWQmbmJzcDthJm5ic3A7dmFsaWQm
bmJzcDt2Q1BVLiZuYnNwO1NvLCZuYnNwO3dlJm5ic3A7Y2FuJm5ic3A7Z2V0CiZndDsmZ3Q7Jm5i
c3A7dGhlJm5ic3A7dXNhZ2UmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO3BoeXNpY2FsJm5ic3A7Q1BV
cyZuYnNwO3RoYXQmbmJzcDtpcyZuYnNwOzYwJS4KJmd0OyZndDsKJmd0OyZndDsmbmJzcDtIZXJl
LCZuYnNwO3dlJm5ic3A7bW9uaXRvciZuYnNwO3RoZSZuYnNwO3BoeXNpY2FsJm5ic3A7Q1BVcyZu
YnNwO2V2ZXJ5Jm5ic3A7MTBtcy4mbmJzcDtXZSZuYnNwO2Fsc28mbmJzcDtjYW4mbmJzcDttb25p
dG9yJm5ic3A7dGhlbSZuYnNwO29uY2UKJmd0OyZndDsmbmJzcDtsZXNzJm5ic3A7dGhhbiZuYnNw
O3RoZSZuYnNwOzEwbXMmbmJzcDtpbnRlcnZhbCwmbmJzcDtzdWNoJm5ic3A7YXMmbmJzcDsxbXMm
bmJzcDtpbnRlcnZhbC4mbmJzcDtXaGF0ZXZlciZuYnNwO2ludGVydmFsJm5ic3A7d2UKJmd0OyZn
dDsmbmJzcDtjaG9vc2UsJm5ic3A7d2UmbmJzcDttdXN0Jm5ic3A7bWFrZSZuYnNwO3N1cmUmbmJz
cDtubyZuYnNwO0NQVSZuYnNwO2NvbnRlbnQmbmJzcDtzd2l0Y2gmbmJzcDtpbiZuYnNwO3RoZSZu
YnNwO2ludGVydmFsJm5ic3A7b3ImbmJzcDt0aGUKJmd0OyZndDsmbmJzcDtjb250ZXh0Jm5ic3A7
c3dpdGNoJm5ic3A7YWx3YXlzJm5ic3A7b2NjdXImbmJzcDthdCZuYnNwO3RoZSZuYnNwO2VkZ2Um
bmJzcDtvZiZuYnNwO2ludGVydmFsLiZuYnNwO09ubHkmbmJzcDtpbiZuYnNwO3RoaXMmbmJzcDtj
b25kaXRpb24sCiZndDsmZ3Q7Jm5ic3A7Y2FuJm5ic3A7dGhpcyZuYnNwO2lkZWEmbmJzcDt3b3Jr
LgomZ3Q7Jmd0OwomZ3Q7Jmd0OyZuYnNwO1NvLCZuYnNwO0kmbmJzcDthbSZuYnNwO25vdCZuYnNw
O3N1cmUmbmJzcDt3aGV0aGVyJm5ic3A7d2UmbmJzcDtjYW4mbmJzcDtmaW5kJm5ic3A7c3VjaCZu
YnNwO2EmbmJzcDt0aW1lJm5ic3A7aW50ZXJ2YWwmbmJzcDt0aGF0Jm5ic3A7Y2FuJm5ic3A7bWVl
dAomZ3Q7Jmd0OyZuYnNwO3RoaXMmbmJzcDtjb25kaXRpb24uJm5ic3A7SW4mbmJzcDtvdGhlciZu
YnNwO3dvcmRzLCZuYnNwO3doZXRoZXImbmJzcDt3ZSZuYnNwO2NhbiZuYnNwO2ZpbmQmbmJzcDtz
dWNoJm5ic3A7YSZuYnNwO3RpbWUmbmJzcDtpbnRlcnZhbAomZ3Q7Jmd0OyZuYnNwO3RoYXQmbmJz
cDtlbnN1cmVzJm5ic3A7YWxsJm5ic3A7dGhlJm5ic3A7Q1BVJm5ic3A7Y29udGVudCZuYnNwO3N3
aXRjaCZuYnNwO29jY3VyJm5ic3A7YXQmbmJzcDt0aGUmbmJzcDtlZGdlJm5ic3A7b2YmbmJzcDtp
bnRlcnZhbC4KJmd0OwomZ3Q7WW91Jm5ic3A7c3RpbGwmbmJzcDtoYXZlbid0Jm5ic3A7ZGVzY3Jp
YmVkJm5ic3A7ZXhhY3RseSZuYnNwO3doYXQmbmJzcDtpdCZuYnNwO2lzJm5ic3A7eW91J3JlJm5i
c3A7dHJ5aW5nJm5ic3A7dG8KJmd0O2FjY29tcGxpc2g6Jm5ic3A7d2hhdCZuYnNwO2lzJm5ic3A7
eW91ciZuYnNwO2VuZCZuYnNwO2dvYWw/Jm5ic3A7Jm5ic3A7SXQmbmJzcDtzZWVtcyZuYnNwO3Rv
Jm5ic3A7YmUmbmJzcDtyZWxhdGVkJm5ic3A7c29tZWhvdyZuYnNwO3RvCiZndDttZWFzdXJpbmcm
bmJzcDtob3cmbmJzcDtidXN5Jm5ic3A7dGhlJm5ic3A7c3lzdGVtJm5ic3A7aXMmbmJzcDsoaS5l
LiwmbmJzcDt0aGUmbmJzcDtudW1iZXImbmJzcDtvZiZuYnNwO2FjdGl2ZSZuYnNwO3BjcHVzJm5i
c3A7YW5kCiZndDtpZGxlJm5ic3A7cGNwdXMpOyZuYnNwO2J1dCZuYnNwO2FzJm5ic3A7SSZuYnNw
O2Rvbid0Jm5ic3A7a25vdyZuYnNwO3doYXQmbmJzcDt5b3UmbmJzcDt3YW50Jm5ic3A7dG8mbmJz
cDtkbyZuYnNwO3dpdGgmbmJzcDt0aGF0CiZndDtpbmZvcm1hdGlvbiwmbmJzcDtJJm5ic3A7Y2Fu
J3QmbmJzcDt0ZWxsJm5ic3A7eW91Jm5ic3A7dGhlJm5ic3A7YmVzdCZuYnNwO3dheSZuYnNwO3Rv
Jm5ic3A7Z2V0Jm5ic3A7aXQuCiZndDsKJmd0O1JlZ2FyZGluZyZuYnNwO2EmbmJzcDttYXAmbmJz
cDtvZiZuYnNwO3BjcHVzJm5ic3A7dG8mbmJzcDt2Y3B1cywmbmJzcDt0aGF0Jm5ic3A7YWxyZWFk
eSZuYnNwO2V4aXN0cy4mbmJzcDsmbmJzcDtUaGUKJmd0O3NjaGVkdWxpbmcmbmJzcDtjb2RlJm5i
c3A7d2lsbCZuYnNwO2tlZXAmbmJzcDt0cmFjayZuYnNwO29mJm5ic3A7dGhlJm5ic3A7Y3VycmVu
dGx5Jm5ic3A7cnVubmluZyZuYnNwO3ZjcHUmbmJzcDtoZXJlOgomZ3Q7Jm5ic3A7Jm5ic3A7cGVy
X2NwdShzY2hlZHVsZV9kYXRhLCZuYnNwO3BjcHVfaWQpLmN1cnIKJmd0OwomZ3Q7WW91Jm5ic3A7
Y2FuJm5ic3A7c2VlJm5ic3A7ZXhhbXBsZXMmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO2Fib3ZlJm5i
c3A7c3RydWN0dXJlJm5ic3A7dXNlZCZuYnNwO2luCiZndDt4ZW4vY29tbW9uL3NjaGVkX2NyZWRp
dDIuYy4mbmJzcDsmbmJzcDtJZiZuYnNwOyJpc19pZGxlKHBlcl9jcHUoc2NoZWR1bGVfZGF0YSwK
Jmd0O3BjcHUpLmN1cnIpIiZuYnNwO2lzJm5ic3A7ZmFsc2UsJm5ic3A7dGhlbiZuYnNwO3RoZSZu
YnNwO2NwdSZuYnNwO2lzJm5ic3A7cnVubmluZyZuYnNwO2EmbmJzcDt2Y3B1OyZuYnNwO2lmJm5i
c3A7aXQmbmJzcDtpcyZuYnNwO3RydWUsCiZndDt0aGVuJm5ic3A7dGhlJm5ic3A7cGNwdSZuYnNw
O2lzJm5ic3A7aWRsZSZuYnNwOyhhbHRob3VnaCZuYnNwO2l0Jm5ic3A7bWF5Jm5ic3A7YmUmbmJz
cDtydW5uaW5nJm5ic3A7YSZuYnNwO3Rhc2tsZXQpLgomZ3Q7CiZndDtBZGRpdGlvbmFsbHksJm5i
c3A7aWYmbmJzcDthbGwmbmJzcDt5b3UmbmJzcDt3YW50Jm5ic3A7aXMmbmJzcDt0aGUmbmJzcDtu
dW1iZXImbmJzcDtvZiZuYnNwO25vbi1pZGxlJm5ic3A7Y3B1cywmbmJzcDt0aGUKJmd0O2NyZWRp
dDEmbmJzcDtzY2hlZHVsZXImbmJzcDtrZWVwcyZuYnNwO3RyYWNrJm5ic3A7b2YmbmJzcDt0aGUm
bmJzcDtpZGxlJm5ic3A7YW5kJm5ic3A7bm9uLWlkbGUmbmJzcDtjcHVzJm5ic3A7aW4KJmd0O3By
di0mZ3Q7aWRsZXJzLiZuYnNwOyZuYnNwO1lvdSZuYnNwO2NvdWxkJm5ic3A7ZWFzaWx5Jm5ic3A7
dXNlJm5ic3A7ImNwdW1hc2tfd2VpZ2h0KCZhbXA7cHJ2LSZndDtpZGxlcnMpIiZuYnNwO3RvCiZn
dDtmaW5kJm5ic3A7b3V0Jm5ic3A7aG93Jm5ic3A7bWFueSZuYnNwO2lkbGUmbmJzcDtjcHVzJm5i
c3A7dGhlcmUmbmJzcDthcmUmbmJzcDthdCZuYnNwO2FueSZuYnNwO2dpdmVuJm5ic3A7dGltZS4m
bmJzcDsmbmJzcDtJZiZuYnNwO3lvdSZuYnNwO2tub3cKJmd0O2hvdyZuYnNwO21hbnkmbmJzcDtv
bmxpbmUmbmJzcDtjcHVzJm5ic3A7dGhlcmUmbmJzcDthcmUsJm5ic3A7dGhhdCZuYnNwO3dpbGwm
bmJzcDtnaXZlJm5ic3A7eW91Jm5ic3A7dGhlJm5ic3A7YnVzeS1uZXNzJm5ic3A7b2YKJmd0O3Ro
ZSZuYnNwO3N5c3RlbS4KJmd0OwomZ3Q7U28mbmJzcDtub3cmbmJzcDt0aGF0Jm5ic3A7eW91Jm5i
c3A7aGF2ZSZuYnNwO3RoaXMmbmJzcDtpbnN0YW50YW5lb3VzJm5ic3A7cGVyY2VudGFnZSwmbmJz
cDt3aGF0Jm5ic3A7ZG8mbmJzcDt5b3UmbmJzcDt3YW50CiZndDt0byZuYnNwO2RvJm5ic3A7d2l0
aCZuYnNwO2l0PwomZ3Q7CiZndDsmbmJzcDstR2VvcmdlCiZndDsKJmd0O19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCiZndDtYZW4tZGV2ZWwmbmJzcDttYWls
aW5nJm5ic3A7bGlzdAomZ3Q7WGVuLWRldmVsQGxpc3RzLnhlbnNvdXJjZS5jb20KJmd0O2h0dHA6
Ly9saXN0cy54ZW5zb3VyY2UuY29tL3hlbi1kZXZlbAo8L3ByZT48L2Rpdj48YnI+PGJyPjxzcGFu
IHRpdGxlPSJuZXRlYXNlZm9vdGVyIj48c3BhbiBpZD0ibmV0ZWFzZV9tYWlsX2Zvb3RlciI+PC9z
cGFuPjwvc3Bhbj4=
------=_Part_343557_1060246463.1324366204521--

------=_Part_343555_1040962665.1324366204520
Content-Type: image/jpeg; name="fig1.jpg"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="fig1.jpg"

/9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAMCAgMCAgMDAwMEAwMEBQgFBQQEBQoHBwYIDAoMDAsK
CwsNDhIQDQ4RDgsLEBYQERMUFRUVDA8XGBYUGBIUFRT/2wBDAQMEBAUEBQkFBQkUDQsNFBQUFBQU
FBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBT/wAARCAD/Ah4DASIA
AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA
AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3
ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm
p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA
AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx
BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK
U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3
uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD9U6KK
KACiiigAooooAKK8s/aOuZbT4faS8MrxOfGHhVC0bFSVbX9PVhx2IJBHcEivU6ACiiigAoorivA3
hybRPE/xEvH1SO/XWddivo7eNizWKrpljb+S4zwSbdpcDHEynvkgHa0UUUAFFFcR8TPDUXiT/hFP
N1aDSf7P1+0v088gfaWTfiBeR8zZ469OhoA7eiiigAooooAKK4j4aeGYvDTeLFi1aDVTfa/dX7iH
H+itIEPkNyfmUAHt94cV29ABRRRQAUVxHxM8NReJP+EU83VoNJ/s/X7S/TzyB9pZN+IF5HzNnjr0
6Gu3oAKKKKACiiuI+GnhmLw03ixYtWg1U32v3V+4hx/orSBD5Dcn5lAB7feHFAHb0UUUAFFFcR8T
PDUXiT/hFPN1aDSf7P1+0v088gfaWTfiBeR8zZ469OhoA7eiiigAooooAKK4j4Z+GovDf/CV+Vq0
Grf2hr93fv5BB+zM+zMDcn5lxz069BXb0AFFFFABRXEfEzw1F4k/4RTzdWg0n+z9ftL9PPIH2lk3
4gXkfM2eOvToa7egAooooAKKK4j4Z+GovDf/AAlflatBq39oa/d37+QQfszPszA3J+Zcc9OvQUAd
vRRRQAUUVxHxN8NR+JF8LNLq0GkjTtftL9TPgfaWQsBAuSPmctgdenQ0AdvRRRQAUUUUAFFJketG
aAFooooAKKTI9aMj1oAWiiigAooooAKKKKACiiigAooooAKKKKAPKv2lf+SdaR/2OfhP/wBSHTq9
Vryr9pX/AJJ1pH/Y5+E//Uh06vVaACiiigArifAOkaPpviv4k3Omap/aF7qHiCG51S3xj7DcjSrC
JYffMEVvL/22rtq4fwF/wjv/AAlfxK/sb7T/AGj/AMJBD/bnnZ2/bf7K0/Z5f+z9m+ydP4t9AHcU
UUUAFcP8TtN0PUv+ET/tzUZNONvr9pPY+WM+fdrv8uI8Hhst6dOoruK4f4nz+HYB4T/4SG3uJ9/i
C0TThbkjZenf5TNgj5R82ev0NAHcUUUUAFFFFAHD/DbTdC0688ZnQ9Sk1CS51+efUVkGPs12YoQ8
Q4GQFCHv97rXcVw3w2m8PTXfjMaBDcW8ieIJ01MzkkPe+VDvZMk/LtMeOnIPFdzQAUUUUAcP8TtN
0PUv+ET/ALc1GTTjb6/aT2PljPn3a7/LiPB4bLenTqK7iuH+J8/h2AeE/wDhIbe4n3+ILRNOFuSN
l6d/lM2CPlHzZ6/Q13FABRRRQAVw/wANtN0LTrzxmdD1KTUJLnX559RWQY+zXZihDxDgZAUIe/3u
tdxXDfDabw9Nd+MxoENxbyJ4gnTUzOSQ975UO9kyT8u0x46cg8UAdzRRRQAVw/xO03Q9S/4RP+3N
Rk042+v2k9j5Yz592u/y4jweGy3p06iu4rh/ifP4dgHhP/hIbe4n3+ILRNOFuSNl6d/lM2CPlHzZ
6/Q0AdxRRRQAUUUUAcP8MdN0PTf+Es/sPUZNRNxr93PfeYMeRdts8yIcDhcL69epruK4f4YT+HZx
4s/4R63uINniC7TURcEnfejZ5rLkn5T8uOn0FdxQAUUUUAcP8TtN0PUv+ET/ALc1GTTjb6/aT2Pl
jPn3a7/LiPB4bLenTqK7iuH+J8/h2AeE/wDhIbe4n3+ILRNOFuSNl6d/lM2CPlHzZ6/Q13FABRRR
QAVw/wAMdN0PTf8AhLP7D1GTUTca/dz33mDHkXbbPMiHA4XC+vXqa7iuH+GE/h2ceLP+Eet7iDZ4
gu01EXBJ33o2eay5J+U/Ljp9BQB3FFFFABXEfFHTdD1O08NrrupSabHD4gsJ7NoxnzrtZQYYjweG
bg9PqK7euH+KU3h6Cz8NnxFBcXEba/YJYi3JBS9Mo8hmwR8obr147GgDuKKKKACiiigD4g+LfxS+
IjfGvx/pWmfEDVtA0jR9QtrOzsNPtLEoiNp9pOxLS2zuWMk8nVsYwABiua/4WJ8UP+is+Jv/AAE0
v/5DqX4n/wDJwHxa/wCw3af+mfT6xq/mriTO8xw+bV6NGtJRT0S6H8g8XcRZthM7xNGhiJRgnols
lZGn/wALG+KP/RWfE3/gJpf/AMh0f8LG+KP/AEVnxN/4CaX/APIdZlFfM/6x5t/0ESPjv9bM9/6C
p/ebGmfFn4m6P4p8JPL8Sdb1O2uvEekWFxZ3tpp/lTQ3GoQQSqdlqrD5JWwVYEHBr78yD/8AXr84
J/8AkYPBX/Y3+Hv/AE72lfo+MfnX7twNjMRjstnUxM3KSm1d9rR0/E/pfw2zDFZllFSti6jnJTau
+3LHT72x9LXnem/tB/C3WP7K+wfEvwhfDVrxtN0/7NrtrJ9suh5ebeHEh8yUefDlFy372Pj5hnlo
Pjj4v1jTtA8TaD8OP7f8BeIb3TodM1Oy1YnUfsl1cQxjUbiyNviK2EMjzjbLJKF8rzYoMzG3/RT9
YPbaK+ffDH7Qfje80m18QeJPAegaX4XbxM3hW4n0vxTPfXsd1/ax0lXSB9PhR4jdbSSZlYREttLD
yzaH7QPim3/Z18efEu+8F6PFqXhabWFOi2/iGWWG6i0y4lguX+0myUozNbXBjXymDARbmTe3lgHv
FFeeW3xJ1SD4p+GfA+q+Gvsd3qnhm612fVLa/Wezjnt57OGW0hyqyy4N4GMrxxDb5eAxZ1i9DoAK
KKKACiiigAooooA8q/aV/wCSdaR/2OfhP/1IdOr1WvKf2lf+SdaR/wBjn4T/APUh06vVcigBaKTN
GaAFrifAOr6PqXiv4k22maX/AGfe6f4ghttUuM5+3XJ0qwlWb2xBLbxf9sa7XIrjPBPiGfWvE3xB
s5dJTT49I12KyhuUQqb9G0yxnM7Ej5iGnaLIzxCB2IAB2lFJmjNAC1w3xO13TNBPhP8AtLSI9W+2
a/aWdt5hA+yzvv2TjIPK4PTB5613GQO9ch8QvEOo6B/wjX9m6Yup/btbtrK53RNJ9ngfdvmG37pX
A+Y8DPNAHYUUmaM0ALRSZozQBxHw213TNcu/GaadpEelPYeIJ7O7ZCD9rnWKFmnOAOSGUc5Pyda7
iuO8A+INR1258VpqGmLpq6frc1lassTJ9qgWOJlmO77xJdhuHHy+1dhketAC0UmR60ZHrQBw/wAT
td0zQT4T/tLSI9W+2a/aWdt5hA+yzvv2TjIPK4PTB5613Ncf8QvEOo6B/wAI1/ZumLqf27W7ayud
0TSfZ4H3b5ht+6VwPmPAzzXX5FAC0UUUAFcP8Ntd0zXLvxmmnaRHpT2HiCezu2Qg/a51ihZpzgDk
hlHOT8nWu3yK4/wD4g1HXbnxWmoaYumrYa3NZWrLEyfaoFjiZZju+8SXYbhx8vtQB2NFJmjNAC1w
3xO13TNBPhP+0tIj1b7Zr9pZ23mED7LO+/ZOMg8rg9MHnrXcEgdSK5D4heIdR0D/AIRr+zdMXU/t
2t21lc7omk+zwPu3zDb90rgfMeBnmgDsKKTNGaAFopM0ZoA4f4Y67pmvHxZ/ZukR6T9j1+7s7nyy
D9qnTZvnOAOWyOuTx1rua4/4e+ItQ1//AISX+0tMXTDY63c2VttiaP7RAm3ZMd33i2T8w4OOK6/I
PegBaKKKAOG+J2u6ZoJ8J/2lpEerfbNftLO28wgfZZ337JxkHlcHpg89a7muP+IfiHUdA/4Rr+zd
MXU/t2t21lc7omk+zwPu3zDb90rgfMeBnmuvyKAFopM0ZoAWuG+GOu6Zrx8Wf2bpEek/Y9fu7O58
sg/ap02b5zgDlsjrk8da7jI9a5D4e+IdR1//AISX+0tMXTDY63c2VttiaP7RAm3ZMd33i2T8w4OO
KAOwooooAK4f4o69pugWnhqTU9Ij1dbrX7Czt1lIH2eeSULHOMg8oeR0PuK7iuO+IniDUfD1voD6
bpi6o93rdlZTq0TSeRBJIFkmG3oUHO48DvQB2NFFFABRRRQB+b/xt+IXhfwr+0Z8WbPW/Emk6Pdn
V7OVYNQv4oHZDpGngMFdgSMgjPTIPpXK/wDC5/h9/wBD34a/8HFv/wDF1+o2ASPSlPTrivzzMOCs
BmOKni6spc0ux+VZr4eZZm2MqY2vOSlN302Py4/4XP8AD7/oe/DP/g4t/wD4uj/hc/w+/wCh78M/
+Di3/wDi6/Uj8KPwrz/+IeZZ/PI8r/iFWT/8/J/eflzY/E7wfr/i7wNYaX4q0TVL+bxf4e8u1stR
hllfGrWpOEViTgAk4HABNfqIABz3pGAIx3pRwB/WvtMmyehkmHeGw7bi23r5pL9D9C4fyDD8O4WW
Ewsm4uTlr3aS/Q8L8LfCHxDpvxrkku0tz8O9I1PU/EuiRLKN0eo6hDCjkf8ALRmSWbX5HWQmMLqd
uE3mPbbWvhTYeO/APhfwd8MoPDPk2nheystLn8Z3k8EmnX9lbIkYa3t45/tIuZo1QFJUSOFmlYS3
AhRbn26ivfPqD5z+APwQhmsdR13xn4Y8UaFrreLNX1iHRtb8SyXWnlZ9SnvbScWFvezWQZBNEeUD
LPCZB8wSVk8QfDrxa3w88d/B+18PXF5pvjCbXWj8apc2y2Nhb6tc3NxMZ4GlFwZ4PtUyJHFG8c2y
AtNB5sn2f6NooA8n8R2GvyftM+B9Ug8MahdeG7PwzrGnXeuxz2gt7ee6uLCWJGjacTtxp7glImAM
0XJHmGP1iiigAorG8R+KtD8H2iXmvazp+iWreZtn1G6S3Q+XDJPJhnIHywwzSN6JE7HhSRynij4p
7f8AhHrDwVbaf4v13xHZS6ppKPqP2fTpbCLyfNu3u0jmxF/pNuq+XHIztPHhRGJJYwD0Sivn3Ufj
38SrXVtI0dPhTp9jquoeJpvDMa634mktreZ49JGo/a7eWKxm862fyruJW2q4MUe9Ed5Y4LUP7QHi
pvFnhzw1L4L0dNWn8WP4T1wp4hla3sZf7KGrJNav9iDXSmz3ZDrARMAnKHzQAe8UV5lH8TvEJ+Lf
jTwmPCVveaboGgWeuW11YasGvtQa5e5jit1t5Yo4o2L2VyNzXG3/AFJJG9/K3/hT46PxP+Fng7xk
LH+zB4i0Wy1f7F5vm/Z/tECS+Xv2ru278btozjOB0oA5b9pT/knWkf8AY5+E/wD1IdOr1PcM9RXi
v7Xur3OhfBKXU7a2jurqw8ReHbuG3llMSSyR61ZOqM4VigJUAsFYgEnBxivLF/bG+ICjH/Cu/DR9
z4nuP/kGvEzDOcDlcoxxlRRb2ufOZpxBluTSjDHVVByV1fqfX/HvRxXyF/w2R8Qf+ie+Gf8Awprj
/wCQaP8Ahsj4g/8ARPfDP/hTXH/yDXkf635N/wBBCPE/174e/wCglH13n16Vyfg3UPEF34j8dw61
bGDTbTWY4dEk8sL51mdPs3d8/wAX+kvdLk/3Mdq+bz+2N8QD/wA098Nf+FNcf/INcx4U/bE+I/8A
b/jTzvCOiahEdXjMNvceIp1SxT7DaAwxEWRLIW3S5ODuncYwoJ0jxXk802q603/L82aQ42yGalKO
JVo6vyV0vzaPuXijj3r5C/4bI+IP/RPfDX/hTXH/AMg0f8NkfEH/AKJ74Z/8Ka4/+Qaz/wBbsm/6
CEZ/698Pf9BKPrzOeuK5Lx9c+JbdvDv/AAjcfmbtZtk1L5UO2yO7zj83T+Hkc+lfN4/bH+IIP/JP
PDP/AIU1x/8AINcv4+/bA+IzWujXMfhHRdNS21izeUWniS4JulaURCBs2Y+RmkUsecBcgE4FaU+K
8nqSUIV02y6fG2Q1pqFPEJt6L1Z9zce9HHvXyF/w2R8Qf+ie+Gv/AAprj/5Bo/4bI+IP/RPfDP8A
4U1x/wDINZ/63ZN/0EIj/Xvh5f8AMSj69496OK+Qv+GyPiD/ANE98M/+FNcf/INH/DZHxB/6J74Z
/wDCmuP/AJBo/wBb8m/6CEH+vfD3/QSj6P8AAlx4juLrxR/wkSbIk1qZNKwqDdY+XFsPy9fnMnLc
/pXWjg1+ZWof8FRvE3wj8Y+LNA1z4e2+vXX9o/a43TxM4itYpYIWSCPdZ5Kryeg5ZuOMlT/wWWvP
+iQQf+FO3/yHX7NlfBef5zgqWYYDCudKolKMk46p7btM+to5hhq1KNWE/dkk16NXR+mmPajHtX5l
/wDD5i9/6I/B/wCFO3/yHR/w+Yvf+iPwf+FO3/yHXq/8Q34r/wCgKX3x/wDkjX65Q/mP0I8fXHiS
A+HP+Ebj8zfrVsmpfKh22J3ecfm6fw8jn0rrR+Ffmh4d/wCCpOsfF/4lfDnwtbeA28LJqPinTbW4
vLbxAZy8Us6wtGyfZk3KfMBI3fw1+l/oa+QzfI8wyKssPmNLkm1dLTZtq+jfZm9OpCqrwdx1FFFe
KajcHFcj4FuPEc9z4oHiKPy449alTSvlRd1j5cWw/L1+cyctz+lddnvXwf8AET9uTxT8CPjH8RPB
s/hS38VxWWsLNb3d3rj2/lQzWlvKkKxi3faqh89erNx3PNXr08PDnquyPWyvKcbnOI+qYCnz1LN2
62R94cUce9fnx/w9G8Q/9Et0z/wpJP8A5Eo/4ejeIf8Aolumf+FJJ/8AIlef/bGB/wCfh9p/xDji
n/oDl98f8z9BSAefXsa5Px9c+JLY+HB4cj379Ztk1LKodtid3nH5un8PI59K+Jj/AMFRvEJH/JLd
M/8ACkk/+Q653xj/AMFLvFepRaO9r4DtdLW01S2uJhb+I5CbmMMQYGP2UYRtwz1xjoelNZvgpNJV
DKp4ecTUoOpUwjSSu3ddPmfpTxRx71+fH/D0bxD/ANEt0z/wpJP/AJDo/wCHo3iH/olumf8AhSSf
/IlL+2MD/wA/DVeHHFL1+py++P8AmfoPx70cV+fH/D0bxD/0S3TP/Ckk/wDkSj/h6N4h/wCiW6Z/
4Ukn/wAiUf2xgf8An4H/ABDfin/oDl98f8z7Z8BT+JJz4j/4SSPy9mtXKab8qDdYjb5J+Xr/ABcn
n1rrQMV88fsV/GnVvjt4F8Y6/q9u1ncQ+Kbm1jtftjXSQxG2tpljRyiEKvnYxjqD619DKTz1/GvV
pzjUgpxd09Ufn2Kw1XB154aurTg3Frs07MkoopDWhzHI+PrjxJB/wjn/AAjcfmF9atk1L5UO2xO7
zj83T+Hkc+ldXuGeorxr9qXxlr3w6+HGn+JvD6CabTte037RZvdvardRTXC2/lNIqOQpeaMt8p4B
OCRg+Tr+2N8QFGP+Fd+Gj7nxPcf/ACDXh5hnOByuUY4ypyt7XPnM04hy3Jpxhj6qg5K6v1Pr/j3o
496+Qv8Ahsj4g/8ARPfDP/hTXH/yDR/w2R8Qf+ie+Gv/AAprj/5Bryf9b8m/6CEeJ/r3w9/0Eo+u
geCen1rlPAFx4kuD4i/4SNAmzWrlNN+VBusRt8k/L1/i5PPrXzef2x/iAevw78Nf+FPcH/2xr0f9
k/4k698S/D/jm88RRJb31j4ontVghvWu4oontLW4REdo0O1RcbcbRyDXp4DPMvzOq6WEqc0kr28t
P8z18s4kyvOKroYGspySu15XS/U95ooor3z6cK5H4g3HiS3ttCPhqPzZn1qzS/8AlQ7bEyD7Qfm9
E7jn0rrq5H4haPr+sW2hLoF99hlt9Zs7m9PmmPzbRJAZo+Ac7l42ng0AddRRRQAUhpaKAPxs/b0+
O/xK8J/tc/EHRtC+IXirQ9IsmsFt7DTNbubaCINp9s7bY43CjLu7E4ySxrwL/hpj4w/9FY8c/wDh
S3v/AMdr0T/goqf+M1fib/1007/02WlfOWc1/fPAmV4Ctw5g6lWhCUnBauMW/wAUfLYmco1pJM9J
/wCGmvjF/wBFY8df+FLe/wDx2j/hpr4xf9FY8df+FLe//Ha82z7UZ9q+/wD7Hy3/AKBaf/gEf8jl
9pP+Zn0L8Af2ifitqvx8+GNjffEzxjfWN34q0m2ubW71+7linikvIkkjdGkKsrKzAgg9a/dE1/PX
+zlx+0b8Jen/ACOWi/8ApfBX9Cn8q/jjxgwtDC57ShQgoJ0lokkvil2PoMvk3Sbbvr/kOpa87039
oP4W6x/ZX2D4l+EL4ateNpun/ZtdtZPtl0PLzbw4kPmSjz4couW/ex8fMM8tB8cfF+sadoHibQfh
x/b/AIC8Q3unQ6ZqdlqxOo/ZLq4hjGo3FkbfEVsIZHnG2WSUL5XmxQZmNv8Ahx6Z7bRXz74Y/aD8
b3mk2viDxJ4D0DS/C7eJm8K3E+l+KZ769juv7WOkq6QPp8KPEbraSTMrCIltpYeWbQ/aB8U2/wCz
r48+Jd94L0eLUvC02sKdFt/EMssN1FplxLBcv9pNkpRma2uDGvlMGAi3Mm9vLAPeKK8n8RfFPxf4
NvNKudc8F6faeHJL3TNIvr+314zXAvb2aC3Q2kH2cCa2S4uoo2lmkt5MJMwgIWMS+sUAfPn7UOiQ
XPjP4E6wng/T/GGtab4zme0tLoQpOUGjalO6wSyqVWXdbQyorMiNNBBukiCiRK3hL4d+Lfh+PDfj
YeHbjWtStJvFTXXhWzubZL5LfWtYTUYyskkq27TweTDHJH5ojO+Zo5n8pFn9p8SfD/wt4x1bRtT1
/wAM6PrepaJN9p0u91KwiuJrCXcjeZA7qTE26OM7lIOUU9hXR0AfOXxT8L+Nfihe/Csa14P1hNNj
8WS6pexeG9bTT7vQtPOm3VpEtzdx3sUkk5lu1lkFoWVUWWIGbYr3PV+Jfg5F4VsPCmpeDdPuNRu/
DHiB/EU9jeahJcX2ts+n3NhIrXt1IzvOsNyPLM7lT9mhhLwx4ki9iooA8n8H2GvnxT4z+JWo+GNQ
0u71LRrHS7Pwm89pLqLpYyX0wZ5EnNsks0l86KgmZFWON3lUyPHDb/Zq0PWfC37Pnw40DxFo9xoG
uaL4fstKvbC5lglaOW3hWFmDwySIysY96kNnay7grZUem0UAeFftpf8AJv8AqP8A2G9B/wDTxZ18
uV9R/tpsB+z/AKjkgf8AE70H/wBPFnXy5X4T4jU5zr0HGLej/Q/mjxapVKmJwrhFv3XsvNBRRRX4
57Cr/I/uZ+A/Vq/8j+5hXNeFP+Q/4z/7C0f/AKQWldLXM+EznX/Gntq0f/pBaV6mFo1fY1/dfwro
/wCeJ7WCw9ZUMT7j+BdH/PA6aiiivL9hV/kf3M8b6tX/AJH9zCua+IX/ACALX/sLaZ/6XwV0tcz8
QiBoFrk4/wCJtpf/AKX29ell1CqsbRbi/ij0fdHrZTh6yzDDtwfxx6PujpqKKK8+VCrd+4/uZ5Us
NX5n7j+5hRRRU+wq/wAj+5i+rV/5H9zPgj9pb/kuniv/AH7X/wBJIK80PWvS/wBpX/kuniv/AH7X
/wBJIK80PWv9xfCjEUafBGVRnNJqlHRtdj+yspjJZbhU1/y7h/6ShKKKK/XPreG/5+R+9Hqcr7Ho
v7OP/Jxvwl/7HHRf/S+Gv6FR0r+er9nE/wDGRvwl/wCxx0X/ANL4a/oVHSv4w8ZakKufUnCSa9mt
tftSPosvTVJ37/5C0UUV+DHqDT3r8dP2qrMWH7UnxVjFwt0G1eKXzEPA32Vs+zqeV3bT7r2r9izz
X45/tUQ2kH7UnxVWznNxCdXidnPaRrK2aRen8Lll/DvXzuepvBNJdUfsfhROFPiWEpuy5Zb+h5fR
RRX5l7OfZn9y/W8P/wA/I/egqjrP/HpH/wBfEH/o5KvVR1ogWceTj/Sbf/0cldGHhP2sNOq/M8jN
sVh3gK6VRfC+q7MvUUUVg6c77M9SGLw/Kv3kfvQUUUUvZz7Mv63hv+fkfvR+in/BLv8A5I745/7H
CX/026fX2T3FfG3/AAS8IHwd8c8j/kcJf/Tbp9fZPcV+wYJNYWkn/KvyR/m9xRJSz3HNPT2s/wD0
pi0UUV3nzB85ft2aeL74I6fM14tsbTxRok4jY83BN9FH5Y56jzC/fiM/UfOlfRP7d0FhL8E9Ne8u
WguIfFOiPZxr0ml+3RKUPHTy2kbtyo+h+dq/CPEanOdeg4xb0f6H8z+LNKpUxOFcIt+69l6BRRRX
477Cr/I/uZ+BfVq/8j+5hX0B+w3/AMi/8UP+xw/9xGmV8/19AfsOMBoHxQGR/wAjeP8A00aZX6p4
d0qkMyquUWlyPp/eiftnhTRqU84rOcWl7N7r+9E+mKKKK/oU/qkK4r4neHU8SWnhxH1iHRxZ69Y3
oaY4+0GOUMIF5HzP0HX6Gu1riPijpuh6naeG113UpNNjh8QWE9m0Yz512soMMR4PDNwen1FAHb0U
UUAFIaWkNAH4z/t7/BP4keKf2vPiHq2h/Dnxhrmk3T2DQahpmgXl1bzBdOtVbZJHGyth1ZTg8FSO
1fP/APwzp8Xef+LS+P8A/wAJTUP/AIzX9Cu4jjvSDOecfhX6nlfiXxBk+Dp4HCyioQVleKbt6nDP
B0qknJ3uz+e3/hnT4u/9Ek+IH/hJ6h/8Zo/4Z0+Lv/RJPiB/4Seof/Ga/oW3Ubq9b/iLvFH88P8A
wBEfUKPmfhN8APgD8VNO+Pvwvvb34XeNrCytPFek3Nzd3nhu9hhgijvIneR3eIKqqqkkkgACv3YH
SkyM9aXIAzX5zxBxHj+JsTHF5g05xXKrKysrvb5nXRoxox5YnhPhb4Q+IdN+Nckl2kB+Hekanqfi
XRIllG6PUdQhhRyP+WjMks2vyOshMYXU7cJvMe22tfCmw8d+AfC/g74ZQeGfJtPC9lZaXP4zvJ4J
NOv7K2RIw1vbxz/aRczRqgKSokcLNKwluBCi3Pt1FfOGx85/AH4IQzWOo674z8MeKNC11vFmr6xD
o2t+JZLrTys+pT3tpOLC3vZrIMgmiPKBlnhMg+YJKyeIPh14tb4eeO/g/a+Hri803xhNrrR+NUub
ZbGwt9Wubm4mM8DSi4M8H2qZEjijeObZAWmg82T7P9G0UAeD/FG+8ceIfi34a0qD4Z6xq/grRdTs
b86kmpadFZ31wz7WlnjkufN8iySQ3KRiBpJbqGAqYRArze8UUUAFFFFABRRRQAUUUUAeLftZaJa+
JfhDBpGoCV7G/wDFXhi0uFgneCQxya9YIwWSNldDgnDKQw6ggjNZp/Yj+EmeNN8Tf+Frrf8A8mV0
n7SmR8O9I4/5nPwn/wCpDp1ep4JNZSpwnbmV/UynTp1Lc8U7eR4V/wAMRfCP/oHeJf8Awttc/wDk
yj/hiL4R/wDQO8Tf+Ftrn/yZXu+z3pNnvUewo/yL7kZ/VaH8i+5HhH/DEXwk/wCgd4l/8LbXP/ky
uZ8Kfsg/BHWNd8Z2un2Pil7vStWjs9QWTxfrEYSc2NpMoVhdguPKmhO5iTklc7VUD6e2+9cT4B1b
R9S8V/Em20zS/wCz73T/ABBDa6pcZz9uuTpVhKs3tiCW3i/7Y01QpLaK+5DWHoraC+5Hn3/DEPwj
/wCgd4m/8LbXP/kyj/hiL4R/9A7xN/4W2uf/ACZXu2z3o2e9HsKP8i+5C+q0P5F9yPCP+GIvhH20
7xL/AOFtrn/yZXNeOP2SPgj4dj0SPVdJ8UTJqWrW1hboni/WZB57NujZg15wFZA24cgqCOa+nNtc
R8Ttc03QT4T/ALT0iPV/tmv2lnbeYQPss779k4yDyuD0weetCoUk7qK+5AsPRTuoK/ojgP8AhiL4
R/8AQO8S/wDhba5/8mUf8MRfCP8A6B3ib/wttc/+TK922e9Gz3o9hR/kX3IPqtD+Rfcjwn/hiL4R
/wDQO8Tf+Ftrn/yZR/wxF8I/+gd4m/8AC21z/wCTK922e9G33pewo/yL7kL6rQ/kX3I+SNH/AGEv
2cPiNqviS5fwXquoX2nam+m3tzqHiPVGkeaOKM8N9qJZQrIAW54x0ArWH/BND9m/OP8AhXtxn/sY
tVx/6VV7V8Ntd03XLzxkmnaRHpTWGvz2d2yEf6XOsULNOcAckMo5yfk6125H1ruhiK1OKjCbSXZs
3UYrRLQ+X/8Ah2d+zh/0T6f/AMKPVf8A5Ko/4dnfs4f9E+n/APCj1X/5Kr6gwaMGtfreI/5+S+9h
yx7HylcfsR/s5/B7xN4O8QWngi8s9XXX7JNLuItb1CcR3ok8yFnSS4KlQ0YJyD0HBr6txxXEfE7X
NN0E+FP7S0iPVvtmv2lnbeYQPss779k4yDyuD0weetdxiuapUnVfNUbb8ytth1FFFSMZ1HYV8z3H
7J/wM+NnjPxp4h1Dwxql3ri6zJa6pcDXdQtFluUiiyVjguFTbsMYztB4r6Zxx0rh/hvrema7d+M0
03SY9Kaw1+ezu2jI/wBLnWKFmnOAOSGUc5PydaTSkrNaFQnKm+aDt+Z5N/w7v+An/Qoan/4VWr//
ACXR/wAO7/gJ/wBChqf/AIVWr/8AyXX0hijFRyQ/lRv9bxP/AD8l97Pm/wD4d3/AP/oUNT/DxVq/
/wAl1zvjL9hv9nTwuuiDUvCGsldT1S3063EXibVXHnPkx7t13woKZyOQQMV9Z4Irh/idrum6EfCZ
1LSI9W+2a/aWdt5hA+yzvv2TjIPK4PTB560ckV0QPFYhqzqSt6s8m/4d3/AT/oUNT/8ACq1f/wCS
6P8Ah3f8BP8AoUNT/wDCq1f/AOS6+kMUYo5IfyoPreJ/5+S+9nzf/wAO7/gJ/wBChqf/AIVWr/8A
yXR/w7v+An/Qoan/AOFVq/8A8l19IYoxRyQ/lQfW8T/z8l97PI/2dvAngH4c+HvE+ifD3TbzTNPt
9fuUvkvbua6Z7xI4o3ZZJpJHK7Y41GT/AA9K9cT7vX8TXEfDHXNM14+LP7N0iPSfsev3dnc+WQft
U6bN85wBy2R1yeOtduFIPt6VokrWRzSk5O7f+bH0UUUAeV/H3wx4K8b+HNB0Dx1Y3eoaXqGuWcFq
ljcy2zreZZoX8yJ0dApUnKtkHFcwf2I/hJnjTfE3/ha63/8AJleg/E7XdN0E+FP7S0iPVvtmv2ln
bbyB9lnffsnGQeVwemDz1rtsEms5U4TtzK/qYzpU6lueKbXkeFf8MRfCP/oHeJf/AAttc/8Akyj/
AIYh+Ef/AEDfE3/hba5/8mV7vs96NvvWfsKP8i+5EfVaH8i+5Hgw/Yj+Eh/5h3iUH38ba3/8mV0n
wA8HeCPBOj+KtL8D2eoWtrFr9wmoHVL6e8llvEihidhLPJI5Xy44lGW6L0FepgE9sVxPwz13TdeP
iv8AszSI9J+x6/d2dyYyP9KnTZvnOAOWyOuTx1q40oQ1jFJ+WhcKNOm7wil8juqKQUtamwVw/wAU
pvD0Fn4bPiKC4uI21+wSxFuSCl6ZR5DNgj5Q3Xrx2NdxXD/FHXtN0C08NSanpEerrda/YWduspA+
zzyShY5xkHlDyOh9xQB3FFFFABRRRQB+Vn7WnxW8daH+1B8RdO0vxx4n0rTbS5s47exsNbureCFW
061dgsaOFXLuzHA5LEmvKT8bPiR/0Ufxn/4UV7/8drrv2y/+Tsvif/1+WP8A6arKvHRivy3M69WG
MqRjNpX2TZ/evAmUZdiOHMHUrYeEpON7uMW3q+rR2n/C7fiT/wBFH8Z/+FFe/wDx2j/hdvxJ/wCi
j+M//Civf/jtcXj6UY9xXk/Wa/8Az8f3s/QP7Cyn/oEp/wDgEf8AI9X+GPxm+Ilx8Wvh5bzfEHxZ
c29z4q0e2nt7jXruSKaKS/hjkjdGkKsrIzKQc9a/YE/dGP1r8TvhVn/hcXw0/wCxw0L/ANOVvX7Z
jBJBFfoXD85VMNKU3d3fW/RH8deL2EoYPPaVPDU1BOknaKSV+aXYcOlLXk+j/tNeAdd/4R/7JPr5
/t7Wrjw9p/neFNVh8y/gz58Lb7YeVs2y7mk2qPIuMn9xLs5/QvHvxY8deGfCnjvwtaeGL3wn4mm0
u7g0C7t5odS0/SLieFpLp7rz/KmnFqzubdYowjOQstx5IFz9Mfh57xRXzR4X+LHxTs/C9t4u8R6v
4Q1XRl8Zt4SuNJ0vw7dWVxJ/xPzoy3CXL6hMqYbbcFDC2QDHuBPmC0/xc+Ith+yz8TPH13f+F7rx
X4Ym8RNaGHRLmKxki0q6uICkkJvWctMLORtwlATzkG1/LPmAH0bRXiPiz4heN/AvjzwRo99q/hC/
n1+8g0y18PW9nPDqOs7Ylk1C/hle4KWkVuhmmMDJcZWCNPP826RU9uoAKKKKACiiigAooooA8q/a
V/5J1pH/AGOfhP8A9SHTq9Vryr9pX/knWkf9jn4T/wDUh06vVaACiiigAri/BPiGfWvE3xBs5dJT
T49I12KyhuUQqb9G0yxnM7Ej5iGnaLIzxCB2IHaVyPg6/wDEF54j8dw6zbeTp1prMcOiP5YXzrI6
dZO75/i/0l7tcn+5jtQB11FFFABXH/EPxDqOgf8ACNf2dpi6n9u1u2srndE0n2eB92+YbfulcD5j
wM812Fcj4+uPElv/AMI5/wAI3H5m/WrZNS+VDtsTu84/N0/h5HPpQB11FFFABRRRQBx3gHX9R125
8VpqGlrpq6frc1lassTJ9qgWOJlmO77xJdhuHHy+1djXI+BbjxJPdeKB4ij8uJNamTSvlQbrHy4t
h+Xr85k5bn9K66gAooooA4/4h+IdR0D/AIRr+ztMXU/t2t21lc7omk+zwPu3zDb90rgfMeBnmuwr
kfH1x4kt/wDhHP8AhG4/M361bJqXyodtid3nH5un8PI59K66gAooooAK47wDr+o67c+K01DS101d
P1uaytWWJk+1QLHEyzHd94kuw3Dj5fauxrkfAtx4knuvFA8RR+XEmtTJpXyoN1j5cWw/L1+cyctz
+lAHXUUUUAFcf8Q/EOo6B/wjX9naYup/btbtrK53RNJ9ngfdvmG37pXA+Y8DPNdhXI+PrjxJb/8A
COf8I3H5m/WrZNS+VDtsTu84/N0/h5HPpQB11FFFABRRRQBx/wAPPEOo6/8A8JL/AGjpi6Z9h1u5
srbbE0f2iBNuyY7vvFsn5hwccV2Fcj4BuPElx/wkf/CSR+Xs1q5TTflQbrEbfJPy9f4uTz6111AB
RRRQBx/xD8Q6joH/AAjX9naYup/btbtrK53RNJ9ngfdvmG37pXA+Y8DPNdhXI+PrjxJb/wDCOf8A
CNx+Zv1q2TUvlQ7bE7vOPzdP4eRz6V11ABRRRQAVx/w88Q6jr/8Awkv9o6YumfYdbubK22xNH9og
TbsmO77xbJ+YcHHFdhXI+AbjxJcf8JH/AMJJH5ezWrlNN+VBusRt8k/L1/i5PPrQB11FFFABXHfE
TxBqPh630B9N0xdUe71uysp1aJpPIgkkCyTDb0KDnceB3rsa5H4g3HiS3ttCPhqPzZn1qzS/+VDt
sTIPtB+b0TuOfSgDrqKKKACiiigD80P2pf2YPjB40/aM8eeIvDnw/vNd0LVLi0ls7+DU9PhWRUsL
WFwUmuY3BEkTjlR0yMg15d/wxz8e/wDok+p/+DnSP/k2v18CnOTzS4IryKuVYSvN1Jx1Z+hZfx9x
BleGhg8LX5acFZK3Q/IL/hjj4+f9En1P/wAHOkf/ACbR/wAMcfHz/ok+p/8Ag50j/wCTa/YCisP7
FwP8h6P/ABE7ij/oJ/BH5Q/Db9kX436b8UvAmo6h8Nb3TdO0/wASaVf3l3Pq2lukMEN7DLK5WO7Z
2wiMcKpJ6AV+rXBHBoxg9zSgewr08PhqWFhyUlZN3Pis6zzH5/iFiswnzTSST8l/w7PH/DnwQvtF
+NmoeKZtTt5vCiT3up6VogRttpqF5DaRTypGfkjZTa3kolT5pG1m9BCfO1wfDzwF488CaV4a8CWt
5pFl4E8Mw21paa/b3DzatqFnbqqw2stq8HkwsUVEluFlk3qkhjit2mQ23sdFdZ4J4P8AAH9nuy8F
Saj4l8XeAvBFn8RJvEGr6rHr+iIt7d+Ve3U84U3clrBKGRLl7fGCCkYOQHKKuufBvxVdeGPFfw1s
jpDfDvxZNqkt9rdxdyrq9jFqU8097bxWwhMUzF7icRTtLGIllj3wzmBvtHu9FAHk/wASvC/jf4h6
xZ+Hzpfh/T/BlvrWk6v/AG7/AGzPLqLfYry3vvL+w/ZFjG+W38nd9p+VX8zDEeUfWKKKACiiigAo
oooAKKKKAPKv2lf+SdaR/wBjn4T/APUh06vVa8p/aVI/4V3pHP8AzOfhP/1IdOr1XNAC0UmaM0AL
XI+DrDxBZ+I/Hc2s3Pnadd6zHNoieYG8myGnWSOmP4f9JS7bB/v5711ucVxngnw/Povib4g3kurp
qEer67Few2yOWNgi6ZYwGBgT8pLQNLgY4mB7kkA7SiiigArkfiBo+v6wPDv9g3v2L7LrNtc3/wC9
MfnWa7vNj4B3Zyvyng4rrcj1riviX4dj8RDwtv1iDSPsOvWl8vnHH2opuxAvI+Zs8denQ0AdtRRR
QAUUUUAcj4E0fX9JufFDa5em8ju9amudNHml/JtDHEEj5Hy4ZZDtHHPvXXVxHw68PJ4evPGLprEO
qnUdenvmWE5+yFooV8huThhsz2++OK7bI9aAFooooA5H4gaPr+sDw7/YN79i+y6zbXN/+9MfnWa7
vNj4B3Zyvyng4rrq4n4l+HY/EQ8Lb9Yg0j7Dr1pfL5xx9qKbsQLyPmbPHXp0NdrmgBaKTNGaAFrk
fAmj6/pNz4obXL03kd3rU1zpo80v5NoY4gkfI+XDLIdo459663OK4n4deHk8PXfjF01iHVTqOvT3
zLCc/Yy0UK+Q3Jww2Z7ffHFAHb0UUUAFcj8QNH1/WB4d/sG9+xfZdZtrm/8A3pj86zXd5sfAO7OV
+U8HFdbketcV8S/DkfiIeFt+sQ6R9h160vl844+1FN2IF5HzNnjr06GgDtqKTNGaAFopM0ZoA5L4
f6Pr+jjxF/b179t+1azc3Nh+9Mnk2bbfKj5A24w3yjgZrrq4n4a+HY/Do8U7dYg1f7dr13fN5Jz9
lL7cwNyfmXHPTr0FdrketAC0UmaM0Acl8QNH1/WB4d/sG9+xfZdZtrm//emPzrNd3mx8A7s5X5Tw
cV11cT8S/DkfiIeFt+sQaR9h160vl844+1FN2IF5HzNnjr06Gu1oAWiiigArkfh/o+v6OPEX9vXv
237VrNzc2H70yeTZtt8qPkDbjDfKOBmutrivhp4cj8OjxTs1iHV/t2vXd83knP2UvtzA3J+Zcc9O
vQUAdtRSZozQAtcj8QtH1/WLbQl0C++wy2+s2dzenzTH5tokgM0fAOdy8bTwa63NcV8TvD0fiS08
OI+sQ6OLPXrG+DzHH2gxyhhAvI+Z+g6/Q0AdtRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUU
UUAY3iPxVofg+0S817WdP0S1bzNs+o3SW6Hy4ZJ5MM5A+WGGaRvRInY8KSOU8UfFPb/wj1h4KttP
8X674jspdU0lH1H7Pp0thF5Pm3b3aRzYi/0m3VfLjkZ2njwojEksfAftQ6JBc+M/gTrCeD9P8Ya1
pvjOZ7S0uhCk5QaNqU7rBLKpVZd1tDKisyI00EG6SIKJEreEvh34t+H48N+Nh4duNa1K0m8VNdeF
bO5tkvkt9a1hNRjKySSrbtPB5MMckfmiM75mjmfykWcAtaj8e/iVa6tpGjp8KdPsdV1DxNN4ZjXW
/E0ltbzPHpI1H7XbyxWM3nWz+VdxK21XBij3ojvLHBah/aA8VN4s8OeGpfBejpq0/ix/CeuFPEMr
W9jL/ZQ1ZJrV/sQa6U2e7IdYCJgE5Q+aMr4p+F/GvxQvfhWNa8H6wmmx+LJdUvYvDetpp93oWnnT
bq0iW5u472KSScy3ayyC0LKqLLEDNsV7nq/Evwci8K2HhTUvBun3Go3fhjxA/iKexvNQkuL7W2fT
7mwkVr26kZ3nWG5Hlmdyp+zQwl4Y8SRAFq++Kni5Pin4x8IaZ4KsNUj0bRtO1Sxu110xS3b3s88E
azRPbhYIo2tLp5HWSVxGiGOKV38td/4ZePr7xpF4jsdZ0m30bxD4c1IaXqdtYXjXtp5rWtvdo0E7
RRPIphu4clokIfzFAYKHbi4D4z0288efFO28Bahc+INR0bTtI0rwLLqNlHey/Y5rx1knuRM1tD5k
l++VSSXbFAr5aSQwR6v7O9h4gsfC2tt4m8Mah4e1q71qe9ubrVZ7SS61R5Uika4ZbaedYYkZmtYY
WnmeO3tLdS5AGADB/bN8XWfgD4C3fijUIriex0PxB4d1S4itVVpXjh1uxkdUDMqliEIALAZxkjrX
h/8Aw95+D5x/xTHjjH/XjZf/ACXXov8AwUt/5Mr+IP8A100v/wBOdpX4j44HNfvnhrwXlPFOFxFX
MVK8JJLllbRq/Y8rGYipQklHqfrn/wAPevg9/wBCz45/8AbL/wCS6P8Ah718Hv8AoWfHP/gDZf8A
yXX5F4o21+1f8Qg4Y/ln/wCB/wDAPO+v1vI/XX/h7z8HyP8AkWfHP42Nl/8AJdeyfsj/ABZ8J/HT
SPiF498HprEFprHicNeWmtwRRSQXEWmafBtQRyOGQxxRPktnLsMcCvwm5zX63f8ABH3/AJN08X8f
8zlcf+kFjX5L4jcC5PwxlVPGZepKUpqLvK6s1J9vJHfg8VUrTcZdj7rFLRRX85nrkfevG/2pPGnh
j4beANK8W+Kv7Uks9F12xura10iON7i5ufM2Rx4kZVx+8LEll4U85wD7L05618s/8FI5dPX9mK7W
9jke5bW9LFky9Em+1RkluenlCUd+SPqMq0nGnKS6JnbgKMcRi6VGe0pJP0bMsf8ABTT4bkD/AIpf
xmP+3Wy/+S6X/h5p8Nv+hX8Z/wDgLZf/ACXX5vcUce9fnD4gxl+n3H9px8HuGmk/3n/gS/8AkT9I
f+Hmnw2/6Ffxn/4C2X/yXR/w80+G3/QseM//AAFsv/kuvze496OKX+sGM8vuK/4g7w1/08/8DX/y
J+tH7KnxH8L/ABX8OeNPEXhSDWbaC68TTm8h1uOJJUuTbWzkJ5TuDHsaIjJzksD0r3LrXxv/AMEv
zj4OeOsdf+Ewl6/9g3T6+xgcjuK/RMLUdWhTqS3aT+9H8bZ5hKWAzTE4OhflpzlFX3sm0vyJaKKK
6TxjxP8Aav8AH/hP4T/DXT/GvjE6rJpuga3Y3sNro0Uclxc3HmbI4wJGVcfOWOWXhDg5wD4L/wAP
efg+cf8AFMeOMf8AXjZf/JddX/wVJewT9j/XBexu9y2qaaLJk6JN9pQktz08oSjvyR9R+MOOBzX7
94bcFZTxRhK9XMFK8JJK0raNX7HlYzEVKMko9T9c/wDh718Hv+hZ8c/+ANl/8l0f8Pevg9/0LPjn
/wAAbL/5Lr8i8Uba/aP+IQcMfyz/APA/+Aed9freR+uv/D3n4Pkf8iz45/Gxsv8A5Lr2b9kL4teD
/jb4Q8X+LfBcWtW9je+Jrg3kGuxQxyx3Rt7dmCCJ3Ux7GjIJYnJbPSvwk5zX63f8Eff+TdPF/H/M
5XH/AKQWNfkviNwLk/DGVU8Zl6kpSmou8rqzUntbyR34PFVK03GXY+6xS0UV/OZ64wDFeRftMeKP
DvgbwZofiPxGupTxaZ4g0+ays9JSNp7q7aXy4oh5jKgBMhJLOoAU89j67mvnP9u6XT0+Cemrexu9
y3inRBZFeiTfboiS3PTyhKO/JH1HLiZulRnOO6Tf4HJi6kqOHqVIbpNr5ImH7aOhEDPgXxgD6bdO
/wDkyl/4bR0L/oRfGH/fOnf/ACZXzfRX88vxCzdP4Yfc/wD5I/lN+KmeptclP/wF/wDyR9If8No6
F/0IvjD/AL507/5Mo/4bR0L/AKEXxh/3zp3/AMmV830Uv+IhZv8Ayw+5/wDyQv8AiKuffyU//AX/
APJHsPgL9qvwj4Zu/FMGneD/ABtdSXWtTX92JU039zPMkchQYuxkbWQjr97BOQQOtH7aGhY/5EXx
h/3zp3/yZXyZ4TP/ABP/ABn/ANhaP/0gtK6WuzF8e5tRqKEYw2i9n1in/N5nfjfE3O8PVUIRp/DF
/C/tRTf2u70PpD/htHQv+hF8Yf8AfOnf/JlH/DaOhf8AQi+MP++dO/8Akyvm+iuP/iIWb/yw+5//
ACRwf8RVz7+Sn/4C/wD5I9u8TftK+E/Hms+DLDUPC/jHSwnibTmtrlksDEt1JOsEIlC3Lt5ZedQS
qkjr2NfU+cHn07V+b9wf+Kg8FHH/ADN/h7H/AIN7Sv0eBJAJ5z1FfrfCecYnO8FLE4lLmUmtFZWS
T7vufunA+f4viPLZ4vGpKSm4+6rKyUX1b7ktFFFfbH6INJr4j8Tft9/CT9mv4k+O/BVzpvjDWNSj
1uW9v7mztLV7cXE0cbvHGXuEYhOFOV6hsEjBP22eK/Bz9ud9Ok/a/wDiodMjkit/7UjV1l6mYW0I
mPU8GXzCPYjp0r9F4ByLB8Q51HA45PkcW9HZ3Rx4qpKlT5on6Af8Pevg9/0LPjn/AMAbL/5Lo/4e
9fB//oWfHP8A4A2X/wAl1+Re2jbX9Q/8Qg4Y/ln/AOB/8A8X6/W8j9dT/wAFePg9/wBCz45+n2Gy
/wDkuqyf8FFPg/8AHXxf4H8Jx6N420++uvE2mGymks7NYvtP2hFhEpFwzCMuyhiqkgV+SZ616H+z
j/ycb8JP+xy0X/0vgr57PvC3hzL8qxOMoqfPThKSvPS6Ta6GtLG1ZzjF21Z/QsOlLRRX8dH0IUUU
UAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAc54k+H/hbxjq2janr/AIZ0fW9S0Sb7Tpd7qVhFcTWE
u5G8yB3UmJt0cZ3KQcop7CujoooAKKKKACiiigD5f/4KXH/jCv4g/wDXTS//AE6WlfiMCMe9fvZ+
154Y07xp8Fv+Ef1i2N3o+r+J/DNhe24keMywS67YJIu9CGXKsRlSCM5BBriv+HZv7OH/AET6f/wo
9V/+Sq/XOCOPP9UKFal7D2ntGnva1lY4MThfrDTbtY/EbNGa/bj/AIdm/s4f9E9n/wDCj1X/AOSq
P+HZv7OH/RPZ/wDwo9V/+Sq/Tf8AiN//AFB/+THF/Zr/AJj8SMiv1u/4I/f8m5+L/wDscrj/ANIL
CvSv+HZv7OP/AET6f/wotV/+Sq7b9mn4b+FvhHH8RfB3g3wqfC+g6V4mURhru5uTfNJpenzPcF7h
3brKYsKdv7n13V+e8aeIn+tuXwwX1fk5ZqV732TVvxOvD4T6vJyvfQ9sooor8YPRG4zXyv8A8FJL
+2sv2Y7qO4tFuZLrW9Lht5TjMEn2qNy446lUdO33zX1OeOgryv8AaI8LWHjrwZpPhTWPDzeJNC1z
XLGz1G3WS4iaGES+aJ1kgdHjKPHGdwYDseDis6kfaQce6OrB1/quIp17X5Wn9zufjzj3ox7iv1L/
AOHd3wE/6FDU/wDwqtY/+S6P+Hd3wE/6FDU//Cq1j/5Lr4r/AFa/6efgf08vG5JJfU//ACY/LTHu
KMe9fqX/AMO7vgJ/0KGp/wDhVax/8l0f8O7vgJ/0KGp/+FVrH/yXS/1a/wCnn4D/AOI3/wDUH/5M
cL/wS95+Dvjrp/yOEv4f8S3T6+yAO3evG/2aPh1onws0bxroPh3wzL4a0qHxLcGJJrq7uXvALe3U
XBkuZJGbIVU+U7f3fAzmvZV57EfWvs6FL2NKNO9+VJfcj+ac1xv9o4+vjbcvtJylbtdt2/EfRRRW
55h8h/8ABUq/trP9kHXIri0W5lutT02G3lOMwSC6Ry446lEdO33zX4xAjHvX9AH7RvhPTviD4J0z
wjrnhw+J/D2v63Y2WpWnmTxmKAS+b5wkgdHQo8SHduA7HIOK82/4dm/s4f8ARPp//Cj1X/5Kr9d4
J49/1QoVaPsPac7T3taysefiML9YabdrH4jZozX7cf8ADs39nD/ons//AIUeq/8AyVR/w7N/Zw/6
J7P/AOFHqv8A8lV+mf8AEb/+oP8A8mOP+zX/ADH4kZFfrd/wR+/5Nz8X/wDY5XH/AKQWFelf8Ozf
2cf+ifT/APhRar/8lV237MPwy8PfCHQPGfhvwr4Ubwpotv4luDDCbi6nN2Ps9uv2gvcSOxyFC/Kd
v7vgZzn89408RP8AW3L4YL6vycs1K977Jq34nXh8J9Xk5Xvoe2UUUV+MHoja+cP279QtrL4J6ZHc
Wi3Mtz4p0SG3lbGYJPt0Tlx7lUdO33zX0djHrXl37QPh+08Y+FNH8NajocmvaPrGu2FtfRQzXEEl
vGsomWdJbd0kjaOSKNgwYAd+DWFal7anKnfdNHNiKXt6M6V7cya+8+O6K+nv+GIfhL/0DfEv/hba
3/8AJlH/AAxD8JP+gb4m/wDC21v/AOTK/F34bXd/rH4H89Pwju7/AFr8D5hor6e/4Yh+En/QN8Tf
+Ftrf/yZR/wxD8JP+gb4m/8AC21v/wCTKP8AiG3/AFEfgL/iEf8A1FfgfHfhPH9v+NMEE/2tHken
+gWldNXtvw7/AGPvhprk3iqS/wDC/iHSnt9cuLSJo/F+uxtdxRrGkc7E3nzkqAu7phABwK7D/hiL
4S/9A3xLj/sdtc/+TK6cR4ee3mp/WOkVt2SX6Hbi/Cv6zUU/rVrRitv5YqP6HzFRX09/wxF8JP8A
oG+Jv/C21v8A+TKP+GIfhJ/0DfEv/hba5/8AJlc3/ENv+oj8Di/4hH/1FfgfKtzxr3grnH/FYeHv
/TvaV+kI6DjFfMvij9ln4f8AgLWPBOqaL4Y1zVbpfEunki88UazeRWwSXzVuDE90yHy5I42G9SuQ
MivpofQ1+jcO5L/YWElhefmvJu/qkv0P1vhTh3/VnAywftOe8nK9rbpL9B9FFFfUn2g0jpX4N/ty
31rqH7X3xTltLRbKJdUjhaJcYMiWsKSPwOrurOfdu9fvJzXyzefsefCb9oHxv428XeP/AIdO3iF9
bksjdpqmpWgu4IIoooZvLjnVMlFUblUA7c9cmvsuEeIv9WMyjmHs+eyate25zV6Pt4ct7H4mZozX
7cf8Ozf2cP8Aons//hR6r/8AJVH/AA7N/Zw/6J7P/wCFHqv/AMlV+8f8Rv8A+oP/AMmPM/s1/wAx
+JPXpxXof7ORH/DRnwkx1/4THRf/AEvgr9dD/wAEzv2cBn/i30//AIUWq/8AyVWNrP7DPwW+E2ve
C/EnhL4aSz61a+JdNMcz6zqlwLQC4VvtGw3JU+WVDfOCvHIIrx828YFmeX18EsJb2kJRvfa6tc0p
4Dkkpc2zPruiiiv5tPYCiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigDyr9
pX/knWkf9jn4T/8AUh06vVa8q/aV/wCSdaR/2OfhP/1IdOr1WgAooooAK5Hwdf8AiC88R+O4dZtv
J0601mOHRH8sL51kdOsnd8/xf6S92uT/AHMdq66uR8HWHiCz8R+O5tZufO0671mObRE8wN5NkNOs
kdMfw/6Sl22D/fz3oA66iiigArkfH1x4kt/+Ec/4RuPzN+tWyal8qHbYnd5x+bp/DyOfSuurkfiB
o+v6wPDv9g3v2L7LrNtc3/70x+dZru82PgHdnK/KeDigDrqKKKACiiigDkfAtx4knuvFA8RR+XEm
tTJpXyoN1j5cWw/L1+cyctz+lddXI+BNH1/SbnxQ2uXpvI7vWprnTR5pfybQxxBI+R8uGWQ7Rxz7
111ABRRRQByPj648SW//AAjn/CNx+Zv1q2TUvlQ7bE7vOPzdP4eRz6V11cj8QNH1/WB4d/sG9+xf
ZdZtrm//AHpj86zXd5sfAO7OV+U8HFddQAUUUUAFcj4FuPEk914oHiKPy4k1qZNK+VBusfLi2H5e
vzmTluf0rrq5HwJo+v6Tc+KG1y9N5Hd61Nc6aPNL+TaGOIJHyPlwyyHaOOfegDrqKKKACuR8fXHi
S3/4Rz/hG4/M361bJqXyodtid3nH5un8PI59K66uR+IGj6/rA8O/2De/Yvsus21zf/vTH51mu7zY
+Ad2cr8p4OKAOuooooAKKKKAOR8A3HiS4/4SP/hJI/L2a1cppvyoN1iNvkn5ev8AFyefWuurkfh/
o+v6OPEX9vXv237VrNzc2H70yeTZtt8qPkDbjDfKOBmuuoAKKKKAOR8fXHiS3/4Rz/hG4/M361bJ
qXyodtid3nH5un8PI59K66uR+IGj6/rA8O/2De/Yvsus21zf/vTH51mu7zY+Ad2cr8p4OK66gAoo
ooAK5HwDceJLj/hI/wDhJI/L2a1cppvyoN1iNvkn5ev8XJ59a66uR+H+j6/o48Rf29e/bftWs3Nz
YfvTJ5Nm23yo+QNuMN8o4GaAOuooooAK5H4g3HiS3ttCPhqPzZn1qzS/+VDtsTIPtB+b0TuOfSuu
rkfiFo+v6xbaEugX32GW31mzub0+aY/NtEkBmj4BzuXjaeDQB11FFFABRRRQAUUUUAFFFFABRRRQ
AUUUUAFFFFABRRRQAUUUUAFFFYXizwpp3jXRZtJ1Vbl7GZlZxaXk1pJlSCMSQujjkdjz0NAG7RXl
P/DMXgL/AJ4eIP8Awq9V/wDkmj/hmLwF/wA8PEH/AIVeq/8AyTQAv7Sv/JOtI/7HPwn/AOpDp1eq
145qf7KHw21e3SC+sNbuoUmiuFjl8U6qwEkUiyxv/wAfPVXRGB7FQau/8MxeAv8Anh4g/wDCr1X/
AOSaAPVqK8p/4Zi8Bf8APDxB/wCFXqv/AMk0f8MxeAv+eHiD/wAKvVf/AJJoA9Wri/BPh6fRfE3x
BvJdWTUI9X12K9htkcsbBF0yxgMDAn5SWgaXAxxMD3JPO/8ADMXgL/nh4g/8KvVf/kmqdl+yh8Nt
Pur+a2sNcgmvphcXTp4p1UGaQRpEHb/SeTsjjXPogHagD2KivKf+GYvAX/PDxB/4Veq//JNH/DMX
gL/nh4g/8KvVf/kmgD1auK+JfhxPEQ8K79Yh0j7Dr1pfL5xx9qKbsQLyPmbPHXp0Nc9/wzF4C/54
eIP/AAq9V/8Akmql9+yj8N9T8j7Vp+t3H2eVZ4vN8Uaq3lyL911zc8MMnBoA9horyn/hmLwF/wA8
PEH/AIVeq/8AyTR/wzF4C/54eIP/AAq9V/8AkmgD1aivKf8AhmLwF/zw8Qf+FXqv/wAk0f8ADMXg
L/nh4g/8KvVf/kmgDf8Ah14dTw/eeMXTWIdVOo69NfMsJz9kLRQr5DcnDDZnt98cV29ePWf7KPw3
057hrTT9btmuZTPMYvFGqr5khABdsXPJIAGT6Crf/DMXgL/nh4g/8KvVf/kmgD1aivKf+GYvAX/P
DxB/4Veq/wDyTR/wzF4C/wCeHiD/AMKvVf8A5JoA6H4l+HE8RDwrv1iHSPsOvWl8vnHH2opuxAvI
+Zs8denQ12tePX37KPw31PyPtWn63cfZ5Vni83xRqreXIv3XXNzwwycGrf8AwzF4C/54eIP/AAq9
V/8AkmgD1aivKf8AhmLwF/zw8Qf+FXqv/wAk0f8ADMXgL/nh4g/8KvVf/kmgD1auI+HXh1PD954x
dNYh1U6jr018ywnP2QtFCvkNycMNme33xxWB/wAMxeAv+eHiD/wq9V/+SaqWf7KPw3057hrTT9bt
muZTPMYvFGqr5khABdsXPJIAGT6CgD2GivKf+GYvAX/PDxB/4Veq/wDyTR/wzF4C/wCeHiD/AMKv
Vf8A5JoA9WriviX4cTxEPCu/WIdI+w69aXy+ccfaim7EC8j5mzx16dDXPf8ADMXgL/nh4g/8KvVf
/kmql9+yj8N9T8j7Vp+t3H2eVZ4vN8Uaq3lyL911zc8MMnBoA9horyn/AIZi8Bf88PEH/hV6r/8A
JNH/AAzF4C/54eIP/Cr1X/5JoA9Woryn/hmLwF/zw8Qf+FXqv/yTR/wzF4C/54eIP/Cr1X/5JoA6
H4aeHE8OjxVs1iHV/t2vXd83knP2UvtzA3J+Zcc9OvQV2tePWP7KPw30z7R9l0/W7f7RK08vleKN
VXzJG+87YueWOBk1b/4Zi8Bf88PEH/hV6r/8k0AerUV5T/wzF4C/54eIP/Cr1X/5Jo/4Zi8Bf88P
EH/hV6r/APJNAHQ/Evw4niIeFd+sQ6R9h160vl844+1FN2IF5HzNnjr06Gu1rx6+/ZR+G+p+R9q0
/W7j7PKs8Xm+KNVby5F+665ueGGTg1b/AOGYvAX/ADw8Qf8AhV6r/wDJNAHq1FeU/wDDMXgL/nh4
g/8ACr1X/wCSaP8AhmLwF/zw8Qf+FXqv/wAk0AerVxXw08OJ4dHirZrEOr/bteu75vJOfspfbmBu
T8y456degrnv+GYvAX/PDxB/4Veq/wDyTVSx/ZR+G+mfaPsun63b/aJWnl8rxRqq+ZI33nbFzyxw
MmgD2GivKf8AhmLwF/zw8Qf+FXqv/wAk0f8ADMXgL/nh4g/8KvVf/kmgD1auK+J3h1PElp4cR9Yh
0cWevWN6GmOPtBjlDCBeR8z9B1+hrnv+GYvAX/PDxB/4Veq//JNVL79lL4b6mkK3en63crDKk8Ql
8Uaq2yRTlXGbngg8g9qAPYa4v4t/Fbw58EfAGo+M/F13JYeHdOe3S7uooWmMQmnjgVtigsQHlXOA
TjPBrnf+GYvAX/PDxB/4Veq//JNeX/tL/sP6N8WPgr4g8KeE7i90rX9Re0EF5q/iDUrq2iVLuGSU
tE8zq58tH2gr97byv3gAfQPgX4h+Gfib4dg17wlr1h4i0if7l5p1ws0ee6kg/Kw7qcEdwK6Wvl79
kT9gbwZ+ySJdS07VtW8QeKrqHybvUri4eC3de6pao2zb3HmeYwPRhX1DQAUUUUAFFFFABRRRQAUU
UUAFFFFABRRRQAUUUUAFFFFABRRRQB538WvGOt+HZvB+i+HJLCz1rxTrTaRBqOq2r3dvZbLG7vWk
e3SWJpdy2TRBRLHgyh8sE2Nb+D/jW+8e+C/7R1OKCPUbTU9T0a6e0Vkhnlsb+4snnRGZjGsjW5kE
ZZygcKXfbvap8WvB2t+IpvB+teHI7C81rwtrTavBp2q3T2lve77G7smje4SKVotq3rShhFJkxBMK
H3rb+D/gq+8BeC/7O1OWCTUbvU9T1m6S0Znhglvr+4vXgR2VTIsbXBjEhVC4QMUTdsUA7miiigAr
zzw5451zUfjh458IX9jp9vo2j6No+p6bc28ryXFx9rkv45TMCqqmGsgqou7gbi5L7I/Q68x0Hwn4
qs/2hfGHii7s9Hj8Kap4f0vSrOeHUZXvjLaTXkpaS3NuqKrHUJFyJmI8hDg+aRGAenUUUUAFc34z
TxVcaVFB4SuNHsNSlmAkvtbgluobWIKzFxbxvGZ2LBE2+dEFEhfc3liOTpK4b4uxePbjwbJb/Dld
ITxFcTRxNdazevara25P72SFltrgGfaMRiSNo1Zg7rIEMUgAfB/xrfePfBf9o6nFBHqNpqep6NdP
aKyQzy2N/cWTzojMxjWRrcyCMs5QOFLvt3t3NcN8F/DmreDfhh4f8Paxpuj6PcaVC1jbadoN3cXd
paWUTslnEs9wqyystusKvIyrucOQACBXc0AFFFFAHjo+IvinT/jxpfg691DwxqCarDd3/wDwjmmx
SjUtJ0uHckepT3Ty7JVkm8iHyFt42DXTbJJVtJXf2KvJ9S8L+N/G3xN8LXmt6XoGieHPCetXOr2N
3p+sT315qO6yu7KOOW3e0hS3yl6ZWZZZdrRBAGD+YvrFABRRRQByHxI8cnwJodvPb2X9ra1qN7Bp
elaWJfLN3dTNtUEhWYRRrvnmdEdo4IJpNjCMg1fgh41vviV8GvAXi7U4oINS1/w/p+qXUNorLCks
9tHK6oGZiFDOQASTjGSetJ49+D/hz4k6ppWp6yNYg1LS4bi2s7zRdev9JmSKdoWmjL2k8RdWa3hO
1iRmMEYqr+z/APDi4+D/AMD/AAH4Lvbj7Vf6FotrY3cy3c1yjzpGolMbzfP5W/dsUhQibVVUVQoA
PRKKKKACvEfAPxN8WeNvjN4j0m5vrDw9oOmXtzFaeHNW8LX9tquoWsAWB7yG9lnS3miNyd4NvFMq
wzW3mNHJMAvt1eYy+E/FXjb4haJqfiaz0jRtD8J6ncaloy6VqEt5c6jK9tcWaPciS3iW3VYLqYmJ
DMWkdCJVWEicA9OooooAK88+NPxh0z4L+FrXUr2P7XqOqXqaVpFhll+23rpI6Q7lR2GVikbCJJI+
3ZDFNM8UMnoded/FrwdrfiKbwfrXhyOwvNa8La02rwadqt09pb3u+xu7Jo3uEilaLat60oYRSZMQ
TCh96gGt8LvEFx4p8DaZqd3rWn6/dzeaJr7TNMm02Lesro0TWs0sssEsZUxSRyPvWSNwyoQUXrq4
b4P+Cr7wF4L/ALO1OWCTUbvU9T1m6S0Znhglvr+4vXgR2VTIsbXBjEhVC4QMUTdsXuaACiiigDxG
w8T/ABT074x+D/Duuan4QmsNbstS1e80zT9HuklsbW2EEZjjv3uyLiVbi9s13NaRLJGs74iYJG3t
1cN4a8F31h8TvG3i3UZbcvqkOn6Vp0dqzYXT7VJZVaYMvE5ub2+BKkqYlt+AwcnuaACiiigDzz40
+MNd8EeFrW+0aTT9Oge9SLUdf1a1e7s9DtdkjNeT28csTyRb1iiYiRFhWYzyMIoZK1fhdr2ueJ/A
um6n4i006Zqs3mho/Ie386NZXWG58iQmS386JY5vs8hMkPm+U5LoxOV8YPB2ueKrPw1d6Cmn6hd6
FrUWrtomr3L21lqeyGaOOOaVIpSnlTSxXaN5UmJbSLAU4kS18G/BV98Pvh7p+iahJbm4imup1tbJ
ma20+Ka5lmisbcsqkwW0ciW8Z2RgxwJiOMYRQDuaKKKACvB/Dfxm8Van4z8P3N0ukHwn4j8Wax4Q
s9Mhs5UvrKXTxqWbuS7MxSZZDpUn7kQRlPtKfvH8o+b7xXiPhr4Ao/xkl8eavB/ZEemXl3Pomg6R
r99cae084kSXU5rZ/Lt4rmSOaZTHDFhWuLmR5bh5laEA9uooooAK88+P3jrXPhj8DvHnjDw3ZWGp
a1oGjXWqQW+qSvHbt5MbSMXKKWbCqzBBt3kBd8YbevodeefH/wAH658RPgf478J+HI9PfWfEGjXW
kwHVLp7e3j+0RtC0jukUrfIrs4UIdxULlQdwAKnxF8V+KR4+8M+CvCN3pGjalq2majrMmq61p8uo
wpFZy2UJgFvHcW53O1+jeZ5uFEJXY28MnQfCjx0fif8ACzwb4yFj/Zg8RaLZav8AYvN837P9ogSX
y9+1d23fjdtGcZwOlcr4w8MeN7jxT4N8c6LpegXniTTNGvtJvtB1DWJ7azX7Y9jNJJFeJaSO/lvY
BFVrdPMWYsTGU2N1Xwo8Cn4YfCzwb4NF9/aY8O6LZaR9t8ryvtH2eBIvM2bm27tmdu44zjJ60AZX
xI+Ltn8N/F/w60G40zUL+XxlrMmkRzWdncTJabbSefzHaKJ1GWiRdrsmEaWXOyCUjldK/az+GLxa
dAfHWn+JNU1b+0bvS7Tw1p11d3F9a299JbEwW0Imln2FWXzIwVmFvcTxqIkfy974y+C/FXiu98Aa
j4Rm0iHU/DviB9Rkk1sy+SsUmm31kXCRrmVka8STyt0QkEZXzYtwceWfDP4V/GDwj450zXNR0HwQ
1vYQ+LmWK28U3jtLLrGpx6nEh3aYoVY5IEgZuSVkaQLlBEwB6/oHx8+Hvic6jJpnizT7iwsLKTUn
1RmKadNaxY8+4t7xgILiKEsqzPC7rCzKshRiAasf7RHgeTS7i9a61e2uIZorf+x7rw7qMGrzNIsj
RmHTntxdTKyw3DB44mXbbXBziGUp4ra/s1/ETV/APgbwTrA8MabpumfC3Vvh5qeq2Oq3N3NHLdxW
sKXMFu1pEJVVdPhYo0sZzcSKCfJDS6r/ALPuvWXh5l0D4TfCjwhcTanbyz6Z4Z1a90ecxRW90v2m
LWLKzhmin33CRhFt8CE3amRhc7YwDoJ/2nLRR8Qtbu9a8P8Ah34fab4N0TxToPii8iuJ/Nj1D7cq
S3NufJc/PbRKltGfMfIAffKI4/StS+MnhPSfGSeGLrULhNRM8NrJOmnXMljbXEoUw2896sZt4J5P
Mh2QyyLI/nwbVPnR7vFfGvwR+LHiLSvilprXHhjxBP4q+HWn+DItfvtRmsZrq9iW8W4vZ7WKzdIF
c6lcOI45HwbeNeBKTD3/AIX8J/EXw142129t7TwvHp3i3U7PXNYuZNRuZptMlSws7Se0t4BboLlW
Wx+S5eWAqZ9xgbytkoBvy/HrwLBrt/pdzrn2A2JuRLqd9aT2+ls9urvcxR38iLayywrFOZI0lZ4/
s8+5R5Mm3W+HvxP0H4oWeqXGgvqH/Ervf7PvbfU9Ju9NuLefyYpwjw3UUcgzFPE4O3BDjBNeFW37
MV7oereMZtM+H3wp1TUr+bxBqVr4r8Q2DXOoajLqDXciWV1EtupigVrsQvKLiYyQQMoiXzv3PsHw
V8JeJPBvhW6tPEl55kk1689np/8Aa9zrH9mwFI18j+0LpVuLvdIss2+VQU8/ylykSEgHodFFFABR
RRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFF
FABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUU
AFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQA
UUUUAFFFFABRRRQAUV4l4t+MvjfSPilr/hPR/Cvg+Ww0yy0m9TVfEHjCfTftH9oT3FtBF5a6dMBK
bi1kjC7zu3w4JZyi9poPxCmOlyXfi2HSPB9xZeH7PWtYsZ9ajnm0hpVnM63BCqiwRmBwtxv2yGOb
5UEeWAO5orxzxj+094OsfhL498b+B9V0f4oP4R0yTUrzTPDOt2kzKqo7DzJBIREu2ORiSCxWN9iS
MAh9joAKKK8c+Jfx2v8A4a/GfwJ4Tu/DlvceGPE0ErTeIl1Jlm06Vbm2tI0a08k+YstzqGnwqyyZ
BndnVUiLEA9jorxz4i/Hi+8J/GzwF8OdF8OW+uXGvzBdUv7nUms10iJ4bqaBwghkNw0sem6ltVSo
VrZQ7IJUau08OfFbwR4w0N9c0Hxl4f1vRVvY9NbUdN1SC4txdSNGkduZEcr5rNNCqpncTKgAywyA
dfRXIQfFfwPc+FbPxNF4x0CXw3eef9m1hNUgNnP5KSyTbJg+xvLS3ndsH5VhkJwEbC3PxF0SD+z7
/wDt3QB4cu9Fudc/tSXVkXdaxeQ32mIYKSWwSfc8/mBY8w8MJcqAddRXNwfEHwte6Vr2p2/ifR59
N0Ca4ttXvIr+JodNlgXdPHcOGxE0a8urkFRycVV8C/FbwR8UPt3/AAhvjLw/4t+w7Ptf9hapBe/Z
9+7Z5nlO23dsfGcZ2tjoaAOuorm7L4g+FtQ8Z3/hC08S6RdeK7CEXN5oUN9E99bREIRJJAG3opEs
Z3EAfvE/vDPm3wZ/aQt/jp421m18LweH9X8Gaf8Aa4W1vTPEsN3ewzw3It41uLFE/dRXOy5lglWW
QPFCGYIZAoAPbaK88039oP4W6x/ZX2D4l+EL4ateNpun/ZtdtZPtl0PLzbw4kPmSjz4couW/ex8f
MM8rB8cfF+sadoHibQfhx/b/AIC8Q3unQ6ZqdlqxOo/ZLq4hjGo3FkbfEVsIZHnG2WSUL5XmxQZm
NuAe20V8++GP2g/G95pNr4g8SeA9A0vwu3iZvCtxPpfime+vY7r+1jpKukD6fCjxG62kkzKwiJba
WHlm0P2gfFNv+zr48+Jd94L0eLUvC02sKdFt/EMssN1FplxLBcv9pNkpRma2uDGvlMGAi3Mm9vLA
PeKK5zUvGNl4M8Gpr/jfUdI8KQQQwtqNzc6iq2NpK5VSguZViDL5jBFZlQtlflBOKqax8WPBHh/Q
rTXNT8ZaBpui3lkNSttRvNTgitp7UtCguEkZwrRbrm3XeDtzPEM5dcgHXUV5l8e/jlpXwK8A6vrl
wlvq+u2+mXuo6d4bGo29pd6mtrF5tx5IlYFlij/eSFA7KgJCO21G77U9VstFt0udQvLext3mhtkk
uZVjVpZZFiijBYgFnkdEVerMygZJAoAv0V55rHxk0STwroeq+Ebuw8aTeJb1tL8PDTL9Gs7+6VJp
HDXSb0jijS2uHkcBmCwOqJJLsifgPFXx5+Jfg+LUIL34U2EN/Z3ug2K3MviWQaXfPql9LZg2t0ti
zv5D/ZDKskMbjzpCFKrE1wAfQVFfPvir9oPxv4Pi1DS73wJoEvi+xvNBjksoPFM5sDa6tfS6fayi
6OniTzVuYW8yIwBRGQ6yO2Yx3+s/ELXNM+OHhjwPDoOn3Gi6vo1/q8usyao8dxb/AGSW3ieNbUW7
K+WvLXDGZeDKSAUUSAHodFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRR
RQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAfPmqfBvT/iH+1NrfiHxb
8Nvt2l6do2g/8I/4rvTZt5F/Y313dv8AZykxuostc24OURZPs0qvlNnmcD8ftG1fwz49+JfiWy+H
2oC11f8A4QaHT9Zs5NOVNT1m010eSXjNyssuDeWaYl8gSJaSx+fAPKlr7Bqhq2l2XiDSr3TNTsrf
UdNvIXtrq0u4llhniddrxujAhlZSQVIIIJBoA+V7qz8SeKfgb8f/AArL4a1i5+LvinTJLu+0F4bC
xWQ3th/ZdnPABqFxDHBs09t6vdvLut522gSQofqjSb2bUdLsrq4sLjS554Ulksrto2mt2ZQTG5jd
0LKTglHZcg4YjBOV4K+H/hb4b6TNpvhLw1o/hbTJZjcyWeiWMVnC8pVVMhSNVBYqiDdjOFA7Cuko
AK8I+Mvw81H4nfFvTNFu/Durv4K1PwP4i8Nar4jsbmyRbRtRey2hUkl80sEspBuELqGmh+8PM2e7
0UAfGnin4Y/FzXrPQtb1rwFo/iPx5q3iC8m1a3kmt7jQdOtYtBvNHtoZTNOs82nzXF1Jf+RGjPHH
eXalDN/ruK+Jvw78Xa03ifUfGngXX/E9pqF54GtdKuPie/h4o11B4ieOS1YaWJBHFLDqZTzPIdtj
3KtkFEf9AK5vxr8P/C3xI0mHTfFvhrR/FOmRTC5js9bsYryFJQrKJAkisAwV3G7GcMR3NAHyv488
E6j/AMLB8EeOdV+HFvf65rPxSbWdM8PaxLZNqVtbxeFZIXQTK0sCTmXSluIlWby2aO13ywsC0XK/
FT9n/wAYaroGr28XwfuPE2p+IfCfjO0kuIp9IzaXWr62upaVBcNPdIWazZXd2j8xI5ZMwtLlmH2l
4k8AeFvGOr6NqWveGtH1zU9Em+06XealYRXE1hLuRvMgd1JibdHGdykHKKewrpKAPjP4v2eu+Hbv
xJqtj8LtY0LQm03wBpnh6CKXS1hi1C014yQ2ogju8bYpNQt0Me6KOQW06LcQq0U59e/Z01C7/tHx
xaeJ7PUNK+IWoXtt4g1qxvLS3tovLlt1sbWa3S3vLxEiZNLZSrXLyeZFKxCJJEtev6tpdl4g0q90
zU7K31HTbyF7a6tLuJZYZ4nXa8bowIZWUkFSCCCQayvBXw/8LfDfSZtN8JeGtH8LaZLMbmSz0Sxi
s4XlKqpkKRqoLFUQbsZwoHYUAeL+FPh34ttfGPhPRbnw7cW2m+GfHPiDxfJ4ie5tmsb23vxq/k28
CLKbjz1/tWEOJYY4x5E+2RsR+Z2n7N9hr+leANUt/EXhjUPCt/J4m13UI7PUZ7SZ3gvNTub2Fw1t
PMg+S5VGBYEOj8FdrN6xRQB4P4W+EPiHTfjXJJdpbn4d6Rqep+JdEiWUbo9R1CGFHI/5aMySza/I
6yExhdTtwm8x7ba18KbDx34B8L+DvhlB4Z8m08L2Vlpc/jO8ngk06/srZEjDW9vHP9pFzNGqApKi
Rws0rCW4EKLc+3UUAfOfwB+CEM1jqOu+M/DHijQtdbxZq+sQ6NrfiWS608rPqU97aTiwt72ayDIJ
ojygZZ4TIPmCSsniD4deLW+Hnjv4P2vh64vNN8YTa60fjVLm2WxsLfVrm5uJjPA0ouDPB9qmRI4o
3jm2QFpoPNk+z/RtFAHmPx10nxLqHh3RrjwvZXF1f2Opi5ll0mKwfWLaI288Rk0434+ypOWlRHab
A+zyXQX94yA/O/wY+Gni3wv8TfCnifxF8GfEF9qehWfjHd4i1GXw89/cSX+q/b7HDQ3gCymFruFt
qxxpJeuBtieR1+1qKAPhS/8AgZ8RZ/2cr/wtL8Mf7Y1nXvhPpHgw6bqOpWCxaZqWlrqH76Z/NdTv
a6hktWi8z95GvnG1A8xfaP2t/Dp8YfAfRote8LeH9b1pfE3heRdH1GX7RYC6k1iyhkiE725bymWa
WFpfJ3GOV8x4YofoOub8a/D/AMLfEjSYdN8W+GtH8U6ZFMLmOz1uxivIUlCsokCSKwDBXcbsZwxH
c0AeL2fw78WX2qX3xCPh64sdSj8cDxha+Ery5thfT26+H00WS3aWOV7dJz++njHmtG2IUkkh8x2h
T43WvxB+KHwsmgb4f6wlvd+INClh8O6fqdpba1bW1pqMN3eXM12t8kMTOkBSFLeZnQ+W5kBlZbb6
NooA8c8T/s/adB4JvrHws1w2utqek6wt54j1i91Ga7bTr+G9gtJLu5eaaOBnidBt3rEbiWRYmZmV
7fhnTte8efFPS/HGr+GNR8E2miaNf6Nb6ZrFxaT3l495PZTSTH7LPNFHFGLGNV/eM7tLJlIhEjTe
sUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQB//9k=
------=_Part_343555_1040962665.1324366204520
Content-Type: image/jpeg; name="fig2.jpg"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="fig2.jpg"

/9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAMCAgMCAgMDAwMEAwMEBQgFBQQEBQoHBwYIDAoMDAsK
CwsNDhIQDQ4RDgsLEBYQERMUFRUVDA8XGBYUGBIUFRT/2wBDAQMEBAUEBQkFBQkUDQsNFBQUFBQU
FBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBT/wAARCAEjAh8DASIA
AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA
AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3
ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm
p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA
AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx
BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK
U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3
uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD9U6KK
KACiiigAooooAKKKKAI8Hd2xWYNe0/8AtO6sPttv9tt40llt/NXeiOWCMVzkBijgE8Eo2OhrUK5B
r518U+FdO8QfHHx9oH9rato/iDX/AAtYLY3VheXZNs6y32bgRxyKFRGhgyflXc5TINwwfKcmrWV9
Tsw1GnV5ud2sr6eqX5XZ9Bi8gBP7+PjrlxTluYjIF81CT0AYc18c22oa/wCNJIPsWn+JdCXxpZJ4
f03zNb1A/wBk3tp5P2qVt7riVMXWVk2NL/ZMuC32pq7XxBfSaH8QL3S4dW1KPxPZ63pFloGmSapO
Xn0lkshdy/ZmkIulAe/LXDpI6mNzvBiBTJVnLVI9CplsabUXPV+ndLv0d18mfSUk8cAzI6Rg9Nxx
R50e/Z5ilz/DuGfyrwb9pzW0sP8AhHtOn1q8tGvYLvy9L0zUJdPvrt18lRJaSRg+dcx+ZtjtG+SZ
pwT/AKsVm+L9cuYPihq8H9rX1v4tTX9Kt9D0lL6SMT6U4svtci2YcJOgD3+6YxuU8t8MvkjZbqNN
qxz08EqkIycrXv8Ag0v1ueo618afCmgeLrXw3f6g0Oo3NwloknkObYXDoXSBp8eWkrIAyxswYhlI
B3LnX8dePdK+HmjQ6nq/202ktxFaqbGxmu382Q7Y12xKxG5iFBIwWZVzlgD8t+MNK8HX958WdUOs
3gbTfG+iG8aPxHdRx20byaasrOizhE2utyoYgGMxbVK+UoX2n4++LdK0/wCFmj6lf3S6VZ3Wt6HL
G2pD7I+BqFvMwZZdrIyxo7FWAKhGJA2nGUZztK/yO6eDwqnQUL62UtV1UXp23e99vktaf4/+FbTV
dSsJ49cibS7k2t9dSaHeLa2jbVYmWcxeWiBGVzIzBNjB87SDXReK/iBpfg57eO9F9d3VzuaKz0qx
mvrhkXG5/JhVn2KWQF8bQXQEgsoPz5qOmyePPFHxZfSfEN/qGm22v2tvr3hXTfIlW7sW0+1guQcR
tOrjZNkRtub7NJHGFlO9e/s/iT4c0Dx7qfjTUNYsIfCuvaPYWena19qi+xzT21xfedF527YHAmQh
SQWw+0N5cm0jOeql338rir4PCx5HTu3ZNq+t2k7babt9T1Xw94l0/wAV6THqOnytJbybgVdSkkbK
xV0dDhkdWVlZGAZWUqwBBFVvBvjfRfH2hw6voV9Hf6fLJNHFcRn5ZGikaNyvPzLuRgGGQwGQSCCe
W+FJOp6j458RwIW0jXNWju9NnI5uYFsLSDzVHUoZIZNrdHUB1JR1Y+KfDbxzomla14R1Cw8Xm4Ov
eM9d06S1Gpo9s1u0l9NHFFEG2bmlezkEmDIftCKH8t0SrdSSa/rsc8cHTnGok7NWt/4C21+Fr/5n
1iLqE7j5seF6/MOPrR9pi2qwlTDfdO4YNfCy+I9R03wnp+pat8YrvTdYubnS11rTrMtHJZ3Ul5b+
dHdPcTzx27xobs+QkUAbypNyNHC6L6N8UdHvdA8aW2iQ+Pb7wXpVrplvLov26S+v7m9vZJ7jzlgH
2uNryVNtt+5kFx/rI1CAPteY1pP7PY3qZZRg1++urtba6WXzu3p5eeh9VDkUtNQYRRz079adXWfP
hRRRQAUUUUAFFFFABRRRQBHg7u2KzBr2n/2ndWH223+228aSy2/mrvRHLBGK5yAxRwCeCUbHQ1qF
cg186+KfCuneIPjj4+0D+1tW0fxBr/hawWxurC8uybZ1lvs3AjjkUKiNDBk/Ku5ymQbhg+U5NWsr
6nZhqNOrzc7tZX09Uvyuz6DF5ACf38fHXLinLcxGQL5qEnoAw5r45tr/AF/xpJB9i07xNoS+NbJP
D+m+ZreoH+yb208n7VK291xKmLrKybGl/smXBb7U1dr4gvpND+IF5pcGranH4ns9b0iy8P6ZJqk7
PPpLJZC7l+zNIRdKA9+WuHSR1MbneDECmSrc2qX9f8MehUy2NNqLnq/Tul36O6+TPpKSeOAZkdIw
em44o86Pfs8xS5/h3DP5V4N+05riWH/CPadPrV5aNewXfl6XpmoS6ff3br5KiS0kjB865j8zbHaN
8kzTgn/VCs3xfrtzB8UNYgGrX1v4tTX9Kt9D0lL6SMT6U4svtci2YcJOgD3+6YxuU8t8MvkjZbqN
NqxzU8GpwjJyte/4NL9bnqOtfGnwpoHi618N3+oNDqNzcJaJJ5Dm2Fw6F0gafHlpKyAMsbMGIZSA
dy51/HXj3Svh5o0Op6v9tNpLcRWqmxsZrt/NkO2NdsSsRuYhQSMFmVc5YA/LfjDSfB9/d/FnVDrN
4DpvjfRDeNH4juo47aN5NNWVnRZwibXW5UMQDGYtqlfKAX2n4++LdK0/4WaPqV/dLpVnda5ocsba
kDaPgahbzMGWXayMsaOxVgCoRiQNpxlGc7S/D7zvqYPCqdBQvrZS1XaL07bve+3yWtP8f/Ctpqup
WE8euRNpdybW+upNDvFtbRtqsTLOYvLRAjK5kZgmxg+dpBrovFfxA0vwc9vHei+u7q53NFZ6VYzX
1wyLjc/kwqz7FLIC+NoLoCQWUH581HTpPHfij4svpPiK/wBQ0221+1t9e8Lab5Eq3di2n2sFyDiN
p1cbJsiNtzfZpI4wsp3r39n8SfDmgePdT8aahrFhD4V17R7Cz07WvtUX2Oae2uL7zovO3bA4EyEK
SC2H2hvLk2kZz1Uu+/lcVfB4WPI6d3om1fW7SdttN33PVfD3iXT/ABXpMeo6fK0lvJuBV1KSRsrF
XR0OGR1ZWVkYBlZSrAEEVW8G+N9F8faHDq+hX0d/p8sk0cVxGflkaKRo3K8/Mu5GAYZDAZBIIJ5b
4Uk6nqPjnxHAhbSNc1aO702cjm5gWwtIPNUdShkhk2t0dQHUlHVj4p8NvHOiaVrXhHULDxebg694
z13TpLUamj2zW7SX00cUUQbZuaV7OQSYMh+0Iofy3RKt1JJr+uxzxwdOcaiTs1a3/gLbX4Wv/mfW
IuoTuPmx4Xr8w4+tH2mLarCVMN907hg18LL4j1HTfCen6lq3xiu9N1i5udLXWtOsy0clndSXlv50
d09xPPHbvGhuz5CRQBvKk3I0cLovo3xR0e90DxpbaJD49vvBelWumW8ui/bpL6/ub29knuPOWAfa
42vJU2237mQXH+sjUIA+15jWk/s9jepllGDX766u1trpZfO7enl56H1UORS01BhFHPTv1p1dZ8+F
FFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUU
UUAM6DNZHinxFa+FtGl1G8LC3R44yUXJy7qi8fVhWwTgGuB+OPPw3vh0/wBKsv8A0qirKo3GDkui
Z14OnGviadKezaT9G7HfqcqD6ilpkX+qT6CnGtUcjMbxR4itfCujS6lebhbo8cZKruOXdUXj6sK1
1OQD6iuB+OBJ+HF7kY/0qy/9Koq72Mny0+grJP33Hsl+p1ypRWGhVW7lJfJKLX5sdVLUtNttZ0+5
sb62hvLK5jaGa3uIw8cqMCGRlPDKQSCDwQaujp0oxWvkce2qZheFvDb+GLCS1Orajq8fmloTqciS
SQR4AWISBFaRVx9+UvISSWdjW4QfwpQCD1pCCfpQtNhybk7sfRRRQAUUUUAFFFFABRRRQAUUUUAF
FFFABRRRQAUUUhoAToM1jaX4jttU1vWNMh3G40x4458rjl0Drg9+GFbIzzXn/gcf8XM+Imc/8fNn
/wCkqVlJ8ril1f6M66FKNSnVlLeMU1680V+TZ6FRRRWpyGJpniO01XWdX0yEsbjTHjjnyuBl0Drg
9+GFXNS0221nT7mxvreK8srmNoZ7edA8csbAhkZTwykEgg8EGuM8ED/i5vxEP/TxZ/8ApKld+e39
KyhLmi793+Z14qmqFVKH8sX83FN/izD8K+G38MWElqdW1HVo/NLQnU5EkkgjwAsQcIrSKuPvyl5C
SSzsa3CD+FKAQetIQT9K1WmxySbk7sfRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFF
FABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRXAfGjxdqPgrwhp+oaXIsdzN4k0DTXaRA4MF3q9pa
zjB7mKeQA9iQR0rv6ACiiigBp71wXxy/5Jvff9fVl/6VRV3p714r4+vvEN34c+JUWtwGHTbXxJp0
OhuYwvm2Rg013YEfe/0p7tcnn5cdAKxq/wAKXo/yPQy7/faP+KP5o9pi/wBUn0FPpkX+qT6Cn1qt
jge5wHxz/wCScXv/AF9Wf/pVFXdxfcT6D+VcJ8c/+ScXv/X1Z/8ApVFVzx7e+I7JPC//AAjsTS+b
rVtFqO2NX22R3eaxz0A+Xkcisl/FfovzZ6E/9ypf4p/lA7OiiitjzgooooAKK4/4e3viO9PiX/hI
omi8rW7mLTt0apusht8phjqD83J5NdhQAUUUUAFFcf8AEK98R2R8Nf8ACOxNL5ut20Wo7Y1fbZHd
5rHPQD5eRyK7CgAooooAKKK4/wCHt74jvT4l/wCEiiaLytbuYtO3Rqm6yG3ymGOoPzcnk0AdhRRR
QAUUVx/xCvfEdkfDX/COxNL5ut20Wo7Y1fbZHd5rHPQD5eRyKAOwooooAT1rz/wR/wAlM+In/XzZ
/wDpKlegetef+CP+SmfET/r5s/8A0lSsam8fX9Gejhf4WI/wr/0uB6DRXH/D298R3p8S/wDCRRNF
5Wt3MWnbo1TdZDb5TDHUH5uTya7Ctjzjz7wR/wAlM+In/XzZ/wDpKlegDpXn/gj/AJKZ8RP+vmz/
APSVK9AHSsaXwv1f5s9DH/xo/wCGH/pERaK4/wCIV74jsj4a/wCEdiaXzdbtotR2xq+2yO7zWOeg
Hy8jkV2FbHnhRRRQAUUVx/w9vfEd6fEv/CRRNF5Wt3MWnbo1TdZDb5TDHUH5uTyaAOwooooAKKK4
/wCIV74jsj4a/wCEdiaXzdbtotR2xq+2yO7zWOegHy8jkUAdhRRRQAUUUUAFFJketGaAFooooAKK
TI9aM0ALRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAHlX7Sv/JOtI/7HPwn/wCpDp1eq15V+0r/AMk6
0j/sc/Cf/qQ6dXqtABRRRQA0968X8f6f4hs/DXxIm1m487TrvxHp02iJ5gbyrIQ6cjpj+H/SUu2w
f7+e9e0HvXiHjnw9Po3h74n3kurJqMereJ9OvYbZHLGwRbbTIDAwJ+UloGlwMcTA9yTjV/hS9H+R
6GXf77R/xR/NHt0X+qT6Cn0yL/VJ9BT61WxwPc4D45/8k4vf+vqz/wDSqKr/AI7sPEN/H4Z/4R65
+zeRrFtNqPzhfMshu81OeucrxVD45/8AJOL3/r6s/wD0qiq18QvDs/iKPwqINXj0n7Drdrevvcr9
pRN2YBgjJbPT2rJfxX6L82ehP/cqX+Kf5QO1ooorY84KKKKAOR8B2HiKwufFB1+5+0x3GtTTaYN4
by7IxxBE46YYSHHvXXVxnw88PT+H7rxa0+rx6r/aGuTXsao5b7IjRRKITknBGwnH+1XZ0AFFFFAH
JeP7DxDf/wDCOf8ACPXP2byNatptR+cL5lkN3mpz1zleK62uM+I/h248RDwwINXj0n7Drlrevvcr
9pRN2YBgjJbPT2rs6ACiiigArkfAdh4isLnxQdfuftMdxrU02mDeG8uyMcQROOmGEhx7111cZ8PP
D0/h+68WtPq8eq/2hrk17GqOW+yI0USiE5JwRsJx/tUAdnRRRQAVyXj+w8Q3/wDwjn/CPXP2byNa
tptR+cL5lkN3mpz1zleK62uM+I/h248RDwwINXj0n7Drlrevvcr9pRN2YBgjJbPT2oA7OiiigBPW
vP8AwR/yUz4if9fNn/6SpXoHrXn/AII/5KZ8RP8Ar5s//SVKxqbx9f0Z6OF/hYj/AAr/ANLgangC
w8Q2H/CR/wDCQ3P2nz9auZtO+cN5dkdvlJx0xhuK62uM+HHh248OjxOJ9Xj1b7drl1epsct9mR9u
IDknBXHT3rs62POPPvBH/JTPiJ/182f/AKSpXoA6V5/4I/5KZ8RP+vmz/wDSVK9AHSsaXwv1f5s9
DH/xo/4Yf+kROT8f2HiG/wD+Ec/4R65+zeRrVtNqPzhfMshu81OeucrxXW1xnxH8O3HiIeGBBq8e
k/Ydctb197lftKJuzAMEZLZ6e1dnWx54UUUUAFcl4AsPENh/wkf/AAkNz9p8/WrmbTvnDeXZHb5S
cdMYbiutrjPhx4duPDo8TifV49W+3a5dXqbHLfZkfbiA5JwVx096AOzooooAK5H4haf4i1C20FfD
tx9mli1qzmvj5gTfZLIDOnPXK8Y7111cX8SvD8/iK08PpBq8ekm01yxvXaRyv2hI5QxgGCMl+gHe
gDtKKKKACkPSlpDQB8vfEf8Aaw8UeF/iZ4p8MaJ4K0nU7bQbmG0e9v8AXJbV5ne0guTiNLWQBQLh
VyXySp4HFYX/AA2T8QSf+Sd+Gh/3M9x/8g15/wDFD/k4D4tf9hu0/wDTPp9Y1fgGf8WZpgMyrYah
NKMXZXR/LvE/HGdZXm9fB4aolCL00v0PWf8Ahsn4g/8ARPPDX/hT3H/yDR/w2T8Qv+ieeGv/AAp7
j/5Bryaivnv9eM6/5+L7j5b/AIiRxD/z9X3Hr+k/tk+L28RaBZ6t4B0S30/U9WsdKlnsvEM0ssJu
rmK3V1RrNQ+1pVJG4ZAPOa+tl4X1+tfm/cDOv+Cuv/I4eHun/YXtK/R8H8fSv2Xg/NMVm+AlXxUr
yU2traJJ/qf0BwDnWMz3K54nGyvNTa2tolF/qSUUVyMvxX8EW3im78MS+MdAi8SWfkfadHk1SAXk
HnPFHDvhL718x7iBFyPmaaMDJdc/dn6WddRXnnhb9oT4W+ONdtdE8OfErwf4g1q6LfZ9O0zXrW5u
Jtql22RpIWbCqzHA4Ck9BVqz+N/w61LwdfeLrXx94YuvClhMLa816HWLZ7G2lJQCOScPsRiZYxtJ
B/eJ/eGQDuaKxdN8V6JrR0r+z9Z0+9/tWybUtP8As10kn2y1Hl5uIcE+ZEPPhy65X97Hz8wztUAF
FFFABRRRQAUUUUAeVftK/wDJOtI/7HPwn/6kOnV6rXlX7Sv/ACTvSP8Asc/Cf/qQ6dXqlAC0UUUA
NPevDfGekaPpuhfFe40zVP7QvdQ8Vabc6pb4x9huRaaXEsPvmCK3l/7bV7l614Z4z/4R3+w/iv8A
2N9o/tH/AISnTf7b87O37b9k0vZ5f+z9m+ydP4t9Y1f4UvR/kehl3++0f8UfzPcov9Un0FPpkTAx
pyOgp2R61qjge5wPxz/5Jxe/9fVn/wClUVS/EnR9H1iPwj/a+qf2X9l160urPgH7Tcrv8uH/AIFk
/lUPxyIPw4vcHP8ApVn/AOlUVS/Eo+HfL8I/8JD5/wDyHrT+zvs+f+P35vK3Y/h+9msl/FfovzZ6
E/8AcqX+Kf5QO7ooorY84KKKKAOI+Guj6PpN34zbSdU/tN7zxBPdXy4x9luTFCGh/BVQ/wDAq7eu
H+G3/CO/avGf9gfaPM/4SCf+0/Pzj7b5UO/Zn+Hb5ePfNdvmgBaKTNGaAOJ+J2j6PrH/AAif9r6p
/Zf2XxBaXVnwD9puV3+XD/wLJ/Ku3rh/if8A8I7jwn/wkP2j/kYLT+zvs+f+P35/K3Y/h+9mu4oA
KKKKACuI+Guj6PpN34zbSdU/tN7zxBPdXy4x9luTFCGh/BVQ/wDAq7bNcR8Nv+Ed+1eM/wCwftHm
f8JBP/afn5x9t8qHfsz/AA7fLx75oA7iikzRmgBa4j4naPo+sf8ACJ/2vqn9l/ZfEFpdWfAP2m5X
f5cP/Asn8q7auI+J3/CO48J/8JD9o/5GC0/s77Pn/j9+fyt2P4fvZoA7iikzRmgA9a8/8Ef8lM+I
n/XzZ/8ApKlegetef+CP+SmfET/r5s//AElSsam8fX9Gejhf4WI/wr/0uBa+GOj6Po//AAln9kap
/an2rxBd3V5wB9muW2eZD/wHA/Ou3rh/hh/wjuPFn/CPfaP+Rgu/7R+0Z/4/fk83bn+H7uK7fNbH
nHn/AII/5KZ8RP8Ar5s//SVK9AHSvP8AwR/yUz4if9fNn/6SpXoA6VjS+F+r/NnoY/8AjR/ww/8A
SInE/E7R9H1j/hE/7X1T+y/sviC0urPgH7Tcrv8ALh/4Fk/lXb1w/wAT/wDhHceE/wDhIftH/IwW
n9nfZ8/8fvz+Vux/D97NdvWx54tFFFABXEfDHR9H0f8A4Sz+yNU/tT7V4gu7q84A+zXLbPMh/wCA
4H5122Qa4j4Ynw7jxZ/wj32jP/CQXf8AaP2jP/H78nm7c/w/dxQB3FFFFABXEfFLR9H1m08NrrGq
f2VHb+ILC6tWxnz7lJQYof8AgbcV29cR8Uv+Ed+yeGv+Ei+0eV/wkFh9i+z5z9t80eRux/Du60Ad
vRRRQAUh6UtIelAHwD8Tzn9oD4tjuNbtB/5R9PrG719Z+MP2UPhr4+8W6t4m1jS9X/tnVJI5LyXT
/Eup2KTOkMcKsYoLlIwfLijXIUEhRnNZI/Yi+EuOdN8S/wDhba5/8mV+T5twN/aeNqYxV+Xmd7WP
w7PPDb+2Mwq476xy87vax8xUV9Pf8MRfCT/oG+Jf/C21v/5Mo/4Yi+En/QN8S/8Ahba3/wDJleR/
xDb/AKiPwPB/4hH/ANRf4Hyrc8a94K5x/wAVh4e/9O9pX6QjoOMV4fpP7G3wq0bWNM1WHStblu9N
vIL+2F54s1e6iWeGVZYnMUt0yPtkRGAZSMqOK9vB9j7Zr9G4dyX+wsJLC8/NeTlf1SX6H63wpw7/
AKs4GWD9pz3k5XtbdJW/A+V/BPiDx9e/FjRfh7dfE3xBfazofibWrrXp57DSVt9Q0aCCxntbZWSy
VhLt1XSQ5VYyS+o4fC2xrf8AhNpXgzWf2avgrb+ObG3v9WSbSblI54nkvl8URN5tzIQgMou0ukvH
uWPzLtuzPhBMa9+TSrOHVLjU47G3TUrmGK2nvFiUTSxRtI0cbPjLKjTSlVJwDI5GNxzlWXw+8Laf
4zv/ABfaeGtItfFd/CLa812GxiS+uYgEAjknC73UCKMbSSP3af3Rj6k+0Pnf4aeF/G/xD8J3fh/+
y/D9h4Mt/iZq2r/27/bM8uot9i8W3F95f2H7IsY3y2/k7vtPyq/mYYjyia9iP9jT476I5261Je+N
dNTTW4uGur7Ub57C3Ef3jLcLeWjQpjdKLmEoGEiZ+iPBXw+8L/DfSpdM8JeGdI8LabLMbmSz0Swi
s4XlKqpkKRqoLFUQbsZwoHYUXvw+8Lah4zsPF934a0i68V2EJtrPXZrGJ762iIcGOOcrvRSJZBtB
A/eP/eOQDz/X9Ksof2ufAupx2NumpXPgfxDbT3ixKJpYo9Q0Zo42fGWVGmlKqTgGRyMbjn2Subvf
h94W1DxnYeL7vw1pF14rsITbWeuzWMT31tEQ4Mcc5XeikSyDaCB+8f8AvHPSUAFFFc3408d6N8Pt
Miv9ZnuFjmmFtb21jZz3t3dSlWby4LaBHlmYIkjlY0YqkcjnCoxAB0lFeOP+1j8NFjt2t9U1jU3n
1OXRBBpfhrVL2ZNQjtY7uW0kjhtneOdIZNzROAymOZSA0MqpqxftE+CJbrw3bLdax9s1/U30a0tH
8O6itxFerGJjBdRG332jeSwnH2gR5hzKMxguAD06iuGl+MnhK28ZeI/DN3qFxp+peHNMTWNVnv8A
T7m2sbWyYErO17JGtuVOyTpIf9TN/wA8pNu/4T8UaX448LaP4k0S6+26NrFlDqFjc+W0fnQSoJI3
2uAy5VgcMARnkA0AcD+0p/yTrSOv/I5+E+v/AGMOn16ofY145+1frFt4d+EUOrXplWy0/wAUeGry
cxQvK4ii12wkcqiAs7bVOFUFicAAkgVl/wDDa/wvI4m8Sn3/AOET1Qfzt64q+Mw+Gdq01H1Z5+Jx
+FwjUcRVUW+7se8fNR81eE/8NsfC7/nt4m/8JPVP/kej/htj4Xf89vE3/hJ6p/8AI9c39q4D/n9H
70cn9t5b/wBBEfvR7qeF4r5d+Lfxu8B+HW+JHhyfytD19PENiL1mPOoyraabN5//AAGB4Ysdf3I9
RXVj9tb4XjOJ/Ep/7lPVP/kevlr9qn47fDH4x+D/ABTLPJdeHtQ0DXYf7M1Sbw5qKLd28lpZiU3L
C3/duXdkCtyVt4TjDqTnPHUsTB0sJUjKb0Sve99LfPp5n0nDmcZHPNKH12uvZpq/K1da6Pr1sfev
gTx9ofxE0GPWfD16uoaezmJZ4/u7l6jPtXTk49/TFfHXw3/bw/Zk+GXgXRvDGl+OpxZ6bbrCG/4R
/UQZG6vIf9H6sxZj7k10w/4KXfs6DH/FeT5/7AGpf/I9fbU+H865Fz4Opfr7kv8AIyxVXC+3n9Wl
7l3y3ava+l/O252H7S/xX8MeC/CraJrGpx2WpXb21xDDJgGSNblCzDPXAU/lWtqXxW8GeLvD3hHW
LaBfEmnXniG1sbKeM/LBdndtlB77OenrXyN+1j+0/wDAH9ojwbptjoHjWWXxbZXkf9nK2gakDMJW
VJIci2z82VYAclkUDrXqelftSfCz4T+A/BnhzQLTWL7T9Ou7W1mlvvC+oxeWjEh7hc24zKXbgDli
+ACTivlsbHE5VjXRzGPsuZJxUk4yer6PzuerjsyyGhk+Hp+1tiXOV02rWtHVaX1srfM+wOaPmrwn
/htj4Xf89vE3/hJ6p/8AI9H/AA2x8Lv+e3ib/wAJPVP/AJHrm/tXAf8AP6P3o+L/ALby3/oIj96P
dvmo+avCf+G2Phd/z28Tf+Enqn/yPR/w2x8Lv+e3ib/wk9U/+R6P7VwH/P6P3oP7by3/AKCI/ej0
H4baxo+rXfjNdJ0z+zHs/EE9rfNn/j6uRFCWm/FWQf8AAa7TdngYr5J0j/goz8FtH1TxFYeI9bm8
NXcGpOIYf+Ef1FZbiExRsk8q/Z8q7biMHnCqehFa/wDw8t/ZzH/M+T59f7A1L/5Hr6zDZPmWMpRr
4fDTnCWqahJpryaWp6cK9KcVOElZn1BRXzB/w8u/Zz/6H2f/AMEGpf8AyPR/w8u/Z0/6H2f/AMEG
pf8AyPXV/q9nH/QHU/8AAJf5Fe2p/wAyPafibrOj6P8A8Ip/a+l/2p9q8QWlrZ84+zXLb/Lm/wCA
4P5129fKUv8AwUM+DHjDxP4O8PeFteTxBq+r69ZackF3o97AIvOfyxKryQBQ4ZkAyR96vqwZxXk4
rBYnAz9niqcoSetpJp2+ZpGUZ6xY+iiiuUobnjoa4j4baxpGr3fjNdJ0v+zHs9fntr5s/wDHzciK
EtN+Ksg/4DXbY46n8a+arz9tr4afD7xr4x8L+LbmbQdY0rV3gMNlo95cefGYonSZ3ihZd7B+mc4C
nuKznOFNc03Y6cNhcRjJ+zw8HOXZK7/A+laK+b/+HhfwN/6GXU//AAndR/8AjFH/AA8L+Bv/AEMu
p/8AhO6j/wDGKw+t4f8A5+L70er/AKvZx/0CVP8AwCX+R9I/55rifibrOj6P/wAIn/a+l/2p9q8Q
WlrZ8gfZrlt/lzf8BwfzryQ/8FC/gb28S6n/AOE7qP8A8YrnvF3/AAUP+D8C6P8AYNRuNTzqcCXB
u9Av1+zQkkNMm6Dl142gZJLcUfWqD/5eL7wfD+bRV3hZ2/wy/wAj6xor5v8A+HhfwN/6GXU//Cd1
H/4xR/w8L+Bv/Qy6n/4Tuo//ABij61h/+fi+9B/q9m//AECVP/AJf5H0h+NcB4I/5KZ8Q+3+k2fT
/r1SvL/+HhfwNzx4l1PH/Yu6j/8AGK5Pwx+3P8HdK8aeL9TufEGopZ6nNbPauNCvmLhIFRsqISy4
YH7wGe2axnisPeP7xb912Z6OF4fzdUq6eEnrFfZl/PHyPoX4Za1o+r/8JYNI0s6Z9l1+7trzoftN
yuzzJv8AgWR+VdquTz2ryX9nf41aJ8dPD3iTWvD8UaafZ69caesiW0sDy7Y4pFkkSRFYOySoTx0I
r1tcgYPX2r0IyUlzRPlKtKdGo6VRWktGn0ZwPgj/AJKZ8RP+vmz/APSVK9AHSvP/AAR/yUz4if8A
XzZ/+kqV6AOlZUvhfq/zZ2Y/+NH/AAw/9IicP8TdY0fR/wDhFP7X0s6p9q8QWlrZ8/8AHtctv8ub
/gOD+ddqfY15p8ePijY/CHw3ouv6rZfatLOtWlpcyi1kuHtllYoJUSNWcvuKqoUEkuAOtcn/AMNr
/C8jibxKff8A4RPVB/O3rCtjMPhnatNR9WfP4nH4XCNRxFVRb7ux7x81HzV4T/w2x8Lv+e3ib/wk
9U/+R6P+G2Phd/z28Tf+Enqn/wAj1zf2rgP+f0fvRyf23lv/AEER+9Huo68Zrivhlq+kayPFf9ka
X/Zf2XxBd2t5z/x83K7PMm/4FkflXnv/AA2t8LwP9d4lH/cp6p/8j10nwC+MGmfGTR/E+p6TZNZ2
un67Pp+Hs5rWSXEcMqySRyojh3SZG5XoRXRRxuGxMuSjUUn5M6sPmOExcuTD1VJ9k7nq1LRRXcei
FcR8UtY0fRrTw22saX/asdx4gsLW1XOPIuXlAim/4A3NdvXF/ErxBP4dtPD7waRHqxu9csbJ1kQt
9nSSUKZxgHBTqD2oA7SiiigApDS0hoA/N79q3/go58S/gb+0J4u8CeH9E8LXWkaM1osM+p2lzJcO
ZbSCdizJcIvDSkABegHWvJ/+Hu3xj/6FzwN/4L7z/wCS68t/4KK/8nq/E3/rrp3/AKbLSvnLPNf2
vwZwZw9mGQ4TFYrCRlUlG7bvdv7z5zEYirGrKMZOyPt7/h7x8Yv+hc8D/wDgvvP/AJLo/wCHvHxi
/wChc8D/APgvvP8A5Lr4for7n/iH/C//AEAw/H/M5vrVf+Y/Qr4R/wDBUr4reOfi14G8M6j4f8HR
6brmvWGlXL2tndpKkdxcxxMyM1yyhgHyMqRx0r9Tuh55r+ev9nH/AJOM+Ev/AGOWi/8ApfBX9ChH
Nfyj4p5PgMlzmnh8upKnF002l35pK+voe3gZyqU25O7uPoorzHU/2jPh/o3iFdHvdauLa4l1OHRb
e6fS7v7DdahJcLbraQXnleRNOJWKvFHIzR+VOXCiGUp+Ononp1FeT+Fv2m/AXjC8tYLCfxBbx3N6
2mpfar4U1bT7IXSzGA273VxbRwpL56mAIzhjLiMAuQptW37RPge5+GGvfEJbrWIvCmhTXEGo3Vx4
d1GGaBoH8u4P2d7cTMsT7lkdUKoY5dxHlvtAPTqK88j+O3g19dsNIa91CC6vPsyeZcaNexW9pNcK
jQW13O0IitLlxLDttp2jmJnhGzMsYb0OgD58/as1P+xdX+Ek9/428QeDvC9z4muLDXP7En8hJ7Vt
Jv5S1xKkbSxRIYBumV41hR5Ji0bQxzQ8t4F8WHw/qXw++IPi7Wfs3giysvF+hQeKdYus262sutWh
0aSa6cndFNZWAKXcrFZiYsyvJcR+Z7n48+GKeO/E3gjWm8R6xoz+FNTbVbe000Wphu5Wgktys/nQ
SPt8ma4jxGyHEzHO5Y2TuaAPlP4w/ELQ9Z8T/By98IaxoHhDVNe8fzS6brWu2iSW+u7dAvbX7bFC
lxBLdRMZba1jlLpvJtynmRPAZeg8TeAr74ban4T8beI9Vt9S8vxy/ibxZrFnZNZ2NjEfD9zpMcyw
NLM8UCAWXmM0kgTdNM7RxK3l/RlFAHiXgXxbomu/FP4h/Euw1jT7r4ff8IzpFgvidLpP7Okks59V
nu2SfOx4oku4d0ykxhvMTdvilVLX7Huq2Wtfsp/B+5069t7+3Twnpls0ttKsirLFaxxSxkqSAySI
6MvVWVgcEEV7HRQB4V+2l/yb/qP/AGG9B/8ATxZ18uV9R/tokH9n/Uef+Y3oP/p4s6+XK/BfEn+P
h/R/ofzH4uf7zhP8L/NBRRRX4yfz8FeCfHj/AJJV8Vv+wzYf+i9Or3uvBPjx/wAkq+K3/YZsP/Re
nV+jcAf8j/Df46f/AKdpn3vBv/Izj60//TtM+N6KMUYr/eqHwo/qg6f4Y/8AJSvCH/Yasf8A0ojr
73+IP/IAtf8AsLaZ/wCl8FfBHww/5KV4Q/7DVj/6UR197/EH/kAWv/YW0z/0vgr/AC/+k7/yW+W/
9e4f+nJH4/xr/wAjPLv8X6xOlooor+EZbs/nyXxMKKKKkk+CP2lv+S6eK/8Aftf/AEkgrzQ9a9L/
AGlefjp4r/37X/0kgrzQjmv90/CV/wDGDZT/ANeo/kf2jlH/ACLML/17p/8ApKEooxRiv2A9Q9F/
Zx/5ON+Ev/Y46L/6Xw1/QqOlfz1fs4/8nG/CX/scdF/9L4a/oVB4r+KfGj/kf0f+vUf/AEqR9Jl3
8J+v+QtFFFfgR6g096/Hf9rCW8m/am+KjX0flzDVYFUAf8shY2oiP4xhD+NfsQTX47/tYRXkP7U3
xUW+k8yY6rAykHP7o2NqYh+CFB+FfOZ9/uT9Ufs/hJ/yU0P8MvyPK6KKK/Lz+7AqjrP/AB6R/wDX
xB/6OSr1UdZ/49I/+viD/wBGpXTh/wCLD1X5nj5t/wAi+v8A4Zfky9RRRXO9z1YfCgoopaRZ+if/
AAS7/wCSO+Of+xwl/wDTbp9fZPcV8bf8EvOPg745/wCxwl/9Nun19kZBxzX7Jgf91pf4V+SP81OK
f+R9jv8Ar7U/9KZwHgj/AJKZ8RP+vmz/APSVK9AHSvP/AAR/yUz4if8AXzZ/+kqV6AOldNL4X6v8
2ePj/wCNH/DD/wBIifO/7dM+oQ/BC0Szj8y3l8TaIl623OyH7fCwPt+8WIZ98d6+cK+jv26Yb+b4
IWj2UgS3i8TaI96u7G+H7fCoHv8AvGiOPbPavnGvwvxJ/wB4w/o/0P5S8XP95wv+F/oFFFFfjJ/P
4V9AfsN/8i/8UP8AscP/AHEaZXz/AF9AfsOH/iQfFD/scP8A3EaZX6v4c/8AIzq/4H/6VE/bvCb/
AJHNb/r2/wD0qB9MUUUV/RJ/V4VyPxC1DxFp9toLeHbf7TLLrVnDfDyw+yyaQCd+emF5z2rrq5H4
haf4i1C20FfDtx9mli1qzmvj5gTfZLIDOnPXK8Y70AddRRRQAUUUUAfhn/wUWYf8Nq/E3H/PXTv/
AE2WlfOIr+hXxT+z58LfG+u3Ot+I/hr4Q8QazdFfP1HU9Btbm4m2qEXfI8ZZsKqqMngKB0FZo/ZQ
+CGD/wAWc+H/AP4S9j/8ar91yTxZxuR5dRy6nhYyjTVk23dnmVMDGrNzbtc/n8x7ijHvX9Av/DJ3
wQ/6I38P/wDwl7H/AONUf8MnfBD/AKI38P8A/wAJex/+NV73/Eb8w/6A4f8AgUjL+zYfzM/D79nL
A/aM+EnI/wCRy0X/ANL4K/oTB7V5npP7NPwh8ParZ6lpnwq8E6bqVlMlxa3tp4ds4pYJUYMkiOsY
KspAIIIIIyK9NA/OvyHi3iitxbjY42tTUHGKjZNvZt9fU7sPRVCLgnc+S/AvgrU0+N2n+AZNY8cN
b+Edf1TxJcavd+KNWmXUtPlhtH0+zmR7ggweZdtFGzs6yNoF4NpM9yE6n4HeNPC2l/CX4ZfCvWIo
Nb+IGg6Zo+map4ORYp77S7qzSEPdzwuwEUEEkSzJcnCPiBoGlaa3En0bRXxR1HyR8ANGvvjb4Q1F
7H4geF9U+HVr8RdX1UWOi6c02oCW38Rz6jbKb8XjRbZHW3lx9my0EwCkFllo8UatZaf8A/iz8H7m
8t4Pif4in8XQ6N4VeVRfaiNTvr+aymgjzmSBo7qNnnXMUOyfzXjNvMI/reigD5z+Ovxq8B6h8SvC
fwqvvF2j2OpR+ING1HV7R7tBeIy3cc2m20EYJd55r1LNnURssdqJ3kaHzLd3+jKKKACiiigAoooo
AKKKKAPD/wBr/RrnX/glLpVpdRWF5qHiPw5Zw3U8JnjheTXLFFdowyFwN2SoZc4xuGc15ef2MfiD
nH/C0vDQ/wC5KuP/AJaV7T+0qCPh3pH/AGOXhP8A9SHTq9TwSen515+JwGFxjTxFNSa2ueXi8swe
PkpYqlGbW11sfIn/AAxf8Qv+ip+Gf/CKuP8A5aUf8MX/ABC/6Kn4Z/8ACKuP/lpX17+FH4Vxf2Hl
v/PiP3Hn/wCreTf9AsPuPkL/AIYv+IP/AEVLwyf+5LuP/lpXBa//AME7vFnjvSfGWhXvxc8Prban
qME9w1l4VlaWJ44bUqpB1DEZIhQ7TvJVt2RvAX74wcn36VxXgLSNH03xX8SLjTNTOoXuoa/Fc6pb
hcfYbkaVYRLD75git5f+21dOHy3BYWoqlClGMlazS10d19z1N6ORZZh5c9LDxi9NUuzTX4pM+AP+
HMd5/wBFng/8JNv/AJPo/wCHMd5/0WeD/wAJNv8A5Pr9NfwNHPoa++/1qzz/AKDJ/ez1vY0v5Ufm
ton/AAR/1Lw7rum6rb/GW2e40+6iu41k8JNsZo3V1DAX4OMgZwRx3FepeKv2JPHWp2dlbT/Fjwxb
xtqFrKCfCU8RLRTLMqrnUm3EtGo28ZGcEHmvtfnpiuI+Juj6Rq//AAiZ1fU/7L+y6/aXVngf8fNy
u/y4f+BZP5V8tmc5Z1XjicyftakdE5atJapI4q+WYPEyjOtSi3HZtbHz1/wxf8Qv+ip+Gf8Awirj
/wCWlH/DF/xC/wCip+Gf/CKuP/lpX17+FH4V4P8AYeW/8+I/cef/AKt5P/0Cw+4+Qv8Ahi/4hf8A
RU/DP/hFXH/y0o/4Yv8AiD/0VPwz/wCEVcf/AC0r69/Cj8KP7Dy3/nxH7g/1byb/AKBYfcfmz4n/
AOCUesfEvxbrfiDUPjHpUV5cXCxyR6f4Xdo0McMaAEG/yjYUEqSeuc84Gf8A8OZL3/os0P8A4Sbf
/J9ff/w10bSNJu/GbaTqh1J7zX57q+XH/HrcmKEND+Cqh/4FXbDOe9fd4TiDNcBQhhcLiZQpxVkk
9EuyPahhqNOChCCSSSS7JdPuPzK/4cx3n/RZ4P8Awk2/+T6P+HMd5/0WeD/wk2/+T6/TX8DRz6Gu
z/WvPf8AoMn97K9jS/lR+cXgT/glDc/DL4leCPFUnxcs9QXRtfsNRNlL4eNqbnyLhJvKR/tb4ZvL
wPlPUntX6PdxXEfE3R9H1j/hFDq+qf2X9l8QWl1Z8D/Sbld/lw/8Cyfyrtx+NeHjcwxeYzVXGVXO
SVk3vZdDWMIwVoqw6iiiuEsZivhn4nf8E9tY+K/xX8beMLb4padpsWsan532JtCe+e32wxRhGkF3
FggIPl28AjmvufnHeuI+G2j6RpN14zbSdTOpveeIJ7q+XH/HrcmKEND+Cqh/4FWVSlCrHlqK6OzB
43E4Cqq2FqOE+63Pi/8A4dZeIf8Aor+mf+EfJ/8ALGj/AIdZeIf+iv6Z/wCEfJ/8sa/Qf8KPwrm+
o4b/AJ9o97/WvPP+guf/AIEz89/+HWfiD/or+mH/ALk+T/5Y1m65/wAEt9e8q0if4xaRGJLqIAye
FpIiSHDAL/p53MSo+XjIzyK/Rg5XsSPYVxPxM0bSNY/4RM6xqn9l/ZdftLqz4/4+bld/lw/8Cyfy
prBYaLTVNXInxRndSLhLFzaejV+h8Yf8OsvEP/RX9M/8I+T/AOWNH/DrLxD/ANFf0z/wj5P/AJY1
+g/4UfhS+o4b/n2i/wDWvPP+guf/AIEz8+P+HWXiH/or+mH/ALk+T/5YVhaN/wAE4db1rxFr2jp8
UtPgfSJIo3uG8LSOJt8YcEL9vGzAbHVs4zx0r9IsEE9cVwPgkZ+JnxD/AOvmz/8ASVKyngsMnH92
tX+jO/DcU526VdvFzbUU/i2fNFfqzh/2Q/gHcfs7eB/EmgXfiaz8V3F9r8uom7srQ2qRf6NbQCJo
zJIQwEG4/MfvV7uq4z0riPhno+kaP/wln9kaodU+1a/d3V5gf8e1y2zzIf8AgOB+dduMnsfxr0Yx
UFypWS2PiqtWdepKrUleUndt7tvqcD4I/wCSmfET/r5s/wD0lSvQB0rz/wAEf8lM+In/AF82f/pK
legDpWdL4X6v82dmP/jR/wAMP/SInjv7TfwlvPjN4B07w9p/iO18MXKa1Y6gl3eQGeNzBL5gjMQk
jL7mC/LvXp1FeRH9jH4g5x/wtLw0P+5KuP8A5aV9D/E7RtI1j/hFDq+qf2Z9l1+0urPjP2m5Xf5c
P/Asn8q7XBJ6fnXLicBhcY1LEU1Jra6Pm8XlmCx8lLFUoza2utj5E/4Yv+IX/RU/DP8A4RVx/wDL
Sj/hi/4g/wDRU/DP/hFXH/y0r69/Cj8K4v7Dy3/nxH7jz/8AVvJv+gWH3HyCf2MfiDjI+KXho/Tw
Vcf/AC0r1f8AZm+EGofB7QPFlnqviPT/ABNfatr76jJc6ZZtaRQ4tLa3ERjaWUqwFsGOXPL17KBj
jGB7VxPwy0bSNHPiv+yNU/tT7V4gu7q84x9muW2eZD/wHA/OuvD5dg8JNzoUlFtWul0O7CZTgcDN
1MLRjCT0bS6djuqKKK9I9YK4v4leH5/EVp4fSDV49JNprljeu0jlftCRyhjAMEZL9AO9dpXEfFLR
9H1m08NrrGqf2VHb+ILC6tWxnz7lJQYof+BtxQB29FFFABRRSGgD4L/aC/bn+Ivws+OfjHwdoune
GJdI0aa2it5L+yuZJ38yzt52LMtwqn5pmAAUcAdTXAD/AIKS/FfPGk+Dcen9nXf/AMl15x+2Wc/t
ZfFDH/P5Y/8Aprs68dr83zHMcXRxVSnCo0k9D+1ODOCuHcxyHC4vF4SMqko6tt6v5M+q/wDh5R8W
P+gR4M/8F13/APJdH/Dyj4sf9AjwZ/4Lrv8A+S6+VPwo/CvN/tfHf8/X+H+R9x/xDvhb/oBj98v/
AJI+wvAv/BQv4neI/iH4N0W90nwkNP1fXtP0u4NvY3SyCO4uo4XZGNywDASZGQRx0r9F+V61+Jvw
pP8AxeL4aYH/ADOGhf8Apyt6/bLJJ7Yr7jJK9XFYeU60rtNr8Efyp4pZNgMjzmnhsupKnB002lfd
ykr6t9h9LRXjl/8AtKaTYS6ZeDwr4ou/CeranY6TpXiy0treXTb+a7uoraJ02z+ckBeUsLiWJIZF
QGJ5PNgE30R+PHsdFeJeF/2mo/EMVrfX/wAO/GHhrw/NrLeH31vVH0t7eC/F8dPELpb30sx3XgEA
ZYmXLBiRHlxah/aOtT8FfF3xMufBPiix03w1PqEV5pMx083zrYzPDeSRhLtoisbxXAwZQzeQ5RW3
R7wD2OivMtQ+Ni6Nqmmwat4L8UaRptzNY2N1rN3Dai0sL67aJILR9twZJmMtxBEZbZJoFeQgyjy5
TH6bQAUUUUAFFFFABRRRQB5V+0r/AMk60j/sc/Cf/qQ6dXqteVftK/8AJOtI/wCxz8J/+pDp1eq0
AFFFFABXD+Av+Ed/4Sv4lf2N9p/tH/hIIf7c87O37b/ZWn7PL/2fs32Tp/FvruK4nwDq+j6l4r+J
Ntpml/2fe6f4ghttUuM5+3XJ0qwlWb2xBLbxf9saAO2ooooAK4f4n/8ACO48J/8ACQ/aP+RgtP7O
+z5/4/fn8rdj+H72a7iuI+J2saPo/wDwif8Aa+l/2p9q8QWlrZ8gfZrlt/lzf8BwfzoA7eiiigAo
oooA4f4bf8I79q8Z/wBgfaPM/wCEgn/tPz84+2+VDv2Z/h2+Xj3zXcVxHw11jR9Wu/Ga6Tpf9mPZ
+IJ7W+bOftVyIoS034qyD/gNdvQAUUUUAcP8T/8AhHceE/8AhIftH/IwWn9nfZ8/8fvz+Vux/D97
NdxXEfE7WNH0f/hE/wC19L/tT7V4gtLWz5A+zXLb/Lm/4Dg/nXb0AFFFFABXD/Db/hHftXjP+wPt
Hmf8JBP/AGn5+cfbfKh37M/w7fLx75ruK4j4a6xo+rXfjNdJ0v8Asx7PxBPa3zZz9quRFCWm/FWQ
f8BoA7eiiigArh/if/wjuPCf/CQ/aP8AkYLT+zvs+f8Aj9+fyt2P4fvZruK4j4naxo+j/wDCJ/2v
pf8Aan2rxBaWtnyB9muW3+XN/wABwfzoA7eiiigBPWvP/BH/ACUz4if9fNn/AOkqV6BmvP8AwR/y
Uz4if9fNn/6SpWNTePr+jPRwv8LEf4V/6XAs/DD/AIR3Hiz/AIR77R/yMF3/AGj9oz/x+/J5u3P8
P3cV3FcP8MdY0fWP+Es/sjS/7L+y+ILu1vOQftNyuzzJv+BZH5V2+a2POPP/AAR/yUz4if8AXzZ/
+kqV6AOlef8Agj/kpnxE/wCvmz/9JUr0AdKxpfC/V/mz0Mf/ABo/4Yf+kROI+J//AAjuPCf/AAkP
2j/kYLT+zvs+f+P35/K3Y/h+9mu4riPidrGj6P8A8In/AGvpf9qfavEFpa2fIH2a5bf5c3/AcH86
7etjzwooooAK4f4Yf8I7jxZ/wj32j/kYLv8AtH7Rn/j9+Tzduf4fu4ruK4j4Y6xo+sf8JZ/ZGl/2
X9l8QXdrecg/abldnmTf8CyPyoA7eiiigAriPil/wjv2Tw1/wkX2jyv+EgsPsX2fOftvmjyN2P4d
3Wu3riPilrGj6NaeG21jS/7VjuPEFha2q5x5Fy8oEU3/AABuaAO3ooooAKQ0tFAH45ftreI9L0r9
rj4oQX2o2dlP9rsG8u4nWNip0uzwQCenv7V4t/wmvh8/8x3TP/AyP/4qv3zIpAMnoc187iMkw+Jq
SqybTZ+yZP4oZtkuBpYChTg4QVldan4G/wDCa+Hv+g9pn/gbH/8AFUf8Jr4e/wCg9pv/AIGx/wDx
VfvrijFc3+ruG/mZ7X/EZc8/59Q+5n4bfB/xPo2ofGr4Y21rq9lczv4w0PbFBcI7t/xMbc4ABzwA
T+FfuOAOPajHtRjrwa9vA4OGBpunTe7ufl3E/EuK4pxkcbi4qMlFR02sm3+p8meBP2atJ0f426do
A+G+j2Hgrwb4g1Xxjo2rx6Tboz3F5DafZo/MC7GVJptTURxqskS6TpZcqFiafvvglr+reA/APgL4
Wf8ACLaxc+LPDWmafo2qXNxZXFtpEcNtFHFLeRag0RhnV0QNFDEWmZpY1ljg2ztB7vS16B8kfLvw
B+Gc3j3QdR1HWtf8b2uhReONX1mPwbrmix6VaFhrc+oWM486xivWXLW1z/ripfMbfKrxA8R6Nq1v
8HviT8FxomsT+K/Fs3iZNLvrfTLiTSGh1a7vLiK4lvlQwwLCl2RLHKyzbreQRRTb4DN9RUUAeD/G
e/tvEvj/AMH2Ohab4nn8eeHPEFhc2Vyuk6lHpEVrLLCupSNctGNPlb+zZL1FZ3Z0aR0i2zNg+8UU
UAFFFFABRRRQAUUUUAeVftK/8k60j/sc/Cf/AKkOnV6rXlP7Sv8AyTrSP+xz8J/+pDp1eq5oAWii
igAri/BPiGfWvE3xBs5dJTT49I12KyhuUQqb9G0yxnM7Ej5iGnaLIzxCB2IHZ5rkvB2oeILzxH47
h1m28nTrTWY4dEfywvnWZ06yd3z/ABf6S92uT/cx2oA66iiigArjPiP4iuPDo8MGDSI9W+3a5a2T
70LfZkfdmcYBwVx1967KuS8f6h4hsP8AhHP+EetvtPn61bQ6j8gby7I7vNfnpjC80AddRSZozQAt
FJmjNAHG/DzxDP4guvFqz6RHpX9n65NZRsiFftaLFEwmOQMk7yM/7NdnXI+A9Q8RX9z4pGv232aO
31qaHTDsC+ZZCOIo/HXLGQZ9q62gBaKKKAOM+I/iK48OjwwYNIj1b7drlrZPvQt9mR92ZxgHBXHX
3rs65Hx/qHiGw/4Rz/hHrb7T5+tW0Oo/IG8uyO7zX56YwvNdbmgBaKKKACuM+HniGfxBdeLVn0iP
Sv7P1yayjZEK/a0WKJhMcgZJ3kZ/2a7LNcl4D1DxDf3Piga/b/Zo7fWpodMOwL5lkI4ij8dcsZBn
2oA66iiigArjPiP4iuPDo8MGDSI9W+3a5a2T70LfZkfdmcYBwVx1967OuR+IGoeIbD/hHP8AhHrb
7SZ9atodR+QN5dkd3mvz0xheaAOuopM0ZoAYMjrg1wPgkj/hZnxE5x/pNn/6SpXa317BptpNdXMq
w20KGSWWRgqooGSxJ4AAGSTXj3gD4neFb34n+NYbfX9NuJr66tBbJFexMZj9nRcKA3zHIxxnmuep
OMZwTfX9GezgMNXrYfEzpwbSir2W3vxZ3fw48RT+Ih4nM+kR6T9h1y6sk2IV+0om3E5yBktnr7V2
WK5L4f6h4hvx4i/4SG2+zeTrNzDp3yBfMsht8p+OuctzXRXt5Dp9rPcXEqQW8KGSSWRgqooGSzE8
AADJJroPGSbdkcT4II/4WZ8Q+c/6TZ9/+nVK9BFeKfD34n+FNQ+KHjWG38QaXNNe3VoLZIr2JjMf
s6LhAG+Y5GOM817QGyAefpXNQnCcW4O+r/M9nNsPWw1eMa0HF8sN1b7COQ+I/iK48OjwwYNIj1b7
drlrZPvQt9mR92ZxgHBXHX3rs65Hx/qHiGwHhz/hHrb7T5+tW0Oo/IG8uyO7zX56YwvNdbmuk8YW
iiigArjPhx4iuPEQ8TmfSI9J+w65dWSbEK/aUTbic5AyWz19q7LNcn8P9Q8Q3/8Awkf/AAkNt9m8
jWrmHTvkC+ZZDb5T8dc5bmgDraKKKACuL+JXiCfw7aeH3g0iPVjd65Y2TrIhb7OkkoUzjAOCnUHt
XZ5rkviFqHiLT7bQW8O2/wBplm1qzhvhsD7LJpAJ356YXnPagDrqKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigArm/GnjvRvh9pkV/rM9wsc0wtre2sbOe9u7qUqzeXBbQI8szBEkcrGjFUjk
c4VGI8g/as1P+xdX+Ek9/wCNvEHg7wvc+Jriw1z+xJ/ISe1bSb+UtcSpG0sUSGAbpleNYUeSYtG0
Mc0PLeBfFh8P6l8PviD4u1n7N4IsrLxfoUHinWLrNutrLrVodGkmunJ3RTWVgCl3KxWYmLMryXEf
mAHpL/tY/DRY7drfVNY1N59Tl0QQaX4a1S9mTUI7WO7ltJI4bZ3jnSGTc0TgMpjmUgNDKqasX7RP
giW68N2y3WsfbNf1N9GtLR/DuorcRXqxiYwXURt99o3ksJx9oEeYcyjMYLjyH4w/ELQ9Z8T/AAcv
fCGsaB4Q1TXvH80um61rtoklvru3QL21+2xQpcQS3UTGW2tY5S6bybcp5kTwGXoPE3gK++G2p+E/
G3iPVbfUvL8cv4m8WaxZ2TWdjYxHw/c6THMsDSzPFAgFl5jNJIE3TTO0cSt5YB6TrHx28HaB4q8Q
eHdQvNQtdU0Gzt769RtGvTEY7hxHbLDMIfLuJZpSYo4YWeSSRHRFZ0ZRv+C/HejfEHTJb/Rp7ho4
ZjbXFtfWc9ld2soVW8ue2nRJYWKPG4WRFLJJG4yrqT5DpvxU8I6P40+JnxjuvEWn/wDCr7fwzoun
/wDCVRTCWyuJ7W51SSdIHXP2jb9ttowYt4aV2hUtLHIi6n7L3ivQ/iDo/jnxXpOs6fq9/rXiaW61
RNKukurWykFnaR2tss0ZeN5UsY7HzjFLLGLhrgI5UBVALf7VGqWWh/Ciz1LU7yDT9Os/Fnhe5ubu
6lWOGCJNf09nkd2ICqqgksSAACTWl/w1D8HD/wA1Z8Df+FJZ/wDx2vMP+Clv/JlfxB/66aX/AOnO
0r8RgeAO9fs3AXAWH4ww9atWrum6ckrJJ3ur9TzsVipUGkle5/QZ/wANQfBv/orPgb/wpLP/AOO0
f8NQfBv/AKKz4G/8KSz/APjtfz5c0c1+qf8AEEMB/wBBs/8AwFf5nD/aUv5T+go/tP8Awc/6K14G
/wDCks//AI7T/g94rTxtf+PdXsPFOl+K/Dk+vINGudI1GG8it7ddOsVkhLREhW+0C5cqTn94D0YV
/PmD7V+tv/BH4E/s5+L/APscrj/0gsa/OOOfDrDcJZdDG0cRKo5TUbNJbpu+nodmGxbrzcWraH3Z
RRSGvww9Mbz+leffGPWrjw1omi6x/b9h4a0mw1m0m1e/1K8jtYBZlijo0khCjczRqASMkgDmvQTy
a+W/+Cj+nvffswX0y3Yt0tNa0uZ4yeZwbuOMIPUgyB8f7B9KyqS5IOXZHVg6CxWJp0G7KUkr9rux
7CP2jPhMQCPif4Nwf+pgtP8A45S/8NF/Cf8A6Kf4N/8ACgtP/jlfjPmjNfD/AOstRf8ALpff/wAA
/quPghg2k/r0v/AF/mfsx/w0X8J/+in+Df8AwoLT/wCOUf8ADRnwn/6Kf4N/8KC0/wDjlfjPmjNL
/Wap/wA+l9//AAB/8QPwf/QdL/wBf5n7JfBrxP8A8JdbeLdRg8T6Z4q0x9fnXT7nSdQivI4LfyoS
sJaMkKwJYlScjcD3Fekehr43/wCCX2R8HfHRz/zOEvX/ALBun19kc/lX22HqutRhUa3Sf3o/l7N8
EstzGvgoy5lTnKN+/K2r/Ow+iiiug8o88+Mmtz+GNE0XWT4hsPDGjafrNpNq+oaneR2luLIsUdGk
kIUbmeNQCRkkAc1R/wCGofg4f+as+Bv/AApLP/47Xi//AAVI05739j/xBKl2tstpqWmzujNzODdJ
HsHqQZA+PRD6V+L4PAHev2fgPgHD8X4atXrYh03BpWSTvdeZ52KxUqDSSvc/oM/4ag+Df/RWfA3/
AIUln/8AHaP+GoPg3/0VnwN/4Uln/wDHa/ny5o5r9T/4ghgP+g2f/gK/zOH+0pfyn9BR/af+Dn/R
WvA3/hSWf/x2n/BbxUnjO18Wana+KtL8W6VJr040670fUYr2GC38qHbCXiJCsCWJUnI3A9xX8+YP
tX62/wDBH4E/s5+L/wDscrj/ANILGvzjjnw6w3CWXQxtHESqOU1GzSW6bvp6HZhsW683Fq2h92Uh
paK/DD0xpzXn3xj1i58OaLousDX7Hw3pNhrNpPq19qN4lrALPcVdGdyFG5mQAZGSQK9AbPSvnb9u
vTnvvglYzLdi3Sz8T6JM8ZbmcG/ij2D1IMgfH+wfSuevUdGlKoleyb+45sRVdCjOqleyb+5HpQ/a
G+FTDI+Jfg8g/wDUetP/AI5R/wANC/Cv/opfhD/wfWv/AMcr4por8TfiTUTt9VX/AIG//kT+dH4v
1k7fUl/4G/8A5E+zrn49/Ci9glhm+I/g2WGRSrI2u2hDKRggjzOQRXxz8AfDXwh+GH7RfizXNR+K
HghdF0dyNAEviSz+fzgTkgyZJiQmMk9WOR0qvXwT+0p/yXXxZkfx23/pJBX634XVKPiXxDHKcVT9
iowc1JPmellazSP0ngrxWzDMJ4vLqFL2UKlP3rSvdKUVbZW337XP2U+H/wC0f8PbAeI/+Eh+MXga
58/WbmbTv+Knsm8uyO3yk4k4xhuK6W6/aU+C95bywS/FbwJJFIpR0bxHZEMpGCCPM5BFfz9c0c+9
f2n/AMQQwH/QbP8A8BX+Z9aszmndRP1Q/Zz8I/CbwD+0N4r8QzfErwXceH9HcjQHHiG0cP5wJ3Z8
zrEhMZPdjkdK+xh+0L8LAQP+Fl+Dv/B9a/8Axyvyw/Y0GPhrrH/Yak/9J7eve6/z04l4njwnneNy
WhQ540akoqTlZuzavazsfnnF3jHmE81nSxeHVR01GKfO1oorpyv/AIc+r/F/xo8K+JdR8JWHhL4l
+FTfy69aLcW0GvWpkurclg8KKHJdmJUBQMntXsuDuBJr84Lj/kYPBP8A2OHh3/072lfo9g55PSvp
eG87ln2ElipQ5LScbXvsk+y7n1PCXEUuJ8DLGSpeztJxte+yTvey7ktFFFfWH3A3pXi2i/Grwr8P
tc8WaN4/+JvhPTNZTWZ5rbT9R1+1iuLazkVHgR43dWT5TuAI6MD0Ne0Gvwf/AG67CTTf2wfinFJd
res2pRzCRTkKJLWCQJ9UDBCOxWvuODOHafFGaLL6tRwTTd0rvT1OXEVnRhzJXP2W/wCGoPg3/wBF
Z8Df+FJZ/wDx2j/hqD4N/wDRWfA3/hSWf/x2v58ufejmv6C/4ghgP+g2f/gK/wAzyv7Sl/Kf0F/8
NPfBvP8AyVrwNj/sZLP/AOOVzniv48+CvFl54X0zwX8VvB1xqs2vWIltLXxFaNNdW/mjzYUQSEuz
DgKBk5wK/BftXon7OP8AycZ8JP8AscdF/wDS+CvGzjwfwWWZdiMbHFzk6cZStyrWybtuaU8fKc1H
l3Z/QtRRRX8vHthRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQBw3jz4Yp478TeCNabxHrGjP4U
1NtVt7TTRamG7laCS3Kz+dBI+3yZriPEbIcTMc7ljZO5oooAKKKKACiiigD5f/4KW/8AJlfxA95N
L/8ATnaV+Iw6e9fu1+3J4Mb4j/s46t4TW9Gmtr2t+H9KF6YfOFuZ9asYvM2bl37d+du4ZxjI618j
f8OY73/os0P/AISbf/J9fufh1xxl/CeGr0cZCTc5Jq3ZKx5mLw0q7Ti9j83vxFH4iv0i/wCHMV5/
0WaD/wAJNv8A5Po/4cxXn/RZof8Awk2/+T6/YP8AiM2R/wDPuf3HB/Z1Xuj83cV+t3/BH3/k3Pxe
D/0OVx/6QWNeZ/8ADmS9/wCizQ/+Em3/AMn19RfsO/A+y/Z08GeOvAdp4ofxZe6f4oaS/vDphsVh
ml02wkWJEMsu4CJ4W3bursMfLz+W+IPH+XcU5ZTweDhJSjNSd+yTX6nbhMLKjNyl2PpWiiiv5+PV
G96+Wf8AgpJY2d3+zFeSXN19mlt9b0uW1j/57SfakQp+CPI//AK+piK8L/bB+G+mfF74VWXhDUNa
k8O3eqa5YR6bqK2RvFiu1m3qHiEke5WVHU/OMbge2DlVi5wlBdUztwNeOGxVKvPaMk36J3PyXor7
W/4dYeIf+iv6Z/4R8n/yxo/4dYeIf+iv6Z/4R8n/AMsa/Pf9XcV/Mj+xY+MuRpJezn9x8U0V9rf8
OsPEP/RX9M/8I+T/AOWNH/DrDxD/ANFf0z/wj5P/AJY0f6u4r+ZFf8RmyP8A59z+477/AIJff8kc
8c5/6HCXj/uG6fX2MGBHH/16+ef2LvhJb/BTwZ408OQ+J/8AhK7lPE88l5eLpZ09Ipxa2kZiWMzS
lgFjRt27kuRgY5+hgCD0H5V99h6To0YU3ukl9yP5DzrGwzHM8TjKatGpOUlfs22vzJKKKK6Txz5F
/wCCpVlaXX7IGuyXN39mmt9U06W2j/57yG5RCn4I8j/8Ar8YB096/dz9s/4V6T8bfg7D4H1TXJfD
s2tazY2+nanHZG7EN0Jd674hJHuVlV1+8MbgecYPyJ/w5jvf+izQ/wDhJt/8n1+6+HfHGX8KYWtR
xkZNzaat5aHmYvDSryTj0Pze/EUfiK/SL/hzFef9Fmg/8JNv/k+j/hzFef8ARZof/CTb/wCT6/Xv
+IzZH/z7n9xwf2dV7o/N3Ffrd/wR9/5Nz8Xg/wDQ5XH/AKQWNeZ/8OZL3/os0P8A4Sbf/J9fUX7C
/wAELH9nr4eeL/CFn4pk8WyweKLiS7vW0w2Ijn+y2qGJUMsu4BY0O7dyWIwMc/lviDx/l3FOWU8H
g4SUozUnfsk1+p24TCyozcpdj6Vooor+fj1RpPFfOf7d9nZ3XwU06S5uvs81v4p0SS2T/nvIb6NC
n4I8j/8AAK+jCM14r+1b4H0/4kfDvSPDt5rDaBqF34h01tKvzZG8jjvEmEkYkhEkZZGEbqfnXG7O
eK5sRTdWjOmt2rHJiqTr0KlOO8k1958p0V61/wAMW/EL/oqfhn/wirj/AOWlH/DFvxC/6Kn4Z/8A
CKuP/lpX8+vw9zNu/PE/lt+FWbt39pA8lr4I/aVyfjp4r/37X/0kgr9UD+xf8Qh/zVLw0f8AuSrj
/wCWleQeN/8AgktrHj/xbqXiDUfjBZQ3l8YzJHbeEXWNSkSxjaDqBPRAeSec/Sv3Xwcws/D/AIk/
tfMXzU+SUbR31t/kfccI8DZhkOMqYjEzi1KPKrd+ZP8AQ/MT8RR+Ir9B/C//AASTj8Xf2t/Z/wAa
kf8AsvUJtMuPM8IMuJo8bwP9P5HzDmtv/hzFef8ARZoP/CTb/wCT6/un/iM2R/8APuf3H6r/AGdV
7o8j/YzOfhprH/Yak/8ASe3r3uuo+GX/AATj8WfCjQrrSdJ+LWj3NvPdG7Zr7wdK7hyiJgFdSUYx
GvbqTz6dif2L/iEP+apeGj/3JVx/8tK/zU4z4VxnEPEWOzbCyShWqSmk90pNtXPxHP8Aw6zPNMyq
4ulOKjK1rvySPG7jP9v+Csf9Dh4e6/8AYXtK/R8Due9fF+qfsu+IPCHiDwVe+JPiZo9zYf8ACUaU
8dvp3hCaGWeaK6juI4vMbUZBGGaDaWKNgE8V9ogEDnr7V9Jwrk9fJMFLD4hptyctPNJfofp/BOQY
nhzLp4TFNOTm5admkv0H0UUV9ofoI3Pevwc/bnsrOx/bA+KkdjdfbIW1SOVpMdJHtoXlT/gDs6f8
Br948Zr87Pin/wAE3dO/aR+MfxA8caB8Tn0GC61l7e50258OtcmC6jijSbbL9rj3qWBYfKMbsc4y
f0DgbP8ADcN5vHH4tNwSast9TkxNJ1qfKtz8u/xFH4iv0i/4cxXn/RZoP/CTb/5Po/4cxXn/AEWa
D/wk2/8Ak+v6T/4jNkf/AD7n9x5H9nVe6PzdxzXof7OP/Jxvwk/7HLRf/S+Cvt4f8EZb3/ossP8A
4Sjf/J1WPDf/AATDt/gd8RPAHi/Vfi3/AGhFYeKNLkhs4fCxja4nW6jeOIv9tbYGZAC21sA5wa8L
O/FjJsxyzE4OlTmpVISirrq1Y0p4CpCak3s0fphRRRX8knvBRRRQAUUUUAFFFFABRRRQAUUUUAFF
FFABRRRQAUUUUAFFFFABRRRQB5V+0r/yTrSP+xz8J/8AqQ6dXqteVftK/wDJOtI/7HPwn/6kOnV6
rQAUUUUAFcT4B1fR9S8V/Em20zS/7PvdP8QQ22qXGc/brk6VYSrN7Yglt4v+2NdtXF+CfEM+teJv
iDZy6Smnx6RrsVlDcohU36NpljOZ2JHzENO0WRniEDsQADtKKKKACuI+J2saPo//AAif9r6X/an2
rxBaWtnyB9muW3+XN/wHB/Ou3rjPiP4iuPDo8MGDSI9W+3a5a2T70LfZkfdmcYBwVx196AOzoooo
AKKKKAOI+GusaPq134zXSdL/ALMez8QT2t82c/arkRQlpvxVkH/Aa7euM+HniGfxBdeLVn0iPSv7
P1yayjZEK/a0WKJhMcgZJ3kZ/wBmuzoAKKKKAOI+J2saPo//AAif9r6X/an2rxBaWtnyB9muW3+X
N/wHB/Ou3rjPiP4iuPDo8MGDSI9W+3a5a2T70LfZkfdmcYBwVx1967OgAooooAK4j4a6xo+rXfjN
dJ0v+zHs/EE9rfNnP2q5EUJab8VZB/wGu3rjPh54hn8QXXi1Z9Ij0r+z9cmso2RCv2tFiiYTHIGS
d5Gf9mgDs6KKKACuI+J2saPo/wDwif8Aa+l/2p9q8QWlrZ8gfZrlt/lzf8Bwfzrt64z4j+Irjw6P
DBg0iPVvt2uWtk+9C32ZH3ZnGAcFcdfegDs6KKKACiiigDiPhjrGj6x/wln9kaX/AGX9l8QXdrec
g/abldnmTf8AAsj8q7euM+HHiK48RDxOZ9Ij0n7Drl1ZJsQr9pRNuJzkDJbPX2rs6ACiiigDiPid
rGj6P/wif9r6X/an2rxBaWtnyB9muW3+XN/wHB/Ou3rjPiP4iuPDo8MGDSI9W+3a5a2T70LfZkfd
mcYBwVx1967OgAooooAK4j4Y6xo+sf8ACWf2Rpf9l/ZfEF3a3nIP2m5XZ5k3/Asj8q7euM+HHiK4
8RDxOZ9Ij0n7Drl1ZJsQr9pRNuJzkDJbPX2oA7OiiigAriPilrGj6NaeG21jS/7VjuPEFha2q5x5
Fy8oEU3/AABua7euL+JXiCfw7aeH3g0iPVjd65Y2TrIhb7OkkoUzjAOCnUHtQB2lFFFABRRRQAUU
UUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFYfiqy1vUNDnt9A1W10TVGZfLvbuxN5GgDAtmIS
R5yMj73Gc80AblFeU/8ACF/F/wD6Kh4f/wDCPb/5Oo/4Qv4v/wDRUPD/AP4R7f8AydQAv7Sv/JOt
I/7HPwn/AOpDp1eq14R44+DPxS8d6LbabffFLQ0gg1PT9UUxeEGB82zvIbuIf8fvQvAgPsTXQ/8A
CF/F/wD6Kh4f/wDCPb/5OoA9Woryn/hC/i//ANFQ8P8A/hHt/wDJ1H/CF/F//oqHh/8A8I9v/k6g
D1auR8HX/iC88R+O4dZtvJ0601mOHRH8sL51kdOsnd8/xf6S92uT/cx2rl/+EL+L/wD0VDw//wCE
e3/ydWbpvw6+MVje6tPJ8XdIu1vrlbiOGbwgSlqohij8uP8A03hSYzJz/FI9AHtFFeU/8IX8X/8A
oqHh/wD8I9v/AJOo/wCEL+L/AP0VDw//AOEe3/ydQB6tXJeP7/xDYf8ACOf8I9bfafP1q2h1H5A3
l2R3ea/PTGF5rlv+EL+L/wD0VDw//wCEe3/ydWdq/wAOPjDqgs9nxd0ix+z3KTt9m8JFfOC5zG+b
05Q55HtQB7PRXlP/AAhfxf8A+ioeH/8Awj2/+TqP+EL+L/8A0VDw/wD+Ee3/AMnUAerUV5T/AMIX
8X/+ioeH/wDwj2/+TqP+EL+L/wD0VDw//wCEe3/ydQB1HgO/8RX9z4oGv232aO31qaHTDsC+ZZCO
Io/HXLGQZ9q66vGNJ+HHxh0xr9n+LukXoublrhRceEiRACqjy0xe8INpIH+0a0f+EL+L/wD0VDw/
/wCEe3/ydQB6tRXlP/CF/F//AKKh4f8A/CPb/wCTqP8AhC/i/wD9FQ8P/wDhHt/8nUAdT4/v/ENh
/wAI5/wj1t9p8/WraHUfkDeXZHd5r89MYXmutrxjV/hx8YdUFns+LukWP2e5Sdvs3hIr5wXOY3ze
nKHPI9q0f+EL+L//AEVDw/8A+Ee3/wAnUAerUV5T/wAIX8X/APoqHh//AMI9v/k6j/hC/i//ANFQ
8P8A/hHt/wDJ1AHq1cj4Dv8AxFf3Piga/bfZo7fWpodMOwL5lkI4ij8dcsZBn2rl/wDhC/i//wBF
Q8P/APhHt/8AJ1Z2k/Dj4w6Y1+z/ABd0i9FzctcKLjwkSIAVUeWmL3hBtJA/2jQB7PRXlP8Awhfx
f/6Kh4f/APCPb/5Oo/4Qv4v/APRUPD//AIR7f/J1AHq1cl4/v/ENh/wjn/CPW32nz9atodR+QN5d
kd3mvz0xhea5b/hC/i//ANFQ8P8A/hHt/wDJ1Z2r/Dj4w6oLPZ8XdIsfs9yk7fZvCRXzgucxvm9O
UOeR7UAez0V5T/whfxf/AOioeH//AAj2/wDk6j/hC/i//wBFQ8P/APhHt/8AJ1AHq1FeU/8ACF/F
/wD6Kh4f/wDCPb/5Oo/4Qv4v/wDRUPD/AP4R7f8AydQB1PgC/wDEN/8A8JH/AMJDbfZvI1q5h075
AvmWQ2+U/HXOW5rra8Y0j4b/ABh0v7Zv+LmkXv2i4edftPhIt5IbH7tMXowgxwPetH/hC/i//wBF
Q8P/APhHt/8AJ1AHq1FeU/8ACF/F/wD6Kh4f/wDCPb/5Oo/4Qv4v/wDRUPD/AP4R7f8AydQB1Pj+
/wDENh/wjn/CPW32nz9atodR+QN5dkd3mvz0xhea62vGNX+HHxh1QWez4u6RY/Z7lJ2+zeEivnBc
5jfN6coc8j2rR/4Qv4v/APRUPD//AIR7f/J1AHq1FeU/8IX8X/8AoqHh/wD8I9v/AJOo/wCEL+L/
AP0VDw//AOEe3/ydQB6tXJeAL/xDf/8ACR/8JDbfZvI1q5h075AvmWQ2+U/HXOW5rlv+EL+L/wD0
VDw//wCEe3/ydWdpHw3+MOl/bN/xc0i9+0XDzr9p8JFvJDY/dpi9GEGOB70Aez0V5T/whfxf/wCi
oeH/APwj2/8Ak6j/AIQv4v8A/RUPD/8A4R7f/J1AHq1cj8QtQ8RafbaC3h23+0yy61Zw3w8sPssm
kAnfnphec9q5f/hC/i//ANFQ8P8A/hHt/wDJ1Z2r/Dj4w6olqsfxd0iwMFzHcE23hEgyhWyY2zen
KN0IoA9nqvcXEdtGHlkSFCypukYKCzMFUc9ySAB3JArzH/hC/i//ANFQ8P8A/hHt/wDJ1eB/t1fC
34yeKv2WvGelW/ia08aXF1Jp6R6HonhZ4bq5b+0LYjY4upCu0jeTtI2o2cDkAH2lRXx7+wV8Kf2j
/hv4djj+MPjS1v8ARPJ22nh69H2/UbU443XoYBQMY2ZmGOAUr7CoAKKKKACiiigAooooAKKKKACi
iigAooooAKKKKACiiigAooooA5H4gfECD4f2emH+zNQ17VdXvv7P0zR9M8kXF7OIZZ2RGnkihTbD
bzyEySICIiAS7KrWvAnjax+IPhuDWrCG5tkae4tJ7S7VRNa3VvO9vcwPtZkLRzRSxlkZkYoSjOpV
jxfxzjuNP1b4ZeJf7P1C+0rw34mk1DUzpllNfXEUEmk6jaK6W8CvNL++uoFIjRioYuQERmW1+z1p
N9pXw3ka+sriwfUfEGvaxBBdRNDN9lvNXvLu2Z42AeNmhniYxuFdCxV1VlZQAenUUUUAFcjonxH0
vXPiR4o8FW9tqEeq+HrOwvrua4tGit5EuzcCIQu2PNx9mfcyAoCdu4usip11eO+GL9m/at+IEZ0z
WIoH8J6HbR6hNpF1HYzSwXWpyTRx3TRiGRlS+tjtVyfmcDJjkCAHsVFFFABXN+NvFc3hDSorm10D
WPE99POIINM0SKNppW2sxJkmkjhiUIjnfNIikgIpMjxo3SVw3xc+JTfCzwbLrNvoGseJr6SeO0td
O0bTrq8ZpXOA832aGZ4oEALSSiNyqqQqSSFI3ANXwJ42sfiD4bg1qwhubZGnuLSe0u1UTWt1bzvb
3MD7WZC0c0UsZZGZGKEozqVY9JXmP7OdvFb/AAf0ZY4NXjnaa8lvbjXtKk0q71C9a7ma6vms5Dut
1uZzLcpEcbUnQBUACj06gAooooA88g+L9v8A8JzZ+Hb7w14g0i01G9n0zS9dv4IY7TUbyGKWWSGK
PzTcr+7trllllhSJ1gLJIwkhMnodeD6vqFv4r/aJ8G6p4Z0zxQut6PNe6Rr95qWkalaaaujm3uGd
YHuo0tJGe/j00+ZbFpZFiUhmhRse8UAFFFFAGL4o8UaZ4K0K61fV7v7JYW+0MyxtK7u7hI4o40Be
WV3ZUSNAzu7qqqzMAavw98aWPxK8BeG/F+mRXEGm6/plrq1rHdqqzLFPEsqK4VmAYK4BAJGc4J61
y3xb+HPirx5qnhi60HxNpGk2ejzSXc2la9okup2l3chomtZ2WK7tjut2SRkVmdN7pJtEkMTpU/ZU
0TXPDX7M3wr0rxHH9n1qz8NafBPbGye0e2226BYZIndmEsa7Uckjc6M21AdigHrFFFFABXnmg/Fq
TxT461HQdK8H+ILzRtPvZNPn8Xo9iNJ8+OINKiZuhcSbJCbdikLBZkkQkGNyvodeEaNoejyfG22v
fhz4UuPCtxBqd5J441VvD8+kW2sRNDOqIWlijW/na8aKZLiMSBI4rj98guAlwAe70UUUAFYvijxR
pngrQrrV9Xu/slhb7QzLG0ru7uEjijjQF5ZXdlRI0DO7uqqrMwB2q8R/ab8J2fiSH4dXes6NqGue
FdF8TNf65aaZa3F5K1q2l6hbKrW1sGmuInmuYI5IVR1aORxIpi8ygD1XwtrN34g0K1v7/QtQ8NXU
27fpeqSW73EGGKjebeWWI7gAw2yNwwzg5A2a8x/Z30m+0X4V2treWdxpsH9p6rNplhcxNC1tpcmo
3MmnQiFgGgVLN7ZVgZVaFVWMohQqPTqACiiigDyfRvj0+qeOvD/hyf4e+L9Ij1/7RJp+qahHYpE8
EMRkNxJbC6N5BEcxJma3QpJcQRyCN5AtesV5joek3/iD47eJ/Ed/ZXEOm+H9Mg8O6M1zE0ReWfZe
ajPCQMSwSL/ZcQcklZbG4VVT5jJ6dQAUUUUAcj8QPiBB8P7PTD/Zmoa9qur339n6Zo+meSLi9nEM
s7IjTyRQptht55CZJEBERAJdlVrXgTxtY/EHw3BrVhDc2yNPcWk9pdqomtbq3ne3uYH2syFo5opY
yyMyMUJRnUqx4r9odbi58K6FazWGoXfhefWYD4il0axmvNRtbONJZopbWOBXmEpvIrJPMgRpYlke
WNomjE8Wt8Bo9Ug+FGh22qWH9m/ZPPtLCBrFbF202KeSPT5JLZVRYJZLRLeR4hHF5buy+VFt8tQD
0OiiigArzHRvjrpOs+MrbRU0XWLfTb7U7zQ9N8RTLb/Yb/UbQT/abWNFmNwjR/Y7wb5YY42+zPtd
t8XmenV8z+Dfh34j1L4y6bHpt/5Pwz8H+JtY8RY1fw7c2Wo3GrXov0lt4Z5ZlW4tlbUrqUTrbqm0
W0cclw3nvGAfTFFFFABXJfFP4j6X8IPhz4j8aa1BqF3pWhWcl9cw6XaNc3DogyQiL+rMVRBlnZEV
mHW15R+1ZHcXP7M/xUs7Kw1DVb+/8M6hp9pY6XYzXlxPPPbvDEiRQqznLyKCQMKMsxCqSADf8f8A
xMXwVqulaNY+HdX8XeIdThuLyDSNFNqk32WBoUnnL3U8EQVHubddvmbyZgVVgrld7wn4o0vxx4W0
fxJol19t0bWLKHULG58to/OglQSRvtcBlyrA4YAjPIBryvxv4hTRvin8PfiJNpPiC48L/wDCNavp
8kmn6BfXl5DPdz6VPbpLZQwtcxZjs7jcXiARkCOVZkVuq/Z88Lan4H+Anw18Oa3bfYda0fwzpmn3
1r5iyeTPFaxxyJuQlWwykZUkHHBIoA6vWfFGmaBqOhWN/dfZ7rXL1tP0+MRs3nzrbzXJTIBC/uba
ZstgfJjOSAbOl3k9/bSSz2FzpzrNNEIbloyzKkjIsg8t2G2RVEigkMFdQyo25R4v+0t4csrvxV8F
/Etx4IuPGdx4f8WyTKlhpS3tzAH0q/EW1mG2FTeLY/vZGjiSRIXd0CB1+d/hl4M8I6z498Mw+KfB
Hj/VvDul2Xjn7RaeJPDXiG6spo5tdS/0/wA+K4haO5llthNL+8V5Hljtw+6eO3CgH6AUV8FeFdF8
TQeAfDFn4X0Pxvp/xJ8U/CDWrfWtYvdM1O2u7vxL5Votkb7UbhFCzxyQaisDzygRIyiIpHNEHtL8
LvCPhjwTdQaFZeP9R8OX+tWQkstc+GAk0Fp47a+LG68P2NnYz3EWGhLXHk4M66YRI4tnSMA+so/i
rY3njLxp4V0/SNX1HXPC2mWepz262ywLei6Fz5MVrJO0aSsTaupfcIgzBTIGWQJ3NfCnxB0CY/Dj
4v8AhOL4f+MPD0jfBrQdEsNE0iw1S+SG/gGo406G/gjK3nlNfWUblXZZEMvmZRJwvqmlafoGq/Gn
Wdc8Q+BfEGr+JNU1nTtQ8Ia2NAu4rjT9J/s+xDob90QWES3Cag81lLLE7h5lMEhuQkwB9L0V8Ow/
C1dM8Y/EDxFq8nxWPjozeKLm7bwjoVrDK2lyC9FisOrGzSW8YW72XkWq3kzRXC2wMKLasIPdf2U/
DNp4Z8E68LDwhp/hS1vdZe6R9L0G48P2+p/6Nbxm6TSrhmlscGMwGNj+8NsZxxOKAPbaKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiuR8dfF
bwR8L/sP/CZeMvD/AIS+3b/sn9u6pBZfaNm3f5fmuu7bvTOM43LnqKTwv8V/BHjiztrvw34y0DX7
S6vW023n0rVILlJrpYTO1ujI5DSiFWkKD5gilsYGaAOvoorm/BXxB8L/ABI0qXU/CXibSPFOmxTG
2kvNEv4ryFJQqsYy8bMAwV0O3OcMD3FAHSUUUUAFFUNM1Wy1q3e50+8t763Saa2eS2lWRVlikaKW
MlSQGSRHRl6qysDggir9ABRRRQAUUUUAFFFUNT1Wy0W3S51C8t7G3eaG2SS5lWNWllkWKKMFiAWe
R0RV6szKBkkCgC/RRRQAUUUUAFFFUNX1Wy0DS7zU9TvbfTtNsoXubq8u5VihgiRSzyO7EBVVQSWJ
AABJoAv0UUUAFFFc341+IPhf4b6VFqfi3xNpHhbTZZhbR3mt38VnC8pVmEYeRlBYqjnbnOFJ7GgD
pKKK5vxr8QfC/wAN9Ki1Pxb4m0jwtpsswto7zW7+KzheUqzCMPIygsVRztznCk9jQB0lFeeeIv2g
vhZ4PvVtNe+JfhDRLtvM2wajr1rbufLmkgkwryA/LNDNG3o8TqeVIGrb/FbwRfa7oeiW/jLQLjWd
csl1LStOi1SBrjULVlZ1uIIw+6WIrG7B0BUhGOcA0AddRXOeG/iB4W8Y6trOmaB4m0fW9S0Sb7Nq
llpt/FcTWEu518udEYmJt0cg2sAcow7GujoAKKKoWeq2WpXN/bWt7b3VzYTC3u4oJVdraUxpKI5A
DlGMcsb7Tg7ZEPRgSAX6KK5GX4r+CLbxTd+GJfGOgReJLPyPtOjyapALyDznijh3wl96+Y9xAi5H
zNNGBkuuQDrqK888LftCfC3xxrtronhz4leD/EGtXRb7Pp2ma9a3NxNtUu2yNJCzYVWY4HAUnoKt
Wfxv+HWpeDr7xda+PvDF14UsJhbXmvQ6xbPY20pKARyTh9iMTLGNpIP7xP7wyAdzRVDSNVstf0uz
1PTL231HTb2FLm1vLSVZYZ4nUMkiOpIZWUghgSCCCKv0AFFFFABRRRQAUUUUAFFFFABRRRQAUUUU
AFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAeJftF22t3Xif4KReG9SsNL1p/Gc
32e81Sxe+t4/+JBrBbfCk0LPldwGJFwSDyBtNQnxr8P9T+BFjqGq6R/a/iPUzY+ObjT9NQPreoR+
H7p/tCzAIFUSWCf8sgzKkKgxojRv6r4k+H/hbxjq2janr/hnR9b1LRJvtOl3upWEVxNYS7kbzIHd
SYm3RxncpByinsKPEnw/8LeMdW0bU9f8M6PrepaJN9p0u91KwiuJrCXcjeZA7qTE26OM7lIOUU9h
QB87fBTU/GXxm17w9da/4j8Qa74R1HwzdXHi7QNS0Cyj8Ptf3C2yw2djcPZK19YlZL8iSG4uFZYI
C8zLIPO9J+FGsWXjf4uePfGVje272V7pmkaXpkUcqu19p9u99LHqajIZYJ57u8hiJXbItiZo3kjl
Ujivhb+xbonw51HTLcweEH8N6bZy6b5Ok+EksdT1q1a3e2+z6xd+e6X8TI/mSp5ESyTxxS4UJsPt
XgX4U+CPhf8Abv8AhDfBvh/wl9u2fa/7C0uCy+0bN2zzPKRd23e+M5xubHU0AddXDfGfxrffD/4Y
+INa0eKC48QrCtpolpdoxhutUuHW3sIHwy4WS5lgjLFlVQ5LMgBYdzXN+Nfh94X+JGlRaZ4t8M6R
4p02KYXMdnrdhFeQpKFZRIEkVgGCu43YzhiO5oA+TZvFXjL4I/Cz4uaNo1tr/gi/tfBk/ivw5ceO
zZatfXN1ZQCPV5/9DuZIBvJsJy0pDPd6hdzMkylkHvvw11jxRYfFLxd4N8Q+If8AhJhZaNpOvLet
ZRWvlTXk+oxTW8KRj5bZPsEZjWRpZl8xw80vyleg8Z/BH4d/ErVItT8XeAfDHinUooRbR3mtaNbX
kyRBmYRh5EYhQzuducZYnuat+HfhT4I8H682taD4N0DRNZayj05tR07S4Le5NrGsaR25kRA3lKsM
SqmdoESADCjAB4D8QvjJq/w6s/HF3rPxI/sa00T4saFpFpPqg0+BJNMu4dJnurF2aFQYo4b29kDj
EypAGaUhHJtfCzx38SU1XwVf+KvGdv4hXX/HHiLwhPptpo8NjZQ29k2sSR3CDLzeeH01IwWmMfku
FaN5VNw/v2p/D3wtrPiJNe1Dw1o9/rqQw2y6nc2EUlysUVwtzFGJWUsFSdEmVc4WRVcYYA1gab+z
58LdH/sr7B8NPCFiNJvG1LT/ALNoVrH9juj5ebiHEY8uU+RDl1w37qPn5RgA8/8AiF43+IviLVvh
dZ6OmofCeHXvE11oup22t2Gn6hfzQDSby6Wa3kgup4IsG3cLvDnzFjZkaJHiuMBPE3xbm+MOrxWf
ijR08E+EfEGkeGbufxBqVvanUhNaafLNJLbpppMl3K2oMkXk3dtEZfIXyCFcTe/+JPh/4W8Y6to2
p6/4Z0fW9S0Sb7Tpd7qVhFcTWEu5G8yB3UmJt0cZ3KQcop7Ckvfh94W1DxnYeL7vw1pF14rsITbW
euzWMT31tEQ4Mcc5XeikSyDaCB+8f+8cgHxvq/xF+LWvfC3WfHmk/Efxhpn9k+ANU8S6xGvh/TY9
HttZSCCa0tdPuJ9OP26xOL797DNcApFC32j94jS9V8cvGWn6/wDGfxD4NvvEmn69LoWtfDvXdK0S
4Fm9xot1L4hFvdtDsQTLmBrQsZGZlF7gFUmVT2vwX/ZCsvg14l0C70ybwxp+naBC1taz+HvCy6Zr
GpxCFoEj1W+W4cXqlWE0iiGIPcRQyjZ5ew+lXP7Pnwtu9Ch0Sf4Z+EJ9Fg8vytOfQbVrdNjTum2M
x7Rta6umGBwbiUjmRsgHzF4k+P3xM0/wZ4t1PQde1eSDUvh1rXjXRvEfiTRtLFjIbM2TxyaVa203
nxQSRXrkJqRklT/RiwkKTpJ9ZeH/AA94n0bwrqNvd+Lf7c8SXXmTw6hqGmRLZ2czIAscVtCY3Nsj
gssckzzbSVadjhhz2rfszfCDX9VvdT1P4UeCNS1K9me5ury78OWcs08rsWeR3aMlmZiSWJJJJJrt
v+ET0T/hFf8AhGf7GsP+Eb+x/wBm/wBj/ZU+x/Zdnl/Z/Jxs8rZ8mzG3bxjFAHzD8I/EfxU8d6V8
ILTVPifcJcePfAz+KdTvrLRLGOaxa3XTQkdiGjdEaU6hmd7hLhWMbeTHbBwI8rQf2j/HHijS/APj
S0uNYvIL2bwnYa1Y6XYadB4c0+bVV04zxXBuJTqMs4TUlljktj5K+Zao4cx3Bf6Ji/Z8+Flt9jMP
w18IRfY7KfTbbZoNqvkWs3m+dbpiP5YpPtE+5B8redJkHe2ad7+zN8INQtrG3u/hR4IuoLCE21nD
N4cs3W2iMjymOMGPCKZJZH2jA3SOerEkA8X+G3xO+JOqXOiNefEbR/EGsan448SeBriwh0WFNP0x
rSPVri3mkgSX7QZx9itvka5VTbTIpVpT9qfi7H49/E5f2c9P8WWPxI0/xBr2v/CbV/GJvzpFq9rp
d/pq2CvFbxxFf3rfa7hJvOeVVuIlZYoo1a2b6I+FPwNvvhzo+tXl3feGNW+IN3Nqslp4qh8MtbNb
xXt7Lfm2kU3TyywJdTyP5YnQFdg4YGRj4W/s1eFvBnwksPBniXQ/DHi+4OmWGlavqD+HooV1qKxR
Y7JrqKRpTI0UaRgF3YBlJUICFUA4C98e/EjR/GPj3Vr3xnb3OkaB8RdD8M2GgWmjwwQSWWojR0kF
zKxkldok1IvG0bxfvldn8yJ0t4jQfFPxB8d/FvSorDxf4otYLTxZqcOvaRp+iWh0GHR7R72K38nU
JbJxLPLJFp6TxR3byxvPdLsgMTCD1OP9mb4QQ6VcaYnwn8DpptzNFczWa+HLMQyyxrIscjJ5eGZF
mlCsRkCRwMbjngtN/ZCsdG+Jb+I9Pm8L6fA+vzeIW1W28LLH4oaWW7a8lgOrrcAGB5HeBk+z5a0Z
oCxJMtAHafEm/wBf1v4p+EPA+keJ9Q8IWmpaNq2s3GqaPBaS3jPaT6dDHCPtUE8QiYX8jN+737o4
8Oo3q/kGjRaj8fPH3wC8Ta7rdxYW/if4W6hqOraBZWdnLp12ssuhyXVq6XMEzmCcXAR137tsMYRk
JkMn0n41+H3hf4kaVFpni3wzpHinTYphcx2et2EV5CkoVlEgSRWAYK7jdjOGI7mi9+H3hbUPGdh4
vu/DWkXXiuwhNtZ67NYxPfW0RDgxxzld6KRLINoIH7x/7xyAeQftJeN9W+E3iHRfFd14x8QaX4Gk
0XWrW80jQrTTppzfwafcX8Fyhubdj8tvaX3Bl2mZLMFCjTkr8GdH8T6B8XhY/EXXf+El8XQ+ANJ2
apPHEiT3Rvb86v8AYgkUSiJWOlrJsjVti2PnZbYT7nqelWWtW6W2oWdvfW6TQ3KR3MSyKssUiyxS
AMCAySIjq3VWVSMEA1leNfh94X+JGlRaZ4t8M6R4p02KYXMdnrdhFeQpKFZRIEkVgGCu43YzhiO5
oA+d7O2svCvxN+FEfwO8NaBe6BJ4Z8XTWlnfajcaTYeTLqukSyzWzra3BaJ5nLRBEELRyBom8vyw
3QeC/Bd78N/jD8NYdalt0n1LTPGk8skDMbZNQ1HV7DVPsMUrqplZY1u9pKo0kdpLJ5aBWVPaL34f
eFtQ8Z2Hi+78NaRdeK7CE21nrs1jE99bREODHHOV3opEsg2ggfvH/vHNvxR4T0TxxoV1oniTRtP1
/Rbor9o07VbVLm3l2sHXfG4KthlVhkcFQeooA4D4Lf6T4z+NV/D+8sLzxkv2a6TmKfydG0u1m2MO
G8u4t54WwflkhkQ4ZGA+d/Enx++Jmn+DPFup6Dr2ryQal8Ota8a6N4j8SaNpYsZDZmyeOTSrW2m8
+KCSK9chNSMkqf6MWEhSdJPtHSNKstA0uz0zTLK307TbKFLa1s7SJYoYIkUKkaIoAVVUABQAAAAK
8/1b9mb4Qa/qt7qep/CjwRqWpXsz3N1eXfhyzlmnldizyO7RkszMSSxJJJJNAHm/in4g+O/AWp+L
PC114q/tm/b/AIRF49ZOnQQPYPrWtT6bdLaxBSgihSESW63HnursfOkuFwtW/wBkuXSdO8V/HrQL
PxHo/iLUrDxz517NpkdvBI7SaVp6tNcQwnYs7zRXKyuqoslxFckJHzGnqdl8Efh3pt1fXFr4B8MW
09/pg0S7lg0a2RrnTxGkQtJCEy8AjijTyjldsaDGFAHQeHPCuh+D7R7PQdG0/RLVvL3QadapbofL
hjgjyqAD5YYYY19EiRRwoAAPmz4P/FHx3e694Yn1/wAfaf4rl1Dx/wCIfA+paRp+mQWlrYpZrqtx
FIVDSTpc4sbcKHmKfZ5kDRvL/pL7/wAJtK8Gaz+zV8FbfxzY29/qyTaTcpHPE8l8viiJvNuZCEBl
F2l0l49yx+Zdt2Z8IJjXa/BL4In4ZRX1/r02geIvF9xe6lKviLTtB/s+4S1vb6S/ksyzzzyGJbme
VlHmBcbMqWUu3aWXw+8Laf4zv/F9p4a0i18V38ItrzXYbGJL65iAQCOScLvdQIoxtJI/dp/dGAD5
3+Gnhfxv8Q/Cd34f/svw/YeDLf4matq/9u/2zPLqLfYvFtxfeX9h+yLGN8tv5O77T8qv5mGI8omv
Yj/Y0+O+iOdutSXvjXTU01uLhrq+1G+ewtxH94y3C3lo0KY3Si5hKBhImfojwV8PvC/w30qXTPCX
hnSPC2myzG5ks9EsIrOF5SqqZCkaqCxVEG7GcKB2FF78PvC2oeM7Dxfd+GtIuvFdhCbaz12axie+
toiHBjjnK70UiWQbQQP3j/3jkA6SiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAC
iiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKK
KKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooo
oAKKKKACiiigAooooAKKKKACiiigAooooA//2Q==
------=_Part_343555_1040962665.1324366204520
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

------=_Part_343555_1040962665.1324366204520--



From xen-devel-bounces@lists.xensource.com Tue Dec 20 09:08:28 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 Dec 2011 09:08:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rcvfk-0007hO-Cv; Tue, 20 Dec 2011 09:07:44 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rcvfi-0007hJ-JI
	for xen-devel@lists.xensource.com; Tue, 20 Dec 2011 09:07:42 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1324372056!8733005!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzQwMQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31064 invoked from network); 20 Dec 2011 09:07:36 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Dec 2011 09:07:36 -0000
X-IronPort-AV: E=Sophos;i="4.71,381,1320624000"; 
   d="scan'208";a="9571112"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Dec 2011 09:07:36 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 20 Dec 2011 09:07:36 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Hui Lv <hui.lv@intel.com>
Date: Tue, 20 Dec 2011 09:07:35 +0000
In-Reply-To: <114495d1ff947737518b.1324332781@wsm-ep-n0>
References: <114495d1ff947737518b.1324332781@wsm-ep-n0>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1324372056.23729.8.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] xen/sched_credit: Use delay to control
 scheduling frequency
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2011-12-19 at 22:13 +0000, Hui Lv wrote:
> 1. Basically, the "delay method" can achieve 11% overall performance
> boost for SPECvirt than original credit scheduler.

Is it possible to publish the raw numbers?

> 2. We have tried 1ms delay and 10ms delay, there is no big difference
> between these two configurations. (1ms is enough to achieve a good
> performance)
> 3. We have compared different load level response time/latency (low,
> high, peak), "delay method" didn't bring very much response time
> increase.
> 4. 1ms delay can reduce 30% context switch at peak performance, where
> produces the benefits. (.int sched_ratelimit_us = 1000. is the
> recommended setting)
> 
> Signed-off-by: Hui Lv <hui.lv@intel.com>
> Signed-off-by: George Dunlap <George.Dunlap@eu.citrix.com>
> 
> diff -r a4bff36780a3 -r 114495d1ff94 xen/common/sched_credit.c
> --- a/xen/common/sched_credit.c	Fri Dec 16 18:46:27 2011 +0000
> +++ b/xen/common/sched_credit.c	Mon Dec 19 15:58:50 2011 -0500
> @@ -110,6 +110,10 @@ boolean_param("sched_credit_default_yiel
>  static int __read_mostly sched_credit_tslice_ms = CSCHED_DEFAULT_TSLICE_MS;
>  integer_param("sched_credit_tslice_ms", sched_credit_tslice_ms);
>  
> +/* Scheduler generic parameters
> +*/
> +extern int sched_ratelimit_us;

If this is generic then it seems like xen/sched.h is the right place for
it.

Is it really generic though if only the credit scheduler applies it?

> +
>  /*
>   * Physical CPU
>   */
> @@ -1297,10 +1301,15 @@ csched_schedule(
>      struct csched_private *prv = CSCHED_PRIV(ops);
>      struct csched_vcpu *snext;
>      struct task_slice ret;
> +    s_time_t runtime, tslice;
>  
>      CSCHED_STAT_CRANK(schedule);
>      CSCHED_VCPU_CHECK(current);
>  
> +    runtime = now - current->runstate.state_entry_time;
> +    if ( runtime < 0 ) /* Does this ever happen? */
> +        runtime = 0;
> +
>      if ( !is_idle_vcpu(scurr->vcpu) )
>      {
>          /* Update credits of a non-idle VCPU. */
> @@ -1313,6 +1322,41 @@ csched_schedule(
>          scurr->pri = CSCHED_PRI_IDLE;
>      }
>  
> +    /* Choices, choices:
> +     * - If we have a tasklet, we need to run the idle vcpu no matter what.
> +     * - If sched rate limiting is in effect, and the current vcpu has
> +     *   run for less than that amount of time, continue the current one,
> +     *   but with a shorter timeslice and return it immediately
> +     * - Otherwise, chose the one with the highest priority (which may
> +     *   be the one currently running)
> +     * - If the currently running one is TS_OVER, see if there
> +     *   is a higher priority one waiting on the runqueue of another
> +     *   cpu and steal it.
> +     */
> +
> +    /* If we have schedule rate limiting enabled, check to see
> +     * how long we've run for. */
> +    if ( !tasklet_work_scheduled
> +         && sched_ratelimit_us
> +         && vcpu_runnable(current)
> +         && !is_idle_vcpu(current)
> +         && runtime < MICROSECS(sched_ratelimit_us) )
> +    {
> +        snext = scurr;
> +        snext->start_time += now;
> +        perfc_incr(delay_ms);
> +        tslice = MICROSECS(sched_ratelimit_us);
> +        ret.migrated = 0;
> +        goto out;
> +    }
> +    else
> +    {

This is the same comment as the next block below, does it really apply
here too?

Since the previous if block ends with a goto the else clause is a bit
redundant.

> +        /*
> +         * Select next runnable local VCPU (ie top of local runq)
> +        */
> +        tslice = MILLISECS(prv->tslice_ms);
> +    }
> +
>      /*
>       * Select next runnable local VCPU (ie top of local runq)
>       */
> @@ -1367,11 +1411,12 @@ csched_schedule(
>      if ( !is_idle_vcpu(snext->vcpu) )
>          snext->start_time += now;
>  
> +out:
>      /*
>       * Return task to run next...
>       */
>      ret.time = (is_idle_vcpu(snext->vcpu) ?
> -                -1 : MILLISECS(prv->tslice_ms));
> +                -1 : tslice);
>      ret.task = snext->vcpu;
>  
>      CSCHED_VCPU_CHECK(ret.task);
> diff -r a4bff36780a3 -r 114495d1ff94 xen/common/schedule.c
> --- a/xen/common/schedule.c	Fri Dec 16 18:46:27 2011 +0000
> +++ b/xen/common/schedule.c	Mon Dec 19 15:58:50 2011 -0500
> @@ -47,6 +47,12 @@ string_param("sched", opt_sched);
>  bool_t sched_smt_power_savings = 0;
>  boolean_param("sched_smt_power_savings", sched_smt_power_savings);
>  
> +/* Default scheduling rate limit: 1ms 
> + * It's not recommended to set this value bigger than "sched_credit_tslice_ms" 
> + * otherwise, something weired may happen

                           weird

It that constraint enforced anywhere?

> + * */
> +int sched_ratelimit_us = 1000;
> +integer_param("sched_ratelimit_us", sched_ratelimit_us);
>  /* Various timer handlers. */
>  static void s_timer_fn(void *unused);
>  static void vcpu_periodic_timer_fn(void *data);
> diff -r a4bff36780a3 -r 114495d1ff94 xen/include/xen/perfc_defn.h
> --- a/xen/include/xen/perfc_defn.h	Fri Dec 16 18:46:27 2011 +0000
> +++ b/xen/include/xen/perfc_defn.h	Mon Dec 19 15:58:50 2011 -0500
> @@ -16,6 +16,7 @@ PERFCOUNTER(sched_irq,              "sch
>  PERFCOUNTER(sched_run,              "sched: runs through scheduler")
>  PERFCOUNTER(sched_ctx,              "sched: context switches")
>  
> +PERFCOUNTER(delay_ms,               "csched: delay")
>  PERFCOUNTER(vcpu_check,             "csched: vcpu_check")
>  PERFCOUNTER(schedule,               "csched: schedule")
>  PERFCOUNTER(acct_run,               "csched: acct_run")
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 20 09:08:28 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 Dec 2011 09:08:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rcvfk-0007hO-Cv; Tue, 20 Dec 2011 09:07:44 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rcvfi-0007hJ-JI
	for xen-devel@lists.xensource.com; Tue, 20 Dec 2011 09:07:42 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1324372056!8733005!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzQwMQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31064 invoked from network); 20 Dec 2011 09:07:36 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Dec 2011 09:07:36 -0000
X-IronPort-AV: E=Sophos;i="4.71,381,1320624000"; 
   d="scan'208";a="9571112"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Dec 2011 09:07:36 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 20 Dec 2011 09:07:36 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Hui Lv <hui.lv@intel.com>
Date: Tue, 20 Dec 2011 09:07:35 +0000
In-Reply-To: <114495d1ff947737518b.1324332781@wsm-ep-n0>
References: <114495d1ff947737518b.1324332781@wsm-ep-n0>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1324372056.23729.8.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] xen/sched_credit: Use delay to control
 scheduling frequency
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2011-12-19 at 22:13 +0000, Hui Lv wrote:
> 1. Basically, the "delay method" can achieve 11% overall performance
> boost for SPECvirt than original credit scheduler.

Is it possible to publish the raw numbers?

> 2. We have tried 1ms delay and 10ms delay, there is no big difference
> between these two configurations. (1ms is enough to achieve a good
> performance)
> 3. We have compared different load level response time/latency (low,
> high, peak), "delay method" didn't bring very much response time
> increase.
> 4. 1ms delay can reduce 30% context switch at peak performance, where
> produces the benefits. (.int sched_ratelimit_us = 1000. is the
> recommended setting)
> 
> Signed-off-by: Hui Lv <hui.lv@intel.com>
> Signed-off-by: George Dunlap <George.Dunlap@eu.citrix.com>
> 
> diff -r a4bff36780a3 -r 114495d1ff94 xen/common/sched_credit.c
> --- a/xen/common/sched_credit.c	Fri Dec 16 18:46:27 2011 +0000
> +++ b/xen/common/sched_credit.c	Mon Dec 19 15:58:50 2011 -0500
> @@ -110,6 +110,10 @@ boolean_param("sched_credit_default_yiel
>  static int __read_mostly sched_credit_tslice_ms = CSCHED_DEFAULT_TSLICE_MS;
>  integer_param("sched_credit_tslice_ms", sched_credit_tslice_ms);
>  
> +/* Scheduler generic parameters
> +*/
> +extern int sched_ratelimit_us;

If this is generic then it seems like xen/sched.h is the right place for
it.

Is it really generic though if only the credit scheduler applies it?

> +
>  /*
>   * Physical CPU
>   */
> @@ -1297,10 +1301,15 @@ csched_schedule(
>      struct csched_private *prv = CSCHED_PRIV(ops);
>      struct csched_vcpu *snext;
>      struct task_slice ret;
> +    s_time_t runtime, tslice;
>  
>      CSCHED_STAT_CRANK(schedule);
>      CSCHED_VCPU_CHECK(current);
>  
> +    runtime = now - current->runstate.state_entry_time;
> +    if ( runtime < 0 ) /* Does this ever happen? */
> +        runtime = 0;
> +
>      if ( !is_idle_vcpu(scurr->vcpu) )
>      {
>          /* Update credits of a non-idle VCPU. */
> @@ -1313,6 +1322,41 @@ csched_schedule(
>          scurr->pri = CSCHED_PRI_IDLE;
>      }
>  
> +    /* Choices, choices:
> +     * - If we have a tasklet, we need to run the idle vcpu no matter what.
> +     * - If sched rate limiting is in effect, and the current vcpu has
> +     *   run for less than that amount of time, continue the current one,
> +     *   but with a shorter timeslice and return it immediately
> +     * - Otherwise, chose the one with the highest priority (which may
> +     *   be the one currently running)
> +     * - If the currently running one is TS_OVER, see if there
> +     *   is a higher priority one waiting on the runqueue of another
> +     *   cpu and steal it.
> +     */
> +
> +    /* If we have schedule rate limiting enabled, check to see
> +     * how long we've run for. */
> +    if ( !tasklet_work_scheduled
> +         && sched_ratelimit_us
> +         && vcpu_runnable(current)
> +         && !is_idle_vcpu(current)
> +         && runtime < MICROSECS(sched_ratelimit_us) )
> +    {
> +        snext = scurr;
> +        snext->start_time += now;
> +        perfc_incr(delay_ms);
> +        tslice = MICROSECS(sched_ratelimit_us);
> +        ret.migrated = 0;
> +        goto out;
> +    }
> +    else
> +    {

This is the same comment as the next block below, does it really apply
here too?

Since the previous if block ends with a goto the else clause is a bit
redundant.

> +        /*
> +         * Select next runnable local VCPU (ie top of local runq)
> +        */
> +        tslice = MILLISECS(prv->tslice_ms);
> +    }
> +
>      /*
>       * Select next runnable local VCPU (ie top of local runq)
>       */
> @@ -1367,11 +1411,12 @@ csched_schedule(
>      if ( !is_idle_vcpu(snext->vcpu) )
>          snext->start_time += now;
>  
> +out:
>      /*
>       * Return task to run next...
>       */
>      ret.time = (is_idle_vcpu(snext->vcpu) ?
> -                -1 : MILLISECS(prv->tslice_ms));
> +                -1 : tslice);
>      ret.task = snext->vcpu;
>  
>      CSCHED_VCPU_CHECK(ret.task);
> diff -r a4bff36780a3 -r 114495d1ff94 xen/common/schedule.c
> --- a/xen/common/schedule.c	Fri Dec 16 18:46:27 2011 +0000
> +++ b/xen/common/schedule.c	Mon Dec 19 15:58:50 2011 -0500
> @@ -47,6 +47,12 @@ string_param("sched", opt_sched);
>  bool_t sched_smt_power_savings = 0;
>  boolean_param("sched_smt_power_savings", sched_smt_power_savings);
>  
> +/* Default scheduling rate limit: 1ms 
> + * It's not recommended to set this value bigger than "sched_credit_tslice_ms" 
> + * otherwise, something weired may happen

                           weird

It that constraint enforced anywhere?

> + * */
> +int sched_ratelimit_us = 1000;
> +integer_param("sched_ratelimit_us", sched_ratelimit_us);
>  /* Various timer handlers. */
>  static void s_timer_fn(void *unused);
>  static void vcpu_periodic_timer_fn(void *data);
> diff -r a4bff36780a3 -r 114495d1ff94 xen/include/xen/perfc_defn.h
> --- a/xen/include/xen/perfc_defn.h	Fri Dec 16 18:46:27 2011 +0000
> +++ b/xen/include/xen/perfc_defn.h	Mon Dec 19 15:58:50 2011 -0500
> @@ -16,6 +16,7 @@ PERFCOUNTER(sched_irq,              "sch
>  PERFCOUNTER(sched_run,              "sched: runs through scheduler")
>  PERFCOUNTER(sched_ctx,              "sched: context switches")
>  
> +PERFCOUNTER(delay_ms,               "csched: delay")
>  PERFCOUNTER(vcpu_check,             "csched: vcpu_check")
>  PERFCOUNTER(schedule,               "csched: schedule")
>  PERFCOUNTER(acct_run,               "csched: acct_run")
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 20 09:17:37 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 Dec 2011 09:17:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rcvoh-0007rd-Gp; Tue, 20 Dec 2011 09:16:59 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <250716708@qq.com>) id 1Rcvof-0007rU-Vh
	for xen-devel@lists.xensource.com; Tue, 20 Dec 2011 09:16:58 +0000
X-Env-Sender: 250716708@qq.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1324372610!6022604!1
X-Originating-IP: [64.71.138.44]
X-SpamReason: No, hits=5.1 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA2NC43MS4xMzguNDQgPT4gMTk0NzYw\n,sa_preprocessor: 
	QmFkIElQOiA2NC43MS4xMzguNDQgPT4gMTk0NzYw\n,FROM_ALL_NUMS,
	FROM_STARTS_WITH_NUMS,HTML_IMAGE_ONLY_12,HTML_IMAGE_RATIO_04,
	HTML_MESSAGE, MIME_BASE64_TEXT, MIME_BOUND_NEXTPART,
	received_headers: No Received headers
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3715 invoked from network); 20 Dec 2011 09:16:51 -0000
Received: from smtpbg55.qq.com (HELO smtpbg55.qq.com) (64.71.138.44)
	by server-14.tower-174.messagelabs.com with SMTP;
	20 Dec 2011 09:16:51 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qq.com; s=s0907;
	t=1324372608; bh=iT3vHQMvTv5eDSjwVJDEOlxh3yaNHUeNyytwh/2+E6E=;
	h=X-QQ-SSF:X-HAS-ATTACH:X-QQ-BUSINESS-ORIGIN:X-Originating-IP:
	X-QQ-STYLE:X-QQ-mid:From:To:Subject:Mime-Version:Content-Type:
	Content-Transfer-Encoding:Date:X-Priority:Message-ID:X-QQ-MIME:
	X-Mailer:X-QQ-Mailer;
	b=gz0EYBOiSKstpORuCoIAqWtumuMB+86e73f5DJt+B/sgNLCDyddhfnvyeT9yT4q2x
	wkpEr0dDoRKsM0lRHzSjJxNvsPkgtdHQix5JfandQsoGc4FR/Uog+D+qa09axJf
X-QQ-SSF: 00000000000000F0000000000000000
X-HAS-ATTACH: no
X-QQ-BUSINESS-ORIGIN: 2
X-Originating-IP: 118.192.67.234
X-QQ-STYLE: 
X-QQ-mid: webmail193t1324372606t4508534
From: "=?gbk?B?oei9S+y2YXdhcmU=?=" <250716708@qq.com>
To: "=?gbk?B?eGVuLWRldmVs?=" <xen-devel@lists.xensource.com>
Mime-Version: 1.0
Date: Tue, 20 Dec 2011 17:16:46 +0800
X-Priority: 3
Message-ID: <tencent_3D9457AB2ED114DE7CC8600B@qq.com>
X-QQ-MIME: TCMime 1.0 by Tencent
X-Mailer: QQMail 2.x
X-QQ-Mailer: QQMail 2.x
Subject: [Xen-devel] debuging about qemu-dm in xen-3.4.2
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============9221037163545570862=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a multi-part message in MIME format.

--===============9221037163545570862==
Content-Type: multipart/alternative;
	boundary="----=_NextPart_4EF0527E_DD47A308_02674E39"
Content-Transfer-Encoding: 8Bit

This is a multi-part message in MIME format.

------=_NextPart_4EF0527E_DD47A308_02674E39
Content-Type: text/plain;
	charset="gbk"
Content-Transfer-Encoding: base64

SGksDQogICAgIEkgYW0gYSBuZXdlciB0byBzdHVkeSBxZW11IGluIHhlbiwgDQogSSBoYXZl
IG5vIGlkZWEgaG93IHRvIGRlYnVnIGFuZCB0cmFjZSB0aGUgcWVtdS1kbSBlZmZpY2llbnRs
eS4NCiAgICAgDQogY2hlZXJzIA0KIGJydWNl

------=_NextPart_4EF0527E_DD47A308_02674E39
Content-Type: text/html;
	charset="gbk"
Content-Transfer-Encoding: base64

PERJVj4mbmJzcDs8L0RJVj4NCjxESVYgc3R5bGU9IlBPU0lUSU9OOiByZWxhdGl2ZTsgUEFE
RElORy1CT1RUT006IDBweDsgTElORS1IRUlHSFQ6IDE3MCU7IE1JTi1IRUlHSFQ6IDEwMHB4
OyBQQURESU5HLUxFRlQ6IDE1cHg7IFBBRERJTkctUklHSFQ6IDE1cHg7IEhFSUdIVDogMTAw
cHg7IEZPTlQtU0laRTogMTRweDsgT1ZFUkZMT1c6IHZpc2libGU7IFBBRERJTkctVE9QOiAx
NXB4IiBpZD1jb250ZW50RGl2IG9uY2xpY2s9ImdldFRvcCgpLnByZVN3YXBMaW5rKGV2ZW50
LCAnaHRtbCcpOyI+DQo8RElWIHN0eWxlPSJQQURESU5HLUJPVFRPTTogMHB4OyBNSU4tSEVJ
R0hUOiBhdXRvOyBQQURESU5HLUxFRlQ6IDBweDsgUEFERElORy1SSUdIVDogMHB4OyBGT05U
LUZBTUlMWTogJ2x1Y2lkYSBHcmFuZGUnLFZlcmRhbmE7IEhFSUdIVDogYXV0bzsgRk9OVC1T
SVpFOiAxNHB4OyBNQVJHSU4tUklHSFQ6IDE3MHB4OyBQQURESU5HLVRPUDogMHB4IiBpZD1t
YWlsQ29udGVudENvbnRhaW5lcj4NCjxESVY+SGksPC9ESVY+DQo8RElWPiZuYnNwOyAmbmJz
cDsgSSBhbSBhIG5ld2VyIHRvIHN0dWR5IHFlbXUgaW4geGVuLCA8L0RJVj4NCjxESVY+SSBo
YXZlIG5vIGlkZWEgaG93IHRvIGRlYnVnIGFuZCB0cmFjZSB0aGUgcWVtdS1kbSBlZmZpY2ll
bnRseS48L0RJVj4NCjxESVY+Jm5ic3A7ICZuYnNwOyA8L0RJVj4NCjxESVY+Y2hlZXJzIDwv
RElWPg0KPERJVj5icnVjZTwvRElWPjwhLS0gLS0+DQo8U1RZTEU+PC9TVFlMRT4NCjwvRElW
PjwvRElWPg0KDQo8SU1HIHN0eWxlPSJIRUlHSFQ6IDBweCIgaWQ9cXFtYWlsY29udGVudF9s
b2FkX2ZpbnNpaCB3aWR0aD0wIGhlaWdodD0wPg0KDQoNCg==

------=_NextPart_4EF0527E_DD47A308_02674E39--



--===============9221037163545570862==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============9221037163545570862==--



From xen-devel-bounces@lists.xensource.com Tue Dec 20 09:17:37 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 Dec 2011 09:17:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rcvoh-0007rd-Gp; Tue, 20 Dec 2011 09:16:59 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <250716708@qq.com>) id 1Rcvof-0007rU-Vh
	for xen-devel@lists.xensource.com; Tue, 20 Dec 2011 09:16:58 +0000
X-Env-Sender: 250716708@qq.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1324372610!6022604!1
X-Originating-IP: [64.71.138.44]
X-SpamReason: No, hits=5.1 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA2NC43MS4xMzguNDQgPT4gMTk0NzYw\n,sa_preprocessor: 
	QmFkIElQOiA2NC43MS4xMzguNDQgPT4gMTk0NzYw\n,FROM_ALL_NUMS,
	FROM_STARTS_WITH_NUMS,HTML_IMAGE_ONLY_12,HTML_IMAGE_RATIO_04,
	HTML_MESSAGE, MIME_BASE64_TEXT, MIME_BOUND_NEXTPART,
	received_headers: No Received headers
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3715 invoked from network); 20 Dec 2011 09:16:51 -0000
Received: from smtpbg55.qq.com (HELO smtpbg55.qq.com) (64.71.138.44)
	by server-14.tower-174.messagelabs.com with SMTP;
	20 Dec 2011 09:16:51 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qq.com; s=s0907;
	t=1324372608; bh=iT3vHQMvTv5eDSjwVJDEOlxh3yaNHUeNyytwh/2+E6E=;
	h=X-QQ-SSF:X-HAS-ATTACH:X-QQ-BUSINESS-ORIGIN:X-Originating-IP:
	X-QQ-STYLE:X-QQ-mid:From:To:Subject:Mime-Version:Content-Type:
	Content-Transfer-Encoding:Date:X-Priority:Message-ID:X-QQ-MIME:
	X-Mailer:X-QQ-Mailer;
	b=gz0EYBOiSKstpORuCoIAqWtumuMB+86e73f5DJt+B/sgNLCDyddhfnvyeT9yT4q2x
	wkpEr0dDoRKsM0lRHzSjJxNvsPkgtdHQix5JfandQsoGc4FR/Uog+D+qa09axJf
X-QQ-SSF: 00000000000000F0000000000000000
X-HAS-ATTACH: no
X-QQ-BUSINESS-ORIGIN: 2
X-Originating-IP: 118.192.67.234
X-QQ-STYLE: 
X-QQ-mid: webmail193t1324372606t4508534
From: "=?gbk?B?oei9S+y2YXdhcmU=?=" <250716708@qq.com>
To: "=?gbk?B?eGVuLWRldmVs?=" <xen-devel@lists.xensource.com>
Mime-Version: 1.0
Date: Tue, 20 Dec 2011 17:16:46 +0800
X-Priority: 3
Message-ID: <tencent_3D9457AB2ED114DE7CC8600B@qq.com>
X-QQ-MIME: TCMime 1.0 by Tencent
X-Mailer: QQMail 2.x
X-QQ-Mailer: QQMail 2.x
Subject: [Xen-devel] debuging about qemu-dm in xen-3.4.2
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============9221037163545570862=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a multi-part message in MIME format.

--===============9221037163545570862==
Content-Type: multipart/alternative;
	boundary="----=_NextPart_4EF0527E_DD47A308_02674E39"
Content-Transfer-Encoding: 8Bit

This is a multi-part message in MIME format.

------=_NextPart_4EF0527E_DD47A308_02674E39
Content-Type: text/plain;
	charset="gbk"
Content-Transfer-Encoding: base64

SGksDQogICAgIEkgYW0gYSBuZXdlciB0byBzdHVkeSBxZW11IGluIHhlbiwgDQogSSBoYXZl
IG5vIGlkZWEgaG93IHRvIGRlYnVnIGFuZCB0cmFjZSB0aGUgcWVtdS1kbSBlZmZpY2llbnRs
eS4NCiAgICAgDQogY2hlZXJzIA0KIGJydWNl

------=_NextPart_4EF0527E_DD47A308_02674E39
Content-Type: text/html;
	charset="gbk"
Content-Transfer-Encoding: base64

PERJVj4mbmJzcDs8L0RJVj4NCjxESVYgc3R5bGU9IlBPU0lUSU9OOiByZWxhdGl2ZTsgUEFE
RElORy1CT1RUT006IDBweDsgTElORS1IRUlHSFQ6IDE3MCU7IE1JTi1IRUlHSFQ6IDEwMHB4
OyBQQURESU5HLUxFRlQ6IDE1cHg7IFBBRERJTkctUklHSFQ6IDE1cHg7IEhFSUdIVDogMTAw
cHg7IEZPTlQtU0laRTogMTRweDsgT1ZFUkZMT1c6IHZpc2libGU7IFBBRERJTkctVE9QOiAx
NXB4IiBpZD1jb250ZW50RGl2IG9uY2xpY2s9ImdldFRvcCgpLnByZVN3YXBMaW5rKGV2ZW50
LCAnaHRtbCcpOyI+DQo8RElWIHN0eWxlPSJQQURESU5HLUJPVFRPTTogMHB4OyBNSU4tSEVJ
R0hUOiBhdXRvOyBQQURESU5HLUxFRlQ6IDBweDsgUEFERElORy1SSUdIVDogMHB4OyBGT05U
LUZBTUlMWTogJ2x1Y2lkYSBHcmFuZGUnLFZlcmRhbmE7IEhFSUdIVDogYXV0bzsgRk9OVC1T
SVpFOiAxNHB4OyBNQVJHSU4tUklHSFQ6IDE3MHB4OyBQQURESU5HLVRPUDogMHB4IiBpZD1t
YWlsQ29udGVudENvbnRhaW5lcj4NCjxESVY+SGksPC9ESVY+DQo8RElWPiZuYnNwOyAmbmJz
cDsgSSBhbSBhIG5ld2VyIHRvIHN0dWR5IHFlbXUgaW4geGVuLCA8L0RJVj4NCjxESVY+SSBo
YXZlIG5vIGlkZWEgaG93IHRvIGRlYnVnIGFuZCB0cmFjZSB0aGUgcWVtdS1kbSBlZmZpY2ll
bnRseS48L0RJVj4NCjxESVY+Jm5ic3A7ICZuYnNwOyA8L0RJVj4NCjxESVY+Y2hlZXJzIDwv
RElWPg0KPERJVj5icnVjZTwvRElWPjwhLS0gLS0+DQo8U1RZTEU+PC9TVFlMRT4NCjwvRElW
PjwvRElWPg0KDQo8SU1HIHN0eWxlPSJIRUlHSFQ6IDBweCIgaWQ9cXFtYWlsY29udGVudF9s
b2FkX2ZpbnNpaCB3aWR0aD0wIGhlaWdodD0wPg0KDQoNCg==

------=_NextPart_4EF0527E_DD47A308_02674E39--



--===============9221037163545570862==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============9221037163545570862==--



From xen-devel-bounces@lists.xensource.com Tue Dec 20 09:36:46 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 Dec 2011 09:36:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rcw76-00084A-8B; Tue, 20 Dec 2011 09:36:00 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Rcw74-000844-TC
	for xen-devel@lists.xensource.com; Tue, 20 Dec 2011 09:35:59 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1324373707!49708642!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22188 invoked from network); 20 Dec 2011 09:35:07 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-3.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 20 Dec 2011 09:35:07 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 20 Dec 2011 09:35:52 +0000
Message-Id: <4EF0653C0200007800069123@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 20 Dec 2011 09:36:44 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Dario Faggioli" <raistlin@linux.it>
References: <1324319661.2599.28.camel@Solace>
In-Reply-To: <1324319661.2599.28.camel@Solace>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Wei Wang2 <wei.wang2@amd.com>, Tim Deegan <tim@xen.org>,
	xen-devel@lists.xensource.com,
	"allen.m.kay@intel.com" <allen.m.kay@intel.com>
Subject: Re: [Xen-devel] [PATCH 0 of 3] Deal with IOMMU faults in softirq
	context.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 19.12.11 at 19:34, Dario Faggioli <raistlin@linux.it> wrote:
> As already discussed here [1], dealing with IOMMU faults in interrupt
> context may cause nasty things to happen, up to being used as a form of
> DoS attack, e.g., by generating a "storm" of IOMMU faults that will
> livelock a pCPU.
> 
> To avoid this, IOMMU faults handling is being moved from interrupt to
> softirq context. Basically, the inerrupt handler of the IRQ originated
> by an IOMMU (page) fault will raise a softirq-tasklet which will then
> deal with the actual fault records by clearing the logs and re-enabling
> interrupts from the offending IOMMU(s). A single tasklet is being used
> even if there are more than just one IOMMU in the system, as the event
> should be rare enough.
> 
> The series introduces the described mechanism for both Intel VT-d and
> AMD-Vi, and has been tested on both platforms with an hacked DomU bnx2
> network driver which was generating I/O page faults upon request.

These look good to me (apart from a minor indentation issue in the
2nd patch), but we'd surely like to have an ack from the respective
maintainers. Also, despite the subject here, I suppose the series
consists of just two patches?

Thanks for doing this!

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 20 09:36:46 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 Dec 2011 09:36:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rcw76-00084A-8B; Tue, 20 Dec 2011 09:36:00 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Rcw74-000844-TC
	for xen-devel@lists.xensource.com; Tue, 20 Dec 2011 09:35:59 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1324373707!49708642!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22188 invoked from network); 20 Dec 2011 09:35:07 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-3.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 20 Dec 2011 09:35:07 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 20 Dec 2011 09:35:52 +0000
Message-Id: <4EF0653C0200007800069123@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 20 Dec 2011 09:36:44 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Dario Faggioli" <raistlin@linux.it>
References: <1324319661.2599.28.camel@Solace>
In-Reply-To: <1324319661.2599.28.camel@Solace>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Wei Wang2 <wei.wang2@amd.com>, Tim Deegan <tim@xen.org>,
	xen-devel@lists.xensource.com,
	"allen.m.kay@intel.com" <allen.m.kay@intel.com>
Subject: Re: [Xen-devel] [PATCH 0 of 3] Deal with IOMMU faults in softirq
	context.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 19.12.11 at 19:34, Dario Faggioli <raistlin@linux.it> wrote:
> As already discussed here [1], dealing with IOMMU faults in interrupt
> context may cause nasty things to happen, up to being used as a form of
> DoS attack, e.g., by generating a "storm" of IOMMU faults that will
> livelock a pCPU.
> 
> To avoid this, IOMMU faults handling is being moved from interrupt to
> softirq context. Basically, the inerrupt handler of the IRQ originated
> by an IOMMU (page) fault will raise a softirq-tasklet which will then
> deal with the actual fault records by clearing the logs and re-enabling
> interrupts from the offending IOMMU(s). A single tasklet is being used
> even if there are more than just one IOMMU in the system, as the event
> should be rare enough.
> 
> The series introduces the described mechanism for both Intel VT-d and
> AMD-Vi, and has been tested on both platforms with an hacked DomU bnx2
> network driver which was generating I/O page faults upon request.

These look good to me (apart from a minor indentation issue in the
2nd patch), but we'd surely like to have an ack from the respective
maintainers. Also, despite the subject here, I suppose the series
consists of just two patches?

Thanks for doing this!

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 20 09:38:04 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 Dec 2011 09:38:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rcw8a-00087L-O3; Tue, 20 Dec 2011 09:37:32 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rcw8Z-000872-5y
	for xen-devel@lists.xensource.com; Tue, 20 Dec 2011 09:37:31 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1324373844!6231739!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzQwMQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21282 invoked from network); 20 Dec 2011 09:37:24 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Dec 2011 09:37:24 -0000
X-IronPort-AV: E=Sophos;i="4.71,381,1320624000"; 
   d="scan'208";a="9571993"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Dec 2011 09:37:23 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 20 Dec 2011 09:37:22 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
Date: Tue, 20 Dec 2011 09:37:22 +0000
In-Reply-To: <20111219194324.GA29852@andromeda.dapyr.net>
References: <CAOMqctShNFqe47w1orEPMCqvDORy5yxh=Gy33e02fyQYrz4nkw@mail.gmail.com>
	<20111219142943.GD27772@andromeda.dapyr.net>
	<CAOMqctSW87AmM8UTC34_ZwDhipnZUMmxyxiBix+EMAmi7hn1hg@mail.gmail.com>
	<20111219194324.GA29852@andromeda.dapyr.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1324373842.23729.16.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Michal Suchanek <hramrach@centrum.cz>
Subject: Re: [Xen-devel] UDP checksums broken in Dom0 -> DomU vif transfer
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2011-12-19 at 19:43 +0000, Konrad Rzeszutek Wilk wrote:
> On Mon, Dec 19, 2011 at 04:20:17PM +0100, Michal Suchanek wrote:
> > On 19 December 2011 15:29, Konrad Rzeszutek Wilk <konrad@darnok.org> wrote:
> > > On Mon, Dec 19, 2011 at 10:27:36AM +0100, Michal Suchanek wrote:
> > >> Hello,
> > >>
> > >> when I boot DomU which uses DHCP to configure IPv4 address it does
> > >
> > > You didn't say what version of DomU you are running? Is it 3.1?
> > 
> > I have this problem in 2.6.32 and 3.1 kernels.
> 
> Ok. Lets concentrate on 3.1 then.
> > 
> > >> never get a lease.
> > >>
> > >> The packets travel to Dom0 where the dhcp server receives them, sends
> > >> a reply, that travels to DomU where dhclient receives it, says the
> > >> checksum is invalid, and discards it.
> > >>
> > >> The problem is documented here:
> > >>
> > >> http://old-list-archives.xen.org/archives/html/xen-users/2006-02/msg00152.html
> > >> http://old-list-archives.xen.org/archives/html/xen-devel/2011-04/msg01235.html
> > >> http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1655
> > >>
> > >> The fix is to turn off UDP checksum offloading on the vif interface in
> > >> Dom0 as documented in the above mail:
> > >>
> > >> I edited /etc/xen/scripts/network-bridge,
> > >> adding this command to the end of the op_start() function:
> > >>
> > >> ?? ?? ?? ?? add_to_bridge2 ${bridge} ${pdev}
> > >> ?? ?? ?? ?? do_ifup ${netdev}
> > >> + ?? ?? ?? # disable ip checksum offloading for veth device
> > >> + ?? ?? ?? ethtool -K ${netdev} tx off
> > >> ?? ?? else
> > >> ?? ?? ?? ?? # old style without ${vdev}
> > >>
> > >> Note: I am not sure which path is taken through the script, I set the
> > >> parameter manually with ethtool before I found this patch.
> > >>
> > >> It some solutions suggest to turn off UDP checksum offloading in the
> > >> DomU as well but it does not seem to be necessary since the packets
> > >> would travel to the dhcp server and it would reply to them.
> > >>
> > >> Some people say this is working for them.
> > >>
> > >> I suspect this is because some Linux distributions already carry this patch.
> > >>
> > >> Any reason why this can't be fixed in Xen upstream?
> > >
> > > It should be fixed in the kernel and I think it is fixed. Did you have
> > > this problem with a 3.1 or 3.0 kernel?
> > 
> > Apparently it is not fixed.
> > 
> > Do you have hash of the Linux upstream commit that fixes it?
> 
> Ah, my appoligies - we do not have the fix, albeit I thought I saw the
> fix some point. Ian might know since he is the maintainer of
> xen-netback.

The issue is that dom0 does checksum offload which means the checksum is
not valid on the domU end, although we know the packet is intact because
it never hit the wire.

The network stack deals with this because skb->ip_summed is set
appropriately but when e.g. raw sockets are used it can ends up exposing
getting exposed to userspace.

We don't want to do the checksum by default since there are performance
gains from avoiding it in the general case. Note that "tx off" turns of
TCP and UDP checksum offload.

It's not clear where the bug is here, it could be a bug in dhclinet for
dropping the packet or perhaps this is something that raw socket driver
should be correcting (based on ip_summed) as the packet passes through
to userspace?

I'm not sure but this might impact native hardware too -- depends on the
H/W's handling of the checksum field on RX, you'd hope they mostly just
leave it alone, but I'm not sure how e.g. LRO/GRO effects things?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 20 09:38:04 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 Dec 2011 09:38:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rcw8a-00087L-O3; Tue, 20 Dec 2011 09:37:32 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rcw8Z-000872-5y
	for xen-devel@lists.xensource.com; Tue, 20 Dec 2011 09:37:31 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1324373844!6231739!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzQwMQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21282 invoked from network); 20 Dec 2011 09:37:24 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Dec 2011 09:37:24 -0000
X-IronPort-AV: E=Sophos;i="4.71,381,1320624000"; 
   d="scan'208";a="9571993"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Dec 2011 09:37:23 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 20 Dec 2011 09:37:22 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
Date: Tue, 20 Dec 2011 09:37:22 +0000
In-Reply-To: <20111219194324.GA29852@andromeda.dapyr.net>
References: <CAOMqctShNFqe47w1orEPMCqvDORy5yxh=Gy33e02fyQYrz4nkw@mail.gmail.com>
	<20111219142943.GD27772@andromeda.dapyr.net>
	<CAOMqctSW87AmM8UTC34_ZwDhipnZUMmxyxiBix+EMAmi7hn1hg@mail.gmail.com>
	<20111219194324.GA29852@andromeda.dapyr.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1324373842.23729.16.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Michal Suchanek <hramrach@centrum.cz>
Subject: Re: [Xen-devel] UDP checksums broken in Dom0 -> DomU vif transfer
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2011-12-19 at 19:43 +0000, Konrad Rzeszutek Wilk wrote:
> On Mon, Dec 19, 2011 at 04:20:17PM +0100, Michal Suchanek wrote:
> > On 19 December 2011 15:29, Konrad Rzeszutek Wilk <konrad@darnok.org> wrote:
> > > On Mon, Dec 19, 2011 at 10:27:36AM +0100, Michal Suchanek wrote:
> > >> Hello,
> > >>
> > >> when I boot DomU which uses DHCP to configure IPv4 address it does
> > >
> > > You didn't say what version of DomU you are running? Is it 3.1?
> > 
> > I have this problem in 2.6.32 and 3.1 kernels.
> 
> Ok. Lets concentrate on 3.1 then.
> > 
> > >> never get a lease.
> > >>
> > >> The packets travel to Dom0 where the dhcp server receives them, sends
> > >> a reply, that travels to DomU where dhclient receives it, says the
> > >> checksum is invalid, and discards it.
> > >>
> > >> The problem is documented here:
> > >>
> > >> http://old-list-archives.xen.org/archives/html/xen-users/2006-02/msg00152.html
> > >> http://old-list-archives.xen.org/archives/html/xen-devel/2011-04/msg01235.html
> > >> http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1655
> > >>
> > >> The fix is to turn off UDP checksum offloading on the vif interface in
> > >> Dom0 as documented in the above mail:
> > >>
> > >> I edited /etc/xen/scripts/network-bridge,
> > >> adding this command to the end of the op_start() function:
> > >>
> > >> ?? ?? ?? ?? add_to_bridge2 ${bridge} ${pdev}
> > >> ?? ?? ?? ?? do_ifup ${netdev}
> > >> + ?? ?? ?? # disable ip checksum offloading for veth device
> > >> + ?? ?? ?? ethtool -K ${netdev} tx off
> > >> ?? ?? else
> > >> ?? ?? ?? ?? # old style without ${vdev}
> > >>
> > >> Note: I am not sure which path is taken through the script, I set the
> > >> parameter manually with ethtool before I found this patch.
> > >>
> > >> It some solutions suggest to turn off UDP checksum offloading in the
> > >> DomU as well but it does not seem to be necessary since the packets
> > >> would travel to the dhcp server and it would reply to them.
> > >>
> > >> Some people say this is working for them.
> > >>
> > >> I suspect this is because some Linux distributions already carry this patch.
> > >>
> > >> Any reason why this can't be fixed in Xen upstream?
> > >
> > > It should be fixed in the kernel and I think it is fixed. Did you have
> > > this problem with a 3.1 or 3.0 kernel?
> > 
> > Apparently it is not fixed.
> > 
> > Do you have hash of the Linux upstream commit that fixes it?
> 
> Ah, my appoligies - we do not have the fix, albeit I thought I saw the
> fix some point. Ian might know since he is the maintainer of
> xen-netback.

The issue is that dom0 does checksum offload which means the checksum is
not valid on the domU end, although we know the packet is intact because
it never hit the wire.

The network stack deals with this because skb->ip_summed is set
appropriately but when e.g. raw sockets are used it can ends up exposing
getting exposed to userspace.

We don't want to do the checksum by default since there are performance
gains from avoiding it in the general case. Note that "tx off" turns of
TCP and UDP checksum offload.

It's not clear where the bug is here, it could be a bug in dhclinet for
dropping the packet or perhaps this is something that raw socket driver
should be correcting (based on ip_summed) as the packet passes through
to userspace?

I'm not sure but this might impact native hardware too -- depends on the
H/W's handling of the checksum field on RX, you'd hope they mostly just
leave it alone, but I'm not sure how e.g. LRO/GRO effects things?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 20 09:44:21 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 Dec 2011 09:44:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RcwEk-0008Lv-J7; Tue, 20 Dec 2011 09:43:54 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jean.guyader@gmail.com>) id 1RcwEj-0008Li-PS
	for xen-devel@lists.xensource.com; Tue, 20 Dec 2011 09:43:54 +0000
X-Env-Sender: jean.guyader@gmail.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1324374225!6181723!1
X-Originating-IP: [209.85.220.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7511 invoked from network); 20 Dec 2011 09:43:46 -0000
Received: from mail-vx0-f171.google.com (HELO mail-vx0-f171.google.com)
	(209.85.220.171)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Dec 2011 09:43:46 -0000
Received: by vcbfl11 with SMTP id fl11so19108128vcb.30
	for <xen-devel@lists.xensource.com>;
	Tue, 20 Dec 2011 01:43:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type;
	bh=+LibUh6zYDh/dpF38r5SSn3GKPL9n5CiEthIfcG+f0A=;
	b=X8FvddT6kokM4Zl4OZDAO4Uj411LOAY7AZizrEFodYWpW0hrXFb+pigMeFJTlSL6j3
	sTZdEizDYktVFrJ/KDTPzpXooXT/VOa3Ol//s2gPzwJpzQvl3TOYDu2pObUVoDRQmJvQ
	LBd5lZnOH1z1yPPNJXdJBx2qNKW2RtPAUYaGY=
Received: by 10.220.39.9 with SMTP id d9mr809864vce.10.1324374225192; Tue, 20
	Dec 2011 01:43:45 -0800 (PST)
MIME-Version: 1.0
Received: by 10.220.156.138 with HTTP; Tue, 20 Dec 2011 01:43:24 -0800 (PST)
In-Reply-To: <1324373842.23729.16.camel@zakaz.uk.xensource.com>
References: <CAOMqctShNFqe47w1orEPMCqvDORy5yxh=Gy33e02fyQYrz4nkw@mail.gmail.com>
	<20111219142943.GD27772@andromeda.dapyr.net>
	<CAOMqctSW87AmM8UTC34_ZwDhipnZUMmxyxiBix+EMAmi7hn1hg@mail.gmail.com>
	<20111219194324.GA29852@andromeda.dapyr.net>
	<1324373842.23729.16.camel@zakaz.uk.xensource.com>
From: Jean Guyader <jean.guyader@gmail.com>
Date: Tue, 20 Dec 2011 10:43:24 +0100
Message-ID: <CAEBdQ92Oy6=EYYFG_KNMP6raq7S1e_195hFth1etMgpQWdGtsg@mail.gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Michal Suchanek <hramrach@centrum.cz>
Subject: Re: [Xen-devel] UDP checksums broken in Dom0 -> DomU vif transfer
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 20 December 2011 10:37, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Mon, 2011-12-19 at 19:43 +0000, Konrad Rzeszutek Wilk wrote:
>> On Mon, Dec 19, 2011 at 04:20:17PM +0100, Michal Suchanek wrote:
>> > On 19 December 2011 15:29, Konrad Rzeszutek Wilk <konrad@darnok.org> wrote:
>> > > On Mon, Dec 19, 2011 at 10:27:36AM +0100, Michal Suchanek wrote:
>> > >> Hello,
>> > >>
>> > >> when I boot DomU which uses DHCP to configure IPv4 address it does
>> > >
>> > > You didn't say what version of DomU you are running? Is it 3.1?
>> >
>> > I have this problem in 2.6.32 and 3.1 kernels.
>>
>> Ok. Lets concentrate on 3.1 then.
>> >
>> > >> never get a lease.
>> > >>
>> > >> The packets travel to Dom0 where the dhcp server receives them, sends
>> > >> a reply, that travels to DomU where dhclient receives it, says the
>> > >> checksum is invalid, and discards it.
>> > >>
>> > >> The problem is documented here:
>> > >>
>> > >> http://old-list-archives.xen.org/archives/html/xen-users/2006-02/msg00152.html
>> > >> http://old-list-archives.xen.org/archives/html/xen-devel/2011-04/msg01235.html
>> > >> http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1655
>> > >>
>> > >> The fix is to turn off UDP checksum offloading on the vif interface in
>> > >> Dom0 as documented in the above mail:
>> > >>
>> > >> I edited /etc/xen/scripts/network-bridge,
>> > >> adding this command to the end of the op_start() function:
>> > >>
>> > >> ?? ?? ?? ?? add_to_bridge2 ${bridge} ${pdev}
>> > >> ?? ?? ?? ?? do_ifup ${netdev}
>> > >> + ?? ?? ?? # disable ip checksum offloading for veth device
>> > >> + ?? ?? ?? ethtool -K ${netdev} tx off
>> > >> ?? ?? else
>> > >> ?? ?? ?? ?? # old style without ${vdev}
>> > >>
>> > >> Note: I am not sure which path is taken through the script, I set the
>> > >> parameter manually with ethtool before I found this patch.
>> > >>
>> > >> It some solutions suggest to turn off UDP checksum offloading in the
>> > >> DomU as well but it does not seem to be necessary since the packets
>> > >> would travel to the dhcp server and it would reply to them.
>> > >>
>> > >> Some people say this is working for them.
>> > >>
>> > >> I suspect this is because some Linux distributions already carry this patch.
>> > >>
>> > >> Any reason why this can't be fixed in Xen upstream?
>> > >
>> > > It should be fixed in the kernel and I think it is fixed. Did you have
>> > > this problem with a 3.1 or 3.0 kernel?
>> >
>> > Apparently it is not fixed.
>> >
>> > Do you have hash of the Linux upstream commit that fixes it?
>>
>> Ah, my appoligies - we do not have the fix, albeit I thought I saw the
>> fix some point. Ian might know since he is the maintainer of
>> xen-netback.
>
> The issue is that dom0 does checksum offload which means the checksum is
> not valid on the domU end, although we know the packet is intact because
> it never hit the wire.
>
> The network stack deals with this because skb->ip_summed is set
> appropriately but when e.g. raw sockets are used it can ends up exposing
> getting exposed to userspace.
>
> We don't want to do the checksum by default since there are performance
> gains from avoiding it in the general case. Note that "tx off" turns of
> TCP and UDP checksum offload.
>
> It's not clear where the bug is here, it could be a bug in dhclinet for
> dropping the packet or perhaps this is something that raw socket driver
> should be correcting (based on ip_summed) as the packet passes through
> to userspace?
>
> I'm not sure but this might impact native hardware too -- depends on the
> H/W's handling of the checksum field on RX, you'd hope they mostly just
> leave it alone, but I'm not sure how e.g. LRO/GRO effects things?
>

I've seen this issue in the past. I belive the bug is in dhclient.
dhclient checks the checksum on the packets and drop them if it's wrong.

Jean

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 20 09:44:21 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 Dec 2011 09:44:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RcwEk-0008Lv-J7; Tue, 20 Dec 2011 09:43:54 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jean.guyader@gmail.com>) id 1RcwEj-0008Li-PS
	for xen-devel@lists.xensource.com; Tue, 20 Dec 2011 09:43:54 +0000
X-Env-Sender: jean.guyader@gmail.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1324374225!6181723!1
X-Originating-IP: [209.85.220.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7511 invoked from network); 20 Dec 2011 09:43:46 -0000
Received: from mail-vx0-f171.google.com (HELO mail-vx0-f171.google.com)
	(209.85.220.171)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Dec 2011 09:43:46 -0000
Received: by vcbfl11 with SMTP id fl11so19108128vcb.30
	for <xen-devel@lists.xensource.com>;
	Tue, 20 Dec 2011 01:43:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type;
	bh=+LibUh6zYDh/dpF38r5SSn3GKPL9n5CiEthIfcG+f0A=;
	b=X8FvddT6kokM4Zl4OZDAO4Uj411LOAY7AZizrEFodYWpW0hrXFb+pigMeFJTlSL6j3
	sTZdEizDYktVFrJ/KDTPzpXooXT/VOa3Ol//s2gPzwJpzQvl3TOYDu2pObUVoDRQmJvQ
	LBd5lZnOH1z1yPPNJXdJBx2qNKW2RtPAUYaGY=
Received: by 10.220.39.9 with SMTP id d9mr809864vce.10.1324374225192; Tue, 20
	Dec 2011 01:43:45 -0800 (PST)
MIME-Version: 1.0
Received: by 10.220.156.138 with HTTP; Tue, 20 Dec 2011 01:43:24 -0800 (PST)
In-Reply-To: <1324373842.23729.16.camel@zakaz.uk.xensource.com>
References: <CAOMqctShNFqe47w1orEPMCqvDORy5yxh=Gy33e02fyQYrz4nkw@mail.gmail.com>
	<20111219142943.GD27772@andromeda.dapyr.net>
	<CAOMqctSW87AmM8UTC34_ZwDhipnZUMmxyxiBix+EMAmi7hn1hg@mail.gmail.com>
	<20111219194324.GA29852@andromeda.dapyr.net>
	<1324373842.23729.16.camel@zakaz.uk.xensource.com>
From: Jean Guyader <jean.guyader@gmail.com>
Date: Tue, 20 Dec 2011 10:43:24 +0100
Message-ID: <CAEBdQ92Oy6=EYYFG_KNMP6raq7S1e_195hFth1etMgpQWdGtsg@mail.gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Michal Suchanek <hramrach@centrum.cz>
Subject: Re: [Xen-devel] UDP checksums broken in Dom0 -> DomU vif transfer
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 20 December 2011 10:37, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Mon, 2011-12-19 at 19:43 +0000, Konrad Rzeszutek Wilk wrote:
>> On Mon, Dec 19, 2011 at 04:20:17PM +0100, Michal Suchanek wrote:
>> > On 19 December 2011 15:29, Konrad Rzeszutek Wilk <konrad@darnok.org> wrote:
>> > > On Mon, Dec 19, 2011 at 10:27:36AM +0100, Michal Suchanek wrote:
>> > >> Hello,
>> > >>
>> > >> when I boot DomU which uses DHCP to configure IPv4 address it does
>> > >
>> > > You didn't say what version of DomU you are running? Is it 3.1?
>> >
>> > I have this problem in 2.6.32 and 3.1 kernels.
>>
>> Ok. Lets concentrate on 3.1 then.
>> >
>> > >> never get a lease.
>> > >>
>> > >> The packets travel to Dom0 where the dhcp server receives them, sends
>> > >> a reply, that travels to DomU where dhclient receives it, says the
>> > >> checksum is invalid, and discards it.
>> > >>
>> > >> The problem is documented here:
>> > >>
>> > >> http://old-list-archives.xen.org/archives/html/xen-users/2006-02/msg00152.html
>> > >> http://old-list-archives.xen.org/archives/html/xen-devel/2011-04/msg01235.html
>> > >> http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1655
>> > >>
>> > >> The fix is to turn off UDP checksum offloading on the vif interface in
>> > >> Dom0 as documented in the above mail:
>> > >>
>> > >> I edited /etc/xen/scripts/network-bridge,
>> > >> adding this command to the end of the op_start() function:
>> > >>
>> > >> ?? ?? ?? ?? add_to_bridge2 ${bridge} ${pdev}
>> > >> ?? ?? ?? ?? do_ifup ${netdev}
>> > >> + ?? ?? ?? # disable ip checksum offloading for veth device
>> > >> + ?? ?? ?? ethtool -K ${netdev} tx off
>> > >> ?? ?? else
>> > >> ?? ?? ?? ?? # old style without ${vdev}
>> > >>
>> > >> Note: I am not sure which path is taken through the script, I set the
>> > >> parameter manually with ethtool before I found this patch.
>> > >>
>> > >> It some solutions suggest to turn off UDP checksum offloading in the
>> > >> DomU as well but it does not seem to be necessary since the packets
>> > >> would travel to the dhcp server and it would reply to them.
>> > >>
>> > >> Some people say this is working for them.
>> > >>
>> > >> I suspect this is because some Linux distributions already carry this patch.
>> > >>
>> > >> Any reason why this can't be fixed in Xen upstream?
>> > >
>> > > It should be fixed in the kernel and I think it is fixed. Did you have
>> > > this problem with a 3.1 or 3.0 kernel?
>> >
>> > Apparently it is not fixed.
>> >
>> > Do you have hash of the Linux upstream commit that fixes it?
>>
>> Ah, my appoligies - we do not have the fix, albeit I thought I saw the
>> fix some point. Ian might know since he is the maintainer of
>> xen-netback.
>
> The issue is that dom0 does checksum offload which means the checksum is
> not valid on the domU end, although we know the packet is intact because
> it never hit the wire.
>
> The network stack deals with this because skb->ip_summed is set
> appropriately but when e.g. raw sockets are used it can ends up exposing
> getting exposed to userspace.
>
> We don't want to do the checksum by default since there are performance
> gains from avoiding it in the general case. Note that "tx off" turns of
> TCP and UDP checksum offload.
>
> It's not clear where the bug is here, it could be a bug in dhclinet for
> dropping the packet or perhaps this is something that raw socket driver
> should be correcting (based on ip_summed) as the packet passes through
> to userspace?
>
> I'm not sure but this might impact native hardware too -- depends on the
> H/W's handling of the checksum field on RX, you'd hope they mostly just
> leave it alone, but I'm not sure how e.g. LRO/GRO effects things?
>

I've seen this issue in the past. I belive the bug is in dhclient.
dhclient checks the checksum on the packets and drop them if it's wrong.

Jean

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 20 09:46:50 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 Dec 2011 09: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.xensource.com>)
	id 1RcwHF-0008Rq-5l; Tue, 20 Dec 2011 09:46:29 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <hui.lv@intel.com>) id 1RcwHD-0008Ra-IH
	for xen-devel@lists.xensource.com; Tue, 20 Dec 2011 09:46:28 +0000
X-Env-Sender: hui.lv@intel.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1324374379!6234443!1
X-Originating-IP: [134.134.136.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjQgPT4gMzE4MDY5\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12667 invoked from network); 20 Dec 2011 09:46:20 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-7.tower-174.messagelabs.com with SMTP;
	20 Dec 2011 09:46:20 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga102.jf.intel.com with ESMTP; 20 Dec 2011 01:45:15 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.67,352,1309762800"; 
	d="xml'?rels'?scan'72,48,208?xlsx'72,48,208,72,48";a="88425283"
Received: from pgsmsx602.gar.corp.intel.com ([10.221.43.81])
	by orsmga001.jf.intel.com with ESMTP; 20 Dec 2011 01:45:04 -0800
Received: from pgsmsx104.gar.corp.intel.com (10.221.44.91) by
	pgsmsx602.gar.corp.intel.com (10.221.43.81) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Tue, 20 Dec 2011 17:44:11 +0800
Received: from shsmsx601.ccr.corp.intel.com (10.239.4.112) by
	PGSMSX104.gar.corp.intel.com (10.221.44.91) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Tue, 20 Dec 2011 17:44:10 +0800
Received: from shsmsx502.ccr.corp.intel.com ([10.239.4.96]) by
	shsmsx601.ccr.corp.intel.com ([10.239.4.112]) with mapi;
	Tue, 20 Dec 2011 17:44:10 +0800
From: "Lv, Hui" <hui.lv@intel.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Tue, 20 Dec 2011 17:44:09 +0800
Thread-Topic: [Xen-devel] [PATCH] xen/sched_credit: Use delay to control
	scheduling frequency
Thread-Index: Acy+9uNlaSLozX1SSw2LWaCKLABrWAAAWByA
Message-ID: <C10D3FB0CD45994C8A51FEC1227CE22F39412A99CE@shsmsx502.ccr.corp.intel.com>
References: <114495d1ff947737518b.1324332781@wsm-ep-n0>
	<1324372056.23729.8.camel@zakaz.uk.xensource.com>
In-Reply-To: <1324372056.23729.8.camel@zakaz.uk.xensource.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/mixed;
	boundary="_002_C10D3FB0CD45994C8A51FEC1227CE22F39412A99CEshsmsx502ccrc_"
MIME-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] xen/sched_credit: Use delay to control
 scheduling frequency
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--_002_C10D3FB0CD45994C8A51FEC1227CE22F39412A99CEshsmsx502ccrc_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

DQo+IElzIGl0IHBvc3NpYmxlIHRvIHB1Ymxpc2ggdGhlIHJhdyBudW1iZXJzPw0KWWVzLiANCkFj
dHVhbGx5LCBJIGhhdmUgcG9zdGVkIHRoZSByYXcgZGF0YSBiZWZvcmUuIA0KWW91IGNhbiBjaGVj
ayB0aGUgYXR0YWNobWVudCBmb3IgdGhlIGRldGFpbHMuDQoNCj4gSWYgdGhpcyBpcyBnZW5lcmlj
IHRoZW4gaXQgc2VlbXMgbGlrZSB4ZW4vc2NoZWQuaCBpcyB0aGUgcmlnaHQgcGxhY2UgZm9yIGl0
Lg0KPiANCj4gSXMgaXQgcmVhbGx5IGdlbmVyaWMgdGhvdWdoIGlmIG9ubHkgdGhlIGNyZWRpdCBz
Y2hlZHVsZXIgYXBwbGllcyBpdD8NCg0KV2UgaGF2ZSBkaXNjdXNzZWQgdGhlICJnZW5lcmljIiBp
c3N1ZSBpbiBwcmV2aW91cyBtYWlscyB3aXRoIEdlb3JnZSwgRGFyaW8gRmFnZ2lvbGkgYW5kIHNv
bWUgb3RoZXIgcGVvcGxlLg0KVGhlIGNvbmNsdXNpb24gaXMgdGhhdCBjdXJyZW50bHksIGl0IGlz
IGFwcGxpZWQgdG8gY3JlZGl0IHNjaGVkdWxlci4gSW4gZnV0dXJlLCBpdCBtYXkgYmUgZGV2ZWxv
cGVkIGludG8gYSBnZW5lcmljIHNvbHV0aW9uLg0KDQo+IFRoaXMgaXMgdGhlIHNhbWUgY29tbWVu
dCBhcyB0aGUgbmV4dCBibG9jayBiZWxvdywgZG9lcyBpdCByZWFsbHkgYXBwbHkgaGVyZQ0KPiB0
b28/DQo+IA0KPiBTaW5jZSB0aGUgcHJldmlvdXMgaWYgYmxvY2sgZW5kcyB3aXRoIGEgZ290byB0
aGUgZWxzZSBjbGF1c2UgaXMgYSBiaXQgcmVkdW5kYW50Lg0KDQpUaGFua3MsIEknbGwgcmVtb3Zl
IHRoZSByZWR1bmRhbnQgY29tbWVudCBhbmQgZWxzZSBjbGF1c2UuDQoNCj4gSXQgdGhhdCBjb25z
dHJhaW50IGVuZm9yY2VkIGFueXdoZXJlPw0KDQpDdXJyZW50bHksIGl0J3Mgbm90IGNvbnN0cmFp
bnQgZW5mb3JjZWQuIA0KSSB0aGluayBHZW9yZ2UgaGF2ZSBnYXZlIHRoZSBleHBsYW5hdGlvbiBp
biB5ZXN0ZXJkYXkncyBkaXNjdXNzaW9uLg0KDQoNCkJlc3QgcmVnYXJkcywNCg0KTHYsIEh1aQ0K
DQoNCg0K

--_002_C10D3FB0CD45994C8A51FEC1227CE22F39412A99CEshsmsx502ccrc_
Content-Type: application/vnd.openxmlformats-officedocument.spreadsheetml.sheet;
	name="scheduler comparison.xlsx"
Content-Description: scheduler comparison.xlsx
Content-Disposition: attachment; filename="scheduler comparison.xlsx";
	size=12105; creation-date="Sun, 11 Dec 2011 23:19:48 GMT";
	modification-date="Sun, 11 Dec 2011 23:19:48 GMT"
Content-Transfer-Encoding: base64

UEsDBBQABgAIAAAAIQB8bJgWbAEAAKAFAAATAAgCW0NvbnRlbnRfVHlwZXNdLnhtbCCiBAIooAAC
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADM
lF1LwzAUhu8F/0PJrTTZJojIul34cakD5w+IzekaliYhJ5vbv/c0+0CkbgwHetPQ5pz3fZI073C8
aky2hIDa2YL1eY9lYEuntJ0V7G36lN+yDKO0ShpnoWBrQDYeXV4Mp2sPmFG3xYLVMfo7IbCsoZHI
nQdLM5ULjYz0GmbCy3IuZyAGvd6NKJ2NYGMeWw02Gj5AJRcmZo8r+rwhCWCQZfebwtarYNJ7o0sZ
iVQsrfrmkm8dOHWmGqy1xyvCYKLToZ352WDb90JbE7SCbCJDfJYNYYiVER8uzN+dm/PDIh2Urqp0
CcqVi4Z2gKMPIBXWALExPI28kdruuA/4p2IUaeifGaRdXxI+kWPwTziu/4gj0v8PIj1/fyRJ5sgB
YFwbwDOvdiN6zLmWAdRrDJQUZwf4qn2Ig+7RJDiPlCgBTt+FXWS03bknIQhRwz40ui7f3pHS6HTD
b7cf2rxToDq8RcrX0ScAAAD//wMAUEsDBBQABgAIAAAAIQC1VTAj9QAAAEwCAAALAAgCX3JlbHMv
LnJlbHMgogQCKKAAAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAjJLPTsMwDMbvSLxD5PvqbkgIoaW7TEi7IVQewCTuH7WNoyRA9/aEA4JKY9vR
9ufPP1ve7uZpVB8cYi9Ow7ooQbEzYnvXanitn1YPoGIiZ2kUxxqOHGFX3d5sX3iklJti1/uosouL
GrqU/CNiNB1PFAvx7HKlkTBRymFo0ZMZqGXclOU9hr8eUC081cFqCAd7B6o++jz5src0TW94L+Z9
YpdOjECeEzvLduVDZgupz9uomkLLSYMV85zTEcn7ImMDnibaXE/0/7Y4cSJLidBI4PM834pzQOvr
gS6faKn4vc484qeE4U1k+GHBxQ9UXwAAAP//AwBQSwMEFAAGAAgAAAAhAN4J/SgCAQAA1AMAABoA
CAF4bC9fcmVscy93b3JrYm9vay54bWwucmVscyCiBAEooAABAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAALyTz2rDMAzG74O9g9F9cZJuZZQ6vYxBr1v3ACZR4tDENpb2J28/k0O6QMkuoReDJPx9
P9Cn/eGn78QXBmqdVZAlKQi0pata2yj4OL0+PIMg1rbSnbOoYECCQ3F/t3/DTnP8RKb1JKKKJQWG
2e+kpNJgrylxHm2c1C70mmMZGul1edYNyjxNtzL81YBipimOlYJwrDYgToOPzv9ru7puS3xx5WeP
lq9YyG8XzmQQOYrq0CArmFokx8kmicQgr8PkN4bJl2CyG8NkSzDbNWHI6IDVO4eYQrqsatZegnla
FYaHLoZ+CgyN9ZL945r2HE8JL+5jKcd32oec3WLxCwAA//8DAFBLAwQUAAYACAAAACEAMDLFhWIB
AABxAgAADwAAAHhsL3dvcmtib29rLnhtbIxSy27CMBC8V+o/WL6XJA6kFJEgVW1VLlWlUji78YZY
OHZkOw38fTdGPCQuPe2udzKeGWe+2DeK/IJ10uicJqOYEtClEVJvc/q9enuYUuI814IroyGnB3B0
UdzfzXtjdz/G7AgSaJfT2vt2FkWurKHhbmRa0LipjG24x9FuI9da4MLVAL5REYvjLGq41PTIMLP/
4TBVJUt4MWXXgPZHEguKe5Tvatk6WswrqWB9dER4237wBnXvFSWKO/8qpAeR0wmOpofLwZgS27XP
nVS4fUpjRqPibPLTEgEV75Rfob0TO+bFxoxlA3KIYi2hd5ePhpHsN1IL0+c0zTDaw2lKUhTQh9VG
Cl8j1SO7nL2D3NY+p1M2jQf26Io+BIjXhEp0cPc1hJrgSw11iQawtzOJjV2KZGC4QbMrNPZndPB9
g06v0Nif0WlQF+AoqeSqxKiGEkSMJxkLt0env6X4AwAA//8DAFBLAwQUAAYACAAAACEA+2KlbZQG
AACnGwAAEwAAAHhsL3RoZW1lL3RoZW1lMS54bWzsWU9v2zYUvw/YdyB0b20nthsHdYrYsZutTRvE
boceaZmWWFOiQNJJfRva44ABw7phlwG77TBsK9ACu3SfJluHrQP6FfZISrIYy0vSBhvW1YdEIn98
/9/jI3X12oOIoUMiJOVx26tdrnqIxD4f0zhoe3eG/UsbHpIKx2PMeEza3pxI79rW++9dxZsqJBFB
sD6Wm7jthUolm5WK9GEYy8s8ITHMTbiIsIJXEVTGAh8B3YhV1qrVZiXCNPZQjCMge3syoT5BQ03S
28qI9xi8xkrqAZ+JgSZNnBUGO57WNELOZZcJdIhZ2wM+Y340JA+UhxiWCibaXtX8vMrW1QreTBcx
tWJtYV3f/NJ16YLxdM3wFMEoZ1rr11tXdnL6BsDUMq7X63V7tZyeAWDfB02tLEWa9f5GrZPRLIDs
4zLtbrVRrbv4Av31JZlbnU6n0UplsUQNyD7Wl/Ab1WZ9e83BG5DFN5bw9c52t9t08AZk8c0lfP9K
q1l38QYUMhpPl9Daof1+Sj2HTDjbLYVvAHyjmsIXKIiGPLo0iwmP1apYi/B9LvoA0ECGFY2Rmidk
gn2I4i6ORoJizQBvElyYsUO+XBrSvJD0BU1U2/swwZARC3qvnn//6vlT9Or5k+OHz44f/nT86NHx
wx8tLWfhLo6D4sKX337259cfoz+efvPy8RfleFnE//rDJ7/8/Hk5EDJoIdGLL5/89uzJi68+/f27
xyXwbYFHRfiQRkSiW+QIHfAIdDOGcSUnI3G+FcMQU2cFDoF2CemeCh3grTlmZbgOcY13V0DxKANe
n913ZB2EYqZoCecbYeQA9zhnHS5KDXBD8ypYeDiLg3LmYlbEHWB8WMa7i2PHtb1ZAlUzC0rH9t2Q
OGLuMxwrHJCYKKTn+JSQEu3uUerYdY/6gks+UegeRR1MS00ypCMnkBaLdmkEfpmX6Qyudmyzdxd1
OCvTeoccukhICMxKhB8S5pjxOp4pHJWRHOKIFQ1+E6uwTMjBXPhFXE8q8HRAGEe9MZGybM1tAfoW
nH4DQ70qdfsem0cuUig6LaN5E3NeRO7waTfEUVKGHdA4LGI/kFMIUYz2uSqD73E3Q/Q7+AHHK919
lxLH3acXgjs0cERaBIiemYkSX14n3InfwZxNMDFVBkq6U6kjGv9d2WYU6rbl8K5st71t2MTKkmf3
RLFehfsPlugdPIv3CWTF8hb1rkK/q9DeW1+hV+XyxdflRSmGKq0bEttrm847Wtl4TyhjAzVn5KY0
vbeEDWjch0G9zhw6SX4QS0J41JkMDBxcILBZgwRXH1EVDkKcQN9e8zSRQKakA4kSLuG8aIZLaWs8
9P7KnjYb+hxiK4fEao+P7fC6Hs6OGzkZI1VgzrQZo3VN4KzM1q+kREG312FW00KdmVvNiGaKosMt
V1mb2JzLweS5ajCYWxM6GwT9EFi5Ccd+zRrOO5iRsba79VHmFuOFi3SRDPGYpD7Sei/7qGaclMXK
kiJaDxsM+ux4itUK3Fqa7BtwO4uTiuzqK9hl3nsTL2URvPASUDuZjiwuJieL0VHbazXWGh7ycdL2
JnBUhscoAa9L3UxiFsB9k6+EDftTk9lk+cKbrUwxNwlqcPth7b6ksFMHEiHVDpahDQ0zlYYAizUn
K/9aA8x6UQqUVKOzSbG+AcHwr0kBdnRdSyYT4quiswsj2nb2NS2lfKaIGITjIzRiM3GAwf06VEGf
MZVw42Eqgn6B6zltbTPlFuc06YqXYgZnxzFLQpyWW52iWSZbuClIuQzmrSAe6FYqu1Hu/KqYlL8g
VYph/D9TRe8ncAWxPtYe8OF2WGCkM6XtcaFCDlUoCanfF9A4mNoB0QJXvDANQQV31Oa/IIf6v805
S8OkNZwk1QENkKCwH6lQELIPZclE3ynEauneZUmylJCJqIK4MrFij8ghYUNdA5t6b/dQCKFuqkla
BgzuZPy572kGjQLd5BTzzalk+d5rc+Cf7nxsMoNSbh02DU1m/1zEvD1Y7Kp2vVme7b1FRfTEos2q
Z1kBzApbQStN+9cU4Zxbra1YSxqvNTLhwIvLGsNg3hAlcJGE9B/Y/6jwmf3goTfUIT+A2org+4Um
BmEDUX3JNh5IF0g7OILGyQ7aYNKkrGnT1klbLdusL7jTzfmeMLaW7Cz+Pqex8+bMZefk4kUaO7Ww
Y2s7ttLU4NmTKQpDk+wgYxxjvpQVP2bx0X1w9A58NpgxJU0wwacqgaGHHpg8gOS3HM3Srb8AAAD/
/wMAUEsDBBQABgAIAAAAIQDCwSunegEAAKICAAAYAAAAeGwvd29ya3NoZWV0cy9zaGVldDIueG1s
jJJPSwMxEMXvgt8h5O5mq9Y/pVsRS7EHQUS9p9nZ3dBNJiRT2357J1srQi/eMiT5vXlvZvqwc734
gpgs+kqOilIK8AZr69tKfrwvLu6kSKR9rXv0UMk9JPkwOz+bbjGuUwdAggk+VbIjChOlkunA6VRg
AM83DUanicvYqhQi6Hr45Hp1WZY3ymnr5YEwif9hYNNYA3M0GweeDpAIvSbuP3U2pCPNmf/gnI7r
Tbgw6AIjVra3tB+gUjgzWbYeo1717Hs3utbmyB6KE7yzJmLChgrGqUOjp57v1b1i0mxaW3aQYxcR
mko+jqSaTYdwPi1s05+zyFmvENf5YllXssxP1cnbxZD1axQ1NHrT0xtun8G2HfFgr4oxd59NTOr9
HJLh9BhUjMa/snNNmrmh40GTNcxp0FPWu5GC9oFT8PiE/mdb8r+gW3jRsbU+iR6agXgrRTyIlgWf
CUPWuWX5FRKhO1Yd7wLwzMviSrIS0rHI3n63a/YNAAD//wMAUEsDBBQABgAIAAAAIQDCwSunegEA
AKICAAAYAAAAeGwvd29ya3NoZWV0cy9zaGVldDMueG1sjJJPSwMxEMXvgt8h5O5mq9Y/pVsRS7EH
QUS9p9nZ3dBNJiRT2357J1srQi/eMiT5vXlvZvqwc734gpgs+kqOilIK8AZr69tKfrwvLu6kSKR9
rXv0UMk9JPkwOz+bbjGuUwdAggk+VbIjChOlkunA6VRgAM83DUanicvYqhQi6Hr45Hp1WZY3ymnr
5YEwif9hYNNYA3M0GweeDpAIvSbuP3U2pCPNmf/gnI7rTbgw6AIjVra3tB+gUjgzWbYeo1717Hs3
utbmyB6KE7yzJmLChgrGqUOjp57v1b1i0mxaW3aQYxcRmko+jqSaTYdwPi1s05+zyFmvENf5YllX
ssxP1cnbxZD1axQ1NHrT0xtun8G2HfFgr4oxd59NTOr9HJLh9BhUjMa/snNNmrmh40GTNcxp0FPW
u5GC9oFT8PiE/mdb8r+gW3jRsbU+iR6agXgrRTyIlgWfCUPWuWX5FRKhO1Yd7wLwzMviSrIS0rHI
3n63a/YNAAD//wMAUEsDBBQABgAIAAAAIQB0L7BAygkAAAUlAAAYAAAAeGwvd29ya3NoZWV0cy9z
aGVldDEueG1spFpbc+I8En3fqv0PFO9jLFm+UUm+qvi287BVW3t9JsRJqAHMgpPM/Ps9utlWixAm
mwcg6qOWdLpbOgjf/PFzt529tcfTptvfzlkQzmftft09bvbPt/N//bP+ls1np361f1xtu317O//V
nuZ/3P35Tzfv3fHH6aVt+xk87E+385e+PywXi9P6pd2tTkF3aPewPHXH3arHv8fnxelwbFePqtNu
u+BhmCx2q81+rj0sj9f46J6eNuu27Navu3bfayfHdrvqMf/Ty+Zwst5262vc7VbHH6+Hb+tud4CL
h8120/9STuez3Xr5/XnfHVcPW6z7JxOrtfWt/vHc7zbrY3fqnvoA7hZ6ov6a80W+gKe7m8cNViBp
nx3bp9v5PVs2EZsv7m4UQf/etO+nyedZv3r4R7tt1337iDjNZ5L/h677IYHf0RTC5UkBpMvVut+8
tUW73d7Ov8sQ/lcNgo8YYDGMMP1sR6tVxP52nD22T6vXbf/37v0v7eb5pcewURCDA0nF8vFX2Z7W
iAGGDlgs/a67LZzgdbbbIJk4OFz9VO/vm8f+BZ8wk/Xrqe92/9ENar1Dh8h0wLvpgAETjiEvdBKm
E95tJx5k6eVOsKqp4d12ij7tlJhOeLedRPDJ7FLTB++2Dw/OT26h6VOxKVf96u7m2L3PUBQI9umw
kiXGl/CjAqEH7l826x/3nYzM2bBwGRXjBdGYejkfRERPjngvwbfzfD6D6xMS6+0uvFm8IVvWBlFo
BMO4A4S5kNJAEM0Bwl1IdQYSuZD6DES4kMZAEMxhoHiALLD+gQTMZUrCb1FpuZE+QHioMl6yVZgW
xbbirzQtYsBUXkvttTSmJZG9nGkjt6fTvhw7Cb6dC5TawEYysKGmVxhIriKbpyIY6dLz14BY7ilv
d3maBjRwBsAMgPSvXTMj5saYueqNMyeJQ55GnItQRCkbZ+uQgPBeT4IE384jlOpAQkpIMBChJhEG
uWsutZnrFcJMsrv6xF5TO01aYx+Gj1MhkizMYhYmURaNlDkkYEHXkyDBhITMXWWhIcJEIsywOU3+
CLo06EjHLUyxZ4qExZF5dX1XFM0CwbM4ZfqV1rmDzuEaycDjOGI5EyQ2jcGmJn8Y41HCshSCIkmz
bIyUQx22zuupk2BCHZlEYSCajCQT47C6hrSd6SJLRE5LyLUj8i59tWNPQ0byt9F2PiRQKnKWhXEC
uqKYxR9UkdQCk8Pk8lYiwYQFRg8Cg9E0iIiTPC+13dAgYmqvXHsmCE21Y0eUx3Upmhttj/X4YZDk
WY4NK0oyHodZNmHdSQYcbdfTIMGUBhLtwmD0NHiUk/Qutd3QwLKY0FhpO4f8HjYsRqlwfBAHjXGA
beWcA2fxOLuc1X/pGFROwArScByQrLqwoNhssiyPUaXjH2GxNHieWHziwEOCryxe7wTQoaRIagsY
HGaJGIcPqcPG4jOztYQC+cTTMMoSniThuAe4hP4/Es3qCqmlkGYsHURD4TeVflPlN9V+U2Ob9DeA
qShiUj9dvScotKsNGan5wmDkkGNuuNtbaTEQPQOGJHx1DkNSrD6HIfNpLGZaHB8csEyKsAkZX6sN
o+QmGlH5RXQnItE2TVSi31T7TY1t8oUik8pqMvvL27tCfyIVLUYfY1lGtp3S2GOtkzx7RezpWEFq
+64/sTfWPmjFkLEoTeJE8DSNs/HQdAtSqqvredBa7KJaxDdcdQjY45YupDSAQTCOM1MLrT6x156d
FENjAXYGeRIJJoaXeEx6lwoplq6nQksrhwqykoIZ+aU3dYZ4BDmkewzdynP8RwvdwPUWzFhIUqiy
/gwgzDN8Q3ad1BSTsiCPGcd5ol48rsyYViGGUc7iOBacMZHhb/DuUiUl1fVUaQHmUEWyu8BmrrJG
y4IUiTuMrEWiARhdkLKYeKgIQCTEQ00AMSMeGgMYhWIGhlnMIpHnLAIpw5RcMqSwup4MLcMcMjyp
yAxIs5FEdC2lAVjNHEYklyoKEN55r4ewHpCRw+q0XDQeRjZiHPBMRLFIBMpp8jXPZUPKq+vZ0GLM
ZYOkdIE5TnMjJWVRGrtZSs7JSipjvywZXSdkiMa6mJ6LE9XpMCDHmTLwpYNROVGiUV4XqssT26QV
FyQcvvS5MSsNhOszCBCaFh5AsNz5cx3Wdkx9vyEdJkRZNtalnRb4ZwwCEPtXLtIs+qBqsP07LF0+
gBXalXx+U+k3VX5T7Tc1tsmXfJxIvq8F09y7TQSr8ussqPSbKr+p9psa23Rm9kSjfUKyEWMTnTm5
YjJJqDF4HbQoSYiSa8i0VGhFnoGQTK3PQMZM0juUgUy/V40F4ZYkUXtfi6K+jBt1aYG9UW5Moywt
TYvSm2qSlddSey2NaTkTP6mlrt5M5Q27nA529iE45BAsLMbeaOIWyy350iCMToXEoJeSFUGkuEpw
fdQEMaoIEzg90VhLVVwZ5tCpUZgwXGyKLE/HjHKjKLXK9WxoZeMcLWStBb4+q5NFsyECfHGd/kXV
N5K5pemBkpMXviJIE2f7zL0eld9jOkToj1HTHrGPaSxGa1zcDPMsyVPcGaYiynn+UR38lm7jZ3Qb
CWVhMEJLXC4laZhkSZLHPM1ymhilhWsFy8MYyQMhljNcxnHcyLl5VHlwHkQ4VriIsFhBU7cmcJZE
gZRtYRZlWcyJ88aix68JecblHS1mxTP+kfaVP839RhYaJYdEG2qSVEuhPOKs12oP+eSyUBq70Tcs
pLcIlQcg8qWmgNDbSvU0sRGpn7BQkXGIsPAwwm0xj0fq3IL8La0HVaKKbUqFp3wtyHDhaT1jN1zk
KcnHitjFWAhq66mJnSZoY+yGCNRVyMABEhQ/OuDSfIiMw0NEFN/lY1ah6S0pmWdhQEILL06WWRoz
TkAZr4nG0oeONV+8JLUg7YOkTGOt02P8I8WLX+OdkvjS8aqcfHZNakBCX6KkAVGvsbf9ltat7RG6
+7XwelS2h97ic/za7XbxetRujyyI3EHObN+mB+pS1xt2TOx/KLg0RU5H0RhvnWj6QQT9Y/euPT6r
BxZOs3X3Kh8rwFe1u5uh2TwlwZf3kbwgJe24TlyWuBfzLbhEXFZnLbg6XMrrNb8PLgyX8pbNtxR8
iZ97/fYSw59rrzD4ufYaQ59rbzDwufZ7Hi3vUb7+yAUsUrL5FkjWpZRuvqWCRUo43wKBupRSzrc0
sEhJ51vuwdb9ebZgKbRlMQQMj4gcXvAsUb9Z4yGTp27fy8dX5Pb564AHbfZd0e3NA0lysMPquf3r
6vi82Z9m2/YJeREGOMGP+okU9bnvDqoVRf3Q9Xi6xP73gseNWvxCHwYQ709d19t/4Hfxbh9guvsf
AAAA//8DAFBLAwQUAAYACAAAACEAZp0jhCYBAABwAgAAFAAAAHhsL3NoYXJlZFN0cmluZ3MueG1s
dJLLTsMwEEX3SPzDyAipLFqnqAKEknRRCbGoRHh0jUw8JBbxuHgc2v49brvCDUvfc+fOQ87nW9vB
D3o2jgoxnWQCkGqnDTWFWL09jO8EcFCkVecIC7FDFvPy/CxnDhBriQvRhrC+l5LrFq3iiVsjRfLp
vFUhPn0jee1RaW4Rg+3kdZbdSKsMCahdT6EQs5mAnsx3j4ujML0VZc6mzENZofqCpVM6l6HM5V48
gqll0Nip3QnI/iOvL4vU7LxpDKku1WP6+yFdPnmTwgr9YT2qMUWLanWZanu7HAL7k+m+Q/A9QWi9
65sWRheSr9KI2lHAbQDemFC3MGw6zAvU2w/0w45xmvvsGEaMMV6f9Hw0cZqhy//pM9xo6TZJqYw/
pvwFAAD//wMAUEsDBBQABgAIAAAAIQCpxHlInAYAAF8zAAANAAAAeGwvc3R5bGVzLnhtbNRb3Y7i
NhS+r9R3iDJStVuVCWFgGFhg2mEWaaXtaqWZSr1YaRSCA9EmMU3MLGzVJ+hl36Nv0Ldp36PHdpwA
wYnJhNksN8SOffyd7xwf/2ZwvfY97RGFkYuDoW6eN3UNBTaeucF8qP9yP2lc6VpErGBmeThAQ32D
Iv169O03g4hsPHS3QIhoICKIhvqCkGXfMCJ7gXwrOsdLFMAbB4e+RSAZzo1oGSJrFtFKvme0ms1L
w7fcQOcS+r6tIsS3wo+rZcPG/tIi7tT1XLJhsnTNt/tv5gEOrakHUNdm27KFbJbIiPddO8QRdsg5
iDOw47g2yqLsGT0DJI0Gwcqf+CTSbLwKyFBvJ1kaf/NmBhR2L3WNKz3GM4Dx8OJ77eyHs7PmebP5
8PIVTX54ITI+8Izvflth8qrB/66vWbEfH17qhmhzp4GupIFd6aVEg7Vl2LPgm6Wa6O02QWlpUkWN
mN3RwMFBSjIoy2zX/xjgT8GEvgKSgXlaajSIPmuPlgc5JpVhYw+HGgEHBOJZTmD5iJf47+8///3n
L1rKsXzX2/DcFqu2sMIIHJlLumjTPObGcVXfBaeimQZvtMKmyzUTzqdDfQI/4I6Rp6TmsW0VCb34
ctxV3HTM55jSeQo+e5SpIjpLuSLzyAh82vW8JDBd0O4BGaMBhEiCwmACCS1+vt8soXMEEM25R7Ny
BaXnobUxWx31ChH23BlFMR+zLpk4LHVZKmYav3CDGVojiJuXrNcZW4Bpd2Pg2B/oOMXhDEYqEX5b
NArwvNHAQw4BsaE7X9B/gpe0EUwIxPXRYOZacxxYHjwaoob4pzVhiIPRbKj7aOaufBDLA8k+OFo0
bkOxBsPD4ChWAOD1wp3QqKgA51ydcrKACcARhOeWz9KdW3yLbKFdbvlT61bgfl+5drnUPl23AvK+
ettVpB/0Z8a1ksM/3Sq5Rle1yTNjrohpwXCBuCoGlVyWTx3laqhfASRVv3sGC2aG11xTqgIv2WFO
A0awmKvZgV6QWz6NTPUCXeB5zwW7AEZ5toUxCxrYijlgn9NNv8v6SAF81X4m2MiFUVOyT4Q50x2/
MNUFzacdUtiyoEI5zz6W7AIQKeoq6Y6XxrDStpHn3dEl8a9OstymmwprZ2sjEraK6UYY3fSkj7BU
jx/5yponRgPLc+eBjwLYXkMhcW26W2dDEvEdtbUjF2tKxYLaO1jiXVeORl5Ns5ZLbzMB1AwzTwHw
NHXD9hjS9E8CfZr1PsQE2YRtmPOdy226OHlbvHXoNvEOWCXitLVTAYMXEgaBIi4fHrY4ESnBgkhv
sUA3XVKTLnDofgY6qVFpnNOPN7IMYqv+EM3OCTCyvl0hjyacR1Ru68pB0m1+5vDC5XgnFalSDlk5
SDgdqT9IOF/JA0m3gunZCO/2teC1BQGxppDb9Y+fMog1ip8yiLWKn1KQdYqfUpB1ip9SkHWKn1KQ
9Y2fMsg1jp8wzkgWBnsRPx2Iyk7t+QgCUS93PrsvfWsuLsMKE9Td0UmO9WnSOHKluTaf2oAyRmb9
xO5X5C+EMhq9W/lTFE7YVZ1Dk4N91swyih7bSJk2ZLObjAL8lk4+TdDfTuZUiewKZmIH3cDssrs8
+Rom6xfRbQ7bSDYXz7J6TJtC88NtyjuZ0lo/GbSFZuo6KHSghDdVHQ507Sx5xzQs1DpMnkxZBRgK
vS6jfZ6tjlFKlc196hQwZ+ZHcswKiDPSDptB3oZS70ymS+WMXYIlUL3CoY6OEqrizK4C7Qkhqo6i
4O8qQ9mTzV3GQVWHMgXZGd7yHBOUdeJtXaBZzN7ABadsa5RuSiZ8HOOYMn0O2Ei2w5gz6zG7CriT
eU+dcLPrwplheofvZLIgcO/Gdxmz+wFAiaNKbVsKQaVWyiLY4hvoPOjfFfGt0DPh2rJyiFQRBxqp
RlwVcYkpRMBNA8eBbrvP9RNb2BenNO8zC2yXKpArHqY4FXuGQQ+J4Fho63Bt52gtOUPS6D3hoT7G
vm9piT355WBxLBeXeUcXbJ4wOdA9XbkecQN+cAQK7gvlFVKp7Io8Q8ZO+wDcbJ2e+LHDLUI/puBv
xcVbaGiGHGvlkfvk5VBPn39mt2gBelzqvfuICRMx1NPnt/SqLhxOAEy0Jm8juFkL/9oqdIf6769v
ur3b15NW46p5c9VoX6BOo9e5uW102uOb29tJr9lqjv8AxemXJ334PuAJX3awL1DghM5s9yMPvv8I
Y2Vj8Hdp3lDfSnD47EY0wIaFuFDCiJIvY0b/AwAA//8DAFBLAwQUAAYACAAAACEAjNwihp4BAABY
AwAAEAAIAWRvY1Byb3BzL2FwcC54bWwgogQBKKAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AACck0FP4zAQhe9I/IfId+q0RStUOUarAgJpV1RqgbPXmTQWjm15hqjdX4+TqDQF9rK38bynp88z
trjeNTZrIaLxrmDTSc4ycNqXxm0L9rS5u7hiGZJypbLeQcH2gOxanp+JVfQBIhnALEU4LFhNFBac
o66hUThJsktK5WOjKB3jlvuqMhpuvH5rwBGf5fkPDjsCV0J5ET4C2ZC4aOl/Q0uvOz583uxDApbi
ZwjWaEXplvK30dGjryi73Wmwgo9FkejWoN+iob3MBR8fxVorC8sULCtlEQQ/NsQ9qG5oK2UiStHS
ogVNPmZo/qaxzVj2RyF0OAVrVTTKUcLqbMOhr21AivLFx1esAQgFT4ah2Zdj77g2l3LeG1JxauwC
BpAknCJuDFnAx2qlIn1DPB8T9wwD74Cz7vimY74P0l6a/VsaSMe36geV+D4RLX0TlNvLB0dgs6WP
wcd+g4IfJPHLuFd8Cht/owgOWzltinWtIpRpkQf92BD3aSHRdiHLWrktlAfPV6F7Q8/DR5HTy0k+
z9PzGPUEP34J+Q4AAP//AwBQSwMEFAAGAAgAAAAhABg6Wmw8AQAAWQIAABEACAFkb2NQcm9wcy9j
b3JlLnhtbCCiBAEooAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJSSzU7DMBCE70i8Q+R7
4jgFVKwklQD1RCUkioq4Wfa2tYgdyzZN+/Y4Pw1B5cLRO7Pfzq6cL46qig5gnax1gUiSogg0r4XU
uwK9rZfxHEXOMy1YVWso0AkcWpTXVzk3lNcWXmxtwHoJLgok7Sg3Bdp7byjGju9BMZcEhw7itraK
+fC0O2wY/2Q7wFma3mEFngnmGW6BsRmJaEAKPiLNl606gOAYKlCgvcMkIfjH68Eq92dDp0ycSvqT
CTsNcadswXtxdB+dHI1N0yTNrIsR8hP8vnp+7VaNpW5vxQGVueCUW2C+tuW+OmQ5nhTa41XM+VW4
81aCeDgNnst64HSxexiIKAShfeyzspk9Pq2XqMxSQmKSxYSsyS0l9zQlH+3YX/1tsL6ghuH/Id7M
J8QzoMzxxWcovwEAAP//AwBQSwECLQAUAAYACAAAACEAfGyYFmwBAACgBQAAEwAAAAAAAAAAAAAA
AAAAAAAAW0NvbnRlbnRfVHlwZXNdLnhtbFBLAQItABQABgAIAAAAIQC1VTAj9QAAAEwCAAALAAAA
AAAAAAAAAAAAAKUDAABfcmVscy8ucmVsc1BLAQItABQABgAIAAAAIQDeCf0oAgEAANQDAAAaAAAA
AAAAAAAAAAAAAMsGAAB4bC9fcmVscy93b3JrYm9vay54bWwucmVsc1BLAQItABQABgAIAAAAIQAw
MsWFYgEAAHECAAAPAAAAAAAAAAAAAAAAAA0JAAB4bC93b3JrYm9vay54bWxQSwECLQAUAAYACAAA
ACEA+2KlbZQGAACnGwAAEwAAAAAAAAAAAAAAAACcCgAAeGwvdGhlbWUvdGhlbWUxLnhtbFBLAQIt
ABQABgAIAAAAIQDCwSunegEAAKICAAAYAAAAAAAAAAAAAAAAAGERAAB4bC93b3Jrc2hlZXRzL3No
ZWV0Mi54bWxQSwECLQAUAAYACAAAACEAwsErp3oBAACiAgAAGAAAAAAAAAAAAAAAAAAREwAAeGwv
d29ya3NoZWV0cy9zaGVldDMueG1sUEsBAi0AFAAGAAgAAAAhAHQvsEDKCQAABSUAABgAAAAAAAAA
AAAAAAAAwRQAAHhsL3dvcmtzaGVldHMvc2hlZXQxLnhtbFBLAQItABQABgAIAAAAIQBmnSOEJgEA
AHACAAAUAAAAAAAAAAAAAAAAAMEeAAB4bC9zaGFyZWRTdHJpbmdzLnhtbFBLAQItABQABgAIAAAA
IQCpxHlInAYAAF8zAAANAAAAAAAAAAAAAAAAABkgAAB4bC9zdHlsZXMueG1sUEsBAi0AFAAGAAgA
AAAhAIzcIoaeAQAAWAMAABAAAAAAAAAAAAAAAAAA4CYAAGRvY1Byb3BzL2FwcC54bWxQSwECLQAU
AAYACAAAACEAGDpabDwBAABZAgAAEQAAAAAAAAAAAAAAAAC0KQAAZG9jUHJvcHMvY29yZS54bWxQ
SwUGAAAAAAwADAAMAwAAJywAAAAA

--_002_C10D3FB0CD45994C8A51FEC1227CE22F39412A99CEshsmsx502ccrc_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--_002_C10D3FB0CD45994C8A51FEC1227CE22F39412A99CEshsmsx502ccrc_--


From xen-devel-bounces@lists.xensource.com Tue Dec 20 09:46:50 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 Dec 2011 09: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.xensource.com>)
	id 1RcwHF-0008Rq-5l; Tue, 20 Dec 2011 09:46:29 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <hui.lv@intel.com>) id 1RcwHD-0008Ra-IH
	for xen-devel@lists.xensource.com; Tue, 20 Dec 2011 09:46:28 +0000
X-Env-Sender: hui.lv@intel.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1324374379!6234443!1
X-Originating-IP: [134.134.136.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjQgPT4gMzE4MDY5\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12667 invoked from network); 20 Dec 2011 09:46:20 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-7.tower-174.messagelabs.com with SMTP;
	20 Dec 2011 09:46:20 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga102.jf.intel.com with ESMTP; 20 Dec 2011 01:45:15 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.67,352,1309762800"; 
	d="xml'?rels'?scan'72,48,208?xlsx'72,48,208,72,48";a="88425283"
Received: from pgsmsx602.gar.corp.intel.com ([10.221.43.81])
	by orsmga001.jf.intel.com with ESMTP; 20 Dec 2011 01:45:04 -0800
Received: from pgsmsx104.gar.corp.intel.com (10.221.44.91) by
	pgsmsx602.gar.corp.intel.com (10.221.43.81) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Tue, 20 Dec 2011 17:44:11 +0800
Received: from shsmsx601.ccr.corp.intel.com (10.239.4.112) by
	PGSMSX104.gar.corp.intel.com (10.221.44.91) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Tue, 20 Dec 2011 17:44:10 +0800
Received: from shsmsx502.ccr.corp.intel.com ([10.239.4.96]) by
	shsmsx601.ccr.corp.intel.com ([10.239.4.112]) with mapi;
	Tue, 20 Dec 2011 17:44:10 +0800
From: "Lv, Hui" <hui.lv@intel.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Tue, 20 Dec 2011 17:44:09 +0800
Thread-Topic: [Xen-devel] [PATCH] xen/sched_credit: Use delay to control
	scheduling frequency
Thread-Index: Acy+9uNlaSLozX1SSw2LWaCKLABrWAAAWByA
Message-ID: <C10D3FB0CD45994C8A51FEC1227CE22F39412A99CE@shsmsx502.ccr.corp.intel.com>
References: <114495d1ff947737518b.1324332781@wsm-ep-n0>
	<1324372056.23729.8.camel@zakaz.uk.xensource.com>
In-Reply-To: <1324372056.23729.8.camel@zakaz.uk.xensource.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/mixed;
	boundary="_002_C10D3FB0CD45994C8A51FEC1227CE22F39412A99CEshsmsx502ccrc_"
MIME-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] xen/sched_credit: Use delay to control
 scheduling frequency
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--_002_C10D3FB0CD45994C8A51FEC1227CE22F39412A99CEshsmsx502ccrc_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

DQo+IElzIGl0IHBvc3NpYmxlIHRvIHB1Ymxpc2ggdGhlIHJhdyBudW1iZXJzPw0KWWVzLiANCkFj
dHVhbGx5LCBJIGhhdmUgcG9zdGVkIHRoZSByYXcgZGF0YSBiZWZvcmUuIA0KWW91IGNhbiBjaGVj
ayB0aGUgYXR0YWNobWVudCBmb3IgdGhlIGRldGFpbHMuDQoNCj4gSWYgdGhpcyBpcyBnZW5lcmlj
IHRoZW4gaXQgc2VlbXMgbGlrZSB4ZW4vc2NoZWQuaCBpcyB0aGUgcmlnaHQgcGxhY2UgZm9yIGl0
Lg0KPiANCj4gSXMgaXQgcmVhbGx5IGdlbmVyaWMgdGhvdWdoIGlmIG9ubHkgdGhlIGNyZWRpdCBz
Y2hlZHVsZXIgYXBwbGllcyBpdD8NCg0KV2UgaGF2ZSBkaXNjdXNzZWQgdGhlICJnZW5lcmljIiBp
c3N1ZSBpbiBwcmV2aW91cyBtYWlscyB3aXRoIEdlb3JnZSwgRGFyaW8gRmFnZ2lvbGkgYW5kIHNv
bWUgb3RoZXIgcGVvcGxlLg0KVGhlIGNvbmNsdXNpb24gaXMgdGhhdCBjdXJyZW50bHksIGl0IGlz
IGFwcGxpZWQgdG8gY3JlZGl0IHNjaGVkdWxlci4gSW4gZnV0dXJlLCBpdCBtYXkgYmUgZGV2ZWxv
cGVkIGludG8gYSBnZW5lcmljIHNvbHV0aW9uLg0KDQo+IFRoaXMgaXMgdGhlIHNhbWUgY29tbWVu
dCBhcyB0aGUgbmV4dCBibG9jayBiZWxvdywgZG9lcyBpdCByZWFsbHkgYXBwbHkgaGVyZQ0KPiB0
b28/DQo+IA0KPiBTaW5jZSB0aGUgcHJldmlvdXMgaWYgYmxvY2sgZW5kcyB3aXRoIGEgZ290byB0
aGUgZWxzZSBjbGF1c2UgaXMgYSBiaXQgcmVkdW5kYW50Lg0KDQpUaGFua3MsIEknbGwgcmVtb3Zl
IHRoZSByZWR1bmRhbnQgY29tbWVudCBhbmQgZWxzZSBjbGF1c2UuDQoNCj4gSXQgdGhhdCBjb25z
dHJhaW50IGVuZm9yY2VkIGFueXdoZXJlPw0KDQpDdXJyZW50bHksIGl0J3Mgbm90IGNvbnN0cmFp
bnQgZW5mb3JjZWQuIA0KSSB0aGluayBHZW9yZ2UgaGF2ZSBnYXZlIHRoZSBleHBsYW5hdGlvbiBp
biB5ZXN0ZXJkYXkncyBkaXNjdXNzaW9uLg0KDQoNCkJlc3QgcmVnYXJkcywNCg0KTHYsIEh1aQ0K
DQoNCg0K

--_002_C10D3FB0CD45994C8A51FEC1227CE22F39412A99CEshsmsx502ccrc_
Content-Type: application/vnd.openxmlformats-officedocument.spreadsheetml.sheet;
	name="scheduler comparison.xlsx"
Content-Description: scheduler comparison.xlsx
Content-Disposition: attachment; filename="scheduler comparison.xlsx";
	size=12105; creation-date="Sun, 11 Dec 2011 23:19:48 GMT";
	modification-date="Sun, 11 Dec 2011 23:19:48 GMT"
Content-Transfer-Encoding: base64

UEsDBBQABgAIAAAAIQB8bJgWbAEAAKAFAAATAAgCW0NvbnRlbnRfVHlwZXNdLnhtbCCiBAIooAAC
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADM
lF1LwzAUhu8F/0PJrTTZJojIul34cakD5w+IzekaliYhJ5vbv/c0+0CkbgwHetPQ5pz3fZI073C8
aky2hIDa2YL1eY9lYEuntJ0V7G36lN+yDKO0ShpnoWBrQDYeXV4Mp2sPmFG3xYLVMfo7IbCsoZHI
nQdLM5ULjYz0GmbCy3IuZyAGvd6NKJ2NYGMeWw02Gj5AJRcmZo8r+rwhCWCQZfebwtarYNJ7o0sZ
iVQsrfrmkm8dOHWmGqy1xyvCYKLToZ352WDb90JbE7SCbCJDfJYNYYiVER8uzN+dm/PDIh2Urqp0
CcqVi4Z2gKMPIBXWALExPI28kdruuA/4p2IUaeifGaRdXxI+kWPwTziu/4gj0v8PIj1/fyRJ5sgB
YFwbwDOvdiN6zLmWAdRrDJQUZwf4qn2Ig+7RJDiPlCgBTt+FXWS03bknIQhRwz40ui7f3pHS6HTD
b7cf2rxToDq8RcrX0ScAAAD//wMAUEsDBBQABgAIAAAAIQC1VTAj9QAAAEwCAAALAAgCX3JlbHMv
LnJlbHMgogQCKKAAAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAjJLPTsMwDMbvSLxD5PvqbkgIoaW7TEi7IVQewCTuH7WNoyRA9/aEA4JKY9vR
9ufPP1ve7uZpVB8cYi9Ow7ooQbEzYnvXanitn1YPoGIiZ2kUxxqOHGFX3d5sX3iklJti1/uosouL
GrqU/CNiNB1PFAvx7HKlkTBRymFo0ZMZqGXclOU9hr8eUC081cFqCAd7B6o++jz5src0TW94L+Z9
YpdOjECeEzvLduVDZgupz9uomkLLSYMV85zTEcn7ImMDnibaXE/0/7Y4cSJLidBI4PM834pzQOvr
gS6faKn4vc484qeE4U1k+GHBxQ9UXwAAAP//AwBQSwMEFAAGAAgAAAAhAN4J/SgCAQAA1AMAABoA
CAF4bC9fcmVscy93b3JrYm9vay54bWwucmVscyCiBAEooAABAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAALyTz2rDMAzG74O9g9F9cZJuZZQ6vYxBr1v3ACZR4tDENpb2J28/k0O6QMkuoReDJPx9
P9Cn/eGn78QXBmqdVZAlKQi0pata2yj4OL0+PIMg1rbSnbOoYECCQ3F/t3/DTnP8RKb1JKKKJQWG
2e+kpNJgrylxHm2c1C70mmMZGul1edYNyjxNtzL81YBipimOlYJwrDYgToOPzv9ru7puS3xx5WeP
lq9YyG8XzmQQOYrq0CArmFokx8kmicQgr8PkN4bJl2CyG8NkSzDbNWHI6IDVO4eYQrqsatZegnla
FYaHLoZ+CgyN9ZL945r2HE8JL+5jKcd32oec3WLxCwAA//8DAFBLAwQUAAYACAAAACEAMDLFhWIB
AABxAgAADwAAAHhsL3dvcmtib29rLnhtbIxSy27CMBC8V+o/WL6XJA6kFJEgVW1VLlWlUji78YZY
OHZkOw38fTdGPCQuPe2udzKeGWe+2DeK/IJ10uicJqOYEtClEVJvc/q9enuYUuI814IroyGnB3B0
UdzfzXtjdz/G7AgSaJfT2vt2FkWurKHhbmRa0LipjG24x9FuI9da4MLVAL5REYvjLGq41PTIMLP/
4TBVJUt4MWXXgPZHEguKe5Tvatk6WswrqWB9dER4237wBnXvFSWKO/8qpAeR0wmOpofLwZgS27XP
nVS4fUpjRqPibPLTEgEV75Rfob0TO+bFxoxlA3KIYi2hd5ePhpHsN1IL0+c0zTDaw2lKUhTQh9VG
Cl8j1SO7nL2D3NY+p1M2jQf26Io+BIjXhEp0cPc1hJrgSw11iQawtzOJjV2KZGC4QbMrNPZndPB9
g06v0Nif0WlQF+AoqeSqxKiGEkSMJxkLt0env6X4AwAA//8DAFBLAwQUAAYACAAAACEA+2KlbZQG
AACnGwAAEwAAAHhsL3RoZW1lL3RoZW1lMS54bWzsWU9v2zYUvw/YdyB0b20nthsHdYrYsZutTRvE
boceaZmWWFOiQNJJfRva44ABw7phlwG77TBsK9ACu3SfJluHrQP6FfZISrIYy0vSBhvW1YdEIn98
/9/jI3X12oOIoUMiJOVx26tdrnqIxD4f0zhoe3eG/UsbHpIKx2PMeEza3pxI79rW++9dxZsqJBFB
sD6Wm7jthUolm5WK9GEYy8s8ITHMTbiIsIJXEVTGAh8B3YhV1qrVZiXCNPZQjCMge3syoT5BQ03S
28qI9xi8xkrqAZ+JgSZNnBUGO57WNELOZZcJdIhZ2wM+Y340JA+UhxiWCibaXtX8vMrW1QreTBcx
tWJtYV3f/NJ16YLxdM3wFMEoZ1rr11tXdnL6BsDUMq7X63V7tZyeAWDfB02tLEWa9f5GrZPRLIDs
4zLtbrVRrbv4Av31JZlbnU6n0UplsUQNyD7Wl/Ab1WZ9e83BG5DFN5bw9c52t9t08AZk8c0lfP9K
q1l38QYUMhpPl9Daof1+Sj2HTDjbLYVvAHyjmsIXKIiGPLo0iwmP1apYi/B9LvoA0ECGFY2Rmidk
gn2I4i6ORoJizQBvElyYsUO+XBrSvJD0BU1U2/swwZARC3qvnn//6vlT9Or5k+OHz44f/nT86NHx
wx8tLWfhLo6D4sKX337259cfoz+efvPy8RfleFnE//rDJ7/8/Hk5EDJoIdGLL5/89uzJi68+/f27
xyXwbYFHRfiQRkSiW+QIHfAIdDOGcSUnI3G+FcMQU2cFDoF2CemeCh3grTlmZbgOcY13V0DxKANe
n913ZB2EYqZoCecbYeQA9zhnHS5KDXBD8ypYeDiLg3LmYlbEHWB8WMa7i2PHtb1ZAlUzC0rH9t2Q
OGLuMxwrHJCYKKTn+JSQEu3uUerYdY/6gks+UegeRR1MS00ypCMnkBaLdmkEfpmX6Qyudmyzdxd1
OCvTeoccukhICMxKhB8S5pjxOp4pHJWRHOKIFQ1+E6uwTMjBXPhFXE8q8HRAGEe9MZGybM1tAfoW
nH4DQ70qdfsem0cuUig6LaN5E3NeRO7waTfEUVKGHdA4LGI/kFMIUYz2uSqD73E3Q/Q7+AHHK919
lxLH3acXgjs0cERaBIiemYkSX14n3InfwZxNMDFVBkq6U6kjGv9d2WYU6rbl8K5st71t2MTKkmf3
RLFehfsPlugdPIv3CWTF8hb1rkK/q9DeW1+hV+XyxdflRSmGKq0bEttrm847Wtl4TyhjAzVn5KY0
vbeEDWjch0G9zhw6SX4QS0J41JkMDBxcILBZgwRXH1EVDkKcQN9e8zSRQKakA4kSLuG8aIZLaWs8
9P7KnjYb+hxiK4fEao+P7fC6Hs6OGzkZI1VgzrQZo3VN4KzM1q+kREG312FW00KdmVvNiGaKosMt
V1mb2JzLweS5ajCYWxM6GwT9EFi5Ccd+zRrOO5iRsba79VHmFuOFi3SRDPGYpD7Sei/7qGaclMXK
kiJaDxsM+ux4itUK3Fqa7BtwO4uTiuzqK9hl3nsTL2URvPASUDuZjiwuJieL0VHbazXWGh7ycdL2
JnBUhscoAa9L3UxiFsB9k6+EDftTk9lk+cKbrUwxNwlqcPth7b6ksFMHEiHVDpahDQ0zlYYAizUn
K/9aA8x6UQqUVKOzSbG+AcHwr0kBdnRdSyYT4quiswsj2nb2NS2lfKaIGITjIzRiM3GAwf06VEGf
MZVw42Eqgn6B6zltbTPlFuc06YqXYgZnxzFLQpyWW52iWSZbuClIuQzmrSAe6FYqu1Hu/KqYlL8g
VYph/D9TRe8ncAWxPtYe8OF2WGCkM6XtcaFCDlUoCanfF9A4mNoB0QJXvDANQQV31Oa/IIf6v805
S8OkNZwk1QENkKCwH6lQELIPZclE3ynEauneZUmylJCJqIK4MrFij8ghYUNdA5t6b/dQCKFuqkla
BgzuZPy572kGjQLd5BTzzalk+d5rc+Cf7nxsMoNSbh02DU1m/1zEvD1Y7Kp2vVme7b1FRfTEos2q
Z1kBzApbQStN+9cU4Zxbra1YSxqvNTLhwIvLGsNg3hAlcJGE9B/Y/6jwmf3goTfUIT+A2org+4Um
BmEDUX3JNh5IF0g7OILGyQ7aYNKkrGnT1klbLdusL7jTzfmeMLaW7Cz+Pqex8+bMZefk4kUaO7Ww
Y2s7ttLU4NmTKQpDk+wgYxxjvpQVP2bx0X1w9A58NpgxJU0wwacqgaGHHpg8gOS3HM3Srb8AAAD/
/wMAUEsDBBQABgAIAAAAIQDCwSunegEAAKICAAAYAAAAeGwvd29ya3NoZWV0cy9zaGVldDIueG1s
jJJPSwMxEMXvgt8h5O5mq9Y/pVsRS7EHQUS9p9nZ3dBNJiRT2357J1srQi/eMiT5vXlvZvqwc734
gpgs+kqOilIK8AZr69tKfrwvLu6kSKR9rXv0UMk9JPkwOz+bbjGuUwdAggk+VbIjChOlkunA6VRg
AM83DUanicvYqhQi6Hr45Hp1WZY3ymnr5YEwif9hYNNYA3M0GweeDpAIvSbuP3U2pCPNmf/gnI7r
Tbgw6AIjVra3tB+gUjgzWbYeo1717Hs3utbmyB6KE7yzJmLChgrGqUOjp57v1b1i0mxaW3aQYxcR
mko+jqSaTYdwPi1s05+zyFmvENf5YllXssxP1cnbxZD1axQ1NHrT0xtun8G2HfFgr4oxd59NTOr9
HJLh9BhUjMa/snNNmrmh40GTNcxp0FPWu5GC9oFT8PiE/mdb8r+gW3jRsbU+iR6agXgrRTyIlgWf
CUPWuWX5FRKhO1Yd7wLwzMviSrIS0rHI3n63a/YNAAD//wMAUEsDBBQABgAIAAAAIQDCwSunegEA
AKICAAAYAAAAeGwvd29ya3NoZWV0cy9zaGVldDMueG1sjJJPSwMxEMXvgt8h5O5mq9Y/pVsRS7EH
QUS9p9nZ3dBNJiRT2357J1srQi/eMiT5vXlvZvqwc734gpgs+kqOilIK8AZr69tKfrwvLu6kSKR9
rXv0UMk9JPkwOz+bbjGuUwdAggk+VbIjChOlkunA6VRgAM83DUanicvYqhQi6Hr45Hp1WZY3ymnr
5YEwif9hYNNYA3M0GweeDpAIvSbuP3U2pCPNmf/gnI7rTbgw6AIjVra3tB+gUjgzWbYeo1717Hs3
utbmyB6KE7yzJmLChgrGqUOjp57v1b1i0mxaW3aQYxcRmko+jqSaTYdwPi1s05+zyFmvENf5YllX
ssxP1cnbxZD1axQ1NHrT0xtun8G2HfFgr4oxd59NTOr9HJLh9BhUjMa/snNNmrmh40GTNcxp0FPW
u5GC9oFT8PiE/mdb8r+gW3jRsbU+iR6agXgrRTyIlgWfCUPWuWX5FRKhO1Yd7wLwzMviSrIS0rHI
3n63a/YNAAD//wMAUEsDBBQABgAIAAAAIQB0L7BAygkAAAUlAAAYAAAAeGwvd29ya3NoZWV0cy9z
aGVldDEueG1spFpbc+I8En3fqv0PFO9jLFm+UUm+qvi287BVW3t9JsRJqAHMgpPM/Ps9utlWixAm
mwcg6qOWdLpbOgjf/PFzt529tcfTptvfzlkQzmftft09bvbPt/N//bP+ls1np361f1xtu317O//V
nuZ/3P35Tzfv3fHH6aVt+xk87E+385e+PywXi9P6pd2tTkF3aPewPHXH3arHv8fnxelwbFePqtNu
u+BhmCx2q81+rj0sj9f46J6eNuu27Navu3bfayfHdrvqMf/Ty+Zwst5262vc7VbHH6+Hb+tud4CL
h8120/9STuez3Xr5/XnfHVcPW6z7JxOrtfWt/vHc7zbrY3fqnvoA7hZ6ov6a80W+gKe7m8cNViBp
nx3bp9v5PVs2EZsv7m4UQf/etO+nyedZv3r4R7tt1337iDjNZ5L/h677IYHf0RTC5UkBpMvVut+8
tUW73d7Ov8sQ/lcNgo8YYDGMMP1sR6tVxP52nD22T6vXbf/37v0v7eb5pcewURCDA0nF8vFX2Z7W
iAGGDlgs/a67LZzgdbbbIJk4OFz9VO/vm8f+BZ8wk/Xrqe92/9ENar1Dh8h0wLvpgAETjiEvdBKm
E95tJx5k6eVOsKqp4d12ij7tlJhOeLedRPDJ7FLTB++2Dw/OT26h6VOxKVf96u7m2L3PUBQI9umw
kiXGl/CjAqEH7l826x/3nYzM2bBwGRXjBdGYejkfRERPjngvwbfzfD6D6xMS6+0uvFm8IVvWBlFo
BMO4A4S5kNJAEM0Bwl1IdQYSuZD6DES4kMZAEMxhoHiALLD+gQTMZUrCb1FpuZE+QHioMl6yVZgW
xbbirzQtYsBUXkvttTSmJZG9nGkjt6fTvhw7Cb6dC5TawEYysKGmVxhIriKbpyIY6dLz14BY7ilv
d3maBjRwBsAMgPSvXTMj5saYueqNMyeJQ55GnItQRCkbZ+uQgPBeT4IE384jlOpAQkpIMBChJhEG
uWsutZnrFcJMsrv6xF5TO01aYx+Gj1MhkizMYhYmURaNlDkkYEHXkyDBhITMXWWhIcJEIsywOU3+
CLo06EjHLUyxZ4qExZF5dX1XFM0CwbM4ZfqV1rmDzuEaycDjOGI5EyQ2jcGmJn8Y41HCshSCIkmz
bIyUQx22zuupk2BCHZlEYSCajCQT47C6hrSd6SJLRE5LyLUj8i59tWNPQ0byt9F2PiRQKnKWhXEC
uqKYxR9UkdQCk8Pk8lYiwYQFRg8Cg9E0iIiTPC+13dAgYmqvXHsmCE21Y0eUx3Upmhttj/X4YZDk
WY4NK0oyHodZNmHdSQYcbdfTIMGUBhLtwmD0NHiUk/Qutd3QwLKY0FhpO4f8HjYsRqlwfBAHjXGA
beWcA2fxOLuc1X/pGFROwArScByQrLqwoNhssiyPUaXjH2GxNHieWHziwEOCryxe7wTQoaRIagsY
HGaJGIcPqcPG4jOztYQC+cTTMMoSniThuAe4hP4/Es3qCqmlkGYsHURD4TeVflPlN9V+U2Ob9DeA
qShiUj9dvScotKsNGan5wmDkkGNuuNtbaTEQPQOGJHx1DkNSrD6HIfNpLGZaHB8csEyKsAkZX6sN
o+QmGlH5RXQnItE2TVSi31T7TY1t8oUik8pqMvvL27tCfyIVLUYfY1lGtp3S2GOtkzx7RezpWEFq
+64/sTfWPmjFkLEoTeJE8DSNs/HQdAtSqqvredBa7KJaxDdcdQjY45YupDSAQTCOM1MLrT6x156d
FENjAXYGeRIJJoaXeEx6lwoplq6nQksrhwqykoIZ+aU3dYZ4BDmkewzdynP8RwvdwPUWzFhIUqiy
/gwgzDN8Q3ad1BSTsiCPGcd5ol48rsyYViGGUc7iOBacMZHhb/DuUiUl1fVUaQHmUEWyu8BmrrJG
y4IUiTuMrEWiARhdkLKYeKgIQCTEQ00AMSMeGgMYhWIGhlnMIpHnLAIpw5RcMqSwup4MLcMcMjyp
yAxIs5FEdC2lAVjNHEYklyoKEN55r4ewHpCRw+q0XDQeRjZiHPBMRLFIBMpp8jXPZUPKq+vZ0GLM
ZYOkdIE5TnMjJWVRGrtZSs7JSipjvywZXSdkiMa6mJ6LE9XpMCDHmTLwpYNROVGiUV4XqssT26QV
FyQcvvS5MSsNhOszCBCaFh5AsNz5cx3Wdkx9vyEdJkRZNtalnRb4ZwwCEPtXLtIs+qBqsP07LF0+
gBXalXx+U+k3VX5T7Tc1tsmXfJxIvq8F09y7TQSr8ussqPSbKr+p9psa23Rm9kSjfUKyEWMTnTm5
YjJJqDF4HbQoSYiSa8i0VGhFnoGQTK3PQMZM0juUgUy/V40F4ZYkUXtfi6K+jBt1aYG9UW5Moywt
TYvSm2qSlddSey2NaTkTP6mlrt5M5Q27nA529iE45BAsLMbeaOIWyy350iCMToXEoJeSFUGkuEpw
fdQEMaoIEzg90VhLVVwZ5tCpUZgwXGyKLE/HjHKjKLXK9WxoZeMcLWStBb4+q5NFsyECfHGd/kXV
N5K5pemBkpMXviJIE2f7zL0eld9jOkToj1HTHrGPaSxGa1zcDPMsyVPcGaYiynn+UR38lm7jZ3Qb
CWVhMEJLXC4laZhkSZLHPM1ymhilhWsFy8MYyQMhljNcxnHcyLl5VHlwHkQ4VriIsFhBU7cmcJZE
gZRtYRZlWcyJ88aix68JecblHS1mxTP+kfaVP839RhYaJYdEG2qSVEuhPOKs12oP+eSyUBq70Tcs
pLcIlQcg8qWmgNDbSvU0sRGpn7BQkXGIsPAwwm0xj0fq3IL8La0HVaKKbUqFp3wtyHDhaT1jN1zk
KcnHitjFWAhq66mJnSZoY+yGCNRVyMABEhQ/OuDSfIiMw0NEFN/lY1ah6S0pmWdhQEILL06WWRoz
TkAZr4nG0oeONV+8JLUg7YOkTGOt02P8I8WLX+OdkvjS8aqcfHZNakBCX6KkAVGvsbf9ltat7RG6
+7XwelS2h97ic/za7XbxetRujyyI3EHObN+mB+pS1xt2TOx/KLg0RU5H0RhvnWj6QQT9Y/euPT6r
BxZOs3X3Kh8rwFe1u5uh2TwlwZf3kbwgJe24TlyWuBfzLbhEXFZnLbg6XMrrNb8PLgyX8pbNtxR8
iZ97/fYSw59rrzD4ufYaQ59rbzDwufZ7Hi3vUb7+yAUsUrL5FkjWpZRuvqWCRUo43wKBupRSzrc0
sEhJ51vuwdb9ebZgKbRlMQQMj4gcXvAsUb9Z4yGTp27fy8dX5Pb564AHbfZd0e3NA0lysMPquf3r
6vi82Z9m2/YJeREGOMGP+okU9bnvDqoVRf3Q9Xi6xP73gseNWvxCHwYQ709d19t/4Hfxbh9guvsf
AAAA//8DAFBLAwQUAAYACAAAACEAZp0jhCYBAABwAgAAFAAAAHhsL3NoYXJlZFN0cmluZ3MueG1s
dJLLTsMwEEX3SPzDyAipLFqnqAKEknRRCbGoRHh0jUw8JBbxuHgc2v49brvCDUvfc+fOQ87nW9vB
D3o2jgoxnWQCkGqnDTWFWL09jO8EcFCkVecIC7FDFvPy/CxnDhBriQvRhrC+l5LrFq3iiVsjRfLp
vFUhPn0jee1RaW4Rg+3kdZbdSKsMCahdT6EQs5mAnsx3j4ujML0VZc6mzENZofqCpVM6l6HM5V48
gqll0Nip3QnI/iOvL4vU7LxpDKku1WP6+yFdPnmTwgr9YT2qMUWLanWZanu7HAL7k+m+Q/A9QWi9
65sWRheSr9KI2lHAbQDemFC3MGw6zAvU2w/0w45xmvvsGEaMMV6f9Hw0cZqhy//pM9xo6TZJqYw/
pvwFAAD//wMAUEsDBBQABgAIAAAAIQCpxHlInAYAAF8zAAANAAAAeGwvc3R5bGVzLnhtbNRb3Y7i
NhS+r9R3iDJStVuVCWFgGFhg2mEWaaXtaqWZSr1YaRSCA9EmMU3MLGzVJ+hl36Nv0Ldp36PHdpwA
wYnJhNksN8SOffyd7xwf/2ZwvfY97RGFkYuDoW6eN3UNBTaeucF8qP9yP2lc6VpErGBmeThAQ32D
Iv169O03g4hsPHS3QIhoICKIhvqCkGXfMCJ7gXwrOsdLFMAbB4e+RSAZzo1oGSJrFtFKvme0ms1L
w7fcQOcS+r6tIsS3wo+rZcPG/tIi7tT1XLJhsnTNt/tv5gEOrakHUNdm27KFbJbIiPddO8QRdsg5
iDOw47g2yqLsGT0DJI0Gwcqf+CTSbLwKyFBvJ1kaf/NmBhR2L3WNKz3GM4Dx8OJ77eyHs7PmebP5
8PIVTX54ITI+8Izvflth8qrB/66vWbEfH17qhmhzp4GupIFd6aVEg7Vl2LPgm6Wa6O02QWlpUkWN
mN3RwMFBSjIoy2zX/xjgT8GEvgKSgXlaajSIPmuPlgc5JpVhYw+HGgEHBOJZTmD5iJf47+8///3n
L1rKsXzX2/DcFqu2sMIIHJlLumjTPObGcVXfBaeimQZvtMKmyzUTzqdDfQI/4I6Rp6TmsW0VCb34
ctxV3HTM55jSeQo+e5SpIjpLuSLzyAh82vW8JDBd0O4BGaMBhEiCwmACCS1+vt8soXMEEM25R7Ny
BaXnobUxWx31ChH23BlFMR+zLpk4LHVZKmYav3CDGVojiJuXrNcZW4Bpd2Pg2B/oOMXhDEYqEX5b
NArwvNHAQw4BsaE7X9B/gpe0EUwIxPXRYOZacxxYHjwaoob4pzVhiIPRbKj7aOaufBDLA8k+OFo0
bkOxBsPD4ChWAOD1wp3QqKgA51ydcrKACcARhOeWz9KdW3yLbKFdbvlT61bgfl+5drnUPl23AvK+
ettVpB/0Z8a1ksM/3Sq5Rle1yTNjrohpwXCBuCoGlVyWTx3laqhfASRVv3sGC2aG11xTqgIv2WFO
A0awmKvZgV6QWz6NTPUCXeB5zwW7AEZ5toUxCxrYijlgn9NNv8v6SAF81X4m2MiFUVOyT4Q50x2/
MNUFzacdUtiyoEI5zz6W7AIQKeoq6Y6XxrDStpHn3dEl8a9OstymmwprZ2sjEraK6UYY3fSkj7BU
jx/5yponRgPLc+eBjwLYXkMhcW26W2dDEvEdtbUjF2tKxYLaO1jiXVeORl5Ns5ZLbzMB1AwzTwHw
NHXD9hjS9E8CfZr1PsQE2YRtmPOdy226OHlbvHXoNvEOWCXitLVTAYMXEgaBIi4fHrY4ESnBgkhv
sUA3XVKTLnDofgY6qVFpnNOPN7IMYqv+EM3OCTCyvl0hjyacR1Ru68pB0m1+5vDC5XgnFalSDlk5
SDgdqT9IOF/JA0m3gunZCO/2teC1BQGxppDb9Y+fMog1ip8yiLWKn1KQdYqfUpB1ip9SkHWKn1KQ
9Y2fMsg1jp8wzkgWBnsRPx2Iyk7t+QgCUS93PrsvfWsuLsMKE9Td0UmO9WnSOHKluTaf2oAyRmb9
xO5X5C+EMhq9W/lTFE7YVZ1Dk4N91swyih7bSJk2ZLObjAL8lk4+TdDfTuZUiewKZmIH3cDssrs8
+Rom6xfRbQ7bSDYXz7J6TJtC88NtyjuZ0lo/GbSFZuo6KHSghDdVHQ507Sx5xzQs1DpMnkxZBRgK
vS6jfZ6tjlFKlc196hQwZ+ZHcswKiDPSDptB3oZS70ymS+WMXYIlUL3CoY6OEqrizK4C7Qkhqo6i
4O8qQ9mTzV3GQVWHMgXZGd7yHBOUdeJtXaBZzN7ABadsa5RuSiZ8HOOYMn0O2Ei2w5gz6zG7CriT
eU+dcLPrwplheofvZLIgcO/Gdxmz+wFAiaNKbVsKQaVWyiLY4hvoPOjfFfGt0DPh2rJyiFQRBxqp
RlwVcYkpRMBNA8eBbrvP9RNb2BenNO8zC2yXKpArHqY4FXuGQQ+J4Fho63Bt52gtOUPS6D3hoT7G
vm9piT355WBxLBeXeUcXbJ4wOdA9XbkecQN+cAQK7gvlFVKp7Io8Q8ZO+wDcbJ2e+LHDLUI/puBv
xcVbaGiGHGvlkfvk5VBPn39mt2gBelzqvfuICRMx1NPnt/SqLhxOAEy0Jm8juFkL/9oqdIf6769v
ur3b15NW46p5c9VoX6BOo9e5uW102uOb29tJr9lqjv8AxemXJ334PuAJX3awL1DghM5s9yMPvv8I
Y2Vj8Hdp3lDfSnD47EY0wIaFuFDCiJIvY0b/AwAA//8DAFBLAwQUAAYACAAAACEAjNwihp4BAABY
AwAAEAAIAWRvY1Byb3BzL2FwcC54bWwgogQBKKAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AACck0FP4zAQhe9I/IfId+q0RStUOUarAgJpV1RqgbPXmTQWjm15hqjdX4+TqDQF9rK38bynp88z
trjeNTZrIaLxrmDTSc4ycNqXxm0L9rS5u7hiGZJypbLeQcH2gOxanp+JVfQBIhnALEU4LFhNFBac
o66hUThJsktK5WOjKB3jlvuqMhpuvH5rwBGf5fkPDjsCV0J5ET4C2ZC4aOl/Q0uvOz583uxDApbi
ZwjWaEXplvK30dGjryi73Wmwgo9FkejWoN+iob3MBR8fxVorC8sULCtlEQQ/NsQ9qG5oK2UiStHS
ogVNPmZo/qaxzVj2RyF0OAVrVTTKUcLqbMOhr21AivLFx1esAQgFT4ah2Zdj77g2l3LeG1JxauwC
BpAknCJuDFnAx2qlIn1DPB8T9wwD74Cz7vimY74P0l6a/VsaSMe36geV+D4RLX0TlNvLB0dgs6WP
wcd+g4IfJPHLuFd8Cht/owgOWzltinWtIpRpkQf92BD3aSHRdiHLWrktlAfPV6F7Q8/DR5HTy0k+
z9PzGPUEP34J+Q4AAP//AwBQSwMEFAAGAAgAAAAhABg6Wmw8AQAAWQIAABEACAFkb2NQcm9wcy9j
b3JlLnhtbCCiBAEooAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJSSzU7DMBCE70i8Q+R7
4jgFVKwklQD1RCUkioq4Wfa2tYgdyzZN+/Y4Pw1B5cLRO7Pfzq6cL46qig5gnax1gUiSogg0r4XU
uwK9rZfxHEXOMy1YVWso0AkcWpTXVzk3lNcWXmxtwHoJLgok7Sg3Bdp7byjGju9BMZcEhw7itraK
+fC0O2wY/2Q7wFma3mEFngnmGW6BsRmJaEAKPiLNl606gOAYKlCgvcMkIfjH68Eq92dDp0ycSvqT
CTsNcadswXtxdB+dHI1N0yTNrIsR8hP8vnp+7VaNpW5vxQGVueCUW2C+tuW+OmQ5nhTa41XM+VW4
81aCeDgNnst64HSxexiIKAShfeyzspk9Pq2XqMxSQmKSxYSsyS0l9zQlH+3YX/1tsL6ghuH/Id7M
J8QzoMzxxWcovwEAAP//AwBQSwECLQAUAAYACAAAACEAfGyYFmwBAACgBQAAEwAAAAAAAAAAAAAA
AAAAAAAAW0NvbnRlbnRfVHlwZXNdLnhtbFBLAQItABQABgAIAAAAIQC1VTAj9QAAAEwCAAALAAAA
AAAAAAAAAAAAAKUDAABfcmVscy8ucmVsc1BLAQItABQABgAIAAAAIQDeCf0oAgEAANQDAAAaAAAA
AAAAAAAAAAAAAMsGAAB4bC9fcmVscy93b3JrYm9vay54bWwucmVsc1BLAQItABQABgAIAAAAIQAw
MsWFYgEAAHECAAAPAAAAAAAAAAAAAAAAAA0JAAB4bC93b3JrYm9vay54bWxQSwECLQAUAAYACAAA
ACEA+2KlbZQGAACnGwAAEwAAAAAAAAAAAAAAAACcCgAAeGwvdGhlbWUvdGhlbWUxLnhtbFBLAQIt
ABQABgAIAAAAIQDCwSunegEAAKICAAAYAAAAAAAAAAAAAAAAAGERAAB4bC93b3Jrc2hlZXRzL3No
ZWV0Mi54bWxQSwECLQAUAAYACAAAACEAwsErp3oBAACiAgAAGAAAAAAAAAAAAAAAAAAREwAAeGwv
d29ya3NoZWV0cy9zaGVldDMueG1sUEsBAi0AFAAGAAgAAAAhAHQvsEDKCQAABSUAABgAAAAAAAAA
AAAAAAAAwRQAAHhsL3dvcmtzaGVldHMvc2hlZXQxLnhtbFBLAQItABQABgAIAAAAIQBmnSOEJgEA
AHACAAAUAAAAAAAAAAAAAAAAAMEeAAB4bC9zaGFyZWRTdHJpbmdzLnhtbFBLAQItABQABgAIAAAA
IQCpxHlInAYAAF8zAAANAAAAAAAAAAAAAAAAABkgAAB4bC9zdHlsZXMueG1sUEsBAi0AFAAGAAgA
AAAhAIzcIoaeAQAAWAMAABAAAAAAAAAAAAAAAAAA4CYAAGRvY1Byb3BzL2FwcC54bWxQSwECLQAU
AAYACAAAACEAGDpabDwBAABZAgAAEQAAAAAAAAAAAAAAAAC0KQAAZG9jUHJvcHMvY29yZS54bWxQ
SwUGAAAAAAwADAAMAwAAJywAAAAA

--_002_C10D3FB0CD45994C8A51FEC1227CE22F39412A99CEshsmsx502ccrc_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--_002_C10D3FB0CD45994C8A51FEC1227CE22F39412A99CEshsmsx502ccrc_--


From xen-devel-bounces@lists.xensource.com Tue Dec 20 09:55:22 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 Dec 2011 09:55:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RcwPS-0000Fz-DF; Tue, 20 Dec 2011 09:54:58 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RcwPQ-0000Fu-BY
	for xen-devel@lists.xensource.com; Tue, 20 Dec 2011 09:54:56 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1324374890!7900887!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzQwMQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 884 invoked from network); 20 Dec 2011 09:54:50 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Dec 2011 09:54:50 -0000
X-IronPort-AV: E=Sophos;i="4.71,381,1320624000"; 
   d="scan'208";a="9572560"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Dec 2011 09:54:50 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 20 Dec 2011 09:54:49 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: =?UTF-8?Q?=C2=A4=3FK=E6=96=BCaware?= <250716708@qq.com>
Date: Tue, 20 Dec 2011 09:54:49 +0000
In-Reply-To: <tencent_3D9457AB2ED114DE7CC8600B@qq.com>
References: <tencent_3D9457AB2ED114DE7CC8600B@qq.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1324374889.23729.21.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] debuging about qemu-dm in xen-3.4.2
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gVHVlLCAyMDExLTEyLTIwIGF0IDA5OjE2ICswMDAwLCDCpD9L5pa8YXdhcmUgd3JvdGU6Cj4g
IAo+IEhpLAo+ICAgICBJIGFtIGEgbmV3ZXIgdG8gc3R1ZHkgcWVtdSBpbiB4ZW4sIAo+IEkgaGF2
ZSBubyBpZGVhIGhvdyB0byBkZWJ1ZyBhbmQgdHJhY2UgdGhlIHFlbXUtZG0gZWZmaWNpZW50bHku
CgpQbGVhc2UgcmVhZCBodHRwOi8vd2lraS54ZW4ub3JnL3dpa2kvQXNraW5nWGVuRGV2ZWxRdWVz
dGlvbnMgd2hpY2gKc2hvdWxkIGhlbHAgeW91IHRvIGZyYW1lIHlvdXIgcXVlc3Rpb24gaW4gYSB3
YXkgd2hpY2ggaXMgbGlrZWx5IHRvCmdhcm5lciByZXNwb25zZXMuCgozLjQuMiBpcyBxdWl0ZSBh
biBvbGQgdmVyc2lvbiBvZiBYZW4uIEkgc3VnZ2VzdCB5b3UgdGFyZ2V0IHNvbWV0aGluZwpuZXdl
ci4KCklhbi4KCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuc291cmNlLmNvbQpo
dHRwOi8vbGlzdHMueGVuc291cmNlLmNvbS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Tue Dec 20 09:55:22 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 Dec 2011 09:55:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RcwPS-0000Fz-DF; Tue, 20 Dec 2011 09:54:58 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RcwPQ-0000Fu-BY
	for xen-devel@lists.xensource.com; Tue, 20 Dec 2011 09:54:56 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1324374890!7900887!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzQwMQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 884 invoked from network); 20 Dec 2011 09:54:50 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Dec 2011 09:54:50 -0000
X-IronPort-AV: E=Sophos;i="4.71,381,1320624000"; 
   d="scan'208";a="9572560"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Dec 2011 09:54:50 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 20 Dec 2011 09:54:49 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: =?UTF-8?Q?=C2=A4=3FK=E6=96=BCaware?= <250716708@qq.com>
Date: Tue, 20 Dec 2011 09:54:49 +0000
In-Reply-To: <tencent_3D9457AB2ED114DE7CC8600B@qq.com>
References: <tencent_3D9457AB2ED114DE7CC8600B@qq.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1324374889.23729.21.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] debuging about qemu-dm in xen-3.4.2
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gVHVlLCAyMDExLTEyLTIwIGF0IDA5OjE2ICswMDAwLCDCpD9L5pa8YXdhcmUgd3JvdGU6Cj4g
IAo+IEhpLAo+ICAgICBJIGFtIGEgbmV3ZXIgdG8gc3R1ZHkgcWVtdSBpbiB4ZW4sIAo+IEkgaGF2
ZSBubyBpZGVhIGhvdyB0byBkZWJ1ZyBhbmQgdHJhY2UgdGhlIHFlbXUtZG0gZWZmaWNpZW50bHku
CgpQbGVhc2UgcmVhZCBodHRwOi8vd2lraS54ZW4ub3JnL3dpa2kvQXNraW5nWGVuRGV2ZWxRdWVz
dGlvbnMgd2hpY2gKc2hvdWxkIGhlbHAgeW91IHRvIGZyYW1lIHlvdXIgcXVlc3Rpb24gaW4gYSB3
YXkgd2hpY2ggaXMgbGlrZWx5IHRvCmdhcm5lciByZXNwb25zZXMuCgozLjQuMiBpcyBxdWl0ZSBh
biBvbGQgdmVyc2lvbiBvZiBYZW4uIEkgc3VnZ2VzdCB5b3UgdGFyZ2V0IHNvbWV0aGluZwpuZXdl
ci4KCklhbi4KCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuc291cmNlLmNvbQpo
dHRwOi8vbGlzdHMueGVuc291cmNlLmNvbS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Tue Dec 20 09:55:40 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 Dec 2011 09:55:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RcwPq-0000HF-Qq; Tue, 20 Dec 2011 09:55:22 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RcwPq-0000Gk-0v
	for xen-devel@lists.xensource.com; Tue, 20 Dec 2011 09:55:22 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1324374915!6044039!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzQwMQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30221 invoked from network); 20 Dec 2011 09:55:15 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Dec 2011 09:55:15 -0000
X-IronPort-AV: E=Sophos;i="4.71,381,1320624000"; 
   d="scan'208";a="9572573"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Dec 2011 09:55:14 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 20 Dec 2011 09:55:14 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jean Guyader <jean.guyader@gmail.com>
Date: Tue, 20 Dec 2011 09:55:14 +0000
In-Reply-To: <CAEBdQ92Oy6=EYYFG_KNMP6raq7S1e_195hFth1etMgpQWdGtsg@mail.gmail.com>
References: <CAOMqctShNFqe47w1orEPMCqvDORy5yxh=Gy33e02fyQYrz4nkw@mail.gmail.com>
	<20111219142943.GD27772@andromeda.dapyr.net>
	<CAOMqctSW87AmM8UTC34_ZwDhipnZUMmxyxiBix+EMAmi7hn1hg@mail.gmail.com>
	<20111219194324.GA29852@andromeda.dapyr.net>
	<1324373842.23729.16.camel@zakaz.uk.xensource.com>
	<CAEBdQ92Oy6=EYYFG_KNMP6raq7S1e_195hFth1etMgpQWdGtsg@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1324374914.23729.22.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Michal Suchanek <hramrach@centrum.cz>
Subject: Re: [Xen-devel] UDP checksums broken in Dom0 -> DomU vif transfer
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2011-12-20 at 09:43 +0000, Jean Guyader wrote:
> On 20 December 2011 10:37, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > The issue is that dom0 does checksum offload which means the checksum is
> > not valid on the domU end, although we know the packet is intact because
> > it never hit the wire.
> >
> > The network stack deals with this because skb->ip_summed is set
> > appropriately but when e.g. raw sockets are used it can ends up exposing
> > getting exposed to userspace.
> >
> > We don't want to do the checksum by default since there are performance
> > gains from avoiding it in the general case. Note that "tx off" turns of
> > TCP and UDP checksum offload.
> >
> > It's not clear where the bug is here, it could be a bug in dhclinet for
> > dropping the packet or perhaps this is something that raw socket driver
> > should be correcting (based on ip_summed) as the packet passes through
> > to userspace?
> >
> > I'm not sure but this might impact native hardware too -- depends on the
> > H/W's handling of the checksum field on RX, you'd hope they mostly just
> > leave it alone, but I'm not sure how e.g. LRO/GRO effects things?
> >
> 
> I've seen this issue in the past. I belive the bug is in dhclient.
> dhclient checks the checksum on the packets and drop them if it's wrong.

Indeed, googling around a bit shows that this dhclient bug affects more
than just Xen, e.g. virtio and even some native hardware appear to be
effected.

http://marc.info/?l=kvm&m=121882968407525&w=2
https://qa.mandriva.com/show_bug.cgi?id=63320
https://bugs.mageia.org/show_bug.cgi?id=1243
http://pkgs.fedoraproject.org/gitweb/?p=dhcp.git;a=blob_plain;f=dhcp-4.2.2-xen-checksum.patch;hb=HEAD

The OP didn't say what distro or version of dhclient he was using but I
think the right place to report this would be to the distro since it
appears to be using an out of date dhclient. In the meantime disabling
offload seems like a reasonable local workaround but it is not a fix we
should apply by default.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 20 09:55:40 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 Dec 2011 09:55:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RcwPq-0000HF-Qq; Tue, 20 Dec 2011 09:55:22 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RcwPq-0000Gk-0v
	for xen-devel@lists.xensource.com; Tue, 20 Dec 2011 09:55:22 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1324374915!6044039!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzQwMQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30221 invoked from network); 20 Dec 2011 09:55:15 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Dec 2011 09:55:15 -0000
X-IronPort-AV: E=Sophos;i="4.71,381,1320624000"; 
   d="scan'208";a="9572573"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Dec 2011 09:55:14 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 20 Dec 2011 09:55:14 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jean Guyader <jean.guyader@gmail.com>
Date: Tue, 20 Dec 2011 09:55:14 +0000
In-Reply-To: <CAEBdQ92Oy6=EYYFG_KNMP6raq7S1e_195hFth1etMgpQWdGtsg@mail.gmail.com>
References: <CAOMqctShNFqe47w1orEPMCqvDORy5yxh=Gy33e02fyQYrz4nkw@mail.gmail.com>
	<20111219142943.GD27772@andromeda.dapyr.net>
	<CAOMqctSW87AmM8UTC34_ZwDhipnZUMmxyxiBix+EMAmi7hn1hg@mail.gmail.com>
	<20111219194324.GA29852@andromeda.dapyr.net>
	<1324373842.23729.16.camel@zakaz.uk.xensource.com>
	<CAEBdQ92Oy6=EYYFG_KNMP6raq7S1e_195hFth1etMgpQWdGtsg@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1324374914.23729.22.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Michal Suchanek <hramrach@centrum.cz>
Subject: Re: [Xen-devel] UDP checksums broken in Dom0 -> DomU vif transfer
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2011-12-20 at 09:43 +0000, Jean Guyader wrote:
> On 20 December 2011 10:37, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > The issue is that dom0 does checksum offload which means the checksum is
> > not valid on the domU end, although we know the packet is intact because
> > it never hit the wire.
> >
> > The network stack deals with this because skb->ip_summed is set
> > appropriately but when e.g. raw sockets are used it can ends up exposing
> > getting exposed to userspace.
> >
> > We don't want to do the checksum by default since there are performance
> > gains from avoiding it in the general case. Note that "tx off" turns of
> > TCP and UDP checksum offload.
> >
> > It's not clear where the bug is here, it could be a bug in dhclinet for
> > dropping the packet or perhaps this is something that raw socket driver
> > should be correcting (based on ip_summed) as the packet passes through
> > to userspace?
> >
> > I'm not sure but this might impact native hardware too -- depends on the
> > H/W's handling of the checksum field on RX, you'd hope they mostly just
> > leave it alone, but I'm not sure how e.g. LRO/GRO effects things?
> >
> 
> I've seen this issue in the past. I belive the bug is in dhclient.
> dhclient checks the checksum on the packets and drop them if it's wrong.

Indeed, googling around a bit shows that this dhclient bug affects more
than just Xen, e.g. virtio and even some native hardware appear to be
effected.

http://marc.info/?l=kvm&m=121882968407525&w=2
https://qa.mandriva.com/show_bug.cgi?id=63320
https://bugs.mageia.org/show_bug.cgi?id=1243
http://pkgs.fedoraproject.org/gitweb/?p=dhcp.git;a=blob_plain;f=dhcp-4.2.2-xen-checksum.patch;hb=HEAD

The OP didn't say what distro or version of dhclient he was using but I
think the right place to report this would be to the distro since it
appears to be using an out of date dhclient. In the meantime disabling
offload seems like a reasonable local workaround but it is not a fix we
should apply by default.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 20 10:05:26 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 Dec 2011 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.xensource.com>)
	id 1RcwZH-0000fX-Bm; Tue, 20 Dec 2011 10:05:07 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1RcwZG-0000fS-BH
	for xen-devel@lists.xensource.com; Tue, 20 Dec 2011 10:05:06 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-4.tower-216.messagelabs.com!1324375499!8115404!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25553 invoked from network); 20 Dec 2011 10:04:59 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-4.tower-216.messagelabs.com with SMTP;
	20 Dec 2011 10:04:59 -0000
Received: from [62.94.181.91] (account d.faggioli@sssup.it HELO [192.168.0.20])
	by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 74042951; Tue, 20 Dec 2011 11:04:59 +0100
Message-ID: <1324375489.6616.7.camel@Abyss>
From: Dario Faggioli <raistlin@linux.it>
To: Jan Beulich <JBeulich@suse.com>
Date: Tue, 20 Dec 2011 11:04:49 +0100
In-Reply-To: <4EF0653C0200007800069123@nat28.tlf.novell.com>
References: <1324319661.2599.28.camel@Solace>
	<4EF0653C0200007800069123@nat28.tlf.novell.com>
Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwCAIAAADYYG7QAAAAA3NCSVQICAjb4U/gAAAVx0lEQVRYwzWY6a/d953XP9/tt51zfme/+37t692OtzhxtzTuJFPaTDVt0cDQeTIajToSKBJICBASQkI8Q1Q8ACQEhUGgCsF0OrSkaRLaxknqOl7i9dq++3727bd/Vx5k+CNe7+WFvvkvbvoywAZF1BMYOFNFbqWEW1gho42yB9jJq1QihEGVCh7BxrXpeNlxbJZmcmNvkArIhAIMJd+drlmA0aiXuBbN5x3Pxq6NS6X85l5/rxNnGtJYgAYhgVCa8UxqAwgQIABAGGMD1JWtS7/48Vy0W1k5GxXnmh41br1y6fxXv3LCEPXLu3vv3N3t2kXPAi0EIjTjnDGcKawzHceZl3N0mIExrmfnGS1iSij2pxgDxJhlsOFID8LUsVjecXvNPiJg2ZYySiODGUVcAwBCCAAMAIAhNc82C2xvuLG8uX422VvZfHrx9Mz5P7kRR51wby188YD+8metqQWBLa00F1JIlQk5imIhle+XBsHI9/PVUoFCBp7JOZbSjGiS92mx7IE0SICRkC/Yw2GSZECpIsYYwEmWGkDGIAAAAIQAY4QMEA6Nvc7G6aaYzKQlUs/x/O99VywsZcZd33w++l9/NbN6Z905MSqPGYO10QDYGCI1EIQQGMdzkzCo+G4pb5eY7blWKhKadiZ92yYsFWoYpwhRv0A4h/4oK5Zcl9nGAMLUgEYYMAZAmhBkM6KkoYpVIRjU47SRRUuVlXRlUZ08nxDyi50na+2jV1r9tTjK/DwYqgFRLHMuYdhCMou1bg64a0M15yKiCyCcLJlJspl+e6x3QNtuv1TbKIwHxpHIZDEYorGFh32eK3h+yc06XYqA2MyyLCmk0lobAFC04NsTyCGjOAbrp5svrs/N1sqeRegKscrF2aiz1ZfJweZPjLzojB0fdPcqFcv481592Y15KiKOLBDyd
	OPw1b37JZ3Qosdspk2Eh71iZ3MmJafLE/2l4w/pjBiiRMVJKjOtLItypb18LkxCmSilAIAorQCA0nLl0lGSqY5kyCP55bFpOwvW1vo79+7vb+z5yjSF1Wg9RaNNjKxRlObPnd/c+UurPFMZPzO5cPpcIt/c/HApaZp+Jzoa6FKhcu4kogzZFGmEGgczG6v1O+8uLp1eQ0VdOrXuLFqu0mAwwZkUCBOMmJAKDAIgAJq88f1/NucwtbZqaXP9pfNnFxY++ujmI4OZVzoYHfKtxnrY2PFAS46yuJTPNzvNYXvbDJsvTfr/5PSJl3/676cbhzvPV4ccbN9KTCoHHYa5xQoZRPpglw1SEim5tzN58KSc4b1LFzEmFiMEYwCSca01MsYAAoyRUYrGgjXOXfgbg8aE5hPV8vsPPr7XHJaPn4x6MY0GjsUWvnxy+dLSB7+43W6zN77y9Q/e/3ENvMvI/dO4WftX/xzidDvrO7Mnxqt+P0kshcCyRj2pe89zKSKxVjrWWKs4balUO/s26MwgqZU2JsmkUhjAAPpr0ACA3vjKydHuAa56B2u7Hz59qDFOkD149x1n9VkW81LevvCH54b5ztiY/+rLr7zxu1+TwdEr99deD0Ln1tMw4ixVhVpuemZGYT5W8JQCgyAMR1whY1IGqRI8E1ks0m2pnqq0k6ogUpgRroBLDQgjDBgTjAEUUgDUJI16Se7sbcWdfoxdzrRUwj7aV1I7165Mnjhx+oLz2+CTyclL3/2D74ApfOFr3w4Hf7778/dmSclIzoXKTy6n2QBrjRQyBPdGQ6RVlCQ8TXScMGk8iwWErsV8Z/58J9KZ0IgbBJgQiok2BghBCCFjMACQlesvrzjY/tWtOM0EoZwCU0Ym2ag+VZ5fLOf9xZXph61s8dibtdpYnApmFe3JmX6372UByfg+wKNOt+hYSgHBNjiesW3H9SyhqEKJlE2ZHiSjrVS2c8Xm639nhEoACAzGhDCGKSVKGQ
	AwBgECxQXNuz7uD1QvQFJEeeOm0iiFBbDu/uEzwW8O+P826hu/d6v0/PTx5Y8/ee/l66/lFqdqb9xQ//pRJ+KBwfmp8U1tmkgnXqaxbPd6/V4fJ1kJ6JQhderZ1OvE/aYSfeKBAYSQQVgbI5Q2UgMgBMgYAxgBAE1U6uQKuS9e7310qzwQ2pDUghR4JU3UZji07BfFamHtIF00O839zx7ceeXaFxGY/J1Hz1sHPEGHDlnTreLkyeNXrpQLDgjtBHF+GI6i4VEYfnpwpAejvNBnUdG2qkBdw4w2Bhv0eXeZzwMfIYQ+7zKgc7VynCux73176ktXV//ix6Onq67RxIhEGTDSHybQH4Xt6LU3317f2pycmGJUVxudOZ+o6Zn764dB0YHx6dCwp88eIYSIxpLLIIziLJbSOAKEW9QlZ7Posijv5awsSw1yDMIAGMAgZBBCGGNjDEJGAdCJnI9thwHLFr3pt9+e3Wl2W41fbj1NlD51sHvmxeP1YfqMya9fvfaf//E/3T/cfPP6K8vv3Wz/3w/SxiBPaDFUeGZ6V2Sd7UOtACmkpeRSaI0wMogZYzNk05KfG5Z8q5a9bBeaA90P0kRixGyuPqddY4wwQgKAFosVQjEANjF1lFIz4/1x50g0kyR+uVi79jtf/vmHL4LKhZ7WreYWMbH5b/8zu3vHGkUZlxjrSOkzy/Px/n5fYxAxNUCNIdhIojEhmDFM3By2sWdJNlajeKmUnqiwQNuRZJ0I398LDVBkABPABgEA7o/CMEhlplzHKlZL1WJVY4LB5Ci6+p2rvRv1uxm8evba/Qe/UaPuDUEXP/kNTdJewqtV/+zlK9yQnfWtdrsVp+koEWEmpQELUwcTqrGMVZpEiUqVU43PflUzLR2pbFqkenncKniZsRNjcaAcocRmGQBQh1kIISmllJLrbG/3oCujE7PHahYo8eDu46fUqawsLzx4+vEZN/eHQcJHyVBjz5DqsYWOwDm/nmP52TF
	vY79x1O4bKcp5b7JWIQoNklRhYhvKjBkfCrf3xJ7+ijVKo+TAsQuO4wKlDsMGpRRjlYm8U+wBp57jWrYlpFRKGa7G56b/4i//x0Hj4OKU9/03Tj3e3BuvFvP1QhJmf2Zcuz/UhGiNWK3a7US8Ovvaq7/zcXenmfWqrmdKpTRLGCO9KELGhJmIOHcZLY9XGo3BBTrUJxuzCtJ8refnuDY6EwRjbaRnA3OxjQ0AUK2U4EIZrYw2gIYyzVQyNV48e9wzRt6729p5sl+2ci8/+Gy80x5hMFIBsZOyf4TIrC4Uld05bChP+kpZNo4RywAERgyTPCJgO1bBmfALzb3B5msXrg0UqxaG5QJgy0UMrIxYjAhHZ4HtJVW3uAaCUkYNGAxGKYkBd/pNC2AizxYq/LPHn9hWfb4eFxob59cakhpXmIaCnGu9u7td9MdajTsvnbxAmY94YEFojOEGEcYQAYSY4VEx79J8QQ+yiPlBFq/aE1Gt7BmTwwo7jh5wjDlxGDWKMGKMAgBsW45t2TazGWHI0hs7G1oJIgavXjmTCKcXwJeuXsv+zwexyhLmxoRix3rEUAv0++3tDweHdzafvlZfxH6RS8cYAkAPW/0Xe612t2sAwNC0nz67t+rmcgEPW82+yEgqdZImo2Gnfbge9p6AaliuGsUj5lAAoJQxKYUCDYAEhkEYFPzCXA0q9eLme0m7K6auTgUf3ynYrCzprhJHBSdYnLX3jvSoNwrMzfbW7Y9aIaCwQMHlOS83XvWTRGDLihCkoyTujpiiBAOSYTKAOAjdXAFjLGTWae0/W3skwa3WJiYnpse9BQCgwyhCCAhBwOgoDErVCd1tLc2ge4+fBKHDjJk/fsrR76BhHBoIy6VoeSlFEmxKHNpN0rGJqbDbV9KwgWj3IlWQhGGlTXuUacvKMxtJhA3oLGZJL+Nht1M/eeZaq90wGDtu7tj8cYUsIU3J8yzKAAQVimdSICmlUQ93Xxw1W8cnxhYW
	wkKhY/C8X+ufq891Wy3P4Nsg26eWolx9dLC9P+wpZBKbNnv9AiGWlipNXEP1gGNKjJIFg0lmLJOWmS2UylMU91qWXw663X4nUAYjkNRxX9zd0oj4lclykTNCAIDatqORMVpJhNY21raP9lS0+bdeWd7ePXr8wlqaXiK//qDX3P20Nr41tZASRtSwhSRCUHVsZkO3F9qkgFKJDC4QprRSmcgTSjHFBjEwjtR5hEm7xxzmunkZhL1Od2F5th+2DQJDqF2ezo8vAcbUpABAkyTjUhjJRzrRQe9CsXj9st0ZbDVeDK8M7b+Nk+7qnaevfvVAC8G5ATTx2mtLRt7+d/+WpKHrWEnRO2gPxqUtMU4UV0bbzMKISCmBIKAUAGyAzvZWrmjZ1SJS/OHde/MzE2OVeqHgX3n5qnLHO/3UIO55GAAoF0pppbTuBoOEGkqsGqPXotlLvUp1pto8ffGdXuPFbz+lsSL5YovoW+++c2q8rmyLaocinCN6VLaToZFcYoM0xpHiHFAOU8aIBpAAgFEmZNLpmFpJsk5hciYeDmsTi/fuf7bX2auWx0rjc47v7j2+BXCRUoK4QQDQaB0Zg7SRhVSxx0NfzHWPrzxfXlj76EObxxqhv1p7fOLiJd8Ujp890z46HG5tGNAIKdtloRCJUjnMMAKsMEK4RbhCAhuMElkkdozAjIb5YZToZiDM5XNntQ2u5VKtGzsbe/tbpXye1SbBvkgJAMVYEzIajTyEj83YQ7/104Xhb37WvLGwEm3shUnAMhUiM1AZz9KjVmtydrpFCAeFMaYWtQBpn0mtBpkCpZAFiGLm2KAhHaY5REEjhJUDhAcxx05hLBcnaa1UKjALE+aVqpHIJienbBAAgEt+frxURBZRBkOuNF2lC2P4fif7JXa2uD7Y3+VxQlO5GwfMyecK+Xq1WB8b6yaBJEhqhRBGGGML56s+rnhW3XeqBavoEERFkFmAkdIIQR4wjlMRxx5zUgG3769qo
	U7MzLS7w04QGcs2zPbLPgDg3qAXh8PV7fXEoPm5xWIt543nRe585djS1vN7+MXDwfZGe9Dc63XSRBwcNOIoAgQjkQqGhdGAkNEaaUW0ylnUw9g1BIdKdsK8op4hNiUSa8VFvVI5ff6sSFOG2YOnG0kii26+6BeJxbjRSZpg1wMAbDMgFjxZvb+/u/X81ntJZysYos7hcNbLjy1MPtp6gkbdqD+oF6vFSs3NeTNT04NePwQtsNZAldYGIaUUaIkkRxrCME0GSQk7HmCiDQWEAQMCGcYXjh2zjQShohiGcXb1pQvH5ueLOafgOkaK2bEiAFDFZTcc2CpayMPSWO3kUn5zbXtwNNjfffTW3/9Hd29+mISBkWRhYf7333xzZqKUBaNOp9/ziqUgwSBSJGxqy0xrYUAZLkUUpXVs5zHJQEstkAFsMGNOOgiS++s05AiACp7G8Vi1xMPk5LFjbrGUQzA3UYOHQA1mz7e3D1qDAtNTp+cZNd2B+NaXvtjvqGrRs4pETXuHR73NezcDHTsMX7n2ansYzc2drnO7K5+vzEwqrtf3okAbkxgeZyCMTy0bUY1U9v/FmMUoaHPc5LOZY7/urk9Yo3H2eu+ou1ir/urxqtHZialp98wUAGAA9XhrPaH+SJPKhB+lfL2de//uemblk0hcml34g7feOHN+5eyZk6eXpoP2YaXsdzdXv3ugb9SXSi75va9d+4f/4I+/89aNotb9ILYFnrYLHsYUAUMYGQAD1CCCSd0tfPrg/hwH0ttctgN7dDjGu0sOdqmZKlvnj88SpAGAPtnYyESKVFTP8Zw16rUOW116FOPr5fqz7b2fP36hP+7zWAkplxdmEUEF1748O/7wg59MaOv7J065NzcOnrW8nKeo48lwxStSLi3QgCkiaATYGMMMgNG1QmlfxxO9Xtn1Ro2+UnDz5z+LgzTP0Hgtl7MhzmIAwI/XVgNBAqNXTh2v5Mwwg3Z3wEfJ7OxyHHPb9SNuEi
	64Ed1RmAjm58rbHz85qdCfzi2fHfH67sj+6EX6s0/hoPvW5Mmq5MwimlCikUXtIYOYIYWUz1impU75ve6WzeHK+OKf/+AHYchVKuJRsLrTfHHY6A77AEAnZ6bBXc6ePj+1UOmPntxfkx3t5yzI5Uu7e3sYEDKmXirisisJnqxPH7Q68aD3rYVllkQJF6GUsRQmiE4j9/Wpkz9tHhGtDSUKACgOmcmQdhS1LDvLMoOwjJJ4d/ir4cfP0qaA23pxWc5N0FKhnQiLMQCgFceSFl24dPwLF4s/efe2P3llmoAbB5ZLw3gYxFE/jkdZNl8udA47KyunB72jb1Qn7c5gmGVcqJTzkVbAzY1TV89fvHR398nBYMgNikD5mhSQHWJuXM/OFaJhKLHhowAIWfjGl7b3nwbx8Nw3f9cCEDJjXAeDEQCQOGjFRzsny8FkRe43i0+fH2jIn5qZkxG/fft+rlDNlSYzxOanZxuj/hfPnLu+erCyvquSmKd6oOORkoMw+VTEb37hm6oXzdq5o2DU0akUMnbJhhgUHHeCelRBnGXDLAGDLMcrvHJ58dtvfXC4tdntCQG+bU/MTPl8sD5cIlMztSAOvvX6ceJEO3tHn7z3JG20XJleu3w1ToPdvQ0j+GS9/vWv3Xjl1Onru935W59ClnZGQ4sxi7FA8N+OBs8QOZqvD20z7fpoGDbikIMwMiNSlRG1DVWZiHiCCHUtG1vW+T/6fXDtrfZRnGSDqN8bdMbLpaS909EXaYBYKafPXl367PH9nd0gzTRRoWPnKWJ/81vfPnNy5Yc//OGt28/nHHhjoz03AD4cZdgUixULcJylFnZ7AOlYuXjj5R/9x//033cPr1VnRjKyLUtkkRYyFIJDUsv5DsWI0ZFUr/2977Gx+iCJDnu9IAgRNYVqaTjomFEEOaA2QV//8qLD0t2do62dWChIs2R8cqbgl0DJ4/NLb//dtzvd7kub2xceHQUqjJDqRmHQjQuOqyn
	ZiaKpyoRz4wuXzr70/MTyi8bR+72NEqPVTGL4a1NvIQRK5Cw3MDBz+RI6tpAAhJIzy65WEGOEYEhF5iv6+VE0F05P+f7Ui61Od4iV1hb1p6amM5USQFoh368t5IvjP/m1ylIuJAhFCGXMotQyjGCbbzX39p88Pvyv/8V2XZT3yED2sHYskteYCcIwBg0DwTVzZLkQ1XyTSuvzgUCpEglFVGMMmNSrzpEAim310sWX7j5ZI9Zc5/ARF6w651dqVSllKIWJhxF3is9XaaPNNOQsBkAdLRLCNMbNLBYGIbcgbdJu7iEpjO+aOE45fxIPl73SuFeORBpgaSwmPUp8ZutU89S1LRwazKgyFkLYY7bHnIXp4sNtoCtLtYnx8n/40Y+2d5U21PfL/+YH/5JqY7v5Ti950DksKlV4+CQnpaY441xzJUBigjMpM6N247ANOGKUKAnaOPliRILBsJ8geDDq1ZhjuzatFsMoKlBdMUbE8aDfY5S5tnvp8pWUZzzL0iR2bdbpHALA/wMUjQteOh3xIgAAAABJRU5ErkJggg==
X-Mailer: Evolution 3.2.2 (3.2.2-1.fc16) 
Mime-Version: 1.0
Cc: Wei Wang2 <wei.wang2@amd.com>, Tim Deegan <tim@xen.org>,
	xen-devel@lists.xensource.com,
	"allen.m.kay@intel.com" <allen.m.kay@intel.com>
Subject: Re: [Xen-devel] [PATCH 0 of 3] Deal with IOMMU faults in softirq
	context.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3580274337533879484=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--===============3580274337533879484==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-xrJnvLiDHt/Q8QaLsiJ5"


--=-xrJnvLiDHt/Q8QaLsiJ5
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, 2011-12-20 at 09:36 +0000, Jan Beulich wrote:=20
> These look good to me (apart from a minor indentation issue in the
> 2nd patch),
>
Oh, you mean those 3 spaces instead of 4 within
do_amd_iommu_page_fault()? I've no idea of how that could have happened
and will fix that, thanks.

If that's fine I'll wait a bit more to see if other reviews pop up and
then resubmit the series.

> but we'd surely like to have an ack from the respective
> maintainers.
>
Ok... Do I Cc-ed them correctly? :-)

> Also, despite the subject here, I suppose the series
> consists of just two patches?
>=20
It does, that '0 of 3' was just another silly mistake from myself. I
promise this will be the last one! :-)

> Thanks for doing this!
>=20
Thanks to you for having looked at it.
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-------------------------------------------------------------------
Dario Faggioli, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
PhD Candidate, ReTiS Lab, Scuola Superiore Sant'Anna, Pisa (Italy)



--=-xrJnvLiDHt/Q8QaLsiJ5
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEABECAAYFAk7wXcEACgkQk4XaBE3IOsSGpgCgnqYhATe5R9zy3rbyXOhtzvN9
cq0AnAyVg3tYAFRjgUwS4RP4539Koo+X
=kgS6
-----END PGP SIGNATURE-----

--=-xrJnvLiDHt/Q8QaLsiJ5--



--===============3580274337533879484==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============3580274337533879484==--



From xen-devel-bounces@lists.xensource.com Tue Dec 20 10:05:26 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 Dec 2011 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.xensource.com>)
	id 1RcwZH-0000fX-Bm; Tue, 20 Dec 2011 10:05:07 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1RcwZG-0000fS-BH
	for xen-devel@lists.xensource.com; Tue, 20 Dec 2011 10:05:06 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-4.tower-216.messagelabs.com!1324375499!8115404!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25553 invoked from network); 20 Dec 2011 10:04:59 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-4.tower-216.messagelabs.com with SMTP;
	20 Dec 2011 10:04:59 -0000
Received: from [62.94.181.91] (account d.faggioli@sssup.it HELO [192.168.0.20])
	by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 74042951; Tue, 20 Dec 2011 11:04:59 +0100
Message-ID: <1324375489.6616.7.camel@Abyss>
From: Dario Faggioli <raistlin@linux.it>
To: Jan Beulich <JBeulich@suse.com>
Date: Tue, 20 Dec 2011 11:04:49 +0100
In-Reply-To: <4EF0653C0200007800069123@nat28.tlf.novell.com>
References: <1324319661.2599.28.camel@Solace>
	<4EF0653C0200007800069123@nat28.tlf.novell.com>
Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwCAIAAADYYG7QAAAAA3NCSVQICAjb4U/gAAAVx0lEQVRYwzWY6a/d953XP9/tt51zfme/+37t692OtzhxtzTuJFPaTDVt0cDQeTIajToSKBJICBASQkI8Q1Q8ACQEhUGgCsF0OrSkaRLaxknqOl7i9dq++3727bd/Vx5k+CNe7+WFvvkvbvoywAZF1BMYOFNFbqWEW1gho42yB9jJq1QihEGVCh7BxrXpeNlxbJZmcmNvkArIhAIMJd+drlmA0aiXuBbN5x3Pxq6NS6X85l5/rxNnGtJYgAYhgVCa8UxqAwgQIABAGGMD1JWtS7/48Vy0W1k5GxXnmh41br1y6fxXv3LCEPXLu3vv3N3t2kXPAi0EIjTjnDGcKawzHceZl3N0mIExrmfnGS1iSij2pxgDxJhlsOFID8LUsVjecXvNPiJg2ZYySiODGUVcAwBCCAAMAIAhNc82C2xvuLG8uX422VvZfHrx9Mz5P7kRR51wby188YD+8metqQWBLa00F1JIlQk5imIhle+XBsHI9/PVUoFCBp7JOZbSjGiS92mx7IE0SICRkC/Yw2GSZECpIsYYwEmWGkDGIAAAAIQAY4QMEA6Nvc7G6aaYzKQlUs/x/O99VywsZcZd33w++l9/NbN6Z905MSqPGYO10QDYGCI1EIQQGMdzkzCo+G4pb5eY7blWKhKadiZ92yYsFWoYpwhRv0A4h/4oK5Zcl9nGAMLUgEYYMAZAmhBkM6KkoYpVIRjU47SRRUuVlXRlUZ08nxDyi50na+2jV1r9tTjK/DwYqgFRLHMuYdhCMou1bg64a0M15yKiCyCcLJlJspl+e6x3QNtuv1TbKIwHxpHIZDEYorGFh32eK3h+yc06XYqA2MyyLCmk0lobAFC04NsTyCGjOAbrp5svrs/N1sqeRegKscrF2aiz1ZfJweZPjLzojB0fdPcqFcv481592Y15KiKOLBDyd
	OPw1b37JZ3Qosdspk2Eh71iZ3MmJafLE/2l4w/pjBiiRMVJKjOtLItypb18LkxCmSilAIAorQCA0nLl0lGSqY5kyCP55bFpOwvW1vo79+7vb+z5yjSF1Wg9RaNNjKxRlObPnd/c+UurPFMZPzO5cPpcIt/c/HApaZp+Jzoa6FKhcu4kogzZFGmEGgczG6v1O+8uLp1eQ0VdOrXuLFqu0mAwwZkUCBOMmJAKDAIgAJq88f1/NucwtbZqaXP9pfNnFxY++ujmI4OZVzoYHfKtxnrY2PFAS46yuJTPNzvNYXvbDJsvTfr/5PSJl3/676cbhzvPV4ccbN9KTCoHHYa5xQoZRPpglw1SEim5tzN58KSc4b1LFzEmFiMEYwCSca01MsYAAoyRUYrGgjXOXfgbg8aE5hPV8vsPPr7XHJaPn4x6MY0GjsUWvnxy+dLSB7+43W6zN77y9Q/e/3ENvMvI/dO4WftX/xzidDvrO7Mnxqt+P0kshcCyRj2pe89zKSKxVjrWWKs4balUO/s26MwgqZU2JsmkUhjAAPpr0ACA3vjKydHuAa56B2u7Hz59qDFOkD149x1n9VkW81LevvCH54b5ztiY/+rLr7zxu1+TwdEr99deD0Ln1tMw4ixVhVpuemZGYT5W8JQCgyAMR1whY1IGqRI8E1ks0m2pnqq0k6ogUpgRroBLDQgjDBgTjAEUUgDUJI16Se7sbcWdfoxdzrRUwj7aV1I7165Mnjhx+oLz2+CTyclL3/2D74ApfOFr3w4Hf7778/dmSclIzoXKTy6n2QBrjRQyBPdGQ6RVlCQ8TXScMGk8iwWErsV8Z/58J9KZ0IgbBJgQiok2BghBCCFjMACQlesvrzjY/tWtOM0EoZwCU0Ym2ag+VZ5fLOf9xZXph61s8dibtdpYnApmFe3JmX6372UByfg+wKNOt+hYSgHBNjiesW3H9SyhqEKJlE2ZHiSjrVS2c8Xm639nhEoACAzGhDCGKSVKGQ
	AwBgECxQXNuz7uD1QvQFJEeeOm0iiFBbDu/uEzwW8O+P826hu/d6v0/PTx5Y8/ee/l66/lFqdqb9xQ//pRJ+KBwfmp8U1tmkgnXqaxbPd6/V4fJ1kJ6JQhderZ1OvE/aYSfeKBAYSQQVgbI5Q2UgMgBMgYAxgBAE1U6uQKuS9e7310qzwQ2pDUghR4JU3UZji07BfFamHtIF00O839zx7ceeXaFxGY/J1Hz1sHPEGHDlnTreLkyeNXrpQLDgjtBHF+GI6i4VEYfnpwpAejvNBnUdG2qkBdw4w2Bhv0eXeZzwMfIYQ+7zKgc7VynCux73176ktXV//ix6Onq67RxIhEGTDSHybQH4Xt6LU3317f2pycmGJUVxudOZ+o6Zn764dB0YHx6dCwp88eIYSIxpLLIIziLJbSOAKEW9QlZ7Posijv5awsSw1yDMIAGMAgZBBCGGNjDEJGAdCJnI9thwHLFr3pt9+e3Wl2W41fbj1NlD51sHvmxeP1YfqMya9fvfaf//E/3T/cfPP6K8vv3Wz/3w/SxiBPaDFUeGZ6V2Sd7UOtACmkpeRSaI0wMogZYzNk05KfG5Z8q5a9bBeaA90P0kRixGyuPqddY4wwQgKAFosVQjEANjF1lFIz4/1x50g0kyR+uVi79jtf/vmHL4LKhZ7WreYWMbH5b/8zu3vHGkUZlxjrSOkzy/Px/n5fYxAxNUCNIdhIojEhmDFM3By2sWdJNlajeKmUnqiwQNuRZJ0I398LDVBkABPABgEA7o/CMEhlplzHKlZL1WJVY4LB5Ci6+p2rvRv1uxm8evba/Qe/UaPuDUEXP/kNTdJewqtV/+zlK9yQnfWtdrsVp+koEWEmpQELUwcTqrGMVZpEiUqVU43PflUzLR2pbFqkenncKniZsRNjcaAcocRmGQBQh1kIISmllJLrbG/3oCujE7PHahYo8eDu46fUqawsLzx4+vEZN/eHQcJHyVBjz5DqsYWOwDm/nmP52TF
	vY79x1O4bKcp5b7JWIQoNklRhYhvKjBkfCrf3xJ7+ijVKo+TAsQuO4wKlDsMGpRRjlYm8U+wBp57jWrYlpFRKGa7G56b/4i//x0Hj4OKU9/03Tj3e3BuvFvP1QhJmf2Zcuz/UhGiNWK3a7US8Ovvaq7/zcXenmfWqrmdKpTRLGCO9KELGhJmIOHcZLY9XGo3BBTrUJxuzCtJ8refnuDY6EwRjbaRnA3OxjQ0AUK2U4EIZrYw2gIYyzVQyNV48e9wzRt6729p5sl+2ci8/+Gy80x5hMFIBsZOyf4TIrC4Uld05bChP+kpZNo4RywAERgyTPCJgO1bBmfALzb3B5msXrg0UqxaG5QJgy0UMrIxYjAhHZ4HtJVW3uAaCUkYNGAxGKYkBd/pNC2AizxYq/LPHn9hWfb4eFxob59cakhpXmIaCnGu9u7td9MdajTsvnbxAmY94YEFojOEGEcYQAYSY4VEx79J8QQ+yiPlBFq/aE1Gt7BmTwwo7jh5wjDlxGDWKMGKMAgBsW45t2TazGWHI0hs7G1oJIgavXjmTCKcXwJeuXsv+zwexyhLmxoRix3rEUAv0++3tDweHdzafvlZfxH6RS8cYAkAPW/0Xe612t2sAwNC0nz67t+rmcgEPW82+yEgqdZImo2Gnfbge9p6AaliuGsUj5lAAoJQxKYUCDYAEhkEYFPzCXA0q9eLme0m7K6auTgUf3ynYrCzprhJHBSdYnLX3jvSoNwrMzfbW7Y9aIaCwQMHlOS83XvWTRGDLihCkoyTujpiiBAOSYTKAOAjdXAFjLGTWae0/W3skwa3WJiYnpse9BQCgwyhCCAhBwOgoDErVCd1tLc2ge4+fBKHDjJk/fsrR76BhHBoIy6VoeSlFEmxKHNpN0rGJqbDbV9KwgWj3IlWQhGGlTXuUacvKMxtJhA3oLGZJL+Nht1M/eeZaq90wGDtu7tj8cYUsIU3J8yzKAAQVimdSICmlUQ93Xxw1W8cnxhYW
	wkKhY/C8X+ufq891Wy3P4Nsg26eWolx9dLC9P+wpZBKbNnv9AiGWlipNXEP1gGNKjJIFg0lmLJOWmS2UylMU91qWXw663X4nUAYjkNRxX9zd0oj4lclykTNCAIDatqORMVpJhNY21raP9lS0+bdeWd7ePXr8wlqaXiK//qDX3P20Nr41tZASRtSwhSRCUHVsZkO3F9qkgFKJDC4QprRSmcgTSjHFBjEwjtR5hEm7xxzmunkZhL1Od2F5th+2DQJDqF2ezo8vAcbUpABAkyTjUhjJRzrRQe9CsXj9st0ZbDVeDK8M7b+Nk+7qnaevfvVAC8G5ATTx2mtLRt7+d/+WpKHrWEnRO2gPxqUtMU4UV0bbzMKISCmBIKAUAGyAzvZWrmjZ1SJS/OHde/MzE2OVeqHgX3n5qnLHO/3UIO55GAAoF0pppbTuBoOEGkqsGqPXotlLvUp1pto8ffGdXuPFbz+lsSL5YovoW+++c2q8rmyLaocinCN6VLaToZFcYoM0xpHiHFAOU8aIBpAAgFEmZNLpmFpJsk5hciYeDmsTi/fuf7bX2auWx0rjc47v7j2+BXCRUoK4QQDQaB0Zg7SRhVSxx0NfzHWPrzxfXlj76EObxxqhv1p7fOLiJd8Ujp890z46HG5tGNAIKdtloRCJUjnMMAKsMEK4RbhCAhuMElkkdozAjIb5YZToZiDM5XNntQ2u5VKtGzsbe/tbpXye1SbBvkgJAMVYEzIajTyEj83YQ7/104Xhb37WvLGwEm3shUnAMhUiM1AZz9KjVmtydrpFCAeFMaYWtQBpn0mtBpkCpZAFiGLm2KAhHaY5REEjhJUDhAcxx05hLBcnaa1UKjALE+aVqpHIJienbBAAgEt+frxURBZRBkOuNF2lC2P4fif7JXa2uD7Y3+VxQlO5GwfMyecK+Xq1WB8b6yaBJEhqhRBGGGML56s+rnhW3XeqBavoEERFkFmAkdIIQR4wjlMRxx5zUgG3769qo
	U7MzLS7w04QGcs2zPbLPgDg3qAXh8PV7fXEoPm5xWIt543nRe585djS1vN7+MXDwfZGe9Dc63XSRBwcNOIoAgQjkQqGhdGAkNEaaUW0ylnUw9g1BIdKdsK8op4hNiUSa8VFvVI5ff6sSFOG2YOnG0kii26+6BeJxbjRSZpg1wMAbDMgFjxZvb+/u/X81ntJZysYos7hcNbLjy1MPtp6gkbdqD+oF6vFSs3NeTNT04NePwQtsNZAldYGIaUUaIkkRxrCME0GSQk7HmCiDQWEAQMCGcYXjh2zjQShohiGcXb1pQvH5ueLOafgOkaK2bEiAFDFZTcc2CpayMPSWO3kUn5zbXtwNNjfffTW3/9Hd29+mISBkWRhYf7333xzZqKUBaNOp9/ziqUgwSBSJGxqy0xrYUAZLkUUpXVs5zHJQEstkAFsMGNOOgiS++s05AiACp7G8Vi1xMPk5LFjbrGUQzA3UYOHQA1mz7e3D1qDAtNTp+cZNd2B+NaXvtjvqGrRs4pETXuHR73NezcDHTsMX7n2ansYzc2drnO7K5+vzEwqrtf3okAbkxgeZyCMTy0bUY1U9v/FmMUoaHPc5LOZY7/urk9Yo3H2eu+ou1ir/urxqtHZialp98wUAGAA9XhrPaH+SJPKhB+lfL2de//uemblk0hcml34g7feOHN+5eyZk6eXpoP2YaXsdzdXv3ugb9SXSi75va9d+4f/4I+/89aNotb9ILYFnrYLHsYUAUMYGQAD1CCCSd0tfPrg/hwH0ttctgN7dDjGu0sOdqmZKlvnj88SpAGAPtnYyESKVFTP8Zw16rUOW116FOPr5fqz7b2fP36hP+7zWAkplxdmEUEF1748O/7wg59MaOv7J065NzcOnrW8nKeo48lwxStSLi3QgCkiaATYGMMMgNG1QmlfxxO9Xtn1Ro2+UnDz5z+LgzTP0Hgtl7MhzmIAwI/XVgNBAqNXTh2v5Mwwg3Z3wEfJ7OxyHHPb9SNuEi
	64Ed1RmAjm58rbHz85qdCfzi2fHfH67sj+6EX6s0/hoPvW5Mmq5MwimlCikUXtIYOYIYWUz1impU75ve6WzeHK+OKf/+AHYchVKuJRsLrTfHHY6A77AEAnZ6bBXc6ePj+1UOmPntxfkx3t5yzI5Uu7e3sYEDKmXirisisJnqxPH7Q68aD3rYVllkQJF6GUsRQmiE4j9/Wpkz9tHhGtDSUKACgOmcmQdhS1LDvLMoOwjJJ4d/ir4cfP0qaA23pxWc5N0FKhnQiLMQCgFceSFl24dPwLF4s/efe2P3llmoAbB5ZLw3gYxFE/jkdZNl8udA47KyunB72jb1Qn7c5gmGVcqJTzkVbAzY1TV89fvHR398nBYMgNikD5mhSQHWJuXM/OFaJhKLHhowAIWfjGl7b3nwbx8Nw3f9cCEDJjXAeDEQCQOGjFRzsny8FkRe43i0+fH2jIn5qZkxG/fft+rlDNlSYzxOanZxuj/hfPnLu+erCyvquSmKd6oOORkoMw+VTEb37hm6oXzdq5o2DU0akUMnbJhhgUHHeCelRBnGXDLAGDLMcrvHJ58dtvfXC4tdntCQG+bU/MTPl8sD5cIlMztSAOvvX6ceJEO3tHn7z3JG20XJleu3w1ToPdvQ0j+GS9/vWv3Xjl1Onru935W59ClnZGQ4sxi7FA8N+OBs8QOZqvD20z7fpoGDbikIMwMiNSlRG1DVWZiHiCCHUtG1vW+T/6fXDtrfZRnGSDqN8bdMbLpaS909EXaYBYKafPXl367PH9nd0gzTRRoWPnKWJ/81vfPnNy5Yc//OGt28/nHHhjoz03AD4cZdgUixULcJylFnZ7AOlYuXjj5R/9x//033cPr1VnRjKyLUtkkRYyFIJDUsv5DsWI0ZFUr/2977Gx+iCJDnu9IAgRNYVqaTjomFEEOaA2QV//8qLD0t2do62dWChIs2R8cqbgl0DJ4/NLb//dtzvd7kub2xceHQUqjJDqRmHQjQuOqyn
	ZiaKpyoRz4wuXzr70/MTyi8bR+72NEqPVTGL4a1NvIQRK5Cw3MDBz+RI6tpAAhJIzy65WEGOEYEhF5iv6+VE0F05P+f7Ui61Od4iV1hb1p6amM5USQFoh368t5IvjP/m1ylIuJAhFCGXMotQyjGCbbzX39p88Pvyv/8V2XZT3yED2sHYskteYCcIwBg0DwTVzZLkQ1XyTSuvzgUCpEglFVGMMmNSrzpEAim310sWX7j5ZI9Zc5/ARF6w651dqVSllKIWJhxF3is9XaaPNNOQsBkAdLRLCNMbNLBYGIbcgbdJu7iEpjO+aOE45fxIPl73SuFeORBpgaSwmPUp8ZutU89S1LRwazKgyFkLYY7bHnIXp4sNtoCtLtYnx8n/40Y+2d5U21PfL/+YH/5JqY7v5Ti950DksKlV4+CQnpaY441xzJUBigjMpM6N247ANOGKUKAnaOPliRILBsJ8geDDq1ZhjuzatFsMoKlBdMUbE8aDfY5S5tnvp8pWUZzzL0iR2bdbpHALA/wMUjQteOh3xIgAAAABJRU5ErkJggg==
X-Mailer: Evolution 3.2.2 (3.2.2-1.fc16) 
Mime-Version: 1.0
Cc: Wei Wang2 <wei.wang2@amd.com>, Tim Deegan <tim@xen.org>,
	xen-devel@lists.xensource.com,
	"allen.m.kay@intel.com" <allen.m.kay@intel.com>
Subject: Re: [Xen-devel] [PATCH 0 of 3] Deal with IOMMU faults in softirq
	context.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3580274337533879484=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--===============3580274337533879484==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-xrJnvLiDHt/Q8QaLsiJ5"


--=-xrJnvLiDHt/Q8QaLsiJ5
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, 2011-12-20 at 09:36 +0000, Jan Beulich wrote:=20
> These look good to me (apart from a minor indentation issue in the
> 2nd patch),
>
Oh, you mean those 3 spaces instead of 4 within
do_amd_iommu_page_fault()? I've no idea of how that could have happened
and will fix that, thanks.

If that's fine I'll wait a bit more to see if other reviews pop up and
then resubmit the series.

> but we'd surely like to have an ack from the respective
> maintainers.
>
Ok... Do I Cc-ed them correctly? :-)

> Also, despite the subject here, I suppose the series
> consists of just two patches?
>=20
It does, that '0 of 3' was just another silly mistake from myself. I
promise this will be the last one! :-)

> Thanks for doing this!
>=20
Thanks to you for having looked at it.
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-------------------------------------------------------------------
Dario Faggioli, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
PhD Candidate, ReTiS Lab, Scuola Superiore Sant'Anna, Pisa (Italy)



--=-xrJnvLiDHt/Q8QaLsiJ5
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEABECAAYFAk7wXcEACgkQk4XaBE3IOsSGpgCgnqYhATe5R9zy3rbyXOhtzvN9
cq0AnAyVg3tYAFRjgUwS4RP4539Koo+X
=kgS6
-----END PGP SIGNATURE-----

--=-xrJnvLiDHt/Q8QaLsiJ5--



--===============3580274337533879484==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============3580274337533879484==--



From xen-devel-bounces@lists.xensource.com Tue Dec 20 10:10:00 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 Dec 2011 10:10:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rcwdg-0000nI-2I; Tue, 20 Dec 2011 10:09:40 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1Rcwde-0000n0-U9
	for xen-devel@lists.xensource.com; Tue, 20 Dec 2011 10:09:39 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-8.tower-21.messagelabs.com!1324375772!8874479!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26660 invoked from network); 20 Dec 2011 10:09:32 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-8.tower-21.messagelabs.com with SMTP;
	20 Dec 2011 10:09:32 -0000
Received: from [62.94.181.91] (account d.faggioli@sssup.it HELO [192.168.0.20])
	by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 74043298; Tue, 20 Dec 2011 11:09:31 +0100
Message-ID: <1324375765.6616.9.camel@Abyss>
From: Dario Faggioli <raistlin@linux.it>
To: "Lv, Hui" <hui.lv@intel.com>
Date: Tue, 20 Dec 2011 11:09:25 +0100
In-Reply-To: <C10D3FB0CD45994C8A51FEC1227CE22F39412A99CE@shsmsx502.ccr.corp.intel.com>
References: <114495d1ff947737518b.1324332781@wsm-ep-n0>
	<1324372056.23729.8.camel@zakaz.uk.xensource.com>
	<C10D3FB0CD45994C8A51FEC1227CE22F39412A99CE@shsmsx502.ccr.corp.intel.com>
Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwCAIAAADYYG7QAAAAA3NCSVQICAjb4U/gAAAVx0lEQVRYwzWY6a/d953XP9/tt51zfme/+37t692OtzhxtzTuJFPaTDVt0cDQeTIajToSKBJICBASQkI8Q1Q8ACQEhUGgCsF0OrSkaRLaxknqOl7i9dq++3727bd/Vx5k+CNe7+WFvvkvbvoywAZF1BMYOFNFbqWEW1gho42yB9jJq1QihEGVCh7BxrXpeNlxbJZmcmNvkArIhAIMJd+drlmA0aiXuBbN5x3Pxq6NS6X85l5/rxNnGtJYgAYhgVCa8UxqAwgQIABAGGMD1JWtS7/48Vy0W1k5GxXnmh41br1y6fxXv3LCEPXLu3vv3N3t2kXPAi0EIjTjnDGcKawzHceZl3N0mIExrmfnGS1iSij2pxgDxJhlsOFID8LUsVjecXvNPiJg2ZYySiODGUVcAwBCCAAMAIAhNc82C2xvuLG8uX422VvZfHrx9Mz5P7kRR51wby188YD+8metqQWBLa00F1JIlQk5imIhle+XBsHI9/PVUoFCBp7JOZbSjGiS92mx7IE0SICRkC/Yw2GSZECpIsYYwEmWGkDGIAAAAIQAY4QMEA6Nvc7G6aaYzKQlUs/x/O99VywsZcZd33w++l9/NbN6Z905MSqPGYO10QDYGCI1EIQQGMdzkzCo+G4pb5eY7blWKhKadiZ92yYsFWoYpwhRv0A4h/4oK5Zcl9nGAMLUgEYYMAZAmhBkM6KkoYpVIRjU47SRRUuVlXRlUZ08nxDyi50na+2jV1r9tTjK/DwYqgFRLHMuYdhCMou1bg64a0M15yKiCyCcLJlJspl+e6x3QNtuv1TbKIwHxpHIZDEYorGFh32eK3h+yc06XYqA2MyyLCmk0lobAFC04NsTyCGjOAbrp5svrs/N1sqeRegKscrF2aiz1ZfJweZPjLzojB0fdPcqFcv481592Y15KiKOLBDyd
	OPw1b37JZ3Qosdspk2Eh71iZ3MmJafLE/2l4w/pjBiiRMVJKjOtLItypb18LkxCmSilAIAorQCA0nLl0lGSqY5kyCP55bFpOwvW1vo79+7vb+z5yjSF1Wg9RaNNjKxRlObPnd/c+UurPFMZPzO5cPpcIt/c/HApaZp+Jzoa6FKhcu4kogzZFGmEGgczG6v1O+8uLp1eQ0VdOrXuLFqu0mAwwZkUCBOMmJAKDAIgAJq88f1/NucwtbZqaXP9pfNnFxY++ujmI4OZVzoYHfKtxnrY2PFAS46yuJTPNzvNYXvbDJsvTfr/5PSJl3/676cbhzvPV4ccbN9KTCoHHYa5xQoZRPpglw1SEim5tzN58KSc4b1LFzEmFiMEYwCSca01MsYAAoyRUYrGgjXOXfgbg8aE5hPV8vsPPr7XHJaPn4x6MY0GjsUWvnxy+dLSB7+43W6zN77y9Q/e/3ENvMvI/dO4WftX/xzidDvrO7Mnxqt+P0kshcCyRj2pe89zKSKxVjrWWKs4balUO/s26MwgqZU2JsmkUhjAAPpr0ACA3vjKydHuAa56B2u7Hz59qDFOkD149x1n9VkW81LevvCH54b5ztiY/+rLr7zxu1+TwdEr99deD0Ln1tMw4ixVhVpuemZGYT5W8JQCgyAMR1whY1IGqRI8E1ks0m2pnqq0k6ogUpgRroBLDQgjDBgTjAEUUgDUJI16Se7sbcWdfoxdzrRUwj7aV1I7165Mnjhx+oLz2+CTyclL3/2D74ApfOFr3w4Hf7778/dmSclIzoXKTy6n2QBrjRQyBPdGQ6RVlCQ8TXScMGk8iwWErsV8Z/58J9KZ0IgbBJgQiok2BghBCCFjMACQlesvrzjY/tWtOM0EoZwCU0Ym2ag+VZ5fLOf9xZXph61s8dibtdpYnApmFe3JmX6372UByfg+wKNOt+hYSgHBNjiesW3H9SyhqEKJlE2ZHiSjrVS2c8Xm639nhEoACAzGhDCGKSVKGQ
	AwBgECxQXNuz7uD1QvQFJEeeOm0iiFBbDu/uEzwW8O+P826hu/d6v0/PTx5Y8/ee/l66/lFqdqb9xQ//pRJ+KBwfmp8U1tmkgnXqaxbPd6/V4fJ1kJ6JQhderZ1OvE/aYSfeKBAYSQQVgbI5Q2UgMgBMgYAxgBAE1U6uQKuS9e7310qzwQ2pDUghR4JU3UZji07BfFamHtIF00O839zx7ceeXaFxGY/J1Hz1sHPEGHDlnTreLkyeNXrpQLDgjtBHF+GI6i4VEYfnpwpAejvNBnUdG2qkBdw4w2Bhv0eXeZzwMfIYQ+7zKgc7VynCux73176ktXV//ix6Onq67RxIhEGTDSHybQH4Xt6LU3317f2pycmGJUVxudOZ+o6Zn764dB0YHx6dCwp88eIYSIxpLLIIziLJbSOAKEW9QlZ7Posijv5awsSw1yDMIAGMAgZBBCGGNjDEJGAdCJnI9thwHLFr3pt9+e3Wl2W41fbj1NlD51sHvmxeP1YfqMya9fvfaf//E/3T/cfPP6K8vv3Wz/3w/SxiBPaDFUeGZ6V2Sd7UOtACmkpeRSaI0wMogZYzNk05KfG5Z8q5a9bBeaA90P0kRixGyuPqddY4wwQgKAFosVQjEANjF1lFIz4/1x50g0kyR+uVi79jtf/vmHL4LKhZ7WreYWMbH5b/8zu3vHGkUZlxjrSOkzy/Px/n5fYxAxNUCNIdhIojEhmDFM3By2sWdJNlajeKmUnqiwQNuRZJ0I398LDVBkABPABgEA7o/CMEhlplzHKlZL1WJVY4LB5Ci6+p2rvRv1uxm8evba/Qe/UaPuDUEXP/kNTdJewqtV/+zlK9yQnfWtdrsVp+koEWEmpQELUwcTqrGMVZpEiUqVU43PflUzLR2pbFqkenncKniZsRNjcaAcocRmGQBQh1kIISmllJLrbG/3oCujE7PHahYo8eDu46fUqawsLzx4+vEZN/eHQcJHyVBjz5DqsYWOwDm/nmP52TF
	vY79x1O4bKcp5b7JWIQoNklRhYhvKjBkfCrf3xJ7+ijVKo+TAsQuO4wKlDsMGpRRjlYm8U+wBp57jWrYlpFRKGa7G56b/4i//x0Hj4OKU9/03Tj3e3BuvFvP1QhJmf2Zcuz/UhGiNWK3a7US8Ovvaq7/zcXenmfWqrmdKpTRLGCO9KELGhJmIOHcZLY9XGo3BBTrUJxuzCtJ8refnuDY6EwRjbaRnA3OxjQ0AUK2U4EIZrYw2gIYyzVQyNV48e9wzRt6729p5sl+2ci8/+Gy80x5hMFIBsZOyf4TIrC4Uld05bChP+kpZNo4RywAERgyTPCJgO1bBmfALzb3B5msXrg0UqxaG5QJgy0UMrIxYjAhHZ4HtJVW3uAaCUkYNGAxGKYkBd/pNC2AizxYq/LPHn9hWfb4eFxob59cakhpXmIaCnGu9u7td9MdajTsvnbxAmY94YEFojOEGEcYQAYSY4VEx79J8QQ+yiPlBFq/aE1Gt7BmTwwo7jh5wjDlxGDWKMGKMAgBsW45t2TazGWHI0hs7G1oJIgavXjmTCKcXwJeuXsv+zwexyhLmxoRix3rEUAv0++3tDweHdzafvlZfxH6RS8cYAkAPW/0Xe612t2sAwNC0nz67t+rmcgEPW82+yEgqdZImo2Gnfbge9p6AaliuGsUj5lAAoJQxKYUCDYAEhkEYFPzCXA0q9eLme0m7K6auTgUf3ynYrCzprhJHBSdYnLX3jvSoNwrMzfbW7Y9aIaCwQMHlOS83XvWTRGDLihCkoyTujpiiBAOSYTKAOAjdXAFjLGTWae0/W3skwa3WJiYnpse9BQCgwyhCCAhBwOgoDErVCd1tLc2ge4+fBKHDjJk/fsrR76BhHBoIy6VoeSlFEmxKHNpN0rGJqbDbV9KwgWj3IlWQhGGlTXuUacvKMxtJhA3oLGZJL+Nht1M/eeZaq90wGDtu7tj8cYUsIU3J8yzKAAQVimdSICmlUQ93Xxw1W8cnxhYW
	wkKhY/C8X+ufq891Wy3P4Nsg26eWolx9dLC9P+wpZBKbNnv9AiGWlipNXEP1gGNKjJIFg0lmLJOWmS2UylMU91qWXw663X4nUAYjkNRxX9zd0oj4lclykTNCAIDatqORMVpJhNY21raP9lS0+bdeWd7ePXr8wlqaXiK//qDX3P20Nr41tZASRtSwhSRCUHVsZkO3F9qkgFKJDC4QprRSmcgTSjHFBjEwjtR5hEm7xxzmunkZhL1Od2F5th+2DQJDqF2ezo8vAcbUpABAkyTjUhjJRzrRQe9CsXj9st0ZbDVeDK8M7b+Nk+7qnaevfvVAC8G5ATTx2mtLRt7+d/+WpKHrWEnRO2gPxqUtMU4UV0bbzMKISCmBIKAUAGyAzvZWrmjZ1SJS/OHde/MzE2OVeqHgX3n5qnLHO/3UIO55GAAoF0pppbTuBoOEGkqsGqPXotlLvUp1pto8ffGdXuPFbz+lsSL5YovoW+++c2q8rmyLaocinCN6VLaToZFcYoM0xpHiHFAOU8aIBpAAgFEmZNLpmFpJsk5hciYeDmsTi/fuf7bX2auWx0rjc47v7j2+BXCRUoK4QQDQaB0Zg7SRhVSxx0NfzHWPrzxfXlj76EObxxqhv1p7fOLiJd8Ujp890z46HG5tGNAIKdtloRCJUjnMMAKsMEK4RbhCAhuMElkkdozAjIb5YZToZiDM5XNntQ2u5VKtGzsbe/tbpXye1SbBvkgJAMVYEzIajTyEj83YQ7/104Xhb37WvLGwEm3shUnAMhUiM1AZz9KjVmtydrpFCAeFMaYWtQBpn0mtBpkCpZAFiGLm2KAhHaY5REEjhJUDhAcxx05hLBcnaa1UKjALE+aVqpHIJienbBAAgEt+frxURBZRBkOuNF2lC2P4fif7JXa2uD7Y3+VxQlO5GwfMyecK+Xq1WB8b6yaBJEhqhRBGGGML56s+rnhW3XeqBavoEERFkFmAkdIIQR4wjlMRxx5zUgG3769qo
	U7MzLS7w04QGcs2zPbLPgDg3qAXh8PV7fXEoPm5xWIt543nRe585djS1vN7+MXDwfZGe9Dc63XSRBwcNOIoAgQjkQqGhdGAkNEaaUW0ylnUw9g1BIdKdsK8op4hNiUSa8VFvVI5ff6sSFOG2YOnG0kii26+6BeJxbjRSZpg1wMAbDMgFjxZvb+/u/X81ntJZysYos7hcNbLjy1MPtp6gkbdqD+oF6vFSs3NeTNT04NePwQtsNZAldYGIaUUaIkkRxrCME0GSQk7HmCiDQWEAQMCGcYXjh2zjQShohiGcXb1pQvH5ueLOafgOkaK2bEiAFDFZTcc2CpayMPSWO3kUn5zbXtwNNjfffTW3/9Hd29+mISBkWRhYf7333xzZqKUBaNOp9/ziqUgwSBSJGxqy0xrYUAZLkUUpXVs5zHJQEstkAFsMGNOOgiS++s05AiACp7G8Vi1xMPk5LFjbrGUQzA3UYOHQA1mz7e3D1qDAtNTp+cZNd2B+NaXvtjvqGrRs4pETXuHR73NezcDHTsMX7n2ansYzc2drnO7K5+vzEwqrtf3okAbkxgeZyCMTy0bUY1U9v/FmMUoaHPc5LOZY7/urk9Yo3H2eu+ou1ir/urxqtHZialp98wUAGAA9XhrPaH+SJPKhB+lfL2de//uemblk0hcml34g7feOHN+5eyZk6eXpoP2YaXsdzdXv3ugb9SXSi75va9d+4f/4I+/89aNotb9ILYFnrYLHsYUAUMYGQAD1CCCSd0tfPrg/hwH0ttctgN7dDjGu0sOdqmZKlvnj88SpAGAPtnYyESKVFTP8Zw16rUOW116FOPr5fqz7b2fP36hP+7zWAkplxdmEUEF1748O/7wg59MaOv7J065NzcOnrW8nKeo48lwxStSLi3QgCkiaATYGMMMgNG1QmlfxxO9Xtn1Ro2+UnDz5z+LgzTP0Hgtl7MhzmIAwI/XVgNBAqNXTh2v5Mwwg3Z3wEfJ7OxyHHPb9SNuEi
	64Ed1RmAjm58rbHz85qdCfzi2fHfH67sj+6EX6s0/hoPvW5Mmq5MwimlCikUXtIYOYIYWUz1impU75ve6WzeHK+OKf/+AHYchVKuJRsLrTfHHY6A77AEAnZ6bBXc6ePj+1UOmPntxfkx3t5yzI5Uu7e3sYEDKmXirisisJnqxPH7Q68aD3rYVllkQJF6GUsRQmiE4j9/Wpkz9tHhGtDSUKACgOmcmQdhS1LDvLMoOwjJJ4d/ir4cfP0qaA23pxWc5N0FKhnQiLMQCgFceSFl24dPwLF4s/efe2P3llmoAbB5ZLw3gYxFE/jkdZNl8udA47KyunB72jb1Qn7c5gmGVcqJTzkVbAzY1TV89fvHR398nBYMgNikD5mhSQHWJuXM/OFaJhKLHhowAIWfjGl7b3nwbx8Nw3f9cCEDJjXAeDEQCQOGjFRzsny8FkRe43i0+fH2jIn5qZkxG/fft+rlDNlSYzxOanZxuj/hfPnLu+erCyvquSmKd6oOORkoMw+VTEb37hm6oXzdq5o2DU0akUMnbJhhgUHHeCelRBnGXDLAGDLMcrvHJ58dtvfXC4tdntCQG+bU/MTPl8sD5cIlMztSAOvvX6ceJEO3tHn7z3JG20XJleu3w1ToPdvQ0j+GS9/vWv3Xjl1Onru935W59ClnZGQ4sxi7FA8N+OBs8QOZqvD20z7fpoGDbikIMwMiNSlRG1DVWZiHiCCHUtG1vW+T/6fXDtrfZRnGSDqN8bdMbLpaS909EXaYBYKafPXl367PH9nd0gzTRRoWPnKWJ/81vfPnNy5Yc//OGt28/nHHhjoz03AD4cZdgUixULcJylFnZ7AOlYuXjj5R/9x//033cPr1VnRjKyLUtkkRYyFIJDUsv5DsWI0ZFUr/2977Gx+iCJDnu9IAgRNYVqaTjomFEEOaA2QV//8qLD0t2do62dWChIs2R8cqbgl0DJ4/NLb//dtzvd7kub2xceHQUqjJDqRmHQjQuOqyn
	ZiaKpyoRz4wuXzr70/MTyi8bR+72NEqPVTGL4a1NvIQRK5Cw3MDBz+RI6tpAAhJIzy65WEGOEYEhF5iv6+VE0F05P+f7Ui61Od4iV1hb1p6amM5USQFoh368t5IvjP/m1ylIuJAhFCGXMotQyjGCbbzX39p88Pvyv/8V2XZT3yED2sHYskteYCcIwBg0DwTVzZLkQ1XyTSuvzgUCpEglFVGMMmNSrzpEAim310sWX7j5ZI9Zc5/ARF6w651dqVSllKIWJhxF3is9XaaPNNOQsBkAdLRLCNMbNLBYGIbcgbdJu7iEpjO+aOE45fxIPl73SuFeORBpgaSwmPUp8ZutU89S1LRwazKgyFkLYY7bHnIXp4sNtoCtLtYnx8n/40Y+2d5U21PfL/+YH/5JqY7v5Ti950DksKlV4+CQnpaY441xzJUBigjMpM6N247ANOGKUKAnaOPliRILBsJ8geDDq1ZhjuzatFsMoKlBdMUbE8aDfY5S5tnvp8pWUZzzL0iR2bdbpHALA/wMUjQteOh3xIgAAAABJRU5ErkJggg==
X-Mailer: Evolution 3.2.2 (3.2.2-1.fc16) 
Mime-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH] xen/sched_credit: Use delay to control
 scheduling frequency
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============2751783175233799290=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--===============2751783175233799290==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-WrBcnFSJeQorqQAB0cAE"


--=-WrBcnFSJeQorqQAB0cAE
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, 2011-12-20 at 17:44 +0800, Lv, Hui wrote:=20
> > It that constraint enforced anywhere?
>=20
> Currently, it's not constraint enforced.=20
> I think George have gave the explanation in yesterday's discussion.
>=20
I think that too, but maybe you can print some kind of warning when it
happens?

Regards,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-------------------------------------------------------------------
Dario Faggioli, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
PhD Candidate, ReTiS Lab, Scuola Superiore Sant'Anna, Pisa (Italy)



--=-WrBcnFSJeQorqQAB0cAE
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEABECAAYFAk7wXtUACgkQk4XaBE3IOsTNjwCfZ5Vnele0iM2EZxw5Ko9aSYcK
gjgAni3Nsoxe819Pt8ae2Cns2vplcghV
=lQMN
-----END PGP SIGNATURE-----

--=-WrBcnFSJeQorqQAB0cAE--



--===============2751783175233799290==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============2751783175233799290==--



From xen-devel-bounces@lists.xensource.com Tue Dec 20 10:10:00 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 Dec 2011 10:10:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rcwdg-0000nI-2I; Tue, 20 Dec 2011 10:09:40 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1Rcwde-0000n0-U9
	for xen-devel@lists.xensource.com; Tue, 20 Dec 2011 10:09:39 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-8.tower-21.messagelabs.com!1324375772!8874479!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26660 invoked from network); 20 Dec 2011 10:09:32 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-8.tower-21.messagelabs.com with SMTP;
	20 Dec 2011 10:09:32 -0000
Received: from [62.94.181.91] (account d.faggioli@sssup.it HELO [192.168.0.20])
	by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 74043298; Tue, 20 Dec 2011 11:09:31 +0100
Message-ID: <1324375765.6616.9.camel@Abyss>
From: Dario Faggioli <raistlin@linux.it>
To: "Lv, Hui" <hui.lv@intel.com>
Date: Tue, 20 Dec 2011 11:09:25 +0100
In-Reply-To: <C10D3FB0CD45994C8A51FEC1227CE22F39412A99CE@shsmsx502.ccr.corp.intel.com>
References: <114495d1ff947737518b.1324332781@wsm-ep-n0>
	<1324372056.23729.8.camel@zakaz.uk.xensource.com>
	<C10D3FB0CD45994C8A51FEC1227CE22F39412A99CE@shsmsx502.ccr.corp.intel.com>
Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwCAIAAADYYG7QAAAAA3NCSVQICAjb4U/gAAAVx0lEQVRYwzWY6a/d953XP9/tt51zfme/+37t692OtzhxtzTuJFPaTDVt0cDQeTIajToSKBJICBASQkI8Q1Q8ACQEhUGgCsF0OrSkaRLaxknqOl7i9dq++3727bd/Vx5k+CNe7+WFvvkvbvoywAZF1BMYOFNFbqWEW1gho42yB9jJq1QihEGVCh7BxrXpeNlxbJZmcmNvkArIhAIMJd+drlmA0aiXuBbN5x3Pxq6NS6X85l5/rxNnGtJYgAYhgVCa8UxqAwgQIABAGGMD1JWtS7/48Vy0W1k5GxXnmh41br1y6fxXv3LCEPXLu3vv3N3t2kXPAi0EIjTjnDGcKawzHceZl3N0mIExrmfnGS1iSij2pxgDxJhlsOFID8LUsVjecXvNPiJg2ZYySiODGUVcAwBCCAAMAIAhNc82C2xvuLG8uX422VvZfHrx9Mz5P7kRR51wby188YD+8metqQWBLa00F1JIlQk5imIhle+XBsHI9/PVUoFCBp7JOZbSjGiS92mx7IE0SICRkC/Yw2GSZECpIsYYwEmWGkDGIAAAAIQAY4QMEA6Nvc7G6aaYzKQlUs/x/O99VywsZcZd33w++l9/NbN6Z905MSqPGYO10QDYGCI1EIQQGMdzkzCo+G4pb5eY7blWKhKadiZ92yYsFWoYpwhRv0A4h/4oK5Zcl9nGAMLUgEYYMAZAmhBkM6KkoYpVIRjU47SRRUuVlXRlUZ08nxDyi50na+2jV1r9tTjK/DwYqgFRLHMuYdhCMou1bg64a0M15yKiCyCcLJlJspl+e6x3QNtuv1TbKIwHxpHIZDEYorGFh32eK3h+yc06XYqA2MyyLCmk0lobAFC04NsTyCGjOAbrp5svrs/N1sqeRegKscrF2aiz1ZfJweZPjLzojB0fdPcqFcv481592Y15KiKOLBDyd
	OPw1b37JZ3Qosdspk2Eh71iZ3MmJafLE/2l4w/pjBiiRMVJKjOtLItypb18LkxCmSilAIAorQCA0nLl0lGSqY5kyCP55bFpOwvW1vo79+7vb+z5yjSF1Wg9RaNNjKxRlObPnd/c+UurPFMZPzO5cPpcIt/c/HApaZp+Jzoa6FKhcu4kogzZFGmEGgczG6v1O+8uLp1eQ0VdOrXuLFqu0mAwwZkUCBOMmJAKDAIgAJq88f1/NucwtbZqaXP9pfNnFxY++ujmI4OZVzoYHfKtxnrY2PFAS46yuJTPNzvNYXvbDJsvTfr/5PSJl3/676cbhzvPV4ccbN9KTCoHHYa5xQoZRPpglw1SEim5tzN58KSc4b1LFzEmFiMEYwCSca01MsYAAoyRUYrGgjXOXfgbg8aE5hPV8vsPPr7XHJaPn4x6MY0GjsUWvnxy+dLSB7+43W6zN77y9Q/e/3ENvMvI/dO4WftX/xzidDvrO7Mnxqt+P0kshcCyRj2pe89zKSKxVjrWWKs4balUO/s26MwgqZU2JsmkUhjAAPpr0ACA3vjKydHuAa56B2u7Hz59qDFOkD149x1n9VkW81LevvCH54b5ztiY/+rLr7zxu1+TwdEr99deD0Ln1tMw4ixVhVpuemZGYT5W8JQCgyAMR1whY1IGqRI8E1ks0m2pnqq0k6ogUpgRroBLDQgjDBgTjAEUUgDUJI16Se7sbcWdfoxdzrRUwj7aV1I7165Mnjhx+oLz2+CTyclL3/2D74ApfOFr3w4Hf7778/dmSclIzoXKTy6n2QBrjRQyBPdGQ6RVlCQ8TXScMGk8iwWErsV8Z/58J9KZ0IgbBJgQiok2BghBCCFjMACQlesvrzjY/tWtOM0EoZwCU0Ym2ag+VZ5fLOf9xZXph61s8dibtdpYnApmFe3JmX6372UByfg+wKNOt+hYSgHBNjiesW3H9SyhqEKJlE2ZHiSjrVS2c8Xm639nhEoACAzGhDCGKSVKGQ
	AwBgECxQXNuz7uD1QvQFJEeeOm0iiFBbDu/uEzwW8O+P826hu/d6v0/PTx5Y8/ee/l66/lFqdqb9xQ//pRJ+KBwfmp8U1tmkgnXqaxbPd6/V4fJ1kJ6JQhderZ1OvE/aYSfeKBAYSQQVgbI5Q2UgMgBMgYAxgBAE1U6uQKuS9e7310qzwQ2pDUghR4JU3UZji07BfFamHtIF00O839zx7ceeXaFxGY/J1Hz1sHPEGHDlnTreLkyeNXrpQLDgjtBHF+GI6i4VEYfnpwpAejvNBnUdG2qkBdw4w2Bhv0eXeZzwMfIYQ+7zKgc7VynCux73176ktXV//ix6Onq67RxIhEGTDSHybQH4Xt6LU3317f2pycmGJUVxudOZ+o6Zn764dB0YHx6dCwp88eIYSIxpLLIIziLJbSOAKEW9QlZ7Posijv5awsSw1yDMIAGMAgZBBCGGNjDEJGAdCJnI9thwHLFr3pt9+e3Wl2W41fbj1NlD51sHvmxeP1YfqMya9fvfaf//E/3T/cfPP6K8vv3Wz/3w/SxiBPaDFUeGZ6V2Sd7UOtACmkpeRSaI0wMogZYzNk05KfG5Z8q5a9bBeaA90P0kRixGyuPqddY4wwQgKAFosVQjEANjF1lFIz4/1x50g0kyR+uVi79jtf/vmHL4LKhZ7WreYWMbH5b/8zu3vHGkUZlxjrSOkzy/Px/n5fYxAxNUCNIdhIojEhmDFM3By2sWdJNlajeKmUnqiwQNuRZJ0I398LDVBkABPABgEA7o/CMEhlplzHKlZL1WJVY4LB5Ci6+p2rvRv1uxm8evba/Qe/UaPuDUEXP/kNTdJewqtV/+zlK9yQnfWtdrsVp+koEWEmpQELUwcTqrGMVZpEiUqVU43PflUzLR2pbFqkenncKniZsRNjcaAcocRmGQBQh1kIISmllJLrbG/3oCujE7PHahYo8eDu46fUqawsLzx4+vEZN/eHQcJHyVBjz5DqsYWOwDm/nmP52TF
	vY79x1O4bKcp5b7JWIQoNklRhYhvKjBkfCrf3xJ7+ijVKo+TAsQuO4wKlDsMGpRRjlYm8U+wBp57jWrYlpFRKGa7G56b/4i//x0Hj4OKU9/03Tj3e3BuvFvP1QhJmf2Zcuz/UhGiNWK3a7US8Ovvaq7/zcXenmfWqrmdKpTRLGCO9KELGhJmIOHcZLY9XGo3BBTrUJxuzCtJ8refnuDY6EwRjbaRnA3OxjQ0AUK2U4EIZrYw2gIYyzVQyNV48e9wzRt6729p5sl+2ci8/+Gy80x5hMFIBsZOyf4TIrC4Uld05bChP+kpZNo4RywAERgyTPCJgO1bBmfALzb3B5msXrg0UqxaG5QJgy0UMrIxYjAhHZ4HtJVW3uAaCUkYNGAxGKYkBd/pNC2AizxYq/LPHn9hWfb4eFxob59cakhpXmIaCnGu9u7td9MdajTsvnbxAmY94YEFojOEGEcYQAYSY4VEx79J8QQ+yiPlBFq/aE1Gt7BmTwwo7jh5wjDlxGDWKMGKMAgBsW45t2TazGWHI0hs7G1oJIgavXjmTCKcXwJeuXsv+zwexyhLmxoRix3rEUAv0++3tDweHdzafvlZfxH6RS8cYAkAPW/0Xe612t2sAwNC0nz67t+rmcgEPW82+yEgqdZImo2Gnfbge9p6AaliuGsUj5lAAoJQxKYUCDYAEhkEYFPzCXA0q9eLme0m7K6auTgUf3ynYrCzprhJHBSdYnLX3jvSoNwrMzfbW7Y9aIaCwQMHlOS83XvWTRGDLihCkoyTujpiiBAOSYTKAOAjdXAFjLGTWae0/W3skwa3WJiYnpse9BQCgwyhCCAhBwOgoDErVCd1tLc2ge4+fBKHDjJk/fsrR76BhHBoIy6VoeSlFEmxKHNpN0rGJqbDbV9KwgWj3IlWQhGGlTXuUacvKMxtJhA3oLGZJL+Nht1M/eeZaq90wGDtu7tj8cYUsIU3J8yzKAAQVimdSICmlUQ93Xxw1W8cnxhYW
	wkKhY/C8X+ufq891Wy3P4Nsg26eWolx9dLC9P+wpZBKbNnv9AiGWlipNXEP1gGNKjJIFg0lmLJOWmS2UylMU91qWXw663X4nUAYjkNRxX9zd0oj4lclykTNCAIDatqORMVpJhNY21raP9lS0+bdeWd7ePXr8wlqaXiK//qDX3P20Nr41tZASRtSwhSRCUHVsZkO3F9qkgFKJDC4QprRSmcgTSjHFBjEwjtR5hEm7xxzmunkZhL1Od2F5th+2DQJDqF2ezo8vAcbUpABAkyTjUhjJRzrRQe9CsXj9st0ZbDVeDK8M7b+Nk+7qnaevfvVAC8G5ATTx2mtLRt7+d/+WpKHrWEnRO2gPxqUtMU4UV0bbzMKISCmBIKAUAGyAzvZWrmjZ1SJS/OHde/MzE2OVeqHgX3n5qnLHO/3UIO55GAAoF0pppbTuBoOEGkqsGqPXotlLvUp1pto8ffGdXuPFbz+lsSL5YovoW+++c2q8rmyLaocinCN6VLaToZFcYoM0xpHiHFAOU8aIBpAAgFEmZNLpmFpJsk5hciYeDmsTi/fuf7bX2auWx0rjc47v7j2+BXCRUoK4QQDQaB0Zg7SRhVSxx0NfzHWPrzxfXlj76EObxxqhv1p7fOLiJd8Ujp890z46HG5tGNAIKdtloRCJUjnMMAKsMEK4RbhCAhuMElkkdozAjIb5YZToZiDM5XNntQ2u5VKtGzsbe/tbpXye1SbBvkgJAMVYEzIajTyEj83YQ7/104Xhb37WvLGwEm3shUnAMhUiM1AZz9KjVmtydrpFCAeFMaYWtQBpn0mtBpkCpZAFiGLm2KAhHaY5REEjhJUDhAcxx05hLBcnaa1UKjALE+aVqpHIJienbBAAgEt+frxURBZRBkOuNF2lC2P4fif7JXa2uD7Y3+VxQlO5GwfMyecK+Xq1WB8b6yaBJEhqhRBGGGML56s+rnhW3XeqBavoEERFkFmAkdIIQR4wjlMRxx5zUgG3769qo
	U7MzLS7w04QGcs2zPbLPgDg3qAXh8PV7fXEoPm5xWIt543nRe585djS1vN7+MXDwfZGe9Dc63XSRBwcNOIoAgQjkQqGhdGAkNEaaUW0ylnUw9g1BIdKdsK8op4hNiUSa8VFvVI5ff6sSFOG2YOnG0kii26+6BeJxbjRSZpg1wMAbDMgFjxZvb+/u/X81ntJZysYos7hcNbLjy1MPtp6gkbdqD+oF6vFSs3NeTNT04NePwQtsNZAldYGIaUUaIkkRxrCME0GSQk7HmCiDQWEAQMCGcYXjh2zjQShohiGcXb1pQvH5ueLOafgOkaK2bEiAFDFZTcc2CpayMPSWO3kUn5zbXtwNNjfffTW3/9Hd29+mISBkWRhYf7333xzZqKUBaNOp9/ziqUgwSBSJGxqy0xrYUAZLkUUpXVs5zHJQEstkAFsMGNOOgiS++s05AiACp7G8Vi1xMPk5LFjbrGUQzA3UYOHQA1mz7e3D1qDAtNTp+cZNd2B+NaXvtjvqGrRs4pETXuHR73NezcDHTsMX7n2ansYzc2drnO7K5+vzEwqrtf3okAbkxgeZyCMTy0bUY1U9v/FmMUoaHPc5LOZY7/urk9Yo3H2eu+ou1ir/urxqtHZialp98wUAGAA9XhrPaH+SJPKhB+lfL2de//uemblk0hcml34g7feOHN+5eyZk6eXpoP2YaXsdzdXv3ugb9SXSi75va9d+4f/4I+/89aNotb9ILYFnrYLHsYUAUMYGQAD1CCCSd0tfPrg/hwH0ttctgN7dDjGu0sOdqmZKlvnj88SpAGAPtnYyESKVFTP8Zw16rUOW116FOPr5fqz7b2fP36hP+7zWAkplxdmEUEF1748O/7wg59MaOv7J065NzcOnrW8nKeo48lwxStSLi3QgCkiaATYGMMMgNG1QmlfxxO9Xtn1Ro2+UnDz5z+LgzTP0Hgtl7MhzmIAwI/XVgNBAqNXTh2v5Mwwg3Z3wEfJ7OxyHHPb9SNuEi
	64Ed1RmAjm58rbHz85qdCfzi2fHfH67sj+6EX6s0/hoPvW5Mmq5MwimlCikUXtIYOYIYWUz1impU75ve6WzeHK+OKf/+AHYchVKuJRsLrTfHHY6A77AEAnZ6bBXc6ePj+1UOmPntxfkx3t5yzI5Uu7e3sYEDKmXirisisJnqxPH7Q68aD3rYVllkQJF6GUsRQmiE4j9/Wpkz9tHhGtDSUKACgOmcmQdhS1LDvLMoOwjJJ4d/ir4cfP0qaA23pxWc5N0FKhnQiLMQCgFceSFl24dPwLF4s/efe2P3llmoAbB5ZLw3gYxFE/jkdZNl8udA47KyunB72jb1Qn7c5gmGVcqJTzkVbAzY1TV89fvHR398nBYMgNikD5mhSQHWJuXM/OFaJhKLHhowAIWfjGl7b3nwbx8Nw3f9cCEDJjXAeDEQCQOGjFRzsny8FkRe43i0+fH2jIn5qZkxG/fft+rlDNlSYzxOanZxuj/hfPnLu+erCyvquSmKd6oOORkoMw+VTEb37hm6oXzdq5o2DU0akUMnbJhhgUHHeCelRBnGXDLAGDLMcrvHJ58dtvfXC4tdntCQG+bU/MTPl8sD5cIlMztSAOvvX6ceJEO3tHn7z3JG20XJleu3w1ToPdvQ0j+GS9/vWv3Xjl1Onru935W59ClnZGQ4sxi7FA8N+OBs8QOZqvD20z7fpoGDbikIMwMiNSlRG1DVWZiHiCCHUtG1vW+T/6fXDtrfZRnGSDqN8bdMbLpaS909EXaYBYKafPXl367PH9nd0gzTRRoWPnKWJ/81vfPnNy5Yc//OGt28/nHHhjoz03AD4cZdgUixULcJylFnZ7AOlYuXjj5R/9x//033cPr1VnRjKyLUtkkRYyFIJDUsv5DsWI0ZFUr/2977Gx+iCJDnu9IAgRNYVqaTjomFEEOaA2QV//8qLD0t2do62dWChIs2R8cqbgl0DJ4/NLb//dtzvd7kub2xceHQUqjJDqRmHQjQuOqyn
	ZiaKpyoRz4wuXzr70/MTyi8bR+72NEqPVTGL4a1NvIQRK5Cw3MDBz+RI6tpAAhJIzy65WEGOEYEhF5iv6+VE0F05P+f7Ui61Od4iV1hb1p6amM5USQFoh368t5IvjP/m1ylIuJAhFCGXMotQyjGCbbzX39p88Pvyv/8V2XZT3yED2sHYskteYCcIwBg0DwTVzZLkQ1XyTSuvzgUCpEglFVGMMmNSrzpEAim310sWX7j5ZI9Zc5/ARF6w651dqVSllKIWJhxF3is9XaaPNNOQsBkAdLRLCNMbNLBYGIbcgbdJu7iEpjO+aOE45fxIPl73SuFeORBpgaSwmPUp8ZutU89S1LRwazKgyFkLYY7bHnIXp4sNtoCtLtYnx8n/40Y+2d5U21PfL/+YH/5JqY7v5Ti950DksKlV4+CQnpaY441xzJUBigjMpM6N247ANOGKUKAnaOPliRILBsJ8geDDq1ZhjuzatFsMoKlBdMUbE8aDfY5S5tnvp8pWUZzzL0iR2bdbpHALA/wMUjQteOh3xIgAAAABJRU5ErkJggg==
X-Mailer: Evolution 3.2.2 (3.2.2-1.fc16) 
Mime-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH] xen/sched_credit: Use delay to control
 scheduling frequency
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============2751783175233799290=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--===============2751783175233799290==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-WrBcnFSJeQorqQAB0cAE"


--=-WrBcnFSJeQorqQAB0cAE
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, 2011-12-20 at 17:44 +0800, Lv, Hui wrote:=20
> > It that constraint enforced anywhere?
>=20
> Currently, it's not constraint enforced.=20
> I think George have gave the explanation in yesterday's discussion.
>=20
I think that too, but maybe you can print some kind of warning when it
happens?

Regards,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-------------------------------------------------------------------
Dario Faggioli, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
PhD Candidate, ReTiS Lab, Scuola Superiore Sant'Anna, Pisa (Italy)



--=-WrBcnFSJeQorqQAB0cAE
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEABECAAYFAk7wXtUACgkQk4XaBE3IOsTNjwCfZ5Vnele0iM2EZxw5Ko9aSYcK
gjgAni3Nsoxe819Pt8ae2Cns2vplcghV
=lQMN
-----END PGP SIGNATURE-----

--=-WrBcnFSJeQorqQAB0cAE--



--===============2751783175233799290==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============2751783175233799290==--



From xen-devel-bounces@lists.xensource.com Tue Dec 20 10:12:13 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 Dec 2011 10:12:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rcwfu-0000uZ-KN; Tue, 20 Dec 2011 10:11:58 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rcwft-0000uC-4h
	for xen-devel@lists.xensource.com; Tue, 20 Dec 2011 10:11:57 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1324375910!6173035!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzQwMQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29106 invoked from network); 20 Dec 2011 10:11:51 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Dec 2011 10:11:51 -0000
X-IronPort-AV: E=Sophos;i="4.71,381,1320624000"; 
   d="scan'208";a="9573140"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Dec 2011 10:11:50 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 20 Dec 2011 10:11:50 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Date: Tue, 20 Dec 2011 10:11:50 +0000
In-Reply-To: <20111216113300.GA4854@aepfle.de>
References: <4EEA4877.8010307@canonical.com>
	<20111215193942.GA7640@andromeda.dapyr.net>
	<20111216113300.GA4854@aepfle.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1324375910.23729.31.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefan Bader <stefan.bader@canonical.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] xenbus and the message of doom
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2011-12-16 at 11:33 +0000, Olaf Hering wrote:
> On Thu, Dec 15, Konrad Rzeszutek Wilk wrote:
> 
> > On Thu, Dec 15, 2011 at 08:20:23PM +0100, Stefan Bader wrote:
> > > I was investigating a bug report[1] about newer kernels (>3.1) not booting as
> > > HVM guests on Amazon EC2. For some reason git bisect did give the some pain, but
> > > it lead me at least close and with some crash dump data I think I figured the
> > > problem.
> > 
> > Stefan, thanks for finding this.
> > 
> > Olaf, what are your thoughts? Should I prep a patch to revert the patch
> > below and then we can work on 3.3 and rethink this in 3.3? The clock is
> > ticking for 3.2 and there is not much runway to fix stuff.
> 
> Sometimes guest changes expose bugs in the host. Its my understanding
> that hosts should be kept uptodate so that it can serve both old and new
> guests well.

In an ideal world yes but we need to balance this against breaking stuff
which is still widely used. It seems like in this case we may have
gotten the balance wrong because people are reporting bugs.

What's wrong with only doing this reset if we know we are kexec'd? If
that can't be automatically detected then e.g. using an explicit
reset_watches command line option. You could even make a tenuous
argument for hanging this off reset_devices?

[...]
> Perhaps we should figure out what exactly EC2 is using as host and why
> it only breaks with upstream kernels.

and in the meantime we leave upstream (and any distros which picks up a
new enough kernel) on EC2? I think at this stage in the rc cycle we'd be
better off reverting and trying again for 3.3.

>  So far I havent received reports
> for SLES11 guests. SP1 got an update recently, so their HVM guests would
> have seen the hang as well. The not yet released SP2 sends
> XS_RESET_WATCHES as well since quite some time.

This thread contains 3 reports of actual regressions. Stefan explicitly
reported an EC2 bug and a reproduction on 3.4.3 and Alessandro by
implication has reported breakage in his environment.

Ian.


> 
> 
> Olaf
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 20 10:12:13 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 Dec 2011 10:12:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rcwfu-0000uZ-KN; Tue, 20 Dec 2011 10:11:58 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rcwft-0000uC-4h
	for xen-devel@lists.xensource.com; Tue, 20 Dec 2011 10:11:57 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1324375910!6173035!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzQwMQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29106 invoked from network); 20 Dec 2011 10:11:51 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Dec 2011 10:11:51 -0000
X-IronPort-AV: E=Sophos;i="4.71,381,1320624000"; 
   d="scan'208";a="9573140"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Dec 2011 10:11:50 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 20 Dec 2011 10:11:50 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Date: Tue, 20 Dec 2011 10:11:50 +0000
In-Reply-To: <20111216113300.GA4854@aepfle.de>
References: <4EEA4877.8010307@canonical.com>
	<20111215193942.GA7640@andromeda.dapyr.net>
	<20111216113300.GA4854@aepfle.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1324375910.23729.31.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefan Bader <stefan.bader@canonical.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] xenbus and the message of doom
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2011-12-16 at 11:33 +0000, Olaf Hering wrote:
> On Thu, Dec 15, Konrad Rzeszutek Wilk wrote:
> 
> > On Thu, Dec 15, 2011 at 08:20:23PM +0100, Stefan Bader wrote:
> > > I was investigating a bug report[1] about newer kernels (>3.1) not booting as
> > > HVM guests on Amazon EC2. For some reason git bisect did give the some pain, but
> > > it lead me at least close and with some crash dump data I think I figured the
> > > problem.
> > 
> > Stefan, thanks for finding this.
> > 
> > Olaf, what are your thoughts? Should I prep a patch to revert the patch
> > below and then we can work on 3.3 and rethink this in 3.3? The clock is
> > ticking for 3.2 and there is not much runway to fix stuff.
> 
> Sometimes guest changes expose bugs in the host. Its my understanding
> that hosts should be kept uptodate so that it can serve both old and new
> guests well.

In an ideal world yes but we need to balance this against breaking stuff
which is still widely used. It seems like in this case we may have
gotten the balance wrong because people are reporting bugs.

What's wrong with only doing this reset if we know we are kexec'd? If
that can't be automatically detected then e.g. using an explicit
reset_watches command line option. You could even make a tenuous
argument for hanging this off reset_devices?

[...]
> Perhaps we should figure out what exactly EC2 is using as host and why
> it only breaks with upstream kernels.

and in the meantime we leave upstream (and any distros which picks up a
new enough kernel) on EC2? I think at this stage in the rc cycle we'd be
better off reverting and trying again for 3.3.

>  So far I havent received reports
> for SLES11 guests. SP1 got an update recently, so their HVM guests would
> have seen the hang as well. The not yet released SP2 sends
> XS_RESET_WATCHES as well since quite some time.

This thread contains 3 reports of actual regressions. Stefan explicitly
reported an EC2 bug and a reproduction on 3.4.3 and Alessandro by
implication has reported breakage in his environment.

Ian.


> 
> 
> Olaf
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 20 10:17:45 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 Dec 2011 10:17:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rcwl9-0001CT-Pt; Tue, 20 Dec 2011 10:17:23 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1Rcwl9-0001Bt-0x
	for xen-devel@lists.xensource.com; Tue, 20 Dec 2011 10:17:23 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1324376235!6226256!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDk1NDk=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6081 invoked from network); 20 Dec 2011 10:17:16 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Dec 2011 10:17:16 -0000
X-IronPort-AV: E=Sophos;i="4.71,381,1320642000"; d="scan'208";a="20138345"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Dec 2011 05:17:15 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Tue, 20 Dec 2011 05:17:15 -0500
Received: from [10.80.2.24] (elijah.uk.xensource.com [10.80.2.24])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pBKAHC9X028623;
	Tue, 20 Dec 2011 02:17:13 -0800
From: George Dunlap <george.dunlap@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1324372056.23729.8.camel@zakaz.uk.xensource.com>
References: <114495d1ff947737518b.1324332781@wsm-ep-n0>
	<1324372056.23729.8.camel@zakaz.uk.xensource.com>
Date: Tue, 20 Dec 2011 10:21:08 +0000
Message-ID: <1324376468.2143.148.camel@elijah>
MIME-Version: 1.0
X-Mailer: Evolution 2.28.3 
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Hui Lv <hui.lv@intel.com>
Subject: Re: [Xen-devel] [PATCH] xen/sched_credit: Use delay to control
 scheduling frequency
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2011-12-20 at 09:07 +0000, Ian Campbell wrote:
>  
> > +/* Scheduler generic parameters
> > +*/
> > +extern int sched_ratelimit_us;
> 
> If this is generic then it seems like xen/sched.h is the right place for
> it.

Yes, this should be declared in xen/include/xen/sched.h.

> Is it really generic though if only the credit scheduler applies it?

The concept is generic enough that I think saying, "This is the control,
not all schedulers implement it" makes sense.  credit2 *may* in the
future have use for such a control; at which point it would be a bit
asinine to have two switches, named "credit_sched_ratelimit_us" and
"credit2_sched_ratelimit_us".

> > +    /* If we have schedule rate limiting enabled, check to see
> > +     * how long we've run for. */
> > +    if ( !tasklet_work_scheduled
> > +         && sched_ratelimit_us
> > +         && vcpu_runnable(current)
> > +         && !is_idle_vcpu(current)
> > +         && runtime < MICROSECS(sched_ratelimit_us) )
> > +    {
> > +        snext = scurr;
> > +        snext->start_time += now;
> > +        perfc_incr(delay_ms);
> > +        tslice = MICROSECS(sched_ratelimit_us);
> > +        ret.migrated = 0;
> > +        goto out;
> > +    }
> > +    else
> > +    {
> 
> This is the same comment as the next block below, does it really apply
> here too?
> 
> Since the previous if block ends with a goto the else clause is a bit
> redundant.

Yeah, probably better w/o the else.

> > +/* Default scheduling rate limit: 1ms 
> > + * It's not recommended to set this value bigger than "sched_credit_tslice_ms" 
> > + * otherwise, something weired may happen

Hui, "something weird may happen" is fine for informal speech, but for
comments we tend to use more formal language.  I might say something
like this:

"The behavior when sched_ratelimit_us is greater than
sched_credit_tslice_ms is undefined."

 -George


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 20 10:17:45 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 Dec 2011 10:17:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rcwl9-0001CT-Pt; Tue, 20 Dec 2011 10:17:23 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1Rcwl9-0001Bt-0x
	for xen-devel@lists.xensource.com; Tue, 20 Dec 2011 10:17:23 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1324376235!6226256!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDk1NDk=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6081 invoked from network); 20 Dec 2011 10:17:16 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Dec 2011 10:17:16 -0000
X-IronPort-AV: E=Sophos;i="4.71,381,1320642000"; d="scan'208";a="20138345"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Dec 2011 05:17:15 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Tue, 20 Dec 2011 05:17:15 -0500
Received: from [10.80.2.24] (elijah.uk.xensource.com [10.80.2.24])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pBKAHC9X028623;
	Tue, 20 Dec 2011 02:17:13 -0800
From: George Dunlap <george.dunlap@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1324372056.23729.8.camel@zakaz.uk.xensource.com>
References: <114495d1ff947737518b.1324332781@wsm-ep-n0>
	<1324372056.23729.8.camel@zakaz.uk.xensource.com>
Date: Tue, 20 Dec 2011 10:21:08 +0000
Message-ID: <1324376468.2143.148.camel@elijah>
MIME-Version: 1.0
X-Mailer: Evolution 2.28.3 
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Hui Lv <hui.lv@intel.com>
Subject: Re: [Xen-devel] [PATCH] xen/sched_credit: Use delay to control
 scheduling frequency
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2011-12-20 at 09:07 +0000, Ian Campbell wrote:
>  
> > +/* Scheduler generic parameters
> > +*/
> > +extern int sched_ratelimit_us;
> 
> If this is generic then it seems like xen/sched.h is the right place for
> it.

Yes, this should be declared in xen/include/xen/sched.h.

> Is it really generic though if only the credit scheduler applies it?

The concept is generic enough that I think saying, "This is the control,
not all schedulers implement it" makes sense.  credit2 *may* in the
future have use for such a control; at which point it would be a bit
asinine to have two switches, named "credit_sched_ratelimit_us" and
"credit2_sched_ratelimit_us".

> > +    /* If we have schedule rate limiting enabled, check to see
> > +     * how long we've run for. */
> > +    if ( !tasklet_work_scheduled
> > +         && sched_ratelimit_us
> > +         && vcpu_runnable(current)
> > +         && !is_idle_vcpu(current)
> > +         && runtime < MICROSECS(sched_ratelimit_us) )
> > +    {
> > +        snext = scurr;
> > +        snext->start_time += now;
> > +        perfc_incr(delay_ms);
> > +        tslice = MICROSECS(sched_ratelimit_us);
> > +        ret.migrated = 0;
> > +        goto out;
> > +    }
> > +    else
> > +    {
> 
> This is the same comment as the next block below, does it really apply
> here too?
> 
> Since the previous if block ends with a goto the else clause is a bit
> redundant.

Yeah, probably better w/o the else.

> > +/* Default scheduling rate limit: 1ms 
> > + * It's not recommended to set this value bigger than "sched_credit_tslice_ms" 
> > + * otherwise, something weired may happen

Hui, "something weird may happen" is fine for informal speech, but for
comments we tend to use more formal language.  I might say something
like this:

"The behavior when sched_ratelimit_us is greater than
sched_credit_tslice_ms is undefined."

 -George


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 20 10:18:10 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 Dec 2011 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.xensource.com>)
	id 1Rcwlh-0001G1-85; Tue, 20 Dec 2011 10:17:57 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <250716708@qq.com>) id 1Rcwlf-0001FO-Oh
	for xen-devel@lists.xensource.com; Tue, 20 Dec 2011 10:17:55 +0000
X-Env-Sender: 250716708@qq.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1324376268!8147336!1
X-Originating-IP: [64.71.138.43]
X-SpamReason: No, hits=2.9 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA2NC43MS4xMzguNDMgPT4gMjgxOTQx\n,sa_preprocessor: 
	QmFkIElQOiA2NC43MS4xMzguNDMgPT4gMjgxOTQx\n,FROM_ALL_NUMS,
	FROM_STARTS_WITH_NUMS,HTML_10_20,HTML_MESSAGE,MIME_BASE64_TEXT,
	MIME_BOUND_NEXTPART,received_headers: No Received headers
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27680 invoked from network); 20 Dec 2011 10:17:49 -0000
Received: from smtpbg52.qq.com (HELO smtpbg52.qq.com) (64.71.138.43)
	by server-7.tower-21.messagelabs.com with SMTP;
	20 Dec 2011 10:17:49 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qq.com; s=s0907;
	t=1324376268; bh=9aVHJHCAzBQ97Z+kYZW5Eqechfa9SWr3CFOhw62EouE=;
	h=X-QQ-SSF:X-HAS-ATTACH:X-QQ-BUSINESS-ORIGIN:X-Originating-IP:
	X-QQ-STYLE:X-QQ-mid:From:To:Subject:Mime-Version:Content-Type:
	Content-Transfer-Encoding:Date:X-Priority:Message-ID:X-QQ-MIME:
	X-Mailer:X-QQ-Mailer;
	b=j1Mtp7tkYEIgEwDRc4FpEA7Eehwwj/dHmkrPkghVy5WtQDyORWFFkr629Y4f14q7U
	juycqWK2xetQWL/T0bTHX34NB7vKg/YoKXJAmpEKvC9nYqKlH7uLhxm89S9Jqu8
X-QQ-SSF: 00000000000000F0000000000000000
X-HAS-ATTACH: no
X-QQ-BUSINESS-ORIGIN: 2
X-Originating-IP: 118.192.67.234
X-QQ-STYLE: 
X-QQ-mid: webmail193t1324376265t2047422
From: "=?gbk?B?oei9S+y2YXdhcmU=?=" <250716708@qq.com>
To: "=?gbk?B?eGVuLWRldmVs?=" <xen-devel@lists.xensource.com>
Mime-Version: 1.0
Date: Tue, 20 Dec 2011 18:17:45 +0800
X-Priority: 3
Message-ID: <tencent_5D24BF254F5D791656749B85@qq.com>
X-QQ-MIME: TCMime 1.0 by Tencent
X-Mailer: QQMail 2.x
X-QQ-Mailer: QQMail 2.x
Subject: [Xen-devel] how to create memory snapshot of vm based on hvm
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============4914425913916065907=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a multi-part message in MIME format.

--===============4914425913916065907==
Content-Type: multipart/alternative;
	boundary="----=_NextPart_4EF060C9_DCA4E330_6A5C6BA0"
Content-Transfer-Encoding: 8Bit

This is a multi-part message in MIME format.

------=_NextPart_4EF060C9_DCA4E330_6A5C6BA0
Content-Type: text/plain;
	charset="gbk"
Content-Transfer-Encoding: base64

SSB3YW50IHRvIGNyZWF0ZSBhIG1lbW9yeSBzbmFwc2hvdCBmaWxlIChzdWNoIGFzIG1tLnNu
YXApIG9mIGN1cnJlbnQgdmlydHVhbCBtYWNoaW5lIGFuZCAgdGhlIG1tLnNuYXAgY2FuIGJl
IHVzZWQgYXMgYSBhcmcgb2YgcWVtdSBjbWQtbGluZSBmb3IgcmVzdG9yaW5nIHRoZSBsYXN0
IG1lbW9yeSBjb25kaXRpb24uDQogICAgQmVzaWRlcywgaXMgdGhlcmUgYW55IGRlYnVnaW5n
IHRvb2wgZm9yIFFFTVUgUEMgZW11bGF0b3IgdmVyc2lvbiAwLjEwLjU/DQogICAgIEkgYW0g
bm90IHZlcnkgY2xlYXIgYWJvdXQgdGhlIHN0cnVjdHVyZSBvZiB0aGUgcWVtdS1kbSBzb3Vy
Y2UgY29kZS4gQWx0aG91Z2ggb2JzZXJ2aW5nIHRoZSBvdXRwdXQgb2YgZXhlY3V0aW9uIGlz
IHRoZSBzdHJhaWdodGZvcndhcmQgd2F5LCBoaWdoIGZyZXF1ZW5jeSBvZiBwcmludGYgIGFu
ZCByZS1jb21wbGluZyBpcyB0b28gaW5jb3ZlbmllbnQgdG8gcHV0IGludG8gZWZmZWN0Lg==

------=_NextPart_4EF060C9_DCA4E330_6A5C6BA0
Content-Type: text/html;
	charset="gbk"
Content-Transfer-Encoding: base64

PERJVj4mbmJzcDsmbmJzcDsmbmJzcDsgSSB3YW50IHRvIGNyZWF0ZSBhIG1lbW9yeSBzbmFw
c2hvdCBmaWxlIChzdWNoIGFzIG1tLnNuYXApIG9mIGN1cnJlbnQgdmlydHVhbCBtYWNoaW5l
IGFuZCZuYnNwOyB0aGUgbW0uc25hcCBjYW4gYmUgdXNlZCBhcyBhIGFyZyBvZiBxZW11IGNt
ZC1saW5lIGZvciByZXN0b3JpbmcgdGhlIGxhc3QgbWVtb3J5IGNvbmRpdGlvbi48L0RJVj4N
CjxESVY+Jm5ic3A7Jm5ic3A7IEJlc2lkZXMsIGlzIHRoZXJlIGFueSBkZWJ1Z2luZyB0b29s
IGZvciBRRU1VIFBDIGVtdWxhdG9yIHZlcnNpb24gMC4xMC41PzwvRElWPg0KPERJVj4mbmJz
cDsmbmJzcDsmbmJzcDsgSSBhbSBub3QgdmVyeSBjbGVhciBhYm91dCB0aGUgc3RydWN0dXJl
IG9mIHRoZSBxZW11LWRtIHNvdXJjZSBjb2RlLiBBbHRob3VnaCBvYnNlcnZpbmcgdGhlIG91
dHB1dCBvZiBleGVjdXRpb24gaXMgdGhlIHN0cmFpZ2h0Zm9yd2FyZCB3YXksIGhpZ2ggZnJl
cXVlbmN5IG9mIHByaW50ZiZuYnNwOyBhbmQgcmUtY29tcGxpbmcgaXMgdG9vIGluY292ZW5p
ZW50IHRvIHB1dCBpbnRvIGVmZmVjdC48L0RJVj4=

------=_NextPart_4EF060C9_DCA4E330_6A5C6BA0--



--===============4914425913916065907==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============4914425913916065907==--



From xen-devel-bounces@lists.xensource.com Tue Dec 20 10:18:10 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 Dec 2011 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.xensource.com>)
	id 1Rcwlh-0001G1-85; Tue, 20 Dec 2011 10:17:57 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <250716708@qq.com>) id 1Rcwlf-0001FO-Oh
	for xen-devel@lists.xensource.com; Tue, 20 Dec 2011 10:17:55 +0000
X-Env-Sender: 250716708@qq.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1324376268!8147336!1
X-Originating-IP: [64.71.138.43]
X-SpamReason: No, hits=2.9 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA2NC43MS4xMzguNDMgPT4gMjgxOTQx\n,sa_preprocessor: 
	QmFkIElQOiA2NC43MS4xMzguNDMgPT4gMjgxOTQx\n,FROM_ALL_NUMS,
	FROM_STARTS_WITH_NUMS,HTML_10_20,HTML_MESSAGE,MIME_BASE64_TEXT,
	MIME_BOUND_NEXTPART,received_headers: No Received headers
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27680 invoked from network); 20 Dec 2011 10:17:49 -0000
Received: from smtpbg52.qq.com (HELO smtpbg52.qq.com) (64.71.138.43)
	by server-7.tower-21.messagelabs.com with SMTP;
	20 Dec 2011 10:17:49 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qq.com; s=s0907;
	t=1324376268; bh=9aVHJHCAzBQ97Z+kYZW5Eqechfa9SWr3CFOhw62EouE=;
	h=X-QQ-SSF:X-HAS-ATTACH:X-QQ-BUSINESS-ORIGIN:X-Originating-IP:
	X-QQ-STYLE:X-QQ-mid:From:To:Subject:Mime-Version:Content-Type:
	Content-Transfer-Encoding:Date:X-Priority:Message-ID:X-QQ-MIME:
	X-Mailer:X-QQ-Mailer;
	b=j1Mtp7tkYEIgEwDRc4FpEA7Eehwwj/dHmkrPkghVy5WtQDyORWFFkr629Y4f14q7U
	juycqWK2xetQWL/T0bTHX34NB7vKg/YoKXJAmpEKvC9nYqKlH7uLhxm89S9Jqu8
X-QQ-SSF: 00000000000000F0000000000000000
X-HAS-ATTACH: no
X-QQ-BUSINESS-ORIGIN: 2
X-Originating-IP: 118.192.67.234
X-QQ-STYLE: 
X-QQ-mid: webmail193t1324376265t2047422
From: "=?gbk?B?oei9S+y2YXdhcmU=?=" <250716708@qq.com>
To: "=?gbk?B?eGVuLWRldmVs?=" <xen-devel@lists.xensource.com>
Mime-Version: 1.0
Date: Tue, 20 Dec 2011 18:17:45 +0800
X-Priority: 3
Message-ID: <tencent_5D24BF254F5D791656749B85@qq.com>
X-QQ-MIME: TCMime 1.0 by Tencent
X-Mailer: QQMail 2.x
X-QQ-Mailer: QQMail 2.x
Subject: [Xen-devel] how to create memory snapshot of vm based on hvm
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============4914425913916065907=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a multi-part message in MIME format.

--===============4914425913916065907==
Content-Type: multipart/alternative;
	boundary="----=_NextPart_4EF060C9_DCA4E330_6A5C6BA0"
Content-Transfer-Encoding: 8Bit

This is a multi-part message in MIME format.

------=_NextPart_4EF060C9_DCA4E330_6A5C6BA0
Content-Type: text/plain;
	charset="gbk"
Content-Transfer-Encoding: base64

SSB3YW50IHRvIGNyZWF0ZSBhIG1lbW9yeSBzbmFwc2hvdCBmaWxlIChzdWNoIGFzIG1tLnNu
YXApIG9mIGN1cnJlbnQgdmlydHVhbCBtYWNoaW5lIGFuZCAgdGhlIG1tLnNuYXAgY2FuIGJl
IHVzZWQgYXMgYSBhcmcgb2YgcWVtdSBjbWQtbGluZSBmb3IgcmVzdG9yaW5nIHRoZSBsYXN0
IG1lbW9yeSBjb25kaXRpb24uDQogICAgQmVzaWRlcywgaXMgdGhlcmUgYW55IGRlYnVnaW5n
IHRvb2wgZm9yIFFFTVUgUEMgZW11bGF0b3IgdmVyc2lvbiAwLjEwLjU/DQogICAgIEkgYW0g
bm90IHZlcnkgY2xlYXIgYWJvdXQgdGhlIHN0cnVjdHVyZSBvZiB0aGUgcWVtdS1kbSBzb3Vy
Y2UgY29kZS4gQWx0aG91Z2ggb2JzZXJ2aW5nIHRoZSBvdXRwdXQgb2YgZXhlY3V0aW9uIGlz
IHRoZSBzdHJhaWdodGZvcndhcmQgd2F5LCBoaWdoIGZyZXF1ZW5jeSBvZiBwcmludGYgIGFu
ZCByZS1jb21wbGluZyBpcyB0b28gaW5jb3ZlbmllbnQgdG8gcHV0IGludG8gZWZmZWN0Lg==

------=_NextPart_4EF060C9_DCA4E330_6A5C6BA0
Content-Type: text/html;
	charset="gbk"
Content-Transfer-Encoding: base64

PERJVj4mbmJzcDsmbmJzcDsmbmJzcDsgSSB3YW50IHRvIGNyZWF0ZSBhIG1lbW9yeSBzbmFw
c2hvdCBmaWxlIChzdWNoIGFzIG1tLnNuYXApIG9mIGN1cnJlbnQgdmlydHVhbCBtYWNoaW5l
IGFuZCZuYnNwOyB0aGUgbW0uc25hcCBjYW4gYmUgdXNlZCBhcyBhIGFyZyBvZiBxZW11IGNt
ZC1saW5lIGZvciByZXN0b3JpbmcgdGhlIGxhc3QgbWVtb3J5IGNvbmRpdGlvbi48L0RJVj4N
CjxESVY+Jm5ic3A7Jm5ic3A7IEJlc2lkZXMsIGlzIHRoZXJlIGFueSBkZWJ1Z2luZyB0b29s
IGZvciBRRU1VIFBDIGVtdWxhdG9yIHZlcnNpb24gMC4xMC41PzwvRElWPg0KPERJVj4mbmJz
cDsmbmJzcDsmbmJzcDsgSSBhbSBub3QgdmVyeSBjbGVhciBhYm91dCB0aGUgc3RydWN0dXJl
IG9mIHRoZSBxZW11LWRtIHNvdXJjZSBjb2RlLiBBbHRob3VnaCBvYnNlcnZpbmcgdGhlIG91
dHB1dCBvZiBleGVjdXRpb24gaXMgdGhlIHN0cmFpZ2h0Zm9yd2FyZCB3YXksIGhpZ2ggZnJl
cXVlbmN5IG9mIHByaW50ZiZuYnNwOyBhbmQgcmUtY29tcGxpbmcgaXMgdG9vIGluY292ZW5p
ZW50IHRvIHB1dCBpbnRvIGVmZmVjdC48L0RJVj4=

------=_NextPart_4EF060C9_DCA4E330_6A5C6BA0--



--===============4914425913916065907==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============4914425913916065907==--



From xen-devel-bounces@lists.xensource.com Tue Dec 20 10:23:16 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 Dec 2011 10: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.xensource.com>)
	id 1RcwqZ-0001kC-0L; Tue, 20 Dec 2011 10:22:59 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1RcwqX-0001jl-0N
	for xen-devel@lists.xensource.com; Tue, 20 Dec 2011 10:22:57 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1324376569!8145541!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDk1NDk=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14103 invoked from network); 20 Dec 2011 10:22:51 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Dec 2011 10:22:51 -0000
X-IronPort-AV: E=Sophos;i="4.71,381,1320642000"; d="scan'208";a="20138514"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Dec 2011 05:22:49 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Tue, 20 Dec 2011 05:22:49 -0500
Received: from [10.80.2.24] (elijah.uk.xensource.com [10.80.2.24])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pBKAMj6t028632;
	Tue, 20 Dec 2011 02:22:46 -0800
From: George Dunlap <george.dunlap@citrix.com>
To: Dario Faggioli <raistlin@linux.it>
In-Reply-To: <1324375765.6616.9.camel@Abyss>
References: <114495d1ff947737518b.1324332781@wsm-ep-n0>
	<1324372056.23729.8.camel@zakaz.uk.xensource.com>
	<C10D3FB0CD45994C8A51FEC1227CE22F39412A99CE@shsmsx502.ccr.corp.intel.com>
	<1324375765.6616.9.camel@Abyss>
Date: Tue, 20 Dec 2011 10:26:42 +0000
Message-ID: <1324376802.2143.154.camel@elijah>
MIME-Version: 1.0
X-Mailer: Evolution 2.28.3 
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Jan Beulich <JBeulich@suse.com>, "Lv, Hui" <hui.lv@intel.com>
Subject: Re: [Xen-devel] [PATCH] xen/sched_credit: Use delay to control
 scheduling frequency
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2011-12-20 at 10:09 +0000, Dario Faggioli wrote:
> On Tue, 2011-12-20 at 17:44 +0800, Lv, Hui wrote: 
> > > It that constraint enforced anywhere?
> > 
> > Currently, it's not constraint enforced. 
> > I think George have gave the explanation in yesterday's discussion.
> > 
> I think that too, but maybe you can print some kind of warning when it
> happens?

I guess the consensus is that we should put in some effort to make the
interface more polished.

How about this:

First, add a ratelimit_us element to csched_priv, just like the current
tslice_ms element.

When the scheduler comes up (in csched_init), it checks to see if
MICROSECS(sched_ratelimit_us) > MILLISECS(sched_credit_tslice_ms); if
so, it prints a warning, and sets prv->ratelimit_us to
1000*prv->tslice_ms.

In the future, when we implement the domctls to change a scheduler's
ratelimit_us, and tslice_ms, we disallow changes which would violate the
"ratelimit < tslice" rule (returning -EINVAL or something like that).

Thoughts?

 -George


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 20 10:23:16 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 Dec 2011 10: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.xensource.com>)
	id 1RcwqZ-0001kC-0L; Tue, 20 Dec 2011 10:22:59 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1RcwqX-0001jl-0N
	for xen-devel@lists.xensource.com; Tue, 20 Dec 2011 10:22:57 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1324376569!8145541!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDk1NDk=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14103 invoked from network); 20 Dec 2011 10:22:51 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Dec 2011 10:22:51 -0000
X-IronPort-AV: E=Sophos;i="4.71,381,1320642000"; d="scan'208";a="20138514"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Dec 2011 05:22:49 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Tue, 20 Dec 2011 05:22:49 -0500
Received: from [10.80.2.24] (elijah.uk.xensource.com [10.80.2.24])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pBKAMj6t028632;
	Tue, 20 Dec 2011 02:22:46 -0800
From: George Dunlap <george.dunlap@citrix.com>
To: Dario Faggioli <raistlin@linux.it>
In-Reply-To: <1324375765.6616.9.camel@Abyss>
References: <114495d1ff947737518b.1324332781@wsm-ep-n0>
	<1324372056.23729.8.camel@zakaz.uk.xensource.com>
	<C10D3FB0CD45994C8A51FEC1227CE22F39412A99CE@shsmsx502.ccr.corp.intel.com>
	<1324375765.6616.9.camel@Abyss>
Date: Tue, 20 Dec 2011 10:26:42 +0000
Message-ID: <1324376802.2143.154.camel@elijah>
MIME-Version: 1.0
X-Mailer: Evolution 2.28.3 
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Jan Beulich <JBeulich@suse.com>, "Lv, Hui" <hui.lv@intel.com>
Subject: Re: [Xen-devel] [PATCH] xen/sched_credit: Use delay to control
 scheduling frequency
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2011-12-20 at 10:09 +0000, Dario Faggioli wrote:
> On Tue, 2011-12-20 at 17:44 +0800, Lv, Hui wrote: 
> > > It that constraint enforced anywhere?
> > 
> > Currently, it's not constraint enforced. 
> > I think George have gave the explanation in yesterday's discussion.
> > 
> I think that too, but maybe you can print some kind of warning when it
> happens?

I guess the consensus is that we should put in some effort to make the
interface more polished.

How about this:

First, add a ratelimit_us element to csched_priv, just like the current
tslice_ms element.

When the scheduler comes up (in csched_init), it checks to see if
MICROSECS(sched_ratelimit_us) > MILLISECS(sched_credit_tslice_ms); if
so, it prints a warning, and sets prv->ratelimit_us to
1000*prv->tslice_ms.

In the future, when we implement the domctls to change a scheduler's
ratelimit_us, and tslice_ms, we disallow changes which would violate the
"ratelimit < tslice" rule (returning -EINVAL or something like that).

Thoughts?

 -George


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 20 10:44:46 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 Dec 2011 10: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.xensource.com>)
	id 1RcxBI-00027f-3B; Tue, 20 Dec 2011 10:44:24 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RcxBG-00027a-6L
	for xen-devel@lists.xensource.com; Tue, 20 Dec 2011 10:44:22 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1324377855!6221924!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24797 invoked from network); 20 Dec 2011 10:44:15 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-8.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 20 Dec 2011 10:44:15 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 20 Dec 2011 10:44:14 +0000
Message-Id: <4EF075430200007800069164@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 20 Dec 2011 10:45:07 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Dario Faggioli" <raistlin@linux.it>
References: <1324319661.2599.28.camel@Solace>
	<4EF0653C0200007800069123@nat28.tlf.novell.com>
	<1324375489.6616.7.camel@Abyss>
In-Reply-To: <1324375489.6616.7.camel@Abyss>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Wei Wang2 <wei.wang2@amd.com>, Tim Deegan <tim@xen.org>,
	xen-devel@lists.xensource.com,
	"allen.m.kay@intel.com" <allen.m.kay@intel.com>
Subject: Re: [Xen-devel] [PATCH 0 of 3] Deal with IOMMU faults in softirq
	context.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 20.12.11 at 11:04, Dario Faggioli <raistlin@linux.it> wrote:
> On Tue, 2011-12-20 at 09:36 +0000, Jan Beulich wrote:=20
>> These look good to me (apart from a minor indentation issue in the
>> 2nd patch),
>>
> Oh, you mean those 3 spaces instead of 4 within
> do_amd_iommu_page_fault()? I've no idea of how that could have happened
> and will fix that, thanks.

It looked like no leading space at all in my mail viewer.

> If that's fine I'll wait a bit more to see if other reviews pop up and
> then resubmit the series.
> 
>> but we'd surely like to have an ack from the respective
>> maintainers.
>>
> Ok... Do I Cc-ed them correctly? :-)

Yes (except that Allen isn't really maintaining VT-d code anymore, but
there was also no successor nominated by Intel so far; perhaps he can
find time to take a look nevertheless).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 20 10:44:46 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 Dec 2011 10: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.xensource.com>)
	id 1RcxBI-00027f-3B; Tue, 20 Dec 2011 10:44:24 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RcxBG-00027a-6L
	for xen-devel@lists.xensource.com; Tue, 20 Dec 2011 10:44:22 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1324377855!6221924!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24797 invoked from network); 20 Dec 2011 10:44:15 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-8.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 20 Dec 2011 10:44:15 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 20 Dec 2011 10:44:14 +0000
Message-Id: <4EF075430200007800069164@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 20 Dec 2011 10:45:07 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Dario Faggioli" <raistlin@linux.it>
References: <1324319661.2599.28.camel@Solace>
	<4EF0653C0200007800069123@nat28.tlf.novell.com>
	<1324375489.6616.7.camel@Abyss>
In-Reply-To: <1324375489.6616.7.camel@Abyss>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Wei Wang2 <wei.wang2@amd.com>, Tim Deegan <tim@xen.org>,
	xen-devel@lists.xensource.com,
	"allen.m.kay@intel.com" <allen.m.kay@intel.com>
Subject: Re: [Xen-devel] [PATCH 0 of 3] Deal with IOMMU faults in softirq
	context.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 20.12.11 at 11:04, Dario Faggioli <raistlin@linux.it> wrote:
> On Tue, 2011-12-20 at 09:36 +0000, Jan Beulich wrote:=20
>> These look good to me (apart from a minor indentation issue in the
>> 2nd patch),
>>
> Oh, you mean those 3 spaces instead of 4 within
> do_amd_iommu_page_fault()? I've no idea of how that could have happened
> and will fix that, thanks.

It looked like no leading space at all in my mail viewer.

> If that's fine I'll wait a bit more to see if other reviews pop up and
> then resubmit the series.
> 
>> but we'd surely like to have an ack from the respective
>> maintainers.
>>
> Ok... Do I Cc-ed them correctly? :-)

Yes (except that Allen isn't really maintaining VT-d code anymore, but
there was also no successor nominated by Intel so far; perhaps he can
find time to take a look nevertheless).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 20 10:51:58 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 Dec 2011 10:51:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RcxIF-0002H8-Vm; Tue, 20 Dec 2011 10:51:35 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1RcxIE-0002Gr-Qm
	for xen-devel@lists.xensource.com; Tue, 20 Dec 2011 10:51:35 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-12.tower-182.messagelabs.com!1324378288!7978845!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17583 invoked from network); 20 Dec 2011 10:51:28 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-12.tower-182.messagelabs.com with SMTP;
	20 Dec 2011 10:51:28 -0000
Received: from [62.94.181.91] (account d.faggioli@sssup.it HELO [192.168.0.20])
	by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 74046349; Tue, 20 Dec 2011 11:51:26 +0100
Message-ID: <1324378284.6616.14.camel@Abyss>
From: Dario Faggioli <raistlin@linux.it>
To: George Dunlap <george.dunlap@citrix.com>
Date: Tue, 20 Dec 2011 11:51:24 +0100
In-Reply-To: <1324376802.2143.154.camel@elijah>
References: <114495d1ff947737518b.1324332781@wsm-ep-n0>
	<1324372056.23729.8.camel@zakaz.uk.xensource.com>
	<C10D3FB0CD45994C8A51FEC1227CE22F39412A99CE@shsmsx502.ccr.corp.intel.com>
	<1324375765.6616.9.camel@Abyss> <1324376802.2143.154.camel@elijah>
Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwCAIAAADYYG7QAAAAA3NCSVQICAjb4U/gAAAVx0lEQVRYwzWY6a/d953XP9/tt51zfme/+37t692OtzhxtzTuJFPaTDVt0cDQeTIajToSKBJICBASQkI8Q1Q8ACQEhUGgCsF0OrSkaRLaxknqOl7i9dq++3727bd/Vx5k+CNe7+WFvvkvbvoywAZF1BMYOFNFbqWEW1gho42yB9jJq1QihEGVCh7BxrXpeNlxbJZmcmNvkArIhAIMJd+drlmA0aiXuBbN5x3Pxq6NS6X85l5/rxNnGtJYgAYhgVCa8UxqAwgQIABAGGMD1JWtS7/48Vy0W1k5GxXnmh41br1y6fxXv3LCEPXLu3vv3N3t2kXPAi0EIjTjnDGcKawzHceZl3N0mIExrmfnGS1iSij2pxgDxJhlsOFID8LUsVjecXvNPiJg2ZYySiODGUVcAwBCCAAMAIAhNc82C2xvuLG8uX422VvZfHrx9Mz5P7kRR51wby188YD+8metqQWBLa00F1JIlQk5imIhle+XBsHI9/PVUoFCBp7JOZbSjGiS92mx7IE0SICRkC/Yw2GSZECpIsYYwEmWGkDGIAAAAIQAY4QMEA6Nvc7G6aaYzKQlUs/x/O99VywsZcZd33w++l9/NbN6Z905MSqPGYO10QDYGCI1EIQQGMdzkzCo+G4pb5eY7blWKhKadiZ92yYsFWoYpwhRv0A4h/4oK5Zcl9nGAMLUgEYYMAZAmhBkM6KkoYpVIRjU47SRRUuVlXRlUZ08nxDyi50na+2jV1r9tTjK/DwYqgFRLHMuYdhCMou1bg64a0M15yKiCyCcLJlJspl+e6x3QNtuv1TbKIwHxpHIZDEYorGFh32eK3h+yc06XYqA2MyyLCmk0lobAFC04NsTyCGjOAbrp5svrs/N1sqeRegKscrF2aiz1ZfJweZPjLzojB0fdPcqFcv481592Y15KiKOLBDyd
	OPw1b37JZ3Qosdspk2Eh71iZ3MmJafLE/2l4w/pjBiiRMVJKjOtLItypb18LkxCmSilAIAorQCA0nLl0lGSqY5kyCP55bFpOwvW1vo79+7vb+z5yjSF1Wg9RaNNjKxRlObPnd/c+UurPFMZPzO5cPpcIt/c/HApaZp+Jzoa6FKhcu4kogzZFGmEGgczG6v1O+8uLp1eQ0VdOrXuLFqu0mAwwZkUCBOMmJAKDAIgAJq88f1/NucwtbZqaXP9pfNnFxY++ujmI4OZVzoYHfKtxnrY2PFAS46yuJTPNzvNYXvbDJsvTfr/5PSJl3/676cbhzvPV4ccbN9KTCoHHYa5xQoZRPpglw1SEim5tzN58KSc4b1LFzEmFiMEYwCSca01MsYAAoyRUYrGgjXOXfgbg8aE5hPV8vsPPr7XHJaPn4x6MY0GjsUWvnxy+dLSB7+43W6zN77y9Q/e/3ENvMvI/dO4WftX/xzidDvrO7Mnxqt+P0kshcCyRj2pe89zKSKxVjrWWKs4balUO/s26MwgqZU2JsmkUhjAAPpr0ACA3vjKydHuAa56B2u7Hz59qDFOkD149x1n9VkW81LevvCH54b5ztiY/+rLr7zxu1+TwdEr99deD0Ln1tMw4ixVhVpuemZGYT5W8JQCgyAMR1whY1IGqRI8E1ks0m2pnqq0k6ogUpgRroBLDQgjDBgTjAEUUgDUJI16Se7sbcWdfoxdzrRUwj7aV1I7165Mnjhx+oLz2+CTyclL3/2D74ApfOFr3w4Hf7778/dmSclIzoXKTy6n2QBrjRQyBPdGQ6RVlCQ8TXScMGk8iwWErsV8Z/58J9KZ0IgbBJgQiok2BghBCCFjMACQlesvrzjY/tWtOM0EoZwCU0Ym2ag+VZ5fLOf9xZXph61s8dibtdpYnApmFe3JmX6372UByfg+wKNOt+hYSgHBNjiesW3H9SyhqEKJlE2ZHiSjrVS2c8Xm639nhEoACAzGhDCGKSVKGQ
	AwBgECxQXNuz7uD1QvQFJEeeOm0iiFBbDu/uEzwW8O+P826hu/d6v0/PTx5Y8/ee/l66/lFqdqb9xQ//pRJ+KBwfmp8U1tmkgnXqaxbPd6/V4fJ1kJ6JQhderZ1OvE/aYSfeKBAYSQQVgbI5Q2UgMgBMgYAxgBAE1U6uQKuS9e7310qzwQ2pDUghR4JU3UZji07BfFamHtIF00O839zx7ceeXaFxGY/J1Hz1sHPEGHDlnTreLkyeNXrpQLDgjtBHF+GI6i4VEYfnpwpAejvNBnUdG2qkBdw4w2Bhv0eXeZzwMfIYQ+7zKgc7VynCux73176ktXV//ix6Onq67RxIhEGTDSHybQH4Xt6LU3317f2pycmGJUVxudOZ+o6Zn764dB0YHx6dCwp88eIYSIxpLLIIziLJbSOAKEW9QlZ7Posijv5awsSw1yDMIAGMAgZBBCGGNjDEJGAdCJnI9thwHLFr3pt9+e3Wl2W41fbj1NlD51sHvmxeP1YfqMya9fvfaf//E/3T/cfPP6K8vv3Wz/3w/SxiBPaDFUeGZ6V2Sd7UOtACmkpeRSaI0wMogZYzNk05KfG5Z8q5a9bBeaA90P0kRixGyuPqddY4wwQgKAFosVQjEANjF1lFIz4/1x50g0kyR+uVi79jtf/vmHL4LKhZ7WreYWMbH5b/8zu3vHGkUZlxjrSOkzy/Px/n5fYxAxNUCNIdhIojEhmDFM3By2sWdJNlajeKmUnqiwQNuRZJ0I398LDVBkABPABgEA7o/CMEhlplzHKlZL1WJVY4LB5Ci6+p2rvRv1uxm8evba/Qe/UaPuDUEXP/kNTdJewqtV/+zlK9yQnfWtdrsVp+koEWEmpQELUwcTqrGMVZpEiUqVU43PflUzLR2pbFqkenncKniZsRNjcaAcocRmGQBQh1kIISmllJLrbG/3oCujE7PHahYo8eDu46fUqawsLzx4+vEZN/eHQcJHyVBjz5DqsYWOwDm/nmP52TF
	vY79x1O4bKcp5b7JWIQoNklRhYhvKjBkfCrf3xJ7+ijVKo+TAsQuO4wKlDsMGpRRjlYm8U+wBp57jWrYlpFRKGa7G56b/4i//x0Hj4OKU9/03Tj3e3BuvFvP1QhJmf2Zcuz/UhGiNWK3a7US8Ovvaq7/zcXenmfWqrmdKpTRLGCO9KELGhJmIOHcZLY9XGo3BBTrUJxuzCtJ8refnuDY6EwRjbaRnA3OxjQ0AUK2U4EIZrYw2gIYyzVQyNV48e9wzRt6729p5sl+2ci8/+Gy80x5hMFIBsZOyf4TIrC4Uld05bChP+kpZNo4RywAERgyTPCJgO1bBmfALzb3B5msXrg0UqxaG5QJgy0UMrIxYjAhHZ4HtJVW3uAaCUkYNGAxGKYkBd/pNC2AizxYq/LPHn9hWfb4eFxob59cakhpXmIaCnGu9u7td9MdajTsvnbxAmY94YEFojOEGEcYQAYSY4VEx79J8QQ+yiPlBFq/aE1Gt7BmTwwo7jh5wjDlxGDWKMGKMAgBsW45t2TazGWHI0hs7G1oJIgavXjmTCKcXwJeuXsv+zwexyhLmxoRix3rEUAv0++3tDweHdzafvlZfxH6RS8cYAkAPW/0Xe612t2sAwNC0nz67t+rmcgEPW82+yEgqdZImo2Gnfbge9p6AaliuGsUj5lAAoJQxKYUCDYAEhkEYFPzCXA0q9eLme0m7K6auTgUf3ynYrCzprhJHBSdYnLX3jvSoNwrMzfbW7Y9aIaCwQMHlOS83XvWTRGDLihCkoyTujpiiBAOSYTKAOAjdXAFjLGTWae0/W3skwa3WJiYnpse9BQCgwyhCCAhBwOgoDErVCd1tLc2ge4+fBKHDjJk/fsrR76BhHBoIy6VoeSlFEmxKHNpN0rGJqbDbV9KwgWj3IlWQhGGlTXuUacvKMxtJhA3oLGZJL+Nht1M/eeZaq90wGDtu7tj8cYUsIU3J8yzKAAQVimdSICmlUQ93Xxw1W8cnxhYW
	wkKhY/C8X+ufq891Wy3P4Nsg26eWolx9dLC9P+wpZBKbNnv9AiGWlipNXEP1gGNKjJIFg0lmLJOWmS2UylMU91qWXw663X4nUAYjkNRxX9zd0oj4lclykTNCAIDatqORMVpJhNY21raP9lS0+bdeWd7ePXr8wlqaXiK//qDX3P20Nr41tZASRtSwhSRCUHVsZkO3F9qkgFKJDC4QprRSmcgTSjHFBjEwjtR5hEm7xxzmunkZhL1Od2F5th+2DQJDqF2ezo8vAcbUpABAkyTjUhjJRzrRQe9CsXj9st0ZbDVeDK8M7b+Nk+7qnaevfvVAC8G5ATTx2mtLRt7+d/+WpKHrWEnRO2gPxqUtMU4UV0bbzMKISCmBIKAUAGyAzvZWrmjZ1SJS/OHde/MzE2OVeqHgX3n5qnLHO/3UIO55GAAoF0pppbTuBoOEGkqsGqPXotlLvUp1pto8ffGdXuPFbz+lsSL5YovoW+++c2q8rmyLaocinCN6VLaToZFcYoM0xpHiHFAOU8aIBpAAgFEmZNLpmFpJsk5hciYeDmsTi/fuf7bX2auWx0rjc47v7j2+BXCRUoK4QQDQaB0Zg7SRhVSxx0NfzHWPrzxfXlj76EObxxqhv1p7fOLiJd8Ujp890z46HG5tGNAIKdtloRCJUjnMMAKsMEK4RbhCAhuMElkkdozAjIb5YZToZiDM5XNntQ2u5VKtGzsbe/tbpXye1SbBvkgJAMVYEzIajTyEj83YQ7/104Xhb37WvLGwEm3shUnAMhUiM1AZz9KjVmtydrpFCAeFMaYWtQBpn0mtBpkCpZAFiGLm2KAhHaY5REEjhJUDhAcxx05hLBcnaa1UKjALE+aVqpHIJienbBAAgEt+frxURBZRBkOuNF2lC2P4fif7JXa2uD7Y3+VxQlO5GwfMyecK+Xq1WB8b6yaBJEhqhRBGGGML56s+rnhW3XeqBavoEERFkFmAkdIIQR4wjlMRxx5zUgG3769qo
	U7MzLS7w04QGcs2zPbLPgDg3qAXh8PV7fXEoPm5xWIt543nRe585djS1vN7+MXDwfZGe9Dc63XSRBwcNOIoAgQjkQqGhdGAkNEaaUW0ylnUw9g1BIdKdsK8op4hNiUSa8VFvVI5ff6sSFOG2YOnG0kii26+6BeJxbjRSZpg1wMAbDMgFjxZvb+/u/X81ntJZysYos7hcNbLjy1MPtp6gkbdqD+oF6vFSs3NeTNT04NePwQtsNZAldYGIaUUaIkkRxrCME0GSQk7HmCiDQWEAQMCGcYXjh2zjQShohiGcXb1pQvH5ueLOafgOkaK2bEiAFDFZTcc2CpayMPSWO3kUn5zbXtwNNjfffTW3/9Hd29+mISBkWRhYf7333xzZqKUBaNOp9/ziqUgwSBSJGxqy0xrYUAZLkUUpXVs5zHJQEstkAFsMGNOOgiS++s05AiACp7G8Vi1xMPk5LFjbrGUQzA3UYOHQA1mz7e3D1qDAtNTp+cZNd2B+NaXvtjvqGrRs4pETXuHR73NezcDHTsMX7n2ansYzc2drnO7K5+vzEwqrtf3okAbkxgeZyCMTy0bUY1U9v/FmMUoaHPc5LOZY7/urk9Yo3H2eu+ou1ir/urxqtHZialp98wUAGAA9XhrPaH+SJPKhB+lfL2de//uemblk0hcml34g7feOHN+5eyZk6eXpoP2YaXsdzdXv3ugb9SXSi75va9d+4f/4I+/89aNotb9ILYFnrYLHsYUAUMYGQAD1CCCSd0tfPrg/hwH0ttctgN7dDjGu0sOdqmZKlvnj88SpAGAPtnYyESKVFTP8Zw16rUOW116FOPr5fqz7b2fP36hP+7zWAkplxdmEUEF1748O/7wg59MaOv7J065NzcOnrW8nKeo48lwxStSLi3QgCkiaATYGMMMgNG1QmlfxxO9Xtn1Ro2+UnDz5z+LgzTP0Hgtl7MhzmIAwI/XVgNBAqNXTh2v5Mwwg3Z3wEfJ7OxyHHPb9SNuEi
	64Ed1RmAjm58rbHz85qdCfzi2fHfH67sj+6EX6s0/hoPvW5Mmq5MwimlCikUXtIYOYIYWUz1impU75ve6WzeHK+OKf/+AHYchVKuJRsLrTfHHY6A77AEAnZ6bBXc6ePj+1UOmPntxfkx3t5yzI5Uu7e3sYEDKmXirisisJnqxPH7Q68aD3rYVllkQJF6GUsRQmiE4j9/Wpkz9tHhGtDSUKACgOmcmQdhS1LDvLMoOwjJJ4d/ir4cfP0qaA23pxWc5N0FKhnQiLMQCgFceSFl24dPwLF4s/efe2P3llmoAbB5ZLw3gYxFE/jkdZNl8udA47KyunB72jb1Qn7c5gmGVcqJTzkVbAzY1TV89fvHR398nBYMgNikD5mhSQHWJuXM/OFaJhKLHhowAIWfjGl7b3nwbx8Nw3f9cCEDJjXAeDEQCQOGjFRzsny8FkRe43i0+fH2jIn5qZkxG/fft+rlDNlSYzxOanZxuj/hfPnLu+erCyvquSmKd6oOORkoMw+VTEb37hm6oXzdq5o2DU0akUMnbJhhgUHHeCelRBnGXDLAGDLMcrvHJ58dtvfXC4tdntCQG+bU/MTPl8sD5cIlMztSAOvvX6ceJEO3tHn7z3JG20XJleu3w1ToPdvQ0j+GS9/vWv3Xjl1Onru935W59ClnZGQ4sxi7FA8N+OBs8QOZqvD20z7fpoGDbikIMwMiNSlRG1DVWZiHiCCHUtG1vW+T/6fXDtrfZRnGSDqN8bdMbLpaS909EXaYBYKafPXl367PH9nd0gzTRRoWPnKWJ/81vfPnNy5Yc//OGt28/nHHhjoz03AD4cZdgUixULcJylFnZ7AOlYuXjj5R/9x//033cPr1VnRjKyLUtkkRYyFIJDUsv5DsWI0ZFUr/2977Gx+iCJDnu9IAgRNYVqaTjomFEEOaA2QV//8qLD0t2do62dWChIs2R8cqbgl0DJ4/NLb//dtzvd7kub2xceHQUqjJDqRmHQjQuOqyn
	ZiaKpyoRz4wuXzr70/MTyi8bR+72NEqPVTGL4a1NvIQRK5Cw3MDBz+RI6tpAAhJIzy65WEGOEYEhF5iv6+VE0F05P+f7Ui61Od4iV1hb1p6amM5USQFoh368t5IvjP/m1ylIuJAhFCGXMotQyjGCbbzX39p88Pvyv/8V2XZT3yED2sHYskteYCcIwBg0DwTVzZLkQ1XyTSuvzgUCpEglFVGMMmNSrzpEAim310sWX7j5ZI9Zc5/ARF6w651dqVSllKIWJhxF3is9XaaPNNOQsBkAdLRLCNMbNLBYGIbcgbdJu7iEpjO+aOE45fxIPl73SuFeORBpgaSwmPUp8ZutU89S1LRwazKgyFkLYY7bHnIXp4sNtoCtLtYnx8n/40Y+2d5U21PfL/+YH/5JqY7v5Ti950DksKlV4+CQnpaY441xzJUBigjMpM6N247ANOGKUKAnaOPliRILBsJ8geDDq1ZhjuzatFsMoKlBdMUbE8aDfY5S5tnvp8pWUZzzL0iR2bdbpHALA/wMUjQteOh3xIgAAAABJRU5ErkJggg==
X-Mailer: Evolution 3.2.2 (3.2.2-1.fc16) 
Mime-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Jan Beulich <JBeulich@suse.com>, "Lv, Hui" <hui.lv@intel.com>
Subject: Re: [Xen-devel] [PATCH] xen/sched_credit: Use delay to control
 scheduling frequency
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3414353275376268182=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--===============3414353275376268182==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-kWN+hrKMXvO7JFXpsTxo"


--=-kWN+hrKMXvO7JFXpsTxo
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, 2011-12-20 at 10:26 +0000, George Dunlap wrote:=20
> > I think that too, but maybe you can print some kind of warning when it
> > happens?
>=20
> I guess the consensus is that we should put in some effort to make the
> interface more polished.
>=20
Exactly! :-)

> How about this:
>=20
> First, add a ratelimit_us element to csched_priv, just like the current
> tslice_ms element.
>=20
> When the scheduler comes up (in csched_init), it checks to see if
> MICROSECS(sched_ratelimit_us) > MILLISECS(sched_credit_tslice_ms); if
> so, it prints a warning, and sets prv->ratelimit_us to
> 1000*prv->tslice_ms.
>=20
For what it counts, I'm more than fine with just printing some
"WARNING: rate-limit > time slice is nonsense", as well as doing as you
suggest... Or even with doing both! :-P=20

> In the future, when we implement the domctls to change a scheduler's
> ratelimit_us, and tslice_ms, we disallow changes which would violate the
> "ratelimit < tslice" rule (returning -EINVAL or something like that).
>
That makes a lot of sense.

Regards,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-------------------------------------------------------------------
Dario Faggioli, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
PhD Candidate, ReTiS Lab, Scuola Superiore Sant'Anna, Pisa (Italy)



--=-kWN+hrKMXvO7JFXpsTxo
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEABECAAYFAk7waKwACgkQk4XaBE3IOsRgbwCfb1trPxijD1sN4lo+FV6N1V5m
utoAn2sFfriavHtAbPkBUWC6y/ZqA3ir
=i2AM
-----END PGP SIGNATURE-----

--=-kWN+hrKMXvO7JFXpsTxo--



--===============3414353275376268182==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============3414353275376268182==--



From xen-devel-bounces@lists.xensource.com Tue Dec 20 10:51:58 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 Dec 2011 10:51:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RcxIF-0002H8-Vm; Tue, 20 Dec 2011 10:51:35 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1RcxIE-0002Gr-Qm
	for xen-devel@lists.xensource.com; Tue, 20 Dec 2011 10:51:35 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-12.tower-182.messagelabs.com!1324378288!7978845!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17583 invoked from network); 20 Dec 2011 10:51:28 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-12.tower-182.messagelabs.com with SMTP;
	20 Dec 2011 10:51:28 -0000
Received: from [62.94.181.91] (account d.faggioli@sssup.it HELO [192.168.0.20])
	by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 74046349; Tue, 20 Dec 2011 11:51:26 +0100
Message-ID: <1324378284.6616.14.camel@Abyss>
From: Dario Faggioli <raistlin@linux.it>
To: George Dunlap <george.dunlap@citrix.com>
Date: Tue, 20 Dec 2011 11:51:24 +0100
In-Reply-To: <1324376802.2143.154.camel@elijah>
References: <114495d1ff947737518b.1324332781@wsm-ep-n0>
	<1324372056.23729.8.camel@zakaz.uk.xensource.com>
	<C10D3FB0CD45994C8A51FEC1227CE22F39412A99CE@shsmsx502.ccr.corp.intel.com>
	<1324375765.6616.9.camel@Abyss> <1324376802.2143.154.camel@elijah>
Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwCAIAAADYYG7QAAAAA3NCSVQICAjb4U/gAAAVx0lEQVRYwzWY6a/d953XP9/tt51zfme/+37t692OtzhxtzTuJFPaTDVt0cDQeTIajToSKBJICBASQkI8Q1Q8ACQEhUGgCsF0OrSkaRLaxknqOl7i9dq++3727bd/Vx5k+CNe7+WFvvkvbvoywAZF1BMYOFNFbqWEW1gho42yB9jJq1QihEGVCh7BxrXpeNlxbJZmcmNvkArIhAIMJd+drlmA0aiXuBbN5x3Pxq6NS6X85l5/rxNnGtJYgAYhgVCa8UxqAwgQIABAGGMD1JWtS7/48Vy0W1k5GxXnmh41br1y6fxXv3LCEPXLu3vv3N3t2kXPAi0EIjTjnDGcKawzHceZl3N0mIExrmfnGS1iSij2pxgDxJhlsOFID8LUsVjecXvNPiJg2ZYySiODGUVcAwBCCAAMAIAhNc82C2xvuLG8uX422VvZfHrx9Mz5P7kRR51wby188YD+8metqQWBLa00F1JIlQk5imIhle+XBsHI9/PVUoFCBp7JOZbSjGiS92mx7IE0SICRkC/Yw2GSZECpIsYYwEmWGkDGIAAAAIQAY4QMEA6Nvc7G6aaYzKQlUs/x/O99VywsZcZd33w++l9/NbN6Z905MSqPGYO10QDYGCI1EIQQGMdzkzCo+G4pb5eY7blWKhKadiZ92yYsFWoYpwhRv0A4h/4oK5Zcl9nGAMLUgEYYMAZAmhBkM6KkoYpVIRjU47SRRUuVlXRlUZ08nxDyi50na+2jV1r9tTjK/DwYqgFRLHMuYdhCMou1bg64a0M15yKiCyCcLJlJspl+e6x3QNtuv1TbKIwHxpHIZDEYorGFh32eK3h+yc06XYqA2MyyLCmk0lobAFC04NsTyCGjOAbrp5svrs/N1sqeRegKscrF2aiz1ZfJweZPjLzojB0fdPcqFcv481592Y15KiKOLBDyd
	OPw1b37JZ3Qosdspk2Eh71iZ3MmJafLE/2l4w/pjBiiRMVJKjOtLItypb18LkxCmSilAIAorQCA0nLl0lGSqY5kyCP55bFpOwvW1vo79+7vb+z5yjSF1Wg9RaNNjKxRlObPnd/c+UurPFMZPzO5cPpcIt/c/HApaZp+Jzoa6FKhcu4kogzZFGmEGgczG6v1O+8uLp1eQ0VdOrXuLFqu0mAwwZkUCBOMmJAKDAIgAJq88f1/NucwtbZqaXP9pfNnFxY++ujmI4OZVzoYHfKtxnrY2PFAS46yuJTPNzvNYXvbDJsvTfr/5PSJl3/676cbhzvPV4ccbN9KTCoHHYa5xQoZRPpglw1SEim5tzN58KSc4b1LFzEmFiMEYwCSca01MsYAAoyRUYrGgjXOXfgbg8aE5hPV8vsPPr7XHJaPn4x6MY0GjsUWvnxy+dLSB7+43W6zN77y9Q/e/3ENvMvI/dO4WftX/xzidDvrO7Mnxqt+P0kshcCyRj2pe89zKSKxVjrWWKs4balUO/s26MwgqZU2JsmkUhjAAPpr0ACA3vjKydHuAa56B2u7Hz59qDFOkD149x1n9VkW81LevvCH54b5ztiY/+rLr7zxu1+TwdEr99deD0Ln1tMw4ixVhVpuemZGYT5W8JQCgyAMR1whY1IGqRI8E1ks0m2pnqq0k6ogUpgRroBLDQgjDBgTjAEUUgDUJI16Se7sbcWdfoxdzrRUwj7aV1I7165Mnjhx+oLz2+CTyclL3/2D74ApfOFr3w4Hf7778/dmSclIzoXKTy6n2QBrjRQyBPdGQ6RVlCQ8TXScMGk8iwWErsV8Z/58J9KZ0IgbBJgQiok2BghBCCFjMACQlesvrzjY/tWtOM0EoZwCU0Ym2ag+VZ5fLOf9xZXph61s8dibtdpYnApmFe3JmX6372UByfg+wKNOt+hYSgHBNjiesW3H9SyhqEKJlE2ZHiSjrVS2c8Xm639nhEoACAzGhDCGKSVKGQ
	AwBgECxQXNuz7uD1QvQFJEeeOm0iiFBbDu/uEzwW8O+P826hu/d6v0/PTx5Y8/ee/l66/lFqdqb9xQ//pRJ+KBwfmp8U1tmkgnXqaxbPd6/V4fJ1kJ6JQhderZ1OvE/aYSfeKBAYSQQVgbI5Q2UgMgBMgYAxgBAE1U6uQKuS9e7310qzwQ2pDUghR4JU3UZji07BfFamHtIF00O839zx7ceeXaFxGY/J1Hz1sHPEGHDlnTreLkyeNXrpQLDgjtBHF+GI6i4VEYfnpwpAejvNBnUdG2qkBdw4w2Bhv0eXeZzwMfIYQ+7zKgc7VynCux73176ktXV//ix6Onq67RxIhEGTDSHybQH4Xt6LU3317f2pycmGJUVxudOZ+o6Zn764dB0YHx6dCwp88eIYSIxpLLIIziLJbSOAKEW9QlZ7Posijv5awsSw1yDMIAGMAgZBBCGGNjDEJGAdCJnI9thwHLFr3pt9+e3Wl2W41fbj1NlD51sHvmxeP1YfqMya9fvfaf//E/3T/cfPP6K8vv3Wz/3w/SxiBPaDFUeGZ6V2Sd7UOtACmkpeRSaI0wMogZYzNk05KfG5Z8q5a9bBeaA90P0kRixGyuPqddY4wwQgKAFosVQjEANjF1lFIz4/1x50g0kyR+uVi79jtf/vmHL4LKhZ7WreYWMbH5b/8zu3vHGkUZlxjrSOkzy/Px/n5fYxAxNUCNIdhIojEhmDFM3By2sWdJNlajeKmUnqiwQNuRZJ0I398LDVBkABPABgEA7o/CMEhlplzHKlZL1WJVY4LB5Ci6+p2rvRv1uxm8evba/Qe/UaPuDUEXP/kNTdJewqtV/+zlK9yQnfWtdrsVp+koEWEmpQELUwcTqrGMVZpEiUqVU43PflUzLR2pbFqkenncKniZsRNjcaAcocRmGQBQh1kIISmllJLrbG/3oCujE7PHahYo8eDu46fUqawsLzx4+vEZN/eHQcJHyVBjz5DqsYWOwDm/nmP52TF
	vY79x1O4bKcp5b7JWIQoNklRhYhvKjBkfCrf3xJ7+ijVKo+TAsQuO4wKlDsMGpRRjlYm8U+wBp57jWrYlpFRKGa7G56b/4i//x0Hj4OKU9/03Tj3e3BuvFvP1QhJmf2Zcuz/UhGiNWK3a7US8Ovvaq7/zcXenmfWqrmdKpTRLGCO9KELGhJmIOHcZLY9XGo3BBTrUJxuzCtJ8refnuDY6EwRjbaRnA3OxjQ0AUK2U4EIZrYw2gIYyzVQyNV48e9wzRt6729p5sl+2ci8/+Gy80x5hMFIBsZOyf4TIrC4Uld05bChP+kpZNo4RywAERgyTPCJgO1bBmfALzb3B5msXrg0UqxaG5QJgy0UMrIxYjAhHZ4HtJVW3uAaCUkYNGAxGKYkBd/pNC2AizxYq/LPHn9hWfb4eFxob59cakhpXmIaCnGu9u7td9MdajTsvnbxAmY94YEFojOEGEcYQAYSY4VEx79J8QQ+yiPlBFq/aE1Gt7BmTwwo7jh5wjDlxGDWKMGKMAgBsW45t2TazGWHI0hs7G1oJIgavXjmTCKcXwJeuXsv+zwexyhLmxoRix3rEUAv0++3tDweHdzafvlZfxH6RS8cYAkAPW/0Xe612t2sAwNC0nz67t+rmcgEPW82+yEgqdZImo2Gnfbge9p6AaliuGsUj5lAAoJQxKYUCDYAEhkEYFPzCXA0q9eLme0m7K6auTgUf3ynYrCzprhJHBSdYnLX3jvSoNwrMzfbW7Y9aIaCwQMHlOS83XvWTRGDLihCkoyTujpiiBAOSYTKAOAjdXAFjLGTWae0/W3skwa3WJiYnpse9BQCgwyhCCAhBwOgoDErVCd1tLc2ge4+fBKHDjJk/fsrR76BhHBoIy6VoeSlFEmxKHNpN0rGJqbDbV9KwgWj3IlWQhGGlTXuUacvKMxtJhA3oLGZJL+Nht1M/eeZaq90wGDtu7tj8cYUsIU3J8yzKAAQVimdSICmlUQ93Xxw1W8cnxhYW
	wkKhY/C8X+ufq891Wy3P4Nsg26eWolx9dLC9P+wpZBKbNnv9AiGWlipNXEP1gGNKjJIFg0lmLJOWmS2UylMU91qWXw663X4nUAYjkNRxX9zd0oj4lclykTNCAIDatqORMVpJhNY21raP9lS0+bdeWd7ePXr8wlqaXiK//qDX3P20Nr41tZASRtSwhSRCUHVsZkO3F9qkgFKJDC4QprRSmcgTSjHFBjEwjtR5hEm7xxzmunkZhL1Od2F5th+2DQJDqF2ezo8vAcbUpABAkyTjUhjJRzrRQe9CsXj9st0ZbDVeDK8M7b+Nk+7qnaevfvVAC8G5ATTx2mtLRt7+d/+WpKHrWEnRO2gPxqUtMU4UV0bbzMKISCmBIKAUAGyAzvZWrmjZ1SJS/OHde/MzE2OVeqHgX3n5qnLHO/3UIO55GAAoF0pppbTuBoOEGkqsGqPXotlLvUp1pto8ffGdXuPFbz+lsSL5YovoW+++c2q8rmyLaocinCN6VLaToZFcYoM0xpHiHFAOU8aIBpAAgFEmZNLpmFpJsk5hciYeDmsTi/fuf7bX2auWx0rjc47v7j2+BXCRUoK4QQDQaB0Zg7SRhVSxx0NfzHWPrzxfXlj76EObxxqhv1p7fOLiJd8Ujp890z46HG5tGNAIKdtloRCJUjnMMAKsMEK4RbhCAhuMElkkdozAjIb5YZToZiDM5XNntQ2u5VKtGzsbe/tbpXye1SbBvkgJAMVYEzIajTyEj83YQ7/104Xhb37WvLGwEm3shUnAMhUiM1AZz9KjVmtydrpFCAeFMaYWtQBpn0mtBpkCpZAFiGLm2KAhHaY5REEjhJUDhAcxx05hLBcnaa1UKjALE+aVqpHIJienbBAAgEt+frxURBZRBkOuNF2lC2P4fif7JXa2uD7Y3+VxQlO5GwfMyecK+Xq1WB8b6yaBJEhqhRBGGGML56s+rnhW3XeqBavoEERFkFmAkdIIQR4wjlMRxx5zUgG3769qo
	U7MzLS7w04QGcs2zPbLPgDg3qAXh8PV7fXEoPm5xWIt543nRe585djS1vN7+MXDwfZGe9Dc63XSRBwcNOIoAgQjkQqGhdGAkNEaaUW0ylnUw9g1BIdKdsK8op4hNiUSa8VFvVI5ff6sSFOG2YOnG0kii26+6BeJxbjRSZpg1wMAbDMgFjxZvb+/u/X81ntJZysYos7hcNbLjy1MPtp6gkbdqD+oF6vFSs3NeTNT04NePwQtsNZAldYGIaUUaIkkRxrCME0GSQk7HmCiDQWEAQMCGcYXjh2zjQShohiGcXb1pQvH5ueLOafgOkaK2bEiAFDFZTcc2CpayMPSWO3kUn5zbXtwNNjfffTW3/9Hd29+mISBkWRhYf7333xzZqKUBaNOp9/ziqUgwSBSJGxqy0xrYUAZLkUUpXVs5zHJQEstkAFsMGNOOgiS++s05AiACp7G8Vi1xMPk5LFjbrGUQzA3UYOHQA1mz7e3D1qDAtNTp+cZNd2B+NaXvtjvqGrRs4pETXuHR73NezcDHTsMX7n2ansYzc2drnO7K5+vzEwqrtf3okAbkxgeZyCMTy0bUY1U9v/FmMUoaHPc5LOZY7/urk9Yo3H2eu+ou1ir/urxqtHZialp98wUAGAA9XhrPaH+SJPKhB+lfL2de//uemblk0hcml34g7feOHN+5eyZk6eXpoP2YaXsdzdXv3ugb9SXSi75va9d+4f/4I+/89aNotb9ILYFnrYLHsYUAUMYGQAD1CCCSd0tfPrg/hwH0ttctgN7dDjGu0sOdqmZKlvnj88SpAGAPtnYyESKVFTP8Zw16rUOW116FOPr5fqz7b2fP36hP+7zWAkplxdmEUEF1748O/7wg59MaOv7J065NzcOnrW8nKeo48lwxStSLi3QgCkiaATYGMMMgNG1QmlfxxO9Xtn1Ro2+UnDz5z+LgzTP0Hgtl7MhzmIAwI/XVgNBAqNXTh2v5Mwwg3Z3wEfJ7OxyHHPb9SNuEi
	64Ed1RmAjm58rbHz85qdCfzi2fHfH67sj+6EX6s0/hoPvW5Mmq5MwimlCikUXtIYOYIYWUz1impU75ve6WzeHK+OKf/+AHYchVKuJRsLrTfHHY6A77AEAnZ6bBXc6ePj+1UOmPntxfkx3t5yzI5Uu7e3sYEDKmXirisisJnqxPH7Q68aD3rYVllkQJF6GUsRQmiE4j9/Wpkz9tHhGtDSUKACgOmcmQdhS1LDvLMoOwjJJ4d/ir4cfP0qaA23pxWc5N0FKhnQiLMQCgFceSFl24dPwLF4s/efe2P3llmoAbB5ZLw3gYxFE/jkdZNl8udA47KyunB72jb1Qn7c5gmGVcqJTzkVbAzY1TV89fvHR398nBYMgNikD5mhSQHWJuXM/OFaJhKLHhowAIWfjGl7b3nwbx8Nw3f9cCEDJjXAeDEQCQOGjFRzsny8FkRe43i0+fH2jIn5qZkxG/fft+rlDNlSYzxOanZxuj/hfPnLu+erCyvquSmKd6oOORkoMw+VTEb37hm6oXzdq5o2DU0akUMnbJhhgUHHeCelRBnGXDLAGDLMcrvHJ58dtvfXC4tdntCQG+bU/MTPl8sD5cIlMztSAOvvX6ceJEO3tHn7z3JG20XJleu3w1ToPdvQ0j+GS9/vWv3Xjl1Onru935W59ClnZGQ4sxi7FA8N+OBs8QOZqvD20z7fpoGDbikIMwMiNSlRG1DVWZiHiCCHUtG1vW+T/6fXDtrfZRnGSDqN8bdMbLpaS909EXaYBYKafPXl367PH9nd0gzTRRoWPnKWJ/81vfPnNy5Yc//OGt28/nHHhjoz03AD4cZdgUixULcJylFnZ7AOlYuXjj5R/9x//033cPr1VnRjKyLUtkkRYyFIJDUsv5DsWI0ZFUr/2977Gx+iCJDnu9IAgRNYVqaTjomFEEOaA2QV//8qLD0t2do62dWChIs2R8cqbgl0DJ4/NLb//dtzvd7kub2xceHQUqjJDqRmHQjQuOqyn
	ZiaKpyoRz4wuXzr70/MTyi8bR+72NEqPVTGL4a1NvIQRK5Cw3MDBz+RI6tpAAhJIzy65WEGOEYEhF5iv6+VE0F05P+f7Ui61Od4iV1hb1p6amM5USQFoh368t5IvjP/m1ylIuJAhFCGXMotQyjGCbbzX39p88Pvyv/8V2XZT3yED2sHYskteYCcIwBg0DwTVzZLkQ1XyTSuvzgUCpEglFVGMMmNSrzpEAim310sWX7j5ZI9Zc5/ARF6w651dqVSllKIWJhxF3is9XaaPNNOQsBkAdLRLCNMbNLBYGIbcgbdJu7iEpjO+aOE45fxIPl73SuFeORBpgaSwmPUp8ZutU89S1LRwazKgyFkLYY7bHnIXp4sNtoCtLtYnx8n/40Y+2d5U21PfL/+YH/5JqY7v5Ti950DksKlV4+CQnpaY441xzJUBigjMpM6N247ANOGKUKAnaOPliRILBsJ8geDDq1ZhjuzatFsMoKlBdMUbE8aDfY5S5tnvp8pWUZzzL0iR2bdbpHALA/wMUjQteOh3xIgAAAABJRU5ErkJggg==
X-Mailer: Evolution 3.2.2 (3.2.2-1.fc16) 
Mime-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Jan Beulich <JBeulich@suse.com>, "Lv, Hui" <hui.lv@intel.com>
Subject: Re: [Xen-devel] [PATCH] xen/sched_credit: Use delay to control
 scheduling frequency
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3414353275376268182=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--===============3414353275376268182==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-kWN+hrKMXvO7JFXpsTxo"


--=-kWN+hrKMXvO7JFXpsTxo
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, 2011-12-20 at 10:26 +0000, George Dunlap wrote:=20
> > I think that too, but maybe you can print some kind of warning when it
> > happens?
>=20
> I guess the consensus is that we should put in some effort to make the
> interface more polished.
>=20
Exactly! :-)

> How about this:
>=20
> First, add a ratelimit_us element to csched_priv, just like the current
> tslice_ms element.
>=20
> When the scheduler comes up (in csched_init), it checks to see if
> MICROSECS(sched_ratelimit_us) > MILLISECS(sched_credit_tslice_ms); if
> so, it prints a warning, and sets prv->ratelimit_us to
> 1000*prv->tslice_ms.
>=20
For what it counts, I'm more than fine with just printing some
"WARNING: rate-limit > time slice is nonsense", as well as doing as you
suggest... Or even with doing both! :-P=20

> In the future, when we implement the domctls to change a scheduler's
> ratelimit_us, and tslice_ms, we disallow changes which would violate the
> "ratelimit < tslice" rule (returning -EINVAL or something like that).
>
That makes a lot of sense.

Regards,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-------------------------------------------------------------------
Dario Faggioli, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
PhD Candidate, ReTiS Lab, Scuola Superiore Sant'Anna, Pisa (Italy)



--=-kWN+hrKMXvO7JFXpsTxo
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEABECAAYFAk7waKwACgkQk4XaBE3IOsRgbwCfb1trPxijD1sN4lo+FV6N1V5m
utoAn2sFfriavHtAbPkBUWC6y/ZqA3ir
=i2AM
-----END PGP SIGNATURE-----

--=-kWN+hrKMXvO7JFXpsTxo--



--===============3414353275376268182==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============3414353275376268182==--



From xen-devel-bounces@lists.xensource.com Tue Dec 20 10:57:41 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 Dec 2011 10:57:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RcxNW-0002QJ-Od; Tue, 20 Dec 2011 10:57:02 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <250716708@qq.com>) id 1RcxNV-0002QD-Hz
	for xen-devel@lists.xensource.com; Tue, 20 Dec 2011 10:57:01 +0000
X-Env-Sender: 250716708@qq.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1324378578!47441372!1
X-Originating-IP: [64.71.138.43]
X-SpamReason: No, hits=2.1 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA2NC43MS4xMzguNDMgPT4gMjgxOTQx\n,sa_preprocessor: 
	QmFkIElQOiA2NC43MS4xMzguNDMgPT4gMjgxOTQx\n,FROM_ALL_NUMS,
	FROM_STARTS_WITH_NUMS,HTML_30_40,HTML_MESSAGE,MIME_BASE64_TEXT,
	MIME_BOUND_NEXTPART,received_headers: No Received headers
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17321 invoked from network); 20 Dec 2011 10:56:18 -0000
Received: from smtpbg52.qq.com (HELO smtpbg52.qq.com) (64.71.138.43)
	by server-5.tower-27.messagelabs.com with SMTP;
	20 Dec 2011 10:56:18 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qq.com; s=s0907;
	t=1324378619; bh=2sb46eVbfIGjMe42sBAxoX3ba2g3bW/lJTlQR/w7Pv8=;
	h=X-QQ-SSF:X-HAS-ATTACH:X-QQ-BUSINESS-ORIGIN:X-Originating-IP:
	X-QQ-STYLE:X-QQ-mid:From:To:Subject:Mime-Version:Content-Type:
	Content-Transfer-Encoding:Date:X-Priority:Message-ID:X-QQ-MIME:
	X-Mailer:X-QQ-Mailer;
	b=OuWkMo40DtZh4RjjQIRv6ccxjOgt3MG3usoYgkqpMCr84jjL6KEU5/busfpb342s9
	o1yiddj9/ABvHPsyGP61MauHuGSwmPNzdrVC6FIJvBeDhf7GYbW39fBy3ZlG83j
X-QQ-SSF: 00000000000000F0000000000000000
X-HAS-ATTACH: no
X-QQ-BUSINESS-ORIGIN: 2
X-Originating-IP: 118.192.67.234
X-QQ-STYLE: 
X-QQ-mid: webmail193t1324378617t4653747
From: "=?gbk?B?oei9S+y2YXdhcmU=?=" <250716708@qq.com>
To: "=?gbk?B?eGVuLWRldmVs?=" <xen-devel@lists.xensource.com>
Mime-Version: 1.0
Date: Tue, 20 Dec 2011 18:56:57 +0800
X-Priority: 3
Message-ID: <tencent_7B46D64D47BC6E2555A88243@qq.com>
X-QQ-MIME: TCMime 1.0 by Tencent
X-Mailer: QQMail 2.x
X-QQ-Mailer: QQMail 2.x
Subject: [Xen-devel] Do vm snapshot feature exist in qemu-dm as in VMware?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3317310970893472112=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a multi-part message in MIME format.

--===============3317310970893472112==
Content-Type: multipart/alternative;
	boundary="----=_NextPart_4EF069F9_DCF36588_1E8EACB1"
Content-Transfer-Encoding: 8Bit

This is a multi-part message in MIME format.

------=_NextPart_4EF069F9_DCF36588_1E8EACB1
Content-Type: text/plain;
	charset="gbk"
Content-Transfer-Encoding: base64

SGksDQogICAgIGhvdyB0byBzYXZlIHRoZSBjdXJyZW50IHN0YXRlIG9mIHRoZSBydW5uaW5n
IHZtIGFzIGEgZmlsZSBhbmQgcmVzdG9yZSB0aGUgbGFzdCBydW5uaW5nIHN0YXRlIGxhdGVy
IGJ5IHVzaW5nIHRoZSBmaWxlIGFzIGEgYXJnIG9mIHFlbXUgY21kIGxpbmU/DQogIA0KIGJy
dWNl

------=_NextPart_4EF069F9_DCF36588_1E8EACB1
Content-Type: text/html;
	charset="gbk"
Content-Transfer-Encoding: base64

PERJVj4NCjxESVY+SGksPC9ESVY+DQo8RElWPiZuYnNwOyZuYnNwOyZuYnNwOyBob3cgdG8g
c2F2ZSB0aGUgY3VycmVudCBzdGF0ZSBvZiB0aGUgcnVubmluZyB2bSBhcyBhIGZpbGUgYW5k
IHJlc3RvcmUgdGhlIGxhc3QgcnVubmluZyBzdGF0ZSBsYXRlciBieSB1c2luZyB0aGUgZmls
ZSBhcyBhIGFyZyBvZiBxZW11IGNtZCBsaW5lPzwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4N
CjxESVY+YnJ1Y2U8L0RJVj48L0RJVj4=

------=_NextPart_4EF069F9_DCF36588_1E8EACB1--



--===============3317310970893472112==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============3317310970893472112==--



From xen-devel-bounces@lists.xensource.com Tue Dec 20 10:57:41 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 Dec 2011 10:57:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RcxNW-0002QJ-Od; Tue, 20 Dec 2011 10:57:02 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <250716708@qq.com>) id 1RcxNV-0002QD-Hz
	for xen-devel@lists.xensource.com; Tue, 20 Dec 2011 10:57:01 +0000
X-Env-Sender: 250716708@qq.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1324378578!47441372!1
X-Originating-IP: [64.71.138.43]
X-SpamReason: No, hits=2.1 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA2NC43MS4xMzguNDMgPT4gMjgxOTQx\n,sa_preprocessor: 
	QmFkIElQOiA2NC43MS4xMzguNDMgPT4gMjgxOTQx\n,FROM_ALL_NUMS,
	FROM_STARTS_WITH_NUMS,HTML_30_40,HTML_MESSAGE,MIME_BASE64_TEXT,
	MIME_BOUND_NEXTPART,received_headers: No Received headers
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17321 invoked from network); 20 Dec 2011 10:56:18 -0000
Received: from smtpbg52.qq.com (HELO smtpbg52.qq.com) (64.71.138.43)
	by server-5.tower-27.messagelabs.com with SMTP;
	20 Dec 2011 10:56:18 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qq.com; s=s0907;
	t=1324378619; bh=2sb46eVbfIGjMe42sBAxoX3ba2g3bW/lJTlQR/w7Pv8=;
	h=X-QQ-SSF:X-HAS-ATTACH:X-QQ-BUSINESS-ORIGIN:X-Originating-IP:
	X-QQ-STYLE:X-QQ-mid:From:To:Subject:Mime-Version:Content-Type:
	Content-Transfer-Encoding:Date:X-Priority:Message-ID:X-QQ-MIME:
	X-Mailer:X-QQ-Mailer;
	b=OuWkMo40DtZh4RjjQIRv6ccxjOgt3MG3usoYgkqpMCr84jjL6KEU5/busfpb342s9
	o1yiddj9/ABvHPsyGP61MauHuGSwmPNzdrVC6FIJvBeDhf7GYbW39fBy3ZlG83j
X-QQ-SSF: 00000000000000F0000000000000000
X-HAS-ATTACH: no
X-QQ-BUSINESS-ORIGIN: 2
X-Originating-IP: 118.192.67.234
X-QQ-STYLE: 
X-QQ-mid: webmail193t1324378617t4653747
From: "=?gbk?B?oei9S+y2YXdhcmU=?=" <250716708@qq.com>
To: "=?gbk?B?eGVuLWRldmVs?=" <xen-devel@lists.xensource.com>
Mime-Version: 1.0
Date: Tue, 20 Dec 2011 18:56:57 +0800
X-Priority: 3
Message-ID: <tencent_7B46D64D47BC6E2555A88243@qq.com>
X-QQ-MIME: TCMime 1.0 by Tencent
X-Mailer: QQMail 2.x
X-QQ-Mailer: QQMail 2.x
Subject: [Xen-devel] Do vm snapshot feature exist in qemu-dm as in VMware?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3317310970893472112=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a multi-part message in MIME format.

--===============3317310970893472112==
Content-Type: multipart/alternative;
	boundary="----=_NextPart_4EF069F9_DCF36588_1E8EACB1"
Content-Transfer-Encoding: 8Bit

This is a multi-part message in MIME format.

------=_NextPart_4EF069F9_DCF36588_1E8EACB1
Content-Type: text/plain;
	charset="gbk"
Content-Transfer-Encoding: base64

SGksDQogICAgIGhvdyB0byBzYXZlIHRoZSBjdXJyZW50IHN0YXRlIG9mIHRoZSBydW5uaW5n
IHZtIGFzIGEgZmlsZSBhbmQgcmVzdG9yZSB0aGUgbGFzdCBydW5uaW5nIHN0YXRlIGxhdGVy
IGJ5IHVzaW5nIHRoZSBmaWxlIGFzIGEgYXJnIG9mIHFlbXUgY21kIGxpbmU/DQogIA0KIGJy
dWNl

------=_NextPart_4EF069F9_DCF36588_1E8EACB1
Content-Type: text/html;
	charset="gbk"
Content-Transfer-Encoding: base64

PERJVj4NCjxESVY+SGksPC9ESVY+DQo8RElWPiZuYnNwOyZuYnNwOyZuYnNwOyBob3cgdG8g
c2F2ZSB0aGUgY3VycmVudCBzdGF0ZSBvZiB0aGUgcnVubmluZyB2bSBhcyBhIGZpbGUgYW5k
IHJlc3RvcmUgdGhlIGxhc3QgcnVubmluZyBzdGF0ZSBsYXRlciBieSB1c2luZyB0aGUgZmls
ZSBhcyBhIGFyZyBvZiBxZW11IGNtZCBsaW5lPzwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4N
CjxESVY+YnJ1Y2U8L0RJVj48L0RJVj4=

------=_NextPart_4EF069F9_DCF36588_1E8EACB1--



--===============3317310970893472112==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============3317310970893472112==--



From xen-devel-bounces@lists.xensource.com Tue Dec 20 11:11:07 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 Dec 2011 11:11:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rcxae-0002wV-13; Tue, 20 Dec 2011 11:10:36 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rcxab-0002wG-VY
	for xen-devel@lists.xensource.com; Tue, 20 Dec 2011 11:10:34 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1324379427!8647337!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzQwMQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8361 invoked from network); 20 Dec 2011 11:10:27 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Dec 2011 11:10:27 -0000
X-IronPort-AV: E=Sophos;i="4.71,381,1320624000"; 
   d="scan'208";a="9575542"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Dec 2011 11:10:26 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 20 Dec 2011 11:10:26 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: =?UTF-8?Q?=C2=A4=3FK=E6=96=BCaware?= <250716708@qq.com>
Date: Tue, 20 Dec 2011 11:10:25 +0000
In-Reply-To: <tencent_7B46D64D47BC6E2555A88243@qq.com>
References: <tencent_7B46D64D47BC6E2555A88243@qq.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1324379426.23729.37.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Do vm snapshot feature exist in qemu-dm as in
 VMware?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gVHVlLCAyMDExLTEyLTIwIGF0IDEwOjU2ICswMDAwLCDCpD9L5pa8YXdhcmUgd3JvdGU6Cj4g
SGksCj4gICAgIGhvdyB0byBzYXZlIHRoZSBjdXJyZW50IHN0YXRlIG9mIHRoZSBydW5uaW5nIHZt
IGFzIGEgZmlsZSBhbmQKPiByZXN0b3JlIHRoZSBsYXN0IHJ1bm5pbmcgc3RhdGUgbGF0ZXIgYnkg
dXNpbmcgdGhlIGZpbGUgYXMgYSBhcmcgb2YKPiBxZW11IGNtZCBsaW5lPwoKVW5kZXIgWGVuIHRo
aXMgaXMgYSBmZWF0dXJlIG9mIHRoZSBYZW4gdG9vbHN0YWNrIG5vdCBvZiBRZW11ICh3aGljaCBp
cwpqdXN0IGEgY29tcG9uZW50IG9mIGEgWGVuIHN5c3RlbSkuIEl0IGhhcyBiZWVuIHN1cHBvcnRl
ZCBmb3IgbWFueSB5ZWFycy4KCklhbi4KCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMu
eGVuc291cmNlLmNvbQpodHRwOi8vbGlzdHMueGVuc291cmNlLmNvbS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Tue Dec 20 11:11:07 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 Dec 2011 11:11:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rcxae-0002wV-13; Tue, 20 Dec 2011 11:10:36 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rcxab-0002wG-VY
	for xen-devel@lists.xensource.com; Tue, 20 Dec 2011 11:10:34 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1324379427!8647337!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzQwMQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8361 invoked from network); 20 Dec 2011 11:10:27 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Dec 2011 11:10:27 -0000
X-IronPort-AV: E=Sophos;i="4.71,381,1320624000"; 
   d="scan'208";a="9575542"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Dec 2011 11:10:26 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 20 Dec 2011 11:10:26 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: =?UTF-8?Q?=C2=A4=3FK=E6=96=BCaware?= <250716708@qq.com>
Date: Tue, 20 Dec 2011 11:10:25 +0000
In-Reply-To: <tencent_7B46D64D47BC6E2555A88243@qq.com>
References: <tencent_7B46D64D47BC6E2555A88243@qq.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1324379426.23729.37.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Do vm snapshot feature exist in qemu-dm as in
 VMware?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gVHVlLCAyMDExLTEyLTIwIGF0IDEwOjU2ICswMDAwLCDCpD9L5pa8YXdhcmUgd3JvdGU6Cj4g
SGksCj4gICAgIGhvdyB0byBzYXZlIHRoZSBjdXJyZW50IHN0YXRlIG9mIHRoZSBydW5uaW5nIHZt
IGFzIGEgZmlsZSBhbmQKPiByZXN0b3JlIHRoZSBsYXN0IHJ1bm5pbmcgc3RhdGUgbGF0ZXIgYnkg
dXNpbmcgdGhlIGZpbGUgYXMgYSBhcmcgb2YKPiBxZW11IGNtZCBsaW5lPwoKVW5kZXIgWGVuIHRo
aXMgaXMgYSBmZWF0dXJlIG9mIHRoZSBYZW4gdG9vbHN0YWNrIG5vdCBvZiBRZW11ICh3aGljaCBp
cwpqdXN0IGEgY29tcG9uZW50IG9mIGEgWGVuIHN5c3RlbSkuIEl0IGhhcyBiZWVuIHN1cHBvcnRl
ZCBmb3IgbWFueSB5ZWFycy4KCklhbi4KCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMu
eGVuc291cmNlLmNvbQpodHRwOi8vbGlzdHMueGVuc291cmNlLmNvbS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Tue Dec 20 11:58:55 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 Dec 2011 11:58:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RcyKs-0003Kg-DS; Tue, 20 Dec 2011 11:58:22 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <hramrach@gmail.com>) id 1RcyKq-0003Kb-0P
	for xen-devel@lists.xensource.com; Tue, 20 Dec 2011 11:58:20 +0000
X-Env-Sender: hramrach@gmail.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1324382291!6264541!1
X-Originating-IP: [209.85.160.43]
X-SpamReason: No, hits=1.7 required=7.0 tests=INFO_TLD,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8546 invoked from network); 20 Dec 2011 11:58:13 -0000
Received: from mail-pw0-f43.google.com (HELO mail-pw0-f43.google.com)
	(209.85.160.43)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Dec 2011 11:58:13 -0000
Received: by pbbb11 with SMTP id b11so22067988pbb.30
	for <xen-devel@lists.xensource.com>;
	Tue, 20 Dec 2011 03:58:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:from:date
	:x-google-sender-auth:message-id:subject:to:cc:content-type;
	bh=E///L11Hkg47STUv15sqHgWm8KHFD5Ok2WFeyrPX4ZE=;
	b=bJmPK1bFDOHSvpHPXLdBnZSdTPmzI+QYrj3pRLjs9gZzesX30m6CYneOgyyCMNDnFP
	q0SOkyVDcCsvB5IpWBU8B/vP2tYl+UNv3AHM978kwEw3bt+yoFlyGtpthuYGSJ7H2s1q
	wX+j3mjeclYOxYnBOZEOZn3tbgngyebWT8Uo8=
Received: by 10.68.212.200 with SMTP id nm8mr3242768pbc.28.1324382290791; Tue,
	20 Dec 2011 03:58:10 -0800 (PST)
MIME-Version: 1.0
Received: by 10.143.60.18 with HTTP; Tue, 20 Dec 2011 03:57:48 -0800 (PST)
In-Reply-To: <1324374914.23729.22.camel@zakaz.uk.xensource.com>
References: <CAOMqctShNFqe47w1orEPMCqvDORy5yxh=Gy33e02fyQYrz4nkw@mail.gmail.com>
	<20111219142943.GD27772@andromeda.dapyr.net>
	<CAOMqctSW87AmM8UTC34_ZwDhipnZUMmxyxiBix+EMAmi7hn1hg@mail.gmail.com>
	<20111219194324.GA29852@andromeda.dapyr.net>
	<1324373842.23729.16.camel@zakaz.uk.xensource.com>
	<CAEBdQ92Oy6=EYYFG_KNMP6raq7S1e_195hFth1etMgpQWdGtsg@mail.gmail.com>
	<1324374914.23729.22.camel@zakaz.uk.xensource.com>
From: Michal Suchanek <hramrach@centrum.cz>
Date: Tue, 20 Dec 2011 12:57:48 +0100
X-Google-Sender-Auth: OlKpK8sX2j8JeKoAlhOJw7dlq_4
Message-ID: <CAOMqctTOC_te2QRqFUC45+cq1qCBcQyMdvQcu4Brpw-kAiYnBg@mail.gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jean Guyader <jean.guyader@gmail.com>
Subject: Re: [Xen-devel] UDP checksums broken in Dom0 -> DomU vif transfer
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 20 December 2011 10:55, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Tue, 2011-12-20 at 09:43 +0000, Jean Guyader wrote:
>> On 20 December 2011 10:37, Ian Campbell <Ian.Campbell@citrix.com> wrote:
>> > The issue is that dom0 does checksum offload which means the checksum is
>> > not valid on the domU end, although we know the packet is intact because
>> > it never hit the wire.
>> >
>> > The network stack deals with this because skb->ip_summed is set
>> > appropriately but when e.g. raw sockets are used it can ends up exposing
>> > getting exposed to userspace.
>> >
>> > We don't want to do the checksum by default since there are performance
>> > gains from avoiding it in the general case. Note that "tx off" turns of
>> > TCP and UDP checksum offload.
>> >
>> > It's not clear where the bug is here, it could be a bug in dhclinet for
>> > dropping the packet or perhaps this is something that raw socket driver
>> > should be correcting (based on ip_summed) as the packet passes through
>> > to userspace?
>> >
>> > I'm not sure but this might impact native hardware too -- depends on the
>> > H/W's handling of the checksum field on RX, you'd hope they mostly just
>> > leave it alone, but I'm not sure how e.g. LRO/GRO effects things?
>> >
>>
>> I've seen this issue in the past. I belive the bug is in dhclient.
>> dhclient checks the checksum on the packets and drop them if it's wrong.
>
> Indeed, googling around a bit shows that this dhclient bug affects more
> than just Xen, e.g. virtio and even some native hardware appear to be
> effected.
>
> http://marc.info/?l=kvm&m=121882968407525&w=2
> https://qa.mandriva.com/show_bug.cgi?id=63320
> https://bugs.mageia.org/show_bug.cgi?id=1243
> http://pkgs.fedoraproject.org/gitweb/?p=dhcp.git;a=blob_plain;f=dhcp-4.2.2-xen-checksum.patch;hb=HEAD
>
> The OP didn't say what distro or version of dhclient he was using but I
> think the right place to report this would be to the distro since it
> appears to be using an out of date dhclient. In the meantime disabling
> offload seems like a reasonable local workaround but it is not a fix we
> should apply by default.

Thanks for the links

I am running Ubuntu in the DomU.

Michal

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 20 11:58:55 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 Dec 2011 11:58:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RcyKs-0003Kg-DS; Tue, 20 Dec 2011 11:58:22 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <hramrach@gmail.com>) id 1RcyKq-0003Kb-0P
	for xen-devel@lists.xensource.com; Tue, 20 Dec 2011 11:58:20 +0000
X-Env-Sender: hramrach@gmail.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1324382291!6264541!1
X-Originating-IP: [209.85.160.43]
X-SpamReason: No, hits=1.7 required=7.0 tests=INFO_TLD,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8546 invoked from network); 20 Dec 2011 11:58:13 -0000
Received: from mail-pw0-f43.google.com (HELO mail-pw0-f43.google.com)
	(209.85.160.43)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Dec 2011 11:58:13 -0000
Received: by pbbb11 with SMTP id b11so22067988pbb.30
	for <xen-devel@lists.xensource.com>;
	Tue, 20 Dec 2011 03:58:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:from:date
	:x-google-sender-auth:message-id:subject:to:cc:content-type;
	bh=E///L11Hkg47STUv15sqHgWm8KHFD5Ok2WFeyrPX4ZE=;
	b=bJmPK1bFDOHSvpHPXLdBnZSdTPmzI+QYrj3pRLjs9gZzesX30m6CYneOgyyCMNDnFP
	q0SOkyVDcCsvB5IpWBU8B/vP2tYl+UNv3AHM978kwEw3bt+yoFlyGtpthuYGSJ7H2s1q
	wX+j3mjeclYOxYnBOZEOZn3tbgngyebWT8Uo8=
Received: by 10.68.212.200 with SMTP id nm8mr3242768pbc.28.1324382290791; Tue,
	20 Dec 2011 03:58:10 -0800 (PST)
MIME-Version: 1.0
Received: by 10.143.60.18 with HTTP; Tue, 20 Dec 2011 03:57:48 -0800 (PST)
In-Reply-To: <1324374914.23729.22.camel@zakaz.uk.xensource.com>
References: <CAOMqctShNFqe47w1orEPMCqvDORy5yxh=Gy33e02fyQYrz4nkw@mail.gmail.com>
	<20111219142943.GD27772@andromeda.dapyr.net>
	<CAOMqctSW87AmM8UTC34_ZwDhipnZUMmxyxiBix+EMAmi7hn1hg@mail.gmail.com>
	<20111219194324.GA29852@andromeda.dapyr.net>
	<1324373842.23729.16.camel@zakaz.uk.xensource.com>
	<CAEBdQ92Oy6=EYYFG_KNMP6raq7S1e_195hFth1etMgpQWdGtsg@mail.gmail.com>
	<1324374914.23729.22.camel@zakaz.uk.xensource.com>
From: Michal Suchanek <hramrach@centrum.cz>
Date: Tue, 20 Dec 2011 12:57:48 +0100
X-Google-Sender-Auth: OlKpK8sX2j8JeKoAlhOJw7dlq_4
Message-ID: <CAOMqctTOC_te2QRqFUC45+cq1qCBcQyMdvQcu4Brpw-kAiYnBg@mail.gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jean Guyader <jean.guyader@gmail.com>
Subject: Re: [Xen-devel] UDP checksums broken in Dom0 -> DomU vif transfer
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 20 December 2011 10:55, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Tue, 2011-12-20 at 09:43 +0000, Jean Guyader wrote:
>> On 20 December 2011 10:37, Ian Campbell <Ian.Campbell@citrix.com> wrote:
>> > The issue is that dom0 does checksum offload which means the checksum is
>> > not valid on the domU end, although we know the packet is intact because
>> > it never hit the wire.
>> >
>> > The network stack deals with this because skb->ip_summed is set
>> > appropriately but when e.g. raw sockets are used it can ends up exposing
>> > getting exposed to userspace.
>> >
>> > We don't want to do the checksum by default since there are performance
>> > gains from avoiding it in the general case. Note that "tx off" turns of
>> > TCP and UDP checksum offload.
>> >
>> > It's not clear where the bug is here, it could be a bug in dhclinet for
>> > dropping the packet or perhaps this is something that raw socket driver
>> > should be correcting (based on ip_summed) as the packet passes through
>> > to userspace?
>> >
>> > I'm not sure but this might impact native hardware too -- depends on the
>> > H/W's handling of the checksum field on RX, you'd hope they mostly just
>> > leave it alone, but I'm not sure how e.g. LRO/GRO effects things?
>> >
>>
>> I've seen this issue in the past. I belive the bug is in dhclient.
>> dhclient checks the checksum on the packets and drop them if it's wrong.
>
> Indeed, googling around a bit shows that this dhclient bug affects more
> than just Xen, e.g. virtio and even some native hardware appear to be
> effected.
>
> http://marc.info/?l=kvm&m=121882968407525&w=2
> https://qa.mandriva.com/show_bug.cgi?id=63320
> https://bugs.mageia.org/show_bug.cgi?id=1243
> http://pkgs.fedoraproject.org/gitweb/?p=dhcp.git;a=blob_plain;f=dhcp-4.2.2-xen-checksum.patch;hb=HEAD
>
> The OP didn't say what distro or version of dhclient he was using but I
> think the right place to report this would be to the distro since it
> appears to be using an out of date dhclient. In the meantime disabling
> offload seems like a reasonable local workaround but it is not a fix we
> should apply by default.

Thanks for the links

I am running Ubuntu in the DomU.

Michal

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 20 12:10:26 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 Dec 2011 12:10:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RcyW6-0003yg-JK; Tue, 20 Dec 2011 12:09:58 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Wang2@amd.com>) id 1RcyW4-0003yW-Q6
	for xen-devel@lists.xensource.com; Tue, 20 Dec 2011 12:09:57 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1324382990!8815162!1
X-Originating-IP: [213.199.154.139]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10802 invoked from network); 20 Dec 2011 12:09:50 -0000
Received: from db3ehsobe001.messaging.microsoft.com (HELO
	DB3EHSOBE001.bigfish.com) (213.199.154.139)
	by server-12.tower-21.messagelabs.com with AES128-SHA encrypted SMTP;
	20 Dec 2011 12:09:50 -0000
Received: from mail56-db3-R.bigfish.com (10.3.81.247) by
	DB3EHSOBE001.bigfish.com (10.3.84.21) with Microsoft SMTP Server id
	14.1.225.23; Tue, 20 Dec 2011 12:09:42 +0000
Received: from mail56-db3 (localhost [127.0.0.1])	by mail56-db3-R.bigfish.com
	(Postfix) with ESMTP id 8AF35540337;
	Tue, 20 Dec 2011 12:10:10 +0000 (UTC)
X-SpamScore: -13
X-BigFish: VPS-13(zz1432N98dK4015Lzz1202hzz8275bhz2dh668h839h93fh)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
X-FB-SS: 0,13,
Received: from mail56-db3 (localhost.localdomain [127.0.0.1]) by mail56-db3
	(MessageSwitch) id 1324382964647200_9160;
	Tue, 20 Dec 2011 12:09:24 +0000 (UTC)
Received: from DB3EHSMHS019.bigfish.com (unknown [10.3.81.251])	by
	mail56-db3.bigfish.com (Postfix) with ESMTP id 977D93A0042;
	Tue, 20 Dec 2011 12:09:24 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	DB3EHSMHS019.bigfish.com (10.3.87.119) with Microsoft SMTP Server id
	14.1.225.23; Tue, 20 Dec 2011 12:08:55 +0000
X-WSS-ID: 0LWI4EW-01-47C-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 239AD1028083;	Tue, 20 Dec 2011 06:08:56 -0600 (CST)
Received: from SAUSEXDAG03.amd.com (163.181.55.3) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Tue, 20 Dec 2011 06:09:05 -0600
Received: from storexhtp01.amd.com (172.24.4.3) by sausexdag03.amd.com
	(163.181.55.3) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Tue, 20 Dec 2011 06:08:57 -0600
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp01.amd.com
	(172.24.4.3) with Microsoft SMTP Server id 8.3.213.0; Tue, 20 Dec 2011
	07:08:51 -0500
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 32D4049C58B; Tue, 20 Dec 2011
	12:08:50 +0000 (GMT)
Received: from gran.osrc.amd.com (gran.osrc.amd.com [165.204.15.57])	by
	mail.osrc.amd.com (Postfix) with ESMTP id 14EB25940FF; Tue, 20 Dec 2011
	13:08:50 +0100 (CET)
From: Wei Wang2 <wei.wang2@amd.com>
To: <xen-devel@lists.xensource.com>
Date: Tue, 20 Dec 2011 13:11:30 +0100
User-Agent: KMail/1.9.6 (enterprise 20070904.708012)
References: <1324319661.2599.28.camel@Solace> <1324320812.2599.34.camel@Solace>
In-Reply-To: <1324320812.2599.34.camel@Solace>
MIME-Version: 1.0
Content-Disposition: inline
Message-ID: <201112201311.31291.wei.wang2@amd.com>
X-OriginatorOrg: amd.com
Cc: Tim Deegan <tim@xen.org>, "allen.m.kay@intel.com" <allen.m.kay@intel.com>,
	Dario Faggioli <raistlin@linux.it>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 2 of 2] Move IOMMU faults handling into
	softirq for AMD-Vi.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Monday 19 December 2011 19:53:32 Dario Faggioli wrote:
> Dealing with interrupts from AMD-Vi IOMMU is deferred to a softirq-tasklet,
> raised by the actual IRQ handler. To avoid more interrupts being generated
> (because of further faults), they must be masked in the IOMMU within the
> low level IRQ handler and enabled back in the tasklet body. Notice that
> this may cause the log to overflow, but none of the existing entry will
> be overwritten.
>
> Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
>
> diff -r 12cc8fc9a908 xen/drivers/passthrough/amd/iommu_init.c
> --- a/xen/drivers/passthrough/amd/iommu_init.c	Mon Dec 19 16:46:14 2011
> +0000 +++ b/xen/drivers/passthrough/amd/iommu_init.c	Mon Dec 19 16:46:39
> 2011 +0000 @@ -32,6 +32,8 @@
>
>  static int __initdata nr_amd_iommus;
>
> +static struct tasklet amd_iommu_fault_tasklet;
> +
>  unsigned short ivrs_bdf_entries;
>  static struct radix_tree_root ivrs_maps;
>  struct list_head amd_iommu_head;
> @@ -522,12 +524,10 @@ static void parse_event_log_entry(struct
>      }
>  }
>
> -static void amd_iommu_page_fault(int irq, void *dev_id,
> -                             struct cpu_user_regs *regs)
> +static void __do_amd_iommu_page_fault(struct amd_iommu *iommu)
>  {
>      u32 entry;
>      unsigned long flags;
> -    struct amd_iommu *iommu = dev_id;
>
>      spin_lock_irqsave(&iommu->lock, flags);
>      amd_iommu_read_event_log(iommu);
> @@ -546,6 +546,43 @@ static void amd_iommu_page_fault(int irq
>      spin_unlock_irqrestore(&iommu->lock, flags);
>  }
>
> +static void do_amd_iommu_page_fault(unsigned long data)
> +{
> +    struct amd_iommu *iommu;
> +
> +    if ( list_empty(&amd_iommu_head) )

Here you could use iommu_found(). Rest part of this patch looks good to me.
Thanks,
Wei

> +    {
> +       AMD_IOMMU_DEBUG("no device found, something must be very
> wrong!\n"); +       return;
> +    }
> +
> +    /* No matter from whom the interrupt came from, check all the
> +     * IOMMUs present in the system. This allows for having just one
> +     * tasklet (instead of one per each IOMMU) and should be more than
> +     * fine, considering how rare the event of a fault should be. */
> +for_each_amd_iommu ( iommu )
> +        __do_amd_iommu_page_fault(iommu);
> +}
> +
> +static void amd_iommu_page_fault(int irq, void *dev_id,
> +                             struct cpu_user_regs *regs)
> +{
> +    u32 entry;
> +    unsigned long flags;
> +    struct amd_iommu *iommu = dev_id;
> +
> +    /* silence interrupts. The tasklet will enable them back */
> +    spin_lock_irqsave(&iommu->lock, flags);
> +    entry = readl(iommu->mmio_base + IOMMU_STATUS_MMIO_OFFSET);
> +    iommu_clear_bit(&entry, IOMMU_STATUS_EVENT_LOG_INT_SHIFT);
> +    writel(entry, iommu->mmio_base+IOMMU_STATUS_MMIO_OFFSET);
> +    spin_unlock_irqrestore(&iommu->lock, flags);
> +
> +    /* Flag the tasklet as runnable so that it can execute, clear
> +     * the log and re-enable interrupts. */
> +    tasklet_schedule(&amd_iommu_fault_tasklet);
> +}
> +
>  static int __init set_iommu_interrupt_handler(struct amd_iommu *iommu)
>  {
>      int irq, ret;
> @@ -884,6 +921,8 @@ int __init amd_iommu_init(void)
>          if ( amd_iommu_init_one(iommu) != 0 )
>              goto error_out;
>
> +    softirq_tasklet_init(&amd_iommu_fault_tasklet,
> do_amd_iommu_page_fault, 0); +
>      return 0;
>
>  error_out:




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 20 12:10:26 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 Dec 2011 12:10:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RcyW6-0003yg-JK; Tue, 20 Dec 2011 12:09:58 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Wang2@amd.com>) id 1RcyW4-0003yW-Q6
	for xen-devel@lists.xensource.com; Tue, 20 Dec 2011 12:09:57 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1324382990!8815162!1
X-Originating-IP: [213.199.154.139]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10802 invoked from network); 20 Dec 2011 12:09:50 -0000
Received: from db3ehsobe001.messaging.microsoft.com (HELO
	DB3EHSOBE001.bigfish.com) (213.199.154.139)
	by server-12.tower-21.messagelabs.com with AES128-SHA encrypted SMTP;
	20 Dec 2011 12:09:50 -0000
Received: from mail56-db3-R.bigfish.com (10.3.81.247) by
	DB3EHSOBE001.bigfish.com (10.3.84.21) with Microsoft SMTP Server id
	14.1.225.23; Tue, 20 Dec 2011 12:09:42 +0000
Received: from mail56-db3 (localhost [127.0.0.1])	by mail56-db3-R.bigfish.com
	(Postfix) with ESMTP id 8AF35540337;
	Tue, 20 Dec 2011 12:10:10 +0000 (UTC)
X-SpamScore: -13
X-BigFish: VPS-13(zz1432N98dK4015Lzz1202hzz8275bhz2dh668h839h93fh)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
X-FB-SS: 0,13,
Received: from mail56-db3 (localhost.localdomain [127.0.0.1]) by mail56-db3
	(MessageSwitch) id 1324382964647200_9160;
	Tue, 20 Dec 2011 12:09:24 +0000 (UTC)
Received: from DB3EHSMHS019.bigfish.com (unknown [10.3.81.251])	by
	mail56-db3.bigfish.com (Postfix) with ESMTP id 977D93A0042;
	Tue, 20 Dec 2011 12:09:24 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	DB3EHSMHS019.bigfish.com (10.3.87.119) with Microsoft SMTP Server id
	14.1.225.23; Tue, 20 Dec 2011 12:08:55 +0000
X-WSS-ID: 0LWI4EW-01-47C-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 239AD1028083;	Tue, 20 Dec 2011 06:08:56 -0600 (CST)
Received: from SAUSEXDAG03.amd.com (163.181.55.3) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Tue, 20 Dec 2011 06:09:05 -0600
Received: from storexhtp01.amd.com (172.24.4.3) by sausexdag03.amd.com
	(163.181.55.3) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Tue, 20 Dec 2011 06:08:57 -0600
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp01.amd.com
	(172.24.4.3) with Microsoft SMTP Server id 8.3.213.0; Tue, 20 Dec 2011
	07:08:51 -0500
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 32D4049C58B; Tue, 20 Dec 2011
	12:08:50 +0000 (GMT)
Received: from gran.osrc.amd.com (gran.osrc.amd.com [165.204.15.57])	by
	mail.osrc.amd.com (Postfix) with ESMTP id 14EB25940FF; Tue, 20 Dec 2011
	13:08:50 +0100 (CET)
From: Wei Wang2 <wei.wang2@amd.com>
To: <xen-devel@lists.xensource.com>
Date: Tue, 20 Dec 2011 13:11:30 +0100
User-Agent: KMail/1.9.6 (enterprise 20070904.708012)
References: <1324319661.2599.28.camel@Solace> <1324320812.2599.34.camel@Solace>
In-Reply-To: <1324320812.2599.34.camel@Solace>
MIME-Version: 1.0
Content-Disposition: inline
Message-ID: <201112201311.31291.wei.wang2@amd.com>
X-OriginatorOrg: amd.com
Cc: Tim Deegan <tim@xen.org>, "allen.m.kay@intel.com" <allen.m.kay@intel.com>,
	Dario Faggioli <raistlin@linux.it>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 2 of 2] Move IOMMU faults handling into
	softirq for AMD-Vi.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Monday 19 December 2011 19:53:32 Dario Faggioli wrote:
> Dealing with interrupts from AMD-Vi IOMMU is deferred to a softirq-tasklet,
> raised by the actual IRQ handler. To avoid more interrupts being generated
> (because of further faults), they must be masked in the IOMMU within the
> low level IRQ handler and enabled back in the tasklet body. Notice that
> this may cause the log to overflow, but none of the existing entry will
> be overwritten.
>
> Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
>
> diff -r 12cc8fc9a908 xen/drivers/passthrough/amd/iommu_init.c
> --- a/xen/drivers/passthrough/amd/iommu_init.c	Mon Dec 19 16:46:14 2011
> +0000 +++ b/xen/drivers/passthrough/amd/iommu_init.c	Mon Dec 19 16:46:39
> 2011 +0000 @@ -32,6 +32,8 @@
>
>  static int __initdata nr_amd_iommus;
>
> +static struct tasklet amd_iommu_fault_tasklet;
> +
>  unsigned short ivrs_bdf_entries;
>  static struct radix_tree_root ivrs_maps;
>  struct list_head amd_iommu_head;
> @@ -522,12 +524,10 @@ static void parse_event_log_entry(struct
>      }
>  }
>
> -static void amd_iommu_page_fault(int irq, void *dev_id,
> -                             struct cpu_user_regs *regs)
> +static void __do_amd_iommu_page_fault(struct amd_iommu *iommu)
>  {
>      u32 entry;
>      unsigned long flags;
> -    struct amd_iommu *iommu = dev_id;
>
>      spin_lock_irqsave(&iommu->lock, flags);
>      amd_iommu_read_event_log(iommu);
> @@ -546,6 +546,43 @@ static void amd_iommu_page_fault(int irq
>      spin_unlock_irqrestore(&iommu->lock, flags);
>  }
>
> +static void do_amd_iommu_page_fault(unsigned long data)
> +{
> +    struct amd_iommu *iommu;
> +
> +    if ( list_empty(&amd_iommu_head) )

Here you could use iommu_found(). Rest part of this patch looks good to me.
Thanks,
Wei

> +    {
> +       AMD_IOMMU_DEBUG("no device found, something must be very
> wrong!\n"); +       return;
> +    }
> +
> +    /* No matter from whom the interrupt came from, check all the
> +     * IOMMUs present in the system. This allows for having just one
> +     * tasklet (instead of one per each IOMMU) and should be more than
> +     * fine, considering how rare the event of a fault should be. */
> +for_each_amd_iommu ( iommu )
> +        __do_amd_iommu_page_fault(iommu);
> +}
> +
> +static void amd_iommu_page_fault(int irq, void *dev_id,
> +                             struct cpu_user_regs *regs)
> +{
> +    u32 entry;
> +    unsigned long flags;
> +    struct amd_iommu *iommu = dev_id;
> +
> +    /* silence interrupts. The tasklet will enable them back */
> +    spin_lock_irqsave(&iommu->lock, flags);
> +    entry = readl(iommu->mmio_base + IOMMU_STATUS_MMIO_OFFSET);
> +    iommu_clear_bit(&entry, IOMMU_STATUS_EVENT_LOG_INT_SHIFT);
> +    writel(entry, iommu->mmio_base+IOMMU_STATUS_MMIO_OFFSET);
> +    spin_unlock_irqrestore(&iommu->lock, flags);
> +
> +    /* Flag the tasklet as runnable so that it can execute, clear
> +     * the log and re-enable interrupts. */
> +    tasklet_schedule(&amd_iommu_fault_tasklet);
> +}
> +
>  static int __init set_iommu_interrupt_handler(struct amd_iommu *iommu)
>  {
>      int irq, ret;
> @@ -884,6 +921,8 @@ int __init amd_iommu_init(void)
>          if ( amd_iommu_init_one(iommu) != 0 )
>              goto error_out;
>
> +    softirq_tasklet_init(&amd_iommu_fault_tasklet,
> do_amd_iommu_page_fault, 0); +
>      return 0;
>
>  error_out:




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 20 12:15:39 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 Dec 2011 12: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.xensource.com>)
	id 1Rcyax-00049k-2q; Tue, 20 Dec 2011 12:14:59 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <hui.lv@intel.com>) id 1Rcyav-00049b-BT
	for xen-devel@lists.xensource.com; Tue, 20 Dec 2011 12:14:57 +0000
X-Env-Sender: hui.lv@intel.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1324383254!57422964!1
X-Originating-IP: [134.134.136.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjQgPT4gMzE4MDY5\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9103 invoked from network); 20 Dec 2011 12:14:15 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-9.tower-27.messagelabs.com with SMTP;
	20 Dec 2011 12:14:15 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga102.jf.intel.com with ESMTP; 20 Dec 2011 04:14:50 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.67,351,1309762800"; d="scan'208";a="89485069"
Received: from pgsmsx602.gar.corp.intel.com ([10.221.43.81])
	by orsmga002.jf.intel.com with ESMTP; 20 Dec 2011 04:14:48 -0800
Received: from pgsmsx103.gar.corp.intel.com (10.221.44.82) by
	pgsmsx602.gar.corp.intel.com (10.221.43.81) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Tue, 20 Dec 2011 20:14:48 +0800
Received: from shsmsx601.ccr.corp.intel.com (10.239.4.112) by
	PGSMSX103.gar.corp.intel.com (10.221.44.82) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Tue, 20 Dec 2011 20:14:47 +0800
Received: from shsmsx502.ccr.corp.intel.com ([10.239.4.96]) by
	shsmsx601.ccr.corp.intel.com ([10.239.4.112]) with mapi;
	Tue, 20 Dec 2011 20:14:47 +0800
From: "Lv, Hui" <hui.lv@intel.com>
To: George Dunlap <george.dunlap@citrix.com>, Dario Faggioli
	<raistlin@linux.it>
Date: Tue, 20 Dec 2011 20:14:45 +0800
Thread-Topic: [Xen-devel] [PATCH] xen/sched_credit: Use delay to control
	scheduling frequency
Thread-Index: Acy/AVV3D7qsKl7FQtC3sfo0xo63HwADo+5g
Message-ID: <C10D3FB0CD45994C8A51FEC1227CE22F39412A99E4@shsmsx502.ccr.corp.intel.com>
References: <114495d1ff947737518b.1324332781@wsm-ep-n0>
	<1324372056.23729.8.camel@zakaz.uk.xensource.com>
	<C10D3FB0CD45994C8A51FEC1227CE22F39412A99CE@shsmsx502.ccr.corp.intel.com>
	<1324375765.6616.9.camel@Abyss> <1324376802.2143.154.camel@elijah>
In-Reply-To: <1324376802.2143.154.camel@elijah>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH] xen/sched_credit: Use delay to control
 scheduling frequency
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> How about this:
> 
> First, add a ratelimit_us element to csched_priv, just like the current tslice_ms
> element.
> 
> When the scheduler comes up (in csched_init), it checks to see if
> MICROSECS(sched_ratelimit_us) > MILLISECS(sched_credit_tslice_ms); if so, it
> prints a warning, and sets prv->ratelimit_us to 1000*prv->tslice_ms.
> 
I think it makes sense to do so.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 20 12:15:39 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 Dec 2011 12: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.xensource.com>)
	id 1Rcyax-00049k-2q; Tue, 20 Dec 2011 12:14:59 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <hui.lv@intel.com>) id 1Rcyav-00049b-BT
	for xen-devel@lists.xensource.com; Tue, 20 Dec 2011 12:14:57 +0000
X-Env-Sender: hui.lv@intel.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1324383254!57422964!1
X-Originating-IP: [134.134.136.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjQgPT4gMzE4MDY5\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9103 invoked from network); 20 Dec 2011 12:14:15 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-9.tower-27.messagelabs.com with SMTP;
	20 Dec 2011 12:14:15 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga102.jf.intel.com with ESMTP; 20 Dec 2011 04:14:50 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.67,351,1309762800"; d="scan'208";a="89485069"
Received: from pgsmsx602.gar.corp.intel.com ([10.221.43.81])
	by orsmga002.jf.intel.com with ESMTP; 20 Dec 2011 04:14:48 -0800
Received: from pgsmsx103.gar.corp.intel.com (10.221.44.82) by
	pgsmsx602.gar.corp.intel.com (10.221.43.81) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Tue, 20 Dec 2011 20:14:48 +0800
Received: from shsmsx601.ccr.corp.intel.com (10.239.4.112) by
	PGSMSX103.gar.corp.intel.com (10.221.44.82) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Tue, 20 Dec 2011 20:14:47 +0800
Received: from shsmsx502.ccr.corp.intel.com ([10.239.4.96]) by
	shsmsx601.ccr.corp.intel.com ([10.239.4.112]) with mapi;
	Tue, 20 Dec 2011 20:14:47 +0800
From: "Lv, Hui" <hui.lv@intel.com>
To: George Dunlap <george.dunlap@citrix.com>, Dario Faggioli
	<raistlin@linux.it>
Date: Tue, 20 Dec 2011 20:14:45 +0800
Thread-Topic: [Xen-devel] [PATCH] xen/sched_credit: Use delay to control
	scheduling frequency
Thread-Index: Acy/AVV3D7qsKl7FQtC3sfo0xo63HwADo+5g
Message-ID: <C10D3FB0CD45994C8A51FEC1227CE22F39412A99E4@shsmsx502.ccr.corp.intel.com>
References: <114495d1ff947737518b.1324332781@wsm-ep-n0>
	<1324372056.23729.8.camel@zakaz.uk.xensource.com>
	<C10D3FB0CD45994C8A51FEC1227CE22F39412A99CE@shsmsx502.ccr.corp.intel.com>
	<1324375765.6616.9.camel@Abyss> <1324376802.2143.154.camel@elijah>
In-Reply-To: <1324376802.2143.154.camel@elijah>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH] xen/sched_credit: Use delay to control
 scheduling frequency
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> How about this:
> 
> First, add a ratelimit_us element to csched_priv, just like the current tslice_ms
> element.
> 
> When the scheduler comes up (in csched_init), it checks to see if
> MICROSECS(sched_ratelimit_us) > MILLISECS(sched_credit_tslice_ms); if so, it
> prints a warning, and sets prv->ratelimit_us to 1000*prv->tslice_ms.
> 
I think it makes sense to do so.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 20 12:24:06 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 Dec 2011 12:24:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RcyjG-0004MX-Gl; Tue, 20 Dec 2011 12:23:34 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1RcyjD-0004MS-Qh
	for xen-devel@lists.xensource.com; Tue, 20 Dec 2011 12:23:32 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-10.tower-182.messagelabs.com!1324383805!7984393!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4755 invoked from network); 20 Dec 2011 12:23:25 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-10.tower-182.messagelabs.com with SMTP;
	20 Dec 2011 12:23:25 -0000
Received: from [62.94.181.91] (account d.faggioli@sssup.it HELO [192.168.0.20])
	by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 74050641; Tue, 20 Dec 2011 13:23:24 +0100
Message-ID: <1324383803.6616.16.camel@Abyss>
From: Dario Faggioli <raistlin@linux.it>
To: Wei Wang2 <wei.wang2@amd.com>
Date: Tue, 20 Dec 2011 13:23:23 +0100
In-Reply-To: <201112201311.31291.wei.wang2@amd.com>
References: <1324319661.2599.28.camel@Solace> <1324320812.2599.34.camel@Solace>
	<201112201311.31291.wei.wang2@amd.com>
Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwCAIAAADYYG7QAAAAA3NCSVQICAjb4U/gAAAVx0lEQVRYwzWY6a/d953XP9/tt51zfme/+37t692OtzhxtzTuJFPaTDVt0cDQeTIajToSKBJICBASQkI8Q1Q8ACQEhUGgCsF0OrSkaRLaxknqOl7i9dq++3727bd/Vx5k+CNe7+WFvvkvbvoywAZF1BMYOFNFbqWEW1gho42yB9jJq1QihEGVCh7BxrXpeNlxbJZmcmNvkArIhAIMJd+drlmA0aiXuBbN5x3Pxq6NS6X85l5/rxNnGtJYgAYhgVCa8UxqAwgQIABAGGMD1JWtS7/48Vy0W1k5GxXnmh41br1y6fxXv3LCEPXLu3vv3N3t2kXPAi0EIjTjnDGcKawzHceZl3N0mIExrmfnGS1iSij2pxgDxJhlsOFID8LUsVjecXvNPiJg2ZYySiODGUVcAwBCCAAMAIAhNc82C2xvuLG8uX422VvZfHrx9Mz5P7kRR51wby188YD+8metqQWBLa00F1JIlQk5imIhle+XBsHI9/PVUoFCBp7JOZbSjGiS92mx7IE0SICRkC/Yw2GSZECpIsYYwEmWGkDGIAAAAIQAY4QMEA6Nvc7G6aaYzKQlUs/x/O99VywsZcZd33w++l9/NbN6Z905MSqPGYO10QDYGCI1EIQQGMdzkzCo+G4pb5eY7blWKhKadiZ92yYsFWoYpwhRv0A4h/4oK5Zcl9nGAMLUgEYYMAZAmhBkM6KkoYpVIRjU47SRRUuVlXRlUZ08nxDyi50na+2jV1r9tTjK/DwYqgFRLHMuYdhCMou1bg64a0M15yKiCyCcLJlJspl+e6x3QNtuv1TbKIwHxpHIZDEYorGFh32eK3h+yc06XYqA2MyyLCmk0lobAFC04NsTyCGjOAbrp5svrs/N1sqeRegKscrF2aiz1ZfJweZPjLzojB0fdPcqFcv481592Y15KiKOLBDyd
	OPw1b37JZ3Qosdspk2Eh71iZ3MmJafLE/2l4w/pjBiiRMVJKjOtLItypb18LkxCmSilAIAorQCA0nLl0lGSqY5kyCP55bFpOwvW1vo79+7vb+z5yjSF1Wg9RaNNjKxRlObPnd/c+UurPFMZPzO5cPpcIt/c/HApaZp+Jzoa6FKhcu4kogzZFGmEGgczG6v1O+8uLp1eQ0VdOrXuLFqu0mAwwZkUCBOMmJAKDAIgAJq88f1/NucwtbZqaXP9pfNnFxY++ujmI4OZVzoYHfKtxnrY2PFAS46yuJTPNzvNYXvbDJsvTfr/5PSJl3/676cbhzvPV4ccbN9KTCoHHYa5xQoZRPpglw1SEim5tzN58KSc4b1LFzEmFiMEYwCSca01MsYAAoyRUYrGgjXOXfgbg8aE5hPV8vsPPr7XHJaPn4x6MY0GjsUWvnxy+dLSB7+43W6zN77y9Q/e/3ENvMvI/dO4WftX/xzidDvrO7Mnxqt+P0kshcCyRj2pe89zKSKxVjrWWKs4balUO/s26MwgqZU2JsmkUhjAAPpr0ACA3vjKydHuAa56B2u7Hz59qDFOkD149x1n9VkW81LevvCH54b5ztiY/+rLr7zxu1+TwdEr99deD0Ln1tMw4ixVhVpuemZGYT5W8JQCgyAMR1whY1IGqRI8E1ks0m2pnqq0k6ogUpgRroBLDQgjDBgTjAEUUgDUJI16Se7sbcWdfoxdzrRUwj7aV1I7165Mnjhx+oLz2+CTyclL3/2D74ApfOFr3w4Hf7778/dmSclIzoXKTy6n2QBrjRQyBPdGQ6RVlCQ8TXScMGk8iwWErsV8Z/58J9KZ0IgbBJgQiok2BghBCCFjMACQlesvrzjY/tWtOM0EoZwCU0Ym2ag+VZ5fLOf9xZXph61s8dibtdpYnApmFe3JmX6372UByfg+wKNOt+hYSgHBNjiesW3H9SyhqEKJlE2ZHiSjrVS2c8Xm639nhEoACAzGhDCGKSVKGQ
	AwBgECxQXNuz7uD1QvQFJEeeOm0iiFBbDu/uEzwW8O+P826hu/d6v0/PTx5Y8/ee/l66/lFqdqb9xQ//pRJ+KBwfmp8U1tmkgnXqaxbPd6/V4fJ1kJ6JQhderZ1OvE/aYSfeKBAYSQQVgbI5Q2UgMgBMgYAxgBAE1U6uQKuS9e7310qzwQ2pDUghR4JU3UZji07BfFamHtIF00O839zx7ceeXaFxGY/J1Hz1sHPEGHDlnTreLkyeNXrpQLDgjtBHF+GI6i4VEYfnpwpAejvNBnUdG2qkBdw4w2Bhv0eXeZzwMfIYQ+7zKgc7VynCux73176ktXV//ix6Onq67RxIhEGTDSHybQH4Xt6LU3317f2pycmGJUVxudOZ+o6Zn764dB0YHx6dCwp88eIYSIxpLLIIziLJbSOAKEW9QlZ7Posijv5awsSw1yDMIAGMAgZBBCGGNjDEJGAdCJnI9thwHLFr3pt9+e3Wl2W41fbj1NlD51sHvmxeP1YfqMya9fvfaf//E/3T/cfPP6K8vv3Wz/3w/SxiBPaDFUeGZ6V2Sd7UOtACmkpeRSaI0wMogZYzNk05KfG5Z8q5a9bBeaA90P0kRixGyuPqddY4wwQgKAFosVQjEANjF1lFIz4/1x50g0kyR+uVi79jtf/vmHL4LKhZ7WreYWMbH5b/8zu3vHGkUZlxjrSOkzy/Px/n5fYxAxNUCNIdhIojEhmDFM3By2sWdJNlajeKmUnqiwQNuRZJ0I398LDVBkABPABgEA7o/CMEhlplzHKlZL1WJVY4LB5Ci6+p2rvRv1uxm8evba/Qe/UaPuDUEXP/kNTdJewqtV/+zlK9yQnfWtdrsVp+koEWEmpQELUwcTqrGMVZpEiUqVU43PflUzLR2pbFqkenncKniZsRNjcaAcocRmGQBQh1kIISmllJLrbG/3oCujE7PHahYo8eDu46fUqawsLzx4+vEZN/eHQcJHyVBjz5DqsYWOwDm/nmP52TF
	vY79x1O4bKcp5b7JWIQoNklRhYhvKjBkfCrf3xJ7+ijVKo+TAsQuO4wKlDsMGpRRjlYm8U+wBp57jWrYlpFRKGa7G56b/4i//x0Hj4OKU9/03Tj3e3BuvFvP1QhJmf2Zcuz/UhGiNWK3a7US8Ovvaq7/zcXenmfWqrmdKpTRLGCO9KELGhJmIOHcZLY9XGo3BBTrUJxuzCtJ8refnuDY6EwRjbaRnA3OxjQ0AUK2U4EIZrYw2gIYyzVQyNV48e9wzRt6729p5sl+2ci8/+Gy80x5hMFIBsZOyf4TIrC4Uld05bChP+kpZNo4RywAERgyTPCJgO1bBmfALzb3B5msXrg0UqxaG5QJgy0UMrIxYjAhHZ4HtJVW3uAaCUkYNGAxGKYkBd/pNC2AizxYq/LPHn9hWfb4eFxob59cakhpXmIaCnGu9u7td9MdajTsvnbxAmY94YEFojOEGEcYQAYSY4VEx79J8QQ+yiPlBFq/aE1Gt7BmTwwo7jh5wjDlxGDWKMGKMAgBsW45t2TazGWHI0hs7G1oJIgavXjmTCKcXwJeuXsv+zwexyhLmxoRix3rEUAv0++3tDweHdzafvlZfxH6RS8cYAkAPW/0Xe612t2sAwNC0nz67t+rmcgEPW82+yEgqdZImo2Gnfbge9p6AaliuGsUj5lAAoJQxKYUCDYAEhkEYFPzCXA0q9eLme0m7K6auTgUf3ynYrCzprhJHBSdYnLX3jvSoNwrMzfbW7Y9aIaCwQMHlOS83XvWTRGDLihCkoyTujpiiBAOSYTKAOAjdXAFjLGTWae0/W3skwa3WJiYnpse9BQCgwyhCCAhBwOgoDErVCd1tLc2ge4+fBKHDjJk/fsrR76BhHBoIy6VoeSlFEmxKHNpN0rGJqbDbV9KwgWj3IlWQhGGlTXuUacvKMxtJhA3oLGZJL+Nht1M/eeZaq90wGDtu7tj8cYUsIU3J8yzKAAQVimdSICmlUQ93Xxw1W8cnxhYW
	wkKhY/C8X+ufq891Wy3P4Nsg26eWolx9dLC9P+wpZBKbNnv9AiGWlipNXEP1gGNKjJIFg0lmLJOWmS2UylMU91qWXw663X4nUAYjkNRxX9zd0oj4lclykTNCAIDatqORMVpJhNY21raP9lS0+bdeWd7ePXr8wlqaXiK//qDX3P20Nr41tZASRtSwhSRCUHVsZkO3F9qkgFKJDC4QprRSmcgTSjHFBjEwjtR5hEm7xxzmunkZhL1Od2F5th+2DQJDqF2ezo8vAcbUpABAkyTjUhjJRzrRQe9CsXj9st0ZbDVeDK8M7b+Nk+7qnaevfvVAC8G5ATTx2mtLRt7+d/+WpKHrWEnRO2gPxqUtMU4UV0bbzMKISCmBIKAUAGyAzvZWrmjZ1SJS/OHde/MzE2OVeqHgX3n5qnLHO/3UIO55GAAoF0pppbTuBoOEGkqsGqPXotlLvUp1pto8ffGdXuPFbz+lsSL5YovoW+++c2q8rmyLaocinCN6VLaToZFcYoM0xpHiHFAOU8aIBpAAgFEmZNLpmFpJsk5hciYeDmsTi/fuf7bX2auWx0rjc47v7j2+BXCRUoK4QQDQaB0Zg7SRhVSxx0NfzHWPrzxfXlj76EObxxqhv1p7fOLiJd8Ujp890z46HG5tGNAIKdtloRCJUjnMMAKsMEK4RbhCAhuMElkkdozAjIb5YZToZiDM5XNntQ2u5VKtGzsbe/tbpXye1SbBvkgJAMVYEzIajTyEj83YQ7/104Xhb37WvLGwEm3shUnAMhUiM1AZz9KjVmtydrpFCAeFMaYWtQBpn0mtBpkCpZAFiGLm2KAhHaY5REEjhJUDhAcxx05hLBcnaa1UKjALE+aVqpHIJienbBAAgEt+frxURBZRBkOuNF2lC2P4fif7JXa2uD7Y3+VxQlO5GwfMyecK+Xq1WB8b6yaBJEhqhRBGGGML56s+rnhW3XeqBavoEERFkFmAkdIIQR4wjlMRxx5zUgG3769qo
	U7MzLS7w04QGcs2zPbLPgDg3qAXh8PV7fXEoPm5xWIt543nRe585djS1vN7+MXDwfZGe9Dc63XSRBwcNOIoAgQjkQqGhdGAkNEaaUW0ylnUw9g1BIdKdsK8op4hNiUSa8VFvVI5ff6sSFOG2YOnG0kii26+6BeJxbjRSZpg1wMAbDMgFjxZvb+/u/X81ntJZysYos7hcNbLjy1MPtp6gkbdqD+oF6vFSs3NeTNT04NePwQtsNZAldYGIaUUaIkkRxrCME0GSQk7HmCiDQWEAQMCGcYXjh2zjQShohiGcXb1pQvH5ueLOafgOkaK2bEiAFDFZTcc2CpayMPSWO3kUn5zbXtwNNjfffTW3/9Hd29+mISBkWRhYf7333xzZqKUBaNOp9/ziqUgwSBSJGxqy0xrYUAZLkUUpXVs5zHJQEstkAFsMGNOOgiS++s05AiACp7G8Vi1xMPk5LFjbrGUQzA3UYOHQA1mz7e3D1qDAtNTp+cZNd2B+NaXvtjvqGrRs4pETXuHR73NezcDHTsMX7n2ansYzc2drnO7K5+vzEwqrtf3okAbkxgeZyCMTy0bUY1U9v/FmMUoaHPc5LOZY7/urk9Yo3H2eu+ou1ir/urxqtHZialp98wUAGAA9XhrPaH+SJPKhB+lfL2de//uemblk0hcml34g7feOHN+5eyZk6eXpoP2YaXsdzdXv3ugb9SXSi75va9d+4f/4I+/89aNotb9ILYFnrYLHsYUAUMYGQAD1CCCSd0tfPrg/hwH0ttctgN7dDjGu0sOdqmZKlvnj88SpAGAPtnYyESKVFTP8Zw16rUOW116FOPr5fqz7b2fP36hP+7zWAkplxdmEUEF1748O/7wg59MaOv7J065NzcOnrW8nKeo48lwxStSLi3QgCkiaATYGMMMgNG1QmlfxxO9Xtn1Ro2+UnDz5z+LgzTP0Hgtl7MhzmIAwI/XVgNBAqNXTh2v5Mwwg3Z3wEfJ7OxyHHPb9SNuEi
	64Ed1RmAjm58rbHz85qdCfzi2fHfH67sj+6EX6s0/hoPvW5Mmq5MwimlCikUXtIYOYIYWUz1impU75ve6WzeHK+OKf/+AHYchVKuJRsLrTfHHY6A77AEAnZ6bBXc6ePj+1UOmPntxfkx3t5yzI5Uu7e3sYEDKmXirisisJnqxPH7Q68aD3rYVllkQJF6GUsRQmiE4j9/Wpkz9tHhGtDSUKACgOmcmQdhS1LDvLMoOwjJJ4d/ir4cfP0qaA23pxWc5N0FKhnQiLMQCgFceSFl24dPwLF4s/efe2P3llmoAbB5ZLw3gYxFE/jkdZNl8udA47KyunB72jb1Qn7c5gmGVcqJTzkVbAzY1TV89fvHR398nBYMgNikD5mhSQHWJuXM/OFaJhKLHhowAIWfjGl7b3nwbx8Nw3f9cCEDJjXAeDEQCQOGjFRzsny8FkRe43i0+fH2jIn5qZkxG/fft+rlDNlSYzxOanZxuj/hfPnLu+erCyvquSmKd6oOORkoMw+VTEb37hm6oXzdq5o2DU0akUMnbJhhgUHHeCelRBnGXDLAGDLMcrvHJ58dtvfXC4tdntCQG+bU/MTPl8sD5cIlMztSAOvvX6ceJEO3tHn7z3JG20XJleu3w1ToPdvQ0j+GS9/vWv3Xjl1Onru935W59ClnZGQ4sxi7FA8N+OBs8QOZqvD20z7fpoGDbikIMwMiNSlRG1DVWZiHiCCHUtG1vW+T/6fXDtrfZRnGSDqN8bdMbLpaS909EXaYBYKafPXl367PH9nd0gzTRRoWPnKWJ/81vfPnNy5Yc//OGt28/nHHhjoz03AD4cZdgUixULcJylFnZ7AOlYuXjj5R/9x//033cPr1VnRjKyLUtkkRYyFIJDUsv5DsWI0ZFUr/2977Gx+iCJDnu9IAgRNYVqaTjomFEEOaA2QV//8qLD0t2do62dWChIs2R8cqbgl0DJ4/NLb//dtzvd7kub2xceHQUqjJDqRmHQjQuOqyn
	ZiaKpyoRz4wuXzr70/MTyi8bR+72NEqPVTGL4a1NvIQRK5Cw3MDBz+RI6tpAAhJIzy65WEGOEYEhF5iv6+VE0F05P+f7Ui61Od4iV1hb1p6amM5USQFoh368t5IvjP/m1ylIuJAhFCGXMotQyjGCbbzX39p88Pvyv/8V2XZT3yED2sHYskteYCcIwBg0DwTVzZLkQ1XyTSuvzgUCpEglFVGMMmNSrzpEAim310sWX7j5ZI9Zc5/ARF6w651dqVSllKIWJhxF3is9XaaPNNOQsBkAdLRLCNMbNLBYGIbcgbdJu7iEpjO+aOE45fxIPl73SuFeORBpgaSwmPUp8ZutU89S1LRwazKgyFkLYY7bHnIXp4sNtoCtLtYnx8n/40Y+2d5U21PfL/+YH/5JqY7v5Ti950DksKlV4+CQnpaY441xzJUBigjMpM6N247ANOGKUKAnaOPliRILBsJ8geDDq1ZhjuzatFsMoKlBdMUbE8aDfY5S5tnvp8pWUZzzL0iR2bdbpHALA/wMUjQteOh3xIgAAAABJRU5ErkJggg==
X-Mailer: Evolution 3.2.2 (3.2.2-1.fc16) 
Mime-Version: 1.0
Cc: "allen.m.kay@intel.com" <allen.m.kay@intel.com>,
	xen-devel@lists.xensource.com, Tim Deegan <tim@xen.org>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 2 of 2] Move IOMMU faults handling into
 softirq for AMD-Vi.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============4082686191325249858=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--===============4082686191325249858==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-hOvTfrfRjfsCw5WeYGh/"


--=-hOvTfrfRjfsCw5WeYGh/
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, 2011-12-20 at 13:11 +0100, Wei Wang2 wrote:=20
> > +static void do_amd_iommu_page_fault(unsigned long data)
> > +{
> > +    struct amd_iommu *iommu;
> > +
> > +    if ( list_empty(&amd_iommu_head) )
>=20
> Here you could use iommu_found().=20
>
Ok, cool. Will do that.

> Rest part of this patch looks good to me.
> Thanks,
>
Thanks to you... Let's wait for some feedback from VT-d people and I'll
respin the whole thing.

Thanks and Regards,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-------------------------------------------------------------------
Dario Faggioli, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
PhD Candidate, ReTiS Lab, Scuola Superiore Sant'Anna, Pisa (Italy)



--=-hOvTfrfRjfsCw5WeYGh/
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEABECAAYFAk7wfjsACgkQk4XaBE3IOsR2/wCfX7eF9ljE4bF9ULU29DvfdXCt
fnMAoJbOPTtraJ+6tjRtHPa7EkhMNiKy
=qhXp
-----END PGP SIGNATURE-----

--=-hOvTfrfRjfsCw5WeYGh/--



--===============4082686191325249858==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============4082686191325249858==--



From xen-devel-bounces@lists.xensource.com Tue Dec 20 12:24:06 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 Dec 2011 12:24:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RcyjG-0004MX-Gl; Tue, 20 Dec 2011 12:23:34 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1RcyjD-0004MS-Qh
	for xen-devel@lists.xensource.com; Tue, 20 Dec 2011 12:23:32 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-10.tower-182.messagelabs.com!1324383805!7984393!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4755 invoked from network); 20 Dec 2011 12:23:25 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-10.tower-182.messagelabs.com with SMTP;
	20 Dec 2011 12:23:25 -0000
Received: from [62.94.181.91] (account d.faggioli@sssup.it HELO [192.168.0.20])
	by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 74050641; Tue, 20 Dec 2011 13:23:24 +0100
Message-ID: <1324383803.6616.16.camel@Abyss>
From: Dario Faggioli <raistlin@linux.it>
To: Wei Wang2 <wei.wang2@amd.com>
Date: Tue, 20 Dec 2011 13:23:23 +0100
In-Reply-To: <201112201311.31291.wei.wang2@amd.com>
References: <1324319661.2599.28.camel@Solace> <1324320812.2599.34.camel@Solace>
	<201112201311.31291.wei.wang2@amd.com>
Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwCAIAAADYYG7QAAAAA3NCSVQICAjb4U/gAAAVx0lEQVRYwzWY6a/d953XP9/tt51zfme/+37t692OtzhxtzTuJFPaTDVt0cDQeTIajToSKBJICBASQkI8Q1Q8ACQEhUGgCsF0OrSkaRLaxknqOl7i9dq++3727bd/Vx5k+CNe7+WFvvkvbvoywAZF1BMYOFNFbqWEW1gho42yB9jJq1QihEGVCh7BxrXpeNlxbJZmcmNvkArIhAIMJd+drlmA0aiXuBbN5x3Pxq6NS6X85l5/rxNnGtJYgAYhgVCa8UxqAwgQIABAGGMD1JWtS7/48Vy0W1k5GxXnmh41br1y6fxXv3LCEPXLu3vv3N3t2kXPAi0EIjTjnDGcKawzHceZl3N0mIExrmfnGS1iSij2pxgDxJhlsOFID8LUsVjecXvNPiJg2ZYySiODGUVcAwBCCAAMAIAhNc82C2xvuLG8uX422VvZfHrx9Mz5P7kRR51wby188YD+8metqQWBLa00F1JIlQk5imIhle+XBsHI9/PVUoFCBp7JOZbSjGiS92mx7IE0SICRkC/Yw2GSZECpIsYYwEmWGkDGIAAAAIQAY4QMEA6Nvc7G6aaYzKQlUs/x/O99VywsZcZd33w++l9/NbN6Z905MSqPGYO10QDYGCI1EIQQGMdzkzCo+G4pb5eY7blWKhKadiZ92yYsFWoYpwhRv0A4h/4oK5Zcl9nGAMLUgEYYMAZAmhBkM6KkoYpVIRjU47SRRUuVlXRlUZ08nxDyi50na+2jV1r9tTjK/DwYqgFRLHMuYdhCMou1bg64a0M15yKiCyCcLJlJspl+e6x3QNtuv1TbKIwHxpHIZDEYorGFh32eK3h+yc06XYqA2MyyLCmk0lobAFC04NsTyCGjOAbrp5svrs/N1sqeRegKscrF2aiz1ZfJweZPjLzojB0fdPcqFcv481592Y15KiKOLBDyd
	OPw1b37JZ3Qosdspk2Eh71iZ3MmJafLE/2l4w/pjBiiRMVJKjOtLItypb18LkxCmSilAIAorQCA0nLl0lGSqY5kyCP55bFpOwvW1vo79+7vb+z5yjSF1Wg9RaNNjKxRlObPnd/c+UurPFMZPzO5cPpcIt/c/HApaZp+Jzoa6FKhcu4kogzZFGmEGgczG6v1O+8uLp1eQ0VdOrXuLFqu0mAwwZkUCBOMmJAKDAIgAJq88f1/NucwtbZqaXP9pfNnFxY++ujmI4OZVzoYHfKtxnrY2PFAS46yuJTPNzvNYXvbDJsvTfr/5PSJl3/676cbhzvPV4ccbN9KTCoHHYa5xQoZRPpglw1SEim5tzN58KSc4b1LFzEmFiMEYwCSca01MsYAAoyRUYrGgjXOXfgbg8aE5hPV8vsPPr7XHJaPn4x6MY0GjsUWvnxy+dLSB7+43W6zN77y9Q/e/3ENvMvI/dO4WftX/xzidDvrO7Mnxqt+P0kshcCyRj2pe89zKSKxVjrWWKs4balUO/s26MwgqZU2JsmkUhjAAPpr0ACA3vjKydHuAa56B2u7Hz59qDFOkD149x1n9VkW81LevvCH54b5ztiY/+rLr7zxu1+TwdEr99deD0Ln1tMw4ixVhVpuemZGYT5W8JQCgyAMR1whY1IGqRI8E1ks0m2pnqq0k6ogUpgRroBLDQgjDBgTjAEUUgDUJI16Se7sbcWdfoxdzrRUwj7aV1I7165Mnjhx+oLz2+CTyclL3/2D74ApfOFr3w4Hf7778/dmSclIzoXKTy6n2QBrjRQyBPdGQ6RVlCQ8TXScMGk8iwWErsV8Z/58J9KZ0IgbBJgQiok2BghBCCFjMACQlesvrzjY/tWtOM0EoZwCU0Ym2ag+VZ5fLOf9xZXph61s8dibtdpYnApmFe3JmX6372UByfg+wKNOt+hYSgHBNjiesW3H9SyhqEKJlE2ZHiSjrVS2c8Xm639nhEoACAzGhDCGKSVKGQ
	AwBgECxQXNuz7uD1QvQFJEeeOm0iiFBbDu/uEzwW8O+P826hu/d6v0/PTx5Y8/ee/l66/lFqdqb9xQ//pRJ+KBwfmp8U1tmkgnXqaxbPd6/V4fJ1kJ6JQhderZ1OvE/aYSfeKBAYSQQVgbI5Q2UgMgBMgYAxgBAE1U6uQKuS9e7310qzwQ2pDUghR4JU3UZji07BfFamHtIF00O839zx7ceeXaFxGY/J1Hz1sHPEGHDlnTreLkyeNXrpQLDgjtBHF+GI6i4VEYfnpwpAejvNBnUdG2qkBdw4w2Bhv0eXeZzwMfIYQ+7zKgc7VynCux73176ktXV//ix6Onq67RxIhEGTDSHybQH4Xt6LU3317f2pycmGJUVxudOZ+o6Zn764dB0YHx6dCwp88eIYSIxpLLIIziLJbSOAKEW9QlZ7Posijv5awsSw1yDMIAGMAgZBBCGGNjDEJGAdCJnI9thwHLFr3pt9+e3Wl2W41fbj1NlD51sHvmxeP1YfqMya9fvfaf//E/3T/cfPP6K8vv3Wz/3w/SxiBPaDFUeGZ6V2Sd7UOtACmkpeRSaI0wMogZYzNk05KfG5Z8q5a9bBeaA90P0kRixGyuPqddY4wwQgKAFosVQjEANjF1lFIz4/1x50g0kyR+uVi79jtf/vmHL4LKhZ7WreYWMbH5b/8zu3vHGkUZlxjrSOkzy/Px/n5fYxAxNUCNIdhIojEhmDFM3By2sWdJNlajeKmUnqiwQNuRZJ0I398LDVBkABPABgEA7o/CMEhlplzHKlZL1WJVY4LB5Ci6+p2rvRv1uxm8evba/Qe/UaPuDUEXP/kNTdJewqtV/+zlK9yQnfWtdrsVp+koEWEmpQELUwcTqrGMVZpEiUqVU43PflUzLR2pbFqkenncKniZsRNjcaAcocRmGQBQh1kIISmllJLrbG/3oCujE7PHahYo8eDu46fUqawsLzx4+vEZN/eHQcJHyVBjz5DqsYWOwDm/nmP52TF
	vY79x1O4bKcp5b7JWIQoNklRhYhvKjBkfCrf3xJ7+ijVKo+TAsQuO4wKlDsMGpRRjlYm8U+wBp57jWrYlpFRKGa7G56b/4i//x0Hj4OKU9/03Tj3e3BuvFvP1QhJmf2Zcuz/UhGiNWK3a7US8Ovvaq7/zcXenmfWqrmdKpTRLGCO9KELGhJmIOHcZLY9XGo3BBTrUJxuzCtJ8refnuDY6EwRjbaRnA3OxjQ0AUK2U4EIZrYw2gIYyzVQyNV48e9wzRt6729p5sl+2ci8/+Gy80x5hMFIBsZOyf4TIrC4Uld05bChP+kpZNo4RywAERgyTPCJgO1bBmfALzb3B5msXrg0UqxaG5QJgy0UMrIxYjAhHZ4HtJVW3uAaCUkYNGAxGKYkBd/pNC2AizxYq/LPHn9hWfb4eFxob59cakhpXmIaCnGu9u7td9MdajTsvnbxAmY94YEFojOEGEcYQAYSY4VEx79J8QQ+yiPlBFq/aE1Gt7BmTwwo7jh5wjDlxGDWKMGKMAgBsW45t2TazGWHI0hs7G1oJIgavXjmTCKcXwJeuXsv+zwexyhLmxoRix3rEUAv0++3tDweHdzafvlZfxH6RS8cYAkAPW/0Xe612t2sAwNC0nz67t+rmcgEPW82+yEgqdZImo2Gnfbge9p6AaliuGsUj5lAAoJQxKYUCDYAEhkEYFPzCXA0q9eLme0m7K6auTgUf3ynYrCzprhJHBSdYnLX3jvSoNwrMzfbW7Y9aIaCwQMHlOS83XvWTRGDLihCkoyTujpiiBAOSYTKAOAjdXAFjLGTWae0/W3skwa3WJiYnpse9BQCgwyhCCAhBwOgoDErVCd1tLc2ge4+fBKHDjJk/fsrR76BhHBoIy6VoeSlFEmxKHNpN0rGJqbDbV9KwgWj3IlWQhGGlTXuUacvKMxtJhA3oLGZJL+Nht1M/eeZaq90wGDtu7tj8cYUsIU3J8yzKAAQVimdSICmlUQ93Xxw1W8cnxhYW
	wkKhY/C8X+ufq891Wy3P4Nsg26eWolx9dLC9P+wpZBKbNnv9AiGWlipNXEP1gGNKjJIFg0lmLJOWmS2UylMU91qWXw663X4nUAYjkNRxX9zd0oj4lclykTNCAIDatqORMVpJhNY21raP9lS0+bdeWd7ePXr8wlqaXiK//qDX3P20Nr41tZASRtSwhSRCUHVsZkO3F9qkgFKJDC4QprRSmcgTSjHFBjEwjtR5hEm7xxzmunkZhL1Od2F5th+2DQJDqF2ezo8vAcbUpABAkyTjUhjJRzrRQe9CsXj9st0ZbDVeDK8M7b+Nk+7qnaevfvVAC8G5ATTx2mtLRt7+d/+WpKHrWEnRO2gPxqUtMU4UV0bbzMKISCmBIKAUAGyAzvZWrmjZ1SJS/OHde/MzE2OVeqHgX3n5qnLHO/3UIO55GAAoF0pppbTuBoOEGkqsGqPXotlLvUp1pto8ffGdXuPFbz+lsSL5YovoW+++c2q8rmyLaocinCN6VLaToZFcYoM0xpHiHFAOU8aIBpAAgFEmZNLpmFpJsk5hciYeDmsTi/fuf7bX2auWx0rjc47v7j2+BXCRUoK4QQDQaB0Zg7SRhVSxx0NfzHWPrzxfXlj76EObxxqhv1p7fOLiJd8Ujp890z46HG5tGNAIKdtloRCJUjnMMAKsMEK4RbhCAhuMElkkdozAjIb5YZToZiDM5XNntQ2u5VKtGzsbe/tbpXye1SbBvkgJAMVYEzIajTyEj83YQ7/104Xhb37WvLGwEm3shUnAMhUiM1AZz9KjVmtydrpFCAeFMaYWtQBpn0mtBpkCpZAFiGLm2KAhHaY5REEjhJUDhAcxx05hLBcnaa1UKjALE+aVqpHIJienbBAAgEt+frxURBZRBkOuNF2lC2P4fif7JXa2uD7Y3+VxQlO5GwfMyecK+Xq1WB8b6yaBJEhqhRBGGGML56s+rnhW3XeqBavoEERFkFmAkdIIQR4wjlMRxx5zUgG3769qo
	U7MzLS7w04QGcs2zPbLPgDg3qAXh8PV7fXEoPm5xWIt543nRe585djS1vN7+MXDwfZGe9Dc63XSRBwcNOIoAgQjkQqGhdGAkNEaaUW0ylnUw9g1BIdKdsK8op4hNiUSa8VFvVI5ff6sSFOG2YOnG0kii26+6BeJxbjRSZpg1wMAbDMgFjxZvb+/u/X81ntJZysYos7hcNbLjy1MPtp6gkbdqD+oF6vFSs3NeTNT04NePwQtsNZAldYGIaUUaIkkRxrCME0GSQk7HmCiDQWEAQMCGcYXjh2zjQShohiGcXb1pQvH5ueLOafgOkaK2bEiAFDFZTcc2CpayMPSWO3kUn5zbXtwNNjfffTW3/9Hd29+mISBkWRhYf7333xzZqKUBaNOp9/ziqUgwSBSJGxqy0xrYUAZLkUUpXVs5zHJQEstkAFsMGNOOgiS++s05AiACp7G8Vi1xMPk5LFjbrGUQzA3UYOHQA1mz7e3D1qDAtNTp+cZNd2B+NaXvtjvqGrRs4pETXuHR73NezcDHTsMX7n2ansYzc2drnO7K5+vzEwqrtf3okAbkxgeZyCMTy0bUY1U9v/FmMUoaHPc5LOZY7/urk9Yo3H2eu+ou1ir/urxqtHZialp98wUAGAA9XhrPaH+SJPKhB+lfL2de//uemblk0hcml34g7feOHN+5eyZk6eXpoP2YaXsdzdXv3ugb9SXSi75va9d+4f/4I+/89aNotb9ILYFnrYLHsYUAUMYGQAD1CCCSd0tfPrg/hwH0ttctgN7dDjGu0sOdqmZKlvnj88SpAGAPtnYyESKVFTP8Zw16rUOW116FOPr5fqz7b2fP36hP+7zWAkplxdmEUEF1748O/7wg59MaOv7J065NzcOnrW8nKeo48lwxStSLi3QgCkiaATYGMMMgNG1QmlfxxO9Xtn1Ro2+UnDz5z+LgzTP0Hgtl7MhzmIAwI/XVgNBAqNXTh2v5Mwwg3Z3wEfJ7OxyHHPb9SNuEi
	64Ed1RmAjm58rbHz85qdCfzi2fHfH67sj+6EX6s0/hoPvW5Mmq5MwimlCikUXtIYOYIYWUz1impU75ve6WzeHK+OKf/+AHYchVKuJRsLrTfHHY6A77AEAnZ6bBXc6ePj+1UOmPntxfkx3t5yzI5Uu7e3sYEDKmXirisisJnqxPH7Q68aD3rYVllkQJF6GUsRQmiE4j9/Wpkz9tHhGtDSUKACgOmcmQdhS1LDvLMoOwjJJ4d/ir4cfP0qaA23pxWc5N0FKhnQiLMQCgFceSFl24dPwLF4s/efe2P3llmoAbB5ZLw3gYxFE/jkdZNl8udA47KyunB72jb1Qn7c5gmGVcqJTzkVbAzY1TV89fvHR398nBYMgNikD5mhSQHWJuXM/OFaJhKLHhowAIWfjGl7b3nwbx8Nw3f9cCEDJjXAeDEQCQOGjFRzsny8FkRe43i0+fH2jIn5qZkxG/fft+rlDNlSYzxOanZxuj/hfPnLu+erCyvquSmKd6oOORkoMw+VTEb37hm6oXzdq5o2DU0akUMnbJhhgUHHeCelRBnGXDLAGDLMcrvHJ58dtvfXC4tdntCQG+bU/MTPl8sD5cIlMztSAOvvX6ceJEO3tHn7z3JG20XJleu3w1ToPdvQ0j+GS9/vWv3Xjl1Onru935W59ClnZGQ4sxi7FA8N+OBs8QOZqvD20z7fpoGDbikIMwMiNSlRG1DVWZiHiCCHUtG1vW+T/6fXDtrfZRnGSDqN8bdMbLpaS909EXaYBYKafPXl367PH9nd0gzTRRoWPnKWJ/81vfPnNy5Yc//OGt28/nHHhjoz03AD4cZdgUixULcJylFnZ7AOlYuXjj5R/9x//033cPr1VnRjKyLUtkkRYyFIJDUsv5DsWI0ZFUr/2977Gx+iCJDnu9IAgRNYVqaTjomFEEOaA2QV//8qLD0t2do62dWChIs2R8cqbgl0DJ4/NLb//dtzvd7kub2xceHQUqjJDqRmHQjQuOqyn
	ZiaKpyoRz4wuXzr70/MTyi8bR+72NEqPVTGL4a1NvIQRK5Cw3MDBz+RI6tpAAhJIzy65WEGOEYEhF5iv6+VE0F05P+f7Ui61Od4iV1hb1p6amM5USQFoh368t5IvjP/m1ylIuJAhFCGXMotQyjGCbbzX39p88Pvyv/8V2XZT3yED2sHYskteYCcIwBg0DwTVzZLkQ1XyTSuvzgUCpEglFVGMMmNSrzpEAim310sWX7j5ZI9Zc5/ARF6w651dqVSllKIWJhxF3is9XaaPNNOQsBkAdLRLCNMbNLBYGIbcgbdJu7iEpjO+aOE45fxIPl73SuFeORBpgaSwmPUp8ZutU89S1LRwazKgyFkLYY7bHnIXp4sNtoCtLtYnx8n/40Y+2d5U21PfL/+YH/5JqY7v5Ti950DksKlV4+CQnpaY441xzJUBigjMpM6N247ANOGKUKAnaOPliRILBsJ8geDDq1ZhjuzatFsMoKlBdMUbE8aDfY5S5tnvp8pWUZzzL0iR2bdbpHALA/wMUjQteOh3xIgAAAABJRU5ErkJggg==
X-Mailer: Evolution 3.2.2 (3.2.2-1.fc16) 
Mime-Version: 1.0
Cc: "allen.m.kay@intel.com" <allen.m.kay@intel.com>,
	xen-devel@lists.xensource.com, Tim Deegan <tim@xen.org>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 2 of 2] Move IOMMU faults handling into
 softirq for AMD-Vi.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============4082686191325249858=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--===============4082686191325249858==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-hOvTfrfRjfsCw5WeYGh/"


--=-hOvTfrfRjfsCw5WeYGh/
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, 2011-12-20 at 13:11 +0100, Wei Wang2 wrote:=20
> > +static void do_amd_iommu_page_fault(unsigned long data)
> > +{
> > +    struct amd_iommu *iommu;
> > +
> > +    if ( list_empty(&amd_iommu_head) )
>=20
> Here you could use iommu_found().=20
>
Ok, cool. Will do that.

> Rest part of this patch looks good to me.
> Thanks,
>
Thanks to you... Let's wait for some feedback from VT-d people and I'll
respin the whole thing.

Thanks and Regards,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-------------------------------------------------------------------
Dario Faggioli, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
PhD Candidate, ReTiS Lab, Scuola Superiore Sant'Anna, Pisa (Italy)



--=-hOvTfrfRjfsCw5WeYGh/
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEABECAAYFAk7wfjsACgkQk4XaBE3IOsR2/wCfX7eF9ljE4bF9ULU29DvfdXCt
fnMAoJbOPTtraJ+6tjRtHPa7EkhMNiKy
=qhXp
-----END PGP SIGNATURE-----

--=-hOvTfrfRjfsCw5WeYGh/--



--===============4082686191325249858==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============4082686191325249858==--



From xen-devel-bounces@lists.xensource.com Tue Dec 20 12:58:28 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 Dec 2011 12:58:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RczGf-0004yn-4N; Tue, 20 Dec 2011 12:58:05 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RczGd-0004yi-Jm
	for xen-devel@lists.xensource.com; Tue, 20 Dec 2011 12:58:03 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1324385874!2221197!1
X-Originating-IP: [209.85.210.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31504 invoked from network); 20 Dec 2011 12:57:56 -0000
Received: from mail-pz0-f43.google.com (HELO mail-pz0-f43.google.com)
	(209.85.210.43)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Dec 2011 12:57:56 -0000
Received: by daec6 with SMTP id c6so27623543dae.30
	for <xen-devel@lists.xensource.com>;
	Tue, 20 Dec 2011 04:57:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=XjBQQW+gvTYOnti+IvGfIfyp4UaispO2P8wdeseTc24=;
	b=YJvILdeGN0FfnoFjFs+FssQ8s6+cLlFx9WLLDMzjXukRnCUEy+dCXLHWGoiL0AtVlM
	4j0iJnacs4QxHIGEJHfdB0Gjrb4kxOlC8ohZEI8bc7TrwF9TEf2UCgQY40aUX71ogRW5
	qPImQXHPxniqXwod4Yw17evTb6UoWioOP2dqA=
MIME-Version: 1.0
Received: by 10.68.212.68 with SMTP id ni4mr3462160pbc.44.1324385873356; Tue,
	20 Dec 2011 04:57:53 -0800 (PST)
Received: by 10.142.47.17 with HTTP; Tue, 20 Dec 2011 04:57:53 -0800 (PST)
In-Reply-To: <CB13AF82.3631C%keir@xen.org>
References: <CAPLaKK6Bv4f605TruaU8JCnBSWeBVg4o7q+o4Pwp1XVmk-GQdg@mail.gmail.com>
	<CB13AF82.3631C%keir@xen.org>
Date: Tue, 20 Dec 2011 13:57:53 +0100
X-Google-Sender-Auth: uL4xhXfJwcWpix9rPbg9i4nU9Y0
Message-ID: <CAPLaKK5nUzJBgp5cqot__quEVNmgqUFbm8mRVbthA3XT0d6Zkg@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Keir Fraser <keir@xen.org>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] ipxe: fix compilation issues with some gcc
	versions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

2011/12/18 Keir Fraser <keir@xen.org>:
> Done for 4.1. In 4.0 it looks like we have the generated code checked in, so
> this fix is not necessary there.

Is there any preferred revision of ipxe that we should choose for
unstable or just pick the latest one?

Roger.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 20 12:58:28 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 Dec 2011 12:58:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RczGf-0004yn-4N; Tue, 20 Dec 2011 12:58:05 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RczGd-0004yi-Jm
	for xen-devel@lists.xensource.com; Tue, 20 Dec 2011 12:58:03 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1324385874!2221197!1
X-Originating-IP: [209.85.210.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31504 invoked from network); 20 Dec 2011 12:57:56 -0000
Received: from mail-pz0-f43.google.com (HELO mail-pz0-f43.google.com)
	(209.85.210.43)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Dec 2011 12:57:56 -0000
Received: by daec6 with SMTP id c6so27623543dae.30
	for <xen-devel@lists.xensource.com>;
	Tue, 20 Dec 2011 04:57:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=XjBQQW+gvTYOnti+IvGfIfyp4UaispO2P8wdeseTc24=;
	b=YJvILdeGN0FfnoFjFs+FssQ8s6+cLlFx9WLLDMzjXukRnCUEy+dCXLHWGoiL0AtVlM
	4j0iJnacs4QxHIGEJHfdB0Gjrb4kxOlC8ohZEI8bc7TrwF9TEf2UCgQY40aUX71ogRW5
	qPImQXHPxniqXwod4Yw17evTb6UoWioOP2dqA=
MIME-Version: 1.0
Received: by 10.68.212.68 with SMTP id ni4mr3462160pbc.44.1324385873356; Tue,
	20 Dec 2011 04:57:53 -0800 (PST)
Received: by 10.142.47.17 with HTTP; Tue, 20 Dec 2011 04:57:53 -0800 (PST)
In-Reply-To: <CB13AF82.3631C%keir@xen.org>
References: <CAPLaKK6Bv4f605TruaU8JCnBSWeBVg4o7q+o4Pwp1XVmk-GQdg@mail.gmail.com>
	<CB13AF82.3631C%keir@xen.org>
Date: Tue, 20 Dec 2011 13:57:53 +0100
X-Google-Sender-Auth: uL4xhXfJwcWpix9rPbg9i4nU9Y0
Message-ID: <CAPLaKK5nUzJBgp5cqot__quEVNmgqUFbm8mRVbthA3XT0d6Zkg@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Keir Fraser <keir@xen.org>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] ipxe: fix compilation issues with some gcc
	versions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

2011/12/18 Keir Fraser <keir@xen.org>:
> Done for 4.1. In 4.0 it looks like we have the generated code checked in, so
> this fix is not necessary there.

Is there any preferred revision of ipxe that we should choose for
unstable or just pick the latest one?

Roger.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 20 13:02:54 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 Dec 2011 13:02:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RczKv-0005BH-QJ; Tue, 20 Dec 2011 13:02:29 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RczKu-0005BA-8F
	for xen-devel@lists.xensource.com; Tue, 20 Dec 2011 13:02:28 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1324386140!6266273!1
X-Originating-IP: [209.85.212.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28089 invoked from network); 20 Dec 2011 13:02:21 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Dec 2011 13:02:21 -0000
Received: by wico1 with SMTP id o1so3592487wic.30
	for <xen-devel@lists.xensource.com>;
	Tue, 20 Dec 2011 05:02:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=t+TStS7PCKw+EXw9LJuv5p//DZou2rcc3J59GwCC2Q0=;
	b=cpgQlxKg2au8JOSNjEeQ/X0Q7x0D1T/Kx/NF7DxVAunzKXEBiruBSdkj1OwudElCxY
	NAGj8hJDj5q0c1YCm87Pg99cMA7Cff11KiH1FLTap167YcV66q633FfjJPz5eMOAU2Gd
	x1fX2P2Z4Sbofh5TpWGV2wAMGBV1YbaqSfJyM=
Received: by 10.181.13.17 with SMTP id eu17mr4547619wid.12.1324386140450;
	Tue, 20 Dec 2011 05:02:20 -0800 (PST)
Received: from [192.168.1.70] (host81-152-17-11.range81-152.btcentralplus.com.
	[81.152.17.11])
	by mx.google.com with ESMTPS id dd4sm4358261wib.1.2011.12.20.05.02.17
	(version=SSLv3 cipher=OTHER); Tue, 20 Dec 2011 05:02:19 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Tue, 20 Dec 2011 13:02:13 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Roger Pau =?ISO-8859-1?B?TW9ubuk=?= <roger.pau@entel.upc.edu>
Message-ID: <CB1637D5.27A22%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH] ipxe: fix compilation issues with some gcc
	versions
Thread-Index: Acy/F5dFJsfGIkhgIkqYJQ35557riA==
In-Reply-To: <CAPLaKK5nUzJBgp5cqot__quEVNmgqUFbm8mRVbthA3XT0d6Zkg@mail.gmail.com>
Mime-version: 1.0
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] ipxe: fix compilation issues with some gcc
 versions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 20/12/2011 12:57, "Roger Pau Monn=E9" <roger.pau@entel.upc.edu> wrote:

> 2011/12/18 Keir Fraser <keir@xen.org>:
>> Done for 4.1. In 4.0 it looks like we have the generated code checked in=
, so
>> this fix is not necessary there.
> =

> Is there any preferred revision of ipxe that we should choose for
> unstable or just pick the latest one?

If it builds and smoke-tests, let's go with the latest. :-)

The main thing is for us to then stick with that revision for a while, so we
are testing a fixed version which we can use in our next release.

 -- Keir

> Roger.
> =

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 20 13:02:54 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 Dec 2011 13:02:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RczKv-0005BH-QJ; Tue, 20 Dec 2011 13:02:29 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RczKu-0005BA-8F
	for xen-devel@lists.xensource.com; Tue, 20 Dec 2011 13:02:28 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1324386140!6266273!1
X-Originating-IP: [209.85.212.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28089 invoked from network); 20 Dec 2011 13:02:21 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Dec 2011 13:02:21 -0000
Received: by wico1 with SMTP id o1so3592487wic.30
	for <xen-devel@lists.xensource.com>;
	Tue, 20 Dec 2011 05:02:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=t+TStS7PCKw+EXw9LJuv5p//DZou2rcc3J59GwCC2Q0=;
	b=cpgQlxKg2au8JOSNjEeQ/X0Q7x0D1T/Kx/NF7DxVAunzKXEBiruBSdkj1OwudElCxY
	NAGj8hJDj5q0c1YCm87Pg99cMA7Cff11KiH1FLTap167YcV66q633FfjJPz5eMOAU2Gd
	x1fX2P2Z4Sbofh5TpWGV2wAMGBV1YbaqSfJyM=
Received: by 10.181.13.17 with SMTP id eu17mr4547619wid.12.1324386140450;
	Tue, 20 Dec 2011 05:02:20 -0800 (PST)
Received: from [192.168.1.70] (host81-152-17-11.range81-152.btcentralplus.com.
	[81.152.17.11])
	by mx.google.com with ESMTPS id dd4sm4358261wib.1.2011.12.20.05.02.17
	(version=SSLv3 cipher=OTHER); Tue, 20 Dec 2011 05:02:19 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Tue, 20 Dec 2011 13:02:13 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Roger Pau =?ISO-8859-1?B?TW9ubuk=?= <roger.pau@entel.upc.edu>
Message-ID: <CB1637D5.27A22%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH] ipxe: fix compilation issues with some gcc
	versions
Thread-Index: Acy/F5dFJsfGIkhgIkqYJQ35557riA==
In-Reply-To: <CAPLaKK5nUzJBgp5cqot__quEVNmgqUFbm8mRVbthA3XT0d6Zkg@mail.gmail.com>
Mime-version: 1.0
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] ipxe: fix compilation issues with some gcc
 versions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 20/12/2011 12:57, "Roger Pau Monn=E9" <roger.pau@entel.upc.edu> wrote:

> 2011/12/18 Keir Fraser <keir@xen.org>:
>> Done for 4.1. In 4.0 it looks like we have the generated code checked in=
, so
>> this fix is not necessary there.
> =

> Is there any preferred revision of ipxe that we should choose for
> unstable or just pick the latest one?

If it builds and smoke-tests, let's go with the latest. :-)

The main thing is for us to then stick with that revision for a while, so we
are testing a fixed version which we can use in our next release.

 -- Keir

> Roger.
> =

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 20 13:16:50 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 Dec 2011 13:16:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RczY9-0005Oz-4Z; Tue, 20 Dec 2011 13:16:09 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RczY8-0005Ou-6f
	for xen-devel@lists.xensource.com; Tue, 20 Dec 2011 13:16:08 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-15.tower-182.messagelabs.com!1324386961!7936417!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzMjc2OTE=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzMjc2OTE=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21965 invoked from network); 20 Dec 2011 13:16:02 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-15.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 20 Dec 2011 13:16:02 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1324386961; l=1083;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=ShzTxRNFEw1nTl2RO36WpLS93/M=;
	b=y+U8vm5sJgm/DclYbTuP4vwKb2tsJW0M+jhEV/LLvB1Huf6gu9iO3pLNsZNJRl2UGpt
	Ke1wdz2fNAxebI71dMKLgchDl+zftc+w6m4uuKAjbZS3eyDBNoiiy5ORsOziRkgUWyjBS
	PBAYF3H20kWHfrdm0BAn+LQNmN6pRUo2Gck=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFPjjMQEgDpkQ==
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-100-109.pools.arcor-ip.net [88.65.100.109])
	by smtp.strato.de (jimi mo19) (RZmta 26.15 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id C04aa1nBKBoOzt ;
	Tue, 20 Dec 2011 14:15:34 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 050E818637; Tue, 20 Dec 2011 14:15:33 +0100 (CET)
Date: Tue, 20 Dec 2011 14:15:33 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20111220131533.GA7800@aepfle.de>
References: <4EEA4877.8010307@canonical.com>
	<20111215193942.GA7640@andromeda.dapyr.net>
	<20111216113300.GA4854@aepfle.de>
	<1324375910.23729.31.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1324375910.23729.31.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefan Bader <stefan.bader@canonical.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] xenbus and the message of doom
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Dec 20, Ian Campbell wrote:

> What's wrong with only doing this reset if we know we are kexec'd? If
> that can't be automatically detected then e.g. using an explicit
> reset_watches command line option. You could even make a tenuous
> argument for hanging this off reset_devices?

The kexec kernel does not know that it was loaded via kexec.
We could make the reset_devices option mandatory for kexec in PVonHVM
guests, so the change to drivers/xen/xenbus/xenbus_xs.c would be very
small, like "if (hvm && reset_devices) xs_reset_watches();"

> > Perhaps we should figure out what exactly EC2 is using as host and why
> > it only breaks with upstream kernels.
> 
> and in the meantime we leave upstream (and any distros which picks up a
> new enough kernel) on EC2? I think at this stage in the rc cycle we'd be
> better off reverting and trying again for 3.3.

If EC2 is unable to fix it in time (or provide info what exactly they
use), I'm ok with reverting/disabling the call to xs_reset_watches().
I can continue to work on this next year.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 20 13:16:50 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 Dec 2011 13:16:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RczY9-0005Oz-4Z; Tue, 20 Dec 2011 13:16:09 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RczY8-0005Ou-6f
	for xen-devel@lists.xensource.com; Tue, 20 Dec 2011 13:16:08 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-15.tower-182.messagelabs.com!1324386961!7936417!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzMjc2OTE=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzMjc2OTE=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21965 invoked from network); 20 Dec 2011 13:16:02 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-15.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 20 Dec 2011 13:16:02 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1324386961; l=1083;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=ShzTxRNFEw1nTl2RO36WpLS93/M=;
	b=y+U8vm5sJgm/DclYbTuP4vwKb2tsJW0M+jhEV/LLvB1Huf6gu9iO3pLNsZNJRl2UGpt
	Ke1wdz2fNAxebI71dMKLgchDl+zftc+w6m4uuKAjbZS3eyDBNoiiy5ORsOziRkgUWyjBS
	PBAYF3H20kWHfrdm0BAn+LQNmN6pRUo2Gck=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFPjjMQEgDpkQ==
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-100-109.pools.arcor-ip.net [88.65.100.109])
	by smtp.strato.de (jimi mo19) (RZmta 26.15 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id C04aa1nBKBoOzt ;
	Tue, 20 Dec 2011 14:15:34 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 050E818637; Tue, 20 Dec 2011 14:15:33 +0100 (CET)
Date: Tue, 20 Dec 2011 14:15:33 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20111220131533.GA7800@aepfle.de>
References: <4EEA4877.8010307@canonical.com>
	<20111215193942.GA7640@andromeda.dapyr.net>
	<20111216113300.GA4854@aepfle.de>
	<1324375910.23729.31.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1324375910.23729.31.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefan Bader <stefan.bader@canonical.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] xenbus and the message of doom
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Dec 20, Ian Campbell wrote:

> What's wrong with only doing this reset if we know we are kexec'd? If
> that can't be automatically detected then e.g. using an explicit
> reset_watches command line option. You could even make a tenuous
> argument for hanging this off reset_devices?

The kexec kernel does not know that it was loaded via kexec.
We could make the reset_devices option mandatory for kexec in PVonHVM
guests, so the change to drivers/xen/xenbus/xenbus_xs.c would be very
small, like "if (hvm && reset_devices) xs_reset_watches();"

> > Perhaps we should figure out what exactly EC2 is using as host and why
> > it only breaks with upstream kernels.
> 
> and in the meantime we leave upstream (and any distros which picks up a
> new enough kernel) on EC2? I think at this stage in the rc cycle we'd be
> better off reverting and trying again for 3.3.

If EC2 is unable to fix it in time (or provide info what exactly they
use), I'm ok with reverting/disabling the call to xs_reset_watches().
I can continue to work on this next year.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 20 13:49:03 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 Dec 2011 13:49:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rd03W-000659-MY; Tue, 20 Dec 2011 13:48:34 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1Rd03U-00064i-Vo
	for xen-devel@lists.xensource.com; Tue, 20 Dec 2011 13:48:33 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1324388906!8942239!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzQwMQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11091 invoked from network); 20 Dec 2011 13:48:26 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Dec 2011 13:48:26 -0000
X-IronPort-AV: E=Sophos;i="4.71,382,1320624000"; 
   d="scan'208";a="9580825"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Dec 2011 13:48:26 +0000
Received: from dhcp-3-28.uk.xensource.com (10.80.3.28) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 20 Dec 2011 13:48:26 +0000
Date: Tue, 20 Dec 2011 13:48:10 +0000
From: Anthony PERARD <anthony.perard@citrix.com>
X-X-Sender: anthony@perard.uk.xensource.com
To: Stefan Hajnoczi <stefanha@gmail.com>
In-Reply-To: <CAJSP0QW_PnPOssPKa0oGdk2CxLXqgsTsd1140+GoxLhWjAuk-A@mail.gmail.com>
Message-ID: <alpine.DEB.2.00.1112201324310.11530@perard.uk.xensource.com>
References: <tencent_28C0C6D7564BBF406BBBE46E@qq.com>
	<CAJSP0QW_PnPOssPKa0oGdk2CxLXqgsTsd1140+GoxLhWjAuk-A@mail.gmail.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323328-1334286411-1324388906=:11530"
Cc: Xen Devel <xen-devel@lists.xensource.com>,
	=?GB2312?Q?=A1=E8=BDK=EC=B6aware?= <250716708@qq.com>,
	qemu-devel <qemu-devel@nongnu.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel]
	=?gb2312?b?u9i4tKO6IFtRZW11LWRldmVsXSBkZWJ1Z2luZyBh?=
	=?gb2312?b?Ym91dCBxZW11LWRtIGluIHhlbiAzLjQuMg==?=
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--8323328-1334286411-1324388906=:11530
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8BIT

On Tue, 20 Dec 2011, Stefan Hajnoczi wrote:

> 2011/12/20 ¤終於aware <250716708@qq.com>:
> >     I want to create a memory snapshot file (such as mm.snap) of current
> > virtual machine and  the mm.snap can be used as a arg of qemu cmd-line for
> > restoring the last memory condition.
> >     But I am not very clear about the structure of the qemu-dm source code.
> > Although observing the output of execution is the straightforward way, high
> > frequency of printf  and re-compling is too incovenient to put into effect.
>
> Please keep qemu-devel@nongnu.org CCed so others can contribute to the
> discussion.
>
> QEMU only deals with virtual memory when simulating an MMU (for
> ARM-on-x86 system translation).  The device model usually operates on
> physical RAM or bus addresses.
>
> Stefano or Anthony can explain the qemu-dm specifics.  It's still not
> clear to me what you're trying to observe - qemu-dm is not where I'd
> try to observe domain memory under Xen but it's the right place to
> observe emulated devices.

Cced Xen-devel as well.

You can save a domain state using the tool stack (probably `xm save`
with Xen 3.4) and restore it as many time as you want.

To run gdb on qemu-dm, remplace the /usr/lib/xen/bin/qemu-dm by a
script:
#!/bin/sh
exec gdbserver 0.0.0.0:1234 /usr/lib/xen/bin/qemu-dm.bak $@

And run gdb. `target remote localhost 1234` to connect to gdbserver.

With the latest Xen (4.1 and unstable), you can specifie a different
device model in the config file instead of remplacing the default
binary.

Regards,

-- 
Anthony PERARD
--8323328-1334286411-1324388906=:11530
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--8323328-1334286411-1324388906=:11530--


From xen-devel-bounces@lists.xensource.com Tue Dec 20 13:49:03 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 Dec 2011 13:49:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rd03W-000659-MY; Tue, 20 Dec 2011 13:48:34 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1Rd03U-00064i-Vo
	for xen-devel@lists.xensource.com; Tue, 20 Dec 2011 13:48:33 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1324388906!8942239!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzQwMQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11091 invoked from network); 20 Dec 2011 13:48:26 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Dec 2011 13:48:26 -0000
X-IronPort-AV: E=Sophos;i="4.71,382,1320624000"; 
   d="scan'208";a="9580825"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Dec 2011 13:48:26 +0000
Received: from dhcp-3-28.uk.xensource.com (10.80.3.28) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 20 Dec 2011 13:48:26 +0000
Date: Tue, 20 Dec 2011 13:48:10 +0000
From: Anthony PERARD <anthony.perard@citrix.com>
X-X-Sender: anthony@perard.uk.xensource.com
To: Stefan Hajnoczi <stefanha@gmail.com>
In-Reply-To: <CAJSP0QW_PnPOssPKa0oGdk2CxLXqgsTsd1140+GoxLhWjAuk-A@mail.gmail.com>
Message-ID: <alpine.DEB.2.00.1112201324310.11530@perard.uk.xensource.com>
References: <tencent_28C0C6D7564BBF406BBBE46E@qq.com>
	<CAJSP0QW_PnPOssPKa0oGdk2CxLXqgsTsd1140+GoxLhWjAuk-A@mail.gmail.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323328-1334286411-1324388906=:11530"
Cc: Xen Devel <xen-devel@lists.xensource.com>,
	=?GB2312?Q?=A1=E8=BDK=EC=B6aware?= <250716708@qq.com>,
	qemu-devel <qemu-devel@nongnu.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel]
	=?gb2312?b?u9i4tKO6IFtRZW11LWRldmVsXSBkZWJ1Z2luZyBh?=
	=?gb2312?b?Ym91dCBxZW11LWRtIGluIHhlbiAzLjQuMg==?=
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--8323328-1334286411-1324388906=:11530
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8BIT

On Tue, 20 Dec 2011, Stefan Hajnoczi wrote:

> 2011/12/20 ¤終於aware <250716708@qq.com>:
> >     I want to create a memory snapshot file (such as mm.snap) of current
> > virtual machine and  the mm.snap can be used as a arg of qemu cmd-line for
> > restoring the last memory condition.
> >     But I am not very clear about the structure of the qemu-dm source code.
> > Although observing the output of execution is the straightforward way, high
> > frequency of printf  and re-compling is too incovenient to put into effect.
>
> Please keep qemu-devel@nongnu.org CCed so others can contribute to the
> discussion.
>
> QEMU only deals with virtual memory when simulating an MMU (for
> ARM-on-x86 system translation).  The device model usually operates on
> physical RAM or bus addresses.
>
> Stefano or Anthony can explain the qemu-dm specifics.  It's still not
> clear to me what you're trying to observe - qemu-dm is not where I'd
> try to observe domain memory under Xen but it's the right place to
> observe emulated devices.

Cced Xen-devel as well.

You can save a domain state using the tool stack (probably `xm save`
with Xen 3.4) and restore it as many time as you want.

To run gdb on qemu-dm, remplace the /usr/lib/xen/bin/qemu-dm by a
script:
#!/bin/sh
exec gdbserver 0.0.0.0:1234 /usr/lib/xen/bin/qemu-dm.bak $@

And run gdb. `target remote localhost 1234` to connect to gdbserver.

With the latest Xen (4.1 and unstable), you can specifie a different
device model in the config file instead of remplacing the default
binary.

Regards,

-- 
Anthony PERARD
--8323328-1334286411-1324388906=:11530
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--8323328-1334286411-1324388906=:11530--


From xen-devel-bounces@lists.xensource.com Tue Dec 20 14:17:03 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 Dec 2011 14: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.xensource.com>)
	id 1Rd0UZ-00071U-Vl; Tue, 20 Dec 2011 14:16:31 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.r.wilk@gmail.com>) id 1Rd0UY-00071O-EK
	for xen-devel@lists.xensource.com; Tue, 20 Dec 2011 14:16:30 +0000
X-Env-Sender: konrad.r.wilk@gmail.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1324390582!7473214!1
X-Originating-IP: [209.85.216.50]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14175 invoked from network); 20 Dec 2011 14:16:24 -0000
Received: from mail-qw0-f50.google.com (HELO mail-qw0-f50.google.com)
	(209.85.216.50)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Dec 2011 14:16:24 -0000
Received: by qaea17 with SMTP id a17so27101140qae.9
	for <xen-devel@lists.xensource.com>;
	Tue, 20 Dec 2011 06:16:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:date:from:to:cc:subject:message-id:references:mime-version
	:content-type:content-disposition:in-reply-to:user-agent;
	bh=cwdDHRevxOTtHsAUweC5TYHQfBuWJz0N9pp79J+bfpQ=;
	b=uBnfWpIVjWtXjdyO699yK8YpcGvNrhKAKvX77jVrNEohAapKTB6Timdp8XNDuH/9zh
	CEsbuzKGLLkzQ/oFPAR9gLNeRmb/0QBP+l3QjkkLkyo9xDos8c1ud2KEhdjwZncoAx3W
	ZKvmYBjDaIxUF9sG7TdjIgNPxDFWu+P/aqhsg=
Received: by 10.224.186.72 with SMTP id cr8mr2813848qab.95.1324390582499;
	Tue, 20 Dec 2011 06:16:22 -0800 (PST)
Received: from konrad-lan (209-6-85-33.c3-0.smr-ubr2.sbo-smr.ma.cable.rcn.com.
	[209.6.85.33])
	by mx.google.com with ESMTPS id eb5sm3825250qab.10.2011.12.20.06.16.21
	(version=TLSv1/SSLv3 cipher=OTHER);
	Tue, 20 Dec 2011 06:16:21 -0800 (PST)
Date: Tue, 20 Dec 2011 09:16:13 -0500
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Olaf Hering <olaf@aepfle.de>
Message-ID: <20111220141612.GA25139@konrad-lan>
References: <4EEA4877.8010307@canonical.com>
	<20111215193942.GA7640@andromeda.dapyr.net>
	<20111216113300.GA4854@aepfle.de>
	<1324375910.23729.31.camel@zakaz.uk.xensource.com>
	<20111220131533.GA7800@aepfle.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20111220131533.GA7800@aepfle.de>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefan Bader <stefan.bader@canonical.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] xenbus and the message of doom
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Dec 20, 2011 at 02:15:33PM +0100, Olaf Hering wrote:
> On Tue, Dec 20, Ian Campbell wrote:
> 
> > What's wrong with only doing this reset if we know we are kexec'd? If
> > that can't be automatically detected then e.g. using an explicit
> > reset_watches command line option. You could even make a tenuous
> > argument for hanging this off reset_devices?
> 
> The kexec kernel does not know that it was loaded via kexec.
> We could make the reset_devices option mandatory for kexec in PVonHVM
> guests, so the change to drivers/xen/xenbus/xenbus_xs.c would be very
> small, like "if (hvm && reset_devices) xs_reset_watches();"

<nods> OK that would be one way. Granted if one tried to kexec under
Amazon EC2 an PVonHVM domain we would hit this bug again. But then
I don't think kexecing without this patch works, so that scenario is
probably moot.

> 
> > > Perhaps we should figure out what exactly EC2 is using as host and why
> > > it only breaks with upstream kernels.
> > 
> > and in the meantime we leave upstream (and any distros which picks up a
> > new enough kernel) on EC2? I think at this stage in the rc cycle we'd be
> > better off reverting and trying again for 3.3.
> 
> If EC2 is unable to fix it in time (or provide info what exactly they
> use), I'm ok with reverting/disabling the call to xs_reset_watches().

By my reckoning the 3.2 is going to come out Dec 29th (60 days after 3.1
was released) or it might slip. With folks buying presents online (and
potentially using Amazon) they [Amazon] is not going to fix anything -
they are in "must work now to sell stuff mode" - which means fix only
those $1M bugs. With the craze of purchases stopping around January I
think they could start addressing this sometime in Janurary - which would
be past the 3.2 release date.

Sorry Olaf, have to revert that commit.

> I can continue to work on this next year.

Ok. I need to serioulsy get a free Amazon EC2 instance to run nightly tests.
This is the third breakage this year.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 20 14:17:03 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 Dec 2011 14: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.xensource.com>)
	id 1Rd0UZ-00071U-Vl; Tue, 20 Dec 2011 14:16:31 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.r.wilk@gmail.com>) id 1Rd0UY-00071O-EK
	for xen-devel@lists.xensource.com; Tue, 20 Dec 2011 14:16:30 +0000
X-Env-Sender: konrad.r.wilk@gmail.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1324390582!7473214!1
X-Originating-IP: [209.85.216.50]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14175 invoked from network); 20 Dec 2011 14:16:24 -0000
Received: from mail-qw0-f50.google.com (HELO mail-qw0-f50.google.com)
	(209.85.216.50)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Dec 2011 14:16:24 -0000
Received: by qaea17 with SMTP id a17so27101140qae.9
	for <xen-devel@lists.xensource.com>;
	Tue, 20 Dec 2011 06:16:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:date:from:to:cc:subject:message-id:references:mime-version
	:content-type:content-disposition:in-reply-to:user-agent;
	bh=cwdDHRevxOTtHsAUweC5TYHQfBuWJz0N9pp79J+bfpQ=;
	b=uBnfWpIVjWtXjdyO699yK8YpcGvNrhKAKvX77jVrNEohAapKTB6Timdp8XNDuH/9zh
	CEsbuzKGLLkzQ/oFPAR9gLNeRmb/0QBP+l3QjkkLkyo9xDos8c1ud2KEhdjwZncoAx3W
	ZKvmYBjDaIxUF9sG7TdjIgNPxDFWu+P/aqhsg=
Received: by 10.224.186.72 with SMTP id cr8mr2813848qab.95.1324390582499;
	Tue, 20 Dec 2011 06:16:22 -0800 (PST)
Received: from konrad-lan (209-6-85-33.c3-0.smr-ubr2.sbo-smr.ma.cable.rcn.com.
	[209.6.85.33])
	by mx.google.com with ESMTPS id eb5sm3825250qab.10.2011.12.20.06.16.21
	(version=TLSv1/SSLv3 cipher=OTHER);
	Tue, 20 Dec 2011 06:16:21 -0800 (PST)
Date: Tue, 20 Dec 2011 09:16:13 -0500
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Olaf Hering <olaf@aepfle.de>
Message-ID: <20111220141612.GA25139@konrad-lan>
References: <4EEA4877.8010307@canonical.com>
	<20111215193942.GA7640@andromeda.dapyr.net>
	<20111216113300.GA4854@aepfle.de>
	<1324375910.23729.31.camel@zakaz.uk.xensource.com>
	<20111220131533.GA7800@aepfle.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20111220131533.GA7800@aepfle.de>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefan Bader <stefan.bader@canonical.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] xenbus and the message of doom
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Dec 20, 2011 at 02:15:33PM +0100, Olaf Hering wrote:
> On Tue, Dec 20, Ian Campbell wrote:
> 
> > What's wrong with only doing this reset if we know we are kexec'd? If
> > that can't be automatically detected then e.g. using an explicit
> > reset_watches command line option. You could even make a tenuous
> > argument for hanging this off reset_devices?
> 
> The kexec kernel does not know that it was loaded via kexec.
> We could make the reset_devices option mandatory for kexec in PVonHVM
> guests, so the change to drivers/xen/xenbus/xenbus_xs.c would be very
> small, like "if (hvm && reset_devices) xs_reset_watches();"

<nods> OK that would be one way. Granted if one tried to kexec under
Amazon EC2 an PVonHVM domain we would hit this bug again. But then
I don't think kexecing without this patch works, so that scenario is
probably moot.

> 
> > > Perhaps we should figure out what exactly EC2 is using as host and why
> > > it only breaks with upstream kernels.
> > 
> > and in the meantime we leave upstream (and any distros which picks up a
> > new enough kernel) on EC2? I think at this stage in the rc cycle we'd be
> > better off reverting and trying again for 3.3.
> 
> If EC2 is unable to fix it in time (or provide info what exactly they
> use), I'm ok with reverting/disabling the call to xs_reset_watches().

By my reckoning the 3.2 is going to come out Dec 29th (60 days after 3.1
was released) or it might slip. With folks buying presents online (and
potentially using Amazon) they [Amazon] is not going to fix anything -
they are in "must work now to sell stuff mode" - which means fix only
those $1M bugs. With the craze of purchases stopping around January I
think they could start addressing this sometime in Janurary - which would
be past the 3.2 release date.

Sorry Olaf, have to revert that commit.

> I can continue to work on this next year.

Ok. I need to serioulsy get a free Amazon EC2 instance to run nightly tests.
This is the third breakage this year.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 20 14:27:28 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 Dec 2011 14:27:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rd0eV-0007GT-3b; Tue, 20 Dec 2011 14:26:47 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.r.wilk@gmail.com>) id 1Rd0eT-0007GO-8E
	for xen-devel@lists.xensource.com; Tue, 20 Dec 2011 14:26:45 +0000
X-Env-Sender: konrad.r.wilk@gmail.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1324391197!8158159!1
X-Originating-IP: [209.85.216.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22846 invoked from network); 20 Dec 2011 14:26:38 -0000
Received: from mail-qy0-f171.google.com (HELO mail-qy0-f171.google.com)
	(209.85.216.171)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Dec 2011 14:26:38 -0000
Received: by qcsc20 with SMTP id c20so49227549qcs.30
	for <xen-devel@lists.xensource.com>;
	Tue, 20 Dec 2011 06:26:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:date:from:to:subject:message-id:references:mime-version
	:content-type:content-disposition:in-reply-to:user-agent;
	bh=W8bOhj8NF3JYbC3hU9gM0Yy0CNc6ImNosijSIb1/3I0=;
	b=iOLdSL+EAUrY7CN9A0ABrfN0UKAvj8uLUUv8vjc1wUCXaE6ZnVUSFXCNRvkgNhJUpb
	XwF50/MqwJv2ZYfMMZl6+h+KX/lgghoqyk+e/4BlwJ1spVhfstDVHTdvcqepirz95Ba+
	nTszz1HlLBvyStRbdtv1xn9vYF2exWu7qzBno=
Received: by 10.224.10.19 with SMTP id n19mr2914091qan.68.1324391196937;
	Tue, 20 Dec 2011 06:26:36 -0800 (PST)
Received: from konrad-lan (209-6-85-33.c3-0.smr-ubr2.sbo-smr.ma.cable.rcn.com.
	[209.6.85.33])
	by mx.google.com with ESMTPS id hv20sm3826982qab.22.2011.12.20.06.26.36
	(version=TLSv1/SSLv3 cipher=OTHER);
	Tue, 20 Dec 2011 06:26:36 -0800 (PST)
Date: Tue, 20 Dec 2011 09:26:33 -0500
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Jan Vejvalka <jan.vejvalka@lfmotol.cuni.cz>, xen-devel@lists.xensource.com
Message-ID: <20111220142633.GC25139@konrad-lan>
References: <4EE8E725.30208@lfmotol.cuni.cz>
	<20111216153211.GA5120@andromeda.dapyr.net>
	<4EF020A3.8050801@lfmotol.cuni.cz>
	<20111220142521.GB25139@konrad-lan>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20111220142521.GB25139@konrad-lan>
User-Agent: Mutt/1.5.20 (2009-06-14)
Subject: Re: [Xen-devel] Failure to start X windows in Dom0 under Xen 4.1.2
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Dec 20, 2011 at 09:25:21AM -0500, Konrad Rzeszutek Wilk wrote:
> On Tue, Dec 20, 2011 at 06:44:03AM +0100, Jan Vejvalka wrote:
> > Dear Konrad,
> > 
> >   thank you for your interest.
> 
> Please don't top post.

And do not remove the xen-devel from the CC. I put it back in this
email.

> > 
> > In the meantime, I found a post that helped at least partially:
> > http://forums.gentoo.org/viewtopic-t-901234-start-0.html .
> > 
> > I added the nopat option to grub, and things got a bit better.
> > I moved one step further, now facing a somewhat different problem:
> > 
> > - on my 3.1.1 kernel without Xen, things work fine
> 
> Can you provide the dmesg of that please.
> 
> I am curious to see why you have:
> 
> [    2.967316] [drm] VGACON disable radeon kernel modesetting.
> 
> Can you also boot the baremetal (so without Xen) and with Xen
> with: "drm.debug=255" and remove the "nomodeset" option on the Linux
> command line?
> 
> Uou are also missing the "debug loglevel=8" options. I need those to
> get a better idea of why the radeon driver is not initializing properly.
> 
> > - on the same kernel with Xen, the first (and sometimes even some
> >     further) attempts to run startx fail
> > - after a couple of tries, startx finally succeeds if the kernel
> >     is loaded with the nopat parameter
> > - without the nopat parameter, it seems it does not work: in the best
> >     attempts, the screen enters the graphic mode for a short while
> >     before the final crash.
> > 
> > The info you asked for is at
> > http://camelot.lf2.cuni.cz/vejvalka/temp/kon .
> > 
> > Thanks for help
> > Dziekuje bardzo
> 
> Oczywiscie.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 20 14:27:28 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 Dec 2011 14:27:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rd0eV-0007GT-3b; Tue, 20 Dec 2011 14:26:47 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.r.wilk@gmail.com>) id 1Rd0eT-0007GO-8E
	for xen-devel@lists.xensource.com; Tue, 20 Dec 2011 14:26:45 +0000
X-Env-Sender: konrad.r.wilk@gmail.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1324391197!8158159!1
X-Originating-IP: [209.85.216.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22846 invoked from network); 20 Dec 2011 14:26:38 -0000
Received: from mail-qy0-f171.google.com (HELO mail-qy0-f171.google.com)
	(209.85.216.171)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Dec 2011 14:26:38 -0000
Received: by qcsc20 with SMTP id c20so49227549qcs.30
	for <xen-devel@lists.xensource.com>;
	Tue, 20 Dec 2011 06:26:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:date:from:to:subject:message-id:references:mime-version
	:content-type:content-disposition:in-reply-to:user-agent;
	bh=W8bOhj8NF3JYbC3hU9gM0Yy0CNc6ImNosijSIb1/3I0=;
	b=iOLdSL+EAUrY7CN9A0ABrfN0UKAvj8uLUUv8vjc1wUCXaE6ZnVUSFXCNRvkgNhJUpb
	XwF50/MqwJv2ZYfMMZl6+h+KX/lgghoqyk+e/4BlwJ1spVhfstDVHTdvcqepirz95Ba+
	nTszz1HlLBvyStRbdtv1xn9vYF2exWu7qzBno=
Received: by 10.224.10.19 with SMTP id n19mr2914091qan.68.1324391196937;
	Tue, 20 Dec 2011 06:26:36 -0800 (PST)
Received: from konrad-lan (209-6-85-33.c3-0.smr-ubr2.sbo-smr.ma.cable.rcn.com.
	[209.6.85.33])
	by mx.google.com with ESMTPS id hv20sm3826982qab.22.2011.12.20.06.26.36
	(version=TLSv1/SSLv3 cipher=OTHER);
	Tue, 20 Dec 2011 06:26:36 -0800 (PST)
Date: Tue, 20 Dec 2011 09:26:33 -0500
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Jan Vejvalka <jan.vejvalka@lfmotol.cuni.cz>, xen-devel@lists.xensource.com
Message-ID: <20111220142633.GC25139@konrad-lan>
References: <4EE8E725.30208@lfmotol.cuni.cz>
	<20111216153211.GA5120@andromeda.dapyr.net>
	<4EF020A3.8050801@lfmotol.cuni.cz>
	<20111220142521.GB25139@konrad-lan>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20111220142521.GB25139@konrad-lan>
User-Agent: Mutt/1.5.20 (2009-06-14)
Subject: Re: [Xen-devel] Failure to start X windows in Dom0 under Xen 4.1.2
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Dec 20, 2011 at 09:25:21AM -0500, Konrad Rzeszutek Wilk wrote:
> On Tue, Dec 20, 2011 at 06:44:03AM +0100, Jan Vejvalka wrote:
> > Dear Konrad,
> > 
> >   thank you for your interest.
> 
> Please don't top post.

And do not remove the xen-devel from the CC. I put it back in this
email.

> > 
> > In the meantime, I found a post that helped at least partially:
> > http://forums.gentoo.org/viewtopic-t-901234-start-0.html .
> > 
> > I added the nopat option to grub, and things got a bit better.
> > I moved one step further, now facing a somewhat different problem:
> > 
> > - on my 3.1.1 kernel without Xen, things work fine
> 
> Can you provide the dmesg of that please.
> 
> I am curious to see why you have:
> 
> [    2.967316] [drm] VGACON disable radeon kernel modesetting.
> 
> Can you also boot the baremetal (so without Xen) and with Xen
> with: "drm.debug=255" and remove the "nomodeset" option on the Linux
> command line?
> 
> Uou are also missing the "debug loglevel=8" options. I need those to
> get a better idea of why the radeon driver is not initializing properly.
> 
> > - on the same kernel with Xen, the first (and sometimes even some
> >     further) attempts to run startx fail
> > - after a couple of tries, startx finally succeeds if the kernel
> >     is loaded with the nopat parameter
> > - without the nopat parameter, it seems it does not work: in the best
> >     attempts, the screen enters the graphic mode for a short while
> >     before the final crash.
> > 
> > The info you asked for is at
> > http://camelot.lf2.cuni.cz/vejvalka/temp/kon .
> > 
> > Thanks for help
> > Dziekuje bardzo
> 
> Oczywiscie.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 20 15:33:01 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 Dec 2011 15:33:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rd1fo-0008LU-Pu; Tue, 20 Dec 2011 15:32:12 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1Rd1fm-0008LH-Rf
	for xen-devel@lists.xensource.com; Tue, 20 Dec 2011 15:32:11 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-13.tower-27.messagelabs.com!1324395100!52937990!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19533 invoked from network); 20 Dec 2011 15:31:42 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-13.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 20 Dec 2011 15:31:42 -0000
Received: from andromeda.dapyr.net (darnok@localhost [127.0.0.1])
	by andromeda.dapyr.net (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id
	pBKFVm7a014146
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Tue, 20 Dec 2011 10:31:48 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pBKFVj5d014144;
	Tue, 20 Dec 2011 10:31:45 -0500
Date: Tue, 20 Dec 2011 11:31:45 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: "Tian, Kevin" <kevin.tian@intel.com>
Message-ID: <20111220153145.GB13253@andromeda.dapyr.net>
References: <1322673664-14642-1-git-send-email-konrad.wilk@oracle.com>
	<1322673664-14642-4-git-send-email-konrad.wilk@oracle.com>
	<20111216220342.GC9832@phenom.dumpdata.com>
	<625BA99ED14B2D499DC4E29D8138F1506E01AABC7A@shsmsx502.ccr.corp.intel.com>
	<20111219142626.GB27772@andromeda.dapyr.net>
	<625BA99ED14B2D499DC4E29D8138F1506E01AAC03A@shsmsx502.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <625BA99ED14B2D499DC4E29D8138F1506E01AAC03A@shsmsx502.ccr.corp.intel.com>
User-Agent: Mutt/1.5.9i
Cc: "jeremy@goop.org" <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"mike.mcclurg@citrix.com" <mike.mcclurg@citrix.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"stefan.bader@canonical.com" <stefan.bader@canonical.com>,
	"rjw@sisk.pl" <rjw@sisk.pl>,
	"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
	"liang.tang@oracle.com" <liang.tang@oracle.com>, "Yu,
	Ke" <ke.yu@intel.com>, "konrad@kernel.org" <konrad@kernel.org>,
	"lenb@kernel.org" <lenb@kernel.org>
Subject: Re: [Xen-devel] [PATCH 3/8] ACPI: processor: add
	__acpi_processor_[un]register_driver helpers.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Dec 20, 2011 at 10:29:12AM +0800, Tian, Kevin wrote:
> > From: Konrad Rzeszutek Wilk [mailto:konrad@darnok.org]
> > Sent: Monday, December 19, 2011 10:26 PM
> > 
> > On Mon, Dec 19, 2011 at 01:48:01PM +0800, Tian, Kevin wrote:
> > > > From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@oracle.com]
> > > > Sent: Saturday, December 17, 2011 6:04 AM
> > > >
> > > > On Wed, Nov 30, 2011 at 12:20:59PM -0500, Konrad Rzeszutek Wilk wrote:
> > > > > From: Tang Liang <liang.tang@oracle.com>
> > > > >
> > > > > This patch implement __acpi_processor_[un]register_driver helper,
> > > > > so we can registry override processor driver function. Specifically
> > > > > the Xen processor driver.
> > > >
> > > > Liang,
> > > >
> > > > Is the reason we are doing this b/c we need to call acpi_bus_register_driver
> > > > and inhibit the registration of 'acpi_processor_driver' ?
> > > >
> > > > And the reason we don't want 'acpi_processor_driver' to run is b/c of what?
> > > > If the cpuidle is disabled what is the harm of running the
> > > > 'acpi_processor_driver'
> > > > driver?
> > >
> > > IIRC, the reason why we want a Xen specific driver is because current driver
> > > is integrated with OS logic too tightly, e.g. the various checks on VCPU related
> > > structures. Long time ago the 1st version in Xen was to use same driver, by
> > > adding various tweaking lines inside which makes it completely messed. Then
> > > later it's found that it's clearer to create a Xen specific wrapping driver, by
> > > invoking some exported functions from existing one.
> > 
> > What I am asking is does it matter "if the current driver is integrated
> > with OS logic to tighly" - as it is not running anyhow (b/c cpuidle is
> > disabled).
> > 
> > And if Xen specific driver can run along-side the generic one - since
> > the generic one is not doing any work (b/c cpuidle is disabled).
> > 
> > That is what I am trying to figure out - since this patch purpose is to
> > thwart the generic driver from running and allowing the xen one to run.
> 
> It's a separate issue from cpuidle case. Here we're talking about acpi processor
> driver, not the acpi cpuidle driver. ACPI processor driver is responsible for 
> discovering ACPI processor projects, and then enumerate various methods 
> such as _PPC, _CST, etc. under those objects. So far this driver depends on 
> VCPU presence in various places, which causes trouble when dom0 is configured
> with less VCPU number than physical present one.
> 
> One example you can see from acpi_processor_add:
> 
>         result = acpi_processor_get_info(device); // call acpi_get_cpuid
>         if (result) {
>                 /* Processor is physically not present */
>                 return 0;
>         }
> 
> #ifdef CONFIG_SMP
>         if (pr->id >= setup_max_cpus && pr->id != 0)
>                 return 0;
> #endif 
> 
>         BUG_ON((pr->id >= nr_cpu_ids) || (pr->id < 0));
> 
> The binding between ACPI processor objects and VCPU presence would only parse
> partial objects to Xen. And there're various places within driver validating pr->id
> making it messy to workaround for Xen within same driver.
> 
> That's the major reason for coming up a Xen specific driver, which always parses
> all present objects regardless of VCPU presence. :-)

OK. Lets put the # VCPU != PCPU aside. Say dom0 will boot with all
CPUs and then later on the admin starts unplugging them.

With that in mind, could we use a slim driver (like the one in: "ACPI:
 add processor driver for Xen virtual CPUs.") that would just
take the _Pxx, Cxx data and shove them to the hypervisor (handwaving
aside the checking for quirks and such). And lets assume that we use the
unmodified acpi_processor_[add|remove|notify] code that is present in
processor_driver.c.

Oh, and the processor-driver.c did try to load (with the understanding
that it would load, but won't do much since cpuidle is turned off).

Would that still get the Pxx, Cxx data to the hypervisor?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 20 15:33:01 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 Dec 2011 15:33:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rd1fo-0008LU-Pu; Tue, 20 Dec 2011 15:32:12 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1Rd1fm-0008LH-Rf
	for xen-devel@lists.xensource.com; Tue, 20 Dec 2011 15:32:11 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-13.tower-27.messagelabs.com!1324395100!52937990!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19533 invoked from network); 20 Dec 2011 15:31:42 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-13.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 20 Dec 2011 15:31:42 -0000
Received: from andromeda.dapyr.net (darnok@localhost [127.0.0.1])
	by andromeda.dapyr.net (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id
	pBKFVm7a014146
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Tue, 20 Dec 2011 10:31:48 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pBKFVj5d014144;
	Tue, 20 Dec 2011 10:31:45 -0500
Date: Tue, 20 Dec 2011 11:31:45 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: "Tian, Kevin" <kevin.tian@intel.com>
Message-ID: <20111220153145.GB13253@andromeda.dapyr.net>
References: <1322673664-14642-1-git-send-email-konrad.wilk@oracle.com>
	<1322673664-14642-4-git-send-email-konrad.wilk@oracle.com>
	<20111216220342.GC9832@phenom.dumpdata.com>
	<625BA99ED14B2D499DC4E29D8138F1506E01AABC7A@shsmsx502.ccr.corp.intel.com>
	<20111219142626.GB27772@andromeda.dapyr.net>
	<625BA99ED14B2D499DC4E29D8138F1506E01AAC03A@shsmsx502.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <625BA99ED14B2D499DC4E29D8138F1506E01AAC03A@shsmsx502.ccr.corp.intel.com>
User-Agent: Mutt/1.5.9i
Cc: "jeremy@goop.org" <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"mike.mcclurg@citrix.com" <mike.mcclurg@citrix.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"stefan.bader@canonical.com" <stefan.bader@canonical.com>,
	"rjw@sisk.pl" <rjw@sisk.pl>,
	"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
	"liang.tang@oracle.com" <liang.tang@oracle.com>, "Yu,
	Ke" <ke.yu@intel.com>, "konrad@kernel.org" <konrad@kernel.org>,
	"lenb@kernel.org" <lenb@kernel.org>
Subject: Re: [Xen-devel] [PATCH 3/8] ACPI: processor: add
	__acpi_processor_[un]register_driver helpers.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Dec 20, 2011 at 10:29:12AM +0800, Tian, Kevin wrote:
> > From: Konrad Rzeszutek Wilk [mailto:konrad@darnok.org]
> > Sent: Monday, December 19, 2011 10:26 PM
> > 
> > On Mon, Dec 19, 2011 at 01:48:01PM +0800, Tian, Kevin wrote:
> > > > From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@oracle.com]
> > > > Sent: Saturday, December 17, 2011 6:04 AM
> > > >
> > > > On Wed, Nov 30, 2011 at 12:20:59PM -0500, Konrad Rzeszutek Wilk wrote:
> > > > > From: Tang Liang <liang.tang@oracle.com>
> > > > >
> > > > > This patch implement __acpi_processor_[un]register_driver helper,
> > > > > so we can registry override processor driver function. Specifically
> > > > > the Xen processor driver.
> > > >
> > > > Liang,
> > > >
> > > > Is the reason we are doing this b/c we need to call acpi_bus_register_driver
> > > > and inhibit the registration of 'acpi_processor_driver' ?
> > > >
> > > > And the reason we don't want 'acpi_processor_driver' to run is b/c of what?
> > > > If the cpuidle is disabled what is the harm of running the
> > > > 'acpi_processor_driver'
> > > > driver?
> > >
> > > IIRC, the reason why we want a Xen specific driver is because current driver
> > > is integrated with OS logic too tightly, e.g. the various checks on VCPU related
> > > structures. Long time ago the 1st version in Xen was to use same driver, by
> > > adding various tweaking lines inside which makes it completely messed. Then
> > > later it's found that it's clearer to create a Xen specific wrapping driver, by
> > > invoking some exported functions from existing one.
> > 
> > What I am asking is does it matter "if the current driver is integrated
> > with OS logic to tighly" - as it is not running anyhow (b/c cpuidle is
> > disabled).
> > 
> > And if Xen specific driver can run along-side the generic one - since
> > the generic one is not doing any work (b/c cpuidle is disabled).
> > 
> > That is what I am trying to figure out - since this patch purpose is to
> > thwart the generic driver from running and allowing the xen one to run.
> 
> It's a separate issue from cpuidle case. Here we're talking about acpi processor
> driver, not the acpi cpuidle driver. ACPI processor driver is responsible for 
> discovering ACPI processor projects, and then enumerate various methods 
> such as _PPC, _CST, etc. under those objects. So far this driver depends on 
> VCPU presence in various places, which causes trouble when dom0 is configured
> with less VCPU number than physical present one.
> 
> One example you can see from acpi_processor_add:
> 
>         result = acpi_processor_get_info(device); // call acpi_get_cpuid
>         if (result) {
>                 /* Processor is physically not present */
>                 return 0;
>         }
> 
> #ifdef CONFIG_SMP
>         if (pr->id >= setup_max_cpus && pr->id != 0)
>                 return 0;
> #endif 
> 
>         BUG_ON((pr->id >= nr_cpu_ids) || (pr->id < 0));
> 
> The binding between ACPI processor objects and VCPU presence would only parse
> partial objects to Xen. And there're various places within driver validating pr->id
> making it messy to workaround for Xen within same driver.
> 
> That's the major reason for coming up a Xen specific driver, which always parses
> all present objects regardless of VCPU presence. :-)

OK. Lets put the # VCPU != PCPU aside. Say dom0 will boot with all
CPUs and then later on the admin starts unplugging them.

With that in mind, could we use a slim driver (like the one in: "ACPI:
 add processor driver for Xen virtual CPUs.") that would just
take the _Pxx, Cxx data and shove them to the hypervisor (handwaving
aside the checking for quirks and such). And lets assume that we use the
unmodified acpi_processor_[add|remove|notify] code that is present in
processor_driver.c.

Oh, and the processor-driver.c did try to load (with the understanding
that it would load, but won't do much since cpuidle is turned off).

Would that still get the Pxx, Cxx data to the hypervisor?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 20 15:36:53 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 Dec 2011 15:36:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rd1ju-00005j-Fu; Tue, 20 Dec 2011 15:36:26 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1Rd1jt-00005b-3W
	for xen-devel@lists.xensource.com; Tue, 20 Dec 2011 15:36:25 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-7.tower-27.messagelabs.com!1324395327!61505428!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=1.4 required=7.0 tests=INFO_TLD
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13105 invoked from network); 20 Dec 2011 15:35:28 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-7.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 20 Dec 2011 15:35:28 -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
	pBKFZ1GC014319
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Tue, 20 Dec 2011 10:35:01 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pBKFZ18V014317;
	Tue, 20 Dec 2011 10:35:01 -0500
Date: Tue, 20 Dec 2011 11:35:01 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Michal Suchanek <hramrach@centrum.cz>, stefan.bader@canonical.com
Message-ID: <20111220153501.GC13253@andromeda.dapyr.net>
References: <CAOMqctShNFqe47w1orEPMCqvDORy5yxh=Gy33e02fyQYrz4nkw@mail.gmail.com>
	<20111219142943.GD27772@andromeda.dapyr.net>
	<CAOMqctSW87AmM8UTC34_ZwDhipnZUMmxyxiBix+EMAmi7hn1hg@mail.gmail.com>
	<20111219194324.GA29852@andromeda.dapyr.net>
	<1324373842.23729.16.camel@zakaz.uk.xensource.com>
	<CAEBdQ92Oy6=EYYFG_KNMP6raq7S1e_195hFth1etMgpQWdGtsg@mail.gmail.com>
	<1324374914.23729.22.camel@zakaz.uk.xensource.com>
	<CAOMqctTOC_te2QRqFUC45+cq1qCBcQyMdvQcu4Brpw-kAiYnBg@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAOMqctTOC_te2QRqFUC45+cq1qCBcQyMdvQcu4Brpw-kAiYnBg@mail.gmail.com>
User-Agent: Mutt/1.5.9i
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Jean Guyader <jean.guyader@gmail.com>
Subject: Re: [Xen-devel] UDP checksums broken in Dom0 -> DomU vif transfer
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Dec 20, 2011 at 12:57:48PM +0100, Michal Suchanek wrote:
> On 20 December 2011 10:55, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > On Tue, 2011-12-20 at 09:43 +0000, Jean Guyader wrote:
> >> On 20 December 2011 10:37, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> >> > The issue is that dom0 does checksum offload which means the checksum is
> >> > not valid on the domU end, although we know the packet is intact because
> >> > it never hit the wire.
> >> >
> >> > The network stack deals with this because skb->ip_summed is set
> >> > appropriately but when e.g. raw sockets are used it can ends up exposing
> >> > getting exposed to userspace.
> >> >
> >> > We don't want to do the checksum by default since there are performance
> >> > gains from avoiding it in the general case. Note that "tx off" turns of
> >> > TCP and UDP checksum offload.
> >> >
> >> > It's not clear where the bug is here, it could be a bug in dhclinet for
> >> > dropping the packet or perhaps this is something that raw socket driver
> >> > should be correcting (based on ip_summed) as the packet passes through
> >> > to userspace?
> >> >
> >> > I'm not sure but this might impact native hardware too -- depends on the
> >> > H/W's handling of the checksum field on RX, you'd hope they mostly just
> >> > leave it alone, but I'm not sure how e.g. LRO/GRO effects things?
> >> >
> >>
> >> I've seen this issue in the past. I belive the bug is in dhclient.
> >> dhclient checks the checksum on the packets and drop them if it's wrong.
> >
> > Indeed, googling around a bit shows that this dhclient bug affects more
> > than just Xen, e.g. virtio and even some native hardware appear to be
> > effected.
> >
> > http://marc.info/?l=kvm&m=121882968407525&w=2
> > https://qa.mandriva.com/show_bug.cgi?id=63320
> > https://bugs.mageia.org/show_bug.cgi?id=1243
> > http://pkgs.fedoraproject.org/gitweb/?p=dhcp.git;a=blob_plain;f=dhcp-4.2.2-xen-checksum.patch;hb=HEAD
> >
> > The OP didn't say what distro or version of dhclient he was using but I
> > think the right place to report this would be to the distro since it
> > appears to be using an out of date dhclient. In the meantime disabling
> > offload seems like a reasonable local workaround but it is not a fix we
> > should apply by default.
> 
> Thanks for the links
> 
> I am running Ubuntu in the DomU.

Stefan, is this something you could help us with?

Ian, would it make sense to add all this awesome details in the Xen FAQ
Wiki part?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 20 15:36:53 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 Dec 2011 15:36:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rd1ju-00005j-Fu; Tue, 20 Dec 2011 15:36:26 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1Rd1jt-00005b-3W
	for xen-devel@lists.xensource.com; Tue, 20 Dec 2011 15:36:25 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-7.tower-27.messagelabs.com!1324395327!61505428!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=1.4 required=7.0 tests=INFO_TLD
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13105 invoked from network); 20 Dec 2011 15:35:28 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-7.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 20 Dec 2011 15:35:28 -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
	pBKFZ1GC014319
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Tue, 20 Dec 2011 10:35:01 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pBKFZ18V014317;
	Tue, 20 Dec 2011 10:35:01 -0500
Date: Tue, 20 Dec 2011 11:35:01 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Michal Suchanek <hramrach@centrum.cz>, stefan.bader@canonical.com
Message-ID: <20111220153501.GC13253@andromeda.dapyr.net>
References: <CAOMqctShNFqe47w1orEPMCqvDORy5yxh=Gy33e02fyQYrz4nkw@mail.gmail.com>
	<20111219142943.GD27772@andromeda.dapyr.net>
	<CAOMqctSW87AmM8UTC34_ZwDhipnZUMmxyxiBix+EMAmi7hn1hg@mail.gmail.com>
	<20111219194324.GA29852@andromeda.dapyr.net>
	<1324373842.23729.16.camel@zakaz.uk.xensource.com>
	<CAEBdQ92Oy6=EYYFG_KNMP6raq7S1e_195hFth1etMgpQWdGtsg@mail.gmail.com>
	<1324374914.23729.22.camel@zakaz.uk.xensource.com>
	<CAOMqctTOC_te2QRqFUC45+cq1qCBcQyMdvQcu4Brpw-kAiYnBg@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAOMqctTOC_te2QRqFUC45+cq1qCBcQyMdvQcu4Brpw-kAiYnBg@mail.gmail.com>
User-Agent: Mutt/1.5.9i
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Jean Guyader <jean.guyader@gmail.com>
Subject: Re: [Xen-devel] UDP checksums broken in Dom0 -> DomU vif transfer
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Dec 20, 2011 at 12:57:48PM +0100, Michal Suchanek wrote:
> On 20 December 2011 10:55, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > On Tue, 2011-12-20 at 09:43 +0000, Jean Guyader wrote:
> >> On 20 December 2011 10:37, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> >> > The issue is that dom0 does checksum offload which means the checksum is
> >> > not valid on the domU end, although we know the packet is intact because
> >> > it never hit the wire.
> >> >
> >> > The network stack deals with this because skb->ip_summed is set
> >> > appropriately but when e.g. raw sockets are used it can ends up exposing
> >> > getting exposed to userspace.
> >> >
> >> > We don't want to do the checksum by default since there are performance
> >> > gains from avoiding it in the general case. Note that "tx off" turns of
> >> > TCP and UDP checksum offload.
> >> >
> >> > It's not clear where the bug is here, it could be a bug in dhclinet for
> >> > dropping the packet or perhaps this is something that raw socket driver
> >> > should be correcting (based on ip_summed) as the packet passes through
> >> > to userspace?
> >> >
> >> > I'm not sure but this might impact native hardware too -- depends on the
> >> > H/W's handling of the checksum field on RX, you'd hope they mostly just
> >> > leave it alone, but I'm not sure how e.g. LRO/GRO effects things?
> >> >
> >>
> >> I've seen this issue in the past. I belive the bug is in dhclient.
> >> dhclient checks the checksum on the packets and drop them if it's wrong.
> >
> > Indeed, googling around a bit shows that this dhclient bug affects more
> > than just Xen, e.g. virtio and even some native hardware appear to be
> > effected.
> >
> > http://marc.info/?l=kvm&m=121882968407525&w=2
> > https://qa.mandriva.com/show_bug.cgi?id=63320
> > https://bugs.mageia.org/show_bug.cgi?id=1243
> > http://pkgs.fedoraproject.org/gitweb/?p=dhcp.git;a=blob_plain;f=dhcp-4.2.2-xen-checksum.patch;hb=HEAD
> >
> > The OP didn't say what distro or version of dhclient he was using but I
> > think the right place to report this would be to the distro since it
> > appears to be using an out of date dhclient. In the meantime disabling
> > offload seems like a reasonable local workaround but it is not a fix we
> > should apply by default.
> 
> Thanks for the links
> 
> I am running Ubuntu in the DomU.

Stefan, is this something you could help us with?

Ian, would it make sense to add all this awesome details in the Xen FAQ
Wiki part?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 20 15:47:32 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 Dec 2011 15:47:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rd1uH-0000Re-3l; Tue, 20 Dec 2011 15:47:09 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Rd1uF-0000RZ-Bj
	for Xen-devel@lists.xensource.com; Tue, 20 Dec 2011 15:47:07 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1324396006!8693302!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ1MDEzNQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3577 invoked from network); 20 Dec 2011 15:46:48 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-10.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 20 Dec 2011 15:46:48 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pBKFkhKc029198
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 20 Dec 2011 15:46:43 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pBKFkfla018388
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 20 Dec 2011 15:46:42 GMT
Received: from abhmt120.oracle.com (abhmt120.oracle.com [141.146.116.72])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pBKFkeGK009250; Tue, 20 Dec 2011 09:46:41 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 20 Dec 2011 07:46:40 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id A41F14003D; Tue, 20 Dec 2011 10:45:41 -0500 (EST)
Date: Tue, 20 Dec 2011 10:45:41 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>, axboe@kernel.dk
Message-ID: <20111220154541.GA1932@phenom.dumpdata.com>
References: <1323893534-436-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1323893534-436-7-git-send-email-dgdegra@tycho.nsa.gov>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1323893534-436-7-git-send-email-dgdegra@tycho.nsa.gov>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090207.4EF0ADE4.003F,ss=1,re=0.000,fgs=0
Cc: Xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 6/6] xen/blkback: Enable blkback on HVM
	guests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Dec 14, 2011 at 03:12:14PM -0500, Daniel De Graaf wrote:
> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>

Jens,

This patch is part of a series and while I can break this off to my
"stable/for-jens-3.3" branch (which I should send soonish), I was wondering
whether you would be OK just Ack-ing this so I can carry it/submit this
patch to Linus directly?

Thanks!
> ---
>  drivers/block/xen-blkback/blkback.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/block/xen-blkback/blkback.c b/drivers/block/xen-blkback/blkback.c
> index 1e256dc..fbffdf0 100644
> --- a/drivers/block/xen-blkback/blkback.c
> +++ b/drivers/block/xen-blkback/blkback.c
> @@ -823,7 +823,7 @@ static int __init xen_blkif_init(void)
>  	int i, mmap_pages;
>  	int rc = 0;
>  
> -	if (!xen_pv_domain())
> +	if (!xen_domain())
>  		return -ENODEV;
>  
>  	blkbk = kzalloc(sizeof(struct xen_blkbk), GFP_KERNEL);
> -- 
> 1.7.7.4

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 20 15:47:32 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 Dec 2011 15:47:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rd1uH-0000Re-3l; Tue, 20 Dec 2011 15:47:09 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Rd1uF-0000RZ-Bj
	for Xen-devel@lists.xensource.com; Tue, 20 Dec 2011 15:47:07 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1324396006!8693302!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ1MDEzNQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3577 invoked from network); 20 Dec 2011 15:46:48 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-10.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 20 Dec 2011 15:46:48 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pBKFkhKc029198
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 20 Dec 2011 15:46:43 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pBKFkfla018388
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 20 Dec 2011 15:46:42 GMT
Received: from abhmt120.oracle.com (abhmt120.oracle.com [141.146.116.72])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pBKFkeGK009250; Tue, 20 Dec 2011 09:46:41 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 20 Dec 2011 07:46:40 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id A41F14003D; Tue, 20 Dec 2011 10:45:41 -0500 (EST)
Date: Tue, 20 Dec 2011 10:45:41 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>, axboe@kernel.dk
Message-ID: <20111220154541.GA1932@phenom.dumpdata.com>
References: <1323893534-436-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1323893534-436-7-git-send-email-dgdegra@tycho.nsa.gov>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1323893534-436-7-git-send-email-dgdegra@tycho.nsa.gov>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090207.4EF0ADE4.003F,ss=1,re=0.000,fgs=0
Cc: Xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 6/6] xen/blkback: Enable blkback on HVM
	guests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Dec 14, 2011 at 03:12:14PM -0500, Daniel De Graaf wrote:
> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>

Jens,

This patch is part of a series and while I can break this off to my
"stable/for-jens-3.3" branch (which I should send soonish), I was wondering
whether you would be OK just Ack-ing this so I can carry it/submit this
patch to Linus directly?

Thanks!
> ---
>  drivers/block/xen-blkback/blkback.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/block/xen-blkback/blkback.c b/drivers/block/xen-blkback/blkback.c
> index 1e256dc..fbffdf0 100644
> --- a/drivers/block/xen-blkback/blkback.c
> +++ b/drivers/block/xen-blkback/blkback.c
> @@ -823,7 +823,7 @@ static int __init xen_blkif_init(void)
>  	int i, mmap_pages;
>  	int rc = 0;
>  
> -	if (!xen_pv_domain())
> +	if (!xen_domain())
>  		return -ENODEV;
>  
>  	blkbk = kzalloc(sizeof(struct xen_blkbk), GFP_KERNEL);
> -- 
> 1.7.7.4

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 20 15:50:28 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 Dec 2011 15:50:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rd1x6-0000bV-S0; Tue, 20 Dec 2011 15:50:04 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <gbtux@126.com>) id 1Rd1x4-0000bL-Hn
	for xen-devel@lists.xensource.com; Tue, 20 Dec 2011 15:50:02 +0000
X-Env-Sender: gbtux@126.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1324396087!56935329!1
X-Originating-IP: [220.181.15.44]
X-SpamReason: No, hits=0.9 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMjAuMTgxLjE1LjQ0ID0+IDE2NjE0\n,sa_preprocessor: 
	QmFkIElQOiAyMjAuMTgxLjE1LjQ0ID0+IDE2NjE0\n,HTML_20_30,HTML_MESSAGE
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7223 invoked from network); 20 Dec 2011 15:48:09 -0000
Received: from m15-44.126.com (HELO m15-44.126.com) (220.181.15.44)
	by server-8.tower-27.messagelabs.com with SMTP;
	20 Dec 2011 15:48:09 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=126.com;
	s=s110527; h=Received:Date:From:To:Cc:Message-ID:In-Reply-To:
	References:Subject:MIME-Version:Content-Type; bh=yJtjsoz1LFk6a+L
	XiRMNdX1KN/RdB1gHsdWc7unc9sU=; b=XtJt1mxxCY7/dM/6OV3vk9/IU6kmN78
	DQCc4u5m2tk0YvhC+Y3CwVMoj17PX8AZtarIkfiLLy9AYyT6SlMBkqXTmRdsOyx+
	8XT954S09yKdgAApO1SBPZ5LSlofxLpwDdVbfnur6xZIZ0nUCoxhE672cnSzD9lc
	VWSew4wsuJlI=
Received: from gbtux ( [124.16.139.196] ) by ajax-webmail-wmsvr44 (Coremail)
	; Tue, 20 Dec 2011 23:49:49 +0800 (CST)
Date: Tue, 20 Dec 2011 23:49:49 +0800 (CST)
From: gavin  <gbtux@126.com>
To: "George Dunlap" <George.Dunlap@eu.citrix.com>
Message-ID: <e7877fd.3f198.1345c2a185c.Coremail.gbtux@126.com>
In-Reply-To: <CAFLBxZZP=K504L86WDJ-F+9SuTf7aKU_C=i8nLZwqDuejoVGag@mail.gmail.com>
References: <CAFLBxZZP=K504L86WDJ-F+9SuTf7aKU_C=i8nLZwqDuejoVGag@mail.gmail.com>
	<26c93838.3b3fb.13445de0e67.Coremail.gbtux@126.com>
	<CAFLBxZYM-8vEc5Egmv+iXqMDUE_UJcgHbwr7=71H-kFowTzXWA@mail.gmail.com>
	<676b608e.2fb26.13447553671.Coremail.gbtux@126.com>
	<CAFLBxZaBiwEvz-dgPzgBQQTj2xMi8m+QnZ3M+uoqw4AKmb0ZvA@mail.gmail.com>
	<35e4701f.ca5a.1344b4ed98e.Coremail.gbtux@126.com>
MIME-Version: 1.0
X-Originating-IP: [124.16.139.196]
X-Priority: 3
X-Mailer: Coremail Webmail Server Version SP_ntes V3.5 build
	111202(16086.4213.4207) Copyright (c) 2002-2011 www.mailtech.cn 126com
X-CM-CTRLDATA: JKB+f2Zvb3Rlcl9odG09OTA0Ojgx
X-CM-TRANSID: LMqowECp7USgrvBOkVc4AA--.4496W
X-CM-SenderInfo: pjew35a6rslhhfrp/1tbi7gwcnE0vLG5j1AADs2
X-Coremail-Antispam: 1U5529EdanIXcx71UUUUU7vcSsGvfC2KfnxnUU==
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] A question on the credit scheduler
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============4924314168956639169=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============4924314168956639169==
Content-Type: multipart/alternative; 
	boundary="----=_Part_714417_1006099000.1324396189787"

------=_Part_714417_1006099000.1324396189787
Content-Type: text/plain; charset=GBK
Content-Transfer-Encoding: 7bit

Hi George,  


I have another question about the credit2 scheduling.
In a shared cache multi-core system, such as two processors (processor 0 and processor 1), there are two CPU cores in each processor. It seems that the credit scheduling treat all the four cores the same and doesn't distinguish them. 
However, I am not sure whether the credit2 scheduling distinguishs them from each other? Maybe the four cores can be divided into two groups. The two cores on the same processor are in the same group. I noted there is development of CPU topology in the To-do list on the credit2 Xen wiki page, but there is no details about the current situation of credit2 scheduling.




--
Best Regards,
Gavin
------=_Part_714417_1006099000.1324396189787
Content-Type: text/html; charset=GBK
Content-Transfer-Encoding: 7bit

<div style="line-height:1.7;color:#000000;font-size:14px;font-family:arial"><div>Hi George, &nbsp;</div><div><br></div><div>I have another question about the credit2 scheduling.</div><div>In a shared cache multi-core system, such as two processors (processor 0 and processor 1), there are two CPU cores in&nbsp;each processor. It seems that the credit scheduling treat all the four cores the same and doesn't distinguish them.&nbsp;</div><div>However, I am not sure whether the credit2 scheduling distinguishs them from each other? Maybe the four cores can be&nbsp;divided into two groups. The two cores on the same processor are in the same group. I noted there is development of CPU topology in the To-do list on the credit2 Xen wiki page, but there is no details about the current situation of credit2 scheduling.</div><div><br></div><div><br></div><div>--<br>Best Regards,<div>Gavin</div></div></div><br><br><span title="neteasefooter"><span id="netease_mail_footer"></span></span>
------=_Part_714417_1006099000.1324396189787--



--===============4924314168956639169==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============4924314168956639169==--



From xen-devel-bounces@lists.xensource.com Tue Dec 20 15:50:28 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 Dec 2011 15:50:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rd1x6-0000bV-S0; Tue, 20 Dec 2011 15:50:04 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <gbtux@126.com>) id 1Rd1x4-0000bL-Hn
	for xen-devel@lists.xensource.com; Tue, 20 Dec 2011 15:50:02 +0000
X-Env-Sender: gbtux@126.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1324396087!56935329!1
X-Originating-IP: [220.181.15.44]
X-SpamReason: No, hits=0.9 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMjAuMTgxLjE1LjQ0ID0+IDE2NjE0\n,sa_preprocessor: 
	QmFkIElQOiAyMjAuMTgxLjE1LjQ0ID0+IDE2NjE0\n,HTML_20_30,HTML_MESSAGE
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7223 invoked from network); 20 Dec 2011 15:48:09 -0000
Received: from m15-44.126.com (HELO m15-44.126.com) (220.181.15.44)
	by server-8.tower-27.messagelabs.com with SMTP;
	20 Dec 2011 15:48:09 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=126.com;
	s=s110527; h=Received:Date:From:To:Cc:Message-ID:In-Reply-To:
	References:Subject:MIME-Version:Content-Type; bh=yJtjsoz1LFk6a+L
	XiRMNdX1KN/RdB1gHsdWc7unc9sU=; b=XtJt1mxxCY7/dM/6OV3vk9/IU6kmN78
	DQCc4u5m2tk0YvhC+Y3CwVMoj17PX8AZtarIkfiLLy9AYyT6SlMBkqXTmRdsOyx+
	8XT954S09yKdgAApO1SBPZ5LSlofxLpwDdVbfnur6xZIZ0nUCoxhE672cnSzD9lc
	VWSew4wsuJlI=
Received: from gbtux ( [124.16.139.196] ) by ajax-webmail-wmsvr44 (Coremail)
	; Tue, 20 Dec 2011 23:49:49 +0800 (CST)
Date: Tue, 20 Dec 2011 23:49:49 +0800 (CST)
From: gavin  <gbtux@126.com>
To: "George Dunlap" <George.Dunlap@eu.citrix.com>
Message-ID: <e7877fd.3f198.1345c2a185c.Coremail.gbtux@126.com>
In-Reply-To: <CAFLBxZZP=K504L86WDJ-F+9SuTf7aKU_C=i8nLZwqDuejoVGag@mail.gmail.com>
References: <CAFLBxZZP=K504L86WDJ-F+9SuTf7aKU_C=i8nLZwqDuejoVGag@mail.gmail.com>
	<26c93838.3b3fb.13445de0e67.Coremail.gbtux@126.com>
	<CAFLBxZYM-8vEc5Egmv+iXqMDUE_UJcgHbwr7=71H-kFowTzXWA@mail.gmail.com>
	<676b608e.2fb26.13447553671.Coremail.gbtux@126.com>
	<CAFLBxZaBiwEvz-dgPzgBQQTj2xMi8m+QnZ3M+uoqw4AKmb0ZvA@mail.gmail.com>
	<35e4701f.ca5a.1344b4ed98e.Coremail.gbtux@126.com>
MIME-Version: 1.0
X-Originating-IP: [124.16.139.196]
X-Priority: 3
X-Mailer: Coremail Webmail Server Version SP_ntes V3.5 build
	111202(16086.4213.4207) Copyright (c) 2002-2011 www.mailtech.cn 126com
X-CM-CTRLDATA: JKB+f2Zvb3Rlcl9odG09OTA0Ojgx
X-CM-TRANSID: LMqowECp7USgrvBOkVc4AA--.4496W
X-CM-SenderInfo: pjew35a6rslhhfrp/1tbi7gwcnE0vLG5j1AADs2
X-Coremail-Antispam: 1U5529EdanIXcx71UUUUU7vcSsGvfC2KfnxnUU==
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] A question on the credit scheduler
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============4924314168956639169=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============4924314168956639169==
Content-Type: multipart/alternative; 
	boundary="----=_Part_714417_1006099000.1324396189787"

------=_Part_714417_1006099000.1324396189787
Content-Type: text/plain; charset=GBK
Content-Transfer-Encoding: 7bit

Hi George,  


I have another question about the credit2 scheduling.
In a shared cache multi-core system, such as two processors (processor 0 and processor 1), there are two CPU cores in each processor. It seems that the credit scheduling treat all the four cores the same and doesn't distinguish them. 
However, I am not sure whether the credit2 scheduling distinguishs them from each other? Maybe the four cores can be divided into two groups. The two cores on the same processor are in the same group. I noted there is development of CPU topology in the To-do list on the credit2 Xen wiki page, but there is no details about the current situation of credit2 scheduling.




--
Best Regards,
Gavin
------=_Part_714417_1006099000.1324396189787
Content-Type: text/html; charset=GBK
Content-Transfer-Encoding: 7bit

<div style="line-height:1.7;color:#000000;font-size:14px;font-family:arial"><div>Hi George, &nbsp;</div><div><br></div><div>I have another question about the credit2 scheduling.</div><div>In a shared cache multi-core system, such as two processors (processor 0 and processor 1), there are two CPU cores in&nbsp;each processor. It seems that the credit scheduling treat all the four cores the same and doesn't distinguish them.&nbsp;</div><div>However, I am not sure whether the credit2 scheduling distinguishs them from each other? Maybe the four cores can be&nbsp;divided into two groups. The two cores on the same processor are in the same group. I noted there is development of CPU topology in the To-do list on the credit2 Xen wiki page, but there is no details about the current situation of credit2 scheduling.</div><div><br></div><div><br></div><div>--<br>Best Regards,<div>Gavin</div></div></div><br><br><span title="neteasefooter"><span id="netease_mail_footer"></span></span>
------=_Part_714417_1006099000.1324396189787--



--===============4924314168956639169==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============4924314168956639169==--



From xen-devel-bounces@lists.xensource.com Tue Dec 20 15:55:05 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 Dec 2011 15:55:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rd21a-0000vN-RB; Tue, 20 Dec 2011 15:54:42 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1Rd21Z-0000v4-BG
	for xen-devel@lists.xensource.com; Tue, 20 Dec 2011 15:54:41 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1324396475!2709574!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzQwMQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19381 invoked from network); 20 Dec 2011 15:54:35 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Dec 2011 15:54:35 -0000
X-IronPort-AV: E=Sophos;i="4.71,382,1320624000"; 
   d="scan'208";a="9585500"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Dec 2011 15:54:12 +0000
Received: from dhcp-3-28.uk.xensource.com (10.80.3.28) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 20 Dec 2011 15:54:11 +0000
Date: Tue, 20 Dec 2011 15:54:05 +0000
From: Anthony PERARD <anthony.perard@citrix.com>
X-X-Sender: anthony@perard.uk.xensource.com
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1324031825.20077.562.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1112201512040.21175@perard.uk.xensource.com>
References: <64e48ae2ef6760db221f.1323796155@cosworth.uk.xensource.com>
	<20202.10169.101830.45527@mariner.uk.xensource.com>
	<1324031825.20077.562.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] libxl: improve error handling when saving
 device model state
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 16 Dec 2011, Ian Campbell wrote:

> On Thu, 2011-12-15 at 17:00 +0000, Ian Jackson wrote:
> > Ian Campbell writes ("[Xen-devel] [PATCH] libxl: improve error handling when saving device model state"):
> > > libxl: improve error handling when saving device model state.
> > ...
> > > +out_close_fd2:
> > >      close(fd2);
> > > +out_unlink:
> > >      unlink(filename);
> >
> > This style of error handling is very prone to errors.
> >
> > How about:
> >
> >     int fd2 = -1;
> >
> >     blah blah maybe goto out blah blah
> >
> >     if (fd2 >= 0) close(fd2);
> >
> > And always unlinking the filename is fine, surely ?
>
> Yes. Patch is below.
>
> In principal it ought to be possible to save upstream qemu state direct
> to the fd and avoid the file altogether, Anthony what do you think?

Upstream QEMU only use the fd, so only xl now about the filename.
I've just create the file because it was more convenient to use in libxl
than changing more code.

So yes, we can avoid the file.

And the patch looks fine to me.

Regards,

-- 
Anthony PERARD

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 20 15:55:05 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 Dec 2011 15:55:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rd21a-0000vN-RB; Tue, 20 Dec 2011 15:54:42 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1Rd21Z-0000v4-BG
	for xen-devel@lists.xensource.com; Tue, 20 Dec 2011 15:54:41 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1324396475!2709574!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzQwMQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19381 invoked from network); 20 Dec 2011 15:54:35 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Dec 2011 15:54:35 -0000
X-IronPort-AV: E=Sophos;i="4.71,382,1320624000"; 
   d="scan'208";a="9585500"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Dec 2011 15:54:12 +0000
Received: from dhcp-3-28.uk.xensource.com (10.80.3.28) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 20 Dec 2011 15:54:11 +0000
Date: Tue, 20 Dec 2011 15:54:05 +0000
From: Anthony PERARD <anthony.perard@citrix.com>
X-X-Sender: anthony@perard.uk.xensource.com
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1324031825.20077.562.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1112201512040.21175@perard.uk.xensource.com>
References: <64e48ae2ef6760db221f.1323796155@cosworth.uk.xensource.com>
	<20202.10169.101830.45527@mariner.uk.xensource.com>
	<1324031825.20077.562.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] libxl: improve error handling when saving
 device model state
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 16 Dec 2011, Ian Campbell wrote:

> On Thu, 2011-12-15 at 17:00 +0000, Ian Jackson wrote:
> > Ian Campbell writes ("[Xen-devel] [PATCH] libxl: improve error handling when saving device model state"):
> > > libxl: improve error handling when saving device model state.
> > ...
> > > +out_close_fd2:
> > >      close(fd2);
> > > +out_unlink:
> > >      unlink(filename);
> >
> > This style of error handling is very prone to errors.
> >
> > How about:
> >
> >     int fd2 = -1;
> >
> >     blah blah maybe goto out blah blah
> >
> >     if (fd2 >= 0) close(fd2);
> >
> > And always unlinking the filename is fine, surely ?
>
> Yes. Patch is below.
>
> In principal it ought to be possible to save upstream qemu state direct
> to the fd and avoid the file altogether, Anthony what do you think?

Upstream QEMU only use the fd, so only xl now about the filename.
I've just create the file because it was more convenient to use in libxl
than changing more code.

So yes, we can avoid the file.

And the patch looks fine to me.

Regards,

-- 
Anthony PERARD

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 20 15:56:54 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 Dec 2011 15:56:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rd23R-00012h-BQ; Tue, 20 Dec 2011 15:56:37 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Rd23Q-00012J-5m
	for Xen-devel@lists.xensource.com; Tue, 20 Dec 2011 15:56:36 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1324396588!8962621!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDUxNDAx\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24144 invoked from network); 20 Dec 2011 15:56:30 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-3.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 20 Dec 2011 15:56:30 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pBKFuRr5021709
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 20 Dec 2011 15:56:28 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pBKFuQUh006307
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 20 Dec 2011 15:56:26 GMT
Received: from abhmt113.oracle.com (abhmt113.oracle.com [141.146.116.65])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pBKFuPKn013140; Tue, 20 Dec 2011 09:56:26 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 20 Dec 2011 07:56:25 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 7B7FE4003D; Tue, 20 Dec 2011 10:55:26 -0500 (EST)
Date: Tue, 20 Dec 2011 10:55:26 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Message-ID: <20111220155526.GB1932@phenom.dumpdata.com>
References: <1323893534-436-1-git-send-email-dgdegra@tycho.nsa.gov>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1323893534-436-1-git-send-email-dgdegra@tycho.nsa.gov>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090203.4EF0B02C.00AE,ss=1,re=0.000,fgs=0
Cc: Xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH v3 0/6] xen/{net,
	blk}back support for running in HVM
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Dec 14, 2011 at 03:12:08PM -0500, Daniel De Graaf wrote:
> Changes from v2:
>  - Clarified comments and commit messages
>  - Based on v3.2-rc3
> 
> Changes from v1:
>  - Rebased on top of David's patches
>  - Grant table wrapper functions used where appropriate
> 
> [PATCH 1/6] xenbus: Support HVM backends
> [PATCH 2/6] xenbus: Use grant-table wrapper functions
> [PATCH 3/6] xen/grant-table: Support mappings required by blkback
> [PATCH 4/6] xen/blkback: use grant-table.c hypercall wrappers
> [PATCH 5/6] xen/netback: Enable netback on HVM guests
> [PATCH 6/6] xen/blkback: Enable blkback on HVM guests

Applied all of them in my #testing branch. Will move them next week
to #linux-next pending testing, Ack from Jens for #4 and #6.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 20 15:56:54 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 Dec 2011 15:56:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rd23R-00012h-BQ; Tue, 20 Dec 2011 15:56:37 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Rd23Q-00012J-5m
	for Xen-devel@lists.xensource.com; Tue, 20 Dec 2011 15:56:36 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1324396588!8962621!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDUxNDAx\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24144 invoked from network); 20 Dec 2011 15:56:30 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-3.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 20 Dec 2011 15:56:30 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pBKFuRr5021709
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 20 Dec 2011 15:56:28 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pBKFuQUh006307
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 20 Dec 2011 15:56:26 GMT
Received: from abhmt113.oracle.com (abhmt113.oracle.com [141.146.116.65])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pBKFuPKn013140; Tue, 20 Dec 2011 09:56:26 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 20 Dec 2011 07:56:25 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 7B7FE4003D; Tue, 20 Dec 2011 10:55:26 -0500 (EST)
Date: Tue, 20 Dec 2011 10:55:26 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Message-ID: <20111220155526.GB1932@phenom.dumpdata.com>
References: <1323893534-436-1-git-send-email-dgdegra@tycho.nsa.gov>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1323893534-436-1-git-send-email-dgdegra@tycho.nsa.gov>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090203.4EF0B02C.00AE,ss=1,re=0.000,fgs=0
Cc: Xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH v3 0/6] xen/{net,
	blk}back support for running in HVM
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Dec 14, 2011 at 03:12:08PM -0500, Daniel De Graaf wrote:
> Changes from v2:
>  - Clarified comments and commit messages
>  - Based on v3.2-rc3
> 
> Changes from v1:
>  - Rebased on top of David's patches
>  - Grant table wrapper functions used where appropriate
> 
> [PATCH 1/6] xenbus: Support HVM backends
> [PATCH 2/6] xenbus: Use grant-table wrapper functions
> [PATCH 3/6] xen/grant-table: Support mappings required by blkback
> [PATCH 4/6] xen/blkback: use grant-table.c hypercall wrappers
> [PATCH 5/6] xen/netback: Enable netback on HVM guests
> [PATCH 6/6] xen/blkback: Enable blkback on HVM guests

Applied all of them in my #testing branch. Will move them next week
to #linux-next pending testing, Ack from Jens for #4 and #6.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 20 16:00:01 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 Dec 2011 16:00:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rd26N-0001JB-LB; Tue, 20 Dec 2011 15:59:39 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Rd26M-0001IO-JJ
	for Xen-devel@lists.xensource.com; Tue, 20 Dec 2011 15:59:38 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1324396771!6295683!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDUxNDAx\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12713 invoked from network); 20 Dec 2011 15:59:32 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-10.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 20 Dec 2011 15:59:32 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pBKFxPkD025866
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 20 Dec 2011 15:59:26 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pBKFxPaX017677
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 20 Dec 2011 15:59:25 GMT
Received: from abhmt107.oracle.com (abhmt107.oracle.com [141.146.116.59])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pBKFxOFr015626; Tue, 20 Dec 2011 09:59:24 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 20 Dec 2011 07:59:24 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 739CA4003D; Tue, 20 Dec 2011 10:58:25 -0500 (EST)
Date: Tue, 20 Dec 2011 10:58:25 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>, axboe@kernel.dk
Message-ID: <20111220155825.GC1932@phenom.dumpdata.com>
References: <1323893534-436-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1323893534-436-5-git-send-email-dgdegra@tycho.nsa.gov>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1323893534-436-5-git-send-email-dgdegra@tycho.nsa.gov>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090203.4EF0B0DF.002E,ss=1,re=0.000,fgs=0
Cc: Xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 4/6] xen/blkback: use grant-table.c
	hypercall wrappers
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Dec 14, 2011 at 03:12:12PM -0500, Daniel De Graaf wrote:
> Now that the grant table hypercall wrappers support mappings without
> GNTMAP_contains_pte, they should be used instead of invoking the
> hypercalls manually.

Hey Jens,

Same deal with this patch as with the other one I sent. Part of a
patchset, and this particular code moves the mucking around to the
existing library that does the mucking around.

It can be applied seperatly so I can also just move this patch
to my "stable/for-jens.3.3" patch series if that would make it easier
for you?

Thanks!
> 
> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
> ---
>  drivers/block/xen-blkback/blkback.c |   29 ++++-------------------------
>  1 files changed, 4 insertions(+), 25 deletions(-)
> 
> diff --git a/drivers/block/xen-blkback/blkback.c b/drivers/block/xen-blkback/blkback.c
> index 15ec4db..1e256dc 100644
> --- a/drivers/block/xen-blkback/blkback.c
> +++ b/drivers/block/xen-blkback/blkback.c
> @@ -324,6 +324,7 @@ struct seg_buf {
>  static void xen_blkbk_unmap(struct pending_req *req)
>  {
>  	struct gnttab_unmap_grant_ref unmap[BLKIF_MAX_SEGMENTS_PER_REQUEST];
> +	struct page *pages[BLKIF_MAX_SEGMENTS_PER_REQUEST];
>  	unsigned int i, invcount = 0;
>  	grant_handle_t handle;
>  	int ret;
> @@ -335,25 +336,12 @@ static void xen_blkbk_unmap(struct pending_req *req)
>  		gnttab_set_unmap_op(&unmap[invcount], vaddr(req, i),
>  				    GNTMAP_host_map, handle);
>  		pending_handle(req, i) = BLKBACK_INVALID_HANDLE;
> +		pages[invcount] = virt_to_page(vaddr(req, i));
>  		invcount++;
>  	}
>  
> -	ret = HYPERVISOR_grant_table_op(
> -		GNTTABOP_unmap_grant_ref, unmap, invcount);
> +	ret = gnttab_unmap_refs(unmap, pages, invcount, false);
>  	BUG_ON(ret);
> -	/*
> -	 * Note, we use invcount, so nr->pages, so we can't index
> -	 * using vaddr(req, i).
> -	 */
> -	for (i = 0; i < invcount; i++) {
> -		ret = m2p_remove_override(
> -			virt_to_page(unmap[i].host_addr), false);
> -		if (ret) {
> -			pr_alert(DRV_PFX "Failed to remove M2P override for %lx\n",
> -				 (unsigned long)unmap[i].host_addr);
> -			continue;
> -		}
> -	}
>  }
>  
>  static int xen_blkbk_map(struct blkif_request *req,
> @@ -381,7 +369,7 @@ static int xen_blkbk_map(struct blkif_request *req,
>  				  pending_req->blkif->domid);
>  	}
>  
> -	ret = HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, map, nseg);
> +	ret = gnttab_map_refs(map, NULL, &blkbk->pending_page(pending_req, 0), nseg);
>  	BUG_ON(ret);
>  
>  	/*
> @@ -401,15 +389,6 @@ static int xen_blkbk_map(struct blkif_request *req,
>  		if (ret)
>  			continue;
>  
> -		ret = m2p_add_override(PFN_DOWN(map[i].dev_bus_addr),
> -			blkbk->pending_page(pending_req, i), NULL);
> -		if (ret) {
> -			pr_alert(DRV_PFX "Failed to install M2P override for %lx (ret: %d)\n",
> -				 (unsigned long)map[i].dev_bus_addr, ret);
> -			/* We could switch over to GNTTABOP_copy */
> -			continue;
> -		}
> -
>  		seg[i].buf  = map[i].dev_bus_addr |
>  			(req->u.rw.seg[i].first_sect << 9);
>  	}
> -- 
> 1.7.7.4

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 20 16:00:01 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 Dec 2011 16:00:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rd26N-0001JB-LB; Tue, 20 Dec 2011 15:59:39 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Rd26M-0001IO-JJ
	for Xen-devel@lists.xensource.com; Tue, 20 Dec 2011 15:59:38 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1324396771!6295683!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDUxNDAx\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12713 invoked from network); 20 Dec 2011 15:59:32 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-10.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 20 Dec 2011 15:59:32 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pBKFxPkD025866
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 20 Dec 2011 15:59:26 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pBKFxPaX017677
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 20 Dec 2011 15:59:25 GMT
Received: from abhmt107.oracle.com (abhmt107.oracle.com [141.146.116.59])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pBKFxOFr015626; Tue, 20 Dec 2011 09:59:24 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 20 Dec 2011 07:59:24 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 739CA4003D; Tue, 20 Dec 2011 10:58:25 -0500 (EST)
Date: Tue, 20 Dec 2011 10:58:25 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>, axboe@kernel.dk
Message-ID: <20111220155825.GC1932@phenom.dumpdata.com>
References: <1323893534-436-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1323893534-436-5-git-send-email-dgdegra@tycho.nsa.gov>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1323893534-436-5-git-send-email-dgdegra@tycho.nsa.gov>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090203.4EF0B0DF.002E,ss=1,re=0.000,fgs=0
Cc: Xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 4/6] xen/blkback: use grant-table.c
	hypercall wrappers
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Dec 14, 2011 at 03:12:12PM -0500, Daniel De Graaf wrote:
> Now that the grant table hypercall wrappers support mappings without
> GNTMAP_contains_pte, they should be used instead of invoking the
> hypercalls manually.

Hey Jens,

Same deal with this patch as with the other one I sent. Part of a
patchset, and this particular code moves the mucking around to the
existing library that does the mucking around.

It can be applied seperatly so I can also just move this patch
to my "stable/for-jens.3.3" patch series if that would make it easier
for you?

Thanks!
> 
> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
> ---
>  drivers/block/xen-blkback/blkback.c |   29 ++++-------------------------
>  1 files changed, 4 insertions(+), 25 deletions(-)
> 
> diff --git a/drivers/block/xen-blkback/blkback.c b/drivers/block/xen-blkback/blkback.c
> index 15ec4db..1e256dc 100644
> --- a/drivers/block/xen-blkback/blkback.c
> +++ b/drivers/block/xen-blkback/blkback.c
> @@ -324,6 +324,7 @@ struct seg_buf {
>  static void xen_blkbk_unmap(struct pending_req *req)
>  {
>  	struct gnttab_unmap_grant_ref unmap[BLKIF_MAX_SEGMENTS_PER_REQUEST];
> +	struct page *pages[BLKIF_MAX_SEGMENTS_PER_REQUEST];
>  	unsigned int i, invcount = 0;
>  	grant_handle_t handle;
>  	int ret;
> @@ -335,25 +336,12 @@ static void xen_blkbk_unmap(struct pending_req *req)
>  		gnttab_set_unmap_op(&unmap[invcount], vaddr(req, i),
>  				    GNTMAP_host_map, handle);
>  		pending_handle(req, i) = BLKBACK_INVALID_HANDLE;
> +		pages[invcount] = virt_to_page(vaddr(req, i));
>  		invcount++;
>  	}
>  
> -	ret = HYPERVISOR_grant_table_op(
> -		GNTTABOP_unmap_grant_ref, unmap, invcount);
> +	ret = gnttab_unmap_refs(unmap, pages, invcount, false);
>  	BUG_ON(ret);
> -	/*
> -	 * Note, we use invcount, so nr->pages, so we can't index
> -	 * using vaddr(req, i).
> -	 */
> -	for (i = 0; i < invcount; i++) {
> -		ret = m2p_remove_override(
> -			virt_to_page(unmap[i].host_addr), false);
> -		if (ret) {
> -			pr_alert(DRV_PFX "Failed to remove M2P override for %lx\n",
> -				 (unsigned long)unmap[i].host_addr);
> -			continue;
> -		}
> -	}
>  }
>  
>  static int xen_blkbk_map(struct blkif_request *req,
> @@ -381,7 +369,7 @@ static int xen_blkbk_map(struct blkif_request *req,
>  				  pending_req->blkif->domid);
>  	}
>  
> -	ret = HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, map, nseg);
> +	ret = gnttab_map_refs(map, NULL, &blkbk->pending_page(pending_req, 0), nseg);
>  	BUG_ON(ret);
>  
>  	/*
> @@ -401,15 +389,6 @@ static int xen_blkbk_map(struct blkif_request *req,
>  		if (ret)
>  			continue;
>  
> -		ret = m2p_add_override(PFN_DOWN(map[i].dev_bus_addr),
> -			blkbk->pending_page(pending_req, i), NULL);
> -		if (ret) {
> -			pr_alert(DRV_PFX "Failed to install M2P override for %lx (ret: %d)\n",
> -				 (unsigned long)map[i].dev_bus_addr, ret);
> -			/* We could switch over to GNTTABOP_copy */
> -			continue;
> -		}
> -
>  		seg[i].buf  = map[i].dev_bus_addr |
>  			(req->u.rw.seg[i].first_sect << 9);
>  	}
> -- 
> 1.7.7.4

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 20 16:18:32 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 Dec 2011 16:18:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rd2Nh-0002DM-Ld; Tue, 20 Dec 2011 16:17:33 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Rd2Ng-0002DH-3k
	for xen-devel@lists.xen.org; Tue, 20 Dec 2011 16:17:32 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1324397845!6276762!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzQwMQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19086 invoked from network); 20 Dec 2011 16:17:26 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Dec 2011 16:17:26 -0000
X-IronPort-AV: E=Sophos;i="4.71,382,1320624000"; 
   d="scan'208";a="9586371"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Dec 2011 16:17:11 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 20 Dec 2011 16:17:11 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Rd2NK-0004kO-U0	for xen-devel@lists.xen.org;
	Tue, 20 Dec 2011 16:17:10 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rd2NK-00071m-T1	for
	xen-devel@lists.xen.org; Tue, 20 Dec 2011 16:17:10 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20208.46342.885854.11320@mariner.uk.xensource.com>
Date: Tue, 20 Dec 2011 16:17:10 +0000
To: xen-devel@lists.xen.org
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Subject: [Xen-devel] vmalloc_sync_all crash still happening on some machines
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

See the crash below, which happened on one of my test machines which
still aren't in the test pool due to these kind of failures.

The bug happened immediately after localhost migration of a pv guest.

The kernel was 2.6.32.46 (as built in flight 10515).

Ian.

Dec 16 19:02:13.085286 [  391.370426] ------------[ cut here ]------------^M
Dec 16 19:02:13.097267 [  391.370440] kernel BUG at arch/x86/mm/fault.c:210!^M
Dec 16 19:02:13.097303 [  391.370460] invalid opcode: 0000 [#1] SMP ^M
Dec 16 19:02:13.109253 [  391.370491] last sysfs file: /sys/devices/vif-9-0/uevent^M
Dec 16 19:02:13.109291 [  391.370503] Modules linked in: e1000e [last unloaded: scsi_wait_scan]^M
Dec 16 19:02:13.117292 [  391.370575] ^M
Dec 16 19:02:13.117330 [  391.370597] Pid: 40, comm: xenwatch Not tainted (2.6.32.46 #1) X9SCL/X9SCM^M
Dec 16 19:02:13.129252 [  391.370613] EIP: 0061:[<c104a052>] EFLAGS: 00010082 CPU: 5^M
Dec 16 19:02:13.129289 [  391.370633] EIP is at vmalloc_sync_one+0x112/0x121^M
Dec 16 19:02:13.137260 [  391.370646] EAX: 000050a0 EBX: c1810fd0 ECX: fffff2e3 EDX: 00000000^M
Dec 16 19:02:13.149240 [  391.370661] ESI: ffffffe0 EDI: d9248fff EBP: dfda7ea8 ESP: dfda7e94^M
Dec 16 19:02:13.149279 [  391.370677]  DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0069^M
Dec 16 19:02:13.157316 [  391.370690] Process xenwatch (pid: 40, ti=dfda6000 task=dfce3cc0 task.ti=dfda6000)^M
Dec 16 19:02:13.169240 [  391.370705] Stack:^M
Dec 16 19:02:13.169267 [  391.370716]  00285067 00000000 c5c68640 ff400000 c1810fc8 dfda7ec4 c104aa52 c1760204^M
Dec 16 19:02:13.177285 [  391.370783] <0> c4be6f84 d7411320 df68bb40 dbc2b600 dfda7ed0 c10da2f9 fffffff4 dfda7f28^M
Dec 16 19:02:13.177352 [  391.370858] <0> c122c1f3 0000032a 00000300 df68bb40 0200006b dce9d3a8 400002c0 c102c23b^M
Dec 16 19:02:13.189265 [  391.370940] Call Trace:^M
Dec 16 19:02:13.189298 [  391.370960]  [<c104aa52>] ? vmalloc_sync_all+0x5f/0xc1^M
Dec 16 19:02:13.197260 [  391.370982]  [<c10da2f9>] ? alloc_vm_area+0x44/0x4b^M
Dec 16 19:02:13.197296 [  391.371004]  [<c122c1f3>] ? netif_map+0x45/0x24d^M
Dec 16 19:02:13.209317 [  391.371033]  [<c102c23b>] ? xen_restore_fl_direct_end+0x0/0x1^M
Dec 16 19:02:13.209352 [  391.371065]  [<c10e40b8>] ? kfree+0xff/0x107^M
Dec 16 19:02:13.217261 [  391.371097]  [<c121e974>] ? xenbus_scanf+0x35/0x48^M
Dec 16 19:02:13.217297 [  391.371118]  [<c122b8b8>] ? frontend_changed+0x2a2/0x4f0^M
Dec 16 19:02:13.229254 [  391.371137]  [<c121f331>] ? xenbus_otherend_changed+0x5c/0x61^M
Dec 16 19:02:13.237246 [  391.371158]  [<c121f6ff>] ? frontend_changed+0xa/0xd^M
Dec 16 19:02:13.237283 [  391.371178]  [<c121e00c>] ? xenwatch_thread+0xfe/0x126^M
Dec 16 19:02:13.245274 [  391.371199]  [<c1076589>] ? autoremove_wake_function+0x0/0x2f^M
Dec 16 19:02:13.245317 [  391.371223]  [<c121df0e>] ? xenwatch_thread+0x0/0x126^M
Dec 16 19:02:13.257249 [  391.371244]  [<c107626f>] ? kthread+0x5f/0x64^M
Dec 16 19:02:13.257283 [  391.371261]  [<c1076210>] ? kthread+0x0/0x64^M
Dec 16 19:02:13.265277 [  391.371283]  [<c102f497>] ? kernel_thread_helper+0x7/0x10^M
Dec 16 19:02:13.265318 [  391.371297] Code: eb fe ff 15 08 dd 66 c1 8b 7d ec 89 ce 89 45 ec 8b 45 ec 89 55 f0 8b 55 f0 0f ac fe 0c c1 e6 05 0f ac d0 0c c1 e0 05 39 c6 74 06 <0f> 0b eb fe 31 db 5a 89 d8 59 5b 5e 5f 5d c3 55 89 e5 53 89 c3 ^M
Dec 16 19:02:13.285270 [  391.371792] EIP: [<c104a052>] vmalloc_sync_one+0x112/0x121 SS:ESP 0069:dfda7e94^M
Dec 16 19:02:13.293255 [  391.371833] ---[ end trace 27f82c4d856810c0 ]---^M

10520/test-amd64-i386-xl

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 20 16:18:32 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 Dec 2011 16:18:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rd2Nh-0002DM-Ld; Tue, 20 Dec 2011 16:17:33 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Rd2Ng-0002DH-3k
	for xen-devel@lists.xen.org; Tue, 20 Dec 2011 16:17:32 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1324397845!6276762!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzQwMQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19086 invoked from network); 20 Dec 2011 16:17:26 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Dec 2011 16:17:26 -0000
X-IronPort-AV: E=Sophos;i="4.71,382,1320624000"; 
   d="scan'208";a="9586371"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Dec 2011 16:17:11 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 20 Dec 2011 16:17:11 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Rd2NK-0004kO-U0	for xen-devel@lists.xen.org;
	Tue, 20 Dec 2011 16:17:10 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rd2NK-00071m-T1	for
	xen-devel@lists.xen.org; Tue, 20 Dec 2011 16:17:10 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20208.46342.885854.11320@mariner.uk.xensource.com>
Date: Tue, 20 Dec 2011 16:17:10 +0000
To: xen-devel@lists.xen.org
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Subject: [Xen-devel] vmalloc_sync_all crash still happening on some machines
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

See the crash below, which happened on one of my test machines which
still aren't in the test pool due to these kind of failures.

The bug happened immediately after localhost migration of a pv guest.

The kernel was 2.6.32.46 (as built in flight 10515).

Ian.

Dec 16 19:02:13.085286 [  391.370426] ------------[ cut here ]------------^M
Dec 16 19:02:13.097267 [  391.370440] kernel BUG at arch/x86/mm/fault.c:210!^M
Dec 16 19:02:13.097303 [  391.370460] invalid opcode: 0000 [#1] SMP ^M
Dec 16 19:02:13.109253 [  391.370491] last sysfs file: /sys/devices/vif-9-0/uevent^M
Dec 16 19:02:13.109291 [  391.370503] Modules linked in: e1000e [last unloaded: scsi_wait_scan]^M
Dec 16 19:02:13.117292 [  391.370575] ^M
Dec 16 19:02:13.117330 [  391.370597] Pid: 40, comm: xenwatch Not tainted (2.6.32.46 #1) X9SCL/X9SCM^M
Dec 16 19:02:13.129252 [  391.370613] EIP: 0061:[<c104a052>] EFLAGS: 00010082 CPU: 5^M
Dec 16 19:02:13.129289 [  391.370633] EIP is at vmalloc_sync_one+0x112/0x121^M
Dec 16 19:02:13.137260 [  391.370646] EAX: 000050a0 EBX: c1810fd0 ECX: fffff2e3 EDX: 00000000^M
Dec 16 19:02:13.149240 [  391.370661] ESI: ffffffe0 EDI: d9248fff EBP: dfda7ea8 ESP: dfda7e94^M
Dec 16 19:02:13.149279 [  391.370677]  DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0069^M
Dec 16 19:02:13.157316 [  391.370690] Process xenwatch (pid: 40, ti=dfda6000 task=dfce3cc0 task.ti=dfda6000)^M
Dec 16 19:02:13.169240 [  391.370705] Stack:^M
Dec 16 19:02:13.169267 [  391.370716]  00285067 00000000 c5c68640 ff400000 c1810fc8 dfda7ec4 c104aa52 c1760204^M
Dec 16 19:02:13.177285 [  391.370783] <0> c4be6f84 d7411320 df68bb40 dbc2b600 dfda7ed0 c10da2f9 fffffff4 dfda7f28^M
Dec 16 19:02:13.177352 [  391.370858] <0> c122c1f3 0000032a 00000300 df68bb40 0200006b dce9d3a8 400002c0 c102c23b^M
Dec 16 19:02:13.189265 [  391.370940] Call Trace:^M
Dec 16 19:02:13.189298 [  391.370960]  [<c104aa52>] ? vmalloc_sync_all+0x5f/0xc1^M
Dec 16 19:02:13.197260 [  391.370982]  [<c10da2f9>] ? alloc_vm_area+0x44/0x4b^M
Dec 16 19:02:13.197296 [  391.371004]  [<c122c1f3>] ? netif_map+0x45/0x24d^M
Dec 16 19:02:13.209317 [  391.371033]  [<c102c23b>] ? xen_restore_fl_direct_end+0x0/0x1^M
Dec 16 19:02:13.209352 [  391.371065]  [<c10e40b8>] ? kfree+0xff/0x107^M
Dec 16 19:02:13.217261 [  391.371097]  [<c121e974>] ? xenbus_scanf+0x35/0x48^M
Dec 16 19:02:13.217297 [  391.371118]  [<c122b8b8>] ? frontend_changed+0x2a2/0x4f0^M
Dec 16 19:02:13.229254 [  391.371137]  [<c121f331>] ? xenbus_otherend_changed+0x5c/0x61^M
Dec 16 19:02:13.237246 [  391.371158]  [<c121f6ff>] ? frontend_changed+0xa/0xd^M
Dec 16 19:02:13.237283 [  391.371178]  [<c121e00c>] ? xenwatch_thread+0xfe/0x126^M
Dec 16 19:02:13.245274 [  391.371199]  [<c1076589>] ? autoremove_wake_function+0x0/0x2f^M
Dec 16 19:02:13.245317 [  391.371223]  [<c121df0e>] ? xenwatch_thread+0x0/0x126^M
Dec 16 19:02:13.257249 [  391.371244]  [<c107626f>] ? kthread+0x5f/0x64^M
Dec 16 19:02:13.257283 [  391.371261]  [<c1076210>] ? kthread+0x0/0x64^M
Dec 16 19:02:13.265277 [  391.371283]  [<c102f497>] ? kernel_thread_helper+0x7/0x10^M
Dec 16 19:02:13.265318 [  391.371297] Code: eb fe ff 15 08 dd 66 c1 8b 7d ec 89 ce 89 45 ec 8b 45 ec 89 55 f0 8b 55 f0 0f ac fe 0c c1 e6 05 0f ac d0 0c c1 e0 05 39 c6 74 06 <0f> 0b eb fe 31 db 5a 89 d8 59 5b 5e 5f 5d c3 55 89 e5 53 89 c3 ^M
Dec 16 19:02:13.285270 [  391.371792] EIP: [<c104a052>] vmalloc_sync_one+0x112/0x121 SS:ESP 0069:dfda7e94^M
Dec 16 19:02:13.293255 [  391.371833] ---[ end trace 27f82c4d856810c0 ]---^M

10520/test-amd64-i386-xl

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 20 16:20:10 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 Dec 2011 16: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.xensource.com>)
	id 1Rd2Pq-0002IW-6k; Tue, 20 Dec 2011 16:19:46 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rd2Po-0002I9-Rz
	for xen-devel@lists.xensource.com; Tue, 20 Dec 2011 16:19:45 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1324397927!58065476!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzQwMQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32239 invoked from network); 20 Dec 2011 16:18:48 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Dec 2011 16:18:48 -0000
X-IronPort-AV: E=Sophos;i="4.71,382,1320624000"; 
   d="scan'208";a="9586446"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Dec 2011 16:19:34 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 20 Dec 2011 16:19:34 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
Date: Tue, 20 Dec 2011 16:19:34 +0000
In-Reply-To: <20111220153501.GC13253@andromeda.dapyr.net>
References: <CAOMqctShNFqe47w1orEPMCqvDORy5yxh=Gy33e02fyQYrz4nkw@mail.gmail.com>
	<20111219142943.GD27772@andromeda.dapyr.net>
	<CAOMqctSW87AmM8UTC34_ZwDhipnZUMmxyxiBix+EMAmi7hn1hg@mail.gmail.com>
	<20111219194324.GA29852@andromeda.dapyr.net>
	<1324373842.23729.16.camel@zakaz.uk.xensource.com>
	<CAEBdQ92Oy6=EYYFG_KNMP6raq7S1e_195hFth1etMgpQWdGtsg@mail.gmail.com>
	<1324374914.23729.22.camel@zakaz.uk.xensource.com>
	<CAOMqctTOC_te2QRqFUC45+cq1qCBcQyMdvQcu4Brpw-kAiYnBg@mail.gmail.com>
	<20111220153501.GC13253@andromeda.dapyr.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1324397974.23729.45.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"stefan.bader@canonical.com" <stefan.bader@canonical.com>,
	Michal Suchanek <hramrach@centrum.cz>,
	Jean Guyader <jean.guyader@gmail.com>
Subject: Re: [Xen-devel] UDP checksums broken in Dom0 -> DomU vif transfer
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2011-12-20 at 15:35 +0000, Konrad Rzeszutek Wilk wrote:
> On Tue, Dec 20, 2011 at 12:57:48PM +0100, Michal Suchanek wrote:
> > On 20 December 2011 10:55, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > > On Tue, 2011-12-20 at 09:43 +0000, Jean Guyader wrote:
> > >> On 20 December 2011 10:37, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > >> > The issue is that dom0 does checksum offload which means the checksum is
> > >> > not valid on the domU end, although we know the packet is intact because
> > >> > it never hit the wire.
> > >> >
> > >> > The network stack deals with this because skb->ip_summed is set
> > >> > appropriately but when e.g. raw sockets are used it can ends up exposing
> > >> > getting exposed to userspace.
> > >> >
> > >> > We don't want to do the checksum by default since there are performance
> > >> > gains from avoiding it in the general case. Note that "tx off" turns of
> > >> > TCP and UDP checksum offload.
> > >> >
> > >> > It's not clear where the bug is here, it could be a bug in dhclinet for
> > >> > dropping the packet or perhaps this is something that raw socket driver
> > >> > should be correcting (based on ip_summed) as the packet passes through
> > >> > to userspace?
> > >> >
> > >> > I'm not sure but this might impact native hardware too -- depends on the
> > >> > H/W's handling of the checksum field on RX, you'd hope they mostly just
> > >> > leave it alone, but I'm not sure how e.g. LRO/GRO effects things?
> > >> >
> > >>
> > >> I've seen this issue in the past. I belive the bug is in dhclient.
> > >> dhclient checks the checksum on the packets and drop them if it's wrong.
> > >
> > > Indeed, googling around a bit shows that this dhclient bug affects more
> > > than just Xen, e.g. virtio and even some native hardware appear to be
> > > effected.
> > >
> > > http://marc.info/?l=kvm&m=121882968407525&w=2
> > > https://qa.mandriva.com/show_bug.cgi?id=63320
> > > https://bugs.mageia.org/show_bug.cgi?id=1243
> > > http://pkgs.fedoraproject.org/gitweb/?p=dhcp.git;a=blob_plain;f=dhcp-4.2.2-xen-checksum.patch;hb=HEAD
> > >
> > > The OP didn't say what distro or version of dhclient he was using but I
> > > think the right place to report this would be to the distro since it
> > > appears to be using an out of date dhclient. In the meantime disabling
> > > offload seems like a reasonable local workaround but it is not a fix we
> > > should apply by default.
> > 
> > Thanks for the links
> > 
> > I am running Ubuntu in the DomU.
> 
> Stefan, is this something you could help us with?
> 
> Ian, would it make sense to add all this awesome details in the Xen FAQ
> Wiki part?

Yes, please!

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 20 16:20:10 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 Dec 2011 16: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.xensource.com>)
	id 1Rd2Pq-0002IW-6k; Tue, 20 Dec 2011 16:19:46 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rd2Po-0002I9-Rz
	for xen-devel@lists.xensource.com; Tue, 20 Dec 2011 16:19:45 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1324397927!58065476!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzQwMQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32239 invoked from network); 20 Dec 2011 16:18:48 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Dec 2011 16:18:48 -0000
X-IronPort-AV: E=Sophos;i="4.71,382,1320624000"; 
   d="scan'208";a="9586446"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Dec 2011 16:19:34 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 20 Dec 2011 16:19:34 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
Date: Tue, 20 Dec 2011 16:19:34 +0000
In-Reply-To: <20111220153501.GC13253@andromeda.dapyr.net>
References: <CAOMqctShNFqe47w1orEPMCqvDORy5yxh=Gy33e02fyQYrz4nkw@mail.gmail.com>
	<20111219142943.GD27772@andromeda.dapyr.net>
	<CAOMqctSW87AmM8UTC34_ZwDhipnZUMmxyxiBix+EMAmi7hn1hg@mail.gmail.com>
	<20111219194324.GA29852@andromeda.dapyr.net>
	<1324373842.23729.16.camel@zakaz.uk.xensource.com>
	<CAEBdQ92Oy6=EYYFG_KNMP6raq7S1e_195hFth1etMgpQWdGtsg@mail.gmail.com>
	<1324374914.23729.22.camel@zakaz.uk.xensource.com>
	<CAOMqctTOC_te2QRqFUC45+cq1qCBcQyMdvQcu4Brpw-kAiYnBg@mail.gmail.com>
	<20111220153501.GC13253@andromeda.dapyr.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1324397974.23729.45.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"stefan.bader@canonical.com" <stefan.bader@canonical.com>,
	Michal Suchanek <hramrach@centrum.cz>,
	Jean Guyader <jean.guyader@gmail.com>
Subject: Re: [Xen-devel] UDP checksums broken in Dom0 -> DomU vif transfer
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2011-12-20 at 15:35 +0000, Konrad Rzeszutek Wilk wrote:
> On Tue, Dec 20, 2011 at 12:57:48PM +0100, Michal Suchanek wrote:
> > On 20 December 2011 10:55, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > > On Tue, 2011-12-20 at 09:43 +0000, Jean Guyader wrote:
> > >> On 20 December 2011 10:37, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > >> > The issue is that dom0 does checksum offload which means the checksum is
> > >> > not valid on the domU end, although we know the packet is intact because
> > >> > it never hit the wire.
> > >> >
> > >> > The network stack deals with this because skb->ip_summed is set
> > >> > appropriately but when e.g. raw sockets are used it can ends up exposing
> > >> > getting exposed to userspace.
> > >> >
> > >> > We don't want to do the checksum by default since there are performance
> > >> > gains from avoiding it in the general case. Note that "tx off" turns of
> > >> > TCP and UDP checksum offload.
> > >> >
> > >> > It's not clear where the bug is here, it could be a bug in dhclinet for
> > >> > dropping the packet or perhaps this is something that raw socket driver
> > >> > should be correcting (based on ip_summed) as the packet passes through
> > >> > to userspace?
> > >> >
> > >> > I'm not sure but this might impact native hardware too -- depends on the
> > >> > H/W's handling of the checksum field on RX, you'd hope they mostly just
> > >> > leave it alone, but I'm not sure how e.g. LRO/GRO effects things?
> > >> >
> > >>
> > >> I've seen this issue in the past. I belive the bug is in dhclient.
> > >> dhclient checks the checksum on the packets and drop them if it's wrong.
> > >
> > > Indeed, googling around a bit shows that this dhclient bug affects more
> > > than just Xen, e.g. virtio and even some native hardware appear to be
> > > effected.
> > >
> > > http://marc.info/?l=kvm&m=121882968407525&w=2
> > > https://qa.mandriva.com/show_bug.cgi?id=63320
> > > https://bugs.mageia.org/show_bug.cgi?id=1243
> > > http://pkgs.fedoraproject.org/gitweb/?p=dhcp.git;a=blob_plain;f=dhcp-4.2.2-xen-checksum.patch;hb=HEAD
> > >
> > > The OP didn't say what distro or version of dhclient he was using but I
> > > think the right place to report this would be to the distro since it
> > > appears to be using an out of date dhclient. In the meantime disabling
> > > offload seems like a reasonable local workaround but it is not a fix we
> > > should apply by default.
> > 
> > Thanks for the links
> > 
> > I am running Ubuntu in the DomU.
> 
> Stefan, is this something you could help us with?
> 
> Ian, would it make sense to add all this awesome details in the Xen FAQ
> Wiki part?

Yes, please!

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 20 16:29:28 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 Dec 2011 16: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.xensource.com>)
	id 1Rd2Yy-0002aO-Du; Tue, 20 Dec 2011 16:29:12 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rd2Yx-0002aJ-7q
	for xen-devel@lists.xen.org; Tue, 20 Dec 2011 16:29:11 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1324398545!7968242!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzQwMQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9551 invoked from network); 20 Dec 2011 16:29:05 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Dec 2011 16:29:05 -0000
X-IronPort-AV: E=Sophos;i="4.71,382,1320624000"; 
   d="scan'208";a="9586712"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Dec 2011 16:28:02 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 20 Dec 2011 16:28:02 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 20 Dec 2011 16:28:02 +0000
In-Reply-To: <20208.46342.885854.11320@mariner.uk.xensource.com>
References: <20208.46342.885854.11320@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1324398482.23729.48.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] vmalloc_sync_all crash still happening on some
 machines
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2011-12-20 at 16:17 +0000, Ian Jackson wrote:
> See the crash below, which happened on one of my test machines which
> still aren't in the test pool due to these kind of failures.
> 
> The bug happened immediately after localhost migration of a pv guest.
> 
> The kernel was 2.6.32.46 (as built in flight 10515).

More specifically it seems to be
6bec8b4a4c14095d0b7ce424db9d583c3decae6c from Jeremy's xen/next-2.6.32
branch.

That's actually a commit from September has the test system got stuck
testing that for some reason? There's quite a few new upstream stable
releases in Jeremy's branch. Does it relate somehow to the kernel.org
outage?

I suspect that's a red-herring though since I bet the vmalloc fixes
simply never got backported to this tree.

Ian.

> 
> Ian.
> 
> Dec 16 19:02:13.085286 [  391.370426] ------------[ cut here ]------------^M
> Dec 16 19:02:13.097267 [  391.370440] kernel BUG at arch/x86/mm/fault.c:210!^M
> Dec 16 19:02:13.097303 [  391.370460] invalid opcode: 0000 [#1] SMP ^M
> Dec 16 19:02:13.109253 [  391.370491] last sysfs file: /sys/devices/vif-9-0/uevent^M
> Dec 16 19:02:13.109291 [  391.370503] Modules linked in: e1000e [last unloaded: scsi_wait_scan]^M
> Dec 16 19:02:13.117292 [  391.370575] ^M
> Dec 16 19:02:13.117330 [  391.370597] Pid: 40, comm: xenwatch Not tainted (2.6.32.46 #1) X9SCL/X9SCM^M
> Dec 16 19:02:13.129252 [  391.370613] EIP: 0061:[<c104a052>] EFLAGS: 00010082 CPU: 5^M
> Dec 16 19:02:13.129289 [  391.370633] EIP is at vmalloc_sync_one+0x112/0x121^M
> Dec 16 19:02:13.137260 [  391.370646] EAX: 000050a0 EBX: c1810fd0 ECX: fffff2e3 EDX: 00000000^M
> Dec 16 19:02:13.149240 [  391.370661] ESI: ffffffe0 EDI: d9248fff EBP: dfda7ea8 ESP: dfda7e94^M
> Dec 16 19:02:13.149279 [  391.370677]  DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0069^M
> Dec 16 19:02:13.157316 [  391.370690] Process xenwatch (pid: 40, ti=dfda6000 task=dfce3cc0 task.ti=dfda6000)^M
> Dec 16 19:02:13.169240 [  391.370705] Stack:^M
> Dec 16 19:02:13.169267 [  391.370716]  00285067 00000000 c5c68640 ff400000 c1810fc8 dfda7ec4 c104aa52 c1760204^M
> Dec 16 19:02:13.177285 [  391.370783] <0> c4be6f84 d7411320 df68bb40 dbc2b600 dfda7ed0 c10da2f9 fffffff4 dfda7f28^M
> Dec 16 19:02:13.177352 [  391.370858] <0> c122c1f3 0000032a 00000300 df68bb40 0200006b dce9d3a8 400002c0 c102c23b^M
> Dec 16 19:02:13.189265 [  391.370940] Call Trace:^M
> Dec 16 19:02:13.189298 [  391.370960]  [<c104aa52>] ? vmalloc_sync_all+0x5f/0xc1^M
> Dec 16 19:02:13.197260 [  391.370982]  [<c10da2f9>] ? alloc_vm_area+0x44/0x4b^M
> Dec 16 19:02:13.197296 [  391.371004]  [<c122c1f3>] ? netif_map+0x45/0x24d^M
> Dec 16 19:02:13.209317 [  391.371033]  [<c102c23b>] ? xen_restore_fl_direct_end+0x0/0x1^M
> Dec 16 19:02:13.209352 [  391.371065]  [<c10e40b8>] ? kfree+0xff/0x107^M
> Dec 16 19:02:13.217261 [  391.371097]  [<c121e974>] ? xenbus_scanf+0x35/0x48^M
> Dec 16 19:02:13.217297 [  391.371118]  [<c122b8b8>] ? frontend_changed+0x2a2/0x4f0^M
> Dec 16 19:02:13.229254 [  391.371137]  [<c121f331>] ? xenbus_otherend_changed+0x5c/0x61^M
> Dec 16 19:02:13.237246 [  391.371158]  [<c121f6ff>] ? frontend_changed+0xa/0xd^M
> Dec 16 19:02:13.237283 [  391.371178]  [<c121e00c>] ? xenwatch_thread+0xfe/0x126^M
> Dec 16 19:02:13.245274 [  391.371199]  [<c1076589>] ? autoremove_wake_function+0x0/0x2f^M
> Dec 16 19:02:13.245317 [  391.371223]  [<c121df0e>] ? xenwatch_thread+0x0/0x126^M
> Dec 16 19:02:13.257249 [  391.371244]  [<c107626f>] ? kthread+0x5f/0x64^M
> Dec 16 19:02:13.257283 [  391.371261]  [<c1076210>] ? kthread+0x0/0x64^M
> Dec 16 19:02:13.265277 [  391.371283]  [<c102f497>] ? kernel_thread_helper+0x7/0x10^M
> Dec 16 19:02:13.265318 [  391.371297] Code: eb fe ff 15 08 dd 66 c1 8b 7d ec 89 ce 89 45 ec 8b 45 ec 89 55 f0 8b 55 f0 0f ac fe 0c c1 e6 05 0f ac d0 0c c1 e0 05 39 c6 74 06 <0f> 0b eb fe 31 db 5a 89 d8 59 5b 5e 5f 5d c3 55 89 e5 53 89 c3 ^M
> Dec 16 19:02:13.285270 [  391.371792] EIP: [<c104a052>] vmalloc_sync_one+0x112/0x121 SS:ESP 0069:dfda7e94^M
> Dec 16 19:02:13.293255 [  391.371833] ---[ end trace 27f82c4d856810c0 ]---^M
> 
> 10520/test-amd64-i386-xl
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 20 16:29:28 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 Dec 2011 16: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.xensource.com>)
	id 1Rd2Yy-0002aO-Du; Tue, 20 Dec 2011 16:29:12 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rd2Yx-0002aJ-7q
	for xen-devel@lists.xen.org; Tue, 20 Dec 2011 16:29:11 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1324398545!7968242!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzQwMQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9551 invoked from network); 20 Dec 2011 16:29:05 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Dec 2011 16:29:05 -0000
X-IronPort-AV: E=Sophos;i="4.71,382,1320624000"; 
   d="scan'208";a="9586712"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Dec 2011 16:28:02 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 20 Dec 2011 16:28:02 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 20 Dec 2011 16:28:02 +0000
In-Reply-To: <20208.46342.885854.11320@mariner.uk.xensource.com>
References: <20208.46342.885854.11320@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1324398482.23729.48.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] vmalloc_sync_all crash still happening on some
 machines
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2011-12-20 at 16:17 +0000, Ian Jackson wrote:
> See the crash below, which happened on one of my test machines which
> still aren't in the test pool due to these kind of failures.
> 
> The bug happened immediately after localhost migration of a pv guest.
> 
> The kernel was 2.6.32.46 (as built in flight 10515).

More specifically it seems to be
6bec8b4a4c14095d0b7ce424db9d583c3decae6c from Jeremy's xen/next-2.6.32
branch.

That's actually a commit from September has the test system got stuck
testing that for some reason? There's quite a few new upstream stable
releases in Jeremy's branch. Does it relate somehow to the kernel.org
outage?

I suspect that's a red-herring though since I bet the vmalloc fixes
simply never got backported to this tree.

Ian.

> 
> Ian.
> 
> Dec 16 19:02:13.085286 [  391.370426] ------------[ cut here ]------------^M
> Dec 16 19:02:13.097267 [  391.370440] kernel BUG at arch/x86/mm/fault.c:210!^M
> Dec 16 19:02:13.097303 [  391.370460] invalid opcode: 0000 [#1] SMP ^M
> Dec 16 19:02:13.109253 [  391.370491] last sysfs file: /sys/devices/vif-9-0/uevent^M
> Dec 16 19:02:13.109291 [  391.370503] Modules linked in: e1000e [last unloaded: scsi_wait_scan]^M
> Dec 16 19:02:13.117292 [  391.370575] ^M
> Dec 16 19:02:13.117330 [  391.370597] Pid: 40, comm: xenwatch Not tainted (2.6.32.46 #1) X9SCL/X9SCM^M
> Dec 16 19:02:13.129252 [  391.370613] EIP: 0061:[<c104a052>] EFLAGS: 00010082 CPU: 5^M
> Dec 16 19:02:13.129289 [  391.370633] EIP is at vmalloc_sync_one+0x112/0x121^M
> Dec 16 19:02:13.137260 [  391.370646] EAX: 000050a0 EBX: c1810fd0 ECX: fffff2e3 EDX: 00000000^M
> Dec 16 19:02:13.149240 [  391.370661] ESI: ffffffe0 EDI: d9248fff EBP: dfda7ea8 ESP: dfda7e94^M
> Dec 16 19:02:13.149279 [  391.370677]  DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0069^M
> Dec 16 19:02:13.157316 [  391.370690] Process xenwatch (pid: 40, ti=dfda6000 task=dfce3cc0 task.ti=dfda6000)^M
> Dec 16 19:02:13.169240 [  391.370705] Stack:^M
> Dec 16 19:02:13.169267 [  391.370716]  00285067 00000000 c5c68640 ff400000 c1810fc8 dfda7ec4 c104aa52 c1760204^M
> Dec 16 19:02:13.177285 [  391.370783] <0> c4be6f84 d7411320 df68bb40 dbc2b600 dfda7ed0 c10da2f9 fffffff4 dfda7f28^M
> Dec 16 19:02:13.177352 [  391.370858] <0> c122c1f3 0000032a 00000300 df68bb40 0200006b dce9d3a8 400002c0 c102c23b^M
> Dec 16 19:02:13.189265 [  391.370940] Call Trace:^M
> Dec 16 19:02:13.189298 [  391.370960]  [<c104aa52>] ? vmalloc_sync_all+0x5f/0xc1^M
> Dec 16 19:02:13.197260 [  391.370982]  [<c10da2f9>] ? alloc_vm_area+0x44/0x4b^M
> Dec 16 19:02:13.197296 [  391.371004]  [<c122c1f3>] ? netif_map+0x45/0x24d^M
> Dec 16 19:02:13.209317 [  391.371033]  [<c102c23b>] ? xen_restore_fl_direct_end+0x0/0x1^M
> Dec 16 19:02:13.209352 [  391.371065]  [<c10e40b8>] ? kfree+0xff/0x107^M
> Dec 16 19:02:13.217261 [  391.371097]  [<c121e974>] ? xenbus_scanf+0x35/0x48^M
> Dec 16 19:02:13.217297 [  391.371118]  [<c122b8b8>] ? frontend_changed+0x2a2/0x4f0^M
> Dec 16 19:02:13.229254 [  391.371137]  [<c121f331>] ? xenbus_otherend_changed+0x5c/0x61^M
> Dec 16 19:02:13.237246 [  391.371158]  [<c121f6ff>] ? frontend_changed+0xa/0xd^M
> Dec 16 19:02:13.237283 [  391.371178]  [<c121e00c>] ? xenwatch_thread+0xfe/0x126^M
> Dec 16 19:02:13.245274 [  391.371199]  [<c1076589>] ? autoremove_wake_function+0x0/0x2f^M
> Dec 16 19:02:13.245317 [  391.371223]  [<c121df0e>] ? xenwatch_thread+0x0/0x126^M
> Dec 16 19:02:13.257249 [  391.371244]  [<c107626f>] ? kthread+0x5f/0x64^M
> Dec 16 19:02:13.257283 [  391.371261]  [<c1076210>] ? kthread+0x0/0x64^M
> Dec 16 19:02:13.265277 [  391.371283]  [<c102f497>] ? kernel_thread_helper+0x7/0x10^M
> Dec 16 19:02:13.265318 [  391.371297] Code: eb fe ff 15 08 dd 66 c1 8b 7d ec 89 ce 89 45 ec 8b 45 ec 89 55 f0 8b 55 f0 0f ac fe 0c c1 e6 05 0f ac d0 0c c1 e0 05 39 c6 74 06 <0f> 0b eb fe 31 db 5a 89 d8 59 5b 5e 5f 5d c3 55 89 e5 53 89 c3 ^M
> Dec 16 19:02:13.285270 [  391.371792] EIP: [<c104a052>] vmalloc_sync_one+0x112/0x121 SS:ESP 0069:dfda7e94^M
> Dec 16 19:02:13.293255 [  391.371833] ---[ end trace 27f82c4d856810c0 ]---^M
> 
> 10520/test-amd64-i386-xl
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 20 16:48:10 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 Dec 2011 16:48:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rd2qr-0002uq-54; Tue, 20 Dec 2011 16:47:41 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1Rd2qp-0002ul-LE
	for xen-devel@lists.xensource.com; Tue, 20 Dec 2011 16:47:39 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1324399653!8131061!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzQwMQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15237 invoked from network); 20 Dec 2011 16:47:33 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Dec 2011 16:47:33 -0000
X-IronPort-AV: E=Sophos;i="4.71,382,1320624000"; 
   d="scan'208";a="9587376"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Dec 2011 16:47:33 +0000
Received: from dhcp-3-28.uk.xensource.com (10.80.3.28) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 20 Dec 2011 16:47:33 +0000
Date: Tue, 20 Dec 2011 16:46:49 +0000
From: Anthony PERARD <anthony.perard@citrix.com>
X-X-Sender: anthony@perard.uk.xensource.com
To: Avi Kivity <avi@redhat.com>
In-Reply-To: <4EEE2697.5020602@redhat.com>
Message-ID: <alpine.DEB.2.00.1112201616310.21175@perard.uk.xensource.com>
References: <1323467645-24271-1-git-send-email-anthony.perard@citrix.com>
	<1323467645-24271-2-git-send-email-anthony.perard@citrix.com>
	<4EEA0E72.20105@codemonkey.ws> <4EEE2697.5020602@redhat.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Xen Devel <xen-devel@lists.xensource.com>,
	QEMU-devel <qemu-devel@nongnu.org>,
	Anthony Liguori <anthony@codemonkey.ws>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH V2 1/5] vl.c: Do not save RAM
 state when Xen is used.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Sun, 18 Dec 2011, Avi Kivity wrote:

> On 12/15/2011 05:12 PM, Anthony Liguori wrote:
> > On 12/09/2011 03:54 PM, Anthony PERARD wrote:
> >> In Xen case, the guest RAM is not handle by QEMU, and it is saved by
> >> Xen tools.
> >> So, we just avoid to register the RAM save state handler.
> >>
> >> -    register_savevm_live(NULL, "ram", 0, 4, NULL, ram_save_live, NULL,
> >> -                         ram_load, NULL);
> >> +    if (!xen_enabled()) {
> >> +        register_savevm_live(NULL, "ram", 0, 4, NULL, ram_save_live,
> >> NULL,
> >> +                             ram_load, NULL);
> >> +    }
> >
> > Why don't you just unregister the section in the xen initialization
> > code?  That way we don't have xen_enabled()'s sprinkled all over the
> > place.
>
> It's better to see them up front, having the magical string "ram"
> connect the two is hard to follow.

Agreed. Unregister it in xen code was the first things I've done. But
I've changed to this with the argumment that this tell that the ram is
not saved in QEMU with Xen.

Another things could be done like a parameter to the machine to not save
the RAM.

If you prefere, I can avoid the if(!xen) in vl.c and probably give a
little headache to the one who will want to know why the ram is not in
the state file. :)

Regards,

-- 
Anthony PERARD

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 20 16:48:10 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 Dec 2011 16:48:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rd2qr-0002uq-54; Tue, 20 Dec 2011 16:47:41 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1Rd2qp-0002ul-LE
	for xen-devel@lists.xensource.com; Tue, 20 Dec 2011 16:47:39 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1324399653!8131061!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzQwMQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15237 invoked from network); 20 Dec 2011 16:47:33 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Dec 2011 16:47:33 -0000
X-IronPort-AV: E=Sophos;i="4.71,382,1320624000"; 
   d="scan'208";a="9587376"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Dec 2011 16:47:33 +0000
Received: from dhcp-3-28.uk.xensource.com (10.80.3.28) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 20 Dec 2011 16:47:33 +0000
Date: Tue, 20 Dec 2011 16:46:49 +0000
From: Anthony PERARD <anthony.perard@citrix.com>
X-X-Sender: anthony@perard.uk.xensource.com
To: Avi Kivity <avi@redhat.com>
In-Reply-To: <4EEE2697.5020602@redhat.com>
Message-ID: <alpine.DEB.2.00.1112201616310.21175@perard.uk.xensource.com>
References: <1323467645-24271-1-git-send-email-anthony.perard@citrix.com>
	<1323467645-24271-2-git-send-email-anthony.perard@citrix.com>
	<4EEA0E72.20105@codemonkey.ws> <4EEE2697.5020602@redhat.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Xen Devel <xen-devel@lists.xensource.com>,
	QEMU-devel <qemu-devel@nongnu.org>,
	Anthony Liguori <anthony@codemonkey.ws>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH V2 1/5] vl.c: Do not save RAM
 state when Xen is used.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Sun, 18 Dec 2011, Avi Kivity wrote:

> On 12/15/2011 05:12 PM, Anthony Liguori wrote:
> > On 12/09/2011 03:54 PM, Anthony PERARD wrote:
> >> In Xen case, the guest RAM is not handle by QEMU, and it is saved by
> >> Xen tools.
> >> So, we just avoid to register the RAM save state handler.
> >>
> >> -    register_savevm_live(NULL, "ram", 0, 4, NULL, ram_save_live, NULL,
> >> -                         ram_load, NULL);
> >> +    if (!xen_enabled()) {
> >> +        register_savevm_live(NULL, "ram", 0, 4, NULL, ram_save_live,
> >> NULL,
> >> +                             ram_load, NULL);
> >> +    }
> >
> > Why don't you just unregister the section in the xen initialization
> > code?  That way we don't have xen_enabled()'s sprinkled all over the
> > place.
>
> It's better to see them up front, having the magical string "ram"
> connect the two is hard to follow.

Agreed. Unregister it in xen code was the first things I've done. But
I've changed to this with the argumment that this tell that the ram is
not saved in QEMU with Xen.

Another things could be done like a parameter to the machine to not save
the RAM.

If you prefere, I can avoid the if(!xen) in vl.c and probably give a
little headache to the one who will want to know why the ram is not in
the state file. :)

Regards,

-- 
Anthony PERARD

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 20 16:52:08 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 Dec 2011 16:52:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rd2um-000329-Ps; Tue, 20 Dec 2011 16:51:44 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Rd2ul-00031s-Jv
	for xen-devel@lists.xen.org; Tue, 20 Dec 2011 16:51:43 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1324399897!6289234!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzQwMQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16572 invoked from network); 20 Dec 2011 16:51:37 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Dec 2011 16:51:37 -0000
X-IronPort-AV: E=Sophos;i="4.71,383,1320624000"; 
   d="scan'208";a="9587494"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Dec 2011 16:51:37 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 20 Dec 2011 16:51:37 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Rd2ue-0004w3-L0; Tue, 20 Dec 2011 16:51:36 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rd2ue-00075R-Ib;
	Tue, 20 Dec 2011 16:51:36 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20208.48408.563986.412467@mariner.uk.xensource.com>
Date: Tue, 20 Dec 2011 16:51:36 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1324398482.23729.48.camel@zakaz.uk.xensource.com>
References: <20208.46342.885854.11320@mariner.uk.xensource.com>
	<1324398482.23729.48.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] vmalloc_sync_all crash still happening on some
 machines
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("Re: [Xen-devel] vmalloc_sync_all crash still happening on some machines"):
> More specifically it seems to be
> 6bec8b4a4c14095d0b7ce424db9d583c3decae6c from Jeremy's xen/next-2.6.32
> branch.

My script is still pulling from Jeremy's github.  I see that the tree
on git.kernel.org has many new changesets so I'll switch back to that.
I guess I naively assumed that having established two trees Jeremy
might push to both of them...

> I suspect that's a red-herring though since I bet the vmalloc fixes
> simply never got backported to this tree.

Yes, it looks like they didn't.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 20 16:52:08 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 Dec 2011 16:52:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rd2um-000329-Ps; Tue, 20 Dec 2011 16:51:44 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Rd2ul-00031s-Jv
	for xen-devel@lists.xen.org; Tue, 20 Dec 2011 16:51:43 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1324399897!6289234!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzQwMQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16572 invoked from network); 20 Dec 2011 16:51:37 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Dec 2011 16:51:37 -0000
X-IronPort-AV: E=Sophos;i="4.71,383,1320624000"; 
   d="scan'208";a="9587494"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Dec 2011 16:51:37 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 20 Dec 2011 16:51:37 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Rd2ue-0004w3-L0; Tue, 20 Dec 2011 16:51:36 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rd2ue-00075R-Ib;
	Tue, 20 Dec 2011 16:51:36 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20208.48408.563986.412467@mariner.uk.xensource.com>
Date: Tue, 20 Dec 2011 16:51:36 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1324398482.23729.48.camel@zakaz.uk.xensource.com>
References: <20208.46342.885854.11320@mariner.uk.xensource.com>
	<1324398482.23729.48.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] vmalloc_sync_all crash still happening on some
 machines
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("Re: [Xen-devel] vmalloc_sync_all crash still happening on some machines"):
> More specifically it seems to be
> 6bec8b4a4c14095d0b7ce424db9d583c3decae6c from Jeremy's xen/next-2.6.32
> branch.

My script is still pulling from Jeremy's github.  I see that the tree
on git.kernel.org has many new changesets so I'll switch back to that.
I guess I naively assumed that having established two trees Jeremy
might push to both of them...

> I suspect that's a red-herring though since I bet the vmalloc fixes
> simply never got backported to this tree.

Yes, it looks like they didn't.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 20 17:15:38 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 Dec 2011 17:15:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rd3HR-0003qg-OE; Tue, 20 Dec 2011 17:15:09 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rd3HR-0003qX-3b
	for xen-devel@lists.xen.org; Tue, 20 Dec 2011 17:15:09 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1324401267!51400592!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzQwMQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11059 invoked from network); 20 Dec 2011 17:14:27 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Dec 2011 17:14:27 -0000
X-IronPort-AV: E=Sophos;i="4.71,383,1320624000"; 
   d="scan'208";a="9588106"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Dec 2011 17:15:08 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 20 Dec 2011 17:15:07 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 20 Dec 2011 17:15:07 +0000
In-Reply-To: <20208.48408.563986.412467@mariner.uk.xensource.com>
References: <20208.46342.885854.11320@mariner.uk.xensource.com>
	<1324398482.23729.48.camel@zakaz.uk.xensource.com>
	<20208.48408.563986.412467@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1324401307.23729.66.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	David Vrabel <david.vrabel@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] vmalloc_sync_all crash still happening on some
 machines
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2011-12-20 at 16:51 +0000, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] vmalloc_sync_all crash still happening on some machines"):
> > More specifically it seems to be
> > 6bec8b4a4c14095d0b7ce424db9d583c3decae6c from Jeremy's xen/next-2.6.32
> > branch.
> 
> My script is still pulling from Jeremy's github.  I see that the tree
> on git.kernel.org has many new changesets so I'll switch back to that.
> I guess I naively assumed that having established two trees Jeremy
> might push to both of them...
> 
> > I suspect that's a red-herring though since I bet the vmalloc fixes
> > simply never got backported to this tree.
> 
> Yes, it looks like they didn't.

Looking at the tree the vmalloc_sync_all() in alloc_vm_area() is present
and has been for ages. The upstream stuff I was thinking of was David
Vrabel's work to make the sync unnecessary.

The only difference in vmalloc_sync_all seems to be that 2.6.32 uses
spin_lock_irqsave() while upstream uses just spin_lock() which doesn't
seem likely to make a difference.

The actual bug you are seeing is hitting the                 
	BUG_ON(pmd_page(*pmd) != pmd_page(*pmd_k))
towards the end of vmalloc_sync_one(). David, do you remember from when
you were digging into this stuff what it actually means?

I suppose we could backport the stuff to make vmalloc_sync_all
unnecessary, but I guess there'd be no guarantee it would help since the
root cause isn't really understood.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 20 17:15:38 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 Dec 2011 17:15:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rd3HR-0003qg-OE; Tue, 20 Dec 2011 17:15:09 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rd3HR-0003qX-3b
	for xen-devel@lists.xen.org; Tue, 20 Dec 2011 17:15:09 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1324401267!51400592!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzQwMQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11059 invoked from network); 20 Dec 2011 17:14:27 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Dec 2011 17:14:27 -0000
X-IronPort-AV: E=Sophos;i="4.71,383,1320624000"; 
   d="scan'208";a="9588106"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Dec 2011 17:15:08 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 20 Dec 2011 17:15:07 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 20 Dec 2011 17:15:07 +0000
In-Reply-To: <20208.48408.563986.412467@mariner.uk.xensource.com>
References: <20208.46342.885854.11320@mariner.uk.xensource.com>
	<1324398482.23729.48.camel@zakaz.uk.xensource.com>
	<20208.48408.563986.412467@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1324401307.23729.66.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	David Vrabel <david.vrabel@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] vmalloc_sync_all crash still happening on some
 machines
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2011-12-20 at 16:51 +0000, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] vmalloc_sync_all crash still happening on some machines"):
> > More specifically it seems to be
> > 6bec8b4a4c14095d0b7ce424db9d583c3decae6c from Jeremy's xen/next-2.6.32
> > branch.
> 
> My script is still pulling from Jeremy's github.  I see that the tree
> on git.kernel.org has many new changesets so I'll switch back to that.
> I guess I naively assumed that having established two trees Jeremy
> might push to both of them...
> 
> > I suspect that's a red-herring though since I bet the vmalloc fixes
> > simply never got backported to this tree.
> 
> Yes, it looks like they didn't.

Looking at the tree the vmalloc_sync_all() in alloc_vm_area() is present
and has been for ages. The upstream stuff I was thinking of was David
Vrabel's work to make the sync unnecessary.

The only difference in vmalloc_sync_all seems to be that 2.6.32 uses
spin_lock_irqsave() while upstream uses just spin_lock() which doesn't
seem likely to make a difference.

The actual bug you are seeing is hitting the                 
	BUG_ON(pmd_page(*pmd) != pmd_page(*pmd_k))
towards the end of vmalloc_sync_one(). David, do you remember from when
you were digging into this stuff what it actually means?

I suppose we could backport the stuff to make vmalloc_sync_all
unnecessary, but I guess there'd be no guarantee it would help since the
root cause isn't really understood.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 20 17:26:54 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 Dec 2011 17: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.xensource.com>)
	id 1Rd3SO-0004Hh-Um; Tue, 20 Dec 2011 17:26:28 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Rd3SN-0004HT-0e
	for xen-devel@lists.xen.org; Tue, 20 Dec 2011 17:26:27 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1324401980!6293654!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2040 invoked from network); 20 Dec 2011 17:26:20 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-13.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 20 Dec 2011 17:26:20 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 20 Dec 2011 17:26:19 +0000
Message-Id: <4EF0D3820200007800069349@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 20 Dec 2011 17:27:14 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>,
	"Ian Jackson" <Ian.Jackson@eu.citrix.com>
References: <20208.46342.885854.11320@mariner.uk.xensource.com>
	<1324398482.23729.48.camel@zakaz.uk.xensource.com>
	<20208.48408.563986.412467@mariner.uk.xensource.com>
	<1324401307.23729.66.camel@zakaz.uk.xensource.com>
In-Reply-To: <1324401307.23729.66.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	David Vrabel <david.vrabel@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] vmalloc_sync_all crash still happening on some
 machines
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 20.12.11 at 18:15, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> The actual bug you are seeing is hitting the                 
> 	BUG_ON(pmd_page(*pmd) != pmd_page(*pmd_k))
> towards the end of vmalloc_sync_one(). David, do you remember from when
> you were digging into this stuff what it actually means?

This means that the pmd entry in the reference page tables (init_mm's)
is referencing a different page than the (non-blank) one in the page
table being updated, i.e. some race occurred that allowed two distinct
page tables to be allocated for the same kernel address (range).

If this is reproducible in some way, printing the entries (or really just
their PFNs/MFNs) might help understand what is going on here
(assuming that such a race can be expected to not really exist in
this old and mature a kernel).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 20 17:26:54 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 Dec 2011 17: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.xensource.com>)
	id 1Rd3SO-0004Hh-Um; Tue, 20 Dec 2011 17:26:28 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Rd3SN-0004HT-0e
	for xen-devel@lists.xen.org; Tue, 20 Dec 2011 17:26:27 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1324401980!6293654!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2040 invoked from network); 20 Dec 2011 17:26:20 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-13.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 20 Dec 2011 17:26:20 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 20 Dec 2011 17:26:19 +0000
Message-Id: <4EF0D3820200007800069349@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 20 Dec 2011 17:27:14 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>,
	"Ian Jackson" <Ian.Jackson@eu.citrix.com>
References: <20208.46342.885854.11320@mariner.uk.xensource.com>
	<1324398482.23729.48.camel@zakaz.uk.xensource.com>
	<20208.48408.563986.412467@mariner.uk.xensource.com>
	<1324401307.23729.66.camel@zakaz.uk.xensource.com>
In-Reply-To: <1324401307.23729.66.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	David Vrabel <david.vrabel@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] vmalloc_sync_all crash still happening on some
 machines
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 20.12.11 at 18:15, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> The actual bug you are seeing is hitting the                 
> 	BUG_ON(pmd_page(*pmd) != pmd_page(*pmd_k))
> towards the end of vmalloc_sync_one(). David, do you remember from when
> you were digging into this stuff what it actually means?

This means that the pmd entry in the reference page tables (init_mm's)
is referencing a different page than the (non-blank) one in the page
table being updated, i.e. some race occurred that allowed two distinct
page tables to be allocated for the same kernel address (range).

If this is reproducible in some way, printing the entries (or really just
their PFNs/MFNs) might help understand what is going on here
(assuming that such a race can be expected to not really exist in
this old and mature a kernel).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 20 17:30:04 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 Dec 2011 17:30:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rd3VT-0004PO-I8; Tue, 20 Dec 2011 17:29:39 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Rd3VR-0004Om-S1
	for xen-devel@lists.xensource.com; Tue, 20 Dec 2011 17:29:38 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1324402171!7974853!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzQwMQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30342 invoked from network); 20 Dec 2011 17:29:32 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Dec 2011 17:29:32 -0000
X-IronPort-AV: E=Sophos;i="4.71,383,1320624000"; 
   d="scan'208";a="9588483"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Dec 2011 17:29:06 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 20 Dec 2011 17:29:05 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Rd3Uv-00058O-RV; Tue, 20 Dec 2011 17:29:05 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rd3Uv-000788-QF;
	Tue, 20 Dec 2011 17:29:05 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20208.50657.799146.57017@mariner.uk.xensource.com>
Date: Tue, 20 Dec 2011 17:29:05 +0000
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <20111220141612.GA25139@konrad-lan>
References: <4EEA4877.8010307@canonical.com>
	<20111215193942.GA7640@andromeda.dapyr.net>
	<20111216113300.GA4854@aepfle.de>
	<1324375910.23729.31.camel@zakaz.uk.xensource.com>
	<20111220131533.GA7800@aepfle.de>
	<20111220141612.GA25139@konrad-lan>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Olaf Hering <olaf@aepfle.de>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefan Bader <stefan.bader@canonical.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] xenbus and the message of doom
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Konrad Rzeszutek Wilk writes ("Re: [Xen-devel] xenbus and the message of doom"):
> Sorry Olaf, have to revert that commit.

I agree.  When we introduced it we weren't aware that most existing
implementations of xenstored simply ignore unknown commands rather
than replying with an error.  If we had known this we would not have
approved Olaf's patch.

That they ignore unknown commands is of course a bug but expecting
everyone to update is no good.  Really the best approach would be some
kind of discovery mechanism.

Maybe we should have a special path @xenstore/fail_unknown_commands
which you could read, or something.  But this time we should try it
against old implementations.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 20 17:30:04 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 Dec 2011 17:30:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rd3VT-0004PO-I8; Tue, 20 Dec 2011 17:29:39 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Rd3VR-0004Om-S1
	for xen-devel@lists.xensource.com; Tue, 20 Dec 2011 17:29:38 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1324402171!7974853!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzQwMQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30342 invoked from network); 20 Dec 2011 17:29:32 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Dec 2011 17:29:32 -0000
X-IronPort-AV: E=Sophos;i="4.71,383,1320624000"; 
   d="scan'208";a="9588483"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Dec 2011 17:29:06 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 20 Dec 2011 17:29:05 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Rd3Uv-00058O-RV; Tue, 20 Dec 2011 17:29:05 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rd3Uv-000788-QF;
	Tue, 20 Dec 2011 17:29:05 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20208.50657.799146.57017@mariner.uk.xensource.com>
Date: Tue, 20 Dec 2011 17:29:05 +0000
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <20111220141612.GA25139@konrad-lan>
References: <4EEA4877.8010307@canonical.com>
	<20111215193942.GA7640@andromeda.dapyr.net>
	<20111216113300.GA4854@aepfle.de>
	<1324375910.23729.31.camel@zakaz.uk.xensource.com>
	<20111220131533.GA7800@aepfle.de>
	<20111220141612.GA25139@konrad-lan>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Olaf Hering <olaf@aepfle.de>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefan Bader <stefan.bader@canonical.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] xenbus and the message of doom
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Konrad Rzeszutek Wilk writes ("Re: [Xen-devel] xenbus and the message of doom"):
> Sorry Olaf, have to revert that commit.

I agree.  When we introduced it we weren't aware that most existing
implementations of xenstored simply ignore unknown commands rather
than replying with an error.  If we had known this we would not have
approved Olaf's patch.

That they ignore unknown commands is of course a bug but expecting
everyone to update is no good.  Really the best approach would be some
kind of discovery mechanism.

Maybe we should have a special path @xenstore/fail_unknown_commands
which you could read, or something.  But this time we should try it
against old implementations.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 20 17:31:15 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 Dec 2011 17:31:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rd3Wi-0004Wy-1c; Tue, 20 Dec 2011 17:30:56 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Rd3Wg-0004WW-Le
	for xen-devel@lists.xen.org; Tue, 20 Dec 2011 17:30:54 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1324402248!8043950!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzQwMQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2229 invoked from network); 20 Dec 2011 17:30:48 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Dec 2011 17:30:48 -0000
X-IronPort-AV: E=Sophos;i="4.71,383,1320624000"; 
   d="scan'208";a="9588498"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Dec 2011 17:29:45 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 20 Dec 2011 17:29:45 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Rd3VZ-00058c-CX; Tue, 20 Dec 2011 17:29:45 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rd3VZ-00078M-BQ;
	Tue, 20 Dec 2011 17:29:45 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20208.50697.342324.740883@mariner.uk.xensource.com>
Date: Tue, 20 Dec 2011 17:29:45 +0000
To: Jan Beulich <JBeulich@suse.com>
In-Reply-To: <4EF0D3820200007800069349@nat28.tlf.novell.com>
References: <20208.46342.885854.11320@mariner.uk.xensource.com>
	<1324398482.23729.48.camel@zakaz.uk.xensource.com>
	<20208.48408.563986.412467@mariner.uk.xensource.com>
	<1324401307.23729.66.camel@zakaz.uk.xensource.com>
	<4EF0D3820200007800069349@nat28.tlf.novell.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	David Vrabel <david.vrabel@citrix.com>
Subject: Re: [Xen-devel] vmalloc_sync_all crash still happening on some
 machines
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Jan Beulich writes ("Re: [Xen-devel] vmalloc_sync_all crash still happening on some machines"):
> If this is reproducible in some way, printing the entries (or really just
> their PFNs/MFNs) might help understand what is going on here
> (assuming that such a race can be expected to not really exist in
> this old and mature a kernel).

It does seem quite reproducible.  I'd be happy to test patches etc.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 20 17:31:15 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 Dec 2011 17:31:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rd3Wi-0004Wy-1c; Tue, 20 Dec 2011 17:30:56 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Rd3Wg-0004WW-Le
	for xen-devel@lists.xen.org; Tue, 20 Dec 2011 17:30:54 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1324402248!8043950!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzQwMQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2229 invoked from network); 20 Dec 2011 17:30:48 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Dec 2011 17:30:48 -0000
X-IronPort-AV: E=Sophos;i="4.71,383,1320624000"; 
   d="scan'208";a="9588498"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Dec 2011 17:29:45 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 20 Dec 2011 17:29:45 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Rd3VZ-00058c-CX; Tue, 20 Dec 2011 17:29:45 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rd3VZ-00078M-BQ;
	Tue, 20 Dec 2011 17:29:45 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20208.50697.342324.740883@mariner.uk.xensource.com>
Date: Tue, 20 Dec 2011 17:29:45 +0000
To: Jan Beulich <JBeulich@suse.com>
In-Reply-To: <4EF0D3820200007800069349@nat28.tlf.novell.com>
References: <20208.46342.885854.11320@mariner.uk.xensource.com>
	<1324398482.23729.48.camel@zakaz.uk.xensource.com>
	<20208.48408.563986.412467@mariner.uk.xensource.com>
	<1324401307.23729.66.camel@zakaz.uk.xensource.com>
	<4EF0D3820200007800069349@nat28.tlf.novell.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	David Vrabel <david.vrabel@citrix.com>
Subject: Re: [Xen-devel] vmalloc_sync_all crash still happening on some
 machines
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Jan Beulich writes ("Re: [Xen-devel] vmalloc_sync_all crash still happening on some machines"):
> If this is reproducible in some way, printing the entries (or really just
> their PFNs/MFNs) might help understand what is going on here
> (assuming that such a race can be expected to not really exist in
> this old and mature a kernel).

It does seem quite reproducible.  I'd be happy to test patches etc.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 20 17:48:53 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 Dec 2011 17:48:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rd3nj-0004ru-NN; Tue, 20 Dec 2011 17:48:31 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1Rd3ni-0004rp-Al
	for xen-devel@lists.xensource.com; Tue, 20 Dec 2011 17:48:31 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-16.tower-182.messagelabs.com!1324403300!722602!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=1.1 required=7.0 tests=BODY_RANDOM_LONG,DIET_1
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27957 invoked from network); 20 Dec 2011 17:48:21 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-16.tower-182.messagelabs.com with SMTP;
	20 Dec 2011 17:48:21 -0000
Received: from [62.94.181.91] (account d.faggioli@sssup.it HELO [192.168.0.40])
	by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 74061268; Tue, 20 Dec 2011 18:48:18 +0100
Message-ID: <1324403256.2632.0.camel@Solace>
From: Dario Faggioli <raistlin@linux.it>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Tue, 20 Dec 2011 18:47:36 +0100
X-Mailer: Evolution 3.2.2-1 
Mime-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>, Keir Fraser <keir@xen.org>
Subject: [Xen-devel] sedf: remove useless tracing printk and harmonize
	comments style.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============4953755209351780878=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--===============4953755209351780878==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-4GhoPkvT2knwTpwLdibp"


--=-4GhoPkvT2knwTpwLdibp
Content-Type: multipart/mixed; boundary="=-3p5/0djGq6n5G1gGRftX"


--=-3p5/0djGq6n5G1gGRftX
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

sched_sedf.c used o have its own mechanism for producing tracing-alike
kind of information (domain block, wakeup, etc.). Nowadays, with an even
not so high number of pCPUs/vCPUs, just trying to enable this makes
the serial console completely unusable, produces tons of very hard to
parse and interpreet logging and can easily livelock Dom0. Moreover,
pretty much the same result this is struggling to get to, is better
achieved by enabling the scheduler-related tracing events, as
it is for the other schedulers (say, credit or credit2).

For all these reasons, this removes that machinery completely. While at
it, check in some cosmetics that harmonize the comments withim themself
and with the rest of the code base.

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>

diff -r 17d99691e0ec xen/common/sched_sedf.c
--- a/xen/common/sched_sedf.c	Tue Dec 20 16:39:56 2011 +0000
+++ b/xen/common/sched_sedf.c	Tue Dec 20 17:32:52 2011 +0000
@@ -13,14 +13,6 @@
 #include <xen/time.h>
 #include <xen/errno.h>
=20
-/*verbosity settings*/
-#define SEDFLEVEL 0
-#define PRINT(_f, _a...)                        \
-    do {                                        \
-        if ( (_f) <=3D SEDFLEVEL )                \
-            printk(_a );                        \
-    } while ( 0 )
-
 #define SEDF_CPUONLINE(_pool)                                             =
\
     (((_pool) =3D=3D NULL) ? &cpupool_free_cpus : (_pool)->cpu_valid)
=20
@@ -66,34 +58,35 @@ struct sedf_vcpu_info {
     struct list_head list;
     struct list_head extralist[2];
 =20
-    /*Parameters for EDF*/
-    s_time_t  period;  /*=3D(relative deadline)*/
-    s_time_t  slice;  /*=3Dworst case execution time*/
+    /* Parameters for EDF */
+    s_time_t  period;  /* =3D(relative deadline) */
+    s_time_t  slice;   /* =3Dworst case execution time */
 =20
-    /*Advaced Parameters*/
-    /*Latency Scaling*/
+    /* Advaced Parameters */
+
+    /* Latency Scaling */
     s_time_t  period_orig;
     s_time_t  slice_orig;
     s_time_t  latency;
 =20
-    /*status of domain*/
+    /* Status of domain */
     int       status;
-    /*weights for "Scheduling for beginners/ lazy/ etc." ;)*/
+    /* Weights for "Scheduling for beginners/ lazy/ etc." ;) */
     short     weight;
     short     extraweight;
-    /*Bookkeeping*/
+    /* Bookkeeping */
     s_time_t  deadl_abs;
     s_time_t  sched_start_abs;
     s_time_t  cputime;
-    /* times the domain un-/blocked */
+    /* Times the domain un-/blocked */
     s_time_t  block_abs;
     s_time_t  unblock_abs;
 =20
-    /*scores for {util, block penalty}-weighted extratime distribution*/
+    /* Scores for {util, block penalty}-weighted extratime distribution */
     int   score[2];
     s_time_t  short_block_lost_tot;
 =20
-    /*Statistics*/
+    /* Statistics */
     s_time_t  extra_time_tot;
=20
 #ifdef SEDF_STATS
@@ -158,18 +151,16 @@ static inline void extraq_del(struct vcp
 {
     struct list_head *list =3D EXTRALIST(d,i);
     ASSERT(extraq_on(d,i));
-    PRINT(3, "Removing domain %i.%i from L%i extraq\n",
-          d->domain->domain_id, d->vcpu_id, i);
     list_del(list);
     list->next =3D NULL;
     ASSERT(!extraq_on(d, i));
 }
=20
-/* adds a domain to the queue of processes which are aware of extra time. =
List
-   is sorted by score, where a lower score means higher priority for an ex=
tra
-   slice. It also updates the score, by simply subtracting a fixed value f=
rom
-   each entry, in order to avoid overflow. The algorithm works by simply
-   charging each domain that recieved extratime with an inverse of its wei=
ght.
+/* Adds a domain to the queue of processes which are aware of extra time. =
List
+ * is sorted by score, where a lower score means higher priority for an ex=
tra
+ * slice. It also updates the score, by simply subtracting a fixed value f=
rom
+ * each entry, in order to avoid overflow. The algorithm works by simply
+ * charging each domain that recieved extratime with an inverse of its wei=
ght.
  */=20
 static inline void extraq_add_sort_update(struct vcpu *d, int i, int sub)
 {
@@ -178,13 +169,7 @@ static inline void extraq_add_sort_updat
 =20
     ASSERT(!extraq_on(d,i));
=20
-    PRINT(3, "Adding domain %i.%i (score=3D %i, short_pen=3D %"PRIi64")"
-          " to L%i extraq\n",
-          d->domain->domain_id, d->vcpu_id, EDOM_INFO(d)->score[i],
-          EDOM_INFO(d)->short_block_lost_tot, i);
-
-    /*
-     * Iterate through all elements to find our "hole" and on our way
+    /* Iterate through all elements to find our "hole" and on our way
      * update all the other scores.
      */
     list_for_each ( cur, EXTRAQ(d->processor, i) )
@@ -193,25 +178,18 @@ static inline void extraq_add_sort_updat
         curinf->score[i] -=3D sub;
         if ( EDOM_INFO(d)->score[i] < curinf->score[i] )
             break;
-        PRINT(4,"\tbehind domain %i.%i (score=3D %i)\n",
-              curinf->vcpu->domain->domain_id,
-              curinf->vcpu->vcpu_id, curinf->score[i]);
     }
=20
-    /* cur now contains the element, before which we'll enqueue. */
-    PRINT(3, "\tlist_add to %p\n", cur->prev);
+    /* cur now contains the element, before which we'll enqueue */
     list_add(EXTRALIST(d,i),cur->prev);
 =20
-    /* Continue updating the extraq. */
+    /* Continue updating the extraq */
     if ( (cur !=3D EXTRAQ(d->processor,i)) && sub )
     {
         for ( cur =3D cur->next; cur !=3D EXTRAQ(d->processor,i); cur =3D =
cur->next )
         {
             curinf =3D list_entry(cur,struct sedf_vcpu_info, extralist[i])=
;
             curinf->score[i] -=3D sub;
-            PRINT(4, "\tupdating domain %i.%i (score=3D %u)\n",
-                  curinf->vcpu->domain->domain_id,=20
-                  curinf->vcpu->vcpu_id, curinf->score[i]);
         }
     }
=20
@@ -221,29 +199,14 @@ static inline void extraq_check(struct v
 {
     if ( extraq_on(d, EXTRA_UTIL_Q) )
     {
-        PRINT(2,"Dom %i.%i is on L1 extraQ\n",
-              d->domain->domain_id, d->vcpu_id);
-
         if ( !(EDOM_INFO(d)->status & EXTRA_AWARE) &&
              !extra_runs(EDOM_INFO(d)) )
-        {
             extraq_del(d, EXTRA_UTIL_Q);
-            PRINT(2,"Removed dom %i.%i from L1 extraQ\n",
-                  d->domain->domain_id, d->vcpu_id);
-        }
     }
     else
     {
-        PRINT(2, "Dom %i.%i is NOT on L1 extraQ\n",
-              d->domain->domain_id,
-              d->vcpu_id);
-
         if ( (EDOM_INFO(d)->status & EXTRA_AWARE) && sedf_runnable(d) )
-        {
             extraq_add_sort_update(d, EXTRA_UTIL_Q, 0);
-            PRINT(2,"Added dom %i.%i to L1 extraQ\n",
-                  d->domain->domain_id, d->vcpu_id);
-        }
     }
 }
=20
@@ -252,7 +215,7 @@ static inline void extraq_check_add_unbl
     struct sedf_vcpu_info *inf =3D EDOM_INFO(d);
=20
     if ( inf->status & EXTRA_AWARE )
-        /* Put on the weighted extraq without updating any scores. */
+        /* Put on the weighted extraq without updating any scores */
         extraq_add_sort_update(d, EXTRA_UTIL_Q, 0);
 }
=20
@@ -265,8 +228,6 @@ static inline void __del_from_queue(stru
 {
     struct list_head *list =3D LIST(d);
     ASSERT(__task_on_queue(d));
-    PRINT(3,"Removing domain %i.%i (bop=3D %"PRIu64") from runq/waitq\n",
-          d->domain->domain_id, d->vcpu_id, PERIOD_BEGIN(EDOM_INFO(d)));
     list_del(list);
     list->next =3D NULL;
     ASSERT(!__task_on_queue(d));
@@ -279,13 +240,12 @@ static inline void list_insert_sort(
 {
     struct list_head     *cur;
=20
-    /* Iterate through all elements to find our "hole". */
+    /* Iterate through all elements to find our "hole" */
     list_for_each( cur, list )
         if ( comp(element, cur) < 0 )
             break;
=20
-    /* cur now contains the element, before which we'll enqueue. */
-    PRINT(3,"\tlist_add to %p\n",cur->prev);
+    /* cur now contains the element, before which we'll enqueue */
     list_add(element, cur->prev);
 }
=20
@@ -303,30 +263,26 @@ static int name##_comp(struct list_head*
         return 1;                                                       \
 }
=20
-/* adds a domain to the queue of processes which wait for the beginning of=
 the
-   next period; this list is therefore sortet by this time, which is simpl=
y
-   absol. deadline - period
+/* Adds a domain to the queue of processes which wait for the beginning of=
 the
+ * next period; this list is therefore sortet by this time, which is simpl=
y
+ * absol. deadline - period.
  */=20
 DOMAIN_COMPARER(waitq, list, PERIOD_BEGIN(d1), PERIOD_BEGIN(d2));
 static inline void __add_to_waitqueue_sort(struct vcpu *v)
 {
     ASSERT(!__task_on_queue(v));
-    PRINT(3,"Adding domain %i.%i (bop=3D %"PRIu64") to waitq\n",
-          v->domain->domain_id, v->vcpu_id, PERIOD_BEGIN(EDOM_INFO(v)));
     list_insert_sort(WAITQ(v->processor), LIST(v), waitq_comp);
     ASSERT(__task_on_queue(v));
 }
=20
-/* adds a domain to the queue of processes which have started their curren=
t
-   period and are runnable (i.e. not blocked, dieing,...). The first eleme=
nt
-   on this list is running on the processor, if the list is empty the idle
-   task will run. As we are implementing EDF, this list is sorted by deadl=
ines.
+/* Adds a domain to the queue of processes which have started their curren=
t
+ * period and are runnable (i.e. not blocked, dieing,...). The first eleme=
nt
+ * on this list is running on the processor, if the list is empty the idle
+ * task will run. As we are implementing EDF, this list is sorted by deadl=
ines.
  */=20
 DOMAIN_COMPARER(runq, list, d1->deadl_abs, d2->deadl_abs);
 static inline void __add_to_runqueue_sort(struct vcpu *v)
 {
-    PRINT(3,"Adding domain %i.%i (deadl=3D %"PRIu64") to runq\n",
-          v->domain->domain_id, v->vcpu_id, EDOM_INFO(v)->deadl_abs);
     list_insert_sort(RUNQ(v->processor), LIST(v), runq_comp);
 }
=20
@@ -445,22 +401,21 @@ static int sedf_pick_cpu(const struct sc
     return cpumask_first(&online_affinity);
 }
=20
-/*
- * Handles the rescheduling & bookkeeping of domains running in their
+
+/* Handles the rescheduling & bookkeeping of domains running in their
  * guaranteed timeslice.
  */
 static void desched_edf_dom(s_time_t now, struct vcpu* d)
 {
     struct sedf_vcpu_info* inf =3D EDOM_INFO(d);
=20
-    /* Current domain is running in real time mode. */
+    /* Current domain is running in real time mode */
     ASSERT(__task_on_queue(d));
=20
-    /* Update the domain's cputime. */
+    /* Update the domain's cputime */
     inf->cputime +=3D now - inf->sched_start_abs;
=20
-    /*
-     * Scheduling decisions which don't remove the running domain from the
+    /* Scheduling decisions which don't remove the running domain from the
      * runq.=20
      */
     if ( (inf->cputime < inf->slice) && sedf_runnable(d) )
@@ -468,8 +423,7 @@ static void desched_edf_dom(s_time_t now
  =20
     __del_from_queue(d);
  =20
-    /*
-     * Manage bookkeeping (i.e. calculate next deadline, memorise
+    /* Manage bookkeeping (i.e. calculate next deadline, memorise
      * overrun-time of slice) of finished domains.
      */
     if ( inf->cputime >=3D inf->slice )
@@ -478,30 +432,30 @@ static void desched_edf_dom(s_time_t now
  =20
         if ( inf->period < inf->period_orig )
         {
-            /* This domain runs in latency scaling or burst mode. */
+            /* This domain runs in latency scaling or burst mode */
             inf->period *=3D 2;
             inf->slice  *=3D 2;
             if ( (inf->period > inf->period_orig) ||
                  (inf->slice > inf->slice_orig) )
             {
-                /* Reset slice and period. */
+                /* Reset slice and period */
                 inf->period =3D inf->period_orig;
                 inf->slice =3D inf->slice_orig;
             }
         }
=20
-        /* Set next deadline. */
+        /* Set next deadline */
         inf->deadl_abs +=3D inf->period;
     }
 =20
-    /* Add a runnable domain to the waitqueue. */
+    /* Add a runnable domain to the waitqueue */
     if ( sedf_runnable(d) )
     {
         __add_to_waitqueue_sort(d);
     }
     else
     {
-        /* We have a blocked realtime task -> remove it from exqs too. */
+        /* We have a blocked realtime task -> remove it from exqs too */
         if ( extraq_on(d, EXTRA_PEN_Q) )
             extraq_del(d, EXTRA_PEN_Q);
         if ( extraq_on(d, EXTRA_UTIL_Q) )
@@ -521,73 +475,59 @@ static void update_queues(
     struct list_head     *cur, *tmp;
     struct sedf_vcpu_info *curinf;
 =20
-    PRINT(3,"Updating waitq..\n");
-
-    /*
-     * Check for the first elements of the waitqueue, whether their
+    /* Check for the first elements of the waitqueue, whether their
      * next period has already started.
      */
     list_for_each_safe ( cur, tmp, waitq )
     {
         curinf =3D list_entry(cur, struct sedf_vcpu_info, list);
-        PRINT(4,"\tLooking @ dom %i.%i\n",
-              curinf->vcpu->domain->domain_id, curinf->vcpu->vcpu_id);
         if ( PERIOD_BEGIN(curinf) > now )
             break;
         __del_from_queue(curinf->vcpu);
         __add_to_runqueue_sort(curinf->vcpu);
     }
 =20
-    PRINT(3,"Updating runq..\n");
-
-    /* Process the runq, find domains that are on the runq that shouldn't.=
 */
+    /* Process the runq, find domains that are on the runq that shouldn't =
*/
     list_for_each_safe ( cur, tmp, runq )
     {
         curinf =3D list_entry(cur,struct sedf_vcpu_info,list);
-        PRINT(4,"\tLooking @ dom %i.%i\n",
-              curinf->vcpu->domain->domain_id, curinf->vcpu->vcpu_id);
=20
         if ( unlikely(curinf->slice =3D=3D 0) )
         {
-            /* Ignore domains with empty slice. */
-            PRINT(4,"\tUpdating zero-slice domain %i.%i\n",
-                  curinf->vcpu->domain->domain_id,
-                  curinf->vcpu->vcpu_id);
+            /* Ignore domains with empty slice */
             __del_from_queue(curinf->vcpu);
=20
-            /* Move them to their next period. */
+            /* Move them to their next period */
             curinf->deadl_abs +=3D curinf->period;
=20
-            /* Ensure that the start of the next period is in the future. =
*/
+            /* Ensure that the start of the next period is in the future *=
/
             if ( unlikely(PERIOD_BEGIN(curinf) < now) )
                 curinf->deadl_abs +=3D=20
                     (DIV_UP(now - PERIOD_BEGIN(curinf),
                             curinf->period)) * curinf->period;
=20
-            /* Put them back into the queue. */
+            /* Put them back into the queue */
             __add_to_waitqueue_sort(curinf->vcpu);
         }
         else if ( unlikely((curinf->deadl_abs < now) ||
                            (curinf->cputime > curinf->slice)) )
         {
-            /*
-             * We missed the deadline or the slice was already finished.
+            /* We missed the deadline or the slice was already finished.
              * Might hapen because of dom_adj.
              */
-            PRINT(4,"\tDomain %i.%i exceeded it's deadline/"
-                  "slice (%"PRIu64" / %"PRIu64") now: %"PRIu64
-                  " cputime: %"PRIu64"\n",
-                  curinf->vcpu->domain->domain_id,
-                  curinf->vcpu->vcpu_id,
-                  curinf->deadl_abs, curinf->slice, now,
-                  curinf->cputime);
+            printk("\tDomain %i.%i exceeded it's deadline/"
+                   "slice (%"PRIu64" / %"PRIu64") now: %"PRIu64
+                   " cputime: %"PRIu64"\n",
+                   curinf->vcpu->domain->domain_id,
+                   curinf->vcpu->vcpu_id,
+                   curinf->deadl_abs, curinf->slice, now,
+                   curinf->cputime);
             __del_from_queue(curinf->vcpu);
=20
-            /* Common case: we miss one period. */
+            /* Common case: we miss one period */
             curinf->deadl_abs +=3D curinf->period;
   =20
-            /*
-             * If we are still behind: modulo arithmetic, force deadline
+            /* If we are still behind: modulo arithmetic, force deadline
              * to be in future and aligned to period borders.
              */
             if ( unlikely(curinf->deadl_abs < now) )
@@ -596,7 +536,7 @@ static void update_queues(
                            curinf->period) * curinf->period;
             ASSERT(curinf->deadl_abs >=3D now);
=20
-            /* Give a fresh slice. */
+            /* Give a fresh slice */
             curinf->cputime =3D 0;
             if ( PERIOD_BEGIN(curinf) > now )
                 __add_to_waitqueue_sort(curinf->vcpu);
@@ -606,17 +546,16 @@ static void update_queues(
         else
             break;
     }
-
-    PRINT(3,"done updating the queues\n");
 }
=20

 /* removes a domain from the head of the according extraQ and
-   requeues it at a specified position:
-     round-robin extratime: end of extraQ
-     weighted ext.: insert in sorted list by score
-   if the domain is blocked / has regained its short-block-loss
-   time it is not put on any queue */
+ * requeues it at a specified position:
+ *   round-robin extratime: end of extraQ
+ *   weighted ext.: insert in sorted list by score
+ * if the domain is blocked / has regained its short-block-loss
+ * time it is not put on any queue.
+ */
 static void desched_extra_dom(s_time_t now, struct vcpu *d)
 {
     struct sedf_vcpu_info *inf =3D EDOM_INFO(d);
@@ -625,29 +564,25 @@ static void desched_extra_dom(s_time_t n
=20
     ASSERT(extraq_on(d, i));
=20
-    /* Unset all running flags. */
+    /* Unset all running flags */
     inf->status  &=3D ~(EXTRA_RUN_PEN | EXTRA_RUN_UTIL);
-    /* Fresh slice for the next run. */
+    /* Fresh slice for the next run */
     inf->cputime =3D 0;
-    /* Accumulate total extratime. */
+    /* Accumulate total extratime */
     inf->extra_time_tot +=3D now - inf->sched_start_abs;
     /* Remove extradomain from head of the queue. */
     extraq_del(d, i);
=20
-    /* Update the score. */
+    /* Update the score */
     oldscore =3D inf->score[i];
     if ( i =3D=3D EXTRA_PEN_Q )
     {
-        /*domain was running in L0 extraq*/
-        /*reduce block lost, probably more sophistication here!*/
+        /* Domain was running in L0 extraq */
+        /* reduce block lost, probably more sophistication here!*/
         /*inf->short_block_lost_tot -=3D EXTRA_QUANTUM;*/
         inf->short_block_lost_tot -=3D now - inf->sched_start_abs;
-        PRINT(3,"Domain %i.%i: Short_block_loss: %"PRIi64"\n",=20
-              inf->vcpu->domain->domain_id, inf->vcpu->vcpu_id,
-              inf->short_block_lost_tot);
 #if 0
-        /*
-         * KAF: If we don't exit short-blocking state at this point
+        /* KAF: If we don't exit short-blocking state at this point
          * domain0 can steal all CPU for up to 10 seconds before
          * scheduling settles down (when competing against another
          * CPU-bound domain). Doing this seems to make things behave
@@ -656,51 +591,56 @@ static void desched_extra_dom(s_time_t n
         if ( inf->short_block_lost_tot <=3D 0 )
 #endif
         {
-            PRINT(4,"Domain %i.%i compensated short block loss!\n",
-                  inf->vcpu->domain->domain_id, inf->vcpu->vcpu_id);
-            /*we have (over-)compensated our block penalty*/
+            /* We have (over-)compensated our block penalty */
             inf->short_block_lost_tot =3D 0;
-            /*we don't want a place on the penalty queue anymore!*/
+            /* We don't want a place on the penalty queue anymore! */
             inf->status &=3D ~EXTRA_WANT_PEN_Q;
             goto check_extra_queues;
         }
=20
-        /*we have to go again for another try in the block-extraq,
-          the score is not used incremantally here, as this is
-          already done by recalculating the block_lost*/
+        /* We have to go again for another try in the block-extraq,
+         * the score is not used incremantally here, as this is
+         * already done by recalculating the block_lost
+         */
         inf->score[EXTRA_PEN_Q] =3D (inf->period << 10) /
             inf->short_block_lost_tot;
         oldscore =3D 0;
     }
     else
     {
-        /*domain was running in L1 extraq =3D> score is inverse of
-          utilization and is used somewhat incremental!*/
+        /* Domain was running in L1 extraq =3D> score is inverse of
+         * utilization and is used somewhat incremental!
+         */
         if ( !inf->extraweight )
-            /*NB: use fixed point arithmetic with 10 bits*/
+        {
+            /* NB: use fixed point arithmetic with 10 bits */
             inf->score[EXTRA_UTIL_Q] =3D (inf->period << 10) /
                 inf->slice;
+        }
         else
-            /*conversion between realtime utilisation and extrawieght:
-              full (ie 100%) utilization is equivalent to 128 extraweight*=
/
+        {
+            /* Conversion between realtime utilisation and extrawieght:
+             * full (ie 100%) utilization is equivalent to 128 extraweight
+             */
             inf->score[EXTRA_UTIL_Q] =3D (1<<17) / inf->extraweight;
+        }
     }
=20
  check_extra_queues:
-    /* Adding a runnable domain to the right queue and removing blocked on=
es*/
+    /* Adding a runnable domain to the right queue and removing blocked on=
es */
     if ( sedf_runnable(d) )
     {
-        /*add according to score: weighted round robin*/
+        /* Add according to score: weighted round robin */
         if (((inf->status & EXTRA_AWARE) && (i =3D=3D EXTRA_UTIL_Q)) ||
             ((inf->status & EXTRA_WANT_PEN_Q) && (i =3D=3D EXTRA_PEN_Q)))
             extraq_add_sort_update(d, i, oldscore);
     }
     else
     {
-        /*remove this blocked domain from the waitq!*/
+        /* Remove this blocked domain from the waitq! */
         __del_from_queue(d);
-        /*make sure that we remove a blocked domain from the other
-          extraq too*/
+        /* Make sure that we remove a blocked domain from the other
+         * extraq too. */
         if ( i =3D=3D EXTRA_PEN_Q )
         {
             if ( extraq_on(d, EXTRA_UTIL_Q) )
@@ -732,8 +672,9 @@ static struct task_slice sedf_do_extra_s
=20
     if ( !list_empty(extraq[EXTRA_PEN_Q]) )
     {
-        /*we still have elements on the level 0 extraq=20
-          =3D> let those run first!*/
+        /* We still have elements on the level 0 extraq
+         * =3D> let those run first!
+         */
         runinf   =3D list_entry(extraq[EXTRA_PEN_Q]->next,=20
                               struct sedf_vcpu_info, extralist[EXTRA_PEN_Q=
]);
         runinf->status |=3D EXTRA_RUN_PEN;
@@ -747,7 +688,7 @@ static struct task_slice sedf_do_extra_s
     {
         if ( !list_empty(extraq[EXTRA_UTIL_Q]) )
         {
-            /*use elements from the normal extraqueue*/
+            /* Use elements from the normal extraqueue */
             runinf   =3D list_entry(extraq[EXTRA_UTIL_Q]->next,
                                   struct sedf_vcpu_info,
                                   extralist[EXTRA_UTIL_Q]);
@@ -773,10 +714,11 @@ static struct task_slice sedf_do_extra_s
=20

 /* Main scheduling function
-   Reasons for calling this function are:
-   -timeslice for the current period used up
-   -domain on waitqueue has started it's period
-   -and various others ;) in general: determine which domain to run next*/
+ * Reasons for calling this function are:
+ * -timeslice for the current period used up
+ * -domain on waitqueue has started it's period
+ * -and various others ;) in general: determine which domain to run next
+ */
 static struct task_slice sedf_do_schedule(
     const struct scheduler *ops, s_time_t now, bool_t tasklet_work_schedul=
ed)
 {
@@ -789,13 +731,14 @@ static struct task_slice sedf_do_schedul
     struct sedf_vcpu_info *runinf, *waitinf;
     struct task_slice      ret;
=20
-    /*idle tasks don't need any of the following stuf*/
+    /* Idle tasks don't need any of the following stuf */
     if ( is_idle_vcpu(current) )
         goto check_waitq;
 =20
-    /* create local state of the status of the domain, in order to avoid
-       inconsistent state during scheduling decisions, because data for
-       vcpu_runnable is not protected by the scheduling lock!*/
+    /* Create local state of the status of the domain, in order to avoid
+     * inconsistent state during scheduling decisions, because data for
+     * vcpu_runnable is not protected by the scheduling lock!
+     */
     if ( !vcpu_runnable(current) )
         inf->status |=3D SEDF_ASLEEP;
 =20
@@ -804,7 +747,7 @@ static struct task_slice sedf_do_schedul
=20
     if ( unlikely(extra_runs(inf)) )
     {
-        /*special treatment of domains running in extra time*/
+        /* Special treatment of domains running in extra time */
         desched_extra_dom(now, current);
     }
     else=20
@@ -814,10 +757,11 @@ static struct task_slice sedf_do_schedul
  check_waitq:
     update_queues(now, runq, waitq);
=20
-    /*now simply pick the first domain from the runqueue, which has the
-      earliest deadline, because the list is sorted*/
-=20
-    /* Tasklet work (which runs in idle VCPU context) overrides all else. =
*/
+    /* Now simply pick the first domain from the runqueue, which has the
+     * earliest deadline, because the list is sorted
+     *
+     * Tasklet work (which runs in idle VCPU context) overrides all else.
+     */
     if ( tasklet_work_scheduled ||
          (list_empty(runq) && list_empty(waitq)) ||
          unlikely(!cpumask_test_cpu(cpu, SEDF_CPUONLINE(per_cpu(cpupool, c=
pu)))) )
@@ -833,9 +777,10 @@ static struct task_slice sedf_do_schedul
         {
             waitinf  =3D list_entry(waitq->next,
                                   struct sedf_vcpu_info,list);
-            /*rerun scheduler, when scheduled domain reaches it's
-              end of slice or the first domain from the waitqueue
-              gets ready*/
+            /* Rerun scheduler, when scheduled domain reaches it's
+             * end of slice or the first domain from the waitqueue
+             * gets ready.
+             */
             ret.time =3D MIN(now + runinf->slice - runinf->cputime,
                            PERIOD_BEGIN(waitinf)) - now;
         }
@@ -847,14 +792,15 @@ static struct task_slice sedf_do_schedul
     else
     {
         waitinf  =3D list_entry(waitq->next,struct sedf_vcpu_info, list);
-        /*we could not find any suitable domain=20
-          =3D> look for domains that are aware of extratime*/
+        /* We could not find any suitable domain=20
+         * =3D> look for domains that are aware of extratime*/
         ret =3D sedf_do_extra_schedule(now, PERIOD_BEGIN(waitinf),
                                      extraq, cpu);
     }
=20
-    /*TODO: Do something USEFUL when this happens and find out, why it
-      still can happen!!!*/
+    /* TODO: Do something USEFUL when this happens and find out, why it
+     * still can happen!!!
+     */
     if ( ret.time < 0)
     {
         printk("Ouch! We are seriously BEHIND schedule! %"PRIi64"\n",
@@ -874,9 +820,6 @@ static struct task_slice sedf_do_schedul
=20
 static void sedf_sleep(const struct scheduler *ops, struct vcpu *d)
 {
-    PRINT(2,"sedf_sleep was called, domain-id %i.%i\n",
-          d->domain->domain_id, d->vcpu_id);
-=20
     if ( is_idle_vcpu(d) )
         return;
=20
@@ -972,27 +915,29 @@ static void sedf_sleep(const struct sche
 static void unblock_short_extra_support(
     struct sedf_vcpu_info* inf, s_time_t now)
 {
-    /*this unblocking scheme tries to support the domain, by assigning it
-    a priority in extratime distribution according to the loss of time
-    in this slice due to blocking*/
+    /* This unblocking scheme tries to support the domain, by assigning it
+     * a priority in extratime distribution according to the loss of time
+     * in this slice due to blocking
+     */
     s_time_t pen;
 =20
-    /*no more realtime execution in this period!*/
+    /* No more realtime execution in this period! */
     inf->deadl_abs +=3D inf->period;
     if ( likely(inf->block_abs) )
     {
-        //treat blocked time as consumed by the domain*/
+        /* Treat blocked time as consumed by the domain */
         /*inf->cputime +=3D now - inf->block_abs;*/
-        /*penalty is time the domain would have
-          had if it continued to run */
+        /* Penalty is time the domain would have
+         * had if it continued to run.
+         */
         pen =3D (inf->slice - inf->cputime);
         if ( pen < 0 )
             pen =3D 0;
-        /*accumulate all penalties over the periods*/
+        /* Accumulate all penalties over the periods */
         /*inf->short_block_lost_tot +=3D pen;*/
-        /*set penalty to the current value*/
+        /* Set penalty to the current value */
         inf->short_block_lost_tot =3D pen;
-        /*not sure which one is better.. but seems to work well...*/
+        /* Not sure which one is better.. but seems to work well... */
  =20
         if ( inf->short_block_lost_tot )
         {
@@ -1002,28 +947,30 @@ static void unblock_short_extra_support(
             inf->pen_extra_blocks++;
 #endif
             if ( extraq_on(inf->vcpu, EXTRA_PEN_Q) )
-                /*remove domain for possible resorting!*/
+                /* Remove domain for possible resorting! */
                 extraq_del(inf->vcpu, EXTRA_PEN_Q);
             else
-                /*remember that we want to be on the penalty q
-                  so that we can continue when we (un-)block
-                  in penalty-extratime*/
+                /* Remember that we want to be on the penalty q
+                 * so that we can continue when we (un-)block
+                 * in penalty-extratime
+                 */
                 inf->status |=3D EXTRA_WANT_PEN_Q;
   =20
-            /*(re-)add domain to the penalty extraq*/
+            /* (re-)add domain to the penalty extraq */
             extraq_add_sort_update(inf->vcpu, EXTRA_PEN_Q, 0);
         }
     }
=20
-    /*give it a fresh slice in the next period!*/
+    /* Give it a fresh slice in the next period! */
     inf->cputime =3D 0;
 }
=20

 static void unblock_long_cons_b(struct sedf_vcpu_info* inf,s_time_t now)
 {
-    /*Conservative 2b*/
-    /*Treat the unblocking time as a start of a new period */
+    /* Conservative 2b */
+
+    /* Treat the unblocking time as a start of a new period */
     inf->deadl_abs =3D now + inf->period;
     inf->cputime =3D 0;
 }
@@ -1046,15 +993,16 @@ static inline int get_run_type(struct vc
 }
=20

-/*Compares two domains in the relation of whether the one is allowed to
-  interrupt the others execution.
-  It returns true (!=3D0) if a switch to the other domain is good.
-  Current Priority scheme is as follows:
-   EDF > L0 (penalty based) extra-time >=20
-   L1 (utilization) extra-time > idle-domain
-  In the same class priorities are assigned as following:
-   EDF: early deadline > late deadline
-   L0 extra-time: lower score > higher score*/
+/* Compares two domains in the relation of whether the one is allowed to
+ * interrupt the others execution.
+ * It returns true (!=3D0) if a switch to the other domain is good.
+ * Current Priority scheme is as follows:
+ *  EDF > L0 (penalty based) extra-time >=20
+ *  L1 (utilization) extra-time > idle-domain
+ * In the same class priorities are assigned as following:
+ *  EDF: early deadline > late deadline
+ *  L0 extra-time: lower score > higher score
+ */
 static inline int should_switch(struct vcpu *cur,
                                 struct vcpu *other,
                                 s_time_t now)
@@ -1063,19 +1011,19 @@ static inline int should_switch(struct v
     cur_inf   =3D EDOM_INFO(cur);
     other_inf =3D EDOM_INFO(other);
 =20
-    /* Check whether we need to make an earlier scheduling decision. */
+    /* Check whether we need to make an earlier scheduling decision */
     if ( PERIOD_BEGIN(other_inf) <=20
          CPU_INFO(other->processor)->current_slice_expires )
         return 1;
=20
-    /* No timing-based switches need to be taken into account here. */
+    /* No timing-based switches need to be taken into account here */
     switch ( get_run_type(cur) )
     {
     case DOMAIN_EDF:
-        /* Do not interrupt a running EDF domain. */
+        /* Do not interrupt a running EDF domain */
         return 0;
     case DOMAIN_EXTRA_PEN:
-        /* Check whether we also want the L0 ex-q with lower score. */
+        /* Check whether we also want the L0 ex-q with lower score */
         return ((other_inf->status & EXTRA_WANT_PEN_Q) &&
                 (other_inf->score[EXTRA_PEN_Q] <=20
                  cur_inf->score[EXTRA_PEN_Q]));
@@ -1096,18 +1044,11 @@ static void sedf_wake(const struct sched
     s_time_t              now =3D NOW();
     struct sedf_vcpu_info* inf =3D EDOM_INFO(d);
=20
-    PRINT(3, "sedf_wake was called, domain-id %i.%i\n",d->domain->domain_i=
d,
-          d->vcpu_id);
-
     if ( unlikely(is_idle_vcpu(d)) )
         return;
   =20
     if ( unlikely(__task_on_queue(d)) )
-    {
-        PRINT(3,"\tdomain %i.%i is already in some queue\n",
-              d->domain->domain_id, d->vcpu_id);
         return;
-    }
=20
     ASSERT(!sedf_runnable(d));
     inf->status &=3D ~SEDF_ASLEEP;
@@ -1116,28 +1057,24 @@ static void sedf_wake(const struct sched
 =20
     if ( unlikely(inf->deadl_abs =3D=3D 0) )
     {
-        /*initial setup of the deadline*/
+        /* Initial setup of the deadline */
         inf->deadl_abs =3D now + inf->slice;
     }
  =20
-    PRINT(3, "waking up domain %i.%i (deadl=3D %"PRIu64" period=3D %"PRIu6=
4
-          "now=3D %"PRIu64")\n",
-          d->domain->domain_id, d->vcpu_id, inf->deadl_abs, inf->period, n=
ow);
-
 #ifdef SEDF_STATS=20
     inf->block_tot++;
 #endif
=20
     if ( unlikely(now < PERIOD_BEGIN(inf)) )
     {
-        PRINT(4,"extratime unblock\n");
-        /* unblocking in extra-time! */
+        /* Unblocking in extra-time! */
         if ( inf->status & EXTRA_WANT_PEN_Q )
         {
-            /*we have a domain that wants compensation
-              for block penalty and did just block in
-              its compensation time. Give it another
-              chance!*/
+            /* We have a domain that wants compensation
+             * for block penalty and did just block in
+             * its compensation time. Give it another
+             * chance!
+             */
             extraq_add_sort_update(d, EXTRA_PEN_Q, 0);
         }
         extraq_check_add_unblocked(d, 0);
@@ -1146,8 +1083,7 @@ static void sedf_wake(const struct sched
     { =20
         if ( now < inf->deadl_abs )
         {
-            PRINT(4,"short unblocking\n");
-            /*short blocking*/
+            /* Short blocking */
 #ifdef SEDF_STATS
             inf->short_block_tot++;
 #endif
@@ -1157,8 +1093,7 @@ static void sedf_wake(const struct sched
         }
         else
         {
-            PRINT(4,"long unblocking\n");
-            /*long unblocking*/
+            /* Long unblocking */
 #ifdef SEDF_STATS
             inf->long_block_tot++;
 #endif
@@ -1168,24 +1103,13 @@ static void sedf_wake(const struct sched
         }
     }
=20
-    PRINT(3, "woke up domain %i.%i (deadl=3D %"PRIu64" period=3D %"PRIu64
-          "now=3D %"PRIu64")\n",
-          d->domain->domain_id, d->vcpu_id, inf->deadl_abs,
-          inf->period, now);
-
     if ( PERIOD_BEGIN(inf) > now )
-    {
         __add_to_waitqueue_sort(d);
-        PRINT(3,"added to waitq\n");
-    }
     else
-    {
         __add_to_runqueue_sort(d);
-        PRINT(3,"added to runq\n");
-    }
 =20
 #ifdef SEDF_STATS
-    /*do some statistics here...*/
+    /* Do some statistics here... */
     if ( inf->block_abs !=3D 0 )
     {
         inf->block_time_tot +=3D now - inf->block_abs;
@@ -1194,12 +1118,13 @@ static void sedf_wake(const struct sched
     }
 #endif
=20
-    /*sanity check: make sure each extra-aware domain IS on the util-q!*/
+    /* Sanity check: make sure each extra-aware domain IS on the util-q! *=
/
     ASSERT(IMPLY(inf->status & EXTRA_AWARE, extraq_on(d, EXTRA_UTIL_Q)));
     ASSERT(__task_on_queue(d));
-    /*check whether the awakened task needs to invoke the do_schedule
-      routine. Try to avoid unnecessary runs but:
-      Save approximation: Always switch to scheduler!*/
+    /* Check whether the awakened task needs to invoke the do_schedule
+     * routine. Try to avoid unnecessary runs but:
+     * Save approximation: Always switch to scheduler!
+     */
     ASSERT(d->processor >=3D 0);
     ASSERT(d->processor < nr_cpu_ids);
     ASSERT(per_cpu(schedule_data, d->processor).curr);
@@ -1244,7 +1169,7 @@ static void sedf_dump_domain(struct vcpu
 }
=20

-/* dumps all domains on the specified cpu */
+/* Dumps all domains on the specified cpu */
 static void sedf_dump_cpu_state(const struct scheduler *ops, int i)
 {
     struct list_head      *list, *queue, *tmp;
@@ -1319,7 +1244,7 @@ static void sedf_dump_cpu_state(const st
 }
=20

-/* Adjusts periods and slices of the domains accordingly to their weights.=
 */
+/* Adjusts periods and slices of the domains accordingly to their weights =
*/
 static int sedf_adjust_weights(struct cpupool *c, struct xen_domctl_schedu=
ler_op *cmd)
 {
     struct vcpu *p;
@@ -1335,7 +1260,7 @@ static int sedf_adjust_weights(struct cp
         return -ENOMEM;
     }
=20
-    /* Sum across all weights. */
+    /* Sum across all weights */
     rcu_read_lock(&domlist_read_lock);
     for_each_domain_in_cpupool( d, c )
     {
@@ -1350,11 +1275,13 @@ static int sedf_adjust_weights(struct cp
             }
             else
             {
-                /*don't modify domains who don't have a weight, but sum
-                  up the time they need, projected to a WEIGHT_PERIOD,
-                  so that this time is not given to the weight-driven
-                  domains*/
-                /*check for overflows*/
+                /* Don't modify domains who don't have a weight, but sum
+                 * up the time they need, projected to a WEIGHT_PERIOD,
+                 * so that this time is not given to the weight-driven
+                 *  domains
+                 */
+
+                /* Check for overflows */
                 ASSERT((WEIGHT_PERIOD < ULONG_MAX)=20
                        && (EDOM_INFO(p)->slice_orig < ULONG_MAX));
                 sumt[cpu] +=3D=20
@@ -1365,7 +1292,7 @@ static int sedf_adjust_weights(struct cp
     }
     rcu_read_unlock(&domlist_read_lock);
=20
-    /* Adjust all slices (and periods) to the new weight. */
+    /* Adjust all slices (and periods) to the new weight */
     rcu_read_lock(&domlist_read_lock);
     for_each_domain_in_cpupool( d, c )
     {
@@ -1393,20 +1320,15 @@ static int sedf_adjust_weights(struct cp
 }
=20

-/* set or fetch domain scheduling parameters */
+/* Set or fetch domain scheduling parameters */
 static int sedf_adjust(const struct scheduler *ops, struct domain *p, stru=
ct xen_domctl_scheduler_op *op)
 {
     struct vcpu *v;
     int rc;
=20
-    PRINT(2,"sedf_adjust was called, domain-id %i new period %"PRIu64" "
-          "new slice %"PRIu64"\nlatency %"PRIu64" extra:%s\n",
-          p->domain_id, op->u.sedf.period, op->u.sedf.slice,
-          op->u.sedf.latency, (op->u.sedf.extratime)?"yes":"no");
-
     if ( op->cmd =3D=3D XEN_DOMCTL_SCHEDOP_putinfo )
     {
-        /* Check for sane parameters. */
+        /* Check for sane parameters */
         if ( !op->u.sedf.period && !op->u.sedf.weight )
             return -EINVAL;
         if ( op->u.sedf.weight )
@@ -1414,7 +1336,7 @@ static int sedf_adjust(const struct sche
             if ( (op->u.sedf.extratime & EXTRA_AWARE) &&
                  (!op->u.sedf.period) )
             {
-                /* Weight-driven domains with extratime only. */
+                /* Weight-driven domains with extratime only */
                 for_each_vcpu ( p, v )
                 {
                     EDOM_INFO(v)->extraweight =3D op->u.sedf.weight;
@@ -1425,7 +1347,7 @@ static int sedf_adjust(const struct sche
             }
             else
             {
-                /* Weight-driven domains with real-time execution. */
+                /* Weight-driven domains with real-time execution */
                 for_each_vcpu ( p, v )
                     EDOM_INFO(v)->weight =3D op->u.sedf.weight;
             }
@@ -1435,8 +1357,7 @@ static int sedf_adjust(const struct sche
             /* Time-driven domains. */
             for_each_vcpu ( p, v )
             {
-                /*
-                 * Sanity checking: note that disabling extra weight requi=
res
+                /* Sanity checking: note that disabling extra weight requi=
res
                  * that we set a non-zero slice.
                  */
                 if ( (op->u.sedf.period > PERIOD_MAX) ||
@@ -1477,7 +1398,6 @@ static int sedf_adjust(const struct sche
         op->u.sedf.weight    =3D EDOM_INFO(p->vcpu[0])->weight;
     }
=20
-    PRINT(2,"sedf_adjust_finished\n");
     return 0;
 }
=20

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-------------------------------------------------------------------
Dario Faggioli, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
PhD Candidate, ReTiS Lab, Scuola Superiore Sant'Anna, Pisa (Italy)




--=-3p5/0djGq6n5G1gGRftX
Content-Disposition: attachment; filename="sedf-debug-cleanup.patch"
Content-Type: text/x-patch; name="sedf-debug-cleanup.patch"; charset="UTF-8"
Content-Transfer-Encoding: base64

IyBIRyBjaGFuZ2VzZXQgcGF0Y2gNCiMgUGFyZW50IDE3ZDk5NjkxZTBlYzFmYTdiYjcxY2YxOGMx
MmNhM2MwNDZjMGM4ZDcNCnNlZGY6IHJlbW92ZSB1c2VsZXNzIHRyYWNpbmcgcHJpbnRrIGFuZCBo
YXJtb25pemUgY29tbWVudHMgc3R5bGUuDQoNCnNjaGVkX3NlZGYuYyB1c2VkIG8gaGF2ZSBpdHMg
b3duIG1lY2hhbmlzbSBmb3IgcHJvZHVjaW5nIHRyYWNpbmctYWxpa2UNCmtpbmQgb2YgaW5mb3Jt
YXRpb24gKGRvbWFpbiBibG9jaywgd2FrZXVwLCBldGMuKS4gTm93YWRheXMsIHdpdGggYW4gZXZl
bg0Kbm90IHNvIGhpZ2ggbnVtYmVyIG9mIHBDUFVzL3ZDUFVzLCBqdXN0IHRyeWluZyB0byBlbmFi
bGUgdGhpcyBtYWtlcw0KdGhlIHNlcmlhbCBjb25zb2xlIGNvbXBsZXRlbHkgdW51c2FibGUsIHBy
b2R1Y2VzIHRvbnMgb2YgdmVyeSBoYXJkIHRvDQpwYXJzZSBhbmQgaW50ZXJwcmVldCBsb2dnaW5n
IGFuZCBjYW4gZWFzaWx5IGxpdmVsb2NrIERvbTAuIE1vcmVvdmVyLA0KcHJldHR5IG11Y2ggdGhl
IHNhbWUgcmVzdWx0IHRoaXMgaXMgc3RydWdnbGluZyB0byBnZXQgdG8sIGlzIGJldHRlcg0KYWNo
aWV2ZWQgYnkgZW5hYmxpbmcgdGhlIHNjaGVkdWxlci1yZWxhdGVkIHRyYWNpbmcgZXZlbnRzLCBh
cw0KaXQgaXMgZm9yIHRoZSBvdGhlciBzY2hlZHVsZXJzIChzYXksIGNyZWRpdCBvciBjcmVkaXQy
KS4NCg0KRm9yIGFsbCB0aGVzZSByZWFzb25zLCB0aGlzIHJlbW92ZXMgdGhhdCBtYWNoaW5lcnkg
Y29tcGxldGVseS4gV2hpbGUgYXQNCml0LCBjaGVjayBpbiBzb21lIGNvc21ldGljcyB0aGF0IGhh
cm1vbml6ZSB0aGUgY29tbWVudHMgd2l0aGltIHRoZW1zZWxmDQphbmQgd2l0aCB0aGUgcmVzdCBv
ZiB0aGUgY29kZSBiYXNlLg0KDQpTaWduZWQtb2ZmLWJ5OiBEYXJpbyBGYWdnaW9saSA8ZGFyaW8u
ZmFnZ2lvbGlAY2l0cml4LmNvbT4NCg0KZGlmZiAtciAxN2Q5OTY5MWUwZWMgeGVuL2NvbW1vbi9z
Y2hlZF9zZWRmLmMNCi0tLSBhL3hlbi9jb21tb24vc2NoZWRfc2VkZi5jCVR1ZSBEZWMgMjAgMTY6
Mzk6NTYgMjAxMSArMDAwMA0KKysrIGIveGVuL2NvbW1vbi9zY2hlZF9zZWRmLmMJVHVlIERlYyAy
MCAxNzozMjo1MiAyMDExICswMDAwDQpAQCAtMTMsMTQgKzEzLDYgQEANCiAjaW5jbHVkZSA8eGVu
L3RpbWUuaD4NCiAjaW5jbHVkZSA8eGVuL2Vycm5vLmg+DQogDQotLyp2ZXJib3NpdHkgc2V0dGlu
Z3MqLw0KLSNkZWZpbmUgU0VERkxFVkVMIDANCi0jZGVmaW5lIFBSSU5UKF9mLCBfYS4uLikgICAg
ICAgICAgICAgICAgICAgICAgICBcDQotICAgIGRvIHsgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgXA0KLSAgICAgICAgaWYgKCAoX2YpIDw9IFNFREZMRVZFTCApICAgICAg
ICAgICAgICAgIFwNCi0gICAgICAgICAgICBwcmludGsoX2EgKTsgICAgICAgICAgICAgICAgICAg
ICAgICBcDQotICAgIH0gd2hpbGUgKCAwICkNCi0NCiAjZGVmaW5lIFNFREZfQ1BVT05MSU5FKF9w
b29sKSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFwNCiAgICAg
KCgoX3Bvb2wpID09IE5VTEwpID8gJmNwdXBvb2xfZnJlZV9jcHVzIDogKF9wb29sKS0+Y3B1X3Zh
bGlkKQ0KIA0KQEAgLTY2LDM0ICs1OCwzNSBAQCBzdHJ1Y3Qgc2VkZl92Y3B1X2luZm8gew0KICAg
ICBzdHJ1Y3QgbGlzdF9oZWFkIGxpc3Q7DQogICAgIHN0cnVjdCBsaXN0X2hlYWQgZXh0cmFsaXN0
WzJdOw0KICANCi0gICAgLypQYXJhbWV0ZXJzIGZvciBFREYqLw0KLSAgICBzX3RpbWVfdCAgcGVy
aW9kOyAgLyo9KHJlbGF0aXZlIGRlYWRsaW5lKSovDQotICAgIHNfdGltZV90ICBzbGljZTsgIC8q
PXdvcnN0IGNhc2UgZXhlY3V0aW9uIHRpbWUqLw0KKyAgICAvKiBQYXJhbWV0ZXJzIGZvciBFREYg
Ki8NCisgICAgc190aW1lX3QgIHBlcmlvZDsgIC8qID0ocmVsYXRpdmUgZGVhZGxpbmUpICovDQor
ICAgIHNfdGltZV90ICBzbGljZTsgICAvKiA9d29yc3QgY2FzZSBleGVjdXRpb24gdGltZSAqLw0K
ICANCi0gICAgLypBZHZhY2VkIFBhcmFtZXRlcnMqLw0KLSAgICAvKkxhdGVuY3kgU2NhbGluZyov
DQorICAgIC8qIEFkdmFjZWQgUGFyYW1ldGVycyAqLw0KKw0KKyAgICAvKiBMYXRlbmN5IFNjYWxp
bmcgKi8NCiAgICAgc190aW1lX3QgIHBlcmlvZF9vcmlnOw0KICAgICBzX3RpbWVfdCAgc2xpY2Vf
b3JpZzsNCiAgICAgc190aW1lX3QgIGxhdGVuY3k7DQogIA0KLSAgICAvKnN0YXR1cyBvZiBkb21h
aW4qLw0KKyAgICAvKiBTdGF0dXMgb2YgZG9tYWluICovDQogICAgIGludCAgICAgICBzdGF0dXM7
DQotICAgIC8qd2VpZ2h0cyBmb3IgIlNjaGVkdWxpbmcgZm9yIGJlZ2lubmVycy8gbGF6eS8gZXRj
LiIgOykqLw0KKyAgICAvKiBXZWlnaHRzIGZvciAiU2NoZWR1bGluZyBmb3IgYmVnaW5uZXJzLyBs
YXp5LyBldGMuIiA7KSAqLw0KICAgICBzaG9ydCAgICAgd2VpZ2h0Ow0KICAgICBzaG9ydCAgICAg
ZXh0cmF3ZWlnaHQ7DQotICAgIC8qQm9va2tlZXBpbmcqLw0KKyAgICAvKiBCb29ra2VlcGluZyAq
Lw0KICAgICBzX3RpbWVfdCAgZGVhZGxfYWJzOw0KICAgICBzX3RpbWVfdCAgc2NoZWRfc3RhcnRf
YWJzOw0KICAgICBzX3RpbWVfdCAgY3B1dGltZTsNCi0gICAgLyogdGltZXMgdGhlIGRvbWFpbiB1
bi0vYmxvY2tlZCAqLw0KKyAgICAvKiBUaW1lcyB0aGUgZG9tYWluIHVuLS9ibG9ja2VkICovDQog
ICAgIHNfdGltZV90ICBibG9ja19hYnM7DQogICAgIHNfdGltZV90ICB1bmJsb2NrX2FiczsNCiAg
DQotICAgIC8qc2NvcmVzIGZvciB7dXRpbCwgYmxvY2sgcGVuYWx0eX0td2VpZ2h0ZWQgZXh0cmF0
aW1lIGRpc3RyaWJ1dGlvbiovDQorICAgIC8qIFNjb3JlcyBmb3Ige3V0aWwsIGJsb2NrIHBlbmFs
dHl9LXdlaWdodGVkIGV4dHJhdGltZSBkaXN0cmlidXRpb24gKi8NCiAgICAgaW50ICAgc2NvcmVb
Ml07DQogICAgIHNfdGltZV90ICBzaG9ydF9ibG9ja19sb3N0X3RvdDsNCiAgDQotICAgIC8qU3Rh
dGlzdGljcyovDQorICAgIC8qIFN0YXRpc3RpY3MgKi8NCiAgICAgc190aW1lX3QgIGV4dHJhX3Rp
bWVfdG90Ow0KIA0KICNpZmRlZiBTRURGX1NUQVRTDQpAQCAtMTU4LDE4ICsxNTEsMTYgQEAgc3Rh
dGljIGlubGluZSB2b2lkIGV4dHJhcV9kZWwoc3RydWN0IHZjcA0KIHsNCiAgICAgc3RydWN0IGxp
c3RfaGVhZCAqbGlzdCA9IEVYVFJBTElTVChkLGkpOw0KICAgICBBU1NFUlQoZXh0cmFxX29uKGQs
aSkpOw0KLSAgICBQUklOVCgzLCAiUmVtb3ZpbmcgZG9tYWluICVpLiVpIGZyb20gTCVpIGV4dHJh
cVxuIiwNCi0gICAgICAgICAgZC0+ZG9tYWluLT5kb21haW5faWQsIGQtPnZjcHVfaWQsIGkpOw0K
ICAgICBsaXN0X2RlbChsaXN0KTsNCiAgICAgbGlzdC0+bmV4dCA9IE5VTEw7DQogICAgIEFTU0VS
VCghZXh0cmFxX29uKGQsIGkpKTsNCiB9DQogDQotLyogYWRkcyBhIGRvbWFpbiB0byB0aGUgcXVl
dWUgb2YgcHJvY2Vzc2VzIHdoaWNoIGFyZSBhd2FyZSBvZiBleHRyYSB0aW1lLiBMaXN0DQotICAg
aXMgc29ydGVkIGJ5IHNjb3JlLCB3aGVyZSBhIGxvd2VyIHNjb3JlIG1lYW5zIGhpZ2hlciBwcmlv
cml0eSBmb3IgYW4gZXh0cmENCi0gICBzbGljZS4gSXQgYWxzbyB1cGRhdGVzIHRoZSBzY29yZSwg
Ynkgc2ltcGx5IHN1YnRyYWN0aW5nIGEgZml4ZWQgdmFsdWUgZnJvbQ0KLSAgIGVhY2ggZW50cnks
IGluIG9yZGVyIHRvIGF2b2lkIG92ZXJmbG93LiBUaGUgYWxnb3JpdGhtIHdvcmtzIGJ5IHNpbXBs
eQ0KLSAgIGNoYXJnaW5nIGVhY2ggZG9tYWluIHRoYXQgcmVjaWV2ZWQgZXh0cmF0aW1lIHdpdGgg
YW4gaW52ZXJzZSBvZiBpdHMgd2VpZ2h0Lg0KKy8qIEFkZHMgYSBkb21haW4gdG8gdGhlIHF1ZXVl
IG9mIHByb2Nlc3NlcyB3aGljaCBhcmUgYXdhcmUgb2YgZXh0cmEgdGltZS4gTGlzdA0KKyAqIGlz
IHNvcnRlZCBieSBzY29yZSwgd2hlcmUgYSBsb3dlciBzY29yZSBtZWFucyBoaWdoZXIgcHJpb3Jp
dHkgZm9yIGFuIGV4dHJhDQorICogc2xpY2UuIEl0IGFsc28gdXBkYXRlcyB0aGUgc2NvcmUsIGJ5
IHNpbXBseSBzdWJ0cmFjdGluZyBhIGZpeGVkIHZhbHVlIGZyb20NCisgKiBlYWNoIGVudHJ5LCBp
biBvcmRlciB0byBhdm9pZCBvdmVyZmxvdy4gVGhlIGFsZ29yaXRobSB3b3JrcyBieSBzaW1wbHkN
CisgKiBjaGFyZ2luZyBlYWNoIGRvbWFpbiB0aGF0IHJlY2lldmVkIGV4dHJhdGltZSB3aXRoIGFu
IGludmVyc2Ugb2YgaXRzIHdlaWdodC4NCiAgKi8gDQogc3RhdGljIGlubGluZSB2b2lkIGV4dHJh
cV9hZGRfc29ydF91cGRhdGUoc3RydWN0IHZjcHUgKmQsIGludCBpLCBpbnQgc3ViKQ0KIHsNCkBA
IC0xNzgsMTMgKzE2OSw3IEBAIHN0YXRpYyBpbmxpbmUgdm9pZCBleHRyYXFfYWRkX3NvcnRfdXBk
YXQNCiAgDQogICAgIEFTU0VSVCghZXh0cmFxX29uKGQsaSkpOw0KIA0KLSAgICBQUklOVCgzLCAi
QWRkaW5nIGRvbWFpbiAlaS4laSAoc2NvcmU9ICVpLCBzaG9ydF9wZW49ICUiUFJJaTY0IikiDQot
ICAgICAgICAgICIgdG8gTCVpIGV4dHJhcVxuIiwNCi0gICAgICAgICAgZC0+ZG9tYWluLT5kb21h
aW5faWQsIGQtPnZjcHVfaWQsIEVET01fSU5GTyhkKS0+c2NvcmVbaV0sDQotICAgICAgICAgIEVE
T01fSU5GTyhkKS0+c2hvcnRfYmxvY2tfbG9zdF90b3QsIGkpOw0KLQ0KLSAgICAvKg0KLSAgICAg
KiBJdGVyYXRlIHRocm91Z2ggYWxsIGVsZW1lbnRzIHRvIGZpbmQgb3VyICJob2xlIiBhbmQgb24g
b3VyIHdheQ0KKyAgICAvKiBJdGVyYXRlIHRocm91Z2ggYWxsIGVsZW1lbnRzIHRvIGZpbmQgb3Vy
ICJob2xlIiBhbmQgb24gb3VyIHdheQ0KICAgICAgKiB1cGRhdGUgYWxsIHRoZSBvdGhlciBzY29y
ZXMuDQogICAgICAqLw0KICAgICBsaXN0X2Zvcl9lYWNoICggY3VyLCBFWFRSQVEoZC0+cHJvY2Vz
c29yLCBpKSApDQpAQCAtMTkzLDI1ICsxNzgsMTggQEAgc3RhdGljIGlubGluZSB2b2lkIGV4dHJh
cV9hZGRfc29ydF91cGRhdA0KICAgICAgICAgY3VyaW5mLT5zY29yZVtpXSAtPSBzdWI7DQogICAg
ICAgICBpZiAoIEVET01fSU5GTyhkKS0+c2NvcmVbaV0gPCBjdXJpbmYtPnNjb3JlW2ldICkNCiAg
ICAgICAgICAgICBicmVhazsNCi0gICAgICAgIFBSSU5UKDQsIlx0YmVoaW5kIGRvbWFpbiAlaS4l
aSAoc2NvcmU9ICVpKVxuIiwNCi0gICAgICAgICAgICAgIGN1cmluZi0+dmNwdS0+ZG9tYWluLT5k
b21haW5faWQsDQotICAgICAgICAgICAgICBjdXJpbmYtPnZjcHUtPnZjcHVfaWQsIGN1cmluZi0+
c2NvcmVbaV0pOw0KICAgICB9DQogDQotICAgIC8qIGN1ciBub3cgY29udGFpbnMgdGhlIGVsZW1l
bnQsIGJlZm9yZSB3aGljaCB3ZSdsbCBlbnF1ZXVlLiAqLw0KLSAgICBQUklOVCgzLCAiXHRsaXN0
X2FkZCB0byAlcFxuIiwgY3VyLT5wcmV2KTsNCisgICAgLyogY3VyIG5vdyBjb250YWlucyB0aGUg
ZWxlbWVudCwgYmVmb3JlIHdoaWNoIHdlJ2xsIGVucXVldWUgKi8NCiAgICAgbGlzdF9hZGQoRVhU
UkFMSVNUKGQsaSksY3VyLT5wcmV2KTsNCiAgDQotICAgIC8qIENvbnRpbnVlIHVwZGF0aW5nIHRo
ZSBleHRyYXEuICovDQorICAgIC8qIENvbnRpbnVlIHVwZGF0aW5nIHRoZSBleHRyYXEgKi8NCiAg
ICAgaWYgKCAoY3VyICE9IEVYVFJBUShkLT5wcm9jZXNzb3IsaSkpICYmIHN1YiApDQogICAgIHsN
CiAgICAgICAgIGZvciAoIGN1ciA9IGN1ci0+bmV4dDsgY3VyICE9IEVYVFJBUShkLT5wcm9jZXNz
b3IsaSk7IGN1ciA9IGN1ci0+bmV4dCApDQogICAgICAgICB7DQogICAgICAgICAgICAgY3VyaW5m
ID0gbGlzdF9lbnRyeShjdXIsc3RydWN0IHNlZGZfdmNwdV9pbmZvLCBleHRyYWxpc3RbaV0pOw0K
ICAgICAgICAgICAgIGN1cmluZi0+c2NvcmVbaV0gLT0gc3ViOw0KLSAgICAgICAgICAgIFBSSU5U
KDQsICJcdHVwZGF0aW5nIGRvbWFpbiAlaS4laSAoc2NvcmU9ICV1KVxuIiwNCi0gICAgICAgICAg
ICAgICAgICBjdXJpbmYtPnZjcHUtPmRvbWFpbi0+ZG9tYWluX2lkLCANCi0gICAgICAgICAgICAg
ICAgICBjdXJpbmYtPnZjcHUtPnZjcHVfaWQsIGN1cmluZi0+c2NvcmVbaV0pOw0KICAgICAgICAg
fQ0KICAgICB9DQogDQpAQCAtMjIxLDI5ICsxOTksMTQgQEAgc3RhdGljIGlubGluZSB2b2lkIGV4
dHJhcV9jaGVjayhzdHJ1Y3Qgdg0KIHsNCiAgICAgaWYgKCBleHRyYXFfb24oZCwgRVhUUkFfVVRJ
TF9RKSApDQogICAgIHsNCi0gICAgICAgIFBSSU5UKDIsIkRvbSAlaS4laSBpcyBvbiBMMSBleHRy
YVFcbiIsDQotICAgICAgICAgICAgICBkLT5kb21haW4tPmRvbWFpbl9pZCwgZC0+dmNwdV9pZCk7
DQotDQogICAgICAgICBpZiAoICEoRURPTV9JTkZPKGQpLT5zdGF0dXMgJiBFWFRSQV9BV0FSRSkg
JiYNCiAgICAgICAgICAgICAgIWV4dHJhX3J1bnMoRURPTV9JTkZPKGQpKSApDQotICAgICAgICB7
DQogICAgICAgICAgICAgZXh0cmFxX2RlbChkLCBFWFRSQV9VVElMX1EpOw0KLSAgICAgICAgICAg
IFBSSU5UKDIsIlJlbW92ZWQgZG9tICVpLiVpIGZyb20gTDEgZXh0cmFRXG4iLA0KLSAgICAgICAg
ICAgICAgICAgIGQtPmRvbWFpbi0+ZG9tYWluX2lkLCBkLT52Y3B1X2lkKTsNCi0gICAgICAgIH0N
CiAgICAgfQ0KICAgICBlbHNlDQogICAgIHsNCi0gICAgICAgIFBSSU5UKDIsICJEb20gJWkuJWkg
aXMgTk9UIG9uIEwxIGV4dHJhUVxuIiwNCi0gICAgICAgICAgICAgIGQtPmRvbWFpbi0+ZG9tYWlu
X2lkLA0KLSAgICAgICAgICAgICAgZC0+dmNwdV9pZCk7DQotDQogICAgICAgICBpZiAoIChFRE9N
X0lORk8oZCktPnN0YXR1cyAmIEVYVFJBX0FXQVJFKSAmJiBzZWRmX3J1bm5hYmxlKGQpICkNCi0g
ICAgICAgIHsNCiAgICAgICAgICAgICBleHRyYXFfYWRkX3NvcnRfdXBkYXRlKGQsIEVYVFJBX1VU
SUxfUSwgMCk7DQotICAgICAgICAgICAgUFJJTlQoMiwiQWRkZWQgZG9tICVpLiVpIHRvIEwxIGV4
dHJhUVxuIiwNCi0gICAgICAgICAgICAgICAgICBkLT5kb21haW4tPmRvbWFpbl9pZCwgZC0+dmNw
dV9pZCk7DQotICAgICAgICB9DQogICAgIH0NCiB9DQogDQpAQCAtMjUyLDcgKzIxNSw3IEBAIHN0
YXRpYyBpbmxpbmUgdm9pZCBleHRyYXFfY2hlY2tfYWRkX3VuYmwNCiAgICAgc3RydWN0IHNlZGZf
dmNwdV9pbmZvICppbmYgPSBFRE9NX0lORk8oZCk7DQogDQogICAgIGlmICggaW5mLT5zdGF0dXMg
JiBFWFRSQV9BV0FSRSApDQotICAgICAgICAvKiBQdXQgb24gdGhlIHdlaWdodGVkIGV4dHJhcSB3
aXRob3V0IHVwZGF0aW5nIGFueSBzY29yZXMuICovDQorICAgICAgICAvKiBQdXQgb24gdGhlIHdl
aWdodGVkIGV4dHJhcSB3aXRob3V0IHVwZGF0aW5nIGFueSBzY29yZXMgKi8NCiAgICAgICAgIGV4
dHJhcV9hZGRfc29ydF91cGRhdGUoZCwgRVhUUkFfVVRJTF9RLCAwKTsNCiB9DQogDQpAQCAtMjY1
LDggKzIyOCw2IEBAIHN0YXRpYyBpbmxpbmUgdm9pZCBfX2RlbF9mcm9tX3F1ZXVlKHN0cnUNCiB7
DQogICAgIHN0cnVjdCBsaXN0X2hlYWQgKmxpc3QgPSBMSVNUKGQpOw0KICAgICBBU1NFUlQoX190
YXNrX29uX3F1ZXVlKGQpKTsNCi0gICAgUFJJTlQoMywiUmVtb3ZpbmcgZG9tYWluICVpLiVpIChi
b3A9ICUiUFJJdTY0IikgZnJvbSBydW5xL3dhaXRxXG4iLA0KLSAgICAgICAgICBkLT5kb21haW4t
PmRvbWFpbl9pZCwgZC0+dmNwdV9pZCwgUEVSSU9EX0JFR0lOKEVET01fSU5GTyhkKSkpOw0KICAg
ICBsaXN0X2RlbChsaXN0KTsNCiAgICAgbGlzdC0+bmV4dCA9IE5VTEw7DQogICAgIEFTU0VSVCgh
X190YXNrX29uX3F1ZXVlKGQpKTsNCkBAIC0yNzksMTMgKzI0MCwxMiBAQCBzdGF0aWMgaW5saW5l
IHZvaWQgbGlzdF9pbnNlcnRfc29ydCgNCiB7DQogICAgIHN0cnVjdCBsaXN0X2hlYWQgICAgICpj
dXI7DQogDQotICAgIC8qIEl0ZXJhdGUgdGhyb3VnaCBhbGwgZWxlbWVudHMgdG8gZmluZCBvdXIg
ImhvbGUiLiAqLw0KKyAgICAvKiBJdGVyYXRlIHRocm91Z2ggYWxsIGVsZW1lbnRzIHRvIGZpbmQg
b3VyICJob2xlIiAqLw0KICAgICBsaXN0X2Zvcl9lYWNoKCBjdXIsIGxpc3QgKQ0KICAgICAgICAg
aWYgKCBjb21wKGVsZW1lbnQsIGN1cikgPCAwICkNCiAgICAgICAgICAgICBicmVhazsNCiANCi0g
ICAgLyogY3VyIG5vdyBjb250YWlucyB0aGUgZWxlbWVudCwgYmVmb3JlIHdoaWNoIHdlJ2xsIGVu
cXVldWUuICovDQotICAgIFBSSU5UKDMsIlx0bGlzdF9hZGQgdG8gJXBcbiIsY3VyLT5wcmV2KTsN
CisgICAgLyogY3VyIG5vdyBjb250YWlucyB0aGUgZWxlbWVudCwgYmVmb3JlIHdoaWNoIHdlJ2xs
IGVucXVldWUgKi8NCiAgICAgbGlzdF9hZGQoZWxlbWVudCwgY3VyLT5wcmV2KTsNCiB9DQogDQpA
QCAtMzAzLDMwICsyNjMsMjYgQEAgc3RhdGljIGludCBuYW1lIyNfY29tcChzdHJ1Y3QgbGlzdF9o
ZWFkKg0KICAgICAgICAgcmV0dXJuIDE7ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIFwNCiB9DQogDQotLyogYWRkcyBhIGRvbWFpbiB0byB0aGUg
cXVldWUgb2YgcHJvY2Vzc2VzIHdoaWNoIHdhaXQgZm9yIHRoZSBiZWdpbm5pbmcgb2YgdGhlDQot
ICAgbmV4dCBwZXJpb2Q7IHRoaXMgbGlzdCBpcyB0aGVyZWZvcmUgc29ydGV0IGJ5IHRoaXMgdGlt
ZSwgd2hpY2ggaXMgc2ltcGx5DQotICAgYWJzb2wuIGRlYWRsaW5lIC0gcGVyaW9kDQorLyogQWRk
cyBhIGRvbWFpbiB0byB0aGUgcXVldWUgb2YgcHJvY2Vzc2VzIHdoaWNoIHdhaXQgZm9yIHRoZSBi
ZWdpbm5pbmcgb2YgdGhlDQorICogbmV4dCBwZXJpb2Q7IHRoaXMgbGlzdCBpcyB0aGVyZWZvcmUg
c29ydGV0IGJ5IHRoaXMgdGltZSwgd2hpY2ggaXMgc2ltcGx5DQorICogYWJzb2wuIGRlYWRsaW5l
IC0gcGVyaW9kLg0KICAqLyANCiBET01BSU5fQ09NUEFSRVIod2FpdHEsIGxpc3QsIFBFUklPRF9C
RUdJTihkMSksIFBFUklPRF9CRUdJTihkMikpOw0KIHN0YXRpYyBpbmxpbmUgdm9pZCBfX2FkZF90
b193YWl0cXVldWVfc29ydChzdHJ1Y3QgdmNwdSAqdikNCiB7DQogICAgIEFTU0VSVCghX190YXNr
X29uX3F1ZXVlKHYpKTsNCi0gICAgUFJJTlQoMywiQWRkaW5nIGRvbWFpbiAlaS4laSAoYm9wPSAl
IlBSSXU2NCIpIHRvIHdhaXRxXG4iLA0KLSAgICAgICAgICB2LT5kb21haW4tPmRvbWFpbl9pZCwg
di0+dmNwdV9pZCwgUEVSSU9EX0JFR0lOKEVET01fSU5GTyh2KSkpOw0KICAgICBsaXN0X2luc2Vy
dF9zb3J0KFdBSVRRKHYtPnByb2Nlc3NvciksIExJU1QodiksIHdhaXRxX2NvbXApOw0KICAgICBB
U1NFUlQoX190YXNrX29uX3F1ZXVlKHYpKTsNCiB9DQogDQotLyogYWRkcyBhIGRvbWFpbiB0byB0
aGUgcXVldWUgb2YgcHJvY2Vzc2VzIHdoaWNoIGhhdmUgc3RhcnRlZCB0aGVpciBjdXJyZW50DQot
ICAgcGVyaW9kIGFuZCBhcmUgcnVubmFibGUgKGkuZS4gbm90IGJsb2NrZWQsIGRpZWluZywuLi4p
LiBUaGUgZmlyc3QgZWxlbWVudA0KLSAgIG9uIHRoaXMgbGlzdCBpcyBydW5uaW5nIG9uIHRoZSBw
cm9jZXNzb3IsIGlmIHRoZSBsaXN0IGlzIGVtcHR5IHRoZSBpZGxlDQotICAgdGFzayB3aWxsIHJ1
bi4gQXMgd2UgYXJlIGltcGxlbWVudGluZyBFREYsIHRoaXMgbGlzdCBpcyBzb3J0ZWQgYnkgZGVh
ZGxpbmVzLg0KKy8qIEFkZHMgYSBkb21haW4gdG8gdGhlIHF1ZXVlIG9mIHByb2Nlc3NlcyB3aGlj
aCBoYXZlIHN0YXJ0ZWQgdGhlaXIgY3VycmVudA0KKyAqIHBlcmlvZCBhbmQgYXJlIHJ1bm5hYmxl
IChpLmUuIG5vdCBibG9ja2VkLCBkaWVpbmcsLi4uKS4gVGhlIGZpcnN0IGVsZW1lbnQNCisgKiBv
biB0aGlzIGxpc3QgaXMgcnVubmluZyBvbiB0aGUgcHJvY2Vzc29yLCBpZiB0aGUgbGlzdCBpcyBl
bXB0eSB0aGUgaWRsZQ0KKyAqIHRhc2sgd2lsbCBydW4uIEFzIHdlIGFyZSBpbXBsZW1lbnRpbmcg
RURGLCB0aGlzIGxpc3QgaXMgc29ydGVkIGJ5IGRlYWRsaW5lcy4NCiAgKi8gDQogRE9NQUlOX0NP
TVBBUkVSKHJ1bnEsIGxpc3QsIGQxLT5kZWFkbF9hYnMsIGQyLT5kZWFkbF9hYnMpOw0KIHN0YXRp
YyBpbmxpbmUgdm9pZCBfX2FkZF90b19ydW5xdWV1ZV9zb3J0KHN0cnVjdCB2Y3B1ICp2KQ0KIHsN
Ci0gICAgUFJJTlQoMywiQWRkaW5nIGRvbWFpbiAlaS4laSAoZGVhZGw9ICUiUFJJdTY0IikgdG8g
cnVucVxuIiwNCi0gICAgICAgICAgdi0+ZG9tYWluLT5kb21haW5faWQsIHYtPnZjcHVfaWQsIEVE
T01fSU5GTyh2KS0+ZGVhZGxfYWJzKTsNCiAgICAgbGlzdF9pbnNlcnRfc29ydChSVU5RKHYtPnBy
b2Nlc3NvciksIExJU1QodiksIHJ1bnFfY29tcCk7DQogfQ0KIA0KQEAgLTQ0NSwyMiArNDAxLDIx
IEBAIHN0YXRpYyBpbnQgc2VkZl9waWNrX2NwdShjb25zdCBzdHJ1Y3Qgc2MNCiAgICAgcmV0dXJu
IGNwdW1hc2tfZmlyc3QoJm9ubGluZV9hZmZpbml0eSk7DQogfQ0KIA0KLS8qDQotICogSGFuZGxl
cyB0aGUgcmVzY2hlZHVsaW5nICYgYm9va2tlZXBpbmcgb2YgZG9tYWlucyBydW5uaW5nIGluIHRo
ZWlyDQorDQorLyogSGFuZGxlcyB0aGUgcmVzY2hlZHVsaW5nICYgYm9va2tlZXBpbmcgb2YgZG9t
YWlucyBydW5uaW5nIGluIHRoZWlyDQogICogZ3VhcmFudGVlZCB0aW1lc2xpY2UuDQogICovDQog
c3RhdGljIHZvaWQgZGVzY2hlZF9lZGZfZG9tKHNfdGltZV90IG5vdywgc3RydWN0IHZjcHUqIGQp
DQogew0KICAgICBzdHJ1Y3Qgc2VkZl92Y3B1X2luZm8qIGluZiA9IEVET01fSU5GTyhkKTsNCiAN
Ci0gICAgLyogQ3VycmVudCBkb21haW4gaXMgcnVubmluZyBpbiByZWFsIHRpbWUgbW9kZS4gKi8N
CisgICAgLyogQ3VycmVudCBkb21haW4gaXMgcnVubmluZyBpbiByZWFsIHRpbWUgbW9kZSAqLw0K
ICAgICBBU1NFUlQoX190YXNrX29uX3F1ZXVlKGQpKTsNCiANCi0gICAgLyogVXBkYXRlIHRoZSBk
b21haW4ncyBjcHV0aW1lLiAqLw0KKyAgICAvKiBVcGRhdGUgdGhlIGRvbWFpbidzIGNwdXRpbWUg
Ki8NCiAgICAgaW5mLT5jcHV0aW1lICs9IG5vdyAtIGluZi0+c2NoZWRfc3RhcnRfYWJzOw0KIA0K
LSAgICAvKg0KLSAgICAgKiBTY2hlZHVsaW5nIGRlY2lzaW9ucyB3aGljaCBkb24ndCByZW1vdmUg
dGhlIHJ1bm5pbmcgZG9tYWluIGZyb20gdGhlDQorICAgIC8qIFNjaGVkdWxpbmcgZGVjaXNpb25z
IHdoaWNoIGRvbid0IHJlbW92ZSB0aGUgcnVubmluZyBkb21haW4gZnJvbSB0aGUNCiAgICAgICog
cnVucS4gDQogICAgICAqLw0KICAgICBpZiAoIChpbmYtPmNwdXRpbWUgPCBpbmYtPnNsaWNlKSAm
JiBzZWRmX3J1bm5hYmxlKGQpICkNCkBAIC00NjgsOCArNDIzLDcgQEAgc3RhdGljIHZvaWQgZGVz
Y2hlZF9lZGZfZG9tKHNfdGltZV90IG5vdw0KICAgDQogICAgIF9fZGVsX2Zyb21fcXVldWUoZCk7
DQogICANCi0gICAgLyoNCi0gICAgICogTWFuYWdlIGJvb2trZWVwaW5nIChpLmUuIGNhbGN1bGF0
ZSBuZXh0IGRlYWRsaW5lLCBtZW1vcmlzZQ0KKyAgICAvKiBNYW5hZ2UgYm9va2tlZXBpbmcgKGku
ZS4gY2FsY3VsYXRlIG5leHQgZGVhZGxpbmUsIG1lbW9yaXNlDQogICAgICAqIG92ZXJydW4tdGlt
ZSBvZiBzbGljZSkgb2YgZmluaXNoZWQgZG9tYWlucy4NCiAgICAgICovDQogICAgIGlmICggaW5m
LT5jcHV0aW1lID49IGluZi0+c2xpY2UgKQ0KQEAgLTQ3OCwzMCArNDMyLDMwIEBAIHN0YXRpYyB2
b2lkIGRlc2NoZWRfZWRmX2RvbShzX3RpbWVfdCBub3cNCiAgIA0KICAgICAgICAgaWYgKCBpbmYt
PnBlcmlvZCA8IGluZi0+cGVyaW9kX29yaWcgKQ0KICAgICAgICAgew0KLSAgICAgICAgICAgIC8q
IFRoaXMgZG9tYWluIHJ1bnMgaW4gbGF0ZW5jeSBzY2FsaW5nIG9yIGJ1cnN0IG1vZGUuICovDQor
ICAgICAgICAgICAgLyogVGhpcyBkb21haW4gcnVucyBpbiBsYXRlbmN5IHNjYWxpbmcgb3IgYnVy
c3QgbW9kZSAqLw0KICAgICAgICAgICAgIGluZi0+cGVyaW9kICo9IDI7DQogICAgICAgICAgICAg
aW5mLT5zbGljZSAgKj0gMjsNCiAgICAgICAgICAgICBpZiAoIChpbmYtPnBlcmlvZCA+IGluZi0+
cGVyaW9kX29yaWcpIHx8DQogICAgICAgICAgICAgICAgICAoaW5mLT5zbGljZSA+IGluZi0+c2xp
Y2Vfb3JpZykgKQ0KICAgICAgICAgICAgIHsNCi0gICAgICAgICAgICAgICAgLyogUmVzZXQgc2xp
Y2UgYW5kIHBlcmlvZC4gKi8NCisgICAgICAgICAgICAgICAgLyogUmVzZXQgc2xpY2UgYW5kIHBl
cmlvZCAqLw0KICAgICAgICAgICAgICAgICBpbmYtPnBlcmlvZCA9IGluZi0+cGVyaW9kX29yaWc7
DQogICAgICAgICAgICAgICAgIGluZi0+c2xpY2UgPSBpbmYtPnNsaWNlX29yaWc7DQogICAgICAg
ICAgICAgfQ0KICAgICAgICAgfQ0KIA0KLSAgICAgICAgLyogU2V0IG5leHQgZGVhZGxpbmUuICov
DQorICAgICAgICAvKiBTZXQgbmV4dCBkZWFkbGluZSAqLw0KICAgICAgICAgaW5mLT5kZWFkbF9h
YnMgKz0gaW5mLT5wZXJpb2Q7DQogICAgIH0NCiAgDQotICAgIC8qIEFkZCBhIHJ1bm5hYmxlIGRv
bWFpbiB0byB0aGUgd2FpdHF1ZXVlLiAqLw0KKyAgICAvKiBBZGQgYSBydW5uYWJsZSBkb21haW4g
dG8gdGhlIHdhaXRxdWV1ZSAqLw0KICAgICBpZiAoIHNlZGZfcnVubmFibGUoZCkgKQ0KICAgICB7
DQogICAgICAgICBfX2FkZF90b193YWl0cXVldWVfc29ydChkKTsNCiAgICAgfQ0KICAgICBlbHNl
DQogICAgIHsNCi0gICAgICAgIC8qIFdlIGhhdmUgYSBibG9ja2VkIHJlYWx0aW1lIHRhc2sgLT4g
cmVtb3ZlIGl0IGZyb20gZXhxcyB0b28uICovDQorICAgICAgICAvKiBXZSBoYXZlIGEgYmxvY2tl
ZCByZWFsdGltZSB0YXNrIC0+IHJlbW92ZSBpdCBmcm9tIGV4cXMgdG9vICovDQogICAgICAgICBp
ZiAoIGV4dHJhcV9vbihkLCBFWFRSQV9QRU5fUSkgKQ0KICAgICAgICAgICAgIGV4dHJhcV9kZWwo
ZCwgRVhUUkFfUEVOX1EpOw0KICAgICAgICAgaWYgKCBleHRyYXFfb24oZCwgRVhUUkFfVVRJTF9R
KSApDQpAQCAtNTIxLDczICs0NzUsNTkgQEAgc3RhdGljIHZvaWQgdXBkYXRlX3F1ZXVlcygNCiAg
ICAgc3RydWN0IGxpc3RfaGVhZCAgICAgKmN1ciwgKnRtcDsNCiAgICAgc3RydWN0IHNlZGZfdmNw
dV9pbmZvICpjdXJpbmY7DQogIA0KLSAgICBQUklOVCgzLCJVcGRhdGluZyB3YWl0cS4uXG4iKTsN
Ci0NCi0gICAgLyoNCi0gICAgICogQ2hlY2sgZm9yIHRoZSBmaXJzdCBlbGVtZW50cyBvZiB0aGUg
d2FpdHF1ZXVlLCB3aGV0aGVyIHRoZWlyDQorICAgIC8qIENoZWNrIGZvciB0aGUgZmlyc3QgZWxl
bWVudHMgb2YgdGhlIHdhaXRxdWV1ZSwgd2hldGhlciB0aGVpcg0KICAgICAgKiBuZXh0IHBlcmlv
ZCBoYXMgYWxyZWFkeSBzdGFydGVkLg0KICAgICAgKi8NCiAgICAgbGlzdF9mb3JfZWFjaF9zYWZl
ICggY3VyLCB0bXAsIHdhaXRxICkNCiAgICAgew0KICAgICAgICAgY3VyaW5mID0gbGlzdF9lbnRy
eShjdXIsIHN0cnVjdCBzZWRmX3ZjcHVfaW5mbywgbGlzdCk7DQotICAgICAgICBQUklOVCg0LCJc
dExvb2tpbmcgQCBkb20gJWkuJWlcbiIsDQotICAgICAgICAgICAgICBjdXJpbmYtPnZjcHUtPmRv
bWFpbi0+ZG9tYWluX2lkLCBjdXJpbmYtPnZjcHUtPnZjcHVfaWQpOw0KICAgICAgICAgaWYgKCBQ
RVJJT0RfQkVHSU4oY3VyaW5mKSA+IG5vdyApDQogICAgICAgICAgICAgYnJlYWs7DQogICAgICAg
ICBfX2RlbF9mcm9tX3F1ZXVlKGN1cmluZi0+dmNwdSk7DQogICAgICAgICBfX2FkZF90b19ydW5x
dWV1ZV9zb3J0KGN1cmluZi0+dmNwdSk7DQogICAgIH0NCiAgDQotICAgIFBSSU5UKDMsIlVwZGF0
aW5nIHJ1bnEuLlxuIik7DQotDQotICAgIC8qIFByb2Nlc3MgdGhlIHJ1bnEsIGZpbmQgZG9tYWlu
cyB0aGF0IGFyZSBvbiB0aGUgcnVucSB0aGF0IHNob3VsZG4ndC4gKi8NCisgICAgLyogUHJvY2Vz
cyB0aGUgcnVucSwgZmluZCBkb21haW5zIHRoYXQgYXJlIG9uIHRoZSBydW5xIHRoYXQgc2hvdWxk
bid0ICovDQogICAgIGxpc3RfZm9yX2VhY2hfc2FmZSAoIGN1ciwgdG1wLCBydW5xICkNCiAgICAg
ew0KICAgICAgICAgY3VyaW5mID0gbGlzdF9lbnRyeShjdXIsc3RydWN0IHNlZGZfdmNwdV9pbmZv
LGxpc3QpOw0KLSAgICAgICAgUFJJTlQoNCwiXHRMb29raW5nIEAgZG9tICVpLiVpXG4iLA0KLSAg
ICAgICAgICAgICAgY3VyaW5mLT52Y3B1LT5kb21haW4tPmRvbWFpbl9pZCwgY3VyaW5mLT52Y3B1
LT52Y3B1X2lkKTsNCiANCiAgICAgICAgIGlmICggdW5saWtlbHkoY3VyaW5mLT5zbGljZSA9PSAw
KSApDQogICAgICAgICB7DQotICAgICAgICAgICAgLyogSWdub3JlIGRvbWFpbnMgd2l0aCBlbXB0
eSBzbGljZS4gKi8NCi0gICAgICAgICAgICBQUklOVCg0LCJcdFVwZGF0aW5nIHplcm8tc2xpY2Ug
ZG9tYWluICVpLiVpXG4iLA0KLSAgICAgICAgICAgICAgICAgIGN1cmluZi0+dmNwdS0+ZG9tYWlu
LT5kb21haW5faWQsDQotICAgICAgICAgICAgICAgICAgY3VyaW5mLT52Y3B1LT52Y3B1X2lkKTsN
CisgICAgICAgICAgICAvKiBJZ25vcmUgZG9tYWlucyB3aXRoIGVtcHR5IHNsaWNlICovDQogICAg
ICAgICAgICAgX19kZWxfZnJvbV9xdWV1ZShjdXJpbmYtPnZjcHUpOw0KIA0KLSAgICAgICAgICAg
IC8qIE1vdmUgdGhlbSB0byB0aGVpciBuZXh0IHBlcmlvZC4gKi8NCisgICAgICAgICAgICAvKiBN
b3ZlIHRoZW0gdG8gdGhlaXIgbmV4dCBwZXJpb2QgKi8NCiAgICAgICAgICAgICBjdXJpbmYtPmRl
YWRsX2FicyArPSBjdXJpbmYtPnBlcmlvZDsNCiANCi0gICAgICAgICAgICAvKiBFbnN1cmUgdGhh
dCB0aGUgc3RhcnQgb2YgdGhlIG5leHQgcGVyaW9kIGlzIGluIHRoZSBmdXR1cmUuICovDQorICAg
ICAgICAgICAgLyogRW5zdXJlIHRoYXQgdGhlIHN0YXJ0IG9mIHRoZSBuZXh0IHBlcmlvZCBpcyBp
biB0aGUgZnV0dXJlICovDQogICAgICAgICAgICAgaWYgKCB1bmxpa2VseShQRVJJT0RfQkVHSU4o
Y3VyaW5mKSA8IG5vdykgKQ0KICAgICAgICAgICAgICAgICBjdXJpbmYtPmRlYWRsX2FicyArPSAN
CiAgICAgICAgICAgICAgICAgICAgIChESVZfVVAobm93IC0gUEVSSU9EX0JFR0lOKGN1cmluZiks
DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgIGN1cmluZi0+cGVyaW9kKSkgKiBjdXJpbmYt
PnBlcmlvZDsNCiANCi0gICAgICAgICAgICAvKiBQdXQgdGhlbSBiYWNrIGludG8gdGhlIHF1ZXVl
LiAqLw0KKyAgICAgICAgICAgIC8qIFB1dCB0aGVtIGJhY2sgaW50byB0aGUgcXVldWUgKi8NCiAg
ICAgICAgICAgICBfX2FkZF90b193YWl0cXVldWVfc29ydChjdXJpbmYtPnZjcHUpOw0KICAgICAg
ICAgfQ0KICAgICAgICAgZWxzZSBpZiAoIHVubGlrZWx5KChjdXJpbmYtPmRlYWRsX2FicyA8IG5v
dykgfHwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAoY3VyaW5mLT5jcHV0aW1lID4gY3Vy
aW5mLT5zbGljZSkpICkNCiAgICAgICAgIHsNCi0gICAgICAgICAgICAvKg0KLSAgICAgICAgICAg
ICAqIFdlIG1pc3NlZCB0aGUgZGVhZGxpbmUgb3IgdGhlIHNsaWNlIHdhcyBhbHJlYWR5IGZpbmlz
aGVkLg0KKyAgICAgICAgICAgIC8qIFdlIG1pc3NlZCB0aGUgZGVhZGxpbmUgb3IgdGhlIHNsaWNl
IHdhcyBhbHJlYWR5IGZpbmlzaGVkLg0KICAgICAgICAgICAgICAqIE1pZ2h0IGhhcGVuIGJlY2F1
c2Ugb2YgZG9tX2Fkai4NCiAgICAgICAgICAgICAgKi8NCi0gICAgICAgICAgICBQUklOVCg0LCJc
dERvbWFpbiAlaS4laSBleGNlZWRlZCBpdCdzIGRlYWRsaW5lLyINCi0gICAgICAgICAgICAgICAg
ICAic2xpY2UgKCUiUFJJdTY0IiAvICUiUFJJdTY0Iikgbm93OiAlIlBSSXU2NA0KLSAgICAgICAg
ICAgICAgICAgICIgY3B1dGltZTogJSJQUkl1NjQiXG4iLA0KLSAgICAgICAgICAgICAgICAgIGN1
cmluZi0+dmNwdS0+ZG9tYWluLT5kb21haW5faWQsDQotICAgICAgICAgICAgICAgICAgY3VyaW5m
LT52Y3B1LT52Y3B1X2lkLA0KLSAgICAgICAgICAgICAgICAgIGN1cmluZi0+ZGVhZGxfYWJzLCBj
dXJpbmYtPnNsaWNlLCBub3csDQotICAgICAgICAgICAgICAgICAgY3VyaW5mLT5jcHV0aW1lKTsN
CisgICAgICAgICAgICBwcmludGsoIlx0RG9tYWluICVpLiVpIGV4Y2VlZGVkIGl0J3MgZGVhZGxp
bmUvIg0KKyAgICAgICAgICAgICAgICAgICAic2xpY2UgKCUiUFJJdTY0IiAvICUiUFJJdTY0Iikg
bm93OiAlIlBSSXU2NA0KKyAgICAgICAgICAgICAgICAgICAiIGNwdXRpbWU6ICUiUFJJdTY0Ilxu
IiwNCisgICAgICAgICAgICAgICAgICAgY3VyaW5mLT52Y3B1LT5kb21haW4tPmRvbWFpbl9pZCwN
CisgICAgICAgICAgICAgICAgICAgY3VyaW5mLT52Y3B1LT52Y3B1X2lkLA0KKyAgICAgICAgICAg
ICAgICAgICBjdXJpbmYtPmRlYWRsX2FicywgY3VyaW5mLT5zbGljZSwgbm93LA0KKyAgICAgICAg
ICAgICAgICAgICBjdXJpbmYtPmNwdXRpbWUpOw0KICAgICAgICAgICAgIF9fZGVsX2Zyb21fcXVl
dWUoY3VyaW5mLT52Y3B1KTsNCiANCi0gICAgICAgICAgICAvKiBDb21tb24gY2FzZTogd2UgbWlz
cyBvbmUgcGVyaW9kLiAqLw0KKyAgICAgICAgICAgIC8qIENvbW1vbiBjYXNlOiB3ZSBtaXNzIG9u
ZSBwZXJpb2QgKi8NCiAgICAgICAgICAgICBjdXJpbmYtPmRlYWRsX2FicyArPSBjdXJpbmYtPnBl
cmlvZDsNCiAgICANCi0gICAgICAgICAgICAvKg0KLSAgICAgICAgICAgICAqIElmIHdlIGFyZSBz
dGlsbCBiZWhpbmQ6IG1vZHVsbyBhcml0aG1ldGljLCBmb3JjZSBkZWFkbGluZQ0KKyAgICAgICAg
ICAgIC8qIElmIHdlIGFyZSBzdGlsbCBiZWhpbmQ6IG1vZHVsbyBhcml0aG1ldGljLCBmb3JjZSBk
ZWFkbGluZQ0KICAgICAgICAgICAgICAqIHRvIGJlIGluIGZ1dHVyZSBhbmQgYWxpZ25lZCB0byBw
ZXJpb2QgYm9yZGVycy4NCiAgICAgICAgICAgICAgKi8NCiAgICAgICAgICAgICBpZiAoIHVubGlr
ZWx5KGN1cmluZi0+ZGVhZGxfYWJzIDwgbm93KSApDQpAQCAtNTk2LDcgKzUzNiw3IEBAIHN0YXRp
YyB2b2lkIHVwZGF0ZV9xdWV1ZXMoDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgY3VyaW5m
LT5wZXJpb2QpICogY3VyaW5mLT5wZXJpb2Q7DQogICAgICAgICAgICAgQVNTRVJUKGN1cmluZi0+
ZGVhZGxfYWJzID49IG5vdyk7DQogDQotICAgICAgICAgICAgLyogR2l2ZSBhIGZyZXNoIHNsaWNl
LiAqLw0KKyAgICAgICAgICAgIC8qIEdpdmUgYSBmcmVzaCBzbGljZSAqLw0KICAgICAgICAgICAg
IGN1cmluZi0+Y3B1dGltZSA9IDA7DQogICAgICAgICAgICAgaWYgKCBQRVJJT0RfQkVHSU4oY3Vy
aW5mKSA+IG5vdyApDQogICAgICAgICAgICAgICAgIF9fYWRkX3RvX3dhaXRxdWV1ZV9zb3J0KGN1
cmluZi0+dmNwdSk7DQpAQCAtNjA2LDE3ICs1NDYsMTYgQEAgc3RhdGljIHZvaWQgdXBkYXRlX3F1
ZXVlcygNCiAgICAgICAgIGVsc2UNCiAgICAgICAgICAgICBicmVhazsNCiAgICAgfQ0KLQ0KLSAg
ICBQUklOVCgzLCJkb25lIHVwZGF0aW5nIHRoZSBxdWV1ZXNcbiIpOw0KIH0NCiANCiANCiAvKiBy
ZW1vdmVzIGEgZG9tYWluIGZyb20gdGhlIGhlYWQgb2YgdGhlIGFjY29yZGluZyBleHRyYVEgYW5k
DQotICAgcmVxdWV1ZXMgaXQgYXQgYSBzcGVjaWZpZWQgcG9zaXRpb246DQotICAgICByb3VuZC1y
b2JpbiBleHRyYXRpbWU6IGVuZCBvZiBleHRyYVENCi0gICAgIHdlaWdodGVkIGV4dC46IGluc2Vy
dCBpbiBzb3J0ZWQgbGlzdCBieSBzY29yZQ0KLSAgIGlmIHRoZSBkb21haW4gaXMgYmxvY2tlZCAv
IGhhcyByZWdhaW5lZCBpdHMgc2hvcnQtYmxvY2stbG9zcw0KLSAgIHRpbWUgaXQgaXMgbm90IHB1
dCBvbiBhbnkgcXVldWUgKi8NCisgKiByZXF1ZXVlcyBpdCBhdCBhIHNwZWNpZmllZCBwb3NpdGlv
bjoNCisgKiAgIHJvdW5kLXJvYmluIGV4dHJhdGltZTogZW5kIG9mIGV4dHJhUQ0KKyAqICAgd2Vp
Z2h0ZWQgZXh0LjogaW5zZXJ0IGluIHNvcnRlZCBsaXN0IGJ5IHNjb3JlDQorICogaWYgdGhlIGRv
bWFpbiBpcyBibG9ja2VkIC8gaGFzIHJlZ2FpbmVkIGl0cyBzaG9ydC1ibG9jay1sb3NzDQorICog
dGltZSBpdCBpcyBub3QgcHV0IG9uIGFueSBxdWV1ZS4NCisgKi8NCiBzdGF0aWMgdm9pZCBkZXNj
aGVkX2V4dHJhX2RvbShzX3RpbWVfdCBub3csIHN0cnVjdCB2Y3B1ICpkKQ0KIHsNCiAgICAgc3Ry
dWN0IHNlZGZfdmNwdV9pbmZvICppbmYgPSBFRE9NX0lORk8oZCk7DQpAQCAtNjI1LDI5ICs1NjQs
MjUgQEAgc3RhdGljIHZvaWQgZGVzY2hlZF9leHRyYV9kb20oc190aW1lX3Qgbg0KIA0KICAgICBB
U1NFUlQoZXh0cmFxX29uKGQsIGkpKTsNCiANCi0gICAgLyogVW5zZXQgYWxsIHJ1bm5pbmcgZmxh
Z3MuICovDQorICAgIC8qIFVuc2V0IGFsbCBydW5uaW5nIGZsYWdzICovDQogICAgIGluZi0+c3Rh
dHVzICAmPSB+KEVYVFJBX1JVTl9QRU4gfCBFWFRSQV9SVU5fVVRJTCk7DQotICAgIC8qIEZyZXNo
IHNsaWNlIGZvciB0aGUgbmV4dCBydW4uICovDQorICAgIC8qIEZyZXNoIHNsaWNlIGZvciB0aGUg
bmV4dCBydW4gKi8NCiAgICAgaW5mLT5jcHV0aW1lID0gMDsNCi0gICAgLyogQWNjdW11bGF0ZSB0
b3RhbCBleHRyYXRpbWUuICovDQorICAgIC8qIEFjY3VtdWxhdGUgdG90YWwgZXh0cmF0aW1lICov
DQogICAgIGluZi0+ZXh0cmFfdGltZV90b3QgKz0gbm93IC0gaW5mLT5zY2hlZF9zdGFydF9hYnM7
DQogICAgIC8qIFJlbW92ZSBleHRyYWRvbWFpbiBmcm9tIGhlYWQgb2YgdGhlIHF1ZXVlLiAqLw0K
ICAgICBleHRyYXFfZGVsKGQsIGkpOw0KIA0KLSAgICAvKiBVcGRhdGUgdGhlIHNjb3JlLiAqLw0K
KyAgICAvKiBVcGRhdGUgdGhlIHNjb3JlICovDQogICAgIG9sZHNjb3JlID0gaW5mLT5zY29yZVtp
XTsNCiAgICAgaWYgKCBpID09IEVYVFJBX1BFTl9RICkNCiAgICAgew0KLSAgICAgICAgLypkb21h
aW4gd2FzIHJ1bm5pbmcgaW4gTDAgZXh0cmFxKi8NCi0gICAgICAgIC8qcmVkdWNlIGJsb2NrIGxv
c3QsIHByb2JhYmx5IG1vcmUgc29waGlzdGljYXRpb24gaGVyZSEqLw0KKyAgICAgICAgLyogRG9t
YWluIHdhcyBydW5uaW5nIGluIEwwIGV4dHJhcSAqLw0KKyAgICAgICAgLyogcmVkdWNlIGJsb2Nr
IGxvc3QsIHByb2JhYmx5IG1vcmUgc29waGlzdGljYXRpb24gaGVyZSEqLw0KICAgICAgICAgLypp
bmYtPnNob3J0X2Jsb2NrX2xvc3RfdG90IC09IEVYVFJBX1FVQU5UVU07Ki8NCiAgICAgICAgIGlu
Zi0+c2hvcnRfYmxvY2tfbG9zdF90b3QgLT0gbm93IC0gaW5mLT5zY2hlZF9zdGFydF9hYnM7DQot
ICAgICAgICBQUklOVCgzLCJEb21haW4gJWkuJWk6IFNob3J0X2Jsb2NrX2xvc3M6ICUiUFJJaTY0
IlxuIiwgDQotICAgICAgICAgICAgICBpbmYtPnZjcHUtPmRvbWFpbi0+ZG9tYWluX2lkLCBpbmYt
PnZjcHUtPnZjcHVfaWQsDQotICAgICAgICAgICAgICBpbmYtPnNob3J0X2Jsb2NrX2xvc3RfdG90
KTsNCiAjaWYgMA0KLSAgICAgICAgLyoNCi0gICAgICAgICAqIEtBRjogSWYgd2UgZG9uJ3QgZXhp
dCBzaG9ydC1ibG9ja2luZyBzdGF0ZSBhdCB0aGlzIHBvaW50DQorICAgICAgICAvKiBLQUY6IElm
IHdlIGRvbid0IGV4aXQgc2hvcnQtYmxvY2tpbmcgc3RhdGUgYXQgdGhpcyBwb2ludA0KICAgICAg
ICAgICogZG9tYWluMCBjYW4gc3RlYWwgYWxsIENQVSBmb3IgdXAgdG8gMTAgc2Vjb25kcyBiZWZv
cmUNCiAgICAgICAgICAqIHNjaGVkdWxpbmcgc2V0dGxlcyBkb3duICh3aGVuIGNvbXBldGluZyBh
Z2FpbnN0IGFub3RoZXINCiAgICAgICAgICAqIENQVS1ib3VuZCBkb21haW4pLiBEb2luZyB0aGlz
IHNlZW1zIHRvIG1ha2UgdGhpbmdzIGJlaGF2ZQ0KQEAgLTY1Niw1MSArNTkxLDU2IEBAIHN0YXRp
YyB2b2lkIGRlc2NoZWRfZXh0cmFfZG9tKHNfdGltZV90IG4NCiAgICAgICAgIGlmICggaW5mLT5z
aG9ydF9ibG9ja19sb3N0X3RvdCA8PSAwICkNCiAjZW5kaWYNCiAgICAgICAgIHsNCi0gICAgICAg
ICAgICBQUklOVCg0LCJEb21haW4gJWkuJWkgY29tcGVuc2F0ZWQgc2hvcnQgYmxvY2sgbG9zcyFc
biIsDQotICAgICAgICAgICAgICAgICAgaW5mLT52Y3B1LT5kb21haW4tPmRvbWFpbl9pZCwgaW5m
LT52Y3B1LT52Y3B1X2lkKTsNCi0gICAgICAgICAgICAvKndlIGhhdmUgKG92ZXItKWNvbXBlbnNh
dGVkIG91ciBibG9jayBwZW5hbHR5Ki8NCisgICAgICAgICAgICAvKiBXZSBoYXZlIChvdmVyLSlj
b21wZW5zYXRlZCBvdXIgYmxvY2sgcGVuYWx0eSAqLw0KICAgICAgICAgICAgIGluZi0+c2hvcnRf
YmxvY2tfbG9zdF90b3QgPSAwOw0KLSAgICAgICAgICAgIC8qd2UgZG9uJ3Qgd2FudCBhIHBsYWNl
IG9uIHRoZSBwZW5hbHR5IHF1ZXVlIGFueW1vcmUhKi8NCisgICAgICAgICAgICAvKiBXZSBkb24n
dCB3YW50IGEgcGxhY2Ugb24gdGhlIHBlbmFsdHkgcXVldWUgYW55bW9yZSEgKi8NCiAgICAgICAg
ICAgICBpbmYtPnN0YXR1cyAmPSB+RVhUUkFfV0FOVF9QRU5fUTsNCiAgICAgICAgICAgICBnb3Rv
IGNoZWNrX2V4dHJhX3F1ZXVlczsNCiAgICAgICAgIH0NCiANCi0gICAgICAgIC8qd2UgaGF2ZSB0
byBnbyBhZ2FpbiBmb3IgYW5vdGhlciB0cnkgaW4gdGhlIGJsb2NrLWV4dHJhcSwNCi0gICAgICAg
ICAgdGhlIHNjb3JlIGlzIG5vdCB1c2VkIGluY3JlbWFudGFsbHkgaGVyZSwgYXMgdGhpcyBpcw0K
LSAgICAgICAgICBhbHJlYWR5IGRvbmUgYnkgcmVjYWxjdWxhdGluZyB0aGUgYmxvY2tfbG9zdCov
DQorICAgICAgICAvKiBXZSBoYXZlIHRvIGdvIGFnYWluIGZvciBhbm90aGVyIHRyeSBpbiB0aGUg
YmxvY2stZXh0cmFxLA0KKyAgICAgICAgICogdGhlIHNjb3JlIGlzIG5vdCB1c2VkIGluY3JlbWFu
dGFsbHkgaGVyZSwgYXMgdGhpcyBpcw0KKyAgICAgICAgICogYWxyZWFkeSBkb25lIGJ5IHJlY2Fs
Y3VsYXRpbmcgdGhlIGJsb2NrX2xvc3QNCisgICAgICAgICAqLw0KICAgICAgICAgaW5mLT5zY29y
ZVtFWFRSQV9QRU5fUV0gPSAoaW5mLT5wZXJpb2QgPDwgMTApIC8NCiAgICAgICAgICAgICBpbmYt
PnNob3J0X2Jsb2NrX2xvc3RfdG90Ow0KICAgICAgICAgb2xkc2NvcmUgPSAwOw0KICAgICB9DQog
ICAgIGVsc2UNCiAgICAgew0KLSAgICAgICAgLypkb21haW4gd2FzIHJ1bm5pbmcgaW4gTDEgZXh0
cmFxID0+IHNjb3JlIGlzIGludmVyc2Ugb2YNCi0gICAgICAgICAgdXRpbGl6YXRpb24gYW5kIGlz
IHVzZWQgc29tZXdoYXQgaW5jcmVtZW50YWwhKi8NCisgICAgICAgIC8qIERvbWFpbiB3YXMgcnVu
bmluZyBpbiBMMSBleHRyYXEgPT4gc2NvcmUgaXMgaW52ZXJzZSBvZg0KKyAgICAgICAgICogdXRp
bGl6YXRpb24gYW5kIGlzIHVzZWQgc29tZXdoYXQgaW5jcmVtZW50YWwhDQorICAgICAgICAgKi8N
CiAgICAgICAgIGlmICggIWluZi0+ZXh0cmF3ZWlnaHQgKQ0KLSAgICAgICAgICAgIC8qTkI6IHVz
ZSBmaXhlZCBwb2ludCBhcml0aG1ldGljIHdpdGggMTAgYml0cyovDQorICAgICAgICB7DQorICAg
ICAgICAgICAgLyogTkI6IHVzZSBmaXhlZCBwb2ludCBhcml0aG1ldGljIHdpdGggMTAgYml0cyAq
Lw0KICAgICAgICAgICAgIGluZi0+c2NvcmVbRVhUUkFfVVRJTF9RXSA9IChpbmYtPnBlcmlvZCA8
PCAxMCkgLw0KICAgICAgICAgICAgICAgICBpbmYtPnNsaWNlOw0KKyAgICAgICAgfQ0KICAgICAg
ICAgZWxzZQ0KLSAgICAgICAgICAgIC8qY29udmVyc2lvbiBiZXR3ZWVuIHJlYWx0aW1lIHV0aWxp
c2F0aW9uIGFuZCBleHRyYXdpZWdodDoNCi0gICAgICAgICAgICAgIGZ1bGwgKGllIDEwMCUpIHV0
aWxpemF0aW9uIGlzIGVxdWl2YWxlbnQgdG8gMTI4IGV4dHJhd2VpZ2h0Ki8NCisgICAgICAgIHsN
CisgICAgICAgICAgICAvKiBDb252ZXJzaW9uIGJldHdlZW4gcmVhbHRpbWUgdXRpbGlzYXRpb24g
YW5kIGV4dHJhd2llZ2h0Og0KKyAgICAgICAgICAgICAqIGZ1bGwgKGllIDEwMCUpIHV0aWxpemF0
aW9uIGlzIGVxdWl2YWxlbnQgdG8gMTI4IGV4dHJhd2VpZ2h0DQorICAgICAgICAgICAgICovDQog
ICAgICAgICAgICAgaW5mLT5zY29yZVtFWFRSQV9VVElMX1FdID0gKDE8PDE3KSAvIGluZi0+ZXh0
cmF3ZWlnaHQ7DQorICAgICAgICB9DQogICAgIH0NCiANCiAgY2hlY2tfZXh0cmFfcXVldWVzOg0K
LSAgICAvKiBBZGRpbmcgYSBydW5uYWJsZSBkb21haW4gdG8gdGhlIHJpZ2h0IHF1ZXVlIGFuZCBy
ZW1vdmluZyBibG9ja2VkIG9uZXMqLw0KKyAgICAvKiBBZGRpbmcgYSBydW5uYWJsZSBkb21haW4g
dG8gdGhlIHJpZ2h0IHF1ZXVlIGFuZCByZW1vdmluZyBibG9ja2VkIG9uZXMgKi8NCiAgICAgaWYg
KCBzZWRmX3J1bm5hYmxlKGQpICkNCiAgICAgew0KLSAgICAgICAgLyphZGQgYWNjb3JkaW5nIHRv
IHNjb3JlOiB3ZWlnaHRlZCByb3VuZCByb2JpbiovDQorICAgICAgICAvKiBBZGQgYWNjb3JkaW5n
IHRvIHNjb3JlOiB3ZWlnaHRlZCByb3VuZCByb2JpbiAqLw0KICAgICAgICAgaWYgKCgoaW5mLT5z
dGF0dXMgJiBFWFRSQV9BV0FSRSkgJiYgKGkgPT0gRVhUUkFfVVRJTF9RKSkgfHwNCiAgICAgICAg
ICAgICAoKGluZi0+c3RhdHVzICYgRVhUUkFfV0FOVF9QRU5fUSkgJiYgKGkgPT0gRVhUUkFfUEVO
X1EpKSkNCiAgICAgICAgICAgICBleHRyYXFfYWRkX3NvcnRfdXBkYXRlKGQsIGksIG9sZHNjb3Jl
KTsNCiAgICAgfQ0KICAgICBlbHNlDQogICAgIHsNCi0gICAgICAgIC8qcmVtb3ZlIHRoaXMgYmxv
Y2tlZCBkb21haW4gZnJvbSB0aGUgd2FpdHEhKi8NCisgICAgICAgIC8qIFJlbW92ZSB0aGlzIGJs
b2NrZWQgZG9tYWluIGZyb20gdGhlIHdhaXRxISAqLw0KICAgICAgICAgX19kZWxfZnJvbV9xdWV1
ZShkKTsNCi0gICAgICAgIC8qbWFrZSBzdXJlIHRoYXQgd2UgcmVtb3ZlIGEgYmxvY2tlZCBkb21h
aW4gZnJvbSB0aGUgb3RoZXINCi0gICAgICAgICAgZXh0cmFxIHRvbyovDQorICAgICAgICAvKiBN
YWtlIHN1cmUgdGhhdCB3ZSByZW1vdmUgYSBibG9ja2VkIGRvbWFpbiBmcm9tIHRoZSBvdGhlcg0K
KyAgICAgICAgICogZXh0cmFxIHRvby4gKi8NCiAgICAgICAgIGlmICggaSA9PSBFWFRSQV9QRU5f
USApDQogICAgICAgICB7DQogICAgICAgICAgICAgaWYgKCBleHRyYXFfb24oZCwgRVhUUkFfVVRJ
TF9RKSApDQpAQCAtNzMyLDggKzY3Miw5IEBAIHN0YXRpYyBzdHJ1Y3QgdGFza19zbGljZSBzZWRm
X2RvX2V4dHJhX3MNCiANCiAgICAgaWYgKCAhbGlzdF9lbXB0eShleHRyYXFbRVhUUkFfUEVOX1Fd
KSApDQogICAgIHsNCi0gICAgICAgIC8qd2Ugc3RpbGwgaGF2ZSBlbGVtZW50cyBvbiB0aGUgbGV2
ZWwgMCBleHRyYXEgDQotICAgICAgICAgID0+IGxldCB0aG9zZSBydW4gZmlyc3QhKi8NCisgICAg
ICAgIC8qIFdlIHN0aWxsIGhhdmUgZWxlbWVudHMgb24gdGhlIGxldmVsIDAgZXh0cmFxDQorICAg
ICAgICAgKiA9PiBsZXQgdGhvc2UgcnVuIGZpcnN0IQ0KKyAgICAgICAgICovDQogICAgICAgICBy
dW5pbmYgICA9IGxpc3RfZW50cnkoZXh0cmFxW0VYVFJBX1BFTl9RXS0+bmV4dCwgDQogICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgc3RydWN0IHNlZGZfdmNwdV9pbmZvLCBleHRyYWxpc3Rb
RVhUUkFfUEVOX1FdKTsNCiAgICAgICAgIHJ1bmluZi0+c3RhdHVzIHw9IEVYVFJBX1JVTl9QRU47
DQpAQCAtNzQ3LDcgKzY4OCw3IEBAIHN0YXRpYyBzdHJ1Y3QgdGFza19zbGljZSBzZWRmX2RvX2V4
dHJhX3MNCiAgICAgew0KICAgICAgICAgaWYgKCAhbGlzdF9lbXB0eShleHRyYXFbRVhUUkFfVVRJ
TF9RXSkgKQ0KICAgICAgICAgew0KLSAgICAgICAgICAgIC8qdXNlIGVsZW1lbnRzIGZyb20gdGhl
IG5vcm1hbCBleHRyYXF1ZXVlKi8NCisgICAgICAgICAgICAvKiBVc2UgZWxlbWVudHMgZnJvbSB0
aGUgbm9ybWFsIGV4dHJhcXVldWUgKi8NCiAgICAgICAgICAgICBydW5pbmYgICA9IGxpc3RfZW50
cnkoZXh0cmFxW0VYVFJBX1VUSUxfUV0tPm5leHQsDQogICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgIHN0cnVjdCBzZWRmX3ZjcHVfaW5mbywNCiAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgZXh0cmFsaXN0W0VYVFJBX1VUSUxfUV0pOw0KQEAgLTc3MywxMCArNzE0LDEx
IEBAIHN0YXRpYyBzdHJ1Y3QgdGFza19zbGljZSBzZWRmX2RvX2V4dHJhX3MNCiANCiANCiAvKiBN
YWluIHNjaGVkdWxpbmcgZnVuY3Rpb24NCi0gICBSZWFzb25zIGZvciBjYWxsaW5nIHRoaXMgZnVu
Y3Rpb24gYXJlOg0KLSAgIC10aW1lc2xpY2UgZm9yIHRoZSBjdXJyZW50IHBlcmlvZCB1c2VkIHVw
DQotICAgLWRvbWFpbiBvbiB3YWl0cXVldWUgaGFzIHN0YXJ0ZWQgaXQncyBwZXJpb2QNCi0gICAt
YW5kIHZhcmlvdXMgb3RoZXJzIDspIGluIGdlbmVyYWw6IGRldGVybWluZSB3aGljaCBkb21haW4g
dG8gcnVuIG5leHQqLw0KKyAqIFJlYXNvbnMgZm9yIGNhbGxpbmcgdGhpcyBmdW5jdGlvbiBhcmU6
DQorICogLXRpbWVzbGljZSBmb3IgdGhlIGN1cnJlbnQgcGVyaW9kIHVzZWQgdXANCisgKiAtZG9t
YWluIG9uIHdhaXRxdWV1ZSBoYXMgc3RhcnRlZCBpdCdzIHBlcmlvZA0KKyAqIC1hbmQgdmFyaW91
cyBvdGhlcnMgOykgaW4gZ2VuZXJhbDogZGV0ZXJtaW5lIHdoaWNoIGRvbWFpbiB0byBydW4gbmV4
dA0KKyAqLw0KIHN0YXRpYyBzdHJ1Y3QgdGFza19zbGljZSBzZWRmX2RvX3NjaGVkdWxlKA0KICAg
ICBjb25zdCBzdHJ1Y3Qgc2NoZWR1bGVyICpvcHMsIHNfdGltZV90IG5vdywgYm9vbF90IHRhc2ts
ZXRfd29ya19zY2hlZHVsZWQpDQogew0KQEAgLTc4OSwxMyArNzMxLDE0IEBAIHN0YXRpYyBzdHJ1
Y3QgdGFza19zbGljZSBzZWRmX2RvX3NjaGVkdWwNCiAgICAgc3RydWN0IHNlZGZfdmNwdV9pbmZv
ICpydW5pbmYsICp3YWl0aW5mOw0KICAgICBzdHJ1Y3QgdGFza19zbGljZSAgICAgIHJldDsNCiAN
Ci0gICAgLyppZGxlIHRhc2tzIGRvbid0IG5lZWQgYW55IG9mIHRoZSBmb2xsb3dpbmcgc3R1Ziov
DQorICAgIC8qIElkbGUgdGFza3MgZG9uJ3QgbmVlZCBhbnkgb2YgdGhlIGZvbGxvd2luZyBzdHVm
ICovDQogICAgIGlmICggaXNfaWRsZV92Y3B1KGN1cnJlbnQpICkNCiAgICAgICAgIGdvdG8gY2hl
Y2tfd2FpdHE7DQogIA0KLSAgICAvKiBjcmVhdGUgbG9jYWwgc3RhdGUgb2YgdGhlIHN0YXR1cyBv
ZiB0aGUgZG9tYWluLCBpbiBvcmRlciB0byBhdm9pZA0KLSAgICAgICBpbmNvbnNpc3RlbnQgc3Rh
dGUgZHVyaW5nIHNjaGVkdWxpbmcgZGVjaXNpb25zLCBiZWNhdXNlIGRhdGEgZm9yDQotICAgICAg
IHZjcHVfcnVubmFibGUgaXMgbm90IHByb3RlY3RlZCBieSB0aGUgc2NoZWR1bGluZyBsb2NrISov
DQorICAgIC8qIENyZWF0ZSBsb2NhbCBzdGF0ZSBvZiB0aGUgc3RhdHVzIG9mIHRoZSBkb21haW4s
IGluIG9yZGVyIHRvIGF2b2lkDQorICAgICAqIGluY29uc2lzdGVudCBzdGF0ZSBkdXJpbmcgc2No
ZWR1bGluZyBkZWNpc2lvbnMsIGJlY2F1c2UgZGF0YSBmb3INCisgICAgICogdmNwdV9ydW5uYWJs
ZSBpcyBub3QgcHJvdGVjdGVkIGJ5IHRoZSBzY2hlZHVsaW5nIGxvY2shDQorICAgICAqLw0KICAg
ICBpZiAoICF2Y3B1X3J1bm5hYmxlKGN1cnJlbnQpICkNCiAgICAgICAgIGluZi0+c3RhdHVzIHw9
IFNFREZfQVNMRUVQOw0KICANCkBAIC04MDQsNyArNzQ3LDcgQEAgc3RhdGljIHN0cnVjdCB0YXNr
X3NsaWNlIHNlZGZfZG9fc2NoZWR1bA0KIA0KICAgICBpZiAoIHVubGlrZWx5KGV4dHJhX3J1bnMo
aW5mKSkgKQ0KICAgICB7DQotICAgICAgICAvKnNwZWNpYWwgdHJlYXRtZW50IG9mIGRvbWFpbnMg
cnVubmluZyBpbiBleHRyYSB0aW1lKi8NCisgICAgICAgIC8qIFNwZWNpYWwgdHJlYXRtZW50IG9m
IGRvbWFpbnMgcnVubmluZyBpbiBleHRyYSB0aW1lICovDQogICAgICAgICBkZXNjaGVkX2V4dHJh
X2RvbShub3csIGN1cnJlbnQpOw0KICAgICB9DQogICAgIGVsc2UgDQpAQCAtODE0LDEwICs3NTcs
MTEgQEAgc3RhdGljIHN0cnVjdCB0YXNrX3NsaWNlIHNlZGZfZG9fc2NoZWR1bA0KICBjaGVja193
YWl0cToNCiAgICAgdXBkYXRlX3F1ZXVlcyhub3csIHJ1bnEsIHdhaXRxKTsNCiANCi0gICAgLypu
b3cgc2ltcGx5IHBpY2sgdGhlIGZpcnN0IGRvbWFpbiBmcm9tIHRoZSBydW5xdWV1ZSwgd2hpY2gg
aGFzIHRoZQ0KLSAgICAgIGVhcmxpZXN0IGRlYWRsaW5lLCBiZWNhdXNlIHRoZSBsaXN0IGlzIHNv
cnRlZCovDQotIA0KLSAgICAvKiBUYXNrbGV0IHdvcmsgKHdoaWNoIHJ1bnMgaW4gaWRsZSBWQ1BV
IGNvbnRleHQpIG92ZXJyaWRlcyBhbGwgZWxzZS4gKi8NCisgICAgLyogTm93IHNpbXBseSBwaWNr
IHRoZSBmaXJzdCBkb21haW4gZnJvbSB0aGUgcnVucXVldWUsIHdoaWNoIGhhcyB0aGUNCisgICAg
ICogZWFybGllc3QgZGVhZGxpbmUsIGJlY2F1c2UgdGhlIGxpc3QgaXMgc29ydGVkDQorICAgICAq
DQorICAgICAqIFRhc2tsZXQgd29yayAod2hpY2ggcnVucyBpbiBpZGxlIFZDUFUgY29udGV4dCkg
b3ZlcnJpZGVzIGFsbCBlbHNlLg0KKyAgICAgKi8NCiAgICAgaWYgKCB0YXNrbGV0X3dvcmtfc2No
ZWR1bGVkIHx8DQogICAgICAgICAgKGxpc3RfZW1wdHkocnVucSkgJiYgbGlzdF9lbXB0eSh3YWl0
cSkpIHx8DQogICAgICAgICAgdW5saWtlbHkoIWNwdW1hc2tfdGVzdF9jcHUoY3B1LCBTRURGX0NQ
VU9OTElORShwZXJfY3B1KGNwdXBvb2wsIGNwdSkpKSkgKQ0KQEAgLTgzMyw5ICs3NzcsMTAgQEAg
c3RhdGljIHN0cnVjdCB0YXNrX3NsaWNlIHNlZGZfZG9fc2NoZWR1bA0KICAgICAgICAgew0KICAg
ICAgICAgICAgIHdhaXRpbmYgID0gbGlzdF9lbnRyeSh3YWl0cS0+bmV4dCwNCiAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgc3RydWN0IHNlZGZfdmNwdV9pbmZvLGxpc3QpOw0KLSAg
ICAgICAgICAgIC8qcmVydW4gc2NoZWR1bGVyLCB3aGVuIHNjaGVkdWxlZCBkb21haW4gcmVhY2hl
cyBpdCdzDQotICAgICAgICAgICAgICBlbmQgb2Ygc2xpY2Ugb3IgdGhlIGZpcnN0IGRvbWFpbiBm
cm9tIHRoZSB3YWl0cXVldWUNCi0gICAgICAgICAgICAgIGdldHMgcmVhZHkqLw0KKyAgICAgICAg
ICAgIC8qIFJlcnVuIHNjaGVkdWxlciwgd2hlbiBzY2hlZHVsZWQgZG9tYWluIHJlYWNoZXMgaXQn
cw0KKyAgICAgICAgICAgICAqIGVuZCBvZiBzbGljZSBvciB0aGUgZmlyc3QgZG9tYWluIGZyb20g
dGhlIHdhaXRxdWV1ZQ0KKyAgICAgICAgICAgICAqIGdldHMgcmVhZHkuDQorICAgICAgICAgICAg
ICovDQogICAgICAgICAgICAgcmV0LnRpbWUgPSBNSU4obm93ICsgcnVuaW5mLT5zbGljZSAtIHJ1
bmluZi0+Y3B1dGltZSwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICBQRVJJT0RfQkVHSU4o
d2FpdGluZikpIC0gbm93Ow0KICAgICAgICAgfQ0KQEAgLTg0NywxNCArNzkyLDE1IEBAIHN0YXRp
YyBzdHJ1Y3QgdGFza19zbGljZSBzZWRmX2RvX3NjaGVkdWwNCiAgICAgZWxzZQ0KICAgICB7DQog
ICAgICAgICB3YWl0aW5mICA9IGxpc3RfZW50cnkod2FpdHEtPm5leHQsc3RydWN0IHNlZGZfdmNw
dV9pbmZvLCBsaXN0KTsNCi0gICAgICAgIC8qd2UgY291bGQgbm90IGZpbmQgYW55IHN1aXRhYmxl
IGRvbWFpbiANCi0gICAgICAgICAgPT4gbG9vayBmb3IgZG9tYWlucyB0aGF0IGFyZSBhd2FyZSBv
ZiBleHRyYXRpbWUqLw0KKyAgICAgICAgLyogV2UgY291bGQgbm90IGZpbmQgYW55IHN1aXRhYmxl
IGRvbWFpbiANCisgICAgICAgICAqID0+IGxvb2sgZm9yIGRvbWFpbnMgdGhhdCBhcmUgYXdhcmUg
b2YgZXh0cmF0aW1lKi8NCiAgICAgICAgIHJldCA9IHNlZGZfZG9fZXh0cmFfc2NoZWR1bGUobm93
LCBQRVJJT0RfQkVHSU4od2FpdGluZiksDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIGV4dHJhcSwgY3B1KTsNCiAgICAgfQ0KIA0KLSAgICAvKlRPRE86IERvIHNvbWV0aGlu
ZyBVU0VGVUwgd2hlbiB0aGlzIGhhcHBlbnMgYW5kIGZpbmQgb3V0LCB3aHkgaXQNCi0gICAgICBz
dGlsbCBjYW4gaGFwcGVuISEhKi8NCisgICAgLyogVE9ETzogRG8gc29tZXRoaW5nIFVTRUZVTCB3
aGVuIHRoaXMgaGFwcGVucyBhbmQgZmluZCBvdXQsIHdoeSBpdA0KKyAgICAgKiBzdGlsbCBjYW4g
aGFwcGVuISEhDQorICAgICAqLw0KICAgICBpZiAoIHJldC50aW1lIDwgMCkNCiAgICAgew0KICAg
ICAgICAgcHJpbnRrKCJPdWNoISBXZSBhcmUgc2VyaW91c2x5IEJFSElORCBzY2hlZHVsZSEgJSJQ
UklpNjQiXG4iLA0KQEAgLTg3NCw5ICs4MjAsNiBAQCBzdGF0aWMgc3RydWN0IHRhc2tfc2xpY2Ug
c2VkZl9kb19zY2hlZHVsDQogDQogc3RhdGljIHZvaWQgc2VkZl9zbGVlcChjb25zdCBzdHJ1Y3Qg
c2NoZWR1bGVyICpvcHMsIHN0cnVjdCB2Y3B1ICpkKQ0KIHsNCi0gICAgUFJJTlQoMiwic2VkZl9z
bGVlcCB3YXMgY2FsbGVkLCBkb21haW4taWQgJWkuJWlcbiIsDQotICAgICAgICAgIGQtPmRvbWFp
bi0+ZG9tYWluX2lkLCBkLT52Y3B1X2lkKTsNCi0gDQogICAgIGlmICggaXNfaWRsZV92Y3B1KGQp
ICkNCiAgICAgICAgIHJldHVybjsNCiANCkBAIC05NzIsMjcgKzkxNSwyOSBAQCBzdGF0aWMgdm9p
ZCBzZWRmX3NsZWVwKGNvbnN0IHN0cnVjdCBzY2hlDQogc3RhdGljIHZvaWQgdW5ibG9ja19zaG9y
dF9leHRyYV9zdXBwb3J0KA0KICAgICBzdHJ1Y3Qgc2VkZl92Y3B1X2luZm8qIGluZiwgc190aW1l
X3Qgbm93KQ0KIHsNCi0gICAgLyp0aGlzIHVuYmxvY2tpbmcgc2NoZW1lIHRyaWVzIHRvIHN1cHBv
cnQgdGhlIGRvbWFpbiwgYnkgYXNzaWduaW5nIGl0DQotICAgIGEgcHJpb3JpdHkgaW4gZXh0cmF0
aW1lIGRpc3RyaWJ1dGlvbiBhY2NvcmRpbmcgdG8gdGhlIGxvc3Mgb2YgdGltZQ0KLSAgICBpbiB0
aGlzIHNsaWNlIGR1ZSB0byBibG9ja2luZyovDQorICAgIC8qIFRoaXMgdW5ibG9ja2luZyBzY2hl
bWUgdHJpZXMgdG8gc3VwcG9ydCB0aGUgZG9tYWluLCBieSBhc3NpZ25pbmcgaXQNCisgICAgICog
YSBwcmlvcml0eSBpbiBleHRyYXRpbWUgZGlzdHJpYnV0aW9uIGFjY29yZGluZyB0byB0aGUgbG9z
cyBvZiB0aW1lDQorICAgICAqIGluIHRoaXMgc2xpY2UgZHVlIHRvIGJsb2NraW5nDQorICAgICAq
Lw0KICAgICBzX3RpbWVfdCBwZW47DQogIA0KLSAgICAvKm5vIG1vcmUgcmVhbHRpbWUgZXhlY3V0
aW9uIGluIHRoaXMgcGVyaW9kISovDQorICAgIC8qIE5vIG1vcmUgcmVhbHRpbWUgZXhlY3V0aW9u
IGluIHRoaXMgcGVyaW9kISAqLw0KICAgICBpbmYtPmRlYWRsX2FicyArPSBpbmYtPnBlcmlvZDsN
CiAgICAgaWYgKCBsaWtlbHkoaW5mLT5ibG9ja19hYnMpICkNCiAgICAgew0KLSAgICAgICAgLy90
cmVhdCBibG9ja2VkIHRpbWUgYXMgY29uc3VtZWQgYnkgdGhlIGRvbWFpbiovDQorICAgICAgICAv
KiBUcmVhdCBibG9ja2VkIHRpbWUgYXMgY29uc3VtZWQgYnkgdGhlIGRvbWFpbiAqLw0KICAgICAg
ICAgLyppbmYtPmNwdXRpbWUgKz0gbm93IC0gaW5mLT5ibG9ja19hYnM7Ki8NCi0gICAgICAgIC8q
cGVuYWx0eSBpcyB0aW1lIHRoZSBkb21haW4gd291bGQgaGF2ZQ0KLSAgICAgICAgICBoYWQgaWYg
aXQgY29udGludWVkIHRvIHJ1biAqLw0KKyAgICAgICAgLyogUGVuYWx0eSBpcyB0aW1lIHRoZSBk
b21haW4gd291bGQgaGF2ZQ0KKyAgICAgICAgICogaGFkIGlmIGl0IGNvbnRpbnVlZCB0byBydW4u
DQorICAgICAgICAgKi8NCiAgICAgICAgIHBlbiA9IChpbmYtPnNsaWNlIC0gaW5mLT5jcHV0aW1l
KTsNCiAgICAgICAgIGlmICggcGVuIDwgMCApDQogICAgICAgICAgICAgcGVuID0gMDsNCi0gICAg
ICAgIC8qYWNjdW11bGF0ZSBhbGwgcGVuYWx0aWVzIG92ZXIgdGhlIHBlcmlvZHMqLw0KKyAgICAg
ICAgLyogQWNjdW11bGF0ZSBhbGwgcGVuYWx0aWVzIG92ZXIgdGhlIHBlcmlvZHMgKi8NCiAgICAg
ICAgIC8qaW5mLT5zaG9ydF9ibG9ja19sb3N0X3RvdCArPSBwZW47Ki8NCi0gICAgICAgIC8qc2V0
IHBlbmFsdHkgdG8gdGhlIGN1cnJlbnQgdmFsdWUqLw0KKyAgICAgICAgLyogU2V0IHBlbmFsdHkg
dG8gdGhlIGN1cnJlbnQgdmFsdWUgKi8NCiAgICAgICAgIGluZi0+c2hvcnRfYmxvY2tfbG9zdF90
b3QgPSBwZW47DQotICAgICAgICAvKm5vdCBzdXJlIHdoaWNoIG9uZSBpcyBiZXR0ZXIuLiBidXQg
c2VlbXMgdG8gd29yayB3ZWxsLi4uKi8NCisgICAgICAgIC8qIE5vdCBzdXJlIHdoaWNoIG9uZSBp
cyBiZXR0ZXIuLiBidXQgc2VlbXMgdG8gd29yayB3ZWxsLi4uICovDQogICANCiAgICAgICAgIGlm
ICggaW5mLT5zaG9ydF9ibG9ja19sb3N0X3RvdCApDQogICAgICAgICB7DQpAQCAtMTAwMiwyOCAr
OTQ3LDMwIEBAIHN0YXRpYyB2b2lkIHVuYmxvY2tfc2hvcnRfZXh0cmFfc3VwcG9ydCgNCiAgICAg
ICAgICAgICBpbmYtPnBlbl9leHRyYV9ibG9ja3MrKzsNCiAjZW5kaWYNCiAgICAgICAgICAgICBp
ZiAoIGV4dHJhcV9vbihpbmYtPnZjcHUsIEVYVFJBX1BFTl9RKSApDQotICAgICAgICAgICAgICAg
IC8qcmVtb3ZlIGRvbWFpbiBmb3IgcG9zc2libGUgcmVzb3J0aW5nISovDQorICAgICAgICAgICAg
ICAgIC8qIFJlbW92ZSBkb21haW4gZm9yIHBvc3NpYmxlIHJlc29ydGluZyEgKi8NCiAgICAgICAg
ICAgICAgICAgZXh0cmFxX2RlbChpbmYtPnZjcHUsIEVYVFJBX1BFTl9RKTsNCiAgICAgICAgICAg
ICBlbHNlDQotICAgICAgICAgICAgICAgIC8qcmVtZW1iZXIgdGhhdCB3ZSB3YW50IHRvIGJlIG9u
IHRoZSBwZW5hbHR5IHENCi0gICAgICAgICAgICAgICAgICBzbyB0aGF0IHdlIGNhbiBjb250aW51
ZSB3aGVuIHdlICh1bi0pYmxvY2sNCi0gICAgICAgICAgICAgICAgICBpbiBwZW5hbHR5LWV4dHJh
dGltZSovDQorICAgICAgICAgICAgICAgIC8qIFJlbWVtYmVyIHRoYXQgd2Ugd2FudCB0byBiZSBv
biB0aGUgcGVuYWx0eSBxDQorICAgICAgICAgICAgICAgICAqIHNvIHRoYXQgd2UgY2FuIGNvbnRp
bnVlIHdoZW4gd2UgKHVuLSlibG9jaw0KKyAgICAgICAgICAgICAgICAgKiBpbiBwZW5hbHR5LWV4
dHJhdGltZQ0KKyAgICAgICAgICAgICAgICAgKi8NCiAgICAgICAgICAgICAgICAgaW5mLT5zdGF0
dXMgfD0gRVhUUkFfV0FOVF9QRU5fUTsNCiAgICANCi0gICAgICAgICAgICAvKihyZS0pYWRkIGRv
bWFpbiB0byB0aGUgcGVuYWx0eSBleHRyYXEqLw0KKyAgICAgICAgICAgIC8qIChyZS0pYWRkIGRv
bWFpbiB0byB0aGUgcGVuYWx0eSBleHRyYXEgKi8NCiAgICAgICAgICAgICBleHRyYXFfYWRkX3Nv
cnRfdXBkYXRlKGluZi0+dmNwdSwgRVhUUkFfUEVOX1EsIDApOw0KICAgICAgICAgfQ0KICAgICB9
DQogDQotICAgIC8qZ2l2ZSBpdCBhIGZyZXNoIHNsaWNlIGluIHRoZSBuZXh0IHBlcmlvZCEqLw0K
KyAgICAvKiBHaXZlIGl0IGEgZnJlc2ggc2xpY2UgaW4gdGhlIG5leHQgcGVyaW9kISAqLw0KICAg
ICBpbmYtPmNwdXRpbWUgPSAwOw0KIH0NCiANCiANCiBzdGF0aWMgdm9pZCB1bmJsb2NrX2xvbmdf
Y29uc19iKHN0cnVjdCBzZWRmX3ZjcHVfaW5mbyogaW5mLHNfdGltZV90IG5vdykNCiB7DQotICAg
IC8qQ29uc2VydmF0aXZlIDJiKi8NCi0gICAgLypUcmVhdCB0aGUgdW5ibG9ja2luZyB0aW1lIGFz
IGEgc3RhcnQgb2YgYSBuZXcgcGVyaW9kICovDQorICAgIC8qIENvbnNlcnZhdGl2ZSAyYiAqLw0K
Kw0KKyAgICAvKiBUcmVhdCB0aGUgdW5ibG9ja2luZyB0aW1lIGFzIGEgc3RhcnQgb2YgYSBuZXcg
cGVyaW9kICovDQogICAgIGluZi0+ZGVhZGxfYWJzID0gbm93ICsgaW5mLT5wZXJpb2Q7DQogICAg
IGluZi0+Y3B1dGltZSA9IDA7DQogfQ0KQEAgLTEwNDYsMTUgKzk5MywxNiBAQCBzdGF0aWMgaW5s
aW5lIGludCBnZXRfcnVuX3R5cGUoc3RydWN0IHZjDQogfQ0KIA0KIA0KLS8qQ29tcGFyZXMgdHdv
IGRvbWFpbnMgaW4gdGhlIHJlbGF0aW9uIG9mIHdoZXRoZXIgdGhlIG9uZSBpcyBhbGxvd2VkIHRv
DQotICBpbnRlcnJ1cHQgdGhlIG90aGVycyBleGVjdXRpb24uDQotICBJdCByZXR1cm5zIHRydWUg
KCE9MCkgaWYgYSBzd2l0Y2ggdG8gdGhlIG90aGVyIGRvbWFpbiBpcyBnb29kLg0KLSAgQ3VycmVu
dCBQcmlvcml0eSBzY2hlbWUgaXMgYXMgZm9sbG93czoNCi0gICBFREYgPiBMMCAocGVuYWx0eSBi
YXNlZCkgZXh0cmEtdGltZSA+IA0KLSAgIEwxICh1dGlsaXphdGlvbikgZXh0cmEtdGltZSA+IGlk
bGUtZG9tYWluDQotICBJbiB0aGUgc2FtZSBjbGFzcyBwcmlvcml0aWVzIGFyZSBhc3NpZ25lZCBh
cyBmb2xsb3dpbmc6DQotICAgRURGOiBlYXJseSBkZWFkbGluZSA+IGxhdGUgZGVhZGxpbmUNCi0g
ICBMMCBleHRyYS10aW1lOiBsb3dlciBzY29yZSA+IGhpZ2hlciBzY29yZSovDQorLyogQ29tcGFy
ZXMgdHdvIGRvbWFpbnMgaW4gdGhlIHJlbGF0aW9uIG9mIHdoZXRoZXIgdGhlIG9uZSBpcyBhbGxv
d2VkIHRvDQorICogaW50ZXJydXB0IHRoZSBvdGhlcnMgZXhlY3V0aW9uLg0KKyAqIEl0IHJldHVy
bnMgdHJ1ZSAoIT0wKSBpZiBhIHN3aXRjaCB0byB0aGUgb3RoZXIgZG9tYWluIGlzIGdvb2QuDQor
ICogQ3VycmVudCBQcmlvcml0eSBzY2hlbWUgaXMgYXMgZm9sbG93czoNCisgKiAgRURGID4gTDAg
KHBlbmFsdHkgYmFzZWQpIGV4dHJhLXRpbWUgPiANCisgKiAgTDEgKHV0aWxpemF0aW9uKSBleHRy
YS10aW1lID4gaWRsZS1kb21haW4NCisgKiBJbiB0aGUgc2FtZSBjbGFzcyBwcmlvcml0aWVzIGFy
ZSBhc3NpZ25lZCBhcyBmb2xsb3dpbmc6DQorICogIEVERjogZWFybHkgZGVhZGxpbmUgPiBsYXRl
IGRlYWRsaW5lDQorICogIEwwIGV4dHJhLXRpbWU6IGxvd2VyIHNjb3JlID4gaGlnaGVyIHNjb3Jl
DQorICovDQogc3RhdGljIGlubGluZSBpbnQgc2hvdWxkX3N3aXRjaChzdHJ1Y3QgdmNwdSAqY3Vy
LA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgc3RydWN0IHZjcHUgKm90aGVyLA0K
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgc190aW1lX3Qgbm93KQ0KQEAgLTEwNjMs
MTkgKzEwMTEsMTkgQEAgc3RhdGljIGlubGluZSBpbnQgc2hvdWxkX3N3aXRjaChzdHJ1Y3Qgdg0K
ICAgICBjdXJfaW5mICAgPSBFRE9NX0lORk8oY3VyKTsNCiAgICAgb3RoZXJfaW5mID0gRURPTV9J
TkZPKG90aGVyKTsNCiAgDQotICAgIC8qIENoZWNrIHdoZXRoZXIgd2UgbmVlZCB0byBtYWtlIGFu
IGVhcmxpZXIgc2NoZWR1bGluZyBkZWNpc2lvbi4gKi8NCisgICAgLyogQ2hlY2sgd2hldGhlciB3
ZSBuZWVkIHRvIG1ha2UgYW4gZWFybGllciBzY2hlZHVsaW5nIGRlY2lzaW9uICovDQogICAgIGlm
ICggUEVSSU9EX0JFR0lOKG90aGVyX2luZikgPCANCiAgICAgICAgICBDUFVfSU5GTyhvdGhlci0+
cHJvY2Vzc29yKS0+Y3VycmVudF9zbGljZV9leHBpcmVzICkNCiAgICAgICAgIHJldHVybiAxOw0K
IA0KLSAgICAvKiBObyB0aW1pbmctYmFzZWQgc3dpdGNoZXMgbmVlZCB0byBiZSB0YWtlbiBpbnRv
IGFjY291bnQgaGVyZS4gKi8NCisgICAgLyogTm8gdGltaW5nLWJhc2VkIHN3aXRjaGVzIG5lZWQg
dG8gYmUgdGFrZW4gaW50byBhY2NvdW50IGhlcmUgKi8NCiAgICAgc3dpdGNoICggZ2V0X3J1bl90
eXBlKGN1cikgKQ0KICAgICB7DQogICAgIGNhc2UgRE9NQUlOX0VERjoNCi0gICAgICAgIC8qIERv
IG5vdCBpbnRlcnJ1cHQgYSBydW5uaW5nIEVERiBkb21haW4uICovDQorICAgICAgICAvKiBEbyBu
b3QgaW50ZXJydXB0IGEgcnVubmluZyBFREYgZG9tYWluICovDQogICAgICAgICByZXR1cm4gMDsN
CiAgICAgY2FzZSBET01BSU5fRVhUUkFfUEVOOg0KLSAgICAgICAgLyogQ2hlY2sgd2hldGhlciB3
ZSBhbHNvIHdhbnQgdGhlIEwwIGV4LXEgd2l0aCBsb3dlciBzY29yZS4gKi8NCisgICAgICAgIC8q
IENoZWNrIHdoZXRoZXIgd2UgYWxzbyB3YW50IHRoZSBMMCBleC1xIHdpdGggbG93ZXIgc2NvcmUg
Ki8NCiAgICAgICAgIHJldHVybiAoKG90aGVyX2luZi0+c3RhdHVzICYgRVhUUkFfV0FOVF9QRU5f
USkgJiYNCiAgICAgICAgICAgICAgICAgKG90aGVyX2luZi0+c2NvcmVbRVhUUkFfUEVOX1FdIDwg
DQogICAgICAgICAgICAgICAgICBjdXJfaW5mLT5zY29yZVtFWFRSQV9QRU5fUV0pKTsNCkBAIC0x
MDk2LDE4ICsxMDQ0LDExIEBAIHN0YXRpYyB2b2lkIHNlZGZfd2FrZShjb25zdCBzdHJ1Y3Qgc2No
ZWQNCiAgICAgc190aW1lX3QgICAgICAgICAgICAgIG5vdyA9IE5PVygpOw0KICAgICBzdHJ1Y3Qg
c2VkZl92Y3B1X2luZm8qIGluZiA9IEVET01fSU5GTyhkKTsNCiANCi0gICAgUFJJTlQoMywgInNl
ZGZfd2FrZSB3YXMgY2FsbGVkLCBkb21haW4taWQgJWkuJWlcbiIsZC0+ZG9tYWluLT5kb21haW5f
aWQsDQotICAgICAgICAgIGQtPnZjcHVfaWQpOw0KLQ0KICAgICBpZiAoIHVubGlrZWx5KGlzX2lk
bGVfdmNwdShkKSkgKQ0KICAgICAgICAgcmV0dXJuOw0KICAgIA0KICAgICBpZiAoIHVubGlrZWx5
KF9fdGFza19vbl9xdWV1ZShkKSkgKQ0KLSAgICB7DQotICAgICAgICBQUklOVCgzLCJcdGRvbWFp
biAlaS4laSBpcyBhbHJlYWR5IGluIHNvbWUgcXVldWVcbiIsDQotICAgICAgICAgICAgICBkLT5k
b21haW4tPmRvbWFpbl9pZCwgZC0+dmNwdV9pZCk7DQogICAgICAgICByZXR1cm47DQotICAgIH0N
CiANCiAgICAgQVNTRVJUKCFzZWRmX3J1bm5hYmxlKGQpKTsNCiAgICAgaW5mLT5zdGF0dXMgJj0g
flNFREZfQVNMRUVQOw0KQEAgLTExMTYsMjggKzEwNTcsMjQgQEAgc3RhdGljIHZvaWQgc2VkZl93
YWtlKGNvbnN0IHN0cnVjdCBzY2hlZA0KICANCiAgICAgaWYgKCB1bmxpa2VseShpbmYtPmRlYWRs
X2FicyA9PSAwKSApDQogICAgIHsNCi0gICAgICAgIC8qaW5pdGlhbCBzZXR1cCBvZiB0aGUgZGVh
ZGxpbmUqLw0KKyAgICAgICAgLyogSW5pdGlhbCBzZXR1cCBvZiB0aGUgZGVhZGxpbmUgKi8NCiAg
ICAgICAgIGluZi0+ZGVhZGxfYWJzID0gbm93ICsgaW5mLT5zbGljZTsNCiAgICAgfQ0KICAgDQot
ICAgIFBSSU5UKDMsICJ3YWtpbmcgdXAgZG9tYWluICVpLiVpIChkZWFkbD0gJSJQUkl1NjQiIHBl
cmlvZD0gJSJQUkl1NjQNCi0gICAgICAgICAgIm5vdz0gJSJQUkl1NjQiKVxuIiwNCi0gICAgICAg
ICAgZC0+ZG9tYWluLT5kb21haW5faWQsIGQtPnZjcHVfaWQsIGluZi0+ZGVhZGxfYWJzLCBpbmYt
PnBlcmlvZCwgbm93KTsNCi0NCiAjaWZkZWYgU0VERl9TVEFUUyANCiAgICAgaW5mLT5ibG9ja190
b3QrKzsNCiAjZW5kaWYNCiANCiAgICAgaWYgKCB1bmxpa2VseShub3cgPCBQRVJJT0RfQkVHSU4o
aW5mKSkgKQ0KICAgICB7DQotICAgICAgICBQUklOVCg0LCJleHRyYXRpbWUgdW5ibG9ja1xuIik7
DQotICAgICAgICAvKiB1bmJsb2NraW5nIGluIGV4dHJhLXRpbWUhICovDQorICAgICAgICAvKiBV
bmJsb2NraW5nIGluIGV4dHJhLXRpbWUhICovDQogICAgICAgICBpZiAoIGluZi0+c3RhdHVzICYg
RVhUUkFfV0FOVF9QRU5fUSApDQogICAgICAgICB7DQotICAgICAgICAgICAgLyp3ZSBoYXZlIGEg
ZG9tYWluIHRoYXQgd2FudHMgY29tcGVuc2F0aW9uDQotICAgICAgICAgICAgICBmb3IgYmxvY2sg
cGVuYWx0eSBhbmQgZGlkIGp1c3QgYmxvY2sgaW4NCi0gICAgICAgICAgICAgIGl0cyBjb21wZW5z
YXRpb24gdGltZS4gR2l2ZSBpdCBhbm90aGVyDQotICAgICAgICAgICAgICBjaGFuY2UhKi8NCisg
ICAgICAgICAgICAvKiBXZSBoYXZlIGEgZG9tYWluIHRoYXQgd2FudHMgY29tcGVuc2F0aW9uDQor
ICAgICAgICAgICAgICogZm9yIGJsb2NrIHBlbmFsdHkgYW5kIGRpZCBqdXN0IGJsb2NrIGluDQor
ICAgICAgICAgICAgICogaXRzIGNvbXBlbnNhdGlvbiB0aW1lLiBHaXZlIGl0IGFub3RoZXINCisg
ICAgICAgICAgICAgKiBjaGFuY2UhDQorICAgICAgICAgICAgICovDQogICAgICAgICAgICAgZXh0
cmFxX2FkZF9zb3J0X3VwZGF0ZShkLCBFWFRSQV9QRU5fUSwgMCk7DQogICAgICAgICB9DQogICAg
ICAgICBleHRyYXFfY2hlY2tfYWRkX3VuYmxvY2tlZChkLCAwKTsNCkBAIC0xMTQ2LDggKzEwODMs
NyBAQCBzdGF0aWMgdm9pZCBzZWRmX3dha2UoY29uc3Qgc3RydWN0IHNjaGVkDQogICAgIHsgIA0K
ICAgICAgICAgaWYgKCBub3cgPCBpbmYtPmRlYWRsX2FicyApDQogICAgICAgICB7DQotICAgICAg
ICAgICAgUFJJTlQoNCwic2hvcnQgdW5ibG9ja2luZ1xuIik7DQotICAgICAgICAgICAgLypzaG9y
dCBibG9ja2luZyovDQorICAgICAgICAgICAgLyogU2hvcnQgYmxvY2tpbmcgKi8NCiAjaWZkZWYg
U0VERl9TVEFUUw0KICAgICAgICAgICAgIGluZi0+c2hvcnRfYmxvY2tfdG90Kys7DQogI2VuZGlm
DQpAQCAtMTE1Nyw4ICsxMDkzLDcgQEAgc3RhdGljIHZvaWQgc2VkZl93YWtlKGNvbnN0IHN0cnVj
dCBzY2hlZA0KICAgICAgICAgfQ0KICAgICAgICAgZWxzZQ0KICAgICAgICAgew0KLSAgICAgICAg
ICAgIFBSSU5UKDQsImxvbmcgdW5ibG9ja2luZ1xuIik7DQotICAgICAgICAgICAgLypsb25nIHVu
YmxvY2tpbmcqLw0KKyAgICAgICAgICAgIC8qIExvbmcgdW5ibG9ja2luZyAqLw0KICNpZmRlZiBT
RURGX1NUQVRTDQogICAgICAgICAgICAgaW5mLT5sb25nX2Jsb2NrX3RvdCsrOw0KICNlbmRpZg0K
QEAgLTExNjgsMjQgKzExMDMsMTMgQEAgc3RhdGljIHZvaWQgc2VkZl93YWtlKGNvbnN0IHN0cnVj
dCBzY2hlZA0KICAgICAgICAgfQ0KICAgICB9DQogDQotICAgIFBSSU5UKDMsICJ3b2tlIHVwIGRv
bWFpbiAlaS4laSAoZGVhZGw9ICUiUFJJdTY0IiBwZXJpb2Q9ICUiUFJJdTY0DQotICAgICAgICAg
ICJub3c9ICUiUFJJdTY0IilcbiIsDQotICAgICAgICAgIGQtPmRvbWFpbi0+ZG9tYWluX2lkLCBk
LT52Y3B1X2lkLCBpbmYtPmRlYWRsX2FicywNCi0gICAgICAgICAgaW5mLT5wZXJpb2QsIG5vdyk7
DQotDQogICAgIGlmICggUEVSSU9EX0JFR0lOKGluZikgPiBub3cgKQ0KLSAgICB7DQogICAgICAg
ICBfX2FkZF90b193YWl0cXVldWVfc29ydChkKTsNCi0gICAgICAgIFBSSU5UKDMsImFkZGVkIHRv
IHdhaXRxXG4iKTsNCi0gICAgfQ0KICAgICBlbHNlDQotICAgIHsNCiAgICAgICAgIF9fYWRkX3Rv
X3J1bnF1ZXVlX3NvcnQoZCk7DQotICAgICAgICBQUklOVCgzLCJhZGRlZCB0byBydW5xXG4iKTsN
Ci0gICAgfQ0KICANCiAjaWZkZWYgU0VERl9TVEFUUw0KLSAgICAvKmRvIHNvbWUgc3RhdGlzdGlj
cyBoZXJlLi4uKi8NCisgICAgLyogRG8gc29tZSBzdGF0aXN0aWNzIGhlcmUuLi4gKi8NCiAgICAg
aWYgKCBpbmYtPmJsb2NrX2FicyAhPSAwICkNCiAgICAgew0KICAgICAgICAgaW5mLT5ibG9ja190
aW1lX3RvdCArPSBub3cgLSBpbmYtPmJsb2NrX2FiczsNCkBAIC0xMTk0LDEyICsxMTE4LDEzIEBA
IHN0YXRpYyB2b2lkIHNlZGZfd2FrZShjb25zdCBzdHJ1Y3Qgc2NoZWQNCiAgICAgfQ0KICNlbmRp
Zg0KIA0KLSAgICAvKnNhbml0eSBjaGVjazogbWFrZSBzdXJlIGVhY2ggZXh0cmEtYXdhcmUgZG9t
YWluIElTIG9uIHRoZSB1dGlsLXEhKi8NCisgICAgLyogU2FuaXR5IGNoZWNrOiBtYWtlIHN1cmUg
ZWFjaCBleHRyYS1hd2FyZSBkb21haW4gSVMgb24gdGhlIHV0aWwtcSEgKi8NCiAgICAgQVNTRVJU
KElNUExZKGluZi0+c3RhdHVzICYgRVhUUkFfQVdBUkUsIGV4dHJhcV9vbihkLCBFWFRSQV9VVElM
X1EpKSk7DQogICAgIEFTU0VSVChfX3Rhc2tfb25fcXVldWUoZCkpOw0KLSAgICAvKmNoZWNrIHdo
ZXRoZXIgdGhlIGF3YWtlbmVkIHRhc2sgbmVlZHMgdG8gaW52b2tlIHRoZSBkb19zY2hlZHVsZQ0K
LSAgICAgIHJvdXRpbmUuIFRyeSB0byBhdm9pZCB1bm5lY2Vzc2FyeSBydW5zIGJ1dDoNCi0gICAg
ICBTYXZlIGFwcHJveGltYXRpb246IEFsd2F5cyBzd2l0Y2ggdG8gc2NoZWR1bGVyISovDQorICAg
IC8qIENoZWNrIHdoZXRoZXIgdGhlIGF3YWtlbmVkIHRhc2sgbmVlZHMgdG8gaW52b2tlIHRoZSBk
b19zY2hlZHVsZQ0KKyAgICAgKiByb3V0aW5lLiBUcnkgdG8gYXZvaWQgdW5uZWNlc3NhcnkgcnVu
cyBidXQ6DQorICAgICAqIFNhdmUgYXBwcm94aW1hdGlvbjogQWx3YXlzIHN3aXRjaCB0byBzY2hl
ZHVsZXIhDQorICAgICAqLw0KICAgICBBU1NFUlQoZC0+cHJvY2Vzc29yID49IDApOw0KICAgICBB
U1NFUlQoZC0+cHJvY2Vzc29yIDwgbnJfY3B1X2lkcyk7DQogICAgIEFTU0VSVChwZXJfY3B1KHNj
aGVkdWxlX2RhdGEsIGQtPnByb2Nlc3NvcikuY3Vycik7DQpAQCAtMTI0NCw3ICsxMTY5LDcgQEAg
c3RhdGljIHZvaWQgc2VkZl9kdW1wX2RvbWFpbihzdHJ1Y3QgdmNwdQ0KIH0NCiANCiANCi0vKiBk
dW1wcyBhbGwgZG9tYWlucyBvbiB0aGUgc3BlY2lmaWVkIGNwdSAqLw0KKy8qIER1bXBzIGFsbCBk
b21haW5zIG9uIHRoZSBzcGVjaWZpZWQgY3B1ICovDQogc3RhdGljIHZvaWQgc2VkZl9kdW1wX2Nw
dV9zdGF0ZShjb25zdCBzdHJ1Y3Qgc2NoZWR1bGVyICpvcHMsIGludCBpKQ0KIHsNCiAgICAgc3Ry
dWN0IGxpc3RfaGVhZCAgICAgICpsaXN0LCAqcXVldWUsICp0bXA7DQpAQCAtMTMxOSw3ICsxMjQ0
LDcgQEAgc3RhdGljIHZvaWQgc2VkZl9kdW1wX2NwdV9zdGF0ZShjb25zdCBzdA0KIH0NCiANCiAN
Ci0vKiBBZGp1c3RzIHBlcmlvZHMgYW5kIHNsaWNlcyBvZiB0aGUgZG9tYWlucyBhY2NvcmRpbmds
eSB0byB0aGVpciB3ZWlnaHRzLiAqLw0KKy8qIEFkanVzdHMgcGVyaW9kcyBhbmQgc2xpY2VzIG9m
IHRoZSBkb21haW5zIGFjY29yZGluZ2x5IHRvIHRoZWlyIHdlaWdodHMgKi8NCiBzdGF0aWMgaW50
IHNlZGZfYWRqdXN0X3dlaWdodHMoc3RydWN0IGNwdXBvb2wgKmMsIHN0cnVjdCB4ZW5fZG9tY3Rs
X3NjaGVkdWxlcl9vcCAqY21kKQ0KIHsNCiAgICAgc3RydWN0IHZjcHUgKnA7DQpAQCAtMTMzNSw3
ICsxMjYwLDcgQEAgc3RhdGljIGludCBzZWRmX2FkanVzdF93ZWlnaHRzKHN0cnVjdCBjcA0KICAg
ICAgICAgcmV0dXJuIC1FTk9NRU07DQogICAgIH0NCiANCi0gICAgLyogU3VtIGFjcm9zcyBhbGwg
d2VpZ2h0cy4gKi8NCisgICAgLyogU3VtIGFjcm9zcyBhbGwgd2VpZ2h0cyAqLw0KICAgICByY3Vf
cmVhZF9sb2NrKCZkb21saXN0X3JlYWRfbG9jayk7DQogICAgIGZvcl9lYWNoX2RvbWFpbl9pbl9j
cHVwb29sKCBkLCBjICkNCiAgICAgew0KQEAgLTEzNTAsMTEgKzEyNzUsMTMgQEAgc3RhdGljIGlu
dCBzZWRmX2FkanVzdF93ZWlnaHRzKHN0cnVjdCBjcA0KICAgICAgICAgICAgIH0NCiAgICAgICAg
ICAgICBlbHNlDQogICAgICAgICAgICAgew0KLSAgICAgICAgICAgICAgICAvKmRvbid0IG1vZGlm
eSBkb21haW5zIHdobyBkb24ndCBoYXZlIGEgd2VpZ2h0LCBidXQgc3VtDQotICAgICAgICAgICAg
ICAgICAgdXAgdGhlIHRpbWUgdGhleSBuZWVkLCBwcm9qZWN0ZWQgdG8gYSBXRUlHSFRfUEVSSU9E
LA0KLSAgICAgICAgICAgICAgICAgIHNvIHRoYXQgdGhpcyB0aW1lIGlzIG5vdCBnaXZlbiB0byB0
aGUgd2VpZ2h0LWRyaXZlbg0KLSAgICAgICAgICAgICAgICAgIGRvbWFpbnMqLw0KLSAgICAgICAg
ICAgICAgICAvKmNoZWNrIGZvciBvdmVyZmxvd3MqLw0KKyAgICAgICAgICAgICAgICAvKiBEb24n
dCBtb2RpZnkgZG9tYWlucyB3aG8gZG9uJ3QgaGF2ZSBhIHdlaWdodCwgYnV0IHN1bQ0KKyAgICAg
ICAgICAgICAgICAgKiB1cCB0aGUgdGltZSB0aGV5IG5lZWQsIHByb2plY3RlZCB0byBhIFdFSUdI
VF9QRVJJT0QsDQorICAgICAgICAgICAgICAgICAqIHNvIHRoYXQgdGhpcyB0aW1lIGlzIG5vdCBn
aXZlbiB0byB0aGUgd2VpZ2h0LWRyaXZlbg0KKyAgICAgICAgICAgICAgICAgKiAgZG9tYWlucw0K
KyAgICAgICAgICAgICAgICAgKi8NCisNCisgICAgICAgICAgICAgICAgLyogQ2hlY2sgZm9yIG92
ZXJmbG93cyAqLw0KICAgICAgICAgICAgICAgICBBU1NFUlQoKFdFSUdIVF9QRVJJT0QgPCBVTE9O
R19NQVgpIA0KICAgICAgICAgICAgICAgICAgICAgICAgJiYgKEVET01fSU5GTyhwKS0+c2xpY2Vf
b3JpZyA8IFVMT05HX01BWCkpOw0KICAgICAgICAgICAgICAgICBzdW10W2NwdV0gKz0gDQpAQCAt
MTM2NSw3ICsxMjkyLDcgQEAgc3RhdGljIGludCBzZWRmX2FkanVzdF93ZWlnaHRzKHN0cnVjdCBj
cA0KICAgICB9DQogICAgIHJjdV9yZWFkX3VubG9jaygmZG9tbGlzdF9yZWFkX2xvY2spOw0KIA0K
LSAgICAvKiBBZGp1c3QgYWxsIHNsaWNlcyAoYW5kIHBlcmlvZHMpIHRvIHRoZSBuZXcgd2VpZ2h0
LiAqLw0KKyAgICAvKiBBZGp1c3QgYWxsIHNsaWNlcyAoYW5kIHBlcmlvZHMpIHRvIHRoZSBuZXcg
d2VpZ2h0ICovDQogICAgIHJjdV9yZWFkX2xvY2soJmRvbWxpc3RfcmVhZF9sb2NrKTsNCiAgICAg
Zm9yX2VhY2hfZG9tYWluX2luX2NwdXBvb2woIGQsIGMgKQ0KICAgICB7DQpAQCAtMTM5MywyMCAr
MTMyMCwxNSBAQCBzdGF0aWMgaW50IHNlZGZfYWRqdXN0X3dlaWdodHMoc3RydWN0IGNwDQogfQ0K
IA0KIA0KLS8qIHNldCBvciBmZXRjaCBkb21haW4gc2NoZWR1bGluZyBwYXJhbWV0ZXJzICovDQor
LyogU2V0IG9yIGZldGNoIGRvbWFpbiBzY2hlZHVsaW5nIHBhcmFtZXRlcnMgKi8NCiBzdGF0aWMg
aW50IHNlZGZfYWRqdXN0KGNvbnN0IHN0cnVjdCBzY2hlZHVsZXIgKm9wcywgc3RydWN0IGRvbWFp
biAqcCwgc3RydWN0IHhlbl9kb21jdGxfc2NoZWR1bGVyX29wICpvcCkNCiB7DQogICAgIHN0cnVj
dCB2Y3B1ICp2Ow0KICAgICBpbnQgcmM7DQogDQotICAgIFBSSU5UKDIsInNlZGZfYWRqdXN0IHdh
cyBjYWxsZWQsIGRvbWFpbi1pZCAlaSBuZXcgcGVyaW9kICUiUFJJdTY0IiAiDQotICAgICAgICAg
ICJuZXcgc2xpY2UgJSJQUkl1NjQiXG5sYXRlbmN5ICUiUFJJdTY0IiBleHRyYTolc1xuIiwNCi0g
ICAgICAgICAgcC0+ZG9tYWluX2lkLCBvcC0+dS5zZWRmLnBlcmlvZCwgb3AtPnUuc2VkZi5zbGlj
ZSwNCi0gICAgICAgICAgb3AtPnUuc2VkZi5sYXRlbmN5LCAob3AtPnUuc2VkZi5leHRyYXRpbWUp
PyJ5ZXMiOiJubyIpOw0KLQ0KICAgICBpZiAoIG9wLT5jbWQgPT0gWEVOX0RPTUNUTF9TQ0hFRE9Q
X3B1dGluZm8gKQ0KICAgICB7DQotICAgICAgICAvKiBDaGVjayBmb3Igc2FuZSBwYXJhbWV0ZXJz
LiAqLw0KKyAgICAgICAgLyogQ2hlY2sgZm9yIHNhbmUgcGFyYW1ldGVycyAqLw0KICAgICAgICAg
aWYgKCAhb3AtPnUuc2VkZi5wZXJpb2QgJiYgIW9wLT51LnNlZGYud2VpZ2h0ICkNCiAgICAgICAg
ICAgICByZXR1cm4gLUVJTlZBTDsNCiAgICAgICAgIGlmICggb3AtPnUuc2VkZi53ZWlnaHQgKQ0K
QEAgLTE0MTQsNyArMTMzNiw3IEBAIHN0YXRpYyBpbnQgc2VkZl9hZGp1c3QoY29uc3Qgc3RydWN0
IHNjaGUNCiAgICAgICAgICAgICBpZiAoIChvcC0+dS5zZWRmLmV4dHJhdGltZSAmIEVYVFJBX0FX
QVJFKSAmJg0KICAgICAgICAgICAgICAgICAgKCFvcC0+dS5zZWRmLnBlcmlvZCkgKQ0KICAgICAg
ICAgICAgIHsNCi0gICAgICAgICAgICAgICAgLyogV2VpZ2h0LWRyaXZlbiBkb21haW5zIHdpdGgg
ZXh0cmF0aW1lIG9ubHkuICovDQorICAgICAgICAgICAgICAgIC8qIFdlaWdodC1kcml2ZW4gZG9t
YWlucyB3aXRoIGV4dHJhdGltZSBvbmx5ICovDQogICAgICAgICAgICAgICAgIGZvcl9lYWNoX3Zj
cHUgKCBwLCB2ICkNCiAgICAgICAgICAgICAgICAgew0KICAgICAgICAgICAgICAgICAgICAgRURP
TV9JTkZPKHYpLT5leHRyYXdlaWdodCA9IG9wLT51LnNlZGYud2VpZ2h0Ow0KQEAgLTE0MjUsNyAr
MTM0Nyw3IEBAIHN0YXRpYyBpbnQgc2VkZl9hZGp1c3QoY29uc3Qgc3RydWN0IHNjaGUNCiAgICAg
ICAgICAgICB9DQogICAgICAgICAgICAgZWxzZQ0KICAgICAgICAgICAgIHsNCi0gICAgICAgICAg
ICAgICAgLyogV2VpZ2h0LWRyaXZlbiBkb21haW5zIHdpdGggcmVhbC10aW1lIGV4ZWN1dGlvbi4g
Ki8NCisgICAgICAgICAgICAgICAgLyogV2VpZ2h0LWRyaXZlbiBkb21haW5zIHdpdGggcmVhbC10
aW1lIGV4ZWN1dGlvbiAqLw0KICAgICAgICAgICAgICAgICBmb3JfZWFjaF92Y3B1ICggcCwgdiAp
DQogICAgICAgICAgICAgICAgICAgICBFRE9NX0lORk8odiktPndlaWdodCA9IG9wLT51LnNlZGYu
d2VpZ2h0Ow0KICAgICAgICAgICAgIH0NCkBAIC0xNDM1LDggKzEzNTcsNyBAQCBzdGF0aWMgaW50
IHNlZGZfYWRqdXN0KGNvbnN0IHN0cnVjdCBzY2hlDQogICAgICAgICAgICAgLyogVGltZS1kcml2
ZW4gZG9tYWlucy4gKi8NCiAgICAgICAgICAgICBmb3JfZWFjaF92Y3B1ICggcCwgdiApDQogICAg
ICAgICAgICAgew0KLSAgICAgICAgICAgICAgICAvKg0KLSAgICAgICAgICAgICAgICAgKiBTYW5p
dHkgY2hlY2tpbmc6IG5vdGUgdGhhdCBkaXNhYmxpbmcgZXh0cmEgd2VpZ2h0IHJlcXVpcmVzDQor
ICAgICAgICAgICAgICAgIC8qIFNhbml0eSBjaGVja2luZzogbm90ZSB0aGF0IGRpc2FibGluZyBl
eHRyYSB3ZWlnaHQgcmVxdWlyZXMNCiAgICAgICAgICAgICAgICAgICogdGhhdCB3ZSBzZXQgYSBu
b24temVybyBzbGljZS4NCiAgICAgICAgICAgICAgICAgICovDQogICAgICAgICAgICAgICAgIGlm
ICggKG9wLT51LnNlZGYucGVyaW9kID4gUEVSSU9EX01BWCkgfHwNCkBAIC0xNDc3LDcgKzEzOTgs
NiBAQCBzdGF0aWMgaW50IHNlZGZfYWRqdXN0KGNvbnN0IHN0cnVjdCBzY2hlDQogICAgICAgICBv
cC0+dS5zZWRmLndlaWdodCAgICA9IEVET01fSU5GTyhwLT52Y3B1WzBdKS0+d2VpZ2h0Ow0KICAg
ICB9DQogDQotICAgIFBSSU5UKDIsInNlZGZfYWRqdXN0X2ZpbmlzaGVkXG4iKTsNCiAgICAgcmV0
dXJuIDA7DQogfQ0KIA0K


--=-3p5/0djGq6n5G1gGRftX--

--=-4GhoPkvT2knwTpwLdibp
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEABECAAYFAk7wyjgACgkQk4XaBE3IOsR/vACgqGtZKPaaw+mk+E5KLy5ydkVO
0dgAn2xbXZ2l2w6UXsUeFgUEefZ0Zm8r
=lJaO
-----END PGP SIGNATURE-----

--=-4GhoPkvT2knwTpwLdibp--



--===============4953755209351780878==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============4953755209351780878==--



From xen-devel-bounces@lists.xensource.com Tue Dec 20 17:48:53 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 Dec 2011 17:48:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rd3nj-0004ru-NN; Tue, 20 Dec 2011 17:48:31 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1Rd3ni-0004rp-Al
	for xen-devel@lists.xensource.com; Tue, 20 Dec 2011 17:48:31 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-16.tower-182.messagelabs.com!1324403300!722602!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=1.1 required=7.0 tests=BODY_RANDOM_LONG,DIET_1
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27957 invoked from network); 20 Dec 2011 17:48:21 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-16.tower-182.messagelabs.com with SMTP;
	20 Dec 2011 17:48:21 -0000
Received: from [62.94.181.91] (account d.faggioli@sssup.it HELO [192.168.0.40])
	by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 74061268; Tue, 20 Dec 2011 18:48:18 +0100
Message-ID: <1324403256.2632.0.camel@Solace>
From: Dario Faggioli <raistlin@linux.it>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Tue, 20 Dec 2011 18:47:36 +0100
X-Mailer: Evolution 3.2.2-1 
Mime-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>, Keir Fraser <keir@xen.org>
Subject: [Xen-devel] sedf: remove useless tracing printk and harmonize
	comments style.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============4953755209351780878=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--===============4953755209351780878==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-4GhoPkvT2knwTpwLdibp"


--=-4GhoPkvT2knwTpwLdibp
Content-Type: multipart/mixed; boundary="=-3p5/0djGq6n5G1gGRftX"


--=-3p5/0djGq6n5G1gGRftX
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

sched_sedf.c used o have its own mechanism for producing tracing-alike
kind of information (domain block, wakeup, etc.). Nowadays, with an even
not so high number of pCPUs/vCPUs, just trying to enable this makes
the serial console completely unusable, produces tons of very hard to
parse and interpreet logging and can easily livelock Dom0. Moreover,
pretty much the same result this is struggling to get to, is better
achieved by enabling the scheduler-related tracing events, as
it is for the other schedulers (say, credit or credit2).

For all these reasons, this removes that machinery completely. While at
it, check in some cosmetics that harmonize the comments withim themself
and with the rest of the code base.

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>

diff -r 17d99691e0ec xen/common/sched_sedf.c
--- a/xen/common/sched_sedf.c	Tue Dec 20 16:39:56 2011 +0000
+++ b/xen/common/sched_sedf.c	Tue Dec 20 17:32:52 2011 +0000
@@ -13,14 +13,6 @@
 #include <xen/time.h>
 #include <xen/errno.h>
=20
-/*verbosity settings*/
-#define SEDFLEVEL 0
-#define PRINT(_f, _a...)                        \
-    do {                                        \
-        if ( (_f) <=3D SEDFLEVEL )                \
-            printk(_a );                        \
-    } while ( 0 )
-
 #define SEDF_CPUONLINE(_pool)                                             =
\
     (((_pool) =3D=3D NULL) ? &cpupool_free_cpus : (_pool)->cpu_valid)
=20
@@ -66,34 +58,35 @@ struct sedf_vcpu_info {
     struct list_head list;
     struct list_head extralist[2];
 =20
-    /*Parameters for EDF*/
-    s_time_t  period;  /*=3D(relative deadline)*/
-    s_time_t  slice;  /*=3Dworst case execution time*/
+    /* Parameters for EDF */
+    s_time_t  period;  /* =3D(relative deadline) */
+    s_time_t  slice;   /* =3Dworst case execution time */
 =20
-    /*Advaced Parameters*/
-    /*Latency Scaling*/
+    /* Advaced Parameters */
+
+    /* Latency Scaling */
     s_time_t  period_orig;
     s_time_t  slice_orig;
     s_time_t  latency;
 =20
-    /*status of domain*/
+    /* Status of domain */
     int       status;
-    /*weights for "Scheduling for beginners/ lazy/ etc." ;)*/
+    /* Weights for "Scheduling for beginners/ lazy/ etc." ;) */
     short     weight;
     short     extraweight;
-    /*Bookkeeping*/
+    /* Bookkeeping */
     s_time_t  deadl_abs;
     s_time_t  sched_start_abs;
     s_time_t  cputime;
-    /* times the domain un-/blocked */
+    /* Times the domain un-/blocked */
     s_time_t  block_abs;
     s_time_t  unblock_abs;
 =20
-    /*scores for {util, block penalty}-weighted extratime distribution*/
+    /* Scores for {util, block penalty}-weighted extratime distribution */
     int   score[2];
     s_time_t  short_block_lost_tot;
 =20
-    /*Statistics*/
+    /* Statistics */
     s_time_t  extra_time_tot;
=20
 #ifdef SEDF_STATS
@@ -158,18 +151,16 @@ static inline void extraq_del(struct vcp
 {
     struct list_head *list =3D EXTRALIST(d,i);
     ASSERT(extraq_on(d,i));
-    PRINT(3, "Removing domain %i.%i from L%i extraq\n",
-          d->domain->domain_id, d->vcpu_id, i);
     list_del(list);
     list->next =3D NULL;
     ASSERT(!extraq_on(d, i));
 }
=20
-/* adds a domain to the queue of processes which are aware of extra time. =
List
-   is sorted by score, where a lower score means higher priority for an ex=
tra
-   slice. It also updates the score, by simply subtracting a fixed value f=
rom
-   each entry, in order to avoid overflow. The algorithm works by simply
-   charging each domain that recieved extratime with an inverse of its wei=
ght.
+/* Adds a domain to the queue of processes which are aware of extra time. =
List
+ * is sorted by score, where a lower score means higher priority for an ex=
tra
+ * slice. It also updates the score, by simply subtracting a fixed value f=
rom
+ * each entry, in order to avoid overflow. The algorithm works by simply
+ * charging each domain that recieved extratime with an inverse of its wei=
ght.
  */=20
 static inline void extraq_add_sort_update(struct vcpu *d, int i, int sub)
 {
@@ -178,13 +169,7 @@ static inline void extraq_add_sort_updat
 =20
     ASSERT(!extraq_on(d,i));
=20
-    PRINT(3, "Adding domain %i.%i (score=3D %i, short_pen=3D %"PRIi64")"
-          " to L%i extraq\n",
-          d->domain->domain_id, d->vcpu_id, EDOM_INFO(d)->score[i],
-          EDOM_INFO(d)->short_block_lost_tot, i);
-
-    /*
-     * Iterate through all elements to find our "hole" and on our way
+    /* Iterate through all elements to find our "hole" and on our way
      * update all the other scores.
      */
     list_for_each ( cur, EXTRAQ(d->processor, i) )
@@ -193,25 +178,18 @@ static inline void extraq_add_sort_updat
         curinf->score[i] -=3D sub;
         if ( EDOM_INFO(d)->score[i] < curinf->score[i] )
             break;
-        PRINT(4,"\tbehind domain %i.%i (score=3D %i)\n",
-              curinf->vcpu->domain->domain_id,
-              curinf->vcpu->vcpu_id, curinf->score[i]);
     }
=20
-    /* cur now contains the element, before which we'll enqueue. */
-    PRINT(3, "\tlist_add to %p\n", cur->prev);
+    /* cur now contains the element, before which we'll enqueue */
     list_add(EXTRALIST(d,i),cur->prev);
 =20
-    /* Continue updating the extraq. */
+    /* Continue updating the extraq */
     if ( (cur !=3D EXTRAQ(d->processor,i)) && sub )
     {
         for ( cur =3D cur->next; cur !=3D EXTRAQ(d->processor,i); cur =3D =
cur->next )
         {
             curinf =3D list_entry(cur,struct sedf_vcpu_info, extralist[i])=
;
             curinf->score[i] -=3D sub;
-            PRINT(4, "\tupdating domain %i.%i (score=3D %u)\n",
-                  curinf->vcpu->domain->domain_id,=20
-                  curinf->vcpu->vcpu_id, curinf->score[i]);
         }
     }
=20
@@ -221,29 +199,14 @@ static inline void extraq_check(struct v
 {
     if ( extraq_on(d, EXTRA_UTIL_Q) )
     {
-        PRINT(2,"Dom %i.%i is on L1 extraQ\n",
-              d->domain->domain_id, d->vcpu_id);
-
         if ( !(EDOM_INFO(d)->status & EXTRA_AWARE) &&
              !extra_runs(EDOM_INFO(d)) )
-        {
             extraq_del(d, EXTRA_UTIL_Q);
-            PRINT(2,"Removed dom %i.%i from L1 extraQ\n",
-                  d->domain->domain_id, d->vcpu_id);
-        }
     }
     else
     {
-        PRINT(2, "Dom %i.%i is NOT on L1 extraQ\n",
-              d->domain->domain_id,
-              d->vcpu_id);
-
         if ( (EDOM_INFO(d)->status & EXTRA_AWARE) && sedf_runnable(d) )
-        {
             extraq_add_sort_update(d, EXTRA_UTIL_Q, 0);
-            PRINT(2,"Added dom %i.%i to L1 extraQ\n",
-                  d->domain->domain_id, d->vcpu_id);
-        }
     }
 }
=20
@@ -252,7 +215,7 @@ static inline void extraq_check_add_unbl
     struct sedf_vcpu_info *inf =3D EDOM_INFO(d);
=20
     if ( inf->status & EXTRA_AWARE )
-        /* Put on the weighted extraq without updating any scores. */
+        /* Put on the weighted extraq without updating any scores */
         extraq_add_sort_update(d, EXTRA_UTIL_Q, 0);
 }
=20
@@ -265,8 +228,6 @@ static inline void __del_from_queue(stru
 {
     struct list_head *list =3D LIST(d);
     ASSERT(__task_on_queue(d));
-    PRINT(3,"Removing domain %i.%i (bop=3D %"PRIu64") from runq/waitq\n",
-          d->domain->domain_id, d->vcpu_id, PERIOD_BEGIN(EDOM_INFO(d)));
     list_del(list);
     list->next =3D NULL;
     ASSERT(!__task_on_queue(d));
@@ -279,13 +240,12 @@ static inline void list_insert_sort(
 {
     struct list_head     *cur;
=20
-    /* Iterate through all elements to find our "hole". */
+    /* Iterate through all elements to find our "hole" */
     list_for_each( cur, list )
         if ( comp(element, cur) < 0 )
             break;
=20
-    /* cur now contains the element, before which we'll enqueue. */
-    PRINT(3,"\tlist_add to %p\n",cur->prev);
+    /* cur now contains the element, before which we'll enqueue */
     list_add(element, cur->prev);
 }
=20
@@ -303,30 +263,26 @@ static int name##_comp(struct list_head*
         return 1;                                                       \
 }
=20
-/* adds a domain to the queue of processes which wait for the beginning of=
 the
-   next period; this list is therefore sortet by this time, which is simpl=
y
-   absol. deadline - period
+/* Adds a domain to the queue of processes which wait for the beginning of=
 the
+ * next period; this list is therefore sortet by this time, which is simpl=
y
+ * absol. deadline - period.
  */=20
 DOMAIN_COMPARER(waitq, list, PERIOD_BEGIN(d1), PERIOD_BEGIN(d2));
 static inline void __add_to_waitqueue_sort(struct vcpu *v)
 {
     ASSERT(!__task_on_queue(v));
-    PRINT(3,"Adding domain %i.%i (bop=3D %"PRIu64") to waitq\n",
-          v->domain->domain_id, v->vcpu_id, PERIOD_BEGIN(EDOM_INFO(v)));
     list_insert_sort(WAITQ(v->processor), LIST(v), waitq_comp);
     ASSERT(__task_on_queue(v));
 }
=20
-/* adds a domain to the queue of processes which have started their curren=
t
-   period and are runnable (i.e. not blocked, dieing,...). The first eleme=
nt
-   on this list is running on the processor, if the list is empty the idle
-   task will run. As we are implementing EDF, this list is sorted by deadl=
ines.
+/* Adds a domain to the queue of processes which have started their curren=
t
+ * period and are runnable (i.e. not blocked, dieing,...). The first eleme=
nt
+ * on this list is running on the processor, if the list is empty the idle
+ * task will run. As we are implementing EDF, this list is sorted by deadl=
ines.
  */=20
 DOMAIN_COMPARER(runq, list, d1->deadl_abs, d2->deadl_abs);
 static inline void __add_to_runqueue_sort(struct vcpu *v)
 {
-    PRINT(3,"Adding domain %i.%i (deadl=3D %"PRIu64") to runq\n",
-          v->domain->domain_id, v->vcpu_id, EDOM_INFO(v)->deadl_abs);
     list_insert_sort(RUNQ(v->processor), LIST(v), runq_comp);
 }
=20
@@ -445,22 +401,21 @@ static int sedf_pick_cpu(const struct sc
     return cpumask_first(&online_affinity);
 }
=20
-/*
- * Handles the rescheduling & bookkeeping of domains running in their
+
+/* Handles the rescheduling & bookkeeping of domains running in their
  * guaranteed timeslice.
  */
 static void desched_edf_dom(s_time_t now, struct vcpu* d)
 {
     struct sedf_vcpu_info* inf =3D EDOM_INFO(d);
=20
-    /* Current domain is running in real time mode. */
+    /* Current domain is running in real time mode */
     ASSERT(__task_on_queue(d));
=20
-    /* Update the domain's cputime. */
+    /* Update the domain's cputime */
     inf->cputime +=3D now - inf->sched_start_abs;
=20
-    /*
-     * Scheduling decisions which don't remove the running domain from the
+    /* Scheduling decisions which don't remove the running domain from the
      * runq.=20
      */
     if ( (inf->cputime < inf->slice) && sedf_runnable(d) )
@@ -468,8 +423,7 @@ static void desched_edf_dom(s_time_t now
  =20
     __del_from_queue(d);
  =20
-    /*
-     * Manage bookkeeping (i.e. calculate next deadline, memorise
+    /* Manage bookkeeping (i.e. calculate next deadline, memorise
      * overrun-time of slice) of finished domains.
      */
     if ( inf->cputime >=3D inf->slice )
@@ -478,30 +432,30 @@ static void desched_edf_dom(s_time_t now
  =20
         if ( inf->period < inf->period_orig )
         {
-            /* This domain runs in latency scaling or burst mode. */
+            /* This domain runs in latency scaling or burst mode */
             inf->period *=3D 2;
             inf->slice  *=3D 2;
             if ( (inf->period > inf->period_orig) ||
                  (inf->slice > inf->slice_orig) )
             {
-                /* Reset slice and period. */
+                /* Reset slice and period */
                 inf->period =3D inf->period_orig;
                 inf->slice =3D inf->slice_orig;
             }
         }
=20
-        /* Set next deadline. */
+        /* Set next deadline */
         inf->deadl_abs +=3D inf->period;
     }
 =20
-    /* Add a runnable domain to the waitqueue. */
+    /* Add a runnable domain to the waitqueue */
     if ( sedf_runnable(d) )
     {
         __add_to_waitqueue_sort(d);
     }
     else
     {
-        /* We have a blocked realtime task -> remove it from exqs too. */
+        /* We have a blocked realtime task -> remove it from exqs too */
         if ( extraq_on(d, EXTRA_PEN_Q) )
             extraq_del(d, EXTRA_PEN_Q);
         if ( extraq_on(d, EXTRA_UTIL_Q) )
@@ -521,73 +475,59 @@ static void update_queues(
     struct list_head     *cur, *tmp;
     struct sedf_vcpu_info *curinf;
 =20
-    PRINT(3,"Updating waitq..\n");
-
-    /*
-     * Check for the first elements of the waitqueue, whether their
+    /* Check for the first elements of the waitqueue, whether their
      * next period has already started.
      */
     list_for_each_safe ( cur, tmp, waitq )
     {
         curinf =3D list_entry(cur, struct sedf_vcpu_info, list);
-        PRINT(4,"\tLooking @ dom %i.%i\n",
-              curinf->vcpu->domain->domain_id, curinf->vcpu->vcpu_id);
         if ( PERIOD_BEGIN(curinf) > now )
             break;
         __del_from_queue(curinf->vcpu);
         __add_to_runqueue_sort(curinf->vcpu);
     }
 =20
-    PRINT(3,"Updating runq..\n");
-
-    /* Process the runq, find domains that are on the runq that shouldn't.=
 */
+    /* Process the runq, find domains that are on the runq that shouldn't =
*/
     list_for_each_safe ( cur, tmp, runq )
     {
         curinf =3D list_entry(cur,struct sedf_vcpu_info,list);
-        PRINT(4,"\tLooking @ dom %i.%i\n",
-              curinf->vcpu->domain->domain_id, curinf->vcpu->vcpu_id);
=20
         if ( unlikely(curinf->slice =3D=3D 0) )
         {
-            /* Ignore domains with empty slice. */
-            PRINT(4,"\tUpdating zero-slice domain %i.%i\n",
-                  curinf->vcpu->domain->domain_id,
-                  curinf->vcpu->vcpu_id);
+            /* Ignore domains with empty slice */
             __del_from_queue(curinf->vcpu);
=20
-            /* Move them to their next period. */
+            /* Move them to their next period */
             curinf->deadl_abs +=3D curinf->period;
=20
-            /* Ensure that the start of the next period is in the future. =
*/
+            /* Ensure that the start of the next period is in the future *=
/
             if ( unlikely(PERIOD_BEGIN(curinf) < now) )
                 curinf->deadl_abs +=3D=20
                     (DIV_UP(now - PERIOD_BEGIN(curinf),
                             curinf->period)) * curinf->period;
=20
-            /* Put them back into the queue. */
+            /* Put them back into the queue */
             __add_to_waitqueue_sort(curinf->vcpu);
         }
         else if ( unlikely((curinf->deadl_abs < now) ||
                            (curinf->cputime > curinf->slice)) )
         {
-            /*
-             * We missed the deadline or the slice was already finished.
+            /* We missed the deadline or the slice was already finished.
              * Might hapen because of dom_adj.
              */
-            PRINT(4,"\tDomain %i.%i exceeded it's deadline/"
-                  "slice (%"PRIu64" / %"PRIu64") now: %"PRIu64
-                  " cputime: %"PRIu64"\n",
-                  curinf->vcpu->domain->domain_id,
-                  curinf->vcpu->vcpu_id,
-                  curinf->deadl_abs, curinf->slice, now,
-                  curinf->cputime);
+            printk("\tDomain %i.%i exceeded it's deadline/"
+                   "slice (%"PRIu64" / %"PRIu64") now: %"PRIu64
+                   " cputime: %"PRIu64"\n",
+                   curinf->vcpu->domain->domain_id,
+                   curinf->vcpu->vcpu_id,
+                   curinf->deadl_abs, curinf->slice, now,
+                   curinf->cputime);
             __del_from_queue(curinf->vcpu);
=20
-            /* Common case: we miss one period. */
+            /* Common case: we miss one period */
             curinf->deadl_abs +=3D curinf->period;
   =20
-            /*
-             * If we are still behind: modulo arithmetic, force deadline
+            /* If we are still behind: modulo arithmetic, force deadline
              * to be in future and aligned to period borders.
              */
             if ( unlikely(curinf->deadl_abs < now) )
@@ -596,7 +536,7 @@ static void update_queues(
                            curinf->period) * curinf->period;
             ASSERT(curinf->deadl_abs >=3D now);
=20
-            /* Give a fresh slice. */
+            /* Give a fresh slice */
             curinf->cputime =3D 0;
             if ( PERIOD_BEGIN(curinf) > now )
                 __add_to_waitqueue_sort(curinf->vcpu);
@@ -606,17 +546,16 @@ static void update_queues(
         else
             break;
     }
-
-    PRINT(3,"done updating the queues\n");
 }
=20

 /* removes a domain from the head of the according extraQ and
-   requeues it at a specified position:
-     round-robin extratime: end of extraQ
-     weighted ext.: insert in sorted list by score
-   if the domain is blocked / has regained its short-block-loss
-   time it is not put on any queue */
+ * requeues it at a specified position:
+ *   round-robin extratime: end of extraQ
+ *   weighted ext.: insert in sorted list by score
+ * if the domain is blocked / has regained its short-block-loss
+ * time it is not put on any queue.
+ */
 static void desched_extra_dom(s_time_t now, struct vcpu *d)
 {
     struct sedf_vcpu_info *inf =3D EDOM_INFO(d);
@@ -625,29 +564,25 @@ static void desched_extra_dom(s_time_t n
=20
     ASSERT(extraq_on(d, i));
=20
-    /* Unset all running flags. */
+    /* Unset all running flags */
     inf->status  &=3D ~(EXTRA_RUN_PEN | EXTRA_RUN_UTIL);
-    /* Fresh slice for the next run. */
+    /* Fresh slice for the next run */
     inf->cputime =3D 0;
-    /* Accumulate total extratime. */
+    /* Accumulate total extratime */
     inf->extra_time_tot +=3D now - inf->sched_start_abs;
     /* Remove extradomain from head of the queue. */
     extraq_del(d, i);
=20
-    /* Update the score. */
+    /* Update the score */
     oldscore =3D inf->score[i];
     if ( i =3D=3D EXTRA_PEN_Q )
     {
-        /*domain was running in L0 extraq*/
-        /*reduce block lost, probably more sophistication here!*/
+        /* Domain was running in L0 extraq */
+        /* reduce block lost, probably more sophistication here!*/
         /*inf->short_block_lost_tot -=3D EXTRA_QUANTUM;*/
         inf->short_block_lost_tot -=3D now - inf->sched_start_abs;
-        PRINT(3,"Domain %i.%i: Short_block_loss: %"PRIi64"\n",=20
-              inf->vcpu->domain->domain_id, inf->vcpu->vcpu_id,
-              inf->short_block_lost_tot);
 #if 0
-        /*
-         * KAF: If we don't exit short-blocking state at this point
+        /* KAF: If we don't exit short-blocking state at this point
          * domain0 can steal all CPU for up to 10 seconds before
          * scheduling settles down (when competing against another
          * CPU-bound domain). Doing this seems to make things behave
@@ -656,51 +591,56 @@ static void desched_extra_dom(s_time_t n
         if ( inf->short_block_lost_tot <=3D 0 )
 #endif
         {
-            PRINT(4,"Domain %i.%i compensated short block loss!\n",
-                  inf->vcpu->domain->domain_id, inf->vcpu->vcpu_id);
-            /*we have (over-)compensated our block penalty*/
+            /* We have (over-)compensated our block penalty */
             inf->short_block_lost_tot =3D 0;
-            /*we don't want a place on the penalty queue anymore!*/
+            /* We don't want a place on the penalty queue anymore! */
             inf->status &=3D ~EXTRA_WANT_PEN_Q;
             goto check_extra_queues;
         }
=20
-        /*we have to go again for another try in the block-extraq,
-          the score is not used incremantally here, as this is
-          already done by recalculating the block_lost*/
+        /* We have to go again for another try in the block-extraq,
+         * the score is not used incremantally here, as this is
+         * already done by recalculating the block_lost
+         */
         inf->score[EXTRA_PEN_Q] =3D (inf->period << 10) /
             inf->short_block_lost_tot;
         oldscore =3D 0;
     }
     else
     {
-        /*domain was running in L1 extraq =3D> score is inverse of
-          utilization and is used somewhat incremental!*/
+        /* Domain was running in L1 extraq =3D> score is inverse of
+         * utilization and is used somewhat incremental!
+         */
         if ( !inf->extraweight )
-            /*NB: use fixed point arithmetic with 10 bits*/
+        {
+            /* NB: use fixed point arithmetic with 10 bits */
             inf->score[EXTRA_UTIL_Q] =3D (inf->period << 10) /
                 inf->slice;
+        }
         else
-            /*conversion between realtime utilisation and extrawieght:
-              full (ie 100%) utilization is equivalent to 128 extraweight*=
/
+        {
+            /* Conversion between realtime utilisation and extrawieght:
+             * full (ie 100%) utilization is equivalent to 128 extraweight
+             */
             inf->score[EXTRA_UTIL_Q] =3D (1<<17) / inf->extraweight;
+        }
     }
=20
  check_extra_queues:
-    /* Adding a runnable domain to the right queue and removing blocked on=
es*/
+    /* Adding a runnable domain to the right queue and removing blocked on=
es */
     if ( sedf_runnable(d) )
     {
-        /*add according to score: weighted round robin*/
+        /* Add according to score: weighted round robin */
         if (((inf->status & EXTRA_AWARE) && (i =3D=3D EXTRA_UTIL_Q)) ||
             ((inf->status & EXTRA_WANT_PEN_Q) && (i =3D=3D EXTRA_PEN_Q)))
             extraq_add_sort_update(d, i, oldscore);
     }
     else
     {
-        /*remove this blocked domain from the waitq!*/
+        /* Remove this blocked domain from the waitq! */
         __del_from_queue(d);
-        /*make sure that we remove a blocked domain from the other
-          extraq too*/
+        /* Make sure that we remove a blocked domain from the other
+         * extraq too. */
         if ( i =3D=3D EXTRA_PEN_Q )
         {
             if ( extraq_on(d, EXTRA_UTIL_Q) )
@@ -732,8 +672,9 @@ static struct task_slice sedf_do_extra_s
=20
     if ( !list_empty(extraq[EXTRA_PEN_Q]) )
     {
-        /*we still have elements on the level 0 extraq=20
-          =3D> let those run first!*/
+        /* We still have elements on the level 0 extraq
+         * =3D> let those run first!
+         */
         runinf   =3D list_entry(extraq[EXTRA_PEN_Q]->next,=20
                               struct sedf_vcpu_info, extralist[EXTRA_PEN_Q=
]);
         runinf->status |=3D EXTRA_RUN_PEN;
@@ -747,7 +688,7 @@ static struct task_slice sedf_do_extra_s
     {
         if ( !list_empty(extraq[EXTRA_UTIL_Q]) )
         {
-            /*use elements from the normal extraqueue*/
+            /* Use elements from the normal extraqueue */
             runinf   =3D list_entry(extraq[EXTRA_UTIL_Q]->next,
                                   struct sedf_vcpu_info,
                                   extralist[EXTRA_UTIL_Q]);
@@ -773,10 +714,11 @@ static struct task_slice sedf_do_extra_s
=20

 /* Main scheduling function
-   Reasons for calling this function are:
-   -timeslice for the current period used up
-   -domain on waitqueue has started it's period
-   -and various others ;) in general: determine which domain to run next*/
+ * Reasons for calling this function are:
+ * -timeslice for the current period used up
+ * -domain on waitqueue has started it's period
+ * -and various others ;) in general: determine which domain to run next
+ */
 static struct task_slice sedf_do_schedule(
     const struct scheduler *ops, s_time_t now, bool_t tasklet_work_schedul=
ed)
 {
@@ -789,13 +731,14 @@ static struct task_slice sedf_do_schedul
     struct sedf_vcpu_info *runinf, *waitinf;
     struct task_slice      ret;
=20
-    /*idle tasks don't need any of the following stuf*/
+    /* Idle tasks don't need any of the following stuf */
     if ( is_idle_vcpu(current) )
         goto check_waitq;
 =20
-    /* create local state of the status of the domain, in order to avoid
-       inconsistent state during scheduling decisions, because data for
-       vcpu_runnable is not protected by the scheduling lock!*/
+    /* Create local state of the status of the domain, in order to avoid
+     * inconsistent state during scheduling decisions, because data for
+     * vcpu_runnable is not protected by the scheduling lock!
+     */
     if ( !vcpu_runnable(current) )
         inf->status |=3D SEDF_ASLEEP;
 =20
@@ -804,7 +747,7 @@ static struct task_slice sedf_do_schedul
=20
     if ( unlikely(extra_runs(inf)) )
     {
-        /*special treatment of domains running in extra time*/
+        /* Special treatment of domains running in extra time */
         desched_extra_dom(now, current);
     }
     else=20
@@ -814,10 +757,11 @@ static struct task_slice sedf_do_schedul
  check_waitq:
     update_queues(now, runq, waitq);
=20
-    /*now simply pick the first domain from the runqueue, which has the
-      earliest deadline, because the list is sorted*/
-=20
-    /* Tasklet work (which runs in idle VCPU context) overrides all else. =
*/
+    /* Now simply pick the first domain from the runqueue, which has the
+     * earliest deadline, because the list is sorted
+     *
+     * Tasklet work (which runs in idle VCPU context) overrides all else.
+     */
     if ( tasklet_work_scheduled ||
          (list_empty(runq) && list_empty(waitq)) ||
          unlikely(!cpumask_test_cpu(cpu, SEDF_CPUONLINE(per_cpu(cpupool, c=
pu)))) )
@@ -833,9 +777,10 @@ static struct task_slice sedf_do_schedul
         {
             waitinf  =3D list_entry(waitq->next,
                                   struct sedf_vcpu_info,list);
-            /*rerun scheduler, when scheduled domain reaches it's
-              end of slice or the first domain from the waitqueue
-              gets ready*/
+            /* Rerun scheduler, when scheduled domain reaches it's
+             * end of slice or the first domain from the waitqueue
+             * gets ready.
+             */
             ret.time =3D MIN(now + runinf->slice - runinf->cputime,
                            PERIOD_BEGIN(waitinf)) - now;
         }
@@ -847,14 +792,15 @@ static struct task_slice sedf_do_schedul
     else
     {
         waitinf  =3D list_entry(waitq->next,struct sedf_vcpu_info, list);
-        /*we could not find any suitable domain=20
-          =3D> look for domains that are aware of extratime*/
+        /* We could not find any suitable domain=20
+         * =3D> look for domains that are aware of extratime*/
         ret =3D sedf_do_extra_schedule(now, PERIOD_BEGIN(waitinf),
                                      extraq, cpu);
     }
=20
-    /*TODO: Do something USEFUL when this happens and find out, why it
-      still can happen!!!*/
+    /* TODO: Do something USEFUL when this happens and find out, why it
+     * still can happen!!!
+     */
     if ( ret.time < 0)
     {
         printk("Ouch! We are seriously BEHIND schedule! %"PRIi64"\n",
@@ -874,9 +820,6 @@ static struct task_slice sedf_do_schedul
=20
 static void sedf_sleep(const struct scheduler *ops, struct vcpu *d)
 {
-    PRINT(2,"sedf_sleep was called, domain-id %i.%i\n",
-          d->domain->domain_id, d->vcpu_id);
-=20
     if ( is_idle_vcpu(d) )
         return;
=20
@@ -972,27 +915,29 @@ static void sedf_sleep(const struct sche
 static void unblock_short_extra_support(
     struct sedf_vcpu_info* inf, s_time_t now)
 {
-    /*this unblocking scheme tries to support the domain, by assigning it
-    a priority in extratime distribution according to the loss of time
-    in this slice due to blocking*/
+    /* This unblocking scheme tries to support the domain, by assigning it
+     * a priority in extratime distribution according to the loss of time
+     * in this slice due to blocking
+     */
     s_time_t pen;
 =20
-    /*no more realtime execution in this period!*/
+    /* No more realtime execution in this period! */
     inf->deadl_abs +=3D inf->period;
     if ( likely(inf->block_abs) )
     {
-        //treat blocked time as consumed by the domain*/
+        /* Treat blocked time as consumed by the domain */
         /*inf->cputime +=3D now - inf->block_abs;*/
-        /*penalty is time the domain would have
-          had if it continued to run */
+        /* Penalty is time the domain would have
+         * had if it continued to run.
+         */
         pen =3D (inf->slice - inf->cputime);
         if ( pen < 0 )
             pen =3D 0;
-        /*accumulate all penalties over the periods*/
+        /* Accumulate all penalties over the periods */
         /*inf->short_block_lost_tot +=3D pen;*/
-        /*set penalty to the current value*/
+        /* Set penalty to the current value */
         inf->short_block_lost_tot =3D pen;
-        /*not sure which one is better.. but seems to work well...*/
+        /* Not sure which one is better.. but seems to work well... */
  =20
         if ( inf->short_block_lost_tot )
         {
@@ -1002,28 +947,30 @@ static void unblock_short_extra_support(
             inf->pen_extra_blocks++;
 #endif
             if ( extraq_on(inf->vcpu, EXTRA_PEN_Q) )
-                /*remove domain for possible resorting!*/
+                /* Remove domain for possible resorting! */
                 extraq_del(inf->vcpu, EXTRA_PEN_Q);
             else
-                /*remember that we want to be on the penalty q
-                  so that we can continue when we (un-)block
-                  in penalty-extratime*/
+                /* Remember that we want to be on the penalty q
+                 * so that we can continue when we (un-)block
+                 * in penalty-extratime
+                 */
                 inf->status |=3D EXTRA_WANT_PEN_Q;
   =20
-            /*(re-)add domain to the penalty extraq*/
+            /* (re-)add domain to the penalty extraq */
             extraq_add_sort_update(inf->vcpu, EXTRA_PEN_Q, 0);
         }
     }
=20
-    /*give it a fresh slice in the next period!*/
+    /* Give it a fresh slice in the next period! */
     inf->cputime =3D 0;
 }
=20

 static void unblock_long_cons_b(struct sedf_vcpu_info* inf,s_time_t now)
 {
-    /*Conservative 2b*/
-    /*Treat the unblocking time as a start of a new period */
+    /* Conservative 2b */
+
+    /* Treat the unblocking time as a start of a new period */
     inf->deadl_abs =3D now + inf->period;
     inf->cputime =3D 0;
 }
@@ -1046,15 +993,16 @@ static inline int get_run_type(struct vc
 }
=20

-/*Compares two domains in the relation of whether the one is allowed to
-  interrupt the others execution.
-  It returns true (!=3D0) if a switch to the other domain is good.
-  Current Priority scheme is as follows:
-   EDF > L0 (penalty based) extra-time >=20
-   L1 (utilization) extra-time > idle-domain
-  In the same class priorities are assigned as following:
-   EDF: early deadline > late deadline
-   L0 extra-time: lower score > higher score*/
+/* Compares two domains in the relation of whether the one is allowed to
+ * interrupt the others execution.
+ * It returns true (!=3D0) if a switch to the other domain is good.
+ * Current Priority scheme is as follows:
+ *  EDF > L0 (penalty based) extra-time >=20
+ *  L1 (utilization) extra-time > idle-domain
+ * In the same class priorities are assigned as following:
+ *  EDF: early deadline > late deadline
+ *  L0 extra-time: lower score > higher score
+ */
 static inline int should_switch(struct vcpu *cur,
                                 struct vcpu *other,
                                 s_time_t now)
@@ -1063,19 +1011,19 @@ static inline int should_switch(struct v
     cur_inf   =3D EDOM_INFO(cur);
     other_inf =3D EDOM_INFO(other);
 =20
-    /* Check whether we need to make an earlier scheduling decision. */
+    /* Check whether we need to make an earlier scheduling decision */
     if ( PERIOD_BEGIN(other_inf) <=20
          CPU_INFO(other->processor)->current_slice_expires )
         return 1;
=20
-    /* No timing-based switches need to be taken into account here. */
+    /* No timing-based switches need to be taken into account here */
     switch ( get_run_type(cur) )
     {
     case DOMAIN_EDF:
-        /* Do not interrupt a running EDF domain. */
+        /* Do not interrupt a running EDF domain */
         return 0;
     case DOMAIN_EXTRA_PEN:
-        /* Check whether we also want the L0 ex-q with lower score. */
+        /* Check whether we also want the L0 ex-q with lower score */
         return ((other_inf->status & EXTRA_WANT_PEN_Q) &&
                 (other_inf->score[EXTRA_PEN_Q] <=20
                  cur_inf->score[EXTRA_PEN_Q]));
@@ -1096,18 +1044,11 @@ static void sedf_wake(const struct sched
     s_time_t              now =3D NOW();
     struct sedf_vcpu_info* inf =3D EDOM_INFO(d);
=20
-    PRINT(3, "sedf_wake was called, domain-id %i.%i\n",d->domain->domain_i=
d,
-          d->vcpu_id);
-
     if ( unlikely(is_idle_vcpu(d)) )
         return;
   =20
     if ( unlikely(__task_on_queue(d)) )
-    {
-        PRINT(3,"\tdomain %i.%i is already in some queue\n",
-              d->domain->domain_id, d->vcpu_id);
         return;
-    }
=20
     ASSERT(!sedf_runnable(d));
     inf->status &=3D ~SEDF_ASLEEP;
@@ -1116,28 +1057,24 @@ static void sedf_wake(const struct sched
 =20
     if ( unlikely(inf->deadl_abs =3D=3D 0) )
     {
-        /*initial setup of the deadline*/
+        /* Initial setup of the deadline */
         inf->deadl_abs =3D now + inf->slice;
     }
  =20
-    PRINT(3, "waking up domain %i.%i (deadl=3D %"PRIu64" period=3D %"PRIu6=
4
-          "now=3D %"PRIu64")\n",
-          d->domain->domain_id, d->vcpu_id, inf->deadl_abs, inf->period, n=
ow);
-
 #ifdef SEDF_STATS=20
     inf->block_tot++;
 #endif
=20
     if ( unlikely(now < PERIOD_BEGIN(inf)) )
     {
-        PRINT(4,"extratime unblock\n");
-        /* unblocking in extra-time! */
+        /* Unblocking in extra-time! */
         if ( inf->status & EXTRA_WANT_PEN_Q )
         {
-            /*we have a domain that wants compensation
-              for block penalty and did just block in
-              its compensation time. Give it another
-              chance!*/
+            /* We have a domain that wants compensation
+             * for block penalty and did just block in
+             * its compensation time. Give it another
+             * chance!
+             */
             extraq_add_sort_update(d, EXTRA_PEN_Q, 0);
         }
         extraq_check_add_unblocked(d, 0);
@@ -1146,8 +1083,7 @@ static void sedf_wake(const struct sched
     { =20
         if ( now < inf->deadl_abs )
         {
-            PRINT(4,"short unblocking\n");
-            /*short blocking*/
+            /* Short blocking */
 #ifdef SEDF_STATS
             inf->short_block_tot++;
 #endif
@@ -1157,8 +1093,7 @@ static void sedf_wake(const struct sched
         }
         else
         {
-            PRINT(4,"long unblocking\n");
-            /*long unblocking*/
+            /* Long unblocking */
 #ifdef SEDF_STATS
             inf->long_block_tot++;
 #endif
@@ -1168,24 +1103,13 @@ static void sedf_wake(const struct sched
         }
     }
=20
-    PRINT(3, "woke up domain %i.%i (deadl=3D %"PRIu64" period=3D %"PRIu64
-          "now=3D %"PRIu64")\n",
-          d->domain->domain_id, d->vcpu_id, inf->deadl_abs,
-          inf->period, now);
-
     if ( PERIOD_BEGIN(inf) > now )
-    {
         __add_to_waitqueue_sort(d);
-        PRINT(3,"added to waitq\n");
-    }
     else
-    {
         __add_to_runqueue_sort(d);
-        PRINT(3,"added to runq\n");
-    }
 =20
 #ifdef SEDF_STATS
-    /*do some statistics here...*/
+    /* Do some statistics here... */
     if ( inf->block_abs !=3D 0 )
     {
         inf->block_time_tot +=3D now - inf->block_abs;
@@ -1194,12 +1118,13 @@ static void sedf_wake(const struct sched
     }
 #endif
=20
-    /*sanity check: make sure each extra-aware domain IS on the util-q!*/
+    /* Sanity check: make sure each extra-aware domain IS on the util-q! *=
/
     ASSERT(IMPLY(inf->status & EXTRA_AWARE, extraq_on(d, EXTRA_UTIL_Q)));
     ASSERT(__task_on_queue(d));
-    /*check whether the awakened task needs to invoke the do_schedule
-      routine. Try to avoid unnecessary runs but:
-      Save approximation: Always switch to scheduler!*/
+    /* Check whether the awakened task needs to invoke the do_schedule
+     * routine. Try to avoid unnecessary runs but:
+     * Save approximation: Always switch to scheduler!
+     */
     ASSERT(d->processor >=3D 0);
     ASSERT(d->processor < nr_cpu_ids);
     ASSERT(per_cpu(schedule_data, d->processor).curr);
@@ -1244,7 +1169,7 @@ static void sedf_dump_domain(struct vcpu
 }
=20

-/* dumps all domains on the specified cpu */
+/* Dumps all domains on the specified cpu */
 static void sedf_dump_cpu_state(const struct scheduler *ops, int i)
 {
     struct list_head      *list, *queue, *tmp;
@@ -1319,7 +1244,7 @@ static void sedf_dump_cpu_state(const st
 }
=20

-/* Adjusts periods and slices of the domains accordingly to their weights.=
 */
+/* Adjusts periods and slices of the domains accordingly to their weights =
*/
 static int sedf_adjust_weights(struct cpupool *c, struct xen_domctl_schedu=
ler_op *cmd)
 {
     struct vcpu *p;
@@ -1335,7 +1260,7 @@ static int sedf_adjust_weights(struct cp
         return -ENOMEM;
     }
=20
-    /* Sum across all weights. */
+    /* Sum across all weights */
     rcu_read_lock(&domlist_read_lock);
     for_each_domain_in_cpupool( d, c )
     {
@@ -1350,11 +1275,13 @@ static int sedf_adjust_weights(struct cp
             }
             else
             {
-                /*don't modify domains who don't have a weight, but sum
-                  up the time they need, projected to a WEIGHT_PERIOD,
-                  so that this time is not given to the weight-driven
-                  domains*/
-                /*check for overflows*/
+                /* Don't modify domains who don't have a weight, but sum
+                 * up the time they need, projected to a WEIGHT_PERIOD,
+                 * so that this time is not given to the weight-driven
+                 *  domains
+                 */
+
+                /* Check for overflows */
                 ASSERT((WEIGHT_PERIOD < ULONG_MAX)=20
                        && (EDOM_INFO(p)->slice_orig < ULONG_MAX));
                 sumt[cpu] +=3D=20
@@ -1365,7 +1292,7 @@ static int sedf_adjust_weights(struct cp
     }
     rcu_read_unlock(&domlist_read_lock);
=20
-    /* Adjust all slices (and periods) to the new weight. */
+    /* Adjust all slices (and periods) to the new weight */
     rcu_read_lock(&domlist_read_lock);
     for_each_domain_in_cpupool( d, c )
     {
@@ -1393,20 +1320,15 @@ static int sedf_adjust_weights(struct cp
 }
=20

-/* set or fetch domain scheduling parameters */
+/* Set or fetch domain scheduling parameters */
 static int sedf_adjust(const struct scheduler *ops, struct domain *p, stru=
ct xen_domctl_scheduler_op *op)
 {
     struct vcpu *v;
     int rc;
=20
-    PRINT(2,"sedf_adjust was called, domain-id %i new period %"PRIu64" "
-          "new slice %"PRIu64"\nlatency %"PRIu64" extra:%s\n",
-          p->domain_id, op->u.sedf.period, op->u.sedf.slice,
-          op->u.sedf.latency, (op->u.sedf.extratime)?"yes":"no");
-
     if ( op->cmd =3D=3D XEN_DOMCTL_SCHEDOP_putinfo )
     {
-        /* Check for sane parameters. */
+        /* Check for sane parameters */
         if ( !op->u.sedf.period && !op->u.sedf.weight )
             return -EINVAL;
         if ( op->u.sedf.weight )
@@ -1414,7 +1336,7 @@ static int sedf_adjust(const struct sche
             if ( (op->u.sedf.extratime & EXTRA_AWARE) &&
                  (!op->u.sedf.period) )
             {
-                /* Weight-driven domains with extratime only. */
+                /* Weight-driven domains with extratime only */
                 for_each_vcpu ( p, v )
                 {
                     EDOM_INFO(v)->extraweight =3D op->u.sedf.weight;
@@ -1425,7 +1347,7 @@ static int sedf_adjust(const struct sche
             }
             else
             {
-                /* Weight-driven domains with real-time execution. */
+                /* Weight-driven domains with real-time execution */
                 for_each_vcpu ( p, v )
                     EDOM_INFO(v)->weight =3D op->u.sedf.weight;
             }
@@ -1435,8 +1357,7 @@ static int sedf_adjust(const struct sche
             /* Time-driven domains. */
             for_each_vcpu ( p, v )
             {
-                /*
-                 * Sanity checking: note that disabling extra weight requi=
res
+                /* Sanity checking: note that disabling extra weight requi=
res
                  * that we set a non-zero slice.
                  */
                 if ( (op->u.sedf.period > PERIOD_MAX) ||
@@ -1477,7 +1398,6 @@ static int sedf_adjust(const struct sche
         op->u.sedf.weight    =3D EDOM_INFO(p->vcpu[0])->weight;
     }
=20
-    PRINT(2,"sedf_adjust_finished\n");
     return 0;
 }
=20

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-------------------------------------------------------------------
Dario Faggioli, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
PhD Candidate, ReTiS Lab, Scuola Superiore Sant'Anna, Pisa (Italy)




--=-3p5/0djGq6n5G1gGRftX
Content-Disposition: attachment; filename="sedf-debug-cleanup.patch"
Content-Type: text/x-patch; name="sedf-debug-cleanup.patch"; charset="UTF-8"
Content-Transfer-Encoding: base64

IyBIRyBjaGFuZ2VzZXQgcGF0Y2gNCiMgUGFyZW50IDE3ZDk5NjkxZTBlYzFmYTdiYjcxY2YxOGMx
MmNhM2MwNDZjMGM4ZDcNCnNlZGY6IHJlbW92ZSB1c2VsZXNzIHRyYWNpbmcgcHJpbnRrIGFuZCBo
YXJtb25pemUgY29tbWVudHMgc3R5bGUuDQoNCnNjaGVkX3NlZGYuYyB1c2VkIG8gaGF2ZSBpdHMg
b3duIG1lY2hhbmlzbSBmb3IgcHJvZHVjaW5nIHRyYWNpbmctYWxpa2UNCmtpbmQgb2YgaW5mb3Jt
YXRpb24gKGRvbWFpbiBibG9jaywgd2FrZXVwLCBldGMuKS4gTm93YWRheXMsIHdpdGggYW4gZXZl
bg0Kbm90IHNvIGhpZ2ggbnVtYmVyIG9mIHBDUFVzL3ZDUFVzLCBqdXN0IHRyeWluZyB0byBlbmFi
bGUgdGhpcyBtYWtlcw0KdGhlIHNlcmlhbCBjb25zb2xlIGNvbXBsZXRlbHkgdW51c2FibGUsIHBy
b2R1Y2VzIHRvbnMgb2YgdmVyeSBoYXJkIHRvDQpwYXJzZSBhbmQgaW50ZXJwcmVldCBsb2dnaW5n
IGFuZCBjYW4gZWFzaWx5IGxpdmVsb2NrIERvbTAuIE1vcmVvdmVyLA0KcHJldHR5IG11Y2ggdGhl
IHNhbWUgcmVzdWx0IHRoaXMgaXMgc3RydWdnbGluZyB0byBnZXQgdG8sIGlzIGJldHRlcg0KYWNo
aWV2ZWQgYnkgZW5hYmxpbmcgdGhlIHNjaGVkdWxlci1yZWxhdGVkIHRyYWNpbmcgZXZlbnRzLCBh
cw0KaXQgaXMgZm9yIHRoZSBvdGhlciBzY2hlZHVsZXJzIChzYXksIGNyZWRpdCBvciBjcmVkaXQy
KS4NCg0KRm9yIGFsbCB0aGVzZSByZWFzb25zLCB0aGlzIHJlbW92ZXMgdGhhdCBtYWNoaW5lcnkg
Y29tcGxldGVseS4gV2hpbGUgYXQNCml0LCBjaGVjayBpbiBzb21lIGNvc21ldGljcyB0aGF0IGhh
cm1vbml6ZSB0aGUgY29tbWVudHMgd2l0aGltIHRoZW1zZWxmDQphbmQgd2l0aCB0aGUgcmVzdCBv
ZiB0aGUgY29kZSBiYXNlLg0KDQpTaWduZWQtb2ZmLWJ5OiBEYXJpbyBGYWdnaW9saSA8ZGFyaW8u
ZmFnZ2lvbGlAY2l0cml4LmNvbT4NCg0KZGlmZiAtciAxN2Q5OTY5MWUwZWMgeGVuL2NvbW1vbi9z
Y2hlZF9zZWRmLmMNCi0tLSBhL3hlbi9jb21tb24vc2NoZWRfc2VkZi5jCVR1ZSBEZWMgMjAgMTY6
Mzk6NTYgMjAxMSArMDAwMA0KKysrIGIveGVuL2NvbW1vbi9zY2hlZF9zZWRmLmMJVHVlIERlYyAy
MCAxNzozMjo1MiAyMDExICswMDAwDQpAQCAtMTMsMTQgKzEzLDYgQEANCiAjaW5jbHVkZSA8eGVu
L3RpbWUuaD4NCiAjaW5jbHVkZSA8eGVuL2Vycm5vLmg+DQogDQotLyp2ZXJib3NpdHkgc2V0dGlu
Z3MqLw0KLSNkZWZpbmUgU0VERkxFVkVMIDANCi0jZGVmaW5lIFBSSU5UKF9mLCBfYS4uLikgICAg
ICAgICAgICAgICAgICAgICAgICBcDQotICAgIGRvIHsgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgXA0KLSAgICAgICAgaWYgKCAoX2YpIDw9IFNFREZMRVZFTCApICAgICAg
ICAgICAgICAgIFwNCi0gICAgICAgICAgICBwcmludGsoX2EgKTsgICAgICAgICAgICAgICAgICAg
ICAgICBcDQotICAgIH0gd2hpbGUgKCAwICkNCi0NCiAjZGVmaW5lIFNFREZfQ1BVT05MSU5FKF9w
b29sKSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFwNCiAgICAg
KCgoX3Bvb2wpID09IE5VTEwpID8gJmNwdXBvb2xfZnJlZV9jcHVzIDogKF9wb29sKS0+Y3B1X3Zh
bGlkKQ0KIA0KQEAgLTY2LDM0ICs1OCwzNSBAQCBzdHJ1Y3Qgc2VkZl92Y3B1X2luZm8gew0KICAg
ICBzdHJ1Y3QgbGlzdF9oZWFkIGxpc3Q7DQogICAgIHN0cnVjdCBsaXN0X2hlYWQgZXh0cmFsaXN0
WzJdOw0KICANCi0gICAgLypQYXJhbWV0ZXJzIGZvciBFREYqLw0KLSAgICBzX3RpbWVfdCAgcGVy
aW9kOyAgLyo9KHJlbGF0aXZlIGRlYWRsaW5lKSovDQotICAgIHNfdGltZV90ICBzbGljZTsgIC8q
PXdvcnN0IGNhc2UgZXhlY3V0aW9uIHRpbWUqLw0KKyAgICAvKiBQYXJhbWV0ZXJzIGZvciBFREYg
Ki8NCisgICAgc190aW1lX3QgIHBlcmlvZDsgIC8qID0ocmVsYXRpdmUgZGVhZGxpbmUpICovDQor
ICAgIHNfdGltZV90ICBzbGljZTsgICAvKiA9d29yc3QgY2FzZSBleGVjdXRpb24gdGltZSAqLw0K
ICANCi0gICAgLypBZHZhY2VkIFBhcmFtZXRlcnMqLw0KLSAgICAvKkxhdGVuY3kgU2NhbGluZyov
DQorICAgIC8qIEFkdmFjZWQgUGFyYW1ldGVycyAqLw0KKw0KKyAgICAvKiBMYXRlbmN5IFNjYWxp
bmcgKi8NCiAgICAgc190aW1lX3QgIHBlcmlvZF9vcmlnOw0KICAgICBzX3RpbWVfdCAgc2xpY2Vf
b3JpZzsNCiAgICAgc190aW1lX3QgIGxhdGVuY3k7DQogIA0KLSAgICAvKnN0YXR1cyBvZiBkb21h
aW4qLw0KKyAgICAvKiBTdGF0dXMgb2YgZG9tYWluICovDQogICAgIGludCAgICAgICBzdGF0dXM7
DQotICAgIC8qd2VpZ2h0cyBmb3IgIlNjaGVkdWxpbmcgZm9yIGJlZ2lubmVycy8gbGF6eS8gZXRj
LiIgOykqLw0KKyAgICAvKiBXZWlnaHRzIGZvciAiU2NoZWR1bGluZyBmb3IgYmVnaW5uZXJzLyBs
YXp5LyBldGMuIiA7KSAqLw0KICAgICBzaG9ydCAgICAgd2VpZ2h0Ow0KICAgICBzaG9ydCAgICAg
ZXh0cmF3ZWlnaHQ7DQotICAgIC8qQm9va2tlZXBpbmcqLw0KKyAgICAvKiBCb29ra2VlcGluZyAq
Lw0KICAgICBzX3RpbWVfdCAgZGVhZGxfYWJzOw0KICAgICBzX3RpbWVfdCAgc2NoZWRfc3RhcnRf
YWJzOw0KICAgICBzX3RpbWVfdCAgY3B1dGltZTsNCi0gICAgLyogdGltZXMgdGhlIGRvbWFpbiB1
bi0vYmxvY2tlZCAqLw0KKyAgICAvKiBUaW1lcyB0aGUgZG9tYWluIHVuLS9ibG9ja2VkICovDQog
ICAgIHNfdGltZV90ICBibG9ja19hYnM7DQogICAgIHNfdGltZV90ICB1bmJsb2NrX2FiczsNCiAg
DQotICAgIC8qc2NvcmVzIGZvciB7dXRpbCwgYmxvY2sgcGVuYWx0eX0td2VpZ2h0ZWQgZXh0cmF0
aW1lIGRpc3RyaWJ1dGlvbiovDQorICAgIC8qIFNjb3JlcyBmb3Ige3V0aWwsIGJsb2NrIHBlbmFs
dHl9LXdlaWdodGVkIGV4dHJhdGltZSBkaXN0cmlidXRpb24gKi8NCiAgICAgaW50ICAgc2NvcmVb
Ml07DQogICAgIHNfdGltZV90ICBzaG9ydF9ibG9ja19sb3N0X3RvdDsNCiAgDQotICAgIC8qU3Rh
dGlzdGljcyovDQorICAgIC8qIFN0YXRpc3RpY3MgKi8NCiAgICAgc190aW1lX3QgIGV4dHJhX3Rp
bWVfdG90Ow0KIA0KICNpZmRlZiBTRURGX1NUQVRTDQpAQCAtMTU4LDE4ICsxNTEsMTYgQEAgc3Rh
dGljIGlubGluZSB2b2lkIGV4dHJhcV9kZWwoc3RydWN0IHZjcA0KIHsNCiAgICAgc3RydWN0IGxp
c3RfaGVhZCAqbGlzdCA9IEVYVFJBTElTVChkLGkpOw0KICAgICBBU1NFUlQoZXh0cmFxX29uKGQs
aSkpOw0KLSAgICBQUklOVCgzLCAiUmVtb3ZpbmcgZG9tYWluICVpLiVpIGZyb20gTCVpIGV4dHJh
cVxuIiwNCi0gICAgICAgICAgZC0+ZG9tYWluLT5kb21haW5faWQsIGQtPnZjcHVfaWQsIGkpOw0K
ICAgICBsaXN0X2RlbChsaXN0KTsNCiAgICAgbGlzdC0+bmV4dCA9IE5VTEw7DQogICAgIEFTU0VS
VCghZXh0cmFxX29uKGQsIGkpKTsNCiB9DQogDQotLyogYWRkcyBhIGRvbWFpbiB0byB0aGUgcXVl
dWUgb2YgcHJvY2Vzc2VzIHdoaWNoIGFyZSBhd2FyZSBvZiBleHRyYSB0aW1lLiBMaXN0DQotICAg
aXMgc29ydGVkIGJ5IHNjb3JlLCB3aGVyZSBhIGxvd2VyIHNjb3JlIG1lYW5zIGhpZ2hlciBwcmlv
cml0eSBmb3IgYW4gZXh0cmENCi0gICBzbGljZS4gSXQgYWxzbyB1cGRhdGVzIHRoZSBzY29yZSwg
Ynkgc2ltcGx5IHN1YnRyYWN0aW5nIGEgZml4ZWQgdmFsdWUgZnJvbQ0KLSAgIGVhY2ggZW50cnks
IGluIG9yZGVyIHRvIGF2b2lkIG92ZXJmbG93LiBUaGUgYWxnb3JpdGhtIHdvcmtzIGJ5IHNpbXBs
eQ0KLSAgIGNoYXJnaW5nIGVhY2ggZG9tYWluIHRoYXQgcmVjaWV2ZWQgZXh0cmF0aW1lIHdpdGgg
YW4gaW52ZXJzZSBvZiBpdHMgd2VpZ2h0Lg0KKy8qIEFkZHMgYSBkb21haW4gdG8gdGhlIHF1ZXVl
IG9mIHByb2Nlc3NlcyB3aGljaCBhcmUgYXdhcmUgb2YgZXh0cmEgdGltZS4gTGlzdA0KKyAqIGlz
IHNvcnRlZCBieSBzY29yZSwgd2hlcmUgYSBsb3dlciBzY29yZSBtZWFucyBoaWdoZXIgcHJpb3Jp
dHkgZm9yIGFuIGV4dHJhDQorICogc2xpY2UuIEl0IGFsc28gdXBkYXRlcyB0aGUgc2NvcmUsIGJ5
IHNpbXBseSBzdWJ0cmFjdGluZyBhIGZpeGVkIHZhbHVlIGZyb20NCisgKiBlYWNoIGVudHJ5LCBp
biBvcmRlciB0byBhdm9pZCBvdmVyZmxvdy4gVGhlIGFsZ29yaXRobSB3b3JrcyBieSBzaW1wbHkN
CisgKiBjaGFyZ2luZyBlYWNoIGRvbWFpbiB0aGF0IHJlY2lldmVkIGV4dHJhdGltZSB3aXRoIGFu
IGludmVyc2Ugb2YgaXRzIHdlaWdodC4NCiAgKi8gDQogc3RhdGljIGlubGluZSB2b2lkIGV4dHJh
cV9hZGRfc29ydF91cGRhdGUoc3RydWN0IHZjcHUgKmQsIGludCBpLCBpbnQgc3ViKQ0KIHsNCkBA
IC0xNzgsMTMgKzE2OSw3IEBAIHN0YXRpYyBpbmxpbmUgdm9pZCBleHRyYXFfYWRkX3NvcnRfdXBk
YXQNCiAgDQogICAgIEFTU0VSVCghZXh0cmFxX29uKGQsaSkpOw0KIA0KLSAgICBQUklOVCgzLCAi
QWRkaW5nIGRvbWFpbiAlaS4laSAoc2NvcmU9ICVpLCBzaG9ydF9wZW49ICUiUFJJaTY0IikiDQot
ICAgICAgICAgICIgdG8gTCVpIGV4dHJhcVxuIiwNCi0gICAgICAgICAgZC0+ZG9tYWluLT5kb21h
aW5faWQsIGQtPnZjcHVfaWQsIEVET01fSU5GTyhkKS0+c2NvcmVbaV0sDQotICAgICAgICAgIEVE
T01fSU5GTyhkKS0+c2hvcnRfYmxvY2tfbG9zdF90b3QsIGkpOw0KLQ0KLSAgICAvKg0KLSAgICAg
KiBJdGVyYXRlIHRocm91Z2ggYWxsIGVsZW1lbnRzIHRvIGZpbmQgb3VyICJob2xlIiBhbmQgb24g
b3VyIHdheQ0KKyAgICAvKiBJdGVyYXRlIHRocm91Z2ggYWxsIGVsZW1lbnRzIHRvIGZpbmQgb3Vy
ICJob2xlIiBhbmQgb24gb3VyIHdheQ0KICAgICAgKiB1cGRhdGUgYWxsIHRoZSBvdGhlciBzY29y
ZXMuDQogICAgICAqLw0KICAgICBsaXN0X2Zvcl9lYWNoICggY3VyLCBFWFRSQVEoZC0+cHJvY2Vz
c29yLCBpKSApDQpAQCAtMTkzLDI1ICsxNzgsMTggQEAgc3RhdGljIGlubGluZSB2b2lkIGV4dHJh
cV9hZGRfc29ydF91cGRhdA0KICAgICAgICAgY3VyaW5mLT5zY29yZVtpXSAtPSBzdWI7DQogICAg
ICAgICBpZiAoIEVET01fSU5GTyhkKS0+c2NvcmVbaV0gPCBjdXJpbmYtPnNjb3JlW2ldICkNCiAg
ICAgICAgICAgICBicmVhazsNCi0gICAgICAgIFBSSU5UKDQsIlx0YmVoaW5kIGRvbWFpbiAlaS4l
aSAoc2NvcmU9ICVpKVxuIiwNCi0gICAgICAgICAgICAgIGN1cmluZi0+dmNwdS0+ZG9tYWluLT5k
b21haW5faWQsDQotICAgICAgICAgICAgICBjdXJpbmYtPnZjcHUtPnZjcHVfaWQsIGN1cmluZi0+
c2NvcmVbaV0pOw0KICAgICB9DQogDQotICAgIC8qIGN1ciBub3cgY29udGFpbnMgdGhlIGVsZW1l
bnQsIGJlZm9yZSB3aGljaCB3ZSdsbCBlbnF1ZXVlLiAqLw0KLSAgICBQUklOVCgzLCAiXHRsaXN0
X2FkZCB0byAlcFxuIiwgY3VyLT5wcmV2KTsNCisgICAgLyogY3VyIG5vdyBjb250YWlucyB0aGUg
ZWxlbWVudCwgYmVmb3JlIHdoaWNoIHdlJ2xsIGVucXVldWUgKi8NCiAgICAgbGlzdF9hZGQoRVhU
UkFMSVNUKGQsaSksY3VyLT5wcmV2KTsNCiAgDQotICAgIC8qIENvbnRpbnVlIHVwZGF0aW5nIHRo
ZSBleHRyYXEuICovDQorICAgIC8qIENvbnRpbnVlIHVwZGF0aW5nIHRoZSBleHRyYXEgKi8NCiAg
ICAgaWYgKCAoY3VyICE9IEVYVFJBUShkLT5wcm9jZXNzb3IsaSkpICYmIHN1YiApDQogICAgIHsN
CiAgICAgICAgIGZvciAoIGN1ciA9IGN1ci0+bmV4dDsgY3VyICE9IEVYVFJBUShkLT5wcm9jZXNz
b3IsaSk7IGN1ciA9IGN1ci0+bmV4dCApDQogICAgICAgICB7DQogICAgICAgICAgICAgY3VyaW5m
ID0gbGlzdF9lbnRyeShjdXIsc3RydWN0IHNlZGZfdmNwdV9pbmZvLCBleHRyYWxpc3RbaV0pOw0K
ICAgICAgICAgICAgIGN1cmluZi0+c2NvcmVbaV0gLT0gc3ViOw0KLSAgICAgICAgICAgIFBSSU5U
KDQsICJcdHVwZGF0aW5nIGRvbWFpbiAlaS4laSAoc2NvcmU9ICV1KVxuIiwNCi0gICAgICAgICAg
ICAgICAgICBjdXJpbmYtPnZjcHUtPmRvbWFpbi0+ZG9tYWluX2lkLCANCi0gICAgICAgICAgICAg
ICAgICBjdXJpbmYtPnZjcHUtPnZjcHVfaWQsIGN1cmluZi0+c2NvcmVbaV0pOw0KICAgICAgICAg
fQ0KICAgICB9DQogDQpAQCAtMjIxLDI5ICsxOTksMTQgQEAgc3RhdGljIGlubGluZSB2b2lkIGV4
dHJhcV9jaGVjayhzdHJ1Y3Qgdg0KIHsNCiAgICAgaWYgKCBleHRyYXFfb24oZCwgRVhUUkFfVVRJ
TF9RKSApDQogICAgIHsNCi0gICAgICAgIFBSSU5UKDIsIkRvbSAlaS4laSBpcyBvbiBMMSBleHRy
YVFcbiIsDQotICAgICAgICAgICAgICBkLT5kb21haW4tPmRvbWFpbl9pZCwgZC0+dmNwdV9pZCk7
DQotDQogICAgICAgICBpZiAoICEoRURPTV9JTkZPKGQpLT5zdGF0dXMgJiBFWFRSQV9BV0FSRSkg
JiYNCiAgICAgICAgICAgICAgIWV4dHJhX3J1bnMoRURPTV9JTkZPKGQpKSApDQotICAgICAgICB7
DQogICAgICAgICAgICAgZXh0cmFxX2RlbChkLCBFWFRSQV9VVElMX1EpOw0KLSAgICAgICAgICAg
IFBSSU5UKDIsIlJlbW92ZWQgZG9tICVpLiVpIGZyb20gTDEgZXh0cmFRXG4iLA0KLSAgICAgICAg
ICAgICAgICAgIGQtPmRvbWFpbi0+ZG9tYWluX2lkLCBkLT52Y3B1X2lkKTsNCi0gICAgICAgIH0N
CiAgICAgfQ0KICAgICBlbHNlDQogICAgIHsNCi0gICAgICAgIFBSSU5UKDIsICJEb20gJWkuJWkg
aXMgTk9UIG9uIEwxIGV4dHJhUVxuIiwNCi0gICAgICAgICAgICAgIGQtPmRvbWFpbi0+ZG9tYWlu
X2lkLA0KLSAgICAgICAgICAgICAgZC0+dmNwdV9pZCk7DQotDQogICAgICAgICBpZiAoIChFRE9N
X0lORk8oZCktPnN0YXR1cyAmIEVYVFJBX0FXQVJFKSAmJiBzZWRmX3J1bm5hYmxlKGQpICkNCi0g
ICAgICAgIHsNCiAgICAgICAgICAgICBleHRyYXFfYWRkX3NvcnRfdXBkYXRlKGQsIEVYVFJBX1VU
SUxfUSwgMCk7DQotICAgICAgICAgICAgUFJJTlQoMiwiQWRkZWQgZG9tICVpLiVpIHRvIEwxIGV4
dHJhUVxuIiwNCi0gICAgICAgICAgICAgICAgICBkLT5kb21haW4tPmRvbWFpbl9pZCwgZC0+dmNw
dV9pZCk7DQotICAgICAgICB9DQogICAgIH0NCiB9DQogDQpAQCAtMjUyLDcgKzIxNSw3IEBAIHN0
YXRpYyBpbmxpbmUgdm9pZCBleHRyYXFfY2hlY2tfYWRkX3VuYmwNCiAgICAgc3RydWN0IHNlZGZf
dmNwdV9pbmZvICppbmYgPSBFRE9NX0lORk8oZCk7DQogDQogICAgIGlmICggaW5mLT5zdGF0dXMg
JiBFWFRSQV9BV0FSRSApDQotICAgICAgICAvKiBQdXQgb24gdGhlIHdlaWdodGVkIGV4dHJhcSB3
aXRob3V0IHVwZGF0aW5nIGFueSBzY29yZXMuICovDQorICAgICAgICAvKiBQdXQgb24gdGhlIHdl
aWdodGVkIGV4dHJhcSB3aXRob3V0IHVwZGF0aW5nIGFueSBzY29yZXMgKi8NCiAgICAgICAgIGV4
dHJhcV9hZGRfc29ydF91cGRhdGUoZCwgRVhUUkFfVVRJTF9RLCAwKTsNCiB9DQogDQpAQCAtMjY1
LDggKzIyOCw2IEBAIHN0YXRpYyBpbmxpbmUgdm9pZCBfX2RlbF9mcm9tX3F1ZXVlKHN0cnUNCiB7
DQogICAgIHN0cnVjdCBsaXN0X2hlYWQgKmxpc3QgPSBMSVNUKGQpOw0KICAgICBBU1NFUlQoX190
YXNrX29uX3F1ZXVlKGQpKTsNCi0gICAgUFJJTlQoMywiUmVtb3ZpbmcgZG9tYWluICVpLiVpIChi
b3A9ICUiUFJJdTY0IikgZnJvbSBydW5xL3dhaXRxXG4iLA0KLSAgICAgICAgICBkLT5kb21haW4t
PmRvbWFpbl9pZCwgZC0+dmNwdV9pZCwgUEVSSU9EX0JFR0lOKEVET01fSU5GTyhkKSkpOw0KICAg
ICBsaXN0X2RlbChsaXN0KTsNCiAgICAgbGlzdC0+bmV4dCA9IE5VTEw7DQogICAgIEFTU0VSVCgh
X190YXNrX29uX3F1ZXVlKGQpKTsNCkBAIC0yNzksMTMgKzI0MCwxMiBAQCBzdGF0aWMgaW5saW5l
IHZvaWQgbGlzdF9pbnNlcnRfc29ydCgNCiB7DQogICAgIHN0cnVjdCBsaXN0X2hlYWQgICAgICpj
dXI7DQogDQotICAgIC8qIEl0ZXJhdGUgdGhyb3VnaCBhbGwgZWxlbWVudHMgdG8gZmluZCBvdXIg
ImhvbGUiLiAqLw0KKyAgICAvKiBJdGVyYXRlIHRocm91Z2ggYWxsIGVsZW1lbnRzIHRvIGZpbmQg
b3VyICJob2xlIiAqLw0KICAgICBsaXN0X2Zvcl9lYWNoKCBjdXIsIGxpc3QgKQ0KICAgICAgICAg
aWYgKCBjb21wKGVsZW1lbnQsIGN1cikgPCAwICkNCiAgICAgICAgICAgICBicmVhazsNCiANCi0g
ICAgLyogY3VyIG5vdyBjb250YWlucyB0aGUgZWxlbWVudCwgYmVmb3JlIHdoaWNoIHdlJ2xsIGVu
cXVldWUuICovDQotICAgIFBSSU5UKDMsIlx0bGlzdF9hZGQgdG8gJXBcbiIsY3VyLT5wcmV2KTsN
CisgICAgLyogY3VyIG5vdyBjb250YWlucyB0aGUgZWxlbWVudCwgYmVmb3JlIHdoaWNoIHdlJ2xs
IGVucXVldWUgKi8NCiAgICAgbGlzdF9hZGQoZWxlbWVudCwgY3VyLT5wcmV2KTsNCiB9DQogDQpA
QCAtMzAzLDMwICsyNjMsMjYgQEAgc3RhdGljIGludCBuYW1lIyNfY29tcChzdHJ1Y3QgbGlzdF9o
ZWFkKg0KICAgICAgICAgcmV0dXJuIDE7ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIFwNCiB9DQogDQotLyogYWRkcyBhIGRvbWFpbiB0byB0aGUg
cXVldWUgb2YgcHJvY2Vzc2VzIHdoaWNoIHdhaXQgZm9yIHRoZSBiZWdpbm5pbmcgb2YgdGhlDQot
ICAgbmV4dCBwZXJpb2Q7IHRoaXMgbGlzdCBpcyB0aGVyZWZvcmUgc29ydGV0IGJ5IHRoaXMgdGlt
ZSwgd2hpY2ggaXMgc2ltcGx5DQotICAgYWJzb2wuIGRlYWRsaW5lIC0gcGVyaW9kDQorLyogQWRk
cyBhIGRvbWFpbiB0byB0aGUgcXVldWUgb2YgcHJvY2Vzc2VzIHdoaWNoIHdhaXQgZm9yIHRoZSBi
ZWdpbm5pbmcgb2YgdGhlDQorICogbmV4dCBwZXJpb2Q7IHRoaXMgbGlzdCBpcyB0aGVyZWZvcmUg
c29ydGV0IGJ5IHRoaXMgdGltZSwgd2hpY2ggaXMgc2ltcGx5DQorICogYWJzb2wuIGRlYWRsaW5l
IC0gcGVyaW9kLg0KICAqLyANCiBET01BSU5fQ09NUEFSRVIod2FpdHEsIGxpc3QsIFBFUklPRF9C
RUdJTihkMSksIFBFUklPRF9CRUdJTihkMikpOw0KIHN0YXRpYyBpbmxpbmUgdm9pZCBfX2FkZF90
b193YWl0cXVldWVfc29ydChzdHJ1Y3QgdmNwdSAqdikNCiB7DQogICAgIEFTU0VSVCghX190YXNr
X29uX3F1ZXVlKHYpKTsNCi0gICAgUFJJTlQoMywiQWRkaW5nIGRvbWFpbiAlaS4laSAoYm9wPSAl
IlBSSXU2NCIpIHRvIHdhaXRxXG4iLA0KLSAgICAgICAgICB2LT5kb21haW4tPmRvbWFpbl9pZCwg
di0+dmNwdV9pZCwgUEVSSU9EX0JFR0lOKEVET01fSU5GTyh2KSkpOw0KICAgICBsaXN0X2luc2Vy
dF9zb3J0KFdBSVRRKHYtPnByb2Nlc3NvciksIExJU1QodiksIHdhaXRxX2NvbXApOw0KICAgICBB
U1NFUlQoX190YXNrX29uX3F1ZXVlKHYpKTsNCiB9DQogDQotLyogYWRkcyBhIGRvbWFpbiB0byB0
aGUgcXVldWUgb2YgcHJvY2Vzc2VzIHdoaWNoIGhhdmUgc3RhcnRlZCB0aGVpciBjdXJyZW50DQot
ICAgcGVyaW9kIGFuZCBhcmUgcnVubmFibGUgKGkuZS4gbm90IGJsb2NrZWQsIGRpZWluZywuLi4p
LiBUaGUgZmlyc3QgZWxlbWVudA0KLSAgIG9uIHRoaXMgbGlzdCBpcyBydW5uaW5nIG9uIHRoZSBw
cm9jZXNzb3IsIGlmIHRoZSBsaXN0IGlzIGVtcHR5IHRoZSBpZGxlDQotICAgdGFzayB3aWxsIHJ1
bi4gQXMgd2UgYXJlIGltcGxlbWVudGluZyBFREYsIHRoaXMgbGlzdCBpcyBzb3J0ZWQgYnkgZGVh
ZGxpbmVzLg0KKy8qIEFkZHMgYSBkb21haW4gdG8gdGhlIHF1ZXVlIG9mIHByb2Nlc3NlcyB3aGlj
aCBoYXZlIHN0YXJ0ZWQgdGhlaXIgY3VycmVudA0KKyAqIHBlcmlvZCBhbmQgYXJlIHJ1bm5hYmxl
IChpLmUuIG5vdCBibG9ja2VkLCBkaWVpbmcsLi4uKS4gVGhlIGZpcnN0IGVsZW1lbnQNCisgKiBv
biB0aGlzIGxpc3QgaXMgcnVubmluZyBvbiB0aGUgcHJvY2Vzc29yLCBpZiB0aGUgbGlzdCBpcyBl
bXB0eSB0aGUgaWRsZQ0KKyAqIHRhc2sgd2lsbCBydW4uIEFzIHdlIGFyZSBpbXBsZW1lbnRpbmcg
RURGLCB0aGlzIGxpc3QgaXMgc29ydGVkIGJ5IGRlYWRsaW5lcy4NCiAgKi8gDQogRE9NQUlOX0NP
TVBBUkVSKHJ1bnEsIGxpc3QsIGQxLT5kZWFkbF9hYnMsIGQyLT5kZWFkbF9hYnMpOw0KIHN0YXRp
YyBpbmxpbmUgdm9pZCBfX2FkZF90b19ydW5xdWV1ZV9zb3J0KHN0cnVjdCB2Y3B1ICp2KQ0KIHsN
Ci0gICAgUFJJTlQoMywiQWRkaW5nIGRvbWFpbiAlaS4laSAoZGVhZGw9ICUiUFJJdTY0IikgdG8g
cnVucVxuIiwNCi0gICAgICAgICAgdi0+ZG9tYWluLT5kb21haW5faWQsIHYtPnZjcHVfaWQsIEVE
T01fSU5GTyh2KS0+ZGVhZGxfYWJzKTsNCiAgICAgbGlzdF9pbnNlcnRfc29ydChSVU5RKHYtPnBy
b2Nlc3NvciksIExJU1QodiksIHJ1bnFfY29tcCk7DQogfQ0KIA0KQEAgLTQ0NSwyMiArNDAxLDIx
IEBAIHN0YXRpYyBpbnQgc2VkZl9waWNrX2NwdShjb25zdCBzdHJ1Y3Qgc2MNCiAgICAgcmV0dXJu
IGNwdW1hc2tfZmlyc3QoJm9ubGluZV9hZmZpbml0eSk7DQogfQ0KIA0KLS8qDQotICogSGFuZGxl
cyB0aGUgcmVzY2hlZHVsaW5nICYgYm9va2tlZXBpbmcgb2YgZG9tYWlucyBydW5uaW5nIGluIHRo
ZWlyDQorDQorLyogSGFuZGxlcyB0aGUgcmVzY2hlZHVsaW5nICYgYm9va2tlZXBpbmcgb2YgZG9t
YWlucyBydW5uaW5nIGluIHRoZWlyDQogICogZ3VhcmFudGVlZCB0aW1lc2xpY2UuDQogICovDQog
c3RhdGljIHZvaWQgZGVzY2hlZF9lZGZfZG9tKHNfdGltZV90IG5vdywgc3RydWN0IHZjcHUqIGQp
DQogew0KICAgICBzdHJ1Y3Qgc2VkZl92Y3B1X2luZm8qIGluZiA9IEVET01fSU5GTyhkKTsNCiAN
Ci0gICAgLyogQ3VycmVudCBkb21haW4gaXMgcnVubmluZyBpbiByZWFsIHRpbWUgbW9kZS4gKi8N
CisgICAgLyogQ3VycmVudCBkb21haW4gaXMgcnVubmluZyBpbiByZWFsIHRpbWUgbW9kZSAqLw0K
ICAgICBBU1NFUlQoX190YXNrX29uX3F1ZXVlKGQpKTsNCiANCi0gICAgLyogVXBkYXRlIHRoZSBk
b21haW4ncyBjcHV0aW1lLiAqLw0KKyAgICAvKiBVcGRhdGUgdGhlIGRvbWFpbidzIGNwdXRpbWUg
Ki8NCiAgICAgaW5mLT5jcHV0aW1lICs9IG5vdyAtIGluZi0+c2NoZWRfc3RhcnRfYWJzOw0KIA0K
LSAgICAvKg0KLSAgICAgKiBTY2hlZHVsaW5nIGRlY2lzaW9ucyB3aGljaCBkb24ndCByZW1vdmUg
dGhlIHJ1bm5pbmcgZG9tYWluIGZyb20gdGhlDQorICAgIC8qIFNjaGVkdWxpbmcgZGVjaXNpb25z
IHdoaWNoIGRvbid0IHJlbW92ZSB0aGUgcnVubmluZyBkb21haW4gZnJvbSB0aGUNCiAgICAgICog
cnVucS4gDQogICAgICAqLw0KICAgICBpZiAoIChpbmYtPmNwdXRpbWUgPCBpbmYtPnNsaWNlKSAm
JiBzZWRmX3J1bm5hYmxlKGQpICkNCkBAIC00NjgsOCArNDIzLDcgQEAgc3RhdGljIHZvaWQgZGVz
Y2hlZF9lZGZfZG9tKHNfdGltZV90IG5vdw0KICAgDQogICAgIF9fZGVsX2Zyb21fcXVldWUoZCk7
DQogICANCi0gICAgLyoNCi0gICAgICogTWFuYWdlIGJvb2trZWVwaW5nIChpLmUuIGNhbGN1bGF0
ZSBuZXh0IGRlYWRsaW5lLCBtZW1vcmlzZQ0KKyAgICAvKiBNYW5hZ2UgYm9va2tlZXBpbmcgKGku
ZS4gY2FsY3VsYXRlIG5leHQgZGVhZGxpbmUsIG1lbW9yaXNlDQogICAgICAqIG92ZXJydW4tdGlt
ZSBvZiBzbGljZSkgb2YgZmluaXNoZWQgZG9tYWlucy4NCiAgICAgICovDQogICAgIGlmICggaW5m
LT5jcHV0aW1lID49IGluZi0+c2xpY2UgKQ0KQEAgLTQ3OCwzMCArNDMyLDMwIEBAIHN0YXRpYyB2
b2lkIGRlc2NoZWRfZWRmX2RvbShzX3RpbWVfdCBub3cNCiAgIA0KICAgICAgICAgaWYgKCBpbmYt
PnBlcmlvZCA8IGluZi0+cGVyaW9kX29yaWcgKQ0KICAgICAgICAgew0KLSAgICAgICAgICAgIC8q
IFRoaXMgZG9tYWluIHJ1bnMgaW4gbGF0ZW5jeSBzY2FsaW5nIG9yIGJ1cnN0IG1vZGUuICovDQor
ICAgICAgICAgICAgLyogVGhpcyBkb21haW4gcnVucyBpbiBsYXRlbmN5IHNjYWxpbmcgb3IgYnVy
c3QgbW9kZSAqLw0KICAgICAgICAgICAgIGluZi0+cGVyaW9kICo9IDI7DQogICAgICAgICAgICAg
aW5mLT5zbGljZSAgKj0gMjsNCiAgICAgICAgICAgICBpZiAoIChpbmYtPnBlcmlvZCA+IGluZi0+
cGVyaW9kX29yaWcpIHx8DQogICAgICAgICAgICAgICAgICAoaW5mLT5zbGljZSA+IGluZi0+c2xp
Y2Vfb3JpZykgKQ0KICAgICAgICAgICAgIHsNCi0gICAgICAgICAgICAgICAgLyogUmVzZXQgc2xp
Y2UgYW5kIHBlcmlvZC4gKi8NCisgICAgICAgICAgICAgICAgLyogUmVzZXQgc2xpY2UgYW5kIHBl
cmlvZCAqLw0KICAgICAgICAgICAgICAgICBpbmYtPnBlcmlvZCA9IGluZi0+cGVyaW9kX29yaWc7
DQogICAgICAgICAgICAgICAgIGluZi0+c2xpY2UgPSBpbmYtPnNsaWNlX29yaWc7DQogICAgICAg
ICAgICAgfQ0KICAgICAgICAgfQ0KIA0KLSAgICAgICAgLyogU2V0IG5leHQgZGVhZGxpbmUuICov
DQorICAgICAgICAvKiBTZXQgbmV4dCBkZWFkbGluZSAqLw0KICAgICAgICAgaW5mLT5kZWFkbF9h
YnMgKz0gaW5mLT5wZXJpb2Q7DQogICAgIH0NCiAgDQotICAgIC8qIEFkZCBhIHJ1bm5hYmxlIGRv
bWFpbiB0byB0aGUgd2FpdHF1ZXVlLiAqLw0KKyAgICAvKiBBZGQgYSBydW5uYWJsZSBkb21haW4g
dG8gdGhlIHdhaXRxdWV1ZSAqLw0KICAgICBpZiAoIHNlZGZfcnVubmFibGUoZCkgKQ0KICAgICB7
DQogICAgICAgICBfX2FkZF90b193YWl0cXVldWVfc29ydChkKTsNCiAgICAgfQ0KICAgICBlbHNl
DQogICAgIHsNCi0gICAgICAgIC8qIFdlIGhhdmUgYSBibG9ja2VkIHJlYWx0aW1lIHRhc2sgLT4g
cmVtb3ZlIGl0IGZyb20gZXhxcyB0b28uICovDQorICAgICAgICAvKiBXZSBoYXZlIGEgYmxvY2tl
ZCByZWFsdGltZSB0YXNrIC0+IHJlbW92ZSBpdCBmcm9tIGV4cXMgdG9vICovDQogICAgICAgICBp
ZiAoIGV4dHJhcV9vbihkLCBFWFRSQV9QRU5fUSkgKQ0KICAgICAgICAgICAgIGV4dHJhcV9kZWwo
ZCwgRVhUUkFfUEVOX1EpOw0KICAgICAgICAgaWYgKCBleHRyYXFfb24oZCwgRVhUUkFfVVRJTF9R
KSApDQpAQCAtNTIxLDczICs0NzUsNTkgQEAgc3RhdGljIHZvaWQgdXBkYXRlX3F1ZXVlcygNCiAg
ICAgc3RydWN0IGxpc3RfaGVhZCAgICAgKmN1ciwgKnRtcDsNCiAgICAgc3RydWN0IHNlZGZfdmNw
dV9pbmZvICpjdXJpbmY7DQogIA0KLSAgICBQUklOVCgzLCJVcGRhdGluZyB3YWl0cS4uXG4iKTsN
Ci0NCi0gICAgLyoNCi0gICAgICogQ2hlY2sgZm9yIHRoZSBmaXJzdCBlbGVtZW50cyBvZiB0aGUg
d2FpdHF1ZXVlLCB3aGV0aGVyIHRoZWlyDQorICAgIC8qIENoZWNrIGZvciB0aGUgZmlyc3QgZWxl
bWVudHMgb2YgdGhlIHdhaXRxdWV1ZSwgd2hldGhlciB0aGVpcg0KICAgICAgKiBuZXh0IHBlcmlv
ZCBoYXMgYWxyZWFkeSBzdGFydGVkLg0KICAgICAgKi8NCiAgICAgbGlzdF9mb3JfZWFjaF9zYWZl
ICggY3VyLCB0bXAsIHdhaXRxICkNCiAgICAgew0KICAgICAgICAgY3VyaW5mID0gbGlzdF9lbnRy
eShjdXIsIHN0cnVjdCBzZWRmX3ZjcHVfaW5mbywgbGlzdCk7DQotICAgICAgICBQUklOVCg0LCJc
dExvb2tpbmcgQCBkb20gJWkuJWlcbiIsDQotICAgICAgICAgICAgICBjdXJpbmYtPnZjcHUtPmRv
bWFpbi0+ZG9tYWluX2lkLCBjdXJpbmYtPnZjcHUtPnZjcHVfaWQpOw0KICAgICAgICAgaWYgKCBQ
RVJJT0RfQkVHSU4oY3VyaW5mKSA+IG5vdyApDQogICAgICAgICAgICAgYnJlYWs7DQogICAgICAg
ICBfX2RlbF9mcm9tX3F1ZXVlKGN1cmluZi0+dmNwdSk7DQogICAgICAgICBfX2FkZF90b19ydW5x
dWV1ZV9zb3J0KGN1cmluZi0+dmNwdSk7DQogICAgIH0NCiAgDQotICAgIFBSSU5UKDMsIlVwZGF0
aW5nIHJ1bnEuLlxuIik7DQotDQotICAgIC8qIFByb2Nlc3MgdGhlIHJ1bnEsIGZpbmQgZG9tYWlu
cyB0aGF0IGFyZSBvbiB0aGUgcnVucSB0aGF0IHNob3VsZG4ndC4gKi8NCisgICAgLyogUHJvY2Vz
cyB0aGUgcnVucSwgZmluZCBkb21haW5zIHRoYXQgYXJlIG9uIHRoZSBydW5xIHRoYXQgc2hvdWxk
bid0ICovDQogICAgIGxpc3RfZm9yX2VhY2hfc2FmZSAoIGN1ciwgdG1wLCBydW5xICkNCiAgICAg
ew0KICAgICAgICAgY3VyaW5mID0gbGlzdF9lbnRyeShjdXIsc3RydWN0IHNlZGZfdmNwdV9pbmZv
LGxpc3QpOw0KLSAgICAgICAgUFJJTlQoNCwiXHRMb29raW5nIEAgZG9tICVpLiVpXG4iLA0KLSAg
ICAgICAgICAgICAgY3VyaW5mLT52Y3B1LT5kb21haW4tPmRvbWFpbl9pZCwgY3VyaW5mLT52Y3B1
LT52Y3B1X2lkKTsNCiANCiAgICAgICAgIGlmICggdW5saWtlbHkoY3VyaW5mLT5zbGljZSA9PSAw
KSApDQogICAgICAgICB7DQotICAgICAgICAgICAgLyogSWdub3JlIGRvbWFpbnMgd2l0aCBlbXB0
eSBzbGljZS4gKi8NCi0gICAgICAgICAgICBQUklOVCg0LCJcdFVwZGF0aW5nIHplcm8tc2xpY2Ug
ZG9tYWluICVpLiVpXG4iLA0KLSAgICAgICAgICAgICAgICAgIGN1cmluZi0+dmNwdS0+ZG9tYWlu
LT5kb21haW5faWQsDQotICAgICAgICAgICAgICAgICAgY3VyaW5mLT52Y3B1LT52Y3B1X2lkKTsN
CisgICAgICAgICAgICAvKiBJZ25vcmUgZG9tYWlucyB3aXRoIGVtcHR5IHNsaWNlICovDQogICAg
ICAgICAgICAgX19kZWxfZnJvbV9xdWV1ZShjdXJpbmYtPnZjcHUpOw0KIA0KLSAgICAgICAgICAg
IC8qIE1vdmUgdGhlbSB0byB0aGVpciBuZXh0IHBlcmlvZC4gKi8NCisgICAgICAgICAgICAvKiBN
b3ZlIHRoZW0gdG8gdGhlaXIgbmV4dCBwZXJpb2QgKi8NCiAgICAgICAgICAgICBjdXJpbmYtPmRl
YWRsX2FicyArPSBjdXJpbmYtPnBlcmlvZDsNCiANCi0gICAgICAgICAgICAvKiBFbnN1cmUgdGhh
dCB0aGUgc3RhcnQgb2YgdGhlIG5leHQgcGVyaW9kIGlzIGluIHRoZSBmdXR1cmUuICovDQorICAg
ICAgICAgICAgLyogRW5zdXJlIHRoYXQgdGhlIHN0YXJ0IG9mIHRoZSBuZXh0IHBlcmlvZCBpcyBp
biB0aGUgZnV0dXJlICovDQogICAgICAgICAgICAgaWYgKCB1bmxpa2VseShQRVJJT0RfQkVHSU4o
Y3VyaW5mKSA8IG5vdykgKQ0KICAgICAgICAgICAgICAgICBjdXJpbmYtPmRlYWRsX2FicyArPSAN
CiAgICAgICAgICAgICAgICAgICAgIChESVZfVVAobm93IC0gUEVSSU9EX0JFR0lOKGN1cmluZiks
DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgIGN1cmluZi0+cGVyaW9kKSkgKiBjdXJpbmYt
PnBlcmlvZDsNCiANCi0gICAgICAgICAgICAvKiBQdXQgdGhlbSBiYWNrIGludG8gdGhlIHF1ZXVl
LiAqLw0KKyAgICAgICAgICAgIC8qIFB1dCB0aGVtIGJhY2sgaW50byB0aGUgcXVldWUgKi8NCiAg
ICAgICAgICAgICBfX2FkZF90b193YWl0cXVldWVfc29ydChjdXJpbmYtPnZjcHUpOw0KICAgICAg
ICAgfQ0KICAgICAgICAgZWxzZSBpZiAoIHVubGlrZWx5KChjdXJpbmYtPmRlYWRsX2FicyA8IG5v
dykgfHwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAoY3VyaW5mLT5jcHV0aW1lID4gY3Vy
aW5mLT5zbGljZSkpICkNCiAgICAgICAgIHsNCi0gICAgICAgICAgICAvKg0KLSAgICAgICAgICAg
ICAqIFdlIG1pc3NlZCB0aGUgZGVhZGxpbmUgb3IgdGhlIHNsaWNlIHdhcyBhbHJlYWR5IGZpbmlz
aGVkLg0KKyAgICAgICAgICAgIC8qIFdlIG1pc3NlZCB0aGUgZGVhZGxpbmUgb3IgdGhlIHNsaWNl
IHdhcyBhbHJlYWR5IGZpbmlzaGVkLg0KICAgICAgICAgICAgICAqIE1pZ2h0IGhhcGVuIGJlY2F1
c2Ugb2YgZG9tX2Fkai4NCiAgICAgICAgICAgICAgKi8NCi0gICAgICAgICAgICBQUklOVCg0LCJc
dERvbWFpbiAlaS4laSBleGNlZWRlZCBpdCdzIGRlYWRsaW5lLyINCi0gICAgICAgICAgICAgICAg
ICAic2xpY2UgKCUiUFJJdTY0IiAvICUiUFJJdTY0Iikgbm93OiAlIlBSSXU2NA0KLSAgICAgICAg
ICAgICAgICAgICIgY3B1dGltZTogJSJQUkl1NjQiXG4iLA0KLSAgICAgICAgICAgICAgICAgIGN1
cmluZi0+dmNwdS0+ZG9tYWluLT5kb21haW5faWQsDQotICAgICAgICAgICAgICAgICAgY3VyaW5m
LT52Y3B1LT52Y3B1X2lkLA0KLSAgICAgICAgICAgICAgICAgIGN1cmluZi0+ZGVhZGxfYWJzLCBj
dXJpbmYtPnNsaWNlLCBub3csDQotICAgICAgICAgICAgICAgICAgY3VyaW5mLT5jcHV0aW1lKTsN
CisgICAgICAgICAgICBwcmludGsoIlx0RG9tYWluICVpLiVpIGV4Y2VlZGVkIGl0J3MgZGVhZGxp
bmUvIg0KKyAgICAgICAgICAgICAgICAgICAic2xpY2UgKCUiUFJJdTY0IiAvICUiUFJJdTY0Iikg
bm93OiAlIlBSSXU2NA0KKyAgICAgICAgICAgICAgICAgICAiIGNwdXRpbWU6ICUiUFJJdTY0Ilxu
IiwNCisgICAgICAgICAgICAgICAgICAgY3VyaW5mLT52Y3B1LT5kb21haW4tPmRvbWFpbl9pZCwN
CisgICAgICAgICAgICAgICAgICAgY3VyaW5mLT52Y3B1LT52Y3B1X2lkLA0KKyAgICAgICAgICAg
ICAgICAgICBjdXJpbmYtPmRlYWRsX2FicywgY3VyaW5mLT5zbGljZSwgbm93LA0KKyAgICAgICAg
ICAgICAgICAgICBjdXJpbmYtPmNwdXRpbWUpOw0KICAgICAgICAgICAgIF9fZGVsX2Zyb21fcXVl
dWUoY3VyaW5mLT52Y3B1KTsNCiANCi0gICAgICAgICAgICAvKiBDb21tb24gY2FzZTogd2UgbWlz
cyBvbmUgcGVyaW9kLiAqLw0KKyAgICAgICAgICAgIC8qIENvbW1vbiBjYXNlOiB3ZSBtaXNzIG9u
ZSBwZXJpb2QgKi8NCiAgICAgICAgICAgICBjdXJpbmYtPmRlYWRsX2FicyArPSBjdXJpbmYtPnBl
cmlvZDsNCiAgICANCi0gICAgICAgICAgICAvKg0KLSAgICAgICAgICAgICAqIElmIHdlIGFyZSBz
dGlsbCBiZWhpbmQ6IG1vZHVsbyBhcml0aG1ldGljLCBmb3JjZSBkZWFkbGluZQ0KKyAgICAgICAg
ICAgIC8qIElmIHdlIGFyZSBzdGlsbCBiZWhpbmQ6IG1vZHVsbyBhcml0aG1ldGljLCBmb3JjZSBk
ZWFkbGluZQ0KICAgICAgICAgICAgICAqIHRvIGJlIGluIGZ1dHVyZSBhbmQgYWxpZ25lZCB0byBw
ZXJpb2QgYm9yZGVycy4NCiAgICAgICAgICAgICAgKi8NCiAgICAgICAgICAgICBpZiAoIHVubGlr
ZWx5KGN1cmluZi0+ZGVhZGxfYWJzIDwgbm93KSApDQpAQCAtNTk2LDcgKzUzNiw3IEBAIHN0YXRp
YyB2b2lkIHVwZGF0ZV9xdWV1ZXMoDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgY3VyaW5m
LT5wZXJpb2QpICogY3VyaW5mLT5wZXJpb2Q7DQogICAgICAgICAgICAgQVNTRVJUKGN1cmluZi0+
ZGVhZGxfYWJzID49IG5vdyk7DQogDQotICAgICAgICAgICAgLyogR2l2ZSBhIGZyZXNoIHNsaWNl
LiAqLw0KKyAgICAgICAgICAgIC8qIEdpdmUgYSBmcmVzaCBzbGljZSAqLw0KICAgICAgICAgICAg
IGN1cmluZi0+Y3B1dGltZSA9IDA7DQogICAgICAgICAgICAgaWYgKCBQRVJJT0RfQkVHSU4oY3Vy
aW5mKSA+IG5vdyApDQogICAgICAgICAgICAgICAgIF9fYWRkX3RvX3dhaXRxdWV1ZV9zb3J0KGN1
cmluZi0+dmNwdSk7DQpAQCAtNjA2LDE3ICs1NDYsMTYgQEAgc3RhdGljIHZvaWQgdXBkYXRlX3F1
ZXVlcygNCiAgICAgICAgIGVsc2UNCiAgICAgICAgICAgICBicmVhazsNCiAgICAgfQ0KLQ0KLSAg
ICBQUklOVCgzLCJkb25lIHVwZGF0aW5nIHRoZSBxdWV1ZXNcbiIpOw0KIH0NCiANCiANCiAvKiBy
ZW1vdmVzIGEgZG9tYWluIGZyb20gdGhlIGhlYWQgb2YgdGhlIGFjY29yZGluZyBleHRyYVEgYW5k
DQotICAgcmVxdWV1ZXMgaXQgYXQgYSBzcGVjaWZpZWQgcG9zaXRpb246DQotICAgICByb3VuZC1y
b2JpbiBleHRyYXRpbWU6IGVuZCBvZiBleHRyYVENCi0gICAgIHdlaWdodGVkIGV4dC46IGluc2Vy
dCBpbiBzb3J0ZWQgbGlzdCBieSBzY29yZQ0KLSAgIGlmIHRoZSBkb21haW4gaXMgYmxvY2tlZCAv
IGhhcyByZWdhaW5lZCBpdHMgc2hvcnQtYmxvY2stbG9zcw0KLSAgIHRpbWUgaXQgaXMgbm90IHB1
dCBvbiBhbnkgcXVldWUgKi8NCisgKiByZXF1ZXVlcyBpdCBhdCBhIHNwZWNpZmllZCBwb3NpdGlv
bjoNCisgKiAgIHJvdW5kLXJvYmluIGV4dHJhdGltZTogZW5kIG9mIGV4dHJhUQ0KKyAqICAgd2Vp
Z2h0ZWQgZXh0LjogaW5zZXJ0IGluIHNvcnRlZCBsaXN0IGJ5IHNjb3JlDQorICogaWYgdGhlIGRv
bWFpbiBpcyBibG9ja2VkIC8gaGFzIHJlZ2FpbmVkIGl0cyBzaG9ydC1ibG9jay1sb3NzDQorICog
dGltZSBpdCBpcyBub3QgcHV0IG9uIGFueSBxdWV1ZS4NCisgKi8NCiBzdGF0aWMgdm9pZCBkZXNj
aGVkX2V4dHJhX2RvbShzX3RpbWVfdCBub3csIHN0cnVjdCB2Y3B1ICpkKQ0KIHsNCiAgICAgc3Ry
dWN0IHNlZGZfdmNwdV9pbmZvICppbmYgPSBFRE9NX0lORk8oZCk7DQpAQCAtNjI1LDI5ICs1NjQs
MjUgQEAgc3RhdGljIHZvaWQgZGVzY2hlZF9leHRyYV9kb20oc190aW1lX3Qgbg0KIA0KICAgICBB
U1NFUlQoZXh0cmFxX29uKGQsIGkpKTsNCiANCi0gICAgLyogVW5zZXQgYWxsIHJ1bm5pbmcgZmxh
Z3MuICovDQorICAgIC8qIFVuc2V0IGFsbCBydW5uaW5nIGZsYWdzICovDQogICAgIGluZi0+c3Rh
dHVzICAmPSB+KEVYVFJBX1JVTl9QRU4gfCBFWFRSQV9SVU5fVVRJTCk7DQotICAgIC8qIEZyZXNo
IHNsaWNlIGZvciB0aGUgbmV4dCBydW4uICovDQorICAgIC8qIEZyZXNoIHNsaWNlIGZvciB0aGUg
bmV4dCBydW4gKi8NCiAgICAgaW5mLT5jcHV0aW1lID0gMDsNCi0gICAgLyogQWNjdW11bGF0ZSB0
b3RhbCBleHRyYXRpbWUuICovDQorICAgIC8qIEFjY3VtdWxhdGUgdG90YWwgZXh0cmF0aW1lICov
DQogICAgIGluZi0+ZXh0cmFfdGltZV90b3QgKz0gbm93IC0gaW5mLT5zY2hlZF9zdGFydF9hYnM7
DQogICAgIC8qIFJlbW92ZSBleHRyYWRvbWFpbiBmcm9tIGhlYWQgb2YgdGhlIHF1ZXVlLiAqLw0K
ICAgICBleHRyYXFfZGVsKGQsIGkpOw0KIA0KLSAgICAvKiBVcGRhdGUgdGhlIHNjb3JlLiAqLw0K
KyAgICAvKiBVcGRhdGUgdGhlIHNjb3JlICovDQogICAgIG9sZHNjb3JlID0gaW5mLT5zY29yZVtp
XTsNCiAgICAgaWYgKCBpID09IEVYVFJBX1BFTl9RICkNCiAgICAgew0KLSAgICAgICAgLypkb21h
aW4gd2FzIHJ1bm5pbmcgaW4gTDAgZXh0cmFxKi8NCi0gICAgICAgIC8qcmVkdWNlIGJsb2NrIGxv
c3QsIHByb2JhYmx5IG1vcmUgc29waGlzdGljYXRpb24gaGVyZSEqLw0KKyAgICAgICAgLyogRG9t
YWluIHdhcyBydW5uaW5nIGluIEwwIGV4dHJhcSAqLw0KKyAgICAgICAgLyogcmVkdWNlIGJsb2Nr
IGxvc3QsIHByb2JhYmx5IG1vcmUgc29waGlzdGljYXRpb24gaGVyZSEqLw0KICAgICAgICAgLypp
bmYtPnNob3J0X2Jsb2NrX2xvc3RfdG90IC09IEVYVFJBX1FVQU5UVU07Ki8NCiAgICAgICAgIGlu
Zi0+c2hvcnRfYmxvY2tfbG9zdF90b3QgLT0gbm93IC0gaW5mLT5zY2hlZF9zdGFydF9hYnM7DQot
ICAgICAgICBQUklOVCgzLCJEb21haW4gJWkuJWk6IFNob3J0X2Jsb2NrX2xvc3M6ICUiUFJJaTY0
IlxuIiwgDQotICAgICAgICAgICAgICBpbmYtPnZjcHUtPmRvbWFpbi0+ZG9tYWluX2lkLCBpbmYt
PnZjcHUtPnZjcHVfaWQsDQotICAgICAgICAgICAgICBpbmYtPnNob3J0X2Jsb2NrX2xvc3RfdG90
KTsNCiAjaWYgMA0KLSAgICAgICAgLyoNCi0gICAgICAgICAqIEtBRjogSWYgd2UgZG9uJ3QgZXhp
dCBzaG9ydC1ibG9ja2luZyBzdGF0ZSBhdCB0aGlzIHBvaW50DQorICAgICAgICAvKiBLQUY6IElm
IHdlIGRvbid0IGV4aXQgc2hvcnQtYmxvY2tpbmcgc3RhdGUgYXQgdGhpcyBwb2ludA0KICAgICAg
ICAgICogZG9tYWluMCBjYW4gc3RlYWwgYWxsIENQVSBmb3IgdXAgdG8gMTAgc2Vjb25kcyBiZWZv
cmUNCiAgICAgICAgICAqIHNjaGVkdWxpbmcgc2V0dGxlcyBkb3duICh3aGVuIGNvbXBldGluZyBh
Z2FpbnN0IGFub3RoZXINCiAgICAgICAgICAqIENQVS1ib3VuZCBkb21haW4pLiBEb2luZyB0aGlz
IHNlZW1zIHRvIG1ha2UgdGhpbmdzIGJlaGF2ZQ0KQEAgLTY1Niw1MSArNTkxLDU2IEBAIHN0YXRp
YyB2b2lkIGRlc2NoZWRfZXh0cmFfZG9tKHNfdGltZV90IG4NCiAgICAgICAgIGlmICggaW5mLT5z
aG9ydF9ibG9ja19sb3N0X3RvdCA8PSAwICkNCiAjZW5kaWYNCiAgICAgICAgIHsNCi0gICAgICAg
ICAgICBQUklOVCg0LCJEb21haW4gJWkuJWkgY29tcGVuc2F0ZWQgc2hvcnQgYmxvY2sgbG9zcyFc
biIsDQotICAgICAgICAgICAgICAgICAgaW5mLT52Y3B1LT5kb21haW4tPmRvbWFpbl9pZCwgaW5m
LT52Y3B1LT52Y3B1X2lkKTsNCi0gICAgICAgICAgICAvKndlIGhhdmUgKG92ZXItKWNvbXBlbnNh
dGVkIG91ciBibG9jayBwZW5hbHR5Ki8NCisgICAgICAgICAgICAvKiBXZSBoYXZlIChvdmVyLSlj
b21wZW5zYXRlZCBvdXIgYmxvY2sgcGVuYWx0eSAqLw0KICAgICAgICAgICAgIGluZi0+c2hvcnRf
YmxvY2tfbG9zdF90b3QgPSAwOw0KLSAgICAgICAgICAgIC8qd2UgZG9uJ3Qgd2FudCBhIHBsYWNl
IG9uIHRoZSBwZW5hbHR5IHF1ZXVlIGFueW1vcmUhKi8NCisgICAgICAgICAgICAvKiBXZSBkb24n
dCB3YW50IGEgcGxhY2Ugb24gdGhlIHBlbmFsdHkgcXVldWUgYW55bW9yZSEgKi8NCiAgICAgICAg
ICAgICBpbmYtPnN0YXR1cyAmPSB+RVhUUkFfV0FOVF9QRU5fUTsNCiAgICAgICAgICAgICBnb3Rv
IGNoZWNrX2V4dHJhX3F1ZXVlczsNCiAgICAgICAgIH0NCiANCi0gICAgICAgIC8qd2UgaGF2ZSB0
byBnbyBhZ2FpbiBmb3IgYW5vdGhlciB0cnkgaW4gdGhlIGJsb2NrLWV4dHJhcSwNCi0gICAgICAg
ICAgdGhlIHNjb3JlIGlzIG5vdCB1c2VkIGluY3JlbWFudGFsbHkgaGVyZSwgYXMgdGhpcyBpcw0K
LSAgICAgICAgICBhbHJlYWR5IGRvbmUgYnkgcmVjYWxjdWxhdGluZyB0aGUgYmxvY2tfbG9zdCov
DQorICAgICAgICAvKiBXZSBoYXZlIHRvIGdvIGFnYWluIGZvciBhbm90aGVyIHRyeSBpbiB0aGUg
YmxvY2stZXh0cmFxLA0KKyAgICAgICAgICogdGhlIHNjb3JlIGlzIG5vdCB1c2VkIGluY3JlbWFu
dGFsbHkgaGVyZSwgYXMgdGhpcyBpcw0KKyAgICAgICAgICogYWxyZWFkeSBkb25lIGJ5IHJlY2Fs
Y3VsYXRpbmcgdGhlIGJsb2NrX2xvc3QNCisgICAgICAgICAqLw0KICAgICAgICAgaW5mLT5zY29y
ZVtFWFRSQV9QRU5fUV0gPSAoaW5mLT5wZXJpb2QgPDwgMTApIC8NCiAgICAgICAgICAgICBpbmYt
PnNob3J0X2Jsb2NrX2xvc3RfdG90Ow0KICAgICAgICAgb2xkc2NvcmUgPSAwOw0KICAgICB9DQog
ICAgIGVsc2UNCiAgICAgew0KLSAgICAgICAgLypkb21haW4gd2FzIHJ1bm5pbmcgaW4gTDEgZXh0
cmFxID0+IHNjb3JlIGlzIGludmVyc2Ugb2YNCi0gICAgICAgICAgdXRpbGl6YXRpb24gYW5kIGlz
IHVzZWQgc29tZXdoYXQgaW5jcmVtZW50YWwhKi8NCisgICAgICAgIC8qIERvbWFpbiB3YXMgcnVu
bmluZyBpbiBMMSBleHRyYXEgPT4gc2NvcmUgaXMgaW52ZXJzZSBvZg0KKyAgICAgICAgICogdXRp
bGl6YXRpb24gYW5kIGlzIHVzZWQgc29tZXdoYXQgaW5jcmVtZW50YWwhDQorICAgICAgICAgKi8N
CiAgICAgICAgIGlmICggIWluZi0+ZXh0cmF3ZWlnaHQgKQ0KLSAgICAgICAgICAgIC8qTkI6IHVz
ZSBmaXhlZCBwb2ludCBhcml0aG1ldGljIHdpdGggMTAgYml0cyovDQorICAgICAgICB7DQorICAg
ICAgICAgICAgLyogTkI6IHVzZSBmaXhlZCBwb2ludCBhcml0aG1ldGljIHdpdGggMTAgYml0cyAq
Lw0KICAgICAgICAgICAgIGluZi0+c2NvcmVbRVhUUkFfVVRJTF9RXSA9IChpbmYtPnBlcmlvZCA8
PCAxMCkgLw0KICAgICAgICAgICAgICAgICBpbmYtPnNsaWNlOw0KKyAgICAgICAgfQ0KICAgICAg
ICAgZWxzZQ0KLSAgICAgICAgICAgIC8qY29udmVyc2lvbiBiZXR3ZWVuIHJlYWx0aW1lIHV0aWxp
c2F0aW9uIGFuZCBleHRyYXdpZWdodDoNCi0gICAgICAgICAgICAgIGZ1bGwgKGllIDEwMCUpIHV0
aWxpemF0aW9uIGlzIGVxdWl2YWxlbnQgdG8gMTI4IGV4dHJhd2VpZ2h0Ki8NCisgICAgICAgIHsN
CisgICAgICAgICAgICAvKiBDb252ZXJzaW9uIGJldHdlZW4gcmVhbHRpbWUgdXRpbGlzYXRpb24g
YW5kIGV4dHJhd2llZ2h0Og0KKyAgICAgICAgICAgICAqIGZ1bGwgKGllIDEwMCUpIHV0aWxpemF0
aW9uIGlzIGVxdWl2YWxlbnQgdG8gMTI4IGV4dHJhd2VpZ2h0DQorICAgICAgICAgICAgICovDQog
ICAgICAgICAgICAgaW5mLT5zY29yZVtFWFRSQV9VVElMX1FdID0gKDE8PDE3KSAvIGluZi0+ZXh0
cmF3ZWlnaHQ7DQorICAgICAgICB9DQogICAgIH0NCiANCiAgY2hlY2tfZXh0cmFfcXVldWVzOg0K
LSAgICAvKiBBZGRpbmcgYSBydW5uYWJsZSBkb21haW4gdG8gdGhlIHJpZ2h0IHF1ZXVlIGFuZCBy
ZW1vdmluZyBibG9ja2VkIG9uZXMqLw0KKyAgICAvKiBBZGRpbmcgYSBydW5uYWJsZSBkb21haW4g
dG8gdGhlIHJpZ2h0IHF1ZXVlIGFuZCByZW1vdmluZyBibG9ja2VkIG9uZXMgKi8NCiAgICAgaWYg
KCBzZWRmX3J1bm5hYmxlKGQpICkNCiAgICAgew0KLSAgICAgICAgLyphZGQgYWNjb3JkaW5nIHRv
IHNjb3JlOiB3ZWlnaHRlZCByb3VuZCByb2JpbiovDQorICAgICAgICAvKiBBZGQgYWNjb3JkaW5n
IHRvIHNjb3JlOiB3ZWlnaHRlZCByb3VuZCByb2JpbiAqLw0KICAgICAgICAgaWYgKCgoaW5mLT5z
dGF0dXMgJiBFWFRSQV9BV0FSRSkgJiYgKGkgPT0gRVhUUkFfVVRJTF9RKSkgfHwNCiAgICAgICAg
ICAgICAoKGluZi0+c3RhdHVzICYgRVhUUkFfV0FOVF9QRU5fUSkgJiYgKGkgPT0gRVhUUkFfUEVO
X1EpKSkNCiAgICAgICAgICAgICBleHRyYXFfYWRkX3NvcnRfdXBkYXRlKGQsIGksIG9sZHNjb3Jl
KTsNCiAgICAgfQ0KICAgICBlbHNlDQogICAgIHsNCi0gICAgICAgIC8qcmVtb3ZlIHRoaXMgYmxv
Y2tlZCBkb21haW4gZnJvbSB0aGUgd2FpdHEhKi8NCisgICAgICAgIC8qIFJlbW92ZSB0aGlzIGJs
b2NrZWQgZG9tYWluIGZyb20gdGhlIHdhaXRxISAqLw0KICAgICAgICAgX19kZWxfZnJvbV9xdWV1
ZShkKTsNCi0gICAgICAgIC8qbWFrZSBzdXJlIHRoYXQgd2UgcmVtb3ZlIGEgYmxvY2tlZCBkb21h
aW4gZnJvbSB0aGUgb3RoZXINCi0gICAgICAgICAgZXh0cmFxIHRvbyovDQorICAgICAgICAvKiBN
YWtlIHN1cmUgdGhhdCB3ZSByZW1vdmUgYSBibG9ja2VkIGRvbWFpbiBmcm9tIHRoZSBvdGhlcg0K
KyAgICAgICAgICogZXh0cmFxIHRvby4gKi8NCiAgICAgICAgIGlmICggaSA9PSBFWFRSQV9QRU5f
USApDQogICAgICAgICB7DQogICAgICAgICAgICAgaWYgKCBleHRyYXFfb24oZCwgRVhUUkFfVVRJ
TF9RKSApDQpAQCAtNzMyLDggKzY3Miw5IEBAIHN0YXRpYyBzdHJ1Y3QgdGFza19zbGljZSBzZWRm
X2RvX2V4dHJhX3MNCiANCiAgICAgaWYgKCAhbGlzdF9lbXB0eShleHRyYXFbRVhUUkFfUEVOX1Fd
KSApDQogICAgIHsNCi0gICAgICAgIC8qd2Ugc3RpbGwgaGF2ZSBlbGVtZW50cyBvbiB0aGUgbGV2
ZWwgMCBleHRyYXEgDQotICAgICAgICAgID0+IGxldCB0aG9zZSBydW4gZmlyc3QhKi8NCisgICAg
ICAgIC8qIFdlIHN0aWxsIGhhdmUgZWxlbWVudHMgb24gdGhlIGxldmVsIDAgZXh0cmFxDQorICAg
ICAgICAgKiA9PiBsZXQgdGhvc2UgcnVuIGZpcnN0IQ0KKyAgICAgICAgICovDQogICAgICAgICBy
dW5pbmYgICA9IGxpc3RfZW50cnkoZXh0cmFxW0VYVFJBX1BFTl9RXS0+bmV4dCwgDQogICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgc3RydWN0IHNlZGZfdmNwdV9pbmZvLCBleHRyYWxpc3Rb
RVhUUkFfUEVOX1FdKTsNCiAgICAgICAgIHJ1bmluZi0+c3RhdHVzIHw9IEVYVFJBX1JVTl9QRU47
DQpAQCAtNzQ3LDcgKzY4OCw3IEBAIHN0YXRpYyBzdHJ1Y3QgdGFza19zbGljZSBzZWRmX2RvX2V4
dHJhX3MNCiAgICAgew0KICAgICAgICAgaWYgKCAhbGlzdF9lbXB0eShleHRyYXFbRVhUUkFfVVRJ
TF9RXSkgKQ0KICAgICAgICAgew0KLSAgICAgICAgICAgIC8qdXNlIGVsZW1lbnRzIGZyb20gdGhl
IG5vcm1hbCBleHRyYXF1ZXVlKi8NCisgICAgICAgICAgICAvKiBVc2UgZWxlbWVudHMgZnJvbSB0
aGUgbm9ybWFsIGV4dHJhcXVldWUgKi8NCiAgICAgICAgICAgICBydW5pbmYgICA9IGxpc3RfZW50
cnkoZXh0cmFxW0VYVFJBX1VUSUxfUV0tPm5leHQsDQogICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgIHN0cnVjdCBzZWRmX3ZjcHVfaW5mbywNCiAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgZXh0cmFsaXN0W0VYVFJBX1VUSUxfUV0pOw0KQEAgLTc3MywxMCArNzE0LDEx
IEBAIHN0YXRpYyBzdHJ1Y3QgdGFza19zbGljZSBzZWRmX2RvX2V4dHJhX3MNCiANCiANCiAvKiBN
YWluIHNjaGVkdWxpbmcgZnVuY3Rpb24NCi0gICBSZWFzb25zIGZvciBjYWxsaW5nIHRoaXMgZnVu
Y3Rpb24gYXJlOg0KLSAgIC10aW1lc2xpY2UgZm9yIHRoZSBjdXJyZW50IHBlcmlvZCB1c2VkIHVw
DQotICAgLWRvbWFpbiBvbiB3YWl0cXVldWUgaGFzIHN0YXJ0ZWQgaXQncyBwZXJpb2QNCi0gICAt
YW5kIHZhcmlvdXMgb3RoZXJzIDspIGluIGdlbmVyYWw6IGRldGVybWluZSB3aGljaCBkb21haW4g
dG8gcnVuIG5leHQqLw0KKyAqIFJlYXNvbnMgZm9yIGNhbGxpbmcgdGhpcyBmdW5jdGlvbiBhcmU6
DQorICogLXRpbWVzbGljZSBmb3IgdGhlIGN1cnJlbnQgcGVyaW9kIHVzZWQgdXANCisgKiAtZG9t
YWluIG9uIHdhaXRxdWV1ZSBoYXMgc3RhcnRlZCBpdCdzIHBlcmlvZA0KKyAqIC1hbmQgdmFyaW91
cyBvdGhlcnMgOykgaW4gZ2VuZXJhbDogZGV0ZXJtaW5lIHdoaWNoIGRvbWFpbiB0byBydW4gbmV4
dA0KKyAqLw0KIHN0YXRpYyBzdHJ1Y3QgdGFza19zbGljZSBzZWRmX2RvX3NjaGVkdWxlKA0KICAg
ICBjb25zdCBzdHJ1Y3Qgc2NoZWR1bGVyICpvcHMsIHNfdGltZV90IG5vdywgYm9vbF90IHRhc2ts
ZXRfd29ya19zY2hlZHVsZWQpDQogew0KQEAgLTc4OSwxMyArNzMxLDE0IEBAIHN0YXRpYyBzdHJ1
Y3QgdGFza19zbGljZSBzZWRmX2RvX3NjaGVkdWwNCiAgICAgc3RydWN0IHNlZGZfdmNwdV9pbmZv
ICpydW5pbmYsICp3YWl0aW5mOw0KICAgICBzdHJ1Y3QgdGFza19zbGljZSAgICAgIHJldDsNCiAN
Ci0gICAgLyppZGxlIHRhc2tzIGRvbid0IG5lZWQgYW55IG9mIHRoZSBmb2xsb3dpbmcgc3R1Ziov
DQorICAgIC8qIElkbGUgdGFza3MgZG9uJ3QgbmVlZCBhbnkgb2YgdGhlIGZvbGxvd2luZyBzdHVm
ICovDQogICAgIGlmICggaXNfaWRsZV92Y3B1KGN1cnJlbnQpICkNCiAgICAgICAgIGdvdG8gY2hl
Y2tfd2FpdHE7DQogIA0KLSAgICAvKiBjcmVhdGUgbG9jYWwgc3RhdGUgb2YgdGhlIHN0YXR1cyBv
ZiB0aGUgZG9tYWluLCBpbiBvcmRlciB0byBhdm9pZA0KLSAgICAgICBpbmNvbnNpc3RlbnQgc3Rh
dGUgZHVyaW5nIHNjaGVkdWxpbmcgZGVjaXNpb25zLCBiZWNhdXNlIGRhdGEgZm9yDQotICAgICAg
IHZjcHVfcnVubmFibGUgaXMgbm90IHByb3RlY3RlZCBieSB0aGUgc2NoZWR1bGluZyBsb2NrISov
DQorICAgIC8qIENyZWF0ZSBsb2NhbCBzdGF0ZSBvZiB0aGUgc3RhdHVzIG9mIHRoZSBkb21haW4s
IGluIG9yZGVyIHRvIGF2b2lkDQorICAgICAqIGluY29uc2lzdGVudCBzdGF0ZSBkdXJpbmcgc2No
ZWR1bGluZyBkZWNpc2lvbnMsIGJlY2F1c2UgZGF0YSBmb3INCisgICAgICogdmNwdV9ydW5uYWJs
ZSBpcyBub3QgcHJvdGVjdGVkIGJ5IHRoZSBzY2hlZHVsaW5nIGxvY2shDQorICAgICAqLw0KICAg
ICBpZiAoICF2Y3B1X3J1bm5hYmxlKGN1cnJlbnQpICkNCiAgICAgICAgIGluZi0+c3RhdHVzIHw9
IFNFREZfQVNMRUVQOw0KICANCkBAIC04MDQsNyArNzQ3LDcgQEAgc3RhdGljIHN0cnVjdCB0YXNr
X3NsaWNlIHNlZGZfZG9fc2NoZWR1bA0KIA0KICAgICBpZiAoIHVubGlrZWx5KGV4dHJhX3J1bnMo
aW5mKSkgKQ0KICAgICB7DQotICAgICAgICAvKnNwZWNpYWwgdHJlYXRtZW50IG9mIGRvbWFpbnMg
cnVubmluZyBpbiBleHRyYSB0aW1lKi8NCisgICAgICAgIC8qIFNwZWNpYWwgdHJlYXRtZW50IG9m
IGRvbWFpbnMgcnVubmluZyBpbiBleHRyYSB0aW1lICovDQogICAgICAgICBkZXNjaGVkX2V4dHJh
X2RvbShub3csIGN1cnJlbnQpOw0KICAgICB9DQogICAgIGVsc2UgDQpAQCAtODE0LDEwICs3NTcs
MTEgQEAgc3RhdGljIHN0cnVjdCB0YXNrX3NsaWNlIHNlZGZfZG9fc2NoZWR1bA0KICBjaGVja193
YWl0cToNCiAgICAgdXBkYXRlX3F1ZXVlcyhub3csIHJ1bnEsIHdhaXRxKTsNCiANCi0gICAgLypu
b3cgc2ltcGx5IHBpY2sgdGhlIGZpcnN0IGRvbWFpbiBmcm9tIHRoZSBydW5xdWV1ZSwgd2hpY2gg
aGFzIHRoZQ0KLSAgICAgIGVhcmxpZXN0IGRlYWRsaW5lLCBiZWNhdXNlIHRoZSBsaXN0IGlzIHNv
cnRlZCovDQotIA0KLSAgICAvKiBUYXNrbGV0IHdvcmsgKHdoaWNoIHJ1bnMgaW4gaWRsZSBWQ1BV
IGNvbnRleHQpIG92ZXJyaWRlcyBhbGwgZWxzZS4gKi8NCisgICAgLyogTm93IHNpbXBseSBwaWNr
IHRoZSBmaXJzdCBkb21haW4gZnJvbSB0aGUgcnVucXVldWUsIHdoaWNoIGhhcyB0aGUNCisgICAg
ICogZWFybGllc3QgZGVhZGxpbmUsIGJlY2F1c2UgdGhlIGxpc3QgaXMgc29ydGVkDQorICAgICAq
DQorICAgICAqIFRhc2tsZXQgd29yayAod2hpY2ggcnVucyBpbiBpZGxlIFZDUFUgY29udGV4dCkg
b3ZlcnJpZGVzIGFsbCBlbHNlLg0KKyAgICAgKi8NCiAgICAgaWYgKCB0YXNrbGV0X3dvcmtfc2No
ZWR1bGVkIHx8DQogICAgICAgICAgKGxpc3RfZW1wdHkocnVucSkgJiYgbGlzdF9lbXB0eSh3YWl0
cSkpIHx8DQogICAgICAgICAgdW5saWtlbHkoIWNwdW1hc2tfdGVzdF9jcHUoY3B1LCBTRURGX0NQ
VU9OTElORShwZXJfY3B1KGNwdXBvb2wsIGNwdSkpKSkgKQ0KQEAgLTgzMyw5ICs3NzcsMTAgQEAg
c3RhdGljIHN0cnVjdCB0YXNrX3NsaWNlIHNlZGZfZG9fc2NoZWR1bA0KICAgICAgICAgew0KICAg
ICAgICAgICAgIHdhaXRpbmYgID0gbGlzdF9lbnRyeSh3YWl0cS0+bmV4dCwNCiAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgc3RydWN0IHNlZGZfdmNwdV9pbmZvLGxpc3QpOw0KLSAg
ICAgICAgICAgIC8qcmVydW4gc2NoZWR1bGVyLCB3aGVuIHNjaGVkdWxlZCBkb21haW4gcmVhY2hl
cyBpdCdzDQotICAgICAgICAgICAgICBlbmQgb2Ygc2xpY2Ugb3IgdGhlIGZpcnN0IGRvbWFpbiBm
cm9tIHRoZSB3YWl0cXVldWUNCi0gICAgICAgICAgICAgIGdldHMgcmVhZHkqLw0KKyAgICAgICAg
ICAgIC8qIFJlcnVuIHNjaGVkdWxlciwgd2hlbiBzY2hlZHVsZWQgZG9tYWluIHJlYWNoZXMgaXQn
cw0KKyAgICAgICAgICAgICAqIGVuZCBvZiBzbGljZSBvciB0aGUgZmlyc3QgZG9tYWluIGZyb20g
dGhlIHdhaXRxdWV1ZQ0KKyAgICAgICAgICAgICAqIGdldHMgcmVhZHkuDQorICAgICAgICAgICAg
ICovDQogICAgICAgICAgICAgcmV0LnRpbWUgPSBNSU4obm93ICsgcnVuaW5mLT5zbGljZSAtIHJ1
bmluZi0+Y3B1dGltZSwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICBQRVJJT0RfQkVHSU4o
d2FpdGluZikpIC0gbm93Ow0KICAgICAgICAgfQ0KQEAgLTg0NywxNCArNzkyLDE1IEBAIHN0YXRp
YyBzdHJ1Y3QgdGFza19zbGljZSBzZWRmX2RvX3NjaGVkdWwNCiAgICAgZWxzZQ0KICAgICB7DQog
ICAgICAgICB3YWl0aW5mICA9IGxpc3RfZW50cnkod2FpdHEtPm5leHQsc3RydWN0IHNlZGZfdmNw
dV9pbmZvLCBsaXN0KTsNCi0gICAgICAgIC8qd2UgY291bGQgbm90IGZpbmQgYW55IHN1aXRhYmxl
IGRvbWFpbiANCi0gICAgICAgICAgPT4gbG9vayBmb3IgZG9tYWlucyB0aGF0IGFyZSBhd2FyZSBv
ZiBleHRyYXRpbWUqLw0KKyAgICAgICAgLyogV2UgY291bGQgbm90IGZpbmQgYW55IHN1aXRhYmxl
IGRvbWFpbiANCisgICAgICAgICAqID0+IGxvb2sgZm9yIGRvbWFpbnMgdGhhdCBhcmUgYXdhcmUg
b2YgZXh0cmF0aW1lKi8NCiAgICAgICAgIHJldCA9IHNlZGZfZG9fZXh0cmFfc2NoZWR1bGUobm93
LCBQRVJJT0RfQkVHSU4od2FpdGluZiksDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIGV4dHJhcSwgY3B1KTsNCiAgICAgfQ0KIA0KLSAgICAvKlRPRE86IERvIHNvbWV0aGlu
ZyBVU0VGVUwgd2hlbiB0aGlzIGhhcHBlbnMgYW5kIGZpbmQgb3V0LCB3aHkgaXQNCi0gICAgICBz
dGlsbCBjYW4gaGFwcGVuISEhKi8NCisgICAgLyogVE9ETzogRG8gc29tZXRoaW5nIFVTRUZVTCB3
aGVuIHRoaXMgaGFwcGVucyBhbmQgZmluZCBvdXQsIHdoeSBpdA0KKyAgICAgKiBzdGlsbCBjYW4g
aGFwcGVuISEhDQorICAgICAqLw0KICAgICBpZiAoIHJldC50aW1lIDwgMCkNCiAgICAgew0KICAg
ICAgICAgcHJpbnRrKCJPdWNoISBXZSBhcmUgc2VyaW91c2x5IEJFSElORCBzY2hlZHVsZSEgJSJQ
UklpNjQiXG4iLA0KQEAgLTg3NCw5ICs4MjAsNiBAQCBzdGF0aWMgc3RydWN0IHRhc2tfc2xpY2Ug
c2VkZl9kb19zY2hlZHVsDQogDQogc3RhdGljIHZvaWQgc2VkZl9zbGVlcChjb25zdCBzdHJ1Y3Qg
c2NoZWR1bGVyICpvcHMsIHN0cnVjdCB2Y3B1ICpkKQ0KIHsNCi0gICAgUFJJTlQoMiwic2VkZl9z
bGVlcCB3YXMgY2FsbGVkLCBkb21haW4taWQgJWkuJWlcbiIsDQotICAgICAgICAgIGQtPmRvbWFp
bi0+ZG9tYWluX2lkLCBkLT52Y3B1X2lkKTsNCi0gDQogICAgIGlmICggaXNfaWRsZV92Y3B1KGQp
ICkNCiAgICAgICAgIHJldHVybjsNCiANCkBAIC05NzIsMjcgKzkxNSwyOSBAQCBzdGF0aWMgdm9p
ZCBzZWRmX3NsZWVwKGNvbnN0IHN0cnVjdCBzY2hlDQogc3RhdGljIHZvaWQgdW5ibG9ja19zaG9y
dF9leHRyYV9zdXBwb3J0KA0KICAgICBzdHJ1Y3Qgc2VkZl92Y3B1X2luZm8qIGluZiwgc190aW1l
X3Qgbm93KQ0KIHsNCi0gICAgLyp0aGlzIHVuYmxvY2tpbmcgc2NoZW1lIHRyaWVzIHRvIHN1cHBv
cnQgdGhlIGRvbWFpbiwgYnkgYXNzaWduaW5nIGl0DQotICAgIGEgcHJpb3JpdHkgaW4gZXh0cmF0
aW1lIGRpc3RyaWJ1dGlvbiBhY2NvcmRpbmcgdG8gdGhlIGxvc3Mgb2YgdGltZQ0KLSAgICBpbiB0
aGlzIHNsaWNlIGR1ZSB0byBibG9ja2luZyovDQorICAgIC8qIFRoaXMgdW5ibG9ja2luZyBzY2hl
bWUgdHJpZXMgdG8gc3VwcG9ydCB0aGUgZG9tYWluLCBieSBhc3NpZ25pbmcgaXQNCisgICAgICog
YSBwcmlvcml0eSBpbiBleHRyYXRpbWUgZGlzdHJpYnV0aW9uIGFjY29yZGluZyB0byB0aGUgbG9z
cyBvZiB0aW1lDQorICAgICAqIGluIHRoaXMgc2xpY2UgZHVlIHRvIGJsb2NraW5nDQorICAgICAq
Lw0KICAgICBzX3RpbWVfdCBwZW47DQogIA0KLSAgICAvKm5vIG1vcmUgcmVhbHRpbWUgZXhlY3V0
aW9uIGluIHRoaXMgcGVyaW9kISovDQorICAgIC8qIE5vIG1vcmUgcmVhbHRpbWUgZXhlY3V0aW9u
IGluIHRoaXMgcGVyaW9kISAqLw0KICAgICBpbmYtPmRlYWRsX2FicyArPSBpbmYtPnBlcmlvZDsN
CiAgICAgaWYgKCBsaWtlbHkoaW5mLT5ibG9ja19hYnMpICkNCiAgICAgew0KLSAgICAgICAgLy90
cmVhdCBibG9ja2VkIHRpbWUgYXMgY29uc3VtZWQgYnkgdGhlIGRvbWFpbiovDQorICAgICAgICAv
KiBUcmVhdCBibG9ja2VkIHRpbWUgYXMgY29uc3VtZWQgYnkgdGhlIGRvbWFpbiAqLw0KICAgICAg
ICAgLyppbmYtPmNwdXRpbWUgKz0gbm93IC0gaW5mLT5ibG9ja19hYnM7Ki8NCi0gICAgICAgIC8q
cGVuYWx0eSBpcyB0aW1lIHRoZSBkb21haW4gd291bGQgaGF2ZQ0KLSAgICAgICAgICBoYWQgaWYg
aXQgY29udGludWVkIHRvIHJ1biAqLw0KKyAgICAgICAgLyogUGVuYWx0eSBpcyB0aW1lIHRoZSBk
b21haW4gd291bGQgaGF2ZQ0KKyAgICAgICAgICogaGFkIGlmIGl0IGNvbnRpbnVlZCB0byBydW4u
DQorICAgICAgICAgKi8NCiAgICAgICAgIHBlbiA9IChpbmYtPnNsaWNlIC0gaW5mLT5jcHV0aW1l
KTsNCiAgICAgICAgIGlmICggcGVuIDwgMCApDQogICAgICAgICAgICAgcGVuID0gMDsNCi0gICAg
ICAgIC8qYWNjdW11bGF0ZSBhbGwgcGVuYWx0aWVzIG92ZXIgdGhlIHBlcmlvZHMqLw0KKyAgICAg
ICAgLyogQWNjdW11bGF0ZSBhbGwgcGVuYWx0aWVzIG92ZXIgdGhlIHBlcmlvZHMgKi8NCiAgICAg
ICAgIC8qaW5mLT5zaG9ydF9ibG9ja19sb3N0X3RvdCArPSBwZW47Ki8NCi0gICAgICAgIC8qc2V0
IHBlbmFsdHkgdG8gdGhlIGN1cnJlbnQgdmFsdWUqLw0KKyAgICAgICAgLyogU2V0IHBlbmFsdHkg
dG8gdGhlIGN1cnJlbnQgdmFsdWUgKi8NCiAgICAgICAgIGluZi0+c2hvcnRfYmxvY2tfbG9zdF90
b3QgPSBwZW47DQotICAgICAgICAvKm5vdCBzdXJlIHdoaWNoIG9uZSBpcyBiZXR0ZXIuLiBidXQg
c2VlbXMgdG8gd29yayB3ZWxsLi4uKi8NCisgICAgICAgIC8qIE5vdCBzdXJlIHdoaWNoIG9uZSBp
cyBiZXR0ZXIuLiBidXQgc2VlbXMgdG8gd29yayB3ZWxsLi4uICovDQogICANCiAgICAgICAgIGlm
ICggaW5mLT5zaG9ydF9ibG9ja19sb3N0X3RvdCApDQogICAgICAgICB7DQpAQCAtMTAwMiwyOCAr
OTQ3LDMwIEBAIHN0YXRpYyB2b2lkIHVuYmxvY2tfc2hvcnRfZXh0cmFfc3VwcG9ydCgNCiAgICAg
ICAgICAgICBpbmYtPnBlbl9leHRyYV9ibG9ja3MrKzsNCiAjZW5kaWYNCiAgICAgICAgICAgICBp
ZiAoIGV4dHJhcV9vbihpbmYtPnZjcHUsIEVYVFJBX1BFTl9RKSApDQotICAgICAgICAgICAgICAg
IC8qcmVtb3ZlIGRvbWFpbiBmb3IgcG9zc2libGUgcmVzb3J0aW5nISovDQorICAgICAgICAgICAg
ICAgIC8qIFJlbW92ZSBkb21haW4gZm9yIHBvc3NpYmxlIHJlc29ydGluZyEgKi8NCiAgICAgICAg
ICAgICAgICAgZXh0cmFxX2RlbChpbmYtPnZjcHUsIEVYVFJBX1BFTl9RKTsNCiAgICAgICAgICAg
ICBlbHNlDQotICAgICAgICAgICAgICAgIC8qcmVtZW1iZXIgdGhhdCB3ZSB3YW50IHRvIGJlIG9u
IHRoZSBwZW5hbHR5IHENCi0gICAgICAgICAgICAgICAgICBzbyB0aGF0IHdlIGNhbiBjb250aW51
ZSB3aGVuIHdlICh1bi0pYmxvY2sNCi0gICAgICAgICAgICAgICAgICBpbiBwZW5hbHR5LWV4dHJh
dGltZSovDQorICAgICAgICAgICAgICAgIC8qIFJlbWVtYmVyIHRoYXQgd2Ugd2FudCB0byBiZSBv
biB0aGUgcGVuYWx0eSBxDQorICAgICAgICAgICAgICAgICAqIHNvIHRoYXQgd2UgY2FuIGNvbnRp
bnVlIHdoZW4gd2UgKHVuLSlibG9jaw0KKyAgICAgICAgICAgICAgICAgKiBpbiBwZW5hbHR5LWV4
dHJhdGltZQ0KKyAgICAgICAgICAgICAgICAgKi8NCiAgICAgICAgICAgICAgICAgaW5mLT5zdGF0
dXMgfD0gRVhUUkFfV0FOVF9QRU5fUTsNCiAgICANCi0gICAgICAgICAgICAvKihyZS0pYWRkIGRv
bWFpbiB0byB0aGUgcGVuYWx0eSBleHRyYXEqLw0KKyAgICAgICAgICAgIC8qIChyZS0pYWRkIGRv
bWFpbiB0byB0aGUgcGVuYWx0eSBleHRyYXEgKi8NCiAgICAgICAgICAgICBleHRyYXFfYWRkX3Nv
cnRfdXBkYXRlKGluZi0+dmNwdSwgRVhUUkFfUEVOX1EsIDApOw0KICAgICAgICAgfQ0KICAgICB9
DQogDQotICAgIC8qZ2l2ZSBpdCBhIGZyZXNoIHNsaWNlIGluIHRoZSBuZXh0IHBlcmlvZCEqLw0K
KyAgICAvKiBHaXZlIGl0IGEgZnJlc2ggc2xpY2UgaW4gdGhlIG5leHQgcGVyaW9kISAqLw0KICAg
ICBpbmYtPmNwdXRpbWUgPSAwOw0KIH0NCiANCiANCiBzdGF0aWMgdm9pZCB1bmJsb2NrX2xvbmdf
Y29uc19iKHN0cnVjdCBzZWRmX3ZjcHVfaW5mbyogaW5mLHNfdGltZV90IG5vdykNCiB7DQotICAg
IC8qQ29uc2VydmF0aXZlIDJiKi8NCi0gICAgLypUcmVhdCB0aGUgdW5ibG9ja2luZyB0aW1lIGFz
IGEgc3RhcnQgb2YgYSBuZXcgcGVyaW9kICovDQorICAgIC8qIENvbnNlcnZhdGl2ZSAyYiAqLw0K
Kw0KKyAgICAvKiBUcmVhdCB0aGUgdW5ibG9ja2luZyB0aW1lIGFzIGEgc3RhcnQgb2YgYSBuZXcg
cGVyaW9kICovDQogICAgIGluZi0+ZGVhZGxfYWJzID0gbm93ICsgaW5mLT5wZXJpb2Q7DQogICAg
IGluZi0+Y3B1dGltZSA9IDA7DQogfQ0KQEAgLTEwNDYsMTUgKzk5MywxNiBAQCBzdGF0aWMgaW5s
aW5lIGludCBnZXRfcnVuX3R5cGUoc3RydWN0IHZjDQogfQ0KIA0KIA0KLS8qQ29tcGFyZXMgdHdv
IGRvbWFpbnMgaW4gdGhlIHJlbGF0aW9uIG9mIHdoZXRoZXIgdGhlIG9uZSBpcyBhbGxvd2VkIHRv
DQotICBpbnRlcnJ1cHQgdGhlIG90aGVycyBleGVjdXRpb24uDQotICBJdCByZXR1cm5zIHRydWUg
KCE9MCkgaWYgYSBzd2l0Y2ggdG8gdGhlIG90aGVyIGRvbWFpbiBpcyBnb29kLg0KLSAgQ3VycmVu
dCBQcmlvcml0eSBzY2hlbWUgaXMgYXMgZm9sbG93czoNCi0gICBFREYgPiBMMCAocGVuYWx0eSBi
YXNlZCkgZXh0cmEtdGltZSA+IA0KLSAgIEwxICh1dGlsaXphdGlvbikgZXh0cmEtdGltZSA+IGlk
bGUtZG9tYWluDQotICBJbiB0aGUgc2FtZSBjbGFzcyBwcmlvcml0aWVzIGFyZSBhc3NpZ25lZCBh
cyBmb2xsb3dpbmc6DQotICAgRURGOiBlYXJseSBkZWFkbGluZSA+IGxhdGUgZGVhZGxpbmUNCi0g
ICBMMCBleHRyYS10aW1lOiBsb3dlciBzY29yZSA+IGhpZ2hlciBzY29yZSovDQorLyogQ29tcGFy
ZXMgdHdvIGRvbWFpbnMgaW4gdGhlIHJlbGF0aW9uIG9mIHdoZXRoZXIgdGhlIG9uZSBpcyBhbGxv
d2VkIHRvDQorICogaW50ZXJydXB0IHRoZSBvdGhlcnMgZXhlY3V0aW9uLg0KKyAqIEl0IHJldHVy
bnMgdHJ1ZSAoIT0wKSBpZiBhIHN3aXRjaCB0byB0aGUgb3RoZXIgZG9tYWluIGlzIGdvb2QuDQor
ICogQ3VycmVudCBQcmlvcml0eSBzY2hlbWUgaXMgYXMgZm9sbG93czoNCisgKiAgRURGID4gTDAg
KHBlbmFsdHkgYmFzZWQpIGV4dHJhLXRpbWUgPiANCisgKiAgTDEgKHV0aWxpemF0aW9uKSBleHRy
YS10aW1lID4gaWRsZS1kb21haW4NCisgKiBJbiB0aGUgc2FtZSBjbGFzcyBwcmlvcml0aWVzIGFy
ZSBhc3NpZ25lZCBhcyBmb2xsb3dpbmc6DQorICogIEVERjogZWFybHkgZGVhZGxpbmUgPiBsYXRl
IGRlYWRsaW5lDQorICogIEwwIGV4dHJhLXRpbWU6IGxvd2VyIHNjb3JlID4gaGlnaGVyIHNjb3Jl
DQorICovDQogc3RhdGljIGlubGluZSBpbnQgc2hvdWxkX3N3aXRjaChzdHJ1Y3QgdmNwdSAqY3Vy
LA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgc3RydWN0IHZjcHUgKm90aGVyLA0K
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgc190aW1lX3Qgbm93KQ0KQEAgLTEwNjMs
MTkgKzEwMTEsMTkgQEAgc3RhdGljIGlubGluZSBpbnQgc2hvdWxkX3N3aXRjaChzdHJ1Y3Qgdg0K
ICAgICBjdXJfaW5mICAgPSBFRE9NX0lORk8oY3VyKTsNCiAgICAgb3RoZXJfaW5mID0gRURPTV9J
TkZPKG90aGVyKTsNCiAgDQotICAgIC8qIENoZWNrIHdoZXRoZXIgd2UgbmVlZCB0byBtYWtlIGFu
IGVhcmxpZXIgc2NoZWR1bGluZyBkZWNpc2lvbi4gKi8NCisgICAgLyogQ2hlY2sgd2hldGhlciB3
ZSBuZWVkIHRvIG1ha2UgYW4gZWFybGllciBzY2hlZHVsaW5nIGRlY2lzaW9uICovDQogICAgIGlm
ICggUEVSSU9EX0JFR0lOKG90aGVyX2luZikgPCANCiAgICAgICAgICBDUFVfSU5GTyhvdGhlci0+
cHJvY2Vzc29yKS0+Y3VycmVudF9zbGljZV9leHBpcmVzICkNCiAgICAgICAgIHJldHVybiAxOw0K
IA0KLSAgICAvKiBObyB0aW1pbmctYmFzZWQgc3dpdGNoZXMgbmVlZCB0byBiZSB0YWtlbiBpbnRv
IGFjY291bnQgaGVyZS4gKi8NCisgICAgLyogTm8gdGltaW5nLWJhc2VkIHN3aXRjaGVzIG5lZWQg
dG8gYmUgdGFrZW4gaW50byBhY2NvdW50IGhlcmUgKi8NCiAgICAgc3dpdGNoICggZ2V0X3J1bl90
eXBlKGN1cikgKQ0KICAgICB7DQogICAgIGNhc2UgRE9NQUlOX0VERjoNCi0gICAgICAgIC8qIERv
IG5vdCBpbnRlcnJ1cHQgYSBydW5uaW5nIEVERiBkb21haW4uICovDQorICAgICAgICAvKiBEbyBu
b3QgaW50ZXJydXB0IGEgcnVubmluZyBFREYgZG9tYWluICovDQogICAgICAgICByZXR1cm4gMDsN
CiAgICAgY2FzZSBET01BSU5fRVhUUkFfUEVOOg0KLSAgICAgICAgLyogQ2hlY2sgd2hldGhlciB3
ZSBhbHNvIHdhbnQgdGhlIEwwIGV4LXEgd2l0aCBsb3dlciBzY29yZS4gKi8NCisgICAgICAgIC8q
IENoZWNrIHdoZXRoZXIgd2UgYWxzbyB3YW50IHRoZSBMMCBleC1xIHdpdGggbG93ZXIgc2NvcmUg
Ki8NCiAgICAgICAgIHJldHVybiAoKG90aGVyX2luZi0+c3RhdHVzICYgRVhUUkFfV0FOVF9QRU5f
USkgJiYNCiAgICAgICAgICAgICAgICAgKG90aGVyX2luZi0+c2NvcmVbRVhUUkFfUEVOX1FdIDwg
DQogICAgICAgICAgICAgICAgICBjdXJfaW5mLT5zY29yZVtFWFRSQV9QRU5fUV0pKTsNCkBAIC0x
MDk2LDE4ICsxMDQ0LDExIEBAIHN0YXRpYyB2b2lkIHNlZGZfd2FrZShjb25zdCBzdHJ1Y3Qgc2No
ZWQNCiAgICAgc190aW1lX3QgICAgICAgICAgICAgIG5vdyA9IE5PVygpOw0KICAgICBzdHJ1Y3Qg
c2VkZl92Y3B1X2luZm8qIGluZiA9IEVET01fSU5GTyhkKTsNCiANCi0gICAgUFJJTlQoMywgInNl
ZGZfd2FrZSB3YXMgY2FsbGVkLCBkb21haW4taWQgJWkuJWlcbiIsZC0+ZG9tYWluLT5kb21haW5f
aWQsDQotICAgICAgICAgIGQtPnZjcHVfaWQpOw0KLQ0KICAgICBpZiAoIHVubGlrZWx5KGlzX2lk
bGVfdmNwdShkKSkgKQ0KICAgICAgICAgcmV0dXJuOw0KICAgIA0KICAgICBpZiAoIHVubGlrZWx5
KF9fdGFza19vbl9xdWV1ZShkKSkgKQ0KLSAgICB7DQotICAgICAgICBQUklOVCgzLCJcdGRvbWFp
biAlaS4laSBpcyBhbHJlYWR5IGluIHNvbWUgcXVldWVcbiIsDQotICAgICAgICAgICAgICBkLT5k
b21haW4tPmRvbWFpbl9pZCwgZC0+dmNwdV9pZCk7DQogICAgICAgICByZXR1cm47DQotICAgIH0N
CiANCiAgICAgQVNTRVJUKCFzZWRmX3J1bm5hYmxlKGQpKTsNCiAgICAgaW5mLT5zdGF0dXMgJj0g
flNFREZfQVNMRUVQOw0KQEAgLTExMTYsMjggKzEwNTcsMjQgQEAgc3RhdGljIHZvaWQgc2VkZl93
YWtlKGNvbnN0IHN0cnVjdCBzY2hlZA0KICANCiAgICAgaWYgKCB1bmxpa2VseShpbmYtPmRlYWRs
X2FicyA9PSAwKSApDQogICAgIHsNCi0gICAgICAgIC8qaW5pdGlhbCBzZXR1cCBvZiB0aGUgZGVh
ZGxpbmUqLw0KKyAgICAgICAgLyogSW5pdGlhbCBzZXR1cCBvZiB0aGUgZGVhZGxpbmUgKi8NCiAg
ICAgICAgIGluZi0+ZGVhZGxfYWJzID0gbm93ICsgaW5mLT5zbGljZTsNCiAgICAgfQ0KICAgDQot
ICAgIFBSSU5UKDMsICJ3YWtpbmcgdXAgZG9tYWluICVpLiVpIChkZWFkbD0gJSJQUkl1NjQiIHBl
cmlvZD0gJSJQUkl1NjQNCi0gICAgICAgICAgIm5vdz0gJSJQUkl1NjQiKVxuIiwNCi0gICAgICAg
ICAgZC0+ZG9tYWluLT5kb21haW5faWQsIGQtPnZjcHVfaWQsIGluZi0+ZGVhZGxfYWJzLCBpbmYt
PnBlcmlvZCwgbm93KTsNCi0NCiAjaWZkZWYgU0VERl9TVEFUUyANCiAgICAgaW5mLT5ibG9ja190
b3QrKzsNCiAjZW5kaWYNCiANCiAgICAgaWYgKCB1bmxpa2VseShub3cgPCBQRVJJT0RfQkVHSU4o
aW5mKSkgKQ0KICAgICB7DQotICAgICAgICBQUklOVCg0LCJleHRyYXRpbWUgdW5ibG9ja1xuIik7
DQotICAgICAgICAvKiB1bmJsb2NraW5nIGluIGV4dHJhLXRpbWUhICovDQorICAgICAgICAvKiBV
bmJsb2NraW5nIGluIGV4dHJhLXRpbWUhICovDQogICAgICAgICBpZiAoIGluZi0+c3RhdHVzICYg
RVhUUkFfV0FOVF9QRU5fUSApDQogICAgICAgICB7DQotICAgICAgICAgICAgLyp3ZSBoYXZlIGEg
ZG9tYWluIHRoYXQgd2FudHMgY29tcGVuc2F0aW9uDQotICAgICAgICAgICAgICBmb3IgYmxvY2sg
cGVuYWx0eSBhbmQgZGlkIGp1c3QgYmxvY2sgaW4NCi0gICAgICAgICAgICAgIGl0cyBjb21wZW5z
YXRpb24gdGltZS4gR2l2ZSBpdCBhbm90aGVyDQotICAgICAgICAgICAgICBjaGFuY2UhKi8NCisg
ICAgICAgICAgICAvKiBXZSBoYXZlIGEgZG9tYWluIHRoYXQgd2FudHMgY29tcGVuc2F0aW9uDQor
ICAgICAgICAgICAgICogZm9yIGJsb2NrIHBlbmFsdHkgYW5kIGRpZCBqdXN0IGJsb2NrIGluDQor
ICAgICAgICAgICAgICogaXRzIGNvbXBlbnNhdGlvbiB0aW1lLiBHaXZlIGl0IGFub3RoZXINCisg
ICAgICAgICAgICAgKiBjaGFuY2UhDQorICAgICAgICAgICAgICovDQogICAgICAgICAgICAgZXh0
cmFxX2FkZF9zb3J0X3VwZGF0ZShkLCBFWFRSQV9QRU5fUSwgMCk7DQogICAgICAgICB9DQogICAg
ICAgICBleHRyYXFfY2hlY2tfYWRkX3VuYmxvY2tlZChkLCAwKTsNCkBAIC0xMTQ2LDggKzEwODMs
NyBAQCBzdGF0aWMgdm9pZCBzZWRmX3dha2UoY29uc3Qgc3RydWN0IHNjaGVkDQogICAgIHsgIA0K
ICAgICAgICAgaWYgKCBub3cgPCBpbmYtPmRlYWRsX2FicyApDQogICAgICAgICB7DQotICAgICAg
ICAgICAgUFJJTlQoNCwic2hvcnQgdW5ibG9ja2luZ1xuIik7DQotICAgICAgICAgICAgLypzaG9y
dCBibG9ja2luZyovDQorICAgICAgICAgICAgLyogU2hvcnQgYmxvY2tpbmcgKi8NCiAjaWZkZWYg
U0VERl9TVEFUUw0KICAgICAgICAgICAgIGluZi0+c2hvcnRfYmxvY2tfdG90Kys7DQogI2VuZGlm
DQpAQCAtMTE1Nyw4ICsxMDkzLDcgQEAgc3RhdGljIHZvaWQgc2VkZl93YWtlKGNvbnN0IHN0cnVj
dCBzY2hlZA0KICAgICAgICAgfQ0KICAgICAgICAgZWxzZQ0KICAgICAgICAgew0KLSAgICAgICAg
ICAgIFBSSU5UKDQsImxvbmcgdW5ibG9ja2luZ1xuIik7DQotICAgICAgICAgICAgLypsb25nIHVu
YmxvY2tpbmcqLw0KKyAgICAgICAgICAgIC8qIExvbmcgdW5ibG9ja2luZyAqLw0KICNpZmRlZiBT
RURGX1NUQVRTDQogICAgICAgICAgICAgaW5mLT5sb25nX2Jsb2NrX3RvdCsrOw0KICNlbmRpZg0K
QEAgLTExNjgsMjQgKzExMDMsMTMgQEAgc3RhdGljIHZvaWQgc2VkZl93YWtlKGNvbnN0IHN0cnVj
dCBzY2hlZA0KICAgICAgICAgfQ0KICAgICB9DQogDQotICAgIFBSSU5UKDMsICJ3b2tlIHVwIGRv
bWFpbiAlaS4laSAoZGVhZGw9ICUiUFJJdTY0IiBwZXJpb2Q9ICUiUFJJdTY0DQotICAgICAgICAg
ICJub3c9ICUiUFJJdTY0IilcbiIsDQotICAgICAgICAgIGQtPmRvbWFpbi0+ZG9tYWluX2lkLCBk
LT52Y3B1X2lkLCBpbmYtPmRlYWRsX2FicywNCi0gICAgICAgICAgaW5mLT5wZXJpb2QsIG5vdyk7
DQotDQogICAgIGlmICggUEVSSU9EX0JFR0lOKGluZikgPiBub3cgKQ0KLSAgICB7DQogICAgICAg
ICBfX2FkZF90b193YWl0cXVldWVfc29ydChkKTsNCi0gICAgICAgIFBSSU5UKDMsImFkZGVkIHRv
IHdhaXRxXG4iKTsNCi0gICAgfQ0KICAgICBlbHNlDQotICAgIHsNCiAgICAgICAgIF9fYWRkX3Rv
X3J1bnF1ZXVlX3NvcnQoZCk7DQotICAgICAgICBQUklOVCgzLCJhZGRlZCB0byBydW5xXG4iKTsN
Ci0gICAgfQ0KICANCiAjaWZkZWYgU0VERl9TVEFUUw0KLSAgICAvKmRvIHNvbWUgc3RhdGlzdGlj
cyBoZXJlLi4uKi8NCisgICAgLyogRG8gc29tZSBzdGF0aXN0aWNzIGhlcmUuLi4gKi8NCiAgICAg
aWYgKCBpbmYtPmJsb2NrX2FicyAhPSAwICkNCiAgICAgew0KICAgICAgICAgaW5mLT5ibG9ja190
aW1lX3RvdCArPSBub3cgLSBpbmYtPmJsb2NrX2FiczsNCkBAIC0xMTk0LDEyICsxMTE4LDEzIEBA
IHN0YXRpYyB2b2lkIHNlZGZfd2FrZShjb25zdCBzdHJ1Y3Qgc2NoZWQNCiAgICAgfQ0KICNlbmRp
Zg0KIA0KLSAgICAvKnNhbml0eSBjaGVjazogbWFrZSBzdXJlIGVhY2ggZXh0cmEtYXdhcmUgZG9t
YWluIElTIG9uIHRoZSB1dGlsLXEhKi8NCisgICAgLyogU2FuaXR5IGNoZWNrOiBtYWtlIHN1cmUg
ZWFjaCBleHRyYS1hd2FyZSBkb21haW4gSVMgb24gdGhlIHV0aWwtcSEgKi8NCiAgICAgQVNTRVJU
KElNUExZKGluZi0+c3RhdHVzICYgRVhUUkFfQVdBUkUsIGV4dHJhcV9vbihkLCBFWFRSQV9VVElM
X1EpKSk7DQogICAgIEFTU0VSVChfX3Rhc2tfb25fcXVldWUoZCkpOw0KLSAgICAvKmNoZWNrIHdo
ZXRoZXIgdGhlIGF3YWtlbmVkIHRhc2sgbmVlZHMgdG8gaW52b2tlIHRoZSBkb19zY2hlZHVsZQ0K
LSAgICAgIHJvdXRpbmUuIFRyeSB0byBhdm9pZCB1bm5lY2Vzc2FyeSBydW5zIGJ1dDoNCi0gICAg
ICBTYXZlIGFwcHJveGltYXRpb246IEFsd2F5cyBzd2l0Y2ggdG8gc2NoZWR1bGVyISovDQorICAg
IC8qIENoZWNrIHdoZXRoZXIgdGhlIGF3YWtlbmVkIHRhc2sgbmVlZHMgdG8gaW52b2tlIHRoZSBk
b19zY2hlZHVsZQ0KKyAgICAgKiByb3V0aW5lLiBUcnkgdG8gYXZvaWQgdW5uZWNlc3NhcnkgcnVu
cyBidXQ6DQorICAgICAqIFNhdmUgYXBwcm94aW1hdGlvbjogQWx3YXlzIHN3aXRjaCB0byBzY2hl
ZHVsZXIhDQorICAgICAqLw0KICAgICBBU1NFUlQoZC0+cHJvY2Vzc29yID49IDApOw0KICAgICBB
U1NFUlQoZC0+cHJvY2Vzc29yIDwgbnJfY3B1X2lkcyk7DQogICAgIEFTU0VSVChwZXJfY3B1KHNj
aGVkdWxlX2RhdGEsIGQtPnByb2Nlc3NvcikuY3Vycik7DQpAQCAtMTI0NCw3ICsxMTY5LDcgQEAg
c3RhdGljIHZvaWQgc2VkZl9kdW1wX2RvbWFpbihzdHJ1Y3QgdmNwdQ0KIH0NCiANCiANCi0vKiBk
dW1wcyBhbGwgZG9tYWlucyBvbiB0aGUgc3BlY2lmaWVkIGNwdSAqLw0KKy8qIER1bXBzIGFsbCBk
b21haW5zIG9uIHRoZSBzcGVjaWZpZWQgY3B1ICovDQogc3RhdGljIHZvaWQgc2VkZl9kdW1wX2Nw
dV9zdGF0ZShjb25zdCBzdHJ1Y3Qgc2NoZWR1bGVyICpvcHMsIGludCBpKQ0KIHsNCiAgICAgc3Ry
dWN0IGxpc3RfaGVhZCAgICAgICpsaXN0LCAqcXVldWUsICp0bXA7DQpAQCAtMTMxOSw3ICsxMjQ0
LDcgQEAgc3RhdGljIHZvaWQgc2VkZl9kdW1wX2NwdV9zdGF0ZShjb25zdCBzdA0KIH0NCiANCiAN
Ci0vKiBBZGp1c3RzIHBlcmlvZHMgYW5kIHNsaWNlcyBvZiB0aGUgZG9tYWlucyBhY2NvcmRpbmds
eSB0byB0aGVpciB3ZWlnaHRzLiAqLw0KKy8qIEFkanVzdHMgcGVyaW9kcyBhbmQgc2xpY2VzIG9m
IHRoZSBkb21haW5zIGFjY29yZGluZ2x5IHRvIHRoZWlyIHdlaWdodHMgKi8NCiBzdGF0aWMgaW50
IHNlZGZfYWRqdXN0X3dlaWdodHMoc3RydWN0IGNwdXBvb2wgKmMsIHN0cnVjdCB4ZW5fZG9tY3Rs
X3NjaGVkdWxlcl9vcCAqY21kKQ0KIHsNCiAgICAgc3RydWN0IHZjcHUgKnA7DQpAQCAtMTMzNSw3
ICsxMjYwLDcgQEAgc3RhdGljIGludCBzZWRmX2FkanVzdF93ZWlnaHRzKHN0cnVjdCBjcA0KICAg
ICAgICAgcmV0dXJuIC1FTk9NRU07DQogICAgIH0NCiANCi0gICAgLyogU3VtIGFjcm9zcyBhbGwg
d2VpZ2h0cy4gKi8NCisgICAgLyogU3VtIGFjcm9zcyBhbGwgd2VpZ2h0cyAqLw0KICAgICByY3Vf
cmVhZF9sb2NrKCZkb21saXN0X3JlYWRfbG9jayk7DQogICAgIGZvcl9lYWNoX2RvbWFpbl9pbl9j
cHVwb29sKCBkLCBjICkNCiAgICAgew0KQEAgLTEzNTAsMTEgKzEyNzUsMTMgQEAgc3RhdGljIGlu
dCBzZWRmX2FkanVzdF93ZWlnaHRzKHN0cnVjdCBjcA0KICAgICAgICAgICAgIH0NCiAgICAgICAg
ICAgICBlbHNlDQogICAgICAgICAgICAgew0KLSAgICAgICAgICAgICAgICAvKmRvbid0IG1vZGlm
eSBkb21haW5zIHdobyBkb24ndCBoYXZlIGEgd2VpZ2h0LCBidXQgc3VtDQotICAgICAgICAgICAg
ICAgICAgdXAgdGhlIHRpbWUgdGhleSBuZWVkLCBwcm9qZWN0ZWQgdG8gYSBXRUlHSFRfUEVSSU9E
LA0KLSAgICAgICAgICAgICAgICAgIHNvIHRoYXQgdGhpcyB0aW1lIGlzIG5vdCBnaXZlbiB0byB0
aGUgd2VpZ2h0LWRyaXZlbg0KLSAgICAgICAgICAgICAgICAgIGRvbWFpbnMqLw0KLSAgICAgICAg
ICAgICAgICAvKmNoZWNrIGZvciBvdmVyZmxvd3MqLw0KKyAgICAgICAgICAgICAgICAvKiBEb24n
dCBtb2RpZnkgZG9tYWlucyB3aG8gZG9uJ3QgaGF2ZSBhIHdlaWdodCwgYnV0IHN1bQ0KKyAgICAg
ICAgICAgICAgICAgKiB1cCB0aGUgdGltZSB0aGV5IG5lZWQsIHByb2plY3RlZCB0byBhIFdFSUdI
VF9QRVJJT0QsDQorICAgICAgICAgICAgICAgICAqIHNvIHRoYXQgdGhpcyB0aW1lIGlzIG5vdCBn
aXZlbiB0byB0aGUgd2VpZ2h0LWRyaXZlbg0KKyAgICAgICAgICAgICAgICAgKiAgZG9tYWlucw0K
KyAgICAgICAgICAgICAgICAgKi8NCisNCisgICAgICAgICAgICAgICAgLyogQ2hlY2sgZm9yIG92
ZXJmbG93cyAqLw0KICAgICAgICAgICAgICAgICBBU1NFUlQoKFdFSUdIVF9QRVJJT0QgPCBVTE9O
R19NQVgpIA0KICAgICAgICAgICAgICAgICAgICAgICAgJiYgKEVET01fSU5GTyhwKS0+c2xpY2Vf
b3JpZyA8IFVMT05HX01BWCkpOw0KICAgICAgICAgICAgICAgICBzdW10W2NwdV0gKz0gDQpAQCAt
MTM2NSw3ICsxMjkyLDcgQEAgc3RhdGljIGludCBzZWRmX2FkanVzdF93ZWlnaHRzKHN0cnVjdCBj
cA0KICAgICB9DQogICAgIHJjdV9yZWFkX3VubG9jaygmZG9tbGlzdF9yZWFkX2xvY2spOw0KIA0K
LSAgICAvKiBBZGp1c3QgYWxsIHNsaWNlcyAoYW5kIHBlcmlvZHMpIHRvIHRoZSBuZXcgd2VpZ2h0
LiAqLw0KKyAgICAvKiBBZGp1c3QgYWxsIHNsaWNlcyAoYW5kIHBlcmlvZHMpIHRvIHRoZSBuZXcg
d2VpZ2h0ICovDQogICAgIHJjdV9yZWFkX2xvY2soJmRvbWxpc3RfcmVhZF9sb2NrKTsNCiAgICAg
Zm9yX2VhY2hfZG9tYWluX2luX2NwdXBvb2woIGQsIGMgKQ0KICAgICB7DQpAQCAtMTM5MywyMCAr
MTMyMCwxNSBAQCBzdGF0aWMgaW50IHNlZGZfYWRqdXN0X3dlaWdodHMoc3RydWN0IGNwDQogfQ0K
IA0KIA0KLS8qIHNldCBvciBmZXRjaCBkb21haW4gc2NoZWR1bGluZyBwYXJhbWV0ZXJzICovDQor
LyogU2V0IG9yIGZldGNoIGRvbWFpbiBzY2hlZHVsaW5nIHBhcmFtZXRlcnMgKi8NCiBzdGF0aWMg
aW50IHNlZGZfYWRqdXN0KGNvbnN0IHN0cnVjdCBzY2hlZHVsZXIgKm9wcywgc3RydWN0IGRvbWFp
biAqcCwgc3RydWN0IHhlbl9kb21jdGxfc2NoZWR1bGVyX29wICpvcCkNCiB7DQogICAgIHN0cnVj
dCB2Y3B1ICp2Ow0KICAgICBpbnQgcmM7DQogDQotICAgIFBSSU5UKDIsInNlZGZfYWRqdXN0IHdh
cyBjYWxsZWQsIGRvbWFpbi1pZCAlaSBuZXcgcGVyaW9kICUiUFJJdTY0IiAiDQotICAgICAgICAg
ICJuZXcgc2xpY2UgJSJQUkl1NjQiXG5sYXRlbmN5ICUiUFJJdTY0IiBleHRyYTolc1xuIiwNCi0g
ICAgICAgICAgcC0+ZG9tYWluX2lkLCBvcC0+dS5zZWRmLnBlcmlvZCwgb3AtPnUuc2VkZi5zbGlj
ZSwNCi0gICAgICAgICAgb3AtPnUuc2VkZi5sYXRlbmN5LCAob3AtPnUuc2VkZi5leHRyYXRpbWUp
PyJ5ZXMiOiJubyIpOw0KLQ0KICAgICBpZiAoIG9wLT5jbWQgPT0gWEVOX0RPTUNUTF9TQ0hFRE9Q
X3B1dGluZm8gKQ0KICAgICB7DQotICAgICAgICAvKiBDaGVjayBmb3Igc2FuZSBwYXJhbWV0ZXJz
LiAqLw0KKyAgICAgICAgLyogQ2hlY2sgZm9yIHNhbmUgcGFyYW1ldGVycyAqLw0KICAgICAgICAg
aWYgKCAhb3AtPnUuc2VkZi5wZXJpb2QgJiYgIW9wLT51LnNlZGYud2VpZ2h0ICkNCiAgICAgICAg
ICAgICByZXR1cm4gLUVJTlZBTDsNCiAgICAgICAgIGlmICggb3AtPnUuc2VkZi53ZWlnaHQgKQ0K
QEAgLTE0MTQsNyArMTMzNiw3IEBAIHN0YXRpYyBpbnQgc2VkZl9hZGp1c3QoY29uc3Qgc3RydWN0
IHNjaGUNCiAgICAgICAgICAgICBpZiAoIChvcC0+dS5zZWRmLmV4dHJhdGltZSAmIEVYVFJBX0FX
QVJFKSAmJg0KICAgICAgICAgICAgICAgICAgKCFvcC0+dS5zZWRmLnBlcmlvZCkgKQ0KICAgICAg
ICAgICAgIHsNCi0gICAgICAgICAgICAgICAgLyogV2VpZ2h0LWRyaXZlbiBkb21haW5zIHdpdGgg
ZXh0cmF0aW1lIG9ubHkuICovDQorICAgICAgICAgICAgICAgIC8qIFdlaWdodC1kcml2ZW4gZG9t
YWlucyB3aXRoIGV4dHJhdGltZSBvbmx5ICovDQogICAgICAgICAgICAgICAgIGZvcl9lYWNoX3Zj
cHUgKCBwLCB2ICkNCiAgICAgICAgICAgICAgICAgew0KICAgICAgICAgICAgICAgICAgICAgRURP
TV9JTkZPKHYpLT5leHRyYXdlaWdodCA9IG9wLT51LnNlZGYud2VpZ2h0Ow0KQEAgLTE0MjUsNyAr
MTM0Nyw3IEBAIHN0YXRpYyBpbnQgc2VkZl9hZGp1c3QoY29uc3Qgc3RydWN0IHNjaGUNCiAgICAg
ICAgICAgICB9DQogICAgICAgICAgICAgZWxzZQ0KICAgICAgICAgICAgIHsNCi0gICAgICAgICAg
ICAgICAgLyogV2VpZ2h0LWRyaXZlbiBkb21haW5zIHdpdGggcmVhbC10aW1lIGV4ZWN1dGlvbi4g
Ki8NCisgICAgICAgICAgICAgICAgLyogV2VpZ2h0LWRyaXZlbiBkb21haW5zIHdpdGggcmVhbC10
aW1lIGV4ZWN1dGlvbiAqLw0KICAgICAgICAgICAgICAgICBmb3JfZWFjaF92Y3B1ICggcCwgdiAp
DQogICAgICAgICAgICAgICAgICAgICBFRE9NX0lORk8odiktPndlaWdodCA9IG9wLT51LnNlZGYu
d2VpZ2h0Ow0KICAgICAgICAgICAgIH0NCkBAIC0xNDM1LDggKzEzNTcsNyBAQCBzdGF0aWMgaW50
IHNlZGZfYWRqdXN0KGNvbnN0IHN0cnVjdCBzY2hlDQogICAgICAgICAgICAgLyogVGltZS1kcml2
ZW4gZG9tYWlucy4gKi8NCiAgICAgICAgICAgICBmb3JfZWFjaF92Y3B1ICggcCwgdiApDQogICAg
ICAgICAgICAgew0KLSAgICAgICAgICAgICAgICAvKg0KLSAgICAgICAgICAgICAgICAgKiBTYW5p
dHkgY2hlY2tpbmc6IG5vdGUgdGhhdCBkaXNhYmxpbmcgZXh0cmEgd2VpZ2h0IHJlcXVpcmVzDQor
ICAgICAgICAgICAgICAgIC8qIFNhbml0eSBjaGVja2luZzogbm90ZSB0aGF0IGRpc2FibGluZyBl
eHRyYSB3ZWlnaHQgcmVxdWlyZXMNCiAgICAgICAgICAgICAgICAgICogdGhhdCB3ZSBzZXQgYSBu
b24temVybyBzbGljZS4NCiAgICAgICAgICAgICAgICAgICovDQogICAgICAgICAgICAgICAgIGlm
ICggKG9wLT51LnNlZGYucGVyaW9kID4gUEVSSU9EX01BWCkgfHwNCkBAIC0xNDc3LDcgKzEzOTgs
NiBAQCBzdGF0aWMgaW50IHNlZGZfYWRqdXN0KGNvbnN0IHN0cnVjdCBzY2hlDQogICAgICAgICBv
cC0+dS5zZWRmLndlaWdodCAgICA9IEVET01fSU5GTyhwLT52Y3B1WzBdKS0+d2VpZ2h0Ow0KICAg
ICB9DQogDQotICAgIFBSSU5UKDIsInNlZGZfYWRqdXN0X2ZpbmlzaGVkXG4iKTsNCiAgICAgcmV0
dXJuIDA7DQogfQ0KIA0K


--=-3p5/0djGq6n5G1gGRftX--

--=-4GhoPkvT2knwTpwLdibp
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEABECAAYFAk7wyjgACgkQk4XaBE3IOsR/vACgqGtZKPaaw+mk+E5KLy5ydkVO
0dgAn2xbXZ2l2w6UXsUeFgUEefZ0Zm8r
=lJaO
-----END PGP SIGNATURE-----

--=-4GhoPkvT2knwTpwLdibp--



--===============4953755209351780878==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============4953755209351780878==--



From xen-devel-bounces@lists.xensource.com Tue Dec 20 17:55:54 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 Dec 2011 17:55:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rd3uV-00051F-Ut; Tue, 20 Dec 2011 17:55:31 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1Rd3uU-000518-4c
	for xen-devel@lists.xensource.com; Tue, 20 Dec 2011 17:55:30 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1324403721!723311!1
X-Originating-IP: [209.85.160.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9315 invoked from network); 20 Dec 2011 17:55:23 -0000
Received: from mail-pw0-f43.google.com (HELO mail-pw0-f43.google.com)
	(209.85.160.43)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Dec 2011 17:55:23 -0000
Received: by pbbb11 with SMTP id b11so22639251pbb.30
	for <xen-devel@lists.xensource.com>;
	Tue, 20 Dec 2011 09:55:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=fvJ/lhKzKdCETpO887o+NE0xEGKa/QKLnDPDtB86QmI=;
	b=A5vbiOuG+k04AdSkCIosEfqEVc5JiPJreWun4BPD3uVIAhnDB2zurHzHxpdvwIQaNP
	efscEzpk9tFaNSODJY8I3HfSs4HIpLBgVw4EK386bxVwgvKdhf8oV/bVX8KzdO89KC9F
	IZ0r2O2UqLgWRzPoIwGisXVd/4QfwxVG4T0x0=
MIME-Version: 1.0
Received: by 10.68.189.133 with SMTP id gi5mr4838777pbc.27.1324403721296; Tue,
	20 Dec 2011 09:55:21 -0800 (PST)
Received: by 10.142.47.17 with HTTP; Tue, 20 Dec 2011 09:55:21 -0800 (PST)
In-Reply-To: <CAPLaKK4xpN5Ro6medFjwBmg9zjs2pYHThmgP=NvdoJt+N=t1rA@mail.gmail.com>
References: <patchbomb.1324212500@alpine.localdomain>
	<c0d5aa328f1ab24aad58.1324212503@alpine.localdomain>
	<CA+T2pCE_L0Gfyb0xu4=bd-yCAz=+Z_4Ugyd-EoO4m=+jz5MPGA@mail.gmail.com>
	<CAPLaKK5gYZ+KDsJW4+FSkP=nqDJmaO3W72pfkbg8m25fYu+_1Q@mail.gmail.com>
	<1324301203.9236.40.camel@zakaz.uk.xensource.com>
	<CAPLaKK6NhoXTiaFWb9aTcuapaqtNVcKo==7=xXP8wf5N66kFUw@mail.gmail.com>
	<1324302182.9236.51.camel@zakaz.uk.xensource.com>
	<CAPLaKK4xpN5Ro6medFjwBmg9zjs2pYHThmgP=NvdoJt+N=t1rA@mail.gmail.com>
Date: Tue, 20 Dec 2011 18:55:21 +0100
X-Google-Sender-Auth: V41BKxxbtHjzq4xjN39QL7L3GfI
Message-ID: <CAPLaKK4TSzGoD2CGW1ubnqLcSfDCu5CFe6OAVFud446JyOcXtw@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: William Pitcock <nenolod@dereferenced.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 3 of 5] blktap2: fix vhd compilation under
	uclibc
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hello,

I've added -liconv to blktap2/vhd/lib, and succesfully compiled and
linked the library. The output from ldd libvhd.so shows:

checking sub-depends for '/lib/libuuid.so.1'
checking sub-depends for '/usr/lib/libiconv.so.2'
checking sub-depends for '/lib/libc.so.0.9.32'
checking sub-depends for '/lib/ld64-uClibc.so.0.9.32'
	libuuid.so.1 => /lib/libuuid.so.1 (0x00000000)
	libiconv.so.2 => /usr/lib/libiconv.so.2 (0x00000000)
	libc.so.0.9.32 => /lib/libc.so.0.9.32 (0x00000000)
	ld64-uClibc.so.0.9.32 => /lib/ld64-uClibc.so.0.9.32 (0x00000000)
	not a dynamic executable

Then I've compiled and linked vhd tools (vhd-util and vhd-update)
without -liconv, since vhd tools doesn't use any iconv functions. They
compile fine, but when I try to execute them I get the following
error:

vhd-util: symbol 'libiconv_open': can't resolve symbol

If I do a ldd of vhd-util:

	libvhd.so.1.0 => /usr/lib/libvhd.so.1.0 (0x7699efaf4000)
	libc.so.0.9.32 => /lib/libc.so.0.9.32 (0x7699ef88c000)
	libuuid.so.1 => /lib/libuuid.so.1 (0x7699ef689000)
	ld64-uClibc.so.0.9.32 => /lib/ld64-uClibc.so.0.9.32 (0x7699efd10000)

How come libiconv is not linked to the application if libvhd is? And
what's most strange, why is the link to libuuid keep, but not the one
to libiconv?

Thanks, Roger.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 20 17:55:54 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 Dec 2011 17:55:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rd3uV-00051F-Ut; Tue, 20 Dec 2011 17:55:31 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1Rd3uU-000518-4c
	for xen-devel@lists.xensource.com; Tue, 20 Dec 2011 17:55:30 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1324403721!723311!1
X-Originating-IP: [209.85.160.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9315 invoked from network); 20 Dec 2011 17:55:23 -0000
Received: from mail-pw0-f43.google.com (HELO mail-pw0-f43.google.com)
	(209.85.160.43)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Dec 2011 17:55:23 -0000
Received: by pbbb11 with SMTP id b11so22639251pbb.30
	for <xen-devel@lists.xensource.com>;
	Tue, 20 Dec 2011 09:55:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=fvJ/lhKzKdCETpO887o+NE0xEGKa/QKLnDPDtB86QmI=;
	b=A5vbiOuG+k04AdSkCIosEfqEVc5JiPJreWun4BPD3uVIAhnDB2zurHzHxpdvwIQaNP
	efscEzpk9tFaNSODJY8I3HfSs4HIpLBgVw4EK386bxVwgvKdhf8oV/bVX8KzdO89KC9F
	IZ0r2O2UqLgWRzPoIwGisXVd/4QfwxVG4T0x0=
MIME-Version: 1.0
Received: by 10.68.189.133 with SMTP id gi5mr4838777pbc.27.1324403721296; Tue,
	20 Dec 2011 09:55:21 -0800 (PST)
Received: by 10.142.47.17 with HTTP; Tue, 20 Dec 2011 09:55:21 -0800 (PST)
In-Reply-To: <CAPLaKK4xpN5Ro6medFjwBmg9zjs2pYHThmgP=NvdoJt+N=t1rA@mail.gmail.com>
References: <patchbomb.1324212500@alpine.localdomain>
	<c0d5aa328f1ab24aad58.1324212503@alpine.localdomain>
	<CA+T2pCE_L0Gfyb0xu4=bd-yCAz=+Z_4Ugyd-EoO4m=+jz5MPGA@mail.gmail.com>
	<CAPLaKK5gYZ+KDsJW4+FSkP=nqDJmaO3W72pfkbg8m25fYu+_1Q@mail.gmail.com>
	<1324301203.9236.40.camel@zakaz.uk.xensource.com>
	<CAPLaKK6NhoXTiaFWb9aTcuapaqtNVcKo==7=xXP8wf5N66kFUw@mail.gmail.com>
	<1324302182.9236.51.camel@zakaz.uk.xensource.com>
	<CAPLaKK4xpN5Ro6medFjwBmg9zjs2pYHThmgP=NvdoJt+N=t1rA@mail.gmail.com>
Date: Tue, 20 Dec 2011 18:55:21 +0100
X-Google-Sender-Auth: V41BKxxbtHjzq4xjN39QL7L3GfI
Message-ID: <CAPLaKK4TSzGoD2CGW1ubnqLcSfDCu5CFe6OAVFud446JyOcXtw@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: William Pitcock <nenolod@dereferenced.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 3 of 5] blktap2: fix vhd compilation under
	uclibc
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hello,

I've added -liconv to blktap2/vhd/lib, and succesfully compiled and
linked the library. The output from ldd libvhd.so shows:

checking sub-depends for '/lib/libuuid.so.1'
checking sub-depends for '/usr/lib/libiconv.so.2'
checking sub-depends for '/lib/libc.so.0.9.32'
checking sub-depends for '/lib/ld64-uClibc.so.0.9.32'
	libuuid.so.1 => /lib/libuuid.so.1 (0x00000000)
	libiconv.so.2 => /usr/lib/libiconv.so.2 (0x00000000)
	libc.so.0.9.32 => /lib/libc.so.0.9.32 (0x00000000)
	ld64-uClibc.so.0.9.32 => /lib/ld64-uClibc.so.0.9.32 (0x00000000)
	not a dynamic executable

Then I've compiled and linked vhd tools (vhd-util and vhd-update)
without -liconv, since vhd tools doesn't use any iconv functions. They
compile fine, but when I try to execute them I get the following
error:

vhd-util: symbol 'libiconv_open': can't resolve symbol

If I do a ldd of vhd-util:

	libvhd.so.1.0 => /usr/lib/libvhd.so.1.0 (0x7699efaf4000)
	libc.so.0.9.32 => /lib/libc.so.0.9.32 (0x7699ef88c000)
	libuuid.so.1 => /lib/libuuid.so.1 (0x7699ef689000)
	ld64-uClibc.so.0.9.32 => /lib/ld64-uClibc.so.0.9.32 (0x7699efd10000)

How come libiconv is not linked to the application if libvhd is? And
what's most strange, why is the link to libuuid keep, but not the one
to libiconv?

Thanks, Roger.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 20 18:04:06 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 Dec 2011 18:04:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rd42V-0005GS-0V; Tue, 20 Dec 2011 18:03:47 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Rd42T-0005GN-OS
	for xen-devel@lists.xensource.com; Tue, 20 Dec 2011 18:03:45 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1324404219!2266081!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzQwMQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31844 invoked from network); 20 Dec 2011 18:03:40 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Dec 2011 18:03:40 -0000
X-IronPort-AV: E=Sophos;i="4.71,383,1320624000"; 
   d="scan'208";a="9589456"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Dec 2011 18:02:37 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 20 Dec 2011 18:02:36 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Rd41M-0005Eh-IN; Tue, 20 Dec 2011 18:02:36 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rd41M-0007AF-Gr;
	Tue, 20 Dec 2011 18:02:36 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20208.52668.490134.650939@mariner.uk.xensource.com>
Date: Tue, 20 Dec 2011 18:02:36 +0000
To: Roger Pau Monne <roger.pau@entel.upc.edu>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <c54c326d6fdf26d311c8.1324212502@alpine.localdomain>
References: <patchbomb.1324212500@alpine.localdomain>
	<c54c326d6fdf26d311c8.1324212502@alpine.localdomain>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 2 of 5] build: detect uclibc
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Roger Pau Monne writes ("[Xen-devel] [PATCH 2 of 5] build: detect uclibc"):
> build: detect uclibc
> 
> Detect uclibc build environment and define CONFIG_UCLIBC accordingly.

I'm not a huge fan of this configuration approach, particularly for a
variant libc.  Rather, we should use portable constructs.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 20 18:04:06 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 Dec 2011 18:04:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rd42V-0005GS-0V; Tue, 20 Dec 2011 18:03:47 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Rd42T-0005GN-OS
	for xen-devel@lists.xensource.com; Tue, 20 Dec 2011 18:03:45 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1324404219!2266081!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzQwMQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31844 invoked from network); 20 Dec 2011 18:03:40 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Dec 2011 18:03:40 -0000
X-IronPort-AV: E=Sophos;i="4.71,383,1320624000"; 
   d="scan'208";a="9589456"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Dec 2011 18:02:37 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 20 Dec 2011 18:02:36 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Rd41M-0005Eh-IN; Tue, 20 Dec 2011 18:02:36 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rd41M-0007AF-Gr;
	Tue, 20 Dec 2011 18:02:36 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20208.52668.490134.650939@mariner.uk.xensource.com>
Date: Tue, 20 Dec 2011 18:02:36 +0000
To: Roger Pau Monne <roger.pau@entel.upc.edu>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <c54c326d6fdf26d311c8.1324212502@alpine.localdomain>
References: <patchbomb.1324212500@alpine.localdomain>
	<c54c326d6fdf26d311c8.1324212502@alpine.localdomain>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 2 of 5] build: detect uclibc
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Roger Pau Monne writes ("[Xen-devel] [PATCH 2 of 5] build: detect uclibc"):
> build: detect uclibc
> 
> Detect uclibc build environment and define CONFIG_UCLIBC accordingly.

I'm not a huge fan of this configuration approach, particularly for a
variant libc.  Rather, we should use portable constructs.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 20 18:13:50 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 Dec 2011 18: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.xensource.com>)
	id 1Rd4Bt-0005WH-3I; Tue, 20 Dec 2011 18:13:29 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Rd4Br-0005WC-Cw
	for xen-devel@lists.xensource.com; Tue, 20 Dec 2011 18:13:27 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1324404799!8042094!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDUxNDAx\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3456 invoked from network); 20 Dec 2011 18:13:21 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-2.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 20 Dec 2011 18:13:21 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pBKICRTW018577
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 20 Dec 2011 18:12:27 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pBKICN1G026921
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 20 Dec 2011 18:12:24 GMT
Received: from abhmt118.oracle.com (abhmt118.oracle.com [141.146.116.70])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pBKICM90027892; Tue, 20 Dec 2011 12:12:22 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 20 Dec 2011 10:12:22 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 050F640068; Tue, 20 Dec 2011 13:11:23 -0500 (EST)
Date: Tue, 20 Dec 2011 13:11:22 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Adin Scannell <adin@scannell.ca>
Message-ID: <20111220181122.GA7152@phenom.dumpdata.com>
References: <1324363013-11031-1-git-send-email-adin@scannell.ca>
	<1324363013-11031-4-git-send-email-adin@scannell.ca>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1324363013-11031-4-git-send-email-adin@scannell.ca>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090203.4EF0D00D.0057,ss=1,re=0.000,fgs=0
Cc: olaf@aepfle.de, xen-devel@lists.xensource.com, andres@gridcentric.ca,
	linux-kernel@vger.kernel.org, JBeulich@suse.com,
	konrad@darnok.org, adin@gridcentric.com
Subject: Re: [Xen-devel] [PATCH 3/3] Port of mmap_batch_v2 to support paging
	in Xen
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Dec 20, 2011 at 01:36:53AM -0500, Adin Scannell wrote:
> This wasn't ported from any patch, but was rewritten based on the XCP 2.6.32
> tree.  The code structure is significantly different and this patch mirrors the
> existing Linux code.
> 
> An important reason to add the V2 interface is to support foreign mappings
> (i.e.  qemu-dm) of paged-out pages.  The kernel generally has to do nothing
> beyond implementing this ioctl in order to provide this support.  The V2
> interface is needed only to pass back full error codes from the mmu_update()'s.
> Xen and libxc have a mutual understanding that when you receive an ENOENT error
> code, you back off and try again. The libxc code will already retry mappings
> when an ENOENT is returned.

Can you say what is the difference between V1 and V2? It looks to be just
that V2 adds an array of return values and not overloading the array of
MFNs with the "top nibble for set on err".

> 
> The only exception to the above case is backend drivers using grant operations.
> To support paging, these drivers must appropriately retry grant operations when
> they receive an EAGAIN error code.  This is implemented in a separate patch.

patches. You need one for netback and one for blkback b/c they go to different
maintainers.

> 
> Signed-off-by: Adin Scannell <adin@scannell.ca>
> ---
>  drivers/xen/privcmd.c |   90 +++++++++++++++++++++++++++++++++++++++++++++++++
>  include/xen/privcmd.h |   10 +++++
>  2 files changed, 100 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
> index 161681f..dd77d5c 100644
> --- a/drivers/xen/privcmd.c
> +++ b/drivers/xen/privcmd.c
> @@ -251,6 +251,15 @@ struct mmap_batch_state {
>  	xen_pfn_t __user *user;
>  };
>  
> +struct mmap_batch_v2_state {
> +	domid_t domain;
> +	unsigned long va;
> +	struct vm_area_struct *vma;
> +	unsigned long paged_out;
> +
> +	int __user *err;

The more I look at this along with the previous structure (struct mmap_batch_state)
they more they look like they could be squashed together.

The two differences are the 'paged_out' and *user. You could sqush them
together and use an union to carry those two. 

And then also make the mmap_batch_fn and mmap_batch_v2_fn be almost the
same and unify those two (in a seperate patch of course).

> +};
> +
>  static int mmap_batch_fn(void *data, void *state)
>  {
>  	xen_pfn_t *mfnp = data;
> @@ -268,6 +277,22 @@ static int mmap_batch_fn(void *data, void *state)
>  	return 0;
>  }
>  
> +static int mmap_batch_v2_fn(void *data, void *state)
> +{
> +	xen_pfn_t *mfnp = data;
> +	struct mmap_batch_v2_state *st = state;
> +
> +	BUG_ON(st == NULL || st->vma == NULL);
> +
> +	int rc = xen_remap_domain_mfn_range(st->vma, st->va & PAGE_MASK, *mfnp,
> +				       1, st->vma->vm_page_prot, st->domain);
> +	if (rc == -ENOENT)
> +		st->paged_out++;
> +	st->va += PAGE_SIZE;
> +
> +	return put_user(rc, st->err++);
> +}
> +
>  static int mmap_return_errors(void *data, void *state)
>  {
>  	xen_pfn_t *mfnp = data;
> @@ -340,6 +365,67 @@ out:
>  	return ret;
>  }
>  
> +static long privcmd_ioctl_mmap_batch_v2(void __user *udata)
> +{
> +	int ret;
> +	struct privcmd_mmapbatch_v2 m;
> +	struct mm_struct *mm = current->mm;
> +	struct vm_area_struct *vma = NULL;
> +	unsigned long nr_pages;
> +	LIST_HEAD(pagelist);
> +	struct mmap_batch_v2_state state;
> +
> +	if (!xen_initial_domain())
> +		return -EPERM;
> +
> +	if (copy_from_user(&m, udata, sizeof(m)))
> +		return -EFAULT;
> +
> +	nr_pages = m.num;
> +	if ((m.num <= 0) || (nr_pages > (ULONG_MAX >> PAGE_SHIFT)))
> +		return -EINVAL;
> +
> +	ret = gather_array(&pagelist, m.num, sizeof(xen_pfn_t),
> +			   m.arr);
> +
> +	if (ret || list_empty(&pagelist))
> +		goto out;
> +
> +	down_write(&mm->mmap_sem);
> +
> +	vma = find_vma(mm, m.addr);
> +	ret = -EINVAL;
> +	/* We allow multiple shots here, because this interface
> +	 * is used by libxc and mappings for specific pages will
> +	 * be retried when pages are paged-out (ENOENT). */
> +	if (!vma ||
> +	    vma->vm_ops != &privcmd_vm_ops ||
> +	    (m.addr < vma->vm_start) ||
> +	    ((m.addr + (nr_pages << PAGE_SHIFT)) > vma->vm_end)) {
> +		up_write(&mm->mmap_sem);
> +		goto out;
> +	}
> +
> +	state.domain = m.dom;
> +	state.vma = vma;
> +	state.va = m.addr;
> +	state.err = m.err;
> +	state.paged_out = 0;
> +
> +	up_write(&mm->mmap_sem);
> +
> +	ret = traverse_pages(m.num, sizeof(xen_pfn_t),
> +			     &pagelist, mmap_batch_v2_fn, &state);
> +
> +out:
> +	free_page_list(&pagelist);
> +
> +	if ((ret == 0) && (state.paged_out > 0))
> +		return -ENOENT;
> +	else
> +		return ret;
> +}
> +

This looks so similar to the the v1 version. Can you extract the generic
parts of privcmd_ioctl_mmap_batch out to a function and just use the
_v1 and _v2 for .. well the things that they differ with?

>  static long privcmd_ioctl(struct file *file,
>  			  unsigned int cmd, unsigned long data)
>  {
> @@ -359,6 +445,10 @@ static long privcmd_ioctl(struct file *file,
>  		ret = privcmd_ioctl_mmap_batch(udata);
>  		break;
>  
> +	case IOCTL_PRIVCMD_MMAPBATCH_V2:
> +		ret = privcmd_ioctl_mmap_batch_v2(udata);
> +		break;
> +
>  	default:
>  		ret = -EINVAL;
>  		break;
> diff --git a/include/xen/privcmd.h b/include/xen/privcmd.h
> index 17857fb..39b92b1 100644
> --- a/include/xen/privcmd.h
> +++ b/include/xen/privcmd.h
> @@ -62,6 +62,14 @@ struct privcmd_mmapbatch {
>  	xen_pfn_t __user *arr; /* array of mfns - top nibble set on err */
>  };
>  
> +struct privcmd_mmapbatch_v2 {
> +	int num;          /* number of pages to populate */
> +	domid_t dom;      /* target domain */
> +	__u64 addr;       /* virtual address */
> +	const xen_pfn_t __user *arr; /* array of mfns */
> +	int __user *err;  /* array of error codes */
> +};
> +
>  /*
>   * @cmd: IOCTL_PRIVCMD_HYPERCALL
>   * @arg: &privcmd_hypercall_t
> @@ -73,5 +81,7 @@ struct privcmd_mmapbatch {
>  	_IOC(_IOC_NONE, 'P', 2, sizeof(struct privcmd_mmap))
>  #define IOCTL_PRIVCMD_MMAPBATCH					\
>  	_IOC(_IOC_NONE, 'P', 3, sizeof(struct privcmd_mmapbatch))
> +#define IOCTL_PRIVCMD_MMAPBATCH_V2				\
> +	_IOC(_IOC_NONE, 'P', 4, sizeof(struct privcmd_mmapbatch_v2))
>  
>  #endif /* __LINUX_PUBLIC_PRIVCMD_H__ */
> -- 
> 1.6.2.5
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 20 18:13:50 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 Dec 2011 18: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.xensource.com>)
	id 1Rd4Bt-0005WH-3I; Tue, 20 Dec 2011 18:13:29 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Rd4Br-0005WC-Cw
	for xen-devel@lists.xensource.com; Tue, 20 Dec 2011 18:13:27 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1324404799!8042094!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDUxNDAx\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3456 invoked from network); 20 Dec 2011 18:13:21 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-2.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 20 Dec 2011 18:13:21 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pBKICRTW018577
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 20 Dec 2011 18:12:27 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pBKICN1G026921
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 20 Dec 2011 18:12:24 GMT
Received: from abhmt118.oracle.com (abhmt118.oracle.com [141.146.116.70])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pBKICM90027892; Tue, 20 Dec 2011 12:12:22 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 20 Dec 2011 10:12:22 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 050F640068; Tue, 20 Dec 2011 13:11:23 -0500 (EST)
Date: Tue, 20 Dec 2011 13:11:22 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Adin Scannell <adin@scannell.ca>
Message-ID: <20111220181122.GA7152@phenom.dumpdata.com>
References: <1324363013-11031-1-git-send-email-adin@scannell.ca>
	<1324363013-11031-4-git-send-email-adin@scannell.ca>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1324363013-11031-4-git-send-email-adin@scannell.ca>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090203.4EF0D00D.0057,ss=1,re=0.000,fgs=0
Cc: olaf@aepfle.de, xen-devel@lists.xensource.com, andres@gridcentric.ca,
	linux-kernel@vger.kernel.org, JBeulich@suse.com,
	konrad@darnok.org, adin@gridcentric.com
Subject: Re: [Xen-devel] [PATCH 3/3] Port of mmap_batch_v2 to support paging
	in Xen
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Dec 20, 2011 at 01:36:53AM -0500, Adin Scannell wrote:
> This wasn't ported from any patch, but was rewritten based on the XCP 2.6.32
> tree.  The code structure is significantly different and this patch mirrors the
> existing Linux code.
> 
> An important reason to add the V2 interface is to support foreign mappings
> (i.e.  qemu-dm) of paged-out pages.  The kernel generally has to do nothing
> beyond implementing this ioctl in order to provide this support.  The V2
> interface is needed only to pass back full error codes from the mmu_update()'s.
> Xen and libxc have a mutual understanding that when you receive an ENOENT error
> code, you back off and try again. The libxc code will already retry mappings
> when an ENOENT is returned.

Can you say what is the difference between V1 and V2? It looks to be just
that V2 adds an array of return values and not overloading the array of
MFNs with the "top nibble for set on err".

> 
> The only exception to the above case is backend drivers using grant operations.
> To support paging, these drivers must appropriately retry grant operations when
> they receive an EAGAIN error code.  This is implemented in a separate patch.

patches. You need one for netback and one for blkback b/c they go to different
maintainers.

> 
> Signed-off-by: Adin Scannell <adin@scannell.ca>
> ---
>  drivers/xen/privcmd.c |   90 +++++++++++++++++++++++++++++++++++++++++++++++++
>  include/xen/privcmd.h |   10 +++++
>  2 files changed, 100 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
> index 161681f..dd77d5c 100644
> --- a/drivers/xen/privcmd.c
> +++ b/drivers/xen/privcmd.c
> @@ -251,6 +251,15 @@ struct mmap_batch_state {
>  	xen_pfn_t __user *user;
>  };
>  
> +struct mmap_batch_v2_state {
> +	domid_t domain;
> +	unsigned long va;
> +	struct vm_area_struct *vma;
> +	unsigned long paged_out;
> +
> +	int __user *err;

The more I look at this along with the previous structure (struct mmap_batch_state)
they more they look like they could be squashed together.

The two differences are the 'paged_out' and *user. You could sqush them
together and use an union to carry those two. 

And then also make the mmap_batch_fn and mmap_batch_v2_fn be almost the
same and unify those two (in a seperate patch of course).

> +};
> +
>  static int mmap_batch_fn(void *data, void *state)
>  {
>  	xen_pfn_t *mfnp = data;
> @@ -268,6 +277,22 @@ static int mmap_batch_fn(void *data, void *state)
>  	return 0;
>  }
>  
> +static int mmap_batch_v2_fn(void *data, void *state)
> +{
> +	xen_pfn_t *mfnp = data;
> +	struct mmap_batch_v2_state *st = state;
> +
> +	BUG_ON(st == NULL || st->vma == NULL);
> +
> +	int rc = xen_remap_domain_mfn_range(st->vma, st->va & PAGE_MASK, *mfnp,
> +				       1, st->vma->vm_page_prot, st->domain);
> +	if (rc == -ENOENT)
> +		st->paged_out++;
> +	st->va += PAGE_SIZE;
> +
> +	return put_user(rc, st->err++);
> +}
> +
>  static int mmap_return_errors(void *data, void *state)
>  {
>  	xen_pfn_t *mfnp = data;
> @@ -340,6 +365,67 @@ out:
>  	return ret;
>  }
>  
> +static long privcmd_ioctl_mmap_batch_v2(void __user *udata)
> +{
> +	int ret;
> +	struct privcmd_mmapbatch_v2 m;
> +	struct mm_struct *mm = current->mm;
> +	struct vm_area_struct *vma = NULL;
> +	unsigned long nr_pages;
> +	LIST_HEAD(pagelist);
> +	struct mmap_batch_v2_state state;
> +
> +	if (!xen_initial_domain())
> +		return -EPERM;
> +
> +	if (copy_from_user(&m, udata, sizeof(m)))
> +		return -EFAULT;
> +
> +	nr_pages = m.num;
> +	if ((m.num <= 0) || (nr_pages > (ULONG_MAX >> PAGE_SHIFT)))
> +		return -EINVAL;
> +
> +	ret = gather_array(&pagelist, m.num, sizeof(xen_pfn_t),
> +			   m.arr);
> +
> +	if (ret || list_empty(&pagelist))
> +		goto out;
> +
> +	down_write(&mm->mmap_sem);
> +
> +	vma = find_vma(mm, m.addr);
> +	ret = -EINVAL;
> +	/* We allow multiple shots here, because this interface
> +	 * is used by libxc and mappings for specific pages will
> +	 * be retried when pages are paged-out (ENOENT). */
> +	if (!vma ||
> +	    vma->vm_ops != &privcmd_vm_ops ||
> +	    (m.addr < vma->vm_start) ||
> +	    ((m.addr + (nr_pages << PAGE_SHIFT)) > vma->vm_end)) {
> +		up_write(&mm->mmap_sem);
> +		goto out;
> +	}
> +
> +	state.domain = m.dom;
> +	state.vma = vma;
> +	state.va = m.addr;
> +	state.err = m.err;
> +	state.paged_out = 0;
> +
> +	up_write(&mm->mmap_sem);
> +
> +	ret = traverse_pages(m.num, sizeof(xen_pfn_t),
> +			     &pagelist, mmap_batch_v2_fn, &state);
> +
> +out:
> +	free_page_list(&pagelist);
> +
> +	if ((ret == 0) && (state.paged_out > 0))
> +		return -ENOENT;
> +	else
> +		return ret;
> +}
> +

This looks so similar to the the v1 version. Can you extract the generic
parts of privcmd_ioctl_mmap_batch out to a function and just use the
_v1 and _v2 for .. well the things that they differ with?

>  static long privcmd_ioctl(struct file *file,
>  			  unsigned int cmd, unsigned long data)
>  {
> @@ -359,6 +445,10 @@ static long privcmd_ioctl(struct file *file,
>  		ret = privcmd_ioctl_mmap_batch(udata);
>  		break;
>  
> +	case IOCTL_PRIVCMD_MMAPBATCH_V2:
> +		ret = privcmd_ioctl_mmap_batch_v2(udata);
> +		break;
> +
>  	default:
>  		ret = -EINVAL;
>  		break;
> diff --git a/include/xen/privcmd.h b/include/xen/privcmd.h
> index 17857fb..39b92b1 100644
> --- a/include/xen/privcmd.h
> +++ b/include/xen/privcmd.h
> @@ -62,6 +62,14 @@ struct privcmd_mmapbatch {
>  	xen_pfn_t __user *arr; /* array of mfns - top nibble set on err */
>  };
>  
> +struct privcmd_mmapbatch_v2 {
> +	int num;          /* number of pages to populate */
> +	domid_t dom;      /* target domain */
> +	__u64 addr;       /* virtual address */
> +	const xen_pfn_t __user *arr; /* array of mfns */
> +	int __user *err;  /* array of error codes */
> +};
> +
>  /*
>   * @cmd: IOCTL_PRIVCMD_HYPERCALL
>   * @arg: &privcmd_hypercall_t
> @@ -73,5 +81,7 @@ struct privcmd_mmapbatch {
>  	_IOC(_IOC_NONE, 'P', 2, sizeof(struct privcmd_mmap))
>  #define IOCTL_PRIVCMD_MMAPBATCH					\
>  	_IOC(_IOC_NONE, 'P', 3, sizeof(struct privcmd_mmapbatch))
> +#define IOCTL_PRIVCMD_MMAPBATCH_V2				\
> +	_IOC(_IOC_NONE, 'P', 4, sizeof(struct privcmd_mmapbatch_v2))
>  
>  #endif /* __LINUX_PUBLIC_PRIVCMD_H__ */
> -- 
> 1.6.2.5
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 20 18:14:09 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 Dec 2011 18: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.xensource.com>)
	id 1Rd4CD-0005XG-Gm; Tue, 20 Dec 2011 18:13:49 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Rd4CC-0005Wq-4H
	for xen-devel@lists.xensource.com; Tue, 20 Dec 2011 18:13:48 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1324404821!8186574!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzQwMQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7822 invoked from network); 20 Dec 2011 18:13:42 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Dec 2011 18:13:42 -0000
X-IronPort-AV: E=Sophos;i="4.71,383,1320624000"; 
   d="scan'208";a="9589793"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Dec 2011 18:13:41 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 20 Dec 2011 18:13:41 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Rd4C4-0005Ge-Rs; Tue, 20 Dec 2011 18:13:40 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rd4C4-0007Ko-Ql;
	Tue, 20 Dec 2011 18:13:40 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20208.53332.666709.138097@mariner.uk.xensource.com>
Date: Tue, 20 Dec 2011 18:13:40 +0000
To: Roger Pau Monne <roger.pau@entel.upc.edu>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <patchbomb.1323971891@loki.upc.es>
References: <patchbomb.1323971891@loki.upc.es>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 0 of 6 ACKED v5] libxl: add support for
 hotplug script calling from libxl
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Roger Pau Monne writes ("[Xen-devel] [PATCH 0 of 6 ACKED v5] libxl: add support for hotplug script calling from libxl"):
> Previously acked patches from the series.

Applied all six, thanks.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 20 18:14:09 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 Dec 2011 18: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.xensource.com>)
	id 1Rd4CD-0005XG-Gm; Tue, 20 Dec 2011 18:13:49 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Rd4CC-0005Wq-4H
	for xen-devel@lists.xensource.com; Tue, 20 Dec 2011 18:13:48 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1324404821!8186574!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzQwMQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7822 invoked from network); 20 Dec 2011 18:13:42 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Dec 2011 18:13:42 -0000
X-IronPort-AV: E=Sophos;i="4.71,383,1320624000"; 
   d="scan'208";a="9589793"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Dec 2011 18:13:41 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 20 Dec 2011 18:13:41 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Rd4C4-0005Ge-Rs; Tue, 20 Dec 2011 18:13:40 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rd4C4-0007Ko-Ql;
	Tue, 20 Dec 2011 18:13:40 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20208.53332.666709.138097@mariner.uk.xensource.com>
Date: Tue, 20 Dec 2011 18:13:40 +0000
To: Roger Pau Monne <roger.pau@entel.upc.edu>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <patchbomb.1323971891@loki.upc.es>
References: <patchbomb.1323971891@loki.upc.es>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 0 of 6 ACKED v5] libxl: add support for
 hotplug script calling from libxl
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Roger Pau Monne writes ("[Xen-devel] [PATCH 0 of 6 ACKED v5] libxl: add support for hotplug script calling from libxl"):
> Previously acked patches from the series.

Applied all six, thanks.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 20 18:15:46 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 Dec 2011 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.xensource.com>)
	id 1Rd4Dn-0005fL-0i; Tue, 20 Dec 2011 18:15:27 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Rd4Dl-0005f2-Uo
	for xen-devel@lists.xensource.com; Tue, 20 Dec 2011 18:15:26 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1324404919!6311729!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzQwMQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9688 invoked from network); 20 Dec 2011 18:15:19 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Dec 2011 18:15:19 -0000
X-IronPort-AV: E=Sophos;i="4.71,383,1320624000"; 
   d="scan'208";a="9589871"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Dec 2011 18:15:19 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 20 Dec 2011 18:15:19 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Rd4Df-0005Gv-1f; Tue, 20 Dec 2011 18:15:19 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rd4Df-0007MR-0l;
	Tue, 20 Dec 2011 18:15:19 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20208.53431.9104.857044@mariner.uk.xensource.com>
Date: Tue, 20 Dec 2011 18:15:19 +0000
To: Anthony PERARD <anthony.perard@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1324031825.20077.562.camel@zakaz.uk.xensource.com>,
	<alpine.DEB.2.00.1112201512040.21175@perard.uk.xensource.com>
References: <64e48ae2ef6760db221f.1323796155@cosworth.uk.xensource.com>
	<20202.10169.101830.45527@mariner.uk.xensource.com>
	<1324031825.20077.562.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1112201512040.21175@perard.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] libxl: improve error handling when saving
 device model state [and 1 more messages]
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("Re: [Xen-devel] [PATCH] libxl: improve error handling when saving device model state"):
> On Thu, 2011-12-15 at 17:00 +0000, Ian Jackson wrote:
> > Ian Campbell writes ("[Xen-devel] [PATCH] libxl: improve error handling when saving device model state"):
> > And always unlinking the filename is fine, surely ?
> 
> Yes. Patch is below.
> 
> In principal it ought to be possible to save upstream qemu state direct
> to the fd and avoid the file altogether, Anthony what do you think?

Applied, thanks to both of you.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 20 18:15:46 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 Dec 2011 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.xensource.com>)
	id 1Rd4Dn-0005fL-0i; Tue, 20 Dec 2011 18:15:27 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Rd4Dl-0005f2-Uo
	for xen-devel@lists.xensource.com; Tue, 20 Dec 2011 18:15:26 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1324404919!6311729!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzQwMQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9688 invoked from network); 20 Dec 2011 18:15:19 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Dec 2011 18:15:19 -0000
X-IronPort-AV: E=Sophos;i="4.71,383,1320624000"; 
   d="scan'208";a="9589871"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Dec 2011 18:15:19 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 20 Dec 2011 18:15:19 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Rd4Df-0005Gv-1f; Tue, 20 Dec 2011 18:15:19 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rd4Df-0007MR-0l;
	Tue, 20 Dec 2011 18:15:19 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20208.53431.9104.857044@mariner.uk.xensource.com>
Date: Tue, 20 Dec 2011 18:15:19 +0000
To: Anthony PERARD <anthony.perard@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1324031825.20077.562.camel@zakaz.uk.xensource.com>,
	<alpine.DEB.2.00.1112201512040.21175@perard.uk.xensource.com>
References: <64e48ae2ef6760db221f.1323796155@cosworth.uk.xensource.com>
	<20202.10169.101830.45527@mariner.uk.xensource.com>
	<1324031825.20077.562.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1112201512040.21175@perard.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] libxl: improve error handling when saving
 device model state [and 1 more messages]
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("Re: [Xen-devel] [PATCH] libxl: improve error handling when saving device model state"):
> On Thu, 2011-12-15 at 17:00 +0000, Ian Jackson wrote:
> > Ian Campbell writes ("[Xen-devel] [PATCH] libxl: improve error handling when saving device model state"):
> > And always unlinking the filename is fine, surely ?
> 
> Yes. Patch is below.
> 
> In principal it ought to be possible to save upstream qemu state direct
> to the fd and avoid the file altogether, Anthony what do you think?

Applied, thanks to both of you.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 20 18:19:08 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 Dec 2011 18:19:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rd4H6-0005tt-LK; Tue, 20 Dec 2011 18:18:52 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Rd4H4-0005tV-Ug
	for xen-devel@lists.xensource.com; Tue, 20 Dec 2011 18:18:51 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1324405124!725513!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzQwMQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20327 invoked from network); 20 Dec 2011 18:18:45 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Dec 2011 18:18:45 -0000
X-IronPort-AV: E=Sophos;i="4.71,383,1320624000"; 
   d="scan'208";a="9589983"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Dec 2011 18:18:44 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 20 Dec 2011 18:18:44 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Rd4Gy-0005HW-HF; Tue, 20 Dec 2011 18:18:44 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rd4Gy-0007T6-GI;
	Tue, 20 Dec 2011 18:18:44 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20208.53636.143629.408001@mariner.uk.xensource.com>
Date: Tue, 20 Dec 2011 18:18:44 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1324029343.20077.537.camel@zakaz.uk.xensource.com>
References: <patchbomb.1324029109@cosworth.uk.xensource.com>
	<1324029343.20077.537.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 0 of 3 V2] libxl: domain shutdown cleanup
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("Re: [Xen-devel] [PATCH 0 of 3 V2] libxl: domain shutdown cleanup"):
> On Fri, 2011-12-16 at 09:51 +0000, Ian Campbell wrote:

Thanks.  I applied 1/3 but the 2/2 had a conflict (with Roger Pau
Monne's series I think) so the rest needs a refresh.

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 20 18:19:08 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 Dec 2011 18:19:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rd4H6-0005tt-LK; Tue, 20 Dec 2011 18:18:52 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Rd4H4-0005tV-Ug
	for xen-devel@lists.xensource.com; Tue, 20 Dec 2011 18:18:51 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1324405124!725513!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzQwMQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20327 invoked from network); 20 Dec 2011 18:18:45 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Dec 2011 18:18:45 -0000
X-IronPort-AV: E=Sophos;i="4.71,383,1320624000"; 
   d="scan'208";a="9589983"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Dec 2011 18:18:44 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 20 Dec 2011 18:18:44 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Rd4Gy-0005HW-HF; Tue, 20 Dec 2011 18:18:44 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rd4Gy-0007T6-GI;
	Tue, 20 Dec 2011 18:18:44 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20208.53636.143629.408001@mariner.uk.xensource.com>
Date: Tue, 20 Dec 2011 18:18:44 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1324029343.20077.537.camel@zakaz.uk.xensource.com>
References: <patchbomb.1324029109@cosworth.uk.xensource.com>
	<1324029343.20077.537.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 0 of 3 V2] libxl: domain shutdown cleanup
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("Re: [Xen-devel] [PATCH 0 of 3 V2] libxl: domain shutdown cleanup"):
> On Fri, 2011-12-16 at 09:51 +0000, Ian Campbell wrote:

Thanks.  I applied 1/3 but the 2/2 had a conflict (with Roger Pau
Monne's series I think) so the rest needs a refresh.

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 20 18:20:47 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 Dec 2011 18:20:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rd4Ih-00061m-5Y; Tue, 20 Dec 2011 18:20:31 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Rd4If-00061K-T9
	for xen-devel@lists.xensource.com; Tue, 20 Dec 2011 18:20:30 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1324405224!8187238!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzQwMQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30041 invoked from network); 20 Dec 2011 18:20:24 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Dec 2011 18:20:24 -0000
X-IronPort-AV: E=Sophos;i="4.71,383,1320624000"; 
   d="scan'208";a="9590053"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Dec 2011 18:20:24 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 20 Dec 2011 18:20:23 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Rd4IZ-0005Ht-NR; Tue, 20 Dec 2011 18:20:23 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rd4IZ-0007TW-MI;
	Tue, 20 Dec 2011 18:20:23 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20208.53735.675500.502429@mariner.uk.xensource.com>
Date: Tue, 20 Dec 2011 18:20:23 +0000
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1323985534-17321-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <20111215205654.GA11829@andromeda.dapyr.net>
	<1323985534-17321-1-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: konrad@darnok.org, xen-devel@lists.xensource.com, keir@xen.org,
	stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH] flask/policy: Update example policy
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Daniel De Graaf writes ("[Xen-devel] [PATCH] flask/policy: Update example policy"):
> Rewrite the example policy to make it easier to understand and
> demonstrate some of the security goals that FLASK can enforce.

Thanks.

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 20 18:20:47 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 Dec 2011 18:20:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rd4Ih-00061m-5Y; Tue, 20 Dec 2011 18:20:31 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Rd4If-00061K-T9
	for xen-devel@lists.xensource.com; Tue, 20 Dec 2011 18:20:30 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1324405224!8187238!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzQwMQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30041 invoked from network); 20 Dec 2011 18:20:24 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Dec 2011 18:20:24 -0000
X-IronPort-AV: E=Sophos;i="4.71,383,1320624000"; 
   d="scan'208";a="9590053"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Dec 2011 18:20:24 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 20 Dec 2011 18:20:23 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Rd4IZ-0005Ht-NR; Tue, 20 Dec 2011 18:20:23 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rd4IZ-0007TW-MI;
	Tue, 20 Dec 2011 18:20:23 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20208.53735.675500.502429@mariner.uk.xensource.com>
Date: Tue, 20 Dec 2011 18:20:23 +0000
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1323985534-17321-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <20111215205654.GA11829@andromeda.dapyr.net>
	<1323985534-17321-1-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: konrad@darnok.org, xen-devel@lists.xensource.com, keir@xen.org,
	stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH] flask/policy: Update example policy
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Daniel De Graaf writes ("[Xen-devel] [PATCH] flask/policy: Update example policy"):
> Rewrite the example policy to make it easier to understand and
> demonstrate some of the security goals that FLASK can enforce.

Thanks.

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 20 18:23:34 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 Dec 2011 18:23:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rd4LS-0006E5-2x; Tue, 20 Dec 2011 18:23:22 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Rd4LQ-0006Dk-La
	for xen-devel@lists.xensource.com; Tue, 20 Dec 2011 18:23:20 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1324405357!53218322!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDUxNDAx\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7875 invoked from network); 20 Dec 2011 18:22:39 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-4.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 20 Dec 2011 18:22:39 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pBKIMLi3030417
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 20 Dec 2011 18:22:21 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pBKIMJGn014190
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 20 Dec 2011 18:22:20 GMT
Received: from abhmt115.oracle.com (abhmt115.oracle.com [141.146.116.67])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pBKIMIQM031507; Tue, 20 Dec 2011 12:22:18 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 20 Dec 2011 10:22:18 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id EE26E40068; Tue, 20 Dec 2011 13:21:18 -0500 (EST)
Date: Tue, 20 Dec 2011 13:21:18 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Adin Scannell <adin@scannell.ca>
Message-ID: <20111220182118.GB7152@phenom.dumpdata.com>
References: <1324363013-11031-1-git-send-email-adin@scannell.ca>
	<1324363013-11031-2-git-send-email-adin@scannell.ca>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1324363013-11031-2-git-send-email-adin@scannell.ca>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090208.4EF0D25E.01ED,ss=1,re=0.000,fgs=0
Cc: olaf@aepfle.de, xen-devel@lists.xensource.com, andres@gridcentric.ca,
	linux-kernel@vger.kernel.org, JBeulich@suse.com,
	konrad@darnok.org, adin@gridcentric.com
Subject: Re: [Xen-devel] [PATCH 1/3] Make xen_remap_domain_mfn_range return
 value meaningful in case of error
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Dec 20, 2011 at 01:36:51AM -0500, Adin Scannell wrote:
> Original patch from Olaf Hering <ohering@novell.com>
> 
> This change fixes the xc_map_foreign_bulk interface, which would
> otherwise cause SIGBUS when pages are gone because -ENOENT is not
> returned as expected by the IOCTL_PRIVCMD_MMAPBATCH_V2 ioctl.
> 
> Signed-off-by: Jan Beulich <jbeulich@novell.com>
> 
> This is a port to the mainline Linux tree.  Functions were refactored and
> renamed.  I believe that this is the only required change to match the
> semantics of the original patch.

Ok, this can go in on itself. Thought the title needs to be change
(to have xen/mmu in it). 

Looking at the code it looks as the IOCTL_PRIVCMD_MMAP could now return -Exx
instead of -EFAULT. Which seems to be OK with the toolstack (at least with
4.1.x).

Is this patch OK with 4.0 toolstack? Does it handle the case of getting
-EsomethingelsethanEFAULT ?

Thanks.
> 
> Signed-off-by: Adin Scannell <adin@scannell.ca>
> ---
>  arch/x86/xen/mmu.c |    4 ++--
>  1 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
> index 87f6673..288a7fc 100644
> --- a/arch/x86/xen/mmu.c
> +++ b/arch/x86/xen/mmu.c
> @@ -2350,8 +2350,8 @@ int xen_remap_domain_mfn_range(struct vm_area_struct *vma,
>  		if (err)
>  			goto out;
>  
> -		err = -EFAULT;
> -		if (HYPERVISOR_mmu_update(mmu_update, batch, NULL, domid) < 0)
> +		err = HYPERVISOR_mmu_update(mmu_update, batch, NULL, domid);
> +		if (err < 0)
>  			goto out;
>  
>  		nr -= batch;
> -- 
> 1.6.2.5
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 20 18:23:34 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 Dec 2011 18:23:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rd4LS-0006E5-2x; Tue, 20 Dec 2011 18:23:22 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Rd4LQ-0006Dk-La
	for xen-devel@lists.xensource.com; Tue, 20 Dec 2011 18:23:20 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1324405357!53218322!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDUxNDAx\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7875 invoked from network); 20 Dec 2011 18:22:39 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-4.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 20 Dec 2011 18:22:39 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pBKIMLi3030417
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 20 Dec 2011 18:22:21 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pBKIMJGn014190
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 20 Dec 2011 18:22:20 GMT
Received: from abhmt115.oracle.com (abhmt115.oracle.com [141.146.116.67])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pBKIMIQM031507; Tue, 20 Dec 2011 12:22:18 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 20 Dec 2011 10:22:18 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id EE26E40068; Tue, 20 Dec 2011 13:21:18 -0500 (EST)
Date: Tue, 20 Dec 2011 13:21:18 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Adin Scannell <adin@scannell.ca>
Message-ID: <20111220182118.GB7152@phenom.dumpdata.com>
References: <1324363013-11031-1-git-send-email-adin@scannell.ca>
	<1324363013-11031-2-git-send-email-adin@scannell.ca>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1324363013-11031-2-git-send-email-adin@scannell.ca>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090208.4EF0D25E.01ED,ss=1,re=0.000,fgs=0
Cc: olaf@aepfle.de, xen-devel@lists.xensource.com, andres@gridcentric.ca,
	linux-kernel@vger.kernel.org, JBeulich@suse.com,
	konrad@darnok.org, adin@gridcentric.com
Subject: Re: [Xen-devel] [PATCH 1/3] Make xen_remap_domain_mfn_range return
 value meaningful in case of error
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Dec 20, 2011 at 01:36:51AM -0500, Adin Scannell wrote:
> Original patch from Olaf Hering <ohering@novell.com>
> 
> This change fixes the xc_map_foreign_bulk interface, which would
> otherwise cause SIGBUS when pages are gone because -ENOENT is not
> returned as expected by the IOCTL_PRIVCMD_MMAPBATCH_V2 ioctl.
> 
> Signed-off-by: Jan Beulich <jbeulich@novell.com>
> 
> This is a port to the mainline Linux tree.  Functions were refactored and
> renamed.  I believe that this is the only required change to match the
> semantics of the original patch.

Ok, this can go in on itself. Thought the title needs to be change
(to have xen/mmu in it). 

Looking at the code it looks as the IOCTL_PRIVCMD_MMAP could now return -Exx
instead of -EFAULT. Which seems to be OK with the toolstack (at least with
4.1.x).

Is this patch OK with 4.0 toolstack? Does it handle the case of getting
-EsomethingelsethanEFAULT ?

Thanks.
> 
> Signed-off-by: Adin Scannell <adin@scannell.ca>
> ---
>  arch/x86/xen/mmu.c |    4 ++--
>  1 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
> index 87f6673..288a7fc 100644
> --- a/arch/x86/xen/mmu.c
> +++ b/arch/x86/xen/mmu.c
> @@ -2350,8 +2350,8 @@ int xen_remap_domain_mfn_range(struct vm_area_struct *vma,
>  		if (err)
>  			goto out;
>  
> -		err = -EFAULT;
> -		if (HYPERVISOR_mmu_update(mmu_update, batch, NULL, domid) < 0)
> +		err = HYPERVISOR_mmu_update(mmu_update, batch, NULL, domid);
> +		if (err < 0)
>  			goto out;
>  
>  		nr -= batch;
> -- 
> 1.6.2.5
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 20 18:24:46 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 Dec 2011 18: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.xensource.com>)
	id 1Rd4Me-0006Lb-PS; Tue, 20 Dec 2011 18:24:36 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1Rd4Md-0006LA-Ce
	for xen-devel@lists.xensource.com; Tue, 20 Dec 2011 18:24:35 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1324405450!59708365!1
X-Originating-IP: [209.85.160.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27524 invoked from network); 20 Dec 2011 18:24:12 -0000
Received: from mail-pw0-f43.google.com (HELO mail-pw0-f43.google.com)
	(209.85.160.43)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Dec 2011 18:24:12 -0000
Received: by pbbb11 with SMTP id b11so22677804pbb.30
	for <xen-devel@lists.xensource.com>;
	Tue, 20 Dec 2011 10:24:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=2rfFYItyfGXTbubLZF8HgkRW+j8jUPYTC4vGQmOlhko=;
	b=Du6/QNX1aXU18aUKDljGC6YLvi3HIJP0AfXeGFNEnqltk+JkvwD524HpkC+zVeca1B
	QXqIQtdcvp8r/XA3/gOnfe7dd//uthUXHNhG/hiT0UNY9eN2mkXuFnYxaQzjG3SbkVYF
	1xGU9S6WVZvhk7wEWqGSxdyutK8tlpVre1dqA=
MIME-Version: 1.0
Received: by 10.68.212.68 with SMTP id ni4mr4944989pbc.44.1324405469308; Tue,
	20 Dec 2011 10:24:29 -0800 (PST)
Received: by 10.142.47.17 with HTTP; Tue, 20 Dec 2011 10:24:29 -0800 (PST)
In-Reply-To: <20208.52668.490134.650939@mariner.uk.xensource.com>
References: <patchbomb.1324212500@alpine.localdomain>
	<c54c326d6fdf26d311c8.1324212502@alpine.localdomain>
	<20208.52668.490134.650939@mariner.uk.xensource.com>
Date: Tue, 20 Dec 2011 19:24:29 +0100
X-Google-Sender-Auth: UllJHgXaemzuHR_sI7ewpMDqd5g
Message-ID: <CAPLaKK6UyyYNtG_AWd8akvLL2KFpFcD2rEkYPcpj9vc_wg-D9Q@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 2 of 5] build: detect uclibc
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

MjAxMS8xMi8yMCBJYW4gSmFja3NvbiA8SWFuLkphY2tzb25AZXUuY2l0cml4LmNvbT46Cj4gUm9n
ZXIgUGF1IE1vbm5lIHdyaXRlcyAoIltYZW4tZGV2ZWxdIFtQQVRDSCAyIG9mIDVdIGJ1aWxkOiBk
ZXRlY3QgdWNsaWJjIik6Cj4+IGJ1aWxkOiBkZXRlY3QgdWNsaWJjCj4+Cj4+IERldGVjdCB1Y2xp
YmMgYnVpbGQgZW52aXJvbm1lbnQgYW5kIGRlZmluZSBDT05GSUdfVUNMSUJDIGFjY29yZGluZ2x5
Lgo+Cj4gSSdtIG5vdCBhIGh1Z2UgZmFuIG9mIHRoaXMgY29uZmlndXJhdGlvbiBhcHByb2FjaCwg
cGFydGljdWxhcmx5IGZvciBhCj4gdmFyaWFudCBsaWJjLiDCoFJhdGhlciwgd2Ugc2hvdWxkIHVz
ZSBwb3J0YWJsZSBjb25zdHJ1Y3RzLgoKVGhhdCB3aWxsIGJlIGdvbmUgb24gdGhlIG5ldyBzZXJp
ZXMgSSdtIHdvcmtpbmcgb24sIHRoZSBvbmx5IHRoaW5nIEknbQptaXNzaW5nIGlzIHRoZSBsaWJp
Y29udiBzdHVmZiB0aGF0J3MgZHJpdmluZyBtZSBudXRzLgoKX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2
ZWxAbGlzdHMueGVuc291cmNlLmNvbQpodHRwOi8vbGlzdHMueGVuc291cmNlLmNvbS94ZW4tZGV2
ZWwK

From xen-devel-bounces@lists.xensource.com Tue Dec 20 18:24:46 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 Dec 2011 18: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.xensource.com>)
	id 1Rd4Me-0006Lb-PS; Tue, 20 Dec 2011 18:24:36 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1Rd4Md-0006LA-Ce
	for xen-devel@lists.xensource.com; Tue, 20 Dec 2011 18:24:35 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1324405450!59708365!1
X-Originating-IP: [209.85.160.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27524 invoked from network); 20 Dec 2011 18:24:12 -0000
Received: from mail-pw0-f43.google.com (HELO mail-pw0-f43.google.com)
	(209.85.160.43)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Dec 2011 18:24:12 -0000
Received: by pbbb11 with SMTP id b11so22677804pbb.30
	for <xen-devel@lists.xensource.com>;
	Tue, 20 Dec 2011 10:24:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=2rfFYItyfGXTbubLZF8HgkRW+j8jUPYTC4vGQmOlhko=;
	b=Du6/QNX1aXU18aUKDljGC6YLvi3HIJP0AfXeGFNEnqltk+JkvwD524HpkC+zVeca1B
	QXqIQtdcvp8r/XA3/gOnfe7dd//uthUXHNhG/hiT0UNY9eN2mkXuFnYxaQzjG3SbkVYF
	1xGU9S6WVZvhk7wEWqGSxdyutK8tlpVre1dqA=
MIME-Version: 1.0
Received: by 10.68.212.68 with SMTP id ni4mr4944989pbc.44.1324405469308; Tue,
	20 Dec 2011 10:24:29 -0800 (PST)
Received: by 10.142.47.17 with HTTP; Tue, 20 Dec 2011 10:24:29 -0800 (PST)
In-Reply-To: <20208.52668.490134.650939@mariner.uk.xensource.com>
References: <patchbomb.1324212500@alpine.localdomain>
	<c54c326d6fdf26d311c8.1324212502@alpine.localdomain>
	<20208.52668.490134.650939@mariner.uk.xensource.com>
Date: Tue, 20 Dec 2011 19:24:29 +0100
X-Google-Sender-Auth: UllJHgXaemzuHR_sI7ewpMDqd5g
Message-ID: <CAPLaKK6UyyYNtG_AWd8akvLL2KFpFcD2rEkYPcpj9vc_wg-D9Q@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 2 of 5] build: detect uclibc
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

MjAxMS8xMi8yMCBJYW4gSmFja3NvbiA8SWFuLkphY2tzb25AZXUuY2l0cml4LmNvbT46Cj4gUm9n
ZXIgUGF1IE1vbm5lIHdyaXRlcyAoIltYZW4tZGV2ZWxdIFtQQVRDSCAyIG9mIDVdIGJ1aWxkOiBk
ZXRlY3QgdWNsaWJjIik6Cj4+IGJ1aWxkOiBkZXRlY3QgdWNsaWJjCj4+Cj4+IERldGVjdCB1Y2xp
YmMgYnVpbGQgZW52aXJvbm1lbnQgYW5kIGRlZmluZSBDT05GSUdfVUNMSUJDIGFjY29yZGluZ2x5
Lgo+Cj4gSSdtIG5vdCBhIGh1Z2UgZmFuIG9mIHRoaXMgY29uZmlndXJhdGlvbiBhcHByb2FjaCwg
cGFydGljdWxhcmx5IGZvciBhCj4gdmFyaWFudCBsaWJjLiDCoFJhdGhlciwgd2Ugc2hvdWxkIHVz
ZSBwb3J0YWJsZSBjb25zdHJ1Y3RzLgoKVGhhdCB3aWxsIGJlIGdvbmUgb24gdGhlIG5ldyBzZXJp
ZXMgSSdtIHdvcmtpbmcgb24sIHRoZSBvbmx5IHRoaW5nIEknbQptaXNzaW5nIGlzIHRoZSBsaWJp
Y29udiBzdHVmZiB0aGF0J3MgZHJpdmluZyBtZSBudXRzLgoKX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2
ZWxAbGlzdHMueGVuc291cmNlLmNvbQpodHRwOi8vbGlzdHMueGVuc291cmNlLmNvbS94ZW4tZGV2
ZWwK

From xen-devel-bounces@lists.xensource.com Tue Dec 20 18:25:43 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 Dec 2011 18:25:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rd4NZ-0006Rs-8J; Tue, 20 Dec 2011 18:25:33 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Rd4NY-0006RO-8X
	for xen-devel@lists.xensource.com; Tue, 20 Dec 2011 18:25:32 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1324405509!59708461!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzQwMQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29504 invoked from network); 20 Dec 2011 18:25:09 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Dec 2011 18:25:09 -0000
X-IronPort-AV: E=Sophos;i="4.71,383,1320624000"; 
   d="scan'208";a="9590169"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Dec 2011 18:25:28 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 20 Dec 2011 18:25:27 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Rd4NT-0005Ix-IR; Tue, 20 Dec 2011 18:25:27 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rd4NT-0007Ub-HY;
	Tue, 20 Dec 2011 18:25:27 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20208.54039.524708.324643@mariner.uk.xensource.com>
Date: Tue, 20 Dec 2011 18:25:27 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1323951936.20077.471.camel@zakaz.uk.xensource.com>
References: <1323951936.20077.471.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [RFC] xl: support configuration of encrypted VNC
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("[Xen-devel] [RFC] xl: support configuration of encrypted VNC"):
> Someone pointed out that it's not possible to configure encrypted vnc
> via xl, while it is possible via xm. This is obviously quite nice to
> have if you are logging in as root...
> 
> The following is my initial attempt but TBH I'm not sure if this is
> presenting the correct interface at either the libxl or xl level. Since
> I don't actually use this stuff myself I'm finding it a bit hard to
> judge how much flexibility is needed or even what the right names/terms
> for things are. Opinions?

What is the security implication of the path with the certificates ?
Is it that only clients with that particular certificate can connect ?

> +        if (!xlu_cfg_get_string (config, "vnctls", &buf, 0)) {
> +            fprintf(stderr, "VNC: %s\n", buf);
> +            if (libxl_vnc_tlsmode_from_string(buf, &dm_info->vnctls)) {
> +                fprintf(stderr, "ERROR: invalid value \"%s\" for \"vnctls\"\n",
> +                        buf);
> +                exit (1);
> +            }
> +        } else {
> +            fprintf(stderr, "!VNC: %s\n", buf);
> +            exit(1);
> +        }

This is a bit odd.  If you don't say "vnctls" in your config file, the
config parser just exits ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 20 18:25:43 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 Dec 2011 18:25:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rd4NZ-0006Rs-8J; Tue, 20 Dec 2011 18:25:33 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Rd4NY-0006RO-8X
	for xen-devel@lists.xensource.com; Tue, 20 Dec 2011 18:25:32 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1324405509!59708461!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzQwMQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29504 invoked from network); 20 Dec 2011 18:25:09 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Dec 2011 18:25:09 -0000
X-IronPort-AV: E=Sophos;i="4.71,383,1320624000"; 
   d="scan'208";a="9590169"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Dec 2011 18:25:28 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 20 Dec 2011 18:25:27 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Rd4NT-0005Ix-IR; Tue, 20 Dec 2011 18:25:27 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rd4NT-0007Ub-HY;
	Tue, 20 Dec 2011 18:25:27 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20208.54039.524708.324643@mariner.uk.xensource.com>
Date: Tue, 20 Dec 2011 18:25:27 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1323951936.20077.471.camel@zakaz.uk.xensource.com>
References: <1323951936.20077.471.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [RFC] xl: support configuration of encrypted VNC
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("[Xen-devel] [RFC] xl: support configuration of encrypted VNC"):
> Someone pointed out that it's not possible to configure encrypted vnc
> via xl, while it is possible via xm. This is obviously quite nice to
> have if you are logging in as root...
> 
> The following is my initial attempt but TBH I'm not sure if this is
> presenting the correct interface at either the libxl or xl level. Since
> I don't actually use this stuff myself I'm finding it a bit hard to
> judge how much flexibility is needed or even what the right names/terms
> for things are. Opinions?

What is the security implication of the path with the certificates ?
Is it that only clients with that particular certificate can connect ?

> +        if (!xlu_cfg_get_string (config, "vnctls", &buf, 0)) {
> +            fprintf(stderr, "VNC: %s\n", buf);
> +            if (libxl_vnc_tlsmode_from_string(buf, &dm_info->vnctls)) {
> +                fprintf(stderr, "ERROR: invalid value \"%s\" for \"vnctls\"\n",
> +                        buf);
> +                exit (1);
> +            }
> +        } else {
> +            fprintf(stderr, "!VNC: %s\n", buf);
> +            exit(1);
> +        }

This is a bit odd.  If you don't say "vnctls" in your config file, the
config parser just exits ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 20 18:26:12 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 Dec 2011 18:26:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rd4O3-0006Vl-MV; Tue, 20 Dec 2011 18:26:03 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Rd4O2-0006V1-EF
	for xen-devel@lists.xensource.com; Tue, 20 Dec 2011 18:26:02 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1324405556!6311711!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzQwMQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23321 invoked from network); 20 Dec 2011 18:25:56 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Dec 2011 18:25:56 -0000
X-IronPort-AV: E=Sophos;i="4.71,383,1320624000"; 
   d="scan'208";a="9590181"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Dec 2011 18:25:56 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 20 Dec 2011 18:25:56 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Rd4Nv-0005J3-VY; Tue, 20 Dec 2011 18:25:56 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rd4Nv-0007Uj-Ui;
	Tue, 20 Dec 2011 18:25:55 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20208.54067.934268.407733@mariner.uk.xensource.com>
Date: Tue, 20 Dec 2011 18:25:55 +0000
To: Roger Pau =?iso-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
In-Reply-To: <CAPLaKK6UyyYNtG_AWd8akvLL2KFpFcD2rEkYPcpj9vc_wg-D9Q@mail.gmail.com>
References: <patchbomb.1324212500@alpine.localdomain>
	<c54c326d6fdf26d311c8.1324212502@alpine.localdomain>
	<20208.52668.490134.650939@mariner.uk.xensource.com>
	<CAPLaKK6UyyYNtG_AWd8akvLL2KFpFcD2rEkYPcpj9vc_wg-D9Q@mail.gmail.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 2 of 5] build: detect uclibc
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Roger Pau Monn=E9 writes ("Re: [Xen-devel] [PATCH 2 of 5] build: detect ucl=
ibc"):
> That will be gone on the new series I'm working on,

Great.

> the only thing I'm missing is the libiconv stuff that's driving me nuts.

Good luck ...

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 20 18:26:12 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 Dec 2011 18:26:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rd4O3-0006Vl-MV; Tue, 20 Dec 2011 18:26:03 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Rd4O2-0006V1-EF
	for xen-devel@lists.xensource.com; Tue, 20 Dec 2011 18:26:02 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1324405556!6311711!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzQwMQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23321 invoked from network); 20 Dec 2011 18:25:56 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Dec 2011 18:25:56 -0000
X-IronPort-AV: E=Sophos;i="4.71,383,1320624000"; 
   d="scan'208";a="9590181"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Dec 2011 18:25:56 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 20 Dec 2011 18:25:56 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Rd4Nv-0005J3-VY; Tue, 20 Dec 2011 18:25:56 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rd4Nv-0007Uj-Ui;
	Tue, 20 Dec 2011 18:25:55 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20208.54067.934268.407733@mariner.uk.xensource.com>
Date: Tue, 20 Dec 2011 18:25:55 +0000
To: Roger Pau =?iso-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
In-Reply-To: <CAPLaKK6UyyYNtG_AWd8akvLL2KFpFcD2rEkYPcpj9vc_wg-D9Q@mail.gmail.com>
References: <patchbomb.1324212500@alpine.localdomain>
	<c54c326d6fdf26d311c8.1324212502@alpine.localdomain>
	<20208.52668.490134.650939@mariner.uk.xensource.com>
	<CAPLaKK6UyyYNtG_AWd8akvLL2KFpFcD2rEkYPcpj9vc_wg-D9Q@mail.gmail.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 2 of 5] build: detect uclibc
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Roger Pau Monn=E9 writes ("Re: [Xen-devel] [PATCH 2 of 5] build: detect ucl=
ibc"):
> That will be gone on the new series I'm working on,

Great.

> the only thing I'm missing is the libiconv stuff that's driving me nuts.

Good luck ...

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 20 18:50:28 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 Dec 2011 18:50:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rd4lQ-00070U-TU; Tue, 20 Dec 2011 18:50:12 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Rd4lP-00070P-Io
	for xen-devel@lists.xensource.com; Tue, 20 Dec 2011 18:50:11 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1324406969!47585634!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzQwMQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8521 invoked from network); 20 Dec 2011 18:49:29 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Dec 2011 18:49:29 -0000
X-IronPort-AV: E=Sophos;i="4.71,383,1320624000"; 
   d="scan'208";a="9590645"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Dec 2011 18:50:10 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 20 Dec 2011 18:50:10 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Rd4JE-0005I3-N5; Tue, 20 Dec 2011 18:21:04 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rd4JE-0007Tp-MA;
	Tue, 20 Dec 2011 18:21:04 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20208.53776.674148.48881@mariner.uk.xensource.com>
Date: Tue, 20 Dec 2011 18:21:04 +0000
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <4EEA4624.3080308@tycho.nsa.gov>
References: <1323808737-29125-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1323808737-29125-9-git-send-email-dgdegra@tycho.nsa.gov>
	<alpine.DEB.2.00.1112151639190.3517@kaball-desktop>
	<4EEA4624.3080308@tycho.nsa.gov>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Keir Fraser <keir@xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 8/8] xl.pod.1: improve documentation of
 FLASK commands
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Daniel De Graaf writes ("Re: [Xen-devel] [PATCH 8/8] xl.pod.1: improve documentation of FLASK commands"):
> FLASK is a security framework that defines a mandatory access control policy
> providing fine-grained controls over Xen domains, allowing the policy writer
> to define what interactions between domains, devices, and the hypervisor are
> permitted. Some example of what you can do using XSM/FLASK: [etc]

Perhaps you'd like to submit this excellent introductory text as a
patch for inclusion somewhere under docs/

Thanks ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 20 18:50:28 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 Dec 2011 18:50:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rd4lQ-00070U-TU; Tue, 20 Dec 2011 18:50:12 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Rd4lP-00070P-Io
	for xen-devel@lists.xensource.com; Tue, 20 Dec 2011 18:50:11 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1324406969!47585634!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzQwMQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8521 invoked from network); 20 Dec 2011 18:49:29 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Dec 2011 18:49:29 -0000
X-IronPort-AV: E=Sophos;i="4.71,383,1320624000"; 
   d="scan'208";a="9590645"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Dec 2011 18:50:10 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 20 Dec 2011 18:50:10 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Rd4JE-0005I3-N5; Tue, 20 Dec 2011 18:21:04 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rd4JE-0007Tp-MA;
	Tue, 20 Dec 2011 18:21:04 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20208.53776.674148.48881@mariner.uk.xensource.com>
Date: Tue, 20 Dec 2011 18:21:04 +0000
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <4EEA4624.3080308@tycho.nsa.gov>
References: <1323808737-29125-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1323808737-29125-9-git-send-email-dgdegra@tycho.nsa.gov>
	<alpine.DEB.2.00.1112151639190.3517@kaball-desktop>
	<4EEA4624.3080308@tycho.nsa.gov>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Keir Fraser <keir@xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 8/8] xl.pod.1: improve documentation of
 FLASK commands
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Daniel De Graaf writes ("Re: [Xen-devel] [PATCH 8/8] xl.pod.1: improve documentation of FLASK commands"):
> FLASK is a security framework that defines a mandatory access control policy
> providing fine-grained controls over Xen domains, allowing the policy writer
> to define what interactions between domains, devices, and the hypervisor are
> permitted. Some example of what you can do using XSM/FLASK: [etc]

Perhaps you'd like to submit this excellent introductory text as a
patch for inclusion somewhere under docs/

Thanks ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 20 19:40:48 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 Dec 2011 19:40:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rd5Xl-0007Ri-2L; Tue, 20 Dec 2011 19:40:09 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mike.mcclurg@citrix.com>)
	id 1Rd5Xj-0007RU-Ex; Tue, 20 Dec 2011 19:40:07 +0000
X-Env-Sender: mike.mcclurg@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1324409950!58086281!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjQxOTA=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30429 invoked from network); 20 Dec 2011 19:39:12 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Dec 2011 19:39:12 -0000
X-IronPort-AV: E=Sophos;i="4.71,383,1320642000"; d="scan'208";a="174907119"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Dec 2011 14:40:01 -0500
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Tue, 20 Dec 2011
	14:40:01 -0500
Message-ID: <4EF0E48E.6010900@citrix.com>
Date: Tue, 20 Dec 2011 19:39:58 +0000
From: Mike McClurg <mike.mcclurg@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:8.0) Gecko/20111124 Thunderbird/8.0
MIME-Version: 1.0
To: =?ISO-8859-1?Q?Pasi_K=E4rkk=E4inen?= <pasik@iki.fi>
References: <D14C52F5-9E35-43F1-9D0E-10336DB51BBD@UFL.EDU>
	<20111219082207.GE12984@reaktio.net>
In-Reply-To: <20111219082207.GE12984@reaktio.net>
X-Enigmail-Version: 1.3.4
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	ruijin zhou <zhourj@UFL.EDU>,
	"xen-api@lists.xensource.com" <xen-api@lists.xensource.com>
Subject: Re: [Xen-devel] [Xen-API]  CrossPoolMigration
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 19/12/11 08:22, Pasi K=E4rkk=E4inen wrote:
> On Sun, Dec 18, 2011 at 09:46:10PM -0500, ruijin zhou wrote:
>> Hi, Guys,
>>
> =

> Hello,
> =

>> I recently found the following links about cross-pool migration:
>>
>> http://wiki.xen.org/wiki/CrossPoolMigration
>>
>> http://wiki.xen.org/wiki/CrossPoolMigrationv2
>>
>> I am interested in the research topic of live storage migration. And, I =
want to build something on Xen. =

>>
>> However, in recent Xen release I cannot find any code about live storage=
 Migration. I found the above links, which have a 'to do list'. It seems th=
at it just started.
>>
>> Does anyone know when will we have the code for storage migration?
>>
>> Thank you very much.
>>
> =

> I added xen-api mailinglist to CC ..
> =


Thanks Pasi.

Hi Ruijin,

Storage motion is something that we are prototyping for XCP/XenServer.
It will not be a part of the Xen hypervisor. We'll probably start more
work on the prototype in January, and we'll post details of our
implementation plan to this list.

Mike

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 20 19:40:48 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 Dec 2011 19:40:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rd5Xl-0007Ri-2L; Tue, 20 Dec 2011 19:40:09 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mike.mcclurg@citrix.com>)
	id 1Rd5Xj-0007RU-Ex; Tue, 20 Dec 2011 19:40:07 +0000
X-Env-Sender: mike.mcclurg@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1324409950!58086281!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjQxOTA=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30429 invoked from network); 20 Dec 2011 19:39:12 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Dec 2011 19:39:12 -0000
X-IronPort-AV: E=Sophos;i="4.71,383,1320642000"; d="scan'208";a="174907119"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Dec 2011 14:40:01 -0500
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Tue, 20 Dec 2011
	14:40:01 -0500
Message-ID: <4EF0E48E.6010900@citrix.com>
Date: Tue, 20 Dec 2011 19:39:58 +0000
From: Mike McClurg <mike.mcclurg@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:8.0) Gecko/20111124 Thunderbird/8.0
MIME-Version: 1.0
To: =?ISO-8859-1?Q?Pasi_K=E4rkk=E4inen?= <pasik@iki.fi>
References: <D14C52F5-9E35-43F1-9D0E-10336DB51BBD@UFL.EDU>
	<20111219082207.GE12984@reaktio.net>
In-Reply-To: <20111219082207.GE12984@reaktio.net>
X-Enigmail-Version: 1.3.4
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	ruijin zhou <zhourj@UFL.EDU>,
	"xen-api@lists.xensource.com" <xen-api@lists.xensource.com>
Subject: Re: [Xen-devel] [Xen-API]  CrossPoolMigration
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 19/12/11 08:22, Pasi K=E4rkk=E4inen wrote:
> On Sun, Dec 18, 2011 at 09:46:10PM -0500, ruijin zhou wrote:
>> Hi, Guys,
>>
> =

> Hello,
> =

>> I recently found the following links about cross-pool migration:
>>
>> http://wiki.xen.org/wiki/CrossPoolMigration
>>
>> http://wiki.xen.org/wiki/CrossPoolMigrationv2
>>
>> I am interested in the research topic of live storage migration. And, I =
want to build something on Xen. =

>>
>> However, in recent Xen release I cannot find any code about live storage=
 Migration. I found the above links, which have a 'to do list'. It seems th=
at it just started.
>>
>> Does anyone know when will we have the code for storage migration?
>>
>> Thank you very much.
>>
> =

> I added xen-api mailinglist to CC ..
> =


Thanks Pasi.

Hi Ruijin,

Storage motion is something that we are prototyping for XCP/XenServer.
It will not be a part of the Xen hypervisor. We'll probably start more
work on the prototype in January, and we'll post details of our
implementation plan to this list.

Mike

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 20 19:50:01 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 Dec 2011 19:50:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rd5gx-0007ih-84; Tue, 20 Dec 2011 19:49:39 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rd5gv-0007ic-TU
	for xen-devel@lists.xensource.com; Tue, 20 Dec 2011 19:49:38 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1324410571!6318305!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzQwMQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8111 invoked from network); 20 Dec 2011 19:49:32 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Dec 2011 19:49:32 -0000
X-IronPort-AV: E=Sophos;i="4.71,384,1320624000"; 
   d="scan'208";a="9591428"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Dec 2011 19:49:10 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 20 Dec 2011 19:49:09 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
In-Reply-To: <20208.54039.524708.324643@mariner.uk.xensource.com>
References: <1323951936.20077.471.camel@zakaz.uk.xensource.com>
	<20208.54039.524708.324643@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
Date: Tue, 20 Dec 2011 19:49:09 +0000
Message-ID: <1324410549.8252.125.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
X-Mailer: Evolution 2.32.3 
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [RFC] xl: support configuration of encrypted VNC
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2011-12-20 at 18:25 +0000, Ian Jackson wrote:
> Ian Campbell writes ("[Xen-devel] [RFC] xl: support configuration of encrypted VNC"):
> > Someone pointed out that it's not possible to configure encrypted vnc
> > via xl, while it is possible via xm. This is obviously quite nice to
> > have if you are logging in as root...
> > 
> > The following is my initial attempt but TBH I'm not sure if this is
> > presenting the correct interface at either the libxl or xl level. Since
> > I don't actually use this stuff myself I'm finding it a bit hard to
> > judge how much flexibility is needed or even what the right names/terms
> > for things are. Opinions?
> 
> What is the security implication of the path with the certificates ?
> Is it that only clients with that particular certificate can connect ?

This option corresponds to the path given to the x509 or x509verify
option to qemu's -vnc. The man page isn't totally clear about what goes
on but AIUI it will look for a CA cert under here and only accept
clients with a cert signed by that CA.

There must surely (?!) be a way to allow you to certify two customers
but only allow them to connect to their own VM but I don't see what it
is, I don't seem to have ended up with either half of a client cert
under that path yet all three options worked for me.

Aha, http://libvirt.org/remote.html suggests that the client certs DN
can be checked against an access control list. Upstream qemu documents
an "acl" command you must use via the monitor to allow the DN. qemu-xen
seems to predate this support.

> 
> > +        if (!xlu_cfg_get_string (config, "vnctls", &buf, 0)) {
> > +            fprintf(stderr, "VNC: %s\n", buf);
> > +            if (libxl_vnc_tlsmode_from_string(buf, &dm_info->vnctls)) {
> > +                fprintf(stderr, "ERROR: invalid value \"%s\" for \"vnctls\"\n",
> > +                        buf);
> > +                exit (1);
> > +            }
> > +        } else {
> > +            fprintf(stderr, "!VNC: %s\n", buf);
> > +            exit(1);
> > +        }
> 
> This is a bit odd.  If you don't say "vnctls" in your config file, the
> config parser just exits ?

Err. that may have been some debug cruft to check I was really passing
the right option when it didn't seem to be working...

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 20 19:50:01 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 Dec 2011 19:50:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rd5gx-0007ih-84; Tue, 20 Dec 2011 19:49:39 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rd5gv-0007ic-TU
	for xen-devel@lists.xensource.com; Tue, 20 Dec 2011 19:49:38 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1324410571!6318305!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzQwMQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8111 invoked from network); 20 Dec 2011 19:49:32 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Dec 2011 19:49:32 -0000
X-IronPort-AV: E=Sophos;i="4.71,384,1320624000"; 
   d="scan'208";a="9591428"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Dec 2011 19:49:10 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 20 Dec 2011 19:49:09 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
In-Reply-To: <20208.54039.524708.324643@mariner.uk.xensource.com>
References: <1323951936.20077.471.camel@zakaz.uk.xensource.com>
	<20208.54039.524708.324643@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
Date: Tue, 20 Dec 2011 19:49:09 +0000
Message-ID: <1324410549.8252.125.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
X-Mailer: Evolution 2.32.3 
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [RFC] xl: support configuration of encrypted VNC
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2011-12-20 at 18:25 +0000, Ian Jackson wrote:
> Ian Campbell writes ("[Xen-devel] [RFC] xl: support configuration of encrypted VNC"):
> > Someone pointed out that it's not possible to configure encrypted vnc
> > via xl, while it is possible via xm. This is obviously quite nice to
> > have if you are logging in as root...
> > 
> > The following is my initial attempt but TBH I'm not sure if this is
> > presenting the correct interface at either the libxl or xl level. Since
> > I don't actually use this stuff myself I'm finding it a bit hard to
> > judge how much flexibility is needed or even what the right names/terms
> > for things are. Opinions?
> 
> What is the security implication of the path with the certificates ?
> Is it that only clients with that particular certificate can connect ?

This option corresponds to the path given to the x509 or x509verify
option to qemu's -vnc. The man page isn't totally clear about what goes
on but AIUI it will look for a CA cert under here and only accept
clients with a cert signed by that CA.

There must surely (?!) be a way to allow you to certify two customers
but only allow them to connect to their own VM but I don't see what it
is, I don't seem to have ended up with either half of a client cert
under that path yet all three options worked for me.

Aha, http://libvirt.org/remote.html suggests that the client certs DN
can be checked against an access control list. Upstream qemu documents
an "acl" command you must use via the monitor to allow the DN. qemu-xen
seems to predate this support.

> 
> > +        if (!xlu_cfg_get_string (config, "vnctls", &buf, 0)) {
> > +            fprintf(stderr, "VNC: %s\n", buf);
> > +            if (libxl_vnc_tlsmode_from_string(buf, &dm_info->vnctls)) {
> > +                fprintf(stderr, "ERROR: invalid value \"%s\" for \"vnctls\"\n",
> > +                        buf);
> > +                exit (1);
> > +            }
> > +        } else {
> > +            fprintf(stderr, "!VNC: %s\n", buf);
> > +            exit(1);
> > +        }
> 
> This is a bit odd.  If you don't say "vnctls" in your config file, the
> config parser just exits ?

Err. that may have been some debug cruft to check I was really passing
the right option when it didn't seem to be working...

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 20 20:05:03 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 Dec 2011 20:05:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rd5vO-00082l-RK; Tue, 20 Dec 2011 20:04:34 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1Rd5vO-00082g-3c
	for xen-devel@lists.xensource.com; Tue, 20 Dec 2011 20:04:34 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-13.tower-216.messagelabs.com!1324411467!7613501!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23837 invoked from network); 20 Dec 2011 20:04:28 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-13.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 20 Dec 2011 20:04:28 -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
	pBKK3ggs031905
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Tue, 20 Dec 2011 15:03:42 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pBKK3g0g031903;
	Tue, 20 Dec 2011 15:03:42 -0500
Date: Tue, 20 Dec 2011 16:03:42 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20111220200341.GA31859@andromeda.dapyr.net>
References: <CAOMqctShNFqe47w1orEPMCqvDORy5yxh=Gy33e02fyQYrz4nkw@mail.gmail.com>
	<20111219142943.GD27772@andromeda.dapyr.net>
	<CAOMqctSW87AmM8UTC34_ZwDhipnZUMmxyxiBix+EMAmi7hn1hg@mail.gmail.com>
	<20111219194324.GA29852@andromeda.dapyr.net>
	<1324373842.23729.16.camel@zakaz.uk.xensource.com>
	<CAEBdQ92Oy6=EYYFG_KNMP6raq7S1e_195hFth1etMgpQWdGtsg@mail.gmail.com>
	<1324374914.23729.22.camel@zakaz.uk.xensource.com>
	<CAOMqctTOC_te2QRqFUC45+cq1qCBcQyMdvQcu4Brpw-kAiYnBg@mail.gmail.com>
	<20111220153501.GC13253@andromeda.dapyr.net>
	<1324397974.23729.45.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1324397974.23729.45.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.9i
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Michal Suchanek <hramrach@centrum.cz>,
	"stefan.bader@canonical.com" <stefan.bader@canonical.com>,
	Jean Guyader <jean.guyader@gmail.com>
Subject: Re: [Xen-devel] UDP checksums broken in Dom0 -> DomU vif transfer
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> > > Thanks for the links
> > > 
> > > I am running Ubuntu in the DomU.
> > 
> > Stefan, is this something you could help us with?
> > 
> > Ian, would it make sense to add all this awesome details in the Xen FAQ
> > Wiki part?
> 
> Yes, please!

I was hoping you would do it :-)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 20 20:05:03 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 Dec 2011 20:05:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rd5vO-00082l-RK; Tue, 20 Dec 2011 20:04:34 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1Rd5vO-00082g-3c
	for xen-devel@lists.xensource.com; Tue, 20 Dec 2011 20:04:34 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-13.tower-216.messagelabs.com!1324411467!7613501!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23837 invoked from network); 20 Dec 2011 20:04:28 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-13.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 20 Dec 2011 20:04:28 -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
	pBKK3ggs031905
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Tue, 20 Dec 2011 15:03:42 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pBKK3g0g031903;
	Tue, 20 Dec 2011 15:03:42 -0500
Date: Tue, 20 Dec 2011 16:03:42 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20111220200341.GA31859@andromeda.dapyr.net>
References: <CAOMqctShNFqe47w1orEPMCqvDORy5yxh=Gy33e02fyQYrz4nkw@mail.gmail.com>
	<20111219142943.GD27772@andromeda.dapyr.net>
	<CAOMqctSW87AmM8UTC34_ZwDhipnZUMmxyxiBix+EMAmi7hn1hg@mail.gmail.com>
	<20111219194324.GA29852@andromeda.dapyr.net>
	<1324373842.23729.16.camel@zakaz.uk.xensource.com>
	<CAEBdQ92Oy6=EYYFG_KNMP6raq7S1e_195hFth1etMgpQWdGtsg@mail.gmail.com>
	<1324374914.23729.22.camel@zakaz.uk.xensource.com>
	<CAOMqctTOC_te2QRqFUC45+cq1qCBcQyMdvQcu4Brpw-kAiYnBg@mail.gmail.com>
	<20111220153501.GC13253@andromeda.dapyr.net>
	<1324397974.23729.45.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1324397974.23729.45.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.9i
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Michal Suchanek <hramrach@centrum.cz>,
	"stefan.bader@canonical.com" <stefan.bader@canonical.com>,
	Jean Guyader <jean.guyader@gmail.com>
Subject: Re: [Xen-devel] UDP checksums broken in Dom0 -> DomU vif transfer
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> > > Thanks for the links
> > > 
> > > I am running Ubuntu in the DomU.
> > 
> > Stefan, is this something you could help us with?
> > 
> > Ian, would it make sense to add all this awesome details in the Xen FAQ
> > Wiki part?
> 
> Yes, please!

I was hoping you would do it :-)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 20 20:20:32 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 Dec 2011 20:20:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rd6AN-0008GM-Cb; Tue, 20 Dec 2011 20:20:03 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rd6AL-0008GH-V1
	for xen-devel@lists.xensource.com; Tue, 20 Dec 2011 20:20:02 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1324412395!6129792!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzQwMQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17525 invoked from network); 20 Dec 2011 20:19:56 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Dec 2011 20:19:56 -0000
X-IronPort-AV: E=Sophos;i="4.71,384,1320624000"; 
   d="scan'208";a="9591749"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Dec 2011 20:19:55 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 20 Dec 2011 20:19:55 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
In-Reply-To: <20208.50657.799146.57017@mariner.uk.xensource.com>
References: <4EEA4877.8010307@canonical.com>
	<20111215193942.GA7640@andromeda.dapyr.net>
	<20111216113300.GA4854@aepfle.de>
	<1324375910.23729.31.camel@zakaz.uk.xensource.com>
	<20111220131533.GA7800@aepfle.de>	<20111220141612.GA25139@konrad-lan>
	<20208.50657.799146.57017@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
Date: Tue, 20 Dec 2011 20:19:54 +0000
Message-ID: <1324412394.8252.163.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
X-Mailer: Evolution 2.32.3 
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>, Olaf Hering <olaf@aepfle.de>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefan Bader <stefan.bader@canonical.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] xenbus and the message of doom
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2011-12-20 at 17:29 +0000, Ian Jackson wrote:
> Konrad Rzeszutek Wilk writes ("Re: [Xen-devel] xenbus and the message of doom"):
> > Sorry Olaf, have to revert that commit.
> 
> I agree.  When we introduced it we weren't aware that most existing
> implementations of xenstored simply ignore unknown commands rather
> than replying with an error.  If we had known this we would not have
> approved Olaf's patch.
> 
> That they ignore unknown commands is of course a bug but expecting
> everyone to update is no good.  Really the best approach would be some
> kind of discovery mechanism.
> 
> Maybe we should have a special path @xenstore/fail_unknown_commands
> which you could read, or something.  But this time we should try it
> against old implementations.

I was sure I'd seen some precedent (and therefore an existing path) for
this sort of thing at some point but I can't for the life of me find it.

The closest I could find is
the /local/domain/<N>/control/platform-feature-multiprocessor-suspend
node which we write statically for every domain. I suppose putting it
under /local/domain/<N> is consistent with restricting the domain to
mostly it's own home area.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 20 20:20:32 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 Dec 2011 20:20:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rd6AN-0008GM-Cb; Tue, 20 Dec 2011 20:20:03 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rd6AL-0008GH-V1
	for xen-devel@lists.xensource.com; Tue, 20 Dec 2011 20:20:02 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1324412395!6129792!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzQwMQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17525 invoked from network); 20 Dec 2011 20:19:56 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Dec 2011 20:19:56 -0000
X-IronPort-AV: E=Sophos;i="4.71,384,1320624000"; 
   d="scan'208";a="9591749"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Dec 2011 20:19:55 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 20 Dec 2011 20:19:55 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
In-Reply-To: <20208.50657.799146.57017@mariner.uk.xensource.com>
References: <4EEA4877.8010307@canonical.com>
	<20111215193942.GA7640@andromeda.dapyr.net>
	<20111216113300.GA4854@aepfle.de>
	<1324375910.23729.31.camel@zakaz.uk.xensource.com>
	<20111220131533.GA7800@aepfle.de>	<20111220141612.GA25139@konrad-lan>
	<20208.50657.799146.57017@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
Date: Tue, 20 Dec 2011 20:19:54 +0000
Message-ID: <1324412394.8252.163.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
X-Mailer: Evolution 2.32.3 
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>, Olaf Hering <olaf@aepfle.de>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefan Bader <stefan.bader@canonical.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] xenbus and the message of doom
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2011-12-20 at 17:29 +0000, Ian Jackson wrote:
> Konrad Rzeszutek Wilk writes ("Re: [Xen-devel] xenbus and the message of doom"):
> > Sorry Olaf, have to revert that commit.
> 
> I agree.  When we introduced it we weren't aware that most existing
> implementations of xenstored simply ignore unknown commands rather
> than replying with an error.  If we had known this we would not have
> approved Olaf's patch.
> 
> That they ignore unknown commands is of course a bug but expecting
> everyone to update is no good.  Really the best approach would be some
> kind of discovery mechanism.
> 
> Maybe we should have a special path @xenstore/fail_unknown_commands
> which you could read, or something.  But this time we should try it
> against old implementations.

I was sure I'd seen some precedent (and therefore an existing path) for
this sort of thing at some point but I can't for the life of me find it.

The closest I could find is
the /local/domain/<N>/control/platform-feature-multiprocessor-suspend
node which we write statically for every domain. I suppose putting it
under /local/domain/<N> is consistent with restricting the domain to
mostly it's own home area.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 20 20:42:22 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 Dec 2011 20: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.xensource.com>)
	id 1Rd6VR-00004x-B2; Tue, 20 Dec 2011 20:41:49 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1Rd6VP-00004s-Ul
	for xen-devel@lists.xensource.com; Tue, 20 Dec 2011 20:41:48 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-12.tower-182.messagelabs.com!1324413700!8060011!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17743 invoked from network); 20 Dec 2011 20:41:41 -0000
Received: from unknown (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-12.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 20 Dec 2011 20:41:41 -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
	pBKKf7sd001047
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Tue, 20 Dec 2011 15:41:08 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pBKKf7aV001045;
	Tue, 20 Dec 2011 15:41:07 -0500
Date: Tue, 20 Dec 2011 16:41:07 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: xen-devel@lists.xensource.com, konrad.wilk@oracle.com,
	George.Dunlap@eu.citrix.com, keir@xen.org
Message-ID: <20111220204107.GA768@andromeda.dapyr.net>
Mime-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.5.9i
Subject: [Xen-devel] issues with PLE and/or scheduler.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hey folks,

I am sending this on behalf of Andrew since our internal email system
is dropping all xen-devel mailing lists :-(

Anyhow:

This is with xen-4.1-testing cs 23201:1c89f7d29fbb
and using the default "credit" scheduler.

I've run into an interesting issue with HVM guests which
make use of Pause Loop Exiting (ie. on westmere systems;
and also on romley systems):  after yielding the cpu, guests
don't seem to receive timer interrupts correctly..

Some background: for historical reasons (ie old templates) we boot
OL/RHEL guests with the following settings:

kernel parameters: clock=pit nohpet nopmtimer
vm.cfg: timer_mode = 2

With PLE enabled, 2.6.32 guests will crash early on with:
 ..MP-BIOS bug: 8254 timer not connected to IO-APIC
 # a few lines omitted..
 Kernel panic - not syncing: IO-APIC + timer doesn't work!  Boot with
apic=debug

While 2.6.18-238 (ie OL/RHEL5u6) will fail to find the timer, but
continue and lock up in the serial line initialization.

 ..MP-BIOS bug: 8254 timer not connected to IO-APIC
 # continues until lock up here:
 Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled

Instrumenting the 2.6.32 code (ie timer_irq_works()) shows that jiffies
isn't advancing (or only 1 or 2 ticks are being received, which is insufficient
for "working"). This is on a "quiet" system with no other activity.
So, even though the guest has voluntarily yielded the cpu (through PLE),
I would still expect it to receive every clock tick (even with timer_mode=2)
as there is no other work to do on the system.

Disabling PLE allows both 2.6.18 and 2.6.32 guests to boot.. [As an
aside, so does setting ple_gap to 41 (ie prior to 21355:727ccaaa6cce) --
the perf counters show no exits happening, so this is equivalent to disabling PLE.]

I'm hoping someone who knows the scheduler well will be able to quickly
decide whether this is a bug or a feature...

Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 20 20:42:22 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 Dec 2011 20: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.xensource.com>)
	id 1Rd6VR-00004x-B2; Tue, 20 Dec 2011 20:41:49 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1Rd6VP-00004s-Ul
	for xen-devel@lists.xensource.com; Tue, 20 Dec 2011 20:41:48 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-12.tower-182.messagelabs.com!1324413700!8060011!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17743 invoked from network); 20 Dec 2011 20:41:41 -0000
Received: from unknown (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-12.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 20 Dec 2011 20:41:41 -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
	pBKKf7sd001047
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Tue, 20 Dec 2011 15:41:08 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pBKKf7aV001045;
	Tue, 20 Dec 2011 15:41:07 -0500
Date: Tue, 20 Dec 2011 16:41:07 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: xen-devel@lists.xensource.com, konrad.wilk@oracle.com,
	George.Dunlap@eu.citrix.com, keir@xen.org
Message-ID: <20111220204107.GA768@andromeda.dapyr.net>
Mime-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.5.9i
Subject: [Xen-devel] issues with PLE and/or scheduler.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hey folks,

I am sending this on behalf of Andrew since our internal email system
is dropping all xen-devel mailing lists :-(

Anyhow:

This is with xen-4.1-testing cs 23201:1c89f7d29fbb
and using the default "credit" scheduler.

I've run into an interesting issue with HVM guests which
make use of Pause Loop Exiting (ie. on westmere systems;
and also on romley systems):  after yielding the cpu, guests
don't seem to receive timer interrupts correctly..

Some background: for historical reasons (ie old templates) we boot
OL/RHEL guests with the following settings:

kernel parameters: clock=pit nohpet nopmtimer
vm.cfg: timer_mode = 2

With PLE enabled, 2.6.32 guests will crash early on with:
 ..MP-BIOS bug: 8254 timer not connected to IO-APIC
 # a few lines omitted..
 Kernel panic - not syncing: IO-APIC + timer doesn't work!  Boot with
apic=debug

While 2.6.18-238 (ie OL/RHEL5u6) will fail to find the timer, but
continue and lock up in the serial line initialization.

 ..MP-BIOS bug: 8254 timer not connected to IO-APIC
 # continues until lock up here:
 Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled

Instrumenting the 2.6.32 code (ie timer_irq_works()) shows that jiffies
isn't advancing (or only 1 or 2 ticks are being received, which is insufficient
for "working"). This is on a "quiet" system with no other activity.
So, even though the guest has voluntarily yielded the cpu (through PLE),
I would still expect it to receive every clock tick (even with timer_mode=2)
as there is no other work to do on the system.

Disabling PLE allows both 2.6.18 and 2.6.32 guests to boot.. [As an
aside, so does setting ple_gap to 41 (ie prior to 21355:727ccaaa6cce) --
the perf counters show no exits happening, so this is equivalent to disabling PLE.]

I'm hoping someone who knows the scheduler well will be able to quickly
decide whether this is a bug or a feature...

Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 20 20:42:54 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 Dec 2011 20:42:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rd6W3-00007H-Th; Tue, 20 Dec 2011 20:42:27 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1Rd6W2-00006k-9r
	for xen-devel@lists.xensource.com; Tue, 20 Dec 2011 20:42:26 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-3.tower-27.messagelabs.com!1324413695!49807633!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7898 invoked from network); 20 Dec 2011 20:41:36 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-3.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 20 Dec 2011 20:41:36 -0000
Received: from andromeda.dapyr.net (darnok@localhost [127.0.0.1])
	by andromeda.dapyr.net (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id
	pBKKfpeX001103
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Tue, 20 Dec 2011 15:41:51 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pBKKfp1O001100;
	Tue, 20 Dec 2011 15:41:51 -0500
Date: Tue, 20 Dec 2011 16:41:51 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: xen-devel@lists.xensource.com, konrad.wilk@oracle.com,
	George.Dunlap@eu.citrix.com, keir@xen.org, andrew.thomas@oracle.com
Message-ID: <20111220204151.GB768@andromeda.dapyr.net>
References: <20111220204107.GA768@andromeda.dapyr.net>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20111220204107.GA768@andromeda.dapyr.net>
User-Agent: Mutt/1.5.9i
Subject: Re: [Xen-devel] issues with PLE and/or scheduler.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Dec 20, 2011 at 04:41:07PM -0400, Konrad Rzeszutek Wilk wrote:
> Hey folks,
> 
> I am sending this on behalf of Andrew since our internal email system
> is dropping all xen-devel mailing lists :-(

<hits his head> And I forgot to CC andrew on it. Added here.
> 
> Anyhow:
> 
> This is with xen-4.1-testing cs 23201:1c89f7d29fbb
> and using the default "credit" scheduler.
> 
> I've run into an interesting issue with HVM guests which
> make use of Pause Loop Exiting (ie. on westmere systems;
> and also on romley systems):  after yielding the cpu, guests
> don't seem to receive timer interrupts correctly..
> 
> Some background: for historical reasons (ie old templates) we boot
> OL/RHEL guests with the following settings:
> 
> kernel parameters: clock=pit nohpet nopmtimer
> vm.cfg: timer_mode = 2
> 
> With PLE enabled, 2.6.32 guests will crash early on with:
>  ..MP-BIOS bug: 8254 timer not connected to IO-APIC
>  # a few lines omitted..
>  Kernel panic - not syncing: IO-APIC + timer doesn't work!  Boot with
> apic=debug
> 
> While 2.6.18-238 (ie OL/RHEL5u6) will fail to find the timer, but
> continue and lock up in the serial line initialization.
> 
>  ..MP-BIOS bug: 8254 timer not connected to IO-APIC
>  # continues until lock up here:
>  Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled
> 
> Instrumenting the 2.6.32 code (ie timer_irq_works()) shows that jiffies
> isn't advancing (or only 1 or 2 ticks are being received, which is insufficient
> for "working"). This is on a "quiet" system with no other activity.
> So, even though the guest has voluntarily yielded the cpu (through PLE),
> I would still expect it to receive every clock tick (even with timer_mode=2)
> as there is no other work to do on the system.
> 
> Disabling PLE allows both 2.6.18 and 2.6.32 guests to boot.. [As an
> aside, so does setting ple_gap to 41 (ie prior to 21355:727ccaaa6cce) --
> the perf counters show no exits happening, so this is equivalent to disabling PLE.]
> 
> I'm hoping someone who knows the scheduler well will be able to quickly
> decide whether this is a bug or a feature...
> 
> Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 20 20:42:54 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 Dec 2011 20:42:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rd6W3-00007H-Th; Tue, 20 Dec 2011 20:42:27 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1Rd6W2-00006k-9r
	for xen-devel@lists.xensource.com; Tue, 20 Dec 2011 20:42:26 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-3.tower-27.messagelabs.com!1324413695!49807633!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7898 invoked from network); 20 Dec 2011 20:41:36 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-3.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 20 Dec 2011 20:41:36 -0000
Received: from andromeda.dapyr.net (darnok@localhost [127.0.0.1])
	by andromeda.dapyr.net (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id
	pBKKfpeX001103
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Tue, 20 Dec 2011 15:41:51 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pBKKfp1O001100;
	Tue, 20 Dec 2011 15:41:51 -0500
Date: Tue, 20 Dec 2011 16:41:51 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: xen-devel@lists.xensource.com, konrad.wilk@oracle.com,
	George.Dunlap@eu.citrix.com, keir@xen.org, andrew.thomas@oracle.com
Message-ID: <20111220204151.GB768@andromeda.dapyr.net>
References: <20111220204107.GA768@andromeda.dapyr.net>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20111220204107.GA768@andromeda.dapyr.net>
User-Agent: Mutt/1.5.9i
Subject: Re: [Xen-devel] issues with PLE and/or scheduler.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Dec 20, 2011 at 04:41:07PM -0400, Konrad Rzeszutek Wilk wrote:
> Hey folks,
> 
> I am sending this on behalf of Andrew since our internal email system
> is dropping all xen-devel mailing lists :-(

<hits his head> And I forgot to CC andrew on it. Added here.
> 
> Anyhow:
> 
> This is with xen-4.1-testing cs 23201:1c89f7d29fbb
> and using the default "credit" scheduler.
> 
> I've run into an interesting issue with HVM guests which
> make use of Pause Loop Exiting (ie. on westmere systems;
> and also on romley systems):  after yielding the cpu, guests
> don't seem to receive timer interrupts correctly..
> 
> Some background: for historical reasons (ie old templates) we boot
> OL/RHEL guests with the following settings:
> 
> kernel parameters: clock=pit nohpet nopmtimer
> vm.cfg: timer_mode = 2
> 
> With PLE enabled, 2.6.32 guests will crash early on with:
>  ..MP-BIOS bug: 8254 timer not connected to IO-APIC
>  # a few lines omitted..
>  Kernel panic - not syncing: IO-APIC + timer doesn't work!  Boot with
> apic=debug
> 
> While 2.6.18-238 (ie OL/RHEL5u6) will fail to find the timer, but
> continue and lock up in the serial line initialization.
> 
>  ..MP-BIOS bug: 8254 timer not connected to IO-APIC
>  # continues until lock up here:
>  Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled
> 
> Instrumenting the 2.6.32 code (ie timer_irq_works()) shows that jiffies
> isn't advancing (or only 1 or 2 ticks are being received, which is insufficient
> for "working"). This is on a "quiet" system with no other activity.
> So, even though the guest has voluntarily yielded the cpu (through PLE),
> I would still expect it to receive every clock tick (even with timer_mode=2)
> as there is no other work to do on the system.
> 
> Disabling PLE allows both 2.6.18 and 2.6.32 guests to boot.. [As an
> aside, so does setting ple_gap to 41 (ie prior to 21355:727ccaaa6cce) --
> the perf counters show no exits happening, so this is equivalent to disabling PLE.]
> 
> I'm hoping someone who knows the scheduler well will be able to quickly
> decide whether this is a bug or a feature...
> 
> Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 20 21:46:24 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 Dec 2011 21:46:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rd7VL-0000aY-5Z; Tue, 20 Dec 2011 21:45:47 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <wcohen@redhat.com>) id 1Rd7VJ-0000aT-Mm
	for xen-devel@lists.xensource.com; Tue, 20 Dec 2011 21:45:45 +0000
X-Env-Sender: wcohen@redhat.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1324417488!61541339!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDY1Mzg=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27537 invoked from network); 20 Dec 2011 21:44:49 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-7.tower-27.messagelabs.com with SMTP;
	20 Dec 2011 21:44:49 -0000
Received: from int-mx02.intmail.prod.int.phx2.redhat.com
	(int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id pBKLisHi019713
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 20 Dec 2011 16:44:54 -0500
Received: from [10.11.231.236] (deploy7.rdu.redhat.com [10.11.231.236])
	by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP
	id pBKLirq5014859; Tue, 20 Dec 2011 16:44:53 -0500
Message-ID: <4EF101D5.20600@redhat.com>
Date: Tue, 20 Dec 2011 16:44:53 -0500
From: William Cohen <wcohen@redhat.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.24) Gecko/20111104 Red Hat/3.1.16-2.el6_1
	Thunderbird/3.1.16
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
References: <4ED4069E.7030307@redhat.com>
	<20111128224545.GA7821@andromeda.dapyr.net>
	<4ED54E66.7040209@redhat.com>
	<20111216210922.GA2295@andromeda.dapyr.net>
In-Reply-To: <20111216210922.GA2295@andromeda.dapyr.net>
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.12
Cc: xen-devel@lists.xensource.com,
	oprofile-list <oprofile-list@lists.sourceforge.net>
Subject: Re: [Xen-devel] xenoprof patch for oprofile-0.9.7
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 12/16/2011 04:09 PM, Konrad Rzeszutek Wilk wrote:
> On Tue, Nov 29, 2011 at 04:28:06PM -0500, William Cohen wrote:
>> On 11/28/2011 05:45 PM, Konrad Rzeszutek Wilk wrote:
>>> On Mon, Nov 28, 2011 at 05:09:34PM -0500, William Cohen wrote:
>>>> I am rebasing Fedora rawhide oprofile package to oprofile-0.9.7. The xenoprof patches on http://xenoprof.sourceforge.net/#download look a bit dated. The newest version is for oprofile-0.9.5. 
>>>
>>> There was one posted some time ago.. Ah:
>>> http://www.flyn.org/patches/linux-xen-passive-oprofile/linux-3.0-xen-passive-oprofile.patch.gz
>>>
>>> I think that ones works , thought I haven't had a chance to test it
>>> myself.
>>>>
>>>> I massaged the patch oprofile-0.9.5-xen.patch to apply to oprofile-.0.9.7. Attached is that updated patch. Does this look reasonable? Is there a desire to get this into upstream oprofile? Or should the xenoprof patch be dropped?
>>>
>>> Well, the desire is to get a performance tool in upstream that works
>>> with Xen very very very much.
>>>
>>> The upstream is using the 'perf' framework which is different from oprofile
>>> and there hasn't been any patches to take advantage of it.
>>>
>>> So to answer your question:
>>>  1). Its awesome you have posted a patch. Will need to spend some time
>>>      with it and and with the version that was posted to see if there is
>>>      something missing. Sadly, the kernel patch is not very
>>>      upstream-compatible as is. But it will get to folks be able to
>>>      do some perf analysis instead of using benchmark tools.
>>
>> If anyone can exercise the patch and verify that it works well with the current upstream xen, that would be greatly appreciated.
> 
> So I tried to do it today but running in trouble of compiling it on
> Fedora Core 16. You wouldn't have any patches floating around to make it
> compile? (I used first a virgin 0.9.7 version).
> 
> Thanks!

Hi Konrad,

Sorry I didn't see this email earlier. 

The patch applies cleanly to oprofile 0.9.7 and builds on fc17. What was the error you got?  How are you configuring it? You should be able to do something like:

cd oprofile-0.9.7
patch -p1 -b < ~/oprofile-0.9.7-xen.patch
./autogen.sh
./configure --with-kernel-support --enable-gui=qt4 

Alternative you should be able to down load the src rpm from http://koji.fedoraproject.org/koji/buildinfo?buildID=276310

then

yum-builddep oprofile-0.9.7-1.src.rpm
rpm -Uvh oprofile-0.9.7-1.src.rpm
cd ~/rpmbuild/SPEC
rpmbuild -b oprofile.spec


Will

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 20 21:46:24 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 Dec 2011 21:46:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rd7VL-0000aY-5Z; Tue, 20 Dec 2011 21:45:47 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <wcohen@redhat.com>) id 1Rd7VJ-0000aT-Mm
	for xen-devel@lists.xensource.com; Tue, 20 Dec 2011 21:45:45 +0000
X-Env-Sender: wcohen@redhat.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1324417488!61541339!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDY1Mzg=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27537 invoked from network); 20 Dec 2011 21:44:49 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-7.tower-27.messagelabs.com with SMTP;
	20 Dec 2011 21:44:49 -0000
Received: from int-mx02.intmail.prod.int.phx2.redhat.com
	(int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id pBKLisHi019713
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 20 Dec 2011 16:44:54 -0500
Received: from [10.11.231.236] (deploy7.rdu.redhat.com [10.11.231.236])
	by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP
	id pBKLirq5014859; Tue, 20 Dec 2011 16:44:53 -0500
Message-ID: <4EF101D5.20600@redhat.com>
Date: Tue, 20 Dec 2011 16:44:53 -0500
From: William Cohen <wcohen@redhat.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.24) Gecko/20111104 Red Hat/3.1.16-2.el6_1
	Thunderbird/3.1.16
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
References: <4ED4069E.7030307@redhat.com>
	<20111128224545.GA7821@andromeda.dapyr.net>
	<4ED54E66.7040209@redhat.com>
	<20111216210922.GA2295@andromeda.dapyr.net>
In-Reply-To: <20111216210922.GA2295@andromeda.dapyr.net>
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.12
Cc: xen-devel@lists.xensource.com,
	oprofile-list <oprofile-list@lists.sourceforge.net>
Subject: Re: [Xen-devel] xenoprof patch for oprofile-0.9.7
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 12/16/2011 04:09 PM, Konrad Rzeszutek Wilk wrote:
> On Tue, Nov 29, 2011 at 04:28:06PM -0500, William Cohen wrote:
>> On 11/28/2011 05:45 PM, Konrad Rzeszutek Wilk wrote:
>>> On Mon, Nov 28, 2011 at 05:09:34PM -0500, William Cohen wrote:
>>>> I am rebasing Fedora rawhide oprofile package to oprofile-0.9.7. The xenoprof patches on http://xenoprof.sourceforge.net/#download look a bit dated. The newest version is for oprofile-0.9.5. 
>>>
>>> There was one posted some time ago.. Ah:
>>> http://www.flyn.org/patches/linux-xen-passive-oprofile/linux-3.0-xen-passive-oprofile.patch.gz
>>>
>>> I think that ones works , thought I haven't had a chance to test it
>>> myself.
>>>>
>>>> I massaged the patch oprofile-0.9.5-xen.patch to apply to oprofile-.0.9.7. Attached is that updated patch. Does this look reasonable? Is there a desire to get this into upstream oprofile? Or should the xenoprof patch be dropped?
>>>
>>> Well, the desire is to get a performance tool in upstream that works
>>> with Xen very very very much.
>>>
>>> The upstream is using the 'perf' framework which is different from oprofile
>>> and there hasn't been any patches to take advantage of it.
>>>
>>> So to answer your question:
>>>  1). Its awesome you have posted a patch. Will need to spend some time
>>>      with it and and with the version that was posted to see if there is
>>>      something missing. Sadly, the kernel patch is not very
>>>      upstream-compatible as is. But it will get to folks be able to
>>>      do some perf analysis instead of using benchmark tools.
>>
>> If anyone can exercise the patch and verify that it works well with the current upstream xen, that would be greatly appreciated.
> 
> So I tried to do it today but running in trouble of compiling it on
> Fedora Core 16. You wouldn't have any patches floating around to make it
> compile? (I used first a virgin 0.9.7 version).
> 
> Thanks!

Hi Konrad,

Sorry I didn't see this email earlier. 

The patch applies cleanly to oprofile 0.9.7 and builds on fc17. What was the error you got?  How are you configuring it? You should be able to do something like:

cd oprofile-0.9.7
patch -p1 -b < ~/oprofile-0.9.7-xen.patch
./autogen.sh
./configure --with-kernel-support --enable-gui=qt4 

Alternative you should be able to down load the src rpm from http://koji.fedoraproject.org/koji/buildinfo?buildID=276310

then

yum-builddep oprofile-0.9.7-1.src.rpm
rpm -Uvh oprofile-0.9.7-1.src.rpm
cd ~/rpmbuild/SPEC
rpmbuild -b oprofile.spec


Will

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 21 00:36:52 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 00:36:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdAAC-0002Zk-TQ; Wed, 21 Dec 2011 00:36:08 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <kevin.tian@intel.com>) id 1RdAAB-0002Zf-Nz
	for xen-devel@lists.xensource.com; Wed, 21 Dec 2011 00:36:08 +0000
X-Env-Sender: kevin.tian@intel.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1324427729!45680971!1
X-Originating-IP: [143.182.124.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjEzNTMw\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27188 invoked from network); 21 Dec 2011 00:35:30 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-12.tower-27.messagelabs.com with SMTP;
	21 Dec 2011 00:35:30 -0000
Received: from azsmga002.ch.intel.com ([10.2.17.35])
	by azsmga101.ch.intel.com with ESMTP; 20 Dec 2011 16:36:00 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="49184900"
Received: from pgsmsx602.gar.corp.intel.com ([10.221.43.81])
	by AZSMGA002.ch.intel.com with ESMTP; 20 Dec 2011 16:35:56 -0800
Received: from pgsmsx102.gar.corp.intel.com (10.221.44.80) by
	pgsmsx602.gar.corp.intel.com (10.221.43.81) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Wed, 21 Dec 2011 08:35:36 +0800
Received: from shsmsx601.ccr.corp.intel.com (10.239.4.112) by
	PGSMSX102.gar.corp.intel.com (10.221.44.80) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Wed, 21 Dec 2011 08:35:36 +0800
Received: from shsmsx502.ccr.corp.intel.com ([10.239.4.96]) by
	shsmsx601.ccr.corp.intel.com ([10.239.4.112]) with mapi;
	Wed, 21 Dec 2011 08:35:36 +0800
From: "Tian, Kevin" <kevin.tian@intel.com>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
Date: Wed, 21 Dec 2011 08:35:34 +0800
Thread-Topic: [Xen-devel] [PATCH 3/8] ACPI: processor: add
	__acpi_processor_[un]register_driver helpers.
Thread-Index: Acy/LIQ3vCjZEYHGRkS1ziA4iSTX8wAShIpw
Message-ID: <625BA99ED14B2D499DC4E29D8138F1506E01AAC469@shsmsx502.ccr.corp.intel.com>
References: <1322673664-14642-1-git-send-email-konrad.wilk@oracle.com>
	<1322673664-14642-4-git-send-email-konrad.wilk@oracle.com>
	<20111216220342.GC9832@phenom.dumpdata.com>
	<625BA99ED14B2D499DC4E29D8138F1506E01AABC7A@shsmsx502.ccr.corp.intel.com>
	<20111219142626.GB27772@andromeda.dapyr.net>
	<625BA99ED14B2D499DC4E29D8138F1506E01AAC03A@shsmsx502.ccr.corp.intel.com>
	<20111220153145.GB13253@andromeda.dapyr.net>
In-Reply-To: <20111220153145.GB13253@andromeda.dapyr.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "jeremy@goop.org" <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"mike.mcclurg@citrix.com" <mike.mcclurg@citrix.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"stefan.bader@canonical.com" <stefan.bader@canonical.com>,
	"rjw@sisk.pl" <rjw@sisk.pl>,
	"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
	"liang.tang@oracle.com" <liang.tang@oracle.com>, "Yu,
	Ke" <ke.yu@intel.com>, "konrad@kernel.org" <konrad@kernel.org>,
	"lenb@kernel.org" <lenb@kernel.org>
Subject: Re: [Xen-devel] [PATCH 3/8] ACPI: processor: add
 __acpi_processor_[un]register_driver helpers.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> From: Konrad Rzeszutek Wilk [mailto:konrad@darnok.org]
> Sent: Tuesday, December 20, 2011 11:32 PM
> 
> On Tue, Dec 20, 2011 at 10:29:12AM +0800, Tian, Kevin wrote:
> > > From: Konrad Rzeszutek Wilk [mailto:konrad@darnok.org]
> > > Sent: Monday, December 19, 2011 10:26 PM
> > >
> > > On Mon, Dec 19, 2011 at 01:48:01PM +0800, Tian, Kevin wrote:
> > > > > From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@oracle.com]
> > > > > Sent: Saturday, December 17, 2011 6:04 AM
> > > > >
> > > > > On Wed, Nov 30, 2011 at 12:20:59PM -0500, Konrad Rzeszutek Wilk
> wrote:
> > > > > > From: Tang Liang <liang.tang@oracle.com>
> > > > > >
> > > > > > This patch implement __acpi_processor_[un]register_driver helper,
> > > > > > so we can registry override processor driver function. Specifically
> > > > > > the Xen processor driver.
> > > > >
> > > > > Liang,
> > > > >
> > > > > Is the reason we are doing this b/c we need to call
> acpi_bus_register_driver
> > > > > and inhibit the registration of 'acpi_processor_driver' ?
> > > > >
> > > > > And the reason we don't want 'acpi_processor_driver' to run is b/c of
> what?
> > > > > If the cpuidle is disabled what is the harm of running the
> > > > > 'acpi_processor_driver'
> > > > > driver?
> > > >
> > > > IIRC, the reason why we want a Xen specific driver is because current
> driver
> > > > is integrated with OS logic too tightly, e.g. the various checks on VCPU
> related
> > > > structures. Long time ago the 1st version in Xen was to use same driver,
> by
> > > > adding various tweaking lines inside which makes it completely messed.
> Then
> > > > later it's found that it's clearer to create a Xen specific wrapping driver, by
> > > > invoking some exported functions from existing one.
> > >
> > > What I am asking is does it matter "if the current driver is integrated
> > > with OS logic to tighly" - as it is not running anyhow (b/c cpuidle is
> > > disabled).
> > >
> > > And if Xen specific driver can run along-side the generic one - since
> > > the generic one is not doing any work (b/c cpuidle is disabled).
> > >
> > > That is what I am trying to figure out - since this patch purpose is to
> > > thwart the generic driver from running and allowing the xen one to run.
> >
> > It's a separate issue from cpuidle case. Here we're talking about acpi
> processor
> > driver, not the acpi cpuidle driver. ACPI processor driver is responsible for
> > discovering ACPI processor projects, and then enumerate various methods
> > such as _PPC, _CST, etc. under those objects. So far this driver depends on
> > VCPU presence in various places, which causes trouble when dom0 is
> configured
> > with less VCPU number than physical present one.
> >
> > One example you can see from acpi_processor_add:
> >
> >         result = acpi_processor_get_info(device); // call acpi_get_cpuid
> >         if (result) {
> >                 /* Processor is physically not present */
> >                 return 0;
> >         }
> >
> > #ifdef CONFIG_SMP
> >         if (pr->id >= setup_max_cpus && pr->id != 0)
> >                 return 0;
> > #endif
> >
> >         BUG_ON((pr->id >= nr_cpu_ids) || (pr->id < 0));
> >
> > The binding between ACPI processor objects and VCPU presence would only
> parse
> > partial objects to Xen. And there're various places within driver validating
> pr->id
> > making it messy to workaround for Xen within same driver.
> >
> > That's the major reason for coming up a Xen specific driver, which always
> parses
> > all present objects regardless of VCPU presence. :-)
> 
> OK. Lets put the # VCPU != PCPU aside. Say dom0 will boot with all
> CPUs and then later on the admin starts unplugging them.

This should be communicated to major Xen based distributions, so that it's
an agreed approach since in majority case dom0 is configured as UP or
a few VCPUs.

> 
> With that in mind, could we use a slim driver (like the one in: "ACPI:
>  add processor driver for Xen virtual CPUs.") that would just
> take the _Pxx, Cxx data and shove them to the hypervisor (handwaving
> aside the checking for quirks and such). And lets assume that we use the
> unmodified acpi_processor_[add|remove|notify] code that is present in
> processor_driver.c.

There may still have other condition checks which may fail, but yes it's possible
to reuse the interfaces. From my memory #VCPU is the major blocker...

> 
> Oh, and the processor-driver.c did try to load (with the understanding
> that it would load, but won't do much since cpuidle is turned off).

you also need consider cpufreq. IIRC, Px related information may be only
parsed from loaded acpi cpufreq driver, which is another reason why a Xen
wrapper driver is created. But of course this could be relaxed from existing
code if you want to go that way.

> 
> Would that still get the Pxx, Cxx data to the hypervisor?

yes, it's possible under the assumption you put in the start. But you need
verify more code paths to make sure some conditional checks for native
Linux still hold true for dom0.

Thanks
Kevin

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 21 00:36:52 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 00:36:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdAAC-0002Zk-TQ; Wed, 21 Dec 2011 00:36:08 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <kevin.tian@intel.com>) id 1RdAAB-0002Zf-Nz
	for xen-devel@lists.xensource.com; Wed, 21 Dec 2011 00:36:08 +0000
X-Env-Sender: kevin.tian@intel.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1324427729!45680971!1
X-Originating-IP: [143.182.124.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjEzNTMw\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27188 invoked from network); 21 Dec 2011 00:35:30 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-12.tower-27.messagelabs.com with SMTP;
	21 Dec 2011 00:35:30 -0000
Received: from azsmga002.ch.intel.com ([10.2.17.35])
	by azsmga101.ch.intel.com with ESMTP; 20 Dec 2011 16:36:00 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="49184900"
Received: from pgsmsx602.gar.corp.intel.com ([10.221.43.81])
	by AZSMGA002.ch.intel.com with ESMTP; 20 Dec 2011 16:35:56 -0800
Received: from pgsmsx102.gar.corp.intel.com (10.221.44.80) by
	pgsmsx602.gar.corp.intel.com (10.221.43.81) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Wed, 21 Dec 2011 08:35:36 +0800
Received: from shsmsx601.ccr.corp.intel.com (10.239.4.112) by
	PGSMSX102.gar.corp.intel.com (10.221.44.80) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Wed, 21 Dec 2011 08:35:36 +0800
Received: from shsmsx502.ccr.corp.intel.com ([10.239.4.96]) by
	shsmsx601.ccr.corp.intel.com ([10.239.4.112]) with mapi;
	Wed, 21 Dec 2011 08:35:36 +0800
From: "Tian, Kevin" <kevin.tian@intel.com>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
Date: Wed, 21 Dec 2011 08:35:34 +0800
Thread-Topic: [Xen-devel] [PATCH 3/8] ACPI: processor: add
	__acpi_processor_[un]register_driver helpers.
Thread-Index: Acy/LIQ3vCjZEYHGRkS1ziA4iSTX8wAShIpw
Message-ID: <625BA99ED14B2D499DC4E29D8138F1506E01AAC469@shsmsx502.ccr.corp.intel.com>
References: <1322673664-14642-1-git-send-email-konrad.wilk@oracle.com>
	<1322673664-14642-4-git-send-email-konrad.wilk@oracle.com>
	<20111216220342.GC9832@phenom.dumpdata.com>
	<625BA99ED14B2D499DC4E29D8138F1506E01AABC7A@shsmsx502.ccr.corp.intel.com>
	<20111219142626.GB27772@andromeda.dapyr.net>
	<625BA99ED14B2D499DC4E29D8138F1506E01AAC03A@shsmsx502.ccr.corp.intel.com>
	<20111220153145.GB13253@andromeda.dapyr.net>
In-Reply-To: <20111220153145.GB13253@andromeda.dapyr.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "jeremy@goop.org" <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"mike.mcclurg@citrix.com" <mike.mcclurg@citrix.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"stefan.bader@canonical.com" <stefan.bader@canonical.com>,
	"rjw@sisk.pl" <rjw@sisk.pl>,
	"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
	"liang.tang@oracle.com" <liang.tang@oracle.com>, "Yu,
	Ke" <ke.yu@intel.com>, "konrad@kernel.org" <konrad@kernel.org>,
	"lenb@kernel.org" <lenb@kernel.org>
Subject: Re: [Xen-devel] [PATCH 3/8] ACPI: processor: add
 __acpi_processor_[un]register_driver helpers.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> From: Konrad Rzeszutek Wilk [mailto:konrad@darnok.org]
> Sent: Tuesday, December 20, 2011 11:32 PM
> 
> On Tue, Dec 20, 2011 at 10:29:12AM +0800, Tian, Kevin wrote:
> > > From: Konrad Rzeszutek Wilk [mailto:konrad@darnok.org]
> > > Sent: Monday, December 19, 2011 10:26 PM
> > >
> > > On Mon, Dec 19, 2011 at 01:48:01PM +0800, Tian, Kevin wrote:
> > > > > From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@oracle.com]
> > > > > Sent: Saturday, December 17, 2011 6:04 AM
> > > > >
> > > > > On Wed, Nov 30, 2011 at 12:20:59PM -0500, Konrad Rzeszutek Wilk
> wrote:
> > > > > > From: Tang Liang <liang.tang@oracle.com>
> > > > > >
> > > > > > This patch implement __acpi_processor_[un]register_driver helper,
> > > > > > so we can registry override processor driver function. Specifically
> > > > > > the Xen processor driver.
> > > > >
> > > > > Liang,
> > > > >
> > > > > Is the reason we are doing this b/c we need to call
> acpi_bus_register_driver
> > > > > and inhibit the registration of 'acpi_processor_driver' ?
> > > > >
> > > > > And the reason we don't want 'acpi_processor_driver' to run is b/c of
> what?
> > > > > If the cpuidle is disabled what is the harm of running the
> > > > > 'acpi_processor_driver'
> > > > > driver?
> > > >
> > > > IIRC, the reason why we want a Xen specific driver is because current
> driver
> > > > is integrated with OS logic too tightly, e.g. the various checks on VCPU
> related
> > > > structures. Long time ago the 1st version in Xen was to use same driver,
> by
> > > > adding various tweaking lines inside which makes it completely messed.
> Then
> > > > later it's found that it's clearer to create a Xen specific wrapping driver, by
> > > > invoking some exported functions from existing one.
> > >
> > > What I am asking is does it matter "if the current driver is integrated
> > > with OS logic to tighly" - as it is not running anyhow (b/c cpuidle is
> > > disabled).
> > >
> > > And if Xen specific driver can run along-side the generic one - since
> > > the generic one is not doing any work (b/c cpuidle is disabled).
> > >
> > > That is what I am trying to figure out - since this patch purpose is to
> > > thwart the generic driver from running and allowing the xen one to run.
> >
> > It's a separate issue from cpuidle case. Here we're talking about acpi
> processor
> > driver, not the acpi cpuidle driver. ACPI processor driver is responsible for
> > discovering ACPI processor projects, and then enumerate various methods
> > such as _PPC, _CST, etc. under those objects. So far this driver depends on
> > VCPU presence in various places, which causes trouble when dom0 is
> configured
> > with less VCPU number than physical present one.
> >
> > One example you can see from acpi_processor_add:
> >
> >         result = acpi_processor_get_info(device); // call acpi_get_cpuid
> >         if (result) {
> >                 /* Processor is physically not present */
> >                 return 0;
> >         }
> >
> > #ifdef CONFIG_SMP
> >         if (pr->id >= setup_max_cpus && pr->id != 0)
> >                 return 0;
> > #endif
> >
> >         BUG_ON((pr->id >= nr_cpu_ids) || (pr->id < 0));
> >
> > The binding between ACPI processor objects and VCPU presence would only
> parse
> > partial objects to Xen. And there're various places within driver validating
> pr->id
> > making it messy to workaround for Xen within same driver.
> >
> > That's the major reason for coming up a Xen specific driver, which always
> parses
> > all present objects regardless of VCPU presence. :-)
> 
> OK. Lets put the # VCPU != PCPU aside. Say dom0 will boot with all
> CPUs and then later on the admin starts unplugging them.

This should be communicated to major Xen based distributions, so that it's
an agreed approach since in majority case dom0 is configured as UP or
a few VCPUs.

> 
> With that in mind, could we use a slim driver (like the one in: "ACPI:
>  add processor driver for Xen virtual CPUs.") that would just
> take the _Pxx, Cxx data and shove them to the hypervisor (handwaving
> aside the checking for quirks and such). And lets assume that we use the
> unmodified acpi_processor_[add|remove|notify] code that is present in
> processor_driver.c.

There may still have other condition checks which may fail, but yes it's possible
to reuse the interfaces. From my memory #VCPU is the major blocker...

> 
> Oh, and the processor-driver.c did try to load (with the understanding
> that it would load, but won't do much since cpuidle is turned off).

you also need consider cpufreq. IIRC, Px related information may be only
parsed from loaded acpi cpufreq driver, which is another reason why a Xen
wrapper driver is created. But of course this could be relaxed from existing
code if you want to go that way.

> 
> Would that still get the Pxx, Cxx data to the hypervisor?

yes, it's possible under the assumption you put in the start. But you need
verify more code paths to make sure some conditional checks for native
Linux still hold true for dom0.

Thanks
Kevin

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 21 01:05:29 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 01:05:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdAby-0006b0-DU; Wed, 21 Dec 2011 01:04:50 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RdAbw-0006as-V1
	for xen-devel@lists.xensource.com; Wed, 21 Dec 2011 01:04:49 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1324429481!8079770!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzUyMg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32410 invoked from network); 21 Dec 2011 01:04:41 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Dec 2011 01:04:41 -0000
X-IronPort-AV: E=Sophos;i="4.71,385,1320624000"; 
   d="scan'208";a="9594165"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Dec 2011 01:04:18 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 21 Dec 2011 01:04:18 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RdAbS-0006gn-6R;
	Wed, 21 Dec 2011 01:04:18 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RdAbS-0000Hq-5r;
	Wed, 21 Dec 2011 01:04:18 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10563-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 21 Dec 2011 01:04:18 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10563: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10563 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10563/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-sedf     14 guest-localmigrate/x10       fail   like 10555
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass

version targeted for testing:
 xen                  e56500f95b6a
baseline version:
 xen                  a4bffc85bb71

------------------------------------------------------------
People who touched revisions under test:
  Anthony PERARD <anthony.perard@citrix.com>
  Boris Ostrovsky <boris.ostrovsky@amd.com>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Roger Pau Monne <roger.pau@entel.upc.edu>
  Wei Huang <wei.huang2@amd.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-unstable
+ revision=e56500f95b6a
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-unstable e56500f95b6a
+ branch=xen-unstable
+ revision=e56500f95b6a
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ : xen@xenbits.xensource.com
+ : xen@xenbits.xensource.com:git/linux-pvops
+ : master
+ : tested/2.6.39.x
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r e56500f95b6a ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 9 changesets with 26 changes to 17 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 21 01:05:29 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 01:05:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdAby-0006b0-DU; Wed, 21 Dec 2011 01:04:50 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RdAbw-0006as-V1
	for xen-devel@lists.xensource.com; Wed, 21 Dec 2011 01:04:49 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1324429481!8079770!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzUyMg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32410 invoked from network); 21 Dec 2011 01:04:41 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Dec 2011 01:04:41 -0000
X-IronPort-AV: E=Sophos;i="4.71,385,1320624000"; 
   d="scan'208";a="9594165"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Dec 2011 01:04:18 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 21 Dec 2011 01:04:18 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RdAbS-0006gn-6R;
	Wed, 21 Dec 2011 01:04:18 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RdAbS-0000Hq-5r;
	Wed, 21 Dec 2011 01:04:18 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10563-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 21 Dec 2011 01:04:18 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10563: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10563 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10563/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-sedf     14 guest-localmigrate/x10       fail   like 10555
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass

version targeted for testing:
 xen                  e56500f95b6a
baseline version:
 xen                  a4bffc85bb71

------------------------------------------------------------
People who touched revisions under test:
  Anthony PERARD <anthony.perard@citrix.com>
  Boris Ostrovsky <boris.ostrovsky@amd.com>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Roger Pau Monne <roger.pau@entel.upc.edu>
  Wei Huang <wei.huang2@amd.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-unstable
+ revision=e56500f95b6a
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-unstable e56500f95b6a
+ branch=xen-unstable
+ revision=e56500f95b6a
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ : xen@xenbits.xensource.com
+ : xen@xenbits.xensource.com:git/linux-pvops
+ : master
+ : tested/2.6.39.x
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r e56500f95b6a ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 9 changesets with 26 changes to 17 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 21 01:29:39 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 01: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.xensource.com>)
	id 1RdAzT-000764-D1; Wed, 21 Dec 2011 01:29:07 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <haitao.shan@intel.com>) id 1RdAzR-00075z-Pp
	for xen-devel@lists.xensource.com; Wed, 21 Dec 2011 01:29:06 +0000
X-Env-Sender: haitao.shan@intel.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1324430938!6341720!1
X-Originating-IP: [134.134.136.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjQgPT4gMzE4NDM1\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1850 invoked from network); 21 Dec 2011 01:28:58 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-10.tower-174.messagelabs.com with SMTP;
	21 Dec 2011 01:28:58 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga102.jf.intel.com with ESMTP; 20 Dec 2011 17:28:57 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.67,352,1309762800"; 
	d="p7s'?scan'208";a="88728694"
Received: from pgsmsx603.gar.corp.intel.com ([10.221.43.87])
	by orsmga001.jf.intel.com with ESMTP; 20 Dec 2011 17:28:55 -0800
Received: from pgsmsx103.gar.corp.intel.com (10.221.44.82) by
	pgsmsx603.gar.corp.intel.com (10.221.43.87) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Wed, 21 Dec 2011 09:28:07 +0800
Received: from shsmsx602.ccr.corp.intel.com (10.239.4.104) by
	PGSMSX103.gar.corp.intel.com (10.221.44.82) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Wed, 21 Dec 2011 09:28:07 +0800
Received: from shsmsx502.ccr.corp.intel.com ([10.239.4.96]) by
	SHSMSX602.ccr.corp.intel.com ([10.239.4.104]) with mapi;
	Wed, 21 Dec 2011 09:28:06 +0800
From: "Shan, Haitao" <haitao.shan@intel.com>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>, "konrad.wilk@oracle.com"
	<konrad.wilk@oracle.com>, "George.Dunlap@eu.citrix.com"
	<George.Dunlap@eu.citrix.com>, "keir@xen.org" <keir@xen.org>,
	"andrew.thomas@oracle.com" <andrew.thomas@oracle.com>
Date: Wed, 21 Dec 2011 09:28:04 +0800
Thread-Topic: [Xen-devel] issues with PLE and/or scheduler.
Thread-Index: Acy/WC58GrEeWsJBTKeBU9VJiBfb5QAJ2kbQ
Message-ID: <04F972F38B3C4E4E91C4697DA8BF9F5286B2029C29@shsmsx502.ccr.corp.intel.com>
References: <20111220204107.GA768@andromeda.dapyr.net>
	<20111220204151.GB768@andromeda.dapyr.net>
In-Reply-To: <20111220204151.GB768@andromeda.dapyr.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Subject: Re: [Xen-devel] issues with PLE and/or scheduler.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============4631903993932103208=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============4631903993932103208==
Content-Language: en-US
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature";
	micalg=SHA1; boundary="----=_NextPart_000_0000_01CCBFC2.D77D5E60"

------=_NextPart_000_0000_01CCBFC2.D77D5E60
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

We have reproduced your problem locally and are looking into this issue. It
seems "PLE with timer mode 2" will trigger the issue. We can post our
findings as soon as possible.

Shan Haitao

> -----Original Message-----
> From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-
> bounces@lists.xensource.com] On Behalf Of Konrad Rzeszutek Wilk
> Sent: Wednesday, December 21, 2011 4:42 AM
> To: xen-devel@lists.xensource.com; konrad.wilk@oracle.com;
> George.Dunlap@eu.citrix.com; keir@xen.org; andrew.thomas@oracle.com
> Subject: Re: [Xen-devel] issues with PLE and/or scheduler.
> 
> On Tue, Dec 20, 2011 at 04:41:07PM -0400, Konrad Rzeszutek Wilk wrote:
> > Hey folks,
> >
> > I am sending this on behalf of Andrew since our internal email system
> > is dropping all xen-devel mailing lists :-(
> 
> <hits his head> And I forgot to CC andrew on it. Added here.
> >
> > Anyhow:
> >
> > This is with xen-4.1-testing cs 23201:1c89f7d29fbb and using the
> > default "credit" scheduler.
> >
> > I've run into an interesting issue with HVM guests which make use of
> > Pause Loop Exiting (ie. on westmere systems; and also on romley
> > systems):  after yielding the cpu, guests don't seem to receive timer
> > interrupts correctly..
> >
> > Some background: for historical reasons (ie old templates) we boot
> > OL/RHEL guests with the following settings:
> >
> > kernel parameters: clock=pit nohpet nopmtimer
> > vm.cfg: timer_mode = 2
> >
> > With PLE enabled, 2.6.32 guests will crash early on with:
> >  ..MP-BIOS bug: 8254 timer not connected to IO-APIC  # a few lines
> > omitted..
> >  Kernel panic - not syncing: IO-APIC + timer doesn't work!  Boot with
> > apic=debug
> >
> > While 2.6.18-238 (ie OL/RHEL5u6) will fail to find the timer, but
> > continue and lock up in the serial line initialization.
> >
> >  ..MP-BIOS bug: 8254 timer not connected to IO-APIC  # continues until
> > lock up here:
> >  Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing
> > enabled
> >
> > Instrumenting the 2.6.32 code (ie timer_irq_works()) shows that
> > jiffies isn't advancing (or only 1 or 2 ticks are being received,
> > which is insufficient for "working"). This is on a "quiet" system with
no
> other activity.
> > So, even though the guest has voluntarily yielded the cpu (through
> > PLE), I would still expect it to receive every clock tick (even with
> > timer_mode=2) as there is no other work to do on the system.
> >
> > Disabling PLE allows both 2.6.18 and 2.6.32 guests to boot.. [As an
> > aside, so does setting ple_gap to 41 (ie prior to 21355:727ccaaa6cce)
> > -- the perf counters show no exits happening, so this is equivalent to
> > disabling PLE.]
> >
> > I'm hoping someone who knows the scheduler well will be able to
> > quickly decide whether this is a bug or a feature...
> >
> > Andrew
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

------=_NextPart_000_0000_01CCBFC2.D77D5E60
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIYUDCCAyAw
ggKJoAMCAQICBDXe9M8wDQYJKoZIhvcNAQEFBQAwTjELMAkGA1UEBhMCVVMxEDAOBgNVBAoTB0Vx
dWlmYXgxLTArBgNVBAsTJEVxdWlmYXggU2VjdXJlIENlcnRpZmljYXRlIEF1dGhvcml0eTAeFw05
ODA4MjIxNjQxNTFaFw0xODA4MjIxNjQxNTFaME4xCzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVp
ZmF4MS0wKwYDVQQLEyRFcXVpZmF4IFNlY3VyZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwgZ8wDQYJ
KoZIhvcNAQEBBQADgY0AMIGJAoGBAMFdsVhnCGLuoJotHwhtkRRomAoe/toEbxOEYiHD0XzOnwXg
uAHwTjTs4oqVBGSs8WtTXwWzy2eAv0ICjv7dAQns4QAUT/z78AzdQ7pbK+EfgHCZFVeTFvEPl2q3
wmgjHMxNWTCsUR47ryvW7mNFe8XZX1DS41APOojnvxT94Me5AgMBAAGjggEJMIIBBTBwBgNVHR8E
aTBnMGWgY6BhpF8wXTELMAkGA1UEBhMCVVMxEDAOBgNVBAoTB0VxdWlmYXgxLTArBgNVBAsTJEVx
dWlmYXggU2VjdXJlIENlcnRpZmljYXRlIEF1dGhvcml0eTENMAsGA1UEAxMEQ1JMMTAaBgNVHRAE
EzARgQ8yMDE4MDgyMjE2NDE1MVowCwYDVR0PBAQDAgEGMB8GA1UdIwQYMBaAFEjmaPkr0rKV10fY
IyAQTzOYkJ/UMB0GA1UdDgQWBBRI5mj5K9KylddH2CMgEE8zmJCf1DAMBgNVHRMEBTADAQH/MBoG
CSqGSIb2fQdBAAQNMAsbBVYzLjBjAwIGwDANBgkqhkiG9w0BAQUFAAOBgQBYzinq/Pfetc4CuRe1
hdG54+CVzCUxDQCmkm5/tpJjnlCV0Zpv5BHeY4VumO6o/1rI01WyZnFX3sAh6z0qpyNJAQSGQnv8
7n+iFlK1Z2fTQNs7JliyKHc9rhR3Ydb6KmYnoA36p3Nc6nDxlCFlRF/6/O8paKmih3nvee9PrAd3
ODCCAz0wggKmoAMCAQICAwWw/zANBgkqhkiG9w0BAQUFADBOMQswCQYDVQQGEwJVUzEQMA4GA1UE
ChMHRXF1aWZheDEtMCsGA1UECxMkRXF1aWZheCBTZWN1cmUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5
MB4XDTA2MDIxNjE4MDEzMFoXDTE2MDIxOTE4MDEzMFowUjELMAkGA1UEBhMCVVMxGjAYBgNVBAoT
EUludGVsIENvcnBvcmF0aW9uMScwJQYDVQQDEx5JbnRlbCBFeHRlcm5hbCBCYXNpYyBQb2xpY3kg
Q0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDBpd/XOb9QVqEZ8mQ1042TdOIq3ATD
IsV2xDyt30yLyMR5Wjtus0bn3B+he89BiNO/LP6+rFzEwlD55PlX+HLGIKeNNG97dqyc30FElEUj
ZzTZFq2N4e3kVJ/XAEEgANzV8v9qp7qWwxugPgfc3z9BkYot+CifozexHLb/hEZj+yISCU61kRZv
uSQ0E11yYL4dRgcglJeaHo3oX57rvIckaLsYV5/1Aj+R8DM1Ppk965XQAKsHfnyT7C4S50T4lVn4
lz36wOdNZn/zegG1zp41lnoTFfT4KuKVJH5x7YD1p6KbgJCKLovnujGuohquBNfdXKpZkvz6pGv+
iC1HawJdAgMBAAGjgaAwgZ0wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBQaxgxKxEdvqNutK/D0
Vgaj7TdUDDA6BgNVHR8EMzAxMC+gLaArhilodHRwOi8vY3JsLmdlb3RydXN0LmNvbS9jcmxzL3Nl
Y3VyZWNhLmNybDAfBgNVHSMEGDAWgBRI5mj5K9KylddH2CMgEE8zmJCf1DAPBgNVHRMBAf8EBTAD
AQH/MA0GCSqGSIb3DQEBBQUAA4GBABMQOK2kVKVIlUWwLTdywJ+e2O+PC/uQltK2F3lRyrPfBn69
tOkIP4SgDJOfsxyobIrPLe75kBLw+Dom13OBDp/EMZJZ1CglQfVV8co9mT3aZMjSGGQiMgkJLR3j
Mfr900fXZKj5XeqCJ+JP0mEhJGEdVCY+FFlksJjV86fDrq1QMIIFijCCBHKgAwIBAgIKYSCKYgAA
AAAACDANBgkqhkiG9w0BAQUFADBSMQswCQYDVQQGEwJVUzEaMBgGA1UEChMRSW50ZWwgQ29ycG9y
YXRpb24xJzAlBgNVBAMTHkludGVsIEV4dGVybmFsIEJhc2ljIFBvbGljeSBDQTAeFw0wOTA1MTUx
OTI3MjZaFw0xNTA1MTUxOTM3MjZaMFYxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFJbnRlbCBDb3Jw
b3JhdGlvbjErMCkGA1UEAxMiSW50ZWwgRXh0ZXJuYWwgQmFzaWMgSXNzdWluZyBDQSAzQjCCASIw
DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKQEM1Wn9TU9vc9C+/Tc7KB+eiYElmrcEWE32WUd
HvWG+IcQHVQsikTmMyKKojNLw2B5s6Iekc8ivDo/wCfjZzX9JyftMnc+AArc0la87Olybzm8K9jX
EfTBvTnUSFSiI9ZYefITdiUgqlAFuljFZEHYKYtLuhrRacpmQfP4mV63NKdc2bT804HRf6YptZFa
4k6YN94zlrGNrBuQQ74WFzz/jLBusbUpEkro6Mu/ZYFOFWQrV9lBhF9Ruk8yN+3N6n9fUo/qBigi
F2kEn9xVh1ykl7SCGL2jBUkXx4qgV27a6Si8lRRdgrHGtN/HWnSWlLXTH5l575H4Lq++77OFv38C
AwEAAaOCAlwwggJYMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFA7GKvdZsggQkCVvw939imYx
MCvFMAsGA1UdDwQEAwIBhjASBgkrBgEEAYI3FQEEBQIDAQABMCMGCSsGAQQBgjcVAgQWBBQ5oFY2
ekKQ/5Ktim+VdMeSWb4QWTAZBgkrBgEEAYI3FAIEDB4KAFMAdQBiAEMAQTAfBgNVHSMEGDAWgBQa
xgxKxEdvqNutK/D0Vgaj7TdUDDCBvQYDVR0fBIG1MIGyMIGvoIGsoIGphk5odHRwOi8vd3d3Lmlu
dGVsLmNvbS9yZXBvc2l0b3J5L0NSTC9JbnRlbCUyMEV4dGVybmFsJTIwQmFzaWMlMjBQb2xpY3kl
MjBDQS5jcmyGV2h0dHA6Ly9jZXJ0aWZpY2F0ZXMuaW50ZWwuY29tL3JlcG9zaXRvcnkvQ1JML0lu
dGVsJTIwRXh0ZXJuYWwlMjBCYXNpYyUyMFBvbGljeSUyMENBLmNybDCB4wYIKwYBBQUHAQEEgdYw
gdMwYwYIKwYBBQUHMAKGV2h0dHA6Ly93d3cuaW50ZWwuY29tL3JlcG9zaXRvcnkvY2VydGlmaWNh
dGVzL0ludGVsJTIwRXh0ZXJuYWwlMjBCYXNpYyUyMFBvbGljeSUyMENBLmNydDBsBggrBgEFBQcw
AoZgaHR0cDovL2NlcnRpZmljYXRlcy5pbnRlbC5jb20vcmVwb3NpdG9yeS9jZXJ0aWZpY2F0ZXMv
SW50ZWwlMjBFeHRlcm5hbCUyMEJhc2ljJTIwUG9saWN5JTIwQ0EuY3J0MA0GCSqGSIb3DQEBBQUA
A4IBAQCxtQEHchVQhXyjEqtMVUMe6gkmPsIczHxSeqNbo9dsD+6xbT65JT+oYgpIAtfEsYXeUJu1
cChqpb22U5bMAz7eaQcW5bzefufWvA6lg2048B8oczBj/q+5P5NpYrUO8jOmN4jTjfJq3ElZ7yFW
py7rB3Vm/aN6ATYqWfMbS/xfh+JCxmH3droUmMJI0/aZJHsLtjbjFnNsHDNrJZX1vxlM78Lb1hjs
kTENPmhbVbfTj5i/ZGnhv4tmI8QZPCNtcegXJrfhRl2D9bWpdTOPrWiLDUqzy1Z6KL7TcOS/PCl8
RHCJXkPau/thTQCpIoDa2+c+3XA++gRTfAQ4svTO260NMIIGBzCCBO+gAwIBAgIKEx06gQABAAB7
rTANBgkqhkiG9w0BAQUFADBWMQswCQYDVQQGEwJVUzEaMBgGA1UEChMRSW50ZWwgQ29ycG9yYXRp
b24xKzApBgNVBAMTIkludGVsIEV4dGVybmFsIEJhc2ljIElzc3VpbmcgQ0EgM0IwHhcNMTExMDEy
MDEyNDIwWhcNMTQwOTI2MDEyNDIwWjA9MRUwEwYDVQQDEwxTaGFuLCBIYWl0YW8xJDAiBgkqhkiG
9w0BCQEWFWhhaXRhby5zaGFuQGludGVsLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC
ggEBALpHYbXkMy06K6Pl9IGxbsKl0zT/OYd523Rh3CX7tHG/80ZGcPeLlzFK+l+30Fhpzf8fsFwG
l5fX2pRtWqT96BUWecXEVJhisfa1Wrq7DBC6coxEnExFADU+2UsBQ/ACKFSCiq/fADojyFWJgPKv
4PLDKJ9LU23Q+g1WRruGHfBnhCMv0KxnkE7pTk3cFRXtNUSUnYLqcvrZwt9VogQNiNNw3jMlDb8t
bJjMsXdhrwqFGW49z/gAJ2Mnr6/lNnqBdcKF2Qm28SfYXRohGrmam3KReM49ZG0+J/+JPF5drbiw
UAV++PMHA3IXIvZF2c66jQM5BzbF93SkoZXmrQZA2jMCAwEAAaOCAu4wggLqMAsGA1UdDwQEAwIH
gDA8BgkrBgEEAYI3FQcELzAtBiUrBgEEAYI3FQiGw4x1hJnlUYP9gSiFjp9TgpHACWeB3r05lfBD
AgFkAgEIMB0GA1UdDgQWBBQ/OInBCgrko9ziRWiEhjM+SyeeoDAfBgNVHSMEGDAWgBQOxir3WbII
EJAlb8Pd/YpmMTArxTCBzwYDVR0fBIHHMIHEMIHBoIG+oIG7hldodHRwOi8vd3d3LmludGVsLmNv
bS9yZXBvc2l0b3J5L0NSTC9JbnRlbCUyMEV4dGVybmFsJTIwQmFzaWMlMjBJc3N1aW5nJTIwQ0El
MjAzQigxKS5jcmyGYGh0dHA6Ly9jZXJ0aWZpY2F0ZXMuaW50ZWwuY29tL3JlcG9zaXRvcnkvQ1JM
L0ludGVsJTIwRXh0ZXJuYWwlMjBCYXNpYyUyMElzc3VpbmclMjBDQSUyMDNCKDEpLmNybDCB9QYI
KwYBBQUHAQEEgegwgeUwbAYIKwYBBQUHMAKGYGh0dHA6Ly93d3cuaW50ZWwuY29tL3JlcG9zaXRv
cnkvY2VydGlmaWNhdGVzL0ludGVsJTIwRXh0ZXJuYWwlMjBCYXNpYyUyMElzc3VpbmclMjBDQSUy
MDNCKDEpLmNydDB1BggrBgEFBQcwAoZpaHR0cDovL2NlcnRpZmljYXRlcy5pbnRlbC5jb20vcmVw
b3NpdG9yeS9jZXJ0aWZpY2F0ZXMvSW50ZWwlMjBFeHRlcm5hbCUyMEJhc2ljJTIwSXNzdWluZyUy
MENBJTIwM0IoMSkuY3J0MB8GA1UdJQQYMBYGCCsGAQUFBwMEBgorBgEEAYI3CgMMMCkGCSsGAQQB
gjcVCgQcMBowCgYIKwYBBQUHAwQwDAYKKwYBBAGCNwoDDDBHBgNVHREEQDA+oCUGCisGAQQBgjcU
AgOgFwwVaGFpdGFvLnNoYW5AaW50ZWwuY29tgRVoYWl0YW8uc2hhbkBpbnRlbC5jb20wDQYJKoZI
hvcNAQEFBQADggEBAG5Us26ruu8jKt3RhZuirjqgF61p+wZer/xV6BTABUx5++DhWXslTztavsvy
JZ5WsZ7xaijBUO3UQViWTylwmSyGwbhEwreu3XRNGlMOnRk+sH7JGiXZJIpqoD/jtRWp0ypHG2g3
nDqAQ1/j4wUgcI0b12KUJyYAeN6cwEeAqIV4mdD8GpH3DS2nZbEZjTNhkaeJuT7lO1jRqzEGOSCk
KDHPfqUtqpw+wZa6mFbzSso9swc4ypgRIl4l5i/4OwNMQazHm2O6Ov91aDJs6j3DCdALzP736hmF
QFfHWL34GFQMRdpO/OI6z/Q0VYm/6N9o4SD/s4J9Edq8zyYNQxBR03QwggZOMIIFNqADAgECAgoT
I00xAAEAAHuuMA0GCSqGSIb3DQEBBQUAMFYxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFJbnRlbCBD
b3Jwb3JhdGlvbjErMCkGA1UEAxMiSW50ZWwgRXh0ZXJuYWwgQmFzaWMgSXNzdWluZyBDQSAzQjAe
Fw0xMTEwMTIwMTMwNTZaFw0xNDA5MjYwMTMwNTZaMD0xFTATBgNVBAMTDFNoYW4sIEhhaXRhbzEk
MCIGCSqGSIb3DQEJARYVaGFpdGFvLnNoYW5AaW50ZWwuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOC
AQ8AMIIBCgKCAQEApaOcuQtYCobUiLQTadd0Hi+U/ausgzeSE59iUrc57VUzvLsLNnKRxLPm+T26
KN9fMDAS3/MZOl5tf+9mKEwrergim5GzwJpfZWPLAyK2Gs57+F+BMgtX6DT0eh4sGQLQDahPZDhy
Ubo420AiTGuTA9/L22B/qbPNuDRNMMJoreAZeSNBSVPa7Q+Y0oXcfKpAmKzHH2Y+WAzupN5jfxhJ
6yb7MpsPDqoU0Ek4VttgUIl4AQlRFMI18ScKvAG2p9kWSSgq+Z9xdQl7F/3ASkXlQMKEOHCDw8E7
XUzqy4pOoXGaI3FVI4AerPeLgz2SkNINfqLnxdhN+BQ6iuRgsOeyIwIDAQABo4IDNTCCAzEwCwYD
VR0PBAQDAgQwMD0GCSsGAQQBgjcVBwQwMC4GJisGAQQBgjcVCIbDjHWEmeVRg/2BKIWOn1OCkcAJ
Z4S52UGHhP9OAgFkAgEMMEQGCSqGSIb3DQEJDwQ3MDUwDgYIKoZIhvcNAwICAgCAMA4GCCqGSIb3
DQMEAgIAgDAHBgUrDgMCBzAKBggqhkiG9w0DBzAdBgNVHQ4EFgQU/+6IdpvPrUveCml7StYwqL40
iqMwHwYDVR0jBBgwFoAUDsYq91myCBCQJW/D3f2KZjEwK8Uwgc8GA1UdHwSBxzCBxDCBwaCBvqCB
u4ZXaHR0cDovL3d3dy5pbnRlbC5jb20vcmVwb3NpdG9yeS9DUkwvSW50ZWwlMjBFeHRlcm5hbCUy
MEJhc2ljJTIwSXNzdWluZyUyMENBJTIwM0IoMSkuY3JshmBodHRwOi8vY2VydGlmaWNhdGVzLmlu
dGVsLmNvbS9yZXBvc2l0b3J5L0NSTC9JbnRlbCUyMEV4dGVybmFsJTIwQmFzaWMlMjBJc3N1aW5n
JTIwQ0ElMjAzQigxKS5jcmwwgfUGCCsGAQUFBwEBBIHoMIHlMGwGCCsGAQUFBzAChmBodHRwOi8v
d3d3LmludGVsLmNvbS9yZXBvc2l0b3J5L2NlcnRpZmljYXRlcy9JbnRlbCUyMEV4dGVybmFsJTIw
QmFzaWMlMjBJc3N1aW5nJTIwQ0ElMjAzQigxKS5jcnQwdQYIKwYBBQUHMAKGaWh0dHA6Ly9jZXJ0
aWZpY2F0ZXMuaW50ZWwuY29tL3JlcG9zaXRvcnkvY2VydGlmaWNhdGVzL0ludGVsJTIwRXh0ZXJu
YWwlMjBCYXNpYyUyMElzc3VpbmclMjBDQSUyMDNCKDEpLmNydDAfBgNVHSUEGDAWBggrBgEFBQcD
BAYKKwYBBAGCNwoDBDApBgkrBgEEAYI3FQoEHDAaMAoGCCsGAQUFBwMEMAwGCisGAQQBgjcKAwQw
RwYDVR0RBEAwPqAlBgorBgEEAYI3FAIDoBcMFWhhaXRhby5zaGFuQGludGVsLmNvbYEVaGFpdGFv
LnNoYW5AaW50ZWwuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQAqWvSRW8jKGuWVwUKo/+QRxKvuT3cv
/975omnwo7QeOj78XruY/Wsl6/tnzI8jgf6ZE5SRoj5sSGBHmy7qHSZNWodLuJgjN+a0Fk2hy0jB
wX2UJLS3ctijemo4e4u8/YFebLVXCzy81lWa7dZcidebnslLlcQXHNzl8hhFAfQwhcCXMAiA89NO
3uJqd9Sk/PSfG90b/f+1u2xIthxQmeh7u1yuiHZrf1u/e6rJWS50iW+LWmrH0c70XN8voHpLXVDo
09C9DETzJOUrhr1BqLVSxKjNn/uhCOcQxNYM3CYsgQBwVogKsGj59xeGFA5iWPKGRj7SfUXH0m3T
kiSaWLnWMYIDhjCCA4ICAQEwZDBWMQswCQYDVQQGEwJVUzEaMBgGA1UEChMRSW50ZWwgQ29ycG9y
YXRpb24xKzApBgNVBAMTIkludGVsIEV4dGVybmFsIEJhc2ljIElzc3VpbmcgQ0EgM0ICChMdOoEA
AQAAe60wCQYFKw4DAhoFAKCCAfcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0B
CQUxDxcNMTExMjIxMDEyODA0WjAjBgkqhkiG9w0BCQQxFgQUMyQay0mdCjMmwCPrDh52oTIVaNsw
cwYJKwYBBAGCNxAEMWYwZDBWMQswCQYDVQQGEwJVUzEaMBgGA1UEChMRSW50ZWwgQ29ycG9yYXRp
b24xKzApBgNVBAMTIkludGVsIEV4dGVybmFsIEJhc2ljIElzc3VpbmcgQ0EgM0ICChMjTTEAAQAA
e64wdQYLKoZIhvcNAQkQAgsxZqBkMFYxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFJbnRlbCBDb3Jw
b3JhdGlvbjErMCkGA1UEAxMiSW50ZWwgRXh0ZXJuYWwgQmFzaWMgSXNzdWluZyBDQSAzQgIKEyNN
MQABAAB7rjCBqwYJKoZIhvcNAQkPMYGdMIGaMAoGCCqGSIb3DQMHMAsGCWCGSAFlAwQBKjALBglg
hkgBZQMEARYwCwYJYIZIAWUDBAECMA4GCCqGSIb3DQMCAgIAgDAHBgUrDgMCBzANBggqhkiG9w0D
AgIBQDANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAsG
CWCGSAFlAwQCATANBgkqhkiG9w0BAQEFAASCAQBXgmRM1qvVW/SpfolYRerAWuXq6abjQfgBz73j
xiclVy/CzS1dkUK6HOzoL1/BD6SvLO9XYWOGBT/31CwsQFpVNLfmg5FmL6i8U1UV1Zg7GElPI++5
IQNxdyxWKAlAFvbQDHrDF8oMKDoLds5GYCtbduLo5rr2j3npKWlXJsdD6JtM4cW6xD46LPpiRni2
COzO8/oSSFlI87NXRow65yYmN0WQTZt8/3skpRv/PUW6tk1iJNcrSt4OnqIuc0Oq6m2hO5Gup0HX
n7yYoc5/QmoaOJG51YJGjnJMamFwlR1xXGwZhhLk28gSSZ6u60c0QoVDho4mymKJzNi6l5h40Q8/
AAAAAAAA

------=_NextPart_000_0000_01CCBFC2.D77D5E60--


--===============4631903993932103208==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============4631903993932103208==--


From xen-devel-bounces@lists.xensource.com Wed Dec 21 01:29:39 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 01: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.xensource.com>)
	id 1RdAzT-000764-D1; Wed, 21 Dec 2011 01:29:07 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <haitao.shan@intel.com>) id 1RdAzR-00075z-Pp
	for xen-devel@lists.xensource.com; Wed, 21 Dec 2011 01:29:06 +0000
X-Env-Sender: haitao.shan@intel.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1324430938!6341720!1
X-Originating-IP: [134.134.136.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjQgPT4gMzE4NDM1\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1850 invoked from network); 21 Dec 2011 01:28:58 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-10.tower-174.messagelabs.com with SMTP;
	21 Dec 2011 01:28:58 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga102.jf.intel.com with ESMTP; 20 Dec 2011 17:28:57 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.67,352,1309762800"; 
	d="p7s'?scan'208";a="88728694"
Received: from pgsmsx603.gar.corp.intel.com ([10.221.43.87])
	by orsmga001.jf.intel.com with ESMTP; 20 Dec 2011 17:28:55 -0800
Received: from pgsmsx103.gar.corp.intel.com (10.221.44.82) by
	pgsmsx603.gar.corp.intel.com (10.221.43.87) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Wed, 21 Dec 2011 09:28:07 +0800
Received: from shsmsx602.ccr.corp.intel.com (10.239.4.104) by
	PGSMSX103.gar.corp.intel.com (10.221.44.82) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Wed, 21 Dec 2011 09:28:07 +0800
Received: from shsmsx502.ccr.corp.intel.com ([10.239.4.96]) by
	SHSMSX602.ccr.corp.intel.com ([10.239.4.104]) with mapi;
	Wed, 21 Dec 2011 09:28:06 +0800
From: "Shan, Haitao" <haitao.shan@intel.com>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>, "konrad.wilk@oracle.com"
	<konrad.wilk@oracle.com>, "George.Dunlap@eu.citrix.com"
	<George.Dunlap@eu.citrix.com>, "keir@xen.org" <keir@xen.org>,
	"andrew.thomas@oracle.com" <andrew.thomas@oracle.com>
Date: Wed, 21 Dec 2011 09:28:04 +0800
Thread-Topic: [Xen-devel] issues with PLE and/or scheduler.
Thread-Index: Acy/WC58GrEeWsJBTKeBU9VJiBfb5QAJ2kbQ
Message-ID: <04F972F38B3C4E4E91C4697DA8BF9F5286B2029C29@shsmsx502.ccr.corp.intel.com>
References: <20111220204107.GA768@andromeda.dapyr.net>
	<20111220204151.GB768@andromeda.dapyr.net>
In-Reply-To: <20111220204151.GB768@andromeda.dapyr.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Subject: Re: [Xen-devel] issues with PLE and/or scheduler.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============4631903993932103208=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============4631903993932103208==
Content-Language: en-US
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature";
	micalg=SHA1; boundary="----=_NextPart_000_0000_01CCBFC2.D77D5E60"

------=_NextPart_000_0000_01CCBFC2.D77D5E60
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

We have reproduced your problem locally and are looking into this issue. It
seems "PLE with timer mode 2" will trigger the issue. We can post our
findings as soon as possible.

Shan Haitao

> -----Original Message-----
> From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-
> bounces@lists.xensource.com] On Behalf Of Konrad Rzeszutek Wilk
> Sent: Wednesday, December 21, 2011 4:42 AM
> To: xen-devel@lists.xensource.com; konrad.wilk@oracle.com;
> George.Dunlap@eu.citrix.com; keir@xen.org; andrew.thomas@oracle.com
> Subject: Re: [Xen-devel] issues with PLE and/or scheduler.
> 
> On Tue, Dec 20, 2011 at 04:41:07PM -0400, Konrad Rzeszutek Wilk wrote:
> > Hey folks,
> >
> > I am sending this on behalf of Andrew since our internal email system
> > is dropping all xen-devel mailing lists :-(
> 
> <hits his head> And I forgot to CC andrew on it. Added here.
> >
> > Anyhow:
> >
> > This is with xen-4.1-testing cs 23201:1c89f7d29fbb and using the
> > default "credit" scheduler.
> >
> > I've run into an interesting issue with HVM guests which make use of
> > Pause Loop Exiting (ie. on westmere systems; and also on romley
> > systems):  after yielding the cpu, guests don't seem to receive timer
> > interrupts correctly..
> >
> > Some background: for historical reasons (ie old templates) we boot
> > OL/RHEL guests with the following settings:
> >
> > kernel parameters: clock=pit nohpet nopmtimer
> > vm.cfg: timer_mode = 2
> >
> > With PLE enabled, 2.6.32 guests will crash early on with:
> >  ..MP-BIOS bug: 8254 timer not connected to IO-APIC  # a few lines
> > omitted..
> >  Kernel panic - not syncing: IO-APIC + timer doesn't work!  Boot with
> > apic=debug
> >
> > While 2.6.18-238 (ie OL/RHEL5u6) will fail to find the timer, but
> > continue and lock up in the serial line initialization.
> >
> >  ..MP-BIOS bug: 8254 timer not connected to IO-APIC  # continues until
> > lock up here:
> >  Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing
> > enabled
> >
> > Instrumenting the 2.6.32 code (ie timer_irq_works()) shows that
> > jiffies isn't advancing (or only 1 or 2 ticks are being received,
> > which is insufficient for "working"). This is on a "quiet" system with
no
> other activity.
> > So, even though the guest has voluntarily yielded the cpu (through
> > PLE), I would still expect it to receive every clock tick (even with
> > timer_mode=2) as there is no other work to do on the system.
> >
> > Disabling PLE allows both 2.6.18 and 2.6.32 guests to boot.. [As an
> > aside, so does setting ple_gap to 41 (ie prior to 21355:727ccaaa6cce)
> > -- the perf counters show no exits happening, so this is equivalent to
> > disabling PLE.]
> >
> > I'm hoping someone who knows the scheduler well will be able to
> > quickly decide whether this is a bug or a feature...
> >
> > Andrew
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

------=_NextPart_000_0000_01CCBFC2.D77D5E60
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIYUDCCAyAw
ggKJoAMCAQICBDXe9M8wDQYJKoZIhvcNAQEFBQAwTjELMAkGA1UEBhMCVVMxEDAOBgNVBAoTB0Vx
dWlmYXgxLTArBgNVBAsTJEVxdWlmYXggU2VjdXJlIENlcnRpZmljYXRlIEF1dGhvcml0eTAeFw05
ODA4MjIxNjQxNTFaFw0xODA4MjIxNjQxNTFaME4xCzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVp
ZmF4MS0wKwYDVQQLEyRFcXVpZmF4IFNlY3VyZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwgZ8wDQYJ
KoZIhvcNAQEBBQADgY0AMIGJAoGBAMFdsVhnCGLuoJotHwhtkRRomAoe/toEbxOEYiHD0XzOnwXg
uAHwTjTs4oqVBGSs8WtTXwWzy2eAv0ICjv7dAQns4QAUT/z78AzdQ7pbK+EfgHCZFVeTFvEPl2q3
wmgjHMxNWTCsUR47ryvW7mNFe8XZX1DS41APOojnvxT94Me5AgMBAAGjggEJMIIBBTBwBgNVHR8E
aTBnMGWgY6BhpF8wXTELMAkGA1UEBhMCVVMxEDAOBgNVBAoTB0VxdWlmYXgxLTArBgNVBAsTJEVx
dWlmYXggU2VjdXJlIENlcnRpZmljYXRlIEF1dGhvcml0eTENMAsGA1UEAxMEQ1JMMTAaBgNVHRAE
EzARgQ8yMDE4MDgyMjE2NDE1MVowCwYDVR0PBAQDAgEGMB8GA1UdIwQYMBaAFEjmaPkr0rKV10fY
IyAQTzOYkJ/UMB0GA1UdDgQWBBRI5mj5K9KylddH2CMgEE8zmJCf1DAMBgNVHRMEBTADAQH/MBoG
CSqGSIb2fQdBAAQNMAsbBVYzLjBjAwIGwDANBgkqhkiG9w0BAQUFAAOBgQBYzinq/Pfetc4CuRe1
hdG54+CVzCUxDQCmkm5/tpJjnlCV0Zpv5BHeY4VumO6o/1rI01WyZnFX3sAh6z0qpyNJAQSGQnv8
7n+iFlK1Z2fTQNs7JliyKHc9rhR3Ydb6KmYnoA36p3Nc6nDxlCFlRF/6/O8paKmih3nvee9PrAd3
ODCCAz0wggKmoAMCAQICAwWw/zANBgkqhkiG9w0BAQUFADBOMQswCQYDVQQGEwJVUzEQMA4GA1UE
ChMHRXF1aWZheDEtMCsGA1UECxMkRXF1aWZheCBTZWN1cmUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5
MB4XDTA2MDIxNjE4MDEzMFoXDTE2MDIxOTE4MDEzMFowUjELMAkGA1UEBhMCVVMxGjAYBgNVBAoT
EUludGVsIENvcnBvcmF0aW9uMScwJQYDVQQDEx5JbnRlbCBFeHRlcm5hbCBCYXNpYyBQb2xpY3kg
Q0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDBpd/XOb9QVqEZ8mQ1042TdOIq3ATD
IsV2xDyt30yLyMR5Wjtus0bn3B+he89BiNO/LP6+rFzEwlD55PlX+HLGIKeNNG97dqyc30FElEUj
ZzTZFq2N4e3kVJ/XAEEgANzV8v9qp7qWwxugPgfc3z9BkYot+CifozexHLb/hEZj+yISCU61kRZv
uSQ0E11yYL4dRgcglJeaHo3oX57rvIckaLsYV5/1Aj+R8DM1Ppk965XQAKsHfnyT7C4S50T4lVn4
lz36wOdNZn/zegG1zp41lnoTFfT4KuKVJH5x7YD1p6KbgJCKLovnujGuohquBNfdXKpZkvz6pGv+
iC1HawJdAgMBAAGjgaAwgZ0wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBQaxgxKxEdvqNutK/D0
Vgaj7TdUDDA6BgNVHR8EMzAxMC+gLaArhilodHRwOi8vY3JsLmdlb3RydXN0LmNvbS9jcmxzL3Nl
Y3VyZWNhLmNybDAfBgNVHSMEGDAWgBRI5mj5K9KylddH2CMgEE8zmJCf1DAPBgNVHRMBAf8EBTAD
AQH/MA0GCSqGSIb3DQEBBQUAA4GBABMQOK2kVKVIlUWwLTdywJ+e2O+PC/uQltK2F3lRyrPfBn69
tOkIP4SgDJOfsxyobIrPLe75kBLw+Dom13OBDp/EMZJZ1CglQfVV8co9mT3aZMjSGGQiMgkJLR3j
Mfr900fXZKj5XeqCJ+JP0mEhJGEdVCY+FFlksJjV86fDrq1QMIIFijCCBHKgAwIBAgIKYSCKYgAA
AAAACDANBgkqhkiG9w0BAQUFADBSMQswCQYDVQQGEwJVUzEaMBgGA1UEChMRSW50ZWwgQ29ycG9y
YXRpb24xJzAlBgNVBAMTHkludGVsIEV4dGVybmFsIEJhc2ljIFBvbGljeSBDQTAeFw0wOTA1MTUx
OTI3MjZaFw0xNTA1MTUxOTM3MjZaMFYxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFJbnRlbCBDb3Jw
b3JhdGlvbjErMCkGA1UEAxMiSW50ZWwgRXh0ZXJuYWwgQmFzaWMgSXNzdWluZyBDQSAzQjCCASIw
DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKQEM1Wn9TU9vc9C+/Tc7KB+eiYElmrcEWE32WUd
HvWG+IcQHVQsikTmMyKKojNLw2B5s6Iekc8ivDo/wCfjZzX9JyftMnc+AArc0la87Olybzm8K9jX
EfTBvTnUSFSiI9ZYefITdiUgqlAFuljFZEHYKYtLuhrRacpmQfP4mV63NKdc2bT804HRf6YptZFa
4k6YN94zlrGNrBuQQ74WFzz/jLBusbUpEkro6Mu/ZYFOFWQrV9lBhF9Ruk8yN+3N6n9fUo/qBigi
F2kEn9xVh1ykl7SCGL2jBUkXx4qgV27a6Si8lRRdgrHGtN/HWnSWlLXTH5l575H4Lq++77OFv38C
AwEAAaOCAlwwggJYMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFA7GKvdZsggQkCVvw939imYx
MCvFMAsGA1UdDwQEAwIBhjASBgkrBgEEAYI3FQEEBQIDAQABMCMGCSsGAQQBgjcVAgQWBBQ5oFY2
ekKQ/5Ktim+VdMeSWb4QWTAZBgkrBgEEAYI3FAIEDB4KAFMAdQBiAEMAQTAfBgNVHSMEGDAWgBQa
xgxKxEdvqNutK/D0Vgaj7TdUDDCBvQYDVR0fBIG1MIGyMIGvoIGsoIGphk5odHRwOi8vd3d3Lmlu
dGVsLmNvbS9yZXBvc2l0b3J5L0NSTC9JbnRlbCUyMEV4dGVybmFsJTIwQmFzaWMlMjBQb2xpY3kl
MjBDQS5jcmyGV2h0dHA6Ly9jZXJ0aWZpY2F0ZXMuaW50ZWwuY29tL3JlcG9zaXRvcnkvQ1JML0lu
dGVsJTIwRXh0ZXJuYWwlMjBCYXNpYyUyMFBvbGljeSUyMENBLmNybDCB4wYIKwYBBQUHAQEEgdYw
gdMwYwYIKwYBBQUHMAKGV2h0dHA6Ly93d3cuaW50ZWwuY29tL3JlcG9zaXRvcnkvY2VydGlmaWNh
dGVzL0ludGVsJTIwRXh0ZXJuYWwlMjBCYXNpYyUyMFBvbGljeSUyMENBLmNydDBsBggrBgEFBQcw
AoZgaHR0cDovL2NlcnRpZmljYXRlcy5pbnRlbC5jb20vcmVwb3NpdG9yeS9jZXJ0aWZpY2F0ZXMv
SW50ZWwlMjBFeHRlcm5hbCUyMEJhc2ljJTIwUG9saWN5JTIwQ0EuY3J0MA0GCSqGSIb3DQEBBQUA
A4IBAQCxtQEHchVQhXyjEqtMVUMe6gkmPsIczHxSeqNbo9dsD+6xbT65JT+oYgpIAtfEsYXeUJu1
cChqpb22U5bMAz7eaQcW5bzefufWvA6lg2048B8oczBj/q+5P5NpYrUO8jOmN4jTjfJq3ElZ7yFW
py7rB3Vm/aN6ATYqWfMbS/xfh+JCxmH3droUmMJI0/aZJHsLtjbjFnNsHDNrJZX1vxlM78Lb1hjs
kTENPmhbVbfTj5i/ZGnhv4tmI8QZPCNtcegXJrfhRl2D9bWpdTOPrWiLDUqzy1Z6KL7TcOS/PCl8
RHCJXkPau/thTQCpIoDa2+c+3XA++gRTfAQ4svTO260NMIIGBzCCBO+gAwIBAgIKEx06gQABAAB7
rTANBgkqhkiG9w0BAQUFADBWMQswCQYDVQQGEwJVUzEaMBgGA1UEChMRSW50ZWwgQ29ycG9yYXRp
b24xKzApBgNVBAMTIkludGVsIEV4dGVybmFsIEJhc2ljIElzc3VpbmcgQ0EgM0IwHhcNMTExMDEy
MDEyNDIwWhcNMTQwOTI2MDEyNDIwWjA9MRUwEwYDVQQDEwxTaGFuLCBIYWl0YW8xJDAiBgkqhkiG
9w0BCQEWFWhhaXRhby5zaGFuQGludGVsLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC
ggEBALpHYbXkMy06K6Pl9IGxbsKl0zT/OYd523Rh3CX7tHG/80ZGcPeLlzFK+l+30Fhpzf8fsFwG
l5fX2pRtWqT96BUWecXEVJhisfa1Wrq7DBC6coxEnExFADU+2UsBQ/ACKFSCiq/fADojyFWJgPKv
4PLDKJ9LU23Q+g1WRruGHfBnhCMv0KxnkE7pTk3cFRXtNUSUnYLqcvrZwt9VogQNiNNw3jMlDb8t
bJjMsXdhrwqFGW49z/gAJ2Mnr6/lNnqBdcKF2Qm28SfYXRohGrmam3KReM49ZG0+J/+JPF5drbiw
UAV++PMHA3IXIvZF2c66jQM5BzbF93SkoZXmrQZA2jMCAwEAAaOCAu4wggLqMAsGA1UdDwQEAwIH
gDA8BgkrBgEEAYI3FQcELzAtBiUrBgEEAYI3FQiGw4x1hJnlUYP9gSiFjp9TgpHACWeB3r05lfBD
AgFkAgEIMB0GA1UdDgQWBBQ/OInBCgrko9ziRWiEhjM+SyeeoDAfBgNVHSMEGDAWgBQOxir3WbII
EJAlb8Pd/YpmMTArxTCBzwYDVR0fBIHHMIHEMIHBoIG+oIG7hldodHRwOi8vd3d3LmludGVsLmNv
bS9yZXBvc2l0b3J5L0NSTC9JbnRlbCUyMEV4dGVybmFsJTIwQmFzaWMlMjBJc3N1aW5nJTIwQ0El
MjAzQigxKS5jcmyGYGh0dHA6Ly9jZXJ0aWZpY2F0ZXMuaW50ZWwuY29tL3JlcG9zaXRvcnkvQ1JM
L0ludGVsJTIwRXh0ZXJuYWwlMjBCYXNpYyUyMElzc3VpbmclMjBDQSUyMDNCKDEpLmNybDCB9QYI
KwYBBQUHAQEEgegwgeUwbAYIKwYBBQUHMAKGYGh0dHA6Ly93d3cuaW50ZWwuY29tL3JlcG9zaXRv
cnkvY2VydGlmaWNhdGVzL0ludGVsJTIwRXh0ZXJuYWwlMjBCYXNpYyUyMElzc3VpbmclMjBDQSUy
MDNCKDEpLmNydDB1BggrBgEFBQcwAoZpaHR0cDovL2NlcnRpZmljYXRlcy5pbnRlbC5jb20vcmVw
b3NpdG9yeS9jZXJ0aWZpY2F0ZXMvSW50ZWwlMjBFeHRlcm5hbCUyMEJhc2ljJTIwSXNzdWluZyUy
MENBJTIwM0IoMSkuY3J0MB8GA1UdJQQYMBYGCCsGAQUFBwMEBgorBgEEAYI3CgMMMCkGCSsGAQQB
gjcVCgQcMBowCgYIKwYBBQUHAwQwDAYKKwYBBAGCNwoDDDBHBgNVHREEQDA+oCUGCisGAQQBgjcU
AgOgFwwVaGFpdGFvLnNoYW5AaW50ZWwuY29tgRVoYWl0YW8uc2hhbkBpbnRlbC5jb20wDQYJKoZI
hvcNAQEFBQADggEBAG5Us26ruu8jKt3RhZuirjqgF61p+wZer/xV6BTABUx5++DhWXslTztavsvy
JZ5WsZ7xaijBUO3UQViWTylwmSyGwbhEwreu3XRNGlMOnRk+sH7JGiXZJIpqoD/jtRWp0ypHG2g3
nDqAQ1/j4wUgcI0b12KUJyYAeN6cwEeAqIV4mdD8GpH3DS2nZbEZjTNhkaeJuT7lO1jRqzEGOSCk
KDHPfqUtqpw+wZa6mFbzSso9swc4ypgRIl4l5i/4OwNMQazHm2O6Ov91aDJs6j3DCdALzP736hmF
QFfHWL34GFQMRdpO/OI6z/Q0VYm/6N9o4SD/s4J9Edq8zyYNQxBR03QwggZOMIIFNqADAgECAgoT
I00xAAEAAHuuMA0GCSqGSIb3DQEBBQUAMFYxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFJbnRlbCBD
b3Jwb3JhdGlvbjErMCkGA1UEAxMiSW50ZWwgRXh0ZXJuYWwgQmFzaWMgSXNzdWluZyBDQSAzQjAe
Fw0xMTEwMTIwMTMwNTZaFw0xNDA5MjYwMTMwNTZaMD0xFTATBgNVBAMTDFNoYW4sIEhhaXRhbzEk
MCIGCSqGSIb3DQEJARYVaGFpdGFvLnNoYW5AaW50ZWwuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOC
AQ8AMIIBCgKCAQEApaOcuQtYCobUiLQTadd0Hi+U/ausgzeSE59iUrc57VUzvLsLNnKRxLPm+T26
KN9fMDAS3/MZOl5tf+9mKEwrergim5GzwJpfZWPLAyK2Gs57+F+BMgtX6DT0eh4sGQLQDahPZDhy
Ubo420AiTGuTA9/L22B/qbPNuDRNMMJoreAZeSNBSVPa7Q+Y0oXcfKpAmKzHH2Y+WAzupN5jfxhJ
6yb7MpsPDqoU0Ek4VttgUIl4AQlRFMI18ScKvAG2p9kWSSgq+Z9xdQl7F/3ASkXlQMKEOHCDw8E7
XUzqy4pOoXGaI3FVI4AerPeLgz2SkNINfqLnxdhN+BQ6iuRgsOeyIwIDAQABo4IDNTCCAzEwCwYD
VR0PBAQDAgQwMD0GCSsGAQQBgjcVBwQwMC4GJisGAQQBgjcVCIbDjHWEmeVRg/2BKIWOn1OCkcAJ
Z4S52UGHhP9OAgFkAgEMMEQGCSqGSIb3DQEJDwQ3MDUwDgYIKoZIhvcNAwICAgCAMA4GCCqGSIb3
DQMEAgIAgDAHBgUrDgMCBzAKBggqhkiG9w0DBzAdBgNVHQ4EFgQU/+6IdpvPrUveCml7StYwqL40
iqMwHwYDVR0jBBgwFoAUDsYq91myCBCQJW/D3f2KZjEwK8Uwgc8GA1UdHwSBxzCBxDCBwaCBvqCB
u4ZXaHR0cDovL3d3dy5pbnRlbC5jb20vcmVwb3NpdG9yeS9DUkwvSW50ZWwlMjBFeHRlcm5hbCUy
MEJhc2ljJTIwSXNzdWluZyUyMENBJTIwM0IoMSkuY3JshmBodHRwOi8vY2VydGlmaWNhdGVzLmlu
dGVsLmNvbS9yZXBvc2l0b3J5L0NSTC9JbnRlbCUyMEV4dGVybmFsJTIwQmFzaWMlMjBJc3N1aW5n
JTIwQ0ElMjAzQigxKS5jcmwwgfUGCCsGAQUFBwEBBIHoMIHlMGwGCCsGAQUFBzAChmBodHRwOi8v
d3d3LmludGVsLmNvbS9yZXBvc2l0b3J5L2NlcnRpZmljYXRlcy9JbnRlbCUyMEV4dGVybmFsJTIw
QmFzaWMlMjBJc3N1aW5nJTIwQ0ElMjAzQigxKS5jcnQwdQYIKwYBBQUHMAKGaWh0dHA6Ly9jZXJ0
aWZpY2F0ZXMuaW50ZWwuY29tL3JlcG9zaXRvcnkvY2VydGlmaWNhdGVzL0ludGVsJTIwRXh0ZXJu
YWwlMjBCYXNpYyUyMElzc3VpbmclMjBDQSUyMDNCKDEpLmNydDAfBgNVHSUEGDAWBggrBgEFBQcD
BAYKKwYBBAGCNwoDBDApBgkrBgEEAYI3FQoEHDAaMAoGCCsGAQUFBwMEMAwGCisGAQQBgjcKAwQw
RwYDVR0RBEAwPqAlBgorBgEEAYI3FAIDoBcMFWhhaXRhby5zaGFuQGludGVsLmNvbYEVaGFpdGFv
LnNoYW5AaW50ZWwuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQAqWvSRW8jKGuWVwUKo/+QRxKvuT3cv
/975omnwo7QeOj78XruY/Wsl6/tnzI8jgf6ZE5SRoj5sSGBHmy7qHSZNWodLuJgjN+a0Fk2hy0jB
wX2UJLS3ctijemo4e4u8/YFebLVXCzy81lWa7dZcidebnslLlcQXHNzl8hhFAfQwhcCXMAiA89NO
3uJqd9Sk/PSfG90b/f+1u2xIthxQmeh7u1yuiHZrf1u/e6rJWS50iW+LWmrH0c70XN8voHpLXVDo
09C9DETzJOUrhr1BqLVSxKjNn/uhCOcQxNYM3CYsgQBwVogKsGj59xeGFA5iWPKGRj7SfUXH0m3T
kiSaWLnWMYIDhjCCA4ICAQEwZDBWMQswCQYDVQQGEwJVUzEaMBgGA1UEChMRSW50ZWwgQ29ycG9y
YXRpb24xKzApBgNVBAMTIkludGVsIEV4dGVybmFsIEJhc2ljIElzc3VpbmcgQ0EgM0ICChMdOoEA
AQAAe60wCQYFKw4DAhoFAKCCAfcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0B
CQUxDxcNMTExMjIxMDEyODA0WjAjBgkqhkiG9w0BCQQxFgQUMyQay0mdCjMmwCPrDh52oTIVaNsw
cwYJKwYBBAGCNxAEMWYwZDBWMQswCQYDVQQGEwJVUzEaMBgGA1UEChMRSW50ZWwgQ29ycG9yYXRp
b24xKzApBgNVBAMTIkludGVsIEV4dGVybmFsIEJhc2ljIElzc3VpbmcgQ0EgM0ICChMjTTEAAQAA
e64wdQYLKoZIhvcNAQkQAgsxZqBkMFYxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFJbnRlbCBDb3Jw
b3JhdGlvbjErMCkGA1UEAxMiSW50ZWwgRXh0ZXJuYWwgQmFzaWMgSXNzdWluZyBDQSAzQgIKEyNN
MQABAAB7rjCBqwYJKoZIhvcNAQkPMYGdMIGaMAoGCCqGSIb3DQMHMAsGCWCGSAFlAwQBKjALBglg
hkgBZQMEARYwCwYJYIZIAWUDBAECMA4GCCqGSIb3DQMCAgIAgDAHBgUrDgMCBzANBggqhkiG9w0D
AgIBQDANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAsG
CWCGSAFlAwQCATANBgkqhkiG9w0BAQEFAASCAQBXgmRM1qvVW/SpfolYRerAWuXq6abjQfgBz73j
xiclVy/CzS1dkUK6HOzoL1/BD6SvLO9XYWOGBT/31CwsQFpVNLfmg5FmL6i8U1UV1Zg7GElPI++5
IQNxdyxWKAlAFvbQDHrDF8oMKDoLds5GYCtbduLo5rr2j3npKWlXJsdD6JtM4cW6xD46LPpiRni2
COzO8/oSSFlI87NXRow65yYmN0WQTZt8/3skpRv/PUW6tk1iJNcrSt4OnqIuc0Oq6m2hO5Gup0HX
n7yYoc5/QmoaOJG51YJGjnJMamFwlR1xXGwZhhLk28gSSZ6u60c0QoVDho4mymKJzNi6l5h40Q8/
AAAAAAAA

------=_NextPart_000_0000_01CCBFC2.D77D5E60--


--===============4631903993932103208==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============4631903993932103208==--


From xen-devel-bounces@lists.xensource.com Wed Dec 21 01:58:08 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 01: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.xensource.com>)
	id 1RdBR4-0007ce-Rh; Wed, 21 Dec 2011 01:57:38 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keith.coleman@n2servers.com>) id 1RdBR3-0007cZ-7c
	for xen-devel@lists.xensource.com; Wed, 21 Dec 2011 01:57:37 +0000
X-Env-Sender: keith.coleman@n2servers.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1324432651!6150143!1
X-Originating-IP: [209.85.215.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1191 invoked from network); 21 Dec 2011 01:57:31 -0000
Received: from mail-ey0-f171.google.com (HELO mail-ey0-f171.google.com)
	(209.85.215.171)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Dec 2011 01:57:31 -0000
Received: by eaad11 with SMTP id d11so24047850eaa.30
	for <xen-devel@lists.xensource.com>;
	Tue, 20 Dec 2011 17:57:31 -0800 (PST)
MIME-Version: 1.0
Received: by 10.204.153.216 with SMTP id l24mr1627034bkw.64.1324432650824;
	Tue, 20 Dec 2011 17:57:30 -0800 (PST)
Received: by 10.204.70.18 with HTTP; Tue, 20 Dec 2011 17:57:30 -0800 (PST)
X-Originating-IP: [75.127.125.83]
Date: Tue, 20 Dec 2011 20:57:30 -0500
Message-ID: <CAH4C7zGi+yd2uTmNOKm8PE_FaUqRgBdsLycA4F3T29vEYf-7wQ@mail.gmail.com>
From: Keith Coleman <keith.coleman@n2servers.com>
To: xen-devel <xen-devel@lists.xensource.com>
Subject: [Xen-devel] Xen 3.4.4 second release candidate
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

The second release candidate for Xen 3.4.4 is tagged at:
http://xenbits.xensource.com/xen-3.4-testing.hg (tag '3.4.4-rc2')

Please test!

--

Keith Coleman

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 21 01:58:08 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 01: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.xensource.com>)
	id 1RdBR4-0007ce-Rh; Wed, 21 Dec 2011 01:57:38 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keith.coleman@n2servers.com>) id 1RdBR3-0007cZ-7c
	for xen-devel@lists.xensource.com; Wed, 21 Dec 2011 01:57:37 +0000
X-Env-Sender: keith.coleman@n2servers.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1324432651!6150143!1
X-Originating-IP: [209.85.215.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1191 invoked from network); 21 Dec 2011 01:57:31 -0000
Received: from mail-ey0-f171.google.com (HELO mail-ey0-f171.google.com)
	(209.85.215.171)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Dec 2011 01:57:31 -0000
Received: by eaad11 with SMTP id d11so24047850eaa.30
	for <xen-devel@lists.xensource.com>;
	Tue, 20 Dec 2011 17:57:31 -0800 (PST)
MIME-Version: 1.0
Received: by 10.204.153.216 with SMTP id l24mr1627034bkw.64.1324432650824;
	Tue, 20 Dec 2011 17:57:30 -0800 (PST)
Received: by 10.204.70.18 with HTTP; Tue, 20 Dec 2011 17:57:30 -0800 (PST)
X-Originating-IP: [75.127.125.83]
Date: Tue, 20 Dec 2011 20:57:30 -0500
Message-ID: <CAH4C7zGi+yd2uTmNOKm8PE_FaUqRgBdsLycA4F3T29vEYf-7wQ@mail.gmail.com>
From: Keith Coleman <keith.coleman@n2servers.com>
To: xen-devel <xen-devel@lists.xensource.com>
Subject: [Xen-devel] Xen 3.4.4 second release candidate
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

The second release candidate for Xen 3.4.4 is tagged at:
http://xenbits.xensource.com/xen-3.4-testing.hg (tag '3.4.4-rc2')

Please test!

--

Keith Coleman

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 21 02:46:41 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 02:46:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdCBv-0008Hp-3D; Wed, 21 Dec 2011 02:46:03 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <250716708@qq.com>) id 1RdCBt-0008Hk-E1
	for xen-devel@lists.xensource.com; Wed, 21 Dec 2011 02:46:02 +0000
X-Env-Sender: 250716708@qq.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1324435554!8628005!1
X-Originating-IP: [64.71.138.43]
X-SpamReason: No, hits=2.6 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA2NC43MS4xMzguNDMgPT4gMjgzNzM5\n,sa_preprocessor: 
	QmFkIElQOiA2NC43MS4xMzguNDMgPT4gMjgzNzM5\n,FROM_ALL_NUMS,
	FROM_STARTS_WITH_NUMS,HTML_40_50,HTML_MESSAGE,MIME_BASE64_TEXT,
	MIME_BOUND_NEXTPART,received_headers: No Received headers
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18041 invoked from network); 21 Dec 2011 02:45:54 -0000
Received: from smtpbg52.qq.com (HELO smtpbg52.qq.com) (64.71.138.43)
	by server-11.tower-21.messagelabs.com with SMTP;
	21 Dec 2011 02:45:54 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qq.com; s=s0907;
	t=1324435543; bh=bSMdYPDmKW6OFKqEkN3dJoH2YWuyzmOQE2QRl+F+b5M=;
	h=X-QQ-SSF:X-HAS-ATTACH:X-QQ-BUSINESS-ORIGIN:X-Originating-IP:
	X-QQ-STYLE:X-QQ-mid:From:To:Cc:Subject:Mime-Version:Content-Type:
	Content-Transfer-Encoding:Date:X-Priority:Message-ID:X-QQ-MIME:
	X-Mailer:X-QQ-Mailer:X-QQ-ReplyHash;
	b=JWEZcm8+Olt9ROHVJZnopW+/pSH1BYrqWGjissYsmHzoRu4b9YmFKPlv3A6ALgXSg
	cAyYW6OTgzhWZ13qj/X53lU8DfJRaquJgFlL7YhIqdbHLRkX78K3IcbIe5oSpaG
X-QQ-SSF: 00000000000000F0000000000000000
X-HAS-ATTACH: no
X-QQ-BUSINESS-ORIGIN: 2
X-Originating-IP: 118.192.67.234
X-QQ-STYLE: 
X-QQ-mid: webmail106t1324435540t8056658
From: "=?gbk?B?oei9S+y2YXdhcmU=?=" <250716708@qq.com>
To: "=?gbk?B?QW50aG9ueSBQRVJBUkQ=?=" <anthony.perard@citrix.com>
Mime-Version: 1.0
Date: Wed, 21 Dec 2011 10:45:40 +0800
X-Priority: 3
Message-ID: <tencent_5E61757F6647880E317AB630@qq.com>
X-QQ-MIME: TCMime 1.0 by Tencent
X-Mailer: QQMail 2.x
X-QQ-Mailer: QQMail 2.x
X-QQ-ReplyHash: 3645358453
Cc: =?gbk?B?eGVuLWRldmVs?= <xen-devel@lists.xensource.com>,
	=?gbk?B?cWVtdS1kZXZlbA==?= <qemu-devel@nongnu.org>
Subject: [Xen-devel] problem with 'xm save' in xen-3.4
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============4046104227291001374=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a multi-part message in MIME format.

--===============4046104227291001374==
Content-Type: multipart/alternative;
	boundary="----=_NextPart_4EF14854_DCBABC68_64CA86BC"
Content-Transfer-Encoding: 8Bit

This is a multi-part message in MIME format.

------=_NextPart_4EF14854_DCBABC68_64CA86BC
Content-Type: text/plain;
	charset="gbk"
Content-Transfer-Encoding: base64

SGksDQogICAgIHRoZSBwcm9ibGVtIGlzIGFzIGZvbGxvd3M6KEFuZCB0aGVuLCBvdGhlcnMg
Y2FuJ3QgbG9naW4gbW9zdGx5IGJlY2F1c2Ugb2YgdGhlIG9zJyBidXNpbmcgYW5kIHlvdSBj
YW4ndCBkbyBhbnl0aGluZyBlbHNlLikNCiBbKipAeGVudGVzdCA6Osj9IDEy1MIgMjE6On5d
JCBzdWRvIHhtIGxpc3QNCk5hbWUgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgSUQgICBNZW0gVkNQVXMgICAgICBTdGF0ZSAgIFRpbWUocykNCkRvbWFpbi0wICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDAgIDE3NDggICAgIDIgICAgIHIt
LS0tLSAgMjkzOTYuMw0KeHAtMTAxICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgMSAgIDI1NiAgICAgMSAgICAgLWItLS0tICAgNDY4NS44DQogICANCiBbKipAeGVu
dGVzdCA6Osj9IDEy1MIgMjE6On5dJCBzdWRvIHhtIHNhdmUgMSAxLnNhdmUNCiBNZXNzYWdl
IGZyb20gc3lzbG9nZEAgYXQgV2VkIERlYyAyMSAxMDoyNzoxMCAyMDExIC4uLg0KeGVudGVz
dCBrZXJuZWw6IHVucmVnaXN0ZXJfbmV0ZGV2aWNlOiB3YWl0aW5nIGZvciB0YXAxLjAgdG8g
YmVjb21lIGZyZWUuIFVzYWdlIGNvdW50ID0gMQ0KIA0KTWVzc2FnZSBmcm9tIHN5c2xvZ2RA
IGF0IFdlZCBEZWMgMjEgMTA6Mjc6NDEgMjAxMSAuLi4NCnhlbnRlc3QgbGFzdCBtZXNzYWdl
IHJlcGVhdGVkIDMgdGltZXMNCk1lc3NhZ2UgZnJvbSBzeXNsb2dkQCBhdCBXZWQgRGVjIDIx
IDEwOjI4OjUyIDIwMTEgLi4uDQp4ZW50ZXN0IGxhc3QgbWVzc2FnZSByZXBlYXRlZCA3IHRp
bWVzDQogLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4NCiAgDQogIC0tLS0tLS0tLS0tLS0tLS0t
LSDUrcq808q8/iAtLS0tLS0tLS0tLS0tLS0tLS0NCiAgt6K8/sjLOiAiQW50aG9ueSBQRVJB
UkQiPGFudGhvbnkucGVyYXJkQGNpdHJpeC5jb20+Ow0KILeiy83KsbzkOiAyMDExxOoxMtTC
MjDI1SjQx8batv4pIM3tyc85OjQ4DQogytW8/sjLOiAiU3RlZmFuIEhham5vY3ppIjxzdGVm
YW5oYUBnbWFpbC5jb20+OyANCiCzrcvNOiAioei9S+y2YXdhcmUiPDI1MDcxNjcwOEBxcS5j
b20+OyAicWVtdS1kZXZlbCI8cWVtdS1kZXZlbEBub25nbnUub3JnPjsgIlN0ZWZhbm8gU3Rh
YmVsbGluaSI8U3RlZmFuby5TdGFiZWxsaW5pQGV1LmNpdHJpeC5jb20+OyAiWGVuIERldmVs
Ijx4ZW4tZGV2ZWxAbGlzdHMueGVuc291cmNlLmNvbT47IA0KINb3zOI6IFJlOiC72Li0o7og
W1FlbXUtZGV2ZWxdIGRlYnVnaW5nIGFib3V0IHFlbXUtZG0gaW4geGVuIDMuNC4yDQoNCiAg
DQpPbiBUdWUsIDIwIERlYyAyMDExLCBTdGVmYW4gSGFqbm9jemkgd3JvdGU6DQoNCj4gMjAx
MS8xMi8yMCCh6L1L7LZhd2FyZSA8MjUwNzE2NzA4QHFxLmNvbT46DQo+ID4gICAgIEkgd2Fu
dCB0byBjcmVhdGUgYSBtZW1vcnkgc25hcHNob3QgZmlsZSAoc3VjaCBhcyBtbS5zbmFwKSBv
ZiBjdXJyZW50DQo+ID4gdmlydHVhbCBtYWNoaW5lIGFuZCAgdGhlIG1tLnNuYXAgY2FuIGJl
IHVzZWQgYXMgYSBhcmcgb2YgcWVtdSBjbWQtbGluZSBmb3INCj4gPiByZXN0b3JpbmcgdGhl
IGxhc3QgbWVtb3J5IGNvbmRpdGlvbi4NCj4gPiAgICAgQnV0IEkgYW0gbm90IHZlcnkgY2xl
YXIgYWJvdXQgdGhlIHN0cnVjdHVyZSBvZiB0aGUgcWVtdS1kbSBzb3VyY2UgY29kZS4NCj4g
PiBBbHRob3VnaCBvYnNlcnZpbmcgdGhlIG91dHB1dCBvZiBleGVjdXRpb24gaXMgdGhlIHN0
cmFpZ2h0Zm9yd2FyZCB3YXksIGhpZ2gNCj4gPiBmcmVxdWVuY3kgb2YgcHJpbnRmICBhbmQg
cmUtY29tcGxpbmcgaXMgdG9vIGluY292ZW5pZW50IHRvIHB1dCBpbnRvIGVmZmVjdC4NCj4N
Cj4gUGxlYXNlIGtlZXAgcWVtdS1kZXZlbEBub25nbnUub3JnIENDZWQgc28gb3RoZXJzIGNh
biBjb250cmlidXRlIHRvIHRoZQ0KPiBkaXNjdXNzaW9uLg0KPg0KPiBRRU1VIG9ubHkgZGVh
bHMgd2l0aCB2aXJ0dWFsIG1lbW9yeSB3aGVuIHNpbXVsYXRpbmcgYW4gTU1VIChmb3INCj4g
QVJNLW9uLXg4NiBzeXN0ZW0gdHJhbnNsYXRpb24pLiAgVGhlIGRldmljZSBtb2RlbCB1c3Vh
bGx5IG9wZXJhdGVzIG9uDQo+IHBoeXNpY2FsIFJBTSBvciBidXMgYWRkcmVzc2VzLg0KPg0K
PiBTdGVmYW5vIG9yIEFudGhvbnkgY2FuIGV4cGxhaW4gdGhlIHFlbXUtZG0gc3BlY2lmaWNz
LiAgSXQncyBzdGlsbCBub3QNCj4gY2xlYXIgdG8gbWUgd2hhdCB5b3UncmUgdHJ5aW5nIHRv
IG9ic2VydmUgLSBxZW11LWRtIGlzIG5vdCB3aGVyZSBJJ2QNCj4gdHJ5IHRvIG9ic2VydmUg
ZG9tYWluIG1lbW9yeSB1bmRlciBYZW4gYnV0IGl0J3MgdGhlIHJpZ2h0IHBsYWNlIHRvDQo+
IG9ic2VydmUgZW11bGF0ZWQgZGV2aWNlcy4NCg0KQ2NlZCBYZW4tZGV2ZWwgYXMgd2VsbC4N
Cg0KWW91IGNhbiBzYXZlIGEgZG9tYWluIHN0YXRlIHVzaW5nIHRoZSB0b29sIHN0YWNrIChw
cm9iYWJseSBgeG0gc2F2ZWANCndpdGggWGVuIDMuNCkgYW5kIHJlc3RvcmUgaXQgYXMgbWFu
eSB0aW1lIGFzIHlvdSB3YW50Lg0KDQpUbyBydW4gZ2RiIG9uIHFlbXUtZG0sIHJlbXBsYWNl
IHRoZSAvdXNyL2xpYi94ZW4vYmluL3FlbXUtZG0gYnkgYQ0Kc2NyaXB0Og0KIyEvYmluL3No
DQpleGVjIGdkYnNlcnZlciAwLjAuMC4wOjEyMzQgL3Vzci9saWIveGVuL2Jpbi9xZW11LWRt
LmJhayAkQA0KDQpBbmQgcnVuIGdkYi4gYHRhcmdldCByZW1vdGUgbG9jYWxob3N0IDEyMzRg
IHRvIGNvbm5lY3QgdG8gZ2Ric2VydmVyLg0KDQpXaXRoIHRoZSBsYXRlc3QgWGVuICg0LjEg
YW5kIHVuc3RhYmxlKSwgeW91IGNhbiBzcGVjaWZpZSBhIGRpZmZlcmVudA0KZGV2aWNlIG1v
ZGVsIGluIHRoZSBjb25maWcgZmlsZSBpbnN0ZWFkIG9mIHJlbXBsYWNpbmcgdGhlIGRlZmF1
bHQNCmJpbmFyeS4NCg0KUmVnYXJkcywNCg0KLS0gDQpBbnRob255IFBFUkFSRA==

------=_NextPart_4EF14854_DCBABC68_64CA86BC
Content-Type: text/html;
	charset="gbk"
Content-Transfer-Encoding: base64

PERJVj5IaSw8L0RJVj4NCjxESVY+Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRoZSBwcm9ibGVtIGlz
IGFzIGZvbGxvd3M6KEFuZCB0aGVuLCBvdGhlcnMgY2FuJ3QgbG9naW4mbmJzcDttb3N0bHkm
bmJzcDtiZWNhdXNlIG9mIHRoZSBvcycgYnVzaW5nIGFuZCB5b3UgY2FuJ3QgZG8gYW55dGhp
bmcgZWxzZS4pPC9ESVY+DQo8RElWPlsqKkB4ZW50ZXN0IDo6yP0gMTLUwiAyMTo6fl0kIHN1
ZG8geG0gbGlzdDxCUj5OYW1lJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IElEJm5ic3A7Jm5ic3A7IE1l
bSBWQ1BVcyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBTdGF0ZSZuYnNwOyZuYnNw
OyBUaW1lKHMpPEJSPkRvbWFpbi0wJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDAmbmJzcDsgMTc0OCZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyAyJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHItLS0tLSZuYnNwOyAyOTM5Ni4zPEJS
PnhwLTEwMSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyAxJm5ic3A7Jm5ic3A7IDI1NiZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyAxJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC1iLS0tLSZuYnNwOyZuYnNwOyA0
Njg1Ljg8L0RJVj4NCjxESVY+PGluY2x1ZGV0YWlsPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxE
SVY+WyoqQHhlbnRlc3QgOjrI/SAxMtTCIDIxOjp+XSQgc3VkbyB4bSBzYXZlIDEgMS5zYXZl
PC9ESVY+DQo8RElWPk1lc3NhZ2UgZnJvbSBzeXNsb2dkQCBhdCBXZWQgRGVjIDIxIDEwOjI3
OjEwIDIwMTEgLi4uPEJSPnhlbnRlc3Qga2VybmVsOiB1bnJlZ2lzdGVyX25ldGRldmljZTog
d2FpdGluZyBmb3IgdGFwMS4wIHRvIGJlY29tZSBmcmVlLiBVc2FnZSBjb3VudCA9IDE8L0RJ
Vj4NCjxESVY+PEJSPk1lc3NhZ2UgZnJvbSBzeXNsb2dkQCBhdCBXZWQgRGVjIDIxIDEwOjI3
OjQxIDIwMTEgLi4uPEJSPnhlbnRlc3QgbGFzdCBtZXNzYWdlIHJlcGVhdGVkIDMgdGltZXM8
QlI+TWVzc2FnZSBmcm9tIHN5c2xvZ2RAIGF0IFdlZCBEZWMgMjEgMTA6Mjg6NTIgMjAxMSAu
Li48QlI+eGVudGVzdCBsYXN0IG1lc3NhZ2UgcmVwZWF0ZWQgNyB0aW1lczwvRElWPg0KPERJ
Vj4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxE
SVYgc3R5bGU9IkNPTE9SOiAjMDAwIj4NCjxESVYgc3R5bGU9IlBBRERJTkctQk9UVE9NOiAy
cHg7IFBBRERJTkctTEVGVDogMHB4OyBQQURESU5HLVJJR0hUOiAwcHg7IEZPTlQtRkFNSUxZ
OiBBcmlhbCBOYXJyb3c7IEZPTlQtU0laRTogMTJweDsgUEFERElORy1UT1A6IDJweCI+LS0t
LS0tLS0tLS0tLS0tLS0tJm5ic3A71K3KvNPKvP4mbmJzcDstLS0tLS0tLS0tLS0tLS0tLS08
L0RJVj4NCjxESVYgc3R5bGU9IlBBRERJTkctQk9UVE9NOiA4cHg7IFBBRERJTkctTEVGVDog
OHB4OyBQQURESU5HLVJJR0hUOiA4cHg7IEJBQ0tHUk9VTkQ6ICNlZmVmZWY7IEZPTlQtU0la
RTogMTJweDsgUEFERElORy1UT1A6IDhweCI+DQo8RElWIGlkPW1lbnVfc2VuZGVyPjxCPrei
vP7Iyzo8L0I+Jm5ic3A7IkFudGhvbnkgUEVSQVJEIiZsdDthbnRob255LnBlcmFyZEBjaXRy
aXguY29tJmd0Ozs8L0RJVj4NCjxESVY+PEI+t6LLzcqxvOQ6PC9CPiZuYnNwOzIwMTHE6jEy
1MIyMMjVKNDHxtq2/ikgze3Jzzk6NDg8L0RJVj4NCjxESVY+PEI+ytW8/sjLOjwvQj4mbmJz
cDsiU3RlZmFuIEhham5vY3ppIiZsdDtzdGVmYW5oYUBnbWFpbC5jb20mZ3Q7OyA8V0JSPjwv
RElWPg0KPERJVj48Qj6zrcvNOjwvQj4mbmJzcDsioei9S+y2YXdhcmUiJmx0OzI1MDcxNjcw
OEBxcS5jb20mZ3Q7OyAicWVtdS1kZXZlbCImbHQ7cWVtdS1kZXZlbEBub25nbnUub3JnJmd0
OzsgIlN0ZWZhbm8gU3RhYmVsbGluaSImbHQ7U3RlZmFuby5TdGFiZWxsaW5pQGV1LmNpdHJp
eC5jb20mZ3Q7OyAiWGVuIERldmVsIiZsdDt4ZW4tZGV2ZWxAbGlzdHMueGVuc291cmNlLmNv
bSZndDs7IDxXQlI+PC9ESVY+DQo8RElWPjxCPtb3zOI6PC9CPiZuYnNwO1JlOiC72Li0o7og
W1FlbXUtZGV2ZWxdIGRlYnVnaW5nIGFib3V0IHFlbXUtZG0gaW4geGVuIDMuNC4yPC9ESVY+
PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPk9uIFR1ZSwgMjAgRGVjIDIwMTEsIFN0ZWZhbiBI
YWpub2N6aSB3cm90ZTo8QlI+PEJSPiZndDsgMjAxMS8xMi8yMCCh6L1L7LZhd2FyZSAmbHQ7
MjUwNzE2NzA4QHFxLmNvbSZndDs6PEJSPiZndDsgJmd0OyAmbmJzcDsmbmJzcDsmbmJzcDsg
SSZuYnNwO3dhbnQgdG8gY3JlYXRlIGEgbWVtb3J5IHNuYXBzaG90IGZpbGUgKHN1Y2ggYXMg
bW0uc25hcCkgb2YgY3VycmVudDxCUj4mZ3Q7ICZndDsgdmlydHVhbCBtYWNoaW5lIGFuZCZu
YnNwOyB0aGUgbW0uc25hcCBjYW4gYmUgdXNlZCBhcyBhIGFyZyBvZiBxZW11IGNtZC1saW5l
IGZvcjxCUj4mZ3Q7ICZndDsgcmVzdG9yaW5nIHRoZSBsYXN0IG1lbW9yeSBjb25kaXRpb24u
PEJSPiZndDsgJmd0OyAmbmJzcDsmbmJzcDsmbmJzcDsgQnV0IEkgYW0gbm90IHZlcnkgY2xl
YXIgYWJvdXQgdGhlIHN0cnVjdHVyZSBvZiB0aGUgcWVtdS1kbSBzb3VyY2UgY29kZS48QlI+
Jmd0OyAmZ3Q7IEFsdGhvdWdoJm5ic3A7b2JzZXJ2aW5nIHRoZSBvdXRwdXQgb2YgZXhlY3V0
aW9uIGlzIHRoZSBzdHJhaWdodGZvcndhcmQgd2F5LCBoaWdoPEJSPiZndDsgJmd0OyBmcmVx
dWVuY3kgb2YgcHJpbnRmJm5ic3A7IGFuZCByZS1jb21wbGluZyBpcyB0b28gaW5jb3Zlbmll
bnQgdG8gcHV0IGludG8gZWZmZWN0LjxCUj4mZ3Q7PEJSPiZndDsgUGxlYXNlIGtlZXAgcWVt
dS1kZXZlbEBub25nbnUub3JnIENDZWQgc28gb3RoZXJzIGNhbiBjb250cmlidXRlIHRvIHRo
ZTxCUj4mZ3Q7IGRpc2N1c3Npb24uPEJSPiZndDs8QlI+Jmd0OyBRRU1VIG9ubHkgZGVhbHMg
d2l0aCB2aXJ0dWFsIG1lbW9yeSB3aGVuIHNpbXVsYXRpbmcgYW4gTU1VIChmb3I8QlI+Jmd0
OyBBUk0tb24teDg2IHN5c3RlbSB0cmFuc2xhdGlvbikuJm5ic3A7IFRoZSBkZXZpY2UgbW9k
ZWwgdXN1YWxseSBvcGVyYXRlcyBvbjxCUj4mZ3Q7IHBoeXNpY2FsIFJBTSBvciBidXMgYWRk
cmVzc2VzLjxCUj4mZ3Q7PEJSPiZndDsgU3RlZmFubyBvciBBbnRob255IGNhbiBleHBsYWlu
IHRoZSBxZW11LWRtIHNwZWNpZmljcy4mbmJzcDsgSXQncyBzdGlsbCBub3Q8QlI+Jmd0OyBj
bGVhciB0byBtZSB3aGF0IHlvdSdyZSB0cnlpbmcgdG8gb2JzZXJ2ZSAtIHFlbXUtZG0gaXMg
bm90IHdoZXJlIEknZDxCUj4mZ3Q7IHRyeSB0byBvYnNlcnZlIGRvbWFpbiBtZW1vcnkgdW5k
ZXIgWGVuIGJ1dCBpdCdzIHRoZSByaWdodCBwbGFjZSB0bzxCUj4mZ3Q7IG9ic2VydmUgZW11
bGF0ZWQgZGV2aWNlcy48QlI+PEJSPkNjZWQgWGVuLWRldmVsIGFzIHdlbGwuPEJSPjxCUj5Z
b3UgY2FuIHNhdmUgYSBkb21haW4gc3RhdGUgdXNpbmcgdGhlIHRvb2wgc3RhY2sgKHByb2Jh
Ymx5IGB4bSBzYXZlYDxCUj53aXRoIFhlbiAzLjQpIGFuZCByZXN0b3JlIGl0IGFzIG1hbnkg
dGltZSBhcyB5b3Ugd2FudC48QlI+PEJSPlRvIHJ1biBnZGIgb24gcWVtdS1kbSwgcmVtcGxh
Y2UgdGhlIC91c3IvbGliL3hlbi9iaW4vcWVtdS1kbSBieSBhPEJSPnNjcmlwdDo8QlI+IyEv
YmluL3NoPEJSPmV4ZWMgZ2Ric2VydmVyIDAuMC4wLjA6MTIzNCAvdXNyL2xpYi94ZW4vYmlu
L3FlbXUtZG0uYmFrICRAPEJSPjxCUj5BbmQgcnVuIGdkYi4gYHRhcmdldCByZW1vdGUgbG9j
YWxob3N0IDEyMzRgIHRvIGNvbm5lY3QgdG8gZ2Ric2VydmVyLjxCUj48QlI+V2l0aCB0aGUg
bGF0ZXN0IFhlbiAoNC4xIGFuZCB1bnN0YWJsZSksIHlvdSBjYW4gc3BlY2lmaWUgYSBkaWZm
ZXJlbnQ8QlI+ZGV2aWNlIG1vZGVsIGluIHRoZSBjb25maWcgZmlsZSBpbnN0ZWFkIG9mIHJl
bXBsYWNpbmcgdGhlIGRlZmF1bHQ8QlI+YmluYXJ5LjxCUj48QlI+UmVnYXJkcyw8QlI+PEJS
Pi0tIDxCUj5BbnRob255IFBFUkFSRDxCUj48L0RJVj48L2luY2x1ZGV0YWlsPjwvRElWPg==

------=_NextPart_4EF14854_DCBABC68_64CA86BC--



--===============4046104227291001374==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============4046104227291001374==--



From xen-devel-bounces@lists.xensource.com Wed Dec 21 02:46:41 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 02:46:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdCBv-0008Hp-3D; Wed, 21 Dec 2011 02:46:03 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <250716708@qq.com>) id 1RdCBt-0008Hk-E1
	for xen-devel@lists.xensource.com; Wed, 21 Dec 2011 02:46:02 +0000
X-Env-Sender: 250716708@qq.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1324435554!8628005!1
X-Originating-IP: [64.71.138.43]
X-SpamReason: No, hits=2.6 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA2NC43MS4xMzguNDMgPT4gMjgzNzM5\n,sa_preprocessor: 
	QmFkIElQOiA2NC43MS4xMzguNDMgPT4gMjgzNzM5\n,FROM_ALL_NUMS,
	FROM_STARTS_WITH_NUMS,HTML_40_50,HTML_MESSAGE,MIME_BASE64_TEXT,
	MIME_BOUND_NEXTPART,received_headers: No Received headers
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18041 invoked from network); 21 Dec 2011 02:45:54 -0000
Received: from smtpbg52.qq.com (HELO smtpbg52.qq.com) (64.71.138.43)
	by server-11.tower-21.messagelabs.com with SMTP;
	21 Dec 2011 02:45:54 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qq.com; s=s0907;
	t=1324435543; bh=bSMdYPDmKW6OFKqEkN3dJoH2YWuyzmOQE2QRl+F+b5M=;
	h=X-QQ-SSF:X-HAS-ATTACH:X-QQ-BUSINESS-ORIGIN:X-Originating-IP:
	X-QQ-STYLE:X-QQ-mid:From:To:Cc:Subject:Mime-Version:Content-Type:
	Content-Transfer-Encoding:Date:X-Priority:Message-ID:X-QQ-MIME:
	X-Mailer:X-QQ-Mailer:X-QQ-ReplyHash;
	b=JWEZcm8+Olt9ROHVJZnopW+/pSH1BYrqWGjissYsmHzoRu4b9YmFKPlv3A6ALgXSg
	cAyYW6OTgzhWZ13qj/X53lU8DfJRaquJgFlL7YhIqdbHLRkX78K3IcbIe5oSpaG
X-QQ-SSF: 00000000000000F0000000000000000
X-HAS-ATTACH: no
X-QQ-BUSINESS-ORIGIN: 2
X-Originating-IP: 118.192.67.234
X-QQ-STYLE: 
X-QQ-mid: webmail106t1324435540t8056658
From: "=?gbk?B?oei9S+y2YXdhcmU=?=" <250716708@qq.com>
To: "=?gbk?B?QW50aG9ueSBQRVJBUkQ=?=" <anthony.perard@citrix.com>
Mime-Version: 1.0
Date: Wed, 21 Dec 2011 10:45:40 +0800
X-Priority: 3
Message-ID: <tencent_5E61757F6647880E317AB630@qq.com>
X-QQ-MIME: TCMime 1.0 by Tencent
X-Mailer: QQMail 2.x
X-QQ-Mailer: QQMail 2.x
X-QQ-ReplyHash: 3645358453
Cc: =?gbk?B?eGVuLWRldmVs?= <xen-devel@lists.xensource.com>,
	=?gbk?B?cWVtdS1kZXZlbA==?= <qemu-devel@nongnu.org>
Subject: [Xen-devel] problem with 'xm save' in xen-3.4
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============4046104227291001374=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a multi-part message in MIME format.

--===============4046104227291001374==
Content-Type: multipart/alternative;
	boundary="----=_NextPart_4EF14854_DCBABC68_64CA86BC"
Content-Transfer-Encoding: 8Bit

This is a multi-part message in MIME format.

------=_NextPart_4EF14854_DCBABC68_64CA86BC
Content-Type: text/plain;
	charset="gbk"
Content-Transfer-Encoding: base64

SGksDQogICAgIHRoZSBwcm9ibGVtIGlzIGFzIGZvbGxvd3M6KEFuZCB0aGVuLCBvdGhlcnMg
Y2FuJ3QgbG9naW4gbW9zdGx5IGJlY2F1c2Ugb2YgdGhlIG9zJyBidXNpbmcgYW5kIHlvdSBj
YW4ndCBkbyBhbnl0aGluZyBlbHNlLikNCiBbKipAeGVudGVzdCA6Osj9IDEy1MIgMjE6On5d
JCBzdWRvIHhtIGxpc3QNCk5hbWUgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgSUQgICBNZW0gVkNQVXMgICAgICBTdGF0ZSAgIFRpbWUocykNCkRvbWFpbi0wICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDAgIDE3NDggICAgIDIgICAgIHIt
LS0tLSAgMjkzOTYuMw0KeHAtMTAxICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgMSAgIDI1NiAgICAgMSAgICAgLWItLS0tICAgNDY4NS44DQogICANCiBbKipAeGVu
dGVzdCA6Osj9IDEy1MIgMjE6On5dJCBzdWRvIHhtIHNhdmUgMSAxLnNhdmUNCiBNZXNzYWdl
IGZyb20gc3lzbG9nZEAgYXQgV2VkIERlYyAyMSAxMDoyNzoxMCAyMDExIC4uLg0KeGVudGVz
dCBrZXJuZWw6IHVucmVnaXN0ZXJfbmV0ZGV2aWNlOiB3YWl0aW5nIGZvciB0YXAxLjAgdG8g
YmVjb21lIGZyZWUuIFVzYWdlIGNvdW50ID0gMQ0KIA0KTWVzc2FnZSBmcm9tIHN5c2xvZ2RA
IGF0IFdlZCBEZWMgMjEgMTA6Mjc6NDEgMjAxMSAuLi4NCnhlbnRlc3QgbGFzdCBtZXNzYWdl
IHJlcGVhdGVkIDMgdGltZXMNCk1lc3NhZ2UgZnJvbSBzeXNsb2dkQCBhdCBXZWQgRGVjIDIx
IDEwOjI4OjUyIDIwMTEgLi4uDQp4ZW50ZXN0IGxhc3QgbWVzc2FnZSByZXBlYXRlZCA3IHRp
bWVzDQogLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4NCiAgDQogIC0tLS0tLS0tLS0tLS0tLS0t
LSDUrcq808q8/iAtLS0tLS0tLS0tLS0tLS0tLS0NCiAgt6K8/sjLOiAiQW50aG9ueSBQRVJB
UkQiPGFudGhvbnkucGVyYXJkQGNpdHJpeC5jb20+Ow0KILeiy83KsbzkOiAyMDExxOoxMtTC
MjDI1SjQx8batv4pIM3tyc85OjQ4DQogytW8/sjLOiAiU3RlZmFuIEhham5vY3ppIjxzdGVm
YW5oYUBnbWFpbC5jb20+OyANCiCzrcvNOiAioei9S+y2YXdhcmUiPDI1MDcxNjcwOEBxcS5j
b20+OyAicWVtdS1kZXZlbCI8cWVtdS1kZXZlbEBub25nbnUub3JnPjsgIlN0ZWZhbm8gU3Rh
YmVsbGluaSI8U3RlZmFuby5TdGFiZWxsaW5pQGV1LmNpdHJpeC5jb20+OyAiWGVuIERldmVs
Ijx4ZW4tZGV2ZWxAbGlzdHMueGVuc291cmNlLmNvbT47IA0KINb3zOI6IFJlOiC72Li0o7og
W1FlbXUtZGV2ZWxdIGRlYnVnaW5nIGFib3V0IHFlbXUtZG0gaW4geGVuIDMuNC4yDQoNCiAg
DQpPbiBUdWUsIDIwIERlYyAyMDExLCBTdGVmYW4gSGFqbm9jemkgd3JvdGU6DQoNCj4gMjAx
MS8xMi8yMCCh6L1L7LZhd2FyZSA8MjUwNzE2NzA4QHFxLmNvbT46DQo+ID4gICAgIEkgd2Fu
dCB0byBjcmVhdGUgYSBtZW1vcnkgc25hcHNob3QgZmlsZSAoc3VjaCBhcyBtbS5zbmFwKSBv
ZiBjdXJyZW50DQo+ID4gdmlydHVhbCBtYWNoaW5lIGFuZCAgdGhlIG1tLnNuYXAgY2FuIGJl
IHVzZWQgYXMgYSBhcmcgb2YgcWVtdSBjbWQtbGluZSBmb3INCj4gPiByZXN0b3JpbmcgdGhl
IGxhc3QgbWVtb3J5IGNvbmRpdGlvbi4NCj4gPiAgICAgQnV0IEkgYW0gbm90IHZlcnkgY2xl
YXIgYWJvdXQgdGhlIHN0cnVjdHVyZSBvZiB0aGUgcWVtdS1kbSBzb3VyY2UgY29kZS4NCj4g
PiBBbHRob3VnaCBvYnNlcnZpbmcgdGhlIG91dHB1dCBvZiBleGVjdXRpb24gaXMgdGhlIHN0
cmFpZ2h0Zm9yd2FyZCB3YXksIGhpZ2gNCj4gPiBmcmVxdWVuY3kgb2YgcHJpbnRmICBhbmQg
cmUtY29tcGxpbmcgaXMgdG9vIGluY292ZW5pZW50IHRvIHB1dCBpbnRvIGVmZmVjdC4NCj4N
Cj4gUGxlYXNlIGtlZXAgcWVtdS1kZXZlbEBub25nbnUub3JnIENDZWQgc28gb3RoZXJzIGNh
biBjb250cmlidXRlIHRvIHRoZQ0KPiBkaXNjdXNzaW9uLg0KPg0KPiBRRU1VIG9ubHkgZGVh
bHMgd2l0aCB2aXJ0dWFsIG1lbW9yeSB3aGVuIHNpbXVsYXRpbmcgYW4gTU1VIChmb3INCj4g
QVJNLW9uLXg4NiBzeXN0ZW0gdHJhbnNsYXRpb24pLiAgVGhlIGRldmljZSBtb2RlbCB1c3Vh
bGx5IG9wZXJhdGVzIG9uDQo+IHBoeXNpY2FsIFJBTSBvciBidXMgYWRkcmVzc2VzLg0KPg0K
PiBTdGVmYW5vIG9yIEFudGhvbnkgY2FuIGV4cGxhaW4gdGhlIHFlbXUtZG0gc3BlY2lmaWNz
LiAgSXQncyBzdGlsbCBub3QNCj4gY2xlYXIgdG8gbWUgd2hhdCB5b3UncmUgdHJ5aW5nIHRv
IG9ic2VydmUgLSBxZW11LWRtIGlzIG5vdCB3aGVyZSBJJ2QNCj4gdHJ5IHRvIG9ic2VydmUg
ZG9tYWluIG1lbW9yeSB1bmRlciBYZW4gYnV0IGl0J3MgdGhlIHJpZ2h0IHBsYWNlIHRvDQo+
IG9ic2VydmUgZW11bGF0ZWQgZGV2aWNlcy4NCg0KQ2NlZCBYZW4tZGV2ZWwgYXMgd2VsbC4N
Cg0KWW91IGNhbiBzYXZlIGEgZG9tYWluIHN0YXRlIHVzaW5nIHRoZSB0b29sIHN0YWNrIChw
cm9iYWJseSBgeG0gc2F2ZWANCndpdGggWGVuIDMuNCkgYW5kIHJlc3RvcmUgaXQgYXMgbWFu
eSB0aW1lIGFzIHlvdSB3YW50Lg0KDQpUbyBydW4gZ2RiIG9uIHFlbXUtZG0sIHJlbXBsYWNl
IHRoZSAvdXNyL2xpYi94ZW4vYmluL3FlbXUtZG0gYnkgYQ0Kc2NyaXB0Og0KIyEvYmluL3No
DQpleGVjIGdkYnNlcnZlciAwLjAuMC4wOjEyMzQgL3Vzci9saWIveGVuL2Jpbi9xZW11LWRt
LmJhayAkQA0KDQpBbmQgcnVuIGdkYi4gYHRhcmdldCByZW1vdGUgbG9jYWxob3N0IDEyMzRg
IHRvIGNvbm5lY3QgdG8gZ2Ric2VydmVyLg0KDQpXaXRoIHRoZSBsYXRlc3QgWGVuICg0LjEg
YW5kIHVuc3RhYmxlKSwgeW91IGNhbiBzcGVjaWZpZSBhIGRpZmZlcmVudA0KZGV2aWNlIG1v
ZGVsIGluIHRoZSBjb25maWcgZmlsZSBpbnN0ZWFkIG9mIHJlbXBsYWNpbmcgdGhlIGRlZmF1
bHQNCmJpbmFyeS4NCg0KUmVnYXJkcywNCg0KLS0gDQpBbnRob255IFBFUkFSRA==

------=_NextPart_4EF14854_DCBABC68_64CA86BC
Content-Type: text/html;
	charset="gbk"
Content-Transfer-Encoding: base64

PERJVj5IaSw8L0RJVj4NCjxESVY+Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRoZSBwcm9ibGVtIGlz
IGFzIGZvbGxvd3M6KEFuZCB0aGVuLCBvdGhlcnMgY2FuJ3QgbG9naW4mbmJzcDttb3N0bHkm
bmJzcDtiZWNhdXNlIG9mIHRoZSBvcycgYnVzaW5nIGFuZCB5b3UgY2FuJ3QgZG8gYW55dGhp
bmcgZWxzZS4pPC9ESVY+DQo8RElWPlsqKkB4ZW50ZXN0IDo6yP0gMTLUwiAyMTo6fl0kIHN1
ZG8geG0gbGlzdDxCUj5OYW1lJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IElEJm5ic3A7Jm5ic3A7IE1l
bSBWQ1BVcyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBTdGF0ZSZuYnNwOyZuYnNw
OyBUaW1lKHMpPEJSPkRvbWFpbi0wJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDAmbmJzcDsgMTc0OCZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyAyJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHItLS0tLSZuYnNwOyAyOTM5Ni4zPEJS
PnhwLTEwMSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyAxJm5ic3A7Jm5ic3A7IDI1NiZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyAxJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC1iLS0tLSZuYnNwOyZuYnNwOyA0
Njg1Ljg8L0RJVj4NCjxESVY+PGluY2x1ZGV0YWlsPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxE
SVY+WyoqQHhlbnRlc3QgOjrI/SAxMtTCIDIxOjp+XSQgc3VkbyB4bSBzYXZlIDEgMS5zYXZl
PC9ESVY+DQo8RElWPk1lc3NhZ2UgZnJvbSBzeXNsb2dkQCBhdCBXZWQgRGVjIDIxIDEwOjI3
OjEwIDIwMTEgLi4uPEJSPnhlbnRlc3Qga2VybmVsOiB1bnJlZ2lzdGVyX25ldGRldmljZTog
d2FpdGluZyBmb3IgdGFwMS4wIHRvIGJlY29tZSBmcmVlLiBVc2FnZSBjb3VudCA9IDE8L0RJ
Vj4NCjxESVY+PEJSPk1lc3NhZ2UgZnJvbSBzeXNsb2dkQCBhdCBXZWQgRGVjIDIxIDEwOjI3
OjQxIDIwMTEgLi4uPEJSPnhlbnRlc3QgbGFzdCBtZXNzYWdlIHJlcGVhdGVkIDMgdGltZXM8
QlI+TWVzc2FnZSBmcm9tIHN5c2xvZ2RAIGF0IFdlZCBEZWMgMjEgMTA6Mjg6NTIgMjAxMSAu
Li48QlI+eGVudGVzdCBsYXN0IG1lc3NhZ2UgcmVwZWF0ZWQgNyB0aW1lczwvRElWPg0KPERJ
Vj4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxE
SVYgc3R5bGU9IkNPTE9SOiAjMDAwIj4NCjxESVYgc3R5bGU9IlBBRERJTkctQk9UVE9NOiAy
cHg7IFBBRERJTkctTEVGVDogMHB4OyBQQURESU5HLVJJR0hUOiAwcHg7IEZPTlQtRkFNSUxZ
OiBBcmlhbCBOYXJyb3c7IEZPTlQtU0laRTogMTJweDsgUEFERElORy1UT1A6IDJweCI+LS0t
LS0tLS0tLS0tLS0tLS0tJm5ic3A71K3KvNPKvP4mbmJzcDstLS0tLS0tLS0tLS0tLS0tLS08
L0RJVj4NCjxESVYgc3R5bGU9IlBBRERJTkctQk9UVE9NOiA4cHg7IFBBRERJTkctTEVGVDog
OHB4OyBQQURESU5HLVJJR0hUOiA4cHg7IEJBQ0tHUk9VTkQ6ICNlZmVmZWY7IEZPTlQtU0la
RTogMTJweDsgUEFERElORy1UT1A6IDhweCI+DQo8RElWIGlkPW1lbnVfc2VuZGVyPjxCPrei
vP7Iyzo8L0I+Jm5ic3A7IkFudGhvbnkgUEVSQVJEIiZsdDthbnRob255LnBlcmFyZEBjaXRy
aXguY29tJmd0Ozs8L0RJVj4NCjxESVY+PEI+t6LLzcqxvOQ6PC9CPiZuYnNwOzIwMTHE6jEy
1MIyMMjVKNDHxtq2/ikgze3Jzzk6NDg8L0RJVj4NCjxESVY+PEI+ytW8/sjLOjwvQj4mbmJz
cDsiU3RlZmFuIEhham5vY3ppIiZsdDtzdGVmYW5oYUBnbWFpbC5jb20mZ3Q7OyA8V0JSPjwv
RElWPg0KPERJVj48Qj6zrcvNOjwvQj4mbmJzcDsioei9S+y2YXdhcmUiJmx0OzI1MDcxNjcw
OEBxcS5jb20mZ3Q7OyAicWVtdS1kZXZlbCImbHQ7cWVtdS1kZXZlbEBub25nbnUub3JnJmd0
OzsgIlN0ZWZhbm8gU3RhYmVsbGluaSImbHQ7U3RlZmFuby5TdGFiZWxsaW5pQGV1LmNpdHJp
eC5jb20mZ3Q7OyAiWGVuIERldmVsIiZsdDt4ZW4tZGV2ZWxAbGlzdHMueGVuc291cmNlLmNv
bSZndDs7IDxXQlI+PC9ESVY+DQo8RElWPjxCPtb3zOI6PC9CPiZuYnNwO1JlOiC72Li0o7og
W1FlbXUtZGV2ZWxdIGRlYnVnaW5nIGFib3V0IHFlbXUtZG0gaW4geGVuIDMuNC4yPC9ESVY+
PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPk9uIFR1ZSwgMjAgRGVjIDIwMTEsIFN0ZWZhbiBI
YWpub2N6aSB3cm90ZTo8QlI+PEJSPiZndDsgMjAxMS8xMi8yMCCh6L1L7LZhd2FyZSAmbHQ7
MjUwNzE2NzA4QHFxLmNvbSZndDs6PEJSPiZndDsgJmd0OyAmbmJzcDsmbmJzcDsmbmJzcDsg
SSZuYnNwO3dhbnQgdG8gY3JlYXRlIGEgbWVtb3J5IHNuYXBzaG90IGZpbGUgKHN1Y2ggYXMg
bW0uc25hcCkgb2YgY3VycmVudDxCUj4mZ3Q7ICZndDsgdmlydHVhbCBtYWNoaW5lIGFuZCZu
YnNwOyB0aGUgbW0uc25hcCBjYW4gYmUgdXNlZCBhcyBhIGFyZyBvZiBxZW11IGNtZC1saW5l
IGZvcjxCUj4mZ3Q7ICZndDsgcmVzdG9yaW5nIHRoZSBsYXN0IG1lbW9yeSBjb25kaXRpb24u
PEJSPiZndDsgJmd0OyAmbmJzcDsmbmJzcDsmbmJzcDsgQnV0IEkgYW0gbm90IHZlcnkgY2xl
YXIgYWJvdXQgdGhlIHN0cnVjdHVyZSBvZiB0aGUgcWVtdS1kbSBzb3VyY2UgY29kZS48QlI+
Jmd0OyAmZ3Q7IEFsdGhvdWdoJm5ic3A7b2JzZXJ2aW5nIHRoZSBvdXRwdXQgb2YgZXhlY3V0
aW9uIGlzIHRoZSBzdHJhaWdodGZvcndhcmQgd2F5LCBoaWdoPEJSPiZndDsgJmd0OyBmcmVx
dWVuY3kgb2YgcHJpbnRmJm5ic3A7IGFuZCByZS1jb21wbGluZyBpcyB0b28gaW5jb3Zlbmll
bnQgdG8gcHV0IGludG8gZWZmZWN0LjxCUj4mZ3Q7PEJSPiZndDsgUGxlYXNlIGtlZXAgcWVt
dS1kZXZlbEBub25nbnUub3JnIENDZWQgc28gb3RoZXJzIGNhbiBjb250cmlidXRlIHRvIHRo
ZTxCUj4mZ3Q7IGRpc2N1c3Npb24uPEJSPiZndDs8QlI+Jmd0OyBRRU1VIG9ubHkgZGVhbHMg
d2l0aCB2aXJ0dWFsIG1lbW9yeSB3aGVuIHNpbXVsYXRpbmcgYW4gTU1VIChmb3I8QlI+Jmd0
OyBBUk0tb24teDg2IHN5c3RlbSB0cmFuc2xhdGlvbikuJm5ic3A7IFRoZSBkZXZpY2UgbW9k
ZWwgdXN1YWxseSBvcGVyYXRlcyBvbjxCUj4mZ3Q7IHBoeXNpY2FsIFJBTSBvciBidXMgYWRk
cmVzc2VzLjxCUj4mZ3Q7PEJSPiZndDsgU3RlZmFubyBvciBBbnRob255IGNhbiBleHBsYWlu
IHRoZSBxZW11LWRtIHNwZWNpZmljcy4mbmJzcDsgSXQncyBzdGlsbCBub3Q8QlI+Jmd0OyBj
bGVhciB0byBtZSB3aGF0IHlvdSdyZSB0cnlpbmcgdG8gb2JzZXJ2ZSAtIHFlbXUtZG0gaXMg
bm90IHdoZXJlIEknZDxCUj4mZ3Q7IHRyeSB0byBvYnNlcnZlIGRvbWFpbiBtZW1vcnkgdW5k
ZXIgWGVuIGJ1dCBpdCdzIHRoZSByaWdodCBwbGFjZSB0bzxCUj4mZ3Q7IG9ic2VydmUgZW11
bGF0ZWQgZGV2aWNlcy48QlI+PEJSPkNjZWQgWGVuLWRldmVsIGFzIHdlbGwuPEJSPjxCUj5Z
b3UgY2FuIHNhdmUgYSBkb21haW4gc3RhdGUgdXNpbmcgdGhlIHRvb2wgc3RhY2sgKHByb2Jh
Ymx5IGB4bSBzYXZlYDxCUj53aXRoIFhlbiAzLjQpIGFuZCByZXN0b3JlIGl0IGFzIG1hbnkg
dGltZSBhcyB5b3Ugd2FudC48QlI+PEJSPlRvIHJ1biBnZGIgb24gcWVtdS1kbSwgcmVtcGxh
Y2UgdGhlIC91c3IvbGliL3hlbi9iaW4vcWVtdS1kbSBieSBhPEJSPnNjcmlwdDo8QlI+IyEv
YmluL3NoPEJSPmV4ZWMgZ2Ric2VydmVyIDAuMC4wLjA6MTIzNCAvdXNyL2xpYi94ZW4vYmlu
L3FlbXUtZG0uYmFrICRAPEJSPjxCUj5BbmQgcnVuIGdkYi4gYHRhcmdldCByZW1vdGUgbG9j
YWxob3N0IDEyMzRgIHRvIGNvbm5lY3QgdG8gZ2Ric2VydmVyLjxCUj48QlI+V2l0aCB0aGUg
bGF0ZXN0IFhlbiAoNC4xIGFuZCB1bnN0YWJsZSksIHlvdSBjYW4gc3BlY2lmaWUgYSBkaWZm
ZXJlbnQ8QlI+ZGV2aWNlIG1vZGVsIGluIHRoZSBjb25maWcgZmlsZSBpbnN0ZWFkIG9mIHJl
bXBsYWNpbmcgdGhlIGRlZmF1bHQ8QlI+YmluYXJ5LjxCUj48QlI+UmVnYXJkcyw8QlI+PEJS
Pi0tIDxCUj5BbnRob255IFBFUkFSRDxCUj48L0RJVj48L2luY2x1ZGV0YWlsPjwvRElWPg==

------=_NextPart_4EF14854_DCBABC68_64CA86BC--



--===============4046104227291001374==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============4046104227291001374==--



From xen-devel-bounces@lists.xensource.com Wed Dec 21 03:18:16 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 03:18:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdCgV-00007T-NZ; Wed, 21 Dec 2011 03:17:39 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fajar@fajar.net>)
	id 1RdCgU-00007L-3B; Wed, 21 Dec 2011 03:17:38 +0000
X-Env-Sender: fajar@fajar.net
X-Msg-Ref: server-2.tower-27.messagelabs.com!1324437403!58111977!1
X-Originating-IP: [209.85.210.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26534 invoked from network); 21 Dec 2011 03:16:45 -0000
Received: from mail-pz0-f43.google.com (HELO mail-pz0-f43.google.com)
	(209.85.210.43)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Dec 2011 03:16:45 -0000
Received: by daec6 with SMTP id c6so28981005dae.30
	for <multiple recipients>; Tue, 20 Dec 2011 19:17:34 -0800 (PST)
MIME-Version: 1.0
Received: by 10.68.191.2 with SMTP id gu2mr8450917pbc.39.1324437042270; Tue,
	20 Dec 2011 19:10:42 -0800 (PST)
Received: by 10.142.214.12 with HTTP; Tue, 20 Dec 2011 19:10:42 -0800 (PST)
In-Reply-To: <4EF0E48E.6010900@citrix.com>
References: <D14C52F5-9E35-43F1-9D0E-10336DB51BBD@UFL.EDU>
	<20111219082207.GE12984@reaktio.net> <4EF0E48E.6010900@citrix.com>
Date: Wed, 21 Dec 2011 10:10:42 +0700
Message-ID: <CAG1y0seAdN1RiNBmFw-cNrKwAzdi83HaaSGtfCei8JXy31xE2w@mail.gmail.com>
From: "Fajar A. Nugraha" <list@fajar.net>
To: Mike McClurg <mike.mcclurg@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	ruijin zhou <zhourj@ufl.edu>,
	"xen-api@lists.xensource.com" <xen-api@lists.xensource.com>
Subject: Re: [Xen-devel] [Xen-API] CrossPoolMigration
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Dec 21, 2011 at 2:39 AM, Mike McClurg <mike.mcclurg@citrix.com> wrote:
> Storage motion is something that we are prototyping for XCP/XenServer.
> It will not be a part of the Xen hypervisor. We'll probably start more
> work on the prototype in January, and we'll post details of our
> implementation plan to this list.

Is still based on drbd and tap, as in the wiki page? If yes, it'd be
... interesting (to say the least) to see how these issues will be
handled:
- space for drbd metadata:
http://www.drbd.org/users-guide/ch-internals.html#s-metadata
- performance penalty and choice of replication modes:
http://www.drbd.org/users-guide-emb/s-replication-protocols.html
- general tap issues (qdisk vs module, vanilla vs patched 2.6.32, etc.)

-- 
Fajar

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 21 03:18:16 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 03:18:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdCgV-00007T-NZ; Wed, 21 Dec 2011 03:17:39 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fajar@fajar.net>)
	id 1RdCgU-00007L-3B; Wed, 21 Dec 2011 03:17:38 +0000
X-Env-Sender: fajar@fajar.net
X-Msg-Ref: server-2.tower-27.messagelabs.com!1324437403!58111977!1
X-Originating-IP: [209.85.210.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26534 invoked from network); 21 Dec 2011 03:16:45 -0000
Received: from mail-pz0-f43.google.com (HELO mail-pz0-f43.google.com)
	(209.85.210.43)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Dec 2011 03:16:45 -0000
Received: by daec6 with SMTP id c6so28981005dae.30
	for <multiple recipients>; Tue, 20 Dec 2011 19:17:34 -0800 (PST)
MIME-Version: 1.0
Received: by 10.68.191.2 with SMTP id gu2mr8450917pbc.39.1324437042270; Tue,
	20 Dec 2011 19:10:42 -0800 (PST)
Received: by 10.142.214.12 with HTTP; Tue, 20 Dec 2011 19:10:42 -0800 (PST)
In-Reply-To: <4EF0E48E.6010900@citrix.com>
References: <D14C52F5-9E35-43F1-9D0E-10336DB51BBD@UFL.EDU>
	<20111219082207.GE12984@reaktio.net> <4EF0E48E.6010900@citrix.com>
Date: Wed, 21 Dec 2011 10:10:42 +0700
Message-ID: <CAG1y0seAdN1RiNBmFw-cNrKwAzdi83HaaSGtfCei8JXy31xE2w@mail.gmail.com>
From: "Fajar A. Nugraha" <list@fajar.net>
To: Mike McClurg <mike.mcclurg@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	ruijin zhou <zhourj@ufl.edu>,
	"xen-api@lists.xensource.com" <xen-api@lists.xensource.com>
Subject: Re: [Xen-devel] [Xen-API] CrossPoolMigration
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Dec 21, 2011 at 2:39 AM, Mike McClurg <mike.mcclurg@citrix.com> wrote:
> Storage motion is something that we are prototyping for XCP/XenServer.
> It will not be a part of the Xen hypervisor. We'll probably start more
> work on the prototype in January, and we'll post details of our
> implementation plan to this list.

Is still based on drbd and tap, as in the wiki page? If yes, it'd be
... interesting (to say the least) to see how these issues will be
handled:
- space for drbd metadata:
http://www.drbd.org/users-guide/ch-internals.html#s-metadata
- performance penalty and choice of replication modes:
http://www.drbd.org/users-guide-emb/s-replication-protocols.html
- general tap issues (qdisk vs module, vanilla vs patched 2.6.32, etc.)

-- 
Fajar

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 21 05:30:26 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 05:30:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdEkL-0000ue-KY; Wed, 21 Dec 2011 05:29:45 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RdEkK-0000uV-Op
	for xen-devel@lists.xensource.com; Wed, 21 Dec 2011 05:29:44 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1324445378!1575493!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzUyMg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22104 invoked from network); 21 Dec 2011 05:29:38 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Dec 2011 05:29:38 -0000
X-IronPort-AV: E=Sophos;i="4.71,386,1320624000"; 
   d="scan'208";a="9595431"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Dec 2011 05:29:38 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 21 Dec 2011 05:29:38 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RdEkE-00088y-8v;
	Wed, 21 Dec 2011 05:29:38 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RdEkD-0003bu-T6;
	Wed, 21 Dec 2011 05:29:38 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10564-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 21 Dec 2011 05:29:37 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10564: tolerable FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10564 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10564/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf     10 guest-saverestore           fail pass in 10563

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-sedf 14 guest-localmigrate/x10 fail in 10563 blocked in 10564

version targeted for testing:
 xen                  e56500f95b6a
baseline version:
 xen                  e56500f95b6a

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 21 05:30:26 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 05:30:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdEkL-0000ue-KY; Wed, 21 Dec 2011 05:29:45 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RdEkK-0000uV-Op
	for xen-devel@lists.xensource.com; Wed, 21 Dec 2011 05:29:44 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1324445378!1575493!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzUyMg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22104 invoked from network); 21 Dec 2011 05:29:38 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Dec 2011 05:29:38 -0000
X-IronPort-AV: E=Sophos;i="4.71,386,1320624000"; 
   d="scan'208";a="9595431"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Dec 2011 05:29:38 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 21 Dec 2011 05:29:38 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RdEkE-00088y-8v;
	Wed, 21 Dec 2011 05:29:38 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RdEkD-0003bu-T6;
	Wed, 21 Dec 2011 05:29:38 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10564-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 21 Dec 2011 05:29:37 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10564: tolerable FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10564 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10564/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf     10 guest-saverestore           fail pass in 10563

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-sedf 14 guest-localmigrate/x10 fail in 10563 blocked in 10564

version targeted for testing:
 xen                  e56500f95b6a
baseline version:
 xen                  e56500f95b6a

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 21 06:56:47 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 06:56:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdG5b-0001PL-SQ; Wed, 21 Dec 2011 06:55:47 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RdG5a-0001PD-KG
	for xen-devel@lists.xensource.com; Wed, 21 Dec 2011 06:55:46 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1324450539!7681661!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzUyMg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31859 invoked from network); 21 Dec 2011 06:55:39 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Dec 2011 06:55:39 -0000
X-IronPort-AV: E=Sophos;i="4.71,387,1320624000"; 
   d="scan'208";a="9596016"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Dec 2011 06:55:38 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 21 Dec 2011 06:55:38 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RdG5R-0000Cs-Ui;
	Wed, 21 Dec 2011 06:55:37 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RdG5R-0006un-U3;
	Wed, 21 Dec 2011 06:55:37 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10565-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 21 Dec 2011 06:55:37 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux test] 10565: regressions - trouble:
	blocked/broken/fail/pass
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10565 linux real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10565/

Regressions :-(

Tests which did not succeed and are blocking,including tests which could not be run:
 test-amd64-i386-xl-win-vcpus1  7 windows-install           fail REGR. vs. 9095
 test-amd64-i386-win-vcpus1    7 windows-install            fail REGR. vs. 9095
 test-amd64-i386-win           7 windows-install            fail REGR. vs. 9095
 build-amd64-pvops             1 hosts-allocate               broken

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win       1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xend-winxpsp3  7 windows-install              fail  never pass
 test-amd64-amd64-xl           1 xen-build-check(1)           blocked  n/a
 build-amd64-pvops             2 logs-capture(2)              broken never pass
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)        blocked never pass
 test-amd64-amd64-xl-sedf-pin  1 xen-build-check(1)          blocked never pass
 test-amd64-amd64-xl-winxpsp3  1 xen-build-check(1)          blocked never pass
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a

version targeted for testing:
 linux                59b1ffe039ce366305d48176b7fccce29ce729d3
baseline version:
 linux                6bec8b4a4c14095d0b7ce424db9d583c3decae6c

------------------------------------------------------------
People who touched revisions under test:
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            broken  
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          blocked 
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               blocked 
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              blocked 
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        blocked 
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 blocked 
 test-amd64-amd64-pv                                          blocked 
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     blocked 
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         blocked 
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      blocked 
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 blocked 
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
commit 59b1ffe039ce366305d48176b7fccce29ce729d3
Merge: cacd265... 60b1e4f...
Author: Jeremy Fitzhardinge <jeremy@goop.org>
Date:   Sat Dec 10 00:20:33 2011 -0800

    Merge commit 'v2.6.32.50' into xen/next-2.6.32
    
    * commit 'v2.6.32.50': (28 commits)
      Linux 2.6.32.50
      clockevents: Set noop handler in clockevents_exchange_device()
      tick-broadcast: Stop active broadcast device when replacing it
      genirq: Fix race condition when stopping the irq thread
      oprofile, x86: Fix crash when unloading module (nmi timer mode)
      x86/mpparse: Account for bus types other than ISA and PCI
      sched, x86: Avoid unnecessary overflow in sched_clock
      cifs: fix cifs stable patch cifs-fix-oplock-break-handling-try-2.patch
      SCSI: Silencing 'killing requests for dead queue'
      SCSI: scsi_lib: fix potential NULL dereference
      USB: usb-storage: unusual_devs entry for Kingston DT 101 G2
      usb: option: add SIMCom SIM5218
      usb: ftdi_sio: add PID for Propox ISPcable III
      USB: whci-hcd: fix endian conversion in qset_clear()
      Staging: comedi: fix signal handling in read and write
      staging: comedi: fix oops for USB DAQ devices.
      staging: usbip: bugfix for deadlock
      gro: reset vlan_tci on reuse
      nl80211: fix MAC address validation
      p54spi: Fix workqueue deadlock
      ...

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 21 06:56:47 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 06:56:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdG5b-0001PL-SQ; Wed, 21 Dec 2011 06:55:47 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RdG5a-0001PD-KG
	for xen-devel@lists.xensource.com; Wed, 21 Dec 2011 06:55:46 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1324450539!7681661!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzUyMg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31859 invoked from network); 21 Dec 2011 06:55:39 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Dec 2011 06:55:39 -0000
X-IronPort-AV: E=Sophos;i="4.71,387,1320624000"; 
   d="scan'208";a="9596016"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Dec 2011 06:55:38 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 21 Dec 2011 06:55:38 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RdG5R-0000Cs-Ui;
	Wed, 21 Dec 2011 06:55:37 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RdG5R-0006un-U3;
	Wed, 21 Dec 2011 06:55:37 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10565-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 21 Dec 2011 06:55:37 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux test] 10565: regressions - trouble:
	blocked/broken/fail/pass
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10565 linux real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10565/

Regressions :-(

Tests which did not succeed and are blocking,including tests which could not be run:
 test-amd64-i386-xl-win-vcpus1  7 windows-install           fail REGR. vs. 9095
 test-amd64-i386-win-vcpus1    7 windows-install            fail REGR. vs. 9095
 test-amd64-i386-win           7 windows-install            fail REGR. vs. 9095
 build-amd64-pvops             1 hosts-allocate               broken

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win       1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xend-winxpsp3  7 windows-install              fail  never pass
 test-amd64-amd64-xl           1 xen-build-check(1)           blocked  n/a
 build-amd64-pvops             2 logs-capture(2)              broken never pass
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)        blocked never pass
 test-amd64-amd64-xl-sedf-pin  1 xen-build-check(1)          blocked never pass
 test-amd64-amd64-xl-winxpsp3  1 xen-build-check(1)          blocked never pass
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a

version targeted for testing:
 linux                59b1ffe039ce366305d48176b7fccce29ce729d3
baseline version:
 linux                6bec8b4a4c14095d0b7ce424db9d583c3decae6c

------------------------------------------------------------
People who touched revisions under test:
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            broken  
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          blocked 
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               blocked 
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              blocked 
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        blocked 
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 blocked 
 test-amd64-amd64-pv                                          blocked 
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     blocked 
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         blocked 
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      blocked 
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 blocked 
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
commit 59b1ffe039ce366305d48176b7fccce29ce729d3
Merge: cacd265... 60b1e4f...
Author: Jeremy Fitzhardinge <jeremy@goop.org>
Date:   Sat Dec 10 00:20:33 2011 -0800

    Merge commit 'v2.6.32.50' into xen/next-2.6.32
    
    * commit 'v2.6.32.50': (28 commits)
      Linux 2.6.32.50
      clockevents: Set noop handler in clockevents_exchange_device()
      tick-broadcast: Stop active broadcast device when replacing it
      genirq: Fix race condition when stopping the irq thread
      oprofile, x86: Fix crash when unloading module (nmi timer mode)
      x86/mpparse: Account for bus types other than ISA and PCI
      sched, x86: Avoid unnecessary overflow in sched_clock
      cifs: fix cifs stable patch cifs-fix-oplock-break-handling-try-2.patch
      SCSI: Silencing 'killing requests for dead queue'
      SCSI: scsi_lib: fix potential NULL dereference
      USB: usb-storage: unusual_devs entry for Kingston DT 101 G2
      usb: option: add SIMCom SIM5218
      usb: ftdi_sio: add PID for Propox ISPcable III
      USB: whci-hcd: fix endian conversion in qset_clear()
      Staging: comedi: fix signal handling in read and write
      staging: comedi: fix oops for USB DAQ devices.
      staging: usbip: bugfix for deadlock
      gro: reset vlan_tci on reuse
      nl80211: fix MAC address validation
      p54spi: Fix workqueue deadlock
      ...

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 21 07:53:40 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 07:53:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdGyz-0001qp-Bd; Wed, 21 Dec 2011 07:53:01 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RdGyx-0001qk-LE
	for xen-devel@lists.xensource.com; Wed, 21 Dec 2011 07:52:59 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1324453972!8096467!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=2.0 required=7.0 tests=SUBJECT_RANDOMQ
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6778 invoked from network); 21 Dec 2011 07:52:53 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-6.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Dec 2011 07:52:53 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 21 Dec 2011 07:52:52 +0000
Message-Id: <4EF19E9A0200007800069494@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 21 Dec 2011 07:53:46 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartDDF26F9A.2__="
Cc: Yongjie Ren <yongjie.ren@intel.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH] x86/passthrough: don't leak guest IRQs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__PartDDF26F9A.2__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

As unmap_domain_pirq_emuirq() fails on a never mapped pIRQ, it must not
be called for the non-emu-IRQ case (to prevent the entire unmap
operation failing).

Based on a suggestion from Stefano.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Tested-by: Yongjie Ren <yongjie.ren@intel.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

--- a/xen/arch/x86/physdev.c
+++ b/xen/arch/x86/physdev.c
@@ -219,7 +219,8 @@ int physdev_unmap_pirq(domid_t domid, in
     if ( is_hvm_domain(d) )
     {
         spin_lock(&d->event_lock);
-        ret =3D unmap_domain_pirq_emuirq(d, pirq);
+        if ( domain_pirq_to_emuirq(d, pirq) !=3D IRQ_UNBOUND )
+            ret =3D unmap_domain_pirq_emuirq(d, pirq);
         spin_unlock(&d->event_lock);
         if ( domid =3D=3D DOMID_SELF || ret )
             goto free_domain;




--=__PartDDF26F9A.2__=
Content-Type: text/plain; name="x86-pt-irq-leak.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-pt-irq-leak.patch"

x86/passthrough: don't leak guest IRQs=0A=0AAs unmap_domain_pirq_emuirq() =
fails on a never mapped pIRQ, it must not=0Abe called for the non-emu-IRQ =
case (to prevent the entire unmap=0Aoperation failing).=0A=0ABased on a =
suggestion from Stefano.=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.com=
>=0ATested-by: Yongjie Ren <yongjie.ren@intel.com>=0AAcked-by: Stefano =
Stabellini <stefano.stabellini@eu.citrix.com>=0A=0A--- a/xen/arch/x86/physd=
ev.c=0A+++ b/xen/arch/x86/physdev.c=0A@@ -219,7 +219,8 @@ int physdev_unmap=
_pirq(domid_t domid, in=0A     if ( is_hvm_domain(d) )=0A     {=0A         =
spin_lock(&d->event_lock);=0A-        ret =3D unmap_domain_pirq_emuirq(d, =
pirq);=0A+        if ( domain_pirq_to_emuirq(d, pirq) !=3D IRQ_UNBOUND =
)=0A+            ret =3D unmap_domain_pirq_emuirq(d, pirq);=0A         =
spin_unlock(&d->event_lock);=0A         if ( domid =3D=3D DOMID_SELF || =
ret )=0A             goto free_domain;=0A
--=__PartDDF26F9A.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.xensource.com
http://lists.xensource.com/xen-devel

--=__PartDDF26F9A.2__=--


From xen-devel-bounces@lists.xensource.com Wed Dec 21 07:53:40 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 07:53:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdGyz-0001qp-Bd; Wed, 21 Dec 2011 07:53:01 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RdGyx-0001qk-LE
	for xen-devel@lists.xensource.com; Wed, 21 Dec 2011 07:52:59 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1324453972!8096467!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=2.0 required=7.0 tests=SUBJECT_RANDOMQ
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6778 invoked from network); 21 Dec 2011 07:52:53 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-6.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Dec 2011 07:52:53 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 21 Dec 2011 07:52:52 +0000
Message-Id: <4EF19E9A0200007800069494@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 21 Dec 2011 07:53:46 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartDDF26F9A.2__="
Cc: Yongjie Ren <yongjie.ren@intel.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH] x86/passthrough: don't leak guest IRQs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__PartDDF26F9A.2__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

As unmap_domain_pirq_emuirq() fails on a never mapped pIRQ, it must not
be called for the non-emu-IRQ case (to prevent the entire unmap
operation failing).

Based on a suggestion from Stefano.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Tested-by: Yongjie Ren <yongjie.ren@intel.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

--- a/xen/arch/x86/physdev.c
+++ b/xen/arch/x86/physdev.c
@@ -219,7 +219,8 @@ int physdev_unmap_pirq(domid_t domid, in
     if ( is_hvm_domain(d) )
     {
         spin_lock(&d->event_lock);
-        ret =3D unmap_domain_pirq_emuirq(d, pirq);
+        if ( domain_pirq_to_emuirq(d, pirq) !=3D IRQ_UNBOUND )
+            ret =3D unmap_domain_pirq_emuirq(d, pirq);
         spin_unlock(&d->event_lock);
         if ( domid =3D=3D DOMID_SELF || ret )
             goto free_domain;




--=__PartDDF26F9A.2__=
Content-Type: text/plain; name="x86-pt-irq-leak.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-pt-irq-leak.patch"

x86/passthrough: don't leak guest IRQs=0A=0AAs unmap_domain_pirq_emuirq() =
fails on a never mapped pIRQ, it must not=0Abe called for the non-emu-IRQ =
case (to prevent the entire unmap=0Aoperation failing).=0A=0ABased on a =
suggestion from Stefano.=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.com=
>=0ATested-by: Yongjie Ren <yongjie.ren@intel.com>=0AAcked-by: Stefano =
Stabellini <stefano.stabellini@eu.citrix.com>=0A=0A--- a/xen/arch/x86/physd=
ev.c=0A+++ b/xen/arch/x86/physdev.c=0A@@ -219,7 +219,8 @@ int physdev_unmap=
_pirq(domid_t domid, in=0A     if ( is_hvm_domain(d) )=0A     {=0A         =
spin_lock(&d->event_lock);=0A-        ret =3D unmap_domain_pirq_emuirq(d, =
pirq);=0A+        if ( domain_pirq_to_emuirq(d, pirq) !=3D IRQ_UNBOUND =
)=0A+            ret =3D unmap_domain_pirq_emuirq(d, pirq);=0A         =
spin_unlock(&d->event_lock);=0A         if ( domid =3D=3D DOMID_SELF || =
ret )=0A             goto free_domain;=0A
--=__PartDDF26F9A.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.xensource.com
http://lists.xensource.com/xen-devel

--=__PartDDF26F9A.2__=--


From xen-devel-bounces@lists.xensource.com Wed Dec 21 08:03:42 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 08:03:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdH8l-0002Vf-8x; Wed, 21 Dec 2011 08:03:07 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RdH8j-0002VY-IT
	for xen-devel@lists.xensource.com; Wed, 21 Dec 2011 08:03:06 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1324454578!8035396!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14597 invoked from network); 21 Dec 2011 08:02:58 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-7.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Dec 2011 08:02:58 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 21 Dec 2011 08:02:58 +0000
Message-Id: <4EF1A0F702000078000694AC@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 21 Dec 2011 08:03:51 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartB29D00F7.0__="
Subject: [Xen-devel] [PATCH] xenpm: assorted adjustments
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__PartB29D00F7.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

- use consistent error values (stop mixing of [positive] errno values
  with literal -E... ones)
- properly format output
- don't use leading zeros in decimal output
- move printing of average frequency into P-state conditional (rather
  than a C-state one)
- don't print some C-state related info when CPU idle management is
  disabled in the hypervisor
- use calloc() for array allocations that also got cleared via memset()
  so far

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/tools/misc/xenpm.c
+++ b/tools/misc/xenpm.c
@@ -87,20 +87,20 @@ static void print_cxstat(int cpuid, stru
            cxstat->idle_time/1000000UL);
     for ( i =3D 0; i < cxstat->nr; i++ )
     {
-        printf("C%d                   : transition [%020"PRIu64"]\n",
+        printf("C%-20d: transition [%20"PRIu64"]\n",
                i, cxstat->triggers[i]);
-        printf("                       residency  [%020"PRIu64" ms]\n",
+        printf("                       residency  [%20"PRIu64" ms]\n",
                cxstat->residencies[i]/1000000UL);
     }
-    printf("pc2                  : [%020"PRIu64" ms]\n"
-           "pc3                  : [%020"PRIu64" ms]\n"
-           "pc6                  : [%020"PRIu64" ms]\n"
-           "pc7                  : [%020"PRIu64" ms]\n",
+    printf("pc2                  : [%20"PRIu64" ms]\n"
+           "pc3                  : [%20"PRIu64" ms]\n"
+           "pc6                  : [%20"PRIu64" ms]\n"
+           "pc7                  : [%20"PRIu64" ms]\n",
             cxstat->pc2/1000000UL, cxstat->pc3/1000000UL,
             cxstat->pc6/1000000UL, cxstat->pc7/1000000UL);
-    printf("cc3                  : [%020"PRIu64" ms]\n"
-           "cc6                  : [%020"PRIu64" ms]\n"
-           "cc7                  : [%020"PRIu64" ms]\n",
+    printf("cc3                  : [%20"PRIu64" ms]\n"
+           "cc6                  : [%20"PRIu64" ms]\n"
+           "cc7                  : [%20"PRIu64" ms]\n",
             cxstat->cc3/1000000UL, cxstat->cc6/1000000UL,
             cxstat->cc7/1000000UL);
     printf("\n");
@@ -114,7 +114,7 @@ static int get_cxstat_by_cpuid(xc_interf
=20
     ret =3D xc_pm_get_max_cx(xc_handle, cpuid, &max_cx_num);
     if ( ret )
-        return errno;
+        return -errno;
=20
     if ( !cxstat )
         return -EINVAL;
@@ -135,15 +135,14 @@ static int get_cxstat_by_cpuid(xc_interf
     ret =3D xc_pm_get_cxstat(xc_handle, cpuid, cxstat);
     if( ret )
     {
-        int temp =3D errno;
+        ret =3D -errno;
         free(cxstat->triggers);
         free(cxstat->residencies);
         cxstat->triggers =3D NULL;
         cxstat->residencies =3D NULL;
-        return temp;
     }
=20
-    return 0;
+    return ret;
 }
=20
 static int show_max_cstate(xc_interface *xc_handle)
@@ -214,14 +213,13 @@ static void print_pxstat(int cpuid, stru
     for ( i =3D 0; i < pxstat->total; i++ )
     {
         if ( pxstat->cur =3D=3D i )
-            printf("*P%d", i);
+            printf("*P%-9d", i);
         else
-            printf("P%d ", i);
-        printf("                  : freq       [%04"PRIu64" MHz]\n",
-               pxstat->pt[i].freq);
-        printf("                       transition [%020"PRIu64"]\n",
+            printf("P%-10d", i);
+        printf("[%4"PRIu64" MHz]", pxstat->pt[i].freq);
+        printf(": transition [%20"PRIu64"]\n",
                pxstat->pt[i].count);
-        printf("                       residency  [%020"PRIu64" ms]\n",
+        printf("                       residency  [%20"PRIu64" ms]\n",
                pxstat->pt[i].residency/1000000UL);
     }
     printf("\n");
@@ -235,7 +233,7 @@ static int get_pxstat_by_cpuid(xc_interf
=20
     ret =3D xc_pm_get_max_px(xc_handle, cpuid, &max_px_num);
     if ( ret )
-        return errno;
+        return -errno;
=20
     if ( !pxstat)
         return -EINVAL;
@@ -254,15 +252,14 @@ static int get_pxstat_by_cpuid(xc_interf
     ret =3D xc_pm_get_pxstat(xc_handle, cpuid, pxstat);
     if( ret )
     {
-        int temp =3D errno;
+        ret =3D -errno;
         free(pxstat->trans_pt);
         free(pxstat->pt);
         pxstat->trans_pt =3D NULL;
         pxstat->pt =3D NULL;
-        return temp;
     }
=20
-    return 0;
+    return ret;
 }
=20
 /* show cpu actual average freq information on CPU cpuid */
@@ -272,11 +269,9 @@ static int get_avgfreq_by_cpuid(xc_inter
=20
     ret =3D xc_get_cpufreq_avgfreq(xc_handle, cpuid, avgfreq);
     if ( ret )
-    {
-        return errno;
-    }
+        ret =3D -errno;
=20
-    return 0;
+    return ret;
 }
=20
 static int show_pxstat_by_cpuid(xc_interface *xc_handle, int cpuid)
@@ -325,7 +320,7 @@ static uint64_t *sum, *sum_cx, *sum_px;
=20
 static void signal_int_handler(int signo)
 {
-    int i, j, k, ret;
+    int i, j, k;
     struct timeval tv;
     int cx_cap =3D 0, px_cap =3D 0;
     DECLARE_HYPERCALL_BUFFER(uint32_t, cpu_to_core);
@@ -404,6 +399,8 @@ static void signal_int_handler(int signo
                         res / 1000000UL, 100UL * res / (double)sum_px[i]);=

             }
         }
+        if ( px_cap && avgfreq[i] )
+            printf("  Avg freq\t%d\tKHz\n", avgfreq[i]);
     }
=20
     set_xen_guest_handle(info.cpu_to_core, cpu_to_core);
@@ -411,8 +408,7 @@ static void signal_int_handler(int signo
     set_xen_guest_handle(info.cpu_to_node, cpu_to_node);
     info.max_cpu_index =3D MAX_NR_CPU - 1;
=20
-    ret =3D xc_topologyinfo(xc_handle, &info);
-    if ( !ret )
+    if ( cx_cap && !xc_topologyinfo(xc_handle, &info) )
     {
         uint32_t socket_ids[MAX_NR_CPU];
         uint32_t core_ids[MAX_NR_CPU];
@@ -461,7 +457,7 @@ static void signal_int_handler(int signo
                     if ( cpu_to_socket[j] =3D=3D socket_ids[i] )
                         break;
                 }
-                printf("Socket %d\n", socket_ids[i]);
+                printf("\nSocket %d\n", socket_ids[i]);
                 res =3D cxstat_end[j].pc2 - cxstat_start[j].pc2;
                 printf("\tPC2\t%"PRIu64" ms\t%.2f%%\n",  res / 1000000UL,
                        100UL * res / (double)sum_cx[j]);
@@ -492,12 +488,9 @@ static void signal_int_handler(int signo
                     res =3D cxstat_end[j].cc7 - cxstat_start[j].cc7;
                     printf("\t\tCC7\t%"PRIu64" ms\t%.2f%%\n",  res / =
1000000UL,
                            100UL * res / (double)sum_cx[j]);
-                    printf("\n");
-
                 }
             }
         }
-        printf("  Avg freq\t%d\tKHz\n", avgfreq[i]);
     }
=20
     /* some clean up and then exits */
@@ -542,23 +535,23 @@ void start_gather_func(int argc, char *a
     }
     usec_start =3D tv.tv_sec * 1000000UL + tv.tv_usec;
=20
-    sum =3D malloc(sizeof(uint64_t) * 2 * max_cpu_nr);
+    sum =3D calloc(2 * max_cpu_nr, sizeof(*sum));
     if ( sum =3D=3D NULL )
         return ;
-    cxstat =3D malloc(sizeof(struct xc_cx_stat) * 2 * max_cpu_nr);
+    cxstat =3D calloc(2 * max_cpu_nr, sizeof(*cxstat));
     if ( cxstat =3D=3D NULL )
     {
         free(sum);
         return ;
     }
-    pxstat =3D malloc(sizeof(struct xc_px_stat) * 2 * max_cpu_nr);
+    pxstat =3D calloc(2 * max_cpu_nr, sizeof(*pxstat));
     if ( pxstat =3D=3D NULL )
     {
         free(sum);
         free(cxstat);
         return ;
     }
-    avgfreq =3D malloc(sizeof(int) * max_cpu_nr);
+    avgfreq =3D calloc(max_cpu_nr, sizeof(*avgfreq));
     if ( avgfreq =3D=3D NULL )
     {
         free(sum);
@@ -566,10 +559,6 @@ void start_gather_func(int argc, char *a
         free(pxstat);
         return ;
     }
-    memset(sum, 0, sizeof(uint64_t) * 2 * max_cpu_nr);
-    memset(cxstat, 0, sizeof(struct xc_cx_stat) * 2 * max_cpu_nr);
-    memset(pxstat, 0, sizeof(struct xc_px_stat) * 2 * max_cpu_nr);
-    memset(avgfreq, 0, sizeof(int) * max_cpu_nr);
     sum_cx =3D sum;
     sum_px =3D sum + max_cpu_nr;
     cxstat_start =3D cxstat;



--=__PartB29D00F7.0__=
Content-Type: text/plain; name="xenpm-cleanup.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="xenpm-cleanup.patch"

xenpm: assorted adjustments=0A=0A- use consistent error values (stop =
mixing of [positive] errno values=0A  with literal -E... ones)=0A- =
properly format output=0A- don't use leading zeros in decimal output=0A- =
move printing of average frequency into P-state conditional (rather=0A  =
than a C-state one)=0A- don't print some C-state related info when CPU =
idle management is=0A  disabled in the hypervisor=0A- use calloc() for =
array allocations that also got cleared via memset()=0A  so far=0A=0ASigned=
-off-by: Jan Beulich <jbeulich@suse.com>=0A=0A--- a/tools/misc/xenpm.c=0A++=
+ b/tools/misc/xenpm.c=0A@@ -87,20 +87,20 @@ static void print_cxstat(int =
cpuid, stru=0A            cxstat->idle_time/1000000UL);=0A     for ( i =3D =
0; i < cxstat->nr; i++ )=0A     {=0A-        printf("C%d                   =
: transition [%020"PRIu64"]\n",=0A+        printf("C%-20d: transition =
[%20"PRIu64"]\n",=0A                i, cxstat->triggers[i]);=0A-        =
printf("                       residency  [%020"PRIu64" ms]\n",=0A+        =
printf("                       residency  [%20"PRIu64" ms]\n",=0A          =
      cxstat->residencies[i]/1000000UL);=0A     }=0A-    printf("pc2       =
           : [%020"PRIu64" ms]\n"=0A-           "pc3                  : =
[%020"PRIu64" ms]\n"=0A-           "pc6                  : [%020"PRIu64" =
ms]\n"=0A-           "pc7                  : [%020"PRIu64" ms]\n",=0A+    =
printf("pc2                  : [%20"PRIu64" ms]\n"=0A+           "pc3      =
            : [%20"PRIu64" ms]\n"=0A+           "pc6                  : =
[%20"PRIu64" ms]\n"=0A+           "pc7                  : [%20"PRIu64" =
ms]\n",=0A             cxstat->pc2/1000000UL, cxstat->pc3/1000000UL,=0A    =
         cxstat->pc6/1000000UL, cxstat->pc7/1000000UL);=0A-    printf("cc3 =
                 : [%020"PRIu64" ms]\n"=0A-           "cc6                 =
 : [%020"PRIu64" ms]\n"=0A-           "cc7                  : [%020"PRIu64"=
 ms]\n",=0A+    printf("cc3                  : [%20"PRIu64" ms]\n"=0A+     =
      "cc6                  : [%20"PRIu64" ms]\n"=0A+           "cc7       =
           : [%20"PRIu64" ms]\n",=0A             cxstat->cc3/1000000UL, =
cxstat->cc6/1000000UL,=0A             cxstat->cc7/1000000UL);=0A     =
printf("\n");=0A@@ -114,7 +114,7 @@ static int get_cxstat_by_cpuid(xc_inter=
f=0A =0A     ret =3D xc_pm_get_max_cx(xc_handle, cpuid, &max_cx_num);=0A   =
  if ( ret )=0A-        return errno;=0A+        return -errno;=0A =0A     =
if ( !cxstat )=0A         return -EINVAL;=0A@@ -135,15 +135,14 @@ static =
int get_cxstat_by_cpuid(xc_interf=0A     ret =3D xc_pm_get_cxstat(xc_handle=
, cpuid, cxstat);=0A     if( ret )=0A     {=0A-        int temp =3D =
errno;=0A+        ret =3D -errno;=0A         free(cxstat->triggers);=0A    =
     free(cxstat->residencies);=0A         cxstat->triggers =3D NULL;=0A   =
      cxstat->residencies =3D NULL;=0A-        return temp;=0A     }=0A =
=0A-    return 0;=0A+    return ret;=0A }=0A =0A static int show_max_cstate=
(xc_interface *xc_handle)=0A@@ -214,14 +213,13 @@ static void print_pxstat(=
int cpuid, stru=0A     for ( i =3D 0; i < pxstat->total; i++ )=0A     {=0A =
        if ( pxstat->cur =3D=3D i )=0A-            printf("*P%d", i);=0A+  =
          printf("*P%-9d", i);=0A         else=0A-            printf("P%d =
", i);=0A-        printf("                  : freq       [%04"PRIu64" =
MHz]\n",=0A-               pxstat->pt[i].freq);=0A-        printf("        =
               transition [%020"PRIu64"]\n",=0A+            printf("P%-10d"=
, i);=0A+        printf("[%4"PRIu64" MHz]", pxstat->pt[i].freq);=0A+       =
 printf(": transition [%20"PRIu64"]\n",=0A                pxstat->pt[i].cou=
nt);=0A-        printf("                       residency  [%020"PRIu64" =
ms]\n",=0A+        printf("                       residency  [%20"PRIu64" =
ms]\n",=0A                pxstat->pt[i].residency/1000000UL);=0A     }=0A  =
   printf("\n");=0A@@ -235,7 +233,7 @@ static int get_pxstat_by_cpuid(xc_in=
terf=0A =0A     ret =3D xc_pm_get_max_px(xc_handle, cpuid, &max_px_num);=0A=
     if ( ret )=0A-        return errno;=0A+        return -errno;=0A =0A  =
   if ( !pxstat)=0A         return -EINVAL;=0A@@ -254,15 +252,14 @@ static =
int get_pxstat_by_cpuid(xc_interf=0A     ret =3D xc_pm_get_pxstat(xc_handle=
, cpuid, pxstat);=0A     if( ret )=0A     {=0A-        int temp =3D =
errno;=0A+        ret =3D -errno;=0A         free(pxstat->trans_pt);=0A    =
     free(pxstat->pt);=0A         pxstat->trans_pt =3D NULL;=0A         =
pxstat->pt =3D NULL;=0A-        return temp;=0A     }=0A =0A-    return =
0;=0A+    return ret;=0A }=0A =0A /* show cpu actual average freq =
information on CPU cpuid */=0A@@ -272,11 +269,9 @@ static int get_avgfreq_b=
y_cpuid(xc_inter=0A =0A     ret =3D xc_get_cpufreq_avgfreq(xc_handle, =
cpuid, avgfreq);=0A     if ( ret )=0A-    {=0A-        return errno;=0A-   =
 }=0A+        ret =3D -errno;=0A =0A-    return 0;=0A+    return ret;=0A =
}=0A =0A static int show_pxstat_by_cpuid(xc_interface *xc_handle, int =
cpuid)=0A@@ -325,7 +320,7 @@ static uint64_t *sum, *sum_cx, *sum_px;=0A =
=0A static void signal_int_handler(int signo)=0A {=0A-    int i, j, k, =
ret;=0A+    int i, j, k;=0A     struct timeval tv;=0A     int cx_cap =3D =
0, px_cap =3D 0;=0A     DECLARE_HYPERCALL_BUFFER(uint32_t, cpu_to_core);=0A=
@@ -404,6 +399,8 @@ static void signal_int_handler(int signo=0A            =
             res / 1000000UL, 100UL * res / (double)sum_px[i]);=0A         =
    }=0A         }=0A+        if ( px_cap && avgfreq[i] )=0A+            =
printf("  Avg freq\t%d\tKHz\n", avgfreq[i]);=0A     }=0A =0A     set_xen_gu=
est_handle(info.cpu_to_core, cpu_to_core);=0A@@ -411,8 +408,7 @@ static =
void signal_int_handler(int signo=0A     set_xen_guest_handle(info.cpu_to_n=
ode, cpu_to_node);=0A     info.max_cpu_index =3D MAX_NR_CPU - 1;=0A =0A-   =
 ret =3D xc_topologyinfo(xc_handle, &info);=0A-    if ( !ret )=0A+    if ( =
cx_cap && !xc_topologyinfo(xc_handle, &info) )=0A     {=0A         =
uint32_t socket_ids[MAX_NR_CPU];=0A         uint32_t core_ids[MAX_NR_CPU];=
=0A@@ -461,7 +457,7 @@ static void signal_int_handler(int signo=0A         =
            if ( cpu_to_socket[j] =3D=3D socket_ids[i] )=0A                =
         break;=0A                 }=0A-                printf("Socket =
%d\n", socket_ids[i]);=0A+                printf("\nSocket %d\n", =
socket_ids[i]);=0A                 res =3D cxstat_end[j].pc2 - cxstat_start=
[j].pc2;=0A                 printf("\tPC2\t%"PRIu64" ms\t%.2f%%\n",  res / =
1000000UL,=0A                        100UL * res / (double)sum_cx[j]);=0A@@=
 -492,12 +488,9 @@ static void signal_int_handler(int signo=0A             =
        res =3D cxstat_end[j].cc7 - cxstat_start[j].cc7;=0A                =
     printf("\t\tCC7\t%"PRIu64" ms\t%.2f%%\n",  res / 1000000UL,=0A        =
                    100UL * res / (double)sum_cx[j]);=0A-                  =
  printf("\n");=0A-=0A                 }=0A             }=0A         }=0A- =
       printf("  Avg freq\t%d\tKHz\n", avgfreq[i]);=0A     }=0A =0A     /* =
some clean up and then exits */=0A@@ -542,23 +535,23 @@ void start_gather_f=
unc(int argc, char *a=0A     }=0A     usec_start =3D tv.tv_sec * 1000000UL =
+ tv.tv_usec;=0A =0A-    sum =3D malloc(sizeof(uint64_t) * 2 * max_cpu_nr);=
=0A+    sum =3D calloc(2 * max_cpu_nr, sizeof(*sum));=0A     if ( sum =
=3D=3D NULL )=0A         return ;=0A-    cxstat =3D malloc(sizeof(struct =
xc_cx_stat) * 2 * max_cpu_nr);=0A+    cxstat =3D calloc(2 * max_cpu_nr, =
sizeof(*cxstat));=0A     if ( cxstat =3D=3D NULL )=0A     {=0A         =
free(sum);=0A         return ;=0A     }=0A-    pxstat =3D malloc(sizeof(str=
uct xc_px_stat) * 2 * max_cpu_nr);=0A+    pxstat =3D calloc(2 * max_cpu_nr,=
 sizeof(*pxstat));=0A     if ( pxstat =3D=3D NULL )=0A     {=0A         =
free(sum);=0A         free(cxstat);=0A         return ;=0A     }=0A-    =
avgfreq =3D malloc(sizeof(int) * max_cpu_nr);=0A+    avgfreq =3D calloc(max=
_cpu_nr, sizeof(*avgfreq));=0A     if ( avgfreq =3D=3D NULL )=0A     {=0A  =
       free(sum);=0A@@ -566,10 +559,6 @@ void start_gather_func(int argc, =
char *a=0A         free(pxstat);=0A         return ;=0A     }=0A-    =
memset(sum, 0, sizeof(uint64_t) * 2 * max_cpu_nr);=0A-    memset(cxstat, =
0, sizeof(struct xc_cx_stat) * 2 * max_cpu_nr);=0A-    memset(pxstat, 0, =
sizeof(struct xc_px_stat) * 2 * max_cpu_nr);=0A-    memset(avgfreq, 0, =
sizeof(int) * max_cpu_nr);=0A     sum_cx =3D sum;=0A     sum_px =3D sum + =
max_cpu_nr;=0A     cxstat_start =3D cxstat;=0A
--=__PartB29D00F7.0__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--=__PartB29D00F7.0__=--


From xen-devel-bounces@lists.xensource.com Wed Dec 21 08:03:42 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 08:03:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdH8l-0002Vf-8x; Wed, 21 Dec 2011 08:03:07 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RdH8j-0002VY-IT
	for xen-devel@lists.xensource.com; Wed, 21 Dec 2011 08:03:06 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1324454578!8035396!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14597 invoked from network); 21 Dec 2011 08:02:58 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-7.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Dec 2011 08:02:58 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 21 Dec 2011 08:02:58 +0000
Message-Id: <4EF1A0F702000078000694AC@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 21 Dec 2011 08:03:51 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartB29D00F7.0__="
Subject: [Xen-devel] [PATCH] xenpm: assorted adjustments
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__PartB29D00F7.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

- use consistent error values (stop mixing of [positive] errno values
  with literal -E... ones)
- properly format output
- don't use leading zeros in decimal output
- move printing of average frequency into P-state conditional (rather
  than a C-state one)
- don't print some C-state related info when CPU idle management is
  disabled in the hypervisor
- use calloc() for array allocations that also got cleared via memset()
  so far

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/tools/misc/xenpm.c
+++ b/tools/misc/xenpm.c
@@ -87,20 +87,20 @@ static void print_cxstat(int cpuid, stru
            cxstat->idle_time/1000000UL);
     for ( i =3D 0; i < cxstat->nr; i++ )
     {
-        printf("C%d                   : transition [%020"PRIu64"]\n",
+        printf("C%-20d: transition [%20"PRIu64"]\n",
                i, cxstat->triggers[i]);
-        printf("                       residency  [%020"PRIu64" ms]\n",
+        printf("                       residency  [%20"PRIu64" ms]\n",
                cxstat->residencies[i]/1000000UL);
     }
-    printf("pc2                  : [%020"PRIu64" ms]\n"
-           "pc3                  : [%020"PRIu64" ms]\n"
-           "pc6                  : [%020"PRIu64" ms]\n"
-           "pc7                  : [%020"PRIu64" ms]\n",
+    printf("pc2                  : [%20"PRIu64" ms]\n"
+           "pc3                  : [%20"PRIu64" ms]\n"
+           "pc6                  : [%20"PRIu64" ms]\n"
+           "pc7                  : [%20"PRIu64" ms]\n",
             cxstat->pc2/1000000UL, cxstat->pc3/1000000UL,
             cxstat->pc6/1000000UL, cxstat->pc7/1000000UL);
-    printf("cc3                  : [%020"PRIu64" ms]\n"
-           "cc6                  : [%020"PRIu64" ms]\n"
-           "cc7                  : [%020"PRIu64" ms]\n",
+    printf("cc3                  : [%20"PRIu64" ms]\n"
+           "cc6                  : [%20"PRIu64" ms]\n"
+           "cc7                  : [%20"PRIu64" ms]\n",
             cxstat->cc3/1000000UL, cxstat->cc6/1000000UL,
             cxstat->cc7/1000000UL);
     printf("\n");
@@ -114,7 +114,7 @@ static int get_cxstat_by_cpuid(xc_interf
=20
     ret =3D xc_pm_get_max_cx(xc_handle, cpuid, &max_cx_num);
     if ( ret )
-        return errno;
+        return -errno;
=20
     if ( !cxstat )
         return -EINVAL;
@@ -135,15 +135,14 @@ static int get_cxstat_by_cpuid(xc_interf
     ret =3D xc_pm_get_cxstat(xc_handle, cpuid, cxstat);
     if( ret )
     {
-        int temp =3D errno;
+        ret =3D -errno;
         free(cxstat->triggers);
         free(cxstat->residencies);
         cxstat->triggers =3D NULL;
         cxstat->residencies =3D NULL;
-        return temp;
     }
=20
-    return 0;
+    return ret;
 }
=20
 static int show_max_cstate(xc_interface *xc_handle)
@@ -214,14 +213,13 @@ static void print_pxstat(int cpuid, stru
     for ( i =3D 0; i < pxstat->total; i++ )
     {
         if ( pxstat->cur =3D=3D i )
-            printf("*P%d", i);
+            printf("*P%-9d", i);
         else
-            printf("P%d ", i);
-        printf("                  : freq       [%04"PRIu64" MHz]\n",
-               pxstat->pt[i].freq);
-        printf("                       transition [%020"PRIu64"]\n",
+            printf("P%-10d", i);
+        printf("[%4"PRIu64" MHz]", pxstat->pt[i].freq);
+        printf(": transition [%20"PRIu64"]\n",
                pxstat->pt[i].count);
-        printf("                       residency  [%020"PRIu64" ms]\n",
+        printf("                       residency  [%20"PRIu64" ms]\n",
                pxstat->pt[i].residency/1000000UL);
     }
     printf("\n");
@@ -235,7 +233,7 @@ static int get_pxstat_by_cpuid(xc_interf
=20
     ret =3D xc_pm_get_max_px(xc_handle, cpuid, &max_px_num);
     if ( ret )
-        return errno;
+        return -errno;
=20
     if ( !pxstat)
         return -EINVAL;
@@ -254,15 +252,14 @@ static int get_pxstat_by_cpuid(xc_interf
     ret =3D xc_pm_get_pxstat(xc_handle, cpuid, pxstat);
     if( ret )
     {
-        int temp =3D errno;
+        ret =3D -errno;
         free(pxstat->trans_pt);
         free(pxstat->pt);
         pxstat->trans_pt =3D NULL;
         pxstat->pt =3D NULL;
-        return temp;
     }
=20
-    return 0;
+    return ret;
 }
=20
 /* show cpu actual average freq information on CPU cpuid */
@@ -272,11 +269,9 @@ static int get_avgfreq_by_cpuid(xc_inter
=20
     ret =3D xc_get_cpufreq_avgfreq(xc_handle, cpuid, avgfreq);
     if ( ret )
-    {
-        return errno;
-    }
+        ret =3D -errno;
=20
-    return 0;
+    return ret;
 }
=20
 static int show_pxstat_by_cpuid(xc_interface *xc_handle, int cpuid)
@@ -325,7 +320,7 @@ static uint64_t *sum, *sum_cx, *sum_px;
=20
 static void signal_int_handler(int signo)
 {
-    int i, j, k, ret;
+    int i, j, k;
     struct timeval tv;
     int cx_cap =3D 0, px_cap =3D 0;
     DECLARE_HYPERCALL_BUFFER(uint32_t, cpu_to_core);
@@ -404,6 +399,8 @@ static void signal_int_handler(int signo
                         res / 1000000UL, 100UL * res / (double)sum_px[i]);=

             }
         }
+        if ( px_cap && avgfreq[i] )
+            printf("  Avg freq\t%d\tKHz\n", avgfreq[i]);
     }
=20
     set_xen_guest_handle(info.cpu_to_core, cpu_to_core);
@@ -411,8 +408,7 @@ static void signal_int_handler(int signo
     set_xen_guest_handle(info.cpu_to_node, cpu_to_node);
     info.max_cpu_index =3D MAX_NR_CPU - 1;
=20
-    ret =3D xc_topologyinfo(xc_handle, &info);
-    if ( !ret )
+    if ( cx_cap && !xc_topologyinfo(xc_handle, &info) )
     {
         uint32_t socket_ids[MAX_NR_CPU];
         uint32_t core_ids[MAX_NR_CPU];
@@ -461,7 +457,7 @@ static void signal_int_handler(int signo
                     if ( cpu_to_socket[j] =3D=3D socket_ids[i] )
                         break;
                 }
-                printf("Socket %d\n", socket_ids[i]);
+                printf("\nSocket %d\n", socket_ids[i]);
                 res =3D cxstat_end[j].pc2 - cxstat_start[j].pc2;
                 printf("\tPC2\t%"PRIu64" ms\t%.2f%%\n",  res / 1000000UL,
                        100UL * res / (double)sum_cx[j]);
@@ -492,12 +488,9 @@ static void signal_int_handler(int signo
                     res =3D cxstat_end[j].cc7 - cxstat_start[j].cc7;
                     printf("\t\tCC7\t%"PRIu64" ms\t%.2f%%\n",  res / =
1000000UL,
                            100UL * res / (double)sum_cx[j]);
-                    printf("\n");
-
                 }
             }
         }
-        printf("  Avg freq\t%d\tKHz\n", avgfreq[i]);
     }
=20
     /* some clean up and then exits */
@@ -542,23 +535,23 @@ void start_gather_func(int argc, char *a
     }
     usec_start =3D tv.tv_sec * 1000000UL + tv.tv_usec;
=20
-    sum =3D malloc(sizeof(uint64_t) * 2 * max_cpu_nr);
+    sum =3D calloc(2 * max_cpu_nr, sizeof(*sum));
     if ( sum =3D=3D NULL )
         return ;
-    cxstat =3D malloc(sizeof(struct xc_cx_stat) * 2 * max_cpu_nr);
+    cxstat =3D calloc(2 * max_cpu_nr, sizeof(*cxstat));
     if ( cxstat =3D=3D NULL )
     {
         free(sum);
         return ;
     }
-    pxstat =3D malloc(sizeof(struct xc_px_stat) * 2 * max_cpu_nr);
+    pxstat =3D calloc(2 * max_cpu_nr, sizeof(*pxstat));
     if ( pxstat =3D=3D NULL )
     {
         free(sum);
         free(cxstat);
         return ;
     }
-    avgfreq =3D malloc(sizeof(int) * max_cpu_nr);
+    avgfreq =3D calloc(max_cpu_nr, sizeof(*avgfreq));
     if ( avgfreq =3D=3D NULL )
     {
         free(sum);
@@ -566,10 +559,6 @@ void start_gather_func(int argc, char *a
         free(pxstat);
         return ;
     }
-    memset(sum, 0, sizeof(uint64_t) * 2 * max_cpu_nr);
-    memset(cxstat, 0, sizeof(struct xc_cx_stat) * 2 * max_cpu_nr);
-    memset(pxstat, 0, sizeof(struct xc_px_stat) * 2 * max_cpu_nr);
-    memset(avgfreq, 0, sizeof(int) * max_cpu_nr);
     sum_cx =3D sum;
     sum_px =3D sum + max_cpu_nr;
     cxstat_start =3D cxstat;



--=__PartB29D00F7.0__=
Content-Type: text/plain; name="xenpm-cleanup.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="xenpm-cleanup.patch"

xenpm: assorted adjustments=0A=0A- use consistent error values (stop =
mixing of [positive] errno values=0A  with literal -E... ones)=0A- =
properly format output=0A- don't use leading zeros in decimal output=0A- =
move printing of average frequency into P-state conditional (rather=0A  =
than a C-state one)=0A- don't print some C-state related info when CPU =
idle management is=0A  disabled in the hypervisor=0A- use calloc() for =
array allocations that also got cleared via memset()=0A  so far=0A=0ASigned=
-off-by: Jan Beulich <jbeulich@suse.com>=0A=0A--- a/tools/misc/xenpm.c=0A++=
+ b/tools/misc/xenpm.c=0A@@ -87,20 +87,20 @@ static void print_cxstat(int =
cpuid, stru=0A            cxstat->idle_time/1000000UL);=0A     for ( i =3D =
0; i < cxstat->nr; i++ )=0A     {=0A-        printf("C%d                   =
: transition [%020"PRIu64"]\n",=0A+        printf("C%-20d: transition =
[%20"PRIu64"]\n",=0A                i, cxstat->triggers[i]);=0A-        =
printf("                       residency  [%020"PRIu64" ms]\n",=0A+        =
printf("                       residency  [%20"PRIu64" ms]\n",=0A          =
      cxstat->residencies[i]/1000000UL);=0A     }=0A-    printf("pc2       =
           : [%020"PRIu64" ms]\n"=0A-           "pc3                  : =
[%020"PRIu64" ms]\n"=0A-           "pc6                  : [%020"PRIu64" =
ms]\n"=0A-           "pc7                  : [%020"PRIu64" ms]\n",=0A+    =
printf("pc2                  : [%20"PRIu64" ms]\n"=0A+           "pc3      =
            : [%20"PRIu64" ms]\n"=0A+           "pc6                  : =
[%20"PRIu64" ms]\n"=0A+           "pc7                  : [%20"PRIu64" =
ms]\n",=0A             cxstat->pc2/1000000UL, cxstat->pc3/1000000UL,=0A    =
         cxstat->pc6/1000000UL, cxstat->pc7/1000000UL);=0A-    printf("cc3 =
                 : [%020"PRIu64" ms]\n"=0A-           "cc6                 =
 : [%020"PRIu64" ms]\n"=0A-           "cc7                  : [%020"PRIu64"=
 ms]\n",=0A+    printf("cc3                  : [%20"PRIu64" ms]\n"=0A+     =
      "cc6                  : [%20"PRIu64" ms]\n"=0A+           "cc7       =
           : [%20"PRIu64" ms]\n",=0A             cxstat->cc3/1000000UL, =
cxstat->cc6/1000000UL,=0A             cxstat->cc7/1000000UL);=0A     =
printf("\n");=0A@@ -114,7 +114,7 @@ static int get_cxstat_by_cpuid(xc_inter=
f=0A =0A     ret =3D xc_pm_get_max_cx(xc_handle, cpuid, &max_cx_num);=0A   =
  if ( ret )=0A-        return errno;=0A+        return -errno;=0A =0A     =
if ( !cxstat )=0A         return -EINVAL;=0A@@ -135,15 +135,14 @@ static =
int get_cxstat_by_cpuid(xc_interf=0A     ret =3D xc_pm_get_cxstat(xc_handle=
, cpuid, cxstat);=0A     if( ret )=0A     {=0A-        int temp =3D =
errno;=0A+        ret =3D -errno;=0A         free(cxstat->triggers);=0A    =
     free(cxstat->residencies);=0A         cxstat->triggers =3D NULL;=0A   =
      cxstat->residencies =3D NULL;=0A-        return temp;=0A     }=0A =
=0A-    return 0;=0A+    return ret;=0A }=0A =0A static int show_max_cstate=
(xc_interface *xc_handle)=0A@@ -214,14 +213,13 @@ static void print_pxstat(=
int cpuid, stru=0A     for ( i =3D 0; i < pxstat->total; i++ )=0A     {=0A =
        if ( pxstat->cur =3D=3D i )=0A-            printf("*P%d", i);=0A+  =
          printf("*P%-9d", i);=0A         else=0A-            printf("P%d =
", i);=0A-        printf("                  : freq       [%04"PRIu64" =
MHz]\n",=0A-               pxstat->pt[i].freq);=0A-        printf("        =
               transition [%020"PRIu64"]\n",=0A+            printf("P%-10d"=
, i);=0A+        printf("[%4"PRIu64" MHz]", pxstat->pt[i].freq);=0A+       =
 printf(": transition [%20"PRIu64"]\n",=0A                pxstat->pt[i].cou=
nt);=0A-        printf("                       residency  [%020"PRIu64" =
ms]\n",=0A+        printf("                       residency  [%20"PRIu64" =
ms]\n",=0A                pxstat->pt[i].residency/1000000UL);=0A     }=0A  =
   printf("\n");=0A@@ -235,7 +233,7 @@ static int get_pxstat_by_cpuid(xc_in=
terf=0A =0A     ret =3D xc_pm_get_max_px(xc_handle, cpuid, &max_px_num);=0A=
     if ( ret )=0A-        return errno;=0A+        return -errno;=0A =0A  =
   if ( !pxstat)=0A         return -EINVAL;=0A@@ -254,15 +252,14 @@ static =
int get_pxstat_by_cpuid(xc_interf=0A     ret =3D xc_pm_get_pxstat(xc_handle=
, cpuid, pxstat);=0A     if( ret )=0A     {=0A-        int temp =3D =
errno;=0A+        ret =3D -errno;=0A         free(pxstat->trans_pt);=0A    =
     free(pxstat->pt);=0A         pxstat->trans_pt =3D NULL;=0A         =
pxstat->pt =3D NULL;=0A-        return temp;=0A     }=0A =0A-    return =
0;=0A+    return ret;=0A }=0A =0A /* show cpu actual average freq =
information on CPU cpuid */=0A@@ -272,11 +269,9 @@ static int get_avgfreq_b=
y_cpuid(xc_inter=0A =0A     ret =3D xc_get_cpufreq_avgfreq(xc_handle, =
cpuid, avgfreq);=0A     if ( ret )=0A-    {=0A-        return errno;=0A-   =
 }=0A+        ret =3D -errno;=0A =0A-    return 0;=0A+    return ret;=0A =
}=0A =0A static int show_pxstat_by_cpuid(xc_interface *xc_handle, int =
cpuid)=0A@@ -325,7 +320,7 @@ static uint64_t *sum, *sum_cx, *sum_px;=0A =
=0A static void signal_int_handler(int signo)=0A {=0A-    int i, j, k, =
ret;=0A+    int i, j, k;=0A     struct timeval tv;=0A     int cx_cap =3D =
0, px_cap =3D 0;=0A     DECLARE_HYPERCALL_BUFFER(uint32_t, cpu_to_core);=0A=
@@ -404,6 +399,8 @@ static void signal_int_handler(int signo=0A            =
             res / 1000000UL, 100UL * res / (double)sum_px[i]);=0A         =
    }=0A         }=0A+        if ( px_cap && avgfreq[i] )=0A+            =
printf("  Avg freq\t%d\tKHz\n", avgfreq[i]);=0A     }=0A =0A     set_xen_gu=
est_handle(info.cpu_to_core, cpu_to_core);=0A@@ -411,8 +408,7 @@ static =
void signal_int_handler(int signo=0A     set_xen_guest_handle(info.cpu_to_n=
ode, cpu_to_node);=0A     info.max_cpu_index =3D MAX_NR_CPU - 1;=0A =0A-   =
 ret =3D xc_topologyinfo(xc_handle, &info);=0A-    if ( !ret )=0A+    if ( =
cx_cap && !xc_topologyinfo(xc_handle, &info) )=0A     {=0A         =
uint32_t socket_ids[MAX_NR_CPU];=0A         uint32_t core_ids[MAX_NR_CPU];=
=0A@@ -461,7 +457,7 @@ static void signal_int_handler(int signo=0A         =
            if ( cpu_to_socket[j] =3D=3D socket_ids[i] )=0A                =
         break;=0A                 }=0A-                printf("Socket =
%d\n", socket_ids[i]);=0A+                printf("\nSocket %d\n", =
socket_ids[i]);=0A                 res =3D cxstat_end[j].pc2 - cxstat_start=
[j].pc2;=0A                 printf("\tPC2\t%"PRIu64" ms\t%.2f%%\n",  res / =
1000000UL,=0A                        100UL * res / (double)sum_cx[j]);=0A@@=
 -492,12 +488,9 @@ static void signal_int_handler(int signo=0A             =
        res =3D cxstat_end[j].cc7 - cxstat_start[j].cc7;=0A                =
     printf("\t\tCC7\t%"PRIu64" ms\t%.2f%%\n",  res / 1000000UL,=0A        =
                    100UL * res / (double)sum_cx[j]);=0A-                  =
  printf("\n");=0A-=0A                 }=0A             }=0A         }=0A- =
       printf("  Avg freq\t%d\tKHz\n", avgfreq[i]);=0A     }=0A =0A     /* =
some clean up and then exits */=0A@@ -542,23 +535,23 @@ void start_gather_f=
unc(int argc, char *a=0A     }=0A     usec_start =3D tv.tv_sec * 1000000UL =
+ tv.tv_usec;=0A =0A-    sum =3D malloc(sizeof(uint64_t) * 2 * max_cpu_nr);=
=0A+    sum =3D calloc(2 * max_cpu_nr, sizeof(*sum));=0A     if ( sum =
=3D=3D NULL )=0A         return ;=0A-    cxstat =3D malloc(sizeof(struct =
xc_cx_stat) * 2 * max_cpu_nr);=0A+    cxstat =3D calloc(2 * max_cpu_nr, =
sizeof(*cxstat));=0A     if ( cxstat =3D=3D NULL )=0A     {=0A         =
free(sum);=0A         return ;=0A     }=0A-    pxstat =3D malloc(sizeof(str=
uct xc_px_stat) * 2 * max_cpu_nr);=0A+    pxstat =3D calloc(2 * max_cpu_nr,=
 sizeof(*pxstat));=0A     if ( pxstat =3D=3D NULL )=0A     {=0A         =
free(sum);=0A         free(cxstat);=0A         return ;=0A     }=0A-    =
avgfreq =3D malloc(sizeof(int) * max_cpu_nr);=0A+    avgfreq =3D calloc(max=
_cpu_nr, sizeof(*avgfreq));=0A     if ( avgfreq =3D=3D NULL )=0A     {=0A  =
       free(sum);=0A@@ -566,10 +559,6 @@ void start_gather_func(int argc, =
char *a=0A         free(pxstat);=0A         return ;=0A     }=0A-    =
memset(sum, 0, sizeof(uint64_t) * 2 * max_cpu_nr);=0A-    memset(cxstat, =
0, sizeof(struct xc_cx_stat) * 2 * max_cpu_nr);=0A-    memset(pxstat, 0, =
sizeof(struct xc_px_stat) * 2 * max_cpu_nr);=0A-    memset(avgfreq, 0, =
sizeof(int) * max_cpu_nr);=0A     sum_cx =3D sum;=0A     sum_px =3D sum + =
max_cpu_nr;=0A     cxstat_start =3D cxstat;=0A
--=__PartB29D00F7.0__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--=__PartB29D00F7.0__=--


From xen-devel-bounces@lists.xensource.com Wed Dec 21 08:08:46 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 08: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.xensource.com>)
	id 1RdHDh-0002dk-6Q; Wed, 21 Dec 2011 08:08:13 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1RdHDf-0002dY-81
	for xen-devel@lists.xensource.com; Wed, 21 Dec 2011 08:08:11 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-12.tower-21.messagelabs.com!1324454881!8924721!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=1.1 required=7.0 tests=BODY_RANDOM_LONG,DIET_1
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28948 invoked from network); 21 Dec 2011 08:08:01 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-12.tower-21.messagelabs.com with SMTP;
	21 Dec 2011 08:08:01 -0000
Received: from [62.94.181.91] (account d.faggioli@sssup.it HELO [192.168.0.40])
	by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 74071203; Wed, 21 Dec 2011 09:07:59 +0100
Message-ID: <1324454839.2682.1.camel@Solace>
From: Dario Faggioli <raistlin@linux.it>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Wed, 21 Dec 2011 09:07:19 +0100
X-Mailer: Evolution 3.2.2-1 
Mime-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>, Keir Fraser <keir@xen.org>
Subject: [Xen-devel] [PATCH] sedf: remove useless tracing printk and
 harmonize comments style.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============7346677379948124988=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--===============7346677379948124988==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-ByODJfHW+wcj4VSHJBM9"


--=-ByODJfHW+wcj4VSHJBM9
Content-Type: multipart/mixed; boundary="=-SQC3wUYrGGqGq8T7E3BQ"


--=-SQC3wUYrGGqGq8T7E3BQ
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

sched_sedf.c used o have its own mechanism for producing tracing-alike
kind of information (domain block, wakeup, etc.). Nowadays, with an even
not so high number of pCPUs/vCPUs, just trying to enable this makes
the serial console completely unusable, produces tons of very hard to
parse and interpreet logging and can easily livelock Dom0. Moreover,
pretty much the same result this is struggling to get to, is better
achieved by enabling the scheduler-related tracing events, as
it is for the other schedulers (say, credit or credit2).

For all these reasons, this removes that machinery completely. While at
it, check in some cosmetics that harmonize the comments withim themself
and with the rest of the code base.

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>

diff -r 17d99691e0ec xen/common/sched_sedf.c
--- a/xen/common/sched_sedf.c	Tue Dec 20 16:39:56 2011 +0000
+++ b/xen/common/sched_sedf.c	Tue Dec 20 17:32:52 2011 +0000
@@ -13,14 +13,6 @@
 #include <xen/time.h>
 #include <xen/errno.h>
=20
-/*verbosity settings*/
-#define SEDFLEVEL 0
-#define PRINT(_f, _a...)                        \
-    do {                                        \
-        if ( (_f) <=3D SEDFLEVEL )                \
-            printk(_a );                        \
-    } while ( 0 )
-
 #define SEDF_CPUONLINE(_pool)                                             =
\
     (((_pool) =3D=3D NULL) ? &cpupool_free_cpus : (_pool)->cpu_valid)
=20
@@ -66,34 +58,35 @@ struct sedf_vcpu_info {
     struct list_head list;
     struct list_head extralist[2];
 =20
-    /*Parameters for EDF*/
-    s_time_t  period;  /*=3D(relative deadline)*/
-    s_time_t  slice;  /*=3Dworst case execution time*/
+    /* Parameters for EDF */
+    s_time_t  period;  /* =3D(relative deadline) */
+    s_time_t  slice;   /* =3Dworst case execution time */
 =20
-    /*Advaced Parameters*/
-    /*Latency Scaling*/
+    /* Advaced Parameters */
+
+    /* Latency Scaling */
     s_time_t  period_orig;
     s_time_t  slice_orig;
     s_time_t  latency;
 =20
-    /*status of domain*/
+    /* Status of domain */
     int       status;
-    /*weights for "Scheduling for beginners/ lazy/ etc." ;)*/
+    /* Weights for "Scheduling for beginners/ lazy/ etc." ;) */
     short     weight;
     short     extraweight;
-    /*Bookkeeping*/
+    /* Bookkeeping */
     s_time_t  deadl_abs;
     s_time_t  sched_start_abs;
     s_time_t  cputime;
-    /* times the domain un-/blocked */
+    /* Times the domain un-/blocked */
     s_time_t  block_abs;
     s_time_t  unblock_abs;
 =20
-    /*scores for {util, block penalty}-weighted extratime distribution*/
+    /* Scores for {util, block penalty}-weighted extratime distribution */
     int   score[2];
     s_time_t  short_block_lost_tot;
 =20
-    /*Statistics*/
+    /* Statistics */
     s_time_t  extra_time_tot;
=20
 #ifdef SEDF_STATS
@@ -158,18 +151,16 @@ static inline void extraq_del(struct vcp
 {
     struct list_head *list =3D EXTRALIST(d,i);
     ASSERT(extraq_on(d,i));
-    PRINT(3, "Removing domain %i.%i from L%i extraq\n",
-          d->domain->domain_id, d->vcpu_id, i);
     list_del(list);
     list->next =3D NULL;
     ASSERT(!extraq_on(d, i));
 }
=20
-/* adds a domain to the queue of processes which are aware of extra time. =
List
-   is sorted by score, where a lower score means higher priority for an ex=
tra
-   slice. It also updates the score, by simply subtracting a fixed value f=
rom
-   each entry, in order to avoid overflow. The algorithm works by simply
-   charging each domain that recieved extratime with an inverse of its wei=
ght.
+/* Adds a domain to the queue of processes which are aware of extra time. =
List
+ * is sorted by score, where a lower score means higher priority for an ex=
tra
+ * slice. It also updates the score, by simply subtracting a fixed value f=
rom
+ * each entry, in order to avoid overflow. The algorithm works by simply
+ * charging each domain that recieved extratime with an inverse of its wei=
ght.
  */=20
 static inline void extraq_add_sort_update(struct vcpu *d, int i, int sub)
 {
@@ -178,13 +169,7 @@ static inline void extraq_add_sort_updat
 =20
     ASSERT(!extraq_on(d,i));
=20
-    PRINT(3, "Adding domain %i.%i (score=3D %i, short_pen=3D %"PRIi64")"
-          " to L%i extraq\n",
-          d->domain->domain_id, d->vcpu_id, EDOM_INFO(d)->score[i],
-          EDOM_INFO(d)->short_block_lost_tot, i);
-
-    /*
-     * Iterate through all elements to find our "hole" and on our way
+    /* Iterate through all elements to find our "hole" and on our way
      * update all the other scores.
      */
     list_for_each ( cur, EXTRAQ(d->processor, i) )
@@ -193,25 +178,18 @@ static inline void extraq_add_sort_updat
         curinf->score[i] -=3D sub;
         if ( EDOM_INFO(d)->score[i] < curinf->score[i] )
             break;
-        PRINT(4,"\tbehind domain %i.%i (score=3D %i)\n",
-              curinf->vcpu->domain->domain_id,
-              curinf->vcpu->vcpu_id, curinf->score[i]);
     }
=20
-    /* cur now contains the element, before which we'll enqueue. */
-    PRINT(3, "\tlist_add to %p\n", cur->prev);
+    /* cur now contains the element, before which we'll enqueue */
     list_add(EXTRALIST(d,i),cur->prev);
 =20
-    /* Continue updating the extraq. */
+    /* Continue updating the extraq */
     if ( (cur !=3D EXTRAQ(d->processor,i)) && sub )
     {
         for ( cur =3D cur->next; cur !=3D EXTRAQ(d->processor,i); cur =3D =
cur->next )
         {
             curinf =3D list_entry(cur,struct sedf_vcpu_info, extralist[i])=
;
             curinf->score[i] -=3D sub;
-            PRINT(4, "\tupdating domain %i.%i (score=3D %u)\n",
-                  curinf->vcpu->domain->domain_id,=20
-                  curinf->vcpu->vcpu_id, curinf->score[i]);
         }
     }
=20
@@ -221,29 +199,14 @@ static inline void extraq_check(struct v
 {
     if ( extraq_on(d, EXTRA_UTIL_Q) )
     {
-        PRINT(2,"Dom %i.%i is on L1 extraQ\n",
-              d->domain->domain_id, d->vcpu_id);
-
         if ( !(EDOM_INFO(d)->status & EXTRA_AWARE) &&
              !extra_runs(EDOM_INFO(d)) )
-        {
             extraq_del(d, EXTRA_UTIL_Q);
-            PRINT(2,"Removed dom %i.%i from L1 extraQ\n",
-                  d->domain->domain_id, d->vcpu_id);
-        }
     }
     else
     {
-        PRINT(2, "Dom %i.%i is NOT on L1 extraQ\n",
-              d->domain->domain_id,
-              d->vcpu_id);
-
         if ( (EDOM_INFO(d)->status & EXTRA_AWARE) && sedf_runnable(d) )
-        {
             extraq_add_sort_update(d, EXTRA_UTIL_Q, 0);
-            PRINT(2,"Added dom %i.%i to L1 extraQ\n",
-                  d->domain->domain_id, d->vcpu_id);
-        }
     }
 }
=20
@@ -252,7 +215,7 @@ static inline void extraq_check_add_unbl
     struct sedf_vcpu_info *inf =3D EDOM_INFO(d);
=20
     if ( inf->status & EXTRA_AWARE )
-        /* Put on the weighted extraq without updating any scores. */
+        /* Put on the weighted extraq without updating any scores */
         extraq_add_sort_update(d, EXTRA_UTIL_Q, 0);
 }
=20
@@ -265,8 +228,6 @@ static inline void __del_from_queue(stru
 {
     struct list_head *list =3D LIST(d);
     ASSERT(__task_on_queue(d));
-    PRINT(3,"Removing domain %i.%i (bop=3D %"PRIu64") from runq/waitq\n",
-          d->domain->domain_id, d->vcpu_id, PERIOD_BEGIN(EDOM_INFO(d)));
     list_del(list);
     list->next =3D NULL;
     ASSERT(!__task_on_queue(d));
@@ -279,13 +240,12 @@ static inline void list_insert_sort(
 {
     struct list_head     *cur;
=20
-    /* Iterate through all elements to find our "hole". */
+    /* Iterate through all elements to find our "hole" */
     list_for_each( cur, list )
         if ( comp(element, cur) < 0 )
             break;
=20
-    /* cur now contains the element, before which we'll enqueue. */
-    PRINT(3,"\tlist_add to %p\n",cur->prev);
+    /* cur now contains the element, before which we'll enqueue */
     list_add(element, cur->prev);
 }
=20
@@ -303,30 +263,26 @@ static int name##_comp(struct list_head*
         return 1;                                                       \
 }
=20
-/* adds a domain to the queue of processes which wait for the beginning of=
 the
-   next period; this list is therefore sortet by this time, which is simpl=
y
-   absol. deadline - period
+/* Adds a domain to the queue of processes which wait for the beginning of=
 the
+ * next period; this list is therefore sortet by this time, which is simpl=
y
+ * absol. deadline - period.
  */=20
 DOMAIN_COMPARER(waitq, list, PERIOD_BEGIN(d1), PERIOD_BEGIN(d2));
 static inline void __add_to_waitqueue_sort(struct vcpu *v)
 {
     ASSERT(!__task_on_queue(v));
-    PRINT(3,"Adding domain %i.%i (bop=3D %"PRIu64") to waitq\n",
-          v->domain->domain_id, v->vcpu_id, PERIOD_BEGIN(EDOM_INFO(v)));
     list_insert_sort(WAITQ(v->processor), LIST(v), waitq_comp);
     ASSERT(__task_on_queue(v));
 }
=20
-/* adds a domain to the queue of processes which have started their curren=
t
-   period and are runnable (i.e. not blocked, dieing,...). The first eleme=
nt
-   on this list is running on the processor, if the list is empty the idle
-   task will run. As we are implementing EDF, this list is sorted by deadl=
ines.
+/* Adds a domain to the queue of processes which have started their curren=
t
+ * period and are runnable (i.e. not blocked, dieing,...). The first eleme=
nt
+ * on this list is running on the processor, if the list is empty the idle
+ * task will run. As we are implementing EDF, this list is sorted by deadl=
ines.
  */=20
 DOMAIN_COMPARER(runq, list, d1->deadl_abs, d2->deadl_abs);
 static inline void __add_to_runqueue_sort(struct vcpu *v)
 {
-    PRINT(3,"Adding domain %i.%i (deadl=3D %"PRIu64") to runq\n",
-          v->domain->domain_id, v->vcpu_id, EDOM_INFO(v)->deadl_abs);
     list_insert_sort(RUNQ(v->processor), LIST(v), runq_comp);
 }
=20
@@ -445,22 +401,21 @@ static int sedf_pick_cpu(const struct sc
     return cpumask_first(&online_affinity);
 }
=20
-/*
- * Handles the rescheduling & bookkeeping of domains running in their
+
+/* Handles the rescheduling & bookkeeping of domains running in their
  * guaranteed timeslice.
  */
 static void desched_edf_dom(s_time_t now, struct vcpu* d)
 {
     struct sedf_vcpu_info* inf =3D EDOM_INFO(d);
=20
-    /* Current domain is running in real time mode. */
+    /* Current domain is running in real time mode */
     ASSERT(__task_on_queue(d));
=20
-    /* Update the domain's cputime. */
+    /* Update the domain's cputime */
     inf->cputime +=3D now - inf->sched_start_abs;
=20
-    /*
-     * Scheduling decisions which don't remove the running domain from the
+    /* Scheduling decisions which don't remove the running domain from the
      * runq.=20
      */
     if ( (inf->cputime < inf->slice) && sedf_runnable(d) )
@@ -468,8 +423,7 @@ static void desched_edf_dom(s_time_t now
  =20
     __del_from_queue(d);
  =20
-    /*
-     * Manage bookkeeping (i.e. calculate next deadline, memorise
+    /* Manage bookkeeping (i.e. calculate next deadline, memorise
      * overrun-time of slice) of finished domains.
      */
     if ( inf->cputime >=3D inf->slice )
@@ -478,30 +432,30 @@ static void desched_edf_dom(s_time_t now
  =20
         if ( inf->period < inf->period_orig )
         {
-            /* This domain runs in latency scaling or burst mode. */
+            /* This domain runs in latency scaling or burst mode */
             inf->period *=3D 2;
             inf->slice  *=3D 2;
             if ( (inf->period > inf->period_orig) ||
                  (inf->slice > inf->slice_orig) )
             {
-                /* Reset slice and period. */
+                /* Reset slice and period */
                 inf->period =3D inf->period_orig;
                 inf->slice =3D inf->slice_orig;
             }
         }
=20
-        /* Set next deadline. */
+        /* Set next deadline */
         inf->deadl_abs +=3D inf->period;
     }
 =20
-    /* Add a runnable domain to the waitqueue. */
+    /* Add a runnable domain to the waitqueue */
     if ( sedf_runnable(d) )
     {
         __add_to_waitqueue_sort(d);
     }
     else
     {
-        /* We have a blocked realtime task -> remove it from exqs too. */
+        /* We have a blocked realtime task -> remove it from exqs too */
         if ( extraq_on(d, EXTRA_PEN_Q) )
             extraq_del(d, EXTRA_PEN_Q);
         if ( extraq_on(d, EXTRA_UTIL_Q) )
@@ -521,73 +475,59 @@ static void update_queues(
     struct list_head     *cur, *tmp;
     struct sedf_vcpu_info *curinf;
 =20
-    PRINT(3,"Updating waitq..\n");
-
-    /*
-     * Check for the first elements of the waitqueue, whether their
+    /* Check for the first elements of the waitqueue, whether their
      * next period has already started.
      */
     list_for_each_safe ( cur, tmp, waitq )
     {
         curinf =3D list_entry(cur, struct sedf_vcpu_info, list);
-        PRINT(4,"\tLooking @ dom %i.%i\n",
-              curinf->vcpu->domain->domain_id, curinf->vcpu->vcpu_id);
         if ( PERIOD_BEGIN(curinf) > now )
             break;
         __del_from_queue(curinf->vcpu);
         __add_to_runqueue_sort(curinf->vcpu);
     }
 =20
-    PRINT(3,"Updating runq..\n");
-
-    /* Process the runq, find domains that are on the runq that shouldn't.=
 */
+    /* Process the runq, find domains that are on the runq that shouldn't =
*/
     list_for_each_safe ( cur, tmp, runq )
     {
         curinf =3D list_entry(cur,struct sedf_vcpu_info,list);
-        PRINT(4,"\tLooking @ dom %i.%i\n",
-              curinf->vcpu->domain->domain_id, curinf->vcpu->vcpu_id);
=20
         if ( unlikely(curinf->slice =3D=3D 0) )
         {
-            /* Ignore domains with empty slice. */
-            PRINT(4,"\tUpdating zero-slice domain %i.%i\n",
-                  curinf->vcpu->domain->domain_id,
-                  curinf->vcpu->vcpu_id);
+            /* Ignore domains with empty slice */
             __del_from_queue(curinf->vcpu);
=20
-            /* Move them to their next period. */
+            /* Move them to their next period */
             curinf->deadl_abs +=3D curinf->period;
=20
-            /* Ensure that the start of the next period is in the future. =
*/
+            /* Ensure that the start of the next period is in the future *=
/
             if ( unlikely(PERIOD_BEGIN(curinf) < now) )
                 curinf->deadl_abs +=3D=20
                     (DIV_UP(now - PERIOD_BEGIN(curinf),
                             curinf->period)) * curinf->period;
=20
-            /* Put them back into the queue. */
+            /* Put them back into the queue */
             __add_to_waitqueue_sort(curinf->vcpu);
         }
         else if ( unlikely((curinf->deadl_abs < now) ||
                            (curinf->cputime > curinf->slice)) )
         {
-            /*
-             * We missed the deadline or the slice was already finished.
+            /* We missed the deadline or the slice was already finished.
              * Might hapen because of dom_adj.
              */
-            PRINT(4,"\tDomain %i.%i exceeded it's deadline/"
-                  "slice (%"PRIu64" / %"PRIu64") now: %"PRIu64
-                  " cputime: %"PRIu64"\n",
-                  curinf->vcpu->domain->domain_id,
-                  curinf->vcpu->vcpu_id,
-                  curinf->deadl_abs, curinf->slice, now,
-                  curinf->cputime);
+            printk("\tDomain %i.%i exceeded it's deadline/"
+                   "slice (%"PRIu64" / %"PRIu64") now: %"PRIu64
+                   " cputime: %"PRIu64"\n",
+                   curinf->vcpu->domain->domain_id,
+                   curinf->vcpu->vcpu_id,
+                   curinf->deadl_abs, curinf->slice, now,
+                   curinf->cputime);
             __del_from_queue(curinf->vcpu);
=20
-            /* Common case: we miss one period. */
+            /* Common case: we miss one period */
             curinf->deadl_abs +=3D curinf->period;
   =20
-            /*
-             * If we are still behind: modulo arithmetic, force deadline
+            /* If we are still behind: modulo arithmetic, force deadline
              * to be in future and aligned to period borders.
              */
             if ( unlikely(curinf->deadl_abs < now) )
@@ -596,7 +536,7 @@ static void update_queues(
                            curinf->period) * curinf->period;
             ASSERT(curinf->deadl_abs >=3D now);
=20
-            /* Give a fresh slice. */
+            /* Give a fresh slice */
             curinf->cputime =3D 0;
             if ( PERIOD_BEGIN(curinf) > now )
                 __add_to_waitqueue_sort(curinf->vcpu);
@@ -606,17 +546,16 @@ static void update_queues(
         else
             break;
     }
-
-    PRINT(3,"done updating the queues\n");
 }
=20

 /* removes a domain from the head of the according extraQ and
-   requeues it at a specified position:
-     round-robin extratime: end of extraQ
-     weighted ext.: insert in sorted list by score
-   if the domain is blocked / has regained its short-block-loss
-   time it is not put on any queue */
+ * requeues it at a specified position:
+ *   round-robin extratime: end of extraQ
+ *   weighted ext.: insert in sorted list by score
+ * if the domain is blocked / has regained its short-block-loss
+ * time it is not put on any queue.
+ */
 static void desched_extra_dom(s_time_t now, struct vcpu *d)
 {
     struct sedf_vcpu_info *inf =3D EDOM_INFO(d);
@@ -625,29 +564,25 @@ static void desched_extra_dom(s_time_t n
=20
     ASSERT(extraq_on(d, i));
=20
-    /* Unset all running flags. */
+    /* Unset all running flags */
     inf->status  &=3D ~(EXTRA_RUN_PEN | EXTRA_RUN_UTIL);
-    /* Fresh slice for the next run. */
+    /* Fresh slice for the next run */
     inf->cputime =3D 0;
-    /* Accumulate total extratime. */
+    /* Accumulate total extratime */
     inf->extra_time_tot +=3D now - inf->sched_start_abs;
     /* Remove extradomain from head of the queue. */
     extraq_del(d, i);
=20
-    /* Update the score. */
+    /* Update the score */
     oldscore =3D inf->score[i];
     if ( i =3D=3D EXTRA_PEN_Q )
     {
-        /*domain was running in L0 extraq*/
-        /*reduce block lost, probably more sophistication here!*/
+        /* Domain was running in L0 extraq */
+        /* reduce block lost, probably more sophistication here!*/
         /*inf->short_block_lost_tot -=3D EXTRA_QUANTUM;*/
         inf->short_block_lost_tot -=3D now - inf->sched_start_abs;
-        PRINT(3,"Domain %i.%i: Short_block_loss: %"PRIi64"\n",=20
-              inf->vcpu->domain->domain_id, inf->vcpu->vcpu_id,
-              inf->short_block_lost_tot);
 #if 0
-        /*
-         * KAF: If we don't exit short-blocking state at this point
+        /* KAF: If we don't exit short-blocking state at this point
          * domain0 can steal all CPU for up to 10 seconds before
          * scheduling settles down (when competing against another
          * CPU-bound domain). Doing this seems to make things behave
@@ -656,51 +591,56 @@ static void desched_extra_dom(s_time_t n
         if ( inf->short_block_lost_tot <=3D 0 )
 #endif
         {
-            PRINT(4,"Domain %i.%i compensated short block loss!\n",
-                  inf->vcpu->domain->domain_id, inf->vcpu->vcpu_id);
-            /*we have (over-)compensated our block penalty*/
+            /* We have (over-)compensated our block penalty */
             inf->short_block_lost_tot =3D 0;
-            /*we don't want a place on the penalty queue anymore!*/
+            /* We don't want a place on the penalty queue anymore! */
             inf->status &=3D ~EXTRA_WANT_PEN_Q;
             goto check_extra_queues;
         }
=20
-        /*we have to go again for another try in the block-extraq,
-          the score is not used incremantally here, as this is
-          already done by recalculating the block_lost*/
+        /* We have to go again for another try in the block-extraq,
+         * the score is not used incremantally here, as this is
+         * already done by recalculating the block_lost
+         */
         inf->score[EXTRA_PEN_Q] =3D (inf->period << 10) /
             inf->short_block_lost_tot;
         oldscore =3D 0;
     }
     else
     {
-        /*domain was running in L1 extraq =3D> score is inverse of
-          utilization and is used somewhat incremental!*/
+        /* Domain was running in L1 extraq =3D> score is inverse of
+         * utilization and is used somewhat incremental!
+         */
         if ( !inf->extraweight )
-            /*NB: use fixed point arithmetic with 10 bits*/
+        {
+            /* NB: use fixed point arithmetic with 10 bits */
             inf->score[EXTRA_UTIL_Q] =3D (inf->period << 10) /
                 inf->slice;
+        }
         else
-            /*conversion between realtime utilisation and extrawieght:
-              full (ie 100%) utilization is equivalent to 128 extraweight*=
/
+        {
+            /* Conversion between realtime utilisation and extrawieght:
+             * full (ie 100%) utilization is equivalent to 128 extraweight
+             */
             inf->score[EXTRA_UTIL_Q] =3D (1<<17) / inf->extraweight;
+        }
     }
=20
  check_extra_queues:
-    /* Adding a runnable domain to the right queue and removing blocked on=
es*/
+    /* Adding a runnable domain to the right queue and removing blocked on=
es */
     if ( sedf_runnable(d) )
     {
-        /*add according to score: weighted round robin*/
+        /* Add according to score: weighted round robin */
         if (((inf->status & EXTRA_AWARE) && (i =3D=3D EXTRA_UTIL_Q)) ||
             ((inf->status & EXTRA_WANT_PEN_Q) && (i =3D=3D EXTRA_PEN_Q)))
             extraq_add_sort_update(d, i, oldscore);
     }
     else
     {
-        /*remove this blocked domain from the waitq!*/
+        /* Remove this blocked domain from the waitq! */
         __del_from_queue(d);
-        /*make sure that we remove a blocked domain from the other
-          extraq too*/
+        /* Make sure that we remove a blocked domain from the other
+         * extraq too. */
         if ( i =3D=3D EXTRA_PEN_Q )
         {
             if ( extraq_on(d, EXTRA_UTIL_Q) )
@@ -732,8 +672,9 @@ static struct task_slice sedf_do_extra_s
=20
     if ( !list_empty(extraq[EXTRA_PEN_Q]) )
     {
-        /*we still have elements on the level 0 extraq=20
-          =3D> let those run first!*/
+        /* We still have elements on the level 0 extraq
+         * =3D> let those run first!
+         */
         runinf   =3D list_entry(extraq[EXTRA_PEN_Q]->next,=20
                               struct sedf_vcpu_info, extralist[EXTRA_PEN_Q=
]);
         runinf->status |=3D EXTRA_RUN_PEN;
@@ -747,7 +688,7 @@ static struct task_slice sedf_do_extra_s
     {
         if ( !list_empty(extraq[EXTRA_UTIL_Q]) )
         {
-            /*use elements from the normal extraqueue*/
+            /* Use elements from the normal extraqueue */
             runinf   =3D list_entry(extraq[EXTRA_UTIL_Q]->next,
                                   struct sedf_vcpu_info,
                                   extralist[EXTRA_UTIL_Q]);
@@ -773,10 +714,11 @@ static struct task_slice sedf_do_extra_s
=20

 /* Main scheduling function
-   Reasons for calling this function are:
-   -timeslice for the current period used up
-   -domain on waitqueue has started it's period
-   -and various others ;) in general: determine which domain to run next*/
+ * Reasons for calling this function are:
+ * -timeslice for the current period used up
+ * -domain on waitqueue has started it's period
+ * -and various others ;) in general: determine which domain to run next
+ */
 static struct task_slice sedf_do_schedule(
     const struct scheduler *ops, s_time_t now, bool_t tasklet_work_schedul=
ed)
 {
@@ -789,13 +731,14 @@ static struct task_slice sedf_do_schedul
     struct sedf_vcpu_info *runinf, *waitinf;
     struct task_slice      ret;
=20
-    /*idle tasks don't need any of the following stuf*/
+    /* Idle tasks don't need any of the following stuf */
     if ( is_idle_vcpu(current) )
         goto check_waitq;
 =20
-    /* create local state of the status of the domain, in order to avoid
-       inconsistent state during scheduling decisions, because data for
-       vcpu_runnable is not protected by the scheduling lock!*/
+    /* Create local state of the status of the domain, in order to avoid
+     * inconsistent state during scheduling decisions, because data for
+     * vcpu_runnable is not protected by the scheduling lock!
+     */
     if ( !vcpu_runnable(current) )
         inf->status |=3D SEDF_ASLEEP;
 =20
@@ -804,7 +747,7 @@ static struct task_slice sedf_do_schedul
=20
     if ( unlikely(extra_runs(inf)) )
     {
-        /*special treatment of domains running in extra time*/
+        /* Special treatment of domains running in extra time */
         desched_extra_dom(now, current);
     }
     else=20
@@ -814,10 +757,11 @@ static struct task_slice sedf_do_schedul
  check_waitq:
     update_queues(now, runq, waitq);
=20
-    /*now simply pick the first domain from the runqueue, which has the
-      earliest deadline, because the list is sorted*/
-=20
-    /* Tasklet work (which runs in idle VCPU context) overrides all else. =
*/
+    /* Now simply pick the first domain from the runqueue, which has the
+     * earliest deadline, because the list is sorted
+     *
+     * Tasklet work (which runs in idle VCPU context) overrides all else.
+     */
     if ( tasklet_work_scheduled ||
          (list_empty(runq) && list_empty(waitq)) ||
          unlikely(!cpumask_test_cpu(cpu, SEDF_CPUONLINE(per_cpu(cpupool, c=
pu)))) )
@@ -833,9 +777,10 @@ static struct task_slice sedf_do_schedul
         {
             waitinf  =3D list_entry(waitq->next,
                                   struct sedf_vcpu_info,list);
-            /*rerun scheduler, when scheduled domain reaches it's
-              end of slice or the first domain from the waitqueue
-              gets ready*/
+            /* Rerun scheduler, when scheduled domain reaches it's
+             * end of slice or the first domain from the waitqueue
+             * gets ready.
+             */
             ret.time =3D MIN(now + runinf->slice - runinf->cputime,
                            PERIOD_BEGIN(waitinf)) - now;
         }
@@ -847,14 +792,15 @@ static struct task_slice sedf_do_schedul
     else
     {
         waitinf  =3D list_entry(waitq->next,struct sedf_vcpu_info, list);
-        /*we could not find any suitable domain=20
-          =3D> look for domains that are aware of extratime*/
+        /* We could not find any suitable domain=20
+         * =3D> look for domains that are aware of extratime*/
         ret =3D sedf_do_extra_schedule(now, PERIOD_BEGIN(waitinf),
                                      extraq, cpu);
     }
=20
-    /*TODO: Do something USEFUL when this happens and find out, why it
-      still can happen!!!*/
+    /* TODO: Do something USEFUL when this happens and find out, why it
+     * still can happen!!!
+     */
     if ( ret.time < 0)
     {
         printk("Ouch! We are seriously BEHIND schedule! %"PRIi64"\n",
@@ -874,9 +820,6 @@ static struct task_slice sedf_do_schedul
=20
 static void sedf_sleep(const struct scheduler *ops, struct vcpu *d)
 {
-    PRINT(2,"sedf_sleep was called, domain-id %i.%i\n",
-          d->domain->domain_id, d->vcpu_id);
-=20
     if ( is_idle_vcpu(d) )
         return;
=20
@@ -972,27 +915,29 @@ static void sedf_sleep(const struct sche
 static void unblock_short_extra_support(
     struct sedf_vcpu_info* inf, s_time_t now)
 {
-    /*this unblocking scheme tries to support the domain, by assigning it
-    a priority in extratime distribution according to the loss of time
-    in this slice due to blocking*/
+    /* This unblocking scheme tries to support the domain, by assigning it
+     * a priority in extratime distribution according to the loss of time
+     * in this slice due to blocking
+     */
     s_time_t pen;
 =20
-    /*no more realtime execution in this period!*/
+    /* No more realtime execution in this period! */
     inf->deadl_abs +=3D inf->period;
     if ( likely(inf->block_abs) )
     {
-        //treat blocked time as consumed by the domain*/
+        /* Treat blocked time as consumed by the domain */
         /*inf->cputime +=3D now - inf->block_abs;*/
-        /*penalty is time the domain would have
-          had if it continued to run */
+        /* Penalty is time the domain would have
+         * had if it continued to run.
+         */
         pen =3D (inf->slice - inf->cputime);
         if ( pen < 0 )
             pen =3D 0;
-        /*accumulate all penalties over the periods*/
+        /* Accumulate all penalties over the periods */
         /*inf->short_block_lost_tot +=3D pen;*/
-        /*set penalty to the current value*/
+        /* Set penalty to the current value */
         inf->short_block_lost_tot =3D pen;
-        /*not sure which one is better.. but seems to work well...*/
+        /* Not sure which one is better.. but seems to work well... */
  =20
         if ( inf->short_block_lost_tot )
         {
@@ -1002,28 +947,30 @@ static void unblock_short_extra_support(
             inf->pen_extra_blocks++;
 #endif
             if ( extraq_on(inf->vcpu, EXTRA_PEN_Q) )
-                /*remove domain for possible resorting!*/
+                /* Remove domain for possible resorting! */
                 extraq_del(inf->vcpu, EXTRA_PEN_Q);
             else
-                /*remember that we want to be on the penalty q
-                  so that we can continue when we (un-)block
-                  in penalty-extratime*/
+                /* Remember that we want to be on the penalty q
+                 * so that we can continue when we (un-)block
+                 * in penalty-extratime
+                 */
                 inf->status |=3D EXTRA_WANT_PEN_Q;
   =20
-            /*(re-)add domain to the penalty extraq*/
+            /* (re-)add domain to the penalty extraq */
             extraq_add_sort_update(inf->vcpu, EXTRA_PEN_Q, 0);
         }
     }
=20
-    /*give it a fresh slice in the next period!*/
+    /* Give it a fresh slice in the next period! */
     inf->cputime =3D 0;
 }
=20

 static void unblock_long_cons_b(struct sedf_vcpu_info* inf,s_time_t now)
 {
-    /*Conservative 2b*/
-    /*Treat the unblocking time as a start of a new period */
+    /* Conservative 2b */
+
+    /* Treat the unblocking time as a start of a new period */
     inf->deadl_abs =3D now + inf->period;
     inf->cputime =3D 0;
 }
@@ -1046,15 +993,16 @@ static inline int get_run_type(struct vc
 }
=20

-/*Compares two domains in the relation of whether the one is allowed to
-  interrupt the others execution.
-  It returns true (!=3D0) if a switch to the other domain is good.
-  Current Priority scheme is as follows:
-   EDF > L0 (penalty based) extra-time >=20
-   L1 (utilization) extra-time > idle-domain
-  In the same class priorities are assigned as following:
-   EDF: early deadline > late deadline
-   L0 extra-time: lower score > higher score*/
+/* Compares two domains in the relation of whether the one is allowed to
+ * interrupt the others execution.
+ * It returns true (!=3D0) if a switch to the other domain is good.
+ * Current Priority scheme is as follows:
+ *  EDF > L0 (penalty based) extra-time >=20
+ *  L1 (utilization) extra-time > idle-domain
+ * In the same class priorities are assigned as following:
+ *  EDF: early deadline > late deadline
+ *  L0 extra-time: lower score > higher score
+ */
 static inline int should_switch(struct vcpu *cur,
                                 struct vcpu *other,
                                 s_time_t now)
@@ -1063,19 +1011,19 @@ static inline int should_switch(struct v
     cur_inf   =3D EDOM_INFO(cur);
     other_inf =3D EDOM_INFO(other);
 =20
-    /* Check whether we need to make an earlier scheduling decision. */
+    /* Check whether we need to make an earlier scheduling decision */
     if ( PERIOD_BEGIN(other_inf) <=20
          CPU_INFO(other->processor)->current_slice_expires )
         return 1;
=20
-    /* No timing-based switches need to be taken into account here. */
+    /* No timing-based switches need to be taken into account here */
     switch ( get_run_type(cur) )
     {
     case DOMAIN_EDF:
-        /* Do not interrupt a running EDF domain. */
+        /* Do not interrupt a running EDF domain */
         return 0;
     case DOMAIN_EXTRA_PEN:
-        /* Check whether we also want the L0 ex-q with lower score. */
+        /* Check whether we also want the L0 ex-q with lower score */
         return ((other_inf->status & EXTRA_WANT_PEN_Q) &&
                 (other_inf->score[EXTRA_PEN_Q] <=20
                  cur_inf->score[EXTRA_PEN_Q]));
@@ -1096,18 +1044,11 @@ static void sedf_wake(const struct sched
     s_time_t              now =3D NOW();
     struct sedf_vcpu_info* inf =3D EDOM_INFO(d);
=20
-    PRINT(3, "sedf_wake was called, domain-id %i.%i\n",d->domain->domain_i=
d,
-          d->vcpu_id);
-
     if ( unlikely(is_idle_vcpu(d)) )
         return;
   =20
     if ( unlikely(__task_on_queue(d)) )
-    {
-        PRINT(3,"\tdomain %i.%i is already in some queue\n",
-              d->domain->domain_id, d->vcpu_id);
         return;
-    }
=20
     ASSERT(!sedf_runnable(d));
     inf->status &=3D ~SEDF_ASLEEP;
@@ -1116,28 +1057,24 @@ static void sedf_wake(const struct sched
 =20
     if ( unlikely(inf->deadl_abs =3D=3D 0) )
     {
-        /*initial setup of the deadline*/
+        /* Initial setup of the deadline */
         inf->deadl_abs =3D now + inf->slice;
     }
  =20
-    PRINT(3, "waking up domain %i.%i (deadl=3D %"PRIu64" period=3D %"PRIu6=
4
-          "now=3D %"PRIu64")\n",
-          d->domain->domain_id, d->vcpu_id, inf->deadl_abs, inf->period, n=
ow);
-
 #ifdef SEDF_STATS=20
     inf->block_tot++;
 #endif
=20
     if ( unlikely(now < PERIOD_BEGIN(inf)) )
     {
-        PRINT(4,"extratime unblock\n");
-        /* unblocking in extra-time! */
+        /* Unblocking in extra-time! */
         if ( inf->status & EXTRA_WANT_PEN_Q )
         {
-            /*we have a domain that wants compensation
-              for block penalty and did just block in
-              its compensation time. Give it another
-              chance!*/
+            /* We have a domain that wants compensation
+             * for block penalty and did just block in
+             * its compensation time. Give it another
+             * chance!
+             */
             extraq_add_sort_update(d, EXTRA_PEN_Q, 0);
         }
         extraq_check_add_unblocked(d, 0);
@@ -1146,8 +1083,7 @@ static void sedf_wake(const struct sched
     { =20
         if ( now < inf->deadl_abs )
         {
-            PRINT(4,"short unblocking\n");
-            /*short blocking*/
+            /* Short blocking */
 #ifdef SEDF_STATS
             inf->short_block_tot++;
 #endif
@@ -1157,8 +1093,7 @@ static void sedf_wake(const struct sched
         }
         else
         {
-            PRINT(4,"long unblocking\n");
-            /*long unblocking*/
+            /* Long unblocking */
 #ifdef SEDF_STATS
             inf->long_block_tot++;
 #endif
@@ -1168,24 +1103,13 @@ static void sedf_wake(const struct sched
         }
     }
=20
-    PRINT(3, "woke up domain %i.%i (deadl=3D %"PRIu64" period=3D %"PRIu64
-          "now=3D %"PRIu64")\n",
-          d->domain->domain_id, d->vcpu_id, inf->deadl_abs,
-          inf->period, now);
-
     if ( PERIOD_BEGIN(inf) > now )
-    {
         __add_to_waitqueue_sort(d);
-        PRINT(3,"added to waitq\n");
-    }
     else
-    {
         __add_to_runqueue_sort(d);
-        PRINT(3,"added to runq\n");
-    }
 =20
 #ifdef SEDF_STATS
-    /*do some statistics here...*/
+    /* Do some statistics here... */
     if ( inf->block_abs !=3D 0 )
     {
         inf->block_time_tot +=3D now - inf->block_abs;
@@ -1194,12 +1118,13 @@ static void sedf_wake(const struct sched
     }
 #endif
=20
-    /*sanity check: make sure each extra-aware domain IS on the util-q!*/
+    /* Sanity check: make sure each extra-aware domain IS on the util-q! *=
/
     ASSERT(IMPLY(inf->status & EXTRA_AWARE, extraq_on(d, EXTRA_UTIL_Q)));
     ASSERT(__task_on_queue(d));
-    /*check whether the awakened task needs to invoke the do_schedule
-      routine. Try to avoid unnecessary runs but:
-      Save approximation: Always switch to scheduler!*/
+    /* Check whether the awakened task needs to invoke the do_schedule
+     * routine. Try to avoid unnecessary runs but:
+     * Save approximation: Always switch to scheduler!
+     */
     ASSERT(d->processor >=3D 0);
     ASSERT(d->processor < nr_cpu_ids);
     ASSERT(per_cpu(schedule_data, d->processor).curr);
@@ -1244,7 +1169,7 @@ static void sedf_dump_domain(struct vcpu
 }
=20

-/* dumps all domains on the specified cpu */
+/* Dumps all domains on the specified cpu */
 static void sedf_dump_cpu_state(const struct scheduler *ops, int i)
 {
     struct list_head      *list, *queue, *tmp;
@@ -1319,7 +1244,7 @@ static void sedf_dump_cpu_state(const st
 }
=20

-/* Adjusts periods and slices of the domains accordingly to their weights.=
 */
+/* Adjusts periods and slices of the domains accordingly to their weights =
*/
 static int sedf_adjust_weights(struct cpupool *c, struct xen_domctl_schedu=
ler_op *cmd)
 {
     struct vcpu *p;
@@ -1335,7 +1260,7 @@ static int sedf_adjust_weights(struct cp
         return -ENOMEM;
     }
=20
-    /* Sum across all weights. */
+    /* Sum across all weights */
     rcu_read_lock(&domlist_read_lock);
     for_each_domain_in_cpupool( d, c )
     {
@@ -1350,11 +1275,13 @@ static int sedf_adjust_weights(struct cp
             }
             else
             {
-                /*don't modify domains who don't have a weight, but sum
-                  up the time they need, projected to a WEIGHT_PERIOD,
-                  so that this time is not given to the weight-driven
-                  domains*/
-                /*check for overflows*/
+                /* Don't modify domains who don't have a weight, but sum
+                 * up the time they need, projected to a WEIGHT_PERIOD,
+                 * so that this time is not given to the weight-driven
+                 *  domains
+                 */
+
+                /* Check for overflows */
                 ASSERT((WEIGHT_PERIOD < ULONG_MAX)=20
                        && (EDOM_INFO(p)->slice_orig < ULONG_MAX));
                 sumt[cpu] +=3D=20
@@ -1365,7 +1292,7 @@ static int sedf_adjust_weights(struct cp
     }
     rcu_read_unlock(&domlist_read_lock);
=20
-    /* Adjust all slices (and periods) to the new weight. */
+    /* Adjust all slices (and periods) to the new weight */
     rcu_read_lock(&domlist_read_lock);
     for_each_domain_in_cpupool( d, c )
     {
@@ -1393,20 +1320,15 @@ static int sedf_adjust_weights(struct cp
 }
=20

-/* set or fetch domain scheduling parameters */
+/* Set or fetch domain scheduling parameters */
 static int sedf_adjust(const struct scheduler *ops, struct domain *p, stru=
ct xen_domctl_scheduler_op *op)
 {
     struct vcpu *v;
     int rc;
=20
-    PRINT(2,"sedf_adjust was called, domain-id %i new period %"PRIu64" "
-          "new slice %"PRIu64"\nlatency %"PRIu64" extra:%s\n",
-          p->domain_id, op->u.sedf.period, op->u.sedf.slice,
-          op->u.sedf.latency, (op->u.sedf.extratime)?"yes":"no");
-
     if ( op->cmd =3D=3D XEN_DOMCTL_SCHEDOP_putinfo )
     {
-        /* Check for sane parameters. */
+        /* Check for sane parameters */
         if ( !op->u.sedf.period && !op->u.sedf.weight )
             return -EINVAL;
         if ( op->u.sedf.weight )
@@ -1414,7 +1336,7 @@ static int sedf_adjust(const struct sche
             if ( (op->u.sedf.extratime & EXTRA_AWARE) &&
                  (!op->u.sedf.period) )
             {
-                /* Weight-driven domains with extratime only. */
+                /* Weight-driven domains with extratime only */
                 for_each_vcpu ( p, v )
                 {
                     EDOM_INFO(v)->extraweight =3D op->u.sedf.weight;
@@ -1425,7 +1347,7 @@ static int sedf_adjust(const struct sche
             }
             else
             {
-                /* Weight-driven domains with real-time execution. */
+                /* Weight-driven domains with real-time execution */
                 for_each_vcpu ( p, v )
                     EDOM_INFO(v)->weight =3D op->u.sedf.weight;
             }
@@ -1435,8 +1357,7 @@ static int sedf_adjust(const struct sche
             /* Time-driven domains. */
             for_each_vcpu ( p, v )
             {
-                /*
-                 * Sanity checking: note that disabling extra weight requi=
res
+                /* Sanity checking: note that disabling extra weight requi=
res
                  * that we set a non-zero slice.
                  */
                 if ( (op->u.sedf.period > PERIOD_MAX) ||
@@ -1477,7 +1398,6 @@ static int sedf_adjust(const struct sche
         op->u.sedf.weight    =3D EDOM_INFO(p->vcpu[0])->weight;
     }
=20
-    PRINT(2,"sedf_adjust_finished\n");
     return 0;
 }
=20

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-------------------------------------------------------------------
Dario Faggioli, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
PhD Candidate, ReTiS Lab, Scuola Superiore Sant'Anna, Pisa (Italy)





--=-SQC3wUYrGGqGq8T7E3BQ
Content-Disposition: attachment; filename="sedf-debug-cleanup.patch"
Content-Type: text/x-patch; name="sedf-debug-cleanup.patch"; charset="UTF-8"
Content-Transfer-Encoding: base64

IyBIRyBjaGFuZ2VzZXQgcGF0Y2gNCiMgUGFyZW50IDE3ZDk5NjkxZTBlYzFmYTdiYjcxY2YxOGMx
MmNhM2MwNDZjMGM4ZDcNCnNlZGY6IHJlbW92ZSB1c2VsZXNzIHRyYWNpbmcgcHJpbnRrIGFuZCBo
YXJtb25pemUgY29tbWVudHMgc3R5bGUuDQoNCnNjaGVkX3NlZGYuYyB1c2VkIG8gaGF2ZSBpdHMg
b3duIG1lY2hhbmlzbSBmb3IgcHJvZHVjaW5nIHRyYWNpbmctYWxpa2UNCmtpbmQgb2YgaW5mb3Jt
YXRpb24gKGRvbWFpbiBibG9jaywgd2FrZXVwLCBldGMuKS4gTm93YWRheXMsIHdpdGggYW4gZXZl
bg0Kbm90IHNvIGhpZ2ggbnVtYmVyIG9mIHBDUFVzL3ZDUFVzLCBqdXN0IHRyeWluZyB0byBlbmFi
bGUgdGhpcyBtYWtlcw0KdGhlIHNlcmlhbCBjb25zb2xlIGNvbXBsZXRlbHkgdW51c2FibGUsIHBy
b2R1Y2VzIHRvbnMgb2YgdmVyeSBoYXJkIHRvDQpwYXJzZSBhbmQgaW50ZXJwcmVldCBsb2dnaW5n
IGFuZCBjYW4gZWFzaWx5IGxpdmVsb2NrIERvbTAuIE1vcmVvdmVyLA0KcHJldHR5IG11Y2ggdGhl
IHNhbWUgcmVzdWx0IHRoaXMgaXMgc3RydWdnbGluZyB0byBnZXQgdG8sIGlzIGJldHRlcg0KYWNo
aWV2ZWQgYnkgZW5hYmxpbmcgdGhlIHNjaGVkdWxlci1yZWxhdGVkIHRyYWNpbmcgZXZlbnRzLCBh
cw0KaXQgaXMgZm9yIHRoZSBvdGhlciBzY2hlZHVsZXJzIChzYXksIGNyZWRpdCBvciBjcmVkaXQy
KS4NCg0KRm9yIGFsbCB0aGVzZSByZWFzb25zLCB0aGlzIHJlbW92ZXMgdGhhdCBtYWNoaW5lcnkg
Y29tcGxldGVseS4gV2hpbGUgYXQNCml0LCBjaGVjayBpbiBzb21lIGNvc21ldGljcyB0aGF0IGhh
cm1vbml6ZSB0aGUgY29tbWVudHMgd2l0aGltIHRoZW1zZWxmDQphbmQgd2l0aCB0aGUgcmVzdCBv
ZiB0aGUgY29kZSBiYXNlLg0KDQpTaWduZWQtb2ZmLWJ5OiBEYXJpbyBGYWdnaW9saSA8ZGFyaW8u
ZmFnZ2lvbGlAY2l0cml4LmNvbT4NCg0KZGlmZiAtciAxN2Q5OTY5MWUwZWMgeGVuL2NvbW1vbi9z
Y2hlZF9zZWRmLmMNCi0tLSBhL3hlbi9jb21tb24vc2NoZWRfc2VkZi5jCVR1ZSBEZWMgMjAgMTY6
Mzk6NTYgMjAxMSArMDAwMA0KKysrIGIveGVuL2NvbW1vbi9zY2hlZF9zZWRmLmMJVHVlIERlYyAy
MCAxNzozMjo1MiAyMDExICswMDAwDQpAQCAtMTMsMTQgKzEzLDYgQEANCiAjaW5jbHVkZSA8eGVu
L3RpbWUuaD4NCiAjaW5jbHVkZSA8eGVuL2Vycm5vLmg+DQogDQotLyp2ZXJib3NpdHkgc2V0dGlu
Z3MqLw0KLSNkZWZpbmUgU0VERkxFVkVMIDANCi0jZGVmaW5lIFBSSU5UKF9mLCBfYS4uLikgICAg
ICAgICAgICAgICAgICAgICAgICBcDQotICAgIGRvIHsgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgXA0KLSAgICAgICAgaWYgKCAoX2YpIDw9IFNFREZMRVZFTCApICAgICAg
ICAgICAgICAgIFwNCi0gICAgICAgICAgICBwcmludGsoX2EgKTsgICAgICAgICAgICAgICAgICAg
ICAgICBcDQotICAgIH0gd2hpbGUgKCAwICkNCi0NCiAjZGVmaW5lIFNFREZfQ1BVT05MSU5FKF9w
b29sKSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFwNCiAgICAg
KCgoX3Bvb2wpID09IE5VTEwpID8gJmNwdXBvb2xfZnJlZV9jcHVzIDogKF9wb29sKS0+Y3B1X3Zh
bGlkKQ0KIA0KQEAgLTY2LDM0ICs1OCwzNSBAQCBzdHJ1Y3Qgc2VkZl92Y3B1X2luZm8gew0KICAg
ICBzdHJ1Y3QgbGlzdF9oZWFkIGxpc3Q7DQogICAgIHN0cnVjdCBsaXN0X2hlYWQgZXh0cmFsaXN0
WzJdOw0KICANCi0gICAgLypQYXJhbWV0ZXJzIGZvciBFREYqLw0KLSAgICBzX3RpbWVfdCAgcGVy
aW9kOyAgLyo9KHJlbGF0aXZlIGRlYWRsaW5lKSovDQotICAgIHNfdGltZV90ICBzbGljZTsgIC8q
PXdvcnN0IGNhc2UgZXhlY3V0aW9uIHRpbWUqLw0KKyAgICAvKiBQYXJhbWV0ZXJzIGZvciBFREYg
Ki8NCisgICAgc190aW1lX3QgIHBlcmlvZDsgIC8qID0ocmVsYXRpdmUgZGVhZGxpbmUpICovDQor
ICAgIHNfdGltZV90ICBzbGljZTsgICAvKiA9d29yc3QgY2FzZSBleGVjdXRpb24gdGltZSAqLw0K
ICANCi0gICAgLypBZHZhY2VkIFBhcmFtZXRlcnMqLw0KLSAgICAvKkxhdGVuY3kgU2NhbGluZyov
DQorICAgIC8qIEFkdmFjZWQgUGFyYW1ldGVycyAqLw0KKw0KKyAgICAvKiBMYXRlbmN5IFNjYWxp
bmcgKi8NCiAgICAgc190aW1lX3QgIHBlcmlvZF9vcmlnOw0KICAgICBzX3RpbWVfdCAgc2xpY2Vf
b3JpZzsNCiAgICAgc190aW1lX3QgIGxhdGVuY3k7DQogIA0KLSAgICAvKnN0YXR1cyBvZiBkb21h
aW4qLw0KKyAgICAvKiBTdGF0dXMgb2YgZG9tYWluICovDQogICAgIGludCAgICAgICBzdGF0dXM7
DQotICAgIC8qd2VpZ2h0cyBmb3IgIlNjaGVkdWxpbmcgZm9yIGJlZ2lubmVycy8gbGF6eS8gZXRj
LiIgOykqLw0KKyAgICAvKiBXZWlnaHRzIGZvciAiU2NoZWR1bGluZyBmb3IgYmVnaW5uZXJzLyBs
YXp5LyBldGMuIiA7KSAqLw0KICAgICBzaG9ydCAgICAgd2VpZ2h0Ow0KICAgICBzaG9ydCAgICAg
ZXh0cmF3ZWlnaHQ7DQotICAgIC8qQm9va2tlZXBpbmcqLw0KKyAgICAvKiBCb29ra2VlcGluZyAq
Lw0KICAgICBzX3RpbWVfdCAgZGVhZGxfYWJzOw0KICAgICBzX3RpbWVfdCAgc2NoZWRfc3RhcnRf
YWJzOw0KICAgICBzX3RpbWVfdCAgY3B1dGltZTsNCi0gICAgLyogdGltZXMgdGhlIGRvbWFpbiB1
bi0vYmxvY2tlZCAqLw0KKyAgICAvKiBUaW1lcyB0aGUgZG9tYWluIHVuLS9ibG9ja2VkICovDQog
ICAgIHNfdGltZV90ICBibG9ja19hYnM7DQogICAgIHNfdGltZV90ICB1bmJsb2NrX2FiczsNCiAg
DQotICAgIC8qc2NvcmVzIGZvciB7dXRpbCwgYmxvY2sgcGVuYWx0eX0td2VpZ2h0ZWQgZXh0cmF0
aW1lIGRpc3RyaWJ1dGlvbiovDQorICAgIC8qIFNjb3JlcyBmb3Ige3V0aWwsIGJsb2NrIHBlbmFs
dHl9LXdlaWdodGVkIGV4dHJhdGltZSBkaXN0cmlidXRpb24gKi8NCiAgICAgaW50ICAgc2NvcmVb
Ml07DQogICAgIHNfdGltZV90ICBzaG9ydF9ibG9ja19sb3N0X3RvdDsNCiAgDQotICAgIC8qU3Rh
dGlzdGljcyovDQorICAgIC8qIFN0YXRpc3RpY3MgKi8NCiAgICAgc190aW1lX3QgIGV4dHJhX3Rp
bWVfdG90Ow0KIA0KICNpZmRlZiBTRURGX1NUQVRTDQpAQCAtMTU4LDE4ICsxNTEsMTYgQEAgc3Rh
dGljIGlubGluZSB2b2lkIGV4dHJhcV9kZWwoc3RydWN0IHZjcA0KIHsNCiAgICAgc3RydWN0IGxp
c3RfaGVhZCAqbGlzdCA9IEVYVFJBTElTVChkLGkpOw0KICAgICBBU1NFUlQoZXh0cmFxX29uKGQs
aSkpOw0KLSAgICBQUklOVCgzLCAiUmVtb3ZpbmcgZG9tYWluICVpLiVpIGZyb20gTCVpIGV4dHJh
cVxuIiwNCi0gICAgICAgICAgZC0+ZG9tYWluLT5kb21haW5faWQsIGQtPnZjcHVfaWQsIGkpOw0K
ICAgICBsaXN0X2RlbChsaXN0KTsNCiAgICAgbGlzdC0+bmV4dCA9IE5VTEw7DQogICAgIEFTU0VS
VCghZXh0cmFxX29uKGQsIGkpKTsNCiB9DQogDQotLyogYWRkcyBhIGRvbWFpbiB0byB0aGUgcXVl
dWUgb2YgcHJvY2Vzc2VzIHdoaWNoIGFyZSBhd2FyZSBvZiBleHRyYSB0aW1lLiBMaXN0DQotICAg
aXMgc29ydGVkIGJ5IHNjb3JlLCB3aGVyZSBhIGxvd2VyIHNjb3JlIG1lYW5zIGhpZ2hlciBwcmlv
cml0eSBmb3IgYW4gZXh0cmENCi0gICBzbGljZS4gSXQgYWxzbyB1cGRhdGVzIHRoZSBzY29yZSwg
Ynkgc2ltcGx5IHN1YnRyYWN0aW5nIGEgZml4ZWQgdmFsdWUgZnJvbQ0KLSAgIGVhY2ggZW50cnks
IGluIG9yZGVyIHRvIGF2b2lkIG92ZXJmbG93LiBUaGUgYWxnb3JpdGhtIHdvcmtzIGJ5IHNpbXBs
eQ0KLSAgIGNoYXJnaW5nIGVhY2ggZG9tYWluIHRoYXQgcmVjaWV2ZWQgZXh0cmF0aW1lIHdpdGgg
YW4gaW52ZXJzZSBvZiBpdHMgd2VpZ2h0Lg0KKy8qIEFkZHMgYSBkb21haW4gdG8gdGhlIHF1ZXVl
IG9mIHByb2Nlc3NlcyB3aGljaCBhcmUgYXdhcmUgb2YgZXh0cmEgdGltZS4gTGlzdA0KKyAqIGlz
IHNvcnRlZCBieSBzY29yZSwgd2hlcmUgYSBsb3dlciBzY29yZSBtZWFucyBoaWdoZXIgcHJpb3Jp
dHkgZm9yIGFuIGV4dHJhDQorICogc2xpY2UuIEl0IGFsc28gdXBkYXRlcyB0aGUgc2NvcmUsIGJ5
IHNpbXBseSBzdWJ0cmFjdGluZyBhIGZpeGVkIHZhbHVlIGZyb20NCisgKiBlYWNoIGVudHJ5LCBp
biBvcmRlciB0byBhdm9pZCBvdmVyZmxvdy4gVGhlIGFsZ29yaXRobSB3b3JrcyBieSBzaW1wbHkN
CisgKiBjaGFyZ2luZyBlYWNoIGRvbWFpbiB0aGF0IHJlY2lldmVkIGV4dHJhdGltZSB3aXRoIGFu
IGludmVyc2Ugb2YgaXRzIHdlaWdodC4NCiAgKi8gDQogc3RhdGljIGlubGluZSB2b2lkIGV4dHJh
cV9hZGRfc29ydF91cGRhdGUoc3RydWN0IHZjcHUgKmQsIGludCBpLCBpbnQgc3ViKQ0KIHsNCkBA
IC0xNzgsMTMgKzE2OSw3IEBAIHN0YXRpYyBpbmxpbmUgdm9pZCBleHRyYXFfYWRkX3NvcnRfdXBk
YXQNCiAgDQogICAgIEFTU0VSVCghZXh0cmFxX29uKGQsaSkpOw0KIA0KLSAgICBQUklOVCgzLCAi
QWRkaW5nIGRvbWFpbiAlaS4laSAoc2NvcmU9ICVpLCBzaG9ydF9wZW49ICUiUFJJaTY0IikiDQot
ICAgICAgICAgICIgdG8gTCVpIGV4dHJhcVxuIiwNCi0gICAgICAgICAgZC0+ZG9tYWluLT5kb21h
aW5faWQsIGQtPnZjcHVfaWQsIEVET01fSU5GTyhkKS0+c2NvcmVbaV0sDQotICAgICAgICAgIEVE
T01fSU5GTyhkKS0+c2hvcnRfYmxvY2tfbG9zdF90b3QsIGkpOw0KLQ0KLSAgICAvKg0KLSAgICAg
KiBJdGVyYXRlIHRocm91Z2ggYWxsIGVsZW1lbnRzIHRvIGZpbmQgb3VyICJob2xlIiBhbmQgb24g
b3VyIHdheQ0KKyAgICAvKiBJdGVyYXRlIHRocm91Z2ggYWxsIGVsZW1lbnRzIHRvIGZpbmQgb3Vy
ICJob2xlIiBhbmQgb24gb3VyIHdheQ0KICAgICAgKiB1cGRhdGUgYWxsIHRoZSBvdGhlciBzY29y
ZXMuDQogICAgICAqLw0KICAgICBsaXN0X2Zvcl9lYWNoICggY3VyLCBFWFRSQVEoZC0+cHJvY2Vz
c29yLCBpKSApDQpAQCAtMTkzLDI1ICsxNzgsMTggQEAgc3RhdGljIGlubGluZSB2b2lkIGV4dHJh
cV9hZGRfc29ydF91cGRhdA0KICAgICAgICAgY3VyaW5mLT5zY29yZVtpXSAtPSBzdWI7DQogICAg
ICAgICBpZiAoIEVET01fSU5GTyhkKS0+c2NvcmVbaV0gPCBjdXJpbmYtPnNjb3JlW2ldICkNCiAg
ICAgICAgICAgICBicmVhazsNCi0gICAgICAgIFBSSU5UKDQsIlx0YmVoaW5kIGRvbWFpbiAlaS4l
aSAoc2NvcmU9ICVpKVxuIiwNCi0gICAgICAgICAgICAgIGN1cmluZi0+dmNwdS0+ZG9tYWluLT5k
b21haW5faWQsDQotICAgICAgICAgICAgICBjdXJpbmYtPnZjcHUtPnZjcHVfaWQsIGN1cmluZi0+
c2NvcmVbaV0pOw0KICAgICB9DQogDQotICAgIC8qIGN1ciBub3cgY29udGFpbnMgdGhlIGVsZW1l
bnQsIGJlZm9yZSB3aGljaCB3ZSdsbCBlbnF1ZXVlLiAqLw0KLSAgICBQUklOVCgzLCAiXHRsaXN0
X2FkZCB0byAlcFxuIiwgY3VyLT5wcmV2KTsNCisgICAgLyogY3VyIG5vdyBjb250YWlucyB0aGUg
ZWxlbWVudCwgYmVmb3JlIHdoaWNoIHdlJ2xsIGVucXVldWUgKi8NCiAgICAgbGlzdF9hZGQoRVhU
UkFMSVNUKGQsaSksY3VyLT5wcmV2KTsNCiAgDQotICAgIC8qIENvbnRpbnVlIHVwZGF0aW5nIHRo
ZSBleHRyYXEuICovDQorICAgIC8qIENvbnRpbnVlIHVwZGF0aW5nIHRoZSBleHRyYXEgKi8NCiAg
ICAgaWYgKCAoY3VyICE9IEVYVFJBUShkLT5wcm9jZXNzb3IsaSkpICYmIHN1YiApDQogICAgIHsN
CiAgICAgICAgIGZvciAoIGN1ciA9IGN1ci0+bmV4dDsgY3VyICE9IEVYVFJBUShkLT5wcm9jZXNz
b3IsaSk7IGN1ciA9IGN1ci0+bmV4dCApDQogICAgICAgICB7DQogICAgICAgICAgICAgY3VyaW5m
ID0gbGlzdF9lbnRyeShjdXIsc3RydWN0IHNlZGZfdmNwdV9pbmZvLCBleHRyYWxpc3RbaV0pOw0K
ICAgICAgICAgICAgIGN1cmluZi0+c2NvcmVbaV0gLT0gc3ViOw0KLSAgICAgICAgICAgIFBSSU5U
KDQsICJcdHVwZGF0aW5nIGRvbWFpbiAlaS4laSAoc2NvcmU9ICV1KVxuIiwNCi0gICAgICAgICAg
ICAgICAgICBjdXJpbmYtPnZjcHUtPmRvbWFpbi0+ZG9tYWluX2lkLCANCi0gICAgICAgICAgICAg
ICAgICBjdXJpbmYtPnZjcHUtPnZjcHVfaWQsIGN1cmluZi0+c2NvcmVbaV0pOw0KICAgICAgICAg
fQ0KICAgICB9DQogDQpAQCAtMjIxLDI5ICsxOTksMTQgQEAgc3RhdGljIGlubGluZSB2b2lkIGV4
dHJhcV9jaGVjayhzdHJ1Y3Qgdg0KIHsNCiAgICAgaWYgKCBleHRyYXFfb24oZCwgRVhUUkFfVVRJ
TF9RKSApDQogICAgIHsNCi0gICAgICAgIFBSSU5UKDIsIkRvbSAlaS4laSBpcyBvbiBMMSBleHRy
YVFcbiIsDQotICAgICAgICAgICAgICBkLT5kb21haW4tPmRvbWFpbl9pZCwgZC0+dmNwdV9pZCk7
DQotDQogICAgICAgICBpZiAoICEoRURPTV9JTkZPKGQpLT5zdGF0dXMgJiBFWFRSQV9BV0FSRSkg
JiYNCiAgICAgICAgICAgICAgIWV4dHJhX3J1bnMoRURPTV9JTkZPKGQpKSApDQotICAgICAgICB7
DQogICAgICAgICAgICAgZXh0cmFxX2RlbChkLCBFWFRSQV9VVElMX1EpOw0KLSAgICAgICAgICAg
IFBSSU5UKDIsIlJlbW92ZWQgZG9tICVpLiVpIGZyb20gTDEgZXh0cmFRXG4iLA0KLSAgICAgICAg
ICAgICAgICAgIGQtPmRvbWFpbi0+ZG9tYWluX2lkLCBkLT52Y3B1X2lkKTsNCi0gICAgICAgIH0N
CiAgICAgfQ0KICAgICBlbHNlDQogICAgIHsNCi0gICAgICAgIFBSSU5UKDIsICJEb20gJWkuJWkg
aXMgTk9UIG9uIEwxIGV4dHJhUVxuIiwNCi0gICAgICAgICAgICAgIGQtPmRvbWFpbi0+ZG9tYWlu
X2lkLA0KLSAgICAgICAgICAgICAgZC0+dmNwdV9pZCk7DQotDQogICAgICAgICBpZiAoIChFRE9N
X0lORk8oZCktPnN0YXR1cyAmIEVYVFJBX0FXQVJFKSAmJiBzZWRmX3J1bm5hYmxlKGQpICkNCi0g
ICAgICAgIHsNCiAgICAgICAgICAgICBleHRyYXFfYWRkX3NvcnRfdXBkYXRlKGQsIEVYVFJBX1VU
SUxfUSwgMCk7DQotICAgICAgICAgICAgUFJJTlQoMiwiQWRkZWQgZG9tICVpLiVpIHRvIEwxIGV4
dHJhUVxuIiwNCi0gICAgICAgICAgICAgICAgICBkLT5kb21haW4tPmRvbWFpbl9pZCwgZC0+dmNw
dV9pZCk7DQotICAgICAgICB9DQogICAgIH0NCiB9DQogDQpAQCAtMjUyLDcgKzIxNSw3IEBAIHN0
YXRpYyBpbmxpbmUgdm9pZCBleHRyYXFfY2hlY2tfYWRkX3VuYmwNCiAgICAgc3RydWN0IHNlZGZf
dmNwdV9pbmZvICppbmYgPSBFRE9NX0lORk8oZCk7DQogDQogICAgIGlmICggaW5mLT5zdGF0dXMg
JiBFWFRSQV9BV0FSRSApDQotICAgICAgICAvKiBQdXQgb24gdGhlIHdlaWdodGVkIGV4dHJhcSB3
aXRob3V0IHVwZGF0aW5nIGFueSBzY29yZXMuICovDQorICAgICAgICAvKiBQdXQgb24gdGhlIHdl
aWdodGVkIGV4dHJhcSB3aXRob3V0IHVwZGF0aW5nIGFueSBzY29yZXMgKi8NCiAgICAgICAgIGV4
dHJhcV9hZGRfc29ydF91cGRhdGUoZCwgRVhUUkFfVVRJTF9RLCAwKTsNCiB9DQogDQpAQCAtMjY1
LDggKzIyOCw2IEBAIHN0YXRpYyBpbmxpbmUgdm9pZCBfX2RlbF9mcm9tX3F1ZXVlKHN0cnUNCiB7
DQogICAgIHN0cnVjdCBsaXN0X2hlYWQgKmxpc3QgPSBMSVNUKGQpOw0KICAgICBBU1NFUlQoX190
YXNrX29uX3F1ZXVlKGQpKTsNCi0gICAgUFJJTlQoMywiUmVtb3ZpbmcgZG9tYWluICVpLiVpIChi
b3A9ICUiUFJJdTY0IikgZnJvbSBydW5xL3dhaXRxXG4iLA0KLSAgICAgICAgICBkLT5kb21haW4t
PmRvbWFpbl9pZCwgZC0+dmNwdV9pZCwgUEVSSU9EX0JFR0lOKEVET01fSU5GTyhkKSkpOw0KICAg
ICBsaXN0X2RlbChsaXN0KTsNCiAgICAgbGlzdC0+bmV4dCA9IE5VTEw7DQogICAgIEFTU0VSVCgh
X190YXNrX29uX3F1ZXVlKGQpKTsNCkBAIC0yNzksMTMgKzI0MCwxMiBAQCBzdGF0aWMgaW5saW5l
IHZvaWQgbGlzdF9pbnNlcnRfc29ydCgNCiB7DQogICAgIHN0cnVjdCBsaXN0X2hlYWQgICAgICpj
dXI7DQogDQotICAgIC8qIEl0ZXJhdGUgdGhyb3VnaCBhbGwgZWxlbWVudHMgdG8gZmluZCBvdXIg
ImhvbGUiLiAqLw0KKyAgICAvKiBJdGVyYXRlIHRocm91Z2ggYWxsIGVsZW1lbnRzIHRvIGZpbmQg
b3VyICJob2xlIiAqLw0KICAgICBsaXN0X2Zvcl9lYWNoKCBjdXIsIGxpc3QgKQ0KICAgICAgICAg
aWYgKCBjb21wKGVsZW1lbnQsIGN1cikgPCAwICkNCiAgICAgICAgICAgICBicmVhazsNCiANCi0g
ICAgLyogY3VyIG5vdyBjb250YWlucyB0aGUgZWxlbWVudCwgYmVmb3JlIHdoaWNoIHdlJ2xsIGVu
cXVldWUuICovDQotICAgIFBSSU5UKDMsIlx0bGlzdF9hZGQgdG8gJXBcbiIsY3VyLT5wcmV2KTsN
CisgICAgLyogY3VyIG5vdyBjb250YWlucyB0aGUgZWxlbWVudCwgYmVmb3JlIHdoaWNoIHdlJ2xs
IGVucXVldWUgKi8NCiAgICAgbGlzdF9hZGQoZWxlbWVudCwgY3VyLT5wcmV2KTsNCiB9DQogDQpA
QCAtMzAzLDMwICsyNjMsMjYgQEAgc3RhdGljIGludCBuYW1lIyNfY29tcChzdHJ1Y3QgbGlzdF9o
ZWFkKg0KICAgICAgICAgcmV0dXJuIDE7ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIFwNCiB9DQogDQotLyogYWRkcyBhIGRvbWFpbiB0byB0aGUg
cXVldWUgb2YgcHJvY2Vzc2VzIHdoaWNoIHdhaXQgZm9yIHRoZSBiZWdpbm5pbmcgb2YgdGhlDQot
ICAgbmV4dCBwZXJpb2Q7IHRoaXMgbGlzdCBpcyB0aGVyZWZvcmUgc29ydGV0IGJ5IHRoaXMgdGlt
ZSwgd2hpY2ggaXMgc2ltcGx5DQotICAgYWJzb2wuIGRlYWRsaW5lIC0gcGVyaW9kDQorLyogQWRk
cyBhIGRvbWFpbiB0byB0aGUgcXVldWUgb2YgcHJvY2Vzc2VzIHdoaWNoIHdhaXQgZm9yIHRoZSBi
ZWdpbm5pbmcgb2YgdGhlDQorICogbmV4dCBwZXJpb2Q7IHRoaXMgbGlzdCBpcyB0aGVyZWZvcmUg
c29ydGV0IGJ5IHRoaXMgdGltZSwgd2hpY2ggaXMgc2ltcGx5DQorICogYWJzb2wuIGRlYWRsaW5l
IC0gcGVyaW9kLg0KICAqLyANCiBET01BSU5fQ09NUEFSRVIod2FpdHEsIGxpc3QsIFBFUklPRF9C
RUdJTihkMSksIFBFUklPRF9CRUdJTihkMikpOw0KIHN0YXRpYyBpbmxpbmUgdm9pZCBfX2FkZF90
b193YWl0cXVldWVfc29ydChzdHJ1Y3QgdmNwdSAqdikNCiB7DQogICAgIEFTU0VSVCghX190YXNr
X29uX3F1ZXVlKHYpKTsNCi0gICAgUFJJTlQoMywiQWRkaW5nIGRvbWFpbiAlaS4laSAoYm9wPSAl
IlBSSXU2NCIpIHRvIHdhaXRxXG4iLA0KLSAgICAgICAgICB2LT5kb21haW4tPmRvbWFpbl9pZCwg
di0+dmNwdV9pZCwgUEVSSU9EX0JFR0lOKEVET01fSU5GTyh2KSkpOw0KICAgICBsaXN0X2luc2Vy
dF9zb3J0KFdBSVRRKHYtPnByb2Nlc3NvciksIExJU1QodiksIHdhaXRxX2NvbXApOw0KICAgICBB
U1NFUlQoX190YXNrX29uX3F1ZXVlKHYpKTsNCiB9DQogDQotLyogYWRkcyBhIGRvbWFpbiB0byB0
aGUgcXVldWUgb2YgcHJvY2Vzc2VzIHdoaWNoIGhhdmUgc3RhcnRlZCB0aGVpciBjdXJyZW50DQot
ICAgcGVyaW9kIGFuZCBhcmUgcnVubmFibGUgKGkuZS4gbm90IGJsb2NrZWQsIGRpZWluZywuLi4p
LiBUaGUgZmlyc3QgZWxlbWVudA0KLSAgIG9uIHRoaXMgbGlzdCBpcyBydW5uaW5nIG9uIHRoZSBw
cm9jZXNzb3IsIGlmIHRoZSBsaXN0IGlzIGVtcHR5IHRoZSBpZGxlDQotICAgdGFzayB3aWxsIHJ1
bi4gQXMgd2UgYXJlIGltcGxlbWVudGluZyBFREYsIHRoaXMgbGlzdCBpcyBzb3J0ZWQgYnkgZGVh
ZGxpbmVzLg0KKy8qIEFkZHMgYSBkb21haW4gdG8gdGhlIHF1ZXVlIG9mIHByb2Nlc3NlcyB3aGlj
aCBoYXZlIHN0YXJ0ZWQgdGhlaXIgY3VycmVudA0KKyAqIHBlcmlvZCBhbmQgYXJlIHJ1bm5hYmxl
IChpLmUuIG5vdCBibG9ja2VkLCBkaWVpbmcsLi4uKS4gVGhlIGZpcnN0IGVsZW1lbnQNCisgKiBv
biB0aGlzIGxpc3QgaXMgcnVubmluZyBvbiB0aGUgcHJvY2Vzc29yLCBpZiB0aGUgbGlzdCBpcyBl
bXB0eSB0aGUgaWRsZQ0KKyAqIHRhc2sgd2lsbCBydW4uIEFzIHdlIGFyZSBpbXBsZW1lbnRpbmcg
RURGLCB0aGlzIGxpc3QgaXMgc29ydGVkIGJ5IGRlYWRsaW5lcy4NCiAgKi8gDQogRE9NQUlOX0NP
TVBBUkVSKHJ1bnEsIGxpc3QsIGQxLT5kZWFkbF9hYnMsIGQyLT5kZWFkbF9hYnMpOw0KIHN0YXRp
YyBpbmxpbmUgdm9pZCBfX2FkZF90b19ydW5xdWV1ZV9zb3J0KHN0cnVjdCB2Y3B1ICp2KQ0KIHsN
Ci0gICAgUFJJTlQoMywiQWRkaW5nIGRvbWFpbiAlaS4laSAoZGVhZGw9ICUiUFJJdTY0IikgdG8g
cnVucVxuIiwNCi0gICAgICAgICAgdi0+ZG9tYWluLT5kb21haW5faWQsIHYtPnZjcHVfaWQsIEVE
T01fSU5GTyh2KS0+ZGVhZGxfYWJzKTsNCiAgICAgbGlzdF9pbnNlcnRfc29ydChSVU5RKHYtPnBy
b2Nlc3NvciksIExJU1QodiksIHJ1bnFfY29tcCk7DQogfQ0KIA0KQEAgLTQ0NSwyMiArNDAxLDIx
IEBAIHN0YXRpYyBpbnQgc2VkZl9waWNrX2NwdShjb25zdCBzdHJ1Y3Qgc2MNCiAgICAgcmV0dXJu
IGNwdW1hc2tfZmlyc3QoJm9ubGluZV9hZmZpbml0eSk7DQogfQ0KIA0KLS8qDQotICogSGFuZGxl
cyB0aGUgcmVzY2hlZHVsaW5nICYgYm9va2tlZXBpbmcgb2YgZG9tYWlucyBydW5uaW5nIGluIHRo
ZWlyDQorDQorLyogSGFuZGxlcyB0aGUgcmVzY2hlZHVsaW5nICYgYm9va2tlZXBpbmcgb2YgZG9t
YWlucyBydW5uaW5nIGluIHRoZWlyDQogICogZ3VhcmFudGVlZCB0aW1lc2xpY2UuDQogICovDQog
c3RhdGljIHZvaWQgZGVzY2hlZF9lZGZfZG9tKHNfdGltZV90IG5vdywgc3RydWN0IHZjcHUqIGQp
DQogew0KICAgICBzdHJ1Y3Qgc2VkZl92Y3B1X2luZm8qIGluZiA9IEVET01fSU5GTyhkKTsNCiAN
Ci0gICAgLyogQ3VycmVudCBkb21haW4gaXMgcnVubmluZyBpbiByZWFsIHRpbWUgbW9kZS4gKi8N
CisgICAgLyogQ3VycmVudCBkb21haW4gaXMgcnVubmluZyBpbiByZWFsIHRpbWUgbW9kZSAqLw0K
ICAgICBBU1NFUlQoX190YXNrX29uX3F1ZXVlKGQpKTsNCiANCi0gICAgLyogVXBkYXRlIHRoZSBk
b21haW4ncyBjcHV0aW1lLiAqLw0KKyAgICAvKiBVcGRhdGUgdGhlIGRvbWFpbidzIGNwdXRpbWUg
Ki8NCiAgICAgaW5mLT5jcHV0aW1lICs9IG5vdyAtIGluZi0+c2NoZWRfc3RhcnRfYWJzOw0KIA0K
LSAgICAvKg0KLSAgICAgKiBTY2hlZHVsaW5nIGRlY2lzaW9ucyB3aGljaCBkb24ndCByZW1vdmUg
dGhlIHJ1bm5pbmcgZG9tYWluIGZyb20gdGhlDQorICAgIC8qIFNjaGVkdWxpbmcgZGVjaXNpb25z
IHdoaWNoIGRvbid0IHJlbW92ZSB0aGUgcnVubmluZyBkb21haW4gZnJvbSB0aGUNCiAgICAgICog
cnVucS4gDQogICAgICAqLw0KICAgICBpZiAoIChpbmYtPmNwdXRpbWUgPCBpbmYtPnNsaWNlKSAm
JiBzZWRmX3J1bm5hYmxlKGQpICkNCkBAIC00NjgsOCArNDIzLDcgQEAgc3RhdGljIHZvaWQgZGVz
Y2hlZF9lZGZfZG9tKHNfdGltZV90IG5vdw0KICAgDQogICAgIF9fZGVsX2Zyb21fcXVldWUoZCk7
DQogICANCi0gICAgLyoNCi0gICAgICogTWFuYWdlIGJvb2trZWVwaW5nIChpLmUuIGNhbGN1bGF0
ZSBuZXh0IGRlYWRsaW5lLCBtZW1vcmlzZQ0KKyAgICAvKiBNYW5hZ2UgYm9va2tlZXBpbmcgKGku
ZS4gY2FsY3VsYXRlIG5leHQgZGVhZGxpbmUsIG1lbW9yaXNlDQogICAgICAqIG92ZXJydW4tdGlt
ZSBvZiBzbGljZSkgb2YgZmluaXNoZWQgZG9tYWlucy4NCiAgICAgICovDQogICAgIGlmICggaW5m
LT5jcHV0aW1lID49IGluZi0+c2xpY2UgKQ0KQEAgLTQ3OCwzMCArNDMyLDMwIEBAIHN0YXRpYyB2
b2lkIGRlc2NoZWRfZWRmX2RvbShzX3RpbWVfdCBub3cNCiAgIA0KICAgICAgICAgaWYgKCBpbmYt
PnBlcmlvZCA8IGluZi0+cGVyaW9kX29yaWcgKQ0KICAgICAgICAgew0KLSAgICAgICAgICAgIC8q
IFRoaXMgZG9tYWluIHJ1bnMgaW4gbGF0ZW5jeSBzY2FsaW5nIG9yIGJ1cnN0IG1vZGUuICovDQor
ICAgICAgICAgICAgLyogVGhpcyBkb21haW4gcnVucyBpbiBsYXRlbmN5IHNjYWxpbmcgb3IgYnVy
c3QgbW9kZSAqLw0KICAgICAgICAgICAgIGluZi0+cGVyaW9kICo9IDI7DQogICAgICAgICAgICAg
aW5mLT5zbGljZSAgKj0gMjsNCiAgICAgICAgICAgICBpZiAoIChpbmYtPnBlcmlvZCA+IGluZi0+
cGVyaW9kX29yaWcpIHx8DQogICAgICAgICAgICAgICAgICAoaW5mLT5zbGljZSA+IGluZi0+c2xp
Y2Vfb3JpZykgKQ0KICAgICAgICAgICAgIHsNCi0gICAgICAgICAgICAgICAgLyogUmVzZXQgc2xp
Y2UgYW5kIHBlcmlvZC4gKi8NCisgICAgICAgICAgICAgICAgLyogUmVzZXQgc2xpY2UgYW5kIHBl
cmlvZCAqLw0KICAgICAgICAgICAgICAgICBpbmYtPnBlcmlvZCA9IGluZi0+cGVyaW9kX29yaWc7
DQogICAgICAgICAgICAgICAgIGluZi0+c2xpY2UgPSBpbmYtPnNsaWNlX29yaWc7DQogICAgICAg
ICAgICAgfQ0KICAgICAgICAgfQ0KIA0KLSAgICAgICAgLyogU2V0IG5leHQgZGVhZGxpbmUuICov
DQorICAgICAgICAvKiBTZXQgbmV4dCBkZWFkbGluZSAqLw0KICAgICAgICAgaW5mLT5kZWFkbF9h
YnMgKz0gaW5mLT5wZXJpb2Q7DQogICAgIH0NCiAgDQotICAgIC8qIEFkZCBhIHJ1bm5hYmxlIGRv
bWFpbiB0byB0aGUgd2FpdHF1ZXVlLiAqLw0KKyAgICAvKiBBZGQgYSBydW5uYWJsZSBkb21haW4g
dG8gdGhlIHdhaXRxdWV1ZSAqLw0KICAgICBpZiAoIHNlZGZfcnVubmFibGUoZCkgKQ0KICAgICB7
DQogICAgICAgICBfX2FkZF90b193YWl0cXVldWVfc29ydChkKTsNCiAgICAgfQ0KICAgICBlbHNl
DQogICAgIHsNCi0gICAgICAgIC8qIFdlIGhhdmUgYSBibG9ja2VkIHJlYWx0aW1lIHRhc2sgLT4g
cmVtb3ZlIGl0IGZyb20gZXhxcyB0b28uICovDQorICAgICAgICAvKiBXZSBoYXZlIGEgYmxvY2tl
ZCByZWFsdGltZSB0YXNrIC0+IHJlbW92ZSBpdCBmcm9tIGV4cXMgdG9vICovDQogICAgICAgICBp
ZiAoIGV4dHJhcV9vbihkLCBFWFRSQV9QRU5fUSkgKQ0KICAgICAgICAgICAgIGV4dHJhcV9kZWwo
ZCwgRVhUUkFfUEVOX1EpOw0KICAgICAgICAgaWYgKCBleHRyYXFfb24oZCwgRVhUUkFfVVRJTF9R
KSApDQpAQCAtNTIxLDczICs0NzUsNTkgQEAgc3RhdGljIHZvaWQgdXBkYXRlX3F1ZXVlcygNCiAg
ICAgc3RydWN0IGxpc3RfaGVhZCAgICAgKmN1ciwgKnRtcDsNCiAgICAgc3RydWN0IHNlZGZfdmNw
dV9pbmZvICpjdXJpbmY7DQogIA0KLSAgICBQUklOVCgzLCJVcGRhdGluZyB3YWl0cS4uXG4iKTsN
Ci0NCi0gICAgLyoNCi0gICAgICogQ2hlY2sgZm9yIHRoZSBmaXJzdCBlbGVtZW50cyBvZiB0aGUg
d2FpdHF1ZXVlLCB3aGV0aGVyIHRoZWlyDQorICAgIC8qIENoZWNrIGZvciB0aGUgZmlyc3QgZWxl
bWVudHMgb2YgdGhlIHdhaXRxdWV1ZSwgd2hldGhlciB0aGVpcg0KICAgICAgKiBuZXh0IHBlcmlv
ZCBoYXMgYWxyZWFkeSBzdGFydGVkLg0KICAgICAgKi8NCiAgICAgbGlzdF9mb3JfZWFjaF9zYWZl
ICggY3VyLCB0bXAsIHdhaXRxICkNCiAgICAgew0KICAgICAgICAgY3VyaW5mID0gbGlzdF9lbnRy
eShjdXIsIHN0cnVjdCBzZWRmX3ZjcHVfaW5mbywgbGlzdCk7DQotICAgICAgICBQUklOVCg0LCJc
dExvb2tpbmcgQCBkb20gJWkuJWlcbiIsDQotICAgICAgICAgICAgICBjdXJpbmYtPnZjcHUtPmRv
bWFpbi0+ZG9tYWluX2lkLCBjdXJpbmYtPnZjcHUtPnZjcHVfaWQpOw0KICAgICAgICAgaWYgKCBQ
RVJJT0RfQkVHSU4oY3VyaW5mKSA+IG5vdyApDQogICAgICAgICAgICAgYnJlYWs7DQogICAgICAg
ICBfX2RlbF9mcm9tX3F1ZXVlKGN1cmluZi0+dmNwdSk7DQogICAgICAgICBfX2FkZF90b19ydW5x
dWV1ZV9zb3J0KGN1cmluZi0+dmNwdSk7DQogICAgIH0NCiAgDQotICAgIFBSSU5UKDMsIlVwZGF0
aW5nIHJ1bnEuLlxuIik7DQotDQotICAgIC8qIFByb2Nlc3MgdGhlIHJ1bnEsIGZpbmQgZG9tYWlu
cyB0aGF0IGFyZSBvbiB0aGUgcnVucSB0aGF0IHNob3VsZG4ndC4gKi8NCisgICAgLyogUHJvY2Vz
cyB0aGUgcnVucSwgZmluZCBkb21haW5zIHRoYXQgYXJlIG9uIHRoZSBydW5xIHRoYXQgc2hvdWxk
bid0ICovDQogICAgIGxpc3RfZm9yX2VhY2hfc2FmZSAoIGN1ciwgdG1wLCBydW5xICkNCiAgICAg
ew0KICAgICAgICAgY3VyaW5mID0gbGlzdF9lbnRyeShjdXIsc3RydWN0IHNlZGZfdmNwdV9pbmZv
LGxpc3QpOw0KLSAgICAgICAgUFJJTlQoNCwiXHRMb29raW5nIEAgZG9tICVpLiVpXG4iLA0KLSAg
ICAgICAgICAgICAgY3VyaW5mLT52Y3B1LT5kb21haW4tPmRvbWFpbl9pZCwgY3VyaW5mLT52Y3B1
LT52Y3B1X2lkKTsNCiANCiAgICAgICAgIGlmICggdW5saWtlbHkoY3VyaW5mLT5zbGljZSA9PSAw
KSApDQogICAgICAgICB7DQotICAgICAgICAgICAgLyogSWdub3JlIGRvbWFpbnMgd2l0aCBlbXB0
eSBzbGljZS4gKi8NCi0gICAgICAgICAgICBQUklOVCg0LCJcdFVwZGF0aW5nIHplcm8tc2xpY2Ug
ZG9tYWluICVpLiVpXG4iLA0KLSAgICAgICAgICAgICAgICAgIGN1cmluZi0+dmNwdS0+ZG9tYWlu
LT5kb21haW5faWQsDQotICAgICAgICAgICAgICAgICAgY3VyaW5mLT52Y3B1LT52Y3B1X2lkKTsN
CisgICAgICAgICAgICAvKiBJZ25vcmUgZG9tYWlucyB3aXRoIGVtcHR5IHNsaWNlICovDQogICAg
ICAgICAgICAgX19kZWxfZnJvbV9xdWV1ZShjdXJpbmYtPnZjcHUpOw0KIA0KLSAgICAgICAgICAg
IC8qIE1vdmUgdGhlbSB0byB0aGVpciBuZXh0IHBlcmlvZC4gKi8NCisgICAgICAgICAgICAvKiBN
b3ZlIHRoZW0gdG8gdGhlaXIgbmV4dCBwZXJpb2QgKi8NCiAgICAgICAgICAgICBjdXJpbmYtPmRl
YWRsX2FicyArPSBjdXJpbmYtPnBlcmlvZDsNCiANCi0gICAgICAgICAgICAvKiBFbnN1cmUgdGhh
dCB0aGUgc3RhcnQgb2YgdGhlIG5leHQgcGVyaW9kIGlzIGluIHRoZSBmdXR1cmUuICovDQorICAg
ICAgICAgICAgLyogRW5zdXJlIHRoYXQgdGhlIHN0YXJ0IG9mIHRoZSBuZXh0IHBlcmlvZCBpcyBp
biB0aGUgZnV0dXJlICovDQogICAgICAgICAgICAgaWYgKCB1bmxpa2VseShQRVJJT0RfQkVHSU4o
Y3VyaW5mKSA8IG5vdykgKQ0KICAgICAgICAgICAgICAgICBjdXJpbmYtPmRlYWRsX2FicyArPSAN
CiAgICAgICAgICAgICAgICAgICAgIChESVZfVVAobm93IC0gUEVSSU9EX0JFR0lOKGN1cmluZiks
DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgIGN1cmluZi0+cGVyaW9kKSkgKiBjdXJpbmYt
PnBlcmlvZDsNCiANCi0gICAgICAgICAgICAvKiBQdXQgdGhlbSBiYWNrIGludG8gdGhlIHF1ZXVl
LiAqLw0KKyAgICAgICAgICAgIC8qIFB1dCB0aGVtIGJhY2sgaW50byB0aGUgcXVldWUgKi8NCiAg
ICAgICAgICAgICBfX2FkZF90b193YWl0cXVldWVfc29ydChjdXJpbmYtPnZjcHUpOw0KICAgICAg
ICAgfQ0KICAgICAgICAgZWxzZSBpZiAoIHVubGlrZWx5KChjdXJpbmYtPmRlYWRsX2FicyA8IG5v
dykgfHwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAoY3VyaW5mLT5jcHV0aW1lID4gY3Vy
aW5mLT5zbGljZSkpICkNCiAgICAgICAgIHsNCi0gICAgICAgICAgICAvKg0KLSAgICAgICAgICAg
ICAqIFdlIG1pc3NlZCB0aGUgZGVhZGxpbmUgb3IgdGhlIHNsaWNlIHdhcyBhbHJlYWR5IGZpbmlz
aGVkLg0KKyAgICAgICAgICAgIC8qIFdlIG1pc3NlZCB0aGUgZGVhZGxpbmUgb3IgdGhlIHNsaWNl
IHdhcyBhbHJlYWR5IGZpbmlzaGVkLg0KICAgICAgICAgICAgICAqIE1pZ2h0IGhhcGVuIGJlY2F1
c2Ugb2YgZG9tX2Fkai4NCiAgICAgICAgICAgICAgKi8NCi0gICAgICAgICAgICBQUklOVCg0LCJc
dERvbWFpbiAlaS4laSBleGNlZWRlZCBpdCdzIGRlYWRsaW5lLyINCi0gICAgICAgICAgICAgICAg
ICAic2xpY2UgKCUiUFJJdTY0IiAvICUiUFJJdTY0Iikgbm93OiAlIlBSSXU2NA0KLSAgICAgICAg
ICAgICAgICAgICIgY3B1dGltZTogJSJQUkl1NjQiXG4iLA0KLSAgICAgICAgICAgICAgICAgIGN1
cmluZi0+dmNwdS0+ZG9tYWluLT5kb21haW5faWQsDQotICAgICAgICAgICAgICAgICAgY3VyaW5m
LT52Y3B1LT52Y3B1X2lkLA0KLSAgICAgICAgICAgICAgICAgIGN1cmluZi0+ZGVhZGxfYWJzLCBj
dXJpbmYtPnNsaWNlLCBub3csDQotICAgICAgICAgICAgICAgICAgY3VyaW5mLT5jcHV0aW1lKTsN
CisgICAgICAgICAgICBwcmludGsoIlx0RG9tYWluICVpLiVpIGV4Y2VlZGVkIGl0J3MgZGVhZGxp
bmUvIg0KKyAgICAgICAgICAgICAgICAgICAic2xpY2UgKCUiUFJJdTY0IiAvICUiUFJJdTY0Iikg
bm93OiAlIlBSSXU2NA0KKyAgICAgICAgICAgICAgICAgICAiIGNwdXRpbWU6ICUiUFJJdTY0Ilxu
IiwNCisgICAgICAgICAgICAgICAgICAgY3VyaW5mLT52Y3B1LT5kb21haW4tPmRvbWFpbl9pZCwN
CisgICAgICAgICAgICAgICAgICAgY3VyaW5mLT52Y3B1LT52Y3B1X2lkLA0KKyAgICAgICAgICAg
ICAgICAgICBjdXJpbmYtPmRlYWRsX2FicywgY3VyaW5mLT5zbGljZSwgbm93LA0KKyAgICAgICAg
ICAgICAgICAgICBjdXJpbmYtPmNwdXRpbWUpOw0KICAgICAgICAgICAgIF9fZGVsX2Zyb21fcXVl
dWUoY3VyaW5mLT52Y3B1KTsNCiANCi0gICAgICAgICAgICAvKiBDb21tb24gY2FzZTogd2UgbWlz
cyBvbmUgcGVyaW9kLiAqLw0KKyAgICAgICAgICAgIC8qIENvbW1vbiBjYXNlOiB3ZSBtaXNzIG9u
ZSBwZXJpb2QgKi8NCiAgICAgICAgICAgICBjdXJpbmYtPmRlYWRsX2FicyArPSBjdXJpbmYtPnBl
cmlvZDsNCiAgICANCi0gICAgICAgICAgICAvKg0KLSAgICAgICAgICAgICAqIElmIHdlIGFyZSBz
dGlsbCBiZWhpbmQ6IG1vZHVsbyBhcml0aG1ldGljLCBmb3JjZSBkZWFkbGluZQ0KKyAgICAgICAg
ICAgIC8qIElmIHdlIGFyZSBzdGlsbCBiZWhpbmQ6IG1vZHVsbyBhcml0aG1ldGljLCBmb3JjZSBk
ZWFkbGluZQ0KICAgICAgICAgICAgICAqIHRvIGJlIGluIGZ1dHVyZSBhbmQgYWxpZ25lZCB0byBw
ZXJpb2QgYm9yZGVycy4NCiAgICAgICAgICAgICAgKi8NCiAgICAgICAgICAgICBpZiAoIHVubGlr
ZWx5KGN1cmluZi0+ZGVhZGxfYWJzIDwgbm93KSApDQpAQCAtNTk2LDcgKzUzNiw3IEBAIHN0YXRp
YyB2b2lkIHVwZGF0ZV9xdWV1ZXMoDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgY3VyaW5m
LT5wZXJpb2QpICogY3VyaW5mLT5wZXJpb2Q7DQogICAgICAgICAgICAgQVNTRVJUKGN1cmluZi0+
ZGVhZGxfYWJzID49IG5vdyk7DQogDQotICAgICAgICAgICAgLyogR2l2ZSBhIGZyZXNoIHNsaWNl
LiAqLw0KKyAgICAgICAgICAgIC8qIEdpdmUgYSBmcmVzaCBzbGljZSAqLw0KICAgICAgICAgICAg
IGN1cmluZi0+Y3B1dGltZSA9IDA7DQogICAgICAgICAgICAgaWYgKCBQRVJJT0RfQkVHSU4oY3Vy
aW5mKSA+IG5vdyApDQogICAgICAgICAgICAgICAgIF9fYWRkX3RvX3dhaXRxdWV1ZV9zb3J0KGN1
cmluZi0+dmNwdSk7DQpAQCAtNjA2LDE3ICs1NDYsMTYgQEAgc3RhdGljIHZvaWQgdXBkYXRlX3F1
ZXVlcygNCiAgICAgICAgIGVsc2UNCiAgICAgICAgICAgICBicmVhazsNCiAgICAgfQ0KLQ0KLSAg
ICBQUklOVCgzLCJkb25lIHVwZGF0aW5nIHRoZSBxdWV1ZXNcbiIpOw0KIH0NCiANCiANCiAvKiBy
ZW1vdmVzIGEgZG9tYWluIGZyb20gdGhlIGhlYWQgb2YgdGhlIGFjY29yZGluZyBleHRyYVEgYW5k
DQotICAgcmVxdWV1ZXMgaXQgYXQgYSBzcGVjaWZpZWQgcG9zaXRpb246DQotICAgICByb3VuZC1y
b2JpbiBleHRyYXRpbWU6IGVuZCBvZiBleHRyYVENCi0gICAgIHdlaWdodGVkIGV4dC46IGluc2Vy
dCBpbiBzb3J0ZWQgbGlzdCBieSBzY29yZQ0KLSAgIGlmIHRoZSBkb21haW4gaXMgYmxvY2tlZCAv
IGhhcyByZWdhaW5lZCBpdHMgc2hvcnQtYmxvY2stbG9zcw0KLSAgIHRpbWUgaXQgaXMgbm90IHB1
dCBvbiBhbnkgcXVldWUgKi8NCisgKiByZXF1ZXVlcyBpdCBhdCBhIHNwZWNpZmllZCBwb3NpdGlv
bjoNCisgKiAgIHJvdW5kLXJvYmluIGV4dHJhdGltZTogZW5kIG9mIGV4dHJhUQ0KKyAqICAgd2Vp
Z2h0ZWQgZXh0LjogaW5zZXJ0IGluIHNvcnRlZCBsaXN0IGJ5IHNjb3JlDQorICogaWYgdGhlIGRv
bWFpbiBpcyBibG9ja2VkIC8gaGFzIHJlZ2FpbmVkIGl0cyBzaG9ydC1ibG9jay1sb3NzDQorICog
dGltZSBpdCBpcyBub3QgcHV0IG9uIGFueSBxdWV1ZS4NCisgKi8NCiBzdGF0aWMgdm9pZCBkZXNj
aGVkX2V4dHJhX2RvbShzX3RpbWVfdCBub3csIHN0cnVjdCB2Y3B1ICpkKQ0KIHsNCiAgICAgc3Ry
dWN0IHNlZGZfdmNwdV9pbmZvICppbmYgPSBFRE9NX0lORk8oZCk7DQpAQCAtNjI1LDI5ICs1NjQs
MjUgQEAgc3RhdGljIHZvaWQgZGVzY2hlZF9leHRyYV9kb20oc190aW1lX3Qgbg0KIA0KICAgICBB
U1NFUlQoZXh0cmFxX29uKGQsIGkpKTsNCiANCi0gICAgLyogVW5zZXQgYWxsIHJ1bm5pbmcgZmxh
Z3MuICovDQorICAgIC8qIFVuc2V0IGFsbCBydW5uaW5nIGZsYWdzICovDQogICAgIGluZi0+c3Rh
dHVzICAmPSB+KEVYVFJBX1JVTl9QRU4gfCBFWFRSQV9SVU5fVVRJTCk7DQotICAgIC8qIEZyZXNo
IHNsaWNlIGZvciB0aGUgbmV4dCBydW4uICovDQorICAgIC8qIEZyZXNoIHNsaWNlIGZvciB0aGUg
bmV4dCBydW4gKi8NCiAgICAgaW5mLT5jcHV0aW1lID0gMDsNCi0gICAgLyogQWNjdW11bGF0ZSB0
b3RhbCBleHRyYXRpbWUuICovDQorICAgIC8qIEFjY3VtdWxhdGUgdG90YWwgZXh0cmF0aW1lICov
DQogICAgIGluZi0+ZXh0cmFfdGltZV90b3QgKz0gbm93IC0gaW5mLT5zY2hlZF9zdGFydF9hYnM7
DQogICAgIC8qIFJlbW92ZSBleHRyYWRvbWFpbiBmcm9tIGhlYWQgb2YgdGhlIHF1ZXVlLiAqLw0K
ICAgICBleHRyYXFfZGVsKGQsIGkpOw0KIA0KLSAgICAvKiBVcGRhdGUgdGhlIHNjb3JlLiAqLw0K
KyAgICAvKiBVcGRhdGUgdGhlIHNjb3JlICovDQogICAgIG9sZHNjb3JlID0gaW5mLT5zY29yZVtp
XTsNCiAgICAgaWYgKCBpID09IEVYVFJBX1BFTl9RICkNCiAgICAgew0KLSAgICAgICAgLypkb21h
aW4gd2FzIHJ1bm5pbmcgaW4gTDAgZXh0cmFxKi8NCi0gICAgICAgIC8qcmVkdWNlIGJsb2NrIGxv
c3QsIHByb2JhYmx5IG1vcmUgc29waGlzdGljYXRpb24gaGVyZSEqLw0KKyAgICAgICAgLyogRG9t
YWluIHdhcyBydW5uaW5nIGluIEwwIGV4dHJhcSAqLw0KKyAgICAgICAgLyogcmVkdWNlIGJsb2Nr
IGxvc3QsIHByb2JhYmx5IG1vcmUgc29waGlzdGljYXRpb24gaGVyZSEqLw0KICAgICAgICAgLypp
bmYtPnNob3J0X2Jsb2NrX2xvc3RfdG90IC09IEVYVFJBX1FVQU5UVU07Ki8NCiAgICAgICAgIGlu
Zi0+c2hvcnRfYmxvY2tfbG9zdF90b3QgLT0gbm93IC0gaW5mLT5zY2hlZF9zdGFydF9hYnM7DQot
ICAgICAgICBQUklOVCgzLCJEb21haW4gJWkuJWk6IFNob3J0X2Jsb2NrX2xvc3M6ICUiUFJJaTY0
IlxuIiwgDQotICAgICAgICAgICAgICBpbmYtPnZjcHUtPmRvbWFpbi0+ZG9tYWluX2lkLCBpbmYt
PnZjcHUtPnZjcHVfaWQsDQotICAgICAgICAgICAgICBpbmYtPnNob3J0X2Jsb2NrX2xvc3RfdG90
KTsNCiAjaWYgMA0KLSAgICAgICAgLyoNCi0gICAgICAgICAqIEtBRjogSWYgd2UgZG9uJ3QgZXhp
dCBzaG9ydC1ibG9ja2luZyBzdGF0ZSBhdCB0aGlzIHBvaW50DQorICAgICAgICAvKiBLQUY6IElm
IHdlIGRvbid0IGV4aXQgc2hvcnQtYmxvY2tpbmcgc3RhdGUgYXQgdGhpcyBwb2ludA0KICAgICAg
ICAgICogZG9tYWluMCBjYW4gc3RlYWwgYWxsIENQVSBmb3IgdXAgdG8gMTAgc2Vjb25kcyBiZWZv
cmUNCiAgICAgICAgICAqIHNjaGVkdWxpbmcgc2V0dGxlcyBkb3duICh3aGVuIGNvbXBldGluZyBh
Z2FpbnN0IGFub3RoZXINCiAgICAgICAgICAqIENQVS1ib3VuZCBkb21haW4pLiBEb2luZyB0aGlz
IHNlZW1zIHRvIG1ha2UgdGhpbmdzIGJlaGF2ZQ0KQEAgLTY1Niw1MSArNTkxLDU2IEBAIHN0YXRp
YyB2b2lkIGRlc2NoZWRfZXh0cmFfZG9tKHNfdGltZV90IG4NCiAgICAgICAgIGlmICggaW5mLT5z
aG9ydF9ibG9ja19sb3N0X3RvdCA8PSAwICkNCiAjZW5kaWYNCiAgICAgICAgIHsNCi0gICAgICAg
ICAgICBQUklOVCg0LCJEb21haW4gJWkuJWkgY29tcGVuc2F0ZWQgc2hvcnQgYmxvY2sgbG9zcyFc
biIsDQotICAgICAgICAgICAgICAgICAgaW5mLT52Y3B1LT5kb21haW4tPmRvbWFpbl9pZCwgaW5m
LT52Y3B1LT52Y3B1X2lkKTsNCi0gICAgICAgICAgICAvKndlIGhhdmUgKG92ZXItKWNvbXBlbnNh
dGVkIG91ciBibG9jayBwZW5hbHR5Ki8NCisgICAgICAgICAgICAvKiBXZSBoYXZlIChvdmVyLSlj
b21wZW5zYXRlZCBvdXIgYmxvY2sgcGVuYWx0eSAqLw0KICAgICAgICAgICAgIGluZi0+c2hvcnRf
YmxvY2tfbG9zdF90b3QgPSAwOw0KLSAgICAgICAgICAgIC8qd2UgZG9uJ3Qgd2FudCBhIHBsYWNl
IG9uIHRoZSBwZW5hbHR5IHF1ZXVlIGFueW1vcmUhKi8NCisgICAgICAgICAgICAvKiBXZSBkb24n
dCB3YW50IGEgcGxhY2Ugb24gdGhlIHBlbmFsdHkgcXVldWUgYW55bW9yZSEgKi8NCiAgICAgICAg
ICAgICBpbmYtPnN0YXR1cyAmPSB+RVhUUkFfV0FOVF9QRU5fUTsNCiAgICAgICAgICAgICBnb3Rv
IGNoZWNrX2V4dHJhX3F1ZXVlczsNCiAgICAgICAgIH0NCiANCi0gICAgICAgIC8qd2UgaGF2ZSB0
byBnbyBhZ2FpbiBmb3IgYW5vdGhlciB0cnkgaW4gdGhlIGJsb2NrLWV4dHJhcSwNCi0gICAgICAg
ICAgdGhlIHNjb3JlIGlzIG5vdCB1c2VkIGluY3JlbWFudGFsbHkgaGVyZSwgYXMgdGhpcyBpcw0K
LSAgICAgICAgICBhbHJlYWR5IGRvbmUgYnkgcmVjYWxjdWxhdGluZyB0aGUgYmxvY2tfbG9zdCov
DQorICAgICAgICAvKiBXZSBoYXZlIHRvIGdvIGFnYWluIGZvciBhbm90aGVyIHRyeSBpbiB0aGUg
YmxvY2stZXh0cmFxLA0KKyAgICAgICAgICogdGhlIHNjb3JlIGlzIG5vdCB1c2VkIGluY3JlbWFu
dGFsbHkgaGVyZSwgYXMgdGhpcyBpcw0KKyAgICAgICAgICogYWxyZWFkeSBkb25lIGJ5IHJlY2Fs
Y3VsYXRpbmcgdGhlIGJsb2NrX2xvc3QNCisgICAgICAgICAqLw0KICAgICAgICAgaW5mLT5zY29y
ZVtFWFRSQV9QRU5fUV0gPSAoaW5mLT5wZXJpb2QgPDwgMTApIC8NCiAgICAgICAgICAgICBpbmYt
PnNob3J0X2Jsb2NrX2xvc3RfdG90Ow0KICAgICAgICAgb2xkc2NvcmUgPSAwOw0KICAgICB9DQog
ICAgIGVsc2UNCiAgICAgew0KLSAgICAgICAgLypkb21haW4gd2FzIHJ1bm5pbmcgaW4gTDEgZXh0
cmFxID0+IHNjb3JlIGlzIGludmVyc2Ugb2YNCi0gICAgICAgICAgdXRpbGl6YXRpb24gYW5kIGlz
IHVzZWQgc29tZXdoYXQgaW5jcmVtZW50YWwhKi8NCisgICAgICAgIC8qIERvbWFpbiB3YXMgcnVu
bmluZyBpbiBMMSBleHRyYXEgPT4gc2NvcmUgaXMgaW52ZXJzZSBvZg0KKyAgICAgICAgICogdXRp
bGl6YXRpb24gYW5kIGlzIHVzZWQgc29tZXdoYXQgaW5jcmVtZW50YWwhDQorICAgICAgICAgKi8N
CiAgICAgICAgIGlmICggIWluZi0+ZXh0cmF3ZWlnaHQgKQ0KLSAgICAgICAgICAgIC8qTkI6IHVz
ZSBmaXhlZCBwb2ludCBhcml0aG1ldGljIHdpdGggMTAgYml0cyovDQorICAgICAgICB7DQorICAg
ICAgICAgICAgLyogTkI6IHVzZSBmaXhlZCBwb2ludCBhcml0aG1ldGljIHdpdGggMTAgYml0cyAq
Lw0KICAgICAgICAgICAgIGluZi0+c2NvcmVbRVhUUkFfVVRJTF9RXSA9IChpbmYtPnBlcmlvZCA8
PCAxMCkgLw0KICAgICAgICAgICAgICAgICBpbmYtPnNsaWNlOw0KKyAgICAgICAgfQ0KICAgICAg
ICAgZWxzZQ0KLSAgICAgICAgICAgIC8qY29udmVyc2lvbiBiZXR3ZWVuIHJlYWx0aW1lIHV0aWxp
c2F0aW9uIGFuZCBleHRyYXdpZWdodDoNCi0gICAgICAgICAgICAgIGZ1bGwgKGllIDEwMCUpIHV0
aWxpemF0aW9uIGlzIGVxdWl2YWxlbnQgdG8gMTI4IGV4dHJhd2VpZ2h0Ki8NCisgICAgICAgIHsN
CisgICAgICAgICAgICAvKiBDb252ZXJzaW9uIGJldHdlZW4gcmVhbHRpbWUgdXRpbGlzYXRpb24g
YW5kIGV4dHJhd2llZ2h0Og0KKyAgICAgICAgICAgICAqIGZ1bGwgKGllIDEwMCUpIHV0aWxpemF0
aW9uIGlzIGVxdWl2YWxlbnQgdG8gMTI4IGV4dHJhd2VpZ2h0DQorICAgICAgICAgICAgICovDQog
ICAgICAgICAgICAgaW5mLT5zY29yZVtFWFRSQV9VVElMX1FdID0gKDE8PDE3KSAvIGluZi0+ZXh0
cmF3ZWlnaHQ7DQorICAgICAgICB9DQogICAgIH0NCiANCiAgY2hlY2tfZXh0cmFfcXVldWVzOg0K
LSAgICAvKiBBZGRpbmcgYSBydW5uYWJsZSBkb21haW4gdG8gdGhlIHJpZ2h0IHF1ZXVlIGFuZCBy
ZW1vdmluZyBibG9ja2VkIG9uZXMqLw0KKyAgICAvKiBBZGRpbmcgYSBydW5uYWJsZSBkb21haW4g
dG8gdGhlIHJpZ2h0IHF1ZXVlIGFuZCByZW1vdmluZyBibG9ja2VkIG9uZXMgKi8NCiAgICAgaWYg
KCBzZWRmX3J1bm5hYmxlKGQpICkNCiAgICAgew0KLSAgICAgICAgLyphZGQgYWNjb3JkaW5nIHRv
IHNjb3JlOiB3ZWlnaHRlZCByb3VuZCByb2JpbiovDQorICAgICAgICAvKiBBZGQgYWNjb3JkaW5n
IHRvIHNjb3JlOiB3ZWlnaHRlZCByb3VuZCByb2JpbiAqLw0KICAgICAgICAgaWYgKCgoaW5mLT5z
dGF0dXMgJiBFWFRSQV9BV0FSRSkgJiYgKGkgPT0gRVhUUkFfVVRJTF9RKSkgfHwNCiAgICAgICAg
ICAgICAoKGluZi0+c3RhdHVzICYgRVhUUkFfV0FOVF9QRU5fUSkgJiYgKGkgPT0gRVhUUkFfUEVO
X1EpKSkNCiAgICAgICAgICAgICBleHRyYXFfYWRkX3NvcnRfdXBkYXRlKGQsIGksIG9sZHNjb3Jl
KTsNCiAgICAgfQ0KICAgICBlbHNlDQogICAgIHsNCi0gICAgICAgIC8qcmVtb3ZlIHRoaXMgYmxv
Y2tlZCBkb21haW4gZnJvbSB0aGUgd2FpdHEhKi8NCisgICAgICAgIC8qIFJlbW92ZSB0aGlzIGJs
b2NrZWQgZG9tYWluIGZyb20gdGhlIHdhaXRxISAqLw0KICAgICAgICAgX19kZWxfZnJvbV9xdWV1
ZShkKTsNCi0gICAgICAgIC8qbWFrZSBzdXJlIHRoYXQgd2UgcmVtb3ZlIGEgYmxvY2tlZCBkb21h
aW4gZnJvbSB0aGUgb3RoZXINCi0gICAgICAgICAgZXh0cmFxIHRvbyovDQorICAgICAgICAvKiBN
YWtlIHN1cmUgdGhhdCB3ZSByZW1vdmUgYSBibG9ja2VkIGRvbWFpbiBmcm9tIHRoZSBvdGhlcg0K
KyAgICAgICAgICogZXh0cmFxIHRvby4gKi8NCiAgICAgICAgIGlmICggaSA9PSBFWFRSQV9QRU5f
USApDQogICAgICAgICB7DQogICAgICAgICAgICAgaWYgKCBleHRyYXFfb24oZCwgRVhUUkFfVVRJ
TF9RKSApDQpAQCAtNzMyLDggKzY3Miw5IEBAIHN0YXRpYyBzdHJ1Y3QgdGFza19zbGljZSBzZWRm
X2RvX2V4dHJhX3MNCiANCiAgICAgaWYgKCAhbGlzdF9lbXB0eShleHRyYXFbRVhUUkFfUEVOX1Fd
KSApDQogICAgIHsNCi0gICAgICAgIC8qd2Ugc3RpbGwgaGF2ZSBlbGVtZW50cyBvbiB0aGUgbGV2
ZWwgMCBleHRyYXEgDQotICAgICAgICAgID0+IGxldCB0aG9zZSBydW4gZmlyc3QhKi8NCisgICAg
ICAgIC8qIFdlIHN0aWxsIGhhdmUgZWxlbWVudHMgb24gdGhlIGxldmVsIDAgZXh0cmFxDQorICAg
ICAgICAgKiA9PiBsZXQgdGhvc2UgcnVuIGZpcnN0IQ0KKyAgICAgICAgICovDQogICAgICAgICBy
dW5pbmYgICA9IGxpc3RfZW50cnkoZXh0cmFxW0VYVFJBX1BFTl9RXS0+bmV4dCwgDQogICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgc3RydWN0IHNlZGZfdmNwdV9pbmZvLCBleHRyYWxpc3Rb
RVhUUkFfUEVOX1FdKTsNCiAgICAgICAgIHJ1bmluZi0+c3RhdHVzIHw9IEVYVFJBX1JVTl9QRU47
DQpAQCAtNzQ3LDcgKzY4OCw3IEBAIHN0YXRpYyBzdHJ1Y3QgdGFza19zbGljZSBzZWRmX2RvX2V4
dHJhX3MNCiAgICAgew0KICAgICAgICAgaWYgKCAhbGlzdF9lbXB0eShleHRyYXFbRVhUUkFfVVRJ
TF9RXSkgKQ0KICAgICAgICAgew0KLSAgICAgICAgICAgIC8qdXNlIGVsZW1lbnRzIGZyb20gdGhl
IG5vcm1hbCBleHRyYXF1ZXVlKi8NCisgICAgICAgICAgICAvKiBVc2UgZWxlbWVudHMgZnJvbSB0
aGUgbm9ybWFsIGV4dHJhcXVldWUgKi8NCiAgICAgICAgICAgICBydW5pbmYgICA9IGxpc3RfZW50
cnkoZXh0cmFxW0VYVFJBX1VUSUxfUV0tPm5leHQsDQogICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgIHN0cnVjdCBzZWRmX3ZjcHVfaW5mbywNCiAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgZXh0cmFsaXN0W0VYVFJBX1VUSUxfUV0pOw0KQEAgLTc3MywxMCArNzE0LDEx
IEBAIHN0YXRpYyBzdHJ1Y3QgdGFza19zbGljZSBzZWRmX2RvX2V4dHJhX3MNCiANCiANCiAvKiBN
YWluIHNjaGVkdWxpbmcgZnVuY3Rpb24NCi0gICBSZWFzb25zIGZvciBjYWxsaW5nIHRoaXMgZnVu
Y3Rpb24gYXJlOg0KLSAgIC10aW1lc2xpY2UgZm9yIHRoZSBjdXJyZW50IHBlcmlvZCB1c2VkIHVw
DQotICAgLWRvbWFpbiBvbiB3YWl0cXVldWUgaGFzIHN0YXJ0ZWQgaXQncyBwZXJpb2QNCi0gICAt
YW5kIHZhcmlvdXMgb3RoZXJzIDspIGluIGdlbmVyYWw6IGRldGVybWluZSB3aGljaCBkb21haW4g
dG8gcnVuIG5leHQqLw0KKyAqIFJlYXNvbnMgZm9yIGNhbGxpbmcgdGhpcyBmdW5jdGlvbiBhcmU6
DQorICogLXRpbWVzbGljZSBmb3IgdGhlIGN1cnJlbnQgcGVyaW9kIHVzZWQgdXANCisgKiAtZG9t
YWluIG9uIHdhaXRxdWV1ZSBoYXMgc3RhcnRlZCBpdCdzIHBlcmlvZA0KKyAqIC1hbmQgdmFyaW91
cyBvdGhlcnMgOykgaW4gZ2VuZXJhbDogZGV0ZXJtaW5lIHdoaWNoIGRvbWFpbiB0byBydW4gbmV4
dA0KKyAqLw0KIHN0YXRpYyBzdHJ1Y3QgdGFza19zbGljZSBzZWRmX2RvX3NjaGVkdWxlKA0KICAg
ICBjb25zdCBzdHJ1Y3Qgc2NoZWR1bGVyICpvcHMsIHNfdGltZV90IG5vdywgYm9vbF90IHRhc2ts
ZXRfd29ya19zY2hlZHVsZWQpDQogew0KQEAgLTc4OSwxMyArNzMxLDE0IEBAIHN0YXRpYyBzdHJ1
Y3QgdGFza19zbGljZSBzZWRmX2RvX3NjaGVkdWwNCiAgICAgc3RydWN0IHNlZGZfdmNwdV9pbmZv
ICpydW5pbmYsICp3YWl0aW5mOw0KICAgICBzdHJ1Y3QgdGFza19zbGljZSAgICAgIHJldDsNCiAN
Ci0gICAgLyppZGxlIHRhc2tzIGRvbid0IG5lZWQgYW55IG9mIHRoZSBmb2xsb3dpbmcgc3R1Ziov
DQorICAgIC8qIElkbGUgdGFza3MgZG9uJ3QgbmVlZCBhbnkgb2YgdGhlIGZvbGxvd2luZyBzdHVm
ICovDQogICAgIGlmICggaXNfaWRsZV92Y3B1KGN1cnJlbnQpICkNCiAgICAgICAgIGdvdG8gY2hl
Y2tfd2FpdHE7DQogIA0KLSAgICAvKiBjcmVhdGUgbG9jYWwgc3RhdGUgb2YgdGhlIHN0YXR1cyBv
ZiB0aGUgZG9tYWluLCBpbiBvcmRlciB0byBhdm9pZA0KLSAgICAgICBpbmNvbnNpc3RlbnQgc3Rh
dGUgZHVyaW5nIHNjaGVkdWxpbmcgZGVjaXNpb25zLCBiZWNhdXNlIGRhdGEgZm9yDQotICAgICAg
IHZjcHVfcnVubmFibGUgaXMgbm90IHByb3RlY3RlZCBieSB0aGUgc2NoZWR1bGluZyBsb2NrISov
DQorICAgIC8qIENyZWF0ZSBsb2NhbCBzdGF0ZSBvZiB0aGUgc3RhdHVzIG9mIHRoZSBkb21haW4s
IGluIG9yZGVyIHRvIGF2b2lkDQorICAgICAqIGluY29uc2lzdGVudCBzdGF0ZSBkdXJpbmcgc2No
ZWR1bGluZyBkZWNpc2lvbnMsIGJlY2F1c2UgZGF0YSBmb3INCisgICAgICogdmNwdV9ydW5uYWJs
ZSBpcyBub3QgcHJvdGVjdGVkIGJ5IHRoZSBzY2hlZHVsaW5nIGxvY2shDQorICAgICAqLw0KICAg
ICBpZiAoICF2Y3B1X3J1bm5hYmxlKGN1cnJlbnQpICkNCiAgICAgICAgIGluZi0+c3RhdHVzIHw9
IFNFREZfQVNMRUVQOw0KICANCkBAIC04MDQsNyArNzQ3LDcgQEAgc3RhdGljIHN0cnVjdCB0YXNr
X3NsaWNlIHNlZGZfZG9fc2NoZWR1bA0KIA0KICAgICBpZiAoIHVubGlrZWx5KGV4dHJhX3J1bnMo
aW5mKSkgKQ0KICAgICB7DQotICAgICAgICAvKnNwZWNpYWwgdHJlYXRtZW50IG9mIGRvbWFpbnMg
cnVubmluZyBpbiBleHRyYSB0aW1lKi8NCisgICAgICAgIC8qIFNwZWNpYWwgdHJlYXRtZW50IG9m
IGRvbWFpbnMgcnVubmluZyBpbiBleHRyYSB0aW1lICovDQogICAgICAgICBkZXNjaGVkX2V4dHJh
X2RvbShub3csIGN1cnJlbnQpOw0KICAgICB9DQogICAgIGVsc2UgDQpAQCAtODE0LDEwICs3NTcs
MTEgQEAgc3RhdGljIHN0cnVjdCB0YXNrX3NsaWNlIHNlZGZfZG9fc2NoZWR1bA0KICBjaGVja193
YWl0cToNCiAgICAgdXBkYXRlX3F1ZXVlcyhub3csIHJ1bnEsIHdhaXRxKTsNCiANCi0gICAgLypu
b3cgc2ltcGx5IHBpY2sgdGhlIGZpcnN0IGRvbWFpbiBmcm9tIHRoZSBydW5xdWV1ZSwgd2hpY2gg
aGFzIHRoZQ0KLSAgICAgIGVhcmxpZXN0IGRlYWRsaW5lLCBiZWNhdXNlIHRoZSBsaXN0IGlzIHNv
cnRlZCovDQotIA0KLSAgICAvKiBUYXNrbGV0IHdvcmsgKHdoaWNoIHJ1bnMgaW4gaWRsZSBWQ1BV
IGNvbnRleHQpIG92ZXJyaWRlcyBhbGwgZWxzZS4gKi8NCisgICAgLyogTm93IHNpbXBseSBwaWNr
IHRoZSBmaXJzdCBkb21haW4gZnJvbSB0aGUgcnVucXVldWUsIHdoaWNoIGhhcyB0aGUNCisgICAg
ICogZWFybGllc3QgZGVhZGxpbmUsIGJlY2F1c2UgdGhlIGxpc3QgaXMgc29ydGVkDQorICAgICAq
DQorICAgICAqIFRhc2tsZXQgd29yayAod2hpY2ggcnVucyBpbiBpZGxlIFZDUFUgY29udGV4dCkg
b3ZlcnJpZGVzIGFsbCBlbHNlLg0KKyAgICAgKi8NCiAgICAgaWYgKCB0YXNrbGV0X3dvcmtfc2No
ZWR1bGVkIHx8DQogICAgICAgICAgKGxpc3RfZW1wdHkocnVucSkgJiYgbGlzdF9lbXB0eSh3YWl0
cSkpIHx8DQogICAgICAgICAgdW5saWtlbHkoIWNwdW1hc2tfdGVzdF9jcHUoY3B1LCBTRURGX0NQ
VU9OTElORShwZXJfY3B1KGNwdXBvb2wsIGNwdSkpKSkgKQ0KQEAgLTgzMyw5ICs3NzcsMTAgQEAg
c3RhdGljIHN0cnVjdCB0YXNrX3NsaWNlIHNlZGZfZG9fc2NoZWR1bA0KICAgICAgICAgew0KICAg
ICAgICAgICAgIHdhaXRpbmYgID0gbGlzdF9lbnRyeSh3YWl0cS0+bmV4dCwNCiAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgc3RydWN0IHNlZGZfdmNwdV9pbmZvLGxpc3QpOw0KLSAg
ICAgICAgICAgIC8qcmVydW4gc2NoZWR1bGVyLCB3aGVuIHNjaGVkdWxlZCBkb21haW4gcmVhY2hl
cyBpdCdzDQotICAgICAgICAgICAgICBlbmQgb2Ygc2xpY2Ugb3IgdGhlIGZpcnN0IGRvbWFpbiBm
cm9tIHRoZSB3YWl0cXVldWUNCi0gICAgICAgICAgICAgIGdldHMgcmVhZHkqLw0KKyAgICAgICAg
ICAgIC8qIFJlcnVuIHNjaGVkdWxlciwgd2hlbiBzY2hlZHVsZWQgZG9tYWluIHJlYWNoZXMgaXQn
cw0KKyAgICAgICAgICAgICAqIGVuZCBvZiBzbGljZSBvciB0aGUgZmlyc3QgZG9tYWluIGZyb20g
dGhlIHdhaXRxdWV1ZQ0KKyAgICAgICAgICAgICAqIGdldHMgcmVhZHkuDQorICAgICAgICAgICAg
ICovDQogICAgICAgICAgICAgcmV0LnRpbWUgPSBNSU4obm93ICsgcnVuaW5mLT5zbGljZSAtIHJ1
bmluZi0+Y3B1dGltZSwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICBQRVJJT0RfQkVHSU4o
d2FpdGluZikpIC0gbm93Ow0KICAgICAgICAgfQ0KQEAgLTg0NywxNCArNzkyLDE1IEBAIHN0YXRp
YyBzdHJ1Y3QgdGFza19zbGljZSBzZWRmX2RvX3NjaGVkdWwNCiAgICAgZWxzZQ0KICAgICB7DQog
ICAgICAgICB3YWl0aW5mICA9IGxpc3RfZW50cnkod2FpdHEtPm5leHQsc3RydWN0IHNlZGZfdmNw
dV9pbmZvLCBsaXN0KTsNCi0gICAgICAgIC8qd2UgY291bGQgbm90IGZpbmQgYW55IHN1aXRhYmxl
IGRvbWFpbiANCi0gICAgICAgICAgPT4gbG9vayBmb3IgZG9tYWlucyB0aGF0IGFyZSBhd2FyZSBv
ZiBleHRyYXRpbWUqLw0KKyAgICAgICAgLyogV2UgY291bGQgbm90IGZpbmQgYW55IHN1aXRhYmxl
IGRvbWFpbiANCisgICAgICAgICAqID0+IGxvb2sgZm9yIGRvbWFpbnMgdGhhdCBhcmUgYXdhcmUg
b2YgZXh0cmF0aW1lKi8NCiAgICAgICAgIHJldCA9IHNlZGZfZG9fZXh0cmFfc2NoZWR1bGUobm93
LCBQRVJJT0RfQkVHSU4od2FpdGluZiksDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIGV4dHJhcSwgY3B1KTsNCiAgICAgfQ0KIA0KLSAgICAvKlRPRE86IERvIHNvbWV0aGlu
ZyBVU0VGVUwgd2hlbiB0aGlzIGhhcHBlbnMgYW5kIGZpbmQgb3V0LCB3aHkgaXQNCi0gICAgICBz
dGlsbCBjYW4gaGFwcGVuISEhKi8NCisgICAgLyogVE9ETzogRG8gc29tZXRoaW5nIFVTRUZVTCB3
aGVuIHRoaXMgaGFwcGVucyBhbmQgZmluZCBvdXQsIHdoeSBpdA0KKyAgICAgKiBzdGlsbCBjYW4g
aGFwcGVuISEhDQorICAgICAqLw0KICAgICBpZiAoIHJldC50aW1lIDwgMCkNCiAgICAgew0KICAg
ICAgICAgcHJpbnRrKCJPdWNoISBXZSBhcmUgc2VyaW91c2x5IEJFSElORCBzY2hlZHVsZSEgJSJQ
UklpNjQiXG4iLA0KQEAgLTg3NCw5ICs4MjAsNiBAQCBzdGF0aWMgc3RydWN0IHRhc2tfc2xpY2Ug
c2VkZl9kb19zY2hlZHVsDQogDQogc3RhdGljIHZvaWQgc2VkZl9zbGVlcChjb25zdCBzdHJ1Y3Qg
c2NoZWR1bGVyICpvcHMsIHN0cnVjdCB2Y3B1ICpkKQ0KIHsNCi0gICAgUFJJTlQoMiwic2VkZl9z
bGVlcCB3YXMgY2FsbGVkLCBkb21haW4taWQgJWkuJWlcbiIsDQotICAgICAgICAgIGQtPmRvbWFp
bi0+ZG9tYWluX2lkLCBkLT52Y3B1X2lkKTsNCi0gDQogICAgIGlmICggaXNfaWRsZV92Y3B1KGQp
ICkNCiAgICAgICAgIHJldHVybjsNCiANCkBAIC05NzIsMjcgKzkxNSwyOSBAQCBzdGF0aWMgdm9p
ZCBzZWRmX3NsZWVwKGNvbnN0IHN0cnVjdCBzY2hlDQogc3RhdGljIHZvaWQgdW5ibG9ja19zaG9y
dF9leHRyYV9zdXBwb3J0KA0KICAgICBzdHJ1Y3Qgc2VkZl92Y3B1X2luZm8qIGluZiwgc190aW1l
X3Qgbm93KQ0KIHsNCi0gICAgLyp0aGlzIHVuYmxvY2tpbmcgc2NoZW1lIHRyaWVzIHRvIHN1cHBv
cnQgdGhlIGRvbWFpbiwgYnkgYXNzaWduaW5nIGl0DQotICAgIGEgcHJpb3JpdHkgaW4gZXh0cmF0
aW1lIGRpc3RyaWJ1dGlvbiBhY2NvcmRpbmcgdG8gdGhlIGxvc3Mgb2YgdGltZQ0KLSAgICBpbiB0
aGlzIHNsaWNlIGR1ZSB0byBibG9ja2luZyovDQorICAgIC8qIFRoaXMgdW5ibG9ja2luZyBzY2hl
bWUgdHJpZXMgdG8gc3VwcG9ydCB0aGUgZG9tYWluLCBieSBhc3NpZ25pbmcgaXQNCisgICAgICog
YSBwcmlvcml0eSBpbiBleHRyYXRpbWUgZGlzdHJpYnV0aW9uIGFjY29yZGluZyB0byB0aGUgbG9z
cyBvZiB0aW1lDQorICAgICAqIGluIHRoaXMgc2xpY2UgZHVlIHRvIGJsb2NraW5nDQorICAgICAq
Lw0KICAgICBzX3RpbWVfdCBwZW47DQogIA0KLSAgICAvKm5vIG1vcmUgcmVhbHRpbWUgZXhlY3V0
aW9uIGluIHRoaXMgcGVyaW9kISovDQorICAgIC8qIE5vIG1vcmUgcmVhbHRpbWUgZXhlY3V0aW9u
IGluIHRoaXMgcGVyaW9kISAqLw0KICAgICBpbmYtPmRlYWRsX2FicyArPSBpbmYtPnBlcmlvZDsN
CiAgICAgaWYgKCBsaWtlbHkoaW5mLT5ibG9ja19hYnMpICkNCiAgICAgew0KLSAgICAgICAgLy90
cmVhdCBibG9ja2VkIHRpbWUgYXMgY29uc3VtZWQgYnkgdGhlIGRvbWFpbiovDQorICAgICAgICAv
KiBUcmVhdCBibG9ja2VkIHRpbWUgYXMgY29uc3VtZWQgYnkgdGhlIGRvbWFpbiAqLw0KICAgICAg
ICAgLyppbmYtPmNwdXRpbWUgKz0gbm93IC0gaW5mLT5ibG9ja19hYnM7Ki8NCi0gICAgICAgIC8q
cGVuYWx0eSBpcyB0aW1lIHRoZSBkb21haW4gd291bGQgaGF2ZQ0KLSAgICAgICAgICBoYWQgaWYg
aXQgY29udGludWVkIHRvIHJ1biAqLw0KKyAgICAgICAgLyogUGVuYWx0eSBpcyB0aW1lIHRoZSBk
b21haW4gd291bGQgaGF2ZQ0KKyAgICAgICAgICogaGFkIGlmIGl0IGNvbnRpbnVlZCB0byBydW4u
DQorICAgICAgICAgKi8NCiAgICAgICAgIHBlbiA9IChpbmYtPnNsaWNlIC0gaW5mLT5jcHV0aW1l
KTsNCiAgICAgICAgIGlmICggcGVuIDwgMCApDQogICAgICAgICAgICAgcGVuID0gMDsNCi0gICAg
ICAgIC8qYWNjdW11bGF0ZSBhbGwgcGVuYWx0aWVzIG92ZXIgdGhlIHBlcmlvZHMqLw0KKyAgICAg
ICAgLyogQWNjdW11bGF0ZSBhbGwgcGVuYWx0aWVzIG92ZXIgdGhlIHBlcmlvZHMgKi8NCiAgICAg
ICAgIC8qaW5mLT5zaG9ydF9ibG9ja19sb3N0X3RvdCArPSBwZW47Ki8NCi0gICAgICAgIC8qc2V0
IHBlbmFsdHkgdG8gdGhlIGN1cnJlbnQgdmFsdWUqLw0KKyAgICAgICAgLyogU2V0IHBlbmFsdHkg
dG8gdGhlIGN1cnJlbnQgdmFsdWUgKi8NCiAgICAgICAgIGluZi0+c2hvcnRfYmxvY2tfbG9zdF90
b3QgPSBwZW47DQotICAgICAgICAvKm5vdCBzdXJlIHdoaWNoIG9uZSBpcyBiZXR0ZXIuLiBidXQg
c2VlbXMgdG8gd29yayB3ZWxsLi4uKi8NCisgICAgICAgIC8qIE5vdCBzdXJlIHdoaWNoIG9uZSBp
cyBiZXR0ZXIuLiBidXQgc2VlbXMgdG8gd29yayB3ZWxsLi4uICovDQogICANCiAgICAgICAgIGlm
ICggaW5mLT5zaG9ydF9ibG9ja19sb3N0X3RvdCApDQogICAgICAgICB7DQpAQCAtMTAwMiwyOCAr
OTQ3LDMwIEBAIHN0YXRpYyB2b2lkIHVuYmxvY2tfc2hvcnRfZXh0cmFfc3VwcG9ydCgNCiAgICAg
ICAgICAgICBpbmYtPnBlbl9leHRyYV9ibG9ja3MrKzsNCiAjZW5kaWYNCiAgICAgICAgICAgICBp
ZiAoIGV4dHJhcV9vbihpbmYtPnZjcHUsIEVYVFJBX1BFTl9RKSApDQotICAgICAgICAgICAgICAg
IC8qcmVtb3ZlIGRvbWFpbiBmb3IgcG9zc2libGUgcmVzb3J0aW5nISovDQorICAgICAgICAgICAg
ICAgIC8qIFJlbW92ZSBkb21haW4gZm9yIHBvc3NpYmxlIHJlc29ydGluZyEgKi8NCiAgICAgICAg
ICAgICAgICAgZXh0cmFxX2RlbChpbmYtPnZjcHUsIEVYVFJBX1BFTl9RKTsNCiAgICAgICAgICAg
ICBlbHNlDQotICAgICAgICAgICAgICAgIC8qcmVtZW1iZXIgdGhhdCB3ZSB3YW50IHRvIGJlIG9u
IHRoZSBwZW5hbHR5IHENCi0gICAgICAgICAgICAgICAgICBzbyB0aGF0IHdlIGNhbiBjb250aW51
ZSB3aGVuIHdlICh1bi0pYmxvY2sNCi0gICAgICAgICAgICAgICAgICBpbiBwZW5hbHR5LWV4dHJh
dGltZSovDQorICAgICAgICAgICAgICAgIC8qIFJlbWVtYmVyIHRoYXQgd2Ugd2FudCB0byBiZSBv
biB0aGUgcGVuYWx0eSBxDQorICAgICAgICAgICAgICAgICAqIHNvIHRoYXQgd2UgY2FuIGNvbnRp
bnVlIHdoZW4gd2UgKHVuLSlibG9jaw0KKyAgICAgICAgICAgICAgICAgKiBpbiBwZW5hbHR5LWV4
dHJhdGltZQ0KKyAgICAgICAgICAgICAgICAgKi8NCiAgICAgICAgICAgICAgICAgaW5mLT5zdGF0
dXMgfD0gRVhUUkFfV0FOVF9QRU5fUTsNCiAgICANCi0gICAgICAgICAgICAvKihyZS0pYWRkIGRv
bWFpbiB0byB0aGUgcGVuYWx0eSBleHRyYXEqLw0KKyAgICAgICAgICAgIC8qIChyZS0pYWRkIGRv
bWFpbiB0byB0aGUgcGVuYWx0eSBleHRyYXEgKi8NCiAgICAgICAgICAgICBleHRyYXFfYWRkX3Nv
cnRfdXBkYXRlKGluZi0+dmNwdSwgRVhUUkFfUEVOX1EsIDApOw0KICAgICAgICAgfQ0KICAgICB9
DQogDQotICAgIC8qZ2l2ZSBpdCBhIGZyZXNoIHNsaWNlIGluIHRoZSBuZXh0IHBlcmlvZCEqLw0K
KyAgICAvKiBHaXZlIGl0IGEgZnJlc2ggc2xpY2UgaW4gdGhlIG5leHQgcGVyaW9kISAqLw0KICAg
ICBpbmYtPmNwdXRpbWUgPSAwOw0KIH0NCiANCiANCiBzdGF0aWMgdm9pZCB1bmJsb2NrX2xvbmdf
Y29uc19iKHN0cnVjdCBzZWRmX3ZjcHVfaW5mbyogaW5mLHNfdGltZV90IG5vdykNCiB7DQotICAg
IC8qQ29uc2VydmF0aXZlIDJiKi8NCi0gICAgLypUcmVhdCB0aGUgdW5ibG9ja2luZyB0aW1lIGFz
IGEgc3RhcnQgb2YgYSBuZXcgcGVyaW9kICovDQorICAgIC8qIENvbnNlcnZhdGl2ZSAyYiAqLw0K
Kw0KKyAgICAvKiBUcmVhdCB0aGUgdW5ibG9ja2luZyB0aW1lIGFzIGEgc3RhcnQgb2YgYSBuZXcg
cGVyaW9kICovDQogICAgIGluZi0+ZGVhZGxfYWJzID0gbm93ICsgaW5mLT5wZXJpb2Q7DQogICAg
IGluZi0+Y3B1dGltZSA9IDA7DQogfQ0KQEAgLTEwNDYsMTUgKzk5MywxNiBAQCBzdGF0aWMgaW5s
aW5lIGludCBnZXRfcnVuX3R5cGUoc3RydWN0IHZjDQogfQ0KIA0KIA0KLS8qQ29tcGFyZXMgdHdv
IGRvbWFpbnMgaW4gdGhlIHJlbGF0aW9uIG9mIHdoZXRoZXIgdGhlIG9uZSBpcyBhbGxvd2VkIHRv
DQotICBpbnRlcnJ1cHQgdGhlIG90aGVycyBleGVjdXRpb24uDQotICBJdCByZXR1cm5zIHRydWUg
KCE9MCkgaWYgYSBzd2l0Y2ggdG8gdGhlIG90aGVyIGRvbWFpbiBpcyBnb29kLg0KLSAgQ3VycmVu
dCBQcmlvcml0eSBzY2hlbWUgaXMgYXMgZm9sbG93czoNCi0gICBFREYgPiBMMCAocGVuYWx0eSBi
YXNlZCkgZXh0cmEtdGltZSA+IA0KLSAgIEwxICh1dGlsaXphdGlvbikgZXh0cmEtdGltZSA+IGlk
bGUtZG9tYWluDQotICBJbiB0aGUgc2FtZSBjbGFzcyBwcmlvcml0aWVzIGFyZSBhc3NpZ25lZCBh
cyBmb2xsb3dpbmc6DQotICAgRURGOiBlYXJseSBkZWFkbGluZSA+IGxhdGUgZGVhZGxpbmUNCi0g
ICBMMCBleHRyYS10aW1lOiBsb3dlciBzY29yZSA+IGhpZ2hlciBzY29yZSovDQorLyogQ29tcGFy
ZXMgdHdvIGRvbWFpbnMgaW4gdGhlIHJlbGF0aW9uIG9mIHdoZXRoZXIgdGhlIG9uZSBpcyBhbGxv
d2VkIHRvDQorICogaW50ZXJydXB0IHRoZSBvdGhlcnMgZXhlY3V0aW9uLg0KKyAqIEl0IHJldHVy
bnMgdHJ1ZSAoIT0wKSBpZiBhIHN3aXRjaCB0byB0aGUgb3RoZXIgZG9tYWluIGlzIGdvb2QuDQor
ICogQ3VycmVudCBQcmlvcml0eSBzY2hlbWUgaXMgYXMgZm9sbG93czoNCisgKiAgRURGID4gTDAg
KHBlbmFsdHkgYmFzZWQpIGV4dHJhLXRpbWUgPiANCisgKiAgTDEgKHV0aWxpemF0aW9uKSBleHRy
YS10aW1lID4gaWRsZS1kb21haW4NCisgKiBJbiB0aGUgc2FtZSBjbGFzcyBwcmlvcml0aWVzIGFy
ZSBhc3NpZ25lZCBhcyBmb2xsb3dpbmc6DQorICogIEVERjogZWFybHkgZGVhZGxpbmUgPiBsYXRl
IGRlYWRsaW5lDQorICogIEwwIGV4dHJhLXRpbWU6IGxvd2VyIHNjb3JlID4gaGlnaGVyIHNjb3Jl
DQorICovDQogc3RhdGljIGlubGluZSBpbnQgc2hvdWxkX3N3aXRjaChzdHJ1Y3QgdmNwdSAqY3Vy
LA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgc3RydWN0IHZjcHUgKm90aGVyLA0K
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgc190aW1lX3Qgbm93KQ0KQEAgLTEwNjMs
MTkgKzEwMTEsMTkgQEAgc3RhdGljIGlubGluZSBpbnQgc2hvdWxkX3N3aXRjaChzdHJ1Y3Qgdg0K
ICAgICBjdXJfaW5mICAgPSBFRE9NX0lORk8oY3VyKTsNCiAgICAgb3RoZXJfaW5mID0gRURPTV9J
TkZPKG90aGVyKTsNCiAgDQotICAgIC8qIENoZWNrIHdoZXRoZXIgd2UgbmVlZCB0byBtYWtlIGFu
IGVhcmxpZXIgc2NoZWR1bGluZyBkZWNpc2lvbi4gKi8NCisgICAgLyogQ2hlY2sgd2hldGhlciB3
ZSBuZWVkIHRvIG1ha2UgYW4gZWFybGllciBzY2hlZHVsaW5nIGRlY2lzaW9uICovDQogICAgIGlm
ICggUEVSSU9EX0JFR0lOKG90aGVyX2luZikgPCANCiAgICAgICAgICBDUFVfSU5GTyhvdGhlci0+
cHJvY2Vzc29yKS0+Y3VycmVudF9zbGljZV9leHBpcmVzICkNCiAgICAgICAgIHJldHVybiAxOw0K
IA0KLSAgICAvKiBObyB0aW1pbmctYmFzZWQgc3dpdGNoZXMgbmVlZCB0byBiZSB0YWtlbiBpbnRv
IGFjY291bnQgaGVyZS4gKi8NCisgICAgLyogTm8gdGltaW5nLWJhc2VkIHN3aXRjaGVzIG5lZWQg
dG8gYmUgdGFrZW4gaW50byBhY2NvdW50IGhlcmUgKi8NCiAgICAgc3dpdGNoICggZ2V0X3J1bl90
eXBlKGN1cikgKQ0KICAgICB7DQogICAgIGNhc2UgRE9NQUlOX0VERjoNCi0gICAgICAgIC8qIERv
IG5vdCBpbnRlcnJ1cHQgYSBydW5uaW5nIEVERiBkb21haW4uICovDQorICAgICAgICAvKiBEbyBu
b3QgaW50ZXJydXB0IGEgcnVubmluZyBFREYgZG9tYWluICovDQogICAgICAgICByZXR1cm4gMDsN
CiAgICAgY2FzZSBET01BSU5fRVhUUkFfUEVOOg0KLSAgICAgICAgLyogQ2hlY2sgd2hldGhlciB3
ZSBhbHNvIHdhbnQgdGhlIEwwIGV4LXEgd2l0aCBsb3dlciBzY29yZS4gKi8NCisgICAgICAgIC8q
IENoZWNrIHdoZXRoZXIgd2UgYWxzbyB3YW50IHRoZSBMMCBleC1xIHdpdGggbG93ZXIgc2NvcmUg
Ki8NCiAgICAgICAgIHJldHVybiAoKG90aGVyX2luZi0+c3RhdHVzICYgRVhUUkFfV0FOVF9QRU5f
USkgJiYNCiAgICAgICAgICAgICAgICAgKG90aGVyX2luZi0+c2NvcmVbRVhUUkFfUEVOX1FdIDwg
DQogICAgICAgICAgICAgICAgICBjdXJfaW5mLT5zY29yZVtFWFRSQV9QRU5fUV0pKTsNCkBAIC0x
MDk2LDE4ICsxMDQ0LDExIEBAIHN0YXRpYyB2b2lkIHNlZGZfd2FrZShjb25zdCBzdHJ1Y3Qgc2No
ZWQNCiAgICAgc190aW1lX3QgICAgICAgICAgICAgIG5vdyA9IE5PVygpOw0KICAgICBzdHJ1Y3Qg
c2VkZl92Y3B1X2luZm8qIGluZiA9IEVET01fSU5GTyhkKTsNCiANCi0gICAgUFJJTlQoMywgInNl
ZGZfd2FrZSB3YXMgY2FsbGVkLCBkb21haW4taWQgJWkuJWlcbiIsZC0+ZG9tYWluLT5kb21haW5f
aWQsDQotICAgICAgICAgIGQtPnZjcHVfaWQpOw0KLQ0KICAgICBpZiAoIHVubGlrZWx5KGlzX2lk
bGVfdmNwdShkKSkgKQ0KICAgICAgICAgcmV0dXJuOw0KICAgIA0KICAgICBpZiAoIHVubGlrZWx5
KF9fdGFza19vbl9xdWV1ZShkKSkgKQ0KLSAgICB7DQotICAgICAgICBQUklOVCgzLCJcdGRvbWFp
biAlaS4laSBpcyBhbHJlYWR5IGluIHNvbWUgcXVldWVcbiIsDQotICAgICAgICAgICAgICBkLT5k
b21haW4tPmRvbWFpbl9pZCwgZC0+dmNwdV9pZCk7DQogICAgICAgICByZXR1cm47DQotICAgIH0N
CiANCiAgICAgQVNTRVJUKCFzZWRmX3J1bm5hYmxlKGQpKTsNCiAgICAgaW5mLT5zdGF0dXMgJj0g
flNFREZfQVNMRUVQOw0KQEAgLTExMTYsMjggKzEwNTcsMjQgQEAgc3RhdGljIHZvaWQgc2VkZl93
YWtlKGNvbnN0IHN0cnVjdCBzY2hlZA0KICANCiAgICAgaWYgKCB1bmxpa2VseShpbmYtPmRlYWRs
X2FicyA9PSAwKSApDQogICAgIHsNCi0gICAgICAgIC8qaW5pdGlhbCBzZXR1cCBvZiB0aGUgZGVh
ZGxpbmUqLw0KKyAgICAgICAgLyogSW5pdGlhbCBzZXR1cCBvZiB0aGUgZGVhZGxpbmUgKi8NCiAg
ICAgICAgIGluZi0+ZGVhZGxfYWJzID0gbm93ICsgaW5mLT5zbGljZTsNCiAgICAgfQ0KICAgDQot
ICAgIFBSSU5UKDMsICJ3YWtpbmcgdXAgZG9tYWluICVpLiVpIChkZWFkbD0gJSJQUkl1NjQiIHBl
cmlvZD0gJSJQUkl1NjQNCi0gICAgICAgICAgIm5vdz0gJSJQUkl1NjQiKVxuIiwNCi0gICAgICAg
ICAgZC0+ZG9tYWluLT5kb21haW5faWQsIGQtPnZjcHVfaWQsIGluZi0+ZGVhZGxfYWJzLCBpbmYt
PnBlcmlvZCwgbm93KTsNCi0NCiAjaWZkZWYgU0VERl9TVEFUUyANCiAgICAgaW5mLT5ibG9ja190
b3QrKzsNCiAjZW5kaWYNCiANCiAgICAgaWYgKCB1bmxpa2VseShub3cgPCBQRVJJT0RfQkVHSU4o
aW5mKSkgKQ0KICAgICB7DQotICAgICAgICBQUklOVCg0LCJleHRyYXRpbWUgdW5ibG9ja1xuIik7
DQotICAgICAgICAvKiB1bmJsb2NraW5nIGluIGV4dHJhLXRpbWUhICovDQorICAgICAgICAvKiBV
bmJsb2NraW5nIGluIGV4dHJhLXRpbWUhICovDQogICAgICAgICBpZiAoIGluZi0+c3RhdHVzICYg
RVhUUkFfV0FOVF9QRU5fUSApDQogICAgICAgICB7DQotICAgICAgICAgICAgLyp3ZSBoYXZlIGEg
ZG9tYWluIHRoYXQgd2FudHMgY29tcGVuc2F0aW9uDQotICAgICAgICAgICAgICBmb3IgYmxvY2sg
cGVuYWx0eSBhbmQgZGlkIGp1c3QgYmxvY2sgaW4NCi0gICAgICAgICAgICAgIGl0cyBjb21wZW5z
YXRpb24gdGltZS4gR2l2ZSBpdCBhbm90aGVyDQotICAgICAgICAgICAgICBjaGFuY2UhKi8NCisg
ICAgICAgICAgICAvKiBXZSBoYXZlIGEgZG9tYWluIHRoYXQgd2FudHMgY29tcGVuc2F0aW9uDQor
ICAgICAgICAgICAgICogZm9yIGJsb2NrIHBlbmFsdHkgYW5kIGRpZCBqdXN0IGJsb2NrIGluDQor
ICAgICAgICAgICAgICogaXRzIGNvbXBlbnNhdGlvbiB0aW1lLiBHaXZlIGl0IGFub3RoZXINCisg
ICAgICAgICAgICAgKiBjaGFuY2UhDQorICAgICAgICAgICAgICovDQogICAgICAgICAgICAgZXh0
cmFxX2FkZF9zb3J0X3VwZGF0ZShkLCBFWFRSQV9QRU5fUSwgMCk7DQogICAgICAgICB9DQogICAg
ICAgICBleHRyYXFfY2hlY2tfYWRkX3VuYmxvY2tlZChkLCAwKTsNCkBAIC0xMTQ2LDggKzEwODMs
NyBAQCBzdGF0aWMgdm9pZCBzZWRmX3dha2UoY29uc3Qgc3RydWN0IHNjaGVkDQogICAgIHsgIA0K
ICAgICAgICAgaWYgKCBub3cgPCBpbmYtPmRlYWRsX2FicyApDQogICAgICAgICB7DQotICAgICAg
ICAgICAgUFJJTlQoNCwic2hvcnQgdW5ibG9ja2luZ1xuIik7DQotICAgICAgICAgICAgLypzaG9y
dCBibG9ja2luZyovDQorICAgICAgICAgICAgLyogU2hvcnQgYmxvY2tpbmcgKi8NCiAjaWZkZWYg
U0VERl9TVEFUUw0KICAgICAgICAgICAgIGluZi0+c2hvcnRfYmxvY2tfdG90Kys7DQogI2VuZGlm
DQpAQCAtMTE1Nyw4ICsxMDkzLDcgQEAgc3RhdGljIHZvaWQgc2VkZl93YWtlKGNvbnN0IHN0cnVj
dCBzY2hlZA0KICAgICAgICAgfQ0KICAgICAgICAgZWxzZQ0KICAgICAgICAgew0KLSAgICAgICAg
ICAgIFBSSU5UKDQsImxvbmcgdW5ibG9ja2luZ1xuIik7DQotICAgICAgICAgICAgLypsb25nIHVu
YmxvY2tpbmcqLw0KKyAgICAgICAgICAgIC8qIExvbmcgdW5ibG9ja2luZyAqLw0KICNpZmRlZiBT
RURGX1NUQVRTDQogICAgICAgICAgICAgaW5mLT5sb25nX2Jsb2NrX3RvdCsrOw0KICNlbmRpZg0K
QEAgLTExNjgsMjQgKzExMDMsMTMgQEAgc3RhdGljIHZvaWQgc2VkZl93YWtlKGNvbnN0IHN0cnVj
dCBzY2hlZA0KICAgICAgICAgfQ0KICAgICB9DQogDQotICAgIFBSSU5UKDMsICJ3b2tlIHVwIGRv
bWFpbiAlaS4laSAoZGVhZGw9ICUiUFJJdTY0IiBwZXJpb2Q9ICUiUFJJdTY0DQotICAgICAgICAg
ICJub3c9ICUiUFJJdTY0IilcbiIsDQotICAgICAgICAgIGQtPmRvbWFpbi0+ZG9tYWluX2lkLCBk
LT52Y3B1X2lkLCBpbmYtPmRlYWRsX2FicywNCi0gICAgICAgICAgaW5mLT5wZXJpb2QsIG5vdyk7
DQotDQogICAgIGlmICggUEVSSU9EX0JFR0lOKGluZikgPiBub3cgKQ0KLSAgICB7DQogICAgICAg
ICBfX2FkZF90b193YWl0cXVldWVfc29ydChkKTsNCi0gICAgICAgIFBSSU5UKDMsImFkZGVkIHRv
IHdhaXRxXG4iKTsNCi0gICAgfQ0KICAgICBlbHNlDQotICAgIHsNCiAgICAgICAgIF9fYWRkX3Rv
X3J1bnF1ZXVlX3NvcnQoZCk7DQotICAgICAgICBQUklOVCgzLCJhZGRlZCB0byBydW5xXG4iKTsN
Ci0gICAgfQ0KICANCiAjaWZkZWYgU0VERl9TVEFUUw0KLSAgICAvKmRvIHNvbWUgc3RhdGlzdGlj
cyBoZXJlLi4uKi8NCisgICAgLyogRG8gc29tZSBzdGF0aXN0aWNzIGhlcmUuLi4gKi8NCiAgICAg
aWYgKCBpbmYtPmJsb2NrX2FicyAhPSAwICkNCiAgICAgew0KICAgICAgICAgaW5mLT5ibG9ja190
aW1lX3RvdCArPSBub3cgLSBpbmYtPmJsb2NrX2FiczsNCkBAIC0xMTk0LDEyICsxMTE4LDEzIEBA
IHN0YXRpYyB2b2lkIHNlZGZfd2FrZShjb25zdCBzdHJ1Y3Qgc2NoZWQNCiAgICAgfQ0KICNlbmRp
Zg0KIA0KLSAgICAvKnNhbml0eSBjaGVjazogbWFrZSBzdXJlIGVhY2ggZXh0cmEtYXdhcmUgZG9t
YWluIElTIG9uIHRoZSB1dGlsLXEhKi8NCisgICAgLyogU2FuaXR5IGNoZWNrOiBtYWtlIHN1cmUg
ZWFjaCBleHRyYS1hd2FyZSBkb21haW4gSVMgb24gdGhlIHV0aWwtcSEgKi8NCiAgICAgQVNTRVJU
KElNUExZKGluZi0+c3RhdHVzICYgRVhUUkFfQVdBUkUsIGV4dHJhcV9vbihkLCBFWFRSQV9VVElM
X1EpKSk7DQogICAgIEFTU0VSVChfX3Rhc2tfb25fcXVldWUoZCkpOw0KLSAgICAvKmNoZWNrIHdo
ZXRoZXIgdGhlIGF3YWtlbmVkIHRhc2sgbmVlZHMgdG8gaW52b2tlIHRoZSBkb19zY2hlZHVsZQ0K
LSAgICAgIHJvdXRpbmUuIFRyeSB0byBhdm9pZCB1bm5lY2Vzc2FyeSBydW5zIGJ1dDoNCi0gICAg
ICBTYXZlIGFwcHJveGltYXRpb246IEFsd2F5cyBzd2l0Y2ggdG8gc2NoZWR1bGVyISovDQorICAg
IC8qIENoZWNrIHdoZXRoZXIgdGhlIGF3YWtlbmVkIHRhc2sgbmVlZHMgdG8gaW52b2tlIHRoZSBk
b19zY2hlZHVsZQ0KKyAgICAgKiByb3V0aW5lLiBUcnkgdG8gYXZvaWQgdW5uZWNlc3NhcnkgcnVu
cyBidXQ6DQorICAgICAqIFNhdmUgYXBwcm94aW1hdGlvbjogQWx3YXlzIHN3aXRjaCB0byBzY2hl
ZHVsZXIhDQorICAgICAqLw0KICAgICBBU1NFUlQoZC0+cHJvY2Vzc29yID49IDApOw0KICAgICBB
U1NFUlQoZC0+cHJvY2Vzc29yIDwgbnJfY3B1X2lkcyk7DQogICAgIEFTU0VSVChwZXJfY3B1KHNj
aGVkdWxlX2RhdGEsIGQtPnByb2Nlc3NvcikuY3Vycik7DQpAQCAtMTI0NCw3ICsxMTY5LDcgQEAg
c3RhdGljIHZvaWQgc2VkZl9kdW1wX2RvbWFpbihzdHJ1Y3QgdmNwdQ0KIH0NCiANCiANCi0vKiBk
dW1wcyBhbGwgZG9tYWlucyBvbiB0aGUgc3BlY2lmaWVkIGNwdSAqLw0KKy8qIER1bXBzIGFsbCBk
b21haW5zIG9uIHRoZSBzcGVjaWZpZWQgY3B1ICovDQogc3RhdGljIHZvaWQgc2VkZl9kdW1wX2Nw
dV9zdGF0ZShjb25zdCBzdHJ1Y3Qgc2NoZWR1bGVyICpvcHMsIGludCBpKQ0KIHsNCiAgICAgc3Ry
dWN0IGxpc3RfaGVhZCAgICAgICpsaXN0LCAqcXVldWUsICp0bXA7DQpAQCAtMTMxOSw3ICsxMjQ0
LDcgQEAgc3RhdGljIHZvaWQgc2VkZl9kdW1wX2NwdV9zdGF0ZShjb25zdCBzdA0KIH0NCiANCiAN
Ci0vKiBBZGp1c3RzIHBlcmlvZHMgYW5kIHNsaWNlcyBvZiB0aGUgZG9tYWlucyBhY2NvcmRpbmds
eSB0byB0aGVpciB3ZWlnaHRzLiAqLw0KKy8qIEFkanVzdHMgcGVyaW9kcyBhbmQgc2xpY2VzIG9m
IHRoZSBkb21haW5zIGFjY29yZGluZ2x5IHRvIHRoZWlyIHdlaWdodHMgKi8NCiBzdGF0aWMgaW50
IHNlZGZfYWRqdXN0X3dlaWdodHMoc3RydWN0IGNwdXBvb2wgKmMsIHN0cnVjdCB4ZW5fZG9tY3Rs
X3NjaGVkdWxlcl9vcCAqY21kKQ0KIHsNCiAgICAgc3RydWN0IHZjcHUgKnA7DQpAQCAtMTMzNSw3
ICsxMjYwLDcgQEAgc3RhdGljIGludCBzZWRmX2FkanVzdF93ZWlnaHRzKHN0cnVjdCBjcA0KICAg
ICAgICAgcmV0dXJuIC1FTk9NRU07DQogICAgIH0NCiANCi0gICAgLyogU3VtIGFjcm9zcyBhbGwg
d2VpZ2h0cy4gKi8NCisgICAgLyogU3VtIGFjcm9zcyBhbGwgd2VpZ2h0cyAqLw0KICAgICByY3Vf
cmVhZF9sb2NrKCZkb21saXN0X3JlYWRfbG9jayk7DQogICAgIGZvcl9lYWNoX2RvbWFpbl9pbl9j
cHVwb29sKCBkLCBjICkNCiAgICAgew0KQEAgLTEzNTAsMTEgKzEyNzUsMTMgQEAgc3RhdGljIGlu
dCBzZWRmX2FkanVzdF93ZWlnaHRzKHN0cnVjdCBjcA0KICAgICAgICAgICAgIH0NCiAgICAgICAg
ICAgICBlbHNlDQogICAgICAgICAgICAgew0KLSAgICAgICAgICAgICAgICAvKmRvbid0IG1vZGlm
eSBkb21haW5zIHdobyBkb24ndCBoYXZlIGEgd2VpZ2h0LCBidXQgc3VtDQotICAgICAgICAgICAg
ICAgICAgdXAgdGhlIHRpbWUgdGhleSBuZWVkLCBwcm9qZWN0ZWQgdG8gYSBXRUlHSFRfUEVSSU9E
LA0KLSAgICAgICAgICAgICAgICAgIHNvIHRoYXQgdGhpcyB0aW1lIGlzIG5vdCBnaXZlbiB0byB0
aGUgd2VpZ2h0LWRyaXZlbg0KLSAgICAgICAgICAgICAgICAgIGRvbWFpbnMqLw0KLSAgICAgICAg
ICAgICAgICAvKmNoZWNrIGZvciBvdmVyZmxvd3MqLw0KKyAgICAgICAgICAgICAgICAvKiBEb24n
dCBtb2RpZnkgZG9tYWlucyB3aG8gZG9uJ3QgaGF2ZSBhIHdlaWdodCwgYnV0IHN1bQ0KKyAgICAg
ICAgICAgICAgICAgKiB1cCB0aGUgdGltZSB0aGV5IG5lZWQsIHByb2plY3RlZCB0byBhIFdFSUdI
VF9QRVJJT0QsDQorICAgICAgICAgICAgICAgICAqIHNvIHRoYXQgdGhpcyB0aW1lIGlzIG5vdCBn
aXZlbiB0byB0aGUgd2VpZ2h0LWRyaXZlbg0KKyAgICAgICAgICAgICAgICAgKiAgZG9tYWlucw0K
KyAgICAgICAgICAgICAgICAgKi8NCisNCisgICAgICAgICAgICAgICAgLyogQ2hlY2sgZm9yIG92
ZXJmbG93cyAqLw0KICAgICAgICAgICAgICAgICBBU1NFUlQoKFdFSUdIVF9QRVJJT0QgPCBVTE9O
R19NQVgpIA0KICAgICAgICAgICAgICAgICAgICAgICAgJiYgKEVET01fSU5GTyhwKS0+c2xpY2Vf
b3JpZyA8IFVMT05HX01BWCkpOw0KICAgICAgICAgICAgICAgICBzdW10W2NwdV0gKz0gDQpAQCAt
MTM2NSw3ICsxMjkyLDcgQEAgc3RhdGljIGludCBzZWRmX2FkanVzdF93ZWlnaHRzKHN0cnVjdCBj
cA0KICAgICB9DQogICAgIHJjdV9yZWFkX3VubG9jaygmZG9tbGlzdF9yZWFkX2xvY2spOw0KIA0K
LSAgICAvKiBBZGp1c3QgYWxsIHNsaWNlcyAoYW5kIHBlcmlvZHMpIHRvIHRoZSBuZXcgd2VpZ2h0
LiAqLw0KKyAgICAvKiBBZGp1c3QgYWxsIHNsaWNlcyAoYW5kIHBlcmlvZHMpIHRvIHRoZSBuZXcg
d2VpZ2h0ICovDQogICAgIHJjdV9yZWFkX2xvY2soJmRvbWxpc3RfcmVhZF9sb2NrKTsNCiAgICAg
Zm9yX2VhY2hfZG9tYWluX2luX2NwdXBvb2woIGQsIGMgKQ0KICAgICB7DQpAQCAtMTM5MywyMCAr
MTMyMCwxNSBAQCBzdGF0aWMgaW50IHNlZGZfYWRqdXN0X3dlaWdodHMoc3RydWN0IGNwDQogfQ0K
IA0KIA0KLS8qIHNldCBvciBmZXRjaCBkb21haW4gc2NoZWR1bGluZyBwYXJhbWV0ZXJzICovDQor
LyogU2V0IG9yIGZldGNoIGRvbWFpbiBzY2hlZHVsaW5nIHBhcmFtZXRlcnMgKi8NCiBzdGF0aWMg
aW50IHNlZGZfYWRqdXN0KGNvbnN0IHN0cnVjdCBzY2hlZHVsZXIgKm9wcywgc3RydWN0IGRvbWFp
biAqcCwgc3RydWN0IHhlbl9kb21jdGxfc2NoZWR1bGVyX29wICpvcCkNCiB7DQogICAgIHN0cnVj
dCB2Y3B1ICp2Ow0KICAgICBpbnQgcmM7DQogDQotICAgIFBSSU5UKDIsInNlZGZfYWRqdXN0IHdh
cyBjYWxsZWQsIGRvbWFpbi1pZCAlaSBuZXcgcGVyaW9kICUiUFJJdTY0IiAiDQotICAgICAgICAg
ICJuZXcgc2xpY2UgJSJQUkl1NjQiXG5sYXRlbmN5ICUiUFJJdTY0IiBleHRyYTolc1xuIiwNCi0g
ICAgICAgICAgcC0+ZG9tYWluX2lkLCBvcC0+dS5zZWRmLnBlcmlvZCwgb3AtPnUuc2VkZi5zbGlj
ZSwNCi0gICAgICAgICAgb3AtPnUuc2VkZi5sYXRlbmN5LCAob3AtPnUuc2VkZi5leHRyYXRpbWUp
PyJ5ZXMiOiJubyIpOw0KLQ0KICAgICBpZiAoIG9wLT5jbWQgPT0gWEVOX0RPTUNUTF9TQ0hFRE9Q
X3B1dGluZm8gKQ0KICAgICB7DQotICAgICAgICAvKiBDaGVjayBmb3Igc2FuZSBwYXJhbWV0ZXJz
LiAqLw0KKyAgICAgICAgLyogQ2hlY2sgZm9yIHNhbmUgcGFyYW1ldGVycyAqLw0KICAgICAgICAg
aWYgKCAhb3AtPnUuc2VkZi5wZXJpb2QgJiYgIW9wLT51LnNlZGYud2VpZ2h0ICkNCiAgICAgICAg
ICAgICByZXR1cm4gLUVJTlZBTDsNCiAgICAgICAgIGlmICggb3AtPnUuc2VkZi53ZWlnaHQgKQ0K
QEAgLTE0MTQsNyArMTMzNiw3IEBAIHN0YXRpYyBpbnQgc2VkZl9hZGp1c3QoY29uc3Qgc3RydWN0
IHNjaGUNCiAgICAgICAgICAgICBpZiAoIChvcC0+dS5zZWRmLmV4dHJhdGltZSAmIEVYVFJBX0FX
QVJFKSAmJg0KICAgICAgICAgICAgICAgICAgKCFvcC0+dS5zZWRmLnBlcmlvZCkgKQ0KICAgICAg
ICAgICAgIHsNCi0gICAgICAgICAgICAgICAgLyogV2VpZ2h0LWRyaXZlbiBkb21haW5zIHdpdGgg
ZXh0cmF0aW1lIG9ubHkuICovDQorICAgICAgICAgICAgICAgIC8qIFdlaWdodC1kcml2ZW4gZG9t
YWlucyB3aXRoIGV4dHJhdGltZSBvbmx5ICovDQogICAgICAgICAgICAgICAgIGZvcl9lYWNoX3Zj
cHUgKCBwLCB2ICkNCiAgICAgICAgICAgICAgICAgew0KICAgICAgICAgICAgICAgICAgICAgRURP
TV9JTkZPKHYpLT5leHRyYXdlaWdodCA9IG9wLT51LnNlZGYud2VpZ2h0Ow0KQEAgLTE0MjUsNyAr
MTM0Nyw3IEBAIHN0YXRpYyBpbnQgc2VkZl9hZGp1c3QoY29uc3Qgc3RydWN0IHNjaGUNCiAgICAg
ICAgICAgICB9DQogICAgICAgICAgICAgZWxzZQ0KICAgICAgICAgICAgIHsNCi0gICAgICAgICAg
ICAgICAgLyogV2VpZ2h0LWRyaXZlbiBkb21haW5zIHdpdGggcmVhbC10aW1lIGV4ZWN1dGlvbi4g
Ki8NCisgICAgICAgICAgICAgICAgLyogV2VpZ2h0LWRyaXZlbiBkb21haW5zIHdpdGggcmVhbC10
aW1lIGV4ZWN1dGlvbiAqLw0KICAgICAgICAgICAgICAgICBmb3JfZWFjaF92Y3B1ICggcCwgdiAp
DQogICAgICAgICAgICAgICAgICAgICBFRE9NX0lORk8odiktPndlaWdodCA9IG9wLT51LnNlZGYu
d2VpZ2h0Ow0KICAgICAgICAgICAgIH0NCkBAIC0xNDM1LDggKzEzNTcsNyBAQCBzdGF0aWMgaW50
IHNlZGZfYWRqdXN0KGNvbnN0IHN0cnVjdCBzY2hlDQogICAgICAgICAgICAgLyogVGltZS1kcml2
ZW4gZG9tYWlucy4gKi8NCiAgICAgICAgICAgICBmb3JfZWFjaF92Y3B1ICggcCwgdiApDQogICAg
ICAgICAgICAgew0KLSAgICAgICAgICAgICAgICAvKg0KLSAgICAgICAgICAgICAgICAgKiBTYW5p
dHkgY2hlY2tpbmc6IG5vdGUgdGhhdCBkaXNhYmxpbmcgZXh0cmEgd2VpZ2h0IHJlcXVpcmVzDQor
ICAgICAgICAgICAgICAgIC8qIFNhbml0eSBjaGVja2luZzogbm90ZSB0aGF0IGRpc2FibGluZyBl
eHRyYSB3ZWlnaHQgcmVxdWlyZXMNCiAgICAgICAgICAgICAgICAgICogdGhhdCB3ZSBzZXQgYSBu
b24temVybyBzbGljZS4NCiAgICAgICAgICAgICAgICAgICovDQogICAgICAgICAgICAgICAgIGlm
ICggKG9wLT51LnNlZGYucGVyaW9kID4gUEVSSU9EX01BWCkgfHwNCkBAIC0xNDc3LDcgKzEzOTgs
NiBAQCBzdGF0aWMgaW50IHNlZGZfYWRqdXN0KGNvbnN0IHN0cnVjdCBzY2hlDQogICAgICAgICBv
cC0+dS5zZWRmLndlaWdodCAgICA9IEVET01fSU5GTyhwLT52Y3B1WzBdKS0+d2VpZ2h0Ow0KICAg
ICB9DQogDQotICAgIFBSSU5UKDIsInNlZGZfYWRqdXN0X2ZpbmlzaGVkXG4iKTsNCiAgICAgcmV0
dXJuIDA7DQogfQ0KIA0K


--=-SQC3wUYrGGqGq8T7E3BQ--

--=-ByODJfHW+wcj4VSHJBM9
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEABECAAYFAk7xk7cACgkQk4XaBE3IOsTscACfeUsCDNw37zRR1IfIwxPK5lKK
/10An06jJC22XSm/UKSek9Fh+w8ihcr8
=7Rxx
-----END PGP SIGNATURE-----

--=-ByODJfHW+wcj4VSHJBM9--



--===============7346677379948124988==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============7346677379948124988==--



From xen-devel-bounces@lists.xensource.com Wed Dec 21 08:08:46 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 08: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.xensource.com>)
	id 1RdHDh-0002dk-6Q; Wed, 21 Dec 2011 08:08:13 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1RdHDf-0002dY-81
	for xen-devel@lists.xensource.com; Wed, 21 Dec 2011 08:08:11 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-12.tower-21.messagelabs.com!1324454881!8924721!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=1.1 required=7.0 tests=BODY_RANDOM_LONG,DIET_1
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28948 invoked from network); 21 Dec 2011 08:08:01 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-12.tower-21.messagelabs.com with SMTP;
	21 Dec 2011 08:08:01 -0000
Received: from [62.94.181.91] (account d.faggioli@sssup.it HELO [192.168.0.40])
	by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 74071203; Wed, 21 Dec 2011 09:07:59 +0100
Message-ID: <1324454839.2682.1.camel@Solace>
From: Dario Faggioli <raistlin@linux.it>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Wed, 21 Dec 2011 09:07:19 +0100
X-Mailer: Evolution 3.2.2-1 
Mime-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>, Keir Fraser <keir@xen.org>
Subject: [Xen-devel] [PATCH] sedf: remove useless tracing printk and
 harmonize comments style.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============7346677379948124988=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--===============7346677379948124988==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-ByODJfHW+wcj4VSHJBM9"


--=-ByODJfHW+wcj4VSHJBM9
Content-Type: multipart/mixed; boundary="=-SQC3wUYrGGqGq8T7E3BQ"


--=-SQC3wUYrGGqGq8T7E3BQ
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

sched_sedf.c used o have its own mechanism for producing tracing-alike
kind of information (domain block, wakeup, etc.). Nowadays, with an even
not so high number of pCPUs/vCPUs, just trying to enable this makes
the serial console completely unusable, produces tons of very hard to
parse and interpreet logging and can easily livelock Dom0. Moreover,
pretty much the same result this is struggling to get to, is better
achieved by enabling the scheduler-related tracing events, as
it is for the other schedulers (say, credit or credit2).

For all these reasons, this removes that machinery completely. While at
it, check in some cosmetics that harmonize the comments withim themself
and with the rest of the code base.

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>

diff -r 17d99691e0ec xen/common/sched_sedf.c
--- a/xen/common/sched_sedf.c	Tue Dec 20 16:39:56 2011 +0000
+++ b/xen/common/sched_sedf.c	Tue Dec 20 17:32:52 2011 +0000
@@ -13,14 +13,6 @@
 #include <xen/time.h>
 #include <xen/errno.h>
=20
-/*verbosity settings*/
-#define SEDFLEVEL 0
-#define PRINT(_f, _a...)                        \
-    do {                                        \
-        if ( (_f) <=3D SEDFLEVEL )                \
-            printk(_a );                        \
-    } while ( 0 )
-
 #define SEDF_CPUONLINE(_pool)                                             =
\
     (((_pool) =3D=3D NULL) ? &cpupool_free_cpus : (_pool)->cpu_valid)
=20
@@ -66,34 +58,35 @@ struct sedf_vcpu_info {
     struct list_head list;
     struct list_head extralist[2];
 =20
-    /*Parameters for EDF*/
-    s_time_t  period;  /*=3D(relative deadline)*/
-    s_time_t  slice;  /*=3Dworst case execution time*/
+    /* Parameters for EDF */
+    s_time_t  period;  /* =3D(relative deadline) */
+    s_time_t  slice;   /* =3Dworst case execution time */
 =20
-    /*Advaced Parameters*/
-    /*Latency Scaling*/
+    /* Advaced Parameters */
+
+    /* Latency Scaling */
     s_time_t  period_orig;
     s_time_t  slice_orig;
     s_time_t  latency;
 =20
-    /*status of domain*/
+    /* Status of domain */
     int       status;
-    /*weights for "Scheduling for beginners/ lazy/ etc." ;)*/
+    /* Weights for "Scheduling for beginners/ lazy/ etc." ;) */
     short     weight;
     short     extraweight;
-    /*Bookkeeping*/
+    /* Bookkeeping */
     s_time_t  deadl_abs;
     s_time_t  sched_start_abs;
     s_time_t  cputime;
-    /* times the domain un-/blocked */
+    /* Times the domain un-/blocked */
     s_time_t  block_abs;
     s_time_t  unblock_abs;
 =20
-    /*scores for {util, block penalty}-weighted extratime distribution*/
+    /* Scores for {util, block penalty}-weighted extratime distribution */
     int   score[2];
     s_time_t  short_block_lost_tot;
 =20
-    /*Statistics*/
+    /* Statistics */
     s_time_t  extra_time_tot;
=20
 #ifdef SEDF_STATS
@@ -158,18 +151,16 @@ static inline void extraq_del(struct vcp
 {
     struct list_head *list =3D EXTRALIST(d,i);
     ASSERT(extraq_on(d,i));
-    PRINT(3, "Removing domain %i.%i from L%i extraq\n",
-          d->domain->domain_id, d->vcpu_id, i);
     list_del(list);
     list->next =3D NULL;
     ASSERT(!extraq_on(d, i));
 }
=20
-/* adds a domain to the queue of processes which are aware of extra time. =
List
-   is sorted by score, where a lower score means higher priority for an ex=
tra
-   slice. It also updates the score, by simply subtracting a fixed value f=
rom
-   each entry, in order to avoid overflow. The algorithm works by simply
-   charging each domain that recieved extratime with an inverse of its wei=
ght.
+/* Adds a domain to the queue of processes which are aware of extra time. =
List
+ * is sorted by score, where a lower score means higher priority for an ex=
tra
+ * slice. It also updates the score, by simply subtracting a fixed value f=
rom
+ * each entry, in order to avoid overflow. The algorithm works by simply
+ * charging each domain that recieved extratime with an inverse of its wei=
ght.
  */=20
 static inline void extraq_add_sort_update(struct vcpu *d, int i, int sub)
 {
@@ -178,13 +169,7 @@ static inline void extraq_add_sort_updat
 =20
     ASSERT(!extraq_on(d,i));
=20
-    PRINT(3, "Adding domain %i.%i (score=3D %i, short_pen=3D %"PRIi64")"
-          " to L%i extraq\n",
-          d->domain->domain_id, d->vcpu_id, EDOM_INFO(d)->score[i],
-          EDOM_INFO(d)->short_block_lost_tot, i);
-
-    /*
-     * Iterate through all elements to find our "hole" and on our way
+    /* Iterate through all elements to find our "hole" and on our way
      * update all the other scores.
      */
     list_for_each ( cur, EXTRAQ(d->processor, i) )
@@ -193,25 +178,18 @@ static inline void extraq_add_sort_updat
         curinf->score[i] -=3D sub;
         if ( EDOM_INFO(d)->score[i] < curinf->score[i] )
             break;
-        PRINT(4,"\tbehind domain %i.%i (score=3D %i)\n",
-              curinf->vcpu->domain->domain_id,
-              curinf->vcpu->vcpu_id, curinf->score[i]);
     }
=20
-    /* cur now contains the element, before which we'll enqueue. */
-    PRINT(3, "\tlist_add to %p\n", cur->prev);
+    /* cur now contains the element, before which we'll enqueue */
     list_add(EXTRALIST(d,i),cur->prev);
 =20
-    /* Continue updating the extraq. */
+    /* Continue updating the extraq */
     if ( (cur !=3D EXTRAQ(d->processor,i)) && sub )
     {
         for ( cur =3D cur->next; cur !=3D EXTRAQ(d->processor,i); cur =3D =
cur->next )
         {
             curinf =3D list_entry(cur,struct sedf_vcpu_info, extralist[i])=
;
             curinf->score[i] -=3D sub;
-            PRINT(4, "\tupdating domain %i.%i (score=3D %u)\n",
-                  curinf->vcpu->domain->domain_id,=20
-                  curinf->vcpu->vcpu_id, curinf->score[i]);
         }
     }
=20
@@ -221,29 +199,14 @@ static inline void extraq_check(struct v
 {
     if ( extraq_on(d, EXTRA_UTIL_Q) )
     {
-        PRINT(2,"Dom %i.%i is on L1 extraQ\n",
-              d->domain->domain_id, d->vcpu_id);
-
         if ( !(EDOM_INFO(d)->status & EXTRA_AWARE) &&
              !extra_runs(EDOM_INFO(d)) )
-        {
             extraq_del(d, EXTRA_UTIL_Q);
-            PRINT(2,"Removed dom %i.%i from L1 extraQ\n",
-                  d->domain->domain_id, d->vcpu_id);
-        }
     }
     else
     {
-        PRINT(2, "Dom %i.%i is NOT on L1 extraQ\n",
-              d->domain->domain_id,
-              d->vcpu_id);
-
         if ( (EDOM_INFO(d)->status & EXTRA_AWARE) && sedf_runnable(d) )
-        {
             extraq_add_sort_update(d, EXTRA_UTIL_Q, 0);
-            PRINT(2,"Added dom %i.%i to L1 extraQ\n",
-                  d->domain->domain_id, d->vcpu_id);
-        }
     }
 }
=20
@@ -252,7 +215,7 @@ static inline void extraq_check_add_unbl
     struct sedf_vcpu_info *inf =3D EDOM_INFO(d);
=20
     if ( inf->status & EXTRA_AWARE )
-        /* Put on the weighted extraq without updating any scores. */
+        /* Put on the weighted extraq without updating any scores */
         extraq_add_sort_update(d, EXTRA_UTIL_Q, 0);
 }
=20
@@ -265,8 +228,6 @@ static inline void __del_from_queue(stru
 {
     struct list_head *list =3D LIST(d);
     ASSERT(__task_on_queue(d));
-    PRINT(3,"Removing domain %i.%i (bop=3D %"PRIu64") from runq/waitq\n",
-          d->domain->domain_id, d->vcpu_id, PERIOD_BEGIN(EDOM_INFO(d)));
     list_del(list);
     list->next =3D NULL;
     ASSERT(!__task_on_queue(d));
@@ -279,13 +240,12 @@ static inline void list_insert_sort(
 {
     struct list_head     *cur;
=20
-    /* Iterate through all elements to find our "hole". */
+    /* Iterate through all elements to find our "hole" */
     list_for_each( cur, list )
         if ( comp(element, cur) < 0 )
             break;
=20
-    /* cur now contains the element, before which we'll enqueue. */
-    PRINT(3,"\tlist_add to %p\n",cur->prev);
+    /* cur now contains the element, before which we'll enqueue */
     list_add(element, cur->prev);
 }
=20
@@ -303,30 +263,26 @@ static int name##_comp(struct list_head*
         return 1;                                                       \
 }
=20
-/* adds a domain to the queue of processes which wait for the beginning of=
 the
-   next period; this list is therefore sortet by this time, which is simpl=
y
-   absol. deadline - period
+/* Adds a domain to the queue of processes which wait for the beginning of=
 the
+ * next period; this list is therefore sortet by this time, which is simpl=
y
+ * absol. deadline - period.
  */=20
 DOMAIN_COMPARER(waitq, list, PERIOD_BEGIN(d1), PERIOD_BEGIN(d2));
 static inline void __add_to_waitqueue_sort(struct vcpu *v)
 {
     ASSERT(!__task_on_queue(v));
-    PRINT(3,"Adding domain %i.%i (bop=3D %"PRIu64") to waitq\n",
-          v->domain->domain_id, v->vcpu_id, PERIOD_BEGIN(EDOM_INFO(v)));
     list_insert_sort(WAITQ(v->processor), LIST(v), waitq_comp);
     ASSERT(__task_on_queue(v));
 }
=20
-/* adds a domain to the queue of processes which have started their curren=
t
-   period and are runnable (i.e. not blocked, dieing,...). The first eleme=
nt
-   on this list is running on the processor, if the list is empty the idle
-   task will run. As we are implementing EDF, this list is sorted by deadl=
ines.
+/* Adds a domain to the queue of processes which have started their curren=
t
+ * period and are runnable (i.e. not blocked, dieing,...). The first eleme=
nt
+ * on this list is running on the processor, if the list is empty the idle
+ * task will run. As we are implementing EDF, this list is sorted by deadl=
ines.
  */=20
 DOMAIN_COMPARER(runq, list, d1->deadl_abs, d2->deadl_abs);
 static inline void __add_to_runqueue_sort(struct vcpu *v)
 {
-    PRINT(3,"Adding domain %i.%i (deadl=3D %"PRIu64") to runq\n",
-          v->domain->domain_id, v->vcpu_id, EDOM_INFO(v)->deadl_abs);
     list_insert_sort(RUNQ(v->processor), LIST(v), runq_comp);
 }
=20
@@ -445,22 +401,21 @@ static int sedf_pick_cpu(const struct sc
     return cpumask_first(&online_affinity);
 }
=20
-/*
- * Handles the rescheduling & bookkeeping of domains running in their
+
+/* Handles the rescheduling & bookkeeping of domains running in their
  * guaranteed timeslice.
  */
 static void desched_edf_dom(s_time_t now, struct vcpu* d)
 {
     struct sedf_vcpu_info* inf =3D EDOM_INFO(d);
=20
-    /* Current domain is running in real time mode. */
+    /* Current domain is running in real time mode */
     ASSERT(__task_on_queue(d));
=20
-    /* Update the domain's cputime. */
+    /* Update the domain's cputime */
     inf->cputime +=3D now - inf->sched_start_abs;
=20
-    /*
-     * Scheduling decisions which don't remove the running domain from the
+    /* Scheduling decisions which don't remove the running domain from the
      * runq.=20
      */
     if ( (inf->cputime < inf->slice) && sedf_runnable(d) )
@@ -468,8 +423,7 @@ static void desched_edf_dom(s_time_t now
  =20
     __del_from_queue(d);
  =20
-    /*
-     * Manage bookkeeping (i.e. calculate next deadline, memorise
+    /* Manage bookkeeping (i.e. calculate next deadline, memorise
      * overrun-time of slice) of finished domains.
      */
     if ( inf->cputime >=3D inf->slice )
@@ -478,30 +432,30 @@ static void desched_edf_dom(s_time_t now
  =20
         if ( inf->period < inf->period_orig )
         {
-            /* This domain runs in latency scaling or burst mode. */
+            /* This domain runs in latency scaling or burst mode */
             inf->period *=3D 2;
             inf->slice  *=3D 2;
             if ( (inf->period > inf->period_orig) ||
                  (inf->slice > inf->slice_orig) )
             {
-                /* Reset slice and period. */
+                /* Reset slice and period */
                 inf->period =3D inf->period_orig;
                 inf->slice =3D inf->slice_orig;
             }
         }
=20
-        /* Set next deadline. */
+        /* Set next deadline */
         inf->deadl_abs +=3D inf->period;
     }
 =20
-    /* Add a runnable domain to the waitqueue. */
+    /* Add a runnable domain to the waitqueue */
     if ( sedf_runnable(d) )
     {
         __add_to_waitqueue_sort(d);
     }
     else
     {
-        /* We have a blocked realtime task -> remove it from exqs too. */
+        /* We have a blocked realtime task -> remove it from exqs too */
         if ( extraq_on(d, EXTRA_PEN_Q) )
             extraq_del(d, EXTRA_PEN_Q);
         if ( extraq_on(d, EXTRA_UTIL_Q) )
@@ -521,73 +475,59 @@ static void update_queues(
     struct list_head     *cur, *tmp;
     struct sedf_vcpu_info *curinf;
 =20
-    PRINT(3,"Updating waitq..\n");
-
-    /*
-     * Check for the first elements of the waitqueue, whether their
+    /* Check for the first elements of the waitqueue, whether their
      * next period has already started.
      */
     list_for_each_safe ( cur, tmp, waitq )
     {
         curinf =3D list_entry(cur, struct sedf_vcpu_info, list);
-        PRINT(4,"\tLooking @ dom %i.%i\n",
-              curinf->vcpu->domain->domain_id, curinf->vcpu->vcpu_id);
         if ( PERIOD_BEGIN(curinf) > now )
             break;
         __del_from_queue(curinf->vcpu);
         __add_to_runqueue_sort(curinf->vcpu);
     }
 =20
-    PRINT(3,"Updating runq..\n");
-
-    /* Process the runq, find domains that are on the runq that shouldn't.=
 */
+    /* Process the runq, find domains that are on the runq that shouldn't =
*/
     list_for_each_safe ( cur, tmp, runq )
     {
         curinf =3D list_entry(cur,struct sedf_vcpu_info,list);
-        PRINT(4,"\tLooking @ dom %i.%i\n",
-              curinf->vcpu->domain->domain_id, curinf->vcpu->vcpu_id);
=20
         if ( unlikely(curinf->slice =3D=3D 0) )
         {
-            /* Ignore domains with empty slice. */
-            PRINT(4,"\tUpdating zero-slice domain %i.%i\n",
-                  curinf->vcpu->domain->domain_id,
-                  curinf->vcpu->vcpu_id);
+            /* Ignore domains with empty slice */
             __del_from_queue(curinf->vcpu);
=20
-            /* Move them to their next period. */
+            /* Move them to their next period */
             curinf->deadl_abs +=3D curinf->period;
=20
-            /* Ensure that the start of the next period is in the future. =
*/
+            /* Ensure that the start of the next period is in the future *=
/
             if ( unlikely(PERIOD_BEGIN(curinf) < now) )
                 curinf->deadl_abs +=3D=20
                     (DIV_UP(now - PERIOD_BEGIN(curinf),
                             curinf->period)) * curinf->period;
=20
-            /* Put them back into the queue. */
+            /* Put them back into the queue */
             __add_to_waitqueue_sort(curinf->vcpu);
         }
         else if ( unlikely((curinf->deadl_abs < now) ||
                            (curinf->cputime > curinf->slice)) )
         {
-            /*
-             * We missed the deadline or the slice was already finished.
+            /* We missed the deadline or the slice was already finished.
              * Might hapen because of dom_adj.
              */
-            PRINT(4,"\tDomain %i.%i exceeded it's deadline/"
-                  "slice (%"PRIu64" / %"PRIu64") now: %"PRIu64
-                  " cputime: %"PRIu64"\n",
-                  curinf->vcpu->domain->domain_id,
-                  curinf->vcpu->vcpu_id,
-                  curinf->deadl_abs, curinf->slice, now,
-                  curinf->cputime);
+            printk("\tDomain %i.%i exceeded it's deadline/"
+                   "slice (%"PRIu64" / %"PRIu64") now: %"PRIu64
+                   " cputime: %"PRIu64"\n",
+                   curinf->vcpu->domain->domain_id,
+                   curinf->vcpu->vcpu_id,
+                   curinf->deadl_abs, curinf->slice, now,
+                   curinf->cputime);
             __del_from_queue(curinf->vcpu);
=20
-            /* Common case: we miss one period. */
+            /* Common case: we miss one period */
             curinf->deadl_abs +=3D curinf->period;
   =20
-            /*
-             * If we are still behind: modulo arithmetic, force deadline
+            /* If we are still behind: modulo arithmetic, force deadline
              * to be in future and aligned to period borders.
              */
             if ( unlikely(curinf->deadl_abs < now) )
@@ -596,7 +536,7 @@ static void update_queues(
                            curinf->period) * curinf->period;
             ASSERT(curinf->deadl_abs >=3D now);
=20
-            /* Give a fresh slice. */
+            /* Give a fresh slice */
             curinf->cputime =3D 0;
             if ( PERIOD_BEGIN(curinf) > now )
                 __add_to_waitqueue_sort(curinf->vcpu);
@@ -606,17 +546,16 @@ static void update_queues(
         else
             break;
     }
-
-    PRINT(3,"done updating the queues\n");
 }
=20

 /* removes a domain from the head of the according extraQ and
-   requeues it at a specified position:
-     round-robin extratime: end of extraQ
-     weighted ext.: insert in sorted list by score
-   if the domain is blocked / has regained its short-block-loss
-   time it is not put on any queue */
+ * requeues it at a specified position:
+ *   round-robin extratime: end of extraQ
+ *   weighted ext.: insert in sorted list by score
+ * if the domain is blocked / has regained its short-block-loss
+ * time it is not put on any queue.
+ */
 static void desched_extra_dom(s_time_t now, struct vcpu *d)
 {
     struct sedf_vcpu_info *inf =3D EDOM_INFO(d);
@@ -625,29 +564,25 @@ static void desched_extra_dom(s_time_t n
=20
     ASSERT(extraq_on(d, i));
=20
-    /* Unset all running flags. */
+    /* Unset all running flags */
     inf->status  &=3D ~(EXTRA_RUN_PEN | EXTRA_RUN_UTIL);
-    /* Fresh slice for the next run. */
+    /* Fresh slice for the next run */
     inf->cputime =3D 0;
-    /* Accumulate total extratime. */
+    /* Accumulate total extratime */
     inf->extra_time_tot +=3D now - inf->sched_start_abs;
     /* Remove extradomain from head of the queue. */
     extraq_del(d, i);
=20
-    /* Update the score. */
+    /* Update the score */
     oldscore =3D inf->score[i];
     if ( i =3D=3D EXTRA_PEN_Q )
     {
-        /*domain was running in L0 extraq*/
-        /*reduce block lost, probably more sophistication here!*/
+        /* Domain was running in L0 extraq */
+        /* reduce block lost, probably more sophistication here!*/
         /*inf->short_block_lost_tot -=3D EXTRA_QUANTUM;*/
         inf->short_block_lost_tot -=3D now - inf->sched_start_abs;
-        PRINT(3,"Domain %i.%i: Short_block_loss: %"PRIi64"\n",=20
-              inf->vcpu->domain->domain_id, inf->vcpu->vcpu_id,
-              inf->short_block_lost_tot);
 #if 0
-        /*
-         * KAF: If we don't exit short-blocking state at this point
+        /* KAF: If we don't exit short-blocking state at this point
          * domain0 can steal all CPU for up to 10 seconds before
          * scheduling settles down (when competing against another
          * CPU-bound domain). Doing this seems to make things behave
@@ -656,51 +591,56 @@ static void desched_extra_dom(s_time_t n
         if ( inf->short_block_lost_tot <=3D 0 )
 #endif
         {
-            PRINT(4,"Domain %i.%i compensated short block loss!\n",
-                  inf->vcpu->domain->domain_id, inf->vcpu->vcpu_id);
-            /*we have (over-)compensated our block penalty*/
+            /* We have (over-)compensated our block penalty */
             inf->short_block_lost_tot =3D 0;
-            /*we don't want a place on the penalty queue anymore!*/
+            /* We don't want a place on the penalty queue anymore! */
             inf->status &=3D ~EXTRA_WANT_PEN_Q;
             goto check_extra_queues;
         }
=20
-        /*we have to go again for another try in the block-extraq,
-          the score is not used incremantally here, as this is
-          already done by recalculating the block_lost*/
+        /* We have to go again for another try in the block-extraq,
+         * the score is not used incremantally here, as this is
+         * already done by recalculating the block_lost
+         */
         inf->score[EXTRA_PEN_Q] =3D (inf->period << 10) /
             inf->short_block_lost_tot;
         oldscore =3D 0;
     }
     else
     {
-        /*domain was running in L1 extraq =3D> score is inverse of
-          utilization and is used somewhat incremental!*/
+        /* Domain was running in L1 extraq =3D> score is inverse of
+         * utilization and is used somewhat incremental!
+         */
         if ( !inf->extraweight )
-            /*NB: use fixed point arithmetic with 10 bits*/
+        {
+            /* NB: use fixed point arithmetic with 10 bits */
             inf->score[EXTRA_UTIL_Q] =3D (inf->period << 10) /
                 inf->slice;
+        }
         else
-            /*conversion between realtime utilisation and extrawieght:
-              full (ie 100%) utilization is equivalent to 128 extraweight*=
/
+        {
+            /* Conversion between realtime utilisation and extrawieght:
+             * full (ie 100%) utilization is equivalent to 128 extraweight
+             */
             inf->score[EXTRA_UTIL_Q] =3D (1<<17) / inf->extraweight;
+        }
     }
=20
  check_extra_queues:
-    /* Adding a runnable domain to the right queue and removing blocked on=
es*/
+    /* Adding a runnable domain to the right queue and removing blocked on=
es */
     if ( sedf_runnable(d) )
     {
-        /*add according to score: weighted round robin*/
+        /* Add according to score: weighted round robin */
         if (((inf->status & EXTRA_AWARE) && (i =3D=3D EXTRA_UTIL_Q)) ||
             ((inf->status & EXTRA_WANT_PEN_Q) && (i =3D=3D EXTRA_PEN_Q)))
             extraq_add_sort_update(d, i, oldscore);
     }
     else
     {
-        /*remove this blocked domain from the waitq!*/
+        /* Remove this blocked domain from the waitq! */
         __del_from_queue(d);
-        /*make sure that we remove a blocked domain from the other
-          extraq too*/
+        /* Make sure that we remove a blocked domain from the other
+         * extraq too. */
         if ( i =3D=3D EXTRA_PEN_Q )
         {
             if ( extraq_on(d, EXTRA_UTIL_Q) )
@@ -732,8 +672,9 @@ static struct task_slice sedf_do_extra_s
=20
     if ( !list_empty(extraq[EXTRA_PEN_Q]) )
     {
-        /*we still have elements on the level 0 extraq=20
-          =3D> let those run first!*/
+        /* We still have elements on the level 0 extraq
+         * =3D> let those run first!
+         */
         runinf   =3D list_entry(extraq[EXTRA_PEN_Q]->next,=20
                               struct sedf_vcpu_info, extralist[EXTRA_PEN_Q=
]);
         runinf->status |=3D EXTRA_RUN_PEN;
@@ -747,7 +688,7 @@ static struct task_slice sedf_do_extra_s
     {
         if ( !list_empty(extraq[EXTRA_UTIL_Q]) )
         {
-            /*use elements from the normal extraqueue*/
+            /* Use elements from the normal extraqueue */
             runinf   =3D list_entry(extraq[EXTRA_UTIL_Q]->next,
                                   struct sedf_vcpu_info,
                                   extralist[EXTRA_UTIL_Q]);
@@ -773,10 +714,11 @@ static struct task_slice sedf_do_extra_s
=20

 /* Main scheduling function
-   Reasons for calling this function are:
-   -timeslice for the current period used up
-   -domain on waitqueue has started it's period
-   -and various others ;) in general: determine which domain to run next*/
+ * Reasons for calling this function are:
+ * -timeslice for the current period used up
+ * -domain on waitqueue has started it's period
+ * -and various others ;) in general: determine which domain to run next
+ */
 static struct task_slice sedf_do_schedule(
     const struct scheduler *ops, s_time_t now, bool_t tasklet_work_schedul=
ed)
 {
@@ -789,13 +731,14 @@ static struct task_slice sedf_do_schedul
     struct sedf_vcpu_info *runinf, *waitinf;
     struct task_slice      ret;
=20
-    /*idle tasks don't need any of the following stuf*/
+    /* Idle tasks don't need any of the following stuf */
     if ( is_idle_vcpu(current) )
         goto check_waitq;
 =20
-    /* create local state of the status of the domain, in order to avoid
-       inconsistent state during scheduling decisions, because data for
-       vcpu_runnable is not protected by the scheduling lock!*/
+    /* Create local state of the status of the domain, in order to avoid
+     * inconsistent state during scheduling decisions, because data for
+     * vcpu_runnable is not protected by the scheduling lock!
+     */
     if ( !vcpu_runnable(current) )
         inf->status |=3D SEDF_ASLEEP;
 =20
@@ -804,7 +747,7 @@ static struct task_slice sedf_do_schedul
=20
     if ( unlikely(extra_runs(inf)) )
     {
-        /*special treatment of domains running in extra time*/
+        /* Special treatment of domains running in extra time */
         desched_extra_dom(now, current);
     }
     else=20
@@ -814,10 +757,11 @@ static struct task_slice sedf_do_schedul
  check_waitq:
     update_queues(now, runq, waitq);
=20
-    /*now simply pick the first domain from the runqueue, which has the
-      earliest deadline, because the list is sorted*/
-=20
-    /* Tasklet work (which runs in idle VCPU context) overrides all else. =
*/
+    /* Now simply pick the first domain from the runqueue, which has the
+     * earliest deadline, because the list is sorted
+     *
+     * Tasklet work (which runs in idle VCPU context) overrides all else.
+     */
     if ( tasklet_work_scheduled ||
          (list_empty(runq) && list_empty(waitq)) ||
          unlikely(!cpumask_test_cpu(cpu, SEDF_CPUONLINE(per_cpu(cpupool, c=
pu)))) )
@@ -833,9 +777,10 @@ static struct task_slice sedf_do_schedul
         {
             waitinf  =3D list_entry(waitq->next,
                                   struct sedf_vcpu_info,list);
-            /*rerun scheduler, when scheduled domain reaches it's
-              end of slice or the first domain from the waitqueue
-              gets ready*/
+            /* Rerun scheduler, when scheduled domain reaches it's
+             * end of slice or the first domain from the waitqueue
+             * gets ready.
+             */
             ret.time =3D MIN(now + runinf->slice - runinf->cputime,
                            PERIOD_BEGIN(waitinf)) - now;
         }
@@ -847,14 +792,15 @@ static struct task_slice sedf_do_schedul
     else
     {
         waitinf  =3D list_entry(waitq->next,struct sedf_vcpu_info, list);
-        /*we could not find any suitable domain=20
-          =3D> look for domains that are aware of extratime*/
+        /* We could not find any suitable domain=20
+         * =3D> look for domains that are aware of extratime*/
         ret =3D sedf_do_extra_schedule(now, PERIOD_BEGIN(waitinf),
                                      extraq, cpu);
     }
=20
-    /*TODO: Do something USEFUL when this happens and find out, why it
-      still can happen!!!*/
+    /* TODO: Do something USEFUL when this happens and find out, why it
+     * still can happen!!!
+     */
     if ( ret.time < 0)
     {
         printk("Ouch! We are seriously BEHIND schedule! %"PRIi64"\n",
@@ -874,9 +820,6 @@ static struct task_slice sedf_do_schedul
=20
 static void sedf_sleep(const struct scheduler *ops, struct vcpu *d)
 {
-    PRINT(2,"sedf_sleep was called, domain-id %i.%i\n",
-          d->domain->domain_id, d->vcpu_id);
-=20
     if ( is_idle_vcpu(d) )
         return;
=20
@@ -972,27 +915,29 @@ static void sedf_sleep(const struct sche
 static void unblock_short_extra_support(
     struct sedf_vcpu_info* inf, s_time_t now)
 {
-    /*this unblocking scheme tries to support the domain, by assigning it
-    a priority in extratime distribution according to the loss of time
-    in this slice due to blocking*/
+    /* This unblocking scheme tries to support the domain, by assigning it
+     * a priority in extratime distribution according to the loss of time
+     * in this slice due to blocking
+     */
     s_time_t pen;
 =20
-    /*no more realtime execution in this period!*/
+    /* No more realtime execution in this period! */
     inf->deadl_abs +=3D inf->period;
     if ( likely(inf->block_abs) )
     {
-        //treat blocked time as consumed by the domain*/
+        /* Treat blocked time as consumed by the domain */
         /*inf->cputime +=3D now - inf->block_abs;*/
-        /*penalty is time the domain would have
-          had if it continued to run */
+        /* Penalty is time the domain would have
+         * had if it continued to run.
+         */
         pen =3D (inf->slice - inf->cputime);
         if ( pen < 0 )
             pen =3D 0;
-        /*accumulate all penalties over the periods*/
+        /* Accumulate all penalties over the periods */
         /*inf->short_block_lost_tot +=3D pen;*/
-        /*set penalty to the current value*/
+        /* Set penalty to the current value */
         inf->short_block_lost_tot =3D pen;
-        /*not sure which one is better.. but seems to work well...*/
+        /* Not sure which one is better.. but seems to work well... */
  =20
         if ( inf->short_block_lost_tot )
         {
@@ -1002,28 +947,30 @@ static void unblock_short_extra_support(
             inf->pen_extra_blocks++;
 #endif
             if ( extraq_on(inf->vcpu, EXTRA_PEN_Q) )
-                /*remove domain for possible resorting!*/
+                /* Remove domain for possible resorting! */
                 extraq_del(inf->vcpu, EXTRA_PEN_Q);
             else
-                /*remember that we want to be on the penalty q
-                  so that we can continue when we (un-)block
-                  in penalty-extratime*/
+                /* Remember that we want to be on the penalty q
+                 * so that we can continue when we (un-)block
+                 * in penalty-extratime
+                 */
                 inf->status |=3D EXTRA_WANT_PEN_Q;
   =20
-            /*(re-)add domain to the penalty extraq*/
+            /* (re-)add domain to the penalty extraq */
             extraq_add_sort_update(inf->vcpu, EXTRA_PEN_Q, 0);
         }
     }
=20
-    /*give it a fresh slice in the next period!*/
+    /* Give it a fresh slice in the next period! */
     inf->cputime =3D 0;
 }
=20

 static void unblock_long_cons_b(struct sedf_vcpu_info* inf,s_time_t now)
 {
-    /*Conservative 2b*/
-    /*Treat the unblocking time as a start of a new period */
+    /* Conservative 2b */
+
+    /* Treat the unblocking time as a start of a new period */
     inf->deadl_abs =3D now + inf->period;
     inf->cputime =3D 0;
 }
@@ -1046,15 +993,16 @@ static inline int get_run_type(struct vc
 }
=20

-/*Compares two domains in the relation of whether the one is allowed to
-  interrupt the others execution.
-  It returns true (!=3D0) if a switch to the other domain is good.
-  Current Priority scheme is as follows:
-   EDF > L0 (penalty based) extra-time >=20
-   L1 (utilization) extra-time > idle-domain
-  In the same class priorities are assigned as following:
-   EDF: early deadline > late deadline
-   L0 extra-time: lower score > higher score*/
+/* Compares two domains in the relation of whether the one is allowed to
+ * interrupt the others execution.
+ * It returns true (!=3D0) if a switch to the other domain is good.
+ * Current Priority scheme is as follows:
+ *  EDF > L0 (penalty based) extra-time >=20
+ *  L1 (utilization) extra-time > idle-domain
+ * In the same class priorities are assigned as following:
+ *  EDF: early deadline > late deadline
+ *  L0 extra-time: lower score > higher score
+ */
 static inline int should_switch(struct vcpu *cur,
                                 struct vcpu *other,
                                 s_time_t now)
@@ -1063,19 +1011,19 @@ static inline int should_switch(struct v
     cur_inf   =3D EDOM_INFO(cur);
     other_inf =3D EDOM_INFO(other);
 =20
-    /* Check whether we need to make an earlier scheduling decision. */
+    /* Check whether we need to make an earlier scheduling decision */
     if ( PERIOD_BEGIN(other_inf) <=20
          CPU_INFO(other->processor)->current_slice_expires )
         return 1;
=20
-    /* No timing-based switches need to be taken into account here. */
+    /* No timing-based switches need to be taken into account here */
     switch ( get_run_type(cur) )
     {
     case DOMAIN_EDF:
-        /* Do not interrupt a running EDF domain. */
+        /* Do not interrupt a running EDF domain */
         return 0;
     case DOMAIN_EXTRA_PEN:
-        /* Check whether we also want the L0 ex-q with lower score. */
+        /* Check whether we also want the L0 ex-q with lower score */
         return ((other_inf->status & EXTRA_WANT_PEN_Q) &&
                 (other_inf->score[EXTRA_PEN_Q] <=20
                  cur_inf->score[EXTRA_PEN_Q]));
@@ -1096,18 +1044,11 @@ static void sedf_wake(const struct sched
     s_time_t              now =3D NOW();
     struct sedf_vcpu_info* inf =3D EDOM_INFO(d);
=20
-    PRINT(3, "sedf_wake was called, domain-id %i.%i\n",d->domain->domain_i=
d,
-          d->vcpu_id);
-
     if ( unlikely(is_idle_vcpu(d)) )
         return;
   =20
     if ( unlikely(__task_on_queue(d)) )
-    {
-        PRINT(3,"\tdomain %i.%i is already in some queue\n",
-              d->domain->domain_id, d->vcpu_id);
         return;
-    }
=20
     ASSERT(!sedf_runnable(d));
     inf->status &=3D ~SEDF_ASLEEP;
@@ -1116,28 +1057,24 @@ static void sedf_wake(const struct sched
 =20
     if ( unlikely(inf->deadl_abs =3D=3D 0) )
     {
-        /*initial setup of the deadline*/
+        /* Initial setup of the deadline */
         inf->deadl_abs =3D now + inf->slice;
     }
  =20
-    PRINT(3, "waking up domain %i.%i (deadl=3D %"PRIu64" period=3D %"PRIu6=
4
-          "now=3D %"PRIu64")\n",
-          d->domain->domain_id, d->vcpu_id, inf->deadl_abs, inf->period, n=
ow);
-
 #ifdef SEDF_STATS=20
     inf->block_tot++;
 #endif
=20
     if ( unlikely(now < PERIOD_BEGIN(inf)) )
     {
-        PRINT(4,"extratime unblock\n");
-        /* unblocking in extra-time! */
+        /* Unblocking in extra-time! */
         if ( inf->status & EXTRA_WANT_PEN_Q )
         {
-            /*we have a domain that wants compensation
-              for block penalty and did just block in
-              its compensation time. Give it another
-              chance!*/
+            /* We have a domain that wants compensation
+             * for block penalty and did just block in
+             * its compensation time. Give it another
+             * chance!
+             */
             extraq_add_sort_update(d, EXTRA_PEN_Q, 0);
         }
         extraq_check_add_unblocked(d, 0);
@@ -1146,8 +1083,7 @@ static void sedf_wake(const struct sched
     { =20
         if ( now < inf->deadl_abs )
         {
-            PRINT(4,"short unblocking\n");
-            /*short blocking*/
+            /* Short blocking */
 #ifdef SEDF_STATS
             inf->short_block_tot++;
 #endif
@@ -1157,8 +1093,7 @@ static void sedf_wake(const struct sched
         }
         else
         {
-            PRINT(4,"long unblocking\n");
-            /*long unblocking*/
+            /* Long unblocking */
 #ifdef SEDF_STATS
             inf->long_block_tot++;
 #endif
@@ -1168,24 +1103,13 @@ static void sedf_wake(const struct sched
         }
     }
=20
-    PRINT(3, "woke up domain %i.%i (deadl=3D %"PRIu64" period=3D %"PRIu64
-          "now=3D %"PRIu64")\n",
-          d->domain->domain_id, d->vcpu_id, inf->deadl_abs,
-          inf->period, now);
-
     if ( PERIOD_BEGIN(inf) > now )
-    {
         __add_to_waitqueue_sort(d);
-        PRINT(3,"added to waitq\n");
-    }
     else
-    {
         __add_to_runqueue_sort(d);
-        PRINT(3,"added to runq\n");
-    }
 =20
 #ifdef SEDF_STATS
-    /*do some statistics here...*/
+    /* Do some statistics here... */
     if ( inf->block_abs !=3D 0 )
     {
         inf->block_time_tot +=3D now - inf->block_abs;
@@ -1194,12 +1118,13 @@ static void sedf_wake(const struct sched
     }
 #endif
=20
-    /*sanity check: make sure each extra-aware domain IS on the util-q!*/
+    /* Sanity check: make sure each extra-aware domain IS on the util-q! *=
/
     ASSERT(IMPLY(inf->status & EXTRA_AWARE, extraq_on(d, EXTRA_UTIL_Q)));
     ASSERT(__task_on_queue(d));
-    /*check whether the awakened task needs to invoke the do_schedule
-      routine. Try to avoid unnecessary runs but:
-      Save approximation: Always switch to scheduler!*/
+    /* Check whether the awakened task needs to invoke the do_schedule
+     * routine. Try to avoid unnecessary runs but:
+     * Save approximation: Always switch to scheduler!
+     */
     ASSERT(d->processor >=3D 0);
     ASSERT(d->processor < nr_cpu_ids);
     ASSERT(per_cpu(schedule_data, d->processor).curr);
@@ -1244,7 +1169,7 @@ static void sedf_dump_domain(struct vcpu
 }
=20

-/* dumps all domains on the specified cpu */
+/* Dumps all domains on the specified cpu */
 static void sedf_dump_cpu_state(const struct scheduler *ops, int i)
 {
     struct list_head      *list, *queue, *tmp;
@@ -1319,7 +1244,7 @@ static void sedf_dump_cpu_state(const st
 }
=20

-/* Adjusts periods and slices of the domains accordingly to their weights.=
 */
+/* Adjusts periods and slices of the domains accordingly to their weights =
*/
 static int sedf_adjust_weights(struct cpupool *c, struct xen_domctl_schedu=
ler_op *cmd)
 {
     struct vcpu *p;
@@ -1335,7 +1260,7 @@ static int sedf_adjust_weights(struct cp
         return -ENOMEM;
     }
=20
-    /* Sum across all weights. */
+    /* Sum across all weights */
     rcu_read_lock(&domlist_read_lock);
     for_each_domain_in_cpupool( d, c )
     {
@@ -1350,11 +1275,13 @@ static int sedf_adjust_weights(struct cp
             }
             else
             {
-                /*don't modify domains who don't have a weight, but sum
-                  up the time they need, projected to a WEIGHT_PERIOD,
-                  so that this time is not given to the weight-driven
-                  domains*/
-                /*check for overflows*/
+                /* Don't modify domains who don't have a weight, but sum
+                 * up the time they need, projected to a WEIGHT_PERIOD,
+                 * so that this time is not given to the weight-driven
+                 *  domains
+                 */
+
+                /* Check for overflows */
                 ASSERT((WEIGHT_PERIOD < ULONG_MAX)=20
                        && (EDOM_INFO(p)->slice_orig < ULONG_MAX));
                 sumt[cpu] +=3D=20
@@ -1365,7 +1292,7 @@ static int sedf_adjust_weights(struct cp
     }
     rcu_read_unlock(&domlist_read_lock);
=20
-    /* Adjust all slices (and periods) to the new weight. */
+    /* Adjust all slices (and periods) to the new weight */
     rcu_read_lock(&domlist_read_lock);
     for_each_domain_in_cpupool( d, c )
     {
@@ -1393,20 +1320,15 @@ static int sedf_adjust_weights(struct cp
 }
=20

-/* set or fetch domain scheduling parameters */
+/* Set or fetch domain scheduling parameters */
 static int sedf_adjust(const struct scheduler *ops, struct domain *p, stru=
ct xen_domctl_scheduler_op *op)
 {
     struct vcpu *v;
     int rc;
=20
-    PRINT(2,"sedf_adjust was called, domain-id %i new period %"PRIu64" "
-          "new slice %"PRIu64"\nlatency %"PRIu64" extra:%s\n",
-          p->domain_id, op->u.sedf.period, op->u.sedf.slice,
-          op->u.sedf.latency, (op->u.sedf.extratime)?"yes":"no");
-
     if ( op->cmd =3D=3D XEN_DOMCTL_SCHEDOP_putinfo )
     {
-        /* Check for sane parameters. */
+        /* Check for sane parameters */
         if ( !op->u.sedf.period && !op->u.sedf.weight )
             return -EINVAL;
         if ( op->u.sedf.weight )
@@ -1414,7 +1336,7 @@ static int sedf_adjust(const struct sche
             if ( (op->u.sedf.extratime & EXTRA_AWARE) &&
                  (!op->u.sedf.period) )
             {
-                /* Weight-driven domains with extratime only. */
+                /* Weight-driven domains with extratime only */
                 for_each_vcpu ( p, v )
                 {
                     EDOM_INFO(v)->extraweight =3D op->u.sedf.weight;
@@ -1425,7 +1347,7 @@ static int sedf_adjust(const struct sche
             }
             else
             {
-                /* Weight-driven domains with real-time execution. */
+                /* Weight-driven domains with real-time execution */
                 for_each_vcpu ( p, v )
                     EDOM_INFO(v)->weight =3D op->u.sedf.weight;
             }
@@ -1435,8 +1357,7 @@ static int sedf_adjust(const struct sche
             /* Time-driven domains. */
             for_each_vcpu ( p, v )
             {
-                /*
-                 * Sanity checking: note that disabling extra weight requi=
res
+                /* Sanity checking: note that disabling extra weight requi=
res
                  * that we set a non-zero slice.
                  */
                 if ( (op->u.sedf.period > PERIOD_MAX) ||
@@ -1477,7 +1398,6 @@ static int sedf_adjust(const struct sche
         op->u.sedf.weight    =3D EDOM_INFO(p->vcpu[0])->weight;
     }
=20
-    PRINT(2,"sedf_adjust_finished\n");
     return 0;
 }
=20

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-------------------------------------------------------------------
Dario Faggioli, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
PhD Candidate, ReTiS Lab, Scuola Superiore Sant'Anna, Pisa (Italy)





--=-SQC3wUYrGGqGq8T7E3BQ
Content-Disposition: attachment; filename="sedf-debug-cleanup.patch"
Content-Type: text/x-patch; name="sedf-debug-cleanup.patch"; charset="UTF-8"
Content-Transfer-Encoding: base64

IyBIRyBjaGFuZ2VzZXQgcGF0Y2gNCiMgUGFyZW50IDE3ZDk5NjkxZTBlYzFmYTdiYjcxY2YxOGMx
MmNhM2MwNDZjMGM4ZDcNCnNlZGY6IHJlbW92ZSB1c2VsZXNzIHRyYWNpbmcgcHJpbnRrIGFuZCBo
YXJtb25pemUgY29tbWVudHMgc3R5bGUuDQoNCnNjaGVkX3NlZGYuYyB1c2VkIG8gaGF2ZSBpdHMg
b3duIG1lY2hhbmlzbSBmb3IgcHJvZHVjaW5nIHRyYWNpbmctYWxpa2UNCmtpbmQgb2YgaW5mb3Jt
YXRpb24gKGRvbWFpbiBibG9jaywgd2FrZXVwLCBldGMuKS4gTm93YWRheXMsIHdpdGggYW4gZXZl
bg0Kbm90IHNvIGhpZ2ggbnVtYmVyIG9mIHBDUFVzL3ZDUFVzLCBqdXN0IHRyeWluZyB0byBlbmFi
bGUgdGhpcyBtYWtlcw0KdGhlIHNlcmlhbCBjb25zb2xlIGNvbXBsZXRlbHkgdW51c2FibGUsIHBy
b2R1Y2VzIHRvbnMgb2YgdmVyeSBoYXJkIHRvDQpwYXJzZSBhbmQgaW50ZXJwcmVldCBsb2dnaW5n
IGFuZCBjYW4gZWFzaWx5IGxpdmVsb2NrIERvbTAuIE1vcmVvdmVyLA0KcHJldHR5IG11Y2ggdGhl
IHNhbWUgcmVzdWx0IHRoaXMgaXMgc3RydWdnbGluZyB0byBnZXQgdG8sIGlzIGJldHRlcg0KYWNo
aWV2ZWQgYnkgZW5hYmxpbmcgdGhlIHNjaGVkdWxlci1yZWxhdGVkIHRyYWNpbmcgZXZlbnRzLCBh
cw0KaXQgaXMgZm9yIHRoZSBvdGhlciBzY2hlZHVsZXJzIChzYXksIGNyZWRpdCBvciBjcmVkaXQy
KS4NCg0KRm9yIGFsbCB0aGVzZSByZWFzb25zLCB0aGlzIHJlbW92ZXMgdGhhdCBtYWNoaW5lcnkg
Y29tcGxldGVseS4gV2hpbGUgYXQNCml0LCBjaGVjayBpbiBzb21lIGNvc21ldGljcyB0aGF0IGhh
cm1vbml6ZSB0aGUgY29tbWVudHMgd2l0aGltIHRoZW1zZWxmDQphbmQgd2l0aCB0aGUgcmVzdCBv
ZiB0aGUgY29kZSBiYXNlLg0KDQpTaWduZWQtb2ZmLWJ5OiBEYXJpbyBGYWdnaW9saSA8ZGFyaW8u
ZmFnZ2lvbGlAY2l0cml4LmNvbT4NCg0KZGlmZiAtciAxN2Q5OTY5MWUwZWMgeGVuL2NvbW1vbi9z
Y2hlZF9zZWRmLmMNCi0tLSBhL3hlbi9jb21tb24vc2NoZWRfc2VkZi5jCVR1ZSBEZWMgMjAgMTY6
Mzk6NTYgMjAxMSArMDAwMA0KKysrIGIveGVuL2NvbW1vbi9zY2hlZF9zZWRmLmMJVHVlIERlYyAy
MCAxNzozMjo1MiAyMDExICswMDAwDQpAQCAtMTMsMTQgKzEzLDYgQEANCiAjaW5jbHVkZSA8eGVu
L3RpbWUuaD4NCiAjaW5jbHVkZSA8eGVuL2Vycm5vLmg+DQogDQotLyp2ZXJib3NpdHkgc2V0dGlu
Z3MqLw0KLSNkZWZpbmUgU0VERkxFVkVMIDANCi0jZGVmaW5lIFBSSU5UKF9mLCBfYS4uLikgICAg
ICAgICAgICAgICAgICAgICAgICBcDQotICAgIGRvIHsgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgXA0KLSAgICAgICAgaWYgKCAoX2YpIDw9IFNFREZMRVZFTCApICAgICAg
ICAgICAgICAgIFwNCi0gICAgICAgICAgICBwcmludGsoX2EgKTsgICAgICAgICAgICAgICAgICAg
ICAgICBcDQotICAgIH0gd2hpbGUgKCAwICkNCi0NCiAjZGVmaW5lIFNFREZfQ1BVT05MSU5FKF9w
b29sKSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFwNCiAgICAg
KCgoX3Bvb2wpID09IE5VTEwpID8gJmNwdXBvb2xfZnJlZV9jcHVzIDogKF9wb29sKS0+Y3B1X3Zh
bGlkKQ0KIA0KQEAgLTY2LDM0ICs1OCwzNSBAQCBzdHJ1Y3Qgc2VkZl92Y3B1X2luZm8gew0KICAg
ICBzdHJ1Y3QgbGlzdF9oZWFkIGxpc3Q7DQogICAgIHN0cnVjdCBsaXN0X2hlYWQgZXh0cmFsaXN0
WzJdOw0KICANCi0gICAgLypQYXJhbWV0ZXJzIGZvciBFREYqLw0KLSAgICBzX3RpbWVfdCAgcGVy
aW9kOyAgLyo9KHJlbGF0aXZlIGRlYWRsaW5lKSovDQotICAgIHNfdGltZV90ICBzbGljZTsgIC8q
PXdvcnN0IGNhc2UgZXhlY3V0aW9uIHRpbWUqLw0KKyAgICAvKiBQYXJhbWV0ZXJzIGZvciBFREYg
Ki8NCisgICAgc190aW1lX3QgIHBlcmlvZDsgIC8qID0ocmVsYXRpdmUgZGVhZGxpbmUpICovDQor
ICAgIHNfdGltZV90ICBzbGljZTsgICAvKiA9d29yc3QgY2FzZSBleGVjdXRpb24gdGltZSAqLw0K
ICANCi0gICAgLypBZHZhY2VkIFBhcmFtZXRlcnMqLw0KLSAgICAvKkxhdGVuY3kgU2NhbGluZyov
DQorICAgIC8qIEFkdmFjZWQgUGFyYW1ldGVycyAqLw0KKw0KKyAgICAvKiBMYXRlbmN5IFNjYWxp
bmcgKi8NCiAgICAgc190aW1lX3QgIHBlcmlvZF9vcmlnOw0KICAgICBzX3RpbWVfdCAgc2xpY2Vf
b3JpZzsNCiAgICAgc190aW1lX3QgIGxhdGVuY3k7DQogIA0KLSAgICAvKnN0YXR1cyBvZiBkb21h
aW4qLw0KKyAgICAvKiBTdGF0dXMgb2YgZG9tYWluICovDQogICAgIGludCAgICAgICBzdGF0dXM7
DQotICAgIC8qd2VpZ2h0cyBmb3IgIlNjaGVkdWxpbmcgZm9yIGJlZ2lubmVycy8gbGF6eS8gZXRj
LiIgOykqLw0KKyAgICAvKiBXZWlnaHRzIGZvciAiU2NoZWR1bGluZyBmb3IgYmVnaW5uZXJzLyBs
YXp5LyBldGMuIiA7KSAqLw0KICAgICBzaG9ydCAgICAgd2VpZ2h0Ow0KICAgICBzaG9ydCAgICAg
ZXh0cmF3ZWlnaHQ7DQotICAgIC8qQm9va2tlZXBpbmcqLw0KKyAgICAvKiBCb29ra2VlcGluZyAq
Lw0KICAgICBzX3RpbWVfdCAgZGVhZGxfYWJzOw0KICAgICBzX3RpbWVfdCAgc2NoZWRfc3RhcnRf
YWJzOw0KICAgICBzX3RpbWVfdCAgY3B1dGltZTsNCi0gICAgLyogdGltZXMgdGhlIGRvbWFpbiB1
bi0vYmxvY2tlZCAqLw0KKyAgICAvKiBUaW1lcyB0aGUgZG9tYWluIHVuLS9ibG9ja2VkICovDQog
ICAgIHNfdGltZV90ICBibG9ja19hYnM7DQogICAgIHNfdGltZV90ICB1bmJsb2NrX2FiczsNCiAg
DQotICAgIC8qc2NvcmVzIGZvciB7dXRpbCwgYmxvY2sgcGVuYWx0eX0td2VpZ2h0ZWQgZXh0cmF0
aW1lIGRpc3RyaWJ1dGlvbiovDQorICAgIC8qIFNjb3JlcyBmb3Ige3V0aWwsIGJsb2NrIHBlbmFs
dHl9LXdlaWdodGVkIGV4dHJhdGltZSBkaXN0cmlidXRpb24gKi8NCiAgICAgaW50ICAgc2NvcmVb
Ml07DQogICAgIHNfdGltZV90ICBzaG9ydF9ibG9ja19sb3N0X3RvdDsNCiAgDQotICAgIC8qU3Rh
dGlzdGljcyovDQorICAgIC8qIFN0YXRpc3RpY3MgKi8NCiAgICAgc190aW1lX3QgIGV4dHJhX3Rp
bWVfdG90Ow0KIA0KICNpZmRlZiBTRURGX1NUQVRTDQpAQCAtMTU4LDE4ICsxNTEsMTYgQEAgc3Rh
dGljIGlubGluZSB2b2lkIGV4dHJhcV9kZWwoc3RydWN0IHZjcA0KIHsNCiAgICAgc3RydWN0IGxp
c3RfaGVhZCAqbGlzdCA9IEVYVFJBTElTVChkLGkpOw0KICAgICBBU1NFUlQoZXh0cmFxX29uKGQs
aSkpOw0KLSAgICBQUklOVCgzLCAiUmVtb3ZpbmcgZG9tYWluICVpLiVpIGZyb20gTCVpIGV4dHJh
cVxuIiwNCi0gICAgICAgICAgZC0+ZG9tYWluLT5kb21haW5faWQsIGQtPnZjcHVfaWQsIGkpOw0K
ICAgICBsaXN0X2RlbChsaXN0KTsNCiAgICAgbGlzdC0+bmV4dCA9IE5VTEw7DQogICAgIEFTU0VS
VCghZXh0cmFxX29uKGQsIGkpKTsNCiB9DQogDQotLyogYWRkcyBhIGRvbWFpbiB0byB0aGUgcXVl
dWUgb2YgcHJvY2Vzc2VzIHdoaWNoIGFyZSBhd2FyZSBvZiBleHRyYSB0aW1lLiBMaXN0DQotICAg
aXMgc29ydGVkIGJ5IHNjb3JlLCB3aGVyZSBhIGxvd2VyIHNjb3JlIG1lYW5zIGhpZ2hlciBwcmlv
cml0eSBmb3IgYW4gZXh0cmENCi0gICBzbGljZS4gSXQgYWxzbyB1cGRhdGVzIHRoZSBzY29yZSwg
Ynkgc2ltcGx5IHN1YnRyYWN0aW5nIGEgZml4ZWQgdmFsdWUgZnJvbQ0KLSAgIGVhY2ggZW50cnks
IGluIG9yZGVyIHRvIGF2b2lkIG92ZXJmbG93LiBUaGUgYWxnb3JpdGhtIHdvcmtzIGJ5IHNpbXBs
eQ0KLSAgIGNoYXJnaW5nIGVhY2ggZG9tYWluIHRoYXQgcmVjaWV2ZWQgZXh0cmF0aW1lIHdpdGgg
YW4gaW52ZXJzZSBvZiBpdHMgd2VpZ2h0Lg0KKy8qIEFkZHMgYSBkb21haW4gdG8gdGhlIHF1ZXVl
IG9mIHByb2Nlc3NlcyB3aGljaCBhcmUgYXdhcmUgb2YgZXh0cmEgdGltZS4gTGlzdA0KKyAqIGlz
IHNvcnRlZCBieSBzY29yZSwgd2hlcmUgYSBsb3dlciBzY29yZSBtZWFucyBoaWdoZXIgcHJpb3Jp
dHkgZm9yIGFuIGV4dHJhDQorICogc2xpY2UuIEl0IGFsc28gdXBkYXRlcyB0aGUgc2NvcmUsIGJ5
IHNpbXBseSBzdWJ0cmFjdGluZyBhIGZpeGVkIHZhbHVlIGZyb20NCisgKiBlYWNoIGVudHJ5LCBp
biBvcmRlciB0byBhdm9pZCBvdmVyZmxvdy4gVGhlIGFsZ29yaXRobSB3b3JrcyBieSBzaW1wbHkN
CisgKiBjaGFyZ2luZyBlYWNoIGRvbWFpbiB0aGF0IHJlY2lldmVkIGV4dHJhdGltZSB3aXRoIGFu
IGludmVyc2Ugb2YgaXRzIHdlaWdodC4NCiAgKi8gDQogc3RhdGljIGlubGluZSB2b2lkIGV4dHJh
cV9hZGRfc29ydF91cGRhdGUoc3RydWN0IHZjcHUgKmQsIGludCBpLCBpbnQgc3ViKQ0KIHsNCkBA
IC0xNzgsMTMgKzE2OSw3IEBAIHN0YXRpYyBpbmxpbmUgdm9pZCBleHRyYXFfYWRkX3NvcnRfdXBk
YXQNCiAgDQogICAgIEFTU0VSVCghZXh0cmFxX29uKGQsaSkpOw0KIA0KLSAgICBQUklOVCgzLCAi
QWRkaW5nIGRvbWFpbiAlaS4laSAoc2NvcmU9ICVpLCBzaG9ydF9wZW49ICUiUFJJaTY0IikiDQot
ICAgICAgICAgICIgdG8gTCVpIGV4dHJhcVxuIiwNCi0gICAgICAgICAgZC0+ZG9tYWluLT5kb21h
aW5faWQsIGQtPnZjcHVfaWQsIEVET01fSU5GTyhkKS0+c2NvcmVbaV0sDQotICAgICAgICAgIEVE
T01fSU5GTyhkKS0+c2hvcnRfYmxvY2tfbG9zdF90b3QsIGkpOw0KLQ0KLSAgICAvKg0KLSAgICAg
KiBJdGVyYXRlIHRocm91Z2ggYWxsIGVsZW1lbnRzIHRvIGZpbmQgb3VyICJob2xlIiBhbmQgb24g
b3VyIHdheQ0KKyAgICAvKiBJdGVyYXRlIHRocm91Z2ggYWxsIGVsZW1lbnRzIHRvIGZpbmQgb3Vy
ICJob2xlIiBhbmQgb24gb3VyIHdheQ0KICAgICAgKiB1cGRhdGUgYWxsIHRoZSBvdGhlciBzY29y
ZXMuDQogICAgICAqLw0KICAgICBsaXN0X2Zvcl9lYWNoICggY3VyLCBFWFRSQVEoZC0+cHJvY2Vz
c29yLCBpKSApDQpAQCAtMTkzLDI1ICsxNzgsMTggQEAgc3RhdGljIGlubGluZSB2b2lkIGV4dHJh
cV9hZGRfc29ydF91cGRhdA0KICAgICAgICAgY3VyaW5mLT5zY29yZVtpXSAtPSBzdWI7DQogICAg
ICAgICBpZiAoIEVET01fSU5GTyhkKS0+c2NvcmVbaV0gPCBjdXJpbmYtPnNjb3JlW2ldICkNCiAg
ICAgICAgICAgICBicmVhazsNCi0gICAgICAgIFBSSU5UKDQsIlx0YmVoaW5kIGRvbWFpbiAlaS4l
aSAoc2NvcmU9ICVpKVxuIiwNCi0gICAgICAgICAgICAgIGN1cmluZi0+dmNwdS0+ZG9tYWluLT5k
b21haW5faWQsDQotICAgICAgICAgICAgICBjdXJpbmYtPnZjcHUtPnZjcHVfaWQsIGN1cmluZi0+
c2NvcmVbaV0pOw0KICAgICB9DQogDQotICAgIC8qIGN1ciBub3cgY29udGFpbnMgdGhlIGVsZW1l
bnQsIGJlZm9yZSB3aGljaCB3ZSdsbCBlbnF1ZXVlLiAqLw0KLSAgICBQUklOVCgzLCAiXHRsaXN0
X2FkZCB0byAlcFxuIiwgY3VyLT5wcmV2KTsNCisgICAgLyogY3VyIG5vdyBjb250YWlucyB0aGUg
ZWxlbWVudCwgYmVmb3JlIHdoaWNoIHdlJ2xsIGVucXVldWUgKi8NCiAgICAgbGlzdF9hZGQoRVhU
UkFMSVNUKGQsaSksY3VyLT5wcmV2KTsNCiAgDQotICAgIC8qIENvbnRpbnVlIHVwZGF0aW5nIHRo
ZSBleHRyYXEuICovDQorICAgIC8qIENvbnRpbnVlIHVwZGF0aW5nIHRoZSBleHRyYXEgKi8NCiAg
ICAgaWYgKCAoY3VyICE9IEVYVFJBUShkLT5wcm9jZXNzb3IsaSkpICYmIHN1YiApDQogICAgIHsN
CiAgICAgICAgIGZvciAoIGN1ciA9IGN1ci0+bmV4dDsgY3VyICE9IEVYVFJBUShkLT5wcm9jZXNz
b3IsaSk7IGN1ciA9IGN1ci0+bmV4dCApDQogICAgICAgICB7DQogICAgICAgICAgICAgY3VyaW5m
ID0gbGlzdF9lbnRyeShjdXIsc3RydWN0IHNlZGZfdmNwdV9pbmZvLCBleHRyYWxpc3RbaV0pOw0K
ICAgICAgICAgICAgIGN1cmluZi0+c2NvcmVbaV0gLT0gc3ViOw0KLSAgICAgICAgICAgIFBSSU5U
KDQsICJcdHVwZGF0aW5nIGRvbWFpbiAlaS4laSAoc2NvcmU9ICV1KVxuIiwNCi0gICAgICAgICAg
ICAgICAgICBjdXJpbmYtPnZjcHUtPmRvbWFpbi0+ZG9tYWluX2lkLCANCi0gICAgICAgICAgICAg
ICAgICBjdXJpbmYtPnZjcHUtPnZjcHVfaWQsIGN1cmluZi0+c2NvcmVbaV0pOw0KICAgICAgICAg
fQ0KICAgICB9DQogDQpAQCAtMjIxLDI5ICsxOTksMTQgQEAgc3RhdGljIGlubGluZSB2b2lkIGV4
dHJhcV9jaGVjayhzdHJ1Y3Qgdg0KIHsNCiAgICAgaWYgKCBleHRyYXFfb24oZCwgRVhUUkFfVVRJ
TF9RKSApDQogICAgIHsNCi0gICAgICAgIFBSSU5UKDIsIkRvbSAlaS4laSBpcyBvbiBMMSBleHRy
YVFcbiIsDQotICAgICAgICAgICAgICBkLT5kb21haW4tPmRvbWFpbl9pZCwgZC0+dmNwdV9pZCk7
DQotDQogICAgICAgICBpZiAoICEoRURPTV9JTkZPKGQpLT5zdGF0dXMgJiBFWFRSQV9BV0FSRSkg
JiYNCiAgICAgICAgICAgICAgIWV4dHJhX3J1bnMoRURPTV9JTkZPKGQpKSApDQotICAgICAgICB7
DQogICAgICAgICAgICAgZXh0cmFxX2RlbChkLCBFWFRSQV9VVElMX1EpOw0KLSAgICAgICAgICAg
IFBSSU5UKDIsIlJlbW92ZWQgZG9tICVpLiVpIGZyb20gTDEgZXh0cmFRXG4iLA0KLSAgICAgICAg
ICAgICAgICAgIGQtPmRvbWFpbi0+ZG9tYWluX2lkLCBkLT52Y3B1X2lkKTsNCi0gICAgICAgIH0N
CiAgICAgfQ0KICAgICBlbHNlDQogICAgIHsNCi0gICAgICAgIFBSSU5UKDIsICJEb20gJWkuJWkg
aXMgTk9UIG9uIEwxIGV4dHJhUVxuIiwNCi0gICAgICAgICAgICAgIGQtPmRvbWFpbi0+ZG9tYWlu
X2lkLA0KLSAgICAgICAgICAgICAgZC0+dmNwdV9pZCk7DQotDQogICAgICAgICBpZiAoIChFRE9N
X0lORk8oZCktPnN0YXR1cyAmIEVYVFJBX0FXQVJFKSAmJiBzZWRmX3J1bm5hYmxlKGQpICkNCi0g
ICAgICAgIHsNCiAgICAgICAgICAgICBleHRyYXFfYWRkX3NvcnRfdXBkYXRlKGQsIEVYVFJBX1VU
SUxfUSwgMCk7DQotICAgICAgICAgICAgUFJJTlQoMiwiQWRkZWQgZG9tICVpLiVpIHRvIEwxIGV4
dHJhUVxuIiwNCi0gICAgICAgICAgICAgICAgICBkLT5kb21haW4tPmRvbWFpbl9pZCwgZC0+dmNw
dV9pZCk7DQotICAgICAgICB9DQogICAgIH0NCiB9DQogDQpAQCAtMjUyLDcgKzIxNSw3IEBAIHN0
YXRpYyBpbmxpbmUgdm9pZCBleHRyYXFfY2hlY2tfYWRkX3VuYmwNCiAgICAgc3RydWN0IHNlZGZf
dmNwdV9pbmZvICppbmYgPSBFRE9NX0lORk8oZCk7DQogDQogICAgIGlmICggaW5mLT5zdGF0dXMg
JiBFWFRSQV9BV0FSRSApDQotICAgICAgICAvKiBQdXQgb24gdGhlIHdlaWdodGVkIGV4dHJhcSB3
aXRob3V0IHVwZGF0aW5nIGFueSBzY29yZXMuICovDQorICAgICAgICAvKiBQdXQgb24gdGhlIHdl
aWdodGVkIGV4dHJhcSB3aXRob3V0IHVwZGF0aW5nIGFueSBzY29yZXMgKi8NCiAgICAgICAgIGV4
dHJhcV9hZGRfc29ydF91cGRhdGUoZCwgRVhUUkFfVVRJTF9RLCAwKTsNCiB9DQogDQpAQCAtMjY1
LDggKzIyOCw2IEBAIHN0YXRpYyBpbmxpbmUgdm9pZCBfX2RlbF9mcm9tX3F1ZXVlKHN0cnUNCiB7
DQogICAgIHN0cnVjdCBsaXN0X2hlYWQgKmxpc3QgPSBMSVNUKGQpOw0KICAgICBBU1NFUlQoX190
YXNrX29uX3F1ZXVlKGQpKTsNCi0gICAgUFJJTlQoMywiUmVtb3ZpbmcgZG9tYWluICVpLiVpIChi
b3A9ICUiUFJJdTY0IikgZnJvbSBydW5xL3dhaXRxXG4iLA0KLSAgICAgICAgICBkLT5kb21haW4t
PmRvbWFpbl9pZCwgZC0+dmNwdV9pZCwgUEVSSU9EX0JFR0lOKEVET01fSU5GTyhkKSkpOw0KICAg
ICBsaXN0X2RlbChsaXN0KTsNCiAgICAgbGlzdC0+bmV4dCA9IE5VTEw7DQogICAgIEFTU0VSVCgh
X190YXNrX29uX3F1ZXVlKGQpKTsNCkBAIC0yNzksMTMgKzI0MCwxMiBAQCBzdGF0aWMgaW5saW5l
IHZvaWQgbGlzdF9pbnNlcnRfc29ydCgNCiB7DQogICAgIHN0cnVjdCBsaXN0X2hlYWQgICAgICpj
dXI7DQogDQotICAgIC8qIEl0ZXJhdGUgdGhyb3VnaCBhbGwgZWxlbWVudHMgdG8gZmluZCBvdXIg
ImhvbGUiLiAqLw0KKyAgICAvKiBJdGVyYXRlIHRocm91Z2ggYWxsIGVsZW1lbnRzIHRvIGZpbmQg
b3VyICJob2xlIiAqLw0KICAgICBsaXN0X2Zvcl9lYWNoKCBjdXIsIGxpc3QgKQ0KICAgICAgICAg
aWYgKCBjb21wKGVsZW1lbnQsIGN1cikgPCAwICkNCiAgICAgICAgICAgICBicmVhazsNCiANCi0g
ICAgLyogY3VyIG5vdyBjb250YWlucyB0aGUgZWxlbWVudCwgYmVmb3JlIHdoaWNoIHdlJ2xsIGVu
cXVldWUuICovDQotICAgIFBSSU5UKDMsIlx0bGlzdF9hZGQgdG8gJXBcbiIsY3VyLT5wcmV2KTsN
CisgICAgLyogY3VyIG5vdyBjb250YWlucyB0aGUgZWxlbWVudCwgYmVmb3JlIHdoaWNoIHdlJ2xs
IGVucXVldWUgKi8NCiAgICAgbGlzdF9hZGQoZWxlbWVudCwgY3VyLT5wcmV2KTsNCiB9DQogDQpA
QCAtMzAzLDMwICsyNjMsMjYgQEAgc3RhdGljIGludCBuYW1lIyNfY29tcChzdHJ1Y3QgbGlzdF9o
ZWFkKg0KICAgICAgICAgcmV0dXJuIDE7ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIFwNCiB9DQogDQotLyogYWRkcyBhIGRvbWFpbiB0byB0aGUg
cXVldWUgb2YgcHJvY2Vzc2VzIHdoaWNoIHdhaXQgZm9yIHRoZSBiZWdpbm5pbmcgb2YgdGhlDQot
ICAgbmV4dCBwZXJpb2Q7IHRoaXMgbGlzdCBpcyB0aGVyZWZvcmUgc29ydGV0IGJ5IHRoaXMgdGlt
ZSwgd2hpY2ggaXMgc2ltcGx5DQotICAgYWJzb2wuIGRlYWRsaW5lIC0gcGVyaW9kDQorLyogQWRk
cyBhIGRvbWFpbiB0byB0aGUgcXVldWUgb2YgcHJvY2Vzc2VzIHdoaWNoIHdhaXQgZm9yIHRoZSBi
ZWdpbm5pbmcgb2YgdGhlDQorICogbmV4dCBwZXJpb2Q7IHRoaXMgbGlzdCBpcyB0aGVyZWZvcmUg
c29ydGV0IGJ5IHRoaXMgdGltZSwgd2hpY2ggaXMgc2ltcGx5DQorICogYWJzb2wuIGRlYWRsaW5l
IC0gcGVyaW9kLg0KICAqLyANCiBET01BSU5fQ09NUEFSRVIod2FpdHEsIGxpc3QsIFBFUklPRF9C
RUdJTihkMSksIFBFUklPRF9CRUdJTihkMikpOw0KIHN0YXRpYyBpbmxpbmUgdm9pZCBfX2FkZF90
b193YWl0cXVldWVfc29ydChzdHJ1Y3QgdmNwdSAqdikNCiB7DQogICAgIEFTU0VSVCghX190YXNr
X29uX3F1ZXVlKHYpKTsNCi0gICAgUFJJTlQoMywiQWRkaW5nIGRvbWFpbiAlaS4laSAoYm9wPSAl
IlBSSXU2NCIpIHRvIHdhaXRxXG4iLA0KLSAgICAgICAgICB2LT5kb21haW4tPmRvbWFpbl9pZCwg
di0+dmNwdV9pZCwgUEVSSU9EX0JFR0lOKEVET01fSU5GTyh2KSkpOw0KICAgICBsaXN0X2luc2Vy
dF9zb3J0KFdBSVRRKHYtPnByb2Nlc3NvciksIExJU1QodiksIHdhaXRxX2NvbXApOw0KICAgICBB
U1NFUlQoX190YXNrX29uX3F1ZXVlKHYpKTsNCiB9DQogDQotLyogYWRkcyBhIGRvbWFpbiB0byB0
aGUgcXVldWUgb2YgcHJvY2Vzc2VzIHdoaWNoIGhhdmUgc3RhcnRlZCB0aGVpciBjdXJyZW50DQot
ICAgcGVyaW9kIGFuZCBhcmUgcnVubmFibGUgKGkuZS4gbm90IGJsb2NrZWQsIGRpZWluZywuLi4p
LiBUaGUgZmlyc3QgZWxlbWVudA0KLSAgIG9uIHRoaXMgbGlzdCBpcyBydW5uaW5nIG9uIHRoZSBw
cm9jZXNzb3IsIGlmIHRoZSBsaXN0IGlzIGVtcHR5IHRoZSBpZGxlDQotICAgdGFzayB3aWxsIHJ1
bi4gQXMgd2UgYXJlIGltcGxlbWVudGluZyBFREYsIHRoaXMgbGlzdCBpcyBzb3J0ZWQgYnkgZGVh
ZGxpbmVzLg0KKy8qIEFkZHMgYSBkb21haW4gdG8gdGhlIHF1ZXVlIG9mIHByb2Nlc3NlcyB3aGlj
aCBoYXZlIHN0YXJ0ZWQgdGhlaXIgY3VycmVudA0KKyAqIHBlcmlvZCBhbmQgYXJlIHJ1bm5hYmxl
IChpLmUuIG5vdCBibG9ja2VkLCBkaWVpbmcsLi4uKS4gVGhlIGZpcnN0IGVsZW1lbnQNCisgKiBv
biB0aGlzIGxpc3QgaXMgcnVubmluZyBvbiB0aGUgcHJvY2Vzc29yLCBpZiB0aGUgbGlzdCBpcyBl
bXB0eSB0aGUgaWRsZQ0KKyAqIHRhc2sgd2lsbCBydW4uIEFzIHdlIGFyZSBpbXBsZW1lbnRpbmcg
RURGLCB0aGlzIGxpc3QgaXMgc29ydGVkIGJ5IGRlYWRsaW5lcy4NCiAgKi8gDQogRE9NQUlOX0NP
TVBBUkVSKHJ1bnEsIGxpc3QsIGQxLT5kZWFkbF9hYnMsIGQyLT5kZWFkbF9hYnMpOw0KIHN0YXRp
YyBpbmxpbmUgdm9pZCBfX2FkZF90b19ydW5xdWV1ZV9zb3J0KHN0cnVjdCB2Y3B1ICp2KQ0KIHsN
Ci0gICAgUFJJTlQoMywiQWRkaW5nIGRvbWFpbiAlaS4laSAoZGVhZGw9ICUiUFJJdTY0IikgdG8g
cnVucVxuIiwNCi0gICAgICAgICAgdi0+ZG9tYWluLT5kb21haW5faWQsIHYtPnZjcHVfaWQsIEVE
T01fSU5GTyh2KS0+ZGVhZGxfYWJzKTsNCiAgICAgbGlzdF9pbnNlcnRfc29ydChSVU5RKHYtPnBy
b2Nlc3NvciksIExJU1QodiksIHJ1bnFfY29tcCk7DQogfQ0KIA0KQEAgLTQ0NSwyMiArNDAxLDIx
IEBAIHN0YXRpYyBpbnQgc2VkZl9waWNrX2NwdShjb25zdCBzdHJ1Y3Qgc2MNCiAgICAgcmV0dXJu
IGNwdW1hc2tfZmlyc3QoJm9ubGluZV9hZmZpbml0eSk7DQogfQ0KIA0KLS8qDQotICogSGFuZGxl
cyB0aGUgcmVzY2hlZHVsaW5nICYgYm9va2tlZXBpbmcgb2YgZG9tYWlucyBydW5uaW5nIGluIHRo
ZWlyDQorDQorLyogSGFuZGxlcyB0aGUgcmVzY2hlZHVsaW5nICYgYm9va2tlZXBpbmcgb2YgZG9t
YWlucyBydW5uaW5nIGluIHRoZWlyDQogICogZ3VhcmFudGVlZCB0aW1lc2xpY2UuDQogICovDQog
c3RhdGljIHZvaWQgZGVzY2hlZF9lZGZfZG9tKHNfdGltZV90IG5vdywgc3RydWN0IHZjcHUqIGQp
DQogew0KICAgICBzdHJ1Y3Qgc2VkZl92Y3B1X2luZm8qIGluZiA9IEVET01fSU5GTyhkKTsNCiAN
Ci0gICAgLyogQ3VycmVudCBkb21haW4gaXMgcnVubmluZyBpbiByZWFsIHRpbWUgbW9kZS4gKi8N
CisgICAgLyogQ3VycmVudCBkb21haW4gaXMgcnVubmluZyBpbiByZWFsIHRpbWUgbW9kZSAqLw0K
ICAgICBBU1NFUlQoX190YXNrX29uX3F1ZXVlKGQpKTsNCiANCi0gICAgLyogVXBkYXRlIHRoZSBk
b21haW4ncyBjcHV0aW1lLiAqLw0KKyAgICAvKiBVcGRhdGUgdGhlIGRvbWFpbidzIGNwdXRpbWUg
Ki8NCiAgICAgaW5mLT5jcHV0aW1lICs9IG5vdyAtIGluZi0+c2NoZWRfc3RhcnRfYWJzOw0KIA0K
LSAgICAvKg0KLSAgICAgKiBTY2hlZHVsaW5nIGRlY2lzaW9ucyB3aGljaCBkb24ndCByZW1vdmUg
dGhlIHJ1bm5pbmcgZG9tYWluIGZyb20gdGhlDQorICAgIC8qIFNjaGVkdWxpbmcgZGVjaXNpb25z
IHdoaWNoIGRvbid0IHJlbW92ZSB0aGUgcnVubmluZyBkb21haW4gZnJvbSB0aGUNCiAgICAgICog
cnVucS4gDQogICAgICAqLw0KICAgICBpZiAoIChpbmYtPmNwdXRpbWUgPCBpbmYtPnNsaWNlKSAm
JiBzZWRmX3J1bm5hYmxlKGQpICkNCkBAIC00NjgsOCArNDIzLDcgQEAgc3RhdGljIHZvaWQgZGVz
Y2hlZF9lZGZfZG9tKHNfdGltZV90IG5vdw0KICAgDQogICAgIF9fZGVsX2Zyb21fcXVldWUoZCk7
DQogICANCi0gICAgLyoNCi0gICAgICogTWFuYWdlIGJvb2trZWVwaW5nIChpLmUuIGNhbGN1bGF0
ZSBuZXh0IGRlYWRsaW5lLCBtZW1vcmlzZQ0KKyAgICAvKiBNYW5hZ2UgYm9va2tlZXBpbmcgKGku
ZS4gY2FsY3VsYXRlIG5leHQgZGVhZGxpbmUsIG1lbW9yaXNlDQogICAgICAqIG92ZXJydW4tdGlt
ZSBvZiBzbGljZSkgb2YgZmluaXNoZWQgZG9tYWlucy4NCiAgICAgICovDQogICAgIGlmICggaW5m
LT5jcHV0aW1lID49IGluZi0+c2xpY2UgKQ0KQEAgLTQ3OCwzMCArNDMyLDMwIEBAIHN0YXRpYyB2
b2lkIGRlc2NoZWRfZWRmX2RvbShzX3RpbWVfdCBub3cNCiAgIA0KICAgICAgICAgaWYgKCBpbmYt
PnBlcmlvZCA8IGluZi0+cGVyaW9kX29yaWcgKQ0KICAgICAgICAgew0KLSAgICAgICAgICAgIC8q
IFRoaXMgZG9tYWluIHJ1bnMgaW4gbGF0ZW5jeSBzY2FsaW5nIG9yIGJ1cnN0IG1vZGUuICovDQor
ICAgICAgICAgICAgLyogVGhpcyBkb21haW4gcnVucyBpbiBsYXRlbmN5IHNjYWxpbmcgb3IgYnVy
c3QgbW9kZSAqLw0KICAgICAgICAgICAgIGluZi0+cGVyaW9kICo9IDI7DQogICAgICAgICAgICAg
aW5mLT5zbGljZSAgKj0gMjsNCiAgICAgICAgICAgICBpZiAoIChpbmYtPnBlcmlvZCA+IGluZi0+
cGVyaW9kX29yaWcpIHx8DQogICAgICAgICAgICAgICAgICAoaW5mLT5zbGljZSA+IGluZi0+c2xp
Y2Vfb3JpZykgKQ0KICAgICAgICAgICAgIHsNCi0gICAgICAgICAgICAgICAgLyogUmVzZXQgc2xp
Y2UgYW5kIHBlcmlvZC4gKi8NCisgICAgICAgICAgICAgICAgLyogUmVzZXQgc2xpY2UgYW5kIHBl
cmlvZCAqLw0KICAgICAgICAgICAgICAgICBpbmYtPnBlcmlvZCA9IGluZi0+cGVyaW9kX29yaWc7
DQogICAgICAgICAgICAgICAgIGluZi0+c2xpY2UgPSBpbmYtPnNsaWNlX29yaWc7DQogICAgICAg
ICAgICAgfQ0KICAgICAgICAgfQ0KIA0KLSAgICAgICAgLyogU2V0IG5leHQgZGVhZGxpbmUuICov
DQorICAgICAgICAvKiBTZXQgbmV4dCBkZWFkbGluZSAqLw0KICAgICAgICAgaW5mLT5kZWFkbF9h
YnMgKz0gaW5mLT5wZXJpb2Q7DQogICAgIH0NCiAgDQotICAgIC8qIEFkZCBhIHJ1bm5hYmxlIGRv
bWFpbiB0byB0aGUgd2FpdHF1ZXVlLiAqLw0KKyAgICAvKiBBZGQgYSBydW5uYWJsZSBkb21haW4g
dG8gdGhlIHdhaXRxdWV1ZSAqLw0KICAgICBpZiAoIHNlZGZfcnVubmFibGUoZCkgKQ0KICAgICB7
DQogICAgICAgICBfX2FkZF90b193YWl0cXVldWVfc29ydChkKTsNCiAgICAgfQ0KICAgICBlbHNl
DQogICAgIHsNCi0gICAgICAgIC8qIFdlIGhhdmUgYSBibG9ja2VkIHJlYWx0aW1lIHRhc2sgLT4g
cmVtb3ZlIGl0IGZyb20gZXhxcyB0b28uICovDQorICAgICAgICAvKiBXZSBoYXZlIGEgYmxvY2tl
ZCByZWFsdGltZSB0YXNrIC0+IHJlbW92ZSBpdCBmcm9tIGV4cXMgdG9vICovDQogICAgICAgICBp
ZiAoIGV4dHJhcV9vbihkLCBFWFRSQV9QRU5fUSkgKQ0KICAgICAgICAgICAgIGV4dHJhcV9kZWwo
ZCwgRVhUUkFfUEVOX1EpOw0KICAgICAgICAgaWYgKCBleHRyYXFfb24oZCwgRVhUUkFfVVRJTF9R
KSApDQpAQCAtNTIxLDczICs0NzUsNTkgQEAgc3RhdGljIHZvaWQgdXBkYXRlX3F1ZXVlcygNCiAg
ICAgc3RydWN0IGxpc3RfaGVhZCAgICAgKmN1ciwgKnRtcDsNCiAgICAgc3RydWN0IHNlZGZfdmNw
dV9pbmZvICpjdXJpbmY7DQogIA0KLSAgICBQUklOVCgzLCJVcGRhdGluZyB3YWl0cS4uXG4iKTsN
Ci0NCi0gICAgLyoNCi0gICAgICogQ2hlY2sgZm9yIHRoZSBmaXJzdCBlbGVtZW50cyBvZiB0aGUg
d2FpdHF1ZXVlLCB3aGV0aGVyIHRoZWlyDQorICAgIC8qIENoZWNrIGZvciB0aGUgZmlyc3QgZWxl
bWVudHMgb2YgdGhlIHdhaXRxdWV1ZSwgd2hldGhlciB0aGVpcg0KICAgICAgKiBuZXh0IHBlcmlv
ZCBoYXMgYWxyZWFkeSBzdGFydGVkLg0KICAgICAgKi8NCiAgICAgbGlzdF9mb3JfZWFjaF9zYWZl
ICggY3VyLCB0bXAsIHdhaXRxICkNCiAgICAgew0KICAgICAgICAgY3VyaW5mID0gbGlzdF9lbnRy
eShjdXIsIHN0cnVjdCBzZWRmX3ZjcHVfaW5mbywgbGlzdCk7DQotICAgICAgICBQUklOVCg0LCJc
dExvb2tpbmcgQCBkb20gJWkuJWlcbiIsDQotICAgICAgICAgICAgICBjdXJpbmYtPnZjcHUtPmRv
bWFpbi0+ZG9tYWluX2lkLCBjdXJpbmYtPnZjcHUtPnZjcHVfaWQpOw0KICAgICAgICAgaWYgKCBQ
RVJJT0RfQkVHSU4oY3VyaW5mKSA+IG5vdyApDQogICAgICAgICAgICAgYnJlYWs7DQogICAgICAg
ICBfX2RlbF9mcm9tX3F1ZXVlKGN1cmluZi0+dmNwdSk7DQogICAgICAgICBfX2FkZF90b19ydW5x
dWV1ZV9zb3J0KGN1cmluZi0+dmNwdSk7DQogICAgIH0NCiAgDQotICAgIFBSSU5UKDMsIlVwZGF0
aW5nIHJ1bnEuLlxuIik7DQotDQotICAgIC8qIFByb2Nlc3MgdGhlIHJ1bnEsIGZpbmQgZG9tYWlu
cyB0aGF0IGFyZSBvbiB0aGUgcnVucSB0aGF0IHNob3VsZG4ndC4gKi8NCisgICAgLyogUHJvY2Vz
cyB0aGUgcnVucSwgZmluZCBkb21haW5zIHRoYXQgYXJlIG9uIHRoZSBydW5xIHRoYXQgc2hvdWxk
bid0ICovDQogICAgIGxpc3RfZm9yX2VhY2hfc2FmZSAoIGN1ciwgdG1wLCBydW5xICkNCiAgICAg
ew0KICAgICAgICAgY3VyaW5mID0gbGlzdF9lbnRyeShjdXIsc3RydWN0IHNlZGZfdmNwdV9pbmZv
LGxpc3QpOw0KLSAgICAgICAgUFJJTlQoNCwiXHRMb29raW5nIEAgZG9tICVpLiVpXG4iLA0KLSAg
ICAgICAgICAgICAgY3VyaW5mLT52Y3B1LT5kb21haW4tPmRvbWFpbl9pZCwgY3VyaW5mLT52Y3B1
LT52Y3B1X2lkKTsNCiANCiAgICAgICAgIGlmICggdW5saWtlbHkoY3VyaW5mLT5zbGljZSA9PSAw
KSApDQogICAgICAgICB7DQotICAgICAgICAgICAgLyogSWdub3JlIGRvbWFpbnMgd2l0aCBlbXB0
eSBzbGljZS4gKi8NCi0gICAgICAgICAgICBQUklOVCg0LCJcdFVwZGF0aW5nIHplcm8tc2xpY2Ug
ZG9tYWluICVpLiVpXG4iLA0KLSAgICAgICAgICAgICAgICAgIGN1cmluZi0+dmNwdS0+ZG9tYWlu
LT5kb21haW5faWQsDQotICAgICAgICAgICAgICAgICAgY3VyaW5mLT52Y3B1LT52Y3B1X2lkKTsN
CisgICAgICAgICAgICAvKiBJZ25vcmUgZG9tYWlucyB3aXRoIGVtcHR5IHNsaWNlICovDQogICAg
ICAgICAgICAgX19kZWxfZnJvbV9xdWV1ZShjdXJpbmYtPnZjcHUpOw0KIA0KLSAgICAgICAgICAg
IC8qIE1vdmUgdGhlbSB0byB0aGVpciBuZXh0IHBlcmlvZC4gKi8NCisgICAgICAgICAgICAvKiBN
b3ZlIHRoZW0gdG8gdGhlaXIgbmV4dCBwZXJpb2QgKi8NCiAgICAgICAgICAgICBjdXJpbmYtPmRl
YWRsX2FicyArPSBjdXJpbmYtPnBlcmlvZDsNCiANCi0gICAgICAgICAgICAvKiBFbnN1cmUgdGhh
dCB0aGUgc3RhcnQgb2YgdGhlIG5leHQgcGVyaW9kIGlzIGluIHRoZSBmdXR1cmUuICovDQorICAg
ICAgICAgICAgLyogRW5zdXJlIHRoYXQgdGhlIHN0YXJ0IG9mIHRoZSBuZXh0IHBlcmlvZCBpcyBp
biB0aGUgZnV0dXJlICovDQogICAgICAgICAgICAgaWYgKCB1bmxpa2VseShQRVJJT0RfQkVHSU4o
Y3VyaW5mKSA8IG5vdykgKQ0KICAgICAgICAgICAgICAgICBjdXJpbmYtPmRlYWRsX2FicyArPSAN
CiAgICAgICAgICAgICAgICAgICAgIChESVZfVVAobm93IC0gUEVSSU9EX0JFR0lOKGN1cmluZiks
DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgIGN1cmluZi0+cGVyaW9kKSkgKiBjdXJpbmYt
PnBlcmlvZDsNCiANCi0gICAgICAgICAgICAvKiBQdXQgdGhlbSBiYWNrIGludG8gdGhlIHF1ZXVl
LiAqLw0KKyAgICAgICAgICAgIC8qIFB1dCB0aGVtIGJhY2sgaW50byB0aGUgcXVldWUgKi8NCiAg
ICAgICAgICAgICBfX2FkZF90b193YWl0cXVldWVfc29ydChjdXJpbmYtPnZjcHUpOw0KICAgICAg
ICAgfQ0KICAgICAgICAgZWxzZSBpZiAoIHVubGlrZWx5KChjdXJpbmYtPmRlYWRsX2FicyA8IG5v
dykgfHwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAoY3VyaW5mLT5jcHV0aW1lID4gY3Vy
aW5mLT5zbGljZSkpICkNCiAgICAgICAgIHsNCi0gICAgICAgICAgICAvKg0KLSAgICAgICAgICAg
ICAqIFdlIG1pc3NlZCB0aGUgZGVhZGxpbmUgb3IgdGhlIHNsaWNlIHdhcyBhbHJlYWR5IGZpbmlz
aGVkLg0KKyAgICAgICAgICAgIC8qIFdlIG1pc3NlZCB0aGUgZGVhZGxpbmUgb3IgdGhlIHNsaWNl
IHdhcyBhbHJlYWR5IGZpbmlzaGVkLg0KICAgICAgICAgICAgICAqIE1pZ2h0IGhhcGVuIGJlY2F1
c2Ugb2YgZG9tX2Fkai4NCiAgICAgICAgICAgICAgKi8NCi0gICAgICAgICAgICBQUklOVCg0LCJc
dERvbWFpbiAlaS4laSBleGNlZWRlZCBpdCdzIGRlYWRsaW5lLyINCi0gICAgICAgICAgICAgICAg
ICAic2xpY2UgKCUiUFJJdTY0IiAvICUiUFJJdTY0Iikgbm93OiAlIlBSSXU2NA0KLSAgICAgICAg
ICAgICAgICAgICIgY3B1dGltZTogJSJQUkl1NjQiXG4iLA0KLSAgICAgICAgICAgICAgICAgIGN1
cmluZi0+dmNwdS0+ZG9tYWluLT5kb21haW5faWQsDQotICAgICAgICAgICAgICAgICAgY3VyaW5m
LT52Y3B1LT52Y3B1X2lkLA0KLSAgICAgICAgICAgICAgICAgIGN1cmluZi0+ZGVhZGxfYWJzLCBj
dXJpbmYtPnNsaWNlLCBub3csDQotICAgICAgICAgICAgICAgICAgY3VyaW5mLT5jcHV0aW1lKTsN
CisgICAgICAgICAgICBwcmludGsoIlx0RG9tYWluICVpLiVpIGV4Y2VlZGVkIGl0J3MgZGVhZGxp
bmUvIg0KKyAgICAgICAgICAgICAgICAgICAic2xpY2UgKCUiUFJJdTY0IiAvICUiUFJJdTY0Iikg
bm93OiAlIlBSSXU2NA0KKyAgICAgICAgICAgICAgICAgICAiIGNwdXRpbWU6ICUiUFJJdTY0Ilxu
IiwNCisgICAgICAgICAgICAgICAgICAgY3VyaW5mLT52Y3B1LT5kb21haW4tPmRvbWFpbl9pZCwN
CisgICAgICAgICAgICAgICAgICAgY3VyaW5mLT52Y3B1LT52Y3B1X2lkLA0KKyAgICAgICAgICAg
ICAgICAgICBjdXJpbmYtPmRlYWRsX2FicywgY3VyaW5mLT5zbGljZSwgbm93LA0KKyAgICAgICAg
ICAgICAgICAgICBjdXJpbmYtPmNwdXRpbWUpOw0KICAgICAgICAgICAgIF9fZGVsX2Zyb21fcXVl
dWUoY3VyaW5mLT52Y3B1KTsNCiANCi0gICAgICAgICAgICAvKiBDb21tb24gY2FzZTogd2UgbWlz
cyBvbmUgcGVyaW9kLiAqLw0KKyAgICAgICAgICAgIC8qIENvbW1vbiBjYXNlOiB3ZSBtaXNzIG9u
ZSBwZXJpb2QgKi8NCiAgICAgICAgICAgICBjdXJpbmYtPmRlYWRsX2FicyArPSBjdXJpbmYtPnBl
cmlvZDsNCiAgICANCi0gICAgICAgICAgICAvKg0KLSAgICAgICAgICAgICAqIElmIHdlIGFyZSBz
dGlsbCBiZWhpbmQ6IG1vZHVsbyBhcml0aG1ldGljLCBmb3JjZSBkZWFkbGluZQ0KKyAgICAgICAg
ICAgIC8qIElmIHdlIGFyZSBzdGlsbCBiZWhpbmQ6IG1vZHVsbyBhcml0aG1ldGljLCBmb3JjZSBk
ZWFkbGluZQ0KICAgICAgICAgICAgICAqIHRvIGJlIGluIGZ1dHVyZSBhbmQgYWxpZ25lZCB0byBw
ZXJpb2QgYm9yZGVycy4NCiAgICAgICAgICAgICAgKi8NCiAgICAgICAgICAgICBpZiAoIHVubGlr
ZWx5KGN1cmluZi0+ZGVhZGxfYWJzIDwgbm93KSApDQpAQCAtNTk2LDcgKzUzNiw3IEBAIHN0YXRp
YyB2b2lkIHVwZGF0ZV9xdWV1ZXMoDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgY3VyaW5m
LT5wZXJpb2QpICogY3VyaW5mLT5wZXJpb2Q7DQogICAgICAgICAgICAgQVNTRVJUKGN1cmluZi0+
ZGVhZGxfYWJzID49IG5vdyk7DQogDQotICAgICAgICAgICAgLyogR2l2ZSBhIGZyZXNoIHNsaWNl
LiAqLw0KKyAgICAgICAgICAgIC8qIEdpdmUgYSBmcmVzaCBzbGljZSAqLw0KICAgICAgICAgICAg
IGN1cmluZi0+Y3B1dGltZSA9IDA7DQogICAgICAgICAgICAgaWYgKCBQRVJJT0RfQkVHSU4oY3Vy
aW5mKSA+IG5vdyApDQogICAgICAgICAgICAgICAgIF9fYWRkX3RvX3dhaXRxdWV1ZV9zb3J0KGN1
cmluZi0+dmNwdSk7DQpAQCAtNjA2LDE3ICs1NDYsMTYgQEAgc3RhdGljIHZvaWQgdXBkYXRlX3F1
ZXVlcygNCiAgICAgICAgIGVsc2UNCiAgICAgICAgICAgICBicmVhazsNCiAgICAgfQ0KLQ0KLSAg
ICBQUklOVCgzLCJkb25lIHVwZGF0aW5nIHRoZSBxdWV1ZXNcbiIpOw0KIH0NCiANCiANCiAvKiBy
ZW1vdmVzIGEgZG9tYWluIGZyb20gdGhlIGhlYWQgb2YgdGhlIGFjY29yZGluZyBleHRyYVEgYW5k
DQotICAgcmVxdWV1ZXMgaXQgYXQgYSBzcGVjaWZpZWQgcG9zaXRpb246DQotICAgICByb3VuZC1y
b2JpbiBleHRyYXRpbWU6IGVuZCBvZiBleHRyYVENCi0gICAgIHdlaWdodGVkIGV4dC46IGluc2Vy
dCBpbiBzb3J0ZWQgbGlzdCBieSBzY29yZQ0KLSAgIGlmIHRoZSBkb21haW4gaXMgYmxvY2tlZCAv
IGhhcyByZWdhaW5lZCBpdHMgc2hvcnQtYmxvY2stbG9zcw0KLSAgIHRpbWUgaXQgaXMgbm90IHB1
dCBvbiBhbnkgcXVldWUgKi8NCisgKiByZXF1ZXVlcyBpdCBhdCBhIHNwZWNpZmllZCBwb3NpdGlv
bjoNCisgKiAgIHJvdW5kLXJvYmluIGV4dHJhdGltZTogZW5kIG9mIGV4dHJhUQ0KKyAqICAgd2Vp
Z2h0ZWQgZXh0LjogaW5zZXJ0IGluIHNvcnRlZCBsaXN0IGJ5IHNjb3JlDQorICogaWYgdGhlIGRv
bWFpbiBpcyBibG9ja2VkIC8gaGFzIHJlZ2FpbmVkIGl0cyBzaG9ydC1ibG9jay1sb3NzDQorICog
dGltZSBpdCBpcyBub3QgcHV0IG9uIGFueSBxdWV1ZS4NCisgKi8NCiBzdGF0aWMgdm9pZCBkZXNj
aGVkX2V4dHJhX2RvbShzX3RpbWVfdCBub3csIHN0cnVjdCB2Y3B1ICpkKQ0KIHsNCiAgICAgc3Ry
dWN0IHNlZGZfdmNwdV9pbmZvICppbmYgPSBFRE9NX0lORk8oZCk7DQpAQCAtNjI1LDI5ICs1NjQs
MjUgQEAgc3RhdGljIHZvaWQgZGVzY2hlZF9leHRyYV9kb20oc190aW1lX3Qgbg0KIA0KICAgICBB
U1NFUlQoZXh0cmFxX29uKGQsIGkpKTsNCiANCi0gICAgLyogVW5zZXQgYWxsIHJ1bm5pbmcgZmxh
Z3MuICovDQorICAgIC8qIFVuc2V0IGFsbCBydW5uaW5nIGZsYWdzICovDQogICAgIGluZi0+c3Rh
dHVzICAmPSB+KEVYVFJBX1JVTl9QRU4gfCBFWFRSQV9SVU5fVVRJTCk7DQotICAgIC8qIEZyZXNo
IHNsaWNlIGZvciB0aGUgbmV4dCBydW4uICovDQorICAgIC8qIEZyZXNoIHNsaWNlIGZvciB0aGUg
bmV4dCBydW4gKi8NCiAgICAgaW5mLT5jcHV0aW1lID0gMDsNCi0gICAgLyogQWNjdW11bGF0ZSB0
b3RhbCBleHRyYXRpbWUuICovDQorICAgIC8qIEFjY3VtdWxhdGUgdG90YWwgZXh0cmF0aW1lICov
DQogICAgIGluZi0+ZXh0cmFfdGltZV90b3QgKz0gbm93IC0gaW5mLT5zY2hlZF9zdGFydF9hYnM7
DQogICAgIC8qIFJlbW92ZSBleHRyYWRvbWFpbiBmcm9tIGhlYWQgb2YgdGhlIHF1ZXVlLiAqLw0K
ICAgICBleHRyYXFfZGVsKGQsIGkpOw0KIA0KLSAgICAvKiBVcGRhdGUgdGhlIHNjb3JlLiAqLw0K
KyAgICAvKiBVcGRhdGUgdGhlIHNjb3JlICovDQogICAgIG9sZHNjb3JlID0gaW5mLT5zY29yZVtp
XTsNCiAgICAgaWYgKCBpID09IEVYVFJBX1BFTl9RICkNCiAgICAgew0KLSAgICAgICAgLypkb21h
aW4gd2FzIHJ1bm5pbmcgaW4gTDAgZXh0cmFxKi8NCi0gICAgICAgIC8qcmVkdWNlIGJsb2NrIGxv
c3QsIHByb2JhYmx5IG1vcmUgc29waGlzdGljYXRpb24gaGVyZSEqLw0KKyAgICAgICAgLyogRG9t
YWluIHdhcyBydW5uaW5nIGluIEwwIGV4dHJhcSAqLw0KKyAgICAgICAgLyogcmVkdWNlIGJsb2Nr
IGxvc3QsIHByb2JhYmx5IG1vcmUgc29waGlzdGljYXRpb24gaGVyZSEqLw0KICAgICAgICAgLypp
bmYtPnNob3J0X2Jsb2NrX2xvc3RfdG90IC09IEVYVFJBX1FVQU5UVU07Ki8NCiAgICAgICAgIGlu
Zi0+c2hvcnRfYmxvY2tfbG9zdF90b3QgLT0gbm93IC0gaW5mLT5zY2hlZF9zdGFydF9hYnM7DQot
ICAgICAgICBQUklOVCgzLCJEb21haW4gJWkuJWk6IFNob3J0X2Jsb2NrX2xvc3M6ICUiUFJJaTY0
IlxuIiwgDQotICAgICAgICAgICAgICBpbmYtPnZjcHUtPmRvbWFpbi0+ZG9tYWluX2lkLCBpbmYt
PnZjcHUtPnZjcHVfaWQsDQotICAgICAgICAgICAgICBpbmYtPnNob3J0X2Jsb2NrX2xvc3RfdG90
KTsNCiAjaWYgMA0KLSAgICAgICAgLyoNCi0gICAgICAgICAqIEtBRjogSWYgd2UgZG9uJ3QgZXhp
dCBzaG9ydC1ibG9ja2luZyBzdGF0ZSBhdCB0aGlzIHBvaW50DQorICAgICAgICAvKiBLQUY6IElm
IHdlIGRvbid0IGV4aXQgc2hvcnQtYmxvY2tpbmcgc3RhdGUgYXQgdGhpcyBwb2ludA0KICAgICAg
ICAgICogZG9tYWluMCBjYW4gc3RlYWwgYWxsIENQVSBmb3IgdXAgdG8gMTAgc2Vjb25kcyBiZWZv
cmUNCiAgICAgICAgICAqIHNjaGVkdWxpbmcgc2V0dGxlcyBkb3duICh3aGVuIGNvbXBldGluZyBh
Z2FpbnN0IGFub3RoZXINCiAgICAgICAgICAqIENQVS1ib3VuZCBkb21haW4pLiBEb2luZyB0aGlz
IHNlZW1zIHRvIG1ha2UgdGhpbmdzIGJlaGF2ZQ0KQEAgLTY1Niw1MSArNTkxLDU2IEBAIHN0YXRp
YyB2b2lkIGRlc2NoZWRfZXh0cmFfZG9tKHNfdGltZV90IG4NCiAgICAgICAgIGlmICggaW5mLT5z
aG9ydF9ibG9ja19sb3N0X3RvdCA8PSAwICkNCiAjZW5kaWYNCiAgICAgICAgIHsNCi0gICAgICAg
ICAgICBQUklOVCg0LCJEb21haW4gJWkuJWkgY29tcGVuc2F0ZWQgc2hvcnQgYmxvY2sgbG9zcyFc
biIsDQotICAgICAgICAgICAgICAgICAgaW5mLT52Y3B1LT5kb21haW4tPmRvbWFpbl9pZCwgaW5m
LT52Y3B1LT52Y3B1X2lkKTsNCi0gICAgICAgICAgICAvKndlIGhhdmUgKG92ZXItKWNvbXBlbnNh
dGVkIG91ciBibG9jayBwZW5hbHR5Ki8NCisgICAgICAgICAgICAvKiBXZSBoYXZlIChvdmVyLSlj
b21wZW5zYXRlZCBvdXIgYmxvY2sgcGVuYWx0eSAqLw0KICAgICAgICAgICAgIGluZi0+c2hvcnRf
YmxvY2tfbG9zdF90b3QgPSAwOw0KLSAgICAgICAgICAgIC8qd2UgZG9uJ3Qgd2FudCBhIHBsYWNl
IG9uIHRoZSBwZW5hbHR5IHF1ZXVlIGFueW1vcmUhKi8NCisgICAgICAgICAgICAvKiBXZSBkb24n
dCB3YW50IGEgcGxhY2Ugb24gdGhlIHBlbmFsdHkgcXVldWUgYW55bW9yZSEgKi8NCiAgICAgICAg
ICAgICBpbmYtPnN0YXR1cyAmPSB+RVhUUkFfV0FOVF9QRU5fUTsNCiAgICAgICAgICAgICBnb3Rv
IGNoZWNrX2V4dHJhX3F1ZXVlczsNCiAgICAgICAgIH0NCiANCi0gICAgICAgIC8qd2UgaGF2ZSB0
byBnbyBhZ2FpbiBmb3IgYW5vdGhlciB0cnkgaW4gdGhlIGJsb2NrLWV4dHJhcSwNCi0gICAgICAg
ICAgdGhlIHNjb3JlIGlzIG5vdCB1c2VkIGluY3JlbWFudGFsbHkgaGVyZSwgYXMgdGhpcyBpcw0K
LSAgICAgICAgICBhbHJlYWR5IGRvbmUgYnkgcmVjYWxjdWxhdGluZyB0aGUgYmxvY2tfbG9zdCov
DQorICAgICAgICAvKiBXZSBoYXZlIHRvIGdvIGFnYWluIGZvciBhbm90aGVyIHRyeSBpbiB0aGUg
YmxvY2stZXh0cmFxLA0KKyAgICAgICAgICogdGhlIHNjb3JlIGlzIG5vdCB1c2VkIGluY3JlbWFu
dGFsbHkgaGVyZSwgYXMgdGhpcyBpcw0KKyAgICAgICAgICogYWxyZWFkeSBkb25lIGJ5IHJlY2Fs
Y3VsYXRpbmcgdGhlIGJsb2NrX2xvc3QNCisgICAgICAgICAqLw0KICAgICAgICAgaW5mLT5zY29y
ZVtFWFRSQV9QRU5fUV0gPSAoaW5mLT5wZXJpb2QgPDwgMTApIC8NCiAgICAgICAgICAgICBpbmYt
PnNob3J0X2Jsb2NrX2xvc3RfdG90Ow0KICAgICAgICAgb2xkc2NvcmUgPSAwOw0KICAgICB9DQog
ICAgIGVsc2UNCiAgICAgew0KLSAgICAgICAgLypkb21haW4gd2FzIHJ1bm5pbmcgaW4gTDEgZXh0
cmFxID0+IHNjb3JlIGlzIGludmVyc2Ugb2YNCi0gICAgICAgICAgdXRpbGl6YXRpb24gYW5kIGlz
IHVzZWQgc29tZXdoYXQgaW5jcmVtZW50YWwhKi8NCisgICAgICAgIC8qIERvbWFpbiB3YXMgcnVu
bmluZyBpbiBMMSBleHRyYXEgPT4gc2NvcmUgaXMgaW52ZXJzZSBvZg0KKyAgICAgICAgICogdXRp
bGl6YXRpb24gYW5kIGlzIHVzZWQgc29tZXdoYXQgaW5jcmVtZW50YWwhDQorICAgICAgICAgKi8N
CiAgICAgICAgIGlmICggIWluZi0+ZXh0cmF3ZWlnaHQgKQ0KLSAgICAgICAgICAgIC8qTkI6IHVz
ZSBmaXhlZCBwb2ludCBhcml0aG1ldGljIHdpdGggMTAgYml0cyovDQorICAgICAgICB7DQorICAg
ICAgICAgICAgLyogTkI6IHVzZSBmaXhlZCBwb2ludCBhcml0aG1ldGljIHdpdGggMTAgYml0cyAq
Lw0KICAgICAgICAgICAgIGluZi0+c2NvcmVbRVhUUkFfVVRJTF9RXSA9IChpbmYtPnBlcmlvZCA8
PCAxMCkgLw0KICAgICAgICAgICAgICAgICBpbmYtPnNsaWNlOw0KKyAgICAgICAgfQ0KICAgICAg
ICAgZWxzZQ0KLSAgICAgICAgICAgIC8qY29udmVyc2lvbiBiZXR3ZWVuIHJlYWx0aW1lIHV0aWxp
c2F0aW9uIGFuZCBleHRyYXdpZWdodDoNCi0gICAgICAgICAgICAgIGZ1bGwgKGllIDEwMCUpIHV0
aWxpemF0aW9uIGlzIGVxdWl2YWxlbnQgdG8gMTI4IGV4dHJhd2VpZ2h0Ki8NCisgICAgICAgIHsN
CisgICAgICAgICAgICAvKiBDb252ZXJzaW9uIGJldHdlZW4gcmVhbHRpbWUgdXRpbGlzYXRpb24g
YW5kIGV4dHJhd2llZ2h0Og0KKyAgICAgICAgICAgICAqIGZ1bGwgKGllIDEwMCUpIHV0aWxpemF0
aW9uIGlzIGVxdWl2YWxlbnQgdG8gMTI4IGV4dHJhd2VpZ2h0DQorICAgICAgICAgICAgICovDQog
ICAgICAgICAgICAgaW5mLT5zY29yZVtFWFRSQV9VVElMX1FdID0gKDE8PDE3KSAvIGluZi0+ZXh0
cmF3ZWlnaHQ7DQorICAgICAgICB9DQogICAgIH0NCiANCiAgY2hlY2tfZXh0cmFfcXVldWVzOg0K
LSAgICAvKiBBZGRpbmcgYSBydW5uYWJsZSBkb21haW4gdG8gdGhlIHJpZ2h0IHF1ZXVlIGFuZCBy
ZW1vdmluZyBibG9ja2VkIG9uZXMqLw0KKyAgICAvKiBBZGRpbmcgYSBydW5uYWJsZSBkb21haW4g
dG8gdGhlIHJpZ2h0IHF1ZXVlIGFuZCByZW1vdmluZyBibG9ja2VkIG9uZXMgKi8NCiAgICAgaWYg
KCBzZWRmX3J1bm5hYmxlKGQpICkNCiAgICAgew0KLSAgICAgICAgLyphZGQgYWNjb3JkaW5nIHRv
IHNjb3JlOiB3ZWlnaHRlZCByb3VuZCByb2JpbiovDQorICAgICAgICAvKiBBZGQgYWNjb3JkaW5n
IHRvIHNjb3JlOiB3ZWlnaHRlZCByb3VuZCByb2JpbiAqLw0KICAgICAgICAgaWYgKCgoaW5mLT5z
dGF0dXMgJiBFWFRSQV9BV0FSRSkgJiYgKGkgPT0gRVhUUkFfVVRJTF9RKSkgfHwNCiAgICAgICAg
ICAgICAoKGluZi0+c3RhdHVzICYgRVhUUkFfV0FOVF9QRU5fUSkgJiYgKGkgPT0gRVhUUkFfUEVO
X1EpKSkNCiAgICAgICAgICAgICBleHRyYXFfYWRkX3NvcnRfdXBkYXRlKGQsIGksIG9sZHNjb3Jl
KTsNCiAgICAgfQ0KICAgICBlbHNlDQogICAgIHsNCi0gICAgICAgIC8qcmVtb3ZlIHRoaXMgYmxv
Y2tlZCBkb21haW4gZnJvbSB0aGUgd2FpdHEhKi8NCisgICAgICAgIC8qIFJlbW92ZSB0aGlzIGJs
b2NrZWQgZG9tYWluIGZyb20gdGhlIHdhaXRxISAqLw0KICAgICAgICAgX19kZWxfZnJvbV9xdWV1
ZShkKTsNCi0gICAgICAgIC8qbWFrZSBzdXJlIHRoYXQgd2UgcmVtb3ZlIGEgYmxvY2tlZCBkb21h
aW4gZnJvbSB0aGUgb3RoZXINCi0gICAgICAgICAgZXh0cmFxIHRvbyovDQorICAgICAgICAvKiBN
YWtlIHN1cmUgdGhhdCB3ZSByZW1vdmUgYSBibG9ja2VkIGRvbWFpbiBmcm9tIHRoZSBvdGhlcg0K
KyAgICAgICAgICogZXh0cmFxIHRvby4gKi8NCiAgICAgICAgIGlmICggaSA9PSBFWFRSQV9QRU5f
USApDQogICAgICAgICB7DQogICAgICAgICAgICAgaWYgKCBleHRyYXFfb24oZCwgRVhUUkFfVVRJ
TF9RKSApDQpAQCAtNzMyLDggKzY3Miw5IEBAIHN0YXRpYyBzdHJ1Y3QgdGFza19zbGljZSBzZWRm
X2RvX2V4dHJhX3MNCiANCiAgICAgaWYgKCAhbGlzdF9lbXB0eShleHRyYXFbRVhUUkFfUEVOX1Fd
KSApDQogICAgIHsNCi0gICAgICAgIC8qd2Ugc3RpbGwgaGF2ZSBlbGVtZW50cyBvbiB0aGUgbGV2
ZWwgMCBleHRyYXEgDQotICAgICAgICAgID0+IGxldCB0aG9zZSBydW4gZmlyc3QhKi8NCisgICAg
ICAgIC8qIFdlIHN0aWxsIGhhdmUgZWxlbWVudHMgb24gdGhlIGxldmVsIDAgZXh0cmFxDQorICAg
ICAgICAgKiA9PiBsZXQgdGhvc2UgcnVuIGZpcnN0IQ0KKyAgICAgICAgICovDQogICAgICAgICBy
dW5pbmYgICA9IGxpc3RfZW50cnkoZXh0cmFxW0VYVFJBX1BFTl9RXS0+bmV4dCwgDQogICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgc3RydWN0IHNlZGZfdmNwdV9pbmZvLCBleHRyYWxpc3Rb
RVhUUkFfUEVOX1FdKTsNCiAgICAgICAgIHJ1bmluZi0+c3RhdHVzIHw9IEVYVFJBX1JVTl9QRU47
DQpAQCAtNzQ3LDcgKzY4OCw3IEBAIHN0YXRpYyBzdHJ1Y3QgdGFza19zbGljZSBzZWRmX2RvX2V4
dHJhX3MNCiAgICAgew0KICAgICAgICAgaWYgKCAhbGlzdF9lbXB0eShleHRyYXFbRVhUUkFfVVRJ
TF9RXSkgKQ0KICAgICAgICAgew0KLSAgICAgICAgICAgIC8qdXNlIGVsZW1lbnRzIGZyb20gdGhl
IG5vcm1hbCBleHRyYXF1ZXVlKi8NCisgICAgICAgICAgICAvKiBVc2UgZWxlbWVudHMgZnJvbSB0
aGUgbm9ybWFsIGV4dHJhcXVldWUgKi8NCiAgICAgICAgICAgICBydW5pbmYgICA9IGxpc3RfZW50
cnkoZXh0cmFxW0VYVFJBX1VUSUxfUV0tPm5leHQsDQogICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgIHN0cnVjdCBzZWRmX3ZjcHVfaW5mbywNCiAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgZXh0cmFsaXN0W0VYVFJBX1VUSUxfUV0pOw0KQEAgLTc3MywxMCArNzE0LDEx
IEBAIHN0YXRpYyBzdHJ1Y3QgdGFza19zbGljZSBzZWRmX2RvX2V4dHJhX3MNCiANCiANCiAvKiBN
YWluIHNjaGVkdWxpbmcgZnVuY3Rpb24NCi0gICBSZWFzb25zIGZvciBjYWxsaW5nIHRoaXMgZnVu
Y3Rpb24gYXJlOg0KLSAgIC10aW1lc2xpY2UgZm9yIHRoZSBjdXJyZW50IHBlcmlvZCB1c2VkIHVw
DQotICAgLWRvbWFpbiBvbiB3YWl0cXVldWUgaGFzIHN0YXJ0ZWQgaXQncyBwZXJpb2QNCi0gICAt
YW5kIHZhcmlvdXMgb3RoZXJzIDspIGluIGdlbmVyYWw6IGRldGVybWluZSB3aGljaCBkb21haW4g
dG8gcnVuIG5leHQqLw0KKyAqIFJlYXNvbnMgZm9yIGNhbGxpbmcgdGhpcyBmdW5jdGlvbiBhcmU6
DQorICogLXRpbWVzbGljZSBmb3IgdGhlIGN1cnJlbnQgcGVyaW9kIHVzZWQgdXANCisgKiAtZG9t
YWluIG9uIHdhaXRxdWV1ZSBoYXMgc3RhcnRlZCBpdCdzIHBlcmlvZA0KKyAqIC1hbmQgdmFyaW91
cyBvdGhlcnMgOykgaW4gZ2VuZXJhbDogZGV0ZXJtaW5lIHdoaWNoIGRvbWFpbiB0byBydW4gbmV4
dA0KKyAqLw0KIHN0YXRpYyBzdHJ1Y3QgdGFza19zbGljZSBzZWRmX2RvX3NjaGVkdWxlKA0KICAg
ICBjb25zdCBzdHJ1Y3Qgc2NoZWR1bGVyICpvcHMsIHNfdGltZV90IG5vdywgYm9vbF90IHRhc2ts
ZXRfd29ya19zY2hlZHVsZWQpDQogew0KQEAgLTc4OSwxMyArNzMxLDE0IEBAIHN0YXRpYyBzdHJ1
Y3QgdGFza19zbGljZSBzZWRmX2RvX3NjaGVkdWwNCiAgICAgc3RydWN0IHNlZGZfdmNwdV9pbmZv
ICpydW5pbmYsICp3YWl0aW5mOw0KICAgICBzdHJ1Y3QgdGFza19zbGljZSAgICAgIHJldDsNCiAN
Ci0gICAgLyppZGxlIHRhc2tzIGRvbid0IG5lZWQgYW55IG9mIHRoZSBmb2xsb3dpbmcgc3R1Ziov
DQorICAgIC8qIElkbGUgdGFza3MgZG9uJ3QgbmVlZCBhbnkgb2YgdGhlIGZvbGxvd2luZyBzdHVm
ICovDQogICAgIGlmICggaXNfaWRsZV92Y3B1KGN1cnJlbnQpICkNCiAgICAgICAgIGdvdG8gY2hl
Y2tfd2FpdHE7DQogIA0KLSAgICAvKiBjcmVhdGUgbG9jYWwgc3RhdGUgb2YgdGhlIHN0YXR1cyBv
ZiB0aGUgZG9tYWluLCBpbiBvcmRlciB0byBhdm9pZA0KLSAgICAgICBpbmNvbnNpc3RlbnQgc3Rh
dGUgZHVyaW5nIHNjaGVkdWxpbmcgZGVjaXNpb25zLCBiZWNhdXNlIGRhdGEgZm9yDQotICAgICAg
IHZjcHVfcnVubmFibGUgaXMgbm90IHByb3RlY3RlZCBieSB0aGUgc2NoZWR1bGluZyBsb2NrISov
DQorICAgIC8qIENyZWF0ZSBsb2NhbCBzdGF0ZSBvZiB0aGUgc3RhdHVzIG9mIHRoZSBkb21haW4s
IGluIG9yZGVyIHRvIGF2b2lkDQorICAgICAqIGluY29uc2lzdGVudCBzdGF0ZSBkdXJpbmcgc2No
ZWR1bGluZyBkZWNpc2lvbnMsIGJlY2F1c2UgZGF0YSBmb3INCisgICAgICogdmNwdV9ydW5uYWJs
ZSBpcyBub3QgcHJvdGVjdGVkIGJ5IHRoZSBzY2hlZHVsaW5nIGxvY2shDQorICAgICAqLw0KICAg
ICBpZiAoICF2Y3B1X3J1bm5hYmxlKGN1cnJlbnQpICkNCiAgICAgICAgIGluZi0+c3RhdHVzIHw9
IFNFREZfQVNMRUVQOw0KICANCkBAIC04MDQsNyArNzQ3LDcgQEAgc3RhdGljIHN0cnVjdCB0YXNr
X3NsaWNlIHNlZGZfZG9fc2NoZWR1bA0KIA0KICAgICBpZiAoIHVubGlrZWx5KGV4dHJhX3J1bnMo
aW5mKSkgKQ0KICAgICB7DQotICAgICAgICAvKnNwZWNpYWwgdHJlYXRtZW50IG9mIGRvbWFpbnMg
cnVubmluZyBpbiBleHRyYSB0aW1lKi8NCisgICAgICAgIC8qIFNwZWNpYWwgdHJlYXRtZW50IG9m
IGRvbWFpbnMgcnVubmluZyBpbiBleHRyYSB0aW1lICovDQogICAgICAgICBkZXNjaGVkX2V4dHJh
X2RvbShub3csIGN1cnJlbnQpOw0KICAgICB9DQogICAgIGVsc2UgDQpAQCAtODE0LDEwICs3NTcs
MTEgQEAgc3RhdGljIHN0cnVjdCB0YXNrX3NsaWNlIHNlZGZfZG9fc2NoZWR1bA0KICBjaGVja193
YWl0cToNCiAgICAgdXBkYXRlX3F1ZXVlcyhub3csIHJ1bnEsIHdhaXRxKTsNCiANCi0gICAgLypu
b3cgc2ltcGx5IHBpY2sgdGhlIGZpcnN0IGRvbWFpbiBmcm9tIHRoZSBydW5xdWV1ZSwgd2hpY2gg
aGFzIHRoZQ0KLSAgICAgIGVhcmxpZXN0IGRlYWRsaW5lLCBiZWNhdXNlIHRoZSBsaXN0IGlzIHNv
cnRlZCovDQotIA0KLSAgICAvKiBUYXNrbGV0IHdvcmsgKHdoaWNoIHJ1bnMgaW4gaWRsZSBWQ1BV
IGNvbnRleHQpIG92ZXJyaWRlcyBhbGwgZWxzZS4gKi8NCisgICAgLyogTm93IHNpbXBseSBwaWNr
IHRoZSBmaXJzdCBkb21haW4gZnJvbSB0aGUgcnVucXVldWUsIHdoaWNoIGhhcyB0aGUNCisgICAg
ICogZWFybGllc3QgZGVhZGxpbmUsIGJlY2F1c2UgdGhlIGxpc3QgaXMgc29ydGVkDQorICAgICAq
DQorICAgICAqIFRhc2tsZXQgd29yayAod2hpY2ggcnVucyBpbiBpZGxlIFZDUFUgY29udGV4dCkg
b3ZlcnJpZGVzIGFsbCBlbHNlLg0KKyAgICAgKi8NCiAgICAgaWYgKCB0YXNrbGV0X3dvcmtfc2No
ZWR1bGVkIHx8DQogICAgICAgICAgKGxpc3RfZW1wdHkocnVucSkgJiYgbGlzdF9lbXB0eSh3YWl0
cSkpIHx8DQogICAgICAgICAgdW5saWtlbHkoIWNwdW1hc2tfdGVzdF9jcHUoY3B1LCBTRURGX0NQ
VU9OTElORShwZXJfY3B1KGNwdXBvb2wsIGNwdSkpKSkgKQ0KQEAgLTgzMyw5ICs3NzcsMTAgQEAg
c3RhdGljIHN0cnVjdCB0YXNrX3NsaWNlIHNlZGZfZG9fc2NoZWR1bA0KICAgICAgICAgew0KICAg
ICAgICAgICAgIHdhaXRpbmYgID0gbGlzdF9lbnRyeSh3YWl0cS0+bmV4dCwNCiAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgc3RydWN0IHNlZGZfdmNwdV9pbmZvLGxpc3QpOw0KLSAg
ICAgICAgICAgIC8qcmVydW4gc2NoZWR1bGVyLCB3aGVuIHNjaGVkdWxlZCBkb21haW4gcmVhY2hl
cyBpdCdzDQotICAgICAgICAgICAgICBlbmQgb2Ygc2xpY2Ugb3IgdGhlIGZpcnN0IGRvbWFpbiBm
cm9tIHRoZSB3YWl0cXVldWUNCi0gICAgICAgICAgICAgIGdldHMgcmVhZHkqLw0KKyAgICAgICAg
ICAgIC8qIFJlcnVuIHNjaGVkdWxlciwgd2hlbiBzY2hlZHVsZWQgZG9tYWluIHJlYWNoZXMgaXQn
cw0KKyAgICAgICAgICAgICAqIGVuZCBvZiBzbGljZSBvciB0aGUgZmlyc3QgZG9tYWluIGZyb20g
dGhlIHdhaXRxdWV1ZQ0KKyAgICAgICAgICAgICAqIGdldHMgcmVhZHkuDQorICAgICAgICAgICAg
ICovDQogICAgICAgICAgICAgcmV0LnRpbWUgPSBNSU4obm93ICsgcnVuaW5mLT5zbGljZSAtIHJ1
bmluZi0+Y3B1dGltZSwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICBQRVJJT0RfQkVHSU4o
d2FpdGluZikpIC0gbm93Ow0KICAgICAgICAgfQ0KQEAgLTg0NywxNCArNzkyLDE1IEBAIHN0YXRp
YyBzdHJ1Y3QgdGFza19zbGljZSBzZWRmX2RvX3NjaGVkdWwNCiAgICAgZWxzZQ0KICAgICB7DQog
ICAgICAgICB3YWl0aW5mICA9IGxpc3RfZW50cnkod2FpdHEtPm5leHQsc3RydWN0IHNlZGZfdmNw
dV9pbmZvLCBsaXN0KTsNCi0gICAgICAgIC8qd2UgY291bGQgbm90IGZpbmQgYW55IHN1aXRhYmxl
IGRvbWFpbiANCi0gICAgICAgICAgPT4gbG9vayBmb3IgZG9tYWlucyB0aGF0IGFyZSBhd2FyZSBv
ZiBleHRyYXRpbWUqLw0KKyAgICAgICAgLyogV2UgY291bGQgbm90IGZpbmQgYW55IHN1aXRhYmxl
IGRvbWFpbiANCisgICAgICAgICAqID0+IGxvb2sgZm9yIGRvbWFpbnMgdGhhdCBhcmUgYXdhcmUg
b2YgZXh0cmF0aW1lKi8NCiAgICAgICAgIHJldCA9IHNlZGZfZG9fZXh0cmFfc2NoZWR1bGUobm93
LCBQRVJJT0RfQkVHSU4od2FpdGluZiksDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIGV4dHJhcSwgY3B1KTsNCiAgICAgfQ0KIA0KLSAgICAvKlRPRE86IERvIHNvbWV0aGlu
ZyBVU0VGVUwgd2hlbiB0aGlzIGhhcHBlbnMgYW5kIGZpbmQgb3V0LCB3aHkgaXQNCi0gICAgICBz
dGlsbCBjYW4gaGFwcGVuISEhKi8NCisgICAgLyogVE9ETzogRG8gc29tZXRoaW5nIFVTRUZVTCB3
aGVuIHRoaXMgaGFwcGVucyBhbmQgZmluZCBvdXQsIHdoeSBpdA0KKyAgICAgKiBzdGlsbCBjYW4g
aGFwcGVuISEhDQorICAgICAqLw0KICAgICBpZiAoIHJldC50aW1lIDwgMCkNCiAgICAgew0KICAg
ICAgICAgcHJpbnRrKCJPdWNoISBXZSBhcmUgc2VyaW91c2x5IEJFSElORCBzY2hlZHVsZSEgJSJQ
UklpNjQiXG4iLA0KQEAgLTg3NCw5ICs4MjAsNiBAQCBzdGF0aWMgc3RydWN0IHRhc2tfc2xpY2Ug
c2VkZl9kb19zY2hlZHVsDQogDQogc3RhdGljIHZvaWQgc2VkZl9zbGVlcChjb25zdCBzdHJ1Y3Qg
c2NoZWR1bGVyICpvcHMsIHN0cnVjdCB2Y3B1ICpkKQ0KIHsNCi0gICAgUFJJTlQoMiwic2VkZl9z
bGVlcCB3YXMgY2FsbGVkLCBkb21haW4taWQgJWkuJWlcbiIsDQotICAgICAgICAgIGQtPmRvbWFp
bi0+ZG9tYWluX2lkLCBkLT52Y3B1X2lkKTsNCi0gDQogICAgIGlmICggaXNfaWRsZV92Y3B1KGQp
ICkNCiAgICAgICAgIHJldHVybjsNCiANCkBAIC05NzIsMjcgKzkxNSwyOSBAQCBzdGF0aWMgdm9p
ZCBzZWRmX3NsZWVwKGNvbnN0IHN0cnVjdCBzY2hlDQogc3RhdGljIHZvaWQgdW5ibG9ja19zaG9y
dF9leHRyYV9zdXBwb3J0KA0KICAgICBzdHJ1Y3Qgc2VkZl92Y3B1X2luZm8qIGluZiwgc190aW1l
X3Qgbm93KQ0KIHsNCi0gICAgLyp0aGlzIHVuYmxvY2tpbmcgc2NoZW1lIHRyaWVzIHRvIHN1cHBv
cnQgdGhlIGRvbWFpbiwgYnkgYXNzaWduaW5nIGl0DQotICAgIGEgcHJpb3JpdHkgaW4gZXh0cmF0
aW1lIGRpc3RyaWJ1dGlvbiBhY2NvcmRpbmcgdG8gdGhlIGxvc3Mgb2YgdGltZQ0KLSAgICBpbiB0
aGlzIHNsaWNlIGR1ZSB0byBibG9ja2luZyovDQorICAgIC8qIFRoaXMgdW5ibG9ja2luZyBzY2hl
bWUgdHJpZXMgdG8gc3VwcG9ydCB0aGUgZG9tYWluLCBieSBhc3NpZ25pbmcgaXQNCisgICAgICog
YSBwcmlvcml0eSBpbiBleHRyYXRpbWUgZGlzdHJpYnV0aW9uIGFjY29yZGluZyB0byB0aGUgbG9z
cyBvZiB0aW1lDQorICAgICAqIGluIHRoaXMgc2xpY2UgZHVlIHRvIGJsb2NraW5nDQorICAgICAq
Lw0KICAgICBzX3RpbWVfdCBwZW47DQogIA0KLSAgICAvKm5vIG1vcmUgcmVhbHRpbWUgZXhlY3V0
aW9uIGluIHRoaXMgcGVyaW9kISovDQorICAgIC8qIE5vIG1vcmUgcmVhbHRpbWUgZXhlY3V0aW9u
IGluIHRoaXMgcGVyaW9kISAqLw0KICAgICBpbmYtPmRlYWRsX2FicyArPSBpbmYtPnBlcmlvZDsN
CiAgICAgaWYgKCBsaWtlbHkoaW5mLT5ibG9ja19hYnMpICkNCiAgICAgew0KLSAgICAgICAgLy90
cmVhdCBibG9ja2VkIHRpbWUgYXMgY29uc3VtZWQgYnkgdGhlIGRvbWFpbiovDQorICAgICAgICAv
KiBUcmVhdCBibG9ja2VkIHRpbWUgYXMgY29uc3VtZWQgYnkgdGhlIGRvbWFpbiAqLw0KICAgICAg
ICAgLyppbmYtPmNwdXRpbWUgKz0gbm93IC0gaW5mLT5ibG9ja19hYnM7Ki8NCi0gICAgICAgIC8q
cGVuYWx0eSBpcyB0aW1lIHRoZSBkb21haW4gd291bGQgaGF2ZQ0KLSAgICAgICAgICBoYWQgaWYg
aXQgY29udGludWVkIHRvIHJ1biAqLw0KKyAgICAgICAgLyogUGVuYWx0eSBpcyB0aW1lIHRoZSBk
b21haW4gd291bGQgaGF2ZQ0KKyAgICAgICAgICogaGFkIGlmIGl0IGNvbnRpbnVlZCB0byBydW4u
DQorICAgICAgICAgKi8NCiAgICAgICAgIHBlbiA9IChpbmYtPnNsaWNlIC0gaW5mLT5jcHV0aW1l
KTsNCiAgICAgICAgIGlmICggcGVuIDwgMCApDQogICAgICAgICAgICAgcGVuID0gMDsNCi0gICAg
ICAgIC8qYWNjdW11bGF0ZSBhbGwgcGVuYWx0aWVzIG92ZXIgdGhlIHBlcmlvZHMqLw0KKyAgICAg
ICAgLyogQWNjdW11bGF0ZSBhbGwgcGVuYWx0aWVzIG92ZXIgdGhlIHBlcmlvZHMgKi8NCiAgICAg
ICAgIC8qaW5mLT5zaG9ydF9ibG9ja19sb3N0X3RvdCArPSBwZW47Ki8NCi0gICAgICAgIC8qc2V0
IHBlbmFsdHkgdG8gdGhlIGN1cnJlbnQgdmFsdWUqLw0KKyAgICAgICAgLyogU2V0IHBlbmFsdHkg
dG8gdGhlIGN1cnJlbnQgdmFsdWUgKi8NCiAgICAgICAgIGluZi0+c2hvcnRfYmxvY2tfbG9zdF90
b3QgPSBwZW47DQotICAgICAgICAvKm5vdCBzdXJlIHdoaWNoIG9uZSBpcyBiZXR0ZXIuLiBidXQg
c2VlbXMgdG8gd29yayB3ZWxsLi4uKi8NCisgICAgICAgIC8qIE5vdCBzdXJlIHdoaWNoIG9uZSBp
cyBiZXR0ZXIuLiBidXQgc2VlbXMgdG8gd29yayB3ZWxsLi4uICovDQogICANCiAgICAgICAgIGlm
ICggaW5mLT5zaG9ydF9ibG9ja19sb3N0X3RvdCApDQogICAgICAgICB7DQpAQCAtMTAwMiwyOCAr
OTQ3LDMwIEBAIHN0YXRpYyB2b2lkIHVuYmxvY2tfc2hvcnRfZXh0cmFfc3VwcG9ydCgNCiAgICAg
ICAgICAgICBpbmYtPnBlbl9leHRyYV9ibG9ja3MrKzsNCiAjZW5kaWYNCiAgICAgICAgICAgICBp
ZiAoIGV4dHJhcV9vbihpbmYtPnZjcHUsIEVYVFJBX1BFTl9RKSApDQotICAgICAgICAgICAgICAg
IC8qcmVtb3ZlIGRvbWFpbiBmb3IgcG9zc2libGUgcmVzb3J0aW5nISovDQorICAgICAgICAgICAg
ICAgIC8qIFJlbW92ZSBkb21haW4gZm9yIHBvc3NpYmxlIHJlc29ydGluZyEgKi8NCiAgICAgICAg
ICAgICAgICAgZXh0cmFxX2RlbChpbmYtPnZjcHUsIEVYVFJBX1BFTl9RKTsNCiAgICAgICAgICAg
ICBlbHNlDQotICAgICAgICAgICAgICAgIC8qcmVtZW1iZXIgdGhhdCB3ZSB3YW50IHRvIGJlIG9u
IHRoZSBwZW5hbHR5IHENCi0gICAgICAgICAgICAgICAgICBzbyB0aGF0IHdlIGNhbiBjb250aW51
ZSB3aGVuIHdlICh1bi0pYmxvY2sNCi0gICAgICAgICAgICAgICAgICBpbiBwZW5hbHR5LWV4dHJh
dGltZSovDQorICAgICAgICAgICAgICAgIC8qIFJlbWVtYmVyIHRoYXQgd2Ugd2FudCB0byBiZSBv
biB0aGUgcGVuYWx0eSBxDQorICAgICAgICAgICAgICAgICAqIHNvIHRoYXQgd2UgY2FuIGNvbnRp
bnVlIHdoZW4gd2UgKHVuLSlibG9jaw0KKyAgICAgICAgICAgICAgICAgKiBpbiBwZW5hbHR5LWV4
dHJhdGltZQ0KKyAgICAgICAgICAgICAgICAgKi8NCiAgICAgICAgICAgICAgICAgaW5mLT5zdGF0
dXMgfD0gRVhUUkFfV0FOVF9QRU5fUTsNCiAgICANCi0gICAgICAgICAgICAvKihyZS0pYWRkIGRv
bWFpbiB0byB0aGUgcGVuYWx0eSBleHRyYXEqLw0KKyAgICAgICAgICAgIC8qIChyZS0pYWRkIGRv
bWFpbiB0byB0aGUgcGVuYWx0eSBleHRyYXEgKi8NCiAgICAgICAgICAgICBleHRyYXFfYWRkX3Nv
cnRfdXBkYXRlKGluZi0+dmNwdSwgRVhUUkFfUEVOX1EsIDApOw0KICAgICAgICAgfQ0KICAgICB9
DQogDQotICAgIC8qZ2l2ZSBpdCBhIGZyZXNoIHNsaWNlIGluIHRoZSBuZXh0IHBlcmlvZCEqLw0K
KyAgICAvKiBHaXZlIGl0IGEgZnJlc2ggc2xpY2UgaW4gdGhlIG5leHQgcGVyaW9kISAqLw0KICAg
ICBpbmYtPmNwdXRpbWUgPSAwOw0KIH0NCiANCiANCiBzdGF0aWMgdm9pZCB1bmJsb2NrX2xvbmdf
Y29uc19iKHN0cnVjdCBzZWRmX3ZjcHVfaW5mbyogaW5mLHNfdGltZV90IG5vdykNCiB7DQotICAg
IC8qQ29uc2VydmF0aXZlIDJiKi8NCi0gICAgLypUcmVhdCB0aGUgdW5ibG9ja2luZyB0aW1lIGFz
IGEgc3RhcnQgb2YgYSBuZXcgcGVyaW9kICovDQorICAgIC8qIENvbnNlcnZhdGl2ZSAyYiAqLw0K
Kw0KKyAgICAvKiBUcmVhdCB0aGUgdW5ibG9ja2luZyB0aW1lIGFzIGEgc3RhcnQgb2YgYSBuZXcg
cGVyaW9kICovDQogICAgIGluZi0+ZGVhZGxfYWJzID0gbm93ICsgaW5mLT5wZXJpb2Q7DQogICAg
IGluZi0+Y3B1dGltZSA9IDA7DQogfQ0KQEAgLTEwNDYsMTUgKzk5MywxNiBAQCBzdGF0aWMgaW5s
aW5lIGludCBnZXRfcnVuX3R5cGUoc3RydWN0IHZjDQogfQ0KIA0KIA0KLS8qQ29tcGFyZXMgdHdv
IGRvbWFpbnMgaW4gdGhlIHJlbGF0aW9uIG9mIHdoZXRoZXIgdGhlIG9uZSBpcyBhbGxvd2VkIHRv
DQotICBpbnRlcnJ1cHQgdGhlIG90aGVycyBleGVjdXRpb24uDQotICBJdCByZXR1cm5zIHRydWUg
KCE9MCkgaWYgYSBzd2l0Y2ggdG8gdGhlIG90aGVyIGRvbWFpbiBpcyBnb29kLg0KLSAgQ3VycmVu
dCBQcmlvcml0eSBzY2hlbWUgaXMgYXMgZm9sbG93czoNCi0gICBFREYgPiBMMCAocGVuYWx0eSBi
YXNlZCkgZXh0cmEtdGltZSA+IA0KLSAgIEwxICh1dGlsaXphdGlvbikgZXh0cmEtdGltZSA+IGlk
bGUtZG9tYWluDQotICBJbiB0aGUgc2FtZSBjbGFzcyBwcmlvcml0aWVzIGFyZSBhc3NpZ25lZCBh
cyBmb2xsb3dpbmc6DQotICAgRURGOiBlYXJseSBkZWFkbGluZSA+IGxhdGUgZGVhZGxpbmUNCi0g
ICBMMCBleHRyYS10aW1lOiBsb3dlciBzY29yZSA+IGhpZ2hlciBzY29yZSovDQorLyogQ29tcGFy
ZXMgdHdvIGRvbWFpbnMgaW4gdGhlIHJlbGF0aW9uIG9mIHdoZXRoZXIgdGhlIG9uZSBpcyBhbGxv
d2VkIHRvDQorICogaW50ZXJydXB0IHRoZSBvdGhlcnMgZXhlY3V0aW9uLg0KKyAqIEl0IHJldHVy
bnMgdHJ1ZSAoIT0wKSBpZiBhIHN3aXRjaCB0byB0aGUgb3RoZXIgZG9tYWluIGlzIGdvb2QuDQor
ICogQ3VycmVudCBQcmlvcml0eSBzY2hlbWUgaXMgYXMgZm9sbG93czoNCisgKiAgRURGID4gTDAg
KHBlbmFsdHkgYmFzZWQpIGV4dHJhLXRpbWUgPiANCisgKiAgTDEgKHV0aWxpemF0aW9uKSBleHRy
YS10aW1lID4gaWRsZS1kb21haW4NCisgKiBJbiB0aGUgc2FtZSBjbGFzcyBwcmlvcml0aWVzIGFy
ZSBhc3NpZ25lZCBhcyBmb2xsb3dpbmc6DQorICogIEVERjogZWFybHkgZGVhZGxpbmUgPiBsYXRl
IGRlYWRsaW5lDQorICogIEwwIGV4dHJhLXRpbWU6IGxvd2VyIHNjb3JlID4gaGlnaGVyIHNjb3Jl
DQorICovDQogc3RhdGljIGlubGluZSBpbnQgc2hvdWxkX3N3aXRjaChzdHJ1Y3QgdmNwdSAqY3Vy
LA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgc3RydWN0IHZjcHUgKm90aGVyLA0K
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgc190aW1lX3Qgbm93KQ0KQEAgLTEwNjMs
MTkgKzEwMTEsMTkgQEAgc3RhdGljIGlubGluZSBpbnQgc2hvdWxkX3N3aXRjaChzdHJ1Y3Qgdg0K
ICAgICBjdXJfaW5mICAgPSBFRE9NX0lORk8oY3VyKTsNCiAgICAgb3RoZXJfaW5mID0gRURPTV9J
TkZPKG90aGVyKTsNCiAgDQotICAgIC8qIENoZWNrIHdoZXRoZXIgd2UgbmVlZCB0byBtYWtlIGFu
IGVhcmxpZXIgc2NoZWR1bGluZyBkZWNpc2lvbi4gKi8NCisgICAgLyogQ2hlY2sgd2hldGhlciB3
ZSBuZWVkIHRvIG1ha2UgYW4gZWFybGllciBzY2hlZHVsaW5nIGRlY2lzaW9uICovDQogICAgIGlm
ICggUEVSSU9EX0JFR0lOKG90aGVyX2luZikgPCANCiAgICAgICAgICBDUFVfSU5GTyhvdGhlci0+
cHJvY2Vzc29yKS0+Y3VycmVudF9zbGljZV9leHBpcmVzICkNCiAgICAgICAgIHJldHVybiAxOw0K
IA0KLSAgICAvKiBObyB0aW1pbmctYmFzZWQgc3dpdGNoZXMgbmVlZCB0byBiZSB0YWtlbiBpbnRv
IGFjY291bnQgaGVyZS4gKi8NCisgICAgLyogTm8gdGltaW5nLWJhc2VkIHN3aXRjaGVzIG5lZWQg
dG8gYmUgdGFrZW4gaW50byBhY2NvdW50IGhlcmUgKi8NCiAgICAgc3dpdGNoICggZ2V0X3J1bl90
eXBlKGN1cikgKQ0KICAgICB7DQogICAgIGNhc2UgRE9NQUlOX0VERjoNCi0gICAgICAgIC8qIERv
IG5vdCBpbnRlcnJ1cHQgYSBydW5uaW5nIEVERiBkb21haW4uICovDQorICAgICAgICAvKiBEbyBu
b3QgaW50ZXJydXB0IGEgcnVubmluZyBFREYgZG9tYWluICovDQogICAgICAgICByZXR1cm4gMDsN
CiAgICAgY2FzZSBET01BSU5fRVhUUkFfUEVOOg0KLSAgICAgICAgLyogQ2hlY2sgd2hldGhlciB3
ZSBhbHNvIHdhbnQgdGhlIEwwIGV4LXEgd2l0aCBsb3dlciBzY29yZS4gKi8NCisgICAgICAgIC8q
IENoZWNrIHdoZXRoZXIgd2UgYWxzbyB3YW50IHRoZSBMMCBleC1xIHdpdGggbG93ZXIgc2NvcmUg
Ki8NCiAgICAgICAgIHJldHVybiAoKG90aGVyX2luZi0+c3RhdHVzICYgRVhUUkFfV0FOVF9QRU5f
USkgJiYNCiAgICAgICAgICAgICAgICAgKG90aGVyX2luZi0+c2NvcmVbRVhUUkFfUEVOX1FdIDwg
DQogICAgICAgICAgICAgICAgICBjdXJfaW5mLT5zY29yZVtFWFRSQV9QRU5fUV0pKTsNCkBAIC0x
MDk2LDE4ICsxMDQ0LDExIEBAIHN0YXRpYyB2b2lkIHNlZGZfd2FrZShjb25zdCBzdHJ1Y3Qgc2No
ZWQNCiAgICAgc190aW1lX3QgICAgICAgICAgICAgIG5vdyA9IE5PVygpOw0KICAgICBzdHJ1Y3Qg
c2VkZl92Y3B1X2luZm8qIGluZiA9IEVET01fSU5GTyhkKTsNCiANCi0gICAgUFJJTlQoMywgInNl
ZGZfd2FrZSB3YXMgY2FsbGVkLCBkb21haW4taWQgJWkuJWlcbiIsZC0+ZG9tYWluLT5kb21haW5f
aWQsDQotICAgICAgICAgIGQtPnZjcHVfaWQpOw0KLQ0KICAgICBpZiAoIHVubGlrZWx5KGlzX2lk
bGVfdmNwdShkKSkgKQ0KICAgICAgICAgcmV0dXJuOw0KICAgIA0KICAgICBpZiAoIHVubGlrZWx5
KF9fdGFza19vbl9xdWV1ZShkKSkgKQ0KLSAgICB7DQotICAgICAgICBQUklOVCgzLCJcdGRvbWFp
biAlaS4laSBpcyBhbHJlYWR5IGluIHNvbWUgcXVldWVcbiIsDQotICAgICAgICAgICAgICBkLT5k
b21haW4tPmRvbWFpbl9pZCwgZC0+dmNwdV9pZCk7DQogICAgICAgICByZXR1cm47DQotICAgIH0N
CiANCiAgICAgQVNTRVJUKCFzZWRmX3J1bm5hYmxlKGQpKTsNCiAgICAgaW5mLT5zdGF0dXMgJj0g
flNFREZfQVNMRUVQOw0KQEAgLTExMTYsMjggKzEwNTcsMjQgQEAgc3RhdGljIHZvaWQgc2VkZl93
YWtlKGNvbnN0IHN0cnVjdCBzY2hlZA0KICANCiAgICAgaWYgKCB1bmxpa2VseShpbmYtPmRlYWRs
X2FicyA9PSAwKSApDQogICAgIHsNCi0gICAgICAgIC8qaW5pdGlhbCBzZXR1cCBvZiB0aGUgZGVh
ZGxpbmUqLw0KKyAgICAgICAgLyogSW5pdGlhbCBzZXR1cCBvZiB0aGUgZGVhZGxpbmUgKi8NCiAg
ICAgICAgIGluZi0+ZGVhZGxfYWJzID0gbm93ICsgaW5mLT5zbGljZTsNCiAgICAgfQ0KICAgDQot
ICAgIFBSSU5UKDMsICJ3YWtpbmcgdXAgZG9tYWluICVpLiVpIChkZWFkbD0gJSJQUkl1NjQiIHBl
cmlvZD0gJSJQUkl1NjQNCi0gICAgICAgICAgIm5vdz0gJSJQUkl1NjQiKVxuIiwNCi0gICAgICAg
ICAgZC0+ZG9tYWluLT5kb21haW5faWQsIGQtPnZjcHVfaWQsIGluZi0+ZGVhZGxfYWJzLCBpbmYt
PnBlcmlvZCwgbm93KTsNCi0NCiAjaWZkZWYgU0VERl9TVEFUUyANCiAgICAgaW5mLT5ibG9ja190
b3QrKzsNCiAjZW5kaWYNCiANCiAgICAgaWYgKCB1bmxpa2VseShub3cgPCBQRVJJT0RfQkVHSU4o
aW5mKSkgKQ0KICAgICB7DQotICAgICAgICBQUklOVCg0LCJleHRyYXRpbWUgdW5ibG9ja1xuIik7
DQotICAgICAgICAvKiB1bmJsb2NraW5nIGluIGV4dHJhLXRpbWUhICovDQorICAgICAgICAvKiBV
bmJsb2NraW5nIGluIGV4dHJhLXRpbWUhICovDQogICAgICAgICBpZiAoIGluZi0+c3RhdHVzICYg
RVhUUkFfV0FOVF9QRU5fUSApDQogICAgICAgICB7DQotICAgICAgICAgICAgLyp3ZSBoYXZlIGEg
ZG9tYWluIHRoYXQgd2FudHMgY29tcGVuc2F0aW9uDQotICAgICAgICAgICAgICBmb3IgYmxvY2sg
cGVuYWx0eSBhbmQgZGlkIGp1c3QgYmxvY2sgaW4NCi0gICAgICAgICAgICAgIGl0cyBjb21wZW5z
YXRpb24gdGltZS4gR2l2ZSBpdCBhbm90aGVyDQotICAgICAgICAgICAgICBjaGFuY2UhKi8NCisg
ICAgICAgICAgICAvKiBXZSBoYXZlIGEgZG9tYWluIHRoYXQgd2FudHMgY29tcGVuc2F0aW9uDQor
ICAgICAgICAgICAgICogZm9yIGJsb2NrIHBlbmFsdHkgYW5kIGRpZCBqdXN0IGJsb2NrIGluDQor
ICAgICAgICAgICAgICogaXRzIGNvbXBlbnNhdGlvbiB0aW1lLiBHaXZlIGl0IGFub3RoZXINCisg
ICAgICAgICAgICAgKiBjaGFuY2UhDQorICAgICAgICAgICAgICovDQogICAgICAgICAgICAgZXh0
cmFxX2FkZF9zb3J0X3VwZGF0ZShkLCBFWFRSQV9QRU5fUSwgMCk7DQogICAgICAgICB9DQogICAg
ICAgICBleHRyYXFfY2hlY2tfYWRkX3VuYmxvY2tlZChkLCAwKTsNCkBAIC0xMTQ2LDggKzEwODMs
NyBAQCBzdGF0aWMgdm9pZCBzZWRmX3dha2UoY29uc3Qgc3RydWN0IHNjaGVkDQogICAgIHsgIA0K
ICAgICAgICAgaWYgKCBub3cgPCBpbmYtPmRlYWRsX2FicyApDQogICAgICAgICB7DQotICAgICAg
ICAgICAgUFJJTlQoNCwic2hvcnQgdW5ibG9ja2luZ1xuIik7DQotICAgICAgICAgICAgLypzaG9y
dCBibG9ja2luZyovDQorICAgICAgICAgICAgLyogU2hvcnQgYmxvY2tpbmcgKi8NCiAjaWZkZWYg
U0VERl9TVEFUUw0KICAgICAgICAgICAgIGluZi0+c2hvcnRfYmxvY2tfdG90Kys7DQogI2VuZGlm
DQpAQCAtMTE1Nyw4ICsxMDkzLDcgQEAgc3RhdGljIHZvaWQgc2VkZl93YWtlKGNvbnN0IHN0cnVj
dCBzY2hlZA0KICAgICAgICAgfQ0KICAgICAgICAgZWxzZQ0KICAgICAgICAgew0KLSAgICAgICAg
ICAgIFBSSU5UKDQsImxvbmcgdW5ibG9ja2luZ1xuIik7DQotICAgICAgICAgICAgLypsb25nIHVu
YmxvY2tpbmcqLw0KKyAgICAgICAgICAgIC8qIExvbmcgdW5ibG9ja2luZyAqLw0KICNpZmRlZiBT
RURGX1NUQVRTDQogICAgICAgICAgICAgaW5mLT5sb25nX2Jsb2NrX3RvdCsrOw0KICNlbmRpZg0K
QEAgLTExNjgsMjQgKzExMDMsMTMgQEAgc3RhdGljIHZvaWQgc2VkZl93YWtlKGNvbnN0IHN0cnVj
dCBzY2hlZA0KICAgICAgICAgfQ0KICAgICB9DQogDQotICAgIFBSSU5UKDMsICJ3b2tlIHVwIGRv
bWFpbiAlaS4laSAoZGVhZGw9ICUiUFJJdTY0IiBwZXJpb2Q9ICUiUFJJdTY0DQotICAgICAgICAg
ICJub3c9ICUiUFJJdTY0IilcbiIsDQotICAgICAgICAgIGQtPmRvbWFpbi0+ZG9tYWluX2lkLCBk
LT52Y3B1X2lkLCBpbmYtPmRlYWRsX2FicywNCi0gICAgICAgICAgaW5mLT5wZXJpb2QsIG5vdyk7
DQotDQogICAgIGlmICggUEVSSU9EX0JFR0lOKGluZikgPiBub3cgKQ0KLSAgICB7DQogICAgICAg
ICBfX2FkZF90b193YWl0cXVldWVfc29ydChkKTsNCi0gICAgICAgIFBSSU5UKDMsImFkZGVkIHRv
IHdhaXRxXG4iKTsNCi0gICAgfQ0KICAgICBlbHNlDQotICAgIHsNCiAgICAgICAgIF9fYWRkX3Rv
X3J1bnF1ZXVlX3NvcnQoZCk7DQotICAgICAgICBQUklOVCgzLCJhZGRlZCB0byBydW5xXG4iKTsN
Ci0gICAgfQ0KICANCiAjaWZkZWYgU0VERl9TVEFUUw0KLSAgICAvKmRvIHNvbWUgc3RhdGlzdGlj
cyBoZXJlLi4uKi8NCisgICAgLyogRG8gc29tZSBzdGF0aXN0aWNzIGhlcmUuLi4gKi8NCiAgICAg
aWYgKCBpbmYtPmJsb2NrX2FicyAhPSAwICkNCiAgICAgew0KICAgICAgICAgaW5mLT5ibG9ja190
aW1lX3RvdCArPSBub3cgLSBpbmYtPmJsb2NrX2FiczsNCkBAIC0xMTk0LDEyICsxMTE4LDEzIEBA
IHN0YXRpYyB2b2lkIHNlZGZfd2FrZShjb25zdCBzdHJ1Y3Qgc2NoZWQNCiAgICAgfQ0KICNlbmRp
Zg0KIA0KLSAgICAvKnNhbml0eSBjaGVjazogbWFrZSBzdXJlIGVhY2ggZXh0cmEtYXdhcmUgZG9t
YWluIElTIG9uIHRoZSB1dGlsLXEhKi8NCisgICAgLyogU2FuaXR5IGNoZWNrOiBtYWtlIHN1cmUg
ZWFjaCBleHRyYS1hd2FyZSBkb21haW4gSVMgb24gdGhlIHV0aWwtcSEgKi8NCiAgICAgQVNTRVJU
KElNUExZKGluZi0+c3RhdHVzICYgRVhUUkFfQVdBUkUsIGV4dHJhcV9vbihkLCBFWFRSQV9VVElM
X1EpKSk7DQogICAgIEFTU0VSVChfX3Rhc2tfb25fcXVldWUoZCkpOw0KLSAgICAvKmNoZWNrIHdo
ZXRoZXIgdGhlIGF3YWtlbmVkIHRhc2sgbmVlZHMgdG8gaW52b2tlIHRoZSBkb19zY2hlZHVsZQ0K
LSAgICAgIHJvdXRpbmUuIFRyeSB0byBhdm9pZCB1bm5lY2Vzc2FyeSBydW5zIGJ1dDoNCi0gICAg
ICBTYXZlIGFwcHJveGltYXRpb246IEFsd2F5cyBzd2l0Y2ggdG8gc2NoZWR1bGVyISovDQorICAg
IC8qIENoZWNrIHdoZXRoZXIgdGhlIGF3YWtlbmVkIHRhc2sgbmVlZHMgdG8gaW52b2tlIHRoZSBk
b19zY2hlZHVsZQ0KKyAgICAgKiByb3V0aW5lLiBUcnkgdG8gYXZvaWQgdW5uZWNlc3NhcnkgcnVu
cyBidXQ6DQorICAgICAqIFNhdmUgYXBwcm94aW1hdGlvbjogQWx3YXlzIHN3aXRjaCB0byBzY2hl
ZHVsZXIhDQorICAgICAqLw0KICAgICBBU1NFUlQoZC0+cHJvY2Vzc29yID49IDApOw0KICAgICBB
U1NFUlQoZC0+cHJvY2Vzc29yIDwgbnJfY3B1X2lkcyk7DQogICAgIEFTU0VSVChwZXJfY3B1KHNj
aGVkdWxlX2RhdGEsIGQtPnByb2Nlc3NvcikuY3Vycik7DQpAQCAtMTI0NCw3ICsxMTY5LDcgQEAg
c3RhdGljIHZvaWQgc2VkZl9kdW1wX2RvbWFpbihzdHJ1Y3QgdmNwdQ0KIH0NCiANCiANCi0vKiBk
dW1wcyBhbGwgZG9tYWlucyBvbiB0aGUgc3BlY2lmaWVkIGNwdSAqLw0KKy8qIER1bXBzIGFsbCBk
b21haW5zIG9uIHRoZSBzcGVjaWZpZWQgY3B1ICovDQogc3RhdGljIHZvaWQgc2VkZl9kdW1wX2Nw
dV9zdGF0ZShjb25zdCBzdHJ1Y3Qgc2NoZWR1bGVyICpvcHMsIGludCBpKQ0KIHsNCiAgICAgc3Ry
dWN0IGxpc3RfaGVhZCAgICAgICpsaXN0LCAqcXVldWUsICp0bXA7DQpAQCAtMTMxOSw3ICsxMjQ0
LDcgQEAgc3RhdGljIHZvaWQgc2VkZl9kdW1wX2NwdV9zdGF0ZShjb25zdCBzdA0KIH0NCiANCiAN
Ci0vKiBBZGp1c3RzIHBlcmlvZHMgYW5kIHNsaWNlcyBvZiB0aGUgZG9tYWlucyBhY2NvcmRpbmds
eSB0byB0aGVpciB3ZWlnaHRzLiAqLw0KKy8qIEFkanVzdHMgcGVyaW9kcyBhbmQgc2xpY2VzIG9m
IHRoZSBkb21haW5zIGFjY29yZGluZ2x5IHRvIHRoZWlyIHdlaWdodHMgKi8NCiBzdGF0aWMgaW50
IHNlZGZfYWRqdXN0X3dlaWdodHMoc3RydWN0IGNwdXBvb2wgKmMsIHN0cnVjdCB4ZW5fZG9tY3Rs
X3NjaGVkdWxlcl9vcCAqY21kKQ0KIHsNCiAgICAgc3RydWN0IHZjcHUgKnA7DQpAQCAtMTMzNSw3
ICsxMjYwLDcgQEAgc3RhdGljIGludCBzZWRmX2FkanVzdF93ZWlnaHRzKHN0cnVjdCBjcA0KICAg
ICAgICAgcmV0dXJuIC1FTk9NRU07DQogICAgIH0NCiANCi0gICAgLyogU3VtIGFjcm9zcyBhbGwg
d2VpZ2h0cy4gKi8NCisgICAgLyogU3VtIGFjcm9zcyBhbGwgd2VpZ2h0cyAqLw0KICAgICByY3Vf
cmVhZF9sb2NrKCZkb21saXN0X3JlYWRfbG9jayk7DQogICAgIGZvcl9lYWNoX2RvbWFpbl9pbl9j
cHVwb29sKCBkLCBjICkNCiAgICAgew0KQEAgLTEzNTAsMTEgKzEyNzUsMTMgQEAgc3RhdGljIGlu
dCBzZWRmX2FkanVzdF93ZWlnaHRzKHN0cnVjdCBjcA0KICAgICAgICAgICAgIH0NCiAgICAgICAg
ICAgICBlbHNlDQogICAgICAgICAgICAgew0KLSAgICAgICAgICAgICAgICAvKmRvbid0IG1vZGlm
eSBkb21haW5zIHdobyBkb24ndCBoYXZlIGEgd2VpZ2h0LCBidXQgc3VtDQotICAgICAgICAgICAg
ICAgICAgdXAgdGhlIHRpbWUgdGhleSBuZWVkLCBwcm9qZWN0ZWQgdG8gYSBXRUlHSFRfUEVSSU9E
LA0KLSAgICAgICAgICAgICAgICAgIHNvIHRoYXQgdGhpcyB0aW1lIGlzIG5vdCBnaXZlbiB0byB0
aGUgd2VpZ2h0LWRyaXZlbg0KLSAgICAgICAgICAgICAgICAgIGRvbWFpbnMqLw0KLSAgICAgICAg
ICAgICAgICAvKmNoZWNrIGZvciBvdmVyZmxvd3MqLw0KKyAgICAgICAgICAgICAgICAvKiBEb24n
dCBtb2RpZnkgZG9tYWlucyB3aG8gZG9uJ3QgaGF2ZSBhIHdlaWdodCwgYnV0IHN1bQ0KKyAgICAg
ICAgICAgICAgICAgKiB1cCB0aGUgdGltZSB0aGV5IG5lZWQsIHByb2plY3RlZCB0byBhIFdFSUdI
VF9QRVJJT0QsDQorICAgICAgICAgICAgICAgICAqIHNvIHRoYXQgdGhpcyB0aW1lIGlzIG5vdCBn
aXZlbiB0byB0aGUgd2VpZ2h0LWRyaXZlbg0KKyAgICAgICAgICAgICAgICAgKiAgZG9tYWlucw0K
KyAgICAgICAgICAgICAgICAgKi8NCisNCisgICAgICAgICAgICAgICAgLyogQ2hlY2sgZm9yIG92
ZXJmbG93cyAqLw0KICAgICAgICAgICAgICAgICBBU1NFUlQoKFdFSUdIVF9QRVJJT0QgPCBVTE9O
R19NQVgpIA0KICAgICAgICAgICAgICAgICAgICAgICAgJiYgKEVET01fSU5GTyhwKS0+c2xpY2Vf
b3JpZyA8IFVMT05HX01BWCkpOw0KICAgICAgICAgICAgICAgICBzdW10W2NwdV0gKz0gDQpAQCAt
MTM2NSw3ICsxMjkyLDcgQEAgc3RhdGljIGludCBzZWRmX2FkanVzdF93ZWlnaHRzKHN0cnVjdCBj
cA0KICAgICB9DQogICAgIHJjdV9yZWFkX3VubG9jaygmZG9tbGlzdF9yZWFkX2xvY2spOw0KIA0K
LSAgICAvKiBBZGp1c3QgYWxsIHNsaWNlcyAoYW5kIHBlcmlvZHMpIHRvIHRoZSBuZXcgd2VpZ2h0
LiAqLw0KKyAgICAvKiBBZGp1c3QgYWxsIHNsaWNlcyAoYW5kIHBlcmlvZHMpIHRvIHRoZSBuZXcg
d2VpZ2h0ICovDQogICAgIHJjdV9yZWFkX2xvY2soJmRvbWxpc3RfcmVhZF9sb2NrKTsNCiAgICAg
Zm9yX2VhY2hfZG9tYWluX2luX2NwdXBvb2woIGQsIGMgKQ0KICAgICB7DQpAQCAtMTM5MywyMCAr
MTMyMCwxNSBAQCBzdGF0aWMgaW50IHNlZGZfYWRqdXN0X3dlaWdodHMoc3RydWN0IGNwDQogfQ0K
IA0KIA0KLS8qIHNldCBvciBmZXRjaCBkb21haW4gc2NoZWR1bGluZyBwYXJhbWV0ZXJzICovDQor
LyogU2V0IG9yIGZldGNoIGRvbWFpbiBzY2hlZHVsaW5nIHBhcmFtZXRlcnMgKi8NCiBzdGF0aWMg
aW50IHNlZGZfYWRqdXN0KGNvbnN0IHN0cnVjdCBzY2hlZHVsZXIgKm9wcywgc3RydWN0IGRvbWFp
biAqcCwgc3RydWN0IHhlbl9kb21jdGxfc2NoZWR1bGVyX29wICpvcCkNCiB7DQogICAgIHN0cnVj
dCB2Y3B1ICp2Ow0KICAgICBpbnQgcmM7DQogDQotICAgIFBSSU5UKDIsInNlZGZfYWRqdXN0IHdh
cyBjYWxsZWQsIGRvbWFpbi1pZCAlaSBuZXcgcGVyaW9kICUiUFJJdTY0IiAiDQotICAgICAgICAg
ICJuZXcgc2xpY2UgJSJQUkl1NjQiXG5sYXRlbmN5ICUiUFJJdTY0IiBleHRyYTolc1xuIiwNCi0g
ICAgICAgICAgcC0+ZG9tYWluX2lkLCBvcC0+dS5zZWRmLnBlcmlvZCwgb3AtPnUuc2VkZi5zbGlj
ZSwNCi0gICAgICAgICAgb3AtPnUuc2VkZi5sYXRlbmN5LCAob3AtPnUuc2VkZi5leHRyYXRpbWUp
PyJ5ZXMiOiJubyIpOw0KLQ0KICAgICBpZiAoIG9wLT5jbWQgPT0gWEVOX0RPTUNUTF9TQ0hFRE9Q
X3B1dGluZm8gKQ0KICAgICB7DQotICAgICAgICAvKiBDaGVjayBmb3Igc2FuZSBwYXJhbWV0ZXJz
LiAqLw0KKyAgICAgICAgLyogQ2hlY2sgZm9yIHNhbmUgcGFyYW1ldGVycyAqLw0KICAgICAgICAg
aWYgKCAhb3AtPnUuc2VkZi5wZXJpb2QgJiYgIW9wLT51LnNlZGYud2VpZ2h0ICkNCiAgICAgICAg
ICAgICByZXR1cm4gLUVJTlZBTDsNCiAgICAgICAgIGlmICggb3AtPnUuc2VkZi53ZWlnaHQgKQ0K
QEAgLTE0MTQsNyArMTMzNiw3IEBAIHN0YXRpYyBpbnQgc2VkZl9hZGp1c3QoY29uc3Qgc3RydWN0
IHNjaGUNCiAgICAgICAgICAgICBpZiAoIChvcC0+dS5zZWRmLmV4dHJhdGltZSAmIEVYVFJBX0FX
QVJFKSAmJg0KICAgICAgICAgICAgICAgICAgKCFvcC0+dS5zZWRmLnBlcmlvZCkgKQ0KICAgICAg
ICAgICAgIHsNCi0gICAgICAgICAgICAgICAgLyogV2VpZ2h0LWRyaXZlbiBkb21haW5zIHdpdGgg
ZXh0cmF0aW1lIG9ubHkuICovDQorICAgICAgICAgICAgICAgIC8qIFdlaWdodC1kcml2ZW4gZG9t
YWlucyB3aXRoIGV4dHJhdGltZSBvbmx5ICovDQogICAgICAgICAgICAgICAgIGZvcl9lYWNoX3Zj
cHUgKCBwLCB2ICkNCiAgICAgICAgICAgICAgICAgew0KICAgICAgICAgICAgICAgICAgICAgRURP
TV9JTkZPKHYpLT5leHRyYXdlaWdodCA9IG9wLT51LnNlZGYud2VpZ2h0Ow0KQEAgLTE0MjUsNyAr
MTM0Nyw3IEBAIHN0YXRpYyBpbnQgc2VkZl9hZGp1c3QoY29uc3Qgc3RydWN0IHNjaGUNCiAgICAg
ICAgICAgICB9DQogICAgICAgICAgICAgZWxzZQ0KICAgICAgICAgICAgIHsNCi0gICAgICAgICAg
ICAgICAgLyogV2VpZ2h0LWRyaXZlbiBkb21haW5zIHdpdGggcmVhbC10aW1lIGV4ZWN1dGlvbi4g
Ki8NCisgICAgICAgICAgICAgICAgLyogV2VpZ2h0LWRyaXZlbiBkb21haW5zIHdpdGggcmVhbC10
aW1lIGV4ZWN1dGlvbiAqLw0KICAgICAgICAgICAgICAgICBmb3JfZWFjaF92Y3B1ICggcCwgdiAp
DQogICAgICAgICAgICAgICAgICAgICBFRE9NX0lORk8odiktPndlaWdodCA9IG9wLT51LnNlZGYu
d2VpZ2h0Ow0KICAgICAgICAgICAgIH0NCkBAIC0xNDM1LDggKzEzNTcsNyBAQCBzdGF0aWMgaW50
IHNlZGZfYWRqdXN0KGNvbnN0IHN0cnVjdCBzY2hlDQogICAgICAgICAgICAgLyogVGltZS1kcml2
ZW4gZG9tYWlucy4gKi8NCiAgICAgICAgICAgICBmb3JfZWFjaF92Y3B1ICggcCwgdiApDQogICAg
ICAgICAgICAgew0KLSAgICAgICAgICAgICAgICAvKg0KLSAgICAgICAgICAgICAgICAgKiBTYW5p
dHkgY2hlY2tpbmc6IG5vdGUgdGhhdCBkaXNhYmxpbmcgZXh0cmEgd2VpZ2h0IHJlcXVpcmVzDQor
ICAgICAgICAgICAgICAgIC8qIFNhbml0eSBjaGVja2luZzogbm90ZSB0aGF0IGRpc2FibGluZyBl
eHRyYSB3ZWlnaHQgcmVxdWlyZXMNCiAgICAgICAgICAgICAgICAgICogdGhhdCB3ZSBzZXQgYSBu
b24temVybyBzbGljZS4NCiAgICAgICAgICAgICAgICAgICovDQogICAgICAgICAgICAgICAgIGlm
ICggKG9wLT51LnNlZGYucGVyaW9kID4gUEVSSU9EX01BWCkgfHwNCkBAIC0xNDc3LDcgKzEzOTgs
NiBAQCBzdGF0aWMgaW50IHNlZGZfYWRqdXN0KGNvbnN0IHN0cnVjdCBzY2hlDQogICAgICAgICBv
cC0+dS5zZWRmLndlaWdodCAgICA9IEVET01fSU5GTyhwLT52Y3B1WzBdKS0+d2VpZ2h0Ow0KICAg
ICB9DQogDQotICAgIFBSSU5UKDIsInNlZGZfYWRqdXN0X2ZpbmlzaGVkXG4iKTsNCiAgICAgcmV0
dXJuIDA7DQogfQ0KIA0K


--=-SQC3wUYrGGqGq8T7E3BQ--

--=-ByODJfHW+wcj4VSHJBM9
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEABECAAYFAk7xk7cACgkQk4XaBE3IOsTscACfeUsCDNw37zRR1IfIwxPK5lKK
/10An06jJC22XSm/UKSek9Fh+w8ihcr8
=7Rxx
-----END PGP SIGNATURE-----

--=-ByODJfHW+wcj4VSHJBM9--



--===============7346677379948124988==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============7346677379948124988==--



From xen-devel-bounces@lists.xensource.com Wed Dec 21 08:10:51 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 08:10:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdHFk-0002kh-2y; Wed, 21 Dec 2011 08:10:20 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RdHFj-0002kL-8D
	for xen-devel@lists.xensource.com; Wed, 21 Dec 2011 08:10:19 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1324455012!1504752!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20379 invoked from network); 21 Dec 2011 08:10:12 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-4.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Dec 2011 08:10:12 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 21 Dec 2011 08:10:12 +0000
Message-Id: <4EF1A2AB02000078000694B1@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 21 Dec 2011 08:11:07 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartC8E77A8B.0__="
Subject: [Xen-devel] [PATCH] x86: move some function scope statics into
	.init.data
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__PartC8E77A8B.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -486,7 +486,7 @@ static void __init kexec_reserve_area(st
 {
     unsigned long kdump_start =3D kexec_crash_area.start;
     unsigned long kdump_size  =3D kexec_crash_area.size;
-    static int is_reserved =3D 0;
+    static bool_t __initdata is_reserved =3D 0;
=20
     kdump_size =3D (kdump_size + PAGE_SIZE - 1) & PAGE_MASK;
=20
@@ -1330,7 +1330,7 @@ void __init __start_xen(unsigned long mb
     cmdline =3D (char *)(mod[0].string ? __va(mod[0].string) : NULL);
     if ( (cmdline !=3D NULL) || (kextra !=3D NULL) )
     {
-        static char dom0_cmdline[MAX_GUEST_CMDLINE];
+        static char __initdata dom0_cmdline[MAX_GUEST_CMDLINE];
=20
         cmdline =3D cmdline_cook(cmdline, loader);
         safe_strcpy(dom0_cmdline, cmdline);
@@ -1430,7 +1430,7 @@ int __init xen_in_range(unsigned long mf
     enum { region_s3, region_text, region_bss, nr_regions };
     static struct {
         paddr_t s, e;
-    } xen_regions[nr_regions];
+    } xen_regions[nr_regions] __initdata;
=20
     /* initialize first time */
     if ( !xen_regions[0].s )




--=__PartC8E77A8B.0__=
Content-Type: text/plain; name="x86-setup-initsec.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-setup-initsec.patch"

x86: move some function scope statics into .init.data=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@@ -486,7 +486,7 @@ static void __init kexec_reser=
ve_area(st=0A {=0A     unsigned long kdump_start =3D kexec_crash_area.start=
;=0A     unsigned long kdump_size  =3D kexec_crash_area.size;=0A-    =
static int is_reserved =3D 0;=0A+    static bool_t __initdata is_reserved =
=3D 0;=0A =0A     kdump_size =3D (kdump_size + PAGE_SIZE - 1) & PAGE_MASK;=
=0A =0A@@ -1330,7 +1330,7 @@ void __init __start_xen(unsigned long mb=0A   =
  cmdline =3D (char *)(mod[0].string ? __va(mod[0].string) : NULL);=0A     =
if ( (cmdline !=3D NULL) || (kextra !=3D NULL) )=0A     {=0A-        =
static char dom0_cmdline[MAX_GUEST_CMDLINE];=0A+        static char =
__initdata dom0_cmdline[MAX_GUEST_CMDLINE];=0A =0A         cmdline =3D =
cmdline_cook(cmdline, loader);=0A         safe_strcpy(dom0_cmdline, =
cmdline);=0A@@ -1430,7 +1430,7 @@ int __init xen_in_range(unsigned long =
mf=0A     enum { region_s3, region_text, region_bss, nr_regions };=0A     =
static struct {=0A         paddr_t s, e;=0A-    } xen_regions[nr_regions];=
=0A+    } xen_regions[nr_regions] __initdata;=0A =0A     /* initialize =
first time */=0A     if ( !xen_regions[0].s )=0A
--=__PartC8E77A8B.0__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--=__PartC8E77A8B.0__=--


From xen-devel-bounces@lists.xensource.com Wed Dec 21 08:10:51 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 08:10:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdHFk-0002kh-2y; Wed, 21 Dec 2011 08:10:20 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RdHFj-0002kL-8D
	for xen-devel@lists.xensource.com; Wed, 21 Dec 2011 08:10:19 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1324455012!1504752!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20379 invoked from network); 21 Dec 2011 08:10:12 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-4.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Dec 2011 08:10:12 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 21 Dec 2011 08:10:12 +0000
Message-Id: <4EF1A2AB02000078000694B1@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 21 Dec 2011 08:11:07 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartC8E77A8B.0__="
Subject: [Xen-devel] [PATCH] x86: move some function scope statics into
	.init.data
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__PartC8E77A8B.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -486,7 +486,7 @@ static void __init kexec_reserve_area(st
 {
     unsigned long kdump_start =3D kexec_crash_area.start;
     unsigned long kdump_size  =3D kexec_crash_area.size;
-    static int is_reserved =3D 0;
+    static bool_t __initdata is_reserved =3D 0;
=20
     kdump_size =3D (kdump_size + PAGE_SIZE - 1) & PAGE_MASK;
=20
@@ -1330,7 +1330,7 @@ void __init __start_xen(unsigned long mb
     cmdline =3D (char *)(mod[0].string ? __va(mod[0].string) : NULL);
     if ( (cmdline !=3D NULL) || (kextra !=3D NULL) )
     {
-        static char dom0_cmdline[MAX_GUEST_CMDLINE];
+        static char __initdata dom0_cmdline[MAX_GUEST_CMDLINE];
=20
         cmdline =3D cmdline_cook(cmdline, loader);
         safe_strcpy(dom0_cmdline, cmdline);
@@ -1430,7 +1430,7 @@ int __init xen_in_range(unsigned long mf
     enum { region_s3, region_text, region_bss, nr_regions };
     static struct {
         paddr_t s, e;
-    } xen_regions[nr_regions];
+    } xen_regions[nr_regions] __initdata;
=20
     /* initialize first time */
     if ( !xen_regions[0].s )




--=__PartC8E77A8B.0__=
Content-Type: text/plain; name="x86-setup-initsec.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-setup-initsec.patch"

x86: move some function scope statics into .init.data=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@@ -486,7 +486,7 @@ static void __init kexec_reser=
ve_area(st=0A {=0A     unsigned long kdump_start =3D kexec_crash_area.start=
;=0A     unsigned long kdump_size  =3D kexec_crash_area.size;=0A-    =
static int is_reserved =3D 0;=0A+    static bool_t __initdata is_reserved =
=3D 0;=0A =0A     kdump_size =3D (kdump_size + PAGE_SIZE - 1) & PAGE_MASK;=
=0A =0A@@ -1330,7 +1330,7 @@ void __init __start_xen(unsigned long mb=0A   =
  cmdline =3D (char *)(mod[0].string ? __va(mod[0].string) : NULL);=0A     =
if ( (cmdline !=3D NULL) || (kextra !=3D NULL) )=0A     {=0A-        =
static char dom0_cmdline[MAX_GUEST_CMDLINE];=0A+        static char =
__initdata dom0_cmdline[MAX_GUEST_CMDLINE];=0A =0A         cmdline =3D =
cmdline_cook(cmdline, loader);=0A         safe_strcpy(dom0_cmdline, =
cmdline);=0A@@ -1430,7 +1430,7 @@ int __init xen_in_range(unsigned long =
mf=0A     enum { region_s3, region_text, region_bss, nr_regions };=0A     =
static struct {=0A         paddr_t s, e;=0A-    } xen_regions[nr_regions];=
=0A+    } xen_regions[nr_regions] __initdata;=0A =0A     /* initialize =
first time */=0A     if ( !xen_regions[0].s )=0A
--=__PartC8E77A8B.0__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--=__PartC8E77A8B.0__=--


From xen-devel-bounces@lists.xensource.com Wed Dec 21 08:14:04 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 08:14:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdHIy-0002vT-Rg; Wed, 21 Dec 2011 08:13:40 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RdHIx-0002vE-Eu
	for xen-devel@lists.xensource.com; Wed, 21 Dec 2011 08:13:39 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1324455212!7813004!1
X-Originating-IP: [209.85.216.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18338 invoked from network); 21 Dec 2011 08:13:33 -0000
Received: from mail-qy0-f171.google.com (HELO mail-qy0-f171.google.com)
	(209.85.216.171)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Dec 2011 08:13:33 -0000
Received: by qcsc20 with SMTP id c20so54835676qcs.30
	for <xen-devel@lists.xensource.com>;
	Wed, 21 Dec 2011 00:13:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=KbQO42IMGNrZt+KO2mPCMjRD5MH84gnajP8vLKaCGvs=;
	b=YbTUX0gEBXBXKBewU2Lanus9FCbamAYXb7jH1RJFkc1tGXH/NQ2cVbgsnFBQC/t6Mj
	IEDTg9fM2Mq/p6SHBD5fQui0yVTxYTh4ktpHDIz9EVeUa6ZdzWdFew3xundolS75q6Sd
	IQ8qYmVuTXL8wxU7MP2Y5w0i0Yj9c56c7z7tw=
Received: by 10.229.75.204 with SMTP id z12mr2090093qcj.148.1324455212180;
	Wed, 21 Dec 2011 00:13:32 -0800 (PST)
Received: from [192.168.1.70] (host81-152-17-11.range81-152.btcentralplus.com.
	[81.152.17.11])
	by mx.google.com with ESMTPS id ed2sm9040577qab.15.2011.12.21.00.13.28
	(version=SSLv3 cipher=OTHER); Wed, 21 Dec 2011 00:13:30 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Wed, 21 Dec 2011 08:13:23 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Message-ID: <CB1745A3.27AB8%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH] x86: move some function scope statics into
	.init.data
Thread-Index: Acy/uGgz/VeB6tMW7k2CelcqCLK6ZA==
In-Reply-To: <4EF1A2AB02000078000694B1@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH] x86: move some function scope statics into
 .init.data
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 21/12/2011 08:11, "Jan Beulich" <JBeulich@suse.com> wrote:

> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Keir Fraser <keir@xen.org>

> --- a/xen/arch/x86/setup.c
> +++ b/xen/arch/x86/setup.c
> @@ -486,7 +486,7 @@ static void __init kexec_reserve_area(st
>  {
>      unsigned long kdump_start = kexec_crash_area.start;
>      unsigned long kdump_size  = kexec_crash_area.size;
> -    static int is_reserved = 0;
> +    static bool_t __initdata is_reserved = 0;
>  
>      kdump_size = (kdump_size + PAGE_SIZE - 1) & PAGE_MASK;
>  
> @@ -1330,7 +1330,7 @@ void __init __start_xen(unsigned long mb
>      cmdline = (char *)(mod[0].string ? __va(mod[0].string) : NULL);
>      if ( (cmdline != NULL) || (kextra != NULL) )
>      {
> -        static char dom0_cmdline[MAX_GUEST_CMDLINE];
> +        static char __initdata dom0_cmdline[MAX_GUEST_CMDLINE];
>  
>          cmdline = cmdline_cook(cmdline, loader);
>          safe_strcpy(dom0_cmdline, cmdline);
> @@ -1430,7 +1430,7 @@ int __init xen_in_range(unsigned long mf
>      enum { region_s3, region_text, region_bss, nr_regions };
>      static struct {
>          paddr_t s, e;
> -    } xen_regions[nr_regions];
> +    } xen_regions[nr_regions] __initdata;
>  
>      /* initialize first time */
>      if ( !xen_regions[0].s )
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 21 08:14:04 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 08:14:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdHIy-0002vT-Rg; Wed, 21 Dec 2011 08:13:40 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RdHIx-0002vE-Eu
	for xen-devel@lists.xensource.com; Wed, 21 Dec 2011 08:13:39 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1324455212!7813004!1
X-Originating-IP: [209.85.216.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18338 invoked from network); 21 Dec 2011 08:13:33 -0000
Received: from mail-qy0-f171.google.com (HELO mail-qy0-f171.google.com)
	(209.85.216.171)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Dec 2011 08:13:33 -0000
Received: by qcsc20 with SMTP id c20so54835676qcs.30
	for <xen-devel@lists.xensource.com>;
	Wed, 21 Dec 2011 00:13:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=KbQO42IMGNrZt+KO2mPCMjRD5MH84gnajP8vLKaCGvs=;
	b=YbTUX0gEBXBXKBewU2Lanus9FCbamAYXb7jH1RJFkc1tGXH/NQ2cVbgsnFBQC/t6Mj
	IEDTg9fM2Mq/p6SHBD5fQui0yVTxYTh4ktpHDIz9EVeUa6ZdzWdFew3xundolS75q6Sd
	IQ8qYmVuTXL8wxU7MP2Y5w0i0Yj9c56c7z7tw=
Received: by 10.229.75.204 with SMTP id z12mr2090093qcj.148.1324455212180;
	Wed, 21 Dec 2011 00:13:32 -0800 (PST)
Received: from [192.168.1.70] (host81-152-17-11.range81-152.btcentralplus.com.
	[81.152.17.11])
	by mx.google.com with ESMTPS id ed2sm9040577qab.15.2011.12.21.00.13.28
	(version=SSLv3 cipher=OTHER); Wed, 21 Dec 2011 00:13:30 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Wed, 21 Dec 2011 08:13:23 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Message-ID: <CB1745A3.27AB8%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH] x86: move some function scope statics into
	.init.data
Thread-Index: Acy/uGgz/VeB6tMW7k2CelcqCLK6ZA==
In-Reply-To: <4EF1A2AB02000078000694B1@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH] x86: move some function scope statics into
 .init.data
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 21/12/2011 08:11, "Jan Beulich" <JBeulich@suse.com> wrote:

> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Keir Fraser <keir@xen.org>

> --- a/xen/arch/x86/setup.c
> +++ b/xen/arch/x86/setup.c
> @@ -486,7 +486,7 @@ static void __init kexec_reserve_area(st
>  {
>      unsigned long kdump_start = kexec_crash_area.start;
>      unsigned long kdump_size  = kexec_crash_area.size;
> -    static int is_reserved = 0;
> +    static bool_t __initdata is_reserved = 0;
>  
>      kdump_size = (kdump_size + PAGE_SIZE - 1) & PAGE_MASK;
>  
> @@ -1330,7 +1330,7 @@ void __init __start_xen(unsigned long mb
>      cmdline = (char *)(mod[0].string ? __va(mod[0].string) : NULL);
>      if ( (cmdline != NULL) || (kextra != NULL) )
>      {
> -        static char dom0_cmdline[MAX_GUEST_CMDLINE];
> +        static char __initdata dom0_cmdline[MAX_GUEST_CMDLINE];
>  
>          cmdline = cmdline_cook(cmdline, loader);
>          safe_strcpy(dom0_cmdline, cmdline);
> @@ -1430,7 +1430,7 @@ int __init xen_in_range(unsigned long mf
>      enum { region_s3, region_text, region_bss, nr_regions };
>      static struct {
>          paddr_t s, e;
> -    } xen_regions[nr_regions];
> +    } xen_regions[nr_regions] __initdata;
>  
>      /* initialize first time */
>      if ( !xen_regions[0].s )
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 21 08:14:11 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 08: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.xensource.com>)
	id 1RdHJD-0002wr-7y; Wed, 21 Dec 2011 08:13:55 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RdHJB-0002w2-F5
	for xen-devel@lists.xensource.com; Wed, 21 Dec 2011 08:13:53 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1324455226!1589470!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19218 invoked from network); 21 Dec 2011 08:13:47 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-5.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Dec 2011 08:13:47 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 21 Dec 2011 08:13:46 +0000
Message-Id: <4EF1A38002000078000694B6@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 21 Dec 2011 08:14:40 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part220D9060.0__="
Subject: [Xen-devel] [PATCH] x86: reduce scope of some symbols used with
 reset_stack_and_jump()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__Part220D9060.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

By making the macro properly advertise the use of the input symbol to
the compiler, it is no longer necessary for them to be global if
they're defined and used in just one source file.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -74,17 +74,6 @@ static void paravirt_ctxt_switch_to(stru
=20
 static void vcpu_destroy_pagetables(struct vcpu *v);
=20
-static void continue_idle_domain(struct vcpu *v)
-{
-    reset_stack_and_jump(idle_loop);
-}
-
-static void continue_nonidle_domain(struct vcpu *v)
-{
-    check_wakeup_from_wait();
-    reset_stack_and_jump(ret_from_intr);
-}
-
 static void default_idle(void)
 {
     local_irq_disable();
@@ -118,7 +107,7 @@ static void play_dead(void)
     (*dead_idle)();
 }
=20
-void idle_loop(void)
+static void idle_loop(void)
 {
     for ( ; ; )
     {
@@ -141,6 +130,17 @@ void startup_cpu_idle_loop(void)
     reset_stack_and_jump(idle_loop);
 }
=20
+static void continue_idle_domain(struct vcpu *v)
+{
+    reset_stack_and_jump(idle_loop);
+}
+
+static void continue_nonidle_domain(struct vcpu *v)
+{
+    check_wakeup_from_wait();
+    reset_stack_and_jump(ret_from_intr);
+}
+
 void dump_pageframe_info(struct domain *d)
 {
     struct page_info *page;
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -63,6 +63,8 @@
 #include <asm/debugger.h>
 #include <asm/xstate.h>
=20
+void svm_asm_do_resume(void);
+
 u32 svm_feature_flags;
=20
 /* Indicates whether guests may use EFER.LMSLE. */
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -508,7 +508,7 @@ static void __init kexec_reserve_area(st
     }
 }
=20
-void init_done(void)
+static void noinline init_done(void)
 {
     /* Free (or page-protect) the init areas. */
     memset(__init_begin, 0xcc, __init_end - __init_begin); /* int3 poison =
*/
--- a/xen/include/asm-x86/asm_defns.h
+++ b/xen/include/asm-x86/asm_defns.h
@@ -8,6 +8,10 @@
 #endif
 #include <asm/processor.h>
=20
+#ifndef __ASSEMBLY__
+void ret_from_intr(void);
+#endif
+
 #ifdef __x86_64__
 #include <asm/x86_64/asm_defns.h>
 #else
--- a/xen/include/asm-x86/current.h
+++ b/xen/include/asm-x86/current.h
@@ -56,8 +56,8 @@ static inline struct cpu_info *get_cpu_i
=20
 #define reset_stack_and_jump(__fn)              \
     __asm__ __volatile__ (                      \
-        "mov %0,%%"__OP"sp; jmp "STR(__fn)      \
-        : : "r" (guest_cpu_user_regs()) : "memory" )
+        "mov %0,%%"__OP"sp; jmp %c1"            \
+        : : "r" (guest_cpu_user_regs()), "i" (__fn) : "memory" )
=20
 #define schedule_tail(vcpu) (((vcpu)->arch.schedule_tail)(vcpu))
=20
--- a/xen/include/asm-x86/setup.h
+++ b/xen/include/asm-x86/setup.h
@@ -7,8 +7,6 @@
 extern bool_t early_boot;
 extern unsigned long xenheap_initial_phys_start;
=20
-void init_done(void);
-
 void early_cpu_init(void);
 void early_time_init(void);
 void early_page_fault(void);




--=__Part220D9060.0__=
Content-Type: text/plain; name="x86-static-syms.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-static-syms.patch"

x86: reduce scope of some symbols used with reset_stack_and_jump()=0A=0ABy =
making the macro properly advertise the use of the input symbol to=0Athe =
compiler, it is no longer necessary for them to be global if=0Athey're =
defined and used in just one source file.=0A=0ASigned-off-by: Jan Beulich =
<jbeulich@suse.com>=0A=0A--- a/xen/arch/x86/domain.c=0A+++ b/xen/arch/x86/d=
omain.c=0A@@ -74,17 +74,6 @@ static void paravirt_ctxt_switch_to(stru=0A =
=0A static void vcpu_destroy_pagetables(struct vcpu *v);=0A =0A-static =
void continue_idle_domain(struct vcpu *v)=0A-{=0A-    reset_stack_and_jump(=
idle_loop);=0A-}=0A-=0A-static void continue_nonidle_domain(struct vcpu =
*v)=0A-{=0A-    check_wakeup_from_wait();=0A-    reset_stack_and_jump(ret_f=
rom_intr);=0A-}=0A-=0A static void default_idle(void)=0A {=0A     =
local_irq_disable();=0A@@ -118,7 +107,7 @@ static void play_dead(void)=0A  =
   (*dead_idle)();=0A }=0A =0A-void idle_loop(void)=0A+static void =
idle_loop(void)=0A {=0A     for ( ; ; )=0A     {=0A@@ -141,6 +130,17 @@ =
void startup_cpu_idle_loop(void)=0A     reset_stack_and_jump(idle_loop);=0A=
 }=0A =0A+static void continue_idle_domain(struct vcpu *v)=0A+{=0A+    =
reset_stack_and_jump(idle_loop);=0A+}=0A+=0A+static void continue_nonidle_d=
omain(struct vcpu *v)=0A+{=0A+    check_wakeup_from_wait();=0A+    =
reset_stack_and_jump(ret_from_intr);=0A+}=0A+=0A void dump_pageframe_info(s=
truct domain *d)=0A {=0A     struct page_info *page;=0A--- a/xen/arch/x86/h=
vm/svm/svm.c=0A+++ b/xen/arch/x86/hvm/svm/svm.c=0A@@ -63,6 +63,8 @@=0A =
#include <asm/debugger.h>=0A #include <asm/xstate.h>=0A =0A+void svm_asm_do=
_resume(void);=0A+=0A u32 svm_feature_flags;=0A =0A /* Indicates whether =
guests may use EFER.LMSLE. */=0A--- a/xen/arch/x86/setup.c=0A+++ b/xen/arch=
/x86/setup.c=0A@@ -508,7 +508,7 @@ static void __init kexec_reserve_area(st=
=0A     }=0A }=0A =0A-void init_done(void)=0A+static void noinline =
init_done(void)=0A {=0A     /* Free (or page-protect) the init areas. =
*/=0A     memset(__init_begin, 0xcc, __init_end - __init_begin); /* int3 =
poison */=0A--- a/xen/include/asm-x86/asm_defns.h=0A+++ b/xen/include/asm-x=
86/asm_defns.h=0A@@ -8,6 +8,10 @@=0A #endif=0A #include <asm/processor.h>=
=0A =0A+#ifndef __ASSEMBLY__=0A+void ret_from_intr(void);=0A+#endif=0A+=0A =
#ifdef __x86_64__=0A #include <asm/x86_64/asm_defns.h>=0A #else=0A--- =
a/xen/include/asm-x86/current.h=0A+++ b/xen/include/asm-x86/current.h=0A@@ =
-56,8 +56,8 @@ static inline struct cpu_info *get_cpu_i=0A =0A #define =
reset_stack_and_jump(__fn)              \=0A     __asm__ __volatile__ (    =
                  \=0A-        "mov %0,%%"__OP"sp; jmp "STR(__fn)      =
\=0A-        : : "r" (guest_cpu_user_regs()) : "memory" )=0A+        "mov =
%0,%%"__OP"sp; jmp %c1"            \=0A+        : : "r" (guest_cpu_user_reg=
s()), "i" (__fn) : "memory" )=0A =0A #define schedule_tail(vcpu) (((vcpu)->=
arch.schedule_tail)(vcpu))=0A =0A--- a/xen/include/asm-x86/setup.h=0A+++ =
b/xen/include/asm-x86/setup.h=0A@@ -7,8 +7,6 @@=0A extern bool_t early_boot=
;=0A extern unsigned long xenheap_initial_phys_start;=0A =0A-void =
init_done(void);=0A-=0A void early_cpu_init(void);=0A void early_time_init(=
void);=0A void early_page_fault(void);=0A
--=__Part220D9060.0__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--=__Part220D9060.0__=--


From xen-devel-bounces@lists.xensource.com Wed Dec 21 08:14:11 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 08: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.xensource.com>)
	id 1RdHJD-0002wr-7y; Wed, 21 Dec 2011 08:13:55 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RdHJB-0002w2-F5
	for xen-devel@lists.xensource.com; Wed, 21 Dec 2011 08:13:53 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1324455226!1589470!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19218 invoked from network); 21 Dec 2011 08:13:47 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-5.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Dec 2011 08:13:47 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 21 Dec 2011 08:13:46 +0000
Message-Id: <4EF1A38002000078000694B6@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 21 Dec 2011 08:14:40 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part220D9060.0__="
Subject: [Xen-devel] [PATCH] x86: reduce scope of some symbols used with
 reset_stack_and_jump()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__Part220D9060.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

By making the macro properly advertise the use of the input symbol to
the compiler, it is no longer necessary for them to be global if
they're defined and used in just one source file.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -74,17 +74,6 @@ static void paravirt_ctxt_switch_to(stru
=20
 static void vcpu_destroy_pagetables(struct vcpu *v);
=20
-static void continue_idle_domain(struct vcpu *v)
-{
-    reset_stack_and_jump(idle_loop);
-}
-
-static void continue_nonidle_domain(struct vcpu *v)
-{
-    check_wakeup_from_wait();
-    reset_stack_and_jump(ret_from_intr);
-}
-
 static void default_idle(void)
 {
     local_irq_disable();
@@ -118,7 +107,7 @@ static void play_dead(void)
     (*dead_idle)();
 }
=20
-void idle_loop(void)
+static void idle_loop(void)
 {
     for ( ; ; )
     {
@@ -141,6 +130,17 @@ void startup_cpu_idle_loop(void)
     reset_stack_and_jump(idle_loop);
 }
=20
+static void continue_idle_domain(struct vcpu *v)
+{
+    reset_stack_and_jump(idle_loop);
+}
+
+static void continue_nonidle_domain(struct vcpu *v)
+{
+    check_wakeup_from_wait();
+    reset_stack_and_jump(ret_from_intr);
+}
+
 void dump_pageframe_info(struct domain *d)
 {
     struct page_info *page;
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -63,6 +63,8 @@
 #include <asm/debugger.h>
 #include <asm/xstate.h>
=20
+void svm_asm_do_resume(void);
+
 u32 svm_feature_flags;
=20
 /* Indicates whether guests may use EFER.LMSLE. */
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -508,7 +508,7 @@ static void __init kexec_reserve_area(st
     }
 }
=20
-void init_done(void)
+static void noinline init_done(void)
 {
     /* Free (or page-protect) the init areas. */
     memset(__init_begin, 0xcc, __init_end - __init_begin); /* int3 poison =
*/
--- a/xen/include/asm-x86/asm_defns.h
+++ b/xen/include/asm-x86/asm_defns.h
@@ -8,6 +8,10 @@
 #endif
 #include <asm/processor.h>
=20
+#ifndef __ASSEMBLY__
+void ret_from_intr(void);
+#endif
+
 #ifdef __x86_64__
 #include <asm/x86_64/asm_defns.h>
 #else
--- a/xen/include/asm-x86/current.h
+++ b/xen/include/asm-x86/current.h
@@ -56,8 +56,8 @@ static inline struct cpu_info *get_cpu_i
=20
 #define reset_stack_and_jump(__fn)              \
     __asm__ __volatile__ (                      \
-        "mov %0,%%"__OP"sp; jmp "STR(__fn)      \
-        : : "r" (guest_cpu_user_regs()) : "memory" )
+        "mov %0,%%"__OP"sp; jmp %c1"            \
+        : : "r" (guest_cpu_user_regs()), "i" (__fn) : "memory" )
=20
 #define schedule_tail(vcpu) (((vcpu)->arch.schedule_tail)(vcpu))
=20
--- a/xen/include/asm-x86/setup.h
+++ b/xen/include/asm-x86/setup.h
@@ -7,8 +7,6 @@
 extern bool_t early_boot;
 extern unsigned long xenheap_initial_phys_start;
=20
-void init_done(void);
-
 void early_cpu_init(void);
 void early_time_init(void);
 void early_page_fault(void);




--=__Part220D9060.0__=
Content-Type: text/plain; name="x86-static-syms.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-static-syms.patch"

x86: reduce scope of some symbols used with reset_stack_and_jump()=0A=0ABy =
making the macro properly advertise the use of the input symbol to=0Athe =
compiler, it is no longer necessary for them to be global if=0Athey're =
defined and used in just one source file.=0A=0ASigned-off-by: Jan Beulich =
<jbeulich@suse.com>=0A=0A--- a/xen/arch/x86/domain.c=0A+++ b/xen/arch/x86/d=
omain.c=0A@@ -74,17 +74,6 @@ static void paravirt_ctxt_switch_to(stru=0A =
=0A static void vcpu_destroy_pagetables(struct vcpu *v);=0A =0A-static =
void continue_idle_domain(struct vcpu *v)=0A-{=0A-    reset_stack_and_jump(=
idle_loop);=0A-}=0A-=0A-static void continue_nonidle_domain(struct vcpu =
*v)=0A-{=0A-    check_wakeup_from_wait();=0A-    reset_stack_and_jump(ret_f=
rom_intr);=0A-}=0A-=0A static void default_idle(void)=0A {=0A     =
local_irq_disable();=0A@@ -118,7 +107,7 @@ static void play_dead(void)=0A  =
   (*dead_idle)();=0A }=0A =0A-void idle_loop(void)=0A+static void =
idle_loop(void)=0A {=0A     for ( ; ; )=0A     {=0A@@ -141,6 +130,17 @@ =
void startup_cpu_idle_loop(void)=0A     reset_stack_and_jump(idle_loop);=0A=
 }=0A =0A+static void continue_idle_domain(struct vcpu *v)=0A+{=0A+    =
reset_stack_and_jump(idle_loop);=0A+}=0A+=0A+static void continue_nonidle_d=
omain(struct vcpu *v)=0A+{=0A+    check_wakeup_from_wait();=0A+    =
reset_stack_and_jump(ret_from_intr);=0A+}=0A+=0A void dump_pageframe_info(s=
truct domain *d)=0A {=0A     struct page_info *page;=0A--- a/xen/arch/x86/h=
vm/svm/svm.c=0A+++ b/xen/arch/x86/hvm/svm/svm.c=0A@@ -63,6 +63,8 @@=0A =
#include <asm/debugger.h>=0A #include <asm/xstate.h>=0A =0A+void svm_asm_do=
_resume(void);=0A+=0A u32 svm_feature_flags;=0A =0A /* Indicates whether =
guests may use EFER.LMSLE. */=0A--- a/xen/arch/x86/setup.c=0A+++ b/xen/arch=
/x86/setup.c=0A@@ -508,7 +508,7 @@ static void __init kexec_reserve_area(st=
=0A     }=0A }=0A =0A-void init_done(void)=0A+static void noinline =
init_done(void)=0A {=0A     /* Free (or page-protect) the init areas. =
*/=0A     memset(__init_begin, 0xcc, __init_end - __init_begin); /* int3 =
poison */=0A--- a/xen/include/asm-x86/asm_defns.h=0A+++ b/xen/include/asm-x=
86/asm_defns.h=0A@@ -8,6 +8,10 @@=0A #endif=0A #include <asm/processor.h>=
=0A =0A+#ifndef __ASSEMBLY__=0A+void ret_from_intr(void);=0A+#endif=0A+=0A =
#ifdef __x86_64__=0A #include <asm/x86_64/asm_defns.h>=0A #else=0A--- =
a/xen/include/asm-x86/current.h=0A+++ b/xen/include/asm-x86/current.h=0A@@ =
-56,8 +56,8 @@ static inline struct cpu_info *get_cpu_i=0A =0A #define =
reset_stack_and_jump(__fn)              \=0A     __asm__ __volatile__ (    =
                  \=0A-        "mov %0,%%"__OP"sp; jmp "STR(__fn)      =
\=0A-        : : "r" (guest_cpu_user_regs()) : "memory" )=0A+        "mov =
%0,%%"__OP"sp; jmp %c1"            \=0A+        : : "r" (guest_cpu_user_reg=
s()), "i" (__fn) : "memory" )=0A =0A #define schedule_tail(vcpu) (((vcpu)->=
arch.schedule_tail)(vcpu))=0A =0A--- a/xen/include/asm-x86/setup.h=0A+++ =
b/xen/include/asm-x86/setup.h=0A@@ -7,8 +7,6 @@=0A extern bool_t early_boot=
;=0A extern unsigned long xenheap_initial_phys_start;=0A =0A-void =
init_done(void);=0A-=0A void early_cpu_init(void);=0A void early_time_init(=
void);=0A void early_page_fault(void);=0A
--=__Part220D9060.0__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--=__Part220D9060.0__=--


From xen-devel-bounces@lists.xensource.com Wed Dec 21 08:31:49 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 08:31:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdHaD-0003Me-W3; Wed, 21 Dec 2011 08:31:29 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RdHaC-0003MZ-0v
	for xen-devel@lists.xensource.com; Wed, 21 Dec 2011 08:31:28 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1324456247!53272463!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13621 invoked from network); 21 Dec 2011 08:30:48 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-4.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Dec 2011 08:30:48 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 21 Dec 2011 08:31:23 +0000
Message-Id: <4EF1A7A002000078000694CA@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 21 Dec 2011 08:32:16 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Laszlo Ersek" <lersek@redhat.com>
References: <1318970579-6282-1-git-send-email-lersek@redhat.com>
In-Reply-To: <1318970579-6282-1-git-send-email-lersek@redhat.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, xen-devel@lists.xensource.com,
	Joe Jin <joe.jin@oracle.com>, Zhenzhong Duan <zhenzhong.duan@oracle.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH] remove blocked time accounting from xen
 "clockchip"
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 18.10.11 at 22:42, Laszlo Ersek <lersek@redhat.com> wrote:
> ... because the "clock_event_device framework" already accounts for idle
> time through the "event_handler" function pointer in
> xen_timer_interrupt().
> 
> The patch is intended as the completion of [1]. It should fix the double
> idle times seen in PV guests' /proc/stat [2]. It should be orthogonal to
> stolen time accounting (the removed code seems to be isolated).

Finally found time to play with this a little myself. As expected, the
change brings a significant improvement, but isn't sufficient to be
on par with the forward port kernels not using the clockevent
infrastructure (we switched to this only in 2.6.34 and above) when
it comes to correct steal time accounting.

Specifically, without further adjustments, on a 4:3 over-committed
system doing a kernel build, I'm seeing an over-accounting of
approximately 4%. I was able to reduce this to slightly above 1%
with below (experimental and not 32-bit compatible) change:

--- a/kernel/sched.c
+++ b/kernel/sched.c
@@ -3864,6 +3864,29 @@
 	return ns;
 }
 
+#ifndef CONFIG_XEN
+#define _cputime_to_cputime64 cputime_to_cputime64
+#else
+#define NS_PER_TICK (1000000000 / HZ)
+static DEFINE_PER_CPU(u64, stolen_snapshot);
+static DEFINE_PER_CPU(unsigned int, stolen_residual);
+
+static cputime64_t _cputime_to_cputime64(cputime_t t)
+{
+	//todo not entirely suitable for 32-bit
+	u64 s = this_cpu_read(runstate.time[RUNSTATE_runnable]);
+	unsigned long adj = div_u64_rem(s - this_cpu_read(stolen_snapshot)
+					  + this_cpu_read(stolen_residual),
+					NS_PER_TICK,
+					&__get_cpu_var(stolen_residual));
+
+	this_cpu_write(stolen_snapshot, s);
+	t = cputime_sub(t, jiffies_to_cputime(adj));
+
+	return cputime_le(t, cputime_max) ? cputime_to_cputime64(t) : 0;
+}
+#endif
+
 /*
  * Account user cpu time to a process.
  * @p: the process that the cpu time gets accounted to
@@ -3882,7 +3905,7 @@
 	account_group_user_time(p, cputime);
 
 	/* Add user time to cpustat. */
-	tmp = cputime_to_cputime64(cputime);
+	tmp = _cputime_to_cputime64(cputime);
 	if (TASK_NICE(p) > 0)
 		cpustat->nice = cputime64_add(cpustat->nice, tmp);
 	else
@@ -3934,7 +3957,7 @@
 void __account_system_time(struct task_struct *p, cputime_t cputime,
 			cputime_t cputime_scaled, cputime64_t *target_cputime64)
 {
-	cputime64_t tmp = cputime_to_cputime64(cputime);
+	cputime64_t tmp = _cputime_to_cputime64(cputime);
 
 	/* Add system time to process. */
 	p->stime = cputime_add(p->stime, cputime);
@@ -3996,7 +4019,7 @@
 void account_idle_time(cputime_t cputime)
 {
 	struct cpu_usage_stat *cpustat = &kstat_this_cpu.cpustat;
-	cputime64_t cputime64 = cputime_to_cputime64(cputime);
+	cputime64_t cputime64 = _cputime_to_cputime64(cputime);
 	struct rq *rq = this_rq();
 
 	if (atomic_read(&rq->nr_iowait) > 0)
@@ -4033,7 +4056,7 @@
 						struct rq *rq)
 {
 	cputime_t one_jiffy_scaled = cputime_to_scaled(cputime_one_jiffy);
-	cputime64_t tmp = cputime_to_cputime64(cputime_one_jiffy);
+	cputime64_t tmp = _cputime_to_cputime64(cputime_one_jiffy);
 	struct cpu_usage_stat *cpustat = &kstat_this_cpu.cpustat;
 
 	if (irqtime_account_hi_update()) {

I currently have no idea what the remain 1% could be attributed to,
so thoughts from others would certainly be welcome.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 21 08:31:49 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 08:31:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdHaD-0003Me-W3; Wed, 21 Dec 2011 08:31:29 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RdHaC-0003MZ-0v
	for xen-devel@lists.xensource.com; Wed, 21 Dec 2011 08:31:28 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1324456247!53272463!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13621 invoked from network); 21 Dec 2011 08:30:48 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-4.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Dec 2011 08:30:48 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 21 Dec 2011 08:31:23 +0000
Message-Id: <4EF1A7A002000078000694CA@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 21 Dec 2011 08:32:16 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Laszlo Ersek" <lersek@redhat.com>
References: <1318970579-6282-1-git-send-email-lersek@redhat.com>
In-Reply-To: <1318970579-6282-1-git-send-email-lersek@redhat.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, xen-devel@lists.xensource.com,
	Joe Jin <joe.jin@oracle.com>, Zhenzhong Duan <zhenzhong.duan@oracle.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH] remove blocked time accounting from xen
 "clockchip"
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 18.10.11 at 22:42, Laszlo Ersek <lersek@redhat.com> wrote:
> ... because the "clock_event_device framework" already accounts for idle
> time through the "event_handler" function pointer in
> xen_timer_interrupt().
> 
> The patch is intended as the completion of [1]. It should fix the double
> idle times seen in PV guests' /proc/stat [2]. It should be orthogonal to
> stolen time accounting (the removed code seems to be isolated).

Finally found time to play with this a little myself. As expected, the
change brings a significant improvement, but isn't sufficient to be
on par with the forward port kernels not using the clockevent
infrastructure (we switched to this only in 2.6.34 and above) when
it comes to correct steal time accounting.

Specifically, without further adjustments, on a 4:3 over-committed
system doing a kernel build, I'm seeing an over-accounting of
approximately 4%. I was able to reduce this to slightly above 1%
with below (experimental and not 32-bit compatible) change:

--- a/kernel/sched.c
+++ b/kernel/sched.c
@@ -3864,6 +3864,29 @@
 	return ns;
 }
 
+#ifndef CONFIG_XEN
+#define _cputime_to_cputime64 cputime_to_cputime64
+#else
+#define NS_PER_TICK (1000000000 / HZ)
+static DEFINE_PER_CPU(u64, stolen_snapshot);
+static DEFINE_PER_CPU(unsigned int, stolen_residual);
+
+static cputime64_t _cputime_to_cputime64(cputime_t t)
+{
+	//todo not entirely suitable for 32-bit
+	u64 s = this_cpu_read(runstate.time[RUNSTATE_runnable]);
+	unsigned long adj = div_u64_rem(s - this_cpu_read(stolen_snapshot)
+					  + this_cpu_read(stolen_residual),
+					NS_PER_TICK,
+					&__get_cpu_var(stolen_residual));
+
+	this_cpu_write(stolen_snapshot, s);
+	t = cputime_sub(t, jiffies_to_cputime(adj));
+
+	return cputime_le(t, cputime_max) ? cputime_to_cputime64(t) : 0;
+}
+#endif
+
 /*
  * Account user cpu time to a process.
  * @p: the process that the cpu time gets accounted to
@@ -3882,7 +3905,7 @@
 	account_group_user_time(p, cputime);
 
 	/* Add user time to cpustat. */
-	tmp = cputime_to_cputime64(cputime);
+	tmp = _cputime_to_cputime64(cputime);
 	if (TASK_NICE(p) > 0)
 		cpustat->nice = cputime64_add(cpustat->nice, tmp);
 	else
@@ -3934,7 +3957,7 @@
 void __account_system_time(struct task_struct *p, cputime_t cputime,
 			cputime_t cputime_scaled, cputime64_t *target_cputime64)
 {
-	cputime64_t tmp = cputime_to_cputime64(cputime);
+	cputime64_t tmp = _cputime_to_cputime64(cputime);
 
 	/* Add system time to process. */
 	p->stime = cputime_add(p->stime, cputime);
@@ -3996,7 +4019,7 @@
 void account_idle_time(cputime_t cputime)
 {
 	struct cpu_usage_stat *cpustat = &kstat_this_cpu.cpustat;
-	cputime64_t cputime64 = cputime_to_cputime64(cputime);
+	cputime64_t cputime64 = _cputime_to_cputime64(cputime);
 	struct rq *rq = this_rq();
 
 	if (atomic_read(&rq->nr_iowait) > 0)
@@ -4033,7 +4056,7 @@
 						struct rq *rq)
 {
 	cputime_t one_jiffy_scaled = cputime_to_scaled(cputime_one_jiffy);
-	cputime64_t tmp = cputime_to_cputime64(cputime_one_jiffy);
+	cputime64_t tmp = _cputime_to_cputime64(cputime_one_jiffy);
 	struct cpu_usage_stat *cpustat = &kstat_this_cpu.cpustat;
 
 	if (irqtime_account_hi_update()) {

I currently have no idea what the remain 1% could be attributed to,
so thoughts from others would certainly be welcome.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 21 08:40:19 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 08:40:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdHiP-0003X4-44; Wed, 21 Dec 2011 08:39:57 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mike.mcclurg@citrix.com>)
	id 1RdHiN-0003Wr-Si; Wed, 21 Dec 2011 08:39:56 +0000
X-Env-Sender: mike.mcclurg@citrix.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1324456787!6372057!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjQzNTA=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7348 invoked from network); 21 Dec 2011 08:39:49 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Dec 2011 08:39:49 -0000
X-IronPort-AV: E=Sophos;i="4.71,387,1320642000"; d="scan'208";a="174972745"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Dec 2011 03:39:47 -0500
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Wed, 21 Dec 2011
	03:39:47 -0500
Message-ID: <4EF19B51.50401@citrix.com>
Date: Wed, 21 Dec 2011 08:39:45 +0000
From: Mike McClurg <mike.mcclurg@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:8.0) Gecko/20111124 Thunderbird/8.0
MIME-Version: 1.0
To: "Fajar A. Nugraha" <list@fajar.net>
References: <D14C52F5-9E35-43F1-9D0E-10336DB51BBD@UFL.EDU>
	<20111219082207.GE12984@reaktio.net>	<4EF0E48E.6010900@citrix.com>
	<CAG1y0seAdN1RiNBmFw-cNrKwAzdi83HaaSGtfCei8JXy31xE2w@mail.gmail.com>
In-Reply-To: <CAG1y0seAdN1RiNBmFw-cNrKwAzdi83HaaSGtfCei8JXy31xE2w@mail.gmail.com>
X-Enigmail-Version: 1.3.4
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	ruijin zhou <zhourj@ufl.edu>,
	"xen-api@lists.xensource.com" <xen-api@lists.xensource.com>
Subject: Re: [Xen-devel] [Xen-API] CrossPoolMigration
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 21/12/11 03:10, Fajar A. Nugraha wrote:
> On Wed, Dec 21, 2011 at 2:39 AM, Mike McClurg <mike.mcclurg@citrix.com> wrote:
>> Storage motion is something that we are prototyping for XCP/XenServer.
>> It will not be a part of the Xen hypervisor. We'll probably start more
>> work on the prototype in January, and we'll post details of our
>> implementation plan to this list.
> 
> Is still based on drbd and tap, as in the wiki page? If yes, it'd be
> ... interesting (to say the least) to see how these issues will be
> handled:
> - space for drbd metadata:
> http://www.drbd.org/users-guide/ch-internals.html#s-metadata
> - performance penalty and choice of replication modes:
> http://www.drbd.org/users-guide-emb/s-replication-protocols.html
> - general tap issues (qdisk vs module, vanilla vs patched 2.6.32, etc.)
> 

Thanks for those links. No, the current plan is not to use DRBD, though
I can't remember the reasons that Dave decided against it.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 21 08:40:19 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 08:40:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdHiP-0003X4-44; Wed, 21 Dec 2011 08:39:57 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mike.mcclurg@citrix.com>)
	id 1RdHiN-0003Wr-Si; Wed, 21 Dec 2011 08:39:56 +0000
X-Env-Sender: mike.mcclurg@citrix.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1324456787!6372057!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjQzNTA=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7348 invoked from network); 21 Dec 2011 08:39:49 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Dec 2011 08:39:49 -0000
X-IronPort-AV: E=Sophos;i="4.71,387,1320642000"; d="scan'208";a="174972745"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Dec 2011 03:39:47 -0500
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Wed, 21 Dec 2011
	03:39:47 -0500
Message-ID: <4EF19B51.50401@citrix.com>
Date: Wed, 21 Dec 2011 08:39:45 +0000
From: Mike McClurg <mike.mcclurg@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:8.0) Gecko/20111124 Thunderbird/8.0
MIME-Version: 1.0
To: "Fajar A. Nugraha" <list@fajar.net>
References: <D14C52F5-9E35-43F1-9D0E-10336DB51BBD@UFL.EDU>
	<20111219082207.GE12984@reaktio.net>	<4EF0E48E.6010900@citrix.com>
	<CAG1y0seAdN1RiNBmFw-cNrKwAzdi83HaaSGtfCei8JXy31xE2w@mail.gmail.com>
In-Reply-To: <CAG1y0seAdN1RiNBmFw-cNrKwAzdi83HaaSGtfCei8JXy31xE2w@mail.gmail.com>
X-Enigmail-Version: 1.3.4
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	ruijin zhou <zhourj@ufl.edu>,
	"xen-api@lists.xensource.com" <xen-api@lists.xensource.com>
Subject: Re: [Xen-devel] [Xen-API] CrossPoolMigration
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 21/12/11 03:10, Fajar A. Nugraha wrote:
> On Wed, Dec 21, 2011 at 2:39 AM, Mike McClurg <mike.mcclurg@citrix.com> wrote:
>> Storage motion is something that we are prototyping for XCP/XenServer.
>> It will not be a part of the Xen hypervisor. We'll probably start more
>> work on the prototype in January, and we'll post details of our
>> implementation plan to this list.
> 
> Is still based on drbd and tap, as in the wiki page? If yes, it'd be
> ... interesting (to say the least) to see how these issues will be
> handled:
> - space for drbd metadata:
> http://www.drbd.org/users-guide/ch-internals.html#s-metadata
> - performance penalty and choice of replication modes:
> http://www.drbd.org/users-guide-emb/s-replication-protocols.html
> - general tap issues (qdisk vs module, vanilla vs patched 2.6.32, etc.)
> 

Thanks for those links. No, the current plan is not to use DRBD, though
I can't remember the reasons that Dave decided against it.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 21 08:48:31 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 08: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.xensource.com>)
	id 1RdHqQ-0003k5-3s; Wed, 21 Dec 2011 08:48:14 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RdHqO-0003k0-Ti
	for xen-devel@lists.xensource.com; Wed, 21 Dec 2011 08:48:13 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1324457259!45714877!1
X-Originating-IP: [209.85.216.50]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1970 invoked from network); 21 Dec 2011 08:47:40 -0000
Received: from mail-qw0-f50.google.com (HELO mail-qw0-f50.google.com)
	(209.85.216.50)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Dec 2011 08:47:40 -0000
Received: by qaea17 with SMTP id a17so30355061qae.9
	for <xen-devel@lists.xensource.com>;
	Wed, 21 Dec 2011 00:48:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=Aok2BsKuNZ2GIT3XnRfuTbmjbkaFl9xF36qkj12TimA=;
	b=meyGdiXb8C7fZd/8SrkwGjhFaLNnDTs7I+zDi7oNFuT+W21AMgkQOvkCkN42c73Tg6
	lKqB3IAE0MnJiZXv2/EyGLA1OOivSzU3U7K7bOk6nbc6FDs9i8KIzQ0U33h+r7o2iiCx
	qBqqCLABu10vQdJuB5xtBIKqX/RIprxcbJ5TI=
Received: by 10.224.18.66 with SMTP id v2mr7232553qaa.91.1324457290468;
	Wed, 21 Dec 2011 00:48:10 -0800 (PST)
Received: from [192.168.1.70] (host81-152-17-11.range81-152.btcentralplus.com.
	[81.152.17.11])
	by mx.google.com with ESMTPS id dj9sm9204998qab.18.2011.12.21.00.48.07
	(version=SSLv3 cipher=OTHER); Wed, 21 Dec 2011 00:48:09 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Wed, 21 Dec 2011 08:48:03 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Message-ID: <CB174DC3.27AC0%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH] x86: reduce scope of some symbols used with
	reset_stack_and_jump()
Thread-Index: Acy/vT/6/kGUkcrkfkC9Ti3N+xTmEA==
In-Reply-To: <4EF1A38002000078000694B6@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH] x86: reduce scope of some symbols used with
 reset_stack_and_jump()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 21/12/2011 08:14, "Jan Beulich" <JBeulich@suse.com> wrote:

> By making the macro properly advertise the use of the input symbol to
> the compiler, it is no longer necessary for them to be global if
> they're defined and used in just one source file.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Keir Fraser <keir@xen.org>

> --- a/xen/arch/x86/domain.c
> +++ b/xen/arch/x86/domain.c
> @@ -74,17 +74,6 @@ static void paravirt_ctxt_switch_to(stru
>  
>  static void vcpu_destroy_pagetables(struct vcpu *v);
>  
> -static void continue_idle_domain(struct vcpu *v)
> -{
> -    reset_stack_and_jump(idle_loop);
> -}
> -
> -static void continue_nonidle_domain(struct vcpu *v)
> -{
> -    check_wakeup_from_wait();
> -    reset_stack_and_jump(ret_from_intr);
> -}
> -
>  static void default_idle(void)
>  {
>      local_irq_disable();
> @@ -118,7 +107,7 @@ static void play_dead(void)
>      (*dead_idle)();
>  }
>  
> -void idle_loop(void)
> +static void idle_loop(void)
>  {
>      for ( ; ; )
>      {
> @@ -141,6 +130,17 @@ void startup_cpu_idle_loop(void)
>      reset_stack_and_jump(idle_loop);
>  }
>  
> +static void continue_idle_domain(struct vcpu *v)
> +{
> +    reset_stack_and_jump(idle_loop);
> +}
> +
> +static void continue_nonidle_domain(struct vcpu *v)
> +{
> +    check_wakeup_from_wait();
> +    reset_stack_and_jump(ret_from_intr);
> +}
> +
>  void dump_pageframe_info(struct domain *d)
>  {
>      struct page_info *page;
> --- a/xen/arch/x86/hvm/svm/svm.c
> +++ b/xen/arch/x86/hvm/svm/svm.c
> @@ -63,6 +63,8 @@
>  #include <asm/debugger.h>
>  #include <asm/xstate.h>
>  
> +void svm_asm_do_resume(void);
> +
>  u32 svm_feature_flags;
>  
>  /* Indicates whether guests may use EFER.LMSLE. */
> --- a/xen/arch/x86/setup.c
> +++ b/xen/arch/x86/setup.c
> @@ -508,7 +508,7 @@ static void __init kexec_reserve_area(st
>      }
>  }
>  
> -void init_done(void)
> +static void noinline init_done(void)
>  {
>      /* Free (or page-protect) the init areas. */
>      memset(__init_begin, 0xcc, __init_end - __init_begin); /* int3 poison */
> --- a/xen/include/asm-x86/asm_defns.h
> +++ b/xen/include/asm-x86/asm_defns.h
> @@ -8,6 +8,10 @@
>  #endif
>  #include <asm/processor.h>
>  
> +#ifndef __ASSEMBLY__
> +void ret_from_intr(void);
> +#endif
> +
>  #ifdef __x86_64__
>  #include <asm/x86_64/asm_defns.h>
>  #else
> --- a/xen/include/asm-x86/current.h
> +++ b/xen/include/asm-x86/current.h
> @@ -56,8 +56,8 @@ static inline struct cpu_info *get_cpu_i
>  
>  #define reset_stack_and_jump(__fn)              \
>      __asm__ __volatile__ (                      \
> -        "mov %0,%%"__OP"sp; jmp "STR(__fn)      \
> -        : : "r" (guest_cpu_user_regs()) : "memory" )
> +        "mov %0,%%"__OP"sp; jmp %c1"            \
> +        : : "r" (guest_cpu_user_regs()), "i" (__fn) : "memory" )
>  
>  #define schedule_tail(vcpu) (((vcpu)->arch.schedule_tail)(vcpu))
>  
> --- a/xen/include/asm-x86/setup.h
> +++ b/xen/include/asm-x86/setup.h
> @@ -7,8 +7,6 @@
>  extern bool_t early_boot;
>  extern unsigned long xenheap_initial_phys_start;
>  
> -void init_done(void);
> -
>  void early_cpu_init(void);
>  void early_time_init(void);
>  void early_page_fault(void);
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 21 08:48:31 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 08: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.xensource.com>)
	id 1RdHqQ-0003k5-3s; Wed, 21 Dec 2011 08:48:14 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RdHqO-0003k0-Ti
	for xen-devel@lists.xensource.com; Wed, 21 Dec 2011 08:48:13 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1324457259!45714877!1
X-Originating-IP: [209.85.216.50]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1970 invoked from network); 21 Dec 2011 08:47:40 -0000
Received: from mail-qw0-f50.google.com (HELO mail-qw0-f50.google.com)
	(209.85.216.50)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Dec 2011 08:47:40 -0000
Received: by qaea17 with SMTP id a17so30355061qae.9
	for <xen-devel@lists.xensource.com>;
	Wed, 21 Dec 2011 00:48:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=Aok2BsKuNZ2GIT3XnRfuTbmjbkaFl9xF36qkj12TimA=;
	b=meyGdiXb8C7fZd/8SrkwGjhFaLNnDTs7I+zDi7oNFuT+W21AMgkQOvkCkN42c73Tg6
	lKqB3IAE0MnJiZXv2/EyGLA1OOivSzU3U7K7bOk6nbc6FDs9i8KIzQ0U33h+r7o2iiCx
	qBqqCLABu10vQdJuB5xtBIKqX/RIprxcbJ5TI=
Received: by 10.224.18.66 with SMTP id v2mr7232553qaa.91.1324457290468;
	Wed, 21 Dec 2011 00:48:10 -0800 (PST)
Received: from [192.168.1.70] (host81-152-17-11.range81-152.btcentralplus.com.
	[81.152.17.11])
	by mx.google.com with ESMTPS id dj9sm9204998qab.18.2011.12.21.00.48.07
	(version=SSLv3 cipher=OTHER); Wed, 21 Dec 2011 00:48:09 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Wed, 21 Dec 2011 08:48:03 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Message-ID: <CB174DC3.27AC0%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH] x86: reduce scope of some symbols used with
	reset_stack_and_jump()
Thread-Index: Acy/vT/6/kGUkcrkfkC9Ti3N+xTmEA==
In-Reply-To: <4EF1A38002000078000694B6@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH] x86: reduce scope of some symbols used with
 reset_stack_and_jump()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 21/12/2011 08:14, "Jan Beulich" <JBeulich@suse.com> wrote:

> By making the macro properly advertise the use of the input symbol to
> the compiler, it is no longer necessary for them to be global if
> they're defined and used in just one source file.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Keir Fraser <keir@xen.org>

> --- a/xen/arch/x86/domain.c
> +++ b/xen/arch/x86/domain.c
> @@ -74,17 +74,6 @@ static void paravirt_ctxt_switch_to(stru
>  
>  static void vcpu_destroy_pagetables(struct vcpu *v);
>  
> -static void continue_idle_domain(struct vcpu *v)
> -{
> -    reset_stack_and_jump(idle_loop);
> -}
> -
> -static void continue_nonidle_domain(struct vcpu *v)
> -{
> -    check_wakeup_from_wait();
> -    reset_stack_and_jump(ret_from_intr);
> -}
> -
>  static void default_idle(void)
>  {
>      local_irq_disable();
> @@ -118,7 +107,7 @@ static void play_dead(void)
>      (*dead_idle)();
>  }
>  
> -void idle_loop(void)
> +static void idle_loop(void)
>  {
>      for ( ; ; )
>      {
> @@ -141,6 +130,17 @@ void startup_cpu_idle_loop(void)
>      reset_stack_and_jump(idle_loop);
>  }
>  
> +static void continue_idle_domain(struct vcpu *v)
> +{
> +    reset_stack_and_jump(idle_loop);
> +}
> +
> +static void continue_nonidle_domain(struct vcpu *v)
> +{
> +    check_wakeup_from_wait();
> +    reset_stack_and_jump(ret_from_intr);
> +}
> +
>  void dump_pageframe_info(struct domain *d)
>  {
>      struct page_info *page;
> --- a/xen/arch/x86/hvm/svm/svm.c
> +++ b/xen/arch/x86/hvm/svm/svm.c
> @@ -63,6 +63,8 @@
>  #include <asm/debugger.h>
>  #include <asm/xstate.h>
>  
> +void svm_asm_do_resume(void);
> +
>  u32 svm_feature_flags;
>  
>  /* Indicates whether guests may use EFER.LMSLE. */
> --- a/xen/arch/x86/setup.c
> +++ b/xen/arch/x86/setup.c
> @@ -508,7 +508,7 @@ static void __init kexec_reserve_area(st
>      }
>  }
>  
> -void init_done(void)
> +static void noinline init_done(void)
>  {
>      /* Free (or page-protect) the init areas. */
>      memset(__init_begin, 0xcc, __init_end - __init_begin); /* int3 poison */
> --- a/xen/include/asm-x86/asm_defns.h
> +++ b/xen/include/asm-x86/asm_defns.h
> @@ -8,6 +8,10 @@
>  #endif
>  #include <asm/processor.h>
>  
> +#ifndef __ASSEMBLY__
> +void ret_from_intr(void);
> +#endif
> +
>  #ifdef __x86_64__
>  #include <asm/x86_64/asm_defns.h>
>  #else
> --- a/xen/include/asm-x86/current.h
> +++ b/xen/include/asm-x86/current.h
> @@ -56,8 +56,8 @@ static inline struct cpu_info *get_cpu_i
>  
>  #define reset_stack_and_jump(__fn)              \
>      __asm__ __volatile__ (                      \
> -        "mov %0,%%"__OP"sp; jmp "STR(__fn)      \
> -        : : "r" (guest_cpu_user_regs()) : "memory" )
> +        "mov %0,%%"__OP"sp; jmp %c1"            \
> +        : : "r" (guest_cpu_user_regs()), "i" (__fn) : "memory" )
>  
>  #define schedule_tail(vcpu) (((vcpu)->arch.schedule_tail)(vcpu))
>  
> --- a/xen/include/asm-x86/setup.h
> +++ b/xen/include/asm-x86/setup.h
> @@ -7,8 +7,6 @@
>  extern bool_t early_boot;
>  extern unsigned long xenheap_initial_phys_start;
>  
> -void init_done(void);
> -
>  void early_cpu_init(void);
>  void early_time_init(void);
>  void early_page_fault(void);
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 21 08:48:55 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 08:48:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdHqm-0003lz-MU; Wed, 21 Dec 2011 08:48:36 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RdHql-0003lR-M2
	for xen-devel@lists.xensource.com; Wed, 21 Dec 2011 08:48:35 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1324457309!6193253!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzUyMg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25650 invoked from network); 21 Dec 2011 08:48:29 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Dec 2011 08:48:29 -0000
X-IronPort-AV: E=Sophos;i="4.71,387,1320624000"; 
   d="scan'208";a="9598114"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Dec 2011 08:48:29 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 21 Dec 2011 08:48:29 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
In-Reply-To: <20111205181652.GA31962@aepfle.de>
References: <1322070039-439-1-git-send-email-anthony.perard@citrix.com>
	<1322070039-439-4-git-send-email-anthony.perard@citrix.com>
	<20111205181652.GA31962@aepfle.de>
Organization: Citrix Systems, Inc.
Date: Wed, 21 Dec 2011 08:48:28 +0000
Message-ID: <1324457308.8252.169.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
X-Mailer: Evolution 2.32.3 
Cc: Anthony Perard <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 3/3] libxl: Introduce migrate with the new
 QEMU.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2011-12-05 at 18:16 +0000, Olaf Hering wrote:
> On Wed, Nov 23, Anthony PERARD wrote:
> 
> > +    case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
> > +        fd2 = open(filename, O_WRONLY | O_CREAT | O_TRUNC);
> 
> I havent checked wether automated testing caught this, but:
> 
> In function 'open',
>     inlined from 'libxl__domain_save_device_model' at libxl_dom.c:630:
> /usr/include/bits/fcntl2.h:51: error: call to '__open_missing_mode' declared with attribute error: open with O_CREAT in second argument needs 3 arguments
> make[3]: *** [libxl_dom.o] Error 1

Was a fix for this ever posted?

Ian.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 21 08:48:55 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 08:48:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdHqm-0003lz-MU; Wed, 21 Dec 2011 08:48:36 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RdHql-0003lR-M2
	for xen-devel@lists.xensource.com; Wed, 21 Dec 2011 08:48:35 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1324457309!6193253!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzUyMg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25650 invoked from network); 21 Dec 2011 08:48:29 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Dec 2011 08:48:29 -0000
X-IronPort-AV: E=Sophos;i="4.71,387,1320624000"; 
   d="scan'208";a="9598114"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Dec 2011 08:48:29 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 21 Dec 2011 08:48:29 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
In-Reply-To: <20111205181652.GA31962@aepfle.de>
References: <1322070039-439-1-git-send-email-anthony.perard@citrix.com>
	<1322070039-439-4-git-send-email-anthony.perard@citrix.com>
	<20111205181652.GA31962@aepfle.de>
Organization: Citrix Systems, Inc.
Date: Wed, 21 Dec 2011 08:48:28 +0000
Message-ID: <1324457308.8252.169.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
X-Mailer: Evolution 2.32.3 
Cc: Anthony Perard <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 3/3] libxl: Introduce migrate with the new
 QEMU.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2011-12-05 at 18:16 +0000, Olaf Hering wrote:
> On Wed, Nov 23, Anthony PERARD wrote:
> 
> > +    case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
> > +        fd2 = open(filename, O_WRONLY | O_CREAT | O_TRUNC);
> 
> I havent checked wether automated testing caught this, but:
> 
> In function 'open',
>     inlined from 'libxl__domain_save_device_model' at libxl_dom.c:630:
> /usr/include/bits/fcntl2.h:51: error: call to '__open_missing_mode' declared with attribute error: open with O_CREAT in second argument needs 3 arguments
> make[3]: *** [libxl_dom.o] Error 1

Was a fix for this ever posted?

Ian.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 21 09:05:11 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 09:05:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdI6S-0004Be-0x; Wed, 21 Dec 2011 09:04:48 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@gmail.com>) id 1RdI6Q-0004BW-GZ
	for xen-devel@lists.xensource.com; Wed, 21 Dec 2011 09:04:46 +0000
X-Env-Sender: anthony.perard@gmail.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1324458278!8932104!1
X-Originating-IP: [209.85.161.171]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22379 invoked from network); 21 Dec 2011 09:04:40 -0000
Received: from mail-gx0-f171.google.com (HELO mail-gx0-f171.google.com)
	(209.85.161.171)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Dec 2011 09:04:40 -0000
Received: by ggnh4 with SMTP id h4so61497798ggn.30
	for <xen-devel@lists.xensource.com>;
	Wed, 21 Dec 2011 01:04:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:from:date
	:x-google-sender-auth:message-id:subject:to:cc:content-type
	:content-transfer-encoding;
	bh=FpxdDqnJiFkmCpwJ9JDKeqoxzD4zMPGwJx49nBPimrw=;
	b=ElRYUz1dNDzubNonhw7MOrHvrsvlhBGarHvuQ/iMvfWo2qKw6Zd+78y7GNVTDSSaRE
	jie/XKqlhicliYO4meYW7NH58CiBfJfESMv0wrSqfWmltrS8Lov/G2rE1GWEwIEJhqTR
	88jifhNdw70Jp8kZjDq0XK3+OWTCCqJtHt+Ss=
Received: by 10.182.74.66 with SMTP id r2mr4929075obv.67.1324458278334; Wed,
	21 Dec 2011 01:04:38 -0800 (PST)
MIME-Version: 1.0
Received: by 10.182.36.230 with HTTP; Wed, 21 Dec 2011 01:04:08 -0800 (PST)
In-Reply-To: <1324457308.8252.169.camel@dagon.hellion.org.uk>
References: <1322070039-439-1-git-send-email-anthony.perard@citrix.com>
	<1322070039-439-4-git-send-email-anthony.perard@citrix.com>
	<20111205181652.GA31962@aepfle.de>
	<1324457308.8252.169.camel@dagon.hellion.org.uk>
From: Anthony PERARD <anthony.perard@citrix.com>
Date: Wed, 21 Dec 2011 10:04:08 +0100
X-Google-Sender-Auth: e6CXkmpSChtUzsjkWl3npXxKQkY
Message-ID: <CAJJyHjJ=DsMb+XsjjLCKXDEpV4-g8L_MmSStC5zTzoQz=RaDVQ@mail.gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Olaf Hering <olaf@aepfle.de>, Xen Devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 3/3] libxl: Introduce migrate with the new
	QEMU.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gV2VkLCBEZWMgMjEsIDIwMTEgYXQgMDk6NDgsIElhbiBDYW1wYmVsbCA8SWFuLkNhbXBiZWxs
QGNpdHJpeC5jb20+IHdyb3RlOgo+IE9uIE1vbiwgMjAxMS0xMi0wNSBhdCAxODoxNiArMDAwMCwg
T2xhZiBIZXJpbmcgd3JvdGU6Cj4+IE9uIFdlZCwgTm92IDIzLCBBbnRob255IFBFUkFSRCB3cm90
ZToKPj4KPj4gPiArIMKgIMKgY2FzZSBMSUJYTF9ERVZJQ0VfTU9ERUxfVkVSU0lPTl9RRU1VX1hF
TjoKPj4gPiArIMKgIMKgIMKgIMKgZmQyID0gb3BlbihmaWxlbmFtZSwgT19XUk9OTFkgfCBPX0NS
RUFUIHwgT19UUlVOQyk7Cj4+Cj4+IEkgaGF2ZW50IGNoZWNrZWQgd2V0aGVyIGF1dG9tYXRlZCB0
ZXN0aW5nIGNhdWdodCB0aGlzLCBidXQ6Cj4+Cj4+IEluIGZ1bmN0aW9uICdvcGVuJywKPj4gwqAg
wqAgaW5saW5lZCBmcm9tICdsaWJ4bF9fZG9tYWluX3NhdmVfZGV2aWNlX21vZGVsJyBhdCBsaWJ4
bF9kb20uYzo2MzA6Cj4+IC91c3IvaW5jbHVkZS9iaXRzL2ZjbnRsMi5oOjUxOiBlcnJvcjogY2Fs
bCB0byAnX19vcGVuX21pc3NpbmdfbW9kZScgZGVjbGFyZWQgd2l0aCBhdHRyaWJ1dGUgZXJyb3I6
IG9wZW4gd2l0aCBPX0NSRUFUIGluIHNlY29uZCBhcmd1bWVudCBuZWVkcyAzIGFyZ3VtZW50cwo+
PiBtYWtlWzNdOiAqKiogW2xpYnhsX2RvbS5vXSBFcnJvciAxCj4KPiBXYXMgYSBmaXggZm9yIHRo
aXMgZXZlciBwb3N0ZWQ/CgpJIGRvbid0IHRoaW5rIHNvLiBJIHdpbGwgZG8gb25lLgoKLS0gCkFu
dGhvbnkgUEVSQVJECgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29t
Cmh0dHA6Ly9saXN0cy54ZW5zb3VyY2UuY29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Wed Dec 21 09:05:11 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 09:05:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdI6S-0004Be-0x; Wed, 21 Dec 2011 09:04:48 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@gmail.com>) id 1RdI6Q-0004BW-GZ
	for xen-devel@lists.xensource.com; Wed, 21 Dec 2011 09:04:46 +0000
X-Env-Sender: anthony.perard@gmail.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1324458278!8932104!1
X-Originating-IP: [209.85.161.171]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22379 invoked from network); 21 Dec 2011 09:04:40 -0000
Received: from mail-gx0-f171.google.com (HELO mail-gx0-f171.google.com)
	(209.85.161.171)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Dec 2011 09:04:40 -0000
Received: by ggnh4 with SMTP id h4so61497798ggn.30
	for <xen-devel@lists.xensource.com>;
	Wed, 21 Dec 2011 01:04:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:from:date
	:x-google-sender-auth:message-id:subject:to:cc:content-type
	:content-transfer-encoding;
	bh=FpxdDqnJiFkmCpwJ9JDKeqoxzD4zMPGwJx49nBPimrw=;
	b=ElRYUz1dNDzubNonhw7MOrHvrsvlhBGarHvuQ/iMvfWo2qKw6Zd+78y7GNVTDSSaRE
	jie/XKqlhicliYO4meYW7NH58CiBfJfESMv0wrSqfWmltrS8Lov/G2rE1GWEwIEJhqTR
	88jifhNdw70Jp8kZjDq0XK3+OWTCCqJtHt+Ss=
Received: by 10.182.74.66 with SMTP id r2mr4929075obv.67.1324458278334; Wed,
	21 Dec 2011 01:04:38 -0800 (PST)
MIME-Version: 1.0
Received: by 10.182.36.230 with HTTP; Wed, 21 Dec 2011 01:04:08 -0800 (PST)
In-Reply-To: <1324457308.8252.169.camel@dagon.hellion.org.uk>
References: <1322070039-439-1-git-send-email-anthony.perard@citrix.com>
	<1322070039-439-4-git-send-email-anthony.perard@citrix.com>
	<20111205181652.GA31962@aepfle.de>
	<1324457308.8252.169.camel@dagon.hellion.org.uk>
From: Anthony PERARD <anthony.perard@citrix.com>
Date: Wed, 21 Dec 2011 10:04:08 +0100
X-Google-Sender-Auth: e6CXkmpSChtUzsjkWl3npXxKQkY
Message-ID: <CAJJyHjJ=DsMb+XsjjLCKXDEpV4-g8L_MmSStC5zTzoQz=RaDVQ@mail.gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Olaf Hering <olaf@aepfle.de>, Xen Devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 3/3] libxl: Introduce migrate with the new
	QEMU.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gV2VkLCBEZWMgMjEsIDIwMTEgYXQgMDk6NDgsIElhbiBDYW1wYmVsbCA8SWFuLkNhbXBiZWxs
QGNpdHJpeC5jb20+IHdyb3RlOgo+IE9uIE1vbiwgMjAxMS0xMi0wNSBhdCAxODoxNiArMDAwMCwg
T2xhZiBIZXJpbmcgd3JvdGU6Cj4+IE9uIFdlZCwgTm92IDIzLCBBbnRob255IFBFUkFSRCB3cm90
ZToKPj4KPj4gPiArIMKgIMKgY2FzZSBMSUJYTF9ERVZJQ0VfTU9ERUxfVkVSU0lPTl9RRU1VX1hF
TjoKPj4gPiArIMKgIMKgIMKgIMKgZmQyID0gb3BlbihmaWxlbmFtZSwgT19XUk9OTFkgfCBPX0NS
RUFUIHwgT19UUlVOQyk7Cj4+Cj4+IEkgaGF2ZW50IGNoZWNrZWQgd2V0aGVyIGF1dG9tYXRlZCB0
ZXN0aW5nIGNhdWdodCB0aGlzLCBidXQ6Cj4+Cj4+IEluIGZ1bmN0aW9uICdvcGVuJywKPj4gwqAg
wqAgaW5saW5lZCBmcm9tICdsaWJ4bF9fZG9tYWluX3NhdmVfZGV2aWNlX21vZGVsJyBhdCBsaWJ4
bF9kb20uYzo2MzA6Cj4+IC91c3IvaW5jbHVkZS9iaXRzL2ZjbnRsMi5oOjUxOiBlcnJvcjogY2Fs
bCB0byAnX19vcGVuX21pc3NpbmdfbW9kZScgZGVjbGFyZWQgd2l0aCBhdHRyaWJ1dGUgZXJyb3I6
IG9wZW4gd2l0aCBPX0NSRUFUIGluIHNlY29uZCBhcmd1bWVudCBuZWVkcyAzIGFyZ3VtZW50cwo+
PiBtYWtlWzNdOiAqKiogW2xpYnhsX2RvbS5vXSBFcnJvciAxCj4KPiBXYXMgYSBmaXggZm9yIHRo
aXMgZXZlciBwb3N0ZWQ/CgpJIGRvbid0IHRoaW5rIHNvLiBJIHdpbGwgZG8gb25lLgoKLS0gCkFu
dGhvbnkgUEVSQVJECgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29t
Cmh0dHA6Ly9saXN0cy54ZW5zb3VyY2UuY29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Wed Dec 21 09:22:33 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 09:22:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdIND-0004Py-1O; Wed, 21 Dec 2011 09:22:07 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <250716708@qq.com>) id 1RdINB-0004Pt-E2
	for xen-devel@lists.xensource.com; Wed, 21 Dec 2011 09:22:05 +0000
X-Env-Sender: 250716708@qq.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1324459108!8122664!1
X-Originating-IP: [64.71.138.43]
X-SpamReason: No, hits=2.9 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA2NC43MS4xMzguNDMgPT4gMjgzNzM5\n,sa_preprocessor: 
	QmFkIElQOiA2NC43MS4xMzguNDMgPT4gMjgzNzM5\n,FROM_ALL_NUMS,
	FROM_STARTS_WITH_NUMS,HTML_20_30,HTML_MESSAGE,MIME_BASE64_TEXT,
	MIME_BOUND_NEXTPART,received_headers: No Received headers
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20475 invoked from network); 21 Dec 2011 09:18:29 -0000
Received: from smtpbg52.qq.com (HELO smtpbg52.qq.com) (64.71.138.43)
	by server-16.tower-216.messagelabs.com with SMTP;
	21 Dec 2011 09:18:29 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qq.com; s=s0907;
	t=1324459098; bh=XUDscV5ugpBpMnOgReekOq8HMwsIWJtatWuG+NyYW54=;
	h=X-QQ-SSF:X-HAS-ATTACH:X-QQ-BUSINESS-ORIGIN:X-Originating-IP:
	X-QQ-STYLE:X-QQ-mid:From:To:Cc:Subject:Mime-Version:Content-Type:
	Content-Transfer-Encoding:Date:X-Priority:Message-ID:X-QQ-MIME:
	X-Mailer:X-QQ-Mailer;
	b=dEONS1n/FiMWGgXeoIclvD/dAhHBZSxoorQ24O5RCt+2WSLdYIeBFAq0+j9WPMbbh
	HcEd25OwAyZnFQ4G7xRRM602cY3Kh5is9GBaczRCkfdSbgyYUo0s7vZvYPlp1E9
X-QQ-SSF: 00000000000000F0000000000000000
X-HAS-ATTACH: no
X-QQ-BUSINESS-ORIGIN: 2
X-Originating-IP: 69.163.32.120
X-QQ-STYLE: 
X-QQ-mid: webmail106t1324459095t677594
From: "=?gbk?B?oei9S+y2YXdhcmU=?=" <250716708@qq.com>
To: "=?gbk?B?eGVuLWRldmVs?=" <xen-devel@lists.xensource.com>
Mime-Version: 1.0
Date: Wed, 21 Dec 2011 17:18:15 +0800
X-Priority: 3
Message-ID: <tencent_1B814ACE4F95C95F71ECDE34@qq.com>
X-QQ-MIME: TCMime 1.0 by Tencent
X-Mailer: QQMail 2.x
X-QQ-Mailer: QQMail 2.x
Cc: =?gbk?B?cWVtdS1kZXZlbA==?= <qemu-devel@nongnu.org>
Subject: [Xen-devel] the principle of the vm snapshot based on qemu-dm
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============7709181125591937405=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a multi-part message in MIME format.

--===============7709181125591937405==
Content-Type: multipart/alternative;
	boundary="----=_NextPart_4EF1A457_DCDC3328_35C42D97"
Content-Transfer-Encoding: 8Bit

This is a multi-part message in MIME format.

------=_NextPart_4EF1A457_DCDC3328_35C42D97
Content-Type: text/plain;
	charset="gbk"
Content-Transfer-Encoding: base64

SGkgZXZlcnlvbmUsDQogIA0KICANCiAgICAgSSdtIG5vdCBjbGVhciBhYm91dCB0aGUgcHJp
bmNpcGxlIG9mIHRoZSB2bSBzbmFwc2hvdCBiYXNlZCBvbiBxZW11LWRtLCBzbyB0aGUgZm9s
bG93aW5nIGJlbG93IG1heWJlIGEgam9rZS4gU29ycnkgZm9yIHRoYXQuLi4NCiAgICAgcmVn
aXN0ZXJfc2F2ZXZtKCkgaW5jbHVkZWQgaW4gaW9lbXUtcWVtdS14ZW4vaHcvKi5jIGNvdmVy
cyB2YXJpb3VzIGtpbmRzIG9mIGhhcmR3YXJlIGluIG9yZGVyIHRvIHNhdmUgdGhlIHN0YXRl
IG9mIGN1cnJlbnQgcnVubmluZyB2bS4gSW4gdGhpcyB3YXksICB0aGUgZmlsZSBzYXZlZCBi
eSB0aGUgY21kIG9mICd4bSBzYXZlIGRvbWFpbiBzbmFwc2hvdC5zYXZlJyBpcyBvZiBsYXJn
ZSBzaXplIGFuZCB0aGUgb3BlcmF0aW9uIGNvc3RzIG11Y2ggdGltZS4gSXMgdGhlcmUgYW55
ZWxzZSB3YXkgdG8gcXVjaWtseSBjcmVhdGUgYSBzbmFwc2hvdCwgc3VjaCBhcyBvbmx5IHNh
dmluZyB0aGUgbWVtb3J5IHN0YXRlKHNpbWlsYXJ5IHdpdGggSGliZXJuYXRpb24pIG9yIHNv
bWV0aGluZyBlbHNlPyENCiAgICAgSWYgc29tZW9uZSB3aG8gdW5kZXJzdGFuZHMgdGhlIHBy
aW5jaXBsZSBvciBoYXZlIHRoZSByZWxldmFudCBzdGF0aXN0aWNzLCB0aGFua3MgZm9yIHNo
YXJpbmcuDQogIA0KICANCiBjaGVlcnMNCiBicnVjZQ==

------=_NextPart_4EF1A457_DCDC3328_35C42D97
Content-Type: text/html;
	charset="gbk"
Content-Transfer-Encoding: base64

PERJVj5IaSBldmVyeW9uZSw8L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPiZuYnNw
OzwvRElWPg0KPERJVj4mbmJzcDsmbmJzcDsmbmJzcDsgSSdtIG5vdCBjbGVhciBhYm91dCB0
aGUgcHJpbmNpcGxlIG9mIHRoZSB2bSBzbmFwc2hvdCBiYXNlZCBvbiBxZW11LWRtLCBzbyB0
aGUgZm9sbG93aW5nIGJlbG93IG1heWJlIGEgam9rZS4gU29ycnkgZm9yIHRoYXQuLi48L0RJ
Vj4NCjxESVY+Jm5ic3A7Jm5ic3A7Jm5ic3A7IHJlZ2lzdGVyX3NhdmV2bSgpIGluY2x1ZGVk
IGluIGlvZW11LXFlbXUteGVuL2h3LyouYyBjb3ZlcnMgdmFyaW91cyBraW5kcyBvZiBoYXJk
d2FyZSBpbiBvcmRlciB0byBzYXZlIHRoZSBzdGF0ZSBvZiBjdXJyZW50IHJ1bm5pbmcgdm0u
IEluIHRoaXMgd2F5LCZuYnNwOyB0aGUgZmlsZSBzYXZlZCBieSB0aGUgY21kIG9mICd4bSBz
YXZlIGRvbWFpbiBzbmFwc2hvdC5zYXZlJyBpcyBvZiBsYXJnZSBzaXplIGFuZCB0aGUgb3Bl
cmF0aW9uIGNvc3RzIG11Y2ggdGltZS4gSXMgdGhlcmUgYW55ZWxzZSB3YXkgdG8gcXVjaWts
eSBjcmVhdGUgYSBzbmFwc2hvdCwgc3VjaCBhcyBvbmx5IHNhdmluZyB0aGUgbWVtb3J5IHN0
YXRlKHNpbWlsYXJ5IHdpdGggSGliZXJuYXRpb24pIG9yIHNvbWV0aGluZyBlbHNlPyE8L0RJ
Vj4NCjxESVY+Jm5ic3A7Jm5ic3A7Jm5ic3A7IElmIHNvbWVvbmUgd2hvIHVuZGVyc3RhbmRz
IHRoZSBwcmluY2lwbGUgb3IgaGF2ZSB0aGUgcmVsZXZhbnQgc3RhdGlzdGljcywgdGhhbmtz
IGZvciBzaGFyaW5nLjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+Jm5ic3A7PC9E
SVY+DQo8RElWPmNoZWVyczwvRElWPg0KPERJVj5icnVjZTwvRElWPg==

------=_NextPart_4EF1A457_DCDC3328_35C42D97--



--===============7709181125591937405==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============7709181125591937405==--



From xen-devel-bounces@lists.xensource.com Wed Dec 21 09:22:33 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 09:22:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdIND-0004Py-1O; Wed, 21 Dec 2011 09:22:07 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <250716708@qq.com>) id 1RdINB-0004Pt-E2
	for xen-devel@lists.xensource.com; Wed, 21 Dec 2011 09:22:05 +0000
X-Env-Sender: 250716708@qq.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1324459108!8122664!1
X-Originating-IP: [64.71.138.43]
X-SpamReason: No, hits=2.9 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA2NC43MS4xMzguNDMgPT4gMjgzNzM5\n,sa_preprocessor: 
	QmFkIElQOiA2NC43MS4xMzguNDMgPT4gMjgzNzM5\n,FROM_ALL_NUMS,
	FROM_STARTS_WITH_NUMS,HTML_20_30,HTML_MESSAGE,MIME_BASE64_TEXT,
	MIME_BOUND_NEXTPART,received_headers: No Received headers
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20475 invoked from network); 21 Dec 2011 09:18:29 -0000
Received: from smtpbg52.qq.com (HELO smtpbg52.qq.com) (64.71.138.43)
	by server-16.tower-216.messagelabs.com with SMTP;
	21 Dec 2011 09:18:29 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qq.com; s=s0907;
	t=1324459098; bh=XUDscV5ugpBpMnOgReekOq8HMwsIWJtatWuG+NyYW54=;
	h=X-QQ-SSF:X-HAS-ATTACH:X-QQ-BUSINESS-ORIGIN:X-Originating-IP:
	X-QQ-STYLE:X-QQ-mid:From:To:Cc:Subject:Mime-Version:Content-Type:
	Content-Transfer-Encoding:Date:X-Priority:Message-ID:X-QQ-MIME:
	X-Mailer:X-QQ-Mailer;
	b=dEONS1n/FiMWGgXeoIclvD/dAhHBZSxoorQ24O5RCt+2WSLdYIeBFAq0+j9WPMbbh
	HcEd25OwAyZnFQ4G7xRRM602cY3Kh5is9GBaczRCkfdSbgyYUo0s7vZvYPlp1E9
X-QQ-SSF: 00000000000000F0000000000000000
X-HAS-ATTACH: no
X-QQ-BUSINESS-ORIGIN: 2
X-Originating-IP: 69.163.32.120
X-QQ-STYLE: 
X-QQ-mid: webmail106t1324459095t677594
From: "=?gbk?B?oei9S+y2YXdhcmU=?=" <250716708@qq.com>
To: "=?gbk?B?eGVuLWRldmVs?=" <xen-devel@lists.xensource.com>
Mime-Version: 1.0
Date: Wed, 21 Dec 2011 17:18:15 +0800
X-Priority: 3
Message-ID: <tencent_1B814ACE4F95C95F71ECDE34@qq.com>
X-QQ-MIME: TCMime 1.0 by Tencent
X-Mailer: QQMail 2.x
X-QQ-Mailer: QQMail 2.x
Cc: =?gbk?B?cWVtdS1kZXZlbA==?= <qemu-devel@nongnu.org>
Subject: [Xen-devel] the principle of the vm snapshot based on qemu-dm
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============7709181125591937405=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a multi-part message in MIME format.

--===============7709181125591937405==
Content-Type: multipart/alternative;
	boundary="----=_NextPart_4EF1A457_DCDC3328_35C42D97"
Content-Transfer-Encoding: 8Bit

This is a multi-part message in MIME format.

------=_NextPart_4EF1A457_DCDC3328_35C42D97
Content-Type: text/plain;
	charset="gbk"
Content-Transfer-Encoding: base64

SGkgZXZlcnlvbmUsDQogIA0KICANCiAgICAgSSdtIG5vdCBjbGVhciBhYm91dCB0aGUgcHJp
bmNpcGxlIG9mIHRoZSB2bSBzbmFwc2hvdCBiYXNlZCBvbiBxZW11LWRtLCBzbyB0aGUgZm9s
bG93aW5nIGJlbG93IG1heWJlIGEgam9rZS4gU29ycnkgZm9yIHRoYXQuLi4NCiAgICAgcmVn
aXN0ZXJfc2F2ZXZtKCkgaW5jbHVkZWQgaW4gaW9lbXUtcWVtdS14ZW4vaHcvKi5jIGNvdmVy
cyB2YXJpb3VzIGtpbmRzIG9mIGhhcmR3YXJlIGluIG9yZGVyIHRvIHNhdmUgdGhlIHN0YXRl
IG9mIGN1cnJlbnQgcnVubmluZyB2bS4gSW4gdGhpcyB3YXksICB0aGUgZmlsZSBzYXZlZCBi
eSB0aGUgY21kIG9mICd4bSBzYXZlIGRvbWFpbiBzbmFwc2hvdC5zYXZlJyBpcyBvZiBsYXJn
ZSBzaXplIGFuZCB0aGUgb3BlcmF0aW9uIGNvc3RzIG11Y2ggdGltZS4gSXMgdGhlcmUgYW55
ZWxzZSB3YXkgdG8gcXVjaWtseSBjcmVhdGUgYSBzbmFwc2hvdCwgc3VjaCBhcyBvbmx5IHNh
dmluZyB0aGUgbWVtb3J5IHN0YXRlKHNpbWlsYXJ5IHdpdGggSGliZXJuYXRpb24pIG9yIHNv
bWV0aGluZyBlbHNlPyENCiAgICAgSWYgc29tZW9uZSB3aG8gdW5kZXJzdGFuZHMgdGhlIHBy
aW5jaXBsZSBvciBoYXZlIHRoZSByZWxldmFudCBzdGF0aXN0aWNzLCB0aGFua3MgZm9yIHNo
YXJpbmcuDQogIA0KICANCiBjaGVlcnMNCiBicnVjZQ==

------=_NextPart_4EF1A457_DCDC3328_35C42D97
Content-Type: text/html;
	charset="gbk"
Content-Transfer-Encoding: base64

PERJVj5IaSBldmVyeW9uZSw8L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPiZuYnNw
OzwvRElWPg0KPERJVj4mbmJzcDsmbmJzcDsmbmJzcDsgSSdtIG5vdCBjbGVhciBhYm91dCB0
aGUgcHJpbmNpcGxlIG9mIHRoZSB2bSBzbmFwc2hvdCBiYXNlZCBvbiBxZW11LWRtLCBzbyB0
aGUgZm9sbG93aW5nIGJlbG93IG1heWJlIGEgam9rZS4gU29ycnkgZm9yIHRoYXQuLi48L0RJ
Vj4NCjxESVY+Jm5ic3A7Jm5ic3A7Jm5ic3A7IHJlZ2lzdGVyX3NhdmV2bSgpIGluY2x1ZGVk
IGluIGlvZW11LXFlbXUteGVuL2h3LyouYyBjb3ZlcnMgdmFyaW91cyBraW5kcyBvZiBoYXJk
d2FyZSBpbiBvcmRlciB0byBzYXZlIHRoZSBzdGF0ZSBvZiBjdXJyZW50IHJ1bm5pbmcgdm0u
IEluIHRoaXMgd2F5LCZuYnNwOyB0aGUgZmlsZSBzYXZlZCBieSB0aGUgY21kIG9mICd4bSBz
YXZlIGRvbWFpbiBzbmFwc2hvdC5zYXZlJyBpcyBvZiBsYXJnZSBzaXplIGFuZCB0aGUgb3Bl
cmF0aW9uIGNvc3RzIG11Y2ggdGltZS4gSXMgdGhlcmUgYW55ZWxzZSB3YXkgdG8gcXVjaWts
eSBjcmVhdGUgYSBzbmFwc2hvdCwgc3VjaCBhcyBvbmx5IHNhdmluZyB0aGUgbWVtb3J5IHN0
YXRlKHNpbWlsYXJ5IHdpdGggSGliZXJuYXRpb24pIG9yIHNvbWV0aGluZyBlbHNlPyE8L0RJ
Vj4NCjxESVY+Jm5ic3A7Jm5ic3A7Jm5ic3A7IElmIHNvbWVvbmUgd2hvIHVuZGVyc3RhbmRz
IHRoZSBwcmluY2lwbGUgb3IgaGF2ZSB0aGUgcmVsZXZhbnQgc3RhdGlzdGljcywgdGhhbmtz
IGZvciBzaGFyaW5nLjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+Jm5ic3A7PC9E
SVY+DQo8RElWPmNoZWVyczwvRElWPg0KPERJVj5icnVjZTwvRElWPg==

------=_NextPart_4EF1A457_DCDC3328_35C42D97--



--===============7709181125591937405==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============7709181125591937405==--



From xen-devel-bounces@lists.xensource.com Wed Dec 21 09:41:40 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 09:41:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdIfa-0004dS-Rb; Wed, 21 Dec 2011 09:41:06 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RdIfZ-0004dN-2D
	for xen-devel@lists.xensource.com; Wed, 21 Dec 2011 09:41:05 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1324460457!6359671!1
X-Originating-IP: [209.85.160.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1252 invoked from network); 21 Dec 2011 09:40:58 -0000
Received: from mail-pw0-f43.google.com (HELO mail-pw0-f43.google.com)
	(209.85.160.43)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Dec 2011 09:40:58 -0000
Received: by pbbb11 with SMTP id b11so24243395pbb.30
	for <xen-devel@lists.xensource.com>;
	Wed, 21 Dec 2011 01:40:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=Zea/fky4o3dfKDN81GhnYrHUz3AydZL7ECXjN+n+B08=;
	b=lGessxOsoYCi8gpFYBBraVWs4Xd0p9SBMS9MVDfjZMfm/d421j51pz6Fhn0Ql8gcqD
	wVVx4EeWWf5KN44Gu1/9+MsNMqUkR02/RZURE0ogLphEv2u2abZz+whHAhYcXp6F7mfs
	pu3yCaErG4aS0zi2mrsMAETECtU5vTbHDUvvI=
MIME-Version: 1.0
Received: by 10.68.74.70 with SMTP id r6mr11130108pbv.78.1324460456525; Wed,
	21 Dec 2011 01:40:56 -0800 (PST)
Received: by 10.142.47.17 with HTTP; Wed, 21 Dec 2011 01:40:56 -0800 (PST)
In-Reply-To: <CAPLaKK5aNB70bXqL1-FxCpanMM92WnuVNbs6UV7gu7LA8L363g@mail.gmail.com>
References: <patchbomb.1324212500@alpine.localdomain>
	<eed78eb655c40b0ac9af.1324212501@alpine.localdomain>
	<1324288096.9236.6.camel@zakaz.uk.xensource.com>
	<CAPLaKK7gEUv9bavavzyYjREPDZJepMkK+-Ap78xzHjPy4SvZ3g@mail.gmail.com>
	<1324289291.9236.16.camel@zakaz.uk.xensource.com>
	<CAPLaKK6=O_h+OxOc_qDLUkw22hV2t6t9wfXOKVuoJf+Ny5+P9g@mail.gmail.com>
	<1324294068.9236.28.camel@zakaz.uk.xensource.com>
	<CAPLaKK771o2-_c=3huGH8ei3jAvL26en=Lu+QCuvdMFbZTi24Q@mail.gmail.com>
	<1324294692.9236.30.camel@zakaz.uk.xensource.com>
	<CAPLaKK6uCbRDGVXowjX30iCdTQuDZfwQ0U0i5apL7SHu7ye=ug@mail.gmail.com>
	<1324295392.9236.32.camel@zakaz.uk.xensource.com>
	<CAPLaKK5aNB70bXqL1-FxCpanMM92WnuVNbs6UV7gu7LA8L363g@mail.gmail.com>
Date: Wed, 21 Dec 2011 10:40:56 +0100
X-Google-Sender-Auth: 2iNBSXuwki6vw49feFscwn_4VRw
Message-ID: <CAPLaKK6teXhgEj2pAVObMx1-t80ZKwgoDmCsMonkPNBH_rsaow@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 1 of 5] blktap: remove HAVE_BYTESWAP_H
 checking, since it's defined by qemu
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

MjAxMS8xMi8xOSBSb2dlciBQYXUgTW9ubsOpIDxyb2dlci5wYXVAZW50ZWwudXBjLmVkdT46Cj4g
T2ssIEkndmUgaW5jbHVkZWQgZW5kaWFuLmggYW5kIGJ5dGVzd2FwLmgganVzdCBsaWtlIGxpYnZo
ZC5oIGRvZXMuCgpJIGRvbid0IHRoaW5rIGVuZGlhbi5oIGlzIG5lY2Vzc2FyeSBhdCBhbGwsIHNv
IEkndmUganVzdCBpbmNsdWRlZCBieXRlc3dhcC5oCgpfX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBs
aXN0cy54ZW5zb3VyY2UuY29tCmh0dHA6Ly9saXN0cy54ZW5zb3VyY2UuY29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Wed Dec 21 09:41:40 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 09:41:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdIfa-0004dS-Rb; Wed, 21 Dec 2011 09:41:06 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RdIfZ-0004dN-2D
	for xen-devel@lists.xensource.com; Wed, 21 Dec 2011 09:41:05 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1324460457!6359671!1
X-Originating-IP: [209.85.160.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1252 invoked from network); 21 Dec 2011 09:40:58 -0000
Received: from mail-pw0-f43.google.com (HELO mail-pw0-f43.google.com)
	(209.85.160.43)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Dec 2011 09:40:58 -0000
Received: by pbbb11 with SMTP id b11so24243395pbb.30
	for <xen-devel@lists.xensource.com>;
	Wed, 21 Dec 2011 01:40:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=Zea/fky4o3dfKDN81GhnYrHUz3AydZL7ECXjN+n+B08=;
	b=lGessxOsoYCi8gpFYBBraVWs4Xd0p9SBMS9MVDfjZMfm/d421j51pz6Fhn0Ql8gcqD
	wVVx4EeWWf5KN44Gu1/9+MsNMqUkR02/RZURE0ogLphEv2u2abZz+whHAhYcXp6F7mfs
	pu3yCaErG4aS0zi2mrsMAETECtU5vTbHDUvvI=
MIME-Version: 1.0
Received: by 10.68.74.70 with SMTP id r6mr11130108pbv.78.1324460456525; Wed,
	21 Dec 2011 01:40:56 -0800 (PST)
Received: by 10.142.47.17 with HTTP; Wed, 21 Dec 2011 01:40:56 -0800 (PST)
In-Reply-To: <CAPLaKK5aNB70bXqL1-FxCpanMM92WnuVNbs6UV7gu7LA8L363g@mail.gmail.com>
References: <patchbomb.1324212500@alpine.localdomain>
	<eed78eb655c40b0ac9af.1324212501@alpine.localdomain>
	<1324288096.9236.6.camel@zakaz.uk.xensource.com>
	<CAPLaKK7gEUv9bavavzyYjREPDZJepMkK+-Ap78xzHjPy4SvZ3g@mail.gmail.com>
	<1324289291.9236.16.camel@zakaz.uk.xensource.com>
	<CAPLaKK6=O_h+OxOc_qDLUkw22hV2t6t9wfXOKVuoJf+Ny5+P9g@mail.gmail.com>
	<1324294068.9236.28.camel@zakaz.uk.xensource.com>
	<CAPLaKK771o2-_c=3huGH8ei3jAvL26en=Lu+QCuvdMFbZTi24Q@mail.gmail.com>
	<1324294692.9236.30.camel@zakaz.uk.xensource.com>
	<CAPLaKK6uCbRDGVXowjX30iCdTQuDZfwQ0U0i5apL7SHu7ye=ug@mail.gmail.com>
	<1324295392.9236.32.camel@zakaz.uk.xensource.com>
	<CAPLaKK5aNB70bXqL1-FxCpanMM92WnuVNbs6UV7gu7LA8L363g@mail.gmail.com>
Date: Wed, 21 Dec 2011 10:40:56 +0100
X-Google-Sender-Auth: 2iNBSXuwki6vw49feFscwn_4VRw
Message-ID: <CAPLaKK6teXhgEj2pAVObMx1-t80ZKwgoDmCsMonkPNBH_rsaow@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 1 of 5] blktap: remove HAVE_BYTESWAP_H
 checking, since it's defined by qemu
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

MjAxMS8xMi8xOSBSb2dlciBQYXUgTW9ubsOpIDxyb2dlci5wYXVAZW50ZWwudXBjLmVkdT46Cj4g
T2ssIEkndmUgaW5jbHVkZWQgZW5kaWFuLmggYW5kIGJ5dGVzd2FwLmgganVzdCBsaWtlIGxpYnZo
ZC5oIGRvZXMuCgpJIGRvbid0IHRoaW5rIGVuZGlhbi5oIGlzIG5lY2Vzc2FyeSBhdCBhbGwsIHNv
IEkndmUganVzdCBpbmNsdWRlZCBieXRlc3dhcC5oCgpfX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBs
aXN0cy54ZW5zb3VyY2UuY29tCmh0dHA6Ly9saXN0cy54ZW5zb3VyY2UuY29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Wed Dec 21 10:01:57 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 10:01:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdIzG-0004te-OE; Wed, 21 Dec 2011 10:01:26 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RdIzE-0004tF-J0
	for xen-devel@lists.xensource.com; Wed, 21 Dec 2011 10:01:24 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1324461678!6192382!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzcyNA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21131 invoked from network); 21 Dec 2011 10:01:18 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Dec 2011 10:01:18 -0000
X-IronPort-AV: E=Sophos;i="4.71,387,1320624000"; d="scan'208,217";a="9601123"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Dec 2011 10:01:18 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 21 Dec 2011 10:01:18 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau =?ISO-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
Date: Wed, 21 Dec 2011 10:01:17 +0000
In-Reply-To: <CAPLaKK4TSzGoD2CGW1ubnqLcSfDCu5CFe6OAVFud446JyOcXtw@mail.gmail.com>
References: <patchbomb.1324212500@alpine.localdomain>
	<c0d5aa328f1ab24aad58.1324212503@alpine.localdomain>
	<CA+T2pCE_L0Gfyb0xu4=bd-yCAz=+Z_4Ugyd-EoO4m=+jz5MPGA@mail.gmail.com>
	<CAPLaKK5gYZ+KDsJW4+FSkP=nqDJmaO3W72pfkbg8m25fYu+_1Q@mail.gmail.com>
	<1324301203.9236.40.camel@zakaz.uk.xensource.com>
	<CAPLaKK6NhoXTiaFWb9aTcuapaqtNVcKo==7=xXP8wf5N66kFUw@mail.gmail.com>
	<1324302182.9236.51.camel@zakaz.uk.xensource.com>
	<CAPLaKK4xpN5Ro6medFjwBmg9zjs2pYHThmgP=NvdoJt+N=t1rA@mail.gmail.com>
	<CAPLaKK4TSzGoD2CGW1ubnqLcSfDCu5CFe6OAVFud446JyOcXtw@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1324461678.23729.84.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: William Pitcock <nenolod@dereferenced.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 3 of 5] blktap2: fix vhd compilation under
 uclibc
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gVHVlLCAyMDExLTEyLTIwIGF0IDE3OjU1ICswMDAwLCBSb2dlciBQYXUgTW9ubsOpIHdyb3Rl
Ogo+IEhlbGxvLAo+IAo+IEkndmUgYWRkZWQgLWxpY29udiB0byBibGt0YXAyL3ZoZC9saWIsIGFu
ZCBzdWNjZXNmdWxseSBjb21waWxlZCBhbmQKPiBsaW5rZWQgdGhlIGxpYnJhcnkuIFRoZSBvdXRw
dXQgZnJvbSBsZGQgbGlidmhkLnNvIHNob3dzOgo+IAo+IGNoZWNraW5nIHN1Yi1kZXBlbmRzIGZv
ciAnL2xpYi9saWJ1dWlkLnNvLjEnCj4gY2hlY2tpbmcgc3ViLWRlcGVuZHMgZm9yICcvdXNyL2xp
Yi9saWJpY29udi5zby4yJwo+IGNoZWNraW5nIHN1Yi1kZXBlbmRzIGZvciAnL2xpYi9saWJjLnNv
LjAuOS4zMicKPiBjaGVja2luZyBzdWItZGVwZW5kcyBmb3IgJy9saWIvbGQ2NC11Q2xpYmMuc28u
MC45LjMyJwo+IAlsaWJ1dWlkLnNvLjEgPT4gL2xpYi9saWJ1dWlkLnNvLjEgKDB4MDAwMDAwMDAp
Cj4gCWxpYmljb252LnNvLjIgPT4gL3Vzci9saWIvbGliaWNvbnYuc28uMiAoMHgwMDAwMDAwMCkK
PiAJbGliYy5zby4wLjkuMzIgPT4gL2xpYi9saWJjLnNvLjAuOS4zMiAoMHgwMDAwMDAwMCkKPiAJ
bGQ2NC11Q2xpYmMuc28uMC45LjMyID0+IC9saWIvbGQ2NC11Q2xpYmMuc28uMC45LjMyICgweDAw
MDAwMDAwKQo+IAlub3QgYSBkeW5hbWljIGV4ZWN1dGFibGUKPiAKPiBUaGVuIEkndmUgY29tcGls
ZWQgYW5kIGxpbmtlZCB2aGQgdG9vbHMgKHZoZC11dGlsIGFuZCB2aGQtdXBkYXRlKQo+IHdpdGhv
dXQgLWxpY29udiwgc2luY2UgdmhkIHRvb2xzIGRvZXNuJ3QgdXNlIGFueSBpY29udiBmdW5jdGlv
bnMuIFRoZXkKPiBjb21waWxlIGZpbmUsIGJ1dCB3aGVuIEkgdHJ5IHRvIGV4ZWN1dGUgdGhlbSBJ
IGdldCB0aGUgZm9sbG93aW5nCj4gZXJyb3I6Cj4gCj4gdmhkLXV0aWw6IHN5bWJvbCAnbGliaWNv
bnZfb3Blbic6IGNhbid0IHJlc29sdmUgc3ltYm9sCj4gCj4gSWYgSSBkbyBhIGxkZCBvZiB2aGQt
dXRpbDoKPiAKPiAJbGlidmhkLnNvLjEuMCA9PiAvdXNyL2xpYi9saWJ2aGQuc28uMS4wICgweDc2
OTllZmFmNDAwMCkKPiAJbGliYy5zby4wLjkuMzIgPT4gL2xpYi9saWJjLnNvLjAuOS4zMiAoMHg3
Njk5ZWY4OGMwMDApCj4gCWxpYnV1aWQuc28uMSA9PiAvbGliL2xpYnV1aWQuc28uMSAoMHg3Njk5
ZWY2ODkwMDApCj4gCWxkNjQtdUNsaWJjLnNvLjAuOS4zMiA9PiAvbGliL2xkNjQtdUNsaWJjLnNv
LjAuOS4zMiAoMHg3Njk5ZWZkMTAwMDApCj4gCj4gSG93IGNvbWUgbGliaWNvbnYgaXMgbm90IGxp
bmtlZCB0byB0aGUgYXBwbGljYXRpb24gaWYgbGlidmhkIGlzPwoKQ2FuIHlvdSBwb3N0IHRoZSBj
b21wbGV0ZSBsaW5rIGxpbmUgZm9yIGVhY2ggc3RhZ2U/CgpBcmUgeW91IHN1cmUgdGhhdCAvdXNy
L2xpYi9saWJ2aGQuc28uMS4wIGlzIHRoZSBzYW1lIG9uZSB5b3UganVzdCBidWlsdAphbmQgbGlu
a2VkIGFnYWluc3Q/IElzIHRoZXJlIGEgY2hhbmNlIHlvdSBoYXZlIGxpbmtlZCBhZ2FpbnN0IHNv
bWV0aGluZwppbiB0aGUgYnVpbGQgZGlyZWN0b3J5IHdoaWNoIGRpZCBub3QgZ2V0IHByb3Blcmx5
IGluc3RhbGxlZD8KClJ1bm5pbmcKCW9iamR1bXAgLXAgPG9iamVjdD4gfCBlZ3JlcCBORUVERURc
fFNPTkFNRQpmb3IgdGhlIGxpYnJhcnkgKGJvdGggYnVpbGQgZGlyIGFuZCBpbnN0YWxsZWQgY29w
aWVzKSBhbmQgYmluYXJ5IHdvdWxkCmJlIGludGVyZXN0aW5nLgoKSXQgc2VlbXMgbGlrZSBlaXRo
ZXIgdGhpcyBpcyBhIGJ1ZyBpbiB1Q2xpYmMncyBkeW5hbWljIGxpbmtlciBvciBteQpleHBlY3Rh
dGlvbiBvZiBob3cgdGhlc2Ugc29ydHMgb2YgdHJhbnNpdGl2ZSBsaWJyYXJ5IGRlcGVuZGVuY2ll
cyB3b3JrCmhhcyBiZWVuIHNldCB0b28gaGlnaCBieSBnbGliYy4uLgoKPiAgQW5kCj4gd2hhdCdz
IG1vc3Qgc3RyYW5nZSwgd2h5IGlzIHRoZSBsaW5rIHRvIGxpYnV1aWQga2VlcCwgYnV0IG5vdCB0
aGUgb25lCj4gdG8gbGliaWNvbnY/CgpZZXMsIHRoYXQgaXMgc3RyYW5nZS4KCklhbi4KCgpfX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFp
bGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tCmh0dHA6Ly9saXN0cy54ZW5z
b3VyY2UuY29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Wed Dec 21 10:01:57 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 10:01:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdIzG-0004te-OE; Wed, 21 Dec 2011 10:01:26 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RdIzE-0004tF-J0
	for xen-devel@lists.xensource.com; Wed, 21 Dec 2011 10:01:24 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1324461678!6192382!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzcyNA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21131 invoked from network); 21 Dec 2011 10:01:18 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Dec 2011 10:01:18 -0000
X-IronPort-AV: E=Sophos;i="4.71,387,1320624000"; d="scan'208,217";a="9601123"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Dec 2011 10:01:18 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 21 Dec 2011 10:01:18 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau =?ISO-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
Date: Wed, 21 Dec 2011 10:01:17 +0000
In-Reply-To: <CAPLaKK4TSzGoD2CGW1ubnqLcSfDCu5CFe6OAVFud446JyOcXtw@mail.gmail.com>
References: <patchbomb.1324212500@alpine.localdomain>
	<c0d5aa328f1ab24aad58.1324212503@alpine.localdomain>
	<CA+T2pCE_L0Gfyb0xu4=bd-yCAz=+Z_4Ugyd-EoO4m=+jz5MPGA@mail.gmail.com>
	<CAPLaKK5gYZ+KDsJW4+FSkP=nqDJmaO3W72pfkbg8m25fYu+_1Q@mail.gmail.com>
	<1324301203.9236.40.camel@zakaz.uk.xensource.com>
	<CAPLaKK6NhoXTiaFWb9aTcuapaqtNVcKo==7=xXP8wf5N66kFUw@mail.gmail.com>
	<1324302182.9236.51.camel@zakaz.uk.xensource.com>
	<CAPLaKK4xpN5Ro6medFjwBmg9zjs2pYHThmgP=NvdoJt+N=t1rA@mail.gmail.com>
	<CAPLaKK4TSzGoD2CGW1ubnqLcSfDCu5CFe6OAVFud446JyOcXtw@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1324461678.23729.84.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: William Pitcock <nenolod@dereferenced.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 3 of 5] blktap2: fix vhd compilation under
 uclibc
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gVHVlLCAyMDExLTEyLTIwIGF0IDE3OjU1ICswMDAwLCBSb2dlciBQYXUgTW9ubsOpIHdyb3Rl
Ogo+IEhlbGxvLAo+IAo+IEkndmUgYWRkZWQgLWxpY29udiB0byBibGt0YXAyL3ZoZC9saWIsIGFu
ZCBzdWNjZXNmdWxseSBjb21waWxlZCBhbmQKPiBsaW5rZWQgdGhlIGxpYnJhcnkuIFRoZSBvdXRw
dXQgZnJvbSBsZGQgbGlidmhkLnNvIHNob3dzOgo+IAo+IGNoZWNraW5nIHN1Yi1kZXBlbmRzIGZv
ciAnL2xpYi9saWJ1dWlkLnNvLjEnCj4gY2hlY2tpbmcgc3ViLWRlcGVuZHMgZm9yICcvdXNyL2xp
Yi9saWJpY29udi5zby4yJwo+IGNoZWNraW5nIHN1Yi1kZXBlbmRzIGZvciAnL2xpYi9saWJjLnNv
LjAuOS4zMicKPiBjaGVja2luZyBzdWItZGVwZW5kcyBmb3IgJy9saWIvbGQ2NC11Q2xpYmMuc28u
MC45LjMyJwo+IAlsaWJ1dWlkLnNvLjEgPT4gL2xpYi9saWJ1dWlkLnNvLjEgKDB4MDAwMDAwMDAp
Cj4gCWxpYmljb252LnNvLjIgPT4gL3Vzci9saWIvbGliaWNvbnYuc28uMiAoMHgwMDAwMDAwMCkK
PiAJbGliYy5zby4wLjkuMzIgPT4gL2xpYi9saWJjLnNvLjAuOS4zMiAoMHgwMDAwMDAwMCkKPiAJ
bGQ2NC11Q2xpYmMuc28uMC45LjMyID0+IC9saWIvbGQ2NC11Q2xpYmMuc28uMC45LjMyICgweDAw
MDAwMDAwKQo+IAlub3QgYSBkeW5hbWljIGV4ZWN1dGFibGUKPiAKPiBUaGVuIEkndmUgY29tcGls
ZWQgYW5kIGxpbmtlZCB2aGQgdG9vbHMgKHZoZC11dGlsIGFuZCB2aGQtdXBkYXRlKQo+IHdpdGhv
dXQgLWxpY29udiwgc2luY2UgdmhkIHRvb2xzIGRvZXNuJ3QgdXNlIGFueSBpY29udiBmdW5jdGlv
bnMuIFRoZXkKPiBjb21waWxlIGZpbmUsIGJ1dCB3aGVuIEkgdHJ5IHRvIGV4ZWN1dGUgdGhlbSBJ
IGdldCB0aGUgZm9sbG93aW5nCj4gZXJyb3I6Cj4gCj4gdmhkLXV0aWw6IHN5bWJvbCAnbGliaWNv
bnZfb3Blbic6IGNhbid0IHJlc29sdmUgc3ltYm9sCj4gCj4gSWYgSSBkbyBhIGxkZCBvZiB2aGQt
dXRpbDoKPiAKPiAJbGlidmhkLnNvLjEuMCA9PiAvdXNyL2xpYi9saWJ2aGQuc28uMS4wICgweDc2
OTllZmFmNDAwMCkKPiAJbGliYy5zby4wLjkuMzIgPT4gL2xpYi9saWJjLnNvLjAuOS4zMiAoMHg3
Njk5ZWY4OGMwMDApCj4gCWxpYnV1aWQuc28uMSA9PiAvbGliL2xpYnV1aWQuc28uMSAoMHg3Njk5
ZWY2ODkwMDApCj4gCWxkNjQtdUNsaWJjLnNvLjAuOS4zMiA9PiAvbGliL2xkNjQtdUNsaWJjLnNv
LjAuOS4zMiAoMHg3Njk5ZWZkMTAwMDApCj4gCj4gSG93IGNvbWUgbGliaWNvbnYgaXMgbm90IGxp
bmtlZCB0byB0aGUgYXBwbGljYXRpb24gaWYgbGlidmhkIGlzPwoKQ2FuIHlvdSBwb3N0IHRoZSBj
b21wbGV0ZSBsaW5rIGxpbmUgZm9yIGVhY2ggc3RhZ2U/CgpBcmUgeW91IHN1cmUgdGhhdCAvdXNy
L2xpYi9saWJ2aGQuc28uMS4wIGlzIHRoZSBzYW1lIG9uZSB5b3UganVzdCBidWlsdAphbmQgbGlu
a2VkIGFnYWluc3Q/IElzIHRoZXJlIGEgY2hhbmNlIHlvdSBoYXZlIGxpbmtlZCBhZ2FpbnN0IHNv
bWV0aGluZwppbiB0aGUgYnVpbGQgZGlyZWN0b3J5IHdoaWNoIGRpZCBub3QgZ2V0IHByb3Blcmx5
IGluc3RhbGxlZD8KClJ1bm5pbmcKCW9iamR1bXAgLXAgPG9iamVjdD4gfCBlZ3JlcCBORUVERURc
fFNPTkFNRQpmb3IgdGhlIGxpYnJhcnkgKGJvdGggYnVpbGQgZGlyIGFuZCBpbnN0YWxsZWQgY29w
aWVzKSBhbmQgYmluYXJ5IHdvdWxkCmJlIGludGVyZXN0aW5nLgoKSXQgc2VlbXMgbGlrZSBlaXRo
ZXIgdGhpcyBpcyBhIGJ1ZyBpbiB1Q2xpYmMncyBkeW5hbWljIGxpbmtlciBvciBteQpleHBlY3Rh
dGlvbiBvZiBob3cgdGhlc2Ugc29ydHMgb2YgdHJhbnNpdGl2ZSBsaWJyYXJ5IGRlcGVuZGVuY2ll
cyB3b3JrCmhhcyBiZWVuIHNldCB0b28gaGlnaCBieSBnbGliYy4uLgoKPiAgQW5kCj4gd2hhdCdz
IG1vc3Qgc3RyYW5nZSwgd2h5IGlzIHRoZSBsaW5rIHRvIGxpYnV1aWQga2VlcCwgYnV0IG5vdCB0
aGUgb25lCj4gdG8gbGliaWNvbnY/CgpZZXMsIHRoYXQgaXMgc3RyYW5nZS4KCklhbi4KCgpfX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFp
bGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tCmh0dHA6Ly9saXN0cy54ZW5z
b3VyY2UuY29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Wed Dec 21 10:15:42 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 10:15:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdJCa-00055s-9C; Wed, 21 Dec 2011 10:15:12 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RdJCZ-00055n-Hx
	for xen-devel@lists.xensource.com; Wed, 21 Dec 2011 10:15:11 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1324462477!45724760!1
X-Originating-IP: [209.85.160.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28072 invoked from network); 21 Dec 2011 10:14:39 -0000
Received: from mail-pw0-f43.google.com (HELO mail-pw0-f43.google.com)
	(209.85.160.43)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Dec 2011 10:14:39 -0000
Received: by pbbb11 with SMTP id b11so24308728pbb.30
	for <xen-devel@lists.xensource.com>;
	Wed, 21 Dec 2011 02:15:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=kZDm+UFsop2Cdeoev6X2Wt6d5KncUT43VIqNzg5p1Ls=;
	b=O+mBEDEJkaVBujeWE3umapKKQYAXgRrRw30PQVW69qPeyT2iE5wflzDjvk2TsXQ4RN
	wjRR+3+9lZO1y8izwxocqlUltz6HTS7OiIsX3tN49YzFbDM9gHbI6YdTdSsfXkgyf/5n
	wEP2GO92VN7rqWstWgLAUqcXYd39bJqrGOfXA=
MIME-Version: 1.0
Received: by 10.68.74.70 with SMTP id r6mr11406040pbv.78.1324462508158; Wed,
	21 Dec 2011 02:15:08 -0800 (PST)
Received: by 10.142.47.17 with HTTP; Wed, 21 Dec 2011 02:15:07 -0800 (PST)
In-Reply-To: <1324461678.23729.84.camel@zakaz.uk.xensource.com>
References: <patchbomb.1324212500@alpine.localdomain>
	<c0d5aa328f1ab24aad58.1324212503@alpine.localdomain>
	<CA+T2pCE_L0Gfyb0xu4=bd-yCAz=+Z_4Ugyd-EoO4m=+jz5MPGA@mail.gmail.com>
	<CAPLaKK5gYZ+KDsJW4+FSkP=nqDJmaO3W72pfkbg8m25fYu+_1Q@mail.gmail.com>
	<1324301203.9236.40.camel@zakaz.uk.xensource.com>
	<CAPLaKK6NhoXTiaFWb9aTcuapaqtNVcKo==7=xXP8wf5N66kFUw@mail.gmail.com>
	<1324302182.9236.51.camel@zakaz.uk.xensource.com>
	<CAPLaKK4xpN5Ro6medFjwBmg9zjs2pYHThmgP=NvdoJt+N=t1rA@mail.gmail.com>
	<CAPLaKK4TSzGoD2CGW1ubnqLcSfDCu5CFe6OAVFud446JyOcXtw@mail.gmail.com>
	<1324461678.23729.84.camel@zakaz.uk.xensource.com>
Date: Wed, 21 Dec 2011 11:15:07 +0100
X-Google-Sender-Auth: NTW-yT6uvqJvO5oyh7i3-3t34Po
Message-ID: <CAPLaKK6OrZfcktRmUvV_0-8vd7hS=YKA-FwivX928ecefot9Zg@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: William Pitcock <nenolod@dereferenced.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 3 of 5] blktap2: fix vhd compilation under
	uclibc
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

MjAxMS8xMi8yMSBJYW4gQ2FtcGJlbGwgPElhbi5DYW1wYmVsbEBjaXRyaXguY29tPjoKPiBPbiBU
dWUsIDIwMTEtMTItMjAgYXQgMTc6NTUgKzAwMDAsIFJvZ2VyIFBhdSBNb25uw6kgd3JvdGU6Cj4+
IEhlbGxvLAo+Pgo+PiBJJ3ZlIGFkZGVkIC1saWNvbnYgdG8gYmxrdGFwMi92aGQvbGliLCBhbmQg
c3VjY2VzZnVsbHkgY29tcGlsZWQgYW5kCj4+IGxpbmtlZCB0aGUgbGlicmFyeS4gVGhlIG91dHB1
dCBmcm9tIGxkZCBsaWJ2aGQuc28gc2hvd3M6Cj4+Cj4+IGNoZWNraW5nIHN1Yi1kZXBlbmRzIGZv
ciAnL2xpYi9saWJ1dWlkLnNvLjEnCj4+IGNoZWNraW5nIHN1Yi1kZXBlbmRzIGZvciAnL3Vzci9s
aWIvbGliaWNvbnYuc28uMicKPj4gY2hlY2tpbmcgc3ViLWRlcGVuZHMgZm9yICcvbGliL2xpYmMu
c28uMC45LjMyJwo+PiBjaGVja2luZyBzdWItZGVwZW5kcyBmb3IgJy9saWIvbGQ2NC11Q2xpYmMu
c28uMC45LjMyJwo+PiDCoCDCoCDCoCBsaWJ1dWlkLnNvLjEgPT4gL2xpYi9saWJ1dWlkLnNvLjEg
KDB4MDAwMDAwMDApCj4+IMKgIMKgIMKgIGxpYmljb252LnNvLjIgPT4gL3Vzci9saWIvbGliaWNv
bnYuc28uMiAoMHgwMDAwMDAwMCkKPj4gwqAgwqAgwqAgbGliYy5zby4wLjkuMzIgPT4gL2xpYi9s
aWJjLnNvLjAuOS4zMiAoMHgwMDAwMDAwMCkKPj4gwqAgwqAgwqAgbGQ2NC11Q2xpYmMuc28uMC45
LjMyID0+IC9saWIvbGQ2NC11Q2xpYmMuc28uMC45LjMyICgweDAwMDAwMDAwKQo+PiDCoCDCoCDC
oCBub3QgYSBkeW5hbWljIGV4ZWN1dGFibGUKPj4KPj4gVGhlbiBJJ3ZlIGNvbXBpbGVkIGFuZCBs
aW5rZWQgdmhkIHRvb2xzICh2aGQtdXRpbCBhbmQgdmhkLXVwZGF0ZSkKPj4gd2l0aG91dCAtbGlj
b252LCBzaW5jZSB2aGQgdG9vbHMgZG9lc24ndCB1c2UgYW55IGljb252IGZ1bmN0aW9ucy4gVGhl
eQo+PiBjb21waWxlIGZpbmUsIGJ1dCB3aGVuIEkgdHJ5IHRvIGV4ZWN1dGUgdGhlbSBJIGdldCB0
aGUgZm9sbG93aW5nCj4+IGVycm9yOgo+Pgo+PiB2aGQtdXRpbDogc3ltYm9sICdsaWJpY29udl9v
cGVuJzogY2FuJ3QgcmVzb2x2ZSBzeW1ib2wKPj4KPj4gSWYgSSBkbyBhIGxkZCBvZiB2aGQtdXRp
bDoKPj4KPj4gwqAgwqAgwqAgbGlidmhkLnNvLjEuMCA9PiAvdXNyL2xpYi9saWJ2aGQuc28uMS4w
ICgweDc2OTllZmFmNDAwMCkKPj4gwqAgwqAgwqAgbGliYy5zby4wLjkuMzIgPT4gL2xpYi9saWJj
LnNvLjAuOS4zMiAoMHg3Njk5ZWY4OGMwMDApCj4+IMKgIMKgIMKgIGxpYnV1aWQuc28uMSA9PiAv
bGliL2xpYnV1aWQuc28uMSAoMHg3Njk5ZWY2ODkwMDApCj4+IMKgIMKgIMKgIGxkNjQtdUNsaWJj
LnNvLjAuOS4zMiA9PiAvbGliL2xkNjQtdUNsaWJjLnNvLjAuOS4zMiAoMHg3Njk5ZWZkMTAwMDAp
Cj4+Cj4+IEhvdyBjb21lIGxpYmljb252IGlzIG5vdCBsaW5rZWQgdG8gdGhlIGFwcGxpY2F0aW9u
IGlmIGxpYnZoZCBpcz8KPgo+IENhbiB5b3UgcG9zdCB0aGUgY29tcGxldGUgbGluayBsaW5lIGZv
ciBlYWNoIHN0YWdlPwo+Cj4gQXJlIHlvdSBzdXJlIHRoYXQgL3Vzci9saWIvbGlidmhkLnNvLjEu
MCBpcyB0aGUgc2FtZSBvbmUgeW91IGp1c3QgYnVpbHQKPiBhbmQgbGlua2VkIGFnYWluc3Q/IElz
IHRoZXJlIGEgY2hhbmNlIHlvdSBoYXZlIGxpbmtlZCBhZ2FpbnN0IHNvbWV0aGluZwo+IGluIHRo
ZSBidWlsZCBkaXJlY3Rvcnkgd2hpY2ggZGlkIG5vdCBnZXQgcHJvcGVybHkgaW5zdGFsbGVkPwoK
U29ycnksIEknbSBqdXN0IHN0dXBpZCwgdG9kYXkgSSd2ZSByZWFsaXplZCB3aGF0IHRoZSBwcm9i
bGVtIHdhcy4gSXQKd2FzIGxpbmtlZCBhZ2FpbnN0IGFuZCBvbGQgL3Vzci9saWIvbGlidmhkLnNv
IHdoaWNoIHdhcyBub3QgY29tcGlsZWQKd2l0aCAtbGljb252LgoKPiBSdW5uaW5nCj4gwqAgwqAg
wqAgwqBvYmpkdW1wIC1wIDxvYmplY3Q+IHwgZWdyZXAgTkVFREVEXHxTT05BTUUKPiBmb3IgdGhl
IGxpYnJhcnkgKGJvdGggYnVpbGQgZGlyIGFuZCBpbnN0YWxsZWQgY29waWVzKSBhbmQgYmluYXJ5
IHdvdWxkCj4gYmUgaW50ZXJlc3RpbmcuCj4KPiBJdCBzZWVtcyBsaWtlIGVpdGhlciB0aGlzIGlz
IGEgYnVnIGluIHVDbGliYydzIGR5bmFtaWMgbGlua2VyIG9yIG15Cj4gZXhwZWN0YXRpb24gb2Yg
aG93IHRoZXNlIHNvcnRzIG9mIHRyYW5zaXRpdmUgbGlicmFyeSBkZXBlbmRlbmNpZXMgd29yawo+
IGhhcyBiZWVuIHNldCB0b28gaGlnaCBieSBnbGliYy4uLgo+Cj4+IMKgQW5kCj4+IHdoYXQncyBt
b3N0IHN0cmFuZ2UsIHdoeSBpcyB0aGUgbGluayB0byBsaWJ1dWlkIGtlZXAsIGJ1dCBub3QgdGhl
IG9uZQo+PiB0byBsaWJpY29udj8KPgo+IFllcywgdGhhdCBpcyBzdHJhbmdlLgoKSSBzdGlsbCBk
b24ndCBnZXQgdGhlIGxpYnV1aWQgdGhpbmcsIGJ1dCBpdCB3b3JrcyBqdXN0IGZpbmUgbm93LgoK
PiBJYW4uCj4KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
Clhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbnNvdXJjZS5jb20KaHR0
cDovL2xpc3RzLnhlbnNvdXJjZS5jb20veGVuLWRldmVsCg==

From xen-devel-bounces@lists.xensource.com Wed Dec 21 10:15:42 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 10:15:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdJCa-00055s-9C; Wed, 21 Dec 2011 10:15:12 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RdJCZ-00055n-Hx
	for xen-devel@lists.xensource.com; Wed, 21 Dec 2011 10:15:11 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1324462477!45724760!1
X-Originating-IP: [209.85.160.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28072 invoked from network); 21 Dec 2011 10:14:39 -0000
Received: from mail-pw0-f43.google.com (HELO mail-pw0-f43.google.com)
	(209.85.160.43)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Dec 2011 10:14:39 -0000
Received: by pbbb11 with SMTP id b11so24308728pbb.30
	for <xen-devel@lists.xensource.com>;
	Wed, 21 Dec 2011 02:15:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=kZDm+UFsop2Cdeoev6X2Wt6d5KncUT43VIqNzg5p1Ls=;
	b=O+mBEDEJkaVBujeWE3umapKKQYAXgRrRw30PQVW69qPeyT2iE5wflzDjvk2TsXQ4RN
	wjRR+3+9lZO1y8izwxocqlUltz6HTS7OiIsX3tN49YzFbDM9gHbI6YdTdSsfXkgyf/5n
	wEP2GO92VN7rqWstWgLAUqcXYd39bJqrGOfXA=
MIME-Version: 1.0
Received: by 10.68.74.70 with SMTP id r6mr11406040pbv.78.1324462508158; Wed,
	21 Dec 2011 02:15:08 -0800 (PST)
Received: by 10.142.47.17 with HTTP; Wed, 21 Dec 2011 02:15:07 -0800 (PST)
In-Reply-To: <1324461678.23729.84.camel@zakaz.uk.xensource.com>
References: <patchbomb.1324212500@alpine.localdomain>
	<c0d5aa328f1ab24aad58.1324212503@alpine.localdomain>
	<CA+T2pCE_L0Gfyb0xu4=bd-yCAz=+Z_4Ugyd-EoO4m=+jz5MPGA@mail.gmail.com>
	<CAPLaKK5gYZ+KDsJW4+FSkP=nqDJmaO3W72pfkbg8m25fYu+_1Q@mail.gmail.com>
	<1324301203.9236.40.camel@zakaz.uk.xensource.com>
	<CAPLaKK6NhoXTiaFWb9aTcuapaqtNVcKo==7=xXP8wf5N66kFUw@mail.gmail.com>
	<1324302182.9236.51.camel@zakaz.uk.xensource.com>
	<CAPLaKK4xpN5Ro6medFjwBmg9zjs2pYHThmgP=NvdoJt+N=t1rA@mail.gmail.com>
	<CAPLaKK4TSzGoD2CGW1ubnqLcSfDCu5CFe6OAVFud446JyOcXtw@mail.gmail.com>
	<1324461678.23729.84.camel@zakaz.uk.xensource.com>
Date: Wed, 21 Dec 2011 11:15:07 +0100
X-Google-Sender-Auth: NTW-yT6uvqJvO5oyh7i3-3t34Po
Message-ID: <CAPLaKK6OrZfcktRmUvV_0-8vd7hS=YKA-FwivX928ecefot9Zg@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: William Pitcock <nenolod@dereferenced.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 3 of 5] blktap2: fix vhd compilation under
	uclibc
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

MjAxMS8xMi8yMSBJYW4gQ2FtcGJlbGwgPElhbi5DYW1wYmVsbEBjaXRyaXguY29tPjoKPiBPbiBU
dWUsIDIwMTEtMTItMjAgYXQgMTc6NTUgKzAwMDAsIFJvZ2VyIFBhdSBNb25uw6kgd3JvdGU6Cj4+
IEhlbGxvLAo+Pgo+PiBJJ3ZlIGFkZGVkIC1saWNvbnYgdG8gYmxrdGFwMi92aGQvbGliLCBhbmQg
c3VjY2VzZnVsbHkgY29tcGlsZWQgYW5kCj4+IGxpbmtlZCB0aGUgbGlicmFyeS4gVGhlIG91dHB1
dCBmcm9tIGxkZCBsaWJ2aGQuc28gc2hvd3M6Cj4+Cj4+IGNoZWNraW5nIHN1Yi1kZXBlbmRzIGZv
ciAnL2xpYi9saWJ1dWlkLnNvLjEnCj4+IGNoZWNraW5nIHN1Yi1kZXBlbmRzIGZvciAnL3Vzci9s
aWIvbGliaWNvbnYuc28uMicKPj4gY2hlY2tpbmcgc3ViLWRlcGVuZHMgZm9yICcvbGliL2xpYmMu
c28uMC45LjMyJwo+PiBjaGVja2luZyBzdWItZGVwZW5kcyBmb3IgJy9saWIvbGQ2NC11Q2xpYmMu
c28uMC45LjMyJwo+PiDCoCDCoCDCoCBsaWJ1dWlkLnNvLjEgPT4gL2xpYi9saWJ1dWlkLnNvLjEg
KDB4MDAwMDAwMDApCj4+IMKgIMKgIMKgIGxpYmljb252LnNvLjIgPT4gL3Vzci9saWIvbGliaWNv
bnYuc28uMiAoMHgwMDAwMDAwMCkKPj4gwqAgwqAgwqAgbGliYy5zby4wLjkuMzIgPT4gL2xpYi9s
aWJjLnNvLjAuOS4zMiAoMHgwMDAwMDAwMCkKPj4gwqAgwqAgwqAgbGQ2NC11Q2xpYmMuc28uMC45
LjMyID0+IC9saWIvbGQ2NC11Q2xpYmMuc28uMC45LjMyICgweDAwMDAwMDAwKQo+PiDCoCDCoCDC
oCBub3QgYSBkeW5hbWljIGV4ZWN1dGFibGUKPj4KPj4gVGhlbiBJJ3ZlIGNvbXBpbGVkIGFuZCBs
aW5rZWQgdmhkIHRvb2xzICh2aGQtdXRpbCBhbmQgdmhkLXVwZGF0ZSkKPj4gd2l0aG91dCAtbGlj
b252LCBzaW5jZSB2aGQgdG9vbHMgZG9lc24ndCB1c2UgYW55IGljb252IGZ1bmN0aW9ucy4gVGhl
eQo+PiBjb21waWxlIGZpbmUsIGJ1dCB3aGVuIEkgdHJ5IHRvIGV4ZWN1dGUgdGhlbSBJIGdldCB0
aGUgZm9sbG93aW5nCj4+IGVycm9yOgo+Pgo+PiB2aGQtdXRpbDogc3ltYm9sICdsaWJpY29udl9v
cGVuJzogY2FuJ3QgcmVzb2x2ZSBzeW1ib2wKPj4KPj4gSWYgSSBkbyBhIGxkZCBvZiB2aGQtdXRp
bDoKPj4KPj4gwqAgwqAgwqAgbGlidmhkLnNvLjEuMCA9PiAvdXNyL2xpYi9saWJ2aGQuc28uMS4w
ICgweDc2OTllZmFmNDAwMCkKPj4gwqAgwqAgwqAgbGliYy5zby4wLjkuMzIgPT4gL2xpYi9saWJj
LnNvLjAuOS4zMiAoMHg3Njk5ZWY4OGMwMDApCj4+IMKgIMKgIMKgIGxpYnV1aWQuc28uMSA9PiAv
bGliL2xpYnV1aWQuc28uMSAoMHg3Njk5ZWY2ODkwMDApCj4+IMKgIMKgIMKgIGxkNjQtdUNsaWJj
LnNvLjAuOS4zMiA9PiAvbGliL2xkNjQtdUNsaWJjLnNvLjAuOS4zMiAoMHg3Njk5ZWZkMTAwMDAp
Cj4+Cj4+IEhvdyBjb21lIGxpYmljb252IGlzIG5vdCBsaW5rZWQgdG8gdGhlIGFwcGxpY2F0aW9u
IGlmIGxpYnZoZCBpcz8KPgo+IENhbiB5b3UgcG9zdCB0aGUgY29tcGxldGUgbGluayBsaW5lIGZv
ciBlYWNoIHN0YWdlPwo+Cj4gQXJlIHlvdSBzdXJlIHRoYXQgL3Vzci9saWIvbGlidmhkLnNvLjEu
MCBpcyB0aGUgc2FtZSBvbmUgeW91IGp1c3QgYnVpbHQKPiBhbmQgbGlua2VkIGFnYWluc3Q/IElz
IHRoZXJlIGEgY2hhbmNlIHlvdSBoYXZlIGxpbmtlZCBhZ2FpbnN0IHNvbWV0aGluZwo+IGluIHRo
ZSBidWlsZCBkaXJlY3Rvcnkgd2hpY2ggZGlkIG5vdCBnZXQgcHJvcGVybHkgaW5zdGFsbGVkPwoK
U29ycnksIEknbSBqdXN0IHN0dXBpZCwgdG9kYXkgSSd2ZSByZWFsaXplZCB3aGF0IHRoZSBwcm9i
bGVtIHdhcy4gSXQKd2FzIGxpbmtlZCBhZ2FpbnN0IGFuZCBvbGQgL3Vzci9saWIvbGlidmhkLnNv
IHdoaWNoIHdhcyBub3QgY29tcGlsZWQKd2l0aCAtbGljb252LgoKPiBSdW5uaW5nCj4gwqAgwqAg
wqAgwqBvYmpkdW1wIC1wIDxvYmplY3Q+IHwgZWdyZXAgTkVFREVEXHxTT05BTUUKPiBmb3IgdGhl
IGxpYnJhcnkgKGJvdGggYnVpbGQgZGlyIGFuZCBpbnN0YWxsZWQgY29waWVzKSBhbmQgYmluYXJ5
IHdvdWxkCj4gYmUgaW50ZXJlc3RpbmcuCj4KPiBJdCBzZWVtcyBsaWtlIGVpdGhlciB0aGlzIGlz
IGEgYnVnIGluIHVDbGliYydzIGR5bmFtaWMgbGlua2VyIG9yIG15Cj4gZXhwZWN0YXRpb24gb2Yg
aG93IHRoZXNlIHNvcnRzIG9mIHRyYW5zaXRpdmUgbGlicmFyeSBkZXBlbmRlbmNpZXMgd29yawo+
IGhhcyBiZWVuIHNldCB0b28gaGlnaCBieSBnbGliYy4uLgo+Cj4+IMKgQW5kCj4+IHdoYXQncyBt
b3N0IHN0cmFuZ2UsIHdoeSBpcyB0aGUgbGluayB0byBsaWJ1dWlkIGtlZXAsIGJ1dCBub3QgdGhl
IG9uZQo+PiB0byBsaWJpY29udj8KPgo+IFllcywgdGhhdCBpcyBzdHJhbmdlLgoKSSBzdGlsbCBk
b24ndCBnZXQgdGhlIGxpYnV1aWQgdGhpbmcsIGJ1dCBpdCB3b3JrcyBqdXN0IGZpbmUgbm93LgoK
PiBJYW4uCj4KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
Clhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbnNvdXJjZS5jb20KaHR0
cDovL2xpc3RzLnhlbnNvdXJjZS5jb20veGVuLWRldmVsCg==

From xen-devel-bounces@lists.xensource.com Wed Dec 21 10:21:23 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 10:21:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdJID-0005HN-2u; Wed, 21 Dec 2011 10:21:01 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1RdJIB-0005HG-UB
	for xen-devel@lists.xensource.com; Wed, 21 Dec 2011 10:21:00 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1324462852!6389926!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTAxMDQ=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8725 invoked from network); 21 Dec 2011 10:20:53 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Dec 2011 10:20:53 -0000
X-IronPort-AV: E=Sophos;i="4.71,387,1320642000"; d="scan'208";a="20178490"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Dec 2011 05:20:51 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Wed, 21 Dec 2011 05:20:51 -0500
Received: from perard.uk.xensource.com (dhcp-3-28.uk.xensource.com
	[10.80.3.28] (may be forged))	by smtp01.ad.xensource.com
	(8.13.1/8.13.1) with
	ESMTP id pBLAKn4Q031779;	Wed, 21 Dec 2011 02:20:49 -0800
From: Anthony PERARD <anthony.perard@citrix.com>
To: Xen Devel <xen-devel@lists.xensource.com>
Date: Wed, 21 Dec 2011 10:20:36 +0000
Message-ID: <1324462836-7059-1-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>, Olaf Hering <olaf@aepfle.de>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH] libxl: Fix,
	specify open mode to QEMU state file.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Reported-by: Olaf Hering <olaf@aepfle.de>
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>

---
 tools/libxl/libxl_dom.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 7683601..70ddae2 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -624,7 +624,7 @@ int libxl__domain_save_device_model(libxl__gc *gc, uint32_t domid, int fd)
         break;
     }
     case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
-        fd2 = open(filename, O_WRONLY | O_CREAT | O_TRUNC);
+        fd2 = open(filename, O_WRONLY | O_CREAT | O_TRUNC, S_IRUSR | S_IWUSR);
         if (fd2 < 0) {
             LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
                              "Unable to create a QEMU save file\n");
-- 
tg: (49ec8ad..) fix/xl-save-open-mode-for-open-migrate (depends on: master)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 21 10:21:23 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 10:21:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdJID-0005HN-2u; Wed, 21 Dec 2011 10:21:01 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1RdJIB-0005HG-UB
	for xen-devel@lists.xensource.com; Wed, 21 Dec 2011 10:21:00 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1324462852!6389926!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTAxMDQ=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8725 invoked from network); 21 Dec 2011 10:20:53 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Dec 2011 10:20:53 -0000
X-IronPort-AV: E=Sophos;i="4.71,387,1320642000"; d="scan'208";a="20178490"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Dec 2011 05:20:51 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Wed, 21 Dec 2011 05:20:51 -0500
Received: from perard.uk.xensource.com (dhcp-3-28.uk.xensource.com
	[10.80.3.28] (may be forged))	by smtp01.ad.xensource.com
	(8.13.1/8.13.1) with
	ESMTP id pBLAKn4Q031779;	Wed, 21 Dec 2011 02:20:49 -0800
From: Anthony PERARD <anthony.perard@citrix.com>
To: Xen Devel <xen-devel@lists.xensource.com>
Date: Wed, 21 Dec 2011 10:20:36 +0000
Message-ID: <1324462836-7059-1-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>, Olaf Hering <olaf@aepfle.de>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH] libxl: Fix,
	specify open mode to QEMU state file.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Reported-by: Olaf Hering <olaf@aepfle.de>
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>

---
 tools/libxl/libxl_dom.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 7683601..70ddae2 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -624,7 +624,7 @@ int libxl__domain_save_device_model(libxl__gc *gc, uint32_t domid, int fd)
         break;
     }
     case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
-        fd2 = open(filename, O_WRONLY | O_CREAT | O_TRUNC);
+        fd2 = open(filename, O_WRONLY | O_CREAT | O_TRUNC, S_IRUSR | S_IWUSR);
         if (fd2 < 0) {
             LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
                              "Unable to create a QEMU save file\n");
-- 
tg: (49ec8ad..) fix/xl-save-open-mode-for-open-migrate (depends on: master)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 21 10:22:37 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 10:22:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdJJQ-0005LD-I5; Wed, 21 Dec 2011 10:22:16 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RdJJO-0005Ks-Hv
	for xen-devel@lists.xensource.com; Wed, 21 Dec 2011 10:22:14 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1324462928!8894964!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzcyNA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22365 invoked from network); 21 Dec 2011 10:22:08 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Dec 2011 10:22:08 -0000
X-IronPort-AV: E=Sophos;i="4.71,387,1320624000"; 
   d="scan'208";a="9602000"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Dec 2011 10:22:08 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 21 Dec 2011 10:22:08 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
Date: Wed, 21 Dec 2011 10:22:08 +0000
In-Reply-To: <20111220200341.GA31859@andromeda.dapyr.net>
References: <CAOMqctShNFqe47w1orEPMCqvDORy5yxh=Gy33e02fyQYrz4nkw@mail.gmail.com>
	<20111219142943.GD27772@andromeda.dapyr.net>
	<CAOMqctSW87AmM8UTC34_ZwDhipnZUMmxyxiBix+EMAmi7hn1hg@mail.gmail.com>
	<20111219194324.GA29852@andromeda.dapyr.net>
	<1324373842.23729.16.camel@zakaz.uk.xensource.com>
	<CAEBdQ92Oy6=EYYFG_KNMP6raq7S1e_195hFth1etMgpQWdGtsg@mail.gmail.com>
	<1324374914.23729.22.camel@zakaz.uk.xensource.com>
	<CAOMqctTOC_te2QRqFUC45+cq1qCBcQyMdvQcu4Brpw-kAiYnBg@mail.gmail.com>
	<20111220153501.GC13253@andromeda.dapyr.net>
	<1324397974.23729.45.camel@zakaz.uk.xensource.com>
	<20111220200341.GA31859@andromeda.dapyr.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1324462928.23729.90.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Michal Suchanek <hramrach@centrum.cz>,
	"stefan.bader@canonical.com" <stefan.bader@canonical.com>,
	Jean Guyader <jean.guyader@gmail.com>
Subject: Re: [Xen-devel] UDP checksums broken in Dom0 -> DomU vif transfer
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2011-12-20 at 20:03 +0000, Konrad Rzeszutek Wilk wrote:
> > > > Thanks for the links
> > > > 
> > > > I am running Ubuntu in the DomU.
> > > 
> > > Stefan, is this something you could help us with?
> > > 
> > > Ian, would it make sense to add all this awesome details in the Xen FAQ
> > > Wiki part?
> > 
> > Yes, please!
> 
> I was hoping you would do it :-)

Guess what I was hoping ;-)

I've added it to http://wiki.xen.org/wiki/Xen_FAQ_DomU . There are loads
of ".*FAQ.*" pages so I've no idea if this is the best place for it.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 21 10:22:37 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 10:22:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdJJQ-0005LD-I5; Wed, 21 Dec 2011 10:22:16 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RdJJO-0005Ks-Hv
	for xen-devel@lists.xensource.com; Wed, 21 Dec 2011 10:22:14 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1324462928!8894964!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzcyNA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22365 invoked from network); 21 Dec 2011 10:22:08 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Dec 2011 10:22:08 -0000
X-IronPort-AV: E=Sophos;i="4.71,387,1320624000"; 
   d="scan'208";a="9602000"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Dec 2011 10:22:08 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 21 Dec 2011 10:22:08 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
Date: Wed, 21 Dec 2011 10:22:08 +0000
In-Reply-To: <20111220200341.GA31859@andromeda.dapyr.net>
References: <CAOMqctShNFqe47w1orEPMCqvDORy5yxh=Gy33e02fyQYrz4nkw@mail.gmail.com>
	<20111219142943.GD27772@andromeda.dapyr.net>
	<CAOMqctSW87AmM8UTC34_ZwDhipnZUMmxyxiBix+EMAmi7hn1hg@mail.gmail.com>
	<20111219194324.GA29852@andromeda.dapyr.net>
	<1324373842.23729.16.camel@zakaz.uk.xensource.com>
	<CAEBdQ92Oy6=EYYFG_KNMP6raq7S1e_195hFth1etMgpQWdGtsg@mail.gmail.com>
	<1324374914.23729.22.camel@zakaz.uk.xensource.com>
	<CAOMqctTOC_te2QRqFUC45+cq1qCBcQyMdvQcu4Brpw-kAiYnBg@mail.gmail.com>
	<20111220153501.GC13253@andromeda.dapyr.net>
	<1324397974.23729.45.camel@zakaz.uk.xensource.com>
	<20111220200341.GA31859@andromeda.dapyr.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1324462928.23729.90.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Michal Suchanek <hramrach@centrum.cz>,
	"stefan.bader@canonical.com" <stefan.bader@canonical.com>,
	Jean Guyader <jean.guyader@gmail.com>
Subject: Re: [Xen-devel] UDP checksums broken in Dom0 -> DomU vif transfer
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2011-12-20 at 20:03 +0000, Konrad Rzeszutek Wilk wrote:
> > > > Thanks for the links
> > > > 
> > > > I am running Ubuntu in the DomU.
> > > 
> > > Stefan, is this something you could help us with?
> > > 
> > > Ian, would it make sense to add all this awesome details in the Xen FAQ
> > > Wiki part?
> > 
> > Yes, please!
> 
> I was hoping you would do it :-)

Guess what I was hoping ;-)

I've added it to http://wiki.xen.org/wiki/Xen_FAQ_DomU . There are loads
of ".*FAQ.*" pages so I've no idea if this is the best place for it.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 21 10:25:36 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 10:25:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdJMN-0005Zm-93; Wed, 21 Dec 2011 10:25:19 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RdJMM-0005Ym-Cf
	for xen-devel@lists.xensource.com; Wed, 21 Dec 2011 10:25:18 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1324463106!8261911!3
X-Originating-IP: [209.85.220.171]
X-SpamReason: No, hits=1.1 required=7.0 tests=DATE_IN_PAST_24_48, RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4917 invoked from network); 21 Dec 2011 10:25:11 -0000
Received: from mail-vx0-f171.google.com (HELO mail-vx0-f171.google.com)
	(209.85.220.171)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Dec 2011 10:25:11 -0000
Received: by mail-vx0-f171.google.com with SMTP id fl11so21603790vcb.30
	for <xen-devel@lists.xensource.com>;
	Wed, 21 Dec 2011 02:25:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to:cc; bh=hREDR0n+xuqdQtb8sszt4eXyInCNpiNIdjgNsLQjqps=;
	b=aIS6fQY9lm1LZ69hxhpSKvKorTM1n+xUnmCdIoykh246zgQ+RrrWCLi95Fr09HGoM+
	MYcMne5RkhLtEPIv3El35NK1VP56vzumk75Evl5AWfll3na5h6nJ+oDkFjDczWKmjQ8I
	AL2pyfO7HCh0Hke8+xVhY35uoX6CldfLCmWzQ=
Received: by 10.221.13.196 with SMTP id pn4mr4145516vcb.74.1324463111236;
	Wed, 21 Dec 2011 02:25:11 -0800 (PST)
Received: from alpine.localdomain (tina.upc.es. [147.83.39.243])
	by mx.google.com with ESMTPS id s10sm3850965vdj.1.2011.12.21.02.25.08
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 21 Dec 2011 02:25:09 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 23e1abbd203ca2619103f3e95c6b1ff36be60e38
Message-Id: <23e1abbd203ca2619103.1324347546@alpine.localdomain>
In-Reply-To: <patchbomb.1324347544@alpine.localdomain>
References: <patchbomb.1324347544@alpine.localdomain>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Tue, 20 Dec 2011 03:19:06 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Cc: nenolod@dereferenced.org
Subject: [Xen-devel] [PATCH 2 of 4 v2] blktap2: remove local definitions and
 include byteswap.h
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1324344514 -3600
# Node ID 23e1abbd203ca2619103f3e95c6b1ff36be60e38
# Parent  29f5b0afe971335eea4f547efed00b132ade5c64
blktap2: remove local definitions and include byteswap.h

Use the same approach as tools/blktap2/include/libvhd.h, remove local
definitions of bswap* and include byteswap.h. Also remove the
HAVE_BYTESWAP_H ifdef, since it was not defined in this context (it's
defined by QEMU).

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 29f5b0afe971 -r 23e1abbd203c tools/blktap2/drivers/bswap.h
--- a/tools/blktap2/drivers/bswap.h	Tue Dec 20 02:27:13 2011 +0100
+++ b/tools/blktap2/drivers/bswap.h	Tue Dec 20 02:28:34 2011 +0100
@@ -15,43 +15,8 @@
 #define bswap_64(x) swap64(x)
 #else
 
-#ifdef HAVE_BYTESWAP_H
+#include <endian.h>
 #include <byteswap.h>
-#else
-
-#define bswap_16(x) \
-({ \
-	uint16_t __x = (x); \
-	((uint16_t)( \
-		(((uint16_t)(__x) & (uint16_t)0x00ffU) << 8) | \
-		(((uint16_t)(__x) & (uint16_t)0xff00U) >> 8) )); \
-})
-
-#define bswap_32(x) \
-({ \
-	uint32_t __x = (x); \
-	((uint32_t)( \
-		(((uint32_t)(__x) & (uint32_t)0x000000ffUL) << 24) | \
-		(((uint32_t)(__x) & (uint32_t)0x0000ff00UL) <<  8) | \
-		(((uint32_t)(__x) & (uint32_t)0x00ff0000UL) >>  8) | \
-		(((uint32_t)(__x) & (uint32_t)0xff000000UL) >> 24) )); \
-})
-
-#define bswap_64(x) \
-({ \
-	uint64_t __x = (x); \
-	((uint64_t)( \
-		(uint64_t)(((uint64_t)(__x) & (uint64_t)0x00000000000000ffULL) << 56) | \
-		(uint64_t)(((uint64_t)(__x) & (uint64_t)0x000000000000ff00ULL) << 40) | \
-		(uint64_t)(((uint64_t)(__x) & (uint64_t)0x0000000000ff0000ULL) << 24) | \
-		(uint64_t)(((uint64_t)(__x) & (uint64_t)0x00000000ff000000ULL) <<  8) | \
-	        (uint64_t)(((uint64_t)(__x) & (uint64_t)0x000000ff00000000ULL) >>  8) | \
-		(uint64_t)(((uint64_t)(__x) & (uint64_t)0x0000ff0000000000ULL) >> 24) | \
-		(uint64_t)(((uint64_t)(__x) & (uint64_t)0x00ff000000000000ULL) >> 40) | \
-		(uint64_t)(((uint64_t)(__x) & (uint64_t)0xff00000000000000ULL) >> 56) )); \
-})
-
-#endif /* !HAVE_BYTESWAP_H */
 
 static inline uint16_t bswap16(uint16_t x)
 {

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 21 10:25:36 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 10:25:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdJMN-0005Zm-93; Wed, 21 Dec 2011 10:25:19 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RdJMM-0005Ym-Cf
	for xen-devel@lists.xensource.com; Wed, 21 Dec 2011 10:25:18 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1324463106!8261911!3
X-Originating-IP: [209.85.220.171]
X-SpamReason: No, hits=1.1 required=7.0 tests=DATE_IN_PAST_24_48, RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4917 invoked from network); 21 Dec 2011 10:25:11 -0000
Received: from mail-vx0-f171.google.com (HELO mail-vx0-f171.google.com)
	(209.85.220.171)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Dec 2011 10:25:11 -0000
Received: by mail-vx0-f171.google.com with SMTP id fl11so21603790vcb.30
	for <xen-devel@lists.xensource.com>;
	Wed, 21 Dec 2011 02:25:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to:cc; bh=hREDR0n+xuqdQtb8sszt4eXyInCNpiNIdjgNsLQjqps=;
	b=aIS6fQY9lm1LZ69hxhpSKvKorTM1n+xUnmCdIoykh246zgQ+RrrWCLi95Fr09HGoM+
	MYcMne5RkhLtEPIv3El35NK1VP56vzumk75Evl5AWfll3na5h6nJ+oDkFjDczWKmjQ8I
	AL2pyfO7HCh0Hke8+xVhY35uoX6CldfLCmWzQ=
Received: by 10.221.13.196 with SMTP id pn4mr4145516vcb.74.1324463111236;
	Wed, 21 Dec 2011 02:25:11 -0800 (PST)
Received: from alpine.localdomain (tina.upc.es. [147.83.39.243])
	by mx.google.com with ESMTPS id s10sm3850965vdj.1.2011.12.21.02.25.08
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 21 Dec 2011 02:25:09 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 23e1abbd203ca2619103f3e95c6b1ff36be60e38
Message-Id: <23e1abbd203ca2619103.1324347546@alpine.localdomain>
In-Reply-To: <patchbomb.1324347544@alpine.localdomain>
References: <patchbomb.1324347544@alpine.localdomain>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Tue, 20 Dec 2011 03:19:06 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Cc: nenolod@dereferenced.org
Subject: [Xen-devel] [PATCH 2 of 4 v2] blktap2: remove local definitions and
 include byteswap.h
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1324344514 -3600
# Node ID 23e1abbd203ca2619103f3e95c6b1ff36be60e38
# Parent  29f5b0afe971335eea4f547efed00b132ade5c64
blktap2: remove local definitions and include byteswap.h

Use the same approach as tools/blktap2/include/libvhd.h, remove local
definitions of bswap* and include byteswap.h. Also remove the
HAVE_BYTESWAP_H ifdef, since it was not defined in this context (it's
defined by QEMU).

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 29f5b0afe971 -r 23e1abbd203c tools/blktap2/drivers/bswap.h
--- a/tools/blktap2/drivers/bswap.h	Tue Dec 20 02:27:13 2011 +0100
+++ b/tools/blktap2/drivers/bswap.h	Tue Dec 20 02:28:34 2011 +0100
@@ -15,43 +15,8 @@
 #define bswap_64(x) swap64(x)
 #else
 
-#ifdef HAVE_BYTESWAP_H
+#include <endian.h>
 #include <byteswap.h>
-#else
-
-#define bswap_16(x) \
-({ \
-	uint16_t __x = (x); \
-	((uint16_t)( \
-		(((uint16_t)(__x) & (uint16_t)0x00ffU) << 8) | \
-		(((uint16_t)(__x) & (uint16_t)0xff00U) >> 8) )); \
-})
-
-#define bswap_32(x) \
-({ \
-	uint32_t __x = (x); \
-	((uint32_t)( \
-		(((uint32_t)(__x) & (uint32_t)0x000000ffUL) << 24) | \
-		(((uint32_t)(__x) & (uint32_t)0x0000ff00UL) <<  8) | \
-		(((uint32_t)(__x) & (uint32_t)0x00ff0000UL) >>  8) | \
-		(((uint32_t)(__x) & (uint32_t)0xff000000UL) >> 24) )); \
-})
-
-#define bswap_64(x) \
-({ \
-	uint64_t __x = (x); \
-	((uint64_t)( \
-		(uint64_t)(((uint64_t)(__x) & (uint64_t)0x00000000000000ffULL) << 56) | \
-		(uint64_t)(((uint64_t)(__x) & (uint64_t)0x000000000000ff00ULL) << 40) | \
-		(uint64_t)(((uint64_t)(__x) & (uint64_t)0x0000000000ff0000ULL) << 24) | \
-		(uint64_t)(((uint64_t)(__x) & (uint64_t)0x00000000ff000000ULL) <<  8) | \
-	        (uint64_t)(((uint64_t)(__x) & (uint64_t)0x000000ff00000000ULL) >>  8) | \
-		(uint64_t)(((uint64_t)(__x) & (uint64_t)0x0000ff0000000000ULL) >> 24) | \
-		(uint64_t)(((uint64_t)(__x) & (uint64_t)0x00ff000000000000ULL) >> 40) | \
-		(uint64_t)(((uint64_t)(__x) & (uint64_t)0xff00000000000000ULL) >> 56) )); \
-})
-
-#endif /* !HAVE_BYTESWAP_H */
 
 static inline uint16_t bswap16(uint16_t x)
 {

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 21 10:25:36 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 10:25:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdJMJ-0005ZG-EJ; Wed, 21 Dec 2011 10:25:15 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RdJMI-0005Ya-GL
	for xen-devel@lists.xensource.com; Wed, 21 Dec 2011 10:25:14 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1324463106!8261911!1
X-Originating-IP: [209.85.220.171]
X-SpamReason: No, hits=1.1 required=7.0 tests=DATE_IN_PAST_24_48, RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4668 invoked from network); 21 Dec 2011 10:25:08 -0000
Received: from mail-vx0-f171.google.com (HELO mail-vx0-f171.google.com)
	(209.85.220.171)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Dec 2011 10:25:08 -0000
Received: by vcbfl11 with SMTP id fl11so21603790vcb.30
	for <xen-devel@lists.xensource.com>;
	Wed, 21 Dec 2011 02:25:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:message-id:user-agent:date:from:to:cc;
	bh=hgp4B48FO6LurjUFjJIYFu+Xsz+QyV2/0z3pBY5u2gQ=;
	b=DNgw2Ktm4N8gIugOCCbKvakELc4QCpx8hEmFLQKrAHpNFzTYGb03lnGq4z9j3OUWn9
	tSG+lrm1JCxn8JoTSHmUk2L2Luchc43jKtlL3BKviYXN84xiC1i42/RYUU8m0ZrqgMei
	4qSor2IIVutbIuTi7DW6RoDzwe8fhMqVUMOZk=
Received: by 10.220.155.1 with SMTP id q1mr3905275vcw.34.1324463106432;
	Wed, 21 Dec 2011 02:25:06 -0800 (PST)
Received: from alpine.localdomain (tina.upc.es. [147.83.39.243])
	by mx.google.com with ESMTPS id s10sm3850965vdj.1.2011.12.21.02.25.04
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 21 Dec 2011 02:25:05 -0800 (PST)
MIME-Version: 1.0
Message-Id: <patchbomb.1324347544@alpine.localdomain>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Tue, 20 Dec 2011 03:19:04 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Cc: nenolod@dereferenced.org
Subject: [Xen-devel] [PATCH 0 of 4 v2] build: various fixes for building
 with uclibc and libiconv
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This patch contains various fixes to the build system to allow
building xen under uclibc with libiconv. Has been tested with uclibc
0.9.32, gcc 4.6.2 and libiconv 1.12, from Alpine Linux 2.3.2.

Since the series is completely different from the previous one, I
don't think it's worth to add a "Changes since v1" section, becasue
everything is different.

Please review, Roger.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 21 10:25:36 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 10:25:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdJMJ-0005ZG-EJ; Wed, 21 Dec 2011 10:25:15 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RdJMI-0005Ya-GL
	for xen-devel@lists.xensource.com; Wed, 21 Dec 2011 10:25:14 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1324463106!8261911!1
X-Originating-IP: [209.85.220.171]
X-SpamReason: No, hits=1.1 required=7.0 tests=DATE_IN_PAST_24_48, RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4668 invoked from network); 21 Dec 2011 10:25:08 -0000
Received: from mail-vx0-f171.google.com (HELO mail-vx0-f171.google.com)
	(209.85.220.171)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Dec 2011 10:25:08 -0000
Received: by vcbfl11 with SMTP id fl11so21603790vcb.30
	for <xen-devel@lists.xensource.com>;
	Wed, 21 Dec 2011 02:25:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:message-id:user-agent:date:from:to:cc;
	bh=hgp4B48FO6LurjUFjJIYFu+Xsz+QyV2/0z3pBY5u2gQ=;
	b=DNgw2Ktm4N8gIugOCCbKvakELc4QCpx8hEmFLQKrAHpNFzTYGb03lnGq4z9j3OUWn9
	tSG+lrm1JCxn8JoTSHmUk2L2Luchc43jKtlL3BKviYXN84xiC1i42/RYUU8m0ZrqgMei
	4qSor2IIVutbIuTi7DW6RoDzwe8fhMqVUMOZk=
Received: by 10.220.155.1 with SMTP id q1mr3905275vcw.34.1324463106432;
	Wed, 21 Dec 2011 02:25:06 -0800 (PST)
Received: from alpine.localdomain (tina.upc.es. [147.83.39.243])
	by mx.google.com with ESMTPS id s10sm3850965vdj.1.2011.12.21.02.25.04
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 21 Dec 2011 02:25:05 -0800 (PST)
MIME-Version: 1.0
Message-Id: <patchbomb.1324347544@alpine.localdomain>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Tue, 20 Dec 2011 03:19:04 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Cc: nenolod@dereferenced.org
Subject: [Xen-devel] [PATCH 0 of 4 v2] build: various fixes for building
 with uclibc and libiconv
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This patch contains various fixes to the build system to allow
building xen under uclibc with libiconv. Has been tested with uclibc
0.9.32, gcc 4.6.2 and libiconv 1.12, from Alpine Linux 2.3.2.

Since the series is completely different from the previous one, I
don't think it's worth to add a "Changes since v1" section, becasue
everything is different.

Please review, Roger.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 21 10:25:37 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 10:25:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdJMK-0005ZW-Rn; Wed, 21 Dec 2011 10:25:16 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RdJMJ-0005Yc-KJ
	for xen-devel@lists.xensource.com; Wed, 21 Dec 2011 10:25:15 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1324463106!8261911!2
X-Originating-IP: [209.85.220.171]
X-SpamReason: No, hits=1.1 required=7.0 tests=DATE_IN_PAST_24_48, RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4719 invoked from network); 21 Dec 2011 10:25:08 -0000
Received: from mail-vx0-f171.google.com (HELO mail-vx0-f171.google.com)
	(209.85.220.171)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Dec 2011 10:25:08 -0000
Received: by mail-vx0-f171.google.com with SMTP id fl11so21603790vcb.30
	for <xen-devel@lists.xensource.com>;
	Wed, 21 Dec 2011 02:25:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to:cc; bh=4L8dogjlypZsyNFlfq396a6cJln/Gz/VzZrYN8SqIRE=;
	b=BpnoeTSwymqfZt/h+iXdwN3+NbUzW0RepxwoNlZst2LtYZb7nRkrzZ5wE7xx+Wq+ZR
	BUhQdAlc8kqvcbaQruq7omHARXCC8F5yQJsta7nQxzYZVaGHyz2vjf3el+zMgANr9L2o
	Y/4ODCxW/1RqONGU8PTYbe1H+MXBOgY01bS98=
Received: by 10.52.24.65 with SMTP id s1mr3263559vdf.106.1324463108419;
	Wed, 21 Dec 2011 02:25:08 -0800 (PST)
Received: from alpine.localdomain (tina.upc.es. [147.83.39.243])
	by mx.google.com with ESMTPS id s10sm3850965vdj.1.2011.12.21.02.25.06
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 21 Dec 2011 02:25:07 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 29f5b0afe971335eea4f547efed00b132ade5c64
Message-Id: <29f5b0afe971335eea4f.1324347545@alpine.localdomain>
In-Reply-To: <patchbomb.1324347544@alpine.localdomain>
References: <patchbomb.1324347544@alpine.localdomain>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Tue, 20 Dec 2011 03:19:05 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Cc: nenolod@dereferenced.org
Subject: [Xen-devel] [PATCH 1 of 4 v2] blktap: remove local definitions and
 include byteswap.h
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1324344433 -3600
# Node ID 29f5b0afe971335eea4f547efed00b132ade5c64
# Parent  d23344a87ad7d3d3acae83171586358b081e3f4e
blktap: remove local definitions and include byteswap.h

Use the same approach as tools/blktap2/include/libvhd.h, remove local
definitions of bswap* and include byteswap.h. Also remove the
HAVE_BYTESWAP_H ifdef, since it was not defined in this context (it's
defined by QEMU).

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r d23344a87ad7 -r 29f5b0afe971 tools/blktap/drivers/bswap.h
--- a/tools/blktap/drivers/bswap.h	Tue Dec 20 02:21:25 2011 +0100
+++ b/tools/blktap/drivers/bswap.h	Tue Dec 20 02:27:13 2011 +0100
@@ -15,43 +15,7 @@
 #define bswap_64(x) swap64(x)
 #else
 
-#ifdef HAVE_BYTESWAP_H
 #include <byteswap.h>
-#else
-
-#define bswap_16(x) \
-({ \
-	uint16_t __x = (x); \
-	((uint16_t)( \
-		(((uint16_t)(__x) & (uint16_t)0x00ffU) << 8) | \
-		(((uint16_t)(__x) & (uint16_t)0xff00U) >> 8) )); \
-})
-
-#define bswap_32(x) \
-({ \
-	uint32_t __x = (x); \
-	((uint32_t)( \
-		(((uint32_t)(__x) & (uint32_t)0x000000ffUL) << 24) | \
-		(((uint32_t)(__x) & (uint32_t)0x0000ff00UL) <<  8) | \
-		(((uint32_t)(__x) & (uint32_t)0x00ff0000UL) >>  8) | \
-		(((uint32_t)(__x) & (uint32_t)0xff000000UL) >> 24) )); \
-})
-
-#define bswap_64(x) \
-({ \
-	uint64_t __x = (x); \
-	((uint64_t)( \
-		(uint64_t)(((uint64_t)(__x) & (uint64_t)0x00000000000000ffULL) << 56) | \
-		(uint64_t)(((uint64_t)(__x) & (uint64_t)0x000000000000ff00ULL) << 40) | \
-		(uint64_t)(((uint64_t)(__x) & (uint64_t)0x0000000000ff0000ULL) << 24) | \
-		(uint64_t)(((uint64_t)(__x) & (uint64_t)0x00000000ff000000ULL) <<  8) | \
-	        (uint64_t)(((uint64_t)(__x) & (uint64_t)0x000000ff00000000ULL) >>  8) | \
-		(uint64_t)(((uint64_t)(__x) & (uint64_t)0x0000ff0000000000ULL) >> 24) | \
-		(uint64_t)(((uint64_t)(__x) & (uint64_t)0x00ff000000000000ULL) >> 40) | \
-		(uint64_t)(((uint64_t)(__x) & (uint64_t)0xff00000000000000ULL) >> 56) )); \
-})
-
-#endif /* !HAVE_BYTESWAP_H */
 
 static inline uint16_t bswap16(uint16_t x)
 {

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 21 10:25:37 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 10:25:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdJMK-0005ZW-Rn; Wed, 21 Dec 2011 10:25:16 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RdJMJ-0005Yc-KJ
	for xen-devel@lists.xensource.com; Wed, 21 Dec 2011 10:25:15 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1324463106!8261911!2
X-Originating-IP: [209.85.220.171]
X-SpamReason: No, hits=1.1 required=7.0 tests=DATE_IN_PAST_24_48, RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4719 invoked from network); 21 Dec 2011 10:25:08 -0000
Received: from mail-vx0-f171.google.com (HELO mail-vx0-f171.google.com)
	(209.85.220.171)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Dec 2011 10:25:08 -0000
Received: by mail-vx0-f171.google.com with SMTP id fl11so21603790vcb.30
	for <xen-devel@lists.xensource.com>;
	Wed, 21 Dec 2011 02:25:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to:cc; bh=4L8dogjlypZsyNFlfq396a6cJln/Gz/VzZrYN8SqIRE=;
	b=BpnoeTSwymqfZt/h+iXdwN3+NbUzW0RepxwoNlZst2LtYZb7nRkrzZ5wE7xx+Wq+ZR
	BUhQdAlc8kqvcbaQruq7omHARXCC8F5yQJsta7nQxzYZVaGHyz2vjf3el+zMgANr9L2o
	Y/4ODCxW/1RqONGU8PTYbe1H+MXBOgY01bS98=
Received: by 10.52.24.65 with SMTP id s1mr3263559vdf.106.1324463108419;
	Wed, 21 Dec 2011 02:25:08 -0800 (PST)
Received: from alpine.localdomain (tina.upc.es. [147.83.39.243])
	by mx.google.com with ESMTPS id s10sm3850965vdj.1.2011.12.21.02.25.06
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 21 Dec 2011 02:25:07 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 29f5b0afe971335eea4f547efed00b132ade5c64
Message-Id: <29f5b0afe971335eea4f.1324347545@alpine.localdomain>
In-Reply-To: <patchbomb.1324347544@alpine.localdomain>
References: <patchbomb.1324347544@alpine.localdomain>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Tue, 20 Dec 2011 03:19:05 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Cc: nenolod@dereferenced.org
Subject: [Xen-devel] [PATCH 1 of 4 v2] blktap: remove local definitions and
 include byteswap.h
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1324344433 -3600
# Node ID 29f5b0afe971335eea4f547efed00b132ade5c64
# Parent  d23344a87ad7d3d3acae83171586358b081e3f4e
blktap: remove local definitions and include byteswap.h

Use the same approach as tools/blktap2/include/libvhd.h, remove local
definitions of bswap* and include byteswap.h. Also remove the
HAVE_BYTESWAP_H ifdef, since it was not defined in this context (it's
defined by QEMU).

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r d23344a87ad7 -r 29f5b0afe971 tools/blktap/drivers/bswap.h
--- a/tools/blktap/drivers/bswap.h	Tue Dec 20 02:21:25 2011 +0100
+++ b/tools/blktap/drivers/bswap.h	Tue Dec 20 02:27:13 2011 +0100
@@ -15,43 +15,7 @@
 #define bswap_64(x) swap64(x)
 #else
 
-#ifdef HAVE_BYTESWAP_H
 #include <byteswap.h>
-#else
-
-#define bswap_16(x) \
-({ \
-	uint16_t __x = (x); \
-	((uint16_t)( \
-		(((uint16_t)(__x) & (uint16_t)0x00ffU) << 8) | \
-		(((uint16_t)(__x) & (uint16_t)0xff00U) >> 8) )); \
-})
-
-#define bswap_32(x) \
-({ \
-	uint32_t __x = (x); \
-	((uint32_t)( \
-		(((uint32_t)(__x) & (uint32_t)0x000000ffUL) << 24) | \
-		(((uint32_t)(__x) & (uint32_t)0x0000ff00UL) <<  8) | \
-		(((uint32_t)(__x) & (uint32_t)0x00ff0000UL) >>  8) | \
-		(((uint32_t)(__x) & (uint32_t)0xff000000UL) >> 24) )); \
-})
-
-#define bswap_64(x) \
-({ \
-	uint64_t __x = (x); \
-	((uint64_t)( \
-		(uint64_t)(((uint64_t)(__x) & (uint64_t)0x00000000000000ffULL) << 56) | \
-		(uint64_t)(((uint64_t)(__x) & (uint64_t)0x000000000000ff00ULL) << 40) | \
-		(uint64_t)(((uint64_t)(__x) & (uint64_t)0x0000000000ff0000ULL) << 24) | \
-		(uint64_t)(((uint64_t)(__x) & (uint64_t)0x00000000ff000000ULL) <<  8) | \
-	        (uint64_t)(((uint64_t)(__x) & (uint64_t)0x000000ff00000000ULL) >>  8) | \
-		(uint64_t)(((uint64_t)(__x) & (uint64_t)0x0000ff0000000000ULL) >> 24) | \
-		(uint64_t)(((uint64_t)(__x) & (uint64_t)0x00ff000000000000ULL) >> 40) | \
-		(uint64_t)(((uint64_t)(__x) & (uint64_t)0xff00000000000000ULL) >> 56) )); \
-})
-
-#endif /* !HAVE_BYTESWAP_H */
 
 static inline uint16_t bswap16(uint16_t x)
 {

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 21 10:25:39 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 10:25:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdJMR-0005aq-NG; Wed, 21 Dec 2011 10:25:23 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RdJMQ-0005Ze-LI
	for xen-devel@lists.xensource.com; Wed, 21 Dec 2011 10:25:22 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1324463106!8261911!4
X-Originating-IP: [209.85.220.171]
X-SpamReason: No, hits=1.1 required=7.0 tests=DATE_IN_PAST_24_48, RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5067 invoked from network); 21 Dec 2011 10:25:16 -0000
Received: from mail-vx0-f171.google.com (HELO mail-vx0-f171.google.com)
	(209.85.220.171)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Dec 2011 10:25:16 -0000
Received: by mail-vx0-f171.google.com with SMTP id fl11so21603790vcb.30
	for <xen-devel@lists.xensource.com>;
	Wed, 21 Dec 2011 02:25:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to:cc; bh=HEbg9P9z5sPz74TxLk+wfCIC25KPz7z39+DC8ZJCDvc=;
	b=Y4T4SnAtOdhfG7lWqgMi8vwlrcGZ/5lYisixuFQ15QezOFnUzm70mYbQKalaQTzwBz
	cySSVWHsUEvwlGi8DC3S9xxdnONzayiW2h+3EWfvgIVRwxpfCUVVtad9bxgRP24WC/5i
	l5Y7O4iu1oh219gMYfO2z9zZPzUTBQGYXVk3o=
Received: by 10.220.39.9 with SMTP id d9mr4237510vce.10.1324463116143;
	Wed, 21 Dec 2011 02:25:16 -0800 (PST)
Received: from alpine.localdomain (tina.upc.es. [147.83.39.243])
	by mx.google.com with ESMTPS id s10sm3850965vdj.1.2011.12.21.02.25.11
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 21 Dec 2011 02:25:15 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 14e911353a91702b439bc06e2a77d67e8bd5f661
Message-Id: <14e911353a91702b439b.1324347547@alpine.localdomain>
In-Reply-To: <patchbomb.1324347544@alpine.localdomain>
References: <patchbomb.1324347544@alpine.localdomain>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Tue, 20 Dec 2011 03:19:07 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Cc: nenolod@dereferenced.org
Subject: [Xen-devel] [PATCH 3 of 4 v2] build: detect is libiconv is present
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1324344612 -3600
# Node ID 14e911353a91702b439bc06e2a77d67e8bd5f661
# Parent  23e1abbd203ca2619103f3e95c6b1ff36be60e38
build: detect is libiconv is present

Detect if libiconv is present in the system, since we will have to
link against it when using iconv.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 23e1abbd203c -r 14e911353a91 Config.mk
--- a/Config.mk	Tue Dec 20 02:28:34 2011 +0100
+++ b/Config.mk	Tue Dec 20 02:30:12 2011 +0100
@@ -18,6 +18,8 @@ XEN_TARGET_ARCH     ?= $(XEN_COMPILE_ARC
 XEN_OS              ?= $(shell uname -s)
 
 CONFIG_$(XEN_OS) := y
+CONFIG_LIBICONV  := $(shell grep -q LIBICONV_PLUG /usr/include/iconv.h \
+                      && echo 'y' || echo 'n')
 
 SHELL     ?= /bin/sh
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 21 10:25:39 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 10:25:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdJMR-0005aq-NG; Wed, 21 Dec 2011 10:25:23 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RdJMQ-0005Ze-LI
	for xen-devel@lists.xensource.com; Wed, 21 Dec 2011 10:25:22 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1324463106!8261911!4
X-Originating-IP: [209.85.220.171]
X-SpamReason: No, hits=1.1 required=7.0 tests=DATE_IN_PAST_24_48, RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5067 invoked from network); 21 Dec 2011 10:25:16 -0000
Received: from mail-vx0-f171.google.com (HELO mail-vx0-f171.google.com)
	(209.85.220.171)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Dec 2011 10:25:16 -0000
Received: by mail-vx0-f171.google.com with SMTP id fl11so21603790vcb.30
	for <xen-devel@lists.xensource.com>;
	Wed, 21 Dec 2011 02:25:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to:cc; bh=HEbg9P9z5sPz74TxLk+wfCIC25KPz7z39+DC8ZJCDvc=;
	b=Y4T4SnAtOdhfG7lWqgMi8vwlrcGZ/5lYisixuFQ15QezOFnUzm70mYbQKalaQTzwBz
	cySSVWHsUEvwlGi8DC3S9xxdnONzayiW2h+3EWfvgIVRwxpfCUVVtad9bxgRP24WC/5i
	l5Y7O4iu1oh219gMYfO2z9zZPzUTBQGYXVk3o=
Received: by 10.220.39.9 with SMTP id d9mr4237510vce.10.1324463116143;
	Wed, 21 Dec 2011 02:25:16 -0800 (PST)
Received: from alpine.localdomain (tina.upc.es. [147.83.39.243])
	by mx.google.com with ESMTPS id s10sm3850965vdj.1.2011.12.21.02.25.11
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 21 Dec 2011 02:25:15 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 14e911353a91702b439bc06e2a77d67e8bd5f661
Message-Id: <14e911353a91702b439b.1324347547@alpine.localdomain>
In-Reply-To: <patchbomb.1324347544@alpine.localdomain>
References: <patchbomb.1324347544@alpine.localdomain>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Tue, 20 Dec 2011 03:19:07 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Cc: nenolod@dereferenced.org
Subject: [Xen-devel] [PATCH 3 of 4 v2] build: detect is libiconv is present
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1324344612 -3600
# Node ID 14e911353a91702b439bc06e2a77d67e8bd5f661
# Parent  23e1abbd203ca2619103f3e95c6b1ff36be60e38
build: detect is libiconv is present

Detect if libiconv is present in the system, since we will have to
link against it when using iconv.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 23e1abbd203c -r 14e911353a91 Config.mk
--- a/Config.mk	Tue Dec 20 02:28:34 2011 +0100
+++ b/Config.mk	Tue Dec 20 02:30:12 2011 +0100
@@ -18,6 +18,8 @@ XEN_TARGET_ARCH     ?= $(XEN_COMPILE_ARC
 XEN_OS              ?= $(shell uname -s)
 
 CONFIG_$(XEN_OS) := y
+CONFIG_LIBICONV  := $(shell grep -q LIBICONV_PLUG /usr/include/iconv.h \
+                      && echo 'y' || echo 'n')
 
 SHELL     ?= /bin/sh
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 21 10:25:42 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 10:25:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdJMV-0005be-5Y; Wed, 21 Dec 2011 10:25:27 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RdJMT-0005a5-S0
	for xen-devel@lists.xensource.com; Wed, 21 Dec 2011 10:25:26 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1324463106!8261911!5
X-Originating-IP: [209.85.220.171]
X-SpamReason: No, hits=1.1 required=7.0 tests=DATE_IN_PAST_24_48, RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5518 invoked from network); 21 Dec 2011 10:25:19 -0000
Received: from mail-vx0-f171.google.com (HELO mail-vx0-f171.google.com)
	(209.85.220.171)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Dec 2011 10:25:19 -0000
Received: by mail-vx0-f171.google.com with SMTP id fl11so21603790vcb.30
	for <xen-devel@lists.xensource.com>;
	Wed, 21 Dec 2011 02:25:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to:cc; bh=BotAsPZKEb2YpruPYP4SE9BZYDUelCv3Y03zcEp/6fY=;
	b=kIuy2e3Z+utxQr4fZ4lZYAGs/326TssFLJPlcjZbvrTJOQXY65jQlZwekPrB+k+IIz
	2DzANLcU0adtsNZPwNTTjRmBOQI9m0CgjhXEeYRlx3dkIRLSz3Hz4Y5yVVBof+TxXJ2W
	huxCRvHswxPLRUQ/L5vDRsxOBV814qrIL4n+o=
Received: by 10.220.214.73 with SMTP id gz9mr3935544vcb.5.1324463119562;
	Wed, 21 Dec 2011 02:25:19 -0800 (PST)
Received: from alpine.localdomain (tina.upc.es. [147.83.39.243])
	by mx.google.com with ESMTPS id s10sm3850965vdj.1.2011.12.21.02.25.16
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 21 Dec 2011 02:25:17 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 993c86e4ecbc85a95f27ba299e8e9285d76c56b2
Message-Id: <993c86e4ecbc85a95f27.1324347548@alpine.localdomain>
In-Reply-To: <patchbomb.1324347544@alpine.localdomain>
References: <patchbomb.1324347544@alpine.localdomain>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Tue, 20 Dec 2011 03:19:08 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Cc: nenolod@dereferenced.org
Subject: [Xen-devel] [PATCH 4 of 4 v2] blktap2/vhd: add -liconv when linking
 if using libiconv
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1324344791 -3600
# Node ID 993c86e4ecbc85a95f27ba299e8e9285d76c56b2
# Parent  14e911353a91702b439bc06e2a77d67e8bd5f661
blktap2/vhd: add -liconv when linking if using libiconv

If libiconv is detected on the system add -liconv when linking the
libvhd library.

If -liconv is not added when compiling libvhd with libiconv the
following error occours when linking vhd-util and vhd-update:

gcc     -o vhd-util vhd-util.o -Llib -lvhd
lib/libvhd.so: undefined reference to `libiconv_open'
lib/libvhd.so: undefined reference to `libiconv_close'
lib/libvhd.so: undefined reference to `libiconv'

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 14e911353a91 -r 993c86e4ecbc tools/blktap2/vhd/lib/Makefile
--- a/tools/blktap2/vhd/lib/Makefile	Tue Dec 20 02:30:12 2011 +0100
+++ b/tools/blktap2/vhd/lib/Makefile	Tue Dec 20 02:33:11 2011 +0100
@@ -23,6 +23,10 @@ ifeq ($(CONFIG_Linux),y)
 LIBS            := -luuid
 endif
 
+ifeq ($(CONFIG_LIBICONV),y)
+LIBS            += -liconv
+endif
+
 LIB-SRCS        := libvhd.c
 LIB-SRCS        += libvhd-journal.c
 LIB-SRCS        += vhd-util-coalesce.c

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 21 10:25:42 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 10:25:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdJMV-0005be-5Y; Wed, 21 Dec 2011 10:25:27 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RdJMT-0005a5-S0
	for xen-devel@lists.xensource.com; Wed, 21 Dec 2011 10:25:26 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1324463106!8261911!5
X-Originating-IP: [209.85.220.171]
X-SpamReason: No, hits=1.1 required=7.0 tests=DATE_IN_PAST_24_48, RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5518 invoked from network); 21 Dec 2011 10:25:19 -0000
Received: from mail-vx0-f171.google.com (HELO mail-vx0-f171.google.com)
	(209.85.220.171)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Dec 2011 10:25:19 -0000
Received: by mail-vx0-f171.google.com with SMTP id fl11so21603790vcb.30
	for <xen-devel@lists.xensource.com>;
	Wed, 21 Dec 2011 02:25:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to:cc; bh=BotAsPZKEb2YpruPYP4SE9BZYDUelCv3Y03zcEp/6fY=;
	b=kIuy2e3Z+utxQr4fZ4lZYAGs/326TssFLJPlcjZbvrTJOQXY65jQlZwekPrB+k+IIz
	2DzANLcU0adtsNZPwNTTjRmBOQI9m0CgjhXEeYRlx3dkIRLSz3Hz4Y5yVVBof+TxXJ2W
	huxCRvHswxPLRUQ/L5vDRsxOBV814qrIL4n+o=
Received: by 10.220.214.73 with SMTP id gz9mr3935544vcb.5.1324463119562;
	Wed, 21 Dec 2011 02:25:19 -0800 (PST)
Received: from alpine.localdomain (tina.upc.es. [147.83.39.243])
	by mx.google.com with ESMTPS id s10sm3850965vdj.1.2011.12.21.02.25.16
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 21 Dec 2011 02:25:17 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 993c86e4ecbc85a95f27ba299e8e9285d76c56b2
Message-Id: <993c86e4ecbc85a95f27.1324347548@alpine.localdomain>
In-Reply-To: <patchbomb.1324347544@alpine.localdomain>
References: <patchbomb.1324347544@alpine.localdomain>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Tue, 20 Dec 2011 03:19:08 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Cc: nenolod@dereferenced.org
Subject: [Xen-devel] [PATCH 4 of 4 v2] blktap2/vhd: add -liconv when linking
 if using libiconv
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1324344791 -3600
# Node ID 993c86e4ecbc85a95f27ba299e8e9285d76c56b2
# Parent  14e911353a91702b439bc06e2a77d67e8bd5f661
blktap2/vhd: add -liconv when linking if using libiconv

If libiconv is detected on the system add -liconv when linking the
libvhd library.

If -liconv is not added when compiling libvhd with libiconv the
following error occours when linking vhd-util and vhd-update:

gcc     -o vhd-util vhd-util.o -Llib -lvhd
lib/libvhd.so: undefined reference to `libiconv_open'
lib/libvhd.so: undefined reference to `libiconv_close'
lib/libvhd.so: undefined reference to `libiconv'

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 14e911353a91 -r 993c86e4ecbc tools/blktap2/vhd/lib/Makefile
--- a/tools/blktap2/vhd/lib/Makefile	Tue Dec 20 02:30:12 2011 +0100
+++ b/tools/blktap2/vhd/lib/Makefile	Tue Dec 20 02:33:11 2011 +0100
@@ -23,6 +23,10 @@ ifeq ($(CONFIG_Linux),y)
 LIBS            := -luuid
 endif
 
+ifeq ($(CONFIG_LIBICONV),y)
+LIBS            += -liconv
+endif
+
 LIB-SRCS        := libvhd.c
 LIB-SRCS        += libvhd-journal.c
 LIB-SRCS        += vhd-util-coalesce.c

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 21 10:28:59 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 10:28:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdJPn-0006IQ-Rt; Wed, 21 Dec 2011 10:28:51 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RdJPn-0006HE-8s
	for xen-devel@lists.xensource.com; Wed, 21 Dec 2011 10:28:51 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1324463325!2345838!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzcyNA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9008 invoked from network); 21 Dec 2011 10:28:45 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Dec 2011 10:28:45 -0000
X-IronPort-AV: E=Sophos;i="4.71,387,1320624000"; d="scan'208,217";a="9602294"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Dec 2011 10:28:43 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 21 Dec 2011 10:28:43 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau =?ISO-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
Date: Wed, 21 Dec 2011 10:28:42 +0000
In-Reply-To: <CAPLaKK6OrZfcktRmUvV_0-8vd7hS=YKA-FwivX928ecefot9Zg@mail.gmail.com>
References: <patchbomb.1324212500@alpine.localdomain>
	<c0d5aa328f1ab24aad58.1324212503@alpine.localdomain>
	<CA+T2pCE_L0Gfyb0xu4=bd-yCAz=+Z_4Ugyd-EoO4m=+jz5MPGA@mail.gmail.com>
	<CAPLaKK5gYZ+KDsJW4+FSkP=nqDJmaO3W72pfkbg8m25fYu+_1Q@mail.gmail.com>
	<1324301203.9236.40.camel@zakaz.uk.xensource.com>
	<CAPLaKK6NhoXTiaFWb9aTcuapaqtNVcKo==7=xXP8wf5N66kFUw@mail.gmail.com>
	<1324302182.9236.51.camel@zakaz.uk.xensource.com>
	<CAPLaKK4xpN5Ro6medFjwBmg9zjs2pYHThmgP=NvdoJt+N=t1rA@mail.gmail.com>
	<CAPLaKK4TSzGoD2CGW1ubnqLcSfDCu5CFe6OAVFud446JyOcXtw@mail.gmail.com>
	<1324461678.23729.84.camel@zakaz.uk.xensource.com>
	<CAPLaKK6OrZfcktRmUvV_0-8vd7hS=YKA-FwivX928ecefot9Zg@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1324463322.23729.96.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: William Pitcock <nenolod@dereferenced.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 3 of 5] blktap2: fix vhd compilation under
 uclibc
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gV2VkLCAyMDExLTEyLTIxIGF0IDEwOjE1ICswMDAwLCBSb2dlciBQYXUgTW9ubsOpIHdyb3Rl
Ogo+IDIwMTEvMTIvMjEgSWFuIENhbXBiZWxsIDxJYW4uQ2FtcGJlbGxAY2l0cml4LmNvbT46Cj4g
PiBPbiBUdWUsIDIwMTEtMTItMjAgYXQgMTc6NTUgKzAwMDAsIFJvZ2VyIFBhdSBNb25uw6kgd3Jv
dGU6Cj4gPj4gSGVsbG8sCj4gPj4KPiA+PiBJJ3ZlIGFkZGVkIC1saWNvbnYgdG8gYmxrdGFwMi92
aGQvbGliLCBhbmQgc3VjY2VzZnVsbHkgY29tcGlsZWQgYW5kCj4gPj4gbGlua2VkIHRoZSBsaWJy
YXJ5LiBUaGUgb3V0cHV0IGZyb20gbGRkIGxpYnZoZC5zbyBzaG93czoKPiA+Pgo+ID4+IGNoZWNr
aW5nIHN1Yi1kZXBlbmRzIGZvciAnL2xpYi9saWJ1dWlkLnNvLjEnCj4gPj4gY2hlY2tpbmcgc3Vi
LWRlcGVuZHMgZm9yICcvdXNyL2xpYi9saWJpY29udi5zby4yJwo+ID4+IGNoZWNraW5nIHN1Yi1k
ZXBlbmRzIGZvciAnL2xpYi9saWJjLnNvLjAuOS4zMicKPiA+PiBjaGVja2luZyBzdWItZGVwZW5k
cyBmb3IgJy9saWIvbGQ2NC11Q2xpYmMuc28uMC45LjMyJwo+ID4+ICAgICAgIGxpYnV1aWQuc28u
MSA9PiAvbGliL2xpYnV1aWQuc28uMSAoMHgwMDAwMDAwMCkKPiA+PiAgICAgICBsaWJpY29udi5z
by4yID0+IC91c3IvbGliL2xpYmljb252LnNvLjIgKDB4MDAwMDAwMDApCj4gPj4gICAgICAgbGli
Yy5zby4wLjkuMzIgPT4gL2xpYi9saWJjLnNvLjAuOS4zMiAoMHgwMDAwMDAwMCkKPiA+PiAgICAg
ICBsZDY0LXVDbGliYy5zby4wLjkuMzIgPT4gL2xpYi9sZDY0LXVDbGliYy5zby4wLjkuMzIgKDB4
MDAwMDAwMDApCj4gPj4gICAgICAgbm90IGEgZHluYW1pYyBleGVjdXRhYmxlCj4gPj4KPiA+PiBU
aGVuIEkndmUgY29tcGlsZWQgYW5kIGxpbmtlZCB2aGQgdG9vbHMgKHZoZC11dGlsIGFuZCB2aGQt
dXBkYXRlKQo+ID4+IHdpdGhvdXQgLWxpY29udiwgc2luY2UgdmhkIHRvb2xzIGRvZXNuJ3QgdXNl
IGFueSBpY29udiBmdW5jdGlvbnMuIFRoZXkKPiA+PiBjb21waWxlIGZpbmUsIGJ1dCB3aGVuIEkg
dHJ5IHRvIGV4ZWN1dGUgdGhlbSBJIGdldCB0aGUgZm9sbG93aW5nCj4gPj4gZXJyb3I6Cj4gPj4K
PiA+PiB2aGQtdXRpbDogc3ltYm9sICdsaWJpY29udl9vcGVuJzogY2FuJ3QgcmVzb2x2ZSBzeW1i
b2wKPiA+Pgo+ID4+IElmIEkgZG8gYSBsZGQgb2YgdmhkLXV0aWw6Cj4gPj4KPiA+PiAgICAgICBs
aWJ2aGQuc28uMS4wID0+IC91c3IvbGliL2xpYnZoZC5zby4xLjAgKDB4NzY5OWVmYWY0MDAwKQo+
ID4+ICAgICAgIGxpYmMuc28uMC45LjMyID0+IC9saWIvbGliYy5zby4wLjkuMzIgKDB4NzY5OWVm
ODhjMDAwKQo+ID4+ICAgICAgIGxpYnV1aWQuc28uMSA9PiAvbGliL2xpYnV1aWQuc28uMSAoMHg3
Njk5ZWY2ODkwMDApCj4gPj4gICAgICAgbGQ2NC11Q2xpYmMuc28uMC45LjMyID0+IC9saWIvbGQ2
NC11Q2xpYmMuc28uMC45LjMyICgweDc2OTllZmQxMDAwMCkKPiA+Pgo+ID4+IEhvdyBjb21lIGxp
Ymljb252IGlzIG5vdCBsaW5rZWQgdG8gdGhlIGFwcGxpY2F0aW9uIGlmIGxpYnZoZCBpcz8KPiA+
Cj4gPiBDYW4geW91IHBvc3QgdGhlIGNvbXBsZXRlIGxpbmsgbGluZSBmb3IgZWFjaCBzdGFnZT8K
PiA+Cj4gPiBBcmUgeW91IHN1cmUgdGhhdCAvdXNyL2xpYi9saWJ2aGQuc28uMS4wIGlzIHRoZSBz
YW1lIG9uZSB5b3UganVzdCBidWlsdAo+ID4gYW5kIGxpbmtlZCBhZ2FpbnN0PyBJcyB0aGVyZSBh
IGNoYW5jZSB5b3UgaGF2ZSBsaW5rZWQgYWdhaW5zdCBzb21ldGhpbmcKPiA+IGluIHRoZSBidWls
ZCBkaXJlY3Rvcnkgd2hpY2ggZGlkIG5vdCBnZXQgcHJvcGVybHkgaW5zdGFsbGVkPwo+IAo+IFNv
cnJ5LCBJJ20ganVzdCBzdHVwaWQsIHRvZGF5IEkndmUgcmVhbGl6ZWQgd2hhdCB0aGUgcHJvYmxl
bSB3YXMuIEl0Cj4gd2FzIGxpbmtlZCBhZ2FpbnN0IGFuZCBvbGQgL3Vzci9saWIvbGlidmhkLnNv
IHdoaWNoIHdhcyBub3QgY29tcGlsZWQKPiB3aXRoIC1saWNvbnYuCgpHcmVhdC4KCj4gCj4gPiBS
dW5uaW5nCj4gPiAgICAgICAgb2JqZHVtcCAtcCA8b2JqZWN0PiB8IGVncmVwIE5FRURFRFx8U09O
QU1FCj4gPiBmb3IgdGhlIGxpYnJhcnkgKGJvdGggYnVpbGQgZGlyIGFuZCBpbnN0YWxsZWQgY29w
aWVzKSBhbmQgYmluYXJ5IHdvdWxkCj4gPiBiZSBpbnRlcmVzdGluZy4KPiA+Cj4gPiBJdCBzZWVt
cyBsaWtlIGVpdGhlciB0aGlzIGlzIGEgYnVnIGluIHVDbGliYydzIGR5bmFtaWMgbGlua2VyIG9y
IG15Cj4gPiBleHBlY3RhdGlvbiBvZiBob3cgdGhlc2Ugc29ydHMgb2YgdHJhbnNpdGl2ZSBsaWJy
YXJ5IGRlcGVuZGVuY2llcyB3b3JrCj4gPiBoYXMgYmVlbiBzZXQgdG9vIGhpZ2ggYnkgZ2xpYmMu
Li4KPiA+Cj4gPj4gIEFuZAo+ID4+IHdoYXQncyBtb3N0IHN0cmFuZ2UsIHdoeSBpcyB0aGUgbGlu
ayB0byBsaWJ1dWlkIGtlZXAsIGJ1dCBub3QgdGhlIG9uZQo+ID4+IHRvIGxpYmljb252Pwo+ID4K
PiA+IFllcywgdGhhdCBpcyBzdHJhbmdlLgo+IAo+IEkgc3RpbGwgZG9uJ3QgZ2V0IHRoZSBsaWJ1
dWlkIHRoaW5nLCBidXQgaXQgd29ya3MganVzdCBmaW5lIG5vdy4KClByZXN1bWFibHkgdGhlIG9s
ZCBsaWJ2aGQuc28gbm90IGNvbXBpbGVkIGFnYWluc3QgLWxpY29udiBfd2FzXyBjb21waWxlZAp3
aXRoIC1sdXVpZC4KCklhbi4KCj4gCj4gPiBJYW4uCj4gPgoKCgpfX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1k
ZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tCmh0dHA6Ly9saXN0cy54ZW5zb3VyY2UuY29tL3hlbi1k
ZXZlbAo=

From xen-devel-bounces@lists.xensource.com Wed Dec 21 10:28:59 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 10:28:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdJPn-0006IQ-Rt; Wed, 21 Dec 2011 10:28:51 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RdJPn-0006HE-8s
	for xen-devel@lists.xensource.com; Wed, 21 Dec 2011 10:28:51 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1324463325!2345838!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzcyNA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9008 invoked from network); 21 Dec 2011 10:28:45 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Dec 2011 10:28:45 -0000
X-IronPort-AV: E=Sophos;i="4.71,387,1320624000"; d="scan'208,217";a="9602294"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Dec 2011 10:28:43 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 21 Dec 2011 10:28:43 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau =?ISO-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
Date: Wed, 21 Dec 2011 10:28:42 +0000
In-Reply-To: <CAPLaKK6OrZfcktRmUvV_0-8vd7hS=YKA-FwivX928ecefot9Zg@mail.gmail.com>
References: <patchbomb.1324212500@alpine.localdomain>
	<c0d5aa328f1ab24aad58.1324212503@alpine.localdomain>
	<CA+T2pCE_L0Gfyb0xu4=bd-yCAz=+Z_4Ugyd-EoO4m=+jz5MPGA@mail.gmail.com>
	<CAPLaKK5gYZ+KDsJW4+FSkP=nqDJmaO3W72pfkbg8m25fYu+_1Q@mail.gmail.com>
	<1324301203.9236.40.camel@zakaz.uk.xensource.com>
	<CAPLaKK6NhoXTiaFWb9aTcuapaqtNVcKo==7=xXP8wf5N66kFUw@mail.gmail.com>
	<1324302182.9236.51.camel@zakaz.uk.xensource.com>
	<CAPLaKK4xpN5Ro6medFjwBmg9zjs2pYHThmgP=NvdoJt+N=t1rA@mail.gmail.com>
	<CAPLaKK4TSzGoD2CGW1ubnqLcSfDCu5CFe6OAVFud446JyOcXtw@mail.gmail.com>
	<1324461678.23729.84.camel@zakaz.uk.xensource.com>
	<CAPLaKK6OrZfcktRmUvV_0-8vd7hS=YKA-FwivX928ecefot9Zg@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1324463322.23729.96.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: William Pitcock <nenolod@dereferenced.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 3 of 5] blktap2: fix vhd compilation under
 uclibc
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gV2VkLCAyMDExLTEyLTIxIGF0IDEwOjE1ICswMDAwLCBSb2dlciBQYXUgTW9ubsOpIHdyb3Rl
Ogo+IDIwMTEvMTIvMjEgSWFuIENhbXBiZWxsIDxJYW4uQ2FtcGJlbGxAY2l0cml4LmNvbT46Cj4g
PiBPbiBUdWUsIDIwMTEtMTItMjAgYXQgMTc6NTUgKzAwMDAsIFJvZ2VyIFBhdSBNb25uw6kgd3Jv
dGU6Cj4gPj4gSGVsbG8sCj4gPj4KPiA+PiBJJ3ZlIGFkZGVkIC1saWNvbnYgdG8gYmxrdGFwMi92
aGQvbGliLCBhbmQgc3VjY2VzZnVsbHkgY29tcGlsZWQgYW5kCj4gPj4gbGlua2VkIHRoZSBsaWJy
YXJ5LiBUaGUgb3V0cHV0IGZyb20gbGRkIGxpYnZoZC5zbyBzaG93czoKPiA+Pgo+ID4+IGNoZWNr
aW5nIHN1Yi1kZXBlbmRzIGZvciAnL2xpYi9saWJ1dWlkLnNvLjEnCj4gPj4gY2hlY2tpbmcgc3Vi
LWRlcGVuZHMgZm9yICcvdXNyL2xpYi9saWJpY29udi5zby4yJwo+ID4+IGNoZWNraW5nIHN1Yi1k
ZXBlbmRzIGZvciAnL2xpYi9saWJjLnNvLjAuOS4zMicKPiA+PiBjaGVja2luZyBzdWItZGVwZW5k
cyBmb3IgJy9saWIvbGQ2NC11Q2xpYmMuc28uMC45LjMyJwo+ID4+ICAgICAgIGxpYnV1aWQuc28u
MSA9PiAvbGliL2xpYnV1aWQuc28uMSAoMHgwMDAwMDAwMCkKPiA+PiAgICAgICBsaWJpY29udi5z
by4yID0+IC91c3IvbGliL2xpYmljb252LnNvLjIgKDB4MDAwMDAwMDApCj4gPj4gICAgICAgbGli
Yy5zby4wLjkuMzIgPT4gL2xpYi9saWJjLnNvLjAuOS4zMiAoMHgwMDAwMDAwMCkKPiA+PiAgICAg
ICBsZDY0LXVDbGliYy5zby4wLjkuMzIgPT4gL2xpYi9sZDY0LXVDbGliYy5zby4wLjkuMzIgKDB4
MDAwMDAwMDApCj4gPj4gICAgICAgbm90IGEgZHluYW1pYyBleGVjdXRhYmxlCj4gPj4KPiA+PiBU
aGVuIEkndmUgY29tcGlsZWQgYW5kIGxpbmtlZCB2aGQgdG9vbHMgKHZoZC11dGlsIGFuZCB2aGQt
dXBkYXRlKQo+ID4+IHdpdGhvdXQgLWxpY29udiwgc2luY2UgdmhkIHRvb2xzIGRvZXNuJ3QgdXNl
IGFueSBpY29udiBmdW5jdGlvbnMuIFRoZXkKPiA+PiBjb21waWxlIGZpbmUsIGJ1dCB3aGVuIEkg
dHJ5IHRvIGV4ZWN1dGUgdGhlbSBJIGdldCB0aGUgZm9sbG93aW5nCj4gPj4gZXJyb3I6Cj4gPj4K
PiA+PiB2aGQtdXRpbDogc3ltYm9sICdsaWJpY29udl9vcGVuJzogY2FuJ3QgcmVzb2x2ZSBzeW1i
b2wKPiA+Pgo+ID4+IElmIEkgZG8gYSBsZGQgb2YgdmhkLXV0aWw6Cj4gPj4KPiA+PiAgICAgICBs
aWJ2aGQuc28uMS4wID0+IC91c3IvbGliL2xpYnZoZC5zby4xLjAgKDB4NzY5OWVmYWY0MDAwKQo+
ID4+ICAgICAgIGxpYmMuc28uMC45LjMyID0+IC9saWIvbGliYy5zby4wLjkuMzIgKDB4NzY5OWVm
ODhjMDAwKQo+ID4+ICAgICAgIGxpYnV1aWQuc28uMSA9PiAvbGliL2xpYnV1aWQuc28uMSAoMHg3
Njk5ZWY2ODkwMDApCj4gPj4gICAgICAgbGQ2NC11Q2xpYmMuc28uMC45LjMyID0+IC9saWIvbGQ2
NC11Q2xpYmMuc28uMC45LjMyICgweDc2OTllZmQxMDAwMCkKPiA+Pgo+ID4+IEhvdyBjb21lIGxp
Ymljb252IGlzIG5vdCBsaW5rZWQgdG8gdGhlIGFwcGxpY2F0aW9uIGlmIGxpYnZoZCBpcz8KPiA+
Cj4gPiBDYW4geW91IHBvc3QgdGhlIGNvbXBsZXRlIGxpbmsgbGluZSBmb3IgZWFjaCBzdGFnZT8K
PiA+Cj4gPiBBcmUgeW91IHN1cmUgdGhhdCAvdXNyL2xpYi9saWJ2aGQuc28uMS4wIGlzIHRoZSBz
YW1lIG9uZSB5b3UganVzdCBidWlsdAo+ID4gYW5kIGxpbmtlZCBhZ2FpbnN0PyBJcyB0aGVyZSBh
IGNoYW5jZSB5b3UgaGF2ZSBsaW5rZWQgYWdhaW5zdCBzb21ldGhpbmcKPiA+IGluIHRoZSBidWls
ZCBkaXJlY3Rvcnkgd2hpY2ggZGlkIG5vdCBnZXQgcHJvcGVybHkgaW5zdGFsbGVkPwo+IAo+IFNv
cnJ5LCBJJ20ganVzdCBzdHVwaWQsIHRvZGF5IEkndmUgcmVhbGl6ZWQgd2hhdCB0aGUgcHJvYmxl
bSB3YXMuIEl0Cj4gd2FzIGxpbmtlZCBhZ2FpbnN0IGFuZCBvbGQgL3Vzci9saWIvbGlidmhkLnNv
IHdoaWNoIHdhcyBub3QgY29tcGlsZWQKPiB3aXRoIC1saWNvbnYuCgpHcmVhdC4KCj4gCj4gPiBS
dW5uaW5nCj4gPiAgICAgICAgb2JqZHVtcCAtcCA8b2JqZWN0PiB8IGVncmVwIE5FRURFRFx8U09O
QU1FCj4gPiBmb3IgdGhlIGxpYnJhcnkgKGJvdGggYnVpbGQgZGlyIGFuZCBpbnN0YWxsZWQgY29w
aWVzKSBhbmQgYmluYXJ5IHdvdWxkCj4gPiBiZSBpbnRlcmVzdGluZy4KPiA+Cj4gPiBJdCBzZWVt
cyBsaWtlIGVpdGhlciB0aGlzIGlzIGEgYnVnIGluIHVDbGliYydzIGR5bmFtaWMgbGlua2VyIG9y
IG15Cj4gPiBleHBlY3RhdGlvbiBvZiBob3cgdGhlc2Ugc29ydHMgb2YgdHJhbnNpdGl2ZSBsaWJy
YXJ5IGRlcGVuZGVuY2llcyB3b3JrCj4gPiBoYXMgYmVlbiBzZXQgdG9vIGhpZ2ggYnkgZ2xpYmMu
Li4KPiA+Cj4gPj4gIEFuZAo+ID4+IHdoYXQncyBtb3N0IHN0cmFuZ2UsIHdoeSBpcyB0aGUgbGlu
ayB0byBsaWJ1dWlkIGtlZXAsIGJ1dCBub3QgdGhlIG9uZQo+ID4+IHRvIGxpYmljb252Pwo+ID4K
PiA+IFllcywgdGhhdCBpcyBzdHJhbmdlLgo+IAo+IEkgc3RpbGwgZG9uJ3QgZ2V0IHRoZSBsaWJ1
dWlkIHRoaW5nLCBidXQgaXQgd29ya3MganVzdCBmaW5lIG5vdy4KClByZXN1bWFibHkgdGhlIG9s
ZCBsaWJ2aGQuc28gbm90IGNvbXBpbGVkIGFnYWluc3QgLWxpY29udiBfd2FzXyBjb21waWxlZAp3
aXRoIC1sdXVpZC4KCklhbi4KCj4gCj4gPiBJYW4uCj4gPgoKCgpfX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1k
ZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tCmh0dHA6Ly9saXN0cy54ZW5zb3VyY2UuY29tL3hlbi1k
ZXZlbAo=

From xen-devel-bounces@lists.xensource.com Wed Dec 21 10:36:34 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 10:36:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdJX3-0006d6-Ro; Wed, 21 Dec 2011 10:36:21 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <xiantao.zhang@intel.com>) id 1RdJX2-0006d1-5j
	for xen-devel@lists.xensource.com; Wed, 21 Dec 2011 10:36:20 +0000
X-Env-Sender: xiantao.zhang@intel.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1324463732!8232103!1
X-Originating-IP: [143.182.124.37]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjE1MTQx\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5661 invoked from network); 21 Dec 2011 10:35:33 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37)
	by server-14.tower-21.messagelabs.com with SMTP;
	21 Dec 2011 10:35:33 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga102.ch.intel.com with ESMTP; 21 Dec 2011 02:35:32 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="88049622"
Received: from pgsmsx602.gar.corp.intel.com ([10.221.43.81])
	by azsmga001.ch.intel.com with ESMTP; 21 Dec 2011 02:35:30 -0800
Received: from pgsmsx509.gar.corp.intel.com (172.30.13.17) by
	pgsmsx602.gar.corp.intel.com (10.221.43.81) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Wed, 21 Dec 2011 18:34:04 +0800
Received: from shsmsx601.ccr.corp.intel.com (10.239.4.112) by
	PGSMSX509.gar.corp.intel.com (172.30.13.17) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Wed, 21 Dec 2011 18:34:04 +0800
Received: from shsmsx502.ccr.corp.intel.com ([10.239.4.96]) by
	shsmsx601.ccr.corp.intel.com ([10.239.4.112]) with mapi;
	Wed, 21 Dec 2011 18:34:02 +0800
From: "Zhang, Xiantao" <xiantao.zhang@intel.com>
To: "Shan, Haitao" <haitao.shan@intel.com>, Konrad Rzeszutek Wilk
	<konrad@darnok.org>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>, "konrad.wilk@oracle.com"
	<konrad.wilk@oracle.com>, "George.Dunlap@eu.citrix.com"
	<George.Dunlap@eu.citrix.com>, "keir@xen.org" <keir@xen.org>,
	"andrew.thomas@oracle.com" <andrew.thomas@oracle.com>
Date: Wed, 21 Dec 2011 18:34:02 +0800
Thread-Topic: [Xen-devel] issues with PLE and/or scheduler.
Thread-Index: Acy/WC58GrEeWsJBTKeBU9VJiBfb5QAJ2kbQABFXDVA=
Message-ID: <BC00F5384FCFC9499AF06F92E8B78A9E2890487CF5@shsmsx502.ccr.corp.intel.com>
References: <20111220204107.GA768@andromeda.dapyr.net>
	<20111220204151.GB768@andromeda.dapyr.net>
	<04F972F38B3C4E4E91C4697DA8BF9F5286B2029C29@shsmsx502.ccr.corp.intel.com>
In-Reply-To: <04F972F38B3C4E4E91C4697DA8BF9F5286B2029C29@shsmsx502.ccr.corp.intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Subject: Re: [Xen-devel] issues with PLE and/or scheduler.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

diff -r 381ab77db71a xen/arch/x86/hvm/vpt.c
--- a/xen/arch/x86/hvm/vpt.c    Mon Apr 18 10:10:02 2011 +0100
+++ b/xen/arch/x86/hvm/vpt.c    Thu Dec 22 05:54:54 2011 +0800
@@ -129,7 +129,7 @@
     if ( missed_ticks <= 0 )
         return;

-    missed_ticks = missed_ticks / (s_time_t) pt->period + 1;
+    missed_ticks = missed_ticks / (s_time_t) pt->period;
     if ( mode_is(pt->vcpu->domain, no_missed_ticks_pending) )
         pt->do_not_freeze = !pt->pending_intr_nr;
     else

Anyone can explain the above "plus one" logic ?   why assume at least one tick is missed in pt_process_missed_ticks ?  

In the guest kernel,  ioapic's check_timer logic is used to determine how to set IRQ0, and it uses mdelay to delay 10 ticks totally.  If kernel can receive 4+ ticks during the delay, kernel deems IRQ0 is routed correctly through ioapic.  
Unfortunately,  mdelay is implemented as a tight pause loop,  when PLE is enabled,  the tight pause loop will trigger PLE vmexit.  In the PLE vmexit handler, scheduler yields the CPU, but the yield operation triggers  guest's time save/restore logic, 
eventually pt_process_missed_ticks gets called.   Once pt_process_missed_ticks is called,  pt->scheduled is plused by one pt->period due to the above "plus one" logic.   
By default, ple_window is 4096,  so each 4096 cycles in guest's mdelay  triggers one  PLE vmexit,  and each vmexit delays  the vpt timer by one pt->period, so the vpt timer maybe never be fired during the guest's delay.   This  is why jiffies is not increased during the 10-tick mdelay.  

Thanks!
Xiantao 





-----Original Message-----
From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Shan, Haitao
Sent: Wednesday, December 21, 2011 9:28 AM
To: Konrad Rzeszutek Wilk; xen-devel@lists.xensource.com; konrad.wilk@oracle.com; George.Dunlap@eu.citrix.com; keir@xen.org; andrew.thomas@oracle.com
Subject: Re: [Xen-devel] issues with PLE and/or scheduler.

We have reproduced your problem locally and are looking into this issue. It seems "PLE with timer mode 2" will trigger the issue. We can post our findings as soon as possible.

Shan Haitao

> -----Original Message-----
> From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel- 
> bounces@lists.xensource.com] On Behalf Of Konrad Rzeszutek Wilk
> Sent: Wednesday, December 21, 2011 4:42 AM
> To: xen-devel@lists.xensource.com; konrad.wilk@oracle.com; 
> George.Dunlap@eu.citrix.com; keir@xen.org; andrew.thomas@oracle.com
> Subject: Re: [Xen-devel] issues with PLE and/or scheduler.
> 
> On Tue, Dec 20, 2011 at 04:41:07PM -0400, Konrad Rzeszutek Wilk wrote:
> > Hey folks,
> >
> > I am sending this on behalf of Andrew since our internal email 
> > system is dropping all xen-devel mailing lists :-(
> 
> <hits his head> And I forgot to CC andrew on it. Added here.
> >
> > Anyhow:
> >
> > This is with xen-4.1-testing cs 23201:1c89f7d29fbb and using the 
> > default "credit" scheduler.
> >
> > I've run into an interesting issue with HVM guests which make use of 
> > Pause Loop Exiting (ie. on westmere systems; and also on romley
> > systems):  after yielding the cpu, guests don't seem to receive 
> > timer interrupts correctly..
> >
> > Some background: for historical reasons (ie old templates) we boot 
> > OL/RHEL guests with the following settings:
> >
> > kernel parameters: clock=pit nohpet nopmtimer
> > vm.cfg: timer_mode = 2
> >
> > With PLE enabled, 2.6.32 guests will crash early on with:
> >  ..MP-BIOS bug: 8254 timer not connected to IO-APIC  # a few lines 
> > omitted..
> >  Kernel panic - not syncing: IO-APIC + timer doesn't work!  Boot 
> > with apic=debug
> >
> > While 2.6.18-238 (ie OL/RHEL5u6) will fail to find the timer, but 
> > continue and lock up in the serial line initialization.
> >
> >  ..MP-BIOS bug: 8254 timer not connected to IO-APIC  # continues 
> > until lock up here:
> >  Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing 
> > enabled
> >
> > Instrumenting the 2.6.32 code (ie timer_irq_works()) shows that 
> > jiffies isn't advancing (or only 1 or 2 ticks are being received, 
> > which is insufficient for "working"). This is on a "quiet" system 
> > with
no
> other activity.
> > So, even though the guest has voluntarily yielded the cpu (through 
> > PLE), I would still expect it to receive every clock tick (even with
> > timer_mode=2) as there is no other work to do on the system.
> >
> > Disabling PLE allows both 2.6.18 and 2.6.32 guests to boot.. [As an 
> > aside, so does setting ple_gap to 41 (ie prior to 
> > 21355:727ccaaa6cce)
> > -- the perf counters show no exits happening, so this is equivalent 
> > to disabling PLE.]
> >
> > I'm hoping someone who knows the scheduler well will be able to 
> > quickly decide whether this is a bug or a feature...
> >
> > Andrew
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 21 10:36:34 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 10:36:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdJX3-0006d6-Ro; Wed, 21 Dec 2011 10:36:21 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <xiantao.zhang@intel.com>) id 1RdJX2-0006d1-5j
	for xen-devel@lists.xensource.com; Wed, 21 Dec 2011 10:36:20 +0000
X-Env-Sender: xiantao.zhang@intel.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1324463732!8232103!1
X-Originating-IP: [143.182.124.37]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjE1MTQx\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5661 invoked from network); 21 Dec 2011 10:35:33 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37)
	by server-14.tower-21.messagelabs.com with SMTP;
	21 Dec 2011 10:35:33 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga102.ch.intel.com with ESMTP; 21 Dec 2011 02:35:32 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="88049622"
Received: from pgsmsx602.gar.corp.intel.com ([10.221.43.81])
	by azsmga001.ch.intel.com with ESMTP; 21 Dec 2011 02:35:30 -0800
Received: from pgsmsx509.gar.corp.intel.com (172.30.13.17) by
	pgsmsx602.gar.corp.intel.com (10.221.43.81) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Wed, 21 Dec 2011 18:34:04 +0800
Received: from shsmsx601.ccr.corp.intel.com (10.239.4.112) by
	PGSMSX509.gar.corp.intel.com (172.30.13.17) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Wed, 21 Dec 2011 18:34:04 +0800
Received: from shsmsx502.ccr.corp.intel.com ([10.239.4.96]) by
	shsmsx601.ccr.corp.intel.com ([10.239.4.112]) with mapi;
	Wed, 21 Dec 2011 18:34:02 +0800
From: "Zhang, Xiantao" <xiantao.zhang@intel.com>
To: "Shan, Haitao" <haitao.shan@intel.com>, Konrad Rzeszutek Wilk
	<konrad@darnok.org>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>, "konrad.wilk@oracle.com"
	<konrad.wilk@oracle.com>, "George.Dunlap@eu.citrix.com"
	<George.Dunlap@eu.citrix.com>, "keir@xen.org" <keir@xen.org>,
	"andrew.thomas@oracle.com" <andrew.thomas@oracle.com>
Date: Wed, 21 Dec 2011 18:34:02 +0800
Thread-Topic: [Xen-devel] issues with PLE and/or scheduler.
Thread-Index: Acy/WC58GrEeWsJBTKeBU9VJiBfb5QAJ2kbQABFXDVA=
Message-ID: <BC00F5384FCFC9499AF06F92E8B78A9E2890487CF5@shsmsx502.ccr.corp.intel.com>
References: <20111220204107.GA768@andromeda.dapyr.net>
	<20111220204151.GB768@andromeda.dapyr.net>
	<04F972F38B3C4E4E91C4697DA8BF9F5286B2029C29@shsmsx502.ccr.corp.intel.com>
In-Reply-To: <04F972F38B3C4E4E91C4697DA8BF9F5286B2029C29@shsmsx502.ccr.corp.intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Subject: Re: [Xen-devel] issues with PLE and/or scheduler.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

diff -r 381ab77db71a xen/arch/x86/hvm/vpt.c
--- a/xen/arch/x86/hvm/vpt.c    Mon Apr 18 10:10:02 2011 +0100
+++ b/xen/arch/x86/hvm/vpt.c    Thu Dec 22 05:54:54 2011 +0800
@@ -129,7 +129,7 @@
     if ( missed_ticks <= 0 )
         return;

-    missed_ticks = missed_ticks / (s_time_t) pt->period + 1;
+    missed_ticks = missed_ticks / (s_time_t) pt->period;
     if ( mode_is(pt->vcpu->domain, no_missed_ticks_pending) )
         pt->do_not_freeze = !pt->pending_intr_nr;
     else

Anyone can explain the above "plus one" logic ?   why assume at least one tick is missed in pt_process_missed_ticks ?  

In the guest kernel,  ioapic's check_timer logic is used to determine how to set IRQ0, and it uses mdelay to delay 10 ticks totally.  If kernel can receive 4+ ticks during the delay, kernel deems IRQ0 is routed correctly through ioapic.  
Unfortunately,  mdelay is implemented as a tight pause loop,  when PLE is enabled,  the tight pause loop will trigger PLE vmexit.  In the PLE vmexit handler, scheduler yields the CPU, but the yield operation triggers  guest's time save/restore logic, 
eventually pt_process_missed_ticks gets called.   Once pt_process_missed_ticks is called,  pt->scheduled is plused by one pt->period due to the above "plus one" logic.   
By default, ple_window is 4096,  so each 4096 cycles in guest's mdelay  triggers one  PLE vmexit,  and each vmexit delays  the vpt timer by one pt->period, so the vpt timer maybe never be fired during the guest's delay.   This  is why jiffies is not increased during the 10-tick mdelay.  

Thanks!
Xiantao 





-----Original Message-----
From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Shan, Haitao
Sent: Wednesday, December 21, 2011 9:28 AM
To: Konrad Rzeszutek Wilk; xen-devel@lists.xensource.com; konrad.wilk@oracle.com; George.Dunlap@eu.citrix.com; keir@xen.org; andrew.thomas@oracle.com
Subject: Re: [Xen-devel] issues with PLE and/or scheduler.

We have reproduced your problem locally and are looking into this issue. It seems "PLE with timer mode 2" will trigger the issue. We can post our findings as soon as possible.

Shan Haitao

> -----Original Message-----
> From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel- 
> bounces@lists.xensource.com] On Behalf Of Konrad Rzeszutek Wilk
> Sent: Wednesday, December 21, 2011 4:42 AM
> To: xen-devel@lists.xensource.com; konrad.wilk@oracle.com; 
> George.Dunlap@eu.citrix.com; keir@xen.org; andrew.thomas@oracle.com
> Subject: Re: [Xen-devel] issues with PLE and/or scheduler.
> 
> On Tue, Dec 20, 2011 at 04:41:07PM -0400, Konrad Rzeszutek Wilk wrote:
> > Hey folks,
> >
> > I am sending this on behalf of Andrew since our internal email 
> > system is dropping all xen-devel mailing lists :-(
> 
> <hits his head> And I forgot to CC andrew on it. Added here.
> >
> > Anyhow:
> >
> > This is with xen-4.1-testing cs 23201:1c89f7d29fbb and using the 
> > default "credit" scheduler.
> >
> > I've run into an interesting issue with HVM guests which make use of 
> > Pause Loop Exiting (ie. on westmere systems; and also on romley
> > systems):  after yielding the cpu, guests don't seem to receive 
> > timer interrupts correctly..
> >
> > Some background: for historical reasons (ie old templates) we boot 
> > OL/RHEL guests with the following settings:
> >
> > kernel parameters: clock=pit nohpet nopmtimer
> > vm.cfg: timer_mode = 2
> >
> > With PLE enabled, 2.6.32 guests will crash early on with:
> >  ..MP-BIOS bug: 8254 timer not connected to IO-APIC  # a few lines 
> > omitted..
> >  Kernel panic - not syncing: IO-APIC + timer doesn't work!  Boot 
> > with apic=debug
> >
> > While 2.6.18-238 (ie OL/RHEL5u6) will fail to find the timer, but 
> > continue and lock up in the serial line initialization.
> >
> >  ..MP-BIOS bug: 8254 timer not connected to IO-APIC  # continues 
> > until lock up here:
> >  Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing 
> > enabled
> >
> > Instrumenting the 2.6.32 code (ie timer_irq_works()) shows that 
> > jiffies isn't advancing (or only 1 or 2 ticks are being received, 
> > which is insufficient for "working"). This is on a "quiet" system 
> > with
no
> other activity.
> > So, even though the guest has voluntarily yielded the cpu (through 
> > PLE), I would still expect it to receive every clock tick (even with
> > timer_mode=2) as there is no other work to do on the system.
> >
> > Disabling PLE allows both 2.6.18 and 2.6.32 guests to boot.. [As an 
> > aside, so does setting ple_gap to 41 (ie prior to 
> > 21355:727ccaaa6cce)
> > -- the perf counters show no exits happening, so this is equivalent 
> > to disabling PLE.]
> >
> > I'm hoping someone who knows the scheduler well will be able to 
> > quickly decide whether this is a bug or a feature...
> >
> > Andrew
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 21 10:49:29 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 10:49:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdJjV-0006qs-CK; Wed, 21 Dec 2011 10:49:13 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RdJjT-0006qi-Ln
	for xen-devel@lists.xensource.com; Wed, 21 Dec 2011 10:49:11 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1324464512!57559036!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjQ3MzY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13421 invoked from network); 21 Dec 2011 10:48:33 -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;
	21 Dec 2011 10:48:33 -0000
X-IronPort-AV: E=Sophos;i="4.71,387,1320642000"; d="scan'208";a="174984002"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Dec 2011 05:49:08 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Wed, 21 Dec 2011 05:49:08 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pBLAn58V031827;	Wed, 21 Dec 2011 02:49:07 -0800
MIME-Version: 1.0
X-Mercurial-Node: 311aa2b2b8d137e73888a3ca07096f4670edcca2
Message-ID: <311aa2b2b8d137e73888.1324464546@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1324464545@cosworth.uk.xensource.com>
References: <patchbomb.1324464545@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Wed, 21 Dec 2011 10:49:06 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 1 of 2 V3] libxl: split libxl_domain_shutdown
 into libxl_domain_shutdown & libxl_domain_reboot
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1324464431 0
# Node ID 311aa2b2b8d137e73888a3ca07096f4670edcca2
# Parent  4656f8a68cc1b0d1353fb744b601437b3a0c4bfe
libxl: split libxl_domain_shutdown into libxl_domain_shutdown & libxl_domain_reboot

The other integer request types which shutdown supported are not useful. Specifically:

 * "suspend" is not usable via this interface since it requires other
   scaffolding, libxl_domain_suspend provides this already.
 * "halt" is the same as "poweroff".
 * "crash" is unused and at least Linux does not implement it. If a user
   steps forward then libxl_domain_crash is trivial to add.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 4656f8a68cc1 -r 311aa2b2b8d1 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Wed Dec 21 10:46:26 2011 +0000
+++ b/tools/libxl/libxl.c	Wed Dec 21 10:47:11 2011 +0000
@@ -594,38 +594,38 @@ int libxl__domain_pvcontrol_write(libxl_
     return libxl__xs_write(gc, t, shutdown_path, "%s", cmd);
 }
 
-static char *req_table[] = {
-    [0] = "poweroff",
-    [1] = "reboot",
-    [2] = "suspend",
-    [3] = "crash",
-    [4] = "halt",
-};
-
-int libxl_domain_shutdown(libxl_ctx *ctx, uint32_t domid, int req)
+static int libxl__domain_pvcontrol(libxl__gc *gc, uint32_t domid,
+                                   const char *cmd)
+{
+    int ret;
+
+    ret = libxl__domain_pvcontrol_available(gc, domid);
+    if (ret < 0)
+        return ret;
+
+    if (!ret) {
+        LIBXL__LOG(CTX, LIBXL__LOG_ERROR,
+                   "PV control interface not available\n");
+        return ERROR_FAIL;
+    }
+
+    return libxl__domain_pvcontrol_write(gc, XBT_NULL, domid, cmd);
+}
+
+int libxl_domain_shutdown(libxl_ctx *ctx, uint32_t domid)
 {
     GC_INIT(ctx);
     int ret;
-
-    if (req > ARRAY_SIZE(req_table)) {
-        GC_FREE;
-        return ERROR_INVAL;
-    }
-
-    ret = libxl__domain_pvcontrol_available(gc, domid);
-    if (ret < 0)
-        goto out;
-
-    if (!ret) {
-        LIBXL__LOG(CTX, LIBXL__LOG_ERROR, "PV shutdown control not available:"
-                   " graceful shutdown not possible, use destroy");
-        ret = ERROR_FAIL;
-        goto out;
-    }
-
-    ret = libxl__domain_pvcontrol_write(gc, XBT_NULL, domid, req_table[req]);
-
-out:
+    ret = libxl__domain_pvcontrol(gc, domid, "poweroff");
+    GC_FREE;
+    return ret;
+}
+
+int libxl_domain_reboot(libxl_ctx *ctx, uint32_t domid)
+{
+    GC_INIT(ctx);
+    int ret;
+    ret = libxl__domain_pvcontrol(gc, domid, "reboot");
     GC_FREE;
     return ret;
 }
diff -r 4656f8a68cc1 -r 311aa2b2b8d1 tools/libxl/libxl.h
--- a/tools/libxl/libxl.h	Wed Dec 21 10:46:26 2011 +0000
+++ b/tools/libxl/libxl.h	Wed Dec 21 10:47:11 2011 +0000
@@ -268,7 +268,8 @@ void libxl_domain_config_dispose(libxl_d
 int libxl_domain_suspend(libxl_ctx *ctx, libxl_domain_suspend_info *info,
                           uint32_t domid, int fd);
 int libxl_domain_resume(libxl_ctx *ctx, uint32_t domid);
-int libxl_domain_shutdown(libxl_ctx *ctx, uint32_t domid, int req);
+int libxl_domain_shutdown(libxl_ctx *ctx, uint32_t domid);
+int libxl_domain_reboot(libxl_ctx *ctx, uint32_t domid);
 int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid);
 int libxl_domain_preserve(libxl_ctx *ctx, uint32_t domid, libxl_domain_create_info *info, const char *name_suffix, libxl_uuid new_uuid);
 
diff -r 4656f8a68cc1 -r 311aa2b2b8d1 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Wed Dec 21 10:46:26 2011 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Wed Dec 21 10:47:11 2011 +0000
@@ -2265,7 +2265,7 @@ static void shutdown_domain(const char *
     int rc;
 
     find_domain(p);
-    rc=libxl_domain_shutdown(ctx, domid, 0);
+    rc=libxl_domain_shutdown(ctx, domid);
     if (rc) { fprintf(stderr,"shutdown failed (rc=%d)\n",rc);exit(-1); }
 
     if (wait) {
@@ -2307,7 +2307,7 @@ static void reboot_domain(const char *p)
 {
     int rc;
     find_domain(p);
-    rc=libxl_domain_shutdown(ctx, domid, 1);
+    rc=libxl_domain_reboot(ctx, domid);
     if (rc) { fprintf(stderr,"reboot failed (rc=%d)\n",rc);exit(-1); }
 }
 
diff -r 4656f8a68cc1 -r 311aa2b2b8d1 tools/python/xen/lowlevel/xl/xl.c
--- a/tools/python/xen/lowlevel/xl/xl.c	Wed Dec 21 10:46:26 2011 +0000
+++ b/tools/python/xen/lowlevel/xl/xl.c	Wed Dec 21 10:47:11 2011 +0000
@@ -424,10 +424,10 @@ static PyObject *pyxl_domid_to_name(XlOb
 
 static PyObject *pyxl_domain_shutdown(XlObject *self, PyObject *args)
 {
-    int domid, req = 0;
-    if ( !PyArg_ParseTuple(args, "i|i", &domid, &req) )
+    int domid;
+    if ( !PyArg_ParseTuple(args, "i", &domid) )
         return NULL;
-    if ( libxl_domain_shutdown(self->ctx, domid, req) ) {
+    if ( libxl_domain_shutdown(self->ctx, domid) ) {
         PyErr_SetString(xl_error_obj, "cannot shutdown domain");
         return NULL;
     }
@@ -435,6 +435,19 @@ static PyObject *pyxl_domain_shutdown(Xl
     return Py_None;
 }
 
+static PyObject *pyxl_domain_reboot(XlObject *self, PyObject *args)
+{
+    int domid;
+    if ( !PyArg_ParseTuple(args, "i", &domid) )
+        return NULL;
+    if ( libxl_domain_reboot(self->ctx, domid) ) {
+        PyErr_SetString(xl_error_obj, "cannot reboot domain");
+        return NULL;
+    }
+    Py_INCREF(Py_None);
+    return Py_None;
+}
+
 static PyObject *pyxl_domain_destroy(XlObject *self, PyObject *args)
 {
     int domid;
@@ -637,6 +650,8 @@ static PyMethodDef pyxl_methods[] = {
          "Retrieve name from domain-id"},
     {"domain_shutdown", (PyCFunction)pyxl_domain_shutdown, METH_VARARGS,
          "Shutdown a domain"},
+    {"domain_reboot", (PyCFunction)pyxl_domain_reboot, METH_VARARGS,
+         "Reboot a domain"},
     {"domain_destroy", (PyCFunction)pyxl_domain_destroy, METH_VARARGS,
          "Destroy a domain"},
     {"domain_pause", (PyCFunction)pyxl_domain_pause, METH_VARARGS,

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 21 10:49:29 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 10:49:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdJjV-0006qs-CK; Wed, 21 Dec 2011 10:49:13 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RdJjT-0006qi-Ln
	for xen-devel@lists.xensource.com; Wed, 21 Dec 2011 10:49:11 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1324464512!57559036!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjQ3MzY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13421 invoked from network); 21 Dec 2011 10:48:33 -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;
	21 Dec 2011 10:48:33 -0000
X-IronPort-AV: E=Sophos;i="4.71,387,1320642000"; d="scan'208";a="174984002"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Dec 2011 05:49:08 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Wed, 21 Dec 2011 05:49:08 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pBLAn58V031827;	Wed, 21 Dec 2011 02:49:07 -0800
MIME-Version: 1.0
X-Mercurial-Node: 311aa2b2b8d137e73888a3ca07096f4670edcca2
Message-ID: <311aa2b2b8d137e73888.1324464546@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1324464545@cosworth.uk.xensource.com>
References: <patchbomb.1324464545@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Wed, 21 Dec 2011 10:49:06 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 1 of 2 V3] libxl: split libxl_domain_shutdown
 into libxl_domain_shutdown & libxl_domain_reboot
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1324464431 0
# Node ID 311aa2b2b8d137e73888a3ca07096f4670edcca2
# Parent  4656f8a68cc1b0d1353fb744b601437b3a0c4bfe
libxl: split libxl_domain_shutdown into libxl_domain_shutdown & libxl_domain_reboot

The other integer request types which shutdown supported are not useful. Specifically:

 * "suspend" is not usable via this interface since it requires other
   scaffolding, libxl_domain_suspend provides this already.
 * "halt" is the same as "poweroff".
 * "crash" is unused and at least Linux does not implement it. If a user
   steps forward then libxl_domain_crash is trivial to add.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 4656f8a68cc1 -r 311aa2b2b8d1 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Wed Dec 21 10:46:26 2011 +0000
+++ b/tools/libxl/libxl.c	Wed Dec 21 10:47:11 2011 +0000
@@ -594,38 +594,38 @@ int libxl__domain_pvcontrol_write(libxl_
     return libxl__xs_write(gc, t, shutdown_path, "%s", cmd);
 }
 
-static char *req_table[] = {
-    [0] = "poweroff",
-    [1] = "reboot",
-    [2] = "suspend",
-    [3] = "crash",
-    [4] = "halt",
-};
-
-int libxl_domain_shutdown(libxl_ctx *ctx, uint32_t domid, int req)
+static int libxl__domain_pvcontrol(libxl__gc *gc, uint32_t domid,
+                                   const char *cmd)
+{
+    int ret;
+
+    ret = libxl__domain_pvcontrol_available(gc, domid);
+    if (ret < 0)
+        return ret;
+
+    if (!ret) {
+        LIBXL__LOG(CTX, LIBXL__LOG_ERROR,
+                   "PV control interface not available\n");
+        return ERROR_FAIL;
+    }
+
+    return libxl__domain_pvcontrol_write(gc, XBT_NULL, domid, cmd);
+}
+
+int libxl_domain_shutdown(libxl_ctx *ctx, uint32_t domid)
 {
     GC_INIT(ctx);
     int ret;
-
-    if (req > ARRAY_SIZE(req_table)) {
-        GC_FREE;
-        return ERROR_INVAL;
-    }
-
-    ret = libxl__domain_pvcontrol_available(gc, domid);
-    if (ret < 0)
-        goto out;
-
-    if (!ret) {
-        LIBXL__LOG(CTX, LIBXL__LOG_ERROR, "PV shutdown control not available:"
-                   " graceful shutdown not possible, use destroy");
-        ret = ERROR_FAIL;
-        goto out;
-    }
-
-    ret = libxl__domain_pvcontrol_write(gc, XBT_NULL, domid, req_table[req]);
-
-out:
+    ret = libxl__domain_pvcontrol(gc, domid, "poweroff");
+    GC_FREE;
+    return ret;
+}
+
+int libxl_domain_reboot(libxl_ctx *ctx, uint32_t domid)
+{
+    GC_INIT(ctx);
+    int ret;
+    ret = libxl__domain_pvcontrol(gc, domid, "reboot");
     GC_FREE;
     return ret;
 }
diff -r 4656f8a68cc1 -r 311aa2b2b8d1 tools/libxl/libxl.h
--- a/tools/libxl/libxl.h	Wed Dec 21 10:46:26 2011 +0000
+++ b/tools/libxl/libxl.h	Wed Dec 21 10:47:11 2011 +0000
@@ -268,7 +268,8 @@ void libxl_domain_config_dispose(libxl_d
 int libxl_domain_suspend(libxl_ctx *ctx, libxl_domain_suspend_info *info,
                           uint32_t domid, int fd);
 int libxl_domain_resume(libxl_ctx *ctx, uint32_t domid);
-int libxl_domain_shutdown(libxl_ctx *ctx, uint32_t domid, int req);
+int libxl_domain_shutdown(libxl_ctx *ctx, uint32_t domid);
+int libxl_domain_reboot(libxl_ctx *ctx, uint32_t domid);
 int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid);
 int libxl_domain_preserve(libxl_ctx *ctx, uint32_t domid, libxl_domain_create_info *info, const char *name_suffix, libxl_uuid new_uuid);
 
diff -r 4656f8a68cc1 -r 311aa2b2b8d1 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Wed Dec 21 10:46:26 2011 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Wed Dec 21 10:47:11 2011 +0000
@@ -2265,7 +2265,7 @@ static void shutdown_domain(const char *
     int rc;
 
     find_domain(p);
-    rc=libxl_domain_shutdown(ctx, domid, 0);
+    rc=libxl_domain_shutdown(ctx, domid);
     if (rc) { fprintf(stderr,"shutdown failed (rc=%d)\n",rc);exit(-1); }
 
     if (wait) {
@@ -2307,7 +2307,7 @@ static void reboot_domain(const char *p)
 {
     int rc;
     find_domain(p);
-    rc=libxl_domain_shutdown(ctx, domid, 1);
+    rc=libxl_domain_reboot(ctx, domid);
     if (rc) { fprintf(stderr,"reboot failed (rc=%d)\n",rc);exit(-1); }
 }
 
diff -r 4656f8a68cc1 -r 311aa2b2b8d1 tools/python/xen/lowlevel/xl/xl.c
--- a/tools/python/xen/lowlevel/xl/xl.c	Wed Dec 21 10:46:26 2011 +0000
+++ b/tools/python/xen/lowlevel/xl/xl.c	Wed Dec 21 10:47:11 2011 +0000
@@ -424,10 +424,10 @@ static PyObject *pyxl_domid_to_name(XlOb
 
 static PyObject *pyxl_domain_shutdown(XlObject *self, PyObject *args)
 {
-    int domid, req = 0;
-    if ( !PyArg_ParseTuple(args, "i|i", &domid, &req) )
+    int domid;
+    if ( !PyArg_ParseTuple(args, "i", &domid) )
         return NULL;
-    if ( libxl_domain_shutdown(self->ctx, domid, req) ) {
+    if ( libxl_domain_shutdown(self->ctx, domid) ) {
         PyErr_SetString(xl_error_obj, "cannot shutdown domain");
         return NULL;
     }
@@ -435,6 +435,19 @@ static PyObject *pyxl_domain_shutdown(Xl
     return Py_None;
 }
 
+static PyObject *pyxl_domain_reboot(XlObject *self, PyObject *args)
+{
+    int domid;
+    if ( !PyArg_ParseTuple(args, "i", &domid) )
+        return NULL;
+    if ( libxl_domain_reboot(self->ctx, domid) ) {
+        PyErr_SetString(xl_error_obj, "cannot reboot domain");
+        return NULL;
+    }
+    Py_INCREF(Py_None);
+    return Py_None;
+}
+
 static PyObject *pyxl_domain_destroy(XlObject *self, PyObject *args)
 {
     int domid;
@@ -637,6 +650,8 @@ static PyMethodDef pyxl_methods[] = {
          "Retrieve name from domain-id"},
     {"domain_shutdown", (PyCFunction)pyxl_domain_shutdown, METH_VARARGS,
          "Shutdown a domain"},
+    {"domain_reboot", (PyCFunction)pyxl_domain_reboot, METH_VARARGS,
+         "Reboot a domain"},
     {"domain_destroy", (PyCFunction)pyxl_domain_destroy, METH_VARARGS,
          "Destroy a domain"},
     {"domain_pause", (PyCFunction)pyxl_domain_pause, METH_VARARGS,

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 21 10:49:30 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 10:49:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdJjc-0006rP-5D; Wed, 21 Dec 2011 10:49:20 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RdJja-0006qr-Do
	for xen-devel@lists.xensource.com; Wed, 21 Dec 2011 10:49:18 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1324464548!6394750!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTAxMDQ=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11431 invoked from network); 21 Dec 2011 10:49:11 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Dec 2011 10:49:11 -0000
X-IronPort-AV: E=Sophos;i="4.71,387,1320642000"; d="scan'208";a="20179134"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Dec 2011 05:49:09 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Wed, 21 Dec 2011 05:49:09 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pBLAn58W031827;	Wed, 21 Dec 2011 02:49:08 -0800
MIME-Version: 1.0
X-Mercurial-Node: 3dedf6c82da2bb53d8693fac8b909cdafdfceeca
Message-ID: <3dedf6c82da2bb53d869.1324464547@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1324464545@cosworth.uk.xensource.com>
References: <patchbomb.1324464545@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Wed, 21 Dec 2011 10:49:07 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 2 of 2 V3] libxl: report failure to
 reboot/shutdown due to lackof PV interfaces to caller
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1324464450 0
# Node ID 3dedf6c82da2bb53d8693fac8b909cdafdfceeca
# Parent  311aa2b2b8d137e73888a3ca07096f4670edcca2
libxl: report failure to reboot/shutdown due to lackof PV interfaces to caller

This allow the caller to react as they think is appropriate. xl now prints a
message much like the library did previously, although hopefully somewhat more
informative.

Update the xl(1) man page to be similarly more informative.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 311aa2b2b8d1 -r 3dedf6c82da2 docs/man/xl.pod.1
--- a/docs/man/xl.pod.1	Wed Dec 21 10:47:11 2011 +0000
+++ b/docs/man/xl.pod.1	Wed Dec 21 10:47:30 2011 +0000
@@ -360,7 +360,11 @@ Reboot a domain.  This acts just as if t
 command run from the console.  The command returns as soon as it has
 executed the reboot action, which may be significantly before the
 domain actually reboots.
-It requires PV drivers installed in your guest OS.
+
+For HVM domains this requires PV drivers to be installed in your guest
+OS. If PV drivers are not present but you have configured the guest OS
+to behave appropriately you may be able to use the I<button-press>
+subcommand to trigger a power button press.
 
 The behavior of what happens to a domain when it reboots is set by the
 B<on_reboot> parameter of the domain configuration file when the
@@ -412,9 +416,15 @@ Leave domain running after creating the 
 Gracefully shuts down a domain.  This coordinates with the domain OS
 to perform graceful shutdown, so there is no guarantee that it will
 succeed, and may take a variable length of time depending on what
-services must be shutdown in the domain.  The command returns
-immediately after signally the domain unless that B<-w> flag is used.
-For HVM domains it requires PV drivers to be installed in your guest OS.
+services must be shutdown in the domain.
+
+For HVM domains this requires PV drivers to be installed in your guest
+OS. If PV drivers are not present but you have configured the guest OS
+to behave appropriately you may be able to use the I<button-press>
+subcommand to trigger a power button press.
+
+The command returns immediately after signally the domain unless that
+B<-w> flag is used.
 
 The behavior of what happens to a domain when it reboots is set by the
 B<on_shutdown> parameter of the domain configuration file when the
diff -r 311aa2b2b8d1 -r 3dedf6c82da2 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Wed Dec 21 10:47:11 2011 +0000
+++ b/tools/libxl/libxl.c	Wed Dec 21 10:47:30 2011 +0000
@@ -603,11 +603,8 @@ static int libxl__domain_pvcontrol(libxl
     if (ret < 0)
         return ret;
 
-    if (!ret) {
-        LIBXL__LOG(CTX, LIBXL__LOG_ERROR,
-                   "PV control interface not available\n");
-        return ERROR_FAIL;
-    }
+    if (!ret)
+        return ERROR_NOPARAVIRT;
 
     return libxl__domain_pvcontrol_write(gc, XBT_NULL, domid, cmd);
 }
diff -r 311aa2b2b8d1 -r 3dedf6c82da2 tools/libxl/libxl.h
--- a/tools/libxl/libxl.h	Wed Dec 21 10:47:11 2011 +0000
+++ b/tools/libxl/libxl.h	Wed Dec 21 10:47:30 2011 +0000
@@ -222,6 +222,7 @@ enum {
     ERROR_BADFAIL = -7,
     ERROR_GUEST_TIMEDOUT = -8,
     ERROR_TIMEDOUT = -9,
+    ERROR_NOPARAVIRT = -10,
 };
 
 #define LIBXL_VERSION 0
diff -r 311aa2b2b8d1 -r 3dedf6c82da2 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Wed Dec 21 10:47:11 2011 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Wed Dec 21 10:47:30 2011 +0000
@@ -2266,7 +2266,15 @@ static void shutdown_domain(const char *
 
     find_domain(p);
     rc=libxl_domain_shutdown(ctx, domid);
-    if (rc) { fprintf(stderr,"shutdown failed (rc=%d)\n",rc);exit(-1); }
+    if (rc) {
+        if (rc == ERROR_NOPARAVIRT) {
+            fprintf(stderr, "PV control interface not available:"
+                    " external graceful shutdown not possible.\n");
+            fprintf(stderr, "Use \"xl button-press <dom> power\" or"
+                    " \"xl destroy <dom>\".\n");
+        }
+        fprintf(stderr,"shutdown failed (rc=%d)\n",rc);exit(-1);
+    }
 
     if (wait) {
         libxl_waiter waiter;
@@ -2308,7 +2316,14 @@ static void reboot_domain(const char *p)
     int rc;
     find_domain(p);
     rc=libxl_domain_reboot(ctx, domid);
-    if (rc) { fprintf(stderr,"reboot failed (rc=%d)\n",rc);exit(-1); }
+    if (rc) {
+        if (rc == ERROR_NOPARAVIRT) {
+            fprintf(stderr, "PV control interface not available:"
+                    " external graceful reboot not possible.\n");
+            fprintf(stderr, "Use \"xl button-press <dom> power\" or"
+                    " \"xl destroy <dom>\".\n");
+        }
+        fprintf(stderr,"reboot failed (rc=%d)\n",rc);exit(-1); }
 }
 
 static void list_domains_details(const libxl_dominfo *info, int nb_domain)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 21 10:49:30 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 10:49:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdJjc-0006rP-5D; Wed, 21 Dec 2011 10:49:20 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RdJja-0006qr-Do
	for xen-devel@lists.xensource.com; Wed, 21 Dec 2011 10:49:18 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1324464548!6394750!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTAxMDQ=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11431 invoked from network); 21 Dec 2011 10:49:11 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Dec 2011 10:49:11 -0000
X-IronPort-AV: E=Sophos;i="4.71,387,1320642000"; d="scan'208";a="20179134"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Dec 2011 05:49:09 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Wed, 21 Dec 2011 05:49:09 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pBLAn58W031827;	Wed, 21 Dec 2011 02:49:08 -0800
MIME-Version: 1.0
X-Mercurial-Node: 3dedf6c82da2bb53d8693fac8b909cdafdfceeca
Message-ID: <3dedf6c82da2bb53d869.1324464547@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1324464545@cosworth.uk.xensource.com>
References: <patchbomb.1324464545@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Wed, 21 Dec 2011 10:49:07 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 2 of 2 V3] libxl: report failure to
 reboot/shutdown due to lackof PV interfaces to caller
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1324464450 0
# Node ID 3dedf6c82da2bb53d8693fac8b909cdafdfceeca
# Parent  311aa2b2b8d137e73888a3ca07096f4670edcca2
libxl: report failure to reboot/shutdown due to lackof PV interfaces to caller

This allow the caller to react as they think is appropriate. xl now prints a
message much like the library did previously, although hopefully somewhat more
informative.

Update the xl(1) man page to be similarly more informative.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 311aa2b2b8d1 -r 3dedf6c82da2 docs/man/xl.pod.1
--- a/docs/man/xl.pod.1	Wed Dec 21 10:47:11 2011 +0000
+++ b/docs/man/xl.pod.1	Wed Dec 21 10:47:30 2011 +0000
@@ -360,7 +360,11 @@ Reboot a domain.  This acts just as if t
 command run from the console.  The command returns as soon as it has
 executed the reboot action, which may be significantly before the
 domain actually reboots.
-It requires PV drivers installed in your guest OS.
+
+For HVM domains this requires PV drivers to be installed in your guest
+OS. If PV drivers are not present but you have configured the guest OS
+to behave appropriately you may be able to use the I<button-press>
+subcommand to trigger a power button press.
 
 The behavior of what happens to a domain when it reboots is set by the
 B<on_reboot> parameter of the domain configuration file when the
@@ -412,9 +416,15 @@ Leave domain running after creating the 
 Gracefully shuts down a domain.  This coordinates with the domain OS
 to perform graceful shutdown, so there is no guarantee that it will
 succeed, and may take a variable length of time depending on what
-services must be shutdown in the domain.  The command returns
-immediately after signally the domain unless that B<-w> flag is used.
-For HVM domains it requires PV drivers to be installed in your guest OS.
+services must be shutdown in the domain.
+
+For HVM domains this requires PV drivers to be installed in your guest
+OS. If PV drivers are not present but you have configured the guest OS
+to behave appropriately you may be able to use the I<button-press>
+subcommand to trigger a power button press.
+
+The command returns immediately after signally the domain unless that
+B<-w> flag is used.
 
 The behavior of what happens to a domain when it reboots is set by the
 B<on_shutdown> parameter of the domain configuration file when the
diff -r 311aa2b2b8d1 -r 3dedf6c82da2 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Wed Dec 21 10:47:11 2011 +0000
+++ b/tools/libxl/libxl.c	Wed Dec 21 10:47:30 2011 +0000
@@ -603,11 +603,8 @@ static int libxl__domain_pvcontrol(libxl
     if (ret < 0)
         return ret;
 
-    if (!ret) {
-        LIBXL__LOG(CTX, LIBXL__LOG_ERROR,
-                   "PV control interface not available\n");
-        return ERROR_FAIL;
-    }
+    if (!ret)
+        return ERROR_NOPARAVIRT;
 
     return libxl__domain_pvcontrol_write(gc, XBT_NULL, domid, cmd);
 }
diff -r 311aa2b2b8d1 -r 3dedf6c82da2 tools/libxl/libxl.h
--- a/tools/libxl/libxl.h	Wed Dec 21 10:47:11 2011 +0000
+++ b/tools/libxl/libxl.h	Wed Dec 21 10:47:30 2011 +0000
@@ -222,6 +222,7 @@ enum {
     ERROR_BADFAIL = -7,
     ERROR_GUEST_TIMEDOUT = -8,
     ERROR_TIMEDOUT = -9,
+    ERROR_NOPARAVIRT = -10,
 };
 
 #define LIBXL_VERSION 0
diff -r 311aa2b2b8d1 -r 3dedf6c82da2 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Wed Dec 21 10:47:11 2011 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Wed Dec 21 10:47:30 2011 +0000
@@ -2266,7 +2266,15 @@ static void shutdown_domain(const char *
 
     find_domain(p);
     rc=libxl_domain_shutdown(ctx, domid);
-    if (rc) { fprintf(stderr,"shutdown failed (rc=%d)\n",rc);exit(-1); }
+    if (rc) {
+        if (rc == ERROR_NOPARAVIRT) {
+            fprintf(stderr, "PV control interface not available:"
+                    " external graceful shutdown not possible.\n");
+            fprintf(stderr, "Use \"xl button-press <dom> power\" or"
+                    " \"xl destroy <dom>\".\n");
+        }
+        fprintf(stderr,"shutdown failed (rc=%d)\n",rc);exit(-1);
+    }
 
     if (wait) {
         libxl_waiter waiter;
@@ -2308,7 +2316,14 @@ static void reboot_domain(const char *p)
     int rc;
     find_domain(p);
     rc=libxl_domain_reboot(ctx, domid);
-    if (rc) { fprintf(stderr,"reboot failed (rc=%d)\n",rc);exit(-1); }
+    if (rc) {
+        if (rc == ERROR_NOPARAVIRT) {
+            fprintf(stderr, "PV control interface not available:"
+                    " external graceful reboot not possible.\n");
+            fprintf(stderr, "Use \"xl button-press <dom> power\" or"
+                    " \"xl destroy <dom>\".\n");
+        }
+        fprintf(stderr,"reboot failed (rc=%d)\n",rc);exit(-1); }
 }
 
 static void list_domains_details(const libxl_dominfo *info, int nb_domain)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 21 10:49:30 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 10:49:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdJja-0006rC-P0; Wed, 21 Dec 2011 10:49:18 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RdJjZ-0006qq-IA
	for xen-devel@lists.xensource.com; Wed, 21 Dec 2011 10:49:17 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1324464548!6394750!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTAxMDQ=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11364 invoked from network); 21 Dec 2011 10:49:10 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Dec 2011 10:49:10 -0000
X-IronPort-AV: E=Sophos;i="4.71,387,1320642000"; d="scan'208";a="20179133"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Dec 2011 05:49:08 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Wed, 21 Dec 2011 05:49:07 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pBLAn58U031827;	Wed, 21 Dec 2011 02:49:06 -0800
MIME-Version: 1.0
Message-ID: <patchbomb.1324464545@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Wed, 21 Dec 2011 10:49:05 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 0 of 2 V3] libxl: domain shutdown cleanup
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

The existing libxl_domain_shutdown is a bit odd, it takes an integer
"req" which can be used to indicate one of:
  * [0] = "poweroff",
  * [1] = "reboot",
  * [2] = "suspend",
  * [3] = "crash",
  * [4] = "halt",

"suspend" is not usable via this interface since it requires other
scaffolding, libxl_domain_suspend provides this already.

"halt" is the same as "poweroff".

"crash" is unused and at least Linux does not implement it. If a user
steps forward then libxl_domain_crash is trivial to add.

Therefore split libxl_domain_shutdown into libxl_domain_shutdown and
libxl_domain_reboot corresponding to "poweroff" and "reboot"
respectively.

Also push responsibility for dealing with lack of PV drivers into the
caller and at the same time improve the error messages presented to
the user when they try and "xl shutdown/reboot" an HVM guest with no
PV drivers and the corresponding documentation.

Changes since last time:
  - Remove massive redundancy in libxl_domain_{shutdown,reboot}

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 21 10:49:30 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 10:49:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdJja-0006rC-P0; Wed, 21 Dec 2011 10:49:18 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RdJjZ-0006qq-IA
	for xen-devel@lists.xensource.com; Wed, 21 Dec 2011 10:49:17 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1324464548!6394750!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTAxMDQ=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11364 invoked from network); 21 Dec 2011 10:49:10 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Dec 2011 10:49:10 -0000
X-IronPort-AV: E=Sophos;i="4.71,387,1320642000"; d="scan'208";a="20179133"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Dec 2011 05:49:08 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Wed, 21 Dec 2011 05:49:07 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pBLAn58U031827;	Wed, 21 Dec 2011 02:49:06 -0800
MIME-Version: 1.0
Message-ID: <patchbomb.1324464545@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Wed, 21 Dec 2011 10:49:05 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 0 of 2 V3] libxl: domain shutdown cleanup
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

The existing libxl_domain_shutdown is a bit odd, it takes an integer
"req" which can be used to indicate one of:
  * [0] = "poweroff",
  * [1] = "reboot",
  * [2] = "suspend",
  * [3] = "crash",
  * [4] = "halt",

"suspend" is not usable via this interface since it requires other
scaffolding, libxl_domain_suspend provides this already.

"halt" is the same as "poweroff".

"crash" is unused and at least Linux does not implement it. If a user
steps forward then libxl_domain_crash is trivial to add.

Therefore split libxl_domain_shutdown into libxl_domain_shutdown and
libxl_domain_reboot corresponding to "poweroff" and "reboot"
respectively.

Also push responsibility for dealing with lack of PV drivers into the
caller and at the same time improve the error messages presented to
the user when they try and "xl shutdown/reboot" an HVM guest with no
PV drivers and the corresponding documentation.

Changes since last time:
  - Remove massive redundancy in libxl_domain_{shutdown,reboot}

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 21 11:00:50 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 11:00:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdJuW-0007LX-Cv; Wed, 21 Dec 2011 11:00:36 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <nenolod@dereferenced.org>) id 1RdJuU-0007LS-GZ
	for xen-devel@lists.xensource.com; Wed, 21 Dec 2011 11:00:34 +0000
X-Env-Sender: nenolod@dereferenced.org
X-Msg-Ref: server-2.tower-216.messagelabs.com!1324465226!9624665!1
X-Originating-IP: [209.85.210.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14656 invoked from network); 21 Dec 2011 11:00:28 -0000
Received: from mail-pz0-f43.google.com (HELO mail-pz0-f43.google.com)
	(209.85.210.43)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Dec 2011 11:00:28 -0000
Received: by daec6 with SMTP id c6so29869292dae.30
	for <xen-devel@lists.xensource.com>;
	Wed, 21 Dec 2011 03:00:26 -0800 (PST)
MIME-Version: 1.0
Received: by 10.68.73.105 with SMTP id k9mr11684624pbv.121.1324465226303; Wed,
	21 Dec 2011 03:00:26 -0800 (PST)
Received: by 10.143.142.18 with HTTP; Wed, 21 Dec 2011 03:00:26 -0800 (PST)
In-Reply-To: <14e911353a91702b439b.1324347547@alpine.localdomain>
References: <patchbomb.1324347544@alpine.localdomain>
	<14e911353a91702b439b.1324347547@alpine.localdomain>
Date: Wed, 21 Dec 2011 05:00:26 -0600
Message-ID: <CA+T2pCGZPhLJ1Be28zuYreQcrVNPKvgd9z2HOq2E8CdnYC+a8A@mail.gmail.com>
From: William Pitcock <nenolod@dereferenced.org>
To: Roger Pau Monne <roger.pau@entel.upc.edu>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 3 of 4 v2] build: detect is libiconv is
	present
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi,

On Mon, Dec 19, 2011 at 8:19 PM, Roger Pau Monne
<roger.pau@entel.upc.edu> wrote:
> # HG changeset patch
> # User Roger Pau Monne <roger.pau@entel.upc.edu>
> # Date 1324344612 -3600
> # Node ID 14e911353a91702b439bc06e2a77d67e8bd5f661
> # Parent =A023e1abbd203ca2619103f3e95c6b1ff36be60e38
> build: detect is libiconv is present
>
> Detect if libiconv is present in the system, since we will have to
> link against it when using iconv.
>
> Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>
>
> diff -r 23e1abbd203c -r 14e911353a91 Config.mk
> --- a/Config.mk Tue Dec 20 02:28:34 2011 +0100
> +++ b/Config.mk Tue Dec 20 02:30:12 2011 +0100
> @@ -18,6 +18,8 @@ XEN_TARGET_ARCH =A0 =A0 ?=3D $(XEN_COMPILE_ARC
> =A0XEN_OS =A0 =A0 =A0 =A0 =A0 =A0 =A0?=3D $(shell uname -s)
>
> =A0CONFIG_$(XEN_OS) :=3D y
> +CONFIG_LIBICONV =A0:=3D $(shell grep -q LIBICONV_PLUG /usr/include/iconv=
.h \
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0&& echo 'y' || echo 'n')
>

Please don't check this way, it is not guaranteed to work.  Check
instead for presence of libiconv.so somehow, perhaps using a dummy
program with -liconv or something, or using a construct like:

  test -f /usr/lib/libiconv.so -o -f /lib/libiconv.so -o -f
/usr/local/lib/libiconv.so && echo 'y' || echo 'n'

If upstream removes LIBICONV_PLUG, this check will break.

Otherwise, everything else looks OK to me.

William

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 21 11:00:50 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 11:00:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdJuW-0007LX-Cv; Wed, 21 Dec 2011 11:00:36 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <nenolod@dereferenced.org>) id 1RdJuU-0007LS-GZ
	for xen-devel@lists.xensource.com; Wed, 21 Dec 2011 11:00:34 +0000
X-Env-Sender: nenolod@dereferenced.org
X-Msg-Ref: server-2.tower-216.messagelabs.com!1324465226!9624665!1
X-Originating-IP: [209.85.210.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14656 invoked from network); 21 Dec 2011 11:00:28 -0000
Received: from mail-pz0-f43.google.com (HELO mail-pz0-f43.google.com)
	(209.85.210.43)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Dec 2011 11:00:28 -0000
Received: by daec6 with SMTP id c6so29869292dae.30
	for <xen-devel@lists.xensource.com>;
	Wed, 21 Dec 2011 03:00:26 -0800 (PST)
MIME-Version: 1.0
Received: by 10.68.73.105 with SMTP id k9mr11684624pbv.121.1324465226303; Wed,
	21 Dec 2011 03:00:26 -0800 (PST)
Received: by 10.143.142.18 with HTTP; Wed, 21 Dec 2011 03:00:26 -0800 (PST)
In-Reply-To: <14e911353a91702b439b.1324347547@alpine.localdomain>
References: <patchbomb.1324347544@alpine.localdomain>
	<14e911353a91702b439b.1324347547@alpine.localdomain>
Date: Wed, 21 Dec 2011 05:00:26 -0600
Message-ID: <CA+T2pCGZPhLJ1Be28zuYreQcrVNPKvgd9z2HOq2E8CdnYC+a8A@mail.gmail.com>
From: William Pitcock <nenolod@dereferenced.org>
To: Roger Pau Monne <roger.pau@entel.upc.edu>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 3 of 4 v2] build: detect is libiconv is
	present
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi,

On Mon, Dec 19, 2011 at 8:19 PM, Roger Pau Monne
<roger.pau@entel.upc.edu> wrote:
> # HG changeset patch
> # User Roger Pau Monne <roger.pau@entel.upc.edu>
> # Date 1324344612 -3600
> # Node ID 14e911353a91702b439bc06e2a77d67e8bd5f661
> # Parent =A023e1abbd203ca2619103f3e95c6b1ff36be60e38
> build: detect is libiconv is present
>
> Detect if libiconv is present in the system, since we will have to
> link against it when using iconv.
>
> Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>
>
> diff -r 23e1abbd203c -r 14e911353a91 Config.mk
> --- a/Config.mk Tue Dec 20 02:28:34 2011 +0100
> +++ b/Config.mk Tue Dec 20 02:30:12 2011 +0100
> @@ -18,6 +18,8 @@ XEN_TARGET_ARCH =A0 =A0 ?=3D $(XEN_COMPILE_ARC
> =A0XEN_OS =A0 =A0 =A0 =A0 =A0 =A0 =A0?=3D $(shell uname -s)
>
> =A0CONFIG_$(XEN_OS) :=3D y
> +CONFIG_LIBICONV =A0:=3D $(shell grep -q LIBICONV_PLUG /usr/include/iconv=
.h \
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0&& echo 'y' || echo 'n')
>

Please don't check this way, it is not guaranteed to work.  Check
instead for presence of libiconv.so somehow, perhaps using a dummy
program with -liconv or something, or using a construct like:

  test -f /usr/lib/libiconv.so -o -f /lib/libiconv.so -o -f
/usr/local/lib/libiconv.so && echo 'y' || echo 'n'

If upstream removes LIBICONV_PLUG, this check will break.

Otherwise, everything else looks OK to me.

William

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 21 11:10:29 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 11: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.xensource.com>)
	id 1RdK3n-0007Vg-F9; Wed, 21 Dec 2011 11:10:11 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RdK3m-0007VY-Hk
	for xen-devel@lists.xensource.com; Wed, 21 Dec 2011 11:10:10 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1324465803!8127333!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzcyNA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26990 invoked from network); 21 Dec 2011 11:10:04 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Dec 2011 11:10:04 -0000
X-IronPort-AV: E=Sophos;i="4.71,387,1320624000"; 
   d="scan'208";a="9603951"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Dec 2011 11:10:03 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 21 Dec 2011 11:10:03 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau Monne <roger.pau@entel.upc.edu>
Date: Wed, 21 Dec 2011 11:10:02 +0000
In-Reply-To: <29f5b0afe971335eea4f.1324347545@alpine.localdomain>
References: <patchbomb.1324347544@alpine.localdomain>
	<29f5b0afe971335eea4f.1324347545@alpine.localdomain>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1324465803.7877.15.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "nenolod@dereferenced.org" <nenolod@dereferenced.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 1 of 4 v2] blktap: remove local definitions
 and include byteswap.h
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2011-12-20 at 02:19 +0000, Roger Pau Monne wrote:
> # HG changeset patch
> # User Roger Pau Monne <roger.pau@entel.upc.edu>
> # Date 1324344433 -3600
> # Node ID 29f5b0afe971335eea4f547efed00b132ade5c64
> # Parent  d23344a87ad7d3d3acae83171586358b081e3f4e
> blktap: remove local definitions and include byteswap.h
> 
> Use the same approach as tools/blktap2/include/libvhd.h, remove local
> definitions of bswap* and include byteswap.h.

The end result of this patch isn't quite the same as libvhd.h. There it
does:

        #if defined(__linux__)
        #include <endian.h>
        #include <byteswap.h>
        #elif defined(__NetBSD__)
        #include <sys/endian.h>
        #include <sys/bswap.h>
        #endif

while here we end up with:

        #if defined(__NetBSD__)
        #include <sys/endian.h>
        #include <sys/types.h>
        #elif defined(__OpenBSD__)
        #include <machine/endian.h>
        #define bswap_16(x) swap16(x)
        #define bswap_32(x) swap32(x)
        #define bswap_64(x) swap64(x)
        #else
        #include <byteswap.h>
        #endif
        
I think that last #else should be an explicit #elif defined(__linux__)
for consistency and so that future porters don't wander around looking
for byteswap.h before realising they need a new #elif clause.

>  Also remove the
> HAVE_BYTESWAP_H ifdef, since it was not defined in this context (it's
> defined by QEMU).
> 
> Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>
> 
> diff -r d23344a87ad7 -r 29f5b0afe971 tools/blktap/drivers/bswap.h
> --- a/tools/blktap/drivers/bswap.h	Tue Dec 20 02:21:25 2011 +0100
> +++ b/tools/blktap/drivers/bswap.h	Tue Dec 20 02:27:13 2011 +0100
> @@ -15,43 +15,7 @@
>  #define bswap_64(x) swap64(x)
>  #else
>  
> -#ifdef HAVE_BYTESWAP_H
>  #include <byteswap.h>
> -#else
> -
> -#define bswap_16(x) \
> -({ \
> -	uint16_t __x = (x); \
> -	((uint16_t)( \
> -		(((uint16_t)(__x) & (uint16_t)0x00ffU) << 8) | \
> -		(((uint16_t)(__x) & (uint16_t)0xff00U) >> 8) )); \
> -})
> -
> -#define bswap_32(x) \
> -({ \
> -	uint32_t __x = (x); \
> -	((uint32_t)( \
> -		(((uint32_t)(__x) & (uint32_t)0x000000ffUL) << 24) | \
> -		(((uint32_t)(__x) & (uint32_t)0x0000ff00UL) <<  8) | \
> -		(((uint32_t)(__x) & (uint32_t)0x00ff0000UL) >>  8) | \
> -		(((uint32_t)(__x) & (uint32_t)0xff000000UL) >> 24) )); \
> -})
> -
> -#define bswap_64(x) \
> -({ \
> -	uint64_t __x = (x); \
> -	((uint64_t)( \
> -		(uint64_t)(((uint64_t)(__x) & (uint64_t)0x00000000000000ffULL) << 56) | \
> -		(uint64_t)(((uint64_t)(__x) & (uint64_t)0x000000000000ff00ULL) << 40) | \
> -		(uint64_t)(((uint64_t)(__x) & (uint64_t)0x0000000000ff0000ULL) << 24) | \
> -		(uint64_t)(((uint64_t)(__x) & (uint64_t)0x00000000ff000000ULL) <<  8) | \
> -	        (uint64_t)(((uint64_t)(__x) & (uint64_t)0x000000ff00000000ULL) >>  8) | \
> -		(uint64_t)(((uint64_t)(__x) & (uint64_t)0x0000ff0000000000ULL) >> 24) | \
> -		(uint64_t)(((uint64_t)(__x) & (uint64_t)0x00ff000000000000ULL) >> 40) | \
> -		(uint64_t)(((uint64_t)(__x) & (uint64_t)0xff00000000000000ULL) >> 56) )); \
> -})
> -
> -#endif /* !HAVE_BYTESWAP_H */
>  
>  static inline uint16_t bswap16(uint16_t x)
>  {
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 21 11:10:29 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 11: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.xensource.com>)
	id 1RdK3n-0007Vg-F9; Wed, 21 Dec 2011 11:10:11 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RdK3m-0007VY-Hk
	for xen-devel@lists.xensource.com; Wed, 21 Dec 2011 11:10:10 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1324465803!8127333!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzcyNA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26990 invoked from network); 21 Dec 2011 11:10:04 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Dec 2011 11:10:04 -0000
X-IronPort-AV: E=Sophos;i="4.71,387,1320624000"; 
   d="scan'208";a="9603951"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Dec 2011 11:10:03 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 21 Dec 2011 11:10:03 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau Monne <roger.pau@entel.upc.edu>
Date: Wed, 21 Dec 2011 11:10:02 +0000
In-Reply-To: <29f5b0afe971335eea4f.1324347545@alpine.localdomain>
References: <patchbomb.1324347544@alpine.localdomain>
	<29f5b0afe971335eea4f.1324347545@alpine.localdomain>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1324465803.7877.15.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "nenolod@dereferenced.org" <nenolod@dereferenced.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 1 of 4 v2] blktap: remove local definitions
 and include byteswap.h
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2011-12-20 at 02:19 +0000, Roger Pau Monne wrote:
> # HG changeset patch
> # User Roger Pau Monne <roger.pau@entel.upc.edu>
> # Date 1324344433 -3600
> # Node ID 29f5b0afe971335eea4f547efed00b132ade5c64
> # Parent  d23344a87ad7d3d3acae83171586358b081e3f4e
> blktap: remove local definitions and include byteswap.h
> 
> Use the same approach as tools/blktap2/include/libvhd.h, remove local
> definitions of bswap* and include byteswap.h.

The end result of this patch isn't quite the same as libvhd.h. There it
does:

        #if defined(__linux__)
        #include <endian.h>
        #include <byteswap.h>
        #elif defined(__NetBSD__)
        #include <sys/endian.h>
        #include <sys/bswap.h>
        #endif

while here we end up with:

        #if defined(__NetBSD__)
        #include <sys/endian.h>
        #include <sys/types.h>
        #elif defined(__OpenBSD__)
        #include <machine/endian.h>
        #define bswap_16(x) swap16(x)
        #define bswap_32(x) swap32(x)
        #define bswap_64(x) swap64(x)
        #else
        #include <byteswap.h>
        #endif
        
I think that last #else should be an explicit #elif defined(__linux__)
for consistency and so that future porters don't wander around looking
for byteswap.h before realising they need a new #elif clause.

>  Also remove the
> HAVE_BYTESWAP_H ifdef, since it was not defined in this context (it's
> defined by QEMU).
> 
> Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>
> 
> diff -r d23344a87ad7 -r 29f5b0afe971 tools/blktap/drivers/bswap.h
> --- a/tools/blktap/drivers/bswap.h	Tue Dec 20 02:21:25 2011 +0100
> +++ b/tools/blktap/drivers/bswap.h	Tue Dec 20 02:27:13 2011 +0100
> @@ -15,43 +15,7 @@
>  #define bswap_64(x) swap64(x)
>  #else
>  
> -#ifdef HAVE_BYTESWAP_H
>  #include <byteswap.h>
> -#else
> -
> -#define bswap_16(x) \
> -({ \
> -	uint16_t __x = (x); \
> -	((uint16_t)( \
> -		(((uint16_t)(__x) & (uint16_t)0x00ffU) << 8) | \
> -		(((uint16_t)(__x) & (uint16_t)0xff00U) >> 8) )); \
> -})
> -
> -#define bswap_32(x) \
> -({ \
> -	uint32_t __x = (x); \
> -	((uint32_t)( \
> -		(((uint32_t)(__x) & (uint32_t)0x000000ffUL) << 24) | \
> -		(((uint32_t)(__x) & (uint32_t)0x0000ff00UL) <<  8) | \
> -		(((uint32_t)(__x) & (uint32_t)0x00ff0000UL) >>  8) | \
> -		(((uint32_t)(__x) & (uint32_t)0xff000000UL) >> 24) )); \
> -})
> -
> -#define bswap_64(x) \
> -({ \
> -	uint64_t __x = (x); \
> -	((uint64_t)( \
> -		(uint64_t)(((uint64_t)(__x) & (uint64_t)0x00000000000000ffULL) << 56) | \
> -		(uint64_t)(((uint64_t)(__x) & (uint64_t)0x000000000000ff00ULL) << 40) | \
> -		(uint64_t)(((uint64_t)(__x) & (uint64_t)0x0000000000ff0000ULL) << 24) | \
> -		(uint64_t)(((uint64_t)(__x) & (uint64_t)0x00000000ff000000ULL) <<  8) | \
> -	        (uint64_t)(((uint64_t)(__x) & (uint64_t)0x000000ff00000000ULL) >>  8) | \
> -		(uint64_t)(((uint64_t)(__x) & (uint64_t)0x0000ff0000000000ULL) >> 24) | \
> -		(uint64_t)(((uint64_t)(__x) & (uint64_t)0x00ff000000000000ULL) >> 40) | \
> -		(uint64_t)(((uint64_t)(__x) & (uint64_t)0xff00000000000000ULL) >> 56) )); \
> -})
> -
> -#endif /* !HAVE_BYTESWAP_H */
>  
>  static inline uint16_t bswap16(uint16_t x)
>  {
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 21 11:10:46 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 11:10:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdK44-0007WS-SR; Wed, 21 Dec 2011 11:10:28 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jean.guyader@gmail.com>) id 1RdK43-0007W4-3b
	for xen-devel@lists.xensource.com; Wed, 21 Dec 2011 11:10:27 +0000
X-Env-Sender: jean.guyader@gmail.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1324465809!8068539!1
X-Originating-IP: [209.85.220.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5330 invoked from network); 21 Dec 2011 11:10:20 -0000
Received: from mail-vx0-f171.google.com (HELO mail-vx0-f171.google.com)
	(209.85.220.171)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Dec 2011 11:10:20 -0000
Received: by vcbfl11 with SMTP id fl11so21681532vcb.30
	for <xen-devel@lists.xensource.com>;
	Wed, 21 Dec 2011 03:10:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type:content-transfer-encoding;
	bh=ytkqfD5C8M9ZbnGeqD++/ZfczXoY37V0Bi85qavE1Q0=;
	b=we0n/xDYVkDf74mc9rt9R9rzzu1oDJDrJSCHUJwysVd5A4rEh7cUWn78WTMlVjVZsf
	QIqyVxqRWYf3S15NlmmfpJLWLmcVt8y/geizsO32EHT7Hmq0PguNFG+kNmL5DJh7+658
	yWH/XftezPL8fbPJEyo/Twa1NH0zurYRAgAKQ=
Received: by 10.220.149.10 with SMTP id r10mr3946938vcv.38.1324465804819; Wed,
	21 Dec 2011 03:10:04 -0800 (PST)
MIME-Version: 1.0
Received: by 10.220.156.138 with HTTP; Wed, 21 Dec 2011 03:09:43 -0800 (PST)
In-Reply-To: <CA+T2pCGZPhLJ1Be28zuYreQcrVNPKvgd9z2HOq2E8CdnYC+a8A@mail.gmail.com>
References: <patchbomb.1324347544@alpine.localdomain>
	<14e911353a91702b439b.1324347547@alpine.localdomain>
	<CA+T2pCGZPhLJ1Be28zuYreQcrVNPKvgd9z2HOq2E8CdnYC+a8A@mail.gmail.com>
From: Jean Guyader <jean.guyader@gmail.com>
Date: Wed, 21 Dec 2011 12:09:43 +0100
Message-ID: <CAEBdQ92w=HkomuqXKdTukPjGrGeJNDmrcXUUMWEMYeRqBwU5vA@mail.gmail.com>
To: William Pitcock <nenolod@dereferenced.org>
Cc: Roger Pau Monne <roger.pau@entel.upc.edu>, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 3 of 4 v2] build: detect is libiconv is
	present
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 21 December 2011 12:00, William Pitcock <nenolod@dereferenced.org> wrote:
> Hi,
>
> On Mon, Dec 19, 2011 at 8:19 PM, Roger Pau Monne
> <roger.pau@entel.upc.edu> wrote:
>> # HG changeset patch
>> # User Roger Pau Monne <roger.pau@entel.upc.edu>
>> # Date 1324344612 -3600
>> # Node ID 14e911353a91702b439bc06e2a77d67e8bd5f661
>> # Parent =A023e1abbd203ca2619103f3e95c6b1ff36be60e38
>> build: detect is libiconv is present
>>
>> Detect if libiconv is present in the system, since we will have to
>> link against it when using iconv.
>>
>> Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>
>>
>> diff -r 23e1abbd203c -r 14e911353a91 Config.mk
>> --- a/Config.mk Tue Dec 20 02:28:34 2011 +0100
>> +++ b/Config.mk Tue Dec 20 02:30:12 2011 +0100
>> @@ -18,6 +18,8 @@ XEN_TARGET_ARCH =A0 =A0 ?=3D $(XEN_COMPILE_ARC
>> =A0XEN_OS =A0 =A0 =A0 =A0 =A0 =A0 =A0?=3D $(shell uname -s)
>>
>> =A0CONFIG_$(XEN_OS) :=3D y
>> +CONFIG_LIBICONV =A0:=3D $(shell grep -q LIBICONV_PLUG /usr/include/icon=
v.h \
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0&& echo 'y' || echo 'n')
>>
>
> Please don't check this way, it is not guaranteed to work. =A0Check
> instead for presence of libiconv.so somehow, perhaps using a dummy
> program with -liconv or something, or using a construct like:
>
> =A0test -f /usr/lib/libiconv.so -o -f /lib/libiconv.so -o -f
> /usr/local/lib/libiconv.so && echo 'y' || echo 'n'
>
> If upstream removes LIBICONV_PLUG, this check will break.
>
> Otherwise, everything else looks OK to me.
>

That doesn't work if you do cross compilation, your libraries could
located in a completely different path.

The best way to check for the presence of a library (and this is how
the autotools do it) is to generate a very simple C program that uses
some iconv functions and try to compile it with the currently
configured compiler. If the compilation succeeded that means the
library is present.

Jean

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 21 11:10:46 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 11:10:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdK44-0007WS-SR; Wed, 21 Dec 2011 11:10:28 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jean.guyader@gmail.com>) id 1RdK43-0007W4-3b
	for xen-devel@lists.xensource.com; Wed, 21 Dec 2011 11:10:27 +0000
X-Env-Sender: jean.guyader@gmail.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1324465809!8068539!1
X-Originating-IP: [209.85.220.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5330 invoked from network); 21 Dec 2011 11:10:20 -0000
Received: from mail-vx0-f171.google.com (HELO mail-vx0-f171.google.com)
	(209.85.220.171)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Dec 2011 11:10:20 -0000
Received: by vcbfl11 with SMTP id fl11so21681532vcb.30
	for <xen-devel@lists.xensource.com>;
	Wed, 21 Dec 2011 03:10:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type:content-transfer-encoding;
	bh=ytkqfD5C8M9ZbnGeqD++/ZfczXoY37V0Bi85qavE1Q0=;
	b=we0n/xDYVkDf74mc9rt9R9rzzu1oDJDrJSCHUJwysVd5A4rEh7cUWn78WTMlVjVZsf
	QIqyVxqRWYf3S15NlmmfpJLWLmcVt8y/geizsO32EHT7Hmq0PguNFG+kNmL5DJh7+658
	yWH/XftezPL8fbPJEyo/Twa1NH0zurYRAgAKQ=
Received: by 10.220.149.10 with SMTP id r10mr3946938vcv.38.1324465804819; Wed,
	21 Dec 2011 03:10:04 -0800 (PST)
MIME-Version: 1.0
Received: by 10.220.156.138 with HTTP; Wed, 21 Dec 2011 03:09:43 -0800 (PST)
In-Reply-To: <CA+T2pCGZPhLJ1Be28zuYreQcrVNPKvgd9z2HOq2E8CdnYC+a8A@mail.gmail.com>
References: <patchbomb.1324347544@alpine.localdomain>
	<14e911353a91702b439b.1324347547@alpine.localdomain>
	<CA+T2pCGZPhLJ1Be28zuYreQcrVNPKvgd9z2HOq2E8CdnYC+a8A@mail.gmail.com>
From: Jean Guyader <jean.guyader@gmail.com>
Date: Wed, 21 Dec 2011 12:09:43 +0100
Message-ID: <CAEBdQ92w=HkomuqXKdTukPjGrGeJNDmrcXUUMWEMYeRqBwU5vA@mail.gmail.com>
To: William Pitcock <nenolod@dereferenced.org>
Cc: Roger Pau Monne <roger.pau@entel.upc.edu>, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 3 of 4 v2] build: detect is libiconv is
	present
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 21 December 2011 12:00, William Pitcock <nenolod@dereferenced.org> wrote:
> Hi,
>
> On Mon, Dec 19, 2011 at 8:19 PM, Roger Pau Monne
> <roger.pau@entel.upc.edu> wrote:
>> # HG changeset patch
>> # User Roger Pau Monne <roger.pau@entel.upc.edu>
>> # Date 1324344612 -3600
>> # Node ID 14e911353a91702b439bc06e2a77d67e8bd5f661
>> # Parent =A023e1abbd203ca2619103f3e95c6b1ff36be60e38
>> build: detect is libiconv is present
>>
>> Detect if libiconv is present in the system, since we will have to
>> link against it when using iconv.
>>
>> Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>
>>
>> diff -r 23e1abbd203c -r 14e911353a91 Config.mk
>> --- a/Config.mk Tue Dec 20 02:28:34 2011 +0100
>> +++ b/Config.mk Tue Dec 20 02:30:12 2011 +0100
>> @@ -18,6 +18,8 @@ XEN_TARGET_ARCH =A0 =A0 ?=3D $(XEN_COMPILE_ARC
>> =A0XEN_OS =A0 =A0 =A0 =A0 =A0 =A0 =A0?=3D $(shell uname -s)
>>
>> =A0CONFIG_$(XEN_OS) :=3D y
>> +CONFIG_LIBICONV =A0:=3D $(shell grep -q LIBICONV_PLUG /usr/include/icon=
v.h \
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0&& echo 'y' || echo 'n')
>>
>
> Please don't check this way, it is not guaranteed to work. =A0Check
> instead for presence of libiconv.so somehow, perhaps using a dummy
> program with -liconv or something, or using a construct like:
>
> =A0test -f /usr/lib/libiconv.so -o -f /lib/libiconv.so -o -f
> /usr/local/lib/libiconv.so && echo 'y' || echo 'n'
>
> If upstream removes LIBICONV_PLUG, this check will break.
>
> Otherwise, everything else looks OK to me.
>

That doesn't work if you do cross compilation, your libraries could
located in a completely different path.

The best way to check for the presence of a library (and this is how
the autotools do it) is to generate a very simple C program that uses
some iconv functions and try to compile it with the currently
configured compiler. If the compilation succeeded that means the
library is present.

Jean

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 21 11:23:27 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 11: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.xensource.com>)
	id 1RdKGJ-0007rY-Hi; Wed, 21 Dec 2011 11:23:07 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <gang.wei@intel.com>) id 1RdKGH-0007rT-LS
	for xen-devel@lists.xensource.com; Wed, 21 Dec 2011 11:23:05 +0000
X-Env-Sender: gang.wei@intel.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1324466578!9628974!1
X-Originating-IP: [143.182.124.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjE0MTY3\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21126 invoked from network); 21 Dec 2011 11:22:59 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-2.tower-216.messagelabs.com with SMTP;
	21 Dec 2011 11:22:59 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga101.ch.intel.com with ESMTP; 21 Dec 2011 03:22:57 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="88064224"
Received: from pgsmsx603.gar.corp.intel.com ([10.221.43.87])
	by azsmga001.ch.intel.com with ESMTP; 21 Dec 2011 03:22:56 -0800
Received: from pgsmsx509.gar.corp.intel.com (172.30.13.17) by
	pgsmsx603.gar.corp.intel.com (10.221.43.87) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Wed, 21 Dec 2011 19:22:55 +0800
Received: from shsmsx601.ccr.corp.intel.com (10.239.4.112) by
	PGSMSX509.gar.corp.intel.com (172.30.13.17) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Wed, 21 Dec 2011 19:22:55 +0800
Received: from shsmsx502.ccr.corp.intel.com ([10.239.4.96]) by
	shsmsx601.ccr.corp.intel.com ([10.239.4.112]) with mapi;
	Wed, 21 Dec 2011 19:22:54 +0800
From: "Wei, Gang" <gang.wei@intel.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Wed, 21 Dec 2011 19:22:52 +0800
Thread-Topic: [patch] x86: Add a delay between INIT & SIPIs for AP bring-up
	in X2APIC case
Thread-Index: Acy/0uD62iL7OBXBT0+nwXPeOaB7qg==
Message-ID: <F26D193E20BBDC42A43B611D1BDEDE7135CEEEAE56@shsmsx502.ccr.corp.intel.com>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
acceptlanguage: zh-CN, en-US
Content-Type: multipart/mixed;
	boundary="_002_F26D193E20BBDC42A43B611D1BDEDE7135CEEEAE56shsmsx502ccrc_"
MIME-Version: 1.0
Cc: Keir Fraser <keir@xen.org>, Tim Deegan <Tim.Deegan@citrix.com>, "Cihula,
	Joseph" <joseph.cihula@intel.com>,
	"tboot-devel@lists.sourceforge.net" <tboot-devel@lists.sourceforge.net>,
	Jan Beulich <jbeulich@suse.com>, "Wei, Gang" <gang.wei@intel.com>
Subject: [Xen-devel] [patch] x86: Add a delay between INIT & SIPIs for AP
 bring-up in X2APIC case
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--_002_F26D193E20BBDC42A43B611D1BDEDE7135CEEEAE56shsmsx502ccrc_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Without this delay, Xen could not bring APs up while working with TXT/tboot=
, because tboot need some time in APs to handle INIT before becoming ready =
for receiving SIPIs. (this delay was removed as part of c/s 23724 by Tim De=
egan)

Signed-off-by: Gang Wei <gang.wei@intel.com>

diff -r d1aefee43af1 xen/arch/x86/smpboot.c
--- a/xen/arch/x86/smpboot.c    Wed Dec 21 18:51:31 2011 +0800
+++ b/xen/arch/x86/smpboot.c    Wed Dec 21 19:08:57 2011 +0800
@@ -463,6 +463,10 @@ static int wakeup_secondary_cpu(int phys
             send_status =3D apic_read(APIC_ICR) & APIC_ICR_BUSY;
         } while ( send_status && (timeout++ < 1000) );
     }
+    else
+    {
+        mdelay(10);
+    }

     /*
      * Should we send STARTUP IPIs ?

--_002_F26D193E20BBDC42A43B611D1BDEDE7135CEEEAE56shsmsx502ccrc_
Content-Type: application/octet-stream; name="delay-btw-init-and-sipi.patch"
Content-Description: delay-btw-init-and-sipi.patch
Content-Disposition: attachment; filename="delay-btw-init-and-sipi.patch";
	size=739; creation-date="Wed, 21 Dec 2011 18:35:03 GMT";
	modification-date="Wed, 21 Dec 2011 19:09:29 GMT"
Content-Transfer-Encoding: base64

WDg2OiBBZGQgYSBkZWxheSBiZXR3ZWVuIElOSVQgJiBTSVBJcyBmb3IgQVAgYnJpbmctdXAgaW4g
WDJBUElDIGNhc2UKCldpdGhvdXQgdGhpcyBkZWxheSwgWGVuIGNvdWxkIG5vdCBicmluZyBBUHMg
dXAgd2hpbGUgd29ya2luZyB3aXRoIFRYVC90Ym9vdCwgYmVjYXVzZSB0Ym9vdCBuZWVkIHNvbWUg
dGltZSBpbiBBUHMgdG8gaGFuZGxlIElOSVQgYmVmb3JlIGJlY29taW5nIHJlYWR5IGZvciByZWNl
aXZpbmcgU0lQSXMuCgpTaWduZWQtb2ZmLWJ5OiBHYW5nIFdlaSA8Z2FuZy53ZWlAaW50ZWwuY29t
PgoKZGlmZiAtciBkMWFlZmVlNDNhZjEgeGVuL2FyY2gveDg2L3NtcGJvb3QuYwotLS0gYS94ZW4v
YXJjaC94ODYvc21wYm9vdC5jICAgIFdlZCBEZWMgMjEgMTg6NTE6MzEgMjAxMSArMDgwMAorKysg
Yi94ZW4vYXJjaC94ODYvc21wYm9vdC5jICAgIFdlZCBEZWMgMjEgMTk6MDg6NTcgMjAxMSArMDgw
MApAQCAtNDYzLDYgKzQ2MywxMCBAQCBzdGF0aWMgaW50IHdha2V1cF9zZWNvbmRhcnlfY3B1KGlu
dCBwaHlzCiAgICAgICAgICAgICBzZW5kX3N0YXR1cyA9IGFwaWNfcmVhZChBUElDX0lDUikgJiBB
UElDX0lDUl9CVVNZOwogICAgICAgICB9IHdoaWxlICggc2VuZF9zdGF0dXMgJiYgKHRpbWVvdXQr
KyA8IDEwMDApICk7CiAgICAgfQorICAgIGVsc2UKKyAgICB7CisgICAgICAgIG1kZWxheSgxMCk7
CisgICAgfQoKICAgICAvKgogICAgICAqIFNob3VsZCB3ZSBzZW5kIFNUQVJUVVAgSVBJcyA/Cg==

--_002_F26D193E20BBDC42A43B611D1BDEDE7135CEEEAE56shsmsx502ccrc_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--_002_F26D193E20BBDC42A43B611D1BDEDE7135CEEEAE56shsmsx502ccrc_--


From xen-devel-bounces@lists.xensource.com Wed Dec 21 11:23:27 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 11: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.xensource.com>)
	id 1RdKGJ-0007rY-Hi; Wed, 21 Dec 2011 11:23:07 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <gang.wei@intel.com>) id 1RdKGH-0007rT-LS
	for xen-devel@lists.xensource.com; Wed, 21 Dec 2011 11:23:05 +0000
X-Env-Sender: gang.wei@intel.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1324466578!9628974!1
X-Originating-IP: [143.182.124.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjE0MTY3\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21126 invoked from network); 21 Dec 2011 11:22:59 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-2.tower-216.messagelabs.com with SMTP;
	21 Dec 2011 11:22:59 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga101.ch.intel.com with ESMTP; 21 Dec 2011 03:22:57 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="88064224"
Received: from pgsmsx603.gar.corp.intel.com ([10.221.43.87])
	by azsmga001.ch.intel.com with ESMTP; 21 Dec 2011 03:22:56 -0800
Received: from pgsmsx509.gar.corp.intel.com (172.30.13.17) by
	pgsmsx603.gar.corp.intel.com (10.221.43.87) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Wed, 21 Dec 2011 19:22:55 +0800
Received: from shsmsx601.ccr.corp.intel.com (10.239.4.112) by
	PGSMSX509.gar.corp.intel.com (172.30.13.17) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Wed, 21 Dec 2011 19:22:55 +0800
Received: from shsmsx502.ccr.corp.intel.com ([10.239.4.96]) by
	shsmsx601.ccr.corp.intel.com ([10.239.4.112]) with mapi;
	Wed, 21 Dec 2011 19:22:54 +0800
From: "Wei, Gang" <gang.wei@intel.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Wed, 21 Dec 2011 19:22:52 +0800
Thread-Topic: [patch] x86: Add a delay between INIT & SIPIs for AP bring-up
	in X2APIC case
Thread-Index: Acy/0uD62iL7OBXBT0+nwXPeOaB7qg==
Message-ID: <F26D193E20BBDC42A43B611D1BDEDE7135CEEEAE56@shsmsx502.ccr.corp.intel.com>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
acceptlanguage: zh-CN, en-US
Content-Type: multipart/mixed;
	boundary="_002_F26D193E20BBDC42A43B611D1BDEDE7135CEEEAE56shsmsx502ccrc_"
MIME-Version: 1.0
Cc: Keir Fraser <keir@xen.org>, Tim Deegan <Tim.Deegan@citrix.com>, "Cihula,
	Joseph" <joseph.cihula@intel.com>,
	"tboot-devel@lists.sourceforge.net" <tboot-devel@lists.sourceforge.net>,
	Jan Beulich <jbeulich@suse.com>, "Wei, Gang" <gang.wei@intel.com>
Subject: [Xen-devel] [patch] x86: Add a delay between INIT & SIPIs for AP
 bring-up in X2APIC case
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--_002_F26D193E20BBDC42A43B611D1BDEDE7135CEEEAE56shsmsx502ccrc_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Without this delay, Xen could not bring APs up while working with TXT/tboot=
, because tboot need some time in APs to handle INIT before becoming ready =
for receiving SIPIs. (this delay was removed as part of c/s 23724 by Tim De=
egan)

Signed-off-by: Gang Wei <gang.wei@intel.com>

diff -r d1aefee43af1 xen/arch/x86/smpboot.c
--- a/xen/arch/x86/smpboot.c    Wed Dec 21 18:51:31 2011 +0800
+++ b/xen/arch/x86/smpboot.c    Wed Dec 21 19:08:57 2011 +0800
@@ -463,6 +463,10 @@ static int wakeup_secondary_cpu(int phys
             send_status =3D apic_read(APIC_ICR) & APIC_ICR_BUSY;
         } while ( send_status && (timeout++ < 1000) );
     }
+    else
+    {
+        mdelay(10);
+    }

     /*
      * Should we send STARTUP IPIs ?

--_002_F26D193E20BBDC42A43B611D1BDEDE7135CEEEAE56shsmsx502ccrc_
Content-Type: application/octet-stream; name="delay-btw-init-and-sipi.patch"
Content-Description: delay-btw-init-and-sipi.patch
Content-Disposition: attachment; filename="delay-btw-init-and-sipi.patch";
	size=739; creation-date="Wed, 21 Dec 2011 18:35:03 GMT";
	modification-date="Wed, 21 Dec 2011 19:09:29 GMT"
Content-Transfer-Encoding: base64

WDg2OiBBZGQgYSBkZWxheSBiZXR3ZWVuIElOSVQgJiBTSVBJcyBmb3IgQVAgYnJpbmctdXAgaW4g
WDJBUElDIGNhc2UKCldpdGhvdXQgdGhpcyBkZWxheSwgWGVuIGNvdWxkIG5vdCBicmluZyBBUHMg
dXAgd2hpbGUgd29ya2luZyB3aXRoIFRYVC90Ym9vdCwgYmVjYXVzZSB0Ym9vdCBuZWVkIHNvbWUg
dGltZSBpbiBBUHMgdG8gaGFuZGxlIElOSVQgYmVmb3JlIGJlY29taW5nIHJlYWR5IGZvciByZWNl
aXZpbmcgU0lQSXMuCgpTaWduZWQtb2ZmLWJ5OiBHYW5nIFdlaSA8Z2FuZy53ZWlAaW50ZWwuY29t
PgoKZGlmZiAtciBkMWFlZmVlNDNhZjEgeGVuL2FyY2gveDg2L3NtcGJvb3QuYwotLS0gYS94ZW4v
YXJjaC94ODYvc21wYm9vdC5jICAgIFdlZCBEZWMgMjEgMTg6NTE6MzEgMjAxMSArMDgwMAorKysg
Yi94ZW4vYXJjaC94ODYvc21wYm9vdC5jICAgIFdlZCBEZWMgMjEgMTk6MDg6NTcgMjAxMSArMDgw
MApAQCAtNDYzLDYgKzQ2MywxMCBAQCBzdGF0aWMgaW50IHdha2V1cF9zZWNvbmRhcnlfY3B1KGlu
dCBwaHlzCiAgICAgICAgICAgICBzZW5kX3N0YXR1cyA9IGFwaWNfcmVhZChBUElDX0lDUikgJiBB
UElDX0lDUl9CVVNZOwogICAgICAgICB9IHdoaWxlICggc2VuZF9zdGF0dXMgJiYgKHRpbWVvdXQr
KyA8IDEwMDApICk7CiAgICAgfQorICAgIGVsc2UKKyAgICB7CisgICAgICAgIG1kZWxheSgxMCk7
CisgICAgfQoKICAgICAvKgogICAgICAqIFNob3VsZCB3ZSBzZW5kIFNUQVJUVVAgSVBJcyA/Cg==

--_002_F26D193E20BBDC42A43B611D1BDEDE7135CEEEAE56shsmsx502ccrc_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--_002_F26D193E20BBDC42A43B611D1BDEDE7135CEEEAE56shsmsx502ccrc_--


From xen-devel-bounces@lists.xensource.com Wed Dec 21 11:48:48 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 11: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.xensource.com>)
	id 1RdKel-0008Da-V2; Wed, 21 Dec 2011 11:48:23 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RdKek-0008DV-S4
	for xen-devel@lists.xensource.com; Wed, 21 Dec 2011 11:48:23 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1324468095!6375378!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17827 invoked from network); 21 Dec 2011 11:48:16 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-2.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Dec 2011 11:48:16 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 21 Dec 2011 11:48:15 +0000
Message-Id: <4EF1D5C4020000780006954D@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 21 Dec 2011 11:49:08 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Gang Wei" <gang.wei@intel.com>
References: <F26D193E20BBDC42A43B611D1BDEDE7135CEEEAE56@shsmsx502.ccr.corp.intel.com>
In-Reply-To: <F26D193E20BBDC42A43B611D1BDEDE7135CEEEAE56@shsmsx502.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"tboot-devel@lists.sourceforge.net" <tboot-devel@lists.sourceforge.net>,
	Joseph Cihula <joseph.cihula@intel.com>,
	Keir Fraser <keir@xen.org>, Tim Deegan <Tim.Deegan@citrix.com>
Subject: Re: [Xen-devel] [patch] x86: Add a delay between INIT & SIPIs for
 AP bring-up in X2APIC case
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 21.12.11 at 12:22, "Wei, Gang" <gang.wei@intel.com> wrote:
> Without this delay, Xen could not bring APs up while working with TXT/tboot, 
> because tboot need some time in APs to handle INIT before becoming ready for 
> receiving SIPIs. (this delay was removed as part of c/s 23724 by Tim Deegan)
> 
> Signed-off-by: Gang Wei <gang.wei@intel.com>
> 
> diff -r d1aefee43af1 xen/arch/x86/smpboot.c
> --- a/xen/arch/x86/smpboot.c    Wed Dec 21 18:51:31 2011 +0800
> +++ b/xen/arch/x86/smpboot.c    Wed Dec 21 19:08:57 2011 +0800
> @@ -463,6 +463,10 @@ static int wakeup_secondary_cpu(int phys
>              send_status = apic_read(APIC_ICR) & APIC_ICR_BUSY;
>          } while ( send_status && (timeout++ < 1000) );
>      }
> +    else
> +    {
> +        mdelay(10);
> +    }

Does it really need to be this long then (even in the non-TBOOT
case)?

Jan

> 
>      /*
>       * Should we send STARTUP IPIs ?




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 21 11:48:48 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 11: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.xensource.com>)
	id 1RdKel-0008Da-V2; Wed, 21 Dec 2011 11:48:23 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RdKek-0008DV-S4
	for xen-devel@lists.xensource.com; Wed, 21 Dec 2011 11:48:23 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1324468095!6375378!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17827 invoked from network); 21 Dec 2011 11:48:16 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-2.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Dec 2011 11:48:16 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 21 Dec 2011 11:48:15 +0000
Message-Id: <4EF1D5C4020000780006954D@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 21 Dec 2011 11:49:08 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Gang Wei" <gang.wei@intel.com>
References: <F26D193E20BBDC42A43B611D1BDEDE7135CEEEAE56@shsmsx502.ccr.corp.intel.com>
In-Reply-To: <F26D193E20BBDC42A43B611D1BDEDE7135CEEEAE56@shsmsx502.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"tboot-devel@lists.sourceforge.net" <tboot-devel@lists.sourceforge.net>,
	Joseph Cihula <joseph.cihula@intel.com>,
	Keir Fraser <keir@xen.org>, Tim Deegan <Tim.Deegan@citrix.com>
Subject: Re: [Xen-devel] [patch] x86: Add a delay between INIT & SIPIs for
 AP bring-up in X2APIC case
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 21.12.11 at 12:22, "Wei, Gang" <gang.wei@intel.com> wrote:
> Without this delay, Xen could not bring APs up while working with TXT/tboot, 
> because tboot need some time in APs to handle INIT before becoming ready for 
> receiving SIPIs. (this delay was removed as part of c/s 23724 by Tim Deegan)
> 
> Signed-off-by: Gang Wei <gang.wei@intel.com>
> 
> diff -r d1aefee43af1 xen/arch/x86/smpboot.c
> --- a/xen/arch/x86/smpboot.c    Wed Dec 21 18:51:31 2011 +0800
> +++ b/xen/arch/x86/smpboot.c    Wed Dec 21 19:08:57 2011 +0800
> @@ -463,6 +463,10 @@ static int wakeup_secondary_cpu(int phys
>              send_status = apic_read(APIC_ICR) & APIC_ICR_BUSY;
>          } while ( send_status && (timeout++ < 1000) );
>      }
> +    else
> +    {
> +        mdelay(10);
> +    }

Does it really need to be this long then (even in the non-TBOOT
case)?

Jan

> 
>      /*
>       * Should we send STARTUP IPIs ?




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 21 11:59:18 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 11:59:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdKox-0008Nb-3J; Wed, 21 Dec 2011 11:58:55 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RdKow-0008NW-0q
	for xen-devel@lists.xensource.com; Wed, 21 Dec 2011 11:58:54 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1324468726!6383554!1
X-Originating-IP: [209.85.216.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21855 invoked from network); 21 Dec 2011 11:58:47 -0000
Received: from mail-qy0-f171.google.com (HELO mail-qy0-f171.google.com)
	(209.85.216.171)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Dec 2011 11:58:47 -0000
Received: by qcsc20 with SMTP id c20so55986227qcs.30
	for <xen-devel@lists.xensource.com>;
	Wed, 21 Dec 2011 03:58:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=PWW3z7Q9IUwLwxS6uIk4As48ZBwNAhfHjxNOvaidYuI=;
	b=UGWaJLKAEA+A6hZU2GPNa3Vfbk6DeMkyeOsZAntj1gXRezV2Kaz6Xb/fwJEsIWwetu
	AqqGJT+aEii9sR4nt8ZzqCXwpadtBDq3e8gIf7CiKdS2c4e+CUViTqIpJ/mQdDZwf9Fw
	zWfv+A38IPB5lgxpiLxKyntNgydVIgUYPN7Tk=
Received: by 10.229.76.202 with SMTP id d10mr2430014qck.21.1324468725592;
	Wed, 21 Dec 2011 03:58:45 -0800 (PST)
Received: from [192.168.1.3] (host81-152-17-11.range81-152.btcentralplus.com.
	[81.152.17.11])
	by mx.google.com with ESMTPS id dm3sm10211682qab.12.2011.12.21.03.58.42
	(version=SSLv3 cipher=OTHER); Wed, 21 Dec 2011 03:58:44 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Wed, 21 Dec 2011 11:58:37 +0000
From: Keir Fraser <keir@xen.org>
To: "Zhang, Xiantao" <xiantao.zhang@intel.com>,
	"Shan, Haitao" <haitao.shan@intel.com>,
	Konrad Rzeszutek Wilk <konrad@darnok.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	"andrew.thomas@oracle.com" <andrew.thomas@oracle.com>
Message-ID: <CB177A6D.365E1%keir@xen.org>
Thread-Topic: [Xen-devel] issues with PLE and/or scheduler.
Thread-Index: Acy/WC58GrEeWsJBTKeBU9VJiBfb5QAJ2kbQABFXDVAABLrZBQ==
In-Reply-To: <BC00F5384FCFC9499AF06F92E8B78A9E2890487CF5@shsmsx502.ccr.corp.intel.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] issues with PLE and/or scheduler.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 21/12/2011 10:34, "Zhang, Xiantao" <xiantao.zhang@intel.com> wrote:

> diff -r 381ab77db71a xen/arch/x86/hvm/vpt.c
> --- a/xen/arch/x86/hvm/vpt.c    Mon Apr 18 10:10:02 2011 +0100
> +++ b/xen/arch/x86/hvm/vpt.c    Thu Dec 22 05:54:54 2011 +0800
> @@ -129,7 +129,7 @@
>      if ( missed_ticks <= 0 )
>          return;
> 
> -    missed_ticks = missed_ticks / (s_time_t) pt->period + 1;
> +    missed_ticks = missed_ticks / (s_time_t) pt->period;
>      if ( mode_is(pt->vcpu->domain, no_missed_ticks_pending) )
>          pt->do_not_freeze = !pt->pending_intr_nr;
>      else
> 
> Anyone can explain the above "plus one" logic ?   why assume at least one tick
> is missed in pt_process_missed_ticks ?

missed_ticks = now - pt->scheduled

pt->scheduled was deadline for next tick. Hence the number of missed ticks
is the total number of period that have passed since pt->scheduled, plus
one. If we had not missed at least one tick, we would return early, from the
if-statement at the top of your patch fragment, above.

What's the guest timer_mode? If there was at least one missed tick I would
have expected a timer interrupt to get injected straight away. Except
perhaps for timer_mode=2=no_missed_ticks_pending -- I don't understand that
timer mode, and perhaps there could be a bad interaction with its specific
interrupt-holdoff logic.

 -- Keir

> In the guest kernel,  ioapic's check_timer logic is used to determine how to
> set IRQ0, and it uses mdelay to delay 10 ticks totally.  If kernel can receive
> 4+ ticks during the delay, kernel deems IRQ0 is routed correctly through
> ioapic.  
> Unfortunately,  mdelay is implemented as a tight pause loop,  when PLE is
> enabled,  the tight pause loop will trigger PLE vmexit.  In the PLE vmexit
> handler, scheduler yields the CPU, but the yield operation triggers  guest's
> time save/restore logic,
> eventually pt_process_missed_ticks gets called.   Once pt_process_missed_ticks
> is called,  pt->scheduled is plused by one pt->period due to the above "plus
> one" logic.   
> By default, ple_window is 4096,  so each 4096 cycles in guest's mdelay
> triggers one  PLE vmexit,  and each vmexit delays  the vpt timer by one
> pt->period, so the vpt timer maybe never be fired during the guest's delay.
> This  is why jiffies is not increased during the 10-tick mdelay.
> 
> Thanks!
> Xiantao 
> 
> 
> 
> 
> 
> -----Original Message-----
> From: xen-devel-bounces@lists.xensource.com
> [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Shan, Haitao
> Sent: Wednesday, December 21, 2011 9:28 AM
> To: Konrad Rzeszutek Wilk; xen-devel@lists.xensource.com;
> konrad.wilk@oracle.com; George.Dunlap@eu.citrix.com; keir@xen.org;
> andrew.thomas@oracle.com
> Subject: Re: [Xen-devel] issues with PLE and/or scheduler.
> 
> We have reproduced your problem locally and are looking into this issue. It
> seems "PLE with timer mode 2" will trigger the issue. We can post our findings
> as soon as possible.
> 
> Shan Haitao
> 
>> -----Original Message-----
>> From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-
>> bounces@lists.xensource.com] On Behalf Of Konrad Rzeszutek Wilk
>> Sent: Wednesday, December 21, 2011 4:42 AM
>> To: xen-devel@lists.xensource.com; konrad.wilk@oracle.com;
>> George.Dunlap@eu.citrix.com; keir@xen.org; andrew.thomas@oracle.com
>> Subject: Re: [Xen-devel] issues with PLE and/or scheduler.
>> 
>> On Tue, Dec 20, 2011 at 04:41:07PM -0400, Konrad Rzeszutek Wilk wrote:
>>> Hey folks,
>>> 
>>> I am sending this on behalf of Andrew since our internal email
>>> system is dropping all xen-devel mailing lists :-(
>> 
>> <hits his head> And I forgot to CC andrew on it. Added here.
>>> 
>>> Anyhow:
>>> 
>>> This is with xen-4.1-testing cs 23201:1c89f7d29fbb and using the
>>> default "credit" scheduler.
>>> 
>>> I've run into an interesting issue with HVM guests which make use of
>>> Pause Loop Exiting (ie. on westmere systems; and also on romley
>>> systems):  after yielding the cpu, guests don't seem to receive
>>> timer interrupts correctly..
>>> 
>>> Some background: for historical reasons (ie old templates) we boot
>>> OL/RHEL guests with the following settings:
>>> 
>>> kernel parameters: clock=pit nohpet nopmtimer
>>> vm.cfg: timer_mode = 2
>>> 
>>> With PLE enabled, 2.6.32 guests will crash early on with:
>>>  ..MP-BIOS bug: 8254 timer not connected to IO-APIC  # a few lines
>>> omitted..
>>>  Kernel panic - not syncing: IO-APIC + timer doesn't work!  Boot
>>> with apic=debug
>>> 
>>> While 2.6.18-238 (ie OL/RHEL5u6) will fail to find the timer, but
>>> continue and lock up in the serial line initialization.
>>> 
>>>  ..MP-BIOS bug: 8254 timer not connected to IO-APIC  # continues
>>> until lock up here:
>>>  Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing
>>> enabled
>>> 
>>> Instrumenting the 2.6.32 code (ie timer_irq_works()) shows that
>>> jiffies isn't advancing (or only 1 or 2 ticks are being received,
>>> which is insufficient for "working"). This is on a "quiet" system
>>> with
> no
>> other activity.
>>> So, even though the guest has voluntarily yielded the cpu (through
>>> PLE), I would still expect it to receive every clock tick (even with
>>> timer_mode=2) as there is no other work to do on the system.
>>> 
>>> Disabling PLE allows both 2.6.18 and 2.6.32 guests to boot.. [As an
>>> aside, so does setting ple_gap to 41 (ie prior to
>>> 21355:727ccaaa6cce)
>>> -- the perf counters show no exits happening, so this is equivalent
>>> to disabling PLE.]
>>> 
>>> I'm hoping someone who knows the scheduler well will be able to
>>> quickly decide whether this is a bug or a feature...
>>> 
>>> Andrew
>> 
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 21 11:59:18 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 11:59:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdKox-0008Nb-3J; Wed, 21 Dec 2011 11:58:55 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RdKow-0008NW-0q
	for xen-devel@lists.xensource.com; Wed, 21 Dec 2011 11:58:54 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1324468726!6383554!1
X-Originating-IP: [209.85.216.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21855 invoked from network); 21 Dec 2011 11:58:47 -0000
Received: from mail-qy0-f171.google.com (HELO mail-qy0-f171.google.com)
	(209.85.216.171)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Dec 2011 11:58:47 -0000
Received: by qcsc20 with SMTP id c20so55986227qcs.30
	for <xen-devel@lists.xensource.com>;
	Wed, 21 Dec 2011 03:58:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=PWW3z7Q9IUwLwxS6uIk4As48ZBwNAhfHjxNOvaidYuI=;
	b=UGWaJLKAEA+A6hZU2GPNa3Vfbk6DeMkyeOsZAntj1gXRezV2Kaz6Xb/fwJEsIWwetu
	AqqGJT+aEii9sR4nt8ZzqCXwpadtBDq3e8gIf7CiKdS2c4e+CUViTqIpJ/mQdDZwf9Fw
	zWfv+A38IPB5lgxpiLxKyntNgydVIgUYPN7Tk=
Received: by 10.229.76.202 with SMTP id d10mr2430014qck.21.1324468725592;
	Wed, 21 Dec 2011 03:58:45 -0800 (PST)
Received: from [192.168.1.3] (host81-152-17-11.range81-152.btcentralplus.com.
	[81.152.17.11])
	by mx.google.com with ESMTPS id dm3sm10211682qab.12.2011.12.21.03.58.42
	(version=SSLv3 cipher=OTHER); Wed, 21 Dec 2011 03:58:44 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Wed, 21 Dec 2011 11:58:37 +0000
From: Keir Fraser <keir@xen.org>
To: "Zhang, Xiantao" <xiantao.zhang@intel.com>,
	"Shan, Haitao" <haitao.shan@intel.com>,
	Konrad Rzeszutek Wilk <konrad@darnok.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	"andrew.thomas@oracle.com" <andrew.thomas@oracle.com>
Message-ID: <CB177A6D.365E1%keir@xen.org>
Thread-Topic: [Xen-devel] issues with PLE and/or scheduler.
Thread-Index: Acy/WC58GrEeWsJBTKeBU9VJiBfb5QAJ2kbQABFXDVAABLrZBQ==
In-Reply-To: <BC00F5384FCFC9499AF06F92E8B78A9E2890487CF5@shsmsx502.ccr.corp.intel.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] issues with PLE and/or scheduler.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 21/12/2011 10:34, "Zhang, Xiantao" <xiantao.zhang@intel.com> wrote:

> diff -r 381ab77db71a xen/arch/x86/hvm/vpt.c
> --- a/xen/arch/x86/hvm/vpt.c    Mon Apr 18 10:10:02 2011 +0100
> +++ b/xen/arch/x86/hvm/vpt.c    Thu Dec 22 05:54:54 2011 +0800
> @@ -129,7 +129,7 @@
>      if ( missed_ticks <= 0 )
>          return;
> 
> -    missed_ticks = missed_ticks / (s_time_t) pt->period + 1;
> +    missed_ticks = missed_ticks / (s_time_t) pt->period;
>      if ( mode_is(pt->vcpu->domain, no_missed_ticks_pending) )
>          pt->do_not_freeze = !pt->pending_intr_nr;
>      else
> 
> Anyone can explain the above "plus one" logic ?   why assume at least one tick
> is missed in pt_process_missed_ticks ?

missed_ticks = now - pt->scheduled

pt->scheduled was deadline for next tick. Hence the number of missed ticks
is the total number of period that have passed since pt->scheduled, plus
one. If we had not missed at least one tick, we would return early, from the
if-statement at the top of your patch fragment, above.

What's the guest timer_mode? If there was at least one missed tick I would
have expected a timer interrupt to get injected straight away. Except
perhaps for timer_mode=2=no_missed_ticks_pending -- I don't understand that
timer mode, and perhaps there could be a bad interaction with its specific
interrupt-holdoff logic.

 -- Keir

> In the guest kernel,  ioapic's check_timer logic is used to determine how to
> set IRQ0, and it uses mdelay to delay 10 ticks totally.  If kernel can receive
> 4+ ticks during the delay, kernel deems IRQ0 is routed correctly through
> ioapic.  
> Unfortunately,  mdelay is implemented as a tight pause loop,  when PLE is
> enabled,  the tight pause loop will trigger PLE vmexit.  In the PLE vmexit
> handler, scheduler yields the CPU, but the yield operation triggers  guest's
> time save/restore logic,
> eventually pt_process_missed_ticks gets called.   Once pt_process_missed_ticks
> is called,  pt->scheduled is plused by one pt->period due to the above "plus
> one" logic.   
> By default, ple_window is 4096,  so each 4096 cycles in guest's mdelay
> triggers one  PLE vmexit,  and each vmexit delays  the vpt timer by one
> pt->period, so the vpt timer maybe never be fired during the guest's delay.
> This  is why jiffies is not increased during the 10-tick mdelay.
> 
> Thanks!
> Xiantao 
> 
> 
> 
> 
> 
> -----Original Message-----
> From: xen-devel-bounces@lists.xensource.com
> [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Shan, Haitao
> Sent: Wednesday, December 21, 2011 9:28 AM
> To: Konrad Rzeszutek Wilk; xen-devel@lists.xensource.com;
> konrad.wilk@oracle.com; George.Dunlap@eu.citrix.com; keir@xen.org;
> andrew.thomas@oracle.com
> Subject: Re: [Xen-devel] issues with PLE and/or scheduler.
> 
> We have reproduced your problem locally and are looking into this issue. It
> seems "PLE with timer mode 2" will trigger the issue. We can post our findings
> as soon as possible.
> 
> Shan Haitao
> 
>> -----Original Message-----
>> From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-
>> bounces@lists.xensource.com] On Behalf Of Konrad Rzeszutek Wilk
>> Sent: Wednesday, December 21, 2011 4:42 AM
>> To: xen-devel@lists.xensource.com; konrad.wilk@oracle.com;
>> George.Dunlap@eu.citrix.com; keir@xen.org; andrew.thomas@oracle.com
>> Subject: Re: [Xen-devel] issues with PLE and/or scheduler.
>> 
>> On Tue, Dec 20, 2011 at 04:41:07PM -0400, Konrad Rzeszutek Wilk wrote:
>>> Hey folks,
>>> 
>>> I am sending this on behalf of Andrew since our internal email
>>> system is dropping all xen-devel mailing lists :-(
>> 
>> <hits his head> And I forgot to CC andrew on it. Added here.
>>> 
>>> Anyhow:
>>> 
>>> This is with xen-4.1-testing cs 23201:1c89f7d29fbb and using the
>>> default "credit" scheduler.
>>> 
>>> I've run into an interesting issue with HVM guests which make use of
>>> Pause Loop Exiting (ie. on westmere systems; and also on romley
>>> systems):  after yielding the cpu, guests don't seem to receive
>>> timer interrupts correctly..
>>> 
>>> Some background: for historical reasons (ie old templates) we boot
>>> OL/RHEL guests with the following settings:
>>> 
>>> kernel parameters: clock=pit nohpet nopmtimer
>>> vm.cfg: timer_mode = 2
>>> 
>>> With PLE enabled, 2.6.32 guests will crash early on with:
>>>  ..MP-BIOS bug: 8254 timer not connected to IO-APIC  # a few lines
>>> omitted..
>>>  Kernel panic - not syncing: IO-APIC + timer doesn't work!  Boot
>>> with apic=debug
>>> 
>>> While 2.6.18-238 (ie OL/RHEL5u6) will fail to find the timer, but
>>> continue and lock up in the serial line initialization.
>>> 
>>>  ..MP-BIOS bug: 8254 timer not connected to IO-APIC  # continues
>>> until lock up here:
>>>  Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing
>>> enabled
>>> 
>>> Instrumenting the 2.6.32 code (ie timer_irq_works()) shows that
>>> jiffies isn't advancing (or only 1 or 2 ticks are being received,
>>> which is insufficient for "working"). This is on a "quiet" system
>>> with
> no
>> other activity.
>>> So, even though the guest has voluntarily yielded the cpu (through
>>> PLE), I would still expect it to receive every clock tick (even with
>>> timer_mode=2) as there is no other work to do on the system.
>>> 
>>> Disabling PLE allows both 2.6.18 and 2.6.32 guests to boot.. [As an
>>> aside, so does setting ple_gap to 41 (ie prior to
>>> 21355:727ccaaa6cce)
>>> -- the perf counters show no exits happening, so this is equivalent
>>> to disabling PLE.]
>>> 
>>> I'm hoping someone who knows the scheduler well will be able to
>>> quickly decide whether this is a bug or a feature...
>>> 
>>> Andrew
>> 
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 21 12:06:43 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 12:06:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdKw9-0000JS-P7; Wed, 21 Dec 2011 12:06:21 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RdKw8-0000JK-4I
	for xen-devel@lists.xensource.com; Wed, 21 Dec 2011 12:06:20 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1324469155!59802216!1
X-Originating-IP: [209.85.216.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29984 invoked from network); 21 Dec 2011 12:05:56 -0000
Received: from mail-qy0-f171.google.com (HELO mail-qy0-f171.google.com)
	(209.85.216.171)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Dec 2011 12:05:56 -0000
Received: by qcsc20 with SMTP id c20so56025764qcs.30
	for <xen-devel@lists.xensource.com>;
	Wed, 21 Dec 2011 04:06:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=eEXWPBXdS7VW9aiGbeuLnqnpbWbFACv6CMUS1v9xIUc=;
	b=jSgYYAwaq+PGw8x5RapKBrRRshLwnsWAEgh/2wvbciyWs0Q+phLqRyDLKNBY7u2aVr
	Gr87/cxtBxvi0RDSfEZDS+L/MeDLYvZcT1/dHTkIqn23b3ZmKbod130rGiWMXwTyDORd
	D6y+lqFRPoOVRChfSpGRCP39hjMSfaosoZkH4=
Received: by 10.229.105.100 with SMTP id s36mr2452938qco.3.1324469174713;
	Wed, 21 Dec 2011 04:06:14 -0800 (PST)
Received: from [192.168.1.3] (host81-152-17-11.range81-152.btcentralplus.com.
	[81.152.17.11])
	by mx.google.com with ESMTPS id q14sm10277139qap.4.2011.12.21.04.06.11
	(version=SSLv3 cipher=OTHER); Wed, 21 Dec 2011 04:06:13 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Wed, 21 Dec 2011 12:06:00 +0000
From: Keir Fraser <keir@xen.org>
To: "Wei, Gang" <gang.wei@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Message-ID: <CB177C28.365E3%keir@xen.org>
Thread-Topic: [patch] x86: Add a delay between INIT & SIPIs for AP bring-up in
	X2APIC case
Thread-Index: Acy/0uD62iL7OBXBT0+nwXPeOaB7qgABgY/9
In-Reply-To: <F26D193E20BBDC42A43B611D1BDEDE7135CEEEAE56@shsmsx502.ccr.corp.intel.com>
Mime-version: 1.0
Cc: "tboot-devel@lists.sourceforge.net" <tboot-devel@lists.sourceforge.net>,
	"Cihula, Joseph" <joseph.cihula@intel.com>,
	Tim Deegan <Tim.Deegan@citrix.com>, Jan Beulich <jbeulich@suse.com>
Subject: Re: [Xen-devel] [patch] x86: Add a delay between INIT & SIPIs for
 AP bring-up in X2APIC case
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 21/12/2011 11:22, "Wei, Gang" <gang.wei@intel.com> wrote:

> Without this delay, Xen could not bring APs up while working with TXT/tboot,
> because tboot need some time in APs to handle INIT before becoming ready for
> receiving SIPIs. (this delay was removed as part of c/s 23724 by Tim Deegan)

Of course Tim will need to review this himself, but a mdelay() right here,
only on the x2apic path just looks bizarre and fragile.

Could we make the !x2apic_enabled conditionals that Tim added be
!(x2apic_enabled || tboot_in_measured_env()) instead? At least that is
somewhat self-documenting and clearly only affects tboot!

 -- Keir

> Signed-off-by: Gang Wei <gang.wei@intel.com>
> 
> diff -r d1aefee43af1 xen/arch/x86/smpboot.c
> --- a/xen/arch/x86/smpboot.c    Wed Dec 21 18:51:31 2011 +0800
> +++ b/xen/arch/x86/smpboot.c    Wed Dec 21 19:08:57 2011 +0800
> @@ -463,6 +463,10 @@ static int wakeup_secondary_cpu(int phys
>              send_status = apic_read(APIC_ICR) & APIC_ICR_BUSY;
>          } while ( send_status && (timeout++ < 1000) );
>      }
> +    else
> +    {
> +        mdelay(10);
> +    }
> 
>      /*
>       * Should we send STARTUP IPIs ?



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 21 12:06:43 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 12:06:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdKw9-0000JS-P7; Wed, 21 Dec 2011 12:06:21 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RdKw8-0000JK-4I
	for xen-devel@lists.xensource.com; Wed, 21 Dec 2011 12:06:20 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1324469155!59802216!1
X-Originating-IP: [209.85.216.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29984 invoked from network); 21 Dec 2011 12:05:56 -0000
Received: from mail-qy0-f171.google.com (HELO mail-qy0-f171.google.com)
	(209.85.216.171)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Dec 2011 12:05:56 -0000
Received: by qcsc20 with SMTP id c20so56025764qcs.30
	for <xen-devel@lists.xensource.com>;
	Wed, 21 Dec 2011 04:06:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=eEXWPBXdS7VW9aiGbeuLnqnpbWbFACv6CMUS1v9xIUc=;
	b=jSgYYAwaq+PGw8x5RapKBrRRshLwnsWAEgh/2wvbciyWs0Q+phLqRyDLKNBY7u2aVr
	Gr87/cxtBxvi0RDSfEZDS+L/MeDLYvZcT1/dHTkIqn23b3ZmKbod130rGiWMXwTyDORd
	D6y+lqFRPoOVRChfSpGRCP39hjMSfaosoZkH4=
Received: by 10.229.105.100 with SMTP id s36mr2452938qco.3.1324469174713;
	Wed, 21 Dec 2011 04:06:14 -0800 (PST)
Received: from [192.168.1.3] (host81-152-17-11.range81-152.btcentralplus.com.
	[81.152.17.11])
	by mx.google.com with ESMTPS id q14sm10277139qap.4.2011.12.21.04.06.11
	(version=SSLv3 cipher=OTHER); Wed, 21 Dec 2011 04:06:13 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Wed, 21 Dec 2011 12:06:00 +0000
From: Keir Fraser <keir@xen.org>
To: "Wei, Gang" <gang.wei@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Message-ID: <CB177C28.365E3%keir@xen.org>
Thread-Topic: [patch] x86: Add a delay between INIT & SIPIs for AP bring-up in
	X2APIC case
Thread-Index: Acy/0uD62iL7OBXBT0+nwXPeOaB7qgABgY/9
In-Reply-To: <F26D193E20BBDC42A43B611D1BDEDE7135CEEEAE56@shsmsx502.ccr.corp.intel.com>
Mime-version: 1.0
Cc: "tboot-devel@lists.sourceforge.net" <tboot-devel@lists.sourceforge.net>,
	"Cihula, Joseph" <joseph.cihula@intel.com>,
	Tim Deegan <Tim.Deegan@citrix.com>, Jan Beulich <jbeulich@suse.com>
Subject: Re: [Xen-devel] [patch] x86: Add a delay between INIT & SIPIs for
 AP bring-up in X2APIC case
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 21/12/2011 11:22, "Wei, Gang" <gang.wei@intel.com> wrote:

> Without this delay, Xen could not bring APs up while working with TXT/tboot,
> because tboot need some time in APs to handle INIT before becoming ready for
> receiving SIPIs. (this delay was removed as part of c/s 23724 by Tim Deegan)

Of course Tim will need to review this himself, but a mdelay() right here,
only on the x2apic path just looks bizarre and fragile.

Could we make the !x2apic_enabled conditionals that Tim added be
!(x2apic_enabled || tboot_in_measured_env()) instead? At least that is
somewhat self-documenting and clearly only affects tboot!

 -- Keir

> Signed-off-by: Gang Wei <gang.wei@intel.com>
> 
> diff -r d1aefee43af1 xen/arch/x86/smpboot.c
> --- a/xen/arch/x86/smpboot.c    Wed Dec 21 18:51:31 2011 +0800
> +++ b/xen/arch/x86/smpboot.c    Wed Dec 21 19:08:57 2011 +0800
> @@ -463,6 +463,10 @@ static int wakeup_secondary_cpu(int phys
>              send_status = apic_read(APIC_ICR) & APIC_ICR_BUSY;
>          } while ( send_status && (timeout++ < 1000) );
>      }
> +    else
> +    {
> +        mdelay(10);
> +    }
> 
>      /*
>       * Should we send STARTUP IPIs ?



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 21 12:07:58 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 12:07:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdKxL-0000Mc-8A; Wed, 21 Dec 2011 12:07:35 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <gang.wei@intel.com>) id 1RdKxJ-0000MO-DS
	for xen-devel@lists.xensource.com; Wed, 21 Dec 2011 12:07:33 +0000
X-Env-Sender: gang.wei@intel.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1324469228!50171630!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDMwMTI2Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29791 invoked from network); 21 Dec 2011 12:07:09 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-11.tower-27.messagelabs.com with SMTP;
	21 Dec 2011 12:07:09 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga101.fm.intel.com with ESMTP; 21 Dec 2011 04:07:28 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="98764976"
Received: from pgsmsx603.gar.corp.intel.com ([10.221.43.87])
	by fmsmga001.fm.intel.com with ESMTP; 21 Dec 2011 04:07:26 -0800
Received: from pgsmsx151.gar.corp.intel.com (172.30.236.41) by
	pgsmsx603.gar.corp.intel.com (10.221.43.87) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Wed, 21 Dec 2011 20:07:26 +0800
Received: from shsmsx601.ccr.corp.intel.com (10.239.4.112) by
	PGSMSX151.gar.corp.intel.com (172.30.236.41) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Wed, 21 Dec 2011 20:07:25 +0800
Received: from shsmsx502.ccr.corp.intel.com ([10.239.4.96]) by
	shsmsx601.ccr.corp.intel.com ([10.239.4.112]) with mapi;
	Wed, 21 Dec 2011 20:07:25 +0800
From: "Wei, Gang" <gang.wei@intel.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Wed, 21 Dec 2011 20:07:24 +0800
Thread-Topic: [patch] x86: Add a delay between INIT & SIPIs for AP bring-up
	in X2APIC case
Thread-Index: Acy/1nAYdBmZFulrQkSecYTe5EWj1gAAaU4w
Message-ID: <F26D193E20BBDC42A43B611D1BDEDE7135CEEEAE62@shsmsx502.ccr.corp.intel.com>
References: <F26D193E20BBDC42A43B611D1BDEDE7135CEEEAE56@shsmsx502.ccr.corp.intel.com>
	<4EF1D5C4020000780006954D@nat28.tlf.novell.com>
In-Reply-To: <4EF1D5C4020000780006954D@nat28.tlf.novell.com>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: zh-CN, en-US
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Keir Fraser <keir@xen.org>, Tim Deegan <Tim.Deegan@citrix.com>,
	"Cihula, Joseph" <joseph.cihula@intel.com>,
	"tboot-devel@lists.sourceforge.net" <tboot-devel@lists.sourceforge.net>,
	"Wei, Gang" <gang.wei@intel.com>
Subject: Re: [Xen-devel] [patch] x86: Add a delay between INIT & SIPIs for
 AP bring-up in X2APIC case
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Jan Beulich wrote on=A02011-12-21:
>>>> On 21.12.11 at 12:22, "Wei, Gang" <gang.wei@intel.com> wrote:
>> Without this delay, Xen could not bring APs up while working with
>> TXT/tboot, because tboot need some time in APs to handle INIT before
>> becoming ready for receiving SIPIs. (this delay was removed as part
>> of c/s 23724 by Tim Deegan)
>> =

>> Signed-off-by: Gang Wei <gang.wei@intel.com>
>> =

>> diff -r d1aefee43af1 xen/arch/x86/smpboot.c
>> --- a/xen/arch/x86/smpboot.c    Wed Dec 21 18:51:31 2011 +0800
>> +++ b/xen/arch/x86/smpboot.c    Wed Dec 21 19:08:57 2011 +0800
>> @@ -463,6 +463,10 @@ static int wakeup_secondary_cpu(int phys
>>              send_status =3D apic_read(APIC_ICR) & APIC_ICR_BUSY;
>>          } while ( send_status && (timeout++ < 1000) );
>>      }
>> +    else
>> +    {
>> +        mdelay(10);
>> +    }
> =

> Does it really need to be this long then (even in the non-TBOOT case)?

No, it could be shorter. I just take a used value back here. If it does mat=
ter, we could use a tested working value here: udelay(10), and for tboot ca=
se only.

Jimmy

> =

> Jan
> =

>> =

>>      /*
>>       * Should we send STARTUP IPIs ?
> =

>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 21 12:07:58 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 12:07:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdKxL-0000Mc-8A; Wed, 21 Dec 2011 12:07:35 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <gang.wei@intel.com>) id 1RdKxJ-0000MO-DS
	for xen-devel@lists.xensource.com; Wed, 21 Dec 2011 12:07:33 +0000
X-Env-Sender: gang.wei@intel.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1324469228!50171630!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDMwMTI2Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29791 invoked from network); 21 Dec 2011 12:07:09 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-11.tower-27.messagelabs.com with SMTP;
	21 Dec 2011 12:07:09 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga101.fm.intel.com with ESMTP; 21 Dec 2011 04:07:28 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="98764976"
Received: from pgsmsx603.gar.corp.intel.com ([10.221.43.87])
	by fmsmga001.fm.intel.com with ESMTP; 21 Dec 2011 04:07:26 -0800
Received: from pgsmsx151.gar.corp.intel.com (172.30.236.41) by
	pgsmsx603.gar.corp.intel.com (10.221.43.87) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Wed, 21 Dec 2011 20:07:26 +0800
Received: from shsmsx601.ccr.corp.intel.com (10.239.4.112) by
	PGSMSX151.gar.corp.intel.com (172.30.236.41) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Wed, 21 Dec 2011 20:07:25 +0800
Received: from shsmsx502.ccr.corp.intel.com ([10.239.4.96]) by
	shsmsx601.ccr.corp.intel.com ([10.239.4.112]) with mapi;
	Wed, 21 Dec 2011 20:07:25 +0800
From: "Wei, Gang" <gang.wei@intel.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Wed, 21 Dec 2011 20:07:24 +0800
Thread-Topic: [patch] x86: Add a delay between INIT & SIPIs for AP bring-up
	in X2APIC case
Thread-Index: Acy/1nAYdBmZFulrQkSecYTe5EWj1gAAaU4w
Message-ID: <F26D193E20BBDC42A43B611D1BDEDE7135CEEEAE62@shsmsx502.ccr.corp.intel.com>
References: <F26D193E20BBDC42A43B611D1BDEDE7135CEEEAE56@shsmsx502.ccr.corp.intel.com>
	<4EF1D5C4020000780006954D@nat28.tlf.novell.com>
In-Reply-To: <4EF1D5C4020000780006954D@nat28.tlf.novell.com>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: zh-CN, en-US
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Keir Fraser <keir@xen.org>, Tim Deegan <Tim.Deegan@citrix.com>,
	"Cihula, Joseph" <joseph.cihula@intel.com>,
	"tboot-devel@lists.sourceforge.net" <tboot-devel@lists.sourceforge.net>,
	"Wei, Gang" <gang.wei@intel.com>
Subject: Re: [Xen-devel] [patch] x86: Add a delay between INIT & SIPIs for
 AP bring-up in X2APIC case
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Jan Beulich wrote on=A02011-12-21:
>>>> On 21.12.11 at 12:22, "Wei, Gang" <gang.wei@intel.com> wrote:
>> Without this delay, Xen could not bring APs up while working with
>> TXT/tboot, because tboot need some time in APs to handle INIT before
>> becoming ready for receiving SIPIs. (this delay was removed as part
>> of c/s 23724 by Tim Deegan)
>> =

>> Signed-off-by: Gang Wei <gang.wei@intel.com>
>> =

>> diff -r d1aefee43af1 xen/arch/x86/smpboot.c
>> --- a/xen/arch/x86/smpboot.c    Wed Dec 21 18:51:31 2011 +0800
>> +++ b/xen/arch/x86/smpboot.c    Wed Dec 21 19:08:57 2011 +0800
>> @@ -463,6 +463,10 @@ static int wakeup_secondary_cpu(int phys
>>              send_status =3D apic_read(APIC_ICR) & APIC_ICR_BUSY;
>>          } while ( send_status && (timeout++ < 1000) );
>>      }
>> +    else
>> +    {
>> +        mdelay(10);
>> +    }
> =

> Does it really need to be this long then (even in the non-TBOOT case)?

No, it could be shorter. I just take a used value back here. If it does mat=
ter, we could use a tested working value here: udelay(10), and for tboot ca=
se only.

Jimmy

> =

> Jan
> =

>> =

>>      /*
>>       * Should we send STARTUP IPIs ?
> =

>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 21 12:10:41 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 12:10:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdL0B-0000Y0-ID; Wed, 21 Dec 2011 12:10:31 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <amscanne@dev.gridcentric.ca>) id 1RctHY-0006RS-Qh
	for xen-devel@lists.xensource.com; Tue, 20 Dec 2011 06:34:37 +0000
X-Env-Sender: amscanne@dev.gridcentric.ca
X-Msg-Ref: server-12.tower-216.messagelabs.com!1324362870!8108774!1
X-Originating-IP: [206.223.182.18]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6767 invoked from network); 20 Dec 2011 06:34:30 -0000
Received: from 206-223-182-18.beanfield.net (HELO dev.gridcentric.ca)
	(206.223.182.18) by server-12.tower-216.messagelabs.com with SMTP;
	20 Dec 2011 06:34:30 -0000
Received: by dev.gridcentric.ca (Postfix, from userid 500)
	id C1A416028C; Tue, 20 Dec 2011 01:36:53 -0500 (EST)
From: Adin Scannell <adin@scannell.ca>
To: xen-devel@lists.xensource.com
Date: Tue, 20 Dec 2011 01:36:50 -0500
Message-Id: <1324363013-11031-1-git-send-email-adin@scannell.ca>
X-Mailer: git-send-email 1.6.2.5
X-Mailman-Approved-At: Wed, 21 Dec 2011 12:10:26 +0000
Cc: olaf@aepfle.de, andres@gridcentric.ca, linux-kernel@vger.kernel.org,
	JBeulich@suse.com, konrad@darnok.org, adin@gridcentric.com
Subject: [Xen-devel] [PATCH 0/3] Add kernel bits necessary to suport Xen
	paging
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This queue now incorporates the feedback received on the last round (sent to
xen-devel), and an additional patch to fix-up the same bits in the original
mmap_batch ioctl.

Here's a summary of this round:
1 - Tiny patch to correctly return the error value for mmu update operations.
2 - Tiny bit of cleanup in the original mmap_batch ioctl.
3 - Implementation of mmap_batch_v2 required by libxc to support paging.

Missing this round however, is the patch that adds support for backend drivers.
These drivers will need retry grant operations appropriate when they receive an
EAGAIN.  This patch will be reworked and sent out independently.

Cheers!
-Adin


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 21 12:10:41 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 12:10:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdL0B-0000Y0-ID; Wed, 21 Dec 2011 12:10:31 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <amscanne@dev.gridcentric.ca>) id 1RctHY-0006RS-Qh
	for xen-devel@lists.xensource.com; Tue, 20 Dec 2011 06:34:37 +0000
X-Env-Sender: amscanne@dev.gridcentric.ca
X-Msg-Ref: server-12.tower-216.messagelabs.com!1324362870!8108774!1
X-Originating-IP: [206.223.182.18]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6767 invoked from network); 20 Dec 2011 06:34:30 -0000
Received: from 206-223-182-18.beanfield.net (HELO dev.gridcentric.ca)
	(206.223.182.18) by server-12.tower-216.messagelabs.com with SMTP;
	20 Dec 2011 06:34:30 -0000
Received: by dev.gridcentric.ca (Postfix, from userid 500)
	id C1A416028C; Tue, 20 Dec 2011 01:36:53 -0500 (EST)
From: Adin Scannell <adin@scannell.ca>
To: xen-devel@lists.xensource.com
Date: Tue, 20 Dec 2011 01:36:50 -0500
Message-Id: <1324363013-11031-1-git-send-email-adin@scannell.ca>
X-Mailer: git-send-email 1.6.2.5
X-Mailman-Approved-At: Wed, 21 Dec 2011 12:10:26 +0000
Cc: olaf@aepfle.de, andres@gridcentric.ca, linux-kernel@vger.kernel.org,
	JBeulich@suse.com, konrad@darnok.org, adin@gridcentric.com
Subject: [Xen-devel] [PATCH 0/3] Add kernel bits necessary to suport Xen
	paging
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This queue now incorporates the feedback received on the last round (sent to
xen-devel), and an additional patch to fix-up the same bits in the original
mmap_batch ioctl.

Here's a summary of this round:
1 - Tiny patch to correctly return the error value for mmu update operations.
2 - Tiny bit of cleanup in the original mmap_batch ioctl.
3 - Implementation of mmap_batch_v2 required by libxc to support paging.

Missing this round however, is the patch that adds support for backend drivers.
These drivers will need retry grant operations appropriate when they receive an
EAGAIN.  This patch will be reworked and sent out independently.

Cheers!
-Adin


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 21 12:10:41 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 12:10:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdL0A-0000XT-95; Wed, 21 Dec 2011 12:10:30 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <adin@scannell.ca>) id 1RblKu-0003sY-3v
	for xen-devel@lists.xensource.com; Sat, 17 Dec 2011 03:53:24 +0000
X-Env-Sender: adin@scannell.ca
X-Msg-Ref: server-9.tower-182.messagelabs.com!1324093997!7611761!1
X-Originating-IP: [206.223.182.18]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26839 invoked from network); 17 Dec 2011 03:53:17 -0000
Received: from 206-223-182-18.beanfield.net (HELO dev.gridcentric.ca)
	(206.223.182.18) by server-9.tower-182.messagelabs.com with SMTP;
	17 Dec 2011 03:53:17 -0000
Received: by dev.gridcentric.ca (Postfix, from userid 500)
	id BB84960289; Fri, 16 Dec 2011 22:55:24 -0500 (EST)
MIME-Version: 1.0
X-Mercurial-Node: 14d42c7d8e0817040186cd01c46f034999fc5dff
Message-Id: <14d42c7d8e0817040186.1324094120@dev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.5.3
Date: Fri, 16 Dec 2011 22:55:20 -0500
From: Adin Scannell <adin@scannell.ca>
To: xen-devel@lists.xensource.com
X-Mailman-Approved-At: Wed, 21 Dec 2011 12:10:26 +0000
Subject: [Xen-devel] [PATCH] Only retry mapping pages when ENOENT is returned
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Adin Scannell <adin@scannell.ca>
# Date 1324094033 18000
# Node ID 14d42c7d8e0817040186cd01c46f034999fc5dff
# Parent  9dcc8557a0cb676b84e6788e03ab596bcfda7143
Only retry mapping pages when ENOENT is returned

If the return value from the ioctl() is not ENOENT, it's possible that err[i]
will not be updated and libxc will just loop forever.  Although it's unlikely
that err[i] would not be updated after the ioctl() gets through at least once,
it's better to be defensive.

diff -r 9dcc8557a0cb -r 14d42c7d8e08 tools/libxc/xc_linux_osdep.c
--- a/tools/libxc/xc_linux_osdep.c
+++ b/tools/libxc/xc_linux_osdep.c
@@ -232,7 +232,7 @@ static void *linux_privcmd_map_foreign_b
             do {
                 usleep(100);
                 rc = ioctl(fd, IOCTL_PRIVCMD_MMAPBATCH_V2, &ioctlx);
-            } while ( rc < 0 && err[i] == -ENOENT );
+            } while ( rc < 0 && errno == ENOENT && err[i] == -ENOENT );
         }
     }
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 21 12:10:41 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 12:10:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdL0A-0000XT-95; Wed, 21 Dec 2011 12:10:30 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <adin@scannell.ca>) id 1RblKu-0003sY-3v
	for xen-devel@lists.xensource.com; Sat, 17 Dec 2011 03:53:24 +0000
X-Env-Sender: adin@scannell.ca
X-Msg-Ref: server-9.tower-182.messagelabs.com!1324093997!7611761!1
X-Originating-IP: [206.223.182.18]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26839 invoked from network); 17 Dec 2011 03:53:17 -0000
Received: from 206-223-182-18.beanfield.net (HELO dev.gridcentric.ca)
	(206.223.182.18) by server-9.tower-182.messagelabs.com with SMTP;
	17 Dec 2011 03:53:17 -0000
Received: by dev.gridcentric.ca (Postfix, from userid 500)
	id BB84960289; Fri, 16 Dec 2011 22:55:24 -0500 (EST)
MIME-Version: 1.0
X-Mercurial-Node: 14d42c7d8e0817040186cd01c46f034999fc5dff
Message-Id: <14d42c7d8e0817040186.1324094120@dev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.5.3
Date: Fri, 16 Dec 2011 22:55:20 -0500
From: Adin Scannell <adin@scannell.ca>
To: xen-devel@lists.xensource.com
X-Mailman-Approved-At: Wed, 21 Dec 2011 12:10:26 +0000
Subject: [Xen-devel] [PATCH] Only retry mapping pages when ENOENT is returned
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Adin Scannell <adin@scannell.ca>
# Date 1324094033 18000
# Node ID 14d42c7d8e0817040186cd01c46f034999fc5dff
# Parent  9dcc8557a0cb676b84e6788e03ab596bcfda7143
Only retry mapping pages when ENOENT is returned

If the return value from the ioctl() is not ENOENT, it's possible that err[i]
will not be updated and libxc will just loop forever.  Although it's unlikely
that err[i] would not be updated after the ioctl() gets through at least once,
it's better to be defensive.

diff -r 9dcc8557a0cb -r 14d42c7d8e08 tools/libxc/xc_linux_osdep.c
--- a/tools/libxc/xc_linux_osdep.c
+++ b/tools/libxc/xc_linux_osdep.c
@@ -232,7 +232,7 @@ static void *linux_privcmd_map_foreign_b
             do {
                 usleep(100);
                 rc = ioctl(fd, IOCTL_PRIVCMD_MMAPBATCH_V2, &ioctlx);
-            } while ( rc < 0 && err[i] == -ENOENT );
+            } while ( rc < 0 && errno == ENOENT && err[i] == -ENOENT );
         }
     }
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 21 12:10:41 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 12:10:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdL09-0000Wy-2q; Wed, 21 Dec 2011 12:10:29 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <amscanne@dev.gridcentric.ca>) id 1Rbkov-0003Ry-VX
	for xen-devel@lists.xensource.com; Sat, 17 Dec 2011 03:20:22 +0000
X-Env-Sender: amscanne@dev.gridcentric.ca
X-Msg-Ref: server-14.tower-21.messagelabs.com!1324092015!7745469!1
X-Originating-IP: [206.223.182.18]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4421 invoked from network); 17 Dec 2011 03:20:15 -0000
Received: from 206-223-182-18.beanfield.net (HELO dev.gridcentric.ca)
	(206.223.182.18) by server-14.tower-21.messagelabs.com with SMTP;
	17 Dec 2011 03:20:15 -0000
Received: by dev.gridcentric.ca (Postfix, from userid 500)
	id CB63F6028D; Fri, 16 Dec 2011 22:22:21 -0500 (EST)
From: Adin Scannell <adin@scannell.ca>
To: xen-devel@lists.xensource.com
Date: Fri, 16 Dec 2011 22:22:18 -0500
Message-Id: <1324092141-9730-1-git-send-email-adin@scannell.ca>
X-Mailer: git-send-email 1.6.2.5
X-Mailman-Approved-At: Wed, 21 Dec 2011 12:10:26 +0000
Cc: konrad@darnok.org, andres@gridcentric.ca, olaf@aepfle.de, JBeulich@suse.com,
	adin@gridcentric.com
Subject: [Xen-devel] [PATCH] Add necessary bits to pvops Linux for mapping
	paged-out pages
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

I've ported a couple of patches to the Linux pvops kernel that are necessary
for correctly running domains with paging.  In a nutshell: in the case of a
foreign attempt to map a paged-out page, the correct error code will now be
propogated up to libxc, which will already handle it correctly.

This required an implementation of mmap_batch_v2.

I've tested it using a highly-paged domain and everything looks okay (qemu will
receive the appropriate error via the mmap_batch_v2 and retry).

(My apologies if anyone/everyone receives this set of patches more than once,
I've had some trouble with both my connection dying and guilt freaking out
while I'm sending, leaving things in a bit of an unknown state.)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 21 12:10:41 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 12:10:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdL0B-0000YF-Tz; Wed, 21 Dec 2011 12:10:31 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <amscanne@dev.gridcentric.ca>) id 1RctHZ-0006RT-7x
	for xen-devel@lists.xensource.com; Tue, 20 Dec 2011 06:34:37 +0000
X-Env-Sender: amscanne@dev.gridcentric.ca
X-Msg-Ref: server-9.tower-182.messagelabs.com!1324362871!7921552!1
X-Originating-IP: [206.223.182.18]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27233 invoked from network); 20 Dec 2011 06:34:31 -0000
Received: from 206-223-182-18.beanfield.net (HELO dev.gridcentric.ca)
	(206.223.182.18) by server-9.tower-182.messagelabs.com with SMTP;
	20 Dec 2011 06:34:31 -0000
Received: by dev.gridcentric.ca (Postfix, from userid 500)
	id 5AFFD6028D; Tue, 20 Dec 2011 01:36:53 -0500 (EST)
From: Adin Scannell <adin@scannell.ca>
To: xen-devel@lists.xensource.com
Date: Tue, 20 Dec 2011 01:36:51 -0500
Message-Id: <1324363013-11031-2-git-send-email-adin@scannell.ca>
X-Mailer: git-send-email 1.6.2.5
In-Reply-To: <1324363013-11031-1-git-send-email-adin@scannell.ca>
References: <1324363013-11031-1-git-send-email-adin@scannell.ca>
X-Mailman-Approved-At: Wed, 21 Dec 2011 12:10:26 +0000
Cc: olaf@aepfle.de, Adin Scannell <adin@scannell.ca>, andres@gridcentric.ca,
	linux-kernel@vger.kernel.org, JBeulich@suse.com,
	konrad@darnok.org, adin@gridcentric.com
Subject: [Xen-devel] [PATCH 1/3] Make xen_remap_domain_mfn_range return
	value meaningful in case of error
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Original patch from Olaf Hering <ohering@novell.com>

This change fixes the xc_map_foreign_bulk interface, which would
otherwise cause SIGBUS when pages are gone because -ENOENT is not
returned as expected by the IOCTL_PRIVCMD_MMAPBATCH_V2 ioctl.

Signed-off-by: Jan Beulich <jbeulich@novell.com>

This is a port to the mainline Linux tree.  Functions were refactored and
renamed.  I believe that this is the only required change to match the
semantics of the original patch.

Signed-off-by: Adin Scannell <adin@scannell.ca>
---
 arch/x86/xen/mmu.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index 87f6673..288a7fc 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -2350,8 +2350,8 @@ int xen_remap_domain_mfn_range(struct vm_area_struct *vma,
 		if (err)
 			goto out;
 
-		err = -EFAULT;
-		if (HYPERVISOR_mmu_update(mmu_update, batch, NULL, domid) < 0)
+		err = HYPERVISOR_mmu_update(mmu_update, batch, NULL, domid);
+		if (err < 0)
 			goto out;
 
 		nr -= batch;
-- 
1.6.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 21 12:10:41 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 12:10:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdL09-0000Wy-2q; Wed, 21 Dec 2011 12:10:29 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <amscanne@dev.gridcentric.ca>) id 1Rbkov-0003Ry-VX
	for xen-devel@lists.xensource.com; Sat, 17 Dec 2011 03:20:22 +0000
X-Env-Sender: amscanne@dev.gridcentric.ca
X-Msg-Ref: server-14.tower-21.messagelabs.com!1324092015!7745469!1
X-Originating-IP: [206.223.182.18]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4421 invoked from network); 17 Dec 2011 03:20:15 -0000
Received: from 206-223-182-18.beanfield.net (HELO dev.gridcentric.ca)
	(206.223.182.18) by server-14.tower-21.messagelabs.com with SMTP;
	17 Dec 2011 03:20:15 -0000
Received: by dev.gridcentric.ca (Postfix, from userid 500)
	id CB63F6028D; Fri, 16 Dec 2011 22:22:21 -0500 (EST)
From: Adin Scannell <adin@scannell.ca>
To: xen-devel@lists.xensource.com
Date: Fri, 16 Dec 2011 22:22:18 -0500
Message-Id: <1324092141-9730-1-git-send-email-adin@scannell.ca>
X-Mailer: git-send-email 1.6.2.5
X-Mailman-Approved-At: Wed, 21 Dec 2011 12:10:26 +0000
Cc: konrad@darnok.org, andres@gridcentric.ca, olaf@aepfle.de, JBeulich@suse.com,
	adin@gridcentric.com
Subject: [Xen-devel] [PATCH] Add necessary bits to pvops Linux for mapping
	paged-out pages
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

I've ported a couple of patches to the Linux pvops kernel that are necessary
for correctly running domains with paging.  In a nutshell: in the case of a
foreign attempt to map a paged-out page, the correct error code will now be
propogated up to libxc, which will already handle it correctly.

This required an implementation of mmap_batch_v2.

I've tested it using a highly-paged domain and everything looks okay (qemu will
receive the appropriate error via the mmap_batch_v2 and retry).

(My apologies if anyone/everyone receives this set of patches more than once,
I've had some trouble with both my connection dying and guilt freaking out
while I'm sending, leaving things in a bit of an unknown state.)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 21 12:10:41 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 12:10:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdL0B-0000YF-Tz; Wed, 21 Dec 2011 12:10:31 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <amscanne@dev.gridcentric.ca>) id 1RctHZ-0006RT-7x
	for xen-devel@lists.xensource.com; Tue, 20 Dec 2011 06:34:37 +0000
X-Env-Sender: amscanne@dev.gridcentric.ca
X-Msg-Ref: server-9.tower-182.messagelabs.com!1324362871!7921552!1
X-Originating-IP: [206.223.182.18]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27233 invoked from network); 20 Dec 2011 06:34:31 -0000
Received: from 206-223-182-18.beanfield.net (HELO dev.gridcentric.ca)
	(206.223.182.18) by server-9.tower-182.messagelabs.com with SMTP;
	20 Dec 2011 06:34:31 -0000
Received: by dev.gridcentric.ca (Postfix, from userid 500)
	id 5AFFD6028D; Tue, 20 Dec 2011 01:36:53 -0500 (EST)
From: Adin Scannell <adin@scannell.ca>
To: xen-devel@lists.xensource.com
Date: Tue, 20 Dec 2011 01:36:51 -0500
Message-Id: <1324363013-11031-2-git-send-email-adin@scannell.ca>
X-Mailer: git-send-email 1.6.2.5
In-Reply-To: <1324363013-11031-1-git-send-email-adin@scannell.ca>
References: <1324363013-11031-1-git-send-email-adin@scannell.ca>
X-Mailman-Approved-At: Wed, 21 Dec 2011 12:10:26 +0000
Cc: olaf@aepfle.de, Adin Scannell <adin@scannell.ca>, andres@gridcentric.ca,
	linux-kernel@vger.kernel.org, JBeulich@suse.com,
	konrad@darnok.org, adin@gridcentric.com
Subject: [Xen-devel] [PATCH 1/3] Make xen_remap_domain_mfn_range return
	value meaningful in case of error
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Original patch from Olaf Hering <ohering@novell.com>

This change fixes the xc_map_foreign_bulk interface, which would
otherwise cause SIGBUS when pages are gone because -ENOENT is not
returned as expected by the IOCTL_PRIVCMD_MMAPBATCH_V2 ioctl.

Signed-off-by: Jan Beulich <jbeulich@novell.com>

This is a port to the mainline Linux tree.  Functions were refactored and
renamed.  I believe that this is the only required change to match the
semantics of the original patch.

Signed-off-by: Adin Scannell <adin@scannell.ca>
---
 arch/x86/xen/mmu.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index 87f6673..288a7fc 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -2350,8 +2350,8 @@ int xen_remap_domain_mfn_range(struct vm_area_struct *vma,
 		if (err)
 			goto out;
 
-		err = -EFAULT;
-		if (HYPERVISOR_mmu_update(mmu_update, batch, NULL, domid) < 0)
+		err = HYPERVISOR_mmu_update(mmu_update, batch, NULL, domid);
+		if (err < 0)
 			goto out;
 
 		nr -= batch;
-- 
1.6.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 21 12:10:42 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 12:10:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdL08-0000Wh-8o; Wed, 21 Dec 2011 12:10:28 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <catalin.marinas@arm.com>) id 1RbbsS-00086h-Ey
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 17:47:24 +0000
X-Env-Sender: catalin.marinas@arm.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1324057637!7575910!1
X-Originating-IP: [217.140.96.50]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20261 invoked from network); 16 Dec 2011 17:47:17 -0000
Received: from cam-admin0.cambridge.arm.com (HELO
	cam-admin0.cambridge.arm.com) (217.140.96.50)
	by server-9.tower-182.messagelabs.com with SMTP;
	16 Dec 2011 17:47:17 -0000
Received: from arm.com (e102109-lin.cambridge.arm.com [10.1.69.68])
	by cam-admin0.cambridge.arm.com (8.12.6/8.12.6) with ESMTP id
	pBGHl8WJ023933; Fri, 16 Dec 2011 17:47:08 GMT
Date: Fri, 16 Dec 2011 17:47:04 +0000
From: Catalin Marinas <catalin.marinas@arm.com>
To: David Vrabel <david.vrabel@citrix.com>
Message-ID: <20111216174704.GF6342@arm.com>
References: <alpine.DEB.2.00.1111281009090.31179@kaball-desktop>
	<201111292129.20444.arnd@arndb.de>
	<alpine.DEB.2.00.1111301053300.31179@kaball-desktop>
	<CAHkRjk48jHO19H04rf8252+v04hk9qSdKBrfYCqJsZyamVhMEw@mail.gmail.com>
	<4EEB673D.3040608@citrix.com> <20111216165420.GE6342@arm.com>
	<4EEB822C.7010809@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4EEB822C.7010809@citrix.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
X-Mailman-Approved-At: Wed, 21 Dec 2011 12:10:26 +0000
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>, Arnd Bergmann <arnd@arndb.de>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [ANNOUNCE] Xen port to Cortex-A15 / ARMv7 with virt
 extensions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Dec 16, 2011 at 05:38:52PM +0000, David Vrabel wrote:
> On 16/12/11 16:54, Catalin Marinas wrote:
> > On Fri, Dec 16, 2011 at 03:43:57PM +0000, David Vrabel wrote:
> >> On 30/11/11 14:11, Catalin Marinas wrote:
> >>> On 30 November 2011 11:39, Stefano Stabellini
> >>> <stefano.stabellini@eu.citrix.com> wrote:
> >>>> A git branch is available here (not ready for submission):
> >>>>
> >>>> git://xenbits.xen.org/people/sstabellini/linux-pvhvm.git arm
> >>>>
> >>>> the branch above is based on git://linux-arm.org/linux-2.6.git arm-lpae,
> >>>> even though guests don't really need lpae support to run on Xen.
> >>>
> >>> Indeed, you don't really need LPAE. What you may need though is
> >>> generic timers support for A15, it would allow less Hypervisor traps.
> >>> For up-to-date architecture patches (well, development tree, not
> >>> guaranteed to be stable), I would recommend this (they get into
> >>> mainline at some point):
> >>>
> >>> http://git.kernel.org/?p=linux/kernel/git/cmarinas/linux-arm-arch.git;a=summary
> >>>
> >>> Either use master or just cherry-pick the branches that you are interested in.
> >>
> >> Which branches are required for the Versatile Express with the
> >> Cortex-A15? I merged linux-arm-arch/arm-arch/vexpress in
> > 
> > That's the branch if you only need VE and A15 support
> > 
> >> but I get a
> >> instruction fault immediately after branching to __mmap_switched.
> >>
> >> Is it not setting up the MMU correctly?
> > 
> > Do you run this on a software model? What config options do you use? You
> > would need to enable VEXPRESS_EXTENDED_MEMORY_MAP and
> > ARCH_VEXPRESS_CA15X4.
> 
> The envelope model, yes.  Both those options are enabled.  I've also
> attached the complete config and the model configuration.
> 
> I took a closer look at the diffs between what Stefano had in his tree
> (which included a bunch of LPAE support which I don't have enabled) and
> the kernel boots the addition of some isb's when the MMU is switched on.
> 
> These were added by: "ARM: LPAE: add ISBs around MMU enabling code"
> (commit 1c553c2 in your tree) which is think is only present in the LPAE
> branch.  Is this patch not actually specific to LPAE?  Are there other
> similar patches?

This patch is not specific to LPAE, it's an architecture requirement and
it became visible with A15. The complete patch is here:

http://git.kernel.org/?p=linux/kernel/git/cmarinas/linux-arm-arch.git;a=commitdiff;h=1c553c2afdd7a57cf874a38925bc58381b28150b

though I only kept it in my LPAE branch (which is on it's way to
mainline for 3.3-rc1).

-- 
Catalin

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 21 12:10:42 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 12:10:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdL08-0000Wh-8o; Wed, 21 Dec 2011 12:10:28 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <catalin.marinas@arm.com>) id 1RbbsS-00086h-Ey
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 17:47:24 +0000
X-Env-Sender: catalin.marinas@arm.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1324057637!7575910!1
X-Originating-IP: [217.140.96.50]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20261 invoked from network); 16 Dec 2011 17:47:17 -0000
Received: from cam-admin0.cambridge.arm.com (HELO
	cam-admin0.cambridge.arm.com) (217.140.96.50)
	by server-9.tower-182.messagelabs.com with SMTP;
	16 Dec 2011 17:47:17 -0000
Received: from arm.com (e102109-lin.cambridge.arm.com [10.1.69.68])
	by cam-admin0.cambridge.arm.com (8.12.6/8.12.6) with ESMTP id
	pBGHl8WJ023933; Fri, 16 Dec 2011 17:47:08 GMT
Date: Fri, 16 Dec 2011 17:47:04 +0000
From: Catalin Marinas <catalin.marinas@arm.com>
To: David Vrabel <david.vrabel@citrix.com>
Message-ID: <20111216174704.GF6342@arm.com>
References: <alpine.DEB.2.00.1111281009090.31179@kaball-desktop>
	<201111292129.20444.arnd@arndb.de>
	<alpine.DEB.2.00.1111301053300.31179@kaball-desktop>
	<CAHkRjk48jHO19H04rf8252+v04hk9qSdKBrfYCqJsZyamVhMEw@mail.gmail.com>
	<4EEB673D.3040608@citrix.com> <20111216165420.GE6342@arm.com>
	<4EEB822C.7010809@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4EEB822C.7010809@citrix.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
X-Mailman-Approved-At: Wed, 21 Dec 2011 12:10:26 +0000
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>, Arnd Bergmann <arnd@arndb.de>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [ANNOUNCE] Xen port to Cortex-A15 / ARMv7 with virt
 extensions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Dec 16, 2011 at 05:38:52PM +0000, David Vrabel wrote:
> On 16/12/11 16:54, Catalin Marinas wrote:
> > On Fri, Dec 16, 2011 at 03:43:57PM +0000, David Vrabel wrote:
> >> On 30/11/11 14:11, Catalin Marinas wrote:
> >>> On 30 November 2011 11:39, Stefano Stabellini
> >>> <stefano.stabellini@eu.citrix.com> wrote:
> >>>> A git branch is available here (not ready for submission):
> >>>>
> >>>> git://xenbits.xen.org/people/sstabellini/linux-pvhvm.git arm
> >>>>
> >>>> the branch above is based on git://linux-arm.org/linux-2.6.git arm-lpae,
> >>>> even though guests don't really need lpae support to run on Xen.
> >>>
> >>> Indeed, you don't really need LPAE. What you may need though is
> >>> generic timers support for A15, it would allow less Hypervisor traps.
> >>> For up-to-date architecture patches (well, development tree, not
> >>> guaranteed to be stable), I would recommend this (they get into
> >>> mainline at some point):
> >>>
> >>> http://git.kernel.org/?p=linux/kernel/git/cmarinas/linux-arm-arch.git;a=summary
> >>>
> >>> Either use master or just cherry-pick the branches that you are interested in.
> >>
> >> Which branches are required for the Versatile Express with the
> >> Cortex-A15? I merged linux-arm-arch/arm-arch/vexpress in
> > 
> > That's the branch if you only need VE and A15 support
> > 
> >> but I get a
> >> instruction fault immediately after branching to __mmap_switched.
> >>
> >> Is it not setting up the MMU correctly?
> > 
> > Do you run this on a software model? What config options do you use? You
> > would need to enable VEXPRESS_EXTENDED_MEMORY_MAP and
> > ARCH_VEXPRESS_CA15X4.
> 
> The envelope model, yes.  Both those options are enabled.  I've also
> attached the complete config and the model configuration.
> 
> I took a closer look at the diffs between what Stefano had in his tree
> (which included a bunch of LPAE support which I don't have enabled) and
> the kernel boots the addition of some isb's when the MMU is switched on.
> 
> These were added by: "ARM: LPAE: add ISBs around MMU enabling code"
> (commit 1c553c2 in your tree) which is think is only present in the LPAE
> branch.  Is this patch not actually specific to LPAE?  Are there other
> similar patches?

This patch is not specific to LPAE, it's an architecture requirement and
it became visible with A15. The complete patch is here:

http://git.kernel.org/?p=linux/kernel/git/cmarinas/linux-arm-arch.git;a=commitdiff;h=1c553c2afdd7a57cf874a38925bc58381b28150b

though I only kept it in my LPAE branch (which is on it's way to
mainline for 3.3-rc1).

-- 
Catalin

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 21 12:10:42 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 12:10:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdL0D-0000ZD-57; Wed, 21 Dec 2011 12:10:33 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <maydin.work@gmail.com>) id 1Rd8hd-0001Sk-Er
	for xen-devel@lists.xensource.com; Tue, 20 Dec 2011 23:02:33 +0000
X-Env-Sender: maydin.work@gmail.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1324422146!6332819!1
X-Originating-IP: [74.125.83.43]
X-SpamReason: No, hits=1.5 required=7.0 tests=HTML_00_10,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19606 invoked from network); 20 Dec 2011 23:02:26 -0000
Received: from mail-ee0-f43.google.com (HELO mail-ee0-f43.google.com)
	(74.125.83.43)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Dec 2011 23:02:26 -0000
Received: by eekd4 with SMTP id d4so33546408eek.30
	for <xen-devel@lists.xensource.com>;
	Tue, 20 Dec 2011 15:02:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=/EcpklEZY8gk8SkqqmXIBKbg8QVcTUr5XbuI3EP5ps8=;
	b=BVhg3r9DfOjYrVEG2X4A6y9y3WWYXfJw9x++l3J/kgu5xcgA+c0R2hLFvRimTeIFij
	TnJWZ4KISzLXIYysB7z+KS22zzFyF86Og1HG3gx0Yui6kAd+MmNVSZrJXFkSnhAdBQW/
	s7dZ7iOkGlb4F07BTR2Y8uPdAw/788t6hWyYA=
MIME-Version: 1.0
Received: by 10.14.16.77 with SMTP id g53mr1697456eeg.19.1324422146160; Tue,
	20 Dec 2011 15:02:26 -0800 (PST)
Received: by 10.213.34.77 with HTTP; Tue, 20 Dec 2011 15:02:26 -0800 (PST)
Date: Tue, 20 Dec 2011 23:02:26 +0000
Message-ID: <CALF+9DFCeYu2E1xBuHOW4n_7J9kz0H4Ngv1BY_Rn8d-SwDb3VA@mail.gmail.com>
From: Mustafa Aydin <maydin.work@gmail.com>
To: xen-devel@lists.xensource.com
X-Mailman-Approved-At: Wed, 21 Dec 2011 12:10:26 +0000
Subject: [Xen-devel] Xen interfaces / hooks
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6238205227377435196=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============6238205227377435196==
Content-Type: multipart/alternative; boundary=0016e65060908df7dd04b48e0f7c

--0016e65060908df7dd04b48e0f7c
Content-Type: text/plain; charset=ISO-8859-1

Hello all,

I have been looking through the internet and through the wiki, trying to
find something which explains in details the available interfaces with
which one might be able to insert some code to make some slight additions
to Xen functionality. I am doing some research on the possibility of adding
some extra functionality to Xen, and my supervisor has mentioned that these
are things worth looking into (he called them modules / kernel modules).

Is there a source of info which lists these tools please? Although I have
spent today going through many pages and searching I could not find
anything, although perhaps I was using some incorrect terms.

All the best,

Muhammed

--0016e65060908df7dd04b48e0f7c
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hello all,<br><br>I have been looking through the internet and through the =
wiki, trying to find something which explains in details the available inte=
rfaces with which one might be able to insert some code to make some slight=
 additions to Xen functionality. I am doing some research on the possibilit=
y of adding some extra functionality to Xen, and my supervisor has mentione=
d that these are things worth looking into (he called them modules / kernel=
 modules). <br>
<br>Is there a source of info which lists these tools please? Although I ha=
ve spent today going through many pages and searching I could not find anyt=
hing, although perhaps I was using some incorrect terms. <br><br>All the be=
st,<br>
<br>Muhammed<br>

--0016e65060908df7dd04b48e0f7c--


--===============6238205227377435196==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============6238205227377435196==--


From xen-devel-bounces@lists.xensource.com Wed Dec 21 12:10:42 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 12:10:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdL07-0000WZ-RD; Wed, 21 Dec 2011 12:10:27 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <catalin.marinas@arm.com>) id 1Rbb3U-00060W-Nr
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 16:54:44 +0000
X-Env-Sender: catalin.marinas@arm.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1324054477!5663945!1
X-Originating-IP: [217.140.96.50]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4549 invoked from network); 16 Dec 2011 16:54:37 -0000
Received: from cam-admin0.cambridge.arm.com (HELO
	cam-admin0.cambridge.arm.com) (217.140.96.50)
	by server-14.tower-174.messagelabs.com with SMTP;
	16 Dec 2011 16:54:37 -0000
Received: from arm.com (e102109-lin.cambridge.arm.com [10.1.69.68])
	by cam-admin0.cambridge.arm.com (8.12.6/8.12.6) with ESMTP id
	pBGGsOWJ014769; Fri, 16 Dec 2011 16:54:25 GMT
Date: Fri, 16 Dec 2011 16:54:20 +0000
From: Catalin Marinas <catalin.marinas@arm.com>
To: David Vrabel <david.vrabel@citrix.com>
Message-ID: <20111216165420.GE6342@arm.com>
References: <alpine.DEB.2.00.1111281009090.31179@kaball-desktop>
	<201111292129.20444.arnd@arndb.de>
	<alpine.DEB.2.00.1111301053300.31179@kaball-desktop>
	<CAHkRjk48jHO19H04rf8252+v04hk9qSdKBrfYCqJsZyamVhMEw@mail.gmail.com>
	<4EEB673D.3040608@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4EEB673D.3040608@citrix.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
X-Mailman-Approved-At: Wed, 21 Dec 2011 12:10:26 +0000
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>, Arnd Bergmann <arnd@arndb.de>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [ANNOUNCE] Xen port to Cortex-A15 / ARMv7 with virt
 extensions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Dec 16, 2011 at 03:43:57PM +0000, David Vrabel wrote:
> On 30/11/11 14:11, Catalin Marinas wrote:
> > On 30 November 2011 11:39, Stefano Stabellini
> > <stefano.stabellini@eu.citrix.com> wrote:
> >> A git branch is available here (not ready for submission):
> >>
> >> git://xenbits.xen.org/people/sstabellini/linux-pvhvm.git arm
> >>
> >> the branch above is based on git://linux-arm.org/linux-2.6.git arm-lpae,
> >> even though guests don't really need lpae support to run on Xen.
> > 
> > Indeed, you don't really need LPAE. What you may need though is
> > generic timers support for A15, it would allow less Hypervisor traps.
> > For up-to-date architecture patches (well, development tree, not
> > guaranteed to be stable), I would recommend this (they get into
> > mainline at some point):
> > 
> > http://git.kernel.org/?p=linux/kernel/git/cmarinas/linux-arm-arch.git;a=summary
> > 
> > Either use master or just cherry-pick the branches that you are interested in.
> 
> Which branches are required for the Versatile Express with the
> Cortex-A15? I merged linux-arm-arch/arm-arch/vexpress in

That's the branch if you only need VE and A15 support

> but I get a
> instruction fault immediately after branching to __mmap_switched.
> 
> Is it not setting up the MMU correctly?

Do you run this on a software model? What config options do you use? You
would need to enable VEXPRESS_EXTENDED_MEMORY_MAP and
ARCH_VEXPRESS_CA15X4.

-- 
Catalin

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 21 12:10:42 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 12:10:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdL08-0000Wq-Lu; Wed, 21 Dec 2011 12:10:28 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <amscanne@dev.gridcentric.ca>) id 1Rbkor-0003Rz-5A
	for xen-devel@lists.xensource.com; Sat, 17 Dec 2011 03:20:17 +0000
X-Env-Sender: amscanne@dev.gridcentric.ca
X-Msg-Ref: server-3.tower-27.messagelabs.com!1324091970!49382572!1
X-Originating-IP: [206.223.182.18]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16902 invoked from network); 17 Dec 2011 03:19:31 -0000
Received: from 206-223-182-18.beanfield.net (HELO dev.gridcentric.ca)
	(206.223.182.18) by server-3.tower-27.messagelabs.com with SMTP;
	17 Dec 2011 03:19:31 -0000
Received: by dev.gridcentric.ca (Postfix, from userid 500)
	id 21E556028A; Fri, 16 Dec 2011 22:22:21 -0500 (EST)
From: Adin Scannell <adin@scannell.ca>
To: xen-devel@lists.xensource.com
Date: Fri, 16 Dec 2011 22:22:19 -0500
Message-Id: <1324092141-9730-2-git-send-email-adin@scannell.ca>
X-Mailer: git-send-email 1.6.2.5
In-Reply-To: <1324092141-9730-1-git-send-email-adin@scannell.ca>
References: <1324092141-9730-1-git-send-email-adin@scannell.ca>
X-Mailman-Approved-At: Wed, 21 Dec 2011 12:10:26 +0000
Cc: olaf@aepfle.de, Adin Scannell <adin@scannell.ca>, andres@gridcentric.ca,
	JBeulich@suse.com, konrad@darnok.org, adin@gridcentric.com
Subject: [Xen-devel] [PATCH 1/3] Make xen_remap_domain_mfn_range return
	value meaningful in case of error
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Original patch from Olaf Hering <ohering@novell.com>

This change fixes the xc_map_foreign_bulk interface, which would
otherwise cause SIGBUS when pages are gone because -ENOENT is not
returned as expected by the IOCTL_PRIVCMD_MMAPBATCH_V2 ioctl.

Signed-off-by: Jan Beulich <jbeulich@novell.com>

This is a port to the mainline Linux tree.  Functions were refactored and
renamed.  I believe that this is the only required change to match the
semantics of the original patch.

Signed-off-by: Adin Scannell <adin@scannell.ca>
---
 arch/x86/xen/mmu.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index 87f6673..288a7fc 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -2350,8 +2350,8 @@ int xen_remap_domain_mfn_range(struct vm_area_struct *vma,
 		if (err)
 			goto out;
 
-		err = -EFAULT;
-		if (HYPERVISOR_mmu_update(mmu_update, batch, NULL, domid) < 0)
+		err = HYPERVISOR_mmu_update(mmu_update, batch, NULL, domid);
+		if (err < 0)
 			goto out;
 
 		nr -= batch;
-- 
1.6.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 21 12:10:42 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 12:10:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdL0A-0000Xc-MM; Wed, 21 Dec 2011 12:10:30 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RcbOV-00039Q-P1
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 11:28:35 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1324294062!57856680!1
X-Originating-IP: [209.85.210.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8419 invoked from network); 19 Dec 2011 11:27:43 -0000
Received: from mail-pz0-f43.google.com (HELO mail-pz0-f43.google.com)
	(209.85.210.43)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Dec 2011 11:27:43 -0000
Received: by daec6 with SMTP id c6so25102531dae.30
	for <xen-devel@lists.xensource.com>;
	Mon, 19 Dec 2011 03:28:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	bh=/+rQcSN7K83yOQKeAd95qEV3sDkpOdgkbCNKcEvN1hQ=;
	b=HojTKGmDO/woBM1y8DsT4P7U1r1UTZI0uSw1PSkqzKtqWhfNBdDs0th3r6grvi0XTr
	EKMMW2iBHHIJ4pbgI/hL0pkpVWcQCO4vnKORGK5FxsfBvddfOkchhcwwTWZH4pVFOsT6
	3iHtzXCkx8Y3v0r6XZrtpWJuIjtDc0sDFmf2I=
MIME-Version: 1.0
Received: by 10.68.74.70 with SMTP id r6mr37745600pbv.78.1324294112482; Mon,
	19 Dec 2011 03:28:32 -0800 (PST)
Received: by 10.142.47.17 with HTTP; Mon, 19 Dec 2011 03:28:32 -0800 (PST)
In-Reply-To: <1324294068.9236.28.camel@zakaz.uk.xensource.com>
References: <patchbomb.1324212500@alpine.localdomain>
	<eed78eb655c40b0ac9af.1324212501@alpine.localdomain>
	<1324288096.9236.6.camel@zakaz.uk.xensource.com>
	<CAPLaKK7gEUv9bavavzyYjREPDZJepMkK+-Ap78xzHjPy4SvZ3g@mail.gmail.com>
	<1324289291.9236.16.camel@zakaz.uk.xensource.com>
	<CAPLaKK6=O_h+OxOc_qDLUkw22hV2t6t9wfXOKVuoJf+Ny5+P9g@mail.gmail.com>
	<1324294068.9236.28.camel@zakaz.uk.xensource.com>
Date: Mon, 19 Dec 2011 12:28:32 +0100
Message-ID: <CAPLaKK771o2-_c=3huGH8ei3jAvL26en=Lu+QCuvdMFbZTi24Q@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <royger@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
X-Mailman-Approved-At: Wed, 21 Dec 2011 12:10:26 +0000
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 1 of 5] blktap: remove HAVE_BYTESWAP_H
 checking, since it's defined by qemu
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

MjAxMS8xMi8xOSBJYW4gQ2FtcGJlbGwgPElhbi5DYW1wYmVsbEBjaXRyaXguY29tPjoKPiBPbiBN
b24sIDIwMTEtMTItMTkgYXQgMTE6MjYgKzAwMDAsIFJvZ2VyIFBhdSBNb25uw6kgd3JvdGU6Cj4+
IDIwMTEvMTIvMTkgSWFuIENhbXBiZWxsIDxJYW4uQ2FtcGJlbGxAY2l0cml4LmNvbT46Cj4+ID4g
SSB0aGluayB0aGlzIGlzIHRoZSBjb3JyZWN0IG9wdGlvbi4gTm8gbmVlZCB0byB1bmRlZiBzdHVm
Zi4gVGhlcmUgaXMKPj4gPiBvbmx5IG9uZSBvdGhlciBpbmNsdWRlIG9mIGJ5dGVzd2FwLmggaW4g
YmxrdGFwLgo+PiA+Cj4+Cj4+IE9uIHVjbGliYywgYnl0ZXN3YXAuaCBnZXRzIGluY2x1ZGVkIGJ5
IGRlZmF1bHQsIGJlY2F1c2UgX0dOVV9TT1VSQ0UKPj4gaW1wbGllcyBfQlNEX1NPVVJDRSB0aGVy
ZS4gT25lIHNvbHV0aW9uIGlzIHRvIGFkZCBfUE9TSVhfU09VUkNFLCB3aGljaAo+PiBwcmV2ZW50
cyB0aGUgYWRkaXRpb24gb2YgX0JTRF9TT1VSQ0UuCj4KPiBXaGF0IHBhdGggb2YgaW5jbHVkZXMg
bGVhZHMgdG8gdGhlIGluY2x1c2lvbiBvZiBieXRlc3dhcC5oPwoKVGhpcyBvbmU6CgpzdGRsaWIu
aCAtPiBzeXMvdHlwZXMuaCAtPiBlbmRpYW4uaCAtPiAoYmVjYXN1ZSBfX1VTRV9CU0QgaXMgZGVm
aW5lZCkgYnl0ZXN3YXAuaAoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuc291cmNl
LmNvbQpodHRwOi8vbGlzdHMueGVuc291cmNlLmNvbS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Wed Dec 21 12:10:42 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 12:10:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdL09-0000X7-Fp; Wed, 21 Dec 2011 12:10:29 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <amscanne@dev.gridcentric.ca>) id 1Rbkow-0003S0-U7
	for xen-devel@lists.xensource.com; Sat, 17 Dec 2011 03:20:23 +0000
X-Env-Sender: amscanne@dev.gridcentric.ca
X-Msg-Ref: server-12.tower-174.messagelabs.com!1324092015!5853893!1
X-Originating-IP: [206.223.182.18]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23975 invoked from network); 17 Dec 2011 03:20:15 -0000
Received: from 206-223-182-18.beanfield.net (HELO dev.gridcentric.ca)
	(206.223.182.18) by server-12.tower-174.messagelabs.com with SMTP;
	17 Dec 2011 03:20:15 -0000
Received: by dev.gridcentric.ca (Postfix, from userid 500)
	id 0DAA760284; Fri, 16 Dec 2011 22:22:21 -0500 (EST)
From: Adin Scannell <adin@scannell.ca>
To: xen-devel@lists.xensource.com
Date: Fri, 16 Dec 2011 22:22:20 -0500
Message-Id: <1324092141-9730-3-git-send-email-adin@scannell.ca>
X-Mailer: git-send-email 1.6.2.5
In-Reply-To: <1324092141-9730-1-git-send-email-adin@scannell.ca>
References: <1324092141-9730-1-git-send-email-adin@scannell.ca>
X-Mailman-Approved-At: Wed, 21 Dec 2011 12:10:26 +0000
Cc: olaf@aepfle.de, Adin Scannell <adin@scannell.ca>, andres@gridcentric.ca,
	JBeulich@suse.com, konrad@darnok.org, adin@gridcentric.com
Subject: [Xen-devel] [PATCH 2/3] Handle GNTST_eagain in kernel drivers
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Handle GNTST_eagain status from GNTTABOP_map_grant_ref and
GNTTABOP_copy operations properly to allow usage of xenpaging without
causing crashes or data corruption.

Replace all relevant HYPERVISOR_grant_table_op() calls with a retry
loop. This loop is implemented as a macro to allow different
GNTTABOP_* args. It will sleep up to 33 seconds and wait for the
page to be paged in again.

All ->status checks were updated to use the GNTST_* namespace. All
return values are converted from GNTST_* namespace to 0/-EINVAL, since
all callers did not use the actual return value.

Signed-off-by: Olaf Hering <olaf@aepfle.de>
Acked-by: Patrick Colp <pjcolp@cs.ubc.ca>

This is a port to the mainline Linux tree.  This required dropping many backend
drivers which have not yet made it in.  Additionally, several of the referenced
functions have moved and/or been refactored.  I attempted to minimize changes
while keeping the same semantics.

Signed-off-by: Adin Scannell <adin@scannell.ca>

Index: linux/drivers/block/xen-blkback/blkback.c
===================================================================
---
 drivers/block/xen-blkback/blkback.c |    4 ++-
 drivers/xen/grant-table.c           |    7 ++++-
 drivers/xen/xenbus/xenbus_client.c  |    4 +++
 include/xen/grant_table.h           |   39 +++++++++++++++++++++++++++++++++++
 include/xen/interface/grant_table.h |    6 ++++-
 5 files changed, 56 insertions(+), 4 deletions(-)

diff --git a/drivers/block/xen-blkback/blkback.c b/drivers/block/xen-blkback/blkback.c
index 15ec4db..d3fb290 100644
--- a/drivers/block/xen-blkback/blkback.c
+++ b/drivers/block/xen-blkback/blkback.c
@@ -390,7 +390,9 @@ static int xen_blkbk_map(struct blkif_request *req,
 	 * the page from the other domain.
 	 */
 	for (i = 0; i < nseg; i++) {
-		if (unlikely(map[i].status != 0)) {
+		if (unlikely(map[i].status == GNTST_eagain))
+			gnttab_check_GNTST_eagain_do_while(GNTTABOP_map_grant_ref, &map[i]);
+		if (unlikely(map[i].status != GNTST_okay)) {
 			pr_debug(DRV_PFX "invalid buffer -- could not remap it\n");
 			map[i].handle = BLKBACK_INVALID_HANDLE;
 			ret |= 1;
diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
index bf1c094..48826c3 100644
--- a/drivers/xen/grant-table.c
+++ b/drivers/xen/grant-table.c
@@ -464,9 +464,12 @@ int gnttab_map_refs(struct gnttab_map_grant_ref *map_ops,
 
 	for (i = 0; i < count; i++) {
 		/* Do not add to override if the map failed. */
-		if (map_ops[i].status)
+		if (map_ops[i].status != GNTST_okay && map_ops[i].status != GNTST_eagain)
 			continue;
 
+		if (map_ops[i].status == GNTST_eagain)
+			return -EAGAIN;
+
 		if (map_ops[i].flags & GNTMAP_contains_pte) {
 			pte = (pte_t *) (mfn_to_virt(PFN_DOWN(map_ops[i].host_addr)) +
 				(map_ops[i].host_addr & ~PAGE_MASK));
@@ -565,7 +568,7 @@ static int gnttab_map(unsigned int start_idx, unsigned int end_idx)
 		return -ENOSYS;
 	}
 
-	BUG_ON(rc || setup.status);
+	BUG_ON(rc || (setup.status != GNTST_okay));
 
 	rc = arch_gnttab_map_shared(frames, nr_gframes, gnttab_max_grant_frames(),
 				    &shared);
diff --git a/drivers/xen/xenbus/xenbus_client.c b/drivers/xen/xenbus/xenbus_client.c
index 1906125..d123c78 100644
--- a/drivers/xen/xenbus/xenbus_client.c
+++ b/drivers/xen/xenbus/xenbus_client.c
@@ -455,6 +455,8 @@ int xenbus_map_ring_valloc(struct xenbus_device *dev, int gnt_ref, void **vaddr)
 	if (HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, &op, 1))
 		BUG();
 
+	if (op.status == GNTST_eagain)
+		gnttab_check_GNTST_eagain_do_while(GNTTABOP_map_grant_ref, (&op));
 	if (op.status != GNTST_okay) {
 		free_vm_area(area);
 		xenbus_dev_fatal(dev, op.status,
@@ -499,6 +501,8 @@ int xenbus_map_ring(struct xenbus_device *dev, int gnt_ref,
 	if (HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, &op, 1))
 		BUG();
 
+	if (op.status == GNTST_eagain)
+		gnttab_check_GNTST_eagain_do_while(GNTTABOP_map_grant_ref, (&op));
 	if (op.status != GNTST_okay) {
 		xenbus_dev_fatal(dev, op.status,
 				 "mapping in shared page %d from domain %d",
diff --git a/include/xen/grant_table.h b/include/xen/grant_table.h
index 11e2dfc..46fac85 100644
--- a/include/xen/grant_table.h
+++ b/include/xen/grant_table.h
@@ -37,6 +37,8 @@
 #ifndef __ASM_GNTTAB_H__
 #define __ASM_GNTTAB_H__
 
+#include <linux/delay.h>
+
 #include <asm/page.h>
 
 #include <xen/interface/xen.h>
@@ -160,4 +162,41 @@ int gnttab_map_refs(struct gnttab_map_grant_ref *map_ops,
 int gnttab_unmap_refs(struct gnttab_unmap_grant_ref *unmap_ops,
 		      struct page **pages, unsigned int count);
 
+#define gnttab_check_GNTST_eagain_while(__HCop, __HCarg_p)					\
+do {																		\
+	u8 __hc_delay = 1;														\
+	int __ret;																\
+	while (unlikely((__HCarg_p)->status == GNTST_eagain && __hc_delay)) {	\
+		msleep(__hc_delay++);												\
+		__ret = HYPERVISOR_grant_table_op(__HCop, (__HCarg_p), 1);			\
+		BUG_ON(__ret);														\
+	}																		\
+	if (__hc_delay == 0) {													\
+		printk(KERN_ERR "%s: gnt busy\n", __func__,);						\
+		(__HCarg_p)->status = GNTST_bad_page;								\
+	}																		\
+	if ((__HCarg_p)->status != GNTST_okay)									\
+		printk(KERN_ERR "%s: gnt status %x\n", 								\
+			__func__, (__HCarg_p)->status);									\
+} while(0)
+
+#define gnttab_check_GNTST_eagain_do_while(__HCop, __HCarg_p)			\
+do {																	\
+	u8 __hc_delay = 1;													\
+	int __ret;															\
+	do {																\
+		__ret = HYPERVISOR_grant_table_op(__HCop, (__HCarg_p), 1);		\
+		BUG_ON(__ret);													\
+		if ((__HCarg_p)->status == GNTST_eagain)						\
+			msleep(__hc_delay++);										\
+	} while ((__HCarg_p)->status == GNTST_eagain && __hc_delay);		\
+	if (__hc_delay == 0) {												\
+		printk(KERN_ERR "%s: gnt busy\n", __func__);					\
+		(__HCarg_p)->status = GNTST_bad_page;							\
+	}																	\
+	if ((__HCarg_p)->status != GNTST_okay)								\
+		printk(KERN_ERR "%s: gnt status %x\n", 							\
+			__func__, (__HCarg_p)->status);								\
+} while(0)
+
 #endif /* __ASM_GNTTAB_H__ */
diff --git a/include/xen/interface/grant_table.h b/include/xen/interface/grant_table.h
index 39e5717..ba04080 100644
--- a/include/xen/interface/grant_table.h
+++ b/include/xen/interface/grant_table.h
@@ -363,6 +363,8 @@ DEFINE_GUEST_HANDLE_STRUCT(gnttab_query_size);
 #define GNTST_permission_denied (-8) /* Not enough privilege for operation.  */
 #define GNTST_bad_page         (-9) /* Specified page was invalid for op.    */
 #define GNTST_bad_copy_arg    (-10) /* copy arguments cross page boundary */
+#define GNTST_address_too_big (-11) /* transfer page address too large.      */
+#define GNTST_eagain          (-12) /* Could not map at the moment. Retry.   */
 
 #define GNTTABOP_error_msgs {                   \
     "okay",                                     \
@@ -375,7 +377,9 @@ DEFINE_GUEST_HANDLE_STRUCT(gnttab_query_size);
     "no spare translation slot in the I/O MMU", \
     "permission denied",                        \
     "bad page",                                 \
-    "copy arguments cross page boundary"        \
+    "copy arguments cross page boundary",       \
+    "page address size too large",              \
+    "could not map at the moment, retry"        \
 }
 
 #endif /* __XEN_PUBLIC_GRANT_TABLE_H__ */
-- 
1.6.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 21 12:10:42 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 12:10:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdL0C-0000Yc-9v; Wed, 21 Dec 2011 12:10:32 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <amscanne@dev.gridcentric.ca>) id 1RctHZ-0006RU-Bk
	for xen-devel@lists.xensource.com; Tue, 20 Dec 2011 06:34:37 +0000
X-Env-Sender: amscanne@dev.gridcentric.ca
X-Msg-Ref: server-9.tower-182.messagelabs.com!1324362870!7921551!1
X-Originating-IP: [206.223.182.18]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27227 invoked from network); 20 Dec 2011 06:34:31 -0000
Received: from 206-223-182-18.beanfield.net (HELO dev.gridcentric.ca)
	(206.223.182.18) by server-9.tower-182.messagelabs.com with SMTP;
	20 Dec 2011 06:34:31 -0000
Received: by dev.gridcentric.ca (Postfix, from userid 500)
	id 037F760283; Tue, 20 Dec 2011 01:36:53 -0500 (EST)
From: Adin Scannell <adin@scannell.ca>
To: xen-devel@lists.xensource.com
Date: Tue, 20 Dec 2011 01:36:53 -0500
Message-Id: <1324363013-11031-4-git-send-email-adin@scannell.ca>
X-Mailer: git-send-email 1.6.2.5
In-Reply-To: <1324363013-11031-1-git-send-email-adin@scannell.ca>
References: <1324363013-11031-1-git-send-email-adin@scannell.ca>
X-Mailman-Approved-At: Wed, 21 Dec 2011 12:10:26 +0000
Cc: olaf@aepfle.de, Adin Scannell <adin@scannell.ca>, andres@gridcentric.ca,
	linux-kernel@vger.kernel.org, JBeulich@suse.com,
	konrad@darnok.org, adin@gridcentric.com
Subject: [Xen-devel] [PATCH 3/3] Port of mmap_batch_v2 to support paging in
	Xen
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This wasn't ported from any patch, but was rewritten based on the XCP 2.6.32
tree.  The code structure is significantly different and this patch mirrors the
existing Linux code.

An important reason to add the V2 interface is to support foreign mappings
(i.e.  qemu-dm) of paged-out pages.  The kernel generally has to do nothing
beyond implementing this ioctl in order to provide this support.  The V2
interface is needed only to pass back full error codes from the mmu_update()'s.
Xen and libxc have a mutual understanding that when you receive an ENOENT error
code, you back off and try again. The libxc code will already retry mappings
when an ENOENT is returned.

The only exception to the above case is backend drivers using grant operations.
To support paging, these drivers must appropriately retry grant operations when
they receive an EAGAIN error code.  This is implemented in a separate patch.

Signed-off-by: Adin Scannell <adin@scannell.ca>
---
 drivers/xen/privcmd.c |   90 +++++++++++++++++++++++++++++++++++++++++++++++++
 include/xen/privcmd.h |   10 +++++
 2 files changed, 100 insertions(+), 0 deletions(-)

diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
index 161681f..dd77d5c 100644
--- a/drivers/xen/privcmd.c
+++ b/drivers/xen/privcmd.c
@@ -251,6 +251,15 @@ struct mmap_batch_state {
 	xen_pfn_t __user *user;
 };
 
+struct mmap_batch_v2_state {
+	domid_t domain;
+	unsigned long va;
+	struct vm_area_struct *vma;
+	unsigned long paged_out;
+
+	int __user *err;
+};
+
 static int mmap_batch_fn(void *data, void *state)
 {
 	xen_pfn_t *mfnp = data;
@@ -268,6 +277,22 @@ static int mmap_batch_fn(void *data, void *state)
 	return 0;
 }
 
+static int mmap_batch_v2_fn(void *data, void *state)
+{
+	xen_pfn_t *mfnp = data;
+	struct mmap_batch_v2_state *st = state;
+
+	BUG_ON(st == NULL || st->vma == NULL);
+
+	int rc = xen_remap_domain_mfn_range(st->vma, st->va & PAGE_MASK, *mfnp,
+				       1, st->vma->vm_page_prot, st->domain);
+	if (rc == -ENOENT)
+		st->paged_out++;
+	st->va += PAGE_SIZE;
+
+	return put_user(rc, st->err++);
+}
+
 static int mmap_return_errors(void *data, void *state)
 {
 	xen_pfn_t *mfnp = data;
@@ -340,6 +365,67 @@ out:
 	return ret;
 }
 
+static long privcmd_ioctl_mmap_batch_v2(void __user *udata)
+{
+	int ret;
+	struct privcmd_mmapbatch_v2 m;
+	struct mm_struct *mm = current->mm;
+	struct vm_area_struct *vma = NULL;
+	unsigned long nr_pages;
+	LIST_HEAD(pagelist);
+	struct mmap_batch_v2_state state;
+
+	if (!xen_initial_domain())
+		return -EPERM;
+
+	if (copy_from_user(&m, udata, sizeof(m)))
+		return -EFAULT;
+
+	nr_pages = m.num;
+	if ((m.num <= 0) || (nr_pages > (ULONG_MAX >> PAGE_SHIFT)))
+		return -EINVAL;
+
+	ret = gather_array(&pagelist, m.num, sizeof(xen_pfn_t),
+			   m.arr);
+
+	if (ret || list_empty(&pagelist))
+		goto out;
+
+	down_write(&mm->mmap_sem);
+
+	vma = find_vma(mm, m.addr);
+	ret = -EINVAL;
+	/* We allow multiple shots here, because this interface
+	 * is used by libxc and mappings for specific pages will
+	 * be retried when pages are paged-out (ENOENT). */
+	if (!vma ||
+	    vma->vm_ops != &privcmd_vm_ops ||
+	    (m.addr < vma->vm_start) ||
+	    ((m.addr + (nr_pages << PAGE_SHIFT)) > vma->vm_end)) {
+		up_write(&mm->mmap_sem);
+		goto out;
+	}
+
+	state.domain = m.dom;
+	state.vma = vma;
+	state.va = m.addr;
+	state.err = m.err;
+	state.paged_out = 0;
+
+	up_write(&mm->mmap_sem);
+
+	ret = traverse_pages(m.num, sizeof(xen_pfn_t),
+			     &pagelist, mmap_batch_v2_fn, &state);
+
+out:
+	free_page_list(&pagelist);
+
+	if ((ret == 0) && (state.paged_out > 0))
+		return -ENOENT;
+	else
+		return ret;
+}
+
 static long privcmd_ioctl(struct file *file,
 			  unsigned int cmd, unsigned long data)
 {
@@ -359,6 +445,10 @@ static long privcmd_ioctl(struct file *file,
 		ret = privcmd_ioctl_mmap_batch(udata);
 		break;
 
+	case IOCTL_PRIVCMD_MMAPBATCH_V2:
+		ret = privcmd_ioctl_mmap_batch_v2(udata);
+		break;
+
 	default:
 		ret = -EINVAL;
 		break;
diff --git a/include/xen/privcmd.h b/include/xen/privcmd.h
index 17857fb..39b92b1 100644
--- a/include/xen/privcmd.h
+++ b/include/xen/privcmd.h
@@ -62,6 +62,14 @@ struct privcmd_mmapbatch {
 	xen_pfn_t __user *arr; /* array of mfns - top nibble set on err */
 };
 
+struct privcmd_mmapbatch_v2 {
+	int num;          /* number of pages to populate */
+	domid_t dom;      /* target domain */
+	__u64 addr;       /* virtual address */
+	const xen_pfn_t __user *arr; /* array of mfns */
+	int __user *err;  /* array of error codes */
+};
+
 /*
  * @cmd: IOCTL_PRIVCMD_HYPERCALL
  * @arg: &privcmd_hypercall_t
@@ -73,5 +81,7 @@ struct privcmd_mmapbatch {
 	_IOC(_IOC_NONE, 'P', 2, sizeof(struct privcmd_mmap))
 #define IOCTL_PRIVCMD_MMAPBATCH					\
 	_IOC(_IOC_NONE, 'P', 3, sizeof(struct privcmd_mmapbatch))
+#define IOCTL_PRIVCMD_MMAPBATCH_V2				\
+	_IOC(_IOC_NONE, 'P', 4, sizeof(struct privcmd_mmapbatch_v2))
 
 #endif /* __LINUX_PUBLIC_PRIVCMD_H__ */
-- 
1.6.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 21 12:10:42 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 12:10:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdL07-0000WZ-RD; Wed, 21 Dec 2011 12:10:27 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <catalin.marinas@arm.com>) id 1Rbb3U-00060W-Nr
	for xen-devel@lists.xensource.com; Fri, 16 Dec 2011 16:54:44 +0000
X-Env-Sender: catalin.marinas@arm.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1324054477!5663945!1
X-Originating-IP: [217.140.96.50]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4549 invoked from network); 16 Dec 2011 16:54:37 -0000
Received: from cam-admin0.cambridge.arm.com (HELO
	cam-admin0.cambridge.arm.com) (217.140.96.50)
	by server-14.tower-174.messagelabs.com with SMTP;
	16 Dec 2011 16:54:37 -0000
Received: from arm.com (e102109-lin.cambridge.arm.com [10.1.69.68])
	by cam-admin0.cambridge.arm.com (8.12.6/8.12.6) with ESMTP id
	pBGGsOWJ014769; Fri, 16 Dec 2011 16:54:25 GMT
Date: Fri, 16 Dec 2011 16:54:20 +0000
From: Catalin Marinas <catalin.marinas@arm.com>
To: David Vrabel <david.vrabel@citrix.com>
Message-ID: <20111216165420.GE6342@arm.com>
References: <alpine.DEB.2.00.1111281009090.31179@kaball-desktop>
	<201111292129.20444.arnd@arndb.de>
	<alpine.DEB.2.00.1111301053300.31179@kaball-desktop>
	<CAHkRjk48jHO19H04rf8252+v04hk9qSdKBrfYCqJsZyamVhMEw@mail.gmail.com>
	<4EEB673D.3040608@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4EEB673D.3040608@citrix.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
X-Mailman-Approved-At: Wed, 21 Dec 2011 12:10:26 +0000
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>, Arnd Bergmann <arnd@arndb.de>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [ANNOUNCE] Xen port to Cortex-A15 / ARMv7 with virt
 extensions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Dec 16, 2011 at 03:43:57PM +0000, David Vrabel wrote:
> On 30/11/11 14:11, Catalin Marinas wrote:
> > On 30 November 2011 11:39, Stefano Stabellini
> > <stefano.stabellini@eu.citrix.com> wrote:
> >> A git branch is available here (not ready for submission):
> >>
> >> git://xenbits.xen.org/people/sstabellini/linux-pvhvm.git arm
> >>
> >> the branch above is based on git://linux-arm.org/linux-2.6.git arm-lpae,
> >> even though guests don't really need lpae support to run on Xen.
> > 
> > Indeed, you don't really need LPAE. What you may need though is
> > generic timers support for A15, it would allow less Hypervisor traps.
> > For up-to-date architecture patches (well, development tree, not
> > guaranteed to be stable), I would recommend this (they get into
> > mainline at some point):
> > 
> > http://git.kernel.org/?p=linux/kernel/git/cmarinas/linux-arm-arch.git;a=summary
> > 
> > Either use master or just cherry-pick the branches that you are interested in.
> 
> Which branches are required for the Versatile Express with the
> Cortex-A15? I merged linux-arm-arch/arm-arch/vexpress in

That's the branch if you only need VE and A15 support

> but I get a
> instruction fault immediately after branching to __mmap_switched.
> 
> Is it not setting up the MMU correctly?

Do you run this on a software model? What config options do you use? You
would need to enable VEXPRESS_EXTENDED_MEMORY_MAP and
ARCH_VEXPRESS_CA15X4.

-- 
Catalin

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 21 12:10:42 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 12:10:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdL0B-0000Xn-41; Wed, 21 Dec 2011 12:10:31 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andrew.thomas@oracle.com>) id 1RcmMV-0007V1-LW
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 23:11:15 +0000
X-Env-Sender: andrew.thomas@oracle.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1324336268!7908190!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ0Njk1NQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7934 invoked from network); 19 Dec 2011 23:11:09 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-6.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Dec 2011 23:11:09 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pBJNB53A003590
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK)
	for <xen-devel@lists.xensource.com>; Mon, 19 Dec 2011 23:11:06 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pBJNB5se011911
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <xen-devel@lists.xensource.com>; Mon, 19 Dec 2011 23:11:05 GMT
Received: from abhmt107.oracle.com (abhmt107.oracle.com [141.146.116.59])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pBJNB4aw020172
	for <xen-devel@lists.xensource.com>; Mon, 19 Dec 2011 17:11:04 -0600
Received: from serenity.us.oracle.com (/130.35.69.209)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 19 Dec 2011 15:11:04 -0800
Message-ID: <4EEFC462.2020307@oracle.com>
Date: Mon, 19 Dec 2011 15:10:26 -0800
From: andrew thomas <andrew.thomas@oracle.com>
User-Agent: Thunderbird 2.0.0.17 (X11/20081009)
MIME-Version: 1.0
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090207.4EEFC48B.003D,ss=1,re=0.000,fgs=0
X-Mailman-Approved-At: Wed, 21 Dec 2011 12:10:26 +0000
Cc: andrew.thomas@oracle.com
Subject: [Xen-devel] issue with PLE and/or scheduler
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is with xen-4.1-testing cs 23201:1c89f7d29fbb
and using the default "credit" scheduler.

I've run into an interesting issue with HVM guests which
make use of Pause Loop Exiting (ie. on westmere systems;
and also on romley systems):  after yielding the cpu, guests
don't seem to receive timer interrupts correctly..

Some background: for historical reasons (ie old templates) we boot 
OL/RHEL guests
with the following settings:

kernel parameters: clock=pit nohpet nopmtimer
vm.cfg: timer_mode = 2

With PLE enabled, 2.6.32 guests will crash early on with:
  ..MP-BIOS bug: 8254 timer not connected to IO-APIC
  # a few lines omitted..
  Kernel panic - not syncing: IO-APIC + timer doesn't work!  Boot with 
apic=debug

While 2.6.18-238 (ie OL/RHEL5u6) will fail to find the timer, but 
continue and
lock up in the serial line initialization.

  ..MP-BIOS bug: 8254 timer not connected to IO-APIC
  # continues until lock up here:
  Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled

Instrumenting the 2.6.32 code (ie timer_irq_works()) shows that jiffies 
isn't advancing (or only 1 or 2 ticks are
being received, which is insufficient for "working"). This is on a 
"quiet" system with no other activity.
So, even though the guest has voluntarily yielded the cpu (through PLE), 
I would still expect it to
receive every clock tick (even with timer_mode=2) as there is no other 
work to do on the
system.

Disabling PLE allows both 2.6.18 and 2.6.32 guests to boot.. [As an 
aside, so does setting ple_gap to
41 (ie prior to 21355:727ccaaa6cce) -- the perf counters show no exits 
happening,
so this is equivalent to disabling PLE.]

I'm hoping someone who knows the scheduler well will be able to quickly
decide whether this is a bug or a feature...

Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 21 12:10:42 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 12:10:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdL0D-0000ZD-57; Wed, 21 Dec 2011 12:10:33 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <maydin.work@gmail.com>) id 1Rd8hd-0001Sk-Er
	for xen-devel@lists.xensource.com; Tue, 20 Dec 2011 23:02:33 +0000
X-Env-Sender: maydin.work@gmail.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1324422146!6332819!1
X-Originating-IP: [74.125.83.43]
X-SpamReason: No, hits=1.5 required=7.0 tests=HTML_00_10,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19606 invoked from network); 20 Dec 2011 23:02:26 -0000
Received: from mail-ee0-f43.google.com (HELO mail-ee0-f43.google.com)
	(74.125.83.43)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Dec 2011 23:02:26 -0000
Received: by eekd4 with SMTP id d4so33546408eek.30
	for <xen-devel@lists.xensource.com>;
	Tue, 20 Dec 2011 15:02:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=/EcpklEZY8gk8SkqqmXIBKbg8QVcTUr5XbuI3EP5ps8=;
	b=BVhg3r9DfOjYrVEG2X4A6y9y3WWYXfJw9x++l3J/kgu5xcgA+c0R2hLFvRimTeIFij
	TnJWZ4KISzLXIYysB7z+KS22zzFyF86Og1HG3gx0Yui6kAd+MmNVSZrJXFkSnhAdBQW/
	s7dZ7iOkGlb4F07BTR2Y8uPdAw/788t6hWyYA=
MIME-Version: 1.0
Received: by 10.14.16.77 with SMTP id g53mr1697456eeg.19.1324422146160; Tue,
	20 Dec 2011 15:02:26 -0800 (PST)
Received: by 10.213.34.77 with HTTP; Tue, 20 Dec 2011 15:02:26 -0800 (PST)
Date: Tue, 20 Dec 2011 23:02:26 +0000
Message-ID: <CALF+9DFCeYu2E1xBuHOW4n_7J9kz0H4Ngv1BY_Rn8d-SwDb3VA@mail.gmail.com>
From: Mustafa Aydin <maydin.work@gmail.com>
To: xen-devel@lists.xensource.com
X-Mailman-Approved-At: Wed, 21 Dec 2011 12:10:26 +0000
Subject: [Xen-devel] Xen interfaces / hooks
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6238205227377435196=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============6238205227377435196==
Content-Type: multipart/alternative; boundary=0016e65060908df7dd04b48e0f7c

--0016e65060908df7dd04b48e0f7c
Content-Type: text/plain; charset=ISO-8859-1

Hello all,

I have been looking through the internet and through the wiki, trying to
find something which explains in details the available interfaces with
which one might be able to insert some code to make some slight additions
to Xen functionality. I am doing some research on the possibility of adding
some extra functionality to Xen, and my supervisor has mentioned that these
are things worth looking into (he called them modules / kernel modules).

Is there a source of info which lists these tools please? Although I have
spent today going through many pages and searching I could not find
anything, although perhaps I was using some incorrect terms.

All the best,

Muhammed

--0016e65060908df7dd04b48e0f7c
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hello all,<br><br>I have been looking through the internet and through the =
wiki, trying to find something which explains in details the available inte=
rfaces with which one might be able to insert some code to make some slight=
 additions to Xen functionality. I am doing some research on the possibilit=
y of adding some extra functionality to Xen, and my supervisor has mentione=
d that these are things worth looking into (he called them modules / kernel=
 modules). <br>
<br>Is there a source of info which lists these tools please? Although I ha=
ve spent today going through many pages and searching I could not find anyt=
hing, although perhaps I was using some incorrect terms. <br><br>All the be=
st,<br>
<br>Muhammed<br>

--0016e65060908df7dd04b48e0f7c--


--===============6238205227377435196==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============6238205227377435196==--


From xen-devel-bounces@lists.xensource.com Wed Dec 21 12:10:42 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 12:10:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdL0C-0000Yq-MP; Wed, 21 Dec 2011 12:10:32 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <amscanne@dev.gridcentric.ca>) id 1RctHb-0006RX-Lq
	for xen-devel@lists.xensource.com; Tue, 20 Dec 2011 06:34:39 +0000
X-Env-Sender: amscanne@dev.gridcentric.ca
X-Msg-Ref: server-16.tower-21.messagelabs.com!1324362872!2163125!1
X-Originating-IP: [206.223.182.18]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12196 invoked from network); 20 Dec 2011 06:34:32 -0000
Received: from 206-223-182-18.beanfield.net (HELO dev.gridcentric.ca)
	(206.223.182.18) by server-16.tower-21.messagelabs.com with SMTP;
	20 Dec 2011 06:34:32 -0000
Received: by dev.gridcentric.ca (Postfix, from userid 500)
	id 2D3406028E; Tue, 20 Dec 2011 01:36:53 -0500 (EST)
From: Adin Scannell <adin@scannell.ca>
To: xen-devel@lists.xensource.com
Date: Tue, 20 Dec 2011 01:36:52 -0500
Message-Id: <1324363013-11031-3-git-send-email-adin@scannell.ca>
X-Mailer: git-send-email 1.6.2.5
In-Reply-To: <1324363013-11031-1-git-send-email-adin@scannell.ca>
References: <1324363013-11031-1-git-send-email-adin@scannell.ca>
X-Mailman-Approved-At: Wed, 21 Dec 2011 12:10:26 +0000
Cc: olaf@aepfle.de, Adin Scannell <adin@scannell.ca>, andres@gridcentric.ca,
	linux-kernel@vger.kernel.org, JBeulich@suse.com,
	konrad@darnok.org, adin@gridcentric.com
Subject: [Xen-devel] [PATCH 2/3] Small fix-ups for the xen/privcmd ioctls
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

In implementing the mmap_batch_v2 ioctl, some of the feedback included small
fixups that were also relevant to the existing mmap_batch ioctl. Prior to the
mmap_batch_v2 patch, this adds those small fixups to the existing code.

The const addition for gather_array is necessary for the implementation of
mmap_batch_v2 and does not affect correctness.

Signed-off-by: Adin Scannell <adin@scannell.ca>
---
 drivers/xen/privcmd.c |    6 ++++--
 1 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
index ccee0f1..161681f 100644
--- a/drivers/xen/privcmd.c
+++ b/drivers/xen/privcmd.c
@@ -76,7 +76,7 @@ static void free_page_list(struct list_head *pages)
  */
 static int gather_array(struct list_head *pagelist,
 			unsigned nelem, size_t size,
-			void __user *data)
+			const void __user *data)
 {
 	unsigned pageidx;
 	void *pagedata;
@@ -246,7 +246,7 @@ struct mmap_batch_state {
 	domid_t domain;
 	unsigned long va;
 	struct vm_area_struct *vma;
-	int err;
+	unsigned long err;
 
 	xen_pfn_t __user *user;
 };
@@ -256,6 +256,8 @@ static int mmap_batch_fn(void *data, void *state)
 	xen_pfn_t *mfnp = data;
 	struct mmap_batch_state *st = state;
 
+	BUG_ON(st == NULL || st->vma == NULL);
+
 	if (xen_remap_domain_mfn_range(st->vma, st->va & PAGE_MASK, *mfnp, 1,
 				       st->vma->vm_page_prot, st->domain) < 0) {
 		*mfnp |= 0xf0000000U;
-- 
1.6.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 21 12:10:42 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 12:10:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdL0D-0000ZN-II; Wed, 21 Dec 2011 12:10:33 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jan.vejvalka@lfmotol.cuni.cz>) id 1RdA0g-0002Uu-Ss
	for xen-devel@lists.xensource.com; Wed, 21 Dec 2011 00:26:19 +0000
X-Env-Sender: jan.vejvalka@lfmotol.cuni.cz
X-Msg-Ref: server-11.tower-27.messagelabs.com!1324427157!50100123!1
X-Originating-IP: [195.113.40.14]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18997 invoked from network); 21 Dec 2011 00:25:57 -0000
Received: from mailer.lf2.cuni.cz (HELO sakal.lf2.cuni.cz) (195.113.40.14)
	by server-11.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Dec 2011 00:25:57 -0000
Received: from kremail.lf2.cuni.cz (kremail [195.113.40.28])
	by sakal.lf2.cuni.cz (8.14.3/8.14.3) with ESMTP id pBL0PWtW030544;
	Wed, 21 Dec 2011 01:25:32 +0100
Received: from [195.113.43.131] ([195.113.43.131]) (authenticated bits=0)
	by kremail.lf2.cuni.cz (8.13.7/8.13.7) with ESMTP id pBL0PSDl013664
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 21 Dec 2011 01:25:31 +0100
Message-ID: <4EF12777.10100@lfmotol.cuni.cz>
Date: Wed, 21 Dec 2011 01:25:27 +0100
From: Jan Vejvalka <jan.vejvalka@lfmotol.cuni.cz>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
References: <4EE8E725.30208@lfmotol.cuni.cz>
	<20111216153211.GA5120@andromeda.dapyr.net>
	<4EF020A3.8050801@lfmotol.cuni.cz>
	<20111220142521.GB25139@konrad-lan>
	<20111220142633.GC25139@konrad-lan>
In-Reply-To: <20111220142633.GC25139@konrad-lan>
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3
	(sakal.lf2.cuni.cz [195.113.40.14]);
	Wed, 21 Dec 2011 01:25:32 +0100 (CET)
X-Spam-Status: No, hits=-0.6, tests=AWL=0.141,BAYES_20=-0.74,
	rbl=<dns:lfmotol.cuni.cz?type=MX> [20 mailer.lf2.cuni.cz.],
X-Mailman-Approved-At: Wed, 21 Dec 2011 12:10:26 +0000
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Failure to start X windows in Dom0 under Xen 4.1.2
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 20.12.2011 15:26, Konrad Rzeszutek Wilk wrote:
> On Tue, Dec 20, 2011 at 09:25:21AM -0500, Konrad Rzeszutek Wilk wrote:
>> On Tue, Dec 20, 2011 at 06:44:03AM +0100, Jan Vejvalka wrote:

>> In the meantime, I found a post that helped at least partially:
>> http://forums.gentoo.org/viewtopic-t-901234-start-0.html .
>>
>> I added the nopat option to grub, and things got a bit better.
>> I moved one step further, now facing a somewhat different problem:
>>
>> - on my 3.1.1 kernel without Xen, things work fine
>
> Can you provide the dmesg of that please.
>
> I am curious to see why you have:
>
> [    2.967316] [drm] VGACON disable radeon kernel modesetting.
>
> Can you also boot the baremetal (so without Xen) and with Xen
> with: "drm.debug=255" and remove the "nomodeset" option on the Linux
> command line?
> Uou are also missing the "debug loglevel=8" options. I need those to
> get a better idea of why the radeon driver is not initializing properly.

See http://camelot.lf2.cuni.cz/vejvalka/temp/kon2 . Missing firmware.
Just distorted graphics came up on the console after boot in both cases.

Found the R600_rlc.bin at
http://people.freedesktop.org/~agd5f/radeon_ucode (as linked from
http://www.x.org/wiki/radeonBuildHowTo ) ... and things started
working, also the X windows start under Xen at the first attempt,
even without the nopat kernel option.

See logs at http://camelot.lf2.cuni.cz/vejvalka/temp/kon3 .

Thanks !

Jan

>> - on the same kernel with Xen, the first (and sometimes even some
>>      further) attempts to run startx fail
>> - after a couple of tries, startx finally succeeds if the kernel
>>      is loaded with the nopat parameter
>> - without the nopat parameter, it seems it does not work: in the best
>>      attempts, the screen enters the graphic mode for a short while
>>      before the final crash.
>>
>> The info you asked for is at
>> http://camelot.lf2.cuni.cz/vejvalka/temp/kon .

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 21 12:10:42 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 12:10:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdL08-0000Wq-Lu; Wed, 21 Dec 2011 12:10:28 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <amscanne@dev.gridcentric.ca>) id 1Rbkor-0003Rz-5A
	for xen-devel@lists.xensource.com; Sat, 17 Dec 2011 03:20:17 +0000
X-Env-Sender: amscanne@dev.gridcentric.ca
X-Msg-Ref: server-3.tower-27.messagelabs.com!1324091970!49382572!1
X-Originating-IP: [206.223.182.18]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16902 invoked from network); 17 Dec 2011 03:19:31 -0000
Received: from 206-223-182-18.beanfield.net (HELO dev.gridcentric.ca)
	(206.223.182.18) by server-3.tower-27.messagelabs.com with SMTP;
	17 Dec 2011 03:19:31 -0000
Received: by dev.gridcentric.ca (Postfix, from userid 500)
	id 21E556028A; Fri, 16 Dec 2011 22:22:21 -0500 (EST)
From: Adin Scannell <adin@scannell.ca>
To: xen-devel@lists.xensource.com
Date: Fri, 16 Dec 2011 22:22:19 -0500
Message-Id: <1324092141-9730-2-git-send-email-adin@scannell.ca>
X-Mailer: git-send-email 1.6.2.5
In-Reply-To: <1324092141-9730-1-git-send-email-adin@scannell.ca>
References: <1324092141-9730-1-git-send-email-adin@scannell.ca>
X-Mailman-Approved-At: Wed, 21 Dec 2011 12:10:26 +0000
Cc: olaf@aepfle.de, Adin Scannell <adin@scannell.ca>, andres@gridcentric.ca,
	JBeulich@suse.com, konrad@darnok.org, adin@gridcentric.com
Subject: [Xen-devel] [PATCH 1/3] Make xen_remap_domain_mfn_range return
	value meaningful in case of error
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Original patch from Olaf Hering <ohering@novell.com>

This change fixes the xc_map_foreign_bulk interface, which would
otherwise cause SIGBUS when pages are gone because -ENOENT is not
returned as expected by the IOCTL_PRIVCMD_MMAPBATCH_V2 ioctl.

Signed-off-by: Jan Beulich <jbeulich@novell.com>

This is a port to the mainline Linux tree.  Functions were refactored and
renamed.  I believe that this is the only required change to match the
semantics of the original patch.

Signed-off-by: Adin Scannell <adin@scannell.ca>
---
 arch/x86/xen/mmu.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index 87f6673..288a7fc 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -2350,8 +2350,8 @@ int xen_remap_domain_mfn_range(struct vm_area_struct *vma,
 		if (err)
 			goto out;
 
-		err = -EFAULT;
-		if (HYPERVISOR_mmu_update(mmu_update, batch, NULL, domid) < 0)
+		err = HYPERVISOR_mmu_update(mmu_update, batch, NULL, domid);
+		if (err < 0)
 			goto out;
 
 		nr -= batch;
-- 
1.6.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 21 12:10:42 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 12:10:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdL0A-0000Xc-MM; Wed, 21 Dec 2011 12:10:30 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RcbOV-00039Q-P1
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 11:28:35 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1324294062!57856680!1
X-Originating-IP: [209.85.210.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8419 invoked from network); 19 Dec 2011 11:27:43 -0000
Received: from mail-pz0-f43.google.com (HELO mail-pz0-f43.google.com)
	(209.85.210.43)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Dec 2011 11:27:43 -0000
Received: by daec6 with SMTP id c6so25102531dae.30
	for <xen-devel@lists.xensource.com>;
	Mon, 19 Dec 2011 03:28:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	bh=/+rQcSN7K83yOQKeAd95qEV3sDkpOdgkbCNKcEvN1hQ=;
	b=HojTKGmDO/woBM1y8DsT4P7U1r1UTZI0uSw1PSkqzKtqWhfNBdDs0th3r6grvi0XTr
	EKMMW2iBHHIJ4pbgI/hL0pkpVWcQCO4vnKORGK5FxsfBvddfOkchhcwwTWZH4pVFOsT6
	3iHtzXCkx8Y3v0r6XZrtpWJuIjtDc0sDFmf2I=
MIME-Version: 1.0
Received: by 10.68.74.70 with SMTP id r6mr37745600pbv.78.1324294112482; Mon,
	19 Dec 2011 03:28:32 -0800 (PST)
Received: by 10.142.47.17 with HTTP; Mon, 19 Dec 2011 03:28:32 -0800 (PST)
In-Reply-To: <1324294068.9236.28.camel@zakaz.uk.xensource.com>
References: <patchbomb.1324212500@alpine.localdomain>
	<eed78eb655c40b0ac9af.1324212501@alpine.localdomain>
	<1324288096.9236.6.camel@zakaz.uk.xensource.com>
	<CAPLaKK7gEUv9bavavzyYjREPDZJepMkK+-Ap78xzHjPy4SvZ3g@mail.gmail.com>
	<1324289291.9236.16.camel@zakaz.uk.xensource.com>
	<CAPLaKK6=O_h+OxOc_qDLUkw22hV2t6t9wfXOKVuoJf+Ny5+P9g@mail.gmail.com>
	<1324294068.9236.28.camel@zakaz.uk.xensource.com>
Date: Mon, 19 Dec 2011 12:28:32 +0100
Message-ID: <CAPLaKK771o2-_c=3huGH8ei3jAvL26en=Lu+QCuvdMFbZTi24Q@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <royger@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
X-Mailman-Approved-At: Wed, 21 Dec 2011 12:10:26 +0000
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 1 of 5] blktap: remove HAVE_BYTESWAP_H
 checking, since it's defined by qemu
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

MjAxMS8xMi8xOSBJYW4gQ2FtcGJlbGwgPElhbi5DYW1wYmVsbEBjaXRyaXguY29tPjoKPiBPbiBN
b24sIDIwMTEtMTItMTkgYXQgMTE6MjYgKzAwMDAsIFJvZ2VyIFBhdSBNb25uw6kgd3JvdGU6Cj4+
IDIwMTEvMTIvMTkgSWFuIENhbXBiZWxsIDxJYW4uQ2FtcGJlbGxAY2l0cml4LmNvbT46Cj4+ID4g
SSB0aGluayB0aGlzIGlzIHRoZSBjb3JyZWN0IG9wdGlvbi4gTm8gbmVlZCB0byB1bmRlZiBzdHVm
Zi4gVGhlcmUgaXMKPj4gPiBvbmx5IG9uZSBvdGhlciBpbmNsdWRlIG9mIGJ5dGVzd2FwLmggaW4g
YmxrdGFwLgo+PiA+Cj4+Cj4+IE9uIHVjbGliYywgYnl0ZXN3YXAuaCBnZXRzIGluY2x1ZGVkIGJ5
IGRlZmF1bHQsIGJlY2F1c2UgX0dOVV9TT1VSQ0UKPj4gaW1wbGllcyBfQlNEX1NPVVJDRSB0aGVy
ZS4gT25lIHNvbHV0aW9uIGlzIHRvIGFkZCBfUE9TSVhfU09VUkNFLCB3aGljaAo+PiBwcmV2ZW50
cyB0aGUgYWRkaXRpb24gb2YgX0JTRF9TT1VSQ0UuCj4KPiBXaGF0IHBhdGggb2YgaW5jbHVkZXMg
bGVhZHMgdG8gdGhlIGluY2x1c2lvbiBvZiBieXRlc3dhcC5oPwoKVGhpcyBvbmU6CgpzdGRsaWIu
aCAtPiBzeXMvdHlwZXMuaCAtPiBlbmRpYW4uaCAtPiAoYmVjYXN1ZSBfX1VTRV9CU0QgaXMgZGVm
aW5lZCkgYnl0ZXN3YXAuaAoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuc291cmNl
LmNvbQpodHRwOi8vbGlzdHMueGVuc291cmNlLmNvbS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Wed Dec 21 12:10:42 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 12:10:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdL0B-0000Xn-41; Wed, 21 Dec 2011 12:10:31 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andrew.thomas@oracle.com>) id 1RcmMV-0007V1-LW
	for xen-devel@lists.xensource.com; Mon, 19 Dec 2011 23:11:15 +0000
X-Env-Sender: andrew.thomas@oracle.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1324336268!7908190!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ0Njk1NQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7934 invoked from network); 19 Dec 2011 23:11:09 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-6.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Dec 2011 23:11:09 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pBJNB53A003590
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK)
	for <xen-devel@lists.xensource.com>; Mon, 19 Dec 2011 23:11:06 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pBJNB5se011911
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <xen-devel@lists.xensource.com>; Mon, 19 Dec 2011 23:11:05 GMT
Received: from abhmt107.oracle.com (abhmt107.oracle.com [141.146.116.59])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pBJNB4aw020172
	for <xen-devel@lists.xensource.com>; Mon, 19 Dec 2011 17:11:04 -0600
Received: from serenity.us.oracle.com (/130.35.69.209)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 19 Dec 2011 15:11:04 -0800
Message-ID: <4EEFC462.2020307@oracle.com>
Date: Mon, 19 Dec 2011 15:10:26 -0800
From: andrew thomas <andrew.thomas@oracle.com>
User-Agent: Thunderbird 2.0.0.17 (X11/20081009)
MIME-Version: 1.0
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090207.4EEFC48B.003D,ss=1,re=0.000,fgs=0
X-Mailman-Approved-At: Wed, 21 Dec 2011 12:10:26 +0000
Cc: andrew.thomas@oracle.com
Subject: [Xen-devel] issue with PLE and/or scheduler
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is with xen-4.1-testing cs 23201:1c89f7d29fbb
and using the default "credit" scheduler.

I've run into an interesting issue with HVM guests which
make use of Pause Loop Exiting (ie. on westmere systems;
and also on romley systems):  after yielding the cpu, guests
don't seem to receive timer interrupts correctly..

Some background: for historical reasons (ie old templates) we boot 
OL/RHEL guests
with the following settings:

kernel parameters: clock=pit nohpet nopmtimer
vm.cfg: timer_mode = 2

With PLE enabled, 2.6.32 guests will crash early on with:
  ..MP-BIOS bug: 8254 timer not connected to IO-APIC
  # a few lines omitted..
  Kernel panic - not syncing: IO-APIC + timer doesn't work!  Boot with 
apic=debug

While 2.6.18-238 (ie OL/RHEL5u6) will fail to find the timer, but 
continue and
lock up in the serial line initialization.

  ..MP-BIOS bug: 8254 timer not connected to IO-APIC
  # continues until lock up here:
  Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled

Instrumenting the 2.6.32 code (ie timer_irq_works()) shows that jiffies 
isn't advancing (or only 1 or 2 ticks are
being received, which is insufficient for "working"). This is on a 
"quiet" system with no other activity.
So, even though the guest has voluntarily yielded the cpu (through PLE), 
I would still expect it to
receive every clock tick (even with timer_mode=2) as there is no other 
work to do on the
system.

Disabling PLE allows both 2.6.18 and 2.6.32 guests to boot.. [As an 
aside, so does setting ple_gap to
41 (ie prior to 21355:727ccaaa6cce) -- the perf counters show no exits 
happening,
so this is equivalent to disabling PLE.]

I'm hoping someone who knows the scheduler well will be able to quickly
decide whether this is a bug or a feature...

Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 21 12:10:42 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 12:10:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdL0D-0000ZN-II; Wed, 21 Dec 2011 12:10:33 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jan.vejvalka@lfmotol.cuni.cz>) id 1RdA0g-0002Uu-Ss
	for xen-devel@lists.xensource.com; Wed, 21 Dec 2011 00:26:19 +0000
X-Env-Sender: jan.vejvalka@lfmotol.cuni.cz
X-Msg-Ref: server-11.tower-27.messagelabs.com!1324427157!50100123!1
X-Originating-IP: [195.113.40.14]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18997 invoked from network); 21 Dec 2011 00:25:57 -0000
Received: from mailer.lf2.cuni.cz (HELO sakal.lf2.cuni.cz) (195.113.40.14)
	by server-11.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Dec 2011 00:25:57 -0000
Received: from kremail.lf2.cuni.cz (kremail [195.113.40.28])
	by sakal.lf2.cuni.cz (8.14.3/8.14.3) with ESMTP id pBL0PWtW030544;
	Wed, 21 Dec 2011 01:25:32 +0100
Received: from [195.113.43.131] ([195.113.43.131]) (authenticated bits=0)
	by kremail.lf2.cuni.cz (8.13.7/8.13.7) with ESMTP id pBL0PSDl013664
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 21 Dec 2011 01:25:31 +0100
Message-ID: <4EF12777.10100@lfmotol.cuni.cz>
Date: Wed, 21 Dec 2011 01:25:27 +0100
From: Jan Vejvalka <jan.vejvalka@lfmotol.cuni.cz>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
References: <4EE8E725.30208@lfmotol.cuni.cz>
	<20111216153211.GA5120@andromeda.dapyr.net>
	<4EF020A3.8050801@lfmotol.cuni.cz>
	<20111220142521.GB25139@konrad-lan>
	<20111220142633.GC25139@konrad-lan>
In-Reply-To: <20111220142633.GC25139@konrad-lan>
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3
	(sakal.lf2.cuni.cz [195.113.40.14]);
	Wed, 21 Dec 2011 01:25:32 +0100 (CET)
X-Spam-Status: No, hits=-0.6, tests=AWL=0.141,BAYES_20=-0.74,
	rbl=<dns:lfmotol.cuni.cz?type=MX> [20 mailer.lf2.cuni.cz.],
X-Mailman-Approved-At: Wed, 21 Dec 2011 12:10:26 +0000
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Failure to start X windows in Dom0 under Xen 4.1.2
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 20.12.2011 15:26, Konrad Rzeszutek Wilk wrote:
> On Tue, Dec 20, 2011 at 09:25:21AM -0500, Konrad Rzeszutek Wilk wrote:
>> On Tue, Dec 20, 2011 at 06:44:03AM +0100, Jan Vejvalka wrote:

>> In the meantime, I found a post that helped at least partially:
>> http://forums.gentoo.org/viewtopic-t-901234-start-0.html .
>>
>> I added the nopat option to grub, and things got a bit better.
>> I moved one step further, now facing a somewhat different problem:
>>
>> - on my 3.1.1 kernel without Xen, things work fine
>
> Can you provide the dmesg of that please.
>
> I am curious to see why you have:
>
> [    2.967316] [drm] VGACON disable radeon kernel modesetting.
>
> Can you also boot the baremetal (so without Xen) and with Xen
> with: "drm.debug=255" and remove the "nomodeset" option on the Linux
> command line?
> Uou are also missing the "debug loglevel=8" options. I need those to
> get a better idea of why the radeon driver is not initializing properly.

See http://camelot.lf2.cuni.cz/vejvalka/temp/kon2 . Missing firmware.
Just distorted graphics came up on the console after boot in both cases.

Found the R600_rlc.bin at
http://people.freedesktop.org/~agd5f/radeon_ucode (as linked from
http://www.x.org/wiki/radeonBuildHowTo ) ... and things started
working, also the X windows start under Xen at the first attempt,
even without the nopat kernel option.

See logs at http://camelot.lf2.cuni.cz/vejvalka/temp/kon3 .

Thanks !

Jan

>> - on the same kernel with Xen, the first (and sometimes even some
>>      further) attempts to run startx fail
>> - after a couple of tries, startx finally succeeds if the kernel
>>      is loaded with the nopat parameter
>> - without the nopat parameter, it seems it does not work: in the best
>>      attempts, the screen enters the graphic mode for a short while
>>      before the final crash.
>>
>> The info you asked for is at
>> http://camelot.lf2.cuni.cz/vejvalka/temp/kon .

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 21 12:10:42 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 12:10:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdL0C-0000Yq-MP; Wed, 21 Dec 2011 12:10:32 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <amscanne@dev.gridcentric.ca>) id 1RctHb-0006RX-Lq
	for xen-devel@lists.xensource.com; Tue, 20 Dec 2011 06:34:39 +0000
X-Env-Sender: amscanne@dev.gridcentric.ca
X-Msg-Ref: server-16.tower-21.messagelabs.com!1324362872!2163125!1
X-Originating-IP: [206.223.182.18]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12196 invoked from network); 20 Dec 2011 06:34:32 -0000
Received: from 206-223-182-18.beanfield.net (HELO dev.gridcentric.ca)
	(206.223.182.18) by server-16.tower-21.messagelabs.com with SMTP;
	20 Dec 2011 06:34:32 -0000
Received: by dev.gridcentric.ca (Postfix, from userid 500)
	id 2D3406028E; Tue, 20 Dec 2011 01:36:53 -0500 (EST)
From: Adin Scannell <adin@scannell.ca>
To: xen-devel@lists.xensource.com
Date: Tue, 20 Dec 2011 01:36:52 -0500
Message-Id: <1324363013-11031-3-git-send-email-adin@scannell.ca>
X-Mailer: git-send-email 1.6.2.5
In-Reply-To: <1324363013-11031-1-git-send-email-adin@scannell.ca>
References: <1324363013-11031-1-git-send-email-adin@scannell.ca>
X-Mailman-Approved-At: Wed, 21 Dec 2011 12:10:26 +0000
Cc: olaf@aepfle.de, Adin Scannell <adin@scannell.ca>, andres@gridcentric.ca,
	linux-kernel@vger.kernel.org, JBeulich@suse.com,
	konrad@darnok.org, adin@gridcentric.com
Subject: [Xen-devel] [PATCH 2/3] Small fix-ups for the xen/privcmd ioctls
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

In implementing the mmap_batch_v2 ioctl, some of the feedback included small
fixups that were also relevant to the existing mmap_batch ioctl. Prior to the
mmap_batch_v2 patch, this adds those small fixups to the existing code.

The const addition for gather_array is necessary for the implementation of
mmap_batch_v2 and does not affect correctness.

Signed-off-by: Adin Scannell <adin@scannell.ca>
---
 drivers/xen/privcmd.c |    6 ++++--
 1 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
index ccee0f1..161681f 100644
--- a/drivers/xen/privcmd.c
+++ b/drivers/xen/privcmd.c
@@ -76,7 +76,7 @@ static void free_page_list(struct list_head *pages)
  */
 static int gather_array(struct list_head *pagelist,
 			unsigned nelem, size_t size,
-			void __user *data)
+			const void __user *data)
 {
 	unsigned pageidx;
 	void *pagedata;
@@ -246,7 +246,7 @@ struct mmap_batch_state {
 	domid_t domain;
 	unsigned long va;
 	struct vm_area_struct *vma;
-	int err;
+	unsigned long err;
 
 	xen_pfn_t __user *user;
 };
@@ -256,6 +256,8 @@ static int mmap_batch_fn(void *data, void *state)
 	xen_pfn_t *mfnp = data;
 	struct mmap_batch_state *st = state;
 
+	BUG_ON(st == NULL || st->vma == NULL);
+
 	if (xen_remap_domain_mfn_range(st->vma, st->va & PAGE_MASK, *mfnp, 1,
 				       st->vma->vm_page_prot, st->domain) < 0) {
 		*mfnp |= 0xf0000000U;
-- 
1.6.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 21 12:10:42 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 12:10:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdL0C-0000Yc-9v; Wed, 21 Dec 2011 12:10:32 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <amscanne@dev.gridcentric.ca>) id 1RctHZ-0006RU-Bk
	for xen-devel@lists.xensource.com; Tue, 20 Dec 2011 06:34:37 +0000
X-Env-Sender: amscanne@dev.gridcentric.ca
X-Msg-Ref: server-9.tower-182.messagelabs.com!1324362870!7921551!1
X-Originating-IP: [206.223.182.18]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27227 invoked from network); 20 Dec 2011 06:34:31 -0000
Received: from 206-223-182-18.beanfield.net (HELO dev.gridcentric.ca)
	(206.223.182.18) by server-9.tower-182.messagelabs.com with SMTP;
	20 Dec 2011 06:34:31 -0000
Received: by dev.gridcentric.ca (Postfix, from userid 500)
	id 037F760283; Tue, 20 Dec 2011 01:36:53 -0500 (EST)
From: Adin Scannell <adin@scannell.ca>
To: xen-devel@lists.xensource.com
Date: Tue, 20 Dec 2011 01:36:53 -0500
Message-Id: <1324363013-11031-4-git-send-email-adin@scannell.ca>
X-Mailer: git-send-email 1.6.2.5
In-Reply-To: <1324363013-11031-1-git-send-email-adin@scannell.ca>
References: <1324363013-11031-1-git-send-email-adin@scannell.ca>
X-Mailman-Approved-At: Wed, 21 Dec 2011 12:10:26 +0000
Cc: olaf@aepfle.de, Adin Scannell <adin@scannell.ca>, andres@gridcentric.ca,
	linux-kernel@vger.kernel.org, JBeulich@suse.com,
	konrad@darnok.org, adin@gridcentric.com
Subject: [Xen-devel] [PATCH 3/3] Port of mmap_batch_v2 to support paging in
	Xen
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This wasn't ported from any patch, but was rewritten based on the XCP 2.6.32
tree.  The code structure is significantly different and this patch mirrors the
existing Linux code.

An important reason to add the V2 interface is to support foreign mappings
(i.e.  qemu-dm) of paged-out pages.  The kernel generally has to do nothing
beyond implementing this ioctl in order to provide this support.  The V2
interface is needed only to pass back full error codes from the mmu_update()'s.
Xen and libxc have a mutual understanding that when you receive an ENOENT error
code, you back off and try again. The libxc code will already retry mappings
when an ENOENT is returned.

The only exception to the above case is backend drivers using grant operations.
To support paging, these drivers must appropriately retry grant operations when
they receive an EAGAIN error code.  This is implemented in a separate patch.

Signed-off-by: Adin Scannell <adin@scannell.ca>
---
 drivers/xen/privcmd.c |   90 +++++++++++++++++++++++++++++++++++++++++++++++++
 include/xen/privcmd.h |   10 +++++
 2 files changed, 100 insertions(+), 0 deletions(-)

diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
index 161681f..dd77d5c 100644
--- a/drivers/xen/privcmd.c
+++ b/drivers/xen/privcmd.c
@@ -251,6 +251,15 @@ struct mmap_batch_state {
 	xen_pfn_t __user *user;
 };
 
+struct mmap_batch_v2_state {
+	domid_t domain;
+	unsigned long va;
+	struct vm_area_struct *vma;
+	unsigned long paged_out;
+
+	int __user *err;
+};
+
 static int mmap_batch_fn(void *data, void *state)
 {
 	xen_pfn_t *mfnp = data;
@@ -268,6 +277,22 @@ static int mmap_batch_fn(void *data, void *state)
 	return 0;
 }
 
+static int mmap_batch_v2_fn(void *data, void *state)
+{
+	xen_pfn_t *mfnp = data;
+	struct mmap_batch_v2_state *st = state;
+
+	BUG_ON(st == NULL || st->vma == NULL);
+
+	int rc = xen_remap_domain_mfn_range(st->vma, st->va & PAGE_MASK, *mfnp,
+				       1, st->vma->vm_page_prot, st->domain);
+	if (rc == -ENOENT)
+		st->paged_out++;
+	st->va += PAGE_SIZE;
+
+	return put_user(rc, st->err++);
+}
+
 static int mmap_return_errors(void *data, void *state)
 {
 	xen_pfn_t *mfnp = data;
@@ -340,6 +365,67 @@ out:
 	return ret;
 }
 
+static long privcmd_ioctl_mmap_batch_v2(void __user *udata)
+{
+	int ret;
+	struct privcmd_mmapbatch_v2 m;
+	struct mm_struct *mm = current->mm;
+	struct vm_area_struct *vma = NULL;
+	unsigned long nr_pages;
+	LIST_HEAD(pagelist);
+	struct mmap_batch_v2_state state;
+
+	if (!xen_initial_domain())
+		return -EPERM;
+
+	if (copy_from_user(&m, udata, sizeof(m)))
+		return -EFAULT;
+
+	nr_pages = m.num;
+	if ((m.num <= 0) || (nr_pages > (ULONG_MAX >> PAGE_SHIFT)))
+		return -EINVAL;
+
+	ret = gather_array(&pagelist, m.num, sizeof(xen_pfn_t),
+			   m.arr);
+
+	if (ret || list_empty(&pagelist))
+		goto out;
+
+	down_write(&mm->mmap_sem);
+
+	vma = find_vma(mm, m.addr);
+	ret = -EINVAL;
+	/* We allow multiple shots here, because this interface
+	 * is used by libxc and mappings for specific pages will
+	 * be retried when pages are paged-out (ENOENT). */
+	if (!vma ||
+	    vma->vm_ops != &privcmd_vm_ops ||
+	    (m.addr < vma->vm_start) ||
+	    ((m.addr + (nr_pages << PAGE_SHIFT)) > vma->vm_end)) {
+		up_write(&mm->mmap_sem);
+		goto out;
+	}
+
+	state.domain = m.dom;
+	state.vma = vma;
+	state.va = m.addr;
+	state.err = m.err;
+	state.paged_out = 0;
+
+	up_write(&mm->mmap_sem);
+
+	ret = traverse_pages(m.num, sizeof(xen_pfn_t),
+			     &pagelist, mmap_batch_v2_fn, &state);
+
+out:
+	free_page_list(&pagelist);
+
+	if ((ret == 0) && (state.paged_out > 0))
+		return -ENOENT;
+	else
+		return ret;
+}
+
 static long privcmd_ioctl(struct file *file,
 			  unsigned int cmd, unsigned long data)
 {
@@ -359,6 +445,10 @@ static long privcmd_ioctl(struct file *file,
 		ret = privcmd_ioctl_mmap_batch(udata);
 		break;
 
+	case IOCTL_PRIVCMD_MMAPBATCH_V2:
+		ret = privcmd_ioctl_mmap_batch_v2(udata);
+		break;
+
 	default:
 		ret = -EINVAL;
 		break;
diff --git a/include/xen/privcmd.h b/include/xen/privcmd.h
index 17857fb..39b92b1 100644
--- a/include/xen/privcmd.h
+++ b/include/xen/privcmd.h
@@ -62,6 +62,14 @@ struct privcmd_mmapbatch {
 	xen_pfn_t __user *arr; /* array of mfns - top nibble set on err */
 };
 
+struct privcmd_mmapbatch_v2 {
+	int num;          /* number of pages to populate */
+	domid_t dom;      /* target domain */
+	__u64 addr;       /* virtual address */
+	const xen_pfn_t __user *arr; /* array of mfns */
+	int __user *err;  /* array of error codes */
+};
+
 /*
  * @cmd: IOCTL_PRIVCMD_HYPERCALL
  * @arg: &privcmd_hypercall_t
@@ -73,5 +81,7 @@ struct privcmd_mmapbatch {
 	_IOC(_IOC_NONE, 'P', 2, sizeof(struct privcmd_mmap))
 #define IOCTL_PRIVCMD_MMAPBATCH					\
 	_IOC(_IOC_NONE, 'P', 3, sizeof(struct privcmd_mmapbatch))
+#define IOCTL_PRIVCMD_MMAPBATCH_V2				\
+	_IOC(_IOC_NONE, 'P', 4, sizeof(struct privcmd_mmapbatch_v2))
 
 #endif /* __LINUX_PUBLIC_PRIVCMD_H__ */
-- 
1.6.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 21 12:10:42 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 12:10:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdL09-0000XF-Sm; Wed, 21 Dec 2011 12:10:29 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <amscanne@dev.gridcentric.ca>) id 1Rbkox-0003S6-B8
	for xen-devel@lists.xensource.com; Sat, 17 Dec 2011 03:20:23 +0000
X-Env-Sender: amscanne@dev.gridcentric.ca
X-Msg-Ref: server-7.tower-182.messagelabs.com!1324092016!7560314!1
X-Originating-IP: [206.223.182.18]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13817 invoked from network); 17 Dec 2011 03:20:16 -0000
Received: from 206-223-182-18.beanfield.net (HELO dev.gridcentric.ca)
	(206.223.182.18) by server-7.tower-182.messagelabs.com with SMTP;
	17 Dec 2011 03:20:16 -0000
Received: by dev.gridcentric.ca (Postfix, from userid 500)
	id 3367460289; Fri, 16 Dec 2011 22:22:21 -0500 (EST)
From: Adin Scannell <adin@scannell.ca>
To: xen-devel@lists.xensource.com
Date: Fri, 16 Dec 2011 22:22:21 -0500
Message-Id: <1324092141-9730-4-git-send-email-adin@scannell.ca>
X-Mailer: git-send-email 1.6.2.5
In-Reply-To: <1324092141-9730-1-git-send-email-adin@scannell.ca>
References: <1324092141-9730-1-git-send-email-adin@scannell.ca>
X-Mailman-Approved-At: Wed, 21 Dec 2011 12:10:26 +0000
Cc: olaf@aepfle.de, Adin Scannell <adin@scannell.ca>, andres@gridcentric.ca,
	JBeulich@suse.com, konrad@darnok.org, adin@gridcentric.com
Subject: [Xen-devel] [PATCH 3/3] Port of mmap_batch_v2 to support paging in
	Xen
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This wasn't ported from any patch, but was rewritten based on the XCP 2.6.32
tree.  The code structure is significantly different and this patch mirrors the
existing Linux code.

The primary reason for need the V2 interface is to support foreign mappings
(i.e. qemu) of paged-out pages.  The libxc code will already retry mappings
when an ENOENT is returned.  The V2 interface provides a richer error value,
so the user-space code is capable of handling these errors specifically.

Signed-off-by: Adin Scannell <adin@scannell.ca>

Index: linux/drivers/xen/xenfs/privcmd.c
===================================================================
---
 drivers/xen/xenfs/privcmd.c |   90 ++++++++++++++++++++++++++++++++++++++++++-
 include/xen/privcmd.h       |   10 +++++
 2 files changed, 99 insertions(+), 1 deletions(-)

diff --git a/drivers/xen/xenfs/privcmd.c b/drivers/xen/xenfs/privcmd.c
index dbd3b16..21cbb5a 100644
--- a/drivers/xen/xenfs/privcmd.c
+++ b/drivers/xen/xenfs/privcmd.c
@@ -70,7 +70,7 @@ static void free_page_list(struct list_head *pages)
  */
 static int gather_array(struct list_head *pagelist,
 			unsigned nelem, size_t size,
-			void __user *data)
+			const void __user *data)
 {
 	unsigned pageidx;
 	void *pagedata;
@@ -245,6 +245,15 @@ struct mmap_batch_state {
 	xen_pfn_t __user *user;
 };
 
+struct mmap_batch_v2_state {
+	domid_t domain;
+	unsigned long va;
+	struct vm_area_struct *vma;
+	int paged_out;
+
+	int __user *err;
+};
+
 static int mmap_batch_fn(void *data, void *state)
 {
 	xen_pfn_t *mfnp = data;
@@ -260,6 +269,20 @@ static int mmap_batch_fn(void *data, void *state)
 	return 0;
 }
 
+static int mmap_batch_v2_fn(void *data, void *state)
+{
+	xen_pfn_t *mfnp = data;
+	struct mmap_batch_v2_state *st = state;
+
+	int rc = xen_remap_domain_mfn_range(st->vma, st->va & PAGE_MASK, *mfnp, 1,
+				       st->vma->vm_page_prot, st->domain);
+	if ( rc == -ENOENT )
+		st->paged_out++;
+	st->va += PAGE_SIZE;
+
+	return put_user(rc, st->err++);
+}
+
 static int mmap_return_errors(void *data, void *state)
 {
 	xen_pfn_t *mfnp = data;
@@ -332,6 +355,67 @@ out:
 	return ret;
 }
 
+static long privcmd_ioctl_mmap_batch_v2(void __user *udata)
+{
+	int ret;
+	struct privcmd_mmapbatch_v2 m;
+	struct mm_struct *mm = current->mm;
+	struct vm_area_struct *vma = NULL;
+	unsigned long nr_pages;
+	LIST_HEAD(pagelist);
+	struct mmap_batch_v2_state state;
+
+	if (!xen_initial_domain())
+		return -EPERM;
+
+	if (copy_from_user(&m, udata, sizeof(m)))
+		return -EFAULT;
+
+	nr_pages = m.num;
+	if ((m.num <= 0) || (nr_pages > (ULONG_MAX >> PAGE_SHIFT)))
+		return -EINVAL;
+
+	ret = gather_array(&pagelist, m.num, sizeof(xen_pfn_t),
+			   m.arr);
+
+	if (ret || list_empty(&pagelist))
+		goto out;
+
+	down_write(&mm->mmap_sem);
+
+	vma = find_vma(mm, m.addr);
+	ret = -EINVAL;
+	/* We allow multiple shots here, because this interface
+	 * is used by libxc and mappings for specific pages will
+	 * be retried when pages are paged-out (ENOENT). */
+	if (!vma ||
+	    vma->vm_ops != &privcmd_vm_ops ||
+	    (m.addr < vma->vm_start) ||
+	    ((m.addr + (nr_pages << PAGE_SHIFT)) > vma->vm_end)) {
+		up_write(&mm->mmap_sem);
+		goto out;
+	}
+
+	state.domain = m.dom;
+	state.vma = vma;
+	state.va = m.addr;
+	state.err = m.err;
+	state.paged_out = 0;
+
+	up_write(&mm->mmap_sem);
+
+	ret = traverse_pages(m.num, sizeof(xen_pfn_t),
+			     &pagelist, mmap_batch_v2_fn, &state);
+
+out:
+	free_page_list(&pagelist);
+
+	if ( (ret == 0) && (state.paged_out > 0) )
+		return -ENOENT;
+        else
+		return ret;
+}
+
 static long privcmd_ioctl(struct file *file,
 			  unsigned int cmd, unsigned long data)
 {
@@ -351,6 +435,10 @@ static long privcmd_ioctl(struct file *file,
 		ret = privcmd_ioctl_mmap_batch(udata);
 		break;
 
+	case IOCTL_PRIVCMD_MMAPBATCH_V2:
+		ret = privcmd_ioctl_mmap_batch_v2(udata);
+		break;
+
 	default:
 		ret = -EINVAL;
 		break;
diff --git a/include/xen/privcmd.h b/include/xen/privcmd.h
index 17857fb..39b92b1 100644
--- a/include/xen/privcmd.h
+++ b/include/xen/privcmd.h
@@ -62,6 +62,14 @@ struct privcmd_mmapbatch {
 	xen_pfn_t __user *arr; /* array of mfns - top nibble set on err */
 };
 
+struct privcmd_mmapbatch_v2 {
+	int num;          /* number of pages to populate */
+	domid_t dom;      /* target domain */
+	__u64 addr;       /* virtual address */
+	const xen_pfn_t __user *arr; /* array of mfns */
+	int __user *err;  /* array of error codes */
+};
+
 /*
  * @cmd: IOCTL_PRIVCMD_HYPERCALL
  * @arg: &privcmd_hypercall_t
@@ -73,5 +81,7 @@ struct privcmd_mmapbatch {
 	_IOC(_IOC_NONE, 'P', 2, sizeof(struct privcmd_mmap))
 #define IOCTL_PRIVCMD_MMAPBATCH					\
 	_IOC(_IOC_NONE, 'P', 3, sizeof(struct privcmd_mmapbatch))
+#define IOCTL_PRIVCMD_MMAPBATCH_V2				\
+	_IOC(_IOC_NONE, 'P', 4, sizeof(struct privcmd_mmapbatch_v2))
 
 #endif /* __LINUX_PUBLIC_PRIVCMD_H__ */
-- 
1.6.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 21 12:10:42 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 12:10:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdL09-0000X7-Fp; Wed, 21 Dec 2011 12:10:29 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <amscanne@dev.gridcentric.ca>) id 1Rbkow-0003S0-U7
	for xen-devel@lists.xensource.com; Sat, 17 Dec 2011 03:20:23 +0000
X-Env-Sender: amscanne@dev.gridcentric.ca
X-Msg-Ref: server-12.tower-174.messagelabs.com!1324092015!5853893!1
X-Originating-IP: [206.223.182.18]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23975 invoked from network); 17 Dec 2011 03:20:15 -0000
Received: from 206-223-182-18.beanfield.net (HELO dev.gridcentric.ca)
	(206.223.182.18) by server-12.tower-174.messagelabs.com with SMTP;
	17 Dec 2011 03:20:15 -0000
Received: by dev.gridcentric.ca (Postfix, from userid 500)
	id 0DAA760284; Fri, 16 Dec 2011 22:22:21 -0500 (EST)
From: Adin Scannell <adin@scannell.ca>
To: xen-devel@lists.xensource.com
Date: Fri, 16 Dec 2011 22:22:20 -0500
Message-Id: <1324092141-9730-3-git-send-email-adin@scannell.ca>
X-Mailer: git-send-email 1.6.2.5
In-Reply-To: <1324092141-9730-1-git-send-email-adin@scannell.ca>
References: <1324092141-9730-1-git-send-email-adin@scannell.ca>
X-Mailman-Approved-At: Wed, 21 Dec 2011 12:10:26 +0000
Cc: olaf@aepfle.de, Adin Scannell <adin@scannell.ca>, andres@gridcentric.ca,
	JBeulich@suse.com, konrad@darnok.org, adin@gridcentric.com
Subject: [Xen-devel] [PATCH 2/3] Handle GNTST_eagain in kernel drivers
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Handle GNTST_eagain status from GNTTABOP_map_grant_ref and
GNTTABOP_copy operations properly to allow usage of xenpaging without
causing crashes or data corruption.

Replace all relevant HYPERVISOR_grant_table_op() calls with a retry
loop. This loop is implemented as a macro to allow different
GNTTABOP_* args. It will sleep up to 33 seconds and wait for the
page to be paged in again.

All ->status checks were updated to use the GNTST_* namespace. All
return values are converted from GNTST_* namespace to 0/-EINVAL, since
all callers did not use the actual return value.

Signed-off-by: Olaf Hering <olaf@aepfle.de>
Acked-by: Patrick Colp <pjcolp@cs.ubc.ca>

This is a port to the mainline Linux tree.  This required dropping many backend
drivers which have not yet made it in.  Additionally, several of the referenced
functions have moved and/or been refactored.  I attempted to minimize changes
while keeping the same semantics.

Signed-off-by: Adin Scannell <adin@scannell.ca>

Index: linux/drivers/block/xen-blkback/blkback.c
===================================================================
---
 drivers/block/xen-blkback/blkback.c |    4 ++-
 drivers/xen/grant-table.c           |    7 ++++-
 drivers/xen/xenbus/xenbus_client.c  |    4 +++
 include/xen/grant_table.h           |   39 +++++++++++++++++++++++++++++++++++
 include/xen/interface/grant_table.h |    6 ++++-
 5 files changed, 56 insertions(+), 4 deletions(-)

diff --git a/drivers/block/xen-blkback/blkback.c b/drivers/block/xen-blkback/blkback.c
index 15ec4db..d3fb290 100644
--- a/drivers/block/xen-blkback/blkback.c
+++ b/drivers/block/xen-blkback/blkback.c
@@ -390,7 +390,9 @@ static int xen_blkbk_map(struct blkif_request *req,
 	 * the page from the other domain.
 	 */
 	for (i = 0; i < nseg; i++) {
-		if (unlikely(map[i].status != 0)) {
+		if (unlikely(map[i].status == GNTST_eagain))
+			gnttab_check_GNTST_eagain_do_while(GNTTABOP_map_grant_ref, &map[i]);
+		if (unlikely(map[i].status != GNTST_okay)) {
 			pr_debug(DRV_PFX "invalid buffer -- could not remap it\n");
 			map[i].handle = BLKBACK_INVALID_HANDLE;
 			ret |= 1;
diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
index bf1c094..48826c3 100644
--- a/drivers/xen/grant-table.c
+++ b/drivers/xen/grant-table.c
@@ -464,9 +464,12 @@ int gnttab_map_refs(struct gnttab_map_grant_ref *map_ops,
 
 	for (i = 0; i < count; i++) {
 		/* Do not add to override if the map failed. */
-		if (map_ops[i].status)
+		if (map_ops[i].status != GNTST_okay && map_ops[i].status != GNTST_eagain)
 			continue;
 
+		if (map_ops[i].status == GNTST_eagain)
+			return -EAGAIN;
+
 		if (map_ops[i].flags & GNTMAP_contains_pte) {
 			pte = (pte_t *) (mfn_to_virt(PFN_DOWN(map_ops[i].host_addr)) +
 				(map_ops[i].host_addr & ~PAGE_MASK));
@@ -565,7 +568,7 @@ static int gnttab_map(unsigned int start_idx, unsigned int end_idx)
 		return -ENOSYS;
 	}
 
-	BUG_ON(rc || setup.status);
+	BUG_ON(rc || (setup.status != GNTST_okay));
 
 	rc = arch_gnttab_map_shared(frames, nr_gframes, gnttab_max_grant_frames(),
 				    &shared);
diff --git a/drivers/xen/xenbus/xenbus_client.c b/drivers/xen/xenbus/xenbus_client.c
index 1906125..d123c78 100644
--- a/drivers/xen/xenbus/xenbus_client.c
+++ b/drivers/xen/xenbus/xenbus_client.c
@@ -455,6 +455,8 @@ int xenbus_map_ring_valloc(struct xenbus_device *dev, int gnt_ref, void **vaddr)
 	if (HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, &op, 1))
 		BUG();
 
+	if (op.status == GNTST_eagain)
+		gnttab_check_GNTST_eagain_do_while(GNTTABOP_map_grant_ref, (&op));
 	if (op.status != GNTST_okay) {
 		free_vm_area(area);
 		xenbus_dev_fatal(dev, op.status,
@@ -499,6 +501,8 @@ int xenbus_map_ring(struct xenbus_device *dev, int gnt_ref,
 	if (HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, &op, 1))
 		BUG();
 
+	if (op.status == GNTST_eagain)
+		gnttab_check_GNTST_eagain_do_while(GNTTABOP_map_grant_ref, (&op));
 	if (op.status != GNTST_okay) {
 		xenbus_dev_fatal(dev, op.status,
 				 "mapping in shared page %d from domain %d",
diff --git a/include/xen/grant_table.h b/include/xen/grant_table.h
index 11e2dfc..46fac85 100644
--- a/include/xen/grant_table.h
+++ b/include/xen/grant_table.h
@@ -37,6 +37,8 @@
 #ifndef __ASM_GNTTAB_H__
 #define __ASM_GNTTAB_H__
 
+#include <linux/delay.h>
+
 #include <asm/page.h>
 
 #include <xen/interface/xen.h>
@@ -160,4 +162,41 @@ int gnttab_map_refs(struct gnttab_map_grant_ref *map_ops,
 int gnttab_unmap_refs(struct gnttab_unmap_grant_ref *unmap_ops,
 		      struct page **pages, unsigned int count);
 
+#define gnttab_check_GNTST_eagain_while(__HCop, __HCarg_p)					\
+do {																		\
+	u8 __hc_delay = 1;														\
+	int __ret;																\
+	while (unlikely((__HCarg_p)->status == GNTST_eagain && __hc_delay)) {	\
+		msleep(__hc_delay++);												\
+		__ret = HYPERVISOR_grant_table_op(__HCop, (__HCarg_p), 1);			\
+		BUG_ON(__ret);														\
+	}																		\
+	if (__hc_delay == 0) {													\
+		printk(KERN_ERR "%s: gnt busy\n", __func__,);						\
+		(__HCarg_p)->status = GNTST_bad_page;								\
+	}																		\
+	if ((__HCarg_p)->status != GNTST_okay)									\
+		printk(KERN_ERR "%s: gnt status %x\n", 								\
+			__func__, (__HCarg_p)->status);									\
+} while(0)
+
+#define gnttab_check_GNTST_eagain_do_while(__HCop, __HCarg_p)			\
+do {																	\
+	u8 __hc_delay = 1;													\
+	int __ret;															\
+	do {																\
+		__ret = HYPERVISOR_grant_table_op(__HCop, (__HCarg_p), 1);		\
+		BUG_ON(__ret);													\
+		if ((__HCarg_p)->status == GNTST_eagain)						\
+			msleep(__hc_delay++);										\
+	} while ((__HCarg_p)->status == GNTST_eagain && __hc_delay);		\
+	if (__hc_delay == 0) {												\
+		printk(KERN_ERR "%s: gnt busy\n", __func__);					\
+		(__HCarg_p)->status = GNTST_bad_page;							\
+	}																	\
+	if ((__HCarg_p)->status != GNTST_okay)								\
+		printk(KERN_ERR "%s: gnt status %x\n", 							\
+			__func__, (__HCarg_p)->status);								\
+} while(0)
+
 #endif /* __ASM_GNTTAB_H__ */
diff --git a/include/xen/interface/grant_table.h b/include/xen/interface/grant_table.h
index 39e5717..ba04080 100644
--- a/include/xen/interface/grant_table.h
+++ b/include/xen/interface/grant_table.h
@@ -363,6 +363,8 @@ DEFINE_GUEST_HANDLE_STRUCT(gnttab_query_size);
 #define GNTST_permission_denied (-8) /* Not enough privilege for operation.  */
 #define GNTST_bad_page         (-9) /* Specified page was invalid for op.    */
 #define GNTST_bad_copy_arg    (-10) /* copy arguments cross page boundary */
+#define GNTST_address_too_big (-11) /* transfer page address too large.      */
+#define GNTST_eagain          (-12) /* Could not map at the moment. Retry.   */
 
 #define GNTTABOP_error_msgs {                   \
     "okay",                                     \
@@ -375,7 +377,9 @@ DEFINE_GUEST_HANDLE_STRUCT(gnttab_query_size);
     "no spare translation slot in the I/O MMU", \
     "permission denied",                        \
     "bad page",                                 \
-    "copy arguments cross page boundary"        \
+    "copy arguments cross page boundary",       \
+    "page address size too large",              \
+    "could not map at the moment, retry"        \
 }
 
 #endif /* __XEN_PUBLIC_GRANT_TABLE_H__ */
-- 
1.6.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 21 12:10:42 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 12:10:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdL09-0000XF-Sm; Wed, 21 Dec 2011 12:10:29 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <amscanne@dev.gridcentric.ca>) id 1Rbkox-0003S6-B8
	for xen-devel@lists.xensource.com; Sat, 17 Dec 2011 03:20:23 +0000
X-Env-Sender: amscanne@dev.gridcentric.ca
X-Msg-Ref: server-7.tower-182.messagelabs.com!1324092016!7560314!1
X-Originating-IP: [206.223.182.18]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13817 invoked from network); 17 Dec 2011 03:20:16 -0000
Received: from 206-223-182-18.beanfield.net (HELO dev.gridcentric.ca)
	(206.223.182.18) by server-7.tower-182.messagelabs.com with SMTP;
	17 Dec 2011 03:20:16 -0000
Received: by dev.gridcentric.ca (Postfix, from userid 500)
	id 3367460289; Fri, 16 Dec 2011 22:22:21 -0500 (EST)
From: Adin Scannell <adin@scannell.ca>
To: xen-devel@lists.xensource.com
Date: Fri, 16 Dec 2011 22:22:21 -0500
Message-Id: <1324092141-9730-4-git-send-email-adin@scannell.ca>
X-Mailer: git-send-email 1.6.2.5
In-Reply-To: <1324092141-9730-1-git-send-email-adin@scannell.ca>
References: <1324092141-9730-1-git-send-email-adin@scannell.ca>
X-Mailman-Approved-At: Wed, 21 Dec 2011 12:10:26 +0000
Cc: olaf@aepfle.de, Adin Scannell <adin@scannell.ca>, andres@gridcentric.ca,
	JBeulich@suse.com, konrad@darnok.org, adin@gridcentric.com
Subject: [Xen-devel] [PATCH 3/3] Port of mmap_batch_v2 to support paging in
	Xen
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This wasn't ported from any patch, but was rewritten based on the XCP 2.6.32
tree.  The code structure is significantly different and this patch mirrors the
existing Linux code.

The primary reason for need the V2 interface is to support foreign mappings
(i.e. qemu) of paged-out pages.  The libxc code will already retry mappings
when an ENOENT is returned.  The V2 interface provides a richer error value,
so the user-space code is capable of handling these errors specifically.

Signed-off-by: Adin Scannell <adin@scannell.ca>

Index: linux/drivers/xen/xenfs/privcmd.c
===================================================================
---
 drivers/xen/xenfs/privcmd.c |   90 ++++++++++++++++++++++++++++++++++++++++++-
 include/xen/privcmd.h       |   10 +++++
 2 files changed, 99 insertions(+), 1 deletions(-)

diff --git a/drivers/xen/xenfs/privcmd.c b/drivers/xen/xenfs/privcmd.c
index dbd3b16..21cbb5a 100644
--- a/drivers/xen/xenfs/privcmd.c
+++ b/drivers/xen/xenfs/privcmd.c
@@ -70,7 +70,7 @@ static void free_page_list(struct list_head *pages)
  */
 static int gather_array(struct list_head *pagelist,
 			unsigned nelem, size_t size,
-			void __user *data)
+			const void __user *data)
 {
 	unsigned pageidx;
 	void *pagedata;
@@ -245,6 +245,15 @@ struct mmap_batch_state {
 	xen_pfn_t __user *user;
 };
 
+struct mmap_batch_v2_state {
+	domid_t domain;
+	unsigned long va;
+	struct vm_area_struct *vma;
+	int paged_out;
+
+	int __user *err;
+};
+
 static int mmap_batch_fn(void *data, void *state)
 {
 	xen_pfn_t *mfnp = data;
@@ -260,6 +269,20 @@ static int mmap_batch_fn(void *data, void *state)
 	return 0;
 }
 
+static int mmap_batch_v2_fn(void *data, void *state)
+{
+	xen_pfn_t *mfnp = data;
+	struct mmap_batch_v2_state *st = state;
+
+	int rc = xen_remap_domain_mfn_range(st->vma, st->va & PAGE_MASK, *mfnp, 1,
+				       st->vma->vm_page_prot, st->domain);
+	if ( rc == -ENOENT )
+		st->paged_out++;
+	st->va += PAGE_SIZE;
+
+	return put_user(rc, st->err++);
+}
+
 static int mmap_return_errors(void *data, void *state)
 {
 	xen_pfn_t *mfnp = data;
@@ -332,6 +355,67 @@ out:
 	return ret;
 }
 
+static long privcmd_ioctl_mmap_batch_v2(void __user *udata)
+{
+	int ret;
+	struct privcmd_mmapbatch_v2 m;
+	struct mm_struct *mm = current->mm;
+	struct vm_area_struct *vma = NULL;
+	unsigned long nr_pages;
+	LIST_HEAD(pagelist);
+	struct mmap_batch_v2_state state;
+
+	if (!xen_initial_domain())
+		return -EPERM;
+
+	if (copy_from_user(&m, udata, sizeof(m)))
+		return -EFAULT;
+
+	nr_pages = m.num;
+	if ((m.num <= 0) || (nr_pages > (ULONG_MAX >> PAGE_SHIFT)))
+		return -EINVAL;
+
+	ret = gather_array(&pagelist, m.num, sizeof(xen_pfn_t),
+			   m.arr);
+
+	if (ret || list_empty(&pagelist))
+		goto out;
+
+	down_write(&mm->mmap_sem);
+
+	vma = find_vma(mm, m.addr);
+	ret = -EINVAL;
+	/* We allow multiple shots here, because this interface
+	 * is used by libxc and mappings for specific pages will
+	 * be retried when pages are paged-out (ENOENT). */
+	if (!vma ||
+	    vma->vm_ops != &privcmd_vm_ops ||
+	    (m.addr < vma->vm_start) ||
+	    ((m.addr + (nr_pages << PAGE_SHIFT)) > vma->vm_end)) {
+		up_write(&mm->mmap_sem);
+		goto out;
+	}
+
+	state.domain = m.dom;
+	state.vma = vma;
+	state.va = m.addr;
+	state.err = m.err;
+	state.paged_out = 0;
+
+	up_write(&mm->mmap_sem);
+
+	ret = traverse_pages(m.num, sizeof(xen_pfn_t),
+			     &pagelist, mmap_batch_v2_fn, &state);
+
+out:
+	free_page_list(&pagelist);
+
+	if ( (ret == 0) && (state.paged_out > 0) )
+		return -ENOENT;
+        else
+		return ret;
+}
+
 static long privcmd_ioctl(struct file *file,
 			  unsigned int cmd, unsigned long data)
 {
@@ -351,6 +435,10 @@ static long privcmd_ioctl(struct file *file,
 		ret = privcmd_ioctl_mmap_batch(udata);
 		break;
 
+	case IOCTL_PRIVCMD_MMAPBATCH_V2:
+		ret = privcmd_ioctl_mmap_batch_v2(udata);
+		break;
+
 	default:
 		ret = -EINVAL;
 		break;
diff --git a/include/xen/privcmd.h b/include/xen/privcmd.h
index 17857fb..39b92b1 100644
--- a/include/xen/privcmd.h
+++ b/include/xen/privcmd.h
@@ -62,6 +62,14 @@ struct privcmd_mmapbatch {
 	xen_pfn_t __user *arr; /* array of mfns - top nibble set on err */
 };
 
+struct privcmd_mmapbatch_v2 {
+	int num;          /* number of pages to populate */
+	domid_t dom;      /* target domain */
+	__u64 addr;       /* virtual address */
+	const xen_pfn_t __user *arr; /* array of mfns */
+	int __user *err;  /* array of error codes */
+};
+
 /*
  * @cmd: IOCTL_PRIVCMD_HYPERCALL
  * @arg: &privcmd_hypercall_t
@@ -73,5 +81,7 @@ struct privcmd_mmapbatch {
 	_IOC(_IOC_NONE, 'P', 2, sizeof(struct privcmd_mmap))
 #define IOCTL_PRIVCMD_MMAPBATCH					\
 	_IOC(_IOC_NONE, 'P', 3, sizeof(struct privcmd_mmapbatch))
+#define IOCTL_PRIVCMD_MMAPBATCH_V2				\
+	_IOC(_IOC_NONE, 'P', 4, sizeof(struct privcmd_mmapbatch_v2))
 
 #endif /* __LINUX_PUBLIC_PRIVCMD_H__ */
-- 
1.6.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 21 12:18:17 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 12:18:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdL7Z-0004Nk-1Z; Wed, 21 Dec 2011 12:18:09 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <gang.wei@intel.com>) id 1RdL7X-0004NT-2L
	for xen-devel@lists.xensource.com; Wed, 21 Dec 2011 12:18:07 +0000
X-Env-Sender: gang.wei@intel.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1324469880!2824026!1
X-Originating-IP: [134.134.136.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjQgPT4gMzE4ODQy\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30226 invoked from network); 21 Dec 2011 12:18:01 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-9.tower-21.messagelabs.com with SMTP;
	21 Dec 2011 12:18:01 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga102.jf.intel.com with ESMTP; 21 Dec 2011 04:18:00 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.67,351,1309762800"; d="scan'208";a="89945328"
Received: from pgsmsx603.gar.corp.intel.com ([10.221.43.87])
	by orsmga002.jf.intel.com with ESMTP; 21 Dec 2011 04:17:58 -0800
Received: from shsmsx602.ccr.corp.intel.com (10.239.4.104) by
	pgsmsx603.gar.corp.intel.com (10.221.43.87) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Wed, 21 Dec 2011 20:17:58 +0800
Received: from shsmsx502.ccr.corp.intel.com ([10.239.4.96]) by
	SHSMSX602.ccr.corp.intel.com ([10.239.4.104]) with mapi;
	Wed, 21 Dec 2011 20:17:57 +0800
From: "Wei, Gang" <gang.wei@intel.com>
To: Keir Fraser <keir@xen.org>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>
Date: Wed, 21 Dec 2011 20:17:54 +0800
Thread-Topic: [patch] x86: Add a delay between INIT & SIPIs for AP bring-up
	in X2APIC case
Thread-Index: Acy/0uD62iL7OBXBT0+nwXPeOaB7qgABgY/9AAA3VoA=
Message-ID: <F26D193E20BBDC42A43B611D1BDEDE7135CEEEAE63@shsmsx502.ccr.corp.intel.com>
References: <F26D193E20BBDC42A43B611D1BDEDE7135CEEEAE56@shsmsx502.ccr.corp.intel.com>
	<CB177C28.365E3%keir@xen.org>
In-Reply-To: <CB177C28.365E3%keir@xen.org>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: zh-CN, en-US
MIME-Version: 1.0
Cc: "tboot-devel@lists.sourceforge.net" <tboot-devel@lists.sourceforge.net>,
	"Cihula, Joseph" <joseph.cihula@intel.com>,
	Tim Deegan <Tim.Deegan@citrix.com>, Jan Beulich <jbeulich@suse.com>, "Wei,
	Gang" <gang.wei@intel.com>
Subject: Re: [Xen-devel] [patch] x86: Add a delay between INIT & SIPIs for
 AP bring-up in X2APIC case
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Keir Fraser wrote on=A02011-12-21:
> On 21/12/2011 11:22, "Wei, Gang" <gang.wei@intel.com> wrote:
> =

>> Without this delay, Xen could not bring APs up while working with
>> TXT/tboot, because tboot need some time in APs to handle INIT before
>> becoming ready for receiving SIPIs. (this delay was removed as part
>> of c/s 23724 by Tim Deegan)
> =

> Of course Tim will need to review this himself, but a mdelay() right
> here, only on the x2apic path just looks bizarre and fragile.
> =

> Could we make the !x2apic_enabled conditionals that Tim added be
> !(x2apic_enabled || tboot_in_measured_env()) instead? At least that is
> somewhat self-documenting and clearly only affects tboot!

Does below patch make more sense?

diff -r d1aefee43af1 xen/arch/x86/smpboot.c
--- a/xen/arch/x86/smpboot.c    Wed Dec 21 18:51:31 2011 +0800
+++ b/xen/arch/x86/smpboot.c    Wed Dec 21 19:08:57 2011 +0800
@@ -463,6 +463,10 @@ static int wakeup_secondary_cpu(int phys
             send_status =3D apic_read(APIC_ICR) & APIC_ICR_BUSY;
         } while ( send_status && (timeout++ < 1000) );
     }
+    else if ( tboot_in_measured_env() )
+    {
+        udelay(10);
+    }

     /*
      * Should we send STARTUP IPIs ?

Jimmy

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 21 12:18:17 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 12:18:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdL7Z-0004Nk-1Z; Wed, 21 Dec 2011 12:18:09 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <gang.wei@intel.com>) id 1RdL7X-0004NT-2L
	for xen-devel@lists.xensource.com; Wed, 21 Dec 2011 12:18:07 +0000
X-Env-Sender: gang.wei@intel.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1324469880!2824026!1
X-Originating-IP: [134.134.136.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjQgPT4gMzE4ODQy\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30226 invoked from network); 21 Dec 2011 12:18:01 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-9.tower-21.messagelabs.com with SMTP;
	21 Dec 2011 12:18:01 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga102.jf.intel.com with ESMTP; 21 Dec 2011 04:18:00 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.67,351,1309762800"; d="scan'208";a="89945328"
Received: from pgsmsx603.gar.corp.intel.com ([10.221.43.87])
	by orsmga002.jf.intel.com with ESMTP; 21 Dec 2011 04:17:58 -0800
Received: from shsmsx602.ccr.corp.intel.com (10.239.4.104) by
	pgsmsx603.gar.corp.intel.com (10.221.43.87) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Wed, 21 Dec 2011 20:17:58 +0800
Received: from shsmsx502.ccr.corp.intel.com ([10.239.4.96]) by
	SHSMSX602.ccr.corp.intel.com ([10.239.4.104]) with mapi;
	Wed, 21 Dec 2011 20:17:57 +0800
From: "Wei, Gang" <gang.wei@intel.com>
To: Keir Fraser <keir@xen.org>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>
Date: Wed, 21 Dec 2011 20:17:54 +0800
Thread-Topic: [patch] x86: Add a delay between INIT & SIPIs for AP bring-up
	in X2APIC case
Thread-Index: Acy/0uD62iL7OBXBT0+nwXPeOaB7qgABgY/9AAA3VoA=
Message-ID: <F26D193E20BBDC42A43B611D1BDEDE7135CEEEAE63@shsmsx502.ccr.corp.intel.com>
References: <F26D193E20BBDC42A43B611D1BDEDE7135CEEEAE56@shsmsx502.ccr.corp.intel.com>
	<CB177C28.365E3%keir@xen.org>
In-Reply-To: <CB177C28.365E3%keir@xen.org>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: zh-CN, en-US
MIME-Version: 1.0
Cc: "tboot-devel@lists.sourceforge.net" <tboot-devel@lists.sourceforge.net>,
	"Cihula, Joseph" <joseph.cihula@intel.com>,
	Tim Deegan <Tim.Deegan@citrix.com>, Jan Beulich <jbeulich@suse.com>, "Wei,
	Gang" <gang.wei@intel.com>
Subject: Re: [Xen-devel] [patch] x86: Add a delay between INIT & SIPIs for
 AP bring-up in X2APIC case
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Keir Fraser wrote on=A02011-12-21:
> On 21/12/2011 11:22, "Wei, Gang" <gang.wei@intel.com> wrote:
> =

>> Without this delay, Xen could not bring APs up while working with
>> TXT/tboot, because tboot need some time in APs to handle INIT before
>> becoming ready for receiving SIPIs. (this delay was removed as part
>> of c/s 23724 by Tim Deegan)
> =

> Of course Tim will need to review this himself, but a mdelay() right
> here, only on the x2apic path just looks bizarre and fragile.
> =

> Could we make the !x2apic_enabled conditionals that Tim added be
> !(x2apic_enabled || tboot_in_measured_env()) instead? At least that is
> somewhat self-documenting and clearly only affects tboot!

Does below patch make more sense?

diff -r d1aefee43af1 xen/arch/x86/smpboot.c
--- a/xen/arch/x86/smpboot.c    Wed Dec 21 18:51:31 2011 +0800
+++ b/xen/arch/x86/smpboot.c    Wed Dec 21 19:08:57 2011 +0800
@@ -463,6 +463,10 @@ static int wakeup_secondary_cpu(int phys
             send_status =3D apic_read(APIC_ICR) & APIC_ICR_BUSY;
         } while ( send_status && (timeout++ < 1000) );
     }
+    else if ( tboot_in_measured_env() )
+    {
+        udelay(10);
+    }

     /*
      * Should we send STARTUP IPIs ?

Jimmy

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 21 12:22:06 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 12:22:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdLBE-0004j4-SL; Wed, 21 Dec 2011 12:21:56 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1RdLBC-0004iY-UX
	for xen-devel@lists.xensource.com; Wed, 21 Dec 2011 12:21:55 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1324470105!6228453!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=1.4 required=7.0 tests=BODY_RANDOM_LONG,DIET_1,
	RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29679 invoked from network); 21 Dec 2011 12:21:46 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Dec 2011 12:21:46 -0000
Received: by iagw33 with SMTP id w33so41369040iag.30
	for <xen-devel@lists.xensource.com>;
	Wed, 21 Dec 2011 04:21:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=kLCF5VJ6E95JT7OZZMotrzT7YpwRtvRDB8hMreMUKRw=;
	b=N4biVQw3PxC+ydbPgF79Fs6/4FhOYvzH8hZ0GQiEiscVSfM2RgF9Q4TRyDKYbBSJNu
	Hm2gNx+YbjiF/fNb9nFSEuG0n4dtJMW6RGWYCgOrZsDuejtfC5GoifRnoA4SsGbU3uza
	wJ50o6L7dDDm4tJbDZwiVu8H0UpIu3+mVAj3E=
MIME-Version: 1.0
Received: by 10.50.191.225 with SMTP id hb1mr3069062igc.17.1324470105104; Wed,
	21 Dec 2011 04:21:45 -0800 (PST)
Received: by 10.231.146.21 with HTTP; Wed, 21 Dec 2011 04:21:45 -0800 (PST)
In-Reply-To: <1324454839.2682.1.camel@Solace>
References: <1324454839.2682.1.camel@Solace>
Date: Wed, 21 Dec 2011 12:21:45 +0000
X-Google-Sender-Auth: l7j2o718I0v7SuIbk-OjZpVEg1k
Message-ID: <CAFLBxZYtb+DaZ3cQD=KR1Xty-YZtsyC53PEiNO4bVU=3qP2WSg@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Dario Faggioli <raistlin@linux.it>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Keir Fraser <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH] sedf: remove useless tracing printk and
 harmonize comments style.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Dec 21, 2011 at 8:07 AM, Dario Faggioli <raistlin@linux.it> wrote:
> sched_sedf.c used o have its own mechanism for producing tracing-alike
> kind of information (domain block, wakeup, etc.). Nowadays, with an even
> not so high number of pCPUs/vCPUs, just trying to enable this makes
> the serial console completely unusable, produces tons of very hard to
> parse and interpreet logging and can easily livelock Dom0. Moreover,
> pretty much the same result this is struggling to get to, is better
> achieved by enabling the scheduler-related tracing events, as
> it is for the other schedulers (say, credit or credit2).
>
> For all these reasons, this removes that machinery completely. While at
> it, check in some cosmetics that harmonize the comments withim themself
> and with the rest of the code base.

RE removing the prinks, and most of the comment changes, ACK.

However, I think the typical comment style is that you should either
do things this way:

/* A one-line comment, start and end in one line */

Or this way:
/*
 * A multi-line comment,
 * Where the opening and closing each have their own line.
 */

Or,
/* If you have a short comment that can't fit on
 * one line, put it on two, but with out any extra lines. */

But you seem to be replacing all multi-line comments with this:

/* The first line having the open-comment at the benning,
 * But the close-comment having its own line.
 */

I've never seen that before, and it looks a bit weird. :-)

I prefer the first two, with judicious use of the third when appropriate.

 -George
>
> Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
>
> diff -r 17d99691e0ec xen/common/sched_sedf.c
> --- a/xen/common/sched_sedf.c =A0 Tue Dec 20 16:39:56 2011 +0000
> +++ b/xen/common/sched_sedf.c =A0 Tue Dec 20 17:32:52 2011 +0000
> @@ -13,14 +13,6 @@
> =A0#include <xen/time.h>
> =A0#include <xen/errno.h>
>
> -/*verbosity settings*/
> -#define SEDFLEVEL 0
> -#define PRINT(_f, _a...) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0\
> - =A0 =A0do { =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 =A0\
> - =A0 =A0 =A0 =A0if ( (_f) <=3D SEDFLEVEL ) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0\
> - =A0 =A0 =A0 =A0 =A0 =A0printk(_a ); =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0\
> - =A0 =A0} while ( 0 )
> -
> =A0#define SEDF_CPUONLINE(_pool) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 \
> =A0 =A0 (((_pool) =3D=3D NULL) ? &cpupool_free_cpus : (_pool)->cpu_valid)
>
> @@ -66,34 +58,35 @@ struct sedf_vcpu_info {
> =A0 =A0 struct list_head list;
> =A0 =A0 struct list_head extralist[2];
>
> - =A0 =A0/*Parameters for EDF*/
> - =A0 =A0s_time_t =A0period; =A0/*=3D(relative deadline)*/
> - =A0 =A0s_time_t =A0slice; =A0/*=3Dworst case execution time*/
> + =A0 =A0/* Parameters for EDF */
> + =A0 =A0s_time_t =A0period; =A0/* =3D(relative deadline) */
> + =A0 =A0s_time_t =A0slice; =A0 /* =3Dworst case execution time */
>
> - =A0 =A0/*Advaced Parameters*/
> - =A0 =A0/*Latency Scaling*/
> + =A0 =A0/* Advaced Parameters */
> +
> + =A0 =A0/* Latency Scaling */
> =A0 =A0 s_time_t =A0period_orig;
> =A0 =A0 s_time_t =A0slice_orig;
> =A0 =A0 s_time_t =A0latency;
>
> - =A0 =A0/*status of domain*/
> + =A0 =A0/* Status of domain */
> =A0 =A0 int =A0 =A0 =A0 status;
> - =A0 =A0/*weights for "Scheduling for beginners/ lazy/ etc." ;)*/
> + =A0 =A0/* Weights for "Scheduling for beginners/ lazy/ etc." ;) */
> =A0 =A0 short =A0 =A0 weight;
> =A0 =A0 short =A0 =A0 extraweight;
> - =A0 =A0/*Bookkeeping*/
> + =A0 =A0/* Bookkeeping */
> =A0 =A0 s_time_t =A0deadl_abs;
> =A0 =A0 s_time_t =A0sched_start_abs;
> =A0 =A0 s_time_t =A0cputime;
> - =A0 =A0/* times the domain un-/blocked */
> + =A0 =A0/* Times the domain un-/blocked */
> =A0 =A0 s_time_t =A0block_abs;
> =A0 =A0 s_time_t =A0unblock_abs;
>
> - =A0 =A0/*scores for {util, block penalty}-weighted extratime distributi=
on*/
> + =A0 =A0/* Scores for {util, block penalty}-weighted extratime distribut=
ion */
> =A0 =A0 int =A0 score[2];
> =A0 =A0 s_time_t =A0short_block_lost_tot;
>
> - =A0 =A0/*Statistics*/
> + =A0 =A0/* Statistics */
> =A0 =A0 s_time_t =A0extra_time_tot;
>
> =A0#ifdef SEDF_STATS
> @@ -158,18 +151,16 @@ static inline void extraq_del(struct vcp
> =A0{
> =A0 =A0 struct list_head *list =3D EXTRALIST(d,i);
> =A0 =A0 ASSERT(extraq_on(d,i));
> - =A0 =A0PRINT(3, "Removing domain %i.%i from L%i extraq\n",
> - =A0 =A0 =A0 =A0 =A0d->domain->domain_id, d->vcpu_id, i);
> =A0 =A0 list_del(list);
> =A0 =A0 list->next =3D NULL;
> =A0 =A0 ASSERT(!extraq_on(d, i));
> =A0}
>
> -/* adds a domain to the queue of processes which are aware of extra time=
. List
> - =A0 is sorted by score, where a lower score means higher priority for a=
n extra
> - =A0 slice. It also updates the score, by simply subtracting a fixed val=
ue from
> - =A0 each entry, in order to avoid overflow. The algorithm works by simp=
ly
> - =A0 charging each domain that recieved extratime with an inverse of its=
 weight.
> +/* Adds a domain to the queue of processes which are aware of extra time=
. List
> + * is sorted by score, where a lower score means higher priority for an =
extra
> + * slice. It also updates the score, by simply subtracting a fixed value=
 from
> + * each entry, in order to avoid overflow. The algorithm works by simply
> + * charging each domain that recieved extratime with an inverse of its w=
eight.
> =A0*/
> =A0static inline void extraq_add_sort_update(struct vcpu *d, int i, int s=
ub)
> =A0{
> @@ -178,13 +169,7 @@ static inline void extraq_add_sort_updat
>
> =A0 =A0 ASSERT(!extraq_on(d,i));
>
> - =A0 =A0PRINT(3, "Adding domain %i.%i (score=3D %i, short_pen=3D %"PRIi6=
4")"
> - =A0 =A0 =A0 =A0 =A0" to L%i extraq\n",
> - =A0 =A0 =A0 =A0 =A0d->domain->domain_id, d->vcpu_id, EDOM_INFO(d)->scor=
e[i],
> - =A0 =A0 =A0 =A0 =A0EDOM_INFO(d)->short_block_lost_tot, i);
> -
> - =A0 =A0/*
> - =A0 =A0 * Iterate through all elements to find our "hole" and on our way
> + =A0 =A0/* Iterate through all elements to find our "hole" and on our way
> =A0 =A0 =A0* update all the other scores.
> =A0 =A0 =A0*/
> =A0 =A0 list_for_each ( cur, EXTRAQ(d->processor, i) )
> @@ -193,25 +178,18 @@ static inline void extraq_add_sort_updat
> =A0 =A0 =A0 =A0 curinf->score[i] -=3D sub;
> =A0 =A0 =A0 =A0 if ( EDOM_INFO(d)->score[i] < curinf->score[i] )
> =A0 =A0 =A0 =A0 =A0 =A0 break;
> - =A0 =A0 =A0 =A0PRINT(4,"\tbehind domain %i.%i (score=3D %i)\n",
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0curinf->vcpu->domain->domain_id,
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0curinf->vcpu->vcpu_id, curinf->score[i]);
> =A0 =A0 }
>
> - =A0 =A0/* cur now contains the element, before which we'll enqueue. */
> - =A0 =A0PRINT(3, "\tlist_add to %p\n", cur->prev);
> + =A0 =A0/* cur now contains the element, before which we'll enqueue */
> =A0 =A0 list_add(EXTRALIST(d,i),cur->prev);
>
> - =A0 =A0/* Continue updating the extraq. */
> + =A0 =A0/* Continue updating the extraq */
> =A0 =A0 if ( (cur !=3D EXTRAQ(d->processor,i)) && sub )
> =A0 =A0 {
> =A0 =A0 =A0 =A0 for ( cur =3D cur->next; cur !=3D EXTRAQ(d->processor,i);=
 cur =3D cur->next )
> =A0 =A0 =A0 =A0 {
> =A0 =A0 =A0 =A0 =A0 =A0 curinf =3D list_entry(cur,struct sedf_vcpu_info, =
extralist[i]);
> =A0 =A0 =A0 =A0 =A0 =A0 curinf->score[i] -=3D sub;
> - =A0 =A0 =A0 =A0 =A0 =A0PRINT(4, "\tupdating domain %i.%i (score=3D %u)\=
n",
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0curinf->vcpu->domain->domain_id,
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0curinf->vcpu->vcpu_id, curinf->score=
[i]);
> =A0 =A0 =A0 =A0 }
> =A0 =A0 }
>
> @@ -221,29 +199,14 @@ static inline void extraq_check(struct v
> =A0{
> =A0 =A0 if ( extraq_on(d, EXTRA_UTIL_Q) )
> =A0 =A0 {
> - =A0 =A0 =A0 =A0PRINT(2,"Dom %i.%i is on L1 extraQ\n",
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0d->domain->domain_id, d->vcpu_id);
> -
> =A0 =A0 =A0 =A0 if ( !(EDOM_INFO(d)->status & EXTRA_AWARE) &&
> =A0 =A0 =A0 =A0 =A0 =A0 =A0!extra_runs(EDOM_INFO(d)) )
> - =A0 =A0 =A0 =A0{
> =A0 =A0 =A0 =A0 =A0 =A0 extraq_del(d, EXTRA_UTIL_Q);
> - =A0 =A0 =A0 =A0 =A0 =A0PRINT(2,"Removed dom %i.%i from L1 extraQ\n",
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0d->domain->domain_id, d->vcpu_id);
> - =A0 =A0 =A0 =A0}
> =A0 =A0 }
> =A0 =A0 else
> =A0 =A0 {
> - =A0 =A0 =A0 =A0PRINT(2, "Dom %i.%i is NOT on L1 extraQ\n",
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0d->domain->domain_id,
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0d->vcpu_id);
> -
> =A0 =A0 =A0 =A0 if ( (EDOM_INFO(d)->status & EXTRA_AWARE) && sedf_runnabl=
e(d) )
> - =A0 =A0 =A0 =A0{
> =A0 =A0 =A0 =A0 =A0 =A0 extraq_add_sort_update(d, EXTRA_UTIL_Q, 0);
> - =A0 =A0 =A0 =A0 =A0 =A0PRINT(2,"Added dom %i.%i to L1 extraQ\n",
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0d->domain->domain_id, d->vcpu_id);
> - =A0 =A0 =A0 =A0}
> =A0 =A0 }
> =A0}
>
> @@ -252,7 +215,7 @@ static inline void extraq_check_add_unbl
> =A0 =A0 struct sedf_vcpu_info *inf =3D EDOM_INFO(d);
>
> =A0 =A0 if ( inf->status & EXTRA_AWARE )
> - =A0 =A0 =A0 =A0/* Put on the weighted extraq without updating any score=
s. */
> + =A0 =A0 =A0 =A0/* Put on the weighted extraq without updating any score=
s */
> =A0 =A0 =A0 =A0 extraq_add_sort_update(d, EXTRA_UTIL_Q, 0);
> =A0}
>
> @@ -265,8 +228,6 @@ static inline void __del_from_queue(stru
> =A0{
> =A0 =A0 struct list_head *list =3D LIST(d);
> =A0 =A0 ASSERT(__task_on_queue(d));
> - =A0 =A0PRINT(3,"Removing domain %i.%i (bop=3D %"PRIu64") from runq/wait=
q\n",
> - =A0 =A0 =A0 =A0 =A0d->domain->domain_id, d->vcpu_id, PERIOD_BEGIN(EDOM_=
INFO(d)));
> =A0 =A0 list_del(list);
> =A0 =A0 list->next =3D NULL;
> =A0 =A0 ASSERT(!__task_on_queue(d));
> @@ -279,13 +240,12 @@ static inline void list_insert_sort(
> =A0{
> =A0 =A0 struct list_head =A0 =A0 *cur;
>
> - =A0 =A0/* Iterate through all elements to find our "hole". */
> + =A0 =A0/* Iterate through all elements to find our "hole" */
> =A0 =A0 list_for_each( cur, list )
> =A0 =A0 =A0 =A0 if ( comp(element, cur) < 0 )
> =A0 =A0 =A0 =A0 =A0 =A0 break;
>
> - =A0 =A0/* cur now contains the element, before which we'll enqueue. */
> - =A0 =A0PRINT(3,"\tlist_add to %p\n",cur->prev);
> + =A0 =A0/* cur now contains the element, before which we'll enqueue */
> =A0 =A0 list_add(element, cur->prev);
> =A0}
>
> @@ -303,30 +263,26 @@ static int name##_comp(struct list_head*
> =A0 =A0 =A0 =A0 return 1; =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 \
> =A0}
>
> -/* adds a domain to the queue of processes which wait for the beginning =
of the
> - =A0 next period; this list is therefore sortet by this time, which is s=
imply
> - =A0 absol. deadline - period
> +/* Adds a domain to the queue of processes which wait for the beginning =
of the
> + * next period; this list is therefore sortet by this time, which is sim=
ply
> + * absol. deadline - period.
> =A0*/
> =A0DOMAIN_COMPARER(waitq, list, PERIOD_BEGIN(d1), PERIOD_BEGIN(d2));
> =A0static inline void __add_to_waitqueue_sort(struct vcpu *v)
> =A0{
> =A0 =A0 ASSERT(!__task_on_queue(v));
> - =A0 =A0PRINT(3,"Adding domain %i.%i (bop=3D %"PRIu64") to waitq\n",
> - =A0 =A0 =A0 =A0 =A0v->domain->domain_id, v->vcpu_id, PERIOD_BEGIN(EDOM_=
INFO(v)));
> =A0 =A0 list_insert_sort(WAITQ(v->processor), LIST(v), waitq_comp);
> =A0 =A0 ASSERT(__task_on_queue(v));
> =A0}
>
> -/* adds a domain to the queue of processes which have started their curr=
ent
> - =A0 period and are runnable (i.e. not blocked, dieing,...). The first e=
lement
> - =A0 on this list is running on the processor, if the list is empty the =
idle
> - =A0 task will run. As we are implementing EDF, this list is sorted by d=
eadlines.
> +/* Adds a domain to the queue of processes which have started their curr=
ent
> + * period and are runnable (i.e. not blocked, dieing,...). The first ele=
ment
> + * on this list is running on the processor, if the list is empty the id=
le
> + * task will run. As we are implementing EDF, this list is sorted by dea=
dlines.
> =A0*/
> =A0DOMAIN_COMPARER(runq, list, d1->deadl_abs, d2->deadl_abs);
> =A0static inline void __add_to_runqueue_sort(struct vcpu *v)
> =A0{
> - =A0 =A0PRINT(3,"Adding domain %i.%i (deadl=3D %"PRIu64") to runq\n",
> - =A0 =A0 =A0 =A0 =A0v->domain->domain_id, v->vcpu_id, EDOM_INFO(v)->dead=
l_abs);
> =A0 =A0 list_insert_sort(RUNQ(v->processor), LIST(v), runq_comp);
> =A0}
>
> @@ -445,22 +401,21 @@ static int sedf_pick_cpu(const struct sc
> =A0 =A0 return cpumask_first(&online_affinity);
> =A0}
>
> -/*
> - * Handles the rescheduling & bookkeeping of domains running in their
> +
> +/* Handles the rescheduling & bookkeeping of domains running in their
> =A0* guaranteed timeslice.
> =A0*/
> =A0static void desched_edf_dom(s_time_t now, struct vcpu* d)
> =A0{
> =A0 =A0 struct sedf_vcpu_info* inf =3D EDOM_INFO(d);
>
> - =A0 =A0/* Current domain is running in real time mode. */
> + =A0 =A0/* Current domain is running in real time mode */
> =A0 =A0 ASSERT(__task_on_queue(d));
>
> - =A0 =A0/* Update the domain's cputime. */
> + =A0 =A0/* Update the domain's cputime */
> =A0 =A0 inf->cputime +=3D now - inf->sched_start_abs;
>
> - =A0 =A0/*
> - =A0 =A0 * Scheduling decisions which don't remove the running domain fr=
om the
> + =A0 =A0/* Scheduling decisions which don't remove the running domain fr=
om the
> =A0 =A0 =A0* runq.
> =A0 =A0 =A0*/
> =A0 =A0 if ( (inf->cputime < inf->slice) && sedf_runnable(d) )
> @@ -468,8 +423,7 @@ static void desched_edf_dom(s_time_t now
>
> =A0 =A0 __del_from_queue(d);
>
> - =A0 =A0/*
> - =A0 =A0 * Manage bookkeeping (i.e. calculate next deadline, memorise
> + =A0 =A0/* Manage bookkeeping (i.e. calculate next deadline, memorise
> =A0 =A0 =A0* overrun-time of slice) of finished domains.
> =A0 =A0 =A0*/
> =A0 =A0 if ( inf->cputime >=3D inf->slice )
> @@ -478,30 +432,30 @@ static void desched_edf_dom(s_time_t now
>
> =A0 =A0 =A0 =A0 if ( inf->period < inf->period_orig )
> =A0 =A0 =A0 =A0 {
> - =A0 =A0 =A0 =A0 =A0 =A0/* This domain runs in latency scaling or burst =
mode. */
> + =A0 =A0 =A0 =A0 =A0 =A0/* This domain runs in latency scaling or burst =
mode */
> =A0 =A0 =A0 =A0 =A0 =A0 inf->period *=3D 2;
> =A0 =A0 =A0 =A0 =A0 =A0 inf->slice =A0*=3D 2;
> =A0 =A0 =A0 =A0 =A0 =A0 if ( (inf->period > inf->period_orig) ||
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(inf->slice > inf->slice_orig) )
> =A0 =A0 =A0 =A0 =A0 =A0 {
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/* Reset slice and period. */
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/* Reset slice and period */
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 inf->period =3D inf->period_orig;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 inf->slice =3D inf->slice_orig;
> =A0 =A0 =A0 =A0 =A0 =A0 }
> =A0 =A0 =A0 =A0 }
>
> - =A0 =A0 =A0 =A0/* Set next deadline. */
> + =A0 =A0 =A0 =A0/* Set next deadline */
> =A0 =A0 =A0 =A0 inf->deadl_abs +=3D inf->period;
> =A0 =A0 }
>
> - =A0 =A0/* Add a runnable domain to the waitqueue. */
> + =A0 =A0/* Add a runnable domain to the waitqueue */
> =A0 =A0 if ( sedf_runnable(d) )
> =A0 =A0 {
> =A0 =A0 =A0 =A0 __add_to_waitqueue_sort(d);
> =A0 =A0 }
> =A0 =A0 else
> =A0 =A0 {
> - =A0 =A0 =A0 =A0/* We have a blocked realtime task -> remove it from exq=
s too. */
> + =A0 =A0 =A0 =A0/* We have a blocked realtime task -> remove it from exq=
s too */
> =A0 =A0 =A0 =A0 if ( extraq_on(d, EXTRA_PEN_Q) )
> =A0 =A0 =A0 =A0 =A0 =A0 extraq_del(d, EXTRA_PEN_Q);
> =A0 =A0 =A0 =A0 if ( extraq_on(d, EXTRA_UTIL_Q) )
> @@ -521,73 +475,59 @@ static void update_queues(
> =A0 =A0 struct list_head =A0 =A0 *cur, *tmp;
> =A0 =A0 struct sedf_vcpu_info *curinf;
>
> - =A0 =A0PRINT(3,"Updating waitq..\n");
> -
> - =A0 =A0/*
> - =A0 =A0 * Check for the first elements of the waitqueue, whether their
> + =A0 =A0/* Check for the first elements of the waitqueue, whether their
> =A0 =A0 =A0* next period has already started.
> =A0 =A0 =A0*/
> =A0 =A0 list_for_each_safe ( cur, tmp, waitq )
> =A0 =A0 {
> =A0 =A0 =A0 =A0 curinf =3D list_entry(cur, struct sedf_vcpu_info, list);
> - =A0 =A0 =A0 =A0PRINT(4,"\tLooking @ dom %i.%i\n",
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0curinf->vcpu->domain->domain_id, curinf->vcp=
u->vcpu_id);
> =A0 =A0 =A0 =A0 if ( PERIOD_BEGIN(curinf) > now )
> =A0 =A0 =A0 =A0 =A0 =A0 break;
> =A0 =A0 =A0 =A0 __del_from_queue(curinf->vcpu);
> =A0 =A0 =A0 =A0 __add_to_runqueue_sort(curinf->vcpu);
> =A0 =A0 }
>
> - =A0 =A0PRINT(3,"Updating runq..\n");
> -
> - =A0 =A0/* Process the runq, find domains that are on the runq that shou=
ldn't. */
> + =A0 =A0/* Process the runq, find domains that are on the runq that shou=
ldn't */
> =A0 =A0 list_for_each_safe ( cur, tmp, runq )
> =A0 =A0 {
> =A0 =A0 =A0 =A0 curinf =3D list_entry(cur,struct sedf_vcpu_info,list);
> - =A0 =A0 =A0 =A0PRINT(4,"\tLooking @ dom %i.%i\n",
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0curinf->vcpu->domain->domain_id, curinf->vcp=
u->vcpu_id);
>
> =A0 =A0 =A0 =A0 if ( unlikely(curinf->slice =3D=3D 0) )
> =A0 =A0 =A0 =A0 {
> - =A0 =A0 =A0 =A0 =A0 =A0/* Ignore domains with empty slice. */
> - =A0 =A0 =A0 =A0 =A0 =A0PRINT(4,"\tUpdating zero-slice domain %i.%i\n",
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0curinf->vcpu->domain->domain_id,
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0curinf->vcpu->vcpu_id);
> + =A0 =A0 =A0 =A0 =A0 =A0/* Ignore domains with empty slice */
> =A0 =A0 =A0 =A0 =A0 =A0 __del_from_queue(curinf->vcpu);
>
> - =A0 =A0 =A0 =A0 =A0 =A0/* Move them to their next period. */
> + =A0 =A0 =A0 =A0 =A0 =A0/* Move them to their next period */
> =A0 =A0 =A0 =A0 =A0 =A0 curinf->deadl_abs +=3D curinf->period;
>
> - =A0 =A0 =A0 =A0 =A0 =A0/* Ensure that the start of the next period is i=
n the future. */
> + =A0 =A0 =A0 =A0 =A0 =A0/* Ensure that the start of the next period is i=
n the future */
> =A0 =A0 =A0 =A0 =A0 =A0 if ( unlikely(PERIOD_BEGIN(curinf) < now) )
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 curinf->deadl_abs +=3D
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (DIV_UP(now - PERIOD_BEGIN(curinf=
),
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 curinf->period)) =
* curinf->period;
>
> - =A0 =A0 =A0 =A0 =A0 =A0/* Put them back into the queue. */
> + =A0 =A0 =A0 =A0 =A0 =A0/* Put them back into the queue */
> =A0 =A0 =A0 =A0 =A0 =A0 __add_to_waitqueue_sort(curinf->vcpu);
> =A0 =A0 =A0 =A0 }
> =A0 =A0 =A0 =A0 else if ( unlikely((curinf->deadl_abs < now) ||
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(curinf->cputime >=
 curinf->slice)) )
> =A0 =A0 =A0 =A0 {
> - =A0 =A0 =A0 =A0 =A0 =A0/*
> - =A0 =A0 =A0 =A0 =A0 =A0 * We missed the deadline or the slice was alrea=
dy finished.
> + =A0 =A0 =A0 =A0 =A0 =A0/* We missed the deadline or the slice was alrea=
dy finished.
> =A0 =A0 =A0 =A0 =A0 =A0 =A0* Might hapen because of dom_adj.
> =A0 =A0 =A0 =A0 =A0 =A0 =A0*/
> - =A0 =A0 =A0 =A0 =A0 =A0PRINT(4,"\tDomain %i.%i exceeded it's deadline/"
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0"slice (%"PRIu64" / %"PRIu64") now: =
%"PRIu64
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0" cputime: %"PRIu64"\n",
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0curinf->vcpu->domain->domain_id,
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0curinf->vcpu->vcpu_id,
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0curinf->deadl_abs, curinf->slice, no=
w,
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0curinf->cputime);
> + =A0 =A0 =A0 =A0 =A0 =A0printk("\tDomain %i.%i exceeded it's deadline/"
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 "slice (%"PRIu64" / %"PRIu64") now:=
 %"PRIu64
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 " cputime: %"PRIu64"\n",
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 curinf->vcpu->domain->domain_id,
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 curinf->vcpu->vcpu_id,
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 curinf->deadl_abs, curinf->slice, n=
ow,
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 curinf->cputime);
> =A0 =A0 =A0 =A0 =A0 =A0 __del_from_queue(curinf->vcpu);
>
> - =A0 =A0 =A0 =A0 =A0 =A0/* Common case: we miss one period. */
> + =A0 =A0 =A0 =A0 =A0 =A0/* Common case: we miss one period */
> =A0 =A0 =A0 =A0 =A0 =A0 curinf->deadl_abs +=3D curinf->period;
>
> - =A0 =A0 =A0 =A0 =A0 =A0/*
> - =A0 =A0 =A0 =A0 =A0 =A0 * If we are still behind: modulo arithmetic, fo=
rce deadline
> + =A0 =A0 =A0 =A0 =A0 =A0/* If we are still behind: modulo arithmetic, fo=
rce deadline
> =A0 =A0 =A0 =A0 =A0 =A0 =A0* to be in future and aligned to period border=
s.
> =A0 =A0 =A0 =A0 =A0 =A0 =A0*/
> =A0 =A0 =A0 =A0 =A0 =A0 if ( unlikely(curinf->deadl_abs < now) )
> @@ -596,7 +536,7 @@ static void update_queues(
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0curinf->period) * =
curinf->period;
> =A0 =A0 =A0 =A0 =A0 =A0 ASSERT(curinf->deadl_abs >=3D now);
>
> - =A0 =A0 =A0 =A0 =A0 =A0/* Give a fresh slice. */
> + =A0 =A0 =A0 =A0 =A0 =A0/* Give a fresh slice */
> =A0 =A0 =A0 =A0 =A0 =A0 curinf->cputime =3D 0;
> =A0 =A0 =A0 =A0 =A0 =A0 if ( PERIOD_BEGIN(curinf) > now )
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 __add_to_waitqueue_sort(curinf->vcpu);
> @@ -606,17 +546,16 @@ static void update_queues(
> =A0 =A0 =A0 =A0 else
> =A0 =A0 =A0 =A0 =A0 =A0 break;
> =A0 =A0 }
> -
> - =A0 =A0PRINT(3,"done updating the queues\n");
> =A0}
>
>
> =A0/* removes a domain from the head of the according extraQ and
> - =A0 requeues it at a specified position:
> - =A0 =A0 round-robin extratime: end of extraQ
> - =A0 =A0 weighted ext.: insert in sorted list by score
> - =A0 if the domain is blocked / has regained its short-block-loss
> - =A0 time it is not put on any queue */
> + * requeues it at a specified position:
> + * =A0 round-robin extratime: end of extraQ
> + * =A0 weighted ext.: insert in sorted list by score
> + * if the domain is blocked / has regained its short-block-loss
> + * time it is not put on any queue.
> + */
> =A0static void desched_extra_dom(s_time_t now, struct vcpu *d)
> =A0{
> =A0 =A0 struct sedf_vcpu_info *inf =3D EDOM_INFO(d);
> @@ -625,29 +564,25 @@ static void desched_extra_dom(s_time_t n
>
> =A0 =A0 ASSERT(extraq_on(d, i));
>
> - =A0 =A0/* Unset all running flags. */
> + =A0 =A0/* Unset all running flags */
> =A0 =A0 inf->status =A0&=3D ~(EXTRA_RUN_PEN | EXTRA_RUN_UTIL);
> - =A0 =A0/* Fresh slice for the next run. */
> + =A0 =A0/* Fresh slice for the next run */
> =A0 =A0 inf->cputime =3D 0;
> - =A0 =A0/* Accumulate total extratime. */
> + =A0 =A0/* Accumulate total extratime */
> =A0 =A0 inf->extra_time_tot +=3D now - inf->sched_start_abs;
> =A0 =A0 /* Remove extradomain from head of the queue. */
> =A0 =A0 extraq_del(d, i);
>
> - =A0 =A0/* Update the score. */
> + =A0 =A0/* Update the score */
> =A0 =A0 oldscore =3D inf->score[i];
> =A0 =A0 if ( i =3D=3D EXTRA_PEN_Q )
> =A0 =A0 {
> - =A0 =A0 =A0 =A0/*domain was running in L0 extraq*/
> - =A0 =A0 =A0 =A0/*reduce block lost, probably more sophistication here!*/
> + =A0 =A0 =A0 =A0/* Domain was running in L0 extraq */
> + =A0 =A0 =A0 =A0/* reduce block lost, probably more sophistication here!=
*/
> =A0 =A0 =A0 =A0 /*inf->short_block_lost_tot -=3D EXTRA_QUANTUM;*/
> =A0 =A0 =A0 =A0 inf->short_block_lost_tot -=3D now - inf->sched_start_abs;
> - =A0 =A0 =A0 =A0PRINT(3,"Domain %i.%i: Short_block_loss: %"PRIi64"\n",
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0inf->vcpu->domain->domain_id, inf->vcpu->vcp=
u_id,
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0inf->short_block_lost_tot);
> =A0#if 0
> - =A0 =A0 =A0 =A0/*
> - =A0 =A0 =A0 =A0 * KAF: If we don't exit short-blocking state at this po=
int
> + =A0 =A0 =A0 =A0/* KAF: If we don't exit short-blocking state at this po=
int
> =A0 =A0 =A0 =A0 =A0* domain0 can steal all CPU for up to 10 seconds before
> =A0 =A0 =A0 =A0 =A0* scheduling settles down (when competing against anot=
her
> =A0 =A0 =A0 =A0 =A0* CPU-bound domain). Doing this seems to make things b=
ehave
> @@ -656,51 +591,56 @@ static void desched_extra_dom(s_time_t n
> =A0 =A0 =A0 =A0 if ( inf->short_block_lost_tot <=3D 0 )
> =A0#endif
> =A0 =A0 =A0 =A0 {
> - =A0 =A0 =A0 =A0 =A0 =A0PRINT(4,"Domain %i.%i compensated short block lo=
ss!\n",
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0inf->vcpu->domain->domain_id, inf->v=
cpu->vcpu_id);
> - =A0 =A0 =A0 =A0 =A0 =A0/*we have (over-)compensated our block penalty*/
> + =A0 =A0 =A0 =A0 =A0 =A0/* We have (over-)compensated our block penalty =
*/
> =A0 =A0 =A0 =A0 =A0 =A0 inf->short_block_lost_tot =3D 0;
> - =A0 =A0 =A0 =A0 =A0 =A0/*we don't want a place on the penalty queue any=
more!*/
> + =A0 =A0 =A0 =A0 =A0 =A0/* We don't want a place on the penalty queue an=
ymore! */
> =A0 =A0 =A0 =A0 =A0 =A0 inf->status &=3D ~EXTRA_WANT_PEN_Q;
> =A0 =A0 =A0 =A0 =A0 =A0 goto check_extra_queues;
> =A0 =A0 =A0 =A0 }
>
> - =A0 =A0 =A0 =A0/*we have to go again for another try in the block-extra=
q,
> - =A0 =A0 =A0 =A0 =A0the score is not used incremantally here, as this is
> - =A0 =A0 =A0 =A0 =A0already done by recalculating the block_lost*/
> + =A0 =A0 =A0 =A0/* We have to go again for another try in the block-extr=
aq,
> + =A0 =A0 =A0 =A0 * the score is not used incremantally here, as this is
> + =A0 =A0 =A0 =A0 * already done by recalculating the block_lost
> + =A0 =A0 =A0 =A0 */
> =A0 =A0 =A0 =A0 inf->score[EXTRA_PEN_Q] =3D (inf->period << 10) /
> =A0 =A0 =A0 =A0 =A0 =A0 inf->short_block_lost_tot;
> =A0 =A0 =A0 =A0 oldscore =3D 0;
> =A0 =A0 }
> =A0 =A0 else
> =A0 =A0 {
> - =A0 =A0 =A0 =A0/*domain was running in L1 extraq =3D> score is inverse =
of
> - =A0 =A0 =A0 =A0 =A0utilization and is used somewhat incremental!*/
> + =A0 =A0 =A0 =A0/* Domain was running in L1 extraq =3D> score is inverse=
 of
> + =A0 =A0 =A0 =A0 * utilization and is used somewhat incremental!
> + =A0 =A0 =A0 =A0 */
> =A0 =A0 =A0 =A0 if ( !inf->extraweight )
> - =A0 =A0 =A0 =A0 =A0 =A0/*NB: use fixed point arithmetic with 10 bits*/
> + =A0 =A0 =A0 =A0{
> + =A0 =A0 =A0 =A0 =A0 =A0/* NB: use fixed point arithmetic with 10 bits */
> =A0 =A0 =A0 =A0 =A0 =A0 inf->score[EXTRA_UTIL_Q] =3D (inf->period << 10) /
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 inf->slice;
> + =A0 =A0 =A0 =A0}
> =A0 =A0 =A0 =A0 else
> - =A0 =A0 =A0 =A0 =A0 =A0/*conversion between realtime utilisation and ex=
trawieght:
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0full (ie 100%) utilization is equivalent to =
128 extraweight*/
> + =A0 =A0 =A0 =A0{
> + =A0 =A0 =A0 =A0 =A0 =A0/* Conversion between realtime utilisation and e=
xtrawieght:
> + =A0 =A0 =A0 =A0 =A0 =A0 * full (ie 100%) utilization is equivalent to 1=
28 extraweight
> + =A0 =A0 =A0 =A0 =A0 =A0 */
> =A0 =A0 =A0 =A0 =A0 =A0 inf->score[EXTRA_UTIL_Q] =3D (1<<17) / inf->extra=
weight;
> + =A0 =A0 =A0 =A0}
> =A0 =A0 }
>
> =A0check_extra_queues:
> - =A0 =A0/* Adding a runnable domain to the right queue and removing bloc=
ked ones*/
> + =A0 =A0/* Adding a runnable domain to the right queue and removing bloc=
ked ones */
> =A0 =A0 if ( sedf_runnable(d) )
> =A0 =A0 {
> - =A0 =A0 =A0 =A0/*add according to score: weighted round robin*/
> + =A0 =A0 =A0 =A0/* Add according to score: weighted round robin */
> =A0 =A0 =A0 =A0 if (((inf->status & EXTRA_AWARE) && (i =3D=3D EXTRA_UTIL_=
Q)) ||
> =A0 =A0 =A0 =A0 =A0 =A0 ((inf->status & EXTRA_WANT_PEN_Q) && (i =3D=3D EX=
TRA_PEN_Q)))
> =A0 =A0 =A0 =A0 =A0 =A0 extraq_add_sort_update(d, i, oldscore);
> =A0 =A0 }
> =A0 =A0 else
> =A0 =A0 {
> - =A0 =A0 =A0 =A0/*remove this blocked domain from the waitq!*/
> + =A0 =A0 =A0 =A0/* Remove this blocked domain from the waitq! */
> =A0 =A0 =A0 =A0 __del_from_queue(d);
> - =A0 =A0 =A0 =A0/*make sure that we remove a blocked domain from the oth=
er
> - =A0 =A0 =A0 =A0 =A0extraq too*/
> + =A0 =A0 =A0 =A0/* Make sure that we remove a blocked domain from the ot=
her
> + =A0 =A0 =A0 =A0 * extraq too. */
> =A0 =A0 =A0 =A0 if ( i =3D=3D EXTRA_PEN_Q )
> =A0 =A0 =A0 =A0 {
> =A0 =A0 =A0 =A0 =A0 =A0 if ( extraq_on(d, EXTRA_UTIL_Q) )
> @@ -732,8 +672,9 @@ static struct task_slice sedf_do_extra_s
>
> =A0 =A0 if ( !list_empty(extraq[EXTRA_PEN_Q]) )
> =A0 =A0 {
> - =A0 =A0 =A0 =A0/*we still have elements on the level 0 extraq
> - =A0 =A0 =A0 =A0 =A0=3D> let those run first!*/
> + =A0 =A0 =A0 =A0/* We still have elements on the level 0 extraq
> + =A0 =A0 =A0 =A0 * =3D> let those run first!
> + =A0 =A0 =A0 =A0 */
> =A0 =A0 =A0 =A0 runinf =A0 =3D list_entry(extraq[EXTRA_PEN_Q]->next,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 struct sedf_v=
cpu_info, extralist[EXTRA_PEN_Q]);
> =A0 =A0 =A0 =A0 runinf->status |=3D EXTRA_RUN_PEN;
> @@ -747,7 +688,7 @@ static struct task_slice sedf_do_extra_s
> =A0 =A0 {
> =A0 =A0 =A0 =A0 if ( !list_empty(extraq[EXTRA_UTIL_Q]) )
> =A0 =A0 =A0 =A0 {
> - =A0 =A0 =A0 =A0 =A0 =A0/*use elements from the normal extraqueue*/
> + =A0 =A0 =A0 =A0 =A0 =A0/* Use elements from the normal extraqueue */
> =A0 =A0 =A0 =A0 =A0 =A0 runinf =A0 =3D list_entry(extraq[EXTRA_UTIL_Q]->n=
ext,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 struc=
t sedf_vcpu_info,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 extra=
list[EXTRA_UTIL_Q]);
> @@ -773,10 +714,11 @@ static struct task_slice sedf_do_extra_s
>
>
> =A0/* Main scheduling function
> - =A0 Reasons for calling this function are:
> - =A0 -timeslice for the current period used up
> - =A0 -domain on waitqueue has started it's period
> - =A0 -and various others ;) in general: determine which domain to run ne=
xt*/
> + * Reasons for calling this function are:
> + * -timeslice for the current period used up
> + * -domain on waitqueue has started it's period
> + * -and various others ;) in general: determine which domain to run next
> + */
> =A0static struct task_slice sedf_do_schedule(
> =A0 =A0 const struct scheduler *ops, s_time_t now, bool_t tasklet_work_sc=
heduled)
> =A0{
> @@ -789,13 +731,14 @@ static struct task_slice sedf_do_schedul
> =A0 =A0 struct sedf_vcpu_info *runinf, *waitinf;
> =A0 =A0 struct task_slice =A0 =A0 =A0ret;
>
> - =A0 =A0/*idle tasks don't need any of the following stuf*/
> + =A0 =A0/* Idle tasks don't need any of the following stuf */
> =A0 =A0 if ( is_idle_vcpu(current) )
> =A0 =A0 =A0 =A0 goto check_waitq;
>
> - =A0 =A0/* create local state of the status of the domain, in order to a=
void
> - =A0 =A0 =A0 inconsistent state during scheduling decisions, because dat=
a for
> - =A0 =A0 =A0 vcpu_runnable is not protected by the scheduling lock!*/
> + =A0 =A0/* Create local state of the status of the domain, in order to a=
void
> + =A0 =A0 * inconsistent state during scheduling decisions, because data =
for
> + =A0 =A0 * vcpu_runnable is not protected by the scheduling lock!
> + =A0 =A0 */
> =A0 =A0 if ( !vcpu_runnable(current) )
> =A0 =A0 =A0 =A0 inf->status |=3D SEDF_ASLEEP;
>
> @@ -804,7 +747,7 @@ static struct task_slice sedf_do_schedul
>
> =A0 =A0 if ( unlikely(extra_runs(inf)) )
> =A0 =A0 {
> - =A0 =A0 =A0 =A0/*special treatment of domains running in extra time*/
> + =A0 =A0 =A0 =A0/* Special treatment of domains running in extra time */
> =A0 =A0 =A0 =A0 desched_extra_dom(now, current);
> =A0 =A0 }
> =A0 =A0 else
> @@ -814,10 +757,11 @@ static struct task_slice sedf_do_schedul
> =A0check_waitq:
> =A0 =A0 update_queues(now, runq, waitq);
>
> - =A0 =A0/*now simply pick the first domain from the runqueue, which has =
the
> - =A0 =A0 =A0earliest deadline, because the list is sorted*/
> -
> - =A0 =A0/* Tasklet work (which runs in idle VCPU context) overrides all =
else. */
> + =A0 =A0/* Now simply pick the first domain from the runqueue, which has=
 the
> + =A0 =A0 * earliest deadline, because the list is sorted
> + =A0 =A0 *
> + =A0 =A0 * Tasklet work (which runs in idle VCPU context) overrides all =
else.
> + =A0 =A0 */
> =A0 =A0 if ( tasklet_work_scheduled ||
> =A0 =A0 =A0 =A0 =A0(list_empty(runq) && list_empty(waitq)) ||
> =A0 =A0 =A0 =A0 =A0unlikely(!cpumask_test_cpu(cpu, SEDF_CPUONLINE(per_cpu=
(cpupool, cpu)))) )
> @@ -833,9 +777,10 @@ static struct task_slice sedf_do_schedul
> =A0 =A0 =A0 =A0 {
> =A0 =A0 =A0 =A0 =A0 =A0 waitinf =A0=3D list_entry(waitq->next,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 struc=
t sedf_vcpu_info,list);
> - =A0 =A0 =A0 =A0 =A0 =A0/*rerun scheduler, when scheduled domain reaches=
 it's
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0end of slice or the first domain from the wa=
itqueue
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0gets ready*/
> + =A0 =A0 =A0 =A0 =A0 =A0/* Rerun scheduler, when scheduled domain reache=
s it's
> + =A0 =A0 =A0 =A0 =A0 =A0 * end of slice or the first domain from the wai=
tqueue
> + =A0 =A0 =A0 =A0 =A0 =A0 * gets ready.
> + =A0 =A0 =A0 =A0 =A0 =A0 */
> =A0 =A0 =A0 =A0 =A0 =A0 ret.time =3D MIN(now + runinf->slice - runinf->cp=
utime,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0PERIOD_BEGIN(waiti=
nf)) - now;
> =A0 =A0 =A0 =A0 }
> @@ -847,14 +792,15 @@ static struct task_slice sedf_do_schedul
> =A0 =A0 else
> =A0 =A0 {
> =A0 =A0 =A0 =A0 waitinf =A0=3D list_entry(waitq->next,struct sedf_vcpu_in=
fo, list);
> - =A0 =A0 =A0 =A0/*we could not find any suitable domain
> - =A0 =A0 =A0 =A0 =A0=3D> look for domains that are aware of extratime*/
> + =A0 =A0 =A0 =A0/* We could not find any suitable domain
> + =A0 =A0 =A0 =A0 * =3D> look for domains that are aware of extratime*/
> =A0 =A0 =A0 =A0 ret =3D sedf_do_extra_schedule(now, PERIOD_BEGIN(waitinf),
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0extraq, cpu);
> =A0 =A0 }
>
> - =A0 =A0/*TODO: Do something USEFUL when this happens and find out, why =
it
> - =A0 =A0 =A0still can happen!!!*/
> + =A0 =A0/* TODO: Do something USEFUL when this happens and find out, why=
 it
> + =A0 =A0 * still can happen!!!
> + =A0 =A0 */
> =A0 =A0 if ( ret.time < 0)
> =A0 =A0 {
> =A0 =A0 =A0 =A0 printk("Ouch! We are seriously BEHIND schedule! %"PRIi64"=
\n",
> @@ -874,9 +820,6 @@ static struct task_slice sedf_do_schedul
>
> =A0static void sedf_sleep(const struct scheduler *ops, struct vcpu *d)
> =A0{
> - =A0 =A0PRINT(2,"sedf_sleep was called, domain-id %i.%i\n",
> - =A0 =A0 =A0 =A0 =A0d->domain->domain_id, d->vcpu_id);
> -
> =A0 =A0 if ( is_idle_vcpu(d) )
> =A0 =A0 =A0 =A0 return;
>
> @@ -972,27 +915,29 @@ static void sedf_sleep(const struct sche
> =A0static void unblock_short_extra_support(
> =A0 =A0 struct sedf_vcpu_info* inf, s_time_t now)
> =A0{
> - =A0 =A0/*this unblocking scheme tries to support the domain, by assigni=
ng it
> - =A0 =A0a priority in extratime distribution according to the loss of ti=
me
> - =A0 =A0in this slice due to blocking*/
> + =A0 =A0/* This unblocking scheme tries to support the domain, by assign=
ing it
> + =A0 =A0 * a priority in extratime distribution according to the loss of=
 time
> + =A0 =A0 * in this slice due to blocking
> + =A0 =A0 */
> =A0 =A0 s_time_t pen;
>
> - =A0 =A0/*no more realtime execution in this period!*/
> + =A0 =A0/* No more realtime execution in this period! */
> =A0 =A0 inf->deadl_abs +=3D inf->period;
> =A0 =A0 if ( likely(inf->block_abs) )
> =A0 =A0 {
> - =A0 =A0 =A0 =A0//treat blocked time as consumed by the domain*/
> + =A0 =A0 =A0 =A0/* Treat blocked time as consumed by the domain */
> =A0 =A0 =A0 =A0 /*inf->cputime +=3D now - inf->block_abs;*/
> - =A0 =A0 =A0 =A0/*penalty is time the domain would have
> - =A0 =A0 =A0 =A0 =A0had if it continued to run */
> + =A0 =A0 =A0 =A0/* Penalty is time the domain would have
> + =A0 =A0 =A0 =A0 * had if it continued to run.
> + =A0 =A0 =A0 =A0 */
> =A0 =A0 =A0 =A0 pen =3D (inf->slice - inf->cputime);
> =A0 =A0 =A0 =A0 if ( pen < 0 )
> =A0 =A0 =A0 =A0 =A0 =A0 pen =3D 0;
> - =A0 =A0 =A0 =A0/*accumulate all penalties over the periods*/
> + =A0 =A0 =A0 =A0/* Accumulate all penalties over the periods */
> =A0 =A0 =A0 =A0 /*inf->short_block_lost_tot +=3D pen;*/
> - =A0 =A0 =A0 =A0/*set penalty to the current value*/
> + =A0 =A0 =A0 =A0/* Set penalty to the current value */
> =A0 =A0 =A0 =A0 inf->short_block_lost_tot =3D pen;
> - =A0 =A0 =A0 =A0/*not sure which one is better.. but seems to work well.=
..*/
> + =A0 =A0 =A0 =A0/* Not sure which one is better.. but seems to work well=
... */
>
> =A0 =A0 =A0 =A0 if ( inf->short_block_lost_tot )
> =A0 =A0 =A0 =A0 {
> @@ -1002,28 +947,30 @@ static void unblock_short_extra_support(
> =A0 =A0 =A0 =A0 =A0 =A0 inf->pen_extra_blocks++;
> =A0#endif
> =A0 =A0 =A0 =A0 =A0 =A0 if ( extraq_on(inf->vcpu, EXTRA_PEN_Q) )
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/*remove domain for possible resorting!*/
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/* Remove domain for possible resorting!=
 */
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 extraq_del(inf->vcpu, EXTRA_PEN_Q);
> =A0 =A0 =A0 =A0 =A0 =A0 else
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/*remember that we want to be on the pen=
alty q
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0so that we can continue when we (un-=
)block
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0in penalty-extratime*/
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/* Remember that we want to be on the pe=
nalty q
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 * so that we can continue when we (un-)=
block
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 * in penalty-extratime
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 */
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 inf->status |=3D EXTRA_WANT_PEN_Q;
>
> - =A0 =A0 =A0 =A0 =A0 =A0/*(re-)add domain to the penalty extraq*/
> + =A0 =A0 =A0 =A0 =A0 =A0/* (re-)add domain to the penalty extraq */
> =A0 =A0 =A0 =A0 =A0 =A0 extraq_add_sort_update(inf->vcpu, EXTRA_PEN_Q, 0);
> =A0 =A0 =A0 =A0 }
> =A0 =A0 }
>
> - =A0 =A0/*give it a fresh slice in the next period!*/
> + =A0 =A0/* Give it a fresh slice in the next period! */
> =A0 =A0 inf->cputime =3D 0;
> =A0}
>
>
> =A0static void unblock_long_cons_b(struct sedf_vcpu_info* inf,s_time_t no=
w)
> =A0{
> - =A0 =A0/*Conservative 2b*/
> - =A0 =A0/*Treat the unblocking time as a start of a new period */
> + =A0 =A0/* Conservative 2b */
> +
> + =A0 =A0/* Treat the unblocking time as a start of a new period */
> =A0 =A0 inf->deadl_abs =3D now + inf->period;
> =A0 =A0 inf->cputime =3D 0;
> =A0}
> @@ -1046,15 +993,16 @@ static inline int get_run_type(struct vc
> =A0}
>
>
> -/*Compares two domains in the relation of whether the one is allowed to
> - =A0interrupt the others execution.
> - =A0It returns true (!=3D0) if a switch to the other domain is good.
> - =A0Current Priority scheme is as follows:
> - =A0 EDF > L0 (penalty based) extra-time >
> - =A0 L1 (utilization) extra-time > idle-domain
> - =A0In the same class priorities are assigned as following:
> - =A0 EDF: early deadline > late deadline
> - =A0 L0 extra-time: lower score > higher score*/
> +/* Compares two domains in the relation of whether the one is allowed to
> + * interrupt the others execution.
> + * It returns true (!=3D0) if a switch to the other domain is good.
> + * Current Priority scheme is as follows:
> + * =A0EDF > L0 (penalty based) extra-time >
> + * =A0L1 (utilization) extra-time > idle-domain
> + * In the same class priorities are assigned as following:
> + * =A0EDF: early deadline > late deadline
> + * =A0L0 extra-time: lower score > higher score
> + */
> =A0static inline int should_switch(struct vcpu *cur,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 struct vc=
pu *other,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 s_time_t =
now)
> @@ -1063,19 +1011,19 @@ static inline int should_switch(struct v
> =A0 =A0 cur_inf =A0 =3D EDOM_INFO(cur);
> =A0 =A0 other_inf =3D EDOM_INFO(other);
>
> - =A0 =A0/* Check whether we need to make an earlier scheduling decision.=
 */
> + =A0 =A0/* Check whether we need to make an earlier scheduling decision =
*/
> =A0 =A0 if ( PERIOD_BEGIN(other_inf) <
> =A0 =A0 =A0 =A0 =A0CPU_INFO(other->processor)->current_slice_expires )
> =A0 =A0 =A0 =A0 return 1;
>
> - =A0 =A0/* No timing-based switches need to be taken into account here. =
*/
> + =A0 =A0/* No timing-based switches need to be taken into account here */
> =A0 =A0 switch ( get_run_type(cur) )
> =A0 =A0 {
> =A0 =A0 case DOMAIN_EDF:
> - =A0 =A0 =A0 =A0/* Do not interrupt a running EDF domain. */
> + =A0 =A0 =A0 =A0/* Do not interrupt a running EDF domain */
> =A0 =A0 =A0 =A0 return 0;
> =A0 =A0 case DOMAIN_EXTRA_PEN:
> - =A0 =A0 =A0 =A0/* Check whether we also want the L0 ex-q with lower sco=
re. */
> + =A0 =A0 =A0 =A0/* Check whether we also want the L0 ex-q with lower sco=
re */
> =A0 =A0 =A0 =A0 return ((other_inf->status & EXTRA_WANT_PEN_Q) &&
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (other_inf->score[EXTRA_PEN_Q] <
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0cur_inf->score[EXTRA_PEN_Q]));
> @@ -1096,18 +1044,11 @@ static void sedf_wake(const struct sched
> =A0 =A0 s_time_t =A0 =A0 =A0 =A0 =A0 =A0 =A0now =3D NOW();
> =A0 =A0 struct sedf_vcpu_info* inf =3D EDOM_INFO(d);
>
> - =A0 =A0PRINT(3, "sedf_wake was called, domain-id %i.%i\n",d->domain->do=
main_id,
> - =A0 =A0 =A0 =A0 =A0d->vcpu_id);
> -
> =A0 =A0 if ( unlikely(is_idle_vcpu(d)) )
> =A0 =A0 =A0 =A0 return;
>
> =A0 =A0 if ( unlikely(__task_on_queue(d)) )
> - =A0 =A0{
> - =A0 =A0 =A0 =A0PRINT(3,"\tdomain %i.%i is already in some queue\n",
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0d->domain->domain_id, d->vcpu_id);
> =A0 =A0 =A0 =A0 return;
> - =A0 =A0}
>
> =A0 =A0 ASSERT(!sedf_runnable(d));
> =A0 =A0 inf->status &=3D ~SEDF_ASLEEP;
> @@ -1116,28 +1057,24 @@ static void sedf_wake(const struct sched
>
> =A0 =A0 if ( unlikely(inf->deadl_abs =3D=3D 0) )
> =A0 =A0 {
> - =A0 =A0 =A0 =A0/*initial setup of the deadline*/
> + =A0 =A0 =A0 =A0/* Initial setup of the deadline */
> =A0 =A0 =A0 =A0 inf->deadl_abs =3D now + inf->slice;
> =A0 =A0 }
>
> - =A0 =A0PRINT(3, "waking up domain %i.%i (deadl=3D %"PRIu64" period=3D %=
"PRIu64
> - =A0 =A0 =A0 =A0 =A0"now=3D %"PRIu64")\n",
> - =A0 =A0 =A0 =A0 =A0d->domain->domain_id, d->vcpu_id, inf->deadl_abs, in=
f->period, now);
> -
> =A0#ifdef SEDF_STATS
> =A0 =A0 inf->block_tot++;
> =A0#endif
>
> =A0 =A0 if ( unlikely(now < PERIOD_BEGIN(inf)) )
> =A0 =A0 {
> - =A0 =A0 =A0 =A0PRINT(4,"extratime unblock\n");
> - =A0 =A0 =A0 =A0/* unblocking in extra-time! */
> + =A0 =A0 =A0 =A0/* Unblocking in extra-time! */
> =A0 =A0 =A0 =A0 if ( inf->status & EXTRA_WANT_PEN_Q )
> =A0 =A0 =A0 =A0 {
> - =A0 =A0 =A0 =A0 =A0 =A0/*we have a domain that wants compensation
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0for block penalty and did just block in
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0its compensation time. Give it another
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0chance!*/
> + =A0 =A0 =A0 =A0 =A0 =A0/* We have a domain that wants compensation
> + =A0 =A0 =A0 =A0 =A0 =A0 * for block penalty and did just block in
> + =A0 =A0 =A0 =A0 =A0 =A0 * its compensation time. Give it another
> + =A0 =A0 =A0 =A0 =A0 =A0 * chance!
> + =A0 =A0 =A0 =A0 =A0 =A0 */
> =A0 =A0 =A0 =A0 =A0 =A0 extraq_add_sort_update(d, EXTRA_PEN_Q, 0);
> =A0 =A0 =A0 =A0 }
> =A0 =A0 =A0 =A0 extraq_check_add_unblocked(d, 0);
> @@ -1146,8 +1083,7 @@ static void sedf_wake(const struct sched
> =A0 =A0 {
> =A0 =A0 =A0 =A0 if ( now < inf->deadl_abs )
> =A0 =A0 =A0 =A0 {
> - =A0 =A0 =A0 =A0 =A0 =A0PRINT(4,"short unblocking\n");
> - =A0 =A0 =A0 =A0 =A0 =A0/*short blocking*/
> + =A0 =A0 =A0 =A0 =A0 =A0/* Short blocking */
> =A0#ifdef SEDF_STATS
> =A0 =A0 =A0 =A0 =A0 =A0 inf->short_block_tot++;
> =A0#endif
> @@ -1157,8 +1093,7 @@ static void sedf_wake(const struct sched
> =A0 =A0 =A0 =A0 }
> =A0 =A0 =A0 =A0 else
> =A0 =A0 =A0 =A0 {
> - =A0 =A0 =A0 =A0 =A0 =A0PRINT(4,"long unblocking\n");
> - =A0 =A0 =A0 =A0 =A0 =A0/*long unblocking*/
> + =A0 =A0 =A0 =A0 =A0 =A0/* Long unblocking */
> =A0#ifdef SEDF_STATS
> =A0 =A0 =A0 =A0 =A0 =A0 inf->long_block_tot++;
> =A0#endif
> @@ -1168,24 +1103,13 @@ static void sedf_wake(const struct sched
> =A0 =A0 =A0 =A0 }
> =A0 =A0 }
>
> - =A0 =A0PRINT(3, "woke up domain %i.%i (deadl=3D %"PRIu64" period=3D %"P=
RIu64
> - =A0 =A0 =A0 =A0 =A0"now=3D %"PRIu64")\n",
> - =A0 =A0 =A0 =A0 =A0d->domain->domain_id, d->vcpu_id, inf->deadl_abs,
> - =A0 =A0 =A0 =A0 =A0inf->period, now);
> -
> =A0 =A0 if ( PERIOD_BEGIN(inf) > now )
> - =A0 =A0{
> =A0 =A0 =A0 =A0 __add_to_waitqueue_sort(d);
> - =A0 =A0 =A0 =A0PRINT(3,"added to waitq\n");
> - =A0 =A0}
> =A0 =A0 else
> - =A0 =A0{
> =A0 =A0 =A0 =A0 __add_to_runqueue_sort(d);
> - =A0 =A0 =A0 =A0PRINT(3,"added to runq\n");
> - =A0 =A0}
>
> =A0#ifdef SEDF_STATS
> - =A0 =A0/*do some statistics here...*/
> + =A0 =A0/* Do some statistics here... */
> =A0 =A0 if ( inf->block_abs !=3D 0 )
> =A0 =A0 {
> =A0 =A0 =A0 =A0 inf->block_time_tot +=3D now - inf->block_abs;
> @@ -1194,12 +1118,13 @@ static void sedf_wake(const struct sched
> =A0 =A0 }
> =A0#endif
>
> - =A0 =A0/*sanity check: make sure each extra-aware domain IS on the util=
-q!*/
> + =A0 =A0/* Sanity check: make sure each extra-aware domain IS on the uti=
l-q! */
> =A0 =A0 ASSERT(IMPLY(inf->status & EXTRA_AWARE, extraq_on(d, EXTRA_UTIL_Q=
)));
> =A0 =A0 ASSERT(__task_on_queue(d));
> - =A0 =A0/*check whether the awakened task needs to invoke the do_schedule
> - =A0 =A0 =A0routine. Try to avoid unnecessary runs but:
> - =A0 =A0 =A0Save approximation: Always switch to scheduler!*/
> + =A0 =A0/* Check whether the awakened task needs to invoke the do_schedu=
le
> + =A0 =A0 * routine. Try to avoid unnecessary runs but:
> + =A0 =A0 * Save approximation: Always switch to scheduler!
> + =A0 =A0 */
> =A0 =A0 ASSERT(d->processor >=3D 0);
> =A0 =A0 ASSERT(d->processor < nr_cpu_ids);
> =A0 =A0 ASSERT(per_cpu(schedule_data, d->processor).curr);
> @@ -1244,7 +1169,7 @@ static void sedf_dump_domain(struct vcpu
> =A0}
>
>
> -/* dumps all domains on the specified cpu */
> +/* Dumps all domains on the specified cpu */
> =A0static void sedf_dump_cpu_state(const struct scheduler *ops, int i)
> =A0{
> =A0 =A0 struct list_head =A0 =A0 =A0*list, *queue, *tmp;
> @@ -1319,7 +1244,7 @@ static void sedf_dump_cpu_state(const st
> =A0}
>
>
> -/* Adjusts periods and slices of the domains accordingly to their weight=
s. */
> +/* Adjusts periods and slices of the domains accordingly to their weight=
s */
> =A0static int sedf_adjust_weights(struct cpupool *c, struct xen_domctl_sc=
heduler_op *cmd)
> =A0{
> =A0 =A0 struct vcpu *p;
> @@ -1335,7 +1260,7 @@ static int sedf_adjust_weights(struct cp
> =A0 =A0 =A0 =A0 return -ENOMEM;
> =A0 =A0 }
>
> - =A0 =A0/* Sum across all weights. */
> + =A0 =A0/* Sum across all weights */
> =A0 =A0 rcu_read_lock(&domlist_read_lock);
> =A0 =A0 for_each_domain_in_cpupool( d, c )
> =A0 =A0 {
> @@ -1350,11 +1275,13 @@ static int sedf_adjust_weights(struct cp
> =A0 =A0 =A0 =A0 =A0 =A0 }
> =A0 =A0 =A0 =A0 =A0 =A0 else
> =A0 =A0 =A0 =A0 =A0 =A0 {
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/*don't modify domains who don't have a =
weight, but sum
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0up the time they need, projected to =
a WEIGHT_PERIOD,
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0so that this time is not given to th=
e weight-driven
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0domains*/
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/*check for overflows*/
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/* Don't modify domains who don't have a=
 weight, but sum
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 * up the time they need, projected to a=
 WEIGHT_PERIOD,
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 * so that this time is not given to the=
 weight-driven
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 * =A0domains
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 */
> +
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/* Check for overflows */
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ASSERT((WEIGHT_PERIOD < ULONG_MAX)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0&& (EDOM_INFO(p)->slice_or=
ig < ULONG_MAX));
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 sumt[cpu] +=3D
> @@ -1365,7 +1292,7 @@ static int sedf_adjust_weights(struct cp
> =A0 =A0 }
> =A0 =A0 rcu_read_unlock(&domlist_read_lock);
>
> - =A0 =A0/* Adjust all slices (and periods) to the new weight. */
> + =A0 =A0/* Adjust all slices (and periods) to the new weight */
> =A0 =A0 rcu_read_lock(&domlist_read_lock);
> =A0 =A0 for_each_domain_in_cpupool( d, c )
> =A0 =A0 {
> @@ -1393,20 +1320,15 @@ static int sedf_adjust_weights(struct cp
> =A0}
>
>
> -/* set or fetch domain scheduling parameters */
> +/* Set or fetch domain scheduling parameters */
> =A0static int sedf_adjust(const struct scheduler *ops, struct domain *p, =
struct xen_domctl_scheduler_op *op)
> =A0{
> =A0 =A0 struct vcpu *v;
> =A0 =A0 int rc;
>
> - =A0 =A0PRINT(2,"sedf_adjust was called, domain-id %i new period %"PRIu6=
4" "
> - =A0 =A0 =A0 =A0 =A0"new slice %"PRIu64"\nlatency %"PRIu64" extra:%s\n",
> - =A0 =A0 =A0 =A0 =A0p->domain_id, op->u.sedf.period, op->u.sedf.slice,
> - =A0 =A0 =A0 =A0 =A0op->u.sedf.latency, (op->u.sedf.extratime)?"yes":"no=
");
> -
> =A0 =A0 if ( op->cmd =3D=3D XEN_DOMCTL_SCHEDOP_putinfo )
> =A0 =A0 {
> - =A0 =A0 =A0 =A0/* Check for sane parameters. */
> + =A0 =A0 =A0 =A0/* Check for sane parameters */
> =A0 =A0 =A0 =A0 if ( !op->u.sedf.period && !op->u.sedf.weight )
> =A0 =A0 =A0 =A0 =A0 =A0 return -EINVAL;
> =A0 =A0 =A0 =A0 if ( op->u.sedf.weight )
> @@ -1414,7 +1336,7 @@ static int sedf_adjust(const struct sche
> =A0 =A0 =A0 =A0 =A0 =A0 if ( (op->u.sedf.extratime & EXTRA_AWARE) &&
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(!op->u.sedf.period) )
> =A0 =A0 =A0 =A0 =A0 =A0 {
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/* Weight-driven domains with extratime =
only. */
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/* Weight-driven domains with extratime =
only */
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 for_each_vcpu ( p, v )
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 {
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 EDOM_INFO(v)->extraweight =3D op-=
>u.sedf.weight;
> @@ -1425,7 +1347,7 @@ static int sedf_adjust(const struct sche
> =A0 =A0 =A0 =A0 =A0 =A0 }
> =A0 =A0 =A0 =A0 =A0 =A0 else
> =A0 =A0 =A0 =A0 =A0 =A0 {
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/* Weight-driven domains with real-time =
execution. */
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/* Weight-driven domains with real-time =
execution */
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 for_each_vcpu ( p, v )
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 EDOM_INFO(v)->weight =3D op->u.se=
df.weight;
> =A0 =A0 =A0 =A0 =A0 =A0 }
> @@ -1435,8 +1357,7 @@ static int sedf_adjust(const struct sche
> =A0 =A0 =A0 =A0 =A0 =A0 /* Time-driven domains. */
> =A0 =A0 =A0 =A0 =A0 =A0 for_each_vcpu ( p, v )
> =A0 =A0 =A0 =A0 =A0 =A0 {
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/*
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 * Sanity checking: note that disabling =
extra weight requires
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/* Sanity checking: note that disabling =
extra weight requires
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* that we set a non-zero slice.
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0*/
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if ( (op->u.sedf.period > PERIOD_MAX) ||
> @@ -1477,7 +1398,6 @@ static int sedf_adjust(const struct sche
> =A0 =A0 =A0 =A0 op->u.sedf.weight =A0 =A0=3D EDOM_INFO(p->vcpu[0])->weigh=
t;
> =A0 =A0 }
>
> - =A0 =A0PRINT(2,"sedf_adjust_finished\n");
> =A0 =A0 return 0;
> =A0}
>
>
> --
> <<This happens because I choose it to happen!>> (Raistlin Majere)
> -------------------------------------------------------------------
> Dario Faggioli, http://retis.sssup.it/people/faggioli
> Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
> PhD Candidate, ReTiS Lab, Scuola Superiore Sant'Anna, Pisa (Italy)
>
>
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 21 12:22:06 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 12:22:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdLBE-0004j4-SL; Wed, 21 Dec 2011 12:21:56 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1RdLBC-0004iY-UX
	for xen-devel@lists.xensource.com; Wed, 21 Dec 2011 12:21:55 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1324470105!6228453!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=1.4 required=7.0 tests=BODY_RANDOM_LONG,DIET_1,
	RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29679 invoked from network); 21 Dec 2011 12:21:46 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Dec 2011 12:21:46 -0000
Received: by iagw33 with SMTP id w33so41369040iag.30
	for <xen-devel@lists.xensource.com>;
	Wed, 21 Dec 2011 04:21:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=kLCF5VJ6E95JT7OZZMotrzT7YpwRtvRDB8hMreMUKRw=;
	b=N4biVQw3PxC+ydbPgF79Fs6/4FhOYvzH8hZ0GQiEiscVSfM2RgF9Q4TRyDKYbBSJNu
	Hm2gNx+YbjiF/fNb9nFSEuG0n4dtJMW6RGWYCgOrZsDuejtfC5GoifRnoA4SsGbU3uza
	wJ50o6L7dDDm4tJbDZwiVu8H0UpIu3+mVAj3E=
MIME-Version: 1.0
Received: by 10.50.191.225 with SMTP id hb1mr3069062igc.17.1324470105104; Wed,
	21 Dec 2011 04:21:45 -0800 (PST)
Received: by 10.231.146.21 with HTTP; Wed, 21 Dec 2011 04:21:45 -0800 (PST)
In-Reply-To: <1324454839.2682.1.camel@Solace>
References: <1324454839.2682.1.camel@Solace>
Date: Wed, 21 Dec 2011 12:21:45 +0000
X-Google-Sender-Auth: l7j2o718I0v7SuIbk-OjZpVEg1k
Message-ID: <CAFLBxZYtb+DaZ3cQD=KR1Xty-YZtsyC53PEiNO4bVU=3qP2WSg@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Dario Faggioli <raistlin@linux.it>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Keir Fraser <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH] sedf: remove useless tracing printk and
 harmonize comments style.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Dec 21, 2011 at 8:07 AM, Dario Faggioli <raistlin@linux.it> wrote:
> sched_sedf.c used o have its own mechanism for producing tracing-alike
> kind of information (domain block, wakeup, etc.). Nowadays, with an even
> not so high number of pCPUs/vCPUs, just trying to enable this makes
> the serial console completely unusable, produces tons of very hard to
> parse and interpreet logging and can easily livelock Dom0. Moreover,
> pretty much the same result this is struggling to get to, is better
> achieved by enabling the scheduler-related tracing events, as
> it is for the other schedulers (say, credit or credit2).
>
> For all these reasons, this removes that machinery completely. While at
> it, check in some cosmetics that harmonize the comments withim themself
> and with the rest of the code base.

RE removing the prinks, and most of the comment changes, ACK.

However, I think the typical comment style is that you should either
do things this way:

/* A one-line comment, start and end in one line */

Or this way:
/*
 * A multi-line comment,
 * Where the opening and closing each have their own line.
 */

Or,
/* If you have a short comment that can't fit on
 * one line, put it on two, but with out any extra lines. */

But you seem to be replacing all multi-line comments with this:

/* The first line having the open-comment at the benning,
 * But the close-comment having its own line.
 */

I've never seen that before, and it looks a bit weird. :-)

I prefer the first two, with judicious use of the third when appropriate.

 -George
>
> Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
>
> diff -r 17d99691e0ec xen/common/sched_sedf.c
> --- a/xen/common/sched_sedf.c =A0 Tue Dec 20 16:39:56 2011 +0000
> +++ b/xen/common/sched_sedf.c =A0 Tue Dec 20 17:32:52 2011 +0000
> @@ -13,14 +13,6 @@
> =A0#include <xen/time.h>
> =A0#include <xen/errno.h>
>
> -/*verbosity settings*/
> -#define SEDFLEVEL 0
> -#define PRINT(_f, _a...) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0\
> - =A0 =A0do { =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 =A0\
> - =A0 =A0 =A0 =A0if ( (_f) <=3D SEDFLEVEL ) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0\
> - =A0 =A0 =A0 =A0 =A0 =A0printk(_a ); =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0\
> - =A0 =A0} while ( 0 )
> -
> =A0#define SEDF_CPUONLINE(_pool) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 \
> =A0 =A0 (((_pool) =3D=3D NULL) ? &cpupool_free_cpus : (_pool)->cpu_valid)
>
> @@ -66,34 +58,35 @@ struct sedf_vcpu_info {
> =A0 =A0 struct list_head list;
> =A0 =A0 struct list_head extralist[2];
>
> - =A0 =A0/*Parameters for EDF*/
> - =A0 =A0s_time_t =A0period; =A0/*=3D(relative deadline)*/
> - =A0 =A0s_time_t =A0slice; =A0/*=3Dworst case execution time*/
> + =A0 =A0/* Parameters for EDF */
> + =A0 =A0s_time_t =A0period; =A0/* =3D(relative deadline) */
> + =A0 =A0s_time_t =A0slice; =A0 /* =3Dworst case execution time */
>
> - =A0 =A0/*Advaced Parameters*/
> - =A0 =A0/*Latency Scaling*/
> + =A0 =A0/* Advaced Parameters */
> +
> + =A0 =A0/* Latency Scaling */
> =A0 =A0 s_time_t =A0period_orig;
> =A0 =A0 s_time_t =A0slice_orig;
> =A0 =A0 s_time_t =A0latency;
>
> - =A0 =A0/*status of domain*/
> + =A0 =A0/* Status of domain */
> =A0 =A0 int =A0 =A0 =A0 status;
> - =A0 =A0/*weights for "Scheduling for beginners/ lazy/ etc." ;)*/
> + =A0 =A0/* Weights for "Scheduling for beginners/ lazy/ etc." ;) */
> =A0 =A0 short =A0 =A0 weight;
> =A0 =A0 short =A0 =A0 extraweight;
> - =A0 =A0/*Bookkeeping*/
> + =A0 =A0/* Bookkeeping */
> =A0 =A0 s_time_t =A0deadl_abs;
> =A0 =A0 s_time_t =A0sched_start_abs;
> =A0 =A0 s_time_t =A0cputime;
> - =A0 =A0/* times the domain un-/blocked */
> + =A0 =A0/* Times the domain un-/blocked */
> =A0 =A0 s_time_t =A0block_abs;
> =A0 =A0 s_time_t =A0unblock_abs;
>
> - =A0 =A0/*scores for {util, block penalty}-weighted extratime distributi=
on*/
> + =A0 =A0/* Scores for {util, block penalty}-weighted extratime distribut=
ion */
> =A0 =A0 int =A0 score[2];
> =A0 =A0 s_time_t =A0short_block_lost_tot;
>
> - =A0 =A0/*Statistics*/
> + =A0 =A0/* Statistics */
> =A0 =A0 s_time_t =A0extra_time_tot;
>
> =A0#ifdef SEDF_STATS
> @@ -158,18 +151,16 @@ static inline void extraq_del(struct vcp
> =A0{
> =A0 =A0 struct list_head *list =3D EXTRALIST(d,i);
> =A0 =A0 ASSERT(extraq_on(d,i));
> - =A0 =A0PRINT(3, "Removing domain %i.%i from L%i extraq\n",
> - =A0 =A0 =A0 =A0 =A0d->domain->domain_id, d->vcpu_id, i);
> =A0 =A0 list_del(list);
> =A0 =A0 list->next =3D NULL;
> =A0 =A0 ASSERT(!extraq_on(d, i));
> =A0}
>
> -/* adds a domain to the queue of processes which are aware of extra time=
. List
> - =A0 is sorted by score, where a lower score means higher priority for a=
n extra
> - =A0 slice. It also updates the score, by simply subtracting a fixed val=
ue from
> - =A0 each entry, in order to avoid overflow. The algorithm works by simp=
ly
> - =A0 charging each domain that recieved extratime with an inverse of its=
 weight.
> +/* Adds a domain to the queue of processes which are aware of extra time=
. List
> + * is sorted by score, where a lower score means higher priority for an =
extra
> + * slice. It also updates the score, by simply subtracting a fixed value=
 from
> + * each entry, in order to avoid overflow. The algorithm works by simply
> + * charging each domain that recieved extratime with an inverse of its w=
eight.
> =A0*/
> =A0static inline void extraq_add_sort_update(struct vcpu *d, int i, int s=
ub)
> =A0{
> @@ -178,13 +169,7 @@ static inline void extraq_add_sort_updat
>
> =A0 =A0 ASSERT(!extraq_on(d,i));
>
> - =A0 =A0PRINT(3, "Adding domain %i.%i (score=3D %i, short_pen=3D %"PRIi6=
4")"
> - =A0 =A0 =A0 =A0 =A0" to L%i extraq\n",
> - =A0 =A0 =A0 =A0 =A0d->domain->domain_id, d->vcpu_id, EDOM_INFO(d)->scor=
e[i],
> - =A0 =A0 =A0 =A0 =A0EDOM_INFO(d)->short_block_lost_tot, i);
> -
> - =A0 =A0/*
> - =A0 =A0 * Iterate through all elements to find our "hole" and on our way
> + =A0 =A0/* Iterate through all elements to find our "hole" and on our way
> =A0 =A0 =A0* update all the other scores.
> =A0 =A0 =A0*/
> =A0 =A0 list_for_each ( cur, EXTRAQ(d->processor, i) )
> @@ -193,25 +178,18 @@ static inline void extraq_add_sort_updat
> =A0 =A0 =A0 =A0 curinf->score[i] -=3D sub;
> =A0 =A0 =A0 =A0 if ( EDOM_INFO(d)->score[i] < curinf->score[i] )
> =A0 =A0 =A0 =A0 =A0 =A0 break;
> - =A0 =A0 =A0 =A0PRINT(4,"\tbehind domain %i.%i (score=3D %i)\n",
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0curinf->vcpu->domain->domain_id,
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0curinf->vcpu->vcpu_id, curinf->score[i]);
> =A0 =A0 }
>
> - =A0 =A0/* cur now contains the element, before which we'll enqueue. */
> - =A0 =A0PRINT(3, "\tlist_add to %p\n", cur->prev);
> + =A0 =A0/* cur now contains the element, before which we'll enqueue */
> =A0 =A0 list_add(EXTRALIST(d,i),cur->prev);
>
> - =A0 =A0/* Continue updating the extraq. */
> + =A0 =A0/* Continue updating the extraq */
> =A0 =A0 if ( (cur !=3D EXTRAQ(d->processor,i)) && sub )
> =A0 =A0 {
> =A0 =A0 =A0 =A0 for ( cur =3D cur->next; cur !=3D EXTRAQ(d->processor,i);=
 cur =3D cur->next )
> =A0 =A0 =A0 =A0 {
> =A0 =A0 =A0 =A0 =A0 =A0 curinf =3D list_entry(cur,struct sedf_vcpu_info, =
extralist[i]);
> =A0 =A0 =A0 =A0 =A0 =A0 curinf->score[i] -=3D sub;
> - =A0 =A0 =A0 =A0 =A0 =A0PRINT(4, "\tupdating domain %i.%i (score=3D %u)\=
n",
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0curinf->vcpu->domain->domain_id,
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0curinf->vcpu->vcpu_id, curinf->score=
[i]);
> =A0 =A0 =A0 =A0 }
> =A0 =A0 }
>
> @@ -221,29 +199,14 @@ static inline void extraq_check(struct v
> =A0{
> =A0 =A0 if ( extraq_on(d, EXTRA_UTIL_Q) )
> =A0 =A0 {
> - =A0 =A0 =A0 =A0PRINT(2,"Dom %i.%i is on L1 extraQ\n",
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0d->domain->domain_id, d->vcpu_id);
> -
> =A0 =A0 =A0 =A0 if ( !(EDOM_INFO(d)->status & EXTRA_AWARE) &&
> =A0 =A0 =A0 =A0 =A0 =A0 =A0!extra_runs(EDOM_INFO(d)) )
> - =A0 =A0 =A0 =A0{
> =A0 =A0 =A0 =A0 =A0 =A0 extraq_del(d, EXTRA_UTIL_Q);
> - =A0 =A0 =A0 =A0 =A0 =A0PRINT(2,"Removed dom %i.%i from L1 extraQ\n",
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0d->domain->domain_id, d->vcpu_id);
> - =A0 =A0 =A0 =A0}
> =A0 =A0 }
> =A0 =A0 else
> =A0 =A0 {
> - =A0 =A0 =A0 =A0PRINT(2, "Dom %i.%i is NOT on L1 extraQ\n",
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0d->domain->domain_id,
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0d->vcpu_id);
> -
> =A0 =A0 =A0 =A0 if ( (EDOM_INFO(d)->status & EXTRA_AWARE) && sedf_runnabl=
e(d) )
> - =A0 =A0 =A0 =A0{
> =A0 =A0 =A0 =A0 =A0 =A0 extraq_add_sort_update(d, EXTRA_UTIL_Q, 0);
> - =A0 =A0 =A0 =A0 =A0 =A0PRINT(2,"Added dom %i.%i to L1 extraQ\n",
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0d->domain->domain_id, d->vcpu_id);
> - =A0 =A0 =A0 =A0}
> =A0 =A0 }
> =A0}
>
> @@ -252,7 +215,7 @@ static inline void extraq_check_add_unbl
> =A0 =A0 struct sedf_vcpu_info *inf =3D EDOM_INFO(d);
>
> =A0 =A0 if ( inf->status & EXTRA_AWARE )
> - =A0 =A0 =A0 =A0/* Put on the weighted extraq without updating any score=
s. */
> + =A0 =A0 =A0 =A0/* Put on the weighted extraq without updating any score=
s */
> =A0 =A0 =A0 =A0 extraq_add_sort_update(d, EXTRA_UTIL_Q, 0);
> =A0}
>
> @@ -265,8 +228,6 @@ static inline void __del_from_queue(stru
> =A0{
> =A0 =A0 struct list_head *list =3D LIST(d);
> =A0 =A0 ASSERT(__task_on_queue(d));
> - =A0 =A0PRINT(3,"Removing domain %i.%i (bop=3D %"PRIu64") from runq/wait=
q\n",
> - =A0 =A0 =A0 =A0 =A0d->domain->domain_id, d->vcpu_id, PERIOD_BEGIN(EDOM_=
INFO(d)));
> =A0 =A0 list_del(list);
> =A0 =A0 list->next =3D NULL;
> =A0 =A0 ASSERT(!__task_on_queue(d));
> @@ -279,13 +240,12 @@ static inline void list_insert_sort(
> =A0{
> =A0 =A0 struct list_head =A0 =A0 *cur;
>
> - =A0 =A0/* Iterate through all elements to find our "hole". */
> + =A0 =A0/* Iterate through all elements to find our "hole" */
> =A0 =A0 list_for_each( cur, list )
> =A0 =A0 =A0 =A0 if ( comp(element, cur) < 0 )
> =A0 =A0 =A0 =A0 =A0 =A0 break;
>
> - =A0 =A0/* cur now contains the element, before which we'll enqueue. */
> - =A0 =A0PRINT(3,"\tlist_add to %p\n",cur->prev);
> + =A0 =A0/* cur now contains the element, before which we'll enqueue */
> =A0 =A0 list_add(element, cur->prev);
> =A0}
>
> @@ -303,30 +263,26 @@ static int name##_comp(struct list_head*
> =A0 =A0 =A0 =A0 return 1; =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 \
> =A0}
>
> -/* adds a domain to the queue of processes which wait for the beginning =
of the
> - =A0 next period; this list is therefore sortet by this time, which is s=
imply
> - =A0 absol. deadline - period
> +/* Adds a domain to the queue of processes which wait for the beginning =
of the
> + * next period; this list is therefore sortet by this time, which is sim=
ply
> + * absol. deadline - period.
> =A0*/
> =A0DOMAIN_COMPARER(waitq, list, PERIOD_BEGIN(d1), PERIOD_BEGIN(d2));
> =A0static inline void __add_to_waitqueue_sort(struct vcpu *v)
> =A0{
> =A0 =A0 ASSERT(!__task_on_queue(v));
> - =A0 =A0PRINT(3,"Adding domain %i.%i (bop=3D %"PRIu64") to waitq\n",
> - =A0 =A0 =A0 =A0 =A0v->domain->domain_id, v->vcpu_id, PERIOD_BEGIN(EDOM_=
INFO(v)));
> =A0 =A0 list_insert_sort(WAITQ(v->processor), LIST(v), waitq_comp);
> =A0 =A0 ASSERT(__task_on_queue(v));
> =A0}
>
> -/* adds a domain to the queue of processes which have started their curr=
ent
> - =A0 period and are runnable (i.e. not blocked, dieing,...). The first e=
lement
> - =A0 on this list is running on the processor, if the list is empty the =
idle
> - =A0 task will run. As we are implementing EDF, this list is sorted by d=
eadlines.
> +/* Adds a domain to the queue of processes which have started their curr=
ent
> + * period and are runnable (i.e. not blocked, dieing,...). The first ele=
ment
> + * on this list is running on the processor, if the list is empty the id=
le
> + * task will run. As we are implementing EDF, this list is sorted by dea=
dlines.
> =A0*/
> =A0DOMAIN_COMPARER(runq, list, d1->deadl_abs, d2->deadl_abs);
> =A0static inline void __add_to_runqueue_sort(struct vcpu *v)
> =A0{
> - =A0 =A0PRINT(3,"Adding domain %i.%i (deadl=3D %"PRIu64") to runq\n",
> - =A0 =A0 =A0 =A0 =A0v->domain->domain_id, v->vcpu_id, EDOM_INFO(v)->dead=
l_abs);
> =A0 =A0 list_insert_sort(RUNQ(v->processor), LIST(v), runq_comp);
> =A0}
>
> @@ -445,22 +401,21 @@ static int sedf_pick_cpu(const struct sc
> =A0 =A0 return cpumask_first(&online_affinity);
> =A0}
>
> -/*
> - * Handles the rescheduling & bookkeeping of domains running in their
> +
> +/* Handles the rescheduling & bookkeeping of domains running in their
> =A0* guaranteed timeslice.
> =A0*/
> =A0static void desched_edf_dom(s_time_t now, struct vcpu* d)
> =A0{
> =A0 =A0 struct sedf_vcpu_info* inf =3D EDOM_INFO(d);
>
> - =A0 =A0/* Current domain is running in real time mode. */
> + =A0 =A0/* Current domain is running in real time mode */
> =A0 =A0 ASSERT(__task_on_queue(d));
>
> - =A0 =A0/* Update the domain's cputime. */
> + =A0 =A0/* Update the domain's cputime */
> =A0 =A0 inf->cputime +=3D now - inf->sched_start_abs;
>
> - =A0 =A0/*
> - =A0 =A0 * Scheduling decisions which don't remove the running domain fr=
om the
> + =A0 =A0/* Scheduling decisions which don't remove the running domain fr=
om the
> =A0 =A0 =A0* runq.
> =A0 =A0 =A0*/
> =A0 =A0 if ( (inf->cputime < inf->slice) && sedf_runnable(d) )
> @@ -468,8 +423,7 @@ static void desched_edf_dom(s_time_t now
>
> =A0 =A0 __del_from_queue(d);
>
> - =A0 =A0/*
> - =A0 =A0 * Manage bookkeeping (i.e. calculate next deadline, memorise
> + =A0 =A0/* Manage bookkeeping (i.e. calculate next deadline, memorise
> =A0 =A0 =A0* overrun-time of slice) of finished domains.
> =A0 =A0 =A0*/
> =A0 =A0 if ( inf->cputime >=3D inf->slice )
> @@ -478,30 +432,30 @@ static void desched_edf_dom(s_time_t now
>
> =A0 =A0 =A0 =A0 if ( inf->period < inf->period_orig )
> =A0 =A0 =A0 =A0 {
> - =A0 =A0 =A0 =A0 =A0 =A0/* This domain runs in latency scaling or burst =
mode. */
> + =A0 =A0 =A0 =A0 =A0 =A0/* This domain runs in latency scaling or burst =
mode */
> =A0 =A0 =A0 =A0 =A0 =A0 inf->period *=3D 2;
> =A0 =A0 =A0 =A0 =A0 =A0 inf->slice =A0*=3D 2;
> =A0 =A0 =A0 =A0 =A0 =A0 if ( (inf->period > inf->period_orig) ||
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(inf->slice > inf->slice_orig) )
> =A0 =A0 =A0 =A0 =A0 =A0 {
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/* Reset slice and period. */
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/* Reset slice and period */
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 inf->period =3D inf->period_orig;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 inf->slice =3D inf->slice_orig;
> =A0 =A0 =A0 =A0 =A0 =A0 }
> =A0 =A0 =A0 =A0 }
>
> - =A0 =A0 =A0 =A0/* Set next deadline. */
> + =A0 =A0 =A0 =A0/* Set next deadline */
> =A0 =A0 =A0 =A0 inf->deadl_abs +=3D inf->period;
> =A0 =A0 }
>
> - =A0 =A0/* Add a runnable domain to the waitqueue. */
> + =A0 =A0/* Add a runnable domain to the waitqueue */
> =A0 =A0 if ( sedf_runnable(d) )
> =A0 =A0 {
> =A0 =A0 =A0 =A0 __add_to_waitqueue_sort(d);
> =A0 =A0 }
> =A0 =A0 else
> =A0 =A0 {
> - =A0 =A0 =A0 =A0/* We have a blocked realtime task -> remove it from exq=
s too. */
> + =A0 =A0 =A0 =A0/* We have a blocked realtime task -> remove it from exq=
s too */
> =A0 =A0 =A0 =A0 if ( extraq_on(d, EXTRA_PEN_Q) )
> =A0 =A0 =A0 =A0 =A0 =A0 extraq_del(d, EXTRA_PEN_Q);
> =A0 =A0 =A0 =A0 if ( extraq_on(d, EXTRA_UTIL_Q) )
> @@ -521,73 +475,59 @@ static void update_queues(
> =A0 =A0 struct list_head =A0 =A0 *cur, *tmp;
> =A0 =A0 struct sedf_vcpu_info *curinf;
>
> - =A0 =A0PRINT(3,"Updating waitq..\n");
> -
> - =A0 =A0/*
> - =A0 =A0 * Check for the first elements of the waitqueue, whether their
> + =A0 =A0/* Check for the first elements of the waitqueue, whether their
> =A0 =A0 =A0* next period has already started.
> =A0 =A0 =A0*/
> =A0 =A0 list_for_each_safe ( cur, tmp, waitq )
> =A0 =A0 {
> =A0 =A0 =A0 =A0 curinf =3D list_entry(cur, struct sedf_vcpu_info, list);
> - =A0 =A0 =A0 =A0PRINT(4,"\tLooking @ dom %i.%i\n",
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0curinf->vcpu->domain->domain_id, curinf->vcp=
u->vcpu_id);
> =A0 =A0 =A0 =A0 if ( PERIOD_BEGIN(curinf) > now )
> =A0 =A0 =A0 =A0 =A0 =A0 break;
> =A0 =A0 =A0 =A0 __del_from_queue(curinf->vcpu);
> =A0 =A0 =A0 =A0 __add_to_runqueue_sort(curinf->vcpu);
> =A0 =A0 }
>
> - =A0 =A0PRINT(3,"Updating runq..\n");
> -
> - =A0 =A0/* Process the runq, find domains that are on the runq that shou=
ldn't. */
> + =A0 =A0/* Process the runq, find domains that are on the runq that shou=
ldn't */
> =A0 =A0 list_for_each_safe ( cur, tmp, runq )
> =A0 =A0 {
> =A0 =A0 =A0 =A0 curinf =3D list_entry(cur,struct sedf_vcpu_info,list);
> - =A0 =A0 =A0 =A0PRINT(4,"\tLooking @ dom %i.%i\n",
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0curinf->vcpu->domain->domain_id, curinf->vcp=
u->vcpu_id);
>
> =A0 =A0 =A0 =A0 if ( unlikely(curinf->slice =3D=3D 0) )
> =A0 =A0 =A0 =A0 {
> - =A0 =A0 =A0 =A0 =A0 =A0/* Ignore domains with empty slice. */
> - =A0 =A0 =A0 =A0 =A0 =A0PRINT(4,"\tUpdating zero-slice domain %i.%i\n",
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0curinf->vcpu->domain->domain_id,
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0curinf->vcpu->vcpu_id);
> + =A0 =A0 =A0 =A0 =A0 =A0/* Ignore domains with empty slice */
> =A0 =A0 =A0 =A0 =A0 =A0 __del_from_queue(curinf->vcpu);
>
> - =A0 =A0 =A0 =A0 =A0 =A0/* Move them to their next period. */
> + =A0 =A0 =A0 =A0 =A0 =A0/* Move them to their next period */
> =A0 =A0 =A0 =A0 =A0 =A0 curinf->deadl_abs +=3D curinf->period;
>
> - =A0 =A0 =A0 =A0 =A0 =A0/* Ensure that the start of the next period is i=
n the future. */
> + =A0 =A0 =A0 =A0 =A0 =A0/* Ensure that the start of the next period is i=
n the future */
> =A0 =A0 =A0 =A0 =A0 =A0 if ( unlikely(PERIOD_BEGIN(curinf) < now) )
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 curinf->deadl_abs +=3D
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (DIV_UP(now - PERIOD_BEGIN(curinf=
),
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 curinf->period)) =
* curinf->period;
>
> - =A0 =A0 =A0 =A0 =A0 =A0/* Put them back into the queue. */
> + =A0 =A0 =A0 =A0 =A0 =A0/* Put them back into the queue */
> =A0 =A0 =A0 =A0 =A0 =A0 __add_to_waitqueue_sort(curinf->vcpu);
> =A0 =A0 =A0 =A0 }
> =A0 =A0 =A0 =A0 else if ( unlikely((curinf->deadl_abs < now) ||
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(curinf->cputime >=
 curinf->slice)) )
> =A0 =A0 =A0 =A0 {
> - =A0 =A0 =A0 =A0 =A0 =A0/*
> - =A0 =A0 =A0 =A0 =A0 =A0 * We missed the deadline or the slice was alrea=
dy finished.
> + =A0 =A0 =A0 =A0 =A0 =A0/* We missed the deadline or the slice was alrea=
dy finished.
> =A0 =A0 =A0 =A0 =A0 =A0 =A0* Might hapen because of dom_adj.
> =A0 =A0 =A0 =A0 =A0 =A0 =A0*/
> - =A0 =A0 =A0 =A0 =A0 =A0PRINT(4,"\tDomain %i.%i exceeded it's deadline/"
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0"slice (%"PRIu64" / %"PRIu64") now: =
%"PRIu64
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0" cputime: %"PRIu64"\n",
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0curinf->vcpu->domain->domain_id,
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0curinf->vcpu->vcpu_id,
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0curinf->deadl_abs, curinf->slice, no=
w,
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0curinf->cputime);
> + =A0 =A0 =A0 =A0 =A0 =A0printk("\tDomain %i.%i exceeded it's deadline/"
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 "slice (%"PRIu64" / %"PRIu64") now:=
 %"PRIu64
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 " cputime: %"PRIu64"\n",
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 curinf->vcpu->domain->domain_id,
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 curinf->vcpu->vcpu_id,
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 curinf->deadl_abs, curinf->slice, n=
ow,
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 curinf->cputime);
> =A0 =A0 =A0 =A0 =A0 =A0 __del_from_queue(curinf->vcpu);
>
> - =A0 =A0 =A0 =A0 =A0 =A0/* Common case: we miss one period. */
> + =A0 =A0 =A0 =A0 =A0 =A0/* Common case: we miss one period */
> =A0 =A0 =A0 =A0 =A0 =A0 curinf->deadl_abs +=3D curinf->period;
>
> - =A0 =A0 =A0 =A0 =A0 =A0/*
> - =A0 =A0 =A0 =A0 =A0 =A0 * If we are still behind: modulo arithmetic, fo=
rce deadline
> + =A0 =A0 =A0 =A0 =A0 =A0/* If we are still behind: modulo arithmetic, fo=
rce deadline
> =A0 =A0 =A0 =A0 =A0 =A0 =A0* to be in future and aligned to period border=
s.
> =A0 =A0 =A0 =A0 =A0 =A0 =A0*/
> =A0 =A0 =A0 =A0 =A0 =A0 if ( unlikely(curinf->deadl_abs < now) )
> @@ -596,7 +536,7 @@ static void update_queues(
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0curinf->period) * =
curinf->period;
> =A0 =A0 =A0 =A0 =A0 =A0 ASSERT(curinf->deadl_abs >=3D now);
>
> - =A0 =A0 =A0 =A0 =A0 =A0/* Give a fresh slice. */
> + =A0 =A0 =A0 =A0 =A0 =A0/* Give a fresh slice */
> =A0 =A0 =A0 =A0 =A0 =A0 curinf->cputime =3D 0;
> =A0 =A0 =A0 =A0 =A0 =A0 if ( PERIOD_BEGIN(curinf) > now )
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 __add_to_waitqueue_sort(curinf->vcpu);
> @@ -606,17 +546,16 @@ static void update_queues(
> =A0 =A0 =A0 =A0 else
> =A0 =A0 =A0 =A0 =A0 =A0 break;
> =A0 =A0 }
> -
> - =A0 =A0PRINT(3,"done updating the queues\n");
> =A0}
>
>
> =A0/* removes a domain from the head of the according extraQ and
> - =A0 requeues it at a specified position:
> - =A0 =A0 round-robin extratime: end of extraQ
> - =A0 =A0 weighted ext.: insert in sorted list by score
> - =A0 if the domain is blocked / has regained its short-block-loss
> - =A0 time it is not put on any queue */
> + * requeues it at a specified position:
> + * =A0 round-robin extratime: end of extraQ
> + * =A0 weighted ext.: insert in sorted list by score
> + * if the domain is blocked / has regained its short-block-loss
> + * time it is not put on any queue.
> + */
> =A0static void desched_extra_dom(s_time_t now, struct vcpu *d)
> =A0{
> =A0 =A0 struct sedf_vcpu_info *inf =3D EDOM_INFO(d);
> @@ -625,29 +564,25 @@ static void desched_extra_dom(s_time_t n
>
> =A0 =A0 ASSERT(extraq_on(d, i));
>
> - =A0 =A0/* Unset all running flags. */
> + =A0 =A0/* Unset all running flags */
> =A0 =A0 inf->status =A0&=3D ~(EXTRA_RUN_PEN | EXTRA_RUN_UTIL);
> - =A0 =A0/* Fresh slice for the next run. */
> + =A0 =A0/* Fresh slice for the next run */
> =A0 =A0 inf->cputime =3D 0;
> - =A0 =A0/* Accumulate total extratime. */
> + =A0 =A0/* Accumulate total extratime */
> =A0 =A0 inf->extra_time_tot +=3D now - inf->sched_start_abs;
> =A0 =A0 /* Remove extradomain from head of the queue. */
> =A0 =A0 extraq_del(d, i);
>
> - =A0 =A0/* Update the score. */
> + =A0 =A0/* Update the score */
> =A0 =A0 oldscore =3D inf->score[i];
> =A0 =A0 if ( i =3D=3D EXTRA_PEN_Q )
> =A0 =A0 {
> - =A0 =A0 =A0 =A0/*domain was running in L0 extraq*/
> - =A0 =A0 =A0 =A0/*reduce block lost, probably more sophistication here!*/
> + =A0 =A0 =A0 =A0/* Domain was running in L0 extraq */
> + =A0 =A0 =A0 =A0/* reduce block lost, probably more sophistication here!=
*/
> =A0 =A0 =A0 =A0 /*inf->short_block_lost_tot -=3D EXTRA_QUANTUM;*/
> =A0 =A0 =A0 =A0 inf->short_block_lost_tot -=3D now - inf->sched_start_abs;
> - =A0 =A0 =A0 =A0PRINT(3,"Domain %i.%i: Short_block_loss: %"PRIi64"\n",
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0inf->vcpu->domain->domain_id, inf->vcpu->vcp=
u_id,
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0inf->short_block_lost_tot);
> =A0#if 0
> - =A0 =A0 =A0 =A0/*
> - =A0 =A0 =A0 =A0 * KAF: If we don't exit short-blocking state at this po=
int
> + =A0 =A0 =A0 =A0/* KAF: If we don't exit short-blocking state at this po=
int
> =A0 =A0 =A0 =A0 =A0* domain0 can steal all CPU for up to 10 seconds before
> =A0 =A0 =A0 =A0 =A0* scheduling settles down (when competing against anot=
her
> =A0 =A0 =A0 =A0 =A0* CPU-bound domain). Doing this seems to make things b=
ehave
> @@ -656,51 +591,56 @@ static void desched_extra_dom(s_time_t n
> =A0 =A0 =A0 =A0 if ( inf->short_block_lost_tot <=3D 0 )
> =A0#endif
> =A0 =A0 =A0 =A0 {
> - =A0 =A0 =A0 =A0 =A0 =A0PRINT(4,"Domain %i.%i compensated short block lo=
ss!\n",
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0inf->vcpu->domain->domain_id, inf->v=
cpu->vcpu_id);
> - =A0 =A0 =A0 =A0 =A0 =A0/*we have (over-)compensated our block penalty*/
> + =A0 =A0 =A0 =A0 =A0 =A0/* We have (over-)compensated our block penalty =
*/
> =A0 =A0 =A0 =A0 =A0 =A0 inf->short_block_lost_tot =3D 0;
> - =A0 =A0 =A0 =A0 =A0 =A0/*we don't want a place on the penalty queue any=
more!*/
> + =A0 =A0 =A0 =A0 =A0 =A0/* We don't want a place on the penalty queue an=
ymore! */
> =A0 =A0 =A0 =A0 =A0 =A0 inf->status &=3D ~EXTRA_WANT_PEN_Q;
> =A0 =A0 =A0 =A0 =A0 =A0 goto check_extra_queues;
> =A0 =A0 =A0 =A0 }
>
> - =A0 =A0 =A0 =A0/*we have to go again for another try in the block-extra=
q,
> - =A0 =A0 =A0 =A0 =A0the score is not used incremantally here, as this is
> - =A0 =A0 =A0 =A0 =A0already done by recalculating the block_lost*/
> + =A0 =A0 =A0 =A0/* We have to go again for another try in the block-extr=
aq,
> + =A0 =A0 =A0 =A0 * the score is not used incremantally here, as this is
> + =A0 =A0 =A0 =A0 * already done by recalculating the block_lost
> + =A0 =A0 =A0 =A0 */
> =A0 =A0 =A0 =A0 inf->score[EXTRA_PEN_Q] =3D (inf->period << 10) /
> =A0 =A0 =A0 =A0 =A0 =A0 inf->short_block_lost_tot;
> =A0 =A0 =A0 =A0 oldscore =3D 0;
> =A0 =A0 }
> =A0 =A0 else
> =A0 =A0 {
> - =A0 =A0 =A0 =A0/*domain was running in L1 extraq =3D> score is inverse =
of
> - =A0 =A0 =A0 =A0 =A0utilization and is used somewhat incremental!*/
> + =A0 =A0 =A0 =A0/* Domain was running in L1 extraq =3D> score is inverse=
 of
> + =A0 =A0 =A0 =A0 * utilization and is used somewhat incremental!
> + =A0 =A0 =A0 =A0 */
> =A0 =A0 =A0 =A0 if ( !inf->extraweight )
> - =A0 =A0 =A0 =A0 =A0 =A0/*NB: use fixed point arithmetic with 10 bits*/
> + =A0 =A0 =A0 =A0{
> + =A0 =A0 =A0 =A0 =A0 =A0/* NB: use fixed point arithmetic with 10 bits */
> =A0 =A0 =A0 =A0 =A0 =A0 inf->score[EXTRA_UTIL_Q] =3D (inf->period << 10) /
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 inf->slice;
> + =A0 =A0 =A0 =A0}
> =A0 =A0 =A0 =A0 else
> - =A0 =A0 =A0 =A0 =A0 =A0/*conversion between realtime utilisation and ex=
trawieght:
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0full (ie 100%) utilization is equivalent to =
128 extraweight*/
> + =A0 =A0 =A0 =A0{
> + =A0 =A0 =A0 =A0 =A0 =A0/* Conversion between realtime utilisation and e=
xtrawieght:
> + =A0 =A0 =A0 =A0 =A0 =A0 * full (ie 100%) utilization is equivalent to 1=
28 extraweight
> + =A0 =A0 =A0 =A0 =A0 =A0 */
> =A0 =A0 =A0 =A0 =A0 =A0 inf->score[EXTRA_UTIL_Q] =3D (1<<17) / inf->extra=
weight;
> + =A0 =A0 =A0 =A0}
> =A0 =A0 }
>
> =A0check_extra_queues:
> - =A0 =A0/* Adding a runnable domain to the right queue and removing bloc=
ked ones*/
> + =A0 =A0/* Adding a runnable domain to the right queue and removing bloc=
ked ones */
> =A0 =A0 if ( sedf_runnable(d) )
> =A0 =A0 {
> - =A0 =A0 =A0 =A0/*add according to score: weighted round robin*/
> + =A0 =A0 =A0 =A0/* Add according to score: weighted round robin */
> =A0 =A0 =A0 =A0 if (((inf->status & EXTRA_AWARE) && (i =3D=3D EXTRA_UTIL_=
Q)) ||
> =A0 =A0 =A0 =A0 =A0 =A0 ((inf->status & EXTRA_WANT_PEN_Q) && (i =3D=3D EX=
TRA_PEN_Q)))
> =A0 =A0 =A0 =A0 =A0 =A0 extraq_add_sort_update(d, i, oldscore);
> =A0 =A0 }
> =A0 =A0 else
> =A0 =A0 {
> - =A0 =A0 =A0 =A0/*remove this blocked domain from the waitq!*/
> + =A0 =A0 =A0 =A0/* Remove this blocked domain from the waitq! */
> =A0 =A0 =A0 =A0 __del_from_queue(d);
> - =A0 =A0 =A0 =A0/*make sure that we remove a blocked domain from the oth=
er
> - =A0 =A0 =A0 =A0 =A0extraq too*/
> + =A0 =A0 =A0 =A0/* Make sure that we remove a blocked domain from the ot=
her
> + =A0 =A0 =A0 =A0 * extraq too. */
> =A0 =A0 =A0 =A0 if ( i =3D=3D EXTRA_PEN_Q )
> =A0 =A0 =A0 =A0 {
> =A0 =A0 =A0 =A0 =A0 =A0 if ( extraq_on(d, EXTRA_UTIL_Q) )
> @@ -732,8 +672,9 @@ static struct task_slice sedf_do_extra_s
>
> =A0 =A0 if ( !list_empty(extraq[EXTRA_PEN_Q]) )
> =A0 =A0 {
> - =A0 =A0 =A0 =A0/*we still have elements on the level 0 extraq
> - =A0 =A0 =A0 =A0 =A0=3D> let those run first!*/
> + =A0 =A0 =A0 =A0/* We still have elements on the level 0 extraq
> + =A0 =A0 =A0 =A0 * =3D> let those run first!
> + =A0 =A0 =A0 =A0 */
> =A0 =A0 =A0 =A0 runinf =A0 =3D list_entry(extraq[EXTRA_PEN_Q]->next,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 struct sedf_v=
cpu_info, extralist[EXTRA_PEN_Q]);
> =A0 =A0 =A0 =A0 runinf->status |=3D EXTRA_RUN_PEN;
> @@ -747,7 +688,7 @@ static struct task_slice sedf_do_extra_s
> =A0 =A0 {
> =A0 =A0 =A0 =A0 if ( !list_empty(extraq[EXTRA_UTIL_Q]) )
> =A0 =A0 =A0 =A0 {
> - =A0 =A0 =A0 =A0 =A0 =A0/*use elements from the normal extraqueue*/
> + =A0 =A0 =A0 =A0 =A0 =A0/* Use elements from the normal extraqueue */
> =A0 =A0 =A0 =A0 =A0 =A0 runinf =A0 =3D list_entry(extraq[EXTRA_UTIL_Q]->n=
ext,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 struc=
t sedf_vcpu_info,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 extra=
list[EXTRA_UTIL_Q]);
> @@ -773,10 +714,11 @@ static struct task_slice sedf_do_extra_s
>
>
> =A0/* Main scheduling function
> - =A0 Reasons for calling this function are:
> - =A0 -timeslice for the current period used up
> - =A0 -domain on waitqueue has started it's period
> - =A0 -and various others ;) in general: determine which domain to run ne=
xt*/
> + * Reasons for calling this function are:
> + * -timeslice for the current period used up
> + * -domain on waitqueue has started it's period
> + * -and various others ;) in general: determine which domain to run next
> + */
> =A0static struct task_slice sedf_do_schedule(
> =A0 =A0 const struct scheduler *ops, s_time_t now, bool_t tasklet_work_sc=
heduled)
> =A0{
> @@ -789,13 +731,14 @@ static struct task_slice sedf_do_schedul
> =A0 =A0 struct sedf_vcpu_info *runinf, *waitinf;
> =A0 =A0 struct task_slice =A0 =A0 =A0ret;
>
> - =A0 =A0/*idle tasks don't need any of the following stuf*/
> + =A0 =A0/* Idle tasks don't need any of the following stuf */
> =A0 =A0 if ( is_idle_vcpu(current) )
> =A0 =A0 =A0 =A0 goto check_waitq;
>
> - =A0 =A0/* create local state of the status of the domain, in order to a=
void
> - =A0 =A0 =A0 inconsistent state during scheduling decisions, because dat=
a for
> - =A0 =A0 =A0 vcpu_runnable is not protected by the scheduling lock!*/
> + =A0 =A0/* Create local state of the status of the domain, in order to a=
void
> + =A0 =A0 * inconsistent state during scheduling decisions, because data =
for
> + =A0 =A0 * vcpu_runnable is not protected by the scheduling lock!
> + =A0 =A0 */
> =A0 =A0 if ( !vcpu_runnable(current) )
> =A0 =A0 =A0 =A0 inf->status |=3D SEDF_ASLEEP;
>
> @@ -804,7 +747,7 @@ static struct task_slice sedf_do_schedul
>
> =A0 =A0 if ( unlikely(extra_runs(inf)) )
> =A0 =A0 {
> - =A0 =A0 =A0 =A0/*special treatment of domains running in extra time*/
> + =A0 =A0 =A0 =A0/* Special treatment of domains running in extra time */
> =A0 =A0 =A0 =A0 desched_extra_dom(now, current);
> =A0 =A0 }
> =A0 =A0 else
> @@ -814,10 +757,11 @@ static struct task_slice sedf_do_schedul
> =A0check_waitq:
> =A0 =A0 update_queues(now, runq, waitq);
>
> - =A0 =A0/*now simply pick the first domain from the runqueue, which has =
the
> - =A0 =A0 =A0earliest deadline, because the list is sorted*/
> -
> - =A0 =A0/* Tasklet work (which runs in idle VCPU context) overrides all =
else. */
> + =A0 =A0/* Now simply pick the first domain from the runqueue, which has=
 the
> + =A0 =A0 * earliest deadline, because the list is sorted
> + =A0 =A0 *
> + =A0 =A0 * Tasklet work (which runs in idle VCPU context) overrides all =
else.
> + =A0 =A0 */
> =A0 =A0 if ( tasklet_work_scheduled ||
> =A0 =A0 =A0 =A0 =A0(list_empty(runq) && list_empty(waitq)) ||
> =A0 =A0 =A0 =A0 =A0unlikely(!cpumask_test_cpu(cpu, SEDF_CPUONLINE(per_cpu=
(cpupool, cpu)))) )
> @@ -833,9 +777,10 @@ static struct task_slice sedf_do_schedul
> =A0 =A0 =A0 =A0 {
> =A0 =A0 =A0 =A0 =A0 =A0 waitinf =A0=3D list_entry(waitq->next,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 struc=
t sedf_vcpu_info,list);
> - =A0 =A0 =A0 =A0 =A0 =A0/*rerun scheduler, when scheduled domain reaches=
 it's
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0end of slice or the first domain from the wa=
itqueue
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0gets ready*/
> + =A0 =A0 =A0 =A0 =A0 =A0/* Rerun scheduler, when scheduled domain reache=
s it's
> + =A0 =A0 =A0 =A0 =A0 =A0 * end of slice or the first domain from the wai=
tqueue
> + =A0 =A0 =A0 =A0 =A0 =A0 * gets ready.
> + =A0 =A0 =A0 =A0 =A0 =A0 */
> =A0 =A0 =A0 =A0 =A0 =A0 ret.time =3D MIN(now + runinf->slice - runinf->cp=
utime,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0PERIOD_BEGIN(waiti=
nf)) - now;
> =A0 =A0 =A0 =A0 }
> @@ -847,14 +792,15 @@ static struct task_slice sedf_do_schedul
> =A0 =A0 else
> =A0 =A0 {
> =A0 =A0 =A0 =A0 waitinf =A0=3D list_entry(waitq->next,struct sedf_vcpu_in=
fo, list);
> - =A0 =A0 =A0 =A0/*we could not find any suitable domain
> - =A0 =A0 =A0 =A0 =A0=3D> look for domains that are aware of extratime*/
> + =A0 =A0 =A0 =A0/* We could not find any suitable domain
> + =A0 =A0 =A0 =A0 * =3D> look for domains that are aware of extratime*/
> =A0 =A0 =A0 =A0 ret =3D sedf_do_extra_schedule(now, PERIOD_BEGIN(waitinf),
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0extraq, cpu);
> =A0 =A0 }
>
> - =A0 =A0/*TODO: Do something USEFUL when this happens and find out, why =
it
> - =A0 =A0 =A0still can happen!!!*/
> + =A0 =A0/* TODO: Do something USEFUL when this happens and find out, why=
 it
> + =A0 =A0 * still can happen!!!
> + =A0 =A0 */
> =A0 =A0 if ( ret.time < 0)
> =A0 =A0 {
> =A0 =A0 =A0 =A0 printk("Ouch! We are seriously BEHIND schedule! %"PRIi64"=
\n",
> @@ -874,9 +820,6 @@ static struct task_slice sedf_do_schedul
>
> =A0static void sedf_sleep(const struct scheduler *ops, struct vcpu *d)
> =A0{
> - =A0 =A0PRINT(2,"sedf_sleep was called, domain-id %i.%i\n",
> - =A0 =A0 =A0 =A0 =A0d->domain->domain_id, d->vcpu_id);
> -
> =A0 =A0 if ( is_idle_vcpu(d) )
> =A0 =A0 =A0 =A0 return;
>
> @@ -972,27 +915,29 @@ static void sedf_sleep(const struct sche
> =A0static void unblock_short_extra_support(
> =A0 =A0 struct sedf_vcpu_info* inf, s_time_t now)
> =A0{
> - =A0 =A0/*this unblocking scheme tries to support the domain, by assigni=
ng it
> - =A0 =A0a priority in extratime distribution according to the loss of ti=
me
> - =A0 =A0in this slice due to blocking*/
> + =A0 =A0/* This unblocking scheme tries to support the domain, by assign=
ing it
> + =A0 =A0 * a priority in extratime distribution according to the loss of=
 time
> + =A0 =A0 * in this slice due to blocking
> + =A0 =A0 */
> =A0 =A0 s_time_t pen;
>
> - =A0 =A0/*no more realtime execution in this period!*/
> + =A0 =A0/* No more realtime execution in this period! */
> =A0 =A0 inf->deadl_abs +=3D inf->period;
> =A0 =A0 if ( likely(inf->block_abs) )
> =A0 =A0 {
> - =A0 =A0 =A0 =A0//treat blocked time as consumed by the domain*/
> + =A0 =A0 =A0 =A0/* Treat blocked time as consumed by the domain */
> =A0 =A0 =A0 =A0 /*inf->cputime +=3D now - inf->block_abs;*/
> - =A0 =A0 =A0 =A0/*penalty is time the domain would have
> - =A0 =A0 =A0 =A0 =A0had if it continued to run */
> + =A0 =A0 =A0 =A0/* Penalty is time the domain would have
> + =A0 =A0 =A0 =A0 * had if it continued to run.
> + =A0 =A0 =A0 =A0 */
> =A0 =A0 =A0 =A0 pen =3D (inf->slice - inf->cputime);
> =A0 =A0 =A0 =A0 if ( pen < 0 )
> =A0 =A0 =A0 =A0 =A0 =A0 pen =3D 0;
> - =A0 =A0 =A0 =A0/*accumulate all penalties over the periods*/
> + =A0 =A0 =A0 =A0/* Accumulate all penalties over the periods */
> =A0 =A0 =A0 =A0 /*inf->short_block_lost_tot +=3D pen;*/
> - =A0 =A0 =A0 =A0/*set penalty to the current value*/
> + =A0 =A0 =A0 =A0/* Set penalty to the current value */
> =A0 =A0 =A0 =A0 inf->short_block_lost_tot =3D pen;
> - =A0 =A0 =A0 =A0/*not sure which one is better.. but seems to work well.=
..*/
> + =A0 =A0 =A0 =A0/* Not sure which one is better.. but seems to work well=
... */
>
> =A0 =A0 =A0 =A0 if ( inf->short_block_lost_tot )
> =A0 =A0 =A0 =A0 {
> @@ -1002,28 +947,30 @@ static void unblock_short_extra_support(
> =A0 =A0 =A0 =A0 =A0 =A0 inf->pen_extra_blocks++;
> =A0#endif
> =A0 =A0 =A0 =A0 =A0 =A0 if ( extraq_on(inf->vcpu, EXTRA_PEN_Q) )
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/*remove domain for possible resorting!*/
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/* Remove domain for possible resorting!=
 */
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 extraq_del(inf->vcpu, EXTRA_PEN_Q);
> =A0 =A0 =A0 =A0 =A0 =A0 else
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/*remember that we want to be on the pen=
alty q
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0so that we can continue when we (un-=
)block
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0in penalty-extratime*/
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/* Remember that we want to be on the pe=
nalty q
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 * so that we can continue when we (un-)=
block
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 * in penalty-extratime
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 */
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 inf->status |=3D EXTRA_WANT_PEN_Q;
>
> - =A0 =A0 =A0 =A0 =A0 =A0/*(re-)add domain to the penalty extraq*/
> + =A0 =A0 =A0 =A0 =A0 =A0/* (re-)add domain to the penalty extraq */
> =A0 =A0 =A0 =A0 =A0 =A0 extraq_add_sort_update(inf->vcpu, EXTRA_PEN_Q, 0);
> =A0 =A0 =A0 =A0 }
> =A0 =A0 }
>
> - =A0 =A0/*give it a fresh slice in the next period!*/
> + =A0 =A0/* Give it a fresh slice in the next period! */
> =A0 =A0 inf->cputime =3D 0;
> =A0}
>
>
> =A0static void unblock_long_cons_b(struct sedf_vcpu_info* inf,s_time_t no=
w)
> =A0{
> - =A0 =A0/*Conservative 2b*/
> - =A0 =A0/*Treat the unblocking time as a start of a new period */
> + =A0 =A0/* Conservative 2b */
> +
> + =A0 =A0/* Treat the unblocking time as a start of a new period */
> =A0 =A0 inf->deadl_abs =3D now + inf->period;
> =A0 =A0 inf->cputime =3D 0;
> =A0}
> @@ -1046,15 +993,16 @@ static inline int get_run_type(struct vc
> =A0}
>
>
> -/*Compares two domains in the relation of whether the one is allowed to
> - =A0interrupt the others execution.
> - =A0It returns true (!=3D0) if a switch to the other domain is good.
> - =A0Current Priority scheme is as follows:
> - =A0 EDF > L0 (penalty based) extra-time >
> - =A0 L1 (utilization) extra-time > idle-domain
> - =A0In the same class priorities are assigned as following:
> - =A0 EDF: early deadline > late deadline
> - =A0 L0 extra-time: lower score > higher score*/
> +/* Compares two domains in the relation of whether the one is allowed to
> + * interrupt the others execution.
> + * It returns true (!=3D0) if a switch to the other domain is good.
> + * Current Priority scheme is as follows:
> + * =A0EDF > L0 (penalty based) extra-time >
> + * =A0L1 (utilization) extra-time > idle-domain
> + * In the same class priorities are assigned as following:
> + * =A0EDF: early deadline > late deadline
> + * =A0L0 extra-time: lower score > higher score
> + */
> =A0static inline int should_switch(struct vcpu *cur,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 struct vc=
pu *other,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 s_time_t =
now)
> @@ -1063,19 +1011,19 @@ static inline int should_switch(struct v
> =A0 =A0 cur_inf =A0 =3D EDOM_INFO(cur);
> =A0 =A0 other_inf =3D EDOM_INFO(other);
>
> - =A0 =A0/* Check whether we need to make an earlier scheduling decision.=
 */
> + =A0 =A0/* Check whether we need to make an earlier scheduling decision =
*/
> =A0 =A0 if ( PERIOD_BEGIN(other_inf) <
> =A0 =A0 =A0 =A0 =A0CPU_INFO(other->processor)->current_slice_expires )
> =A0 =A0 =A0 =A0 return 1;
>
> - =A0 =A0/* No timing-based switches need to be taken into account here. =
*/
> + =A0 =A0/* No timing-based switches need to be taken into account here */
> =A0 =A0 switch ( get_run_type(cur) )
> =A0 =A0 {
> =A0 =A0 case DOMAIN_EDF:
> - =A0 =A0 =A0 =A0/* Do not interrupt a running EDF domain. */
> + =A0 =A0 =A0 =A0/* Do not interrupt a running EDF domain */
> =A0 =A0 =A0 =A0 return 0;
> =A0 =A0 case DOMAIN_EXTRA_PEN:
> - =A0 =A0 =A0 =A0/* Check whether we also want the L0 ex-q with lower sco=
re. */
> + =A0 =A0 =A0 =A0/* Check whether we also want the L0 ex-q with lower sco=
re */
> =A0 =A0 =A0 =A0 return ((other_inf->status & EXTRA_WANT_PEN_Q) &&
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (other_inf->score[EXTRA_PEN_Q] <
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0cur_inf->score[EXTRA_PEN_Q]));
> @@ -1096,18 +1044,11 @@ static void sedf_wake(const struct sched
> =A0 =A0 s_time_t =A0 =A0 =A0 =A0 =A0 =A0 =A0now =3D NOW();
> =A0 =A0 struct sedf_vcpu_info* inf =3D EDOM_INFO(d);
>
> - =A0 =A0PRINT(3, "sedf_wake was called, domain-id %i.%i\n",d->domain->do=
main_id,
> - =A0 =A0 =A0 =A0 =A0d->vcpu_id);
> -
> =A0 =A0 if ( unlikely(is_idle_vcpu(d)) )
> =A0 =A0 =A0 =A0 return;
>
> =A0 =A0 if ( unlikely(__task_on_queue(d)) )
> - =A0 =A0{
> - =A0 =A0 =A0 =A0PRINT(3,"\tdomain %i.%i is already in some queue\n",
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0d->domain->domain_id, d->vcpu_id);
> =A0 =A0 =A0 =A0 return;
> - =A0 =A0}
>
> =A0 =A0 ASSERT(!sedf_runnable(d));
> =A0 =A0 inf->status &=3D ~SEDF_ASLEEP;
> @@ -1116,28 +1057,24 @@ static void sedf_wake(const struct sched
>
> =A0 =A0 if ( unlikely(inf->deadl_abs =3D=3D 0) )
> =A0 =A0 {
> - =A0 =A0 =A0 =A0/*initial setup of the deadline*/
> + =A0 =A0 =A0 =A0/* Initial setup of the deadline */
> =A0 =A0 =A0 =A0 inf->deadl_abs =3D now + inf->slice;
> =A0 =A0 }
>
> - =A0 =A0PRINT(3, "waking up domain %i.%i (deadl=3D %"PRIu64" period=3D %=
"PRIu64
> - =A0 =A0 =A0 =A0 =A0"now=3D %"PRIu64")\n",
> - =A0 =A0 =A0 =A0 =A0d->domain->domain_id, d->vcpu_id, inf->deadl_abs, in=
f->period, now);
> -
> =A0#ifdef SEDF_STATS
> =A0 =A0 inf->block_tot++;
> =A0#endif
>
> =A0 =A0 if ( unlikely(now < PERIOD_BEGIN(inf)) )
> =A0 =A0 {
> - =A0 =A0 =A0 =A0PRINT(4,"extratime unblock\n");
> - =A0 =A0 =A0 =A0/* unblocking in extra-time! */
> + =A0 =A0 =A0 =A0/* Unblocking in extra-time! */
> =A0 =A0 =A0 =A0 if ( inf->status & EXTRA_WANT_PEN_Q )
> =A0 =A0 =A0 =A0 {
> - =A0 =A0 =A0 =A0 =A0 =A0/*we have a domain that wants compensation
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0for block penalty and did just block in
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0its compensation time. Give it another
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0chance!*/
> + =A0 =A0 =A0 =A0 =A0 =A0/* We have a domain that wants compensation
> + =A0 =A0 =A0 =A0 =A0 =A0 * for block penalty and did just block in
> + =A0 =A0 =A0 =A0 =A0 =A0 * its compensation time. Give it another
> + =A0 =A0 =A0 =A0 =A0 =A0 * chance!
> + =A0 =A0 =A0 =A0 =A0 =A0 */
> =A0 =A0 =A0 =A0 =A0 =A0 extraq_add_sort_update(d, EXTRA_PEN_Q, 0);
> =A0 =A0 =A0 =A0 }
> =A0 =A0 =A0 =A0 extraq_check_add_unblocked(d, 0);
> @@ -1146,8 +1083,7 @@ static void sedf_wake(const struct sched
> =A0 =A0 {
> =A0 =A0 =A0 =A0 if ( now < inf->deadl_abs )
> =A0 =A0 =A0 =A0 {
> - =A0 =A0 =A0 =A0 =A0 =A0PRINT(4,"short unblocking\n");
> - =A0 =A0 =A0 =A0 =A0 =A0/*short blocking*/
> + =A0 =A0 =A0 =A0 =A0 =A0/* Short blocking */
> =A0#ifdef SEDF_STATS
> =A0 =A0 =A0 =A0 =A0 =A0 inf->short_block_tot++;
> =A0#endif
> @@ -1157,8 +1093,7 @@ static void sedf_wake(const struct sched
> =A0 =A0 =A0 =A0 }
> =A0 =A0 =A0 =A0 else
> =A0 =A0 =A0 =A0 {
> - =A0 =A0 =A0 =A0 =A0 =A0PRINT(4,"long unblocking\n");
> - =A0 =A0 =A0 =A0 =A0 =A0/*long unblocking*/
> + =A0 =A0 =A0 =A0 =A0 =A0/* Long unblocking */
> =A0#ifdef SEDF_STATS
> =A0 =A0 =A0 =A0 =A0 =A0 inf->long_block_tot++;
> =A0#endif
> @@ -1168,24 +1103,13 @@ static void sedf_wake(const struct sched
> =A0 =A0 =A0 =A0 }
> =A0 =A0 }
>
> - =A0 =A0PRINT(3, "woke up domain %i.%i (deadl=3D %"PRIu64" period=3D %"P=
RIu64
> - =A0 =A0 =A0 =A0 =A0"now=3D %"PRIu64")\n",
> - =A0 =A0 =A0 =A0 =A0d->domain->domain_id, d->vcpu_id, inf->deadl_abs,
> - =A0 =A0 =A0 =A0 =A0inf->period, now);
> -
> =A0 =A0 if ( PERIOD_BEGIN(inf) > now )
> - =A0 =A0{
> =A0 =A0 =A0 =A0 __add_to_waitqueue_sort(d);
> - =A0 =A0 =A0 =A0PRINT(3,"added to waitq\n");
> - =A0 =A0}
> =A0 =A0 else
> - =A0 =A0{
> =A0 =A0 =A0 =A0 __add_to_runqueue_sort(d);
> - =A0 =A0 =A0 =A0PRINT(3,"added to runq\n");
> - =A0 =A0}
>
> =A0#ifdef SEDF_STATS
> - =A0 =A0/*do some statistics here...*/
> + =A0 =A0/* Do some statistics here... */
> =A0 =A0 if ( inf->block_abs !=3D 0 )
> =A0 =A0 {
> =A0 =A0 =A0 =A0 inf->block_time_tot +=3D now - inf->block_abs;
> @@ -1194,12 +1118,13 @@ static void sedf_wake(const struct sched
> =A0 =A0 }
> =A0#endif
>
> - =A0 =A0/*sanity check: make sure each extra-aware domain IS on the util=
-q!*/
> + =A0 =A0/* Sanity check: make sure each extra-aware domain IS on the uti=
l-q! */
> =A0 =A0 ASSERT(IMPLY(inf->status & EXTRA_AWARE, extraq_on(d, EXTRA_UTIL_Q=
)));
> =A0 =A0 ASSERT(__task_on_queue(d));
> - =A0 =A0/*check whether the awakened task needs to invoke the do_schedule
> - =A0 =A0 =A0routine. Try to avoid unnecessary runs but:
> - =A0 =A0 =A0Save approximation: Always switch to scheduler!*/
> + =A0 =A0/* Check whether the awakened task needs to invoke the do_schedu=
le
> + =A0 =A0 * routine. Try to avoid unnecessary runs but:
> + =A0 =A0 * Save approximation: Always switch to scheduler!
> + =A0 =A0 */
> =A0 =A0 ASSERT(d->processor >=3D 0);
> =A0 =A0 ASSERT(d->processor < nr_cpu_ids);
> =A0 =A0 ASSERT(per_cpu(schedule_data, d->processor).curr);
> @@ -1244,7 +1169,7 @@ static void sedf_dump_domain(struct vcpu
> =A0}
>
>
> -/* dumps all domains on the specified cpu */
> +/* Dumps all domains on the specified cpu */
> =A0static void sedf_dump_cpu_state(const struct scheduler *ops, int i)
> =A0{
> =A0 =A0 struct list_head =A0 =A0 =A0*list, *queue, *tmp;
> @@ -1319,7 +1244,7 @@ static void sedf_dump_cpu_state(const st
> =A0}
>
>
> -/* Adjusts periods and slices of the domains accordingly to their weight=
s. */
> +/* Adjusts periods and slices of the domains accordingly to their weight=
s */
> =A0static int sedf_adjust_weights(struct cpupool *c, struct xen_domctl_sc=
heduler_op *cmd)
> =A0{
> =A0 =A0 struct vcpu *p;
> @@ -1335,7 +1260,7 @@ static int sedf_adjust_weights(struct cp
> =A0 =A0 =A0 =A0 return -ENOMEM;
> =A0 =A0 }
>
> - =A0 =A0/* Sum across all weights. */
> + =A0 =A0/* Sum across all weights */
> =A0 =A0 rcu_read_lock(&domlist_read_lock);
> =A0 =A0 for_each_domain_in_cpupool( d, c )
> =A0 =A0 {
> @@ -1350,11 +1275,13 @@ static int sedf_adjust_weights(struct cp
> =A0 =A0 =A0 =A0 =A0 =A0 }
> =A0 =A0 =A0 =A0 =A0 =A0 else
> =A0 =A0 =A0 =A0 =A0 =A0 {
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/*don't modify domains who don't have a =
weight, but sum
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0up the time they need, projected to =
a WEIGHT_PERIOD,
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0so that this time is not given to th=
e weight-driven
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0domains*/
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/*check for overflows*/
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/* Don't modify domains who don't have a=
 weight, but sum
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 * up the time they need, projected to a=
 WEIGHT_PERIOD,
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 * so that this time is not given to the=
 weight-driven
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 * =A0domains
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 */
> +
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/* Check for overflows */
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ASSERT((WEIGHT_PERIOD < ULONG_MAX)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0&& (EDOM_INFO(p)->slice_or=
ig < ULONG_MAX));
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 sumt[cpu] +=3D
> @@ -1365,7 +1292,7 @@ static int sedf_adjust_weights(struct cp
> =A0 =A0 }
> =A0 =A0 rcu_read_unlock(&domlist_read_lock);
>
> - =A0 =A0/* Adjust all slices (and periods) to the new weight. */
> + =A0 =A0/* Adjust all slices (and periods) to the new weight */
> =A0 =A0 rcu_read_lock(&domlist_read_lock);
> =A0 =A0 for_each_domain_in_cpupool( d, c )
> =A0 =A0 {
> @@ -1393,20 +1320,15 @@ static int sedf_adjust_weights(struct cp
> =A0}
>
>
> -/* set or fetch domain scheduling parameters */
> +/* Set or fetch domain scheduling parameters */
> =A0static int sedf_adjust(const struct scheduler *ops, struct domain *p, =
struct xen_domctl_scheduler_op *op)
> =A0{
> =A0 =A0 struct vcpu *v;
> =A0 =A0 int rc;
>
> - =A0 =A0PRINT(2,"sedf_adjust was called, domain-id %i new period %"PRIu6=
4" "
> - =A0 =A0 =A0 =A0 =A0"new slice %"PRIu64"\nlatency %"PRIu64" extra:%s\n",
> - =A0 =A0 =A0 =A0 =A0p->domain_id, op->u.sedf.period, op->u.sedf.slice,
> - =A0 =A0 =A0 =A0 =A0op->u.sedf.latency, (op->u.sedf.extratime)?"yes":"no=
");
> -
> =A0 =A0 if ( op->cmd =3D=3D XEN_DOMCTL_SCHEDOP_putinfo )
> =A0 =A0 {
> - =A0 =A0 =A0 =A0/* Check for sane parameters. */
> + =A0 =A0 =A0 =A0/* Check for sane parameters */
> =A0 =A0 =A0 =A0 if ( !op->u.sedf.period && !op->u.sedf.weight )
> =A0 =A0 =A0 =A0 =A0 =A0 return -EINVAL;
> =A0 =A0 =A0 =A0 if ( op->u.sedf.weight )
> @@ -1414,7 +1336,7 @@ static int sedf_adjust(const struct sche
> =A0 =A0 =A0 =A0 =A0 =A0 if ( (op->u.sedf.extratime & EXTRA_AWARE) &&
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(!op->u.sedf.period) )
> =A0 =A0 =A0 =A0 =A0 =A0 {
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/* Weight-driven domains with extratime =
only. */
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/* Weight-driven domains with extratime =
only */
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 for_each_vcpu ( p, v )
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 {
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 EDOM_INFO(v)->extraweight =3D op-=
>u.sedf.weight;
> @@ -1425,7 +1347,7 @@ static int sedf_adjust(const struct sche
> =A0 =A0 =A0 =A0 =A0 =A0 }
> =A0 =A0 =A0 =A0 =A0 =A0 else
> =A0 =A0 =A0 =A0 =A0 =A0 {
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/* Weight-driven domains with real-time =
execution. */
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/* Weight-driven domains with real-time =
execution */
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 for_each_vcpu ( p, v )
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 EDOM_INFO(v)->weight =3D op->u.se=
df.weight;
> =A0 =A0 =A0 =A0 =A0 =A0 }
> @@ -1435,8 +1357,7 @@ static int sedf_adjust(const struct sche
> =A0 =A0 =A0 =A0 =A0 =A0 /* Time-driven domains. */
> =A0 =A0 =A0 =A0 =A0 =A0 for_each_vcpu ( p, v )
> =A0 =A0 =A0 =A0 =A0 =A0 {
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/*
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 * Sanity checking: note that disabling =
extra weight requires
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/* Sanity checking: note that disabling =
extra weight requires
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* that we set a non-zero slice.
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0*/
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if ( (op->u.sedf.period > PERIOD_MAX) ||
> @@ -1477,7 +1398,6 @@ static int sedf_adjust(const struct sche
> =A0 =A0 =A0 =A0 op->u.sedf.weight =A0 =A0=3D EDOM_INFO(p->vcpu[0])->weigh=
t;
> =A0 =A0 }
>
> - =A0 =A0PRINT(2,"sedf_adjust_finished\n");
> =A0 =A0 return 0;
> =A0}
>
>
> --
> <<This happens because I choose it to happen!>> (Raistlin Majere)
> -------------------------------------------------------------------
> Dario Faggioli, http://retis.sssup.it/people/faggioli
> Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
> PhD Candidate, ReTiS Lab, Scuola Superiore Sant'Anna, Pisa (Italy)
>
>
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 21 12:27:03 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 12:27:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdLG0-0005FL-Ua; Wed, 21 Dec 2011 12:26:52 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RdLFz-0005El-Io
	for xen-devel@lists.xensource.com; Wed, 21 Dec 2011 12:26:51 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1324470404!1631330!1
X-Originating-IP: [209.85.216.50]
X-SpamReason: No, hits=1.4 required=7.0 tests=DATE_IN_PAST_24_48,
	MAILTO_TO_SPAM_ADDR,RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16187 invoked from network); 21 Dec 2011 12:26:45 -0000
Received: from mail-qw0-f50.google.com (HELO mail-qw0-f50.google.com)
	(209.85.216.50)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Dec 2011 12:26:45 -0000
Received: by qaea17 with SMTP id a17so30986616qae.9
	for <xen-devel@lists.xensource.com>;
	Wed, 21 Dec 2011 04:26:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:user-agent:date:from:to;
	bh=ac5Hz1475YSvU0MmAX3rdiF4COyHaY11qK1phHPKA3o=;
	b=f49DACqwzb1C8/1Mo5tgZGb4l0V27HSsu5n1KkiDnAg+j/NFLnc7y/xjVLtob4GE1N
	wrFKd3fM62/kIT3gpsgJnenu0lKtH9qONLAt4E3LfdX+JdHqcoi0vPDetdJZzxoKn45K
	5edpAf3KXtdgUy4iflw2knvBhwVnSRVa7OMKA=
Received: by 10.224.100.71 with SMTP id x7mr7986369qan.33.1324470403238;
	Wed, 21 Dec 2011 04:26:43 -0800 (PST)
Received: from alpine.localdomain (tina.upc.es. [147.83.39.243])
	by mx.google.com with ESMTPS id h9sm10356121qac.13.2011.12.21.04.26.41
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 21 Dec 2011 04:26:42 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: d61e6300274bbc6bc464ad340146bd81e91f64f3
Message-Id: <d61e6300274bbc6bc464.1324354898@alpine.localdomain>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Tue, 20 Dec 2011 05:21:38 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH] ipxe: update to upstream version
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1324354802 -3600
# Node ID d61e6300274bbc6bc464ad340146bd81e91f64f3
# Parent  03138a08366b895d79e143119d4c9c72833cdbcd
ipxe: update to upstream version

Updated ipxe to current tree, which is
540e5960dc6b49eacf367f7c319fd0546474b845:

Provide PXENV_FILE_EXIT_HOOK only for ipxelinux.0 builds

Removed all the backported patches and updated
boot_prompt_option.patch to apply against current ipxe.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 03138a08366b -r d61e6300274b tools/firmware/etherboot/Makefile
--- a/tools/firmware/etherboot/Makefile	Fri Dec 09 16:19:36 2011 +0000
+++ b/tools/firmware/etherboot/Makefile	Tue Dec 20 05:20:02 2011 +0100
@@ -10,9 +10,7 @@ else
 IPXE_GIT_URL := git://git.ipxe.org/ipxe.git
 endif
 
-IPXE_GIT_TAG := v1.0.0
-
-IPXE_TARBALL_URL := $(XEN_EXTFILES_URL)/ipxe-git-$(IPXE_GIT_TAG).tar.gz
+IPXE_GIT_TREE := 540e5960dc6b49eacf367f7c319fd0546474b845
 
 D=ipxe
 T=ipxe.tar.gz
@@ -35,12 +33,10 @@ eb-roms.h: Config
 	mv -f $@.new $@
 
 $T:
-	if ! wget -O _$T $(IPXE_TARBALL_URL); then \
-		$(GIT) clone $(IPXE_GIT_URL) $D.git; \
-		(cd $D.git && $(GIT) archive --format=tar --prefix=$D/ \
-		$(IPXE_GIT_TAG) | gzip >../_$T); \
-		rm -rf $D.git; \
-	fi
+	$(GIT) clone $(IPXE_GIT_URL) $D.git; \
+	(cd $D.git && $(GIT) archive --format=tar --prefix=$D/ \
+	$(IPXE_GIT_TREE) | gzip >../_$T); \
+	rm -rf $D.git; \
 	mv _$T $T
 
 $D/src/arch/i386/Makefile: $T Config
diff -r 03138a08366b -r d61e6300274b tools/firmware/etherboot/patches/boot_prompt_option.patch
--- a/tools/firmware/etherboot/patches/boot_prompt_option.patch	Fri Dec 09 16:19:36 2011 +0000
+++ b/tools/firmware/etherboot/patches/boot_prompt_option.patch	Tue Dec 20 05:20:02 2011 +0100
@@ -1,7 +1,8 @@
-diff -pruN gpxe/src/arch/i386/prefix/romprefix.S gpxe.new/src/arch/i386/prefix/romprefix.S
---- gpxe/src/arch/i386/prefix/romprefix.S	2010-06-29 20:31:33.000000000 +0100
-+++ gpxe.new/src/arch/i386/prefix/romprefix.S	2010-07-20 10:40:20.000000000 +0100
-@@ -458,6 +458,7 @@ no_pmm:
+diff --git a/src/arch/i386/prefix/romprefix.S b/src/arch/i386/prefix/romprefix.S
+index 0f92415..cce7505 100644
+--- a/src/arch/i386/prefix/romprefix.S
++++ b/src/arch/i386/prefix/romprefix.S
+@@ -391,6 +391,7 @@ no_pmm:
  	xorw	%di, %di
  	cs rep	movsb
  
@@ -9,15 +10,15 @@ diff -pruN gpxe/src/arch/i386/prefix/rom
  	/* Prompt for POST-time shell */
  	movw	$init_message_prompt, %si
  	xorw	%di, %di
-@@ -484,6 +485,7 @@ no_pmm:
+@@ -418,6 +419,7 @@ no_pmm:
  	pushw	%cs
  	call	exec
- out:
+ 2:
 +#endif
  	/* Restore registers */
  	popw	%gs
  	popw	%fs
-@@ -538,6 +540,7 @@ init_message_no_pmm:
+@@ -546,6 +548,7 @@ init_message_pmm:
  init_message_int19:
  	.asciz	" INT19"
  	.size	init_message_int19, . - init_message_int19
@@ -25,11 +26,11 @@ diff -pruN gpxe/src/arch/i386/prefix/rom
  init_message_prompt:
  	.asciz	"\nPress Ctrl-B to configure "
  	.size	init_message_prompt, . - init_message_prompt
-@@ -547,6 +550,7 @@ init_message_dots:
+@@ -555,6 +558,7 @@ init_message_dots:
  init_message_done:
  	.asciz	"\n\n"
  	.size	init_message_done, . - init_message_done
 +#endif
  
- /* ROM image location
+ /* PCI bus:dev.fn
   *
diff -r 03138a08366b -r d61e6300274b tools/firmware/etherboot/patches/gpxe-git-0edf2405b457
--- a/tools/firmware/etherboot/patches/gpxe-git-0edf2405b457	Fri Dec 09 16:19:36 2011 +0000
+++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
@@ -1,30 +0,0 @@
-commit 0edf2405b457e542c244a72285511b3ff5c06885
-Author: Michael Brown <mcb30@ipxe.org>
-Date:   Tue Apr 27 09:52:22 2010 +0100
-
-    [build] Fix building with binutils 2.16
-    
-    Signed-off-by: Michael Brown <mcb30@ipxe.org>
-    Signed-off-by: Stefan Hajnoczi <stefanha@gmail.com>
-
-diff --git a/src/arch/i386/scripts/i386.lds b/src/arch/i386/scripts/i386.lds
-index 278a397..0ce2c10 100644
---- a/src/arch/i386/scripts/i386.lds
-+++ b/src/arch/i386/scripts/i386.lds
-@@ -24,6 +24,8 @@ SECTIONS {
-      *
-      */
- 
-+    PROVIDE ( _max_align = 16 );
-+
-     /*
-      * The prefix
-      *
-@@ -169,7 +171,6 @@ SECTIONS {
-      *
-      */
- 
--    PROVIDE ( _max_align = 16 );
-     .			= 0;
- 
-     .			= ALIGN ( _max_align );
diff -r 03138a08366b -r d61e6300274b tools/firmware/etherboot/patches/gpxe-git-a803ef3dfeac
--- a/tools/firmware/etherboot/patches/gpxe-git-a803ef3dfeac	Fri Dec 09 16:19:36 2011 +0000
+++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
@@ -1,125 +0,0 @@
-commit a803ef3dfeac4e8aa35810bba65f9ccab0bdf264
-Author: Michael Brown <mcb30@ipxe.org>
-Date:   Thu Jun 24 01:23:00 2010 +0100
-
-    [build] Avoid hard-coding the path to perl
-    
-    The path "/usr/bin/perl" has been hard-coded since Etherboot 5.1, for
-    no discernible reason.  Use just "perl" instead to fix the
-    inconsistency and allow building on systems with Perl installed
-    outside of /usr/bin.
-    
-    This commit also includes a later fix that removes a dependency on
-    "perl" which broke builds from fully clean trees.
-    
-    Reported-by: Gabor Z. Papp <gzp@papp.hu>
-    Signed-off-by: Michael Brown <mcb30@ipxe.org>
-    Signed-off-by: Stefan Hajnoczi <stefanha@gmail.com>
-
-diff -pruN a/src/arch/i386/Makefile.pcbios b/src/arch/i386/Makefile.pcbios
---- a/src/arch/i386/Makefile.pcbios	2010-06-29 20:31:33.000000000 +0100
-+++ b/src/arch/i386/Makefile.pcbios	2010-07-20 16:07:06.000000000 +0100
-@@ -24,11 +24,11 @@ MEDIA		+= raw
- 
- # Padding rules
- #
--PAD_rom		= $(PADIMG) --blksize=512 --byte=0xff $@
-+PAD_rom		= $(PERL) $(PADIMG) --blksize=512 --byte=0xff $@
- PAD_hrom	= $(PAD_rom)
- PAD_xrom	= $(PAD_rom)
--PAD_dsk		= $(PADIMG) --blksize=512 $@
--PAD_hd		= $(PADIMG) --blksize=32768 $@
-+PAD_dsk		= $(PERL) $(PADIMG) --blksize=512 $@
-+PAD_hd		= $(PERL) $(PADIMG) --blksize=32768 $@
- 
- # rule to make a non-emulation ISO boot image
- NON_AUTO_MEDIA	+= iso
-@@ -67,4 +67,4 @@ NON_AUTO_MEDIA	+= usb
- NON_AUTO_MEDIA += pdsk
- %pdsk : %dsk
- 	$(Q)cp $< $@
--	$(Q)$(PADIMG) --blksize=1474560 $@
-+	$(Q)$(PERL) $(PADIMG) --blksize=1474560 $@
-diff -pruN a/src/Makefile b/src/Makefile
---- a/src/Makefile	2010-06-29 20:31:33.000000000 +0100
-+++ b/src/Makefile	2010-07-20 16:02:56.000000000 +0100
-@@ -20,7 +20,7 @@ MKDIR		:= mkdir
- CP		:= cp
- ECHO		:= echo
- PRINTF		:= printf
--PERL		:= /usr/bin/perl
-+PERL		:= perl
- CC		:= $(CROSS_COMPILE)gcc
- CPP		:= $(CC) -E
- AS		:= $(CROSS_COMPILE)as
-@@ -31,12 +31,12 @@ RANLIB		:= $(CROSS_COMPILE)ranlib
- OBJCOPY		:= $(CROSS_COMPILE)objcopy
- NM		:= $(CROSS_COMPILE)nm
- OBJDUMP		:= $(CROSS_COMPILE)objdump
--PARSEROM	:= $(PERL) ./util/parserom.pl
--MAKEROM		:= $(PERL) ./util/makerom.pl
--SYMCHECK	:= $(PERL) ./util/symcheck.pl
--SORTOBJDUMP	:= $(PERL) ./util/sortobjdump.pl
--PADIMG		:= $(PERL) ./util/padimg.pl
--LICENCE		:= $(PERL) ./util/licence.pl
-+PARSEROM	:= ./util/parserom.pl
-+MAKEROM		:= ./util/makerom.pl
-+SYMCHECK	:= ./util/symcheck.pl
-+SORTOBJDUMP	:= ./util/sortobjdump.pl
-+PADIMG		:= ./util/padimg.pl
-+LICENCE		:= ./util/licence.pl
- NRV2B		:= ./util/nrv2b
- ZBIN		:= ./util/zbin
- ELF2EFI32	:= ./util/elf2efi32
-diff -pruN a/src/Makefile.housekeeping b/src/Makefile.housekeeping
---- a/src/Makefile.housekeeping	2010-06-29 20:31:33.000000000 +0100
-+++ b/src/Makefile.housekeeping	2010-07-20 16:04:42.000000000 +0100
-@@ -486,7 +486,7 @@ define src_template
- 		 '\n$(2) : $$($(4)_DEPS)\n' \
- 		 '\nTAGS : $$($(4)_DEPS)\n' \
- 		>> $(2)
--	@$(PARSEROM) $(1) >> $(2)
-+	@$(PERL) $(PARSEROM) $(1) >> $(2)
- 
- endef
- 
-@@ -695,7 +695,7 @@ $(BIN)/%.tmp : $(BLIB) $(MAKEDEPS) $(LDS
- 	$(QM)$(ECHO) "  [LD] $@"
- 	$(Q)$(LD) $(LDFLAGS) -T $(LDSCRIPT) $(TGT_LD_FLAGS) $(BLIB) -o $@ \
- 		-Map $(BIN)/$*.tmp.map
--	$(Q)$(OBJDUMP) -ht $@ | $(SORTOBJDUMP) >> $(BIN)/$*.tmp.map
-+	$(Q)$(OBJDUMP) -ht $@ | $(PERL) $(SORTOBJDUMP) >> $(BIN)/$*.tmp.map
- 
- # Keep intermediate object file (useful for debugging)
- .PRECIOUS : $(BIN)/%.tmp
-@@ -752,7 +752,7 @@ $(BIN)/%.licence : $(BIN)/%.tmp
- 		echo "files are missing a licence declaration:" ;\
- 		echo $(call unlicensed_deps_list,$<);\
- 		exit 1,\
--		$(LICENCE) $(call licence_list,$<))
-+		$(PERL) $(LICENCE) $(call licence_list,$<))
- 
- # Extract compression information from intermediate object file
- #
-@@ -866,10 +866,10 @@ endif # defined(BIN)
- # the automatic build system and varies by target; it includes the
- # "-p 0x1234,0x5678" string to set the PCI IDs.
- #
--FINALISE_rom	= $(MAKEROM) $(MAKEROM_FLAGS) $(TGT_MAKEROM_FLAGS) \
-+FINALISE_rom	= $(PERL) $(MAKEROM) $(MAKEROM_FLAGS) $(TGT_MAKEROM_FLAGS) \
- 		  -i$(IDENT) -s 0 $@
- FINALISE_hrom	= $(FINALISE_rom)
--FINALISE_xrom	= $(MAKEROM) $(MAKEROM_FLAGS) $(TGT_MAKEROM_FLAGS) \
-+FINALISE_xrom	= $(PERL) $(MAKEROM) $(MAKEROM_FLAGS) $(TGT_MAKEROM_FLAGS) \
- 		  -i$(IDENT) -n -s 0 $@
- 
- # Some ROMs require specific flags to be passed to makerom.pl
-@@ -987,7 +987,7 @@ $(SYMTAB) : $(BLIB)
- CLEANUP	+= $(BIN)/symtab
- 
- symcheck : $(SYMTAB)
--	$(SYMCHECK) $<
-+	$(PERL) $(SYMCHECK) $<
- 
- endif # defined(BIN)
- 
diff -r 03138a08366b -r d61e6300274b tools/firmware/etherboot/patches/series
--- a/tools/firmware/etherboot/patches/series	Fri Dec 09 16:19:36 2011 +0000
+++ b/tools/firmware/etherboot/patches/series	Tue Dec 20 05:20:02 2011 +0100
@@ -1,3 +1,1 @@
 boot_prompt_option.patch
-gpxe-git-0edf2405b457
-gpxe-git-a803ef3dfeac

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 21 12:27:03 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 12:27:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdLG0-0005FL-Ua; Wed, 21 Dec 2011 12:26:52 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RdLFz-0005El-Io
	for xen-devel@lists.xensource.com; Wed, 21 Dec 2011 12:26:51 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1324470404!1631330!1
X-Originating-IP: [209.85.216.50]
X-SpamReason: No, hits=1.4 required=7.0 tests=DATE_IN_PAST_24_48,
	MAILTO_TO_SPAM_ADDR,RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16187 invoked from network); 21 Dec 2011 12:26:45 -0000
Received: from mail-qw0-f50.google.com (HELO mail-qw0-f50.google.com)
	(209.85.216.50)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Dec 2011 12:26:45 -0000
Received: by qaea17 with SMTP id a17so30986616qae.9
	for <xen-devel@lists.xensource.com>;
	Wed, 21 Dec 2011 04:26:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:user-agent:date:from:to;
	bh=ac5Hz1475YSvU0MmAX3rdiF4COyHaY11qK1phHPKA3o=;
	b=f49DACqwzb1C8/1Mo5tgZGb4l0V27HSsu5n1KkiDnAg+j/NFLnc7y/xjVLtob4GE1N
	wrFKd3fM62/kIT3gpsgJnenu0lKtH9qONLAt4E3LfdX+JdHqcoi0vPDetdJZzxoKn45K
	5edpAf3KXtdgUy4iflw2knvBhwVnSRVa7OMKA=
Received: by 10.224.100.71 with SMTP id x7mr7986369qan.33.1324470403238;
	Wed, 21 Dec 2011 04:26:43 -0800 (PST)
Received: from alpine.localdomain (tina.upc.es. [147.83.39.243])
	by mx.google.com with ESMTPS id h9sm10356121qac.13.2011.12.21.04.26.41
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 21 Dec 2011 04:26:42 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: d61e6300274bbc6bc464ad340146bd81e91f64f3
Message-Id: <d61e6300274bbc6bc464.1324354898@alpine.localdomain>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Tue, 20 Dec 2011 05:21:38 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH] ipxe: update to upstream version
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1324354802 -3600
# Node ID d61e6300274bbc6bc464ad340146bd81e91f64f3
# Parent  03138a08366b895d79e143119d4c9c72833cdbcd
ipxe: update to upstream version

Updated ipxe to current tree, which is
540e5960dc6b49eacf367f7c319fd0546474b845:

Provide PXENV_FILE_EXIT_HOOK only for ipxelinux.0 builds

Removed all the backported patches and updated
boot_prompt_option.patch to apply against current ipxe.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 03138a08366b -r d61e6300274b tools/firmware/etherboot/Makefile
--- a/tools/firmware/etherboot/Makefile	Fri Dec 09 16:19:36 2011 +0000
+++ b/tools/firmware/etherboot/Makefile	Tue Dec 20 05:20:02 2011 +0100
@@ -10,9 +10,7 @@ else
 IPXE_GIT_URL := git://git.ipxe.org/ipxe.git
 endif
 
-IPXE_GIT_TAG := v1.0.0
-
-IPXE_TARBALL_URL := $(XEN_EXTFILES_URL)/ipxe-git-$(IPXE_GIT_TAG).tar.gz
+IPXE_GIT_TREE := 540e5960dc6b49eacf367f7c319fd0546474b845
 
 D=ipxe
 T=ipxe.tar.gz
@@ -35,12 +33,10 @@ eb-roms.h: Config
 	mv -f $@.new $@
 
 $T:
-	if ! wget -O _$T $(IPXE_TARBALL_URL); then \
-		$(GIT) clone $(IPXE_GIT_URL) $D.git; \
-		(cd $D.git && $(GIT) archive --format=tar --prefix=$D/ \
-		$(IPXE_GIT_TAG) | gzip >../_$T); \
-		rm -rf $D.git; \
-	fi
+	$(GIT) clone $(IPXE_GIT_URL) $D.git; \
+	(cd $D.git && $(GIT) archive --format=tar --prefix=$D/ \
+	$(IPXE_GIT_TREE) | gzip >../_$T); \
+	rm -rf $D.git; \
 	mv _$T $T
 
 $D/src/arch/i386/Makefile: $T Config
diff -r 03138a08366b -r d61e6300274b tools/firmware/etherboot/patches/boot_prompt_option.patch
--- a/tools/firmware/etherboot/patches/boot_prompt_option.patch	Fri Dec 09 16:19:36 2011 +0000
+++ b/tools/firmware/etherboot/patches/boot_prompt_option.patch	Tue Dec 20 05:20:02 2011 +0100
@@ -1,7 +1,8 @@
-diff -pruN gpxe/src/arch/i386/prefix/romprefix.S gpxe.new/src/arch/i386/prefix/romprefix.S
---- gpxe/src/arch/i386/prefix/romprefix.S	2010-06-29 20:31:33.000000000 +0100
-+++ gpxe.new/src/arch/i386/prefix/romprefix.S	2010-07-20 10:40:20.000000000 +0100
-@@ -458,6 +458,7 @@ no_pmm:
+diff --git a/src/arch/i386/prefix/romprefix.S b/src/arch/i386/prefix/romprefix.S
+index 0f92415..cce7505 100644
+--- a/src/arch/i386/prefix/romprefix.S
++++ b/src/arch/i386/prefix/romprefix.S
+@@ -391,6 +391,7 @@ no_pmm:
  	xorw	%di, %di
  	cs rep	movsb
  
@@ -9,15 +10,15 @@ diff -pruN gpxe/src/arch/i386/prefix/rom
  	/* Prompt for POST-time shell */
  	movw	$init_message_prompt, %si
  	xorw	%di, %di
-@@ -484,6 +485,7 @@ no_pmm:
+@@ -418,6 +419,7 @@ no_pmm:
  	pushw	%cs
  	call	exec
- out:
+ 2:
 +#endif
  	/* Restore registers */
  	popw	%gs
  	popw	%fs
-@@ -538,6 +540,7 @@ init_message_no_pmm:
+@@ -546,6 +548,7 @@ init_message_pmm:
  init_message_int19:
  	.asciz	" INT19"
  	.size	init_message_int19, . - init_message_int19
@@ -25,11 +26,11 @@ diff -pruN gpxe/src/arch/i386/prefix/rom
  init_message_prompt:
  	.asciz	"\nPress Ctrl-B to configure "
  	.size	init_message_prompt, . - init_message_prompt
-@@ -547,6 +550,7 @@ init_message_dots:
+@@ -555,6 +558,7 @@ init_message_dots:
  init_message_done:
  	.asciz	"\n\n"
  	.size	init_message_done, . - init_message_done
 +#endif
  
- /* ROM image location
+ /* PCI bus:dev.fn
   *
diff -r 03138a08366b -r d61e6300274b tools/firmware/etherboot/patches/gpxe-git-0edf2405b457
--- a/tools/firmware/etherboot/patches/gpxe-git-0edf2405b457	Fri Dec 09 16:19:36 2011 +0000
+++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
@@ -1,30 +0,0 @@
-commit 0edf2405b457e542c244a72285511b3ff5c06885
-Author: Michael Brown <mcb30@ipxe.org>
-Date:   Tue Apr 27 09:52:22 2010 +0100
-
-    [build] Fix building with binutils 2.16
-    
-    Signed-off-by: Michael Brown <mcb30@ipxe.org>
-    Signed-off-by: Stefan Hajnoczi <stefanha@gmail.com>
-
-diff --git a/src/arch/i386/scripts/i386.lds b/src/arch/i386/scripts/i386.lds
-index 278a397..0ce2c10 100644
---- a/src/arch/i386/scripts/i386.lds
-+++ b/src/arch/i386/scripts/i386.lds
-@@ -24,6 +24,8 @@ SECTIONS {
-      *
-      */
- 
-+    PROVIDE ( _max_align = 16 );
-+
-     /*
-      * The prefix
-      *
-@@ -169,7 +171,6 @@ SECTIONS {
-      *
-      */
- 
--    PROVIDE ( _max_align = 16 );
-     .			= 0;
- 
-     .			= ALIGN ( _max_align );
diff -r 03138a08366b -r d61e6300274b tools/firmware/etherboot/patches/gpxe-git-a803ef3dfeac
--- a/tools/firmware/etherboot/patches/gpxe-git-a803ef3dfeac	Fri Dec 09 16:19:36 2011 +0000
+++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
@@ -1,125 +0,0 @@
-commit a803ef3dfeac4e8aa35810bba65f9ccab0bdf264
-Author: Michael Brown <mcb30@ipxe.org>
-Date:   Thu Jun 24 01:23:00 2010 +0100
-
-    [build] Avoid hard-coding the path to perl
-    
-    The path "/usr/bin/perl" has been hard-coded since Etherboot 5.1, for
-    no discernible reason.  Use just "perl" instead to fix the
-    inconsistency and allow building on systems with Perl installed
-    outside of /usr/bin.
-    
-    This commit also includes a later fix that removes a dependency on
-    "perl" which broke builds from fully clean trees.
-    
-    Reported-by: Gabor Z. Papp <gzp@papp.hu>
-    Signed-off-by: Michael Brown <mcb30@ipxe.org>
-    Signed-off-by: Stefan Hajnoczi <stefanha@gmail.com>
-
-diff -pruN a/src/arch/i386/Makefile.pcbios b/src/arch/i386/Makefile.pcbios
---- a/src/arch/i386/Makefile.pcbios	2010-06-29 20:31:33.000000000 +0100
-+++ b/src/arch/i386/Makefile.pcbios	2010-07-20 16:07:06.000000000 +0100
-@@ -24,11 +24,11 @@ MEDIA		+= raw
- 
- # Padding rules
- #
--PAD_rom		= $(PADIMG) --blksize=512 --byte=0xff $@
-+PAD_rom		= $(PERL) $(PADIMG) --blksize=512 --byte=0xff $@
- PAD_hrom	= $(PAD_rom)
- PAD_xrom	= $(PAD_rom)
--PAD_dsk		= $(PADIMG) --blksize=512 $@
--PAD_hd		= $(PADIMG) --blksize=32768 $@
-+PAD_dsk		= $(PERL) $(PADIMG) --blksize=512 $@
-+PAD_hd		= $(PERL) $(PADIMG) --blksize=32768 $@
- 
- # rule to make a non-emulation ISO boot image
- NON_AUTO_MEDIA	+= iso
-@@ -67,4 +67,4 @@ NON_AUTO_MEDIA	+= usb
- NON_AUTO_MEDIA += pdsk
- %pdsk : %dsk
- 	$(Q)cp $< $@
--	$(Q)$(PADIMG) --blksize=1474560 $@
-+	$(Q)$(PERL) $(PADIMG) --blksize=1474560 $@
-diff -pruN a/src/Makefile b/src/Makefile
---- a/src/Makefile	2010-06-29 20:31:33.000000000 +0100
-+++ b/src/Makefile	2010-07-20 16:02:56.000000000 +0100
-@@ -20,7 +20,7 @@ MKDIR		:= mkdir
- CP		:= cp
- ECHO		:= echo
- PRINTF		:= printf
--PERL		:= /usr/bin/perl
-+PERL		:= perl
- CC		:= $(CROSS_COMPILE)gcc
- CPP		:= $(CC) -E
- AS		:= $(CROSS_COMPILE)as
-@@ -31,12 +31,12 @@ RANLIB		:= $(CROSS_COMPILE)ranlib
- OBJCOPY		:= $(CROSS_COMPILE)objcopy
- NM		:= $(CROSS_COMPILE)nm
- OBJDUMP		:= $(CROSS_COMPILE)objdump
--PARSEROM	:= $(PERL) ./util/parserom.pl
--MAKEROM		:= $(PERL) ./util/makerom.pl
--SYMCHECK	:= $(PERL) ./util/symcheck.pl
--SORTOBJDUMP	:= $(PERL) ./util/sortobjdump.pl
--PADIMG		:= $(PERL) ./util/padimg.pl
--LICENCE		:= $(PERL) ./util/licence.pl
-+PARSEROM	:= ./util/parserom.pl
-+MAKEROM		:= ./util/makerom.pl
-+SYMCHECK	:= ./util/symcheck.pl
-+SORTOBJDUMP	:= ./util/sortobjdump.pl
-+PADIMG		:= ./util/padimg.pl
-+LICENCE		:= ./util/licence.pl
- NRV2B		:= ./util/nrv2b
- ZBIN		:= ./util/zbin
- ELF2EFI32	:= ./util/elf2efi32
-diff -pruN a/src/Makefile.housekeeping b/src/Makefile.housekeeping
---- a/src/Makefile.housekeeping	2010-06-29 20:31:33.000000000 +0100
-+++ b/src/Makefile.housekeeping	2010-07-20 16:04:42.000000000 +0100
-@@ -486,7 +486,7 @@ define src_template
- 		 '\n$(2) : $$($(4)_DEPS)\n' \
- 		 '\nTAGS : $$($(4)_DEPS)\n' \
- 		>> $(2)
--	@$(PARSEROM) $(1) >> $(2)
-+	@$(PERL) $(PARSEROM) $(1) >> $(2)
- 
- endef
- 
-@@ -695,7 +695,7 @@ $(BIN)/%.tmp : $(BLIB) $(MAKEDEPS) $(LDS
- 	$(QM)$(ECHO) "  [LD] $@"
- 	$(Q)$(LD) $(LDFLAGS) -T $(LDSCRIPT) $(TGT_LD_FLAGS) $(BLIB) -o $@ \
- 		-Map $(BIN)/$*.tmp.map
--	$(Q)$(OBJDUMP) -ht $@ | $(SORTOBJDUMP) >> $(BIN)/$*.tmp.map
-+	$(Q)$(OBJDUMP) -ht $@ | $(PERL) $(SORTOBJDUMP) >> $(BIN)/$*.tmp.map
- 
- # Keep intermediate object file (useful for debugging)
- .PRECIOUS : $(BIN)/%.tmp
-@@ -752,7 +752,7 @@ $(BIN)/%.licence : $(BIN)/%.tmp
- 		echo "files are missing a licence declaration:" ;\
- 		echo $(call unlicensed_deps_list,$<);\
- 		exit 1,\
--		$(LICENCE) $(call licence_list,$<))
-+		$(PERL) $(LICENCE) $(call licence_list,$<))
- 
- # Extract compression information from intermediate object file
- #
-@@ -866,10 +866,10 @@ endif # defined(BIN)
- # the automatic build system and varies by target; it includes the
- # "-p 0x1234,0x5678" string to set the PCI IDs.
- #
--FINALISE_rom	= $(MAKEROM) $(MAKEROM_FLAGS) $(TGT_MAKEROM_FLAGS) \
-+FINALISE_rom	= $(PERL) $(MAKEROM) $(MAKEROM_FLAGS) $(TGT_MAKEROM_FLAGS) \
- 		  -i$(IDENT) -s 0 $@
- FINALISE_hrom	= $(FINALISE_rom)
--FINALISE_xrom	= $(MAKEROM) $(MAKEROM_FLAGS) $(TGT_MAKEROM_FLAGS) \
-+FINALISE_xrom	= $(PERL) $(MAKEROM) $(MAKEROM_FLAGS) $(TGT_MAKEROM_FLAGS) \
- 		  -i$(IDENT) -n -s 0 $@
- 
- # Some ROMs require specific flags to be passed to makerom.pl
-@@ -987,7 +987,7 @@ $(SYMTAB) : $(BLIB)
- CLEANUP	+= $(BIN)/symtab
- 
- symcheck : $(SYMTAB)
--	$(SYMCHECK) $<
-+	$(PERL) $(SYMCHECK) $<
- 
- endif # defined(BIN)
- 
diff -r 03138a08366b -r d61e6300274b tools/firmware/etherboot/patches/series
--- a/tools/firmware/etherboot/patches/series	Fri Dec 09 16:19:36 2011 +0000
+++ b/tools/firmware/etherboot/patches/series	Tue Dec 20 05:20:02 2011 +0100
@@ -1,3 +1,1 @@
 boot_prompt_option.patch
-gpxe-git-0edf2405b457
-gpxe-git-a803ef3dfeac

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 21 12:30:07 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 12:30:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdLIy-0005QM-IE; Wed, 21 Dec 2011 12:29:56 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <gang.wei@intel.com>) id 1RdLIw-0005PZ-LD
	for xen-devel@lists.xensource.com; Wed, 21 Dec 2011 12:29:54 +0000
X-Env-Sender: gang.wei@intel.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1324470587!8130564!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMjg5NzA2\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5327 invoked from network); 21 Dec 2011 12:29:48 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-9.tower-182.messagelabs.com with SMTP;
	21 Dec 2011 12:29:48 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga101.jf.intel.com with ESMTP; 21 Dec 2011 04:29:47 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.67,351,1309762800"; d="scan'208";a="89949857"
Received: from pgsmsx603.gar.corp.intel.com ([10.221.43.87])
	by orsmga002.jf.intel.com with ESMTP; 21 Dec 2011 04:29:45 -0800
Received: from pgsmsx103.gar.corp.intel.com (10.221.44.82) by
	pgsmsx603.gar.corp.intel.com (10.221.43.87) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Wed, 21 Dec 2011 20:29:45 +0800
Received: from shsmsx602.ccr.corp.intel.com (10.239.4.104) by
	PGSMSX103.gar.corp.intel.com (10.221.44.82) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Wed, 21 Dec 2011 20:29:44 +0800
Received: from shsmsx502.ccr.corp.intel.com ([10.239.4.96]) by
	SHSMSX602.ccr.corp.intel.com ([10.239.4.104]) with mapi;
	Wed, 21 Dec 2011 20:29:44 +0800
From: "Wei, Gang" <gang.wei@intel.com>
To: Keir Fraser <keir@xen.org>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>
Date: Wed, 21 Dec 2011 20:29:42 +0800
Thread-Topic: [patch] x86: Add a delay between INIT & SIPIs for AP bring-up
	in X2APIC case
Thread-Index: Acy/0uD62iL7OBXBT0+nwXPeOaB7qgABgY/9AAA3VoAAAIsegA==
Message-ID: <F26D193E20BBDC42A43B611D1BDEDE7135CEEEAE65@shsmsx502.ccr.corp.intel.com>
References: <F26D193E20BBDC42A43B611D1BDEDE7135CEEEAE56@shsmsx502.ccr.corp.intel.com>
	<CB177C28.365E3%keir@xen.org>
	<F26D193E20BBDC42A43B611D1BDEDE7135CEEEAE63@shsmsx502.ccr.corp.intel.com>
In-Reply-To: <F26D193E20BBDC42A43B611D1BDEDE7135CEEEAE63@shsmsx502.ccr.corp.intel.com>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: zh-CN, en-US
MIME-Version: 1.0
Cc: "tboot-devel@lists.sourceforge.net" <tboot-devel@lists.sourceforge.net>,
	"Cihula, Joseph" <joseph.cihula@intel.com>,
	Tim Deegan <Tim.Deegan@citrix.com>, Jan Beulich <jbeulich@suse.com>, "Wei,
	Gang" <gang.wei@intel.com>
Subject: Re: [Xen-devel] [patch] x86: Add a delay between INIT & SIPIs for
 AP bring-up in X2APIC case
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Resent:

Without this delay, Xen could not bring APs up while working with TXT/tboot=
, because tboot need some time in APs to handle INIT before becoming ready =
for receiving SIPIs. (this delay was removed as part of c/s 23724 by Tim De=
egan)

diff -r d1aefee43af1 xen/arch/x86/smpboot.c
--- a/xen/arch/x86/smpboot.c    Wed Dec 21 18:51:31 2011 +0800
+++ b/xen/arch/x86/smpboot.c    Wed Dec 21 20:26:39 2011 +0800
@@ -42,6 +42,7 @@
 #include <asm/msr.h>
 #include <asm/mtrr.h>
 #include <asm/time.h>
+#include <asm/tboot.h>
 #include <mach_apic.h>
 #include <mach_wakecpu.h>
 #include <smpboot_hooks.h>
@@ -463,6 +464,10 @@ static int wakeup_secondary_cpu(int phys
             send_status =3D apic_read(APIC_ICR) & APIC_ICR_BUSY;
         } while ( send_status && (timeout++ < 1000) );
     }
+    else if ( tboot_in_measured_env() )
+    {
+        udelay(10);
+    }

     /*
      * Should we send STARTUP IPIs ?

Jimmy


> -----Original Message-----
> From: Wei, Gang
> Sent: Wednesday, December 21, 2011 8:18 PM
> To: Keir Fraser; xen-devel@lists.xensource.com
> Cc: tboot-devel@lists.sourceforge.net; Jan Beulich; Tim Deegan; Cihula,
> Joseph; Wei, Gang
> Subject: RE: [patch] x86: Add a delay between INIT & SIPIs for AP bring-u=
p in
> X2APIC case
> =

> Keir Fraser wrote on=A02011-12-21:
> > On 21/12/2011 11:22, "Wei, Gang" <gang.wei@intel.com> wrote:
> >
> >> Without this delay, Xen could not bring APs up while working with
> >> TXT/tboot, because tboot need some time in APs to handle INIT before
> >> becoming ready for receiving SIPIs. (this delay was removed as part
> >> of c/s 23724 by Tim Deegan)
> >
> > Of course Tim will need to review this himself, but a mdelay() right
> > here, only on the x2apic path just looks bizarre and fragile.
> >
> > Could we make the !x2apic_enabled conditionals that Tim added be
> > !(x2apic_enabled || tboot_in_measured_env()) instead? At least that is
> > somewhat self-documenting and clearly only affects tboot!
> =

> Does below patch make more sense?
> =

> diff -r d1aefee43af1 xen/arch/x86/smpboot.c
> --- a/xen/arch/x86/smpboot.c    Wed Dec 21 18:51:31 2011 +0800
> +++ b/xen/arch/x86/smpboot.c    Wed Dec 21 19:08:57 2011 +0800
> @@ -463,6 +463,10 @@ static int wakeup_secondary_cpu(int phys
>              send_status =3D apic_read(APIC_ICR) & APIC_ICR_BUSY;
>          } while ( send_status && (timeout++ < 1000) );
>      }
> +    else if ( tboot_in_measured_env() )
> +    {
> +        udelay(10);
> +    }
> =

>      /*
>       * Should we send STARTUP IPIs ?
> =

> Jimmy

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 21 12:30:07 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 12:30:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdLIy-0005QM-IE; Wed, 21 Dec 2011 12:29:56 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <gang.wei@intel.com>) id 1RdLIw-0005PZ-LD
	for xen-devel@lists.xensource.com; Wed, 21 Dec 2011 12:29:54 +0000
X-Env-Sender: gang.wei@intel.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1324470587!8130564!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMjg5NzA2\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5327 invoked from network); 21 Dec 2011 12:29:48 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-9.tower-182.messagelabs.com with SMTP;
	21 Dec 2011 12:29:48 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga101.jf.intel.com with ESMTP; 21 Dec 2011 04:29:47 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.67,351,1309762800"; d="scan'208";a="89949857"
Received: from pgsmsx603.gar.corp.intel.com ([10.221.43.87])
	by orsmga002.jf.intel.com with ESMTP; 21 Dec 2011 04:29:45 -0800
Received: from pgsmsx103.gar.corp.intel.com (10.221.44.82) by
	pgsmsx603.gar.corp.intel.com (10.221.43.87) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Wed, 21 Dec 2011 20:29:45 +0800
Received: from shsmsx602.ccr.corp.intel.com (10.239.4.104) by
	PGSMSX103.gar.corp.intel.com (10.221.44.82) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Wed, 21 Dec 2011 20:29:44 +0800
Received: from shsmsx502.ccr.corp.intel.com ([10.239.4.96]) by
	SHSMSX602.ccr.corp.intel.com ([10.239.4.104]) with mapi;
	Wed, 21 Dec 2011 20:29:44 +0800
From: "Wei, Gang" <gang.wei@intel.com>
To: Keir Fraser <keir@xen.org>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>
Date: Wed, 21 Dec 2011 20:29:42 +0800
Thread-Topic: [patch] x86: Add a delay between INIT & SIPIs for AP bring-up
	in X2APIC case
Thread-Index: Acy/0uD62iL7OBXBT0+nwXPeOaB7qgABgY/9AAA3VoAAAIsegA==
Message-ID: <F26D193E20BBDC42A43B611D1BDEDE7135CEEEAE65@shsmsx502.ccr.corp.intel.com>
References: <F26D193E20BBDC42A43B611D1BDEDE7135CEEEAE56@shsmsx502.ccr.corp.intel.com>
	<CB177C28.365E3%keir@xen.org>
	<F26D193E20BBDC42A43B611D1BDEDE7135CEEEAE63@shsmsx502.ccr.corp.intel.com>
In-Reply-To: <F26D193E20BBDC42A43B611D1BDEDE7135CEEEAE63@shsmsx502.ccr.corp.intel.com>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: zh-CN, en-US
MIME-Version: 1.0
Cc: "tboot-devel@lists.sourceforge.net" <tboot-devel@lists.sourceforge.net>,
	"Cihula, Joseph" <joseph.cihula@intel.com>,
	Tim Deegan <Tim.Deegan@citrix.com>, Jan Beulich <jbeulich@suse.com>, "Wei,
	Gang" <gang.wei@intel.com>
Subject: Re: [Xen-devel] [patch] x86: Add a delay between INIT & SIPIs for
 AP bring-up in X2APIC case
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Resent:

Without this delay, Xen could not bring APs up while working with TXT/tboot=
, because tboot need some time in APs to handle INIT before becoming ready =
for receiving SIPIs. (this delay was removed as part of c/s 23724 by Tim De=
egan)

diff -r d1aefee43af1 xen/arch/x86/smpboot.c
--- a/xen/arch/x86/smpboot.c    Wed Dec 21 18:51:31 2011 +0800
+++ b/xen/arch/x86/smpboot.c    Wed Dec 21 20:26:39 2011 +0800
@@ -42,6 +42,7 @@
 #include <asm/msr.h>
 #include <asm/mtrr.h>
 #include <asm/time.h>
+#include <asm/tboot.h>
 #include <mach_apic.h>
 #include <mach_wakecpu.h>
 #include <smpboot_hooks.h>
@@ -463,6 +464,10 @@ static int wakeup_secondary_cpu(int phys
             send_status =3D apic_read(APIC_ICR) & APIC_ICR_BUSY;
         } while ( send_status && (timeout++ < 1000) );
     }
+    else if ( tboot_in_measured_env() )
+    {
+        udelay(10);
+    }

     /*
      * Should we send STARTUP IPIs ?

Jimmy


> -----Original Message-----
> From: Wei, Gang
> Sent: Wednesday, December 21, 2011 8:18 PM
> To: Keir Fraser; xen-devel@lists.xensource.com
> Cc: tboot-devel@lists.sourceforge.net; Jan Beulich; Tim Deegan; Cihula,
> Joseph; Wei, Gang
> Subject: RE: [patch] x86: Add a delay between INIT & SIPIs for AP bring-u=
p in
> X2APIC case
> =

> Keir Fraser wrote on=A02011-12-21:
> > On 21/12/2011 11:22, "Wei, Gang" <gang.wei@intel.com> wrote:
> >
> >> Without this delay, Xen could not bring APs up while working with
> >> TXT/tboot, because tboot need some time in APs to handle INIT before
> >> becoming ready for receiving SIPIs. (this delay was removed as part
> >> of c/s 23724 by Tim Deegan)
> >
> > Of course Tim will need to review this himself, but a mdelay() right
> > here, only on the x2apic path just looks bizarre and fragile.
> >
> > Could we make the !x2apic_enabled conditionals that Tim added be
> > !(x2apic_enabled || tboot_in_measured_env()) instead? At least that is
> > somewhat self-documenting and clearly only affects tboot!
> =

> Does below patch make more sense?
> =

> diff -r d1aefee43af1 xen/arch/x86/smpboot.c
> --- a/xen/arch/x86/smpboot.c    Wed Dec 21 18:51:31 2011 +0800
> +++ b/xen/arch/x86/smpboot.c    Wed Dec 21 19:08:57 2011 +0800
> @@ -463,6 +463,10 @@ static int wakeup_secondary_cpu(int phys
>              send_status =3D apic_read(APIC_ICR) & APIC_ICR_BUSY;
>          } while ( send_status && (timeout++ < 1000) );
>      }
> +    else if ( tboot_in_measured_env() )
> +    {
> +        udelay(10);
> +    }
> =

>      /*
>       * Should we send STARTUP IPIs ?
> =

> Jimmy

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 21 13:14:20 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 13:14:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdLzS-0006DW-9N; Wed, 21 Dec 2011 13:13:50 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RdLzQ-0006DQ-Nh
	for xen-devel@lists.xensource.com; Wed, 21 Dec 2011 13:13:48 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1324473193!45756593!1
X-Originating-IP: [74.125.82.41]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21847 invoked from network); 21 Dec 2011 13:13:13 -0000
Received: from mail-ww0-f41.google.com (HELO mail-ww0-f41.google.com)
	(74.125.82.41)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Dec 2011 13:13:13 -0000
Received: by wgbdt12 with SMTP id dt12so11715885wgb.0
	for <xen-devel@lists.xensource.com>;
	Wed, 21 Dec 2011 05:13:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=vrEP8z1HJEp/PR9Yxm16qsUld7sajlmcXve2G68tHIc=;
	b=ufq2PDLghqqaHZML0uVsIAZu6KMSw9XFrKkyuRC4fAfqQR2bWhVIDkx6kC4umuNx/m
	2KYaMdyiWcXfHqb4XSWVO+ot8+MYiPLCHhQJVGJzmYshWRq6fXQ1tI+m9c3LPK1hI9hj
	LqqRhgmxkse0GP5ee7Ot1R9c6U4eq/0l/MBuU=
Received: by 10.180.101.35 with SMTP id fd3mr4232261wib.22.1324473224420;
	Wed, 21 Dec 2011 05:13:44 -0800 (PST)
Received: from [192.168.1.3] (host81-152-17-11.range81-152.btcentralplus.com.
	[81.152.17.11])
	by mx.google.com with ESMTPS id p2sm5791884wbh.22.2011.12.21.05.13.40
	(version=SSLv3 cipher=OTHER); Wed, 21 Dec 2011 05:13:43 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Wed, 21 Dec 2011 13:13:31 +0000
From: Keir Fraser <keir@xen.org>
To: "Wei, Gang" <gang.wei@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Message-ID: <CB178BFB.36631%keir@xen.org>
Thread-Topic: [patch] x86: Add a delay between INIT & SIPIs for AP bring-up in
	X2APIC case
Thread-Index: Acy/0uD62iL7OBXBT0+nwXPeOaB7qgABgY/9AAA3VoAAAIsegAABmTKG
In-Reply-To: <F26D193E20BBDC42A43B611D1BDEDE7135CEEEAE65@shsmsx502.ccr.corp.intel.com>
Mime-version: 1.0
Cc: "tboot-devel@lists.sourceforge.net" <tboot-devel@lists.sourceforge.net>,
	"Cihula, Joseph" <joseph.cihula@intel.com>,
	Tim Deegan <Tim.Deegan@citrix.com>, Jan Beulich <jbeulich@suse.com>
Subject: Re: [Xen-devel] [patch] x86: Add a delay between INIT & SIPIs for
 AP bring-up in X2APIC case
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Please add a code comment explaining why the delay is needed. Apart from
that:

Acked-by: Keir Fraser <keir@xen.org>


On 21/12/2011 12:29, "Wei, Gang" <gang.wei@intel.com> wrote:

> Resent:
> =

> Without this delay, Xen could not bring APs up while working with TXT/tbo=
ot,
> because tboot need some time in APs to handle INIT before becoming ready =
for
> receiving SIPIs. (this delay was removed as part of c/s 23724 by Tim Deeg=
an)
> =

> diff -r d1aefee43af1 xen/arch/x86/smpboot.c
> --- a/xen/arch/x86/smpboot.c    Wed Dec 21 18:51:31 2011 +0800
> +++ b/xen/arch/x86/smpboot.c    Wed Dec 21 20:26:39 2011 +0800
> @@ -42,6 +42,7 @@
>  #include <asm/msr.h>
>  #include <asm/mtrr.h>
>  #include <asm/time.h>
> +#include <asm/tboot.h>
>  #include <mach_apic.h>
>  #include <mach_wakecpu.h>
>  #include <smpboot_hooks.h>
> @@ -463,6 +464,10 @@ static int wakeup_secondary_cpu(int phys
>              send_status =3D apic_read(APIC_ICR) & APIC_ICR_BUSY;
>          } while ( send_status && (timeout++ < 1000) );
>      }
> +    else if ( tboot_in_measured_env() )
> +    {
> +        udelay(10);
> +    }
> =

>      /*
>       * Should we send STARTUP IPIs ?
> =

> Jimmy
> =

> =

>> -----Original Message-----
>> From: Wei, Gang
>> Sent: Wednesday, December 21, 2011 8:18 PM
>> To: Keir Fraser; xen-devel@lists.xensource.com
>> Cc: tboot-devel@lists.sourceforge.net; Jan Beulich; Tim Deegan; Cihula,
>> Joseph; Wei, Gang
>> Subject: RE: [patch] x86: Add a delay between INIT & SIPIs for AP bring-=
up in
>> X2APIC case
>> =

>> Keir Fraser wrote on=A02011-12-21:
>>> On 21/12/2011 11:22, "Wei, Gang" <gang.wei@intel.com> wrote:
>>> =

>>>> Without this delay, Xen could not bring APs up while working with
>>>> TXT/tboot, because tboot need some time in APs to handle INIT before
>>>> becoming ready for receiving SIPIs. (this delay was removed as part
>>>> of c/s 23724 by Tim Deegan)
>>> =

>>> Of course Tim will need to review this himself, but a mdelay() right
>>> here, only on the x2apic path just looks bizarre and fragile.
>>> =

>>> Could we make the !x2apic_enabled conditionals that Tim added be
>>> !(x2apic_enabled || tboot_in_measured_env()) instead? At least that is
>>> somewhat self-documenting and clearly only affects tboot!
>> =

>> Does below patch make more sense?
>> =

>> diff -r d1aefee43af1 xen/arch/x86/smpboot.c
>> --- a/xen/arch/x86/smpboot.c    Wed Dec 21 18:51:31 2011 +0800
>> +++ b/xen/arch/x86/smpboot.c    Wed Dec 21 19:08:57 2011 +0800
>> @@ -463,6 +463,10 @@ static int wakeup_secondary_cpu(int phys
>>              send_status =3D apic_read(APIC_ICR) & APIC_ICR_BUSY;
>>          } while ( send_status && (timeout++ < 1000) );
>>      }
>> +    else if ( tboot_in_measured_env() )
>> +    {
>> +        udelay(10);
>> +    }
>> =

>>      /*
>>       * Should we send STARTUP IPIs ?
>> =

>> Jimmy



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 21 13:14:20 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 13:14:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdLzS-0006DW-9N; Wed, 21 Dec 2011 13:13:50 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RdLzQ-0006DQ-Nh
	for xen-devel@lists.xensource.com; Wed, 21 Dec 2011 13:13:48 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1324473193!45756593!1
X-Originating-IP: [74.125.82.41]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21847 invoked from network); 21 Dec 2011 13:13:13 -0000
Received: from mail-ww0-f41.google.com (HELO mail-ww0-f41.google.com)
	(74.125.82.41)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Dec 2011 13:13:13 -0000
Received: by wgbdt12 with SMTP id dt12so11715885wgb.0
	for <xen-devel@lists.xensource.com>;
	Wed, 21 Dec 2011 05:13:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=vrEP8z1HJEp/PR9Yxm16qsUld7sajlmcXve2G68tHIc=;
	b=ufq2PDLghqqaHZML0uVsIAZu6KMSw9XFrKkyuRC4fAfqQR2bWhVIDkx6kC4umuNx/m
	2KYaMdyiWcXfHqb4XSWVO+ot8+MYiPLCHhQJVGJzmYshWRq6fXQ1tI+m9c3LPK1hI9hj
	LqqRhgmxkse0GP5ee7Ot1R9c6U4eq/0l/MBuU=
Received: by 10.180.101.35 with SMTP id fd3mr4232261wib.22.1324473224420;
	Wed, 21 Dec 2011 05:13:44 -0800 (PST)
Received: from [192.168.1.3] (host81-152-17-11.range81-152.btcentralplus.com.
	[81.152.17.11])
	by mx.google.com with ESMTPS id p2sm5791884wbh.22.2011.12.21.05.13.40
	(version=SSLv3 cipher=OTHER); Wed, 21 Dec 2011 05:13:43 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Wed, 21 Dec 2011 13:13:31 +0000
From: Keir Fraser <keir@xen.org>
To: "Wei, Gang" <gang.wei@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Message-ID: <CB178BFB.36631%keir@xen.org>
Thread-Topic: [patch] x86: Add a delay between INIT & SIPIs for AP bring-up in
	X2APIC case
Thread-Index: Acy/0uD62iL7OBXBT0+nwXPeOaB7qgABgY/9AAA3VoAAAIsegAABmTKG
In-Reply-To: <F26D193E20BBDC42A43B611D1BDEDE7135CEEEAE65@shsmsx502.ccr.corp.intel.com>
Mime-version: 1.0
Cc: "tboot-devel@lists.sourceforge.net" <tboot-devel@lists.sourceforge.net>,
	"Cihula, Joseph" <joseph.cihula@intel.com>,
	Tim Deegan <Tim.Deegan@citrix.com>, Jan Beulich <jbeulich@suse.com>
Subject: Re: [Xen-devel] [patch] x86: Add a delay between INIT & SIPIs for
 AP bring-up in X2APIC case
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Please add a code comment explaining why the delay is needed. Apart from
that:

Acked-by: Keir Fraser <keir@xen.org>


On 21/12/2011 12:29, "Wei, Gang" <gang.wei@intel.com> wrote:

> Resent:
> =

> Without this delay, Xen could not bring APs up while working with TXT/tbo=
ot,
> because tboot need some time in APs to handle INIT before becoming ready =
for
> receiving SIPIs. (this delay was removed as part of c/s 23724 by Tim Deeg=
an)
> =

> diff -r d1aefee43af1 xen/arch/x86/smpboot.c
> --- a/xen/arch/x86/smpboot.c    Wed Dec 21 18:51:31 2011 +0800
> +++ b/xen/arch/x86/smpboot.c    Wed Dec 21 20:26:39 2011 +0800
> @@ -42,6 +42,7 @@
>  #include <asm/msr.h>
>  #include <asm/mtrr.h>
>  #include <asm/time.h>
> +#include <asm/tboot.h>
>  #include <mach_apic.h>
>  #include <mach_wakecpu.h>
>  #include <smpboot_hooks.h>
> @@ -463,6 +464,10 @@ static int wakeup_secondary_cpu(int phys
>              send_status =3D apic_read(APIC_ICR) & APIC_ICR_BUSY;
>          } while ( send_status && (timeout++ < 1000) );
>      }
> +    else if ( tboot_in_measured_env() )
> +    {
> +        udelay(10);
> +    }
> =

>      /*
>       * Should we send STARTUP IPIs ?
> =

> Jimmy
> =

> =

>> -----Original Message-----
>> From: Wei, Gang
>> Sent: Wednesday, December 21, 2011 8:18 PM
>> To: Keir Fraser; xen-devel@lists.xensource.com
>> Cc: tboot-devel@lists.sourceforge.net; Jan Beulich; Tim Deegan; Cihula,
>> Joseph; Wei, Gang
>> Subject: RE: [patch] x86: Add a delay between INIT & SIPIs for AP bring-=
up in
>> X2APIC case
>> =

>> Keir Fraser wrote on=A02011-12-21:
>>> On 21/12/2011 11:22, "Wei, Gang" <gang.wei@intel.com> wrote:
>>> =

>>>> Without this delay, Xen could not bring APs up while working with
>>>> TXT/tboot, because tboot need some time in APs to handle INIT before
>>>> becoming ready for receiving SIPIs. (this delay was removed as part
>>>> of c/s 23724 by Tim Deegan)
>>> =

>>> Of course Tim will need to review this himself, but a mdelay() right
>>> here, only on the x2apic path just looks bizarre and fragile.
>>> =

>>> Could we make the !x2apic_enabled conditionals that Tim added be
>>> !(x2apic_enabled || tboot_in_measured_env()) instead? At least that is
>>> somewhat self-documenting and clearly only affects tboot!
>> =

>> Does below patch make more sense?
>> =

>> diff -r d1aefee43af1 xen/arch/x86/smpboot.c
>> --- a/xen/arch/x86/smpboot.c    Wed Dec 21 18:51:31 2011 +0800
>> +++ b/xen/arch/x86/smpboot.c    Wed Dec 21 19:08:57 2011 +0800
>> @@ -463,6 +463,10 @@ static int wakeup_secondary_cpu(int phys
>>              send_status =3D apic_read(APIC_ICR) & APIC_ICR_BUSY;
>>          } while ( send_status && (timeout++ < 1000) );
>>      }
>> +    else if ( tboot_in_measured_env() )
>> +    {
>> +        udelay(10);
>> +    }
>> =

>>      /*
>>       * Should we send STARTUP IPIs ?
>> =

>> Jimmy



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 21 13:43:49 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 13:43:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdMRt-0006Rs-0G; Wed, 21 Dec 2011 13:43:13 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1RdMRr-0006Rj-Jl
	for xen-devel@lists.xensource.com; Wed, 21 Dec 2011 13:43:11 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-7.tower-174.messagelabs.com!1324474985!6422184!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3571 invoked from network); 21 Dec 2011 13:43:05 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-7.tower-174.messagelabs.com with SMTP;
	21 Dec 2011 13:43:05 -0000
Received: from [213.136.170.40] (account d.faggioli@sssup.it HELO
	[192.168.0.40]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 74082294; Wed, 21 Dec 2011 14:43:03 +0100
Message-ID: <1324474962.2581.4.camel@Solace>
From: Dario Faggioli <raistlin@linux.it>
To: George Dunlap <George.Dunlap@eu.citrix.com>
Date: Wed, 21 Dec 2011 14:42:42 +0100
In-Reply-To: <CAFLBxZYtb+DaZ3cQD=KR1Xty-YZtsyC53PEiNO4bVU=3qP2WSg@mail.gmail.com>
References: <1324454839.2682.1.camel@Solace>
	<CAFLBxZYtb+DaZ3cQD=KR1Xty-YZtsyC53PEiNO4bVU=3qP2WSg@mail.gmail.com>
X-Mailer: Evolution 3.2.2-1 
Mime-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Keir Fraser <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH] sedf: remove useless tracing printk and
 harmonize comments style.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============4936964494995583975=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--===============4936964494995583975==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-RKi6krBp20+bW/XbN6cQ"


--=-RKi6krBp20+bW/XbN6cQ
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, 2011-12-21 at 12:21 +0000, George Dunlap wrote:
> RE removing the prinks, and most of the comment changes, ACK.
>=20
Ok, that's what counts most. :-)

> However, I think the typical comment style is that you should either
> do things this way:
>=20
> /* A one-line comment, start and end in one line */
>=20
> Or this way:
> /*
>  * A multi-line comment,
>  * Where the opening and closing each have their own line.
>  */
>=20
Which is my favorite...

> Or,
> /* If you have a short comment that can't fit on
>  * one line, put it on two, but with out any extra lines. */
>=20
> But you seem to be replacing all multi-line comments with this:
>=20
> /* The first line having the open-comment at the benning,
>  * But the close-comment having its own line.
>  */
>=20
It looks weird to me too, but I'm sure I've seen it in a couple of
source files in xen (and it looked weird at that time too! :-P).
Moreover, it was like that on many multiline comments in sched_sedf.c,
so I just changed the one with an even weirder one to it.

> I've never seen that before, and it looks a bit weird. :-)
>=20
100% Agree. :-)

> I prefer the first two, with judicious use of the third when appropriate.
>=20
I can't be more happy to hear that, I'll go for the first, the one with
both wings. :-D

Thanks,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-------------------------------------------------------------------
Dario Faggioli, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
PhD Candidate, ReTiS Lab, Scuola Superiore Sant'Anna, Pisa (Italy)


--=-RKi6krBp20+bW/XbN6cQ
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEABECAAYFAk7x4lIACgkQk4XaBE3IOsQQDACeJAkdWopkl0CzWVVT/zXZRCyH
NVEAn2+vtPG78PdYgEe4Fws+GPrdhFV0
=O4a4
-----END PGP SIGNATURE-----

--=-RKi6krBp20+bW/XbN6cQ--



--===============4936964494995583975==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============4936964494995583975==--



From xen-devel-bounces@lists.xensource.com Wed Dec 21 13:43:49 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 13:43:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdMRt-0006Rs-0G; Wed, 21 Dec 2011 13:43:13 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1RdMRr-0006Rj-Jl
	for xen-devel@lists.xensource.com; Wed, 21 Dec 2011 13:43:11 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-7.tower-174.messagelabs.com!1324474985!6422184!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3571 invoked from network); 21 Dec 2011 13:43:05 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-7.tower-174.messagelabs.com with SMTP;
	21 Dec 2011 13:43:05 -0000
Received: from [213.136.170.40] (account d.faggioli@sssup.it HELO
	[192.168.0.40]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 74082294; Wed, 21 Dec 2011 14:43:03 +0100
Message-ID: <1324474962.2581.4.camel@Solace>
From: Dario Faggioli <raistlin@linux.it>
To: George Dunlap <George.Dunlap@eu.citrix.com>
Date: Wed, 21 Dec 2011 14:42:42 +0100
In-Reply-To: <CAFLBxZYtb+DaZ3cQD=KR1Xty-YZtsyC53PEiNO4bVU=3qP2WSg@mail.gmail.com>
References: <1324454839.2682.1.camel@Solace>
	<CAFLBxZYtb+DaZ3cQD=KR1Xty-YZtsyC53PEiNO4bVU=3qP2WSg@mail.gmail.com>
X-Mailer: Evolution 3.2.2-1 
Mime-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Keir Fraser <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH] sedf: remove useless tracing printk and
 harmonize comments style.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============4936964494995583975=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--===============4936964494995583975==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-RKi6krBp20+bW/XbN6cQ"


--=-RKi6krBp20+bW/XbN6cQ
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, 2011-12-21 at 12:21 +0000, George Dunlap wrote:
> RE removing the prinks, and most of the comment changes, ACK.
>=20
Ok, that's what counts most. :-)

> However, I think the typical comment style is that you should either
> do things this way:
>=20
> /* A one-line comment, start and end in one line */
>=20
> Or this way:
> /*
>  * A multi-line comment,
>  * Where the opening and closing each have their own line.
>  */
>=20
Which is my favorite...

> Or,
> /* If you have a short comment that can't fit on
>  * one line, put it on two, but with out any extra lines. */
>=20
> But you seem to be replacing all multi-line comments with this:
>=20
> /* The first line having the open-comment at the benning,
>  * But the close-comment having its own line.
>  */
>=20
It looks weird to me too, but I'm sure I've seen it in a couple of
source files in xen (and it looked weird at that time too! :-P).
Moreover, it was like that on many multiline comments in sched_sedf.c,
so I just changed the one with an even weirder one to it.

> I've never seen that before, and it looks a bit weird. :-)
>=20
100% Agree. :-)

> I prefer the first two, with judicious use of the third when appropriate.
>=20
I can't be more happy to hear that, I'll go for the first, the one with
both wings. :-D

Thanks,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-------------------------------------------------------------------
Dario Faggioli, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
PhD Candidate, ReTiS Lab, Scuola Superiore Sant'Anna, Pisa (Italy)


--=-RKi6krBp20+bW/XbN6cQ
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEABECAAYFAk7x4lIACgkQk4XaBE3IOsQQDACeJAkdWopkl0CzWVVT/zXZRCyH
NVEAn2+vtPG78PdYgEe4Fws+GPrdhFV0
=O4a4
-----END PGP SIGNATURE-----

--=-RKi6krBp20+bW/XbN6cQ--



--===============4936964494995583975==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============4936964494995583975==--



From xen-devel-bounces@lists.xensource.com Wed Dec 21 13:47:31 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 13:47:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdMVg-0006Yh-Lh; Wed, 21 Dec 2011 13:47:08 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RdMVf-0006YU-79
	for xen-devel@lists.xensource.com; Wed, 21 Dec 2011 13:47:07 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1324475220!6408340!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzcyNA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28713 invoked from network); 21 Dec 2011 13:47:01 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Dec 2011 13:47:01 -0000
X-IronPort-AV: E=Sophos;i="4.71,388,1320624000"; 
   d="scan'208";a="9610187"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Dec 2011 13:47:00 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 21 Dec 2011 13:47:00 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Mustafa Aydin <maydin.work@gmail.com>
Date: Wed, 21 Dec 2011 13:47:00 +0000
In-Reply-To: <CALF+9DFCeYu2E1xBuHOW4n_7J9kz0H4Ngv1BY_Rn8d-SwDb3VA@mail.gmail.com>
References: <CALF+9DFCeYu2E1xBuHOW4n_7J9kz0H4Ngv1BY_Rn8d-SwDb3VA@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1324475220.7877.32.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Xen interfaces / hooks
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2011-12-20 at 23:02 +0000, Mustafa Aydin wrote:
> Hello all,
> 
> I have been looking through the internet and through the wiki, trying
> to find something which explains in details the available interfaces
> with which one might be able to insert some code to make some slight
> additions to Xen functionality. I am doing some research on the
> possibility of adding some extra functionality to Xen, and my
> supervisor has mentioned that these are things worth looking into (he
> called them modules / kernel modules). 
> 
> Is there a source of info which lists these tools please? Although I
> have spent today going through many pages and searching I could not
> find anything, although perhaps I was using some incorrect terms. 

The Xen hypervisor does not have any concept of kernel modules or
runtime code modification / loading.

The method by which you insert some code into or make some modification
is to modify the hypervisor code directly.

Perhaps if you explain your actual end goal you can be better advised.

Or perhaps you/your supervisor are thinking of the dom0 guest operating
system which may have a module loading system (e.g. Linux does). This is
nothing to do with Xen though.

Thanks,
Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 21 13:47:31 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 13:47:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdMVg-0006Yh-Lh; Wed, 21 Dec 2011 13:47:08 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RdMVf-0006YU-79
	for xen-devel@lists.xensource.com; Wed, 21 Dec 2011 13:47:07 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1324475220!6408340!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzcyNA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28713 invoked from network); 21 Dec 2011 13:47:01 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Dec 2011 13:47:01 -0000
X-IronPort-AV: E=Sophos;i="4.71,388,1320624000"; 
   d="scan'208";a="9610187"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Dec 2011 13:47:00 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 21 Dec 2011 13:47:00 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Mustafa Aydin <maydin.work@gmail.com>
Date: Wed, 21 Dec 2011 13:47:00 +0000
In-Reply-To: <CALF+9DFCeYu2E1xBuHOW4n_7J9kz0H4Ngv1BY_Rn8d-SwDb3VA@mail.gmail.com>
References: <CALF+9DFCeYu2E1xBuHOW4n_7J9kz0H4Ngv1BY_Rn8d-SwDb3VA@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1324475220.7877.32.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Xen interfaces / hooks
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2011-12-20 at 23:02 +0000, Mustafa Aydin wrote:
> Hello all,
> 
> I have been looking through the internet and through the wiki, trying
> to find something which explains in details the available interfaces
> with which one might be able to insert some code to make some slight
> additions to Xen functionality. I am doing some research on the
> possibility of adding some extra functionality to Xen, and my
> supervisor has mentioned that these are things worth looking into (he
> called them modules / kernel modules). 
> 
> Is there a source of info which lists these tools please? Although I
> have spent today going through many pages and searching I could not
> find anything, although perhaps I was using some incorrect terms. 

The Xen hypervisor does not have any concept of kernel modules or
runtime code modification / loading.

The method by which you insert some code into or make some modification
is to modify the hypervisor code directly.

Perhaps if you explain your actual end goal you can be better advised.

Or perhaps you/your supervisor are thinking of the dom0 guest operating
system which may have a module loading system (e.g. Linux does). This is
nothing to do with Xen though.

Thanks,
Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 21 13:52:13 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 13: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.xensource.com>)
	id 1RdMaE-0006m4-Hp; Wed, 21 Dec 2011 13:51:50 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <lersek@redhat.com>) id 1RdMaD-0006lu-Be
	for xen-devel@lists.xensource.com; Wed, 21 Dec 2011 13:51:49 +0000
X-Env-Sender: lersek@redhat.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1324475461!47692261!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDY2OTY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14573 invoked from network); 21 Dec 2011 13:51:02 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-10.tower-27.messagelabs.com with SMTP;
	21 Dec 2011 13:51:02 -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 pBLDpfGq014593
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 21 Dec 2011 08:51:41 -0500
Received: from lacos-laptop.usersys.redhat.com (dhcp-1-169.brq.redhat.com
	[10.34.1.169])
	by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id pBLDpcFi027760; Wed, 21 Dec 2011 08:51:38 -0500
Message-ID: <4EF1E4D5.4090301@redhat.com>
Date: Wed, 21 Dec 2011 14:53:25 +0100
From: Laszlo Ersek <lersek@redhat.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.24) Gecko/20111104 Red Hat/3.1.16-2.el6_1 Mnenhy/0.8.4
	Thunderbird/3.1.16
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1318970579-6282-1-git-send-email-lersek@redhat.com>
	<4EF1A7A002000078000694CA@nat28.tlf.novell.com>
In-Reply-To: <4EF1A7A002000078000694CA@nat28.tlf.novell.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, xen-devel@lists.xensource.com,
	Joe Jin <joe.jin@oracle.com>, Zhenzhong Duan <zhenzhong.duan@oracle.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH] remove blocked time accounting from xen
	"clockchip"
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 12/21/11 09:32, Jan Beulich wrote:

> Specifically, without further adjustments, on a 4:3 over-committed
> system doing a kernel build, I'm seeing an over-accounting of
> approximately 4%. I was able to reduce this to slightly above 1%
> with below (experimental and not 32-bit compatible) change:
>
> --- a/kernel/sched.c
> +++ b/kernel/sched.c
> @@ -3864,6 +3864,29 @@
>   	return ns;
>   }
>
> +#ifndef CONFIG_XEN
> +#define _cputime_to_cputime64 cputime_to_cputime64
> +#else
> +#define NS_PER_TICK (1000000000 / HZ)
> +static DEFINE_PER_CPU(u64, stolen_snapshot);
> +static DEFINE_PER_CPU(unsigned int, stolen_residual);
> +
> +static cputime64_t _cputime_to_cputime64(cputime_t t)
> +{
> +	//todo not entirely suitable for 32-bit
> +	u64 s = this_cpu_read(runstate.time[RUNSTATE_runnable]);
> +	unsigned long adj = div_u64_rem(s - this_cpu_read(stolen_snapshot)
> +					  + this_cpu_read(stolen_residual),
> +					NS_PER_TICK,
> +					&__get_cpu_var(stolen_residual));
> +
> +	this_cpu_write(stolen_snapshot, s);
> +	t = cputime_sub(t, jiffies_to_cputime(adj));
> +
> +	return cputime_le(t, cputime_max) ? cputime_to_cputime64(t) : 0;
> +}
> +#endif
> +

Why is this not entirely suitable for 32-bit? div_u64_rem() indeed 
returns an u64, but for the truncation to do actual damage, the retval 
(which is the number of ticks that was stolen from the VCPU) would have 
to be greater than about 4*10^9, which seems improbable with 1 msec long 
ticks. Also cputime_sub() only depends, in order to leave any underflow 
detectable, on adj <= cputime_max (cca. 2*10^9). I'm likely looking in 
the wrong place though.


>   /*
>    * Account user cpu time to a process.
>    * @p: the process that the cpu time gets accounted to
> @@ -3882,7 +3905,7 @@
>   	account_group_user_time(p, cputime);
>
>   	/* Add user time to cpustat. */
> -	tmp = cputime_to_cputime64(cputime);
> +	tmp = _cputime_to_cputime64(cputime);
>   	if (TASK_NICE(p)>  0)
>   		cpustat->nice = cputime64_add(cpustat->nice, tmp);
>   	else
> @@ -3934,7 +3957,7 @@
>   void __account_system_time(struct task_struct *p, cputime_t cputime,
>   			cputime_t cputime_scaled, cputime64_t *target_cputime64)
>   {
> -	cputime64_t tmp = cputime_to_cputime64(cputime);
> +	cputime64_t tmp = _cputime_to_cputime64(cputime);
>
>   	/* Add system time to process. */
>   	p->stime = cputime_add(p->stime, cputime);
> @@ -3996,7 +4019,7 @@
>   void account_idle_time(cputime_t cputime)
>   {
>   	struct cpu_usage_stat *cpustat =&kstat_this_cpu.cpustat;
> -	cputime64_t cputime64 = cputime_to_cputime64(cputime);
> +	cputime64_t cputime64 = _cputime_to_cputime64(cputime);
>   	struct rq *rq = this_rq();
>
>   	if (atomic_read(&rq->nr_iowait)>  0)
> @@ -4033,7 +4056,7 @@
>   						struct rq *rq)
>   {
>   	cputime_t one_jiffy_scaled = cputime_to_scaled(cputime_one_jiffy);
> -	cputime64_t tmp = cputime_to_cputime64(cputime_one_jiffy);
> +	cputime64_t tmp = _cputime_to_cputime64(cputime_one_jiffy);
>   	struct cpu_usage_stat *cpustat =&kstat_this_cpu.cpustat;
>
>   	if (irqtime_account_hi_update()) {
>
> I currently have no idea what the remain 1% could be attributed to,
> so thoughts from others would certainly be welcome.

What about irqtime_account_process_tick() calling account_idle_time() 
with "cputime_one_jiffy" -- it could more frequently trigger the 
underflow in _cputime_to_cputime64(). In that case we might want to 
decrease idle time (ie. account "negative" cputime against idle), but can't.

As always, apologies if what I wrote is painfully wrong.
Laszlo

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 21 13:52:13 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 13: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.xensource.com>)
	id 1RdMaE-0006m4-Hp; Wed, 21 Dec 2011 13:51:50 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <lersek@redhat.com>) id 1RdMaD-0006lu-Be
	for xen-devel@lists.xensource.com; Wed, 21 Dec 2011 13:51:49 +0000
X-Env-Sender: lersek@redhat.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1324475461!47692261!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDY2OTY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14573 invoked from network); 21 Dec 2011 13:51:02 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-10.tower-27.messagelabs.com with SMTP;
	21 Dec 2011 13:51:02 -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 pBLDpfGq014593
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 21 Dec 2011 08:51:41 -0500
Received: from lacos-laptop.usersys.redhat.com (dhcp-1-169.brq.redhat.com
	[10.34.1.169])
	by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id pBLDpcFi027760; Wed, 21 Dec 2011 08:51:38 -0500
Message-ID: <4EF1E4D5.4090301@redhat.com>
Date: Wed, 21 Dec 2011 14:53:25 +0100
From: Laszlo Ersek <lersek@redhat.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.24) Gecko/20111104 Red Hat/3.1.16-2.el6_1 Mnenhy/0.8.4
	Thunderbird/3.1.16
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1318970579-6282-1-git-send-email-lersek@redhat.com>
	<4EF1A7A002000078000694CA@nat28.tlf.novell.com>
In-Reply-To: <4EF1A7A002000078000694CA@nat28.tlf.novell.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, xen-devel@lists.xensource.com,
	Joe Jin <joe.jin@oracle.com>, Zhenzhong Duan <zhenzhong.duan@oracle.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH] remove blocked time accounting from xen
	"clockchip"
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 12/21/11 09:32, Jan Beulich wrote:

> Specifically, without further adjustments, on a 4:3 over-committed
> system doing a kernel build, I'm seeing an over-accounting of
> approximately 4%. I was able to reduce this to slightly above 1%
> with below (experimental and not 32-bit compatible) change:
>
> --- a/kernel/sched.c
> +++ b/kernel/sched.c
> @@ -3864,6 +3864,29 @@
>   	return ns;
>   }
>
> +#ifndef CONFIG_XEN
> +#define _cputime_to_cputime64 cputime_to_cputime64
> +#else
> +#define NS_PER_TICK (1000000000 / HZ)
> +static DEFINE_PER_CPU(u64, stolen_snapshot);
> +static DEFINE_PER_CPU(unsigned int, stolen_residual);
> +
> +static cputime64_t _cputime_to_cputime64(cputime_t t)
> +{
> +	//todo not entirely suitable for 32-bit
> +	u64 s = this_cpu_read(runstate.time[RUNSTATE_runnable]);
> +	unsigned long adj = div_u64_rem(s - this_cpu_read(stolen_snapshot)
> +					  + this_cpu_read(stolen_residual),
> +					NS_PER_TICK,
> +					&__get_cpu_var(stolen_residual));
> +
> +	this_cpu_write(stolen_snapshot, s);
> +	t = cputime_sub(t, jiffies_to_cputime(adj));
> +
> +	return cputime_le(t, cputime_max) ? cputime_to_cputime64(t) : 0;
> +}
> +#endif
> +

Why is this not entirely suitable for 32-bit? div_u64_rem() indeed 
returns an u64, but for the truncation to do actual damage, the retval 
(which is the number of ticks that was stolen from the VCPU) would have 
to be greater than about 4*10^9, which seems improbable with 1 msec long 
ticks. Also cputime_sub() only depends, in order to leave any underflow 
detectable, on adj <= cputime_max (cca. 2*10^9). I'm likely looking in 
the wrong place though.


>   /*
>    * Account user cpu time to a process.
>    * @p: the process that the cpu time gets accounted to
> @@ -3882,7 +3905,7 @@
>   	account_group_user_time(p, cputime);
>
>   	/* Add user time to cpustat. */
> -	tmp = cputime_to_cputime64(cputime);
> +	tmp = _cputime_to_cputime64(cputime);
>   	if (TASK_NICE(p)>  0)
>   		cpustat->nice = cputime64_add(cpustat->nice, tmp);
>   	else
> @@ -3934,7 +3957,7 @@
>   void __account_system_time(struct task_struct *p, cputime_t cputime,
>   			cputime_t cputime_scaled, cputime64_t *target_cputime64)
>   {
> -	cputime64_t tmp = cputime_to_cputime64(cputime);
> +	cputime64_t tmp = _cputime_to_cputime64(cputime);
>
>   	/* Add system time to process. */
>   	p->stime = cputime_add(p->stime, cputime);
> @@ -3996,7 +4019,7 @@
>   void account_idle_time(cputime_t cputime)
>   {
>   	struct cpu_usage_stat *cpustat =&kstat_this_cpu.cpustat;
> -	cputime64_t cputime64 = cputime_to_cputime64(cputime);
> +	cputime64_t cputime64 = _cputime_to_cputime64(cputime);
>   	struct rq *rq = this_rq();
>
>   	if (atomic_read(&rq->nr_iowait)>  0)
> @@ -4033,7 +4056,7 @@
>   						struct rq *rq)
>   {
>   	cputime_t one_jiffy_scaled = cputime_to_scaled(cputime_one_jiffy);
> -	cputime64_t tmp = cputime_to_cputime64(cputime_one_jiffy);
> +	cputime64_t tmp = _cputime_to_cputime64(cputime_one_jiffy);
>   	struct cpu_usage_stat *cpustat =&kstat_this_cpu.cpustat;
>
>   	if (irqtime_account_hi_update()) {
>
> I currently have no idea what the remain 1% could be attributed to,
> so thoughts from others would certainly be welcome.

What about irqtime_account_process_tick() calling account_idle_time() 
with "cputime_one_jiffy" -- it could more frequently trigger the 
underflow in _cputime_to_cputime64(). In that case we might want to 
decrease idle time (ie. account "negative" cputime against idle), but can't.

As always, apologies if what I wrote is painfully wrong.
Laszlo

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 21 14:48:25 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 14:48:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdNSJ-0007Og-A3; Wed, 21 Dec 2011 14:47:43 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RdNSI-0007Ob-1A
	for xen-devel@lists.xensource.com; Wed, 21 Dec 2011 14:47:42 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1324478855!6418532!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzcyNA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10567 invoked from network); 21 Dec 2011 14:47:36 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Dec 2011 14:47:36 -0000
X-IronPort-AV: E=Sophos;i="4.71,388,1320624000"; 
   d="scan'208";a="9612028"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Dec 2011 14:47:35 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 21 Dec 2011 14:47:35 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RdNSB-0002vN-H9; Wed, 21 Dec 2011 14:47:35 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RdNSB-0008PX-DV;
	Wed, 21 Dec 2011 14:47:35 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20209.61831.404644.406603@mariner.uk.xensource.com>
Date: Wed, 21 Dec 2011 14:47:35 +0000
To: Anthony PERARD <anthony.perard@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1324462836-7059-1-git-send-email-anthony.perard@citrix.com>
References: <1324462836-7059-1-git-send-email-anthony.perard@citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Olaf Hering <olaf@aepfle.de>, Xen Devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] libxl: Fix,
	specify open mode to QEMU state file.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Anthony PERARD writes ("[Xen-devel] [PATCH] libxl: Fix, specify open mode to QEMU state file."):
> Reported-by: Olaf Hering <olaf@aepfle.de>
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>

Thanks.

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 21 14:48:25 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 14:48:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdNSJ-0007Og-A3; Wed, 21 Dec 2011 14:47:43 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RdNSI-0007Ob-1A
	for xen-devel@lists.xensource.com; Wed, 21 Dec 2011 14:47:42 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1324478855!6418532!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzcyNA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10567 invoked from network); 21 Dec 2011 14:47:36 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Dec 2011 14:47:36 -0000
X-IronPort-AV: E=Sophos;i="4.71,388,1320624000"; 
   d="scan'208";a="9612028"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Dec 2011 14:47:35 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 21 Dec 2011 14:47:35 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RdNSB-0002vN-H9; Wed, 21 Dec 2011 14:47:35 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RdNSB-0008PX-DV;
	Wed, 21 Dec 2011 14:47:35 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20209.61831.404644.406603@mariner.uk.xensource.com>
Date: Wed, 21 Dec 2011 14:47:35 +0000
To: Anthony PERARD <anthony.perard@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1324462836-7059-1-git-send-email-anthony.perard@citrix.com>
References: <1324462836-7059-1-git-send-email-anthony.perard@citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Olaf Hering <olaf@aepfle.de>, Xen Devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] libxl: Fix,
	specify open mode to QEMU state file.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Anthony PERARD writes ("[Xen-devel] [PATCH] libxl: Fix, specify open mode to QEMU state file."):
> Reported-by: Olaf Hering <olaf@aepfle.de>
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>

Thanks.

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 21 14:55:46 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 14:55:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdNZe-0007Xy-6i; Wed, 21 Dec 2011 14:55:18 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RdNZc-0007Xm-Dj
	for xen-devel@lists.xensource.com; Wed, 21 Dec 2011 14:55:16 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1324479310!8323549!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzcyNA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5990 invoked from network); 21 Dec 2011 14:55:10 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Dec 2011 14:55:10 -0000
X-IronPort-AV: E=Sophos;i="4.71,388,1320624000"; 
   d="scan'208";a="9612236"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Dec 2011 14:55:09 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 21 Dec 2011 14:55:09 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RdNZV-0002y7-Hy; Wed, 21 Dec 2011 14:55:09 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RdNZV-00006U-Gz;
	Wed, 21 Dec 2011 14:55:09 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20209.62285.443395.3747@mariner.uk.xensource.com>
Date: Wed, 21 Dec 2011 14:55:09 +0000
To: Ian Campbell <ian.campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <3dedf6c82da2bb53d869.1324464547@cosworth.uk.xensource.com>
References: <patchbomb.1324464545@cosworth.uk.xensource.com>
	<3dedf6c82da2bb53d869.1324464547@cosworth.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 2 of 2 V3] libxl: report failure to
 reboot/shutdown due to lackof PV interfaces to caller
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("[Xen-devel] [PATCH 2 of 2 V3] libxl: report failure to reboot/shutdown due to lackof PV interfaces to caller"):
> libxl: report failure to reboot/shutdown due to lackof PV interfaces to caller

Applied both of these, thanks.  (You should make your commit messages
fit in 80 columns; I massaged it for you.)

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 21 14:55:46 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 14:55:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdNZe-0007Xy-6i; Wed, 21 Dec 2011 14:55:18 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RdNZc-0007Xm-Dj
	for xen-devel@lists.xensource.com; Wed, 21 Dec 2011 14:55:16 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1324479310!8323549!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzcyNA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5990 invoked from network); 21 Dec 2011 14:55:10 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Dec 2011 14:55:10 -0000
X-IronPort-AV: E=Sophos;i="4.71,388,1320624000"; 
   d="scan'208";a="9612236"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Dec 2011 14:55:09 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 21 Dec 2011 14:55:09 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RdNZV-0002y7-Hy; Wed, 21 Dec 2011 14:55:09 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RdNZV-00006U-Gz;
	Wed, 21 Dec 2011 14:55:09 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20209.62285.443395.3747@mariner.uk.xensource.com>
Date: Wed, 21 Dec 2011 14:55:09 +0000
To: Ian Campbell <ian.campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <3dedf6c82da2bb53d869.1324464547@cosworth.uk.xensource.com>
References: <patchbomb.1324464545@cosworth.uk.xensource.com>
	<3dedf6c82da2bb53d869.1324464547@cosworth.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 2 of 2 V3] libxl: report failure to
 reboot/shutdown due to lackof PV interfaces to caller
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("[Xen-devel] [PATCH 2 of 2 V3] libxl: report failure to reboot/shutdown due to lackof PV interfaces to caller"):
> libxl: report failure to reboot/shutdown due to lackof PV interfaces to caller

Applied both of these, thanks.  (You should make your commit messages
fit in 80 columns; I massaged it for you.)

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 21 14:57:34 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 14: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.xensource.com>)
	id 1RdNbN-0007d7-Qg; Wed, 21 Dec 2011 14:57:05 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RdNbL-0007cf-G2
	for xen-devel@lists.xensource.com; Wed, 21 Dec 2011 14:57:03 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1324479414!6419614!1
X-Originating-IP: [209.85.160.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17686 invoked from network); 21 Dec 2011 14:56:56 -0000
Received: from mail-pw0-f43.google.com (HELO mail-pw0-f43.google.com)
	(209.85.160.43)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Dec 2011 14:56:56 -0000
Received: by pbbb11 with SMTP id b11so24862092pbb.30
	for <xen-devel@lists.xensource.com>;
	Wed, 21 Dec 2011 06:56:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=q3r9tSNZWYWYxovdSjfWazMaV3Xgdyjd6XHna/l+MLU=;
	b=ZhIfYEjXnK4pHw/Yfx3NwtPKhRHJq3HepxnvSx/kl/XGnHhCYTIUZKYVE15Wfn/sA3
	2tKZq0VPcBPlIc8KaMx/tgjf5HdQl30Fuj3CPKxjrqbZ6QzsmeoCGxPFsREqX3QhpApa
	bhzItAyLgQWDFHjem4pMqqxHQBayrhIvBUEDs=
MIME-Version: 1.0
Received: by 10.68.74.70 with SMTP id r6mr13525971pbv.78.1324479414081; Wed,
	21 Dec 2011 06:56:54 -0800 (PST)
Received: by 10.142.47.17 with HTTP; Wed, 21 Dec 2011 06:56:54 -0800 (PST)
In-Reply-To: <CAEBdQ92w=HkomuqXKdTukPjGrGeJNDmrcXUUMWEMYeRqBwU5vA@mail.gmail.com>
References: <patchbomb.1324347544@alpine.localdomain>
	<14e911353a91702b439b.1324347547@alpine.localdomain>
	<CA+T2pCGZPhLJ1Be28zuYreQcrVNPKvgd9z2HOq2E8CdnYC+a8A@mail.gmail.com>
	<CAEBdQ92w=HkomuqXKdTukPjGrGeJNDmrcXUUMWEMYeRqBwU5vA@mail.gmail.com>
Date: Wed, 21 Dec 2011 15:56:54 +0100
X-Google-Sender-Auth: oF_8q2ZE_iscsO_9EyCVJ0B_LLg
Message-ID: <CAPLaKK4boeR9WyX_KOSVwCw7ZwJQwvoqCNPLsCDxPTF3hmPwuw@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Jean Guyader <jean.guyader@gmail.com>
Cc: William Pitcock <nenolod@dereferenced.org>, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 3 of 4 v2] build: detect is libiconv is
	present
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

2011/12/21 Jean Guyader <jean.guyader@gmail.com>:
> That doesn't work if you do cross compilation, your libraries could
> located in a completely different path.
>
> The best way to check for the presence of a library (and this is how
> the autotools do it) is to generate a very simple C program that uses
> some iconv functions and try to compile it with the currently
> configured compiler. If the compilation succeeded that means the
> library is present.

I'm not sure this is easy to implement without much fuss, given the
way Xen checks for configuration options. What about this:

CONFIG_LIBICONV   := $(shell export OS="`uname -s`"; \
                       export CHECK_LIB="$(CHECK_LIB)"; \
                       . $(XEN_ROOT)/tools/check/funcs.sh; \
                       has_lib libiconv.so && echo 'y' || echo 'n')

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 21 14:57:34 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 14: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.xensource.com>)
	id 1RdNbN-0007d7-Qg; Wed, 21 Dec 2011 14:57:05 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RdNbL-0007cf-G2
	for xen-devel@lists.xensource.com; Wed, 21 Dec 2011 14:57:03 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1324479414!6419614!1
X-Originating-IP: [209.85.160.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17686 invoked from network); 21 Dec 2011 14:56:56 -0000
Received: from mail-pw0-f43.google.com (HELO mail-pw0-f43.google.com)
	(209.85.160.43)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Dec 2011 14:56:56 -0000
Received: by pbbb11 with SMTP id b11so24862092pbb.30
	for <xen-devel@lists.xensource.com>;
	Wed, 21 Dec 2011 06:56:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=q3r9tSNZWYWYxovdSjfWazMaV3Xgdyjd6XHna/l+MLU=;
	b=ZhIfYEjXnK4pHw/Yfx3NwtPKhRHJq3HepxnvSx/kl/XGnHhCYTIUZKYVE15Wfn/sA3
	2tKZq0VPcBPlIc8KaMx/tgjf5HdQl30Fuj3CPKxjrqbZ6QzsmeoCGxPFsREqX3QhpApa
	bhzItAyLgQWDFHjem4pMqqxHQBayrhIvBUEDs=
MIME-Version: 1.0
Received: by 10.68.74.70 with SMTP id r6mr13525971pbv.78.1324479414081; Wed,
	21 Dec 2011 06:56:54 -0800 (PST)
Received: by 10.142.47.17 with HTTP; Wed, 21 Dec 2011 06:56:54 -0800 (PST)
In-Reply-To: <CAEBdQ92w=HkomuqXKdTukPjGrGeJNDmrcXUUMWEMYeRqBwU5vA@mail.gmail.com>
References: <patchbomb.1324347544@alpine.localdomain>
	<14e911353a91702b439b.1324347547@alpine.localdomain>
	<CA+T2pCGZPhLJ1Be28zuYreQcrVNPKvgd9z2HOq2E8CdnYC+a8A@mail.gmail.com>
	<CAEBdQ92w=HkomuqXKdTukPjGrGeJNDmrcXUUMWEMYeRqBwU5vA@mail.gmail.com>
Date: Wed, 21 Dec 2011 15:56:54 +0100
X-Google-Sender-Auth: oF_8q2ZE_iscsO_9EyCVJ0B_LLg
Message-ID: <CAPLaKK4boeR9WyX_KOSVwCw7ZwJQwvoqCNPLsCDxPTF3hmPwuw@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Jean Guyader <jean.guyader@gmail.com>
Cc: William Pitcock <nenolod@dereferenced.org>, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 3 of 4 v2] build: detect is libiconv is
	present
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

2011/12/21 Jean Guyader <jean.guyader@gmail.com>:
> That doesn't work if you do cross compilation, your libraries could
> located in a completely different path.
>
> The best way to check for the presence of a library (and this is how
> the autotools do it) is to generate a very simple C program that uses
> some iconv functions and try to compile it with the currently
> configured compiler. If the compilation succeeded that means the
> library is present.

I'm not sure this is easy to implement without much fuss, given the
way Xen checks for configuration options. What about this:

CONFIG_LIBICONV   := $(shell export OS="`uname -s`"; \
                       export CHECK_LIB="$(CHECK_LIB)"; \
                       . $(XEN_ROOT)/tools/check/funcs.sh; \
                       has_lib libiconv.so && echo 'y' || echo 'n')

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 21 14:57:46 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 14:57:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdNbb-0007eH-7U; Wed, 21 Dec 2011 14:57:19 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RdNba-0007dj-55
	for xen-devel@lists.xensource.com; Wed, 21 Dec 2011 14:57:18 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1324479430!6420217!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14209 invoked from network); 21 Dec 2011 14:57:11 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-4.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Dec 2011 14:57:11 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 21 Dec 2011 14:57:11 +0000
Message-Id: <4EF2020C0200007800069632@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 21 Dec 2011 14:58:04 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Laszlo Ersek" <lersek@redhat.com>
References: <1318970579-6282-1-git-send-email-lersek@redhat.com>
	<4EF1A7A002000078000694CA@nat28.tlf.novell.com>
	<4EF1E4D5.4090301@redhat.com>
In-Reply-To: <4EF1E4D5.4090301@redhat.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, xen-devel@lists.xensource.com,
	Joe Jin <joe.jin@oracle.com>, Zhenzhong Duan <zhenzhong.duan@oracle.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH] remove blocked time accounting from xen
 "clockchip"
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 21.12.11 at 14:53, Laszlo Ersek <lersek@redhat.com> wrote:
> On 12/21/11 09:32, Jan Beulich wrote:
> 
>> Specifically, without further adjustments, on a 4:3 over-committed
>> system doing a kernel build, I'm seeing an over-accounting of
>> approximately 4%. I was able to reduce this to slightly above 1%
>> with below (experimental and not 32-bit compatible) change:
>>
>> --- a/kernel/sched.c
>> +++ b/kernel/sched.c
>> @@ -3864,6 +3864,29 @@
>>   	return ns;
>>   }
>>
>> +#ifndef CONFIG_XEN
>> +#define _cputime_to_cputime64 cputime_to_cputime64
>> +#else
>> +#define NS_PER_TICK (1000000000 / HZ)
>> +static DEFINE_PER_CPU(u64, stolen_snapshot);
>> +static DEFINE_PER_CPU(unsigned int, stolen_residual);
>> +
>> +static cputime64_t _cputime_to_cputime64(cputime_t t)
>> +{
>> +	//todo not entirely suitable for 32-bit
>> +	u64 s = this_cpu_read(runstate.time[RUNSTATE_runnable]);
>> +	unsigned long adj = div_u64_rem(s - this_cpu_read(stolen_snapshot)
>> +					  + this_cpu_read(stolen_residual),
>> +					NS_PER_TICK,
>> +					&__get_cpu_var(stolen_residual));
>> +
>> +	this_cpu_write(stolen_snapshot, s);
>> +	t = cputime_sub(t, jiffies_to_cputime(adj));
>> +
>> +	return cputime_le(t, cputime_max) ? cputime_to_cputime64(t) : 0;
>> +}
>> +#endif
>> +
> 
> Why is this not entirely suitable for 32-bit? div_u64_rem() indeed 
> returns an u64, but for the truncation to do actual damage, the retval 
> (which is the number of ticks that was stolen from the VCPU) would have 
> to be greater than about 4*10^9, which seems improbable with 1 msec long 
> ticks. Also cputime_sub() only depends, in order to leave any underflow 
> detectable, on adj <= cputime_max (cca. 2*10^9). I'm likely looking in 
> the wrong place though.

No, this is not about overflows. The very first this_cpu_read() is what
is problematic on 64-bit - it reads from space updated by the hypervisor,
and hence reading in two halves may get interrupted by an update.
The solution is to use cmpxchg8b here, but I only just now put that
part together.

>>   /*
>>    * Account user cpu time to a process.
>>    * @p: the process that the cpu time gets accounted to
>> @@ -3882,7 +3905,7 @@
>>   	account_group_user_time(p, cputime);
>>
>>   	/* Add user time to cpustat. */
>> -	tmp = cputime_to_cputime64(cputime);
>> +	tmp = _cputime_to_cputime64(cputime);
>>   	if (TASK_NICE(p)>  0)
>>   		cpustat->nice = cputime64_add(cpustat->nice, tmp);
>>   	else
>> @@ -3934,7 +3957,7 @@
>>   void __account_system_time(struct task_struct *p, cputime_t cputime,
>>   			cputime_t cputime_scaled, cputime64_t *target_cputime64)
>>   {
>> -	cputime64_t tmp = cputime_to_cputime64(cputime);
>> +	cputime64_t tmp = _cputime_to_cputime64(cputime);
>>
>>   	/* Add system time to process. */
>>   	p->stime = cputime_add(p->stime, cputime);
>> @@ -3996,7 +4019,7 @@
>>   void account_idle_time(cputime_t cputime)
>>   {
>>   	struct cpu_usage_stat *cpustat =&kstat_this_cpu.cpustat;
>> -	cputime64_t cputime64 = cputime_to_cputime64(cputime);
>> +	cputime64_t cputime64 = _cputime_to_cputime64(cputime);
>>   	struct rq *rq = this_rq();
>>
>>   	if (atomic_read(&rq->nr_iowait)>  0)
>> @@ -4033,7 +4056,7 @@
>>   						struct rq *rq)
>>   {
>>   	cputime_t one_jiffy_scaled = cputime_to_scaled(cputime_one_jiffy);
>> -	cputime64_t tmp = cputime_to_cputime64(cputime_one_jiffy);
>> +	cputime64_t tmp = _cputime_to_cputime64(cputime_one_jiffy);
>>   	struct cpu_usage_stat *cpustat =&kstat_this_cpu.cpustat;
>>
>>   	if (irqtime_account_hi_update()) {
>>
>> I currently have no idea what the remain 1% could be attributed to,
>> so thoughts from others would certainly be welcome.
> 
> What about irqtime_account_process_tick() calling account_idle_time() 
> with "cputime_one_jiffy" -- it could more frequently trigger the 
> underflow in _cputime_to_cputime64(). In that case we might want to 
> decrease idle time (ie. account "negative" cputime against idle), but can't.

I don't think the underflow can actually happen, I just wanted to be
safe by checking for it. If the calculation underflowed, it would mean
that more time was stolen than was spent in the current state (e.g.
idle) prior to the adjustment, which ought to be impossible.

Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 21 14:57:46 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 14:57:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdNbb-0007eH-7U; Wed, 21 Dec 2011 14:57:19 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RdNba-0007dj-55
	for xen-devel@lists.xensource.com; Wed, 21 Dec 2011 14:57:18 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1324479430!6420217!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14209 invoked from network); 21 Dec 2011 14:57:11 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-4.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Dec 2011 14:57:11 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 21 Dec 2011 14:57:11 +0000
Message-Id: <4EF2020C0200007800069632@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 21 Dec 2011 14:58:04 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Laszlo Ersek" <lersek@redhat.com>
References: <1318970579-6282-1-git-send-email-lersek@redhat.com>
	<4EF1A7A002000078000694CA@nat28.tlf.novell.com>
	<4EF1E4D5.4090301@redhat.com>
In-Reply-To: <4EF1E4D5.4090301@redhat.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, xen-devel@lists.xensource.com,
	Joe Jin <joe.jin@oracle.com>, Zhenzhong Duan <zhenzhong.duan@oracle.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH] remove blocked time accounting from xen
 "clockchip"
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 21.12.11 at 14:53, Laszlo Ersek <lersek@redhat.com> wrote:
> On 12/21/11 09:32, Jan Beulich wrote:
> 
>> Specifically, without further adjustments, on a 4:3 over-committed
>> system doing a kernel build, I'm seeing an over-accounting of
>> approximately 4%. I was able to reduce this to slightly above 1%
>> with below (experimental and not 32-bit compatible) change:
>>
>> --- a/kernel/sched.c
>> +++ b/kernel/sched.c
>> @@ -3864,6 +3864,29 @@
>>   	return ns;
>>   }
>>
>> +#ifndef CONFIG_XEN
>> +#define _cputime_to_cputime64 cputime_to_cputime64
>> +#else
>> +#define NS_PER_TICK (1000000000 / HZ)
>> +static DEFINE_PER_CPU(u64, stolen_snapshot);
>> +static DEFINE_PER_CPU(unsigned int, stolen_residual);
>> +
>> +static cputime64_t _cputime_to_cputime64(cputime_t t)
>> +{
>> +	//todo not entirely suitable for 32-bit
>> +	u64 s = this_cpu_read(runstate.time[RUNSTATE_runnable]);
>> +	unsigned long adj = div_u64_rem(s - this_cpu_read(stolen_snapshot)
>> +					  + this_cpu_read(stolen_residual),
>> +					NS_PER_TICK,
>> +					&__get_cpu_var(stolen_residual));
>> +
>> +	this_cpu_write(stolen_snapshot, s);
>> +	t = cputime_sub(t, jiffies_to_cputime(adj));
>> +
>> +	return cputime_le(t, cputime_max) ? cputime_to_cputime64(t) : 0;
>> +}
>> +#endif
>> +
> 
> Why is this not entirely suitable for 32-bit? div_u64_rem() indeed 
> returns an u64, but for the truncation to do actual damage, the retval 
> (which is the number of ticks that was stolen from the VCPU) would have 
> to be greater than about 4*10^9, which seems improbable with 1 msec long 
> ticks. Also cputime_sub() only depends, in order to leave any underflow 
> detectable, on adj <= cputime_max (cca. 2*10^9). I'm likely looking in 
> the wrong place though.

No, this is not about overflows. The very first this_cpu_read() is what
is problematic on 64-bit - it reads from space updated by the hypervisor,
and hence reading in two halves may get interrupted by an update.
The solution is to use cmpxchg8b here, but I only just now put that
part together.

>>   /*
>>    * Account user cpu time to a process.
>>    * @p: the process that the cpu time gets accounted to
>> @@ -3882,7 +3905,7 @@
>>   	account_group_user_time(p, cputime);
>>
>>   	/* Add user time to cpustat. */
>> -	tmp = cputime_to_cputime64(cputime);
>> +	tmp = _cputime_to_cputime64(cputime);
>>   	if (TASK_NICE(p)>  0)
>>   		cpustat->nice = cputime64_add(cpustat->nice, tmp);
>>   	else
>> @@ -3934,7 +3957,7 @@
>>   void __account_system_time(struct task_struct *p, cputime_t cputime,
>>   			cputime_t cputime_scaled, cputime64_t *target_cputime64)
>>   {
>> -	cputime64_t tmp = cputime_to_cputime64(cputime);
>> +	cputime64_t tmp = _cputime_to_cputime64(cputime);
>>
>>   	/* Add system time to process. */
>>   	p->stime = cputime_add(p->stime, cputime);
>> @@ -3996,7 +4019,7 @@
>>   void account_idle_time(cputime_t cputime)
>>   {
>>   	struct cpu_usage_stat *cpustat =&kstat_this_cpu.cpustat;
>> -	cputime64_t cputime64 = cputime_to_cputime64(cputime);
>> +	cputime64_t cputime64 = _cputime_to_cputime64(cputime);
>>   	struct rq *rq = this_rq();
>>
>>   	if (atomic_read(&rq->nr_iowait)>  0)
>> @@ -4033,7 +4056,7 @@
>>   						struct rq *rq)
>>   {
>>   	cputime_t one_jiffy_scaled = cputime_to_scaled(cputime_one_jiffy);
>> -	cputime64_t tmp = cputime_to_cputime64(cputime_one_jiffy);
>> +	cputime64_t tmp = _cputime_to_cputime64(cputime_one_jiffy);
>>   	struct cpu_usage_stat *cpustat =&kstat_this_cpu.cpustat;
>>
>>   	if (irqtime_account_hi_update()) {
>>
>> I currently have no idea what the remain 1% could be attributed to,
>> so thoughts from others would certainly be welcome.
> 
> What about irqtime_account_process_tick() calling account_idle_time() 
> with "cputime_one_jiffy" -- it could more frequently trigger the 
> underflow in _cputime_to_cputime64(). In that case we might want to 
> decrease idle time (ie. account "negative" cputime against idle), but can't.

I don't think the underflow can actually happen, I just wanted to be
safe by checking for it. If the calculation underflowed, it would mean
that more time was stolen than was spent in the current state (e.g.
idle) prior to the adjustment, which ought to be impossible.

Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 21 15:09:10 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 15:09:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdNmk-0008A7-E7; Wed, 21 Dec 2011 15:08:50 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RdNmj-00089z-0O
	for xen-devel@lists.xensource.com; Wed, 21 Dec 2011 15:08:49 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1324480122!8169692!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17616 invoked from network); 21 Dec 2011 15:08:42 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-6.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Dec 2011 15:08:42 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 21 Dec 2011 15:08:42 +0000
Message-Id: <4EF204BF020000780006963F@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 21 Dec 2011 15:09:35 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Roger Pau Monne" <roger.pau@entel.upc.edu>
References: <d61e6300274bbc6bc464.1324354898@alpine.localdomain>
In-Reply-To: <d61e6300274bbc6bc464.1324354898@alpine.localdomain>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] ipxe: update to upstream version
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 20.12.11 at 05:21, Roger Pau Monne <roger.pau@entel.upc.edu> wrote:
> --- a/tools/firmware/etherboot/Makefile	Fri Dec 09 16:19:36 2011 +0000
> +++ b/tools/firmware/etherboot/Makefile	Tue Dec 20 05:20:02 2011 +0100
> @@ -10,9 +10,7 @@ else
>  IPXE_GIT_URL := git://git.ipxe.org/ipxe.git
>  endif
>  
> -IPXE_GIT_TAG := v1.0.0
> -
> -IPXE_TARBALL_URL := $(XEN_EXTFILES_URL)/ipxe-git-$(IPXE_GIT_TAG).tar.gz
> +IPXE_GIT_TREE := 540e5960dc6b49eacf367f7c319fd0546474b845

Is "TREE" really a meaningful name tag here? "COMMIT" would seem
more reasonable to me.

>  
>  D=ipxe
>  T=ipxe.tar.gz
> @@ -35,12 +33,10 @@ eb-roms.h: Config
>  	mv -f $@.new $@
>  
>  $T:
> -	if ! wget -O _$T $(IPXE_TARBALL_URL); then \
> -		$(GIT) clone $(IPXE_GIT_URL) $D.git; \
> -		(cd $D.git && $(GIT) archive --format=tar --prefix=$D/ \
> -		$(IPXE_GIT_TAG) | gzip >../_$T); \
> -		rm -rf $D.git; \
> -	fi
> +	$(GIT) clone $(IPXE_GIT_URL) $D.git; \
> +	(cd $D.git && $(GIT) archive --format=tar --prefix=$D/ \
> +	$(IPXE_GIT_TREE) | gzip >../_$T); \
> +	rm -rf $D.git; \
>  	mv _$T $T
>  
>  $D/src/arch/i386/Makefile: $T Config

Please retain the option to have a tarball, so one can easily point
this to some local file (and not require a functional network, nor
having to tolerate the slowness of the cloning process, nor having
to have git installed everywhere).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 21 15:09:10 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 15:09:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdNmk-0008A7-E7; Wed, 21 Dec 2011 15:08:50 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RdNmj-00089z-0O
	for xen-devel@lists.xensource.com; Wed, 21 Dec 2011 15:08:49 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1324480122!8169692!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17616 invoked from network); 21 Dec 2011 15:08:42 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-6.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Dec 2011 15:08:42 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 21 Dec 2011 15:08:42 +0000
Message-Id: <4EF204BF020000780006963F@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 21 Dec 2011 15:09:35 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Roger Pau Monne" <roger.pau@entel.upc.edu>
References: <d61e6300274bbc6bc464.1324354898@alpine.localdomain>
In-Reply-To: <d61e6300274bbc6bc464.1324354898@alpine.localdomain>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] ipxe: update to upstream version
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 20.12.11 at 05:21, Roger Pau Monne <roger.pau@entel.upc.edu> wrote:
> --- a/tools/firmware/etherboot/Makefile	Fri Dec 09 16:19:36 2011 +0000
> +++ b/tools/firmware/etherboot/Makefile	Tue Dec 20 05:20:02 2011 +0100
> @@ -10,9 +10,7 @@ else
>  IPXE_GIT_URL := git://git.ipxe.org/ipxe.git
>  endif
>  
> -IPXE_GIT_TAG := v1.0.0
> -
> -IPXE_TARBALL_URL := $(XEN_EXTFILES_URL)/ipxe-git-$(IPXE_GIT_TAG).tar.gz
> +IPXE_GIT_TREE := 540e5960dc6b49eacf367f7c319fd0546474b845

Is "TREE" really a meaningful name tag here? "COMMIT" would seem
more reasonable to me.

>  
>  D=ipxe
>  T=ipxe.tar.gz
> @@ -35,12 +33,10 @@ eb-roms.h: Config
>  	mv -f $@.new $@
>  
>  $T:
> -	if ! wget -O _$T $(IPXE_TARBALL_URL); then \
> -		$(GIT) clone $(IPXE_GIT_URL) $D.git; \
> -		(cd $D.git && $(GIT) archive --format=tar --prefix=$D/ \
> -		$(IPXE_GIT_TAG) | gzip >../_$T); \
> -		rm -rf $D.git; \
> -	fi
> +	$(GIT) clone $(IPXE_GIT_URL) $D.git; \
> +	(cd $D.git && $(GIT) archive --format=tar --prefix=$D/ \
> +	$(IPXE_GIT_TREE) | gzip >../_$T); \
> +	rm -rf $D.git; \
>  	mv _$T $T
>  
>  $D/src/arch/i386/Makefile: $T Config

Please retain the option to have a tarball, so one can easily point
this to some local file (and not require a functional network, nor
having to tolerate the slowness of the cloning process, nor having
to have git installed everywhere).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 21 15:27:06 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 15:27:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdO41-0008PA-C3; Wed, 21 Dec 2011 15:26:41 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RdO3z-0008P5-1F
	for xen-devel@lists.xensource.com; Wed, 21 Dec 2011 15:26:39 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1324481192!8172567!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzcyNA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22626 invoked from network); 21 Dec 2011 15:26:33 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Dec 2011 15:26:33 -0000
X-IronPort-AV: E=Sophos;i="4.71,388,1320624000"; 
   d="scan'208";a="9613402"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Dec 2011 15:25:30 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 21 Dec 2011 15:25:29 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RdO2r-00038X-Iq;
	Wed, 21 Dec 2011 15:25:29 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RdO2r-0004tl-Cz;
	Wed, 21 Dec 2011 15:25:29 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10569-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 21 Dec 2011 15:25:29 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10569: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10569 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10569/

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. 10564
 test-amd64-amd64-xl-winxpsp3  7 windows-install           fail REGR. vs. 10564
 test-amd64-amd64-xl-win7-amd64  7 windows-install         fail REGR. vs. 10564
 test-amd64-i386-xend-winxpsp3  7 windows-install          fail REGR. vs. 10564

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-amd64-xl-sedf-pin 14 guest-localmigrate/x10    fail REGR. vs. 10564
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-amd64-xl-sedf     13 guest-localmigrate.2      fail REGR. vs. 10563
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass

version targeted for testing:
 xen                  73ab77073140
baseline version:
 xen                  e56500f95b6a

------------------------------------------------------------
People who touched revisions under test:
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   24441:73ab77073140
tag:         tip
user:        Jan Beulich <jbeulich@suse.com>
date:        Wed Dec 21 09:20:15 2011 +0100
    
    x86: move some function scope statics into .init.data
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24440:e56500f95b6a
user:        Daniel De Graaf <dgdegra@tycho.nsa.gov>
date:        Tue Dec 20 18:19:53 2011 +0000
    
    flask/policy: Update example policy
    
    Rewrite the example policy to make it easier to understand and
    demonstrate some of the security goals that FLASK can enforce.
    
    Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
    Committed-by: Ian Jackson <ian.jackson.citrix.com>
    
    
========================================
commit 54e24021005458ad0a361c1d83011b751726a94b
Author: Ian Jackson <ian.jackson@eu.citrix.com>
Date:   Thu Dec 8 16:38:06 2011 +0000

    qemu_get_timer: Provide a comment about the behaviour on ts==NULL
    
    Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 21 15:27:06 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 15:27:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdO41-0008PA-C3; Wed, 21 Dec 2011 15:26:41 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RdO3z-0008P5-1F
	for xen-devel@lists.xensource.com; Wed, 21 Dec 2011 15:26:39 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1324481192!8172567!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzcyNA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22626 invoked from network); 21 Dec 2011 15:26:33 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Dec 2011 15:26:33 -0000
X-IronPort-AV: E=Sophos;i="4.71,388,1320624000"; 
   d="scan'208";a="9613402"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Dec 2011 15:25:30 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 21 Dec 2011 15:25:29 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RdO2r-00038X-Iq;
	Wed, 21 Dec 2011 15:25:29 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RdO2r-0004tl-Cz;
	Wed, 21 Dec 2011 15:25:29 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10569-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 21 Dec 2011 15:25:29 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10569: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10569 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10569/

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. 10564
 test-amd64-amd64-xl-winxpsp3  7 windows-install           fail REGR. vs. 10564
 test-amd64-amd64-xl-win7-amd64  7 windows-install         fail REGR. vs. 10564
 test-amd64-i386-xend-winxpsp3  7 windows-install          fail REGR. vs. 10564

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-amd64-xl-sedf-pin 14 guest-localmigrate/x10    fail REGR. vs. 10564
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-amd64-xl-sedf     13 guest-localmigrate.2      fail REGR. vs. 10563
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass

version targeted for testing:
 xen                  73ab77073140
baseline version:
 xen                  e56500f95b6a

------------------------------------------------------------
People who touched revisions under test:
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   24441:73ab77073140
tag:         tip
user:        Jan Beulich <jbeulich@suse.com>
date:        Wed Dec 21 09:20:15 2011 +0100
    
    x86: move some function scope statics into .init.data
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24440:e56500f95b6a
user:        Daniel De Graaf <dgdegra@tycho.nsa.gov>
date:        Tue Dec 20 18:19:53 2011 +0000
    
    flask/policy: Update example policy
    
    Rewrite the example policy to make it easier to understand and
    demonstrate some of the security goals that FLASK can enforce.
    
    Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
    Committed-by: Ian Jackson <ian.jackson.citrix.com>
    
    
========================================
commit 54e24021005458ad0a361c1d83011b751726a94b
Author: Ian Jackson <ian.jackson@eu.citrix.com>
Date:   Thu Dec 8 16:38:06 2011 +0000

    qemu_get_timer: Provide a comment about the behaviour on ts==NULL
    
    Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 21 15:44:34 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 15: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.xensource.com>)
	id 1RdOL2-0000Gs-98; Wed, 21 Dec 2011 15:44:16 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1RdOL0-0000Gk-FK
	for xen-devel@lists.xensource.com; Wed, 21 Dec 2011 15:44:14 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-2.tower-216.messagelabs.com!1324482246!9669324!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.6 required=7.0 tests=BODY_RANDOM_LONG,
  BODY_VIRGIN
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8551 invoked from network); 21 Dec 2011 15:44:08 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-2.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Dec 2011 15:44:08 -0000
Received: from andromeda.dapyr.net (darnok@localhost [127.0.0.1])
	by andromeda.dapyr.net (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id
	pBLFhpST029848
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Wed, 21 Dec 2011 10:43:51 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pBLFhp4O029846;
	Wed, 21 Dec 2011 10:43:51 -0500
Date: Wed, 21 Dec 2011 11:43:51 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: William Cohen <wcohen@redhat.com>
Message-ID: <20111221154350.GA26547@andromeda.dapyr.net>
References: <4ED4069E.7030307@redhat.com>
	<20111128224545.GA7821@andromeda.dapyr.net>
	<4ED54E66.7040209@redhat.com>
	<20111216210922.GA2295@andromeda.dapyr.net>
	<4EF101D5.20600@redhat.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4EF101D5.20600@redhat.com>
User-Agent: Mutt/1.5.9i
Cc: xen-devel@lists.xensource.com,
	oprofile-list <oprofile-list@lists.sourceforge.net>
Subject: Re: [Xen-devel] xenoprof patch for oprofile-0.9.7
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Dec 20, 2011 at 04:44:53PM -0500, William Cohen wrote:
> On 12/16/2011 04:09 PM, Konrad Rzeszutek Wilk wrote:
> > On Tue, Nov 29, 2011 at 04:28:06PM -0500, William Cohen wrote:
> >> On 11/28/2011 05:45 PM, Konrad Rzeszutek Wilk wrote:
> >>> On Mon, Nov 28, 2011 at 05:09:34PM -0500, William Cohen wrote:
> >>>> I am rebasing Fedora rawhide oprofile package to oprofile-0.9.7. The xenoprof patches on http://xenoprof.sourceforge.net/#download look a bit dated. The newest version is for oprofile-0.9.5. 
> >>>
> >>> There was one posted some time ago.. Ah:
> >>> http://www.flyn.org/patches/linux-xen-passive-oprofile/linux-3.0-xen-passive-oprofile.patch.gz
> >>>
> >>> I think that ones works , thought I haven't had a chance to test it
> >>> myself.
> >>>>
> >>>> I massaged the patch oprofile-0.9.5-xen.patch to apply to oprofile-.0.9.7. Attached is that updated patch. Does this look reasonable? Is there a desire to get this into upstream oprofile? Or should the xenoprof patch be dropped?
> >>>
> >>> Well, the desire is to get a performance tool in upstream that works
> >>> with Xen very very very much.
> >>>
> >>> The upstream is using the 'perf' framework which is different from oprofile
> >>> and there hasn't been any patches to take advantage of it.
> >>>
> >>> So to answer your question:
> >>>  1). Its awesome you have posted a patch. Will need to spend some time
> >>>      with it and and with the version that was posted to see if there is
> >>>      something missing. Sadly, the kernel patch is not very
> >>>      upstream-compatible as is. But it will get to folks be able to
> >>>      do some perf analysis instead of using benchmark tools.
> >>
> >> If anyone can exercise the patch and verify that it works well with the current upstream xen, that would be greatly appreciated.
> > 
> > So I tried to do it today but running in trouble of compiling it on
> > Fedora Core 16. You wouldn't have any patches floating around to make it
> > compile? (I used first a virgin 0.9.7 version).
> > 
> > Thanks!
> 
> Hi Konrad,
> 
> Sorry I didn't see this email earlier. 

That is OK.
> 
> The patch applies cleanly to oprofile 0.9.7 and builds on fc17. What was the error you got?  How are you configuring it? You should be able to do something like:

Well, I was getting some errors about the wrong header files, but now
that started it again the errors don't show up.

Could be that I had installed the required libraries/headers in between
when I had the problem and now, but can't recall.

Should get you some details soon to your question. Thanks!
> 
> cd oprofile-0.9.7
> patch -p1 -b < ~/oprofile-0.9.7-xen.patch
> ./autogen.sh
> ./configure --with-kernel-support --enable-gui=qt4 
> 
> Alternative you should be able to down load the src rpm from http://koji.fedoraproject.org/koji/buildinfo?buildID=276310
> 
> then
> 
> yum-builddep oprofile-0.9.7-1.src.rpm
> rpm -Uvh oprofile-0.9.7-1.src.rpm
> cd ~/rpmbuild/SPEC
> rpmbuild -b oprofile.spec
> 
> 
> Will
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 21 15:44:34 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 15: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.xensource.com>)
	id 1RdOL2-0000Gs-98; Wed, 21 Dec 2011 15:44:16 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1RdOL0-0000Gk-FK
	for xen-devel@lists.xensource.com; Wed, 21 Dec 2011 15:44:14 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-2.tower-216.messagelabs.com!1324482246!9669324!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.6 required=7.0 tests=BODY_RANDOM_LONG,
  BODY_VIRGIN
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8551 invoked from network); 21 Dec 2011 15:44:08 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-2.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Dec 2011 15:44:08 -0000
Received: from andromeda.dapyr.net (darnok@localhost [127.0.0.1])
	by andromeda.dapyr.net (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id
	pBLFhpST029848
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Wed, 21 Dec 2011 10:43:51 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pBLFhp4O029846;
	Wed, 21 Dec 2011 10:43:51 -0500
Date: Wed, 21 Dec 2011 11:43:51 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: William Cohen <wcohen@redhat.com>
Message-ID: <20111221154350.GA26547@andromeda.dapyr.net>
References: <4ED4069E.7030307@redhat.com>
	<20111128224545.GA7821@andromeda.dapyr.net>
	<4ED54E66.7040209@redhat.com>
	<20111216210922.GA2295@andromeda.dapyr.net>
	<4EF101D5.20600@redhat.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4EF101D5.20600@redhat.com>
User-Agent: Mutt/1.5.9i
Cc: xen-devel@lists.xensource.com,
	oprofile-list <oprofile-list@lists.sourceforge.net>
Subject: Re: [Xen-devel] xenoprof patch for oprofile-0.9.7
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Dec 20, 2011 at 04:44:53PM -0500, William Cohen wrote:
> On 12/16/2011 04:09 PM, Konrad Rzeszutek Wilk wrote:
> > On Tue, Nov 29, 2011 at 04:28:06PM -0500, William Cohen wrote:
> >> On 11/28/2011 05:45 PM, Konrad Rzeszutek Wilk wrote:
> >>> On Mon, Nov 28, 2011 at 05:09:34PM -0500, William Cohen wrote:
> >>>> I am rebasing Fedora rawhide oprofile package to oprofile-0.9.7. The xenoprof patches on http://xenoprof.sourceforge.net/#download look a bit dated. The newest version is for oprofile-0.9.5. 
> >>>
> >>> There was one posted some time ago.. Ah:
> >>> http://www.flyn.org/patches/linux-xen-passive-oprofile/linux-3.0-xen-passive-oprofile.patch.gz
> >>>
> >>> I think that ones works , thought I haven't had a chance to test it
> >>> myself.
> >>>>
> >>>> I massaged the patch oprofile-0.9.5-xen.patch to apply to oprofile-.0.9.7. Attached is that updated patch. Does this look reasonable? Is there a desire to get this into upstream oprofile? Or should the xenoprof patch be dropped?
> >>>
> >>> Well, the desire is to get a performance tool in upstream that works
> >>> with Xen very very very much.
> >>>
> >>> The upstream is using the 'perf' framework which is different from oprofile
> >>> and there hasn't been any patches to take advantage of it.
> >>>
> >>> So to answer your question:
> >>>  1). Its awesome you have posted a patch. Will need to spend some time
> >>>      with it and and with the version that was posted to see if there is
> >>>      something missing. Sadly, the kernel patch is not very
> >>>      upstream-compatible as is. But it will get to folks be able to
> >>>      do some perf analysis instead of using benchmark tools.
> >>
> >> If anyone can exercise the patch and verify that it works well with the current upstream xen, that would be greatly appreciated.
> > 
> > So I tried to do it today but running in trouble of compiling it on
> > Fedora Core 16. You wouldn't have any patches floating around to make it
> > compile? (I used first a virgin 0.9.7 version).
> > 
> > Thanks!
> 
> Hi Konrad,
> 
> Sorry I didn't see this email earlier. 

That is OK.
> 
> The patch applies cleanly to oprofile 0.9.7 and builds on fc17. What was the error you got?  How are you configuring it? You should be able to do something like:

Well, I was getting some errors about the wrong header files, but now
that started it again the errors don't show up.

Could be that I had installed the required libraries/headers in between
when I had the problem and now, but can't recall.

Should get you some details soon to your question. Thanks!
> 
> cd oprofile-0.9.7
> patch -p1 -b < ~/oprofile-0.9.7-xen.patch
> ./autogen.sh
> ./configure --with-kernel-support --enable-gui=qt4 
> 
> Alternative you should be able to down load the src rpm from http://koji.fedoraproject.org/koji/buildinfo?buildID=276310
> 
> then
> 
> yum-builddep oprofile-0.9.7-1.src.rpm
> rpm -Uvh oprofile-0.9.7-1.src.rpm
> cd ~/rpmbuild/SPEC
> rpmbuild -b oprofile.spec
> 
> 
> Will
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 21 15:47:25 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 15:47:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdONn-0000Mf-Rp; Wed, 21 Dec 2011 15:47:07 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RdONl-0000MN-Oe
	for xen-devel@lists.xensource.com; Wed, 21 Dec 2011 15:47:05 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1324482417!6442406!1
X-Originating-IP: [209.85.160.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17403 invoked from network); 21 Dec 2011 15:46:59 -0000
Received: from mail-pw0-f43.google.com (HELO mail-pw0-f43.google.com)
	(209.85.160.43)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Dec 2011 15:46:59 -0000
Received: by pbbb11 with SMTP id b11so24968895pbb.30
	for <xen-devel@lists.xensource.com>;
	Wed, 21 Dec 2011 07:46:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=SR7MH71CRXEaS3RPoEONYc0ahmNMOE40wD0gblUBx6c=;
	b=kJhGbtFsFglbzcj+Gab+iCo0UAj8rXVJDlzdbb5zmi5ECDvveL4S19Fq7S4G6VP2th
	fcEUVWDRkwmd+nrisYJrDAdBpO8v5gXvoPqBNObJFRVotpH57svgOxBRLg3aX04lvvHF
	dJQHWVpskHX14THUlp83Nbn9gt0Tsb4TMwI9M=
MIME-Version: 1.0
Received: by 10.68.190.226 with SMTP id gt2mr13795988pbc.112.1324482417229;
	Wed, 21 Dec 2011 07:46:57 -0800 (PST)
Received: by 10.142.47.17 with HTTP; Wed, 21 Dec 2011 07:46:57 -0800 (PST)
In-Reply-To: <4EF204BF020000780006963F@nat28.tlf.novell.com>
References: <d61e6300274bbc6bc464.1324354898@alpine.localdomain>
	<4EF204BF020000780006963F@nat28.tlf.novell.com>
Date: Wed, 21 Dec 2011 16:46:57 +0100
X-Google-Sender-Auth: BLMI4-dMbQFw7p8JBWzJxhTg1-A
Message-ID: <CAPLaKK4PxrRscS8Wz60mC4gSLad1vPFc4epJwdBPk=URm_uJHw@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Jan Beulich <JBeulich@suse.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] ipxe: update to upstream version
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

MjAxMS8xMi8yMSBKYW4gQmV1bGljaCA8SkJldWxpY2hAc3VzZS5jb20+Ogo+Pj4+IE9uIDIwLjEy
LjExIGF0IDA1OjIxLCBSb2dlciBQYXUgTW9ubmUgPHJvZ2VyLnBhdUBlbnRlbC51cGMuZWR1PiB3
cm90ZToKPj4gLS0tIGEvdG9vbHMvZmlybXdhcmUvZXRoZXJib290L01ha2VmaWxlIMKgIMKgIMKg
IEZyaSBEZWMgMDkgMTY6MTk6MzYgMjAxMSArMDAwMAo+PiArKysgYi90b29scy9maXJtd2FyZS9l
dGhlcmJvb3QvTWFrZWZpbGUgwqAgwqAgwqAgVHVlIERlYyAyMCAwNToyMDowMiAyMDExICswMTAw
Cj4+IEBAIC0xMCw5ICsxMCw3IEBAIGVsc2UKPj4gwqBJUFhFX0dJVF9VUkwgOj0gZ2l0Oi8vZ2l0
LmlweGUub3JnL2lweGUuZ2l0Cj4+IMKgZW5kaWYKPj4KPj4gLUlQWEVfR0lUX1RBRyA6PSB2MS4w
LjAKPj4gLQo+PiAtSVBYRV9UQVJCQUxMX1VSTCA6PSAkKFhFTl9FWFRGSUxFU19VUkwpL2lweGUt
Z2l0LSQoSVBYRV9HSVRfVEFHKS50YXIuZ3oKPj4gK0lQWEVfR0lUX1RSRUUgOj0gNTQwZTU5NjBk
YzZiNDllYWNmMzY3ZjdjMzE5ZmQwNTQ2NDc0Yjg0NQo+Cj4gSXMgIlRSRUUiIHJlYWxseSBhIG1l
YW5pbmdmdWwgbmFtZSB0YWcgaGVyZT8gIkNPTU1JVCIgd291bGQgc2VlbQo+IG1vcmUgcmVhc29u
YWJsZSB0byBtZS4KCldlbGwgdGhpcyBoYXNoIGlzIGFjdHVhbGx5IHRoZSB0cmVlIGhhc2gsIG5v
dCB0aGUgY29tbWl0IGhhc2gsIHNlZToKCmh0dHBzOi8vZ2l0LmlweGUub3JnL2lweGUuZ2l0L2Nv
bW1pdC85YTkzZGIzZjA5NDc0ODRlMzBlNzUzYmJkNjFhMTBiMTczMzZlMjBlCgo+Pgo+PiDCoEQ9
aXB4ZQo+PiDCoFQ9aXB4ZS50YXIuZ3oKPj4gQEAgLTM1LDEyICszMywxMCBAQCBlYi1yb21zLmg6
IENvbmZpZwo+PiDCoCDCoCDCoCBtdiAtZiAkQC5uZXcgJEAKPj4KPj4gwqAkVDoKPj4gLSDCoCDC
oCBpZiAhIHdnZXQgLU8gXyRUICQoSVBYRV9UQVJCQUxMX1VSTCk7IHRoZW4gXAo+PiAtIMKgIMKg
IMKgIMKgIMKgIMKgICQoR0lUKSBjbG9uZSAkKElQWEVfR0lUX1VSTCkgJEQuZ2l0OyBcCj4+IC0g
wqAgwqAgwqAgwqAgwqAgwqAgKGNkICRELmdpdCAmJiAkKEdJVCkgYXJjaGl2ZSAtLWZvcm1hdD10
YXIgLS1wcmVmaXg9JEQvIFwKPj4gLSDCoCDCoCDCoCDCoCDCoCDCoCAkKElQWEVfR0lUX1RBRykg
fCBnemlwID4uLi9fJFQpOyBcCj4+IC0gwqAgwqAgwqAgwqAgwqAgwqAgcm0gLXJmICRELmdpdDsg
XAo+PiAtIMKgIMKgIGZpCj4+ICsgwqAgwqAgJChHSVQpIGNsb25lICQoSVBYRV9HSVRfVVJMKSAk
RC5naXQ7IFwKPj4gKyDCoCDCoCAoY2QgJEQuZ2l0ICYmICQoR0lUKSBhcmNoaXZlIC0tZm9ybWF0
PXRhciAtLXByZWZpeD0kRC8gXAo+PiArIMKgIMKgICQoSVBYRV9HSVRfVFJFRSkgfCBnemlwID4u
Li9fJFQpOyBcCj4+ICsgwqAgwqAgcm0gLXJmICRELmdpdDsgXAo+PiDCoCDCoCDCoCBtdiBfJFQg
JFQKPj4KPj4gwqAkRC9zcmMvYXJjaC9pMzg2L01ha2VmaWxlOiAkVCBDb25maWcKPgo+IFBsZWFz
ZSByZXRhaW4gdGhlIG9wdGlvbiB0byBoYXZlIGEgdGFyYmFsbCwgc28gb25lIGNhbiBlYXNpbHkg
cG9pbnQKPiB0aGlzIHRvIHNvbWUgbG9jYWwgZmlsZSAoYW5kIG5vdCByZXF1aXJlIGEgZnVuY3Rp
b25hbCBuZXR3b3JrLCBub3IKPiBoYXZpbmcgdG8gdG9sZXJhdGUgdGhlIHNsb3duZXNzIG9mIHRo
ZSBjbG9uaW5nIHByb2Nlc3MsIG5vciBoYXZpbmcKPiB0byBoYXZlIGdpdCBpbnN0YWxsZWQgZXZl
cnl3aGVyZSkuCgpUaGlzIHBhdGNoIHJldGFpbnMgdGhlIG9wdGlvbiB0byBoYXZlIGEgdGFyYmFs
bCwgaWYgaXQgZmluZHMgYQppcHhlLnRhci5neiwgbm90aGluZyBpcyBkb3dubG9hZGVkLgoKX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1h
aWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuc291cmNlLmNvbQpodHRwOi8vbGlzdHMueGVu
c291cmNlLmNvbS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Wed Dec 21 15:47:25 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 15:47:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdONn-0000Mf-Rp; Wed, 21 Dec 2011 15:47:07 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RdONl-0000MN-Oe
	for xen-devel@lists.xensource.com; Wed, 21 Dec 2011 15:47:05 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1324482417!6442406!1
X-Originating-IP: [209.85.160.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17403 invoked from network); 21 Dec 2011 15:46:59 -0000
Received: from mail-pw0-f43.google.com (HELO mail-pw0-f43.google.com)
	(209.85.160.43)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Dec 2011 15:46:59 -0000
Received: by pbbb11 with SMTP id b11so24968895pbb.30
	for <xen-devel@lists.xensource.com>;
	Wed, 21 Dec 2011 07:46:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=SR7MH71CRXEaS3RPoEONYc0ahmNMOE40wD0gblUBx6c=;
	b=kJhGbtFsFglbzcj+Gab+iCo0UAj8rXVJDlzdbb5zmi5ECDvveL4S19Fq7S4G6VP2th
	fcEUVWDRkwmd+nrisYJrDAdBpO8v5gXvoPqBNObJFRVotpH57svgOxBRLg3aX04lvvHF
	dJQHWVpskHX14THUlp83Nbn9gt0Tsb4TMwI9M=
MIME-Version: 1.0
Received: by 10.68.190.226 with SMTP id gt2mr13795988pbc.112.1324482417229;
	Wed, 21 Dec 2011 07:46:57 -0800 (PST)
Received: by 10.142.47.17 with HTTP; Wed, 21 Dec 2011 07:46:57 -0800 (PST)
In-Reply-To: <4EF204BF020000780006963F@nat28.tlf.novell.com>
References: <d61e6300274bbc6bc464.1324354898@alpine.localdomain>
	<4EF204BF020000780006963F@nat28.tlf.novell.com>
Date: Wed, 21 Dec 2011 16:46:57 +0100
X-Google-Sender-Auth: BLMI4-dMbQFw7p8JBWzJxhTg1-A
Message-ID: <CAPLaKK4PxrRscS8Wz60mC4gSLad1vPFc4epJwdBPk=URm_uJHw@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Jan Beulich <JBeulich@suse.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] ipxe: update to upstream version
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

MjAxMS8xMi8yMSBKYW4gQmV1bGljaCA8SkJldWxpY2hAc3VzZS5jb20+Ogo+Pj4+IE9uIDIwLjEy
LjExIGF0IDA1OjIxLCBSb2dlciBQYXUgTW9ubmUgPHJvZ2VyLnBhdUBlbnRlbC51cGMuZWR1PiB3
cm90ZToKPj4gLS0tIGEvdG9vbHMvZmlybXdhcmUvZXRoZXJib290L01ha2VmaWxlIMKgIMKgIMKg
IEZyaSBEZWMgMDkgMTY6MTk6MzYgMjAxMSArMDAwMAo+PiArKysgYi90b29scy9maXJtd2FyZS9l
dGhlcmJvb3QvTWFrZWZpbGUgwqAgwqAgwqAgVHVlIERlYyAyMCAwNToyMDowMiAyMDExICswMTAw
Cj4+IEBAIC0xMCw5ICsxMCw3IEBAIGVsc2UKPj4gwqBJUFhFX0dJVF9VUkwgOj0gZ2l0Oi8vZ2l0
LmlweGUub3JnL2lweGUuZ2l0Cj4+IMKgZW5kaWYKPj4KPj4gLUlQWEVfR0lUX1RBRyA6PSB2MS4w
LjAKPj4gLQo+PiAtSVBYRV9UQVJCQUxMX1VSTCA6PSAkKFhFTl9FWFRGSUxFU19VUkwpL2lweGUt
Z2l0LSQoSVBYRV9HSVRfVEFHKS50YXIuZ3oKPj4gK0lQWEVfR0lUX1RSRUUgOj0gNTQwZTU5NjBk
YzZiNDllYWNmMzY3ZjdjMzE5ZmQwNTQ2NDc0Yjg0NQo+Cj4gSXMgIlRSRUUiIHJlYWxseSBhIG1l
YW5pbmdmdWwgbmFtZSB0YWcgaGVyZT8gIkNPTU1JVCIgd291bGQgc2VlbQo+IG1vcmUgcmVhc29u
YWJsZSB0byBtZS4KCldlbGwgdGhpcyBoYXNoIGlzIGFjdHVhbGx5IHRoZSB0cmVlIGhhc2gsIG5v
dCB0aGUgY29tbWl0IGhhc2gsIHNlZToKCmh0dHBzOi8vZ2l0LmlweGUub3JnL2lweGUuZ2l0L2Nv
bW1pdC85YTkzZGIzZjA5NDc0ODRlMzBlNzUzYmJkNjFhMTBiMTczMzZlMjBlCgo+Pgo+PiDCoEQ9
aXB4ZQo+PiDCoFQ9aXB4ZS50YXIuZ3oKPj4gQEAgLTM1LDEyICszMywxMCBAQCBlYi1yb21zLmg6
IENvbmZpZwo+PiDCoCDCoCDCoCBtdiAtZiAkQC5uZXcgJEAKPj4KPj4gwqAkVDoKPj4gLSDCoCDC
oCBpZiAhIHdnZXQgLU8gXyRUICQoSVBYRV9UQVJCQUxMX1VSTCk7IHRoZW4gXAo+PiAtIMKgIMKg
IMKgIMKgIMKgIMKgICQoR0lUKSBjbG9uZSAkKElQWEVfR0lUX1VSTCkgJEQuZ2l0OyBcCj4+IC0g
wqAgwqAgwqAgwqAgwqAgwqAgKGNkICRELmdpdCAmJiAkKEdJVCkgYXJjaGl2ZSAtLWZvcm1hdD10
YXIgLS1wcmVmaXg9JEQvIFwKPj4gLSDCoCDCoCDCoCDCoCDCoCDCoCAkKElQWEVfR0lUX1RBRykg
fCBnemlwID4uLi9fJFQpOyBcCj4+IC0gwqAgwqAgwqAgwqAgwqAgwqAgcm0gLXJmICRELmdpdDsg
XAo+PiAtIMKgIMKgIGZpCj4+ICsgwqAgwqAgJChHSVQpIGNsb25lICQoSVBYRV9HSVRfVVJMKSAk
RC5naXQ7IFwKPj4gKyDCoCDCoCAoY2QgJEQuZ2l0ICYmICQoR0lUKSBhcmNoaXZlIC0tZm9ybWF0
PXRhciAtLXByZWZpeD0kRC8gXAo+PiArIMKgIMKgICQoSVBYRV9HSVRfVFJFRSkgfCBnemlwID4u
Li9fJFQpOyBcCj4+ICsgwqAgwqAgcm0gLXJmICRELmdpdDsgXAo+PiDCoCDCoCDCoCBtdiBfJFQg
JFQKPj4KPj4gwqAkRC9zcmMvYXJjaC9pMzg2L01ha2VmaWxlOiAkVCBDb25maWcKPgo+IFBsZWFz
ZSByZXRhaW4gdGhlIG9wdGlvbiB0byBoYXZlIGEgdGFyYmFsbCwgc28gb25lIGNhbiBlYXNpbHkg
cG9pbnQKPiB0aGlzIHRvIHNvbWUgbG9jYWwgZmlsZSAoYW5kIG5vdCByZXF1aXJlIGEgZnVuY3Rp
b25hbCBuZXR3b3JrLCBub3IKPiBoYXZpbmcgdG8gdG9sZXJhdGUgdGhlIHNsb3duZXNzIG9mIHRo
ZSBjbG9uaW5nIHByb2Nlc3MsIG5vciBoYXZpbmcKPiB0byBoYXZlIGdpdCBpbnN0YWxsZWQgZXZl
cnl3aGVyZSkuCgpUaGlzIHBhdGNoIHJldGFpbnMgdGhlIG9wdGlvbiB0byBoYXZlIGEgdGFyYmFs
bCwgaWYgaXQgZmluZHMgYQppcHhlLnRhci5neiwgbm90aGluZyBpcyBkb3dubG9hZGVkLgoKX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1h
aWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuc291cmNlLmNvbQpodHRwOi8vbGlzdHMueGVu
c291cmNlLmNvbS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Wed Dec 21 16:01:16 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 16:01:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdOax-00010e-6W; Wed, 21 Dec 2011 16:00:43 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RdOav-00010Z-Jk
	for xen-devel@lists.xensource.com; Wed, 21 Dec 2011 16:00:42 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1324483233!8166909!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5623 invoked from network); 21 Dec 2011 16:00:34 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-14.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Dec 2011 16:00:34 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 21 Dec 2011 16:01:03 +0000
Message-Id: <4EF210E7020000780006965E@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 21 Dec 2011 16:01:27 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad@darnok.org>,
	"Jeremy Fitzhardinge" <jeremy@goop.org>,
	"Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part113EA0C7.2__="
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	linux-kernel@vger.kernel.org
Subject: [Xen-devel] [PATCH] Xen: consolidate and simplify struct
 xenbus_driver instantiation
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__Part113EA0C7.2__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

The 'name', 'owner', and 'mod_name' members are redundant with the
identically named fields in the 'driver' sub-structure. Rather than
switching each instance to specify these fields explicitly, introduce
a macro to simplify this.

Eliminate further redundancy by allowing the drvname argument to
DEFINE_XENBUS_DRIVER() to be blank (in which case the first entry from
the ID table will be used for .driver.name).

Also eliminate the questionable xenbus_register_{back,front}end()
wrappers - their sole remaining purpose was the checking of the
'owner' field, proper setting of which shouldn't be an issue anymore
when the macro gets used.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

---
 drivers/block/xen-blkback/xenbus.c         |    9 ++------
 drivers/block/xen-blkfront.c               |   11 +++-------
 drivers/input/misc/xen-kbdfront.c          |    7 +-----
 drivers/net/xen-netback/xenbus.c           |    9 ++------
 drivers/net/xen-netfront.c                 |    9 ++------
 drivers/pci/xen-pcifront.c                 |   11 +++-------
 drivers/video/xen-fbfront.c                |    9 ++------
 drivers/xen/xen-pciback/xenbus.c           |   13 ++++--------
 drivers/xen/xenbus/xenbus_probe.c          |    7 ------
 drivers/xen/xenbus/xenbus_probe.h          |    4 ---
 drivers/xen/xenbus/xenbus_probe_backend.c  |    8 ++-----
 drivers/xen/xenbus/xenbus_probe_frontend.c |    8 ++-----
 include/xen/xenbus.h                       |   31 ++++++++----------------=
-----
 13 files changed, 44 insertions(+), 92 deletions(-)

--- 3.2-rc6/drivers/block/xen-blkback/xenbus.c
+++ 3.2-rc6-struct-xenbus_driver/drivers/block/xen-blkback/xenbus.c
@@ -787,17 +787,14 @@ static const struct xenbus_device_id xen
 };
=20
=20
-static struct xenbus_driver xen_blkbk =3D {
-	.name =3D "vbd",
-	.owner =3D THIS_MODULE,
-	.ids =3D xen_blkbk_ids,
+static DEFINE_XENBUS_DRIVER(xen_blkbk, ,
 	.probe =3D xen_blkbk_probe,
 	.remove =3D xen_blkbk_remove,
 	.otherend_changed =3D frontend_changed
-};
+);
=20
=20
 int xen_blkif_xenbus_init(void)
 {
-	return xenbus_register_backend(&xen_blkbk);
+	return xenbus_register_backend(&xen_blkbk_driver);
 }
--- 3.2-rc6/drivers/block/xen-blkfront.c
+++ 3.2-rc6-struct-xenbus_driver/drivers/block/xen-blkfront.c
@@ -1437,16 +1437,13 @@ static const struct xenbus_device_id blk
 	{ "" }
 };
=20
-static struct xenbus_driver blkfront =3D {
-	.name =3D "vbd",
-	.owner =3D THIS_MODULE,
-	.ids =3D blkfront_ids,
+static DEFINE_XENBUS_DRIVER(blkfront, ,
 	.probe =3D blkfront_probe,
 	.remove =3D blkfront_remove,
 	.resume =3D blkfront_resume,
 	.otherend_changed =3D blkback_changed,
 	.is_ready =3D blkfront_is_ready,
-};
+);
=20
 static int __init xlblk_init(void)
 {
@@ -1461,7 +1458,7 @@ static int __init xlblk_init(void)
 		return -ENODEV;
 	}
=20
-	ret =3D xenbus_register_frontend(&blkfront);
+	ret =3D xenbus_register_frontend(&blkfront_driver);
 	if (ret) {
 		unregister_blkdev(XENVBD_MAJOR, DEV_NAME);
 		return ret;
@@ -1474,7 +1471,7 @@ module_init(xlblk_init);
=20
 static void __exit xlblk_exit(void)
 {
-	return xenbus_unregister_driver(&blkfront);
+	return xenbus_unregister_driver(&blkfront_driver);
 }
 module_exit(xlblk_exit);
=20
--- 3.2-rc6/drivers/input/misc/xen-kbdfront.c
+++ 3.2-rc6-struct-xenbus_driver/drivers/input/misc/xen-kbdfront.c
@@ -361,15 +361,12 @@ static const struct xenbus_device_id xen
 	{ "" }
 };
=20
-static struct xenbus_driver xenkbd_driver =3D {
-	.name =3D "vkbd",
-	.owner =3D THIS_MODULE,
-	.ids =3D xenkbd_ids,
+static DEFINE_XENBUS_DRIVER(xenkbd, ,
 	.probe =3D xenkbd_probe,
 	.remove =3D xenkbd_remove,
 	.resume =3D xenkbd_resume,
 	.otherend_changed =3D xenkbd_backend_changed,
-};
+);
=20
 static int __init xenkbd_init(void)
 {
--- 3.2-rc6/drivers/net/xen-netback/xenbus.c
+++ 3.2-rc6-struct-xenbus_driver/drivers/net/xen-netback/xenbus.c
@@ -474,17 +474,14 @@ static const struct xenbus_device_id net
 };
=20
=20
-static struct xenbus_driver netback =3D {
-	.name =3D "vif",
-	.owner =3D THIS_MODULE,
-	.ids =3D netback_ids,
+static DEFINE_XENBUS_DRIVER(netback, ,
 	.probe =3D netback_probe,
 	.remove =3D netback_remove,
 	.uevent =3D netback_uevent,
 	.otherend_changed =3D frontend_changed,
-};
+);
=20
 int xenvif_xenbus_init(void)
 {
-	return xenbus_register_backend(&netback);
+	return xenbus_register_backend(&netback_driver);
 }
--- 3.2-rc6/drivers/net/xen-netfront.c
+++ 3.2-rc6-struct-xenbus_driver/drivers/net/xen-netfront.c
@@ -1910,7 +1910,7 @@ static void xennet_sysfs_delif(struct ne
=20
 #endif /* CONFIG_SYSFS */
=20
-static struct xenbus_device_id netfront_ids[] =3D {
+static const struct xenbus_device_id netfront_ids[] =3D {
 	{ "vif" },
 	{ "" }
 };
@@ -1937,15 +1937,12 @@ static int __devexit xennet_remove(struc
 	return 0;
 }
=20
-static struct xenbus_driver netfront_driver =3D {
-	.name =3D "vif",
-	.owner =3D THIS_MODULE,
-	.ids =3D netfront_ids,
+static DEFINE_XENBUS_DRIVER(netfront, ,
 	.probe =3D netfront_probe,
 	.remove =3D __devexit_p(xennet_remove),
 	.resume =3D netfront_resume,
 	.otherend_changed =3D netback_changed,
-};
+);
=20
 static int __init netif_init(void)
 {
--- 3.2-rc6/drivers/pci/xen-pcifront.c
+++ 3.2-rc6-struct-xenbus_driver/drivers/pci/xen-pcifront.c
@@ -1126,14 +1126,11 @@ static const struct xenbus_device_id xen
 	{""},
 };
=20
-static struct xenbus_driver xenbus_pcifront_driver =3D {
-	.name			=3D "pcifront",
-	.owner			=3D THIS_MODULE,
-	.ids			=3D xenpci_ids,
+static DEFINE_XENBUS_DRIVER(xenpci, "pcifront",
 	.probe			=3D pcifront_xenbus_probe,
 	.remove			=3D pcifront_xenbus_remove,
 	.otherend_changed	=3D pcifront_backend_changed,
-};
+);
=20
 static int __init pcifront_init(void)
 {
@@ -1142,12 +1139,12 @@ static int __init pcifront_init(void)
=20
 	pci_frontend_registrar(1 /* enable */);
=20
-	return xenbus_register_frontend(&xenbus_pcifront_driver);
+	return xenbus_register_frontend(&xenpci_driver);
 }
=20
 static void __exit pcifront_cleanup(void)
 {
-	xenbus_unregister_driver(&xenbus_pcifront_driver);
+	xenbus_unregister_driver(&xenpci_driver);
 	pci_frontend_registrar(0 /* disable */);
 }
 module_init(pcifront_init);
--- 3.2-rc6/drivers/video/xen-fbfront.c
+++ 3.2-rc6-struct-xenbus_driver/drivers/video/xen-fbfront.c
@@ -671,20 +671,17 @@ InitWait:
 	}
 }
=20
-static struct xenbus_device_id xenfb_ids[] =3D {
+static const struct xenbus_device_id xenfb_ids[] =3D {
 	{ "vfb" },
 	{ "" }
 };
=20
-static struct xenbus_driver xenfb_driver =3D {
-	.name =3D "vfb",
-	.owner =3D THIS_MODULE,
-	.ids =3D xenfb_ids,
+static DEFINE_XENBUS_DRIVER(xenfb, ,
 	.probe =3D xenfb_probe,
 	.remove =3D xenfb_remove,
 	.resume =3D xenfb_resume,
 	.otherend_changed =3D xenfb_backend_changed,
-};
+);
=20
 static int __init xenfb_init(void)
 {
--- 3.2-rc6/drivers/xen/xen-pciback/xenbus.c
+++ 3.2-rc6-struct-xenbus_driver/drivers/xen/xen-pciback/xenbus.c
@@ -707,19 +707,16 @@ static int xen_pcibk_xenbus_remove(struc
 	return 0;
 }
=20
-static const struct xenbus_device_id xenpci_ids[] =3D {
+static const struct xenbus_device_id xen_pcibk_ids[] =3D {
 	{"pci"},
 	{""},
 };
=20
-static struct xenbus_driver xenbus_xen_pcibk_driver =3D {
-	.name			=3D DRV_NAME,
-	.owner			=3D THIS_MODULE,
-	.ids			=3D xenpci_ids,
+static DEFINE_XENBUS_DRIVER(xen_pcibk, "pciback",
 	.probe			=3D xen_pcibk_xenbus_probe,
 	.remove			=3D xen_pcibk_xenbus_remove,
 	.otherend_changed	=3D xen_pcibk_frontend_changed,
-};
+);
=20
 const struct xen_pcibk_backend *__read_mostly xen_pcibk_backend;
=20
@@ -735,11 +732,11 @@ int __init xen_pcibk_xenbus_register(voi
 	if (passthrough)
 		xen_pcibk_backend =3D &xen_pcibk_passthrough_backend;
 	pr_info(DRV_NAME ": backend is %s\n", xen_pcibk_backend->name);
-	return xenbus_register_backend(&xenbus_xen_pcibk_driver);
+	return xenbus_register_backend(&xen_pcibk_driver);
 }
=20
 void __exit xen_pcibk_xenbus_unregister(void)
 {
 	destroy_workqueue(xen_pcibk_wq);
-	xenbus_unregister_driver(&xenbus_xen_pcibk_driver);
+	xenbus_unregister_driver(&xen_pcibk_driver);
 }
--- 3.2-rc6/drivers/xen/xenbus/xenbus_probe.c
+++ 3.2-rc6-struct-xenbus_driver/drivers/xen/xenbus/xenbus_probe.c
@@ -291,14 +291,9 @@ void xenbus_dev_shutdown(struct device *
 EXPORT_SYMBOL_GPL(xenbus_dev_shutdown);
=20
 int xenbus_register_driver_common(struct xenbus_driver *drv,
-				  struct xen_bus_type *bus,
-				  struct module *owner,
-				  const char *mod_name)
+				  struct xen_bus_type *bus)
 {
-	drv->driver.name =3D drv->name;
 	drv->driver.bus =3D &bus->bus;
-	drv->driver.owner =3D owner;
-	drv->driver.mod_name =3D mod_name;
=20
 	return driver_register(&drv->driver);
 }
--- 3.2-rc6/drivers/xen/xenbus/xenbus_probe.h
+++ 3.2-rc6-struct-xenbus_driver/drivers/xen/xenbus/xenbus_probe.h
@@ -53,9 +53,7 @@ extern int xenbus_match(struct device *_
 extern int xenbus_dev_probe(struct device *_dev);
 extern int xenbus_dev_remove(struct device *_dev);
 extern int xenbus_register_driver_common(struct xenbus_driver *drv,
-					 struct xen_bus_type *bus,
-					 struct module *owner,
-					 const char *mod_name);
+					 struct xen_bus_type *bus);
 extern int xenbus_probe_node(struct xen_bus_type *bus,
 			     const char *type,
 			     const char *nodename);
--- 3.2-rc6/drivers/xen/xenbus/xenbus_probe_backend.c
+++ 3.2-rc6-struct-xenbus_driver/drivers/xen/xenbus/xenbus_probe_backend.c
@@ -232,15 +232,13 @@ int xenbus_dev_is_online(struct xenbus_d
 }
 EXPORT_SYMBOL_GPL(xenbus_dev_is_online);
=20
-int __xenbus_register_backend(struct xenbus_driver *drv,
-			      struct module *owner, const char *mod_name)
+int xenbus_register_backend(struct xenbus_driver *drv)
 {
 	drv->read_otherend_details =3D read_frontend_details;
=20
-	return xenbus_register_driver_common(drv, &xenbus_backend,
-					     owner, mod_name);
+	return xenbus_register_driver_common(drv, &xenbus_backend);
 }
-EXPORT_SYMBOL_GPL(__xenbus_register_backend);
+EXPORT_SYMBOL_GPL(xenbus_register_backend);
=20
 static int backend_probe_and_watch(struct notifier_block *notifier,
 				   unsigned long event,
--- 3.2-rc6/drivers/xen/xenbus/xenbus_probe_frontend.c
+++ 3.2-rc6-struct-xenbus_driver/drivers/xen/xenbus/xenbus_probe_frontend.c=

@@ -230,15 +230,13 @@ static void wait_for_devices(struct xenb
 			 print_device_status);
 }
=20
-int __xenbus_register_frontend(struct xenbus_driver *drv,
-			       struct module *owner, const char *mod_name)
+int xenbus_register_frontend(struct xenbus_driver *drv)
 {
 	int ret;
=20
 	drv->read_otherend_details =3D read_backend_details;
=20
-	ret =3D xenbus_register_driver_common(drv, &xenbus_frontend,
-					    owner, mod_name);
+	ret =3D xenbus_register_driver_common(drv, &xenbus_frontend);
 	if (ret)
 		return ret;
=20
@@ -247,7 +245,7 @@ int __xenbus_register_frontend(struct xe
=20
 	return 0;
 }
-EXPORT_SYMBOL_GPL(__xenbus_register_frontend);
+EXPORT_SYMBOL_GPL(xenbus_register_frontend);
=20
 static DECLARE_WAIT_QUEUE_HEAD(backend_state_wq);
 static int backend_state;
--- 3.2-rc6/include/xen/xenbus.h
+++ 3.2-rc6-struct-xenbus_driver/include/xen/xenbus.h
@@ -85,8 +85,6 @@ struct xenbus_device_id
=20
 /* A xenbus driver. */
 struct xenbus_driver {
-	char *name;
-	struct module *owner;
 	const struct xenbus_device_id *ids;
 	int (*probe)(struct xenbus_device *dev,
 		     const struct xenbus_device_id *id);
@@ -101,31 +99,20 @@ struct xenbus_driver {
 	int (*is_ready)(struct xenbus_device *dev);
 };
=20
-static inline struct xenbus_driver *to_xenbus_driver(struct device_driver =
*drv)
-{
-	return container_of(drv, struct xenbus_driver, driver);
+#define DEFINE_XENBUS_DRIVER(var, drvname, methods...)		\
+struct xenbus_driver var ## _driver =3D {				\
+	.driver.name =3D drvname + 0 ?: var ## _ids->devicetype,	\
+	.driver.owner =3D THIS_MODULE,				\
+	.ids =3D var ## _ids, ## methods				\
 }
=20
-int __must_check __xenbus_register_frontend(struct xenbus_driver *drv,
-					    struct module *owner,
-					    const char *mod_name);
-
-static inline int __must_check
-xenbus_register_frontend(struct xenbus_driver *drv)
+static inline struct xenbus_driver *to_xenbus_driver(struct device_driver =
*drv)
 {
-	WARN_ON(drv->owner !=3D THIS_MODULE);
-	return __xenbus_register_frontend(drv, THIS_MODULE, KBUILD_MODNAME)=
;
+	return container_of(drv, struct xenbus_driver, driver);
 }
=20
-int __must_check __xenbus_register_backend(struct xenbus_driver *drv,
-					   struct module *owner,
-					   const char *mod_name);
-static inline int __must_check
-xenbus_register_backend(struct xenbus_driver *drv)
-{
-	WARN_ON(drv->owner !=3D THIS_MODULE);
-	return __xenbus_register_backend(drv, THIS_MODULE, KBUILD_MODNAME);=

-}
+int __must_check xenbus_register_frontend(struct xenbus_driver *);
+int __must_check xenbus_register_backend(struct xenbus_driver *);
=20
 void xenbus_unregister_driver(struct xenbus_driver *drv);
=20



--=__Part113EA0C7.2__=
Content-Type: text/plain; name="linux-3.2-rc6-struct-xenbus_driver.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="linux-3.2-rc6-struct-xenbus_driver.patch"

Xen: consolidate and simplify struct xenbus_driver instantiation=0A=0AThe =
'name', 'owner', and 'mod_name' members are redundant with the=0Aidenticall=
y named fields in the 'driver' sub-structure. Rather than=0Aswitching each =
instance to specify these fields explicitly, introduce=0Aa macro to =
simplify this.=0A=0AEliminate further redundancy by allowing the drvname =
argument to=0ADEFINE_XENBUS_DRIVER() to be blank (in which case the first =
entry from=0Athe ID table will be used for .driver.name).=0A=0AAlso =
eliminate the questionable xenbus_register_{back,front}end()=0Awrappers - =
their sole remaining purpose was the checking of the=0A'owner' field, =
proper setting of which shouldn't be an issue anymore=0Awhen the macro =
gets used.=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=0A=0A---=0A =
drivers/block/xen-blkback/xenbus.c         |    9 ++------=0A drivers/block=
/xen-blkfront.c               |   11 +++-------=0A drivers/input/misc/xen-k=
bdfront.c          |    7 +-----=0A drivers/net/xen-netback/xenbus.c       =
    |    9 ++------=0A drivers/net/xen-netfront.c                 |    9 =
++------=0A drivers/pci/xen-pcifront.c                 |   11 +++-------=0A=
 drivers/video/xen-fbfront.c                |    9 ++------=0A drivers/xen/=
xen-pciback/xenbus.c           |   13 ++++--------=0A drivers/xen/xenbus/xe=
nbus_probe.c          |    7 ------=0A drivers/xen/xenbus/xenbus_probe.h   =
       |    4 ---=0A drivers/xen/xenbus/xenbus_probe_backend.c  |    8 =
++-----=0A drivers/xen/xenbus/xenbus_probe_frontend.c |    8 ++-----=0A =
include/xen/xenbus.h                       |   31 ++++++++-----------------=
----=0A 13 files changed, 44 insertions(+), 92 deletions(-)=0A=0A--- =
3.2-rc6/drivers/block/xen-blkback/xenbus.c=0A+++ 3.2-rc6-struct-xenbus_driv=
er/drivers/block/xen-blkback/xenbus.c=0A@@ -787,17 +787,14 @@ static const =
struct xenbus_device_id xen=0A };=0A =0A =0A-static struct xenbus_driver =
xen_blkbk =3D {=0A-	.name =3D "vbd",=0A-	.owner =3D THIS_MODULE,=0A-=
	.ids =3D xen_blkbk_ids,=0A+static DEFINE_XENBUS_DRIVER(xen_blkbk, =
,=0A 	.probe =3D xen_blkbk_probe,=0A 	.remove =3D xen_blkbk_remove,=0A 	=
.otherend_changed =3D frontend_changed=0A-};=0A+);=0A =0A =0A int =
xen_blkif_xenbus_init(void)=0A {=0A-	return xenbus_register_backend(&xen=
_blkbk);=0A+	return xenbus_register_backend(&xen_blkbk_driver);=0A =
}=0A--- 3.2-rc6/drivers/block/xen-blkfront.c=0A+++ 3.2-rc6-struct-xenbus_dr=
iver/drivers/block/xen-blkfront.c=0A@@ -1437,16 +1437,13 @@ static const =
struct xenbus_device_id blk=0A 	{ "" }=0A };=0A =0A-static struct =
xenbus_driver blkfront =3D {=0A-	.name =3D "vbd",=0A-	.owner =3D =
THIS_MODULE,=0A-	.ids =3D blkfront_ids,=0A+static DEFINE_XENBUS_DRIV=
ER(blkfront, ,=0A 	.probe =3D blkfront_probe,=0A 	.remove =3D =
blkfront_remove,=0A 	.resume =3D blkfront_resume,=0A 	.otherend_c=
hanged =3D blkback_changed,=0A 	.is_ready =3D blkfront_is_ready,=0A-};=0A+)=
;=0A =0A static int __init xlblk_init(void)=0A {=0A@@ -1461,7 +1458,7 @@ =
static int __init xlblk_init(void)=0A 		return -ENODEV;=0A 	=
}=0A =0A-	ret =3D xenbus_register_frontend(&blkfront);=0A+	=
ret =3D xenbus_register_frontend(&blkfront_driver);=0A 	if (ret) {=0A 		=
unregister_blkdev(XENVBD_MAJOR, DEV_NAME);=0A 		return ret;=0A@@ =
-1474,7 +1471,7 @@ module_init(xlblk_init);=0A =0A static void __exit =
xlblk_exit(void)=0A {=0A-	return xenbus_unregister_driver(&blkfront);=
=0A+	return xenbus_unregister_driver(&blkfront_driver);=0A }=0A =
module_exit(xlblk_exit);=0A =0A--- 3.2-rc6/drivers/input/misc/xen-kbdfront.=
c=0A+++ 3.2-rc6-struct-xenbus_driver/drivers/input/misc/xen-kbdfront.c=0A@@=
 -361,15 +361,12 @@ static const struct xenbus_device_id xen=0A 	{ =
"" }=0A };=0A =0A-static struct xenbus_driver xenkbd_driver =3D {=0A-	=
.name =3D "vkbd",=0A-	.owner =3D THIS_MODULE,=0A-	.ids =3D xenkbd_ids=
,=0A+static DEFINE_XENBUS_DRIVER(xenkbd, ,=0A 	.probe =3D xenkbd_probe,=0A=
 	.remove =3D xenkbd_remove,=0A 	.resume =3D xenkbd_resume,=0A 	=
.otherend_changed =3D xenkbd_backend_changed,=0A-};=0A+);=0A =0A static =
int __init xenkbd_init(void)=0A {=0A--- 3.2-rc6/drivers/net/xen-netback/xen=
bus.c=0A+++ 3.2-rc6-struct-xenbus_driver/drivers/net/xen-netback/xenbus.c=
=0A@@ -474,17 +474,14 @@ static const struct xenbus_device_id net=0A };=0A =
=0A =0A-static struct xenbus_driver netback =3D {=0A-	.name =3D =
"vif",=0A-	.owner =3D THIS_MODULE,=0A-	.ids =3D netback_ids,=0A+st=
atic DEFINE_XENBUS_DRIVER(netback, ,=0A 	.probe =3D netback_probe,=
=0A 	.remove =3D netback_remove,=0A 	.uevent =3D netback_uevent,=0A 	=
.otherend_changed =3D frontend_changed,=0A-};=0A+);=0A =0A int xenvif_xenbu=
s_init(void)=0A {=0A-	return xenbus_register_backend(&netback);=0A+	=
return xenbus_register_backend(&netback_driver);=0A }=0A--- 3.2-rc6/drivers=
/net/xen-netfront.c=0A+++ 3.2-rc6-struct-xenbus_driver/drivers/net/xen-netf=
ront.c=0A@@ -1910,7 +1910,7 @@ static void xennet_sysfs_delif(struct ne=0A =
=0A #endif /* CONFIG_SYSFS */=0A =0A-static struct xenbus_device_id =
netfront_ids[] =3D {=0A+static const struct xenbus_device_id netfront_ids[]=
 =3D {=0A 	{ "vif" },=0A 	{ "" }=0A };=0A@@ -1937,15 +1937,12 @@ =
static int __devexit xennet_remove(struc=0A 	return 0;=0A }=0A =
=0A-static struct xenbus_driver netfront_driver =3D {=0A-	.name =3D =
"vif",=0A-	.owner =3D THIS_MODULE,=0A-	.ids =3D netfront_ids,=0A+s=
tatic DEFINE_XENBUS_DRIVER(netfront, ,=0A 	.probe =3D netfront_probe,=
=0A 	.remove =3D __devexit_p(xennet_remove),=0A 	.resume =3D =
netfront_resume,=0A 	.otherend_changed =3D netback_changed,=0A-};=0A+);=
=0A =0A static int __init netif_init(void)=0A {=0A--- 3.2-rc6/drivers/pci/x=
en-pcifront.c=0A+++ 3.2-rc6-struct-xenbus_driver/drivers/pci/xen-pcifront.c=
=0A@@ -1126,14 +1126,11 @@ static const struct xenbus_device_id xen=0A 	=
{""},=0A };=0A =0A-static struct xenbus_driver xenbus_pcifront_driver =3D =
{=0A-	.name			=3D "pcifront",=0A-	.owner			=
=3D THIS_MODULE,=0A-	.ids			=3D xenpci_ids,=0A+static =
DEFINE_XENBUS_DRIVER(xenpci, "pcifront",=0A 	.probe			=
=3D pcifront_xenbus_probe,=0A 	.remove			=3D pcifront_xenbus=
_remove,=0A 	.otherend_changed	=3D pcifront_backend_changed,=0A-};=
=0A+);=0A =0A static int __init pcifront_init(void)=0A {=0A@@ -1142,12 =
+1139,12 @@ static int __init pcifront_init(void)=0A =0A 	pci_fronten=
d_registrar(1 /* enable */);=0A =0A-	return xenbus_register_frontend(&xe=
nbus_pcifront_driver);=0A+	return xenbus_register_frontend(&xenpci_dri=
ver);=0A }=0A =0A static void __exit pcifront_cleanup(void)=0A {=0A-	=
xenbus_unregister_driver(&xenbus_pcifront_driver);=0A+	xenbus_unregister_d=
river(&xenpci_driver);=0A 	pci_frontend_registrar(0 /* disable =
*/);=0A }=0A module_init(pcifront_init);=0A--- 3.2-rc6/drivers/video/xen-fb=
front.c=0A+++ 3.2-rc6-struct-xenbus_driver/drivers/video/xen-fbfront.c=0A@@=
 -671,20 +671,17 @@ InitWait:=0A 	}=0A }=0A =0A-static struct =
xenbus_device_id xenfb_ids[] =3D {=0A+static const struct xenbus_device_id =
xenfb_ids[] =3D {=0A 	{ "vfb" },=0A 	{ "" }=0A };=0A =0A-static struct =
xenbus_driver xenfb_driver =3D {=0A-	.name =3D "vfb",=0A-	.owner =3D =
THIS_MODULE,=0A-	.ids =3D xenfb_ids,=0A+static DEFINE_XENBUS_DRIVER(=
xenfb, ,=0A 	.probe =3D xenfb_probe,=0A 	.remove =3D xenfb_remove,=
=0A 	.resume =3D xenfb_resume,=0A 	.otherend_changed =3D xenfb_backend=
_changed,=0A-};=0A+);=0A =0A static int __init xenfb_init(void)=0A {=0A--- =
3.2-rc6/drivers/xen/xen-pciback/xenbus.c=0A+++ 3.2-rc6-struct-xenbus_driver=
/drivers/xen/xen-pciback/xenbus.c=0A@@ -707,19 +707,16 @@ static int =
xen_pcibk_xenbus_remove(struc=0A 	return 0;=0A }=0A =0A-static const =
struct xenbus_device_id xenpci_ids[] =3D {=0A+static const struct =
xenbus_device_id xen_pcibk_ids[] =3D {=0A 	{"pci"},=0A 	{""},=0A =
};=0A =0A-static struct xenbus_driver xenbus_xen_pcibk_driver =3D {=0A-	=
.name			=3D DRV_NAME,=0A-	.owner			=
=3D THIS_MODULE,=0A-	.ids			=3D xenpci_ids,=0A+static =
DEFINE_XENBUS_DRIVER(xen_pcibk, "pciback",=0A 	.probe			=
=3D xen_pcibk_xenbus_probe,=0A 	.remove			=3D xen_pcibk_xenbu=
s_remove,=0A 	.otherend_changed	=3D xen_pcibk_frontend_changed,=0A-=
};=0A+);=0A =0A const struct xen_pcibk_backend *__read_mostly xen_pcibk_bac=
kend;=0A =0A@@ -735,11 +732,11 @@ int __init xen_pcibk_xenbus_register(voi=
=0A 	if (passthrough)=0A 		xen_pcibk_backend =3D &xen_pcibk_pa=
ssthrough_backend;=0A 	pr_info(DRV_NAME ": backend is %s\n", xen_pcibk_bac=
kend->name);=0A-	return xenbus_register_backend(&xenbus_xen_pcibk_dr=
iver);=0A+	return xenbus_register_backend(&xen_pcibk_driver);=0A }=0A =
=0A void __exit xen_pcibk_xenbus_unregister(void)=0A {=0A 	destroy_wor=
kqueue(xen_pcibk_wq);=0A-	xenbus_unregister_driver(&xenbus_xen_pcibk_=
driver);=0A+	xenbus_unregister_driver(&xen_pcibk_driver);=0A }=0A--- =
3.2-rc6/drivers/xen/xenbus/xenbus_probe.c=0A+++ 3.2-rc6-struct-xenbus_drive=
r/drivers/xen/xenbus/xenbus_probe.c=0A@@ -291,14 +291,9 @@ void xenbus_dev_=
shutdown(struct device *=0A EXPORT_SYMBOL_GPL(xenbus_dev_shutdown);=0A =0A =
int xenbus_register_driver_common(struct xenbus_driver *drv,=0A-		=
		  struct xen_bus_type *bus,=0A-				  =
struct module *owner,=0A-				  const char =
*mod_name)=0A+				  struct xen_bus_type *bus)=0A =
{=0A-	drv->driver.name =3D drv->name;=0A 	drv->driver.bus =3D =
&bus->bus;=0A-	drv->driver.owner =3D owner;=0A-	drv->driver.mod_nam=
e =3D mod_name;=0A =0A 	return driver_register(&drv->driver);=0A }=0A--- =
3.2-rc6/drivers/xen/xenbus/xenbus_probe.h=0A+++ 3.2-rc6-struct-xenbus_drive=
r/drivers/xen/xenbus/xenbus_probe.h=0A@@ -53,9 +53,7 @@ extern int =
xenbus_match(struct device *_=0A extern int xenbus_dev_probe(struct device =
*_dev);=0A extern int xenbus_dev_remove(struct device *_dev);=0A extern =
int xenbus_register_driver_common(struct xenbus_driver *drv,=0A-		=
			 struct xen_bus_type *bus,=0A-				=
	 struct module *owner,=0A-					 =
const char *mod_name);=0A+					 struct =
xen_bus_type *bus);=0A extern int xenbus_probe_node(struct xen_bus_type =
*bus,=0A 			     const char *type,=0A 			=
     const char *nodename);=0A--- 3.2-rc6/drivers/xen/xenbus/xenbus_probe_b=
ackend.c=0A+++ 3.2-rc6-struct-xenbus_driver/drivers/xen/xenbus/xenbus_probe=
_backend.c=0A@@ -232,15 +232,13 @@ int xenbus_dev_is_online(struct =
xenbus_d=0A }=0A EXPORT_SYMBOL_GPL(xenbus_dev_is_online);=0A =0A-int =
__xenbus_register_backend(struct xenbus_driver *drv,=0A-			=
      struct module *owner, const char *mod_name)=0A+int xenbus_register_ba=
ckend(struct xenbus_driver *drv)=0A {=0A 	drv->read_otherend_details =
=3D read_frontend_details;=0A =0A-	return xenbus_register_driver_commo=
n(drv, &xenbus_backend,=0A-					     =
owner, mod_name);=0A+	return xenbus_register_driver_common(drv, =
&xenbus_backend);=0A }=0A-EXPORT_SYMBOL_GPL(__xenbus_register_backend);=0A+=
EXPORT_SYMBOL_GPL(xenbus_register_backend);=0A =0A static int backend_probe=
_and_watch(struct notifier_block *notifier,=0A 				   =
unsigned long event,=0A--- 3.2-rc6/drivers/xen/xenbus/xenbus_probe_frontend=
.c=0A+++ 3.2-rc6-struct-xenbus_driver/drivers/xen/xenbus/xenbus_probe_front=
end.c=0A@@ -230,15 +230,13 @@ static void wait_for_devices(struct xenb=0A 	=
		 print_device_status);=0A }=0A =0A-int __xenbus_register_fr=
ontend(struct xenbus_driver *drv,=0A-			       struct =
module *owner, const char *mod_name)=0A+int xenbus_register_frontend(struct=
 xenbus_driver *drv)=0A {=0A 	int ret;=0A =0A 	drv->read_otherend_=
details =3D read_backend_details;=0A =0A-	ret =3D xenbus_register_dri=
ver_common(drv, &xenbus_frontend,=0A-					   =
 owner, mod_name);=0A+	ret =3D xenbus_register_driver_common(drv, =
&xenbus_frontend);=0A 	if (ret)=0A 		return ret;=0A =0A@@ =
-247,7 +245,7 @@ int __xenbus_register_frontend(struct xe=0A =0A 	=
return 0;=0A }=0A-EXPORT_SYMBOL_GPL(__xenbus_register_frontend);=0A+EXPORT_=
SYMBOL_GPL(xenbus_register_frontend);=0A =0A static DECLARE_WAIT_QUEUE_HEAD=
(backend_state_wq);=0A static int backend_state;=0A--- 3.2-rc6/include/xen/=
xenbus.h=0A+++ 3.2-rc6-struct-xenbus_driver/include/xen/xenbus.h=0A@@ =
-85,8 +85,6 @@ struct xenbus_device_id=0A =0A /* A xenbus driver. */=0A =
struct xenbus_driver {=0A-	char *name;=0A-	struct module *owner;=0A 	=
const struct xenbus_device_id *ids;=0A 	int (*probe)(struct xenbus_device =
*dev,=0A 		     const struct xenbus_device_id *id);=0A@@ =
-101,31 +99,20 @@ struct xenbus_driver {=0A 	int (*is_ready)(struct =
xenbus_device *dev);=0A };=0A =0A-static inline struct xenbus_driver =
*to_xenbus_driver(struct device_driver *drv)=0A-{=0A-	return container_of=
(drv, struct xenbus_driver, driver);=0A+#define DEFINE_XENBUS_DRIVER(var, =
drvname, methods...)		\=0A+struct xenbus_driver var ## _driver =
=3D {				\=0A+	.driver.name =3D drvname + 0 ?: =
var ## _ids->devicetype,	\=0A+	.driver.owner =3D THIS_MODULE,		=
		\=0A+	.ids =3D var ## _ids, ## methods			=
	\=0A }=0A =0A-int __must_check __xenbus_register_frontend(struct =
xenbus_driver *drv,=0A-					    struct module =
*owner,=0A-					    const char *mod_name);=
=0A-=0A-static inline int __must_check=0A-xenbus_register_frontend(struct =
xenbus_driver *drv)=0A+static inline struct xenbus_driver *to_xenbus_driver=
(struct device_driver *drv)=0A {=0A-	WARN_ON(drv->owner !=3D THIS_MODULE=
);=0A-	return __xenbus_register_frontend(drv, THIS_MODULE, KBUILD_MODNAME)=
;=0A+	return container_of(drv, struct xenbus_driver, driver);=0A }=0A =
=0A-int __must_check __xenbus_register_backend(struct xenbus_driver =
*drv,=0A-					   struct module *owner,=0A=
-					   const char *mod_name);=0A-static=
 inline int __must_check=0A-xenbus_register_backend(struct xenbus_driver =
*drv)=0A-{=0A-	WARN_ON(drv->owner !=3D THIS_MODULE);=0A-	return =
__xenbus_register_backend(drv, THIS_MODULE, KBUILD_MODNAME);=0A-}=0A+int =
__must_check xenbus_register_frontend(struct xenbus_driver *);=0A+int =
__must_check xenbus_register_backend(struct xenbus_driver *);=0A =0A void =
xenbus_unregister_driver(struct xenbus_driver *drv);=0A =0A
--=__Part113EA0C7.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.xensource.com
http://lists.xensource.com/xen-devel

--=__Part113EA0C7.2__=--


From xen-devel-bounces@lists.xensource.com Wed Dec 21 16:01:16 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 16:01:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdOax-00010e-6W; Wed, 21 Dec 2011 16:00:43 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RdOav-00010Z-Jk
	for xen-devel@lists.xensource.com; Wed, 21 Dec 2011 16:00:42 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1324483233!8166909!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5623 invoked from network); 21 Dec 2011 16:00:34 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-14.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Dec 2011 16:00:34 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 21 Dec 2011 16:01:03 +0000
Message-Id: <4EF210E7020000780006965E@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 21 Dec 2011 16:01:27 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad@darnok.org>,
	"Jeremy Fitzhardinge" <jeremy@goop.org>,
	"Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part113EA0C7.2__="
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	linux-kernel@vger.kernel.org
Subject: [Xen-devel] [PATCH] Xen: consolidate and simplify struct
 xenbus_driver instantiation
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__Part113EA0C7.2__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

The 'name', 'owner', and 'mod_name' members are redundant with the
identically named fields in the 'driver' sub-structure. Rather than
switching each instance to specify these fields explicitly, introduce
a macro to simplify this.

Eliminate further redundancy by allowing the drvname argument to
DEFINE_XENBUS_DRIVER() to be blank (in which case the first entry from
the ID table will be used for .driver.name).

Also eliminate the questionable xenbus_register_{back,front}end()
wrappers - their sole remaining purpose was the checking of the
'owner' field, proper setting of which shouldn't be an issue anymore
when the macro gets used.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

---
 drivers/block/xen-blkback/xenbus.c         |    9 ++------
 drivers/block/xen-blkfront.c               |   11 +++-------
 drivers/input/misc/xen-kbdfront.c          |    7 +-----
 drivers/net/xen-netback/xenbus.c           |    9 ++------
 drivers/net/xen-netfront.c                 |    9 ++------
 drivers/pci/xen-pcifront.c                 |   11 +++-------
 drivers/video/xen-fbfront.c                |    9 ++------
 drivers/xen/xen-pciback/xenbus.c           |   13 ++++--------
 drivers/xen/xenbus/xenbus_probe.c          |    7 ------
 drivers/xen/xenbus/xenbus_probe.h          |    4 ---
 drivers/xen/xenbus/xenbus_probe_backend.c  |    8 ++-----
 drivers/xen/xenbus/xenbus_probe_frontend.c |    8 ++-----
 include/xen/xenbus.h                       |   31 ++++++++----------------=
-----
 13 files changed, 44 insertions(+), 92 deletions(-)

--- 3.2-rc6/drivers/block/xen-blkback/xenbus.c
+++ 3.2-rc6-struct-xenbus_driver/drivers/block/xen-blkback/xenbus.c
@@ -787,17 +787,14 @@ static const struct xenbus_device_id xen
 };
=20
=20
-static struct xenbus_driver xen_blkbk =3D {
-	.name =3D "vbd",
-	.owner =3D THIS_MODULE,
-	.ids =3D xen_blkbk_ids,
+static DEFINE_XENBUS_DRIVER(xen_blkbk, ,
 	.probe =3D xen_blkbk_probe,
 	.remove =3D xen_blkbk_remove,
 	.otherend_changed =3D frontend_changed
-};
+);
=20
=20
 int xen_blkif_xenbus_init(void)
 {
-	return xenbus_register_backend(&xen_blkbk);
+	return xenbus_register_backend(&xen_blkbk_driver);
 }
--- 3.2-rc6/drivers/block/xen-blkfront.c
+++ 3.2-rc6-struct-xenbus_driver/drivers/block/xen-blkfront.c
@@ -1437,16 +1437,13 @@ static const struct xenbus_device_id blk
 	{ "" }
 };
=20
-static struct xenbus_driver blkfront =3D {
-	.name =3D "vbd",
-	.owner =3D THIS_MODULE,
-	.ids =3D blkfront_ids,
+static DEFINE_XENBUS_DRIVER(blkfront, ,
 	.probe =3D blkfront_probe,
 	.remove =3D blkfront_remove,
 	.resume =3D blkfront_resume,
 	.otherend_changed =3D blkback_changed,
 	.is_ready =3D blkfront_is_ready,
-};
+);
=20
 static int __init xlblk_init(void)
 {
@@ -1461,7 +1458,7 @@ static int __init xlblk_init(void)
 		return -ENODEV;
 	}
=20
-	ret =3D xenbus_register_frontend(&blkfront);
+	ret =3D xenbus_register_frontend(&blkfront_driver);
 	if (ret) {
 		unregister_blkdev(XENVBD_MAJOR, DEV_NAME);
 		return ret;
@@ -1474,7 +1471,7 @@ module_init(xlblk_init);
=20
 static void __exit xlblk_exit(void)
 {
-	return xenbus_unregister_driver(&blkfront);
+	return xenbus_unregister_driver(&blkfront_driver);
 }
 module_exit(xlblk_exit);
=20
--- 3.2-rc6/drivers/input/misc/xen-kbdfront.c
+++ 3.2-rc6-struct-xenbus_driver/drivers/input/misc/xen-kbdfront.c
@@ -361,15 +361,12 @@ static const struct xenbus_device_id xen
 	{ "" }
 };
=20
-static struct xenbus_driver xenkbd_driver =3D {
-	.name =3D "vkbd",
-	.owner =3D THIS_MODULE,
-	.ids =3D xenkbd_ids,
+static DEFINE_XENBUS_DRIVER(xenkbd, ,
 	.probe =3D xenkbd_probe,
 	.remove =3D xenkbd_remove,
 	.resume =3D xenkbd_resume,
 	.otherend_changed =3D xenkbd_backend_changed,
-};
+);
=20
 static int __init xenkbd_init(void)
 {
--- 3.2-rc6/drivers/net/xen-netback/xenbus.c
+++ 3.2-rc6-struct-xenbus_driver/drivers/net/xen-netback/xenbus.c
@@ -474,17 +474,14 @@ static const struct xenbus_device_id net
 };
=20
=20
-static struct xenbus_driver netback =3D {
-	.name =3D "vif",
-	.owner =3D THIS_MODULE,
-	.ids =3D netback_ids,
+static DEFINE_XENBUS_DRIVER(netback, ,
 	.probe =3D netback_probe,
 	.remove =3D netback_remove,
 	.uevent =3D netback_uevent,
 	.otherend_changed =3D frontend_changed,
-};
+);
=20
 int xenvif_xenbus_init(void)
 {
-	return xenbus_register_backend(&netback);
+	return xenbus_register_backend(&netback_driver);
 }
--- 3.2-rc6/drivers/net/xen-netfront.c
+++ 3.2-rc6-struct-xenbus_driver/drivers/net/xen-netfront.c
@@ -1910,7 +1910,7 @@ static void xennet_sysfs_delif(struct ne
=20
 #endif /* CONFIG_SYSFS */
=20
-static struct xenbus_device_id netfront_ids[] =3D {
+static const struct xenbus_device_id netfront_ids[] =3D {
 	{ "vif" },
 	{ "" }
 };
@@ -1937,15 +1937,12 @@ static int __devexit xennet_remove(struc
 	return 0;
 }
=20
-static struct xenbus_driver netfront_driver =3D {
-	.name =3D "vif",
-	.owner =3D THIS_MODULE,
-	.ids =3D netfront_ids,
+static DEFINE_XENBUS_DRIVER(netfront, ,
 	.probe =3D netfront_probe,
 	.remove =3D __devexit_p(xennet_remove),
 	.resume =3D netfront_resume,
 	.otherend_changed =3D netback_changed,
-};
+);
=20
 static int __init netif_init(void)
 {
--- 3.2-rc6/drivers/pci/xen-pcifront.c
+++ 3.2-rc6-struct-xenbus_driver/drivers/pci/xen-pcifront.c
@@ -1126,14 +1126,11 @@ static const struct xenbus_device_id xen
 	{""},
 };
=20
-static struct xenbus_driver xenbus_pcifront_driver =3D {
-	.name			=3D "pcifront",
-	.owner			=3D THIS_MODULE,
-	.ids			=3D xenpci_ids,
+static DEFINE_XENBUS_DRIVER(xenpci, "pcifront",
 	.probe			=3D pcifront_xenbus_probe,
 	.remove			=3D pcifront_xenbus_remove,
 	.otherend_changed	=3D pcifront_backend_changed,
-};
+);
=20
 static int __init pcifront_init(void)
 {
@@ -1142,12 +1139,12 @@ static int __init pcifront_init(void)
=20
 	pci_frontend_registrar(1 /* enable */);
=20
-	return xenbus_register_frontend(&xenbus_pcifront_driver);
+	return xenbus_register_frontend(&xenpci_driver);
 }
=20
 static void __exit pcifront_cleanup(void)
 {
-	xenbus_unregister_driver(&xenbus_pcifront_driver);
+	xenbus_unregister_driver(&xenpci_driver);
 	pci_frontend_registrar(0 /* disable */);
 }
 module_init(pcifront_init);
--- 3.2-rc6/drivers/video/xen-fbfront.c
+++ 3.2-rc6-struct-xenbus_driver/drivers/video/xen-fbfront.c
@@ -671,20 +671,17 @@ InitWait:
 	}
 }
=20
-static struct xenbus_device_id xenfb_ids[] =3D {
+static const struct xenbus_device_id xenfb_ids[] =3D {
 	{ "vfb" },
 	{ "" }
 };
=20
-static struct xenbus_driver xenfb_driver =3D {
-	.name =3D "vfb",
-	.owner =3D THIS_MODULE,
-	.ids =3D xenfb_ids,
+static DEFINE_XENBUS_DRIVER(xenfb, ,
 	.probe =3D xenfb_probe,
 	.remove =3D xenfb_remove,
 	.resume =3D xenfb_resume,
 	.otherend_changed =3D xenfb_backend_changed,
-};
+);
=20
 static int __init xenfb_init(void)
 {
--- 3.2-rc6/drivers/xen/xen-pciback/xenbus.c
+++ 3.2-rc6-struct-xenbus_driver/drivers/xen/xen-pciback/xenbus.c
@@ -707,19 +707,16 @@ static int xen_pcibk_xenbus_remove(struc
 	return 0;
 }
=20
-static const struct xenbus_device_id xenpci_ids[] =3D {
+static const struct xenbus_device_id xen_pcibk_ids[] =3D {
 	{"pci"},
 	{""},
 };
=20
-static struct xenbus_driver xenbus_xen_pcibk_driver =3D {
-	.name			=3D DRV_NAME,
-	.owner			=3D THIS_MODULE,
-	.ids			=3D xenpci_ids,
+static DEFINE_XENBUS_DRIVER(xen_pcibk, "pciback",
 	.probe			=3D xen_pcibk_xenbus_probe,
 	.remove			=3D xen_pcibk_xenbus_remove,
 	.otherend_changed	=3D xen_pcibk_frontend_changed,
-};
+);
=20
 const struct xen_pcibk_backend *__read_mostly xen_pcibk_backend;
=20
@@ -735,11 +732,11 @@ int __init xen_pcibk_xenbus_register(voi
 	if (passthrough)
 		xen_pcibk_backend =3D &xen_pcibk_passthrough_backend;
 	pr_info(DRV_NAME ": backend is %s\n", xen_pcibk_backend->name);
-	return xenbus_register_backend(&xenbus_xen_pcibk_driver);
+	return xenbus_register_backend(&xen_pcibk_driver);
 }
=20
 void __exit xen_pcibk_xenbus_unregister(void)
 {
 	destroy_workqueue(xen_pcibk_wq);
-	xenbus_unregister_driver(&xenbus_xen_pcibk_driver);
+	xenbus_unregister_driver(&xen_pcibk_driver);
 }
--- 3.2-rc6/drivers/xen/xenbus/xenbus_probe.c
+++ 3.2-rc6-struct-xenbus_driver/drivers/xen/xenbus/xenbus_probe.c
@@ -291,14 +291,9 @@ void xenbus_dev_shutdown(struct device *
 EXPORT_SYMBOL_GPL(xenbus_dev_shutdown);
=20
 int xenbus_register_driver_common(struct xenbus_driver *drv,
-				  struct xen_bus_type *bus,
-				  struct module *owner,
-				  const char *mod_name)
+				  struct xen_bus_type *bus)
 {
-	drv->driver.name =3D drv->name;
 	drv->driver.bus =3D &bus->bus;
-	drv->driver.owner =3D owner;
-	drv->driver.mod_name =3D mod_name;
=20
 	return driver_register(&drv->driver);
 }
--- 3.2-rc6/drivers/xen/xenbus/xenbus_probe.h
+++ 3.2-rc6-struct-xenbus_driver/drivers/xen/xenbus/xenbus_probe.h
@@ -53,9 +53,7 @@ extern int xenbus_match(struct device *_
 extern int xenbus_dev_probe(struct device *_dev);
 extern int xenbus_dev_remove(struct device *_dev);
 extern int xenbus_register_driver_common(struct xenbus_driver *drv,
-					 struct xen_bus_type *bus,
-					 struct module *owner,
-					 const char *mod_name);
+					 struct xen_bus_type *bus);
 extern int xenbus_probe_node(struct xen_bus_type *bus,
 			     const char *type,
 			     const char *nodename);
--- 3.2-rc6/drivers/xen/xenbus/xenbus_probe_backend.c
+++ 3.2-rc6-struct-xenbus_driver/drivers/xen/xenbus/xenbus_probe_backend.c
@@ -232,15 +232,13 @@ int xenbus_dev_is_online(struct xenbus_d
 }
 EXPORT_SYMBOL_GPL(xenbus_dev_is_online);
=20
-int __xenbus_register_backend(struct xenbus_driver *drv,
-			      struct module *owner, const char *mod_name)
+int xenbus_register_backend(struct xenbus_driver *drv)
 {
 	drv->read_otherend_details =3D read_frontend_details;
=20
-	return xenbus_register_driver_common(drv, &xenbus_backend,
-					     owner, mod_name);
+	return xenbus_register_driver_common(drv, &xenbus_backend);
 }
-EXPORT_SYMBOL_GPL(__xenbus_register_backend);
+EXPORT_SYMBOL_GPL(xenbus_register_backend);
=20
 static int backend_probe_and_watch(struct notifier_block *notifier,
 				   unsigned long event,
--- 3.2-rc6/drivers/xen/xenbus/xenbus_probe_frontend.c
+++ 3.2-rc6-struct-xenbus_driver/drivers/xen/xenbus/xenbus_probe_frontend.c=

@@ -230,15 +230,13 @@ static void wait_for_devices(struct xenb
 			 print_device_status);
 }
=20
-int __xenbus_register_frontend(struct xenbus_driver *drv,
-			       struct module *owner, const char *mod_name)
+int xenbus_register_frontend(struct xenbus_driver *drv)
 {
 	int ret;
=20
 	drv->read_otherend_details =3D read_backend_details;
=20
-	ret =3D xenbus_register_driver_common(drv, &xenbus_frontend,
-					    owner, mod_name);
+	ret =3D xenbus_register_driver_common(drv, &xenbus_frontend);
 	if (ret)
 		return ret;
=20
@@ -247,7 +245,7 @@ int __xenbus_register_frontend(struct xe
=20
 	return 0;
 }
-EXPORT_SYMBOL_GPL(__xenbus_register_frontend);
+EXPORT_SYMBOL_GPL(xenbus_register_frontend);
=20
 static DECLARE_WAIT_QUEUE_HEAD(backend_state_wq);
 static int backend_state;
--- 3.2-rc6/include/xen/xenbus.h
+++ 3.2-rc6-struct-xenbus_driver/include/xen/xenbus.h
@@ -85,8 +85,6 @@ struct xenbus_device_id
=20
 /* A xenbus driver. */
 struct xenbus_driver {
-	char *name;
-	struct module *owner;
 	const struct xenbus_device_id *ids;
 	int (*probe)(struct xenbus_device *dev,
 		     const struct xenbus_device_id *id);
@@ -101,31 +99,20 @@ struct xenbus_driver {
 	int (*is_ready)(struct xenbus_device *dev);
 };
=20
-static inline struct xenbus_driver *to_xenbus_driver(struct device_driver =
*drv)
-{
-	return container_of(drv, struct xenbus_driver, driver);
+#define DEFINE_XENBUS_DRIVER(var, drvname, methods...)		\
+struct xenbus_driver var ## _driver =3D {				\
+	.driver.name =3D drvname + 0 ?: var ## _ids->devicetype,	\
+	.driver.owner =3D THIS_MODULE,				\
+	.ids =3D var ## _ids, ## methods				\
 }
=20
-int __must_check __xenbus_register_frontend(struct xenbus_driver *drv,
-					    struct module *owner,
-					    const char *mod_name);
-
-static inline int __must_check
-xenbus_register_frontend(struct xenbus_driver *drv)
+static inline struct xenbus_driver *to_xenbus_driver(struct device_driver =
*drv)
 {
-	WARN_ON(drv->owner !=3D THIS_MODULE);
-	return __xenbus_register_frontend(drv, THIS_MODULE, KBUILD_MODNAME)=
;
+	return container_of(drv, struct xenbus_driver, driver);
 }
=20
-int __must_check __xenbus_register_backend(struct xenbus_driver *drv,
-					   struct module *owner,
-					   const char *mod_name);
-static inline int __must_check
-xenbus_register_backend(struct xenbus_driver *drv)
-{
-	WARN_ON(drv->owner !=3D THIS_MODULE);
-	return __xenbus_register_backend(drv, THIS_MODULE, KBUILD_MODNAME);=

-}
+int __must_check xenbus_register_frontend(struct xenbus_driver *);
+int __must_check xenbus_register_backend(struct xenbus_driver *);
=20
 void xenbus_unregister_driver(struct xenbus_driver *drv);
=20



--=__Part113EA0C7.2__=
Content-Type: text/plain; name="linux-3.2-rc6-struct-xenbus_driver.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="linux-3.2-rc6-struct-xenbus_driver.patch"

Xen: consolidate and simplify struct xenbus_driver instantiation=0A=0AThe =
'name', 'owner', and 'mod_name' members are redundant with the=0Aidenticall=
y named fields in the 'driver' sub-structure. Rather than=0Aswitching each =
instance to specify these fields explicitly, introduce=0Aa macro to =
simplify this.=0A=0AEliminate further redundancy by allowing the drvname =
argument to=0ADEFINE_XENBUS_DRIVER() to be blank (in which case the first =
entry from=0Athe ID table will be used for .driver.name).=0A=0AAlso =
eliminate the questionable xenbus_register_{back,front}end()=0Awrappers - =
their sole remaining purpose was the checking of the=0A'owner' field, =
proper setting of which shouldn't be an issue anymore=0Awhen the macro =
gets used.=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=0A=0A---=0A =
drivers/block/xen-blkback/xenbus.c         |    9 ++------=0A drivers/block=
/xen-blkfront.c               |   11 +++-------=0A drivers/input/misc/xen-k=
bdfront.c          |    7 +-----=0A drivers/net/xen-netback/xenbus.c       =
    |    9 ++------=0A drivers/net/xen-netfront.c                 |    9 =
++------=0A drivers/pci/xen-pcifront.c                 |   11 +++-------=0A=
 drivers/video/xen-fbfront.c                |    9 ++------=0A drivers/xen/=
xen-pciback/xenbus.c           |   13 ++++--------=0A drivers/xen/xenbus/xe=
nbus_probe.c          |    7 ------=0A drivers/xen/xenbus/xenbus_probe.h   =
       |    4 ---=0A drivers/xen/xenbus/xenbus_probe_backend.c  |    8 =
++-----=0A drivers/xen/xenbus/xenbus_probe_frontend.c |    8 ++-----=0A =
include/xen/xenbus.h                       |   31 ++++++++-----------------=
----=0A 13 files changed, 44 insertions(+), 92 deletions(-)=0A=0A--- =
3.2-rc6/drivers/block/xen-blkback/xenbus.c=0A+++ 3.2-rc6-struct-xenbus_driv=
er/drivers/block/xen-blkback/xenbus.c=0A@@ -787,17 +787,14 @@ static const =
struct xenbus_device_id xen=0A };=0A =0A =0A-static struct xenbus_driver =
xen_blkbk =3D {=0A-	.name =3D "vbd",=0A-	.owner =3D THIS_MODULE,=0A-=
	.ids =3D xen_blkbk_ids,=0A+static DEFINE_XENBUS_DRIVER(xen_blkbk, =
,=0A 	.probe =3D xen_blkbk_probe,=0A 	.remove =3D xen_blkbk_remove,=0A 	=
.otherend_changed =3D frontend_changed=0A-};=0A+);=0A =0A =0A int =
xen_blkif_xenbus_init(void)=0A {=0A-	return xenbus_register_backend(&xen=
_blkbk);=0A+	return xenbus_register_backend(&xen_blkbk_driver);=0A =
}=0A--- 3.2-rc6/drivers/block/xen-blkfront.c=0A+++ 3.2-rc6-struct-xenbus_dr=
iver/drivers/block/xen-blkfront.c=0A@@ -1437,16 +1437,13 @@ static const =
struct xenbus_device_id blk=0A 	{ "" }=0A };=0A =0A-static struct =
xenbus_driver blkfront =3D {=0A-	.name =3D "vbd",=0A-	.owner =3D =
THIS_MODULE,=0A-	.ids =3D blkfront_ids,=0A+static DEFINE_XENBUS_DRIV=
ER(blkfront, ,=0A 	.probe =3D blkfront_probe,=0A 	.remove =3D =
blkfront_remove,=0A 	.resume =3D blkfront_resume,=0A 	.otherend_c=
hanged =3D blkback_changed,=0A 	.is_ready =3D blkfront_is_ready,=0A-};=0A+)=
;=0A =0A static int __init xlblk_init(void)=0A {=0A@@ -1461,7 +1458,7 @@ =
static int __init xlblk_init(void)=0A 		return -ENODEV;=0A 	=
}=0A =0A-	ret =3D xenbus_register_frontend(&blkfront);=0A+	=
ret =3D xenbus_register_frontend(&blkfront_driver);=0A 	if (ret) {=0A 		=
unregister_blkdev(XENVBD_MAJOR, DEV_NAME);=0A 		return ret;=0A@@ =
-1474,7 +1471,7 @@ module_init(xlblk_init);=0A =0A static void __exit =
xlblk_exit(void)=0A {=0A-	return xenbus_unregister_driver(&blkfront);=
=0A+	return xenbus_unregister_driver(&blkfront_driver);=0A }=0A =
module_exit(xlblk_exit);=0A =0A--- 3.2-rc6/drivers/input/misc/xen-kbdfront.=
c=0A+++ 3.2-rc6-struct-xenbus_driver/drivers/input/misc/xen-kbdfront.c=0A@@=
 -361,15 +361,12 @@ static const struct xenbus_device_id xen=0A 	{ =
"" }=0A };=0A =0A-static struct xenbus_driver xenkbd_driver =3D {=0A-	=
.name =3D "vkbd",=0A-	.owner =3D THIS_MODULE,=0A-	.ids =3D xenkbd_ids=
,=0A+static DEFINE_XENBUS_DRIVER(xenkbd, ,=0A 	.probe =3D xenkbd_probe,=0A=
 	.remove =3D xenkbd_remove,=0A 	.resume =3D xenkbd_resume,=0A 	=
.otherend_changed =3D xenkbd_backend_changed,=0A-};=0A+);=0A =0A static =
int __init xenkbd_init(void)=0A {=0A--- 3.2-rc6/drivers/net/xen-netback/xen=
bus.c=0A+++ 3.2-rc6-struct-xenbus_driver/drivers/net/xen-netback/xenbus.c=
=0A@@ -474,17 +474,14 @@ static const struct xenbus_device_id net=0A };=0A =
=0A =0A-static struct xenbus_driver netback =3D {=0A-	.name =3D =
"vif",=0A-	.owner =3D THIS_MODULE,=0A-	.ids =3D netback_ids,=0A+st=
atic DEFINE_XENBUS_DRIVER(netback, ,=0A 	.probe =3D netback_probe,=
=0A 	.remove =3D netback_remove,=0A 	.uevent =3D netback_uevent,=0A 	=
.otherend_changed =3D frontend_changed,=0A-};=0A+);=0A =0A int xenvif_xenbu=
s_init(void)=0A {=0A-	return xenbus_register_backend(&netback);=0A+	=
return xenbus_register_backend(&netback_driver);=0A }=0A--- 3.2-rc6/drivers=
/net/xen-netfront.c=0A+++ 3.2-rc6-struct-xenbus_driver/drivers/net/xen-netf=
ront.c=0A@@ -1910,7 +1910,7 @@ static void xennet_sysfs_delif(struct ne=0A =
=0A #endif /* CONFIG_SYSFS */=0A =0A-static struct xenbus_device_id =
netfront_ids[] =3D {=0A+static const struct xenbus_device_id netfront_ids[]=
 =3D {=0A 	{ "vif" },=0A 	{ "" }=0A };=0A@@ -1937,15 +1937,12 @@ =
static int __devexit xennet_remove(struc=0A 	return 0;=0A }=0A =
=0A-static struct xenbus_driver netfront_driver =3D {=0A-	.name =3D =
"vif",=0A-	.owner =3D THIS_MODULE,=0A-	.ids =3D netfront_ids,=0A+s=
tatic DEFINE_XENBUS_DRIVER(netfront, ,=0A 	.probe =3D netfront_probe,=
=0A 	.remove =3D __devexit_p(xennet_remove),=0A 	.resume =3D =
netfront_resume,=0A 	.otherend_changed =3D netback_changed,=0A-};=0A+);=
=0A =0A static int __init netif_init(void)=0A {=0A--- 3.2-rc6/drivers/pci/x=
en-pcifront.c=0A+++ 3.2-rc6-struct-xenbus_driver/drivers/pci/xen-pcifront.c=
=0A@@ -1126,14 +1126,11 @@ static const struct xenbus_device_id xen=0A 	=
{""},=0A };=0A =0A-static struct xenbus_driver xenbus_pcifront_driver =3D =
{=0A-	.name			=3D "pcifront",=0A-	.owner			=
=3D THIS_MODULE,=0A-	.ids			=3D xenpci_ids,=0A+static =
DEFINE_XENBUS_DRIVER(xenpci, "pcifront",=0A 	.probe			=
=3D pcifront_xenbus_probe,=0A 	.remove			=3D pcifront_xenbus=
_remove,=0A 	.otherend_changed	=3D pcifront_backend_changed,=0A-};=
=0A+);=0A =0A static int __init pcifront_init(void)=0A {=0A@@ -1142,12 =
+1139,12 @@ static int __init pcifront_init(void)=0A =0A 	pci_fronten=
d_registrar(1 /* enable */);=0A =0A-	return xenbus_register_frontend(&xe=
nbus_pcifront_driver);=0A+	return xenbus_register_frontend(&xenpci_dri=
ver);=0A }=0A =0A static void __exit pcifront_cleanup(void)=0A {=0A-	=
xenbus_unregister_driver(&xenbus_pcifront_driver);=0A+	xenbus_unregister_d=
river(&xenpci_driver);=0A 	pci_frontend_registrar(0 /* disable =
*/);=0A }=0A module_init(pcifront_init);=0A--- 3.2-rc6/drivers/video/xen-fb=
front.c=0A+++ 3.2-rc6-struct-xenbus_driver/drivers/video/xen-fbfront.c=0A@@=
 -671,20 +671,17 @@ InitWait:=0A 	}=0A }=0A =0A-static struct =
xenbus_device_id xenfb_ids[] =3D {=0A+static const struct xenbus_device_id =
xenfb_ids[] =3D {=0A 	{ "vfb" },=0A 	{ "" }=0A };=0A =0A-static struct =
xenbus_driver xenfb_driver =3D {=0A-	.name =3D "vfb",=0A-	.owner =3D =
THIS_MODULE,=0A-	.ids =3D xenfb_ids,=0A+static DEFINE_XENBUS_DRIVER(=
xenfb, ,=0A 	.probe =3D xenfb_probe,=0A 	.remove =3D xenfb_remove,=
=0A 	.resume =3D xenfb_resume,=0A 	.otherend_changed =3D xenfb_backend=
_changed,=0A-};=0A+);=0A =0A static int __init xenfb_init(void)=0A {=0A--- =
3.2-rc6/drivers/xen/xen-pciback/xenbus.c=0A+++ 3.2-rc6-struct-xenbus_driver=
/drivers/xen/xen-pciback/xenbus.c=0A@@ -707,19 +707,16 @@ static int =
xen_pcibk_xenbus_remove(struc=0A 	return 0;=0A }=0A =0A-static const =
struct xenbus_device_id xenpci_ids[] =3D {=0A+static const struct =
xenbus_device_id xen_pcibk_ids[] =3D {=0A 	{"pci"},=0A 	{""},=0A =
};=0A =0A-static struct xenbus_driver xenbus_xen_pcibk_driver =3D {=0A-	=
.name			=3D DRV_NAME,=0A-	.owner			=
=3D THIS_MODULE,=0A-	.ids			=3D xenpci_ids,=0A+static =
DEFINE_XENBUS_DRIVER(xen_pcibk, "pciback",=0A 	.probe			=
=3D xen_pcibk_xenbus_probe,=0A 	.remove			=3D xen_pcibk_xenbu=
s_remove,=0A 	.otherend_changed	=3D xen_pcibk_frontend_changed,=0A-=
};=0A+);=0A =0A const struct xen_pcibk_backend *__read_mostly xen_pcibk_bac=
kend;=0A =0A@@ -735,11 +732,11 @@ int __init xen_pcibk_xenbus_register(voi=
=0A 	if (passthrough)=0A 		xen_pcibk_backend =3D &xen_pcibk_pa=
ssthrough_backend;=0A 	pr_info(DRV_NAME ": backend is %s\n", xen_pcibk_bac=
kend->name);=0A-	return xenbus_register_backend(&xenbus_xen_pcibk_dr=
iver);=0A+	return xenbus_register_backend(&xen_pcibk_driver);=0A }=0A =
=0A void __exit xen_pcibk_xenbus_unregister(void)=0A {=0A 	destroy_wor=
kqueue(xen_pcibk_wq);=0A-	xenbus_unregister_driver(&xenbus_xen_pcibk_=
driver);=0A+	xenbus_unregister_driver(&xen_pcibk_driver);=0A }=0A--- =
3.2-rc6/drivers/xen/xenbus/xenbus_probe.c=0A+++ 3.2-rc6-struct-xenbus_drive=
r/drivers/xen/xenbus/xenbus_probe.c=0A@@ -291,14 +291,9 @@ void xenbus_dev_=
shutdown(struct device *=0A EXPORT_SYMBOL_GPL(xenbus_dev_shutdown);=0A =0A =
int xenbus_register_driver_common(struct xenbus_driver *drv,=0A-		=
		  struct xen_bus_type *bus,=0A-				  =
struct module *owner,=0A-				  const char =
*mod_name)=0A+				  struct xen_bus_type *bus)=0A =
{=0A-	drv->driver.name =3D drv->name;=0A 	drv->driver.bus =3D =
&bus->bus;=0A-	drv->driver.owner =3D owner;=0A-	drv->driver.mod_nam=
e =3D mod_name;=0A =0A 	return driver_register(&drv->driver);=0A }=0A--- =
3.2-rc6/drivers/xen/xenbus/xenbus_probe.h=0A+++ 3.2-rc6-struct-xenbus_drive=
r/drivers/xen/xenbus/xenbus_probe.h=0A@@ -53,9 +53,7 @@ extern int =
xenbus_match(struct device *_=0A extern int xenbus_dev_probe(struct device =
*_dev);=0A extern int xenbus_dev_remove(struct device *_dev);=0A extern =
int xenbus_register_driver_common(struct xenbus_driver *drv,=0A-		=
			 struct xen_bus_type *bus,=0A-				=
	 struct module *owner,=0A-					 =
const char *mod_name);=0A+					 struct =
xen_bus_type *bus);=0A extern int xenbus_probe_node(struct xen_bus_type =
*bus,=0A 			     const char *type,=0A 			=
     const char *nodename);=0A--- 3.2-rc6/drivers/xen/xenbus/xenbus_probe_b=
ackend.c=0A+++ 3.2-rc6-struct-xenbus_driver/drivers/xen/xenbus/xenbus_probe=
_backend.c=0A@@ -232,15 +232,13 @@ int xenbus_dev_is_online(struct =
xenbus_d=0A }=0A EXPORT_SYMBOL_GPL(xenbus_dev_is_online);=0A =0A-int =
__xenbus_register_backend(struct xenbus_driver *drv,=0A-			=
      struct module *owner, const char *mod_name)=0A+int xenbus_register_ba=
ckend(struct xenbus_driver *drv)=0A {=0A 	drv->read_otherend_details =
=3D read_frontend_details;=0A =0A-	return xenbus_register_driver_commo=
n(drv, &xenbus_backend,=0A-					     =
owner, mod_name);=0A+	return xenbus_register_driver_common(drv, =
&xenbus_backend);=0A }=0A-EXPORT_SYMBOL_GPL(__xenbus_register_backend);=0A+=
EXPORT_SYMBOL_GPL(xenbus_register_backend);=0A =0A static int backend_probe=
_and_watch(struct notifier_block *notifier,=0A 				   =
unsigned long event,=0A--- 3.2-rc6/drivers/xen/xenbus/xenbus_probe_frontend=
.c=0A+++ 3.2-rc6-struct-xenbus_driver/drivers/xen/xenbus/xenbus_probe_front=
end.c=0A@@ -230,15 +230,13 @@ static void wait_for_devices(struct xenb=0A 	=
		 print_device_status);=0A }=0A =0A-int __xenbus_register_fr=
ontend(struct xenbus_driver *drv,=0A-			       struct =
module *owner, const char *mod_name)=0A+int xenbus_register_frontend(struct=
 xenbus_driver *drv)=0A {=0A 	int ret;=0A =0A 	drv->read_otherend_=
details =3D read_backend_details;=0A =0A-	ret =3D xenbus_register_dri=
ver_common(drv, &xenbus_frontend,=0A-					   =
 owner, mod_name);=0A+	ret =3D xenbus_register_driver_common(drv, =
&xenbus_frontend);=0A 	if (ret)=0A 		return ret;=0A =0A@@ =
-247,7 +245,7 @@ int __xenbus_register_frontend(struct xe=0A =0A 	=
return 0;=0A }=0A-EXPORT_SYMBOL_GPL(__xenbus_register_frontend);=0A+EXPORT_=
SYMBOL_GPL(xenbus_register_frontend);=0A =0A static DECLARE_WAIT_QUEUE_HEAD=
(backend_state_wq);=0A static int backend_state;=0A--- 3.2-rc6/include/xen/=
xenbus.h=0A+++ 3.2-rc6-struct-xenbus_driver/include/xen/xenbus.h=0A@@ =
-85,8 +85,6 @@ struct xenbus_device_id=0A =0A /* A xenbus driver. */=0A =
struct xenbus_driver {=0A-	char *name;=0A-	struct module *owner;=0A 	=
const struct xenbus_device_id *ids;=0A 	int (*probe)(struct xenbus_device =
*dev,=0A 		     const struct xenbus_device_id *id);=0A@@ =
-101,31 +99,20 @@ struct xenbus_driver {=0A 	int (*is_ready)(struct =
xenbus_device *dev);=0A };=0A =0A-static inline struct xenbus_driver =
*to_xenbus_driver(struct device_driver *drv)=0A-{=0A-	return container_of=
(drv, struct xenbus_driver, driver);=0A+#define DEFINE_XENBUS_DRIVER(var, =
drvname, methods...)		\=0A+struct xenbus_driver var ## _driver =
=3D {				\=0A+	.driver.name =3D drvname + 0 ?: =
var ## _ids->devicetype,	\=0A+	.driver.owner =3D THIS_MODULE,		=
		\=0A+	.ids =3D var ## _ids, ## methods			=
	\=0A }=0A =0A-int __must_check __xenbus_register_frontend(struct =
xenbus_driver *drv,=0A-					    struct module =
*owner,=0A-					    const char *mod_name);=
=0A-=0A-static inline int __must_check=0A-xenbus_register_frontend(struct =
xenbus_driver *drv)=0A+static inline struct xenbus_driver *to_xenbus_driver=
(struct device_driver *drv)=0A {=0A-	WARN_ON(drv->owner !=3D THIS_MODULE=
);=0A-	return __xenbus_register_frontend(drv, THIS_MODULE, KBUILD_MODNAME)=
;=0A+	return container_of(drv, struct xenbus_driver, driver);=0A }=0A =
=0A-int __must_check __xenbus_register_backend(struct xenbus_driver =
*drv,=0A-					   struct module *owner,=0A=
-					   const char *mod_name);=0A-static=
 inline int __must_check=0A-xenbus_register_backend(struct xenbus_driver =
*drv)=0A-{=0A-	WARN_ON(drv->owner !=3D THIS_MODULE);=0A-	return =
__xenbus_register_backend(drv, THIS_MODULE, KBUILD_MODNAME);=0A-}=0A+int =
__must_check xenbus_register_frontend(struct xenbus_driver *);=0A+int =
__must_check xenbus_register_backend(struct xenbus_driver *);=0A =0A void =
xenbus_unregister_driver(struct xenbus_driver *drv);=0A =0A
--=__Part113EA0C7.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.xensource.com
http://lists.xensource.com/xen-devel

--=__Part113EA0C7.2__=--


From xen-devel-bounces@lists.xensource.com Wed Dec 21 16:04:29 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 16: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.xensource.com>)
	id 1RdOe8-000192-1r; Wed, 21 Dec 2011 16:04:00 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1RdOe6-00018l-8C
	for xen-devel@lists.xensource.com; Wed, 21 Dec 2011 16:03:59 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-13.tower-27.messagelabs.com!1324483403!53094887!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=1.1 required=7.0 tests=BODY_RANDOM_LONG,DIET_1
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10443 invoked from network); 21 Dec 2011 16:03:24 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-13.tower-27.messagelabs.com with SMTP;
	21 Dec 2011 16:03:24 -0000
Received: from [83.211.178.94] (account d.faggioli@sssup.it HELO
	[192.168.0.20]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 74086552; Wed, 21 Dec 2011 17:03:46 +0100
Message-ID: <1324483425.4366.43.camel@Abyss>
From: Dario Faggioli <raistlin@linux.it>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Wed, 21 Dec 2011 17:03:45 +0100
Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwCAIAAADYYG7QAAAAA3NCSVQICAjb4U/gAAAVx0lEQVRYwzWY6a/d953XP9/tt51zfme/+37t692OtzhxtzTuJFPaTDVt0cDQeTIajToSKBJICBASQkI8Q1Q8ACQEhUGgCsF0OrSkaRLaxknqOl7i9dq++3727bd/Vx5k+CNe7+WFvvkvbvoywAZF1BMYOFNFbqWEW1gho42yB9jJq1QihEGVCh7BxrXpeNlxbJZmcmNvkArIhAIMJd+drlmA0aiXuBbN5x3Pxq6NS6X85l5/rxNnGtJYgAYhgVCa8UxqAwgQIABAGGMD1JWtS7/48Vy0W1k5GxXnmh41br1y6fxXv3LCEPXLu3vv3N3t2kXPAi0EIjTjnDGcKawzHceZl3N0mIExrmfnGS1iSij2pxgDxJhlsOFID8LUsVjecXvNPiJg2ZYySiODGUVcAwBCCAAMAIAhNc82C2xvuLG8uX422VvZfHrx9Mz5P7kRR51wby188YD+8metqQWBLa00F1JIlQk5imIhle+XBsHI9/PVUoFCBp7JOZbSjGiS92mx7IE0SICRkC/Yw2GSZECpIsYYwEmWGkDGIAAAAIQAY4QMEA6Nvc7G6aaYzKQlUs/x/O99VywsZcZd33w++l9/NbN6Z905MSqPGYO10QDYGCI1EIQQGMdzkzCo+G4pb5eY7blWKhKadiZ92yYsFWoYpwhRv0A4h/4oK5Zcl9nGAMLUgEYYMAZAmhBkM6KkoYpVIRjU47SRRUuVlXRlUZ08nxDyi50na+2jV1r9tTjK/DwYqgFRLHMuYdhCMou1bg64a0M15yKiCyCcLJlJspl+e6x3QNtuv1TbKIwHxpHIZDEYorGFh32eK3h+yc06XYqA2MyyLCmk0lobAFC04NsTyCGjOAbrp5svrs/N1sqeRegKscrF2aiz1ZfJweZPjLzojB0fdPcqFcv481592Y15KiKOLBDyd
	OPw1b37JZ3Qosdspk2Eh71iZ3MmJafLE/2l4w/pjBiiRMVJKjOtLItypb18LkxCmSilAIAorQCA0nLl0lGSqY5kyCP55bFpOwvW1vo79+7vb+z5yjSF1Wg9RaNNjKxRlObPnd/c+UurPFMZPzO5cPpcIt/c/HApaZp+Jzoa6FKhcu4kogzZFGmEGgczG6v1O+8uLp1eQ0VdOrXuLFqu0mAwwZkUCBOMmJAKDAIgAJq88f1/NucwtbZqaXP9pfNnFxY++ujmI4OZVzoYHfKtxnrY2PFAS46yuJTPNzvNYXvbDJsvTfr/5PSJl3/676cbhzvPV4ccbN9KTCoHHYa5xQoZRPpglw1SEim5tzN58KSc4b1LFzEmFiMEYwCSca01MsYAAoyRUYrGgjXOXfgbg8aE5hPV8vsPPr7XHJaPn4x6MY0GjsUWvnxy+dLSB7+43W6zN77y9Q/e/3ENvMvI/dO4WftX/xzidDvrO7Mnxqt+P0kshcCyRj2pe89zKSKxVjrWWKs4balUO/s26MwgqZU2JsmkUhjAAPpr0ACA3vjKydHuAa56B2u7Hz59qDFOkD149x1n9VkW81LevvCH54b5ztiY/+rLr7zxu1+TwdEr99deD0Ln1tMw4ixVhVpuemZGYT5W8JQCgyAMR1whY1IGqRI8E1ks0m2pnqq0k6ogUpgRroBLDQgjDBgTjAEUUgDUJI16Se7sbcWdfoxdzrRUwj7aV1I7165Mnjhx+oLz2+CTyclL3/2D74ApfOFr3w4Hf7778/dmSclIzoXKTy6n2QBrjRQyBPdGQ6RVlCQ8TXScMGk8iwWErsV8Z/58J9KZ0IgbBJgQiok2BghBCCFjMACQlesvrzjY/tWtOM0EoZwCU0Ym2ag+VZ5fLOf9xZXph61s8dibtdpYnApmFe3JmX6372UByfg+wKNOt+hYSgHBNjiesW3H9SyhqEKJlE2ZHiSjrVS2c8Xm639nhEoACAzGhDCGKSVKGQ
	AwBgECxQXNuz7uD1QvQFJEeeOm0iiFBbDu/uEzwW8O+P826hu/d6v0/PTx5Y8/ee/l66/lFqdqb9xQ//pRJ+KBwfmp8U1tmkgnXqaxbPd6/V4fJ1kJ6JQhderZ1OvE/aYSfeKBAYSQQVgbI5Q2UgMgBMgYAxgBAE1U6uQKuS9e7310qzwQ2pDUghR4JU3UZji07BfFamHtIF00O839zx7ceeXaFxGY/J1Hz1sHPEGHDlnTreLkyeNXrpQLDgjtBHF+GI6i4VEYfnpwpAejvNBnUdG2qkBdw4w2Bhv0eXeZzwMfIYQ+7zKgc7VynCux73176ktXV//ix6Onq67RxIhEGTDSHybQH4Xt6LU3317f2pycmGJUVxudOZ+o6Zn764dB0YHx6dCwp88eIYSIxpLLIIziLJbSOAKEW9QlZ7Posijv5awsSw1yDMIAGMAgZBBCGGNjDEJGAdCJnI9thwHLFr3pt9+e3Wl2W41fbj1NlD51sHvmxeP1YfqMya9fvfaf//E/3T/cfPP6K8vv3Wz/3w/SxiBPaDFUeGZ6V2Sd7UOtACmkpeRSaI0wMogZYzNk05KfG5Z8q5a9bBeaA90P0kRixGyuPqddY4wwQgKAFosVQjEANjF1lFIz4/1x50g0kyR+uVi79jtf/vmHL4LKhZ7WreYWMbH5b/8zu3vHGkUZlxjrSOkzy/Px/n5fYxAxNUCNIdhIojEhmDFM3By2sWdJNlajeKmUnqiwQNuRZJ0I398LDVBkABPABgEA7o/CMEhlplzHKlZL1WJVY4LB5Ci6+p2rvRv1uxm8evba/Qe/UaPuDUEXP/kNTdJewqtV/+zlK9yQnfWtdrsVp+koEWEmpQELUwcTqrGMVZpEiUqVU43PflUzLR2pbFqkenncKniZsRNjcaAcocRmGQBQh1kIISmllJLrbG/3oCujE7PHahYo8eDu46fUqawsLzx4+vEZN/eHQcJHyVBjz5DqsYWOwDm/nmP52TF
	vY79x1O4bKcp5b7JWIQoNklRhYhvKjBkfCrf3xJ7+ijVKo+TAsQuO4wKlDsMGpRRjlYm8U+wBp57jWrYlpFRKGa7G56b/4i//x0Hj4OKU9/03Tj3e3BuvFvP1QhJmf2Zcuz/UhGiNWK3a7US8Ovvaq7/zcXenmfWqrmdKpTRLGCO9KELGhJmIOHcZLY9XGo3BBTrUJxuzCtJ8refnuDY6EwRjbaRnA3OxjQ0AUK2U4EIZrYw2gIYyzVQyNV48e9wzRt6729p5sl+2ci8/+Gy80x5hMFIBsZOyf4TIrC4Uld05bChP+kpZNo4RywAERgyTPCJgO1bBmfALzb3B5msXrg0UqxaG5QJgy0UMrIxYjAhHZ4HtJVW3uAaCUkYNGAxGKYkBd/pNC2AizxYq/LPHn9hWfb4eFxob59cakhpXmIaCnGu9u7td9MdajTsvnbxAmY94YEFojOEGEcYQAYSY4VEx79J8QQ+yiPlBFq/aE1Gt7BmTwwo7jh5wjDlxGDWKMGKMAgBsW45t2TazGWHI0hs7G1oJIgavXjmTCKcXwJeuXsv+zwexyhLmxoRix3rEUAv0++3tDweHdzafvlZfxH6RS8cYAkAPW/0Xe612t2sAwNC0nz67t+rmcgEPW82+yEgqdZImo2Gnfbge9p6AaliuGsUj5lAAoJQxKYUCDYAEhkEYFPzCXA0q9eLme0m7K6auTgUf3ynYrCzprhJHBSdYnLX3jvSoNwrMzfbW7Y9aIaCwQMHlOS83XvWTRGDLihCkoyTujpiiBAOSYTKAOAjdXAFjLGTWae0/W3skwa3WJiYnpse9BQCgwyhCCAhBwOgoDErVCd1tLc2ge4+fBKHDjJk/fsrR76BhHBoIy6VoeSlFEmxKHNpN0rGJqbDbV9KwgWj3IlWQhGGlTXuUacvKMxtJhA3oLGZJL+Nht1M/eeZaq90wGDtu7tj8cYUsIU3J8yzKAAQVimdSICmlUQ93Xxw1W8cnxhYW
	wkKhY/C8X+ufq891Wy3P4Nsg26eWolx9dLC9P+wpZBKbNnv9AiGWlipNXEP1gGNKjJIFg0lmLJOWmS2UylMU91qWXw663X4nUAYjkNRxX9zd0oj4lclykTNCAIDatqORMVpJhNY21raP9lS0+bdeWd7ePXr8wlqaXiK//qDX3P20Nr41tZASRtSwhSRCUHVsZkO3F9qkgFKJDC4QprRSmcgTSjHFBjEwjtR5hEm7xxzmunkZhL1Od2F5th+2DQJDqF2ezo8vAcbUpABAkyTjUhjJRzrRQe9CsXj9st0ZbDVeDK8M7b+Nk+7qnaevfvVAC8G5ATTx2mtLRt7+d/+WpKHrWEnRO2gPxqUtMU4UV0bbzMKISCmBIKAUAGyAzvZWrmjZ1SJS/OHde/MzE2OVeqHgX3n5qnLHO/3UIO55GAAoF0pppbTuBoOEGkqsGqPXotlLvUp1pto8ffGdXuPFbz+lsSL5YovoW+++c2q8rmyLaocinCN6VLaToZFcYoM0xpHiHFAOU8aIBpAAgFEmZNLpmFpJsk5hciYeDmsTi/fuf7bX2auWx0rjc47v7j2+BXCRUoK4QQDQaB0Zg7SRhVSxx0NfzHWPrzxfXlj76EObxxqhv1p7fOLiJd8Ujp890z46HG5tGNAIKdtloRCJUjnMMAKsMEK4RbhCAhuMElkkdozAjIb5YZToZiDM5XNntQ2u5VKtGzsbe/tbpXye1SbBvkgJAMVYEzIajTyEj83YQ7/104Xhb37WvLGwEm3shUnAMhUiM1AZz9KjVmtydrpFCAeFMaYWtQBpn0mtBpkCpZAFiGLm2KAhHaY5REEjhJUDhAcxx05hLBcnaa1UKjALE+aVqpHIJienbBAAgEt+frxURBZRBkOuNF2lC2P4fif7JXa2uD7Y3+VxQlO5GwfMyecK+Xq1WB8b6yaBJEhqhRBGGGML56s+rnhW3XeqBavoEERFkFmAkdIIQR4wjlMRxx5zUgG3769qo
	U7MzLS7w04QGcs2zPbLPgDg3qAXh8PV7fXEoPm5xWIt543nRe585djS1vN7+MXDwfZGe9Dc63XSRBwcNOIoAgQjkQqGhdGAkNEaaUW0ylnUw9g1BIdKdsK8op4hNiUSa8VFvVI5ff6sSFOG2YOnG0kii26+6BeJxbjRSZpg1wMAbDMgFjxZvb+/u/X81ntJZysYos7hcNbLjy1MPtp6gkbdqD+oF6vFSs3NeTNT04NePwQtsNZAldYGIaUUaIkkRxrCME0GSQk7HmCiDQWEAQMCGcYXjh2zjQShohiGcXb1pQvH5ueLOafgOkaK2bEiAFDFZTcc2CpayMPSWO3kUn5zbXtwNNjfffTW3/9Hd29+mISBkWRhYf7333xzZqKUBaNOp9/ziqUgwSBSJGxqy0xrYUAZLkUUpXVs5zHJQEstkAFsMGNOOgiS++s05AiACp7G8Vi1xMPk5LFjbrGUQzA3UYOHQA1mz7e3D1qDAtNTp+cZNd2B+NaXvtjvqGrRs4pETXuHR73NezcDHTsMX7n2ansYzc2drnO7K5+vzEwqrtf3okAbkxgeZyCMTy0bUY1U9v/FmMUoaHPc5LOZY7/urk9Yo3H2eu+ou1ir/urxqtHZialp98wUAGAA9XhrPaH+SJPKhB+lfL2de//uemblk0hcml34g7feOHN+5eyZk6eXpoP2YaXsdzdXv3ugb9SXSi75va9d+4f/4I+/89aNotb9ILYFnrYLHsYUAUMYGQAD1CCCSd0tfPrg/hwH0ttctgN7dDjGu0sOdqmZKlvnj88SpAGAPtnYyESKVFTP8Zw16rUOW116FOPr5fqz7b2fP36hP+7zWAkplxdmEUEF1748O/7wg59MaOv7J065NzcOnrW8nKeo48lwxStSLi3QgCkiaATYGMMMgNG1QmlfxxO9Xtn1Ro2+UnDz5z+LgzTP0Hgtl7MhzmIAwI/XVgNBAqNXTh2v5Mwwg3Z3wEfJ7OxyHHPb9SNuEi
	64Ed1RmAjm58rbHz85qdCfzi2fHfH67sj+6EX6s0/hoPvW5Mmq5MwimlCikUXtIYOYIYWUz1impU75ve6WzeHK+OKf/+AHYchVKuJRsLrTfHHY6A77AEAnZ6bBXc6ePj+1UOmPntxfkx3t5yzI5Uu7e3sYEDKmXirisisJnqxPH7Q68aD3rYVllkQJF6GUsRQmiE4j9/Wpkz9tHhGtDSUKACgOmcmQdhS1LDvLMoOwjJJ4d/ir4cfP0qaA23pxWc5N0FKhnQiLMQCgFceSFl24dPwLF4s/efe2P3llmoAbB5ZLw3gYxFE/jkdZNl8udA47KyunB72jb1Qn7c5gmGVcqJTzkVbAzY1TV89fvHR398nBYMgNikD5mhSQHWJuXM/OFaJhKLHhowAIWfjGl7b3nwbx8Nw3f9cCEDJjXAeDEQCQOGjFRzsny8FkRe43i0+fH2jIn5qZkxG/fft+rlDNlSYzxOanZxuj/hfPnLu+erCyvquSmKd6oOORkoMw+VTEb37hm6oXzdq5o2DU0akUMnbJhhgUHHeCelRBnGXDLAGDLMcrvHJ58dtvfXC4tdntCQG+bU/MTPl8sD5cIlMztSAOvvX6ceJEO3tHn7z3JG20XJleu3w1ToPdvQ0j+GS9/vWv3Xjl1Onru935W59ClnZGQ4sxi7FA8N+OBs8QOZqvD20z7fpoGDbikIMwMiNSlRG1DVWZiHiCCHUtG1vW+T/6fXDtrfZRnGSDqN8bdMbLpaS909EXaYBYKafPXl367PH9nd0gzTRRoWPnKWJ/81vfPnNy5Yc//OGt28/nHHhjoz03AD4cZdgUixULcJylFnZ7AOlYuXjj5R/9x//033cPr1VnRjKyLUtkkRYyFIJDUsv5DsWI0ZFUr/2977Gx+iCJDnu9IAgRNYVqaTjomFEEOaA2QV//8qLD0t2do62dWChIs2R8cqbgl0DJ4/NLb//dtzvd7kub2xceHQUqjJDqRmHQjQuOqyn
	ZiaKpyoRz4wuXzr70/MTyi8bR+72NEqPVTGL4a1NvIQRK5Cw3MDBz+RI6tpAAhJIzy65WEGOEYEhF5iv6+VE0F05P+f7Ui61Od4iV1hb1p6amM5USQFoh368t5IvjP/m1ylIuJAhFCGXMotQyjGCbbzX39p88Pvyv/8V2XZT3yED2sHYskteYCcIwBg0DwTVzZLkQ1XyTSuvzgUCpEglFVGMMmNSrzpEAim310sWX7j5ZI9Zc5/ARF6w651dqVSllKIWJhxF3is9XaaPNNOQsBkAdLRLCNMbNLBYGIbcgbdJu7iEpjO+aOE45fxIPl73SuFeORBpgaSwmPUp8ZutU89S1LRwazKgyFkLYY7bHnIXp4sNtoCtLtYnx8n/40Y+2d5U21PfL/+YH/5JqY7v5Ti950DksKlV4+CQnpaY441xzJUBigjMpM6N247ANOGKUKAnaOPliRILBsJ8geDDq1ZhjuzatFsMoKlBdMUbE8aDfY5S5tnvp8pWUZzzL0iR2bdbpHALA/wMUjQteOh3xIgAAAABJRU5ErkJggg==
X-Mailer: Evolution 3.2.2 (3.2.2-1.fc16) 
Mime-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>, Keir Fraser <keir@xen.org>
Subject: [Xen-devel] [PATCHv2] sedf: remove useless tracing printk and
 harmonize comments style.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============2284887627372470128=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--===============2284887627372470128==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-oVXZhmqkWYbyP3+4MWM6"


--=-oVXZhmqkWYbyP3+4MWM6
Content-Type: multipart/mixed; boundary="=-DM3xwBkUsBWsFUckworM"


--=-DM3xwBkUsBWsFUckworM
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

sched_sedf.c used o have its own mechanism for producing tracing-alike
kind of information (domain block, wakeup, etc.). Nowadays, with an even
not so high number of pCPUs/vCPUs, just trying to enable this makes
the serial console completely unusable, produces tons of very hard to
parse and interpreet logging and can easily livelock Dom0. Moreover,
pretty much the same result this is struggling to get to, is better
achieved by enabling the scheduler-related tracing events, as
it is for the other schedulers (say, credit or credit2).

For all these reasons, this removes that machinery completely. While at
it, check in some cosmetics that harmonize the comments withim themself
and with the rest of the code base.

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>

diff -r 51045a5ec6bc xen/common/sched_sedf.c
--- a/xen/common/sched_sedf.c	Wed Dec 21 14:49:01 2011 +0000
+++ b/xen/common/sched_sedf.c	Wed Dec 21 15:12:07 2011 +0000
@@ -13,14 +13,6 @@
 #include <xen/time.h>
 #include <xen/errno.h>
=20
-/*verbosity settings*/
-#define SEDFLEVEL 0
-#define PRINT(_f, _a...)                        \
-    do {                                        \
-        if ( (_f) <=3D SEDFLEVEL )                \
-            printk(_a );                        \
-    } while ( 0 )
-
 #define SEDF_CPUONLINE(_pool)                                             =
\
     (((_pool) =3D=3D NULL) ? &cpupool_free_cpus : (_pool)->cpu_valid)
=20
@@ -66,34 +58,35 @@ struct sedf_vcpu_info {
     struct list_head list;
     struct list_head extralist[2];
 =20
-    /*Parameters for EDF*/
-    s_time_t  period;  /*=3D(relative deadline)*/
-    s_time_t  slice;  /*=3Dworst case execution time*/
+    /* Parameters for EDF */
+    s_time_t  period;  /* =3D(relative deadline) */
+    s_time_t  slice;   /* =3Dworst case execution time */
 =20
-    /*Advaced Parameters*/
-    /*Latency Scaling*/
+    /* Advaced Parameters */
+
+    /* Latency Scaling */
     s_time_t  period_orig;
     s_time_t  slice_orig;
     s_time_t  latency;
 =20
-    /*status of domain*/
+    /* Status of domain */
     int       status;
-    /*weights for "Scheduling for beginners/ lazy/ etc." ;)*/
+    /* Weights for "Scheduling for beginners/ lazy/ etc." ;) */
     short     weight;
     short     extraweight;
-    /*Bookkeeping*/
+    /* Bookkeeping */
     s_time_t  deadl_abs;
     s_time_t  sched_start_abs;
     s_time_t  cputime;
-    /* times the domain un-/blocked */
+    /* Times the domain un-/blocked */
     s_time_t  block_abs;
     s_time_t  unblock_abs;
 =20
-    /*scores for {util, block penalty}-weighted extratime distribution*/
+    /* Scores for {util, block penalty}-weighted extratime distribution */
     int   score[2];
     s_time_t  short_block_lost_tot;
 =20
-    /*Statistics*/
+    /* Statistics */
     s_time_t  extra_time_tot;
=20
 #ifdef SEDF_STATS
@@ -158,18 +151,17 @@ static inline void extraq_del(struct vcp
 {
     struct list_head *list =3D EXTRALIST(d,i);
     ASSERT(extraq_on(d,i));
-    PRINT(3, "Removing domain %i.%i from L%i extraq\n",
-          d->domain->domain_id, d->vcpu_id, i);
     list_del(list);
     list->next =3D NULL;
     ASSERT(!extraq_on(d, i));
 }
=20
-/* adds a domain to the queue of processes which are aware of extra time. =
List
-   is sorted by score, where a lower score means higher priority for an ex=
tra
-   slice. It also updates the score, by simply subtracting a fixed value f=
rom
-   each entry, in order to avoid overflow. The algorithm works by simply
-   charging each domain that recieved extratime with an inverse of its wei=
ght.
+/*
+ * Adds a domain to the queue of processes which are aware of extra time. =
List
+ * is sorted by score, where a lower score means higher priority for an ex=
tra
+ * slice. It also updates the score, by simply subtracting a fixed value f=
rom
+ * each entry, in order to avoid overflow. The algorithm works by simply
+ * charging each domain that recieved extratime with an inverse of its wei=
ght.
  */=20
 static inline void extraq_add_sort_update(struct vcpu *d, int i, int sub)
 {
@@ -178,11 +170,6 @@ static inline void extraq_add_sort_updat
 =20
     ASSERT(!extraq_on(d,i));
=20
-    PRINT(3, "Adding domain %i.%i (score=3D %i, short_pen=3D %"PRIi64")"
-          " to L%i extraq\n",
-          d->domain->domain_id, d->vcpu_id, EDOM_INFO(d)->score[i],
-          EDOM_INFO(d)->short_block_lost_tot, i);
-
     /*
      * Iterate through all elements to find our "hole" and on our way
      * update all the other scores.
@@ -193,25 +180,18 @@ static inline void extraq_add_sort_updat
         curinf->score[i] -=3D sub;
         if ( EDOM_INFO(d)->score[i] < curinf->score[i] )
             break;
-        PRINT(4,"\tbehind domain %i.%i (score=3D %i)\n",
-              curinf->vcpu->domain->domain_id,
-              curinf->vcpu->vcpu_id, curinf->score[i]);
     }
=20
-    /* cur now contains the element, before which we'll enqueue. */
-    PRINT(3, "\tlist_add to %p\n", cur->prev);
+    /* cur now contains the element, before which we'll enqueue */
     list_add(EXTRALIST(d,i),cur->prev);
 =20
-    /* Continue updating the extraq. */
+    /* Continue updating the extraq */
     if ( (cur !=3D EXTRAQ(d->processor,i)) && sub )
     {
         for ( cur =3D cur->next; cur !=3D EXTRAQ(d->processor,i); cur =3D =
cur->next )
         {
             curinf =3D list_entry(cur,struct sedf_vcpu_info, extralist[i])=
;
             curinf->score[i] -=3D sub;
-            PRINT(4, "\tupdating domain %i.%i (score=3D %u)\n",
-                  curinf->vcpu->domain->domain_id,=20
-                  curinf->vcpu->vcpu_id, curinf->score[i]);
         }
     }
=20
@@ -221,29 +201,14 @@ static inline void extraq_check(struct v
 {
     if ( extraq_on(d, EXTRA_UTIL_Q) )
     {
-        PRINT(2,"Dom %i.%i is on L1 extraQ\n",
-              d->domain->domain_id, d->vcpu_id);
-
         if ( !(EDOM_INFO(d)->status & EXTRA_AWARE) &&
              !extra_runs(EDOM_INFO(d)) )
-        {
             extraq_del(d, EXTRA_UTIL_Q);
-            PRINT(2,"Removed dom %i.%i from L1 extraQ\n",
-                  d->domain->domain_id, d->vcpu_id);
-        }
     }
     else
     {
-        PRINT(2, "Dom %i.%i is NOT on L1 extraQ\n",
-              d->domain->domain_id,
-              d->vcpu_id);
-
         if ( (EDOM_INFO(d)->status & EXTRA_AWARE) && sedf_runnable(d) )
-        {
             extraq_add_sort_update(d, EXTRA_UTIL_Q, 0);
-            PRINT(2,"Added dom %i.%i to L1 extraQ\n",
-                  d->domain->domain_id, d->vcpu_id);
-        }
     }
 }
=20
@@ -252,7 +217,7 @@ static inline void extraq_check_add_unbl
     struct sedf_vcpu_info *inf =3D EDOM_INFO(d);
=20
     if ( inf->status & EXTRA_AWARE )
-        /* Put on the weighted extraq without updating any scores. */
+        /* Put on the weighted extraq without updating any scores */
         extraq_add_sort_update(d, EXTRA_UTIL_Q, 0);
 }
=20
@@ -265,8 +230,6 @@ static inline void __del_from_queue(stru
 {
     struct list_head *list =3D LIST(d);
     ASSERT(__task_on_queue(d));
-    PRINT(3,"Removing domain %i.%i (bop=3D %"PRIu64") from runq/waitq\n",
-          d->domain->domain_id, d->vcpu_id, PERIOD_BEGIN(EDOM_INFO(d)));
     list_del(list);
     list->next =3D NULL;
     ASSERT(!__task_on_queue(d));
@@ -279,13 +242,12 @@ static inline void list_insert_sort(
 {
     struct list_head     *cur;
=20
-    /* Iterate through all elements to find our "hole". */
+    /* Iterate through all elements to find our "hole" */
     list_for_each( cur, list )
         if ( comp(element, cur) < 0 )
             break;
=20
-    /* cur now contains the element, before which we'll enqueue. */
-    PRINT(3,"\tlist_add to %p\n",cur->prev);
+    /* cur now contains the element, before which we'll enqueue */
     list_add(element, cur->prev);
 }
=20
@@ -303,30 +265,28 @@ static int name##_comp(struct list_head*
         return 1;                                                       \
 }
=20
-/* adds a domain to the queue of processes which wait for the beginning of=
 the
-   next period; this list is therefore sortet by this time, which is simpl=
y
-   absol. deadline - period
+/*
+ * Adds a domain to the queue of processes which wait for the beginning of=
 the
+ * next period; this list is therefore sortet by this time, which is simpl=
y
+ * absol. deadline - period.
  */=20
 DOMAIN_COMPARER(waitq, list, PERIOD_BEGIN(d1), PERIOD_BEGIN(d2));
 static inline void __add_to_waitqueue_sort(struct vcpu *v)
 {
     ASSERT(!__task_on_queue(v));
-    PRINT(3,"Adding domain %i.%i (bop=3D %"PRIu64") to waitq\n",
-          v->domain->domain_id, v->vcpu_id, PERIOD_BEGIN(EDOM_INFO(v)));
     list_insert_sort(WAITQ(v->processor), LIST(v), waitq_comp);
     ASSERT(__task_on_queue(v));
 }
=20
-/* adds a domain to the queue of processes which have started their curren=
t
-   period and are runnable (i.e. not blocked, dieing,...). The first eleme=
nt
-   on this list is running on the processor, if the list is empty the idle
-   task will run. As we are implementing EDF, this list is sorted by deadl=
ines.
+/*
+ * Adds a domain to the queue of processes which have started their curren=
t
+ * period and are runnable (i.e. not blocked, dieing,...). The first eleme=
nt
+ * on this list is running on the processor, if the list is empty the idle
+ * task will run. As we are implementing EDF, this list is sorted by deadl=
ines.
  */=20
 DOMAIN_COMPARER(runq, list, d1->deadl_abs, d2->deadl_abs);
 static inline void __add_to_runqueue_sort(struct vcpu *v)
 {
-    PRINT(3,"Adding domain %i.%i (deadl=3D %"PRIu64") to runq\n",
-          v->domain->domain_id, v->vcpu_id, EDOM_INFO(v)->deadl_abs);
     list_insert_sort(RUNQ(v->processor), LIST(v), runq_comp);
 }
=20
@@ -453,10 +413,10 @@ static void desched_edf_dom(s_time_t now
 {
     struct sedf_vcpu_info* inf =3D EDOM_INFO(d);
=20
-    /* Current domain is running in real time mode. */
+    /* Current domain is running in real time mode */
     ASSERT(__task_on_queue(d));
=20
-    /* Update the domain's cputime. */
+    /* Update the domain's cputime */
     inf->cputime +=3D now - inf->sched_start_abs;
=20
     /*
@@ -467,7 +427,7 @@ static void desched_edf_dom(s_time_t now
         return;
  =20
     __del_from_queue(d);
- =20
+
     /*
      * Manage bookkeeping (i.e. calculate next deadline, memorise
      * overrun-time of slice) of finished domains.
@@ -478,30 +438,30 @@ static void desched_edf_dom(s_time_t now
  =20
         if ( inf->period < inf->period_orig )
         {
-            /* This domain runs in latency scaling or burst mode. */
+            /* This domain runs in latency scaling or burst mode */
             inf->period *=3D 2;
             inf->slice  *=3D 2;
             if ( (inf->period > inf->period_orig) ||
                  (inf->slice > inf->slice_orig) )
             {
-                /* Reset slice and period. */
+                /* Reset slice and period */
                 inf->period =3D inf->period_orig;
                 inf->slice =3D inf->slice_orig;
             }
         }
=20
-        /* Set next deadline. */
+        /* Set next deadline */
         inf->deadl_abs +=3D inf->period;
     }
 =20
-    /* Add a runnable domain to the waitqueue. */
+    /* Add a runnable domain to the waitqueue */
     if ( sedf_runnable(d) )
     {
         __add_to_waitqueue_sort(d);
     }
     else
     {
-        /* We have a blocked realtime task -> remove it from exqs too. */
+        /* We have a blocked realtime task -> remove it from exqs too */
         if ( extraq_on(d, EXTRA_PEN_Q) )
             extraq_del(d, EXTRA_PEN_Q);
         if ( extraq_on(d, EXTRA_UTIL_Q) )
@@ -521,8 +481,6 @@ static void update_queues(
     struct list_head     *cur, *tmp;
     struct sedf_vcpu_info *curinf;
 =20
-    PRINT(3,"Updating waitq..\n");
-
     /*
      * Check for the first elements of the waitqueue, whether their
      * next period has already started.
@@ -530,41 +488,32 @@ static void update_queues(
     list_for_each_safe ( cur, tmp, waitq )
     {
         curinf =3D list_entry(cur, struct sedf_vcpu_info, list);
-        PRINT(4,"\tLooking @ dom %i.%i\n",
-              curinf->vcpu->domain->domain_id, curinf->vcpu->vcpu_id);
         if ( PERIOD_BEGIN(curinf) > now )
             break;
         __del_from_queue(curinf->vcpu);
         __add_to_runqueue_sort(curinf->vcpu);
     }
 =20
-    PRINT(3,"Updating runq..\n");
-
-    /* Process the runq, find domains that are on the runq that shouldn't.=
 */
+    /* Process the runq, find domains that are on the runq that shouldn't =
*/
     list_for_each_safe ( cur, tmp, runq )
     {
         curinf =3D list_entry(cur,struct sedf_vcpu_info,list);
-        PRINT(4,"\tLooking @ dom %i.%i\n",
-              curinf->vcpu->domain->domain_id, curinf->vcpu->vcpu_id);
=20
         if ( unlikely(curinf->slice =3D=3D 0) )
         {
-            /* Ignore domains with empty slice. */
-            PRINT(4,"\tUpdating zero-slice domain %i.%i\n",
-                  curinf->vcpu->domain->domain_id,
-                  curinf->vcpu->vcpu_id);
+            /* Ignore domains with empty slice */
             __del_from_queue(curinf->vcpu);
=20
-            /* Move them to their next period. */
+            /* Move them to their next period */
             curinf->deadl_abs +=3D curinf->period;
=20
-            /* Ensure that the start of the next period is in the future. =
*/
+            /* Ensure that the start of the next period is in the future *=
/
             if ( unlikely(PERIOD_BEGIN(curinf) < now) )
                 curinf->deadl_abs +=3D=20
                     (DIV_UP(now - PERIOD_BEGIN(curinf),
                             curinf->period)) * curinf->period;
=20
-            /* Put them back into the queue. */
+            /* Put them back into the queue */
             __add_to_waitqueue_sort(curinf->vcpu);
         }
         else if ( unlikely((curinf->deadl_abs < now) ||
@@ -574,18 +523,18 @@ static void update_queues(
              * We missed the deadline or the slice was already finished.
              * Might hapen because of dom_adj.
              */
-            PRINT(4,"\tDomain %i.%i exceeded it's deadline/"
-                  "slice (%"PRIu64" / %"PRIu64") now: %"PRIu64
-                  " cputime: %"PRIu64"\n",
-                  curinf->vcpu->domain->domain_id,
-                  curinf->vcpu->vcpu_id,
-                  curinf->deadl_abs, curinf->slice, now,
-                  curinf->cputime);
+            printk("\tDomain %i.%i exceeded it's deadline/"
+                   "slice (%"PRIu64" / %"PRIu64") now: %"PRIu64
+                   " cputime: %"PRIu64"\n",
+                   curinf->vcpu->domain->domain_id,
+                   curinf->vcpu->vcpu_id,
+                   curinf->deadl_abs, curinf->slice, now,
+                   curinf->cputime);
             __del_from_queue(curinf->vcpu);
=20
-            /* Common case: we miss one period. */
+            /* Common case: we miss one period */
             curinf->deadl_abs +=3D curinf->period;
-  =20
+
             /*
              * If we are still behind: modulo arithmetic, force deadline
              * to be in future and aligned to period borders.
@@ -596,7 +545,7 @@ static void update_queues(
                            curinf->period) * curinf->period;
             ASSERT(curinf->deadl_abs >=3D now);
=20
-            /* Give a fresh slice. */
+            /* Give a fresh slice */
             curinf->cputime =3D 0;
             if ( PERIOD_BEGIN(curinf) > now )
                 __add_to_waitqueue_sort(curinf->vcpu);
@@ -606,17 +555,17 @@ static void update_queues(
         else
             break;
     }
-
-    PRINT(3,"done updating the queues\n");
 }
=20

-/* removes a domain from the head of the according extraQ and
-   requeues it at a specified position:
-     round-robin extratime: end of extraQ
-     weighted ext.: insert in sorted list by score
-   if the domain is blocked / has regained its short-block-loss
-   time it is not put on any queue */
+/*
+ * removes a domain from the head of the according extraQ and
+ * requeues it at a specified position:
+ *   round-robin extratime: end of extraQ
+ *   weighted ext.: insert in sorted list by score
+ * if the domain is blocked / has regained its short-block-loss
+ * time it is not put on any queue.
+ */
 static void desched_extra_dom(s_time_t now, struct vcpu *d)
 {
     struct sedf_vcpu_info *inf =3D EDOM_INFO(d);
@@ -625,29 +574,25 @@ static void desched_extra_dom(s_time_t n
=20
     ASSERT(extraq_on(d, i));
=20
-    /* Unset all running flags. */
+    /* Unset all running flags */
     inf->status  &=3D ~(EXTRA_RUN_PEN | EXTRA_RUN_UTIL);
-    /* Fresh slice for the next run. */
+    /* Fresh slice for the next run */
     inf->cputime =3D 0;
-    /* Accumulate total extratime. */
+    /* Accumulate total extratime */
     inf->extra_time_tot +=3D now - inf->sched_start_abs;
     /* Remove extradomain from head of the queue. */
     extraq_del(d, i);
=20
-    /* Update the score. */
+    /* Update the score */
     oldscore =3D inf->score[i];
     if ( i =3D=3D EXTRA_PEN_Q )
     {
-        /*domain was running in L0 extraq*/
-        /*reduce block lost, probably more sophistication here!*/
+        /* Domain was running in L0 extraq */
+        /* reduce block lost, probably more sophistication here!*/
         /*inf->short_block_lost_tot -=3D EXTRA_QUANTUM;*/
         inf->short_block_lost_tot -=3D now - inf->sched_start_abs;
-        PRINT(3,"Domain %i.%i: Short_block_loss: %"PRIi64"\n",=20
-              inf->vcpu->domain->domain_id, inf->vcpu->vcpu_id,
-              inf->short_block_lost_tot);
 #if 0
-        /*
-         * KAF: If we don't exit short-blocking state at this point
+        /* KAF: If we don't exit short-blocking state at this point
          * domain0 can steal all CPU for up to 10 seconds before
          * scheduling settles down (when competing against another
          * CPU-bound domain). Doing this seems to make things behave
@@ -656,51 +601,59 @@ static void desched_extra_dom(s_time_t n
         if ( inf->short_block_lost_tot <=3D 0 )
 #endif
         {
-            PRINT(4,"Domain %i.%i compensated short block loss!\n",
-                  inf->vcpu->domain->domain_id, inf->vcpu->vcpu_id);
-            /*we have (over-)compensated our block penalty*/
+            /* We have (over-)compensated our block penalty */
             inf->short_block_lost_tot =3D 0;
-            /*we don't want a place on the penalty queue anymore!*/
+            /* We don't want a place on the penalty queue anymore! */
             inf->status &=3D ~EXTRA_WANT_PEN_Q;
             goto check_extra_queues;
         }
=20
-        /*we have to go again for another try in the block-extraq,
-          the score is not used incremantally here, as this is
-          already done by recalculating the block_lost*/
+        /*
+         * We have to go again for another try in the block-extraq,
+         * the score is not used incremantally here, as this is
+         * already done by recalculating the block_lost
+         */
         inf->score[EXTRA_PEN_Q] =3D (inf->period << 10) /
             inf->short_block_lost_tot;
         oldscore =3D 0;
     }
     else
     {
-        /*domain was running in L1 extraq =3D> score is inverse of
-          utilization and is used somewhat incremental!*/
+        /*
+         * Domain was running in L1 extraq =3D> score is inverse of
+         * utilization and is used somewhat incremental!
+         */
         if ( !inf->extraweight )
-            /*NB: use fixed point arithmetic with 10 bits*/
+        {
+            /* NB: use fixed point arithmetic with 10 bits */
             inf->score[EXTRA_UTIL_Q] =3D (inf->period << 10) /
                 inf->slice;
+        }
         else
-            /*conversion between realtime utilisation and extrawieght:
-              full (ie 100%) utilization is equivalent to 128 extraweight*=
/
+        {
+            /*
+             * Conversion between realtime utilisation and extrawieght:
+             * full (ie 100%) utilization is equivalent to 128 extraweight
+             */
             inf->score[EXTRA_UTIL_Q] =3D (1<<17) / inf->extraweight;
+        }
     }
=20
  check_extra_queues:
-    /* Adding a runnable domain to the right queue and removing blocked on=
es*/
+    /* Adding a runnable domain to the right queue and removing blocked on=
es */
     if ( sedf_runnable(d) )
     {
-        /*add according to score: weighted round robin*/
+        /* Add according to score: weighted round robin */
         if (((inf->status & EXTRA_AWARE) && (i =3D=3D EXTRA_UTIL_Q)) ||
             ((inf->status & EXTRA_WANT_PEN_Q) && (i =3D=3D EXTRA_PEN_Q)))
             extraq_add_sort_update(d, i, oldscore);
     }
     else
     {
-        /*remove this blocked domain from the waitq!*/
+        /* Remove this blocked domain from the waitq! */
         __del_from_queue(d);
-        /*make sure that we remove a blocked domain from the other
-          extraq too*/
+        /* Make sure that we remove a blocked domain from the other
+         * extraq too. */
         if ( i =3D=3D EXTRA_PEN_Q )
         {
             if ( extraq_on(d, EXTRA_UTIL_Q) )
@@ -732,8 +685,10 @@ static struct task_slice sedf_do_extra_s
=20
     if ( !list_empty(extraq[EXTRA_PEN_Q]) )
     {
-        /*we still have elements on the level 0 extraq=20
-          =3D> let those run first!*/
+        /*
+         * We still have elements on the level 0 extraq
+         * =3D> let those run first!
+         */
         runinf   =3D list_entry(extraq[EXTRA_PEN_Q]->next,=20
                               struct sedf_vcpu_info, extralist[EXTRA_PEN_Q=
]);
         runinf->status |=3D EXTRA_RUN_PEN;
@@ -747,7 +702,7 @@ static struct task_slice sedf_do_extra_s
     {
         if ( !list_empty(extraq[EXTRA_UTIL_Q]) )
         {
-            /*use elements from the normal extraqueue*/
+            /* Use elements from the normal extraqueue */
             runinf   =3D list_entry(extraq[EXTRA_UTIL_Q]->next,
                                   struct sedf_vcpu_info,
                                   extralist[EXTRA_UTIL_Q]);
@@ -772,11 +727,13 @@ static struct task_slice sedf_do_extra_s
 }
=20

-/* Main scheduling function
-   Reasons for calling this function are:
-   -timeslice for the current period used up
-   -domain on waitqueue has started it's period
-   -and various others ;) in general: determine which domain to run next*/
+/*
+ * Main scheduling function
+ * Reasons for calling this function are:
+ * -timeslice for the current period used up
+ * -domain on waitqueue has started it's period
+ * -and various others ;) in general: determine which domain to run next
+ */
 static struct task_slice sedf_do_schedule(
     const struct scheduler *ops, s_time_t now, bool_t tasklet_work_schedul=
ed)
 {
@@ -789,13 +746,15 @@ static struct task_slice sedf_do_schedul
     struct sedf_vcpu_info *runinf, *waitinf;
     struct task_slice      ret;
=20
-    /*idle tasks don't need any of the following stuf*/
+    /* Idle tasks don't need any of the following stuf */
     if ( is_idle_vcpu(current) )
         goto check_waitq;
-=20
-    /* create local state of the status of the domain, in order to avoid
-       inconsistent state during scheduling decisions, because data for
-       vcpu_runnable is not protected by the scheduling lock!*/
+
+    /*
+     * Create local state of the status of the domain, in order to avoid
+     * inconsistent state during scheduling decisions, because data for
+     * vcpu_runnable is not protected by the scheduling lock!
+     */
     if ( !vcpu_runnable(current) )
         inf->status |=3D SEDF_ASLEEP;
 =20
@@ -804,7 +763,7 @@ static struct task_slice sedf_do_schedul
=20
     if ( unlikely(extra_runs(inf)) )
     {
-        /*special treatment of domains running in extra time*/
+        /* Special treatment of domains running in extra time */
         desched_extra_dom(now, current);
     }
     else=20
@@ -814,10 +773,12 @@ static struct task_slice sedf_do_schedul
  check_waitq:
     update_queues(now, runq, waitq);
=20
-    /*now simply pick the first domain from the runqueue, which has the
-      earliest deadline, because the list is sorted*/
-=20
-    /* Tasklet work (which runs in idle VCPU context) overrides all else. =
*/
+    /*
+     * Now simply pick the first domain from the runqueue, which has the
+     * earliest deadline, because the list is sorted
+     *
+     * Tasklet work (which runs in idle VCPU context) overrides all else.
+     */
     if ( tasklet_work_scheduled ||
          (list_empty(runq) && list_empty(waitq)) ||
          unlikely(!cpumask_test_cpu(cpu, SEDF_CPUONLINE(per_cpu(cpupool, c=
pu)))) )
@@ -833,9 +794,11 @@ static struct task_slice sedf_do_schedul
         {
             waitinf  =3D list_entry(waitq->next,
                                   struct sedf_vcpu_info,list);
-            /*rerun scheduler, when scheduled domain reaches it's
-              end of slice or the first domain from the waitqueue
-              gets ready*/
+            /*
+             * Rerun scheduler, when scheduled domain reaches it's
+             * end of slice or the first domain from the waitqueue
+             * gets ready.
+             */
             ret.time =3D MIN(now + runinf->slice - runinf->cputime,
                            PERIOD_BEGIN(waitinf)) - now;
         }
@@ -847,14 +810,18 @@ static struct task_slice sedf_do_schedul
     else
     {
         waitinf  =3D list_entry(waitq->next,struct sedf_vcpu_info, list);
-        /*we could not find any suitable domain=20
-          =3D> look for domains that are aware of extratime*/
+        /*
+         * We could not find any suitable domain=20
+         * =3D> look for domains that are aware of extratime
+         */
         ret =3D sedf_do_extra_schedule(now, PERIOD_BEGIN(waitinf),
                                      extraq, cpu);
     }
=20
-    /*TODO: Do something USEFUL when this happens and find out, why it
-      still can happen!!!*/
+    /*
+     * TODO: Do something USEFUL when this happens and find out, why it
+     * still can happen!!!
+     */
     if ( ret.time < 0)
     {
         printk("Ouch! We are seriously BEHIND schedule! %"PRIi64"\n",
@@ -874,9 +841,6 @@ static struct task_slice sedf_do_schedul
=20
 static void sedf_sleep(const struct scheduler *ops, struct vcpu *d)
 {
-    PRINT(2,"sedf_sleep was called, domain-id %i.%i\n",
-          d->domain->domain_id, d->vcpu_id);
-=20
     if ( is_idle_vcpu(d) )
         return;
=20
@@ -898,7 +862,8 @@ static void sedf_sleep(const struct sche
 }
=20

-/* This function wakes up a domain, i.e. moves them into the waitqueue
+/*
+ * This function wakes up a domain, i.e. moves them into the waitqueue
  * things to mention are: admission control is taking place nowhere at
  * the moment, so we can't be sure, whether it is safe to wake the domain
  * up at all. Anyway, even if it is safe (total cpu usage <=3D100%) there =
are
@@ -972,27 +937,31 @@ static void sedf_sleep(const struct sche
 static void unblock_short_extra_support(
     struct sedf_vcpu_info* inf, s_time_t now)
 {
-    /*this unblocking scheme tries to support the domain, by assigning it
-    a priority in extratime distribution according to the loss of time
-    in this slice due to blocking*/
+    /*
+     * This unblocking scheme tries to support the domain, by assigning it
+     * a priority in extratime distribution according to the loss of time
+     * in this slice due to blocking
+     */
     s_time_t pen;
 =20
-    /*no more realtime execution in this period!*/
+    /* No more realtime execution in this period! */
     inf->deadl_abs +=3D inf->period;
     if ( likely(inf->block_abs) )
     {
-        //treat blocked time as consumed by the domain*/
+        /* Treat blocked time as consumed by the domain */
         /*inf->cputime +=3D now - inf->block_abs;*/
-        /*penalty is time the domain would have
-          had if it continued to run */
+        /*
+         * Penalty is time the domain would have
+         * had if it continued to run.
+         */
         pen =3D (inf->slice - inf->cputime);
         if ( pen < 0 )
             pen =3D 0;
-        /*accumulate all penalties over the periods*/
+        /* Accumulate all penalties over the periods */
         /*inf->short_block_lost_tot +=3D pen;*/
-        /*set penalty to the current value*/
+        /* Set penalty to the current value */
         inf->short_block_lost_tot =3D pen;
-        /*not sure which one is better.. but seems to work well...*/
+        /* Not sure which one is better.. but seems to work well... */
  =20
         if ( inf->short_block_lost_tot )
         {
@@ -1002,28 +971,31 @@ static void unblock_short_extra_support(
             inf->pen_extra_blocks++;
 #endif
             if ( extraq_on(inf->vcpu, EXTRA_PEN_Q) )
-                /*remove domain for possible resorting!*/
+                /* Remove domain for possible resorting! */
                 extraq_del(inf->vcpu, EXTRA_PEN_Q);
             else
-                /*remember that we want to be on the penalty q
-                  so that we can continue when we (un-)block
-                  in penalty-extratime*/
+                /*
+                 * Remember that we want to be on the penalty q
+                 * so that we can continue when we (un-)block
+                 * in penalty-extratime
+                 */
                 inf->status |=3D EXTRA_WANT_PEN_Q;
   =20
-            /*(re-)add domain to the penalty extraq*/
+            /* (re-)add domain to the penalty extraq */
             extraq_add_sort_update(inf->vcpu, EXTRA_PEN_Q, 0);
         }
     }
=20
-    /*give it a fresh slice in the next period!*/
+    /* Give it a fresh slice in the next period! */
     inf->cputime =3D 0;
 }
=20

 static void unblock_long_cons_b(struct sedf_vcpu_info* inf,s_time_t now)
 {
-    /*Conservative 2b*/
-    /*Treat the unblocking time as a start of a new period */
+    /* Conservative 2b */
+
+    /* Treat the unblocking time as a start of a new period */
     inf->deadl_abs =3D now + inf->period;
     inf->cputime =3D 0;
 }
@@ -1046,15 +1018,17 @@ static inline int get_run_type(struct vc
 }
=20

-/*Compares two domains in the relation of whether the one is allowed to
-  interrupt the others execution.
-  It returns true (!=3D0) if a switch to the other domain is good.
-  Current Priority scheme is as follows:
-   EDF > L0 (penalty based) extra-time >=20
-   L1 (utilization) extra-time > idle-domain
-  In the same class priorities are assigned as following:
-   EDF: early deadline > late deadline
-   L0 extra-time: lower score > higher score*/
+/*
+ * Compares two domains in the relation of whether the one is allowed to
+ * interrupt the others execution.
+ * It returns true (!=3D0) if a switch to the other domain is good.
+ * Current Priority scheme is as follows:
+ *  EDF > L0 (penalty based) extra-time >=20
+ *  L1 (utilization) extra-time > idle-domain
+ * In the same class priorities are assigned as following:
+ *  EDF: early deadline > late deadline
+ *  L0 extra-time: lower score > higher score
+ */
 static inline int should_switch(struct vcpu *cur,
                                 struct vcpu *other,
                                 s_time_t now)
@@ -1063,26 +1037,25 @@ static inline int should_switch(struct v
     cur_inf   =3D EDOM_INFO(cur);
     other_inf =3D EDOM_INFO(other);
 =20
-    /* Check whether we need to make an earlier scheduling decision. */
+    /* Check whether we need to make an earlier scheduling decision */
     if ( PERIOD_BEGIN(other_inf) <=20
          CPU_INFO(other->processor)->current_slice_expires )
         return 1;
=20
-    /* No timing-based switches need to be taken into account here. */
+    /* No timing-based switches need to be taken into account here */
     switch ( get_run_type(cur) )
     {
     case DOMAIN_EDF:
-        /* Do not interrupt a running EDF domain. */
+        /* Do not interrupt a running EDF domain */
         return 0;
     case DOMAIN_EXTRA_PEN:
-        /* Check whether we also want the L0 ex-q with lower score. */
+        /* Check whether we also want the L0 ex-q with lower score */
         return ((other_inf->status & EXTRA_WANT_PEN_Q) &&
                 (other_inf->score[EXTRA_PEN_Q] <=20
                  cur_inf->score[EXTRA_PEN_Q]));
     case DOMAIN_EXTRA_UTIL:
         /* Check whether we want the L0 extraq. Don't
-         * switch if both domains want L1 extraq.
-         */
+         * switch if both domains want L1 extraq. */
         return !!(other_inf->status & EXTRA_WANT_PEN_Q);
     case DOMAIN_IDLE:
         return 1;
@@ -1096,18 +1069,11 @@ static void sedf_wake(const struct sched
     s_time_t              now =3D NOW();
     struct sedf_vcpu_info* inf =3D EDOM_INFO(d);
=20
-    PRINT(3, "sedf_wake was called, domain-id %i.%i\n",d->domain->domain_i=
d,
-          d->vcpu_id);
-
     if ( unlikely(is_idle_vcpu(d)) )
         return;
   =20
     if ( unlikely(__task_on_queue(d)) )
-    {
-        PRINT(3,"\tdomain %i.%i is already in some queue\n",
-              d->domain->domain_id, d->vcpu_id);
         return;
-    }
=20
     ASSERT(!sedf_runnable(d));
     inf->status &=3D ~SEDF_ASLEEP;
@@ -1116,28 +1082,25 @@ static void sedf_wake(const struct sched
 =20
     if ( unlikely(inf->deadl_abs =3D=3D 0) )
     {
-        /*initial setup of the deadline*/
+        /* Initial setup of the deadline */
         inf->deadl_abs =3D now + inf->slice;
     }
  =20
-    PRINT(3, "waking up domain %i.%i (deadl=3D %"PRIu64" period=3D %"PRIu6=
4
-          "now=3D %"PRIu64")\n",
-          d->domain->domain_id, d->vcpu_id, inf->deadl_abs, inf->period, n=
ow);
-
 #ifdef SEDF_STATS=20
     inf->block_tot++;
 #endif
=20
     if ( unlikely(now < PERIOD_BEGIN(inf)) )
     {
-        PRINT(4,"extratime unblock\n");
-        /* unblocking in extra-time! */
+        /* Unblocking in extra-time! */
         if ( inf->status & EXTRA_WANT_PEN_Q )
         {
-            /*we have a domain that wants compensation
-              for block penalty and did just block in
-              its compensation time. Give it another
-              chance!*/
+            /*
+             * We have a domain that wants compensation
+             * for block penalty and did just block in
+             * its compensation time. Give it another
+             * chance!
+             */
             extraq_add_sort_update(d, EXTRA_PEN_Q, 0);
         }
         extraq_check_add_unblocked(d, 0);
@@ -1146,8 +1109,7 @@ static void sedf_wake(const struct sched
     { =20
         if ( now < inf->deadl_abs )
         {
-            PRINT(4,"short unblocking\n");
-            /*short blocking*/
+            /* Short blocking */
 #ifdef SEDF_STATS
             inf->short_block_tot++;
 #endif
@@ -1157,8 +1119,7 @@ static void sedf_wake(const struct sched
         }
         else
         {
-            PRINT(4,"long unblocking\n");
-            /*long unblocking*/
+            /* Long unblocking */
 #ifdef SEDF_STATS
             inf->long_block_tot++;
 #endif
@@ -1168,24 +1129,13 @@ static void sedf_wake(const struct sched
         }
     }
=20
-    PRINT(3, "woke up domain %i.%i (deadl=3D %"PRIu64" period=3D %"PRIu64
-          "now=3D %"PRIu64")\n",
-          d->domain->domain_id, d->vcpu_id, inf->deadl_abs,
-          inf->period, now);
-
     if ( PERIOD_BEGIN(inf) > now )
-    {
         __add_to_waitqueue_sort(d);
-        PRINT(3,"added to waitq\n");
-    }
     else
-    {
         __add_to_runqueue_sort(d);
-        PRINT(3,"added to runq\n");
-    }
 =20
 #ifdef SEDF_STATS
-    /*do some statistics here...*/
+    /* Do some statistics here... */
     if ( inf->block_abs !=3D 0 )
     {
         inf->block_time_tot +=3D now - inf->block_abs;
@@ -1194,12 +1144,14 @@ static void sedf_wake(const struct sched
     }
 #endif
=20
-    /*sanity check: make sure each extra-aware domain IS on the util-q!*/
+    /* Sanity check: make sure each extra-aware domain IS on the util-q! *=
/
     ASSERT(IMPLY(inf->status & EXTRA_AWARE, extraq_on(d, EXTRA_UTIL_Q)));
     ASSERT(__task_on_queue(d));
-    /*check whether the awakened task needs to invoke the do_schedule
-      routine. Try to avoid unnecessary runs but:
-      Save approximation: Always switch to scheduler!*/
+    /*
+     * Check whether the awakened task needs to invoke the do_schedule
+     * routine. Try to avoid unnecessary runs but:
+     * Save approximation: Always switch to scheduler!
+     */
     ASSERT(d->processor >=3D 0);
     ASSERT(d->processor < nr_cpu_ids);
     ASSERT(per_cpu(schedule_data, d->processor).curr);
@@ -1244,7 +1196,7 @@ static void sedf_dump_domain(struct vcpu
 }
=20

-/* dumps all domains on the specified cpu */
+/* Dumps all domains on the specified cpu */
 static void sedf_dump_cpu_state(const struct scheduler *ops, int i)
 {
     struct list_head      *list, *queue, *tmp;
@@ -1319,7 +1271,7 @@ static void sedf_dump_cpu_state(const st
 }
=20

-/* Adjusts periods and slices of the domains accordingly to their weights.=
 */
+/* Adjusts periods and slices of the domains accordingly to their weights =
*/
 static int sedf_adjust_weights(struct cpupool *c, struct xen_domctl_schedu=
ler_op *cmd)
 {
     struct vcpu *p;
@@ -1335,7 +1287,7 @@ static int sedf_adjust_weights(struct cp
         return -ENOMEM;
     }
=20
-    /* Sum across all weights. */
+    /* Sum across all weights */
     rcu_read_lock(&domlist_read_lock);
     for_each_domain_in_cpupool( d, c )
     {
@@ -1350,11 +1302,14 @@ static int sedf_adjust_weights(struct cp
             }
             else
             {
-                /*don't modify domains who don't have a weight, but sum
-                  up the time they need, projected to a WEIGHT_PERIOD,
-                  so that this time is not given to the weight-driven
-                  domains*/
-                /*check for overflows*/
+                /*
+                 * Don't modify domains who don't have a weight, but sum
+                 * up the time they need, projected to a WEIGHT_PERIOD,
+                 * so that this time is not given to the weight-driven
+                 *  domains
+                 */
+
+                /* Check for overflows */
                 ASSERT((WEIGHT_PERIOD < ULONG_MAX)=20
                        && (EDOM_INFO(p)->slice_orig < ULONG_MAX));
                 sumt[cpu] +=3D=20
@@ -1365,7 +1320,7 @@ static int sedf_adjust_weights(struct cp
     }
     rcu_read_unlock(&domlist_read_lock);
=20
-    /* Adjust all slices (and periods) to the new weight. */
+    /* Adjust all slices (and periods) to the new weight */
     rcu_read_lock(&domlist_read_lock);
     for_each_domain_in_cpupool( d, c )
     {
@@ -1393,20 +1348,15 @@ static int sedf_adjust_weights(struct cp
 }
=20

-/* set or fetch domain scheduling parameters */
+/* Set or fetch domain scheduling parameters */
 static int sedf_adjust(const struct scheduler *ops, struct domain *p, stru=
ct xen_domctl_scheduler_op *op)
 {
     struct vcpu *v;
     int rc;
=20
-    PRINT(2,"sedf_adjust was called, domain-id %i new period %"PRIu64" "
-          "new slice %"PRIu64"\nlatency %"PRIu64" extra:%s\n",
-          p->domain_id, op->u.sedf.period, op->u.sedf.slice,
-          op->u.sedf.latency, (op->u.sedf.extratime)?"yes":"no");
-
     if ( op->cmd =3D=3D XEN_DOMCTL_SCHEDOP_putinfo )
     {
-        /* Check for sane parameters. */
+        /* Check for sane parameters */
         if ( !op->u.sedf.period && !op->u.sedf.weight )
             return -EINVAL;
         if ( op->u.sedf.weight )
@@ -1414,7 +1364,7 @@ static int sedf_adjust(const struct sche
             if ( (op->u.sedf.extratime & EXTRA_AWARE) &&
                  (!op->u.sedf.period) )
             {
-                /* Weight-driven domains with extratime only. */
+                /* Weight-driven domains with extratime only */
                 for_each_vcpu ( p, v )
                 {
                     EDOM_INFO(v)->extraweight =3D op->u.sedf.weight;
@@ -1425,7 +1375,7 @@ static int sedf_adjust(const struct sche
             }
             else
             {
-                /* Weight-driven domains with real-time execution. */
+                /* Weight-driven domains with real-time execution */
                 for_each_vcpu ( p, v )
                     EDOM_INFO(v)->weight =3D op->u.sedf.weight;
             }
@@ -1477,7 +1427,6 @@ static int sedf_adjust(const struct sche
         op->u.sedf.weight    =3D EDOM_INFO(p->vcpu[0])->weight;
     }
=20
-    PRINT(2,"sedf_adjust_finished\n");
     return 0;
 }
=20

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-------------------------------------------------------------------
Dario Faggioli, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
PhD Candidate, ReTiS Lab, Scuola Superiore Sant'Anna, Pisa (Italy)



--=-DM3xwBkUsBWsFUckworM
Content-Disposition: attachment; filename="sedf-debug-cleanup.patch"
Content-Type: text/x-patch; name="sedf-debug-cleanup.patch"; charset="UTF-8"
Content-Transfer-Encoding: base64

IyBIRyBjaGFuZ2VzZXQgcGF0Y2gNCiMgUGFyZW50IDUxMDQ1YTVlYzZiY2YxZTk3NDU4ZTRlNzQ3
ZDUyYmNjYjA3MzQ4YTQNCnNlZGY6IHJlbW92ZSB1c2VsZXNzIHRyYWNpbmcgcHJpbnRrIGFuZCBo
YXJtb25pemUgY29tbWVudHMgc3R5bGUuDQoNCnNjaGVkX3NlZGYuYyB1c2VkIG8gaGF2ZSBpdHMg
b3duIG1lY2hhbmlzbSBmb3IgcHJvZHVjaW5nIHRyYWNpbmctYWxpa2UNCmtpbmQgb2YgaW5mb3Jt
YXRpb24gKGRvbWFpbiBibG9jaywgd2FrZXVwLCBldGMuKS4gTm93YWRheXMsIHdpdGggYW4gZXZl
bg0Kbm90IHNvIGhpZ2ggbnVtYmVyIG9mIHBDUFVzL3ZDUFVzLCBqdXN0IHRyeWluZyB0byBlbmFi
bGUgdGhpcyBtYWtlcw0KdGhlIHNlcmlhbCBjb25zb2xlIGNvbXBsZXRlbHkgdW51c2FibGUsIHBy
b2R1Y2VzIHRvbnMgb2YgdmVyeSBoYXJkIHRvDQpwYXJzZSBhbmQgaW50ZXJwcmVldCBsb2dnaW5n
IGFuZCBjYW4gZWFzaWx5IGxpdmVsb2NrIERvbTAuIE1vcmVvdmVyLA0KcHJldHR5IG11Y2ggdGhl
IHNhbWUgcmVzdWx0IHRoaXMgaXMgc3RydWdnbGluZyB0byBnZXQgdG8sIGlzIGJldHRlcg0KYWNo
aWV2ZWQgYnkgZW5hYmxpbmcgdGhlIHNjaGVkdWxlci1yZWxhdGVkIHRyYWNpbmcgZXZlbnRzLCBh
cw0KaXQgaXMgZm9yIHRoZSBvdGhlciBzY2hlZHVsZXJzIChzYXksIGNyZWRpdCBvciBjcmVkaXQy
KS4NCg0KRm9yIGFsbCB0aGVzZSByZWFzb25zLCB0aGlzIHJlbW92ZXMgdGhhdCBtYWNoaW5lcnkg
Y29tcGxldGVseS4gV2hpbGUgYXQNCml0LCBjaGVjayBpbiBzb21lIGNvc21ldGljcyB0aGF0IGhh
cm1vbml6ZSB0aGUgY29tbWVudHMgd2l0aGltIHRoZW1zZWxmDQphbmQgd2l0aCB0aGUgcmVzdCBv
ZiB0aGUgY29kZSBiYXNlLg0KDQpTaWduZWQtb2ZmLWJ5OiBEYXJpbyBGYWdnaW9saSA8ZGFyaW8u
ZmFnZ2lvbGlAY2l0cml4LmNvbT4NCg0KZGlmZiAtciA1MTA0NWE1ZWM2YmMgeGVuL2NvbW1vbi9z
Y2hlZF9zZWRmLmMNCi0tLSBhL3hlbi9jb21tb24vc2NoZWRfc2VkZi5jCVdlZCBEZWMgMjEgMTQ6
NDk6MDEgMjAxMSArMDAwMA0KKysrIGIveGVuL2NvbW1vbi9zY2hlZF9zZWRmLmMJV2VkIERlYyAy
MSAxNToxMjowNyAyMDExICswMDAwDQpAQCAtMTMsMTQgKzEzLDYgQEANCiAjaW5jbHVkZSA8eGVu
L3RpbWUuaD4NCiAjaW5jbHVkZSA8eGVuL2Vycm5vLmg+DQogDQotLyp2ZXJib3NpdHkgc2V0dGlu
Z3MqLw0KLSNkZWZpbmUgU0VERkxFVkVMIDANCi0jZGVmaW5lIFBSSU5UKF9mLCBfYS4uLikgICAg
ICAgICAgICAgICAgICAgICAgICBcDQotICAgIGRvIHsgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgXA0KLSAgICAgICAgaWYgKCAoX2YpIDw9IFNFREZMRVZFTCApICAgICAg
ICAgICAgICAgIFwNCi0gICAgICAgICAgICBwcmludGsoX2EgKTsgICAgICAgICAgICAgICAgICAg
ICAgICBcDQotICAgIH0gd2hpbGUgKCAwICkNCi0NCiAjZGVmaW5lIFNFREZfQ1BVT05MSU5FKF9w
b29sKSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFwNCiAgICAg
KCgoX3Bvb2wpID09IE5VTEwpID8gJmNwdXBvb2xfZnJlZV9jcHVzIDogKF9wb29sKS0+Y3B1X3Zh
bGlkKQ0KIA0KQEAgLTY2LDM0ICs1OCwzNSBAQCBzdHJ1Y3Qgc2VkZl92Y3B1X2luZm8gew0KICAg
ICBzdHJ1Y3QgbGlzdF9oZWFkIGxpc3Q7DQogICAgIHN0cnVjdCBsaXN0X2hlYWQgZXh0cmFsaXN0
WzJdOw0KICANCi0gICAgLypQYXJhbWV0ZXJzIGZvciBFREYqLw0KLSAgICBzX3RpbWVfdCAgcGVy
aW9kOyAgLyo9KHJlbGF0aXZlIGRlYWRsaW5lKSovDQotICAgIHNfdGltZV90ICBzbGljZTsgIC8q
PXdvcnN0IGNhc2UgZXhlY3V0aW9uIHRpbWUqLw0KKyAgICAvKiBQYXJhbWV0ZXJzIGZvciBFREYg
Ki8NCisgICAgc190aW1lX3QgIHBlcmlvZDsgIC8qID0ocmVsYXRpdmUgZGVhZGxpbmUpICovDQor
ICAgIHNfdGltZV90ICBzbGljZTsgICAvKiA9d29yc3QgY2FzZSBleGVjdXRpb24gdGltZSAqLw0K
ICANCi0gICAgLypBZHZhY2VkIFBhcmFtZXRlcnMqLw0KLSAgICAvKkxhdGVuY3kgU2NhbGluZyov
DQorICAgIC8qIEFkdmFjZWQgUGFyYW1ldGVycyAqLw0KKw0KKyAgICAvKiBMYXRlbmN5IFNjYWxp
bmcgKi8NCiAgICAgc190aW1lX3QgIHBlcmlvZF9vcmlnOw0KICAgICBzX3RpbWVfdCAgc2xpY2Vf
b3JpZzsNCiAgICAgc190aW1lX3QgIGxhdGVuY3k7DQogIA0KLSAgICAvKnN0YXR1cyBvZiBkb21h
aW4qLw0KKyAgICAvKiBTdGF0dXMgb2YgZG9tYWluICovDQogICAgIGludCAgICAgICBzdGF0dXM7
DQotICAgIC8qd2VpZ2h0cyBmb3IgIlNjaGVkdWxpbmcgZm9yIGJlZ2lubmVycy8gbGF6eS8gZXRj
LiIgOykqLw0KKyAgICAvKiBXZWlnaHRzIGZvciAiU2NoZWR1bGluZyBmb3IgYmVnaW5uZXJzLyBs
YXp5LyBldGMuIiA7KSAqLw0KICAgICBzaG9ydCAgICAgd2VpZ2h0Ow0KICAgICBzaG9ydCAgICAg
ZXh0cmF3ZWlnaHQ7DQotICAgIC8qQm9va2tlZXBpbmcqLw0KKyAgICAvKiBCb29ra2VlcGluZyAq
Lw0KICAgICBzX3RpbWVfdCAgZGVhZGxfYWJzOw0KICAgICBzX3RpbWVfdCAgc2NoZWRfc3RhcnRf
YWJzOw0KICAgICBzX3RpbWVfdCAgY3B1dGltZTsNCi0gICAgLyogdGltZXMgdGhlIGRvbWFpbiB1
bi0vYmxvY2tlZCAqLw0KKyAgICAvKiBUaW1lcyB0aGUgZG9tYWluIHVuLS9ibG9ja2VkICovDQog
ICAgIHNfdGltZV90ICBibG9ja19hYnM7DQogICAgIHNfdGltZV90ICB1bmJsb2NrX2FiczsNCiAg
DQotICAgIC8qc2NvcmVzIGZvciB7dXRpbCwgYmxvY2sgcGVuYWx0eX0td2VpZ2h0ZWQgZXh0cmF0
aW1lIGRpc3RyaWJ1dGlvbiovDQorICAgIC8qIFNjb3JlcyBmb3Ige3V0aWwsIGJsb2NrIHBlbmFs
dHl9LXdlaWdodGVkIGV4dHJhdGltZSBkaXN0cmlidXRpb24gKi8NCiAgICAgaW50ICAgc2NvcmVb
Ml07DQogICAgIHNfdGltZV90ICBzaG9ydF9ibG9ja19sb3N0X3RvdDsNCiAgDQotICAgIC8qU3Rh
dGlzdGljcyovDQorICAgIC8qIFN0YXRpc3RpY3MgKi8NCiAgICAgc190aW1lX3QgIGV4dHJhX3Rp
bWVfdG90Ow0KIA0KICNpZmRlZiBTRURGX1NUQVRTDQpAQCAtMTU4LDE4ICsxNTEsMTcgQEAgc3Rh
dGljIGlubGluZSB2b2lkIGV4dHJhcV9kZWwoc3RydWN0IHZjcA0KIHsNCiAgICAgc3RydWN0IGxp
c3RfaGVhZCAqbGlzdCA9IEVYVFJBTElTVChkLGkpOw0KICAgICBBU1NFUlQoZXh0cmFxX29uKGQs
aSkpOw0KLSAgICBQUklOVCgzLCAiUmVtb3ZpbmcgZG9tYWluICVpLiVpIGZyb20gTCVpIGV4dHJh
cVxuIiwNCi0gICAgICAgICAgZC0+ZG9tYWluLT5kb21haW5faWQsIGQtPnZjcHVfaWQsIGkpOw0K
ICAgICBsaXN0X2RlbChsaXN0KTsNCiAgICAgbGlzdC0+bmV4dCA9IE5VTEw7DQogICAgIEFTU0VS
VCghZXh0cmFxX29uKGQsIGkpKTsNCiB9DQogDQotLyogYWRkcyBhIGRvbWFpbiB0byB0aGUgcXVl
dWUgb2YgcHJvY2Vzc2VzIHdoaWNoIGFyZSBhd2FyZSBvZiBleHRyYSB0aW1lLiBMaXN0DQotICAg
aXMgc29ydGVkIGJ5IHNjb3JlLCB3aGVyZSBhIGxvd2VyIHNjb3JlIG1lYW5zIGhpZ2hlciBwcmlv
cml0eSBmb3IgYW4gZXh0cmENCi0gICBzbGljZS4gSXQgYWxzbyB1cGRhdGVzIHRoZSBzY29yZSwg
Ynkgc2ltcGx5IHN1YnRyYWN0aW5nIGEgZml4ZWQgdmFsdWUgZnJvbQ0KLSAgIGVhY2ggZW50cnks
IGluIG9yZGVyIHRvIGF2b2lkIG92ZXJmbG93LiBUaGUgYWxnb3JpdGhtIHdvcmtzIGJ5IHNpbXBs
eQ0KLSAgIGNoYXJnaW5nIGVhY2ggZG9tYWluIHRoYXQgcmVjaWV2ZWQgZXh0cmF0aW1lIHdpdGgg
YW4gaW52ZXJzZSBvZiBpdHMgd2VpZ2h0Lg0KKy8qDQorICogQWRkcyBhIGRvbWFpbiB0byB0aGUg
cXVldWUgb2YgcHJvY2Vzc2VzIHdoaWNoIGFyZSBhd2FyZSBvZiBleHRyYSB0aW1lLiBMaXN0DQor
ICogaXMgc29ydGVkIGJ5IHNjb3JlLCB3aGVyZSBhIGxvd2VyIHNjb3JlIG1lYW5zIGhpZ2hlciBw
cmlvcml0eSBmb3IgYW4gZXh0cmENCisgKiBzbGljZS4gSXQgYWxzbyB1cGRhdGVzIHRoZSBzY29y
ZSwgYnkgc2ltcGx5IHN1YnRyYWN0aW5nIGEgZml4ZWQgdmFsdWUgZnJvbQ0KKyAqIGVhY2ggZW50
cnksIGluIG9yZGVyIHRvIGF2b2lkIG92ZXJmbG93LiBUaGUgYWxnb3JpdGhtIHdvcmtzIGJ5IHNp
bXBseQ0KKyAqIGNoYXJnaW5nIGVhY2ggZG9tYWluIHRoYXQgcmVjaWV2ZWQgZXh0cmF0aW1lIHdp
dGggYW4gaW52ZXJzZSBvZiBpdHMgd2VpZ2h0Lg0KICAqLyANCiBzdGF0aWMgaW5saW5lIHZvaWQg
ZXh0cmFxX2FkZF9zb3J0X3VwZGF0ZShzdHJ1Y3QgdmNwdSAqZCwgaW50IGksIGludCBzdWIpDQog
ew0KQEAgLTE3OCwxMSArMTcwLDYgQEAgc3RhdGljIGlubGluZSB2b2lkIGV4dHJhcV9hZGRfc29y
dF91cGRhdA0KICANCiAgICAgQVNTRVJUKCFleHRyYXFfb24oZCxpKSk7DQogDQotICAgIFBSSU5U
KDMsICJBZGRpbmcgZG9tYWluICVpLiVpIChzY29yZT0gJWksIHNob3J0X3Blbj0gJSJQUklpNjQi
KSINCi0gICAgICAgICAgIiB0byBMJWkgZXh0cmFxXG4iLA0KLSAgICAgICAgICBkLT5kb21haW4t
PmRvbWFpbl9pZCwgZC0+dmNwdV9pZCwgRURPTV9JTkZPKGQpLT5zY29yZVtpXSwNCi0gICAgICAg
ICAgRURPTV9JTkZPKGQpLT5zaG9ydF9ibG9ja19sb3N0X3RvdCwgaSk7DQotDQogICAgIC8qDQog
ICAgICAqIEl0ZXJhdGUgdGhyb3VnaCBhbGwgZWxlbWVudHMgdG8gZmluZCBvdXIgImhvbGUiIGFu
ZCBvbiBvdXIgd2F5DQogICAgICAqIHVwZGF0ZSBhbGwgdGhlIG90aGVyIHNjb3Jlcy4NCkBAIC0x
OTMsMjUgKzE4MCwxOCBAQCBzdGF0aWMgaW5saW5lIHZvaWQgZXh0cmFxX2FkZF9zb3J0X3VwZGF0
DQogICAgICAgICBjdXJpbmYtPnNjb3JlW2ldIC09IHN1YjsNCiAgICAgICAgIGlmICggRURPTV9J
TkZPKGQpLT5zY29yZVtpXSA8IGN1cmluZi0+c2NvcmVbaV0gKQ0KICAgICAgICAgICAgIGJyZWFr
Ow0KLSAgICAgICAgUFJJTlQoNCwiXHRiZWhpbmQgZG9tYWluICVpLiVpIChzY29yZT0gJWkpXG4i
LA0KLSAgICAgICAgICAgICAgY3VyaW5mLT52Y3B1LT5kb21haW4tPmRvbWFpbl9pZCwNCi0gICAg
ICAgICAgICAgIGN1cmluZi0+dmNwdS0+dmNwdV9pZCwgY3VyaW5mLT5zY29yZVtpXSk7DQogICAg
IH0NCiANCi0gICAgLyogY3VyIG5vdyBjb250YWlucyB0aGUgZWxlbWVudCwgYmVmb3JlIHdoaWNo
IHdlJ2xsIGVucXVldWUuICovDQotICAgIFBSSU5UKDMsICJcdGxpc3RfYWRkIHRvICVwXG4iLCBj
dXItPnByZXYpOw0KKyAgICAvKiBjdXIgbm93IGNvbnRhaW5zIHRoZSBlbGVtZW50LCBiZWZvcmUg
d2hpY2ggd2UnbGwgZW5xdWV1ZSAqLw0KICAgICBsaXN0X2FkZChFWFRSQUxJU1QoZCxpKSxjdXIt
PnByZXYpOw0KICANCi0gICAgLyogQ29udGludWUgdXBkYXRpbmcgdGhlIGV4dHJhcS4gKi8NCisg
ICAgLyogQ29udGludWUgdXBkYXRpbmcgdGhlIGV4dHJhcSAqLw0KICAgICBpZiAoIChjdXIgIT0g
RVhUUkFRKGQtPnByb2Nlc3NvcixpKSkgJiYgc3ViICkNCiAgICAgew0KICAgICAgICAgZm9yICgg
Y3VyID0gY3VyLT5uZXh0OyBjdXIgIT0gRVhUUkFRKGQtPnByb2Nlc3NvcixpKTsgY3VyID0gY3Vy
LT5uZXh0ICkNCiAgICAgICAgIHsNCiAgICAgICAgICAgICBjdXJpbmYgPSBsaXN0X2VudHJ5KGN1
cixzdHJ1Y3Qgc2VkZl92Y3B1X2luZm8sIGV4dHJhbGlzdFtpXSk7DQogICAgICAgICAgICAgY3Vy
aW5mLT5zY29yZVtpXSAtPSBzdWI7DQotICAgICAgICAgICAgUFJJTlQoNCwgIlx0dXBkYXRpbmcg
ZG9tYWluICVpLiVpIChzY29yZT0gJXUpXG4iLA0KLSAgICAgICAgICAgICAgICAgIGN1cmluZi0+
dmNwdS0+ZG9tYWluLT5kb21haW5faWQsIA0KLSAgICAgICAgICAgICAgICAgIGN1cmluZi0+dmNw
dS0+dmNwdV9pZCwgY3VyaW5mLT5zY29yZVtpXSk7DQogICAgICAgICB9DQogICAgIH0NCiANCkBA
IC0yMjEsMjkgKzIwMSwxNCBAQCBzdGF0aWMgaW5saW5lIHZvaWQgZXh0cmFxX2NoZWNrKHN0cnVj
dCB2DQogew0KICAgICBpZiAoIGV4dHJhcV9vbihkLCBFWFRSQV9VVElMX1EpICkNCiAgICAgew0K
LSAgICAgICAgUFJJTlQoMiwiRG9tICVpLiVpIGlzIG9uIEwxIGV4dHJhUVxuIiwNCi0gICAgICAg
ICAgICAgIGQtPmRvbWFpbi0+ZG9tYWluX2lkLCBkLT52Y3B1X2lkKTsNCi0NCiAgICAgICAgIGlm
ICggIShFRE9NX0lORk8oZCktPnN0YXR1cyAmIEVYVFJBX0FXQVJFKSAmJg0KICAgICAgICAgICAg
ICAhZXh0cmFfcnVucyhFRE9NX0lORk8oZCkpICkNCi0gICAgICAgIHsNCiAgICAgICAgICAgICBl
eHRyYXFfZGVsKGQsIEVYVFJBX1VUSUxfUSk7DQotICAgICAgICAgICAgUFJJTlQoMiwiUmVtb3Zl
ZCBkb20gJWkuJWkgZnJvbSBMMSBleHRyYVFcbiIsDQotICAgICAgICAgICAgICAgICAgZC0+ZG9t
YWluLT5kb21haW5faWQsIGQtPnZjcHVfaWQpOw0KLSAgICAgICAgfQ0KICAgICB9DQogICAgIGVs
c2UNCiAgICAgew0KLSAgICAgICAgUFJJTlQoMiwgIkRvbSAlaS4laSBpcyBOT1Qgb24gTDEgZXh0
cmFRXG4iLA0KLSAgICAgICAgICAgICAgZC0+ZG9tYWluLT5kb21haW5faWQsDQotICAgICAgICAg
ICAgICBkLT52Y3B1X2lkKTsNCi0NCiAgICAgICAgIGlmICggKEVET01fSU5GTyhkKS0+c3RhdHVz
ICYgRVhUUkFfQVdBUkUpICYmIHNlZGZfcnVubmFibGUoZCkgKQ0KLSAgICAgICAgew0KICAgICAg
ICAgICAgIGV4dHJhcV9hZGRfc29ydF91cGRhdGUoZCwgRVhUUkFfVVRJTF9RLCAwKTsNCi0gICAg
ICAgICAgICBQUklOVCgyLCJBZGRlZCBkb20gJWkuJWkgdG8gTDEgZXh0cmFRXG4iLA0KLSAgICAg
ICAgICAgICAgICAgIGQtPmRvbWFpbi0+ZG9tYWluX2lkLCBkLT52Y3B1X2lkKTsNCi0gICAgICAg
IH0NCiAgICAgfQ0KIH0NCiANCkBAIC0yNTIsNyArMjE3LDcgQEAgc3RhdGljIGlubGluZSB2b2lk
IGV4dHJhcV9jaGVja19hZGRfdW5ibA0KICAgICBzdHJ1Y3Qgc2VkZl92Y3B1X2luZm8gKmluZiA9
IEVET01fSU5GTyhkKTsNCiANCiAgICAgaWYgKCBpbmYtPnN0YXR1cyAmIEVYVFJBX0FXQVJFICkN
Ci0gICAgICAgIC8qIFB1dCBvbiB0aGUgd2VpZ2h0ZWQgZXh0cmFxIHdpdGhvdXQgdXBkYXRpbmcg
YW55IHNjb3Jlcy4gKi8NCisgICAgICAgIC8qIFB1dCBvbiB0aGUgd2VpZ2h0ZWQgZXh0cmFxIHdp
dGhvdXQgdXBkYXRpbmcgYW55IHNjb3JlcyAqLw0KICAgICAgICAgZXh0cmFxX2FkZF9zb3J0X3Vw
ZGF0ZShkLCBFWFRSQV9VVElMX1EsIDApOw0KIH0NCiANCkBAIC0yNjUsOCArMjMwLDYgQEAgc3Rh
dGljIGlubGluZSB2b2lkIF9fZGVsX2Zyb21fcXVldWUoc3RydQ0KIHsNCiAgICAgc3RydWN0IGxp
c3RfaGVhZCAqbGlzdCA9IExJU1QoZCk7DQogICAgIEFTU0VSVChfX3Rhc2tfb25fcXVldWUoZCkp
Ow0KLSAgICBQUklOVCgzLCJSZW1vdmluZyBkb21haW4gJWkuJWkgKGJvcD0gJSJQUkl1NjQiKSBm
cm9tIHJ1bnEvd2FpdHFcbiIsDQotICAgICAgICAgIGQtPmRvbWFpbi0+ZG9tYWluX2lkLCBkLT52
Y3B1X2lkLCBQRVJJT0RfQkVHSU4oRURPTV9JTkZPKGQpKSk7DQogICAgIGxpc3RfZGVsKGxpc3Qp
Ow0KICAgICBsaXN0LT5uZXh0ID0gTlVMTDsNCiAgICAgQVNTRVJUKCFfX3Rhc2tfb25fcXVldWUo
ZCkpOw0KQEAgLTI3OSwxMyArMjQyLDEyIEBAIHN0YXRpYyBpbmxpbmUgdm9pZCBsaXN0X2luc2Vy
dF9zb3J0KA0KIHsNCiAgICAgc3RydWN0IGxpc3RfaGVhZCAgICAgKmN1cjsNCiANCi0gICAgLyog
SXRlcmF0ZSB0aHJvdWdoIGFsbCBlbGVtZW50cyB0byBmaW5kIG91ciAiaG9sZSIuICovDQorICAg
IC8qIEl0ZXJhdGUgdGhyb3VnaCBhbGwgZWxlbWVudHMgdG8gZmluZCBvdXIgImhvbGUiICovDQog
ICAgIGxpc3RfZm9yX2VhY2goIGN1ciwgbGlzdCApDQogICAgICAgICBpZiAoIGNvbXAoZWxlbWVu
dCwgY3VyKSA8IDAgKQ0KICAgICAgICAgICAgIGJyZWFrOw0KIA0KLSAgICAvKiBjdXIgbm93IGNv
bnRhaW5zIHRoZSBlbGVtZW50LCBiZWZvcmUgd2hpY2ggd2UnbGwgZW5xdWV1ZS4gKi8NCi0gICAg
UFJJTlQoMywiXHRsaXN0X2FkZCB0byAlcFxuIixjdXItPnByZXYpOw0KKyAgICAvKiBjdXIgbm93
IGNvbnRhaW5zIHRoZSBlbGVtZW50LCBiZWZvcmUgd2hpY2ggd2UnbGwgZW5xdWV1ZSAqLw0KICAg
ICBsaXN0X2FkZChlbGVtZW50LCBjdXItPnByZXYpOw0KIH0NCiANCkBAIC0zMDMsMzAgKzI2NSwy
OCBAQCBzdGF0aWMgaW50IG5hbWUjI19jb21wKHN0cnVjdCBsaXN0X2hlYWQqDQogICAgICAgICBy
ZXR1cm4gMTsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgXA0KIH0NCiANCi0vKiBhZGRzIGEgZG9tYWluIHRvIHRoZSBxdWV1ZSBvZiBwcm9jZXNz
ZXMgd2hpY2ggd2FpdCBmb3IgdGhlIGJlZ2lubmluZyBvZiB0aGUNCi0gICBuZXh0IHBlcmlvZDsg
dGhpcyBsaXN0IGlzIHRoZXJlZm9yZSBzb3J0ZXQgYnkgdGhpcyB0aW1lLCB3aGljaCBpcyBzaW1w
bHkNCi0gICBhYnNvbC4gZGVhZGxpbmUgLSBwZXJpb2QNCisvKg0KKyAqIEFkZHMgYSBkb21haW4g
dG8gdGhlIHF1ZXVlIG9mIHByb2Nlc3NlcyB3aGljaCB3YWl0IGZvciB0aGUgYmVnaW5uaW5nIG9m
IHRoZQ0KKyAqIG5leHQgcGVyaW9kOyB0aGlzIGxpc3QgaXMgdGhlcmVmb3JlIHNvcnRldCBieSB0
aGlzIHRpbWUsIHdoaWNoIGlzIHNpbXBseQ0KKyAqIGFic29sLiBkZWFkbGluZSAtIHBlcmlvZC4N
CiAgKi8gDQogRE9NQUlOX0NPTVBBUkVSKHdhaXRxLCBsaXN0LCBQRVJJT0RfQkVHSU4oZDEpLCBQ
RVJJT0RfQkVHSU4oZDIpKTsNCiBzdGF0aWMgaW5saW5lIHZvaWQgX19hZGRfdG9fd2FpdHF1ZXVl
X3NvcnQoc3RydWN0IHZjcHUgKnYpDQogew0KICAgICBBU1NFUlQoIV9fdGFza19vbl9xdWV1ZSh2
KSk7DQotICAgIFBSSU5UKDMsIkFkZGluZyBkb21haW4gJWkuJWkgKGJvcD0gJSJQUkl1NjQiKSB0
byB3YWl0cVxuIiwNCi0gICAgICAgICAgdi0+ZG9tYWluLT5kb21haW5faWQsIHYtPnZjcHVfaWQs
IFBFUklPRF9CRUdJTihFRE9NX0lORk8odikpKTsNCiAgICAgbGlzdF9pbnNlcnRfc29ydChXQUlU
USh2LT5wcm9jZXNzb3IpLCBMSVNUKHYpLCB3YWl0cV9jb21wKTsNCiAgICAgQVNTRVJUKF9fdGFz
a19vbl9xdWV1ZSh2KSk7DQogfQ0KIA0KLS8qIGFkZHMgYSBkb21haW4gdG8gdGhlIHF1ZXVlIG9m
IHByb2Nlc3NlcyB3aGljaCBoYXZlIHN0YXJ0ZWQgdGhlaXIgY3VycmVudA0KLSAgIHBlcmlvZCBh
bmQgYXJlIHJ1bm5hYmxlIChpLmUuIG5vdCBibG9ja2VkLCBkaWVpbmcsLi4uKS4gVGhlIGZpcnN0
IGVsZW1lbnQNCi0gICBvbiB0aGlzIGxpc3QgaXMgcnVubmluZyBvbiB0aGUgcHJvY2Vzc29yLCBp
ZiB0aGUgbGlzdCBpcyBlbXB0eSB0aGUgaWRsZQ0KLSAgIHRhc2sgd2lsbCBydW4uIEFzIHdlIGFy
ZSBpbXBsZW1lbnRpbmcgRURGLCB0aGlzIGxpc3QgaXMgc29ydGVkIGJ5IGRlYWRsaW5lcy4NCisv
Kg0KKyAqIEFkZHMgYSBkb21haW4gdG8gdGhlIHF1ZXVlIG9mIHByb2Nlc3NlcyB3aGljaCBoYXZl
IHN0YXJ0ZWQgdGhlaXIgY3VycmVudA0KKyAqIHBlcmlvZCBhbmQgYXJlIHJ1bm5hYmxlIChpLmUu
IG5vdCBibG9ja2VkLCBkaWVpbmcsLi4uKS4gVGhlIGZpcnN0IGVsZW1lbnQNCisgKiBvbiB0aGlz
IGxpc3QgaXMgcnVubmluZyBvbiB0aGUgcHJvY2Vzc29yLCBpZiB0aGUgbGlzdCBpcyBlbXB0eSB0
aGUgaWRsZQ0KKyAqIHRhc2sgd2lsbCBydW4uIEFzIHdlIGFyZSBpbXBsZW1lbnRpbmcgRURGLCB0
aGlzIGxpc3QgaXMgc29ydGVkIGJ5IGRlYWRsaW5lcy4NCiAgKi8gDQogRE9NQUlOX0NPTVBBUkVS
KHJ1bnEsIGxpc3QsIGQxLT5kZWFkbF9hYnMsIGQyLT5kZWFkbF9hYnMpOw0KIHN0YXRpYyBpbmxp
bmUgdm9pZCBfX2FkZF90b19ydW5xdWV1ZV9zb3J0KHN0cnVjdCB2Y3B1ICp2KQ0KIHsNCi0gICAg
UFJJTlQoMywiQWRkaW5nIGRvbWFpbiAlaS4laSAoZGVhZGw9ICUiUFJJdTY0IikgdG8gcnVucVxu
IiwNCi0gICAgICAgICAgdi0+ZG9tYWluLT5kb21haW5faWQsIHYtPnZjcHVfaWQsIEVET01fSU5G
Tyh2KS0+ZGVhZGxfYWJzKTsNCiAgICAgbGlzdF9pbnNlcnRfc29ydChSVU5RKHYtPnByb2Nlc3Nv
ciksIExJU1QodiksIHJ1bnFfY29tcCk7DQogfQ0KIA0KQEAgLTQ1MywxMCArNDEzLDEwIEBAIHN0
YXRpYyB2b2lkIGRlc2NoZWRfZWRmX2RvbShzX3RpbWVfdCBub3cNCiB7DQogICAgIHN0cnVjdCBz
ZWRmX3ZjcHVfaW5mbyogaW5mID0gRURPTV9JTkZPKGQpOw0KIA0KLSAgICAvKiBDdXJyZW50IGRv
bWFpbiBpcyBydW5uaW5nIGluIHJlYWwgdGltZSBtb2RlLiAqLw0KKyAgICAvKiBDdXJyZW50IGRv
bWFpbiBpcyBydW5uaW5nIGluIHJlYWwgdGltZSBtb2RlICovDQogICAgIEFTU0VSVChfX3Rhc2tf
b25fcXVldWUoZCkpOw0KIA0KLSAgICAvKiBVcGRhdGUgdGhlIGRvbWFpbidzIGNwdXRpbWUuICov
DQorICAgIC8qIFVwZGF0ZSB0aGUgZG9tYWluJ3MgY3B1dGltZSAqLw0KICAgICBpbmYtPmNwdXRp
bWUgKz0gbm93IC0gaW5mLT5zY2hlZF9zdGFydF9hYnM7DQogDQogICAgIC8qDQpAQCAtNDY3LDcg
KzQyNyw3IEBAIHN0YXRpYyB2b2lkIGRlc2NoZWRfZWRmX2RvbShzX3RpbWVfdCBub3cNCiAgICAg
ICAgIHJldHVybjsNCiAgIA0KICAgICBfX2RlbF9mcm9tX3F1ZXVlKGQpOw0KLSAgDQorDQogICAg
IC8qDQogICAgICAqIE1hbmFnZSBib29ra2VlcGluZyAoaS5lLiBjYWxjdWxhdGUgbmV4dCBkZWFk
bGluZSwgbWVtb3Jpc2UNCiAgICAgICogb3ZlcnJ1bi10aW1lIG9mIHNsaWNlKSBvZiBmaW5pc2hl
ZCBkb21haW5zLg0KQEAgLTQ3OCwzMCArNDM4LDMwIEBAIHN0YXRpYyB2b2lkIGRlc2NoZWRfZWRm
X2RvbShzX3RpbWVfdCBub3cNCiAgIA0KICAgICAgICAgaWYgKCBpbmYtPnBlcmlvZCA8IGluZi0+
cGVyaW9kX29yaWcgKQ0KICAgICAgICAgew0KLSAgICAgICAgICAgIC8qIFRoaXMgZG9tYWluIHJ1
bnMgaW4gbGF0ZW5jeSBzY2FsaW5nIG9yIGJ1cnN0IG1vZGUuICovDQorICAgICAgICAgICAgLyog
VGhpcyBkb21haW4gcnVucyBpbiBsYXRlbmN5IHNjYWxpbmcgb3IgYnVyc3QgbW9kZSAqLw0KICAg
ICAgICAgICAgIGluZi0+cGVyaW9kICo9IDI7DQogICAgICAgICAgICAgaW5mLT5zbGljZSAgKj0g
MjsNCiAgICAgICAgICAgICBpZiAoIChpbmYtPnBlcmlvZCA+IGluZi0+cGVyaW9kX29yaWcpIHx8
DQogICAgICAgICAgICAgICAgICAoaW5mLT5zbGljZSA+IGluZi0+c2xpY2Vfb3JpZykgKQ0KICAg
ICAgICAgICAgIHsNCi0gICAgICAgICAgICAgICAgLyogUmVzZXQgc2xpY2UgYW5kIHBlcmlvZC4g
Ki8NCisgICAgICAgICAgICAgICAgLyogUmVzZXQgc2xpY2UgYW5kIHBlcmlvZCAqLw0KICAgICAg
ICAgICAgICAgICBpbmYtPnBlcmlvZCA9IGluZi0+cGVyaW9kX29yaWc7DQogICAgICAgICAgICAg
ICAgIGluZi0+c2xpY2UgPSBpbmYtPnNsaWNlX29yaWc7DQogICAgICAgICAgICAgfQ0KICAgICAg
ICAgfQ0KIA0KLSAgICAgICAgLyogU2V0IG5leHQgZGVhZGxpbmUuICovDQorICAgICAgICAvKiBT
ZXQgbmV4dCBkZWFkbGluZSAqLw0KICAgICAgICAgaW5mLT5kZWFkbF9hYnMgKz0gaW5mLT5wZXJp
b2Q7DQogICAgIH0NCiAgDQotICAgIC8qIEFkZCBhIHJ1bm5hYmxlIGRvbWFpbiB0byB0aGUgd2Fp
dHF1ZXVlLiAqLw0KKyAgICAvKiBBZGQgYSBydW5uYWJsZSBkb21haW4gdG8gdGhlIHdhaXRxdWV1
ZSAqLw0KICAgICBpZiAoIHNlZGZfcnVubmFibGUoZCkgKQ0KICAgICB7DQogICAgICAgICBfX2Fk
ZF90b193YWl0cXVldWVfc29ydChkKTsNCiAgICAgfQ0KICAgICBlbHNlDQogICAgIHsNCi0gICAg
ICAgIC8qIFdlIGhhdmUgYSBibG9ja2VkIHJlYWx0aW1lIHRhc2sgLT4gcmVtb3ZlIGl0IGZyb20g
ZXhxcyB0b28uICovDQorICAgICAgICAvKiBXZSBoYXZlIGEgYmxvY2tlZCByZWFsdGltZSB0YXNr
IC0+IHJlbW92ZSBpdCBmcm9tIGV4cXMgdG9vICovDQogICAgICAgICBpZiAoIGV4dHJhcV9vbihk
LCBFWFRSQV9QRU5fUSkgKQ0KICAgICAgICAgICAgIGV4dHJhcV9kZWwoZCwgRVhUUkFfUEVOX1Ep
Ow0KICAgICAgICAgaWYgKCBleHRyYXFfb24oZCwgRVhUUkFfVVRJTF9RKSApDQpAQCAtNTIxLDgg
KzQ4MSw2IEBAIHN0YXRpYyB2b2lkIHVwZGF0ZV9xdWV1ZXMoDQogICAgIHN0cnVjdCBsaXN0X2hl
YWQgICAgICpjdXIsICp0bXA7DQogICAgIHN0cnVjdCBzZWRmX3ZjcHVfaW5mbyAqY3VyaW5mOw0K
ICANCi0gICAgUFJJTlQoMywiVXBkYXRpbmcgd2FpdHEuLlxuIik7DQotDQogICAgIC8qDQogICAg
ICAqIENoZWNrIGZvciB0aGUgZmlyc3QgZWxlbWVudHMgb2YgdGhlIHdhaXRxdWV1ZSwgd2hldGhl
ciB0aGVpcg0KICAgICAgKiBuZXh0IHBlcmlvZCBoYXMgYWxyZWFkeSBzdGFydGVkLg0KQEAgLTUz
MCw0MSArNDg4LDMyIEBAIHN0YXRpYyB2b2lkIHVwZGF0ZV9xdWV1ZXMoDQogICAgIGxpc3RfZm9y
X2VhY2hfc2FmZSAoIGN1ciwgdG1wLCB3YWl0cSApDQogICAgIHsNCiAgICAgICAgIGN1cmluZiA9
IGxpc3RfZW50cnkoY3VyLCBzdHJ1Y3Qgc2VkZl92Y3B1X2luZm8sIGxpc3QpOw0KLSAgICAgICAg
UFJJTlQoNCwiXHRMb29raW5nIEAgZG9tICVpLiVpXG4iLA0KLSAgICAgICAgICAgICAgY3VyaW5m
LT52Y3B1LT5kb21haW4tPmRvbWFpbl9pZCwgY3VyaW5mLT52Y3B1LT52Y3B1X2lkKTsNCiAgICAg
ICAgIGlmICggUEVSSU9EX0JFR0lOKGN1cmluZikgPiBub3cgKQ0KICAgICAgICAgICAgIGJyZWFr
Ow0KICAgICAgICAgX19kZWxfZnJvbV9xdWV1ZShjdXJpbmYtPnZjcHUpOw0KICAgICAgICAgX19h
ZGRfdG9fcnVucXVldWVfc29ydChjdXJpbmYtPnZjcHUpOw0KICAgICB9DQogIA0KLSAgICBQUklO
VCgzLCJVcGRhdGluZyBydW5xLi5cbiIpOw0KLQ0KLSAgICAvKiBQcm9jZXNzIHRoZSBydW5xLCBm
aW5kIGRvbWFpbnMgdGhhdCBhcmUgb24gdGhlIHJ1bnEgdGhhdCBzaG91bGRuJ3QuICovDQorICAg
IC8qIFByb2Nlc3MgdGhlIHJ1bnEsIGZpbmQgZG9tYWlucyB0aGF0IGFyZSBvbiB0aGUgcnVucSB0
aGF0IHNob3VsZG4ndCAqLw0KICAgICBsaXN0X2Zvcl9lYWNoX3NhZmUgKCBjdXIsIHRtcCwgcnVu
cSApDQogICAgIHsNCiAgICAgICAgIGN1cmluZiA9IGxpc3RfZW50cnkoY3VyLHN0cnVjdCBzZWRm
X3ZjcHVfaW5mbyxsaXN0KTsNCi0gICAgICAgIFBSSU5UKDQsIlx0TG9va2luZyBAIGRvbSAlaS4l
aVxuIiwNCi0gICAgICAgICAgICAgIGN1cmluZi0+dmNwdS0+ZG9tYWluLT5kb21haW5faWQsIGN1
cmluZi0+dmNwdS0+dmNwdV9pZCk7DQogDQogICAgICAgICBpZiAoIHVubGlrZWx5KGN1cmluZi0+
c2xpY2UgPT0gMCkgKQ0KICAgICAgICAgew0KLSAgICAgICAgICAgIC8qIElnbm9yZSBkb21haW5z
IHdpdGggZW1wdHkgc2xpY2UuICovDQotICAgICAgICAgICAgUFJJTlQoNCwiXHRVcGRhdGluZyB6
ZXJvLXNsaWNlIGRvbWFpbiAlaS4laVxuIiwNCi0gICAgICAgICAgICAgICAgICBjdXJpbmYtPnZj
cHUtPmRvbWFpbi0+ZG9tYWluX2lkLA0KLSAgICAgICAgICAgICAgICAgIGN1cmluZi0+dmNwdS0+
dmNwdV9pZCk7DQorICAgICAgICAgICAgLyogSWdub3JlIGRvbWFpbnMgd2l0aCBlbXB0eSBzbGlj
ZSAqLw0KICAgICAgICAgICAgIF9fZGVsX2Zyb21fcXVldWUoY3VyaW5mLT52Y3B1KTsNCiANCi0g
ICAgICAgICAgICAvKiBNb3ZlIHRoZW0gdG8gdGhlaXIgbmV4dCBwZXJpb2QuICovDQorICAgICAg
ICAgICAgLyogTW92ZSB0aGVtIHRvIHRoZWlyIG5leHQgcGVyaW9kICovDQogICAgICAgICAgICAg
Y3VyaW5mLT5kZWFkbF9hYnMgKz0gY3VyaW5mLT5wZXJpb2Q7DQogDQotICAgICAgICAgICAgLyog
RW5zdXJlIHRoYXQgdGhlIHN0YXJ0IG9mIHRoZSBuZXh0IHBlcmlvZCBpcyBpbiB0aGUgZnV0dXJl
LiAqLw0KKyAgICAgICAgICAgIC8qIEVuc3VyZSB0aGF0IHRoZSBzdGFydCBvZiB0aGUgbmV4dCBw
ZXJpb2QgaXMgaW4gdGhlIGZ1dHVyZSAqLw0KICAgICAgICAgICAgIGlmICggdW5saWtlbHkoUEVS
SU9EX0JFR0lOKGN1cmluZikgPCBub3cpICkNCiAgICAgICAgICAgICAgICAgY3VyaW5mLT5kZWFk
bF9hYnMgKz0gDQogICAgICAgICAgICAgICAgICAgICAoRElWX1VQKG5vdyAtIFBFUklPRF9CRUdJ
TihjdXJpbmYpLA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICBjdXJpbmYtPnBlcmlvZCkp
ICogY3VyaW5mLT5wZXJpb2Q7DQogDQotICAgICAgICAgICAgLyogUHV0IHRoZW0gYmFjayBpbnRv
IHRoZSBxdWV1ZS4gKi8NCisgICAgICAgICAgICAvKiBQdXQgdGhlbSBiYWNrIGludG8gdGhlIHF1
ZXVlICovDQogICAgICAgICAgICAgX19hZGRfdG9fd2FpdHF1ZXVlX3NvcnQoY3VyaW5mLT52Y3B1
KTsNCiAgICAgICAgIH0NCiAgICAgICAgIGVsc2UgaWYgKCB1bmxpa2VseSgoY3VyaW5mLT5kZWFk
bF9hYnMgPCBub3cpIHx8DQpAQCAtNTc0LDE4ICs1MjMsMTggQEAgc3RhdGljIHZvaWQgdXBkYXRl
X3F1ZXVlcygNCiAgICAgICAgICAgICAgKiBXZSBtaXNzZWQgdGhlIGRlYWRsaW5lIG9yIHRoZSBz
bGljZSB3YXMgYWxyZWFkeSBmaW5pc2hlZC4NCiAgICAgICAgICAgICAgKiBNaWdodCBoYXBlbiBi
ZWNhdXNlIG9mIGRvbV9hZGouDQogICAgICAgICAgICAgICovDQotICAgICAgICAgICAgUFJJTlQo
NCwiXHREb21haW4gJWkuJWkgZXhjZWVkZWQgaXQncyBkZWFkbGluZS8iDQotICAgICAgICAgICAg
ICAgICAgInNsaWNlICglIlBSSXU2NCIgLyAlIlBSSXU2NCIpIG5vdzogJSJQUkl1NjQNCi0gICAg
ICAgICAgICAgICAgICAiIGNwdXRpbWU6ICUiUFJJdTY0IlxuIiwNCi0gICAgICAgICAgICAgICAg
ICBjdXJpbmYtPnZjcHUtPmRvbWFpbi0+ZG9tYWluX2lkLA0KLSAgICAgICAgICAgICAgICAgIGN1
cmluZi0+dmNwdS0+dmNwdV9pZCwNCi0gICAgICAgICAgICAgICAgICBjdXJpbmYtPmRlYWRsX2Fi
cywgY3VyaW5mLT5zbGljZSwgbm93LA0KLSAgICAgICAgICAgICAgICAgIGN1cmluZi0+Y3B1dGlt
ZSk7DQorICAgICAgICAgICAgcHJpbnRrKCJcdERvbWFpbiAlaS4laSBleGNlZWRlZCBpdCdzIGRl
YWRsaW5lLyINCisgICAgICAgICAgICAgICAgICAgInNsaWNlICglIlBSSXU2NCIgLyAlIlBSSXU2
NCIpIG5vdzogJSJQUkl1NjQNCisgICAgICAgICAgICAgICAgICAgIiBjcHV0aW1lOiAlIlBSSXU2
NCJcbiIsDQorICAgICAgICAgICAgICAgICAgIGN1cmluZi0+dmNwdS0+ZG9tYWluLT5kb21haW5f
aWQsDQorICAgICAgICAgICAgICAgICAgIGN1cmluZi0+dmNwdS0+dmNwdV9pZCwNCisgICAgICAg
ICAgICAgICAgICAgY3VyaW5mLT5kZWFkbF9hYnMsIGN1cmluZi0+c2xpY2UsIG5vdywNCisgICAg
ICAgICAgICAgICAgICAgY3VyaW5mLT5jcHV0aW1lKTsNCiAgICAgICAgICAgICBfX2RlbF9mcm9t
X3F1ZXVlKGN1cmluZi0+dmNwdSk7DQogDQotICAgICAgICAgICAgLyogQ29tbW9uIGNhc2U6IHdl
IG1pc3Mgb25lIHBlcmlvZC4gKi8NCisgICAgICAgICAgICAvKiBDb21tb24gY2FzZTogd2UgbWlz
cyBvbmUgcGVyaW9kICovDQogICAgICAgICAgICAgY3VyaW5mLT5kZWFkbF9hYnMgKz0gY3VyaW5m
LT5wZXJpb2Q7DQotICAgDQorDQogICAgICAgICAgICAgLyoNCiAgICAgICAgICAgICAgKiBJZiB3
ZSBhcmUgc3RpbGwgYmVoaW5kOiBtb2R1bG8gYXJpdGhtZXRpYywgZm9yY2UgZGVhZGxpbmUNCiAg
ICAgICAgICAgICAgKiB0byBiZSBpbiBmdXR1cmUgYW5kIGFsaWduZWQgdG8gcGVyaW9kIGJvcmRl
cnMuDQpAQCAtNTk2LDcgKzU0NSw3IEBAIHN0YXRpYyB2b2lkIHVwZGF0ZV9xdWV1ZXMoDQogICAg
ICAgICAgICAgICAgICAgICAgICAgICAgY3VyaW5mLT5wZXJpb2QpICogY3VyaW5mLT5wZXJpb2Q7
DQogICAgICAgICAgICAgQVNTRVJUKGN1cmluZi0+ZGVhZGxfYWJzID49IG5vdyk7DQogDQotICAg
ICAgICAgICAgLyogR2l2ZSBhIGZyZXNoIHNsaWNlLiAqLw0KKyAgICAgICAgICAgIC8qIEdpdmUg
YSBmcmVzaCBzbGljZSAqLw0KICAgICAgICAgICAgIGN1cmluZi0+Y3B1dGltZSA9IDA7DQogICAg
ICAgICAgICAgaWYgKCBQRVJJT0RfQkVHSU4oY3VyaW5mKSA+IG5vdyApDQogICAgICAgICAgICAg
ICAgIF9fYWRkX3RvX3dhaXRxdWV1ZV9zb3J0KGN1cmluZi0+dmNwdSk7DQpAQCAtNjA2LDE3ICs1
NTUsMTcgQEAgc3RhdGljIHZvaWQgdXBkYXRlX3F1ZXVlcygNCiAgICAgICAgIGVsc2UNCiAgICAg
ICAgICAgICBicmVhazsNCiAgICAgfQ0KLQ0KLSAgICBQUklOVCgzLCJkb25lIHVwZGF0aW5nIHRo
ZSBxdWV1ZXNcbiIpOw0KIH0NCiANCiANCi0vKiByZW1vdmVzIGEgZG9tYWluIGZyb20gdGhlIGhl
YWQgb2YgdGhlIGFjY29yZGluZyBleHRyYVEgYW5kDQotICAgcmVxdWV1ZXMgaXQgYXQgYSBzcGVj
aWZpZWQgcG9zaXRpb246DQotICAgICByb3VuZC1yb2JpbiBleHRyYXRpbWU6IGVuZCBvZiBleHRy
YVENCi0gICAgIHdlaWdodGVkIGV4dC46IGluc2VydCBpbiBzb3J0ZWQgbGlzdCBieSBzY29yZQ0K
LSAgIGlmIHRoZSBkb21haW4gaXMgYmxvY2tlZCAvIGhhcyByZWdhaW5lZCBpdHMgc2hvcnQtYmxv
Y2stbG9zcw0KLSAgIHRpbWUgaXQgaXMgbm90IHB1dCBvbiBhbnkgcXVldWUgKi8NCisvKg0KKyAq
IHJlbW92ZXMgYSBkb21haW4gZnJvbSB0aGUgaGVhZCBvZiB0aGUgYWNjb3JkaW5nIGV4dHJhUSBh
bmQNCisgKiByZXF1ZXVlcyBpdCBhdCBhIHNwZWNpZmllZCBwb3NpdGlvbjoNCisgKiAgIHJvdW5k
LXJvYmluIGV4dHJhdGltZTogZW5kIG9mIGV4dHJhUQ0KKyAqICAgd2VpZ2h0ZWQgZXh0LjogaW5z
ZXJ0IGluIHNvcnRlZCBsaXN0IGJ5IHNjb3JlDQorICogaWYgdGhlIGRvbWFpbiBpcyBibG9ja2Vk
IC8gaGFzIHJlZ2FpbmVkIGl0cyBzaG9ydC1ibG9jay1sb3NzDQorICogdGltZSBpdCBpcyBub3Qg
cHV0IG9uIGFueSBxdWV1ZS4NCisgKi8NCiBzdGF0aWMgdm9pZCBkZXNjaGVkX2V4dHJhX2RvbShz
X3RpbWVfdCBub3csIHN0cnVjdCB2Y3B1ICpkKQ0KIHsNCiAgICAgc3RydWN0IHNlZGZfdmNwdV9p
bmZvICppbmYgPSBFRE9NX0lORk8oZCk7DQpAQCAtNjI1LDI5ICs1NzQsMjUgQEAgc3RhdGljIHZv
aWQgZGVzY2hlZF9leHRyYV9kb20oc190aW1lX3Qgbg0KIA0KICAgICBBU1NFUlQoZXh0cmFxX29u
KGQsIGkpKTsNCiANCi0gICAgLyogVW5zZXQgYWxsIHJ1bm5pbmcgZmxhZ3MuICovDQorICAgIC8q
IFVuc2V0IGFsbCBydW5uaW5nIGZsYWdzICovDQogICAgIGluZi0+c3RhdHVzICAmPSB+KEVYVFJB
X1JVTl9QRU4gfCBFWFRSQV9SVU5fVVRJTCk7DQotICAgIC8qIEZyZXNoIHNsaWNlIGZvciB0aGUg
bmV4dCBydW4uICovDQorICAgIC8qIEZyZXNoIHNsaWNlIGZvciB0aGUgbmV4dCBydW4gKi8NCiAg
ICAgaW5mLT5jcHV0aW1lID0gMDsNCi0gICAgLyogQWNjdW11bGF0ZSB0b3RhbCBleHRyYXRpbWUu
ICovDQorICAgIC8qIEFjY3VtdWxhdGUgdG90YWwgZXh0cmF0aW1lICovDQogICAgIGluZi0+ZXh0
cmFfdGltZV90b3QgKz0gbm93IC0gaW5mLT5zY2hlZF9zdGFydF9hYnM7DQogICAgIC8qIFJlbW92
ZSBleHRyYWRvbWFpbiBmcm9tIGhlYWQgb2YgdGhlIHF1ZXVlLiAqLw0KICAgICBleHRyYXFfZGVs
KGQsIGkpOw0KIA0KLSAgICAvKiBVcGRhdGUgdGhlIHNjb3JlLiAqLw0KKyAgICAvKiBVcGRhdGUg
dGhlIHNjb3JlICovDQogICAgIG9sZHNjb3JlID0gaW5mLT5zY29yZVtpXTsNCiAgICAgaWYgKCBp
ID09IEVYVFJBX1BFTl9RICkNCiAgICAgew0KLSAgICAgICAgLypkb21haW4gd2FzIHJ1bm5pbmcg
aW4gTDAgZXh0cmFxKi8NCi0gICAgICAgIC8qcmVkdWNlIGJsb2NrIGxvc3QsIHByb2JhYmx5IG1v
cmUgc29waGlzdGljYXRpb24gaGVyZSEqLw0KKyAgICAgICAgLyogRG9tYWluIHdhcyBydW5uaW5n
IGluIEwwIGV4dHJhcSAqLw0KKyAgICAgICAgLyogcmVkdWNlIGJsb2NrIGxvc3QsIHByb2JhYmx5
IG1vcmUgc29waGlzdGljYXRpb24gaGVyZSEqLw0KICAgICAgICAgLyppbmYtPnNob3J0X2Jsb2Nr
X2xvc3RfdG90IC09IEVYVFJBX1FVQU5UVU07Ki8NCiAgICAgICAgIGluZi0+c2hvcnRfYmxvY2tf
bG9zdF90b3QgLT0gbm93IC0gaW5mLT5zY2hlZF9zdGFydF9hYnM7DQotICAgICAgICBQUklOVCgz
LCJEb21haW4gJWkuJWk6IFNob3J0X2Jsb2NrX2xvc3M6ICUiUFJJaTY0IlxuIiwgDQotICAgICAg
ICAgICAgICBpbmYtPnZjcHUtPmRvbWFpbi0+ZG9tYWluX2lkLCBpbmYtPnZjcHUtPnZjcHVfaWQs
DQotICAgICAgICAgICAgICBpbmYtPnNob3J0X2Jsb2NrX2xvc3RfdG90KTsNCiAjaWYgMA0KLSAg
ICAgICAgLyoNCi0gICAgICAgICAqIEtBRjogSWYgd2UgZG9uJ3QgZXhpdCBzaG9ydC1ibG9ja2lu
ZyBzdGF0ZSBhdCB0aGlzIHBvaW50DQorICAgICAgICAvKiBLQUY6IElmIHdlIGRvbid0IGV4aXQg
c2hvcnQtYmxvY2tpbmcgc3RhdGUgYXQgdGhpcyBwb2ludA0KICAgICAgICAgICogZG9tYWluMCBj
YW4gc3RlYWwgYWxsIENQVSBmb3IgdXAgdG8gMTAgc2Vjb25kcyBiZWZvcmUNCiAgICAgICAgICAq
IHNjaGVkdWxpbmcgc2V0dGxlcyBkb3duICh3aGVuIGNvbXBldGluZyBhZ2FpbnN0IGFub3RoZXIN
CiAgICAgICAgICAqIENQVS1ib3VuZCBkb21haW4pLiBEb2luZyB0aGlzIHNlZW1zIHRvIG1ha2Ug
dGhpbmdzIGJlaGF2ZQ0KQEAgLTY1Niw1MSArNjAxLDU5IEBAIHN0YXRpYyB2b2lkIGRlc2NoZWRf
ZXh0cmFfZG9tKHNfdGltZV90IG4NCiAgICAgICAgIGlmICggaW5mLT5zaG9ydF9ibG9ja19sb3N0
X3RvdCA8PSAwICkNCiAjZW5kaWYNCiAgICAgICAgIHsNCi0gICAgICAgICAgICBQUklOVCg0LCJE
b21haW4gJWkuJWkgY29tcGVuc2F0ZWQgc2hvcnQgYmxvY2sgbG9zcyFcbiIsDQotICAgICAgICAg
ICAgICAgICAgaW5mLT52Y3B1LT5kb21haW4tPmRvbWFpbl9pZCwgaW5mLT52Y3B1LT52Y3B1X2lk
KTsNCi0gICAgICAgICAgICAvKndlIGhhdmUgKG92ZXItKWNvbXBlbnNhdGVkIG91ciBibG9jayBw
ZW5hbHR5Ki8NCisgICAgICAgICAgICAvKiBXZSBoYXZlIChvdmVyLSljb21wZW5zYXRlZCBvdXIg
YmxvY2sgcGVuYWx0eSAqLw0KICAgICAgICAgICAgIGluZi0+c2hvcnRfYmxvY2tfbG9zdF90b3Qg
PSAwOw0KLSAgICAgICAgICAgIC8qd2UgZG9uJ3Qgd2FudCBhIHBsYWNlIG9uIHRoZSBwZW5hbHR5
IHF1ZXVlIGFueW1vcmUhKi8NCisgICAgICAgICAgICAvKiBXZSBkb24ndCB3YW50IGEgcGxhY2Ug
b24gdGhlIHBlbmFsdHkgcXVldWUgYW55bW9yZSEgKi8NCiAgICAgICAgICAgICBpbmYtPnN0YXR1
cyAmPSB+RVhUUkFfV0FOVF9QRU5fUTsNCiAgICAgICAgICAgICBnb3RvIGNoZWNrX2V4dHJhX3F1
ZXVlczsNCiAgICAgICAgIH0NCiANCi0gICAgICAgIC8qd2UgaGF2ZSB0byBnbyBhZ2FpbiBmb3Ig
YW5vdGhlciB0cnkgaW4gdGhlIGJsb2NrLWV4dHJhcSwNCi0gICAgICAgICAgdGhlIHNjb3JlIGlz
IG5vdCB1c2VkIGluY3JlbWFudGFsbHkgaGVyZSwgYXMgdGhpcyBpcw0KLSAgICAgICAgICBhbHJl
YWR5IGRvbmUgYnkgcmVjYWxjdWxhdGluZyB0aGUgYmxvY2tfbG9zdCovDQorICAgICAgICAvKg0K
KyAgICAgICAgICogV2UgaGF2ZSB0byBnbyBhZ2FpbiBmb3IgYW5vdGhlciB0cnkgaW4gdGhlIGJs
b2NrLWV4dHJhcSwNCisgICAgICAgICAqIHRoZSBzY29yZSBpcyBub3QgdXNlZCBpbmNyZW1hbnRh
bGx5IGhlcmUsIGFzIHRoaXMgaXMNCisgICAgICAgICAqIGFscmVhZHkgZG9uZSBieSByZWNhbGN1
bGF0aW5nIHRoZSBibG9ja19sb3N0DQorICAgICAgICAgKi8NCiAgICAgICAgIGluZi0+c2NvcmVb
RVhUUkFfUEVOX1FdID0gKGluZi0+cGVyaW9kIDw8IDEwKSAvDQogICAgICAgICAgICAgaW5mLT5z
aG9ydF9ibG9ja19sb3N0X3RvdDsNCiAgICAgICAgIG9sZHNjb3JlID0gMDsNCiAgICAgfQ0KICAg
ICBlbHNlDQogICAgIHsNCi0gICAgICAgIC8qZG9tYWluIHdhcyBydW5uaW5nIGluIEwxIGV4dHJh
cSA9PiBzY29yZSBpcyBpbnZlcnNlIG9mDQotICAgICAgICAgIHV0aWxpemF0aW9uIGFuZCBpcyB1
c2VkIHNvbWV3aGF0IGluY3JlbWVudGFsISovDQorICAgICAgICAvKg0KKyAgICAgICAgICogRG9t
YWluIHdhcyBydW5uaW5nIGluIEwxIGV4dHJhcSA9PiBzY29yZSBpcyBpbnZlcnNlIG9mDQorICAg
ICAgICAgKiB1dGlsaXphdGlvbiBhbmQgaXMgdXNlZCBzb21ld2hhdCBpbmNyZW1lbnRhbCENCisg
ICAgICAgICAqLw0KICAgICAgICAgaWYgKCAhaW5mLT5leHRyYXdlaWdodCApDQotICAgICAgICAg
ICAgLypOQjogdXNlIGZpeGVkIHBvaW50IGFyaXRobWV0aWMgd2l0aCAxMCBiaXRzKi8NCisgICAg
ICAgIHsNCisgICAgICAgICAgICAvKiBOQjogdXNlIGZpeGVkIHBvaW50IGFyaXRobWV0aWMgd2l0
aCAxMCBiaXRzICovDQogICAgICAgICAgICAgaW5mLT5zY29yZVtFWFRSQV9VVElMX1FdID0gKGlu
Zi0+cGVyaW9kIDw8IDEwKSAvDQogICAgICAgICAgICAgICAgIGluZi0+c2xpY2U7DQorICAgICAg
ICB9DQogICAgICAgICBlbHNlDQotICAgICAgICAgICAgLypjb252ZXJzaW9uIGJldHdlZW4gcmVh
bHRpbWUgdXRpbGlzYXRpb24gYW5kIGV4dHJhd2llZ2h0Og0KLSAgICAgICAgICAgICAgZnVsbCAo
aWUgMTAwJSkgdXRpbGl6YXRpb24gaXMgZXF1aXZhbGVudCB0byAxMjggZXh0cmF3ZWlnaHQqLw0K
KyAgICAgICAgew0KKyAgICAgICAgICAgIC8qDQorICAgICAgICAgICAgICogQ29udmVyc2lvbiBi
ZXR3ZWVuIHJlYWx0aW1lIHV0aWxpc2F0aW9uIGFuZCBleHRyYXdpZWdodDoNCisgICAgICAgICAg
ICAgKiBmdWxsIChpZSAxMDAlKSB1dGlsaXphdGlvbiBpcyBlcXVpdmFsZW50IHRvIDEyOCBleHRy
YXdlaWdodA0KKyAgICAgICAgICAgICAqLw0KICAgICAgICAgICAgIGluZi0+c2NvcmVbRVhUUkFf
VVRJTF9RXSA9ICgxPDwxNykgLyBpbmYtPmV4dHJhd2VpZ2h0Ow0KKyAgICAgICAgfQ0KICAgICB9
DQogDQogIGNoZWNrX2V4dHJhX3F1ZXVlczoNCi0gICAgLyogQWRkaW5nIGEgcnVubmFibGUgZG9t
YWluIHRvIHRoZSByaWdodCBxdWV1ZSBhbmQgcmVtb3ZpbmcgYmxvY2tlZCBvbmVzKi8NCisgICAg
LyogQWRkaW5nIGEgcnVubmFibGUgZG9tYWluIHRvIHRoZSByaWdodCBxdWV1ZSBhbmQgcmVtb3Zp
bmcgYmxvY2tlZCBvbmVzICovDQogICAgIGlmICggc2VkZl9ydW5uYWJsZShkKSApDQogICAgIHsN
Ci0gICAgICAgIC8qYWRkIGFjY29yZGluZyB0byBzY29yZTogd2VpZ2h0ZWQgcm91bmQgcm9iaW4q
Lw0KKyAgICAgICAgLyogQWRkIGFjY29yZGluZyB0byBzY29yZTogd2VpZ2h0ZWQgcm91bmQgcm9i
aW4gKi8NCiAgICAgICAgIGlmICgoKGluZi0+c3RhdHVzICYgRVhUUkFfQVdBUkUpICYmIChpID09
IEVYVFJBX1VUSUxfUSkpIHx8DQogICAgICAgICAgICAgKChpbmYtPnN0YXR1cyAmIEVYVFJBX1dB
TlRfUEVOX1EpICYmIChpID09IEVYVFJBX1BFTl9RKSkpDQogICAgICAgICAgICAgZXh0cmFxX2Fk
ZF9zb3J0X3VwZGF0ZShkLCBpLCBvbGRzY29yZSk7DQogICAgIH0NCiAgICAgZWxzZQ0KICAgICB7
DQotICAgICAgICAvKnJlbW92ZSB0aGlzIGJsb2NrZWQgZG9tYWluIGZyb20gdGhlIHdhaXRxISov
DQorICAgICAgICAvKiBSZW1vdmUgdGhpcyBibG9ja2VkIGRvbWFpbiBmcm9tIHRoZSB3YWl0cSEg
Ki8NCiAgICAgICAgIF9fZGVsX2Zyb21fcXVldWUoZCk7DQotICAgICAgICAvKm1ha2Ugc3VyZSB0
aGF0IHdlIHJlbW92ZSBhIGJsb2NrZWQgZG9tYWluIGZyb20gdGhlIG90aGVyDQotICAgICAgICAg
IGV4dHJhcSB0b28qLw0KKyAgICAgICAgLyogTWFrZSBzdXJlIHRoYXQgd2UgcmVtb3ZlIGEgYmxv
Y2tlZCBkb21haW4gZnJvbSB0aGUgb3RoZXINCisgICAgICAgICAqIGV4dHJhcSB0b28uICovDQog
ICAgICAgICBpZiAoIGkgPT0gRVhUUkFfUEVOX1EgKQ0KICAgICAgICAgew0KICAgICAgICAgICAg
IGlmICggZXh0cmFxX29uKGQsIEVYVFJBX1VUSUxfUSkgKQ0KQEAgLTczMiw4ICs2ODUsMTAgQEAg
c3RhdGljIHN0cnVjdCB0YXNrX3NsaWNlIHNlZGZfZG9fZXh0cmFfcw0KIA0KICAgICBpZiAoICFs
aXN0X2VtcHR5KGV4dHJhcVtFWFRSQV9QRU5fUV0pICkNCiAgICAgew0KLSAgICAgICAgLyp3ZSBz
dGlsbCBoYXZlIGVsZW1lbnRzIG9uIHRoZSBsZXZlbCAwIGV4dHJhcSANCi0gICAgICAgICAgPT4g
bGV0IHRob3NlIHJ1biBmaXJzdCEqLw0KKyAgICAgICAgLyoNCisgICAgICAgICAqIFdlIHN0aWxs
IGhhdmUgZWxlbWVudHMgb24gdGhlIGxldmVsIDAgZXh0cmFxDQorICAgICAgICAgKiA9PiBsZXQg
dGhvc2UgcnVuIGZpcnN0IQ0KKyAgICAgICAgICovDQogICAgICAgICBydW5pbmYgICA9IGxpc3Rf
ZW50cnkoZXh0cmFxW0VYVFJBX1BFTl9RXS0+bmV4dCwgDQogICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgc3RydWN0IHNlZGZfdmNwdV9pbmZvLCBleHRyYWxpc3RbRVhUUkFfUEVOX1FdKTsN
CiAgICAgICAgIHJ1bmluZi0+c3RhdHVzIHw9IEVYVFJBX1JVTl9QRU47DQpAQCAtNzQ3LDcgKzcw
Miw3IEBAIHN0YXRpYyBzdHJ1Y3QgdGFza19zbGljZSBzZWRmX2RvX2V4dHJhX3MNCiAgICAgew0K
ICAgICAgICAgaWYgKCAhbGlzdF9lbXB0eShleHRyYXFbRVhUUkFfVVRJTF9RXSkgKQ0KICAgICAg
ICAgew0KLSAgICAgICAgICAgIC8qdXNlIGVsZW1lbnRzIGZyb20gdGhlIG5vcm1hbCBleHRyYXF1
ZXVlKi8NCisgICAgICAgICAgICAvKiBVc2UgZWxlbWVudHMgZnJvbSB0aGUgbm9ybWFsIGV4dHJh
cXVldWUgKi8NCiAgICAgICAgICAgICBydW5pbmYgICA9IGxpc3RfZW50cnkoZXh0cmFxW0VYVFJB
X1VUSUxfUV0tPm5leHQsDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHN0cnVj
dCBzZWRmX3ZjcHVfaW5mbywNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgZXh0
cmFsaXN0W0VYVFJBX1VUSUxfUV0pOw0KQEAgLTc3MiwxMSArNzI3LDEzIEBAIHN0YXRpYyBzdHJ1
Y3QgdGFza19zbGljZSBzZWRmX2RvX2V4dHJhX3MNCiB9DQogDQogDQotLyogTWFpbiBzY2hlZHVs
aW5nIGZ1bmN0aW9uDQotICAgUmVhc29ucyBmb3IgY2FsbGluZyB0aGlzIGZ1bmN0aW9uIGFyZToN
Ci0gICAtdGltZXNsaWNlIGZvciB0aGUgY3VycmVudCBwZXJpb2QgdXNlZCB1cA0KLSAgIC1kb21h
aW4gb24gd2FpdHF1ZXVlIGhhcyBzdGFydGVkIGl0J3MgcGVyaW9kDQotICAgLWFuZCB2YXJpb3Vz
IG90aGVycyA7KSBpbiBnZW5lcmFsOiBkZXRlcm1pbmUgd2hpY2ggZG9tYWluIHRvIHJ1biBuZXh0
Ki8NCisvKg0KKyAqIE1haW4gc2NoZWR1bGluZyBmdW5jdGlvbg0KKyAqIFJlYXNvbnMgZm9yIGNh
bGxpbmcgdGhpcyBmdW5jdGlvbiBhcmU6DQorICogLXRpbWVzbGljZSBmb3IgdGhlIGN1cnJlbnQg
cGVyaW9kIHVzZWQgdXANCisgKiAtZG9tYWluIG9uIHdhaXRxdWV1ZSBoYXMgc3RhcnRlZCBpdCdz
IHBlcmlvZA0KKyAqIC1hbmQgdmFyaW91cyBvdGhlcnMgOykgaW4gZ2VuZXJhbDogZGV0ZXJtaW5l
IHdoaWNoIGRvbWFpbiB0byBydW4gbmV4dA0KKyAqLw0KIHN0YXRpYyBzdHJ1Y3QgdGFza19zbGlj
ZSBzZWRmX2RvX3NjaGVkdWxlKA0KICAgICBjb25zdCBzdHJ1Y3Qgc2NoZWR1bGVyICpvcHMsIHNf
dGltZV90IG5vdywgYm9vbF90IHRhc2tsZXRfd29ya19zY2hlZHVsZWQpDQogew0KQEAgLTc4OSwx
MyArNzQ2LDE1IEBAIHN0YXRpYyBzdHJ1Y3QgdGFza19zbGljZSBzZWRmX2RvX3NjaGVkdWwNCiAg
ICAgc3RydWN0IHNlZGZfdmNwdV9pbmZvICpydW5pbmYsICp3YWl0aW5mOw0KICAgICBzdHJ1Y3Qg
dGFza19zbGljZSAgICAgIHJldDsNCiANCi0gICAgLyppZGxlIHRhc2tzIGRvbid0IG5lZWQgYW55
IG9mIHRoZSBmb2xsb3dpbmcgc3R1ZiovDQorICAgIC8qIElkbGUgdGFza3MgZG9uJ3QgbmVlZCBh
bnkgb2YgdGhlIGZvbGxvd2luZyBzdHVmICovDQogICAgIGlmICggaXNfaWRsZV92Y3B1KGN1cnJl
bnQpICkNCiAgICAgICAgIGdvdG8gY2hlY2tfd2FpdHE7DQotIA0KLSAgICAvKiBjcmVhdGUgbG9j
YWwgc3RhdGUgb2YgdGhlIHN0YXR1cyBvZiB0aGUgZG9tYWluLCBpbiBvcmRlciB0byBhdm9pZA0K
LSAgICAgICBpbmNvbnNpc3RlbnQgc3RhdGUgZHVyaW5nIHNjaGVkdWxpbmcgZGVjaXNpb25zLCBi
ZWNhdXNlIGRhdGEgZm9yDQotICAgICAgIHZjcHVfcnVubmFibGUgaXMgbm90IHByb3RlY3RlZCBi
eSB0aGUgc2NoZWR1bGluZyBsb2NrISovDQorDQorICAgIC8qDQorICAgICAqIENyZWF0ZSBsb2Nh
bCBzdGF0ZSBvZiB0aGUgc3RhdHVzIG9mIHRoZSBkb21haW4sIGluIG9yZGVyIHRvIGF2b2lkDQor
ICAgICAqIGluY29uc2lzdGVudCBzdGF0ZSBkdXJpbmcgc2NoZWR1bGluZyBkZWNpc2lvbnMsIGJl
Y2F1c2UgZGF0YSBmb3INCisgICAgICogdmNwdV9ydW5uYWJsZSBpcyBub3QgcHJvdGVjdGVkIGJ5
IHRoZSBzY2hlZHVsaW5nIGxvY2shDQorICAgICAqLw0KICAgICBpZiAoICF2Y3B1X3J1bm5hYmxl
KGN1cnJlbnQpICkNCiAgICAgICAgIGluZi0+c3RhdHVzIHw9IFNFREZfQVNMRUVQOw0KICANCkBA
IC04MDQsNyArNzYzLDcgQEAgc3RhdGljIHN0cnVjdCB0YXNrX3NsaWNlIHNlZGZfZG9fc2NoZWR1
bA0KIA0KICAgICBpZiAoIHVubGlrZWx5KGV4dHJhX3J1bnMoaW5mKSkgKQ0KICAgICB7DQotICAg
ICAgICAvKnNwZWNpYWwgdHJlYXRtZW50IG9mIGRvbWFpbnMgcnVubmluZyBpbiBleHRyYSB0aW1l
Ki8NCisgICAgICAgIC8qIFNwZWNpYWwgdHJlYXRtZW50IG9mIGRvbWFpbnMgcnVubmluZyBpbiBl
eHRyYSB0aW1lICovDQogICAgICAgICBkZXNjaGVkX2V4dHJhX2RvbShub3csIGN1cnJlbnQpOw0K
ICAgICB9DQogICAgIGVsc2UgDQpAQCAtODE0LDEwICs3NzMsMTIgQEAgc3RhdGljIHN0cnVjdCB0
YXNrX3NsaWNlIHNlZGZfZG9fc2NoZWR1bA0KICBjaGVja193YWl0cToNCiAgICAgdXBkYXRlX3F1
ZXVlcyhub3csIHJ1bnEsIHdhaXRxKTsNCiANCi0gICAgLypub3cgc2ltcGx5IHBpY2sgdGhlIGZp
cnN0IGRvbWFpbiBmcm9tIHRoZSBydW5xdWV1ZSwgd2hpY2ggaGFzIHRoZQ0KLSAgICAgIGVhcmxp
ZXN0IGRlYWRsaW5lLCBiZWNhdXNlIHRoZSBsaXN0IGlzIHNvcnRlZCovDQotIA0KLSAgICAvKiBU
YXNrbGV0IHdvcmsgKHdoaWNoIHJ1bnMgaW4gaWRsZSBWQ1BVIGNvbnRleHQpIG92ZXJyaWRlcyBh
bGwgZWxzZS4gKi8NCisgICAgLyoNCisgICAgICogTm93IHNpbXBseSBwaWNrIHRoZSBmaXJzdCBk
b21haW4gZnJvbSB0aGUgcnVucXVldWUsIHdoaWNoIGhhcyB0aGUNCisgICAgICogZWFybGllc3Qg
ZGVhZGxpbmUsIGJlY2F1c2UgdGhlIGxpc3QgaXMgc29ydGVkDQorICAgICAqDQorICAgICAqIFRh
c2tsZXQgd29yayAod2hpY2ggcnVucyBpbiBpZGxlIFZDUFUgY29udGV4dCkgb3ZlcnJpZGVzIGFs
bCBlbHNlLg0KKyAgICAgKi8NCiAgICAgaWYgKCB0YXNrbGV0X3dvcmtfc2NoZWR1bGVkIHx8DQog
ICAgICAgICAgKGxpc3RfZW1wdHkocnVucSkgJiYgbGlzdF9lbXB0eSh3YWl0cSkpIHx8DQogICAg
ICAgICAgdW5saWtlbHkoIWNwdW1hc2tfdGVzdF9jcHUoY3B1LCBTRURGX0NQVU9OTElORShwZXJf
Y3B1KGNwdXBvb2wsIGNwdSkpKSkgKQ0KQEAgLTgzMyw5ICs3OTQsMTEgQEAgc3RhdGljIHN0cnVj
dCB0YXNrX3NsaWNlIHNlZGZfZG9fc2NoZWR1bA0KICAgICAgICAgew0KICAgICAgICAgICAgIHdh
aXRpbmYgID0gbGlzdF9lbnRyeSh3YWl0cS0+bmV4dCwNCiAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgc3RydWN0IHNlZGZfdmNwdV9pbmZvLGxpc3QpOw0KLSAgICAgICAgICAgIC8q
cmVydW4gc2NoZWR1bGVyLCB3aGVuIHNjaGVkdWxlZCBkb21haW4gcmVhY2hlcyBpdCdzDQotICAg
ICAgICAgICAgICBlbmQgb2Ygc2xpY2Ugb3IgdGhlIGZpcnN0IGRvbWFpbiBmcm9tIHRoZSB3YWl0
cXVldWUNCi0gICAgICAgICAgICAgIGdldHMgcmVhZHkqLw0KKyAgICAgICAgICAgIC8qDQorICAg
ICAgICAgICAgICogUmVydW4gc2NoZWR1bGVyLCB3aGVuIHNjaGVkdWxlZCBkb21haW4gcmVhY2hl
cyBpdCdzDQorICAgICAgICAgICAgICogZW5kIG9mIHNsaWNlIG9yIHRoZSBmaXJzdCBkb21haW4g
ZnJvbSB0aGUgd2FpdHF1ZXVlDQorICAgICAgICAgICAgICogZ2V0cyByZWFkeS4NCisgICAgICAg
ICAgICAgKi8NCiAgICAgICAgICAgICByZXQudGltZSA9IE1JTihub3cgKyBydW5pbmYtPnNsaWNl
IC0gcnVuaW5mLT5jcHV0aW1lLA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIFBFUklPRF9C
RUdJTih3YWl0aW5mKSkgLSBub3c7DQogICAgICAgICB9DQpAQCAtODQ3LDE0ICs4MTAsMTggQEAg
c3RhdGljIHN0cnVjdCB0YXNrX3NsaWNlIHNlZGZfZG9fc2NoZWR1bA0KICAgICBlbHNlDQogICAg
IHsNCiAgICAgICAgIHdhaXRpbmYgID0gbGlzdF9lbnRyeSh3YWl0cS0+bmV4dCxzdHJ1Y3Qgc2Vk
Zl92Y3B1X2luZm8sIGxpc3QpOw0KLSAgICAgICAgLyp3ZSBjb3VsZCBub3QgZmluZCBhbnkgc3Vp
dGFibGUgZG9tYWluIA0KLSAgICAgICAgICA9PiBsb29rIGZvciBkb21haW5zIHRoYXQgYXJlIGF3
YXJlIG9mIGV4dHJhdGltZSovDQorICAgICAgICAvKg0KKyAgICAgICAgICogV2UgY291bGQgbm90
IGZpbmQgYW55IHN1aXRhYmxlIGRvbWFpbiANCisgICAgICAgICAqID0+IGxvb2sgZm9yIGRvbWFp
bnMgdGhhdCBhcmUgYXdhcmUgb2YgZXh0cmF0aW1lDQorICAgICAgICAgKi8NCiAgICAgICAgIHJl
dCA9IHNlZGZfZG9fZXh0cmFfc2NoZWR1bGUobm93LCBQRVJJT0RfQkVHSU4od2FpdGluZiksDQog
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGV4dHJhcSwgY3B1KTsNCiAgICAg
fQ0KIA0KLSAgICAvKlRPRE86IERvIHNvbWV0aGluZyBVU0VGVUwgd2hlbiB0aGlzIGhhcHBlbnMg
YW5kIGZpbmQgb3V0LCB3aHkgaXQNCi0gICAgICBzdGlsbCBjYW4gaGFwcGVuISEhKi8NCisgICAg
LyoNCisgICAgICogVE9ETzogRG8gc29tZXRoaW5nIFVTRUZVTCB3aGVuIHRoaXMgaGFwcGVucyBh
bmQgZmluZCBvdXQsIHdoeSBpdA0KKyAgICAgKiBzdGlsbCBjYW4gaGFwcGVuISEhDQorICAgICAq
Lw0KICAgICBpZiAoIHJldC50aW1lIDwgMCkNCiAgICAgew0KICAgICAgICAgcHJpbnRrKCJPdWNo
ISBXZSBhcmUgc2VyaW91c2x5IEJFSElORCBzY2hlZHVsZSEgJSJQUklpNjQiXG4iLA0KQEAgLTg3
NCw5ICs4NDEsNiBAQCBzdGF0aWMgc3RydWN0IHRhc2tfc2xpY2Ugc2VkZl9kb19zY2hlZHVsDQog
DQogc3RhdGljIHZvaWQgc2VkZl9zbGVlcChjb25zdCBzdHJ1Y3Qgc2NoZWR1bGVyICpvcHMsIHN0
cnVjdCB2Y3B1ICpkKQ0KIHsNCi0gICAgUFJJTlQoMiwic2VkZl9zbGVlcCB3YXMgY2FsbGVkLCBk
b21haW4taWQgJWkuJWlcbiIsDQotICAgICAgICAgIGQtPmRvbWFpbi0+ZG9tYWluX2lkLCBkLT52
Y3B1X2lkKTsNCi0gDQogICAgIGlmICggaXNfaWRsZV92Y3B1KGQpICkNCiAgICAgICAgIHJldHVy
bjsNCiANCkBAIC04OTgsNyArODYyLDggQEAgc3RhdGljIHZvaWQgc2VkZl9zbGVlcChjb25zdCBz
dHJ1Y3Qgc2NoZQ0KIH0NCiANCiANCi0vKiBUaGlzIGZ1bmN0aW9uIHdha2VzIHVwIGEgZG9tYWlu
LCBpLmUuIG1vdmVzIHRoZW0gaW50byB0aGUgd2FpdHF1ZXVlDQorLyoNCisgKiBUaGlzIGZ1bmN0
aW9uIHdha2VzIHVwIGEgZG9tYWluLCBpLmUuIG1vdmVzIHRoZW0gaW50byB0aGUgd2FpdHF1ZXVl
DQogICogdGhpbmdzIHRvIG1lbnRpb24gYXJlOiBhZG1pc3Npb24gY29udHJvbCBpcyB0YWtpbmcg
cGxhY2Ugbm93aGVyZSBhdA0KICAqIHRoZSBtb21lbnQsIHNvIHdlIGNhbid0IGJlIHN1cmUsIHdo
ZXRoZXIgaXQgaXMgc2FmZSB0byB3YWtlIHRoZSBkb21haW4NCiAgKiB1cCBhdCBhbGwuIEFueXdh
eSwgZXZlbiBpZiBpdCBpcyBzYWZlICh0b3RhbCBjcHUgdXNhZ2UgPD0xMDAlKSB0aGVyZSBhcmUN
CkBAIC05NzIsMjcgKzkzNywzMSBAQCBzdGF0aWMgdm9pZCBzZWRmX3NsZWVwKGNvbnN0IHN0cnVj
dCBzY2hlDQogc3RhdGljIHZvaWQgdW5ibG9ja19zaG9ydF9leHRyYV9zdXBwb3J0KA0KICAgICBz
dHJ1Y3Qgc2VkZl92Y3B1X2luZm8qIGluZiwgc190aW1lX3Qgbm93KQ0KIHsNCi0gICAgLyp0aGlz
IHVuYmxvY2tpbmcgc2NoZW1lIHRyaWVzIHRvIHN1cHBvcnQgdGhlIGRvbWFpbiwgYnkgYXNzaWdu
aW5nIGl0DQotICAgIGEgcHJpb3JpdHkgaW4gZXh0cmF0aW1lIGRpc3RyaWJ1dGlvbiBhY2NvcmRp
bmcgdG8gdGhlIGxvc3Mgb2YgdGltZQ0KLSAgICBpbiB0aGlzIHNsaWNlIGR1ZSB0byBibG9ja2lu
ZyovDQorICAgIC8qDQorICAgICAqIFRoaXMgdW5ibG9ja2luZyBzY2hlbWUgdHJpZXMgdG8gc3Vw
cG9ydCB0aGUgZG9tYWluLCBieSBhc3NpZ25pbmcgaXQNCisgICAgICogYSBwcmlvcml0eSBpbiBl
eHRyYXRpbWUgZGlzdHJpYnV0aW9uIGFjY29yZGluZyB0byB0aGUgbG9zcyBvZiB0aW1lDQorICAg
ICAqIGluIHRoaXMgc2xpY2UgZHVlIHRvIGJsb2NraW5nDQorICAgICAqLw0KICAgICBzX3RpbWVf
dCBwZW47DQogIA0KLSAgICAvKm5vIG1vcmUgcmVhbHRpbWUgZXhlY3V0aW9uIGluIHRoaXMgcGVy
aW9kISovDQorICAgIC8qIE5vIG1vcmUgcmVhbHRpbWUgZXhlY3V0aW9uIGluIHRoaXMgcGVyaW9k
ISAqLw0KICAgICBpbmYtPmRlYWRsX2FicyArPSBpbmYtPnBlcmlvZDsNCiAgICAgaWYgKCBsaWtl
bHkoaW5mLT5ibG9ja19hYnMpICkNCiAgICAgew0KLSAgICAgICAgLy90cmVhdCBibG9ja2VkIHRp
bWUgYXMgY29uc3VtZWQgYnkgdGhlIGRvbWFpbiovDQorICAgICAgICAvKiBUcmVhdCBibG9ja2Vk
IHRpbWUgYXMgY29uc3VtZWQgYnkgdGhlIGRvbWFpbiAqLw0KICAgICAgICAgLyppbmYtPmNwdXRp
bWUgKz0gbm93IC0gaW5mLT5ibG9ja19hYnM7Ki8NCi0gICAgICAgIC8qcGVuYWx0eSBpcyB0aW1l
IHRoZSBkb21haW4gd291bGQgaGF2ZQ0KLSAgICAgICAgICBoYWQgaWYgaXQgY29udGludWVkIHRv
IHJ1biAqLw0KKyAgICAgICAgLyoNCisgICAgICAgICAqIFBlbmFsdHkgaXMgdGltZSB0aGUgZG9t
YWluIHdvdWxkIGhhdmUNCisgICAgICAgICAqIGhhZCBpZiBpdCBjb250aW51ZWQgdG8gcnVuLg0K
KyAgICAgICAgICovDQogICAgICAgICBwZW4gPSAoaW5mLT5zbGljZSAtIGluZi0+Y3B1dGltZSk7
DQogICAgICAgICBpZiAoIHBlbiA8IDAgKQ0KICAgICAgICAgICAgIHBlbiA9IDA7DQotICAgICAg
ICAvKmFjY3VtdWxhdGUgYWxsIHBlbmFsdGllcyBvdmVyIHRoZSBwZXJpb2RzKi8NCisgICAgICAg
IC8qIEFjY3VtdWxhdGUgYWxsIHBlbmFsdGllcyBvdmVyIHRoZSBwZXJpb2RzICovDQogICAgICAg
ICAvKmluZi0+c2hvcnRfYmxvY2tfbG9zdF90b3QgKz0gcGVuOyovDQotICAgICAgICAvKnNldCBw
ZW5hbHR5IHRvIHRoZSBjdXJyZW50IHZhbHVlKi8NCisgICAgICAgIC8qIFNldCBwZW5hbHR5IHRv
IHRoZSBjdXJyZW50IHZhbHVlICovDQogICAgICAgICBpbmYtPnNob3J0X2Jsb2NrX2xvc3RfdG90
ID0gcGVuOw0KLSAgICAgICAgLypub3Qgc3VyZSB3aGljaCBvbmUgaXMgYmV0dGVyLi4gYnV0IHNl
ZW1zIHRvIHdvcmsgd2VsbC4uLiovDQorICAgICAgICAvKiBOb3Qgc3VyZSB3aGljaCBvbmUgaXMg
YmV0dGVyLi4gYnV0IHNlZW1zIHRvIHdvcmsgd2VsbC4uLiAqLw0KICAgDQogICAgICAgICBpZiAo
IGluZi0+c2hvcnRfYmxvY2tfbG9zdF90b3QgKQ0KICAgICAgICAgew0KQEAgLTEwMDIsMjggKzk3
MSwzMSBAQCBzdGF0aWMgdm9pZCB1bmJsb2NrX3Nob3J0X2V4dHJhX3N1cHBvcnQoDQogICAgICAg
ICAgICAgaW5mLT5wZW5fZXh0cmFfYmxvY2tzKys7DQogI2VuZGlmDQogICAgICAgICAgICAgaWYg
KCBleHRyYXFfb24oaW5mLT52Y3B1LCBFWFRSQV9QRU5fUSkgKQ0KLSAgICAgICAgICAgICAgICAv
KnJlbW92ZSBkb21haW4gZm9yIHBvc3NpYmxlIHJlc29ydGluZyEqLw0KKyAgICAgICAgICAgICAg
ICAvKiBSZW1vdmUgZG9tYWluIGZvciBwb3NzaWJsZSByZXNvcnRpbmchICovDQogICAgICAgICAg
ICAgICAgIGV4dHJhcV9kZWwoaW5mLT52Y3B1LCBFWFRSQV9QRU5fUSk7DQogICAgICAgICAgICAg
ZWxzZQ0KLSAgICAgICAgICAgICAgICAvKnJlbWVtYmVyIHRoYXQgd2Ugd2FudCB0byBiZSBvbiB0
aGUgcGVuYWx0eSBxDQotICAgICAgICAgICAgICAgICAgc28gdGhhdCB3ZSBjYW4gY29udGludWUg
d2hlbiB3ZSAodW4tKWJsb2NrDQotICAgICAgICAgICAgICAgICAgaW4gcGVuYWx0eS1leHRyYXRp
bWUqLw0KKyAgICAgICAgICAgICAgICAvKg0KKyAgICAgICAgICAgICAgICAgKiBSZW1lbWJlciB0
aGF0IHdlIHdhbnQgdG8gYmUgb24gdGhlIHBlbmFsdHkgcQ0KKyAgICAgICAgICAgICAgICAgKiBz
byB0aGF0IHdlIGNhbiBjb250aW51ZSB3aGVuIHdlICh1bi0pYmxvY2sNCisgICAgICAgICAgICAg
ICAgICogaW4gcGVuYWx0eS1leHRyYXRpbWUNCisgICAgICAgICAgICAgICAgICovDQogICAgICAg
ICAgICAgICAgIGluZi0+c3RhdHVzIHw9IEVYVFJBX1dBTlRfUEVOX1E7DQogICAgDQotICAgICAg
ICAgICAgLyoocmUtKWFkZCBkb21haW4gdG8gdGhlIHBlbmFsdHkgZXh0cmFxKi8NCisgICAgICAg
ICAgICAvKiAocmUtKWFkZCBkb21haW4gdG8gdGhlIHBlbmFsdHkgZXh0cmFxICovDQogICAgICAg
ICAgICAgZXh0cmFxX2FkZF9zb3J0X3VwZGF0ZShpbmYtPnZjcHUsIEVYVFJBX1BFTl9RLCAwKTsN
CiAgICAgICAgIH0NCiAgICAgfQ0KIA0KLSAgICAvKmdpdmUgaXQgYSBmcmVzaCBzbGljZSBpbiB0
aGUgbmV4dCBwZXJpb2QhKi8NCisgICAgLyogR2l2ZSBpdCBhIGZyZXNoIHNsaWNlIGluIHRoZSBu
ZXh0IHBlcmlvZCEgKi8NCiAgICAgaW5mLT5jcHV0aW1lID0gMDsNCiB9DQogDQogDQogc3RhdGlj
IHZvaWQgdW5ibG9ja19sb25nX2NvbnNfYihzdHJ1Y3Qgc2VkZl92Y3B1X2luZm8qIGluZixzX3Rp
bWVfdCBub3cpDQogew0KLSAgICAvKkNvbnNlcnZhdGl2ZSAyYiovDQotICAgIC8qVHJlYXQgdGhl
IHVuYmxvY2tpbmcgdGltZSBhcyBhIHN0YXJ0IG9mIGEgbmV3IHBlcmlvZCAqLw0KKyAgICAvKiBD
b25zZXJ2YXRpdmUgMmIgKi8NCisNCisgICAgLyogVHJlYXQgdGhlIHVuYmxvY2tpbmcgdGltZSBh
cyBhIHN0YXJ0IG9mIGEgbmV3IHBlcmlvZCAqLw0KICAgICBpbmYtPmRlYWRsX2FicyA9IG5vdyAr
IGluZi0+cGVyaW9kOw0KICAgICBpbmYtPmNwdXRpbWUgPSAwOw0KIH0NCkBAIC0xMDQ2LDE1ICsx
MDE4LDE3IEBAIHN0YXRpYyBpbmxpbmUgaW50IGdldF9ydW5fdHlwZShzdHJ1Y3QgdmMNCiB9DQog
DQogDQotLypDb21wYXJlcyB0d28gZG9tYWlucyBpbiB0aGUgcmVsYXRpb24gb2Ygd2hldGhlciB0
aGUgb25lIGlzIGFsbG93ZWQgdG8NCi0gIGludGVycnVwdCB0aGUgb3RoZXJzIGV4ZWN1dGlvbi4N
Ci0gIEl0IHJldHVybnMgdHJ1ZSAoIT0wKSBpZiBhIHN3aXRjaCB0byB0aGUgb3RoZXIgZG9tYWlu
IGlzIGdvb2QuDQotICBDdXJyZW50IFByaW9yaXR5IHNjaGVtZSBpcyBhcyBmb2xsb3dzOg0KLSAg
IEVERiA+IEwwIChwZW5hbHR5IGJhc2VkKSBleHRyYS10aW1lID4gDQotICAgTDEgKHV0aWxpemF0
aW9uKSBleHRyYS10aW1lID4gaWRsZS1kb21haW4NCi0gIEluIHRoZSBzYW1lIGNsYXNzIHByaW9y
aXRpZXMgYXJlIGFzc2lnbmVkIGFzIGZvbGxvd2luZzoNCi0gICBFREY6IGVhcmx5IGRlYWRsaW5l
ID4gbGF0ZSBkZWFkbGluZQ0KLSAgIEwwIGV4dHJhLXRpbWU6IGxvd2VyIHNjb3JlID4gaGlnaGVy
IHNjb3JlKi8NCisvKg0KKyAqIENvbXBhcmVzIHR3byBkb21haW5zIGluIHRoZSByZWxhdGlvbiBv
ZiB3aGV0aGVyIHRoZSBvbmUgaXMgYWxsb3dlZCB0bw0KKyAqIGludGVycnVwdCB0aGUgb3RoZXJz
IGV4ZWN1dGlvbi4NCisgKiBJdCByZXR1cm5zIHRydWUgKCE9MCkgaWYgYSBzd2l0Y2ggdG8gdGhl
IG90aGVyIGRvbWFpbiBpcyBnb29kLg0KKyAqIEN1cnJlbnQgUHJpb3JpdHkgc2NoZW1lIGlzIGFz
IGZvbGxvd3M6DQorICogIEVERiA+IEwwIChwZW5hbHR5IGJhc2VkKSBleHRyYS10aW1lID4gDQor
ICogIEwxICh1dGlsaXphdGlvbikgZXh0cmEtdGltZSA+IGlkbGUtZG9tYWluDQorICogSW4gdGhl
IHNhbWUgY2xhc3MgcHJpb3JpdGllcyBhcmUgYXNzaWduZWQgYXMgZm9sbG93aW5nOg0KKyAqICBF
REY6IGVhcmx5IGRlYWRsaW5lID4gbGF0ZSBkZWFkbGluZQ0KKyAqICBMMCBleHRyYS10aW1lOiBs
b3dlciBzY29yZSA+IGhpZ2hlciBzY29yZQ0KKyAqLw0KIHN0YXRpYyBpbmxpbmUgaW50IHNob3Vs
ZF9zd2l0Y2goc3RydWN0IHZjcHUgKmN1ciwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIHN0cnVjdCB2Y3B1ICpvdGhlciwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
IHNfdGltZV90IG5vdykNCkBAIC0xMDYzLDI2ICsxMDM3LDI1IEBAIHN0YXRpYyBpbmxpbmUgaW50
IHNob3VsZF9zd2l0Y2goc3RydWN0IHYNCiAgICAgY3VyX2luZiAgID0gRURPTV9JTkZPKGN1cik7
DQogICAgIG90aGVyX2luZiA9IEVET01fSU5GTyhvdGhlcik7DQogIA0KLSAgICAvKiBDaGVjayB3
aGV0aGVyIHdlIG5lZWQgdG8gbWFrZSBhbiBlYXJsaWVyIHNjaGVkdWxpbmcgZGVjaXNpb24uICov
DQorICAgIC8qIENoZWNrIHdoZXRoZXIgd2UgbmVlZCB0byBtYWtlIGFuIGVhcmxpZXIgc2NoZWR1
bGluZyBkZWNpc2lvbiAqLw0KICAgICBpZiAoIFBFUklPRF9CRUdJTihvdGhlcl9pbmYpIDwgDQog
ICAgICAgICAgQ1BVX0lORk8ob3RoZXItPnByb2Nlc3NvciktPmN1cnJlbnRfc2xpY2VfZXhwaXJl
cyApDQogICAgICAgICByZXR1cm4gMTsNCiANCi0gICAgLyogTm8gdGltaW5nLWJhc2VkIHN3aXRj
aGVzIG5lZWQgdG8gYmUgdGFrZW4gaW50byBhY2NvdW50IGhlcmUuICovDQorICAgIC8qIE5vIHRp
bWluZy1iYXNlZCBzd2l0Y2hlcyBuZWVkIHRvIGJlIHRha2VuIGludG8gYWNjb3VudCBoZXJlICov
DQogICAgIHN3aXRjaCAoIGdldF9ydW5fdHlwZShjdXIpICkNCiAgICAgew0KICAgICBjYXNlIERP
TUFJTl9FREY6DQotICAgICAgICAvKiBEbyBub3QgaW50ZXJydXB0IGEgcnVubmluZyBFREYgZG9t
YWluLiAqLw0KKyAgICAgICAgLyogRG8gbm90IGludGVycnVwdCBhIHJ1bm5pbmcgRURGIGRvbWFp
biAqLw0KICAgICAgICAgcmV0dXJuIDA7DQogICAgIGNhc2UgRE9NQUlOX0VYVFJBX1BFTjoNCi0g
ICAgICAgIC8qIENoZWNrIHdoZXRoZXIgd2UgYWxzbyB3YW50IHRoZSBMMCBleC1xIHdpdGggbG93
ZXIgc2NvcmUuICovDQorICAgICAgICAvKiBDaGVjayB3aGV0aGVyIHdlIGFsc28gd2FudCB0aGUg
TDAgZXgtcSB3aXRoIGxvd2VyIHNjb3JlICovDQogICAgICAgICByZXR1cm4gKChvdGhlcl9pbmYt
PnN0YXR1cyAmIEVYVFJBX1dBTlRfUEVOX1EpICYmDQogICAgICAgICAgICAgICAgIChvdGhlcl9p
bmYtPnNjb3JlW0VYVFJBX1BFTl9RXSA8IA0KICAgICAgICAgICAgICAgICAgY3VyX2luZi0+c2Nv
cmVbRVhUUkFfUEVOX1FdKSk7DQogICAgIGNhc2UgRE9NQUlOX0VYVFJBX1VUSUw6DQogICAgICAg
ICAvKiBDaGVjayB3aGV0aGVyIHdlIHdhbnQgdGhlIEwwIGV4dHJhcS4gRG9uJ3QNCi0gICAgICAg
ICAqIHN3aXRjaCBpZiBib3RoIGRvbWFpbnMgd2FudCBMMSBleHRyYXEuDQotICAgICAgICAgKi8N
CisgICAgICAgICAqIHN3aXRjaCBpZiBib3RoIGRvbWFpbnMgd2FudCBMMSBleHRyYXEuICovDQog
ICAgICAgICByZXR1cm4gISEob3RoZXJfaW5mLT5zdGF0dXMgJiBFWFRSQV9XQU5UX1BFTl9RKTsN
CiAgICAgY2FzZSBET01BSU5fSURMRToNCiAgICAgICAgIHJldHVybiAxOw0KQEAgLTEwOTYsMTgg
KzEwNjksMTEgQEAgc3RhdGljIHZvaWQgc2VkZl93YWtlKGNvbnN0IHN0cnVjdCBzY2hlZA0KICAg
ICBzX3RpbWVfdCAgICAgICAgICAgICAgbm93ID0gTk9XKCk7DQogICAgIHN0cnVjdCBzZWRmX3Zj
cHVfaW5mbyogaW5mID0gRURPTV9JTkZPKGQpOw0KIA0KLSAgICBQUklOVCgzLCAic2VkZl93YWtl
IHdhcyBjYWxsZWQsIGRvbWFpbi1pZCAlaS4laVxuIixkLT5kb21haW4tPmRvbWFpbl9pZCwNCi0g
ICAgICAgICAgZC0+dmNwdV9pZCk7DQotDQogICAgIGlmICggdW5saWtlbHkoaXNfaWRsZV92Y3B1
KGQpKSApDQogICAgICAgICByZXR1cm47DQogICAgDQogICAgIGlmICggdW5saWtlbHkoX190YXNr
X29uX3F1ZXVlKGQpKSApDQotICAgIHsNCi0gICAgICAgIFBSSU5UKDMsIlx0ZG9tYWluICVpLiVp
IGlzIGFscmVhZHkgaW4gc29tZSBxdWV1ZVxuIiwNCi0gICAgICAgICAgICAgIGQtPmRvbWFpbi0+
ZG9tYWluX2lkLCBkLT52Y3B1X2lkKTsNCiAgICAgICAgIHJldHVybjsNCi0gICAgfQ0KIA0KICAg
ICBBU1NFUlQoIXNlZGZfcnVubmFibGUoZCkpOw0KICAgICBpbmYtPnN0YXR1cyAmPSB+U0VERl9B
U0xFRVA7DQpAQCAtMTExNiwyOCArMTA4MiwyNSBAQCBzdGF0aWMgdm9pZCBzZWRmX3dha2UoY29u
c3Qgc3RydWN0IHNjaGVkDQogIA0KICAgICBpZiAoIHVubGlrZWx5KGluZi0+ZGVhZGxfYWJzID09
IDApICkNCiAgICAgew0KLSAgICAgICAgLyppbml0aWFsIHNldHVwIG9mIHRoZSBkZWFkbGluZSov
DQorICAgICAgICAvKiBJbml0aWFsIHNldHVwIG9mIHRoZSBkZWFkbGluZSAqLw0KICAgICAgICAg
aW5mLT5kZWFkbF9hYnMgPSBub3cgKyBpbmYtPnNsaWNlOw0KICAgICB9DQogICANCi0gICAgUFJJ
TlQoMywgIndha2luZyB1cCBkb21haW4gJWkuJWkgKGRlYWRsPSAlIlBSSXU2NCIgcGVyaW9kPSAl
IlBSSXU2NA0KLSAgICAgICAgICAibm93PSAlIlBSSXU2NCIpXG4iLA0KLSAgICAgICAgICBkLT5k
b21haW4tPmRvbWFpbl9pZCwgZC0+dmNwdV9pZCwgaW5mLT5kZWFkbF9hYnMsIGluZi0+cGVyaW9k
LCBub3cpOw0KLQ0KICNpZmRlZiBTRURGX1NUQVRTIA0KICAgICBpbmYtPmJsb2NrX3RvdCsrOw0K
ICNlbmRpZg0KIA0KICAgICBpZiAoIHVubGlrZWx5KG5vdyA8IFBFUklPRF9CRUdJTihpbmYpKSAp
DQogICAgIHsNCi0gICAgICAgIFBSSU5UKDQsImV4dHJhdGltZSB1bmJsb2NrXG4iKTsNCi0gICAg
ICAgIC8qIHVuYmxvY2tpbmcgaW4gZXh0cmEtdGltZSEgKi8NCisgICAgICAgIC8qIFVuYmxvY2tp
bmcgaW4gZXh0cmEtdGltZSEgKi8NCiAgICAgICAgIGlmICggaW5mLT5zdGF0dXMgJiBFWFRSQV9X
QU5UX1BFTl9RICkNCiAgICAgICAgIHsNCi0gICAgICAgICAgICAvKndlIGhhdmUgYSBkb21haW4g
dGhhdCB3YW50cyBjb21wZW5zYXRpb24NCi0gICAgICAgICAgICAgIGZvciBibG9jayBwZW5hbHR5
IGFuZCBkaWQganVzdCBibG9jayBpbg0KLSAgICAgICAgICAgICAgaXRzIGNvbXBlbnNhdGlvbiB0
aW1lLiBHaXZlIGl0IGFub3RoZXINCi0gICAgICAgICAgICAgIGNoYW5jZSEqLw0KKyAgICAgICAg
ICAgIC8qDQorICAgICAgICAgICAgICogV2UgaGF2ZSBhIGRvbWFpbiB0aGF0IHdhbnRzIGNvbXBl
bnNhdGlvbg0KKyAgICAgICAgICAgICAqIGZvciBibG9jayBwZW5hbHR5IGFuZCBkaWQganVzdCBi
bG9jayBpbg0KKyAgICAgICAgICAgICAqIGl0cyBjb21wZW5zYXRpb24gdGltZS4gR2l2ZSBpdCBh
bm90aGVyDQorICAgICAgICAgICAgICogY2hhbmNlIQ0KKyAgICAgICAgICAgICAqLw0KICAgICAg
ICAgICAgIGV4dHJhcV9hZGRfc29ydF91cGRhdGUoZCwgRVhUUkFfUEVOX1EsIDApOw0KICAgICAg
ICAgfQ0KICAgICAgICAgZXh0cmFxX2NoZWNrX2FkZF91bmJsb2NrZWQoZCwgMCk7DQpAQCAtMTE0
Niw4ICsxMTA5LDcgQEAgc3RhdGljIHZvaWQgc2VkZl93YWtlKGNvbnN0IHN0cnVjdCBzY2hlZA0K
ICAgICB7ICANCiAgICAgICAgIGlmICggbm93IDwgaW5mLT5kZWFkbF9hYnMgKQ0KICAgICAgICAg
ew0KLSAgICAgICAgICAgIFBSSU5UKDQsInNob3J0IHVuYmxvY2tpbmdcbiIpOw0KLSAgICAgICAg
ICAgIC8qc2hvcnQgYmxvY2tpbmcqLw0KKyAgICAgICAgICAgIC8qIFNob3J0IGJsb2NraW5nICov
DQogI2lmZGVmIFNFREZfU1RBVFMNCiAgICAgICAgICAgICBpbmYtPnNob3J0X2Jsb2NrX3RvdCsr
Ow0KICNlbmRpZg0KQEAgLTExNTcsOCArMTExOSw3IEBAIHN0YXRpYyB2b2lkIHNlZGZfd2FrZShj
b25zdCBzdHJ1Y3Qgc2NoZWQNCiAgICAgICAgIH0NCiAgICAgICAgIGVsc2UNCiAgICAgICAgIHsN
Ci0gICAgICAgICAgICBQUklOVCg0LCJsb25nIHVuYmxvY2tpbmdcbiIpOw0KLSAgICAgICAgICAg
IC8qbG9uZyB1bmJsb2NraW5nKi8NCisgICAgICAgICAgICAvKiBMb25nIHVuYmxvY2tpbmcgKi8N
CiAjaWZkZWYgU0VERl9TVEFUUw0KICAgICAgICAgICAgIGluZi0+bG9uZ19ibG9ja190b3QrKzsN
CiAjZW5kaWYNCkBAIC0xMTY4LDI0ICsxMTI5LDEzIEBAIHN0YXRpYyB2b2lkIHNlZGZfd2FrZShj
b25zdCBzdHJ1Y3Qgc2NoZWQNCiAgICAgICAgIH0NCiAgICAgfQ0KIA0KLSAgICBQUklOVCgzLCAi
d29rZSB1cCBkb21haW4gJWkuJWkgKGRlYWRsPSAlIlBSSXU2NCIgcGVyaW9kPSAlIlBSSXU2NA0K
LSAgICAgICAgICAibm93PSAlIlBSSXU2NCIpXG4iLA0KLSAgICAgICAgICBkLT5kb21haW4tPmRv
bWFpbl9pZCwgZC0+dmNwdV9pZCwgaW5mLT5kZWFkbF9hYnMsDQotICAgICAgICAgIGluZi0+cGVy
aW9kLCBub3cpOw0KLQ0KICAgICBpZiAoIFBFUklPRF9CRUdJTihpbmYpID4gbm93ICkNCi0gICAg
ew0KICAgICAgICAgX19hZGRfdG9fd2FpdHF1ZXVlX3NvcnQoZCk7DQotICAgICAgICBQUklOVCgz
LCJhZGRlZCB0byB3YWl0cVxuIik7DQotICAgIH0NCiAgICAgZWxzZQ0KLSAgICB7DQogICAgICAg
ICBfX2FkZF90b19ydW5xdWV1ZV9zb3J0KGQpOw0KLSAgICAgICAgUFJJTlQoMywiYWRkZWQgdG8g
cnVucVxuIik7DQotICAgIH0NCiAgDQogI2lmZGVmIFNFREZfU1RBVFMNCi0gICAgLypkbyBzb21l
IHN0YXRpc3RpY3MgaGVyZS4uLiovDQorICAgIC8qIERvIHNvbWUgc3RhdGlzdGljcyBoZXJlLi4u
ICovDQogICAgIGlmICggaW5mLT5ibG9ja19hYnMgIT0gMCApDQogICAgIHsNCiAgICAgICAgIGlu
Zi0+YmxvY2tfdGltZV90b3QgKz0gbm93IC0gaW5mLT5ibG9ja19hYnM7DQpAQCAtMTE5NCwxMiAr
MTE0NCwxNCBAQCBzdGF0aWMgdm9pZCBzZWRmX3dha2UoY29uc3Qgc3RydWN0IHNjaGVkDQogICAg
IH0NCiAjZW5kaWYNCiANCi0gICAgLypzYW5pdHkgY2hlY2s6IG1ha2Ugc3VyZSBlYWNoIGV4dHJh
LWF3YXJlIGRvbWFpbiBJUyBvbiB0aGUgdXRpbC1xISovDQorICAgIC8qIFNhbml0eSBjaGVjazog
bWFrZSBzdXJlIGVhY2ggZXh0cmEtYXdhcmUgZG9tYWluIElTIG9uIHRoZSB1dGlsLXEhICovDQog
ICAgIEFTU0VSVChJTVBMWShpbmYtPnN0YXR1cyAmIEVYVFJBX0FXQVJFLCBleHRyYXFfb24oZCwg
RVhUUkFfVVRJTF9RKSkpOw0KICAgICBBU1NFUlQoX190YXNrX29uX3F1ZXVlKGQpKTsNCi0gICAg
LypjaGVjayB3aGV0aGVyIHRoZSBhd2FrZW5lZCB0YXNrIG5lZWRzIHRvIGludm9rZSB0aGUgZG9f
c2NoZWR1bGUNCi0gICAgICByb3V0aW5lLiBUcnkgdG8gYXZvaWQgdW5uZWNlc3NhcnkgcnVucyBi
dXQ6DQotICAgICAgU2F2ZSBhcHByb3hpbWF0aW9uOiBBbHdheXMgc3dpdGNoIHRvIHNjaGVkdWxl
ciEqLw0KKyAgICAvKg0KKyAgICAgKiBDaGVjayB3aGV0aGVyIHRoZSBhd2FrZW5lZCB0YXNrIG5l
ZWRzIHRvIGludm9rZSB0aGUgZG9fc2NoZWR1bGUNCisgICAgICogcm91dGluZS4gVHJ5IHRvIGF2
b2lkIHVubmVjZXNzYXJ5IHJ1bnMgYnV0Og0KKyAgICAgKiBTYXZlIGFwcHJveGltYXRpb246IEFs
d2F5cyBzd2l0Y2ggdG8gc2NoZWR1bGVyIQ0KKyAgICAgKi8NCiAgICAgQVNTRVJUKGQtPnByb2Nl
c3NvciA+PSAwKTsNCiAgICAgQVNTRVJUKGQtPnByb2Nlc3NvciA8IG5yX2NwdV9pZHMpOw0KICAg
ICBBU1NFUlQocGVyX2NwdShzY2hlZHVsZV9kYXRhLCBkLT5wcm9jZXNzb3IpLmN1cnIpOw0KQEAg
LTEyNDQsNyArMTE5Niw3IEBAIHN0YXRpYyB2b2lkIHNlZGZfZHVtcF9kb21haW4oc3RydWN0IHZj
cHUNCiB9DQogDQogDQotLyogZHVtcHMgYWxsIGRvbWFpbnMgb24gdGhlIHNwZWNpZmllZCBjcHUg
Ki8NCisvKiBEdW1wcyBhbGwgZG9tYWlucyBvbiB0aGUgc3BlY2lmaWVkIGNwdSAqLw0KIHN0YXRp
YyB2b2lkIHNlZGZfZHVtcF9jcHVfc3RhdGUoY29uc3Qgc3RydWN0IHNjaGVkdWxlciAqb3BzLCBp
bnQgaSkNCiB7DQogICAgIHN0cnVjdCBsaXN0X2hlYWQgICAgICAqbGlzdCwgKnF1ZXVlLCAqdG1w
Ow0KQEAgLTEzMTksNyArMTI3MSw3IEBAIHN0YXRpYyB2b2lkIHNlZGZfZHVtcF9jcHVfc3RhdGUo
Y29uc3Qgc3QNCiB9DQogDQogDQotLyogQWRqdXN0cyBwZXJpb2RzIGFuZCBzbGljZXMgb2YgdGhl
IGRvbWFpbnMgYWNjb3JkaW5nbHkgdG8gdGhlaXIgd2VpZ2h0cy4gKi8NCisvKiBBZGp1c3RzIHBl
cmlvZHMgYW5kIHNsaWNlcyBvZiB0aGUgZG9tYWlucyBhY2NvcmRpbmdseSB0byB0aGVpciB3ZWln
aHRzICovDQogc3RhdGljIGludCBzZWRmX2FkanVzdF93ZWlnaHRzKHN0cnVjdCBjcHVwb29sICpj
LCBzdHJ1Y3QgeGVuX2RvbWN0bF9zY2hlZHVsZXJfb3AgKmNtZCkNCiB7DQogICAgIHN0cnVjdCB2
Y3B1ICpwOw0KQEAgLTEzMzUsNyArMTI4Nyw3IEBAIHN0YXRpYyBpbnQgc2VkZl9hZGp1c3Rfd2Vp
Z2h0cyhzdHJ1Y3QgY3ANCiAgICAgICAgIHJldHVybiAtRU5PTUVNOw0KICAgICB9DQogDQotICAg
IC8qIFN1bSBhY3Jvc3MgYWxsIHdlaWdodHMuICovDQorICAgIC8qIFN1bSBhY3Jvc3MgYWxsIHdl
aWdodHMgKi8NCiAgICAgcmN1X3JlYWRfbG9jaygmZG9tbGlzdF9yZWFkX2xvY2spOw0KICAgICBm
b3JfZWFjaF9kb21haW5faW5fY3B1cG9vbCggZCwgYyApDQogICAgIHsNCkBAIC0xMzUwLDExICsx
MzAyLDE0IEBAIHN0YXRpYyBpbnQgc2VkZl9hZGp1c3Rfd2VpZ2h0cyhzdHJ1Y3QgY3ANCiAgICAg
ICAgICAgICB9DQogICAgICAgICAgICAgZWxzZQ0KICAgICAgICAgICAgIHsNCi0gICAgICAgICAg
ICAgICAgLypkb24ndCBtb2RpZnkgZG9tYWlucyB3aG8gZG9uJ3QgaGF2ZSBhIHdlaWdodCwgYnV0
IHN1bQ0KLSAgICAgICAgICAgICAgICAgIHVwIHRoZSB0aW1lIHRoZXkgbmVlZCwgcHJvamVjdGVk
IHRvIGEgV0VJR0hUX1BFUklPRCwNCi0gICAgICAgICAgICAgICAgICBzbyB0aGF0IHRoaXMgdGlt
ZSBpcyBub3QgZ2l2ZW4gdG8gdGhlIHdlaWdodC1kcml2ZW4NCi0gICAgICAgICAgICAgICAgICBk
b21haW5zKi8NCi0gICAgICAgICAgICAgICAgLypjaGVjayBmb3Igb3ZlcmZsb3dzKi8NCisgICAg
ICAgICAgICAgICAgLyoNCisgICAgICAgICAgICAgICAgICogRG9uJ3QgbW9kaWZ5IGRvbWFpbnMg
d2hvIGRvbid0IGhhdmUgYSB3ZWlnaHQsIGJ1dCBzdW0NCisgICAgICAgICAgICAgICAgICogdXAg
dGhlIHRpbWUgdGhleSBuZWVkLCBwcm9qZWN0ZWQgdG8gYSBXRUlHSFRfUEVSSU9ELA0KKyAgICAg
ICAgICAgICAgICAgKiBzbyB0aGF0IHRoaXMgdGltZSBpcyBub3QgZ2l2ZW4gdG8gdGhlIHdlaWdo
dC1kcml2ZW4NCisgICAgICAgICAgICAgICAgICogIGRvbWFpbnMNCisgICAgICAgICAgICAgICAg
ICovDQorDQorICAgICAgICAgICAgICAgIC8qIENoZWNrIGZvciBvdmVyZmxvd3MgKi8NCiAgICAg
ICAgICAgICAgICAgQVNTRVJUKChXRUlHSFRfUEVSSU9EIDwgVUxPTkdfTUFYKSANCiAgICAgICAg
ICAgICAgICAgICAgICAgICYmIChFRE9NX0lORk8ocCktPnNsaWNlX29yaWcgPCBVTE9OR19NQVgp
KTsNCiAgICAgICAgICAgICAgICAgc3VtdFtjcHVdICs9IA0KQEAgLTEzNjUsNyArMTMyMCw3IEBA
IHN0YXRpYyBpbnQgc2VkZl9hZGp1c3Rfd2VpZ2h0cyhzdHJ1Y3QgY3ANCiAgICAgfQ0KICAgICBy
Y3VfcmVhZF91bmxvY2soJmRvbWxpc3RfcmVhZF9sb2NrKTsNCiANCi0gICAgLyogQWRqdXN0IGFs
bCBzbGljZXMgKGFuZCBwZXJpb2RzKSB0byB0aGUgbmV3IHdlaWdodC4gKi8NCisgICAgLyogQWRq
dXN0IGFsbCBzbGljZXMgKGFuZCBwZXJpb2RzKSB0byB0aGUgbmV3IHdlaWdodCAqLw0KICAgICBy
Y3VfcmVhZF9sb2NrKCZkb21saXN0X3JlYWRfbG9jayk7DQogICAgIGZvcl9lYWNoX2RvbWFpbl9p
bl9jcHVwb29sKCBkLCBjICkNCiAgICAgew0KQEAgLTEzOTMsMjAgKzEzNDgsMTUgQEAgc3RhdGlj
IGludCBzZWRmX2FkanVzdF93ZWlnaHRzKHN0cnVjdCBjcA0KIH0NCiANCiANCi0vKiBzZXQgb3Ig
ZmV0Y2ggZG9tYWluIHNjaGVkdWxpbmcgcGFyYW1ldGVycyAqLw0KKy8qIFNldCBvciBmZXRjaCBk
b21haW4gc2NoZWR1bGluZyBwYXJhbWV0ZXJzICovDQogc3RhdGljIGludCBzZWRmX2FkanVzdChj
b25zdCBzdHJ1Y3Qgc2NoZWR1bGVyICpvcHMsIHN0cnVjdCBkb21haW4gKnAsIHN0cnVjdCB4ZW5f
ZG9tY3RsX3NjaGVkdWxlcl9vcCAqb3ApDQogew0KICAgICBzdHJ1Y3QgdmNwdSAqdjsNCiAgICAg
aW50IHJjOw0KIA0KLSAgICBQUklOVCgyLCJzZWRmX2FkanVzdCB3YXMgY2FsbGVkLCBkb21haW4t
aWQgJWkgbmV3IHBlcmlvZCAlIlBSSXU2NCIgIg0KLSAgICAgICAgICAibmV3IHNsaWNlICUiUFJJ
dTY0IlxubGF0ZW5jeSAlIlBSSXU2NCIgZXh0cmE6JXNcbiIsDQotICAgICAgICAgIHAtPmRvbWFp
bl9pZCwgb3AtPnUuc2VkZi5wZXJpb2QsIG9wLT51LnNlZGYuc2xpY2UsDQotICAgICAgICAgIG9w
LT51LnNlZGYubGF0ZW5jeSwgKG9wLT51LnNlZGYuZXh0cmF0aW1lKT8ieWVzIjoibm8iKTsNCi0N
CiAgICAgaWYgKCBvcC0+Y21kID09IFhFTl9ET01DVExfU0NIRURPUF9wdXRpbmZvICkNCiAgICAg
ew0KLSAgICAgICAgLyogQ2hlY2sgZm9yIHNhbmUgcGFyYW1ldGVycy4gKi8NCisgICAgICAgIC8q
IENoZWNrIGZvciBzYW5lIHBhcmFtZXRlcnMgKi8NCiAgICAgICAgIGlmICggIW9wLT51LnNlZGYu
cGVyaW9kICYmICFvcC0+dS5zZWRmLndlaWdodCApDQogICAgICAgICAgICAgcmV0dXJuIC1FSU5W
QUw7DQogICAgICAgICBpZiAoIG9wLT51LnNlZGYud2VpZ2h0ICkNCkBAIC0xNDE0LDcgKzEzNjQs
NyBAQCBzdGF0aWMgaW50IHNlZGZfYWRqdXN0KGNvbnN0IHN0cnVjdCBzY2hlDQogICAgICAgICAg
ICAgaWYgKCAob3AtPnUuc2VkZi5leHRyYXRpbWUgJiBFWFRSQV9BV0FSRSkgJiYNCiAgICAgICAg
ICAgICAgICAgICghb3AtPnUuc2VkZi5wZXJpb2QpICkNCiAgICAgICAgICAgICB7DQotICAgICAg
ICAgICAgICAgIC8qIFdlaWdodC1kcml2ZW4gZG9tYWlucyB3aXRoIGV4dHJhdGltZSBvbmx5LiAq
Lw0KKyAgICAgICAgICAgICAgICAvKiBXZWlnaHQtZHJpdmVuIGRvbWFpbnMgd2l0aCBleHRyYXRp
bWUgb25seSAqLw0KICAgICAgICAgICAgICAgICBmb3JfZWFjaF92Y3B1ICggcCwgdiApDQogICAg
ICAgICAgICAgICAgIHsNCiAgICAgICAgICAgICAgICAgICAgIEVET01fSU5GTyh2KS0+ZXh0cmF3
ZWlnaHQgPSBvcC0+dS5zZWRmLndlaWdodDsNCkBAIC0xNDI1LDcgKzEzNzUsNyBAQCBzdGF0aWMg
aW50IHNlZGZfYWRqdXN0KGNvbnN0IHN0cnVjdCBzY2hlDQogICAgICAgICAgICAgfQ0KICAgICAg
ICAgICAgIGVsc2UNCiAgICAgICAgICAgICB7DQotICAgICAgICAgICAgICAgIC8qIFdlaWdodC1k
cml2ZW4gZG9tYWlucyB3aXRoIHJlYWwtdGltZSBleGVjdXRpb24uICovDQorICAgICAgICAgICAg
ICAgIC8qIFdlaWdodC1kcml2ZW4gZG9tYWlucyB3aXRoIHJlYWwtdGltZSBleGVjdXRpb24gKi8N
CiAgICAgICAgICAgICAgICAgZm9yX2VhY2hfdmNwdSAoIHAsIHYgKQ0KICAgICAgICAgICAgICAg
ICAgICAgRURPTV9JTkZPKHYpLT53ZWlnaHQgPSBvcC0+dS5zZWRmLndlaWdodDsNCiAgICAgICAg
ICAgICB9DQpAQCAtMTQ3Nyw3ICsxNDI3LDYgQEAgc3RhdGljIGludCBzZWRmX2FkanVzdChjb25z
dCBzdHJ1Y3Qgc2NoZQ0KICAgICAgICAgb3AtPnUuc2VkZi53ZWlnaHQgICAgPSBFRE9NX0lORk8o
cC0+dmNwdVswXSktPndlaWdodDsNCiAgICAgfQ0KIA0KLSAgICBQUklOVCgyLCJzZWRmX2FkanVz
dF9maW5pc2hlZFxuIik7DQogICAgIHJldHVybiAwOw0KIH0NCiANCm==


--=-DM3xwBkUsBWsFUckworM--

--=-oVXZhmqkWYbyP3+4MWM6
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEABECAAYFAk7yA2EACgkQk4XaBE3IOsQjHgCgokeOKmICEG21IO9eF+nOwRTE
4HYAoJlFaHcaHVJZC2nqIqROHfizcSkc
=ZkFV
-----END PGP SIGNATURE-----

--=-oVXZhmqkWYbyP3+4MWM6--



--===============2284887627372470128==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============2284887627372470128==--



From xen-devel-bounces@lists.xensource.com Wed Dec 21 16:04:29 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 16: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.xensource.com>)
	id 1RdOe8-000192-1r; Wed, 21 Dec 2011 16:04:00 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1RdOe6-00018l-8C
	for xen-devel@lists.xensource.com; Wed, 21 Dec 2011 16:03:59 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-13.tower-27.messagelabs.com!1324483403!53094887!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=1.1 required=7.0 tests=BODY_RANDOM_LONG,DIET_1
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10443 invoked from network); 21 Dec 2011 16:03:24 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-13.tower-27.messagelabs.com with SMTP;
	21 Dec 2011 16:03:24 -0000
Received: from [83.211.178.94] (account d.faggioli@sssup.it HELO
	[192.168.0.20]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 74086552; Wed, 21 Dec 2011 17:03:46 +0100
Message-ID: <1324483425.4366.43.camel@Abyss>
From: Dario Faggioli <raistlin@linux.it>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Wed, 21 Dec 2011 17:03:45 +0100
Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwCAIAAADYYG7QAAAAA3NCSVQICAjb4U/gAAAVx0lEQVRYwzWY6a/d953XP9/tt51zfme/+37t692OtzhxtzTuJFPaTDVt0cDQeTIajToSKBJICBASQkI8Q1Q8ACQEhUGgCsF0OrSkaRLaxknqOl7i9dq++3727bd/Vx5k+CNe7+WFvvkvbvoywAZF1BMYOFNFbqWEW1gho42yB9jJq1QihEGVCh7BxrXpeNlxbJZmcmNvkArIhAIMJd+drlmA0aiXuBbN5x3Pxq6NS6X85l5/rxNnGtJYgAYhgVCa8UxqAwgQIABAGGMD1JWtS7/48Vy0W1k5GxXnmh41br1y6fxXv3LCEPXLu3vv3N3t2kXPAi0EIjTjnDGcKawzHceZl3N0mIExrmfnGS1iSij2pxgDxJhlsOFID8LUsVjecXvNPiJg2ZYySiODGUVcAwBCCAAMAIAhNc82C2xvuLG8uX422VvZfHrx9Mz5P7kRR51wby188YD+8metqQWBLa00F1JIlQk5imIhle+XBsHI9/PVUoFCBp7JOZbSjGiS92mx7IE0SICRkC/Yw2GSZECpIsYYwEmWGkDGIAAAAIQAY4QMEA6Nvc7G6aaYzKQlUs/x/O99VywsZcZd33w++l9/NbN6Z905MSqPGYO10QDYGCI1EIQQGMdzkzCo+G4pb5eY7blWKhKadiZ92yYsFWoYpwhRv0A4h/4oK5Zcl9nGAMLUgEYYMAZAmhBkM6KkoYpVIRjU47SRRUuVlXRlUZ08nxDyi50na+2jV1r9tTjK/DwYqgFRLHMuYdhCMou1bg64a0M15yKiCyCcLJlJspl+e6x3QNtuv1TbKIwHxpHIZDEYorGFh32eK3h+yc06XYqA2MyyLCmk0lobAFC04NsTyCGjOAbrp5svrs/N1sqeRegKscrF2aiz1ZfJweZPjLzojB0fdPcqFcv481592Y15KiKOLBDyd
	OPw1b37JZ3Qosdspk2Eh71iZ3MmJafLE/2l4w/pjBiiRMVJKjOtLItypb18LkxCmSilAIAorQCA0nLl0lGSqY5kyCP55bFpOwvW1vo79+7vb+z5yjSF1Wg9RaNNjKxRlObPnd/c+UurPFMZPzO5cPpcIt/c/HApaZp+Jzoa6FKhcu4kogzZFGmEGgczG6v1O+8uLp1eQ0VdOrXuLFqu0mAwwZkUCBOMmJAKDAIgAJq88f1/NucwtbZqaXP9pfNnFxY++ujmI4OZVzoYHfKtxnrY2PFAS46yuJTPNzvNYXvbDJsvTfr/5PSJl3/676cbhzvPV4ccbN9KTCoHHYa5xQoZRPpglw1SEim5tzN58KSc4b1LFzEmFiMEYwCSca01MsYAAoyRUYrGgjXOXfgbg8aE5hPV8vsPPr7XHJaPn4x6MY0GjsUWvnxy+dLSB7+43W6zN77y9Q/e/3ENvMvI/dO4WftX/xzidDvrO7Mnxqt+P0kshcCyRj2pe89zKSKxVjrWWKs4balUO/s26MwgqZU2JsmkUhjAAPpr0ACA3vjKydHuAa56B2u7Hz59qDFOkD149x1n9VkW81LevvCH54b5ztiY/+rLr7zxu1+TwdEr99deD0Ln1tMw4ixVhVpuemZGYT5W8JQCgyAMR1whY1IGqRI8E1ks0m2pnqq0k6ogUpgRroBLDQgjDBgTjAEUUgDUJI16Se7sbcWdfoxdzrRUwj7aV1I7165Mnjhx+oLz2+CTyclL3/2D74ApfOFr3w4Hf7778/dmSclIzoXKTy6n2QBrjRQyBPdGQ6RVlCQ8TXScMGk8iwWErsV8Z/58J9KZ0IgbBJgQiok2BghBCCFjMACQlesvrzjY/tWtOM0EoZwCU0Ym2ag+VZ5fLOf9xZXph61s8dibtdpYnApmFe3JmX6372UByfg+wKNOt+hYSgHBNjiesW3H9SyhqEKJlE2ZHiSjrVS2c8Xm639nhEoACAzGhDCGKSVKGQ
	AwBgECxQXNuz7uD1QvQFJEeeOm0iiFBbDu/uEzwW8O+P826hu/d6v0/PTx5Y8/ee/l66/lFqdqb9xQ//pRJ+KBwfmp8U1tmkgnXqaxbPd6/V4fJ1kJ6JQhderZ1OvE/aYSfeKBAYSQQVgbI5Q2UgMgBMgYAxgBAE1U6uQKuS9e7310qzwQ2pDUghR4JU3UZji07BfFamHtIF00O839zx7ceeXaFxGY/J1Hz1sHPEGHDlnTreLkyeNXrpQLDgjtBHF+GI6i4VEYfnpwpAejvNBnUdG2qkBdw4w2Bhv0eXeZzwMfIYQ+7zKgc7VynCux73176ktXV//ix6Onq67RxIhEGTDSHybQH4Xt6LU3317f2pycmGJUVxudOZ+o6Zn764dB0YHx6dCwp88eIYSIxpLLIIziLJbSOAKEW9QlZ7Posijv5awsSw1yDMIAGMAgZBBCGGNjDEJGAdCJnI9thwHLFr3pt9+e3Wl2W41fbj1NlD51sHvmxeP1YfqMya9fvfaf//E/3T/cfPP6K8vv3Wz/3w/SxiBPaDFUeGZ6V2Sd7UOtACmkpeRSaI0wMogZYzNk05KfG5Z8q5a9bBeaA90P0kRixGyuPqddY4wwQgKAFosVQjEANjF1lFIz4/1x50g0kyR+uVi79jtf/vmHL4LKhZ7WreYWMbH5b/8zu3vHGkUZlxjrSOkzy/Px/n5fYxAxNUCNIdhIojEhmDFM3By2sWdJNlajeKmUnqiwQNuRZJ0I398LDVBkABPABgEA7o/CMEhlplzHKlZL1WJVY4LB5Ci6+p2rvRv1uxm8evba/Qe/UaPuDUEXP/kNTdJewqtV/+zlK9yQnfWtdrsVp+koEWEmpQELUwcTqrGMVZpEiUqVU43PflUzLR2pbFqkenncKniZsRNjcaAcocRmGQBQh1kIISmllJLrbG/3oCujE7PHahYo8eDu46fUqawsLzx4+vEZN/eHQcJHyVBjz5DqsYWOwDm/nmP52TF
	vY79x1O4bKcp5b7JWIQoNklRhYhvKjBkfCrf3xJ7+ijVKo+TAsQuO4wKlDsMGpRRjlYm8U+wBp57jWrYlpFRKGa7G56b/4i//x0Hj4OKU9/03Tj3e3BuvFvP1QhJmf2Zcuz/UhGiNWK3a7US8Ovvaq7/zcXenmfWqrmdKpTRLGCO9KELGhJmIOHcZLY9XGo3BBTrUJxuzCtJ8refnuDY6EwRjbaRnA3OxjQ0AUK2U4EIZrYw2gIYyzVQyNV48e9wzRt6729p5sl+2ci8/+Gy80x5hMFIBsZOyf4TIrC4Uld05bChP+kpZNo4RywAERgyTPCJgO1bBmfALzb3B5msXrg0UqxaG5QJgy0UMrIxYjAhHZ4HtJVW3uAaCUkYNGAxGKYkBd/pNC2AizxYq/LPHn9hWfb4eFxob59cakhpXmIaCnGu9u7td9MdajTsvnbxAmY94YEFojOEGEcYQAYSY4VEx79J8QQ+yiPlBFq/aE1Gt7BmTwwo7jh5wjDlxGDWKMGKMAgBsW45t2TazGWHI0hs7G1oJIgavXjmTCKcXwJeuXsv+zwexyhLmxoRix3rEUAv0++3tDweHdzafvlZfxH6RS8cYAkAPW/0Xe612t2sAwNC0nz67t+rmcgEPW82+yEgqdZImo2Gnfbge9p6AaliuGsUj5lAAoJQxKYUCDYAEhkEYFPzCXA0q9eLme0m7K6auTgUf3ynYrCzprhJHBSdYnLX3jvSoNwrMzfbW7Y9aIaCwQMHlOS83XvWTRGDLihCkoyTujpiiBAOSYTKAOAjdXAFjLGTWae0/W3skwa3WJiYnpse9BQCgwyhCCAhBwOgoDErVCd1tLc2ge4+fBKHDjJk/fsrR76BhHBoIy6VoeSlFEmxKHNpN0rGJqbDbV9KwgWj3IlWQhGGlTXuUacvKMxtJhA3oLGZJL+Nht1M/eeZaq90wGDtu7tj8cYUsIU3J8yzKAAQVimdSICmlUQ93Xxw1W8cnxhYW
	wkKhY/C8X+ufq891Wy3P4Nsg26eWolx9dLC9P+wpZBKbNnv9AiGWlipNXEP1gGNKjJIFg0lmLJOWmS2UylMU91qWXw663X4nUAYjkNRxX9zd0oj4lclykTNCAIDatqORMVpJhNY21raP9lS0+bdeWd7ePXr8wlqaXiK//qDX3P20Nr41tZASRtSwhSRCUHVsZkO3F9qkgFKJDC4QprRSmcgTSjHFBjEwjtR5hEm7xxzmunkZhL1Od2F5th+2DQJDqF2ezo8vAcbUpABAkyTjUhjJRzrRQe9CsXj9st0ZbDVeDK8M7b+Nk+7qnaevfvVAC8G5ATTx2mtLRt7+d/+WpKHrWEnRO2gPxqUtMU4UV0bbzMKISCmBIKAUAGyAzvZWrmjZ1SJS/OHde/MzE2OVeqHgX3n5qnLHO/3UIO55GAAoF0pppbTuBoOEGkqsGqPXotlLvUp1pto8ffGdXuPFbz+lsSL5YovoW+++c2q8rmyLaocinCN6VLaToZFcYoM0xpHiHFAOU8aIBpAAgFEmZNLpmFpJsk5hciYeDmsTi/fuf7bX2auWx0rjc47v7j2+BXCRUoK4QQDQaB0Zg7SRhVSxx0NfzHWPrzxfXlj76EObxxqhv1p7fOLiJd8Ujp890z46HG5tGNAIKdtloRCJUjnMMAKsMEK4RbhCAhuMElkkdozAjIb5YZToZiDM5XNntQ2u5VKtGzsbe/tbpXye1SbBvkgJAMVYEzIajTyEj83YQ7/104Xhb37WvLGwEm3shUnAMhUiM1AZz9KjVmtydrpFCAeFMaYWtQBpn0mtBpkCpZAFiGLm2KAhHaY5REEjhJUDhAcxx05hLBcnaa1UKjALE+aVqpHIJienbBAAgEt+frxURBZRBkOuNF2lC2P4fif7JXa2uD7Y3+VxQlO5GwfMyecK+Xq1WB8b6yaBJEhqhRBGGGML56s+rnhW3XeqBavoEERFkFmAkdIIQR4wjlMRxx5zUgG3769qo
	U7MzLS7w04QGcs2zPbLPgDg3qAXh8PV7fXEoPm5xWIt543nRe585djS1vN7+MXDwfZGe9Dc63XSRBwcNOIoAgQjkQqGhdGAkNEaaUW0ylnUw9g1BIdKdsK8op4hNiUSa8VFvVI5ff6sSFOG2YOnG0kii26+6BeJxbjRSZpg1wMAbDMgFjxZvb+/u/X81ntJZysYos7hcNbLjy1MPtp6gkbdqD+oF6vFSs3NeTNT04NePwQtsNZAldYGIaUUaIkkRxrCME0GSQk7HmCiDQWEAQMCGcYXjh2zjQShohiGcXb1pQvH5ueLOafgOkaK2bEiAFDFZTcc2CpayMPSWO3kUn5zbXtwNNjfffTW3/9Hd29+mISBkWRhYf7333xzZqKUBaNOp9/ziqUgwSBSJGxqy0xrYUAZLkUUpXVs5zHJQEstkAFsMGNOOgiS++s05AiACp7G8Vi1xMPk5LFjbrGUQzA3UYOHQA1mz7e3D1qDAtNTp+cZNd2B+NaXvtjvqGrRs4pETXuHR73NezcDHTsMX7n2ansYzc2drnO7K5+vzEwqrtf3okAbkxgeZyCMTy0bUY1U9v/FmMUoaHPc5LOZY7/urk9Yo3H2eu+ou1ir/urxqtHZialp98wUAGAA9XhrPaH+SJPKhB+lfL2de//uemblk0hcml34g7feOHN+5eyZk6eXpoP2YaXsdzdXv3ugb9SXSi75va9d+4f/4I+/89aNotb9ILYFnrYLHsYUAUMYGQAD1CCCSd0tfPrg/hwH0ttctgN7dDjGu0sOdqmZKlvnj88SpAGAPtnYyESKVFTP8Zw16rUOW116FOPr5fqz7b2fP36hP+7zWAkplxdmEUEF1748O/7wg59MaOv7J065NzcOnrW8nKeo48lwxStSLi3QgCkiaATYGMMMgNG1QmlfxxO9Xtn1Ro2+UnDz5z+LgzTP0Hgtl7MhzmIAwI/XVgNBAqNXTh2v5Mwwg3Z3wEfJ7OxyHHPb9SNuEi
	64Ed1RmAjm58rbHz85qdCfzi2fHfH67sj+6EX6s0/hoPvW5Mmq5MwimlCikUXtIYOYIYWUz1impU75ve6WzeHK+OKf/+AHYchVKuJRsLrTfHHY6A77AEAnZ6bBXc6ePj+1UOmPntxfkx3t5yzI5Uu7e3sYEDKmXirisisJnqxPH7Q68aD3rYVllkQJF6GUsRQmiE4j9/Wpkz9tHhGtDSUKACgOmcmQdhS1LDvLMoOwjJJ4d/ir4cfP0qaA23pxWc5N0FKhnQiLMQCgFceSFl24dPwLF4s/efe2P3llmoAbB5ZLw3gYxFE/jkdZNl8udA47KyunB72jb1Qn7c5gmGVcqJTzkVbAzY1TV89fvHR398nBYMgNikD5mhSQHWJuXM/OFaJhKLHhowAIWfjGl7b3nwbx8Nw3f9cCEDJjXAeDEQCQOGjFRzsny8FkRe43i0+fH2jIn5qZkxG/fft+rlDNlSYzxOanZxuj/hfPnLu+erCyvquSmKd6oOORkoMw+VTEb37hm6oXzdq5o2DU0akUMnbJhhgUHHeCelRBnGXDLAGDLMcrvHJ58dtvfXC4tdntCQG+bU/MTPl8sD5cIlMztSAOvvX6ceJEO3tHn7z3JG20XJleu3w1ToPdvQ0j+GS9/vWv3Xjl1Onru935W59ClnZGQ4sxi7FA8N+OBs8QOZqvD20z7fpoGDbikIMwMiNSlRG1DVWZiHiCCHUtG1vW+T/6fXDtrfZRnGSDqN8bdMbLpaS909EXaYBYKafPXl367PH9nd0gzTRRoWPnKWJ/81vfPnNy5Yc//OGt28/nHHhjoz03AD4cZdgUixULcJylFnZ7AOlYuXjj5R/9x//033cPr1VnRjKyLUtkkRYyFIJDUsv5DsWI0ZFUr/2977Gx+iCJDnu9IAgRNYVqaTjomFEEOaA2QV//8qLD0t2do62dWChIs2R8cqbgl0DJ4/NLb//dtzvd7kub2xceHQUqjJDqRmHQjQuOqyn
	ZiaKpyoRz4wuXzr70/MTyi8bR+72NEqPVTGL4a1NvIQRK5Cw3MDBz+RI6tpAAhJIzy65WEGOEYEhF5iv6+VE0F05P+f7Ui61Od4iV1hb1p6amM5USQFoh368t5IvjP/m1ylIuJAhFCGXMotQyjGCbbzX39p88Pvyv/8V2XZT3yED2sHYskteYCcIwBg0DwTVzZLkQ1XyTSuvzgUCpEglFVGMMmNSrzpEAim310sWX7j5ZI9Zc5/ARF6w651dqVSllKIWJhxF3is9XaaPNNOQsBkAdLRLCNMbNLBYGIbcgbdJu7iEpjO+aOE45fxIPl73SuFeORBpgaSwmPUp8ZutU89S1LRwazKgyFkLYY7bHnIXp4sNtoCtLtYnx8n/40Y+2d5U21PfL/+YH/5JqY7v5Ti950DksKlV4+CQnpaY441xzJUBigjMpM6N247ANOGKUKAnaOPliRILBsJ8geDDq1ZhjuzatFsMoKlBdMUbE8aDfY5S5tnvp8pWUZzzL0iR2bdbpHALA/wMUjQteOh3xIgAAAABJRU5ErkJggg==
X-Mailer: Evolution 3.2.2 (3.2.2-1.fc16) 
Mime-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>, Keir Fraser <keir@xen.org>
Subject: [Xen-devel] [PATCHv2] sedf: remove useless tracing printk and
 harmonize comments style.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============2284887627372470128=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--===============2284887627372470128==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-oVXZhmqkWYbyP3+4MWM6"


--=-oVXZhmqkWYbyP3+4MWM6
Content-Type: multipart/mixed; boundary="=-DM3xwBkUsBWsFUckworM"


--=-DM3xwBkUsBWsFUckworM
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

sched_sedf.c used o have its own mechanism for producing tracing-alike
kind of information (domain block, wakeup, etc.). Nowadays, with an even
not so high number of pCPUs/vCPUs, just trying to enable this makes
the serial console completely unusable, produces tons of very hard to
parse and interpreet logging and can easily livelock Dom0. Moreover,
pretty much the same result this is struggling to get to, is better
achieved by enabling the scheduler-related tracing events, as
it is for the other schedulers (say, credit or credit2).

For all these reasons, this removes that machinery completely. While at
it, check in some cosmetics that harmonize the comments withim themself
and with the rest of the code base.

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>

diff -r 51045a5ec6bc xen/common/sched_sedf.c
--- a/xen/common/sched_sedf.c	Wed Dec 21 14:49:01 2011 +0000
+++ b/xen/common/sched_sedf.c	Wed Dec 21 15:12:07 2011 +0000
@@ -13,14 +13,6 @@
 #include <xen/time.h>
 #include <xen/errno.h>
=20
-/*verbosity settings*/
-#define SEDFLEVEL 0
-#define PRINT(_f, _a...)                        \
-    do {                                        \
-        if ( (_f) <=3D SEDFLEVEL )                \
-            printk(_a );                        \
-    } while ( 0 )
-
 #define SEDF_CPUONLINE(_pool)                                             =
\
     (((_pool) =3D=3D NULL) ? &cpupool_free_cpus : (_pool)->cpu_valid)
=20
@@ -66,34 +58,35 @@ struct sedf_vcpu_info {
     struct list_head list;
     struct list_head extralist[2];
 =20
-    /*Parameters for EDF*/
-    s_time_t  period;  /*=3D(relative deadline)*/
-    s_time_t  slice;  /*=3Dworst case execution time*/
+    /* Parameters for EDF */
+    s_time_t  period;  /* =3D(relative deadline) */
+    s_time_t  slice;   /* =3Dworst case execution time */
 =20
-    /*Advaced Parameters*/
-    /*Latency Scaling*/
+    /* Advaced Parameters */
+
+    /* Latency Scaling */
     s_time_t  period_orig;
     s_time_t  slice_orig;
     s_time_t  latency;
 =20
-    /*status of domain*/
+    /* Status of domain */
     int       status;
-    /*weights for "Scheduling for beginners/ lazy/ etc." ;)*/
+    /* Weights for "Scheduling for beginners/ lazy/ etc." ;) */
     short     weight;
     short     extraweight;
-    /*Bookkeeping*/
+    /* Bookkeeping */
     s_time_t  deadl_abs;
     s_time_t  sched_start_abs;
     s_time_t  cputime;
-    /* times the domain un-/blocked */
+    /* Times the domain un-/blocked */
     s_time_t  block_abs;
     s_time_t  unblock_abs;
 =20
-    /*scores for {util, block penalty}-weighted extratime distribution*/
+    /* Scores for {util, block penalty}-weighted extratime distribution */
     int   score[2];
     s_time_t  short_block_lost_tot;
 =20
-    /*Statistics*/
+    /* Statistics */
     s_time_t  extra_time_tot;
=20
 #ifdef SEDF_STATS
@@ -158,18 +151,17 @@ static inline void extraq_del(struct vcp
 {
     struct list_head *list =3D EXTRALIST(d,i);
     ASSERT(extraq_on(d,i));
-    PRINT(3, "Removing domain %i.%i from L%i extraq\n",
-          d->domain->domain_id, d->vcpu_id, i);
     list_del(list);
     list->next =3D NULL;
     ASSERT(!extraq_on(d, i));
 }
=20
-/* adds a domain to the queue of processes which are aware of extra time. =
List
-   is sorted by score, where a lower score means higher priority for an ex=
tra
-   slice. It also updates the score, by simply subtracting a fixed value f=
rom
-   each entry, in order to avoid overflow. The algorithm works by simply
-   charging each domain that recieved extratime with an inverse of its wei=
ght.
+/*
+ * Adds a domain to the queue of processes which are aware of extra time. =
List
+ * is sorted by score, where a lower score means higher priority for an ex=
tra
+ * slice. It also updates the score, by simply subtracting a fixed value f=
rom
+ * each entry, in order to avoid overflow. The algorithm works by simply
+ * charging each domain that recieved extratime with an inverse of its wei=
ght.
  */=20
 static inline void extraq_add_sort_update(struct vcpu *d, int i, int sub)
 {
@@ -178,11 +170,6 @@ static inline void extraq_add_sort_updat
 =20
     ASSERT(!extraq_on(d,i));
=20
-    PRINT(3, "Adding domain %i.%i (score=3D %i, short_pen=3D %"PRIi64")"
-          " to L%i extraq\n",
-          d->domain->domain_id, d->vcpu_id, EDOM_INFO(d)->score[i],
-          EDOM_INFO(d)->short_block_lost_tot, i);
-
     /*
      * Iterate through all elements to find our "hole" and on our way
      * update all the other scores.
@@ -193,25 +180,18 @@ static inline void extraq_add_sort_updat
         curinf->score[i] -=3D sub;
         if ( EDOM_INFO(d)->score[i] < curinf->score[i] )
             break;
-        PRINT(4,"\tbehind domain %i.%i (score=3D %i)\n",
-              curinf->vcpu->domain->domain_id,
-              curinf->vcpu->vcpu_id, curinf->score[i]);
     }
=20
-    /* cur now contains the element, before which we'll enqueue. */
-    PRINT(3, "\tlist_add to %p\n", cur->prev);
+    /* cur now contains the element, before which we'll enqueue */
     list_add(EXTRALIST(d,i),cur->prev);
 =20
-    /* Continue updating the extraq. */
+    /* Continue updating the extraq */
     if ( (cur !=3D EXTRAQ(d->processor,i)) && sub )
     {
         for ( cur =3D cur->next; cur !=3D EXTRAQ(d->processor,i); cur =3D =
cur->next )
         {
             curinf =3D list_entry(cur,struct sedf_vcpu_info, extralist[i])=
;
             curinf->score[i] -=3D sub;
-            PRINT(4, "\tupdating domain %i.%i (score=3D %u)\n",
-                  curinf->vcpu->domain->domain_id,=20
-                  curinf->vcpu->vcpu_id, curinf->score[i]);
         }
     }
=20
@@ -221,29 +201,14 @@ static inline void extraq_check(struct v
 {
     if ( extraq_on(d, EXTRA_UTIL_Q) )
     {
-        PRINT(2,"Dom %i.%i is on L1 extraQ\n",
-              d->domain->domain_id, d->vcpu_id);
-
         if ( !(EDOM_INFO(d)->status & EXTRA_AWARE) &&
              !extra_runs(EDOM_INFO(d)) )
-        {
             extraq_del(d, EXTRA_UTIL_Q);
-            PRINT(2,"Removed dom %i.%i from L1 extraQ\n",
-                  d->domain->domain_id, d->vcpu_id);
-        }
     }
     else
     {
-        PRINT(2, "Dom %i.%i is NOT on L1 extraQ\n",
-              d->domain->domain_id,
-              d->vcpu_id);
-
         if ( (EDOM_INFO(d)->status & EXTRA_AWARE) && sedf_runnable(d) )
-        {
             extraq_add_sort_update(d, EXTRA_UTIL_Q, 0);
-            PRINT(2,"Added dom %i.%i to L1 extraQ\n",
-                  d->domain->domain_id, d->vcpu_id);
-        }
     }
 }
=20
@@ -252,7 +217,7 @@ static inline void extraq_check_add_unbl
     struct sedf_vcpu_info *inf =3D EDOM_INFO(d);
=20
     if ( inf->status & EXTRA_AWARE )
-        /* Put on the weighted extraq without updating any scores. */
+        /* Put on the weighted extraq without updating any scores */
         extraq_add_sort_update(d, EXTRA_UTIL_Q, 0);
 }
=20
@@ -265,8 +230,6 @@ static inline void __del_from_queue(stru
 {
     struct list_head *list =3D LIST(d);
     ASSERT(__task_on_queue(d));
-    PRINT(3,"Removing domain %i.%i (bop=3D %"PRIu64") from runq/waitq\n",
-          d->domain->domain_id, d->vcpu_id, PERIOD_BEGIN(EDOM_INFO(d)));
     list_del(list);
     list->next =3D NULL;
     ASSERT(!__task_on_queue(d));
@@ -279,13 +242,12 @@ static inline void list_insert_sort(
 {
     struct list_head     *cur;
=20
-    /* Iterate through all elements to find our "hole". */
+    /* Iterate through all elements to find our "hole" */
     list_for_each( cur, list )
         if ( comp(element, cur) < 0 )
             break;
=20
-    /* cur now contains the element, before which we'll enqueue. */
-    PRINT(3,"\tlist_add to %p\n",cur->prev);
+    /* cur now contains the element, before which we'll enqueue */
     list_add(element, cur->prev);
 }
=20
@@ -303,30 +265,28 @@ static int name##_comp(struct list_head*
         return 1;                                                       \
 }
=20
-/* adds a domain to the queue of processes which wait for the beginning of=
 the
-   next period; this list is therefore sortet by this time, which is simpl=
y
-   absol. deadline - period
+/*
+ * Adds a domain to the queue of processes which wait for the beginning of=
 the
+ * next period; this list is therefore sortet by this time, which is simpl=
y
+ * absol. deadline - period.
  */=20
 DOMAIN_COMPARER(waitq, list, PERIOD_BEGIN(d1), PERIOD_BEGIN(d2));
 static inline void __add_to_waitqueue_sort(struct vcpu *v)
 {
     ASSERT(!__task_on_queue(v));
-    PRINT(3,"Adding domain %i.%i (bop=3D %"PRIu64") to waitq\n",
-          v->domain->domain_id, v->vcpu_id, PERIOD_BEGIN(EDOM_INFO(v)));
     list_insert_sort(WAITQ(v->processor), LIST(v), waitq_comp);
     ASSERT(__task_on_queue(v));
 }
=20
-/* adds a domain to the queue of processes which have started their curren=
t
-   period and are runnable (i.e. not blocked, dieing,...). The first eleme=
nt
-   on this list is running on the processor, if the list is empty the idle
-   task will run. As we are implementing EDF, this list is sorted by deadl=
ines.
+/*
+ * Adds a domain to the queue of processes which have started their curren=
t
+ * period and are runnable (i.e. not blocked, dieing,...). The first eleme=
nt
+ * on this list is running on the processor, if the list is empty the idle
+ * task will run. As we are implementing EDF, this list is sorted by deadl=
ines.
  */=20
 DOMAIN_COMPARER(runq, list, d1->deadl_abs, d2->deadl_abs);
 static inline void __add_to_runqueue_sort(struct vcpu *v)
 {
-    PRINT(3,"Adding domain %i.%i (deadl=3D %"PRIu64") to runq\n",
-          v->domain->domain_id, v->vcpu_id, EDOM_INFO(v)->deadl_abs);
     list_insert_sort(RUNQ(v->processor), LIST(v), runq_comp);
 }
=20
@@ -453,10 +413,10 @@ static void desched_edf_dom(s_time_t now
 {
     struct sedf_vcpu_info* inf =3D EDOM_INFO(d);
=20
-    /* Current domain is running in real time mode. */
+    /* Current domain is running in real time mode */
     ASSERT(__task_on_queue(d));
=20
-    /* Update the domain's cputime. */
+    /* Update the domain's cputime */
     inf->cputime +=3D now - inf->sched_start_abs;
=20
     /*
@@ -467,7 +427,7 @@ static void desched_edf_dom(s_time_t now
         return;
  =20
     __del_from_queue(d);
- =20
+
     /*
      * Manage bookkeeping (i.e. calculate next deadline, memorise
      * overrun-time of slice) of finished domains.
@@ -478,30 +438,30 @@ static void desched_edf_dom(s_time_t now
  =20
         if ( inf->period < inf->period_orig )
         {
-            /* This domain runs in latency scaling or burst mode. */
+            /* This domain runs in latency scaling or burst mode */
             inf->period *=3D 2;
             inf->slice  *=3D 2;
             if ( (inf->period > inf->period_orig) ||
                  (inf->slice > inf->slice_orig) )
             {
-                /* Reset slice and period. */
+                /* Reset slice and period */
                 inf->period =3D inf->period_orig;
                 inf->slice =3D inf->slice_orig;
             }
         }
=20
-        /* Set next deadline. */
+        /* Set next deadline */
         inf->deadl_abs +=3D inf->period;
     }
 =20
-    /* Add a runnable domain to the waitqueue. */
+    /* Add a runnable domain to the waitqueue */
     if ( sedf_runnable(d) )
     {
         __add_to_waitqueue_sort(d);
     }
     else
     {
-        /* We have a blocked realtime task -> remove it from exqs too. */
+        /* We have a blocked realtime task -> remove it from exqs too */
         if ( extraq_on(d, EXTRA_PEN_Q) )
             extraq_del(d, EXTRA_PEN_Q);
         if ( extraq_on(d, EXTRA_UTIL_Q) )
@@ -521,8 +481,6 @@ static void update_queues(
     struct list_head     *cur, *tmp;
     struct sedf_vcpu_info *curinf;
 =20
-    PRINT(3,"Updating waitq..\n");
-
     /*
      * Check for the first elements of the waitqueue, whether their
      * next period has already started.
@@ -530,41 +488,32 @@ static void update_queues(
     list_for_each_safe ( cur, tmp, waitq )
     {
         curinf =3D list_entry(cur, struct sedf_vcpu_info, list);
-        PRINT(4,"\tLooking @ dom %i.%i\n",
-              curinf->vcpu->domain->domain_id, curinf->vcpu->vcpu_id);
         if ( PERIOD_BEGIN(curinf) > now )
             break;
         __del_from_queue(curinf->vcpu);
         __add_to_runqueue_sort(curinf->vcpu);
     }
 =20
-    PRINT(3,"Updating runq..\n");
-
-    /* Process the runq, find domains that are on the runq that shouldn't.=
 */
+    /* Process the runq, find domains that are on the runq that shouldn't =
*/
     list_for_each_safe ( cur, tmp, runq )
     {
         curinf =3D list_entry(cur,struct sedf_vcpu_info,list);
-        PRINT(4,"\tLooking @ dom %i.%i\n",
-              curinf->vcpu->domain->domain_id, curinf->vcpu->vcpu_id);
=20
         if ( unlikely(curinf->slice =3D=3D 0) )
         {
-            /* Ignore domains with empty slice. */
-            PRINT(4,"\tUpdating zero-slice domain %i.%i\n",
-                  curinf->vcpu->domain->domain_id,
-                  curinf->vcpu->vcpu_id);
+            /* Ignore domains with empty slice */
             __del_from_queue(curinf->vcpu);
=20
-            /* Move them to their next period. */
+            /* Move them to their next period */
             curinf->deadl_abs +=3D curinf->period;
=20
-            /* Ensure that the start of the next period is in the future. =
*/
+            /* Ensure that the start of the next period is in the future *=
/
             if ( unlikely(PERIOD_BEGIN(curinf) < now) )
                 curinf->deadl_abs +=3D=20
                     (DIV_UP(now - PERIOD_BEGIN(curinf),
                             curinf->period)) * curinf->period;
=20
-            /* Put them back into the queue. */
+            /* Put them back into the queue */
             __add_to_waitqueue_sort(curinf->vcpu);
         }
         else if ( unlikely((curinf->deadl_abs < now) ||
@@ -574,18 +523,18 @@ static void update_queues(
              * We missed the deadline or the slice was already finished.
              * Might hapen because of dom_adj.
              */
-            PRINT(4,"\tDomain %i.%i exceeded it's deadline/"
-                  "slice (%"PRIu64" / %"PRIu64") now: %"PRIu64
-                  " cputime: %"PRIu64"\n",
-                  curinf->vcpu->domain->domain_id,
-                  curinf->vcpu->vcpu_id,
-                  curinf->deadl_abs, curinf->slice, now,
-                  curinf->cputime);
+            printk("\tDomain %i.%i exceeded it's deadline/"
+                   "slice (%"PRIu64" / %"PRIu64") now: %"PRIu64
+                   " cputime: %"PRIu64"\n",
+                   curinf->vcpu->domain->domain_id,
+                   curinf->vcpu->vcpu_id,
+                   curinf->deadl_abs, curinf->slice, now,
+                   curinf->cputime);
             __del_from_queue(curinf->vcpu);
=20
-            /* Common case: we miss one period. */
+            /* Common case: we miss one period */
             curinf->deadl_abs +=3D curinf->period;
-  =20
+
             /*
              * If we are still behind: modulo arithmetic, force deadline
              * to be in future and aligned to period borders.
@@ -596,7 +545,7 @@ static void update_queues(
                            curinf->period) * curinf->period;
             ASSERT(curinf->deadl_abs >=3D now);
=20
-            /* Give a fresh slice. */
+            /* Give a fresh slice */
             curinf->cputime =3D 0;
             if ( PERIOD_BEGIN(curinf) > now )
                 __add_to_waitqueue_sort(curinf->vcpu);
@@ -606,17 +555,17 @@ static void update_queues(
         else
             break;
     }
-
-    PRINT(3,"done updating the queues\n");
 }
=20

-/* removes a domain from the head of the according extraQ and
-   requeues it at a specified position:
-     round-robin extratime: end of extraQ
-     weighted ext.: insert in sorted list by score
-   if the domain is blocked / has regained its short-block-loss
-   time it is not put on any queue */
+/*
+ * removes a domain from the head of the according extraQ and
+ * requeues it at a specified position:
+ *   round-robin extratime: end of extraQ
+ *   weighted ext.: insert in sorted list by score
+ * if the domain is blocked / has regained its short-block-loss
+ * time it is not put on any queue.
+ */
 static void desched_extra_dom(s_time_t now, struct vcpu *d)
 {
     struct sedf_vcpu_info *inf =3D EDOM_INFO(d);
@@ -625,29 +574,25 @@ static void desched_extra_dom(s_time_t n
=20
     ASSERT(extraq_on(d, i));
=20
-    /* Unset all running flags. */
+    /* Unset all running flags */
     inf->status  &=3D ~(EXTRA_RUN_PEN | EXTRA_RUN_UTIL);
-    /* Fresh slice for the next run. */
+    /* Fresh slice for the next run */
     inf->cputime =3D 0;
-    /* Accumulate total extratime. */
+    /* Accumulate total extratime */
     inf->extra_time_tot +=3D now - inf->sched_start_abs;
     /* Remove extradomain from head of the queue. */
     extraq_del(d, i);
=20
-    /* Update the score. */
+    /* Update the score */
     oldscore =3D inf->score[i];
     if ( i =3D=3D EXTRA_PEN_Q )
     {
-        /*domain was running in L0 extraq*/
-        /*reduce block lost, probably more sophistication here!*/
+        /* Domain was running in L0 extraq */
+        /* reduce block lost, probably more sophistication here!*/
         /*inf->short_block_lost_tot -=3D EXTRA_QUANTUM;*/
         inf->short_block_lost_tot -=3D now - inf->sched_start_abs;
-        PRINT(3,"Domain %i.%i: Short_block_loss: %"PRIi64"\n",=20
-              inf->vcpu->domain->domain_id, inf->vcpu->vcpu_id,
-              inf->short_block_lost_tot);
 #if 0
-        /*
-         * KAF: If we don't exit short-blocking state at this point
+        /* KAF: If we don't exit short-blocking state at this point
          * domain0 can steal all CPU for up to 10 seconds before
          * scheduling settles down (when competing against another
          * CPU-bound domain). Doing this seems to make things behave
@@ -656,51 +601,59 @@ static void desched_extra_dom(s_time_t n
         if ( inf->short_block_lost_tot <=3D 0 )
 #endif
         {
-            PRINT(4,"Domain %i.%i compensated short block loss!\n",
-                  inf->vcpu->domain->domain_id, inf->vcpu->vcpu_id);
-            /*we have (over-)compensated our block penalty*/
+            /* We have (over-)compensated our block penalty */
             inf->short_block_lost_tot =3D 0;
-            /*we don't want a place on the penalty queue anymore!*/
+            /* We don't want a place on the penalty queue anymore! */
             inf->status &=3D ~EXTRA_WANT_PEN_Q;
             goto check_extra_queues;
         }
=20
-        /*we have to go again for another try in the block-extraq,
-          the score is not used incremantally here, as this is
-          already done by recalculating the block_lost*/
+        /*
+         * We have to go again for another try in the block-extraq,
+         * the score is not used incremantally here, as this is
+         * already done by recalculating the block_lost
+         */
         inf->score[EXTRA_PEN_Q] =3D (inf->period << 10) /
             inf->short_block_lost_tot;
         oldscore =3D 0;
     }
     else
     {
-        /*domain was running in L1 extraq =3D> score is inverse of
-          utilization and is used somewhat incremental!*/
+        /*
+         * Domain was running in L1 extraq =3D> score is inverse of
+         * utilization and is used somewhat incremental!
+         */
         if ( !inf->extraweight )
-            /*NB: use fixed point arithmetic with 10 bits*/
+        {
+            /* NB: use fixed point arithmetic with 10 bits */
             inf->score[EXTRA_UTIL_Q] =3D (inf->period << 10) /
                 inf->slice;
+        }
         else
-            /*conversion between realtime utilisation and extrawieght:
-              full (ie 100%) utilization is equivalent to 128 extraweight*=
/
+        {
+            /*
+             * Conversion between realtime utilisation and extrawieght:
+             * full (ie 100%) utilization is equivalent to 128 extraweight
+             */
             inf->score[EXTRA_UTIL_Q] =3D (1<<17) / inf->extraweight;
+        }
     }
=20
  check_extra_queues:
-    /* Adding a runnable domain to the right queue and removing blocked on=
es*/
+    /* Adding a runnable domain to the right queue and removing blocked on=
es */
     if ( sedf_runnable(d) )
     {
-        /*add according to score: weighted round robin*/
+        /* Add according to score: weighted round robin */
         if (((inf->status & EXTRA_AWARE) && (i =3D=3D EXTRA_UTIL_Q)) ||
             ((inf->status & EXTRA_WANT_PEN_Q) && (i =3D=3D EXTRA_PEN_Q)))
             extraq_add_sort_update(d, i, oldscore);
     }
     else
     {
-        /*remove this blocked domain from the waitq!*/
+        /* Remove this blocked domain from the waitq! */
         __del_from_queue(d);
-        /*make sure that we remove a blocked domain from the other
-          extraq too*/
+        /* Make sure that we remove a blocked domain from the other
+         * extraq too. */
         if ( i =3D=3D EXTRA_PEN_Q )
         {
             if ( extraq_on(d, EXTRA_UTIL_Q) )
@@ -732,8 +685,10 @@ static struct task_slice sedf_do_extra_s
=20
     if ( !list_empty(extraq[EXTRA_PEN_Q]) )
     {
-        /*we still have elements on the level 0 extraq=20
-          =3D> let those run first!*/
+        /*
+         * We still have elements on the level 0 extraq
+         * =3D> let those run first!
+         */
         runinf   =3D list_entry(extraq[EXTRA_PEN_Q]->next,=20
                               struct sedf_vcpu_info, extralist[EXTRA_PEN_Q=
]);
         runinf->status |=3D EXTRA_RUN_PEN;
@@ -747,7 +702,7 @@ static struct task_slice sedf_do_extra_s
     {
         if ( !list_empty(extraq[EXTRA_UTIL_Q]) )
         {
-            /*use elements from the normal extraqueue*/
+            /* Use elements from the normal extraqueue */
             runinf   =3D list_entry(extraq[EXTRA_UTIL_Q]->next,
                                   struct sedf_vcpu_info,
                                   extralist[EXTRA_UTIL_Q]);
@@ -772,11 +727,13 @@ static struct task_slice sedf_do_extra_s
 }
=20

-/* Main scheduling function
-   Reasons for calling this function are:
-   -timeslice for the current period used up
-   -domain on waitqueue has started it's period
-   -and various others ;) in general: determine which domain to run next*/
+/*
+ * Main scheduling function
+ * Reasons for calling this function are:
+ * -timeslice for the current period used up
+ * -domain on waitqueue has started it's period
+ * -and various others ;) in general: determine which domain to run next
+ */
 static struct task_slice sedf_do_schedule(
     const struct scheduler *ops, s_time_t now, bool_t tasklet_work_schedul=
ed)
 {
@@ -789,13 +746,15 @@ static struct task_slice sedf_do_schedul
     struct sedf_vcpu_info *runinf, *waitinf;
     struct task_slice      ret;
=20
-    /*idle tasks don't need any of the following stuf*/
+    /* Idle tasks don't need any of the following stuf */
     if ( is_idle_vcpu(current) )
         goto check_waitq;
-=20
-    /* create local state of the status of the domain, in order to avoid
-       inconsistent state during scheduling decisions, because data for
-       vcpu_runnable is not protected by the scheduling lock!*/
+
+    /*
+     * Create local state of the status of the domain, in order to avoid
+     * inconsistent state during scheduling decisions, because data for
+     * vcpu_runnable is not protected by the scheduling lock!
+     */
     if ( !vcpu_runnable(current) )
         inf->status |=3D SEDF_ASLEEP;
 =20
@@ -804,7 +763,7 @@ static struct task_slice sedf_do_schedul
=20
     if ( unlikely(extra_runs(inf)) )
     {
-        /*special treatment of domains running in extra time*/
+        /* Special treatment of domains running in extra time */
         desched_extra_dom(now, current);
     }
     else=20
@@ -814,10 +773,12 @@ static struct task_slice sedf_do_schedul
  check_waitq:
     update_queues(now, runq, waitq);
=20
-    /*now simply pick the first domain from the runqueue, which has the
-      earliest deadline, because the list is sorted*/
-=20
-    /* Tasklet work (which runs in idle VCPU context) overrides all else. =
*/
+    /*
+     * Now simply pick the first domain from the runqueue, which has the
+     * earliest deadline, because the list is sorted
+     *
+     * Tasklet work (which runs in idle VCPU context) overrides all else.
+     */
     if ( tasklet_work_scheduled ||
          (list_empty(runq) && list_empty(waitq)) ||
          unlikely(!cpumask_test_cpu(cpu, SEDF_CPUONLINE(per_cpu(cpupool, c=
pu)))) )
@@ -833,9 +794,11 @@ static struct task_slice sedf_do_schedul
         {
             waitinf  =3D list_entry(waitq->next,
                                   struct sedf_vcpu_info,list);
-            /*rerun scheduler, when scheduled domain reaches it's
-              end of slice or the first domain from the waitqueue
-              gets ready*/
+            /*
+             * Rerun scheduler, when scheduled domain reaches it's
+             * end of slice or the first domain from the waitqueue
+             * gets ready.
+             */
             ret.time =3D MIN(now + runinf->slice - runinf->cputime,
                            PERIOD_BEGIN(waitinf)) - now;
         }
@@ -847,14 +810,18 @@ static struct task_slice sedf_do_schedul
     else
     {
         waitinf  =3D list_entry(waitq->next,struct sedf_vcpu_info, list);
-        /*we could not find any suitable domain=20
-          =3D> look for domains that are aware of extratime*/
+        /*
+         * We could not find any suitable domain=20
+         * =3D> look for domains that are aware of extratime
+         */
         ret =3D sedf_do_extra_schedule(now, PERIOD_BEGIN(waitinf),
                                      extraq, cpu);
     }
=20
-    /*TODO: Do something USEFUL when this happens and find out, why it
-      still can happen!!!*/
+    /*
+     * TODO: Do something USEFUL when this happens and find out, why it
+     * still can happen!!!
+     */
     if ( ret.time < 0)
     {
         printk("Ouch! We are seriously BEHIND schedule! %"PRIi64"\n",
@@ -874,9 +841,6 @@ static struct task_slice sedf_do_schedul
=20
 static void sedf_sleep(const struct scheduler *ops, struct vcpu *d)
 {
-    PRINT(2,"sedf_sleep was called, domain-id %i.%i\n",
-          d->domain->domain_id, d->vcpu_id);
-=20
     if ( is_idle_vcpu(d) )
         return;
=20
@@ -898,7 +862,8 @@ static void sedf_sleep(const struct sche
 }
=20

-/* This function wakes up a domain, i.e. moves them into the waitqueue
+/*
+ * This function wakes up a domain, i.e. moves them into the waitqueue
  * things to mention are: admission control is taking place nowhere at
  * the moment, so we can't be sure, whether it is safe to wake the domain
  * up at all. Anyway, even if it is safe (total cpu usage <=3D100%) there =
are
@@ -972,27 +937,31 @@ static void sedf_sleep(const struct sche
 static void unblock_short_extra_support(
     struct sedf_vcpu_info* inf, s_time_t now)
 {
-    /*this unblocking scheme tries to support the domain, by assigning it
-    a priority in extratime distribution according to the loss of time
-    in this slice due to blocking*/
+    /*
+     * This unblocking scheme tries to support the domain, by assigning it
+     * a priority in extratime distribution according to the loss of time
+     * in this slice due to blocking
+     */
     s_time_t pen;
 =20
-    /*no more realtime execution in this period!*/
+    /* No more realtime execution in this period! */
     inf->deadl_abs +=3D inf->period;
     if ( likely(inf->block_abs) )
     {
-        //treat blocked time as consumed by the domain*/
+        /* Treat blocked time as consumed by the domain */
         /*inf->cputime +=3D now - inf->block_abs;*/
-        /*penalty is time the domain would have
-          had if it continued to run */
+        /*
+         * Penalty is time the domain would have
+         * had if it continued to run.
+         */
         pen =3D (inf->slice - inf->cputime);
         if ( pen < 0 )
             pen =3D 0;
-        /*accumulate all penalties over the periods*/
+        /* Accumulate all penalties over the periods */
         /*inf->short_block_lost_tot +=3D pen;*/
-        /*set penalty to the current value*/
+        /* Set penalty to the current value */
         inf->short_block_lost_tot =3D pen;
-        /*not sure which one is better.. but seems to work well...*/
+        /* Not sure which one is better.. but seems to work well... */
  =20
         if ( inf->short_block_lost_tot )
         {
@@ -1002,28 +971,31 @@ static void unblock_short_extra_support(
             inf->pen_extra_blocks++;
 #endif
             if ( extraq_on(inf->vcpu, EXTRA_PEN_Q) )
-                /*remove domain for possible resorting!*/
+                /* Remove domain for possible resorting! */
                 extraq_del(inf->vcpu, EXTRA_PEN_Q);
             else
-                /*remember that we want to be on the penalty q
-                  so that we can continue when we (un-)block
-                  in penalty-extratime*/
+                /*
+                 * Remember that we want to be on the penalty q
+                 * so that we can continue when we (un-)block
+                 * in penalty-extratime
+                 */
                 inf->status |=3D EXTRA_WANT_PEN_Q;
   =20
-            /*(re-)add domain to the penalty extraq*/
+            /* (re-)add domain to the penalty extraq */
             extraq_add_sort_update(inf->vcpu, EXTRA_PEN_Q, 0);
         }
     }
=20
-    /*give it a fresh slice in the next period!*/
+    /* Give it a fresh slice in the next period! */
     inf->cputime =3D 0;
 }
=20

 static void unblock_long_cons_b(struct sedf_vcpu_info* inf,s_time_t now)
 {
-    /*Conservative 2b*/
-    /*Treat the unblocking time as a start of a new period */
+    /* Conservative 2b */
+
+    /* Treat the unblocking time as a start of a new period */
     inf->deadl_abs =3D now + inf->period;
     inf->cputime =3D 0;
 }
@@ -1046,15 +1018,17 @@ static inline int get_run_type(struct vc
 }
=20

-/*Compares two domains in the relation of whether the one is allowed to
-  interrupt the others execution.
-  It returns true (!=3D0) if a switch to the other domain is good.
-  Current Priority scheme is as follows:
-   EDF > L0 (penalty based) extra-time >=20
-   L1 (utilization) extra-time > idle-domain
-  In the same class priorities are assigned as following:
-   EDF: early deadline > late deadline
-   L0 extra-time: lower score > higher score*/
+/*
+ * Compares two domains in the relation of whether the one is allowed to
+ * interrupt the others execution.
+ * It returns true (!=3D0) if a switch to the other domain is good.
+ * Current Priority scheme is as follows:
+ *  EDF > L0 (penalty based) extra-time >=20
+ *  L1 (utilization) extra-time > idle-domain
+ * In the same class priorities are assigned as following:
+ *  EDF: early deadline > late deadline
+ *  L0 extra-time: lower score > higher score
+ */
 static inline int should_switch(struct vcpu *cur,
                                 struct vcpu *other,
                                 s_time_t now)
@@ -1063,26 +1037,25 @@ static inline int should_switch(struct v
     cur_inf   =3D EDOM_INFO(cur);
     other_inf =3D EDOM_INFO(other);
 =20
-    /* Check whether we need to make an earlier scheduling decision. */
+    /* Check whether we need to make an earlier scheduling decision */
     if ( PERIOD_BEGIN(other_inf) <=20
          CPU_INFO(other->processor)->current_slice_expires )
         return 1;
=20
-    /* No timing-based switches need to be taken into account here. */
+    /* No timing-based switches need to be taken into account here */
     switch ( get_run_type(cur) )
     {
     case DOMAIN_EDF:
-        /* Do not interrupt a running EDF domain. */
+        /* Do not interrupt a running EDF domain */
         return 0;
     case DOMAIN_EXTRA_PEN:
-        /* Check whether we also want the L0 ex-q with lower score. */
+        /* Check whether we also want the L0 ex-q with lower score */
         return ((other_inf->status & EXTRA_WANT_PEN_Q) &&
                 (other_inf->score[EXTRA_PEN_Q] <=20
                  cur_inf->score[EXTRA_PEN_Q]));
     case DOMAIN_EXTRA_UTIL:
         /* Check whether we want the L0 extraq. Don't
-         * switch if both domains want L1 extraq.
-         */
+         * switch if both domains want L1 extraq. */
         return !!(other_inf->status & EXTRA_WANT_PEN_Q);
     case DOMAIN_IDLE:
         return 1;
@@ -1096,18 +1069,11 @@ static void sedf_wake(const struct sched
     s_time_t              now =3D NOW();
     struct sedf_vcpu_info* inf =3D EDOM_INFO(d);
=20
-    PRINT(3, "sedf_wake was called, domain-id %i.%i\n",d->domain->domain_i=
d,
-          d->vcpu_id);
-
     if ( unlikely(is_idle_vcpu(d)) )
         return;
   =20
     if ( unlikely(__task_on_queue(d)) )
-    {
-        PRINT(3,"\tdomain %i.%i is already in some queue\n",
-              d->domain->domain_id, d->vcpu_id);
         return;
-    }
=20
     ASSERT(!sedf_runnable(d));
     inf->status &=3D ~SEDF_ASLEEP;
@@ -1116,28 +1082,25 @@ static void sedf_wake(const struct sched
 =20
     if ( unlikely(inf->deadl_abs =3D=3D 0) )
     {
-        /*initial setup of the deadline*/
+        /* Initial setup of the deadline */
         inf->deadl_abs =3D now + inf->slice;
     }
  =20
-    PRINT(3, "waking up domain %i.%i (deadl=3D %"PRIu64" period=3D %"PRIu6=
4
-          "now=3D %"PRIu64")\n",
-          d->domain->domain_id, d->vcpu_id, inf->deadl_abs, inf->period, n=
ow);
-
 #ifdef SEDF_STATS=20
     inf->block_tot++;
 #endif
=20
     if ( unlikely(now < PERIOD_BEGIN(inf)) )
     {
-        PRINT(4,"extratime unblock\n");
-        /* unblocking in extra-time! */
+        /* Unblocking in extra-time! */
         if ( inf->status & EXTRA_WANT_PEN_Q )
         {
-            /*we have a domain that wants compensation
-              for block penalty and did just block in
-              its compensation time. Give it another
-              chance!*/
+            /*
+             * We have a domain that wants compensation
+             * for block penalty and did just block in
+             * its compensation time. Give it another
+             * chance!
+             */
             extraq_add_sort_update(d, EXTRA_PEN_Q, 0);
         }
         extraq_check_add_unblocked(d, 0);
@@ -1146,8 +1109,7 @@ static void sedf_wake(const struct sched
     { =20
         if ( now < inf->deadl_abs )
         {
-            PRINT(4,"short unblocking\n");
-            /*short blocking*/
+            /* Short blocking */
 #ifdef SEDF_STATS
             inf->short_block_tot++;
 #endif
@@ -1157,8 +1119,7 @@ static void sedf_wake(const struct sched
         }
         else
         {
-            PRINT(4,"long unblocking\n");
-            /*long unblocking*/
+            /* Long unblocking */
 #ifdef SEDF_STATS
             inf->long_block_tot++;
 #endif
@@ -1168,24 +1129,13 @@ static void sedf_wake(const struct sched
         }
     }
=20
-    PRINT(3, "woke up domain %i.%i (deadl=3D %"PRIu64" period=3D %"PRIu64
-          "now=3D %"PRIu64")\n",
-          d->domain->domain_id, d->vcpu_id, inf->deadl_abs,
-          inf->period, now);
-
     if ( PERIOD_BEGIN(inf) > now )
-    {
         __add_to_waitqueue_sort(d);
-        PRINT(3,"added to waitq\n");
-    }
     else
-    {
         __add_to_runqueue_sort(d);
-        PRINT(3,"added to runq\n");
-    }
 =20
 #ifdef SEDF_STATS
-    /*do some statistics here...*/
+    /* Do some statistics here... */
     if ( inf->block_abs !=3D 0 )
     {
         inf->block_time_tot +=3D now - inf->block_abs;
@@ -1194,12 +1144,14 @@ static void sedf_wake(const struct sched
     }
 #endif
=20
-    /*sanity check: make sure each extra-aware domain IS on the util-q!*/
+    /* Sanity check: make sure each extra-aware domain IS on the util-q! *=
/
     ASSERT(IMPLY(inf->status & EXTRA_AWARE, extraq_on(d, EXTRA_UTIL_Q)));
     ASSERT(__task_on_queue(d));
-    /*check whether the awakened task needs to invoke the do_schedule
-      routine. Try to avoid unnecessary runs but:
-      Save approximation: Always switch to scheduler!*/
+    /*
+     * Check whether the awakened task needs to invoke the do_schedule
+     * routine. Try to avoid unnecessary runs but:
+     * Save approximation: Always switch to scheduler!
+     */
     ASSERT(d->processor >=3D 0);
     ASSERT(d->processor < nr_cpu_ids);
     ASSERT(per_cpu(schedule_data, d->processor).curr);
@@ -1244,7 +1196,7 @@ static void sedf_dump_domain(struct vcpu
 }
=20

-/* dumps all domains on the specified cpu */
+/* Dumps all domains on the specified cpu */
 static void sedf_dump_cpu_state(const struct scheduler *ops, int i)
 {
     struct list_head      *list, *queue, *tmp;
@@ -1319,7 +1271,7 @@ static void sedf_dump_cpu_state(const st
 }
=20

-/* Adjusts periods and slices of the domains accordingly to their weights.=
 */
+/* Adjusts periods and slices of the domains accordingly to their weights =
*/
 static int sedf_adjust_weights(struct cpupool *c, struct xen_domctl_schedu=
ler_op *cmd)
 {
     struct vcpu *p;
@@ -1335,7 +1287,7 @@ static int sedf_adjust_weights(struct cp
         return -ENOMEM;
     }
=20
-    /* Sum across all weights. */
+    /* Sum across all weights */
     rcu_read_lock(&domlist_read_lock);
     for_each_domain_in_cpupool( d, c )
     {
@@ -1350,11 +1302,14 @@ static int sedf_adjust_weights(struct cp
             }
             else
             {
-                /*don't modify domains who don't have a weight, but sum
-                  up the time they need, projected to a WEIGHT_PERIOD,
-                  so that this time is not given to the weight-driven
-                  domains*/
-                /*check for overflows*/
+                /*
+                 * Don't modify domains who don't have a weight, but sum
+                 * up the time they need, projected to a WEIGHT_PERIOD,
+                 * so that this time is not given to the weight-driven
+                 *  domains
+                 */
+
+                /* Check for overflows */
                 ASSERT((WEIGHT_PERIOD < ULONG_MAX)=20
                        && (EDOM_INFO(p)->slice_orig < ULONG_MAX));
                 sumt[cpu] +=3D=20
@@ -1365,7 +1320,7 @@ static int sedf_adjust_weights(struct cp
     }
     rcu_read_unlock(&domlist_read_lock);
=20
-    /* Adjust all slices (and periods) to the new weight. */
+    /* Adjust all slices (and periods) to the new weight */
     rcu_read_lock(&domlist_read_lock);
     for_each_domain_in_cpupool( d, c )
     {
@@ -1393,20 +1348,15 @@ static int sedf_adjust_weights(struct cp
 }
=20

-/* set or fetch domain scheduling parameters */
+/* Set or fetch domain scheduling parameters */
 static int sedf_adjust(const struct scheduler *ops, struct domain *p, stru=
ct xen_domctl_scheduler_op *op)
 {
     struct vcpu *v;
     int rc;
=20
-    PRINT(2,"sedf_adjust was called, domain-id %i new period %"PRIu64" "
-          "new slice %"PRIu64"\nlatency %"PRIu64" extra:%s\n",
-          p->domain_id, op->u.sedf.period, op->u.sedf.slice,
-          op->u.sedf.latency, (op->u.sedf.extratime)?"yes":"no");
-
     if ( op->cmd =3D=3D XEN_DOMCTL_SCHEDOP_putinfo )
     {
-        /* Check for sane parameters. */
+        /* Check for sane parameters */
         if ( !op->u.sedf.period && !op->u.sedf.weight )
             return -EINVAL;
         if ( op->u.sedf.weight )
@@ -1414,7 +1364,7 @@ static int sedf_adjust(const struct sche
             if ( (op->u.sedf.extratime & EXTRA_AWARE) &&
                  (!op->u.sedf.period) )
             {
-                /* Weight-driven domains with extratime only. */
+                /* Weight-driven domains with extratime only */
                 for_each_vcpu ( p, v )
                 {
                     EDOM_INFO(v)->extraweight =3D op->u.sedf.weight;
@@ -1425,7 +1375,7 @@ static int sedf_adjust(const struct sche
             }
             else
             {
-                /* Weight-driven domains with real-time execution. */
+                /* Weight-driven domains with real-time execution */
                 for_each_vcpu ( p, v )
                     EDOM_INFO(v)->weight =3D op->u.sedf.weight;
             }
@@ -1477,7 +1427,6 @@ static int sedf_adjust(const struct sche
         op->u.sedf.weight    =3D EDOM_INFO(p->vcpu[0])->weight;
     }
=20
-    PRINT(2,"sedf_adjust_finished\n");
     return 0;
 }
=20

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-------------------------------------------------------------------
Dario Faggioli, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
PhD Candidate, ReTiS Lab, Scuola Superiore Sant'Anna, Pisa (Italy)



--=-DM3xwBkUsBWsFUckworM
Content-Disposition: attachment; filename="sedf-debug-cleanup.patch"
Content-Type: text/x-patch; name="sedf-debug-cleanup.patch"; charset="UTF-8"
Content-Transfer-Encoding: base64

IyBIRyBjaGFuZ2VzZXQgcGF0Y2gNCiMgUGFyZW50IDUxMDQ1YTVlYzZiY2YxZTk3NDU4ZTRlNzQ3
ZDUyYmNjYjA3MzQ4YTQNCnNlZGY6IHJlbW92ZSB1c2VsZXNzIHRyYWNpbmcgcHJpbnRrIGFuZCBo
YXJtb25pemUgY29tbWVudHMgc3R5bGUuDQoNCnNjaGVkX3NlZGYuYyB1c2VkIG8gaGF2ZSBpdHMg
b3duIG1lY2hhbmlzbSBmb3IgcHJvZHVjaW5nIHRyYWNpbmctYWxpa2UNCmtpbmQgb2YgaW5mb3Jt
YXRpb24gKGRvbWFpbiBibG9jaywgd2FrZXVwLCBldGMuKS4gTm93YWRheXMsIHdpdGggYW4gZXZl
bg0Kbm90IHNvIGhpZ2ggbnVtYmVyIG9mIHBDUFVzL3ZDUFVzLCBqdXN0IHRyeWluZyB0byBlbmFi
bGUgdGhpcyBtYWtlcw0KdGhlIHNlcmlhbCBjb25zb2xlIGNvbXBsZXRlbHkgdW51c2FibGUsIHBy
b2R1Y2VzIHRvbnMgb2YgdmVyeSBoYXJkIHRvDQpwYXJzZSBhbmQgaW50ZXJwcmVldCBsb2dnaW5n
IGFuZCBjYW4gZWFzaWx5IGxpdmVsb2NrIERvbTAuIE1vcmVvdmVyLA0KcHJldHR5IG11Y2ggdGhl
IHNhbWUgcmVzdWx0IHRoaXMgaXMgc3RydWdnbGluZyB0byBnZXQgdG8sIGlzIGJldHRlcg0KYWNo
aWV2ZWQgYnkgZW5hYmxpbmcgdGhlIHNjaGVkdWxlci1yZWxhdGVkIHRyYWNpbmcgZXZlbnRzLCBh
cw0KaXQgaXMgZm9yIHRoZSBvdGhlciBzY2hlZHVsZXJzIChzYXksIGNyZWRpdCBvciBjcmVkaXQy
KS4NCg0KRm9yIGFsbCB0aGVzZSByZWFzb25zLCB0aGlzIHJlbW92ZXMgdGhhdCBtYWNoaW5lcnkg
Y29tcGxldGVseS4gV2hpbGUgYXQNCml0LCBjaGVjayBpbiBzb21lIGNvc21ldGljcyB0aGF0IGhh
cm1vbml6ZSB0aGUgY29tbWVudHMgd2l0aGltIHRoZW1zZWxmDQphbmQgd2l0aCB0aGUgcmVzdCBv
ZiB0aGUgY29kZSBiYXNlLg0KDQpTaWduZWQtb2ZmLWJ5OiBEYXJpbyBGYWdnaW9saSA8ZGFyaW8u
ZmFnZ2lvbGlAY2l0cml4LmNvbT4NCg0KZGlmZiAtciA1MTA0NWE1ZWM2YmMgeGVuL2NvbW1vbi9z
Y2hlZF9zZWRmLmMNCi0tLSBhL3hlbi9jb21tb24vc2NoZWRfc2VkZi5jCVdlZCBEZWMgMjEgMTQ6
NDk6MDEgMjAxMSArMDAwMA0KKysrIGIveGVuL2NvbW1vbi9zY2hlZF9zZWRmLmMJV2VkIERlYyAy
MSAxNToxMjowNyAyMDExICswMDAwDQpAQCAtMTMsMTQgKzEzLDYgQEANCiAjaW5jbHVkZSA8eGVu
L3RpbWUuaD4NCiAjaW5jbHVkZSA8eGVuL2Vycm5vLmg+DQogDQotLyp2ZXJib3NpdHkgc2V0dGlu
Z3MqLw0KLSNkZWZpbmUgU0VERkxFVkVMIDANCi0jZGVmaW5lIFBSSU5UKF9mLCBfYS4uLikgICAg
ICAgICAgICAgICAgICAgICAgICBcDQotICAgIGRvIHsgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgXA0KLSAgICAgICAgaWYgKCAoX2YpIDw9IFNFREZMRVZFTCApICAgICAg
ICAgICAgICAgIFwNCi0gICAgICAgICAgICBwcmludGsoX2EgKTsgICAgICAgICAgICAgICAgICAg
ICAgICBcDQotICAgIH0gd2hpbGUgKCAwICkNCi0NCiAjZGVmaW5lIFNFREZfQ1BVT05MSU5FKF9w
b29sKSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFwNCiAgICAg
KCgoX3Bvb2wpID09IE5VTEwpID8gJmNwdXBvb2xfZnJlZV9jcHVzIDogKF9wb29sKS0+Y3B1X3Zh
bGlkKQ0KIA0KQEAgLTY2LDM0ICs1OCwzNSBAQCBzdHJ1Y3Qgc2VkZl92Y3B1X2luZm8gew0KICAg
ICBzdHJ1Y3QgbGlzdF9oZWFkIGxpc3Q7DQogICAgIHN0cnVjdCBsaXN0X2hlYWQgZXh0cmFsaXN0
WzJdOw0KICANCi0gICAgLypQYXJhbWV0ZXJzIGZvciBFREYqLw0KLSAgICBzX3RpbWVfdCAgcGVy
aW9kOyAgLyo9KHJlbGF0aXZlIGRlYWRsaW5lKSovDQotICAgIHNfdGltZV90ICBzbGljZTsgIC8q
PXdvcnN0IGNhc2UgZXhlY3V0aW9uIHRpbWUqLw0KKyAgICAvKiBQYXJhbWV0ZXJzIGZvciBFREYg
Ki8NCisgICAgc190aW1lX3QgIHBlcmlvZDsgIC8qID0ocmVsYXRpdmUgZGVhZGxpbmUpICovDQor
ICAgIHNfdGltZV90ICBzbGljZTsgICAvKiA9d29yc3QgY2FzZSBleGVjdXRpb24gdGltZSAqLw0K
ICANCi0gICAgLypBZHZhY2VkIFBhcmFtZXRlcnMqLw0KLSAgICAvKkxhdGVuY3kgU2NhbGluZyov
DQorICAgIC8qIEFkdmFjZWQgUGFyYW1ldGVycyAqLw0KKw0KKyAgICAvKiBMYXRlbmN5IFNjYWxp
bmcgKi8NCiAgICAgc190aW1lX3QgIHBlcmlvZF9vcmlnOw0KICAgICBzX3RpbWVfdCAgc2xpY2Vf
b3JpZzsNCiAgICAgc190aW1lX3QgIGxhdGVuY3k7DQogIA0KLSAgICAvKnN0YXR1cyBvZiBkb21h
aW4qLw0KKyAgICAvKiBTdGF0dXMgb2YgZG9tYWluICovDQogICAgIGludCAgICAgICBzdGF0dXM7
DQotICAgIC8qd2VpZ2h0cyBmb3IgIlNjaGVkdWxpbmcgZm9yIGJlZ2lubmVycy8gbGF6eS8gZXRj
LiIgOykqLw0KKyAgICAvKiBXZWlnaHRzIGZvciAiU2NoZWR1bGluZyBmb3IgYmVnaW5uZXJzLyBs
YXp5LyBldGMuIiA7KSAqLw0KICAgICBzaG9ydCAgICAgd2VpZ2h0Ow0KICAgICBzaG9ydCAgICAg
ZXh0cmF3ZWlnaHQ7DQotICAgIC8qQm9va2tlZXBpbmcqLw0KKyAgICAvKiBCb29ra2VlcGluZyAq
Lw0KICAgICBzX3RpbWVfdCAgZGVhZGxfYWJzOw0KICAgICBzX3RpbWVfdCAgc2NoZWRfc3RhcnRf
YWJzOw0KICAgICBzX3RpbWVfdCAgY3B1dGltZTsNCi0gICAgLyogdGltZXMgdGhlIGRvbWFpbiB1
bi0vYmxvY2tlZCAqLw0KKyAgICAvKiBUaW1lcyB0aGUgZG9tYWluIHVuLS9ibG9ja2VkICovDQog
ICAgIHNfdGltZV90ICBibG9ja19hYnM7DQogICAgIHNfdGltZV90ICB1bmJsb2NrX2FiczsNCiAg
DQotICAgIC8qc2NvcmVzIGZvciB7dXRpbCwgYmxvY2sgcGVuYWx0eX0td2VpZ2h0ZWQgZXh0cmF0
aW1lIGRpc3RyaWJ1dGlvbiovDQorICAgIC8qIFNjb3JlcyBmb3Ige3V0aWwsIGJsb2NrIHBlbmFs
dHl9LXdlaWdodGVkIGV4dHJhdGltZSBkaXN0cmlidXRpb24gKi8NCiAgICAgaW50ICAgc2NvcmVb
Ml07DQogICAgIHNfdGltZV90ICBzaG9ydF9ibG9ja19sb3N0X3RvdDsNCiAgDQotICAgIC8qU3Rh
dGlzdGljcyovDQorICAgIC8qIFN0YXRpc3RpY3MgKi8NCiAgICAgc190aW1lX3QgIGV4dHJhX3Rp
bWVfdG90Ow0KIA0KICNpZmRlZiBTRURGX1NUQVRTDQpAQCAtMTU4LDE4ICsxNTEsMTcgQEAgc3Rh
dGljIGlubGluZSB2b2lkIGV4dHJhcV9kZWwoc3RydWN0IHZjcA0KIHsNCiAgICAgc3RydWN0IGxp
c3RfaGVhZCAqbGlzdCA9IEVYVFJBTElTVChkLGkpOw0KICAgICBBU1NFUlQoZXh0cmFxX29uKGQs
aSkpOw0KLSAgICBQUklOVCgzLCAiUmVtb3ZpbmcgZG9tYWluICVpLiVpIGZyb20gTCVpIGV4dHJh
cVxuIiwNCi0gICAgICAgICAgZC0+ZG9tYWluLT5kb21haW5faWQsIGQtPnZjcHVfaWQsIGkpOw0K
ICAgICBsaXN0X2RlbChsaXN0KTsNCiAgICAgbGlzdC0+bmV4dCA9IE5VTEw7DQogICAgIEFTU0VS
VCghZXh0cmFxX29uKGQsIGkpKTsNCiB9DQogDQotLyogYWRkcyBhIGRvbWFpbiB0byB0aGUgcXVl
dWUgb2YgcHJvY2Vzc2VzIHdoaWNoIGFyZSBhd2FyZSBvZiBleHRyYSB0aW1lLiBMaXN0DQotICAg
aXMgc29ydGVkIGJ5IHNjb3JlLCB3aGVyZSBhIGxvd2VyIHNjb3JlIG1lYW5zIGhpZ2hlciBwcmlv
cml0eSBmb3IgYW4gZXh0cmENCi0gICBzbGljZS4gSXQgYWxzbyB1cGRhdGVzIHRoZSBzY29yZSwg
Ynkgc2ltcGx5IHN1YnRyYWN0aW5nIGEgZml4ZWQgdmFsdWUgZnJvbQ0KLSAgIGVhY2ggZW50cnks
IGluIG9yZGVyIHRvIGF2b2lkIG92ZXJmbG93LiBUaGUgYWxnb3JpdGhtIHdvcmtzIGJ5IHNpbXBs
eQ0KLSAgIGNoYXJnaW5nIGVhY2ggZG9tYWluIHRoYXQgcmVjaWV2ZWQgZXh0cmF0aW1lIHdpdGgg
YW4gaW52ZXJzZSBvZiBpdHMgd2VpZ2h0Lg0KKy8qDQorICogQWRkcyBhIGRvbWFpbiB0byB0aGUg
cXVldWUgb2YgcHJvY2Vzc2VzIHdoaWNoIGFyZSBhd2FyZSBvZiBleHRyYSB0aW1lLiBMaXN0DQor
ICogaXMgc29ydGVkIGJ5IHNjb3JlLCB3aGVyZSBhIGxvd2VyIHNjb3JlIG1lYW5zIGhpZ2hlciBw
cmlvcml0eSBmb3IgYW4gZXh0cmENCisgKiBzbGljZS4gSXQgYWxzbyB1cGRhdGVzIHRoZSBzY29y
ZSwgYnkgc2ltcGx5IHN1YnRyYWN0aW5nIGEgZml4ZWQgdmFsdWUgZnJvbQ0KKyAqIGVhY2ggZW50
cnksIGluIG9yZGVyIHRvIGF2b2lkIG92ZXJmbG93LiBUaGUgYWxnb3JpdGhtIHdvcmtzIGJ5IHNp
bXBseQ0KKyAqIGNoYXJnaW5nIGVhY2ggZG9tYWluIHRoYXQgcmVjaWV2ZWQgZXh0cmF0aW1lIHdp
dGggYW4gaW52ZXJzZSBvZiBpdHMgd2VpZ2h0Lg0KICAqLyANCiBzdGF0aWMgaW5saW5lIHZvaWQg
ZXh0cmFxX2FkZF9zb3J0X3VwZGF0ZShzdHJ1Y3QgdmNwdSAqZCwgaW50IGksIGludCBzdWIpDQog
ew0KQEAgLTE3OCwxMSArMTcwLDYgQEAgc3RhdGljIGlubGluZSB2b2lkIGV4dHJhcV9hZGRfc29y
dF91cGRhdA0KICANCiAgICAgQVNTRVJUKCFleHRyYXFfb24oZCxpKSk7DQogDQotICAgIFBSSU5U
KDMsICJBZGRpbmcgZG9tYWluICVpLiVpIChzY29yZT0gJWksIHNob3J0X3Blbj0gJSJQUklpNjQi
KSINCi0gICAgICAgICAgIiB0byBMJWkgZXh0cmFxXG4iLA0KLSAgICAgICAgICBkLT5kb21haW4t
PmRvbWFpbl9pZCwgZC0+dmNwdV9pZCwgRURPTV9JTkZPKGQpLT5zY29yZVtpXSwNCi0gICAgICAg
ICAgRURPTV9JTkZPKGQpLT5zaG9ydF9ibG9ja19sb3N0X3RvdCwgaSk7DQotDQogICAgIC8qDQog
ICAgICAqIEl0ZXJhdGUgdGhyb3VnaCBhbGwgZWxlbWVudHMgdG8gZmluZCBvdXIgImhvbGUiIGFu
ZCBvbiBvdXIgd2F5DQogICAgICAqIHVwZGF0ZSBhbGwgdGhlIG90aGVyIHNjb3Jlcy4NCkBAIC0x
OTMsMjUgKzE4MCwxOCBAQCBzdGF0aWMgaW5saW5lIHZvaWQgZXh0cmFxX2FkZF9zb3J0X3VwZGF0
DQogICAgICAgICBjdXJpbmYtPnNjb3JlW2ldIC09IHN1YjsNCiAgICAgICAgIGlmICggRURPTV9J
TkZPKGQpLT5zY29yZVtpXSA8IGN1cmluZi0+c2NvcmVbaV0gKQ0KICAgICAgICAgICAgIGJyZWFr
Ow0KLSAgICAgICAgUFJJTlQoNCwiXHRiZWhpbmQgZG9tYWluICVpLiVpIChzY29yZT0gJWkpXG4i
LA0KLSAgICAgICAgICAgICAgY3VyaW5mLT52Y3B1LT5kb21haW4tPmRvbWFpbl9pZCwNCi0gICAg
ICAgICAgICAgIGN1cmluZi0+dmNwdS0+dmNwdV9pZCwgY3VyaW5mLT5zY29yZVtpXSk7DQogICAg
IH0NCiANCi0gICAgLyogY3VyIG5vdyBjb250YWlucyB0aGUgZWxlbWVudCwgYmVmb3JlIHdoaWNo
IHdlJ2xsIGVucXVldWUuICovDQotICAgIFBSSU5UKDMsICJcdGxpc3RfYWRkIHRvICVwXG4iLCBj
dXItPnByZXYpOw0KKyAgICAvKiBjdXIgbm93IGNvbnRhaW5zIHRoZSBlbGVtZW50LCBiZWZvcmUg
d2hpY2ggd2UnbGwgZW5xdWV1ZSAqLw0KICAgICBsaXN0X2FkZChFWFRSQUxJU1QoZCxpKSxjdXIt
PnByZXYpOw0KICANCi0gICAgLyogQ29udGludWUgdXBkYXRpbmcgdGhlIGV4dHJhcS4gKi8NCisg
ICAgLyogQ29udGludWUgdXBkYXRpbmcgdGhlIGV4dHJhcSAqLw0KICAgICBpZiAoIChjdXIgIT0g
RVhUUkFRKGQtPnByb2Nlc3NvcixpKSkgJiYgc3ViICkNCiAgICAgew0KICAgICAgICAgZm9yICgg
Y3VyID0gY3VyLT5uZXh0OyBjdXIgIT0gRVhUUkFRKGQtPnByb2Nlc3NvcixpKTsgY3VyID0gY3Vy
LT5uZXh0ICkNCiAgICAgICAgIHsNCiAgICAgICAgICAgICBjdXJpbmYgPSBsaXN0X2VudHJ5KGN1
cixzdHJ1Y3Qgc2VkZl92Y3B1X2luZm8sIGV4dHJhbGlzdFtpXSk7DQogICAgICAgICAgICAgY3Vy
aW5mLT5zY29yZVtpXSAtPSBzdWI7DQotICAgICAgICAgICAgUFJJTlQoNCwgIlx0dXBkYXRpbmcg
ZG9tYWluICVpLiVpIChzY29yZT0gJXUpXG4iLA0KLSAgICAgICAgICAgICAgICAgIGN1cmluZi0+
dmNwdS0+ZG9tYWluLT5kb21haW5faWQsIA0KLSAgICAgICAgICAgICAgICAgIGN1cmluZi0+dmNw
dS0+dmNwdV9pZCwgY3VyaW5mLT5zY29yZVtpXSk7DQogICAgICAgICB9DQogICAgIH0NCiANCkBA
IC0yMjEsMjkgKzIwMSwxNCBAQCBzdGF0aWMgaW5saW5lIHZvaWQgZXh0cmFxX2NoZWNrKHN0cnVj
dCB2DQogew0KICAgICBpZiAoIGV4dHJhcV9vbihkLCBFWFRSQV9VVElMX1EpICkNCiAgICAgew0K
LSAgICAgICAgUFJJTlQoMiwiRG9tICVpLiVpIGlzIG9uIEwxIGV4dHJhUVxuIiwNCi0gICAgICAg
ICAgICAgIGQtPmRvbWFpbi0+ZG9tYWluX2lkLCBkLT52Y3B1X2lkKTsNCi0NCiAgICAgICAgIGlm
ICggIShFRE9NX0lORk8oZCktPnN0YXR1cyAmIEVYVFJBX0FXQVJFKSAmJg0KICAgICAgICAgICAg
ICAhZXh0cmFfcnVucyhFRE9NX0lORk8oZCkpICkNCi0gICAgICAgIHsNCiAgICAgICAgICAgICBl
eHRyYXFfZGVsKGQsIEVYVFJBX1VUSUxfUSk7DQotICAgICAgICAgICAgUFJJTlQoMiwiUmVtb3Zl
ZCBkb20gJWkuJWkgZnJvbSBMMSBleHRyYVFcbiIsDQotICAgICAgICAgICAgICAgICAgZC0+ZG9t
YWluLT5kb21haW5faWQsIGQtPnZjcHVfaWQpOw0KLSAgICAgICAgfQ0KICAgICB9DQogICAgIGVs
c2UNCiAgICAgew0KLSAgICAgICAgUFJJTlQoMiwgIkRvbSAlaS4laSBpcyBOT1Qgb24gTDEgZXh0
cmFRXG4iLA0KLSAgICAgICAgICAgICAgZC0+ZG9tYWluLT5kb21haW5faWQsDQotICAgICAgICAg
ICAgICBkLT52Y3B1X2lkKTsNCi0NCiAgICAgICAgIGlmICggKEVET01fSU5GTyhkKS0+c3RhdHVz
ICYgRVhUUkFfQVdBUkUpICYmIHNlZGZfcnVubmFibGUoZCkgKQ0KLSAgICAgICAgew0KICAgICAg
ICAgICAgIGV4dHJhcV9hZGRfc29ydF91cGRhdGUoZCwgRVhUUkFfVVRJTF9RLCAwKTsNCi0gICAg
ICAgICAgICBQUklOVCgyLCJBZGRlZCBkb20gJWkuJWkgdG8gTDEgZXh0cmFRXG4iLA0KLSAgICAg
ICAgICAgICAgICAgIGQtPmRvbWFpbi0+ZG9tYWluX2lkLCBkLT52Y3B1X2lkKTsNCi0gICAgICAg
IH0NCiAgICAgfQ0KIH0NCiANCkBAIC0yNTIsNyArMjE3LDcgQEAgc3RhdGljIGlubGluZSB2b2lk
IGV4dHJhcV9jaGVja19hZGRfdW5ibA0KICAgICBzdHJ1Y3Qgc2VkZl92Y3B1X2luZm8gKmluZiA9
IEVET01fSU5GTyhkKTsNCiANCiAgICAgaWYgKCBpbmYtPnN0YXR1cyAmIEVYVFJBX0FXQVJFICkN
Ci0gICAgICAgIC8qIFB1dCBvbiB0aGUgd2VpZ2h0ZWQgZXh0cmFxIHdpdGhvdXQgdXBkYXRpbmcg
YW55IHNjb3Jlcy4gKi8NCisgICAgICAgIC8qIFB1dCBvbiB0aGUgd2VpZ2h0ZWQgZXh0cmFxIHdp
dGhvdXQgdXBkYXRpbmcgYW55IHNjb3JlcyAqLw0KICAgICAgICAgZXh0cmFxX2FkZF9zb3J0X3Vw
ZGF0ZShkLCBFWFRSQV9VVElMX1EsIDApOw0KIH0NCiANCkBAIC0yNjUsOCArMjMwLDYgQEAgc3Rh
dGljIGlubGluZSB2b2lkIF9fZGVsX2Zyb21fcXVldWUoc3RydQ0KIHsNCiAgICAgc3RydWN0IGxp
c3RfaGVhZCAqbGlzdCA9IExJU1QoZCk7DQogICAgIEFTU0VSVChfX3Rhc2tfb25fcXVldWUoZCkp
Ow0KLSAgICBQUklOVCgzLCJSZW1vdmluZyBkb21haW4gJWkuJWkgKGJvcD0gJSJQUkl1NjQiKSBm
cm9tIHJ1bnEvd2FpdHFcbiIsDQotICAgICAgICAgIGQtPmRvbWFpbi0+ZG9tYWluX2lkLCBkLT52
Y3B1X2lkLCBQRVJJT0RfQkVHSU4oRURPTV9JTkZPKGQpKSk7DQogICAgIGxpc3RfZGVsKGxpc3Qp
Ow0KICAgICBsaXN0LT5uZXh0ID0gTlVMTDsNCiAgICAgQVNTRVJUKCFfX3Rhc2tfb25fcXVldWUo
ZCkpOw0KQEAgLTI3OSwxMyArMjQyLDEyIEBAIHN0YXRpYyBpbmxpbmUgdm9pZCBsaXN0X2luc2Vy
dF9zb3J0KA0KIHsNCiAgICAgc3RydWN0IGxpc3RfaGVhZCAgICAgKmN1cjsNCiANCi0gICAgLyog
SXRlcmF0ZSB0aHJvdWdoIGFsbCBlbGVtZW50cyB0byBmaW5kIG91ciAiaG9sZSIuICovDQorICAg
IC8qIEl0ZXJhdGUgdGhyb3VnaCBhbGwgZWxlbWVudHMgdG8gZmluZCBvdXIgImhvbGUiICovDQog
ICAgIGxpc3RfZm9yX2VhY2goIGN1ciwgbGlzdCApDQogICAgICAgICBpZiAoIGNvbXAoZWxlbWVu
dCwgY3VyKSA8IDAgKQ0KICAgICAgICAgICAgIGJyZWFrOw0KIA0KLSAgICAvKiBjdXIgbm93IGNv
bnRhaW5zIHRoZSBlbGVtZW50LCBiZWZvcmUgd2hpY2ggd2UnbGwgZW5xdWV1ZS4gKi8NCi0gICAg
UFJJTlQoMywiXHRsaXN0X2FkZCB0byAlcFxuIixjdXItPnByZXYpOw0KKyAgICAvKiBjdXIgbm93
IGNvbnRhaW5zIHRoZSBlbGVtZW50LCBiZWZvcmUgd2hpY2ggd2UnbGwgZW5xdWV1ZSAqLw0KICAg
ICBsaXN0X2FkZChlbGVtZW50LCBjdXItPnByZXYpOw0KIH0NCiANCkBAIC0zMDMsMzAgKzI2NSwy
OCBAQCBzdGF0aWMgaW50IG5hbWUjI19jb21wKHN0cnVjdCBsaXN0X2hlYWQqDQogICAgICAgICBy
ZXR1cm4gMTsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgXA0KIH0NCiANCi0vKiBhZGRzIGEgZG9tYWluIHRvIHRoZSBxdWV1ZSBvZiBwcm9jZXNz
ZXMgd2hpY2ggd2FpdCBmb3IgdGhlIGJlZ2lubmluZyBvZiB0aGUNCi0gICBuZXh0IHBlcmlvZDsg
dGhpcyBsaXN0IGlzIHRoZXJlZm9yZSBzb3J0ZXQgYnkgdGhpcyB0aW1lLCB3aGljaCBpcyBzaW1w
bHkNCi0gICBhYnNvbC4gZGVhZGxpbmUgLSBwZXJpb2QNCisvKg0KKyAqIEFkZHMgYSBkb21haW4g
dG8gdGhlIHF1ZXVlIG9mIHByb2Nlc3NlcyB3aGljaCB3YWl0IGZvciB0aGUgYmVnaW5uaW5nIG9m
IHRoZQ0KKyAqIG5leHQgcGVyaW9kOyB0aGlzIGxpc3QgaXMgdGhlcmVmb3JlIHNvcnRldCBieSB0
aGlzIHRpbWUsIHdoaWNoIGlzIHNpbXBseQ0KKyAqIGFic29sLiBkZWFkbGluZSAtIHBlcmlvZC4N
CiAgKi8gDQogRE9NQUlOX0NPTVBBUkVSKHdhaXRxLCBsaXN0LCBQRVJJT0RfQkVHSU4oZDEpLCBQ
RVJJT0RfQkVHSU4oZDIpKTsNCiBzdGF0aWMgaW5saW5lIHZvaWQgX19hZGRfdG9fd2FpdHF1ZXVl
X3NvcnQoc3RydWN0IHZjcHUgKnYpDQogew0KICAgICBBU1NFUlQoIV9fdGFza19vbl9xdWV1ZSh2
KSk7DQotICAgIFBSSU5UKDMsIkFkZGluZyBkb21haW4gJWkuJWkgKGJvcD0gJSJQUkl1NjQiKSB0
byB3YWl0cVxuIiwNCi0gICAgICAgICAgdi0+ZG9tYWluLT5kb21haW5faWQsIHYtPnZjcHVfaWQs
IFBFUklPRF9CRUdJTihFRE9NX0lORk8odikpKTsNCiAgICAgbGlzdF9pbnNlcnRfc29ydChXQUlU
USh2LT5wcm9jZXNzb3IpLCBMSVNUKHYpLCB3YWl0cV9jb21wKTsNCiAgICAgQVNTRVJUKF9fdGFz
a19vbl9xdWV1ZSh2KSk7DQogfQ0KIA0KLS8qIGFkZHMgYSBkb21haW4gdG8gdGhlIHF1ZXVlIG9m
IHByb2Nlc3NlcyB3aGljaCBoYXZlIHN0YXJ0ZWQgdGhlaXIgY3VycmVudA0KLSAgIHBlcmlvZCBh
bmQgYXJlIHJ1bm5hYmxlIChpLmUuIG5vdCBibG9ja2VkLCBkaWVpbmcsLi4uKS4gVGhlIGZpcnN0
IGVsZW1lbnQNCi0gICBvbiB0aGlzIGxpc3QgaXMgcnVubmluZyBvbiB0aGUgcHJvY2Vzc29yLCBp
ZiB0aGUgbGlzdCBpcyBlbXB0eSB0aGUgaWRsZQ0KLSAgIHRhc2sgd2lsbCBydW4uIEFzIHdlIGFy
ZSBpbXBsZW1lbnRpbmcgRURGLCB0aGlzIGxpc3QgaXMgc29ydGVkIGJ5IGRlYWRsaW5lcy4NCisv
Kg0KKyAqIEFkZHMgYSBkb21haW4gdG8gdGhlIHF1ZXVlIG9mIHByb2Nlc3NlcyB3aGljaCBoYXZl
IHN0YXJ0ZWQgdGhlaXIgY3VycmVudA0KKyAqIHBlcmlvZCBhbmQgYXJlIHJ1bm5hYmxlIChpLmUu
IG5vdCBibG9ja2VkLCBkaWVpbmcsLi4uKS4gVGhlIGZpcnN0IGVsZW1lbnQNCisgKiBvbiB0aGlz
IGxpc3QgaXMgcnVubmluZyBvbiB0aGUgcHJvY2Vzc29yLCBpZiB0aGUgbGlzdCBpcyBlbXB0eSB0
aGUgaWRsZQ0KKyAqIHRhc2sgd2lsbCBydW4uIEFzIHdlIGFyZSBpbXBsZW1lbnRpbmcgRURGLCB0
aGlzIGxpc3QgaXMgc29ydGVkIGJ5IGRlYWRsaW5lcy4NCiAgKi8gDQogRE9NQUlOX0NPTVBBUkVS
KHJ1bnEsIGxpc3QsIGQxLT5kZWFkbF9hYnMsIGQyLT5kZWFkbF9hYnMpOw0KIHN0YXRpYyBpbmxp
bmUgdm9pZCBfX2FkZF90b19ydW5xdWV1ZV9zb3J0KHN0cnVjdCB2Y3B1ICp2KQ0KIHsNCi0gICAg
UFJJTlQoMywiQWRkaW5nIGRvbWFpbiAlaS4laSAoZGVhZGw9ICUiUFJJdTY0IikgdG8gcnVucVxu
IiwNCi0gICAgICAgICAgdi0+ZG9tYWluLT5kb21haW5faWQsIHYtPnZjcHVfaWQsIEVET01fSU5G
Tyh2KS0+ZGVhZGxfYWJzKTsNCiAgICAgbGlzdF9pbnNlcnRfc29ydChSVU5RKHYtPnByb2Nlc3Nv
ciksIExJU1QodiksIHJ1bnFfY29tcCk7DQogfQ0KIA0KQEAgLTQ1MywxMCArNDEzLDEwIEBAIHN0
YXRpYyB2b2lkIGRlc2NoZWRfZWRmX2RvbShzX3RpbWVfdCBub3cNCiB7DQogICAgIHN0cnVjdCBz
ZWRmX3ZjcHVfaW5mbyogaW5mID0gRURPTV9JTkZPKGQpOw0KIA0KLSAgICAvKiBDdXJyZW50IGRv
bWFpbiBpcyBydW5uaW5nIGluIHJlYWwgdGltZSBtb2RlLiAqLw0KKyAgICAvKiBDdXJyZW50IGRv
bWFpbiBpcyBydW5uaW5nIGluIHJlYWwgdGltZSBtb2RlICovDQogICAgIEFTU0VSVChfX3Rhc2tf
b25fcXVldWUoZCkpOw0KIA0KLSAgICAvKiBVcGRhdGUgdGhlIGRvbWFpbidzIGNwdXRpbWUuICov
DQorICAgIC8qIFVwZGF0ZSB0aGUgZG9tYWluJ3MgY3B1dGltZSAqLw0KICAgICBpbmYtPmNwdXRp
bWUgKz0gbm93IC0gaW5mLT5zY2hlZF9zdGFydF9hYnM7DQogDQogICAgIC8qDQpAQCAtNDY3LDcg
KzQyNyw3IEBAIHN0YXRpYyB2b2lkIGRlc2NoZWRfZWRmX2RvbShzX3RpbWVfdCBub3cNCiAgICAg
ICAgIHJldHVybjsNCiAgIA0KICAgICBfX2RlbF9mcm9tX3F1ZXVlKGQpOw0KLSAgDQorDQogICAg
IC8qDQogICAgICAqIE1hbmFnZSBib29ra2VlcGluZyAoaS5lLiBjYWxjdWxhdGUgbmV4dCBkZWFk
bGluZSwgbWVtb3Jpc2UNCiAgICAgICogb3ZlcnJ1bi10aW1lIG9mIHNsaWNlKSBvZiBmaW5pc2hl
ZCBkb21haW5zLg0KQEAgLTQ3OCwzMCArNDM4LDMwIEBAIHN0YXRpYyB2b2lkIGRlc2NoZWRfZWRm
X2RvbShzX3RpbWVfdCBub3cNCiAgIA0KICAgICAgICAgaWYgKCBpbmYtPnBlcmlvZCA8IGluZi0+
cGVyaW9kX29yaWcgKQ0KICAgICAgICAgew0KLSAgICAgICAgICAgIC8qIFRoaXMgZG9tYWluIHJ1
bnMgaW4gbGF0ZW5jeSBzY2FsaW5nIG9yIGJ1cnN0IG1vZGUuICovDQorICAgICAgICAgICAgLyog
VGhpcyBkb21haW4gcnVucyBpbiBsYXRlbmN5IHNjYWxpbmcgb3IgYnVyc3QgbW9kZSAqLw0KICAg
ICAgICAgICAgIGluZi0+cGVyaW9kICo9IDI7DQogICAgICAgICAgICAgaW5mLT5zbGljZSAgKj0g
MjsNCiAgICAgICAgICAgICBpZiAoIChpbmYtPnBlcmlvZCA+IGluZi0+cGVyaW9kX29yaWcpIHx8
DQogICAgICAgICAgICAgICAgICAoaW5mLT5zbGljZSA+IGluZi0+c2xpY2Vfb3JpZykgKQ0KICAg
ICAgICAgICAgIHsNCi0gICAgICAgICAgICAgICAgLyogUmVzZXQgc2xpY2UgYW5kIHBlcmlvZC4g
Ki8NCisgICAgICAgICAgICAgICAgLyogUmVzZXQgc2xpY2UgYW5kIHBlcmlvZCAqLw0KICAgICAg
ICAgICAgICAgICBpbmYtPnBlcmlvZCA9IGluZi0+cGVyaW9kX29yaWc7DQogICAgICAgICAgICAg
ICAgIGluZi0+c2xpY2UgPSBpbmYtPnNsaWNlX29yaWc7DQogICAgICAgICAgICAgfQ0KICAgICAg
ICAgfQ0KIA0KLSAgICAgICAgLyogU2V0IG5leHQgZGVhZGxpbmUuICovDQorICAgICAgICAvKiBT
ZXQgbmV4dCBkZWFkbGluZSAqLw0KICAgICAgICAgaW5mLT5kZWFkbF9hYnMgKz0gaW5mLT5wZXJp
b2Q7DQogICAgIH0NCiAgDQotICAgIC8qIEFkZCBhIHJ1bm5hYmxlIGRvbWFpbiB0byB0aGUgd2Fp
dHF1ZXVlLiAqLw0KKyAgICAvKiBBZGQgYSBydW5uYWJsZSBkb21haW4gdG8gdGhlIHdhaXRxdWV1
ZSAqLw0KICAgICBpZiAoIHNlZGZfcnVubmFibGUoZCkgKQ0KICAgICB7DQogICAgICAgICBfX2Fk
ZF90b193YWl0cXVldWVfc29ydChkKTsNCiAgICAgfQ0KICAgICBlbHNlDQogICAgIHsNCi0gICAg
ICAgIC8qIFdlIGhhdmUgYSBibG9ja2VkIHJlYWx0aW1lIHRhc2sgLT4gcmVtb3ZlIGl0IGZyb20g
ZXhxcyB0b28uICovDQorICAgICAgICAvKiBXZSBoYXZlIGEgYmxvY2tlZCByZWFsdGltZSB0YXNr
IC0+IHJlbW92ZSBpdCBmcm9tIGV4cXMgdG9vICovDQogICAgICAgICBpZiAoIGV4dHJhcV9vbihk
LCBFWFRSQV9QRU5fUSkgKQ0KICAgICAgICAgICAgIGV4dHJhcV9kZWwoZCwgRVhUUkFfUEVOX1Ep
Ow0KICAgICAgICAgaWYgKCBleHRyYXFfb24oZCwgRVhUUkFfVVRJTF9RKSApDQpAQCAtNTIxLDgg
KzQ4MSw2IEBAIHN0YXRpYyB2b2lkIHVwZGF0ZV9xdWV1ZXMoDQogICAgIHN0cnVjdCBsaXN0X2hl
YWQgICAgICpjdXIsICp0bXA7DQogICAgIHN0cnVjdCBzZWRmX3ZjcHVfaW5mbyAqY3VyaW5mOw0K
ICANCi0gICAgUFJJTlQoMywiVXBkYXRpbmcgd2FpdHEuLlxuIik7DQotDQogICAgIC8qDQogICAg
ICAqIENoZWNrIGZvciB0aGUgZmlyc3QgZWxlbWVudHMgb2YgdGhlIHdhaXRxdWV1ZSwgd2hldGhl
ciB0aGVpcg0KICAgICAgKiBuZXh0IHBlcmlvZCBoYXMgYWxyZWFkeSBzdGFydGVkLg0KQEAgLTUz
MCw0MSArNDg4LDMyIEBAIHN0YXRpYyB2b2lkIHVwZGF0ZV9xdWV1ZXMoDQogICAgIGxpc3RfZm9y
X2VhY2hfc2FmZSAoIGN1ciwgdG1wLCB3YWl0cSApDQogICAgIHsNCiAgICAgICAgIGN1cmluZiA9
IGxpc3RfZW50cnkoY3VyLCBzdHJ1Y3Qgc2VkZl92Y3B1X2luZm8sIGxpc3QpOw0KLSAgICAgICAg
UFJJTlQoNCwiXHRMb29raW5nIEAgZG9tICVpLiVpXG4iLA0KLSAgICAgICAgICAgICAgY3VyaW5m
LT52Y3B1LT5kb21haW4tPmRvbWFpbl9pZCwgY3VyaW5mLT52Y3B1LT52Y3B1X2lkKTsNCiAgICAg
ICAgIGlmICggUEVSSU9EX0JFR0lOKGN1cmluZikgPiBub3cgKQ0KICAgICAgICAgICAgIGJyZWFr
Ow0KICAgICAgICAgX19kZWxfZnJvbV9xdWV1ZShjdXJpbmYtPnZjcHUpOw0KICAgICAgICAgX19h
ZGRfdG9fcnVucXVldWVfc29ydChjdXJpbmYtPnZjcHUpOw0KICAgICB9DQogIA0KLSAgICBQUklO
VCgzLCJVcGRhdGluZyBydW5xLi5cbiIpOw0KLQ0KLSAgICAvKiBQcm9jZXNzIHRoZSBydW5xLCBm
aW5kIGRvbWFpbnMgdGhhdCBhcmUgb24gdGhlIHJ1bnEgdGhhdCBzaG91bGRuJ3QuICovDQorICAg
IC8qIFByb2Nlc3MgdGhlIHJ1bnEsIGZpbmQgZG9tYWlucyB0aGF0IGFyZSBvbiB0aGUgcnVucSB0
aGF0IHNob3VsZG4ndCAqLw0KICAgICBsaXN0X2Zvcl9lYWNoX3NhZmUgKCBjdXIsIHRtcCwgcnVu
cSApDQogICAgIHsNCiAgICAgICAgIGN1cmluZiA9IGxpc3RfZW50cnkoY3VyLHN0cnVjdCBzZWRm
X3ZjcHVfaW5mbyxsaXN0KTsNCi0gICAgICAgIFBSSU5UKDQsIlx0TG9va2luZyBAIGRvbSAlaS4l
aVxuIiwNCi0gICAgICAgICAgICAgIGN1cmluZi0+dmNwdS0+ZG9tYWluLT5kb21haW5faWQsIGN1
cmluZi0+dmNwdS0+dmNwdV9pZCk7DQogDQogICAgICAgICBpZiAoIHVubGlrZWx5KGN1cmluZi0+
c2xpY2UgPT0gMCkgKQ0KICAgICAgICAgew0KLSAgICAgICAgICAgIC8qIElnbm9yZSBkb21haW5z
IHdpdGggZW1wdHkgc2xpY2UuICovDQotICAgICAgICAgICAgUFJJTlQoNCwiXHRVcGRhdGluZyB6
ZXJvLXNsaWNlIGRvbWFpbiAlaS4laVxuIiwNCi0gICAgICAgICAgICAgICAgICBjdXJpbmYtPnZj
cHUtPmRvbWFpbi0+ZG9tYWluX2lkLA0KLSAgICAgICAgICAgICAgICAgIGN1cmluZi0+dmNwdS0+
dmNwdV9pZCk7DQorICAgICAgICAgICAgLyogSWdub3JlIGRvbWFpbnMgd2l0aCBlbXB0eSBzbGlj
ZSAqLw0KICAgICAgICAgICAgIF9fZGVsX2Zyb21fcXVldWUoY3VyaW5mLT52Y3B1KTsNCiANCi0g
ICAgICAgICAgICAvKiBNb3ZlIHRoZW0gdG8gdGhlaXIgbmV4dCBwZXJpb2QuICovDQorICAgICAg
ICAgICAgLyogTW92ZSB0aGVtIHRvIHRoZWlyIG5leHQgcGVyaW9kICovDQogICAgICAgICAgICAg
Y3VyaW5mLT5kZWFkbF9hYnMgKz0gY3VyaW5mLT5wZXJpb2Q7DQogDQotICAgICAgICAgICAgLyog
RW5zdXJlIHRoYXQgdGhlIHN0YXJ0IG9mIHRoZSBuZXh0IHBlcmlvZCBpcyBpbiB0aGUgZnV0dXJl
LiAqLw0KKyAgICAgICAgICAgIC8qIEVuc3VyZSB0aGF0IHRoZSBzdGFydCBvZiB0aGUgbmV4dCBw
ZXJpb2QgaXMgaW4gdGhlIGZ1dHVyZSAqLw0KICAgICAgICAgICAgIGlmICggdW5saWtlbHkoUEVS
SU9EX0JFR0lOKGN1cmluZikgPCBub3cpICkNCiAgICAgICAgICAgICAgICAgY3VyaW5mLT5kZWFk
bF9hYnMgKz0gDQogICAgICAgICAgICAgICAgICAgICAoRElWX1VQKG5vdyAtIFBFUklPRF9CRUdJ
TihjdXJpbmYpLA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICBjdXJpbmYtPnBlcmlvZCkp
ICogY3VyaW5mLT5wZXJpb2Q7DQogDQotICAgICAgICAgICAgLyogUHV0IHRoZW0gYmFjayBpbnRv
IHRoZSBxdWV1ZS4gKi8NCisgICAgICAgICAgICAvKiBQdXQgdGhlbSBiYWNrIGludG8gdGhlIHF1
ZXVlICovDQogICAgICAgICAgICAgX19hZGRfdG9fd2FpdHF1ZXVlX3NvcnQoY3VyaW5mLT52Y3B1
KTsNCiAgICAgICAgIH0NCiAgICAgICAgIGVsc2UgaWYgKCB1bmxpa2VseSgoY3VyaW5mLT5kZWFk
bF9hYnMgPCBub3cpIHx8DQpAQCAtNTc0LDE4ICs1MjMsMTggQEAgc3RhdGljIHZvaWQgdXBkYXRl
X3F1ZXVlcygNCiAgICAgICAgICAgICAgKiBXZSBtaXNzZWQgdGhlIGRlYWRsaW5lIG9yIHRoZSBz
bGljZSB3YXMgYWxyZWFkeSBmaW5pc2hlZC4NCiAgICAgICAgICAgICAgKiBNaWdodCBoYXBlbiBi
ZWNhdXNlIG9mIGRvbV9hZGouDQogICAgICAgICAgICAgICovDQotICAgICAgICAgICAgUFJJTlQo
NCwiXHREb21haW4gJWkuJWkgZXhjZWVkZWQgaXQncyBkZWFkbGluZS8iDQotICAgICAgICAgICAg
ICAgICAgInNsaWNlICglIlBSSXU2NCIgLyAlIlBSSXU2NCIpIG5vdzogJSJQUkl1NjQNCi0gICAg
ICAgICAgICAgICAgICAiIGNwdXRpbWU6ICUiUFJJdTY0IlxuIiwNCi0gICAgICAgICAgICAgICAg
ICBjdXJpbmYtPnZjcHUtPmRvbWFpbi0+ZG9tYWluX2lkLA0KLSAgICAgICAgICAgICAgICAgIGN1
cmluZi0+dmNwdS0+dmNwdV9pZCwNCi0gICAgICAgICAgICAgICAgICBjdXJpbmYtPmRlYWRsX2Fi
cywgY3VyaW5mLT5zbGljZSwgbm93LA0KLSAgICAgICAgICAgICAgICAgIGN1cmluZi0+Y3B1dGlt
ZSk7DQorICAgICAgICAgICAgcHJpbnRrKCJcdERvbWFpbiAlaS4laSBleGNlZWRlZCBpdCdzIGRl
YWRsaW5lLyINCisgICAgICAgICAgICAgICAgICAgInNsaWNlICglIlBSSXU2NCIgLyAlIlBSSXU2
NCIpIG5vdzogJSJQUkl1NjQNCisgICAgICAgICAgICAgICAgICAgIiBjcHV0aW1lOiAlIlBSSXU2
NCJcbiIsDQorICAgICAgICAgICAgICAgICAgIGN1cmluZi0+dmNwdS0+ZG9tYWluLT5kb21haW5f
aWQsDQorICAgICAgICAgICAgICAgICAgIGN1cmluZi0+dmNwdS0+dmNwdV9pZCwNCisgICAgICAg
ICAgICAgICAgICAgY3VyaW5mLT5kZWFkbF9hYnMsIGN1cmluZi0+c2xpY2UsIG5vdywNCisgICAg
ICAgICAgICAgICAgICAgY3VyaW5mLT5jcHV0aW1lKTsNCiAgICAgICAgICAgICBfX2RlbF9mcm9t
X3F1ZXVlKGN1cmluZi0+dmNwdSk7DQogDQotICAgICAgICAgICAgLyogQ29tbW9uIGNhc2U6IHdl
IG1pc3Mgb25lIHBlcmlvZC4gKi8NCisgICAgICAgICAgICAvKiBDb21tb24gY2FzZTogd2UgbWlz
cyBvbmUgcGVyaW9kICovDQogICAgICAgICAgICAgY3VyaW5mLT5kZWFkbF9hYnMgKz0gY3VyaW5m
LT5wZXJpb2Q7DQotICAgDQorDQogICAgICAgICAgICAgLyoNCiAgICAgICAgICAgICAgKiBJZiB3
ZSBhcmUgc3RpbGwgYmVoaW5kOiBtb2R1bG8gYXJpdGhtZXRpYywgZm9yY2UgZGVhZGxpbmUNCiAg
ICAgICAgICAgICAgKiB0byBiZSBpbiBmdXR1cmUgYW5kIGFsaWduZWQgdG8gcGVyaW9kIGJvcmRl
cnMuDQpAQCAtNTk2LDcgKzU0NSw3IEBAIHN0YXRpYyB2b2lkIHVwZGF0ZV9xdWV1ZXMoDQogICAg
ICAgICAgICAgICAgICAgICAgICAgICAgY3VyaW5mLT5wZXJpb2QpICogY3VyaW5mLT5wZXJpb2Q7
DQogICAgICAgICAgICAgQVNTRVJUKGN1cmluZi0+ZGVhZGxfYWJzID49IG5vdyk7DQogDQotICAg
ICAgICAgICAgLyogR2l2ZSBhIGZyZXNoIHNsaWNlLiAqLw0KKyAgICAgICAgICAgIC8qIEdpdmUg
YSBmcmVzaCBzbGljZSAqLw0KICAgICAgICAgICAgIGN1cmluZi0+Y3B1dGltZSA9IDA7DQogICAg
ICAgICAgICAgaWYgKCBQRVJJT0RfQkVHSU4oY3VyaW5mKSA+IG5vdyApDQogICAgICAgICAgICAg
ICAgIF9fYWRkX3RvX3dhaXRxdWV1ZV9zb3J0KGN1cmluZi0+dmNwdSk7DQpAQCAtNjA2LDE3ICs1
NTUsMTcgQEAgc3RhdGljIHZvaWQgdXBkYXRlX3F1ZXVlcygNCiAgICAgICAgIGVsc2UNCiAgICAg
ICAgICAgICBicmVhazsNCiAgICAgfQ0KLQ0KLSAgICBQUklOVCgzLCJkb25lIHVwZGF0aW5nIHRo
ZSBxdWV1ZXNcbiIpOw0KIH0NCiANCiANCi0vKiByZW1vdmVzIGEgZG9tYWluIGZyb20gdGhlIGhl
YWQgb2YgdGhlIGFjY29yZGluZyBleHRyYVEgYW5kDQotICAgcmVxdWV1ZXMgaXQgYXQgYSBzcGVj
aWZpZWQgcG9zaXRpb246DQotICAgICByb3VuZC1yb2JpbiBleHRyYXRpbWU6IGVuZCBvZiBleHRy
YVENCi0gICAgIHdlaWdodGVkIGV4dC46IGluc2VydCBpbiBzb3J0ZWQgbGlzdCBieSBzY29yZQ0K
LSAgIGlmIHRoZSBkb21haW4gaXMgYmxvY2tlZCAvIGhhcyByZWdhaW5lZCBpdHMgc2hvcnQtYmxv
Y2stbG9zcw0KLSAgIHRpbWUgaXQgaXMgbm90IHB1dCBvbiBhbnkgcXVldWUgKi8NCisvKg0KKyAq
IHJlbW92ZXMgYSBkb21haW4gZnJvbSB0aGUgaGVhZCBvZiB0aGUgYWNjb3JkaW5nIGV4dHJhUSBh
bmQNCisgKiByZXF1ZXVlcyBpdCBhdCBhIHNwZWNpZmllZCBwb3NpdGlvbjoNCisgKiAgIHJvdW5k
LXJvYmluIGV4dHJhdGltZTogZW5kIG9mIGV4dHJhUQ0KKyAqICAgd2VpZ2h0ZWQgZXh0LjogaW5z
ZXJ0IGluIHNvcnRlZCBsaXN0IGJ5IHNjb3JlDQorICogaWYgdGhlIGRvbWFpbiBpcyBibG9ja2Vk
IC8gaGFzIHJlZ2FpbmVkIGl0cyBzaG9ydC1ibG9jay1sb3NzDQorICogdGltZSBpdCBpcyBub3Qg
cHV0IG9uIGFueSBxdWV1ZS4NCisgKi8NCiBzdGF0aWMgdm9pZCBkZXNjaGVkX2V4dHJhX2RvbShz
X3RpbWVfdCBub3csIHN0cnVjdCB2Y3B1ICpkKQ0KIHsNCiAgICAgc3RydWN0IHNlZGZfdmNwdV9p
bmZvICppbmYgPSBFRE9NX0lORk8oZCk7DQpAQCAtNjI1LDI5ICs1NzQsMjUgQEAgc3RhdGljIHZv
aWQgZGVzY2hlZF9leHRyYV9kb20oc190aW1lX3Qgbg0KIA0KICAgICBBU1NFUlQoZXh0cmFxX29u
KGQsIGkpKTsNCiANCi0gICAgLyogVW5zZXQgYWxsIHJ1bm5pbmcgZmxhZ3MuICovDQorICAgIC8q
IFVuc2V0IGFsbCBydW5uaW5nIGZsYWdzICovDQogICAgIGluZi0+c3RhdHVzICAmPSB+KEVYVFJB
X1JVTl9QRU4gfCBFWFRSQV9SVU5fVVRJTCk7DQotICAgIC8qIEZyZXNoIHNsaWNlIGZvciB0aGUg
bmV4dCBydW4uICovDQorICAgIC8qIEZyZXNoIHNsaWNlIGZvciB0aGUgbmV4dCBydW4gKi8NCiAg
ICAgaW5mLT5jcHV0aW1lID0gMDsNCi0gICAgLyogQWNjdW11bGF0ZSB0b3RhbCBleHRyYXRpbWUu
ICovDQorICAgIC8qIEFjY3VtdWxhdGUgdG90YWwgZXh0cmF0aW1lICovDQogICAgIGluZi0+ZXh0
cmFfdGltZV90b3QgKz0gbm93IC0gaW5mLT5zY2hlZF9zdGFydF9hYnM7DQogICAgIC8qIFJlbW92
ZSBleHRyYWRvbWFpbiBmcm9tIGhlYWQgb2YgdGhlIHF1ZXVlLiAqLw0KICAgICBleHRyYXFfZGVs
KGQsIGkpOw0KIA0KLSAgICAvKiBVcGRhdGUgdGhlIHNjb3JlLiAqLw0KKyAgICAvKiBVcGRhdGUg
dGhlIHNjb3JlICovDQogICAgIG9sZHNjb3JlID0gaW5mLT5zY29yZVtpXTsNCiAgICAgaWYgKCBp
ID09IEVYVFJBX1BFTl9RICkNCiAgICAgew0KLSAgICAgICAgLypkb21haW4gd2FzIHJ1bm5pbmcg
aW4gTDAgZXh0cmFxKi8NCi0gICAgICAgIC8qcmVkdWNlIGJsb2NrIGxvc3QsIHByb2JhYmx5IG1v
cmUgc29waGlzdGljYXRpb24gaGVyZSEqLw0KKyAgICAgICAgLyogRG9tYWluIHdhcyBydW5uaW5n
IGluIEwwIGV4dHJhcSAqLw0KKyAgICAgICAgLyogcmVkdWNlIGJsb2NrIGxvc3QsIHByb2JhYmx5
IG1vcmUgc29waGlzdGljYXRpb24gaGVyZSEqLw0KICAgICAgICAgLyppbmYtPnNob3J0X2Jsb2Nr
X2xvc3RfdG90IC09IEVYVFJBX1FVQU5UVU07Ki8NCiAgICAgICAgIGluZi0+c2hvcnRfYmxvY2tf
bG9zdF90b3QgLT0gbm93IC0gaW5mLT5zY2hlZF9zdGFydF9hYnM7DQotICAgICAgICBQUklOVCgz
LCJEb21haW4gJWkuJWk6IFNob3J0X2Jsb2NrX2xvc3M6ICUiUFJJaTY0IlxuIiwgDQotICAgICAg
ICAgICAgICBpbmYtPnZjcHUtPmRvbWFpbi0+ZG9tYWluX2lkLCBpbmYtPnZjcHUtPnZjcHVfaWQs
DQotICAgICAgICAgICAgICBpbmYtPnNob3J0X2Jsb2NrX2xvc3RfdG90KTsNCiAjaWYgMA0KLSAg
ICAgICAgLyoNCi0gICAgICAgICAqIEtBRjogSWYgd2UgZG9uJ3QgZXhpdCBzaG9ydC1ibG9ja2lu
ZyBzdGF0ZSBhdCB0aGlzIHBvaW50DQorICAgICAgICAvKiBLQUY6IElmIHdlIGRvbid0IGV4aXQg
c2hvcnQtYmxvY2tpbmcgc3RhdGUgYXQgdGhpcyBwb2ludA0KICAgICAgICAgICogZG9tYWluMCBj
YW4gc3RlYWwgYWxsIENQVSBmb3IgdXAgdG8gMTAgc2Vjb25kcyBiZWZvcmUNCiAgICAgICAgICAq
IHNjaGVkdWxpbmcgc2V0dGxlcyBkb3duICh3aGVuIGNvbXBldGluZyBhZ2FpbnN0IGFub3RoZXIN
CiAgICAgICAgICAqIENQVS1ib3VuZCBkb21haW4pLiBEb2luZyB0aGlzIHNlZW1zIHRvIG1ha2Ug
dGhpbmdzIGJlaGF2ZQ0KQEAgLTY1Niw1MSArNjAxLDU5IEBAIHN0YXRpYyB2b2lkIGRlc2NoZWRf
ZXh0cmFfZG9tKHNfdGltZV90IG4NCiAgICAgICAgIGlmICggaW5mLT5zaG9ydF9ibG9ja19sb3N0
X3RvdCA8PSAwICkNCiAjZW5kaWYNCiAgICAgICAgIHsNCi0gICAgICAgICAgICBQUklOVCg0LCJE
b21haW4gJWkuJWkgY29tcGVuc2F0ZWQgc2hvcnQgYmxvY2sgbG9zcyFcbiIsDQotICAgICAgICAg
ICAgICAgICAgaW5mLT52Y3B1LT5kb21haW4tPmRvbWFpbl9pZCwgaW5mLT52Y3B1LT52Y3B1X2lk
KTsNCi0gICAgICAgICAgICAvKndlIGhhdmUgKG92ZXItKWNvbXBlbnNhdGVkIG91ciBibG9jayBw
ZW5hbHR5Ki8NCisgICAgICAgICAgICAvKiBXZSBoYXZlIChvdmVyLSljb21wZW5zYXRlZCBvdXIg
YmxvY2sgcGVuYWx0eSAqLw0KICAgICAgICAgICAgIGluZi0+c2hvcnRfYmxvY2tfbG9zdF90b3Qg
PSAwOw0KLSAgICAgICAgICAgIC8qd2UgZG9uJ3Qgd2FudCBhIHBsYWNlIG9uIHRoZSBwZW5hbHR5
IHF1ZXVlIGFueW1vcmUhKi8NCisgICAgICAgICAgICAvKiBXZSBkb24ndCB3YW50IGEgcGxhY2Ug
b24gdGhlIHBlbmFsdHkgcXVldWUgYW55bW9yZSEgKi8NCiAgICAgICAgICAgICBpbmYtPnN0YXR1
cyAmPSB+RVhUUkFfV0FOVF9QRU5fUTsNCiAgICAgICAgICAgICBnb3RvIGNoZWNrX2V4dHJhX3F1
ZXVlczsNCiAgICAgICAgIH0NCiANCi0gICAgICAgIC8qd2UgaGF2ZSB0byBnbyBhZ2FpbiBmb3Ig
YW5vdGhlciB0cnkgaW4gdGhlIGJsb2NrLWV4dHJhcSwNCi0gICAgICAgICAgdGhlIHNjb3JlIGlz
IG5vdCB1c2VkIGluY3JlbWFudGFsbHkgaGVyZSwgYXMgdGhpcyBpcw0KLSAgICAgICAgICBhbHJl
YWR5IGRvbmUgYnkgcmVjYWxjdWxhdGluZyB0aGUgYmxvY2tfbG9zdCovDQorICAgICAgICAvKg0K
KyAgICAgICAgICogV2UgaGF2ZSB0byBnbyBhZ2FpbiBmb3IgYW5vdGhlciB0cnkgaW4gdGhlIGJs
b2NrLWV4dHJhcSwNCisgICAgICAgICAqIHRoZSBzY29yZSBpcyBub3QgdXNlZCBpbmNyZW1hbnRh
bGx5IGhlcmUsIGFzIHRoaXMgaXMNCisgICAgICAgICAqIGFscmVhZHkgZG9uZSBieSByZWNhbGN1
bGF0aW5nIHRoZSBibG9ja19sb3N0DQorICAgICAgICAgKi8NCiAgICAgICAgIGluZi0+c2NvcmVb
RVhUUkFfUEVOX1FdID0gKGluZi0+cGVyaW9kIDw8IDEwKSAvDQogICAgICAgICAgICAgaW5mLT5z
aG9ydF9ibG9ja19sb3N0X3RvdDsNCiAgICAgICAgIG9sZHNjb3JlID0gMDsNCiAgICAgfQ0KICAg
ICBlbHNlDQogICAgIHsNCi0gICAgICAgIC8qZG9tYWluIHdhcyBydW5uaW5nIGluIEwxIGV4dHJh
cSA9PiBzY29yZSBpcyBpbnZlcnNlIG9mDQotICAgICAgICAgIHV0aWxpemF0aW9uIGFuZCBpcyB1
c2VkIHNvbWV3aGF0IGluY3JlbWVudGFsISovDQorICAgICAgICAvKg0KKyAgICAgICAgICogRG9t
YWluIHdhcyBydW5uaW5nIGluIEwxIGV4dHJhcSA9PiBzY29yZSBpcyBpbnZlcnNlIG9mDQorICAg
ICAgICAgKiB1dGlsaXphdGlvbiBhbmQgaXMgdXNlZCBzb21ld2hhdCBpbmNyZW1lbnRhbCENCisg
ICAgICAgICAqLw0KICAgICAgICAgaWYgKCAhaW5mLT5leHRyYXdlaWdodCApDQotICAgICAgICAg
ICAgLypOQjogdXNlIGZpeGVkIHBvaW50IGFyaXRobWV0aWMgd2l0aCAxMCBiaXRzKi8NCisgICAg
ICAgIHsNCisgICAgICAgICAgICAvKiBOQjogdXNlIGZpeGVkIHBvaW50IGFyaXRobWV0aWMgd2l0
aCAxMCBiaXRzICovDQogICAgICAgICAgICAgaW5mLT5zY29yZVtFWFRSQV9VVElMX1FdID0gKGlu
Zi0+cGVyaW9kIDw8IDEwKSAvDQogICAgICAgICAgICAgICAgIGluZi0+c2xpY2U7DQorICAgICAg
ICB9DQogICAgICAgICBlbHNlDQotICAgICAgICAgICAgLypjb252ZXJzaW9uIGJldHdlZW4gcmVh
bHRpbWUgdXRpbGlzYXRpb24gYW5kIGV4dHJhd2llZ2h0Og0KLSAgICAgICAgICAgICAgZnVsbCAo
aWUgMTAwJSkgdXRpbGl6YXRpb24gaXMgZXF1aXZhbGVudCB0byAxMjggZXh0cmF3ZWlnaHQqLw0K
KyAgICAgICAgew0KKyAgICAgICAgICAgIC8qDQorICAgICAgICAgICAgICogQ29udmVyc2lvbiBi
ZXR3ZWVuIHJlYWx0aW1lIHV0aWxpc2F0aW9uIGFuZCBleHRyYXdpZWdodDoNCisgICAgICAgICAg
ICAgKiBmdWxsIChpZSAxMDAlKSB1dGlsaXphdGlvbiBpcyBlcXVpdmFsZW50IHRvIDEyOCBleHRy
YXdlaWdodA0KKyAgICAgICAgICAgICAqLw0KICAgICAgICAgICAgIGluZi0+c2NvcmVbRVhUUkFf
VVRJTF9RXSA9ICgxPDwxNykgLyBpbmYtPmV4dHJhd2VpZ2h0Ow0KKyAgICAgICAgfQ0KICAgICB9
DQogDQogIGNoZWNrX2V4dHJhX3F1ZXVlczoNCi0gICAgLyogQWRkaW5nIGEgcnVubmFibGUgZG9t
YWluIHRvIHRoZSByaWdodCBxdWV1ZSBhbmQgcmVtb3ZpbmcgYmxvY2tlZCBvbmVzKi8NCisgICAg
LyogQWRkaW5nIGEgcnVubmFibGUgZG9tYWluIHRvIHRoZSByaWdodCBxdWV1ZSBhbmQgcmVtb3Zp
bmcgYmxvY2tlZCBvbmVzICovDQogICAgIGlmICggc2VkZl9ydW5uYWJsZShkKSApDQogICAgIHsN
Ci0gICAgICAgIC8qYWRkIGFjY29yZGluZyB0byBzY29yZTogd2VpZ2h0ZWQgcm91bmQgcm9iaW4q
Lw0KKyAgICAgICAgLyogQWRkIGFjY29yZGluZyB0byBzY29yZTogd2VpZ2h0ZWQgcm91bmQgcm9i
aW4gKi8NCiAgICAgICAgIGlmICgoKGluZi0+c3RhdHVzICYgRVhUUkFfQVdBUkUpICYmIChpID09
IEVYVFJBX1VUSUxfUSkpIHx8DQogICAgICAgICAgICAgKChpbmYtPnN0YXR1cyAmIEVYVFJBX1dB
TlRfUEVOX1EpICYmIChpID09IEVYVFJBX1BFTl9RKSkpDQogICAgICAgICAgICAgZXh0cmFxX2Fk
ZF9zb3J0X3VwZGF0ZShkLCBpLCBvbGRzY29yZSk7DQogICAgIH0NCiAgICAgZWxzZQ0KICAgICB7
DQotICAgICAgICAvKnJlbW92ZSB0aGlzIGJsb2NrZWQgZG9tYWluIGZyb20gdGhlIHdhaXRxISov
DQorICAgICAgICAvKiBSZW1vdmUgdGhpcyBibG9ja2VkIGRvbWFpbiBmcm9tIHRoZSB3YWl0cSEg
Ki8NCiAgICAgICAgIF9fZGVsX2Zyb21fcXVldWUoZCk7DQotICAgICAgICAvKm1ha2Ugc3VyZSB0
aGF0IHdlIHJlbW92ZSBhIGJsb2NrZWQgZG9tYWluIGZyb20gdGhlIG90aGVyDQotICAgICAgICAg
IGV4dHJhcSB0b28qLw0KKyAgICAgICAgLyogTWFrZSBzdXJlIHRoYXQgd2UgcmVtb3ZlIGEgYmxv
Y2tlZCBkb21haW4gZnJvbSB0aGUgb3RoZXINCisgICAgICAgICAqIGV4dHJhcSB0b28uICovDQog
ICAgICAgICBpZiAoIGkgPT0gRVhUUkFfUEVOX1EgKQ0KICAgICAgICAgew0KICAgICAgICAgICAg
IGlmICggZXh0cmFxX29uKGQsIEVYVFJBX1VUSUxfUSkgKQ0KQEAgLTczMiw4ICs2ODUsMTAgQEAg
c3RhdGljIHN0cnVjdCB0YXNrX3NsaWNlIHNlZGZfZG9fZXh0cmFfcw0KIA0KICAgICBpZiAoICFs
aXN0X2VtcHR5KGV4dHJhcVtFWFRSQV9QRU5fUV0pICkNCiAgICAgew0KLSAgICAgICAgLyp3ZSBz
dGlsbCBoYXZlIGVsZW1lbnRzIG9uIHRoZSBsZXZlbCAwIGV4dHJhcSANCi0gICAgICAgICAgPT4g
bGV0IHRob3NlIHJ1biBmaXJzdCEqLw0KKyAgICAgICAgLyoNCisgICAgICAgICAqIFdlIHN0aWxs
IGhhdmUgZWxlbWVudHMgb24gdGhlIGxldmVsIDAgZXh0cmFxDQorICAgICAgICAgKiA9PiBsZXQg
dGhvc2UgcnVuIGZpcnN0IQ0KKyAgICAgICAgICovDQogICAgICAgICBydW5pbmYgICA9IGxpc3Rf
ZW50cnkoZXh0cmFxW0VYVFJBX1BFTl9RXS0+bmV4dCwgDQogICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgc3RydWN0IHNlZGZfdmNwdV9pbmZvLCBleHRyYWxpc3RbRVhUUkFfUEVOX1FdKTsN
CiAgICAgICAgIHJ1bmluZi0+c3RhdHVzIHw9IEVYVFJBX1JVTl9QRU47DQpAQCAtNzQ3LDcgKzcw
Miw3IEBAIHN0YXRpYyBzdHJ1Y3QgdGFza19zbGljZSBzZWRmX2RvX2V4dHJhX3MNCiAgICAgew0K
ICAgICAgICAgaWYgKCAhbGlzdF9lbXB0eShleHRyYXFbRVhUUkFfVVRJTF9RXSkgKQ0KICAgICAg
ICAgew0KLSAgICAgICAgICAgIC8qdXNlIGVsZW1lbnRzIGZyb20gdGhlIG5vcm1hbCBleHRyYXF1
ZXVlKi8NCisgICAgICAgICAgICAvKiBVc2UgZWxlbWVudHMgZnJvbSB0aGUgbm9ybWFsIGV4dHJh
cXVldWUgKi8NCiAgICAgICAgICAgICBydW5pbmYgICA9IGxpc3RfZW50cnkoZXh0cmFxW0VYVFJB
X1VUSUxfUV0tPm5leHQsDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHN0cnVj
dCBzZWRmX3ZjcHVfaW5mbywNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgZXh0
cmFsaXN0W0VYVFJBX1VUSUxfUV0pOw0KQEAgLTc3MiwxMSArNzI3LDEzIEBAIHN0YXRpYyBzdHJ1
Y3QgdGFza19zbGljZSBzZWRmX2RvX2V4dHJhX3MNCiB9DQogDQogDQotLyogTWFpbiBzY2hlZHVs
aW5nIGZ1bmN0aW9uDQotICAgUmVhc29ucyBmb3IgY2FsbGluZyB0aGlzIGZ1bmN0aW9uIGFyZToN
Ci0gICAtdGltZXNsaWNlIGZvciB0aGUgY3VycmVudCBwZXJpb2QgdXNlZCB1cA0KLSAgIC1kb21h
aW4gb24gd2FpdHF1ZXVlIGhhcyBzdGFydGVkIGl0J3MgcGVyaW9kDQotICAgLWFuZCB2YXJpb3Vz
IG90aGVycyA7KSBpbiBnZW5lcmFsOiBkZXRlcm1pbmUgd2hpY2ggZG9tYWluIHRvIHJ1biBuZXh0
Ki8NCisvKg0KKyAqIE1haW4gc2NoZWR1bGluZyBmdW5jdGlvbg0KKyAqIFJlYXNvbnMgZm9yIGNh
bGxpbmcgdGhpcyBmdW5jdGlvbiBhcmU6DQorICogLXRpbWVzbGljZSBmb3IgdGhlIGN1cnJlbnQg
cGVyaW9kIHVzZWQgdXANCisgKiAtZG9tYWluIG9uIHdhaXRxdWV1ZSBoYXMgc3RhcnRlZCBpdCdz
IHBlcmlvZA0KKyAqIC1hbmQgdmFyaW91cyBvdGhlcnMgOykgaW4gZ2VuZXJhbDogZGV0ZXJtaW5l
IHdoaWNoIGRvbWFpbiB0byBydW4gbmV4dA0KKyAqLw0KIHN0YXRpYyBzdHJ1Y3QgdGFza19zbGlj
ZSBzZWRmX2RvX3NjaGVkdWxlKA0KICAgICBjb25zdCBzdHJ1Y3Qgc2NoZWR1bGVyICpvcHMsIHNf
dGltZV90IG5vdywgYm9vbF90IHRhc2tsZXRfd29ya19zY2hlZHVsZWQpDQogew0KQEAgLTc4OSwx
MyArNzQ2LDE1IEBAIHN0YXRpYyBzdHJ1Y3QgdGFza19zbGljZSBzZWRmX2RvX3NjaGVkdWwNCiAg
ICAgc3RydWN0IHNlZGZfdmNwdV9pbmZvICpydW5pbmYsICp3YWl0aW5mOw0KICAgICBzdHJ1Y3Qg
dGFza19zbGljZSAgICAgIHJldDsNCiANCi0gICAgLyppZGxlIHRhc2tzIGRvbid0IG5lZWQgYW55
IG9mIHRoZSBmb2xsb3dpbmcgc3R1ZiovDQorICAgIC8qIElkbGUgdGFza3MgZG9uJ3QgbmVlZCBh
bnkgb2YgdGhlIGZvbGxvd2luZyBzdHVmICovDQogICAgIGlmICggaXNfaWRsZV92Y3B1KGN1cnJl
bnQpICkNCiAgICAgICAgIGdvdG8gY2hlY2tfd2FpdHE7DQotIA0KLSAgICAvKiBjcmVhdGUgbG9j
YWwgc3RhdGUgb2YgdGhlIHN0YXR1cyBvZiB0aGUgZG9tYWluLCBpbiBvcmRlciB0byBhdm9pZA0K
LSAgICAgICBpbmNvbnNpc3RlbnQgc3RhdGUgZHVyaW5nIHNjaGVkdWxpbmcgZGVjaXNpb25zLCBi
ZWNhdXNlIGRhdGEgZm9yDQotICAgICAgIHZjcHVfcnVubmFibGUgaXMgbm90IHByb3RlY3RlZCBi
eSB0aGUgc2NoZWR1bGluZyBsb2NrISovDQorDQorICAgIC8qDQorICAgICAqIENyZWF0ZSBsb2Nh
bCBzdGF0ZSBvZiB0aGUgc3RhdHVzIG9mIHRoZSBkb21haW4sIGluIG9yZGVyIHRvIGF2b2lkDQor
ICAgICAqIGluY29uc2lzdGVudCBzdGF0ZSBkdXJpbmcgc2NoZWR1bGluZyBkZWNpc2lvbnMsIGJl
Y2F1c2UgZGF0YSBmb3INCisgICAgICogdmNwdV9ydW5uYWJsZSBpcyBub3QgcHJvdGVjdGVkIGJ5
IHRoZSBzY2hlZHVsaW5nIGxvY2shDQorICAgICAqLw0KICAgICBpZiAoICF2Y3B1X3J1bm5hYmxl
KGN1cnJlbnQpICkNCiAgICAgICAgIGluZi0+c3RhdHVzIHw9IFNFREZfQVNMRUVQOw0KICANCkBA
IC04MDQsNyArNzYzLDcgQEAgc3RhdGljIHN0cnVjdCB0YXNrX3NsaWNlIHNlZGZfZG9fc2NoZWR1
bA0KIA0KICAgICBpZiAoIHVubGlrZWx5KGV4dHJhX3J1bnMoaW5mKSkgKQ0KICAgICB7DQotICAg
ICAgICAvKnNwZWNpYWwgdHJlYXRtZW50IG9mIGRvbWFpbnMgcnVubmluZyBpbiBleHRyYSB0aW1l
Ki8NCisgICAgICAgIC8qIFNwZWNpYWwgdHJlYXRtZW50IG9mIGRvbWFpbnMgcnVubmluZyBpbiBl
eHRyYSB0aW1lICovDQogICAgICAgICBkZXNjaGVkX2V4dHJhX2RvbShub3csIGN1cnJlbnQpOw0K
ICAgICB9DQogICAgIGVsc2UgDQpAQCAtODE0LDEwICs3NzMsMTIgQEAgc3RhdGljIHN0cnVjdCB0
YXNrX3NsaWNlIHNlZGZfZG9fc2NoZWR1bA0KICBjaGVja193YWl0cToNCiAgICAgdXBkYXRlX3F1
ZXVlcyhub3csIHJ1bnEsIHdhaXRxKTsNCiANCi0gICAgLypub3cgc2ltcGx5IHBpY2sgdGhlIGZp
cnN0IGRvbWFpbiBmcm9tIHRoZSBydW5xdWV1ZSwgd2hpY2ggaGFzIHRoZQ0KLSAgICAgIGVhcmxp
ZXN0IGRlYWRsaW5lLCBiZWNhdXNlIHRoZSBsaXN0IGlzIHNvcnRlZCovDQotIA0KLSAgICAvKiBU
YXNrbGV0IHdvcmsgKHdoaWNoIHJ1bnMgaW4gaWRsZSBWQ1BVIGNvbnRleHQpIG92ZXJyaWRlcyBh
bGwgZWxzZS4gKi8NCisgICAgLyoNCisgICAgICogTm93IHNpbXBseSBwaWNrIHRoZSBmaXJzdCBk
b21haW4gZnJvbSB0aGUgcnVucXVldWUsIHdoaWNoIGhhcyB0aGUNCisgICAgICogZWFybGllc3Qg
ZGVhZGxpbmUsIGJlY2F1c2UgdGhlIGxpc3QgaXMgc29ydGVkDQorICAgICAqDQorICAgICAqIFRh
c2tsZXQgd29yayAod2hpY2ggcnVucyBpbiBpZGxlIFZDUFUgY29udGV4dCkgb3ZlcnJpZGVzIGFs
bCBlbHNlLg0KKyAgICAgKi8NCiAgICAgaWYgKCB0YXNrbGV0X3dvcmtfc2NoZWR1bGVkIHx8DQog
ICAgICAgICAgKGxpc3RfZW1wdHkocnVucSkgJiYgbGlzdF9lbXB0eSh3YWl0cSkpIHx8DQogICAg
ICAgICAgdW5saWtlbHkoIWNwdW1hc2tfdGVzdF9jcHUoY3B1LCBTRURGX0NQVU9OTElORShwZXJf
Y3B1KGNwdXBvb2wsIGNwdSkpKSkgKQ0KQEAgLTgzMyw5ICs3OTQsMTEgQEAgc3RhdGljIHN0cnVj
dCB0YXNrX3NsaWNlIHNlZGZfZG9fc2NoZWR1bA0KICAgICAgICAgew0KICAgICAgICAgICAgIHdh
aXRpbmYgID0gbGlzdF9lbnRyeSh3YWl0cS0+bmV4dCwNCiAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgc3RydWN0IHNlZGZfdmNwdV9pbmZvLGxpc3QpOw0KLSAgICAgICAgICAgIC8q
cmVydW4gc2NoZWR1bGVyLCB3aGVuIHNjaGVkdWxlZCBkb21haW4gcmVhY2hlcyBpdCdzDQotICAg
ICAgICAgICAgICBlbmQgb2Ygc2xpY2Ugb3IgdGhlIGZpcnN0IGRvbWFpbiBmcm9tIHRoZSB3YWl0
cXVldWUNCi0gICAgICAgICAgICAgIGdldHMgcmVhZHkqLw0KKyAgICAgICAgICAgIC8qDQorICAg
ICAgICAgICAgICogUmVydW4gc2NoZWR1bGVyLCB3aGVuIHNjaGVkdWxlZCBkb21haW4gcmVhY2hl
cyBpdCdzDQorICAgICAgICAgICAgICogZW5kIG9mIHNsaWNlIG9yIHRoZSBmaXJzdCBkb21haW4g
ZnJvbSB0aGUgd2FpdHF1ZXVlDQorICAgICAgICAgICAgICogZ2V0cyByZWFkeS4NCisgICAgICAg
ICAgICAgKi8NCiAgICAgICAgICAgICByZXQudGltZSA9IE1JTihub3cgKyBydW5pbmYtPnNsaWNl
IC0gcnVuaW5mLT5jcHV0aW1lLA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIFBFUklPRF9C
RUdJTih3YWl0aW5mKSkgLSBub3c7DQogICAgICAgICB9DQpAQCAtODQ3LDE0ICs4MTAsMTggQEAg
c3RhdGljIHN0cnVjdCB0YXNrX3NsaWNlIHNlZGZfZG9fc2NoZWR1bA0KICAgICBlbHNlDQogICAg
IHsNCiAgICAgICAgIHdhaXRpbmYgID0gbGlzdF9lbnRyeSh3YWl0cS0+bmV4dCxzdHJ1Y3Qgc2Vk
Zl92Y3B1X2luZm8sIGxpc3QpOw0KLSAgICAgICAgLyp3ZSBjb3VsZCBub3QgZmluZCBhbnkgc3Vp
dGFibGUgZG9tYWluIA0KLSAgICAgICAgICA9PiBsb29rIGZvciBkb21haW5zIHRoYXQgYXJlIGF3
YXJlIG9mIGV4dHJhdGltZSovDQorICAgICAgICAvKg0KKyAgICAgICAgICogV2UgY291bGQgbm90
IGZpbmQgYW55IHN1aXRhYmxlIGRvbWFpbiANCisgICAgICAgICAqID0+IGxvb2sgZm9yIGRvbWFp
bnMgdGhhdCBhcmUgYXdhcmUgb2YgZXh0cmF0aW1lDQorICAgICAgICAgKi8NCiAgICAgICAgIHJl
dCA9IHNlZGZfZG9fZXh0cmFfc2NoZWR1bGUobm93LCBQRVJJT0RfQkVHSU4od2FpdGluZiksDQog
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGV4dHJhcSwgY3B1KTsNCiAgICAg
fQ0KIA0KLSAgICAvKlRPRE86IERvIHNvbWV0aGluZyBVU0VGVUwgd2hlbiB0aGlzIGhhcHBlbnMg
YW5kIGZpbmQgb3V0LCB3aHkgaXQNCi0gICAgICBzdGlsbCBjYW4gaGFwcGVuISEhKi8NCisgICAg
LyoNCisgICAgICogVE9ETzogRG8gc29tZXRoaW5nIFVTRUZVTCB3aGVuIHRoaXMgaGFwcGVucyBh
bmQgZmluZCBvdXQsIHdoeSBpdA0KKyAgICAgKiBzdGlsbCBjYW4gaGFwcGVuISEhDQorICAgICAq
Lw0KICAgICBpZiAoIHJldC50aW1lIDwgMCkNCiAgICAgew0KICAgICAgICAgcHJpbnRrKCJPdWNo
ISBXZSBhcmUgc2VyaW91c2x5IEJFSElORCBzY2hlZHVsZSEgJSJQUklpNjQiXG4iLA0KQEAgLTg3
NCw5ICs4NDEsNiBAQCBzdGF0aWMgc3RydWN0IHRhc2tfc2xpY2Ugc2VkZl9kb19zY2hlZHVsDQog
DQogc3RhdGljIHZvaWQgc2VkZl9zbGVlcChjb25zdCBzdHJ1Y3Qgc2NoZWR1bGVyICpvcHMsIHN0
cnVjdCB2Y3B1ICpkKQ0KIHsNCi0gICAgUFJJTlQoMiwic2VkZl9zbGVlcCB3YXMgY2FsbGVkLCBk
b21haW4taWQgJWkuJWlcbiIsDQotICAgICAgICAgIGQtPmRvbWFpbi0+ZG9tYWluX2lkLCBkLT52
Y3B1X2lkKTsNCi0gDQogICAgIGlmICggaXNfaWRsZV92Y3B1KGQpICkNCiAgICAgICAgIHJldHVy
bjsNCiANCkBAIC04OTgsNyArODYyLDggQEAgc3RhdGljIHZvaWQgc2VkZl9zbGVlcChjb25zdCBz
dHJ1Y3Qgc2NoZQ0KIH0NCiANCiANCi0vKiBUaGlzIGZ1bmN0aW9uIHdha2VzIHVwIGEgZG9tYWlu
LCBpLmUuIG1vdmVzIHRoZW0gaW50byB0aGUgd2FpdHF1ZXVlDQorLyoNCisgKiBUaGlzIGZ1bmN0
aW9uIHdha2VzIHVwIGEgZG9tYWluLCBpLmUuIG1vdmVzIHRoZW0gaW50byB0aGUgd2FpdHF1ZXVl
DQogICogdGhpbmdzIHRvIG1lbnRpb24gYXJlOiBhZG1pc3Npb24gY29udHJvbCBpcyB0YWtpbmcg
cGxhY2Ugbm93aGVyZSBhdA0KICAqIHRoZSBtb21lbnQsIHNvIHdlIGNhbid0IGJlIHN1cmUsIHdo
ZXRoZXIgaXQgaXMgc2FmZSB0byB3YWtlIHRoZSBkb21haW4NCiAgKiB1cCBhdCBhbGwuIEFueXdh
eSwgZXZlbiBpZiBpdCBpcyBzYWZlICh0b3RhbCBjcHUgdXNhZ2UgPD0xMDAlKSB0aGVyZSBhcmUN
CkBAIC05NzIsMjcgKzkzNywzMSBAQCBzdGF0aWMgdm9pZCBzZWRmX3NsZWVwKGNvbnN0IHN0cnVj
dCBzY2hlDQogc3RhdGljIHZvaWQgdW5ibG9ja19zaG9ydF9leHRyYV9zdXBwb3J0KA0KICAgICBz
dHJ1Y3Qgc2VkZl92Y3B1X2luZm8qIGluZiwgc190aW1lX3Qgbm93KQ0KIHsNCi0gICAgLyp0aGlz
IHVuYmxvY2tpbmcgc2NoZW1lIHRyaWVzIHRvIHN1cHBvcnQgdGhlIGRvbWFpbiwgYnkgYXNzaWdu
aW5nIGl0DQotICAgIGEgcHJpb3JpdHkgaW4gZXh0cmF0aW1lIGRpc3RyaWJ1dGlvbiBhY2NvcmRp
bmcgdG8gdGhlIGxvc3Mgb2YgdGltZQ0KLSAgICBpbiB0aGlzIHNsaWNlIGR1ZSB0byBibG9ja2lu
ZyovDQorICAgIC8qDQorICAgICAqIFRoaXMgdW5ibG9ja2luZyBzY2hlbWUgdHJpZXMgdG8gc3Vw
cG9ydCB0aGUgZG9tYWluLCBieSBhc3NpZ25pbmcgaXQNCisgICAgICogYSBwcmlvcml0eSBpbiBl
eHRyYXRpbWUgZGlzdHJpYnV0aW9uIGFjY29yZGluZyB0byB0aGUgbG9zcyBvZiB0aW1lDQorICAg
ICAqIGluIHRoaXMgc2xpY2UgZHVlIHRvIGJsb2NraW5nDQorICAgICAqLw0KICAgICBzX3RpbWVf
dCBwZW47DQogIA0KLSAgICAvKm5vIG1vcmUgcmVhbHRpbWUgZXhlY3V0aW9uIGluIHRoaXMgcGVy
aW9kISovDQorICAgIC8qIE5vIG1vcmUgcmVhbHRpbWUgZXhlY3V0aW9uIGluIHRoaXMgcGVyaW9k
ISAqLw0KICAgICBpbmYtPmRlYWRsX2FicyArPSBpbmYtPnBlcmlvZDsNCiAgICAgaWYgKCBsaWtl
bHkoaW5mLT5ibG9ja19hYnMpICkNCiAgICAgew0KLSAgICAgICAgLy90cmVhdCBibG9ja2VkIHRp
bWUgYXMgY29uc3VtZWQgYnkgdGhlIGRvbWFpbiovDQorICAgICAgICAvKiBUcmVhdCBibG9ja2Vk
IHRpbWUgYXMgY29uc3VtZWQgYnkgdGhlIGRvbWFpbiAqLw0KICAgICAgICAgLyppbmYtPmNwdXRp
bWUgKz0gbm93IC0gaW5mLT5ibG9ja19hYnM7Ki8NCi0gICAgICAgIC8qcGVuYWx0eSBpcyB0aW1l
IHRoZSBkb21haW4gd291bGQgaGF2ZQ0KLSAgICAgICAgICBoYWQgaWYgaXQgY29udGludWVkIHRv
IHJ1biAqLw0KKyAgICAgICAgLyoNCisgICAgICAgICAqIFBlbmFsdHkgaXMgdGltZSB0aGUgZG9t
YWluIHdvdWxkIGhhdmUNCisgICAgICAgICAqIGhhZCBpZiBpdCBjb250aW51ZWQgdG8gcnVuLg0K
KyAgICAgICAgICovDQogICAgICAgICBwZW4gPSAoaW5mLT5zbGljZSAtIGluZi0+Y3B1dGltZSk7
DQogICAgICAgICBpZiAoIHBlbiA8IDAgKQ0KICAgICAgICAgICAgIHBlbiA9IDA7DQotICAgICAg
ICAvKmFjY3VtdWxhdGUgYWxsIHBlbmFsdGllcyBvdmVyIHRoZSBwZXJpb2RzKi8NCisgICAgICAg
IC8qIEFjY3VtdWxhdGUgYWxsIHBlbmFsdGllcyBvdmVyIHRoZSBwZXJpb2RzICovDQogICAgICAg
ICAvKmluZi0+c2hvcnRfYmxvY2tfbG9zdF90b3QgKz0gcGVuOyovDQotICAgICAgICAvKnNldCBw
ZW5hbHR5IHRvIHRoZSBjdXJyZW50IHZhbHVlKi8NCisgICAgICAgIC8qIFNldCBwZW5hbHR5IHRv
IHRoZSBjdXJyZW50IHZhbHVlICovDQogICAgICAgICBpbmYtPnNob3J0X2Jsb2NrX2xvc3RfdG90
ID0gcGVuOw0KLSAgICAgICAgLypub3Qgc3VyZSB3aGljaCBvbmUgaXMgYmV0dGVyLi4gYnV0IHNl
ZW1zIHRvIHdvcmsgd2VsbC4uLiovDQorICAgICAgICAvKiBOb3Qgc3VyZSB3aGljaCBvbmUgaXMg
YmV0dGVyLi4gYnV0IHNlZW1zIHRvIHdvcmsgd2VsbC4uLiAqLw0KICAgDQogICAgICAgICBpZiAo
IGluZi0+c2hvcnRfYmxvY2tfbG9zdF90b3QgKQ0KICAgICAgICAgew0KQEAgLTEwMDIsMjggKzk3
MSwzMSBAQCBzdGF0aWMgdm9pZCB1bmJsb2NrX3Nob3J0X2V4dHJhX3N1cHBvcnQoDQogICAgICAg
ICAgICAgaW5mLT5wZW5fZXh0cmFfYmxvY2tzKys7DQogI2VuZGlmDQogICAgICAgICAgICAgaWYg
KCBleHRyYXFfb24oaW5mLT52Y3B1LCBFWFRSQV9QRU5fUSkgKQ0KLSAgICAgICAgICAgICAgICAv
KnJlbW92ZSBkb21haW4gZm9yIHBvc3NpYmxlIHJlc29ydGluZyEqLw0KKyAgICAgICAgICAgICAg
ICAvKiBSZW1vdmUgZG9tYWluIGZvciBwb3NzaWJsZSByZXNvcnRpbmchICovDQogICAgICAgICAg
ICAgICAgIGV4dHJhcV9kZWwoaW5mLT52Y3B1LCBFWFRSQV9QRU5fUSk7DQogICAgICAgICAgICAg
ZWxzZQ0KLSAgICAgICAgICAgICAgICAvKnJlbWVtYmVyIHRoYXQgd2Ugd2FudCB0byBiZSBvbiB0
aGUgcGVuYWx0eSBxDQotICAgICAgICAgICAgICAgICAgc28gdGhhdCB3ZSBjYW4gY29udGludWUg
d2hlbiB3ZSAodW4tKWJsb2NrDQotICAgICAgICAgICAgICAgICAgaW4gcGVuYWx0eS1leHRyYXRp
bWUqLw0KKyAgICAgICAgICAgICAgICAvKg0KKyAgICAgICAgICAgICAgICAgKiBSZW1lbWJlciB0
aGF0IHdlIHdhbnQgdG8gYmUgb24gdGhlIHBlbmFsdHkgcQ0KKyAgICAgICAgICAgICAgICAgKiBz
byB0aGF0IHdlIGNhbiBjb250aW51ZSB3aGVuIHdlICh1bi0pYmxvY2sNCisgICAgICAgICAgICAg
ICAgICogaW4gcGVuYWx0eS1leHRyYXRpbWUNCisgICAgICAgICAgICAgICAgICovDQogICAgICAg
ICAgICAgICAgIGluZi0+c3RhdHVzIHw9IEVYVFJBX1dBTlRfUEVOX1E7DQogICAgDQotICAgICAg
ICAgICAgLyoocmUtKWFkZCBkb21haW4gdG8gdGhlIHBlbmFsdHkgZXh0cmFxKi8NCisgICAgICAg
ICAgICAvKiAocmUtKWFkZCBkb21haW4gdG8gdGhlIHBlbmFsdHkgZXh0cmFxICovDQogICAgICAg
ICAgICAgZXh0cmFxX2FkZF9zb3J0X3VwZGF0ZShpbmYtPnZjcHUsIEVYVFJBX1BFTl9RLCAwKTsN
CiAgICAgICAgIH0NCiAgICAgfQ0KIA0KLSAgICAvKmdpdmUgaXQgYSBmcmVzaCBzbGljZSBpbiB0
aGUgbmV4dCBwZXJpb2QhKi8NCisgICAgLyogR2l2ZSBpdCBhIGZyZXNoIHNsaWNlIGluIHRoZSBu
ZXh0IHBlcmlvZCEgKi8NCiAgICAgaW5mLT5jcHV0aW1lID0gMDsNCiB9DQogDQogDQogc3RhdGlj
IHZvaWQgdW5ibG9ja19sb25nX2NvbnNfYihzdHJ1Y3Qgc2VkZl92Y3B1X2luZm8qIGluZixzX3Rp
bWVfdCBub3cpDQogew0KLSAgICAvKkNvbnNlcnZhdGl2ZSAyYiovDQotICAgIC8qVHJlYXQgdGhl
IHVuYmxvY2tpbmcgdGltZSBhcyBhIHN0YXJ0IG9mIGEgbmV3IHBlcmlvZCAqLw0KKyAgICAvKiBD
b25zZXJ2YXRpdmUgMmIgKi8NCisNCisgICAgLyogVHJlYXQgdGhlIHVuYmxvY2tpbmcgdGltZSBh
cyBhIHN0YXJ0IG9mIGEgbmV3IHBlcmlvZCAqLw0KICAgICBpbmYtPmRlYWRsX2FicyA9IG5vdyAr
IGluZi0+cGVyaW9kOw0KICAgICBpbmYtPmNwdXRpbWUgPSAwOw0KIH0NCkBAIC0xMDQ2LDE1ICsx
MDE4LDE3IEBAIHN0YXRpYyBpbmxpbmUgaW50IGdldF9ydW5fdHlwZShzdHJ1Y3QgdmMNCiB9DQog
DQogDQotLypDb21wYXJlcyB0d28gZG9tYWlucyBpbiB0aGUgcmVsYXRpb24gb2Ygd2hldGhlciB0
aGUgb25lIGlzIGFsbG93ZWQgdG8NCi0gIGludGVycnVwdCB0aGUgb3RoZXJzIGV4ZWN1dGlvbi4N
Ci0gIEl0IHJldHVybnMgdHJ1ZSAoIT0wKSBpZiBhIHN3aXRjaCB0byB0aGUgb3RoZXIgZG9tYWlu
IGlzIGdvb2QuDQotICBDdXJyZW50IFByaW9yaXR5IHNjaGVtZSBpcyBhcyBmb2xsb3dzOg0KLSAg
IEVERiA+IEwwIChwZW5hbHR5IGJhc2VkKSBleHRyYS10aW1lID4gDQotICAgTDEgKHV0aWxpemF0
aW9uKSBleHRyYS10aW1lID4gaWRsZS1kb21haW4NCi0gIEluIHRoZSBzYW1lIGNsYXNzIHByaW9y
aXRpZXMgYXJlIGFzc2lnbmVkIGFzIGZvbGxvd2luZzoNCi0gICBFREY6IGVhcmx5IGRlYWRsaW5l
ID4gbGF0ZSBkZWFkbGluZQ0KLSAgIEwwIGV4dHJhLXRpbWU6IGxvd2VyIHNjb3JlID4gaGlnaGVy
IHNjb3JlKi8NCisvKg0KKyAqIENvbXBhcmVzIHR3byBkb21haW5zIGluIHRoZSByZWxhdGlvbiBv
ZiB3aGV0aGVyIHRoZSBvbmUgaXMgYWxsb3dlZCB0bw0KKyAqIGludGVycnVwdCB0aGUgb3RoZXJz
IGV4ZWN1dGlvbi4NCisgKiBJdCByZXR1cm5zIHRydWUgKCE9MCkgaWYgYSBzd2l0Y2ggdG8gdGhl
IG90aGVyIGRvbWFpbiBpcyBnb29kLg0KKyAqIEN1cnJlbnQgUHJpb3JpdHkgc2NoZW1lIGlzIGFz
IGZvbGxvd3M6DQorICogIEVERiA+IEwwIChwZW5hbHR5IGJhc2VkKSBleHRyYS10aW1lID4gDQor
ICogIEwxICh1dGlsaXphdGlvbikgZXh0cmEtdGltZSA+IGlkbGUtZG9tYWluDQorICogSW4gdGhl
IHNhbWUgY2xhc3MgcHJpb3JpdGllcyBhcmUgYXNzaWduZWQgYXMgZm9sbG93aW5nOg0KKyAqICBF
REY6IGVhcmx5IGRlYWRsaW5lID4gbGF0ZSBkZWFkbGluZQ0KKyAqICBMMCBleHRyYS10aW1lOiBs
b3dlciBzY29yZSA+IGhpZ2hlciBzY29yZQ0KKyAqLw0KIHN0YXRpYyBpbmxpbmUgaW50IHNob3Vs
ZF9zd2l0Y2goc3RydWN0IHZjcHUgKmN1ciwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIHN0cnVjdCB2Y3B1ICpvdGhlciwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
IHNfdGltZV90IG5vdykNCkBAIC0xMDYzLDI2ICsxMDM3LDI1IEBAIHN0YXRpYyBpbmxpbmUgaW50
IHNob3VsZF9zd2l0Y2goc3RydWN0IHYNCiAgICAgY3VyX2luZiAgID0gRURPTV9JTkZPKGN1cik7
DQogICAgIG90aGVyX2luZiA9IEVET01fSU5GTyhvdGhlcik7DQogIA0KLSAgICAvKiBDaGVjayB3
aGV0aGVyIHdlIG5lZWQgdG8gbWFrZSBhbiBlYXJsaWVyIHNjaGVkdWxpbmcgZGVjaXNpb24uICov
DQorICAgIC8qIENoZWNrIHdoZXRoZXIgd2UgbmVlZCB0byBtYWtlIGFuIGVhcmxpZXIgc2NoZWR1
bGluZyBkZWNpc2lvbiAqLw0KICAgICBpZiAoIFBFUklPRF9CRUdJTihvdGhlcl9pbmYpIDwgDQog
ICAgICAgICAgQ1BVX0lORk8ob3RoZXItPnByb2Nlc3NvciktPmN1cnJlbnRfc2xpY2VfZXhwaXJl
cyApDQogICAgICAgICByZXR1cm4gMTsNCiANCi0gICAgLyogTm8gdGltaW5nLWJhc2VkIHN3aXRj
aGVzIG5lZWQgdG8gYmUgdGFrZW4gaW50byBhY2NvdW50IGhlcmUuICovDQorICAgIC8qIE5vIHRp
bWluZy1iYXNlZCBzd2l0Y2hlcyBuZWVkIHRvIGJlIHRha2VuIGludG8gYWNjb3VudCBoZXJlICov
DQogICAgIHN3aXRjaCAoIGdldF9ydW5fdHlwZShjdXIpICkNCiAgICAgew0KICAgICBjYXNlIERP
TUFJTl9FREY6DQotICAgICAgICAvKiBEbyBub3QgaW50ZXJydXB0IGEgcnVubmluZyBFREYgZG9t
YWluLiAqLw0KKyAgICAgICAgLyogRG8gbm90IGludGVycnVwdCBhIHJ1bm5pbmcgRURGIGRvbWFp
biAqLw0KICAgICAgICAgcmV0dXJuIDA7DQogICAgIGNhc2UgRE9NQUlOX0VYVFJBX1BFTjoNCi0g
ICAgICAgIC8qIENoZWNrIHdoZXRoZXIgd2UgYWxzbyB3YW50IHRoZSBMMCBleC1xIHdpdGggbG93
ZXIgc2NvcmUuICovDQorICAgICAgICAvKiBDaGVjayB3aGV0aGVyIHdlIGFsc28gd2FudCB0aGUg
TDAgZXgtcSB3aXRoIGxvd2VyIHNjb3JlICovDQogICAgICAgICByZXR1cm4gKChvdGhlcl9pbmYt
PnN0YXR1cyAmIEVYVFJBX1dBTlRfUEVOX1EpICYmDQogICAgICAgICAgICAgICAgIChvdGhlcl9p
bmYtPnNjb3JlW0VYVFJBX1BFTl9RXSA8IA0KICAgICAgICAgICAgICAgICAgY3VyX2luZi0+c2Nv
cmVbRVhUUkFfUEVOX1FdKSk7DQogICAgIGNhc2UgRE9NQUlOX0VYVFJBX1VUSUw6DQogICAgICAg
ICAvKiBDaGVjayB3aGV0aGVyIHdlIHdhbnQgdGhlIEwwIGV4dHJhcS4gRG9uJ3QNCi0gICAgICAg
ICAqIHN3aXRjaCBpZiBib3RoIGRvbWFpbnMgd2FudCBMMSBleHRyYXEuDQotICAgICAgICAgKi8N
CisgICAgICAgICAqIHN3aXRjaCBpZiBib3RoIGRvbWFpbnMgd2FudCBMMSBleHRyYXEuICovDQog
ICAgICAgICByZXR1cm4gISEob3RoZXJfaW5mLT5zdGF0dXMgJiBFWFRSQV9XQU5UX1BFTl9RKTsN
CiAgICAgY2FzZSBET01BSU5fSURMRToNCiAgICAgICAgIHJldHVybiAxOw0KQEAgLTEwOTYsMTgg
KzEwNjksMTEgQEAgc3RhdGljIHZvaWQgc2VkZl93YWtlKGNvbnN0IHN0cnVjdCBzY2hlZA0KICAg
ICBzX3RpbWVfdCAgICAgICAgICAgICAgbm93ID0gTk9XKCk7DQogICAgIHN0cnVjdCBzZWRmX3Zj
cHVfaW5mbyogaW5mID0gRURPTV9JTkZPKGQpOw0KIA0KLSAgICBQUklOVCgzLCAic2VkZl93YWtl
IHdhcyBjYWxsZWQsIGRvbWFpbi1pZCAlaS4laVxuIixkLT5kb21haW4tPmRvbWFpbl9pZCwNCi0g
ICAgICAgICAgZC0+dmNwdV9pZCk7DQotDQogICAgIGlmICggdW5saWtlbHkoaXNfaWRsZV92Y3B1
KGQpKSApDQogICAgICAgICByZXR1cm47DQogICAgDQogICAgIGlmICggdW5saWtlbHkoX190YXNr
X29uX3F1ZXVlKGQpKSApDQotICAgIHsNCi0gICAgICAgIFBSSU5UKDMsIlx0ZG9tYWluICVpLiVp
IGlzIGFscmVhZHkgaW4gc29tZSBxdWV1ZVxuIiwNCi0gICAgICAgICAgICAgIGQtPmRvbWFpbi0+
ZG9tYWluX2lkLCBkLT52Y3B1X2lkKTsNCiAgICAgICAgIHJldHVybjsNCi0gICAgfQ0KIA0KICAg
ICBBU1NFUlQoIXNlZGZfcnVubmFibGUoZCkpOw0KICAgICBpbmYtPnN0YXR1cyAmPSB+U0VERl9B
U0xFRVA7DQpAQCAtMTExNiwyOCArMTA4MiwyNSBAQCBzdGF0aWMgdm9pZCBzZWRmX3dha2UoY29u
c3Qgc3RydWN0IHNjaGVkDQogIA0KICAgICBpZiAoIHVubGlrZWx5KGluZi0+ZGVhZGxfYWJzID09
IDApICkNCiAgICAgew0KLSAgICAgICAgLyppbml0aWFsIHNldHVwIG9mIHRoZSBkZWFkbGluZSov
DQorICAgICAgICAvKiBJbml0aWFsIHNldHVwIG9mIHRoZSBkZWFkbGluZSAqLw0KICAgICAgICAg
aW5mLT5kZWFkbF9hYnMgPSBub3cgKyBpbmYtPnNsaWNlOw0KICAgICB9DQogICANCi0gICAgUFJJ
TlQoMywgIndha2luZyB1cCBkb21haW4gJWkuJWkgKGRlYWRsPSAlIlBSSXU2NCIgcGVyaW9kPSAl
IlBSSXU2NA0KLSAgICAgICAgICAibm93PSAlIlBSSXU2NCIpXG4iLA0KLSAgICAgICAgICBkLT5k
b21haW4tPmRvbWFpbl9pZCwgZC0+dmNwdV9pZCwgaW5mLT5kZWFkbF9hYnMsIGluZi0+cGVyaW9k
LCBub3cpOw0KLQ0KICNpZmRlZiBTRURGX1NUQVRTIA0KICAgICBpbmYtPmJsb2NrX3RvdCsrOw0K
ICNlbmRpZg0KIA0KICAgICBpZiAoIHVubGlrZWx5KG5vdyA8IFBFUklPRF9CRUdJTihpbmYpKSAp
DQogICAgIHsNCi0gICAgICAgIFBSSU5UKDQsImV4dHJhdGltZSB1bmJsb2NrXG4iKTsNCi0gICAg
ICAgIC8qIHVuYmxvY2tpbmcgaW4gZXh0cmEtdGltZSEgKi8NCisgICAgICAgIC8qIFVuYmxvY2tp
bmcgaW4gZXh0cmEtdGltZSEgKi8NCiAgICAgICAgIGlmICggaW5mLT5zdGF0dXMgJiBFWFRSQV9X
QU5UX1BFTl9RICkNCiAgICAgICAgIHsNCi0gICAgICAgICAgICAvKndlIGhhdmUgYSBkb21haW4g
dGhhdCB3YW50cyBjb21wZW5zYXRpb24NCi0gICAgICAgICAgICAgIGZvciBibG9jayBwZW5hbHR5
IGFuZCBkaWQganVzdCBibG9jayBpbg0KLSAgICAgICAgICAgICAgaXRzIGNvbXBlbnNhdGlvbiB0
aW1lLiBHaXZlIGl0IGFub3RoZXINCi0gICAgICAgICAgICAgIGNoYW5jZSEqLw0KKyAgICAgICAg
ICAgIC8qDQorICAgICAgICAgICAgICogV2UgaGF2ZSBhIGRvbWFpbiB0aGF0IHdhbnRzIGNvbXBl
bnNhdGlvbg0KKyAgICAgICAgICAgICAqIGZvciBibG9jayBwZW5hbHR5IGFuZCBkaWQganVzdCBi
bG9jayBpbg0KKyAgICAgICAgICAgICAqIGl0cyBjb21wZW5zYXRpb24gdGltZS4gR2l2ZSBpdCBh
bm90aGVyDQorICAgICAgICAgICAgICogY2hhbmNlIQ0KKyAgICAgICAgICAgICAqLw0KICAgICAg
ICAgICAgIGV4dHJhcV9hZGRfc29ydF91cGRhdGUoZCwgRVhUUkFfUEVOX1EsIDApOw0KICAgICAg
ICAgfQ0KICAgICAgICAgZXh0cmFxX2NoZWNrX2FkZF91bmJsb2NrZWQoZCwgMCk7DQpAQCAtMTE0
Niw4ICsxMTA5LDcgQEAgc3RhdGljIHZvaWQgc2VkZl93YWtlKGNvbnN0IHN0cnVjdCBzY2hlZA0K
ICAgICB7ICANCiAgICAgICAgIGlmICggbm93IDwgaW5mLT5kZWFkbF9hYnMgKQ0KICAgICAgICAg
ew0KLSAgICAgICAgICAgIFBSSU5UKDQsInNob3J0IHVuYmxvY2tpbmdcbiIpOw0KLSAgICAgICAg
ICAgIC8qc2hvcnQgYmxvY2tpbmcqLw0KKyAgICAgICAgICAgIC8qIFNob3J0IGJsb2NraW5nICov
DQogI2lmZGVmIFNFREZfU1RBVFMNCiAgICAgICAgICAgICBpbmYtPnNob3J0X2Jsb2NrX3RvdCsr
Ow0KICNlbmRpZg0KQEAgLTExNTcsOCArMTExOSw3IEBAIHN0YXRpYyB2b2lkIHNlZGZfd2FrZShj
b25zdCBzdHJ1Y3Qgc2NoZWQNCiAgICAgICAgIH0NCiAgICAgICAgIGVsc2UNCiAgICAgICAgIHsN
Ci0gICAgICAgICAgICBQUklOVCg0LCJsb25nIHVuYmxvY2tpbmdcbiIpOw0KLSAgICAgICAgICAg
IC8qbG9uZyB1bmJsb2NraW5nKi8NCisgICAgICAgICAgICAvKiBMb25nIHVuYmxvY2tpbmcgKi8N
CiAjaWZkZWYgU0VERl9TVEFUUw0KICAgICAgICAgICAgIGluZi0+bG9uZ19ibG9ja190b3QrKzsN
CiAjZW5kaWYNCkBAIC0xMTY4LDI0ICsxMTI5LDEzIEBAIHN0YXRpYyB2b2lkIHNlZGZfd2FrZShj
b25zdCBzdHJ1Y3Qgc2NoZWQNCiAgICAgICAgIH0NCiAgICAgfQ0KIA0KLSAgICBQUklOVCgzLCAi
d29rZSB1cCBkb21haW4gJWkuJWkgKGRlYWRsPSAlIlBSSXU2NCIgcGVyaW9kPSAlIlBSSXU2NA0K
LSAgICAgICAgICAibm93PSAlIlBSSXU2NCIpXG4iLA0KLSAgICAgICAgICBkLT5kb21haW4tPmRv
bWFpbl9pZCwgZC0+dmNwdV9pZCwgaW5mLT5kZWFkbF9hYnMsDQotICAgICAgICAgIGluZi0+cGVy
aW9kLCBub3cpOw0KLQ0KICAgICBpZiAoIFBFUklPRF9CRUdJTihpbmYpID4gbm93ICkNCi0gICAg
ew0KICAgICAgICAgX19hZGRfdG9fd2FpdHF1ZXVlX3NvcnQoZCk7DQotICAgICAgICBQUklOVCgz
LCJhZGRlZCB0byB3YWl0cVxuIik7DQotICAgIH0NCiAgICAgZWxzZQ0KLSAgICB7DQogICAgICAg
ICBfX2FkZF90b19ydW5xdWV1ZV9zb3J0KGQpOw0KLSAgICAgICAgUFJJTlQoMywiYWRkZWQgdG8g
cnVucVxuIik7DQotICAgIH0NCiAgDQogI2lmZGVmIFNFREZfU1RBVFMNCi0gICAgLypkbyBzb21l
IHN0YXRpc3RpY3MgaGVyZS4uLiovDQorICAgIC8qIERvIHNvbWUgc3RhdGlzdGljcyBoZXJlLi4u
ICovDQogICAgIGlmICggaW5mLT5ibG9ja19hYnMgIT0gMCApDQogICAgIHsNCiAgICAgICAgIGlu
Zi0+YmxvY2tfdGltZV90b3QgKz0gbm93IC0gaW5mLT5ibG9ja19hYnM7DQpAQCAtMTE5NCwxMiAr
MTE0NCwxNCBAQCBzdGF0aWMgdm9pZCBzZWRmX3dha2UoY29uc3Qgc3RydWN0IHNjaGVkDQogICAg
IH0NCiAjZW5kaWYNCiANCi0gICAgLypzYW5pdHkgY2hlY2s6IG1ha2Ugc3VyZSBlYWNoIGV4dHJh
LWF3YXJlIGRvbWFpbiBJUyBvbiB0aGUgdXRpbC1xISovDQorICAgIC8qIFNhbml0eSBjaGVjazog
bWFrZSBzdXJlIGVhY2ggZXh0cmEtYXdhcmUgZG9tYWluIElTIG9uIHRoZSB1dGlsLXEhICovDQog
ICAgIEFTU0VSVChJTVBMWShpbmYtPnN0YXR1cyAmIEVYVFJBX0FXQVJFLCBleHRyYXFfb24oZCwg
RVhUUkFfVVRJTF9RKSkpOw0KICAgICBBU1NFUlQoX190YXNrX29uX3F1ZXVlKGQpKTsNCi0gICAg
LypjaGVjayB3aGV0aGVyIHRoZSBhd2FrZW5lZCB0YXNrIG5lZWRzIHRvIGludm9rZSB0aGUgZG9f
c2NoZWR1bGUNCi0gICAgICByb3V0aW5lLiBUcnkgdG8gYXZvaWQgdW5uZWNlc3NhcnkgcnVucyBi
dXQ6DQotICAgICAgU2F2ZSBhcHByb3hpbWF0aW9uOiBBbHdheXMgc3dpdGNoIHRvIHNjaGVkdWxl
ciEqLw0KKyAgICAvKg0KKyAgICAgKiBDaGVjayB3aGV0aGVyIHRoZSBhd2FrZW5lZCB0YXNrIG5l
ZWRzIHRvIGludm9rZSB0aGUgZG9fc2NoZWR1bGUNCisgICAgICogcm91dGluZS4gVHJ5IHRvIGF2
b2lkIHVubmVjZXNzYXJ5IHJ1bnMgYnV0Og0KKyAgICAgKiBTYXZlIGFwcHJveGltYXRpb246IEFs
d2F5cyBzd2l0Y2ggdG8gc2NoZWR1bGVyIQ0KKyAgICAgKi8NCiAgICAgQVNTRVJUKGQtPnByb2Nl
c3NvciA+PSAwKTsNCiAgICAgQVNTRVJUKGQtPnByb2Nlc3NvciA8IG5yX2NwdV9pZHMpOw0KICAg
ICBBU1NFUlQocGVyX2NwdShzY2hlZHVsZV9kYXRhLCBkLT5wcm9jZXNzb3IpLmN1cnIpOw0KQEAg
LTEyNDQsNyArMTE5Niw3IEBAIHN0YXRpYyB2b2lkIHNlZGZfZHVtcF9kb21haW4oc3RydWN0IHZj
cHUNCiB9DQogDQogDQotLyogZHVtcHMgYWxsIGRvbWFpbnMgb24gdGhlIHNwZWNpZmllZCBjcHUg
Ki8NCisvKiBEdW1wcyBhbGwgZG9tYWlucyBvbiB0aGUgc3BlY2lmaWVkIGNwdSAqLw0KIHN0YXRp
YyB2b2lkIHNlZGZfZHVtcF9jcHVfc3RhdGUoY29uc3Qgc3RydWN0IHNjaGVkdWxlciAqb3BzLCBp
bnQgaSkNCiB7DQogICAgIHN0cnVjdCBsaXN0X2hlYWQgICAgICAqbGlzdCwgKnF1ZXVlLCAqdG1w
Ow0KQEAgLTEzMTksNyArMTI3MSw3IEBAIHN0YXRpYyB2b2lkIHNlZGZfZHVtcF9jcHVfc3RhdGUo
Y29uc3Qgc3QNCiB9DQogDQogDQotLyogQWRqdXN0cyBwZXJpb2RzIGFuZCBzbGljZXMgb2YgdGhl
IGRvbWFpbnMgYWNjb3JkaW5nbHkgdG8gdGhlaXIgd2VpZ2h0cy4gKi8NCisvKiBBZGp1c3RzIHBl
cmlvZHMgYW5kIHNsaWNlcyBvZiB0aGUgZG9tYWlucyBhY2NvcmRpbmdseSB0byB0aGVpciB3ZWln
aHRzICovDQogc3RhdGljIGludCBzZWRmX2FkanVzdF93ZWlnaHRzKHN0cnVjdCBjcHVwb29sICpj
LCBzdHJ1Y3QgeGVuX2RvbWN0bF9zY2hlZHVsZXJfb3AgKmNtZCkNCiB7DQogICAgIHN0cnVjdCB2
Y3B1ICpwOw0KQEAgLTEzMzUsNyArMTI4Nyw3IEBAIHN0YXRpYyBpbnQgc2VkZl9hZGp1c3Rfd2Vp
Z2h0cyhzdHJ1Y3QgY3ANCiAgICAgICAgIHJldHVybiAtRU5PTUVNOw0KICAgICB9DQogDQotICAg
IC8qIFN1bSBhY3Jvc3MgYWxsIHdlaWdodHMuICovDQorICAgIC8qIFN1bSBhY3Jvc3MgYWxsIHdl
aWdodHMgKi8NCiAgICAgcmN1X3JlYWRfbG9jaygmZG9tbGlzdF9yZWFkX2xvY2spOw0KICAgICBm
b3JfZWFjaF9kb21haW5faW5fY3B1cG9vbCggZCwgYyApDQogICAgIHsNCkBAIC0xMzUwLDExICsx
MzAyLDE0IEBAIHN0YXRpYyBpbnQgc2VkZl9hZGp1c3Rfd2VpZ2h0cyhzdHJ1Y3QgY3ANCiAgICAg
ICAgICAgICB9DQogICAgICAgICAgICAgZWxzZQ0KICAgICAgICAgICAgIHsNCi0gICAgICAgICAg
ICAgICAgLypkb24ndCBtb2RpZnkgZG9tYWlucyB3aG8gZG9uJ3QgaGF2ZSBhIHdlaWdodCwgYnV0
IHN1bQ0KLSAgICAgICAgICAgICAgICAgIHVwIHRoZSB0aW1lIHRoZXkgbmVlZCwgcHJvamVjdGVk
IHRvIGEgV0VJR0hUX1BFUklPRCwNCi0gICAgICAgICAgICAgICAgICBzbyB0aGF0IHRoaXMgdGlt
ZSBpcyBub3QgZ2l2ZW4gdG8gdGhlIHdlaWdodC1kcml2ZW4NCi0gICAgICAgICAgICAgICAgICBk
b21haW5zKi8NCi0gICAgICAgICAgICAgICAgLypjaGVjayBmb3Igb3ZlcmZsb3dzKi8NCisgICAg
ICAgICAgICAgICAgLyoNCisgICAgICAgICAgICAgICAgICogRG9uJ3QgbW9kaWZ5IGRvbWFpbnMg
d2hvIGRvbid0IGhhdmUgYSB3ZWlnaHQsIGJ1dCBzdW0NCisgICAgICAgICAgICAgICAgICogdXAg
dGhlIHRpbWUgdGhleSBuZWVkLCBwcm9qZWN0ZWQgdG8gYSBXRUlHSFRfUEVSSU9ELA0KKyAgICAg
ICAgICAgICAgICAgKiBzbyB0aGF0IHRoaXMgdGltZSBpcyBub3QgZ2l2ZW4gdG8gdGhlIHdlaWdo
dC1kcml2ZW4NCisgICAgICAgICAgICAgICAgICogIGRvbWFpbnMNCisgICAgICAgICAgICAgICAg
ICovDQorDQorICAgICAgICAgICAgICAgIC8qIENoZWNrIGZvciBvdmVyZmxvd3MgKi8NCiAgICAg
ICAgICAgICAgICAgQVNTRVJUKChXRUlHSFRfUEVSSU9EIDwgVUxPTkdfTUFYKSANCiAgICAgICAg
ICAgICAgICAgICAgICAgICYmIChFRE9NX0lORk8ocCktPnNsaWNlX29yaWcgPCBVTE9OR19NQVgp
KTsNCiAgICAgICAgICAgICAgICAgc3VtdFtjcHVdICs9IA0KQEAgLTEzNjUsNyArMTMyMCw3IEBA
IHN0YXRpYyBpbnQgc2VkZl9hZGp1c3Rfd2VpZ2h0cyhzdHJ1Y3QgY3ANCiAgICAgfQ0KICAgICBy
Y3VfcmVhZF91bmxvY2soJmRvbWxpc3RfcmVhZF9sb2NrKTsNCiANCi0gICAgLyogQWRqdXN0IGFs
bCBzbGljZXMgKGFuZCBwZXJpb2RzKSB0byB0aGUgbmV3IHdlaWdodC4gKi8NCisgICAgLyogQWRq
dXN0IGFsbCBzbGljZXMgKGFuZCBwZXJpb2RzKSB0byB0aGUgbmV3IHdlaWdodCAqLw0KICAgICBy
Y3VfcmVhZF9sb2NrKCZkb21saXN0X3JlYWRfbG9jayk7DQogICAgIGZvcl9lYWNoX2RvbWFpbl9p
bl9jcHVwb29sKCBkLCBjICkNCiAgICAgew0KQEAgLTEzOTMsMjAgKzEzNDgsMTUgQEAgc3RhdGlj
IGludCBzZWRmX2FkanVzdF93ZWlnaHRzKHN0cnVjdCBjcA0KIH0NCiANCiANCi0vKiBzZXQgb3Ig
ZmV0Y2ggZG9tYWluIHNjaGVkdWxpbmcgcGFyYW1ldGVycyAqLw0KKy8qIFNldCBvciBmZXRjaCBk
b21haW4gc2NoZWR1bGluZyBwYXJhbWV0ZXJzICovDQogc3RhdGljIGludCBzZWRmX2FkanVzdChj
b25zdCBzdHJ1Y3Qgc2NoZWR1bGVyICpvcHMsIHN0cnVjdCBkb21haW4gKnAsIHN0cnVjdCB4ZW5f
ZG9tY3RsX3NjaGVkdWxlcl9vcCAqb3ApDQogew0KICAgICBzdHJ1Y3QgdmNwdSAqdjsNCiAgICAg
aW50IHJjOw0KIA0KLSAgICBQUklOVCgyLCJzZWRmX2FkanVzdCB3YXMgY2FsbGVkLCBkb21haW4t
aWQgJWkgbmV3IHBlcmlvZCAlIlBSSXU2NCIgIg0KLSAgICAgICAgICAibmV3IHNsaWNlICUiUFJJ
dTY0IlxubGF0ZW5jeSAlIlBSSXU2NCIgZXh0cmE6JXNcbiIsDQotICAgICAgICAgIHAtPmRvbWFp
bl9pZCwgb3AtPnUuc2VkZi5wZXJpb2QsIG9wLT51LnNlZGYuc2xpY2UsDQotICAgICAgICAgIG9w
LT51LnNlZGYubGF0ZW5jeSwgKG9wLT51LnNlZGYuZXh0cmF0aW1lKT8ieWVzIjoibm8iKTsNCi0N
CiAgICAgaWYgKCBvcC0+Y21kID09IFhFTl9ET01DVExfU0NIRURPUF9wdXRpbmZvICkNCiAgICAg
ew0KLSAgICAgICAgLyogQ2hlY2sgZm9yIHNhbmUgcGFyYW1ldGVycy4gKi8NCisgICAgICAgIC8q
IENoZWNrIGZvciBzYW5lIHBhcmFtZXRlcnMgKi8NCiAgICAgICAgIGlmICggIW9wLT51LnNlZGYu
cGVyaW9kICYmICFvcC0+dS5zZWRmLndlaWdodCApDQogICAgICAgICAgICAgcmV0dXJuIC1FSU5W
QUw7DQogICAgICAgICBpZiAoIG9wLT51LnNlZGYud2VpZ2h0ICkNCkBAIC0xNDE0LDcgKzEzNjQs
NyBAQCBzdGF0aWMgaW50IHNlZGZfYWRqdXN0KGNvbnN0IHN0cnVjdCBzY2hlDQogICAgICAgICAg
ICAgaWYgKCAob3AtPnUuc2VkZi5leHRyYXRpbWUgJiBFWFRSQV9BV0FSRSkgJiYNCiAgICAgICAg
ICAgICAgICAgICghb3AtPnUuc2VkZi5wZXJpb2QpICkNCiAgICAgICAgICAgICB7DQotICAgICAg
ICAgICAgICAgIC8qIFdlaWdodC1kcml2ZW4gZG9tYWlucyB3aXRoIGV4dHJhdGltZSBvbmx5LiAq
Lw0KKyAgICAgICAgICAgICAgICAvKiBXZWlnaHQtZHJpdmVuIGRvbWFpbnMgd2l0aCBleHRyYXRp
bWUgb25seSAqLw0KICAgICAgICAgICAgICAgICBmb3JfZWFjaF92Y3B1ICggcCwgdiApDQogICAg
ICAgICAgICAgICAgIHsNCiAgICAgICAgICAgICAgICAgICAgIEVET01fSU5GTyh2KS0+ZXh0cmF3
ZWlnaHQgPSBvcC0+dS5zZWRmLndlaWdodDsNCkBAIC0xNDI1LDcgKzEzNzUsNyBAQCBzdGF0aWMg
aW50IHNlZGZfYWRqdXN0KGNvbnN0IHN0cnVjdCBzY2hlDQogICAgICAgICAgICAgfQ0KICAgICAg
ICAgICAgIGVsc2UNCiAgICAgICAgICAgICB7DQotICAgICAgICAgICAgICAgIC8qIFdlaWdodC1k
cml2ZW4gZG9tYWlucyB3aXRoIHJlYWwtdGltZSBleGVjdXRpb24uICovDQorICAgICAgICAgICAg
ICAgIC8qIFdlaWdodC1kcml2ZW4gZG9tYWlucyB3aXRoIHJlYWwtdGltZSBleGVjdXRpb24gKi8N
CiAgICAgICAgICAgICAgICAgZm9yX2VhY2hfdmNwdSAoIHAsIHYgKQ0KICAgICAgICAgICAgICAg
ICAgICAgRURPTV9JTkZPKHYpLT53ZWlnaHQgPSBvcC0+dS5zZWRmLndlaWdodDsNCiAgICAgICAg
ICAgICB9DQpAQCAtMTQ3Nyw3ICsxNDI3LDYgQEAgc3RhdGljIGludCBzZWRmX2FkanVzdChjb25z
dCBzdHJ1Y3Qgc2NoZQ0KICAgICAgICAgb3AtPnUuc2VkZi53ZWlnaHQgICAgPSBFRE9NX0lORk8o
cC0+dmNwdVswXSktPndlaWdodDsNCiAgICAgfQ0KIA0KLSAgICBQUklOVCgyLCJzZWRmX2FkanVz
dF9maW5pc2hlZFxuIik7DQogICAgIHJldHVybiAwOw0KIH0NCiANCm==


--=-DM3xwBkUsBWsFUckworM--

--=-oVXZhmqkWYbyP3+4MWM6
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEABECAAYFAk7yA2EACgkQk4XaBE3IOsQjHgCgokeOKmICEG21IO9eF+nOwRTE
4HYAoJlFaHcaHVJZC2nqIqROHfizcSkc
=ZkFV
-----END PGP SIGNATURE-----

--=-oVXZhmqkWYbyP3+4MWM6--



--===============2284887627372470128==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============2284887627372470128==--



From xen-devel-bounces@lists.xensource.com Wed Dec 21 16:10:00 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 16:10:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdOjW-0001Qm-6p; Wed, 21 Dec 2011 16:09:34 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RdOjU-0001QU-Ve
	for xen-devel@lists.xensource.com; Wed, 21 Dec 2011 16:09:33 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1324483764!8179153!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28676 invoked from network); 21 Dec 2011 16:09:25 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-6.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Dec 2011 16:09:25 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 21 Dec 2011 16:10:34 +0000
Message-Id: <4EF212FA020000780006966B@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 21 Dec 2011 16:10:18 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "=?UTF-8?Q?Roger=20Pau=20Monn=C3=A9?=" <roger.pau@entel.upc.edu>
References: <d61e6300274bbc6bc464.1324354898@alpine.localdomain>
	<4EF204BF020000780006963F@nat28.tlf.novell.com>
	<CAPLaKK4PxrRscS8Wz60mC4gSLad1vPFc4epJwdBPk=URm_uJHw@mail.gmail.com>
In-Reply-To: <CAPLaKK4PxrRscS8Wz60mC4gSLad1vPFc4epJwdBPk=URm_uJHw@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] ipxe: update to upstream version
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Pj4+IE9uIDIxLjEyLjExIGF0IDE2OjQ2LCBSb2dlciBQYXUgTW9ubsOpPHJvZ2VyLnBhdUBlbnRl
bC51cGMuZWR1PiB3cm90ZToKPiAyMDExLzEyLzIxIEphbiBCZXVsaWNoIDxKQmV1bGljaEBzdXNl
LmNvbT46Cj4+Pj4+IE9uIDIwLjEyLjExIGF0IDA1OjIxLCBSb2dlciBQYXUgTW9ubmUgPHJvZ2Vy
LnBhdUBlbnRlbC51cGMuZWR1PiB3cm90ZToKPj4+IC0tLSBhL3Rvb2xzL2Zpcm13YXJlL2V0aGVy
Ym9vdC9NYWtlZmlsZSAgICAgICBGcmkgRGVjIDA5IDE2OjE5OjM2IDIwMTEgKzAwMDAKPj4+ICsr
KyBiL3Rvb2xzL2Zpcm13YXJlL2V0aGVyYm9vdC9NYWtlZmlsZSAgICAgICBUdWUgRGVjIDIwIDA1
OjIwOjAyIDIwMTEgKzAxMDAKPj4+IEBAIC0xMCw5ICsxMCw3IEBAIGVsc2UKPj4+ICBJUFhFX0dJ
VF9VUkwgOj0gZ2l0Oi8vZ2l0LmlweGUub3JnL2lweGUuZ2l0Cj4+PiAgZW5kaWYKPj4+Cj4+PiAt
SVBYRV9HSVRfVEFHIDo9IHYxLjAuMAo+Pj4gLQo+Pj4gLUlQWEVfVEFSQkFMTF9VUkwgOj0gJChY
RU5fRVhURklMRVNfVVJMKS9pcHhlLWdpdC0kKElQWEVfR0lUX1RBRykudGFyLmd6Cj4+PiArSVBY
RV9HSVRfVFJFRSA6PSA1NDBlNTk2MGRjNmI0OWVhY2YzNjdmN2MzMTlmZDA1NDY0NzRiODQ1Cj4+
Cj4+IElzICJUUkVFIiByZWFsbHkgYSBtZWFuaW5nZnVsIG5hbWUgdGFnIGhlcmU/ICJDT01NSVQi
IHdvdWxkIHNlZW0KPj4gbW9yZSByZWFzb25hYmxlIHRvIG1lLgo+IAo+IFdlbGwgdGhpcyBoYXNo
IGlzIGFjdHVhbGx5IHRoZSB0cmVlIGhhc2gsIG5vdCB0aGUgY29tbWl0IGhhc2gsIHNlZToKPiAK
PiBodHRwczovL2dpdC5pcHhlLm9yZy9pcHhlLmdpdC9jb21taXQvOWE5M2RiM2YwOTQ3NDg0ZTMw
ZTc1M2JiZDYxYTEwYjE3MzM2ZTIwZQoKQXMgdGhlIFVSTCBzYXlzLCB0aGlzIGlzIGEgY29tbWl0
IGhhc2guIFRoZSByZXByZXNlbnRhdGlvbiBvZiB0aGUgdHJlZSBhdAp0aGF0IGNvbW1pdCBjYW4g
YmUgb2J0YWluZWQgYnkgcmVwbGFjaW5nICJjb21taXQiIHdpdGggInRyZWUiLCB0aGF0J3MKY29y
cmVjdCwgYnV0IGFjY29yZGluZyB0byBteSAoYWRtaXR0ZWRseSB2ZXJ5IGxpbWl0ZWQpIGdpdCBr
bm93bGVkZ2UgaXQncwphbHdheXMgY29tbWl0cyAoYW5kIG1heWJlIGEgZmV3IG90aGVyIHRoaW5n
cykgdGhhdCBnZXQgaGFzaGVzIGFzc2lnbmVkLApuZXZlciB0cmVlcy4KCj4+Pgo+Pj4gIEQ9aXB4
ZQo+Pj4gIFQ9aXB4ZS50YXIuZ3oKPj4+IEBAIC0zNSwxMiArMzMsMTAgQEAgZWItcm9tcy5oOiBD
b25maWcKPj4+ICAgICAgIG12IC1mICRALm5ldyAkQAo+Pj4KPj4+ICAkVDoKPj4+IC0gICAgIGlm
ICEgd2dldCAtTyBfJFQgJChJUFhFX1RBUkJBTExfVVJMKTsgdGhlbiBcCj4+PiAtICAgICAgICAg
ICAgICQoR0lUKSBjbG9uZSAkKElQWEVfR0lUX1VSTCkgJEQuZ2l0OyBcCj4+PiAtICAgICAgICAg
ICAgIChjZCAkRC5naXQgJiYgJChHSVQpIGFyY2hpdmUgLS1mb3JtYXQ9dGFyIC0tcHJlZml4PSRE
LyBcCj4+PiAtICAgICAgICAgICAgICQoSVBYRV9HSVRfVEFHKSB8IGd6aXAgPi4uL18kVCk7IFwK
Pj4+IC0gICAgICAgICAgICAgcm0gLXJmICRELmdpdDsgXAo+Pj4gLSAgICAgZmkKPj4+ICsgICAg
ICQoR0lUKSBjbG9uZSAkKElQWEVfR0lUX1VSTCkgJEQuZ2l0OyBcCj4+PiArICAgICAoY2QgJEQu
Z2l0ICYmICQoR0lUKSBhcmNoaXZlIC0tZm9ybWF0PXRhciAtLXByZWZpeD0kRC8gXAo+Pj4gKyAg
ICAgJChJUFhFX0dJVF9UUkVFKSB8IGd6aXAgPi4uL18kVCk7IFwKPj4+ICsgICAgIHJtIC1yZiAk
RC5naXQ7IFwKPj4+ICAgICAgIG12IF8kVCAkVAo+Pj4KPj4+ICAkRC9zcmMvYXJjaC9pMzg2L01h
a2VmaWxlOiAkVCBDb25maWcKPj4KPj4gUGxlYXNlIHJldGFpbiB0aGUgb3B0aW9uIHRvIGhhdmUg
YSB0YXJiYWxsLCBzbyBvbmUgY2FuIGVhc2lseSBwb2ludAo+PiB0aGlzIHRvIHNvbWUgbG9jYWwg
ZmlsZSAoYW5kIG5vdCByZXF1aXJlIGEgZnVuY3Rpb25hbCBuZXR3b3JrLCBub3IKPj4gaGF2aW5n
IHRvIHRvbGVyYXRlIHRoZSBzbG93bmVzcyBvZiB0aGUgY2xvbmluZyBwcm9jZXNzLCBub3IgaGF2
aW5nCj4+IHRvIGhhdmUgZ2l0IGluc3RhbGxlZCBldmVyeXdoZXJlKS4KPiAKPiBUaGlzIHBhdGNo
IHJldGFpbnMgdGhlIG9wdGlvbiB0byBoYXZlIGEgdGFyYmFsbCwgaWYgaXQgZmluZHMgYQo+IGlw
eGUudGFyLmd6LCBub3RoaW5nIGlzIGRvd25sb2FkZWQuCgpIbW0sIG9rYXkuIEJ1dCB0aGUgd2F5
IHlvdSBtb2RpZnkgdGhlIGxvZ2ljIHRoaW5ncyB3aWxsIG5lZWQgdG8gYmUKcmV2ZXJ0ZWQgb25j
ZSBhIHByb3BlciB0YWcgYmVjb21lcyBhdmFpbGFibGUgaW4gdGhhdCB0cmVlIGFnYWluLgpJJ2Qg
dGhpbmsgc3VjaCBzd2l0Y2hpbmcgYXJvdW5kIHNob3VsZG4ndCAoZ29pbmcgZm9yd2FyZCBhdCBs
ZWFzdCkKcmVxdWlyZSBtb3JlIHRoYW4gb25lIG9yIHR3byBjaGFuZ2VkIGxpbmVzLiBDYW4ndCB5
b3UganVzdApzZXQgSVBYRV9HSVRfVEFHIHRvIHRoZSBjb21taXQgaGFzaCB5b3Ugd2FudCwgYW5k
IGxlYXZlCmV2ZXJ5dGhpbmcgZWxzZSB1bnRvdWNoZWQ/CgpKYW4KCl9fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVu
LWRldmVsQGxpc3RzLnhlbnNvdXJjZS5jb20KaHR0cDovL2xpc3RzLnhlbnNvdXJjZS5jb20veGVu
LWRldmVsCg==

From xen-devel-bounces@lists.xensource.com Wed Dec 21 16:10:00 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 16:10:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdOjW-0001Qm-6p; Wed, 21 Dec 2011 16:09:34 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RdOjU-0001QU-Ve
	for xen-devel@lists.xensource.com; Wed, 21 Dec 2011 16:09:33 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1324483764!8179153!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28676 invoked from network); 21 Dec 2011 16:09:25 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-6.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Dec 2011 16:09:25 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 21 Dec 2011 16:10:34 +0000
Message-Id: <4EF212FA020000780006966B@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 21 Dec 2011 16:10:18 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "=?UTF-8?Q?Roger=20Pau=20Monn=C3=A9?=" <roger.pau@entel.upc.edu>
References: <d61e6300274bbc6bc464.1324354898@alpine.localdomain>
	<4EF204BF020000780006963F@nat28.tlf.novell.com>
	<CAPLaKK4PxrRscS8Wz60mC4gSLad1vPFc4epJwdBPk=URm_uJHw@mail.gmail.com>
In-Reply-To: <CAPLaKK4PxrRscS8Wz60mC4gSLad1vPFc4epJwdBPk=URm_uJHw@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] ipxe: update to upstream version
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Pj4+IE9uIDIxLjEyLjExIGF0IDE2OjQ2LCBSb2dlciBQYXUgTW9ubsOpPHJvZ2VyLnBhdUBlbnRl
bC51cGMuZWR1PiB3cm90ZToKPiAyMDExLzEyLzIxIEphbiBCZXVsaWNoIDxKQmV1bGljaEBzdXNl
LmNvbT46Cj4+Pj4+IE9uIDIwLjEyLjExIGF0IDA1OjIxLCBSb2dlciBQYXUgTW9ubmUgPHJvZ2Vy
LnBhdUBlbnRlbC51cGMuZWR1PiB3cm90ZToKPj4+IC0tLSBhL3Rvb2xzL2Zpcm13YXJlL2V0aGVy
Ym9vdC9NYWtlZmlsZSAgICAgICBGcmkgRGVjIDA5IDE2OjE5OjM2IDIwMTEgKzAwMDAKPj4+ICsr
KyBiL3Rvb2xzL2Zpcm13YXJlL2V0aGVyYm9vdC9NYWtlZmlsZSAgICAgICBUdWUgRGVjIDIwIDA1
OjIwOjAyIDIwMTEgKzAxMDAKPj4+IEBAIC0xMCw5ICsxMCw3IEBAIGVsc2UKPj4+ICBJUFhFX0dJ
VF9VUkwgOj0gZ2l0Oi8vZ2l0LmlweGUub3JnL2lweGUuZ2l0Cj4+PiAgZW5kaWYKPj4+Cj4+PiAt
SVBYRV9HSVRfVEFHIDo9IHYxLjAuMAo+Pj4gLQo+Pj4gLUlQWEVfVEFSQkFMTF9VUkwgOj0gJChY
RU5fRVhURklMRVNfVVJMKS9pcHhlLWdpdC0kKElQWEVfR0lUX1RBRykudGFyLmd6Cj4+PiArSVBY
RV9HSVRfVFJFRSA6PSA1NDBlNTk2MGRjNmI0OWVhY2YzNjdmN2MzMTlmZDA1NDY0NzRiODQ1Cj4+
Cj4+IElzICJUUkVFIiByZWFsbHkgYSBtZWFuaW5nZnVsIG5hbWUgdGFnIGhlcmU/ICJDT01NSVQi
IHdvdWxkIHNlZW0KPj4gbW9yZSByZWFzb25hYmxlIHRvIG1lLgo+IAo+IFdlbGwgdGhpcyBoYXNo
IGlzIGFjdHVhbGx5IHRoZSB0cmVlIGhhc2gsIG5vdCB0aGUgY29tbWl0IGhhc2gsIHNlZToKPiAK
PiBodHRwczovL2dpdC5pcHhlLm9yZy9pcHhlLmdpdC9jb21taXQvOWE5M2RiM2YwOTQ3NDg0ZTMw
ZTc1M2JiZDYxYTEwYjE3MzM2ZTIwZQoKQXMgdGhlIFVSTCBzYXlzLCB0aGlzIGlzIGEgY29tbWl0
IGhhc2guIFRoZSByZXByZXNlbnRhdGlvbiBvZiB0aGUgdHJlZSBhdAp0aGF0IGNvbW1pdCBjYW4g
YmUgb2J0YWluZWQgYnkgcmVwbGFjaW5nICJjb21taXQiIHdpdGggInRyZWUiLCB0aGF0J3MKY29y
cmVjdCwgYnV0IGFjY29yZGluZyB0byBteSAoYWRtaXR0ZWRseSB2ZXJ5IGxpbWl0ZWQpIGdpdCBr
bm93bGVkZ2UgaXQncwphbHdheXMgY29tbWl0cyAoYW5kIG1heWJlIGEgZmV3IG90aGVyIHRoaW5n
cykgdGhhdCBnZXQgaGFzaGVzIGFzc2lnbmVkLApuZXZlciB0cmVlcy4KCj4+Pgo+Pj4gIEQ9aXB4
ZQo+Pj4gIFQ9aXB4ZS50YXIuZ3oKPj4+IEBAIC0zNSwxMiArMzMsMTAgQEAgZWItcm9tcy5oOiBD
b25maWcKPj4+ICAgICAgIG12IC1mICRALm5ldyAkQAo+Pj4KPj4+ICAkVDoKPj4+IC0gICAgIGlm
ICEgd2dldCAtTyBfJFQgJChJUFhFX1RBUkJBTExfVVJMKTsgdGhlbiBcCj4+PiAtICAgICAgICAg
ICAgICQoR0lUKSBjbG9uZSAkKElQWEVfR0lUX1VSTCkgJEQuZ2l0OyBcCj4+PiAtICAgICAgICAg
ICAgIChjZCAkRC5naXQgJiYgJChHSVQpIGFyY2hpdmUgLS1mb3JtYXQ9dGFyIC0tcHJlZml4PSRE
LyBcCj4+PiAtICAgICAgICAgICAgICQoSVBYRV9HSVRfVEFHKSB8IGd6aXAgPi4uL18kVCk7IFwK
Pj4+IC0gICAgICAgICAgICAgcm0gLXJmICRELmdpdDsgXAo+Pj4gLSAgICAgZmkKPj4+ICsgICAg
ICQoR0lUKSBjbG9uZSAkKElQWEVfR0lUX1VSTCkgJEQuZ2l0OyBcCj4+PiArICAgICAoY2QgJEQu
Z2l0ICYmICQoR0lUKSBhcmNoaXZlIC0tZm9ybWF0PXRhciAtLXByZWZpeD0kRC8gXAo+Pj4gKyAg
ICAgJChJUFhFX0dJVF9UUkVFKSB8IGd6aXAgPi4uL18kVCk7IFwKPj4+ICsgICAgIHJtIC1yZiAk
RC5naXQ7IFwKPj4+ICAgICAgIG12IF8kVCAkVAo+Pj4KPj4+ICAkRC9zcmMvYXJjaC9pMzg2L01h
a2VmaWxlOiAkVCBDb25maWcKPj4KPj4gUGxlYXNlIHJldGFpbiB0aGUgb3B0aW9uIHRvIGhhdmUg
YSB0YXJiYWxsLCBzbyBvbmUgY2FuIGVhc2lseSBwb2ludAo+PiB0aGlzIHRvIHNvbWUgbG9jYWwg
ZmlsZSAoYW5kIG5vdCByZXF1aXJlIGEgZnVuY3Rpb25hbCBuZXR3b3JrLCBub3IKPj4gaGF2aW5n
IHRvIHRvbGVyYXRlIHRoZSBzbG93bmVzcyBvZiB0aGUgY2xvbmluZyBwcm9jZXNzLCBub3IgaGF2
aW5nCj4+IHRvIGhhdmUgZ2l0IGluc3RhbGxlZCBldmVyeXdoZXJlKS4KPiAKPiBUaGlzIHBhdGNo
IHJldGFpbnMgdGhlIG9wdGlvbiB0byBoYXZlIGEgdGFyYmFsbCwgaWYgaXQgZmluZHMgYQo+IGlw
eGUudGFyLmd6LCBub3RoaW5nIGlzIGRvd25sb2FkZWQuCgpIbW0sIG9rYXkuIEJ1dCB0aGUgd2F5
IHlvdSBtb2RpZnkgdGhlIGxvZ2ljIHRoaW5ncyB3aWxsIG5lZWQgdG8gYmUKcmV2ZXJ0ZWQgb25j
ZSBhIHByb3BlciB0YWcgYmVjb21lcyBhdmFpbGFibGUgaW4gdGhhdCB0cmVlIGFnYWluLgpJJ2Qg
dGhpbmsgc3VjaCBzd2l0Y2hpbmcgYXJvdW5kIHNob3VsZG4ndCAoZ29pbmcgZm9yd2FyZCBhdCBs
ZWFzdCkKcmVxdWlyZSBtb3JlIHRoYW4gb25lIG9yIHR3byBjaGFuZ2VkIGxpbmVzLiBDYW4ndCB5
b3UganVzdApzZXQgSVBYRV9HSVRfVEFHIHRvIHRoZSBjb21taXQgaGFzaCB5b3Ugd2FudCwgYW5k
IGxlYXZlCmV2ZXJ5dGhpbmcgZWxzZSB1bnRvdWNoZWQ/CgpKYW4KCl9fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVu
LWRldmVsQGxpc3RzLnhlbnNvdXJjZS5jb20KaHR0cDovL2xpc3RzLnhlbnNvdXJjZS5jb20veGVu
LWRldmVsCg==

From xen-devel-bounces@lists.xensource.com Wed Dec 21 16:21:16 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 16:21:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdOuW-0001tE-Ew; Wed, 21 Dec 2011 16:20:56 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <xiantao.zhang@intel.com>) id 1RdOuV-0001t4-02
	for xen-devel@lists.xensource.com; Wed, 21 Dec 2011 16:20:55 +0000
X-Env-Sender: xiantao.zhang@intel.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1324484447!6447002!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDI5OTg0MA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8593 invoked from network); 21 Dec 2011 16:20:48 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-10.tower-174.messagelabs.com with SMTP;
	21 Dec 2011 16:20:48 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga102.fm.intel.com with ESMTP; 21 Dec 2011 08:20:46 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="98853382"
Received: from pgsmsx603.gar.corp.intel.com ([10.221.43.87])
	by fmsmga001.fm.intel.com with ESMTP; 21 Dec 2011 08:20:45 -0800
Received: from shsmsx601.ccr.corp.intel.com (10.239.4.112) by
	pgsmsx603.gar.corp.intel.com (10.221.43.87) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Thu, 22 Dec 2011 00:20:44 +0800
Received: from shsmsx502.ccr.corp.intel.com ([10.239.4.96]) by
	shsmsx601.ccr.corp.intel.com ([10.239.4.112]) with mapi;
	Thu, 22 Dec 2011 00:20:43 +0800
From: "Zhang, Xiantao" <xiantao.zhang@intel.com>
To: Keir Fraser <keir@xen.org>, "Shan, Haitao" <haitao.shan@intel.com>, Konrad
	Rzeszutek Wilk <konrad@darnok.org>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>, Konrad Rzeszutek Wilk
	<konrad.wilk@oracle.com>, George Dunlap <George.Dunlap@eu.citrix.com>, 
	"andrew.thomas@oracle.com" <andrew.thomas@oracle.com>
Date: Thu, 22 Dec 2011 00:20:42 +0800
Thread-Topic: [Xen-devel] issues with PLE and/or scheduler.
Thread-Index: Acy/WC58GrEeWsJBTKeBU9VJiBfb5QAJ2kbQABFXDVAABLrZBQAGusrQ
Message-ID: <BC00F5384FCFC9499AF06F92E8B78A9E2890487D80@shsmsx502.ccr.corp.intel.com>
References: <BC00F5384FCFC9499AF06F92E8B78A9E2890487CF5@shsmsx502.ccr.corp.intel.com>
	<CB177A6D.365E1%keir@xen.org>
In-Reply-To: <CB177A6D.365E1%keir@xen.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Subject: Re: [Xen-devel] issues with PLE and/or scheduler.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

05:54:54 2011 +0800
> > @@ -129,7 +129,7 @@
> >      if ( missed_ticks <= 0 )
> >          return;
> >
> > -    missed_ticks = missed_ticks / (s_time_t) pt->period + 1;
> > +    missed_ticks = missed_ticks / (s_time_t) pt->period;
> >      if ( mode_is(pt->vcpu->domain, no_missed_ticks_pending) )
> >          pt->do_not_freeze = !pt->pending_intr_nr;
> >      else
> >
> > Anyone can explain the above "plus one" logic ?   why assume at least one
> tick
> > is missed in pt_process_missed_ticks ?
> 
> missed_ticks = now - pt->scheduled
> 
> pt->scheduled was deadline for next tick. Hence the number of missed
> pt->ticks
> is the total number of period that have passed since pt->scheduled, plus one.
> If we had not missed at least one tick, we would return early, from the if-
> statement at the top of your patch fragment, above.
> What's the guest timer_mode? If there was at least one missed tick I would
> have expected a timer interrupt to get injected straight away. Except
> perhaps for timer_mode=2=no_missed_ticks_pending -- I don't understand
> that timer mode, and perhaps there could be a bad interaction with its
> specific interrupt-holdoff logic.

Agree, in the if-statement, pt->do_not_freeze is set 1 if pt->pending_intr_nr ==0, so the timer is not stopped in next round's pt_save_timer.  In this case, we expect the timer can be fired after expiration. However, even if expiration occurs, the timer maybe not fired (because timer handler is executed in late softirq).  In this case, pt_process_missd_tick may see one missed tick and then delay this timer by one period, but pt->pending_intr_nr is not increased due to not-fired timer.  For example, in yield operation, due to short runq, scheduler may always select the previous vcpu as the next vcpu to run after yielding, so between pt_save_timer and pt_restore_timer, even if expiration occurs, it has no chance to fire the timer.    However, pt_restore_timer may call pt_process_missed_tick to re-calculate pt->scheduled which will be plused one pt->period once expiration occurs, then the timer is delayed without increasing pt->pending_intr_nr.  
I think the below patch can fix this issue.  if the timer is not stopped( in save logic )and not fired yet( in restore logic), we should keep the timer running until it is fired in softirq, and we shouldn't delay it through re-calculating its expiration time, because this may lead to guest's lost timer interrupts in some cases.     

diff -r 381ab77db71a xen/arch/x86/hvm/vpt.c
--- a/xen/arch/x86/hvm/vpt.c    Mon Apr 18 10:10:02 2011 +0100
+++ b/xen/arch/x86/hvm/vpt.c    Thu Dec 22 11:35:36 2011 +0800
@@ -185,7 +185,7 @@

     list_for_each_entry ( pt, head, list )
     {
-        if ( pt->pending_intr_nr == 0 )
+        if ( pt->pending_intr_nr == 0 && !pt->do_not_freeze)
         {
             pt_process_missed_ticks(pt);
             set_timer(&pt->timer, pt->scheduled);


> > We have reproduced your problem locally and are looking into this
> > issue. It seems "PLE with timer mode 2" will trigger the issue. We can
> > post our findings as soon as possible.
> 
> > Shan Haitao
> >
> >> -----Original Message-----
> >> From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-
> >> bounces@lists.xensource.com] On Behalf Of Konrad Rzeszutek Wilk
> >> Sent: Wednesday, December 21, 2011 4:42 AM
> >> To: xen-devel@lists.xensource.com; konrad.wilk@oracle.com;
> >> George.Dunlap@eu.citrix.com; keir@xen.org;
> andrew.thomas@oracle.com
> >> Subject: Re: [Xen-devel] issues with PLE and/or scheduler.
> >>
> >> On Tue, Dec 20, 2011 at 04:41:07PM -0400, Konrad Rzeszutek Wilk wrote:
> >>> Hey folks,
> >>>
> >>> I am sending this on behalf of Andrew since our internal email
> >>> system is dropping all xen-devel mailing lists :-(
> >>
> >> <hits his head> And I forgot to CC andrew on it. Added here.
> >>>
> >>> Anyhow:
> >>>
> >>> This is with xen-4.1-testing cs 23201:1c89f7d29fbb and using the
> >>> default "credit" scheduler.
> >>>
> >>> I've run into an interesting issue with HVM guests which make use of
> >>> Pause Loop Exiting (ie. on westmere systems; and also on romley
> >>> systems):  after yielding the cpu, guests don't seem to receive
> >>> timer interrupts correctly..
> >>>
> >>> Some background: for historical reasons (ie old templates) we boot
> >>> OL/RHEL guests with the following settings:
> >>>
> >>> kernel parameters: clock=pit nohpet nopmtimer
> >>> vm.cfg: timer_mode = 2
> >>>
> >>> With PLE enabled, 2.6.32 guests will crash early on with:
> >>>  ..MP-BIOS bug: 8254 timer not connected to IO-APIC  # a few lines
> >>> omitted..
> >>>  Kernel panic - not syncing: IO-APIC + timer doesn't work!  Boot
> >>> with apic=debug
> >>>
> >>> While 2.6.18-238 (ie OL/RHEL5u6) will fail to find the timer, but
> >>> continue and lock up in the serial line initialization.
> >>>
> >>>  ..MP-BIOS bug: 8254 timer not connected to IO-APIC  # continues
> >>> until lock up here:
> >>>  Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing
> >>> enabled
> >>>
> >>> Instrumenting the 2.6.32 code (ie timer_irq_works()) shows that
> >>> jiffies isn't advancing (or only 1 or 2 ticks are being received,
> >>> which is insufficient for "working"). This is on a "quiet" system
> >>> with
> > no
> >> other activity.
> >>> So, even though the guest has voluntarily yielded the cpu (through
> >>> PLE), I would still expect it to receive every clock tick (even with
> >>> timer_mode=2) as there is no other work to do on the system.
> >>>
> >>> Disabling PLE allows both 2.6.18 and 2.6.32 guests to boot.. [As an
> >>> aside, so does setting ple_gap to 41 (ie prior to
> >>> 21355:727ccaaa6cce)
> >>> -- the perf counters show no exits happening, so this is equivalent
> >>> to disabling PLE.]
> >>>
> >>> I'm hoping someone who knows the scheduler well will be able to
> >>> quickly decide whether this is a bug or a feature...
> >>>
> >>> Andrew
> >>
> >> _______________________________________________
> >> Xen-devel mailing list
> >> Xen-devel@lists.xensource.com
> >> http://lists.xensource.com/xen-devel
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 21 16:21:16 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 16:21:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdOuW-0001tE-Ew; Wed, 21 Dec 2011 16:20:56 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <xiantao.zhang@intel.com>) id 1RdOuV-0001t4-02
	for xen-devel@lists.xensource.com; Wed, 21 Dec 2011 16:20:55 +0000
X-Env-Sender: xiantao.zhang@intel.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1324484447!6447002!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDI5OTg0MA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8593 invoked from network); 21 Dec 2011 16:20:48 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-10.tower-174.messagelabs.com with SMTP;
	21 Dec 2011 16:20:48 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga102.fm.intel.com with ESMTP; 21 Dec 2011 08:20:46 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="98853382"
Received: from pgsmsx603.gar.corp.intel.com ([10.221.43.87])
	by fmsmga001.fm.intel.com with ESMTP; 21 Dec 2011 08:20:45 -0800
Received: from shsmsx601.ccr.corp.intel.com (10.239.4.112) by
	pgsmsx603.gar.corp.intel.com (10.221.43.87) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Thu, 22 Dec 2011 00:20:44 +0800
Received: from shsmsx502.ccr.corp.intel.com ([10.239.4.96]) by
	shsmsx601.ccr.corp.intel.com ([10.239.4.112]) with mapi;
	Thu, 22 Dec 2011 00:20:43 +0800
From: "Zhang, Xiantao" <xiantao.zhang@intel.com>
To: Keir Fraser <keir@xen.org>, "Shan, Haitao" <haitao.shan@intel.com>, Konrad
	Rzeszutek Wilk <konrad@darnok.org>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>, Konrad Rzeszutek Wilk
	<konrad.wilk@oracle.com>, George Dunlap <George.Dunlap@eu.citrix.com>, 
	"andrew.thomas@oracle.com" <andrew.thomas@oracle.com>
Date: Thu, 22 Dec 2011 00:20:42 +0800
Thread-Topic: [Xen-devel] issues with PLE and/or scheduler.
Thread-Index: Acy/WC58GrEeWsJBTKeBU9VJiBfb5QAJ2kbQABFXDVAABLrZBQAGusrQ
Message-ID: <BC00F5384FCFC9499AF06F92E8B78A9E2890487D80@shsmsx502.ccr.corp.intel.com>
References: <BC00F5384FCFC9499AF06F92E8B78A9E2890487CF5@shsmsx502.ccr.corp.intel.com>
	<CB177A6D.365E1%keir@xen.org>
In-Reply-To: <CB177A6D.365E1%keir@xen.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Subject: Re: [Xen-devel] issues with PLE and/or scheduler.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

05:54:54 2011 +0800
> > @@ -129,7 +129,7 @@
> >      if ( missed_ticks <= 0 )
> >          return;
> >
> > -    missed_ticks = missed_ticks / (s_time_t) pt->period + 1;
> > +    missed_ticks = missed_ticks / (s_time_t) pt->period;
> >      if ( mode_is(pt->vcpu->domain, no_missed_ticks_pending) )
> >          pt->do_not_freeze = !pt->pending_intr_nr;
> >      else
> >
> > Anyone can explain the above "plus one" logic ?   why assume at least one
> tick
> > is missed in pt_process_missed_ticks ?
> 
> missed_ticks = now - pt->scheduled
> 
> pt->scheduled was deadline for next tick. Hence the number of missed
> pt->ticks
> is the total number of period that have passed since pt->scheduled, plus one.
> If we had not missed at least one tick, we would return early, from the if-
> statement at the top of your patch fragment, above.
> What's the guest timer_mode? If there was at least one missed tick I would
> have expected a timer interrupt to get injected straight away. Except
> perhaps for timer_mode=2=no_missed_ticks_pending -- I don't understand
> that timer mode, and perhaps there could be a bad interaction with its
> specific interrupt-holdoff logic.

Agree, in the if-statement, pt->do_not_freeze is set 1 if pt->pending_intr_nr ==0, so the timer is not stopped in next round's pt_save_timer.  In this case, we expect the timer can be fired after expiration. However, even if expiration occurs, the timer maybe not fired (because timer handler is executed in late softirq).  In this case, pt_process_missd_tick may see one missed tick and then delay this timer by one period, but pt->pending_intr_nr is not increased due to not-fired timer.  For example, in yield operation, due to short runq, scheduler may always select the previous vcpu as the next vcpu to run after yielding, so between pt_save_timer and pt_restore_timer, even if expiration occurs, it has no chance to fire the timer.    However, pt_restore_timer may call pt_process_missed_tick to re-calculate pt->scheduled which will be plused one pt->period once expiration occurs, then the timer is delayed without increasing pt->pending_intr_nr.  
I think the below patch can fix this issue.  if the timer is not stopped( in save logic )and not fired yet( in restore logic), we should keep the timer running until it is fired in softirq, and we shouldn't delay it through re-calculating its expiration time, because this may lead to guest's lost timer interrupts in some cases.     

diff -r 381ab77db71a xen/arch/x86/hvm/vpt.c
--- a/xen/arch/x86/hvm/vpt.c    Mon Apr 18 10:10:02 2011 +0100
+++ b/xen/arch/x86/hvm/vpt.c    Thu Dec 22 11:35:36 2011 +0800
@@ -185,7 +185,7 @@

     list_for_each_entry ( pt, head, list )
     {
-        if ( pt->pending_intr_nr == 0 )
+        if ( pt->pending_intr_nr == 0 && !pt->do_not_freeze)
         {
             pt_process_missed_ticks(pt);
             set_timer(&pt->timer, pt->scheduled);


> > We have reproduced your problem locally and are looking into this
> > issue. It seems "PLE with timer mode 2" will trigger the issue. We can
> > post our findings as soon as possible.
> 
> > Shan Haitao
> >
> >> -----Original Message-----
> >> From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-
> >> bounces@lists.xensource.com] On Behalf Of Konrad Rzeszutek Wilk
> >> Sent: Wednesday, December 21, 2011 4:42 AM
> >> To: xen-devel@lists.xensource.com; konrad.wilk@oracle.com;
> >> George.Dunlap@eu.citrix.com; keir@xen.org;
> andrew.thomas@oracle.com
> >> Subject: Re: [Xen-devel] issues with PLE and/or scheduler.
> >>
> >> On Tue, Dec 20, 2011 at 04:41:07PM -0400, Konrad Rzeszutek Wilk wrote:
> >>> Hey folks,
> >>>
> >>> I am sending this on behalf of Andrew since our internal email
> >>> system is dropping all xen-devel mailing lists :-(
> >>
> >> <hits his head> And I forgot to CC andrew on it. Added here.
> >>>
> >>> Anyhow:
> >>>
> >>> This is with xen-4.1-testing cs 23201:1c89f7d29fbb and using the
> >>> default "credit" scheduler.
> >>>
> >>> I've run into an interesting issue with HVM guests which make use of
> >>> Pause Loop Exiting (ie. on westmere systems; and also on romley
> >>> systems):  after yielding the cpu, guests don't seem to receive
> >>> timer interrupts correctly..
> >>>
> >>> Some background: for historical reasons (ie old templates) we boot
> >>> OL/RHEL guests with the following settings:
> >>>
> >>> kernel parameters: clock=pit nohpet nopmtimer
> >>> vm.cfg: timer_mode = 2
> >>>
> >>> With PLE enabled, 2.6.32 guests will crash early on with:
> >>>  ..MP-BIOS bug: 8254 timer not connected to IO-APIC  # a few lines
> >>> omitted..
> >>>  Kernel panic - not syncing: IO-APIC + timer doesn't work!  Boot
> >>> with apic=debug
> >>>
> >>> While 2.6.18-238 (ie OL/RHEL5u6) will fail to find the timer, but
> >>> continue and lock up in the serial line initialization.
> >>>
> >>>  ..MP-BIOS bug: 8254 timer not connected to IO-APIC  # continues
> >>> until lock up here:
> >>>  Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing
> >>> enabled
> >>>
> >>> Instrumenting the 2.6.32 code (ie timer_irq_works()) shows that
> >>> jiffies isn't advancing (or only 1 or 2 ticks are being received,
> >>> which is insufficient for "working"). This is on a "quiet" system
> >>> with
> > no
> >> other activity.
> >>> So, even though the guest has voluntarily yielded the cpu (through
> >>> PLE), I would still expect it to receive every clock tick (even with
> >>> timer_mode=2) as there is no other work to do on the system.
> >>>
> >>> Disabling PLE allows both 2.6.18 and 2.6.32 guests to boot.. [As an
> >>> aside, so does setting ple_gap to 41 (ie prior to
> >>> 21355:727ccaaa6cce)
> >>> -- the perf counters show no exits happening, so this is equivalent
> >>> to disabling PLE.]
> >>>
> >>> I'm hoping someone who knows the scheduler well will be able to
> >>> quickly decide whether this is a bug or a feature...
> >>>
> >>> Andrew
> >>
> >> _______________________________________________
> >> Xen-devel mailing list
> >> Xen-devel@lists.xensource.com
> >> http://lists.xensource.com/xen-devel
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 21 16:29:44 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 16: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.xensource.com>)
	id 1RdP2f-00027s-EV; Wed, 21 Dec 2011 16:29:21 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <gang.wei@intel.com>) id 1RdP2e-00027i-D1
	for xen-devel@lists.xensource.com; Wed, 21 Dec 2011 16:29:20 +0000
X-Env-Sender: gang.wei@intel.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1324484953!8319628!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMjg5NzA2\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16507 invoked from network); 21 Dec 2011 16:29:14 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-15.tower-216.messagelabs.com with SMTP;
	21 Dec 2011 16:29:14 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga101.jf.intel.com with ESMTP; 21 Dec 2011 08:29:13 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.67,351,1309762800"; d="scan'208";a="90038537"
Received: from pgsmsx602.gar.corp.intel.com ([10.221.43.81])
	by orsmga002.jf.intel.com with ESMTP; 21 Dec 2011 08:29:11 -0800
Received: from shsmsx602.ccr.corp.intel.com (10.239.4.104) by
	pgsmsx602.gar.corp.intel.com (10.221.43.81) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Thu, 22 Dec 2011 00:28:10 +0800
Received: from shsmsx502.ccr.corp.intel.com ([10.239.4.96]) by
	SHSMSX602.ccr.corp.intel.com ([10.239.4.104]) with mapi;
	Thu, 22 Dec 2011 00:28:10 +0800
From: "Wei, Gang" <gang.wei@intel.com>
To: Keir Fraser <keir@xen.org>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>
Date: Thu, 22 Dec 2011 00:28:07 +0800
Thread-Topic: [patch] x86: Add a delay between INIT & SIPIs for AP bring-up
	in X2APIC case
Thread-Index: Acy/0uD62iL7OBXBT0+nwXPeOaB7qgABgY/9AAA3VoAAAIsegAABmTKGAAYPl8A=
Message-ID: <F26D193E20BBDC42A43B611D1BDEDE7135CEEEAEB6@shsmsx502.ccr.corp.intel.com>
References: <F26D193E20BBDC42A43B611D1BDEDE7135CEEEAE65@shsmsx502.ccr.corp.intel.com>
	<CB178BFB.36631%keir@xen.org>
In-Reply-To: <CB178BFB.36631%keir@xen.org>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
acceptlanguage: zh-CN, en-US
Content-Type: multipart/mixed;
	boundary="_002_F26D193E20BBDC42A43B611D1BDEDE7135CEEEAEB6shsmsx502ccrc_"
MIME-Version: 1.0
Cc: "tboot-devel@lists.sourceforge.net" <tboot-devel@lists.sourceforge.net>,
	"Cihula, Joseph" <joseph.cihula@intel.com>,
	Tim Deegan <Tim.Deegan@citrix.com>, Jan Beulich <jbeulich@suse.com>, "Wei,
	Gang" <gang.wei@intel.com>
Subject: Re: [Xen-devel] [patch] x86: Add a delay between INIT & SIPIs for
 AP bring-up in X2APIC case
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--_002_F26D193E20BBDC42A43B611D1BDEDE7135CEEEAEB6shsmsx502ccrc_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

(resend)

Without this delay, Xen could not bring APs up while working with TXT/tboot=
, because tboot need some time in APs to handle INIT before becoming ready =
for receiving SIPIs.(this delay was removed as part of c/s 23724 by Tim Dee=
gan)

Signed-off-by: Gang Wei <gang.wei@intel.com>
Acked-by: Keir Fraser <keir@xen.org>

diff -r d1aefee43af1 xen/arch/x86/smpboot.c
--- a/xen/arch/x86/smpboot.c	Wed Dec 21 18:51:31 2011 +0800
+++ b/xen/arch/x86/smpboot.c	Thu Dec 22 00:26:52 2011 +0800
@@ -42,6 +42,7 @@
 #include <asm/msr.h>
 #include <asm/mtrr.h>
 #include <asm/time.h>
+#include <asm/tboot.h>
 #include <mach_apic.h>
 #include <mach_wakecpu.h>
 #include <smpboot_hooks.h>
@@ -463,6 +464,14 @@
             send_status =3D apic_read(APIC_ICR) & APIC_ICR_BUSY;
         } while ( send_status && (timeout++ < 1000) );
     }
+    else if ( tboot_in_measured_env() )
+    {
+        /*
+         * give AP time to handle INIT before ready to receive SIPIs
+         * otherwise SIPIs may be skipped and AP will fail to up
+         */
+        udelay(10);
+    }
=20
     /*
      * Should we send STARTUP IPIs ?

--_002_F26D193E20BBDC42A43B611D1BDEDE7135CEEEAEB6shsmsx502ccrc_
Content-Type: application/octet-stream; name="delay-btw-init-and-sipi.patch"
Content-Description: delay-btw-init-and-sipi.patch
Content-Disposition: attachment; filename="delay-btw-init-and-sipi.patch";
	size=1170; creation-date="Thu, 22 Dec 2011 00:26:57 GMT";
	modification-date="Thu, 22 Dec 2011 00:26:52 GMT"
Content-Transfer-Encoding: base64

WDg2OiBBZGQgYSBkZWxheSBiZXR3ZWVuIElOSVQgJiBTSVBJcyBmb3IgQVAgYnJpbmctdXAgaW4g
WDJBUElDIGNhc2UKCldpdGhvdXQgdGhpcyBkZWxheSwgWGVuIGNvdWxkIG5vdCBicmluZyBBUHMg
dXAgd2hpbGUgd29ya2luZyB3aXRoIFRYVC90Ym9vdCwgYmVjYXVzZSB0Ym9vdCBuZWVkIHNvbWUg
dGltZSBpbiBBUHMgdG8gaGFuZGxlIElOSVQgYmVmb3JlIGJlY29taW5nIHJlYWR5IGZvciByZWNl
aXZpbmcgU0lQSXMuKHRoaXMgZGVsYXkgd2FzIHJlbW92ZWQgYXMgcGFydCBvZiBjL3MgMjM3MjQg
YnkgVGltIERlZWdhbikKClNpZ25lZC1vZmYtYnk6IEdhbmcgV2VpIDxnYW5nLndlaUBpbnRlbC5j
b20+CkFja2VkLWJ5OiBLZWlyIEZyYXNlciA8a2VpckB4ZW4ub3JnPgoKZGlmZiAtciBkMWFlZmVl
NDNhZjEgeGVuL2FyY2gveDg2L3NtcGJvb3QuYwotLS0gYS94ZW4vYXJjaC94ODYvc21wYm9vdC5j
CVdlZCBEZWMgMjEgMTg6NTE6MzEgMjAxMSArMDgwMAorKysgYi94ZW4vYXJjaC94ODYvc21wYm9v
dC5jCVRodSBEZWMgMjIgMDA6MjY6NTIgMjAxMSArMDgwMApAQCAtNDIsNiArNDIsNyBAQAogI2lu
Y2x1ZGUgPGFzbS9tc3IuaD4KICNpbmNsdWRlIDxhc20vbXRyci5oPgogI2luY2x1ZGUgPGFzbS90
aW1lLmg+CisjaW5jbHVkZSA8YXNtL3Rib290Lmg+CiAjaW5jbHVkZSA8bWFjaF9hcGljLmg+CiAj
aW5jbHVkZSA8bWFjaF93YWtlY3B1Lmg+CiAjaW5jbHVkZSA8c21wYm9vdF9ob29rcy5oPgpAQCAt
NDYzLDYgKzQ2NCwxNCBAQAogICAgICAgICAgICAgc2VuZF9zdGF0dXMgPSBhcGljX3JlYWQoQVBJ
Q19JQ1IpICYgQVBJQ19JQ1JfQlVTWTsKICAgICAgICAgfSB3aGlsZSAoIHNlbmRfc3RhdHVzICYm
ICh0aW1lb3V0KysgPCAxMDAwKSApOwogICAgIH0KKyAgICBlbHNlIGlmICggdGJvb3RfaW5fbWVh
c3VyZWRfZW52KCkgKQorICAgIHsKKyAgICAgICAgLyoKKyAgICAgICAgICogZ2l2ZSBBUCB0aW1l
IHRvIGhhbmRsZSBJTklUIGJlZm9yZSByZWFkeSB0byByZWNlaXZlIFNJUElzCisgICAgICAgICAq
IG90aGVyd2lzZSBTSVBJcyBtYXkgYmUgc2tpcHBlZCBhbmQgQVAgd2lsbCBmYWlsIHRvIHVwCisg
ICAgICAgICAqLworICAgICAgICB1ZGVsYXkoMTApOworICAgIH0KIAogICAgIC8qCiAgICAgICog
U2hvdWxkIHdlIHNlbmQgU1RBUlRVUCBJUElzID8K

--_002_F26D193E20BBDC42A43B611D1BDEDE7135CEEEAEB6shsmsx502ccrc_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--_002_F26D193E20BBDC42A43B611D1BDEDE7135CEEEAEB6shsmsx502ccrc_--


From xen-devel-bounces@lists.xensource.com Wed Dec 21 16:29:44 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 16: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.xensource.com>)
	id 1RdP2f-00027s-EV; Wed, 21 Dec 2011 16:29:21 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <gang.wei@intel.com>) id 1RdP2e-00027i-D1
	for xen-devel@lists.xensource.com; Wed, 21 Dec 2011 16:29:20 +0000
X-Env-Sender: gang.wei@intel.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1324484953!8319628!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMjg5NzA2\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16507 invoked from network); 21 Dec 2011 16:29:14 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-15.tower-216.messagelabs.com with SMTP;
	21 Dec 2011 16:29:14 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga101.jf.intel.com with ESMTP; 21 Dec 2011 08:29:13 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.67,351,1309762800"; d="scan'208";a="90038537"
Received: from pgsmsx602.gar.corp.intel.com ([10.221.43.81])
	by orsmga002.jf.intel.com with ESMTP; 21 Dec 2011 08:29:11 -0800
Received: from shsmsx602.ccr.corp.intel.com (10.239.4.104) by
	pgsmsx602.gar.corp.intel.com (10.221.43.81) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Thu, 22 Dec 2011 00:28:10 +0800
Received: from shsmsx502.ccr.corp.intel.com ([10.239.4.96]) by
	SHSMSX602.ccr.corp.intel.com ([10.239.4.104]) with mapi;
	Thu, 22 Dec 2011 00:28:10 +0800
From: "Wei, Gang" <gang.wei@intel.com>
To: Keir Fraser <keir@xen.org>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>
Date: Thu, 22 Dec 2011 00:28:07 +0800
Thread-Topic: [patch] x86: Add a delay between INIT & SIPIs for AP bring-up
	in X2APIC case
Thread-Index: Acy/0uD62iL7OBXBT0+nwXPeOaB7qgABgY/9AAA3VoAAAIsegAABmTKGAAYPl8A=
Message-ID: <F26D193E20BBDC42A43B611D1BDEDE7135CEEEAEB6@shsmsx502.ccr.corp.intel.com>
References: <F26D193E20BBDC42A43B611D1BDEDE7135CEEEAE65@shsmsx502.ccr.corp.intel.com>
	<CB178BFB.36631%keir@xen.org>
In-Reply-To: <CB178BFB.36631%keir@xen.org>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
acceptlanguage: zh-CN, en-US
Content-Type: multipart/mixed;
	boundary="_002_F26D193E20BBDC42A43B611D1BDEDE7135CEEEAEB6shsmsx502ccrc_"
MIME-Version: 1.0
Cc: "tboot-devel@lists.sourceforge.net" <tboot-devel@lists.sourceforge.net>,
	"Cihula, Joseph" <joseph.cihula@intel.com>,
	Tim Deegan <Tim.Deegan@citrix.com>, Jan Beulich <jbeulich@suse.com>, "Wei,
	Gang" <gang.wei@intel.com>
Subject: Re: [Xen-devel] [patch] x86: Add a delay between INIT & SIPIs for
 AP bring-up in X2APIC case
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--_002_F26D193E20BBDC42A43B611D1BDEDE7135CEEEAEB6shsmsx502ccrc_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

(resend)

Without this delay, Xen could not bring APs up while working with TXT/tboot=
, because tboot need some time in APs to handle INIT before becoming ready =
for receiving SIPIs.(this delay was removed as part of c/s 23724 by Tim Dee=
gan)

Signed-off-by: Gang Wei <gang.wei@intel.com>
Acked-by: Keir Fraser <keir@xen.org>

diff -r d1aefee43af1 xen/arch/x86/smpboot.c
--- a/xen/arch/x86/smpboot.c	Wed Dec 21 18:51:31 2011 +0800
+++ b/xen/arch/x86/smpboot.c	Thu Dec 22 00:26:52 2011 +0800
@@ -42,6 +42,7 @@
 #include <asm/msr.h>
 #include <asm/mtrr.h>
 #include <asm/time.h>
+#include <asm/tboot.h>
 #include <mach_apic.h>
 #include <mach_wakecpu.h>
 #include <smpboot_hooks.h>
@@ -463,6 +464,14 @@
             send_status =3D apic_read(APIC_ICR) & APIC_ICR_BUSY;
         } while ( send_status && (timeout++ < 1000) );
     }
+    else if ( tboot_in_measured_env() )
+    {
+        /*
+         * give AP time to handle INIT before ready to receive SIPIs
+         * otherwise SIPIs may be skipped and AP will fail to up
+         */
+        udelay(10);
+    }
=20
     /*
      * Should we send STARTUP IPIs ?

--_002_F26D193E20BBDC42A43B611D1BDEDE7135CEEEAEB6shsmsx502ccrc_
Content-Type: application/octet-stream; name="delay-btw-init-and-sipi.patch"
Content-Description: delay-btw-init-and-sipi.patch
Content-Disposition: attachment; filename="delay-btw-init-and-sipi.patch";
	size=1170; creation-date="Thu, 22 Dec 2011 00:26:57 GMT";
	modification-date="Thu, 22 Dec 2011 00:26:52 GMT"
Content-Transfer-Encoding: base64

WDg2OiBBZGQgYSBkZWxheSBiZXR3ZWVuIElOSVQgJiBTSVBJcyBmb3IgQVAgYnJpbmctdXAgaW4g
WDJBUElDIGNhc2UKCldpdGhvdXQgdGhpcyBkZWxheSwgWGVuIGNvdWxkIG5vdCBicmluZyBBUHMg
dXAgd2hpbGUgd29ya2luZyB3aXRoIFRYVC90Ym9vdCwgYmVjYXVzZSB0Ym9vdCBuZWVkIHNvbWUg
dGltZSBpbiBBUHMgdG8gaGFuZGxlIElOSVQgYmVmb3JlIGJlY29taW5nIHJlYWR5IGZvciByZWNl
aXZpbmcgU0lQSXMuKHRoaXMgZGVsYXkgd2FzIHJlbW92ZWQgYXMgcGFydCBvZiBjL3MgMjM3MjQg
YnkgVGltIERlZWdhbikKClNpZ25lZC1vZmYtYnk6IEdhbmcgV2VpIDxnYW5nLndlaUBpbnRlbC5j
b20+CkFja2VkLWJ5OiBLZWlyIEZyYXNlciA8a2VpckB4ZW4ub3JnPgoKZGlmZiAtciBkMWFlZmVl
NDNhZjEgeGVuL2FyY2gveDg2L3NtcGJvb3QuYwotLS0gYS94ZW4vYXJjaC94ODYvc21wYm9vdC5j
CVdlZCBEZWMgMjEgMTg6NTE6MzEgMjAxMSArMDgwMAorKysgYi94ZW4vYXJjaC94ODYvc21wYm9v
dC5jCVRodSBEZWMgMjIgMDA6MjY6NTIgMjAxMSArMDgwMApAQCAtNDIsNiArNDIsNyBAQAogI2lu
Y2x1ZGUgPGFzbS9tc3IuaD4KICNpbmNsdWRlIDxhc20vbXRyci5oPgogI2luY2x1ZGUgPGFzbS90
aW1lLmg+CisjaW5jbHVkZSA8YXNtL3Rib290Lmg+CiAjaW5jbHVkZSA8bWFjaF9hcGljLmg+CiAj
aW5jbHVkZSA8bWFjaF93YWtlY3B1Lmg+CiAjaW5jbHVkZSA8c21wYm9vdF9ob29rcy5oPgpAQCAt
NDYzLDYgKzQ2NCwxNCBAQAogICAgICAgICAgICAgc2VuZF9zdGF0dXMgPSBhcGljX3JlYWQoQVBJ
Q19JQ1IpICYgQVBJQ19JQ1JfQlVTWTsKICAgICAgICAgfSB3aGlsZSAoIHNlbmRfc3RhdHVzICYm
ICh0aW1lb3V0KysgPCAxMDAwKSApOwogICAgIH0KKyAgICBlbHNlIGlmICggdGJvb3RfaW5fbWVh
c3VyZWRfZW52KCkgKQorICAgIHsKKyAgICAgICAgLyoKKyAgICAgICAgICogZ2l2ZSBBUCB0aW1l
IHRvIGhhbmRsZSBJTklUIGJlZm9yZSByZWFkeSB0byByZWNlaXZlIFNJUElzCisgICAgICAgICAq
IG90aGVyd2lzZSBTSVBJcyBtYXkgYmUgc2tpcHBlZCBhbmQgQVAgd2lsbCBmYWlsIHRvIHVwCisg
ICAgICAgICAqLworICAgICAgICB1ZGVsYXkoMTApOworICAgIH0KIAogICAgIC8qCiAgICAgICog
U2hvdWxkIHdlIHNlbmQgU1RBUlRVUCBJUElzID8K

--_002_F26D193E20BBDC42A43B611D1BDEDE7135CEEEAEB6shsmsx502ccrc_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--_002_F26D193E20BBDC42A43B611D1BDEDE7135CEEEAEB6shsmsx502ccrc_--


From xen-devel-bounces@lists.xensource.com Wed Dec 21 16:55:08 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 16:55:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdPRE-0002S2-T2; Wed, 21 Dec 2011 16:54:44 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RdPRD-0002Rx-M4
	for xen-devel@lists.xensource.com; Wed, 21 Dec 2011 16:54:43 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1324486477!868581!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzcyNA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20630 invoked from network); 21 Dec 2011 16:54:37 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Dec 2011 16:54:37 -0000
X-IronPort-AV: E=Sophos;i="4.71,389,1320624000"; 
   d="scan'208";a="9615859"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Dec 2011 16:54:07 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 21 Dec 2011 16:54:07 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Muhammed Aydin <maydin.work@gmail.com>
Date: Wed, 21 Dec 2011 16:54:06 +0000
In-Reply-To: <CALF+9DEP5-Tb9NTzzwFF8WiWMmGQ2mTJ7vdp+adde0tYejRgGQ@mail.gmail.com>
References: <CALF+9DFCeYu2E1xBuHOW4n_7J9kz0H4Ngv1BY_Rn8d-SwDb3VA@mail.gmail.com>
	<1324475220.7877.32.camel@zakaz.uk.xensource.com>
	<CALF+9DEP5-Tb9NTzzwFF8WiWMmGQ2mTJ7vdp+adde0tYejRgGQ@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1324486446.7877.46.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Xen interfaces / hooks
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2011-12-21 at 16:40 +0000, Muhammed Aydin wrote:
> Hi Ian,
> 
> Thanks for the response.
> 
> > Perhaps if you explain your actual end goal you can be better
> advised.
> 
> What we are planning to do is to insert some code which can
> automatically utilise some instructions from forensics investigation
> tools (such as a command line tools like Sleuthkit), and to do this
> automatically upon starting up and shutdown / suspension of a virtual
> machine running on the Xen hypervisor in order to aid forensic
> investigations. Nothing complicated being added but we need to know
> exactly where we would need to put these commands.
> 
> My understanding is that because this would be performed on the domain
> U guest operating systems this change would need to be at the
> hypervisor level rather than the dom 0. Could you advise on how to go
> about this please? What I have been looking for is anything which
> could help me to do this to Xen, such as a tutorial or a guide, and
> couldn't find anything. 

Without knowing the precise details for "some instructions from
forensics investigation tools" I can't say for sure but this sounds on
the face of it like something which can be done from dom0 by using the
usual privileged operations to examine guest state.

Perhaps the "xenaccess" library (now apparently called LibVMI) will help
you to achieve your goals. I believe this uses the Memory Access API
added in Xen 4.1 although I'm not personally familiar with the
specifics.

There are no hooks for doing anything on domain startup/shutdown/suspend
but the generic functionality of running something on these events seems
like a plausibly useful generic addition to the xl toolstack (see
tools/libxl).

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 21 16:55:08 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 16:55:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdPRE-0002S2-T2; Wed, 21 Dec 2011 16:54:44 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RdPRD-0002Rx-M4
	for xen-devel@lists.xensource.com; Wed, 21 Dec 2011 16:54:43 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1324486477!868581!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzcyNA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20630 invoked from network); 21 Dec 2011 16:54:37 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Dec 2011 16:54:37 -0000
X-IronPort-AV: E=Sophos;i="4.71,389,1320624000"; 
   d="scan'208";a="9615859"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Dec 2011 16:54:07 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 21 Dec 2011 16:54:07 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Muhammed Aydin <maydin.work@gmail.com>
Date: Wed, 21 Dec 2011 16:54:06 +0000
In-Reply-To: <CALF+9DEP5-Tb9NTzzwFF8WiWMmGQ2mTJ7vdp+adde0tYejRgGQ@mail.gmail.com>
References: <CALF+9DFCeYu2E1xBuHOW4n_7J9kz0H4Ngv1BY_Rn8d-SwDb3VA@mail.gmail.com>
	<1324475220.7877.32.camel@zakaz.uk.xensource.com>
	<CALF+9DEP5-Tb9NTzzwFF8WiWMmGQ2mTJ7vdp+adde0tYejRgGQ@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1324486446.7877.46.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Xen interfaces / hooks
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2011-12-21 at 16:40 +0000, Muhammed Aydin wrote:
> Hi Ian,
> 
> Thanks for the response.
> 
> > Perhaps if you explain your actual end goal you can be better
> advised.
> 
> What we are planning to do is to insert some code which can
> automatically utilise some instructions from forensics investigation
> tools (such as a command line tools like Sleuthkit), and to do this
> automatically upon starting up and shutdown / suspension of a virtual
> machine running on the Xen hypervisor in order to aid forensic
> investigations. Nothing complicated being added but we need to know
> exactly where we would need to put these commands.
> 
> My understanding is that because this would be performed on the domain
> U guest operating systems this change would need to be at the
> hypervisor level rather than the dom 0. Could you advise on how to go
> about this please? What I have been looking for is anything which
> could help me to do this to Xen, such as a tutorial or a guide, and
> couldn't find anything. 

Without knowing the precise details for "some instructions from
forensics investigation tools" I can't say for sure but this sounds on
the face of it like something which can be done from dom0 by using the
usual privileged operations to examine guest state.

Perhaps the "xenaccess" library (now apparently called LibVMI) will help
you to achieve your goals. I believe this uses the Memory Access API
added in Xen 4.1 although I'm not personally familiar with the
specifics.

There are no hooks for doing anything on domain startup/shutdown/suspend
but the generic functionality of running something on these events seems
like a plausibly useful generic addition to the xl toolstack (see
tools/libxl).

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 21 17:06:18 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 17:06:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdPbx-0002hY-2L; Wed, 21 Dec 2011 17:05:49 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RdPbu-0002h6-RP
	for xen-devel@lists.xensource.com; Wed, 21 Dec 2011 17:05:47 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-9.tower-27.messagelabs.com!1324487105!57619920!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15762 invoked from network); 21 Dec 2011 17:05:06 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-9.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Dec 2011 17:05:06 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RdPbn-000KZZ-LW; Wed, 21 Dec 2011 17:05:39 +0000
Date: Wed, 21 Dec 2011 17:05:39 +0000
From: Tim Deegan <tim@xen.org>
To: "Wei, Gang" <gang.wei@intel.com>
Message-ID: <20111221170539.GA72385@ocelot.phlegethon.org>
References: <F26D193E20BBDC42A43B611D1BDEDE7135CEEEAE56@shsmsx502.ccr.corp.intel.com>
	<CB177C28.365E3%keir@xen.org>
	<F26D193E20BBDC42A43B611D1BDEDE7135CEEEAE63@shsmsx502.ccr.corp.intel.com>
	<F26D193E20BBDC42A43B611D1BDEDE7135CEEEAE65@shsmsx502.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <F26D193E20BBDC42A43B611D1BDEDE7135CEEEAE65@shsmsx502.ccr.corp.intel.com>
User-Agent: Mutt/1.4.2.1i
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	"Tim Deegan \(3P\)" <Tim.Deegan@citrix.com>, "Cihula,
	Joseph" <joseph.cihula@intel.com>,
	"tboot-devel@lists.sourceforge.net" <tboot-devel@lists.sourceforge.net>,
	Jan Beulich <jbeulich@suse.com>
Subject: Re: [Xen-devel] [patch] x86: Add a delay between INIT & SIPIs for
	AP bring-up in X2APIC case
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 12:29 +0000 on 21 Dec (1324470582), Wei, Gang wrote:
> Without this delay, Xen could not bring APs up while working with
> TXT/tboot, because tboot need some time in APs to handle INIT before
> becoming ready for receiving SIPIs. (this delay was removed as part of
> c/s 23724 by Tim Deegan)

It was removed because I was seeing the opposite problem -- if there was
a delay, the AP did not come up.  Unfortunately I don;'t have sucah a
machine available any more, so I can't check whether this breaks boot
there. =


Is this something that can be fixed in tboot?  If not, than this patch
is OK, provided it gets a code comment explaining _why_ tboot needs the
delay. =


Cheers,

Tim.

> diff -r d1aefee43af1 xen/arch/x86/smpboot.c
> --- a/xen/arch/x86/smpboot.c    Wed Dec 21 18:51:31 2011 +0800
> +++ b/xen/arch/x86/smpboot.c    Wed Dec 21 20:26:39 2011 +0800
> @@ -42,6 +42,7 @@
>  #include <asm/msr.h>
>  #include <asm/mtrr.h>
>  #include <asm/time.h>
> +#include <asm/tboot.h>
>  #include <mach_apic.h>
>  #include <mach_wakecpu.h>
>  #include <smpboot_hooks.h>
> @@ -463,6 +464,10 @@ static int wakeup_secondary_cpu(int phys
>              send_status =3D apic_read(APIC_ICR) & APIC_ICR_BUSY;
>          } while ( send_status && (timeout++ < 1000) );
>      }
> +    else if ( tboot_in_measured_env() )
> +    {
> +        udelay(10);
> +    }
> =

>      /*
>       * Should we send STARTUP IPIs ?
> =

> Jimmy
> =

> =

> > -----Original Message-----
> > From: Wei, Gang
> > Sent: Wednesday, December 21, 2011 8:18 PM
> > To: Keir Fraser; xen-devel@lists.xensource.com
> > Cc: tboot-devel@lists.sourceforge.net; Jan Beulich; Tim Deegan; Cihula,
> > Joseph; Wei, Gang
> > Subject: RE: [patch] x86: Add a delay between INIT & SIPIs for AP bring=
-up in
> > X2APIC case
> > =

> > Keir Fraser wrote on=A02011-12-21:
> > > On 21/12/2011 11:22, "Wei, Gang" <gang.wei@intel.com> wrote:
> > >
> > >> Without this delay, Xen could not bring APs up while working with
> > >> TXT/tboot, because tboot need some time in APs to handle INIT before
> > >> becoming ready for receiving SIPIs. (this delay was removed as part
> > >> of c/s 23724 by Tim Deegan)
> > >
> > > Of course Tim will need to review this himself, but a mdelay() right
> > > here, only on the x2apic path just looks bizarre and fragile.
> > >
> > > Could we make the !x2apic_enabled conditionals that Tim added be
> > > !(x2apic_enabled || tboot_in_measured_env()) instead? At least that is
> > > somewhat self-documenting and clearly only affects tboot!
> > =

> > Does below patch make more sense?
> > =

> > diff -r d1aefee43af1 xen/arch/x86/smpboot.c
> > --- a/xen/arch/x86/smpboot.c    Wed Dec 21 18:51:31 2011 +0800
> > +++ b/xen/arch/x86/smpboot.c    Wed Dec 21 19:08:57 2011 +0800
> > @@ -463,6 +463,10 @@ static int wakeup_secondary_cpu(int phys
> >              send_status =3D apic_read(APIC_ICR) & APIC_ICR_BUSY;
> >          } while ( send_status && (timeout++ < 1000) );
> >      }
> > +    else if ( tboot_in_measured_env() )
> > +    {
> > +        udelay(10);
> > +    }
> > =

> >      /*
> >       * Should we send STARTUP IPIs ?
> > =

> > Jimmy

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 21 17:06:18 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 17:06:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdPbx-0002hY-2L; Wed, 21 Dec 2011 17:05:49 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RdPbu-0002h6-RP
	for xen-devel@lists.xensource.com; Wed, 21 Dec 2011 17:05:47 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-9.tower-27.messagelabs.com!1324487105!57619920!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15762 invoked from network); 21 Dec 2011 17:05:06 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-9.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Dec 2011 17:05:06 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RdPbn-000KZZ-LW; Wed, 21 Dec 2011 17:05:39 +0000
Date: Wed, 21 Dec 2011 17:05:39 +0000
From: Tim Deegan <tim@xen.org>
To: "Wei, Gang" <gang.wei@intel.com>
Message-ID: <20111221170539.GA72385@ocelot.phlegethon.org>
References: <F26D193E20BBDC42A43B611D1BDEDE7135CEEEAE56@shsmsx502.ccr.corp.intel.com>
	<CB177C28.365E3%keir@xen.org>
	<F26D193E20BBDC42A43B611D1BDEDE7135CEEEAE63@shsmsx502.ccr.corp.intel.com>
	<F26D193E20BBDC42A43B611D1BDEDE7135CEEEAE65@shsmsx502.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <F26D193E20BBDC42A43B611D1BDEDE7135CEEEAE65@shsmsx502.ccr.corp.intel.com>
User-Agent: Mutt/1.4.2.1i
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	"Tim Deegan \(3P\)" <Tim.Deegan@citrix.com>, "Cihula,
	Joseph" <joseph.cihula@intel.com>,
	"tboot-devel@lists.sourceforge.net" <tboot-devel@lists.sourceforge.net>,
	Jan Beulich <jbeulich@suse.com>
Subject: Re: [Xen-devel] [patch] x86: Add a delay between INIT & SIPIs for
	AP bring-up in X2APIC case
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 12:29 +0000 on 21 Dec (1324470582), Wei, Gang wrote:
> Without this delay, Xen could not bring APs up while working with
> TXT/tboot, because tboot need some time in APs to handle INIT before
> becoming ready for receiving SIPIs. (this delay was removed as part of
> c/s 23724 by Tim Deegan)

It was removed because I was seeing the opposite problem -- if there was
a delay, the AP did not come up.  Unfortunately I don;'t have sucah a
machine available any more, so I can't check whether this breaks boot
there. =


Is this something that can be fixed in tboot?  If not, than this patch
is OK, provided it gets a code comment explaining _why_ tboot needs the
delay. =


Cheers,

Tim.

> diff -r d1aefee43af1 xen/arch/x86/smpboot.c
> --- a/xen/arch/x86/smpboot.c    Wed Dec 21 18:51:31 2011 +0800
> +++ b/xen/arch/x86/smpboot.c    Wed Dec 21 20:26:39 2011 +0800
> @@ -42,6 +42,7 @@
>  #include <asm/msr.h>
>  #include <asm/mtrr.h>
>  #include <asm/time.h>
> +#include <asm/tboot.h>
>  #include <mach_apic.h>
>  #include <mach_wakecpu.h>
>  #include <smpboot_hooks.h>
> @@ -463,6 +464,10 @@ static int wakeup_secondary_cpu(int phys
>              send_status =3D apic_read(APIC_ICR) & APIC_ICR_BUSY;
>          } while ( send_status && (timeout++ < 1000) );
>      }
> +    else if ( tboot_in_measured_env() )
> +    {
> +        udelay(10);
> +    }
> =

>      /*
>       * Should we send STARTUP IPIs ?
> =

> Jimmy
> =

> =

> > -----Original Message-----
> > From: Wei, Gang
> > Sent: Wednesday, December 21, 2011 8:18 PM
> > To: Keir Fraser; xen-devel@lists.xensource.com
> > Cc: tboot-devel@lists.sourceforge.net; Jan Beulich; Tim Deegan; Cihula,
> > Joseph; Wei, Gang
> > Subject: RE: [patch] x86: Add a delay between INIT & SIPIs for AP bring=
-up in
> > X2APIC case
> > =

> > Keir Fraser wrote on=A02011-12-21:
> > > On 21/12/2011 11:22, "Wei, Gang" <gang.wei@intel.com> wrote:
> > >
> > >> Without this delay, Xen could not bring APs up while working with
> > >> TXT/tboot, because tboot need some time in APs to handle INIT before
> > >> becoming ready for receiving SIPIs. (this delay was removed as part
> > >> of c/s 23724 by Tim Deegan)
> > >
> > > Of course Tim will need to review this himself, but a mdelay() right
> > > here, only on the x2apic path just looks bizarre and fragile.
> > >
> > > Could we make the !x2apic_enabled conditionals that Tim added be
> > > !(x2apic_enabled || tboot_in_measured_env()) instead? At least that is
> > > somewhat self-documenting and clearly only affects tboot!
> > =

> > Does below patch make more sense?
> > =

> > diff -r d1aefee43af1 xen/arch/x86/smpboot.c
> > --- a/xen/arch/x86/smpboot.c    Wed Dec 21 18:51:31 2011 +0800
> > +++ b/xen/arch/x86/smpboot.c    Wed Dec 21 19:08:57 2011 +0800
> > @@ -463,6 +463,10 @@ static int wakeup_secondary_cpu(int phys
> >              send_status =3D apic_read(APIC_ICR) & APIC_ICR_BUSY;
> >          } while ( send_status && (timeout++ < 1000) );
> >      }
> > +    else if ( tboot_in_measured_env() )
> > +    {
> > +        udelay(10);
> > +    }
> > =

> >      /*
> >       * Should we send STARTUP IPIs ?
> > =

> > Jimmy

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 21 17:41:59 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 17:41:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdQAU-0003KK-KS; Wed, 21 Dec 2011 17:41:30 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RdQAS-0003KF-Py
	for xen-devel@lists.xensource.com; Wed, 21 Dec 2011 17:41:29 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1324489281!8190767!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ1MzUwMw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20456 invoked from network); 21 Dec 2011 17:41:22 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-2.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Dec 2011 17:41:22 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pBLHeLCK004169
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 21 Dec 2011 17:40:22 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pBLHeJ3Z004430
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 21 Dec 2011 17:40:19 GMT
Received: from abhmt101.oracle.com (abhmt101.oracle.com [141.146.116.53])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pBLHeGgW004492; Wed, 21 Dec 2011 11:40:16 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 21 Dec 2011 09:40:15 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 225A2401B2; Wed, 21 Dec 2011 12:39:15 -0500 (EST)
Date: Wed, 21 Dec 2011 12:39:15 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jan Beulich <JBeulich@suse.com>, dmitry.torokhov@gmail.com,
	axboe@kernel.dk, FlorianSchandinat@gmx.de, ian.campbell@citrix.com,
	davem@davemloft.net, netdev@vger.kernel.org
Message-ID: <20111221173915.GA15377@phenom.dumpdata.com>
References: <4EF210E7020000780006965E@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4EF210E7020000780006965E@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090205.4EF21A08.0110,ss=1,re=-2.300,fgs=0
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>,
	Jeremy Fitzhardinge <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH] Xen: consolidate and simplify struct
 xenbus_driver instantiation
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Dec 21, 2011 at 04:01:27PM +0000, Jan Beulich wrote:
> The 'name', 'owner', and 'mod_name' members are redundant with the
> identically named fields in the 'driver' sub-structure. Rather than
> switching each instance to specify these fields explicitly, introduce
> a macro to simplify this.
> 
> Eliminate further redundancy by allowing the drvname argument to
> DEFINE_XENBUS_DRIVER() to be blank (in which case the first entry from
> the ID table will be used for .driver.name).
> 
> Also eliminate the questionable xenbus_register_{back,front}end()
> wrappers - their sole remaining purpose was the checking of the
> 'owner' field, proper setting of which shouldn't be an issue anymore
> when the macro gets used.

Looks good, except:

a)  It also needs four ACKs from:

 1) block for block maintainer (Jens Axboe <axboe@kernel.dk> )
 2) kbdinput for input maintainer (Dmitry Torokhov <dmitry.torokhov@gmail.com)
 3) fbfront for the video maintainer (FlorianSchandinat@gmx.de)
 4) network for the network maintainer (Ian Campbell <ian.campbell@citrix.com>, netdev@vger.kernel.org ,"David S. Miller" <davem@davemloft.net>)

CC-ing all of them.

b) this is changing it from xen-pciback to pciback:

> --- 3.2-rc6/drivers/xen/xen-pciback/xenbus.c
> +++ 3.2-rc6-struct-xenbus_driver/drivers/xen/xen-pciback/xenbus.c
> @@ -707,19 +707,16 @@ static int xen_pcibk_xenbus_remove(struc
>  	return 0;
>  }
>  
> -static const struct xenbus_device_id xenpci_ids[] = {
> +static const struct xenbus_device_id xen_pcibk_ids[] = {
>  	{"pci"},
>  	{""},
>  };
>  
> -static struct xenbus_driver xenbus_xen_pcibk_driver = {
> -	.name			= DRV_NAME,
> -	.owner			= THIS_MODULE,
> -	.ids			= xenpci_ids,
> +static DEFINE_XENBUS_DRIVER(xen_pcibk, "pciback",
                                          ^^^^^^^^^
I think that should be "xen-pciback" or just DRV_NAME ?

>  	.probe			= xen_pcibk_xenbus_probe,
>  	.remove			= xen_pcibk_xenbus_remove,
>  	.otherend_changed	= xen_pcibk_frontend_changed,
> -};
> +);

Otherwise all the other changes look OK to me.

Here is the unchanged version of the patch for the other maintainers.

Xen: consolidate and simplify struct xenbus_driver instantiation

The 'name', 'owner', and 'mod_name' members are redundant with the
identically named fields in the 'driver' sub-structure. Rather than
switching each instance to specify these fields explicitly, introduce
a macro to simplify this.

Eliminate further redundancy by allowing the drvname argument to
DEFINE_XENBUS_DRIVER() to be blank (in which case the first entry from
the ID table will be used for .driver.name).

Also eliminate the questionable xenbus_register_{back,front}end()
wrappers - their sole remaining purpose was the checking of the
'owner' field, proper setting of which shouldn't be an issue anymore
when the macro gets used.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

---
 drivers/block/xen-blkback/xenbus.c         |    9 ++------
 drivers/block/xen-blkfront.c               |   11 +++-------
 drivers/input/misc/xen-kbdfront.c          |    7 +-----
 drivers/net/xen-netback/xenbus.c           |    9 ++------
 drivers/net/xen-netfront.c                 |    9 ++------
 drivers/pci/xen-pcifront.c                 |   11 +++-------
 drivers/video/xen-fbfront.c                |    9 ++------
 drivers/xen/xen-pciback/xenbus.c           |   13 ++++--------
 drivers/xen/xenbus/xenbus_probe.c          |    7 ------
 drivers/xen/xenbus/xenbus_probe.h          |    4 ---
 drivers/xen/xenbus/xenbus_probe_backend.c  |    8 ++-----
 drivers/xen/xenbus/xenbus_probe_frontend.c |    8 ++-----
 include/xen/xenbus.h                       |   31 ++++++++---------------------
 13 files changed, 44 insertions(+), 92 deletions(-)

--- 3.2-rc6/drivers/block/xen-blkback/xenbus.c
+++ 3.2-rc6-struct-xenbus_driver/drivers/block/xen-blkback/xenbus.c
@@ -787,17 +787,14 @@ static const struct xenbus_device_id xen
 };
 
 
-static struct xenbus_driver xen_blkbk = {
-	.name = "vbd",
-	.owner = THIS_MODULE,
-	.ids = xen_blkbk_ids,
+static DEFINE_XENBUS_DRIVER(xen_blkbk, ,
 	.probe = xen_blkbk_probe,
 	.remove = xen_blkbk_remove,
 	.otherend_changed = frontend_changed
-};
+);
 
 
 int xen_blkif_xenbus_init(void)
 {
-	return xenbus_register_backend(&xen_blkbk);
+	return xenbus_register_backend(&xen_blkbk_driver);
 }
--- 3.2-rc6/drivers/block/xen-blkfront.c
+++ 3.2-rc6-struct-xenbus_driver/drivers/block/xen-blkfront.c
@@ -1437,16 +1437,13 @@ static const struct xenbus_device_id blk
 	{ "" }
 };
 
-static struct xenbus_driver blkfront = {
-	.name = "vbd",
-	.owner = THIS_MODULE,
-	.ids = blkfront_ids,
+static DEFINE_XENBUS_DRIVER(blkfront, ,
 	.probe = blkfront_probe,
 	.remove = blkfront_remove,
 	.resume = blkfront_resume,
 	.otherend_changed = blkback_changed,
 	.is_ready = blkfront_is_ready,
-};
+);
 
 static int __init xlblk_init(void)
 {
@@ -1461,7 +1458,7 @@ static int __init xlblk_init(void)
 		return -ENODEV;
 	}
 
-	ret = xenbus_register_frontend(&blkfront);
+	ret = xenbus_register_frontend(&blkfront_driver);
 	if (ret) {
 		unregister_blkdev(XENVBD_MAJOR, DEV_NAME);
 		return ret;
@@ -1474,7 +1471,7 @@ module_init(xlblk_init);
 
 static void __exit xlblk_exit(void)
 {
-	return xenbus_unregister_driver(&blkfront);
+	return xenbus_unregister_driver(&blkfront_driver);
 }
 module_exit(xlblk_exit);
 
--- 3.2-rc6/drivers/input/misc/xen-kbdfront.c
+++ 3.2-rc6-struct-xenbus_driver/drivers/input/misc/xen-kbdfront.c
@@ -361,15 +361,12 @@ static const struct xenbus_device_id xen
 	{ "" }
 };
 
-static struct xenbus_driver xenkbd_driver = {
-	.name = "vkbd",
-	.owner = THIS_MODULE,
-	.ids = xenkbd_ids,
+static DEFINE_XENBUS_DRIVER(xenkbd, ,
 	.probe = xenkbd_probe,
 	.remove = xenkbd_remove,
 	.resume = xenkbd_resume,
 	.otherend_changed = xenkbd_backend_changed,
-};
+);
 
 static int __init xenkbd_init(void)
 {
--- 3.2-rc6/drivers/net/xen-netback/xenbus.c
+++ 3.2-rc6-struct-xenbus_driver/drivers/net/xen-netback/xenbus.c
@@ -474,17 +474,14 @@ static const struct xenbus_device_id net
 };
 
 
-static struct xenbus_driver netback = {
-	.name = "vif",
-	.owner = THIS_MODULE,
-	.ids = netback_ids,
+static DEFINE_XENBUS_DRIVER(netback, ,
 	.probe = netback_probe,
 	.remove = netback_remove,
 	.uevent = netback_uevent,
 	.otherend_changed = frontend_changed,
-};
+);
 
 int xenvif_xenbus_init(void)
 {
-	return xenbus_register_backend(&netback);
+	return xenbus_register_backend(&netback_driver);
 }
--- 3.2-rc6/drivers/net/xen-netfront.c
+++ 3.2-rc6-struct-xenbus_driver/drivers/net/xen-netfront.c
@@ -1910,7 +1910,7 @@ static void xennet_sysfs_delif(struct ne
 
 #endif /* CONFIG_SYSFS */
 
-static struct xenbus_device_id netfront_ids[] = {
+static const struct xenbus_device_id netfront_ids[] = {
 	{ "vif" },
 	{ "" }
 };
@@ -1937,15 +1937,12 @@ static int __devexit xennet_remove(struc
 	return 0;
 }
 
-static struct xenbus_driver netfront_driver = {
-	.name = "vif",
-	.owner = THIS_MODULE,
-	.ids = netfront_ids,
+static DEFINE_XENBUS_DRIVER(netfront, ,
 	.probe = netfront_probe,
 	.remove = __devexit_p(xennet_remove),
 	.resume = netfront_resume,
 	.otherend_changed = netback_changed,
-};
+);
 
 static int __init netif_init(void)
 {
--- 3.2-rc6/drivers/pci/xen-pcifront.c
+++ 3.2-rc6-struct-xenbus_driver/drivers/pci/xen-pcifront.c
@@ -1126,14 +1126,11 @@ static const struct xenbus_device_id xen
 	{""},
 };
 
-static struct xenbus_driver xenbus_pcifront_driver = {
-	.name			= "pcifront",
-	.owner			= THIS_MODULE,
-	.ids			= xenpci_ids,
+static DEFINE_XENBUS_DRIVER(xenpci, "pcifront",
 	.probe			= pcifront_xenbus_probe,
 	.remove			= pcifront_xenbus_remove,
 	.otherend_changed	= pcifront_backend_changed,
-};
+);
 
 static int __init pcifront_init(void)
 {
@@ -1142,12 +1139,12 @@ static int __init pcifront_init(void)
 
 	pci_frontend_registrar(1 /* enable */);
 
-	return xenbus_register_frontend(&xenbus_pcifront_driver);
+	return xenbus_register_frontend(&xenpci_driver);
 }
 
 static void __exit pcifront_cleanup(void)
 {
-	xenbus_unregister_driver(&xenbus_pcifront_driver);
+	xenbus_unregister_driver(&xenpci_driver);
 	pci_frontend_registrar(0 /* disable */);
 }
 module_init(pcifront_init);
--- 3.2-rc6/drivers/video/xen-fbfront.c
+++ 3.2-rc6-struct-xenbus_driver/drivers/video/xen-fbfront.c
@@ -671,20 +671,17 @@ InitWait:
 	}
 }
 
-static struct xenbus_device_id xenfb_ids[] = {
+static const struct xenbus_device_id xenfb_ids[] = {
 	{ "vfb" },
 	{ "" }
 };
 
-static struct xenbus_driver xenfb_driver = {
-	.name = "vfb",
-	.owner = THIS_MODULE,
-	.ids = xenfb_ids,
+static DEFINE_XENBUS_DRIVER(xenfb, ,
 	.probe = xenfb_probe,
 	.remove = xenfb_remove,
 	.resume = xenfb_resume,
 	.otherend_changed = xenfb_backend_changed,
-};
+);
 
 static int __init xenfb_init(void)
 {
--- 3.2-rc6/drivers/xen/xen-pciback/xenbus.c
+++ 3.2-rc6-struct-xenbus_driver/drivers/xen/xen-pciback/xenbus.c
@@ -707,19 +707,16 @@ static int xen_pcibk_xenbus_remove(struc
 	return 0;
 }
 
-static const struct xenbus_device_id xenpci_ids[] = {
+static const struct xenbus_device_id xen_pcibk_ids[] = {
 	{"pci"},
 	{""},
 };
 
-static struct xenbus_driver xenbus_xen_pcibk_driver = {
-	.name			= DRV_NAME,
-	.owner			= THIS_MODULE,
-	.ids			= xenpci_ids,
+static DEFINE_XENBUS_DRIVER(xen_pcibk, "pciback",
 	.probe			= xen_pcibk_xenbus_probe,
 	.remove			= xen_pcibk_xenbus_remove,
 	.otherend_changed	= xen_pcibk_frontend_changed,
-};
+);
 
 const struct xen_pcibk_backend *__read_mostly xen_pcibk_backend;
 
@@ -735,11 +732,11 @@ int __init xen_pcibk_xenbus_register(voi
 	if (passthrough)
 		xen_pcibk_backend = &xen_pcibk_passthrough_backend;
 	pr_info(DRV_NAME ": backend is %s\n", xen_pcibk_backend->name);
-	return xenbus_register_backend(&xenbus_xen_pcibk_driver);
+	return xenbus_register_backend(&xen_pcibk_driver);
 }
 
 void __exit xen_pcibk_xenbus_unregister(void)
 {
 	destroy_workqueue(xen_pcibk_wq);
-	xenbus_unregister_driver(&xenbus_xen_pcibk_driver);
+	xenbus_unregister_driver(&xen_pcibk_driver);
 }
--- 3.2-rc6/drivers/xen/xenbus/xenbus_probe.c
+++ 3.2-rc6-struct-xenbus_driver/drivers/xen/xenbus/xenbus_probe.c
@@ -291,14 +291,9 @@ void xenbus_dev_shutdown(struct device *
 EXPORT_SYMBOL_GPL(xenbus_dev_shutdown);
 
 int xenbus_register_driver_common(struct xenbus_driver *drv,
-				  struct xen_bus_type *bus,
-				  struct module *owner,
-				  const char *mod_name)
+				  struct xen_bus_type *bus)
 {
-	drv->driver.name = drv->name;
 	drv->driver.bus = &bus->bus;
-	drv->driver.owner = owner;
-	drv->driver.mod_name = mod_name;
 
 	return driver_register(&drv->driver);
 }
--- 3.2-rc6/drivers/xen/xenbus/xenbus_probe.h
+++ 3.2-rc6-struct-xenbus_driver/drivers/xen/xenbus/xenbus_probe.h
@@ -53,9 +53,7 @@ extern int xenbus_match(struct device *_
 extern int xenbus_dev_probe(struct device *_dev);
 extern int xenbus_dev_remove(struct device *_dev);
 extern int xenbus_register_driver_common(struct xenbus_driver *drv,
-					 struct xen_bus_type *bus,
-					 struct module *owner,
-					 const char *mod_name);
+					 struct xen_bus_type *bus);
 extern int xenbus_probe_node(struct xen_bus_type *bus,
 			     const char *type,
 			     const char *nodename);
--- 3.2-rc6/drivers/xen/xenbus/xenbus_probe_backend.c
+++ 3.2-rc6-struct-xenbus_driver/drivers/xen/xenbus/xenbus_probe_backend.c
@@ -232,15 +232,13 @@ int xenbus_dev_is_online(struct xenbus_d
 }
 EXPORT_SYMBOL_GPL(xenbus_dev_is_online);
 
-int __xenbus_register_backend(struct xenbus_driver *drv,
-			      struct module *owner, const char *mod_name)
+int xenbus_register_backend(struct xenbus_driver *drv)
 {
 	drv->read_otherend_details = read_frontend_details;
 
-	return xenbus_register_driver_common(drv, &xenbus_backend,
-					     owner, mod_name);
+	return xenbus_register_driver_common(drv, &xenbus_backend);
 }
-EXPORT_SYMBOL_GPL(__xenbus_register_backend);
+EXPORT_SYMBOL_GPL(xenbus_register_backend);
 
 static int backend_probe_and_watch(struct notifier_block *notifier,
 				   unsigned long event,
--- 3.2-rc6/drivers/xen/xenbus/xenbus_probe_frontend.c
+++ 3.2-rc6-struct-xenbus_driver/drivers/xen/xenbus/xenbus_probe_frontend.c
@@ -230,15 +230,13 @@ static void wait_for_devices(struct xenb
 			 print_device_status);
 }
 
-int __xenbus_register_frontend(struct xenbus_driver *drv,
-			       struct module *owner, const char *mod_name)
+int xenbus_register_frontend(struct xenbus_driver *drv)
 {
 	int ret;
 
 	drv->read_otherend_details = read_backend_details;
 
-	ret = xenbus_register_driver_common(drv, &xenbus_frontend,
-					    owner, mod_name);
+	ret = xenbus_register_driver_common(drv, &xenbus_frontend);
 	if (ret)
 		return ret;
 
@@ -247,7 +245,7 @@ int __xenbus_register_frontend(struct xe
 
 	return 0;
 }
-EXPORT_SYMBOL_GPL(__xenbus_register_frontend);
+EXPORT_SYMBOL_GPL(xenbus_register_frontend);
 
 static DECLARE_WAIT_QUEUE_HEAD(backend_state_wq);
 static int backend_state;
--- 3.2-rc6/include/xen/xenbus.h
+++ 3.2-rc6-struct-xenbus_driver/include/xen/xenbus.h
@@ -85,8 +85,6 @@ struct xenbus_device_id
 
 /* A xenbus driver. */
 struct xenbus_driver {
-	char *name;
-	struct module *owner;
 	const struct xenbus_device_id *ids;
 	int (*probe)(struct xenbus_device *dev,
 		     const struct xenbus_device_id *id);
@@ -101,31 +99,20 @@ struct xenbus_driver {
 	int (*is_ready)(struct xenbus_device *dev);
 };
 
-static inline struct xenbus_driver *to_xenbus_driver(struct device_driver *drv)
-{
-	return container_of(drv, struct xenbus_driver, driver);
+#define DEFINE_XENBUS_DRIVER(var, drvname, methods...)		\
+struct xenbus_driver var ## _driver = {				\
+	.driver.name = drvname + 0 ?: var ## _ids->devicetype,	\
+	.driver.owner = THIS_MODULE,				\
+	.ids = var ## _ids, ## methods				\
 }
 
-int __must_check __xenbus_register_frontend(struct xenbus_driver *drv,
-					    struct module *owner,
-					    const char *mod_name);
-
-static inline int __must_check
-xenbus_register_frontend(struct xenbus_driver *drv)
+static inline struct xenbus_driver *to_xenbus_driver(struct device_driver *drv)
 {
-	WARN_ON(drv->owner != THIS_MODULE);
-	return __xenbus_register_frontend(drv, THIS_MODULE, KBUILD_MODNAME);
+	return container_of(drv, struct xenbus_driver, driver);
 }
 
-int __must_check __xenbus_register_backend(struct xenbus_driver *drv,
-					   struct module *owner,
-					   const char *mod_name);
-static inline int __must_check
-xenbus_register_backend(struct xenbus_driver *drv)
-{
-	WARN_ON(drv->owner != THIS_MODULE);
-	return __xenbus_register_backend(drv, THIS_MODULE, KBUILD_MODNAME);
-}
+int __must_check xenbus_register_frontend(struct xenbus_driver *);
+int __must_check xenbus_register_backend(struct xenbus_driver *);
 
 void xenbus_unregister_driver(struct xenbus_driver *drv);
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 21 17:41:59 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 17:41:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdQAU-0003KK-KS; Wed, 21 Dec 2011 17:41:30 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RdQAS-0003KF-Py
	for xen-devel@lists.xensource.com; Wed, 21 Dec 2011 17:41:29 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1324489281!8190767!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ1MzUwMw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20456 invoked from network); 21 Dec 2011 17:41:22 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-2.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Dec 2011 17:41:22 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pBLHeLCK004169
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 21 Dec 2011 17:40:22 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pBLHeJ3Z004430
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 21 Dec 2011 17:40:19 GMT
Received: from abhmt101.oracle.com (abhmt101.oracle.com [141.146.116.53])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pBLHeGgW004492; Wed, 21 Dec 2011 11:40:16 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 21 Dec 2011 09:40:15 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 225A2401B2; Wed, 21 Dec 2011 12:39:15 -0500 (EST)
Date: Wed, 21 Dec 2011 12:39:15 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jan Beulich <JBeulich@suse.com>, dmitry.torokhov@gmail.com,
	axboe@kernel.dk, FlorianSchandinat@gmx.de, ian.campbell@citrix.com,
	davem@davemloft.net, netdev@vger.kernel.org
Message-ID: <20111221173915.GA15377@phenom.dumpdata.com>
References: <4EF210E7020000780006965E@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4EF210E7020000780006965E@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090205.4EF21A08.0110,ss=1,re=-2.300,fgs=0
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>,
	Jeremy Fitzhardinge <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH] Xen: consolidate and simplify struct
 xenbus_driver instantiation
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Dec 21, 2011 at 04:01:27PM +0000, Jan Beulich wrote:
> The 'name', 'owner', and 'mod_name' members are redundant with the
> identically named fields in the 'driver' sub-structure. Rather than
> switching each instance to specify these fields explicitly, introduce
> a macro to simplify this.
> 
> Eliminate further redundancy by allowing the drvname argument to
> DEFINE_XENBUS_DRIVER() to be blank (in which case the first entry from
> the ID table will be used for .driver.name).
> 
> Also eliminate the questionable xenbus_register_{back,front}end()
> wrappers - their sole remaining purpose was the checking of the
> 'owner' field, proper setting of which shouldn't be an issue anymore
> when the macro gets used.

Looks good, except:

a)  It also needs four ACKs from:

 1) block for block maintainer (Jens Axboe <axboe@kernel.dk> )
 2) kbdinput for input maintainer (Dmitry Torokhov <dmitry.torokhov@gmail.com)
 3) fbfront for the video maintainer (FlorianSchandinat@gmx.de)
 4) network for the network maintainer (Ian Campbell <ian.campbell@citrix.com>, netdev@vger.kernel.org ,"David S. Miller" <davem@davemloft.net>)

CC-ing all of them.

b) this is changing it from xen-pciback to pciback:

> --- 3.2-rc6/drivers/xen/xen-pciback/xenbus.c
> +++ 3.2-rc6-struct-xenbus_driver/drivers/xen/xen-pciback/xenbus.c
> @@ -707,19 +707,16 @@ static int xen_pcibk_xenbus_remove(struc
>  	return 0;
>  }
>  
> -static const struct xenbus_device_id xenpci_ids[] = {
> +static const struct xenbus_device_id xen_pcibk_ids[] = {
>  	{"pci"},
>  	{""},
>  };
>  
> -static struct xenbus_driver xenbus_xen_pcibk_driver = {
> -	.name			= DRV_NAME,
> -	.owner			= THIS_MODULE,
> -	.ids			= xenpci_ids,
> +static DEFINE_XENBUS_DRIVER(xen_pcibk, "pciback",
                                          ^^^^^^^^^
I think that should be "xen-pciback" or just DRV_NAME ?

>  	.probe			= xen_pcibk_xenbus_probe,
>  	.remove			= xen_pcibk_xenbus_remove,
>  	.otherend_changed	= xen_pcibk_frontend_changed,
> -};
> +);

Otherwise all the other changes look OK to me.

Here is the unchanged version of the patch for the other maintainers.

Xen: consolidate and simplify struct xenbus_driver instantiation

The 'name', 'owner', and 'mod_name' members are redundant with the
identically named fields in the 'driver' sub-structure. Rather than
switching each instance to specify these fields explicitly, introduce
a macro to simplify this.

Eliminate further redundancy by allowing the drvname argument to
DEFINE_XENBUS_DRIVER() to be blank (in which case the first entry from
the ID table will be used for .driver.name).

Also eliminate the questionable xenbus_register_{back,front}end()
wrappers - their sole remaining purpose was the checking of the
'owner' field, proper setting of which shouldn't be an issue anymore
when the macro gets used.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

---
 drivers/block/xen-blkback/xenbus.c         |    9 ++------
 drivers/block/xen-blkfront.c               |   11 +++-------
 drivers/input/misc/xen-kbdfront.c          |    7 +-----
 drivers/net/xen-netback/xenbus.c           |    9 ++------
 drivers/net/xen-netfront.c                 |    9 ++------
 drivers/pci/xen-pcifront.c                 |   11 +++-------
 drivers/video/xen-fbfront.c                |    9 ++------
 drivers/xen/xen-pciback/xenbus.c           |   13 ++++--------
 drivers/xen/xenbus/xenbus_probe.c          |    7 ------
 drivers/xen/xenbus/xenbus_probe.h          |    4 ---
 drivers/xen/xenbus/xenbus_probe_backend.c  |    8 ++-----
 drivers/xen/xenbus/xenbus_probe_frontend.c |    8 ++-----
 include/xen/xenbus.h                       |   31 ++++++++---------------------
 13 files changed, 44 insertions(+), 92 deletions(-)

--- 3.2-rc6/drivers/block/xen-blkback/xenbus.c
+++ 3.2-rc6-struct-xenbus_driver/drivers/block/xen-blkback/xenbus.c
@@ -787,17 +787,14 @@ static const struct xenbus_device_id xen
 };
 
 
-static struct xenbus_driver xen_blkbk = {
-	.name = "vbd",
-	.owner = THIS_MODULE,
-	.ids = xen_blkbk_ids,
+static DEFINE_XENBUS_DRIVER(xen_blkbk, ,
 	.probe = xen_blkbk_probe,
 	.remove = xen_blkbk_remove,
 	.otherend_changed = frontend_changed
-};
+);
 
 
 int xen_blkif_xenbus_init(void)
 {
-	return xenbus_register_backend(&xen_blkbk);
+	return xenbus_register_backend(&xen_blkbk_driver);
 }
--- 3.2-rc6/drivers/block/xen-blkfront.c
+++ 3.2-rc6-struct-xenbus_driver/drivers/block/xen-blkfront.c
@@ -1437,16 +1437,13 @@ static const struct xenbus_device_id blk
 	{ "" }
 };
 
-static struct xenbus_driver blkfront = {
-	.name = "vbd",
-	.owner = THIS_MODULE,
-	.ids = blkfront_ids,
+static DEFINE_XENBUS_DRIVER(blkfront, ,
 	.probe = blkfront_probe,
 	.remove = blkfront_remove,
 	.resume = blkfront_resume,
 	.otherend_changed = blkback_changed,
 	.is_ready = blkfront_is_ready,
-};
+);
 
 static int __init xlblk_init(void)
 {
@@ -1461,7 +1458,7 @@ static int __init xlblk_init(void)
 		return -ENODEV;
 	}
 
-	ret = xenbus_register_frontend(&blkfront);
+	ret = xenbus_register_frontend(&blkfront_driver);
 	if (ret) {
 		unregister_blkdev(XENVBD_MAJOR, DEV_NAME);
 		return ret;
@@ -1474,7 +1471,7 @@ module_init(xlblk_init);
 
 static void __exit xlblk_exit(void)
 {
-	return xenbus_unregister_driver(&blkfront);
+	return xenbus_unregister_driver(&blkfront_driver);
 }
 module_exit(xlblk_exit);
 
--- 3.2-rc6/drivers/input/misc/xen-kbdfront.c
+++ 3.2-rc6-struct-xenbus_driver/drivers/input/misc/xen-kbdfront.c
@@ -361,15 +361,12 @@ static const struct xenbus_device_id xen
 	{ "" }
 };
 
-static struct xenbus_driver xenkbd_driver = {
-	.name = "vkbd",
-	.owner = THIS_MODULE,
-	.ids = xenkbd_ids,
+static DEFINE_XENBUS_DRIVER(xenkbd, ,
 	.probe = xenkbd_probe,
 	.remove = xenkbd_remove,
 	.resume = xenkbd_resume,
 	.otherend_changed = xenkbd_backend_changed,
-};
+);
 
 static int __init xenkbd_init(void)
 {
--- 3.2-rc6/drivers/net/xen-netback/xenbus.c
+++ 3.2-rc6-struct-xenbus_driver/drivers/net/xen-netback/xenbus.c
@@ -474,17 +474,14 @@ static const struct xenbus_device_id net
 };
 
 
-static struct xenbus_driver netback = {
-	.name = "vif",
-	.owner = THIS_MODULE,
-	.ids = netback_ids,
+static DEFINE_XENBUS_DRIVER(netback, ,
 	.probe = netback_probe,
 	.remove = netback_remove,
 	.uevent = netback_uevent,
 	.otherend_changed = frontend_changed,
-};
+);
 
 int xenvif_xenbus_init(void)
 {
-	return xenbus_register_backend(&netback);
+	return xenbus_register_backend(&netback_driver);
 }
--- 3.2-rc6/drivers/net/xen-netfront.c
+++ 3.2-rc6-struct-xenbus_driver/drivers/net/xen-netfront.c
@@ -1910,7 +1910,7 @@ static void xennet_sysfs_delif(struct ne
 
 #endif /* CONFIG_SYSFS */
 
-static struct xenbus_device_id netfront_ids[] = {
+static const struct xenbus_device_id netfront_ids[] = {
 	{ "vif" },
 	{ "" }
 };
@@ -1937,15 +1937,12 @@ static int __devexit xennet_remove(struc
 	return 0;
 }
 
-static struct xenbus_driver netfront_driver = {
-	.name = "vif",
-	.owner = THIS_MODULE,
-	.ids = netfront_ids,
+static DEFINE_XENBUS_DRIVER(netfront, ,
 	.probe = netfront_probe,
 	.remove = __devexit_p(xennet_remove),
 	.resume = netfront_resume,
 	.otherend_changed = netback_changed,
-};
+);
 
 static int __init netif_init(void)
 {
--- 3.2-rc6/drivers/pci/xen-pcifront.c
+++ 3.2-rc6-struct-xenbus_driver/drivers/pci/xen-pcifront.c
@@ -1126,14 +1126,11 @@ static const struct xenbus_device_id xen
 	{""},
 };
 
-static struct xenbus_driver xenbus_pcifront_driver = {
-	.name			= "pcifront",
-	.owner			= THIS_MODULE,
-	.ids			= xenpci_ids,
+static DEFINE_XENBUS_DRIVER(xenpci, "pcifront",
 	.probe			= pcifront_xenbus_probe,
 	.remove			= pcifront_xenbus_remove,
 	.otherend_changed	= pcifront_backend_changed,
-};
+);
 
 static int __init pcifront_init(void)
 {
@@ -1142,12 +1139,12 @@ static int __init pcifront_init(void)
 
 	pci_frontend_registrar(1 /* enable */);
 
-	return xenbus_register_frontend(&xenbus_pcifront_driver);
+	return xenbus_register_frontend(&xenpci_driver);
 }
 
 static void __exit pcifront_cleanup(void)
 {
-	xenbus_unregister_driver(&xenbus_pcifront_driver);
+	xenbus_unregister_driver(&xenpci_driver);
 	pci_frontend_registrar(0 /* disable */);
 }
 module_init(pcifront_init);
--- 3.2-rc6/drivers/video/xen-fbfront.c
+++ 3.2-rc6-struct-xenbus_driver/drivers/video/xen-fbfront.c
@@ -671,20 +671,17 @@ InitWait:
 	}
 }
 
-static struct xenbus_device_id xenfb_ids[] = {
+static const struct xenbus_device_id xenfb_ids[] = {
 	{ "vfb" },
 	{ "" }
 };
 
-static struct xenbus_driver xenfb_driver = {
-	.name = "vfb",
-	.owner = THIS_MODULE,
-	.ids = xenfb_ids,
+static DEFINE_XENBUS_DRIVER(xenfb, ,
 	.probe = xenfb_probe,
 	.remove = xenfb_remove,
 	.resume = xenfb_resume,
 	.otherend_changed = xenfb_backend_changed,
-};
+);
 
 static int __init xenfb_init(void)
 {
--- 3.2-rc6/drivers/xen/xen-pciback/xenbus.c
+++ 3.2-rc6-struct-xenbus_driver/drivers/xen/xen-pciback/xenbus.c
@@ -707,19 +707,16 @@ static int xen_pcibk_xenbus_remove(struc
 	return 0;
 }
 
-static const struct xenbus_device_id xenpci_ids[] = {
+static const struct xenbus_device_id xen_pcibk_ids[] = {
 	{"pci"},
 	{""},
 };
 
-static struct xenbus_driver xenbus_xen_pcibk_driver = {
-	.name			= DRV_NAME,
-	.owner			= THIS_MODULE,
-	.ids			= xenpci_ids,
+static DEFINE_XENBUS_DRIVER(xen_pcibk, "pciback",
 	.probe			= xen_pcibk_xenbus_probe,
 	.remove			= xen_pcibk_xenbus_remove,
 	.otherend_changed	= xen_pcibk_frontend_changed,
-};
+);
 
 const struct xen_pcibk_backend *__read_mostly xen_pcibk_backend;
 
@@ -735,11 +732,11 @@ int __init xen_pcibk_xenbus_register(voi
 	if (passthrough)
 		xen_pcibk_backend = &xen_pcibk_passthrough_backend;
 	pr_info(DRV_NAME ": backend is %s\n", xen_pcibk_backend->name);
-	return xenbus_register_backend(&xenbus_xen_pcibk_driver);
+	return xenbus_register_backend(&xen_pcibk_driver);
 }
 
 void __exit xen_pcibk_xenbus_unregister(void)
 {
 	destroy_workqueue(xen_pcibk_wq);
-	xenbus_unregister_driver(&xenbus_xen_pcibk_driver);
+	xenbus_unregister_driver(&xen_pcibk_driver);
 }
--- 3.2-rc6/drivers/xen/xenbus/xenbus_probe.c
+++ 3.2-rc6-struct-xenbus_driver/drivers/xen/xenbus/xenbus_probe.c
@@ -291,14 +291,9 @@ void xenbus_dev_shutdown(struct device *
 EXPORT_SYMBOL_GPL(xenbus_dev_shutdown);
 
 int xenbus_register_driver_common(struct xenbus_driver *drv,
-				  struct xen_bus_type *bus,
-				  struct module *owner,
-				  const char *mod_name)
+				  struct xen_bus_type *bus)
 {
-	drv->driver.name = drv->name;
 	drv->driver.bus = &bus->bus;
-	drv->driver.owner = owner;
-	drv->driver.mod_name = mod_name;
 
 	return driver_register(&drv->driver);
 }
--- 3.2-rc6/drivers/xen/xenbus/xenbus_probe.h
+++ 3.2-rc6-struct-xenbus_driver/drivers/xen/xenbus/xenbus_probe.h
@@ -53,9 +53,7 @@ extern int xenbus_match(struct device *_
 extern int xenbus_dev_probe(struct device *_dev);
 extern int xenbus_dev_remove(struct device *_dev);
 extern int xenbus_register_driver_common(struct xenbus_driver *drv,
-					 struct xen_bus_type *bus,
-					 struct module *owner,
-					 const char *mod_name);
+					 struct xen_bus_type *bus);
 extern int xenbus_probe_node(struct xen_bus_type *bus,
 			     const char *type,
 			     const char *nodename);
--- 3.2-rc6/drivers/xen/xenbus/xenbus_probe_backend.c
+++ 3.2-rc6-struct-xenbus_driver/drivers/xen/xenbus/xenbus_probe_backend.c
@@ -232,15 +232,13 @@ int xenbus_dev_is_online(struct xenbus_d
 }
 EXPORT_SYMBOL_GPL(xenbus_dev_is_online);
 
-int __xenbus_register_backend(struct xenbus_driver *drv,
-			      struct module *owner, const char *mod_name)
+int xenbus_register_backend(struct xenbus_driver *drv)
 {
 	drv->read_otherend_details = read_frontend_details;
 
-	return xenbus_register_driver_common(drv, &xenbus_backend,
-					     owner, mod_name);
+	return xenbus_register_driver_common(drv, &xenbus_backend);
 }
-EXPORT_SYMBOL_GPL(__xenbus_register_backend);
+EXPORT_SYMBOL_GPL(xenbus_register_backend);
 
 static int backend_probe_and_watch(struct notifier_block *notifier,
 				   unsigned long event,
--- 3.2-rc6/drivers/xen/xenbus/xenbus_probe_frontend.c
+++ 3.2-rc6-struct-xenbus_driver/drivers/xen/xenbus/xenbus_probe_frontend.c
@@ -230,15 +230,13 @@ static void wait_for_devices(struct xenb
 			 print_device_status);
 }
 
-int __xenbus_register_frontend(struct xenbus_driver *drv,
-			       struct module *owner, const char *mod_name)
+int xenbus_register_frontend(struct xenbus_driver *drv)
 {
 	int ret;
 
 	drv->read_otherend_details = read_backend_details;
 
-	ret = xenbus_register_driver_common(drv, &xenbus_frontend,
-					    owner, mod_name);
+	ret = xenbus_register_driver_common(drv, &xenbus_frontend);
 	if (ret)
 		return ret;
 
@@ -247,7 +245,7 @@ int __xenbus_register_frontend(struct xe
 
 	return 0;
 }
-EXPORT_SYMBOL_GPL(__xenbus_register_frontend);
+EXPORT_SYMBOL_GPL(xenbus_register_frontend);
 
 static DECLARE_WAIT_QUEUE_HEAD(backend_state_wq);
 static int backend_state;
--- 3.2-rc6/include/xen/xenbus.h
+++ 3.2-rc6-struct-xenbus_driver/include/xen/xenbus.h
@@ -85,8 +85,6 @@ struct xenbus_device_id
 
 /* A xenbus driver. */
 struct xenbus_driver {
-	char *name;
-	struct module *owner;
 	const struct xenbus_device_id *ids;
 	int (*probe)(struct xenbus_device *dev,
 		     const struct xenbus_device_id *id);
@@ -101,31 +99,20 @@ struct xenbus_driver {
 	int (*is_ready)(struct xenbus_device *dev);
 };
 
-static inline struct xenbus_driver *to_xenbus_driver(struct device_driver *drv)
-{
-	return container_of(drv, struct xenbus_driver, driver);
+#define DEFINE_XENBUS_DRIVER(var, drvname, methods...)		\
+struct xenbus_driver var ## _driver = {				\
+	.driver.name = drvname + 0 ?: var ## _ids->devicetype,	\
+	.driver.owner = THIS_MODULE,				\
+	.ids = var ## _ids, ## methods				\
 }
 
-int __must_check __xenbus_register_frontend(struct xenbus_driver *drv,
-					    struct module *owner,
-					    const char *mod_name);
-
-static inline int __must_check
-xenbus_register_frontend(struct xenbus_driver *drv)
+static inline struct xenbus_driver *to_xenbus_driver(struct device_driver *drv)
 {
-	WARN_ON(drv->owner != THIS_MODULE);
-	return __xenbus_register_frontend(drv, THIS_MODULE, KBUILD_MODNAME);
+	return container_of(drv, struct xenbus_driver, driver);
 }
 
-int __must_check __xenbus_register_backend(struct xenbus_driver *drv,
-					   struct module *owner,
-					   const char *mod_name);
-static inline int __must_check
-xenbus_register_backend(struct xenbus_driver *drv)
-{
-	WARN_ON(drv->owner != THIS_MODULE);
-	return __xenbus_register_backend(drv, THIS_MODULE, KBUILD_MODNAME);
-}
+int __must_check xenbus_register_frontend(struct xenbus_driver *);
+int __must_check xenbus_register_backend(struct xenbus_driver *);
 
 void xenbus_unregister_driver(struct xenbus_driver *drv);
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 21 18:29:25 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 18:29:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdQuG-0004E4-EG; Wed, 21 Dec 2011 18:28:48 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RdQuF-0004Dw-9s
	for xen-devel@lists.xensource.com; Wed, 21 Dec 2011 18:28:47 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1324492120!8366488!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzcyNA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16685 invoked from network); 21 Dec 2011 18:28:40 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Dec 2011 18:28:40 -0000
X-IronPort-AV: E=Sophos;i="4.71,389,1320624000"; 
   d="scan'208";a="9617592"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Dec 2011 18:28:39 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 21 Dec 2011 18:28:40 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RdQu7-0004AF-K1;
	Wed, 21 Dec 2011 18:28:39 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RdQu7-0000sL-Ha;
	Wed, 21 Dec 2011 18:28:39 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10570-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 21 Dec 2011 18:28:39 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux test] 10570: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10570 linux real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10570/

Regressions :-(

Tests which did not succeed and are blocking,including tests which could not be run:
 test-amd64-amd64-win          7 windows-install            fail REGR. vs. 9095
 test-amd64-i386-win           7 windows-install            fail REGR. vs. 9095
 test-amd64-amd64-xl-win       7 windows-install            fail REGR. vs. 9095
 build-amd64-pvops             1 hosts-allocate               broken   in 10565

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-multivcpu 16 guest-start.2               fail pass in 10565
 test-amd64-i386-xl-win-vcpus1  7 windows-install   fail in 10565 pass in 10570
 test-amd64-i386-win-vcpus1    7 windows-install    fail in 10565 pass in 10570

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-xl-win7-amd64  7 windows-install              fail never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-i386-i386-xl-winxpsp3    7 windows-install           fail blocked in 9095
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install     fail blocked in 9095
 build-amd64-pvops             2 logs-capture(2)     broken in 10565 never pass
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)     blocked in 10565 n/a
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)      blocked in 10565 n/a
 test-amd64-amd64-xl-sedf-pin  1 xen-build-check(1)        blocked in 10565 n/a
 test-amd64-amd64-pv           1 xen-build-check(1)        blocked in 10565 n/a
 test-amd64-amd64-xl           1 xen-build-check(1)        blocked in 10565 n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)        blocked in 10565 n/a
 test-amd64-amd64-pair         1 xen-build-check(1)        blocked in 10565 n/a
 test-amd64-amd64-xl-winxpsp3  1 xen-build-check(1)        blocked in 10565 n/a
 test-amd64-i386-xend-winxpsp3  7 windows-install fail in 10565 blocked in 9095
 test-amd64-amd64-win          1 xen-build-check(1)        blocked in 10565 n/a
 test-i386-i386-xl-winxpsp3   13 guest-stop            fail in 10565 never pass
 test-amd64-amd64-xl-win       1 xen-build-check(1)        blocked in 10565 n/a
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop      fail in 10565 never pass

version targeted for testing:
 linux                59b1ffe039ce366305d48176b7fccce29ce729d3
baseline version:
 linux                6bec8b4a4c14095d0b7ce424db9d583c3decae6c

------------------------------------------------------------
People who touched revisions under test:
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
commit 59b1ffe039ce366305d48176b7fccce29ce729d3
Merge: cacd265... 60b1e4f...
Author: Jeremy Fitzhardinge <jeremy@goop.org>
Date:   Sat Dec 10 00:20:33 2011 -0800

    Merge commit 'v2.6.32.50' into xen/next-2.6.32
    
    * commit 'v2.6.32.50': (28 commits)
      Linux 2.6.32.50
      clockevents: Set noop handler in clockevents_exchange_device()
      tick-broadcast: Stop active broadcast device when replacing it
      genirq: Fix race condition when stopping the irq thread
      oprofile, x86: Fix crash when unloading module (nmi timer mode)
      x86/mpparse: Account for bus types other than ISA and PCI
      sched, x86: Avoid unnecessary overflow in sched_clock
      cifs: fix cifs stable patch cifs-fix-oplock-break-handling-try-2.patch
      SCSI: Silencing 'killing requests for dead queue'
      SCSI: scsi_lib: fix potential NULL dereference
      USB: usb-storage: unusual_devs entry for Kingston DT 101 G2
      usb: option: add SIMCom SIM5218
      usb: ftdi_sio: add PID for Propox ISPcable III
      USB: whci-hcd: fix endian conversion in qset_clear()
      Staging: comedi: fix signal handling in read and write
      staging: comedi: fix oops for USB DAQ devices.
      staging: usbip: bugfix for deadlock
      gro: reset vlan_tci on reuse
      nl80211: fix MAC address validation
      p54spi: Fix workqueue deadlock
      ...

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 21 18:29:25 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 18:29:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdQuG-0004E4-EG; Wed, 21 Dec 2011 18:28:48 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RdQuF-0004Dw-9s
	for xen-devel@lists.xensource.com; Wed, 21 Dec 2011 18:28:47 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1324492120!8366488!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzcyNA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16685 invoked from network); 21 Dec 2011 18:28:40 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Dec 2011 18:28:40 -0000
X-IronPort-AV: E=Sophos;i="4.71,389,1320624000"; 
   d="scan'208";a="9617592"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Dec 2011 18:28:39 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 21 Dec 2011 18:28:40 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RdQu7-0004AF-K1;
	Wed, 21 Dec 2011 18:28:39 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RdQu7-0000sL-Ha;
	Wed, 21 Dec 2011 18:28:39 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10570-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 21 Dec 2011 18:28:39 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux test] 10570: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10570 linux real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10570/

Regressions :-(

Tests which did not succeed and are blocking,including tests which could not be run:
 test-amd64-amd64-win          7 windows-install            fail REGR. vs. 9095
 test-amd64-i386-win           7 windows-install            fail REGR. vs. 9095
 test-amd64-amd64-xl-win       7 windows-install            fail REGR. vs. 9095
 build-amd64-pvops             1 hosts-allocate               broken   in 10565

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-multivcpu 16 guest-start.2               fail pass in 10565
 test-amd64-i386-xl-win-vcpus1  7 windows-install   fail in 10565 pass in 10570
 test-amd64-i386-win-vcpus1    7 windows-install    fail in 10565 pass in 10570

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-xl-win7-amd64  7 windows-install              fail never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-i386-i386-xl-winxpsp3    7 windows-install           fail blocked in 9095
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install     fail blocked in 9095
 build-amd64-pvops             2 logs-capture(2)     broken in 10565 never pass
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)     blocked in 10565 n/a
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)      blocked in 10565 n/a
 test-amd64-amd64-xl-sedf-pin  1 xen-build-check(1)        blocked in 10565 n/a
 test-amd64-amd64-pv           1 xen-build-check(1)        blocked in 10565 n/a
 test-amd64-amd64-xl           1 xen-build-check(1)        blocked in 10565 n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)        blocked in 10565 n/a
 test-amd64-amd64-pair         1 xen-build-check(1)        blocked in 10565 n/a
 test-amd64-amd64-xl-winxpsp3  1 xen-build-check(1)        blocked in 10565 n/a
 test-amd64-i386-xend-winxpsp3  7 windows-install fail in 10565 blocked in 9095
 test-amd64-amd64-win          1 xen-build-check(1)        blocked in 10565 n/a
 test-i386-i386-xl-winxpsp3   13 guest-stop            fail in 10565 never pass
 test-amd64-amd64-xl-win       1 xen-build-check(1)        blocked in 10565 n/a
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop      fail in 10565 never pass

version targeted for testing:
 linux                59b1ffe039ce366305d48176b7fccce29ce729d3
baseline version:
 linux                6bec8b4a4c14095d0b7ce424db9d583c3decae6c

------------------------------------------------------------
People who touched revisions under test:
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
commit 59b1ffe039ce366305d48176b7fccce29ce729d3
Merge: cacd265... 60b1e4f...
Author: Jeremy Fitzhardinge <jeremy@goop.org>
Date:   Sat Dec 10 00:20:33 2011 -0800

    Merge commit 'v2.6.32.50' into xen/next-2.6.32
    
    * commit 'v2.6.32.50': (28 commits)
      Linux 2.6.32.50
      clockevents: Set noop handler in clockevents_exchange_device()
      tick-broadcast: Stop active broadcast device when replacing it
      genirq: Fix race condition when stopping the irq thread
      oprofile, x86: Fix crash when unloading module (nmi timer mode)
      x86/mpparse: Account for bus types other than ISA and PCI
      sched, x86: Avoid unnecessary overflow in sched_clock
      cifs: fix cifs stable patch cifs-fix-oplock-break-handling-try-2.patch
      SCSI: Silencing 'killing requests for dead queue'
      SCSI: scsi_lib: fix potential NULL dereference
      USB: usb-storage: unusual_devs entry for Kingston DT 101 G2
      usb: option: add SIMCom SIM5218
      usb: ftdi_sio: add PID for Propox ISPcable III
      USB: whci-hcd: fix endian conversion in qset_clear()
      Staging: comedi: fix signal handling in read and write
      staging: comedi: fix oops for USB DAQ devices.
      staging: usbip: bugfix for deadlock
      gro: reset vlan_tci on reuse
      nl80211: fix MAC address validation
      p54spi: Fix workqueue deadlock
      ...

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 21 19:12:51 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 19:12:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdRaI-0004xk-RH; Wed, 21 Dec 2011 19:12:14 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <rdunlap@xenotime.net>) id 1RdRaH-0004xb-5R
	for xen-devel@lists.xensource.com; Wed, 21 Dec 2011 19:12:13 +0000
X-Env-Sender: rdunlap@xenotime.net
X-Msg-Ref: server-15.tower-27.messagelabs.com!1324494709!59863081!1
X-Originating-IP: [67.222.38.55]
X-SpamReason: No, hits=3.5 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA2Ny4yMjIuMzguNTUgPT4gMzQ1NDc=\n,sa_preprocessor: 
	QmFkIElQOiA2Ny4yMjIuMzguNTUgPT4gMzQ1NDc=\n, UNIQUE_WORDS,
	UPPERCASE_75_100
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3821 invoked from network); 21 Dec 2011 19:11:49 -0000
Received: from oproxy5-pub.bluehost.com (HELO oproxy5-pub.bluehost.com)
	(67.222.38.55) by server-15.tower-27.messagelabs.com with SMTP;
	21 Dec 2011 19:11:49 -0000
Received: (qmail 17191 invoked by uid 0); 21 Dec 2011 19:12:07 -0000
Received: from unknown (HELO box742.bluehost.com) (66.147.244.242)
	by cpoproxy2.bluehost.com with SMTP; 21 Dec 2011 19:11:16 -0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenotime.net;
	s=default; 
	h=Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID;
	bh=fbYDPNJosMkGaF7Z7n0ecB8B+bPYvArZweGnLIn+TSg=; 
	b=AKtvYlXzLHgBynPNakbFzklcQKjje1SrYRIy1uwRA5Fp3/xKTXNoua56XGeZdTn5YpCFnZFimYKFL+4FjhpMMfiJcqaULSyi1bN9DhW8VAvXKBbVhwc++FRXWqzNHeiG;
Received: from static-50-53-38-135.bvtn.or.frontiernet.net ([50.53.38.135]
	helo=[192.168.1.3])
	by box742.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256)
	(Exim 4.76) (envelope-from <rdunlap@xenotime.net>)
	id 1RdRZM-0004oA-59; Wed, 21 Dec 2011 12:11:16 -0700
Message-ID: <4EF23D67.9050602@xenotime.net>
Date: Wed, 21 Dec 2011 12:11:19 -0800
From: Randy Dunlap <rdunlap@xenotime.net>
Organization: YPO4
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.15) Gecko/20110323 Thunderbird/3.1.9
MIME-Version: 1.0
To: Stephen Rothwell <sfr@canb.auug.org.au>
References: <20111221174733.9ba0861e762e8d96844b060b@canb.auug.org.au>
In-Reply-To: <20111221174733.9ba0861e762e8d96844b060b@canb.auug.org.au>
Content-Type: multipart/mixed; boundary="------------070407000708080709040807"
X-Identified-User: {1807:box742.bluehost.com:xenotime:xenotime.net}
	{sentby:smtp auth 50.53.38.135 authed with
	rdunlap@xenotime.net}
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	linux-next@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] linux-next: Tree for Dec 21 (xen)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a multi-part message in MIME format.
--------------070407000708080709040807
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

On 12/20/2011 10:47 PM, Stephen Rothwell wrote:
> Hi all,
> 
> Changes since 20111220:


drivers/xen/xenbus/xenbus_dev_backend.c:74:2: error: implicit declaration of function 'xen_initial_domain'

Full randconfig file is attached.

-- 
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***

--------------070407000708080709040807
Content-Type: text/plain;
 name="config-xenbus"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="config-xenbus"

#
# Automatically generated file; DO NOT EDIT.
# Linux/x86_64 3.2.0-rc6 Kernel Configuration
#
CONFIG_64BIT=y
# CONFIG_X86_32 is not set
CONFIG_X86_64=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_OUTPUT_FORMAT="elf64-x86-64"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig"
CONFIG_GENERIC_CMOS_UPDATE=y
CONFIG_CLOCKSOURCE_WATCHDOG=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_ARCH_CLOCKSOURCE_DATA=y
CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_HAVE_LATENCYTOP_SUPPORT=y
CONFIG_MMU=y
CONFIG_ZONE_DMA=y
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_GENERIC_GPIO=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
# CONFIG_RWSEM_GENERIC_SPINLOCK is not set
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_ARCH_HAS_CPU_IDLE_WAIT=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_GENERIC_TIME_VSYSCALL=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_DEFAULT_IDLE=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ZONE_DMA32=y
CONFIG_AUDIT_ARCH=y
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_ARCH_HWEIGHT_CFLAGS="-fcall-saved-rdi -fcall-saved-rsi -fcall-saved-rdx -fcall-saved-rcx -fcall-saved-r8 -fcall-saved-r9 -fcall-saved-r10 -fcall-saved-r11"
# CONFIG_KTIME_SCALAR is not set
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_CONSTRUCTORS=y
CONFIG_HAVE_IRQ_WORK=y
CONFIG_IRQ_WORK=y

#
# General setup
#
CONFIG_EXPERIMENTAL=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
CONFIG_LOCALVERSION=""
# CONFIG_LOCALVERSION_AUTO is not set
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
# CONFIG_KERNEL_GZIP is not set
# CONFIG_KERNEL_BZIP2 is not set
CONFIG_KERNEL_LZMA=y
# CONFIG_KERNEL_XZ is not set
# CONFIG_KERNEL_LZO is not set
CONFIG_DEFAULT_HOSTNAME="(none)"
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
CONFIG_POSIX_MQUEUE=y
CONFIG_POSIX_MQUEUE_SYSCTL=y
# CONFIG_BSD_PROCESS_ACCT is not set
CONFIG_FHANDLE=y
CONFIG_TASKSTATS=y
CONFIG_TASK_DELAY_ACCT=y
CONFIG_TASK_XACCT=y
CONFIG_TASK_IO_ACCOUNTING=y
# CONFIG_AUDIT is not set
CONFIG_HAVE_GENERIC_HARDIRQS=y

#
# IRQ subsystem
#
CONFIG_GENERIC_HARDIRQS=y
CONFIG_HAVE_SPARSE_IRQ=y
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_GENERIC_IRQ_CHIP=y
CONFIG_IRQ_FORCED_THREADING=y
CONFIG_SPARSE_IRQ=y

#
# RCU Subsystem
#
CONFIG_TINY_PREEMPT_RCU=y
CONFIG_PREEMPT_RCU=y
CONFIG_RCU_TRACE=y
# CONFIG_TREE_RCU_TRACE is not set
# CONFIG_RCU_BOOST is not set
# CONFIG_IKCONFIG is not set
CONFIG_LOG_BUF_SHIFT=17
CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y
CONFIG_CGROUPS=y
# CONFIG_CGROUP_DEBUG is not set
CONFIG_CGROUP_FREEZER=y
# CONFIG_CGROUP_DEVICE is not set
CONFIG_CPUSETS=y
# CONFIG_PROC_PID_CPUSET is not set
# CONFIG_CGROUP_CPUACCT is not set
CONFIG_RESOURCE_COUNTERS=y
# CONFIG_CGROUP_MEM_RES_CTLR is not set
CONFIG_CGROUP_PERF=y
# CONFIG_CGROUP_SCHED is not set
CONFIG_BLK_CGROUP=y
# CONFIG_DEBUG_BLK_CGROUP is not set
# CONFIG_CHECKPOINT_RESTORE is not set
CONFIG_NAMESPACES=y
# CONFIG_UTS_NS is not set
CONFIG_IPC_NS=y
# CONFIG_USER_NS is not set
# CONFIG_PID_NS is not set
CONFIG_NET_NS=y
# CONFIG_SCHED_AUTOGROUP is not set
# CONFIG_SYSFS_DEPRECATED is not set
CONFIG_RELAY=y
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=""
CONFIG_RD_GZIP=y
CONFIG_RD_BZIP2=y
CONFIG_RD_LZMA=y
CONFIG_RD_XZ=y
CONFIG_RD_LZO=y
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
CONFIG_SYSCTL=y
CONFIG_ANON_INODES=y
# CONFIG_EXPERT is not set
CONFIG_UID16=y
# CONFIG_SYSCTL_SYSCALL is not set
CONFIG_KALLSYMS=y
CONFIG_KALLSYMS_ALL=y
CONFIG_HOTPLUG=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_PCSPKR_PLATFORM=y
CONFIG_HAVE_PCSPKR_PLATFORM=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_SIGNALFD=y
CONFIG_TIMERFD=y
CONFIG_EVENTFD=y
CONFIG_SHMEM=y
CONFIG_AIO=y
# CONFIG_EMBEDDED is not set
CONFIG_HAVE_PERF_EVENTS=y
CONFIG_PERF_USE_VMALLOC=y

#
# Kernel Performance Events And Counters
#
CONFIG_PERF_EVENTS=y
# CONFIG_PERF_COUNTERS is not set
CONFIG_DEBUG_PERF_USE_VMALLOC=y
CONFIG_VM_EVENT_COUNTERS=y
CONFIG_PCI_QUIRKS=y
CONFIG_SLUB_DEBUG=y
CONFIG_COMPAT_BRK=y
# CONFIG_SLAB is not set
CONFIG_SLUB=y
# CONFIG_PROFILING is not set
CONFIG_TRACEPOINTS=y
CONFIG_HAVE_OPROFILE=y
CONFIG_OPROFILE_NMI_TIMER=y
# CONFIG_JUMP_LABEL is not set
CONFIG_UPROBES=y
CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS=y
CONFIG_USER_RETURN_NOTIFIER=y
CONFIG_HAVE_IOREMAP_PROT=y
CONFIG_HAVE_KPROBES=y
CONFIG_HAVE_KRETPROBES=y
CONFIG_HAVE_OPTPROBES=y
CONFIG_HAVE_ARCH_TRACEHOOK=y
CONFIG_HAVE_DMA_ATTRS=y
CONFIG_HAVE_REGS_AND_STACK_ACCESS_API=y
CONFIG_HAVE_DMA_API_DEBUG=y
CONFIG_HAVE_HW_BREAKPOINT=y
CONFIG_HAVE_MIXED_BREAKPOINTS_REGS=y
CONFIG_HAVE_USER_RETURN_NOTIFIER=y
CONFIG_HAVE_PERF_EVENTS_NMI=y
CONFIG_HAVE_ARCH_JUMP_LABEL=y
CONFIG_ARCH_HAVE_NMI_SAFE_CMPXCHG=y
CONFIG_HAVE_ALIGNED_STRUCT_PAGE=y
CONFIG_HAVE_CMPXCHG_LOCAL=y
CONFIG_HAVE_CMPXCHG_DOUBLE=y

#
# GCOV-based kernel profiling
#
CONFIG_GCOV_KERNEL=y
# CONFIG_GCOV_PROFILE_ALL is not set
# CONFIG_HAVE_GENERIC_DMA_COHERENT is not set
CONFIG_SLABINFO=y
CONFIG_RT_MUTEXES=y
CONFIG_BASE_SMALL=0
# CONFIG_MODULES is not set
CONFIG_BLOCK=y
CONFIG_BLK_DEV_BSG=y
CONFIG_BLK_DEV_BSGLIB=y
# CONFIG_BLK_DEV_INTEGRITY is not set
# CONFIG_BLK_DEV_THROTTLING is not set
CONFIG_BLOCK_COMPAT=y

#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_DEADLINE=y
# CONFIG_IOSCHED_CFQ is not set
# CONFIG_DEFAULT_DEADLINE is not set
CONFIG_DEFAULT_NOOP=y
CONFIG_DEFAULT_IOSCHED="noop"
CONFIG_PREEMPT_NOTIFIERS=y
# CONFIG_INLINE_SPIN_TRYLOCK is not set
# CONFIG_INLINE_SPIN_TRYLOCK_BH is not set
# CONFIG_INLINE_SPIN_LOCK is not set
# CONFIG_INLINE_SPIN_LOCK_BH is not set
# CONFIG_INLINE_SPIN_LOCK_IRQ is not set
# CONFIG_INLINE_SPIN_LOCK_IRQSAVE is not set
# CONFIG_INLINE_SPIN_UNLOCK is not set
# CONFIG_INLINE_SPIN_UNLOCK_BH is not set
# CONFIG_INLINE_SPIN_UNLOCK_IRQ is not set
# CONFIG_INLINE_SPIN_UNLOCK_IRQRESTORE is not set
# CONFIG_INLINE_READ_TRYLOCK is not set
# CONFIG_INLINE_READ_LOCK is not set
# CONFIG_INLINE_READ_LOCK_BH is not set
# CONFIG_INLINE_READ_LOCK_IRQ is not set
# CONFIG_INLINE_READ_LOCK_IRQSAVE is not set
# CONFIG_INLINE_READ_UNLOCK is not set
# CONFIG_INLINE_READ_UNLOCK_BH is not set
# CONFIG_INLINE_READ_UNLOCK_IRQ is not set
# CONFIG_INLINE_READ_UNLOCK_IRQRESTORE is not set
# CONFIG_INLINE_WRITE_TRYLOCK is not set
# CONFIG_INLINE_WRITE_LOCK is not set
# CONFIG_INLINE_WRITE_LOCK_BH is not set
# CONFIG_INLINE_WRITE_LOCK_IRQ is not set
# CONFIG_INLINE_WRITE_LOCK_IRQSAVE is not set
# CONFIG_INLINE_WRITE_UNLOCK is not set
# CONFIG_INLINE_WRITE_UNLOCK_BH is not set
# CONFIG_INLINE_WRITE_UNLOCK_IRQ is not set
# CONFIG_INLINE_WRITE_UNLOCK_IRQRESTORE is not set
# CONFIG_MUTEX_SPIN_ON_OWNER is not set
CONFIG_FREEZER=y

#
# Processor type and features
#
CONFIG_TICK_ONESHOT=y
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y
CONFIG_GENERIC_CLOCKEVENTS_BUILD=y
CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y
# CONFIG_SMP is not set
CONFIG_X86_MPPARSE=y
CONFIG_X86_EXTENDED_PLATFORM=y
CONFIG_X86_VSMP=y
# CONFIG_SCHED_OMIT_FRAME_POINTER is not set
# CONFIG_KVMTOOL_TEST_ENABLE is not set
CONFIG_PARAVIRT_GUEST=y
# CONFIG_PARAVIRT_TIME_ACCOUNTING is not set
CONFIG_XEN=y
CONFIG_XEN_DOM0=y
CONFIG_XEN_PRIVILEGED_GUEST=y
CONFIG_XEN_PVHVM=y
CONFIG_XEN_MAX_DOMAIN_MEMORY=500
CONFIG_XEN_SAVE_RESTORE=y
# CONFIG_XEN_DEBUG_FS is not set
# CONFIG_KVM_CLOCK is not set
# CONFIG_KVM_GUEST is not set
CONFIG_PARAVIRT=y
CONFIG_PARAVIRT_CLOCK=y
CONFIG_PARAVIRT_DEBUG=y
CONFIG_NO_BOOTMEM=y
CONFIG_MEMTEST=y
# CONFIG_MK8 is not set
# CONFIG_MPSC is not set
# CONFIG_MCORE2 is not set
# CONFIG_MATOM is not set
CONFIG_GENERIC_CPU=y
CONFIG_X86_INTERNODE_CACHE_SHIFT=12
CONFIG_X86_CMPXCHG=y
CONFIG_X86_L1_CACHE_SHIFT=6
CONFIG_X86_XADD=y
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_TSC=y
CONFIG_X86_CMPXCHG64=y
CONFIG_X86_CMOV=y
CONFIG_X86_MINIMUM_CPU_FAMILY=64
CONFIG_X86_DEBUGCTLMSR=y
CONFIG_CPU_SUP_INTEL=y
CONFIG_CPU_SUP_AMD=y
CONFIG_CPU_SUP_CENTAUR=y
CONFIG_HPET_TIMER=y
CONFIG_HPET_EMULATE_RTC=y
CONFIG_DMI=y
CONFIG_GART_IOMMU=y
CONFIG_CALGARY_IOMMU=y
# CONFIG_CALGARY_IOMMU_ENABLED_BY_DEFAULT is not set
CONFIG_SWIOTLB=y
CONFIG_IOMMU_HELPER=y
CONFIG_NR_CPUS=1
# CONFIG_IRQ_TIME_ACCOUNTING is not set
# CONFIG_PREEMPT_NONE is not set
# CONFIG_PREEMPT_VOLUNTARY is not set
CONFIG_PREEMPT=y
CONFIG_PREEMPT_COUNT=y
CONFIG_X86_LOCAL_APIC=y
CONFIG_X86_IO_APIC=y
CONFIG_X86_REROUTE_FOR_BROKEN_BOOT_IRQS=y
# CONFIG_X86_MCE is not set
# CONFIG_I8K is not set
# CONFIG_MICROCODE is not set
CONFIG_X86_MSR=y
# CONFIG_X86_CPUID is not set
CONFIG_ARCH_PHYS_ADDR_T_64BIT=y
CONFIG_ARCH_DMA_ADDR_T_64BIT=y
CONFIG_DIRECT_GBPAGES=y
CONFIG_ARCH_SPARSEMEM_ENABLE=y
CONFIG_ARCH_SPARSEMEM_DEFAULT=y
CONFIG_ARCH_SELECT_MEMORY_MODEL=y
CONFIG_ARCH_PROC_KCORE_TEXT=y
CONFIG_ILLEGAL_POINTER_VALUE=0xdead000000000000
CONFIG_SELECT_MEMORY_MODEL=y
CONFIG_SPARSEMEM_MANUAL=y
CONFIG_SPARSEMEM=y
CONFIG_HAVE_MEMORY_PRESENT=y
CONFIG_SPARSEMEM_EXTREME=y
CONFIG_SPARSEMEM_VMEMMAP_ENABLE=y
CONFIG_SPARSEMEM_ALLOC_MEM_MAP_TOGETHER=y
CONFIG_SPARSEMEM_VMEMMAP=y
CONFIG_HAVE_MEMBLOCK=y
CONFIG_HAVE_MEMBLOCK_NODE_MAP=y
CONFIG_ARCH_DISCARD_MEMBLOCK=y
# CONFIG_MEMORY_HOTPLUG is not set
CONFIG_PAGEFLAGS_EXTENDED=y
CONFIG_SPLIT_PTLOCK_CPUS=999999
CONFIG_COMPACTION=y
CONFIG_MIGRATION=y
CONFIG_PHYS_ADDR_T_64BIT=y
CONFIG_ZONE_DMA_FLAG=1
CONFIG_BOUNCE=y
CONFIG_VIRT_TO_BUS=y
CONFIG_MMU_NOTIFIER=y
CONFIG_KSM=y
CONFIG_DEFAULT_MMAP_MIN_ADDR=4096
CONFIG_TRANSPARENT_HUGEPAGE=y
# CONFIG_TRANSPARENT_HUGEPAGE_ALWAYS is not set
CONFIG_TRANSPARENT_HUGEPAGE_MADVISE=y
CONFIG_NEED_PER_CPU_KM=y
CONFIG_CLEANCACHE=y
CONFIG_FRONTSWAP=y
CONFIG_X86_CHECK_BIOS_CORRUPTION=y
CONFIG_X86_BOOTPARAM_MEMORY_CORRUPTION_CHECK=y
CONFIG_X86_RESERVE_LOW=64
CONFIG_MTRR=y
CONFIG_MTRR_SANITIZER=y
CONFIG_MTRR_SANITIZER_ENABLE_DEFAULT=0
CONFIG_MTRR_SANITIZER_SPARE_REG_NR_DEFAULT=1
CONFIG_X86_PAT=y
CONFIG_ARCH_USES_PG_UNCACHED=y
CONFIG_ARCH_RANDOM=y
CONFIG_EFI=y
CONFIG_EFI_STUB=y
CONFIG_SECCOMP=y
# CONFIG_CC_STACKPROTECTOR is not set
# CONFIG_HZ_100 is not set
CONFIG_HZ_250=y
# CONFIG_HZ_300 is not set
# CONFIG_HZ_1000 is not set
CONFIG_HZ=250
CONFIG_SCHED_HRTICK=y
# CONFIG_KEXEC is not set
# CONFIG_CRASH_DUMP is not set
CONFIG_PHYSICAL_START=0x1000000
CONFIG_RELOCATABLE=y
CONFIG_PHYSICAL_ALIGN=0x1000000
CONFIG_COMPAT_VDSO=y
CONFIG_CMDLINE_BOOL=y
CONFIG_CMDLINE=""
# CONFIG_CMDLINE_OVERRIDE is not set
CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y

#
# Power management and ACPI options
#
CONFIG_ARCH_HIBERNATION_HEADER=y
# CONFIG_SUSPEND is not set
CONFIG_HIBERNATE_CALLBACKS=y
CONFIG_HIBERNATION=y
CONFIG_PM_STD_PARTITION=""
CONFIG_PM_SLEEP=y
# CONFIG_PM_RUNTIME is not set
CONFIG_PM=y
CONFIG_PM_DEBUG=y
# CONFIG_PM_ADVANCED_DEBUG is not set
CONFIG_CAN_PM_TRACE=y
# CONFIG_PM_TRACE_RTC is not set
CONFIG_ACPI=y
CONFIG_ACPI_SLEEP=y
CONFIG_ACPI_PROCFS=y
# CONFIG_ACPI_PROCFS_POWER is not set
# CONFIG_ACPI_EC_DEBUGFS is not set
CONFIG_ACPI_PROC_EVENT=y
# CONFIG_ACPI_AC is not set
CONFIG_ACPI_BATTERY=y
CONFIG_ACPI_BUTTON=y
CONFIG_ACPI_VIDEO=y
CONFIG_ACPI_FAN=y
CONFIG_ACPI_DOCK=y
CONFIG_ACPI_PROCESSOR=y
CONFIG_ACPI_PROCESSOR_AGGREGATOR=y
# CONFIG_ACPI_THERMAL is not set
# CONFIG_ACPI_CUSTOM_DSDT is not set
CONFIG_ACPI_BLACKLIST_YEAR=0
# CONFIG_ACPI_DEBUG is not set
# CONFIG_ACPI_PCI_SLOT is not set
CONFIG_X86_PM_TIMER=y
# CONFIG_ACPI_CONTAINER is not set
CONFIG_ACPI_SBS=y
CONFIG_ACPI_HED=y
CONFIG_ACPI_CUSTOM_METHOD=y
CONFIG_ACPI_APEI=y
# CONFIG_ACPI_APEI_GHES is not set
# CONFIG_ACPI_APEI_PCIEAER is not set
CONFIG_ACPI_APEI_EINJ=y
# CONFIG_ACPI_APEI_ERST_DEBUG is not set
# CONFIG_SFI is not set

#
# CPU Frequency scaling
#
# CONFIG_CPU_FREQ is not set
CONFIG_CPU_IDLE=y
CONFIG_CPU_IDLE_GOV_LADDER=y
CONFIG_CPU_IDLE_GOV_MENU=y
# CONFIG_INTEL_IDLE is not set

#
# Memory power savings
#
# CONFIG_I7300_IDLE is not set

#
# Bus options (PCI etc.)
#
CONFIG_PCI=y
CONFIG_PCI_DIRECT=y
CONFIG_PCI_MMCONFIG=y
CONFIG_PCI_XEN=y
CONFIG_PCI_DOMAINS=y
# CONFIG_PCI_CNB20LE_QUIRK is not set
CONFIG_PCIEPORTBUS=y
# CONFIG_HOTPLUG_PCI_PCIE is not set
CONFIG_PCIEAER=y
CONFIG_PCIE_ECRC=y
# CONFIG_PCIEAER_INJECT is not set
CONFIG_PCIEASPM=y
CONFIG_PCIEASPM_DEBUG=y
CONFIG_ARCH_SUPPORTS_MSI=y
# CONFIG_PCI_MSI is not set
# CONFIG_PCI_DEBUG is not set
# CONFIG_PCI_STUB is not set
CONFIG_XEN_PCIDEV_FRONTEND=y
# CONFIG_HT_IRQ is not set
CONFIG_PCI_ATS=y
CONFIG_PCI_IOV=y
# CONFIG_PCI_PRI is not set
# CONFIG_PCI_PASID is not set
CONFIG_PCI_IOAPIC=y
CONFIG_PCI_LABEL=y
CONFIG_ISA_DMA_API=y
CONFIG_AMD_NB=y
CONFIG_PCCARD=y
# CONFIG_PCMCIA is not set
CONFIG_CARDBUS=y

#
# PC-card bridges
#
CONFIG_YENTA=y
CONFIG_YENTA_O2=y
CONFIG_YENTA_RICOH=y
CONFIG_YENTA_TI=y
CONFIG_YENTA_ENE_TUNE=y
CONFIG_YENTA_TOSHIBA=y
CONFIG_HOTPLUG_PCI=y
# CONFIG_HOTPLUG_PCI_FAKE is not set
# CONFIG_HOTPLUG_PCI_ACPI is not set
# CONFIG_HOTPLUG_PCI_CPCI is not set
# CONFIG_HOTPLUG_PCI_SHPC is not set
CONFIG_RAPIDIO=y
# CONFIG_RAPIDIO_TSI721 is not set
CONFIG_RAPIDIO_DISC_TIMEOUT=30
# CONFIG_RAPIDIO_ENABLE_RX_TX_PORTS is not set
CONFIG_RAPIDIO_DEBUG=y
# CONFIG_RAPIDIO_TSI57X is not set
# CONFIG_RAPIDIO_CPS_XX is not set
CONFIG_RAPIDIO_TSI568=y
# CONFIG_RAPIDIO_CPS_GEN2 is not set
# CONFIG_RAPIDIO_TSI500 is not set

#
# Executable file formats / Emulations
#
# CONFIG_BINFMT_ELF is not set
CONFIG_COMPAT_BINFMT_ELF=y
CONFIG_ARCH_BINFMT_ELF_RANDOMIZE_PIE=y
# CONFIG_HAVE_AOUT is not set
# CONFIG_BINFMT_MISC is not set
CONFIG_IA32_EMULATION=y
# CONFIG_IA32_AOUT is not set
CONFIG_COMPAT=y
CONFIG_COMPAT_FOR_U64_ALIGNMENT=y
CONFIG_SYSVIPC_COMPAT=y
CONFIG_KEYS_COMPAT=y
CONFIG_HAVE_TEXT_POKE_SMP=y
CONFIG_NET=y
CONFIG_COMPAT_NETLINK_MESSAGES=y

#
# Networking options
#
# CONFIG_PACKET is not set
CONFIG_UNIX=y
# CONFIG_UNIX_DIAG is not set
CONFIG_XFRM=y
CONFIG_XFRM_SUB_POLICY=y
CONFIG_XFRM_MIGRATE=y
CONFIG_NET_KEY=y
CONFIG_NET_KEY_MIGRATE=y
# CONFIG_INET is not set
CONFIG_NETWORK_SECMARK=y
# CONFIG_NETWORK_PHY_TIMESTAMPING is not set
CONFIG_NETFILTER=y
CONFIG_NETFILTER_DEBUG=y
# CONFIG_NETFILTER_ADVANCED is not set
CONFIG_ATM=y
CONFIG_ATM_LANE=y
# CONFIG_BRIDGE is not set
CONFIG_NET_DSA=y
CONFIG_NET_DSA_TAG_DSA=y
CONFIG_NET_DSA_TAG_EDSA=y
CONFIG_NET_DSA_TAG_TRAILER=y
# CONFIG_VLAN_8021Q is not set
# CONFIG_DECNET is not set
CONFIG_LLC=y
CONFIG_LLC2=y
CONFIG_IPX=y
CONFIG_IPX_INTERN=y
# CONFIG_ATALK is not set
CONFIG_X25=y
# CONFIG_LAPB is not set
# CONFIG_WAN_ROUTER is not set
CONFIG_PHONET=y
# CONFIG_IEEE802154 is not set
CONFIG_NET_SCHED=y

#
# Queueing/Scheduling
#
# CONFIG_NET_SCH_CBQ is not set
CONFIG_NET_SCH_HTB=y
CONFIG_NET_SCH_HFSC=y
CONFIG_NET_SCH_ATM=y
# CONFIG_NET_SCH_PRIO is not set
# CONFIG_NET_SCH_MULTIQ is not set
CONFIG_NET_SCH_RED=y
CONFIG_NET_SCH_SFB=y
CONFIG_NET_SCH_SFQ=y
# CONFIG_NET_SCH_TEQL is not set
CONFIG_NET_SCH_TBF=y
# CONFIG_NET_SCH_GRED is not set
# CONFIG_NET_SCH_DSMARK is not set
# CONFIG_NET_SCH_NETEM is not set
CONFIG_NET_SCH_DRR=y
# CONFIG_NET_SCH_MQPRIO is not set
# CONFIG_NET_SCH_CHOKE is not set
CONFIG_NET_SCH_QFQ=y

#
# Classification
#
CONFIG_NET_CLS=y
# CONFIG_NET_CLS_BASIC is not set
# CONFIG_NET_CLS_TCINDEX is not set
CONFIG_NET_CLS_FW=y
# CONFIG_NET_CLS_U32 is not set
# CONFIG_NET_CLS_RSVP is not set
# CONFIG_NET_CLS_RSVP6 is not set
CONFIG_NET_CLS_FLOW=y
CONFIG_NET_CLS_CGROUP=y
CONFIG_NET_EMATCH=y
CONFIG_NET_EMATCH_STACK=32
# CONFIG_NET_EMATCH_CMP is not set
CONFIG_NET_EMATCH_NBYTE=y
# CONFIG_NET_EMATCH_U32 is not set
CONFIG_NET_EMATCH_META=y
CONFIG_NET_EMATCH_TEXT=y
# CONFIG_NET_CLS_ACT is not set
CONFIG_NET_CLS_IND=y
CONFIG_NET_SCH_FIFO=y
# CONFIG_DCB is not set
# CONFIG_DNS_RESOLVER is not set
# CONFIG_BATMAN_ADV is not set
CONFIG_OPENVSWITCH=y
CONFIG_NETPRIO_CGROUP=y
CONFIG_BQL=y
CONFIG_HAVE_BPF_JIT=y

#
# Network testing
#
CONFIG_NET_PKTGEN=y
# CONFIG_HAMRADIO is not set
# CONFIG_CAN is not set
CONFIG_IRDA=y

#
# IrDA protocols
#
CONFIG_IRLAN=y
# CONFIG_IRCOMM is not set
CONFIG_IRDA_ULTRA=y

#
# IrDA options
#
# CONFIG_IRDA_CACHE_LAST_LSAP is not set
# CONFIG_IRDA_FAST_RR is not set
CONFIG_IRDA_DEBUG=y

#
# Infrared-port device drivers
#

#
# SIR device drivers
#
# CONFIG_IRTTY_SIR is not set

#
# Dongle support
#

#
# FIR device drivers
#
# CONFIG_NSC_FIR is not set
# CONFIG_WINBOND_FIR is not set
CONFIG_SMC_IRCC_FIR=y
CONFIG_ALI_FIR=y
CONFIG_VLSI_FIR=y
# CONFIG_VIA_FIR is not set
# CONFIG_BT is not set
CONFIG_WIRELESS=y
CONFIG_WIRELESS_EXT=y
CONFIG_WEXT_CORE=y
CONFIG_WEXT_PROC=y
CONFIG_WEXT_SPY=y
CONFIG_WEXT_PRIV=y
# CONFIG_CFG80211 is not set
CONFIG_WIRELESS_EXT_SYSFS=y
# CONFIG_LIB80211 is not set

#
# CFG80211 needs to be enabled for MAC80211
#
CONFIG_WIMAX=y
CONFIG_WIMAX_DEBUG_LEVEL=8
# CONFIG_RFKILL is not set
CONFIG_RFKILL_REGULATOR=y
CONFIG_NET_9P=y
# CONFIG_NET_9P_VIRTIO is not set
CONFIG_NET_9P_DEBUG=y
# CONFIG_CAIF is not set
# CONFIG_NFC is not set

#
# Device Drivers
#

#
# Generic Driver Options
#
CONFIG_UEVENT_HELPER_PATH=""
# CONFIG_DEVTMPFS is not set
CONFIG_STANDALONE=y
CONFIG_PREVENT_FIRMWARE_BUILD=y
CONFIG_FW_LOADER=y
CONFIG_FIRMWARE_IN_KERNEL=y
CONFIG_EXTRA_FIRMWARE=""
# CONFIG_DEBUG_DRIVER is not set
# CONFIG_DEBUG_DEVRES is not set
CONFIG_SYS_HYPERVISOR=y
CONFIG_REGMAP=y
CONFIG_REGMAP_I2C=y
CONFIG_REGMAP_SPI=y
CONFIG_REGMAP_IRQ=y
CONFIG_CONNECTOR=y
# CONFIG_PROC_EVENTS is not set
CONFIG_MTD=y
# CONFIG_MTD_REDBOOT_PARTS is not set
CONFIG_MTD_CMDLINE_PARTS=y
# CONFIG_MTD_AR7_PARTS is not set

#
# User Modules And Translation Layers
#
# CONFIG_MTD_CHAR is not set
CONFIG_HAVE_MTD_OTP=y
CONFIG_MTD_BLKDEVS=y
CONFIG_MTD_BLOCK=y
CONFIG_FTL=y
CONFIG_NFTL=y
# CONFIG_NFTL_RW is not set
CONFIG_INFTL=y
CONFIG_RFD_FTL=y
CONFIG_SSFDC=y
# CONFIG_SM_FTL is not set
CONFIG_MTD_OOPS=y
CONFIG_MTD_SWAP=y

#
# RAM/ROM/Flash chip drivers
#
CONFIG_MTD_CFI=y
CONFIG_MTD_JEDECPROBE=y
CONFIG_MTD_GEN_PROBE=y
CONFIG_MTD_CFI_ADV_OPTIONS=y
# CONFIG_MTD_CFI_NOSWAP is not set
CONFIG_MTD_CFI_BE_BYTE_SWAP=y
# CONFIG_MTD_CFI_LE_BYTE_SWAP is not set
CONFIG_MTD_CFI_GEOMETRY=y
# CONFIG_MTD_MAP_BANK_WIDTH_1 is not set
CONFIG_MTD_MAP_BANK_WIDTH_2=y
# CONFIG_MTD_MAP_BANK_WIDTH_4 is not set
# CONFIG_MTD_MAP_BANK_WIDTH_8 is not set
CONFIG_MTD_MAP_BANK_WIDTH_16=y
# CONFIG_MTD_MAP_BANK_WIDTH_32 is not set
CONFIG_MTD_CFI_I1=y
CONFIG_MTD_CFI_I2=y
CONFIG_MTD_CFI_I4=y
# CONFIG_MTD_CFI_I8 is not set
CONFIG_MTD_OTP=y
CONFIG_MTD_CFI_INTELEXT=y
CONFIG_MTD_CFI_AMDSTD=y
# CONFIG_MTD_CFI_STAA is not set
CONFIG_MTD_CFI_UTIL=y
CONFIG_MTD_RAM=y
CONFIG_MTD_ROM=y
CONFIG_MTD_ABSENT=y

#
# Mapping drivers for chip access
#
CONFIG_MTD_COMPLEX_MAPPINGS=y
# CONFIG_MTD_PHYSMAP is not set
CONFIG_MTD_SC520CDP=y
# CONFIG_MTD_NETSC520 is not set
CONFIG_MTD_TS5500=y
CONFIG_MTD_SBC_GXX=y
# CONFIG_MTD_AMD76XROM is not set
CONFIG_MTD_ICHXROM=y
# CONFIG_MTD_ESB2ROM is not set
CONFIG_MTD_CK804XROM=y
CONFIG_MTD_SCB2_FLASH=y
# CONFIG_MTD_NETtel is not set
CONFIG_MTD_L440GX=y
# CONFIG_MTD_PCI is not set
CONFIG_MTD_GPIO_ADDR=y
# CONFIG_MTD_INTEL_VR_NOR is not set
CONFIG_MTD_PLATRAM=y
CONFIG_MTD_LATCH_ADDR=y

#
# Self-contained MTD device drivers
#
# CONFIG_MTD_PMC551 is not set
CONFIG_MTD_DATAFLASH=y
# CONFIG_MTD_DATAFLASH_WRITE_VERIFY is not set
# CONFIG_MTD_DATAFLASH_OTP is not set
# CONFIG_MTD_M25P80 is not set
# CONFIG_MTD_SST25L is not set
CONFIG_MTD_SLRAM=y
# CONFIG_MTD_PHRAM is not set
# CONFIG_MTD_MTDRAM is not set
# CONFIG_MTD_BLOCK2MTD is not set

#
# Disk-On-Chip Device Drivers
#
CONFIG_MTD_DOC2000=y
CONFIG_MTD_DOC2001=y
CONFIG_MTD_DOC2001PLUS=y
CONFIG_MTD_DOCG3=y
CONFIG_BCH_CONST_M=14
CONFIG_BCH_CONST_T=4
CONFIG_MTD_DOCPROBE=y
CONFIG_MTD_DOCECC=y
# CONFIG_MTD_DOCPROBE_ADVANCED is not set
CONFIG_MTD_DOCPROBE_ADDRESS=0x0
CONFIG_MTD_NAND_ECC=y
# CONFIG_MTD_NAND_ECC_SMC is not set
CONFIG_MTD_NAND=y
CONFIG_MTD_NAND_VERIFY_WRITE=y
CONFIG_MTD_NAND_BCH=y
CONFIG_MTD_NAND_ECC_BCH=y
# CONFIG_MTD_SM_COMMON is not set
# CONFIG_MTD_NAND_MUSEUM_IDS is not set
CONFIG_MTD_NAND_DENALI=y
CONFIG_MTD_NAND_DENALI_SCRATCH_REG_ADDR=0xFF108018
CONFIG_MTD_NAND_IDS=y
# CONFIG_MTD_NAND_RICOH is not set
# CONFIG_MTD_NAND_DISKONCHIP is not set
# CONFIG_MTD_NAND_CAFE is not set
CONFIG_MTD_NAND_NANDSIM=y
CONFIG_MTD_NAND_PLATFORM=y
CONFIG_MTD_ONENAND=y
# CONFIG_MTD_ONENAND_VERIFY_WRITE is not set
CONFIG_MTD_ONENAND_GENERIC=y
CONFIG_MTD_ONENAND_OTP=y
CONFIG_MTD_ONENAND_2X_PROGRAM=y
# CONFIG_MTD_ONENAND_SIM is not set

#
# LPDDR flash memory drivers
#
CONFIG_MTD_LPDDR=y
CONFIG_MTD_QINFO_PROBE=y
CONFIG_MTD_UBI=y
CONFIG_MTD_UBI_WL_THRESHOLD=4096
CONFIG_MTD_UBI_BEB_RESERVE=1
CONFIG_MTD_UBI_GLUEBI=y
# CONFIG_MTD_UBI_DEBUG is not set
# CONFIG_PARPORT is not set
CONFIG_PNP=y
# CONFIG_PNP_DEBUG_MESSAGES is not set

#
# Protocols
#
CONFIG_PNPACPI=y
CONFIG_BLK_DEV=y
# CONFIG_BLK_DEV_FD is not set
# CONFIG_BLK_CPQ_DA is not set
# CONFIG_BLK_CPQ_CISS_DA is not set
# CONFIG_BLK_DEV_DAC960 is not set
CONFIG_BLK_DEV_UMEM=y
# CONFIG_BLK_DEV_COW_COMMON is not set
# CONFIG_BLK_DEV_LOOP is not set

#
# DRBD disabled because PROC_FS, INET or CONNECTOR not selected
#
CONFIG_BLK_DEV_NBD=y
CONFIG_BLK_DEV_OSD=y
CONFIG_BLK_DEV_SX8=y
# CONFIG_BLK_DEV_RAM is not set
CONFIG_CDROM_PKTCDVD=y
CONFIG_CDROM_PKTCDVD_BUFFERS=8
CONFIG_CDROM_PKTCDVD_WCACHE=y
# CONFIG_ATA_OVER_ETH is not set
CONFIG_XEN_BLKDEV_FRONTEND=y
# CONFIG_XEN_BLKDEV_BACKEND is not set
# CONFIG_VIRTIO_BLK is not set
CONFIG_BLK_DEV_HD=y
# CONFIG_SENSORS_LIS3LV02D is not set
# CONFIG_MISC_DEVICES is not set
CONFIG_HAVE_IDE=y
CONFIG_IDE=y

#
# Please see Documentation/ide/ide.txt for help/info on IDE drives
#
CONFIG_IDE_XFER_MODE=y
CONFIG_IDE_TIMINGS=y
CONFIG_BLK_DEV_IDE_SATA=y
# CONFIG_IDE_GD is not set
CONFIG_BLK_DEV_DELKIN=y
# CONFIG_BLK_DEV_IDECD is not set
# CONFIG_BLK_DEV_IDETAPE is not set
CONFIG_BLK_DEV_IDEACPI=y
# CONFIG_IDE_TASK_IOCTL is not set
# CONFIG_IDE_PROC_FS is not set

#
# IDE chipset support/bugfixes
#
# CONFIG_IDE_GENERIC is not set
# CONFIG_BLK_DEV_PLATFORM is not set
# CONFIG_BLK_DEV_CMD640 is not set
# CONFIG_BLK_DEV_IDEPNP is not set
CONFIG_BLK_DEV_IDEDMA_SFF=y

#
# PCI IDE chipsets support
#
CONFIG_BLK_DEV_IDEPCI=y
CONFIG_IDEPCI_PCIBUS_ORDER=y
# CONFIG_BLK_DEV_OFFBOARD is not set
# CONFIG_BLK_DEV_GENERIC is not set
# CONFIG_BLK_DEV_OPTI621 is not set
# CONFIG_BLK_DEV_RZ1000 is not set
CONFIG_BLK_DEV_IDEDMA_PCI=y
CONFIG_BLK_DEV_AEC62XX=y
# CONFIG_BLK_DEV_ALI15X3 is not set
# CONFIG_BLK_DEV_AMD74XX is not set
CONFIG_BLK_DEV_ATIIXP=y
CONFIG_BLK_DEV_CMD64X=y
CONFIG_BLK_DEV_TRIFLEX=y
# CONFIG_BLK_DEV_CS5520 is not set
CONFIG_BLK_DEV_CS5530=y
CONFIG_BLK_DEV_HPT366=y
# CONFIG_BLK_DEV_JMICRON is not set
# CONFIG_BLK_DEV_SC1200 is not set
# CONFIG_BLK_DEV_PIIX is not set
CONFIG_BLK_DEV_IT8172=y
CONFIG_BLK_DEV_IT8213=y
# CONFIG_BLK_DEV_IT821X is not set
# CONFIG_BLK_DEV_NS87415 is not set
# CONFIG_BLK_DEV_PDC202XX_OLD is not set
CONFIG_BLK_DEV_PDC202XX_NEW=y
CONFIG_BLK_DEV_SVWKS=y
# CONFIG_BLK_DEV_SIIMAGE is not set
# CONFIG_BLK_DEV_SIS5513 is not set
# CONFIG_BLK_DEV_SLC90E66 is not set
# CONFIG_BLK_DEV_TRM290 is not set
# CONFIG_BLK_DEV_VIA82CXXX is not set
# CONFIG_BLK_DEV_TC86C001 is not set
CONFIG_BLK_DEV_IDEDMA=y

#
# SCSI device support
#
CONFIG_SCSI_MOD=y
CONFIG_RAID_ATTRS=y
CONFIG_SCSI=y
CONFIG_SCSI_DMA=y
# CONFIG_SCSI_TGT is not set
CONFIG_SCSI_NETLINK=y
# CONFIG_SCSI_PROC_FS is not set

#
# SCSI support type (disk, tape, CD-ROM)
#
# CONFIG_BLK_DEV_SD is not set
# CONFIG_CHR_DEV_ST is not set
# CONFIG_CHR_DEV_OSST is not set
# CONFIG_BLK_DEV_SR is not set
CONFIG_CHR_DEV_SG=y
# CONFIG_CHR_DEV_SCH is not set
# CONFIG_SCSI_MULTI_LUN is not set
# CONFIG_SCSI_CONSTANTS is not set
# CONFIG_SCSI_LOGGING is not set
# CONFIG_SCSI_SCAN_ASYNC is not set

#
# SCSI Transports
#
CONFIG_SCSI_SPI_ATTRS=y
CONFIG_SCSI_FC_ATTRS=y
CONFIG_SCSI_ISCSI_ATTRS=y
CONFIG_SCSI_SAS_ATTRS=y
CONFIG_SCSI_SAS_LIBSAS=y
CONFIG_SCSI_SAS_HOST_SMP=y
CONFIG_SCSI_SRP_ATTRS=y
CONFIG_SCSI_LOWLEVEL=y
CONFIG_ISCSI_BOOT_SYSFS=y
# CONFIG_SCSI_BNX2_ISCSI is not set
CONFIG_SCSI_BNX2X_FCOE=y
CONFIG_BE2ISCSI=y
# CONFIG_BLK_DEV_3W_XXXX_RAID is not set
CONFIG_SCSI_HPSA=y
CONFIG_SCSI_3W_9XXX=y
CONFIG_SCSI_3W_SAS=y
# CONFIG_SCSI_ACARD is not set
CONFIG_SCSI_AACRAID=y
# CONFIG_SCSI_AIC7XXX is not set
CONFIG_SCSI_AIC7XXX_OLD=y
CONFIG_SCSI_AIC79XX=y
CONFIG_AIC79XX_CMDS_PER_DEVICE=32
CONFIG_AIC79XX_RESET_DELAY_MS=5000
CONFIG_AIC79XX_DEBUG_ENABLE=y
CONFIG_AIC79XX_DEBUG_MASK=0
CONFIG_AIC79XX_REG_PRETTY_PRINT=y
CONFIG_SCSI_AIC94XX=y
CONFIG_AIC94XX_DEBUG=y
CONFIG_SCSI_MVSAS=y
# CONFIG_SCSI_MVSAS_DEBUG is not set
CONFIG_SCSI_MVSAS_TASKLET=y
CONFIG_SCSI_MVUMI=y
CONFIG_SCSI_DPT_I2O=y
CONFIG_SCSI_ADVANSYS=y
CONFIG_SCSI_ARCMSR=y
CONFIG_MEGARAID_NEWGEN=y
CONFIG_MEGARAID_MM=y
# CONFIG_MEGARAID_MAILBOX is not set
# CONFIG_MEGARAID_LEGACY is not set
# CONFIG_MEGARAID_SAS is not set
CONFIG_SCSI_MPT2SAS=y
CONFIG_SCSI_MPT2SAS_MAX_SGE=128
CONFIG_SCSI_MPT2SAS_LOGGING=y
# CONFIG_SCSI_HPTIOP is not set
# CONFIG_SCSI_BUSLOGIC is not set
# CONFIG_VMWARE_PVSCSI is not set
CONFIG_LIBFC=y
CONFIG_LIBFCOE=y
CONFIG_FCOE=y
CONFIG_FCOE_FNIC=y
# CONFIG_SCSI_DMX3191D is not set
CONFIG_SCSI_EATA=y
# CONFIG_SCSI_EATA_TAGGED_QUEUE is not set
CONFIG_SCSI_EATA_LINKED_COMMANDS=y
CONFIG_SCSI_EATA_MAX_TAGS=16
CONFIG_SCSI_FUTURE_DOMAIN=y
# CONFIG_SCSI_GDTH is not set
CONFIG_SCSI_ISCI=y
# CONFIG_SCSI_IPS is not set
CONFIG_SCSI_INITIO=y
# CONFIG_SCSI_INIA100 is not set
# CONFIG_SCSI_STEX is not set
CONFIG_SCSI_SYM53C8XX_2=y
CONFIG_SCSI_SYM53C8XX_DMA_ADDRESSING_MODE=1
CONFIG_SCSI_SYM53C8XX_DEFAULT_TAGS=16
CONFIG_SCSI_SYM53C8XX_MAX_TAGS=64
# CONFIG_SCSI_SYM53C8XX_MMIO is not set
# CONFIG_SCSI_QLOGIC_1280 is not set
CONFIG_SCSI_QLA_FC=y
# CONFIG_SCSI_QLA_ISCSI is not set
CONFIG_SCSI_LPFC=y
# CONFIG_SCSI_LPFC_DEBUG_FS is not set
# CONFIG_SCSI_DC395x is not set
# CONFIG_SCSI_DC390T is not set
# CONFIG_SCSI_DEBUG is not set
CONFIG_SCSI_PMCRAID=y
# CONFIG_SCSI_PM8001 is not set
# CONFIG_SCSI_SRP is not set
CONFIG_SCSI_BFA_FC=y
CONFIG_SCSI_DH=y
# CONFIG_SCSI_DH_RDAC is not set
# CONFIG_SCSI_DH_HP_SW is not set
# CONFIG_SCSI_DH_EMC is not set
# CONFIG_SCSI_DH_ALUA is not set
CONFIG_SCSI_OSD_INITIATOR=y
CONFIG_SCSI_OSD_ULD=y
CONFIG_SCSI_OSD_DPRINT_SENSE=1
# CONFIG_SCSI_OSD_DEBUG is not set
# CONFIG_ATA is not set
CONFIG_MD=y
# CONFIG_BLK_DEV_MD is not set
# CONFIG_BLK_DEV_DM is not set
CONFIG_TARGET_CORE=y
CONFIG_TCM_IBLOCK=y
# CONFIG_TCM_FILEIO is not set
CONFIG_TCM_PSCSI=y
CONFIG_LOOPBACK_TARGET=y
CONFIG_TCM_FC=y
CONFIG_ISCSI_TARGET=y
# CONFIG_FUSION is not set

#
# IEEE 1394 (FireWire) support
#
CONFIG_FIREWIRE=y
CONFIG_FIREWIRE_OHCI=y
CONFIG_FIREWIRE_OHCI_DEBUG=y
CONFIG_FIREWIRE_SBP2=y
# CONFIG_FIREWIRE_NOSY is not set
# CONFIG_I2O is not set
CONFIG_MACINTOSH_DRIVERS=y
# CONFIG_MAC_EMUMOUSEBTN is not set
CONFIG_NETDEVICES=y
CONFIG_NET_CORE=y
# CONFIG_DUMMY is not set
# CONFIG_EQUALIZER is not set
# CONFIG_NET_FC is not set
CONFIG_MII=y
# CONFIG_NET_TEAM is not set
CONFIG_MACVLAN=y
CONFIG_MACVTAP=y
# CONFIG_NETCONSOLE is not set
# CONFIG_NETPOLL is not set
# CONFIG_NET_POLL_CONTROLLER is not set
# CONFIG_RIONET is not set
CONFIG_TUN=y
# CONFIG_VETH is not set
CONFIG_VIRTIO_NET=y
# CONFIG_ARCNET is not set
# CONFIG_ATM_DRIVERS is not set

#
# CAIF transport drivers
#

#
# Distributed Switch Architecture drivers
#
CONFIG_NET_DSA_MV88E6XXX=y
CONFIG_NET_DSA_MV88E6060=y
CONFIG_NET_DSA_MV88E6XXX_NEED_PPU=y
CONFIG_NET_DSA_MV88E6131=y
CONFIG_NET_DSA_MV88E6123_61_65=y
CONFIG_ETHERNET=y
CONFIG_MDIO=y
# CONFIG_NET_VENDOR_3COM is not set
# CONFIG_NET_VENDOR_ADAPTEC is not set
# CONFIG_NET_VENDOR_ALTEON is not set
CONFIG_NET_VENDOR_AMD=y
# CONFIG_AMD8111_ETH is not set
# CONFIG_PCNET32 is not set
CONFIG_NET_VENDOR_ATHEROS=y
# CONFIG_ATL2 is not set
CONFIG_ATL1=y
CONFIG_ATL1E=y
# CONFIG_ATL1C is not set
CONFIG_NET_VENDOR_BROADCOM=y
# CONFIG_B44 is not set
CONFIG_BNX2=y
CONFIG_CNIC=y
# CONFIG_TIGON3 is not set
CONFIG_BNX2X=y
# CONFIG_NET_VENDOR_BROCADE is not set
CONFIG_NET_CALXEDA_XGMAC=y
CONFIG_NET_VENDOR_CHELSIO=y
# CONFIG_CHELSIO_T1 is not set
# CONFIG_CHELSIO_T4 is not set
# CONFIG_CHELSIO_T4VF is not set
CONFIG_DNET=y
CONFIG_NET_VENDOR_DEC=y
CONFIG_NET_TULIP=y
# CONFIG_DE2104X is not set
CONFIG_TULIP=y
# CONFIG_TULIP_MWI is not set
CONFIG_TULIP_MMIO=y
CONFIG_TULIP_NAPI=y
# CONFIG_TULIP_NAPI_HW_MITIGATION is not set
# CONFIG_DE4X5 is not set
CONFIG_WINBOND_840=y
CONFIG_DM9102=y
CONFIG_ULI526X=y
# CONFIG_PCMCIA_XIRCOM is not set
# CONFIG_NET_VENDOR_DLINK is not set
# CONFIG_NET_VENDOR_EXAR is not set
CONFIG_NET_VENDOR_HP=y
CONFIG_HP100=y
# CONFIG_NET_VENDOR_INTEL is not set
# CONFIG_IP1000 is not set
CONFIG_JME=y
CONFIG_NET_VENDOR_MARVELL=y
# CONFIG_SKGE is not set
# CONFIG_SKY2 is not set
# CONFIG_NET_VENDOR_MICREL is not set
# CONFIG_NET_VENDOR_MICROCHIP is not set
# CONFIG_FEALNX is not set
# CONFIG_NET_VENDOR_NATSEMI is not set
# CONFIG_NET_VENDOR_NVIDIA is not set
CONFIG_NET_VENDOR_OKI=y
# CONFIG_PCH_GBE is not set
CONFIG_ETHOC=y
# CONFIG_NET_PACKET_ENGINE is not set
# CONFIG_NET_VENDOR_QLOGIC is not set
CONFIG_NET_VENDOR_REALTEK=y
CONFIG_8139CP=y
# CONFIG_8139TOO is not set
# CONFIG_R8169 is not set
# CONFIG_NET_VENDOR_RDC is not set
CONFIG_NET_VENDOR_SEEQ=y
CONFIG_SEEQ8005=y
CONFIG_NET_VENDOR_SILAN=y
# CONFIG_SC92031 is not set
# CONFIG_NET_VENDOR_SIS is not set
# CONFIG_NET_VENDOR_SMSC is not set
CONFIG_NET_VENDOR_STMICRO=y
CONFIG_STMMAC_ETH=y
CONFIG_STMMAC_DEBUG_FS=y
CONFIG_STMMAC_DA=y
CONFIG_STMMAC_RING=y
# CONFIG_STMMAC_CHAINED is not set
CONFIG_NET_VENDOR_SUN=y
CONFIG_HAPPYMEAL=y
# CONFIG_SUNGEM is not set
CONFIG_CASSINI=y
# CONFIG_NIU is not set
# CONFIG_NET_VENDOR_TEHUTI is not set
CONFIG_NET_VENDOR_TI=y
# CONFIG_TLAN is not set
CONFIG_NET_VENDOR_VIA=y
# CONFIG_VIA_RHINE is not set
# CONFIG_VIA_VELOCITY is not set
CONFIG_FDDI=y
# CONFIG_DEFXX is not set
CONFIG_SKFP=y
CONFIG_NET_SB1000=y
CONFIG_PHYLIB=y

#
# MII PHY device drivers
#
# CONFIG_MARVELL_PHY is not set
# CONFIG_DAVICOM_PHY is not set
CONFIG_QSEMI_PHY=y
CONFIG_LXT_PHY=y
CONFIG_CICADA_PHY=y
CONFIG_VITESSE_PHY=y
# CONFIG_SMSC_PHY is not set
CONFIG_BROADCOM_PHY=y
CONFIG_ICPLUS_PHY=y
CONFIG_REALTEK_PHY=y
# CONFIG_NATIONAL_PHY is not set
# CONFIG_STE10XP is not set
CONFIG_LSI_ET1011C_PHY=y
# CONFIG_MICREL_PHY is not set
CONFIG_FIXED_PHY=y
CONFIG_MDIO_BITBANG=y
CONFIG_MDIO_GPIO=y
CONFIG_MICREL_KS8995MA=y
# CONFIG_PPP is not set
CONFIG_SLIP=y
# CONFIG_SLIP_COMPRESSED is not set
CONFIG_SLIP_SMART=y
CONFIG_SLIP_MODE_SLIP6=y
CONFIG_TR=y
# CONFIG_IBMOL is not set
CONFIG_3C359=y
# CONFIG_TMS380TR is not set
CONFIG_WLAN=y
# CONFIG_AIRO is not set
# CONFIG_ATMEL is not set
CONFIG_PRISM54=y
# CONFIG_HOSTAP is not set

#
# WiMAX Wireless Broadband devices
#

#
# Enable USB support to see WiMAX USB drivers
#

#
# Enable MMC support to see WiMAX SDIO drivers
#
CONFIG_WAN=y
CONFIG_LANMEDIA=y
CONFIG_HDLC=y
CONFIG_HDLC_RAW=y
# CONFIG_HDLC_RAW_ETH is not set
# CONFIG_HDLC_CISCO is not set
# CONFIG_HDLC_FR is not set
CONFIG_HDLC_PPP=y

#
# X.25/LAPB support is disabled
#
CONFIG_PCI200SYN=y
# CONFIG_WANXL is not set
CONFIG_PC300TOO=y
CONFIG_FARSYNC=y
CONFIG_DLCI=y
CONFIG_DLCI_MAX=8
# CONFIG_SBNI is not set
# CONFIG_XEN_NETDEV_FRONTEND is not set
CONFIG_XEN_NETDEV_BACKEND=y
CONFIG_ISDN=y
CONFIG_ISDN_I4L=y
# CONFIG_ISDN_AUDIO is not set
CONFIG_ISDN_X25=y

#
# ISDN feature submodules
#
# CONFIG_ISDN_DRV_LOOP is not set
# CONFIG_ISDN_DIVERSION is not set

#
# ISDN4Linux hardware drivers
#

#
# Passive cards
#
# CONFIG_ISDN_DRV_HISAX is not set

#
# Active cards
#
# CONFIG_ISDN_CAPI is not set
CONFIG_ISDN_DRV_GIGASET=y
CONFIG_GIGASET_I4L=y
# CONFIG_GIGASET_DUMMYLL is not set
CONFIG_GIGASET_M101=y
# CONFIG_GIGASET_DEBUG is not set
CONFIG_MISDN=y
CONFIG_MISDN_DSP=y
# CONFIG_MISDN_L1OIP is not set

#
# mISDN hardware drivers
#
CONFIG_MISDN_HFCPCI=y
# CONFIG_MISDN_HFCMULTI is not set
CONFIG_MISDN_AVMFRITZ=y
# CONFIG_MISDN_SPEEDFAX is not set
# CONFIG_MISDN_INFINEON is not set
CONFIG_MISDN_W6692=y
CONFIG_MISDN_NETJET=y
CONFIG_MISDN_IPAC=y
CONFIG_ISDN_HDLC=y
# CONFIG_PHONE is not set

#
# Input device support
#
CONFIG_INPUT=y
# CONFIG_INPUT_FF_MEMLESS is not set
CONFIG_INPUT_POLLDEV=y
CONFIG_INPUT_SPARSEKMAP=y

#
# Userland interfaces
#
CONFIG_INPUT_MOUSEDEV=y
CONFIG_INPUT_MOUSEDEV_PSAUX=y
CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024
CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768
CONFIG_INPUT_JOYDEV=y
# CONFIG_INPUT_EVDEV is not set
CONFIG_INPUT_EVBUG=y

#
# Input Device Drivers
#
CONFIG_INPUT_KEYBOARD=y
# CONFIG_KEYBOARD_ADP5588 is not set
CONFIG_KEYBOARD_ADP5589=y
CONFIG_KEYBOARD_ATKBD=y
CONFIG_KEYBOARD_QT1070=y
# CONFIG_KEYBOARD_QT2160 is not set
CONFIG_KEYBOARD_LKKBD=y
# CONFIG_KEYBOARD_GPIO is not set
# CONFIG_KEYBOARD_GPIO_POLLED is not set
CONFIG_KEYBOARD_TCA6416=y
# CONFIG_KEYBOARD_TCA8418 is not set
CONFIG_KEYBOARD_MATRIX=y
CONFIG_KEYBOARD_LM8323=y
# CONFIG_KEYBOARD_MAX7359 is not set
CONFIG_KEYBOARD_MCS=y
CONFIG_KEYBOARD_MPR121=y
CONFIG_KEYBOARD_NEWTON=y
CONFIG_KEYBOARD_OPENCORES=y
# CONFIG_KEYBOARD_STOWAWAY is not set
CONFIG_KEYBOARD_SUNKBD=y
# CONFIG_KEYBOARD_TC3589X is not set
CONFIG_KEYBOARD_XTKBD=y
CONFIG_INPUT_MOUSE=y
CONFIG_MOUSE_PS2=y
CONFIG_MOUSE_PS2_ALPS=y
CONFIG_MOUSE_PS2_LOGIPS2PP=y
CONFIG_MOUSE_PS2_SYNAPTICS=y
CONFIG_MOUSE_PS2_LIFEBOOK=y
CONFIG_MOUSE_PS2_TRACKPOINT=y
CONFIG_MOUSE_PS2_ELANTECH=y
# CONFIG_MOUSE_PS2_SENTELIC is not set
# CONFIG_MOUSE_PS2_TOUCHKIT is not set
CONFIG_MOUSE_SERIAL=y
CONFIG_MOUSE_VSXXXAA=y
# CONFIG_MOUSE_GPIO is not set
CONFIG_MOUSE_SYNAPTICS_I2C=y
# CONFIG_INPUT_JOYSTICK is not set
CONFIG_INPUT_TABLET=y
# CONFIG_INPUT_TOUCHSCREEN is not set
CONFIG_INPUT_MISC=y
CONFIG_INPUT_88PM860X_ONKEY=y
# CONFIG_INPUT_AD714X is not set
CONFIG_INPUT_BMA150=y
# CONFIG_INPUT_PCSPKR is not set
# CONFIG_INPUT_MMA8450 is not set
CONFIG_INPUT_MPU3050=y
# CONFIG_INPUT_APANEL is not set
# CONFIG_INPUT_GP2A is not set
CONFIG_INPUT_GPIO_TILT_POLLED=y
CONFIG_INPUT_ATLAS_BTNS=y
# CONFIG_INPUT_KXTJ9 is not set
# CONFIG_INPUT_UINPUT is not set
# CONFIG_INPUT_PCF8574 is not set
CONFIG_INPUT_GPIO_ROTARY_ENCODER=y
# CONFIG_INPUT_WM831X_ON is not set
# CONFIG_INPUT_PCAP is not set
CONFIG_INPUT_ADXL34X=y
CONFIG_INPUT_ADXL34X_I2C=y
CONFIG_INPUT_ADXL34X_SPI=y
# CONFIG_INPUT_CMA3000 is not set

#
# Hardware I/O ports
#
CONFIG_SERIO=y
CONFIG_SERIO_I8042=y
CONFIG_SERIO_SERPORT=y
CONFIG_SERIO_CT82C710=y
CONFIG_SERIO_PCIPS2=y
CONFIG_SERIO_LIBPS2=y
# CONFIG_SERIO_RAW is not set
CONFIG_SERIO_ALTERA_PS2=y
# CONFIG_SERIO_PS2MULT is not set
CONFIG_GAMEPORT=y
# CONFIG_GAMEPORT_NS558 is not set
CONFIG_GAMEPORT_L4=y
CONFIG_GAMEPORT_EMU10K1=y
# CONFIG_GAMEPORT_FM801 is not set

#
# Character devices
#
CONFIG_VT=y
CONFIG_CONSOLE_TRANSLATIONS=y
CONFIG_VT_CONSOLE=y
CONFIG_VT_CONSOLE_SLEEP=y
CONFIG_HW_CONSOLE=y
# CONFIG_VT_HW_CONSOLE_BINDING is not set
CONFIG_UNIX98_PTYS=y
CONFIG_DEVPTS_MULTIPLE_INSTANCES=y
CONFIG_LEGACY_PTYS=y
CONFIG_LEGACY_PTY_COUNT=256
CONFIG_SERIAL_NONSTANDARD=y
# CONFIG_ROCKETPORT is not set
# CONFIG_CYCLADES is not set
CONFIG_MOXA_INTELLIO=y
# CONFIG_MOXA_SMARTIO is not set
CONFIG_SYNCLINK=y
# CONFIG_SYNCLINKMP is not set
# CONFIG_SYNCLINK_GT is not set
CONFIG_NOZOMI=y
# CONFIG_ISI is not set
# CONFIG_N_HDLC is not set
# CONFIG_N_GSM is not set
# CONFIG_TRACE_ROUTER is not set
CONFIG_TRACE_SINK=y
# CONFIG_DEVKMEM is not set
# CONFIG_STALDRV is not set

#
# Serial drivers
#
CONFIG_SERIAL_8250=y
# CONFIG_SERIAL_8250_CONSOLE is not set
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_SERIAL_8250_PCI=y
CONFIG_SERIAL_8250_PNP=y
CONFIG_SERIAL_8250_NR_UARTS=4
CONFIG_SERIAL_8250_RUNTIME_UARTS=4
# CONFIG_SERIAL_8250_EXTENDED is not set

#
# Non-8250 serial port support
#
CONFIG_SERIAL_MAX3100=y
# CONFIG_SERIAL_MAX3107 is not set
# CONFIG_SERIAL_MFD_HSU is not set
# CONFIG_SERIAL_UARTLITE is not set
CONFIG_SERIAL_CORE=y
CONFIG_SERIAL_CORE_CONSOLE=y
CONFIG_CONSOLE_POLL=y
# CONFIG_SERIAL_JSM is not set
CONFIG_SERIAL_TIMBERDALE=y
# CONFIG_SERIAL_ALTERA_JTAGUART is not set
CONFIG_SERIAL_ALTERA_UART=y
CONFIG_SERIAL_ALTERA_UART_MAXPORTS=4
CONFIG_SERIAL_ALTERA_UART_BAUDRATE=115200
# CONFIG_SERIAL_ALTERA_UART_CONSOLE is not set
CONFIG_SERIAL_IFX6X60=y
CONFIG_SERIAL_PCH_UART=y
# CONFIG_SERIAL_PCH_UART_CONSOLE is not set
CONFIG_SERIAL_XILINX_PS_UART=y
CONFIG_SERIAL_XILINX_PS_UART_CONSOLE=y
CONFIG_HVC_DRIVER=y
CONFIG_HVC_IRQ=y
CONFIG_HVC_XEN=y
# CONFIG_VIRTIO_CONSOLE is not set
# CONFIG_IPMI_HANDLER is not set
CONFIG_HW_RANDOM=y
CONFIG_HW_RANDOM_TIMERIOMEM=y
# CONFIG_HW_RANDOM_INTEL is not set
CONFIG_HW_RANDOM_AMD=y
# CONFIG_HW_RANDOM_VIA is not set
# CONFIG_HW_RANDOM_VIRTIO is not set
CONFIG_NVRAM=y
CONFIG_R3964=y
# CONFIG_APPLICOM is not set
CONFIG_MWAVE=y
# CONFIG_RAW_DRIVER is not set
# CONFIG_HPET is not set
# CONFIG_HANGCHECK_TIMER is not set
# CONFIG_TCG_TPM is not set
CONFIG_TELCLOCK=y
CONFIG_DEVPORT=y
CONFIG_RAMOOPS=y
CONFIG_I2C=y
CONFIG_I2C_BOARDINFO=y
# CONFIG_I2C_COMPAT is not set
# CONFIG_I2C_CHARDEV is not set
# CONFIG_I2C_MUX is not set
CONFIG_I2C_HELPER_AUTO=y
CONFIG_I2C_SMBUS=y
CONFIG_I2C_ALGOBIT=y

#
# I2C Hardware Bus support
#

#
# PC SMBus host controller drivers
#
CONFIG_I2C_ALI1535=y
# CONFIG_I2C_ALI1563 is not set
CONFIG_I2C_ALI15X3=y
CONFIG_I2C_AMD756=y
# CONFIG_I2C_AMD756_S4882 is not set
# CONFIG_I2C_AMD8111 is not set
# CONFIG_I2C_I801 is not set
# CONFIG_I2C_ISCH is not set
# CONFIG_I2C_PIIX4 is not set
CONFIG_I2C_NFORCE2=y
# CONFIG_I2C_NFORCE2_S4985 is not set
# CONFIG_I2C_SIS5595 is not set
CONFIG_I2C_SIS630=y
# CONFIG_I2C_SIS96X is not set
CONFIG_I2C_VIA=y
CONFIG_I2C_VIAPRO=y

#
# ACPI drivers
#
CONFIG_I2C_SCMI=y

#
# I2C system bus drivers (mostly embedded / system-on-chip)
#
# CONFIG_I2C_DESIGNWARE_PCI is not set
CONFIG_I2C_GPIO=y
CONFIG_I2C_INTEL_MID=y
# CONFIG_I2C_OCORES is not set
# CONFIG_I2C_PCA_PLATFORM is not set
# CONFIG_I2C_PXA_PCI is not set
# CONFIG_I2C_SIMTEC is not set
CONFIG_I2C_XILINX=y
# CONFIG_I2C_EG20T is not set

#
# External I2C/SMBus adapter drivers
#
CONFIG_I2C_PARPORT_LIGHT=y
CONFIG_I2C_TAOS_EVM=y

#
# Other I2C/SMBus bus drivers
#
CONFIG_I2C_DEBUG_CORE=y
# CONFIG_I2C_DEBUG_ALGO is not set
CONFIG_I2C_DEBUG_BUS=y
CONFIG_SPI=y
CONFIG_SPI_DEBUG=y
CONFIG_SPI_MASTER=y

#
# SPI Master Controller Drivers
#
# CONFIG_SPI_ALTERA is not set
CONFIG_SPI_BITBANG=y
CONFIG_SPI_GPIO=y
# CONFIG_SPI_OC_TINY is not set
# CONFIG_SPI_PXA2XX_PCI is not set
CONFIG_SPI_TOPCLIFF_PCH=y
CONFIG_SPI_XILINX=y
# CONFIG_SPI_DESIGNWARE is not set

#
# SPI Protocol Masters
#
CONFIG_SPI_SPIDEV=y
CONFIG_SPI_TLE62X0=y
CONFIG_HSI=y
CONFIG_HSI_BOARDINFO=y

#
# HSI clients
#
# CONFIG_HSI_CHAR is not set

#
# PPS support
#
CONFIG_PPS=y
CONFIG_PPS_DEBUG=y

#
# PPS clients support
#
CONFIG_PPS_CLIENT_KTIMER=y
# CONFIG_PPS_CLIENT_LDISC is not set
# CONFIG_PPS_CLIENT_GPIO is not set

#
# PPS generators support
#

#
# PTP clock support
#
CONFIG_PTP_1588_CLOCK=y

#
# Enable PHYLIB and NETWORK_PHY_TIMESTAMPING to see the additional clocks.
#
CONFIG_ARCH_WANT_OPTIONAL_GPIOLIB=y
CONFIG_GPIOLIB=y
CONFIG_DEBUG_GPIO=y
CONFIG_GPIO_SYSFS=y
CONFIG_GPIO_MAX730X=y

#
# Memory mapped GPIO drivers:
#
# CONFIG_GPIO_GENERIC_PLATFORM is not set
CONFIG_GPIO_IT8761E=y
CONFIG_GPIO_SCH=y
CONFIG_GPIO_VX855=y

#
# I2C GPIO expanders:
#
CONFIG_GPIO_MAX7300=y
CONFIG_GPIO_MAX732X=y
# CONFIG_GPIO_MAX732X_IRQ is not set
CONFIG_GPIO_PCA953X=y
# CONFIG_GPIO_PCA953X_IRQ is not set
# CONFIG_GPIO_PCF857X is not set
# CONFIG_GPIO_SX150X is not set
CONFIG_GPIO_TC3589X=y
# CONFIG_GPIO_WM831X is not set
CONFIG_GPIO_WM8350=y
# CONFIG_GPIO_WM8994 is not set
CONFIG_GPIO_ADP5588=y
CONFIG_GPIO_ADP5588_IRQ=y

#
# PCI GPIO expanders:
#
# CONFIG_GPIO_BT8XX is not set
CONFIG_GPIO_LANGWELL=y
CONFIG_GPIO_PCH=y
CONFIG_GPIO_ML_IOH=y
CONFIG_GPIO_TIMBERDALE=y
CONFIG_GPIO_RDC321X=y

#
# SPI GPIO expanders:
#
# CONFIG_GPIO_MAX7301 is not set
# CONFIG_GPIO_MCP23S08 is not set
CONFIG_GPIO_MC33880=y
CONFIG_GPIO_74X164=y

#
# AC97 GPIO expanders:
#

#
# MODULbus GPIO expanders:
#
CONFIG_GPIO_TPS65910=y
# CONFIG_W1 is not set
CONFIG_POWER_SUPPLY=y
# CONFIG_POWER_SUPPLY_DEBUG is not set
CONFIG_PDA_POWER=y
# CONFIG_WM831X_BACKUP is not set
CONFIG_WM831X_POWER=y
# CONFIG_WM8350_POWER is not set
CONFIG_TEST_POWER=y
# CONFIG_BATTERY_DS2780 is not set
CONFIG_BATTERY_DS2782=y
CONFIG_BATTERY_BQ20Z75=y
# CONFIG_BATTERY_BQ27x00 is not set
CONFIG_BATTERY_MAX17040=y
# CONFIG_BATTERY_MAX17042 is not set
# CONFIG_CHARGER_MAX8903 is not set
CONFIG_CHARGER_GPIO=y
CONFIG_CHARGER_MAX8998=y
CONFIG_HWMON=y
CONFIG_HWMON_VID=y
CONFIG_HWMON_DEBUG_CHIP=y

#
# Native drivers
#
# CONFIG_SENSORS_ABITUGURU is not set
# CONFIG_SENSORS_ABITUGURU3 is not set
CONFIG_SENSORS_AD7314=y
CONFIG_SENSORS_AD7414=y
CONFIG_SENSORS_AD7418=y
CONFIG_SENSORS_ADCXX=y
# CONFIG_SENSORS_ADM1021 is not set
# CONFIG_SENSORS_ADM1025 is not set
CONFIG_SENSORS_ADM1026=y
CONFIG_SENSORS_ADM1029=y
CONFIG_SENSORS_ADM1031=y
# CONFIG_SENSORS_ADM9240 is not set
CONFIG_SENSORS_ADT7411=y
CONFIG_SENSORS_ADT7462=y
CONFIG_SENSORS_ADT7470=y
CONFIG_SENSORS_ADT7475=y
# CONFIG_SENSORS_ASC7621 is not set
# CONFIG_SENSORS_K8TEMP is not set
CONFIG_SENSORS_K10TEMP=y
# CONFIG_SENSORS_FAM15H_POWER is not set
CONFIG_SENSORS_ASB100=y
# CONFIG_SENSORS_ATXP1 is not set
CONFIG_SENSORS_DS620=y
CONFIG_SENSORS_DS1621=y
CONFIG_SENSORS_I5K_AMB=y
CONFIG_SENSORS_F71805F=y
# CONFIG_SENSORS_F71882FG is not set
CONFIG_SENSORS_F75375S=y
CONFIG_SENSORS_FSCHMD=y
CONFIG_SENSORS_G760A=y
# CONFIG_SENSORS_GL518SM is not set
# CONFIG_SENSORS_GL520SM is not set
CONFIG_SENSORS_GPIO_FAN=y
CONFIG_SENSORS_CORETEMP=y
CONFIG_SENSORS_IT87=y
CONFIG_SENSORS_JC42=y
CONFIG_SENSORS_LINEAGE=y
# CONFIG_SENSORS_LM63 is not set
# CONFIG_SENSORS_LM70 is not set
CONFIG_SENSORS_LM73=y
# CONFIG_SENSORS_LM75 is not set
CONFIG_SENSORS_LM77=y
CONFIG_SENSORS_LM78=y
CONFIG_SENSORS_LM80=y
# CONFIG_SENSORS_LM83 is not set
CONFIG_SENSORS_LM85=y
CONFIG_SENSORS_LM87=y
# CONFIG_SENSORS_LM90 is not set
# CONFIG_SENSORS_LM92 is not set
CONFIG_SENSORS_LM93=y
CONFIG_SENSORS_LTC4151=y
# CONFIG_SENSORS_LTC4215 is not set
CONFIG_SENSORS_LTC4245=y
# CONFIG_SENSORS_LTC4261 is not set
# CONFIG_SENSORS_LM95241 is not set
# CONFIG_SENSORS_LM95245 is not set
# CONFIG_SENSORS_MAX1111 is not set
# CONFIG_SENSORS_MAX16065 is not set
CONFIG_SENSORS_MAX1619=y
CONFIG_SENSORS_MAX1668=y
CONFIG_SENSORS_MAX6639=y
CONFIG_SENSORS_MAX6642=y
# CONFIG_SENSORS_MAX6650 is not set
# CONFIG_SENSORS_NTC_THERMISTOR is not set
CONFIG_SENSORS_PC87360=y
# CONFIG_SENSORS_PC87427 is not set
CONFIG_SENSORS_PCF8591=y
CONFIG_PMBUS=y
CONFIG_SENSORS_PMBUS=y
# CONFIG_SENSORS_ADM1275 is not set
# CONFIG_SENSORS_LM25066 is not set
# CONFIG_SENSORS_LTC2978 is not set
# CONFIG_SENSORS_MAX16064 is not set
# CONFIG_SENSORS_MAX34440 is not set
# CONFIG_SENSORS_MAX8688 is not set
# CONFIG_SENSORS_UCD9000 is not set
# CONFIG_SENSORS_UCD9200 is not set
CONFIG_SENSORS_ZL6100=y
# CONFIG_SENSORS_SHT15 is not set
# CONFIG_SENSORS_SHT21 is not set
CONFIG_SENSORS_SIS5595=y
# CONFIG_SENSORS_SMM665 is not set
CONFIG_SENSORS_DME1737=y
# CONFIG_SENSORS_EMC1403 is not set
# CONFIG_SENSORS_EMC2103 is not set
# CONFIG_SENSORS_EMC6W201 is not set
CONFIG_SENSORS_SMSC47M1=y
CONFIG_SENSORS_SMSC47M192=y
# CONFIG_SENSORS_SMSC47B397 is not set
# CONFIG_SENSORS_SCH56XX_COMMON is not set
# CONFIG_SENSORS_SCH5627 is not set
# CONFIG_SENSORS_SCH5636 is not set
# CONFIG_SENSORS_ADS1015 is not set
# CONFIG_SENSORS_ADS7828 is not set
CONFIG_SENSORS_ADS7871=y
CONFIG_SENSORS_AMC6821=y
# CONFIG_SENSORS_THMC50 is not set
# CONFIG_SENSORS_TMP102 is not set
# CONFIG_SENSORS_TMP401 is not set
CONFIG_SENSORS_TMP421=y
# CONFIG_SENSORS_VIA_CPUTEMP is not set
CONFIG_SENSORS_VIA686A=y
CONFIG_SENSORS_VT1211=y
# CONFIG_SENSORS_VT8231 is not set
CONFIG_SENSORS_W83781D=y
# CONFIG_SENSORS_W83791D is not set
# CONFIG_SENSORS_W83792D is not set
CONFIG_SENSORS_W83793=y
CONFIG_SENSORS_W83795=y
CONFIG_SENSORS_W83795_FANCTRL=y
CONFIG_SENSORS_W83L785TS=y
CONFIG_SENSORS_W83L786NG=y
CONFIG_SENSORS_W83627HF=y
# CONFIG_SENSORS_W83627EHF is not set
CONFIG_SENSORS_WM831X=y
CONFIG_SENSORS_WM8350=y
CONFIG_SENSORS_APPLESMC=y

#
# ACPI drivers
#
# CONFIG_SENSORS_ACPI_POWER is not set
CONFIG_SENSORS_ATK0110=y
CONFIG_THERMAL=y
CONFIG_THERMAL_HWMON=y
# CONFIG_WATCHDOG is not set
CONFIG_SSB_POSSIBLE=y

#
# Sonics Silicon Backplane
#
# CONFIG_SSB is not set
CONFIG_BCMA_POSSIBLE=y

#
# Broadcom specific AMBA
#
# CONFIG_BCMA is not set

#
# Multifunction device drivers
#
CONFIG_MFD_CORE=y
CONFIG_MFD_88PM860X=y
CONFIG_MFD_SM501=y
# CONFIG_MFD_SM501_GPIO is not set
CONFIG_HTC_PASIC3=y
CONFIG_HTC_I2CPLD=y
CONFIG_TPS6105X=y
CONFIG_TPS65010=y
# CONFIG_TPS6507X is not set
CONFIG_MFD_TPS6586X=y
CONFIG_MFD_TPS65910=y
# CONFIG_MFD_TPS65912_I2C is not set
# CONFIG_MFD_TPS65912_SPI is not set
# CONFIG_TWL4030_CORE is not set
# CONFIG_MFD_STMPE is not set
CONFIG_MFD_TC3589X=y
# CONFIG_MFD_TMIO is not set
# CONFIG_PMIC_DA903X is not set
CONFIG_PMIC_DA9052=y
CONFIG_MFD_DA9052_SPI=y
CONFIG_MFD_DA9052_I2C=y
# CONFIG_PMIC_ADP5520 is not set
# CONFIG_MFD_MAX8925 is not set
# CONFIG_MFD_MAX8997 is not set
CONFIG_MFD_MAX8998=y
# CONFIG_MFD_WM8400 is not set
CONFIG_MFD_WM831X=y
CONFIG_MFD_WM831X_I2C=y
CONFIG_MFD_WM831X_SPI=y
CONFIG_MFD_WM8350=y
CONFIG_MFD_WM8350_I2C=y
CONFIG_MFD_WM8994=y
# CONFIG_MFD_PCF50633 is not set
# CONFIG_MFD_MC13XXX is not set
# CONFIG_ABX500_CORE is not set
CONFIG_EZX_PCAP=y
# CONFIG_MFD_CS5535 is not set
CONFIG_MFD_TIMBERDALE=y
CONFIG_LPC_SCH=y
CONFIG_MFD_RDC321X=y
# CONFIG_MFD_JANZ_CMODIO is not set
CONFIG_MFD_VX855=y
CONFIG_MFD_WL1273_CORE=y
# CONFIG_MFD_AAT2870_CORE is not set
CONFIG_REGULATOR=y
CONFIG_REGULATOR_DEBUG=y
CONFIG_REGULATOR_DUMMY=y
CONFIG_REGULATOR_FIXED_VOLTAGE=y
CONFIG_REGULATOR_VIRTUAL_CONSUMER=y
# CONFIG_REGULATOR_USERSPACE_CONSUMER is not set
CONFIG_REGULATOR_GPIO=y
CONFIG_REGULATOR_BQ24022=y
# CONFIG_REGULATOR_MAX1586 is not set
# CONFIG_REGULATOR_MAX8649 is not set
# CONFIG_REGULATOR_MAX8660 is not set
CONFIG_REGULATOR_MAX8952=y
CONFIG_REGULATOR_MAX8998=y
CONFIG_REGULATOR_WM831X=y
CONFIG_REGULATOR_WM8350=y
# CONFIG_REGULATOR_WM8994 is not set
# CONFIG_REGULATOR_DA9052 is not set
# CONFIG_REGULATOR_LP3971 is not set
# CONFIG_REGULATOR_LP3972 is not set
CONFIG_REGULATOR_PCAP=y
# CONFIG_REGULATOR_TPS6105X is not set
CONFIG_REGULATOR_TPS65023=y
# CONFIG_REGULATOR_TPS6507X is not set
# CONFIG_REGULATOR_88PM8607 is not set
CONFIG_REGULATOR_ISL6271A=y
CONFIG_REGULATOR_AD5398=y
# CONFIG_REGULATOR_TPS6586X is not set
CONFIG_REGULATOR_TPS6524X=y
CONFIG_REGULATOR_TPS65910=y
# CONFIG_MEDIA_SUPPORT is not set

#
# Graphics support
#
CONFIG_AGP=y
CONFIG_AGP_AMD64=y
CONFIG_AGP_INTEL=y
CONFIG_AGP_SIS=y
CONFIG_AGP_VIA=y
CONFIG_VGA_ARB=y
CONFIG_VGA_ARB_MAX_GPUS=16
CONFIG_VGA_SWITCHEROO=y
CONFIG_DRM=y
CONFIG_DRM_KMS_HELPER=y
CONFIG_DRM_TTM=y
CONFIG_DRM_TDFX=y
# CONFIG_DRM_R128 is not set
CONFIG_DRM_RADEON=y
# CONFIG_DRM_RADEON_KMS is not set
CONFIG_DRM_I915=y
CONFIG_DRM_I915_KMS=y
# CONFIG_DRM_MGA is not set
# CONFIG_DRM_SIS is not set
CONFIG_DRM_VIA=y
CONFIG_DRM_SAVAGE=y
# CONFIG_DRM_VMWGFX is not set
# CONFIG_DRM_GMA500 is not set
# CONFIG_STUB_POULSBO is not set
CONFIG_VGASTATE=y
CONFIG_VIDEO_OUTPUT_CONTROL=y
CONFIG_FB=y
# CONFIG_FIRMWARE_EDID is not set
# CONFIG_FB_DDC is not set
CONFIG_FB_BOOT_VESA_SUPPORT=y
CONFIG_FB_CFB_FILLRECT=y
CONFIG_FB_CFB_COPYAREA=y
CONFIG_FB_CFB_IMAGEBLIT=y
# CONFIG_FB_CFB_REV_PIXELS_IN_BYTE is not set
CONFIG_FB_SYS_FILLRECT=y
CONFIG_FB_SYS_COPYAREA=y
CONFIG_FB_SYS_IMAGEBLIT=y
# CONFIG_FB_FOREIGN_ENDIAN is not set
CONFIG_FB_SYS_FOPS=y
# CONFIG_FB_WMT_GE_ROPS is not set
CONFIG_FB_DEFERRED_IO=y
CONFIG_FB_SVGALIB=y
# CONFIG_FB_MACMODES is not set
# CONFIG_FB_BACKLIGHT is not set
CONFIG_FB_MODE_HELPERS=y
CONFIG_FB_TILEBLITTING=y

#
# Frame buffer hardware drivers
#
CONFIG_FB_CIRRUS=y
CONFIG_FB_PM2=y
CONFIG_FB_PM2_FIFO_DISCONNECT=y
# CONFIG_FB_CYBER2000 is not set
# CONFIG_FB_ARC is not set
CONFIG_FB_ASILIANT=y
CONFIG_FB_IMSTT=y
# CONFIG_FB_VGA16 is not set
CONFIG_FB_UVESA=y
CONFIG_FB_VESA=y
# CONFIG_FB_EFI is not set
# CONFIG_FB_N411 is not set
CONFIG_FB_HGA=y
# CONFIG_FB_S1D13XXX is not set
# CONFIG_FB_NVIDIA is not set
# CONFIG_FB_RIVA is not set
CONFIG_FB_LE80578=y
# CONFIG_FB_CARILLO_RANCH is not set
# CONFIG_FB_MATROX is not set
# CONFIG_FB_RADEON is not set
# CONFIG_FB_ATY128 is not set
CONFIG_FB_ATY=y
# CONFIG_FB_ATY_CT is not set
CONFIG_FB_ATY_GX=y
# CONFIG_FB_ATY_BACKLIGHT is not set
# CONFIG_FB_S3 is not set
CONFIG_FB_SAVAGE=y
# CONFIG_FB_SAVAGE_I2C is not set
# CONFIG_FB_SAVAGE_ACCEL is not set
CONFIG_FB_SIS=y
CONFIG_FB_SIS_300=y
# CONFIG_FB_SIS_315 is not set
CONFIG_FB_VIA=y
# CONFIG_FB_VIA_DIRECT_PROCFS is not set
CONFIG_FB_VIA_X_COMPATIBILITY=y
CONFIG_FB_NEOMAGIC=y
# CONFIG_FB_KYRO is not set
CONFIG_FB_3DFX=y
# CONFIG_FB_3DFX_ACCEL is not set
# CONFIG_FB_3DFX_I2C is not set
CONFIG_FB_VOODOO1=y
CONFIG_FB_VT8623=y
CONFIG_FB_TRIDENT=y
CONFIG_FB_ARK=y
CONFIG_FB_PM3=y
CONFIG_FB_CARMINE=y
# CONFIG_FB_CARMINE_DRAM_EVAL is not set
CONFIG_CARMINE_DRAM_CUSTOM=y
# CONFIG_FB_GEODE is not set
# CONFIG_FB_TMIO is not set
# CONFIG_FB_SM501 is not set
# CONFIG_FB_VIRTUAL is not set
# CONFIG_XEN_FBDEV_FRONTEND is not set
# CONFIG_FB_METRONOME is not set
CONFIG_FB_MB862XX=y
CONFIG_FB_MB862XX_PCI_GDC=y
# CONFIG_FB_MB862XX_I2C is not set
CONFIG_FB_BROADSHEET=y
CONFIG_BACKLIGHT_LCD_SUPPORT=y
# CONFIG_LCD_CLASS_DEVICE is not set
CONFIG_BACKLIGHT_CLASS_DEVICE=y
# CONFIG_BACKLIGHT_GENERIC is not set
# CONFIG_BACKLIGHT_PROGEAR is not set
# CONFIG_BACKLIGHT_APPLE is not set
CONFIG_BACKLIGHT_SAHARA=y
CONFIG_BACKLIGHT_WM831X=y
CONFIG_BACKLIGHT_ADP8860=y
CONFIG_BACKLIGHT_ADP8870=y
# CONFIG_BACKLIGHT_88PM860X is not set

#
# Console display driver support
#
CONFIG_VGA_CONSOLE=y
CONFIG_VGACON_SOFT_SCROLLBACK=y
CONFIG_VGACON_SOFT_SCROLLBACK_SIZE=64
CONFIG_DUMMY_CONSOLE=y
CONFIG_FRAMEBUFFER_CONSOLE=y
CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY=y
CONFIG_FRAMEBUFFER_CONSOLE_ROTATION=y
# CONFIG_FONTS is not set
CONFIG_FONT_8x8=y
CONFIG_FONT_8x16=y
CONFIG_LOGO=y
CONFIG_LOGO_LINUX_MONO=y
# CONFIG_LOGO_LINUX_VGA16 is not set
CONFIG_LOGO_LINUX_CLUT224=y
# CONFIG_SOUND is not set
CONFIG_HID_SUPPORT=y
# CONFIG_HID is not set
CONFIG_HID_PID=y
# CONFIG_USB_SUPPORT is not set
CONFIG_UWB=y
CONFIG_UWB_WHCI=y
# CONFIG_MMC is not set
CONFIG_MEMSTICK=y
# CONFIG_MEMSTICK_DEBUG is not set

#
# MemoryStick drivers
#
# CONFIG_MEMSTICK_UNSAFE_RESUME is not set
# CONFIG_MSPRO_BLOCK is not set

#
# MemoryStick Host Controller Drivers
#
# CONFIG_MEMSTICK_TIFM_MS is not set
CONFIG_MEMSTICK_JMICRON_38X=y
CONFIG_MEMSTICK_R592=y
CONFIG_NEW_LEDS=y
CONFIG_LEDS_CLASS=y

#
# LED drivers
#
CONFIG_LEDS_88PM860X=y
CONFIG_LEDS_LM3530=y
CONFIG_LEDS_PCA9532=y
CONFIG_LEDS_PCA9532_GPIO=y
# CONFIG_LEDS_GPIO is not set
# CONFIG_LEDS_LP3944 is not set
# CONFIG_LEDS_LP5521 is not set
CONFIG_LEDS_LP5523=y
# CONFIG_LEDS_CLEVO_MAIL is not set
# CONFIG_LEDS_PCA955X is not set
CONFIG_LEDS_WM831X_STATUS=y
CONFIG_LEDS_WM8350=y
# CONFIG_LEDS_DAC124S085 is not set
CONFIG_LEDS_REGULATOR=y
CONFIG_LEDS_BD2802=y
CONFIG_LEDS_INTEL_SS4200=y
# CONFIG_LEDS_LT3593 is not set
CONFIG_LEDS_TCA6507=y
# CONFIG_LEDS_TRIGGERS is not set

#
# LED Triggers
#
CONFIG_ACCESSIBILITY=y
CONFIG_A11Y_BRAILLE_CONSOLE=y
# CONFIG_INFINIBAND is not set
# CONFIG_EDAC is not set
CONFIG_RTC_LIB=y
CONFIG_RTC_CLASS=y
# CONFIG_RTC_HCTOSYS is not set
CONFIG_RTC_DEBUG=y

#
# RTC interfaces
#
CONFIG_RTC_INTF_SYSFS=y
# CONFIG_RTC_INTF_PROC is not set
# CONFIG_RTC_INTF_DEV is not set
CONFIG_RTC_DRV_TEST=y

#
# I2C RTC drivers
#
CONFIG_RTC_DRV_88PM860X=y
CONFIG_RTC_DRV_DS1307=y
CONFIG_RTC_DRV_DS1374=y
# CONFIG_RTC_DRV_DS1672 is not set
# CONFIG_RTC_DRV_DS3232 is not set
CONFIG_RTC_DRV_MAX6900=y
CONFIG_RTC_DRV_MAX8998=y
# CONFIG_RTC_DRV_RS5C372 is not set
CONFIG_RTC_DRV_ISL1208=y
# CONFIG_RTC_DRV_ISL12022 is not set
CONFIG_RTC_DRV_X1205=y
CONFIG_RTC_DRV_PCF8563=y
# CONFIG_RTC_DRV_PCF8583 is not set
CONFIG_RTC_DRV_M41T80=y
# CONFIG_RTC_DRV_M41T80_WDT is not set
CONFIG_RTC_DRV_BQ32K=y
CONFIG_RTC_DRV_S35390A=y
# CONFIG_RTC_DRV_FM3130 is not set
# CONFIG_RTC_DRV_RX8581 is not set
# CONFIG_RTC_DRV_RX8025 is not set
# CONFIG_RTC_DRV_EM3027 is not set
# CONFIG_RTC_DRV_RV3029C2 is not set

#
# SPI RTC drivers
#
# CONFIG_RTC_DRV_M41T93 is not set
# CONFIG_RTC_DRV_M41T94 is not set
# CONFIG_RTC_DRV_DS1305 is not set
CONFIG_RTC_DRV_DS1390=y
CONFIG_RTC_DRV_MAX6902=y
# CONFIG_RTC_DRV_R9701 is not set
# CONFIG_RTC_DRV_RS5C348 is not set
CONFIG_RTC_DRV_DS3234=y
CONFIG_RTC_DRV_PCF2123=y

#
# Platform RTC drivers
#
CONFIG_RTC_DRV_CMOS=y
# CONFIG_RTC_DRV_DS1286 is not set
CONFIG_RTC_DRV_DS1511=y
CONFIG_RTC_DRV_DS1553=y
# CONFIG_RTC_DRV_DS1742 is not set
CONFIG_RTC_DRV_STK17TA8=y
CONFIG_RTC_DRV_M48T86=y
CONFIG_RTC_DRV_M48T35=y
CONFIG_RTC_DRV_M48T59=y
# CONFIG_RTC_DRV_MSM6242 is not set
# CONFIG_RTC_DRV_BQ4802 is not set
CONFIG_RTC_DRV_RP5C01=y
CONFIG_RTC_DRV_V3020=y
CONFIG_RTC_DRV_WM831X=y
# CONFIG_RTC_DRV_WM8350 is not set

#
# on-CPU RTC drivers
#
CONFIG_RTC_DRV_PCAP=y
CONFIG_DMADEVICES=y
CONFIG_DMADEVICES_DEBUG=y
# CONFIG_DMADEVICES_VDEBUG is not set

#
# DMA Devices
#
# CONFIG_INTEL_MID_DMAC is not set
# CONFIG_INTEL_IOATDMA is not set
# CONFIG_TIMB_DMA is not set
# CONFIG_PCH_DMA is not set
# CONFIG_AUXDISPLAY is not set
CONFIG_UIO=y
# CONFIG_UIO_CIF is not set
CONFIG_UIO_PDRV=y
# CONFIG_UIO_PDRV_GENIRQ is not set
CONFIG_UIO_AEC=y
CONFIG_UIO_SERCOS3=y
CONFIG_UIO_PCI_GENERIC=y
CONFIG_UIO_NETX=y
CONFIG_VIRTIO=y
CONFIG_VIRTIO_RING=y

#
# Virtio drivers
#
# CONFIG_VIRTIO_PCI is not set
# CONFIG_VIRTIO_BALLOON is not set
CONFIG_VIRTIO_MMIO=y

#
# Microsoft Hyper-V guest support
#
# CONFIG_HYPERV is not set

#
# Xen driver support
#
# CONFIG_XEN_BALLOON is not set
# CONFIG_XEN_DEV_EVTCHN is not set
CONFIG_XEN_BACKEND=y
# CONFIG_XENFS is not set
CONFIG_XEN_SYS_HYPERVISOR=y
CONFIG_XEN_XENBUS_FRONTEND=y
CONFIG_XEN_GNTDEV=y
# CONFIG_XEN_GRANT_DEV_ALLOC is not set
CONFIG_SWIOTLB_XEN=y
CONFIG_XEN_TMEM=y
# CONFIG_XEN_PCIDEV_BACKEND is not set
CONFIG_XEN_PRIVCMD=y
# CONFIG_STAGING is not set
CONFIG_X86_PLATFORM_DEVICES=y
# CONFIG_ACERHDF is not set
CONFIG_DELL_LAPTOP=y
# CONFIG_FUJITSU_LAPTOP is not set
# CONFIG_HP_ACCEL is not set
CONFIG_PANASONIC_LAPTOP=y
# CONFIG_THINKPAD_ACPI is not set
# CONFIG_SENSORS_HDAPS is not set
CONFIG_EEEPC_LAPTOP=y
# CONFIG_ACPI_WMI is not set
CONFIG_ACPI_ASUS=y
# CONFIG_TOPSTAR_LAPTOP is not set
# CONFIG_ACPI_TOSHIBA is not set
CONFIG_TOSHIBA_BT_RFKILL=y
CONFIG_ACPI_CMPC=y
# CONFIG_INTEL_IPS is not set
CONFIG_IBM_RTL=y
# CONFIG_XO15_EBOOK is not set
CONFIG_SAMSUNG_Q10=y

#
# Hardware Spinlock drivers
#
CONFIG_CLKEVT_I8253=y
CONFIG_I8253_LOCK=y
CONFIG_CLKBLD_I8253=y
CONFIG_IOMMU_SUPPORT=y
# CONFIG_AMD_IOMMU is not set
CONFIG_VIRT_DRIVERS=y
# CONFIG_PM_DEVFREQ is not set
# CONFIG_XSHM is not set

#
# Firmware Drivers
#
# CONFIG_EDD is not set
CONFIG_FIRMWARE_MEMMAP=y
CONFIG_EFI_VARS=y
# CONFIG_DELL_RBU is not set
CONFIG_DCDBAS=y
# CONFIG_DMIID is not set
# CONFIG_DMI_SYSFS is not set
CONFIG_ISCSI_IBFT_FIND=y
# CONFIG_ISCSI_IBFT is not set
CONFIG_GOOGLE_FIRMWARE=y

#
# Google Firmware Drivers
#
CONFIG_GOOGLE_SMI=y
# CONFIG_GOOGLE_MEMCONSOLE is not set

#
# File systems
#
CONFIG_EXT2_FS=y
CONFIG_EXT2_FS_XATTR=y
CONFIG_EXT2_FS_POSIX_ACL=y
# CONFIG_EXT2_FS_SECURITY is not set
CONFIG_EXT2_FS_XIP=y
# CONFIG_EXT3_FS is not set
# CONFIG_EXT4_FS is not set
CONFIG_FS_XIP=y
CONFIG_FS_MBCACHE=y
# CONFIG_REISERFS_FS is not set
# CONFIG_JFS_FS is not set
CONFIG_XFS_FS=y
CONFIG_XFS_QUOTA=y
CONFIG_XFS_POSIX_ACL=y
# CONFIG_XFS_RT is not set
CONFIG_XFS_DEBUG=y
# CONFIG_GFS2_FS is not set
# CONFIG_OCFS2_FS is not set
# CONFIG_BTRFS_FS is not set
# CONFIG_NILFS2_FS is not set
CONFIG_FS_POSIX_ACL=y
CONFIG_EXPORTFS=y
CONFIG_FILE_LOCKING=y
CONFIG_FSNOTIFY=y
CONFIG_DNOTIFY=y
# CONFIG_INOTIFY_USER is not set
# CONFIG_FANOTIFY is not set
CONFIG_QUOTA=y
# CONFIG_QUOTA_NETLINK_INTERFACE is not set
# CONFIG_PRINT_QUOTA_WARNING is not set
CONFIG_QUOTA_DEBUG=y
CONFIG_QUOTA_TREE=y
CONFIG_QFMT_V1=y
CONFIG_QFMT_V2=y
CONFIG_QUOTACTL=y
CONFIG_QUOTACTL_COMPAT=y
CONFIG_AUTOFS4_FS=y
# CONFIG_FUSE_FS is not set

#
# Caches
#
# CONFIG_FSCACHE is not set

#
# CD-ROM/DVD Filesystems
#
CONFIG_ISO9660_FS=y
CONFIG_JOLIET=y
# CONFIG_ZISOFS is not set
CONFIG_UDF_FS=y
CONFIG_UDF_NLS=y

#
# DOS/FAT/NT Filesystems
#
CONFIG_FAT_FS=y
CONFIG_MSDOS_FS=y
CONFIG_VFAT_FS=y
CONFIG_FAT_DEFAULT_CODEPAGE=437
CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1"
CONFIG_NTFS_FS=y
# CONFIG_NTFS_DEBUG is not set
CONFIG_NTFS_RW=y

#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
CONFIG_PROC_KCORE=y
CONFIG_PROC_SYSCTL=y
CONFIG_PROC_PAGE_MONITOR=y
CONFIG_SYSFS=y
CONFIG_TMPFS=y
# CONFIG_TMPFS_POSIX_ACL is not set
# CONFIG_TMPFS_XATTR is not set
# CONFIG_HUGETLBFS is not set
# CONFIG_HUGETLB_PAGE is not set
CONFIG_CONFIGFS_FS=y
CONFIG_MISC_FILESYSTEMS=y
# CONFIG_ADFS_FS is not set
CONFIG_AFFS_FS=y
CONFIG_ECRYPT_FS=y
CONFIG_HFS_FS=y
# CONFIG_HFSPLUS_FS is not set
# CONFIG_BEFS_FS is not set
# CONFIG_BFS_FS is not set
# CONFIG_EFS_FS is not set
# CONFIG_JFFS2_FS is not set
CONFIG_UBIFS_FS=y
# CONFIG_UBIFS_FS_XATTR is not set
# CONFIG_UBIFS_FS_ADVANCED_COMPR is not set
CONFIG_UBIFS_FS_LZO=y
CONFIG_UBIFS_FS_ZLIB=y
CONFIG_UBIFS_FS_DEBUG=y
# CONFIG_LOGFS is not set
CONFIG_CRAMFS=y
# CONFIG_SQUASHFS is not set
# CONFIG_VXFS_FS is not set
CONFIG_MINIX_FS=y
# CONFIG_OMFS_FS is not set
# CONFIG_HPFS_FS is not set
CONFIG_QNX4FS_FS=y
# CONFIG_ROMFS_FS is not set
CONFIG_PSTORE=y
# CONFIG_SYSV_FS is not set
CONFIG_UFS_FS=y
CONFIG_UFS_FS_WRITE=y
CONFIG_UFS_DEBUG=y
CONFIG_ORE=y
CONFIG_EXOFS_FS=y
CONFIG_EXOFS_DEBUG=y
# CONFIG_NETWORK_FILESYSTEMS is not set

#
# Partition Types
#
CONFIG_PARTITION_ADVANCED=y
CONFIG_ACORN_PARTITION=y
CONFIG_ACORN_PARTITION_CUMANA=y
# CONFIG_ACORN_PARTITION_EESOX is not set
# CONFIG_ACORN_PARTITION_ICS is not set
CONFIG_ACORN_PARTITION_ADFS=y
CONFIG_ACORN_PARTITION_POWERTEC=y
# CONFIG_ACORN_PARTITION_RISCIX is not set
CONFIG_OSF_PARTITION=y
CONFIG_AMIGA_PARTITION=y
CONFIG_ATARI_PARTITION=y
CONFIG_MAC_PARTITION=y
CONFIG_MSDOS_PARTITION=y
# CONFIG_BSD_DISKLABEL is not set
CONFIG_MINIX_SUBPARTITION=y
# CONFIG_SOLARIS_X86_PARTITION is not set
CONFIG_UNIXWARE_DISKLABEL=y
# CONFIG_LDM_PARTITION is not set
CONFIG_SGI_PARTITION=y
# CONFIG_ULTRIX_PARTITION is not set
# CONFIG_SUN_PARTITION is not set
CONFIG_KARMA_PARTITION=y
CONFIG_EFI_PARTITION=y
# CONFIG_SYSV68_PARTITION is not set
CONFIG_NLS=y
CONFIG_NLS_DEFAULT="iso8859-1"
# CONFIG_NLS_CODEPAGE_437 is not set
CONFIG_NLS_CODEPAGE_737=y
CONFIG_NLS_CODEPAGE_775=y
# CONFIG_NLS_CODEPAGE_850 is not set
# CONFIG_NLS_CODEPAGE_852 is not set
# CONFIG_NLS_CODEPAGE_855 is not set
CONFIG_NLS_CODEPAGE_857=y
CONFIG_NLS_CODEPAGE_860=y
CONFIG_NLS_CODEPAGE_861=y
CONFIG_NLS_CODEPAGE_862=y
# CONFIG_NLS_CODEPAGE_863 is not set
# CONFIG_NLS_CODEPAGE_864 is not set
# CONFIG_NLS_CODEPAGE_865 is not set
CONFIG_NLS_CODEPAGE_866=y
CONFIG_NLS_CODEPAGE_869=y
# CONFIG_NLS_CODEPAGE_936 is not set
# CONFIG_NLS_CODEPAGE_950 is not set
# CONFIG_NLS_CODEPAGE_932 is not set
# CONFIG_NLS_CODEPAGE_949 is not set
# CONFIG_NLS_CODEPAGE_874 is not set
CONFIG_NLS_ISO8859_8=y
# CONFIG_NLS_CODEPAGE_1250 is not set
CONFIG_NLS_CODEPAGE_1251=y
# CONFIG_NLS_ASCII is not set
# CONFIG_NLS_ISO8859_1 is not set
CONFIG_NLS_ISO8859_2=y
# CONFIG_NLS_ISO8859_3 is not set
# CONFIG_NLS_ISO8859_4 is not set
CONFIG_NLS_ISO8859_5=y
CONFIG_NLS_ISO8859_6=y
CONFIG_NLS_ISO8859_7=y
# CONFIG_NLS_ISO8859_9 is not set
# CONFIG_NLS_ISO8859_13 is not set
# CONFIG_NLS_ISO8859_14 is not set
CONFIG_NLS_ISO8859_15=y
CONFIG_NLS_KOI8_R=y
# CONFIG_NLS_KOI8_U is not set
CONFIG_NLS_UTF8=y

#
# Kernel hacking
#
CONFIG_TRACE_IRQFLAGS_SUPPORT=y
CONFIG_PRINTK_TIME=y
CONFIG_DEFAULT_MESSAGE_LOGLEVEL=4
CONFIG_ENABLE_WARN_DEPRECATED=y
CONFIG_ENABLE_MUST_CHECK=y
CONFIG_FRAME_WARN=2048
CONFIG_MAGIC_SYSRQ=y
CONFIG_STRIP_ASM_SYMS=y
CONFIG_UNUSED_SYMBOLS=y
CONFIG_DEBUG_FS=y
# CONFIG_HEADERS_CHECK is not set
CONFIG_DEBUG_SECTION_MISMATCH=y
CONFIG_DEBUG_KERNEL=y
# CONFIG_DEBUG_SHIRQ is not set
# CONFIG_LOCKUP_DETECTOR is not set
# CONFIG_HARDLOCKUP_DETECTOR is not set
CONFIG_DETECT_HUNG_TASK=y
CONFIG_DEFAULT_HUNG_TASK_TIMEOUT=120
# CONFIG_BOOTPARAM_HUNG_TASK_PANIC is not set
CONFIG_BOOTPARAM_HUNG_TASK_PANIC_VALUE=0
CONFIG_SCHED_DEBUG=y
CONFIG_SCHEDSTATS=y
# CONFIG_TIMER_STATS is not set
CONFIG_DEBUG_OBJECTS=y
CONFIG_DEBUG_OBJECTS_SELFTEST=y
CONFIG_DEBUG_OBJECTS_FREE=y
# CONFIG_DEBUG_OBJECTS_TIMERS is not set
# CONFIG_DEBUG_OBJECTS_WORK is not set
# CONFIG_DEBUG_OBJECTS_RCU_HEAD is not set
# CONFIG_DEBUG_OBJECTS_PERCPU_COUNTER is not set
CONFIG_DEBUG_OBJECTS_ENABLE_DEFAULT=1
# CONFIG_SLUB_DEBUG_ON is not set
# CONFIG_SLUB_STATS is not set
# CONFIG_DEBUG_KMEMLEAK is not set
CONFIG_DEBUG_PREEMPT=y
CONFIG_DEBUG_RT_MUTEXES=y
CONFIG_DEBUG_PI_LIST=y
# CONFIG_RT_MUTEX_TESTER is not set
CONFIG_DEBUG_SPINLOCK=y
CONFIG_DEBUG_MUTEXES=y
# CONFIG_DEBUG_LOCK_ALLOC is not set
# CONFIG_PROVE_LOCKING is not set
CONFIG_SPARSE_RCU_POINTER=y
# CONFIG_LOCK_STAT is not set
CONFIG_TRACE_IRQFLAGS=y
# CONFIG_DEBUG_ATOMIC_SLEEP is not set
CONFIG_DEBUG_LOCKING_API_SELFTESTS=y
CONFIG_STACKTRACE=y
# CONFIG_DEBUG_STACK_USAGE is not set
CONFIG_DEBUG_KOBJECT=y
CONFIG_DEBUG_BUGVERBOSE=y
# CONFIG_DEBUG_INFO is not set
# CONFIG_DEBUG_VM is not set
# CONFIG_DEBUG_VIRTUAL is not set
CONFIG_DEBUG_WRITECOUNT=y
CONFIG_DEBUG_MEMORY_INIT=y
CONFIG_DEBUG_LIST=y
CONFIG_TEST_LIST_SORT=y
CONFIG_DEBUG_SG=y
# CONFIG_DEBUG_NOTIFIERS is not set
# CONFIG_DEBUG_CREDENTIALS is not set
CONFIG_ARCH_WANT_FRAME_POINTERS=y
CONFIG_FRAME_POINTER=y
# CONFIG_BOOT_PRINTK_DELAY is not set
CONFIG_RCU_TORTURE_TEST=y
# CONFIG_RCU_TORTURE_TEST_RUNNABLE is not set
CONFIG_BACKTRACE_SELF_TEST=y
# CONFIG_DEBUG_BLOCK_EXT_DEVT is not set
# CONFIG_DEBUG_FORCE_WEAK_PER_CPU is not set
CONFIG_LKDTM=y
CONFIG_FAULT_INJECTION=y
# CONFIG_FAILSLAB is not set
# CONFIG_FAIL_PAGE_ALLOC is not set
CONFIG_FAIL_MAKE_REQUEST=y
CONFIG_FAIL_IO_TIMEOUT=y
CONFIG_FAULT_INJECTION_DEBUG_FS=y
# CONFIG_LATENCYTOP is not set
# CONFIG_SYSCTL_SYSCALL_CHECK is not set
# CONFIG_DEBUG_PAGEALLOC is not set
CONFIG_USER_STACKTRACE_SUPPORT=y
CONFIG_NOP_TRACER=y
CONFIG_HAVE_FTRACE_NMI_ENTER=y
CONFIG_HAVE_FUNCTION_TRACER=y
CONFIG_HAVE_FUNCTION_GRAPH_TRACER=y
CONFIG_HAVE_FUNCTION_GRAPH_FP_TEST=y
CONFIG_HAVE_FUNCTION_TRACE_MCOUNT_TEST=y
CONFIG_HAVE_DYNAMIC_FTRACE=y
CONFIG_HAVE_FTRACE_MCOUNT_RECORD=y
CONFIG_HAVE_SYSCALL_TRACEPOINTS=y
CONFIG_HAVE_C_RECORDMCOUNT=y
CONFIG_TRACER_MAX_TRACE=y
CONFIG_RING_BUFFER=y
CONFIG_FTRACE_NMI_ENTER=y
CONFIG_EVENT_TRACING=y
CONFIG_EVENT_POWER_TRACING_DEPRECATED=y
CONFIG_CONTEXT_SWITCH_TRACER=y
CONFIG_RING_BUFFER_ALLOW_SWAP=y
CONFIG_TRACING=y
CONFIG_GENERIC_TRACER=y
CONFIG_TRACING_SUPPORT=y
CONFIG_FTRACE=y
CONFIG_FUNCTION_TRACER=y
# CONFIG_FUNCTION_GRAPH_TRACER is not set
CONFIG_IRQSOFF_TRACER=y
CONFIG_PREEMPT_TRACER=y
CONFIG_SCHED_TRACER=y
# CONFIG_FTRACE_SYSCALLS is not set
CONFIG_BRANCH_PROFILE_NONE=y
# CONFIG_PROFILE_ANNOTATED_BRANCHES is not set
# CONFIG_PROFILE_ALL_BRANCHES is not set
# CONFIG_STACK_TRACER is not set
# CONFIG_BLK_DEV_IO_TRACE is not set
CONFIG_UPROBE_EVENT=y
CONFIG_PROBE_EVENTS=y
CONFIG_DYNAMIC_FTRACE=y
CONFIG_FUNCTION_PROFILER=y
CONFIG_FTRACE_MCOUNT_RECORD=y
# CONFIG_FTRACE_STARTUP_TEST is not set
# CONFIG_MMIOTRACE is not set
# CONFIG_RING_BUFFER_BENCHMARK is not set
CONFIG_PROVIDE_OHCI1394_DMA_INIT=y
# CONFIG_FIREWIRE_OHCI_REMOTE_DMA is not set
CONFIG_DYNAMIC_DEBUG=y
CONFIG_DMA_API_DEBUG=y
CONFIG_ATOMIC64_SELFTEST=y
CONFIG_SAMPLES=y
CONFIG_HAVE_ARCH_KGDB=y
CONFIG_KGDB=y
CONFIG_KGDB_SERIAL_CONSOLE=y
# CONFIG_KGDB_TESTS is not set
# CONFIG_KGDB_LOW_LEVEL_TRAP is not set
# CONFIG_KGDB_KDB is not set
CONFIG_HAVE_ARCH_KMEMCHECK=y
CONFIG_TEST_KSTRTOX=y
# CONFIG_STRICT_DEVMEM is not set
CONFIG_X86_VERBOSE_BOOTUP=y
CONFIG_EARLY_PRINTK=y
# CONFIG_EARLY_PRINTK_DBGP is not set
CONFIG_DEBUG_STACKOVERFLOW=y
CONFIG_X86_PTDUMP=y
CONFIG_DEBUG_RODATA=y
CONFIG_DEBUG_RODATA_TEST=y
CONFIG_IOMMU_DEBUG=y
# CONFIG_IOMMU_STRESS is not set
CONFIG_IOMMU_LEAK=y
CONFIG_HAVE_MMIOTRACE_SUPPORT=y
CONFIG_IO_DELAY_TYPE_0X80=0
CONFIG_IO_DELAY_TYPE_0XED=1
CONFIG_IO_DELAY_TYPE_UDELAY=2
CONFIG_IO_DELAY_TYPE_NONE=3
# CONFIG_IO_DELAY_0X80 is not set
# CONFIG_IO_DELAY_0XED is not set
# CONFIG_IO_DELAY_UDELAY is not set
CONFIG_IO_DELAY_NONE=y
CONFIG_DEFAULT_IO_DELAY_TYPE=3
CONFIG_DEBUG_BOOT_PARAMS=y
CONFIG_CPA_DEBUG=y
CONFIG_OPTIMIZE_INLINING=y
# CONFIG_DEBUG_STRICT_USER_COPY_CHECKS is not set
CONFIG_DEBUG_NMI_SELFTEST=y

#
# Security options
#
CONFIG_KEYS=y
CONFIG_ENCRYPTED_KEYS=y
# CONFIG_KEYS_DEBUG_PROC_KEYS is not set
# CONFIG_SECURITY_DMESG_RESTRICT is not set
# CONFIG_SECURITY is not set
CONFIG_SECURITYFS=y
CONFIG_DEFAULT_SECURITY_DAC=y
CONFIG_DEFAULT_SECURITY=""
CONFIG_XOR_BLOCKS=y
CONFIG_ASYNC_CORE=y
CONFIG_ASYNC_XOR=y
CONFIG_CRYPTO=y

#
# Crypto core or helper
#
# CONFIG_CRYPTO_FIPS is not set
CONFIG_CRYPTO_ALGAPI=y
CONFIG_CRYPTO_ALGAPI2=y
CONFIG_CRYPTO_AEAD=y
CONFIG_CRYPTO_AEAD2=y
CONFIG_CRYPTO_BLKCIPHER=y
CONFIG_CRYPTO_BLKCIPHER2=y
CONFIG_CRYPTO_HASH=y
CONFIG_CRYPTO_HASH2=y
CONFIG_CRYPTO_RNG=y
CONFIG_CRYPTO_RNG2=y
CONFIG_CRYPTO_PCOMP2=y
CONFIG_CRYPTO_MANAGER=y
CONFIG_CRYPTO_MANAGER2=y
# CONFIG_CRYPTO_USER is not set
# CONFIG_CRYPTO_MANAGER_DISABLE_TESTS is not set
CONFIG_CRYPTO_GF128MUL=y
CONFIG_CRYPTO_NULL=y
CONFIG_CRYPTO_WORKQUEUE=y
CONFIG_CRYPTO_CRYPTD=y
CONFIG_CRYPTO_AUTHENC=y

#
# Authenticated Encryption with Associated Data
#
# CONFIG_CRYPTO_CCM is not set
# CONFIG_CRYPTO_GCM is not set
CONFIG_CRYPTO_SEQIV=y

#
# Block modes
#
CONFIG_CRYPTO_CBC=y
# CONFIG_CRYPTO_CTR is not set
# CONFIG_CRYPTO_CTS is not set
CONFIG_CRYPTO_ECB=y
CONFIG_CRYPTO_LRW=y
CONFIG_CRYPTO_PCBC=y
CONFIG_CRYPTO_XTS=y

#
# Hash modes
#
CONFIG_CRYPTO_HMAC=y
CONFIG_CRYPTO_XCBC=y
CONFIG_CRYPTO_VMAC=y

#
# Digest
#
CONFIG_CRYPTO_CRC32C=y
CONFIG_CRYPTO_CRC32C_INTEL=y
CONFIG_CRYPTO_GHASH=y
# CONFIG_CRYPTO_MD4 is not set
CONFIG_CRYPTO_MD5=y
# CONFIG_CRYPTO_MICHAEL_MIC is not set
CONFIG_CRYPTO_RMD128=y
CONFIG_CRYPTO_RMD160=y
CONFIG_CRYPTO_RMD256=y
# CONFIG_CRYPTO_RMD320 is not set
CONFIG_CRYPTO_SHA1=y
# CONFIG_CRYPTO_SHA1_SSSE3 is not set
CONFIG_CRYPTO_SHA256=y
CONFIG_CRYPTO_SHA512=y
CONFIG_CRYPTO_TGR192=y
CONFIG_CRYPTO_WP512=y
# CONFIG_CRYPTO_GHASH_CLMUL_NI_INTEL is not set

#
# Ciphers
#
CONFIG_CRYPTO_AES=y
CONFIG_CRYPTO_AES_X86_64=y
# CONFIG_CRYPTO_AES_NI_INTEL is not set
CONFIG_CRYPTO_ANUBIS=y
# CONFIG_CRYPTO_ARC4 is not set
CONFIG_CRYPTO_BLOWFISH=y
CONFIG_CRYPTO_BLOWFISH_COMMON=y
CONFIG_CRYPTO_BLOWFISH_X86_64=y
CONFIG_CRYPTO_CAMELLIA=y
# CONFIG_CRYPTO_CAST5 is not set
CONFIG_CRYPTO_CAST6=y
CONFIG_CRYPTO_DES=y
CONFIG_CRYPTO_FCRYPT=y
# CONFIG_CRYPTO_KHAZAD is not set
# CONFIG_CRYPTO_SALSA20 is not set
# CONFIG_CRYPTO_SALSA20_X86_64 is not set
# CONFIG_CRYPTO_SEED is not set
CONFIG_CRYPTO_SERPENT=y
CONFIG_CRYPTO_SERPENT_SSE2_X86_64=y
CONFIG_CRYPTO_TEA=y
# CONFIG_CRYPTO_TWOFISH is not set
CONFIG_CRYPTO_TWOFISH_COMMON=y
CONFIG_CRYPTO_TWOFISH_X86_64=y
# CONFIG_CRYPTO_TWOFISH_X86_64_3WAY is not set

#
# Compression
#
CONFIG_CRYPTO_DEFLATE=y
# CONFIG_CRYPTO_ZLIB is not set
CONFIG_CRYPTO_LZO=y

#
# Random Number Generation
#
CONFIG_CRYPTO_ANSI_CPRNG=y
CONFIG_CRYPTO_USER_API=y
CONFIG_CRYPTO_USER_API_HASH=y
CONFIG_CRYPTO_USER_API_SKCIPHER=y
CONFIG_CRYPTO_HW=y
CONFIG_CRYPTO_DEV_PADLOCK=y
# CONFIG_CRYPTO_DEV_PADLOCK_AES is not set
# CONFIG_CRYPTO_DEV_PADLOCK_SHA is not set
CONFIG_HAVE_KVM=y
CONFIG_HAVE_KVM_IRQCHIP=y
CONFIG_HAVE_KVM_EVENTFD=y
CONFIG_KVM_APIC_ARCHITECTURE=y
CONFIG_KVM_MMIO=y
CONFIG_KVM_ASYNC_PF=y
CONFIG_VIRTUALIZATION=y
CONFIG_KVM=y
CONFIG_KVM_INTEL=y
# CONFIG_KVM_AMD is not set
# CONFIG_KVM_MMU_AUDIT is not set
CONFIG_VHOST_NET=y
CONFIG_BINARY_PRINTF=y

#
# Library routines
#
CONFIG_BITREVERSE=y
CONFIG_GENERIC_FIND_FIRST_BIT=y
CONFIG_GENERIC_PCI_IOMAP=y
CONFIG_GENERIC_IOMAP=y
CONFIG_CRC_CCITT=y
CONFIG_CRC16=y
CONFIG_CRC_T10DIF=y
CONFIG_CRC_ITU_T=y
CONFIG_CRC32=y
CONFIG_CRC7=y
CONFIG_LIBCRC32C=y
CONFIG_CRC8=y
CONFIG_ZLIB_INFLATE=y
CONFIG_ZLIB_DEFLATE=y
CONFIG_LZO_COMPRESS=y
CONFIG_LZO_DECOMPRESS=y
CONFIG_XZ_DEC=y
CONFIG_XZ_DEC_X86=y
CONFIG_XZ_DEC_POWERPC=y
CONFIG_XZ_DEC_IA64=y
CONFIG_XZ_DEC_ARM=y
CONFIG_XZ_DEC_ARMTHUMB=y
CONFIG_XZ_DEC_SPARC=y
CONFIG_XZ_DEC_BCJ=y
# CONFIG_XZ_DEC_TEST is not set
CONFIG_DECOMPRESS_GZIP=y
CONFIG_DECOMPRESS_BZIP2=y
CONFIG_DECOMPRESS_LZMA=y
CONFIG_DECOMPRESS_XZ=y
CONFIG_DECOMPRESS_LZO=y
CONFIG_BCH=y
CONFIG_BCH_CONST_PARAMS=y
CONFIG_TEXTSEARCH=y
CONFIG_TEXTSEARCH_KMP=y
CONFIG_TEXTSEARCH_BM=y
CONFIG_TEXTSEARCH_FSM=y
CONFIG_HAS_IOMEM=y
CONFIG_HAS_IOPORT=y
CONFIG_HAS_DMA=y
CONFIG_CHECK_SIGNATURE=y
CONFIG_DQL=y
CONFIG_NLATTR=y
CONFIG_AVERAGE=y
# CONFIG_CORDIC is not set
CONFIG_MPILIB=y
CONFIG_MPILIB_EXTRA=y
# CONFIG_DIGSIG is not set

--------------070407000708080709040807
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--------------070407000708080709040807--


From xen-devel-bounces@lists.xensource.com Wed Dec 21 19:12:51 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 19:12:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdRaI-0004xk-RH; Wed, 21 Dec 2011 19:12:14 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <rdunlap@xenotime.net>) id 1RdRaH-0004xb-5R
	for xen-devel@lists.xensource.com; Wed, 21 Dec 2011 19:12:13 +0000
X-Env-Sender: rdunlap@xenotime.net
X-Msg-Ref: server-15.tower-27.messagelabs.com!1324494709!59863081!1
X-Originating-IP: [67.222.38.55]
X-SpamReason: No, hits=3.5 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA2Ny4yMjIuMzguNTUgPT4gMzQ1NDc=\n,sa_preprocessor: 
	QmFkIElQOiA2Ny4yMjIuMzguNTUgPT4gMzQ1NDc=\n, UNIQUE_WORDS,
	UPPERCASE_75_100
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3821 invoked from network); 21 Dec 2011 19:11:49 -0000
Received: from oproxy5-pub.bluehost.com (HELO oproxy5-pub.bluehost.com)
	(67.222.38.55) by server-15.tower-27.messagelabs.com with SMTP;
	21 Dec 2011 19:11:49 -0000
Received: (qmail 17191 invoked by uid 0); 21 Dec 2011 19:12:07 -0000
Received: from unknown (HELO box742.bluehost.com) (66.147.244.242)
	by cpoproxy2.bluehost.com with SMTP; 21 Dec 2011 19:11:16 -0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenotime.net;
	s=default; 
	h=Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID;
	bh=fbYDPNJosMkGaF7Z7n0ecB8B+bPYvArZweGnLIn+TSg=; 
	b=AKtvYlXzLHgBynPNakbFzklcQKjje1SrYRIy1uwRA5Fp3/xKTXNoua56XGeZdTn5YpCFnZFimYKFL+4FjhpMMfiJcqaULSyi1bN9DhW8VAvXKBbVhwc++FRXWqzNHeiG;
Received: from static-50-53-38-135.bvtn.or.frontiernet.net ([50.53.38.135]
	helo=[192.168.1.3])
	by box742.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256)
	(Exim 4.76) (envelope-from <rdunlap@xenotime.net>)
	id 1RdRZM-0004oA-59; Wed, 21 Dec 2011 12:11:16 -0700
Message-ID: <4EF23D67.9050602@xenotime.net>
Date: Wed, 21 Dec 2011 12:11:19 -0800
From: Randy Dunlap <rdunlap@xenotime.net>
Organization: YPO4
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.15) Gecko/20110323 Thunderbird/3.1.9
MIME-Version: 1.0
To: Stephen Rothwell <sfr@canb.auug.org.au>
References: <20111221174733.9ba0861e762e8d96844b060b@canb.auug.org.au>
In-Reply-To: <20111221174733.9ba0861e762e8d96844b060b@canb.auug.org.au>
Content-Type: multipart/mixed; boundary="------------070407000708080709040807"
X-Identified-User: {1807:box742.bluehost.com:xenotime:xenotime.net}
	{sentby:smtp auth 50.53.38.135 authed with
	rdunlap@xenotime.net}
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	linux-next@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] linux-next: Tree for Dec 21 (xen)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a multi-part message in MIME format.
--------------070407000708080709040807
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

On 12/20/2011 10:47 PM, Stephen Rothwell wrote:
> Hi all,
> 
> Changes since 20111220:


drivers/xen/xenbus/xenbus_dev_backend.c:74:2: error: implicit declaration of function 'xen_initial_domain'

Full randconfig file is attached.

-- 
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***

--------------070407000708080709040807
Content-Type: text/plain;
 name="config-xenbus"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="config-xenbus"

#
# Automatically generated file; DO NOT EDIT.
# Linux/x86_64 3.2.0-rc6 Kernel Configuration
#
CONFIG_64BIT=y
# CONFIG_X86_32 is not set
CONFIG_X86_64=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_OUTPUT_FORMAT="elf64-x86-64"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig"
CONFIG_GENERIC_CMOS_UPDATE=y
CONFIG_CLOCKSOURCE_WATCHDOG=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_ARCH_CLOCKSOURCE_DATA=y
CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_HAVE_LATENCYTOP_SUPPORT=y
CONFIG_MMU=y
CONFIG_ZONE_DMA=y
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_GENERIC_GPIO=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
# CONFIG_RWSEM_GENERIC_SPINLOCK is not set
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_ARCH_HAS_CPU_IDLE_WAIT=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_GENERIC_TIME_VSYSCALL=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_DEFAULT_IDLE=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ZONE_DMA32=y
CONFIG_AUDIT_ARCH=y
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_ARCH_HWEIGHT_CFLAGS="-fcall-saved-rdi -fcall-saved-rsi -fcall-saved-rdx -fcall-saved-rcx -fcall-saved-r8 -fcall-saved-r9 -fcall-saved-r10 -fcall-saved-r11"
# CONFIG_KTIME_SCALAR is not set
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_CONSTRUCTORS=y
CONFIG_HAVE_IRQ_WORK=y
CONFIG_IRQ_WORK=y

#
# General setup
#
CONFIG_EXPERIMENTAL=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
CONFIG_LOCALVERSION=""
# CONFIG_LOCALVERSION_AUTO is not set
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
# CONFIG_KERNEL_GZIP is not set
# CONFIG_KERNEL_BZIP2 is not set
CONFIG_KERNEL_LZMA=y
# CONFIG_KERNEL_XZ is not set
# CONFIG_KERNEL_LZO is not set
CONFIG_DEFAULT_HOSTNAME="(none)"
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
CONFIG_POSIX_MQUEUE=y
CONFIG_POSIX_MQUEUE_SYSCTL=y
# CONFIG_BSD_PROCESS_ACCT is not set
CONFIG_FHANDLE=y
CONFIG_TASKSTATS=y
CONFIG_TASK_DELAY_ACCT=y
CONFIG_TASK_XACCT=y
CONFIG_TASK_IO_ACCOUNTING=y
# CONFIG_AUDIT is not set
CONFIG_HAVE_GENERIC_HARDIRQS=y

#
# IRQ subsystem
#
CONFIG_GENERIC_HARDIRQS=y
CONFIG_HAVE_SPARSE_IRQ=y
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_GENERIC_IRQ_CHIP=y
CONFIG_IRQ_FORCED_THREADING=y
CONFIG_SPARSE_IRQ=y

#
# RCU Subsystem
#
CONFIG_TINY_PREEMPT_RCU=y
CONFIG_PREEMPT_RCU=y
CONFIG_RCU_TRACE=y
# CONFIG_TREE_RCU_TRACE is not set
# CONFIG_RCU_BOOST is not set
# CONFIG_IKCONFIG is not set
CONFIG_LOG_BUF_SHIFT=17
CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y
CONFIG_CGROUPS=y
# CONFIG_CGROUP_DEBUG is not set
CONFIG_CGROUP_FREEZER=y
# CONFIG_CGROUP_DEVICE is not set
CONFIG_CPUSETS=y
# CONFIG_PROC_PID_CPUSET is not set
# CONFIG_CGROUP_CPUACCT is not set
CONFIG_RESOURCE_COUNTERS=y
# CONFIG_CGROUP_MEM_RES_CTLR is not set
CONFIG_CGROUP_PERF=y
# CONFIG_CGROUP_SCHED is not set
CONFIG_BLK_CGROUP=y
# CONFIG_DEBUG_BLK_CGROUP is not set
# CONFIG_CHECKPOINT_RESTORE is not set
CONFIG_NAMESPACES=y
# CONFIG_UTS_NS is not set
CONFIG_IPC_NS=y
# CONFIG_USER_NS is not set
# CONFIG_PID_NS is not set
CONFIG_NET_NS=y
# CONFIG_SCHED_AUTOGROUP is not set
# CONFIG_SYSFS_DEPRECATED is not set
CONFIG_RELAY=y
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=""
CONFIG_RD_GZIP=y
CONFIG_RD_BZIP2=y
CONFIG_RD_LZMA=y
CONFIG_RD_XZ=y
CONFIG_RD_LZO=y
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
CONFIG_SYSCTL=y
CONFIG_ANON_INODES=y
# CONFIG_EXPERT is not set
CONFIG_UID16=y
# CONFIG_SYSCTL_SYSCALL is not set
CONFIG_KALLSYMS=y
CONFIG_KALLSYMS_ALL=y
CONFIG_HOTPLUG=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_PCSPKR_PLATFORM=y
CONFIG_HAVE_PCSPKR_PLATFORM=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_SIGNALFD=y
CONFIG_TIMERFD=y
CONFIG_EVENTFD=y
CONFIG_SHMEM=y
CONFIG_AIO=y
# CONFIG_EMBEDDED is not set
CONFIG_HAVE_PERF_EVENTS=y
CONFIG_PERF_USE_VMALLOC=y

#
# Kernel Performance Events And Counters
#
CONFIG_PERF_EVENTS=y
# CONFIG_PERF_COUNTERS is not set
CONFIG_DEBUG_PERF_USE_VMALLOC=y
CONFIG_VM_EVENT_COUNTERS=y
CONFIG_PCI_QUIRKS=y
CONFIG_SLUB_DEBUG=y
CONFIG_COMPAT_BRK=y
# CONFIG_SLAB is not set
CONFIG_SLUB=y
# CONFIG_PROFILING is not set
CONFIG_TRACEPOINTS=y
CONFIG_HAVE_OPROFILE=y
CONFIG_OPROFILE_NMI_TIMER=y
# CONFIG_JUMP_LABEL is not set
CONFIG_UPROBES=y
CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS=y
CONFIG_USER_RETURN_NOTIFIER=y
CONFIG_HAVE_IOREMAP_PROT=y
CONFIG_HAVE_KPROBES=y
CONFIG_HAVE_KRETPROBES=y
CONFIG_HAVE_OPTPROBES=y
CONFIG_HAVE_ARCH_TRACEHOOK=y
CONFIG_HAVE_DMA_ATTRS=y
CONFIG_HAVE_REGS_AND_STACK_ACCESS_API=y
CONFIG_HAVE_DMA_API_DEBUG=y
CONFIG_HAVE_HW_BREAKPOINT=y
CONFIG_HAVE_MIXED_BREAKPOINTS_REGS=y
CONFIG_HAVE_USER_RETURN_NOTIFIER=y
CONFIG_HAVE_PERF_EVENTS_NMI=y
CONFIG_HAVE_ARCH_JUMP_LABEL=y
CONFIG_ARCH_HAVE_NMI_SAFE_CMPXCHG=y
CONFIG_HAVE_ALIGNED_STRUCT_PAGE=y
CONFIG_HAVE_CMPXCHG_LOCAL=y
CONFIG_HAVE_CMPXCHG_DOUBLE=y

#
# GCOV-based kernel profiling
#
CONFIG_GCOV_KERNEL=y
# CONFIG_GCOV_PROFILE_ALL is not set
# CONFIG_HAVE_GENERIC_DMA_COHERENT is not set
CONFIG_SLABINFO=y
CONFIG_RT_MUTEXES=y
CONFIG_BASE_SMALL=0
# CONFIG_MODULES is not set
CONFIG_BLOCK=y
CONFIG_BLK_DEV_BSG=y
CONFIG_BLK_DEV_BSGLIB=y
# CONFIG_BLK_DEV_INTEGRITY is not set
# CONFIG_BLK_DEV_THROTTLING is not set
CONFIG_BLOCK_COMPAT=y

#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_DEADLINE=y
# CONFIG_IOSCHED_CFQ is not set
# CONFIG_DEFAULT_DEADLINE is not set
CONFIG_DEFAULT_NOOP=y
CONFIG_DEFAULT_IOSCHED="noop"
CONFIG_PREEMPT_NOTIFIERS=y
# CONFIG_INLINE_SPIN_TRYLOCK is not set
# CONFIG_INLINE_SPIN_TRYLOCK_BH is not set
# CONFIG_INLINE_SPIN_LOCK is not set
# CONFIG_INLINE_SPIN_LOCK_BH is not set
# CONFIG_INLINE_SPIN_LOCK_IRQ is not set
# CONFIG_INLINE_SPIN_LOCK_IRQSAVE is not set
# CONFIG_INLINE_SPIN_UNLOCK is not set
# CONFIG_INLINE_SPIN_UNLOCK_BH is not set
# CONFIG_INLINE_SPIN_UNLOCK_IRQ is not set
# CONFIG_INLINE_SPIN_UNLOCK_IRQRESTORE is not set
# CONFIG_INLINE_READ_TRYLOCK is not set
# CONFIG_INLINE_READ_LOCK is not set
# CONFIG_INLINE_READ_LOCK_BH is not set
# CONFIG_INLINE_READ_LOCK_IRQ is not set
# CONFIG_INLINE_READ_LOCK_IRQSAVE is not set
# CONFIG_INLINE_READ_UNLOCK is not set
# CONFIG_INLINE_READ_UNLOCK_BH is not set
# CONFIG_INLINE_READ_UNLOCK_IRQ is not set
# CONFIG_INLINE_READ_UNLOCK_IRQRESTORE is not set
# CONFIG_INLINE_WRITE_TRYLOCK is not set
# CONFIG_INLINE_WRITE_LOCK is not set
# CONFIG_INLINE_WRITE_LOCK_BH is not set
# CONFIG_INLINE_WRITE_LOCK_IRQ is not set
# CONFIG_INLINE_WRITE_LOCK_IRQSAVE is not set
# CONFIG_INLINE_WRITE_UNLOCK is not set
# CONFIG_INLINE_WRITE_UNLOCK_BH is not set
# CONFIG_INLINE_WRITE_UNLOCK_IRQ is not set
# CONFIG_INLINE_WRITE_UNLOCK_IRQRESTORE is not set
# CONFIG_MUTEX_SPIN_ON_OWNER is not set
CONFIG_FREEZER=y

#
# Processor type and features
#
CONFIG_TICK_ONESHOT=y
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y
CONFIG_GENERIC_CLOCKEVENTS_BUILD=y
CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y
# CONFIG_SMP is not set
CONFIG_X86_MPPARSE=y
CONFIG_X86_EXTENDED_PLATFORM=y
CONFIG_X86_VSMP=y
# CONFIG_SCHED_OMIT_FRAME_POINTER is not set
# CONFIG_KVMTOOL_TEST_ENABLE is not set
CONFIG_PARAVIRT_GUEST=y
# CONFIG_PARAVIRT_TIME_ACCOUNTING is not set
CONFIG_XEN=y
CONFIG_XEN_DOM0=y
CONFIG_XEN_PRIVILEGED_GUEST=y
CONFIG_XEN_PVHVM=y
CONFIG_XEN_MAX_DOMAIN_MEMORY=500
CONFIG_XEN_SAVE_RESTORE=y
# CONFIG_XEN_DEBUG_FS is not set
# CONFIG_KVM_CLOCK is not set
# CONFIG_KVM_GUEST is not set
CONFIG_PARAVIRT=y
CONFIG_PARAVIRT_CLOCK=y
CONFIG_PARAVIRT_DEBUG=y
CONFIG_NO_BOOTMEM=y
CONFIG_MEMTEST=y
# CONFIG_MK8 is not set
# CONFIG_MPSC is not set
# CONFIG_MCORE2 is not set
# CONFIG_MATOM is not set
CONFIG_GENERIC_CPU=y
CONFIG_X86_INTERNODE_CACHE_SHIFT=12
CONFIG_X86_CMPXCHG=y
CONFIG_X86_L1_CACHE_SHIFT=6
CONFIG_X86_XADD=y
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_TSC=y
CONFIG_X86_CMPXCHG64=y
CONFIG_X86_CMOV=y
CONFIG_X86_MINIMUM_CPU_FAMILY=64
CONFIG_X86_DEBUGCTLMSR=y
CONFIG_CPU_SUP_INTEL=y
CONFIG_CPU_SUP_AMD=y
CONFIG_CPU_SUP_CENTAUR=y
CONFIG_HPET_TIMER=y
CONFIG_HPET_EMULATE_RTC=y
CONFIG_DMI=y
CONFIG_GART_IOMMU=y
CONFIG_CALGARY_IOMMU=y
# CONFIG_CALGARY_IOMMU_ENABLED_BY_DEFAULT is not set
CONFIG_SWIOTLB=y
CONFIG_IOMMU_HELPER=y
CONFIG_NR_CPUS=1
# CONFIG_IRQ_TIME_ACCOUNTING is not set
# CONFIG_PREEMPT_NONE is not set
# CONFIG_PREEMPT_VOLUNTARY is not set
CONFIG_PREEMPT=y
CONFIG_PREEMPT_COUNT=y
CONFIG_X86_LOCAL_APIC=y
CONFIG_X86_IO_APIC=y
CONFIG_X86_REROUTE_FOR_BROKEN_BOOT_IRQS=y
# CONFIG_X86_MCE is not set
# CONFIG_I8K is not set
# CONFIG_MICROCODE is not set
CONFIG_X86_MSR=y
# CONFIG_X86_CPUID is not set
CONFIG_ARCH_PHYS_ADDR_T_64BIT=y
CONFIG_ARCH_DMA_ADDR_T_64BIT=y
CONFIG_DIRECT_GBPAGES=y
CONFIG_ARCH_SPARSEMEM_ENABLE=y
CONFIG_ARCH_SPARSEMEM_DEFAULT=y
CONFIG_ARCH_SELECT_MEMORY_MODEL=y
CONFIG_ARCH_PROC_KCORE_TEXT=y
CONFIG_ILLEGAL_POINTER_VALUE=0xdead000000000000
CONFIG_SELECT_MEMORY_MODEL=y
CONFIG_SPARSEMEM_MANUAL=y
CONFIG_SPARSEMEM=y
CONFIG_HAVE_MEMORY_PRESENT=y
CONFIG_SPARSEMEM_EXTREME=y
CONFIG_SPARSEMEM_VMEMMAP_ENABLE=y
CONFIG_SPARSEMEM_ALLOC_MEM_MAP_TOGETHER=y
CONFIG_SPARSEMEM_VMEMMAP=y
CONFIG_HAVE_MEMBLOCK=y
CONFIG_HAVE_MEMBLOCK_NODE_MAP=y
CONFIG_ARCH_DISCARD_MEMBLOCK=y
# CONFIG_MEMORY_HOTPLUG is not set
CONFIG_PAGEFLAGS_EXTENDED=y
CONFIG_SPLIT_PTLOCK_CPUS=999999
CONFIG_COMPACTION=y
CONFIG_MIGRATION=y
CONFIG_PHYS_ADDR_T_64BIT=y
CONFIG_ZONE_DMA_FLAG=1
CONFIG_BOUNCE=y
CONFIG_VIRT_TO_BUS=y
CONFIG_MMU_NOTIFIER=y
CONFIG_KSM=y
CONFIG_DEFAULT_MMAP_MIN_ADDR=4096
CONFIG_TRANSPARENT_HUGEPAGE=y
# CONFIG_TRANSPARENT_HUGEPAGE_ALWAYS is not set
CONFIG_TRANSPARENT_HUGEPAGE_MADVISE=y
CONFIG_NEED_PER_CPU_KM=y
CONFIG_CLEANCACHE=y
CONFIG_FRONTSWAP=y
CONFIG_X86_CHECK_BIOS_CORRUPTION=y
CONFIG_X86_BOOTPARAM_MEMORY_CORRUPTION_CHECK=y
CONFIG_X86_RESERVE_LOW=64
CONFIG_MTRR=y
CONFIG_MTRR_SANITIZER=y
CONFIG_MTRR_SANITIZER_ENABLE_DEFAULT=0
CONFIG_MTRR_SANITIZER_SPARE_REG_NR_DEFAULT=1
CONFIG_X86_PAT=y
CONFIG_ARCH_USES_PG_UNCACHED=y
CONFIG_ARCH_RANDOM=y
CONFIG_EFI=y
CONFIG_EFI_STUB=y
CONFIG_SECCOMP=y
# CONFIG_CC_STACKPROTECTOR is not set
# CONFIG_HZ_100 is not set
CONFIG_HZ_250=y
# CONFIG_HZ_300 is not set
# CONFIG_HZ_1000 is not set
CONFIG_HZ=250
CONFIG_SCHED_HRTICK=y
# CONFIG_KEXEC is not set
# CONFIG_CRASH_DUMP is not set
CONFIG_PHYSICAL_START=0x1000000
CONFIG_RELOCATABLE=y
CONFIG_PHYSICAL_ALIGN=0x1000000
CONFIG_COMPAT_VDSO=y
CONFIG_CMDLINE_BOOL=y
CONFIG_CMDLINE=""
# CONFIG_CMDLINE_OVERRIDE is not set
CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y

#
# Power management and ACPI options
#
CONFIG_ARCH_HIBERNATION_HEADER=y
# CONFIG_SUSPEND is not set
CONFIG_HIBERNATE_CALLBACKS=y
CONFIG_HIBERNATION=y
CONFIG_PM_STD_PARTITION=""
CONFIG_PM_SLEEP=y
# CONFIG_PM_RUNTIME is not set
CONFIG_PM=y
CONFIG_PM_DEBUG=y
# CONFIG_PM_ADVANCED_DEBUG is not set
CONFIG_CAN_PM_TRACE=y
# CONFIG_PM_TRACE_RTC is not set
CONFIG_ACPI=y
CONFIG_ACPI_SLEEP=y
CONFIG_ACPI_PROCFS=y
# CONFIG_ACPI_PROCFS_POWER is not set
# CONFIG_ACPI_EC_DEBUGFS is not set
CONFIG_ACPI_PROC_EVENT=y
# CONFIG_ACPI_AC is not set
CONFIG_ACPI_BATTERY=y
CONFIG_ACPI_BUTTON=y
CONFIG_ACPI_VIDEO=y
CONFIG_ACPI_FAN=y
CONFIG_ACPI_DOCK=y
CONFIG_ACPI_PROCESSOR=y
CONFIG_ACPI_PROCESSOR_AGGREGATOR=y
# CONFIG_ACPI_THERMAL is not set
# CONFIG_ACPI_CUSTOM_DSDT is not set
CONFIG_ACPI_BLACKLIST_YEAR=0
# CONFIG_ACPI_DEBUG is not set
# CONFIG_ACPI_PCI_SLOT is not set
CONFIG_X86_PM_TIMER=y
# CONFIG_ACPI_CONTAINER is not set
CONFIG_ACPI_SBS=y
CONFIG_ACPI_HED=y
CONFIG_ACPI_CUSTOM_METHOD=y
CONFIG_ACPI_APEI=y
# CONFIG_ACPI_APEI_GHES is not set
# CONFIG_ACPI_APEI_PCIEAER is not set
CONFIG_ACPI_APEI_EINJ=y
# CONFIG_ACPI_APEI_ERST_DEBUG is not set
# CONFIG_SFI is not set

#
# CPU Frequency scaling
#
# CONFIG_CPU_FREQ is not set
CONFIG_CPU_IDLE=y
CONFIG_CPU_IDLE_GOV_LADDER=y
CONFIG_CPU_IDLE_GOV_MENU=y
# CONFIG_INTEL_IDLE is not set

#
# Memory power savings
#
# CONFIG_I7300_IDLE is not set

#
# Bus options (PCI etc.)
#
CONFIG_PCI=y
CONFIG_PCI_DIRECT=y
CONFIG_PCI_MMCONFIG=y
CONFIG_PCI_XEN=y
CONFIG_PCI_DOMAINS=y
# CONFIG_PCI_CNB20LE_QUIRK is not set
CONFIG_PCIEPORTBUS=y
# CONFIG_HOTPLUG_PCI_PCIE is not set
CONFIG_PCIEAER=y
CONFIG_PCIE_ECRC=y
# CONFIG_PCIEAER_INJECT is not set
CONFIG_PCIEASPM=y
CONFIG_PCIEASPM_DEBUG=y
CONFIG_ARCH_SUPPORTS_MSI=y
# CONFIG_PCI_MSI is not set
# CONFIG_PCI_DEBUG is not set
# CONFIG_PCI_STUB is not set
CONFIG_XEN_PCIDEV_FRONTEND=y
# CONFIG_HT_IRQ is not set
CONFIG_PCI_ATS=y
CONFIG_PCI_IOV=y
# CONFIG_PCI_PRI is not set
# CONFIG_PCI_PASID is not set
CONFIG_PCI_IOAPIC=y
CONFIG_PCI_LABEL=y
CONFIG_ISA_DMA_API=y
CONFIG_AMD_NB=y
CONFIG_PCCARD=y
# CONFIG_PCMCIA is not set
CONFIG_CARDBUS=y

#
# PC-card bridges
#
CONFIG_YENTA=y
CONFIG_YENTA_O2=y
CONFIG_YENTA_RICOH=y
CONFIG_YENTA_TI=y
CONFIG_YENTA_ENE_TUNE=y
CONFIG_YENTA_TOSHIBA=y
CONFIG_HOTPLUG_PCI=y
# CONFIG_HOTPLUG_PCI_FAKE is not set
# CONFIG_HOTPLUG_PCI_ACPI is not set
# CONFIG_HOTPLUG_PCI_CPCI is not set
# CONFIG_HOTPLUG_PCI_SHPC is not set
CONFIG_RAPIDIO=y
# CONFIG_RAPIDIO_TSI721 is not set
CONFIG_RAPIDIO_DISC_TIMEOUT=30
# CONFIG_RAPIDIO_ENABLE_RX_TX_PORTS is not set
CONFIG_RAPIDIO_DEBUG=y
# CONFIG_RAPIDIO_TSI57X is not set
# CONFIG_RAPIDIO_CPS_XX is not set
CONFIG_RAPIDIO_TSI568=y
# CONFIG_RAPIDIO_CPS_GEN2 is not set
# CONFIG_RAPIDIO_TSI500 is not set

#
# Executable file formats / Emulations
#
# CONFIG_BINFMT_ELF is not set
CONFIG_COMPAT_BINFMT_ELF=y
CONFIG_ARCH_BINFMT_ELF_RANDOMIZE_PIE=y
# CONFIG_HAVE_AOUT is not set
# CONFIG_BINFMT_MISC is not set
CONFIG_IA32_EMULATION=y
# CONFIG_IA32_AOUT is not set
CONFIG_COMPAT=y
CONFIG_COMPAT_FOR_U64_ALIGNMENT=y
CONFIG_SYSVIPC_COMPAT=y
CONFIG_KEYS_COMPAT=y
CONFIG_HAVE_TEXT_POKE_SMP=y
CONFIG_NET=y
CONFIG_COMPAT_NETLINK_MESSAGES=y

#
# Networking options
#
# CONFIG_PACKET is not set
CONFIG_UNIX=y
# CONFIG_UNIX_DIAG is not set
CONFIG_XFRM=y
CONFIG_XFRM_SUB_POLICY=y
CONFIG_XFRM_MIGRATE=y
CONFIG_NET_KEY=y
CONFIG_NET_KEY_MIGRATE=y
# CONFIG_INET is not set
CONFIG_NETWORK_SECMARK=y
# CONFIG_NETWORK_PHY_TIMESTAMPING is not set
CONFIG_NETFILTER=y
CONFIG_NETFILTER_DEBUG=y
# CONFIG_NETFILTER_ADVANCED is not set
CONFIG_ATM=y
CONFIG_ATM_LANE=y
# CONFIG_BRIDGE is not set
CONFIG_NET_DSA=y
CONFIG_NET_DSA_TAG_DSA=y
CONFIG_NET_DSA_TAG_EDSA=y
CONFIG_NET_DSA_TAG_TRAILER=y
# CONFIG_VLAN_8021Q is not set
# CONFIG_DECNET is not set
CONFIG_LLC=y
CONFIG_LLC2=y
CONFIG_IPX=y
CONFIG_IPX_INTERN=y
# CONFIG_ATALK is not set
CONFIG_X25=y
# CONFIG_LAPB is not set
# CONFIG_WAN_ROUTER is not set
CONFIG_PHONET=y
# CONFIG_IEEE802154 is not set
CONFIG_NET_SCHED=y

#
# Queueing/Scheduling
#
# CONFIG_NET_SCH_CBQ is not set
CONFIG_NET_SCH_HTB=y
CONFIG_NET_SCH_HFSC=y
CONFIG_NET_SCH_ATM=y
# CONFIG_NET_SCH_PRIO is not set
# CONFIG_NET_SCH_MULTIQ is not set
CONFIG_NET_SCH_RED=y
CONFIG_NET_SCH_SFB=y
CONFIG_NET_SCH_SFQ=y
# CONFIG_NET_SCH_TEQL is not set
CONFIG_NET_SCH_TBF=y
# CONFIG_NET_SCH_GRED is not set
# CONFIG_NET_SCH_DSMARK is not set
# CONFIG_NET_SCH_NETEM is not set
CONFIG_NET_SCH_DRR=y
# CONFIG_NET_SCH_MQPRIO is not set
# CONFIG_NET_SCH_CHOKE is not set
CONFIG_NET_SCH_QFQ=y

#
# Classification
#
CONFIG_NET_CLS=y
# CONFIG_NET_CLS_BASIC is not set
# CONFIG_NET_CLS_TCINDEX is not set
CONFIG_NET_CLS_FW=y
# CONFIG_NET_CLS_U32 is not set
# CONFIG_NET_CLS_RSVP is not set
# CONFIG_NET_CLS_RSVP6 is not set
CONFIG_NET_CLS_FLOW=y
CONFIG_NET_CLS_CGROUP=y
CONFIG_NET_EMATCH=y
CONFIG_NET_EMATCH_STACK=32
# CONFIG_NET_EMATCH_CMP is not set
CONFIG_NET_EMATCH_NBYTE=y
# CONFIG_NET_EMATCH_U32 is not set
CONFIG_NET_EMATCH_META=y
CONFIG_NET_EMATCH_TEXT=y
# CONFIG_NET_CLS_ACT is not set
CONFIG_NET_CLS_IND=y
CONFIG_NET_SCH_FIFO=y
# CONFIG_DCB is not set
# CONFIG_DNS_RESOLVER is not set
# CONFIG_BATMAN_ADV is not set
CONFIG_OPENVSWITCH=y
CONFIG_NETPRIO_CGROUP=y
CONFIG_BQL=y
CONFIG_HAVE_BPF_JIT=y

#
# Network testing
#
CONFIG_NET_PKTGEN=y
# CONFIG_HAMRADIO is not set
# CONFIG_CAN is not set
CONFIG_IRDA=y

#
# IrDA protocols
#
CONFIG_IRLAN=y
# CONFIG_IRCOMM is not set
CONFIG_IRDA_ULTRA=y

#
# IrDA options
#
# CONFIG_IRDA_CACHE_LAST_LSAP is not set
# CONFIG_IRDA_FAST_RR is not set
CONFIG_IRDA_DEBUG=y

#
# Infrared-port device drivers
#

#
# SIR device drivers
#
# CONFIG_IRTTY_SIR is not set

#
# Dongle support
#

#
# FIR device drivers
#
# CONFIG_NSC_FIR is not set
# CONFIG_WINBOND_FIR is not set
CONFIG_SMC_IRCC_FIR=y
CONFIG_ALI_FIR=y
CONFIG_VLSI_FIR=y
# CONFIG_VIA_FIR is not set
# CONFIG_BT is not set
CONFIG_WIRELESS=y
CONFIG_WIRELESS_EXT=y
CONFIG_WEXT_CORE=y
CONFIG_WEXT_PROC=y
CONFIG_WEXT_SPY=y
CONFIG_WEXT_PRIV=y
# CONFIG_CFG80211 is not set
CONFIG_WIRELESS_EXT_SYSFS=y
# CONFIG_LIB80211 is not set

#
# CFG80211 needs to be enabled for MAC80211
#
CONFIG_WIMAX=y
CONFIG_WIMAX_DEBUG_LEVEL=8
# CONFIG_RFKILL is not set
CONFIG_RFKILL_REGULATOR=y
CONFIG_NET_9P=y
# CONFIG_NET_9P_VIRTIO is not set
CONFIG_NET_9P_DEBUG=y
# CONFIG_CAIF is not set
# CONFIG_NFC is not set

#
# Device Drivers
#

#
# Generic Driver Options
#
CONFIG_UEVENT_HELPER_PATH=""
# CONFIG_DEVTMPFS is not set
CONFIG_STANDALONE=y
CONFIG_PREVENT_FIRMWARE_BUILD=y
CONFIG_FW_LOADER=y
CONFIG_FIRMWARE_IN_KERNEL=y
CONFIG_EXTRA_FIRMWARE=""
# CONFIG_DEBUG_DRIVER is not set
# CONFIG_DEBUG_DEVRES is not set
CONFIG_SYS_HYPERVISOR=y
CONFIG_REGMAP=y
CONFIG_REGMAP_I2C=y
CONFIG_REGMAP_SPI=y
CONFIG_REGMAP_IRQ=y
CONFIG_CONNECTOR=y
# CONFIG_PROC_EVENTS is not set
CONFIG_MTD=y
# CONFIG_MTD_REDBOOT_PARTS is not set
CONFIG_MTD_CMDLINE_PARTS=y
# CONFIG_MTD_AR7_PARTS is not set

#
# User Modules And Translation Layers
#
# CONFIG_MTD_CHAR is not set
CONFIG_HAVE_MTD_OTP=y
CONFIG_MTD_BLKDEVS=y
CONFIG_MTD_BLOCK=y
CONFIG_FTL=y
CONFIG_NFTL=y
# CONFIG_NFTL_RW is not set
CONFIG_INFTL=y
CONFIG_RFD_FTL=y
CONFIG_SSFDC=y
# CONFIG_SM_FTL is not set
CONFIG_MTD_OOPS=y
CONFIG_MTD_SWAP=y

#
# RAM/ROM/Flash chip drivers
#
CONFIG_MTD_CFI=y
CONFIG_MTD_JEDECPROBE=y
CONFIG_MTD_GEN_PROBE=y
CONFIG_MTD_CFI_ADV_OPTIONS=y
# CONFIG_MTD_CFI_NOSWAP is not set
CONFIG_MTD_CFI_BE_BYTE_SWAP=y
# CONFIG_MTD_CFI_LE_BYTE_SWAP is not set
CONFIG_MTD_CFI_GEOMETRY=y
# CONFIG_MTD_MAP_BANK_WIDTH_1 is not set
CONFIG_MTD_MAP_BANK_WIDTH_2=y
# CONFIG_MTD_MAP_BANK_WIDTH_4 is not set
# CONFIG_MTD_MAP_BANK_WIDTH_8 is not set
CONFIG_MTD_MAP_BANK_WIDTH_16=y
# CONFIG_MTD_MAP_BANK_WIDTH_32 is not set
CONFIG_MTD_CFI_I1=y
CONFIG_MTD_CFI_I2=y
CONFIG_MTD_CFI_I4=y
# CONFIG_MTD_CFI_I8 is not set
CONFIG_MTD_OTP=y
CONFIG_MTD_CFI_INTELEXT=y
CONFIG_MTD_CFI_AMDSTD=y
# CONFIG_MTD_CFI_STAA is not set
CONFIG_MTD_CFI_UTIL=y
CONFIG_MTD_RAM=y
CONFIG_MTD_ROM=y
CONFIG_MTD_ABSENT=y

#
# Mapping drivers for chip access
#
CONFIG_MTD_COMPLEX_MAPPINGS=y
# CONFIG_MTD_PHYSMAP is not set
CONFIG_MTD_SC520CDP=y
# CONFIG_MTD_NETSC520 is not set
CONFIG_MTD_TS5500=y
CONFIG_MTD_SBC_GXX=y
# CONFIG_MTD_AMD76XROM is not set
CONFIG_MTD_ICHXROM=y
# CONFIG_MTD_ESB2ROM is not set
CONFIG_MTD_CK804XROM=y
CONFIG_MTD_SCB2_FLASH=y
# CONFIG_MTD_NETtel is not set
CONFIG_MTD_L440GX=y
# CONFIG_MTD_PCI is not set
CONFIG_MTD_GPIO_ADDR=y
# CONFIG_MTD_INTEL_VR_NOR is not set
CONFIG_MTD_PLATRAM=y
CONFIG_MTD_LATCH_ADDR=y

#
# Self-contained MTD device drivers
#
# CONFIG_MTD_PMC551 is not set
CONFIG_MTD_DATAFLASH=y
# CONFIG_MTD_DATAFLASH_WRITE_VERIFY is not set
# CONFIG_MTD_DATAFLASH_OTP is not set
# CONFIG_MTD_M25P80 is not set
# CONFIG_MTD_SST25L is not set
CONFIG_MTD_SLRAM=y
# CONFIG_MTD_PHRAM is not set
# CONFIG_MTD_MTDRAM is not set
# CONFIG_MTD_BLOCK2MTD is not set

#
# Disk-On-Chip Device Drivers
#
CONFIG_MTD_DOC2000=y
CONFIG_MTD_DOC2001=y
CONFIG_MTD_DOC2001PLUS=y
CONFIG_MTD_DOCG3=y
CONFIG_BCH_CONST_M=14
CONFIG_BCH_CONST_T=4
CONFIG_MTD_DOCPROBE=y
CONFIG_MTD_DOCECC=y
# CONFIG_MTD_DOCPROBE_ADVANCED is not set
CONFIG_MTD_DOCPROBE_ADDRESS=0x0
CONFIG_MTD_NAND_ECC=y
# CONFIG_MTD_NAND_ECC_SMC is not set
CONFIG_MTD_NAND=y
CONFIG_MTD_NAND_VERIFY_WRITE=y
CONFIG_MTD_NAND_BCH=y
CONFIG_MTD_NAND_ECC_BCH=y
# CONFIG_MTD_SM_COMMON is not set
# CONFIG_MTD_NAND_MUSEUM_IDS is not set
CONFIG_MTD_NAND_DENALI=y
CONFIG_MTD_NAND_DENALI_SCRATCH_REG_ADDR=0xFF108018
CONFIG_MTD_NAND_IDS=y
# CONFIG_MTD_NAND_RICOH is not set
# CONFIG_MTD_NAND_DISKONCHIP is not set
# CONFIG_MTD_NAND_CAFE is not set
CONFIG_MTD_NAND_NANDSIM=y
CONFIG_MTD_NAND_PLATFORM=y
CONFIG_MTD_ONENAND=y
# CONFIG_MTD_ONENAND_VERIFY_WRITE is not set
CONFIG_MTD_ONENAND_GENERIC=y
CONFIG_MTD_ONENAND_OTP=y
CONFIG_MTD_ONENAND_2X_PROGRAM=y
# CONFIG_MTD_ONENAND_SIM is not set

#
# LPDDR flash memory drivers
#
CONFIG_MTD_LPDDR=y
CONFIG_MTD_QINFO_PROBE=y
CONFIG_MTD_UBI=y
CONFIG_MTD_UBI_WL_THRESHOLD=4096
CONFIG_MTD_UBI_BEB_RESERVE=1
CONFIG_MTD_UBI_GLUEBI=y
# CONFIG_MTD_UBI_DEBUG is not set
# CONFIG_PARPORT is not set
CONFIG_PNP=y
# CONFIG_PNP_DEBUG_MESSAGES is not set

#
# Protocols
#
CONFIG_PNPACPI=y
CONFIG_BLK_DEV=y
# CONFIG_BLK_DEV_FD is not set
# CONFIG_BLK_CPQ_DA is not set
# CONFIG_BLK_CPQ_CISS_DA is not set
# CONFIG_BLK_DEV_DAC960 is not set
CONFIG_BLK_DEV_UMEM=y
# CONFIG_BLK_DEV_COW_COMMON is not set
# CONFIG_BLK_DEV_LOOP is not set

#
# DRBD disabled because PROC_FS, INET or CONNECTOR not selected
#
CONFIG_BLK_DEV_NBD=y
CONFIG_BLK_DEV_OSD=y
CONFIG_BLK_DEV_SX8=y
# CONFIG_BLK_DEV_RAM is not set
CONFIG_CDROM_PKTCDVD=y
CONFIG_CDROM_PKTCDVD_BUFFERS=8
CONFIG_CDROM_PKTCDVD_WCACHE=y
# CONFIG_ATA_OVER_ETH is not set
CONFIG_XEN_BLKDEV_FRONTEND=y
# CONFIG_XEN_BLKDEV_BACKEND is not set
# CONFIG_VIRTIO_BLK is not set
CONFIG_BLK_DEV_HD=y
# CONFIG_SENSORS_LIS3LV02D is not set
# CONFIG_MISC_DEVICES is not set
CONFIG_HAVE_IDE=y
CONFIG_IDE=y

#
# Please see Documentation/ide/ide.txt for help/info on IDE drives
#
CONFIG_IDE_XFER_MODE=y
CONFIG_IDE_TIMINGS=y
CONFIG_BLK_DEV_IDE_SATA=y
# CONFIG_IDE_GD is not set
CONFIG_BLK_DEV_DELKIN=y
# CONFIG_BLK_DEV_IDECD is not set
# CONFIG_BLK_DEV_IDETAPE is not set
CONFIG_BLK_DEV_IDEACPI=y
# CONFIG_IDE_TASK_IOCTL is not set
# CONFIG_IDE_PROC_FS is not set

#
# IDE chipset support/bugfixes
#
# CONFIG_IDE_GENERIC is not set
# CONFIG_BLK_DEV_PLATFORM is not set
# CONFIG_BLK_DEV_CMD640 is not set
# CONFIG_BLK_DEV_IDEPNP is not set
CONFIG_BLK_DEV_IDEDMA_SFF=y

#
# PCI IDE chipsets support
#
CONFIG_BLK_DEV_IDEPCI=y
CONFIG_IDEPCI_PCIBUS_ORDER=y
# CONFIG_BLK_DEV_OFFBOARD is not set
# CONFIG_BLK_DEV_GENERIC is not set
# CONFIG_BLK_DEV_OPTI621 is not set
# CONFIG_BLK_DEV_RZ1000 is not set
CONFIG_BLK_DEV_IDEDMA_PCI=y
CONFIG_BLK_DEV_AEC62XX=y
# CONFIG_BLK_DEV_ALI15X3 is not set
# CONFIG_BLK_DEV_AMD74XX is not set
CONFIG_BLK_DEV_ATIIXP=y
CONFIG_BLK_DEV_CMD64X=y
CONFIG_BLK_DEV_TRIFLEX=y
# CONFIG_BLK_DEV_CS5520 is not set
CONFIG_BLK_DEV_CS5530=y
CONFIG_BLK_DEV_HPT366=y
# CONFIG_BLK_DEV_JMICRON is not set
# CONFIG_BLK_DEV_SC1200 is not set
# CONFIG_BLK_DEV_PIIX is not set
CONFIG_BLK_DEV_IT8172=y
CONFIG_BLK_DEV_IT8213=y
# CONFIG_BLK_DEV_IT821X is not set
# CONFIG_BLK_DEV_NS87415 is not set
# CONFIG_BLK_DEV_PDC202XX_OLD is not set
CONFIG_BLK_DEV_PDC202XX_NEW=y
CONFIG_BLK_DEV_SVWKS=y
# CONFIG_BLK_DEV_SIIMAGE is not set
# CONFIG_BLK_DEV_SIS5513 is not set
# CONFIG_BLK_DEV_SLC90E66 is not set
# CONFIG_BLK_DEV_TRM290 is not set
# CONFIG_BLK_DEV_VIA82CXXX is not set
# CONFIG_BLK_DEV_TC86C001 is not set
CONFIG_BLK_DEV_IDEDMA=y

#
# SCSI device support
#
CONFIG_SCSI_MOD=y
CONFIG_RAID_ATTRS=y
CONFIG_SCSI=y
CONFIG_SCSI_DMA=y
# CONFIG_SCSI_TGT is not set
CONFIG_SCSI_NETLINK=y
# CONFIG_SCSI_PROC_FS is not set

#
# SCSI support type (disk, tape, CD-ROM)
#
# CONFIG_BLK_DEV_SD is not set
# CONFIG_CHR_DEV_ST is not set
# CONFIG_CHR_DEV_OSST is not set
# CONFIG_BLK_DEV_SR is not set
CONFIG_CHR_DEV_SG=y
# CONFIG_CHR_DEV_SCH is not set
# CONFIG_SCSI_MULTI_LUN is not set
# CONFIG_SCSI_CONSTANTS is not set
# CONFIG_SCSI_LOGGING is not set
# CONFIG_SCSI_SCAN_ASYNC is not set

#
# SCSI Transports
#
CONFIG_SCSI_SPI_ATTRS=y
CONFIG_SCSI_FC_ATTRS=y
CONFIG_SCSI_ISCSI_ATTRS=y
CONFIG_SCSI_SAS_ATTRS=y
CONFIG_SCSI_SAS_LIBSAS=y
CONFIG_SCSI_SAS_HOST_SMP=y
CONFIG_SCSI_SRP_ATTRS=y
CONFIG_SCSI_LOWLEVEL=y
CONFIG_ISCSI_BOOT_SYSFS=y
# CONFIG_SCSI_BNX2_ISCSI is not set
CONFIG_SCSI_BNX2X_FCOE=y
CONFIG_BE2ISCSI=y
# CONFIG_BLK_DEV_3W_XXXX_RAID is not set
CONFIG_SCSI_HPSA=y
CONFIG_SCSI_3W_9XXX=y
CONFIG_SCSI_3W_SAS=y
# CONFIG_SCSI_ACARD is not set
CONFIG_SCSI_AACRAID=y
# CONFIG_SCSI_AIC7XXX is not set
CONFIG_SCSI_AIC7XXX_OLD=y
CONFIG_SCSI_AIC79XX=y
CONFIG_AIC79XX_CMDS_PER_DEVICE=32
CONFIG_AIC79XX_RESET_DELAY_MS=5000
CONFIG_AIC79XX_DEBUG_ENABLE=y
CONFIG_AIC79XX_DEBUG_MASK=0
CONFIG_AIC79XX_REG_PRETTY_PRINT=y
CONFIG_SCSI_AIC94XX=y
CONFIG_AIC94XX_DEBUG=y
CONFIG_SCSI_MVSAS=y
# CONFIG_SCSI_MVSAS_DEBUG is not set
CONFIG_SCSI_MVSAS_TASKLET=y
CONFIG_SCSI_MVUMI=y
CONFIG_SCSI_DPT_I2O=y
CONFIG_SCSI_ADVANSYS=y
CONFIG_SCSI_ARCMSR=y
CONFIG_MEGARAID_NEWGEN=y
CONFIG_MEGARAID_MM=y
# CONFIG_MEGARAID_MAILBOX is not set
# CONFIG_MEGARAID_LEGACY is not set
# CONFIG_MEGARAID_SAS is not set
CONFIG_SCSI_MPT2SAS=y
CONFIG_SCSI_MPT2SAS_MAX_SGE=128
CONFIG_SCSI_MPT2SAS_LOGGING=y
# CONFIG_SCSI_HPTIOP is not set
# CONFIG_SCSI_BUSLOGIC is not set
# CONFIG_VMWARE_PVSCSI is not set
CONFIG_LIBFC=y
CONFIG_LIBFCOE=y
CONFIG_FCOE=y
CONFIG_FCOE_FNIC=y
# CONFIG_SCSI_DMX3191D is not set
CONFIG_SCSI_EATA=y
# CONFIG_SCSI_EATA_TAGGED_QUEUE is not set
CONFIG_SCSI_EATA_LINKED_COMMANDS=y
CONFIG_SCSI_EATA_MAX_TAGS=16
CONFIG_SCSI_FUTURE_DOMAIN=y
# CONFIG_SCSI_GDTH is not set
CONFIG_SCSI_ISCI=y
# CONFIG_SCSI_IPS is not set
CONFIG_SCSI_INITIO=y
# CONFIG_SCSI_INIA100 is not set
# CONFIG_SCSI_STEX is not set
CONFIG_SCSI_SYM53C8XX_2=y
CONFIG_SCSI_SYM53C8XX_DMA_ADDRESSING_MODE=1
CONFIG_SCSI_SYM53C8XX_DEFAULT_TAGS=16
CONFIG_SCSI_SYM53C8XX_MAX_TAGS=64
# CONFIG_SCSI_SYM53C8XX_MMIO is not set
# CONFIG_SCSI_QLOGIC_1280 is not set
CONFIG_SCSI_QLA_FC=y
# CONFIG_SCSI_QLA_ISCSI is not set
CONFIG_SCSI_LPFC=y
# CONFIG_SCSI_LPFC_DEBUG_FS is not set
# CONFIG_SCSI_DC395x is not set
# CONFIG_SCSI_DC390T is not set
# CONFIG_SCSI_DEBUG is not set
CONFIG_SCSI_PMCRAID=y
# CONFIG_SCSI_PM8001 is not set
# CONFIG_SCSI_SRP is not set
CONFIG_SCSI_BFA_FC=y
CONFIG_SCSI_DH=y
# CONFIG_SCSI_DH_RDAC is not set
# CONFIG_SCSI_DH_HP_SW is not set
# CONFIG_SCSI_DH_EMC is not set
# CONFIG_SCSI_DH_ALUA is not set
CONFIG_SCSI_OSD_INITIATOR=y
CONFIG_SCSI_OSD_ULD=y
CONFIG_SCSI_OSD_DPRINT_SENSE=1
# CONFIG_SCSI_OSD_DEBUG is not set
# CONFIG_ATA is not set
CONFIG_MD=y
# CONFIG_BLK_DEV_MD is not set
# CONFIG_BLK_DEV_DM is not set
CONFIG_TARGET_CORE=y
CONFIG_TCM_IBLOCK=y
# CONFIG_TCM_FILEIO is not set
CONFIG_TCM_PSCSI=y
CONFIG_LOOPBACK_TARGET=y
CONFIG_TCM_FC=y
CONFIG_ISCSI_TARGET=y
# CONFIG_FUSION is not set

#
# IEEE 1394 (FireWire) support
#
CONFIG_FIREWIRE=y
CONFIG_FIREWIRE_OHCI=y
CONFIG_FIREWIRE_OHCI_DEBUG=y
CONFIG_FIREWIRE_SBP2=y
# CONFIG_FIREWIRE_NOSY is not set
# CONFIG_I2O is not set
CONFIG_MACINTOSH_DRIVERS=y
# CONFIG_MAC_EMUMOUSEBTN is not set
CONFIG_NETDEVICES=y
CONFIG_NET_CORE=y
# CONFIG_DUMMY is not set
# CONFIG_EQUALIZER is not set
# CONFIG_NET_FC is not set
CONFIG_MII=y
# CONFIG_NET_TEAM is not set
CONFIG_MACVLAN=y
CONFIG_MACVTAP=y
# CONFIG_NETCONSOLE is not set
# CONFIG_NETPOLL is not set
# CONFIG_NET_POLL_CONTROLLER is not set
# CONFIG_RIONET is not set
CONFIG_TUN=y
# CONFIG_VETH is not set
CONFIG_VIRTIO_NET=y
# CONFIG_ARCNET is not set
# CONFIG_ATM_DRIVERS is not set

#
# CAIF transport drivers
#

#
# Distributed Switch Architecture drivers
#
CONFIG_NET_DSA_MV88E6XXX=y
CONFIG_NET_DSA_MV88E6060=y
CONFIG_NET_DSA_MV88E6XXX_NEED_PPU=y
CONFIG_NET_DSA_MV88E6131=y
CONFIG_NET_DSA_MV88E6123_61_65=y
CONFIG_ETHERNET=y
CONFIG_MDIO=y
# CONFIG_NET_VENDOR_3COM is not set
# CONFIG_NET_VENDOR_ADAPTEC is not set
# CONFIG_NET_VENDOR_ALTEON is not set
CONFIG_NET_VENDOR_AMD=y
# CONFIG_AMD8111_ETH is not set
# CONFIG_PCNET32 is not set
CONFIG_NET_VENDOR_ATHEROS=y
# CONFIG_ATL2 is not set
CONFIG_ATL1=y
CONFIG_ATL1E=y
# CONFIG_ATL1C is not set
CONFIG_NET_VENDOR_BROADCOM=y
# CONFIG_B44 is not set
CONFIG_BNX2=y
CONFIG_CNIC=y
# CONFIG_TIGON3 is not set
CONFIG_BNX2X=y
# CONFIG_NET_VENDOR_BROCADE is not set
CONFIG_NET_CALXEDA_XGMAC=y
CONFIG_NET_VENDOR_CHELSIO=y
# CONFIG_CHELSIO_T1 is not set
# CONFIG_CHELSIO_T4 is not set
# CONFIG_CHELSIO_T4VF is not set
CONFIG_DNET=y
CONFIG_NET_VENDOR_DEC=y
CONFIG_NET_TULIP=y
# CONFIG_DE2104X is not set
CONFIG_TULIP=y
# CONFIG_TULIP_MWI is not set
CONFIG_TULIP_MMIO=y
CONFIG_TULIP_NAPI=y
# CONFIG_TULIP_NAPI_HW_MITIGATION is not set
# CONFIG_DE4X5 is not set
CONFIG_WINBOND_840=y
CONFIG_DM9102=y
CONFIG_ULI526X=y
# CONFIG_PCMCIA_XIRCOM is not set
# CONFIG_NET_VENDOR_DLINK is not set
# CONFIG_NET_VENDOR_EXAR is not set
CONFIG_NET_VENDOR_HP=y
CONFIG_HP100=y
# CONFIG_NET_VENDOR_INTEL is not set
# CONFIG_IP1000 is not set
CONFIG_JME=y
CONFIG_NET_VENDOR_MARVELL=y
# CONFIG_SKGE is not set
# CONFIG_SKY2 is not set
# CONFIG_NET_VENDOR_MICREL is not set
# CONFIG_NET_VENDOR_MICROCHIP is not set
# CONFIG_FEALNX is not set
# CONFIG_NET_VENDOR_NATSEMI is not set
# CONFIG_NET_VENDOR_NVIDIA is not set
CONFIG_NET_VENDOR_OKI=y
# CONFIG_PCH_GBE is not set
CONFIG_ETHOC=y
# CONFIG_NET_PACKET_ENGINE is not set
# CONFIG_NET_VENDOR_QLOGIC is not set
CONFIG_NET_VENDOR_REALTEK=y
CONFIG_8139CP=y
# CONFIG_8139TOO is not set
# CONFIG_R8169 is not set
# CONFIG_NET_VENDOR_RDC is not set
CONFIG_NET_VENDOR_SEEQ=y
CONFIG_SEEQ8005=y
CONFIG_NET_VENDOR_SILAN=y
# CONFIG_SC92031 is not set
# CONFIG_NET_VENDOR_SIS is not set
# CONFIG_NET_VENDOR_SMSC is not set
CONFIG_NET_VENDOR_STMICRO=y
CONFIG_STMMAC_ETH=y
CONFIG_STMMAC_DEBUG_FS=y
CONFIG_STMMAC_DA=y
CONFIG_STMMAC_RING=y
# CONFIG_STMMAC_CHAINED is not set
CONFIG_NET_VENDOR_SUN=y
CONFIG_HAPPYMEAL=y
# CONFIG_SUNGEM is not set
CONFIG_CASSINI=y
# CONFIG_NIU is not set
# CONFIG_NET_VENDOR_TEHUTI is not set
CONFIG_NET_VENDOR_TI=y
# CONFIG_TLAN is not set
CONFIG_NET_VENDOR_VIA=y
# CONFIG_VIA_RHINE is not set
# CONFIG_VIA_VELOCITY is not set
CONFIG_FDDI=y
# CONFIG_DEFXX is not set
CONFIG_SKFP=y
CONFIG_NET_SB1000=y
CONFIG_PHYLIB=y

#
# MII PHY device drivers
#
# CONFIG_MARVELL_PHY is not set
# CONFIG_DAVICOM_PHY is not set
CONFIG_QSEMI_PHY=y
CONFIG_LXT_PHY=y
CONFIG_CICADA_PHY=y
CONFIG_VITESSE_PHY=y
# CONFIG_SMSC_PHY is not set
CONFIG_BROADCOM_PHY=y
CONFIG_ICPLUS_PHY=y
CONFIG_REALTEK_PHY=y
# CONFIG_NATIONAL_PHY is not set
# CONFIG_STE10XP is not set
CONFIG_LSI_ET1011C_PHY=y
# CONFIG_MICREL_PHY is not set
CONFIG_FIXED_PHY=y
CONFIG_MDIO_BITBANG=y
CONFIG_MDIO_GPIO=y
CONFIG_MICREL_KS8995MA=y
# CONFIG_PPP is not set
CONFIG_SLIP=y
# CONFIG_SLIP_COMPRESSED is not set
CONFIG_SLIP_SMART=y
CONFIG_SLIP_MODE_SLIP6=y
CONFIG_TR=y
# CONFIG_IBMOL is not set
CONFIG_3C359=y
# CONFIG_TMS380TR is not set
CONFIG_WLAN=y
# CONFIG_AIRO is not set
# CONFIG_ATMEL is not set
CONFIG_PRISM54=y
# CONFIG_HOSTAP is not set

#
# WiMAX Wireless Broadband devices
#

#
# Enable USB support to see WiMAX USB drivers
#

#
# Enable MMC support to see WiMAX SDIO drivers
#
CONFIG_WAN=y
CONFIG_LANMEDIA=y
CONFIG_HDLC=y
CONFIG_HDLC_RAW=y
# CONFIG_HDLC_RAW_ETH is not set
# CONFIG_HDLC_CISCO is not set
# CONFIG_HDLC_FR is not set
CONFIG_HDLC_PPP=y

#
# X.25/LAPB support is disabled
#
CONFIG_PCI200SYN=y
# CONFIG_WANXL is not set
CONFIG_PC300TOO=y
CONFIG_FARSYNC=y
CONFIG_DLCI=y
CONFIG_DLCI_MAX=8
# CONFIG_SBNI is not set
# CONFIG_XEN_NETDEV_FRONTEND is not set
CONFIG_XEN_NETDEV_BACKEND=y
CONFIG_ISDN=y
CONFIG_ISDN_I4L=y
# CONFIG_ISDN_AUDIO is not set
CONFIG_ISDN_X25=y

#
# ISDN feature submodules
#
# CONFIG_ISDN_DRV_LOOP is not set
# CONFIG_ISDN_DIVERSION is not set

#
# ISDN4Linux hardware drivers
#

#
# Passive cards
#
# CONFIG_ISDN_DRV_HISAX is not set

#
# Active cards
#
# CONFIG_ISDN_CAPI is not set
CONFIG_ISDN_DRV_GIGASET=y
CONFIG_GIGASET_I4L=y
# CONFIG_GIGASET_DUMMYLL is not set
CONFIG_GIGASET_M101=y
# CONFIG_GIGASET_DEBUG is not set
CONFIG_MISDN=y
CONFIG_MISDN_DSP=y
# CONFIG_MISDN_L1OIP is not set

#
# mISDN hardware drivers
#
CONFIG_MISDN_HFCPCI=y
# CONFIG_MISDN_HFCMULTI is not set
CONFIG_MISDN_AVMFRITZ=y
# CONFIG_MISDN_SPEEDFAX is not set
# CONFIG_MISDN_INFINEON is not set
CONFIG_MISDN_W6692=y
CONFIG_MISDN_NETJET=y
CONFIG_MISDN_IPAC=y
CONFIG_ISDN_HDLC=y
# CONFIG_PHONE is not set

#
# Input device support
#
CONFIG_INPUT=y
# CONFIG_INPUT_FF_MEMLESS is not set
CONFIG_INPUT_POLLDEV=y
CONFIG_INPUT_SPARSEKMAP=y

#
# Userland interfaces
#
CONFIG_INPUT_MOUSEDEV=y
CONFIG_INPUT_MOUSEDEV_PSAUX=y
CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024
CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768
CONFIG_INPUT_JOYDEV=y
# CONFIG_INPUT_EVDEV is not set
CONFIG_INPUT_EVBUG=y

#
# Input Device Drivers
#
CONFIG_INPUT_KEYBOARD=y
# CONFIG_KEYBOARD_ADP5588 is not set
CONFIG_KEYBOARD_ADP5589=y
CONFIG_KEYBOARD_ATKBD=y
CONFIG_KEYBOARD_QT1070=y
# CONFIG_KEYBOARD_QT2160 is not set
CONFIG_KEYBOARD_LKKBD=y
# CONFIG_KEYBOARD_GPIO is not set
# CONFIG_KEYBOARD_GPIO_POLLED is not set
CONFIG_KEYBOARD_TCA6416=y
# CONFIG_KEYBOARD_TCA8418 is not set
CONFIG_KEYBOARD_MATRIX=y
CONFIG_KEYBOARD_LM8323=y
# CONFIG_KEYBOARD_MAX7359 is not set
CONFIG_KEYBOARD_MCS=y
CONFIG_KEYBOARD_MPR121=y
CONFIG_KEYBOARD_NEWTON=y
CONFIG_KEYBOARD_OPENCORES=y
# CONFIG_KEYBOARD_STOWAWAY is not set
CONFIG_KEYBOARD_SUNKBD=y
# CONFIG_KEYBOARD_TC3589X is not set
CONFIG_KEYBOARD_XTKBD=y
CONFIG_INPUT_MOUSE=y
CONFIG_MOUSE_PS2=y
CONFIG_MOUSE_PS2_ALPS=y
CONFIG_MOUSE_PS2_LOGIPS2PP=y
CONFIG_MOUSE_PS2_SYNAPTICS=y
CONFIG_MOUSE_PS2_LIFEBOOK=y
CONFIG_MOUSE_PS2_TRACKPOINT=y
CONFIG_MOUSE_PS2_ELANTECH=y
# CONFIG_MOUSE_PS2_SENTELIC is not set
# CONFIG_MOUSE_PS2_TOUCHKIT is not set
CONFIG_MOUSE_SERIAL=y
CONFIG_MOUSE_VSXXXAA=y
# CONFIG_MOUSE_GPIO is not set
CONFIG_MOUSE_SYNAPTICS_I2C=y
# CONFIG_INPUT_JOYSTICK is not set
CONFIG_INPUT_TABLET=y
# CONFIG_INPUT_TOUCHSCREEN is not set
CONFIG_INPUT_MISC=y
CONFIG_INPUT_88PM860X_ONKEY=y
# CONFIG_INPUT_AD714X is not set
CONFIG_INPUT_BMA150=y
# CONFIG_INPUT_PCSPKR is not set
# CONFIG_INPUT_MMA8450 is not set
CONFIG_INPUT_MPU3050=y
# CONFIG_INPUT_APANEL is not set
# CONFIG_INPUT_GP2A is not set
CONFIG_INPUT_GPIO_TILT_POLLED=y
CONFIG_INPUT_ATLAS_BTNS=y
# CONFIG_INPUT_KXTJ9 is not set
# CONFIG_INPUT_UINPUT is not set
# CONFIG_INPUT_PCF8574 is not set
CONFIG_INPUT_GPIO_ROTARY_ENCODER=y
# CONFIG_INPUT_WM831X_ON is not set
# CONFIG_INPUT_PCAP is not set
CONFIG_INPUT_ADXL34X=y
CONFIG_INPUT_ADXL34X_I2C=y
CONFIG_INPUT_ADXL34X_SPI=y
# CONFIG_INPUT_CMA3000 is not set

#
# Hardware I/O ports
#
CONFIG_SERIO=y
CONFIG_SERIO_I8042=y
CONFIG_SERIO_SERPORT=y
CONFIG_SERIO_CT82C710=y
CONFIG_SERIO_PCIPS2=y
CONFIG_SERIO_LIBPS2=y
# CONFIG_SERIO_RAW is not set
CONFIG_SERIO_ALTERA_PS2=y
# CONFIG_SERIO_PS2MULT is not set
CONFIG_GAMEPORT=y
# CONFIG_GAMEPORT_NS558 is not set
CONFIG_GAMEPORT_L4=y
CONFIG_GAMEPORT_EMU10K1=y
# CONFIG_GAMEPORT_FM801 is not set

#
# Character devices
#
CONFIG_VT=y
CONFIG_CONSOLE_TRANSLATIONS=y
CONFIG_VT_CONSOLE=y
CONFIG_VT_CONSOLE_SLEEP=y
CONFIG_HW_CONSOLE=y
# CONFIG_VT_HW_CONSOLE_BINDING is not set
CONFIG_UNIX98_PTYS=y
CONFIG_DEVPTS_MULTIPLE_INSTANCES=y
CONFIG_LEGACY_PTYS=y
CONFIG_LEGACY_PTY_COUNT=256
CONFIG_SERIAL_NONSTANDARD=y
# CONFIG_ROCKETPORT is not set
# CONFIG_CYCLADES is not set
CONFIG_MOXA_INTELLIO=y
# CONFIG_MOXA_SMARTIO is not set
CONFIG_SYNCLINK=y
# CONFIG_SYNCLINKMP is not set
# CONFIG_SYNCLINK_GT is not set
CONFIG_NOZOMI=y
# CONFIG_ISI is not set
# CONFIG_N_HDLC is not set
# CONFIG_N_GSM is not set
# CONFIG_TRACE_ROUTER is not set
CONFIG_TRACE_SINK=y
# CONFIG_DEVKMEM is not set
# CONFIG_STALDRV is not set

#
# Serial drivers
#
CONFIG_SERIAL_8250=y
# CONFIG_SERIAL_8250_CONSOLE is not set
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_SERIAL_8250_PCI=y
CONFIG_SERIAL_8250_PNP=y
CONFIG_SERIAL_8250_NR_UARTS=4
CONFIG_SERIAL_8250_RUNTIME_UARTS=4
# CONFIG_SERIAL_8250_EXTENDED is not set

#
# Non-8250 serial port support
#
CONFIG_SERIAL_MAX3100=y
# CONFIG_SERIAL_MAX3107 is not set
# CONFIG_SERIAL_MFD_HSU is not set
# CONFIG_SERIAL_UARTLITE is not set
CONFIG_SERIAL_CORE=y
CONFIG_SERIAL_CORE_CONSOLE=y
CONFIG_CONSOLE_POLL=y
# CONFIG_SERIAL_JSM is not set
CONFIG_SERIAL_TIMBERDALE=y
# CONFIG_SERIAL_ALTERA_JTAGUART is not set
CONFIG_SERIAL_ALTERA_UART=y
CONFIG_SERIAL_ALTERA_UART_MAXPORTS=4
CONFIG_SERIAL_ALTERA_UART_BAUDRATE=115200
# CONFIG_SERIAL_ALTERA_UART_CONSOLE is not set
CONFIG_SERIAL_IFX6X60=y
CONFIG_SERIAL_PCH_UART=y
# CONFIG_SERIAL_PCH_UART_CONSOLE is not set
CONFIG_SERIAL_XILINX_PS_UART=y
CONFIG_SERIAL_XILINX_PS_UART_CONSOLE=y
CONFIG_HVC_DRIVER=y
CONFIG_HVC_IRQ=y
CONFIG_HVC_XEN=y
# CONFIG_VIRTIO_CONSOLE is not set
# CONFIG_IPMI_HANDLER is not set
CONFIG_HW_RANDOM=y
CONFIG_HW_RANDOM_TIMERIOMEM=y
# CONFIG_HW_RANDOM_INTEL is not set
CONFIG_HW_RANDOM_AMD=y
# CONFIG_HW_RANDOM_VIA is not set
# CONFIG_HW_RANDOM_VIRTIO is not set
CONFIG_NVRAM=y
CONFIG_R3964=y
# CONFIG_APPLICOM is not set
CONFIG_MWAVE=y
# CONFIG_RAW_DRIVER is not set
# CONFIG_HPET is not set
# CONFIG_HANGCHECK_TIMER is not set
# CONFIG_TCG_TPM is not set
CONFIG_TELCLOCK=y
CONFIG_DEVPORT=y
CONFIG_RAMOOPS=y
CONFIG_I2C=y
CONFIG_I2C_BOARDINFO=y
# CONFIG_I2C_COMPAT is not set
# CONFIG_I2C_CHARDEV is not set
# CONFIG_I2C_MUX is not set
CONFIG_I2C_HELPER_AUTO=y
CONFIG_I2C_SMBUS=y
CONFIG_I2C_ALGOBIT=y

#
# I2C Hardware Bus support
#

#
# PC SMBus host controller drivers
#
CONFIG_I2C_ALI1535=y
# CONFIG_I2C_ALI1563 is not set
CONFIG_I2C_ALI15X3=y
CONFIG_I2C_AMD756=y
# CONFIG_I2C_AMD756_S4882 is not set
# CONFIG_I2C_AMD8111 is not set
# CONFIG_I2C_I801 is not set
# CONFIG_I2C_ISCH is not set
# CONFIG_I2C_PIIX4 is not set
CONFIG_I2C_NFORCE2=y
# CONFIG_I2C_NFORCE2_S4985 is not set
# CONFIG_I2C_SIS5595 is not set
CONFIG_I2C_SIS630=y
# CONFIG_I2C_SIS96X is not set
CONFIG_I2C_VIA=y
CONFIG_I2C_VIAPRO=y

#
# ACPI drivers
#
CONFIG_I2C_SCMI=y

#
# I2C system bus drivers (mostly embedded / system-on-chip)
#
# CONFIG_I2C_DESIGNWARE_PCI is not set
CONFIG_I2C_GPIO=y
CONFIG_I2C_INTEL_MID=y
# CONFIG_I2C_OCORES is not set
# CONFIG_I2C_PCA_PLATFORM is not set
# CONFIG_I2C_PXA_PCI is not set
# CONFIG_I2C_SIMTEC is not set
CONFIG_I2C_XILINX=y
# CONFIG_I2C_EG20T is not set

#
# External I2C/SMBus adapter drivers
#
CONFIG_I2C_PARPORT_LIGHT=y
CONFIG_I2C_TAOS_EVM=y

#
# Other I2C/SMBus bus drivers
#
CONFIG_I2C_DEBUG_CORE=y
# CONFIG_I2C_DEBUG_ALGO is not set
CONFIG_I2C_DEBUG_BUS=y
CONFIG_SPI=y
CONFIG_SPI_DEBUG=y
CONFIG_SPI_MASTER=y

#
# SPI Master Controller Drivers
#
# CONFIG_SPI_ALTERA is not set
CONFIG_SPI_BITBANG=y
CONFIG_SPI_GPIO=y
# CONFIG_SPI_OC_TINY is not set
# CONFIG_SPI_PXA2XX_PCI is not set
CONFIG_SPI_TOPCLIFF_PCH=y
CONFIG_SPI_XILINX=y
# CONFIG_SPI_DESIGNWARE is not set

#
# SPI Protocol Masters
#
CONFIG_SPI_SPIDEV=y
CONFIG_SPI_TLE62X0=y
CONFIG_HSI=y
CONFIG_HSI_BOARDINFO=y

#
# HSI clients
#
# CONFIG_HSI_CHAR is not set

#
# PPS support
#
CONFIG_PPS=y
CONFIG_PPS_DEBUG=y

#
# PPS clients support
#
CONFIG_PPS_CLIENT_KTIMER=y
# CONFIG_PPS_CLIENT_LDISC is not set
# CONFIG_PPS_CLIENT_GPIO is not set

#
# PPS generators support
#

#
# PTP clock support
#
CONFIG_PTP_1588_CLOCK=y

#
# Enable PHYLIB and NETWORK_PHY_TIMESTAMPING to see the additional clocks.
#
CONFIG_ARCH_WANT_OPTIONAL_GPIOLIB=y
CONFIG_GPIOLIB=y
CONFIG_DEBUG_GPIO=y
CONFIG_GPIO_SYSFS=y
CONFIG_GPIO_MAX730X=y

#
# Memory mapped GPIO drivers:
#
# CONFIG_GPIO_GENERIC_PLATFORM is not set
CONFIG_GPIO_IT8761E=y
CONFIG_GPIO_SCH=y
CONFIG_GPIO_VX855=y

#
# I2C GPIO expanders:
#
CONFIG_GPIO_MAX7300=y
CONFIG_GPIO_MAX732X=y
# CONFIG_GPIO_MAX732X_IRQ is not set
CONFIG_GPIO_PCA953X=y
# CONFIG_GPIO_PCA953X_IRQ is not set
# CONFIG_GPIO_PCF857X is not set
# CONFIG_GPIO_SX150X is not set
CONFIG_GPIO_TC3589X=y
# CONFIG_GPIO_WM831X is not set
CONFIG_GPIO_WM8350=y
# CONFIG_GPIO_WM8994 is not set
CONFIG_GPIO_ADP5588=y
CONFIG_GPIO_ADP5588_IRQ=y

#
# PCI GPIO expanders:
#
# CONFIG_GPIO_BT8XX is not set
CONFIG_GPIO_LANGWELL=y
CONFIG_GPIO_PCH=y
CONFIG_GPIO_ML_IOH=y
CONFIG_GPIO_TIMBERDALE=y
CONFIG_GPIO_RDC321X=y

#
# SPI GPIO expanders:
#
# CONFIG_GPIO_MAX7301 is not set
# CONFIG_GPIO_MCP23S08 is not set
CONFIG_GPIO_MC33880=y
CONFIG_GPIO_74X164=y

#
# AC97 GPIO expanders:
#

#
# MODULbus GPIO expanders:
#
CONFIG_GPIO_TPS65910=y
# CONFIG_W1 is not set
CONFIG_POWER_SUPPLY=y
# CONFIG_POWER_SUPPLY_DEBUG is not set
CONFIG_PDA_POWER=y
# CONFIG_WM831X_BACKUP is not set
CONFIG_WM831X_POWER=y
# CONFIG_WM8350_POWER is not set
CONFIG_TEST_POWER=y
# CONFIG_BATTERY_DS2780 is not set
CONFIG_BATTERY_DS2782=y
CONFIG_BATTERY_BQ20Z75=y
# CONFIG_BATTERY_BQ27x00 is not set
CONFIG_BATTERY_MAX17040=y
# CONFIG_BATTERY_MAX17042 is not set
# CONFIG_CHARGER_MAX8903 is not set
CONFIG_CHARGER_GPIO=y
CONFIG_CHARGER_MAX8998=y
CONFIG_HWMON=y
CONFIG_HWMON_VID=y
CONFIG_HWMON_DEBUG_CHIP=y

#
# Native drivers
#
# CONFIG_SENSORS_ABITUGURU is not set
# CONFIG_SENSORS_ABITUGURU3 is not set
CONFIG_SENSORS_AD7314=y
CONFIG_SENSORS_AD7414=y
CONFIG_SENSORS_AD7418=y
CONFIG_SENSORS_ADCXX=y
# CONFIG_SENSORS_ADM1021 is not set
# CONFIG_SENSORS_ADM1025 is not set
CONFIG_SENSORS_ADM1026=y
CONFIG_SENSORS_ADM1029=y
CONFIG_SENSORS_ADM1031=y
# CONFIG_SENSORS_ADM9240 is not set
CONFIG_SENSORS_ADT7411=y
CONFIG_SENSORS_ADT7462=y
CONFIG_SENSORS_ADT7470=y
CONFIG_SENSORS_ADT7475=y
# CONFIG_SENSORS_ASC7621 is not set
# CONFIG_SENSORS_K8TEMP is not set
CONFIG_SENSORS_K10TEMP=y
# CONFIG_SENSORS_FAM15H_POWER is not set
CONFIG_SENSORS_ASB100=y
# CONFIG_SENSORS_ATXP1 is not set
CONFIG_SENSORS_DS620=y
CONFIG_SENSORS_DS1621=y
CONFIG_SENSORS_I5K_AMB=y
CONFIG_SENSORS_F71805F=y
# CONFIG_SENSORS_F71882FG is not set
CONFIG_SENSORS_F75375S=y
CONFIG_SENSORS_FSCHMD=y
CONFIG_SENSORS_G760A=y
# CONFIG_SENSORS_GL518SM is not set
# CONFIG_SENSORS_GL520SM is not set
CONFIG_SENSORS_GPIO_FAN=y
CONFIG_SENSORS_CORETEMP=y
CONFIG_SENSORS_IT87=y
CONFIG_SENSORS_JC42=y
CONFIG_SENSORS_LINEAGE=y
# CONFIG_SENSORS_LM63 is not set
# CONFIG_SENSORS_LM70 is not set
CONFIG_SENSORS_LM73=y
# CONFIG_SENSORS_LM75 is not set
CONFIG_SENSORS_LM77=y
CONFIG_SENSORS_LM78=y
CONFIG_SENSORS_LM80=y
# CONFIG_SENSORS_LM83 is not set
CONFIG_SENSORS_LM85=y
CONFIG_SENSORS_LM87=y
# CONFIG_SENSORS_LM90 is not set
# CONFIG_SENSORS_LM92 is not set
CONFIG_SENSORS_LM93=y
CONFIG_SENSORS_LTC4151=y
# CONFIG_SENSORS_LTC4215 is not set
CONFIG_SENSORS_LTC4245=y
# CONFIG_SENSORS_LTC4261 is not set
# CONFIG_SENSORS_LM95241 is not set
# CONFIG_SENSORS_LM95245 is not set
# CONFIG_SENSORS_MAX1111 is not set
# CONFIG_SENSORS_MAX16065 is not set
CONFIG_SENSORS_MAX1619=y
CONFIG_SENSORS_MAX1668=y
CONFIG_SENSORS_MAX6639=y
CONFIG_SENSORS_MAX6642=y
# CONFIG_SENSORS_MAX6650 is not set
# CONFIG_SENSORS_NTC_THERMISTOR is not set
CONFIG_SENSORS_PC87360=y
# CONFIG_SENSORS_PC87427 is not set
CONFIG_SENSORS_PCF8591=y
CONFIG_PMBUS=y
CONFIG_SENSORS_PMBUS=y
# CONFIG_SENSORS_ADM1275 is not set
# CONFIG_SENSORS_LM25066 is not set
# CONFIG_SENSORS_LTC2978 is not set
# CONFIG_SENSORS_MAX16064 is not set
# CONFIG_SENSORS_MAX34440 is not set
# CONFIG_SENSORS_MAX8688 is not set
# CONFIG_SENSORS_UCD9000 is not set
# CONFIG_SENSORS_UCD9200 is not set
CONFIG_SENSORS_ZL6100=y
# CONFIG_SENSORS_SHT15 is not set
# CONFIG_SENSORS_SHT21 is not set
CONFIG_SENSORS_SIS5595=y
# CONFIG_SENSORS_SMM665 is not set
CONFIG_SENSORS_DME1737=y
# CONFIG_SENSORS_EMC1403 is not set
# CONFIG_SENSORS_EMC2103 is not set
# CONFIG_SENSORS_EMC6W201 is not set
CONFIG_SENSORS_SMSC47M1=y
CONFIG_SENSORS_SMSC47M192=y
# CONFIG_SENSORS_SMSC47B397 is not set
# CONFIG_SENSORS_SCH56XX_COMMON is not set
# CONFIG_SENSORS_SCH5627 is not set
# CONFIG_SENSORS_SCH5636 is not set
# CONFIG_SENSORS_ADS1015 is not set
# CONFIG_SENSORS_ADS7828 is not set
CONFIG_SENSORS_ADS7871=y
CONFIG_SENSORS_AMC6821=y
# CONFIG_SENSORS_THMC50 is not set
# CONFIG_SENSORS_TMP102 is not set
# CONFIG_SENSORS_TMP401 is not set
CONFIG_SENSORS_TMP421=y
# CONFIG_SENSORS_VIA_CPUTEMP is not set
CONFIG_SENSORS_VIA686A=y
CONFIG_SENSORS_VT1211=y
# CONFIG_SENSORS_VT8231 is not set
CONFIG_SENSORS_W83781D=y
# CONFIG_SENSORS_W83791D is not set
# CONFIG_SENSORS_W83792D is not set
CONFIG_SENSORS_W83793=y
CONFIG_SENSORS_W83795=y
CONFIG_SENSORS_W83795_FANCTRL=y
CONFIG_SENSORS_W83L785TS=y
CONFIG_SENSORS_W83L786NG=y
CONFIG_SENSORS_W83627HF=y
# CONFIG_SENSORS_W83627EHF is not set
CONFIG_SENSORS_WM831X=y
CONFIG_SENSORS_WM8350=y
CONFIG_SENSORS_APPLESMC=y

#
# ACPI drivers
#
# CONFIG_SENSORS_ACPI_POWER is not set
CONFIG_SENSORS_ATK0110=y
CONFIG_THERMAL=y
CONFIG_THERMAL_HWMON=y
# CONFIG_WATCHDOG is not set
CONFIG_SSB_POSSIBLE=y

#
# Sonics Silicon Backplane
#
# CONFIG_SSB is not set
CONFIG_BCMA_POSSIBLE=y

#
# Broadcom specific AMBA
#
# CONFIG_BCMA is not set

#
# Multifunction device drivers
#
CONFIG_MFD_CORE=y
CONFIG_MFD_88PM860X=y
CONFIG_MFD_SM501=y
# CONFIG_MFD_SM501_GPIO is not set
CONFIG_HTC_PASIC3=y
CONFIG_HTC_I2CPLD=y
CONFIG_TPS6105X=y
CONFIG_TPS65010=y
# CONFIG_TPS6507X is not set
CONFIG_MFD_TPS6586X=y
CONFIG_MFD_TPS65910=y
# CONFIG_MFD_TPS65912_I2C is not set
# CONFIG_MFD_TPS65912_SPI is not set
# CONFIG_TWL4030_CORE is not set
# CONFIG_MFD_STMPE is not set
CONFIG_MFD_TC3589X=y
# CONFIG_MFD_TMIO is not set
# CONFIG_PMIC_DA903X is not set
CONFIG_PMIC_DA9052=y
CONFIG_MFD_DA9052_SPI=y
CONFIG_MFD_DA9052_I2C=y
# CONFIG_PMIC_ADP5520 is not set
# CONFIG_MFD_MAX8925 is not set
# CONFIG_MFD_MAX8997 is not set
CONFIG_MFD_MAX8998=y
# CONFIG_MFD_WM8400 is not set
CONFIG_MFD_WM831X=y
CONFIG_MFD_WM831X_I2C=y
CONFIG_MFD_WM831X_SPI=y
CONFIG_MFD_WM8350=y
CONFIG_MFD_WM8350_I2C=y
CONFIG_MFD_WM8994=y
# CONFIG_MFD_PCF50633 is not set
# CONFIG_MFD_MC13XXX is not set
# CONFIG_ABX500_CORE is not set
CONFIG_EZX_PCAP=y
# CONFIG_MFD_CS5535 is not set
CONFIG_MFD_TIMBERDALE=y
CONFIG_LPC_SCH=y
CONFIG_MFD_RDC321X=y
# CONFIG_MFD_JANZ_CMODIO is not set
CONFIG_MFD_VX855=y
CONFIG_MFD_WL1273_CORE=y
# CONFIG_MFD_AAT2870_CORE is not set
CONFIG_REGULATOR=y
CONFIG_REGULATOR_DEBUG=y
CONFIG_REGULATOR_DUMMY=y
CONFIG_REGULATOR_FIXED_VOLTAGE=y
CONFIG_REGULATOR_VIRTUAL_CONSUMER=y
# CONFIG_REGULATOR_USERSPACE_CONSUMER is not set
CONFIG_REGULATOR_GPIO=y
CONFIG_REGULATOR_BQ24022=y
# CONFIG_REGULATOR_MAX1586 is not set
# CONFIG_REGULATOR_MAX8649 is not set
# CONFIG_REGULATOR_MAX8660 is not set
CONFIG_REGULATOR_MAX8952=y
CONFIG_REGULATOR_MAX8998=y
CONFIG_REGULATOR_WM831X=y
CONFIG_REGULATOR_WM8350=y
# CONFIG_REGULATOR_WM8994 is not set
# CONFIG_REGULATOR_DA9052 is not set
# CONFIG_REGULATOR_LP3971 is not set
# CONFIG_REGULATOR_LP3972 is not set
CONFIG_REGULATOR_PCAP=y
# CONFIG_REGULATOR_TPS6105X is not set
CONFIG_REGULATOR_TPS65023=y
# CONFIG_REGULATOR_TPS6507X is not set
# CONFIG_REGULATOR_88PM8607 is not set
CONFIG_REGULATOR_ISL6271A=y
CONFIG_REGULATOR_AD5398=y
# CONFIG_REGULATOR_TPS6586X is not set
CONFIG_REGULATOR_TPS6524X=y
CONFIG_REGULATOR_TPS65910=y
# CONFIG_MEDIA_SUPPORT is not set

#
# Graphics support
#
CONFIG_AGP=y
CONFIG_AGP_AMD64=y
CONFIG_AGP_INTEL=y
CONFIG_AGP_SIS=y
CONFIG_AGP_VIA=y
CONFIG_VGA_ARB=y
CONFIG_VGA_ARB_MAX_GPUS=16
CONFIG_VGA_SWITCHEROO=y
CONFIG_DRM=y
CONFIG_DRM_KMS_HELPER=y
CONFIG_DRM_TTM=y
CONFIG_DRM_TDFX=y
# CONFIG_DRM_R128 is not set
CONFIG_DRM_RADEON=y
# CONFIG_DRM_RADEON_KMS is not set
CONFIG_DRM_I915=y
CONFIG_DRM_I915_KMS=y
# CONFIG_DRM_MGA is not set
# CONFIG_DRM_SIS is not set
CONFIG_DRM_VIA=y
CONFIG_DRM_SAVAGE=y
# CONFIG_DRM_VMWGFX is not set
# CONFIG_DRM_GMA500 is not set
# CONFIG_STUB_POULSBO is not set
CONFIG_VGASTATE=y
CONFIG_VIDEO_OUTPUT_CONTROL=y
CONFIG_FB=y
# CONFIG_FIRMWARE_EDID is not set
# CONFIG_FB_DDC is not set
CONFIG_FB_BOOT_VESA_SUPPORT=y
CONFIG_FB_CFB_FILLRECT=y
CONFIG_FB_CFB_COPYAREA=y
CONFIG_FB_CFB_IMAGEBLIT=y
# CONFIG_FB_CFB_REV_PIXELS_IN_BYTE is not set
CONFIG_FB_SYS_FILLRECT=y
CONFIG_FB_SYS_COPYAREA=y
CONFIG_FB_SYS_IMAGEBLIT=y
# CONFIG_FB_FOREIGN_ENDIAN is not set
CONFIG_FB_SYS_FOPS=y
# CONFIG_FB_WMT_GE_ROPS is not set
CONFIG_FB_DEFERRED_IO=y
CONFIG_FB_SVGALIB=y
# CONFIG_FB_MACMODES is not set
# CONFIG_FB_BACKLIGHT is not set
CONFIG_FB_MODE_HELPERS=y
CONFIG_FB_TILEBLITTING=y

#
# Frame buffer hardware drivers
#
CONFIG_FB_CIRRUS=y
CONFIG_FB_PM2=y
CONFIG_FB_PM2_FIFO_DISCONNECT=y
# CONFIG_FB_CYBER2000 is not set
# CONFIG_FB_ARC is not set
CONFIG_FB_ASILIANT=y
CONFIG_FB_IMSTT=y
# CONFIG_FB_VGA16 is not set
CONFIG_FB_UVESA=y
CONFIG_FB_VESA=y
# CONFIG_FB_EFI is not set
# CONFIG_FB_N411 is not set
CONFIG_FB_HGA=y
# CONFIG_FB_S1D13XXX is not set
# CONFIG_FB_NVIDIA is not set
# CONFIG_FB_RIVA is not set
CONFIG_FB_LE80578=y
# CONFIG_FB_CARILLO_RANCH is not set
# CONFIG_FB_MATROX is not set
# CONFIG_FB_RADEON is not set
# CONFIG_FB_ATY128 is not set
CONFIG_FB_ATY=y
# CONFIG_FB_ATY_CT is not set
CONFIG_FB_ATY_GX=y
# CONFIG_FB_ATY_BACKLIGHT is not set
# CONFIG_FB_S3 is not set
CONFIG_FB_SAVAGE=y
# CONFIG_FB_SAVAGE_I2C is not set
# CONFIG_FB_SAVAGE_ACCEL is not set
CONFIG_FB_SIS=y
CONFIG_FB_SIS_300=y
# CONFIG_FB_SIS_315 is not set
CONFIG_FB_VIA=y
# CONFIG_FB_VIA_DIRECT_PROCFS is not set
CONFIG_FB_VIA_X_COMPATIBILITY=y
CONFIG_FB_NEOMAGIC=y
# CONFIG_FB_KYRO is not set
CONFIG_FB_3DFX=y
# CONFIG_FB_3DFX_ACCEL is not set
# CONFIG_FB_3DFX_I2C is not set
CONFIG_FB_VOODOO1=y
CONFIG_FB_VT8623=y
CONFIG_FB_TRIDENT=y
CONFIG_FB_ARK=y
CONFIG_FB_PM3=y
CONFIG_FB_CARMINE=y
# CONFIG_FB_CARMINE_DRAM_EVAL is not set
CONFIG_CARMINE_DRAM_CUSTOM=y
# CONFIG_FB_GEODE is not set
# CONFIG_FB_TMIO is not set
# CONFIG_FB_SM501 is not set
# CONFIG_FB_VIRTUAL is not set
# CONFIG_XEN_FBDEV_FRONTEND is not set
# CONFIG_FB_METRONOME is not set
CONFIG_FB_MB862XX=y
CONFIG_FB_MB862XX_PCI_GDC=y
# CONFIG_FB_MB862XX_I2C is not set
CONFIG_FB_BROADSHEET=y
CONFIG_BACKLIGHT_LCD_SUPPORT=y
# CONFIG_LCD_CLASS_DEVICE is not set
CONFIG_BACKLIGHT_CLASS_DEVICE=y
# CONFIG_BACKLIGHT_GENERIC is not set
# CONFIG_BACKLIGHT_PROGEAR is not set
# CONFIG_BACKLIGHT_APPLE is not set
CONFIG_BACKLIGHT_SAHARA=y
CONFIG_BACKLIGHT_WM831X=y
CONFIG_BACKLIGHT_ADP8860=y
CONFIG_BACKLIGHT_ADP8870=y
# CONFIG_BACKLIGHT_88PM860X is not set

#
# Console display driver support
#
CONFIG_VGA_CONSOLE=y
CONFIG_VGACON_SOFT_SCROLLBACK=y
CONFIG_VGACON_SOFT_SCROLLBACK_SIZE=64
CONFIG_DUMMY_CONSOLE=y
CONFIG_FRAMEBUFFER_CONSOLE=y
CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY=y
CONFIG_FRAMEBUFFER_CONSOLE_ROTATION=y
# CONFIG_FONTS is not set
CONFIG_FONT_8x8=y
CONFIG_FONT_8x16=y
CONFIG_LOGO=y
CONFIG_LOGO_LINUX_MONO=y
# CONFIG_LOGO_LINUX_VGA16 is not set
CONFIG_LOGO_LINUX_CLUT224=y
# CONFIG_SOUND is not set
CONFIG_HID_SUPPORT=y
# CONFIG_HID is not set
CONFIG_HID_PID=y
# CONFIG_USB_SUPPORT is not set
CONFIG_UWB=y
CONFIG_UWB_WHCI=y
# CONFIG_MMC is not set
CONFIG_MEMSTICK=y
# CONFIG_MEMSTICK_DEBUG is not set

#
# MemoryStick drivers
#
# CONFIG_MEMSTICK_UNSAFE_RESUME is not set
# CONFIG_MSPRO_BLOCK is not set

#
# MemoryStick Host Controller Drivers
#
# CONFIG_MEMSTICK_TIFM_MS is not set
CONFIG_MEMSTICK_JMICRON_38X=y
CONFIG_MEMSTICK_R592=y
CONFIG_NEW_LEDS=y
CONFIG_LEDS_CLASS=y

#
# LED drivers
#
CONFIG_LEDS_88PM860X=y
CONFIG_LEDS_LM3530=y
CONFIG_LEDS_PCA9532=y
CONFIG_LEDS_PCA9532_GPIO=y
# CONFIG_LEDS_GPIO is not set
# CONFIG_LEDS_LP3944 is not set
# CONFIG_LEDS_LP5521 is not set
CONFIG_LEDS_LP5523=y
# CONFIG_LEDS_CLEVO_MAIL is not set
# CONFIG_LEDS_PCA955X is not set
CONFIG_LEDS_WM831X_STATUS=y
CONFIG_LEDS_WM8350=y
# CONFIG_LEDS_DAC124S085 is not set
CONFIG_LEDS_REGULATOR=y
CONFIG_LEDS_BD2802=y
CONFIG_LEDS_INTEL_SS4200=y
# CONFIG_LEDS_LT3593 is not set
CONFIG_LEDS_TCA6507=y
# CONFIG_LEDS_TRIGGERS is not set

#
# LED Triggers
#
CONFIG_ACCESSIBILITY=y
CONFIG_A11Y_BRAILLE_CONSOLE=y
# CONFIG_INFINIBAND is not set
# CONFIG_EDAC is not set
CONFIG_RTC_LIB=y
CONFIG_RTC_CLASS=y
# CONFIG_RTC_HCTOSYS is not set
CONFIG_RTC_DEBUG=y

#
# RTC interfaces
#
CONFIG_RTC_INTF_SYSFS=y
# CONFIG_RTC_INTF_PROC is not set
# CONFIG_RTC_INTF_DEV is not set
CONFIG_RTC_DRV_TEST=y

#
# I2C RTC drivers
#
CONFIG_RTC_DRV_88PM860X=y
CONFIG_RTC_DRV_DS1307=y
CONFIG_RTC_DRV_DS1374=y
# CONFIG_RTC_DRV_DS1672 is not set
# CONFIG_RTC_DRV_DS3232 is not set
CONFIG_RTC_DRV_MAX6900=y
CONFIG_RTC_DRV_MAX8998=y
# CONFIG_RTC_DRV_RS5C372 is not set
CONFIG_RTC_DRV_ISL1208=y
# CONFIG_RTC_DRV_ISL12022 is not set
CONFIG_RTC_DRV_X1205=y
CONFIG_RTC_DRV_PCF8563=y
# CONFIG_RTC_DRV_PCF8583 is not set
CONFIG_RTC_DRV_M41T80=y
# CONFIG_RTC_DRV_M41T80_WDT is not set
CONFIG_RTC_DRV_BQ32K=y
CONFIG_RTC_DRV_S35390A=y
# CONFIG_RTC_DRV_FM3130 is not set
# CONFIG_RTC_DRV_RX8581 is not set
# CONFIG_RTC_DRV_RX8025 is not set
# CONFIG_RTC_DRV_EM3027 is not set
# CONFIG_RTC_DRV_RV3029C2 is not set

#
# SPI RTC drivers
#
# CONFIG_RTC_DRV_M41T93 is not set
# CONFIG_RTC_DRV_M41T94 is not set
# CONFIG_RTC_DRV_DS1305 is not set
CONFIG_RTC_DRV_DS1390=y
CONFIG_RTC_DRV_MAX6902=y
# CONFIG_RTC_DRV_R9701 is not set
# CONFIG_RTC_DRV_RS5C348 is not set
CONFIG_RTC_DRV_DS3234=y
CONFIG_RTC_DRV_PCF2123=y

#
# Platform RTC drivers
#
CONFIG_RTC_DRV_CMOS=y
# CONFIG_RTC_DRV_DS1286 is not set
CONFIG_RTC_DRV_DS1511=y
CONFIG_RTC_DRV_DS1553=y
# CONFIG_RTC_DRV_DS1742 is not set
CONFIG_RTC_DRV_STK17TA8=y
CONFIG_RTC_DRV_M48T86=y
CONFIG_RTC_DRV_M48T35=y
CONFIG_RTC_DRV_M48T59=y
# CONFIG_RTC_DRV_MSM6242 is not set
# CONFIG_RTC_DRV_BQ4802 is not set
CONFIG_RTC_DRV_RP5C01=y
CONFIG_RTC_DRV_V3020=y
CONFIG_RTC_DRV_WM831X=y
# CONFIG_RTC_DRV_WM8350 is not set

#
# on-CPU RTC drivers
#
CONFIG_RTC_DRV_PCAP=y
CONFIG_DMADEVICES=y
CONFIG_DMADEVICES_DEBUG=y
# CONFIG_DMADEVICES_VDEBUG is not set

#
# DMA Devices
#
# CONFIG_INTEL_MID_DMAC is not set
# CONFIG_INTEL_IOATDMA is not set
# CONFIG_TIMB_DMA is not set
# CONFIG_PCH_DMA is not set
# CONFIG_AUXDISPLAY is not set
CONFIG_UIO=y
# CONFIG_UIO_CIF is not set
CONFIG_UIO_PDRV=y
# CONFIG_UIO_PDRV_GENIRQ is not set
CONFIG_UIO_AEC=y
CONFIG_UIO_SERCOS3=y
CONFIG_UIO_PCI_GENERIC=y
CONFIG_UIO_NETX=y
CONFIG_VIRTIO=y
CONFIG_VIRTIO_RING=y

#
# Virtio drivers
#
# CONFIG_VIRTIO_PCI is not set
# CONFIG_VIRTIO_BALLOON is not set
CONFIG_VIRTIO_MMIO=y

#
# Microsoft Hyper-V guest support
#
# CONFIG_HYPERV is not set

#
# Xen driver support
#
# CONFIG_XEN_BALLOON is not set
# CONFIG_XEN_DEV_EVTCHN is not set
CONFIG_XEN_BACKEND=y
# CONFIG_XENFS is not set
CONFIG_XEN_SYS_HYPERVISOR=y
CONFIG_XEN_XENBUS_FRONTEND=y
CONFIG_XEN_GNTDEV=y
# CONFIG_XEN_GRANT_DEV_ALLOC is not set
CONFIG_SWIOTLB_XEN=y
CONFIG_XEN_TMEM=y
# CONFIG_XEN_PCIDEV_BACKEND is not set
CONFIG_XEN_PRIVCMD=y
# CONFIG_STAGING is not set
CONFIG_X86_PLATFORM_DEVICES=y
# CONFIG_ACERHDF is not set
CONFIG_DELL_LAPTOP=y
# CONFIG_FUJITSU_LAPTOP is not set
# CONFIG_HP_ACCEL is not set
CONFIG_PANASONIC_LAPTOP=y
# CONFIG_THINKPAD_ACPI is not set
# CONFIG_SENSORS_HDAPS is not set
CONFIG_EEEPC_LAPTOP=y
# CONFIG_ACPI_WMI is not set
CONFIG_ACPI_ASUS=y
# CONFIG_TOPSTAR_LAPTOP is not set
# CONFIG_ACPI_TOSHIBA is not set
CONFIG_TOSHIBA_BT_RFKILL=y
CONFIG_ACPI_CMPC=y
# CONFIG_INTEL_IPS is not set
CONFIG_IBM_RTL=y
# CONFIG_XO15_EBOOK is not set
CONFIG_SAMSUNG_Q10=y

#
# Hardware Spinlock drivers
#
CONFIG_CLKEVT_I8253=y
CONFIG_I8253_LOCK=y
CONFIG_CLKBLD_I8253=y
CONFIG_IOMMU_SUPPORT=y
# CONFIG_AMD_IOMMU is not set
CONFIG_VIRT_DRIVERS=y
# CONFIG_PM_DEVFREQ is not set
# CONFIG_XSHM is not set

#
# Firmware Drivers
#
# CONFIG_EDD is not set
CONFIG_FIRMWARE_MEMMAP=y
CONFIG_EFI_VARS=y
# CONFIG_DELL_RBU is not set
CONFIG_DCDBAS=y
# CONFIG_DMIID is not set
# CONFIG_DMI_SYSFS is not set
CONFIG_ISCSI_IBFT_FIND=y
# CONFIG_ISCSI_IBFT is not set
CONFIG_GOOGLE_FIRMWARE=y

#
# Google Firmware Drivers
#
CONFIG_GOOGLE_SMI=y
# CONFIG_GOOGLE_MEMCONSOLE is not set

#
# File systems
#
CONFIG_EXT2_FS=y
CONFIG_EXT2_FS_XATTR=y
CONFIG_EXT2_FS_POSIX_ACL=y
# CONFIG_EXT2_FS_SECURITY is not set
CONFIG_EXT2_FS_XIP=y
# CONFIG_EXT3_FS is not set
# CONFIG_EXT4_FS is not set
CONFIG_FS_XIP=y
CONFIG_FS_MBCACHE=y
# CONFIG_REISERFS_FS is not set
# CONFIG_JFS_FS is not set
CONFIG_XFS_FS=y
CONFIG_XFS_QUOTA=y
CONFIG_XFS_POSIX_ACL=y
# CONFIG_XFS_RT is not set
CONFIG_XFS_DEBUG=y
# CONFIG_GFS2_FS is not set
# CONFIG_OCFS2_FS is not set
# CONFIG_BTRFS_FS is not set
# CONFIG_NILFS2_FS is not set
CONFIG_FS_POSIX_ACL=y
CONFIG_EXPORTFS=y
CONFIG_FILE_LOCKING=y
CONFIG_FSNOTIFY=y
CONFIG_DNOTIFY=y
# CONFIG_INOTIFY_USER is not set
# CONFIG_FANOTIFY is not set
CONFIG_QUOTA=y
# CONFIG_QUOTA_NETLINK_INTERFACE is not set
# CONFIG_PRINT_QUOTA_WARNING is not set
CONFIG_QUOTA_DEBUG=y
CONFIG_QUOTA_TREE=y
CONFIG_QFMT_V1=y
CONFIG_QFMT_V2=y
CONFIG_QUOTACTL=y
CONFIG_QUOTACTL_COMPAT=y
CONFIG_AUTOFS4_FS=y
# CONFIG_FUSE_FS is not set

#
# Caches
#
# CONFIG_FSCACHE is not set

#
# CD-ROM/DVD Filesystems
#
CONFIG_ISO9660_FS=y
CONFIG_JOLIET=y
# CONFIG_ZISOFS is not set
CONFIG_UDF_FS=y
CONFIG_UDF_NLS=y

#
# DOS/FAT/NT Filesystems
#
CONFIG_FAT_FS=y
CONFIG_MSDOS_FS=y
CONFIG_VFAT_FS=y
CONFIG_FAT_DEFAULT_CODEPAGE=437
CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1"
CONFIG_NTFS_FS=y
# CONFIG_NTFS_DEBUG is not set
CONFIG_NTFS_RW=y

#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
CONFIG_PROC_KCORE=y
CONFIG_PROC_SYSCTL=y
CONFIG_PROC_PAGE_MONITOR=y
CONFIG_SYSFS=y
CONFIG_TMPFS=y
# CONFIG_TMPFS_POSIX_ACL is not set
# CONFIG_TMPFS_XATTR is not set
# CONFIG_HUGETLBFS is not set
# CONFIG_HUGETLB_PAGE is not set
CONFIG_CONFIGFS_FS=y
CONFIG_MISC_FILESYSTEMS=y
# CONFIG_ADFS_FS is not set
CONFIG_AFFS_FS=y
CONFIG_ECRYPT_FS=y
CONFIG_HFS_FS=y
# CONFIG_HFSPLUS_FS is not set
# CONFIG_BEFS_FS is not set
# CONFIG_BFS_FS is not set
# CONFIG_EFS_FS is not set
# CONFIG_JFFS2_FS is not set
CONFIG_UBIFS_FS=y
# CONFIG_UBIFS_FS_XATTR is not set
# CONFIG_UBIFS_FS_ADVANCED_COMPR is not set
CONFIG_UBIFS_FS_LZO=y
CONFIG_UBIFS_FS_ZLIB=y
CONFIG_UBIFS_FS_DEBUG=y
# CONFIG_LOGFS is not set
CONFIG_CRAMFS=y
# CONFIG_SQUASHFS is not set
# CONFIG_VXFS_FS is not set
CONFIG_MINIX_FS=y
# CONFIG_OMFS_FS is not set
# CONFIG_HPFS_FS is not set
CONFIG_QNX4FS_FS=y
# CONFIG_ROMFS_FS is not set
CONFIG_PSTORE=y
# CONFIG_SYSV_FS is not set
CONFIG_UFS_FS=y
CONFIG_UFS_FS_WRITE=y
CONFIG_UFS_DEBUG=y
CONFIG_ORE=y
CONFIG_EXOFS_FS=y
CONFIG_EXOFS_DEBUG=y
# CONFIG_NETWORK_FILESYSTEMS is not set

#
# Partition Types
#
CONFIG_PARTITION_ADVANCED=y
CONFIG_ACORN_PARTITION=y
CONFIG_ACORN_PARTITION_CUMANA=y
# CONFIG_ACORN_PARTITION_EESOX is not set
# CONFIG_ACORN_PARTITION_ICS is not set
CONFIG_ACORN_PARTITION_ADFS=y
CONFIG_ACORN_PARTITION_POWERTEC=y
# CONFIG_ACORN_PARTITION_RISCIX is not set
CONFIG_OSF_PARTITION=y
CONFIG_AMIGA_PARTITION=y
CONFIG_ATARI_PARTITION=y
CONFIG_MAC_PARTITION=y
CONFIG_MSDOS_PARTITION=y
# CONFIG_BSD_DISKLABEL is not set
CONFIG_MINIX_SUBPARTITION=y
# CONFIG_SOLARIS_X86_PARTITION is not set
CONFIG_UNIXWARE_DISKLABEL=y
# CONFIG_LDM_PARTITION is not set
CONFIG_SGI_PARTITION=y
# CONFIG_ULTRIX_PARTITION is not set
# CONFIG_SUN_PARTITION is not set
CONFIG_KARMA_PARTITION=y
CONFIG_EFI_PARTITION=y
# CONFIG_SYSV68_PARTITION is not set
CONFIG_NLS=y
CONFIG_NLS_DEFAULT="iso8859-1"
# CONFIG_NLS_CODEPAGE_437 is not set
CONFIG_NLS_CODEPAGE_737=y
CONFIG_NLS_CODEPAGE_775=y
# CONFIG_NLS_CODEPAGE_850 is not set
# CONFIG_NLS_CODEPAGE_852 is not set
# CONFIG_NLS_CODEPAGE_855 is not set
CONFIG_NLS_CODEPAGE_857=y
CONFIG_NLS_CODEPAGE_860=y
CONFIG_NLS_CODEPAGE_861=y
CONFIG_NLS_CODEPAGE_862=y
# CONFIG_NLS_CODEPAGE_863 is not set
# CONFIG_NLS_CODEPAGE_864 is not set
# CONFIG_NLS_CODEPAGE_865 is not set
CONFIG_NLS_CODEPAGE_866=y
CONFIG_NLS_CODEPAGE_869=y
# CONFIG_NLS_CODEPAGE_936 is not set
# CONFIG_NLS_CODEPAGE_950 is not set
# CONFIG_NLS_CODEPAGE_932 is not set
# CONFIG_NLS_CODEPAGE_949 is not set
# CONFIG_NLS_CODEPAGE_874 is not set
CONFIG_NLS_ISO8859_8=y
# CONFIG_NLS_CODEPAGE_1250 is not set
CONFIG_NLS_CODEPAGE_1251=y
# CONFIG_NLS_ASCII is not set
# CONFIG_NLS_ISO8859_1 is not set
CONFIG_NLS_ISO8859_2=y
# CONFIG_NLS_ISO8859_3 is not set
# CONFIG_NLS_ISO8859_4 is not set
CONFIG_NLS_ISO8859_5=y
CONFIG_NLS_ISO8859_6=y
CONFIG_NLS_ISO8859_7=y
# CONFIG_NLS_ISO8859_9 is not set
# CONFIG_NLS_ISO8859_13 is not set
# CONFIG_NLS_ISO8859_14 is not set
CONFIG_NLS_ISO8859_15=y
CONFIG_NLS_KOI8_R=y
# CONFIG_NLS_KOI8_U is not set
CONFIG_NLS_UTF8=y

#
# Kernel hacking
#
CONFIG_TRACE_IRQFLAGS_SUPPORT=y
CONFIG_PRINTK_TIME=y
CONFIG_DEFAULT_MESSAGE_LOGLEVEL=4
CONFIG_ENABLE_WARN_DEPRECATED=y
CONFIG_ENABLE_MUST_CHECK=y
CONFIG_FRAME_WARN=2048
CONFIG_MAGIC_SYSRQ=y
CONFIG_STRIP_ASM_SYMS=y
CONFIG_UNUSED_SYMBOLS=y
CONFIG_DEBUG_FS=y
# CONFIG_HEADERS_CHECK is not set
CONFIG_DEBUG_SECTION_MISMATCH=y
CONFIG_DEBUG_KERNEL=y
# CONFIG_DEBUG_SHIRQ is not set
# CONFIG_LOCKUP_DETECTOR is not set
# CONFIG_HARDLOCKUP_DETECTOR is not set
CONFIG_DETECT_HUNG_TASK=y
CONFIG_DEFAULT_HUNG_TASK_TIMEOUT=120
# CONFIG_BOOTPARAM_HUNG_TASK_PANIC is not set
CONFIG_BOOTPARAM_HUNG_TASK_PANIC_VALUE=0
CONFIG_SCHED_DEBUG=y
CONFIG_SCHEDSTATS=y
# CONFIG_TIMER_STATS is not set
CONFIG_DEBUG_OBJECTS=y
CONFIG_DEBUG_OBJECTS_SELFTEST=y
CONFIG_DEBUG_OBJECTS_FREE=y
# CONFIG_DEBUG_OBJECTS_TIMERS is not set
# CONFIG_DEBUG_OBJECTS_WORK is not set
# CONFIG_DEBUG_OBJECTS_RCU_HEAD is not set
# CONFIG_DEBUG_OBJECTS_PERCPU_COUNTER is not set
CONFIG_DEBUG_OBJECTS_ENABLE_DEFAULT=1
# CONFIG_SLUB_DEBUG_ON is not set
# CONFIG_SLUB_STATS is not set
# CONFIG_DEBUG_KMEMLEAK is not set
CONFIG_DEBUG_PREEMPT=y
CONFIG_DEBUG_RT_MUTEXES=y
CONFIG_DEBUG_PI_LIST=y
# CONFIG_RT_MUTEX_TESTER is not set
CONFIG_DEBUG_SPINLOCK=y
CONFIG_DEBUG_MUTEXES=y
# CONFIG_DEBUG_LOCK_ALLOC is not set
# CONFIG_PROVE_LOCKING is not set
CONFIG_SPARSE_RCU_POINTER=y
# CONFIG_LOCK_STAT is not set
CONFIG_TRACE_IRQFLAGS=y
# CONFIG_DEBUG_ATOMIC_SLEEP is not set
CONFIG_DEBUG_LOCKING_API_SELFTESTS=y
CONFIG_STACKTRACE=y
# CONFIG_DEBUG_STACK_USAGE is not set
CONFIG_DEBUG_KOBJECT=y
CONFIG_DEBUG_BUGVERBOSE=y
# CONFIG_DEBUG_INFO is not set
# CONFIG_DEBUG_VM is not set
# CONFIG_DEBUG_VIRTUAL is not set
CONFIG_DEBUG_WRITECOUNT=y
CONFIG_DEBUG_MEMORY_INIT=y
CONFIG_DEBUG_LIST=y
CONFIG_TEST_LIST_SORT=y
CONFIG_DEBUG_SG=y
# CONFIG_DEBUG_NOTIFIERS is not set
# CONFIG_DEBUG_CREDENTIALS is not set
CONFIG_ARCH_WANT_FRAME_POINTERS=y
CONFIG_FRAME_POINTER=y
# CONFIG_BOOT_PRINTK_DELAY is not set
CONFIG_RCU_TORTURE_TEST=y
# CONFIG_RCU_TORTURE_TEST_RUNNABLE is not set
CONFIG_BACKTRACE_SELF_TEST=y
# CONFIG_DEBUG_BLOCK_EXT_DEVT is not set
# CONFIG_DEBUG_FORCE_WEAK_PER_CPU is not set
CONFIG_LKDTM=y
CONFIG_FAULT_INJECTION=y
# CONFIG_FAILSLAB is not set
# CONFIG_FAIL_PAGE_ALLOC is not set
CONFIG_FAIL_MAKE_REQUEST=y
CONFIG_FAIL_IO_TIMEOUT=y
CONFIG_FAULT_INJECTION_DEBUG_FS=y
# CONFIG_LATENCYTOP is not set
# CONFIG_SYSCTL_SYSCALL_CHECK is not set
# CONFIG_DEBUG_PAGEALLOC is not set
CONFIG_USER_STACKTRACE_SUPPORT=y
CONFIG_NOP_TRACER=y
CONFIG_HAVE_FTRACE_NMI_ENTER=y
CONFIG_HAVE_FUNCTION_TRACER=y
CONFIG_HAVE_FUNCTION_GRAPH_TRACER=y
CONFIG_HAVE_FUNCTION_GRAPH_FP_TEST=y
CONFIG_HAVE_FUNCTION_TRACE_MCOUNT_TEST=y
CONFIG_HAVE_DYNAMIC_FTRACE=y
CONFIG_HAVE_FTRACE_MCOUNT_RECORD=y
CONFIG_HAVE_SYSCALL_TRACEPOINTS=y
CONFIG_HAVE_C_RECORDMCOUNT=y
CONFIG_TRACER_MAX_TRACE=y
CONFIG_RING_BUFFER=y
CONFIG_FTRACE_NMI_ENTER=y
CONFIG_EVENT_TRACING=y
CONFIG_EVENT_POWER_TRACING_DEPRECATED=y
CONFIG_CONTEXT_SWITCH_TRACER=y
CONFIG_RING_BUFFER_ALLOW_SWAP=y
CONFIG_TRACING=y
CONFIG_GENERIC_TRACER=y
CONFIG_TRACING_SUPPORT=y
CONFIG_FTRACE=y
CONFIG_FUNCTION_TRACER=y
# CONFIG_FUNCTION_GRAPH_TRACER is not set
CONFIG_IRQSOFF_TRACER=y
CONFIG_PREEMPT_TRACER=y
CONFIG_SCHED_TRACER=y
# CONFIG_FTRACE_SYSCALLS is not set
CONFIG_BRANCH_PROFILE_NONE=y
# CONFIG_PROFILE_ANNOTATED_BRANCHES is not set
# CONFIG_PROFILE_ALL_BRANCHES is not set
# CONFIG_STACK_TRACER is not set
# CONFIG_BLK_DEV_IO_TRACE is not set
CONFIG_UPROBE_EVENT=y
CONFIG_PROBE_EVENTS=y
CONFIG_DYNAMIC_FTRACE=y
CONFIG_FUNCTION_PROFILER=y
CONFIG_FTRACE_MCOUNT_RECORD=y
# CONFIG_FTRACE_STARTUP_TEST is not set
# CONFIG_MMIOTRACE is not set
# CONFIG_RING_BUFFER_BENCHMARK is not set
CONFIG_PROVIDE_OHCI1394_DMA_INIT=y
# CONFIG_FIREWIRE_OHCI_REMOTE_DMA is not set
CONFIG_DYNAMIC_DEBUG=y
CONFIG_DMA_API_DEBUG=y
CONFIG_ATOMIC64_SELFTEST=y
CONFIG_SAMPLES=y
CONFIG_HAVE_ARCH_KGDB=y
CONFIG_KGDB=y
CONFIG_KGDB_SERIAL_CONSOLE=y
# CONFIG_KGDB_TESTS is not set
# CONFIG_KGDB_LOW_LEVEL_TRAP is not set
# CONFIG_KGDB_KDB is not set
CONFIG_HAVE_ARCH_KMEMCHECK=y
CONFIG_TEST_KSTRTOX=y
# CONFIG_STRICT_DEVMEM is not set
CONFIG_X86_VERBOSE_BOOTUP=y
CONFIG_EARLY_PRINTK=y
# CONFIG_EARLY_PRINTK_DBGP is not set
CONFIG_DEBUG_STACKOVERFLOW=y
CONFIG_X86_PTDUMP=y
CONFIG_DEBUG_RODATA=y
CONFIG_DEBUG_RODATA_TEST=y
CONFIG_IOMMU_DEBUG=y
# CONFIG_IOMMU_STRESS is not set
CONFIG_IOMMU_LEAK=y
CONFIG_HAVE_MMIOTRACE_SUPPORT=y
CONFIG_IO_DELAY_TYPE_0X80=0
CONFIG_IO_DELAY_TYPE_0XED=1
CONFIG_IO_DELAY_TYPE_UDELAY=2
CONFIG_IO_DELAY_TYPE_NONE=3
# CONFIG_IO_DELAY_0X80 is not set
# CONFIG_IO_DELAY_0XED is not set
# CONFIG_IO_DELAY_UDELAY is not set
CONFIG_IO_DELAY_NONE=y
CONFIG_DEFAULT_IO_DELAY_TYPE=3
CONFIG_DEBUG_BOOT_PARAMS=y
CONFIG_CPA_DEBUG=y
CONFIG_OPTIMIZE_INLINING=y
# CONFIG_DEBUG_STRICT_USER_COPY_CHECKS is not set
CONFIG_DEBUG_NMI_SELFTEST=y

#
# Security options
#
CONFIG_KEYS=y
CONFIG_ENCRYPTED_KEYS=y
# CONFIG_KEYS_DEBUG_PROC_KEYS is not set
# CONFIG_SECURITY_DMESG_RESTRICT is not set
# CONFIG_SECURITY is not set
CONFIG_SECURITYFS=y
CONFIG_DEFAULT_SECURITY_DAC=y
CONFIG_DEFAULT_SECURITY=""
CONFIG_XOR_BLOCKS=y
CONFIG_ASYNC_CORE=y
CONFIG_ASYNC_XOR=y
CONFIG_CRYPTO=y

#
# Crypto core or helper
#
# CONFIG_CRYPTO_FIPS is not set
CONFIG_CRYPTO_ALGAPI=y
CONFIG_CRYPTO_ALGAPI2=y
CONFIG_CRYPTO_AEAD=y
CONFIG_CRYPTO_AEAD2=y
CONFIG_CRYPTO_BLKCIPHER=y
CONFIG_CRYPTO_BLKCIPHER2=y
CONFIG_CRYPTO_HASH=y
CONFIG_CRYPTO_HASH2=y
CONFIG_CRYPTO_RNG=y
CONFIG_CRYPTO_RNG2=y
CONFIG_CRYPTO_PCOMP2=y
CONFIG_CRYPTO_MANAGER=y
CONFIG_CRYPTO_MANAGER2=y
# CONFIG_CRYPTO_USER is not set
# CONFIG_CRYPTO_MANAGER_DISABLE_TESTS is not set
CONFIG_CRYPTO_GF128MUL=y
CONFIG_CRYPTO_NULL=y
CONFIG_CRYPTO_WORKQUEUE=y
CONFIG_CRYPTO_CRYPTD=y
CONFIG_CRYPTO_AUTHENC=y

#
# Authenticated Encryption with Associated Data
#
# CONFIG_CRYPTO_CCM is not set
# CONFIG_CRYPTO_GCM is not set
CONFIG_CRYPTO_SEQIV=y

#
# Block modes
#
CONFIG_CRYPTO_CBC=y
# CONFIG_CRYPTO_CTR is not set
# CONFIG_CRYPTO_CTS is not set
CONFIG_CRYPTO_ECB=y
CONFIG_CRYPTO_LRW=y
CONFIG_CRYPTO_PCBC=y
CONFIG_CRYPTO_XTS=y

#
# Hash modes
#
CONFIG_CRYPTO_HMAC=y
CONFIG_CRYPTO_XCBC=y
CONFIG_CRYPTO_VMAC=y

#
# Digest
#
CONFIG_CRYPTO_CRC32C=y
CONFIG_CRYPTO_CRC32C_INTEL=y
CONFIG_CRYPTO_GHASH=y
# CONFIG_CRYPTO_MD4 is not set
CONFIG_CRYPTO_MD5=y
# CONFIG_CRYPTO_MICHAEL_MIC is not set
CONFIG_CRYPTO_RMD128=y
CONFIG_CRYPTO_RMD160=y
CONFIG_CRYPTO_RMD256=y
# CONFIG_CRYPTO_RMD320 is not set
CONFIG_CRYPTO_SHA1=y
# CONFIG_CRYPTO_SHA1_SSSE3 is not set
CONFIG_CRYPTO_SHA256=y
CONFIG_CRYPTO_SHA512=y
CONFIG_CRYPTO_TGR192=y
CONFIG_CRYPTO_WP512=y
# CONFIG_CRYPTO_GHASH_CLMUL_NI_INTEL is not set

#
# Ciphers
#
CONFIG_CRYPTO_AES=y
CONFIG_CRYPTO_AES_X86_64=y
# CONFIG_CRYPTO_AES_NI_INTEL is not set
CONFIG_CRYPTO_ANUBIS=y
# CONFIG_CRYPTO_ARC4 is not set
CONFIG_CRYPTO_BLOWFISH=y
CONFIG_CRYPTO_BLOWFISH_COMMON=y
CONFIG_CRYPTO_BLOWFISH_X86_64=y
CONFIG_CRYPTO_CAMELLIA=y
# CONFIG_CRYPTO_CAST5 is not set
CONFIG_CRYPTO_CAST6=y
CONFIG_CRYPTO_DES=y
CONFIG_CRYPTO_FCRYPT=y
# CONFIG_CRYPTO_KHAZAD is not set
# CONFIG_CRYPTO_SALSA20 is not set
# CONFIG_CRYPTO_SALSA20_X86_64 is not set
# CONFIG_CRYPTO_SEED is not set
CONFIG_CRYPTO_SERPENT=y
CONFIG_CRYPTO_SERPENT_SSE2_X86_64=y
CONFIG_CRYPTO_TEA=y
# CONFIG_CRYPTO_TWOFISH is not set
CONFIG_CRYPTO_TWOFISH_COMMON=y
CONFIG_CRYPTO_TWOFISH_X86_64=y
# CONFIG_CRYPTO_TWOFISH_X86_64_3WAY is not set

#
# Compression
#
CONFIG_CRYPTO_DEFLATE=y
# CONFIG_CRYPTO_ZLIB is not set
CONFIG_CRYPTO_LZO=y

#
# Random Number Generation
#
CONFIG_CRYPTO_ANSI_CPRNG=y
CONFIG_CRYPTO_USER_API=y
CONFIG_CRYPTO_USER_API_HASH=y
CONFIG_CRYPTO_USER_API_SKCIPHER=y
CONFIG_CRYPTO_HW=y
CONFIG_CRYPTO_DEV_PADLOCK=y
# CONFIG_CRYPTO_DEV_PADLOCK_AES is not set
# CONFIG_CRYPTO_DEV_PADLOCK_SHA is not set
CONFIG_HAVE_KVM=y
CONFIG_HAVE_KVM_IRQCHIP=y
CONFIG_HAVE_KVM_EVENTFD=y
CONFIG_KVM_APIC_ARCHITECTURE=y
CONFIG_KVM_MMIO=y
CONFIG_KVM_ASYNC_PF=y
CONFIG_VIRTUALIZATION=y
CONFIG_KVM=y
CONFIG_KVM_INTEL=y
# CONFIG_KVM_AMD is not set
# CONFIG_KVM_MMU_AUDIT is not set
CONFIG_VHOST_NET=y
CONFIG_BINARY_PRINTF=y

#
# Library routines
#
CONFIG_BITREVERSE=y
CONFIG_GENERIC_FIND_FIRST_BIT=y
CONFIG_GENERIC_PCI_IOMAP=y
CONFIG_GENERIC_IOMAP=y
CONFIG_CRC_CCITT=y
CONFIG_CRC16=y
CONFIG_CRC_T10DIF=y
CONFIG_CRC_ITU_T=y
CONFIG_CRC32=y
CONFIG_CRC7=y
CONFIG_LIBCRC32C=y
CONFIG_CRC8=y
CONFIG_ZLIB_INFLATE=y
CONFIG_ZLIB_DEFLATE=y
CONFIG_LZO_COMPRESS=y
CONFIG_LZO_DECOMPRESS=y
CONFIG_XZ_DEC=y
CONFIG_XZ_DEC_X86=y
CONFIG_XZ_DEC_POWERPC=y
CONFIG_XZ_DEC_IA64=y
CONFIG_XZ_DEC_ARM=y
CONFIG_XZ_DEC_ARMTHUMB=y
CONFIG_XZ_DEC_SPARC=y
CONFIG_XZ_DEC_BCJ=y
# CONFIG_XZ_DEC_TEST is not set
CONFIG_DECOMPRESS_GZIP=y
CONFIG_DECOMPRESS_BZIP2=y
CONFIG_DECOMPRESS_LZMA=y
CONFIG_DECOMPRESS_XZ=y
CONFIG_DECOMPRESS_LZO=y
CONFIG_BCH=y
CONFIG_BCH_CONST_PARAMS=y
CONFIG_TEXTSEARCH=y
CONFIG_TEXTSEARCH_KMP=y
CONFIG_TEXTSEARCH_BM=y
CONFIG_TEXTSEARCH_FSM=y
CONFIG_HAS_IOMEM=y
CONFIG_HAS_IOPORT=y
CONFIG_HAS_DMA=y
CONFIG_CHECK_SIGNATURE=y
CONFIG_DQL=y
CONFIG_NLATTR=y
CONFIG_AVERAGE=y
# CONFIG_CORDIC is not set
CONFIG_MPILIB=y
CONFIG_MPILIB_EXTRA=y
# CONFIG_DIGSIG is not set

--------------070407000708080709040807
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--------------070407000708080709040807--


From xen-devel-bounces@lists.xensource.com Wed Dec 21 19:22:03 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 19:22:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdRjG-0005Et-3v; Wed, 21 Dec 2011 19:21:30 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <xen-devel.GarveyPatrickD@OrdinaryAmerican.net>)
	id 1RdRjE-0005En-CI
	for xen-devel@lists.xensource.com; Wed, 21 Dec 2011 19:21:28 +0000
X-Env-Sender: xen-devel.GarveyPatrickD@OrdinaryAmerican.net
X-Msg-Ref: server-5.tower-216.messagelabs.com!1324495281!8364901!1
X-Originating-IP: [216.75.62.102]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 534 invoked from network); 21 Dec 2011 19:21:22 -0000
Received: from gourmet7.spamgourmet.com (HELO gourmet8.spamgourmet.com)
	(216.75.62.102) by server-5.tower-216.messagelabs.com with SMTP;
	21 Dec 2011 19:21:22 -0000
Received: from spamgourmet by gourmet7.spamgourmet.com with local (Exim 4.69)
	(envelope-from <xen-devel.GarveyPatrickD@OrdinaryAmerican.net>)
	id 1RdRj7-0003l5-H1
	for xen-devel@lists.xensource.com; Wed, 21 Dec 2011 19:21:21 +0000
Received: from mail-gx0-f176.google.com ([209.85.161.176])
	by gourmet7.spamgourmet.com with esmtp (Exim 4.69)
	(envelope-from <xen-devel.GarveyPatrickD@OrdinaryAmerican.net>)
	id 1RdRj7-0003kn-AN for
	+xen-devel+GarveyPatrickD+fbe7693c78.xen-devel#lists.xensource.com@spamgourmet.com;
	Wed, 21 Dec 2011 19:21:21 +0000
Received: by ggnr4 with SMTP id r4so6118431ggn.7 for
	<+xen-devel+GarveyPatrickD+fbe7693c78.xen-devel#lists.xensource.com@spamgourmet.com>;
	Wed, 21 Dec 2011 11:21:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=D9rvs2MzAmMxEibB5ceLSBqjbX9rcVPqqe1mZYk6u+Y=;
	b=FzHFjIDjeF7Eh1VMRD1WLPCgUP7dp4rUCIvmW01Xk3WM8VE6qo1WcbC04FSqxjOBQu
	0TgeNmxDN2uYb+y4irxXWcc67rEaH1GuGiCjcnegNM4ikn/Rrr+/7y45njypdsaCoynz
	56NfzK66Bzva6LpEO9wclx+U4tZ5Kf8Yb+X/4=
MIME-Version: 1.0
Received: by 10.182.13.42 with SMTP id e10mr6748108obc.18.1324495280790; Wed,
	21 Dec 2011 11:21:20 -0800 (PST)
Received: by 10.182.16.163 with HTTP; Wed, 21 Dec 2011 11:21:20 -0800 (PST)
Date: Wed, 21 Dec 2011 11:21:20 -0800
Message-ID: <CACm5R6R4M6oDdgHyKLkUr4jah3Bki-gDCfTUQpDDTQS8X4bBCw@mail.gmail.com>
From: xen-devel.GarveyPatrickD@OrdinaryAmerican.net
To: xen-devel@lists.xensource.com
X-Spamgourmet: 
Subject: [Xen-devel] The connection to the server was reset while the page
	was loading.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On http://xen.org/projects/xenhv_devs.html
there is a link to http://lxr.xensource.com/lxr/source/MAINTAINERS
which responds "The connection to the server was reset while the page
was loading."


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 21 19:22:03 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 19:22:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdRjG-0005Et-3v; Wed, 21 Dec 2011 19:21:30 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <xen-devel.GarveyPatrickD@OrdinaryAmerican.net>)
	id 1RdRjE-0005En-CI
	for xen-devel@lists.xensource.com; Wed, 21 Dec 2011 19:21:28 +0000
X-Env-Sender: xen-devel.GarveyPatrickD@OrdinaryAmerican.net
X-Msg-Ref: server-5.tower-216.messagelabs.com!1324495281!8364901!1
X-Originating-IP: [216.75.62.102]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 534 invoked from network); 21 Dec 2011 19:21:22 -0000
Received: from gourmet7.spamgourmet.com (HELO gourmet8.spamgourmet.com)
	(216.75.62.102) by server-5.tower-216.messagelabs.com with SMTP;
	21 Dec 2011 19:21:22 -0000
Received: from spamgourmet by gourmet7.spamgourmet.com with local (Exim 4.69)
	(envelope-from <xen-devel.GarveyPatrickD@OrdinaryAmerican.net>)
	id 1RdRj7-0003l5-H1
	for xen-devel@lists.xensource.com; Wed, 21 Dec 2011 19:21:21 +0000
Received: from mail-gx0-f176.google.com ([209.85.161.176])
	by gourmet7.spamgourmet.com with esmtp (Exim 4.69)
	(envelope-from <xen-devel.GarveyPatrickD@OrdinaryAmerican.net>)
	id 1RdRj7-0003kn-AN for
	+xen-devel+GarveyPatrickD+fbe7693c78.xen-devel#lists.xensource.com@spamgourmet.com;
	Wed, 21 Dec 2011 19:21:21 +0000
Received: by ggnr4 with SMTP id r4so6118431ggn.7 for
	<+xen-devel+GarveyPatrickD+fbe7693c78.xen-devel#lists.xensource.com@spamgourmet.com>;
	Wed, 21 Dec 2011 11:21:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=D9rvs2MzAmMxEibB5ceLSBqjbX9rcVPqqe1mZYk6u+Y=;
	b=FzHFjIDjeF7Eh1VMRD1WLPCgUP7dp4rUCIvmW01Xk3WM8VE6qo1WcbC04FSqxjOBQu
	0TgeNmxDN2uYb+y4irxXWcc67rEaH1GuGiCjcnegNM4ikn/Rrr+/7y45njypdsaCoynz
	56NfzK66Bzva6LpEO9wclx+U4tZ5Kf8Yb+X/4=
MIME-Version: 1.0
Received: by 10.182.13.42 with SMTP id e10mr6748108obc.18.1324495280790; Wed,
	21 Dec 2011 11:21:20 -0800 (PST)
Received: by 10.182.16.163 with HTTP; Wed, 21 Dec 2011 11:21:20 -0800 (PST)
Date: Wed, 21 Dec 2011 11:21:20 -0800
Message-ID: <CACm5R6R4M6oDdgHyKLkUr4jah3Bki-gDCfTUQpDDTQS8X4bBCw@mail.gmail.com>
From: xen-devel.GarveyPatrickD@OrdinaryAmerican.net
To: xen-devel@lists.xensource.com
X-Spamgourmet: 
Subject: [Xen-devel] The connection to the server was reset while the page
	was loading.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On http://xen.org/projects/xenhv_devs.html
there is a link to http://lxr.xensource.com/lxr/source/MAINTAINERS
which responds "The connection to the server was reset while the page
was loading."


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 21 19:32:19 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 19:32:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdRtC-0005Py-8X; Wed, 21 Dec 2011 19:31:46 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RdRtB-0005Pt-6H
	for xen-devel@lists.xensource.com; Wed, 21 Dec 2011 19:31:45 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1324495897!7909588!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDU0NTUw\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12911 invoked from network); 21 Dec 2011 19:31:38 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-3.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Dec 2011 19:31:38 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pBLJVOqx020427
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 21 Dec 2011 19:31:24 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pBLJVMwe003822
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 21 Dec 2011 19:31:23 GMT
Received: from abhmt114.oracle.com (abhmt114.oracle.com [141.146.116.66])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pBLJVMdw022430; Wed, 21 Dec 2011 13:31:22 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 21 Dec 2011 11:31:22 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id D24AA416F3; Wed, 21 Dec 2011 14:30:21 -0500 (EST)
Date: Wed, 21 Dec 2011 14:30:21 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Randy Dunlap <rdunlap@xenotime.net>
Message-ID: <20111221193021.GA19671@phenom.dumpdata.com>
References: <20111221174733.9ba0861e762e8d96844b060b@canb.auug.org.au>
	<4EF23D67.9050602@xenotime.net>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4EF23D67.9050602@xenotime.net>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090205.4EF23410.0033,ss=1,re=-6.500,fgs=0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stephen Rothwell <sfr@canb.auug.org.au>,
	linux-next@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>
Subject: Re: [Xen-devel] linux-next: Tree for Dec 21 (xen)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Dec 21, 2011 at 12:11:19PM -0800, Randy Dunlap wrote:
> On 12/20/2011 10:47 PM, Stephen Rothwell wrote:
> > Hi all,
> > 
> > Changes since 20111220:
> 
> 
> drivers/xen/xenbus/xenbus_dev_backend.c:74:2: error: implicit declaration of function 'xen_initial_domain'

Fixed. But I am still not sure what CONFIG_* + header magic is 
is triggering this.

Last time I thought it was the combination of !PCI, !ACPI, and
CONFIG_XEN_XENBUS=m (and the other xen drivers turned to m as well).

But that is not the case here.

Thanks for reporting. Will disect this some more.
> 
> Full randconfig file is attached.
> 
> -- 
> ~Randy
> *** Remember to use Documentation/SubmitChecklist when testing your code ***

> #
> # Automatically generated file; DO NOT EDIT.
> # Linux/x86_64 3.2.0-rc6 Kernel Configuration
> #
> CONFIG_64BIT=y
> # CONFIG_X86_32 is not set
> CONFIG_X86_64=y
> CONFIG_X86=y
> CONFIG_INSTRUCTION_DECODER=y
> CONFIG_OUTPUT_FORMAT="elf64-x86-64"
> CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig"
> CONFIG_GENERIC_CMOS_UPDATE=y
> CONFIG_CLOCKSOURCE_WATCHDOG=y
> CONFIG_GENERIC_CLOCKEVENTS=y
> CONFIG_ARCH_CLOCKSOURCE_DATA=y
> CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
> CONFIG_LOCKDEP_SUPPORT=y
> CONFIG_STACKTRACE_SUPPORT=y
> CONFIG_HAVE_LATENCYTOP_SUPPORT=y
> CONFIG_MMU=y
> CONFIG_ZONE_DMA=y
> CONFIG_NEED_DMA_MAP_STATE=y
> CONFIG_NEED_SG_DMA_LENGTH=y
> CONFIG_GENERIC_ISA_DMA=y
> CONFIG_GENERIC_BUG=y
> CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y
> CONFIG_GENERIC_HWEIGHT=y
> CONFIG_GENERIC_GPIO=y
> CONFIG_ARCH_MAY_HAVE_PC_FDC=y
> # CONFIG_RWSEM_GENERIC_SPINLOCK is not set
> CONFIG_RWSEM_XCHGADD_ALGORITHM=y
> CONFIG_ARCH_HAS_CPU_IDLE_WAIT=y
> CONFIG_GENERIC_CALIBRATE_DELAY=y
> CONFIG_GENERIC_TIME_VSYSCALL=y
> CONFIG_ARCH_HAS_CPU_RELAX=y
> CONFIG_ARCH_HAS_DEFAULT_IDLE=y
> CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
> CONFIG_HAVE_SETUP_PER_CPU_AREA=y
> CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
> CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
> CONFIG_ARCH_HIBERNATION_POSSIBLE=y
> CONFIG_ARCH_SUSPEND_POSSIBLE=y
> CONFIG_ZONE_DMA32=y
> CONFIG_AUDIT_ARCH=y
> CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
> CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
> CONFIG_ARCH_HWEIGHT_CFLAGS="-fcall-saved-rdi -fcall-saved-rsi -fcall-saved-rdx -fcall-saved-rcx -fcall-saved-r8 -fcall-saved-r9 -fcall-saved-r10 -fcall-saved-r11"
> # CONFIG_KTIME_SCALAR is not set
> CONFIG_ARCH_SUPPORTS_UPROBES=y
> CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
> CONFIG_CONSTRUCTORS=y
> CONFIG_HAVE_IRQ_WORK=y
> CONFIG_IRQ_WORK=y
> 
> #
> # General setup
> #
> CONFIG_EXPERIMENTAL=y
> CONFIG_BROKEN_ON_SMP=y
> CONFIG_INIT_ENV_ARG_LIMIT=32
> CONFIG_CROSS_COMPILE=""
> CONFIG_LOCALVERSION=""
> # CONFIG_LOCALVERSION_AUTO is not set
> CONFIG_HAVE_KERNEL_GZIP=y
> CONFIG_HAVE_KERNEL_BZIP2=y
> CONFIG_HAVE_KERNEL_LZMA=y
> CONFIG_HAVE_KERNEL_XZ=y
> CONFIG_HAVE_KERNEL_LZO=y
> # CONFIG_KERNEL_GZIP is not set
> # CONFIG_KERNEL_BZIP2 is not set
> CONFIG_KERNEL_LZMA=y
> # CONFIG_KERNEL_XZ is not set
> # CONFIG_KERNEL_LZO is not set
> CONFIG_DEFAULT_HOSTNAME="(none)"
> CONFIG_SWAP=y
> CONFIG_SYSVIPC=y
> CONFIG_SYSVIPC_SYSCTL=y
> CONFIG_POSIX_MQUEUE=y
> CONFIG_POSIX_MQUEUE_SYSCTL=y
> # CONFIG_BSD_PROCESS_ACCT is not set
> CONFIG_FHANDLE=y
> CONFIG_TASKSTATS=y
> CONFIG_TASK_DELAY_ACCT=y
> CONFIG_TASK_XACCT=y
> CONFIG_TASK_IO_ACCOUNTING=y
> # CONFIG_AUDIT is not set
> CONFIG_HAVE_GENERIC_HARDIRQS=y
> 
> #
> # IRQ subsystem
> #
> CONFIG_GENERIC_HARDIRQS=y
> CONFIG_HAVE_SPARSE_IRQ=y
> CONFIG_GENERIC_IRQ_PROBE=y
> CONFIG_GENERIC_IRQ_SHOW=y
> CONFIG_GENERIC_IRQ_CHIP=y
> CONFIG_IRQ_FORCED_THREADING=y
> CONFIG_SPARSE_IRQ=y
> 
> #
> # RCU Subsystem
> #
> CONFIG_TINY_PREEMPT_RCU=y
> CONFIG_PREEMPT_RCU=y
> CONFIG_RCU_TRACE=y
> # CONFIG_TREE_RCU_TRACE is not set
> # CONFIG_RCU_BOOST is not set
> # CONFIG_IKCONFIG is not set
> CONFIG_LOG_BUF_SHIFT=17
> CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y
> CONFIG_CGROUPS=y
> # CONFIG_CGROUP_DEBUG is not set
> CONFIG_CGROUP_FREEZER=y
> # CONFIG_CGROUP_DEVICE is not set
> CONFIG_CPUSETS=y
> # CONFIG_PROC_PID_CPUSET is not set
> # CONFIG_CGROUP_CPUACCT is not set
> CONFIG_RESOURCE_COUNTERS=y
> # CONFIG_CGROUP_MEM_RES_CTLR is not set
> CONFIG_CGROUP_PERF=y
> # CONFIG_CGROUP_SCHED is not set
> CONFIG_BLK_CGROUP=y
> # CONFIG_DEBUG_BLK_CGROUP is not set
> # CONFIG_CHECKPOINT_RESTORE is not set
> CONFIG_NAMESPACES=y
> # CONFIG_UTS_NS is not set
> CONFIG_IPC_NS=y
> # CONFIG_USER_NS is not set
> # CONFIG_PID_NS is not set
> CONFIG_NET_NS=y
> # CONFIG_SCHED_AUTOGROUP is not set
> # CONFIG_SYSFS_DEPRECATED is not set
> CONFIG_RELAY=y
> CONFIG_BLK_DEV_INITRD=y
> CONFIG_INITRAMFS_SOURCE=""
> CONFIG_RD_GZIP=y
> CONFIG_RD_BZIP2=y
> CONFIG_RD_LZMA=y
> CONFIG_RD_XZ=y
> CONFIG_RD_LZO=y
> # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
> CONFIG_SYSCTL=y
> CONFIG_ANON_INODES=y
> # CONFIG_EXPERT is not set
> CONFIG_UID16=y
> # CONFIG_SYSCTL_SYSCALL is not set
> CONFIG_KALLSYMS=y
> CONFIG_KALLSYMS_ALL=y
> CONFIG_HOTPLUG=y
> CONFIG_PRINTK=y
> CONFIG_BUG=y
> CONFIG_ELF_CORE=y
> CONFIG_PCSPKR_PLATFORM=y
> CONFIG_HAVE_PCSPKR_PLATFORM=y
> CONFIG_BASE_FULL=y
> CONFIG_FUTEX=y
> CONFIG_EPOLL=y
> CONFIG_SIGNALFD=y
> CONFIG_TIMERFD=y
> CONFIG_EVENTFD=y
> CONFIG_SHMEM=y
> CONFIG_AIO=y
> # CONFIG_EMBEDDED is not set
> CONFIG_HAVE_PERF_EVENTS=y
> CONFIG_PERF_USE_VMALLOC=y
> 
> #
> # Kernel Performance Events And Counters
> #
> CONFIG_PERF_EVENTS=y
> # CONFIG_PERF_COUNTERS is not set
> CONFIG_DEBUG_PERF_USE_VMALLOC=y
> CONFIG_VM_EVENT_COUNTERS=y
> CONFIG_PCI_QUIRKS=y
> CONFIG_SLUB_DEBUG=y
> CONFIG_COMPAT_BRK=y
> # CONFIG_SLAB is not set
> CONFIG_SLUB=y
> # CONFIG_PROFILING is not set
> CONFIG_TRACEPOINTS=y
> CONFIG_HAVE_OPROFILE=y
> CONFIG_OPROFILE_NMI_TIMER=y
> # CONFIG_JUMP_LABEL is not set
> CONFIG_UPROBES=y
> CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS=y
> CONFIG_USER_RETURN_NOTIFIER=y
> CONFIG_HAVE_IOREMAP_PROT=y
> CONFIG_HAVE_KPROBES=y
> CONFIG_HAVE_KRETPROBES=y
> CONFIG_HAVE_OPTPROBES=y
> CONFIG_HAVE_ARCH_TRACEHOOK=y
> CONFIG_HAVE_DMA_ATTRS=y
> CONFIG_HAVE_REGS_AND_STACK_ACCESS_API=y
> CONFIG_HAVE_DMA_API_DEBUG=y
> CONFIG_HAVE_HW_BREAKPOINT=y
> CONFIG_HAVE_MIXED_BREAKPOINTS_REGS=y
> CONFIG_HAVE_USER_RETURN_NOTIFIER=y
> CONFIG_HAVE_PERF_EVENTS_NMI=y
> CONFIG_HAVE_ARCH_JUMP_LABEL=y
> CONFIG_ARCH_HAVE_NMI_SAFE_CMPXCHG=y
> CONFIG_HAVE_ALIGNED_STRUCT_PAGE=y
> CONFIG_HAVE_CMPXCHG_LOCAL=y
> CONFIG_HAVE_CMPXCHG_DOUBLE=y
> 
> #
> # GCOV-based kernel profiling
> #
> CONFIG_GCOV_KERNEL=y
> # CONFIG_GCOV_PROFILE_ALL is not set
> # CONFIG_HAVE_GENERIC_DMA_COHERENT is not set
> CONFIG_SLABINFO=y
> CONFIG_RT_MUTEXES=y
> CONFIG_BASE_SMALL=0
> # CONFIG_MODULES is not set
> CONFIG_BLOCK=y
> CONFIG_BLK_DEV_BSG=y
> CONFIG_BLK_DEV_BSGLIB=y
> # CONFIG_BLK_DEV_INTEGRITY is not set
> # CONFIG_BLK_DEV_THROTTLING is not set
> CONFIG_BLOCK_COMPAT=y
> 
> #
> # IO Schedulers
> #
> CONFIG_IOSCHED_NOOP=y
> CONFIG_IOSCHED_DEADLINE=y
> # CONFIG_IOSCHED_CFQ is not set
> # CONFIG_DEFAULT_DEADLINE is not set
> CONFIG_DEFAULT_NOOP=y
> CONFIG_DEFAULT_IOSCHED="noop"
> CONFIG_PREEMPT_NOTIFIERS=y
> # CONFIG_INLINE_SPIN_TRYLOCK is not set
> # CONFIG_INLINE_SPIN_TRYLOCK_BH is not set
> # CONFIG_INLINE_SPIN_LOCK is not set
> # CONFIG_INLINE_SPIN_LOCK_BH is not set
> # CONFIG_INLINE_SPIN_LOCK_IRQ is not set
> # CONFIG_INLINE_SPIN_LOCK_IRQSAVE is not set
> # CONFIG_INLINE_SPIN_UNLOCK is not set
> # CONFIG_INLINE_SPIN_UNLOCK_BH is not set
> # CONFIG_INLINE_SPIN_UNLOCK_IRQ is not set
> # CONFIG_INLINE_SPIN_UNLOCK_IRQRESTORE is not set
> # CONFIG_INLINE_READ_TRYLOCK is not set
> # CONFIG_INLINE_READ_LOCK is not set
> # CONFIG_INLINE_READ_LOCK_BH is not set
> # CONFIG_INLINE_READ_LOCK_IRQ is not set
> # CONFIG_INLINE_READ_LOCK_IRQSAVE is not set
> # CONFIG_INLINE_READ_UNLOCK is not set
> # CONFIG_INLINE_READ_UNLOCK_BH is not set
> # CONFIG_INLINE_READ_UNLOCK_IRQ is not set
> # CONFIG_INLINE_READ_UNLOCK_IRQRESTORE is not set
> # CONFIG_INLINE_WRITE_TRYLOCK is not set
> # CONFIG_INLINE_WRITE_LOCK is not set
> # CONFIG_INLINE_WRITE_LOCK_BH is not set
> # CONFIG_INLINE_WRITE_LOCK_IRQ is not set
> # CONFIG_INLINE_WRITE_LOCK_IRQSAVE is not set
> # CONFIG_INLINE_WRITE_UNLOCK is not set
> # CONFIG_INLINE_WRITE_UNLOCK_BH is not set
> # CONFIG_INLINE_WRITE_UNLOCK_IRQ is not set
> # CONFIG_INLINE_WRITE_UNLOCK_IRQRESTORE is not set
> # CONFIG_MUTEX_SPIN_ON_OWNER is not set
> CONFIG_FREEZER=y
> 
> #
> # Processor type and features
> #
> CONFIG_TICK_ONESHOT=y
> CONFIG_NO_HZ=y
> CONFIG_HIGH_RES_TIMERS=y
> CONFIG_GENERIC_CLOCKEVENTS_BUILD=y
> CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y
> # CONFIG_SMP is not set
> CONFIG_X86_MPPARSE=y
> CONFIG_X86_EXTENDED_PLATFORM=y
> CONFIG_X86_VSMP=y
> # CONFIG_SCHED_OMIT_FRAME_POINTER is not set
> # CONFIG_KVMTOOL_TEST_ENABLE is not set
> CONFIG_PARAVIRT_GUEST=y
> # CONFIG_PARAVIRT_TIME_ACCOUNTING is not set
> CONFIG_XEN=y
> CONFIG_XEN_DOM0=y
> CONFIG_XEN_PRIVILEGED_GUEST=y
> CONFIG_XEN_PVHVM=y
> CONFIG_XEN_MAX_DOMAIN_MEMORY=500
> CONFIG_XEN_SAVE_RESTORE=y
> # CONFIG_XEN_DEBUG_FS is not set
> # CONFIG_KVM_CLOCK is not set
> # CONFIG_KVM_GUEST is not set
> CONFIG_PARAVIRT=y
> CONFIG_PARAVIRT_CLOCK=y
> CONFIG_PARAVIRT_DEBUG=y
> CONFIG_NO_BOOTMEM=y
> CONFIG_MEMTEST=y
> # CONFIG_MK8 is not set
> # CONFIG_MPSC is not set
> # CONFIG_MCORE2 is not set
> # CONFIG_MATOM is not set
> CONFIG_GENERIC_CPU=y
> CONFIG_X86_INTERNODE_CACHE_SHIFT=12
> CONFIG_X86_CMPXCHG=y
> CONFIG_X86_L1_CACHE_SHIFT=6
> CONFIG_X86_XADD=y
> CONFIG_X86_WP_WORKS_OK=y
> CONFIG_X86_TSC=y
> CONFIG_X86_CMPXCHG64=y
> CONFIG_X86_CMOV=y
> CONFIG_X86_MINIMUM_CPU_FAMILY=64
> CONFIG_X86_DEBUGCTLMSR=y
> CONFIG_CPU_SUP_INTEL=y
> CONFIG_CPU_SUP_AMD=y
> CONFIG_CPU_SUP_CENTAUR=y
> CONFIG_HPET_TIMER=y
> CONFIG_HPET_EMULATE_RTC=y
> CONFIG_DMI=y
> CONFIG_GART_IOMMU=y
> CONFIG_CALGARY_IOMMU=y
> # CONFIG_CALGARY_IOMMU_ENABLED_BY_DEFAULT is not set
> CONFIG_SWIOTLB=y
> CONFIG_IOMMU_HELPER=y
> CONFIG_NR_CPUS=1
> # CONFIG_IRQ_TIME_ACCOUNTING is not set
> # CONFIG_PREEMPT_NONE is not set
> # CONFIG_PREEMPT_VOLUNTARY is not set
> CONFIG_PREEMPT=y
> CONFIG_PREEMPT_COUNT=y
> CONFIG_X86_LOCAL_APIC=y
> CONFIG_X86_IO_APIC=y
> CONFIG_X86_REROUTE_FOR_BROKEN_BOOT_IRQS=y
> # CONFIG_X86_MCE is not set
> # CONFIG_I8K is not set
> # CONFIG_MICROCODE is not set
> CONFIG_X86_MSR=y
> # CONFIG_X86_CPUID is not set
> CONFIG_ARCH_PHYS_ADDR_T_64BIT=y
> CONFIG_ARCH_DMA_ADDR_T_64BIT=y
> CONFIG_DIRECT_GBPAGES=y
> CONFIG_ARCH_SPARSEMEM_ENABLE=y
> CONFIG_ARCH_SPARSEMEM_DEFAULT=y
> CONFIG_ARCH_SELECT_MEMORY_MODEL=y
> CONFIG_ARCH_PROC_KCORE_TEXT=y
> CONFIG_ILLEGAL_POINTER_VALUE=0xdead000000000000
> CONFIG_SELECT_MEMORY_MODEL=y
> CONFIG_SPARSEMEM_MANUAL=y
> CONFIG_SPARSEMEM=y
> CONFIG_HAVE_MEMORY_PRESENT=y
> CONFIG_SPARSEMEM_EXTREME=y
> CONFIG_SPARSEMEM_VMEMMAP_ENABLE=y
> CONFIG_SPARSEMEM_ALLOC_MEM_MAP_TOGETHER=y
> CONFIG_SPARSEMEM_VMEMMAP=y
> CONFIG_HAVE_MEMBLOCK=y
> CONFIG_HAVE_MEMBLOCK_NODE_MAP=y
> CONFIG_ARCH_DISCARD_MEMBLOCK=y
> # CONFIG_MEMORY_HOTPLUG is not set
> CONFIG_PAGEFLAGS_EXTENDED=y
> CONFIG_SPLIT_PTLOCK_CPUS=999999
> CONFIG_COMPACTION=y
> CONFIG_MIGRATION=y
> CONFIG_PHYS_ADDR_T_64BIT=y
> CONFIG_ZONE_DMA_FLAG=1
> CONFIG_BOUNCE=y
> CONFIG_VIRT_TO_BUS=y
> CONFIG_MMU_NOTIFIER=y
> CONFIG_KSM=y
> CONFIG_DEFAULT_MMAP_MIN_ADDR=4096
> CONFIG_TRANSPARENT_HUGEPAGE=y
> # CONFIG_TRANSPARENT_HUGEPAGE_ALWAYS is not set
> CONFIG_TRANSPARENT_HUGEPAGE_MADVISE=y
> CONFIG_NEED_PER_CPU_KM=y
> CONFIG_CLEANCACHE=y
> CONFIG_FRONTSWAP=y
> CONFIG_X86_CHECK_BIOS_CORRUPTION=y
> CONFIG_X86_BOOTPARAM_MEMORY_CORRUPTION_CHECK=y
> CONFIG_X86_RESERVE_LOW=64
> CONFIG_MTRR=y
> CONFIG_MTRR_SANITIZER=y
> CONFIG_MTRR_SANITIZER_ENABLE_DEFAULT=0
> CONFIG_MTRR_SANITIZER_SPARE_REG_NR_DEFAULT=1
> CONFIG_X86_PAT=y
> CONFIG_ARCH_USES_PG_UNCACHED=y
> CONFIG_ARCH_RANDOM=y
> CONFIG_EFI=y
> CONFIG_EFI_STUB=y
> CONFIG_SECCOMP=y
> # CONFIG_CC_STACKPROTECTOR is not set
> # CONFIG_HZ_100 is not set
> CONFIG_HZ_250=y
> # CONFIG_HZ_300 is not set
> # CONFIG_HZ_1000 is not set
> CONFIG_HZ=250
> CONFIG_SCHED_HRTICK=y
> # CONFIG_KEXEC is not set
> # CONFIG_CRASH_DUMP is not set
> CONFIG_PHYSICAL_START=0x1000000
> CONFIG_RELOCATABLE=y
> CONFIG_PHYSICAL_ALIGN=0x1000000
> CONFIG_COMPAT_VDSO=y
> CONFIG_CMDLINE_BOOL=y
> CONFIG_CMDLINE=""
> # CONFIG_CMDLINE_OVERRIDE is not set
> CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y
> 
> #
> # Power management and ACPI options
> #
> CONFIG_ARCH_HIBERNATION_HEADER=y
> # CONFIG_SUSPEND is not set
> CONFIG_HIBERNATE_CALLBACKS=y
> CONFIG_HIBERNATION=y
> CONFIG_PM_STD_PARTITION=""
> CONFIG_PM_SLEEP=y
> # CONFIG_PM_RUNTIME is not set
> CONFIG_PM=y
> CONFIG_PM_DEBUG=y
> # CONFIG_PM_ADVANCED_DEBUG is not set
> CONFIG_CAN_PM_TRACE=y
> # CONFIG_PM_TRACE_RTC is not set
> CONFIG_ACPI=y
> CONFIG_ACPI_SLEEP=y
> CONFIG_ACPI_PROCFS=y
> # CONFIG_ACPI_PROCFS_POWER is not set
> # CONFIG_ACPI_EC_DEBUGFS is not set
> CONFIG_ACPI_PROC_EVENT=y
> # CONFIG_ACPI_AC is not set
> CONFIG_ACPI_BATTERY=y
> CONFIG_ACPI_BUTTON=y
> CONFIG_ACPI_VIDEO=y
> CONFIG_ACPI_FAN=y
> CONFIG_ACPI_DOCK=y
> CONFIG_ACPI_PROCESSOR=y
> CONFIG_ACPI_PROCESSOR_AGGREGATOR=y
> # CONFIG_ACPI_THERMAL is not set
> # CONFIG_ACPI_CUSTOM_DSDT is not set
> CONFIG_ACPI_BLACKLIST_YEAR=0
> # CONFIG_ACPI_DEBUG is not set
> # CONFIG_ACPI_PCI_SLOT is not set
> CONFIG_X86_PM_TIMER=y
> # CONFIG_ACPI_CONTAINER is not set
> CONFIG_ACPI_SBS=y
> CONFIG_ACPI_HED=y
> CONFIG_ACPI_CUSTOM_METHOD=y
> CONFIG_ACPI_APEI=y
> # CONFIG_ACPI_APEI_GHES is not set
> # CONFIG_ACPI_APEI_PCIEAER is not set
> CONFIG_ACPI_APEI_EINJ=y
> # CONFIG_ACPI_APEI_ERST_DEBUG is not set
> # CONFIG_SFI is not set
> 
> #
> # CPU Frequency scaling
> #
> # CONFIG_CPU_FREQ is not set
> CONFIG_CPU_IDLE=y
> CONFIG_CPU_IDLE_GOV_LADDER=y
> CONFIG_CPU_IDLE_GOV_MENU=y
> # CONFIG_INTEL_IDLE is not set
> 
> #
> # Memory power savings
> #
> # CONFIG_I7300_IDLE is not set
> 
> #
> # Bus options (PCI etc.)
> #
> CONFIG_PCI=y
> CONFIG_PCI_DIRECT=y
> CONFIG_PCI_MMCONFIG=y
> CONFIG_PCI_XEN=y
> CONFIG_PCI_DOMAINS=y
> # CONFIG_PCI_CNB20LE_QUIRK is not set
> CONFIG_PCIEPORTBUS=y
> # CONFIG_HOTPLUG_PCI_PCIE is not set
> CONFIG_PCIEAER=y
> CONFIG_PCIE_ECRC=y
> # CONFIG_PCIEAER_INJECT is not set
> CONFIG_PCIEASPM=y
> CONFIG_PCIEASPM_DEBUG=y
> CONFIG_ARCH_SUPPORTS_MSI=y
> # CONFIG_PCI_MSI is not set
> # CONFIG_PCI_DEBUG is not set
> # CONFIG_PCI_STUB is not set
> CONFIG_XEN_PCIDEV_FRONTEND=y
> # CONFIG_HT_IRQ is not set
> CONFIG_PCI_ATS=y
> CONFIG_PCI_IOV=y
> # CONFIG_PCI_PRI is not set
> # CONFIG_PCI_PASID is not set
> CONFIG_PCI_IOAPIC=y
> CONFIG_PCI_LABEL=y
> CONFIG_ISA_DMA_API=y
> CONFIG_AMD_NB=y
> CONFIG_PCCARD=y
> # CONFIG_PCMCIA is not set
> CONFIG_CARDBUS=y
> 
> #
> # PC-card bridges
> #
> CONFIG_YENTA=y
> CONFIG_YENTA_O2=y
> CONFIG_YENTA_RICOH=y
> CONFIG_YENTA_TI=y
> CONFIG_YENTA_ENE_TUNE=y
> CONFIG_YENTA_TOSHIBA=y
> CONFIG_HOTPLUG_PCI=y
> # CONFIG_HOTPLUG_PCI_FAKE is not set
> # CONFIG_HOTPLUG_PCI_ACPI is not set
> # CONFIG_HOTPLUG_PCI_CPCI is not set
> # CONFIG_HOTPLUG_PCI_SHPC is not set
> CONFIG_RAPIDIO=y
> # CONFIG_RAPIDIO_TSI721 is not set
> CONFIG_RAPIDIO_DISC_TIMEOUT=30
> # CONFIG_RAPIDIO_ENABLE_RX_TX_PORTS is not set
> CONFIG_RAPIDIO_DEBUG=y
> # CONFIG_RAPIDIO_TSI57X is not set
> # CONFIG_RAPIDIO_CPS_XX is not set
> CONFIG_RAPIDIO_TSI568=y
> # CONFIG_RAPIDIO_CPS_GEN2 is not set
> # CONFIG_RAPIDIO_TSI500 is not set
> 
> #
> # Executable file formats / Emulations
> #
> # CONFIG_BINFMT_ELF is not set
> CONFIG_COMPAT_BINFMT_ELF=y
> CONFIG_ARCH_BINFMT_ELF_RANDOMIZE_PIE=y
> # CONFIG_HAVE_AOUT is not set
> # CONFIG_BINFMT_MISC is not set
> CONFIG_IA32_EMULATION=y
> # CONFIG_IA32_AOUT is not set
> CONFIG_COMPAT=y
> CONFIG_COMPAT_FOR_U64_ALIGNMENT=y
> CONFIG_SYSVIPC_COMPAT=y
> CONFIG_KEYS_COMPAT=y
> CONFIG_HAVE_TEXT_POKE_SMP=y
> CONFIG_NET=y
> CONFIG_COMPAT_NETLINK_MESSAGES=y
> 
> #
> # Networking options
> #
> # CONFIG_PACKET is not set
> CONFIG_UNIX=y
> # CONFIG_UNIX_DIAG is not set
> CONFIG_XFRM=y
> CONFIG_XFRM_SUB_POLICY=y
> CONFIG_XFRM_MIGRATE=y
> CONFIG_NET_KEY=y
> CONFIG_NET_KEY_MIGRATE=y
> # CONFIG_INET is not set
> CONFIG_NETWORK_SECMARK=y
> # CONFIG_NETWORK_PHY_TIMESTAMPING is not set
> CONFIG_NETFILTER=y
> CONFIG_NETFILTER_DEBUG=y
> # CONFIG_NETFILTER_ADVANCED is not set
> CONFIG_ATM=y
> CONFIG_ATM_LANE=y
> # CONFIG_BRIDGE is not set
> CONFIG_NET_DSA=y
> CONFIG_NET_DSA_TAG_DSA=y
> CONFIG_NET_DSA_TAG_EDSA=y
> CONFIG_NET_DSA_TAG_TRAILER=y
> # CONFIG_VLAN_8021Q is not set
> # CONFIG_DECNET is not set
> CONFIG_LLC=y
> CONFIG_LLC2=y
> CONFIG_IPX=y
> CONFIG_IPX_INTERN=y
> # CONFIG_ATALK is not set
> CONFIG_X25=y
> # CONFIG_LAPB is not set
> # CONFIG_WAN_ROUTER is not set
> CONFIG_PHONET=y
> # CONFIG_IEEE802154 is not set
> CONFIG_NET_SCHED=y
> 
> #
> # Queueing/Scheduling
> #
> # CONFIG_NET_SCH_CBQ is not set
> CONFIG_NET_SCH_HTB=y
> CONFIG_NET_SCH_HFSC=y
> CONFIG_NET_SCH_ATM=y
> # CONFIG_NET_SCH_PRIO is not set
> # CONFIG_NET_SCH_MULTIQ is not set
> CONFIG_NET_SCH_RED=y
> CONFIG_NET_SCH_SFB=y
> CONFIG_NET_SCH_SFQ=y
> # CONFIG_NET_SCH_TEQL is not set
> CONFIG_NET_SCH_TBF=y
> # CONFIG_NET_SCH_GRED is not set
> # CONFIG_NET_SCH_DSMARK is not set
> # CONFIG_NET_SCH_NETEM is not set
> CONFIG_NET_SCH_DRR=y
> # CONFIG_NET_SCH_MQPRIO is not set
> # CONFIG_NET_SCH_CHOKE is not set
> CONFIG_NET_SCH_QFQ=y
> 
> #
> # Classification
> #
> CONFIG_NET_CLS=y
> # CONFIG_NET_CLS_BASIC is not set
> # CONFIG_NET_CLS_TCINDEX is not set
> CONFIG_NET_CLS_FW=y
> # CONFIG_NET_CLS_U32 is not set
> # CONFIG_NET_CLS_RSVP is not set
> # CONFIG_NET_CLS_RSVP6 is not set
> CONFIG_NET_CLS_FLOW=y
> CONFIG_NET_CLS_CGROUP=y
> CONFIG_NET_EMATCH=y
> CONFIG_NET_EMATCH_STACK=32
> # CONFIG_NET_EMATCH_CMP is not set
> CONFIG_NET_EMATCH_NBYTE=y
> # CONFIG_NET_EMATCH_U32 is not set
> CONFIG_NET_EMATCH_META=y
> CONFIG_NET_EMATCH_TEXT=y
> # CONFIG_NET_CLS_ACT is not set
> CONFIG_NET_CLS_IND=y
> CONFIG_NET_SCH_FIFO=y
> # CONFIG_DCB is not set
> # CONFIG_DNS_RESOLVER is not set
> # CONFIG_BATMAN_ADV is not set
> CONFIG_OPENVSWITCH=y
> CONFIG_NETPRIO_CGROUP=y
> CONFIG_BQL=y
> CONFIG_HAVE_BPF_JIT=y
> 
> #
> # Network testing
> #
> CONFIG_NET_PKTGEN=y
> # CONFIG_HAMRADIO is not set
> # CONFIG_CAN is not set
> CONFIG_IRDA=y
> 
> #
> # IrDA protocols
> #
> CONFIG_IRLAN=y
> # CONFIG_IRCOMM is not set
> CONFIG_IRDA_ULTRA=y
> 
> #
> # IrDA options
> #
> # CONFIG_IRDA_CACHE_LAST_LSAP is not set
> # CONFIG_IRDA_FAST_RR is not set
> CONFIG_IRDA_DEBUG=y
> 
> #
> # Infrared-port device drivers
> #
> 
> #
> # SIR device drivers
> #
> # CONFIG_IRTTY_SIR is not set
> 
> #
> # Dongle support
> #
> 
> #
> # FIR device drivers
> #
> # CONFIG_NSC_FIR is not set
> # CONFIG_WINBOND_FIR is not set
> CONFIG_SMC_IRCC_FIR=y
> CONFIG_ALI_FIR=y
> CONFIG_VLSI_FIR=y
> # CONFIG_VIA_FIR is not set
> # CONFIG_BT is not set
> CONFIG_WIRELESS=y
> CONFIG_WIRELESS_EXT=y
> CONFIG_WEXT_CORE=y
> CONFIG_WEXT_PROC=y
> CONFIG_WEXT_SPY=y
> CONFIG_WEXT_PRIV=y
> # CONFIG_CFG80211 is not set
> CONFIG_WIRELESS_EXT_SYSFS=y
> # CONFIG_LIB80211 is not set
> 
> #
> # CFG80211 needs to be enabled for MAC80211
> #
> CONFIG_WIMAX=y
> CONFIG_WIMAX_DEBUG_LEVEL=8
> # CONFIG_RFKILL is not set
> CONFIG_RFKILL_REGULATOR=y
> CONFIG_NET_9P=y
> # CONFIG_NET_9P_VIRTIO is not set
> CONFIG_NET_9P_DEBUG=y
> # CONFIG_CAIF is not set
> # CONFIG_NFC is not set
> 
> #
> # Device Drivers
> #
> 
> #
> # Generic Driver Options
> #
> CONFIG_UEVENT_HELPER_PATH=""
> # CONFIG_DEVTMPFS is not set
> CONFIG_STANDALONE=y
> CONFIG_PREVENT_FIRMWARE_BUILD=y
> CONFIG_FW_LOADER=y
> CONFIG_FIRMWARE_IN_KERNEL=y
> CONFIG_EXTRA_FIRMWARE=""
> # CONFIG_DEBUG_DRIVER is not set
> # CONFIG_DEBUG_DEVRES is not set
> CONFIG_SYS_HYPERVISOR=y
> CONFIG_REGMAP=y
> CONFIG_REGMAP_I2C=y
> CONFIG_REGMAP_SPI=y
> CONFIG_REGMAP_IRQ=y
> CONFIG_CONNECTOR=y
> # CONFIG_PROC_EVENTS is not set
> CONFIG_MTD=y
> # CONFIG_MTD_REDBOOT_PARTS is not set
> CONFIG_MTD_CMDLINE_PARTS=y
> # CONFIG_MTD_AR7_PARTS is not set
> 
> #
> # User Modules And Translation Layers
> #
> # CONFIG_MTD_CHAR is not set
> CONFIG_HAVE_MTD_OTP=y
> CONFIG_MTD_BLKDEVS=y
> CONFIG_MTD_BLOCK=y
> CONFIG_FTL=y
> CONFIG_NFTL=y
> # CONFIG_NFTL_RW is not set
> CONFIG_INFTL=y
> CONFIG_RFD_FTL=y
> CONFIG_SSFDC=y
> # CONFIG_SM_FTL is not set
> CONFIG_MTD_OOPS=y
> CONFIG_MTD_SWAP=y
> 
> #
> # RAM/ROM/Flash chip drivers
> #
> CONFIG_MTD_CFI=y
> CONFIG_MTD_JEDECPROBE=y
> CONFIG_MTD_GEN_PROBE=y
> CONFIG_MTD_CFI_ADV_OPTIONS=y
> # CONFIG_MTD_CFI_NOSWAP is not set
> CONFIG_MTD_CFI_BE_BYTE_SWAP=y
> # CONFIG_MTD_CFI_LE_BYTE_SWAP is not set
> CONFIG_MTD_CFI_GEOMETRY=y
> # CONFIG_MTD_MAP_BANK_WIDTH_1 is not set
> CONFIG_MTD_MAP_BANK_WIDTH_2=y
> # CONFIG_MTD_MAP_BANK_WIDTH_4 is not set
> # CONFIG_MTD_MAP_BANK_WIDTH_8 is not set
> CONFIG_MTD_MAP_BANK_WIDTH_16=y
> # CONFIG_MTD_MAP_BANK_WIDTH_32 is not set
> CONFIG_MTD_CFI_I1=y
> CONFIG_MTD_CFI_I2=y
> CONFIG_MTD_CFI_I4=y
> # CONFIG_MTD_CFI_I8 is not set
> CONFIG_MTD_OTP=y
> CONFIG_MTD_CFI_INTELEXT=y
> CONFIG_MTD_CFI_AMDSTD=y
> # CONFIG_MTD_CFI_STAA is not set
> CONFIG_MTD_CFI_UTIL=y
> CONFIG_MTD_RAM=y
> CONFIG_MTD_ROM=y
> CONFIG_MTD_ABSENT=y
> 
> #
> # Mapping drivers for chip access
> #
> CONFIG_MTD_COMPLEX_MAPPINGS=y
> # CONFIG_MTD_PHYSMAP is not set
> CONFIG_MTD_SC520CDP=y
> # CONFIG_MTD_NETSC520 is not set
> CONFIG_MTD_TS5500=y
> CONFIG_MTD_SBC_GXX=y
> # CONFIG_MTD_AMD76XROM is not set
> CONFIG_MTD_ICHXROM=y
> # CONFIG_MTD_ESB2ROM is not set
> CONFIG_MTD_CK804XROM=y
> CONFIG_MTD_SCB2_FLASH=y
> # CONFIG_MTD_NETtel is not set
> CONFIG_MTD_L440GX=y
> # CONFIG_MTD_PCI is not set
> CONFIG_MTD_GPIO_ADDR=y
> # CONFIG_MTD_INTEL_VR_NOR is not set
> CONFIG_MTD_PLATRAM=y
> CONFIG_MTD_LATCH_ADDR=y
> 
> #
> # Self-contained MTD device drivers
> #
> # CONFIG_MTD_PMC551 is not set
> CONFIG_MTD_DATAFLASH=y
> # CONFIG_MTD_DATAFLASH_WRITE_VERIFY is not set
> # CONFIG_MTD_DATAFLASH_OTP is not set
> # CONFIG_MTD_M25P80 is not set
> # CONFIG_MTD_SST25L is not set
> CONFIG_MTD_SLRAM=y
> # CONFIG_MTD_PHRAM is not set
> # CONFIG_MTD_MTDRAM is not set
> # CONFIG_MTD_BLOCK2MTD is not set
> 
> #
> # Disk-On-Chip Device Drivers
> #
> CONFIG_MTD_DOC2000=y
> CONFIG_MTD_DOC2001=y
> CONFIG_MTD_DOC2001PLUS=y
> CONFIG_MTD_DOCG3=y
> CONFIG_BCH_CONST_M=14
> CONFIG_BCH_CONST_T=4
> CONFIG_MTD_DOCPROBE=y
> CONFIG_MTD_DOCECC=y
> # CONFIG_MTD_DOCPROBE_ADVANCED is not set
> CONFIG_MTD_DOCPROBE_ADDRESS=0x0
> CONFIG_MTD_NAND_ECC=y
> # CONFIG_MTD_NAND_ECC_SMC is not set
> CONFIG_MTD_NAND=y
> CONFIG_MTD_NAND_VERIFY_WRITE=y
> CONFIG_MTD_NAND_BCH=y
> CONFIG_MTD_NAND_ECC_BCH=y
> # CONFIG_MTD_SM_COMMON is not set
> # CONFIG_MTD_NAND_MUSEUM_IDS is not set
> CONFIG_MTD_NAND_DENALI=y
> CONFIG_MTD_NAND_DENALI_SCRATCH_REG_ADDR=0xFF108018
> CONFIG_MTD_NAND_IDS=y
> # CONFIG_MTD_NAND_RICOH is not set
> # CONFIG_MTD_NAND_DISKONCHIP is not set
> # CONFIG_MTD_NAND_CAFE is not set
> CONFIG_MTD_NAND_NANDSIM=y
> CONFIG_MTD_NAND_PLATFORM=y
> CONFIG_MTD_ONENAND=y
> # CONFIG_MTD_ONENAND_VERIFY_WRITE is not set
> CONFIG_MTD_ONENAND_GENERIC=y
> CONFIG_MTD_ONENAND_OTP=y
> CONFIG_MTD_ONENAND_2X_PROGRAM=y
> # CONFIG_MTD_ONENAND_SIM is not set
> 
> #
> # LPDDR flash memory drivers
> #
> CONFIG_MTD_LPDDR=y
> CONFIG_MTD_QINFO_PROBE=y
> CONFIG_MTD_UBI=y
> CONFIG_MTD_UBI_WL_THRESHOLD=4096
> CONFIG_MTD_UBI_BEB_RESERVE=1
> CONFIG_MTD_UBI_GLUEBI=y
> # CONFIG_MTD_UBI_DEBUG is not set
> # CONFIG_PARPORT is not set
> CONFIG_PNP=y
> # CONFIG_PNP_DEBUG_MESSAGES is not set
> 
> #
> # Protocols
> #
> CONFIG_PNPACPI=y
> CONFIG_BLK_DEV=y
> # CONFIG_BLK_DEV_FD is not set
> # CONFIG_BLK_CPQ_DA is not set
> # CONFIG_BLK_CPQ_CISS_DA is not set
> # CONFIG_BLK_DEV_DAC960 is not set
> CONFIG_BLK_DEV_UMEM=y
> # CONFIG_BLK_DEV_COW_COMMON is not set
> # CONFIG_BLK_DEV_LOOP is not set
> 
> #
> # DRBD disabled because PROC_FS, INET or CONNECTOR not selected
> #
> CONFIG_BLK_DEV_NBD=y
> CONFIG_BLK_DEV_OSD=y
> CONFIG_BLK_DEV_SX8=y
> # CONFIG_BLK_DEV_RAM is not set
> CONFIG_CDROM_PKTCDVD=y
> CONFIG_CDROM_PKTCDVD_BUFFERS=8
> CONFIG_CDROM_PKTCDVD_WCACHE=y
> # CONFIG_ATA_OVER_ETH is not set
> CONFIG_XEN_BLKDEV_FRONTEND=y
> # CONFIG_XEN_BLKDEV_BACKEND is not set
> # CONFIG_VIRTIO_BLK is not set
> CONFIG_BLK_DEV_HD=y
> # CONFIG_SENSORS_LIS3LV02D is not set
> # CONFIG_MISC_DEVICES is not set
> CONFIG_HAVE_IDE=y
> CONFIG_IDE=y
> 
> #
> # Please see Documentation/ide/ide.txt for help/info on IDE drives
> #
> CONFIG_IDE_XFER_MODE=y
> CONFIG_IDE_TIMINGS=y
> CONFIG_BLK_DEV_IDE_SATA=y
> # CONFIG_IDE_GD is not set
> CONFIG_BLK_DEV_DELKIN=y
> # CONFIG_BLK_DEV_IDECD is not set
> # CONFIG_BLK_DEV_IDETAPE is not set
> CONFIG_BLK_DEV_IDEACPI=y
> # CONFIG_IDE_TASK_IOCTL is not set
> # CONFIG_IDE_PROC_FS is not set
> 
> #
> # IDE chipset support/bugfixes
> #
> # CONFIG_IDE_GENERIC is not set
> # CONFIG_BLK_DEV_PLATFORM is not set
> # CONFIG_BLK_DEV_CMD640 is not set
> # CONFIG_BLK_DEV_IDEPNP is not set
> CONFIG_BLK_DEV_IDEDMA_SFF=y
> 
> #
> # PCI IDE chipsets support
> #
> CONFIG_BLK_DEV_IDEPCI=y
> CONFIG_IDEPCI_PCIBUS_ORDER=y
> # CONFIG_BLK_DEV_OFFBOARD is not set
> # CONFIG_BLK_DEV_GENERIC is not set
> # CONFIG_BLK_DEV_OPTI621 is not set
> # CONFIG_BLK_DEV_RZ1000 is not set
> CONFIG_BLK_DEV_IDEDMA_PCI=y
> CONFIG_BLK_DEV_AEC62XX=y
> # CONFIG_BLK_DEV_ALI15X3 is not set
> # CONFIG_BLK_DEV_AMD74XX is not set
> CONFIG_BLK_DEV_ATIIXP=y
> CONFIG_BLK_DEV_CMD64X=y
> CONFIG_BLK_DEV_TRIFLEX=y
> # CONFIG_BLK_DEV_CS5520 is not set
> CONFIG_BLK_DEV_CS5530=y
> CONFIG_BLK_DEV_HPT366=y
> # CONFIG_BLK_DEV_JMICRON is not set
> # CONFIG_BLK_DEV_SC1200 is not set
> # CONFIG_BLK_DEV_PIIX is not set
> CONFIG_BLK_DEV_IT8172=y
> CONFIG_BLK_DEV_IT8213=y
> # CONFIG_BLK_DEV_IT821X is not set
> # CONFIG_BLK_DEV_NS87415 is not set
> # CONFIG_BLK_DEV_PDC202XX_OLD is not set
> CONFIG_BLK_DEV_PDC202XX_NEW=y
> CONFIG_BLK_DEV_SVWKS=y
> # CONFIG_BLK_DEV_SIIMAGE is not set
> # CONFIG_BLK_DEV_SIS5513 is not set
> # CONFIG_BLK_DEV_SLC90E66 is not set
> # CONFIG_BLK_DEV_TRM290 is not set
> # CONFIG_BLK_DEV_VIA82CXXX is not set
> # CONFIG_BLK_DEV_TC86C001 is not set
> CONFIG_BLK_DEV_IDEDMA=y
> 
> #
> # SCSI device support
> #
> CONFIG_SCSI_MOD=y
> CONFIG_RAID_ATTRS=y
> CONFIG_SCSI=y
> CONFIG_SCSI_DMA=y
> # CONFIG_SCSI_TGT is not set
> CONFIG_SCSI_NETLINK=y
> # CONFIG_SCSI_PROC_FS is not set
> 
> #
> # SCSI support type (disk, tape, CD-ROM)
> #
> # CONFIG_BLK_DEV_SD is not set
> # CONFIG_CHR_DEV_ST is not set
> # CONFIG_CHR_DEV_OSST is not set
> # CONFIG_BLK_DEV_SR is not set
> CONFIG_CHR_DEV_SG=y
> # CONFIG_CHR_DEV_SCH is not set
> # CONFIG_SCSI_MULTI_LUN is not set
> # CONFIG_SCSI_CONSTANTS is not set
> # CONFIG_SCSI_LOGGING is not set
> # CONFIG_SCSI_SCAN_ASYNC is not set
> 
> #
> # SCSI Transports
> #
> CONFIG_SCSI_SPI_ATTRS=y
> CONFIG_SCSI_FC_ATTRS=y
> CONFIG_SCSI_ISCSI_ATTRS=y
> CONFIG_SCSI_SAS_ATTRS=y
> CONFIG_SCSI_SAS_LIBSAS=y
> CONFIG_SCSI_SAS_HOST_SMP=y
> CONFIG_SCSI_SRP_ATTRS=y
> CONFIG_SCSI_LOWLEVEL=y
> CONFIG_ISCSI_BOOT_SYSFS=y
> # CONFIG_SCSI_BNX2_ISCSI is not set
> CONFIG_SCSI_BNX2X_FCOE=y
> CONFIG_BE2ISCSI=y
> # CONFIG_BLK_DEV_3W_XXXX_RAID is not set
> CONFIG_SCSI_HPSA=y
> CONFIG_SCSI_3W_9XXX=y
> CONFIG_SCSI_3W_SAS=y
> # CONFIG_SCSI_ACARD is not set
> CONFIG_SCSI_AACRAID=y
> # CONFIG_SCSI_AIC7XXX is not set
> CONFIG_SCSI_AIC7XXX_OLD=y
> CONFIG_SCSI_AIC79XX=y
> CONFIG_AIC79XX_CMDS_PER_DEVICE=32
> CONFIG_AIC79XX_RESET_DELAY_MS=5000
> CONFIG_AIC79XX_DEBUG_ENABLE=y
> CONFIG_AIC79XX_DEBUG_MASK=0
> CONFIG_AIC79XX_REG_PRETTY_PRINT=y
> CONFIG_SCSI_AIC94XX=y
> CONFIG_AIC94XX_DEBUG=y
> CONFIG_SCSI_MVSAS=y
> # CONFIG_SCSI_MVSAS_DEBUG is not set
> CONFIG_SCSI_MVSAS_TASKLET=y
> CONFIG_SCSI_MVUMI=y
> CONFIG_SCSI_DPT_I2O=y
> CONFIG_SCSI_ADVANSYS=y
> CONFIG_SCSI_ARCMSR=y
> CONFIG_MEGARAID_NEWGEN=y
> CONFIG_MEGARAID_MM=y
> # CONFIG_MEGARAID_MAILBOX is not set
> # CONFIG_MEGARAID_LEGACY is not set
> # CONFIG_MEGARAID_SAS is not set
> CONFIG_SCSI_MPT2SAS=y
> CONFIG_SCSI_MPT2SAS_MAX_SGE=128
> CONFIG_SCSI_MPT2SAS_LOGGING=y
> # CONFIG_SCSI_HPTIOP is not set
> # CONFIG_SCSI_BUSLOGIC is not set
> # CONFIG_VMWARE_PVSCSI is not set
> CONFIG_LIBFC=y
> CONFIG_LIBFCOE=y
> CONFIG_FCOE=y
> CONFIG_FCOE_FNIC=y
> # CONFIG_SCSI_DMX3191D is not set
> CONFIG_SCSI_EATA=y
> # CONFIG_SCSI_EATA_TAGGED_QUEUE is not set
> CONFIG_SCSI_EATA_LINKED_COMMANDS=y
> CONFIG_SCSI_EATA_MAX_TAGS=16
> CONFIG_SCSI_FUTURE_DOMAIN=y
> # CONFIG_SCSI_GDTH is not set
> CONFIG_SCSI_ISCI=y
> # CONFIG_SCSI_IPS is not set
> CONFIG_SCSI_INITIO=y
> # CONFIG_SCSI_INIA100 is not set
> # CONFIG_SCSI_STEX is not set
> CONFIG_SCSI_SYM53C8XX_2=y
> CONFIG_SCSI_SYM53C8XX_DMA_ADDRESSING_MODE=1
> CONFIG_SCSI_SYM53C8XX_DEFAULT_TAGS=16
> CONFIG_SCSI_SYM53C8XX_MAX_TAGS=64
> # CONFIG_SCSI_SYM53C8XX_MMIO is not set
> # CONFIG_SCSI_QLOGIC_1280 is not set
> CONFIG_SCSI_QLA_FC=y
> # CONFIG_SCSI_QLA_ISCSI is not set
> CONFIG_SCSI_LPFC=y
> # CONFIG_SCSI_LPFC_DEBUG_FS is not set
> # CONFIG_SCSI_DC395x is not set
> # CONFIG_SCSI_DC390T is not set
> # CONFIG_SCSI_DEBUG is not set
> CONFIG_SCSI_PMCRAID=y
> # CONFIG_SCSI_PM8001 is not set
> # CONFIG_SCSI_SRP is not set
> CONFIG_SCSI_BFA_FC=y
> CONFIG_SCSI_DH=y
> # CONFIG_SCSI_DH_RDAC is not set
> # CONFIG_SCSI_DH_HP_SW is not set
> # CONFIG_SCSI_DH_EMC is not set
> # CONFIG_SCSI_DH_ALUA is not set
> CONFIG_SCSI_OSD_INITIATOR=y
> CONFIG_SCSI_OSD_ULD=y
> CONFIG_SCSI_OSD_DPRINT_SENSE=1
> # CONFIG_SCSI_OSD_DEBUG is not set
> # CONFIG_ATA is not set
> CONFIG_MD=y
> # CONFIG_BLK_DEV_MD is not set
> # CONFIG_BLK_DEV_DM is not set
> CONFIG_TARGET_CORE=y
> CONFIG_TCM_IBLOCK=y
> # CONFIG_TCM_FILEIO is not set
> CONFIG_TCM_PSCSI=y
> CONFIG_LOOPBACK_TARGET=y
> CONFIG_TCM_FC=y
> CONFIG_ISCSI_TARGET=y
> # CONFIG_FUSION is not set
> 
> #
> # IEEE 1394 (FireWire) support
> #
> CONFIG_FIREWIRE=y
> CONFIG_FIREWIRE_OHCI=y
> CONFIG_FIREWIRE_OHCI_DEBUG=y
> CONFIG_FIREWIRE_SBP2=y
> # CONFIG_FIREWIRE_NOSY is not set
> # CONFIG_I2O is not set
> CONFIG_MACINTOSH_DRIVERS=y
> # CONFIG_MAC_EMUMOUSEBTN is not set
> CONFIG_NETDEVICES=y
> CONFIG_NET_CORE=y
> # CONFIG_DUMMY is not set
> # CONFIG_EQUALIZER is not set
> # CONFIG_NET_FC is not set
> CONFIG_MII=y
> # CONFIG_NET_TEAM is not set
> CONFIG_MACVLAN=y
> CONFIG_MACVTAP=y
> # CONFIG_NETCONSOLE is not set
> # CONFIG_NETPOLL is not set
> # CONFIG_NET_POLL_CONTROLLER is not set
> # CONFIG_RIONET is not set
> CONFIG_TUN=y
> # CONFIG_VETH is not set
> CONFIG_VIRTIO_NET=y
> # CONFIG_ARCNET is not set
> # CONFIG_ATM_DRIVERS is not set
> 
> #
> # CAIF transport drivers
> #
> 
> #
> # Distributed Switch Architecture drivers
> #
> CONFIG_NET_DSA_MV88E6XXX=y
> CONFIG_NET_DSA_MV88E6060=y
> CONFIG_NET_DSA_MV88E6XXX_NEED_PPU=y
> CONFIG_NET_DSA_MV88E6131=y
> CONFIG_NET_DSA_MV88E6123_61_65=y
> CONFIG_ETHERNET=y
> CONFIG_MDIO=y
> # CONFIG_NET_VENDOR_3COM is not set
> # CONFIG_NET_VENDOR_ADAPTEC is not set
> # CONFIG_NET_VENDOR_ALTEON is not set
> CONFIG_NET_VENDOR_AMD=y
> # CONFIG_AMD8111_ETH is not set
> # CONFIG_PCNET32 is not set
> CONFIG_NET_VENDOR_ATHEROS=y
> # CONFIG_ATL2 is not set
> CONFIG_ATL1=y
> CONFIG_ATL1E=y
> # CONFIG_ATL1C is not set
> CONFIG_NET_VENDOR_BROADCOM=y
> # CONFIG_B44 is not set
> CONFIG_BNX2=y
> CONFIG_CNIC=y
> # CONFIG_TIGON3 is not set
> CONFIG_BNX2X=y
> # CONFIG_NET_VENDOR_BROCADE is not set
> CONFIG_NET_CALXEDA_XGMAC=y
> CONFIG_NET_VENDOR_CHELSIO=y
> # CONFIG_CHELSIO_T1 is not set
> # CONFIG_CHELSIO_T4 is not set
> # CONFIG_CHELSIO_T4VF is not set
> CONFIG_DNET=y
> CONFIG_NET_VENDOR_DEC=y
> CONFIG_NET_TULIP=y
> # CONFIG_DE2104X is not set
> CONFIG_TULIP=y
> # CONFIG_TULIP_MWI is not set
> CONFIG_TULIP_MMIO=y
> CONFIG_TULIP_NAPI=y
> # CONFIG_TULIP_NAPI_HW_MITIGATION is not set
> # CONFIG_DE4X5 is not set
> CONFIG_WINBOND_840=y
> CONFIG_DM9102=y
> CONFIG_ULI526X=y
> # CONFIG_PCMCIA_XIRCOM is not set
> # CONFIG_NET_VENDOR_DLINK is not set
> # CONFIG_NET_VENDOR_EXAR is not set
> CONFIG_NET_VENDOR_HP=y
> CONFIG_HP100=y
> # CONFIG_NET_VENDOR_INTEL is not set
> # CONFIG_IP1000 is not set
> CONFIG_JME=y
> CONFIG_NET_VENDOR_MARVELL=y
> # CONFIG_SKGE is not set
> # CONFIG_SKY2 is not set
> # CONFIG_NET_VENDOR_MICREL is not set
> # CONFIG_NET_VENDOR_MICROCHIP is not set
> # CONFIG_FEALNX is not set
> # CONFIG_NET_VENDOR_NATSEMI is not set
> # CONFIG_NET_VENDOR_NVIDIA is not set
> CONFIG_NET_VENDOR_OKI=y
> # CONFIG_PCH_GBE is not set
> CONFIG_ETHOC=y
> # CONFIG_NET_PACKET_ENGINE is not set
> # CONFIG_NET_VENDOR_QLOGIC is not set
> CONFIG_NET_VENDOR_REALTEK=y
> CONFIG_8139CP=y
> # CONFIG_8139TOO is not set
> # CONFIG_R8169 is not set
> # CONFIG_NET_VENDOR_RDC is not set
> CONFIG_NET_VENDOR_SEEQ=y
> CONFIG_SEEQ8005=y
> CONFIG_NET_VENDOR_SILAN=y
> # CONFIG_SC92031 is not set
> # CONFIG_NET_VENDOR_SIS is not set
> # CONFIG_NET_VENDOR_SMSC is not set
> CONFIG_NET_VENDOR_STMICRO=y
> CONFIG_STMMAC_ETH=y
> CONFIG_STMMAC_DEBUG_FS=y
> CONFIG_STMMAC_DA=y
> CONFIG_STMMAC_RING=y
> # CONFIG_STMMAC_CHAINED is not set
> CONFIG_NET_VENDOR_SUN=y
> CONFIG_HAPPYMEAL=y
> # CONFIG_SUNGEM is not set
> CONFIG_CASSINI=y
> # CONFIG_NIU is not set
> # CONFIG_NET_VENDOR_TEHUTI is not set
> CONFIG_NET_VENDOR_TI=y
> # CONFIG_TLAN is not set
> CONFIG_NET_VENDOR_VIA=y
> # CONFIG_VIA_RHINE is not set
> # CONFIG_VIA_VELOCITY is not set
> CONFIG_FDDI=y
> # CONFIG_DEFXX is not set
> CONFIG_SKFP=y
> CONFIG_NET_SB1000=y
> CONFIG_PHYLIB=y
> 
> #
> # MII PHY device drivers
> #
> # CONFIG_MARVELL_PHY is not set
> # CONFIG_DAVICOM_PHY is not set
> CONFIG_QSEMI_PHY=y
> CONFIG_LXT_PHY=y
> CONFIG_CICADA_PHY=y
> CONFIG_VITESSE_PHY=y
> # CONFIG_SMSC_PHY is not set
> CONFIG_BROADCOM_PHY=y
> CONFIG_ICPLUS_PHY=y
> CONFIG_REALTEK_PHY=y
> # CONFIG_NATIONAL_PHY is not set
> # CONFIG_STE10XP is not set
> CONFIG_LSI_ET1011C_PHY=y
> # CONFIG_MICREL_PHY is not set
> CONFIG_FIXED_PHY=y
> CONFIG_MDIO_BITBANG=y
> CONFIG_MDIO_GPIO=y
> CONFIG_MICREL_KS8995MA=y
> # CONFIG_PPP is not set
> CONFIG_SLIP=y
> # CONFIG_SLIP_COMPRESSED is not set
> CONFIG_SLIP_SMART=y
> CONFIG_SLIP_MODE_SLIP6=y
> CONFIG_TR=y
> # CONFIG_IBMOL is not set
> CONFIG_3C359=y
> # CONFIG_TMS380TR is not set
> CONFIG_WLAN=y
> # CONFIG_AIRO is not set
> # CONFIG_ATMEL is not set
> CONFIG_PRISM54=y
> # CONFIG_HOSTAP is not set
> 
> #
> # WiMAX Wireless Broadband devices
> #
> 
> #
> # Enable USB support to see WiMAX USB drivers
> #
> 
> #
> # Enable MMC support to see WiMAX SDIO drivers
> #
> CONFIG_WAN=y
> CONFIG_LANMEDIA=y
> CONFIG_HDLC=y
> CONFIG_HDLC_RAW=y
> # CONFIG_HDLC_RAW_ETH is not set
> # CONFIG_HDLC_CISCO is not set
> # CONFIG_HDLC_FR is not set
> CONFIG_HDLC_PPP=y
> 
> #
> # X.25/LAPB support is disabled
> #
> CONFIG_PCI200SYN=y
> # CONFIG_WANXL is not set
> CONFIG_PC300TOO=y
> CONFIG_FARSYNC=y
> CONFIG_DLCI=y
> CONFIG_DLCI_MAX=8
> # CONFIG_SBNI is not set
> # CONFIG_XEN_NETDEV_FRONTEND is not set
> CONFIG_XEN_NETDEV_BACKEND=y
> CONFIG_ISDN=y
> CONFIG_ISDN_I4L=y
> # CONFIG_ISDN_AUDIO is not set
> CONFIG_ISDN_X25=y
> 
> #
> # ISDN feature submodules
> #
> # CONFIG_ISDN_DRV_LOOP is not set
> # CONFIG_ISDN_DIVERSION is not set
> 
> #
> # ISDN4Linux hardware drivers
> #
> 
> #
> # Passive cards
> #
> # CONFIG_ISDN_DRV_HISAX is not set
> 
> #
> # Active cards
> #
> # CONFIG_ISDN_CAPI is not set
> CONFIG_ISDN_DRV_GIGASET=y
> CONFIG_GIGASET_I4L=y
> # CONFIG_GIGASET_DUMMYLL is not set
> CONFIG_GIGASET_M101=y
> # CONFIG_GIGASET_DEBUG is not set
> CONFIG_MISDN=y
> CONFIG_MISDN_DSP=y
> # CONFIG_MISDN_L1OIP is not set
> 
> #
> # mISDN hardware drivers
> #
> CONFIG_MISDN_HFCPCI=y
> # CONFIG_MISDN_HFCMULTI is not set
> CONFIG_MISDN_AVMFRITZ=y
> # CONFIG_MISDN_SPEEDFAX is not set
> # CONFIG_MISDN_INFINEON is not set
> CONFIG_MISDN_W6692=y
> CONFIG_MISDN_NETJET=y
> CONFIG_MISDN_IPAC=y
> CONFIG_ISDN_HDLC=y
> # CONFIG_PHONE is not set
> 
> #
> # Input device support
> #
> CONFIG_INPUT=y
> # CONFIG_INPUT_FF_MEMLESS is not set
> CONFIG_INPUT_POLLDEV=y
> CONFIG_INPUT_SPARSEKMAP=y
> 
> #
> # Userland interfaces
> #
> CONFIG_INPUT_MOUSEDEV=y
> CONFIG_INPUT_MOUSEDEV_PSAUX=y
> CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024
> CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768
> CONFIG_INPUT_JOYDEV=y
> # CONFIG_INPUT_EVDEV is not set
> CONFIG_INPUT_EVBUG=y
> 
> #
> # Input Device Drivers
> #
> CONFIG_INPUT_KEYBOARD=y
> # CONFIG_KEYBOARD_ADP5588 is not set
> CONFIG_KEYBOARD_ADP5589=y
> CONFIG_KEYBOARD_ATKBD=y
> CONFIG_KEYBOARD_QT1070=y
> # CONFIG_KEYBOARD_QT2160 is not set
> CONFIG_KEYBOARD_LKKBD=y
> # CONFIG_KEYBOARD_GPIO is not set
> # CONFIG_KEYBOARD_GPIO_POLLED is not set
> CONFIG_KEYBOARD_TCA6416=y
> # CONFIG_KEYBOARD_TCA8418 is not set
> CONFIG_KEYBOARD_MATRIX=y
> CONFIG_KEYBOARD_LM8323=y
> # CONFIG_KEYBOARD_MAX7359 is not set
> CONFIG_KEYBOARD_MCS=y
> CONFIG_KEYBOARD_MPR121=y
> CONFIG_KEYBOARD_NEWTON=y
> CONFIG_KEYBOARD_OPENCORES=y
> # CONFIG_KEYBOARD_STOWAWAY is not set
> CONFIG_KEYBOARD_SUNKBD=y
> # CONFIG_KEYBOARD_TC3589X is not set
> CONFIG_KEYBOARD_XTKBD=y
> CONFIG_INPUT_MOUSE=y
> CONFIG_MOUSE_PS2=y
> CONFIG_MOUSE_PS2_ALPS=y
> CONFIG_MOUSE_PS2_LOGIPS2PP=y
> CONFIG_MOUSE_PS2_SYNAPTICS=y
> CONFIG_MOUSE_PS2_LIFEBOOK=y
> CONFIG_MOUSE_PS2_TRACKPOINT=y
> CONFIG_MOUSE_PS2_ELANTECH=y
> # CONFIG_MOUSE_PS2_SENTELIC is not set
> # CONFIG_MOUSE_PS2_TOUCHKIT is not set
> CONFIG_MOUSE_SERIAL=y
> CONFIG_MOUSE_VSXXXAA=y
> # CONFIG_MOUSE_GPIO is not set
> CONFIG_MOUSE_SYNAPTICS_I2C=y
> # CONFIG_INPUT_JOYSTICK is not set
> CONFIG_INPUT_TABLET=y
> # CONFIG_INPUT_TOUCHSCREEN is not set
> CONFIG_INPUT_MISC=y
> CONFIG_INPUT_88PM860X_ONKEY=y
> # CONFIG_INPUT_AD714X is not set
> CONFIG_INPUT_BMA150=y
> # CONFIG_INPUT_PCSPKR is not set
> # CONFIG_INPUT_MMA8450 is not set
> CONFIG_INPUT_MPU3050=y
> # CONFIG_INPUT_APANEL is not set
> # CONFIG_INPUT_GP2A is not set
> CONFIG_INPUT_GPIO_TILT_POLLED=y
> CONFIG_INPUT_ATLAS_BTNS=y
> # CONFIG_INPUT_KXTJ9 is not set
> # CONFIG_INPUT_UINPUT is not set
> # CONFIG_INPUT_PCF8574 is not set
> CONFIG_INPUT_GPIO_ROTARY_ENCODER=y
> # CONFIG_INPUT_WM831X_ON is not set
> # CONFIG_INPUT_PCAP is not set
> CONFIG_INPUT_ADXL34X=y
> CONFIG_INPUT_ADXL34X_I2C=y
> CONFIG_INPUT_ADXL34X_SPI=y
> # CONFIG_INPUT_CMA3000 is not set
> 
> #
> # Hardware I/O ports
> #
> CONFIG_SERIO=y
> CONFIG_SERIO_I8042=y
> CONFIG_SERIO_SERPORT=y
> CONFIG_SERIO_CT82C710=y
> CONFIG_SERIO_PCIPS2=y
> CONFIG_SERIO_LIBPS2=y
> # CONFIG_SERIO_RAW is not set
> CONFIG_SERIO_ALTERA_PS2=y
> # CONFIG_SERIO_PS2MULT is not set
> CONFIG_GAMEPORT=y
> # CONFIG_GAMEPORT_NS558 is not set
> CONFIG_GAMEPORT_L4=y
> CONFIG_GAMEPORT_EMU10K1=y
> # CONFIG_GAMEPORT_FM801 is not set
> 
> #
> # Character devices
> #
> CONFIG_VT=y
> CONFIG_CONSOLE_TRANSLATIONS=y
> CONFIG_VT_CONSOLE=y
> CONFIG_VT_CONSOLE_SLEEP=y
> CONFIG_HW_CONSOLE=y
> # CONFIG_VT_HW_CONSOLE_BINDING is not set
> CONFIG_UNIX98_PTYS=y
> CONFIG_DEVPTS_MULTIPLE_INSTANCES=y
> CONFIG_LEGACY_PTYS=y
> CONFIG_LEGACY_PTY_COUNT=256
> CONFIG_SERIAL_NONSTANDARD=y
> # CONFIG_ROCKETPORT is not set
> # CONFIG_CYCLADES is not set
> CONFIG_MOXA_INTELLIO=y
> # CONFIG_MOXA_SMARTIO is not set
> CONFIG_SYNCLINK=y
> # CONFIG_SYNCLINKMP is not set
> # CONFIG_SYNCLINK_GT is not set
> CONFIG_NOZOMI=y
> # CONFIG_ISI is not set
> # CONFIG_N_HDLC is not set
> # CONFIG_N_GSM is not set
> # CONFIG_TRACE_ROUTER is not set
> CONFIG_TRACE_SINK=y
> # CONFIG_DEVKMEM is not set
> # CONFIG_STALDRV is not set
> 
> #
> # Serial drivers
> #
> CONFIG_SERIAL_8250=y
> # CONFIG_SERIAL_8250_CONSOLE is not set
> CONFIG_FIX_EARLYCON_MEM=y
> CONFIG_SERIAL_8250_PCI=y
> CONFIG_SERIAL_8250_PNP=y
> CONFIG_SERIAL_8250_NR_UARTS=4
> CONFIG_SERIAL_8250_RUNTIME_UARTS=4
> # CONFIG_SERIAL_8250_EXTENDED is not set
> 
> #
> # Non-8250 serial port support
> #
> CONFIG_SERIAL_MAX3100=y
> # CONFIG_SERIAL_MAX3107 is not set
> # CONFIG_SERIAL_MFD_HSU is not set
> # CONFIG_SERIAL_UARTLITE is not set
> CONFIG_SERIAL_CORE=y
> CONFIG_SERIAL_CORE_CONSOLE=y
> CONFIG_CONSOLE_POLL=y
> # CONFIG_SERIAL_JSM is not set
> CONFIG_SERIAL_TIMBERDALE=y
> # CONFIG_SERIAL_ALTERA_JTAGUART is not set
> CONFIG_SERIAL_ALTERA_UART=y
> CONFIG_SERIAL_ALTERA_UART_MAXPORTS=4
> CONFIG_SERIAL_ALTERA_UART_BAUDRATE=115200
> # CONFIG_SERIAL_ALTERA_UART_CONSOLE is not set
> CONFIG_SERIAL_IFX6X60=y
> CONFIG_SERIAL_PCH_UART=y
> # CONFIG_SERIAL_PCH_UART_CONSOLE is not set
> CONFIG_SERIAL_XILINX_PS_UART=y
> CONFIG_SERIAL_XILINX_PS_UART_CONSOLE=y
> CONFIG_HVC_DRIVER=y
> CONFIG_HVC_IRQ=y
> CONFIG_HVC_XEN=y
> # CONFIG_VIRTIO_CONSOLE is not set
> # CONFIG_IPMI_HANDLER is not set
> CONFIG_HW_RANDOM=y
> CONFIG_HW_RANDOM_TIMERIOMEM=y
> # CONFIG_HW_RANDOM_INTEL is not set
> CONFIG_HW_RANDOM_AMD=y
> # CONFIG_HW_RANDOM_VIA is not set
> # CONFIG_HW_RANDOM_VIRTIO is not set
> CONFIG_NVRAM=y
> CONFIG_R3964=y
> # CONFIG_APPLICOM is not set
> CONFIG_MWAVE=y
> # CONFIG_RAW_DRIVER is not set
> # CONFIG_HPET is not set
> # CONFIG_HANGCHECK_TIMER is not set
> # CONFIG_TCG_TPM is not set
> CONFIG_TELCLOCK=y
> CONFIG_DEVPORT=y
> CONFIG_RAMOOPS=y
> CONFIG_I2C=y
> CONFIG_I2C_BOARDINFO=y
> # CONFIG_I2C_COMPAT is not set
> # CONFIG_I2C_CHARDEV is not set
> # CONFIG_I2C_MUX is not set
> CONFIG_I2C_HELPER_AUTO=y
> CONFIG_I2C_SMBUS=y
> CONFIG_I2C_ALGOBIT=y
> 
> #
> # I2C Hardware Bus support
> #
> 
> #
> # PC SMBus host controller drivers
> #
> CONFIG_I2C_ALI1535=y
> # CONFIG_I2C_ALI1563 is not set
> CONFIG_I2C_ALI15X3=y
> CONFIG_I2C_AMD756=y
> # CONFIG_I2C_AMD756_S4882 is not set
> # CONFIG_I2C_AMD8111 is not set
> # CONFIG_I2C_I801 is not set
> # CONFIG_I2C_ISCH is not set
> # CONFIG_I2C_PIIX4 is not set
> CONFIG_I2C_NFORCE2=y
> # CONFIG_I2C_NFORCE2_S4985 is not set
> # CONFIG_I2C_SIS5595 is not set
> CONFIG_I2C_SIS630=y
> # CONFIG_I2C_SIS96X is not set
> CONFIG_I2C_VIA=y
> CONFIG_I2C_VIAPRO=y
> 
> #
> # ACPI drivers
> #
> CONFIG_I2C_SCMI=y
> 
> #
> # I2C system bus drivers (mostly embedded / system-on-chip)
> #
> # CONFIG_I2C_DESIGNWARE_PCI is not set
> CONFIG_I2C_GPIO=y
> CONFIG_I2C_INTEL_MID=y
> # CONFIG_I2C_OCORES is not set
> # CONFIG_I2C_PCA_PLATFORM is not set
> # CONFIG_I2C_PXA_PCI is not set
> # CONFIG_I2C_SIMTEC is not set
> CONFIG_I2C_XILINX=y
> # CONFIG_I2C_EG20T is not set
> 
> #
> # External I2C/SMBus adapter drivers
> #
> CONFIG_I2C_PARPORT_LIGHT=y
> CONFIG_I2C_TAOS_EVM=y
> 
> #
> # Other I2C/SMBus bus drivers
> #
> CONFIG_I2C_DEBUG_CORE=y
> # CONFIG_I2C_DEBUG_ALGO is not set
> CONFIG_I2C_DEBUG_BUS=y
> CONFIG_SPI=y
> CONFIG_SPI_DEBUG=y
> CONFIG_SPI_MASTER=y
> 
> #
> # SPI Master Controller Drivers
> #
> # CONFIG_SPI_ALTERA is not set
> CONFIG_SPI_BITBANG=y
> CONFIG_SPI_GPIO=y
> # CONFIG_SPI_OC_TINY is not set
> # CONFIG_SPI_PXA2XX_PCI is not set
> CONFIG_SPI_TOPCLIFF_PCH=y
> CONFIG_SPI_XILINX=y
> # CONFIG_SPI_DESIGNWARE is not set
> 
> #
> # SPI Protocol Masters
> #
> CONFIG_SPI_SPIDEV=y
> CONFIG_SPI_TLE62X0=y
> CONFIG_HSI=y
> CONFIG_HSI_BOARDINFO=y
> 
> #
> # HSI clients
> #
> # CONFIG_HSI_CHAR is not set
> 
> #
> # PPS support
> #
> CONFIG_PPS=y
> CONFIG_PPS_DEBUG=y
> 
> #
> # PPS clients support
> #
> CONFIG_PPS_CLIENT_KTIMER=y
> # CONFIG_PPS_CLIENT_LDISC is not set
> # CONFIG_PPS_CLIENT_GPIO is not set
> 
> #
> # PPS generators support
> #
> 
> #
> # PTP clock support
> #
> CONFIG_PTP_1588_CLOCK=y
> 
> #
> # Enable PHYLIB and NETWORK_PHY_TIMESTAMPING to see the additional clocks.
> #
> CONFIG_ARCH_WANT_OPTIONAL_GPIOLIB=y
> CONFIG_GPIOLIB=y
> CONFIG_DEBUG_GPIO=y
> CONFIG_GPIO_SYSFS=y
> CONFIG_GPIO_MAX730X=y
> 
> #
> # Memory mapped GPIO drivers:
> #
> # CONFIG_GPIO_GENERIC_PLATFORM is not set
> CONFIG_GPIO_IT8761E=y
> CONFIG_GPIO_SCH=y
> CONFIG_GPIO_VX855=y
> 
> #
> # I2C GPIO expanders:
> #
> CONFIG_GPIO_MAX7300=y
> CONFIG_GPIO_MAX732X=y
> # CONFIG_GPIO_MAX732X_IRQ is not set
> CONFIG_GPIO_PCA953X=y
> # CONFIG_GPIO_PCA953X_IRQ is not set
> # CONFIG_GPIO_PCF857X is not set
> # CONFIG_GPIO_SX150X is not set
> CONFIG_GPIO_TC3589X=y
> # CONFIG_GPIO_WM831X is not set
> CONFIG_GPIO_WM8350=y
> # CONFIG_GPIO_WM8994 is not set
> CONFIG_GPIO_ADP5588=y
> CONFIG_GPIO_ADP5588_IRQ=y
> 
> #
> # PCI GPIO expanders:
> #
> # CONFIG_GPIO_BT8XX is not set
> CONFIG_GPIO_LANGWELL=y
> CONFIG_GPIO_PCH=y
> CONFIG_GPIO_ML_IOH=y
> CONFIG_GPIO_TIMBERDALE=y
> CONFIG_GPIO_RDC321X=y
> 
> #
> # SPI GPIO expanders:
> #
> # CONFIG_GPIO_MAX7301 is not set
> # CONFIG_GPIO_MCP23S08 is not set
> CONFIG_GPIO_MC33880=y
> CONFIG_GPIO_74X164=y
> 
> #
> # AC97 GPIO expanders:
> #
> 
> #
> # MODULbus GPIO expanders:
> #
> CONFIG_GPIO_TPS65910=y
> # CONFIG_W1 is not set
> CONFIG_POWER_SUPPLY=y
> # CONFIG_POWER_SUPPLY_DEBUG is not set
> CONFIG_PDA_POWER=y
> # CONFIG_WM831X_BACKUP is not set
> CONFIG_WM831X_POWER=y
> # CONFIG_WM8350_POWER is not set
> CONFIG_TEST_POWER=y
> # CONFIG_BATTERY_DS2780 is not set
> CONFIG_BATTERY_DS2782=y
> CONFIG_BATTERY_BQ20Z75=y
> # CONFIG_BATTERY_BQ27x00 is not set
> CONFIG_BATTERY_MAX17040=y
> # CONFIG_BATTERY_MAX17042 is not set
> # CONFIG_CHARGER_MAX8903 is not set
> CONFIG_CHARGER_GPIO=y
> CONFIG_CHARGER_MAX8998=y
> CONFIG_HWMON=y
> CONFIG_HWMON_VID=y
> CONFIG_HWMON_DEBUG_CHIP=y
> 
> #
> # Native drivers
> #
> # CONFIG_SENSORS_ABITUGURU is not set
> # CONFIG_SENSORS_ABITUGURU3 is not set
> CONFIG_SENSORS_AD7314=y
> CONFIG_SENSORS_AD7414=y
> CONFIG_SENSORS_AD7418=y
> CONFIG_SENSORS_ADCXX=y
> # CONFIG_SENSORS_ADM1021 is not set
> # CONFIG_SENSORS_ADM1025 is not set
> CONFIG_SENSORS_ADM1026=y
> CONFIG_SENSORS_ADM1029=y
> CONFIG_SENSORS_ADM1031=y
> # CONFIG_SENSORS_ADM9240 is not set
> CONFIG_SENSORS_ADT7411=y
> CONFIG_SENSORS_ADT7462=y
> CONFIG_SENSORS_ADT7470=y
> CONFIG_SENSORS_ADT7475=y
> # CONFIG_SENSORS_ASC7621 is not set
> # CONFIG_SENSORS_K8TEMP is not set
> CONFIG_SENSORS_K10TEMP=y
> # CONFIG_SENSORS_FAM15H_POWER is not set
> CONFIG_SENSORS_ASB100=y
> # CONFIG_SENSORS_ATXP1 is not set
> CONFIG_SENSORS_DS620=y
> CONFIG_SENSORS_DS1621=y
> CONFIG_SENSORS_I5K_AMB=y
> CONFIG_SENSORS_F71805F=y
> # CONFIG_SENSORS_F71882FG is not set
> CONFIG_SENSORS_F75375S=y
> CONFIG_SENSORS_FSCHMD=y
> CONFIG_SENSORS_G760A=y
> # CONFIG_SENSORS_GL518SM is not set
> # CONFIG_SENSORS_GL520SM is not set
> CONFIG_SENSORS_GPIO_FAN=y
> CONFIG_SENSORS_CORETEMP=y
> CONFIG_SENSORS_IT87=y
> CONFIG_SENSORS_JC42=y
> CONFIG_SENSORS_LINEAGE=y
> # CONFIG_SENSORS_LM63 is not set
> # CONFIG_SENSORS_LM70 is not set
> CONFIG_SENSORS_LM73=y
> # CONFIG_SENSORS_LM75 is not set
> CONFIG_SENSORS_LM77=y
> CONFIG_SENSORS_LM78=y
> CONFIG_SENSORS_LM80=y
> # CONFIG_SENSORS_LM83 is not set
> CONFIG_SENSORS_LM85=y
> CONFIG_SENSORS_LM87=y
> # CONFIG_SENSORS_LM90 is not set
> # CONFIG_SENSORS_LM92 is not set
> CONFIG_SENSORS_LM93=y
> CONFIG_SENSORS_LTC4151=y
> # CONFIG_SENSORS_LTC4215 is not set
> CONFIG_SENSORS_LTC4245=y
> # CONFIG_SENSORS_LTC4261 is not set
> # CONFIG_SENSORS_LM95241 is not set
> # CONFIG_SENSORS_LM95245 is not set
> # CONFIG_SENSORS_MAX1111 is not set
> # CONFIG_SENSORS_MAX16065 is not set
> CONFIG_SENSORS_MAX1619=y
> CONFIG_SENSORS_MAX1668=y
> CONFIG_SENSORS_MAX6639=y
> CONFIG_SENSORS_MAX6642=y
> # CONFIG_SENSORS_MAX6650 is not set
> # CONFIG_SENSORS_NTC_THERMISTOR is not set
> CONFIG_SENSORS_PC87360=y
> # CONFIG_SENSORS_PC87427 is not set
> CONFIG_SENSORS_PCF8591=y
> CONFIG_PMBUS=y
> CONFIG_SENSORS_PMBUS=y
> # CONFIG_SENSORS_ADM1275 is not set
> # CONFIG_SENSORS_LM25066 is not set
> # CONFIG_SENSORS_LTC2978 is not set
> # CONFIG_SENSORS_MAX16064 is not set
> # CONFIG_SENSORS_MAX34440 is not set
> # CONFIG_SENSORS_MAX8688 is not set
> # CONFIG_SENSORS_UCD9000 is not set
> # CONFIG_SENSORS_UCD9200 is not set
> CONFIG_SENSORS_ZL6100=y
> # CONFIG_SENSORS_SHT15 is not set
> # CONFIG_SENSORS_SHT21 is not set
> CONFIG_SENSORS_SIS5595=y
> # CONFIG_SENSORS_SMM665 is not set
> CONFIG_SENSORS_DME1737=y
> # CONFIG_SENSORS_EMC1403 is not set
> # CONFIG_SENSORS_EMC2103 is not set
> # CONFIG_SENSORS_EMC6W201 is not set
> CONFIG_SENSORS_SMSC47M1=y
> CONFIG_SENSORS_SMSC47M192=y
> # CONFIG_SENSORS_SMSC47B397 is not set
> # CONFIG_SENSORS_SCH56XX_COMMON is not set
> # CONFIG_SENSORS_SCH5627 is not set
> # CONFIG_SENSORS_SCH5636 is not set
> # CONFIG_SENSORS_ADS1015 is not set
> # CONFIG_SENSORS_ADS7828 is not set
> CONFIG_SENSORS_ADS7871=y
> CONFIG_SENSORS_AMC6821=y
> # CONFIG_SENSORS_THMC50 is not set
> # CONFIG_SENSORS_TMP102 is not set
> # CONFIG_SENSORS_TMP401 is not set
> CONFIG_SENSORS_TMP421=y
> # CONFIG_SENSORS_VIA_CPUTEMP is not set
> CONFIG_SENSORS_VIA686A=y
> CONFIG_SENSORS_VT1211=y
> # CONFIG_SENSORS_VT8231 is not set
> CONFIG_SENSORS_W83781D=y
> # CONFIG_SENSORS_W83791D is not set
> # CONFIG_SENSORS_W83792D is not set
> CONFIG_SENSORS_W83793=y
> CONFIG_SENSORS_W83795=y
> CONFIG_SENSORS_W83795_FANCTRL=y
> CONFIG_SENSORS_W83L785TS=y
> CONFIG_SENSORS_W83L786NG=y
> CONFIG_SENSORS_W83627HF=y
> # CONFIG_SENSORS_W83627EHF is not set
> CONFIG_SENSORS_WM831X=y
> CONFIG_SENSORS_WM8350=y
> CONFIG_SENSORS_APPLESMC=y
> 
> #
> # ACPI drivers
> #
> # CONFIG_SENSORS_ACPI_POWER is not set
> CONFIG_SENSORS_ATK0110=y
> CONFIG_THERMAL=y
> CONFIG_THERMAL_HWMON=y
> # CONFIG_WATCHDOG is not set
> CONFIG_SSB_POSSIBLE=y
> 
> #
> # Sonics Silicon Backplane
> #
> # CONFIG_SSB is not set
> CONFIG_BCMA_POSSIBLE=y
> 
> #
> # Broadcom specific AMBA
> #
> # CONFIG_BCMA is not set
> 
> #
> # Multifunction device drivers
> #
> CONFIG_MFD_CORE=y
> CONFIG_MFD_88PM860X=y
> CONFIG_MFD_SM501=y
> # CONFIG_MFD_SM501_GPIO is not set
> CONFIG_HTC_PASIC3=y
> CONFIG_HTC_I2CPLD=y
> CONFIG_TPS6105X=y
> CONFIG_TPS65010=y
> # CONFIG_TPS6507X is not set
> CONFIG_MFD_TPS6586X=y
> CONFIG_MFD_TPS65910=y
> # CONFIG_MFD_TPS65912_I2C is not set
> # CONFIG_MFD_TPS65912_SPI is not set
> # CONFIG_TWL4030_CORE is not set
> # CONFIG_MFD_STMPE is not set
> CONFIG_MFD_TC3589X=y
> # CONFIG_MFD_TMIO is not set
> # CONFIG_PMIC_DA903X is not set
> CONFIG_PMIC_DA9052=y
> CONFIG_MFD_DA9052_SPI=y
> CONFIG_MFD_DA9052_I2C=y
> # CONFIG_PMIC_ADP5520 is not set
> # CONFIG_MFD_MAX8925 is not set
> # CONFIG_MFD_MAX8997 is not set
> CONFIG_MFD_MAX8998=y
> # CONFIG_MFD_WM8400 is not set
> CONFIG_MFD_WM831X=y
> CONFIG_MFD_WM831X_I2C=y
> CONFIG_MFD_WM831X_SPI=y
> CONFIG_MFD_WM8350=y
> CONFIG_MFD_WM8350_I2C=y
> CONFIG_MFD_WM8994=y
> # CONFIG_MFD_PCF50633 is not set
> # CONFIG_MFD_MC13XXX is not set
> # CONFIG_ABX500_CORE is not set
> CONFIG_EZX_PCAP=y
> # CONFIG_MFD_CS5535 is not set
> CONFIG_MFD_TIMBERDALE=y
> CONFIG_LPC_SCH=y
> CONFIG_MFD_RDC321X=y
> # CONFIG_MFD_JANZ_CMODIO is not set
> CONFIG_MFD_VX855=y
> CONFIG_MFD_WL1273_CORE=y
> # CONFIG_MFD_AAT2870_CORE is not set
> CONFIG_REGULATOR=y
> CONFIG_REGULATOR_DEBUG=y
> CONFIG_REGULATOR_DUMMY=y
> CONFIG_REGULATOR_FIXED_VOLTAGE=y
> CONFIG_REGULATOR_VIRTUAL_CONSUMER=y
> # CONFIG_REGULATOR_USERSPACE_CONSUMER is not set
> CONFIG_REGULATOR_GPIO=y
> CONFIG_REGULATOR_BQ24022=y
> # CONFIG_REGULATOR_MAX1586 is not set
> # CONFIG_REGULATOR_MAX8649 is not set
> # CONFIG_REGULATOR_MAX8660 is not set
> CONFIG_REGULATOR_MAX8952=y
> CONFIG_REGULATOR_MAX8998=y
> CONFIG_REGULATOR_WM831X=y
> CONFIG_REGULATOR_WM8350=y
> # CONFIG_REGULATOR_WM8994 is not set
> # CONFIG_REGULATOR_DA9052 is not set
> # CONFIG_REGULATOR_LP3971 is not set
> # CONFIG_REGULATOR_LP3972 is not set
> CONFIG_REGULATOR_PCAP=y
> # CONFIG_REGULATOR_TPS6105X is not set
> CONFIG_REGULATOR_TPS65023=y
> # CONFIG_REGULATOR_TPS6507X is not set
> # CONFIG_REGULATOR_88PM8607 is not set
> CONFIG_REGULATOR_ISL6271A=y
> CONFIG_REGULATOR_AD5398=y
> # CONFIG_REGULATOR_TPS6586X is not set
> CONFIG_REGULATOR_TPS6524X=y
> CONFIG_REGULATOR_TPS65910=y
> # CONFIG_MEDIA_SUPPORT is not set
> 
> #
> # Graphics support
> #
> CONFIG_AGP=y
> CONFIG_AGP_AMD64=y
> CONFIG_AGP_INTEL=y
> CONFIG_AGP_SIS=y
> CONFIG_AGP_VIA=y
> CONFIG_VGA_ARB=y
> CONFIG_VGA_ARB_MAX_GPUS=16
> CONFIG_VGA_SWITCHEROO=y
> CONFIG_DRM=y
> CONFIG_DRM_KMS_HELPER=y
> CONFIG_DRM_TTM=y
> CONFIG_DRM_TDFX=y
> # CONFIG_DRM_R128 is not set
> CONFIG_DRM_RADEON=y
> # CONFIG_DRM_RADEON_KMS is not set
> CONFIG_DRM_I915=y
> CONFIG_DRM_I915_KMS=y
> # CONFIG_DRM_MGA is not set
> # CONFIG_DRM_SIS is not set
> CONFIG_DRM_VIA=y
> CONFIG_DRM_SAVAGE=y
> # CONFIG_DRM_VMWGFX is not set
> # CONFIG_DRM_GMA500 is not set
> # CONFIG_STUB_POULSBO is not set
> CONFIG_VGASTATE=y
> CONFIG_VIDEO_OUTPUT_CONTROL=y
> CONFIG_FB=y
> # CONFIG_FIRMWARE_EDID is not set
> # CONFIG_FB_DDC is not set
> CONFIG_FB_BOOT_VESA_SUPPORT=y
> CONFIG_FB_CFB_FILLRECT=y
> CONFIG_FB_CFB_COPYAREA=y
> CONFIG_FB_CFB_IMAGEBLIT=y
> # CONFIG_FB_CFB_REV_PIXELS_IN_BYTE is not set
> CONFIG_FB_SYS_FILLRECT=y
> CONFIG_FB_SYS_COPYAREA=y
> CONFIG_FB_SYS_IMAGEBLIT=y
> # CONFIG_FB_FOREIGN_ENDIAN is not set
> CONFIG_FB_SYS_FOPS=y
> # CONFIG_FB_WMT_GE_ROPS is not set
> CONFIG_FB_DEFERRED_IO=y
> CONFIG_FB_SVGALIB=y
> # CONFIG_FB_MACMODES is not set
> # CONFIG_FB_BACKLIGHT is not set
> CONFIG_FB_MODE_HELPERS=y
> CONFIG_FB_TILEBLITTING=y
> 
> #
> # Frame buffer hardware drivers
> #
> CONFIG_FB_CIRRUS=y
> CONFIG_FB_PM2=y
> CONFIG_FB_PM2_FIFO_DISCONNECT=y
> # CONFIG_FB_CYBER2000 is not set
> # CONFIG_FB_ARC is not set
> CONFIG_FB_ASILIANT=y
> CONFIG_FB_IMSTT=y
> # CONFIG_FB_VGA16 is not set
> CONFIG_FB_UVESA=y
> CONFIG_FB_VESA=y
> # CONFIG_FB_EFI is not set
> # CONFIG_FB_N411 is not set
> CONFIG_FB_HGA=y
> # CONFIG_FB_S1D13XXX is not set
> # CONFIG_FB_NVIDIA is not set
> # CONFIG_FB_RIVA is not set
> CONFIG_FB_LE80578=y
> # CONFIG_FB_CARILLO_RANCH is not set
> # CONFIG_FB_MATROX is not set
> # CONFIG_FB_RADEON is not set
> # CONFIG_FB_ATY128 is not set
> CONFIG_FB_ATY=y
> # CONFIG_FB_ATY_CT is not set
> CONFIG_FB_ATY_GX=y
> # CONFIG_FB_ATY_BACKLIGHT is not set
> # CONFIG_FB_S3 is not set
> CONFIG_FB_SAVAGE=y
> # CONFIG_FB_SAVAGE_I2C is not set
> # CONFIG_FB_SAVAGE_ACCEL is not set
> CONFIG_FB_SIS=y
> CONFIG_FB_SIS_300=y
> # CONFIG_FB_SIS_315 is not set
> CONFIG_FB_VIA=y
> # CONFIG_FB_VIA_DIRECT_PROCFS is not set
> CONFIG_FB_VIA_X_COMPATIBILITY=y
> CONFIG_FB_NEOMAGIC=y
> # CONFIG_FB_KYRO is not set
> CONFIG_FB_3DFX=y
> # CONFIG_FB_3DFX_ACCEL is not set
> # CONFIG_FB_3DFX_I2C is not set
> CONFIG_FB_VOODOO1=y
> CONFIG_FB_VT8623=y
> CONFIG_FB_TRIDENT=y
> CONFIG_FB_ARK=y
> CONFIG_FB_PM3=y
> CONFIG_FB_CARMINE=y
> # CONFIG_FB_CARMINE_DRAM_EVAL is not set
> CONFIG_CARMINE_DRAM_CUSTOM=y
> # CONFIG_FB_GEODE is not set
> # CONFIG_FB_TMIO is not set
> # CONFIG_FB_SM501 is not set
> # CONFIG_FB_VIRTUAL is not set
> # CONFIG_XEN_FBDEV_FRONTEND is not set
> # CONFIG_FB_METRONOME is not set
> CONFIG_FB_MB862XX=y
> CONFIG_FB_MB862XX_PCI_GDC=y
> # CONFIG_FB_MB862XX_I2C is not set
> CONFIG_FB_BROADSHEET=y
> CONFIG_BACKLIGHT_LCD_SUPPORT=y
> # CONFIG_LCD_CLASS_DEVICE is not set
> CONFIG_BACKLIGHT_CLASS_DEVICE=y
> # CONFIG_BACKLIGHT_GENERIC is not set
> # CONFIG_BACKLIGHT_PROGEAR is not set
> # CONFIG_BACKLIGHT_APPLE is not set
> CONFIG_BACKLIGHT_SAHARA=y
> CONFIG_BACKLIGHT_WM831X=y
> CONFIG_BACKLIGHT_ADP8860=y
> CONFIG_BACKLIGHT_ADP8870=y
> # CONFIG_BACKLIGHT_88PM860X is not set
> 
> #
> # Console display driver support
> #
> CONFIG_VGA_CONSOLE=y
> CONFIG_VGACON_SOFT_SCROLLBACK=y
> CONFIG_VGACON_SOFT_SCROLLBACK_SIZE=64
> CONFIG_DUMMY_CONSOLE=y
> CONFIG_FRAMEBUFFER_CONSOLE=y
> CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY=y
> CONFIG_FRAMEBUFFER_CONSOLE_ROTATION=y
> # CONFIG_FONTS is not set
> CONFIG_FONT_8x8=y
> CONFIG_FONT_8x16=y
> CONFIG_LOGO=y
> CONFIG_LOGO_LINUX_MONO=y
> # CONFIG_LOGO_LINUX_VGA16 is not set
> CONFIG_LOGO_LINUX_CLUT224=y
> # CONFIG_SOUND is not set
> CONFIG_HID_SUPPORT=y
> # CONFIG_HID is not set
> CONFIG_HID_PID=y
> # CONFIG_USB_SUPPORT is not set
> CONFIG_UWB=y
> CONFIG_UWB_WHCI=y
> # CONFIG_MMC is not set
> CONFIG_MEMSTICK=y
> # CONFIG_MEMSTICK_DEBUG is not set
> 
> #
> # MemoryStick drivers
> #
> # CONFIG_MEMSTICK_UNSAFE_RESUME is not set
> # CONFIG_MSPRO_BLOCK is not set
> 
> #
> # MemoryStick Host Controller Drivers
> #
> # CONFIG_MEMSTICK_TIFM_MS is not set
> CONFIG_MEMSTICK_JMICRON_38X=y
> CONFIG_MEMSTICK_R592=y
> CONFIG_NEW_LEDS=y
> CONFIG_LEDS_CLASS=y
> 
> #
> # LED drivers
> #
> CONFIG_LEDS_88PM860X=y
> CONFIG_LEDS_LM3530=y
> CONFIG_LEDS_PCA9532=y
> CONFIG_LEDS_PCA9532_GPIO=y
> # CONFIG_LEDS_GPIO is not set
> # CONFIG_LEDS_LP3944 is not set
> # CONFIG_LEDS_LP5521 is not set
> CONFIG_LEDS_LP5523=y
> # CONFIG_LEDS_CLEVO_MAIL is not set
> # CONFIG_LEDS_PCA955X is not set
> CONFIG_LEDS_WM831X_STATUS=y
> CONFIG_LEDS_WM8350=y
> # CONFIG_LEDS_DAC124S085 is not set
> CONFIG_LEDS_REGULATOR=y
> CONFIG_LEDS_BD2802=y
> CONFIG_LEDS_INTEL_SS4200=y
> # CONFIG_LEDS_LT3593 is not set
> CONFIG_LEDS_TCA6507=y
> # CONFIG_LEDS_TRIGGERS is not set
> 
> #
> # LED Triggers
> #
> CONFIG_ACCESSIBILITY=y
> CONFIG_A11Y_BRAILLE_CONSOLE=y
> # CONFIG_INFINIBAND is not set
> # CONFIG_EDAC is not set
> CONFIG_RTC_LIB=y
> CONFIG_RTC_CLASS=y
> # CONFIG_RTC_HCTOSYS is not set
> CONFIG_RTC_DEBUG=y
> 
> #
> # RTC interfaces
> #
> CONFIG_RTC_INTF_SYSFS=y
> # CONFIG_RTC_INTF_PROC is not set
> # CONFIG_RTC_INTF_DEV is not set
> CONFIG_RTC_DRV_TEST=y
> 
> #
> # I2C RTC drivers
> #
> CONFIG_RTC_DRV_88PM860X=y
> CONFIG_RTC_DRV_DS1307=y
> CONFIG_RTC_DRV_DS1374=y
> # CONFIG_RTC_DRV_DS1672 is not set
> # CONFIG_RTC_DRV_DS3232 is not set
> CONFIG_RTC_DRV_MAX6900=y
> CONFIG_RTC_DRV_MAX8998=y
> # CONFIG_RTC_DRV_RS5C372 is not set
> CONFIG_RTC_DRV_ISL1208=y
> # CONFIG_RTC_DRV_ISL12022 is not set
> CONFIG_RTC_DRV_X1205=y
> CONFIG_RTC_DRV_PCF8563=y
> # CONFIG_RTC_DRV_PCF8583 is not set
> CONFIG_RTC_DRV_M41T80=y
> # CONFIG_RTC_DRV_M41T80_WDT is not set
> CONFIG_RTC_DRV_BQ32K=y
> CONFIG_RTC_DRV_S35390A=y
> # CONFIG_RTC_DRV_FM3130 is not set
> # CONFIG_RTC_DRV_RX8581 is not set
> # CONFIG_RTC_DRV_RX8025 is not set
> # CONFIG_RTC_DRV_EM3027 is not set
> # CONFIG_RTC_DRV_RV3029C2 is not set
> 
> #
> # SPI RTC drivers
> #
> # CONFIG_RTC_DRV_M41T93 is not set
> # CONFIG_RTC_DRV_M41T94 is not set
> # CONFIG_RTC_DRV_DS1305 is not set
> CONFIG_RTC_DRV_DS1390=y
> CONFIG_RTC_DRV_MAX6902=y
> # CONFIG_RTC_DRV_R9701 is not set
> # CONFIG_RTC_DRV_RS5C348 is not set
> CONFIG_RTC_DRV_DS3234=y
> CONFIG_RTC_DRV_PCF2123=y
> 
> #
> # Platform RTC drivers
> #
> CONFIG_RTC_DRV_CMOS=y
> # CONFIG_RTC_DRV_DS1286 is not set
> CONFIG_RTC_DRV_DS1511=y
> CONFIG_RTC_DRV_DS1553=y
> # CONFIG_RTC_DRV_DS1742 is not set
> CONFIG_RTC_DRV_STK17TA8=y
> CONFIG_RTC_DRV_M48T86=y
> CONFIG_RTC_DRV_M48T35=y
> CONFIG_RTC_DRV_M48T59=y
> # CONFIG_RTC_DRV_MSM6242 is not set
> # CONFIG_RTC_DRV_BQ4802 is not set
> CONFIG_RTC_DRV_RP5C01=y
> CONFIG_RTC_DRV_V3020=y
> CONFIG_RTC_DRV_WM831X=y
> # CONFIG_RTC_DRV_WM8350 is not set
> 
> #
> # on-CPU RTC drivers
> #
> CONFIG_RTC_DRV_PCAP=y
> CONFIG_DMADEVICES=y
> CONFIG_DMADEVICES_DEBUG=y
> # CONFIG_DMADEVICES_VDEBUG is not set
> 
> #
> # DMA Devices
> #
> # CONFIG_INTEL_MID_DMAC is not set
> # CONFIG_INTEL_IOATDMA is not set
> # CONFIG_TIMB_DMA is not set
> # CONFIG_PCH_DMA is not set
> # CONFIG_AUXDISPLAY is not set
> CONFIG_UIO=y
> # CONFIG_UIO_CIF is not set
> CONFIG_UIO_PDRV=y
> # CONFIG_UIO_PDRV_GENIRQ is not set
> CONFIG_UIO_AEC=y
> CONFIG_UIO_SERCOS3=y
> CONFIG_UIO_PCI_GENERIC=y
> CONFIG_UIO_NETX=y
> CONFIG_VIRTIO=y
> CONFIG_VIRTIO_RING=y
> 
> #
> # Virtio drivers
> #
> # CONFIG_VIRTIO_PCI is not set
> # CONFIG_VIRTIO_BALLOON is not set
> CONFIG_VIRTIO_MMIO=y
> 
> #
> # Microsoft Hyper-V guest support
> #
> # CONFIG_HYPERV is not set
> 
> #
> # Xen driver support
> #
> # CONFIG_XEN_BALLOON is not set
> # CONFIG_XEN_DEV_EVTCHN is not set
> CONFIG_XEN_BACKEND=y
> # CONFIG_XENFS is not set
> CONFIG_XEN_SYS_HYPERVISOR=y
> CONFIG_XEN_XENBUS_FRONTEND=y
> CONFIG_XEN_GNTDEV=y
> # CONFIG_XEN_GRANT_DEV_ALLOC is not set
> CONFIG_SWIOTLB_XEN=y
> CONFIG_XEN_TMEM=y
> # CONFIG_XEN_PCIDEV_BACKEND is not set
> CONFIG_XEN_PRIVCMD=y
> # CONFIG_STAGING is not set
> CONFIG_X86_PLATFORM_DEVICES=y
> # CONFIG_ACERHDF is not set
> CONFIG_DELL_LAPTOP=y
> # CONFIG_FUJITSU_LAPTOP is not set
> # CONFIG_HP_ACCEL is not set
> CONFIG_PANASONIC_LAPTOP=y
> # CONFIG_THINKPAD_ACPI is not set
> # CONFIG_SENSORS_HDAPS is not set
> CONFIG_EEEPC_LAPTOP=y
> # CONFIG_ACPI_WMI is not set
> CONFIG_ACPI_ASUS=y
> # CONFIG_TOPSTAR_LAPTOP is not set
> # CONFIG_ACPI_TOSHIBA is not set
> CONFIG_TOSHIBA_BT_RFKILL=y
> CONFIG_ACPI_CMPC=y
> # CONFIG_INTEL_IPS is not set
> CONFIG_IBM_RTL=y
> # CONFIG_XO15_EBOOK is not set
> CONFIG_SAMSUNG_Q10=y
> 
> #
> # Hardware Spinlock drivers
> #
> CONFIG_CLKEVT_I8253=y
> CONFIG_I8253_LOCK=y
> CONFIG_CLKBLD_I8253=y
> CONFIG_IOMMU_SUPPORT=y
> # CONFIG_AMD_IOMMU is not set
> CONFIG_VIRT_DRIVERS=y
> # CONFIG_PM_DEVFREQ is not set
> # CONFIG_XSHM is not set
> 
> #
> # Firmware Drivers
> #
> # CONFIG_EDD is not set
> CONFIG_FIRMWARE_MEMMAP=y
> CONFIG_EFI_VARS=y
> # CONFIG_DELL_RBU is not set
> CONFIG_DCDBAS=y
> # CONFIG_DMIID is not set
> # CONFIG_DMI_SYSFS is not set
> CONFIG_ISCSI_IBFT_FIND=y
> # CONFIG_ISCSI_IBFT is not set
> CONFIG_GOOGLE_FIRMWARE=y
> 
> #
> # Google Firmware Drivers
> #
> CONFIG_GOOGLE_SMI=y
> # CONFIG_GOOGLE_MEMCONSOLE is not set
> 
> #
> # File systems
> #
> CONFIG_EXT2_FS=y
> CONFIG_EXT2_FS_XATTR=y
> CONFIG_EXT2_FS_POSIX_ACL=y
> # CONFIG_EXT2_FS_SECURITY is not set
> CONFIG_EXT2_FS_XIP=y
> # CONFIG_EXT3_FS is not set
> # CONFIG_EXT4_FS is not set
> CONFIG_FS_XIP=y
> CONFIG_FS_MBCACHE=y
> # CONFIG_REISERFS_FS is not set
> # CONFIG_JFS_FS is not set
> CONFIG_XFS_FS=y
> CONFIG_XFS_QUOTA=y
> CONFIG_XFS_POSIX_ACL=y
> # CONFIG_XFS_RT is not set
> CONFIG_XFS_DEBUG=y
> # CONFIG_GFS2_FS is not set
> # CONFIG_OCFS2_FS is not set
> # CONFIG_BTRFS_FS is not set
> # CONFIG_NILFS2_FS is not set
> CONFIG_FS_POSIX_ACL=y
> CONFIG_EXPORTFS=y
> CONFIG_FILE_LOCKING=y
> CONFIG_FSNOTIFY=y
> CONFIG_DNOTIFY=y
> # CONFIG_INOTIFY_USER is not set
> # CONFIG_FANOTIFY is not set
> CONFIG_QUOTA=y
> # CONFIG_QUOTA_NETLINK_INTERFACE is not set
> # CONFIG_PRINT_QUOTA_WARNING is not set
> CONFIG_QUOTA_DEBUG=y
> CONFIG_QUOTA_TREE=y
> CONFIG_QFMT_V1=y
> CONFIG_QFMT_V2=y
> CONFIG_QUOTACTL=y
> CONFIG_QUOTACTL_COMPAT=y
> CONFIG_AUTOFS4_FS=y
> # CONFIG_FUSE_FS is not set
> 
> #
> # Caches
> #
> # CONFIG_FSCACHE is not set
> 
> #
> # CD-ROM/DVD Filesystems
> #
> CONFIG_ISO9660_FS=y
> CONFIG_JOLIET=y
> # CONFIG_ZISOFS is not set
> CONFIG_UDF_FS=y
> CONFIG_UDF_NLS=y
> 
> #
> # DOS/FAT/NT Filesystems
> #
> CONFIG_FAT_FS=y
> CONFIG_MSDOS_FS=y
> CONFIG_VFAT_FS=y
> CONFIG_FAT_DEFAULT_CODEPAGE=437
> CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1"
> CONFIG_NTFS_FS=y
> # CONFIG_NTFS_DEBUG is not set
> CONFIG_NTFS_RW=y
> 
> #
> # Pseudo filesystems
> #
> CONFIG_PROC_FS=y
> CONFIG_PROC_KCORE=y
> CONFIG_PROC_SYSCTL=y
> CONFIG_PROC_PAGE_MONITOR=y
> CONFIG_SYSFS=y
> CONFIG_TMPFS=y
> # CONFIG_TMPFS_POSIX_ACL is not set
> # CONFIG_TMPFS_XATTR is not set
> # CONFIG_HUGETLBFS is not set
> # CONFIG_HUGETLB_PAGE is not set
> CONFIG_CONFIGFS_FS=y
> CONFIG_MISC_FILESYSTEMS=y
> # CONFIG_ADFS_FS is not set
> CONFIG_AFFS_FS=y
> CONFIG_ECRYPT_FS=y
> CONFIG_HFS_FS=y
> # CONFIG_HFSPLUS_FS is not set
> # CONFIG_BEFS_FS is not set
> # CONFIG_BFS_FS is not set
> # CONFIG_EFS_FS is not set
> # CONFIG_JFFS2_FS is not set
> CONFIG_UBIFS_FS=y
> # CONFIG_UBIFS_FS_XATTR is not set
> # CONFIG_UBIFS_FS_ADVANCED_COMPR is not set
> CONFIG_UBIFS_FS_LZO=y
> CONFIG_UBIFS_FS_ZLIB=y
> CONFIG_UBIFS_FS_DEBUG=y
> # CONFIG_LOGFS is not set
> CONFIG_CRAMFS=y
> # CONFIG_SQUASHFS is not set
> # CONFIG_VXFS_FS is not set
> CONFIG_MINIX_FS=y
> # CONFIG_OMFS_FS is not set
> # CONFIG_HPFS_FS is not set
> CONFIG_QNX4FS_FS=y
> # CONFIG_ROMFS_FS is not set
> CONFIG_PSTORE=y
> # CONFIG_SYSV_FS is not set
> CONFIG_UFS_FS=y
> CONFIG_UFS_FS_WRITE=y
> CONFIG_UFS_DEBUG=y
> CONFIG_ORE=y
> CONFIG_EXOFS_FS=y
> CONFIG_EXOFS_DEBUG=y
> # CONFIG_NETWORK_FILESYSTEMS is not set
> 
> #
> # Partition Types
> #
> CONFIG_PARTITION_ADVANCED=y
> CONFIG_ACORN_PARTITION=y
> CONFIG_ACORN_PARTITION_CUMANA=y
> # CONFIG_ACORN_PARTITION_EESOX is not set
> # CONFIG_ACORN_PARTITION_ICS is not set
> CONFIG_ACORN_PARTITION_ADFS=y
> CONFIG_ACORN_PARTITION_POWERTEC=y
> # CONFIG_ACORN_PARTITION_RISCIX is not set
> CONFIG_OSF_PARTITION=y
> CONFIG_AMIGA_PARTITION=y
> CONFIG_ATARI_PARTITION=y
> CONFIG_MAC_PARTITION=y
> CONFIG_MSDOS_PARTITION=y
> # CONFIG_BSD_DISKLABEL is not set
> CONFIG_MINIX_SUBPARTITION=y
> # CONFIG_SOLARIS_X86_PARTITION is not set
> CONFIG_UNIXWARE_DISKLABEL=y
> # CONFIG_LDM_PARTITION is not set
> CONFIG_SGI_PARTITION=y
> # CONFIG_ULTRIX_PARTITION is not set
> # CONFIG_SUN_PARTITION is not set
> CONFIG_KARMA_PARTITION=y
> CONFIG_EFI_PARTITION=y
> # CONFIG_SYSV68_PARTITION is not set
> CONFIG_NLS=y
> CONFIG_NLS_DEFAULT="iso8859-1"
> # CONFIG_NLS_CODEPAGE_437 is not set
> CONFIG_NLS_CODEPAGE_737=y
> CONFIG_NLS_CODEPAGE_775=y
> # CONFIG_NLS_CODEPAGE_850 is not set
> # CONFIG_NLS_CODEPAGE_852 is not set
> # CONFIG_NLS_CODEPAGE_855 is not set
> CONFIG_NLS_CODEPAGE_857=y
> CONFIG_NLS_CODEPAGE_860=y
> CONFIG_NLS_CODEPAGE_861=y
> CONFIG_NLS_CODEPAGE_862=y
> # CONFIG_NLS_CODEPAGE_863 is not set
> # CONFIG_NLS_CODEPAGE_864 is not set
> # CONFIG_NLS_CODEPAGE_865 is not set
> CONFIG_NLS_CODEPAGE_866=y
> CONFIG_NLS_CODEPAGE_869=y
> # CONFIG_NLS_CODEPAGE_936 is not set
> # CONFIG_NLS_CODEPAGE_950 is not set
> # CONFIG_NLS_CODEPAGE_932 is not set
> # CONFIG_NLS_CODEPAGE_949 is not set
> # CONFIG_NLS_CODEPAGE_874 is not set
> CONFIG_NLS_ISO8859_8=y
> # CONFIG_NLS_CODEPAGE_1250 is not set
> CONFIG_NLS_CODEPAGE_1251=y
> # CONFIG_NLS_ASCII is not set
> # CONFIG_NLS_ISO8859_1 is not set
> CONFIG_NLS_ISO8859_2=y
> # CONFIG_NLS_ISO8859_3 is not set
> # CONFIG_NLS_ISO8859_4 is not set
> CONFIG_NLS_ISO8859_5=y
> CONFIG_NLS_ISO8859_6=y
> CONFIG_NLS_ISO8859_7=y
> # CONFIG_NLS_ISO8859_9 is not set
> # CONFIG_NLS_ISO8859_13 is not set
> # CONFIG_NLS_ISO8859_14 is not set
> CONFIG_NLS_ISO8859_15=y
> CONFIG_NLS_KOI8_R=y
> # CONFIG_NLS_KOI8_U is not set
> CONFIG_NLS_UTF8=y
> 
> #
> # Kernel hacking
> #
> CONFIG_TRACE_IRQFLAGS_SUPPORT=y
> CONFIG_PRINTK_TIME=y
> CONFIG_DEFAULT_MESSAGE_LOGLEVEL=4
> CONFIG_ENABLE_WARN_DEPRECATED=y
> CONFIG_ENABLE_MUST_CHECK=y
> CONFIG_FRAME_WARN=2048
> CONFIG_MAGIC_SYSRQ=y
> CONFIG_STRIP_ASM_SYMS=y
> CONFIG_UNUSED_SYMBOLS=y
> CONFIG_DEBUG_FS=y
> # CONFIG_HEADERS_CHECK is not set
> CONFIG_DEBUG_SECTION_MISMATCH=y
> CONFIG_DEBUG_KERNEL=y
> # CONFIG_DEBUG_SHIRQ is not set
> # CONFIG_LOCKUP_DETECTOR is not set
> # CONFIG_HARDLOCKUP_DETECTOR is not set
> CONFIG_DETECT_HUNG_TASK=y
> CONFIG_DEFAULT_HUNG_TASK_TIMEOUT=120
> # CONFIG_BOOTPARAM_HUNG_TASK_PANIC is not set
> CONFIG_BOOTPARAM_HUNG_TASK_PANIC_VALUE=0
> CONFIG_SCHED_DEBUG=y
> CONFIG_SCHEDSTATS=y
> # CONFIG_TIMER_STATS is not set
> CONFIG_DEBUG_OBJECTS=y
> CONFIG_DEBUG_OBJECTS_SELFTEST=y
> CONFIG_DEBUG_OBJECTS_FREE=y
> # CONFIG_DEBUG_OBJECTS_TIMERS is not set
> # CONFIG_DEBUG_OBJECTS_WORK is not set
> # CONFIG_DEBUG_OBJECTS_RCU_HEAD is not set
> # CONFIG_DEBUG_OBJECTS_PERCPU_COUNTER is not set
> CONFIG_DEBUG_OBJECTS_ENABLE_DEFAULT=1
> # CONFIG_SLUB_DEBUG_ON is not set
> # CONFIG_SLUB_STATS is not set
> # CONFIG_DEBUG_KMEMLEAK is not set
> CONFIG_DEBUG_PREEMPT=y
> CONFIG_DEBUG_RT_MUTEXES=y
> CONFIG_DEBUG_PI_LIST=y
> # CONFIG_RT_MUTEX_TESTER is not set
> CONFIG_DEBUG_SPINLOCK=y
> CONFIG_DEBUG_MUTEXES=y
> # CONFIG_DEBUG_LOCK_ALLOC is not set
> # CONFIG_PROVE_LOCKING is not set
> CONFIG_SPARSE_RCU_POINTER=y
> # CONFIG_LOCK_STAT is not set
> CONFIG_TRACE_IRQFLAGS=y
> # CONFIG_DEBUG_ATOMIC_SLEEP is not set
> CONFIG_DEBUG_LOCKING_API_SELFTESTS=y
> CONFIG_STACKTRACE=y
> # CONFIG_DEBUG_STACK_USAGE is not set
> CONFIG_DEBUG_KOBJECT=y
> CONFIG_DEBUG_BUGVERBOSE=y
> # CONFIG_DEBUG_INFO is not set
> # CONFIG_DEBUG_VM is not set
> # CONFIG_DEBUG_VIRTUAL is not set
> CONFIG_DEBUG_WRITECOUNT=y
> CONFIG_DEBUG_MEMORY_INIT=y
> CONFIG_DEBUG_LIST=y
> CONFIG_TEST_LIST_SORT=y
> CONFIG_DEBUG_SG=y
> # CONFIG_DEBUG_NOTIFIERS is not set
> # CONFIG_DEBUG_CREDENTIALS is not set
> CONFIG_ARCH_WANT_FRAME_POINTERS=y
> CONFIG_FRAME_POINTER=y
> # CONFIG_BOOT_PRINTK_DELAY is not set
> CONFIG_RCU_TORTURE_TEST=y
> # CONFIG_RCU_TORTURE_TEST_RUNNABLE is not set
> CONFIG_BACKTRACE_SELF_TEST=y
> # CONFIG_DEBUG_BLOCK_EXT_DEVT is not set
> # CONFIG_DEBUG_FORCE_WEAK_PER_CPU is not set
> CONFIG_LKDTM=y
> CONFIG_FAULT_INJECTION=y
> # CONFIG_FAILSLAB is not set
> # CONFIG_FAIL_PAGE_ALLOC is not set
> CONFIG_FAIL_MAKE_REQUEST=y
> CONFIG_FAIL_IO_TIMEOUT=y
> CONFIG_FAULT_INJECTION_DEBUG_FS=y
> # CONFIG_LATENCYTOP is not set
> # CONFIG_SYSCTL_SYSCALL_CHECK is not set
> # CONFIG_DEBUG_PAGEALLOC is not set
> CONFIG_USER_STACKTRACE_SUPPORT=y
> CONFIG_NOP_TRACER=y
> CONFIG_HAVE_FTRACE_NMI_ENTER=y
> CONFIG_HAVE_FUNCTION_TRACER=y
> CONFIG_HAVE_FUNCTION_GRAPH_TRACER=y
> CONFIG_HAVE_FUNCTION_GRAPH_FP_TEST=y
> CONFIG_HAVE_FUNCTION_TRACE_MCOUNT_TEST=y
> CONFIG_HAVE_DYNAMIC_FTRACE=y
> CONFIG_HAVE_FTRACE_MCOUNT_RECORD=y
> CONFIG_HAVE_SYSCALL_TRACEPOINTS=y
> CONFIG_HAVE_C_RECORDMCOUNT=y
> CONFIG_TRACER_MAX_TRACE=y
> CONFIG_RING_BUFFER=y
> CONFIG_FTRACE_NMI_ENTER=y
> CONFIG_EVENT_TRACING=y
> CONFIG_EVENT_POWER_TRACING_DEPRECATED=y
> CONFIG_CONTEXT_SWITCH_TRACER=y
> CONFIG_RING_BUFFER_ALLOW_SWAP=y
> CONFIG_TRACING=y
> CONFIG_GENERIC_TRACER=y
> CONFIG_TRACING_SUPPORT=y
> CONFIG_FTRACE=y
> CONFIG_FUNCTION_TRACER=y
> # CONFIG_FUNCTION_GRAPH_TRACER is not set
> CONFIG_IRQSOFF_TRACER=y
> CONFIG_PREEMPT_TRACER=y
> CONFIG_SCHED_TRACER=y
> # CONFIG_FTRACE_SYSCALLS is not set
> CONFIG_BRANCH_PROFILE_NONE=y
> # CONFIG_PROFILE_ANNOTATED_BRANCHES is not set
> # CONFIG_PROFILE_ALL_BRANCHES is not set
> # CONFIG_STACK_TRACER is not set
> # CONFIG_BLK_DEV_IO_TRACE is not set
> CONFIG_UPROBE_EVENT=y
> CONFIG_PROBE_EVENTS=y
> CONFIG_DYNAMIC_FTRACE=y
> CONFIG_FUNCTION_PROFILER=y
> CONFIG_FTRACE_MCOUNT_RECORD=y
> # CONFIG_FTRACE_STARTUP_TEST is not set
> # CONFIG_MMIOTRACE is not set
> # CONFIG_RING_BUFFER_BENCHMARK is not set
> CONFIG_PROVIDE_OHCI1394_DMA_INIT=y
> # CONFIG_FIREWIRE_OHCI_REMOTE_DMA is not set
> CONFIG_DYNAMIC_DEBUG=y
> CONFIG_DMA_API_DEBUG=y
> CONFIG_ATOMIC64_SELFTEST=y
> CONFIG_SAMPLES=y
> CONFIG_HAVE_ARCH_KGDB=y
> CONFIG_KGDB=y
> CONFIG_KGDB_SERIAL_CONSOLE=y
> # CONFIG_KGDB_TESTS is not set
> # CONFIG_KGDB_LOW_LEVEL_TRAP is not set
> # CONFIG_KGDB_KDB is not set
> CONFIG_HAVE_ARCH_KMEMCHECK=y
> CONFIG_TEST_KSTRTOX=y
> # CONFIG_STRICT_DEVMEM is not set
> CONFIG_X86_VERBOSE_BOOTUP=y
> CONFIG_EARLY_PRINTK=y
> # CONFIG_EARLY_PRINTK_DBGP is not set
> CONFIG_DEBUG_STACKOVERFLOW=y
> CONFIG_X86_PTDUMP=y
> CONFIG_DEBUG_RODATA=y
> CONFIG_DEBUG_RODATA_TEST=y
> CONFIG_IOMMU_DEBUG=y
> # CONFIG_IOMMU_STRESS is not set
> CONFIG_IOMMU_LEAK=y
> CONFIG_HAVE_MMIOTRACE_SUPPORT=y
> CONFIG_IO_DELAY_TYPE_0X80=0
> CONFIG_IO_DELAY_TYPE_0XED=1
> CONFIG_IO_DELAY_TYPE_UDELAY=2
> CONFIG_IO_DELAY_TYPE_NONE=3
> # CONFIG_IO_DELAY_0X80 is not set
> # CONFIG_IO_DELAY_0XED is not set
> # CONFIG_IO_DELAY_UDELAY is not set
> CONFIG_IO_DELAY_NONE=y
> CONFIG_DEFAULT_IO_DELAY_TYPE=3
> CONFIG_DEBUG_BOOT_PARAMS=y
> CONFIG_CPA_DEBUG=y
> CONFIG_OPTIMIZE_INLINING=y
> # CONFIG_DEBUG_STRICT_USER_COPY_CHECKS is not set
> CONFIG_DEBUG_NMI_SELFTEST=y
> 
> #
> # Security options
> #
> CONFIG_KEYS=y
> CONFIG_ENCRYPTED_KEYS=y
> # CONFIG_KEYS_DEBUG_PROC_KEYS is not set
> # CONFIG_SECURITY_DMESG_RESTRICT is not set
> # CONFIG_SECURITY is not set
> CONFIG_SECURITYFS=y
> CONFIG_DEFAULT_SECURITY_DAC=y
> CONFIG_DEFAULT_SECURITY=""
> CONFIG_XOR_BLOCKS=y
> CONFIG_ASYNC_CORE=y
> CONFIG_ASYNC_XOR=y
> CONFIG_CRYPTO=y
> 
> #
> # Crypto core or helper
> #
> # CONFIG_CRYPTO_FIPS is not set
> CONFIG_CRYPTO_ALGAPI=y
> CONFIG_CRYPTO_ALGAPI2=y
> CONFIG_CRYPTO_AEAD=y
> CONFIG_CRYPTO_AEAD2=y
> CONFIG_CRYPTO_BLKCIPHER=y
> CONFIG_CRYPTO_BLKCIPHER2=y
> CONFIG_CRYPTO_HASH=y
> CONFIG_CRYPTO_HASH2=y
> CONFIG_CRYPTO_RNG=y
> CONFIG_CRYPTO_RNG2=y
> CONFIG_CRYPTO_PCOMP2=y
> CONFIG_CRYPTO_MANAGER=y
> CONFIG_CRYPTO_MANAGER2=y
> # CONFIG_CRYPTO_USER is not set
> # CONFIG_CRYPTO_MANAGER_DISABLE_TESTS is not set
> CONFIG_CRYPTO_GF128MUL=y
> CONFIG_CRYPTO_NULL=y
> CONFIG_CRYPTO_WORKQUEUE=y
> CONFIG_CRYPTO_CRYPTD=y
> CONFIG_CRYPTO_AUTHENC=y
> 
> #
> # Authenticated Encryption with Associated Data
> #
> # CONFIG_CRYPTO_CCM is not set
> # CONFIG_CRYPTO_GCM is not set
> CONFIG_CRYPTO_SEQIV=y
> 
> #
> # Block modes
> #
> CONFIG_CRYPTO_CBC=y
> # CONFIG_CRYPTO_CTR is not set
> # CONFIG_CRYPTO_CTS is not set
> CONFIG_CRYPTO_ECB=y
> CONFIG_CRYPTO_LRW=y
> CONFIG_CRYPTO_PCBC=y
> CONFIG_CRYPTO_XTS=y
> 
> #
> # Hash modes
> #
> CONFIG_CRYPTO_HMAC=y
> CONFIG_CRYPTO_XCBC=y
> CONFIG_CRYPTO_VMAC=y
> 
> #
> # Digest
> #
> CONFIG_CRYPTO_CRC32C=y
> CONFIG_CRYPTO_CRC32C_INTEL=y
> CONFIG_CRYPTO_GHASH=y
> # CONFIG_CRYPTO_MD4 is not set
> CONFIG_CRYPTO_MD5=y
> # CONFIG_CRYPTO_MICHAEL_MIC is not set
> CONFIG_CRYPTO_RMD128=y
> CONFIG_CRYPTO_RMD160=y
> CONFIG_CRYPTO_RMD256=y
> # CONFIG_CRYPTO_RMD320 is not set
> CONFIG_CRYPTO_SHA1=y
> # CONFIG_CRYPTO_SHA1_SSSE3 is not set
> CONFIG_CRYPTO_SHA256=y
> CONFIG_CRYPTO_SHA512=y
> CONFIG_CRYPTO_TGR192=y
> CONFIG_CRYPTO_WP512=y
> # CONFIG_CRYPTO_GHASH_CLMUL_NI_INTEL is not set
> 
> #
> # Ciphers
> #
> CONFIG_CRYPTO_AES=y
> CONFIG_CRYPTO_AES_X86_64=y
> # CONFIG_CRYPTO_AES_NI_INTEL is not set
> CONFIG_CRYPTO_ANUBIS=y
> # CONFIG_CRYPTO_ARC4 is not set
> CONFIG_CRYPTO_BLOWFISH=y
> CONFIG_CRYPTO_BLOWFISH_COMMON=y
> CONFIG_CRYPTO_BLOWFISH_X86_64=y
> CONFIG_CRYPTO_CAMELLIA=y
> # CONFIG_CRYPTO_CAST5 is not set
> CONFIG_CRYPTO_CAST6=y
> CONFIG_CRYPTO_DES=y
> CONFIG_CRYPTO_FCRYPT=y
> # CONFIG_CRYPTO_KHAZAD is not set
> # CONFIG_CRYPTO_SALSA20 is not set
> # CONFIG_CRYPTO_SALSA20_X86_64 is not set
> # CONFIG_CRYPTO_SEED is not set
> CONFIG_CRYPTO_SERPENT=y
> CONFIG_CRYPTO_SERPENT_SSE2_X86_64=y
> CONFIG_CRYPTO_TEA=y
> # CONFIG_CRYPTO_TWOFISH is not set
> CONFIG_CRYPTO_TWOFISH_COMMON=y
> CONFIG_CRYPTO_TWOFISH_X86_64=y
> # CONFIG_CRYPTO_TWOFISH_X86_64_3WAY is not set
> 
> #
> # Compression
> #
> CONFIG_CRYPTO_DEFLATE=y
> # CONFIG_CRYPTO_ZLIB is not set
> CONFIG_CRYPTO_LZO=y
> 
> #
> # Random Number Generation
> #
> CONFIG_CRYPTO_ANSI_CPRNG=y
> CONFIG_CRYPTO_USER_API=y
> CONFIG_CRYPTO_USER_API_HASH=y
> CONFIG_CRYPTO_USER_API_SKCIPHER=y
> CONFIG_CRYPTO_HW=y
> CONFIG_CRYPTO_DEV_PADLOCK=y
> # CONFIG_CRYPTO_DEV_PADLOCK_AES is not set
> # CONFIG_CRYPTO_DEV_PADLOCK_SHA is not set
> CONFIG_HAVE_KVM=y
> CONFIG_HAVE_KVM_IRQCHIP=y
> CONFIG_HAVE_KVM_EVENTFD=y
> CONFIG_KVM_APIC_ARCHITECTURE=y
> CONFIG_KVM_MMIO=y
> CONFIG_KVM_ASYNC_PF=y
> CONFIG_VIRTUALIZATION=y
> CONFIG_KVM=y
> CONFIG_KVM_INTEL=y
> # CONFIG_KVM_AMD is not set
> # CONFIG_KVM_MMU_AUDIT is not set
> CONFIG_VHOST_NET=y
> CONFIG_BINARY_PRINTF=y
> 
> #
> # Library routines
> #
> CONFIG_BITREVERSE=y
> CONFIG_GENERIC_FIND_FIRST_BIT=y
> CONFIG_GENERIC_PCI_IOMAP=y
> CONFIG_GENERIC_IOMAP=y
> CONFIG_CRC_CCITT=y
> CONFIG_CRC16=y
> CONFIG_CRC_T10DIF=y
> CONFIG_CRC_ITU_T=y
> CONFIG_CRC32=y
> CONFIG_CRC7=y
> CONFIG_LIBCRC32C=y
> CONFIG_CRC8=y
> CONFIG_ZLIB_INFLATE=y
> CONFIG_ZLIB_DEFLATE=y
> CONFIG_LZO_COMPRESS=y
> CONFIG_LZO_DECOMPRESS=y
> CONFIG_XZ_DEC=y
> CONFIG_XZ_DEC_X86=y
> CONFIG_XZ_DEC_POWERPC=y
> CONFIG_XZ_DEC_IA64=y
> CONFIG_XZ_DEC_ARM=y
> CONFIG_XZ_DEC_ARMTHUMB=y
> CONFIG_XZ_DEC_SPARC=y
> CONFIG_XZ_DEC_BCJ=y
> # CONFIG_XZ_DEC_TEST is not set
> CONFIG_DECOMPRESS_GZIP=y
> CONFIG_DECOMPRESS_BZIP2=y
> CONFIG_DECOMPRESS_LZMA=y
> CONFIG_DECOMPRESS_XZ=y
> CONFIG_DECOMPRESS_LZO=y
> CONFIG_BCH=y
> CONFIG_BCH_CONST_PARAMS=y
> CONFIG_TEXTSEARCH=y
> CONFIG_TEXTSEARCH_KMP=y
> CONFIG_TEXTSEARCH_BM=y
> CONFIG_TEXTSEARCH_FSM=y
> CONFIG_HAS_IOMEM=y
> CONFIG_HAS_IOPORT=y
> CONFIG_HAS_DMA=y
> CONFIG_CHECK_SIGNATURE=y
> CONFIG_DQL=y
> CONFIG_NLATTR=y
> CONFIG_AVERAGE=y
> # CONFIG_CORDIC is not set
> CONFIG_MPILIB=y
> CONFIG_MPILIB_EXTRA=y
> # CONFIG_DIGSIG is not set


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 21 19:32:19 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 19:32:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdRtC-0005Py-8X; Wed, 21 Dec 2011 19:31:46 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RdRtB-0005Pt-6H
	for xen-devel@lists.xensource.com; Wed, 21 Dec 2011 19:31:45 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1324495897!7909588!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDU0NTUw\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12911 invoked from network); 21 Dec 2011 19:31:38 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-3.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Dec 2011 19:31:38 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pBLJVOqx020427
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 21 Dec 2011 19:31:24 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pBLJVMwe003822
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 21 Dec 2011 19:31:23 GMT
Received: from abhmt114.oracle.com (abhmt114.oracle.com [141.146.116.66])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pBLJVMdw022430; Wed, 21 Dec 2011 13:31:22 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 21 Dec 2011 11:31:22 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id D24AA416F3; Wed, 21 Dec 2011 14:30:21 -0500 (EST)
Date: Wed, 21 Dec 2011 14:30:21 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Randy Dunlap <rdunlap@xenotime.net>
Message-ID: <20111221193021.GA19671@phenom.dumpdata.com>
References: <20111221174733.9ba0861e762e8d96844b060b@canb.auug.org.au>
	<4EF23D67.9050602@xenotime.net>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4EF23D67.9050602@xenotime.net>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090205.4EF23410.0033,ss=1,re=-6.500,fgs=0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stephen Rothwell <sfr@canb.auug.org.au>,
	linux-next@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>
Subject: Re: [Xen-devel] linux-next: Tree for Dec 21 (xen)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Dec 21, 2011 at 12:11:19PM -0800, Randy Dunlap wrote:
> On 12/20/2011 10:47 PM, Stephen Rothwell wrote:
> > Hi all,
> > 
> > Changes since 20111220:
> 
> 
> drivers/xen/xenbus/xenbus_dev_backend.c:74:2: error: implicit declaration of function 'xen_initial_domain'

Fixed. But I am still not sure what CONFIG_* + header magic is 
is triggering this.

Last time I thought it was the combination of !PCI, !ACPI, and
CONFIG_XEN_XENBUS=m (and the other xen drivers turned to m as well).

But that is not the case here.

Thanks for reporting. Will disect this some more.
> 
> Full randconfig file is attached.
> 
> -- 
> ~Randy
> *** Remember to use Documentation/SubmitChecklist when testing your code ***

> #
> # Automatically generated file; DO NOT EDIT.
> # Linux/x86_64 3.2.0-rc6 Kernel Configuration
> #
> CONFIG_64BIT=y
> # CONFIG_X86_32 is not set
> CONFIG_X86_64=y
> CONFIG_X86=y
> CONFIG_INSTRUCTION_DECODER=y
> CONFIG_OUTPUT_FORMAT="elf64-x86-64"
> CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig"
> CONFIG_GENERIC_CMOS_UPDATE=y
> CONFIG_CLOCKSOURCE_WATCHDOG=y
> CONFIG_GENERIC_CLOCKEVENTS=y
> CONFIG_ARCH_CLOCKSOURCE_DATA=y
> CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
> CONFIG_LOCKDEP_SUPPORT=y
> CONFIG_STACKTRACE_SUPPORT=y
> CONFIG_HAVE_LATENCYTOP_SUPPORT=y
> CONFIG_MMU=y
> CONFIG_ZONE_DMA=y
> CONFIG_NEED_DMA_MAP_STATE=y
> CONFIG_NEED_SG_DMA_LENGTH=y
> CONFIG_GENERIC_ISA_DMA=y
> CONFIG_GENERIC_BUG=y
> CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y
> CONFIG_GENERIC_HWEIGHT=y
> CONFIG_GENERIC_GPIO=y
> CONFIG_ARCH_MAY_HAVE_PC_FDC=y
> # CONFIG_RWSEM_GENERIC_SPINLOCK is not set
> CONFIG_RWSEM_XCHGADD_ALGORITHM=y
> CONFIG_ARCH_HAS_CPU_IDLE_WAIT=y
> CONFIG_GENERIC_CALIBRATE_DELAY=y
> CONFIG_GENERIC_TIME_VSYSCALL=y
> CONFIG_ARCH_HAS_CPU_RELAX=y
> CONFIG_ARCH_HAS_DEFAULT_IDLE=y
> CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
> CONFIG_HAVE_SETUP_PER_CPU_AREA=y
> CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
> CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
> CONFIG_ARCH_HIBERNATION_POSSIBLE=y
> CONFIG_ARCH_SUSPEND_POSSIBLE=y
> CONFIG_ZONE_DMA32=y
> CONFIG_AUDIT_ARCH=y
> CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
> CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
> CONFIG_ARCH_HWEIGHT_CFLAGS="-fcall-saved-rdi -fcall-saved-rsi -fcall-saved-rdx -fcall-saved-rcx -fcall-saved-r8 -fcall-saved-r9 -fcall-saved-r10 -fcall-saved-r11"
> # CONFIG_KTIME_SCALAR is not set
> CONFIG_ARCH_SUPPORTS_UPROBES=y
> CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
> CONFIG_CONSTRUCTORS=y
> CONFIG_HAVE_IRQ_WORK=y
> CONFIG_IRQ_WORK=y
> 
> #
> # General setup
> #
> CONFIG_EXPERIMENTAL=y
> CONFIG_BROKEN_ON_SMP=y
> CONFIG_INIT_ENV_ARG_LIMIT=32
> CONFIG_CROSS_COMPILE=""
> CONFIG_LOCALVERSION=""
> # CONFIG_LOCALVERSION_AUTO is not set
> CONFIG_HAVE_KERNEL_GZIP=y
> CONFIG_HAVE_KERNEL_BZIP2=y
> CONFIG_HAVE_KERNEL_LZMA=y
> CONFIG_HAVE_KERNEL_XZ=y
> CONFIG_HAVE_KERNEL_LZO=y
> # CONFIG_KERNEL_GZIP is not set
> # CONFIG_KERNEL_BZIP2 is not set
> CONFIG_KERNEL_LZMA=y
> # CONFIG_KERNEL_XZ is not set
> # CONFIG_KERNEL_LZO is not set
> CONFIG_DEFAULT_HOSTNAME="(none)"
> CONFIG_SWAP=y
> CONFIG_SYSVIPC=y
> CONFIG_SYSVIPC_SYSCTL=y
> CONFIG_POSIX_MQUEUE=y
> CONFIG_POSIX_MQUEUE_SYSCTL=y
> # CONFIG_BSD_PROCESS_ACCT is not set
> CONFIG_FHANDLE=y
> CONFIG_TASKSTATS=y
> CONFIG_TASK_DELAY_ACCT=y
> CONFIG_TASK_XACCT=y
> CONFIG_TASK_IO_ACCOUNTING=y
> # CONFIG_AUDIT is not set
> CONFIG_HAVE_GENERIC_HARDIRQS=y
> 
> #
> # IRQ subsystem
> #
> CONFIG_GENERIC_HARDIRQS=y
> CONFIG_HAVE_SPARSE_IRQ=y
> CONFIG_GENERIC_IRQ_PROBE=y
> CONFIG_GENERIC_IRQ_SHOW=y
> CONFIG_GENERIC_IRQ_CHIP=y
> CONFIG_IRQ_FORCED_THREADING=y
> CONFIG_SPARSE_IRQ=y
> 
> #
> # RCU Subsystem
> #
> CONFIG_TINY_PREEMPT_RCU=y
> CONFIG_PREEMPT_RCU=y
> CONFIG_RCU_TRACE=y
> # CONFIG_TREE_RCU_TRACE is not set
> # CONFIG_RCU_BOOST is not set
> # CONFIG_IKCONFIG is not set
> CONFIG_LOG_BUF_SHIFT=17
> CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y
> CONFIG_CGROUPS=y
> # CONFIG_CGROUP_DEBUG is not set
> CONFIG_CGROUP_FREEZER=y
> # CONFIG_CGROUP_DEVICE is not set
> CONFIG_CPUSETS=y
> # CONFIG_PROC_PID_CPUSET is not set
> # CONFIG_CGROUP_CPUACCT is not set
> CONFIG_RESOURCE_COUNTERS=y
> # CONFIG_CGROUP_MEM_RES_CTLR is not set
> CONFIG_CGROUP_PERF=y
> # CONFIG_CGROUP_SCHED is not set
> CONFIG_BLK_CGROUP=y
> # CONFIG_DEBUG_BLK_CGROUP is not set
> # CONFIG_CHECKPOINT_RESTORE is not set
> CONFIG_NAMESPACES=y
> # CONFIG_UTS_NS is not set
> CONFIG_IPC_NS=y
> # CONFIG_USER_NS is not set
> # CONFIG_PID_NS is not set
> CONFIG_NET_NS=y
> # CONFIG_SCHED_AUTOGROUP is not set
> # CONFIG_SYSFS_DEPRECATED is not set
> CONFIG_RELAY=y
> CONFIG_BLK_DEV_INITRD=y
> CONFIG_INITRAMFS_SOURCE=""
> CONFIG_RD_GZIP=y
> CONFIG_RD_BZIP2=y
> CONFIG_RD_LZMA=y
> CONFIG_RD_XZ=y
> CONFIG_RD_LZO=y
> # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
> CONFIG_SYSCTL=y
> CONFIG_ANON_INODES=y
> # CONFIG_EXPERT is not set
> CONFIG_UID16=y
> # CONFIG_SYSCTL_SYSCALL is not set
> CONFIG_KALLSYMS=y
> CONFIG_KALLSYMS_ALL=y
> CONFIG_HOTPLUG=y
> CONFIG_PRINTK=y
> CONFIG_BUG=y
> CONFIG_ELF_CORE=y
> CONFIG_PCSPKR_PLATFORM=y
> CONFIG_HAVE_PCSPKR_PLATFORM=y
> CONFIG_BASE_FULL=y
> CONFIG_FUTEX=y
> CONFIG_EPOLL=y
> CONFIG_SIGNALFD=y
> CONFIG_TIMERFD=y
> CONFIG_EVENTFD=y
> CONFIG_SHMEM=y
> CONFIG_AIO=y
> # CONFIG_EMBEDDED is not set
> CONFIG_HAVE_PERF_EVENTS=y
> CONFIG_PERF_USE_VMALLOC=y
> 
> #
> # Kernel Performance Events And Counters
> #
> CONFIG_PERF_EVENTS=y
> # CONFIG_PERF_COUNTERS is not set
> CONFIG_DEBUG_PERF_USE_VMALLOC=y
> CONFIG_VM_EVENT_COUNTERS=y
> CONFIG_PCI_QUIRKS=y
> CONFIG_SLUB_DEBUG=y
> CONFIG_COMPAT_BRK=y
> # CONFIG_SLAB is not set
> CONFIG_SLUB=y
> # CONFIG_PROFILING is not set
> CONFIG_TRACEPOINTS=y
> CONFIG_HAVE_OPROFILE=y
> CONFIG_OPROFILE_NMI_TIMER=y
> # CONFIG_JUMP_LABEL is not set
> CONFIG_UPROBES=y
> CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS=y
> CONFIG_USER_RETURN_NOTIFIER=y
> CONFIG_HAVE_IOREMAP_PROT=y
> CONFIG_HAVE_KPROBES=y
> CONFIG_HAVE_KRETPROBES=y
> CONFIG_HAVE_OPTPROBES=y
> CONFIG_HAVE_ARCH_TRACEHOOK=y
> CONFIG_HAVE_DMA_ATTRS=y
> CONFIG_HAVE_REGS_AND_STACK_ACCESS_API=y
> CONFIG_HAVE_DMA_API_DEBUG=y
> CONFIG_HAVE_HW_BREAKPOINT=y
> CONFIG_HAVE_MIXED_BREAKPOINTS_REGS=y
> CONFIG_HAVE_USER_RETURN_NOTIFIER=y
> CONFIG_HAVE_PERF_EVENTS_NMI=y
> CONFIG_HAVE_ARCH_JUMP_LABEL=y
> CONFIG_ARCH_HAVE_NMI_SAFE_CMPXCHG=y
> CONFIG_HAVE_ALIGNED_STRUCT_PAGE=y
> CONFIG_HAVE_CMPXCHG_LOCAL=y
> CONFIG_HAVE_CMPXCHG_DOUBLE=y
> 
> #
> # GCOV-based kernel profiling
> #
> CONFIG_GCOV_KERNEL=y
> # CONFIG_GCOV_PROFILE_ALL is not set
> # CONFIG_HAVE_GENERIC_DMA_COHERENT is not set
> CONFIG_SLABINFO=y
> CONFIG_RT_MUTEXES=y
> CONFIG_BASE_SMALL=0
> # CONFIG_MODULES is not set
> CONFIG_BLOCK=y
> CONFIG_BLK_DEV_BSG=y
> CONFIG_BLK_DEV_BSGLIB=y
> # CONFIG_BLK_DEV_INTEGRITY is not set
> # CONFIG_BLK_DEV_THROTTLING is not set
> CONFIG_BLOCK_COMPAT=y
> 
> #
> # IO Schedulers
> #
> CONFIG_IOSCHED_NOOP=y
> CONFIG_IOSCHED_DEADLINE=y
> # CONFIG_IOSCHED_CFQ is not set
> # CONFIG_DEFAULT_DEADLINE is not set
> CONFIG_DEFAULT_NOOP=y
> CONFIG_DEFAULT_IOSCHED="noop"
> CONFIG_PREEMPT_NOTIFIERS=y
> # CONFIG_INLINE_SPIN_TRYLOCK is not set
> # CONFIG_INLINE_SPIN_TRYLOCK_BH is not set
> # CONFIG_INLINE_SPIN_LOCK is not set
> # CONFIG_INLINE_SPIN_LOCK_BH is not set
> # CONFIG_INLINE_SPIN_LOCK_IRQ is not set
> # CONFIG_INLINE_SPIN_LOCK_IRQSAVE is not set
> # CONFIG_INLINE_SPIN_UNLOCK is not set
> # CONFIG_INLINE_SPIN_UNLOCK_BH is not set
> # CONFIG_INLINE_SPIN_UNLOCK_IRQ is not set
> # CONFIG_INLINE_SPIN_UNLOCK_IRQRESTORE is not set
> # CONFIG_INLINE_READ_TRYLOCK is not set
> # CONFIG_INLINE_READ_LOCK is not set
> # CONFIG_INLINE_READ_LOCK_BH is not set
> # CONFIG_INLINE_READ_LOCK_IRQ is not set
> # CONFIG_INLINE_READ_LOCK_IRQSAVE is not set
> # CONFIG_INLINE_READ_UNLOCK is not set
> # CONFIG_INLINE_READ_UNLOCK_BH is not set
> # CONFIG_INLINE_READ_UNLOCK_IRQ is not set
> # CONFIG_INLINE_READ_UNLOCK_IRQRESTORE is not set
> # CONFIG_INLINE_WRITE_TRYLOCK is not set
> # CONFIG_INLINE_WRITE_LOCK is not set
> # CONFIG_INLINE_WRITE_LOCK_BH is not set
> # CONFIG_INLINE_WRITE_LOCK_IRQ is not set
> # CONFIG_INLINE_WRITE_LOCK_IRQSAVE is not set
> # CONFIG_INLINE_WRITE_UNLOCK is not set
> # CONFIG_INLINE_WRITE_UNLOCK_BH is not set
> # CONFIG_INLINE_WRITE_UNLOCK_IRQ is not set
> # CONFIG_INLINE_WRITE_UNLOCK_IRQRESTORE is not set
> # CONFIG_MUTEX_SPIN_ON_OWNER is not set
> CONFIG_FREEZER=y
> 
> #
> # Processor type and features
> #
> CONFIG_TICK_ONESHOT=y
> CONFIG_NO_HZ=y
> CONFIG_HIGH_RES_TIMERS=y
> CONFIG_GENERIC_CLOCKEVENTS_BUILD=y
> CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y
> # CONFIG_SMP is not set
> CONFIG_X86_MPPARSE=y
> CONFIG_X86_EXTENDED_PLATFORM=y
> CONFIG_X86_VSMP=y
> # CONFIG_SCHED_OMIT_FRAME_POINTER is not set
> # CONFIG_KVMTOOL_TEST_ENABLE is not set
> CONFIG_PARAVIRT_GUEST=y
> # CONFIG_PARAVIRT_TIME_ACCOUNTING is not set
> CONFIG_XEN=y
> CONFIG_XEN_DOM0=y
> CONFIG_XEN_PRIVILEGED_GUEST=y
> CONFIG_XEN_PVHVM=y
> CONFIG_XEN_MAX_DOMAIN_MEMORY=500
> CONFIG_XEN_SAVE_RESTORE=y
> # CONFIG_XEN_DEBUG_FS is not set
> # CONFIG_KVM_CLOCK is not set
> # CONFIG_KVM_GUEST is not set
> CONFIG_PARAVIRT=y
> CONFIG_PARAVIRT_CLOCK=y
> CONFIG_PARAVIRT_DEBUG=y
> CONFIG_NO_BOOTMEM=y
> CONFIG_MEMTEST=y
> # CONFIG_MK8 is not set
> # CONFIG_MPSC is not set
> # CONFIG_MCORE2 is not set
> # CONFIG_MATOM is not set
> CONFIG_GENERIC_CPU=y
> CONFIG_X86_INTERNODE_CACHE_SHIFT=12
> CONFIG_X86_CMPXCHG=y
> CONFIG_X86_L1_CACHE_SHIFT=6
> CONFIG_X86_XADD=y
> CONFIG_X86_WP_WORKS_OK=y
> CONFIG_X86_TSC=y
> CONFIG_X86_CMPXCHG64=y
> CONFIG_X86_CMOV=y
> CONFIG_X86_MINIMUM_CPU_FAMILY=64
> CONFIG_X86_DEBUGCTLMSR=y
> CONFIG_CPU_SUP_INTEL=y
> CONFIG_CPU_SUP_AMD=y
> CONFIG_CPU_SUP_CENTAUR=y
> CONFIG_HPET_TIMER=y
> CONFIG_HPET_EMULATE_RTC=y
> CONFIG_DMI=y
> CONFIG_GART_IOMMU=y
> CONFIG_CALGARY_IOMMU=y
> # CONFIG_CALGARY_IOMMU_ENABLED_BY_DEFAULT is not set
> CONFIG_SWIOTLB=y
> CONFIG_IOMMU_HELPER=y
> CONFIG_NR_CPUS=1
> # CONFIG_IRQ_TIME_ACCOUNTING is not set
> # CONFIG_PREEMPT_NONE is not set
> # CONFIG_PREEMPT_VOLUNTARY is not set
> CONFIG_PREEMPT=y
> CONFIG_PREEMPT_COUNT=y
> CONFIG_X86_LOCAL_APIC=y
> CONFIG_X86_IO_APIC=y
> CONFIG_X86_REROUTE_FOR_BROKEN_BOOT_IRQS=y
> # CONFIG_X86_MCE is not set
> # CONFIG_I8K is not set
> # CONFIG_MICROCODE is not set
> CONFIG_X86_MSR=y
> # CONFIG_X86_CPUID is not set
> CONFIG_ARCH_PHYS_ADDR_T_64BIT=y
> CONFIG_ARCH_DMA_ADDR_T_64BIT=y
> CONFIG_DIRECT_GBPAGES=y
> CONFIG_ARCH_SPARSEMEM_ENABLE=y
> CONFIG_ARCH_SPARSEMEM_DEFAULT=y
> CONFIG_ARCH_SELECT_MEMORY_MODEL=y
> CONFIG_ARCH_PROC_KCORE_TEXT=y
> CONFIG_ILLEGAL_POINTER_VALUE=0xdead000000000000
> CONFIG_SELECT_MEMORY_MODEL=y
> CONFIG_SPARSEMEM_MANUAL=y
> CONFIG_SPARSEMEM=y
> CONFIG_HAVE_MEMORY_PRESENT=y
> CONFIG_SPARSEMEM_EXTREME=y
> CONFIG_SPARSEMEM_VMEMMAP_ENABLE=y
> CONFIG_SPARSEMEM_ALLOC_MEM_MAP_TOGETHER=y
> CONFIG_SPARSEMEM_VMEMMAP=y
> CONFIG_HAVE_MEMBLOCK=y
> CONFIG_HAVE_MEMBLOCK_NODE_MAP=y
> CONFIG_ARCH_DISCARD_MEMBLOCK=y
> # CONFIG_MEMORY_HOTPLUG is not set
> CONFIG_PAGEFLAGS_EXTENDED=y
> CONFIG_SPLIT_PTLOCK_CPUS=999999
> CONFIG_COMPACTION=y
> CONFIG_MIGRATION=y
> CONFIG_PHYS_ADDR_T_64BIT=y
> CONFIG_ZONE_DMA_FLAG=1
> CONFIG_BOUNCE=y
> CONFIG_VIRT_TO_BUS=y
> CONFIG_MMU_NOTIFIER=y
> CONFIG_KSM=y
> CONFIG_DEFAULT_MMAP_MIN_ADDR=4096
> CONFIG_TRANSPARENT_HUGEPAGE=y
> # CONFIG_TRANSPARENT_HUGEPAGE_ALWAYS is not set
> CONFIG_TRANSPARENT_HUGEPAGE_MADVISE=y
> CONFIG_NEED_PER_CPU_KM=y
> CONFIG_CLEANCACHE=y
> CONFIG_FRONTSWAP=y
> CONFIG_X86_CHECK_BIOS_CORRUPTION=y
> CONFIG_X86_BOOTPARAM_MEMORY_CORRUPTION_CHECK=y
> CONFIG_X86_RESERVE_LOW=64
> CONFIG_MTRR=y
> CONFIG_MTRR_SANITIZER=y
> CONFIG_MTRR_SANITIZER_ENABLE_DEFAULT=0
> CONFIG_MTRR_SANITIZER_SPARE_REG_NR_DEFAULT=1
> CONFIG_X86_PAT=y
> CONFIG_ARCH_USES_PG_UNCACHED=y
> CONFIG_ARCH_RANDOM=y
> CONFIG_EFI=y
> CONFIG_EFI_STUB=y
> CONFIG_SECCOMP=y
> # CONFIG_CC_STACKPROTECTOR is not set
> # CONFIG_HZ_100 is not set
> CONFIG_HZ_250=y
> # CONFIG_HZ_300 is not set
> # CONFIG_HZ_1000 is not set
> CONFIG_HZ=250
> CONFIG_SCHED_HRTICK=y
> # CONFIG_KEXEC is not set
> # CONFIG_CRASH_DUMP is not set
> CONFIG_PHYSICAL_START=0x1000000
> CONFIG_RELOCATABLE=y
> CONFIG_PHYSICAL_ALIGN=0x1000000
> CONFIG_COMPAT_VDSO=y
> CONFIG_CMDLINE_BOOL=y
> CONFIG_CMDLINE=""
> # CONFIG_CMDLINE_OVERRIDE is not set
> CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y
> 
> #
> # Power management and ACPI options
> #
> CONFIG_ARCH_HIBERNATION_HEADER=y
> # CONFIG_SUSPEND is not set
> CONFIG_HIBERNATE_CALLBACKS=y
> CONFIG_HIBERNATION=y
> CONFIG_PM_STD_PARTITION=""
> CONFIG_PM_SLEEP=y
> # CONFIG_PM_RUNTIME is not set
> CONFIG_PM=y
> CONFIG_PM_DEBUG=y
> # CONFIG_PM_ADVANCED_DEBUG is not set
> CONFIG_CAN_PM_TRACE=y
> # CONFIG_PM_TRACE_RTC is not set
> CONFIG_ACPI=y
> CONFIG_ACPI_SLEEP=y
> CONFIG_ACPI_PROCFS=y
> # CONFIG_ACPI_PROCFS_POWER is not set
> # CONFIG_ACPI_EC_DEBUGFS is not set
> CONFIG_ACPI_PROC_EVENT=y
> # CONFIG_ACPI_AC is not set
> CONFIG_ACPI_BATTERY=y
> CONFIG_ACPI_BUTTON=y
> CONFIG_ACPI_VIDEO=y
> CONFIG_ACPI_FAN=y
> CONFIG_ACPI_DOCK=y
> CONFIG_ACPI_PROCESSOR=y
> CONFIG_ACPI_PROCESSOR_AGGREGATOR=y
> # CONFIG_ACPI_THERMAL is not set
> # CONFIG_ACPI_CUSTOM_DSDT is not set
> CONFIG_ACPI_BLACKLIST_YEAR=0
> # CONFIG_ACPI_DEBUG is not set
> # CONFIG_ACPI_PCI_SLOT is not set
> CONFIG_X86_PM_TIMER=y
> # CONFIG_ACPI_CONTAINER is not set
> CONFIG_ACPI_SBS=y
> CONFIG_ACPI_HED=y
> CONFIG_ACPI_CUSTOM_METHOD=y
> CONFIG_ACPI_APEI=y
> # CONFIG_ACPI_APEI_GHES is not set
> # CONFIG_ACPI_APEI_PCIEAER is not set
> CONFIG_ACPI_APEI_EINJ=y
> # CONFIG_ACPI_APEI_ERST_DEBUG is not set
> # CONFIG_SFI is not set
> 
> #
> # CPU Frequency scaling
> #
> # CONFIG_CPU_FREQ is not set
> CONFIG_CPU_IDLE=y
> CONFIG_CPU_IDLE_GOV_LADDER=y
> CONFIG_CPU_IDLE_GOV_MENU=y
> # CONFIG_INTEL_IDLE is not set
> 
> #
> # Memory power savings
> #
> # CONFIG_I7300_IDLE is not set
> 
> #
> # Bus options (PCI etc.)
> #
> CONFIG_PCI=y
> CONFIG_PCI_DIRECT=y
> CONFIG_PCI_MMCONFIG=y
> CONFIG_PCI_XEN=y
> CONFIG_PCI_DOMAINS=y
> # CONFIG_PCI_CNB20LE_QUIRK is not set
> CONFIG_PCIEPORTBUS=y
> # CONFIG_HOTPLUG_PCI_PCIE is not set
> CONFIG_PCIEAER=y
> CONFIG_PCIE_ECRC=y
> # CONFIG_PCIEAER_INJECT is not set
> CONFIG_PCIEASPM=y
> CONFIG_PCIEASPM_DEBUG=y
> CONFIG_ARCH_SUPPORTS_MSI=y
> # CONFIG_PCI_MSI is not set
> # CONFIG_PCI_DEBUG is not set
> # CONFIG_PCI_STUB is not set
> CONFIG_XEN_PCIDEV_FRONTEND=y
> # CONFIG_HT_IRQ is not set
> CONFIG_PCI_ATS=y
> CONFIG_PCI_IOV=y
> # CONFIG_PCI_PRI is not set
> # CONFIG_PCI_PASID is not set
> CONFIG_PCI_IOAPIC=y
> CONFIG_PCI_LABEL=y
> CONFIG_ISA_DMA_API=y
> CONFIG_AMD_NB=y
> CONFIG_PCCARD=y
> # CONFIG_PCMCIA is not set
> CONFIG_CARDBUS=y
> 
> #
> # PC-card bridges
> #
> CONFIG_YENTA=y
> CONFIG_YENTA_O2=y
> CONFIG_YENTA_RICOH=y
> CONFIG_YENTA_TI=y
> CONFIG_YENTA_ENE_TUNE=y
> CONFIG_YENTA_TOSHIBA=y
> CONFIG_HOTPLUG_PCI=y
> # CONFIG_HOTPLUG_PCI_FAKE is not set
> # CONFIG_HOTPLUG_PCI_ACPI is not set
> # CONFIG_HOTPLUG_PCI_CPCI is not set
> # CONFIG_HOTPLUG_PCI_SHPC is not set
> CONFIG_RAPIDIO=y
> # CONFIG_RAPIDIO_TSI721 is not set
> CONFIG_RAPIDIO_DISC_TIMEOUT=30
> # CONFIG_RAPIDIO_ENABLE_RX_TX_PORTS is not set
> CONFIG_RAPIDIO_DEBUG=y
> # CONFIG_RAPIDIO_TSI57X is not set
> # CONFIG_RAPIDIO_CPS_XX is not set
> CONFIG_RAPIDIO_TSI568=y
> # CONFIG_RAPIDIO_CPS_GEN2 is not set
> # CONFIG_RAPIDIO_TSI500 is not set
> 
> #
> # Executable file formats / Emulations
> #
> # CONFIG_BINFMT_ELF is not set
> CONFIG_COMPAT_BINFMT_ELF=y
> CONFIG_ARCH_BINFMT_ELF_RANDOMIZE_PIE=y
> # CONFIG_HAVE_AOUT is not set
> # CONFIG_BINFMT_MISC is not set
> CONFIG_IA32_EMULATION=y
> # CONFIG_IA32_AOUT is not set
> CONFIG_COMPAT=y
> CONFIG_COMPAT_FOR_U64_ALIGNMENT=y
> CONFIG_SYSVIPC_COMPAT=y
> CONFIG_KEYS_COMPAT=y
> CONFIG_HAVE_TEXT_POKE_SMP=y
> CONFIG_NET=y
> CONFIG_COMPAT_NETLINK_MESSAGES=y
> 
> #
> # Networking options
> #
> # CONFIG_PACKET is not set
> CONFIG_UNIX=y
> # CONFIG_UNIX_DIAG is not set
> CONFIG_XFRM=y
> CONFIG_XFRM_SUB_POLICY=y
> CONFIG_XFRM_MIGRATE=y
> CONFIG_NET_KEY=y
> CONFIG_NET_KEY_MIGRATE=y
> # CONFIG_INET is not set
> CONFIG_NETWORK_SECMARK=y
> # CONFIG_NETWORK_PHY_TIMESTAMPING is not set
> CONFIG_NETFILTER=y
> CONFIG_NETFILTER_DEBUG=y
> # CONFIG_NETFILTER_ADVANCED is not set
> CONFIG_ATM=y
> CONFIG_ATM_LANE=y
> # CONFIG_BRIDGE is not set
> CONFIG_NET_DSA=y
> CONFIG_NET_DSA_TAG_DSA=y
> CONFIG_NET_DSA_TAG_EDSA=y
> CONFIG_NET_DSA_TAG_TRAILER=y
> # CONFIG_VLAN_8021Q is not set
> # CONFIG_DECNET is not set
> CONFIG_LLC=y
> CONFIG_LLC2=y
> CONFIG_IPX=y
> CONFIG_IPX_INTERN=y
> # CONFIG_ATALK is not set
> CONFIG_X25=y
> # CONFIG_LAPB is not set
> # CONFIG_WAN_ROUTER is not set
> CONFIG_PHONET=y
> # CONFIG_IEEE802154 is not set
> CONFIG_NET_SCHED=y
> 
> #
> # Queueing/Scheduling
> #
> # CONFIG_NET_SCH_CBQ is not set
> CONFIG_NET_SCH_HTB=y
> CONFIG_NET_SCH_HFSC=y
> CONFIG_NET_SCH_ATM=y
> # CONFIG_NET_SCH_PRIO is not set
> # CONFIG_NET_SCH_MULTIQ is not set
> CONFIG_NET_SCH_RED=y
> CONFIG_NET_SCH_SFB=y
> CONFIG_NET_SCH_SFQ=y
> # CONFIG_NET_SCH_TEQL is not set
> CONFIG_NET_SCH_TBF=y
> # CONFIG_NET_SCH_GRED is not set
> # CONFIG_NET_SCH_DSMARK is not set
> # CONFIG_NET_SCH_NETEM is not set
> CONFIG_NET_SCH_DRR=y
> # CONFIG_NET_SCH_MQPRIO is not set
> # CONFIG_NET_SCH_CHOKE is not set
> CONFIG_NET_SCH_QFQ=y
> 
> #
> # Classification
> #
> CONFIG_NET_CLS=y
> # CONFIG_NET_CLS_BASIC is not set
> # CONFIG_NET_CLS_TCINDEX is not set
> CONFIG_NET_CLS_FW=y
> # CONFIG_NET_CLS_U32 is not set
> # CONFIG_NET_CLS_RSVP is not set
> # CONFIG_NET_CLS_RSVP6 is not set
> CONFIG_NET_CLS_FLOW=y
> CONFIG_NET_CLS_CGROUP=y
> CONFIG_NET_EMATCH=y
> CONFIG_NET_EMATCH_STACK=32
> # CONFIG_NET_EMATCH_CMP is not set
> CONFIG_NET_EMATCH_NBYTE=y
> # CONFIG_NET_EMATCH_U32 is not set
> CONFIG_NET_EMATCH_META=y
> CONFIG_NET_EMATCH_TEXT=y
> # CONFIG_NET_CLS_ACT is not set
> CONFIG_NET_CLS_IND=y
> CONFIG_NET_SCH_FIFO=y
> # CONFIG_DCB is not set
> # CONFIG_DNS_RESOLVER is not set
> # CONFIG_BATMAN_ADV is not set
> CONFIG_OPENVSWITCH=y
> CONFIG_NETPRIO_CGROUP=y
> CONFIG_BQL=y
> CONFIG_HAVE_BPF_JIT=y
> 
> #
> # Network testing
> #
> CONFIG_NET_PKTGEN=y
> # CONFIG_HAMRADIO is not set
> # CONFIG_CAN is not set
> CONFIG_IRDA=y
> 
> #
> # IrDA protocols
> #
> CONFIG_IRLAN=y
> # CONFIG_IRCOMM is not set
> CONFIG_IRDA_ULTRA=y
> 
> #
> # IrDA options
> #
> # CONFIG_IRDA_CACHE_LAST_LSAP is not set
> # CONFIG_IRDA_FAST_RR is not set
> CONFIG_IRDA_DEBUG=y
> 
> #
> # Infrared-port device drivers
> #
> 
> #
> # SIR device drivers
> #
> # CONFIG_IRTTY_SIR is not set
> 
> #
> # Dongle support
> #
> 
> #
> # FIR device drivers
> #
> # CONFIG_NSC_FIR is not set
> # CONFIG_WINBOND_FIR is not set
> CONFIG_SMC_IRCC_FIR=y
> CONFIG_ALI_FIR=y
> CONFIG_VLSI_FIR=y
> # CONFIG_VIA_FIR is not set
> # CONFIG_BT is not set
> CONFIG_WIRELESS=y
> CONFIG_WIRELESS_EXT=y
> CONFIG_WEXT_CORE=y
> CONFIG_WEXT_PROC=y
> CONFIG_WEXT_SPY=y
> CONFIG_WEXT_PRIV=y
> # CONFIG_CFG80211 is not set
> CONFIG_WIRELESS_EXT_SYSFS=y
> # CONFIG_LIB80211 is not set
> 
> #
> # CFG80211 needs to be enabled for MAC80211
> #
> CONFIG_WIMAX=y
> CONFIG_WIMAX_DEBUG_LEVEL=8
> # CONFIG_RFKILL is not set
> CONFIG_RFKILL_REGULATOR=y
> CONFIG_NET_9P=y
> # CONFIG_NET_9P_VIRTIO is not set
> CONFIG_NET_9P_DEBUG=y
> # CONFIG_CAIF is not set
> # CONFIG_NFC is not set
> 
> #
> # Device Drivers
> #
> 
> #
> # Generic Driver Options
> #
> CONFIG_UEVENT_HELPER_PATH=""
> # CONFIG_DEVTMPFS is not set
> CONFIG_STANDALONE=y
> CONFIG_PREVENT_FIRMWARE_BUILD=y
> CONFIG_FW_LOADER=y
> CONFIG_FIRMWARE_IN_KERNEL=y
> CONFIG_EXTRA_FIRMWARE=""
> # CONFIG_DEBUG_DRIVER is not set
> # CONFIG_DEBUG_DEVRES is not set
> CONFIG_SYS_HYPERVISOR=y
> CONFIG_REGMAP=y
> CONFIG_REGMAP_I2C=y
> CONFIG_REGMAP_SPI=y
> CONFIG_REGMAP_IRQ=y
> CONFIG_CONNECTOR=y
> # CONFIG_PROC_EVENTS is not set
> CONFIG_MTD=y
> # CONFIG_MTD_REDBOOT_PARTS is not set
> CONFIG_MTD_CMDLINE_PARTS=y
> # CONFIG_MTD_AR7_PARTS is not set
> 
> #
> # User Modules And Translation Layers
> #
> # CONFIG_MTD_CHAR is not set
> CONFIG_HAVE_MTD_OTP=y
> CONFIG_MTD_BLKDEVS=y
> CONFIG_MTD_BLOCK=y
> CONFIG_FTL=y
> CONFIG_NFTL=y
> # CONFIG_NFTL_RW is not set
> CONFIG_INFTL=y
> CONFIG_RFD_FTL=y
> CONFIG_SSFDC=y
> # CONFIG_SM_FTL is not set
> CONFIG_MTD_OOPS=y
> CONFIG_MTD_SWAP=y
> 
> #
> # RAM/ROM/Flash chip drivers
> #
> CONFIG_MTD_CFI=y
> CONFIG_MTD_JEDECPROBE=y
> CONFIG_MTD_GEN_PROBE=y
> CONFIG_MTD_CFI_ADV_OPTIONS=y
> # CONFIG_MTD_CFI_NOSWAP is not set
> CONFIG_MTD_CFI_BE_BYTE_SWAP=y
> # CONFIG_MTD_CFI_LE_BYTE_SWAP is not set
> CONFIG_MTD_CFI_GEOMETRY=y
> # CONFIG_MTD_MAP_BANK_WIDTH_1 is not set
> CONFIG_MTD_MAP_BANK_WIDTH_2=y
> # CONFIG_MTD_MAP_BANK_WIDTH_4 is not set
> # CONFIG_MTD_MAP_BANK_WIDTH_8 is not set
> CONFIG_MTD_MAP_BANK_WIDTH_16=y
> # CONFIG_MTD_MAP_BANK_WIDTH_32 is not set
> CONFIG_MTD_CFI_I1=y
> CONFIG_MTD_CFI_I2=y
> CONFIG_MTD_CFI_I4=y
> # CONFIG_MTD_CFI_I8 is not set
> CONFIG_MTD_OTP=y
> CONFIG_MTD_CFI_INTELEXT=y
> CONFIG_MTD_CFI_AMDSTD=y
> # CONFIG_MTD_CFI_STAA is not set
> CONFIG_MTD_CFI_UTIL=y
> CONFIG_MTD_RAM=y
> CONFIG_MTD_ROM=y
> CONFIG_MTD_ABSENT=y
> 
> #
> # Mapping drivers for chip access
> #
> CONFIG_MTD_COMPLEX_MAPPINGS=y
> # CONFIG_MTD_PHYSMAP is not set
> CONFIG_MTD_SC520CDP=y
> # CONFIG_MTD_NETSC520 is not set
> CONFIG_MTD_TS5500=y
> CONFIG_MTD_SBC_GXX=y
> # CONFIG_MTD_AMD76XROM is not set
> CONFIG_MTD_ICHXROM=y
> # CONFIG_MTD_ESB2ROM is not set
> CONFIG_MTD_CK804XROM=y
> CONFIG_MTD_SCB2_FLASH=y
> # CONFIG_MTD_NETtel is not set
> CONFIG_MTD_L440GX=y
> # CONFIG_MTD_PCI is not set
> CONFIG_MTD_GPIO_ADDR=y
> # CONFIG_MTD_INTEL_VR_NOR is not set
> CONFIG_MTD_PLATRAM=y
> CONFIG_MTD_LATCH_ADDR=y
> 
> #
> # Self-contained MTD device drivers
> #
> # CONFIG_MTD_PMC551 is not set
> CONFIG_MTD_DATAFLASH=y
> # CONFIG_MTD_DATAFLASH_WRITE_VERIFY is not set
> # CONFIG_MTD_DATAFLASH_OTP is not set
> # CONFIG_MTD_M25P80 is not set
> # CONFIG_MTD_SST25L is not set
> CONFIG_MTD_SLRAM=y
> # CONFIG_MTD_PHRAM is not set
> # CONFIG_MTD_MTDRAM is not set
> # CONFIG_MTD_BLOCK2MTD is not set
> 
> #
> # Disk-On-Chip Device Drivers
> #
> CONFIG_MTD_DOC2000=y
> CONFIG_MTD_DOC2001=y
> CONFIG_MTD_DOC2001PLUS=y
> CONFIG_MTD_DOCG3=y
> CONFIG_BCH_CONST_M=14
> CONFIG_BCH_CONST_T=4
> CONFIG_MTD_DOCPROBE=y
> CONFIG_MTD_DOCECC=y
> # CONFIG_MTD_DOCPROBE_ADVANCED is not set
> CONFIG_MTD_DOCPROBE_ADDRESS=0x0
> CONFIG_MTD_NAND_ECC=y
> # CONFIG_MTD_NAND_ECC_SMC is not set
> CONFIG_MTD_NAND=y
> CONFIG_MTD_NAND_VERIFY_WRITE=y
> CONFIG_MTD_NAND_BCH=y
> CONFIG_MTD_NAND_ECC_BCH=y
> # CONFIG_MTD_SM_COMMON is not set
> # CONFIG_MTD_NAND_MUSEUM_IDS is not set
> CONFIG_MTD_NAND_DENALI=y
> CONFIG_MTD_NAND_DENALI_SCRATCH_REG_ADDR=0xFF108018
> CONFIG_MTD_NAND_IDS=y
> # CONFIG_MTD_NAND_RICOH is not set
> # CONFIG_MTD_NAND_DISKONCHIP is not set
> # CONFIG_MTD_NAND_CAFE is not set
> CONFIG_MTD_NAND_NANDSIM=y
> CONFIG_MTD_NAND_PLATFORM=y
> CONFIG_MTD_ONENAND=y
> # CONFIG_MTD_ONENAND_VERIFY_WRITE is not set
> CONFIG_MTD_ONENAND_GENERIC=y
> CONFIG_MTD_ONENAND_OTP=y
> CONFIG_MTD_ONENAND_2X_PROGRAM=y
> # CONFIG_MTD_ONENAND_SIM is not set
> 
> #
> # LPDDR flash memory drivers
> #
> CONFIG_MTD_LPDDR=y
> CONFIG_MTD_QINFO_PROBE=y
> CONFIG_MTD_UBI=y
> CONFIG_MTD_UBI_WL_THRESHOLD=4096
> CONFIG_MTD_UBI_BEB_RESERVE=1
> CONFIG_MTD_UBI_GLUEBI=y
> # CONFIG_MTD_UBI_DEBUG is not set
> # CONFIG_PARPORT is not set
> CONFIG_PNP=y
> # CONFIG_PNP_DEBUG_MESSAGES is not set
> 
> #
> # Protocols
> #
> CONFIG_PNPACPI=y
> CONFIG_BLK_DEV=y
> # CONFIG_BLK_DEV_FD is not set
> # CONFIG_BLK_CPQ_DA is not set
> # CONFIG_BLK_CPQ_CISS_DA is not set
> # CONFIG_BLK_DEV_DAC960 is not set
> CONFIG_BLK_DEV_UMEM=y
> # CONFIG_BLK_DEV_COW_COMMON is not set
> # CONFIG_BLK_DEV_LOOP is not set
> 
> #
> # DRBD disabled because PROC_FS, INET or CONNECTOR not selected
> #
> CONFIG_BLK_DEV_NBD=y
> CONFIG_BLK_DEV_OSD=y
> CONFIG_BLK_DEV_SX8=y
> # CONFIG_BLK_DEV_RAM is not set
> CONFIG_CDROM_PKTCDVD=y
> CONFIG_CDROM_PKTCDVD_BUFFERS=8
> CONFIG_CDROM_PKTCDVD_WCACHE=y
> # CONFIG_ATA_OVER_ETH is not set
> CONFIG_XEN_BLKDEV_FRONTEND=y
> # CONFIG_XEN_BLKDEV_BACKEND is not set
> # CONFIG_VIRTIO_BLK is not set
> CONFIG_BLK_DEV_HD=y
> # CONFIG_SENSORS_LIS3LV02D is not set
> # CONFIG_MISC_DEVICES is not set
> CONFIG_HAVE_IDE=y
> CONFIG_IDE=y
> 
> #
> # Please see Documentation/ide/ide.txt for help/info on IDE drives
> #
> CONFIG_IDE_XFER_MODE=y
> CONFIG_IDE_TIMINGS=y
> CONFIG_BLK_DEV_IDE_SATA=y
> # CONFIG_IDE_GD is not set
> CONFIG_BLK_DEV_DELKIN=y
> # CONFIG_BLK_DEV_IDECD is not set
> # CONFIG_BLK_DEV_IDETAPE is not set
> CONFIG_BLK_DEV_IDEACPI=y
> # CONFIG_IDE_TASK_IOCTL is not set
> # CONFIG_IDE_PROC_FS is not set
> 
> #
> # IDE chipset support/bugfixes
> #
> # CONFIG_IDE_GENERIC is not set
> # CONFIG_BLK_DEV_PLATFORM is not set
> # CONFIG_BLK_DEV_CMD640 is not set
> # CONFIG_BLK_DEV_IDEPNP is not set
> CONFIG_BLK_DEV_IDEDMA_SFF=y
> 
> #
> # PCI IDE chipsets support
> #
> CONFIG_BLK_DEV_IDEPCI=y
> CONFIG_IDEPCI_PCIBUS_ORDER=y
> # CONFIG_BLK_DEV_OFFBOARD is not set
> # CONFIG_BLK_DEV_GENERIC is not set
> # CONFIG_BLK_DEV_OPTI621 is not set
> # CONFIG_BLK_DEV_RZ1000 is not set
> CONFIG_BLK_DEV_IDEDMA_PCI=y
> CONFIG_BLK_DEV_AEC62XX=y
> # CONFIG_BLK_DEV_ALI15X3 is not set
> # CONFIG_BLK_DEV_AMD74XX is not set
> CONFIG_BLK_DEV_ATIIXP=y
> CONFIG_BLK_DEV_CMD64X=y
> CONFIG_BLK_DEV_TRIFLEX=y
> # CONFIG_BLK_DEV_CS5520 is not set
> CONFIG_BLK_DEV_CS5530=y
> CONFIG_BLK_DEV_HPT366=y
> # CONFIG_BLK_DEV_JMICRON is not set
> # CONFIG_BLK_DEV_SC1200 is not set
> # CONFIG_BLK_DEV_PIIX is not set
> CONFIG_BLK_DEV_IT8172=y
> CONFIG_BLK_DEV_IT8213=y
> # CONFIG_BLK_DEV_IT821X is not set
> # CONFIG_BLK_DEV_NS87415 is not set
> # CONFIG_BLK_DEV_PDC202XX_OLD is not set
> CONFIG_BLK_DEV_PDC202XX_NEW=y
> CONFIG_BLK_DEV_SVWKS=y
> # CONFIG_BLK_DEV_SIIMAGE is not set
> # CONFIG_BLK_DEV_SIS5513 is not set
> # CONFIG_BLK_DEV_SLC90E66 is not set
> # CONFIG_BLK_DEV_TRM290 is not set
> # CONFIG_BLK_DEV_VIA82CXXX is not set
> # CONFIG_BLK_DEV_TC86C001 is not set
> CONFIG_BLK_DEV_IDEDMA=y
> 
> #
> # SCSI device support
> #
> CONFIG_SCSI_MOD=y
> CONFIG_RAID_ATTRS=y
> CONFIG_SCSI=y
> CONFIG_SCSI_DMA=y
> # CONFIG_SCSI_TGT is not set
> CONFIG_SCSI_NETLINK=y
> # CONFIG_SCSI_PROC_FS is not set
> 
> #
> # SCSI support type (disk, tape, CD-ROM)
> #
> # CONFIG_BLK_DEV_SD is not set
> # CONFIG_CHR_DEV_ST is not set
> # CONFIG_CHR_DEV_OSST is not set
> # CONFIG_BLK_DEV_SR is not set
> CONFIG_CHR_DEV_SG=y
> # CONFIG_CHR_DEV_SCH is not set
> # CONFIG_SCSI_MULTI_LUN is not set
> # CONFIG_SCSI_CONSTANTS is not set
> # CONFIG_SCSI_LOGGING is not set
> # CONFIG_SCSI_SCAN_ASYNC is not set
> 
> #
> # SCSI Transports
> #
> CONFIG_SCSI_SPI_ATTRS=y
> CONFIG_SCSI_FC_ATTRS=y
> CONFIG_SCSI_ISCSI_ATTRS=y
> CONFIG_SCSI_SAS_ATTRS=y
> CONFIG_SCSI_SAS_LIBSAS=y
> CONFIG_SCSI_SAS_HOST_SMP=y
> CONFIG_SCSI_SRP_ATTRS=y
> CONFIG_SCSI_LOWLEVEL=y
> CONFIG_ISCSI_BOOT_SYSFS=y
> # CONFIG_SCSI_BNX2_ISCSI is not set
> CONFIG_SCSI_BNX2X_FCOE=y
> CONFIG_BE2ISCSI=y
> # CONFIG_BLK_DEV_3W_XXXX_RAID is not set
> CONFIG_SCSI_HPSA=y
> CONFIG_SCSI_3W_9XXX=y
> CONFIG_SCSI_3W_SAS=y
> # CONFIG_SCSI_ACARD is not set
> CONFIG_SCSI_AACRAID=y
> # CONFIG_SCSI_AIC7XXX is not set
> CONFIG_SCSI_AIC7XXX_OLD=y
> CONFIG_SCSI_AIC79XX=y
> CONFIG_AIC79XX_CMDS_PER_DEVICE=32
> CONFIG_AIC79XX_RESET_DELAY_MS=5000
> CONFIG_AIC79XX_DEBUG_ENABLE=y
> CONFIG_AIC79XX_DEBUG_MASK=0
> CONFIG_AIC79XX_REG_PRETTY_PRINT=y
> CONFIG_SCSI_AIC94XX=y
> CONFIG_AIC94XX_DEBUG=y
> CONFIG_SCSI_MVSAS=y
> # CONFIG_SCSI_MVSAS_DEBUG is not set
> CONFIG_SCSI_MVSAS_TASKLET=y
> CONFIG_SCSI_MVUMI=y
> CONFIG_SCSI_DPT_I2O=y
> CONFIG_SCSI_ADVANSYS=y
> CONFIG_SCSI_ARCMSR=y
> CONFIG_MEGARAID_NEWGEN=y
> CONFIG_MEGARAID_MM=y
> # CONFIG_MEGARAID_MAILBOX is not set
> # CONFIG_MEGARAID_LEGACY is not set
> # CONFIG_MEGARAID_SAS is not set
> CONFIG_SCSI_MPT2SAS=y
> CONFIG_SCSI_MPT2SAS_MAX_SGE=128
> CONFIG_SCSI_MPT2SAS_LOGGING=y
> # CONFIG_SCSI_HPTIOP is not set
> # CONFIG_SCSI_BUSLOGIC is not set
> # CONFIG_VMWARE_PVSCSI is not set
> CONFIG_LIBFC=y
> CONFIG_LIBFCOE=y
> CONFIG_FCOE=y
> CONFIG_FCOE_FNIC=y
> # CONFIG_SCSI_DMX3191D is not set
> CONFIG_SCSI_EATA=y
> # CONFIG_SCSI_EATA_TAGGED_QUEUE is not set
> CONFIG_SCSI_EATA_LINKED_COMMANDS=y
> CONFIG_SCSI_EATA_MAX_TAGS=16
> CONFIG_SCSI_FUTURE_DOMAIN=y
> # CONFIG_SCSI_GDTH is not set
> CONFIG_SCSI_ISCI=y
> # CONFIG_SCSI_IPS is not set
> CONFIG_SCSI_INITIO=y
> # CONFIG_SCSI_INIA100 is not set
> # CONFIG_SCSI_STEX is not set
> CONFIG_SCSI_SYM53C8XX_2=y
> CONFIG_SCSI_SYM53C8XX_DMA_ADDRESSING_MODE=1
> CONFIG_SCSI_SYM53C8XX_DEFAULT_TAGS=16
> CONFIG_SCSI_SYM53C8XX_MAX_TAGS=64
> # CONFIG_SCSI_SYM53C8XX_MMIO is not set
> # CONFIG_SCSI_QLOGIC_1280 is not set
> CONFIG_SCSI_QLA_FC=y
> # CONFIG_SCSI_QLA_ISCSI is not set
> CONFIG_SCSI_LPFC=y
> # CONFIG_SCSI_LPFC_DEBUG_FS is not set
> # CONFIG_SCSI_DC395x is not set
> # CONFIG_SCSI_DC390T is not set
> # CONFIG_SCSI_DEBUG is not set
> CONFIG_SCSI_PMCRAID=y
> # CONFIG_SCSI_PM8001 is not set
> # CONFIG_SCSI_SRP is not set
> CONFIG_SCSI_BFA_FC=y
> CONFIG_SCSI_DH=y
> # CONFIG_SCSI_DH_RDAC is not set
> # CONFIG_SCSI_DH_HP_SW is not set
> # CONFIG_SCSI_DH_EMC is not set
> # CONFIG_SCSI_DH_ALUA is not set
> CONFIG_SCSI_OSD_INITIATOR=y
> CONFIG_SCSI_OSD_ULD=y
> CONFIG_SCSI_OSD_DPRINT_SENSE=1
> # CONFIG_SCSI_OSD_DEBUG is not set
> # CONFIG_ATA is not set
> CONFIG_MD=y
> # CONFIG_BLK_DEV_MD is not set
> # CONFIG_BLK_DEV_DM is not set
> CONFIG_TARGET_CORE=y
> CONFIG_TCM_IBLOCK=y
> # CONFIG_TCM_FILEIO is not set
> CONFIG_TCM_PSCSI=y
> CONFIG_LOOPBACK_TARGET=y
> CONFIG_TCM_FC=y
> CONFIG_ISCSI_TARGET=y
> # CONFIG_FUSION is not set
> 
> #
> # IEEE 1394 (FireWire) support
> #
> CONFIG_FIREWIRE=y
> CONFIG_FIREWIRE_OHCI=y
> CONFIG_FIREWIRE_OHCI_DEBUG=y
> CONFIG_FIREWIRE_SBP2=y
> # CONFIG_FIREWIRE_NOSY is not set
> # CONFIG_I2O is not set
> CONFIG_MACINTOSH_DRIVERS=y
> # CONFIG_MAC_EMUMOUSEBTN is not set
> CONFIG_NETDEVICES=y
> CONFIG_NET_CORE=y
> # CONFIG_DUMMY is not set
> # CONFIG_EQUALIZER is not set
> # CONFIG_NET_FC is not set
> CONFIG_MII=y
> # CONFIG_NET_TEAM is not set
> CONFIG_MACVLAN=y
> CONFIG_MACVTAP=y
> # CONFIG_NETCONSOLE is not set
> # CONFIG_NETPOLL is not set
> # CONFIG_NET_POLL_CONTROLLER is not set
> # CONFIG_RIONET is not set
> CONFIG_TUN=y
> # CONFIG_VETH is not set
> CONFIG_VIRTIO_NET=y
> # CONFIG_ARCNET is not set
> # CONFIG_ATM_DRIVERS is not set
> 
> #
> # CAIF transport drivers
> #
> 
> #
> # Distributed Switch Architecture drivers
> #
> CONFIG_NET_DSA_MV88E6XXX=y
> CONFIG_NET_DSA_MV88E6060=y
> CONFIG_NET_DSA_MV88E6XXX_NEED_PPU=y
> CONFIG_NET_DSA_MV88E6131=y
> CONFIG_NET_DSA_MV88E6123_61_65=y
> CONFIG_ETHERNET=y
> CONFIG_MDIO=y
> # CONFIG_NET_VENDOR_3COM is not set
> # CONFIG_NET_VENDOR_ADAPTEC is not set
> # CONFIG_NET_VENDOR_ALTEON is not set
> CONFIG_NET_VENDOR_AMD=y
> # CONFIG_AMD8111_ETH is not set
> # CONFIG_PCNET32 is not set
> CONFIG_NET_VENDOR_ATHEROS=y
> # CONFIG_ATL2 is not set
> CONFIG_ATL1=y
> CONFIG_ATL1E=y
> # CONFIG_ATL1C is not set
> CONFIG_NET_VENDOR_BROADCOM=y
> # CONFIG_B44 is not set
> CONFIG_BNX2=y
> CONFIG_CNIC=y
> # CONFIG_TIGON3 is not set
> CONFIG_BNX2X=y
> # CONFIG_NET_VENDOR_BROCADE is not set
> CONFIG_NET_CALXEDA_XGMAC=y
> CONFIG_NET_VENDOR_CHELSIO=y
> # CONFIG_CHELSIO_T1 is not set
> # CONFIG_CHELSIO_T4 is not set
> # CONFIG_CHELSIO_T4VF is not set
> CONFIG_DNET=y
> CONFIG_NET_VENDOR_DEC=y
> CONFIG_NET_TULIP=y
> # CONFIG_DE2104X is not set
> CONFIG_TULIP=y
> # CONFIG_TULIP_MWI is not set
> CONFIG_TULIP_MMIO=y
> CONFIG_TULIP_NAPI=y
> # CONFIG_TULIP_NAPI_HW_MITIGATION is not set
> # CONFIG_DE4X5 is not set
> CONFIG_WINBOND_840=y
> CONFIG_DM9102=y
> CONFIG_ULI526X=y
> # CONFIG_PCMCIA_XIRCOM is not set
> # CONFIG_NET_VENDOR_DLINK is not set
> # CONFIG_NET_VENDOR_EXAR is not set
> CONFIG_NET_VENDOR_HP=y
> CONFIG_HP100=y
> # CONFIG_NET_VENDOR_INTEL is not set
> # CONFIG_IP1000 is not set
> CONFIG_JME=y
> CONFIG_NET_VENDOR_MARVELL=y
> # CONFIG_SKGE is not set
> # CONFIG_SKY2 is not set
> # CONFIG_NET_VENDOR_MICREL is not set
> # CONFIG_NET_VENDOR_MICROCHIP is not set
> # CONFIG_FEALNX is not set
> # CONFIG_NET_VENDOR_NATSEMI is not set
> # CONFIG_NET_VENDOR_NVIDIA is not set
> CONFIG_NET_VENDOR_OKI=y
> # CONFIG_PCH_GBE is not set
> CONFIG_ETHOC=y
> # CONFIG_NET_PACKET_ENGINE is not set
> # CONFIG_NET_VENDOR_QLOGIC is not set
> CONFIG_NET_VENDOR_REALTEK=y
> CONFIG_8139CP=y
> # CONFIG_8139TOO is not set
> # CONFIG_R8169 is not set
> # CONFIG_NET_VENDOR_RDC is not set
> CONFIG_NET_VENDOR_SEEQ=y
> CONFIG_SEEQ8005=y
> CONFIG_NET_VENDOR_SILAN=y
> # CONFIG_SC92031 is not set
> # CONFIG_NET_VENDOR_SIS is not set
> # CONFIG_NET_VENDOR_SMSC is not set
> CONFIG_NET_VENDOR_STMICRO=y
> CONFIG_STMMAC_ETH=y
> CONFIG_STMMAC_DEBUG_FS=y
> CONFIG_STMMAC_DA=y
> CONFIG_STMMAC_RING=y
> # CONFIG_STMMAC_CHAINED is not set
> CONFIG_NET_VENDOR_SUN=y
> CONFIG_HAPPYMEAL=y
> # CONFIG_SUNGEM is not set
> CONFIG_CASSINI=y
> # CONFIG_NIU is not set
> # CONFIG_NET_VENDOR_TEHUTI is not set
> CONFIG_NET_VENDOR_TI=y
> # CONFIG_TLAN is not set
> CONFIG_NET_VENDOR_VIA=y
> # CONFIG_VIA_RHINE is not set
> # CONFIG_VIA_VELOCITY is not set
> CONFIG_FDDI=y
> # CONFIG_DEFXX is not set
> CONFIG_SKFP=y
> CONFIG_NET_SB1000=y
> CONFIG_PHYLIB=y
> 
> #
> # MII PHY device drivers
> #
> # CONFIG_MARVELL_PHY is not set
> # CONFIG_DAVICOM_PHY is not set
> CONFIG_QSEMI_PHY=y
> CONFIG_LXT_PHY=y
> CONFIG_CICADA_PHY=y
> CONFIG_VITESSE_PHY=y
> # CONFIG_SMSC_PHY is not set
> CONFIG_BROADCOM_PHY=y
> CONFIG_ICPLUS_PHY=y
> CONFIG_REALTEK_PHY=y
> # CONFIG_NATIONAL_PHY is not set
> # CONFIG_STE10XP is not set
> CONFIG_LSI_ET1011C_PHY=y
> # CONFIG_MICREL_PHY is not set
> CONFIG_FIXED_PHY=y
> CONFIG_MDIO_BITBANG=y
> CONFIG_MDIO_GPIO=y
> CONFIG_MICREL_KS8995MA=y
> # CONFIG_PPP is not set
> CONFIG_SLIP=y
> # CONFIG_SLIP_COMPRESSED is not set
> CONFIG_SLIP_SMART=y
> CONFIG_SLIP_MODE_SLIP6=y
> CONFIG_TR=y
> # CONFIG_IBMOL is not set
> CONFIG_3C359=y
> # CONFIG_TMS380TR is not set
> CONFIG_WLAN=y
> # CONFIG_AIRO is not set
> # CONFIG_ATMEL is not set
> CONFIG_PRISM54=y
> # CONFIG_HOSTAP is not set
> 
> #
> # WiMAX Wireless Broadband devices
> #
> 
> #
> # Enable USB support to see WiMAX USB drivers
> #
> 
> #
> # Enable MMC support to see WiMAX SDIO drivers
> #
> CONFIG_WAN=y
> CONFIG_LANMEDIA=y
> CONFIG_HDLC=y
> CONFIG_HDLC_RAW=y
> # CONFIG_HDLC_RAW_ETH is not set
> # CONFIG_HDLC_CISCO is not set
> # CONFIG_HDLC_FR is not set
> CONFIG_HDLC_PPP=y
> 
> #
> # X.25/LAPB support is disabled
> #
> CONFIG_PCI200SYN=y
> # CONFIG_WANXL is not set
> CONFIG_PC300TOO=y
> CONFIG_FARSYNC=y
> CONFIG_DLCI=y
> CONFIG_DLCI_MAX=8
> # CONFIG_SBNI is not set
> # CONFIG_XEN_NETDEV_FRONTEND is not set
> CONFIG_XEN_NETDEV_BACKEND=y
> CONFIG_ISDN=y
> CONFIG_ISDN_I4L=y
> # CONFIG_ISDN_AUDIO is not set
> CONFIG_ISDN_X25=y
> 
> #
> # ISDN feature submodules
> #
> # CONFIG_ISDN_DRV_LOOP is not set
> # CONFIG_ISDN_DIVERSION is not set
> 
> #
> # ISDN4Linux hardware drivers
> #
> 
> #
> # Passive cards
> #
> # CONFIG_ISDN_DRV_HISAX is not set
> 
> #
> # Active cards
> #
> # CONFIG_ISDN_CAPI is not set
> CONFIG_ISDN_DRV_GIGASET=y
> CONFIG_GIGASET_I4L=y
> # CONFIG_GIGASET_DUMMYLL is not set
> CONFIG_GIGASET_M101=y
> # CONFIG_GIGASET_DEBUG is not set
> CONFIG_MISDN=y
> CONFIG_MISDN_DSP=y
> # CONFIG_MISDN_L1OIP is not set
> 
> #
> # mISDN hardware drivers
> #
> CONFIG_MISDN_HFCPCI=y
> # CONFIG_MISDN_HFCMULTI is not set
> CONFIG_MISDN_AVMFRITZ=y
> # CONFIG_MISDN_SPEEDFAX is not set
> # CONFIG_MISDN_INFINEON is not set
> CONFIG_MISDN_W6692=y
> CONFIG_MISDN_NETJET=y
> CONFIG_MISDN_IPAC=y
> CONFIG_ISDN_HDLC=y
> # CONFIG_PHONE is not set
> 
> #
> # Input device support
> #
> CONFIG_INPUT=y
> # CONFIG_INPUT_FF_MEMLESS is not set
> CONFIG_INPUT_POLLDEV=y
> CONFIG_INPUT_SPARSEKMAP=y
> 
> #
> # Userland interfaces
> #
> CONFIG_INPUT_MOUSEDEV=y
> CONFIG_INPUT_MOUSEDEV_PSAUX=y
> CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024
> CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768
> CONFIG_INPUT_JOYDEV=y
> # CONFIG_INPUT_EVDEV is not set
> CONFIG_INPUT_EVBUG=y
> 
> #
> # Input Device Drivers
> #
> CONFIG_INPUT_KEYBOARD=y
> # CONFIG_KEYBOARD_ADP5588 is not set
> CONFIG_KEYBOARD_ADP5589=y
> CONFIG_KEYBOARD_ATKBD=y
> CONFIG_KEYBOARD_QT1070=y
> # CONFIG_KEYBOARD_QT2160 is not set
> CONFIG_KEYBOARD_LKKBD=y
> # CONFIG_KEYBOARD_GPIO is not set
> # CONFIG_KEYBOARD_GPIO_POLLED is not set
> CONFIG_KEYBOARD_TCA6416=y
> # CONFIG_KEYBOARD_TCA8418 is not set
> CONFIG_KEYBOARD_MATRIX=y
> CONFIG_KEYBOARD_LM8323=y
> # CONFIG_KEYBOARD_MAX7359 is not set
> CONFIG_KEYBOARD_MCS=y
> CONFIG_KEYBOARD_MPR121=y
> CONFIG_KEYBOARD_NEWTON=y
> CONFIG_KEYBOARD_OPENCORES=y
> # CONFIG_KEYBOARD_STOWAWAY is not set
> CONFIG_KEYBOARD_SUNKBD=y
> # CONFIG_KEYBOARD_TC3589X is not set
> CONFIG_KEYBOARD_XTKBD=y
> CONFIG_INPUT_MOUSE=y
> CONFIG_MOUSE_PS2=y
> CONFIG_MOUSE_PS2_ALPS=y
> CONFIG_MOUSE_PS2_LOGIPS2PP=y
> CONFIG_MOUSE_PS2_SYNAPTICS=y
> CONFIG_MOUSE_PS2_LIFEBOOK=y
> CONFIG_MOUSE_PS2_TRACKPOINT=y
> CONFIG_MOUSE_PS2_ELANTECH=y
> # CONFIG_MOUSE_PS2_SENTELIC is not set
> # CONFIG_MOUSE_PS2_TOUCHKIT is not set
> CONFIG_MOUSE_SERIAL=y
> CONFIG_MOUSE_VSXXXAA=y
> # CONFIG_MOUSE_GPIO is not set
> CONFIG_MOUSE_SYNAPTICS_I2C=y
> # CONFIG_INPUT_JOYSTICK is not set
> CONFIG_INPUT_TABLET=y
> # CONFIG_INPUT_TOUCHSCREEN is not set
> CONFIG_INPUT_MISC=y
> CONFIG_INPUT_88PM860X_ONKEY=y
> # CONFIG_INPUT_AD714X is not set
> CONFIG_INPUT_BMA150=y
> # CONFIG_INPUT_PCSPKR is not set
> # CONFIG_INPUT_MMA8450 is not set
> CONFIG_INPUT_MPU3050=y
> # CONFIG_INPUT_APANEL is not set
> # CONFIG_INPUT_GP2A is not set
> CONFIG_INPUT_GPIO_TILT_POLLED=y
> CONFIG_INPUT_ATLAS_BTNS=y
> # CONFIG_INPUT_KXTJ9 is not set
> # CONFIG_INPUT_UINPUT is not set
> # CONFIG_INPUT_PCF8574 is not set
> CONFIG_INPUT_GPIO_ROTARY_ENCODER=y
> # CONFIG_INPUT_WM831X_ON is not set
> # CONFIG_INPUT_PCAP is not set
> CONFIG_INPUT_ADXL34X=y
> CONFIG_INPUT_ADXL34X_I2C=y
> CONFIG_INPUT_ADXL34X_SPI=y
> # CONFIG_INPUT_CMA3000 is not set
> 
> #
> # Hardware I/O ports
> #
> CONFIG_SERIO=y
> CONFIG_SERIO_I8042=y
> CONFIG_SERIO_SERPORT=y
> CONFIG_SERIO_CT82C710=y
> CONFIG_SERIO_PCIPS2=y
> CONFIG_SERIO_LIBPS2=y
> # CONFIG_SERIO_RAW is not set
> CONFIG_SERIO_ALTERA_PS2=y
> # CONFIG_SERIO_PS2MULT is not set
> CONFIG_GAMEPORT=y
> # CONFIG_GAMEPORT_NS558 is not set
> CONFIG_GAMEPORT_L4=y
> CONFIG_GAMEPORT_EMU10K1=y
> # CONFIG_GAMEPORT_FM801 is not set
> 
> #
> # Character devices
> #
> CONFIG_VT=y
> CONFIG_CONSOLE_TRANSLATIONS=y
> CONFIG_VT_CONSOLE=y
> CONFIG_VT_CONSOLE_SLEEP=y
> CONFIG_HW_CONSOLE=y
> # CONFIG_VT_HW_CONSOLE_BINDING is not set
> CONFIG_UNIX98_PTYS=y
> CONFIG_DEVPTS_MULTIPLE_INSTANCES=y
> CONFIG_LEGACY_PTYS=y
> CONFIG_LEGACY_PTY_COUNT=256
> CONFIG_SERIAL_NONSTANDARD=y
> # CONFIG_ROCKETPORT is not set
> # CONFIG_CYCLADES is not set
> CONFIG_MOXA_INTELLIO=y
> # CONFIG_MOXA_SMARTIO is not set
> CONFIG_SYNCLINK=y
> # CONFIG_SYNCLINKMP is not set
> # CONFIG_SYNCLINK_GT is not set
> CONFIG_NOZOMI=y
> # CONFIG_ISI is not set
> # CONFIG_N_HDLC is not set
> # CONFIG_N_GSM is not set
> # CONFIG_TRACE_ROUTER is not set
> CONFIG_TRACE_SINK=y
> # CONFIG_DEVKMEM is not set
> # CONFIG_STALDRV is not set
> 
> #
> # Serial drivers
> #
> CONFIG_SERIAL_8250=y
> # CONFIG_SERIAL_8250_CONSOLE is not set
> CONFIG_FIX_EARLYCON_MEM=y
> CONFIG_SERIAL_8250_PCI=y
> CONFIG_SERIAL_8250_PNP=y
> CONFIG_SERIAL_8250_NR_UARTS=4
> CONFIG_SERIAL_8250_RUNTIME_UARTS=4
> # CONFIG_SERIAL_8250_EXTENDED is not set
> 
> #
> # Non-8250 serial port support
> #
> CONFIG_SERIAL_MAX3100=y
> # CONFIG_SERIAL_MAX3107 is not set
> # CONFIG_SERIAL_MFD_HSU is not set
> # CONFIG_SERIAL_UARTLITE is not set
> CONFIG_SERIAL_CORE=y
> CONFIG_SERIAL_CORE_CONSOLE=y
> CONFIG_CONSOLE_POLL=y
> # CONFIG_SERIAL_JSM is not set
> CONFIG_SERIAL_TIMBERDALE=y
> # CONFIG_SERIAL_ALTERA_JTAGUART is not set
> CONFIG_SERIAL_ALTERA_UART=y
> CONFIG_SERIAL_ALTERA_UART_MAXPORTS=4
> CONFIG_SERIAL_ALTERA_UART_BAUDRATE=115200
> # CONFIG_SERIAL_ALTERA_UART_CONSOLE is not set
> CONFIG_SERIAL_IFX6X60=y
> CONFIG_SERIAL_PCH_UART=y
> # CONFIG_SERIAL_PCH_UART_CONSOLE is not set
> CONFIG_SERIAL_XILINX_PS_UART=y
> CONFIG_SERIAL_XILINX_PS_UART_CONSOLE=y
> CONFIG_HVC_DRIVER=y
> CONFIG_HVC_IRQ=y
> CONFIG_HVC_XEN=y
> # CONFIG_VIRTIO_CONSOLE is not set
> # CONFIG_IPMI_HANDLER is not set
> CONFIG_HW_RANDOM=y
> CONFIG_HW_RANDOM_TIMERIOMEM=y
> # CONFIG_HW_RANDOM_INTEL is not set
> CONFIG_HW_RANDOM_AMD=y
> # CONFIG_HW_RANDOM_VIA is not set
> # CONFIG_HW_RANDOM_VIRTIO is not set
> CONFIG_NVRAM=y
> CONFIG_R3964=y
> # CONFIG_APPLICOM is not set
> CONFIG_MWAVE=y
> # CONFIG_RAW_DRIVER is not set
> # CONFIG_HPET is not set
> # CONFIG_HANGCHECK_TIMER is not set
> # CONFIG_TCG_TPM is not set
> CONFIG_TELCLOCK=y
> CONFIG_DEVPORT=y
> CONFIG_RAMOOPS=y
> CONFIG_I2C=y
> CONFIG_I2C_BOARDINFO=y
> # CONFIG_I2C_COMPAT is not set
> # CONFIG_I2C_CHARDEV is not set
> # CONFIG_I2C_MUX is not set
> CONFIG_I2C_HELPER_AUTO=y
> CONFIG_I2C_SMBUS=y
> CONFIG_I2C_ALGOBIT=y
> 
> #
> # I2C Hardware Bus support
> #
> 
> #
> # PC SMBus host controller drivers
> #
> CONFIG_I2C_ALI1535=y
> # CONFIG_I2C_ALI1563 is not set
> CONFIG_I2C_ALI15X3=y
> CONFIG_I2C_AMD756=y
> # CONFIG_I2C_AMD756_S4882 is not set
> # CONFIG_I2C_AMD8111 is not set
> # CONFIG_I2C_I801 is not set
> # CONFIG_I2C_ISCH is not set
> # CONFIG_I2C_PIIX4 is not set
> CONFIG_I2C_NFORCE2=y
> # CONFIG_I2C_NFORCE2_S4985 is not set
> # CONFIG_I2C_SIS5595 is not set
> CONFIG_I2C_SIS630=y
> # CONFIG_I2C_SIS96X is not set
> CONFIG_I2C_VIA=y
> CONFIG_I2C_VIAPRO=y
> 
> #
> # ACPI drivers
> #
> CONFIG_I2C_SCMI=y
> 
> #
> # I2C system bus drivers (mostly embedded / system-on-chip)
> #
> # CONFIG_I2C_DESIGNWARE_PCI is not set
> CONFIG_I2C_GPIO=y
> CONFIG_I2C_INTEL_MID=y
> # CONFIG_I2C_OCORES is not set
> # CONFIG_I2C_PCA_PLATFORM is not set
> # CONFIG_I2C_PXA_PCI is not set
> # CONFIG_I2C_SIMTEC is not set
> CONFIG_I2C_XILINX=y
> # CONFIG_I2C_EG20T is not set
> 
> #
> # External I2C/SMBus adapter drivers
> #
> CONFIG_I2C_PARPORT_LIGHT=y
> CONFIG_I2C_TAOS_EVM=y
> 
> #
> # Other I2C/SMBus bus drivers
> #
> CONFIG_I2C_DEBUG_CORE=y
> # CONFIG_I2C_DEBUG_ALGO is not set
> CONFIG_I2C_DEBUG_BUS=y
> CONFIG_SPI=y
> CONFIG_SPI_DEBUG=y
> CONFIG_SPI_MASTER=y
> 
> #
> # SPI Master Controller Drivers
> #
> # CONFIG_SPI_ALTERA is not set
> CONFIG_SPI_BITBANG=y
> CONFIG_SPI_GPIO=y
> # CONFIG_SPI_OC_TINY is not set
> # CONFIG_SPI_PXA2XX_PCI is not set
> CONFIG_SPI_TOPCLIFF_PCH=y
> CONFIG_SPI_XILINX=y
> # CONFIG_SPI_DESIGNWARE is not set
> 
> #
> # SPI Protocol Masters
> #
> CONFIG_SPI_SPIDEV=y
> CONFIG_SPI_TLE62X0=y
> CONFIG_HSI=y
> CONFIG_HSI_BOARDINFO=y
> 
> #
> # HSI clients
> #
> # CONFIG_HSI_CHAR is not set
> 
> #
> # PPS support
> #
> CONFIG_PPS=y
> CONFIG_PPS_DEBUG=y
> 
> #
> # PPS clients support
> #
> CONFIG_PPS_CLIENT_KTIMER=y
> # CONFIG_PPS_CLIENT_LDISC is not set
> # CONFIG_PPS_CLIENT_GPIO is not set
> 
> #
> # PPS generators support
> #
> 
> #
> # PTP clock support
> #
> CONFIG_PTP_1588_CLOCK=y
> 
> #
> # Enable PHYLIB and NETWORK_PHY_TIMESTAMPING to see the additional clocks.
> #
> CONFIG_ARCH_WANT_OPTIONAL_GPIOLIB=y
> CONFIG_GPIOLIB=y
> CONFIG_DEBUG_GPIO=y
> CONFIG_GPIO_SYSFS=y
> CONFIG_GPIO_MAX730X=y
> 
> #
> # Memory mapped GPIO drivers:
> #
> # CONFIG_GPIO_GENERIC_PLATFORM is not set
> CONFIG_GPIO_IT8761E=y
> CONFIG_GPIO_SCH=y
> CONFIG_GPIO_VX855=y
> 
> #
> # I2C GPIO expanders:
> #
> CONFIG_GPIO_MAX7300=y
> CONFIG_GPIO_MAX732X=y
> # CONFIG_GPIO_MAX732X_IRQ is not set
> CONFIG_GPIO_PCA953X=y
> # CONFIG_GPIO_PCA953X_IRQ is not set
> # CONFIG_GPIO_PCF857X is not set
> # CONFIG_GPIO_SX150X is not set
> CONFIG_GPIO_TC3589X=y
> # CONFIG_GPIO_WM831X is not set
> CONFIG_GPIO_WM8350=y
> # CONFIG_GPIO_WM8994 is not set
> CONFIG_GPIO_ADP5588=y
> CONFIG_GPIO_ADP5588_IRQ=y
> 
> #
> # PCI GPIO expanders:
> #
> # CONFIG_GPIO_BT8XX is not set
> CONFIG_GPIO_LANGWELL=y
> CONFIG_GPIO_PCH=y
> CONFIG_GPIO_ML_IOH=y
> CONFIG_GPIO_TIMBERDALE=y
> CONFIG_GPIO_RDC321X=y
> 
> #
> # SPI GPIO expanders:
> #
> # CONFIG_GPIO_MAX7301 is not set
> # CONFIG_GPIO_MCP23S08 is not set
> CONFIG_GPIO_MC33880=y
> CONFIG_GPIO_74X164=y
> 
> #
> # AC97 GPIO expanders:
> #
> 
> #
> # MODULbus GPIO expanders:
> #
> CONFIG_GPIO_TPS65910=y
> # CONFIG_W1 is not set
> CONFIG_POWER_SUPPLY=y
> # CONFIG_POWER_SUPPLY_DEBUG is not set
> CONFIG_PDA_POWER=y
> # CONFIG_WM831X_BACKUP is not set
> CONFIG_WM831X_POWER=y
> # CONFIG_WM8350_POWER is not set
> CONFIG_TEST_POWER=y
> # CONFIG_BATTERY_DS2780 is not set
> CONFIG_BATTERY_DS2782=y
> CONFIG_BATTERY_BQ20Z75=y
> # CONFIG_BATTERY_BQ27x00 is not set
> CONFIG_BATTERY_MAX17040=y
> # CONFIG_BATTERY_MAX17042 is not set
> # CONFIG_CHARGER_MAX8903 is not set
> CONFIG_CHARGER_GPIO=y
> CONFIG_CHARGER_MAX8998=y
> CONFIG_HWMON=y
> CONFIG_HWMON_VID=y
> CONFIG_HWMON_DEBUG_CHIP=y
> 
> #
> # Native drivers
> #
> # CONFIG_SENSORS_ABITUGURU is not set
> # CONFIG_SENSORS_ABITUGURU3 is not set
> CONFIG_SENSORS_AD7314=y
> CONFIG_SENSORS_AD7414=y
> CONFIG_SENSORS_AD7418=y
> CONFIG_SENSORS_ADCXX=y
> # CONFIG_SENSORS_ADM1021 is not set
> # CONFIG_SENSORS_ADM1025 is not set
> CONFIG_SENSORS_ADM1026=y
> CONFIG_SENSORS_ADM1029=y
> CONFIG_SENSORS_ADM1031=y
> # CONFIG_SENSORS_ADM9240 is not set
> CONFIG_SENSORS_ADT7411=y
> CONFIG_SENSORS_ADT7462=y
> CONFIG_SENSORS_ADT7470=y
> CONFIG_SENSORS_ADT7475=y
> # CONFIG_SENSORS_ASC7621 is not set
> # CONFIG_SENSORS_K8TEMP is not set
> CONFIG_SENSORS_K10TEMP=y
> # CONFIG_SENSORS_FAM15H_POWER is not set
> CONFIG_SENSORS_ASB100=y
> # CONFIG_SENSORS_ATXP1 is not set
> CONFIG_SENSORS_DS620=y
> CONFIG_SENSORS_DS1621=y
> CONFIG_SENSORS_I5K_AMB=y
> CONFIG_SENSORS_F71805F=y
> # CONFIG_SENSORS_F71882FG is not set
> CONFIG_SENSORS_F75375S=y
> CONFIG_SENSORS_FSCHMD=y
> CONFIG_SENSORS_G760A=y
> # CONFIG_SENSORS_GL518SM is not set
> # CONFIG_SENSORS_GL520SM is not set
> CONFIG_SENSORS_GPIO_FAN=y
> CONFIG_SENSORS_CORETEMP=y
> CONFIG_SENSORS_IT87=y
> CONFIG_SENSORS_JC42=y
> CONFIG_SENSORS_LINEAGE=y
> # CONFIG_SENSORS_LM63 is not set
> # CONFIG_SENSORS_LM70 is not set
> CONFIG_SENSORS_LM73=y
> # CONFIG_SENSORS_LM75 is not set
> CONFIG_SENSORS_LM77=y
> CONFIG_SENSORS_LM78=y
> CONFIG_SENSORS_LM80=y
> # CONFIG_SENSORS_LM83 is not set
> CONFIG_SENSORS_LM85=y
> CONFIG_SENSORS_LM87=y
> # CONFIG_SENSORS_LM90 is not set
> # CONFIG_SENSORS_LM92 is not set
> CONFIG_SENSORS_LM93=y
> CONFIG_SENSORS_LTC4151=y
> # CONFIG_SENSORS_LTC4215 is not set
> CONFIG_SENSORS_LTC4245=y
> # CONFIG_SENSORS_LTC4261 is not set
> # CONFIG_SENSORS_LM95241 is not set
> # CONFIG_SENSORS_LM95245 is not set
> # CONFIG_SENSORS_MAX1111 is not set
> # CONFIG_SENSORS_MAX16065 is not set
> CONFIG_SENSORS_MAX1619=y
> CONFIG_SENSORS_MAX1668=y
> CONFIG_SENSORS_MAX6639=y
> CONFIG_SENSORS_MAX6642=y
> # CONFIG_SENSORS_MAX6650 is not set
> # CONFIG_SENSORS_NTC_THERMISTOR is not set
> CONFIG_SENSORS_PC87360=y
> # CONFIG_SENSORS_PC87427 is not set
> CONFIG_SENSORS_PCF8591=y
> CONFIG_PMBUS=y
> CONFIG_SENSORS_PMBUS=y
> # CONFIG_SENSORS_ADM1275 is not set
> # CONFIG_SENSORS_LM25066 is not set
> # CONFIG_SENSORS_LTC2978 is not set
> # CONFIG_SENSORS_MAX16064 is not set
> # CONFIG_SENSORS_MAX34440 is not set
> # CONFIG_SENSORS_MAX8688 is not set
> # CONFIG_SENSORS_UCD9000 is not set
> # CONFIG_SENSORS_UCD9200 is not set
> CONFIG_SENSORS_ZL6100=y
> # CONFIG_SENSORS_SHT15 is not set
> # CONFIG_SENSORS_SHT21 is not set
> CONFIG_SENSORS_SIS5595=y
> # CONFIG_SENSORS_SMM665 is not set
> CONFIG_SENSORS_DME1737=y
> # CONFIG_SENSORS_EMC1403 is not set
> # CONFIG_SENSORS_EMC2103 is not set
> # CONFIG_SENSORS_EMC6W201 is not set
> CONFIG_SENSORS_SMSC47M1=y
> CONFIG_SENSORS_SMSC47M192=y
> # CONFIG_SENSORS_SMSC47B397 is not set
> # CONFIG_SENSORS_SCH56XX_COMMON is not set
> # CONFIG_SENSORS_SCH5627 is not set
> # CONFIG_SENSORS_SCH5636 is not set
> # CONFIG_SENSORS_ADS1015 is not set
> # CONFIG_SENSORS_ADS7828 is not set
> CONFIG_SENSORS_ADS7871=y
> CONFIG_SENSORS_AMC6821=y
> # CONFIG_SENSORS_THMC50 is not set
> # CONFIG_SENSORS_TMP102 is not set
> # CONFIG_SENSORS_TMP401 is not set
> CONFIG_SENSORS_TMP421=y
> # CONFIG_SENSORS_VIA_CPUTEMP is not set
> CONFIG_SENSORS_VIA686A=y
> CONFIG_SENSORS_VT1211=y
> # CONFIG_SENSORS_VT8231 is not set
> CONFIG_SENSORS_W83781D=y
> # CONFIG_SENSORS_W83791D is not set
> # CONFIG_SENSORS_W83792D is not set
> CONFIG_SENSORS_W83793=y
> CONFIG_SENSORS_W83795=y
> CONFIG_SENSORS_W83795_FANCTRL=y
> CONFIG_SENSORS_W83L785TS=y
> CONFIG_SENSORS_W83L786NG=y
> CONFIG_SENSORS_W83627HF=y
> # CONFIG_SENSORS_W83627EHF is not set
> CONFIG_SENSORS_WM831X=y
> CONFIG_SENSORS_WM8350=y
> CONFIG_SENSORS_APPLESMC=y
> 
> #
> # ACPI drivers
> #
> # CONFIG_SENSORS_ACPI_POWER is not set
> CONFIG_SENSORS_ATK0110=y
> CONFIG_THERMAL=y
> CONFIG_THERMAL_HWMON=y
> # CONFIG_WATCHDOG is not set
> CONFIG_SSB_POSSIBLE=y
> 
> #
> # Sonics Silicon Backplane
> #
> # CONFIG_SSB is not set
> CONFIG_BCMA_POSSIBLE=y
> 
> #
> # Broadcom specific AMBA
> #
> # CONFIG_BCMA is not set
> 
> #
> # Multifunction device drivers
> #
> CONFIG_MFD_CORE=y
> CONFIG_MFD_88PM860X=y
> CONFIG_MFD_SM501=y
> # CONFIG_MFD_SM501_GPIO is not set
> CONFIG_HTC_PASIC3=y
> CONFIG_HTC_I2CPLD=y
> CONFIG_TPS6105X=y
> CONFIG_TPS65010=y
> # CONFIG_TPS6507X is not set
> CONFIG_MFD_TPS6586X=y
> CONFIG_MFD_TPS65910=y
> # CONFIG_MFD_TPS65912_I2C is not set
> # CONFIG_MFD_TPS65912_SPI is not set
> # CONFIG_TWL4030_CORE is not set
> # CONFIG_MFD_STMPE is not set
> CONFIG_MFD_TC3589X=y
> # CONFIG_MFD_TMIO is not set
> # CONFIG_PMIC_DA903X is not set
> CONFIG_PMIC_DA9052=y
> CONFIG_MFD_DA9052_SPI=y
> CONFIG_MFD_DA9052_I2C=y
> # CONFIG_PMIC_ADP5520 is not set
> # CONFIG_MFD_MAX8925 is not set
> # CONFIG_MFD_MAX8997 is not set
> CONFIG_MFD_MAX8998=y
> # CONFIG_MFD_WM8400 is not set
> CONFIG_MFD_WM831X=y
> CONFIG_MFD_WM831X_I2C=y
> CONFIG_MFD_WM831X_SPI=y
> CONFIG_MFD_WM8350=y
> CONFIG_MFD_WM8350_I2C=y
> CONFIG_MFD_WM8994=y
> # CONFIG_MFD_PCF50633 is not set
> # CONFIG_MFD_MC13XXX is not set
> # CONFIG_ABX500_CORE is not set
> CONFIG_EZX_PCAP=y
> # CONFIG_MFD_CS5535 is not set
> CONFIG_MFD_TIMBERDALE=y
> CONFIG_LPC_SCH=y
> CONFIG_MFD_RDC321X=y
> # CONFIG_MFD_JANZ_CMODIO is not set
> CONFIG_MFD_VX855=y
> CONFIG_MFD_WL1273_CORE=y
> # CONFIG_MFD_AAT2870_CORE is not set
> CONFIG_REGULATOR=y
> CONFIG_REGULATOR_DEBUG=y
> CONFIG_REGULATOR_DUMMY=y
> CONFIG_REGULATOR_FIXED_VOLTAGE=y
> CONFIG_REGULATOR_VIRTUAL_CONSUMER=y
> # CONFIG_REGULATOR_USERSPACE_CONSUMER is not set
> CONFIG_REGULATOR_GPIO=y
> CONFIG_REGULATOR_BQ24022=y
> # CONFIG_REGULATOR_MAX1586 is not set
> # CONFIG_REGULATOR_MAX8649 is not set
> # CONFIG_REGULATOR_MAX8660 is not set
> CONFIG_REGULATOR_MAX8952=y
> CONFIG_REGULATOR_MAX8998=y
> CONFIG_REGULATOR_WM831X=y
> CONFIG_REGULATOR_WM8350=y
> # CONFIG_REGULATOR_WM8994 is not set
> # CONFIG_REGULATOR_DA9052 is not set
> # CONFIG_REGULATOR_LP3971 is not set
> # CONFIG_REGULATOR_LP3972 is not set
> CONFIG_REGULATOR_PCAP=y
> # CONFIG_REGULATOR_TPS6105X is not set
> CONFIG_REGULATOR_TPS65023=y
> # CONFIG_REGULATOR_TPS6507X is not set
> # CONFIG_REGULATOR_88PM8607 is not set
> CONFIG_REGULATOR_ISL6271A=y
> CONFIG_REGULATOR_AD5398=y
> # CONFIG_REGULATOR_TPS6586X is not set
> CONFIG_REGULATOR_TPS6524X=y
> CONFIG_REGULATOR_TPS65910=y
> # CONFIG_MEDIA_SUPPORT is not set
> 
> #
> # Graphics support
> #
> CONFIG_AGP=y
> CONFIG_AGP_AMD64=y
> CONFIG_AGP_INTEL=y
> CONFIG_AGP_SIS=y
> CONFIG_AGP_VIA=y
> CONFIG_VGA_ARB=y
> CONFIG_VGA_ARB_MAX_GPUS=16
> CONFIG_VGA_SWITCHEROO=y
> CONFIG_DRM=y
> CONFIG_DRM_KMS_HELPER=y
> CONFIG_DRM_TTM=y
> CONFIG_DRM_TDFX=y
> # CONFIG_DRM_R128 is not set
> CONFIG_DRM_RADEON=y
> # CONFIG_DRM_RADEON_KMS is not set
> CONFIG_DRM_I915=y
> CONFIG_DRM_I915_KMS=y
> # CONFIG_DRM_MGA is not set
> # CONFIG_DRM_SIS is not set
> CONFIG_DRM_VIA=y
> CONFIG_DRM_SAVAGE=y
> # CONFIG_DRM_VMWGFX is not set
> # CONFIG_DRM_GMA500 is not set
> # CONFIG_STUB_POULSBO is not set
> CONFIG_VGASTATE=y
> CONFIG_VIDEO_OUTPUT_CONTROL=y
> CONFIG_FB=y
> # CONFIG_FIRMWARE_EDID is not set
> # CONFIG_FB_DDC is not set
> CONFIG_FB_BOOT_VESA_SUPPORT=y
> CONFIG_FB_CFB_FILLRECT=y
> CONFIG_FB_CFB_COPYAREA=y
> CONFIG_FB_CFB_IMAGEBLIT=y
> # CONFIG_FB_CFB_REV_PIXELS_IN_BYTE is not set
> CONFIG_FB_SYS_FILLRECT=y
> CONFIG_FB_SYS_COPYAREA=y
> CONFIG_FB_SYS_IMAGEBLIT=y
> # CONFIG_FB_FOREIGN_ENDIAN is not set
> CONFIG_FB_SYS_FOPS=y
> # CONFIG_FB_WMT_GE_ROPS is not set
> CONFIG_FB_DEFERRED_IO=y
> CONFIG_FB_SVGALIB=y
> # CONFIG_FB_MACMODES is not set
> # CONFIG_FB_BACKLIGHT is not set
> CONFIG_FB_MODE_HELPERS=y
> CONFIG_FB_TILEBLITTING=y
> 
> #
> # Frame buffer hardware drivers
> #
> CONFIG_FB_CIRRUS=y
> CONFIG_FB_PM2=y
> CONFIG_FB_PM2_FIFO_DISCONNECT=y
> # CONFIG_FB_CYBER2000 is not set
> # CONFIG_FB_ARC is not set
> CONFIG_FB_ASILIANT=y
> CONFIG_FB_IMSTT=y
> # CONFIG_FB_VGA16 is not set
> CONFIG_FB_UVESA=y
> CONFIG_FB_VESA=y
> # CONFIG_FB_EFI is not set
> # CONFIG_FB_N411 is not set
> CONFIG_FB_HGA=y
> # CONFIG_FB_S1D13XXX is not set
> # CONFIG_FB_NVIDIA is not set
> # CONFIG_FB_RIVA is not set
> CONFIG_FB_LE80578=y
> # CONFIG_FB_CARILLO_RANCH is not set
> # CONFIG_FB_MATROX is not set
> # CONFIG_FB_RADEON is not set
> # CONFIG_FB_ATY128 is not set
> CONFIG_FB_ATY=y
> # CONFIG_FB_ATY_CT is not set
> CONFIG_FB_ATY_GX=y
> # CONFIG_FB_ATY_BACKLIGHT is not set
> # CONFIG_FB_S3 is not set
> CONFIG_FB_SAVAGE=y
> # CONFIG_FB_SAVAGE_I2C is not set
> # CONFIG_FB_SAVAGE_ACCEL is not set
> CONFIG_FB_SIS=y
> CONFIG_FB_SIS_300=y
> # CONFIG_FB_SIS_315 is not set
> CONFIG_FB_VIA=y
> # CONFIG_FB_VIA_DIRECT_PROCFS is not set
> CONFIG_FB_VIA_X_COMPATIBILITY=y
> CONFIG_FB_NEOMAGIC=y
> # CONFIG_FB_KYRO is not set
> CONFIG_FB_3DFX=y
> # CONFIG_FB_3DFX_ACCEL is not set
> # CONFIG_FB_3DFX_I2C is not set
> CONFIG_FB_VOODOO1=y
> CONFIG_FB_VT8623=y
> CONFIG_FB_TRIDENT=y
> CONFIG_FB_ARK=y
> CONFIG_FB_PM3=y
> CONFIG_FB_CARMINE=y
> # CONFIG_FB_CARMINE_DRAM_EVAL is not set
> CONFIG_CARMINE_DRAM_CUSTOM=y
> # CONFIG_FB_GEODE is not set
> # CONFIG_FB_TMIO is not set
> # CONFIG_FB_SM501 is not set
> # CONFIG_FB_VIRTUAL is not set
> # CONFIG_XEN_FBDEV_FRONTEND is not set
> # CONFIG_FB_METRONOME is not set
> CONFIG_FB_MB862XX=y
> CONFIG_FB_MB862XX_PCI_GDC=y
> # CONFIG_FB_MB862XX_I2C is not set
> CONFIG_FB_BROADSHEET=y
> CONFIG_BACKLIGHT_LCD_SUPPORT=y
> # CONFIG_LCD_CLASS_DEVICE is not set
> CONFIG_BACKLIGHT_CLASS_DEVICE=y
> # CONFIG_BACKLIGHT_GENERIC is not set
> # CONFIG_BACKLIGHT_PROGEAR is not set
> # CONFIG_BACKLIGHT_APPLE is not set
> CONFIG_BACKLIGHT_SAHARA=y
> CONFIG_BACKLIGHT_WM831X=y
> CONFIG_BACKLIGHT_ADP8860=y
> CONFIG_BACKLIGHT_ADP8870=y
> # CONFIG_BACKLIGHT_88PM860X is not set
> 
> #
> # Console display driver support
> #
> CONFIG_VGA_CONSOLE=y
> CONFIG_VGACON_SOFT_SCROLLBACK=y
> CONFIG_VGACON_SOFT_SCROLLBACK_SIZE=64
> CONFIG_DUMMY_CONSOLE=y
> CONFIG_FRAMEBUFFER_CONSOLE=y
> CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY=y
> CONFIG_FRAMEBUFFER_CONSOLE_ROTATION=y
> # CONFIG_FONTS is not set
> CONFIG_FONT_8x8=y
> CONFIG_FONT_8x16=y
> CONFIG_LOGO=y
> CONFIG_LOGO_LINUX_MONO=y
> # CONFIG_LOGO_LINUX_VGA16 is not set
> CONFIG_LOGO_LINUX_CLUT224=y
> # CONFIG_SOUND is not set
> CONFIG_HID_SUPPORT=y
> # CONFIG_HID is not set
> CONFIG_HID_PID=y
> # CONFIG_USB_SUPPORT is not set
> CONFIG_UWB=y
> CONFIG_UWB_WHCI=y
> # CONFIG_MMC is not set
> CONFIG_MEMSTICK=y
> # CONFIG_MEMSTICK_DEBUG is not set
> 
> #
> # MemoryStick drivers
> #
> # CONFIG_MEMSTICK_UNSAFE_RESUME is not set
> # CONFIG_MSPRO_BLOCK is not set
> 
> #
> # MemoryStick Host Controller Drivers
> #
> # CONFIG_MEMSTICK_TIFM_MS is not set
> CONFIG_MEMSTICK_JMICRON_38X=y
> CONFIG_MEMSTICK_R592=y
> CONFIG_NEW_LEDS=y
> CONFIG_LEDS_CLASS=y
> 
> #
> # LED drivers
> #
> CONFIG_LEDS_88PM860X=y
> CONFIG_LEDS_LM3530=y
> CONFIG_LEDS_PCA9532=y
> CONFIG_LEDS_PCA9532_GPIO=y
> # CONFIG_LEDS_GPIO is not set
> # CONFIG_LEDS_LP3944 is not set
> # CONFIG_LEDS_LP5521 is not set
> CONFIG_LEDS_LP5523=y
> # CONFIG_LEDS_CLEVO_MAIL is not set
> # CONFIG_LEDS_PCA955X is not set
> CONFIG_LEDS_WM831X_STATUS=y
> CONFIG_LEDS_WM8350=y
> # CONFIG_LEDS_DAC124S085 is not set
> CONFIG_LEDS_REGULATOR=y
> CONFIG_LEDS_BD2802=y
> CONFIG_LEDS_INTEL_SS4200=y
> # CONFIG_LEDS_LT3593 is not set
> CONFIG_LEDS_TCA6507=y
> # CONFIG_LEDS_TRIGGERS is not set
> 
> #
> # LED Triggers
> #
> CONFIG_ACCESSIBILITY=y
> CONFIG_A11Y_BRAILLE_CONSOLE=y
> # CONFIG_INFINIBAND is not set
> # CONFIG_EDAC is not set
> CONFIG_RTC_LIB=y
> CONFIG_RTC_CLASS=y
> # CONFIG_RTC_HCTOSYS is not set
> CONFIG_RTC_DEBUG=y
> 
> #
> # RTC interfaces
> #
> CONFIG_RTC_INTF_SYSFS=y
> # CONFIG_RTC_INTF_PROC is not set
> # CONFIG_RTC_INTF_DEV is not set
> CONFIG_RTC_DRV_TEST=y
> 
> #
> # I2C RTC drivers
> #
> CONFIG_RTC_DRV_88PM860X=y
> CONFIG_RTC_DRV_DS1307=y
> CONFIG_RTC_DRV_DS1374=y
> # CONFIG_RTC_DRV_DS1672 is not set
> # CONFIG_RTC_DRV_DS3232 is not set
> CONFIG_RTC_DRV_MAX6900=y
> CONFIG_RTC_DRV_MAX8998=y
> # CONFIG_RTC_DRV_RS5C372 is not set
> CONFIG_RTC_DRV_ISL1208=y
> # CONFIG_RTC_DRV_ISL12022 is not set
> CONFIG_RTC_DRV_X1205=y
> CONFIG_RTC_DRV_PCF8563=y
> # CONFIG_RTC_DRV_PCF8583 is not set
> CONFIG_RTC_DRV_M41T80=y
> # CONFIG_RTC_DRV_M41T80_WDT is not set
> CONFIG_RTC_DRV_BQ32K=y
> CONFIG_RTC_DRV_S35390A=y
> # CONFIG_RTC_DRV_FM3130 is not set
> # CONFIG_RTC_DRV_RX8581 is not set
> # CONFIG_RTC_DRV_RX8025 is not set
> # CONFIG_RTC_DRV_EM3027 is not set
> # CONFIG_RTC_DRV_RV3029C2 is not set
> 
> #
> # SPI RTC drivers
> #
> # CONFIG_RTC_DRV_M41T93 is not set
> # CONFIG_RTC_DRV_M41T94 is not set
> # CONFIG_RTC_DRV_DS1305 is not set
> CONFIG_RTC_DRV_DS1390=y
> CONFIG_RTC_DRV_MAX6902=y
> # CONFIG_RTC_DRV_R9701 is not set
> # CONFIG_RTC_DRV_RS5C348 is not set
> CONFIG_RTC_DRV_DS3234=y
> CONFIG_RTC_DRV_PCF2123=y
> 
> #
> # Platform RTC drivers
> #
> CONFIG_RTC_DRV_CMOS=y
> # CONFIG_RTC_DRV_DS1286 is not set
> CONFIG_RTC_DRV_DS1511=y
> CONFIG_RTC_DRV_DS1553=y
> # CONFIG_RTC_DRV_DS1742 is not set
> CONFIG_RTC_DRV_STK17TA8=y
> CONFIG_RTC_DRV_M48T86=y
> CONFIG_RTC_DRV_M48T35=y
> CONFIG_RTC_DRV_M48T59=y
> # CONFIG_RTC_DRV_MSM6242 is not set
> # CONFIG_RTC_DRV_BQ4802 is not set
> CONFIG_RTC_DRV_RP5C01=y
> CONFIG_RTC_DRV_V3020=y
> CONFIG_RTC_DRV_WM831X=y
> # CONFIG_RTC_DRV_WM8350 is not set
> 
> #
> # on-CPU RTC drivers
> #
> CONFIG_RTC_DRV_PCAP=y
> CONFIG_DMADEVICES=y
> CONFIG_DMADEVICES_DEBUG=y
> # CONFIG_DMADEVICES_VDEBUG is not set
> 
> #
> # DMA Devices
> #
> # CONFIG_INTEL_MID_DMAC is not set
> # CONFIG_INTEL_IOATDMA is not set
> # CONFIG_TIMB_DMA is not set
> # CONFIG_PCH_DMA is not set
> # CONFIG_AUXDISPLAY is not set
> CONFIG_UIO=y
> # CONFIG_UIO_CIF is not set
> CONFIG_UIO_PDRV=y
> # CONFIG_UIO_PDRV_GENIRQ is not set
> CONFIG_UIO_AEC=y
> CONFIG_UIO_SERCOS3=y
> CONFIG_UIO_PCI_GENERIC=y
> CONFIG_UIO_NETX=y
> CONFIG_VIRTIO=y
> CONFIG_VIRTIO_RING=y
> 
> #
> # Virtio drivers
> #
> # CONFIG_VIRTIO_PCI is not set
> # CONFIG_VIRTIO_BALLOON is not set
> CONFIG_VIRTIO_MMIO=y
> 
> #
> # Microsoft Hyper-V guest support
> #
> # CONFIG_HYPERV is not set
> 
> #
> # Xen driver support
> #
> # CONFIG_XEN_BALLOON is not set
> # CONFIG_XEN_DEV_EVTCHN is not set
> CONFIG_XEN_BACKEND=y
> # CONFIG_XENFS is not set
> CONFIG_XEN_SYS_HYPERVISOR=y
> CONFIG_XEN_XENBUS_FRONTEND=y
> CONFIG_XEN_GNTDEV=y
> # CONFIG_XEN_GRANT_DEV_ALLOC is not set
> CONFIG_SWIOTLB_XEN=y
> CONFIG_XEN_TMEM=y
> # CONFIG_XEN_PCIDEV_BACKEND is not set
> CONFIG_XEN_PRIVCMD=y
> # CONFIG_STAGING is not set
> CONFIG_X86_PLATFORM_DEVICES=y
> # CONFIG_ACERHDF is not set
> CONFIG_DELL_LAPTOP=y
> # CONFIG_FUJITSU_LAPTOP is not set
> # CONFIG_HP_ACCEL is not set
> CONFIG_PANASONIC_LAPTOP=y
> # CONFIG_THINKPAD_ACPI is not set
> # CONFIG_SENSORS_HDAPS is not set
> CONFIG_EEEPC_LAPTOP=y
> # CONFIG_ACPI_WMI is not set
> CONFIG_ACPI_ASUS=y
> # CONFIG_TOPSTAR_LAPTOP is not set
> # CONFIG_ACPI_TOSHIBA is not set
> CONFIG_TOSHIBA_BT_RFKILL=y
> CONFIG_ACPI_CMPC=y
> # CONFIG_INTEL_IPS is not set
> CONFIG_IBM_RTL=y
> # CONFIG_XO15_EBOOK is not set
> CONFIG_SAMSUNG_Q10=y
> 
> #
> # Hardware Spinlock drivers
> #
> CONFIG_CLKEVT_I8253=y
> CONFIG_I8253_LOCK=y
> CONFIG_CLKBLD_I8253=y
> CONFIG_IOMMU_SUPPORT=y
> # CONFIG_AMD_IOMMU is not set
> CONFIG_VIRT_DRIVERS=y
> # CONFIG_PM_DEVFREQ is not set
> # CONFIG_XSHM is not set
> 
> #
> # Firmware Drivers
> #
> # CONFIG_EDD is not set
> CONFIG_FIRMWARE_MEMMAP=y
> CONFIG_EFI_VARS=y
> # CONFIG_DELL_RBU is not set
> CONFIG_DCDBAS=y
> # CONFIG_DMIID is not set
> # CONFIG_DMI_SYSFS is not set
> CONFIG_ISCSI_IBFT_FIND=y
> # CONFIG_ISCSI_IBFT is not set
> CONFIG_GOOGLE_FIRMWARE=y
> 
> #
> # Google Firmware Drivers
> #
> CONFIG_GOOGLE_SMI=y
> # CONFIG_GOOGLE_MEMCONSOLE is not set
> 
> #
> # File systems
> #
> CONFIG_EXT2_FS=y
> CONFIG_EXT2_FS_XATTR=y
> CONFIG_EXT2_FS_POSIX_ACL=y
> # CONFIG_EXT2_FS_SECURITY is not set
> CONFIG_EXT2_FS_XIP=y
> # CONFIG_EXT3_FS is not set
> # CONFIG_EXT4_FS is not set
> CONFIG_FS_XIP=y
> CONFIG_FS_MBCACHE=y
> # CONFIG_REISERFS_FS is not set
> # CONFIG_JFS_FS is not set
> CONFIG_XFS_FS=y
> CONFIG_XFS_QUOTA=y
> CONFIG_XFS_POSIX_ACL=y
> # CONFIG_XFS_RT is not set
> CONFIG_XFS_DEBUG=y
> # CONFIG_GFS2_FS is not set
> # CONFIG_OCFS2_FS is not set
> # CONFIG_BTRFS_FS is not set
> # CONFIG_NILFS2_FS is not set
> CONFIG_FS_POSIX_ACL=y
> CONFIG_EXPORTFS=y
> CONFIG_FILE_LOCKING=y
> CONFIG_FSNOTIFY=y
> CONFIG_DNOTIFY=y
> # CONFIG_INOTIFY_USER is not set
> # CONFIG_FANOTIFY is not set
> CONFIG_QUOTA=y
> # CONFIG_QUOTA_NETLINK_INTERFACE is not set
> # CONFIG_PRINT_QUOTA_WARNING is not set
> CONFIG_QUOTA_DEBUG=y
> CONFIG_QUOTA_TREE=y
> CONFIG_QFMT_V1=y
> CONFIG_QFMT_V2=y
> CONFIG_QUOTACTL=y
> CONFIG_QUOTACTL_COMPAT=y
> CONFIG_AUTOFS4_FS=y
> # CONFIG_FUSE_FS is not set
> 
> #
> # Caches
> #
> # CONFIG_FSCACHE is not set
> 
> #
> # CD-ROM/DVD Filesystems
> #
> CONFIG_ISO9660_FS=y
> CONFIG_JOLIET=y
> # CONFIG_ZISOFS is not set
> CONFIG_UDF_FS=y
> CONFIG_UDF_NLS=y
> 
> #
> # DOS/FAT/NT Filesystems
> #
> CONFIG_FAT_FS=y
> CONFIG_MSDOS_FS=y
> CONFIG_VFAT_FS=y
> CONFIG_FAT_DEFAULT_CODEPAGE=437
> CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1"
> CONFIG_NTFS_FS=y
> # CONFIG_NTFS_DEBUG is not set
> CONFIG_NTFS_RW=y
> 
> #
> # Pseudo filesystems
> #
> CONFIG_PROC_FS=y
> CONFIG_PROC_KCORE=y
> CONFIG_PROC_SYSCTL=y
> CONFIG_PROC_PAGE_MONITOR=y
> CONFIG_SYSFS=y
> CONFIG_TMPFS=y
> # CONFIG_TMPFS_POSIX_ACL is not set
> # CONFIG_TMPFS_XATTR is not set
> # CONFIG_HUGETLBFS is not set
> # CONFIG_HUGETLB_PAGE is not set
> CONFIG_CONFIGFS_FS=y
> CONFIG_MISC_FILESYSTEMS=y
> # CONFIG_ADFS_FS is not set
> CONFIG_AFFS_FS=y
> CONFIG_ECRYPT_FS=y
> CONFIG_HFS_FS=y
> # CONFIG_HFSPLUS_FS is not set
> # CONFIG_BEFS_FS is not set
> # CONFIG_BFS_FS is not set
> # CONFIG_EFS_FS is not set
> # CONFIG_JFFS2_FS is not set
> CONFIG_UBIFS_FS=y
> # CONFIG_UBIFS_FS_XATTR is not set
> # CONFIG_UBIFS_FS_ADVANCED_COMPR is not set
> CONFIG_UBIFS_FS_LZO=y
> CONFIG_UBIFS_FS_ZLIB=y
> CONFIG_UBIFS_FS_DEBUG=y
> # CONFIG_LOGFS is not set
> CONFIG_CRAMFS=y
> # CONFIG_SQUASHFS is not set
> # CONFIG_VXFS_FS is not set
> CONFIG_MINIX_FS=y
> # CONFIG_OMFS_FS is not set
> # CONFIG_HPFS_FS is not set
> CONFIG_QNX4FS_FS=y
> # CONFIG_ROMFS_FS is not set
> CONFIG_PSTORE=y
> # CONFIG_SYSV_FS is not set
> CONFIG_UFS_FS=y
> CONFIG_UFS_FS_WRITE=y
> CONFIG_UFS_DEBUG=y
> CONFIG_ORE=y
> CONFIG_EXOFS_FS=y
> CONFIG_EXOFS_DEBUG=y
> # CONFIG_NETWORK_FILESYSTEMS is not set
> 
> #
> # Partition Types
> #
> CONFIG_PARTITION_ADVANCED=y
> CONFIG_ACORN_PARTITION=y
> CONFIG_ACORN_PARTITION_CUMANA=y
> # CONFIG_ACORN_PARTITION_EESOX is not set
> # CONFIG_ACORN_PARTITION_ICS is not set
> CONFIG_ACORN_PARTITION_ADFS=y
> CONFIG_ACORN_PARTITION_POWERTEC=y
> # CONFIG_ACORN_PARTITION_RISCIX is not set
> CONFIG_OSF_PARTITION=y
> CONFIG_AMIGA_PARTITION=y
> CONFIG_ATARI_PARTITION=y
> CONFIG_MAC_PARTITION=y
> CONFIG_MSDOS_PARTITION=y
> # CONFIG_BSD_DISKLABEL is not set
> CONFIG_MINIX_SUBPARTITION=y
> # CONFIG_SOLARIS_X86_PARTITION is not set
> CONFIG_UNIXWARE_DISKLABEL=y
> # CONFIG_LDM_PARTITION is not set
> CONFIG_SGI_PARTITION=y
> # CONFIG_ULTRIX_PARTITION is not set
> # CONFIG_SUN_PARTITION is not set
> CONFIG_KARMA_PARTITION=y
> CONFIG_EFI_PARTITION=y
> # CONFIG_SYSV68_PARTITION is not set
> CONFIG_NLS=y
> CONFIG_NLS_DEFAULT="iso8859-1"
> # CONFIG_NLS_CODEPAGE_437 is not set
> CONFIG_NLS_CODEPAGE_737=y
> CONFIG_NLS_CODEPAGE_775=y
> # CONFIG_NLS_CODEPAGE_850 is not set
> # CONFIG_NLS_CODEPAGE_852 is not set
> # CONFIG_NLS_CODEPAGE_855 is not set
> CONFIG_NLS_CODEPAGE_857=y
> CONFIG_NLS_CODEPAGE_860=y
> CONFIG_NLS_CODEPAGE_861=y
> CONFIG_NLS_CODEPAGE_862=y
> # CONFIG_NLS_CODEPAGE_863 is not set
> # CONFIG_NLS_CODEPAGE_864 is not set
> # CONFIG_NLS_CODEPAGE_865 is not set
> CONFIG_NLS_CODEPAGE_866=y
> CONFIG_NLS_CODEPAGE_869=y
> # CONFIG_NLS_CODEPAGE_936 is not set
> # CONFIG_NLS_CODEPAGE_950 is not set
> # CONFIG_NLS_CODEPAGE_932 is not set
> # CONFIG_NLS_CODEPAGE_949 is not set
> # CONFIG_NLS_CODEPAGE_874 is not set
> CONFIG_NLS_ISO8859_8=y
> # CONFIG_NLS_CODEPAGE_1250 is not set
> CONFIG_NLS_CODEPAGE_1251=y
> # CONFIG_NLS_ASCII is not set
> # CONFIG_NLS_ISO8859_1 is not set
> CONFIG_NLS_ISO8859_2=y
> # CONFIG_NLS_ISO8859_3 is not set
> # CONFIG_NLS_ISO8859_4 is not set
> CONFIG_NLS_ISO8859_5=y
> CONFIG_NLS_ISO8859_6=y
> CONFIG_NLS_ISO8859_7=y
> # CONFIG_NLS_ISO8859_9 is not set
> # CONFIG_NLS_ISO8859_13 is not set
> # CONFIG_NLS_ISO8859_14 is not set
> CONFIG_NLS_ISO8859_15=y
> CONFIG_NLS_KOI8_R=y
> # CONFIG_NLS_KOI8_U is not set
> CONFIG_NLS_UTF8=y
> 
> #
> # Kernel hacking
> #
> CONFIG_TRACE_IRQFLAGS_SUPPORT=y
> CONFIG_PRINTK_TIME=y
> CONFIG_DEFAULT_MESSAGE_LOGLEVEL=4
> CONFIG_ENABLE_WARN_DEPRECATED=y
> CONFIG_ENABLE_MUST_CHECK=y
> CONFIG_FRAME_WARN=2048
> CONFIG_MAGIC_SYSRQ=y
> CONFIG_STRIP_ASM_SYMS=y
> CONFIG_UNUSED_SYMBOLS=y
> CONFIG_DEBUG_FS=y
> # CONFIG_HEADERS_CHECK is not set
> CONFIG_DEBUG_SECTION_MISMATCH=y
> CONFIG_DEBUG_KERNEL=y
> # CONFIG_DEBUG_SHIRQ is not set
> # CONFIG_LOCKUP_DETECTOR is not set
> # CONFIG_HARDLOCKUP_DETECTOR is not set
> CONFIG_DETECT_HUNG_TASK=y
> CONFIG_DEFAULT_HUNG_TASK_TIMEOUT=120
> # CONFIG_BOOTPARAM_HUNG_TASK_PANIC is not set
> CONFIG_BOOTPARAM_HUNG_TASK_PANIC_VALUE=0
> CONFIG_SCHED_DEBUG=y
> CONFIG_SCHEDSTATS=y
> # CONFIG_TIMER_STATS is not set
> CONFIG_DEBUG_OBJECTS=y
> CONFIG_DEBUG_OBJECTS_SELFTEST=y
> CONFIG_DEBUG_OBJECTS_FREE=y
> # CONFIG_DEBUG_OBJECTS_TIMERS is not set
> # CONFIG_DEBUG_OBJECTS_WORK is not set
> # CONFIG_DEBUG_OBJECTS_RCU_HEAD is not set
> # CONFIG_DEBUG_OBJECTS_PERCPU_COUNTER is not set
> CONFIG_DEBUG_OBJECTS_ENABLE_DEFAULT=1
> # CONFIG_SLUB_DEBUG_ON is not set
> # CONFIG_SLUB_STATS is not set
> # CONFIG_DEBUG_KMEMLEAK is not set
> CONFIG_DEBUG_PREEMPT=y
> CONFIG_DEBUG_RT_MUTEXES=y
> CONFIG_DEBUG_PI_LIST=y
> # CONFIG_RT_MUTEX_TESTER is not set
> CONFIG_DEBUG_SPINLOCK=y
> CONFIG_DEBUG_MUTEXES=y
> # CONFIG_DEBUG_LOCK_ALLOC is not set
> # CONFIG_PROVE_LOCKING is not set
> CONFIG_SPARSE_RCU_POINTER=y
> # CONFIG_LOCK_STAT is not set
> CONFIG_TRACE_IRQFLAGS=y
> # CONFIG_DEBUG_ATOMIC_SLEEP is not set
> CONFIG_DEBUG_LOCKING_API_SELFTESTS=y
> CONFIG_STACKTRACE=y
> # CONFIG_DEBUG_STACK_USAGE is not set
> CONFIG_DEBUG_KOBJECT=y
> CONFIG_DEBUG_BUGVERBOSE=y
> # CONFIG_DEBUG_INFO is not set
> # CONFIG_DEBUG_VM is not set
> # CONFIG_DEBUG_VIRTUAL is not set
> CONFIG_DEBUG_WRITECOUNT=y
> CONFIG_DEBUG_MEMORY_INIT=y
> CONFIG_DEBUG_LIST=y
> CONFIG_TEST_LIST_SORT=y
> CONFIG_DEBUG_SG=y
> # CONFIG_DEBUG_NOTIFIERS is not set
> # CONFIG_DEBUG_CREDENTIALS is not set
> CONFIG_ARCH_WANT_FRAME_POINTERS=y
> CONFIG_FRAME_POINTER=y
> # CONFIG_BOOT_PRINTK_DELAY is not set
> CONFIG_RCU_TORTURE_TEST=y
> # CONFIG_RCU_TORTURE_TEST_RUNNABLE is not set
> CONFIG_BACKTRACE_SELF_TEST=y
> # CONFIG_DEBUG_BLOCK_EXT_DEVT is not set
> # CONFIG_DEBUG_FORCE_WEAK_PER_CPU is not set
> CONFIG_LKDTM=y
> CONFIG_FAULT_INJECTION=y
> # CONFIG_FAILSLAB is not set
> # CONFIG_FAIL_PAGE_ALLOC is not set
> CONFIG_FAIL_MAKE_REQUEST=y
> CONFIG_FAIL_IO_TIMEOUT=y
> CONFIG_FAULT_INJECTION_DEBUG_FS=y
> # CONFIG_LATENCYTOP is not set
> # CONFIG_SYSCTL_SYSCALL_CHECK is not set
> # CONFIG_DEBUG_PAGEALLOC is not set
> CONFIG_USER_STACKTRACE_SUPPORT=y
> CONFIG_NOP_TRACER=y
> CONFIG_HAVE_FTRACE_NMI_ENTER=y
> CONFIG_HAVE_FUNCTION_TRACER=y
> CONFIG_HAVE_FUNCTION_GRAPH_TRACER=y
> CONFIG_HAVE_FUNCTION_GRAPH_FP_TEST=y
> CONFIG_HAVE_FUNCTION_TRACE_MCOUNT_TEST=y
> CONFIG_HAVE_DYNAMIC_FTRACE=y
> CONFIG_HAVE_FTRACE_MCOUNT_RECORD=y
> CONFIG_HAVE_SYSCALL_TRACEPOINTS=y
> CONFIG_HAVE_C_RECORDMCOUNT=y
> CONFIG_TRACER_MAX_TRACE=y
> CONFIG_RING_BUFFER=y
> CONFIG_FTRACE_NMI_ENTER=y
> CONFIG_EVENT_TRACING=y
> CONFIG_EVENT_POWER_TRACING_DEPRECATED=y
> CONFIG_CONTEXT_SWITCH_TRACER=y
> CONFIG_RING_BUFFER_ALLOW_SWAP=y
> CONFIG_TRACING=y
> CONFIG_GENERIC_TRACER=y
> CONFIG_TRACING_SUPPORT=y
> CONFIG_FTRACE=y
> CONFIG_FUNCTION_TRACER=y
> # CONFIG_FUNCTION_GRAPH_TRACER is not set
> CONFIG_IRQSOFF_TRACER=y
> CONFIG_PREEMPT_TRACER=y
> CONFIG_SCHED_TRACER=y
> # CONFIG_FTRACE_SYSCALLS is not set
> CONFIG_BRANCH_PROFILE_NONE=y
> # CONFIG_PROFILE_ANNOTATED_BRANCHES is not set
> # CONFIG_PROFILE_ALL_BRANCHES is not set
> # CONFIG_STACK_TRACER is not set
> # CONFIG_BLK_DEV_IO_TRACE is not set
> CONFIG_UPROBE_EVENT=y
> CONFIG_PROBE_EVENTS=y
> CONFIG_DYNAMIC_FTRACE=y
> CONFIG_FUNCTION_PROFILER=y
> CONFIG_FTRACE_MCOUNT_RECORD=y
> # CONFIG_FTRACE_STARTUP_TEST is not set
> # CONFIG_MMIOTRACE is not set
> # CONFIG_RING_BUFFER_BENCHMARK is not set
> CONFIG_PROVIDE_OHCI1394_DMA_INIT=y
> # CONFIG_FIREWIRE_OHCI_REMOTE_DMA is not set
> CONFIG_DYNAMIC_DEBUG=y
> CONFIG_DMA_API_DEBUG=y
> CONFIG_ATOMIC64_SELFTEST=y
> CONFIG_SAMPLES=y
> CONFIG_HAVE_ARCH_KGDB=y
> CONFIG_KGDB=y
> CONFIG_KGDB_SERIAL_CONSOLE=y
> # CONFIG_KGDB_TESTS is not set
> # CONFIG_KGDB_LOW_LEVEL_TRAP is not set
> # CONFIG_KGDB_KDB is not set
> CONFIG_HAVE_ARCH_KMEMCHECK=y
> CONFIG_TEST_KSTRTOX=y
> # CONFIG_STRICT_DEVMEM is not set
> CONFIG_X86_VERBOSE_BOOTUP=y
> CONFIG_EARLY_PRINTK=y
> # CONFIG_EARLY_PRINTK_DBGP is not set
> CONFIG_DEBUG_STACKOVERFLOW=y
> CONFIG_X86_PTDUMP=y
> CONFIG_DEBUG_RODATA=y
> CONFIG_DEBUG_RODATA_TEST=y
> CONFIG_IOMMU_DEBUG=y
> # CONFIG_IOMMU_STRESS is not set
> CONFIG_IOMMU_LEAK=y
> CONFIG_HAVE_MMIOTRACE_SUPPORT=y
> CONFIG_IO_DELAY_TYPE_0X80=0
> CONFIG_IO_DELAY_TYPE_0XED=1
> CONFIG_IO_DELAY_TYPE_UDELAY=2
> CONFIG_IO_DELAY_TYPE_NONE=3
> # CONFIG_IO_DELAY_0X80 is not set
> # CONFIG_IO_DELAY_0XED is not set
> # CONFIG_IO_DELAY_UDELAY is not set
> CONFIG_IO_DELAY_NONE=y
> CONFIG_DEFAULT_IO_DELAY_TYPE=3
> CONFIG_DEBUG_BOOT_PARAMS=y
> CONFIG_CPA_DEBUG=y
> CONFIG_OPTIMIZE_INLINING=y
> # CONFIG_DEBUG_STRICT_USER_COPY_CHECKS is not set
> CONFIG_DEBUG_NMI_SELFTEST=y
> 
> #
> # Security options
> #
> CONFIG_KEYS=y
> CONFIG_ENCRYPTED_KEYS=y
> # CONFIG_KEYS_DEBUG_PROC_KEYS is not set
> # CONFIG_SECURITY_DMESG_RESTRICT is not set
> # CONFIG_SECURITY is not set
> CONFIG_SECURITYFS=y
> CONFIG_DEFAULT_SECURITY_DAC=y
> CONFIG_DEFAULT_SECURITY=""
> CONFIG_XOR_BLOCKS=y
> CONFIG_ASYNC_CORE=y
> CONFIG_ASYNC_XOR=y
> CONFIG_CRYPTO=y
> 
> #
> # Crypto core or helper
> #
> # CONFIG_CRYPTO_FIPS is not set
> CONFIG_CRYPTO_ALGAPI=y
> CONFIG_CRYPTO_ALGAPI2=y
> CONFIG_CRYPTO_AEAD=y
> CONFIG_CRYPTO_AEAD2=y
> CONFIG_CRYPTO_BLKCIPHER=y
> CONFIG_CRYPTO_BLKCIPHER2=y
> CONFIG_CRYPTO_HASH=y
> CONFIG_CRYPTO_HASH2=y
> CONFIG_CRYPTO_RNG=y
> CONFIG_CRYPTO_RNG2=y
> CONFIG_CRYPTO_PCOMP2=y
> CONFIG_CRYPTO_MANAGER=y
> CONFIG_CRYPTO_MANAGER2=y
> # CONFIG_CRYPTO_USER is not set
> # CONFIG_CRYPTO_MANAGER_DISABLE_TESTS is not set
> CONFIG_CRYPTO_GF128MUL=y
> CONFIG_CRYPTO_NULL=y
> CONFIG_CRYPTO_WORKQUEUE=y
> CONFIG_CRYPTO_CRYPTD=y
> CONFIG_CRYPTO_AUTHENC=y
> 
> #
> # Authenticated Encryption with Associated Data
> #
> # CONFIG_CRYPTO_CCM is not set
> # CONFIG_CRYPTO_GCM is not set
> CONFIG_CRYPTO_SEQIV=y
> 
> #
> # Block modes
> #
> CONFIG_CRYPTO_CBC=y
> # CONFIG_CRYPTO_CTR is not set
> # CONFIG_CRYPTO_CTS is not set
> CONFIG_CRYPTO_ECB=y
> CONFIG_CRYPTO_LRW=y
> CONFIG_CRYPTO_PCBC=y
> CONFIG_CRYPTO_XTS=y
> 
> #
> # Hash modes
> #
> CONFIG_CRYPTO_HMAC=y
> CONFIG_CRYPTO_XCBC=y
> CONFIG_CRYPTO_VMAC=y
> 
> #
> # Digest
> #
> CONFIG_CRYPTO_CRC32C=y
> CONFIG_CRYPTO_CRC32C_INTEL=y
> CONFIG_CRYPTO_GHASH=y
> # CONFIG_CRYPTO_MD4 is not set
> CONFIG_CRYPTO_MD5=y
> # CONFIG_CRYPTO_MICHAEL_MIC is not set
> CONFIG_CRYPTO_RMD128=y
> CONFIG_CRYPTO_RMD160=y
> CONFIG_CRYPTO_RMD256=y
> # CONFIG_CRYPTO_RMD320 is not set
> CONFIG_CRYPTO_SHA1=y
> # CONFIG_CRYPTO_SHA1_SSSE3 is not set
> CONFIG_CRYPTO_SHA256=y
> CONFIG_CRYPTO_SHA512=y
> CONFIG_CRYPTO_TGR192=y
> CONFIG_CRYPTO_WP512=y
> # CONFIG_CRYPTO_GHASH_CLMUL_NI_INTEL is not set
> 
> #
> # Ciphers
> #
> CONFIG_CRYPTO_AES=y
> CONFIG_CRYPTO_AES_X86_64=y
> # CONFIG_CRYPTO_AES_NI_INTEL is not set
> CONFIG_CRYPTO_ANUBIS=y
> # CONFIG_CRYPTO_ARC4 is not set
> CONFIG_CRYPTO_BLOWFISH=y
> CONFIG_CRYPTO_BLOWFISH_COMMON=y
> CONFIG_CRYPTO_BLOWFISH_X86_64=y
> CONFIG_CRYPTO_CAMELLIA=y
> # CONFIG_CRYPTO_CAST5 is not set
> CONFIG_CRYPTO_CAST6=y
> CONFIG_CRYPTO_DES=y
> CONFIG_CRYPTO_FCRYPT=y
> # CONFIG_CRYPTO_KHAZAD is not set
> # CONFIG_CRYPTO_SALSA20 is not set
> # CONFIG_CRYPTO_SALSA20_X86_64 is not set
> # CONFIG_CRYPTO_SEED is not set
> CONFIG_CRYPTO_SERPENT=y
> CONFIG_CRYPTO_SERPENT_SSE2_X86_64=y
> CONFIG_CRYPTO_TEA=y
> # CONFIG_CRYPTO_TWOFISH is not set
> CONFIG_CRYPTO_TWOFISH_COMMON=y
> CONFIG_CRYPTO_TWOFISH_X86_64=y
> # CONFIG_CRYPTO_TWOFISH_X86_64_3WAY is not set
> 
> #
> # Compression
> #
> CONFIG_CRYPTO_DEFLATE=y
> # CONFIG_CRYPTO_ZLIB is not set
> CONFIG_CRYPTO_LZO=y
> 
> #
> # Random Number Generation
> #
> CONFIG_CRYPTO_ANSI_CPRNG=y
> CONFIG_CRYPTO_USER_API=y
> CONFIG_CRYPTO_USER_API_HASH=y
> CONFIG_CRYPTO_USER_API_SKCIPHER=y
> CONFIG_CRYPTO_HW=y
> CONFIG_CRYPTO_DEV_PADLOCK=y
> # CONFIG_CRYPTO_DEV_PADLOCK_AES is not set
> # CONFIG_CRYPTO_DEV_PADLOCK_SHA is not set
> CONFIG_HAVE_KVM=y
> CONFIG_HAVE_KVM_IRQCHIP=y
> CONFIG_HAVE_KVM_EVENTFD=y
> CONFIG_KVM_APIC_ARCHITECTURE=y
> CONFIG_KVM_MMIO=y
> CONFIG_KVM_ASYNC_PF=y
> CONFIG_VIRTUALIZATION=y
> CONFIG_KVM=y
> CONFIG_KVM_INTEL=y
> # CONFIG_KVM_AMD is not set
> # CONFIG_KVM_MMU_AUDIT is not set
> CONFIG_VHOST_NET=y
> CONFIG_BINARY_PRINTF=y
> 
> #
> # Library routines
> #
> CONFIG_BITREVERSE=y
> CONFIG_GENERIC_FIND_FIRST_BIT=y
> CONFIG_GENERIC_PCI_IOMAP=y
> CONFIG_GENERIC_IOMAP=y
> CONFIG_CRC_CCITT=y
> CONFIG_CRC16=y
> CONFIG_CRC_T10DIF=y
> CONFIG_CRC_ITU_T=y
> CONFIG_CRC32=y
> CONFIG_CRC7=y
> CONFIG_LIBCRC32C=y
> CONFIG_CRC8=y
> CONFIG_ZLIB_INFLATE=y
> CONFIG_ZLIB_DEFLATE=y
> CONFIG_LZO_COMPRESS=y
> CONFIG_LZO_DECOMPRESS=y
> CONFIG_XZ_DEC=y
> CONFIG_XZ_DEC_X86=y
> CONFIG_XZ_DEC_POWERPC=y
> CONFIG_XZ_DEC_IA64=y
> CONFIG_XZ_DEC_ARM=y
> CONFIG_XZ_DEC_ARMTHUMB=y
> CONFIG_XZ_DEC_SPARC=y
> CONFIG_XZ_DEC_BCJ=y
> # CONFIG_XZ_DEC_TEST is not set
> CONFIG_DECOMPRESS_GZIP=y
> CONFIG_DECOMPRESS_BZIP2=y
> CONFIG_DECOMPRESS_LZMA=y
> CONFIG_DECOMPRESS_XZ=y
> CONFIG_DECOMPRESS_LZO=y
> CONFIG_BCH=y
> CONFIG_BCH_CONST_PARAMS=y
> CONFIG_TEXTSEARCH=y
> CONFIG_TEXTSEARCH_KMP=y
> CONFIG_TEXTSEARCH_BM=y
> CONFIG_TEXTSEARCH_FSM=y
> CONFIG_HAS_IOMEM=y
> CONFIG_HAS_IOPORT=y
> CONFIG_HAS_DMA=y
> CONFIG_CHECK_SIGNATURE=y
> CONFIG_DQL=y
> CONFIG_NLATTR=y
> CONFIG_AVERAGE=y
> # CONFIG_CORDIC is not set
> CONFIG_MPILIB=y
> CONFIG_MPILIB_EXTRA=y
> # CONFIG_DIGSIG is not set


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 21 20:14:34 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 20:14:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdSY3-0005yE-5r; Wed, 21 Dec 2011 20:13:59 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RdSY1-0005y9-De
	for xen-devel@lists.xensource.com; Wed, 21 Dec 2011 20:13:57 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1324498430!2884666!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzcyNA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28383 invoked from network); 21 Dec 2011 20:13:50 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Dec 2011 20:13:50 -0000
X-IronPort-AV: E=Sophos;i="4.71,389,1320624000"; 
   d="scan'208";a="9618511"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Dec 2011 20:13:50 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 21 Dec 2011 20:13:49 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RdSXt-0004ja-Mq;
	Wed, 21 Dec 2011 20:13:49 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RdSXt-0003jF-D3;
	Wed, 21 Dec 2011 20:13:49 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10571-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 21 Dec 2011 20:13:49 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10571: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10571 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10571/

Regressions :-(

Tests which did not succeed and are blocking,including tests which could not be run:
 test-amd64-i386-xl-credit2    7 debian-install            fail REGR. vs. 10564
 test-i386-i386-pv            16 guest-start.2             fail REGR. vs. 10564
 test-i386-i386-xl            16 guest-start.2             fail REGR. vs. 10564
 test-amd64-amd64-xl-win7-amd64  7 windows-install         fail REGR. vs. 10564

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass

version targeted for testing:
 xen                  492914c65838
baseline version:
 xen                  e56500f95b6a

------------------------------------------------------------
People who touched revisions under test:
  Anthony PERARD <anthony.perard@citrix.com>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            fail    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            fail    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   24445:492914c65838
tag:         tip
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Wed Dec 21 10:47:30 2011 +0000
    
    libxl: report failure to reboot/shutdown due to lackof PV interfaces to caller
    
    This allow the caller to react as they think is appropriate. xl now prints a
    message much like the library did previously, although hopefully somewhat more
    informative.
    
    Update the xl(1) man page to be similarly more informative.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Committed-by: Ian Jackson <ian.jackson.citrix.com>
    Acked-by: Ian Jackson <ian.jackson.citrix.com>
    
    
changeset:   24444:1c3f9cac204e
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Wed Dec 21 10:47:11 2011 +0000
    
    libxl: split libxl_domain_shutdown into libxl_domain_shutdown,..._reboot
    
    The other integer request types which shutdown supported are not
    useful. Specifically:
    
     * "suspend" is not usable via this interface since it requires other
       scaffolding, libxl_domain_suspend provides this already.
     * "halt" is the same as "poweroff".
     * "crash" is unused and at least Linux does not implement it. If a user
       steps forward then libxl_domain_crash is trivial to add.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Committed-by: Ian Jackson <ian.jackson.citrix.com>
    Acked-by: Ian Jackson <ian.jackson.citrix.com>
    
    
changeset:   24443:b3455a4d2298
user:        Anthony PERARD <anthony.perard@citrix.com>
date:        Wed Dec 21 14:47:26 2011 +0000
    
    libxl: Fix, specify open mode to QEMU state file.
    
    Reported-by: Olaf Hering <olaf@aepfle.de>
    Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24442:16dc2a1cd40f
user:        Jan Beulich <jbeulich@suse.com>
date:        Wed Dec 21 14:26:09 2011 +0100
    
    x86: reduce scope of some symbols used with reset_stack_and_jump()
    
    By making the macro properly advertise the use of the input symbol to
    the compiler, it is no longer necessary for them to be global if
    they're defined and used in just one source file.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24441:73ab77073140
user:        Jan Beulich <jbeulich@suse.com>
date:        Wed Dec 21 09:20:15 2011 +0100
    
    x86: move some function scope statics into .init.data
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24440:e56500f95b6a
user:        Daniel De Graaf <dgdegra@tycho.nsa.gov>
date:        Tue Dec 20 18:19:53 2011 +0000
    
    flask/policy: Update example policy
    
    Rewrite the example policy to make it easier to understand and
    demonstrate some of the security goals that FLASK can enforce.
    
    Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
    Committed-by: Ian Jackson <ian.jackson.citrix.com>
    
    
========================================
commit 54e24021005458ad0a361c1d83011b751726a94b
Author: Ian Jackson <ian.jackson@eu.citrix.com>
Date:   Thu Dec 8 16:38:06 2011 +0000

    qemu_get_timer: Provide a comment about the behaviour on ts==NULL
    
    Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 21 20:14:34 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 20:14:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdSY3-0005yE-5r; Wed, 21 Dec 2011 20:13:59 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RdSY1-0005y9-De
	for xen-devel@lists.xensource.com; Wed, 21 Dec 2011 20:13:57 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1324498430!2884666!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzcyNA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28383 invoked from network); 21 Dec 2011 20:13:50 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Dec 2011 20:13:50 -0000
X-IronPort-AV: E=Sophos;i="4.71,389,1320624000"; 
   d="scan'208";a="9618511"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Dec 2011 20:13:50 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 21 Dec 2011 20:13:49 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RdSXt-0004ja-Mq;
	Wed, 21 Dec 2011 20:13:49 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RdSXt-0003jF-D3;
	Wed, 21 Dec 2011 20:13:49 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10571-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 21 Dec 2011 20:13:49 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10571: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10571 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10571/

Regressions :-(

Tests which did not succeed and are blocking,including tests which could not be run:
 test-amd64-i386-xl-credit2    7 debian-install            fail REGR. vs. 10564
 test-i386-i386-pv            16 guest-start.2             fail REGR. vs. 10564
 test-i386-i386-xl            16 guest-start.2             fail REGR. vs. 10564
 test-amd64-amd64-xl-win7-amd64  7 windows-install         fail REGR. vs. 10564

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass

version targeted for testing:
 xen                  492914c65838
baseline version:
 xen                  e56500f95b6a

------------------------------------------------------------
People who touched revisions under test:
  Anthony PERARD <anthony.perard@citrix.com>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            fail    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            fail    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   24445:492914c65838
tag:         tip
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Wed Dec 21 10:47:30 2011 +0000
    
    libxl: report failure to reboot/shutdown due to lackof PV interfaces to caller
    
    This allow the caller to react as they think is appropriate. xl now prints a
    message much like the library did previously, although hopefully somewhat more
    informative.
    
    Update the xl(1) man page to be similarly more informative.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Committed-by: Ian Jackson <ian.jackson.citrix.com>
    Acked-by: Ian Jackson <ian.jackson.citrix.com>
    
    
changeset:   24444:1c3f9cac204e
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Wed Dec 21 10:47:11 2011 +0000
    
    libxl: split libxl_domain_shutdown into libxl_domain_shutdown,..._reboot
    
    The other integer request types which shutdown supported are not
    useful. Specifically:
    
     * "suspend" is not usable via this interface since it requires other
       scaffolding, libxl_domain_suspend provides this already.
     * "halt" is the same as "poweroff".
     * "crash" is unused and at least Linux does not implement it. If a user
       steps forward then libxl_domain_crash is trivial to add.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Committed-by: Ian Jackson <ian.jackson.citrix.com>
    Acked-by: Ian Jackson <ian.jackson.citrix.com>
    
    
changeset:   24443:b3455a4d2298
user:        Anthony PERARD <anthony.perard@citrix.com>
date:        Wed Dec 21 14:47:26 2011 +0000
    
    libxl: Fix, specify open mode to QEMU state file.
    
    Reported-by: Olaf Hering <olaf@aepfle.de>
    Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24442:16dc2a1cd40f
user:        Jan Beulich <jbeulich@suse.com>
date:        Wed Dec 21 14:26:09 2011 +0100
    
    x86: reduce scope of some symbols used with reset_stack_and_jump()
    
    By making the macro properly advertise the use of the input symbol to
    the compiler, it is no longer necessary for them to be global if
    they're defined and used in just one source file.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24441:73ab77073140
user:        Jan Beulich <jbeulich@suse.com>
date:        Wed Dec 21 09:20:15 2011 +0100
    
    x86: move some function scope statics into .init.data
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24440:e56500f95b6a
user:        Daniel De Graaf <dgdegra@tycho.nsa.gov>
date:        Tue Dec 20 18:19:53 2011 +0000
    
    flask/policy: Update example policy
    
    Rewrite the example policy to make it easier to understand and
    demonstrate some of the security goals that FLASK can enforce.
    
    Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
    Committed-by: Ian Jackson <ian.jackson.citrix.com>
    
    
========================================
commit 54e24021005458ad0a361c1d83011b751726a94b
Author: Ian Jackson <ian.jackson@eu.citrix.com>
Date:   Thu Dec 8 16:38:06 2011 +0000

    qemu_get_timer: Provide a comment about the behaviour on ts==NULL
    
    Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 21 23:34:43 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 23:34:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdVfU-0007zY-0K; Wed, 21 Dec 2011 23:33:52 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RdVfT-0007zQ-8m
	for xen-devel@lists.xensource.com; Wed, 21 Dec 2011 23:33:51 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1324510425!8197418!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzcyNA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17808 invoked from network); 21 Dec 2011 23:33:45 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Dec 2011 23:33:45 -0000
X-IronPort-AV: E=Sophos;i="4.71,390,1320624000"; 
   d="scan'208";a="9619981"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Dec 2011 23:33:44 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 21 Dec 2011 23:33:44 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RdVfM-0005pU-CX;
	Wed, 21 Dec 2011 23:33:44 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RdVfM-0004ar-4o;
	Wed, 21 Dec 2011 23:33:44 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10574-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 21 Dec 2011 23:33:44 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux test] 10574: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10574 linux real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10574/

Regressions :-(

Tests which did not succeed and are blocking,including tests which could not be run:
 test-amd64-amd64-win          7 windows-install            fail REGR. vs. 9095
 test-amd64-amd64-xl-win       7 windows-install            fail REGR. vs. 9095
 build-amd64-pvops             1 hosts-allocate               broken   in 10565

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-pv          16 guest-start.2               fail pass in 10570
 test-amd64-amd64-xl-sedf     16 guest-start.2               fail pass in 10570
 test-amd64-i386-rhel6hvm-intel  7 redhat-install            fail pass in 10570
 test-amd64-i386-xl-credit2    9 guest-start                 fail pass in 10570
 test-amd64-i386-pv           16 guest-start.2               fail pass in 10570
 test-i386-i386-pv            16 guest-start.2               fail pass in 10570
 test-i386-i386-xl            16 guest-start.2               fail pass in 10570
 test-amd64-i386-xl-multivcpu 16 guest-start.2               fail pass in 10565
 test-amd64-i386-xl           16 guest-start.2               fail pass in 10570
 test-amd64-amd64-xl          16 guest-start.2               fail pass in 10570
 test-amd64-i386-rhel6hvm-amd  7 redhat-install              fail pass in 10570
 test-i386-i386-win            7 windows-install             fail pass in 10570
 test-amd64-i386-win           7 windows-install    fail in 10570 pass in 10574
 test-amd64-i386-xl-win-vcpus1  7 windows-install   fail in 10565 pass in 10574
 test-amd64-i386-win-vcpus1    7 windows-install    fail in 10565 pass in 10574

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-xl-sedf-pin 16 guest-start.2             fail blocked in 9095
 test-amd64-i386-xl-win7-amd64  7 windows-install          fail blocked in 9095
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-xl-winxpsp3    7 windows-install           fail blocked in 9095
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64  7 windows-install              fail never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2       fail in 10570 never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2         fail in 10570 never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop           fail in 10570 never pass
 test-i386-i386-win           16 leak-check/check      fail in 10570 never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 7 windows-install fail in 10570 blocked in 9095
 build-amd64-pvops             2 logs-capture(2)     broken in 10565 never pass
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)     blocked in 10565 n/a
 test-amd64-amd64-xl-sedf-pin  1 xen-build-check(1)        blocked in 10565 n/a
 test-amd64-amd64-pv           1 xen-build-check(1)        blocked in 10565 n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)        blocked in 10565 n/a
 test-amd64-amd64-pair         1 xen-build-check(1)        blocked in 10565 n/a
 test-amd64-amd64-xl           1 xen-build-check(1)        blocked in 10565 n/a
 test-amd64-amd64-xl-winxpsp3  1 xen-build-check(1)        blocked in 10565 n/a
 test-amd64-i386-xend-winxpsp3  7 windows-install fail in 10565 blocked in 9095
 test-amd64-amd64-win          1 xen-build-check(1)        blocked in 10565 n/a
 test-i386-i386-xl-winxpsp3   13 guest-stop            fail in 10565 never pass
 test-amd64-amd64-xl-win       1 xen-build-check(1)        blocked in 10565 n/a
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)      blocked in 10565 n/a

version targeted for testing:
 linux                59b1ffe039ce366305d48176b7fccce29ce729d3
baseline version:
 linux                6bec8b4a4c14095d0b7ce424db9d583c3decae6c

------------------------------------------------------------
People who touched revisions under test:
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          fail    
 test-amd64-i386-xl                                           fail    
 test-i386-i386-xl                                            fail    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          fail    
 test-amd64-i386-pv                                           fail    
 test-i386-i386-pv                                            fail    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
commit 59b1ffe039ce366305d48176b7fccce29ce729d3
Merge: cacd265... 60b1e4f...
Author: Jeremy Fitzhardinge <jeremy@goop.org>
Date:   Sat Dec 10 00:20:33 2011 -0800

    Merge commit 'v2.6.32.50' into xen/next-2.6.32
    
    * commit 'v2.6.32.50': (28 commits)
      Linux 2.6.32.50
      clockevents: Set noop handler in clockevents_exchange_device()
      tick-broadcast: Stop active broadcast device when replacing it
      genirq: Fix race condition when stopping the irq thread
      oprofile, x86: Fix crash when unloading module (nmi timer mode)
      x86/mpparse: Account for bus types other than ISA and PCI
      sched, x86: Avoid unnecessary overflow in sched_clock
      cifs: fix cifs stable patch cifs-fix-oplock-break-handling-try-2.patch
      SCSI: Silencing 'killing requests for dead queue'
      SCSI: scsi_lib: fix potential NULL dereference
      USB: usb-storage: unusual_devs entry for Kingston DT 101 G2
      usb: option: add SIMCom SIM5218
      usb: ftdi_sio: add PID for Propox ISPcable III
      USB: whci-hcd: fix endian conversion in qset_clear()
      Staging: comedi: fix signal handling in read and write
      staging: comedi: fix oops for USB DAQ devices.
      staging: usbip: bugfix for deadlock
      gro: reset vlan_tci on reuse
      nl80211: fix MAC address validation
      p54spi: Fix workqueue deadlock
      ...

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 21 23:34:43 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 23:34:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdVfU-0007zY-0K; Wed, 21 Dec 2011 23:33:52 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RdVfT-0007zQ-8m
	for xen-devel@lists.xensource.com; Wed, 21 Dec 2011 23:33:51 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1324510425!8197418!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzcyNA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17808 invoked from network); 21 Dec 2011 23:33:45 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Dec 2011 23:33:45 -0000
X-IronPort-AV: E=Sophos;i="4.71,390,1320624000"; 
   d="scan'208";a="9619981"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Dec 2011 23:33:44 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 21 Dec 2011 23:33:44 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RdVfM-0005pU-CX;
	Wed, 21 Dec 2011 23:33:44 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RdVfM-0004ar-4o;
	Wed, 21 Dec 2011 23:33:44 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10574-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 21 Dec 2011 23:33:44 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux test] 10574: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10574 linux real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10574/

Regressions :-(

Tests which did not succeed and are blocking,including tests which could not be run:
 test-amd64-amd64-win          7 windows-install            fail REGR. vs. 9095
 test-amd64-amd64-xl-win       7 windows-install            fail REGR. vs. 9095
 build-amd64-pvops             1 hosts-allocate               broken   in 10565

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-pv          16 guest-start.2               fail pass in 10570
 test-amd64-amd64-xl-sedf     16 guest-start.2               fail pass in 10570
 test-amd64-i386-rhel6hvm-intel  7 redhat-install            fail pass in 10570
 test-amd64-i386-xl-credit2    9 guest-start                 fail pass in 10570
 test-amd64-i386-pv           16 guest-start.2               fail pass in 10570
 test-i386-i386-pv            16 guest-start.2               fail pass in 10570
 test-i386-i386-xl            16 guest-start.2               fail pass in 10570
 test-amd64-i386-xl-multivcpu 16 guest-start.2               fail pass in 10565
 test-amd64-i386-xl           16 guest-start.2               fail pass in 10570
 test-amd64-amd64-xl          16 guest-start.2               fail pass in 10570
 test-amd64-i386-rhel6hvm-amd  7 redhat-install              fail pass in 10570
 test-i386-i386-win            7 windows-install             fail pass in 10570
 test-amd64-i386-win           7 windows-install    fail in 10570 pass in 10574
 test-amd64-i386-xl-win-vcpus1  7 windows-install   fail in 10565 pass in 10574
 test-amd64-i386-win-vcpus1    7 windows-install    fail in 10565 pass in 10574

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-xl-sedf-pin 16 guest-start.2             fail blocked in 9095
 test-amd64-i386-xl-win7-amd64  7 windows-install          fail blocked in 9095
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-xl-winxpsp3    7 windows-install           fail blocked in 9095
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64  7 windows-install              fail never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2       fail in 10570 never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2         fail in 10570 never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop           fail in 10570 never pass
 test-i386-i386-win           16 leak-check/check      fail in 10570 never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 7 windows-install fail in 10570 blocked in 9095
 build-amd64-pvops             2 logs-capture(2)     broken in 10565 never pass
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)     blocked in 10565 n/a
 test-amd64-amd64-xl-sedf-pin  1 xen-build-check(1)        blocked in 10565 n/a
 test-amd64-amd64-pv           1 xen-build-check(1)        blocked in 10565 n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)        blocked in 10565 n/a
 test-amd64-amd64-pair         1 xen-build-check(1)        blocked in 10565 n/a
 test-amd64-amd64-xl           1 xen-build-check(1)        blocked in 10565 n/a
 test-amd64-amd64-xl-winxpsp3  1 xen-build-check(1)        blocked in 10565 n/a
 test-amd64-i386-xend-winxpsp3  7 windows-install fail in 10565 blocked in 9095
 test-amd64-amd64-win          1 xen-build-check(1)        blocked in 10565 n/a
 test-i386-i386-xl-winxpsp3   13 guest-stop            fail in 10565 never pass
 test-amd64-amd64-xl-win       1 xen-build-check(1)        blocked in 10565 n/a
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)      blocked in 10565 n/a

version targeted for testing:
 linux                59b1ffe039ce366305d48176b7fccce29ce729d3
baseline version:
 linux                6bec8b4a4c14095d0b7ce424db9d583c3decae6c

------------------------------------------------------------
People who touched revisions under test:
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          fail    
 test-amd64-i386-xl                                           fail    
 test-i386-i386-xl                                            fail    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          fail    
 test-amd64-i386-pv                                           fail    
 test-i386-i386-pv                                            fail    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
commit 59b1ffe039ce366305d48176b7fccce29ce729d3
Merge: cacd265... 60b1e4f...
Author: Jeremy Fitzhardinge <jeremy@goop.org>
Date:   Sat Dec 10 00:20:33 2011 -0800

    Merge commit 'v2.6.32.50' into xen/next-2.6.32
    
    * commit 'v2.6.32.50': (28 commits)
      Linux 2.6.32.50
      clockevents: Set noop handler in clockevents_exchange_device()
      tick-broadcast: Stop active broadcast device when replacing it
      genirq: Fix race condition when stopping the irq thread
      oprofile, x86: Fix crash when unloading module (nmi timer mode)
      x86/mpparse: Account for bus types other than ISA and PCI
      sched, x86: Avoid unnecessary overflow in sched_clock
      cifs: fix cifs stable patch cifs-fix-oplock-break-handling-try-2.patch
      SCSI: Silencing 'killing requests for dead queue'
      SCSI: scsi_lib: fix potential NULL dereference
      USB: usb-storage: unusual_devs entry for Kingston DT 101 G2
      usb: option: add SIMCom SIM5218
      usb: ftdi_sio: add PID for Propox ISPcable III
      USB: whci-hcd: fix endian conversion in qset_clear()
      Staging: comedi: fix signal handling in read and write
      staging: comedi: fix oops for USB DAQ devices.
      staging: usbip: bugfix for deadlock
      gro: reset vlan_tci on reuse
      nl80211: fix MAC address validation
      p54spi: Fix workqueue deadlock
      ...

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 21 23:51:46 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 23: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.xensource.com>)
	id 1RdVwB-0008B9-A1; Wed, 21 Dec 2011 23:51:07 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <florianmanschwetus@gmx.de>) id 1RdVw9-0008B4-0u
	for xen-devel@lists.xensource.com; Wed, 21 Dec 2011 23:51:05 +0000
X-Env-Sender: florianmanschwetus@gmx.de
X-Msg-Ref: server-15.tower-174.messagelabs.com!1324511455!6289997!1
X-Originating-IP: [213.165.64.23]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjEzLjE2NS42NC4yMyA9PiAxMTAyMjE=\n,
	ML_RADAR_SPEW_LINKS_14,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17757 invoked from network); 21 Dec 2011 23:50:58 -0000
Received: from mailout-de.gmx.net (HELO mailout-de.gmx.net) (213.165.64.23)
	by server-15.tower-174.messagelabs.com with SMTP;
	21 Dec 2011 23:50:58 -0000
Received: (qmail invoked by alias); 21 Dec 2011 23:50:55 -0000
Received: from dslb-094-219-040-177.pools.arcor-ip.net (EHLO [192.168.222.23])
	[94.219.40.177]
	by mail.gmx.net (mp061) with SMTP; 22 Dec 2011 00:50:55 +0100
X-Authenticated: #7518697
X-Provags-ID: V01U2FsdGVkX180QIFxirk0INQIR1/BMtrcQEn8R2Fym/ce/7/VYI
	5c5jKoWxfCJpKH
Message-ID: <4EF270A7.2010705@gmx.de>
Date: Thu, 22 Dec 2011 00:49:59 +0100
From: Florian Manschwetus <florianmanschwetus@gmx.de>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:8.0) Gecko/20111121 Thunderbird/8.0
MIME-Version: 1.0
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
References: <4EF06B14.4070106@gmx.de> <4EF0B034.1090708@gmx.de>
In-Reply-To: <4EF0B034.1090708@gmx.de>
X-Y-GMX-Trusted: 0
Cc: xen-users@lists.xensource.com
Subject: Re: [Xen-devel] [Xen-users] Problem booting xen 4.1.2 on Athlon 64
	X2
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============2016542240821628888=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Dies ist eine kryptografisch unterzeichnete Nachricht im MIME-Format.

--===============2016542240821628888==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms070806050800030409020202"

Dies ist eine kryptografisch unterzeichnete Nachricht im MIME-Format.

--------------ms070806050800030409020202
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: quoted-printable

Sending to devel, maybe a BUG?

Here are the details to the used mobo:

Handle 0x0000, DMI type 0, 24 bytes
BIOS Information
         Vendor: American Megatrends Inc.
         Version: 1004
         Release Date: 03/26/2008
         Address: 0xF0000
         Runtime Size: 64 kB
         ROM Size: 512 kB
         Characteristics:
                 ISA is supported
                 PCI is supported
                 PNP is supported
                 APM is supported
                 BIOS is upgradeable
                 BIOS shadowing is allowed
                 ESCD support is available
                 Boot from CD is supported
                 Selectable boot is supported
                 BIOS ROM is socketed
                 EDD is supported
                 5.25"/1.2 MB floppy services are supported (int 13h)
                 3.5"/720 kB floppy services are supported (int 13h)
                 3.5"/2.88 MB floppy services are supported (int 13h)
                 Print screen service is supported (int 5h)
                 8042 keyboard services are supported (int 9h)
                 Serial services are supported (int 14h)
                 Printer services are supported (int 17h)
                 CGA/mono video services are supported (int 10h)
                 ACPI is supported
                 USB legacy is supported
                 LS-120 boot is supported
                 ATAPI Zip drive boot is supported
                 BIOS boot specification is supported
                 Targeted content distribution is supported
         BIOS Revision: 8.12

Handle 0x0002, DMI type 2, 15 bytes
Base Board Information
         Manufacturer: ASUSTeK Computer INC.
         Product Name: M2N-MX
         Version: Rev 1.xx
         Serial Number: MB-xxxxxxxxxx
         Asset Tag: To Be Filled By O.E.M.
         Features:
                 Board is a hosting board
                 Board is replaceable
         Location In Chassis: To Be Filled By O.E.M.
         Chassis Handle: 0x0003
         Type: Motherboard
         Contained Object Handles: 0


Am 20.12.2011 16:56, schrieb Florian Manschwetus:
> Ok, I setup a serial so I can, give you a full copy of output (also
> added some debug options I found)
>
> Booting a command list
>
> Loading Xen 4.1.2 ...
> Loading Linux x86_64-3.1.5-gentoo ...
> Loading initial ramdisk ...
> __ __ _ _ _ ____
> \ \/ /___ _ __ | || | / | |___ \
> \ // _ \ '_ \ | || |_ | | __) |
> / \ __/ | | | |__ _|| |_ / __/
> /_/\_\___|_| |_| |_|(_)_(_)_____|
>
> (XEN) Xen version 4.1.2 (@) (gcc-Version 4.6.2 (Gentoo 4.6.2 p1.0,
> pie-0.4.5) ) Thu Dec 15 17:51:19 CET 2011
> (XEN) Latest ChangeSet: unavailable
> (XEN) Console output is synchronous.
> (XEN) Bootloader: GRUB 1.99
> (XEN) Command line: placeholder sync_console console_to_ring
> com1=3D115200,8n1 console=3Dcom1,vga loglvl=3Dall lapic=3Ddebug
> apic_verbosity=3Ddebug apic=3Ddebug
> (XEN) Video information:
> (XEN) VGA is text mode 80x25, font 8x16
> (XEN) VBE/DDC methods: none; EDID transfer time: 0 seconds
> (XEN) EDID info not retrieved because no DDC retrieval method detected
> (XEN) Disc information:
> (XEN) Found 1 MBR signatures
> (XEN) Found 1 EDD information structures
> (XEN) Xen-e820 RAM map:
> (XEN) 0000000000000000 - 000000000009fc00 (usable)
> (XEN) 000000000009fc00 - 00000000000a0000 (reserved)
> (XEN) 00000000000e0000 - 0000000000100000 (reserved)
> (XEN) 0000000000100000 - 00000000bffc0000 (usable)
> (XEN) 00000000bffc0000 - 00000000bffce000 (ACPI data)
> (XEN) 00000000bffce000 - 00000000bfff0000 (ACPI NVS)
> (XEN) 00000000bfff0000 - 00000000c0000000 (reserved)
> (XEN) 00000000fec00000 - 00000000fec01000 (reserved)
> (XEN) 00000000fee00000 - 00000000fef00000 (reserved)
> (XEN) 00000000ff780000 - 0000000100000000 (reserved)
> (XEN) 0000000100000000 - 0000000140000000 (usable)
> (XEN) ACPI: RSDP 000FB840, 0024 (r2 ACPIAM)
> (XEN) ACPI: XSDT BFFC0100, 004C (r1 A_M_I_ OEMXSDT 3000826 MSFT 97)
> (XEN) ACPI: FACP BFFC0290, 00F4 (r3 A_M_I_ OEMFACP 3000826 MSFT 97)
> (XEN) ACPI: DSDT BFFC05C0, 4E38 (r1 A0557 A0557000 0 INTL 20051117)
> (XEN) ACPI: FACS BFFCE000, 0040
> (XEN) ACPI: APIC BFFC0390, 0070 (r1 A_M_I_ OEMAPIC 3000826 MSFT 97)
> (XEN) ACPI: MCFG BFFC0400, 003C (r1 A_M_I_ OEMMCFG 3000826 MSFT 97)
> (XEN) ACPI: OEMB BFFCE040, 0060 (r1 A_M_I_ AMI_OEM 3000826 MSFT 97)
> (XEN) ACPI: HPET BFFC5400, 0038 (r1 A_M_I_ OEMHPET0 3000826 MSFT 97)
> (XEN) System RAM: 4095MB (4193660kB)
> (XEN) No NUMA configuration found
> (XEN) Faking a node at 0000000000000000-0000000140000000
> (XEN) Domain heap initialised
> (XEN) found SMP MP-table at 000ff780
> (XEN) DMI present.
> (XEN) APIC boot state is 'xapic'
> (XEN) Using APIC driver default
> (XEN) ACPI: PM-Timer IO Port: 0x508
> (XEN) ACPI: ACPI SLEEP INFO: pm1x_cnt[504,0], pm1x_evt[500,0]
> (XEN) ACPI: wakeup_vec[bffce00c], vec_size[20]
> (XEN) ACPI: Local APIC address 0xfee00000
> (XEN) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
> (XEN) Processor #0 15:3 APIC version 16
> (XEN) ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled)
> (XEN) Processor #1 15:3 APIC version 16
> (XEN) ACPI: IOAPIC (id[0x02] address[0xfec00000] gsi_base[0])
> (XEN) IOAPIC[0]: apic_id 2, version 17, address 0xfec00000, GSI 0-23
> (XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 0 dfl dfl)
> (XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
> (XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 14 global_irq 14 high edge)
> (XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 15 global_irq 15 high edge)
> (XEN) ACPI: IRQ0 used by override.
> (XEN) ACPI: IRQ9 used by override.
> (XEN) ACPI: IRQ14 used by override.
> (XEN) ACPI: IRQ15 used by override.
> (XEN) Enabling APIC mode: Flat. Using 1 I/O APICs
> (XEN) ACPI: HPET id: 0x10de8201 base: 0xfed00000
> (XEN) PCI: MCFG configuration 0: base e0000000 segment 0 buses 0 - 255
> (XEN) PCI: Not using MMCONFIG.
> (XEN) Table is not found!
> (XEN) Using ACPI (MADT) for SMP configuration information
> (XEN) mapped APIC to ffff82c3ffffe000 (fee00000)
> (XEN) mapped IOAPIC to ffff82c3ffffd000 (fec00000)
> (XEN) IRQ limits: 24 GSI, 376 MSI/MSI-X
> (XEN) Using scheduler: SMP Credit Scheduler (credit)
> (XEN) Detected 2611.867 MHz processor.
> (XEN) Initing memory sharing.
> (XEN) AMD K8 machine check reporting enabled
> (XEN) AMD-Vi: IOMMU not found!
> (XEN) I/O virtualisation disabled
> (XEN) Getting VERSION: 80050010
> (XEN) Getting VERSION: 80050010
> (XEN) Getting ID: 0
> (XEN) Getting LVT0: 700
> (XEN) Getting LVT1: 400
> (XEN) enabled ExtINT on CPU#0
> (XEN) ESR value before enabling vector: 0x00000004 after: 0x00000000
> (XEN) ENABLING IO-APIC IRQs
> (XEN) -> Using new ACK method
> (XEN) init IO_APIC IRQs
> (XEN) IO-APIC (apicid-pin) 2-16, 2-17, 2-18, 2-19, 2-20, 2-21, 2-22,
> 2-23 not connected.
> (XEN) ..TIMER: vector=3D0xF0 apic1=3D0 pin1=3D0 apic2=3D-1 pin2=3D-1
> (XEN) ..MP-BIOS bug: 8254 timer not connected to IO-APIC
> (XEN) ...trying to set up timer (IRQ0) through the 8259A ... failed.
> (XEN) ...trying to set up timer as Virtual Wire IRQ... failed.
> (XEN) ...trying to set up timer as ExtINT IRQ... failed :(.
> (XEN)
> (XEN) ****************************************
> (XEN) Panic on CPU 0:
> (XEN) IO-APIC + timer doesn't work! Boot with apic_verbosity=3Ddebug an=
d
> send a report. Then try booting with the 'noapic'
> option****************************************
> (XEN)
> (XEN) Reboot in five seconds...
>
>
>
> Am 20.12.2011 12:01, schrieb Florian Manschwetus:
>> Adding apic_verbosity=3Ddebug gives me that (hope nothing miss-typed a=
s I
>> have no serial console on this box). I found a lot of suggested
>> workarounds:
>> - noapic as suggested in output gives an noapic isn't support
>> - acpi_skip_timer_override has no effect at all
>>
>> Thx,
>> Florian
>>
>> (XEN) Initing memory sharing.
>> (XEN) AMD-Vi: IOMMU not found!
>> (XEN) I/O virtualisation disabled
>> (XEN) Getting VERSION: 8005010
>> (XEN) Getting VERSION: 8005010
>> (XEN) Getting ID: 0
>> (XEN) Getting LVT0: 700
>> (XEN) Getting LVT1: 400
>> (XEN) enabled ExtINT on CPU#0
>> (XEN) ESR value before enabling vector: 0x00000004 after: 0x0000000
>> (XEN) ENABLING IO-APIC IRQs
>> (XEN) -> Using new ACK method
>> (XEN) ..MP-BIOS bug: 8254 timer not connected to IO-APIC
>> (XEN)
>> (XEN) *****************************************************
>> (XEN) Panic on CPU 0:
>> (XEN) IO-APIC + timer doesn't work! Boot with apic_verbosity=3Ddebug a=
nd
>> send a report. Then try booting with hte 'noapic'
>> option****************************
>>
>>
>>
>> _______________________________________________
>> Xen-users mailing list
>> Xen-users@lists.xensource.com
>> http://lists.xensource.com/xen-users
>
>
>
>
> _______________________________________________
> Xen-users mailing list
> Xen-users@lists.xensource.com
> http://lists.xensource.com/xen-users



--------------ms070806050800030409020202
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Kryptografische Unterschrift

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFSjCC
BUYwggMuoAMCAQICAwhzEzANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4w
HAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmlu
ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMDA0
MDMxMjE2NDhaFw0xMjA0MDIxMjE2NDhaMEgxHDAaBgNVBAMTE0Zsb3JpYW4gTWFuc2Nod2V0
dXMxKDAmBgkqhkiG9w0BCQEWGUZsb3JpYW5NYW5zY2h3ZXR1c0BnbXguZGUwggEiMA0GCSqG
SIb3DQEBAQUAA4IBDwAwggEKAoIBAQDOx228LSNcMIRtatTC835J0dYDQbcsng06PdtewI0r
rwtxTSXndYotpjS257vzZOlIPMGRPUJL/FZgL7Nw8zaz2d/jCuQnzGgRukKefl2BZV4eW/xq
hrc5tStj1h7+jZyhtGtR1Jt4Y8TOXF/bjBFCoZRgrfo316LoP/zW1WY34UbW3E2hLpkbRkP7
4Tj6tgpH1TZl1UtA2skuL3GQ3+Mx/Wsh7hCNGAvrV+3BGkA5bZMrKRd1Trcz1Bla68m1WAas
xkNL/DbvgSWiIdyT7860wzcdKRS+ANlhtswsnwfj7arLNeBycQkiQeliFnQY2KBC9KZszkZ7
jdO1HgaEWKFLAgMBAAGjggEGMIIBAjAMBgNVHRMBAf8EAjAAMFYGCWCGSAGG+EIBDQRJFkdU
byBnZXQgeW91ciBvd24gY2VydGlmaWNhdGUgZm9yIEZSRUUgaGVhZCBvdmVyIHRvIGh0dHA6
Ly93d3cuQ0FjZXJ0Lm9yZzBABgNVHSUEOTA3BggrBgEFBQcDBAYIKwYBBQUHAwIGCisGAQQB
gjcKAwQGCisGAQQBgjcKAwMGCWCGSAGG+EIEATAyBggrBgEFBQcBAQQmMCQwIgYIKwYBBQUH
MAGGFmh0dHA6Ly9vY3NwLmNhY2VydC5vcmcwJAYDVR0RBB0wG4EZRmxvcmlhbk1hbnNjaHdl
dHVzQGdteC5kZTANBgkqhkiG9w0BAQUFAAOCAgEABTIxdlft8iVgfpvh+nR842ialjkFp5Fi
ow5HOGkTG1tcPczEOvApu8267JHwy390X8ZsOvxZt9QSNmGwKAeQuX1meNgRzXBWuGT5YjOH
2qtwLvXr2AIPaRB1U8Qu2iKEKqjOY8x9SBrU5cFqrN7iySlo7kvvq8DQub5BFLd6FMsCaxZI
Gyxd0FXVy57YEu/ZeknQutGS1NmGFc70hRe53DKILDh/bDO2r4yhvLOujJKjQf2kDkBoBZRI
MyACJiqxz7R+/Dog9zbqcqEiB2YCe1x8KFmgwfevrBH3+MyAhlg5lKA3DTq41kiwlpgC+unC
rgOfGoi1Y1IU/FoXgTil7G87L1IRrnVlcEcd6OiysFgwHsK6Y1ScVPoxJ3gmuqGsYDNlUxoH
U8wLRVexlTuQjCLr3kwbTUlrWfXw1b30Fkx1RludNrP8MO6vDFW4/8tOF9CApplTBZ/FpMhs
l2PF8suztvTobCuc7Z4DnqtfcqfPfcyNR610DaGOrp5eIjcn071z93qwzqOc0qxN1bcJZFM5
IAAKpvLLIlYzbK0fuHMb+xGFwCxjY6uQJrz77xpMu/bfS0LU5Xlzg+VfDFgpeUkY4tGS9e5v
qRyUN2es5+TRqNR0hmdRj3zxL1ogBtcLLHdvcxmna8n5yyHwU2eZkXEr0JW0uOT903skt/mC
/zUxggOUMIIDkAIBATCBgDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8v
d3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAf
BgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZwIDCHMTMAkGBSsOAwIaBQCgggHoMBgG
CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMTIyMTIzNDk1OVow
IwYJKoZIhvcNAQkEMRYEFPGaCdr6dPBUcpzK04Z96tjsRdOzMF8GCSqGSIb3DQEJDzFSMFAw
CwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIB
QDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBkQYJKwYBBAGCNxAEMYGDMIGAMHkxEDAOBgNV
BAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZ
Q0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNl
cnQub3JnAgMIcxMwgZMGCyqGSIb3DQEJEAILMYGDoIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0Ex
HjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWdu
aW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMIcxMw
DQYJKoZIhvcNAQEBBQAEggEAHgPpMcC1fJ/A+OOjuEpNEgkmmhye7TYGe40KlZp9f2NAD7ml
1kUK3gPQ/tRHih2I2/B/W56c527XIxP4rOhPm3E2A8K7CpSGj7tZmedVC9J35xSW8TJ38rx2
8Nljotrt3/6pWQ8m9/YJhIJnYT155jNkM6u3uTFTZAS7rlFkFzbYYfwDfNxwltOvLmqOILpX
qFnHI6ZGVU0NgzMUyy3dJ7JwJVrTio/3pI6dQAoJvFSYExNXZABAw0TRIriDGWFqdjFf+fgI
c1kxUb18r9Q5dLSiRAwL239UtxFfQxXBpvyBmCq1LJ7+E4hq65Eol0SMCukeRPF4THREbpPw
Ch8JIwAAAAAAAA==
--------------ms070806050800030409020202--


--===============2016542240821628888==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============2016542240821628888==--


From xen-devel-bounces@lists.xensource.com Wed Dec 21 23:51:46 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 Dec 2011 23: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.xensource.com>)
	id 1RdVwB-0008B9-A1; Wed, 21 Dec 2011 23:51:07 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <florianmanschwetus@gmx.de>) id 1RdVw9-0008B4-0u
	for xen-devel@lists.xensource.com; Wed, 21 Dec 2011 23:51:05 +0000
X-Env-Sender: florianmanschwetus@gmx.de
X-Msg-Ref: server-15.tower-174.messagelabs.com!1324511455!6289997!1
X-Originating-IP: [213.165.64.23]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjEzLjE2NS42NC4yMyA9PiAxMTAyMjE=\n,
	ML_RADAR_SPEW_LINKS_14,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17757 invoked from network); 21 Dec 2011 23:50:58 -0000
Received: from mailout-de.gmx.net (HELO mailout-de.gmx.net) (213.165.64.23)
	by server-15.tower-174.messagelabs.com with SMTP;
	21 Dec 2011 23:50:58 -0000
Received: (qmail invoked by alias); 21 Dec 2011 23:50:55 -0000
Received: from dslb-094-219-040-177.pools.arcor-ip.net (EHLO [192.168.222.23])
	[94.219.40.177]
	by mail.gmx.net (mp061) with SMTP; 22 Dec 2011 00:50:55 +0100
X-Authenticated: #7518697
X-Provags-ID: V01U2FsdGVkX180QIFxirk0INQIR1/BMtrcQEn8R2Fym/ce/7/VYI
	5c5jKoWxfCJpKH
Message-ID: <4EF270A7.2010705@gmx.de>
Date: Thu, 22 Dec 2011 00:49:59 +0100
From: Florian Manschwetus <florianmanschwetus@gmx.de>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:8.0) Gecko/20111121 Thunderbird/8.0
MIME-Version: 1.0
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
References: <4EF06B14.4070106@gmx.de> <4EF0B034.1090708@gmx.de>
In-Reply-To: <4EF0B034.1090708@gmx.de>
X-Y-GMX-Trusted: 0
Cc: xen-users@lists.xensource.com
Subject: Re: [Xen-devel] [Xen-users] Problem booting xen 4.1.2 on Athlon 64
	X2
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============2016542240821628888=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Dies ist eine kryptografisch unterzeichnete Nachricht im MIME-Format.

--===============2016542240821628888==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms070806050800030409020202"

Dies ist eine kryptografisch unterzeichnete Nachricht im MIME-Format.

--------------ms070806050800030409020202
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: quoted-printable

Sending to devel, maybe a BUG?

Here are the details to the used mobo:

Handle 0x0000, DMI type 0, 24 bytes
BIOS Information
         Vendor: American Megatrends Inc.
         Version: 1004
         Release Date: 03/26/2008
         Address: 0xF0000
         Runtime Size: 64 kB
         ROM Size: 512 kB
         Characteristics:
                 ISA is supported
                 PCI is supported
                 PNP is supported
                 APM is supported
                 BIOS is upgradeable
                 BIOS shadowing is allowed
                 ESCD support is available
                 Boot from CD is supported
                 Selectable boot is supported
                 BIOS ROM is socketed
                 EDD is supported
                 5.25"/1.2 MB floppy services are supported (int 13h)
                 3.5"/720 kB floppy services are supported (int 13h)
                 3.5"/2.88 MB floppy services are supported (int 13h)
                 Print screen service is supported (int 5h)
                 8042 keyboard services are supported (int 9h)
                 Serial services are supported (int 14h)
                 Printer services are supported (int 17h)
                 CGA/mono video services are supported (int 10h)
                 ACPI is supported
                 USB legacy is supported
                 LS-120 boot is supported
                 ATAPI Zip drive boot is supported
                 BIOS boot specification is supported
                 Targeted content distribution is supported
         BIOS Revision: 8.12

Handle 0x0002, DMI type 2, 15 bytes
Base Board Information
         Manufacturer: ASUSTeK Computer INC.
         Product Name: M2N-MX
         Version: Rev 1.xx
         Serial Number: MB-xxxxxxxxxx
         Asset Tag: To Be Filled By O.E.M.
         Features:
                 Board is a hosting board
                 Board is replaceable
         Location In Chassis: To Be Filled By O.E.M.
         Chassis Handle: 0x0003
         Type: Motherboard
         Contained Object Handles: 0


Am 20.12.2011 16:56, schrieb Florian Manschwetus:
> Ok, I setup a serial so I can, give you a full copy of output (also
> added some debug options I found)
>
> Booting a command list
>
> Loading Xen 4.1.2 ...
> Loading Linux x86_64-3.1.5-gentoo ...
> Loading initial ramdisk ...
> __ __ _ _ _ ____
> \ \/ /___ _ __ | || | / | |___ \
> \ // _ \ '_ \ | || |_ | | __) |
> / \ __/ | | | |__ _|| |_ / __/
> /_/\_\___|_| |_| |_|(_)_(_)_____|
>
> (XEN) Xen version 4.1.2 (@) (gcc-Version 4.6.2 (Gentoo 4.6.2 p1.0,
> pie-0.4.5) ) Thu Dec 15 17:51:19 CET 2011
> (XEN) Latest ChangeSet: unavailable
> (XEN) Console output is synchronous.
> (XEN) Bootloader: GRUB 1.99
> (XEN) Command line: placeholder sync_console console_to_ring
> com1=3D115200,8n1 console=3Dcom1,vga loglvl=3Dall lapic=3Ddebug
> apic_verbosity=3Ddebug apic=3Ddebug
> (XEN) Video information:
> (XEN) VGA is text mode 80x25, font 8x16
> (XEN) VBE/DDC methods: none; EDID transfer time: 0 seconds
> (XEN) EDID info not retrieved because no DDC retrieval method detected
> (XEN) Disc information:
> (XEN) Found 1 MBR signatures
> (XEN) Found 1 EDD information structures
> (XEN) Xen-e820 RAM map:
> (XEN) 0000000000000000 - 000000000009fc00 (usable)
> (XEN) 000000000009fc00 - 00000000000a0000 (reserved)
> (XEN) 00000000000e0000 - 0000000000100000 (reserved)
> (XEN) 0000000000100000 - 00000000bffc0000 (usable)
> (XEN) 00000000bffc0000 - 00000000bffce000 (ACPI data)
> (XEN) 00000000bffce000 - 00000000bfff0000 (ACPI NVS)
> (XEN) 00000000bfff0000 - 00000000c0000000 (reserved)
> (XEN) 00000000fec00000 - 00000000fec01000 (reserved)
> (XEN) 00000000fee00000 - 00000000fef00000 (reserved)
> (XEN) 00000000ff780000 - 0000000100000000 (reserved)
> (XEN) 0000000100000000 - 0000000140000000 (usable)
> (XEN) ACPI: RSDP 000FB840, 0024 (r2 ACPIAM)
> (XEN) ACPI: XSDT BFFC0100, 004C (r1 A_M_I_ OEMXSDT 3000826 MSFT 97)
> (XEN) ACPI: FACP BFFC0290, 00F4 (r3 A_M_I_ OEMFACP 3000826 MSFT 97)
> (XEN) ACPI: DSDT BFFC05C0, 4E38 (r1 A0557 A0557000 0 INTL 20051117)
> (XEN) ACPI: FACS BFFCE000, 0040
> (XEN) ACPI: APIC BFFC0390, 0070 (r1 A_M_I_ OEMAPIC 3000826 MSFT 97)
> (XEN) ACPI: MCFG BFFC0400, 003C (r1 A_M_I_ OEMMCFG 3000826 MSFT 97)
> (XEN) ACPI: OEMB BFFCE040, 0060 (r1 A_M_I_ AMI_OEM 3000826 MSFT 97)
> (XEN) ACPI: HPET BFFC5400, 0038 (r1 A_M_I_ OEMHPET0 3000826 MSFT 97)
> (XEN) System RAM: 4095MB (4193660kB)
> (XEN) No NUMA configuration found
> (XEN) Faking a node at 0000000000000000-0000000140000000
> (XEN) Domain heap initialised
> (XEN) found SMP MP-table at 000ff780
> (XEN) DMI present.
> (XEN) APIC boot state is 'xapic'
> (XEN) Using APIC driver default
> (XEN) ACPI: PM-Timer IO Port: 0x508
> (XEN) ACPI: ACPI SLEEP INFO: pm1x_cnt[504,0], pm1x_evt[500,0]
> (XEN) ACPI: wakeup_vec[bffce00c], vec_size[20]
> (XEN) ACPI: Local APIC address 0xfee00000
> (XEN) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
> (XEN) Processor #0 15:3 APIC version 16
> (XEN) ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled)
> (XEN) Processor #1 15:3 APIC version 16
> (XEN) ACPI: IOAPIC (id[0x02] address[0xfec00000] gsi_base[0])
> (XEN) IOAPIC[0]: apic_id 2, version 17, address 0xfec00000, GSI 0-23
> (XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 0 dfl dfl)
> (XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
> (XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 14 global_irq 14 high edge)
> (XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 15 global_irq 15 high edge)
> (XEN) ACPI: IRQ0 used by override.
> (XEN) ACPI: IRQ9 used by override.
> (XEN) ACPI: IRQ14 used by override.
> (XEN) ACPI: IRQ15 used by override.
> (XEN) Enabling APIC mode: Flat. Using 1 I/O APICs
> (XEN) ACPI: HPET id: 0x10de8201 base: 0xfed00000
> (XEN) PCI: MCFG configuration 0: base e0000000 segment 0 buses 0 - 255
> (XEN) PCI: Not using MMCONFIG.
> (XEN) Table is not found!
> (XEN) Using ACPI (MADT) for SMP configuration information
> (XEN) mapped APIC to ffff82c3ffffe000 (fee00000)
> (XEN) mapped IOAPIC to ffff82c3ffffd000 (fec00000)
> (XEN) IRQ limits: 24 GSI, 376 MSI/MSI-X
> (XEN) Using scheduler: SMP Credit Scheduler (credit)
> (XEN) Detected 2611.867 MHz processor.
> (XEN) Initing memory sharing.
> (XEN) AMD K8 machine check reporting enabled
> (XEN) AMD-Vi: IOMMU not found!
> (XEN) I/O virtualisation disabled
> (XEN) Getting VERSION: 80050010
> (XEN) Getting VERSION: 80050010
> (XEN) Getting ID: 0
> (XEN) Getting LVT0: 700
> (XEN) Getting LVT1: 400
> (XEN) enabled ExtINT on CPU#0
> (XEN) ESR value before enabling vector: 0x00000004 after: 0x00000000
> (XEN) ENABLING IO-APIC IRQs
> (XEN) -> Using new ACK method
> (XEN) init IO_APIC IRQs
> (XEN) IO-APIC (apicid-pin) 2-16, 2-17, 2-18, 2-19, 2-20, 2-21, 2-22,
> 2-23 not connected.
> (XEN) ..TIMER: vector=3D0xF0 apic1=3D0 pin1=3D0 apic2=3D-1 pin2=3D-1
> (XEN) ..MP-BIOS bug: 8254 timer not connected to IO-APIC
> (XEN) ...trying to set up timer (IRQ0) through the 8259A ... failed.
> (XEN) ...trying to set up timer as Virtual Wire IRQ... failed.
> (XEN) ...trying to set up timer as ExtINT IRQ... failed :(.
> (XEN)
> (XEN) ****************************************
> (XEN) Panic on CPU 0:
> (XEN) IO-APIC + timer doesn't work! Boot with apic_verbosity=3Ddebug an=
d
> send a report. Then try booting with the 'noapic'
> option****************************************
> (XEN)
> (XEN) Reboot in five seconds...
>
>
>
> Am 20.12.2011 12:01, schrieb Florian Manschwetus:
>> Adding apic_verbosity=3Ddebug gives me that (hope nothing miss-typed a=
s I
>> have no serial console on this box). I found a lot of suggested
>> workarounds:
>> - noapic as suggested in output gives an noapic isn't support
>> - acpi_skip_timer_override has no effect at all
>>
>> Thx,
>> Florian
>>
>> (XEN) Initing memory sharing.
>> (XEN) AMD-Vi: IOMMU not found!
>> (XEN) I/O virtualisation disabled
>> (XEN) Getting VERSION: 8005010
>> (XEN) Getting VERSION: 8005010
>> (XEN) Getting ID: 0
>> (XEN) Getting LVT0: 700
>> (XEN) Getting LVT1: 400
>> (XEN) enabled ExtINT on CPU#0
>> (XEN) ESR value before enabling vector: 0x00000004 after: 0x0000000
>> (XEN) ENABLING IO-APIC IRQs
>> (XEN) -> Using new ACK method
>> (XEN) ..MP-BIOS bug: 8254 timer not connected to IO-APIC
>> (XEN)
>> (XEN) *****************************************************
>> (XEN) Panic on CPU 0:
>> (XEN) IO-APIC + timer doesn't work! Boot with apic_verbosity=3Ddebug a=
nd
>> send a report. Then try booting with hte 'noapic'
>> option****************************
>>
>>
>>
>> _______________________________________________
>> Xen-users mailing list
>> Xen-users@lists.xensource.com
>> http://lists.xensource.com/xen-users
>
>
>
>
> _______________________________________________
> Xen-users mailing list
> Xen-users@lists.xensource.com
> http://lists.xensource.com/xen-users



--------------ms070806050800030409020202
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Kryptografische Unterschrift

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFSjCC
BUYwggMuoAMCAQICAwhzEzANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4w
HAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmlu
ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMDA0
MDMxMjE2NDhaFw0xMjA0MDIxMjE2NDhaMEgxHDAaBgNVBAMTE0Zsb3JpYW4gTWFuc2Nod2V0
dXMxKDAmBgkqhkiG9w0BCQEWGUZsb3JpYW5NYW5zY2h3ZXR1c0BnbXguZGUwggEiMA0GCSqG
SIb3DQEBAQUAA4IBDwAwggEKAoIBAQDOx228LSNcMIRtatTC835J0dYDQbcsng06PdtewI0r
rwtxTSXndYotpjS257vzZOlIPMGRPUJL/FZgL7Nw8zaz2d/jCuQnzGgRukKefl2BZV4eW/xq
hrc5tStj1h7+jZyhtGtR1Jt4Y8TOXF/bjBFCoZRgrfo316LoP/zW1WY34UbW3E2hLpkbRkP7
4Tj6tgpH1TZl1UtA2skuL3GQ3+Mx/Wsh7hCNGAvrV+3BGkA5bZMrKRd1Trcz1Bla68m1WAas
xkNL/DbvgSWiIdyT7860wzcdKRS+ANlhtswsnwfj7arLNeBycQkiQeliFnQY2KBC9KZszkZ7
jdO1HgaEWKFLAgMBAAGjggEGMIIBAjAMBgNVHRMBAf8EAjAAMFYGCWCGSAGG+EIBDQRJFkdU
byBnZXQgeW91ciBvd24gY2VydGlmaWNhdGUgZm9yIEZSRUUgaGVhZCBvdmVyIHRvIGh0dHA6
Ly93d3cuQ0FjZXJ0Lm9yZzBABgNVHSUEOTA3BggrBgEFBQcDBAYIKwYBBQUHAwIGCisGAQQB
gjcKAwQGCisGAQQBgjcKAwMGCWCGSAGG+EIEATAyBggrBgEFBQcBAQQmMCQwIgYIKwYBBQUH
MAGGFmh0dHA6Ly9vY3NwLmNhY2VydC5vcmcwJAYDVR0RBB0wG4EZRmxvcmlhbk1hbnNjaHdl
dHVzQGdteC5kZTANBgkqhkiG9w0BAQUFAAOCAgEABTIxdlft8iVgfpvh+nR842ialjkFp5Fi
ow5HOGkTG1tcPczEOvApu8267JHwy390X8ZsOvxZt9QSNmGwKAeQuX1meNgRzXBWuGT5YjOH
2qtwLvXr2AIPaRB1U8Qu2iKEKqjOY8x9SBrU5cFqrN7iySlo7kvvq8DQub5BFLd6FMsCaxZI
Gyxd0FXVy57YEu/ZeknQutGS1NmGFc70hRe53DKILDh/bDO2r4yhvLOujJKjQf2kDkBoBZRI
MyACJiqxz7R+/Dog9zbqcqEiB2YCe1x8KFmgwfevrBH3+MyAhlg5lKA3DTq41kiwlpgC+unC
rgOfGoi1Y1IU/FoXgTil7G87L1IRrnVlcEcd6OiysFgwHsK6Y1ScVPoxJ3gmuqGsYDNlUxoH
U8wLRVexlTuQjCLr3kwbTUlrWfXw1b30Fkx1RludNrP8MO6vDFW4/8tOF9CApplTBZ/FpMhs
l2PF8suztvTobCuc7Z4DnqtfcqfPfcyNR610DaGOrp5eIjcn071z93qwzqOc0qxN1bcJZFM5
IAAKpvLLIlYzbK0fuHMb+xGFwCxjY6uQJrz77xpMu/bfS0LU5Xlzg+VfDFgpeUkY4tGS9e5v
qRyUN2es5+TRqNR0hmdRj3zxL1ogBtcLLHdvcxmna8n5yyHwU2eZkXEr0JW0uOT903skt/mC
/zUxggOUMIIDkAIBATCBgDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8v
d3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAf
BgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZwIDCHMTMAkGBSsOAwIaBQCgggHoMBgG
CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMTIyMTIzNDk1OVow
IwYJKoZIhvcNAQkEMRYEFPGaCdr6dPBUcpzK04Z96tjsRdOzMF8GCSqGSIb3DQEJDzFSMFAw
CwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIB
QDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBkQYJKwYBBAGCNxAEMYGDMIGAMHkxEDAOBgNV
BAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZ
Q0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNl
cnQub3JnAgMIcxMwgZMGCyqGSIb3DQEJEAILMYGDoIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0Ex
HjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWdu
aW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMIcxMw
DQYJKoZIhvcNAQEBBQAEggEAHgPpMcC1fJ/A+OOjuEpNEgkmmhye7TYGe40KlZp9f2NAD7ml
1kUK3gPQ/tRHih2I2/B/W56c527XIxP4rOhPm3E2A8K7CpSGj7tZmedVC9J35xSW8TJ38rx2
8Nljotrt3/6pWQ8m9/YJhIJnYT155jNkM6u3uTFTZAS7rlFkFzbYYfwDfNxwltOvLmqOILpX
qFnHI6ZGVU0NgzMUyy3dJ7JwJVrTio/3pI6dQAoJvFSYExNXZABAw0TRIriDGWFqdjFf+fgI
c1kxUb18r9Q5dLSiRAwL239UtxFfQxXBpvyBmCq1LJ7+E4hq65Eol0SMCukeRPF4THREbpPw
Ch8JIwAAAAAAAA==
--------------ms070806050800030409020202--


--===============2016542240821628888==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============2016542240821628888==--


From xen-devel-bounces@lists.xensource.com Thu Dec 22 01:31:29 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 Dec 2011 01: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.xensource.com>)
	id 1RdXUf-0004lL-En; Thu, 22 Dec 2011 01:30:49 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RdXUe-0004lD-0a
	for xen-devel@lists.xensource.com; Thu, 22 Dec 2011 01:30:48 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1324517441!6463472!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Nzc4MA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21925 invoked from network); 22 Dec 2011 01:30:41 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Dec 2011 01:30:41 -0000
X-IronPort-AV: E=Sophos;i="4.71,390,1320624000"; 
   d="scan'208";a="9620894"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Dec 2011 01:30:40 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 22 Dec 2011 01:30:40 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RdXUV-0006U1-U6;
	Thu, 22 Dec 2011 01:30:39 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RdXUV-0002DS-OD;
	Thu, 22 Dec 2011 01:30:39 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10577-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 22 Dec 2011 01:30:39 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10577: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10577 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10577/

Regressions :-(

Tests which did not succeed and are blocking,including tests which could not be run:
 test-amd64-i386-xl-credit2   16 guest-start.2             fail REGR. vs. 10564
 test-i386-i386-pv            16 guest-start.2             fail REGR. vs. 10564
 test-i386-i386-xl            16 guest-start.2             fail REGR. vs. 10564
 test-amd64-amd64-xl-win7-amd64  7 windows-install         fail REGR. vs. 10564

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-pv          16 guest-start.2               fail pass in 10571
 test-amd64-i386-pv           16 guest-start.2               fail pass in 10571
 test-amd64-i386-xl-multivcpu 16 guest-start.2               fail pass in 10571
 test-amd64-i386-xl           16 guest-start.2               fail pass in 10571
 test-amd64-amd64-xl-sedf-pin 16 guest-start.2               fail pass in 10571
 test-amd64-i386-rhel6hvm-amd  7 redhat-install              fail pass in 10571
 test-amd64-i386-xl-win7-amd64  7 windows-install            fail pass in 10571
 test-amd64-amd64-xl          16 guest-start.2               fail pass in 10571
 test-amd64-amd64-xl-sedf      7 debian-install              fail pass in 10571
 test-amd64-i386-xl-credit2    7 debian-install     fail in 10571 pass in 10577

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2         fail in 10571 never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop           fail in 10571 never pass

version targeted for testing:
 xen                  492914c65838
baseline version:
 xen                  e56500f95b6a

------------------------------------------------------------
People who touched revisions under test:
  Anthony PERARD <anthony.perard@citrix.com>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          fail    
 test-amd64-i386-xl                                           fail    
 test-i386-i386-xl                                            fail    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          fail    
 test-amd64-i386-pv                                           fail    
 test-i386-i386-pv                                            fail    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   24445:492914c65838
tag:         tip
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Wed Dec 21 10:47:30 2011 +0000
    
    libxl: report failure to reboot/shutdown due to lackof PV interfaces to caller
    
    This allow the caller to react as they think is appropriate. xl now prints a
    message much like the library did previously, although hopefully somewhat more
    informative.
    
    Update the xl(1) man page to be similarly more informative.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Committed-by: Ian Jackson <ian.jackson.citrix.com>
    Acked-by: Ian Jackson <ian.jackson.citrix.com>
    
    
changeset:   24444:1c3f9cac204e
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Wed Dec 21 10:47:11 2011 +0000
    
    libxl: split libxl_domain_shutdown into libxl_domain_shutdown,..._reboot
    
    The other integer request types which shutdown supported are not
    useful. Specifically:
    
     * "suspend" is not usable via this interface since it requires other
       scaffolding, libxl_domain_suspend provides this already.
     * "halt" is the same as "poweroff".
     * "crash" is unused and at least Linux does not implement it. If a user
       steps forward then libxl_domain_crash is trivial to add.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Committed-by: Ian Jackson <ian.jackson.citrix.com>
    Acked-by: Ian Jackson <ian.jackson.citrix.com>
    
    
changeset:   24443:b3455a4d2298
user:        Anthony PERARD <anthony.perard@citrix.com>
date:        Wed Dec 21 14:47:26 2011 +0000
    
    libxl: Fix, specify open mode to QEMU state file.
    
    Reported-by: Olaf Hering <olaf@aepfle.de>
    Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24442:16dc2a1cd40f
user:        Jan Beulich <jbeulich@suse.com>
date:        Wed Dec 21 14:26:09 2011 +0100
    
    x86: reduce scope of some symbols used with reset_stack_and_jump()
    
    By making the macro properly advertise the use of the input symbol to
    the compiler, it is no longer necessary for them to be global if
    they're defined and used in just one source file.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24441:73ab77073140
user:        Jan Beulich <jbeulich@suse.com>
date:        Wed Dec 21 09:20:15 2011 +0100
    
    x86: move some function scope statics into .init.data
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24440:e56500f95b6a
user:        Daniel De Graaf <dgdegra@tycho.nsa.gov>
date:        Tue Dec 20 18:19:53 2011 +0000
    
    flask/policy: Update example policy
    
    Rewrite the example policy to make it easier to understand and
    demonstrate some of the security goals that FLASK can enforce.
    
    Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
    Committed-by: Ian Jackson <ian.jackson.citrix.com>
    
    
========================================
commit 54e24021005458ad0a361c1d83011b751726a94b
Author: Ian Jackson <ian.jackson@eu.citrix.com>
Date:   Thu Dec 8 16:38:06 2011 +0000

    qemu_get_timer: Provide a comment about the behaviour on ts==NULL
    
    Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 22 01:31:29 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 Dec 2011 01: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.xensource.com>)
	id 1RdXUf-0004lL-En; Thu, 22 Dec 2011 01:30:49 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RdXUe-0004lD-0a
	for xen-devel@lists.xensource.com; Thu, 22 Dec 2011 01:30:48 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1324517441!6463472!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Nzc4MA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21925 invoked from network); 22 Dec 2011 01:30:41 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Dec 2011 01:30:41 -0000
X-IronPort-AV: E=Sophos;i="4.71,390,1320624000"; 
   d="scan'208";a="9620894"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Dec 2011 01:30:40 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 22 Dec 2011 01:30:40 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RdXUV-0006U1-U6;
	Thu, 22 Dec 2011 01:30:39 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RdXUV-0002DS-OD;
	Thu, 22 Dec 2011 01:30:39 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10577-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 22 Dec 2011 01:30:39 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10577: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10577 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10577/

Regressions :-(

Tests which did not succeed and are blocking,including tests which could not be run:
 test-amd64-i386-xl-credit2   16 guest-start.2             fail REGR. vs. 10564
 test-i386-i386-pv            16 guest-start.2             fail REGR. vs. 10564
 test-i386-i386-xl            16 guest-start.2             fail REGR. vs. 10564
 test-amd64-amd64-xl-win7-amd64  7 windows-install         fail REGR. vs. 10564

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-pv          16 guest-start.2               fail pass in 10571
 test-amd64-i386-pv           16 guest-start.2               fail pass in 10571
 test-amd64-i386-xl-multivcpu 16 guest-start.2               fail pass in 10571
 test-amd64-i386-xl           16 guest-start.2               fail pass in 10571
 test-amd64-amd64-xl-sedf-pin 16 guest-start.2               fail pass in 10571
 test-amd64-i386-rhel6hvm-amd  7 redhat-install              fail pass in 10571
 test-amd64-i386-xl-win7-amd64  7 windows-install            fail pass in 10571
 test-amd64-amd64-xl          16 guest-start.2               fail pass in 10571
 test-amd64-amd64-xl-sedf      7 debian-install              fail pass in 10571
 test-amd64-i386-xl-credit2    7 debian-install     fail in 10571 pass in 10577

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2         fail in 10571 never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop           fail in 10571 never pass

version targeted for testing:
 xen                  492914c65838
baseline version:
 xen                  e56500f95b6a

------------------------------------------------------------
People who touched revisions under test:
  Anthony PERARD <anthony.perard@citrix.com>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          fail    
 test-amd64-i386-xl                                           fail    
 test-i386-i386-xl                                            fail    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          fail    
 test-amd64-i386-pv                                           fail    
 test-i386-i386-pv                                            fail    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   24445:492914c65838
tag:         tip
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Wed Dec 21 10:47:30 2011 +0000
    
    libxl: report failure to reboot/shutdown due to lackof PV interfaces to caller
    
    This allow the caller to react as they think is appropriate. xl now prints a
    message much like the library did previously, although hopefully somewhat more
    informative.
    
    Update the xl(1) man page to be similarly more informative.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Committed-by: Ian Jackson <ian.jackson.citrix.com>
    Acked-by: Ian Jackson <ian.jackson.citrix.com>
    
    
changeset:   24444:1c3f9cac204e
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Wed Dec 21 10:47:11 2011 +0000
    
    libxl: split libxl_domain_shutdown into libxl_domain_shutdown,..._reboot
    
    The other integer request types which shutdown supported are not
    useful. Specifically:
    
     * "suspend" is not usable via this interface since it requires other
       scaffolding, libxl_domain_suspend provides this already.
     * "halt" is the same as "poweroff".
     * "crash" is unused and at least Linux does not implement it. If a user
       steps forward then libxl_domain_crash is trivial to add.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Committed-by: Ian Jackson <ian.jackson.citrix.com>
    Acked-by: Ian Jackson <ian.jackson.citrix.com>
    
    
changeset:   24443:b3455a4d2298
user:        Anthony PERARD <anthony.perard@citrix.com>
date:        Wed Dec 21 14:47:26 2011 +0000
    
    libxl: Fix, specify open mode to QEMU state file.
    
    Reported-by: Olaf Hering <olaf@aepfle.de>
    Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24442:16dc2a1cd40f
user:        Jan Beulich <jbeulich@suse.com>
date:        Wed Dec 21 14:26:09 2011 +0100
    
    x86: reduce scope of some symbols used with reset_stack_and_jump()
    
    By making the macro properly advertise the use of the input symbol to
    the compiler, it is no longer necessary for them to be global if
    they're defined and used in just one source file.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24441:73ab77073140
user:        Jan Beulich <jbeulich@suse.com>
date:        Wed Dec 21 09:20:15 2011 +0100
    
    x86: move some function scope statics into .init.data
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24440:e56500f95b6a
user:        Daniel De Graaf <dgdegra@tycho.nsa.gov>
date:        Tue Dec 20 18:19:53 2011 +0000
    
    flask/policy: Update example policy
    
    Rewrite the example policy to make it easier to understand and
    demonstrate some of the security goals that FLASK can enforce.
    
    Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
    Committed-by: Ian Jackson <ian.jackson.citrix.com>
    
    
========================================
commit 54e24021005458ad0a361c1d83011b751726a94b
Author: Ian Jackson <ian.jackson@eu.citrix.com>
Date:   Thu Dec 8 16:38:06 2011 +0000

    qemu_get_timer: Provide a comment about the behaviour on ts==NULL
    
    Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 22 01:33:30 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 Dec 2011 01:33:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdXWl-0004pe-1k; Thu, 22 Dec 2011 01:32:59 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <gang.wei@intel.com>) id 1RdXWj-0004pI-8i
	for xen-devel@lists.xensource.com; Thu, 22 Dec 2011 01:32:57 +0000
X-Env-Sender: gang.wei@intel.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1324517570!8393103!1
X-Originating-IP: [143.182.124.37]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjE1NDQ2\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16277 invoked from network); 22 Dec 2011 01:32:51 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37)
	by server-9.tower-216.messagelabs.com with SMTP;
	22 Dec 2011 01:32:51 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga102.ch.intel.com with ESMTP; 21 Dec 2011 17:32:49 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="88323182"
Received: from pgsmsx602.gar.corp.intel.com ([10.221.43.81])
	by azsmga001.ch.intel.com with ESMTP; 21 Dec 2011 17:32:48 -0800
Received: from pgsmsx151.gar.corp.intel.com (172.30.236.41) by
	pgsmsx602.gar.corp.intel.com (10.221.43.81) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Thu, 22 Dec 2011 09:32:03 +0800
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	PGSMSX151.gar.corp.intel.com (172.30.236.41) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Thu, 22 Dec 2011 09:32:02 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.38]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.223]) with mapi id
	14.01.0355.002; Thu, 22 Dec 2011 09:32:01 +0800
From: "Wei, Gang" <gang.wei@intel.com>
To: Tim Deegan <tim@xen.org>
Thread-Topic: [patch] x86: Add a delay between INIT & SIPIs for AP bring-up
	in X2APIC case
Thread-Index: AczAAslz2iL7OBXBT0+nwXPeOaB7qgARIT5g
Date: Thu, 22 Dec 2011 01:32:00 +0000
Message-ID: <D0B11485C64D4B47B66902F8A4E901BE9146@SHSMSX101.ccr.corp.intel.com>
References: <F26D193E20BBDC42A43B611D1BDEDE7135CEEEAE56@shsmsx502.ccr.corp.intel.com>
	<CB177C28.365E3%keir@xen.org>
	<F26D193E20BBDC42A43B611D1BDEDE7135CEEEAE63@shsmsx502.ccr.corp.intel.com>
	<F26D193E20BBDC42A43B611D1BDEDE7135CEEEAE65@shsmsx502.ccr.corp.intel.com>
	<20111221170539.GA72385@ocelot.phlegethon.org>
In-Reply-To: <20111221170539.GA72385@ocelot.phlegethon.org>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, "Tim
	Deegan \(3P\)" <Tim.Deegan@citrix.com>, "Cihula,
	Joseph" <joseph.cihula@intel.com>,
	"tboot-devel@lists.sourceforge.net" <tboot-devel@lists.sourceforge.net>,
	Jan Beulich <jbeulich@suse.com>, "Wei, Gang" <gang.wei@intel.com>
Subject: Re: [Xen-devel] [patch] x86: Add a delay between INIT & SIPIs for
 AP bring-up in X2APIC case
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Tim Deegan wrote on=A02011-12-22:
> At 12:29 +0000 on 21 Dec (1324470582), Wei, Gang wrote:
>> Without this delay, Xen could not bring APs up while working with
>> TXT/tboot, because tboot need some time in APs to handle INIT before
>> becoming ready for receiving SIPIs. (this delay was removed as part
>> of c/s 23724 by Tim Deegan)
> =

> It was removed because I was seeing the opposite problem -- if there
> was a delay, the AP did not come up.  Unfortunately I don;'t have
> sucah a machine available any more, so I can't check whether this breaks =
boot there.
> =

> Is this something that can be fixed in tboot?  If not, than this patch
> is OK, provided it gets a code comment explaining _why_ tboot needs the d=
elay.

First, Linux kernel always place a delay between INIT & SIPIs.

Second, with tboot AP is actually spinning in a mini-guest before receiving=
 INIT, upon receiving INIT ipi, AP need time to VMExit, update VMCS to trac=
king SIPIs and VMResume. After that SIPI is able to be trapped by APs. This=
 is MUST if giving no change to current AP bring-up method(INIT-SIPI-SIPI) =
for tboot.

I have provided a resent patch with code comment in a previous reply.

Jimmy

> =

> Cheers,
> =

> Tim.
> =

>> diff -r d1aefee43af1 xen/arch/x86/smpboot.c
>> --- a/xen/arch/x86/smpboot.c    Wed Dec 21 18:51:31 2011 +0800
>> +++ b/xen/arch/x86/smpboot.c    Wed Dec 21 20:26:39 2011 +0800
>> @@ -42,6 +42,7 @@
>>  #include <asm/msr.h> #include <asm/mtrr.h> #include <asm/time.h>
>>  +#include <asm/tboot.h> #include <mach_apic.h> #include
>>  <mach_wakecpu.h> #include <smpboot_hooks.h>
>> @@ -463,6 +464,10 @@ static int wakeup_secondary_cpu(int phys
>>              send_status =3D apic_read(APIC_ICR) & APIC_ICR_BUSY;
>>          } while ( send_status && (timeout++ < 1000) );
>>      }
>> +    else if ( tboot_in_measured_env() )
>> +    {
>> +        udelay(10);
>> +    }
>> =

>>      /*
>>       * Should we send STARTUP IPIs ?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 22 01:33:30 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 Dec 2011 01:33:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdXWl-0004pe-1k; Thu, 22 Dec 2011 01:32:59 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <gang.wei@intel.com>) id 1RdXWj-0004pI-8i
	for xen-devel@lists.xensource.com; Thu, 22 Dec 2011 01:32:57 +0000
X-Env-Sender: gang.wei@intel.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1324517570!8393103!1
X-Originating-IP: [143.182.124.37]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjE1NDQ2\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16277 invoked from network); 22 Dec 2011 01:32:51 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37)
	by server-9.tower-216.messagelabs.com with SMTP;
	22 Dec 2011 01:32:51 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga102.ch.intel.com with ESMTP; 21 Dec 2011 17:32:49 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="88323182"
Received: from pgsmsx602.gar.corp.intel.com ([10.221.43.81])
	by azsmga001.ch.intel.com with ESMTP; 21 Dec 2011 17:32:48 -0800
Received: from pgsmsx151.gar.corp.intel.com (172.30.236.41) by
	pgsmsx602.gar.corp.intel.com (10.221.43.81) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Thu, 22 Dec 2011 09:32:03 +0800
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	PGSMSX151.gar.corp.intel.com (172.30.236.41) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Thu, 22 Dec 2011 09:32:02 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.38]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.223]) with mapi id
	14.01.0355.002; Thu, 22 Dec 2011 09:32:01 +0800
From: "Wei, Gang" <gang.wei@intel.com>
To: Tim Deegan <tim@xen.org>
Thread-Topic: [patch] x86: Add a delay between INIT & SIPIs for AP bring-up
	in X2APIC case
Thread-Index: AczAAslz2iL7OBXBT0+nwXPeOaB7qgARIT5g
Date: Thu, 22 Dec 2011 01:32:00 +0000
Message-ID: <D0B11485C64D4B47B66902F8A4E901BE9146@SHSMSX101.ccr.corp.intel.com>
References: <F26D193E20BBDC42A43B611D1BDEDE7135CEEEAE56@shsmsx502.ccr.corp.intel.com>
	<CB177C28.365E3%keir@xen.org>
	<F26D193E20BBDC42A43B611D1BDEDE7135CEEEAE63@shsmsx502.ccr.corp.intel.com>
	<F26D193E20BBDC42A43B611D1BDEDE7135CEEEAE65@shsmsx502.ccr.corp.intel.com>
	<20111221170539.GA72385@ocelot.phlegethon.org>
In-Reply-To: <20111221170539.GA72385@ocelot.phlegethon.org>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, "Tim
	Deegan \(3P\)" <Tim.Deegan@citrix.com>, "Cihula,
	Joseph" <joseph.cihula@intel.com>,
	"tboot-devel@lists.sourceforge.net" <tboot-devel@lists.sourceforge.net>,
	Jan Beulich <jbeulich@suse.com>, "Wei, Gang" <gang.wei@intel.com>
Subject: Re: [Xen-devel] [patch] x86: Add a delay between INIT & SIPIs for
 AP bring-up in X2APIC case
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Tim Deegan wrote on=A02011-12-22:
> At 12:29 +0000 on 21 Dec (1324470582), Wei, Gang wrote:
>> Without this delay, Xen could not bring APs up while working with
>> TXT/tboot, because tboot need some time in APs to handle INIT before
>> becoming ready for receiving SIPIs. (this delay was removed as part
>> of c/s 23724 by Tim Deegan)
> =

> It was removed because I was seeing the opposite problem -- if there
> was a delay, the AP did not come up.  Unfortunately I don;'t have
> sucah a machine available any more, so I can't check whether this breaks =
boot there.
> =

> Is this something that can be fixed in tboot?  If not, than this patch
> is OK, provided it gets a code comment explaining _why_ tboot needs the d=
elay.

First, Linux kernel always place a delay between INIT & SIPIs.

Second, with tboot AP is actually spinning in a mini-guest before receiving=
 INIT, upon receiving INIT ipi, AP need time to VMExit, update VMCS to trac=
king SIPIs and VMResume. After that SIPI is able to be trapped by APs. This=
 is MUST if giving no change to current AP bring-up method(INIT-SIPI-SIPI) =
for tboot.

I have provided a resent patch with code comment in a previous reply.

Jimmy

> =

> Cheers,
> =

> Tim.
> =

>> diff -r d1aefee43af1 xen/arch/x86/smpboot.c
>> --- a/xen/arch/x86/smpboot.c    Wed Dec 21 18:51:31 2011 +0800
>> +++ b/xen/arch/x86/smpboot.c    Wed Dec 21 20:26:39 2011 +0800
>> @@ -42,6 +42,7 @@
>>  #include <asm/msr.h> #include <asm/mtrr.h> #include <asm/time.h>
>>  +#include <asm/tboot.h> #include <mach_apic.h> #include
>>  <mach_wakecpu.h> #include <smpboot_hooks.h>
>> @@ -463,6 +464,10 @@ static int wakeup_secondary_cpu(int phys
>>              send_status =3D apic_read(APIC_ICR) & APIC_ICR_BUSY;
>>          } while ( send_status && (timeout++ < 1000) );
>>      }
>> +    else if ( tboot_in_measured_env() )
>> +    {
>> +        udelay(10);
>> +    }
>> =

>>      /*
>>       * Should we send STARTUP IPIs ?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 22 03:52:58 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 Dec 2011 03:52:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdZhg-0006tN-0a; Thu, 22 Dec 2011 03:52:24 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RdZhe-0006tI-2t
	for xen-devel@lists.xensource.com; Thu, 22 Dec 2011 03:52:22 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1324525936!8403303!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Nzc4MA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16049 invoked from network); 22 Dec 2011 03:52:16 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Dec 2011 03:52:16 -0000
X-IronPort-AV: E=Sophos;i="4.71,391,1320624000"; 
   d="scan'208";a="9621519"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Dec 2011 03:52:15 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 22 Dec 2011 03:52:15 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RdZhX-0007GV-2D;
	Thu, 22 Dec 2011 03:52:15 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RdZhW-0005KU-VR;
	Thu, 22 Dec 2011 03:52:15 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10581-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 22 Dec 2011 03:52:14 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux test] 10581: FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10581 linux real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10581/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,including tests which could not be run:
 build-amd64-pvops             1 hosts-allocate               broken   in 10565

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf     16 guest-start.2               fail pass in 10570
 test-amd64-i386-rhel6hvm-intel  7 redhat-install            fail pass in 10570
 test-amd64-i386-xl-credit2   16 guest-start.2               fail pass in 10570
 test-i386-i386-pv            16 guest-start.2               fail pass in 10570
 test-i386-i386-xl            16 guest-start.2               fail pass in 10570
 test-amd64-i386-xl-multivcpu 16 guest-start.2               fail pass in 10565
 test-amd64-i386-xl           16 guest-start.2               fail pass in 10570
 test-amd64-amd64-xl          16 guest-start.2               fail pass in 10570
 test-amd64-i386-rhel6hvm-amd  7 redhat-install              fail pass in 10570
 test-amd64-i386-win-vcpus1    7 windows-install             fail pass in 10574
 test-amd64-i386-win           7 windows-install    fail in 10570 pass in 10581
 test-amd64-amd64-win          7 windows-install    fail in 10570 pass in 10581
 test-amd64-amd64-xl-win       7 windows-install    fail in 10570 pass in 10581
 test-amd64-i386-xl-win-vcpus1  7 windows-install   fail in 10565 pass in 10581
 test-amd64-i386-xl-credit2    9 guest-start        fail in 10574 pass in 10581
 test-amd64-i386-pv           16 guest-start.2      fail in 10574 pass in 10581
 test-amd64-amd64-pv          16 guest-start.2      fail in 10574 pass in 10581
 test-i386-i386-win            7 windows-install    fail in 10574 pass in 10581

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-xl-sedf-pin 16 guest-start.2             fail blocked in 9095
 test-amd64-i386-xl-win7-amd64  7 windows-install          fail blocked in 9095
 test-amd64-amd64-xl-winxpsp3  7 windows-install           fail blocked in 9095
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64  7 windows-install              fail never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2       fail in 10570 never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2         fail in 10570 never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop           fail in 10570 never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop            fail in 10570 never pass
 test-i386-i386-xl-winxpsp3    7 windows-install  fail in 10570 blocked in 9095
 test-amd64-i386-xl-winxpsp3-vcpus1 7 windows-install fail in 10570 blocked in 9095
 test-amd64-i386-win-vcpus1   16 leak-check/check      fail in 10570 never pass
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)     blocked in 10565 n/a
 test-amd64-amd64-xl-sedf-pin  1 xen-build-check(1)        blocked in 10565 n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)        blocked in 10565 n/a
 test-amd64-amd64-pair         1 xen-build-check(1)        blocked in 10565 n/a
 test-amd64-amd64-pv           1 xen-build-check(1)        blocked in 10565 n/a
 test-amd64-amd64-xl           1 xen-build-check(1)        blocked in 10565 n/a
 test-amd64-amd64-xl-winxpsp3  1 xen-build-check(1)        blocked in 10565 n/a
 build-amd64-pvops             2 logs-capture(2)     broken in 10565 never pass
 test-amd64-i386-xend-winxpsp3  7 windows-install fail in 10565 blocked in 9095
 test-amd64-amd64-win          1 xen-build-check(1)        blocked in 10565 n/a
 test-amd64-amd64-xl-win       1 xen-build-check(1)        blocked in 10565 n/a
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)      blocked in 10565 n/a

version targeted for testing:
 linux                59b1ffe039ce366305d48176b7fccce29ce729d3
baseline version:
 linux                6bec8b4a4c14095d0b7ce424db9d583c3decae6c

------------------------------------------------------------
People who touched revisions under test:
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          fail    
 test-amd64-i386-xl                                           fail    
 test-i386-i386-xl                                            fail    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            fail    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
commit 59b1ffe039ce366305d48176b7fccce29ce729d3
Merge: cacd265... 60b1e4f...
Author: Jeremy Fitzhardinge <jeremy@goop.org>
Date:   Sat Dec 10 00:20:33 2011 -0800

    Merge commit 'v2.6.32.50' into xen/next-2.6.32
    
    * commit 'v2.6.32.50': (28 commits)
      Linux 2.6.32.50
      clockevents: Set noop handler in clockevents_exchange_device()
      tick-broadcast: Stop active broadcast device when replacing it
      genirq: Fix race condition when stopping the irq thread
      oprofile, x86: Fix crash when unloading module (nmi timer mode)
      x86/mpparse: Account for bus types other than ISA and PCI
      sched, x86: Avoid unnecessary overflow in sched_clock
      cifs: fix cifs stable patch cifs-fix-oplock-break-handling-try-2.patch
      SCSI: Silencing 'killing requests for dead queue'
      SCSI: scsi_lib: fix potential NULL dereference
      USB: usb-storage: unusual_devs entry for Kingston DT 101 G2
      usb: option: add SIMCom SIM5218
      usb: ftdi_sio: add PID for Propox ISPcable III
      USB: whci-hcd: fix endian conversion in qset_clear()
      Staging: comedi: fix signal handling in read and write
      staging: comedi: fix oops for USB DAQ devices.
      staging: usbip: bugfix for deadlock
      gro: reset vlan_tci on reuse
      nl80211: fix MAC address validation
      p54spi: Fix workqueue deadlock
      ...

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 22 03:52:58 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 Dec 2011 03:52:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdZhg-0006tN-0a; Thu, 22 Dec 2011 03:52:24 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RdZhe-0006tI-2t
	for xen-devel@lists.xensource.com; Thu, 22 Dec 2011 03:52:22 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1324525936!8403303!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Nzc4MA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16049 invoked from network); 22 Dec 2011 03:52:16 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Dec 2011 03:52:16 -0000
X-IronPort-AV: E=Sophos;i="4.71,391,1320624000"; 
   d="scan'208";a="9621519"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Dec 2011 03:52:15 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 22 Dec 2011 03:52:15 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RdZhX-0007GV-2D;
	Thu, 22 Dec 2011 03:52:15 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RdZhW-0005KU-VR;
	Thu, 22 Dec 2011 03:52:15 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10581-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 22 Dec 2011 03:52:14 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux test] 10581: FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10581 linux real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10581/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,including tests which could not be run:
 build-amd64-pvops             1 hosts-allocate               broken   in 10565

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf     16 guest-start.2               fail pass in 10570
 test-amd64-i386-rhel6hvm-intel  7 redhat-install            fail pass in 10570
 test-amd64-i386-xl-credit2   16 guest-start.2               fail pass in 10570
 test-i386-i386-pv            16 guest-start.2               fail pass in 10570
 test-i386-i386-xl            16 guest-start.2               fail pass in 10570
 test-amd64-i386-xl-multivcpu 16 guest-start.2               fail pass in 10565
 test-amd64-i386-xl           16 guest-start.2               fail pass in 10570
 test-amd64-amd64-xl          16 guest-start.2               fail pass in 10570
 test-amd64-i386-rhel6hvm-amd  7 redhat-install              fail pass in 10570
 test-amd64-i386-win-vcpus1    7 windows-install             fail pass in 10574
 test-amd64-i386-win           7 windows-install    fail in 10570 pass in 10581
 test-amd64-amd64-win          7 windows-install    fail in 10570 pass in 10581
 test-amd64-amd64-xl-win       7 windows-install    fail in 10570 pass in 10581
 test-amd64-i386-xl-win-vcpus1  7 windows-install   fail in 10565 pass in 10581
 test-amd64-i386-xl-credit2    9 guest-start        fail in 10574 pass in 10581
 test-amd64-i386-pv           16 guest-start.2      fail in 10574 pass in 10581
 test-amd64-amd64-pv          16 guest-start.2      fail in 10574 pass in 10581
 test-i386-i386-win            7 windows-install    fail in 10574 pass in 10581

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-xl-sedf-pin 16 guest-start.2             fail blocked in 9095
 test-amd64-i386-xl-win7-amd64  7 windows-install          fail blocked in 9095
 test-amd64-amd64-xl-winxpsp3  7 windows-install           fail blocked in 9095
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64  7 windows-install              fail never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2       fail in 10570 never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2         fail in 10570 never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop           fail in 10570 never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop            fail in 10570 never pass
 test-i386-i386-xl-winxpsp3    7 windows-install  fail in 10570 blocked in 9095
 test-amd64-i386-xl-winxpsp3-vcpus1 7 windows-install fail in 10570 blocked in 9095
 test-amd64-i386-win-vcpus1   16 leak-check/check      fail in 10570 never pass
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)     blocked in 10565 n/a
 test-amd64-amd64-xl-sedf-pin  1 xen-build-check(1)        blocked in 10565 n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)        blocked in 10565 n/a
 test-amd64-amd64-pair         1 xen-build-check(1)        blocked in 10565 n/a
 test-amd64-amd64-pv           1 xen-build-check(1)        blocked in 10565 n/a
 test-amd64-amd64-xl           1 xen-build-check(1)        blocked in 10565 n/a
 test-amd64-amd64-xl-winxpsp3  1 xen-build-check(1)        blocked in 10565 n/a
 build-amd64-pvops             2 logs-capture(2)     broken in 10565 never pass
 test-amd64-i386-xend-winxpsp3  7 windows-install fail in 10565 blocked in 9095
 test-amd64-amd64-win          1 xen-build-check(1)        blocked in 10565 n/a
 test-amd64-amd64-xl-win       1 xen-build-check(1)        blocked in 10565 n/a
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)      blocked in 10565 n/a

version targeted for testing:
 linux                59b1ffe039ce366305d48176b7fccce29ce729d3
baseline version:
 linux                6bec8b4a4c14095d0b7ce424db9d583c3decae6c

------------------------------------------------------------
People who touched revisions under test:
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          fail    
 test-amd64-i386-xl                                           fail    
 test-i386-i386-xl                                            fail    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            fail    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
commit 59b1ffe039ce366305d48176b7fccce29ce729d3
Merge: cacd265... 60b1e4f...
Author: Jeremy Fitzhardinge <jeremy@goop.org>
Date:   Sat Dec 10 00:20:33 2011 -0800

    Merge commit 'v2.6.32.50' into xen/next-2.6.32
    
    * commit 'v2.6.32.50': (28 commits)
      Linux 2.6.32.50
      clockevents: Set noop handler in clockevents_exchange_device()
      tick-broadcast: Stop active broadcast device when replacing it
      genirq: Fix race condition when stopping the irq thread
      oprofile, x86: Fix crash when unloading module (nmi timer mode)
      x86/mpparse: Account for bus types other than ISA and PCI
      sched, x86: Avoid unnecessary overflow in sched_clock
      cifs: fix cifs stable patch cifs-fix-oplock-break-handling-try-2.patch
      SCSI: Silencing 'killing requests for dead queue'
      SCSI: scsi_lib: fix potential NULL dereference
      USB: usb-storage: unusual_devs entry for Kingston DT 101 G2
      usb: option: add SIMCom SIM5218
      usb: ftdi_sio: add PID for Propox ISPcable III
      USB: whci-hcd: fix endian conversion in qset_clear()
      Staging: comedi: fix signal handling in read and write
      staging: comedi: fix oops for USB DAQ devices.
      staging: usbip: bugfix for deadlock
      gro: reset vlan_tci on reuse
      nl80211: fix MAC address validation
      p54spi: Fix workqueue deadlock
      ...

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 22 06:14:30 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 Dec 2011 06: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.xensource.com>)
	id 1RdbuV-0008Mj-89; Thu, 22 Dec 2011 06:13:47 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RdbuT-0008Mc-BS
	for xen-devel@lists.xensource.com; Thu, 22 Dec 2011 06:13:45 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1324534418!8220367!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Nzc4MA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13543 invoked from network); 22 Dec 2011 06:13:39 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Dec 2011 06:13:39 -0000
X-IronPort-AV: E=Sophos;i="4.71,391,1320624000"; 
   d="scan'208";a="9622523"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Dec 2011 06:13:38 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 22 Dec 2011 06:13:38 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RdbuM-00082X-C5;
	Thu, 22 Dec 2011 06:13:38 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RdbuM-0008Lh-9W;
	Thu, 22 Dec 2011 06:13:38 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10585-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 22 Dec 2011 06:13:38 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10585: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10585 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10585/

Regressions :-(

Tests which did not succeed and are blocking,including tests which could not be run:
 test-amd64-i386-xl-credit2   16 guest-start.2             fail REGR. vs. 10564
 test-i386-i386-pv            16 guest-start.2             fail REGR. vs. 10564
 test-i386-i386-xl            16 guest-start.2             fail REGR. vs. 10564
 test-amd64-amd64-xl-win7-amd64  7 windows-install         fail REGR. vs. 10564

Tests which are failing intermittently (not blocking):
 test-amd64-i386-rhel6hvm-intel  7 redhat-install            fail pass in 10577
 test-amd64-amd64-pv          16 guest-start.2               fail pass in 10571
 test-amd64-i386-pv           16 guest-start.2               fail pass in 10571
 test-amd64-i386-xl-multivcpu 16 guest-start.2               fail pass in 10571
 test-amd64-amd64-xl-sedf-pin 16 guest-start.2               fail pass in 10571
 test-amd64-i386-xl           16 guest-start.2               fail pass in 10571
 test-amd64-i386-rhel6hvm-amd  7 redhat-install              fail pass in 10571
 test-amd64-i386-xl-win7-amd64  7 windows-install            fail pass in 10571
 test-i386-i386-win            7 windows-install             fail pass in 10577
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install       fail pass in 10577
 test-amd64-amd64-xl          16 guest-start.2      fail in 10577 pass in 10585
 test-amd64-amd64-xl-sedf      7 debian-install     fail in 10577 pass in 10585
 test-amd64-i386-xl-credit2    7 debian-install     fail in 10571 pass in 10585

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-xl-sedf     14 guest-localmigrate/x10       fail   like 10563
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2       fail in 10577 never pass
 test-i386-i386-win           16 leak-check/check      fail in 10577 never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop      fail in 10577 never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2         fail in 10571 never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop           fail in 10571 never pass

version targeted for testing:
 xen                  492914c65838
baseline version:
 xen                  e56500f95b6a

------------------------------------------------------------
People who touched revisions under test:
  Anthony PERARD <anthony.perard@citrix.com>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           fail    
 test-i386-i386-xl                                            fail    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          fail    
 test-amd64-i386-pv                                           fail    
 test-i386-i386-pv                                            fail    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   24445:492914c65838
tag:         tip
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Wed Dec 21 10:47:30 2011 +0000
    
    libxl: report failure to reboot/shutdown due to lackof PV interfaces to caller
    
    This allow the caller to react as they think is appropriate. xl now prints a
    message much like the library did previously, although hopefully somewhat more
    informative.
    
    Update the xl(1) man page to be similarly more informative.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Committed-by: Ian Jackson <ian.jackson.citrix.com>
    Acked-by: Ian Jackson <ian.jackson.citrix.com>
    
    
changeset:   24444:1c3f9cac204e
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Wed Dec 21 10:47:11 2011 +0000
    
    libxl: split libxl_domain_shutdown into libxl_domain_shutdown,..._reboot
    
    The other integer request types which shutdown supported are not
    useful. Specifically:
    
     * "suspend" is not usable via this interface since it requires other
       scaffolding, libxl_domain_suspend provides this already.
     * "halt" is the same as "poweroff".
     * "crash" is unused and at least Linux does not implement it. If a user
       steps forward then libxl_domain_crash is trivial to add.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Committed-by: Ian Jackson <ian.jackson.citrix.com>
    Acked-by: Ian Jackson <ian.jackson.citrix.com>
    
    
changeset:   24443:b3455a4d2298
user:        Anthony PERARD <anthony.perard@citrix.com>
date:        Wed Dec 21 14:47:26 2011 +0000
    
    libxl: Fix, specify open mode to QEMU state file.
    
    Reported-by: Olaf Hering <olaf@aepfle.de>
    Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24442:16dc2a1cd40f
user:        Jan Beulich <jbeulich@suse.com>
date:        Wed Dec 21 14:26:09 2011 +0100
    
    x86: reduce scope of some symbols used with reset_stack_and_jump()
    
    By making the macro properly advertise the use of the input symbol to
    the compiler, it is no longer necessary for them to be global if
    they're defined and used in just one source file.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24441:73ab77073140
user:        Jan Beulich <jbeulich@suse.com>
date:        Wed Dec 21 09:20:15 2011 +0100
    
    x86: move some function scope statics into .init.data
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24440:e56500f95b6a
user:        Daniel De Graaf <dgdegra@tycho.nsa.gov>
date:        Tue Dec 20 18:19:53 2011 +0000
    
    flask/policy: Update example policy
    
    Rewrite the example policy to make it easier to understand and
    demonstrate some of the security goals that FLASK can enforce.
    
    Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
    Committed-by: Ian Jackson <ian.jackson.citrix.com>
    
    
========================================
commit 54e24021005458ad0a361c1d83011b751726a94b
Author: Ian Jackson <ian.jackson@eu.citrix.com>
Date:   Thu Dec 8 16:38:06 2011 +0000

    qemu_get_timer: Provide a comment about the behaviour on ts==NULL
    
    Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 22 06:14:30 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 Dec 2011 06: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.xensource.com>)
	id 1RdbuV-0008Mj-89; Thu, 22 Dec 2011 06:13:47 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RdbuT-0008Mc-BS
	for xen-devel@lists.xensource.com; Thu, 22 Dec 2011 06:13:45 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1324534418!8220367!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Nzc4MA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13543 invoked from network); 22 Dec 2011 06:13:39 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Dec 2011 06:13:39 -0000
X-IronPort-AV: E=Sophos;i="4.71,391,1320624000"; 
   d="scan'208";a="9622523"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Dec 2011 06:13:38 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 22 Dec 2011 06:13:38 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RdbuM-00082X-C5;
	Thu, 22 Dec 2011 06:13:38 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RdbuM-0008Lh-9W;
	Thu, 22 Dec 2011 06:13:38 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10585-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 22 Dec 2011 06:13:38 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10585: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10585 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10585/

Regressions :-(

Tests which did not succeed and are blocking,including tests which could not be run:
 test-amd64-i386-xl-credit2   16 guest-start.2             fail REGR. vs. 10564
 test-i386-i386-pv            16 guest-start.2             fail REGR. vs. 10564
 test-i386-i386-xl            16 guest-start.2             fail REGR. vs. 10564
 test-amd64-amd64-xl-win7-amd64  7 windows-install         fail REGR. vs. 10564

Tests which are failing intermittently (not blocking):
 test-amd64-i386-rhel6hvm-intel  7 redhat-install            fail pass in 10577
 test-amd64-amd64-pv          16 guest-start.2               fail pass in 10571
 test-amd64-i386-pv           16 guest-start.2               fail pass in 10571
 test-amd64-i386-xl-multivcpu 16 guest-start.2               fail pass in 10571
 test-amd64-amd64-xl-sedf-pin 16 guest-start.2               fail pass in 10571
 test-amd64-i386-xl           16 guest-start.2               fail pass in 10571
 test-amd64-i386-rhel6hvm-amd  7 redhat-install              fail pass in 10571
 test-amd64-i386-xl-win7-amd64  7 windows-install            fail pass in 10571
 test-i386-i386-win            7 windows-install             fail pass in 10577
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install       fail pass in 10577
 test-amd64-amd64-xl          16 guest-start.2      fail in 10577 pass in 10585
 test-amd64-amd64-xl-sedf      7 debian-install     fail in 10577 pass in 10585
 test-amd64-i386-xl-credit2    7 debian-install     fail in 10571 pass in 10585

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-xl-sedf     14 guest-localmigrate/x10       fail   like 10563
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2       fail in 10577 never pass
 test-i386-i386-win           16 leak-check/check      fail in 10577 never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop      fail in 10577 never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2         fail in 10571 never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop           fail in 10571 never pass

version targeted for testing:
 xen                  492914c65838
baseline version:
 xen                  e56500f95b6a

------------------------------------------------------------
People who touched revisions under test:
  Anthony PERARD <anthony.perard@citrix.com>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           fail    
 test-i386-i386-xl                                            fail    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          fail    
 test-amd64-i386-pv                                           fail    
 test-i386-i386-pv                                            fail    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   24445:492914c65838
tag:         tip
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Wed Dec 21 10:47:30 2011 +0000
    
    libxl: report failure to reboot/shutdown due to lackof PV interfaces to caller
    
    This allow the caller to react as they think is appropriate. xl now prints a
    message much like the library did previously, although hopefully somewhat more
    informative.
    
    Update the xl(1) man page to be similarly more informative.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Committed-by: Ian Jackson <ian.jackson.citrix.com>
    Acked-by: Ian Jackson <ian.jackson.citrix.com>
    
    
changeset:   24444:1c3f9cac204e
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Wed Dec 21 10:47:11 2011 +0000
    
    libxl: split libxl_domain_shutdown into libxl_domain_shutdown,..._reboot
    
    The other integer request types which shutdown supported are not
    useful. Specifically:
    
     * "suspend" is not usable via this interface since it requires other
       scaffolding, libxl_domain_suspend provides this already.
     * "halt" is the same as "poweroff".
     * "crash" is unused and at least Linux does not implement it. If a user
       steps forward then libxl_domain_crash is trivial to add.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Committed-by: Ian Jackson <ian.jackson.citrix.com>
    Acked-by: Ian Jackson <ian.jackson.citrix.com>
    
    
changeset:   24443:b3455a4d2298
user:        Anthony PERARD <anthony.perard@citrix.com>
date:        Wed Dec 21 14:47:26 2011 +0000
    
    libxl: Fix, specify open mode to QEMU state file.
    
    Reported-by: Olaf Hering <olaf@aepfle.de>
    Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24442:16dc2a1cd40f
user:        Jan Beulich <jbeulich@suse.com>
date:        Wed Dec 21 14:26:09 2011 +0100
    
    x86: reduce scope of some symbols used with reset_stack_and_jump()
    
    By making the macro properly advertise the use of the input symbol to
    the compiler, it is no longer necessary for them to be global if
    they're defined and used in just one source file.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24441:73ab77073140
user:        Jan Beulich <jbeulich@suse.com>
date:        Wed Dec 21 09:20:15 2011 +0100
    
    x86: move some function scope statics into .init.data
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24440:e56500f95b6a
user:        Daniel De Graaf <dgdegra@tycho.nsa.gov>
date:        Tue Dec 20 18:19:53 2011 +0000
    
    flask/policy: Update example policy
    
    Rewrite the example policy to make it easier to understand and
    demonstrate some of the security goals that FLASK can enforce.
    
    Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
    Committed-by: Ian Jackson <ian.jackson.citrix.com>
    
    
========================================
commit 54e24021005458ad0a361c1d83011b751726a94b
Author: Ian Jackson <ian.jackson@eu.citrix.com>
Date:   Thu Dec 8 16:38:06 2011 +0000

    qemu_get_timer: Provide a comment about the behaviour on ts==NULL
    
    Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 22 08:50:03 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 Dec 2011 08:50:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdeKm-0001pM-Es; Thu, 22 Dec 2011 08:49:04 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RdeKl-0001pH-0V
	for xen-devel@lists.xensource.com; Thu, 22 Dec 2011 08:49:03 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1324543736!6310319!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2763 invoked from network); 22 Dec 2011 08:48:56 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-14.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 22 Dec 2011 08:48:56 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 22 Dec 2011 08:48:55 +0000
Message-Id: <4EF2FD3E020000780006984D@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 22 Dec 2011 08:49:50 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Laszlo Ersek" <lersek@redhat.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, xen-devel@lists.xensource.com,
	Joe Jin <joe.jin@oracle.com>, Zhenzhong Duan <zhenzhong.duan@oracle.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH] remove blocked time accounting from xen
 "clockchip"
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 21.12.11 at 14:53, Laszlo Ersek <lersek@redhat.com> wrote:
> On 12/21/11 09:32, Jan Beulich wrote:
>> I currently have no idea what the remain 1% could be attributed to,
>> so thoughts from others would certainly be welcome.
> 
> What about irqtime_account_process_tick() calling account_idle_time() 
> with "cputime_one_jiffy" -- it could more frequently trigger the 
> underflow in _cputime_to_cputime64(). In that case we might want to 
> decrease idle time (ie. account "negative" cputime against idle), but can't.

Despite my thinking of this supposedly being impossible, I put in
accounting of what is getting lost here. With an unexpected result:
There's far more stolen ticks that can't get subtracted from one of the
other counters than such that can. With the result that if I kept a
record of how many still didn't get used for adjustment, there would
then be about 10% under-accounting (instead on the 1% over-
accounting). I understand this as meaning that the majority of stolen
ticks don't get mis-accounted in any of the other counters, and it's
just very few that need to be corrected for. But I'm not entirely
convinced of this explanation.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 22 08:50:03 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 Dec 2011 08:50:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdeKm-0001pM-Es; Thu, 22 Dec 2011 08:49:04 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RdeKl-0001pH-0V
	for xen-devel@lists.xensource.com; Thu, 22 Dec 2011 08:49:03 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1324543736!6310319!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2763 invoked from network); 22 Dec 2011 08:48:56 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-14.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 22 Dec 2011 08:48:56 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 22 Dec 2011 08:48:55 +0000
Message-Id: <4EF2FD3E020000780006984D@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 22 Dec 2011 08:49:50 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Laszlo Ersek" <lersek@redhat.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, xen-devel@lists.xensource.com,
	Joe Jin <joe.jin@oracle.com>, Zhenzhong Duan <zhenzhong.duan@oracle.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH] remove blocked time accounting from xen
 "clockchip"
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 21.12.11 at 14:53, Laszlo Ersek <lersek@redhat.com> wrote:
> On 12/21/11 09:32, Jan Beulich wrote:
>> I currently have no idea what the remain 1% could be attributed to,
>> so thoughts from others would certainly be welcome.
> 
> What about irqtime_account_process_tick() calling account_idle_time() 
> with "cputime_one_jiffy" -- it could more frequently trigger the 
> underflow in _cputime_to_cputime64(). In that case we might want to 
> decrease idle time (ie. account "negative" cputime against idle), but can't.

Despite my thinking of this supposedly being impossible, I put in
accounting of what is getting lost here. With an unexpected result:
There's far more stolen ticks that can't get subtracted from one of the
other counters than such that can. With the result that if I kept a
record of how many still didn't get used for adjustment, there would
then be about 10% under-accounting (instead on the 1% over-
accounting). I understand this as meaning that the majority of stolen
ticks don't get mis-accounted in any of the other counters, and it's
just very few that need to be corrected for. But I'm not entirely
convinced of this explanation.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 22 08:57:31 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 Dec 2011 08:57:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdeRp-0001yM-Ay; Thu, 22 Dec 2011 08:56:21 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RdeRn-0001yE-S2
	for xen-devel@lists.xensource.com; Thu, 22 Dec 2011 08:56:20 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1324544173!6520549!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11825 invoked from network); 22 Dec 2011 08:56:13 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-6.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 22 Dec 2011 08:56:13 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 22 Dec 2011 08:56:12 +0000
Message-Id: <4EF2FEF1020000780006985F@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 22 Dec 2011 08:57:05 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <4EF210E7020000780006965E@nat28.tlf.novell.com>
	<20111221173915.GA15377@phenom.dumpdata.com>
In-Reply-To: <20111221173915.GA15377@phenom.dumpdata.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>,
	Jeremy Fitzhardinge <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH] Xen: consolidate and simplify struct
 xenbus_driver instantiation
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 21.12.11 at 18:39, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> b) this is changing it from xen-pciback to pciback:

Yes, this clearly was unintentional. I'll get a v2 out right away, and also
try to remember Cc-ing the other people you mentioned.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 22 08:57:31 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 Dec 2011 08:57:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdeRp-0001yM-Ay; Thu, 22 Dec 2011 08:56:21 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RdeRn-0001yE-S2
	for xen-devel@lists.xensource.com; Thu, 22 Dec 2011 08:56:20 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1324544173!6520549!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11825 invoked from network); 22 Dec 2011 08:56:13 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-6.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 22 Dec 2011 08:56:13 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 22 Dec 2011 08:56:12 +0000
Message-Id: <4EF2FEF1020000780006985F@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 22 Dec 2011 08:57:05 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <4EF210E7020000780006965E@nat28.tlf.novell.com>
	<20111221173915.GA15377@phenom.dumpdata.com>
In-Reply-To: <20111221173915.GA15377@phenom.dumpdata.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>,
	Jeremy Fitzhardinge <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH] Xen: consolidate and simplify struct
 xenbus_driver instantiation
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 21.12.11 at 18:39, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> b) this is changing it from xen-pciback to pciback:

Yes, this clearly was unintentional. I'll get a v2 out right away, and also
try to remember Cc-ing the other people you mentioned.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 22 09:04:33 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 Dec 2011 09:04:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdeZH-0002CL-58; Thu, 22 Dec 2011 09:04:03 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RdeZF-0002C6-9A
	for xen-devel@lists.xensource.com; Thu, 22 Dec 2011 09:04:01 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1324544634!8421278!1
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=1.0 required=7.0 tests=DATE_IN_PAST_48_96,
	MAILTO_TO_SPAM_ADDR,RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16928 invoked from network); 22 Dec 2011 09:03:54 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Dec 2011 09:03:54 -0000
Received: by werg1 with SMTP id g1so8550397wer.30
	for <xen-devel@lists.xensource.com>;
	Thu, 22 Dec 2011 01:03:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:user-agent:date:from:to:cc;
	bh=sVPH+8E5+CX2mqth09zB+GMNHw3WMvlCL3+BOOEnnVk=;
	b=Y6Fcto+qWo0ztrIG6KKguMm/VqSbKsQ9beiJhHsMdzrJgssnOWAqtWPmltzmhwsNLt
	2CDW/FT9UMBd6ejdfskW4MiSTzN/B0v1A+LxCwMG/2opderGMRRkIwaz0PgUIQK1mnWS
	Q4FT2jfVnuGPcJWlKCbce4hQb7N6XRSHkgSlw=
Received: by 10.216.138.1 with SMTP id z1mr10689934wei.55.1324544633246;
	Thu, 22 Dec 2011 01:03:53 -0800 (PST)
Received: from alpine.localdomain (tina.upc.es. [147.83.39.243])
	by mx.google.com with ESMTPS id fi6sm13643410wib.2.2011.12.22.01.03.50
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 22 Dec 2011 01:03:51 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: cf68eb390e1bf2fa4bb005ffeccfd41a01c3f81d
Message-Id: <cf68eb390e1bf2fa4bb0.1324365732@alpine.localdomain>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Tue, 20 Dec 2011 08:22:12 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Cc: JBeulich@suse.com
Subject: [Xen-devel] [PATCH v2] ipxe: update to upstream version
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1324365671 -3600
# Node ID cf68eb390e1bf2fa4bb005ffeccfd41a01c3f81d
# Parent  03138a08366b895d79e143119d4c9c72833cdbcd
ipxe: update to upstream version

Updated ipxe to current tree, which is
540e5960dc6b49eacf367f7c319fd0546474b845:

Provide PXENV_FILE_EXIT_HOOK only for ipxelinux.0 builds

Removed all the backported patches and updated
boot_prompt_option.patch to apply against current ipxe.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 03138a08366b -r cf68eb390e1b tools/firmware/etherboot/Makefile
--- a/tools/firmware/etherboot/Makefile	Fri Dec 09 16:19:36 2011 +0000
+++ b/tools/firmware/etherboot/Makefile	Tue Dec 20 08:21:11 2011 +0100
@@ -10,7 +10,7 @@ else
 IPXE_GIT_URL := git://git.ipxe.org/ipxe.git
 endif
 
-IPXE_GIT_TAG := v1.0.0
+IPXE_GIT_TAG := 9a93db3f0947484e30e753bbd61a10b17336e20e
 
 IPXE_TARBALL_URL := $(XEN_EXTFILES_URL)/ipxe-git-$(IPXE_GIT_TAG).tar.gz
 
diff -r 03138a08366b -r cf68eb390e1b tools/firmware/etherboot/patches/boot_prompt_option.patch
--- a/tools/firmware/etherboot/patches/boot_prompt_option.patch	Fri Dec 09 16:19:36 2011 +0000
+++ b/tools/firmware/etherboot/patches/boot_prompt_option.patch	Tue Dec 20 08:21:11 2011 +0100
@@ -1,7 +1,8 @@
-diff -pruN gpxe/src/arch/i386/prefix/romprefix.S gpxe.new/src/arch/i386/prefix/romprefix.S
---- gpxe/src/arch/i386/prefix/romprefix.S	2010-06-29 20:31:33.000000000 +0100
-+++ gpxe.new/src/arch/i386/prefix/romprefix.S	2010-07-20 10:40:20.000000000 +0100
-@@ -458,6 +458,7 @@ no_pmm:
+diff --git a/src/arch/i386/prefix/romprefix.S b/src/arch/i386/prefix/romprefix.S
+index 0f92415..cce7505 100644
+--- a/src/arch/i386/prefix/romprefix.S
++++ b/src/arch/i386/prefix/romprefix.S
+@@ -391,6 +391,7 @@ no_pmm:
  	xorw	%di, %di
  	cs rep	movsb
  
@@ -9,15 +10,15 @@ diff -pruN gpxe/src/arch/i386/prefix/rom
  	/* Prompt for POST-time shell */
  	movw	$init_message_prompt, %si
  	xorw	%di, %di
-@@ -484,6 +485,7 @@ no_pmm:
+@@ -418,6 +419,7 @@ no_pmm:
  	pushw	%cs
  	call	exec
- out:
+ 2:
 +#endif
  	/* Restore registers */
  	popw	%gs
  	popw	%fs
-@@ -538,6 +540,7 @@ init_message_no_pmm:
+@@ -546,6 +548,7 @@ init_message_pmm:
  init_message_int19:
  	.asciz	" INT19"
  	.size	init_message_int19, . - init_message_int19
@@ -25,11 +26,11 @@ diff -pruN gpxe/src/arch/i386/prefix/rom
  init_message_prompt:
  	.asciz	"\nPress Ctrl-B to configure "
  	.size	init_message_prompt, . - init_message_prompt
-@@ -547,6 +550,7 @@ init_message_dots:
+@@ -555,6 +558,7 @@ init_message_dots:
  init_message_done:
  	.asciz	"\n\n"
  	.size	init_message_done, . - init_message_done
 +#endif
  
- /* ROM image location
+ /* PCI bus:dev.fn
   *
diff -r 03138a08366b -r cf68eb390e1b tools/firmware/etherboot/patches/gpxe-git-0edf2405b457
--- a/tools/firmware/etherboot/patches/gpxe-git-0edf2405b457	Fri Dec 09 16:19:36 2011 +0000
+++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
@@ -1,30 +0,0 @@
-commit 0edf2405b457e542c244a72285511b3ff5c06885
-Author: Michael Brown <mcb30@ipxe.org>
-Date:   Tue Apr 27 09:52:22 2010 +0100
-
-    [build] Fix building with binutils 2.16
-    
-    Signed-off-by: Michael Brown <mcb30@ipxe.org>
-    Signed-off-by: Stefan Hajnoczi <stefanha@gmail.com>
-
-diff --git a/src/arch/i386/scripts/i386.lds b/src/arch/i386/scripts/i386.lds
-index 278a397..0ce2c10 100644
---- a/src/arch/i386/scripts/i386.lds
-+++ b/src/arch/i386/scripts/i386.lds
-@@ -24,6 +24,8 @@ SECTIONS {
-      *
-      */
- 
-+    PROVIDE ( _max_align = 16 );
-+
-     /*
-      * The prefix
-      *
-@@ -169,7 +171,6 @@ SECTIONS {
-      *
-      */
- 
--    PROVIDE ( _max_align = 16 );
-     .			= 0;
- 
-     .			= ALIGN ( _max_align );
diff -r 03138a08366b -r cf68eb390e1b tools/firmware/etherboot/patches/gpxe-git-a803ef3dfeac
--- a/tools/firmware/etherboot/patches/gpxe-git-a803ef3dfeac	Fri Dec 09 16:19:36 2011 +0000
+++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
@@ -1,125 +0,0 @@
-commit a803ef3dfeac4e8aa35810bba65f9ccab0bdf264
-Author: Michael Brown <mcb30@ipxe.org>
-Date:   Thu Jun 24 01:23:00 2010 +0100
-
-    [build] Avoid hard-coding the path to perl
-    
-    The path "/usr/bin/perl" has been hard-coded since Etherboot 5.1, for
-    no discernible reason.  Use just "perl" instead to fix the
-    inconsistency and allow building on systems with Perl installed
-    outside of /usr/bin.
-    
-    This commit also includes a later fix that removes a dependency on
-    "perl" which broke builds from fully clean trees.
-    
-    Reported-by: Gabor Z. Papp <gzp@papp.hu>
-    Signed-off-by: Michael Brown <mcb30@ipxe.org>
-    Signed-off-by: Stefan Hajnoczi <stefanha@gmail.com>
-
-diff -pruN a/src/arch/i386/Makefile.pcbios b/src/arch/i386/Makefile.pcbios
---- a/src/arch/i386/Makefile.pcbios	2010-06-29 20:31:33.000000000 +0100
-+++ b/src/arch/i386/Makefile.pcbios	2010-07-20 16:07:06.000000000 +0100
-@@ -24,11 +24,11 @@ MEDIA		+= raw
- 
- # Padding rules
- #
--PAD_rom		= $(PADIMG) --blksize=512 --byte=0xff $@
-+PAD_rom		= $(PERL) $(PADIMG) --blksize=512 --byte=0xff $@
- PAD_hrom	= $(PAD_rom)
- PAD_xrom	= $(PAD_rom)
--PAD_dsk		= $(PADIMG) --blksize=512 $@
--PAD_hd		= $(PADIMG) --blksize=32768 $@
-+PAD_dsk		= $(PERL) $(PADIMG) --blksize=512 $@
-+PAD_hd		= $(PERL) $(PADIMG) --blksize=32768 $@
- 
- # rule to make a non-emulation ISO boot image
- NON_AUTO_MEDIA	+= iso
-@@ -67,4 +67,4 @@ NON_AUTO_MEDIA	+= usb
- NON_AUTO_MEDIA += pdsk
- %pdsk : %dsk
- 	$(Q)cp $< $@
--	$(Q)$(PADIMG) --blksize=1474560 $@
-+	$(Q)$(PERL) $(PADIMG) --blksize=1474560 $@
-diff -pruN a/src/Makefile b/src/Makefile
---- a/src/Makefile	2010-06-29 20:31:33.000000000 +0100
-+++ b/src/Makefile	2010-07-20 16:02:56.000000000 +0100
-@@ -20,7 +20,7 @@ MKDIR		:= mkdir
- CP		:= cp
- ECHO		:= echo
- PRINTF		:= printf
--PERL		:= /usr/bin/perl
-+PERL		:= perl
- CC		:= $(CROSS_COMPILE)gcc
- CPP		:= $(CC) -E
- AS		:= $(CROSS_COMPILE)as
-@@ -31,12 +31,12 @@ RANLIB		:= $(CROSS_COMPILE)ranlib
- OBJCOPY		:= $(CROSS_COMPILE)objcopy
- NM		:= $(CROSS_COMPILE)nm
- OBJDUMP		:= $(CROSS_COMPILE)objdump
--PARSEROM	:= $(PERL) ./util/parserom.pl
--MAKEROM		:= $(PERL) ./util/makerom.pl
--SYMCHECK	:= $(PERL) ./util/symcheck.pl
--SORTOBJDUMP	:= $(PERL) ./util/sortobjdump.pl
--PADIMG		:= $(PERL) ./util/padimg.pl
--LICENCE		:= $(PERL) ./util/licence.pl
-+PARSEROM	:= ./util/parserom.pl
-+MAKEROM		:= ./util/makerom.pl
-+SYMCHECK	:= ./util/symcheck.pl
-+SORTOBJDUMP	:= ./util/sortobjdump.pl
-+PADIMG		:= ./util/padimg.pl
-+LICENCE		:= ./util/licence.pl
- NRV2B		:= ./util/nrv2b
- ZBIN		:= ./util/zbin
- ELF2EFI32	:= ./util/elf2efi32
-diff -pruN a/src/Makefile.housekeeping b/src/Makefile.housekeeping
---- a/src/Makefile.housekeeping	2010-06-29 20:31:33.000000000 +0100
-+++ b/src/Makefile.housekeeping	2010-07-20 16:04:42.000000000 +0100
-@@ -486,7 +486,7 @@ define src_template
- 		 '\n$(2) : $$($(4)_DEPS)\n' \
- 		 '\nTAGS : $$($(4)_DEPS)\n' \
- 		>> $(2)
--	@$(PARSEROM) $(1) >> $(2)
-+	@$(PERL) $(PARSEROM) $(1) >> $(2)
- 
- endef
- 
-@@ -695,7 +695,7 @@ $(BIN)/%.tmp : $(BLIB) $(MAKEDEPS) $(LDS
- 	$(QM)$(ECHO) "  [LD] $@"
- 	$(Q)$(LD) $(LDFLAGS) -T $(LDSCRIPT) $(TGT_LD_FLAGS) $(BLIB) -o $@ \
- 		-Map $(BIN)/$*.tmp.map
--	$(Q)$(OBJDUMP) -ht $@ | $(SORTOBJDUMP) >> $(BIN)/$*.tmp.map
-+	$(Q)$(OBJDUMP) -ht $@ | $(PERL) $(SORTOBJDUMP) >> $(BIN)/$*.tmp.map
- 
- # Keep intermediate object file (useful for debugging)
- .PRECIOUS : $(BIN)/%.tmp
-@@ -752,7 +752,7 @@ $(BIN)/%.licence : $(BIN)/%.tmp
- 		echo "files are missing a licence declaration:" ;\
- 		echo $(call unlicensed_deps_list,$<);\
- 		exit 1,\
--		$(LICENCE) $(call licence_list,$<))
-+		$(PERL) $(LICENCE) $(call licence_list,$<))
- 
- # Extract compression information from intermediate object file
- #
-@@ -866,10 +866,10 @@ endif # defined(BIN)
- # the automatic build system and varies by target; it includes the
- # "-p 0x1234,0x5678" string to set the PCI IDs.
- #
--FINALISE_rom	= $(MAKEROM) $(MAKEROM_FLAGS) $(TGT_MAKEROM_FLAGS) \
-+FINALISE_rom	= $(PERL) $(MAKEROM) $(MAKEROM_FLAGS) $(TGT_MAKEROM_FLAGS) \
- 		  -i$(IDENT) -s 0 $@
- FINALISE_hrom	= $(FINALISE_rom)
--FINALISE_xrom	= $(MAKEROM) $(MAKEROM_FLAGS) $(TGT_MAKEROM_FLAGS) \
-+FINALISE_xrom	= $(PERL) $(MAKEROM) $(MAKEROM_FLAGS) $(TGT_MAKEROM_FLAGS) \
- 		  -i$(IDENT) -n -s 0 $@
- 
- # Some ROMs require specific flags to be passed to makerom.pl
-@@ -987,7 +987,7 @@ $(SYMTAB) : $(BLIB)
- CLEANUP	+= $(BIN)/symtab
- 
- symcheck : $(SYMTAB)
--	$(SYMCHECK) $<
-+	$(PERL) $(SYMCHECK) $<
- 
- endif # defined(BIN)
- 
diff -r 03138a08366b -r cf68eb390e1b tools/firmware/etherboot/patches/series
--- a/tools/firmware/etherboot/patches/series	Fri Dec 09 16:19:36 2011 +0000
+++ b/tools/firmware/etherboot/patches/series	Tue Dec 20 08:21:11 2011 +0100
@@ -1,3 +1,1 @@
 boot_prompt_option.patch
-gpxe-git-0edf2405b457
-gpxe-git-a803ef3dfeac

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 22 09:04:33 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 Dec 2011 09:04:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdeZH-0002CL-58; Thu, 22 Dec 2011 09:04:03 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RdeZF-0002C6-9A
	for xen-devel@lists.xensource.com; Thu, 22 Dec 2011 09:04:01 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1324544634!8421278!1
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=1.0 required=7.0 tests=DATE_IN_PAST_48_96,
	MAILTO_TO_SPAM_ADDR,RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16928 invoked from network); 22 Dec 2011 09:03:54 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Dec 2011 09:03:54 -0000
Received: by werg1 with SMTP id g1so8550397wer.30
	for <xen-devel@lists.xensource.com>;
	Thu, 22 Dec 2011 01:03:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:user-agent:date:from:to:cc;
	bh=sVPH+8E5+CX2mqth09zB+GMNHw3WMvlCL3+BOOEnnVk=;
	b=Y6Fcto+qWo0ztrIG6KKguMm/VqSbKsQ9beiJhHsMdzrJgssnOWAqtWPmltzmhwsNLt
	2CDW/FT9UMBd6ejdfskW4MiSTzN/B0v1A+LxCwMG/2opderGMRRkIwaz0PgUIQK1mnWS
	Q4FT2jfVnuGPcJWlKCbce4hQb7N6XRSHkgSlw=
Received: by 10.216.138.1 with SMTP id z1mr10689934wei.55.1324544633246;
	Thu, 22 Dec 2011 01:03:53 -0800 (PST)
Received: from alpine.localdomain (tina.upc.es. [147.83.39.243])
	by mx.google.com with ESMTPS id fi6sm13643410wib.2.2011.12.22.01.03.50
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 22 Dec 2011 01:03:51 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: cf68eb390e1bf2fa4bb005ffeccfd41a01c3f81d
Message-Id: <cf68eb390e1bf2fa4bb0.1324365732@alpine.localdomain>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Tue, 20 Dec 2011 08:22:12 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Cc: JBeulich@suse.com
Subject: [Xen-devel] [PATCH v2] ipxe: update to upstream version
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1324365671 -3600
# Node ID cf68eb390e1bf2fa4bb005ffeccfd41a01c3f81d
# Parent  03138a08366b895d79e143119d4c9c72833cdbcd
ipxe: update to upstream version

Updated ipxe to current tree, which is
540e5960dc6b49eacf367f7c319fd0546474b845:

Provide PXENV_FILE_EXIT_HOOK only for ipxelinux.0 builds

Removed all the backported patches and updated
boot_prompt_option.patch to apply against current ipxe.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 03138a08366b -r cf68eb390e1b tools/firmware/etherboot/Makefile
--- a/tools/firmware/etherboot/Makefile	Fri Dec 09 16:19:36 2011 +0000
+++ b/tools/firmware/etherboot/Makefile	Tue Dec 20 08:21:11 2011 +0100
@@ -10,7 +10,7 @@ else
 IPXE_GIT_URL := git://git.ipxe.org/ipxe.git
 endif
 
-IPXE_GIT_TAG := v1.0.0
+IPXE_GIT_TAG := 9a93db3f0947484e30e753bbd61a10b17336e20e
 
 IPXE_TARBALL_URL := $(XEN_EXTFILES_URL)/ipxe-git-$(IPXE_GIT_TAG).tar.gz
 
diff -r 03138a08366b -r cf68eb390e1b tools/firmware/etherboot/patches/boot_prompt_option.patch
--- a/tools/firmware/etherboot/patches/boot_prompt_option.patch	Fri Dec 09 16:19:36 2011 +0000
+++ b/tools/firmware/etherboot/patches/boot_prompt_option.patch	Tue Dec 20 08:21:11 2011 +0100
@@ -1,7 +1,8 @@
-diff -pruN gpxe/src/arch/i386/prefix/romprefix.S gpxe.new/src/arch/i386/prefix/romprefix.S
---- gpxe/src/arch/i386/prefix/romprefix.S	2010-06-29 20:31:33.000000000 +0100
-+++ gpxe.new/src/arch/i386/prefix/romprefix.S	2010-07-20 10:40:20.000000000 +0100
-@@ -458,6 +458,7 @@ no_pmm:
+diff --git a/src/arch/i386/prefix/romprefix.S b/src/arch/i386/prefix/romprefix.S
+index 0f92415..cce7505 100644
+--- a/src/arch/i386/prefix/romprefix.S
++++ b/src/arch/i386/prefix/romprefix.S
+@@ -391,6 +391,7 @@ no_pmm:
  	xorw	%di, %di
  	cs rep	movsb
  
@@ -9,15 +10,15 @@ diff -pruN gpxe/src/arch/i386/prefix/rom
  	/* Prompt for POST-time shell */
  	movw	$init_message_prompt, %si
  	xorw	%di, %di
-@@ -484,6 +485,7 @@ no_pmm:
+@@ -418,6 +419,7 @@ no_pmm:
  	pushw	%cs
  	call	exec
- out:
+ 2:
 +#endif
  	/* Restore registers */
  	popw	%gs
  	popw	%fs
-@@ -538,6 +540,7 @@ init_message_no_pmm:
+@@ -546,6 +548,7 @@ init_message_pmm:
  init_message_int19:
  	.asciz	" INT19"
  	.size	init_message_int19, . - init_message_int19
@@ -25,11 +26,11 @@ diff -pruN gpxe/src/arch/i386/prefix/rom
  init_message_prompt:
  	.asciz	"\nPress Ctrl-B to configure "
  	.size	init_message_prompt, . - init_message_prompt
-@@ -547,6 +550,7 @@ init_message_dots:
+@@ -555,6 +558,7 @@ init_message_dots:
  init_message_done:
  	.asciz	"\n\n"
  	.size	init_message_done, . - init_message_done
 +#endif
  
- /* ROM image location
+ /* PCI bus:dev.fn
   *
diff -r 03138a08366b -r cf68eb390e1b tools/firmware/etherboot/patches/gpxe-git-0edf2405b457
--- a/tools/firmware/etherboot/patches/gpxe-git-0edf2405b457	Fri Dec 09 16:19:36 2011 +0000
+++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
@@ -1,30 +0,0 @@
-commit 0edf2405b457e542c244a72285511b3ff5c06885
-Author: Michael Brown <mcb30@ipxe.org>
-Date:   Tue Apr 27 09:52:22 2010 +0100
-
-    [build] Fix building with binutils 2.16
-    
-    Signed-off-by: Michael Brown <mcb30@ipxe.org>
-    Signed-off-by: Stefan Hajnoczi <stefanha@gmail.com>
-
-diff --git a/src/arch/i386/scripts/i386.lds b/src/arch/i386/scripts/i386.lds
-index 278a397..0ce2c10 100644
---- a/src/arch/i386/scripts/i386.lds
-+++ b/src/arch/i386/scripts/i386.lds
-@@ -24,6 +24,8 @@ SECTIONS {
-      *
-      */
- 
-+    PROVIDE ( _max_align = 16 );
-+
-     /*
-      * The prefix
-      *
-@@ -169,7 +171,6 @@ SECTIONS {
-      *
-      */
- 
--    PROVIDE ( _max_align = 16 );
-     .			= 0;
- 
-     .			= ALIGN ( _max_align );
diff -r 03138a08366b -r cf68eb390e1b tools/firmware/etherboot/patches/gpxe-git-a803ef3dfeac
--- a/tools/firmware/etherboot/patches/gpxe-git-a803ef3dfeac	Fri Dec 09 16:19:36 2011 +0000
+++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
@@ -1,125 +0,0 @@
-commit a803ef3dfeac4e8aa35810bba65f9ccab0bdf264
-Author: Michael Brown <mcb30@ipxe.org>
-Date:   Thu Jun 24 01:23:00 2010 +0100
-
-    [build] Avoid hard-coding the path to perl
-    
-    The path "/usr/bin/perl" has been hard-coded since Etherboot 5.1, for
-    no discernible reason.  Use just "perl" instead to fix the
-    inconsistency and allow building on systems with Perl installed
-    outside of /usr/bin.
-    
-    This commit also includes a later fix that removes a dependency on
-    "perl" which broke builds from fully clean trees.
-    
-    Reported-by: Gabor Z. Papp <gzp@papp.hu>
-    Signed-off-by: Michael Brown <mcb30@ipxe.org>
-    Signed-off-by: Stefan Hajnoczi <stefanha@gmail.com>
-
-diff -pruN a/src/arch/i386/Makefile.pcbios b/src/arch/i386/Makefile.pcbios
---- a/src/arch/i386/Makefile.pcbios	2010-06-29 20:31:33.000000000 +0100
-+++ b/src/arch/i386/Makefile.pcbios	2010-07-20 16:07:06.000000000 +0100
-@@ -24,11 +24,11 @@ MEDIA		+= raw
- 
- # Padding rules
- #
--PAD_rom		= $(PADIMG) --blksize=512 --byte=0xff $@
-+PAD_rom		= $(PERL) $(PADIMG) --blksize=512 --byte=0xff $@
- PAD_hrom	= $(PAD_rom)
- PAD_xrom	= $(PAD_rom)
--PAD_dsk		= $(PADIMG) --blksize=512 $@
--PAD_hd		= $(PADIMG) --blksize=32768 $@
-+PAD_dsk		= $(PERL) $(PADIMG) --blksize=512 $@
-+PAD_hd		= $(PERL) $(PADIMG) --blksize=32768 $@
- 
- # rule to make a non-emulation ISO boot image
- NON_AUTO_MEDIA	+= iso
-@@ -67,4 +67,4 @@ NON_AUTO_MEDIA	+= usb
- NON_AUTO_MEDIA += pdsk
- %pdsk : %dsk
- 	$(Q)cp $< $@
--	$(Q)$(PADIMG) --blksize=1474560 $@
-+	$(Q)$(PERL) $(PADIMG) --blksize=1474560 $@
-diff -pruN a/src/Makefile b/src/Makefile
---- a/src/Makefile	2010-06-29 20:31:33.000000000 +0100
-+++ b/src/Makefile	2010-07-20 16:02:56.000000000 +0100
-@@ -20,7 +20,7 @@ MKDIR		:= mkdir
- CP		:= cp
- ECHO		:= echo
- PRINTF		:= printf
--PERL		:= /usr/bin/perl
-+PERL		:= perl
- CC		:= $(CROSS_COMPILE)gcc
- CPP		:= $(CC) -E
- AS		:= $(CROSS_COMPILE)as
-@@ -31,12 +31,12 @@ RANLIB		:= $(CROSS_COMPILE)ranlib
- OBJCOPY		:= $(CROSS_COMPILE)objcopy
- NM		:= $(CROSS_COMPILE)nm
- OBJDUMP		:= $(CROSS_COMPILE)objdump
--PARSEROM	:= $(PERL) ./util/parserom.pl
--MAKEROM		:= $(PERL) ./util/makerom.pl
--SYMCHECK	:= $(PERL) ./util/symcheck.pl
--SORTOBJDUMP	:= $(PERL) ./util/sortobjdump.pl
--PADIMG		:= $(PERL) ./util/padimg.pl
--LICENCE		:= $(PERL) ./util/licence.pl
-+PARSEROM	:= ./util/parserom.pl
-+MAKEROM		:= ./util/makerom.pl
-+SYMCHECK	:= ./util/symcheck.pl
-+SORTOBJDUMP	:= ./util/sortobjdump.pl
-+PADIMG		:= ./util/padimg.pl
-+LICENCE		:= ./util/licence.pl
- NRV2B		:= ./util/nrv2b
- ZBIN		:= ./util/zbin
- ELF2EFI32	:= ./util/elf2efi32
-diff -pruN a/src/Makefile.housekeeping b/src/Makefile.housekeeping
---- a/src/Makefile.housekeeping	2010-06-29 20:31:33.000000000 +0100
-+++ b/src/Makefile.housekeeping	2010-07-20 16:04:42.000000000 +0100
-@@ -486,7 +486,7 @@ define src_template
- 		 '\n$(2) : $$($(4)_DEPS)\n' \
- 		 '\nTAGS : $$($(4)_DEPS)\n' \
- 		>> $(2)
--	@$(PARSEROM) $(1) >> $(2)
-+	@$(PERL) $(PARSEROM) $(1) >> $(2)
- 
- endef
- 
-@@ -695,7 +695,7 @@ $(BIN)/%.tmp : $(BLIB) $(MAKEDEPS) $(LDS
- 	$(QM)$(ECHO) "  [LD] $@"
- 	$(Q)$(LD) $(LDFLAGS) -T $(LDSCRIPT) $(TGT_LD_FLAGS) $(BLIB) -o $@ \
- 		-Map $(BIN)/$*.tmp.map
--	$(Q)$(OBJDUMP) -ht $@ | $(SORTOBJDUMP) >> $(BIN)/$*.tmp.map
-+	$(Q)$(OBJDUMP) -ht $@ | $(PERL) $(SORTOBJDUMP) >> $(BIN)/$*.tmp.map
- 
- # Keep intermediate object file (useful for debugging)
- .PRECIOUS : $(BIN)/%.tmp
-@@ -752,7 +752,7 @@ $(BIN)/%.licence : $(BIN)/%.tmp
- 		echo "files are missing a licence declaration:" ;\
- 		echo $(call unlicensed_deps_list,$<);\
- 		exit 1,\
--		$(LICENCE) $(call licence_list,$<))
-+		$(PERL) $(LICENCE) $(call licence_list,$<))
- 
- # Extract compression information from intermediate object file
- #
-@@ -866,10 +866,10 @@ endif # defined(BIN)
- # the automatic build system and varies by target; it includes the
- # "-p 0x1234,0x5678" string to set the PCI IDs.
- #
--FINALISE_rom	= $(MAKEROM) $(MAKEROM_FLAGS) $(TGT_MAKEROM_FLAGS) \
-+FINALISE_rom	= $(PERL) $(MAKEROM) $(MAKEROM_FLAGS) $(TGT_MAKEROM_FLAGS) \
- 		  -i$(IDENT) -s 0 $@
- FINALISE_hrom	= $(FINALISE_rom)
--FINALISE_xrom	= $(MAKEROM) $(MAKEROM_FLAGS) $(TGT_MAKEROM_FLAGS) \
-+FINALISE_xrom	= $(PERL) $(MAKEROM) $(MAKEROM_FLAGS) $(TGT_MAKEROM_FLAGS) \
- 		  -i$(IDENT) -n -s 0 $@
- 
- # Some ROMs require specific flags to be passed to makerom.pl
-@@ -987,7 +987,7 @@ $(SYMTAB) : $(BLIB)
- CLEANUP	+= $(BIN)/symtab
- 
- symcheck : $(SYMTAB)
--	$(SYMCHECK) $<
-+	$(PERL) $(SYMCHECK) $<
- 
- endif # defined(BIN)
- 
diff -r 03138a08366b -r cf68eb390e1b tools/firmware/etherboot/patches/series
--- a/tools/firmware/etherboot/patches/series	Fri Dec 09 16:19:36 2011 +0000
+++ b/tools/firmware/etherboot/patches/series	Tue Dec 20 08:21:11 2011 +0100
@@ -1,3 +1,1 @@
 boot_prompt_option.patch
-gpxe-git-0edf2405b457
-gpxe-git-a803ef3dfeac

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 22 09:07:56 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 Dec 2011 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.xensource.com>)
	id 1Rdecb-0002U5-Rd; Thu, 22 Dec 2011 09:07:29 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RdecZ-0002TS-Vu
	for xen-devel@lists.xensource.com; Thu, 22 Dec 2011 09:07:28 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1324544840!8367100!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6571 invoked from network); 22 Dec 2011 09:07:20 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-3.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 22 Dec 2011 09:07:20 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 22 Dec 2011 09:07:19 +0000
Message-Id: <4EF3018D020000780006986E@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 22 Dec 2011 09:08:13 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad@darnok.org>,
	"Jeremy Fitzhardinge" <jeremy@goop.org>,
	"Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part4A65FB6D.7__="
Cc: Jens Axboe <axboe@kernel.dk>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <ian.campbell@citrix.com>, FlorianSchandinat@gmx.de,
	netdev@vger.kernel.org, dmitry.torokhov@gmail.com,
	linux-kernel@vger.kernel.org, davem@davemloft.net
Subject: [Xen-devel] [PATCH,
 v2] Xen: consolidate and simplify struct xenbus_driver instantiation
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__Part4A65FB6D.7__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

The 'name', 'owner', and 'mod_name' members are redundant with the
identically named fields in the 'driver' sub-structure. Rather than
switching each instance to specify these fields explicitly, introduce
a macro to simplify this.

Eliminate further redundancy by allowing the drvname argument to
DEFINE_XENBUS_DRIVER() to be blank (in which case the first entry from
the ID table will be used for .driver.name).

Also eliminate the questionable xenbus_register_{back,front}end()
wrappers - their sole remaining purpose was the checking of the
'owner' field, proper setting of which shouldn't be an issue anymore
when the macro gets used.

v2: Restore DRV_NAME for the driver name in xen-pciback.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Cc: Jens Axboe <axboe@kernel.dk>
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: David S. Miller <davem@davemloft.net>

---
 drivers/block/xen-blkback/xenbus.c         |    9 ++------
 drivers/block/xen-blkfront.c               |   11 +++-------
 drivers/input/misc/xen-kbdfront.c          |    7 +-----
 drivers/net/xen-netback/xenbus.c           |    9 ++------
 drivers/net/xen-netfront.c                 |    9 ++------
 drivers/pci/xen-pcifront.c                 |   11 +++-------
 drivers/video/xen-fbfront.c                |    9 ++------
 drivers/xen/xen-pciback/xenbus.c           |   13 ++++--------
 drivers/xen/xenbus/xenbus_probe.c          |    7 ------
 drivers/xen/xenbus/xenbus_probe.h          |    4 ---
 drivers/xen/xenbus/xenbus_probe_backend.c  |    8 ++-----
 drivers/xen/xenbus/xenbus_probe_frontend.c |    8 ++-----
 include/xen/xenbus.h                       |   31 ++++++++----------------=
-----
 13 files changed, 44 insertions(+), 92 deletions(-)

--- 3.2-rc6/drivers/block/xen-blkback/xenbus.c
+++ 3.2-rc6-struct-xenbus_driver/drivers/block/xen-blkback/xenbus.c
@@ -787,17 +787,14 @@ static const struct xenbus_device_id xen
 };
=20
=20
-static struct xenbus_driver xen_blkbk =3D {
-	.name =3D "vbd",
-	.owner =3D THIS_MODULE,
-	.ids =3D xen_blkbk_ids,
+static DEFINE_XENBUS_DRIVER(xen_blkbk, ,
 	.probe =3D xen_blkbk_probe,
 	.remove =3D xen_blkbk_remove,
 	.otherend_changed =3D frontend_changed
-};
+);
=20
=20
 int xen_blkif_xenbus_init(void)
 {
-	return xenbus_register_backend(&xen_blkbk);
+	return xenbus_register_backend(&xen_blkbk_driver);
 }
--- 3.2-rc6/drivers/block/xen-blkfront.c
+++ 3.2-rc6-struct-xenbus_driver/drivers/block/xen-blkfront.c
@@ -1437,16 +1437,13 @@ static const struct xenbus_device_id blk
 	{ "" }
 };
=20
-static struct xenbus_driver blkfront =3D {
-	.name =3D "vbd",
-	.owner =3D THIS_MODULE,
-	.ids =3D blkfront_ids,
+static DEFINE_XENBUS_DRIVER(blkfront, ,
 	.probe =3D blkfront_probe,
 	.remove =3D blkfront_remove,
 	.resume =3D blkfront_resume,
 	.otherend_changed =3D blkback_changed,
 	.is_ready =3D blkfront_is_ready,
-};
+);
=20
 static int __init xlblk_init(void)
 {
@@ -1461,7 +1458,7 @@ static int __init xlblk_init(void)
 		return -ENODEV;
 	}
=20
-	ret =3D xenbus_register_frontend(&blkfront);
+	ret =3D xenbus_register_frontend(&blkfront_driver);
 	if (ret) {
 		unregister_blkdev(XENVBD_MAJOR, DEV_NAME);
 		return ret;
@@ -1474,7 +1471,7 @@ module_init(xlblk_init);
=20
 static void __exit xlblk_exit(void)
 {
-	return xenbus_unregister_driver(&blkfront);
+	return xenbus_unregister_driver(&blkfront_driver);
 }
 module_exit(xlblk_exit);
=20
--- 3.2-rc6/drivers/input/misc/xen-kbdfront.c
+++ 3.2-rc6-struct-xenbus_driver/drivers/input/misc/xen-kbdfront.c
@@ -361,15 +361,12 @@ static const struct xenbus_device_id xen
 	{ "" }
 };
=20
-static struct xenbus_driver xenkbd_driver =3D {
-	.name =3D "vkbd",
-	.owner =3D THIS_MODULE,
-	.ids =3D xenkbd_ids,
+static DEFINE_XENBUS_DRIVER(xenkbd, ,
 	.probe =3D xenkbd_probe,
 	.remove =3D xenkbd_remove,
 	.resume =3D xenkbd_resume,
 	.otherend_changed =3D xenkbd_backend_changed,
-};
+);
=20
 static int __init xenkbd_init(void)
 {
--- 3.2-rc6/drivers/net/xen-netback/xenbus.c
+++ 3.2-rc6-struct-xenbus_driver/drivers/net/xen-netback/xenbus.c
@@ -474,17 +474,14 @@ static const struct xenbus_device_id net
 };
=20
=20
-static struct xenbus_driver netback =3D {
-	.name =3D "vif",
-	.owner =3D THIS_MODULE,
-	.ids =3D netback_ids,
+static DEFINE_XENBUS_DRIVER(netback, ,
 	.probe =3D netback_probe,
 	.remove =3D netback_remove,
 	.uevent =3D netback_uevent,
 	.otherend_changed =3D frontend_changed,
-};
+);
=20
 int xenvif_xenbus_init(void)
 {
-	return xenbus_register_backend(&netback);
+	return xenbus_register_backend(&netback_driver);
 }
--- 3.2-rc6/drivers/net/xen-netfront.c
+++ 3.2-rc6-struct-xenbus_driver/drivers/net/xen-netfront.c
@@ -1910,7 +1910,7 @@ static void xennet_sysfs_delif(struct ne
=20
 #endif /* CONFIG_SYSFS */
=20
-static struct xenbus_device_id netfront_ids[] =3D {
+static const struct xenbus_device_id netfront_ids[] =3D {
 	{ "vif" },
 	{ "" }
 };
@@ -1937,15 +1937,12 @@ static int __devexit xennet_remove(struc
 	return 0;
 }
=20
-static struct xenbus_driver netfront_driver =3D {
-	.name =3D "vif",
-	.owner =3D THIS_MODULE,
-	.ids =3D netfront_ids,
+static DEFINE_XENBUS_DRIVER(netfront, ,
 	.probe =3D netfront_probe,
 	.remove =3D __devexit_p(xennet_remove),
 	.resume =3D netfront_resume,
 	.otherend_changed =3D netback_changed,
-};
+);
=20
 static int __init netif_init(void)
 {
--- 3.2-rc6/drivers/pci/xen-pcifront.c
+++ 3.2-rc6-struct-xenbus_driver/drivers/pci/xen-pcifront.c
@@ -1126,14 +1126,11 @@ static const struct xenbus_device_id xen
 	{""},
 };
=20
-static struct xenbus_driver xenbus_pcifront_driver =3D {
-	.name			=3D "pcifront",
-	.owner			=3D THIS_MODULE,
-	.ids			=3D xenpci_ids,
+static DEFINE_XENBUS_DRIVER(xenpci, "pcifront",
 	.probe			=3D pcifront_xenbus_probe,
 	.remove			=3D pcifront_xenbus_remove,
 	.otherend_changed	=3D pcifront_backend_changed,
-};
+);
=20
 static int __init pcifront_init(void)
 {
@@ -1142,12 +1139,12 @@ static int __init pcifront_init(void)
=20
 	pci_frontend_registrar(1 /* enable */);
=20
-	return xenbus_register_frontend(&xenbus_pcifront_driver);
+	return xenbus_register_frontend(&xenpci_driver);
 }
=20
 static void __exit pcifront_cleanup(void)
 {
-	xenbus_unregister_driver(&xenbus_pcifront_driver);
+	xenbus_unregister_driver(&xenpci_driver);
 	pci_frontend_registrar(0 /* disable */);
 }
 module_init(pcifront_init);
--- 3.2-rc6/drivers/video/xen-fbfront.c
+++ 3.2-rc6-struct-xenbus_driver/drivers/video/xen-fbfront.c
@@ -671,20 +671,17 @@ InitWait:
 	}
 }
=20
-static struct xenbus_device_id xenfb_ids[] =3D {
+static const struct xenbus_device_id xenfb_ids[] =3D {
 	{ "vfb" },
 	{ "" }
 };
=20
-static struct xenbus_driver xenfb_driver =3D {
-	.name =3D "vfb",
-	.owner =3D THIS_MODULE,
-	.ids =3D xenfb_ids,
+static DEFINE_XENBUS_DRIVER(xenfb, ,
 	.probe =3D xenfb_probe,
 	.remove =3D xenfb_remove,
 	.resume =3D xenfb_resume,
 	.otherend_changed =3D xenfb_backend_changed,
-};
+);
=20
 static int __init xenfb_init(void)
 {
--- 3.2-rc6/drivers/xen/xen-pciback/xenbus.c
+++ 3.2-rc6-struct-xenbus_driver/drivers/xen/xen-pciback/xenbus.c
@@ -707,19 +707,16 @@ static int xen_pcibk_xenbus_remove(struc
 	return 0;
 }
=20
-static const struct xenbus_device_id xenpci_ids[] =3D {
+static const struct xenbus_device_id xen_pcibk_ids[] =3D {
 	{"pci"},
 	{""},
 };
=20
-static struct xenbus_driver xenbus_xen_pcibk_driver =3D {
-	.name			=3D DRV_NAME,
-	.owner			=3D THIS_MODULE,
-	.ids			=3D xenpci_ids,
+static DEFINE_XENBUS_DRIVER(xen_pcibk, DRV_NAME,
 	.probe			=3D xen_pcibk_xenbus_probe,
 	.remove			=3D xen_pcibk_xenbus_remove,
 	.otherend_changed	=3D xen_pcibk_frontend_changed,
-};
+);
=20
 const struct xen_pcibk_backend *__read_mostly xen_pcibk_backend;
=20
@@ -735,11 +732,11 @@ int __init xen_pcibk_xenbus_register(voi
 	if (passthrough)
 		xen_pcibk_backend =3D &xen_pcibk_passthrough_backend;
 	pr_info(DRV_NAME ": backend is %s\n", xen_pcibk_backend->name);
-	return xenbus_register_backend(&xenbus_xen_pcibk_driver);
+	return xenbus_register_backend(&xen_pcibk_driver);
 }
=20
 void __exit xen_pcibk_xenbus_unregister(void)
 {
 	destroy_workqueue(xen_pcibk_wq);
-	xenbus_unregister_driver(&xenbus_xen_pcibk_driver);
+	xenbus_unregister_driver(&xen_pcibk_driver);
 }
--- 3.2-rc6/drivers/xen/xenbus/xenbus_probe.c
+++ 3.2-rc6-struct-xenbus_driver/drivers/xen/xenbus/xenbus_probe.c
@@ -291,14 +291,9 @@ void xenbus_dev_shutdown(struct device *
 EXPORT_SYMBOL_GPL(xenbus_dev_shutdown);
=20
 int xenbus_register_driver_common(struct xenbus_driver *drv,
-				  struct xen_bus_type *bus,
-				  struct module *owner,
-				  const char *mod_name)
+				  struct xen_bus_type *bus)
 {
-	drv->driver.name =3D drv->name;
 	drv->driver.bus =3D &bus->bus;
-	drv->driver.owner =3D owner;
-	drv->driver.mod_name =3D mod_name;
=20
 	return driver_register(&drv->driver);
 }
--- 3.2-rc6/drivers/xen/xenbus/xenbus_probe.h
+++ 3.2-rc6-struct-xenbus_driver/drivers/xen/xenbus/xenbus_probe.h
@@ -53,9 +53,7 @@ extern int xenbus_match(struct device *_
 extern int xenbus_dev_probe(struct device *_dev);
 extern int xenbus_dev_remove(struct device *_dev);
 extern int xenbus_register_driver_common(struct xenbus_driver *drv,
-					 struct xen_bus_type *bus,
-					 struct module *owner,
-					 const char *mod_name);
+					 struct xen_bus_type *bus);
 extern int xenbus_probe_node(struct xen_bus_type *bus,
 			     const char *type,
 			     const char *nodename);
--- 3.2-rc6/drivers/xen/xenbus/xenbus_probe_backend.c
+++ 3.2-rc6-struct-xenbus_driver/drivers/xen/xenbus/xenbus_probe_backend.c
@@ -232,15 +232,13 @@ int xenbus_dev_is_online(struct xenbus_d
 }
 EXPORT_SYMBOL_GPL(xenbus_dev_is_online);
=20
-int __xenbus_register_backend(struct xenbus_driver *drv,
-			      struct module *owner, const char *mod_name)
+int xenbus_register_backend(struct xenbus_driver *drv)
 {
 	drv->read_otherend_details =3D read_frontend_details;
=20
-	return xenbus_register_driver_common(drv, &xenbus_backend,
-					     owner, mod_name);
+	return xenbus_register_driver_common(drv, &xenbus_backend);
 }
-EXPORT_SYMBOL_GPL(__xenbus_register_backend);
+EXPORT_SYMBOL_GPL(xenbus_register_backend);
=20
 static int backend_probe_and_watch(struct notifier_block *notifier,
 				   unsigned long event,
--- 3.2-rc6/drivers/xen/xenbus/xenbus_probe_frontend.c
+++ 3.2-rc6-struct-xenbus_driver/drivers/xen/xenbus/xenbus_probe_frontend.c=

@@ -230,15 +230,13 @@ static void wait_for_devices(struct xenb
 			 print_device_status);
 }
=20
-int __xenbus_register_frontend(struct xenbus_driver *drv,
-			       struct module *owner, const char *mod_name)
+int xenbus_register_frontend(struct xenbus_driver *drv)
 {
 	int ret;
=20
 	drv->read_otherend_details =3D read_backend_details;
=20
-	ret =3D xenbus_register_driver_common(drv, &xenbus_frontend,
-					    owner, mod_name);
+	ret =3D xenbus_register_driver_common(drv, &xenbus_frontend);
 	if (ret)
 		return ret;
=20
@@ -247,7 +245,7 @@ int __xenbus_register_frontend(struct xe
=20
 	return 0;
 }
-EXPORT_SYMBOL_GPL(__xenbus_register_frontend);
+EXPORT_SYMBOL_GPL(xenbus_register_frontend);
=20
 static DECLARE_WAIT_QUEUE_HEAD(backend_state_wq);
 static int backend_state;
--- 3.2-rc6/include/xen/xenbus.h
+++ 3.2-rc6-struct-xenbus_driver/include/xen/xenbus.h
@@ -85,8 +85,6 @@ struct xenbus_device_id
=20
 /* A xenbus driver. */
 struct xenbus_driver {
-	char *name;
-	struct module *owner;
 	const struct xenbus_device_id *ids;
 	int (*probe)(struct xenbus_device *dev,
 		     const struct xenbus_device_id *id);
@@ -101,31 +99,20 @@ struct xenbus_driver {
 	int (*is_ready)(struct xenbus_device *dev);
 };
=20
-static inline struct xenbus_driver *to_xenbus_driver(struct device_driver =
*drv)
-{
-	return container_of(drv, struct xenbus_driver, driver);
+#define DEFINE_XENBUS_DRIVER(var, drvname, methods...)		\
+struct xenbus_driver var ## _driver =3D {				\
+	.driver.name =3D drvname + 0 ?: var ## _ids->devicetype,	\
+	.driver.owner =3D THIS_MODULE,				\
+	.ids =3D var ## _ids, ## methods				\
 }
=20
-int __must_check __xenbus_register_frontend(struct xenbus_driver *drv,
-					    struct module *owner,
-					    const char *mod_name);
-
-static inline int __must_check
-xenbus_register_frontend(struct xenbus_driver *drv)
+static inline struct xenbus_driver *to_xenbus_driver(struct device_driver =
*drv)
 {
-	WARN_ON(drv->owner !=3D THIS_MODULE);
-	return __xenbus_register_frontend(drv, THIS_MODULE, KBUILD_MODNAME)=
;
+	return container_of(drv, struct xenbus_driver, driver);
 }
=20
-int __must_check __xenbus_register_backend(struct xenbus_driver *drv,
-					   struct module *owner,
-					   const char *mod_name);
-static inline int __must_check
-xenbus_register_backend(struct xenbus_driver *drv)
-{
-	WARN_ON(drv->owner !=3D THIS_MODULE);
-	return __xenbus_register_backend(drv, THIS_MODULE, KBUILD_MODNAME);=

-}
+int __must_check xenbus_register_frontend(struct xenbus_driver *);
+int __must_check xenbus_register_backend(struct xenbus_driver *);
=20
 void xenbus_unregister_driver(struct xenbus_driver *drv);
=20



--=__Part4A65FB6D.7__=
Content-Type: text/plain; name="linux-3.2-rc6-struct-xenbus_driver.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="linux-3.2-rc6-struct-xenbus_driver.patch"

Xen: consolidate and simplify struct xenbus_driver instantiation=0A=0AThe =
'name', 'owner', and 'mod_name' members are redundant with the=0Aidenticall=
y named fields in the 'driver' sub-structure. Rather than=0Aswitching each =
instance to specify these fields explicitly, introduce=0Aa macro to =
simplify this.=0A=0AEliminate further redundancy by allowing the drvname =
argument to=0ADEFINE_XENBUS_DRIVER() to be blank (in which case the first =
entry from=0Athe ID table will be used for .driver.name).=0A=0AAlso =
eliminate the questionable xenbus_register_{back,front}end()=0Awrappers - =
their sole remaining purpose was the checking of the=0A'owner' field, =
proper setting of which shouldn't be an issue anymore=0Awhen the macro =
gets used.=0A=0Av2: Restore DRV_NAME for the driver name in xen-pciback.=0A=
=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=0ACc: Jens Axboe =
<axboe@kernel.dk>=0ACc: Dmitry Torokhov <dmitry.torokhov@gmail.com>=0ACc: =
Florian Tobias Schandinat <FlorianSchandinat@gmx.de>=0ACc: Ian Campbell =
<ian.campbell@citrix.com>=0ACc: David S. Miller <davem@davemloft.net>=0A=0A=
---=0A drivers/block/xen-blkback/xenbus.c         |    9 ++------=0A =
drivers/block/xen-blkfront.c               |   11 +++-------=0A drivers/inp=
ut/misc/xen-kbdfront.c          |    7 +-----=0A drivers/net/xen-netback/xe=
nbus.c           |    9 ++------=0A drivers/net/xen-netfront.c             =
    |    9 ++------=0A drivers/pci/xen-pcifront.c                 |   11 =
+++-------=0A drivers/video/xen-fbfront.c                |    9 ++------=0A=
 drivers/xen/xen-pciback/xenbus.c           |   13 ++++--------=0A =
drivers/xen/xenbus/xenbus_probe.c          |    7 ------=0A drivers/xen/xen=
bus/xenbus_probe.h          |    4 ---=0A drivers/xen/xenbus/xenbus_probe_b=
ackend.c  |    8 ++-----=0A drivers/xen/xenbus/xenbus_probe_frontend.c |   =
 8 ++-----=0A include/xen/xenbus.h                       |   31 ++++++++---=
------------------=0A 13 files changed, 44 insertions(+), 92 deletions(-)=
=0A=0A--- 3.2-rc6/drivers/block/xen-blkback/xenbus.c=0A+++ 3.2-rc6-struct-x=
enbus_driver/drivers/block/xen-blkback/xenbus.c=0A@@ -787,17 +787,14 @@ =
static const struct xenbus_device_id xen=0A };=0A =0A =0A-static struct =
xenbus_driver xen_blkbk =3D {=0A-	.name =3D "vbd",=0A-	.owner =3D =
THIS_MODULE,=0A-	.ids =3D xen_blkbk_ids,=0A+static DEFINE_XENBUS_DRI=
VER(xen_blkbk, ,=0A 	.probe =3D xen_blkbk_probe,=0A 	.remove =3D =
xen_blkbk_remove,=0A 	.otherend_changed =3D frontend_changed=0A-};=0A+);=
=0A =0A =0A int xen_blkif_xenbus_init(void)=0A {=0A-	return xenbus_regis=
ter_backend(&xen_blkbk);=0A+	return xenbus_register_backend(&xen_blkbk_d=
river);=0A }=0A--- 3.2-rc6/drivers/block/xen-blkfront.c=0A+++ 3.2-rc6-struc=
t-xenbus_driver/drivers/block/xen-blkfront.c=0A@@ -1437,16 +1437,13 @@ =
static const struct xenbus_device_id blk=0A 	{ "" }=0A };=0A =0A-static =
struct xenbus_driver blkfront =3D {=0A-	.name =3D "vbd",=0A-	.owner =3D =
THIS_MODULE,=0A-	.ids =3D blkfront_ids,=0A+static DEFINE_XENBUS_DRIV=
ER(blkfront, ,=0A 	.probe =3D blkfront_probe,=0A 	.remove =3D =
blkfront_remove,=0A 	.resume =3D blkfront_resume,=0A 	.otherend_c=
hanged =3D blkback_changed,=0A 	.is_ready =3D blkfront_is_ready,=0A-};=0A+)=
;=0A =0A static int __init xlblk_init(void)=0A {=0A@@ -1461,7 +1458,7 @@ =
static int __init xlblk_init(void)=0A 		return -ENODEV;=0A 	=
}=0A =0A-	ret =3D xenbus_register_frontend(&blkfront);=0A+	=
ret =3D xenbus_register_frontend(&blkfront_driver);=0A 	if (ret) {=0A 		=
unregister_blkdev(XENVBD_MAJOR, DEV_NAME);=0A 		return ret;=0A@@ =
-1474,7 +1471,7 @@ module_init(xlblk_init);=0A =0A static void __exit =
xlblk_exit(void)=0A {=0A-	return xenbus_unregister_driver(&blkfront);=
=0A+	return xenbus_unregister_driver(&blkfront_driver);=0A }=0A =
module_exit(xlblk_exit);=0A =0A--- 3.2-rc6/drivers/input/misc/xen-kbdfront.=
c=0A+++ 3.2-rc6-struct-xenbus_driver/drivers/input/misc/xen-kbdfront.c=0A@@=
 -361,15 +361,12 @@ static const struct xenbus_device_id xen=0A 	{ =
"" }=0A };=0A =0A-static struct xenbus_driver xenkbd_driver =3D {=0A-	=
.name =3D "vkbd",=0A-	.owner =3D THIS_MODULE,=0A-	.ids =3D xenkbd_ids=
,=0A+static DEFINE_XENBUS_DRIVER(xenkbd, ,=0A 	.probe =3D xenkbd_probe,=0A=
 	.remove =3D xenkbd_remove,=0A 	.resume =3D xenkbd_resume,=0A 	=
.otherend_changed =3D xenkbd_backend_changed,=0A-};=0A+);=0A =0A static =
int __init xenkbd_init(void)=0A {=0A--- 3.2-rc6/drivers/net/xen-netback/xen=
bus.c=0A+++ 3.2-rc6-struct-xenbus_driver/drivers/net/xen-netback/xenbus.c=
=0A@@ -474,17 +474,14 @@ static const struct xenbus_device_id net=0A };=0A =
=0A =0A-static struct xenbus_driver netback =3D {=0A-	.name =3D =
"vif",=0A-	.owner =3D THIS_MODULE,=0A-	.ids =3D netback_ids,=0A+st=
atic DEFINE_XENBUS_DRIVER(netback, ,=0A 	.probe =3D netback_probe,=
=0A 	.remove =3D netback_remove,=0A 	.uevent =3D netback_uevent,=0A 	=
.otherend_changed =3D frontend_changed,=0A-};=0A+);=0A =0A int xenvif_xenbu=
s_init(void)=0A {=0A-	return xenbus_register_backend(&netback);=0A+	=
return xenbus_register_backend(&netback_driver);=0A }=0A--- 3.2-rc6/drivers=
/net/xen-netfront.c=0A+++ 3.2-rc6-struct-xenbus_driver/drivers/net/xen-netf=
ront.c=0A@@ -1910,7 +1910,7 @@ static void xennet_sysfs_delif(struct ne=0A =
=0A #endif /* CONFIG_SYSFS */=0A =0A-static struct xenbus_device_id =
netfront_ids[] =3D {=0A+static const struct xenbus_device_id netfront_ids[]=
 =3D {=0A 	{ "vif" },=0A 	{ "" }=0A };=0A@@ -1937,15 +1937,12 @@ =
static int __devexit xennet_remove(struc=0A 	return 0;=0A }=0A =
=0A-static struct xenbus_driver netfront_driver =3D {=0A-	.name =3D =
"vif",=0A-	.owner =3D THIS_MODULE,=0A-	.ids =3D netfront_ids,=0A+s=
tatic DEFINE_XENBUS_DRIVER(netfront, ,=0A 	.probe =3D netfront_probe,=
=0A 	.remove =3D __devexit_p(xennet_remove),=0A 	.resume =3D =
netfront_resume,=0A 	.otherend_changed =3D netback_changed,=0A-};=0A+);=
=0A =0A static int __init netif_init(void)=0A {=0A--- 3.2-rc6/drivers/pci/x=
en-pcifront.c=0A+++ 3.2-rc6-struct-xenbus_driver/drivers/pci/xen-pcifront.c=
=0A@@ -1126,14 +1126,11 @@ static const struct xenbus_device_id xen=0A 	=
{""},=0A };=0A =0A-static struct xenbus_driver xenbus_pcifront_driver =3D =
{=0A-	.name			=3D "pcifront",=0A-	.owner			=
=3D THIS_MODULE,=0A-	.ids			=3D xenpci_ids,=0A+static =
DEFINE_XENBUS_DRIVER(xenpci, "pcifront",=0A 	.probe			=
=3D pcifront_xenbus_probe,=0A 	.remove			=3D pcifront_xenbus=
_remove,=0A 	.otherend_changed	=3D pcifront_backend_changed,=0A-};=
=0A+);=0A =0A static int __init pcifront_init(void)=0A {=0A@@ -1142,12 =
+1139,12 @@ static int __init pcifront_init(void)=0A =0A 	pci_fronten=
d_registrar(1 /* enable */);=0A =0A-	return xenbus_register_frontend(&xe=
nbus_pcifront_driver);=0A+	return xenbus_register_frontend(&xenpci_dri=
ver);=0A }=0A =0A static void __exit pcifront_cleanup(void)=0A {=0A-	=
xenbus_unregister_driver(&xenbus_pcifront_driver);=0A+	xenbus_unregister_d=
river(&xenpci_driver);=0A 	pci_frontend_registrar(0 /* disable =
*/);=0A }=0A module_init(pcifront_init);=0A--- 3.2-rc6/drivers/video/xen-fb=
front.c=0A+++ 3.2-rc6-struct-xenbus_driver/drivers/video/xen-fbfront.c=0A@@=
 -671,20 +671,17 @@ InitWait:=0A 	}=0A }=0A =0A-static struct =
xenbus_device_id xenfb_ids[] =3D {=0A+static const struct xenbus_device_id =
xenfb_ids[] =3D {=0A 	{ "vfb" },=0A 	{ "" }=0A };=0A =0A-static struct =
xenbus_driver xenfb_driver =3D {=0A-	.name =3D "vfb",=0A-	.owner =3D =
THIS_MODULE,=0A-	.ids =3D xenfb_ids,=0A+static DEFINE_XENBUS_DRIVER(=
xenfb, ,=0A 	.probe =3D xenfb_probe,=0A 	.remove =3D xenfb_remove,=
=0A 	.resume =3D xenfb_resume,=0A 	.otherend_changed =3D xenfb_backend=
_changed,=0A-};=0A+);=0A =0A static int __init xenfb_init(void)=0A {=0A--- =
3.2-rc6/drivers/xen/xen-pciback/xenbus.c=0A+++ 3.2-rc6-struct-xenbus_driver=
/drivers/xen/xen-pciback/xenbus.c=0A@@ -707,19 +707,16 @@ static int =
xen_pcibk_xenbus_remove(struc=0A 	return 0;=0A }=0A =0A-static const =
struct xenbus_device_id xenpci_ids[] =3D {=0A+static const struct =
xenbus_device_id xen_pcibk_ids[] =3D {=0A 	{"pci"},=0A 	{""},=0A =
};=0A =0A-static struct xenbus_driver xenbus_xen_pcibk_driver =3D {=0A-	=
.name			=3D DRV_NAME,=0A-	.owner			=
=3D THIS_MODULE,=0A-	.ids			=3D xenpci_ids,=0A+static =
DEFINE_XENBUS_DRIVER(xen_pcibk, DRV_NAME,=0A 	.probe			=
=3D xen_pcibk_xenbus_probe,=0A 	.remove			=3D xen_pcibk_xenbu=
s_remove,=0A 	.otherend_changed	=3D xen_pcibk_frontend_changed,=0A-=
};=0A+);=0A =0A const struct xen_pcibk_backend *__read_mostly xen_pcibk_bac=
kend;=0A =0A@@ -735,11 +732,11 @@ int __init xen_pcibk_xenbus_register(voi=
=0A 	if (passthrough)=0A 		xen_pcibk_backend =3D &xen_pcibk_pa=
ssthrough_backend;=0A 	pr_info(DRV_NAME ": backend is %s\n", xen_pcibk_bac=
kend->name);=0A-	return xenbus_register_backend(&xenbus_xen_pcibk_dr=
iver);=0A+	return xenbus_register_backend(&xen_pcibk_driver);=0A }=0A =
=0A void __exit xen_pcibk_xenbus_unregister(void)=0A {=0A 	destroy_wor=
kqueue(xen_pcibk_wq);=0A-	xenbus_unregister_driver(&xenbus_xen_pcibk_=
driver);=0A+	xenbus_unregister_driver(&xen_pcibk_driver);=0A }=0A--- =
3.2-rc6/drivers/xen/xenbus/xenbus_probe.c=0A+++ 3.2-rc6-struct-xenbus_drive=
r/drivers/xen/xenbus/xenbus_probe.c=0A@@ -291,14 +291,9 @@ void xenbus_dev_=
shutdown(struct device *=0A EXPORT_SYMBOL_GPL(xenbus_dev_shutdown);=0A =0A =
int xenbus_register_driver_common(struct xenbus_driver *drv,=0A-		=
		  struct xen_bus_type *bus,=0A-				  =
struct module *owner,=0A-				  const char =
*mod_name)=0A+				  struct xen_bus_type *bus)=0A =
{=0A-	drv->driver.name =3D drv->name;=0A 	drv->driver.bus =3D =
&bus->bus;=0A-	drv->driver.owner =3D owner;=0A-	drv->driver.mod_nam=
e =3D mod_name;=0A =0A 	return driver_register(&drv->driver);=0A }=0A--- =
3.2-rc6/drivers/xen/xenbus/xenbus_probe.h=0A+++ 3.2-rc6-struct-xenbus_drive=
r/drivers/xen/xenbus/xenbus_probe.h=0A@@ -53,9 +53,7 @@ extern int =
xenbus_match(struct device *_=0A extern int xenbus_dev_probe(struct device =
*_dev);=0A extern int xenbus_dev_remove(struct device *_dev);=0A extern =
int xenbus_register_driver_common(struct xenbus_driver *drv,=0A-		=
			 struct xen_bus_type *bus,=0A-				=
	 struct module *owner,=0A-					 =
const char *mod_name);=0A+					 struct =
xen_bus_type *bus);=0A extern int xenbus_probe_node(struct xen_bus_type =
*bus,=0A 			     const char *type,=0A 			=
     const char *nodename);=0A--- 3.2-rc6/drivers/xen/xenbus/xenbus_probe_b=
ackend.c=0A+++ 3.2-rc6-struct-xenbus_driver/drivers/xen/xenbus/xenbus_probe=
_backend.c=0A@@ -232,15 +232,13 @@ int xenbus_dev_is_online(struct =
xenbus_d=0A }=0A EXPORT_SYMBOL_GPL(xenbus_dev_is_online);=0A =0A-int =
__xenbus_register_backend(struct xenbus_driver *drv,=0A-			=
      struct module *owner, const char *mod_name)=0A+int xenbus_register_ba=
ckend(struct xenbus_driver *drv)=0A {=0A 	drv->read_otherend_details =
=3D read_frontend_details;=0A =0A-	return xenbus_register_driver_commo=
n(drv, &xenbus_backend,=0A-					     =
owner, mod_name);=0A+	return xenbus_register_driver_common(drv, =
&xenbus_backend);=0A }=0A-EXPORT_SYMBOL_GPL(__xenbus_register_backend);=0A+=
EXPORT_SYMBOL_GPL(xenbus_register_backend);=0A =0A static int backend_probe=
_and_watch(struct notifier_block *notifier,=0A 				   =
unsigned long event,=0A--- 3.2-rc6/drivers/xen/xenbus/xenbus_probe_frontend=
.c=0A+++ 3.2-rc6-struct-xenbus_driver/drivers/xen/xenbus/xenbus_probe_front=
end.c=0A@@ -230,15 +230,13 @@ static void wait_for_devices(struct xenb=0A 	=
		 print_device_status);=0A }=0A =0A-int __xenbus_register_fr=
ontend(struct xenbus_driver *drv,=0A-			       struct =
module *owner, const char *mod_name)=0A+int xenbus_register_frontend(struct=
 xenbus_driver *drv)=0A {=0A 	int ret;=0A =0A 	drv->read_otherend_=
details =3D read_backend_details;=0A =0A-	ret =3D xenbus_register_dri=
ver_common(drv, &xenbus_frontend,=0A-					   =
 owner, mod_name);=0A+	ret =3D xenbus_register_driver_common(drv, =
&xenbus_frontend);=0A 	if (ret)=0A 		return ret;=0A =0A@@ =
-247,7 +245,7 @@ int __xenbus_register_frontend(struct xe=0A =0A 	=
return 0;=0A }=0A-EXPORT_SYMBOL_GPL(__xenbus_register_frontend);=0A+EXPORT_=
SYMBOL_GPL(xenbus_register_frontend);=0A =0A static DECLARE_WAIT_QUEUE_HEAD=
(backend_state_wq);=0A static int backend_state;=0A--- 3.2-rc6/include/xen/=
xenbus.h=0A+++ 3.2-rc6-struct-xenbus_driver/include/xen/xenbus.h=0A@@ =
-85,8 +85,6 @@ struct xenbus_device_id=0A =0A /* A xenbus driver. */=0A =
struct xenbus_driver {=0A-	char *name;=0A-	struct module *owner;=0A 	=
const struct xenbus_device_id *ids;=0A 	int (*probe)(struct xenbus_device =
*dev,=0A 		     const struct xenbus_device_id *id);=0A@@ =
-101,31 +99,20 @@ struct xenbus_driver {=0A 	int (*is_ready)(struct =
xenbus_device *dev);=0A };=0A =0A-static inline struct xenbus_driver =
*to_xenbus_driver(struct device_driver *drv)=0A-{=0A-	return container_of=
(drv, struct xenbus_driver, driver);=0A+#define DEFINE_XENBUS_DRIVER(var, =
drvname, methods...)		\=0A+struct xenbus_driver var ## _driver =
=3D {				\=0A+	.driver.name =3D drvname + 0 ?: =
var ## _ids->devicetype,	\=0A+	.driver.owner =3D THIS_MODULE,		=
		\=0A+	.ids =3D var ## _ids, ## methods			=
	\=0A }=0A =0A-int __must_check __xenbus_register_frontend(struct =
xenbus_driver *drv,=0A-					    struct module =
*owner,=0A-					    const char *mod_name);=
=0A-=0A-static inline int __must_check=0A-xenbus_register_frontend(struct =
xenbus_driver *drv)=0A+static inline struct xenbus_driver *to_xenbus_driver=
(struct device_driver *drv)=0A {=0A-	WARN_ON(drv->owner !=3D THIS_MODULE=
);=0A-	return __xenbus_register_frontend(drv, THIS_MODULE, KBUILD_MODNAME)=
;=0A+	return container_of(drv, struct xenbus_driver, driver);=0A }=0A =
=0A-int __must_check __xenbus_register_backend(struct xenbus_driver =
*drv,=0A-					   struct module *owner,=0A=
-					   const char *mod_name);=0A-static=
 inline int __must_check=0A-xenbus_register_backend(struct xenbus_driver =
*drv)=0A-{=0A-	WARN_ON(drv->owner !=3D THIS_MODULE);=0A-	return =
__xenbus_register_backend(drv, THIS_MODULE, KBUILD_MODNAME);=0A-}=0A+int =
__must_check xenbus_register_frontend(struct xenbus_driver *);=0A+int =
__must_check xenbus_register_backend(struct xenbus_driver *);=0A =0A void =
xenbus_unregister_driver(struct xenbus_driver *drv);=0A =0A
--=__Part4A65FB6D.7__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--=__Part4A65FB6D.7__=--


From xen-devel-bounces@lists.xensource.com Thu Dec 22 09:07:56 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 Dec 2011 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.xensource.com>)
	id 1Rdecb-0002U5-Rd; Thu, 22 Dec 2011 09:07:29 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RdecZ-0002TS-Vu
	for xen-devel@lists.xensource.com; Thu, 22 Dec 2011 09:07:28 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1324544840!8367100!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6571 invoked from network); 22 Dec 2011 09:07:20 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-3.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 22 Dec 2011 09:07:20 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 22 Dec 2011 09:07:19 +0000
Message-Id: <4EF3018D020000780006986E@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 22 Dec 2011 09:08:13 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad@darnok.org>,
	"Jeremy Fitzhardinge" <jeremy@goop.org>,
	"Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part4A65FB6D.7__="
Cc: Jens Axboe <axboe@kernel.dk>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <ian.campbell@citrix.com>, FlorianSchandinat@gmx.de,
	netdev@vger.kernel.org, dmitry.torokhov@gmail.com,
	linux-kernel@vger.kernel.org, davem@davemloft.net
Subject: [Xen-devel] [PATCH,
 v2] Xen: consolidate and simplify struct xenbus_driver instantiation
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__Part4A65FB6D.7__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

The 'name', 'owner', and 'mod_name' members are redundant with the
identically named fields in the 'driver' sub-structure. Rather than
switching each instance to specify these fields explicitly, introduce
a macro to simplify this.

Eliminate further redundancy by allowing the drvname argument to
DEFINE_XENBUS_DRIVER() to be blank (in which case the first entry from
the ID table will be used for .driver.name).

Also eliminate the questionable xenbus_register_{back,front}end()
wrappers - their sole remaining purpose was the checking of the
'owner' field, proper setting of which shouldn't be an issue anymore
when the macro gets used.

v2: Restore DRV_NAME for the driver name in xen-pciback.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Cc: Jens Axboe <axboe@kernel.dk>
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: David S. Miller <davem@davemloft.net>

---
 drivers/block/xen-blkback/xenbus.c         |    9 ++------
 drivers/block/xen-blkfront.c               |   11 +++-------
 drivers/input/misc/xen-kbdfront.c          |    7 +-----
 drivers/net/xen-netback/xenbus.c           |    9 ++------
 drivers/net/xen-netfront.c                 |    9 ++------
 drivers/pci/xen-pcifront.c                 |   11 +++-------
 drivers/video/xen-fbfront.c                |    9 ++------
 drivers/xen/xen-pciback/xenbus.c           |   13 ++++--------
 drivers/xen/xenbus/xenbus_probe.c          |    7 ------
 drivers/xen/xenbus/xenbus_probe.h          |    4 ---
 drivers/xen/xenbus/xenbus_probe_backend.c  |    8 ++-----
 drivers/xen/xenbus/xenbus_probe_frontend.c |    8 ++-----
 include/xen/xenbus.h                       |   31 ++++++++----------------=
-----
 13 files changed, 44 insertions(+), 92 deletions(-)

--- 3.2-rc6/drivers/block/xen-blkback/xenbus.c
+++ 3.2-rc6-struct-xenbus_driver/drivers/block/xen-blkback/xenbus.c
@@ -787,17 +787,14 @@ static const struct xenbus_device_id xen
 };
=20
=20
-static struct xenbus_driver xen_blkbk =3D {
-	.name =3D "vbd",
-	.owner =3D THIS_MODULE,
-	.ids =3D xen_blkbk_ids,
+static DEFINE_XENBUS_DRIVER(xen_blkbk, ,
 	.probe =3D xen_blkbk_probe,
 	.remove =3D xen_blkbk_remove,
 	.otherend_changed =3D frontend_changed
-};
+);
=20
=20
 int xen_blkif_xenbus_init(void)
 {
-	return xenbus_register_backend(&xen_blkbk);
+	return xenbus_register_backend(&xen_blkbk_driver);
 }
--- 3.2-rc6/drivers/block/xen-blkfront.c
+++ 3.2-rc6-struct-xenbus_driver/drivers/block/xen-blkfront.c
@@ -1437,16 +1437,13 @@ static const struct xenbus_device_id blk
 	{ "" }
 };
=20
-static struct xenbus_driver blkfront =3D {
-	.name =3D "vbd",
-	.owner =3D THIS_MODULE,
-	.ids =3D blkfront_ids,
+static DEFINE_XENBUS_DRIVER(blkfront, ,
 	.probe =3D blkfront_probe,
 	.remove =3D blkfront_remove,
 	.resume =3D blkfront_resume,
 	.otherend_changed =3D blkback_changed,
 	.is_ready =3D blkfront_is_ready,
-};
+);
=20
 static int __init xlblk_init(void)
 {
@@ -1461,7 +1458,7 @@ static int __init xlblk_init(void)
 		return -ENODEV;
 	}
=20
-	ret =3D xenbus_register_frontend(&blkfront);
+	ret =3D xenbus_register_frontend(&blkfront_driver);
 	if (ret) {
 		unregister_blkdev(XENVBD_MAJOR, DEV_NAME);
 		return ret;
@@ -1474,7 +1471,7 @@ module_init(xlblk_init);
=20
 static void __exit xlblk_exit(void)
 {
-	return xenbus_unregister_driver(&blkfront);
+	return xenbus_unregister_driver(&blkfront_driver);
 }
 module_exit(xlblk_exit);
=20
--- 3.2-rc6/drivers/input/misc/xen-kbdfront.c
+++ 3.2-rc6-struct-xenbus_driver/drivers/input/misc/xen-kbdfront.c
@@ -361,15 +361,12 @@ static const struct xenbus_device_id xen
 	{ "" }
 };
=20
-static struct xenbus_driver xenkbd_driver =3D {
-	.name =3D "vkbd",
-	.owner =3D THIS_MODULE,
-	.ids =3D xenkbd_ids,
+static DEFINE_XENBUS_DRIVER(xenkbd, ,
 	.probe =3D xenkbd_probe,
 	.remove =3D xenkbd_remove,
 	.resume =3D xenkbd_resume,
 	.otherend_changed =3D xenkbd_backend_changed,
-};
+);
=20
 static int __init xenkbd_init(void)
 {
--- 3.2-rc6/drivers/net/xen-netback/xenbus.c
+++ 3.2-rc6-struct-xenbus_driver/drivers/net/xen-netback/xenbus.c
@@ -474,17 +474,14 @@ static const struct xenbus_device_id net
 };
=20
=20
-static struct xenbus_driver netback =3D {
-	.name =3D "vif",
-	.owner =3D THIS_MODULE,
-	.ids =3D netback_ids,
+static DEFINE_XENBUS_DRIVER(netback, ,
 	.probe =3D netback_probe,
 	.remove =3D netback_remove,
 	.uevent =3D netback_uevent,
 	.otherend_changed =3D frontend_changed,
-};
+);
=20
 int xenvif_xenbus_init(void)
 {
-	return xenbus_register_backend(&netback);
+	return xenbus_register_backend(&netback_driver);
 }
--- 3.2-rc6/drivers/net/xen-netfront.c
+++ 3.2-rc6-struct-xenbus_driver/drivers/net/xen-netfront.c
@@ -1910,7 +1910,7 @@ static void xennet_sysfs_delif(struct ne
=20
 #endif /* CONFIG_SYSFS */
=20
-static struct xenbus_device_id netfront_ids[] =3D {
+static const struct xenbus_device_id netfront_ids[] =3D {
 	{ "vif" },
 	{ "" }
 };
@@ -1937,15 +1937,12 @@ static int __devexit xennet_remove(struc
 	return 0;
 }
=20
-static struct xenbus_driver netfront_driver =3D {
-	.name =3D "vif",
-	.owner =3D THIS_MODULE,
-	.ids =3D netfront_ids,
+static DEFINE_XENBUS_DRIVER(netfront, ,
 	.probe =3D netfront_probe,
 	.remove =3D __devexit_p(xennet_remove),
 	.resume =3D netfront_resume,
 	.otherend_changed =3D netback_changed,
-};
+);
=20
 static int __init netif_init(void)
 {
--- 3.2-rc6/drivers/pci/xen-pcifront.c
+++ 3.2-rc6-struct-xenbus_driver/drivers/pci/xen-pcifront.c
@@ -1126,14 +1126,11 @@ static const struct xenbus_device_id xen
 	{""},
 };
=20
-static struct xenbus_driver xenbus_pcifront_driver =3D {
-	.name			=3D "pcifront",
-	.owner			=3D THIS_MODULE,
-	.ids			=3D xenpci_ids,
+static DEFINE_XENBUS_DRIVER(xenpci, "pcifront",
 	.probe			=3D pcifront_xenbus_probe,
 	.remove			=3D pcifront_xenbus_remove,
 	.otherend_changed	=3D pcifront_backend_changed,
-};
+);
=20
 static int __init pcifront_init(void)
 {
@@ -1142,12 +1139,12 @@ static int __init pcifront_init(void)
=20
 	pci_frontend_registrar(1 /* enable */);
=20
-	return xenbus_register_frontend(&xenbus_pcifront_driver);
+	return xenbus_register_frontend(&xenpci_driver);
 }
=20
 static void __exit pcifront_cleanup(void)
 {
-	xenbus_unregister_driver(&xenbus_pcifront_driver);
+	xenbus_unregister_driver(&xenpci_driver);
 	pci_frontend_registrar(0 /* disable */);
 }
 module_init(pcifront_init);
--- 3.2-rc6/drivers/video/xen-fbfront.c
+++ 3.2-rc6-struct-xenbus_driver/drivers/video/xen-fbfront.c
@@ -671,20 +671,17 @@ InitWait:
 	}
 }
=20
-static struct xenbus_device_id xenfb_ids[] =3D {
+static const struct xenbus_device_id xenfb_ids[] =3D {
 	{ "vfb" },
 	{ "" }
 };
=20
-static struct xenbus_driver xenfb_driver =3D {
-	.name =3D "vfb",
-	.owner =3D THIS_MODULE,
-	.ids =3D xenfb_ids,
+static DEFINE_XENBUS_DRIVER(xenfb, ,
 	.probe =3D xenfb_probe,
 	.remove =3D xenfb_remove,
 	.resume =3D xenfb_resume,
 	.otherend_changed =3D xenfb_backend_changed,
-};
+);
=20
 static int __init xenfb_init(void)
 {
--- 3.2-rc6/drivers/xen/xen-pciback/xenbus.c
+++ 3.2-rc6-struct-xenbus_driver/drivers/xen/xen-pciback/xenbus.c
@@ -707,19 +707,16 @@ static int xen_pcibk_xenbus_remove(struc
 	return 0;
 }
=20
-static const struct xenbus_device_id xenpci_ids[] =3D {
+static const struct xenbus_device_id xen_pcibk_ids[] =3D {
 	{"pci"},
 	{""},
 };
=20
-static struct xenbus_driver xenbus_xen_pcibk_driver =3D {
-	.name			=3D DRV_NAME,
-	.owner			=3D THIS_MODULE,
-	.ids			=3D xenpci_ids,
+static DEFINE_XENBUS_DRIVER(xen_pcibk, DRV_NAME,
 	.probe			=3D xen_pcibk_xenbus_probe,
 	.remove			=3D xen_pcibk_xenbus_remove,
 	.otherend_changed	=3D xen_pcibk_frontend_changed,
-};
+);
=20
 const struct xen_pcibk_backend *__read_mostly xen_pcibk_backend;
=20
@@ -735,11 +732,11 @@ int __init xen_pcibk_xenbus_register(voi
 	if (passthrough)
 		xen_pcibk_backend =3D &xen_pcibk_passthrough_backend;
 	pr_info(DRV_NAME ": backend is %s\n", xen_pcibk_backend->name);
-	return xenbus_register_backend(&xenbus_xen_pcibk_driver);
+	return xenbus_register_backend(&xen_pcibk_driver);
 }
=20
 void __exit xen_pcibk_xenbus_unregister(void)
 {
 	destroy_workqueue(xen_pcibk_wq);
-	xenbus_unregister_driver(&xenbus_xen_pcibk_driver);
+	xenbus_unregister_driver(&xen_pcibk_driver);
 }
--- 3.2-rc6/drivers/xen/xenbus/xenbus_probe.c
+++ 3.2-rc6-struct-xenbus_driver/drivers/xen/xenbus/xenbus_probe.c
@@ -291,14 +291,9 @@ void xenbus_dev_shutdown(struct device *
 EXPORT_SYMBOL_GPL(xenbus_dev_shutdown);
=20
 int xenbus_register_driver_common(struct xenbus_driver *drv,
-				  struct xen_bus_type *bus,
-				  struct module *owner,
-				  const char *mod_name)
+				  struct xen_bus_type *bus)
 {
-	drv->driver.name =3D drv->name;
 	drv->driver.bus =3D &bus->bus;
-	drv->driver.owner =3D owner;
-	drv->driver.mod_name =3D mod_name;
=20
 	return driver_register(&drv->driver);
 }
--- 3.2-rc6/drivers/xen/xenbus/xenbus_probe.h
+++ 3.2-rc6-struct-xenbus_driver/drivers/xen/xenbus/xenbus_probe.h
@@ -53,9 +53,7 @@ extern int xenbus_match(struct device *_
 extern int xenbus_dev_probe(struct device *_dev);
 extern int xenbus_dev_remove(struct device *_dev);
 extern int xenbus_register_driver_common(struct xenbus_driver *drv,
-					 struct xen_bus_type *bus,
-					 struct module *owner,
-					 const char *mod_name);
+					 struct xen_bus_type *bus);
 extern int xenbus_probe_node(struct xen_bus_type *bus,
 			     const char *type,
 			     const char *nodename);
--- 3.2-rc6/drivers/xen/xenbus/xenbus_probe_backend.c
+++ 3.2-rc6-struct-xenbus_driver/drivers/xen/xenbus/xenbus_probe_backend.c
@@ -232,15 +232,13 @@ int xenbus_dev_is_online(struct xenbus_d
 }
 EXPORT_SYMBOL_GPL(xenbus_dev_is_online);
=20
-int __xenbus_register_backend(struct xenbus_driver *drv,
-			      struct module *owner, const char *mod_name)
+int xenbus_register_backend(struct xenbus_driver *drv)
 {
 	drv->read_otherend_details =3D read_frontend_details;
=20
-	return xenbus_register_driver_common(drv, &xenbus_backend,
-					     owner, mod_name);
+	return xenbus_register_driver_common(drv, &xenbus_backend);
 }
-EXPORT_SYMBOL_GPL(__xenbus_register_backend);
+EXPORT_SYMBOL_GPL(xenbus_register_backend);
=20
 static int backend_probe_and_watch(struct notifier_block *notifier,
 				   unsigned long event,
--- 3.2-rc6/drivers/xen/xenbus/xenbus_probe_frontend.c
+++ 3.2-rc6-struct-xenbus_driver/drivers/xen/xenbus/xenbus_probe_frontend.c=

@@ -230,15 +230,13 @@ static void wait_for_devices(struct xenb
 			 print_device_status);
 }
=20
-int __xenbus_register_frontend(struct xenbus_driver *drv,
-			       struct module *owner, const char *mod_name)
+int xenbus_register_frontend(struct xenbus_driver *drv)
 {
 	int ret;
=20
 	drv->read_otherend_details =3D read_backend_details;
=20
-	ret =3D xenbus_register_driver_common(drv, &xenbus_frontend,
-					    owner, mod_name);
+	ret =3D xenbus_register_driver_common(drv, &xenbus_frontend);
 	if (ret)
 		return ret;
=20
@@ -247,7 +245,7 @@ int __xenbus_register_frontend(struct xe
=20
 	return 0;
 }
-EXPORT_SYMBOL_GPL(__xenbus_register_frontend);
+EXPORT_SYMBOL_GPL(xenbus_register_frontend);
=20
 static DECLARE_WAIT_QUEUE_HEAD(backend_state_wq);
 static int backend_state;
--- 3.2-rc6/include/xen/xenbus.h
+++ 3.2-rc6-struct-xenbus_driver/include/xen/xenbus.h
@@ -85,8 +85,6 @@ struct xenbus_device_id
=20
 /* A xenbus driver. */
 struct xenbus_driver {
-	char *name;
-	struct module *owner;
 	const struct xenbus_device_id *ids;
 	int (*probe)(struct xenbus_device *dev,
 		     const struct xenbus_device_id *id);
@@ -101,31 +99,20 @@ struct xenbus_driver {
 	int (*is_ready)(struct xenbus_device *dev);
 };
=20
-static inline struct xenbus_driver *to_xenbus_driver(struct device_driver =
*drv)
-{
-	return container_of(drv, struct xenbus_driver, driver);
+#define DEFINE_XENBUS_DRIVER(var, drvname, methods...)		\
+struct xenbus_driver var ## _driver =3D {				\
+	.driver.name =3D drvname + 0 ?: var ## _ids->devicetype,	\
+	.driver.owner =3D THIS_MODULE,				\
+	.ids =3D var ## _ids, ## methods				\
 }
=20
-int __must_check __xenbus_register_frontend(struct xenbus_driver *drv,
-					    struct module *owner,
-					    const char *mod_name);
-
-static inline int __must_check
-xenbus_register_frontend(struct xenbus_driver *drv)
+static inline struct xenbus_driver *to_xenbus_driver(struct device_driver =
*drv)
 {
-	WARN_ON(drv->owner !=3D THIS_MODULE);
-	return __xenbus_register_frontend(drv, THIS_MODULE, KBUILD_MODNAME)=
;
+	return container_of(drv, struct xenbus_driver, driver);
 }
=20
-int __must_check __xenbus_register_backend(struct xenbus_driver *drv,
-					   struct module *owner,
-					   const char *mod_name);
-static inline int __must_check
-xenbus_register_backend(struct xenbus_driver *drv)
-{
-	WARN_ON(drv->owner !=3D THIS_MODULE);
-	return __xenbus_register_backend(drv, THIS_MODULE, KBUILD_MODNAME);=

-}
+int __must_check xenbus_register_frontend(struct xenbus_driver *);
+int __must_check xenbus_register_backend(struct xenbus_driver *);
=20
 void xenbus_unregister_driver(struct xenbus_driver *drv);
=20



--=__Part4A65FB6D.7__=
Content-Type: text/plain; name="linux-3.2-rc6-struct-xenbus_driver.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="linux-3.2-rc6-struct-xenbus_driver.patch"

Xen: consolidate and simplify struct xenbus_driver instantiation=0A=0AThe =
'name', 'owner', and 'mod_name' members are redundant with the=0Aidenticall=
y named fields in the 'driver' sub-structure. Rather than=0Aswitching each =
instance to specify these fields explicitly, introduce=0Aa macro to =
simplify this.=0A=0AEliminate further redundancy by allowing the drvname =
argument to=0ADEFINE_XENBUS_DRIVER() to be blank (in which case the first =
entry from=0Athe ID table will be used for .driver.name).=0A=0AAlso =
eliminate the questionable xenbus_register_{back,front}end()=0Awrappers - =
their sole remaining purpose was the checking of the=0A'owner' field, =
proper setting of which shouldn't be an issue anymore=0Awhen the macro =
gets used.=0A=0Av2: Restore DRV_NAME for the driver name in xen-pciback.=0A=
=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=0ACc: Jens Axboe =
<axboe@kernel.dk>=0ACc: Dmitry Torokhov <dmitry.torokhov@gmail.com>=0ACc: =
Florian Tobias Schandinat <FlorianSchandinat@gmx.de>=0ACc: Ian Campbell =
<ian.campbell@citrix.com>=0ACc: David S. Miller <davem@davemloft.net>=0A=0A=
---=0A drivers/block/xen-blkback/xenbus.c         |    9 ++------=0A =
drivers/block/xen-blkfront.c               |   11 +++-------=0A drivers/inp=
ut/misc/xen-kbdfront.c          |    7 +-----=0A drivers/net/xen-netback/xe=
nbus.c           |    9 ++------=0A drivers/net/xen-netfront.c             =
    |    9 ++------=0A drivers/pci/xen-pcifront.c                 |   11 =
+++-------=0A drivers/video/xen-fbfront.c                |    9 ++------=0A=
 drivers/xen/xen-pciback/xenbus.c           |   13 ++++--------=0A =
drivers/xen/xenbus/xenbus_probe.c          |    7 ------=0A drivers/xen/xen=
bus/xenbus_probe.h          |    4 ---=0A drivers/xen/xenbus/xenbus_probe_b=
ackend.c  |    8 ++-----=0A drivers/xen/xenbus/xenbus_probe_frontend.c |   =
 8 ++-----=0A include/xen/xenbus.h                       |   31 ++++++++---=
------------------=0A 13 files changed, 44 insertions(+), 92 deletions(-)=
=0A=0A--- 3.2-rc6/drivers/block/xen-blkback/xenbus.c=0A+++ 3.2-rc6-struct-x=
enbus_driver/drivers/block/xen-blkback/xenbus.c=0A@@ -787,17 +787,14 @@ =
static const struct xenbus_device_id xen=0A };=0A =0A =0A-static struct =
xenbus_driver xen_blkbk =3D {=0A-	.name =3D "vbd",=0A-	.owner =3D =
THIS_MODULE,=0A-	.ids =3D xen_blkbk_ids,=0A+static DEFINE_XENBUS_DRI=
VER(xen_blkbk, ,=0A 	.probe =3D xen_blkbk_probe,=0A 	.remove =3D =
xen_blkbk_remove,=0A 	.otherend_changed =3D frontend_changed=0A-};=0A+);=
=0A =0A =0A int xen_blkif_xenbus_init(void)=0A {=0A-	return xenbus_regis=
ter_backend(&xen_blkbk);=0A+	return xenbus_register_backend(&xen_blkbk_d=
river);=0A }=0A--- 3.2-rc6/drivers/block/xen-blkfront.c=0A+++ 3.2-rc6-struc=
t-xenbus_driver/drivers/block/xen-blkfront.c=0A@@ -1437,16 +1437,13 @@ =
static const struct xenbus_device_id blk=0A 	{ "" }=0A };=0A =0A-static =
struct xenbus_driver blkfront =3D {=0A-	.name =3D "vbd",=0A-	.owner =3D =
THIS_MODULE,=0A-	.ids =3D blkfront_ids,=0A+static DEFINE_XENBUS_DRIV=
ER(blkfront, ,=0A 	.probe =3D blkfront_probe,=0A 	.remove =3D =
blkfront_remove,=0A 	.resume =3D blkfront_resume,=0A 	.otherend_c=
hanged =3D blkback_changed,=0A 	.is_ready =3D blkfront_is_ready,=0A-};=0A+)=
;=0A =0A static int __init xlblk_init(void)=0A {=0A@@ -1461,7 +1458,7 @@ =
static int __init xlblk_init(void)=0A 		return -ENODEV;=0A 	=
}=0A =0A-	ret =3D xenbus_register_frontend(&blkfront);=0A+	=
ret =3D xenbus_register_frontend(&blkfront_driver);=0A 	if (ret) {=0A 		=
unregister_blkdev(XENVBD_MAJOR, DEV_NAME);=0A 		return ret;=0A@@ =
-1474,7 +1471,7 @@ module_init(xlblk_init);=0A =0A static void __exit =
xlblk_exit(void)=0A {=0A-	return xenbus_unregister_driver(&blkfront);=
=0A+	return xenbus_unregister_driver(&blkfront_driver);=0A }=0A =
module_exit(xlblk_exit);=0A =0A--- 3.2-rc6/drivers/input/misc/xen-kbdfront.=
c=0A+++ 3.2-rc6-struct-xenbus_driver/drivers/input/misc/xen-kbdfront.c=0A@@=
 -361,15 +361,12 @@ static const struct xenbus_device_id xen=0A 	{ =
"" }=0A };=0A =0A-static struct xenbus_driver xenkbd_driver =3D {=0A-	=
.name =3D "vkbd",=0A-	.owner =3D THIS_MODULE,=0A-	.ids =3D xenkbd_ids=
,=0A+static DEFINE_XENBUS_DRIVER(xenkbd, ,=0A 	.probe =3D xenkbd_probe,=0A=
 	.remove =3D xenkbd_remove,=0A 	.resume =3D xenkbd_resume,=0A 	=
.otherend_changed =3D xenkbd_backend_changed,=0A-};=0A+);=0A =0A static =
int __init xenkbd_init(void)=0A {=0A--- 3.2-rc6/drivers/net/xen-netback/xen=
bus.c=0A+++ 3.2-rc6-struct-xenbus_driver/drivers/net/xen-netback/xenbus.c=
=0A@@ -474,17 +474,14 @@ static const struct xenbus_device_id net=0A };=0A =
=0A =0A-static struct xenbus_driver netback =3D {=0A-	.name =3D =
"vif",=0A-	.owner =3D THIS_MODULE,=0A-	.ids =3D netback_ids,=0A+st=
atic DEFINE_XENBUS_DRIVER(netback, ,=0A 	.probe =3D netback_probe,=
=0A 	.remove =3D netback_remove,=0A 	.uevent =3D netback_uevent,=0A 	=
.otherend_changed =3D frontend_changed,=0A-};=0A+);=0A =0A int xenvif_xenbu=
s_init(void)=0A {=0A-	return xenbus_register_backend(&netback);=0A+	=
return xenbus_register_backend(&netback_driver);=0A }=0A--- 3.2-rc6/drivers=
/net/xen-netfront.c=0A+++ 3.2-rc6-struct-xenbus_driver/drivers/net/xen-netf=
ront.c=0A@@ -1910,7 +1910,7 @@ static void xennet_sysfs_delif(struct ne=0A =
=0A #endif /* CONFIG_SYSFS */=0A =0A-static struct xenbus_device_id =
netfront_ids[] =3D {=0A+static const struct xenbus_device_id netfront_ids[]=
 =3D {=0A 	{ "vif" },=0A 	{ "" }=0A };=0A@@ -1937,15 +1937,12 @@ =
static int __devexit xennet_remove(struc=0A 	return 0;=0A }=0A =
=0A-static struct xenbus_driver netfront_driver =3D {=0A-	.name =3D =
"vif",=0A-	.owner =3D THIS_MODULE,=0A-	.ids =3D netfront_ids,=0A+s=
tatic DEFINE_XENBUS_DRIVER(netfront, ,=0A 	.probe =3D netfront_probe,=
=0A 	.remove =3D __devexit_p(xennet_remove),=0A 	.resume =3D =
netfront_resume,=0A 	.otherend_changed =3D netback_changed,=0A-};=0A+);=
=0A =0A static int __init netif_init(void)=0A {=0A--- 3.2-rc6/drivers/pci/x=
en-pcifront.c=0A+++ 3.2-rc6-struct-xenbus_driver/drivers/pci/xen-pcifront.c=
=0A@@ -1126,14 +1126,11 @@ static const struct xenbus_device_id xen=0A 	=
{""},=0A };=0A =0A-static struct xenbus_driver xenbus_pcifront_driver =3D =
{=0A-	.name			=3D "pcifront",=0A-	.owner			=
=3D THIS_MODULE,=0A-	.ids			=3D xenpci_ids,=0A+static =
DEFINE_XENBUS_DRIVER(xenpci, "pcifront",=0A 	.probe			=
=3D pcifront_xenbus_probe,=0A 	.remove			=3D pcifront_xenbus=
_remove,=0A 	.otherend_changed	=3D pcifront_backend_changed,=0A-};=
=0A+);=0A =0A static int __init pcifront_init(void)=0A {=0A@@ -1142,12 =
+1139,12 @@ static int __init pcifront_init(void)=0A =0A 	pci_fronten=
d_registrar(1 /* enable */);=0A =0A-	return xenbus_register_frontend(&xe=
nbus_pcifront_driver);=0A+	return xenbus_register_frontend(&xenpci_dri=
ver);=0A }=0A =0A static void __exit pcifront_cleanup(void)=0A {=0A-	=
xenbus_unregister_driver(&xenbus_pcifront_driver);=0A+	xenbus_unregister_d=
river(&xenpci_driver);=0A 	pci_frontend_registrar(0 /* disable =
*/);=0A }=0A module_init(pcifront_init);=0A--- 3.2-rc6/drivers/video/xen-fb=
front.c=0A+++ 3.2-rc6-struct-xenbus_driver/drivers/video/xen-fbfront.c=0A@@=
 -671,20 +671,17 @@ InitWait:=0A 	}=0A }=0A =0A-static struct =
xenbus_device_id xenfb_ids[] =3D {=0A+static const struct xenbus_device_id =
xenfb_ids[] =3D {=0A 	{ "vfb" },=0A 	{ "" }=0A };=0A =0A-static struct =
xenbus_driver xenfb_driver =3D {=0A-	.name =3D "vfb",=0A-	.owner =3D =
THIS_MODULE,=0A-	.ids =3D xenfb_ids,=0A+static DEFINE_XENBUS_DRIVER(=
xenfb, ,=0A 	.probe =3D xenfb_probe,=0A 	.remove =3D xenfb_remove,=
=0A 	.resume =3D xenfb_resume,=0A 	.otherend_changed =3D xenfb_backend=
_changed,=0A-};=0A+);=0A =0A static int __init xenfb_init(void)=0A {=0A--- =
3.2-rc6/drivers/xen/xen-pciback/xenbus.c=0A+++ 3.2-rc6-struct-xenbus_driver=
/drivers/xen/xen-pciback/xenbus.c=0A@@ -707,19 +707,16 @@ static int =
xen_pcibk_xenbus_remove(struc=0A 	return 0;=0A }=0A =0A-static const =
struct xenbus_device_id xenpci_ids[] =3D {=0A+static const struct =
xenbus_device_id xen_pcibk_ids[] =3D {=0A 	{"pci"},=0A 	{""},=0A =
};=0A =0A-static struct xenbus_driver xenbus_xen_pcibk_driver =3D {=0A-	=
.name			=3D DRV_NAME,=0A-	.owner			=
=3D THIS_MODULE,=0A-	.ids			=3D xenpci_ids,=0A+static =
DEFINE_XENBUS_DRIVER(xen_pcibk, DRV_NAME,=0A 	.probe			=
=3D xen_pcibk_xenbus_probe,=0A 	.remove			=3D xen_pcibk_xenbu=
s_remove,=0A 	.otherend_changed	=3D xen_pcibk_frontend_changed,=0A-=
};=0A+);=0A =0A const struct xen_pcibk_backend *__read_mostly xen_pcibk_bac=
kend;=0A =0A@@ -735,11 +732,11 @@ int __init xen_pcibk_xenbus_register(voi=
=0A 	if (passthrough)=0A 		xen_pcibk_backend =3D &xen_pcibk_pa=
ssthrough_backend;=0A 	pr_info(DRV_NAME ": backend is %s\n", xen_pcibk_bac=
kend->name);=0A-	return xenbus_register_backend(&xenbus_xen_pcibk_dr=
iver);=0A+	return xenbus_register_backend(&xen_pcibk_driver);=0A }=0A =
=0A void __exit xen_pcibk_xenbus_unregister(void)=0A {=0A 	destroy_wor=
kqueue(xen_pcibk_wq);=0A-	xenbus_unregister_driver(&xenbus_xen_pcibk_=
driver);=0A+	xenbus_unregister_driver(&xen_pcibk_driver);=0A }=0A--- =
3.2-rc6/drivers/xen/xenbus/xenbus_probe.c=0A+++ 3.2-rc6-struct-xenbus_drive=
r/drivers/xen/xenbus/xenbus_probe.c=0A@@ -291,14 +291,9 @@ void xenbus_dev_=
shutdown(struct device *=0A EXPORT_SYMBOL_GPL(xenbus_dev_shutdown);=0A =0A =
int xenbus_register_driver_common(struct xenbus_driver *drv,=0A-		=
		  struct xen_bus_type *bus,=0A-				  =
struct module *owner,=0A-				  const char =
*mod_name)=0A+				  struct xen_bus_type *bus)=0A =
{=0A-	drv->driver.name =3D drv->name;=0A 	drv->driver.bus =3D =
&bus->bus;=0A-	drv->driver.owner =3D owner;=0A-	drv->driver.mod_nam=
e =3D mod_name;=0A =0A 	return driver_register(&drv->driver);=0A }=0A--- =
3.2-rc6/drivers/xen/xenbus/xenbus_probe.h=0A+++ 3.2-rc6-struct-xenbus_drive=
r/drivers/xen/xenbus/xenbus_probe.h=0A@@ -53,9 +53,7 @@ extern int =
xenbus_match(struct device *_=0A extern int xenbus_dev_probe(struct device =
*_dev);=0A extern int xenbus_dev_remove(struct device *_dev);=0A extern =
int xenbus_register_driver_common(struct xenbus_driver *drv,=0A-		=
			 struct xen_bus_type *bus,=0A-				=
	 struct module *owner,=0A-					 =
const char *mod_name);=0A+					 struct =
xen_bus_type *bus);=0A extern int xenbus_probe_node(struct xen_bus_type =
*bus,=0A 			     const char *type,=0A 			=
     const char *nodename);=0A--- 3.2-rc6/drivers/xen/xenbus/xenbus_probe_b=
ackend.c=0A+++ 3.2-rc6-struct-xenbus_driver/drivers/xen/xenbus/xenbus_probe=
_backend.c=0A@@ -232,15 +232,13 @@ int xenbus_dev_is_online(struct =
xenbus_d=0A }=0A EXPORT_SYMBOL_GPL(xenbus_dev_is_online);=0A =0A-int =
__xenbus_register_backend(struct xenbus_driver *drv,=0A-			=
      struct module *owner, const char *mod_name)=0A+int xenbus_register_ba=
ckend(struct xenbus_driver *drv)=0A {=0A 	drv->read_otherend_details =
=3D read_frontend_details;=0A =0A-	return xenbus_register_driver_commo=
n(drv, &xenbus_backend,=0A-					     =
owner, mod_name);=0A+	return xenbus_register_driver_common(drv, =
&xenbus_backend);=0A }=0A-EXPORT_SYMBOL_GPL(__xenbus_register_backend);=0A+=
EXPORT_SYMBOL_GPL(xenbus_register_backend);=0A =0A static int backend_probe=
_and_watch(struct notifier_block *notifier,=0A 				   =
unsigned long event,=0A--- 3.2-rc6/drivers/xen/xenbus/xenbus_probe_frontend=
.c=0A+++ 3.2-rc6-struct-xenbus_driver/drivers/xen/xenbus/xenbus_probe_front=
end.c=0A@@ -230,15 +230,13 @@ static void wait_for_devices(struct xenb=0A 	=
		 print_device_status);=0A }=0A =0A-int __xenbus_register_fr=
ontend(struct xenbus_driver *drv,=0A-			       struct =
module *owner, const char *mod_name)=0A+int xenbus_register_frontend(struct=
 xenbus_driver *drv)=0A {=0A 	int ret;=0A =0A 	drv->read_otherend_=
details =3D read_backend_details;=0A =0A-	ret =3D xenbus_register_dri=
ver_common(drv, &xenbus_frontend,=0A-					   =
 owner, mod_name);=0A+	ret =3D xenbus_register_driver_common(drv, =
&xenbus_frontend);=0A 	if (ret)=0A 		return ret;=0A =0A@@ =
-247,7 +245,7 @@ int __xenbus_register_frontend(struct xe=0A =0A 	=
return 0;=0A }=0A-EXPORT_SYMBOL_GPL(__xenbus_register_frontend);=0A+EXPORT_=
SYMBOL_GPL(xenbus_register_frontend);=0A =0A static DECLARE_WAIT_QUEUE_HEAD=
(backend_state_wq);=0A static int backend_state;=0A--- 3.2-rc6/include/xen/=
xenbus.h=0A+++ 3.2-rc6-struct-xenbus_driver/include/xen/xenbus.h=0A@@ =
-85,8 +85,6 @@ struct xenbus_device_id=0A =0A /* A xenbus driver. */=0A =
struct xenbus_driver {=0A-	char *name;=0A-	struct module *owner;=0A 	=
const struct xenbus_device_id *ids;=0A 	int (*probe)(struct xenbus_device =
*dev,=0A 		     const struct xenbus_device_id *id);=0A@@ =
-101,31 +99,20 @@ struct xenbus_driver {=0A 	int (*is_ready)(struct =
xenbus_device *dev);=0A };=0A =0A-static inline struct xenbus_driver =
*to_xenbus_driver(struct device_driver *drv)=0A-{=0A-	return container_of=
(drv, struct xenbus_driver, driver);=0A+#define DEFINE_XENBUS_DRIVER(var, =
drvname, methods...)		\=0A+struct xenbus_driver var ## _driver =
=3D {				\=0A+	.driver.name =3D drvname + 0 ?: =
var ## _ids->devicetype,	\=0A+	.driver.owner =3D THIS_MODULE,		=
		\=0A+	.ids =3D var ## _ids, ## methods			=
	\=0A }=0A =0A-int __must_check __xenbus_register_frontend(struct =
xenbus_driver *drv,=0A-					    struct module =
*owner,=0A-					    const char *mod_name);=
=0A-=0A-static inline int __must_check=0A-xenbus_register_frontend(struct =
xenbus_driver *drv)=0A+static inline struct xenbus_driver *to_xenbus_driver=
(struct device_driver *drv)=0A {=0A-	WARN_ON(drv->owner !=3D THIS_MODULE=
);=0A-	return __xenbus_register_frontend(drv, THIS_MODULE, KBUILD_MODNAME)=
;=0A+	return container_of(drv, struct xenbus_driver, driver);=0A }=0A =
=0A-int __must_check __xenbus_register_backend(struct xenbus_driver =
*drv,=0A-					   struct module *owner,=0A=
-					   const char *mod_name);=0A-static=
 inline int __must_check=0A-xenbus_register_backend(struct xenbus_driver =
*drv)=0A-{=0A-	WARN_ON(drv->owner !=3D THIS_MODULE);=0A-	return =
__xenbus_register_backend(drv, THIS_MODULE, KBUILD_MODNAME);=0A-}=0A+int =
__must_check xenbus_register_frontend(struct xenbus_driver *);=0A+int =
__must_check xenbus_register_backend(struct xenbus_driver *);=0A =0A void =
xenbus_unregister_driver(struct xenbus_driver *drv);=0A =0A
--=__Part4A65FB6D.7__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--=__Part4A65FB6D.7__=--


From xen-devel-bounces@lists.xensource.com Thu Dec 22 09:10:55 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 Dec 2011 09:10:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdefX-0002iO-Oj; Thu, 22 Dec 2011 09:10:31 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RdefV-0002i6-ND
	for xen-devel@lists.xensource.com; Thu, 22 Dec 2011 09:10:30 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1324544989!53428448!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Nzk5NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 959 invoked from network); 22 Dec 2011 09:09:49 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Dec 2011 09:09:49 -0000
X-IronPort-AV: E=Sophos;i="4.71,392,1320624000"; 
   d="scan'208";a="9625746"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Dec 2011 09:10:25 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 22 Dec 2011 09:10:25 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RdefR-0000bU-42;
	Thu, 22 Dec 2011 09:10:25 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RdefQ-0006LC-PG;
	Thu, 22 Dec 2011 09:10:24 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10589-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 22 Dec 2011 09:10:24 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux test] 10589: FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10589 linux real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10589/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,including tests which could not be run:
 build-amd64-pvops             1 hosts-allocate               broken   in 10565

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-credit2   16 guest-start.2               fail pass in 10570
 test-amd64-i386-rhel6hvm-intel  7 redhat-install            fail pass in 10570
 test-amd64-i386-pv           16 guest-start.2               fail pass in 10581
 test-amd64-amd64-pv          16 guest-start.2               fail pass in 10581
 test-i386-i386-pv            16 guest-start.2               fail pass in 10570
 test-i386-i386-xl            16 guest-start.2               fail pass in 10570
 test-amd64-i386-xl-multivcpu 16 guest-start.2               fail pass in 10565
 test-amd64-i386-xl           16 guest-start.2               fail pass in 10570
 test-amd64-amd64-xl          16 guest-start.2               fail pass in 10570
 test-amd64-i386-rhel6hvm-amd  7 redhat-install              fail pass in 10570
 test-i386-i386-xl-win         7 windows-install             fail pass in 10581
 test-amd64-amd64-win          7 windows-install             fail pass in 10581
 test-amd64-i386-win           7 windows-install    fail in 10570 pass in 10589
 test-amd64-amd64-xl-win       7 windows-install    fail in 10570 pass in 10589
 test-amd64-i386-xl-win-vcpus1  7 windows-install   fail in 10565 pass in 10589
 test-amd64-i386-win-vcpus1    7 windows-install    fail in 10565 pass in 10589
 test-amd64-amd64-xl-sedf     16 guest-start.2      fail in 10581 pass in 10570

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail    like 9095
 test-amd64-amd64-xl-sedf-pin 16 guest-start.2             fail blocked in 9095
 test-amd64-i386-xl-win7-amd64  7 windows-install          fail blocked in 9095
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install     fail blocked in 9095
 test-amd64-amd64-xl-win7-amd64  7 windows-install              fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-i386-i386-xl-winxpsp3    7 windows-install           fail blocked in 9095
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2       fail in 10570 never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2         fail in 10570 never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop           fail in 10570 never pass
 test-i386-i386-xl-win        13 guest-stop            fail in 10570 never pass
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)     blocked in 10565 n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)        blocked in 10565 n/a
 test-amd64-amd64-pair         1 xen-build-check(1)        blocked in 10565 n/a
 test-amd64-amd64-pv           1 xen-build-check(1)        blocked in 10565 n/a
 test-amd64-amd64-xl           1 xen-build-check(1)        blocked in 10565 n/a
 test-amd64-amd64-xl-sedf-pin  1 xen-build-check(1)        blocked in 10565 n/a
 test-amd64-amd64-xl-winxpsp3  1 xen-build-check(1)        blocked in 10565 n/a
 build-amd64-pvops             2 logs-capture(2)     broken in 10565 never pass
 test-amd64-i386-xend-winxpsp3  7 windows-install fail in 10565 blocked in 9095
 test-amd64-amd64-xl-win       1 xen-build-check(1)        blocked in 10565 n/a
 test-amd64-amd64-win          1 xen-build-check(1)        blocked in 10565 n/a
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop      fail in 10565 never pass
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)      blocked in 10565 n/a
 test-i386-i386-xl-winxpsp3   13 guest-stop            fail in 10565 never pass
 test-amd64-amd64-xl-winxpsp3  7 windows-install  fail in 10581 blocked in 9095
 test-amd64-amd64-win         16 leak-check/check      fail in 10581 never pass

version targeted for testing:
 linux                59b1ffe039ce366305d48176b7fccce29ce729d3
baseline version:
 linux                6bec8b4a4c14095d0b7ce424db9d583c3decae6c

------------------------------------------------------------
People who touched revisions under test:
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          fail    
 test-amd64-i386-xl                                           fail    
 test-i386-i386-xl                                            fail    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          fail    
 test-amd64-i386-pv                                           fail    
 test-i386-i386-pv                                            fail    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
commit 59b1ffe039ce366305d48176b7fccce29ce729d3
Merge: cacd265... 60b1e4f...
Author: Jeremy Fitzhardinge <jeremy@goop.org>
Date:   Sat Dec 10 00:20:33 2011 -0800

    Merge commit 'v2.6.32.50' into xen/next-2.6.32
    
    * commit 'v2.6.32.50': (28 commits)
      Linux 2.6.32.50
      clockevents: Set noop handler in clockevents_exchange_device()
      tick-broadcast: Stop active broadcast device when replacing it
      genirq: Fix race condition when stopping the irq thread
      oprofile, x86: Fix crash when unloading module (nmi timer mode)
      x86/mpparse: Account for bus types other than ISA and PCI
      sched, x86: Avoid unnecessary overflow in sched_clock
      cifs: fix cifs stable patch cifs-fix-oplock-break-handling-try-2.patch
      SCSI: Silencing 'killing requests for dead queue'
      SCSI: scsi_lib: fix potential NULL dereference
      USB: usb-storage: unusual_devs entry for Kingston DT 101 G2
      usb: option: add SIMCom SIM5218
      usb: ftdi_sio: add PID for Propox ISPcable III
      USB: whci-hcd: fix endian conversion in qset_clear()
      Staging: comedi: fix signal handling in read and write
      staging: comedi: fix oops for USB DAQ devices.
      staging: usbip: bugfix for deadlock
      gro: reset vlan_tci on reuse
      nl80211: fix MAC address validation
      p54spi: Fix workqueue deadlock
      ...

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 22 09:10:55 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 Dec 2011 09:10:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdefX-0002iO-Oj; Thu, 22 Dec 2011 09:10:31 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RdefV-0002i6-ND
	for xen-devel@lists.xensource.com; Thu, 22 Dec 2011 09:10:30 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1324544989!53428448!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Nzk5NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 959 invoked from network); 22 Dec 2011 09:09:49 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Dec 2011 09:09:49 -0000
X-IronPort-AV: E=Sophos;i="4.71,392,1320624000"; 
   d="scan'208";a="9625746"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Dec 2011 09:10:25 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 22 Dec 2011 09:10:25 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RdefR-0000bU-42;
	Thu, 22 Dec 2011 09:10:25 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RdefQ-0006LC-PG;
	Thu, 22 Dec 2011 09:10:24 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10589-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 22 Dec 2011 09:10:24 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux test] 10589: FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10589 linux real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10589/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,including tests which could not be run:
 build-amd64-pvops             1 hosts-allocate               broken   in 10565

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-credit2   16 guest-start.2               fail pass in 10570
 test-amd64-i386-rhel6hvm-intel  7 redhat-install            fail pass in 10570
 test-amd64-i386-pv           16 guest-start.2               fail pass in 10581
 test-amd64-amd64-pv          16 guest-start.2               fail pass in 10581
 test-i386-i386-pv            16 guest-start.2               fail pass in 10570
 test-i386-i386-xl            16 guest-start.2               fail pass in 10570
 test-amd64-i386-xl-multivcpu 16 guest-start.2               fail pass in 10565
 test-amd64-i386-xl           16 guest-start.2               fail pass in 10570
 test-amd64-amd64-xl          16 guest-start.2               fail pass in 10570
 test-amd64-i386-rhel6hvm-amd  7 redhat-install              fail pass in 10570
 test-i386-i386-xl-win         7 windows-install             fail pass in 10581
 test-amd64-amd64-win          7 windows-install             fail pass in 10581
 test-amd64-i386-win           7 windows-install    fail in 10570 pass in 10589
 test-amd64-amd64-xl-win       7 windows-install    fail in 10570 pass in 10589
 test-amd64-i386-xl-win-vcpus1  7 windows-install   fail in 10565 pass in 10589
 test-amd64-i386-win-vcpus1    7 windows-install    fail in 10565 pass in 10589
 test-amd64-amd64-xl-sedf     16 guest-start.2      fail in 10581 pass in 10570

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail    like 9095
 test-amd64-amd64-xl-sedf-pin 16 guest-start.2             fail blocked in 9095
 test-amd64-i386-xl-win7-amd64  7 windows-install          fail blocked in 9095
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install     fail blocked in 9095
 test-amd64-amd64-xl-win7-amd64  7 windows-install              fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-i386-i386-xl-winxpsp3    7 windows-install           fail blocked in 9095
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2       fail in 10570 never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2         fail in 10570 never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop           fail in 10570 never pass
 test-i386-i386-xl-win        13 guest-stop            fail in 10570 never pass
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)     blocked in 10565 n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)        blocked in 10565 n/a
 test-amd64-amd64-pair         1 xen-build-check(1)        blocked in 10565 n/a
 test-amd64-amd64-pv           1 xen-build-check(1)        blocked in 10565 n/a
 test-amd64-amd64-xl           1 xen-build-check(1)        blocked in 10565 n/a
 test-amd64-amd64-xl-sedf-pin  1 xen-build-check(1)        blocked in 10565 n/a
 test-amd64-amd64-xl-winxpsp3  1 xen-build-check(1)        blocked in 10565 n/a
 build-amd64-pvops             2 logs-capture(2)     broken in 10565 never pass
 test-amd64-i386-xend-winxpsp3  7 windows-install fail in 10565 blocked in 9095
 test-amd64-amd64-xl-win       1 xen-build-check(1)        blocked in 10565 n/a
 test-amd64-amd64-win          1 xen-build-check(1)        blocked in 10565 n/a
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop      fail in 10565 never pass
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)      blocked in 10565 n/a
 test-i386-i386-xl-winxpsp3   13 guest-stop            fail in 10565 never pass
 test-amd64-amd64-xl-winxpsp3  7 windows-install  fail in 10581 blocked in 9095
 test-amd64-amd64-win         16 leak-check/check      fail in 10581 never pass

version targeted for testing:
 linux                59b1ffe039ce366305d48176b7fccce29ce729d3
baseline version:
 linux                6bec8b4a4c14095d0b7ce424db9d583c3decae6c

------------------------------------------------------------
People who touched revisions under test:
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          fail    
 test-amd64-i386-xl                                           fail    
 test-i386-i386-xl                                            fail    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          fail    
 test-amd64-i386-pv                                           fail    
 test-i386-i386-pv                                            fail    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
commit 59b1ffe039ce366305d48176b7fccce29ce729d3
Merge: cacd265... 60b1e4f...
Author: Jeremy Fitzhardinge <jeremy@goop.org>
Date:   Sat Dec 10 00:20:33 2011 -0800

    Merge commit 'v2.6.32.50' into xen/next-2.6.32
    
    * commit 'v2.6.32.50': (28 commits)
      Linux 2.6.32.50
      clockevents: Set noop handler in clockevents_exchange_device()
      tick-broadcast: Stop active broadcast device when replacing it
      genirq: Fix race condition when stopping the irq thread
      oprofile, x86: Fix crash when unloading module (nmi timer mode)
      x86/mpparse: Account for bus types other than ISA and PCI
      sched, x86: Avoid unnecessary overflow in sched_clock
      cifs: fix cifs stable patch cifs-fix-oplock-break-handling-try-2.patch
      SCSI: Silencing 'killing requests for dead queue'
      SCSI: scsi_lib: fix potential NULL dereference
      USB: usb-storage: unusual_devs entry for Kingston DT 101 G2
      usb: option: add SIMCom SIM5218
      usb: ftdi_sio: add PID for Propox ISPcable III
      USB: whci-hcd: fix endian conversion in qset_clear()
      Staging: comedi: fix signal handling in read and write
      staging: comedi: fix oops for USB DAQ devices.
      staging: usbip: bugfix for deadlock
      gro: reset vlan_tci on reuse
      nl80211: fix MAC address validation
      p54spi: Fix workqueue deadlock
      ...

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 22 09:32:43 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 Dec 2011 09: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.xensource.com>)
	id 1Rdf0T-00036c-T6; Thu, 22 Dec 2011 09:32:09 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Rdf0S-00036X-LR
	for xen-devel@lists.xensource.com; Thu, 22 Dec 2011 09:32:08 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1324546322!8349366!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23342 invoked from network); 22 Dec 2011 09:32:02 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-11.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 22 Dec 2011 09:32:02 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 22 Dec 2011 09:31:57 +0000
Message-Id: <4EF307540200007800069894@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 22 Dec 2011 09:32:52 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Florian Manschwetus" <florianmanschwetus@gmx.de>
References: <4EF06B14.4070106@gmx.de> <4EF0B034.1090708@gmx.de>
	<4EF270A7.2010705@gmx.de>
In-Reply-To: <4EF270A7.2010705@gmx.de>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [Xen-users] Problem booting xen 4.1.2 on Athlon 64
 X2
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 22.12.11 at 00:49, Florian Manschwetus <florianmanschwetus@gmx.de> wrote:
> Sending to devel, maybe a BUG?

Unlikely, perhaps rather the lack of a necessary command line option
("acpi_skip_timer_override"). If you don't need this option when booting
Linux on that system, you can verify this by looking at whether the
native kernel logs a respective message and/or one saying
"BIOS IRQ0 pin2 override ignored".

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 22 09:32:43 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 Dec 2011 09: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.xensource.com>)
	id 1Rdf0T-00036c-T6; Thu, 22 Dec 2011 09:32:09 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Rdf0S-00036X-LR
	for xen-devel@lists.xensource.com; Thu, 22 Dec 2011 09:32:08 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1324546322!8349366!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23342 invoked from network); 22 Dec 2011 09:32:02 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-11.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 22 Dec 2011 09:32:02 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 22 Dec 2011 09:31:57 +0000
Message-Id: <4EF307540200007800069894@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 22 Dec 2011 09:32:52 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Florian Manschwetus" <florianmanschwetus@gmx.de>
References: <4EF06B14.4070106@gmx.de> <4EF0B034.1090708@gmx.de>
	<4EF270A7.2010705@gmx.de>
In-Reply-To: <4EF270A7.2010705@gmx.de>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [Xen-users] Problem booting xen 4.1.2 on Athlon 64
 X2
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 22.12.11 at 00:49, Florian Manschwetus <florianmanschwetus@gmx.de> wrote:
> Sending to devel, maybe a BUG?

Unlikely, perhaps rather the lack of a necessary command line option
("acpi_skip_timer_override"). If you don't need this option when booting
Linux on that system, you can verify this by looking at whether the
native kernel logs a respective message and/or one saying
"BIOS IRQ0 pin2 override ignored".

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 22 09:48:28 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 Dec 2011 09:48:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdfFt-0003HV-JZ; Thu, 22 Dec 2011 09:48:05 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jean.guyader@gmail.com>) id 1RdfFs-0003HE-Sx
	for xen-devel@lists.xensource.com; Thu, 22 Dec 2011 09:48:05 +0000
X-Env-Sender: jean.guyader@gmail.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1324547277!6515290!1
X-Originating-IP: [209.85.220.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21278 invoked from network); 22 Dec 2011 09:47:58 -0000
Received: from mail-vx0-f171.google.com (HELO mail-vx0-f171.google.com)
	(209.85.220.171)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Dec 2011 09:47:58 -0000
Received: by vcbfl11 with SMTP id fl11so24393679vcb.30
	for <xen-devel@lists.xensource.com>;
	Thu, 22 Dec 2011 01:47:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type:content-transfer-encoding;
	bh=99oKuh0UJuIJZwQIEElh8Tu8GdpJUdS/cTtjtJz2MXA=;
	b=JpHaRIqRa0kGgSDWBVX8ezTLap1sUqLQsEj+QBIglr8UMuDE/LyZRnnNdvzYnI1ptE
	eh0+4w2gsnzO4pEwBMi0J22UzVPFPvFTltLQvPS9a7+MWhkCoLUL4WExTxycEBRKfTwd
	cB+aPqpKVBXpmmskCouU9XCVt9cRv/P+dI2OE=
Received: by 10.220.231.136 with SMTP id jq8mr6633525vcb.18.1324547277214;
	Thu, 22 Dec 2011 01:47:57 -0800 (PST)
MIME-Version: 1.0
Received: by 10.220.156.138 with HTTP; Thu, 22 Dec 2011 01:47:36 -0800 (PST)
In-Reply-To: <CAPLaKK4boeR9WyX_KOSVwCw7ZwJQwvoqCNPLsCDxPTF3hmPwuw@mail.gmail.com>
References: <patchbomb.1324347544@alpine.localdomain>
	<14e911353a91702b439b.1324347547@alpine.localdomain>
	<CA+T2pCGZPhLJ1Be28zuYreQcrVNPKvgd9z2HOq2E8CdnYC+a8A@mail.gmail.com>
	<CAEBdQ92w=HkomuqXKdTukPjGrGeJNDmrcXUUMWEMYeRqBwU5vA@mail.gmail.com>
	<CAPLaKK4boeR9WyX_KOSVwCw7ZwJQwvoqCNPLsCDxPTF3hmPwuw@mail.gmail.com>
From: Jean Guyader <jean.guyader@gmail.com>
Date: Thu, 22 Dec 2011 10:47:36 +0100
Message-ID: <CAEBdQ907W471ghxWmUB4vr0BE2cuzJmWzXpC6oA0G5s+iWuqZw@mail.gmail.com>
To: =?ISO-8859-1?Q?Roger_Pau_Monn=E9?= <roger.pau@entel.upc.edu>
Cc: William Pitcock <nenolod@dereferenced.org>, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 3 of 4 v2] build: detect is libiconv is
	present
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 21 December 2011 15:56, Roger Pau Monn=E9 <roger.pau@entel.upc.edu> wrot=
e:
> 2011/12/21 Jean Guyader <jean.guyader@gmail.com>:
>> That doesn't work if you do cross compilation, your libraries could
>> located in a completely different path.
>>
>> The best way to check for the presence of a library (and this is how
>> the autotools do it) is to generate a very simple C program that uses
>> some iconv functions and try to compile it with the currently
>> configured compiler. If the compilation succeeded that means the
>> library is present.
>
> I'm not sure this is easy to implement without much fuss, given the
> way Xen checks for configuration options. What about this:
>
> CONFIG_LIBICONV =A0 :=3D $(shell export OS=3D"`uname -s`"; \
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 export CHECK_LIB=3D"$(CHECK_L=
IB)"; \
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 . $(XEN_ROOT)/tools/check/fun=
cs.sh; \
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 has_lib libiconv.so && echo '=
y' || echo 'n')

I think that does the right thing.

Jean

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 22 09:48:28 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 Dec 2011 09:48:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdfFt-0003HV-JZ; Thu, 22 Dec 2011 09:48:05 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jean.guyader@gmail.com>) id 1RdfFs-0003HE-Sx
	for xen-devel@lists.xensource.com; Thu, 22 Dec 2011 09:48:05 +0000
X-Env-Sender: jean.guyader@gmail.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1324547277!6515290!1
X-Originating-IP: [209.85.220.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21278 invoked from network); 22 Dec 2011 09:47:58 -0000
Received: from mail-vx0-f171.google.com (HELO mail-vx0-f171.google.com)
	(209.85.220.171)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Dec 2011 09:47:58 -0000
Received: by vcbfl11 with SMTP id fl11so24393679vcb.30
	for <xen-devel@lists.xensource.com>;
	Thu, 22 Dec 2011 01:47:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type:content-transfer-encoding;
	bh=99oKuh0UJuIJZwQIEElh8Tu8GdpJUdS/cTtjtJz2MXA=;
	b=JpHaRIqRa0kGgSDWBVX8ezTLap1sUqLQsEj+QBIglr8UMuDE/LyZRnnNdvzYnI1ptE
	eh0+4w2gsnzO4pEwBMi0J22UzVPFPvFTltLQvPS9a7+MWhkCoLUL4WExTxycEBRKfTwd
	cB+aPqpKVBXpmmskCouU9XCVt9cRv/P+dI2OE=
Received: by 10.220.231.136 with SMTP id jq8mr6633525vcb.18.1324547277214;
	Thu, 22 Dec 2011 01:47:57 -0800 (PST)
MIME-Version: 1.0
Received: by 10.220.156.138 with HTTP; Thu, 22 Dec 2011 01:47:36 -0800 (PST)
In-Reply-To: <CAPLaKK4boeR9WyX_KOSVwCw7ZwJQwvoqCNPLsCDxPTF3hmPwuw@mail.gmail.com>
References: <patchbomb.1324347544@alpine.localdomain>
	<14e911353a91702b439b.1324347547@alpine.localdomain>
	<CA+T2pCGZPhLJ1Be28zuYreQcrVNPKvgd9z2HOq2E8CdnYC+a8A@mail.gmail.com>
	<CAEBdQ92w=HkomuqXKdTukPjGrGeJNDmrcXUUMWEMYeRqBwU5vA@mail.gmail.com>
	<CAPLaKK4boeR9WyX_KOSVwCw7ZwJQwvoqCNPLsCDxPTF3hmPwuw@mail.gmail.com>
From: Jean Guyader <jean.guyader@gmail.com>
Date: Thu, 22 Dec 2011 10:47:36 +0100
Message-ID: <CAEBdQ907W471ghxWmUB4vr0BE2cuzJmWzXpC6oA0G5s+iWuqZw@mail.gmail.com>
To: =?ISO-8859-1?Q?Roger_Pau_Monn=E9?= <roger.pau@entel.upc.edu>
Cc: William Pitcock <nenolod@dereferenced.org>, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 3 of 4 v2] build: detect is libiconv is
	present
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 21 December 2011 15:56, Roger Pau Monn=E9 <roger.pau@entel.upc.edu> wrot=
e:
> 2011/12/21 Jean Guyader <jean.guyader@gmail.com>:
>> That doesn't work if you do cross compilation, your libraries could
>> located in a completely different path.
>>
>> The best way to check for the presence of a library (and this is how
>> the autotools do it) is to generate a very simple C program that uses
>> some iconv functions and try to compile it with the currently
>> configured compiler. If the compilation succeeded that means the
>> library is present.
>
> I'm not sure this is easy to implement without much fuss, given the
> way Xen checks for configuration options. What about this:
>
> CONFIG_LIBICONV =A0 :=3D $(shell export OS=3D"`uname -s`"; \
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 export CHECK_LIB=3D"$(CHECK_L=
IB)"; \
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 . $(XEN_ROOT)/tools/check/fun=
cs.sh; \
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 has_lib libiconv.so && echo '=
y' || echo 'n')

I think that does the right thing.

Jean

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 22 09:51:13 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 Dec 2011 09:51:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdfIV-0003RP-Sy; Thu, 22 Dec 2011 09:50:47 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <florianmanschwetus@gmx.de>) id 1RdfIT-0003R8-5S
	for xen-devel@lists.xensource.com; Thu, 22 Dec 2011 09:50:45 +0000
X-Env-Sender: florianmanschwetus@gmx.de
X-Msg-Ref: server-10.tower-27.messagelabs.com!1324547400!47798685!1
X-Originating-IP: [213.165.64.22]
X-SpamReason: No, hits=0.5 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMTMuMTY1LjY0LjIyID0+IDEwNTI0MQ==\n,sa_preprocessor: 
	QmFkIElQOiAyMTMuMTY1LjY0LjIyID0+IDEwNTI0MQ==\n,BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23161 invoked from network); 22 Dec 2011 09:50:00 -0000
Received: from mailout-de.gmx.net (HELO mailout-de.gmx.net) (213.165.64.22)
	by server-10.tower-27.messagelabs.com with SMTP;
	22 Dec 2011 09:50:00 -0000
Received: (qmail invoked by alias); 22 Dec 2011 09:50:40 -0000
Received: from dslb-088-069-059-020.pools.arcor-ip.net (EHLO [192.168.222.23])
	[88.69.59.20]
	by mail.gmx.net (mp008) with SMTP; 22 Dec 2011 10:50:40 +0100
X-Authenticated: #7518697
X-Provags-ID: V01U2FsdGVkX1+fbus0D5ifqp2gWuuQxZxk3i511641iooPsy1AEq
	6YI68OcUrSR6+D
Message-ID: <4EF2FD37.5030600@gmx.de>
Date: Thu, 22 Dec 2011 10:49:43 +0100
From: Florian Manschwetus <florianmanschwetus@gmx.de>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:8.0) Gecko/20111121 Thunderbird/8.0
MIME-Version: 1.0
To: xen-devel@lists.xensource.com
References: <4EF06B14.4070106@gmx.de> <4EF0B034.1090708@gmx.de>
	<4EF270A7.2010705@gmx.de>
	<4EF307540200007800069894@nat28.tlf.novell.com>
In-Reply-To: <4EF307540200007800069894@nat28.tlf.novell.com>
X-Y-GMX-Trusted: 0
Subject: Re: [Xen-devel] [Xen-users] Problem booting xen 4.1.2 on Athlon 64
 X2
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============5591654311481353553=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Dies ist eine kryptografisch unterzeichnete Nachricht im MIME-Format.

--===============5591654311481353553==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms000509080907080106070402"

Dies ist eine kryptografisch unterzeichnete Nachricht im MIME-Format.

--------------ms000509080907080106070402
Content-Type: multipart/mixed;
 boundary="------------030803080705040100080906"

This is a multi-part message in MIME format.
--------------030803080705040100080906
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: quoted-printable

Am 22.12.2011 10:32, schrieb Jan Beulich:
>>>> On 22.12.11 at 00:49, Florian Manschwetus<florianmanschwetus@gmx.de>=
  wrote:
>> Sending to devel, maybe a BUG?
>
> Unlikely, perhaps rather the lack of a necessary command line option
> ("acpi_skip_timer_override"). If you don't need this option when bootin=
g
> Linux on that system, you can verify this by looking at whether the
> native kernel logs a respective message and/or one saying
> "BIOS IRQ0 pin2 override ignored".
>
> Jan
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>
Ok, I think I got the output. But I see nothing really helpful in there. =

I have attached the boot-log, maybe it gives you the needed information.

Thx,
Florian

--------------030803080705040100080906
Content-Type: text/plain;
 name="kernel-boot"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
 filename="kernel-boot"

Loading Linux x86_64-3.1.5-gentoo ...
Loading initial ramdisk ...
[    0.000000] Initializing cgroup subsys cpuset
[    0.000000] Initializing cgroup subsys cpu
[    0.000000] Linux version 3.1.5-gentoo (root@turing.algo.informatik.tu=
-darmstadt.de) (gcc version 4.5.3 (Gentoo 4.5.3-r1 p1.0, pie-0.4.5) ) #2 =
SMP Tue Dec 20 16:08:28 CET 2011
[    0.000000] Command line: BOOT_IMAGE=3D/kernel-genkernel-x86_64-3.1.5-=
gentoo ro init=3D/linuxrc splash=3Dsilent,theme:sabayon vga=3D791 console=
=3Dtty1 domdadm resume=3Dswap:/dev/mapper/vg_turing-lv_swap real_resume=3D=
/dev/mapper/vg_turing-lv_swap dolvm root=3D/dev/mapper/vg_turing-lv_root =
docrypt console=3DttyS0,115200n8
[    0.000000] BIOS-provided physical RAM map:
[    0.000000]  BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
[    0.000000]  BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)=

[    0.000000]  BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved)=

[    0.000000]  BIOS-e820: 0000000000100000 - 00000000bffc0000 (usable)
[    0.000000]  BIOS-e820: 00000000bffc0000 - 00000000bffce000 (ACPI data=
)
[    0.000000]  BIOS-e820: 00000000bffce000 - 00000000bfff0000 (ACPI NVS)=

[    0.000000]  BIOS-e820: 00000000bfff0000 - 00000000c0000000 (reserved)=

[    0.000000]  BIOS-e820: 00000000fec00000 - 00000000fec01000 (reserved)=

[    0.000000]  BIOS-e820: 00000000fee00000 - 00000000fef00000 (reserved)=

[    0.000000]  BIOS-e820: 00000000ff780000 - 0000000100000000 (reserved)=

[    0.000000]  BIOS-e820: 0000000100000000 - 0000000140000000 (usable)
[    0.000000] NX (Execute Disable) protection: active
[    0.000000] DMI present.
[    0.000000] No AGP bridge found
[    0.000000] last_pfn =3D 0x140000 max_arch_pfn =3D 0x400000000
[    0.000000] x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600=
070106
[    0.000000] last_pfn =3D 0xbffc0 max_arch_pfn =3D 0x400000000
[    0.000000] found SMP MP-table at [ffff8800000ff780] ff780
[    0.000000] init_memory_mapping: 0000000000000000-00000000bffc0000
[    0.000000] init_memory_mapping: 0000000100000000-0000000140000000
[    0.000000] RAMDISK: 36b68000 - 375ac000
[    0.000000] ACPI: RSDP 00000000000fb840 00024 (v02 ACPIAM)
[    0.000000] ACPI: XSDT 00000000bffc0100 0004C (v01 A_M_I_ OEMXSDT  030=
00826 MSFT 00000097)
[    0.000000] ACPI: FACP 00000000bffc0290 000F4 (v03 A_M_I_ OEMFACP  030=
00826 MSFT 00000097)
[    0.000000] ACPI: DSDT 00000000bffc05c0 04E38 (v01  A0557 A0557000 000=
00000 INTL 20051117)
[    0.000000] ACPI: FACS 00000000bffce000 00040
[    0.000000] ACPI: APIC 00000000bffc0390 00070 (v01 A_M_I_ OEMAPIC  030=
00826 MSFT 00000097)
[    0.000000] ACPI: MCFG 00000000bffc0400 0003C (v01 A_M_I_ OEMMCFG  030=
00826 MSFT 00000097)
[    0.000000] ACPI: OEMB 00000000bffce040 00060 (v01 A_M_I_ AMI_OEM  030=
00826 MSFT 00000097)
[    0.000000] ACPI: HPET 00000000bffc5400 00038 (v01 A_M_I_ OEMHPET0 030=
00826 MSFT 00000097)
[    0.000000] Scanning NUMA topology in Northbridge 24
[    0.000000] No NUMA configuration found
[    0.000000] Faking a node at 0000000000000000-0000000140000000
[    0.000000] Initmem setup node 0 0000000000000000-0000000140000000
[    0.000000]   NODE_DATA [000000013fffb000 - 000000013fffffff]
[    0.000000] Zone PFN ranges:
[    0.000000]   DMA      0x00000010 -> 0x00001000
[    0.000000]   DMA32    0x00001000 -> 0x00100000
[    0.000000]   Normal   0x00100000 -> 0x00140000
[    0.000000] Movable zone start PFN for each node
[    0.000000] early_node_map[3] active PFN ranges
[    0.000000]     0: 0x00000010 -> 0x0000009f
[    0.000000]     0: 0x00000100 -> 0x000bffc0
[    0.000000]     0: 0x00100000 -> 0x00140000
[    0.000000] Detected use of extended apic ids on hypertransport bus
[    0.000000] ACPI: PM-Timer IO Port: 0x508
[    0.000000] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled)
[    0.000000] ACPI: IOAPIC (id[0x02] address[0xfec00000] gsi_base[0])
[    0.000000] IOAPIC[0]: apic_id 2, version 17, address 0xfec00000, GSI =
0-23
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 0 dfl dfl)
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level=
)
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 14 global_irq 14 high edg=
e)
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 15 global_irq 15 high edg=
e)
[    0.000000] Using ACPI (MADT) for SMP configuration information
[    0.000000] ACPI: HPET id: 0x10de8201 base: 0xfed00000
[    0.000000] SMP: Allowing 2 CPUs, 0 hotplug CPUs
[    0.000000] PM: Registered nosave memory: 000000000009f000 - 000000000=
00a0000
[    0.000000] PM: Registered nosave memory: 00000000000a0000 - 000000000=
00e0000
[    0.000000] PM: Registered nosave memory: 00000000000e0000 - 000000000=
0100000
[    0.000000] PM: Registered nosave memory: 00000000bffc0000 - 00000000b=
ffce000
[    0.000000] PM: Registered nosave memory: 00000000bffce000 - 00000000b=
fff0000
[    0.000000] PM: Registered nosave memory: 00000000bfff0000 - 00000000c=
0000000
[    0.000000] PM: Registered nosave memory: 00000000c0000000 - 00000000f=
ec00000
[    0.000000] PM: Registered nosave memory: 00000000fec00000 - 00000000f=
ec01000
[    0.000000] PM: Registered nosave memory: 00000000fec01000 - 00000000f=
ee00000
[    0.000000] PM: Registered nosave memory: 00000000fee00000 - 00000000f=
ef00000
[    0.000000] PM: Registered nosave memory: 00000000fef00000 - 00000000f=
f780000
[    0.000000] PM: Registered nosave memory: 00000000ff780000 - 000000010=
0000000
[    0.000000] Allocating PCI resources starting at c0000000 (gap: c00000=
00:3ec00000)
[    0.000000] Booting paravirtualized kernel on bare hardware
[    0.000000] setup_percpu: NR_CPUS:64 nr_cpumask_bits:64 nr_cpu_ids:2 n=
r_node_ids:1
[    0.000000] PERCPU: Embedded 26 pages/cpu @ffff88013fc00000 s74688 r81=
92 d23616 u1048576
[    0.000000] Built 1 zonelists in Node order, mobility grouping on.  To=
tal pages: 1027914
[    0.000000] Policy zone: Normal
[    0.000000] Kernel command line: BOOT_IMAGE=3D/kernel-genkernel-x86_64=
-3.1.5-gentoo ro init=3D/linuxrc splash=3Dsilent,theme:sabayon vga=3D791 =
console=3Dtty1 domdadm resume=3Dswap:/dev/mapper/vg_turing-lv_swap real_r=
esume=3D/dev/mapper/vg_turing-lv_swap dolvm root=3D/dev/mapper/vg_turing-=
lv_root docrypt console=3DttyS0,115200n8
[    0.000000] PID hash table entries: 4096 (order: 3, 32768 bytes)
[    0.000000] Checking aperture...
[    0.000000] No AGP bridge found
[    0.000000] Node 0: aperture @ b4000000 size 32 MB
[    0.000000] Aperture pointing to e820 RAM. Ignoring.
[    0.000000] Your BIOS doesn't leave a aperture memory hole
[    0.000000] Please enable the IOMMU option in the BIOS setup
[    0.000000] This costs you 64 MB of RAM
[    0.000000] Mapping aperture over 65536 KB of RAM @ b4000000
[    0.000000] PM: Registered nosave memory: 00000000b4000000 - 00000000b=
8000000
[    0.000000] Memory: 3972508k/5242880k available (7229k kernel code, 10=
49284k absent, 221088k reserved, 4408k data, 748k init)
[    0.000000] SLUB: Genslabs=3D15, HWalign=3D64, Order=3D0-3, MinObjects=
=3D0, CPUs=3D2, Nodes=3D1
[    0.000000] Hierarchical RCU implementation.
[    0.000000] NR_IRQS:4352 nr_irqs:512 16
[    0.000000] Extended CMOS year: 2000
[    0.000000] Console: colour dummy device 80x25
[    0.000000] console [tty1] enabled
[    0.000000] console [ttyS0] enabled
[    0.000000] allocated 33554432 bytes of page_cgroup
[    0.000000] please try 'cgroup_disable=3Dmemory' option if you don't w=
ant memory cgroups
[    0.000000] Fast TSC calibration using PIT
[    0.000000] Detected 2611.707 MHz processor.
[    0.000000] Marking TSC unstable due to TSCs unsynchronized
[    0.003999] Calibrating delay loop (skipped), value calculated using t=
imer frequency.. 5223.41 BogoMIPS (lpj=3D2611707)
[    0.005002] pid_max: default: 32768 minimum: 301
[    0.006028] Security Framework initialized
[    0.007005] AppArmor: AppArmor disabled by boot time parameter
[    0.008406] Dentry cache hash table entries: 524288 (order: 10, 419430=
4 bytes)
[    0.010954] Inode-cache hash table entries: 262144 (order: 9, 2097152 =
bytes)
[    0.012068] Mount-cache hash table entries: 256
[    0.013148] Initializing cgroup subsys debug
[    0.014003] Initializing cgroup subsys memory
[    0.015011] Initializing cgroup subsys devices
[    0.016002] Initializing cgroup subsys freezer
[    0.017002] Initializing cgroup subsys blkio
[    0.018009] Initializing cgroup subsys perf_event
[    0.019039] CPU: Physical Processor ID: 0
[    0.020001] CPU: Processor Core ID: 0
[    0.021002] mce: CPU supports 5 MCE banks
[    0.022009] using AMD E400 aware idle routine
[    0.025543] ACPI: Core revision 20110623
[    0.028998] ..TIMER: vector=3D0x30 apic1=3D0 pin1=3D0 apic2=3D-1 pin2=3D=
-1
[    0.029997] ..MP-BIOS bug: 8254 timer not connected to IO-APIC
[    0.029997] ...trying to set up timer (IRQ0) through the 8259A ...
[    0.029997] ..... (found apic 0 pin 0) ...
[    0.040381] ....... works.
[    0.040998] CPU0: AMD Athlon(tm) 64 X2 Dual Core Processor 5200+ stepp=
ing 03
[    0.044996] Performance Events: AMD PMU driver.
[    0.045999] ... version:                0
[    0.046997] ... bit width:              48
[    0.047997] ... generic registers:      4
[    0.048997] ... value mask:             0000ffffffffffff
[    0.049997] ... max period:             00007fffffffffff
[    0.050997] ... fixed-purpose events:   0
[    0.051997] ... event mask:             000000000000000f
[    0.053077] MCE: In-kernel MCE decoding enabled.
[    0.054069] Booting Node   0, Processors  #1 Ok.
[    0.127031] Brought up 2 CPUs
[    0.127990] Total of 2 processors activated (10446.80 BogoMIPS).
[    0.129469] devtmpfs: initialized
[    0.131709] PM: Registering ACPI NVS region at bffce000 (139264 bytes)=

[    0.138025] xor: automatically using best checksumming function: gener=
ic_sse
[    0.149948]    generic_sse:  8052.000 MB/sec
[    0.153986] xor: using function: generic_sse (8052.000 MB/sec)
[    0.160052] print_constraints: dummy:=20
[    0.164032] NET: Registered protocol family 16
[    0.168989] TOM: 00000000c0000000 aka 3072M
[    0.173005] TOM2: 0000000140000000 aka 5120M
[    0.177004] ACPI: bus type pci registered
[    0.181020] PCI: MMCONFIG for domain 0000 [bus 00-ff] at [mem 0xe00000=
00-0xefffffff] (base 0xe0000000)
[    0.191002] PCI: not using MMCONFIG
[    0.193981] PCI: Using configuration type 1 for base access
[    0.217136] bio: create slab <bio-0> at 0
[    0.234953] raid6: int64x1   2171 MB/s
[    0.254954] raid6: int64x2   2777 MB/s
[    0.274953] raid6: int64x4   2027 MB/s
[    0.294948] raid6: int64x8   1468 MB/s
[    0.314925] raid6: sse2x1    3664 MB/s
[    0.334930] raid6: sse2x2    4839 MB/s
[    0.354929] raid6: sse2x4    5023 MB/s
[    0.357956] raid6: using algorithm sse2x4 (5023 MB/s)
[    0.362983] ACPI: Added _OSI(Module Device)
[    0.368075] ACPI: Added _OSI(Processor Device)
[    0.371985] ACPI: Added _OSI(3.0 _SCP Extensions)
[    0.376973] ACPI: Added _OSI(Processor Aggregator Device)
[    0.385172] ACPI: Executed 1 blocks of module-level executable AML cod=
e
[    0.393578] ACPI: Interpreter enabled
[    0.396952] ACPI: (supports S0 S1 S3 S4 S5)
[    0.401514] ACPI: Using IOAPIC for interrupt routing
[    0.405967] PCI: MMCONFIG for domain 0000 [bus 00-ff] at [mem 0xe00000=
00-0xefffffff] (base 0xe0000000)
[    0.416987] PCI: MMCONFIG at [mem 0xe0000000-0xefffffff] reserved in A=
CPI motherboard resources
[    0.456060] ACPI: No dock devices found.
[    0.459963] HEST: Table not found.
[    0.463963] PCI: Using host bridge windows from ACPI; if necessary, us=
e "pci=3Dnocrs" and report a bug
[    0.472998] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff])
[    0.479039] pci_root PNP0A03:00: host bridge window [io  0x0000-0x0cf7=
]
[    0.485965] pci_root PNP0A03:00: host bridge window [io  0x0d00-0xffff=
]
[    0.491949] pci_root PNP0A03:00: host bridge window [mem 0x000a0000-0x=
000bffff]
[    0.499935] pci_root PNP0A03:00: host bridge window [mem 0x000d0000-0x=
000dffff]
[    0.506934] pci_root PNP0A03:00: host bridge window [mem 0xc0000000-0x=
ff77ffff]
[    0.515776] pci 0000:00:04.0: PCI bridge to [bus 01-01] (subtractive d=
ecode)
[    0.524938] pci 0000:00:09.0: PCI bridge to [bus 02-02]
[    0.529958] pci 0000:00:0b.0: PCI bridge to [bus 03-03]
[    0.534948] pci 0000:00:0c.0: PCI bridge to [bus 04-04]
[    0.540180]  pci0000:00: Requesting ACPI _OSC control (0x1d)
[    0.545929]  pci0000:00: ACPI _OSC request failed (AE_NOT_FOUND), retu=
rned control mask: 0x1d
[    0.554926] ACPI _OSC control for PCIe not granted, disabling ASPM
[    0.565157] ACPI: PCI Interrupt Link [LNKA] (IRQs 16 17 18 19) *0, dis=
abled.
[    0.573178] ACPI: PCI Interrupt Link [LNKB] (IRQs 16 17 18 19) *0, dis=
abled.
[    0.580180] ACPI: PCI Interrupt Link [LNKC] (IRQs 16 17 18 19) *0, dis=
abled.
[    0.587174] ACPI: PCI Interrupt Link [LNKD] (IRQs 16 17 18 19) *0, dis=
abled.
[    0.594983] ACPI: PCI Interrupt Link [LNEA] (IRQs 16 17 18 19) *0, dis=
abled.
[    0.602174] ACPI: PCI Interrupt Link [LNEB] (IRQs 16 17 18 19) *0, dis=
abled.
[    0.609172] ACPI: PCI Interrupt Link [LNEC] (IRQs 16 17 18 19) *0, dis=
abled.
[    0.616169] ACPI: PCI Interrupt Link [LNED] (IRQs 16 17 18 19) *11
[    0.623172] ACPI: PCI Interrupt Link [LUB0] (IRQs 20 21 22 23) *11
[    0.629534] ACPI: PCI Interrupt Link [LUB2] (IRQs 20 21 22 23) *10
[    0.635978] ACPI: PCI Interrupt Link [LMAC] (IRQs 20 21 22 23) *11
[    0.642165] ACPI: PCI Interrupt Link [LAZA] (IRQs 20 21 22 23) *11
[    0.648641] ACPI: PCI Interrupt Link [LACI] (IRQs 20 21 22 23) *0, dis=
abled.
[    0.655974] ACPI: PCI Interrupt Link [LMC9] (IRQs 20 21 22 23) *0, dis=
abled.
[    0.663164] ACPI: PCI Interrupt Link [LSMB] (IRQs 20 21 22 23) *10
[    0.669636] ACPI: PCI Interrupt Link [LPMU] (IRQs 20 21 22 23) *0, dis=
abled.
[    0.676971] ACPI: PCI Interrupt Link [LSA0] (IRQs 20 21 22 23) *15
[    0.683161] ACPI: PCI Interrupt Link [LSA1] (IRQs 20 21 22 23) *5
[    0.689555] ACPI: PCI Interrupt Link [LATA] (IRQs 20 21 22 23) *0, dis=
abled.
[    0.696931] vgaarb: device added: PCI:0000:02:00.0,decodes=3Dio+mem,ow=
ns=3Dio+mem,locks=3Dnone
[    0.704909] vgaarb: loaded
[    0.707902] vgaarb: bridge control possible 0000:02:00.0
[    0.712968] SCSI subsystem initialized
[    0.716940] usbcore: registered new interface driver usbfs
[    0.717932] usbcore: registered new interface driver hub
[    0.718915] usbcore: registered new device driver usb
[    0.724943] wmi: Mapper loaded
[    0.725931] PCI: Using ACPI for IRQ routing
[    0.733376] NetLabel: Initializing
[    0.733899] NetLabel:  domain hash size =3D 128
[    0.734898] NetLabel:  protocols =3D UNLABELED CIPSOv4
[    0.735908] NetLabel:  unlabeled traffic allowed by default
[    0.736926] HPET: 3 timers in total, 0 timers will be used for per-cpu=
 timer
[    0.737912] hpet0: at MMIO 0xfed00000, IRQs 2, 8, 31
[    0.740087] hpet0: 3 comparators, 32-bit 25.000000 MHz counter
[    0.743925] Switching to clocksource hpet
[    0.745795] Switched to NOHz mode on CPU #0
[    0.745831] Switched to NOHz mode on CPU #1
[    0.758811] pnp: PnP ACPI init
[    0.761880] ACPI: bus type pnp registered
[    0.768493] pnp 00:07: disabling [io  0x0900-0x097f] because it overla=
ps 0000:00:01.0 BAR 0 [io  0x0900-0x09ff]
[    0.778577] pnp 00:07: disabling [io  0x0980-0x09ff] because it overla=
ps 0000:00:01.0 BAR 0 [io  0x0900-0x09ff]
[    0.789016] system 00:07: [io  0x04d0-0x04d1] has been reserved
[    0.794937] system 00:07: [io  0x0800-0x080f] has been reserved
[    0.800888] system 00:07: [io  0x0500-0x057f] has been reserved
[    0.806809] system 00:07: [io  0x0580-0x05ff] has been reserved
[    0.812747] system 00:07: [io  0x0800-0x087f] could not be reserved
[    0.819020] system 00:07: [io  0x0880-0x08ff] has been reserved
[    0.824940] system 00:07: [io  0x0d00-0x0d7f] has been reserved
[    0.830857] system 00:07: [io  0x0d80-0x0dff] has been reserved
[    0.836778] system 00:07: [io  0x2000-0x207f] has been reserved
[    0.842697] system 00:07: [io  0x2080-0x20ff] has been reserved
[    0.848685] system 00:07: [mem 0x000d0000-0x000d3fff window] has been =
reserved
[    0.855906] system 00:07: [mem 0x000d4000-0x000d7fff window] has been =
reserved
[    0.863124] system 00:07: [mem 0x000de000-0x000dffff window] has been =
reserved
[    0.870344] system 00:07: [mem 0xfefe0000-0xfefe01ff] has been reserve=
d
[    0.876955] system 00:07: [mem 0xfefe1000-0xfefe1fff] has been reserve=
d
[    0.883568] system 00:07: [mem 0xfee01000-0xfeefffff] has been reserve=
d
[    0.890182] system 00:07: [mem 0xffb80000-0xffffffff] has been reserve=
d
[    0.896794] system 00:07: [mem 0xff300000-0xff3fffff] has been reserve=
d
[    0.903682] system 00:09: [mem 0xfec00000-0xfec00fff] could not be res=
erved
[    0.910783] system 00:09: [mem 0xfee00000-0xfee00fff] has been reserve=
d
[    0.917734] system 00:0b: [io  0x0230-0x023f] has been reserved
[    0.923659] system 00:0b: [io  0x0290-0x029f] has been reserved
[    0.929579] system 00:0b: [io  0x0a00-0x0a0f] has been reserved
[    0.935502] system 00:0b: [io  0x0a10-0x0a1f] has been reserved
[    0.942144] system 00:0d: [mem 0xe0000000-0xefffffff] has been reserve=
d
[    0.948997] system 00:0e: [mem 0x00000000-0x0009ffff] could not be res=
erved
[    0.955963] system 00:0e: [mem 0x000c0000-0x000cffff] could not be res=
erved
[    0.962935] system 00:0e: [mem 0x000e0000-0x000fffff] could not be res=
erved
[    0.969897] system 00:0e: [mem 0x00100000-0xbfffffff] could not be res=
erved
[    0.976945] system 00:0e: [mem 0xff780000-0xffffffff] could not be res=
erved
[    0.984185] pnp: PnP ACPI: found 15 devices
[    0.988375] ACPI: ACPI bus type pnp unregistered
[    0.998454] pci 0000:00:04.0: PCI bridge to [bus 01-01]
[    1.003693] pci 0000:00:09.0: PCI bridge to [bus 02-02]
[    1.008923] pci 0000:00:09.0:   bridge window [io  0xe000-0xefff]
[    1.015019] pci 0000:00:09.0:   bridge window [mem 0xdc000000-0xdfffff=
ff]
[    1.021809] pci 0000:00:09.0:   bridge window [mem 0xc0000000-0xcfffff=
ff 64bit pref]
[    1.029568] pci 0000:00:0b.0: PCI bridge to [bus 03-03]
[    1.034795] pci 0000:00:0c.0: PCI bridge to [bus 04-04]
[    1.040256] NET: Registered protocol family 2
[    1.044747] IP route cache hash table entries: 131072 (order: 8, 10485=
76 bytes)
[    1.053461] TCP established hash table entries: 524288 (order: 11, 838=
8608 bytes)
[    1.064520] TCP bind hash table entries: 65536 (order: 8, 1048576 byte=
s)
[    1.071748] TCP: Hash tables configured (established 524288 bind 65536=
)
[    1.078363] TCP reno registered
[    1.081523] UDP hash table entries: 2048 (order: 4, 65536 bytes)
[    1.087577] UDP-Lite hash table entries: 2048 (order: 4, 65536 bytes)
[    1.094139] NET: Registered protocol family 1
[    1.673093] pci 0000:00:00.0: Found enabled HT MSI Mapping
[    1.678626] pci 0000:00:00.0: Found enabled HT MSI Mapping
[    1.684170] pci 0000:00:00.0: Found enabled HT MSI Mapping
[    1.689708] pci 0000:00:00.0: Found enabled HT MSI Mapping
[    1.695245] pci 0000:00:00.0: Found enabled HT MSI Mapping
[    1.700786] pci 0000:00:00.0: Found enabled HT MSI Mapping
[    1.706335] pci 0000:00:00.0: Found enabled HT MSI Mapping
[    1.711885] pci 0000:00:00.0: Found enabled HT MSI Mapping
[    1.717442] Trying to unpack rootfs image as initramfs...
[    1.871811] Freeing initrd memory: 10512k freed
[    1.883027] PCI-DMA: Disabling AGP.
[    1.886613] PCI-DMA: aperture base @ b4000000 size 65536 KB
[    1.892188] PCI-DMA: using GART IOMMU.
[    1.895940] PCI-DMA: Reserving 64MB of IOMMU area in the AGP aperture
[    1.907445] audit: initializing netlink socket (disabled)
[    1.912903] type=3D2000 audit(1324547036.911:1): initialized
[    1.933398] HugeTLB registered 2 MB page size, pre-allocated 0 pages
[    1.973772] VFS: Disk quotas dquot_6.5.2
[    1.977939] Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
[    1.984492] squashfs: version 4.0 (2009/01/31) Phillip Lougher
[    1.990915] ROMFS MTD (C) 2007 Red Hat, Inc.
[    1.995336] QNX4 filesystem 0.2.3 registered.
[    2.000588] Btrfs loaded
[    2.003134] msgmni has been set to 7908
[    2.007397] async_tx: api initialized (async)
[    2.011915] Block layer SCSI generic (bsg) driver version 0.4 loaded (=
major 253)
[    2.019349] io scheduler noop registered
[    2.023282] io scheduler deadline registered
[    2.027664] io scheduler cfq registered (default)
[    2.033318] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
=EF=BF=BD[    2.304133] serial8250: ttyS0 at I/O 0x3f8 (irq =3D 4) is a 1=
6550A
[    2.387672] 00:0c: ttyS0 at I/O 0x3f8 (irq =3D 4) is a 16550A
[    2.402444] Linux agpgart interface v0.103
[    2.406692] vesafb: mode is 1024x768x16, linelength=3D2048, pages=3D0
[    2.412787] vesafb: scrolling: redraw
[    2.416459] vesafb: Truecolor: size=3D0:5:6:5, shift=3D0:11:5:0
[    2.422191] vesafb: framebuffer at 0xdd000000, mapped to 0xffffc900111=
00000, using 1536k, total 1536k
[    2.435631] Console: switching to colour frame buffer device 128x48
[    2.446153] fb0: VESA VGA frame buffer device
[    2.456177] input: Power Button as /devices/LNXSYSTM:00/device:00/PNP0=
C0C:00/input/input0
[    2.464421] ACPI: Power Button [PWRB]
[    2.468194] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/in=
put/input1
[    2.475654] ACPI: Power Button [PWRF]
[    2.482017] ERST: Table is not found!
[    2.485730] GHES: HEST is not enabled!
[    2.489638] XENFS: not registering filesystem on non-xen platform
[    2.498035] brd: module loaded
[    2.502340] loop: module loaded
[    2.505544] Compaq SMART2 Driver (v 2.6.0)
[    2.509779] HP CISS Driver (v 3.6.26)
[    2.513888] MM: desc_per_page =3D 128
[    2.517673] Loading iSCSI transport class v2.0-870.
[    2.522596] fbcondecor: console 0 using theme 'sabayon'
[    2.530014] fnic: Cisco FCoE HBA Driver, ver 1.5.0.2
[    2.535365] Loading Adaptec I2O RAID: Version 2.4 Build 5go
[    2.541023] Detecting Adaptec I2O RAID controllers...
[    2.546340] Adaptec aacraid driver 1.1-7[28000]-ms
[    2.562908] fbcondecor: switched decor state to 'on' on console 0
[    2.570582] aic94xx: Adaptec aic94xx SAS/SATA driver version 1.0.3 loa=
ded
[    2.579043] isci: Intel(R) C600 SAS Controller Driver - version 1.0.0
[    2.587223] qla2xxx [0000:00:00.0]-0005: : QLogic Fibre Channel HBA Dr=
iver: 8.03.07.07-k.
[    2.597680] iscsi: registered transport (qla4xxx)
[    2.603962] QLogic iSCSI HBA Driver
[    2.608909] Emulex LightPulse Fibre Channel SCSI driver 8.3.25
[    2.616212] Copyright(c) 2004-2009 Emulex.  All rights reserved.
[    2.623989] DC390: clustering now enabled by default. If you get probl=
ems load
[    2.632758]        with "disable_clustering=3D1" and report to maintai=
ners
[    2.641154] megaraid cmm: 2.20.2.7 (Release Date: Sun Jul 16 00:01:03 =
EST 2006)
[    2.650120] megaraid: 2.20.5.1 (Release Date: Thu Nov 16 15:32:35 EST =
2006)
[    2.658711] megasas: 00.00.05.40-rc1 Tue. Jul. 26 17:00:00 PDT 2011
[    2.666605] mpt2sas version 09.100.00.00 loaded
[    2.672894] GDT-HA: Storage RAID Controller Driver. Version: 3.05
[    2.680711] 3ware Storage Controller device driver for Linux v1.26.02.=
003.
[    2.689234] 3ware 9000 Storage Controller device driver for Linux v2.2=
6.02.014.
[    2.698184] LSI 3ware SAS/SATA-RAID Controller device driver for Linux=
 v3.26.02.000.
[    2.707598] ipr: IBM Power RAID SCSI Device Driver version: 2.5.2 (Apr=
il 27, 2011)
[    2.716823] RocketRAID 3xxx/4xxx Controller driver v1.6 (090910)
[    2.724488] stex: Promise SuperTrak EX Driver version: 4.6.0000.4
[    2.732296] libcxgbi:libcxgbi_init_module: tag itt 0x1fff, 13 bits, ag=
e 0xf, 4 bits.
[    2.741616] libcxgbi:ddp_setup_host_page_size: system PAGE 4096, ddp i=
dx 0.
[    2.750128] Chelsio T3 iSCSI Driver cxgb3i v2.0.0 (Jun. 2010)
[    2.757506] iscsi: registered transport (cxgb3i)
[    2.763694] Chelsio T4 iSCSI Driver cxgb4i v0.9.1 (Aug. 2010)
[    2.771091] iscsi: registered transport (cxgb4i)
[    2.777285] Broadcom NetXtreme II iSCSI Driver bnx2i v2.7.0.3 (Jun 15,=
 2011)
[    2.785995] iscsi: registered transport (bnx2i)
[    2.792203] VMware PVSCSI driver - version 1.0.1.0-k
[    2.798865] st: Version 20101219, fixed bufsize 32768, s/g segs 256
[    2.806874] osst :I: Tape driver with OnStream support version 0.99.4
[    2.806875] osst :I: $Id: osst.c,v 1.73 2005/01/01 21:13:34 wriede Exp=
 $
[    2.824383] ACPI: PCI Interrupt Link [LSA0] enabled at IRQ 23
[    2.831832] sata_nv 0000:00:08.0: PCI INT A -> Link[LSA0] -> GSI 23 (l=
evel, low) -> IRQ 23
[    2.842347] scsi0 : sata_nv
[    2.847012] scsi1 : sata_nv
[    2.851689] ata1: SATA max UDMA/133 cmd 0xd400 ctl 0xd080 bmdma 0xc880=
 irq 23
[    2.860511] ata2: SATA max UDMA/133 cmd 0xd000 ctl 0xcc00 bmdma 0xc888=
 irq 23
[    2.869498] ACPI: PCI Interrupt Link [LSA1] enabled at IRQ 22
[    2.876971] sata_nv 0000:00:08.1: PCI INT B -> Link[LSA1] -> GSI 22 (l=
evel, low) -> IRQ 22
[    2.887543] scsi2 : sata_nv
[    2.892239] scsi3 : sata_nv
[    2.896962] ata3: SATA max UDMA/133 cmd 0xc800 ctl 0xc480 bmdma 0xc000=
 irq 22
[    2.905848] ata4: SATA max UDMA/133 cmd 0xc400 ctl 0xc080 bmdma 0xc008=
 irq 22
[    2.915861] scsi4 : pata_amd
[    2.920573] scsi5 : pata_amd
[    2.925602] ata5: PATA max UDMA/133 cmd 0x1f0 ctl 0x3f6 bmdma 0xffa0 i=
rq 14
[    2.934247] ata6: PATA max UDMA/133 cmd 0x170 ctl 0x376 bmdma 0xffa8 i=
rq 15
[    2.945422] Fixed MDIO Bus: probed
[    2.950710] cnic: Broadcom NetXtreme II CNIC Driver cnic v2.5.7 (July =
20, 2011)
[    2.959857] I2O subsystem v1.325
[    2.964718] i2o: max drivers =3D 8
[    2.969762] I2O Configuration OSM v1.323
[    2.975429] I2O Bus Adapter OSM v1.317
[    2.980809] I2O Block Device OSM v1.325
[    2.986398] I2O SCSI Peripheral OSM v1.316
[    2.992074] I2O ProcFS OSM v1.316
[    2.996939] Fusion MPT base driver 3.04.19
[    3.002520] Copyright (c) 1999-2008 LSI Corporation
[    3.008861] Fusion MPT SPI Host driver 3.04.19
[    3.014833] Fusion MPT FC Host driver 3.04.19
[    3.020702] Fusion MPT SAS Host driver 3.04.19
[    3.026628] Fusion MPT misc device (ioctl) driver 3.04.19
[    3.033523] mptctl: Registered with Fusion MPT base driver
[    3.040400] mptctl: /dev/mptctl @ (major,minor=3D10,220)
[    3.046911] Fusion MPT LAN driver 3.04.19
[    3.052496] Initializing USB Mass Storage driver...
[    3.058819] usbcore: registered new interface driver usb-storage
[    3.066186] USB Mass Storage support registered.
[    3.072219] usbcore: registered new interface driver libusual
[    3.079398] usbcore: registered new interface driver ums-alauda
[    3.086717] usbcore: registered new interface driver ums-cypress
[    3.105090] usbcore: registered new interface driver ums-datafab
[    3.112462] usbcore: registered new interface driver ums-freecom
[    3.119789] usbcore: registered new interface driver ums-isd200
[    3.126992] usbcore: registered new interface driver ums-jumpshot
[    3.134331] usbcore: registered new interface driver ums-karma
[    3.141421] usbcore: registered new interface driver ums-onetouch
[    3.148730] usbcore: registered new interface driver ums-sddr09
[    3.155860] usbcore: registered new interface driver ums-sddr55
[    3.162946] usbcore: registered new interface driver ums-usbat
[    3.169973] i8042: PNP: PS/2 Controller [PNP0303:PS2K] at 0x60,0x64 ir=
q 1
[    3.177831] i8042: PNP: PS/2 appears to have AUX port disabled, if thi=
s is incorrect please boot with i8042.nopnp
[    3.189426] serio: i8042 KBD port at 0x60,0x64 irq 1
[    3.195871] mousedev: PS/2 mouse device common for all mice
[    3.203218] rtc_cmos 00:02: RTC can wake from S4
[    3.209200] rtc_cmos 00:02: rtc core: registered rtc_cmos as rtc0
[    3.216538] rtc0: alarms up to one year, y3k, 114 bytes nvram, hpet ir=
qs
[    3.224468] md: linear personality registered for level -1
[    3.231145] md: raid0 personality registered for level 0
[    3.237631] md: raid1 personality registered for level 1
[    3.244079] md: raid10 personality registered for level 10
[    3.250682] md: raid6 personality registered for level 6
[    3.250758] input: AT Translated Set 2 keyboard as /devices/platform/i=
8042/serio0/input/input2
[    3.266905] md: raid5 personality registered for level 5
[    3.273415] md: raid4 personality registered for level 4
[    3.279915] md: multipath personality registered for level -4
[    3.286863] md: faulty personality registered for level -5
[    3.293858] device-mapper: ioctl: 4.21.0-ioctl (2011-07-06) initialise=
d: dm-devel@redhat.com
[    3.303861] cpuidle: using governor ladder
[    3.309246] cpuidle: using governor menu
[    3.314563] dcdbas dcdbas: Dell Systems Management Base Driver (versio=
n 5.6.0-3.2)
[    3.324981] usbcore: registered new interface driver usbhid
[    3.328052] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[    3.339381] usbhid: USB HID core driver
[    3.344747] TCP bic registered
[    3.349158] NET: Registered protocol family 17
[    3.355056] Registering the dns_resolver key type
[    3.373036] ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[    3.380554] ata1.00: ATA-7: ST3320620AS, 3.AAK, max UDMA/133
[    3.383170] ata3.00: ATAPI: TSSTcorp CDDVDW SH-S203B, SB00, max UDMA/1=
00
[    3.389164] ata3.00: configured for UDMA/100
[    3.401097] ata1.00: 625142448 sectors, multi 16: LBA48 NCQ (depth 0/3=
2)
[    3.448321] ata1.00: configured for UDMA/133
[    3.454155] scsi 0:0:0:0: Direct-Access     ATA      ST3320620AS      =
3.AA PQ: 0 ANSI: 5
[    3.464039] sd 0:0:0:0: [sda] 625142448 512-byte logical blocks: (320 =
GB/298 GiB)
[    3.473052] sd 0:0:0:0: [sda] Write Protect is off
[    3.479363] sd 0:0:0:0: Attached scsi generic sg0 type 0
[    3.479366] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enable=
d, doesn't support DPO or FUA
[    3.513012]  sda: sda1 sda2
[    3.517835] sd 0:0:0:0: [sda] Attached SCSI disk
[    3.950053] ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[    4.014122] ata2.00: ATAPI: TSSTcorpDVD-ROM SH-D163B, SB00, max UDMA/3=
3
[    4.066114] ata2.00: configured for UDMA/33
[    4.073557] scsi 1:0:0:0: CD-ROM            TSSTcorp DVD-ROM SH-D163B =
SB00 PQ: 0 ANSI: 5
[    4.085485] sr0: scsi3-mmc drive: 4x/48x cd/rw xa/form2 cdda tray
[    4.093176] cdrom: Uniform CD-ROM driver Revision: 3.20
[    4.100400] sr 1:0:0:0: Attached scsi generic sg1 type 5
[    4.108241] scsi 2:0:0:0: CD-ROM            TSSTcorp CDDVDW SH-S203B  =
SB00 PQ: 0 ANSI: 5
[    4.120617] sr1: scsi3-mmc drive: 48x/48x writer dvd-ram cd/rw xa/form=
2 cdda tray
[    4.130111] sr 2:0:0:0: Attached scsi generic sg2 type 5
[    4.450307] ata4: SATA link down (SStatus 0 SControl 300)
[    4.457449] registered taskstats version 1
[    4.478066] rtc_cmos 00:02: setting system clock to 2011-12-22 09:44:0=
0 UTC (1324547040)
[    4.487864] powernow-k8: Found 1 AMD Athlon(tm) 64 X2 Dual Core Proces=
sor 5200+ (2 cpu cores) (version 2.20.00)
[    4.499680] [Firmware Bug]: powernow-k8: No compatible ACPI _PSS objec=
ts found.
[    4.499682] [Firmware Bug]: powernow-k8: Try again with latest BIOS.
[    4.517194] Freeing unused kernel memory: 748k freed


--------------030803080705040100080906--

--------------ms000509080907080106070402
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Kryptografische Unterschrift

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFSjCC
BUYwggMuoAMCAQICAwhzEzANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4w
HAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmlu
ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMDA0
MDMxMjE2NDhaFw0xMjA0MDIxMjE2NDhaMEgxHDAaBgNVBAMTE0Zsb3JpYW4gTWFuc2Nod2V0
dXMxKDAmBgkqhkiG9w0BCQEWGUZsb3JpYW5NYW5zY2h3ZXR1c0BnbXguZGUwggEiMA0GCSqG
SIb3DQEBAQUAA4IBDwAwggEKAoIBAQDOx228LSNcMIRtatTC835J0dYDQbcsng06PdtewI0r
rwtxTSXndYotpjS257vzZOlIPMGRPUJL/FZgL7Nw8zaz2d/jCuQnzGgRukKefl2BZV4eW/xq
hrc5tStj1h7+jZyhtGtR1Jt4Y8TOXF/bjBFCoZRgrfo316LoP/zW1WY34UbW3E2hLpkbRkP7
4Tj6tgpH1TZl1UtA2skuL3GQ3+Mx/Wsh7hCNGAvrV+3BGkA5bZMrKRd1Trcz1Bla68m1WAas
xkNL/DbvgSWiIdyT7860wzcdKRS+ANlhtswsnwfj7arLNeBycQkiQeliFnQY2KBC9KZszkZ7
jdO1HgaEWKFLAgMBAAGjggEGMIIBAjAMBgNVHRMBAf8EAjAAMFYGCWCGSAGG+EIBDQRJFkdU
byBnZXQgeW91ciBvd24gY2VydGlmaWNhdGUgZm9yIEZSRUUgaGVhZCBvdmVyIHRvIGh0dHA6
Ly93d3cuQ0FjZXJ0Lm9yZzBABgNVHSUEOTA3BggrBgEFBQcDBAYIKwYBBQUHAwIGCisGAQQB
gjcKAwQGCisGAQQBgjcKAwMGCWCGSAGG+EIEATAyBggrBgEFBQcBAQQmMCQwIgYIKwYBBQUH
MAGGFmh0dHA6Ly9vY3NwLmNhY2VydC5vcmcwJAYDVR0RBB0wG4EZRmxvcmlhbk1hbnNjaHdl
dHVzQGdteC5kZTANBgkqhkiG9w0BAQUFAAOCAgEABTIxdlft8iVgfpvh+nR842ialjkFp5Fi
ow5HOGkTG1tcPczEOvApu8267JHwy390X8ZsOvxZt9QSNmGwKAeQuX1meNgRzXBWuGT5YjOH
2qtwLvXr2AIPaRB1U8Qu2iKEKqjOY8x9SBrU5cFqrN7iySlo7kvvq8DQub5BFLd6FMsCaxZI
Gyxd0FXVy57YEu/ZeknQutGS1NmGFc70hRe53DKILDh/bDO2r4yhvLOujJKjQf2kDkBoBZRI
MyACJiqxz7R+/Dog9zbqcqEiB2YCe1x8KFmgwfevrBH3+MyAhlg5lKA3DTq41kiwlpgC+unC
rgOfGoi1Y1IU/FoXgTil7G87L1IRrnVlcEcd6OiysFgwHsK6Y1ScVPoxJ3gmuqGsYDNlUxoH
U8wLRVexlTuQjCLr3kwbTUlrWfXw1b30Fkx1RludNrP8MO6vDFW4/8tOF9CApplTBZ/FpMhs
l2PF8suztvTobCuc7Z4DnqtfcqfPfcyNR610DaGOrp5eIjcn071z93qwzqOc0qxN1bcJZFM5
IAAKpvLLIlYzbK0fuHMb+xGFwCxjY6uQJrz77xpMu/bfS0LU5Xlzg+VfDFgpeUkY4tGS9e5v
qRyUN2es5+TRqNR0hmdRj3zxL1ogBtcLLHdvcxmna8n5yyHwU2eZkXEr0JW0uOT903skt/mC
/zUxggOUMIIDkAIBATCBgDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8v
d3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAf
BgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZwIDCHMTMAkGBSsOAwIaBQCgggHoMBgG
CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMTIyMjA5NDk0M1ow
IwYJKoZIhvcNAQkEMRYEFIed/oeB9gkzUIQSHFnFX8i+e4y3MF8GCSqGSIb3DQEJDzFSMFAw
CwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIB
QDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBkQYJKwYBBAGCNxAEMYGDMIGAMHkxEDAOBgNV
BAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZ
Q0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNl
cnQub3JnAgMIcxMwgZMGCyqGSIb3DQEJEAILMYGDoIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0Ex
HjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWdu
aW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMIcxMw
DQYJKoZIhvcNAQEBBQAEggEAwtFZtA9QpSTxp6SMKu+E4JxWtleKbpXSjcJmJq9/8oHFzY3b
OmiIomIP3krpFu6DVa/xGgn6CNnNRboOyywa/4BhQypEeb0RGQonES6wtGYREyuoBvBGG36t
t6yQcggnE8cUmrF110oCl/Wyju1p0Eo2Ssy9ds2Quo2e5bZ/5IHrBMvZtR5LJchg7c/VFOfG
uyiCbwcc6tjP4jTeri3+eAKvea6L3Q4sJ/h+YOudWw/T6nxpv6u7US+SDAYFo6MfxtK6ImgP
Cm2uIxoIuNMJFM5lh7p96yjRh9FFVxadt9FqXKl2D+LAUmIulSzgRKTzNFVYL+Yv70OARpJl
/lcg4wAAAAAAAA==
--------------ms000509080907080106070402--


--===============5591654311481353553==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============5591654311481353553==--


From xen-devel-bounces@lists.xensource.com Thu Dec 22 09:51:13 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 Dec 2011 09:51:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdfIV-0003RP-Sy; Thu, 22 Dec 2011 09:50:47 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <florianmanschwetus@gmx.de>) id 1RdfIT-0003R8-5S
	for xen-devel@lists.xensource.com; Thu, 22 Dec 2011 09:50:45 +0000
X-Env-Sender: florianmanschwetus@gmx.de
X-Msg-Ref: server-10.tower-27.messagelabs.com!1324547400!47798685!1
X-Originating-IP: [213.165.64.22]
X-SpamReason: No, hits=0.5 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMTMuMTY1LjY0LjIyID0+IDEwNTI0MQ==\n,sa_preprocessor: 
	QmFkIElQOiAyMTMuMTY1LjY0LjIyID0+IDEwNTI0MQ==\n,BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23161 invoked from network); 22 Dec 2011 09:50:00 -0000
Received: from mailout-de.gmx.net (HELO mailout-de.gmx.net) (213.165.64.22)
	by server-10.tower-27.messagelabs.com with SMTP;
	22 Dec 2011 09:50:00 -0000
Received: (qmail invoked by alias); 22 Dec 2011 09:50:40 -0000
Received: from dslb-088-069-059-020.pools.arcor-ip.net (EHLO [192.168.222.23])
	[88.69.59.20]
	by mail.gmx.net (mp008) with SMTP; 22 Dec 2011 10:50:40 +0100
X-Authenticated: #7518697
X-Provags-ID: V01U2FsdGVkX1+fbus0D5ifqp2gWuuQxZxk3i511641iooPsy1AEq
	6YI68OcUrSR6+D
Message-ID: <4EF2FD37.5030600@gmx.de>
Date: Thu, 22 Dec 2011 10:49:43 +0100
From: Florian Manschwetus <florianmanschwetus@gmx.de>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:8.0) Gecko/20111121 Thunderbird/8.0
MIME-Version: 1.0
To: xen-devel@lists.xensource.com
References: <4EF06B14.4070106@gmx.de> <4EF0B034.1090708@gmx.de>
	<4EF270A7.2010705@gmx.de>
	<4EF307540200007800069894@nat28.tlf.novell.com>
In-Reply-To: <4EF307540200007800069894@nat28.tlf.novell.com>
X-Y-GMX-Trusted: 0
Subject: Re: [Xen-devel] [Xen-users] Problem booting xen 4.1.2 on Athlon 64
 X2
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============5591654311481353553=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Dies ist eine kryptografisch unterzeichnete Nachricht im MIME-Format.

--===============5591654311481353553==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms000509080907080106070402"

Dies ist eine kryptografisch unterzeichnete Nachricht im MIME-Format.

--------------ms000509080907080106070402
Content-Type: multipart/mixed;
 boundary="------------030803080705040100080906"

This is a multi-part message in MIME format.
--------------030803080705040100080906
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: quoted-printable

Am 22.12.2011 10:32, schrieb Jan Beulich:
>>>> On 22.12.11 at 00:49, Florian Manschwetus<florianmanschwetus@gmx.de>=
  wrote:
>> Sending to devel, maybe a BUG?
>
> Unlikely, perhaps rather the lack of a necessary command line option
> ("acpi_skip_timer_override"). If you don't need this option when bootin=
g
> Linux on that system, you can verify this by looking at whether the
> native kernel logs a respective message and/or one saying
> "BIOS IRQ0 pin2 override ignored".
>
> Jan
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>
Ok, I think I got the output. But I see nothing really helpful in there. =

I have attached the boot-log, maybe it gives you the needed information.

Thx,
Florian

--------------030803080705040100080906
Content-Type: text/plain;
 name="kernel-boot"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
 filename="kernel-boot"

Loading Linux x86_64-3.1.5-gentoo ...
Loading initial ramdisk ...
[    0.000000] Initializing cgroup subsys cpuset
[    0.000000] Initializing cgroup subsys cpu
[    0.000000] Linux version 3.1.5-gentoo (root@turing.algo.informatik.tu=
-darmstadt.de) (gcc version 4.5.3 (Gentoo 4.5.3-r1 p1.0, pie-0.4.5) ) #2 =
SMP Tue Dec 20 16:08:28 CET 2011
[    0.000000] Command line: BOOT_IMAGE=3D/kernel-genkernel-x86_64-3.1.5-=
gentoo ro init=3D/linuxrc splash=3Dsilent,theme:sabayon vga=3D791 console=
=3Dtty1 domdadm resume=3Dswap:/dev/mapper/vg_turing-lv_swap real_resume=3D=
/dev/mapper/vg_turing-lv_swap dolvm root=3D/dev/mapper/vg_turing-lv_root =
docrypt console=3DttyS0,115200n8
[    0.000000] BIOS-provided physical RAM map:
[    0.000000]  BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
[    0.000000]  BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)=

[    0.000000]  BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved)=

[    0.000000]  BIOS-e820: 0000000000100000 - 00000000bffc0000 (usable)
[    0.000000]  BIOS-e820: 00000000bffc0000 - 00000000bffce000 (ACPI data=
)
[    0.000000]  BIOS-e820: 00000000bffce000 - 00000000bfff0000 (ACPI NVS)=

[    0.000000]  BIOS-e820: 00000000bfff0000 - 00000000c0000000 (reserved)=

[    0.000000]  BIOS-e820: 00000000fec00000 - 00000000fec01000 (reserved)=

[    0.000000]  BIOS-e820: 00000000fee00000 - 00000000fef00000 (reserved)=

[    0.000000]  BIOS-e820: 00000000ff780000 - 0000000100000000 (reserved)=

[    0.000000]  BIOS-e820: 0000000100000000 - 0000000140000000 (usable)
[    0.000000] NX (Execute Disable) protection: active
[    0.000000] DMI present.
[    0.000000] No AGP bridge found
[    0.000000] last_pfn =3D 0x140000 max_arch_pfn =3D 0x400000000
[    0.000000] x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600=
070106
[    0.000000] last_pfn =3D 0xbffc0 max_arch_pfn =3D 0x400000000
[    0.000000] found SMP MP-table at [ffff8800000ff780] ff780
[    0.000000] init_memory_mapping: 0000000000000000-00000000bffc0000
[    0.000000] init_memory_mapping: 0000000100000000-0000000140000000
[    0.000000] RAMDISK: 36b68000 - 375ac000
[    0.000000] ACPI: RSDP 00000000000fb840 00024 (v02 ACPIAM)
[    0.000000] ACPI: XSDT 00000000bffc0100 0004C (v01 A_M_I_ OEMXSDT  030=
00826 MSFT 00000097)
[    0.000000] ACPI: FACP 00000000bffc0290 000F4 (v03 A_M_I_ OEMFACP  030=
00826 MSFT 00000097)
[    0.000000] ACPI: DSDT 00000000bffc05c0 04E38 (v01  A0557 A0557000 000=
00000 INTL 20051117)
[    0.000000] ACPI: FACS 00000000bffce000 00040
[    0.000000] ACPI: APIC 00000000bffc0390 00070 (v01 A_M_I_ OEMAPIC  030=
00826 MSFT 00000097)
[    0.000000] ACPI: MCFG 00000000bffc0400 0003C (v01 A_M_I_ OEMMCFG  030=
00826 MSFT 00000097)
[    0.000000] ACPI: OEMB 00000000bffce040 00060 (v01 A_M_I_ AMI_OEM  030=
00826 MSFT 00000097)
[    0.000000] ACPI: HPET 00000000bffc5400 00038 (v01 A_M_I_ OEMHPET0 030=
00826 MSFT 00000097)
[    0.000000] Scanning NUMA topology in Northbridge 24
[    0.000000] No NUMA configuration found
[    0.000000] Faking a node at 0000000000000000-0000000140000000
[    0.000000] Initmem setup node 0 0000000000000000-0000000140000000
[    0.000000]   NODE_DATA [000000013fffb000 - 000000013fffffff]
[    0.000000] Zone PFN ranges:
[    0.000000]   DMA      0x00000010 -> 0x00001000
[    0.000000]   DMA32    0x00001000 -> 0x00100000
[    0.000000]   Normal   0x00100000 -> 0x00140000
[    0.000000] Movable zone start PFN for each node
[    0.000000] early_node_map[3] active PFN ranges
[    0.000000]     0: 0x00000010 -> 0x0000009f
[    0.000000]     0: 0x00000100 -> 0x000bffc0
[    0.000000]     0: 0x00100000 -> 0x00140000
[    0.000000] Detected use of extended apic ids on hypertransport bus
[    0.000000] ACPI: PM-Timer IO Port: 0x508
[    0.000000] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled)
[    0.000000] ACPI: IOAPIC (id[0x02] address[0xfec00000] gsi_base[0])
[    0.000000] IOAPIC[0]: apic_id 2, version 17, address 0xfec00000, GSI =
0-23
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 0 dfl dfl)
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level=
)
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 14 global_irq 14 high edg=
e)
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 15 global_irq 15 high edg=
e)
[    0.000000] Using ACPI (MADT) for SMP configuration information
[    0.000000] ACPI: HPET id: 0x10de8201 base: 0xfed00000
[    0.000000] SMP: Allowing 2 CPUs, 0 hotplug CPUs
[    0.000000] PM: Registered nosave memory: 000000000009f000 - 000000000=
00a0000
[    0.000000] PM: Registered nosave memory: 00000000000a0000 - 000000000=
00e0000
[    0.000000] PM: Registered nosave memory: 00000000000e0000 - 000000000=
0100000
[    0.000000] PM: Registered nosave memory: 00000000bffc0000 - 00000000b=
ffce000
[    0.000000] PM: Registered nosave memory: 00000000bffce000 - 00000000b=
fff0000
[    0.000000] PM: Registered nosave memory: 00000000bfff0000 - 00000000c=
0000000
[    0.000000] PM: Registered nosave memory: 00000000c0000000 - 00000000f=
ec00000
[    0.000000] PM: Registered nosave memory: 00000000fec00000 - 00000000f=
ec01000
[    0.000000] PM: Registered nosave memory: 00000000fec01000 - 00000000f=
ee00000
[    0.000000] PM: Registered nosave memory: 00000000fee00000 - 00000000f=
ef00000
[    0.000000] PM: Registered nosave memory: 00000000fef00000 - 00000000f=
f780000
[    0.000000] PM: Registered nosave memory: 00000000ff780000 - 000000010=
0000000
[    0.000000] Allocating PCI resources starting at c0000000 (gap: c00000=
00:3ec00000)
[    0.000000] Booting paravirtualized kernel on bare hardware
[    0.000000] setup_percpu: NR_CPUS:64 nr_cpumask_bits:64 nr_cpu_ids:2 n=
r_node_ids:1
[    0.000000] PERCPU: Embedded 26 pages/cpu @ffff88013fc00000 s74688 r81=
92 d23616 u1048576
[    0.000000] Built 1 zonelists in Node order, mobility grouping on.  To=
tal pages: 1027914
[    0.000000] Policy zone: Normal
[    0.000000] Kernel command line: BOOT_IMAGE=3D/kernel-genkernel-x86_64=
-3.1.5-gentoo ro init=3D/linuxrc splash=3Dsilent,theme:sabayon vga=3D791 =
console=3Dtty1 domdadm resume=3Dswap:/dev/mapper/vg_turing-lv_swap real_r=
esume=3D/dev/mapper/vg_turing-lv_swap dolvm root=3D/dev/mapper/vg_turing-=
lv_root docrypt console=3DttyS0,115200n8
[    0.000000] PID hash table entries: 4096 (order: 3, 32768 bytes)
[    0.000000] Checking aperture...
[    0.000000] No AGP bridge found
[    0.000000] Node 0: aperture @ b4000000 size 32 MB
[    0.000000] Aperture pointing to e820 RAM. Ignoring.
[    0.000000] Your BIOS doesn't leave a aperture memory hole
[    0.000000] Please enable the IOMMU option in the BIOS setup
[    0.000000] This costs you 64 MB of RAM
[    0.000000] Mapping aperture over 65536 KB of RAM @ b4000000
[    0.000000] PM: Registered nosave memory: 00000000b4000000 - 00000000b=
8000000
[    0.000000] Memory: 3972508k/5242880k available (7229k kernel code, 10=
49284k absent, 221088k reserved, 4408k data, 748k init)
[    0.000000] SLUB: Genslabs=3D15, HWalign=3D64, Order=3D0-3, MinObjects=
=3D0, CPUs=3D2, Nodes=3D1
[    0.000000] Hierarchical RCU implementation.
[    0.000000] NR_IRQS:4352 nr_irqs:512 16
[    0.000000] Extended CMOS year: 2000
[    0.000000] Console: colour dummy device 80x25
[    0.000000] console [tty1] enabled
[    0.000000] console [ttyS0] enabled
[    0.000000] allocated 33554432 bytes of page_cgroup
[    0.000000] please try 'cgroup_disable=3Dmemory' option if you don't w=
ant memory cgroups
[    0.000000] Fast TSC calibration using PIT
[    0.000000] Detected 2611.707 MHz processor.
[    0.000000] Marking TSC unstable due to TSCs unsynchronized
[    0.003999] Calibrating delay loop (skipped), value calculated using t=
imer frequency.. 5223.41 BogoMIPS (lpj=3D2611707)
[    0.005002] pid_max: default: 32768 minimum: 301
[    0.006028] Security Framework initialized
[    0.007005] AppArmor: AppArmor disabled by boot time parameter
[    0.008406] Dentry cache hash table entries: 524288 (order: 10, 419430=
4 bytes)
[    0.010954] Inode-cache hash table entries: 262144 (order: 9, 2097152 =
bytes)
[    0.012068] Mount-cache hash table entries: 256
[    0.013148] Initializing cgroup subsys debug
[    0.014003] Initializing cgroup subsys memory
[    0.015011] Initializing cgroup subsys devices
[    0.016002] Initializing cgroup subsys freezer
[    0.017002] Initializing cgroup subsys blkio
[    0.018009] Initializing cgroup subsys perf_event
[    0.019039] CPU: Physical Processor ID: 0
[    0.020001] CPU: Processor Core ID: 0
[    0.021002] mce: CPU supports 5 MCE banks
[    0.022009] using AMD E400 aware idle routine
[    0.025543] ACPI: Core revision 20110623
[    0.028998] ..TIMER: vector=3D0x30 apic1=3D0 pin1=3D0 apic2=3D-1 pin2=3D=
-1
[    0.029997] ..MP-BIOS bug: 8254 timer not connected to IO-APIC
[    0.029997] ...trying to set up timer (IRQ0) through the 8259A ...
[    0.029997] ..... (found apic 0 pin 0) ...
[    0.040381] ....... works.
[    0.040998] CPU0: AMD Athlon(tm) 64 X2 Dual Core Processor 5200+ stepp=
ing 03
[    0.044996] Performance Events: AMD PMU driver.
[    0.045999] ... version:                0
[    0.046997] ... bit width:              48
[    0.047997] ... generic registers:      4
[    0.048997] ... value mask:             0000ffffffffffff
[    0.049997] ... max period:             00007fffffffffff
[    0.050997] ... fixed-purpose events:   0
[    0.051997] ... event mask:             000000000000000f
[    0.053077] MCE: In-kernel MCE decoding enabled.
[    0.054069] Booting Node   0, Processors  #1 Ok.
[    0.127031] Brought up 2 CPUs
[    0.127990] Total of 2 processors activated (10446.80 BogoMIPS).
[    0.129469] devtmpfs: initialized
[    0.131709] PM: Registering ACPI NVS region at bffce000 (139264 bytes)=

[    0.138025] xor: automatically using best checksumming function: gener=
ic_sse
[    0.149948]    generic_sse:  8052.000 MB/sec
[    0.153986] xor: using function: generic_sse (8052.000 MB/sec)
[    0.160052] print_constraints: dummy:=20
[    0.164032] NET: Registered protocol family 16
[    0.168989] TOM: 00000000c0000000 aka 3072M
[    0.173005] TOM2: 0000000140000000 aka 5120M
[    0.177004] ACPI: bus type pci registered
[    0.181020] PCI: MMCONFIG for domain 0000 [bus 00-ff] at [mem 0xe00000=
00-0xefffffff] (base 0xe0000000)
[    0.191002] PCI: not using MMCONFIG
[    0.193981] PCI: Using configuration type 1 for base access
[    0.217136] bio: create slab <bio-0> at 0
[    0.234953] raid6: int64x1   2171 MB/s
[    0.254954] raid6: int64x2   2777 MB/s
[    0.274953] raid6: int64x4   2027 MB/s
[    0.294948] raid6: int64x8   1468 MB/s
[    0.314925] raid6: sse2x1    3664 MB/s
[    0.334930] raid6: sse2x2    4839 MB/s
[    0.354929] raid6: sse2x4    5023 MB/s
[    0.357956] raid6: using algorithm sse2x4 (5023 MB/s)
[    0.362983] ACPI: Added _OSI(Module Device)
[    0.368075] ACPI: Added _OSI(Processor Device)
[    0.371985] ACPI: Added _OSI(3.0 _SCP Extensions)
[    0.376973] ACPI: Added _OSI(Processor Aggregator Device)
[    0.385172] ACPI: Executed 1 blocks of module-level executable AML cod=
e
[    0.393578] ACPI: Interpreter enabled
[    0.396952] ACPI: (supports S0 S1 S3 S4 S5)
[    0.401514] ACPI: Using IOAPIC for interrupt routing
[    0.405967] PCI: MMCONFIG for domain 0000 [bus 00-ff] at [mem 0xe00000=
00-0xefffffff] (base 0xe0000000)
[    0.416987] PCI: MMCONFIG at [mem 0xe0000000-0xefffffff] reserved in A=
CPI motherboard resources
[    0.456060] ACPI: No dock devices found.
[    0.459963] HEST: Table not found.
[    0.463963] PCI: Using host bridge windows from ACPI; if necessary, us=
e "pci=3Dnocrs" and report a bug
[    0.472998] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff])
[    0.479039] pci_root PNP0A03:00: host bridge window [io  0x0000-0x0cf7=
]
[    0.485965] pci_root PNP0A03:00: host bridge window [io  0x0d00-0xffff=
]
[    0.491949] pci_root PNP0A03:00: host bridge window [mem 0x000a0000-0x=
000bffff]
[    0.499935] pci_root PNP0A03:00: host bridge window [mem 0x000d0000-0x=
000dffff]
[    0.506934] pci_root PNP0A03:00: host bridge window [mem 0xc0000000-0x=
ff77ffff]
[    0.515776] pci 0000:00:04.0: PCI bridge to [bus 01-01] (subtractive d=
ecode)
[    0.524938] pci 0000:00:09.0: PCI bridge to [bus 02-02]
[    0.529958] pci 0000:00:0b.0: PCI bridge to [bus 03-03]
[    0.534948] pci 0000:00:0c.0: PCI bridge to [bus 04-04]
[    0.540180]  pci0000:00: Requesting ACPI _OSC control (0x1d)
[    0.545929]  pci0000:00: ACPI _OSC request failed (AE_NOT_FOUND), retu=
rned control mask: 0x1d
[    0.554926] ACPI _OSC control for PCIe not granted, disabling ASPM
[    0.565157] ACPI: PCI Interrupt Link [LNKA] (IRQs 16 17 18 19) *0, dis=
abled.
[    0.573178] ACPI: PCI Interrupt Link [LNKB] (IRQs 16 17 18 19) *0, dis=
abled.
[    0.580180] ACPI: PCI Interrupt Link [LNKC] (IRQs 16 17 18 19) *0, dis=
abled.
[    0.587174] ACPI: PCI Interrupt Link [LNKD] (IRQs 16 17 18 19) *0, dis=
abled.
[    0.594983] ACPI: PCI Interrupt Link [LNEA] (IRQs 16 17 18 19) *0, dis=
abled.
[    0.602174] ACPI: PCI Interrupt Link [LNEB] (IRQs 16 17 18 19) *0, dis=
abled.
[    0.609172] ACPI: PCI Interrupt Link [LNEC] (IRQs 16 17 18 19) *0, dis=
abled.
[    0.616169] ACPI: PCI Interrupt Link [LNED] (IRQs 16 17 18 19) *11
[    0.623172] ACPI: PCI Interrupt Link [LUB0] (IRQs 20 21 22 23) *11
[    0.629534] ACPI: PCI Interrupt Link [LUB2] (IRQs 20 21 22 23) *10
[    0.635978] ACPI: PCI Interrupt Link [LMAC] (IRQs 20 21 22 23) *11
[    0.642165] ACPI: PCI Interrupt Link [LAZA] (IRQs 20 21 22 23) *11
[    0.648641] ACPI: PCI Interrupt Link [LACI] (IRQs 20 21 22 23) *0, dis=
abled.
[    0.655974] ACPI: PCI Interrupt Link [LMC9] (IRQs 20 21 22 23) *0, dis=
abled.
[    0.663164] ACPI: PCI Interrupt Link [LSMB] (IRQs 20 21 22 23) *10
[    0.669636] ACPI: PCI Interrupt Link [LPMU] (IRQs 20 21 22 23) *0, dis=
abled.
[    0.676971] ACPI: PCI Interrupt Link [LSA0] (IRQs 20 21 22 23) *15
[    0.683161] ACPI: PCI Interrupt Link [LSA1] (IRQs 20 21 22 23) *5
[    0.689555] ACPI: PCI Interrupt Link [LATA] (IRQs 20 21 22 23) *0, dis=
abled.
[    0.696931] vgaarb: device added: PCI:0000:02:00.0,decodes=3Dio+mem,ow=
ns=3Dio+mem,locks=3Dnone
[    0.704909] vgaarb: loaded
[    0.707902] vgaarb: bridge control possible 0000:02:00.0
[    0.712968] SCSI subsystem initialized
[    0.716940] usbcore: registered new interface driver usbfs
[    0.717932] usbcore: registered new interface driver hub
[    0.718915] usbcore: registered new device driver usb
[    0.724943] wmi: Mapper loaded
[    0.725931] PCI: Using ACPI for IRQ routing
[    0.733376] NetLabel: Initializing
[    0.733899] NetLabel:  domain hash size =3D 128
[    0.734898] NetLabel:  protocols =3D UNLABELED CIPSOv4
[    0.735908] NetLabel:  unlabeled traffic allowed by default
[    0.736926] HPET: 3 timers in total, 0 timers will be used for per-cpu=
 timer
[    0.737912] hpet0: at MMIO 0xfed00000, IRQs 2, 8, 31
[    0.740087] hpet0: 3 comparators, 32-bit 25.000000 MHz counter
[    0.743925] Switching to clocksource hpet
[    0.745795] Switched to NOHz mode on CPU #0
[    0.745831] Switched to NOHz mode on CPU #1
[    0.758811] pnp: PnP ACPI init
[    0.761880] ACPI: bus type pnp registered
[    0.768493] pnp 00:07: disabling [io  0x0900-0x097f] because it overla=
ps 0000:00:01.0 BAR 0 [io  0x0900-0x09ff]
[    0.778577] pnp 00:07: disabling [io  0x0980-0x09ff] because it overla=
ps 0000:00:01.0 BAR 0 [io  0x0900-0x09ff]
[    0.789016] system 00:07: [io  0x04d0-0x04d1] has been reserved
[    0.794937] system 00:07: [io  0x0800-0x080f] has been reserved
[    0.800888] system 00:07: [io  0x0500-0x057f] has been reserved
[    0.806809] system 00:07: [io  0x0580-0x05ff] has been reserved
[    0.812747] system 00:07: [io  0x0800-0x087f] could not be reserved
[    0.819020] system 00:07: [io  0x0880-0x08ff] has been reserved
[    0.824940] system 00:07: [io  0x0d00-0x0d7f] has been reserved
[    0.830857] system 00:07: [io  0x0d80-0x0dff] has been reserved
[    0.836778] system 00:07: [io  0x2000-0x207f] has been reserved
[    0.842697] system 00:07: [io  0x2080-0x20ff] has been reserved
[    0.848685] system 00:07: [mem 0x000d0000-0x000d3fff window] has been =
reserved
[    0.855906] system 00:07: [mem 0x000d4000-0x000d7fff window] has been =
reserved
[    0.863124] system 00:07: [mem 0x000de000-0x000dffff window] has been =
reserved
[    0.870344] system 00:07: [mem 0xfefe0000-0xfefe01ff] has been reserve=
d
[    0.876955] system 00:07: [mem 0xfefe1000-0xfefe1fff] has been reserve=
d
[    0.883568] system 00:07: [mem 0xfee01000-0xfeefffff] has been reserve=
d
[    0.890182] system 00:07: [mem 0xffb80000-0xffffffff] has been reserve=
d
[    0.896794] system 00:07: [mem 0xff300000-0xff3fffff] has been reserve=
d
[    0.903682] system 00:09: [mem 0xfec00000-0xfec00fff] could not be res=
erved
[    0.910783] system 00:09: [mem 0xfee00000-0xfee00fff] has been reserve=
d
[    0.917734] system 00:0b: [io  0x0230-0x023f] has been reserved
[    0.923659] system 00:0b: [io  0x0290-0x029f] has been reserved
[    0.929579] system 00:0b: [io  0x0a00-0x0a0f] has been reserved
[    0.935502] system 00:0b: [io  0x0a10-0x0a1f] has been reserved
[    0.942144] system 00:0d: [mem 0xe0000000-0xefffffff] has been reserve=
d
[    0.948997] system 00:0e: [mem 0x00000000-0x0009ffff] could not be res=
erved
[    0.955963] system 00:0e: [mem 0x000c0000-0x000cffff] could not be res=
erved
[    0.962935] system 00:0e: [mem 0x000e0000-0x000fffff] could not be res=
erved
[    0.969897] system 00:0e: [mem 0x00100000-0xbfffffff] could not be res=
erved
[    0.976945] system 00:0e: [mem 0xff780000-0xffffffff] could not be res=
erved
[    0.984185] pnp: PnP ACPI: found 15 devices
[    0.988375] ACPI: ACPI bus type pnp unregistered
[    0.998454] pci 0000:00:04.0: PCI bridge to [bus 01-01]
[    1.003693] pci 0000:00:09.0: PCI bridge to [bus 02-02]
[    1.008923] pci 0000:00:09.0:   bridge window [io  0xe000-0xefff]
[    1.015019] pci 0000:00:09.0:   bridge window [mem 0xdc000000-0xdfffff=
ff]
[    1.021809] pci 0000:00:09.0:   bridge window [mem 0xc0000000-0xcfffff=
ff 64bit pref]
[    1.029568] pci 0000:00:0b.0: PCI bridge to [bus 03-03]
[    1.034795] pci 0000:00:0c.0: PCI bridge to [bus 04-04]
[    1.040256] NET: Registered protocol family 2
[    1.044747] IP route cache hash table entries: 131072 (order: 8, 10485=
76 bytes)
[    1.053461] TCP established hash table entries: 524288 (order: 11, 838=
8608 bytes)
[    1.064520] TCP bind hash table entries: 65536 (order: 8, 1048576 byte=
s)
[    1.071748] TCP: Hash tables configured (established 524288 bind 65536=
)
[    1.078363] TCP reno registered
[    1.081523] UDP hash table entries: 2048 (order: 4, 65536 bytes)
[    1.087577] UDP-Lite hash table entries: 2048 (order: 4, 65536 bytes)
[    1.094139] NET: Registered protocol family 1
[    1.673093] pci 0000:00:00.0: Found enabled HT MSI Mapping
[    1.678626] pci 0000:00:00.0: Found enabled HT MSI Mapping
[    1.684170] pci 0000:00:00.0: Found enabled HT MSI Mapping
[    1.689708] pci 0000:00:00.0: Found enabled HT MSI Mapping
[    1.695245] pci 0000:00:00.0: Found enabled HT MSI Mapping
[    1.700786] pci 0000:00:00.0: Found enabled HT MSI Mapping
[    1.706335] pci 0000:00:00.0: Found enabled HT MSI Mapping
[    1.711885] pci 0000:00:00.0: Found enabled HT MSI Mapping
[    1.717442] Trying to unpack rootfs image as initramfs...
[    1.871811] Freeing initrd memory: 10512k freed
[    1.883027] PCI-DMA: Disabling AGP.
[    1.886613] PCI-DMA: aperture base @ b4000000 size 65536 KB
[    1.892188] PCI-DMA: using GART IOMMU.
[    1.895940] PCI-DMA: Reserving 64MB of IOMMU area in the AGP aperture
[    1.907445] audit: initializing netlink socket (disabled)
[    1.912903] type=3D2000 audit(1324547036.911:1): initialized
[    1.933398] HugeTLB registered 2 MB page size, pre-allocated 0 pages
[    1.973772] VFS: Disk quotas dquot_6.5.2
[    1.977939] Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
[    1.984492] squashfs: version 4.0 (2009/01/31) Phillip Lougher
[    1.990915] ROMFS MTD (C) 2007 Red Hat, Inc.
[    1.995336] QNX4 filesystem 0.2.3 registered.
[    2.000588] Btrfs loaded
[    2.003134] msgmni has been set to 7908
[    2.007397] async_tx: api initialized (async)
[    2.011915] Block layer SCSI generic (bsg) driver version 0.4 loaded (=
major 253)
[    2.019349] io scheduler noop registered
[    2.023282] io scheduler deadline registered
[    2.027664] io scheduler cfq registered (default)
[    2.033318] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
=EF=BF=BD[    2.304133] serial8250: ttyS0 at I/O 0x3f8 (irq =3D 4) is a 1=
6550A
[    2.387672] 00:0c: ttyS0 at I/O 0x3f8 (irq =3D 4) is a 16550A
[    2.402444] Linux agpgart interface v0.103
[    2.406692] vesafb: mode is 1024x768x16, linelength=3D2048, pages=3D0
[    2.412787] vesafb: scrolling: redraw
[    2.416459] vesafb: Truecolor: size=3D0:5:6:5, shift=3D0:11:5:0
[    2.422191] vesafb: framebuffer at 0xdd000000, mapped to 0xffffc900111=
00000, using 1536k, total 1536k
[    2.435631] Console: switching to colour frame buffer device 128x48
[    2.446153] fb0: VESA VGA frame buffer device
[    2.456177] input: Power Button as /devices/LNXSYSTM:00/device:00/PNP0=
C0C:00/input/input0
[    2.464421] ACPI: Power Button [PWRB]
[    2.468194] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/in=
put/input1
[    2.475654] ACPI: Power Button [PWRF]
[    2.482017] ERST: Table is not found!
[    2.485730] GHES: HEST is not enabled!
[    2.489638] XENFS: not registering filesystem on non-xen platform
[    2.498035] brd: module loaded
[    2.502340] loop: module loaded
[    2.505544] Compaq SMART2 Driver (v 2.6.0)
[    2.509779] HP CISS Driver (v 3.6.26)
[    2.513888] MM: desc_per_page =3D 128
[    2.517673] Loading iSCSI transport class v2.0-870.
[    2.522596] fbcondecor: console 0 using theme 'sabayon'
[    2.530014] fnic: Cisco FCoE HBA Driver, ver 1.5.0.2
[    2.535365] Loading Adaptec I2O RAID: Version 2.4 Build 5go
[    2.541023] Detecting Adaptec I2O RAID controllers...
[    2.546340] Adaptec aacraid driver 1.1-7[28000]-ms
[    2.562908] fbcondecor: switched decor state to 'on' on console 0
[    2.570582] aic94xx: Adaptec aic94xx SAS/SATA driver version 1.0.3 loa=
ded
[    2.579043] isci: Intel(R) C600 SAS Controller Driver - version 1.0.0
[    2.587223] qla2xxx [0000:00:00.0]-0005: : QLogic Fibre Channel HBA Dr=
iver: 8.03.07.07-k.
[    2.597680] iscsi: registered transport (qla4xxx)
[    2.603962] QLogic iSCSI HBA Driver
[    2.608909] Emulex LightPulse Fibre Channel SCSI driver 8.3.25
[    2.616212] Copyright(c) 2004-2009 Emulex.  All rights reserved.
[    2.623989] DC390: clustering now enabled by default. If you get probl=
ems load
[    2.632758]        with "disable_clustering=3D1" and report to maintai=
ners
[    2.641154] megaraid cmm: 2.20.2.7 (Release Date: Sun Jul 16 00:01:03 =
EST 2006)
[    2.650120] megaraid: 2.20.5.1 (Release Date: Thu Nov 16 15:32:35 EST =
2006)
[    2.658711] megasas: 00.00.05.40-rc1 Tue. Jul. 26 17:00:00 PDT 2011
[    2.666605] mpt2sas version 09.100.00.00 loaded
[    2.672894] GDT-HA: Storage RAID Controller Driver. Version: 3.05
[    2.680711] 3ware Storage Controller device driver for Linux v1.26.02.=
003.
[    2.689234] 3ware 9000 Storage Controller device driver for Linux v2.2=
6.02.014.
[    2.698184] LSI 3ware SAS/SATA-RAID Controller device driver for Linux=
 v3.26.02.000.
[    2.707598] ipr: IBM Power RAID SCSI Device Driver version: 2.5.2 (Apr=
il 27, 2011)
[    2.716823] RocketRAID 3xxx/4xxx Controller driver v1.6 (090910)
[    2.724488] stex: Promise SuperTrak EX Driver version: 4.6.0000.4
[    2.732296] libcxgbi:libcxgbi_init_module: tag itt 0x1fff, 13 bits, ag=
e 0xf, 4 bits.
[    2.741616] libcxgbi:ddp_setup_host_page_size: system PAGE 4096, ddp i=
dx 0.
[    2.750128] Chelsio T3 iSCSI Driver cxgb3i v2.0.0 (Jun. 2010)
[    2.757506] iscsi: registered transport (cxgb3i)
[    2.763694] Chelsio T4 iSCSI Driver cxgb4i v0.9.1 (Aug. 2010)
[    2.771091] iscsi: registered transport (cxgb4i)
[    2.777285] Broadcom NetXtreme II iSCSI Driver bnx2i v2.7.0.3 (Jun 15,=
 2011)
[    2.785995] iscsi: registered transport (bnx2i)
[    2.792203] VMware PVSCSI driver - version 1.0.1.0-k
[    2.798865] st: Version 20101219, fixed bufsize 32768, s/g segs 256
[    2.806874] osst :I: Tape driver with OnStream support version 0.99.4
[    2.806875] osst :I: $Id: osst.c,v 1.73 2005/01/01 21:13:34 wriede Exp=
 $
[    2.824383] ACPI: PCI Interrupt Link [LSA0] enabled at IRQ 23
[    2.831832] sata_nv 0000:00:08.0: PCI INT A -> Link[LSA0] -> GSI 23 (l=
evel, low) -> IRQ 23
[    2.842347] scsi0 : sata_nv
[    2.847012] scsi1 : sata_nv
[    2.851689] ata1: SATA max UDMA/133 cmd 0xd400 ctl 0xd080 bmdma 0xc880=
 irq 23
[    2.860511] ata2: SATA max UDMA/133 cmd 0xd000 ctl 0xcc00 bmdma 0xc888=
 irq 23
[    2.869498] ACPI: PCI Interrupt Link [LSA1] enabled at IRQ 22
[    2.876971] sata_nv 0000:00:08.1: PCI INT B -> Link[LSA1] -> GSI 22 (l=
evel, low) -> IRQ 22
[    2.887543] scsi2 : sata_nv
[    2.892239] scsi3 : sata_nv
[    2.896962] ata3: SATA max UDMA/133 cmd 0xc800 ctl 0xc480 bmdma 0xc000=
 irq 22
[    2.905848] ata4: SATA max UDMA/133 cmd 0xc400 ctl 0xc080 bmdma 0xc008=
 irq 22
[    2.915861] scsi4 : pata_amd
[    2.920573] scsi5 : pata_amd
[    2.925602] ata5: PATA max UDMA/133 cmd 0x1f0 ctl 0x3f6 bmdma 0xffa0 i=
rq 14
[    2.934247] ata6: PATA max UDMA/133 cmd 0x170 ctl 0x376 bmdma 0xffa8 i=
rq 15
[    2.945422] Fixed MDIO Bus: probed
[    2.950710] cnic: Broadcom NetXtreme II CNIC Driver cnic v2.5.7 (July =
20, 2011)
[    2.959857] I2O subsystem v1.325
[    2.964718] i2o: max drivers =3D 8
[    2.969762] I2O Configuration OSM v1.323
[    2.975429] I2O Bus Adapter OSM v1.317
[    2.980809] I2O Block Device OSM v1.325
[    2.986398] I2O SCSI Peripheral OSM v1.316
[    2.992074] I2O ProcFS OSM v1.316
[    2.996939] Fusion MPT base driver 3.04.19
[    3.002520] Copyright (c) 1999-2008 LSI Corporation
[    3.008861] Fusion MPT SPI Host driver 3.04.19
[    3.014833] Fusion MPT FC Host driver 3.04.19
[    3.020702] Fusion MPT SAS Host driver 3.04.19
[    3.026628] Fusion MPT misc device (ioctl) driver 3.04.19
[    3.033523] mptctl: Registered with Fusion MPT base driver
[    3.040400] mptctl: /dev/mptctl @ (major,minor=3D10,220)
[    3.046911] Fusion MPT LAN driver 3.04.19
[    3.052496] Initializing USB Mass Storage driver...
[    3.058819] usbcore: registered new interface driver usb-storage
[    3.066186] USB Mass Storage support registered.
[    3.072219] usbcore: registered new interface driver libusual
[    3.079398] usbcore: registered new interface driver ums-alauda
[    3.086717] usbcore: registered new interface driver ums-cypress
[    3.105090] usbcore: registered new interface driver ums-datafab
[    3.112462] usbcore: registered new interface driver ums-freecom
[    3.119789] usbcore: registered new interface driver ums-isd200
[    3.126992] usbcore: registered new interface driver ums-jumpshot
[    3.134331] usbcore: registered new interface driver ums-karma
[    3.141421] usbcore: registered new interface driver ums-onetouch
[    3.148730] usbcore: registered new interface driver ums-sddr09
[    3.155860] usbcore: registered new interface driver ums-sddr55
[    3.162946] usbcore: registered new interface driver ums-usbat
[    3.169973] i8042: PNP: PS/2 Controller [PNP0303:PS2K] at 0x60,0x64 ir=
q 1
[    3.177831] i8042: PNP: PS/2 appears to have AUX port disabled, if thi=
s is incorrect please boot with i8042.nopnp
[    3.189426] serio: i8042 KBD port at 0x60,0x64 irq 1
[    3.195871] mousedev: PS/2 mouse device common for all mice
[    3.203218] rtc_cmos 00:02: RTC can wake from S4
[    3.209200] rtc_cmos 00:02: rtc core: registered rtc_cmos as rtc0
[    3.216538] rtc0: alarms up to one year, y3k, 114 bytes nvram, hpet ir=
qs
[    3.224468] md: linear personality registered for level -1
[    3.231145] md: raid0 personality registered for level 0
[    3.237631] md: raid1 personality registered for level 1
[    3.244079] md: raid10 personality registered for level 10
[    3.250682] md: raid6 personality registered for level 6
[    3.250758] input: AT Translated Set 2 keyboard as /devices/platform/i=
8042/serio0/input/input2
[    3.266905] md: raid5 personality registered for level 5
[    3.273415] md: raid4 personality registered for level 4
[    3.279915] md: multipath personality registered for level -4
[    3.286863] md: faulty personality registered for level -5
[    3.293858] device-mapper: ioctl: 4.21.0-ioctl (2011-07-06) initialise=
d: dm-devel@redhat.com
[    3.303861] cpuidle: using governor ladder
[    3.309246] cpuidle: using governor menu
[    3.314563] dcdbas dcdbas: Dell Systems Management Base Driver (versio=
n 5.6.0-3.2)
[    3.324981] usbcore: registered new interface driver usbhid
[    3.328052] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[    3.339381] usbhid: USB HID core driver
[    3.344747] TCP bic registered
[    3.349158] NET: Registered protocol family 17
[    3.355056] Registering the dns_resolver key type
[    3.373036] ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[    3.380554] ata1.00: ATA-7: ST3320620AS, 3.AAK, max UDMA/133
[    3.383170] ata3.00: ATAPI: TSSTcorp CDDVDW SH-S203B, SB00, max UDMA/1=
00
[    3.389164] ata3.00: configured for UDMA/100
[    3.401097] ata1.00: 625142448 sectors, multi 16: LBA48 NCQ (depth 0/3=
2)
[    3.448321] ata1.00: configured for UDMA/133
[    3.454155] scsi 0:0:0:0: Direct-Access     ATA      ST3320620AS      =
3.AA PQ: 0 ANSI: 5
[    3.464039] sd 0:0:0:0: [sda] 625142448 512-byte logical blocks: (320 =
GB/298 GiB)
[    3.473052] sd 0:0:0:0: [sda] Write Protect is off
[    3.479363] sd 0:0:0:0: Attached scsi generic sg0 type 0
[    3.479366] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enable=
d, doesn't support DPO or FUA
[    3.513012]  sda: sda1 sda2
[    3.517835] sd 0:0:0:0: [sda] Attached SCSI disk
[    3.950053] ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[    4.014122] ata2.00: ATAPI: TSSTcorpDVD-ROM SH-D163B, SB00, max UDMA/3=
3
[    4.066114] ata2.00: configured for UDMA/33
[    4.073557] scsi 1:0:0:0: CD-ROM            TSSTcorp DVD-ROM SH-D163B =
SB00 PQ: 0 ANSI: 5
[    4.085485] sr0: scsi3-mmc drive: 4x/48x cd/rw xa/form2 cdda tray
[    4.093176] cdrom: Uniform CD-ROM driver Revision: 3.20
[    4.100400] sr 1:0:0:0: Attached scsi generic sg1 type 5
[    4.108241] scsi 2:0:0:0: CD-ROM            TSSTcorp CDDVDW SH-S203B  =
SB00 PQ: 0 ANSI: 5
[    4.120617] sr1: scsi3-mmc drive: 48x/48x writer dvd-ram cd/rw xa/form=
2 cdda tray
[    4.130111] sr 2:0:0:0: Attached scsi generic sg2 type 5
[    4.450307] ata4: SATA link down (SStatus 0 SControl 300)
[    4.457449] registered taskstats version 1
[    4.478066] rtc_cmos 00:02: setting system clock to 2011-12-22 09:44:0=
0 UTC (1324547040)
[    4.487864] powernow-k8: Found 1 AMD Athlon(tm) 64 X2 Dual Core Proces=
sor 5200+ (2 cpu cores) (version 2.20.00)
[    4.499680] [Firmware Bug]: powernow-k8: No compatible ACPI _PSS objec=
ts found.
[    4.499682] [Firmware Bug]: powernow-k8: Try again with latest BIOS.
[    4.517194] Freeing unused kernel memory: 748k freed


--------------030803080705040100080906--

--------------ms000509080907080106070402
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Kryptografische Unterschrift

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFSjCC
BUYwggMuoAMCAQICAwhzEzANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4w
HAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmlu
ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMDA0
MDMxMjE2NDhaFw0xMjA0MDIxMjE2NDhaMEgxHDAaBgNVBAMTE0Zsb3JpYW4gTWFuc2Nod2V0
dXMxKDAmBgkqhkiG9w0BCQEWGUZsb3JpYW5NYW5zY2h3ZXR1c0BnbXguZGUwggEiMA0GCSqG
SIb3DQEBAQUAA4IBDwAwggEKAoIBAQDOx228LSNcMIRtatTC835J0dYDQbcsng06PdtewI0r
rwtxTSXndYotpjS257vzZOlIPMGRPUJL/FZgL7Nw8zaz2d/jCuQnzGgRukKefl2BZV4eW/xq
hrc5tStj1h7+jZyhtGtR1Jt4Y8TOXF/bjBFCoZRgrfo316LoP/zW1WY34UbW3E2hLpkbRkP7
4Tj6tgpH1TZl1UtA2skuL3GQ3+Mx/Wsh7hCNGAvrV+3BGkA5bZMrKRd1Trcz1Bla68m1WAas
xkNL/DbvgSWiIdyT7860wzcdKRS+ANlhtswsnwfj7arLNeBycQkiQeliFnQY2KBC9KZszkZ7
jdO1HgaEWKFLAgMBAAGjggEGMIIBAjAMBgNVHRMBAf8EAjAAMFYGCWCGSAGG+EIBDQRJFkdU
byBnZXQgeW91ciBvd24gY2VydGlmaWNhdGUgZm9yIEZSRUUgaGVhZCBvdmVyIHRvIGh0dHA6
Ly93d3cuQ0FjZXJ0Lm9yZzBABgNVHSUEOTA3BggrBgEFBQcDBAYIKwYBBQUHAwIGCisGAQQB
gjcKAwQGCisGAQQBgjcKAwMGCWCGSAGG+EIEATAyBggrBgEFBQcBAQQmMCQwIgYIKwYBBQUH
MAGGFmh0dHA6Ly9vY3NwLmNhY2VydC5vcmcwJAYDVR0RBB0wG4EZRmxvcmlhbk1hbnNjaHdl
dHVzQGdteC5kZTANBgkqhkiG9w0BAQUFAAOCAgEABTIxdlft8iVgfpvh+nR842ialjkFp5Fi
ow5HOGkTG1tcPczEOvApu8267JHwy390X8ZsOvxZt9QSNmGwKAeQuX1meNgRzXBWuGT5YjOH
2qtwLvXr2AIPaRB1U8Qu2iKEKqjOY8x9SBrU5cFqrN7iySlo7kvvq8DQub5BFLd6FMsCaxZI
Gyxd0FXVy57YEu/ZeknQutGS1NmGFc70hRe53DKILDh/bDO2r4yhvLOujJKjQf2kDkBoBZRI
MyACJiqxz7R+/Dog9zbqcqEiB2YCe1x8KFmgwfevrBH3+MyAhlg5lKA3DTq41kiwlpgC+unC
rgOfGoi1Y1IU/FoXgTil7G87L1IRrnVlcEcd6OiysFgwHsK6Y1ScVPoxJ3gmuqGsYDNlUxoH
U8wLRVexlTuQjCLr3kwbTUlrWfXw1b30Fkx1RludNrP8MO6vDFW4/8tOF9CApplTBZ/FpMhs
l2PF8suztvTobCuc7Z4DnqtfcqfPfcyNR610DaGOrp5eIjcn071z93qwzqOc0qxN1bcJZFM5
IAAKpvLLIlYzbK0fuHMb+xGFwCxjY6uQJrz77xpMu/bfS0LU5Xlzg+VfDFgpeUkY4tGS9e5v
qRyUN2es5+TRqNR0hmdRj3zxL1ogBtcLLHdvcxmna8n5yyHwU2eZkXEr0JW0uOT903skt/mC
/zUxggOUMIIDkAIBATCBgDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8v
d3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAf
BgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZwIDCHMTMAkGBSsOAwIaBQCgggHoMBgG
CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMTIyMjA5NDk0M1ow
IwYJKoZIhvcNAQkEMRYEFIed/oeB9gkzUIQSHFnFX8i+e4y3MF8GCSqGSIb3DQEJDzFSMFAw
CwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIB
QDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBkQYJKwYBBAGCNxAEMYGDMIGAMHkxEDAOBgNV
BAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZ
Q0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNl
cnQub3JnAgMIcxMwgZMGCyqGSIb3DQEJEAILMYGDoIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0Ex
HjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWdu
aW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMIcxMw
DQYJKoZIhvcNAQEBBQAEggEAwtFZtA9QpSTxp6SMKu+E4JxWtleKbpXSjcJmJq9/8oHFzY3b
OmiIomIP3krpFu6DVa/xGgn6CNnNRboOyywa/4BhQypEeb0RGQonES6wtGYREyuoBvBGG36t
t6yQcggnE8cUmrF110oCl/Wyju1p0Eo2Ssy9ds2Quo2e5bZ/5IHrBMvZtR5LJchg7c/VFOfG
uyiCbwcc6tjP4jTeri3+eAKvea6L3Q4sJ/h+YOudWw/T6nxpv6u7US+SDAYFo6MfxtK6ImgP
Cm2uIxoIuNMJFM5lh7p96yjRh9FFVxadt9FqXKl2D+LAUmIulSzgRKTzNFVYL+Yv70OARpJl
/lcg4wAAAAAAAA==
--------------ms000509080907080106070402--


--===============5591654311481353553==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============5591654311481353553==--


From xen-devel-bounces@lists.xensource.com Thu Dec 22 09:57:35 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 Dec 2011 09:57:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdfOf-0003xP-6F; Thu, 22 Dec 2011 09:57:09 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RdfOd-0003x4-97
	for xen-devel@lists.xensource.com; Thu, 22 Dec 2011 09:57:07 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1324547779!47725902!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Nzk5NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22693 invoked from network); 22 Dec 2011 09:56:19 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Dec 2011 09:56:19 -0000
X-IronPort-AV: E=Sophos;i="4.71,392,1320624000"; 
   d="scan'208";a="9627160"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Dec 2011 09:57:00 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 22 Dec 2011 09:57:00 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Thu, 22 Dec 2011 09:57:00 +0000
In-Reply-To: <4EF3018D020000780006986E@nat28.tlf.novell.com>
References: <4EF3018D020000780006986E@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1324547820.7877.71.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Jens Axboe <axboe@kernel.dk>, Jeremy Fitzhardinge <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"FlorianSchandinat@gmx.de" <FlorianSchandinat@gmx.de>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"dmitry.torokhov@gmail.com" <dmitry.torokhov@gmail.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Konrad Rzeszutek Wilk <konrad@darnok.org>,
	"davem@davemloft.net" <davem@davemloft.net>
Subject: Re: [Xen-devel] [PATCH,
 v2] Xen: consolidate and simplify struct xenbus_driver instantiation
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2011-12-22 at 09:08 +0000, Jan Beulich wrote:
> The 'name', 'owner', and 'mod_name' members are redundant with the
> identically named fields in the 'driver' sub-structure. Rather than
> switching each instance to specify these fields explicitly, introduce
> a macro to simplify this.
> 
> Eliminate further redundancy by allowing the drvname argument to
> DEFINE_XENBUS_DRIVER() to be blank (in which case the first entry from
> the ID table will be used for .driver.name).

Any reason not to always use DRV_NAME here (which is generally a bit
more specific e.g. "xen-foofront" rather than "foo") and rely on the id
table for the shorter names used in xenstore?

Empty parameters to macros always make me look twice, I think they
deserve at least a comment at which point you might as well just have
the actual desired string there.

Ian.

> Also eliminate the questionable xenbus_register_{back,front}end()
> wrappers - their sole remaining purpose was the checking of the
> 'owner' field, proper setting of which shouldn't be an issue anymore
> when the macro gets used.
> 
> v2: Restore DRV_NAME for the driver name in xen-pciback.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> Cc: Jens Axboe <axboe@kernel.dk>
> Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
> Cc: Ian Campbell <ian.campbell@citrix.com>
> Cc: David S. Miller <davem@davemloft.net>
> 
> ---
>  drivers/block/xen-blkback/xenbus.c         |    9 ++------
>  drivers/block/xen-blkfront.c               |   11 +++-------
>  drivers/input/misc/xen-kbdfront.c          |    7 +-----
>  drivers/net/xen-netback/xenbus.c           |    9 ++------
>  drivers/net/xen-netfront.c                 |    9 ++------
>  drivers/pci/xen-pcifront.c                 |   11 +++-------
>  drivers/video/xen-fbfront.c                |    9 ++------
>  drivers/xen/xen-pciback/xenbus.c           |   13 ++++--------
>  drivers/xen/xenbus/xenbus_probe.c          |    7 ------
>  drivers/xen/xenbus/xenbus_probe.h          |    4 ---
>  drivers/xen/xenbus/xenbus_probe_backend.c  |    8 ++-----
>  drivers/xen/xenbus/xenbus_probe_frontend.c |    8 ++-----
>  include/xen/xenbus.h                       |   31 ++++++++---------------------
>  13 files changed, 44 insertions(+), 92 deletions(-)
> 
> --- 3.2-rc6/drivers/block/xen-blkback/xenbus.c
> +++ 3.2-rc6-struct-xenbus_driver/drivers/block/xen-blkback/xenbus.c
> @@ -787,17 +787,14 @@ static const struct xenbus_device_id xen
>  };
> 
> 
> -static struct xenbus_driver xen_blkbk = {
> -       .name = "vbd",
> -       .owner = THIS_MODULE,
> -       .ids = xen_blkbk_ids,
> +static DEFINE_XENBUS_DRIVER(xen_blkbk, ,
>         .probe = xen_blkbk_probe,
>         .remove = xen_blkbk_remove,
>         .otherend_changed = frontend_changed
> -};
> +);
> 
> 
>  int xen_blkif_xenbus_init(void)
>  {
> -       return xenbus_register_backend(&xen_blkbk);
> +       return xenbus_register_backend(&xen_blkbk_driver);
>  }
> --- 3.2-rc6/drivers/block/xen-blkfront.c
> +++ 3.2-rc6-struct-xenbus_driver/drivers/block/xen-blkfront.c
> @@ -1437,16 +1437,13 @@ static const struct xenbus_device_id blk
>         { "" }
>  };
> 
> -static struct xenbus_driver blkfront = {
> -       .name = "vbd",
> -       .owner = THIS_MODULE,
> -       .ids = blkfront_ids,
> +static DEFINE_XENBUS_DRIVER(blkfront, ,
>         .probe = blkfront_probe,
>         .remove = blkfront_remove,
>         .resume = blkfront_resume,
>         .otherend_changed = blkback_changed,
>         .is_ready = blkfront_is_ready,
> -};
> +);
> 
>  static int __init xlblk_init(void)
>  {
> @@ -1461,7 +1458,7 @@ static int __init xlblk_init(void)
>                 return -ENODEV;
>         }
> 
> -       ret = xenbus_register_frontend(&blkfront);
> +       ret = xenbus_register_frontend(&blkfront_driver);
>         if (ret) {
>                 unregister_blkdev(XENVBD_MAJOR, DEV_NAME);
>                 return ret;
> @@ -1474,7 +1471,7 @@ module_init(xlblk_init);
> 
>  static void __exit xlblk_exit(void)
>  {
> -       return xenbus_unregister_driver(&blkfront);
> +       return xenbus_unregister_driver(&blkfront_driver);
>  }
>  module_exit(xlblk_exit);
> 
> --- 3.2-rc6/drivers/input/misc/xen-kbdfront.c
> +++ 3.2-rc6-struct-xenbus_driver/drivers/input/misc/xen-kbdfront.c
> @@ -361,15 +361,12 @@ static const struct xenbus_device_id xen
>         { "" }
>  };
> 
> -static struct xenbus_driver xenkbd_driver = {
> -       .name = "vkbd",
> -       .owner = THIS_MODULE,
> -       .ids = xenkbd_ids,
> +static DEFINE_XENBUS_DRIVER(xenkbd, ,
>         .probe = xenkbd_probe,
>         .remove = xenkbd_remove,
>         .resume = xenkbd_resume,
>         .otherend_changed = xenkbd_backend_changed,
> -};
> +);
> 
>  static int __init xenkbd_init(void)
>  {
> --- 3.2-rc6/drivers/net/xen-netback/xenbus.c
> +++ 3.2-rc6-struct-xenbus_driver/drivers/net/xen-netback/xenbus.c
> @@ -474,17 +474,14 @@ static const struct xenbus_device_id net
>  };
> 
> 
> -static struct xenbus_driver netback = {
> -       .name = "vif",
> -       .owner = THIS_MODULE,
> -       .ids = netback_ids,
> +static DEFINE_XENBUS_DRIVER(netback, ,
>         .probe = netback_probe,
>         .remove = netback_remove,
>         .uevent = netback_uevent,
>         .otherend_changed = frontend_changed,
> -};
> +);
> 
>  int xenvif_xenbus_init(void)
>  {
> -       return xenbus_register_backend(&netback);
> +       return xenbus_register_backend(&netback_driver);
>  }
> --- 3.2-rc6/drivers/net/xen-netfront.c
> +++ 3.2-rc6-struct-xenbus_driver/drivers/net/xen-netfront.c
> @@ -1910,7 +1910,7 @@ static void xennet_sysfs_delif(struct ne
> 
>  #endif /* CONFIG_SYSFS */
> 
> -static struct xenbus_device_id netfront_ids[] = {
> +static const struct xenbus_device_id netfront_ids[] = {
>         { "vif" },
>         { "" }
>  };
> @@ -1937,15 +1937,12 @@ static int __devexit xennet_remove(struc
>         return 0;
>  }
> 
> -static struct xenbus_driver netfront_driver = {
> -       .name = "vif",
> -       .owner = THIS_MODULE,
> -       .ids = netfront_ids,
> +static DEFINE_XENBUS_DRIVER(netfront, ,
>         .probe = netfront_probe,
>         .remove = __devexit_p(xennet_remove),
>         .resume = netfront_resume,
>         .otherend_changed = netback_changed,
> -};
> +);
> 
>  static int __init netif_init(void)
>  {
> --- 3.2-rc6/drivers/pci/xen-pcifront.c
> +++ 3.2-rc6-struct-xenbus_driver/drivers/pci/xen-pcifront.c
> @@ -1126,14 +1126,11 @@ static const struct xenbus_device_id xen
>         {""},
>  };
> 
> -static struct xenbus_driver xenbus_pcifront_driver = {
> -       .name                   = "pcifront",
> -       .owner                  = THIS_MODULE,
> -       .ids                    = xenpci_ids,
> +static DEFINE_XENBUS_DRIVER(xenpci, "pcifront",
>         .probe                  = pcifront_xenbus_probe,
>         .remove                 = pcifront_xenbus_remove,
>         .otherend_changed       = pcifront_backend_changed,
> -};
> +);
> 
>  static int __init pcifront_init(void)
>  {
> @@ -1142,12 +1139,12 @@ static int __init pcifront_init(void)
> 
>         pci_frontend_registrar(1 /* enable */);
> 
> -       return xenbus_register_frontend(&xenbus_pcifront_driver);
> +       return xenbus_register_frontend(&xenpci_driver);
>  }
> 
>  static void __exit pcifront_cleanup(void)
>  {
> -       xenbus_unregister_driver(&xenbus_pcifront_driver);
> +       xenbus_unregister_driver(&xenpci_driver);
>         pci_frontend_registrar(0 /* disable */);
>  }
>  module_init(pcifront_init);
> --- 3.2-rc6/drivers/video/xen-fbfront.c
> +++ 3.2-rc6-struct-xenbus_driver/drivers/video/xen-fbfront.c
> @@ -671,20 +671,17 @@ InitWait:
>         }
>  }
> 
> -static struct xenbus_device_id xenfb_ids[] = {
> +static const struct xenbus_device_id xenfb_ids[] = {
>         { "vfb" },
>         { "" }
>  };
> 
> -static struct xenbus_driver xenfb_driver = {
> -       .name = "vfb",
> -       .owner = THIS_MODULE,
> -       .ids = xenfb_ids,
> +static DEFINE_XENBUS_DRIVER(xenfb, ,
>         .probe = xenfb_probe,
>         .remove = xenfb_remove,
>         .resume = xenfb_resume,
>         .otherend_changed = xenfb_backend_changed,
> -};
> +);
> 
>  static int __init xenfb_init(void)
>  {
> --- 3.2-rc6/drivers/xen/xen-pciback/xenbus.c
> +++ 3.2-rc6-struct-xenbus_driver/drivers/xen/xen-pciback/xenbus.c
> @@ -707,19 +707,16 @@ static int xen_pcibk_xenbus_remove(struc
>         return 0;
>  }
> 
> -static const struct xenbus_device_id xenpci_ids[] = {
> +static const struct xenbus_device_id xen_pcibk_ids[] = {
>         {"pci"},
>         {""},
>  };
> 
> -static struct xenbus_driver xenbus_xen_pcibk_driver = {
> -       .name                   = DRV_NAME,
> -       .owner                  = THIS_MODULE,
> -       .ids                    = xenpci_ids,
> +static DEFINE_XENBUS_DRIVER(xen_pcibk, DRV_NAME,
>         .probe                  = xen_pcibk_xenbus_probe,
>         .remove                 = xen_pcibk_xenbus_remove,
>         .otherend_changed       = xen_pcibk_frontend_changed,
> -};
> +);
> 
>  const struct xen_pcibk_backend *__read_mostly xen_pcibk_backend;
> 
> @@ -735,11 +732,11 @@ int __init xen_pcibk_xenbus_register(voi
>         if (passthrough)
>                 xen_pcibk_backend = &xen_pcibk_passthrough_backend;
>         pr_info(DRV_NAME ": backend is %s\n", xen_pcibk_backend->name);
> -       return xenbus_register_backend(&xenbus_xen_pcibk_driver);
> +       return xenbus_register_backend(&xen_pcibk_driver);
>  }
> 
>  void __exit xen_pcibk_xenbus_unregister(void)
>  {
>         destroy_workqueue(xen_pcibk_wq);
> -       xenbus_unregister_driver(&xenbus_xen_pcibk_driver);
> +       xenbus_unregister_driver(&xen_pcibk_driver);
>  }
> --- 3.2-rc6/drivers/xen/xenbus/xenbus_probe.c
> +++ 3.2-rc6-struct-xenbus_driver/drivers/xen/xenbus/xenbus_probe.c
> @@ -291,14 +291,9 @@ void xenbus_dev_shutdown(struct device *
>  EXPORT_SYMBOL_GPL(xenbus_dev_shutdown);
> 
>  int xenbus_register_driver_common(struct xenbus_driver *drv,
> -                                 struct xen_bus_type *bus,
> -                                 struct module *owner,
> -                                 const char *mod_name)
> +                                 struct xen_bus_type *bus)
>  {
> -       drv->driver.name = drv->name;
>         drv->driver.bus = &bus->bus;
> -       drv->driver.owner = owner;
> -       drv->driver.mod_name = mod_name;
> 
>         return driver_register(&drv->driver);
>  }
> --- 3.2-rc6/drivers/xen/xenbus/xenbus_probe.h
> +++ 3.2-rc6-struct-xenbus_driver/drivers/xen/xenbus/xenbus_probe.h
> @@ -53,9 +53,7 @@ extern int xenbus_match(struct device *_
>  extern int xenbus_dev_probe(struct device *_dev);
>  extern int xenbus_dev_remove(struct device *_dev);
>  extern int xenbus_register_driver_common(struct xenbus_driver *drv,
> -                                        struct xen_bus_type *bus,
> -                                        struct module *owner,
> -                                        const char *mod_name);
> +                                        struct xen_bus_type *bus);
>  extern int xenbus_probe_node(struct xen_bus_type *bus,
>                              const char *type,
>                              const char *nodename);
> --- 3.2-rc6/drivers/xen/xenbus/xenbus_probe_backend.c
> +++ 3.2-rc6-struct-xenbus_driver/drivers/xen/xenbus/xenbus_probe_backend.c
> @@ -232,15 +232,13 @@ int xenbus_dev_is_online(struct xenbus_d
>  }
>  EXPORT_SYMBOL_GPL(xenbus_dev_is_online);
> 
> -int __xenbus_register_backend(struct xenbus_driver *drv,
> -                             struct module *owner, const char *mod_name)
> +int xenbus_register_backend(struct xenbus_driver *drv)
>  {
>         drv->read_otherend_details = read_frontend_details;
> 
> -       return xenbus_register_driver_common(drv, &xenbus_backend,
> -                                            owner, mod_name);
> +       return xenbus_register_driver_common(drv, &xenbus_backend);
>  }
> -EXPORT_SYMBOL_GPL(__xenbus_register_backend);
> +EXPORT_SYMBOL_GPL(xenbus_register_backend);
> 
>  static int backend_probe_and_watch(struct notifier_block *notifier,
>                                    unsigned long event,
> --- 3.2-rc6/drivers/xen/xenbus/xenbus_probe_frontend.c
> +++ 3.2-rc6-struct-xenbus_driver/drivers/xen/xenbus/xenbus_probe_frontend.c
> @@ -230,15 +230,13 @@ static void wait_for_devices(struct xenb
>                          print_device_status);
>  }
> 
> -int __xenbus_register_frontend(struct xenbus_driver *drv,
> -                              struct module *owner, const char *mod_name)
> +int xenbus_register_frontend(struct xenbus_driver *drv)
>  {
>         int ret;
> 
>         drv->read_otherend_details = read_backend_details;
> 
> -       ret = xenbus_register_driver_common(drv, &xenbus_frontend,
> -                                           owner, mod_name);
> +       ret = xenbus_register_driver_common(drv, &xenbus_frontend);
>         if (ret)
>                 return ret;
> 
> @@ -247,7 +245,7 @@ int __xenbus_register_frontend(struct xe
> 
>         return 0;
>  }
> -EXPORT_SYMBOL_GPL(__xenbus_register_frontend);
> +EXPORT_SYMBOL_GPL(xenbus_register_frontend);
> 
>  static DECLARE_WAIT_QUEUE_HEAD(backend_state_wq);
>  static int backend_state;
> --- 3.2-rc6/include/xen/xenbus.h
> +++ 3.2-rc6-struct-xenbus_driver/include/xen/xenbus.h
> @@ -85,8 +85,6 @@ struct xenbus_device_id
> 
>  /* A xenbus driver. */
>  struct xenbus_driver {
> -       char *name;
> -       struct module *owner;
>         const struct xenbus_device_id *ids;
>         int (*probe)(struct xenbus_device *dev,
>                      const struct xenbus_device_id *id);
> @@ -101,31 +99,20 @@ struct xenbus_driver {
>         int (*is_ready)(struct xenbus_device *dev);
>  };
> 
> -static inline struct xenbus_driver *to_xenbus_driver(struct device_driver *drv)
> -{
> -       return container_of(drv, struct xenbus_driver, driver);
> +#define DEFINE_XENBUS_DRIVER(var, drvname, methods...)         \
> +struct xenbus_driver var ## _driver = {                                \
> +       .driver.name = drvname + 0 ?: var ## _ids->devicetype,  \
> +       .driver.owner = THIS_MODULE,                            \
> +       .ids = var ## _ids, ## methods                          \
>  }
> 
> -int __must_check __xenbus_register_frontend(struct xenbus_driver *drv,
> -                                           struct module *owner,
> -                                           const char *mod_name);
> -
> -static inline int __must_check
> -xenbus_register_frontend(struct xenbus_driver *drv)
> +static inline struct xenbus_driver *to_xenbus_driver(struct device_driver *drv)
>  {
> -       WARN_ON(drv->owner != THIS_MODULE);
> -       return __xenbus_register_frontend(drv, THIS_MODULE, KBUILD_MODNAME);
> +       return container_of(drv, struct xenbus_driver, driver);
>  }
> 
> -int __must_check __xenbus_register_backend(struct xenbus_driver *drv,
> -                                          struct module *owner,
> -                                          const char *mod_name);
> -static inline int __must_check
> -xenbus_register_backend(struct xenbus_driver *drv)
> -{
> -       WARN_ON(drv->owner != THIS_MODULE);
> -       return __xenbus_register_backend(drv, THIS_MODULE, KBUILD_MODNAME);
> -}
> +int __must_check xenbus_register_frontend(struct xenbus_driver *);
> +int __must_check xenbus_register_backend(struct xenbus_driver *);
> 
>  void xenbus_unregister_driver(struct xenbus_driver *drv);
> 
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 22 09:57:35 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 Dec 2011 09:57:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdfOf-0003xP-6F; Thu, 22 Dec 2011 09:57:09 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RdfOd-0003x4-97
	for xen-devel@lists.xensource.com; Thu, 22 Dec 2011 09:57:07 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1324547779!47725902!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Nzk5NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22693 invoked from network); 22 Dec 2011 09:56:19 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Dec 2011 09:56:19 -0000
X-IronPort-AV: E=Sophos;i="4.71,392,1320624000"; 
   d="scan'208";a="9627160"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Dec 2011 09:57:00 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 22 Dec 2011 09:57:00 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Thu, 22 Dec 2011 09:57:00 +0000
In-Reply-To: <4EF3018D020000780006986E@nat28.tlf.novell.com>
References: <4EF3018D020000780006986E@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1324547820.7877.71.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Jens Axboe <axboe@kernel.dk>, Jeremy Fitzhardinge <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"FlorianSchandinat@gmx.de" <FlorianSchandinat@gmx.de>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"dmitry.torokhov@gmail.com" <dmitry.torokhov@gmail.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Konrad Rzeszutek Wilk <konrad@darnok.org>,
	"davem@davemloft.net" <davem@davemloft.net>
Subject: Re: [Xen-devel] [PATCH,
 v2] Xen: consolidate and simplify struct xenbus_driver instantiation
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2011-12-22 at 09:08 +0000, Jan Beulich wrote:
> The 'name', 'owner', and 'mod_name' members are redundant with the
> identically named fields in the 'driver' sub-structure. Rather than
> switching each instance to specify these fields explicitly, introduce
> a macro to simplify this.
> 
> Eliminate further redundancy by allowing the drvname argument to
> DEFINE_XENBUS_DRIVER() to be blank (in which case the first entry from
> the ID table will be used for .driver.name).

Any reason not to always use DRV_NAME here (which is generally a bit
more specific e.g. "xen-foofront" rather than "foo") and rely on the id
table for the shorter names used in xenstore?

Empty parameters to macros always make me look twice, I think they
deserve at least a comment at which point you might as well just have
the actual desired string there.

Ian.

> Also eliminate the questionable xenbus_register_{back,front}end()
> wrappers - their sole remaining purpose was the checking of the
> 'owner' field, proper setting of which shouldn't be an issue anymore
> when the macro gets used.
> 
> v2: Restore DRV_NAME for the driver name in xen-pciback.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> Cc: Jens Axboe <axboe@kernel.dk>
> Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
> Cc: Ian Campbell <ian.campbell@citrix.com>
> Cc: David S. Miller <davem@davemloft.net>
> 
> ---
>  drivers/block/xen-blkback/xenbus.c         |    9 ++------
>  drivers/block/xen-blkfront.c               |   11 +++-------
>  drivers/input/misc/xen-kbdfront.c          |    7 +-----
>  drivers/net/xen-netback/xenbus.c           |    9 ++------
>  drivers/net/xen-netfront.c                 |    9 ++------
>  drivers/pci/xen-pcifront.c                 |   11 +++-------
>  drivers/video/xen-fbfront.c                |    9 ++------
>  drivers/xen/xen-pciback/xenbus.c           |   13 ++++--------
>  drivers/xen/xenbus/xenbus_probe.c          |    7 ------
>  drivers/xen/xenbus/xenbus_probe.h          |    4 ---
>  drivers/xen/xenbus/xenbus_probe_backend.c  |    8 ++-----
>  drivers/xen/xenbus/xenbus_probe_frontend.c |    8 ++-----
>  include/xen/xenbus.h                       |   31 ++++++++---------------------
>  13 files changed, 44 insertions(+), 92 deletions(-)
> 
> --- 3.2-rc6/drivers/block/xen-blkback/xenbus.c
> +++ 3.2-rc6-struct-xenbus_driver/drivers/block/xen-blkback/xenbus.c
> @@ -787,17 +787,14 @@ static const struct xenbus_device_id xen
>  };
> 
> 
> -static struct xenbus_driver xen_blkbk = {
> -       .name = "vbd",
> -       .owner = THIS_MODULE,
> -       .ids = xen_blkbk_ids,
> +static DEFINE_XENBUS_DRIVER(xen_blkbk, ,
>         .probe = xen_blkbk_probe,
>         .remove = xen_blkbk_remove,
>         .otherend_changed = frontend_changed
> -};
> +);
> 
> 
>  int xen_blkif_xenbus_init(void)
>  {
> -       return xenbus_register_backend(&xen_blkbk);
> +       return xenbus_register_backend(&xen_blkbk_driver);
>  }
> --- 3.2-rc6/drivers/block/xen-blkfront.c
> +++ 3.2-rc6-struct-xenbus_driver/drivers/block/xen-blkfront.c
> @@ -1437,16 +1437,13 @@ static const struct xenbus_device_id blk
>         { "" }
>  };
> 
> -static struct xenbus_driver blkfront = {
> -       .name = "vbd",
> -       .owner = THIS_MODULE,
> -       .ids = blkfront_ids,
> +static DEFINE_XENBUS_DRIVER(blkfront, ,
>         .probe = blkfront_probe,
>         .remove = blkfront_remove,
>         .resume = blkfront_resume,
>         .otherend_changed = blkback_changed,
>         .is_ready = blkfront_is_ready,
> -};
> +);
> 
>  static int __init xlblk_init(void)
>  {
> @@ -1461,7 +1458,7 @@ static int __init xlblk_init(void)
>                 return -ENODEV;
>         }
> 
> -       ret = xenbus_register_frontend(&blkfront);
> +       ret = xenbus_register_frontend(&blkfront_driver);
>         if (ret) {
>                 unregister_blkdev(XENVBD_MAJOR, DEV_NAME);
>                 return ret;
> @@ -1474,7 +1471,7 @@ module_init(xlblk_init);
> 
>  static void __exit xlblk_exit(void)
>  {
> -       return xenbus_unregister_driver(&blkfront);
> +       return xenbus_unregister_driver(&blkfront_driver);
>  }
>  module_exit(xlblk_exit);
> 
> --- 3.2-rc6/drivers/input/misc/xen-kbdfront.c
> +++ 3.2-rc6-struct-xenbus_driver/drivers/input/misc/xen-kbdfront.c
> @@ -361,15 +361,12 @@ static const struct xenbus_device_id xen
>         { "" }
>  };
> 
> -static struct xenbus_driver xenkbd_driver = {
> -       .name = "vkbd",
> -       .owner = THIS_MODULE,
> -       .ids = xenkbd_ids,
> +static DEFINE_XENBUS_DRIVER(xenkbd, ,
>         .probe = xenkbd_probe,
>         .remove = xenkbd_remove,
>         .resume = xenkbd_resume,
>         .otherend_changed = xenkbd_backend_changed,
> -};
> +);
> 
>  static int __init xenkbd_init(void)
>  {
> --- 3.2-rc6/drivers/net/xen-netback/xenbus.c
> +++ 3.2-rc6-struct-xenbus_driver/drivers/net/xen-netback/xenbus.c
> @@ -474,17 +474,14 @@ static const struct xenbus_device_id net
>  };
> 
> 
> -static struct xenbus_driver netback = {
> -       .name = "vif",
> -       .owner = THIS_MODULE,
> -       .ids = netback_ids,
> +static DEFINE_XENBUS_DRIVER(netback, ,
>         .probe = netback_probe,
>         .remove = netback_remove,
>         .uevent = netback_uevent,
>         .otherend_changed = frontend_changed,
> -};
> +);
> 
>  int xenvif_xenbus_init(void)
>  {
> -       return xenbus_register_backend(&netback);
> +       return xenbus_register_backend(&netback_driver);
>  }
> --- 3.2-rc6/drivers/net/xen-netfront.c
> +++ 3.2-rc6-struct-xenbus_driver/drivers/net/xen-netfront.c
> @@ -1910,7 +1910,7 @@ static void xennet_sysfs_delif(struct ne
> 
>  #endif /* CONFIG_SYSFS */
> 
> -static struct xenbus_device_id netfront_ids[] = {
> +static const struct xenbus_device_id netfront_ids[] = {
>         { "vif" },
>         { "" }
>  };
> @@ -1937,15 +1937,12 @@ static int __devexit xennet_remove(struc
>         return 0;
>  }
> 
> -static struct xenbus_driver netfront_driver = {
> -       .name = "vif",
> -       .owner = THIS_MODULE,
> -       .ids = netfront_ids,
> +static DEFINE_XENBUS_DRIVER(netfront, ,
>         .probe = netfront_probe,
>         .remove = __devexit_p(xennet_remove),
>         .resume = netfront_resume,
>         .otherend_changed = netback_changed,
> -};
> +);
> 
>  static int __init netif_init(void)
>  {
> --- 3.2-rc6/drivers/pci/xen-pcifront.c
> +++ 3.2-rc6-struct-xenbus_driver/drivers/pci/xen-pcifront.c
> @@ -1126,14 +1126,11 @@ static const struct xenbus_device_id xen
>         {""},
>  };
> 
> -static struct xenbus_driver xenbus_pcifront_driver = {
> -       .name                   = "pcifront",
> -       .owner                  = THIS_MODULE,
> -       .ids                    = xenpci_ids,
> +static DEFINE_XENBUS_DRIVER(xenpci, "pcifront",
>         .probe                  = pcifront_xenbus_probe,
>         .remove                 = pcifront_xenbus_remove,
>         .otherend_changed       = pcifront_backend_changed,
> -};
> +);
> 
>  static int __init pcifront_init(void)
>  {
> @@ -1142,12 +1139,12 @@ static int __init pcifront_init(void)
> 
>         pci_frontend_registrar(1 /* enable */);
> 
> -       return xenbus_register_frontend(&xenbus_pcifront_driver);
> +       return xenbus_register_frontend(&xenpci_driver);
>  }
> 
>  static void __exit pcifront_cleanup(void)
>  {
> -       xenbus_unregister_driver(&xenbus_pcifront_driver);
> +       xenbus_unregister_driver(&xenpci_driver);
>         pci_frontend_registrar(0 /* disable */);
>  }
>  module_init(pcifront_init);
> --- 3.2-rc6/drivers/video/xen-fbfront.c
> +++ 3.2-rc6-struct-xenbus_driver/drivers/video/xen-fbfront.c
> @@ -671,20 +671,17 @@ InitWait:
>         }
>  }
> 
> -static struct xenbus_device_id xenfb_ids[] = {
> +static const struct xenbus_device_id xenfb_ids[] = {
>         { "vfb" },
>         { "" }
>  };
> 
> -static struct xenbus_driver xenfb_driver = {
> -       .name = "vfb",
> -       .owner = THIS_MODULE,
> -       .ids = xenfb_ids,
> +static DEFINE_XENBUS_DRIVER(xenfb, ,
>         .probe = xenfb_probe,
>         .remove = xenfb_remove,
>         .resume = xenfb_resume,
>         .otherend_changed = xenfb_backend_changed,
> -};
> +);
> 
>  static int __init xenfb_init(void)
>  {
> --- 3.2-rc6/drivers/xen/xen-pciback/xenbus.c
> +++ 3.2-rc6-struct-xenbus_driver/drivers/xen/xen-pciback/xenbus.c
> @@ -707,19 +707,16 @@ static int xen_pcibk_xenbus_remove(struc
>         return 0;
>  }
> 
> -static const struct xenbus_device_id xenpci_ids[] = {
> +static const struct xenbus_device_id xen_pcibk_ids[] = {
>         {"pci"},
>         {""},
>  };
> 
> -static struct xenbus_driver xenbus_xen_pcibk_driver = {
> -       .name                   = DRV_NAME,
> -       .owner                  = THIS_MODULE,
> -       .ids                    = xenpci_ids,
> +static DEFINE_XENBUS_DRIVER(xen_pcibk, DRV_NAME,
>         .probe                  = xen_pcibk_xenbus_probe,
>         .remove                 = xen_pcibk_xenbus_remove,
>         .otherend_changed       = xen_pcibk_frontend_changed,
> -};
> +);
> 
>  const struct xen_pcibk_backend *__read_mostly xen_pcibk_backend;
> 
> @@ -735,11 +732,11 @@ int __init xen_pcibk_xenbus_register(voi
>         if (passthrough)
>                 xen_pcibk_backend = &xen_pcibk_passthrough_backend;
>         pr_info(DRV_NAME ": backend is %s\n", xen_pcibk_backend->name);
> -       return xenbus_register_backend(&xenbus_xen_pcibk_driver);
> +       return xenbus_register_backend(&xen_pcibk_driver);
>  }
> 
>  void __exit xen_pcibk_xenbus_unregister(void)
>  {
>         destroy_workqueue(xen_pcibk_wq);
> -       xenbus_unregister_driver(&xenbus_xen_pcibk_driver);
> +       xenbus_unregister_driver(&xen_pcibk_driver);
>  }
> --- 3.2-rc6/drivers/xen/xenbus/xenbus_probe.c
> +++ 3.2-rc6-struct-xenbus_driver/drivers/xen/xenbus/xenbus_probe.c
> @@ -291,14 +291,9 @@ void xenbus_dev_shutdown(struct device *
>  EXPORT_SYMBOL_GPL(xenbus_dev_shutdown);
> 
>  int xenbus_register_driver_common(struct xenbus_driver *drv,
> -                                 struct xen_bus_type *bus,
> -                                 struct module *owner,
> -                                 const char *mod_name)
> +                                 struct xen_bus_type *bus)
>  {
> -       drv->driver.name = drv->name;
>         drv->driver.bus = &bus->bus;
> -       drv->driver.owner = owner;
> -       drv->driver.mod_name = mod_name;
> 
>         return driver_register(&drv->driver);
>  }
> --- 3.2-rc6/drivers/xen/xenbus/xenbus_probe.h
> +++ 3.2-rc6-struct-xenbus_driver/drivers/xen/xenbus/xenbus_probe.h
> @@ -53,9 +53,7 @@ extern int xenbus_match(struct device *_
>  extern int xenbus_dev_probe(struct device *_dev);
>  extern int xenbus_dev_remove(struct device *_dev);
>  extern int xenbus_register_driver_common(struct xenbus_driver *drv,
> -                                        struct xen_bus_type *bus,
> -                                        struct module *owner,
> -                                        const char *mod_name);
> +                                        struct xen_bus_type *bus);
>  extern int xenbus_probe_node(struct xen_bus_type *bus,
>                              const char *type,
>                              const char *nodename);
> --- 3.2-rc6/drivers/xen/xenbus/xenbus_probe_backend.c
> +++ 3.2-rc6-struct-xenbus_driver/drivers/xen/xenbus/xenbus_probe_backend.c
> @@ -232,15 +232,13 @@ int xenbus_dev_is_online(struct xenbus_d
>  }
>  EXPORT_SYMBOL_GPL(xenbus_dev_is_online);
> 
> -int __xenbus_register_backend(struct xenbus_driver *drv,
> -                             struct module *owner, const char *mod_name)
> +int xenbus_register_backend(struct xenbus_driver *drv)
>  {
>         drv->read_otherend_details = read_frontend_details;
> 
> -       return xenbus_register_driver_common(drv, &xenbus_backend,
> -                                            owner, mod_name);
> +       return xenbus_register_driver_common(drv, &xenbus_backend);
>  }
> -EXPORT_SYMBOL_GPL(__xenbus_register_backend);
> +EXPORT_SYMBOL_GPL(xenbus_register_backend);
> 
>  static int backend_probe_and_watch(struct notifier_block *notifier,
>                                    unsigned long event,
> --- 3.2-rc6/drivers/xen/xenbus/xenbus_probe_frontend.c
> +++ 3.2-rc6-struct-xenbus_driver/drivers/xen/xenbus/xenbus_probe_frontend.c
> @@ -230,15 +230,13 @@ static void wait_for_devices(struct xenb
>                          print_device_status);
>  }
> 
> -int __xenbus_register_frontend(struct xenbus_driver *drv,
> -                              struct module *owner, const char *mod_name)
> +int xenbus_register_frontend(struct xenbus_driver *drv)
>  {
>         int ret;
> 
>         drv->read_otherend_details = read_backend_details;
> 
> -       ret = xenbus_register_driver_common(drv, &xenbus_frontend,
> -                                           owner, mod_name);
> +       ret = xenbus_register_driver_common(drv, &xenbus_frontend);
>         if (ret)
>                 return ret;
> 
> @@ -247,7 +245,7 @@ int __xenbus_register_frontend(struct xe
> 
>         return 0;
>  }
> -EXPORT_SYMBOL_GPL(__xenbus_register_frontend);
> +EXPORT_SYMBOL_GPL(xenbus_register_frontend);
> 
>  static DECLARE_WAIT_QUEUE_HEAD(backend_state_wq);
>  static int backend_state;
> --- 3.2-rc6/include/xen/xenbus.h
> +++ 3.2-rc6-struct-xenbus_driver/include/xen/xenbus.h
> @@ -85,8 +85,6 @@ struct xenbus_device_id
> 
>  /* A xenbus driver. */
>  struct xenbus_driver {
> -       char *name;
> -       struct module *owner;
>         const struct xenbus_device_id *ids;
>         int (*probe)(struct xenbus_device *dev,
>                      const struct xenbus_device_id *id);
> @@ -101,31 +99,20 @@ struct xenbus_driver {
>         int (*is_ready)(struct xenbus_device *dev);
>  };
> 
> -static inline struct xenbus_driver *to_xenbus_driver(struct device_driver *drv)
> -{
> -       return container_of(drv, struct xenbus_driver, driver);
> +#define DEFINE_XENBUS_DRIVER(var, drvname, methods...)         \
> +struct xenbus_driver var ## _driver = {                                \
> +       .driver.name = drvname + 0 ?: var ## _ids->devicetype,  \
> +       .driver.owner = THIS_MODULE,                            \
> +       .ids = var ## _ids, ## methods                          \
>  }
> 
> -int __must_check __xenbus_register_frontend(struct xenbus_driver *drv,
> -                                           struct module *owner,
> -                                           const char *mod_name);
> -
> -static inline int __must_check
> -xenbus_register_frontend(struct xenbus_driver *drv)
> +static inline struct xenbus_driver *to_xenbus_driver(struct device_driver *drv)
>  {
> -       WARN_ON(drv->owner != THIS_MODULE);
> -       return __xenbus_register_frontend(drv, THIS_MODULE, KBUILD_MODNAME);
> +       return container_of(drv, struct xenbus_driver, driver);
>  }
> 
> -int __must_check __xenbus_register_backend(struct xenbus_driver *drv,
> -                                          struct module *owner,
> -                                          const char *mod_name);
> -static inline int __must_check
> -xenbus_register_backend(struct xenbus_driver *drv)
> -{
> -       WARN_ON(drv->owner != THIS_MODULE);
> -       return __xenbus_register_backend(drv, THIS_MODULE, KBUILD_MODNAME);
> -}
> +int __must_check xenbus_register_frontend(struct xenbus_driver *);
> +int __must_check xenbus_register_backend(struct xenbus_driver *);
> 
>  void xenbus_unregister_driver(struct xenbus_driver *drv);
> 
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 22 09:59:26 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 Dec 2011 09:59:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdfQb-000464-Oc; Thu, 22 Dec 2011 09:59:09 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1RdfQa-00045m-3y
	for xen-devel@lists.xensource.com; Thu, 22 Dec 2011 09:59:08 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1324547941!8369616!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMjkwMjgz\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16657 invoked from network); 22 Dec 2011 09:59:02 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-14.tower-21.messagelabs.com with SMTP;
	22 Dec 2011 09:59:02 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga101.jf.intel.com with ESMTP; 22 Dec 2011 01:59:01 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.67,352,1309762800"; d="scan'208";a="89277878"
Received: from pgsmsx602.gar.corp.intel.com ([10.221.43.81])
	by orsmga001.jf.intel.com with ESMTP; 22 Dec 2011 01:59:00 -0800
Received: from pgsmsx102.gar.corp.intel.com (10.221.44.80) by
	pgsmsx602.gar.corp.intel.com (10.221.43.81) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Thu, 22 Dec 2011 17:57:58 +0800
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	PGSMSX102.gar.corp.intel.com (10.221.44.80) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Thu, 22 Dec 2011 17:57:57 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.38]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.199]) with mapi id
	14.01.0355.002; Thu, 22 Dec 2011 17:57:56 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: "konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Thread-Topic: Linux 3.1.0 Xen RAS rebase
Thread-Index: AczAkC06XqGHtOYqROC3xMCYadWJeg==
Date: Thu, 22 Dec 2011 09:57:55 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC829233587C7@SHSMSX101.ccr.corp.intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "Jiang, Yunhong" <yunhong.jiang@intel.com>,
	"jeremy.fitzhardinge@citrix.com" <jeremy.fitzhardinge@citrix.com>
Subject: [Xen-devel] Linux 3.1.0 Xen RAS rebase
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Recently we did dom0 Xen RAS rebase work.

Basically it rebased from Jeremy's pvops (2.6.32), to Konrad's pvops (3.1.0, branch "devel/acpi-cpufreq.v3")
patch 1: for mcelog logic
patch 2: for dom0 vmce
patch 3: for cpu sysfs and cpu online/offline
patch 4: for cpu hotadd
patch 5: for memory hotadd prepare work
patch 6: for memory hotadd
patch 7: for cpu hotadd prepare work
patch 8: complement cpu hotadd lacked at Konrad's tree
patch 9: update PM logic
patch 10: upate cpu online/offline logic


Thanks,
Jinsong
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 22 09:59:26 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 Dec 2011 09:59:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdfQb-000464-Oc; Thu, 22 Dec 2011 09:59:09 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1RdfQa-00045m-3y
	for xen-devel@lists.xensource.com; Thu, 22 Dec 2011 09:59:08 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1324547941!8369616!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMjkwMjgz\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16657 invoked from network); 22 Dec 2011 09:59:02 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-14.tower-21.messagelabs.com with SMTP;
	22 Dec 2011 09:59:02 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga101.jf.intel.com with ESMTP; 22 Dec 2011 01:59:01 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.67,352,1309762800"; d="scan'208";a="89277878"
Received: from pgsmsx602.gar.corp.intel.com ([10.221.43.81])
	by orsmga001.jf.intel.com with ESMTP; 22 Dec 2011 01:59:00 -0800
Received: from pgsmsx102.gar.corp.intel.com (10.221.44.80) by
	pgsmsx602.gar.corp.intel.com (10.221.43.81) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Thu, 22 Dec 2011 17:57:58 +0800
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	PGSMSX102.gar.corp.intel.com (10.221.44.80) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Thu, 22 Dec 2011 17:57:57 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.38]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.199]) with mapi id
	14.01.0355.002; Thu, 22 Dec 2011 17:57:56 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: "konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Thread-Topic: Linux 3.1.0 Xen RAS rebase
Thread-Index: AczAkC06XqGHtOYqROC3xMCYadWJeg==
Date: Thu, 22 Dec 2011 09:57:55 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC829233587C7@SHSMSX101.ccr.corp.intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "Jiang, Yunhong" <yunhong.jiang@intel.com>,
	"jeremy.fitzhardinge@citrix.com" <jeremy.fitzhardinge@citrix.com>
Subject: [Xen-devel] Linux 3.1.0 Xen RAS rebase
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Recently we did dom0 Xen RAS rebase work.

Basically it rebased from Jeremy's pvops (2.6.32), to Konrad's pvops (3.1.0, branch "devel/acpi-cpufreq.v3")
patch 1: for mcelog logic
patch 2: for dom0 vmce
patch 3: for cpu sysfs and cpu online/offline
patch 4: for cpu hotadd
patch 5: for memory hotadd prepare work
patch 6: for memory hotadd
patch 7: for cpu hotadd prepare work
patch 8: complement cpu hotadd lacked at Konrad's tree
patch 9: update PM logic
patch 10: upate cpu online/offline logic


Thanks,
Jinsong
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 22 10:00:25 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 Dec 2011 10: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.xensource.com>)
	id 1RdfRR-0004B2-Ij; Thu, 22 Dec 2011 10:00:01 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1RdfRP-0004AO-G4
	for xen-devel@lists.xensource.com; Thu, 22 Dec 2011 10:00:00 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1324547990!6538900!1
X-Originating-IP: [134.134.136.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjQgPT4gMzE5NDEx\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16058 invoked from network); 22 Dec 2011 09:59:51 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-9.tower-174.messagelabs.com with SMTP;
	22 Dec 2011 09:59:51 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga102.jf.intel.com with ESMTP; 22 Dec 2011 01:59:49 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.67,352,1309762800"; d="scan'208,223";a="89278182"
Received: from pgsmsx602.gar.corp.intel.com ([10.221.43.81])
	by orsmga001.jf.intel.com with ESMTP; 22 Dec 2011 01:59:47 -0800
Received: from pgsmsx151.gar.corp.intel.com (172.30.236.41) by
	pgsmsx602.gar.corp.intel.com (10.221.43.81) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Thu, 22 Dec 2011 17:59:46 +0800
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	PGSMSX151.gar.corp.intel.com (172.30.236.41) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Thu, 22 Dec 2011 17:59:45 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.38]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.199]) with mapi id
	14.01.0355.002; Thu, 22 Dec 2011 17:59:44 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: "konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Thread-Topic: [PATCH 01/10] Add mcelog support from xen platform
Thread-Index: AczAkG036XwYNBn7SKyUXMKcFe2umw==
Date: Thu, 22 Dec 2011 09:59:43 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC829233589D0@SHSMSX101.ccr.corp.intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
Content-Type: multipart/mixed;
	boundary="_002_DE8DF0795D48FD4CA783C40EC829233589D0SHSMSX101ccrcorpint_"
MIME-Version: 1.0
Cc: "Jiang, Yunhong" <yunhong.jiang@intel.com>,
	"jeremy.fitzhardinge@citrix.com" <jeremy.fitzhardinge@citrix.com>
Subject: [Xen-devel] [PATCH 01/10] Add mcelog support from xen platform
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--_002_DE8DF0795D48FD4CA783C40EC829233589D0SHSMSX101ccrcorpint_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

>From 0e8de1ce0f13aa34aa6013e6a387ae5be78031ca Mon Sep 17 00:00:00 2001
From: Liu Jinsong <jinsong.liu@intel.com>
Date: Tue, 6 Dec 2011 18:08:12 +0800
Subject: [PATCH 01/10] Add mcelog support from xen platform

This patch backport from Jeremy's pvops commit a5ed1f3dae179158e385e9371462=
dd65d5e125c5,
which in turn backport from previous xen DOM0(2.6.18) cs: 75e5bfa7fbdc

When a MCE/CMCI error happens (or by polling), the related error
information will be sent to privileged pv-ops domain by XEN. This
patch will help to fetch the xen-logged information by hypercall
and then convert XEN-format log into Linux format MCELOG. It makes
using current available mcelog tools for native Linux possible.

With this patch, after mce/cmci error log information is sent to
pv-ops guest, Running mcelog tools in the guest, you will get same
detailed decoded mce information as in Native Linux.

Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
Signed-off-by: Ke, Liping <liping.ke@intel.com>
Signed-off-by: Jiang, Yunhong <yunhong.jiang@intel.com>
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
---
 arch/x86/include/asm/xen/hypercall.h |    8 +
 arch/x86/xen/enlighten.c             |    8 +-
 drivers/xen/Kconfig                  |    8 +
 drivers/xen/Makefile                 |    1 +
 drivers/xen/mcelog.c                 |  217 +++++++++++++++++
 include/xen/interface/xen-mca.h      |  429 ++++++++++++++++++++++++++++++=
++++
 6 files changed, 667 insertions(+), 4 deletions(-)
 create mode 100644 drivers/xen/mcelog.c
 create mode 100644 include/xen/interface/xen-mca.h

diff --git a/arch/x86/include/asm/xen/hypercall.h b/arch/x86/include/asm/xe=
n/hypercall.h
index 5728852..59c226d 100644
--- a/arch/x86/include/asm/xen/hypercall.h
+++ b/arch/x86/include/asm/xen/hypercall.h
@@ -48,6 +48,7 @@
 #include <xen/interface/sched.h>
 #include <xen/interface/physdev.h>
 #include <xen/interface/platform.h>
+#include <xen/interface/xen-mca.h>
=20
 /*
  * The hypercall asms have to meet several constraints:
@@ -302,6 +303,13 @@ HYPERVISOR_set_timer_op(u64 timeout)
 }
=20
 static inline int
+HYPERVISOR_mca(struct xen_mc *mc_op)
+{
+	mc_op->interface_version =3D XEN_MCA_INTERFACE_VERSION;
+	return _hypercall1(int, mca, mc_op);
+}
+
+static inline int
 HYPERVISOR_dom0_op(struct xen_platform_op *platform_op)
 {
 	platform_op->interface_version =3D XENPF_INTERFACE_VERSION;
diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index 9306320..b073e4c 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -242,14 +242,14 @@ static void __init xen_init_cpuid_mask(void)
 	unsigned int xsave_mask;
=20
 	cpuid_leaf1_edx_mask =3D
-		~((1 << X86_FEATURE_MCE)  |  /* disable MCE */
-		  (1 << X86_FEATURE_MCA)  |  /* disable MCA */
-		  (1 << X86_FEATURE_MTRR) |  /* disable MTRR */
+		~((1 << X86_FEATURE_MTRR) |  /* disable MTRR */
 		  (1 << X86_FEATURE_ACC));   /* thermal monitoring */
=20
 	if (!xen_initial_domain())
 		cpuid_leaf1_edx_mask &=3D
-			~((1 << X86_FEATURE_APIC) |  /* disable local APIC */
+			~((1 << X86_FEATURE_MCE)  |  /* disable MCE */
+			  (1 << X86_FEATURE_MCA)  |  /* disable MCA */
+			  (1 << X86_FEATURE_APIC) |  /* disable local APIC */
 			  (1 << X86_FEATURE_ACPI));  /* disable ACPI */
 	ax =3D 1;
 	xen_cpuid(&ax, &bx, &cx, &dx);
diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
index e8fb85f..eb2a327 100644
--- a/drivers/xen/Kconfig
+++ b/drivers/xen/Kconfig
@@ -117,6 +117,14 @@ config XEN_SYS_HYPERVISOR
 	 virtual environment, /sys/hypervisor will still be present,
 	 but will have no xen contents.
=20
+config XEN_MCE_LOG
+	bool "Xen platform mcelog"
+	depends on XEN_DOM0 && X86_64 && X86_MCE
+	default y
+	help
+	  Allow kernel fetching mce log from xen platform and
+	  converting it into linux mcelog format for mcelog tools
+
 config ACPI_PROCESSOR_XEN
 	tristate
 	depends on XEN_DOM0 && ACPI_PROCESSOR && CPU_FREQ
diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
index d42da53..405cce9 100644
--- a/drivers/xen/Makefile
+++ b/drivers/xen/Makefile
@@ -14,6 +14,7 @@ obj-$(CONFIG_XEN_GNTDEV)		+=3D xen-gntdev.o
 obj-$(CONFIG_XEN_GRANT_DEV_ALLOC)	+=3D xen-gntalloc.o
 obj-$(CONFIG_XENFS)			+=3D xenfs/
 obj-$(CONFIG_XEN_SYS_HYPERVISOR)	+=3D sys-hypervisor.o
+obj-$(CONFIG_XEN_MCE_LOG)		+=3D mcelog.o
 obj-$(CONFIG_XEN_PLATFORM_PCI)		+=3D xen-platform-pci.o
 obj-$(CONFIG_XEN_TMEM)			+=3D tmem.o
 obj-$(CONFIG_SWIOTLB_XEN)		+=3D swiotlb-xen.o
diff --git a/drivers/xen/mcelog.c b/drivers/xen/mcelog.c
new file mode 100644
index 0000000..892ca7b
--- /dev/null
+++ b/drivers/xen/mcelog.c
@@ -0,0 +1,217 @@
+/*************************************************************************=
*****
+ * mcelog.c
+ * Add Machine Check event Logging support in DOM0
+ *
+ * Driver for receiving and logging machine check event
+ *
+ * Copyright (c) 2008, 2009 Intel Corporation
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version 2
+ * as published by the Free Software Foundation; or, when distributed
+ * separately from the Linux kernel or incorporated into other
+ * software packages, subject to the following license:
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a=
 copy
+ * of this source file (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use, copy, modi=
fy,
+ * merge, publish, distribute, sublicense, and/or sell copies of the Softw=
are,
+ * and to permit persons to whom the Software is furnished to do so, subje=
ct to
+ * the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included=
 in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS=
 OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY=
,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL=
 THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEA=
LINGS
+ * IN THE SOFTWARE.
+ */
+
+#include <linux/module.h>
+#include <linux/init.h>
+#include <linux/types.h>
+#include <linux/kernel.h>
+#include <linux/slab.h>
+#include <xen/interface/xen.h>
+#include <asm/xen/hypervisor.h>
+#include <xen/events.h>
+#include <xen/interface/vcpu.h>
+#include <asm/xen/hypercall.h>
+#include <asm/mce.h>
+#include <xen/xen.h>
+
+static mc_info_t *g_mi;
+static mcinfo_logical_cpu_t *g_physinfo;
+static uint32_t ncpus;
+
+static int convert_log(struct mc_info *mi)
+{
+	struct mcinfo_common *mic =3D NULL;
+	struct mcinfo_global *mc_global;
+	struct mcinfo_bank *mc_bank;
+	struct mce m;
+	int i, found =3D 0;
+
+	x86_mcinfo_lookup(&mic, mi, MC_TYPE_GLOBAL);
+	WARN_ON(!mic);
+
+	mce_setup(&m);
+	mc_global =3D (struct mcinfo_global *)mic;
+	m.mcgstatus =3D mc_global->mc_gstatus;
+	m.apicid =3D mc_global->mc_apicid;
+	for (i =3D 0; i < ncpus; i++) {
+		if (g_physinfo[i].mc_apicid =3D=3D m.apicid) {
+			found =3D 1;
+			break;
+		}
+	}
+	WARN_ON(!found);
+
+	m.socketid =3D g_physinfo[i].mc_chipid;
+	m.cpu =3D m.extcpu =3D g_physinfo[i].mc_cpunr;
+	m.cpuvendor =3D (__u8)g_physinfo[i].mc_vendor;
+	m.mcgcap =3D g_physinfo[i].mc_msrvalues[0].value;
+	x86_mcinfo_lookup(&mic, mi, MC_TYPE_BANK);
+	do {
+		if (mic =3D=3D NULL || mic->size =3D=3D 0)
+			break;
+		if (mic->type =3D=3D MC_TYPE_BANK) {
+			mc_bank =3D (struct mcinfo_bank *)mic;
+			m.misc =3D mc_bank->mc_misc;
+			m.status =3D mc_bank->mc_status;
+			m.addr =3D mc_bank->mc_addr;
+			m.tsc =3D mc_bank->mc_tsc;
+			m.bank =3D mc_bank->mc_bank;
+			m.finished =3D 1;
+			/*log this record*/
+			mce_log(&m);
+		}
+		mic =3D x86_mcinfo_next(mic);
+	} while (1);
+
+	return 0;
+}
+
+/*pv_ops domain mce virq handler, logging physical mce error info*/
+static irqreturn_t mce_dom_interrupt(int irq, void *dev_id)
+{
+	xen_mc_t mc_op;
+	int result =3D 0;
+
+	mc_op.cmd =3D XEN_MC_fetch;
+	mc_op.interface_version =3D XEN_MCA_INTERFACE_VERSION;
+	set_xen_guest_handle(mc_op.u.mc_fetch.data, g_mi);
+urgent:
+	mc_op.u.mc_fetch.flags =3D XEN_MC_URGENT;
+	result =3D HYPERVISOR_mca(&mc_op);
+	if (result || mc_op.u.mc_fetch.flags & XEN_MC_NODATA ||
+			mc_op.u.mc_fetch.flags & XEN_MC_FETCHFAILED)
+		goto nonurgent;
+	else {
+		result =3D convert_log(g_mi);
+		if (result)
+			goto end;
+		/* After fetching the error event log entry from DOM0,
+		 * we need to dec the refcnt and release the entry.
+		 * The entry is reserved and inc refcnt when filling
+		 * the error log entry.
+		 */
+		mc_op.u.mc_fetch.flags =3D XEN_MC_URGENT | XEN_MC_ACK;
+		result =3D HYPERVISOR_mca(&mc_op);
+		goto urgent;
+	}
+nonurgent:
+	mc_op.u.mc_fetch.flags =3D XEN_MC_NONURGENT;
+	result =3D HYPERVISOR_mca(&mc_op);
+	if (result || mc_op.u.mc_fetch.flags & XEN_MC_NODATA ||
+			mc_op.u.mc_fetch.flags & XEN_MC_FETCHFAILED)
+		goto end;
+	else {
+		result =3D convert_log(g_mi);
+		if (result)
+			goto end;
+		/* After fetching the error event log entry from DOM0,
+		 * we need to dec the refcnt and release the entry. The
+		 * entry is reserved and inc refcnt when filling the
+		 * error log entry.
+		 */
+		mc_op.u.mc_fetch.flags =3D XEN_MC_NONURGENT | XEN_MC_ACK;
+		result =3D HYPERVISOR_mca(&mc_op);
+		goto nonurgent;
+	}
+end:
+	return IRQ_HANDLED;
+}
+
+static int bind_virq_for_mce(void)
+{
+	int ret;
+	xen_mc_t mc_op;
+
+	g_mi =3D kmalloc(sizeof(struct mc_info), GFP_KERNEL);
+
+	if (!g_mi)
+		return -ENOMEM;
+
+	/* Fetch physical CPU Numbers */
+	mc_op.cmd =3D XEN_MC_physcpuinfo;
+	mc_op.interface_version =3D XEN_MCA_INTERFACE_VERSION;
+	set_xen_guest_handle(mc_op.u.mc_physcpuinfo.info, g_physinfo);
+	ret =3D HYPERVISOR_mca(&mc_op);
+	if (ret) {
+		printk(KERN_ERR "MCE_DOM0_LOG: Fail to get physical CPU numbers\n");
+		kfree(g_mi);
+		return ret;
+	}
+
+	/* Fetch each CPU Physical Info for later reference*/
+	ncpus =3D mc_op.u.mc_physcpuinfo.ncpus;
+	g_physinfo =3D kmalloc(sizeof(struct mcinfo_logical_cpu)*ncpus,
+					GFP_KERNEL);
+	if (!g_physinfo) {
+		kfree(g_mi);
+		return -ENOMEM;
+	}
+	set_xen_guest_handle(mc_op.u.mc_physcpuinfo.info, g_physinfo);
+	ret =3D HYPERVISOR_mca(&mc_op);
+	if (ret) {
+		printk(KERN_ERR "MCE_DOM0_LOG: Fail to get physical CPUs info\n");
+		kfree(g_mi);
+		kfree(g_physinfo);
+		return ret;
+	}
+
+	ret  =3D bind_virq_to_irqhandler(VIRQ_MCA, 0,
+		mce_dom_interrupt, 0, "mce", NULL);
+
+	if (ret < 0) {
+		printk(KERN_ERR "MCE_DOM0_LOG: bind_virq for DOM0 failed\n");
+		return ret;
+	}
+
+	return 0;
+}
+
+static int __init mcelog_init(void)
+{
+	/* Only DOM0 is responsible for MCE logging */
+	if (xen_initial_domain())
+		return bind_virq_for_mce();
+
+	return 0;
+}
+
+
+static void __exit mcelog_cleanup(void)
+{
+	kfree(g_mi);
+	kfree(g_physinfo);
+}
+module_init(mcelog_init);
+module_exit(mcelog_cleanup);
+
+MODULE_LICENSE("GPL");
diff --git a/include/xen/interface/xen-mca.h b/include/xen/interface/xen-mc=
a.h
new file mode 100644
index 0000000..f31fdab
--- /dev/null
+++ b/include/xen/interface/xen-mca.h
@@ -0,0 +1,429 @@
+/*************************************************************************=
*****
+ * arch-x86/mca.h
+ *
+ * Contributed by Advanced Micro Devices, Inc.
+ * Author: Christoph Egger <Christoph.Egger@amd.com>
+ *
+ * Guest OS machine check interface to x86 Xen.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a=
 copy
+ * of this software and associated documentation files (the "Software"), t=
o
+ * deal in the Software without restriction, including without limitation =
the
+ * rights to use, copy, modify, merge, publish, distribute, sublicense, an=
d/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.
+ */
+
+/* Full MCA functionality has the following Usecases from the guest side:
+ *
+ * Must have's:
+ * 1. Dom0 and DomU register machine check trap callback handlers
+ *    (already done via "set_trap_table" hypercall)
+ * 2. Dom0 registers machine check event callback handler
+ *    (doable via EVTCHNOP_bind_virq)
+ * 3. Dom0 and DomU fetches machine check data
+ * 4. Dom0 wants Xen to notify a DomU
+ * 5. Dom0 gets DomU ID from physical address
+ * 6. Dom0 wants Xen to kill DomU (already done for "xm destroy")
+ *
+ * Nice to have's:
+ * 7. Dom0 wants Xen to deactivate a physical CPU
+ *    This is better done as separate task, physical CPU hotplugging,
+ *    and hypercall(s) should be sysctl's
+ * 8. Page migration proposed from Xen NUMA work, where Dom0 can tell Xen =
to
+ *    move a DomU (or Dom0 itself) away from a malicious page
+ *    producing correctable errors.
+ * 9. offlining physical page:
+ *    Xen free's and never re-uses a certain physical page.
+ * 10. Testfacility: Allow Dom0 to write values into machine check MSR's
+ *     and tell Xen to trigger a machine check
+ */
+
+#ifndef __XEN_PUBLIC_ARCH_X86_MCA_H__
+#define __XEN_PUBLIC_ARCH_X86_MCA_H__
+
+/* Hypercall */
+#define __HYPERVISOR_mca __HYPERVISOR_arch_0
+
+/*
+ * The xen-unstable repo has interface version 0x03000001; out interface
+ * is incompatible with that and any future minor revisions, so we
+ * choose a different version number range that is numerically less
+ * than that used in xen-unstable.
+ */
+#define XEN_MCA_INTERFACE_VERSION 0x01ecc003
+
+/* IN: Dom0 calls hypercall to retrieve nonurgent error log entry */
+#define XEN_MC_NONURGENT  0x0001
+/* IN: Dom0/DomU calls hypercall to retrieve urgent error log entry */
+#define XEN_MC_URGENT     0x0002
+/* IN: Dom0 acknowledges previosly-fetched error log entry */
+#define XEN_MC_ACK        0x0004
+
+/* OUT: All is ok */
+#define XEN_MC_OK           0x0
+/* OUT: Domain could not fetch data. */
+#define XEN_MC_FETCHFAILED  0x1
+/* OUT: There was no machine check data to fetch. */
+#define XEN_MC_NODATA       0x2
+/* OUT: Between notification time and this hypercall an other
+ *  (most likely) correctable error happened. The fetched data,
+ *  does not match the original machine check data. */
+#define XEN_MC_NOMATCH      0x4
+
+/* OUT: DomU did not register MC NMI handler. Try something else. */
+#define XEN_MC_CANNOTHANDLE 0x8
+/* OUT: Notifying DomU failed. Retry later or try something else. */
+#define XEN_MC_NOTDELIVERED 0x10
+/* Note, XEN_MC_CANNOTHANDLE and XEN_MC_NOTDELIVERED are mutually exclusiv=
e. */
+
+
+#ifndef __ASSEMBLY__
+
+#define VIRQ_MCA VIRQ_ARCH_0 /* G. (DOM0) Machine Check Architecture */
+
+/*
+ * Machine Check Architecure:
+ * structs are read-only and used to report all kinds of
+ * correctable and uncorrectable errors detected by the HW.
+ * Dom0 and DomU: register a handler to get notified.
+ * Dom0 only: Correctable errors are reported via VIRQ_MCA
+ */
+#define MC_TYPE_GLOBAL          0
+#define MC_TYPE_BANK            1
+#define MC_TYPE_EXTENDED        2
+#define MC_TYPE_RECOVERY        3
+
+struct mcinfo_common {
+	uint16_t type;      /* structure type */
+	uint16_t size;      /* size of this struct in bytes */
+};
+
+
+#define MC_FLAG_CORRECTABLE     (1 << 0)
+#define MC_FLAG_UNCORRECTABLE   (1 << 1)
+#define MC_FLAG_RECOVERABLE	(1 << 2)
+#define MC_FLAG_POLLED		(1 << 3)
+#define MC_FLAG_RESET		(1 << 4)
+#define MC_FLAG_CMCI		(1 << 5)
+#define MC_FLAG_MCE		(1 << 6)
+/* contains global x86 mc information */
+struct mcinfo_global {
+	struct mcinfo_common common;
+
+	/* running domain at the time in error (most likely
+	 * the impacted one) */
+	uint16_t mc_domid;
+	uint16_t mc_vcpuid; /* virtual cpu scheduled for mc_domid */
+	uint32_t mc_socketid; /* physical socket of the physical core */
+	uint16_t mc_coreid; /* physical impacted core */
+	uint16_t mc_core_threadid; /* core thread of physical core */
+	uint32_t mc_apicid;
+	uint32_t mc_flags;
+	uint64_t mc_gstatus; /* global status */
+};
+
+/* contains bank local x86 mc information */
+struct mcinfo_bank {
+	struct mcinfo_common common;
+
+	uint16_t mc_bank; /* bank nr */
+	uint16_t mc_domid; /* Usecase 5: domain referenced by mc_addr on
+			* privileged pv-ops dom and if mc_addr is valid.
+			* Never valid on DomU. */
+	uint64_t mc_status; /* bank status */
+	uint64_t mc_addr;   /* bank address, only valid
+					 * if addr bit is set in mc_status */
+	uint64_t mc_misc;
+	uint64_t mc_ctrl2;
+	uint64_t mc_tsc;
+};
+
+
+struct mcinfo_msr {
+	uint64_t reg;   /* MSR */
+	uint64_t value; /* MSR value */
+};
+
+/* contains mc information from other
+ * or additional mc MSRs */
+struct mcinfo_extended {
+	struct mcinfo_common common;
+
+	/* You can fill up to five registers.
+	 * If you need more, then use this structure
+	 * multiple times. */
+
+	uint32_t mc_msrs; /* Number of msr with valid values. */
+	/*
+	 * Currently Intel extended MSR (32/64) include all gp registers
+	 * and E(R)FLAGS, E(R)IP, E(R)MISC, up to 11/19 of them might be
+	 * useful at present. So expand this array to 16/32 to leave room.
+	 */
+	struct mcinfo_msr mc_msr[sizeof(void *) * 4];
+};
+
+/* Recovery Action flags. Giving recovery result information to DOM0 */
+
+/* Xen takes successful recovery action, the error is recovered */
+#define REC_ACTION_RECOVERED (0x1 << 0)
+/* No action is performed by XEN */
+#define REC_ACTION_NONE (0x1 << 1)
+/* It's possible DOM0 might take action ownership in some case */
+#define REC_ACTION_NEED_RESET (0x1 << 2)
+
+/* Different Recovery Action types, if the action is performed successfull=
y,
+ * REC_ACTION_RECOVERED flag will be returned.
+ */
+
+/* Page Offline Action */
+#define MC_ACTION_PAGE_OFFLINE (0x1 << 0)
+/* CPU offline Action */
+#define MC_ACTION_CPU_OFFLINE (0x1 << 1)
+/* L3 cache disable Action */
+#define MC_ACTION_CACHE_SHRINK (0x1 << 2)
+
+/* Below interface used between XEN/DOM0 for passing XEN's recovery action
+ * information to DOM0.
+ * usage Senario: After offlining broken page, XEN might pass its page off=
line
+ * recovery action result to DOM0. DOM0 will save the information in
+ * non-volatile memory for further proactive actions, such as offlining th=
e
+ * easy broken page earlier when doing next reboot.
+*/
+struct page_offline_action {
+	/* Params for passing the offlined page number to DOM0 */
+	uint64_t mfn;
+	uint64_t status;
+};
+
+struct cpu_offline_action {
+	/* Params for passing the identity of the offlined CPU to DOM0 */
+	uint32_t mc_socketid;
+	uint16_t mc_coreid;
+	uint16_t mc_core_threadid;
+};
+
+#define MAX_UNION_SIZE 16
+struct mcinfo_recovery {
+	struct mcinfo_common common;
+	uint16_t mc_bank; /* bank nr */
+	/* Recovery Action Flags defined above such as REC_ACTION_DONE */
+	uint8_t action_flags;
+	/* Recovery Action types defined above such as MC_ACTION_PAGE_OFFLINE */
+	uint8_t action_types;
+	/* In future if more than one recovery action permitted per error bank,
+	 * a mcinfo_recovery data array will be returned
+	 */
+	union {
+		struct page_offline_action page_retire;
+		struct cpu_offline_action cpu_offline;
+		uint8_t pad[MAX_UNION_SIZE];
+	} action_info;
+};
+
+
+#define MCINFO_HYPERCALLSIZE	1024
+#define MCINFO_MAXSIZE		768
+
+struct mc_info {
+	/* Number of mcinfo_* entries in mi_data */
+	uint32_t mi_nentries;
+	uint32_t _pad0;
+	uint64_t mi_data[(MCINFO_MAXSIZE - 1) / 8];
+};
+typedef struct mc_info mc_info_t;
+DEFINE_GUEST_HANDLE_STRUCT(mc_info);
+
+#define __MC_MSR_ARRAYSIZE 8
+#define __MC_NMSRS 1
+#define MC_NCAPS	7	/* 7 CPU feature flag words */
+#define MC_CAPS_STD_EDX	0	/* cpuid level 0x00000001 (%edx) */
+#define MC_CAPS_AMD_EDX	1	/* cpuid level 0x80000001 (%edx) */
+#define MC_CAPS_TM	2	/* cpuid level 0x80860001 (TransMeta) */
+#define MC_CAPS_LINUX	3	/* Linux-defined */
+#define MC_CAPS_STD_ECX	4	/* cpuid level 0x00000001 (%ecx) */
+#define MC_CAPS_VIA	5	/* cpuid level 0xc0000001 */
+#define MC_CAPS_AMD_ECX	6	/* cpuid level 0x80000001 (%ecx) */
+
+struct mcinfo_logical_cpu {
+	uint32_t mc_cpunr;
+	uint32_t mc_chipid;
+	uint16_t mc_coreid;
+	uint16_t mc_threadid;
+	uint32_t mc_apicid;
+	uint32_t mc_clusterid;
+	uint32_t mc_ncores;
+	uint32_t mc_ncores_active;
+	uint32_t mc_nthreads;
+	int32_t mc_cpuid_level;
+	uint32_t mc_family;
+	uint32_t mc_vendor;
+	uint32_t mc_model;
+	uint32_t mc_step;
+	char mc_vendorid[16];
+	char mc_brandid[64];
+	uint32_t mc_cpu_caps[MC_NCAPS];
+	uint32_t mc_cache_size;
+	uint32_t mc_cache_alignment;
+	int32_t mc_nmsrvals;
+	struct mcinfo_msr mc_msrvalues[__MC_MSR_ARRAYSIZE];
+};
+typedef struct mcinfo_logical_cpu mcinfo_logical_cpu_t;
+DEFINE_GUEST_HANDLE_STRUCT(mcinfo_logical_cpu);
+
+
+/*
+ * OS's should use these instead of writing their own lookup function
+ * each with its own bugs and drawbacks.
+ * We use macros instead of static inline functions to allow guests
+ * to include this header in assembly files (*.S).
+ */
+/* Prototype:
+ *    uint32_t x86_mcinfo_nentries(struct mc_info *mi);
+ */
+#define x86_mcinfo_nentries(_mi)    \
+    ((_mi)->mi_nentries)
+/* Prototype:
+ *    struct mcinfo_common *x86_mcinfo_first(struct mc_info *mi);
+ */
+#define x86_mcinfo_first(_mi)       \
+    ((struct mcinfo_common *)(_mi)->mi_data)
+/* Prototype:
+ *    struct mcinfo_common *x86_mcinfo_next(struct mcinfo_common *mic);
+ */
+#define x86_mcinfo_next(_mic)       \
+    ((struct mcinfo_common *)((uint8_t *)(_mic) + (_mic)->size))
+
+/* Prototype:
+ *    void x86_mcinfo_lookup(void *ret, struct mc_info *mi, uint16_t type)=
;
+ */
+
+static inline void x86_mcinfo_lookup
+	(struct mcinfo_common **ret, struct mc_info *mi, uint16_t type)
+{
+	uint32_t found =3D 0, i;
+	struct mcinfo_common *mic;
+
+	*ret =3D NULL;
+	if (!mi)
+		return;
+	mic =3D x86_mcinfo_first(mi);
+
+	for (i =3D 0; i < x86_mcinfo_nentries(mi); i++) {
+		if (mic->type =3D=3D type) {
+			found =3D 1;
+			break;
+		}
+		mic =3D x86_mcinfo_next(mic);
+	}
+
+	*ret =3D found ? mic : NULL;
+}
+/* Usecase 1
+ * Register machine check trap callback handler
+ *    (already done via "set_trap_table" hypercall)
+ */
+
+/* Usecase 2
+ * Dom0 registers machine check event callback handler
+ * done by EVTCHNOP_bind_virq
+ */
+
+/* Usecase 3
+ * Fetch machine check data from hypervisor.
+ * Note, this hypercall is special, because both Dom0 and DomU must use th=
is.
+ */
+#define XEN_MC_fetch            1
+struct xen_mc_fetch {
+    /* IN/OUT variables.
+	 * IN: XEN_MC_NONURGENT, XEN_MC_URGENT,
+	 * XEN_MC_ACK if ack'king an earlier fetch
+	 * OUT: XEN_MC_OK, XEN_MC_FETCHAILED,
+	 * XEN_MC_NODATA, XEN_MC_NOMATCH
+	*/
+	uint32_t flags;
+	uint32_t _pad0;
+	/* OUT: id for ack, IN: id we are ack'ing */
+	uint64_t fetch_id;
+
+	/* OUT variables. */
+	GUEST_HANDLE(mc_info) data;
+};
+typedef struct xen_mc_fetch xen_mc_fetch_t;
+DEFINE_GUEST_HANDLE_STRUCT(xen_mc_fetch);
+
+
+/* Usecase 4
+ * This tells the hypervisor to notify a DomU about the machine check erro=
r
+ */
+#define XEN_MC_notifydomain     2
+struct xen_mc_notifydomain {
+	/* IN variables. */
+	uint16_t mc_domid;/* The unprivileged domain to notify. */
+	uint16_t mc_vcpuid;/* The vcpu in mc_domid to notify.
+			* Usually echo'd value from the fetch hypercall. */
+
+	/* IN/OUT variables. */
+	uint32_t flags;
+
+/* OUT: XEN_MC_OK, XEN_MC_CANNOTHANDLE, XEN_MC_NOTDELIVERED, XEN_MC_NOMATC=
H */
+};
+typedef struct xen_mc_notifydomain xen_mc_notifydomain_t;
+DEFINE_GUEST_HANDLE_STRUCT(xen_mc_notifydomain);
+
+#define XEN_MC_physcpuinfo 3
+struct xen_mc_physcpuinfo {
+	/* IN/OUT */
+	uint32_t ncpus;
+	uint32_t _pad0;
+	/* OUT */
+	GUEST_HANDLE(mcinfo_logical_cpu) info;
+};
+
+#define XEN_MC_msrinject    4
+#define MC_MSRINJ_MAXMSRS       8
+struct xen_mc_msrinject {
+	/* IN */
+	uint32_t mcinj_cpunr;/* target processor id */
+	uint32_t mcinj_flags;/* see MC_MSRINJ_F_* below */
+	uint32_t mcinj_count;/* 0 .. count-1 in array are valid */
+	uint32_t _pad0;
+	struct mcinfo_msr mcinj_msr[MC_MSRINJ_MAXMSRS];
+};
+
+/* Flags for mcinj_flags above; bits 16-31 are reserved */
+#define MC_MSRINJ_F_INTERPOSE   0x1
+
+#define XEN_MC_mceinject    5
+struct xen_mc_mceinject {
+	unsigned int mceinj_cpunr;      /* target processor id */
+};
+
+struct xen_mc {
+	uint32_t cmd;
+	uint32_t interface_version; /* XEN_MCA_INTERFACE_VERSION */
+	union {
+		struct xen_mc_fetch        mc_fetch;
+		struct xen_mc_notifydomain mc_notifydomain;
+		struct xen_mc_physcpuinfo  mc_physcpuinfo;
+		struct xen_mc_msrinject    mc_msrinject;
+		struct xen_mc_mceinject    mc_mceinject;
+	} u;
+};
+typedef struct xen_mc xen_mc_t;
+DEFINE_GUEST_HANDLE_STRUCT(xen_mc);
+
+#endif /* __ASSEMBLY__ */
+
+#endif /* __XEN_PUBLIC_ARCH_X86_MCA_H__ */
--=20
1.6.5.6

--_002_DE8DF0795D48FD4CA783C40EC829233589D0SHSMSX101ccrcorpint_
Content-Type: application/octet-stream;
	name="0001-Add-mcelog-support-from-xen-platform.patch"
Content-Description: 0001-Add-mcelog-support-from-xen-platform.patch
Content-Disposition: attachment;
	filename="0001-Add-mcelog-support-from-xen-platform.patch"; size=25075;
	creation-date="Wed, 14 Dec 2011 15:20:15 GMT";
	modification-date="Wed, 14 Dec 2011 15:03:34 GMT"
Content-Transfer-Encoding: base64

RnJvbSAwZThkZTFjZTBmMTNhYTM0YWE2MDEzZTZhMzg3YWU1YmU3ODAzMWNhIE1vbiBTZXAgMTcg
MDA6MDA6MDAgMjAwMQpGcm9tOiBMaXUgSmluc29uZyA8amluc29uZy5saXVAaW50ZWwuY29tPgpE
YXRlOiBUdWUsIDYgRGVjIDIwMTEgMTg6MDg6MTIgKzA4MDAKU3ViamVjdDogW1BBVENIIDAxLzEw
XSBBZGQgbWNlbG9nIHN1cHBvcnQgZnJvbSB4ZW4gcGxhdGZvcm0KClRoaXMgcGF0Y2ggYmFja3Bv
cnQgZnJvbSBKZXJlbXkncyBwdm9wcyBjb21taXQgYTVlZDFmM2RhZTE3OTE1OGUzODVlOTM3MTQ2
MmRkNjVkNWUxMjVjNSwKd2hpY2ggaW4gdHVybiBiYWNrcG9ydCBmcm9tIHByZXZpb3VzIHhlbiBE
T00wKDIuNi4xOCkgY3M6IDc1ZTViZmE3ZmJkYwoKV2hlbiBhIE1DRS9DTUNJIGVycm9yIGhhcHBl
bnMgKG9yIGJ5IHBvbGxpbmcpLCB0aGUgcmVsYXRlZCBlcnJvcgppbmZvcm1hdGlvbiB3aWxsIGJl
IHNlbnQgdG8gcHJpdmlsZWdlZCBwdi1vcHMgZG9tYWluIGJ5IFhFTi4gVGhpcwpwYXRjaCB3aWxs
IGhlbHAgdG8gZmV0Y2ggdGhlIHhlbi1sb2dnZWQgaW5mb3JtYXRpb24gYnkgaHlwZXJjYWxsCmFu
ZCB0aGVuIGNvbnZlcnQgWEVOLWZvcm1hdCBsb2cgaW50byBMaW51eCBmb3JtYXQgTUNFTE9HLiBJ
dCBtYWtlcwp1c2luZyBjdXJyZW50IGF2YWlsYWJsZSBtY2Vsb2cgdG9vbHMgZm9yIG5hdGl2ZSBM
aW51eCBwb3NzaWJsZS4KCldpdGggdGhpcyBwYXRjaCwgYWZ0ZXIgbWNlL2NtY2kgZXJyb3IgbG9n
IGluZm9ybWF0aW9uIGlzIHNlbnQgdG8KcHYtb3BzIGd1ZXN0LCBSdW5uaW5nIG1jZWxvZyB0b29s
cyBpbiB0aGUgZ3Vlc3QsIHlvdSB3aWxsIGdldCBzYW1lCmRldGFpbGVkIGRlY29kZWQgbWNlIGlu
Zm9ybWF0aW9uIGFzIGluIE5hdGl2ZSBMaW51eC4KClNpZ25lZC1vZmYtYnk6IExpdSwgSmluc29u
ZyA8amluc29uZy5saXVAaW50ZWwuY29tPgpTaWduZWQtb2ZmLWJ5OiBLZSwgTGlwaW5nIDxsaXBp
bmcua2VAaW50ZWwuY29tPgpTaWduZWQtb2ZmLWJ5OiBKaWFuZywgWXVuaG9uZyA8eXVuaG9uZy5q
aWFuZ0BpbnRlbC5jb20+ClNpZ25lZC1vZmYtYnk6IEplcmVteSBGaXR6aGFyZGluZ2UgPGplcmVt
eS5maXR6aGFyZGluZ2VAY2l0cml4LmNvbT4KLS0tCiBhcmNoL3g4Ni9pbmNsdWRlL2FzbS94ZW4v
aHlwZXJjYWxsLmggfCAgICA4ICsKIGFyY2gveDg2L3hlbi9lbmxpZ2h0ZW4uYyAgICAgICAgICAg
ICB8ICAgIDggKy0KIGRyaXZlcnMveGVuL0tjb25maWcgICAgICAgICAgICAgICAgICB8ICAgIDgg
KwogZHJpdmVycy94ZW4vTWFrZWZpbGUgICAgICAgICAgICAgICAgIHwgICAgMSArCiBkcml2ZXJz
L3hlbi9tY2Vsb2cuYyAgICAgICAgICAgICAgICAgfCAgMjE3ICsrKysrKysrKysrKysrKysrCiBp
bmNsdWRlL3hlbi9pbnRlcmZhY2UveGVuLW1jYS5oICAgICAgfCAgNDI5ICsrKysrKysrKysrKysr
KysrKysrKysrKysrKysrKysrKysKIDYgZmlsZXMgY2hhbmdlZCwgNjY3IGluc2VydGlvbnMoKyks
IDQgZGVsZXRpb25zKC0pCiBjcmVhdGUgbW9kZSAxMDA2NDQgZHJpdmVycy94ZW4vbWNlbG9nLmMK
IGNyZWF0ZSBtb2RlIDEwMDY0NCBpbmNsdWRlL3hlbi9pbnRlcmZhY2UveGVuLW1jYS5oCgpkaWZm
IC0tZ2l0IGEvYXJjaC94ODYvaW5jbHVkZS9hc20veGVuL2h5cGVyY2FsbC5oIGIvYXJjaC94ODYv
aW5jbHVkZS9hc20veGVuL2h5cGVyY2FsbC5oCmluZGV4IDU3Mjg4NTIuLjU5YzIyNmQgMTAwNjQ0
Ci0tLSBhL2FyY2gveDg2L2luY2x1ZGUvYXNtL3hlbi9oeXBlcmNhbGwuaAorKysgYi9hcmNoL3g4
Ni9pbmNsdWRlL2FzbS94ZW4vaHlwZXJjYWxsLmgKQEAgLTQ4LDYgKzQ4LDcgQEAKICNpbmNsdWRl
IDx4ZW4vaW50ZXJmYWNlL3NjaGVkLmg+CiAjaW5jbHVkZSA8eGVuL2ludGVyZmFjZS9waHlzZGV2
Lmg+CiAjaW5jbHVkZSA8eGVuL2ludGVyZmFjZS9wbGF0Zm9ybS5oPgorI2luY2x1ZGUgPHhlbi9p
bnRlcmZhY2UveGVuLW1jYS5oPgogCiAvKgogICogVGhlIGh5cGVyY2FsbCBhc21zIGhhdmUgdG8g
bWVldCBzZXZlcmFsIGNvbnN0cmFpbnRzOgpAQCAtMzAyLDYgKzMwMywxMyBAQCBIWVBFUlZJU09S
X3NldF90aW1lcl9vcCh1NjQgdGltZW91dCkKIH0KIAogc3RhdGljIGlubGluZSBpbnQKK0hZUEVS
VklTT1JfbWNhKHN0cnVjdCB4ZW5fbWMgKm1jX29wKQoreworCW1jX29wLT5pbnRlcmZhY2VfdmVy
c2lvbiA9IFhFTl9NQ0FfSU5URVJGQUNFX1ZFUlNJT047CisJcmV0dXJuIF9oeXBlcmNhbGwxKGlu
dCwgbWNhLCBtY19vcCk7Cit9CisKK3N0YXRpYyBpbmxpbmUgaW50CiBIWVBFUlZJU09SX2RvbTBf
b3Aoc3RydWN0IHhlbl9wbGF0Zm9ybV9vcCAqcGxhdGZvcm1fb3ApCiB7CiAJcGxhdGZvcm1fb3At
PmludGVyZmFjZV92ZXJzaW9uID0gWEVOUEZfSU5URVJGQUNFX1ZFUlNJT047CmRpZmYgLS1naXQg
YS9hcmNoL3g4Ni94ZW4vZW5saWdodGVuLmMgYi9hcmNoL3g4Ni94ZW4vZW5saWdodGVuLmMKaW5k
ZXggOTMwNjMyMC4uYjA3M2U0YyAxMDA2NDQKLS0tIGEvYXJjaC94ODYveGVuL2VubGlnaHRlbi5j
CisrKyBiL2FyY2gveDg2L3hlbi9lbmxpZ2h0ZW4uYwpAQCAtMjQyLDE0ICsyNDIsMTQgQEAgc3Rh
dGljIHZvaWQgX19pbml0IHhlbl9pbml0X2NwdWlkX21hc2sodm9pZCkKIAl1bnNpZ25lZCBpbnQg
eHNhdmVfbWFzazsKIAogCWNwdWlkX2xlYWYxX2VkeF9tYXNrID0KLQkJfigoMSA8PCBYODZfRkVB
VFVSRV9NQ0UpICB8ICAvKiBkaXNhYmxlIE1DRSAqLwotCQkgICgxIDw8IFg4Nl9GRUFUVVJFX01D
QSkgIHwgIC8qIGRpc2FibGUgTUNBICovCi0JCSAgKDEgPDwgWDg2X0ZFQVRVUkVfTVRSUikgfCAg
LyogZGlzYWJsZSBNVFJSICovCisJCX4oKDEgPDwgWDg2X0ZFQVRVUkVfTVRSUikgfCAgLyogZGlz
YWJsZSBNVFJSICovCiAJCSAgKDEgPDwgWDg2X0ZFQVRVUkVfQUNDKSk7ICAgLyogdGhlcm1hbCBt
b25pdG9yaW5nICovCiAKIAlpZiAoIXhlbl9pbml0aWFsX2RvbWFpbigpKQogCQljcHVpZF9sZWFm
MV9lZHhfbWFzayAmPQotCQkJfigoMSA8PCBYODZfRkVBVFVSRV9BUElDKSB8ICAvKiBkaXNhYmxl
IGxvY2FsIEFQSUMgKi8KKwkJCX4oKDEgPDwgWDg2X0ZFQVRVUkVfTUNFKSAgfCAgLyogZGlzYWJs
ZSBNQ0UgKi8KKwkJCSAgKDEgPDwgWDg2X0ZFQVRVUkVfTUNBKSAgfCAgLyogZGlzYWJsZSBNQ0Eg
Ki8KKwkJCSAgKDEgPDwgWDg2X0ZFQVRVUkVfQVBJQykgfCAgLyogZGlzYWJsZSBsb2NhbCBBUElD
ICovCiAJCQkgICgxIDw8IFg4Nl9GRUFUVVJFX0FDUEkpKTsgIC8qIGRpc2FibGUgQUNQSSAqLwog
CWF4ID0gMTsKIAl4ZW5fY3B1aWQoJmF4LCAmYngsICZjeCwgJmR4KTsKZGlmZiAtLWdpdCBhL2Ry
aXZlcnMveGVuL0tjb25maWcgYi9kcml2ZXJzL3hlbi9LY29uZmlnCmluZGV4IGU4ZmI4NWYuLmVi
MmEzMjcgMTAwNjQ0Ci0tLSBhL2RyaXZlcnMveGVuL0tjb25maWcKKysrIGIvZHJpdmVycy94ZW4v
S2NvbmZpZwpAQCAtMTE3LDYgKzExNywxNCBAQCBjb25maWcgWEVOX1NZU19IWVBFUlZJU09SCiAJ
IHZpcnR1YWwgZW52aXJvbm1lbnQsIC9zeXMvaHlwZXJ2aXNvciB3aWxsIHN0aWxsIGJlIHByZXNl
bnQsCiAJIGJ1dCB3aWxsIGhhdmUgbm8geGVuIGNvbnRlbnRzLgogCitjb25maWcgWEVOX01DRV9M
T0cKKwlib29sICJYZW4gcGxhdGZvcm0gbWNlbG9nIgorCWRlcGVuZHMgb24gWEVOX0RPTTAgJiYg
WDg2XzY0ICYmIFg4Nl9NQ0UKKwlkZWZhdWx0IHkKKwloZWxwCisJICBBbGxvdyBrZXJuZWwgZmV0
Y2hpbmcgbWNlIGxvZyBmcm9tIHhlbiBwbGF0Zm9ybSBhbmQKKwkgIGNvbnZlcnRpbmcgaXQgaW50
byBsaW51eCBtY2Vsb2cgZm9ybWF0IGZvciBtY2Vsb2cgdG9vbHMKKwogY29uZmlnIEFDUElfUFJP
Q0VTU09SX1hFTgogCXRyaXN0YXRlCiAJZGVwZW5kcyBvbiBYRU5fRE9NMCAmJiBBQ1BJX1BST0NF
U1NPUiAmJiBDUFVfRlJFUQpkaWZmIC0tZ2l0IGEvZHJpdmVycy94ZW4vTWFrZWZpbGUgYi9kcml2
ZXJzL3hlbi9NYWtlZmlsZQppbmRleCBkNDJkYTUzLi40MDVjY2U5IDEwMDY0NAotLS0gYS9kcml2
ZXJzL3hlbi9NYWtlZmlsZQorKysgYi9kcml2ZXJzL3hlbi9NYWtlZmlsZQpAQCAtMTQsNiArMTQs
NyBAQCBvYmotJChDT05GSUdfWEVOX0dOVERFVikJCSs9IHhlbi1nbnRkZXYubwogb2JqLSQoQ09O
RklHX1hFTl9HUkFOVF9ERVZfQUxMT0MpCSs9IHhlbi1nbnRhbGxvYy5vCiBvYmotJChDT05GSUdf
WEVORlMpCQkJKz0geGVuZnMvCiBvYmotJChDT05GSUdfWEVOX1NZU19IWVBFUlZJU09SKQkrPSBz
eXMtaHlwZXJ2aXNvci5vCitvYmotJChDT05GSUdfWEVOX01DRV9MT0cpCQkrPSBtY2Vsb2cubwog
b2JqLSQoQ09ORklHX1hFTl9QTEFURk9STV9QQ0kpCQkrPSB4ZW4tcGxhdGZvcm0tcGNpLm8KIG9i
ai0kKENPTkZJR19YRU5fVE1FTSkJCQkrPSB0bWVtLm8KIG9iai0kKENPTkZJR19TV0lPVExCX1hF
TikJCSs9IHN3aW90bGIteGVuLm8KZGlmZiAtLWdpdCBhL2RyaXZlcnMveGVuL21jZWxvZy5jIGIv
ZHJpdmVycy94ZW4vbWNlbG9nLmMKbmV3IGZpbGUgbW9kZSAxMDA2NDQKaW5kZXggMDAwMDAwMC4u
ODkyY2E3YgotLS0gL2Rldi9udWxsCisrKyBiL2RyaXZlcnMveGVuL21jZWxvZy5jCkBAIC0wLDAg
KzEsMjE3IEBACisvKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqCisgKiBtY2Vsb2cuYworICogQWRkIE1h
Y2hpbmUgQ2hlY2sgZXZlbnQgTG9nZ2luZyBzdXBwb3J0IGluIERPTTAKKyAqCisgKiBEcml2ZXIg
Zm9yIHJlY2VpdmluZyBhbmQgbG9nZ2luZyBtYWNoaW5lIGNoZWNrIGV2ZW50CisgKgorICogQ29w
eXJpZ2h0IChjKSAyMDA4LCAyMDA5IEludGVsIENvcnBvcmF0aW9uCisgKgorICogVGhpcyBwcm9n
cmFtIGlzIGZyZWUgc29mdHdhcmU7IHlvdSBjYW4gcmVkaXN0cmlidXRlIGl0IGFuZC9vcgorICog
bW9kaWZ5IGl0IHVuZGVyIHRoZSB0ZXJtcyBvZiB0aGUgR05VIEdlbmVyYWwgUHVibGljIExpY2Vu
c2UgdmVyc2lvbiAyCisgKiBhcyBwdWJsaXNoZWQgYnkgdGhlIEZyZWUgU29mdHdhcmUgRm91bmRh
dGlvbjsgb3IsIHdoZW4gZGlzdHJpYnV0ZWQKKyAqIHNlcGFyYXRlbHkgZnJvbSB0aGUgTGludXgg
a2VybmVsIG9yIGluY29ycG9yYXRlZCBpbnRvIG90aGVyCisgKiBzb2Z0d2FyZSBwYWNrYWdlcywg
c3ViamVjdCB0byB0aGUgZm9sbG93aW5nIGxpY2Vuc2U6CisgKgorICogUGVybWlzc2lvbiBpcyBo
ZXJlYnkgZ3JhbnRlZCwgZnJlZSBvZiBjaGFyZ2UsIHRvIGFueSBwZXJzb24gb2J0YWluaW5nIGEg
Y29weQorICogb2YgdGhpcyBzb3VyY2UgZmlsZSAodGhlICJTb2Z0d2FyZSIpLCB0byBkZWFsIGlu
IHRoZSBTb2Z0d2FyZSB3aXRob3V0CisgKiByZXN0cmljdGlvbiwgaW5jbHVkaW5nIHdpdGhvdXQg
bGltaXRhdGlvbiB0aGUgcmlnaHRzIHRvIHVzZSwgY29weSwgbW9kaWZ5LAorICogbWVyZ2UsIHB1
Ymxpc2gsIGRpc3RyaWJ1dGUsIHN1YmxpY2Vuc2UsIGFuZC9vciBzZWxsIGNvcGllcyBvZiB0aGUg
U29mdHdhcmUsCisgKiBhbmQgdG8gcGVybWl0IHBlcnNvbnMgdG8gd2hvbSB0aGUgU29mdHdhcmUg
aXMgZnVybmlzaGVkIHRvIGRvIHNvLCBzdWJqZWN0IHRvCisgKiB0aGUgZm9sbG93aW5nIGNvbmRp
dGlvbnM6CisgKgorICogVGhlIGFib3ZlIGNvcHlyaWdodCBub3RpY2UgYW5kIHRoaXMgcGVybWlz
c2lvbiBub3RpY2Ugc2hhbGwgYmUgaW5jbHVkZWQgaW4KKyAqIGFsbCBjb3BpZXMgb3Igc3Vic3Rh
bnRpYWwgcG9ydGlvbnMgb2YgdGhlIFNvZnR3YXJlLgorICoKKyAqIFRIRSBTT0ZUV0FSRSBJUyBQ
Uk9WSURFRCAiQVMgSVMiLCBXSVRIT1VUIFdBUlJBTlRZIE9GIEFOWSBLSU5ELCBFWFBSRVNTIE9S
CisgKiBJTVBMSUVELCBJTkNMVURJTkcgQlVUIE5PVCBMSU1JVEVEIFRPIFRIRSBXQVJSQU5USUVT
IE9GIE1FUkNIQU5UQUJJTElUWSwKKyAqIEZJVE5FU1MgRk9SIEEgUEFSVElDVUxBUiBQVVJQT1NF
IEFORCBOT05JTkZSSU5HRU1FTlQuIElOIE5PIEVWRU5UIFNIQUxMIFRIRQorICogQVVUSE9SUyBP
UiBDT1BZUklHSFQgSE9MREVSUyBCRSBMSUFCTEUgRk9SIEFOWSBDTEFJTSwgREFNQUdFUyBPUiBP
VEhFUgorICogTElBQklMSVRZLCBXSEVUSEVSIElOIEFOIEFDVElPTiBPRiBDT05UUkFDVCwgVE9S
VCBPUiBPVEhFUldJU0UsIEFSSVNJTkcKKyAqIEZST00sIE9VVCBPRiBPUiBJTiBDT05ORUNUSU9O
IFdJVEggVEhFIFNPRlRXQVJFIE9SIFRIRSBVU0UgT1IgT1RIRVIgREVBTElOR1MKKyAqIElOIFRI
RSBTT0ZUV0FSRS4KKyAqLworCisjaW5jbHVkZSA8bGludXgvbW9kdWxlLmg+CisjaW5jbHVkZSA8
bGludXgvaW5pdC5oPgorI2luY2x1ZGUgPGxpbnV4L3R5cGVzLmg+CisjaW5jbHVkZSA8bGludXgv
a2VybmVsLmg+CisjaW5jbHVkZSA8bGludXgvc2xhYi5oPgorI2luY2x1ZGUgPHhlbi9pbnRlcmZh
Y2UveGVuLmg+CisjaW5jbHVkZSA8YXNtL3hlbi9oeXBlcnZpc29yLmg+CisjaW5jbHVkZSA8eGVu
L2V2ZW50cy5oPgorI2luY2x1ZGUgPHhlbi9pbnRlcmZhY2UvdmNwdS5oPgorI2luY2x1ZGUgPGFz
bS94ZW4vaHlwZXJjYWxsLmg+CisjaW5jbHVkZSA8YXNtL21jZS5oPgorI2luY2x1ZGUgPHhlbi94
ZW4uaD4KKworc3RhdGljIG1jX2luZm9fdCAqZ19taTsKK3N0YXRpYyBtY2luZm9fbG9naWNhbF9j
cHVfdCAqZ19waHlzaW5mbzsKK3N0YXRpYyB1aW50MzJfdCBuY3B1czsKKworc3RhdGljIGludCBj
b252ZXJ0X2xvZyhzdHJ1Y3QgbWNfaW5mbyAqbWkpCit7CisJc3RydWN0IG1jaW5mb19jb21tb24g
Km1pYyA9IE5VTEw7CisJc3RydWN0IG1jaW5mb19nbG9iYWwgKm1jX2dsb2JhbDsKKwlzdHJ1Y3Qg
bWNpbmZvX2JhbmsgKm1jX2Jhbms7CisJc3RydWN0IG1jZSBtOworCWludCBpLCBmb3VuZCA9IDA7
CisKKwl4ODZfbWNpbmZvX2xvb2t1cCgmbWljLCBtaSwgTUNfVFlQRV9HTE9CQUwpOworCVdBUk5f
T04oIW1pYyk7CisKKwltY2Vfc2V0dXAoJm0pOworCW1jX2dsb2JhbCA9IChzdHJ1Y3QgbWNpbmZv
X2dsb2JhbCAqKW1pYzsKKwltLm1jZ3N0YXR1cyA9IG1jX2dsb2JhbC0+bWNfZ3N0YXR1czsKKwlt
LmFwaWNpZCA9IG1jX2dsb2JhbC0+bWNfYXBpY2lkOworCWZvciAoaSA9IDA7IGkgPCBuY3B1czsg
aSsrKSB7CisJCWlmIChnX3BoeXNpbmZvW2ldLm1jX2FwaWNpZCA9PSBtLmFwaWNpZCkgeworCQkJ
Zm91bmQgPSAxOworCQkJYnJlYWs7CisJCX0KKwl9CisJV0FSTl9PTighZm91bmQpOworCisJbS5z
b2NrZXRpZCA9IGdfcGh5c2luZm9baV0ubWNfY2hpcGlkOworCW0uY3B1ID0gbS5leHRjcHUgPSBn
X3BoeXNpbmZvW2ldLm1jX2NwdW5yOworCW0uY3B1dmVuZG9yID0gKF9fdTgpZ19waHlzaW5mb1tp
XS5tY192ZW5kb3I7CisJbS5tY2djYXAgPSBnX3BoeXNpbmZvW2ldLm1jX21zcnZhbHVlc1swXS52
YWx1ZTsKKwl4ODZfbWNpbmZvX2xvb2t1cCgmbWljLCBtaSwgTUNfVFlQRV9CQU5LKTsKKwlkbyB7
CisJCWlmIChtaWMgPT0gTlVMTCB8fCBtaWMtPnNpemUgPT0gMCkKKwkJCWJyZWFrOworCQlpZiAo
bWljLT50eXBlID09IE1DX1RZUEVfQkFOSykgeworCQkJbWNfYmFuayA9IChzdHJ1Y3QgbWNpbmZv
X2JhbmsgKiltaWM7CisJCQltLm1pc2MgPSBtY19iYW5rLT5tY19taXNjOworCQkJbS5zdGF0dXMg
PSBtY19iYW5rLT5tY19zdGF0dXM7CisJCQltLmFkZHIgPSBtY19iYW5rLT5tY19hZGRyOworCQkJ
bS50c2MgPSBtY19iYW5rLT5tY190c2M7CisJCQltLmJhbmsgPSBtY19iYW5rLT5tY19iYW5rOwor
CQkJbS5maW5pc2hlZCA9IDE7CisJCQkvKmxvZyB0aGlzIHJlY29yZCovCisJCQltY2VfbG9nKCZt
KTsKKwkJfQorCQltaWMgPSB4ODZfbWNpbmZvX25leHQobWljKTsKKwl9IHdoaWxlICgxKTsKKwor
CXJldHVybiAwOworfQorCisvKnB2X29wcyBkb21haW4gbWNlIHZpcnEgaGFuZGxlciwgbG9nZ2lu
ZyBwaHlzaWNhbCBtY2UgZXJyb3IgaW5mbyovCitzdGF0aWMgaXJxcmV0dXJuX3QgbWNlX2RvbV9p
bnRlcnJ1cHQoaW50IGlycSwgdm9pZCAqZGV2X2lkKQoreworCXhlbl9tY190IG1jX29wOworCWlu
dCByZXN1bHQgPSAwOworCisJbWNfb3AuY21kID0gWEVOX01DX2ZldGNoOworCW1jX29wLmludGVy
ZmFjZV92ZXJzaW9uID0gWEVOX01DQV9JTlRFUkZBQ0VfVkVSU0lPTjsKKwlzZXRfeGVuX2d1ZXN0
X2hhbmRsZShtY19vcC51Lm1jX2ZldGNoLmRhdGEsIGdfbWkpOwordXJnZW50OgorCW1jX29wLnUu
bWNfZmV0Y2guZmxhZ3MgPSBYRU5fTUNfVVJHRU5UOworCXJlc3VsdCA9IEhZUEVSVklTT1JfbWNh
KCZtY19vcCk7CisJaWYgKHJlc3VsdCB8fCBtY19vcC51Lm1jX2ZldGNoLmZsYWdzICYgWEVOX01D
X05PREFUQSB8fAorCQkJbWNfb3AudS5tY19mZXRjaC5mbGFncyAmIFhFTl9NQ19GRVRDSEZBSUxF
RCkKKwkJZ290byBub251cmdlbnQ7CisJZWxzZSB7CisJCXJlc3VsdCA9IGNvbnZlcnRfbG9nKGdf
bWkpOworCQlpZiAocmVzdWx0KQorCQkJZ290byBlbmQ7CisJCS8qIEFmdGVyIGZldGNoaW5nIHRo
ZSBlcnJvciBldmVudCBsb2cgZW50cnkgZnJvbSBET00wLAorCQkgKiB3ZSBuZWVkIHRvIGRlYyB0
aGUgcmVmY250IGFuZCByZWxlYXNlIHRoZSBlbnRyeS4KKwkJICogVGhlIGVudHJ5IGlzIHJlc2Vy
dmVkIGFuZCBpbmMgcmVmY250IHdoZW4gZmlsbGluZworCQkgKiB0aGUgZXJyb3IgbG9nIGVudHJ5
LgorCQkgKi8KKwkJbWNfb3AudS5tY19mZXRjaC5mbGFncyA9IFhFTl9NQ19VUkdFTlQgfCBYRU5f
TUNfQUNLOworCQlyZXN1bHQgPSBIWVBFUlZJU09SX21jYSgmbWNfb3ApOworCQlnb3RvIHVyZ2Vu
dDsKKwl9Citub251cmdlbnQ6CisJbWNfb3AudS5tY19mZXRjaC5mbGFncyA9IFhFTl9NQ19OT05V
UkdFTlQ7CisJcmVzdWx0ID0gSFlQRVJWSVNPUl9tY2EoJm1jX29wKTsKKwlpZiAocmVzdWx0IHx8
IG1jX29wLnUubWNfZmV0Y2guZmxhZ3MgJiBYRU5fTUNfTk9EQVRBIHx8CisJCQltY19vcC51Lm1j
X2ZldGNoLmZsYWdzICYgWEVOX01DX0ZFVENIRkFJTEVEKQorCQlnb3RvIGVuZDsKKwllbHNlIHsK
KwkJcmVzdWx0ID0gY29udmVydF9sb2coZ19taSk7CisJCWlmIChyZXN1bHQpCisJCQlnb3RvIGVu
ZDsKKwkJLyogQWZ0ZXIgZmV0Y2hpbmcgdGhlIGVycm9yIGV2ZW50IGxvZyBlbnRyeSBmcm9tIERP
TTAsCisJCSAqIHdlIG5lZWQgdG8gZGVjIHRoZSByZWZjbnQgYW5kIHJlbGVhc2UgdGhlIGVudHJ5
LiBUaGUKKwkJICogZW50cnkgaXMgcmVzZXJ2ZWQgYW5kIGluYyByZWZjbnQgd2hlbiBmaWxsaW5n
IHRoZQorCQkgKiBlcnJvciBsb2cgZW50cnkuCisJCSAqLworCQltY19vcC51Lm1jX2ZldGNoLmZs
YWdzID0gWEVOX01DX05PTlVSR0VOVCB8IFhFTl9NQ19BQ0s7CisJCXJlc3VsdCA9IEhZUEVSVklT
T1JfbWNhKCZtY19vcCk7CisJCWdvdG8gbm9udXJnZW50OworCX0KK2VuZDoKKwlyZXR1cm4gSVJR
X0hBTkRMRUQ7Cit9CisKK3N0YXRpYyBpbnQgYmluZF92aXJxX2Zvcl9tY2Uodm9pZCkKK3sKKwlp
bnQgcmV0OworCXhlbl9tY190IG1jX29wOworCisJZ19taSA9IGttYWxsb2Moc2l6ZW9mKHN0cnVj
dCBtY19pbmZvKSwgR0ZQX0tFUk5FTCk7CisKKwlpZiAoIWdfbWkpCisJCXJldHVybiAtRU5PTUVN
OworCisJLyogRmV0Y2ggcGh5c2ljYWwgQ1BVIE51bWJlcnMgKi8KKwltY19vcC5jbWQgPSBYRU5f
TUNfcGh5c2NwdWluZm87CisJbWNfb3AuaW50ZXJmYWNlX3ZlcnNpb24gPSBYRU5fTUNBX0lOVEVS
RkFDRV9WRVJTSU9OOworCXNldF94ZW5fZ3Vlc3RfaGFuZGxlKG1jX29wLnUubWNfcGh5c2NwdWlu
Zm8uaW5mbywgZ19waHlzaW5mbyk7CisJcmV0ID0gSFlQRVJWSVNPUl9tY2EoJm1jX29wKTsKKwlp
ZiAocmV0KSB7CisJCXByaW50ayhLRVJOX0VSUiAiTUNFX0RPTTBfTE9HOiBGYWlsIHRvIGdldCBw
aHlzaWNhbCBDUFUgbnVtYmVyc1xuIik7CisJCWtmcmVlKGdfbWkpOworCQlyZXR1cm4gcmV0Owor
CX0KKworCS8qIEZldGNoIGVhY2ggQ1BVIFBoeXNpY2FsIEluZm8gZm9yIGxhdGVyIHJlZmVyZW5j
ZSovCisJbmNwdXMgPSBtY19vcC51Lm1jX3BoeXNjcHVpbmZvLm5jcHVzOworCWdfcGh5c2luZm8g
PSBrbWFsbG9jKHNpemVvZihzdHJ1Y3QgbWNpbmZvX2xvZ2ljYWxfY3B1KSpuY3B1cywKKwkJCQkJ
R0ZQX0tFUk5FTCk7CisJaWYgKCFnX3BoeXNpbmZvKSB7CisJCWtmcmVlKGdfbWkpOworCQlyZXR1
cm4gLUVOT01FTTsKKwl9CisJc2V0X3hlbl9ndWVzdF9oYW5kbGUobWNfb3AudS5tY19waHlzY3B1
aW5mby5pbmZvLCBnX3BoeXNpbmZvKTsKKwlyZXQgPSBIWVBFUlZJU09SX21jYSgmbWNfb3ApOwor
CWlmIChyZXQpIHsKKwkJcHJpbnRrKEtFUk5fRVJSICJNQ0VfRE9NMF9MT0c6IEZhaWwgdG8gZ2V0
IHBoeXNpY2FsIENQVXMgaW5mb1xuIik7CisJCWtmcmVlKGdfbWkpOworCQlrZnJlZShnX3BoeXNp
bmZvKTsKKwkJcmV0dXJuIHJldDsKKwl9CisKKwlyZXQgID0gYmluZF92aXJxX3RvX2lycWhhbmRs
ZXIoVklSUV9NQ0EsIDAsCisJCW1jZV9kb21faW50ZXJydXB0LCAwLCAibWNlIiwgTlVMTCk7CisK
KwlpZiAocmV0IDwgMCkgeworCQlwcmludGsoS0VSTl9FUlIgIk1DRV9ET00wX0xPRzogYmluZF92
aXJxIGZvciBET00wIGZhaWxlZFxuIik7CisJCXJldHVybiByZXQ7CisJfQorCisJcmV0dXJuIDA7
Cit9CisKK3N0YXRpYyBpbnQgX19pbml0IG1jZWxvZ19pbml0KHZvaWQpCit7CisJLyogT25seSBE
T00wIGlzIHJlc3BvbnNpYmxlIGZvciBNQ0UgbG9nZ2luZyAqLworCWlmICh4ZW5faW5pdGlhbF9k
b21haW4oKSkKKwkJcmV0dXJuIGJpbmRfdmlycV9mb3JfbWNlKCk7CisKKwlyZXR1cm4gMDsKK30K
KworCitzdGF0aWMgdm9pZCBfX2V4aXQgbWNlbG9nX2NsZWFudXAodm9pZCkKK3sKKwlrZnJlZShn
X21pKTsKKwlrZnJlZShnX3BoeXNpbmZvKTsKK30KK21vZHVsZV9pbml0KG1jZWxvZ19pbml0KTsK
K21vZHVsZV9leGl0KG1jZWxvZ19jbGVhbnVwKTsKKworTU9EVUxFX0xJQ0VOU0UoIkdQTCIpOwpk
aWZmIC0tZ2l0IGEvaW5jbHVkZS94ZW4vaW50ZXJmYWNlL3hlbi1tY2EuaCBiL2luY2x1ZGUveGVu
L2ludGVyZmFjZS94ZW4tbWNhLmgKbmV3IGZpbGUgbW9kZSAxMDA2NDQKaW5kZXggMDAwMDAwMC4u
ZjMxZmRhYgotLS0gL2Rldi9udWxsCisrKyBiL2luY2x1ZGUveGVuL2ludGVyZmFjZS94ZW4tbWNh
LmgKQEAgLTAsMCArMSw0MjkgQEAKKy8qKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioKKyAqIGFyY2gteDg2
L21jYS5oCisgKgorICogQ29udHJpYnV0ZWQgYnkgQWR2YW5jZWQgTWljcm8gRGV2aWNlcywgSW5j
LgorICogQXV0aG9yOiBDaHJpc3RvcGggRWdnZXIgPENocmlzdG9waC5FZ2dlckBhbWQuY29tPgor
ICoKKyAqIEd1ZXN0IE9TIG1hY2hpbmUgY2hlY2sgaW50ZXJmYWNlIHRvIHg4NiBYZW4uCisgKgor
ICogUGVybWlzc2lvbiBpcyBoZXJlYnkgZ3JhbnRlZCwgZnJlZSBvZiBjaGFyZ2UsIHRvIGFueSBw
ZXJzb24gb2J0YWluaW5nIGEgY29weQorICogb2YgdGhpcyBzb2Z0d2FyZSBhbmQgYXNzb2NpYXRl
ZCBkb2N1bWVudGF0aW9uIGZpbGVzICh0aGUgIlNvZnR3YXJlIiksIHRvCisgKiBkZWFsIGluIHRo
ZSBTb2Z0d2FyZSB3aXRob3V0IHJlc3RyaWN0aW9uLCBpbmNsdWRpbmcgd2l0aG91dCBsaW1pdGF0
aW9uIHRoZQorICogcmlnaHRzIHRvIHVzZSwgY29weSwgbW9kaWZ5LCBtZXJnZSwgcHVibGlzaCwg
ZGlzdHJpYnV0ZSwgc3VibGljZW5zZSwgYW5kL29yCisgKiBzZWxsIGNvcGllcyBvZiB0aGUgU29m
dHdhcmUsIGFuZCB0byBwZXJtaXQgcGVyc29ucyB0byB3aG9tIHRoZSBTb2Z0d2FyZSBpcworICog
ZnVybmlzaGVkIHRvIGRvIHNvLCBzdWJqZWN0IHRvIHRoZSBmb2xsb3dpbmcgY29uZGl0aW9uczoK
KyAqCisgKiBUaGUgYWJvdmUgY29weXJpZ2h0IG5vdGljZSBhbmQgdGhpcyBwZXJtaXNzaW9uIG5v
dGljZSBzaGFsbCBiZSBpbmNsdWRlZCBpbgorICogYWxsIGNvcGllcyBvciBzdWJzdGFudGlhbCBw
b3J0aW9ucyBvZiB0aGUgU29mdHdhcmUuCisgKgorICogVEhFIFNPRlRXQVJFIElTIFBST1ZJREVE
ICJBUyBJUyIsIFdJVEhPVVQgV0FSUkFOVFkgT0YgQU5ZIEtJTkQsIEVYUFJFU1MgT1IKKyAqIElN
UExJRUQsIElOQ0xVRElORyBCVVQgTk9UIExJTUlURUQgVE8gVEhFIFdBUlJBTlRJRVMgT0YgTUVS
Q0hBTlRBQklMSVRZLAorICogRklUTkVTUyBGT1IgQSBQQVJUSUNVTEFSIFBVUlBPU0UgQU5EIE5P
TklORlJJTkdFTUVOVC4gSU4gTk8gRVZFTlQgU0hBTEwgVEhFCisgKiBBVVRIT1JTIE9SIENPUFlS
SUdIVCBIT0xERVJTIEJFIExJQUJMRSBGT1IgQU5ZIENMQUlNLCBEQU1BR0VTIE9SIE9USEVSCisg
KiBMSUFCSUxJVFksIFdIRVRIRVIgSU4gQU4gQUNUSU9OIE9GIENPTlRSQUNULCBUT1JUIE9SIE9U
SEVSV0lTRSwgQVJJU0lORworICogRlJPTSwgT1VUIE9GIE9SIElOIENPTk5FQ1RJT04gV0lUSCBU
SEUgU09GVFdBUkUgT1IgVEhFIFVTRSBPUiBPVEhFUgorICogREVBTElOR1MgSU4gVEhFIFNPRlRX
QVJFLgorICovCisKKy8qIEZ1bGwgTUNBIGZ1bmN0aW9uYWxpdHkgaGFzIHRoZSBmb2xsb3dpbmcg
VXNlY2FzZXMgZnJvbSB0aGUgZ3Vlc3Qgc2lkZToKKyAqCisgKiBNdXN0IGhhdmUnczoKKyAqIDEu
IERvbTAgYW5kIERvbVUgcmVnaXN0ZXIgbWFjaGluZSBjaGVjayB0cmFwIGNhbGxiYWNrIGhhbmRs
ZXJzCisgKiAgICAoYWxyZWFkeSBkb25lIHZpYSAic2V0X3RyYXBfdGFibGUiIGh5cGVyY2FsbCkK
KyAqIDIuIERvbTAgcmVnaXN0ZXJzIG1hY2hpbmUgY2hlY2sgZXZlbnQgY2FsbGJhY2sgaGFuZGxl
cgorICogICAgKGRvYWJsZSB2aWEgRVZUQ0hOT1BfYmluZF92aXJxKQorICogMy4gRG9tMCBhbmQg
RG9tVSBmZXRjaGVzIG1hY2hpbmUgY2hlY2sgZGF0YQorICogNC4gRG9tMCB3YW50cyBYZW4gdG8g
bm90aWZ5IGEgRG9tVQorICogNS4gRG9tMCBnZXRzIERvbVUgSUQgZnJvbSBwaHlzaWNhbCBhZGRy
ZXNzCisgKiA2LiBEb20wIHdhbnRzIFhlbiB0byBraWxsIERvbVUgKGFscmVhZHkgZG9uZSBmb3Ig
InhtIGRlc3Ryb3kiKQorICoKKyAqIE5pY2UgdG8gaGF2ZSdzOgorICogNy4gRG9tMCB3YW50cyBY
ZW4gdG8gZGVhY3RpdmF0ZSBhIHBoeXNpY2FsIENQVQorICogICAgVGhpcyBpcyBiZXR0ZXIgZG9u
ZSBhcyBzZXBhcmF0ZSB0YXNrLCBwaHlzaWNhbCBDUFUgaG90cGx1Z2dpbmcsCisgKiAgICBhbmQg
aHlwZXJjYWxsKHMpIHNob3VsZCBiZSBzeXNjdGwncworICogOC4gUGFnZSBtaWdyYXRpb24gcHJv
cG9zZWQgZnJvbSBYZW4gTlVNQSB3b3JrLCB3aGVyZSBEb20wIGNhbiB0ZWxsIFhlbiB0bworICog
ICAgbW92ZSBhIERvbVUgKG9yIERvbTAgaXRzZWxmKSBhd2F5IGZyb20gYSBtYWxpY2lvdXMgcGFn
ZQorICogICAgcHJvZHVjaW5nIGNvcnJlY3RhYmxlIGVycm9ycy4KKyAqIDkuIG9mZmxpbmluZyBw
aHlzaWNhbCBwYWdlOgorICogICAgWGVuIGZyZWUncyBhbmQgbmV2ZXIgcmUtdXNlcyBhIGNlcnRh
aW4gcGh5c2ljYWwgcGFnZS4KKyAqIDEwLiBUZXN0ZmFjaWxpdHk6IEFsbG93IERvbTAgdG8gd3Jp
dGUgdmFsdWVzIGludG8gbWFjaGluZSBjaGVjayBNU1IncworICogICAgIGFuZCB0ZWxsIFhlbiB0
byB0cmlnZ2VyIGEgbWFjaGluZSBjaGVjaworICovCisKKyNpZm5kZWYgX19YRU5fUFVCTElDX0FS
Q0hfWDg2X01DQV9IX18KKyNkZWZpbmUgX19YRU5fUFVCTElDX0FSQ0hfWDg2X01DQV9IX18KKwor
LyogSHlwZXJjYWxsICovCisjZGVmaW5lIF9fSFlQRVJWSVNPUl9tY2EgX19IWVBFUlZJU09SX2Fy
Y2hfMAorCisvKgorICogVGhlIHhlbi11bnN0YWJsZSByZXBvIGhhcyBpbnRlcmZhY2UgdmVyc2lv
biAweDAzMDAwMDAxOyBvdXQgaW50ZXJmYWNlCisgKiBpcyBpbmNvbXBhdGlibGUgd2l0aCB0aGF0
IGFuZCBhbnkgZnV0dXJlIG1pbm9yIHJldmlzaW9ucywgc28gd2UKKyAqIGNob29zZSBhIGRpZmZl
cmVudCB2ZXJzaW9uIG51bWJlciByYW5nZSB0aGF0IGlzIG51bWVyaWNhbGx5IGxlc3MKKyAqIHRo
YW4gdGhhdCB1c2VkIGluIHhlbi11bnN0YWJsZS4KKyAqLworI2RlZmluZSBYRU5fTUNBX0lOVEVS
RkFDRV9WRVJTSU9OIDB4MDFlY2MwMDMKKworLyogSU46IERvbTAgY2FsbHMgaHlwZXJjYWxsIHRv
IHJldHJpZXZlIG5vbnVyZ2VudCBlcnJvciBsb2cgZW50cnkgKi8KKyNkZWZpbmUgWEVOX01DX05P
TlVSR0VOVCAgMHgwMDAxCisvKiBJTjogRG9tMC9Eb21VIGNhbGxzIGh5cGVyY2FsbCB0byByZXRy
aWV2ZSB1cmdlbnQgZXJyb3IgbG9nIGVudHJ5ICovCisjZGVmaW5lIFhFTl9NQ19VUkdFTlQgICAg
IDB4MDAwMgorLyogSU46IERvbTAgYWNrbm93bGVkZ2VzIHByZXZpb3NseS1mZXRjaGVkIGVycm9y
IGxvZyBlbnRyeSAqLworI2RlZmluZSBYRU5fTUNfQUNLICAgICAgICAweDAwMDQKKworLyogT1VU
OiBBbGwgaXMgb2sgKi8KKyNkZWZpbmUgWEVOX01DX09LICAgICAgICAgICAweDAKKy8qIE9VVDog
RG9tYWluIGNvdWxkIG5vdCBmZXRjaCBkYXRhLiAqLworI2RlZmluZSBYRU5fTUNfRkVUQ0hGQUlM
RUQgIDB4MQorLyogT1VUOiBUaGVyZSB3YXMgbm8gbWFjaGluZSBjaGVjayBkYXRhIHRvIGZldGNo
LiAqLworI2RlZmluZSBYRU5fTUNfTk9EQVRBICAgICAgIDB4MgorLyogT1VUOiBCZXR3ZWVuIG5v
dGlmaWNhdGlvbiB0aW1lIGFuZCB0aGlzIGh5cGVyY2FsbCBhbiBvdGhlcgorICogIChtb3N0IGxp
a2VseSkgY29ycmVjdGFibGUgZXJyb3IgaGFwcGVuZWQuIFRoZSBmZXRjaGVkIGRhdGEsCisgKiAg
ZG9lcyBub3QgbWF0Y2ggdGhlIG9yaWdpbmFsIG1hY2hpbmUgY2hlY2sgZGF0YS4gKi8KKyNkZWZp
bmUgWEVOX01DX05PTUFUQ0ggICAgICAweDQKKworLyogT1VUOiBEb21VIGRpZCBub3QgcmVnaXN0
ZXIgTUMgTk1JIGhhbmRsZXIuIFRyeSBzb21ldGhpbmcgZWxzZS4gKi8KKyNkZWZpbmUgWEVOX01D
X0NBTk5PVEhBTkRMRSAweDgKKy8qIE9VVDogTm90aWZ5aW5nIERvbVUgZmFpbGVkLiBSZXRyeSBs
YXRlciBvciB0cnkgc29tZXRoaW5nIGVsc2UuICovCisjZGVmaW5lIFhFTl9NQ19OT1RERUxJVkVS
RUQgMHgxMAorLyogTm90ZSwgWEVOX01DX0NBTk5PVEhBTkRMRSBhbmQgWEVOX01DX05PVERFTElW
RVJFRCBhcmUgbXV0dWFsbHkgZXhjbHVzaXZlLiAqLworCisKKyNpZm5kZWYgX19BU1NFTUJMWV9f
CisKKyNkZWZpbmUgVklSUV9NQ0EgVklSUV9BUkNIXzAgLyogRy4gKERPTTApIE1hY2hpbmUgQ2hl
Y2sgQXJjaGl0ZWN0dXJlICovCisKKy8qCisgKiBNYWNoaW5lIENoZWNrIEFyY2hpdGVjdXJlOgor
ICogc3RydWN0cyBhcmUgcmVhZC1vbmx5IGFuZCB1c2VkIHRvIHJlcG9ydCBhbGwga2luZHMgb2YK
KyAqIGNvcnJlY3RhYmxlIGFuZCB1bmNvcnJlY3RhYmxlIGVycm9ycyBkZXRlY3RlZCBieSB0aGUg
SFcuCisgKiBEb20wIGFuZCBEb21VOiByZWdpc3RlciBhIGhhbmRsZXIgdG8gZ2V0IG5vdGlmaWVk
LgorICogRG9tMCBvbmx5OiBDb3JyZWN0YWJsZSBlcnJvcnMgYXJlIHJlcG9ydGVkIHZpYSBWSVJR
X01DQQorICovCisjZGVmaW5lIE1DX1RZUEVfR0xPQkFMICAgICAgICAgIDAKKyNkZWZpbmUgTUNf
VFlQRV9CQU5LICAgICAgICAgICAgMQorI2RlZmluZSBNQ19UWVBFX0VYVEVOREVEICAgICAgICAy
CisjZGVmaW5lIE1DX1RZUEVfUkVDT1ZFUlkgICAgICAgIDMKKworc3RydWN0IG1jaW5mb19jb21t
b24geworCXVpbnQxNl90IHR5cGU7ICAgICAgLyogc3RydWN0dXJlIHR5cGUgKi8KKwl1aW50MTZf
dCBzaXplOyAgICAgIC8qIHNpemUgb2YgdGhpcyBzdHJ1Y3QgaW4gYnl0ZXMgKi8KK307CisKKwor
I2RlZmluZSBNQ19GTEFHX0NPUlJFQ1RBQkxFICAgICAoMSA8PCAwKQorI2RlZmluZSBNQ19GTEFH
X1VOQ09SUkVDVEFCTEUgICAoMSA8PCAxKQorI2RlZmluZSBNQ19GTEFHX1JFQ09WRVJBQkxFCSgx
IDw8IDIpCisjZGVmaW5lIE1DX0ZMQUdfUE9MTEVECQkoMSA8PCAzKQorI2RlZmluZSBNQ19GTEFH
X1JFU0VUCQkoMSA8PCA0KQorI2RlZmluZSBNQ19GTEFHX0NNQ0kJCSgxIDw8IDUpCisjZGVmaW5l
IE1DX0ZMQUdfTUNFCQkoMSA8PCA2KQorLyogY29udGFpbnMgZ2xvYmFsIHg4NiBtYyBpbmZvcm1h
dGlvbiAqLworc3RydWN0IG1jaW5mb19nbG9iYWwgeworCXN0cnVjdCBtY2luZm9fY29tbW9uIGNv
bW1vbjsKKworCS8qIHJ1bm5pbmcgZG9tYWluIGF0IHRoZSB0aW1lIGluIGVycm9yIChtb3N0IGxp
a2VseQorCSAqIHRoZSBpbXBhY3RlZCBvbmUpICovCisJdWludDE2X3QgbWNfZG9taWQ7CisJdWlu
dDE2X3QgbWNfdmNwdWlkOyAvKiB2aXJ0dWFsIGNwdSBzY2hlZHVsZWQgZm9yIG1jX2RvbWlkICov
CisJdWludDMyX3QgbWNfc29ja2V0aWQ7IC8qIHBoeXNpY2FsIHNvY2tldCBvZiB0aGUgcGh5c2lj
YWwgY29yZSAqLworCXVpbnQxNl90IG1jX2NvcmVpZDsgLyogcGh5c2ljYWwgaW1wYWN0ZWQgY29y
ZSAqLworCXVpbnQxNl90IG1jX2NvcmVfdGhyZWFkaWQ7IC8qIGNvcmUgdGhyZWFkIG9mIHBoeXNp
Y2FsIGNvcmUgKi8KKwl1aW50MzJfdCBtY19hcGljaWQ7CisJdWludDMyX3QgbWNfZmxhZ3M7CisJ
dWludDY0X3QgbWNfZ3N0YXR1czsgLyogZ2xvYmFsIHN0YXR1cyAqLworfTsKKworLyogY29udGFp
bnMgYmFuayBsb2NhbCB4ODYgbWMgaW5mb3JtYXRpb24gKi8KK3N0cnVjdCBtY2luZm9fYmFuayB7
CisJc3RydWN0IG1jaW5mb19jb21tb24gY29tbW9uOworCisJdWludDE2X3QgbWNfYmFuazsgLyog
YmFuayBuciAqLworCXVpbnQxNl90IG1jX2RvbWlkOyAvKiBVc2VjYXNlIDU6IGRvbWFpbiByZWZl
cmVuY2VkIGJ5IG1jX2FkZHIgb24KKwkJCSogcHJpdmlsZWdlZCBwdi1vcHMgZG9tIGFuZCBpZiBt
Y19hZGRyIGlzIHZhbGlkLgorCQkJKiBOZXZlciB2YWxpZCBvbiBEb21VLiAqLworCXVpbnQ2NF90
IG1jX3N0YXR1czsgLyogYmFuayBzdGF0dXMgKi8KKwl1aW50NjRfdCBtY19hZGRyOyAgIC8qIGJh
bmsgYWRkcmVzcywgb25seSB2YWxpZAorCQkJCQkgKiBpZiBhZGRyIGJpdCBpcyBzZXQgaW4gbWNf
c3RhdHVzICovCisJdWludDY0X3QgbWNfbWlzYzsKKwl1aW50NjRfdCBtY19jdHJsMjsKKwl1aW50
NjRfdCBtY190c2M7Cit9OworCisKK3N0cnVjdCBtY2luZm9fbXNyIHsKKwl1aW50NjRfdCByZWc7
ICAgLyogTVNSICovCisJdWludDY0X3QgdmFsdWU7IC8qIE1TUiB2YWx1ZSAqLworfTsKKworLyog
Y29udGFpbnMgbWMgaW5mb3JtYXRpb24gZnJvbSBvdGhlcgorICogb3IgYWRkaXRpb25hbCBtYyBN
U1JzICovCitzdHJ1Y3QgbWNpbmZvX2V4dGVuZGVkIHsKKwlzdHJ1Y3QgbWNpbmZvX2NvbW1vbiBj
b21tb247CisKKwkvKiBZb3UgY2FuIGZpbGwgdXAgdG8gZml2ZSByZWdpc3RlcnMuCisJICogSWYg
eW91IG5lZWQgbW9yZSwgdGhlbiB1c2UgdGhpcyBzdHJ1Y3R1cmUKKwkgKiBtdWx0aXBsZSB0aW1l
cy4gKi8KKworCXVpbnQzMl90IG1jX21zcnM7IC8qIE51bWJlciBvZiBtc3Igd2l0aCB2YWxpZCB2
YWx1ZXMuICovCisJLyoKKwkgKiBDdXJyZW50bHkgSW50ZWwgZXh0ZW5kZWQgTVNSICgzMi82NCkg
aW5jbHVkZSBhbGwgZ3AgcmVnaXN0ZXJzCisJICogYW5kIEUoUilGTEFHUywgRShSKUlQLCBFKFIp
TUlTQywgdXAgdG8gMTEvMTkgb2YgdGhlbSBtaWdodCBiZQorCSAqIHVzZWZ1bCBhdCBwcmVzZW50
LiBTbyBleHBhbmQgdGhpcyBhcnJheSB0byAxNi8zMiB0byBsZWF2ZSByb29tLgorCSAqLworCXN0
cnVjdCBtY2luZm9fbXNyIG1jX21zcltzaXplb2Yodm9pZCAqKSAqIDRdOworfTsKKworLyogUmVj
b3ZlcnkgQWN0aW9uIGZsYWdzLiBHaXZpbmcgcmVjb3ZlcnkgcmVzdWx0IGluZm9ybWF0aW9uIHRv
IERPTTAgKi8KKworLyogWGVuIHRha2VzIHN1Y2Nlc3NmdWwgcmVjb3ZlcnkgYWN0aW9uLCB0aGUg
ZXJyb3IgaXMgcmVjb3ZlcmVkICovCisjZGVmaW5lIFJFQ19BQ1RJT05fUkVDT1ZFUkVEICgweDEg
PDwgMCkKKy8qIE5vIGFjdGlvbiBpcyBwZXJmb3JtZWQgYnkgWEVOICovCisjZGVmaW5lIFJFQ19B
Q1RJT05fTk9ORSAoMHgxIDw8IDEpCisvKiBJdCdzIHBvc3NpYmxlIERPTTAgbWlnaHQgdGFrZSBh
Y3Rpb24gb3duZXJzaGlwIGluIHNvbWUgY2FzZSAqLworI2RlZmluZSBSRUNfQUNUSU9OX05FRURf
UkVTRVQgKDB4MSA8PCAyKQorCisvKiBEaWZmZXJlbnQgUmVjb3ZlcnkgQWN0aW9uIHR5cGVzLCBp
ZiB0aGUgYWN0aW9uIGlzIHBlcmZvcm1lZCBzdWNjZXNzZnVsbHksCisgKiBSRUNfQUNUSU9OX1JF
Q09WRVJFRCBmbGFnIHdpbGwgYmUgcmV0dXJuZWQuCisgKi8KKworLyogUGFnZSBPZmZsaW5lIEFj
dGlvbiAqLworI2RlZmluZSBNQ19BQ1RJT05fUEFHRV9PRkZMSU5FICgweDEgPDwgMCkKKy8qIENQ
VSBvZmZsaW5lIEFjdGlvbiAqLworI2RlZmluZSBNQ19BQ1RJT05fQ1BVX09GRkxJTkUgKDB4MSA8
PCAxKQorLyogTDMgY2FjaGUgZGlzYWJsZSBBY3Rpb24gKi8KKyNkZWZpbmUgTUNfQUNUSU9OX0NB
Q0hFX1NIUklOSyAoMHgxIDw8IDIpCisKKy8qIEJlbG93IGludGVyZmFjZSB1c2VkIGJldHdlZW4g
WEVOL0RPTTAgZm9yIHBhc3NpbmcgWEVOJ3MgcmVjb3ZlcnkgYWN0aW9uCisgKiBpbmZvcm1hdGlv
biB0byBET00wLgorICogdXNhZ2UgU2VuYXJpbzogQWZ0ZXIgb2ZmbGluaW5nIGJyb2tlbiBwYWdl
LCBYRU4gbWlnaHQgcGFzcyBpdHMgcGFnZSBvZmZsaW5lCisgKiByZWNvdmVyeSBhY3Rpb24gcmVz
dWx0IHRvIERPTTAuIERPTTAgd2lsbCBzYXZlIHRoZSBpbmZvcm1hdGlvbiBpbgorICogbm9uLXZv
bGF0aWxlIG1lbW9yeSBmb3IgZnVydGhlciBwcm9hY3RpdmUgYWN0aW9ucywgc3VjaCBhcyBvZmZs
aW5pbmcgdGhlCisgKiBlYXN5IGJyb2tlbiBwYWdlIGVhcmxpZXIgd2hlbiBkb2luZyBuZXh0IHJl
Ym9vdC4KKyovCitzdHJ1Y3QgcGFnZV9vZmZsaW5lX2FjdGlvbiB7CisJLyogUGFyYW1zIGZvciBw
YXNzaW5nIHRoZSBvZmZsaW5lZCBwYWdlIG51bWJlciB0byBET00wICovCisJdWludDY0X3QgbWZu
OworCXVpbnQ2NF90IHN0YXR1czsKK307CisKK3N0cnVjdCBjcHVfb2ZmbGluZV9hY3Rpb24gewor
CS8qIFBhcmFtcyBmb3IgcGFzc2luZyB0aGUgaWRlbnRpdHkgb2YgdGhlIG9mZmxpbmVkIENQVSB0
byBET00wICovCisJdWludDMyX3QgbWNfc29ja2V0aWQ7CisJdWludDE2X3QgbWNfY29yZWlkOwor
CXVpbnQxNl90IG1jX2NvcmVfdGhyZWFkaWQ7Cit9OworCisjZGVmaW5lIE1BWF9VTklPTl9TSVpF
IDE2CitzdHJ1Y3QgbWNpbmZvX3JlY292ZXJ5IHsKKwlzdHJ1Y3QgbWNpbmZvX2NvbW1vbiBjb21t
b247CisJdWludDE2X3QgbWNfYmFuazsgLyogYmFuayBuciAqLworCS8qIFJlY292ZXJ5IEFjdGlv
biBGbGFncyBkZWZpbmVkIGFib3ZlIHN1Y2ggYXMgUkVDX0FDVElPTl9ET05FICovCisJdWludDhf
dCBhY3Rpb25fZmxhZ3M7CisJLyogUmVjb3ZlcnkgQWN0aW9uIHR5cGVzIGRlZmluZWQgYWJvdmUg
c3VjaCBhcyBNQ19BQ1RJT05fUEFHRV9PRkZMSU5FICovCisJdWludDhfdCBhY3Rpb25fdHlwZXM7
CisJLyogSW4gZnV0dXJlIGlmIG1vcmUgdGhhbiBvbmUgcmVjb3ZlcnkgYWN0aW9uIHBlcm1pdHRl
ZCBwZXIgZXJyb3IgYmFuaywKKwkgKiBhIG1jaW5mb19yZWNvdmVyeSBkYXRhIGFycmF5IHdpbGwg
YmUgcmV0dXJuZWQKKwkgKi8KKwl1bmlvbiB7CisJCXN0cnVjdCBwYWdlX29mZmxpbmVfYWN0aW9u
IHBhZ2VfcmV0aXJlOworCQlzdHJ1Y3QgY3B1X29mZmxpbmVfYWN0aW9uIGNwdV9vZmZsaW5lOwor
CQl1aW50OF90IHBhZFtNQVhfVU5JT05fU0laRV07CisJfSBhY3Rpb25faW5mbzsKK307CisKKwor
I2RlZmluZSBNQ0lORk9fSFlQRVJDQUxMU0laRQkxMDI0CisjZGVmaW5lIE1DSU5GT19NQVhTSVpF
CQk3NjgKKworc3RydWN0IG1jX2luZm8geworCS8qIE51bWJlciBvZiBtY2luZm9fKiBlbnRyaWVz
IGluIG1pX2RhdGEgKi8KKwl1aW50MzJfdCBtaV9uZW50cmllczsKKwl1aW50MzJfdCBfcGFkMDsK
Kwl1aW50NjRfdCBtaV9kYXRhWyhNQ0lORk9fTUFYU0laRSAtIDEpIC8gOF07Cit9OwordHlwZWRl
ZiBzdHJ1Y3QgbWNfaW5mbyBtY19pbmZvX3Q7CitERUZJTkVfR1VFU1RfSEFORExFX1NUUlVDVCht
Y19pbmZvKTsKKworI2RlZmluZSBfX01DX01TUl9BUlJBWVNJWkUgOAorI2RlZmluZSBfX01DX05N
U1JTIDEKKyNkZWZpbmUgTUNfTkNBUFMJNwkvKiA3IENQVSBmZWF0dXJlIGZsYWcgd29yZHMgKi8K
KyNkZWZpbmUgTUNfQ0FQU19TVERfRURYCTAJLyogY3B1aWQgbGV2ZWwgMHgwMDAwMDAwMSAoJWVk
eCkgKi8KKyNkZWZpbmUgTUNfQ0FQU19BTURfRURYCTEJLyogY3B1aWQgbGV2ZWwgMHg4MDAwMDAw
MSAoJWVkeCkgKi8KKyNkZWZpbmUgTUNfQ0FQU19UTQkyCS8qIGNwdWlkIGxldmVsIDB4ODA4NjAw
MDEgKFRyYW5zTWV0YSkgKi8KKyNkZWZpbmUgTUNfQ0FQU19MSU5VWAkzCS8qIExpbnV4LWRlZmlu
ZWQgKi8KKyNkZWZpbmUgTUNfQ0FQU19TVERfRUNYCTQJLyogY3B1aWQgbGV2ZWwgMHgwMDAwMDAw
MSAoJWVjeCkgKi8KKyNkZWZpbmUgTUNfQ0FQU19WSUEJNQkvKiBjcHVpZCBsZXZlbCAweGMwMDAw
MDAxICovCisjZGVmaW5lIE1DX0NBUFNfQU1EX0VDWAk2CS8qIGNwdWlkIGxldmVsIDB4ODAwMDAw
MDEgKCVlY3gpICovCisKK3N0cnVjdCBtY2luZm9fbG9naWNhbF9jcHUgeworCXVpbnQzMl90IG1j
X2NwdW5yOworCXVpbnQzMl90IG1jX2NoaXBpZDsKKwl1aW50MTZfdCBtY19jb3JlaWQ7CisJdWlu
dDE2X3QgbWNfdGhyZWFkaWQ7CisJdWludDMyX3QgbWNfYXBpY2lkOworCXVpbnQzMl90IG1jX2Ns
dXN0ZXJpZDsKKwl1aW50MzJfdCBtY19uY29yZXM7CisJdWludDMyX3QgbWNfbmNvcmVzX2FjdGl2
ZTsKKwl1aW50MzJfdCBtY19udGhyZWFkczsKKwlpbnQzMl90IG1jX2NwdWlkX2xldmVsOworCXVp
bnQzMl90IG1jX2ZhbWlseTsKKwl1aW50MzJfdCBtY192ZW5kb3I7CisJdWludDMyX3QgbWNfbW9k
ZWw7CisJdWludDMyX3QgbWNfc3RlcDsKKwljaGFyIG1jX3ZlbmRvcmlkWzE2XTsKKwljaGFyIG1j
X2JyYW5kaWRbNjRdOworCXVpbnQzMl90IG1jX2NwdV9jYXBzW01DX05DQVBTXTsKKwl1aW50MzJf
dCBtY19jYWNoZV9zaXplOworCXVpbnQzMl90IG1jX2NhY2hlX2FsaWdubWVudDsKKwlpbnQzMl90
IG1jX25tc3J2YWxzOworCXN0cnVjdCBtY2luZm9fbXNyIG1jX21zcnZhbHVlc1tfX01DX01TUl9B
UlJBWVNJWkVdOworfTsKK3R5cGVkZWYgc3RydWN0IG1jaW5mb19sb2dpY2FsX2NwdSBtY2luZm9f
bG9naWNhbF9jcHVfdDsKK0RFRklORV9HVUVTVF9IQU5ETEVfU1RSVUNUKG1jaW5mb19sb2dpY2Fs
X2NwdSk7CisKKworLyoKKyAqIE9TJ3Mgc2hvdWxkIHVzZSB0aGVzZSBpbnN0ZWFkIG9mIHdyaXRp
bmcgdGhlaXIgb3duIGxvb2t1cCBmdW5jdGlvbgorICogZWFjaCB3aXRoIGl0cyBvd24gYnVncyBh
bmQgZHJhd2JhY2tzLgorICogV2UgdXNlIG1hY3JvcyBpbnN0ZWFkIG9mIHN0YXRpYyBpbmxpbmUg
ZnVuY3Rpb25zIHRvIGFsbG93IGd1ZXN0cworICogdG8gaW5jbHVkZSB0aGlzIGhlYWRlciBpbiBh
c3NlbWJseSBmaWxlcyAoKi5TKS4KKyAqLworLyogUHJvdG90eXBlOgorICogICAgdWludDMyX3Qg
eDg2X21jaW5mb19uZW50cmllcyhzdHJ1Y3QgbWNfaW5mbyAqbWkpOworICovCisjZGVmaW5lIHg4
Nl9tY2luZm9fbmVudHJpZXMoX21pKSAgICBcCisgICAgKChfbWkpLT5taV9uZW50cmllcykKKy8q
IFByb3RvdHlwZToKKyAqICAgIHN0cnVjdCBtY2luZm9fY29tbW9uICp4ODZfbWNpbmZvX2ZpcnN0
KHN0cnVjdCBtY19pbmZvICptaSk7CisgKi8KKyNkZWZpbmUgeDg2X21jaW5mb19maXJzdChfbWkp
ICAgICAgIFwKKyAgICAoKHN0cnVjdCBtY2luZm9fY29tbW9uICopKF9taSktPm1pX2RhdGEpCisv
KiBQcm90b3R5cGU6CisgKiAgICBzdHJ1Y3QgbWNpbmZvX2NvbW1vbiAqeDg2X21jaW5mb19uZXh0
KHN0cnVjdCBtY2luZm9fY29tbW9uICptaWMpOworICovCisjZGVmaW5lIHg4Nl9tY2luZm9fbmV4
dChfbWljKSAgICAgICBcCisgICAgKChzdHJ1Y3QgbWNpbmZvX2NvbW1vbiAqKSgodWludDhfdCAq
KShfbWljKSArIChfbWljKS0+c2l6ZSkpCisKKy8qIFByb3RvdHlwZToKKyAqICAgIHZvaWQgeDg2
X21jaW5mb19sb29rdXAodm9pZCAqcmV0LCBzdHJ1Y3QgbWNfaW5mbyAqbWksIHVpbnQxNl90IHR5
cGUpOworICovCisKK3N0YXRpYyBpbmxpbmUgdm9pZCB4ODZfbWNpbmZvX2xvb2t1cAorCShzdHJ1
Y3QgbWNpbmZvX2NvbW1vbiAqKnJldCwgc3RydWN0IG1jX2luZm8gKm1pLCB1aW50MTZfdCB0eXBl
KQoreworCXVpbnQzMl90IGZvdW5kID0gMCwgaTsKKwlzdHJ1Y3QgbWNpbmZvX2NvbW1vbiAqbWlj
OworCisJKnJldCA9IE5VTEw7CisJaWYgKCFtaSkKKwkJcmV0dXJuOworCW1pYyA9IHg4Nl9tY2lu
Zm9fZmlyc3QobWkpOworCisJZm9yIChpID0gMDsgaSA8IHg4Nl9tY2luZm9fbmVudHJpZXMobWkp
OyBpKyspIHsKKwkJaWYgKG1pYy0+dHlwZSA9PSB0eXBlKSB7CisJCQlmb3VuZCA9IDE7CisJCQli
cmVhazsKKwkJfQorCQltaWMgPSB4ODZfbWNpbmZvX25leHQobWljKTsKKwl9CisKKwkqcmV0ID0g
Zm91bmQgPyBtaWMgOiBOVUxMOworfQorLyogVXNlY2FzZSAxCisgKiBSZWdpc3RlciBtYWNoaW5l
IGNoZWNrIHRyYXAgY2FsbGJhY2sgaGFuZGxlcgorICogICAgKGFscmVhZHkgZG9uZSB2aWEgInNl
dF90cmFwX3RhYmxlIiBoeXBlcmNhbGwpCisgKi8KKworLyogVXNlY2FzZSAyCisgKiBEb20wIHJl
Z2lzdGVycyBtYWNoaW5lIGNoZWNrIGV2ZW50IGNhbGxiYWNrIGhhbmRsZXIKKyAqIGRvbmUgYnkg
RVZUQ0hOT1BfYmluZF92aXJxCisgKi8KKworLyogVXNlY2FzZSAzCisgKiBGZXRjaCBtYWNoaW5l
IGNoZWNrIGRhdGEgZnJvbSBoeXBlcnZpc29yLgorICogTm90ZSwgdGhpcyBoeXBlcmNhbGwgaXMg
c3BlY2lhbCwgYmVjYXVzZSBib3RoIERvbTAgYW5kIERvbVUgbXVzdCB1c2UgdGhpcy4KKyAqLwor
I2RlZmluZSBYRU5fTUNfZmV0Y2ggICAgICAgICAgICAxCitzdHJ1Y3QgeGVuX21jX2ZldGNoIHsK
KyAgICAvKiBJTi9PVVQgdmFyaWFibGVzLgorCSAqIElOOiBYRU5fTUNfTk9OVVJHRU5ULCBYRU5f
TUNfVVJHRU5ULAorCSAqIFhFTl9NQ19BQ0sgaWYgYWNrJ2tpbmcgYW4gZWFybGllciBmZXRjaAor
CSAqIE9VVDogWEVOX01DX09LLCBYRU5fTUNfRkVUQ0hBSUxFRCwKKwkgKiBYRU5fTUNfTk9EQVRB
LCBYRU5fTUNfTk9NQVRDSAorCSovCisJdWludDMyX3QgZmxhZ3M7CisJdWludDMyX3QgX3BhZDA7
CisJLyogT1VUOiBpZCBmb3IgYWNrLCBJTjogaWQgd2UgYXJlIGFjaydpbmcgKi8KKwl1aW50NjRf
dCBmZXRjaF9pZDsKKworCS8qIE9VVCB2YXJpYWJsZXMuICovCisJR1VFU1RfSEFORExFKG1jX2lu
Zm8pIGRhdGE7Cit9OwordHlwZWRlZiBzdHJ1Y3QgeGVuX21jX2ZldGNoIHhlbl9tY19mZXRjaF90
OworREVGSU5FX0dVRVNUX0hBTkRMRV9TVFJVQ1QoeGVuX21jX2ZldGNoKTsKKworCisvKiBVc2Vj
YXNlIDQKKyAqIFRoaXMgdGVsbHMgdGhlIGh5cGVydmlzb3IgdG8gbm90aWZ5IGEgRG9tVSBhYm91
dCB0aGUgbWFjaGluZSBjaGVjayBlcnJvcgorICovCisjZGVmaW5lIFhFTl9NQ19ub3RpZnlkb21h
aW4gICAgIDIKK3N0cnVjdCB4ZW5fbWNfbm90aWZ5ZG9tYWluIHsKKwkvKiBJTiB2YXJpYWJsZXMu
ICovCisJdWludDE2X3QgbWNfZG9taWQ7LyogVGhlIHVucHJpdmlsZWdlZCBkb21haW4gdG8gbm90
aWZ5LiAqLworCXVpbnQxNl90IG1jX3ZjcHVpZDsvKiBUaGUgdmNwdSBpbiBtY19kb21pZCB0byBu
b3RpZnkuCisJCQkqIFVzdWFsbHkgZWNobydkIHZhbHVlIGZyb20gdGhlIGZldGNoIGh5cGVyY2Fs
bC4gKi8KKworCS8qIElOL09VVCB2YXJpYWJsZXMuICovCisJdWludDMyX3QgZmxhZ3M7CisKKy8q
IE9VVDogWEVOX01DX09LLCBYRU5fTUNfQ0FOTk9USEFORExFLCBYRU5fTUNfTk9UREVMSVZFUkVE
LCBYRU5fTUNfTk9NQVRDSCAqLworfTsKK3R5cGVkZWYgc3RydWN0IHhlbl9tY19ub3RpZnlkb21h
aW4geGVuX21jX25vdGlmeWRvbWFpbl90OworREVGSU5FX0dVRVNUX0hBTkRMRV9TVFJVQ1QoeGVu
X21jX25vdGlmeWRvbWFpbik7CisKKyNkZWZpbmUgWEVOX01DX3BoeXNjcHVpbmZvIDMKK3N0cnVj
dCB4ZW5fbWNfcGh5c2NwdWluZm8geworCS8qIElOL09VVCAqLworCXVpbnQzMl90IG5jcHVzOwor
CXVpbnQzMl90IF9wYWQwOworCS8qIE9VVCAqLworCUdVRVNUX0hBTkRMRShtY2luZm9fbG9naWNh
bF9jcHUpIGluZm87Cit9OworCisjZGVmaW5lIFhFTl9NQ19tc3JpbmplY3QgICAgNAorI2RlZmlu
ZSBNQ19NU1JJTkpfTUFYTVNSUyAgICAgICA4CitzdHJ1Y3QgeGVuX21jX21zcmluamVjdCB7CisJ
LyogSU4gKi8KKwl1aW50MzJfdCBtY2lual9jcHVucjsvKiB0YXJnZXQgcHJvY2Vzc29yIGlkICov
CisJdWludDMyX3QgbWNpbmpfZmxhZ3M7Lyogc2VlIE1DX01TUklOSl9GXyogYmVsb3cgKi8KKwl1
aW50MzJfdCBtY2lual9jb3VudDsvKiAwIC4uIGNvdW50LTEgaW4gYXJyYXkgYXJlIHZhbGlkICov
CisJdWludDMyX3QgX3BhZDA7CisJc3RydWN0IG1jaW5mb19tc3IgbWNpbmpfbXNyW01DX01TUklO
Sl9NQVhNU1JTXTsKK307CisKKy8qIEZsYWdzIGZvciBtY2lual9mbGFncyBhYm92ZTsgYml0cyAx
Ni0zMSBhcmUgcmVzZXJ2ZWQgKi8KKyNkZWZpbmUgTUNfTVNSSU5KX0ZfSU5URVJQT1NFICAgMHgx
CisKKyNkZWZpbmUgWEVOX01DX21jZWluamVjdCAgICA1CitzdHJ1Y3QgeGVuX21jX21jZWluamVj
dCB7CisJdW5zaWduZWQgaW50IG1jZWlual9jcHVucjsgICAgICAvKiB0YXJnZXQgcHJvY2Vzc29y
IGlkICovCit9OworCitzdHJ1Y3QgeGVuX21jIHsKKwl1aW50MzJfdCBjbWQ7CisJdWludDMyX3Qg
aW50ZXJmYWNlX3ZlcnNpb247IC8qIFhFTl9NQ0FfSU5URVJGQUNFX1ZFUlNJT04gKi8KKwl1bmlv
biB7CisJCXN0cnVjdCB4ZW5fbWNfZmV0Y2ggICAgICAgIG1jX2ZldGNoOworCQlzdHJ1Y3QgeGVu
X21jX25vdGlmeWRvbWFpbiBtY19ub3RpZnlkb21haW47CisJCXN0cnVjdCB4ZW5fbWNfcGh5c2Nw
dWluZm8gIG1jX3BoeXNjcHVpbmZvOworCQlzdHJ1Y3QgeGVuX21jX21zcmluamVjdCAgICBtY19t
c3JpbmplY3Q7CisJCXN0cnVjdCB4ZW5fbWNfbWNlaW5qZWN0ICAgIG1jX21jZWluamVjdDsKKwl9
IHU7Cit9OwordHlwZWRlZiBzdHJ1Y3QgeGVuX21jIHhlbl9tY190OworREVGSU5FX0dVRVNUX0hB
TkRMRV9TVFJVQ1QoeGVuX21jKTsKKworI2VuZGlmIC8qIF9fQVNTRU1CTFlfXyAqLworCisjZW5k
aWYgLyogX19YRU5fUFVCTElDX0FSQ0hfWDg2X01DQV9IX18gKi8KLS0gCjEuNi41LjYKCg==

--_002_DE8DF0795D48FD4CA783C40EC829233589D0SHSMSX101ccrcorpint_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--_002_DE8DF0795D48FD4CA783C40EC829233589D0SHSMSX101ccrcorpint_--


From xen-devel-bounces@lists.xensource.com Thu Dec 22 10:00:25 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 Dec 2011 10: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.xensource.com>)
	id 1RdfRR-0004B2-Ij; Thu, 22 Dec 2011 10:00:01 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1RdfRP-0004AO-G4
	for xen-devel@lists.xensource.com; Thu, 22 Dec 2011 10:00:00 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1324547990!6538900!1
X-Originating-IP: [134.134.136.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjQgPT4gMzE5NDEx\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16058 invoked from network); 22 Dec 2011 09:59:51 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-9.tower-174.messagelabs.com with SMTP;
	22 Dec 2011 09:59:51 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga102.jf.intel.com with ESMTP; 22 Dec 2011 01:59:49 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.67,352,1309762800"; d="scan'208,223";a="89278182"
Received: from pgsmsx602.gar.corp.intel.com ([10.221.43.81])
	by orsmga001.jf.intel.com with ESMTP; 22 Dec 2011 01:59:47 -0800
Received: from pgsmsx151.gar.corp.intel.com (172.30.236.41) by
	pgsmsx602.gar.corp.intel.com (10.221.43.81) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Thu, 22 Dec 2011 17:59:46 +0800
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	PGSMSX151.gar.corp.intel.com (172.30.236.41) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Thu, 22 Dec 2011 17:59:45 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.38]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.199]) with mapi id
	14.01.0355.002; Thu, 22 Dec 2011 17:59:44 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: "konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Thread-Topic: [PATCH 01/10] Add mcelog support from xen platform
Thread-Index: AczAkG036XwYNBn7SKyUXMKcFe2umw==
Date: Thu, 22 Dec 2011 09:59:43 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC829233589D0@SHSMSX101.ccr.corp.intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
Content-Type: multipart/mixed;
	boundary="_002_DE8DF0795D48FD4CA783C40EC829233589D0SHSMSX101ccrcorpint_"
MIME-Version: 1.0
Cc: "Jiang, Yunhong" <yunhong.jiang@intel.com>,
	"jeremy.fitzhardinge@citrix.com" <jeremy.fitzhardinge@citrix.com>
Subject: [Xen-devel] [PATCH 01/10] Add mcelog support from xen platform
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--_002_DE8DF0795D48FD4CA783C40EC829233589D0SHSMSX101ccrcorpint_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

>From 0e8de1ce0f13aa34aa6013e6a387ae5be78031ca Mon Sep 17 00:00:00 2001
From: Liu Jinsong <jinsong.liu@intel.com>
Date: Tue, 6 Dec 2011 18:08:12 +0800
Subject: [PATCH 01/10] Add mcelog support from xen platform

This patch backport from Jeremy's pvops commit a5ed1f3dae179158e385e9371462=
dd65d5e125c5,
which in turn backport from previous xen DOM0(2.6.18) cs: 75e5bfa7fbdc

When a MCE/CMCI error happens (or by polling), the related error
information will be sent to privileged pv-ops domain by XEN. This
patch will help to fetch the xen-logged information by hypercall
and then convert XEN-format log into Linux format MCELOG. It makes
using current available mcelog tools for native Linux possible.

With this patch, after mce/cmci error log information is sent to
pv-ops guest, Running mcelog tools in the guest, you will get same
detailed decoded mce information as in Native Linux.

Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
Signed-off-by: Ke, Liping <liping.ke@intel.com>
Signed-off-by: Jiang, Yunhong <yunhong.jiang@intel.com>
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
---
 arch/x86/include/asm/xen/hypercall.h |    8 +
 arch/x86/xen/enlighten.c             |    8 +-
 drivers/xen/Kconfig                  |    8 +
 drivers/xen/Makefile                 |    1 +
 drivers/xen/mcelog.c                 |  217 +++++++++++++++++
 include/xen/interface/xen-mca.h      |  429 ++++++++++++++++++++++++++++++=
++++
 6 files changed, 667 insertions(+), 4 deletions(-)
 create mode 100644 drivers/xen/mcelog.c
 create mode 100644 include/xen/interface/xen-mca.h

diff --git a/arch/x86/include/asm/xen/hypercall.h b/arch/x86/include/asm/xe=
n/hypercall.h
index 5728852..59c226d 100644
--- a/arch/x86/include/asm/xen/hypercall.h
+++ b/arch/x86/include/asm/xen/hypercall.h
@@ -48,6 +48,7 @@
 #include <xen/interface/sched.h>
 #include <xen/interface/physdev.h>
 #include <xen/interface/platform.h>
+#include <xen/interface/xen-mca.h>
=20
 /*
  * The hypercall asms have to meet several constraints:
@@ -302,6 +303,13 @@ HYPERVISOR_set_timer_op(u64 timeout)
 }
=20
 static inline int
+HYPERVISOR_mca(struct xen_mc *mc_op)
+{
+	mc_op->interface_version =3D XEN_MCA_INTERFACE_VERSION;
+	return _hypercall1(int, mca, mc_op);
+}
+
+static inline int
 HYPERVISOR_dom0_op(struct xen_platform_op *platform_op)
 {
 	platform_op->interface_version =3D XENPF_INTERFACE_VERSION;
diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index 9306320..b073e4c 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -242,14 +242,14 @@ static void __init xen_init_cpuid_mask(void)
 	unsigned int xsave_mask;
=20
 	cpuid_leaf1_edx_mask =3D
-		~((1 << X86_FEATURE_MCE)  |  /* disable MCE */
-		  (1 << X86_FEATURE_MCA)  |  /* disable MCA */
-		  (1 << X86_FEATURE_MTRR) |  /* disable MTRR */
+		~((1 << X86_FEATURE_MTRR) |  /* disable MTRR */
 		  (1 << X86_FEATURE_ACC));   /* thermal monitoring */
=20
 	if (!xen_initial_domain())
 		cpuid_leaf1_edx_mask &=3D
-			~((1 << X86_FEATURE_APIC) |  /* disable local APIC */
+			~((1 << X86_FEATURE_MCE)  |  /* disable MCE */
+			  (1 << X86_FEATURE_MCA)  |  /* disable MCA */
+			  (1 << X86_FEATURE_APIC) |  /* disable local APIC */
 			  (1 << X86_FEATURE_ACPI));  /* disable ACPI */
 	ax =3D 1;
 	xen_cpuid(&ax, &bx, &cx, &dx);
diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
index e8fb85f..eb2a327 100644
--- a/drivers/xen/Kconfig
+++ b/drivers/xen/Kconfig
@@ -117,6 +117,14 @@ config XEN_SYS_HYPERVISOR
 	 virtual environment, /sys/hypervisor will still be present,
 	 but will have no xen contents.
=20
+config XEN_MCE_LOG
+	bool "Xen platform mcelog"
+	depends on XEN_DOM0 && X86_64 && X86_MCE
+	default y
+	help
+	  Allow kernel fetching mce log from xen platform and
+	  converting it into linux mcelog format for mcelog tools
+
 config ACPI_PROCESSOR_XEN
 	tristate
 	depends on XEN_DOM0 && ACPI_PROCESSOR && CPU_FREQ
diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
index d42da53..405cce9 100644
--- a/drivers/xen/Makefile
+++ b/drivers/xen/Makefile
@@ -14,6 +14,7 @@ obj-$(CONFIG_XEN_GNTDEV)		+=3D xen-gntdev.o
 obj-$(CONFIG_XEN_GRANT_DEV_ALLOC)	+=3D xen-gntalloc.o
 obj-$(CONFIG_XENFS)			+=3D xenfs/
 obj-$(CONFIG_XEN_SYS_HYPERVISOR)	+=3D sys-hypervisor.o
+obj-$(CONFIG_XEN_MCE_LOG)		+=3D mcelog.o
 obj-$(CONFIG_XEN_PLATFORM_PCI)		+=3D xen-platform-pci.o
 obj-$(CONFIG_XEN_TMEM)			+=3D tmem.o
 obj-$(CONFIG_SWIOTLB_XEN)		+=3D swiotlb-xen.o
diff --git a/drivers/xen/mcelog.c b/drivers/xen/mcelog.c
new file mode 100644
index 0000000..892ca7b
--- /dev/null
+++ b/drivers/xen/mcelog.c
@@ -0,0 +1,217 @@
+/*************************************************************************=
*****
+ * mcelog.c
+ * Add Machine Check event Logging support in DOM0
+ *
+ * Driver for receiving and logging machine check event
+ *
+ * Copyright (c) 2008, 2009 Intel Corporation
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version 2
+ * as published by the Free Software Foundation; or, when distributed
+ * separately from the Linux kernel or incorporated into other
+ * software packages, subject to the following license:
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a=
 copy
+ * of this source file (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use, copy, modi=
fy,
+ * merge, publish, distribute, sublicense, and/or sell copies of the Softw=
are,
+ * and to permit persons to whom the Software is furnished to do so, subje=
ct to
+ * the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included=
 in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS=
 OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY=
,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL=
 THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEA=
LINGS
+ * IN THE SOFTWARE.
+ */
+
+#include <linux/module.h>
+#include <linux/init.h>
+#include <linux/types.h>
+#include <linux/kernel.h>
+#include <linux/slab.h>
+#include <xen/interface/xen.h>
+#include <asm/xen/hypervisor.h>
+#include <xen/events.h>
+#include <xen/interface/vcpu.h>
+#include <asm/xen/hypercall.h>
+#include <asm/mce.h>
+#include <xen/xen.h>
+
+static mc_info_t *g_mi;
+static mcinfo_logical_cpu_t *g_physinfo;
+static uint32_t ncpus;
+
+static int convert_log(struct mc_info *mi)
+{
+	struct mcinfo_common *mic =3D NULL;
+	struct mcinfo_global *mc_global;
+	struct mcinfo_bank *mc_bank;
+	struct mce m;
+	int i, found =3D 0;
+
+	x86_mcinfo_lookup(&mic, mi, MC_TYPE_GLOBAL);
+	WARN_ON(!mic);
+
+	mce_setup(&m);
+	mc_global =3D (struct mcinfo_global *)mic;
+	m.mcgstatus =3D mc_global->mc_gstatus;
+	m.apicid =3D mc_global->mc_apicid;
+	for (i =3D 0; i < ncpus; i++) {
+		if (g_physinfo[i].mc_apicid =3D=3D m.apicid) {
+			found =3D 1;
+			break;
+		}
+	}
+	WARN_ON(!found);
+
+	m.socketid =3D g_physinfo[i].mc_chipid;
+	m.cpu =3D m.extcpu =3D g_physinfo[i].mc_cpunr;
+	m.cpuvendor =3D (__u8)g_physinfo[i].mc_vendor;
+	m.mcgcap =3D g_physinfo[i].mc_msrvalues[0].value;
+	x86_mcinfo_lookup(&mic, mi, MC_TYPE_BANK);
+	do {
+		if (mic =3D=3D NULL || mic->size =3D=3D 0)
+			break;
+		if (mic->type =3D=3D MC_TYPE_BANK) {
+			mc_bank =3D (struct mcinfo_bank *)mic;
+			m.misc =3D mc_bank->mc_misc;
+			m.status =3D mc_bank->mc_status;
+			m.addr =3D mc_bank->mc_addr;
+			m.tsc =3D mc_bank->mc_tsc;
+			m.bank =3D mc_bank->mc_bank;
+			m.finished =3D 1;
+			/*log this record*/
+			mce_log(&m);
+		}
+		mic =3D x86_mcinfo_next(mic);
+	} while (1);
+
+	return 0;
+}
+
+/*pv_ops domain mce virq handler, logging physical mce error info*/
+static irqreturn_t mce_dom_interrupt(int irq, void *dev_id)
+{
+	xen_mc_t mc_op;
+	int result =3D 0;
+
+	mc_op.cmd =3D XEN_MC_fetch;
+	mc_op.interface_version =3D XEN_MCA_INTERFACE_VERSION;
+	set_xen_guest_handle(mc_op.u.mc_fetch.data, g_mi);
+urgent:
+	mc_op.u.mc_fetch.flags =3D XEN_MC_URGENT;
+	result =3D HYPERVISOR_mca(&mc_op);
+	if (result || mc_op.u.mc_fetch.flags & XEN_MC_NODATA ||
+			mc_op.u.mc_fetch.flags & XEN_MC_FETCHFAILED)
+		goto nonurgent;
+	else {
+		result =3D convert_log(g_mi);
+		if (result)
+			goto end;
+		/* After fetching the error event log entry from DOM0,
+		 * we need to dec the refcnt and release the entry.
+		 * The entry is reserved and inc refcnt when filling
+		 * the error log entry.
+		 */
+		mc_op.u.mc_fetch.flags =3D XEN_MC_URGENT | XEN_MC_ACK;
+		result =3D HYPERVISOR_mca(&mc_op);
+		goto urgent;
+	}
+nonurgent:
+	mc_op.u.mc_fetch.flags =3D XEN_MC_NONURGENT;
+	result =3D HYPERVISOR_mca(&mc_op);
+	if (result || mc_op.u.mc_fetch.flags & XEN_MC_NODATA ||
+			mc_op.u.mc_fetch.flags & XEN_MC_FETCHFAILED)
+		goto end;
+	else {
+		result =3D convert_log(g_mi);
+		if (result)
+			goto end;
+		/* After fetching the error event log entry from DOM0,
+		 * we need to dec the refcnt and release the entry. The
+		 * entry is reserved and inc refcnt when filling the
+		 * error log entry.
+		 */
+		mc_op.u.mc_fetch.flags =3D XEN_MC_NONURGENT | XEN_MC_ACK;
+		result =3D HYPERVISOR_mca(&mc_op);
+		goto nonurgent;
+	}
+end:
+	return IRQ_HANDLED;
+}
+
+static int bind_virq_for_mce(void)
+{
+	int ret;
+	xen_mc_t mc_op;
+
+	g_mi =3D kmalloc(sizeof(struct mc_info), GFP_KERNEL);
+
+	if (!g_mi)
+		return -ENOMEM;
+
+	/* Fetch physical CPU Numbers */
+	mc_op.cmd =3D XEN_MC_physcpuinfo;
+	mc_op.interface_version =3D XEN_MCA_INTERFACE_VERSION;
+	set_xen_guest_handle(mc_op.u.mc_physcpuinfo.info, g_physinfo);
+	ret =3D HYPERVISOR_mca(&mc_op);
+	if (ret) {
+		printk(KERN_ERR "MCE_DOM0_LOG: Fail to get physical CPU numbers\n");
+		kfree(g_mi);
+		return ret;
+	}
+
+	/* Fetch each CPU Physical Info for later reference*/
+	ncpus =3D mc_op.u.mc_physcpuinfo.ncpus;
+	g_physinfo =3D kmalloc(sizeof(struct mcinfo_logical_cpu)*ncpus,
+					GFP_KERNEL);
+	if (!g_physinfo) {
+		kfree(g_mi);
+		return -ENOMEM;
+	}
+	set_xen_guest_handle(mc_op.u.mc_physcpuinfo.info, g_physinfo);
+	ret =3D HYPERVISOR_mca(&mc_op);
+	if (ret) {
+		printk(KERN_ERR "MCE_DOM0_LOG: Fail to get physical CPUs info\n");
+		kfree(g_mi);
+		kfree(g_physinfo);
+		return ret;
+	}
+
+	ret  =3D bind_virq_to_irqhandler(VIRQ_MCA, 0,
+		mce_dom_interrupt, 0, "mce", NULL);
+
+	if (ret < 0) {
+		printk(KERN_ERR "MCE_DOM0_LOG: bind_virq for DOM0 failed\n");
+		return ret;
+	}
+
+	return 0;
+}
+
+static int __init mcelog_init(void)
+{
+	/* Only DOM0 is responsible for MCE logging */
+	if (xen_initial_domain())
+		return bind_virq_for_mce();
+
+	return 0;
+}
+
+
+static void __exit mcelog_cleanup(void)
+{
+	kfree(g_mi);
+	kfree(g_physinfo);
+}
+module_init(mcelog_init);
+module_exit(mcelog_cleanup);
+
+MODULE_LICENSE("GPL");
diff --git a/include/xen/interface/xen-mca.h b/include/xen/interface/xen-mc=
a.h
new file mode 100644
index 0000000..f31fdab
--- /dev/null
+++ b/include/xen/interface/xen-mca.h
@@ -0,0 +1,429 @@
+/*************************************************************************=
*****
+ * arch-x86/mca.h
+ *
+ * Contributed by Advanced Micro Devices, Inc.
+ * Author: Christoph Egger <Christoph.Egger@amd.com>
+ *
+ * Guest OS machine check interface to x86 Xen.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a=
 copy
+ * of this software and associated documentation files (the "Software"), t=
o
+ * deal in the Software without restriction, including without limitation =
the
+ * rights to use, copy, modify, merge, publish, distribute, sublicense, an=
d/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.
+ */
+
+/* Full MCA functionality has the following Usecases from the guest side:
+ *
+ * Must have's:
+ * 1. Dom0 and DomU register machine check trap callback handlers
+ *    (already done via "set_trap_table" hypercall)
+ * 2. Dom0 registers machine check event callback handler
+ *    (doable via EVTCHNOP_bind_virq)
+ * 3. Dom0 and DomU fetches machine check data
+ * 4. Dom0 wants Xen to notify a DomU
+ * 5. Dom0 gets DomU ID from physical address
+ * 6. Dom0 wants Xen to kill DomU (already done for "xm destroy")
+ *
+ * Nice to have's:
+ * 7. Dom0 wants Xen to deactivate a physical CPU
+ *    This is better done as separate task, physical CPU hotplugging,
+ *    and hypercall(s) should be sysctl's
+ * 8. Page migration proposed from Xen NUMA work, where Dom0 can tell Xen =
to
+ *    move a DomU (or Dom0 itself) away from a malicious page
+ *    producing correctable errors.
+ * 9. offlining physical page:
+ *    Xen free's and never re-uses a certain physical page.
+ * 10. Testfacility: Allow Dom0 to write values into machine check MSR's
+ *     and tell Xen to trigger a machine check
+ */
+
+#ifndef __XEN_PUBLIC_ARCH_X86_MCA_H__
+#define __XEN_PUBLIC_ARCH_X86_MCA_H__
+
+/* Hypercall */
+#define __HYPERVISOR_mca __HYPERVISOR_arch_0
+
+/*
+ * The xen-unstable repo has interface version 0x03000001; out interface
+ * is incompatible with that and any future minor revisions, so we
+ * choose a different version number range that is numerically less
+ * than that used in xen-unstable.
+ */
+#define XEN_MCA_INTERFACE_VERSION 0x01ecc003
+
+/* IN: Dom0 calls hypercall to retrieve nonurgent error log entry */
+#define XEN_MC_NONURGENT  0x0001
+/* IN: Dom0/DomU calls hypercall to retrieve urgent error log entry */
+#define XEN_MC_URGENT     0x0002
+/* IN: Dom0 acknowledges previosly-fetched error log entry */
+#define XEN_MC_ACK        0x0004
+
+/* OUT: All is ok */
+#define XEN_MC_OK           0x0
+/* OUT: Domain could not fetch data. */
+#define XEN_MC_FETCHFAILED  0x1
+/* OUT: There was no machine check data to fetch. */
+#define XEN_MC_NODATA       0x2
+/* OUT: Between notification time and this hypercall an other
+ *  (most likely) correctable error happened. The fetched data,
+ *  does not match the original machine check data. */
+#define XEN_MC_NOMATCH      0x4
+
+/* OUT: DomU did not register MC NMI handler. Try something else. */
+#define XEN_MC_CANNOTHANDLE 0x8
+/* OUT: Notifying DomU failed. Retry later or try something else. */
+#define XEN_MC_NOTDELIVERED 0x10
+/* Note, XEN_MC_CANNOTHANDLE and XEN_MC_NOTDELIVERED are mutually exclusiv=
e. */
+
+
+#ifndef __ASSEMBLY__
+
+#define VIRQ_MCA VIRQ_ARCH_0 /* G. (DOM0) Machine Check Architecture */
+
+/*
+ * Machine Check Architecure:
+ * structs are read-only and used to report all kinds of
+ * correctable and uncorrectable errors detected by the HW.
+ * Dom0 and DomU: register a handler to get notified.
+ * Dom0 only: Correctable errors are reported via VIRQ_MCA
+ */
+#define MC_TYPE_GLOBAL          0
+#define MC_TYPE_BANK            1
+#define MC_TYPE_EXTENDED        2
+#define MC_TYPE_RECOVERY        3
+
+struct mcinfo_common {
+	uint16_t type;      /* structure type */
+	uint16_t size;      /* size of this struct in bytes */
+};
+
+
+#define MC_FLAG_CORRECTABLE     (1 << 0)
+#define MC_FLAG_UNCORRECTABLE   (1 << 1)
+#define MC_FLAG_RECOVERABLE	(1 << 2)
+#define MC_FLAG_POLLED		(1 << 3)
+#define MC_FLAG_RESET		(1 << 4)
+#define MC_FLAG_CMCI		(1 << 5)
+#define MC_FLAG_MCE		(1 << 6)
+/* contains global x86 mc information */
+struct mcinfo_global {
+	struct mcinfo_common common;
+
+	/* running domain at the time in error (most likely
+	 * the impacted one) */
+	uint16_t mc_domid;
+	uint16_t mc_vcpuid; /* virtual cpu scheduled for mc_domid */
+	uint32_t mc_socketid; /* physical socket of the physical core */
+	uint16_t mc_coreid; /* physical impacted core */
+	uint16_t mc_core_threadid; /* core thread of physical core */
+	uint32_t mc_apicid;
+	uint32_t mc_flags;
+	uint64_t mc_gstatus; /* global status */
+};
+
+/* contains bank local x86 mc information */
+struct mcinfo_bank {
+	struct mcinfo_common common;
+
+	uint16_t mc_bank; /* bank nr */
+	uint16_t mc_domid; /* Usecase 5: domain referenced by mc_addr on
+			* privileged pv-ops dom and if mc_addr is valid.
+			* Never valid on DomU. */
+	uint64_t mc_status; /* bank status */
+	uint64_t mc_addr;   /* bank address, only valid
+					 * if addr bit is set in mc_status */
+	uint64_t mc_misc;
+	uint64_t mc_ctrl2;
+	uint64_t mc_tsc;
+};
+
+
+struct mcinfo_msr {
+	uint64_t reg;   /* MSR */
+	uint64_t value; /* MSR value */
+};
+
+/* contains mc information from other
+ * or additional mc MSRs */
+struct mcinfo_extended {
+	struct mcinfo_common common;
+
+	/* You can fill up to five registers.
+	 * If you need more, then use this structure
+	 * multiple times. */
+
+	uint32_t mc_msrs; /* Number of msr with valid values. */
+	/*
+	 * Currently Intel extended MSR (32/64) include all gp registers
+	 * and E(R)FLAGS, E(R)IP, E(R)MISC, up to 11/19 of them might be
+	 * useful at present. So expand this array to 16/32 to leave room.
+	 */
+	struct mcinfo_msr mc_msr[sizeof(void *) * 4];
+};
+
+/* Recovery Action flags. Giving recovery result information to DOM0 */
+
+/* Xen takes successful recovery action, the error is recovered */
+#define REC_ACTION_RECOVERED (0x1 << 0)
+/* No action is performed by XEN */
+#define REC_ACTION_NONE (0x1 << 1)
+/* It's possible DOM0 might take action ownership in some case */
+#define REC_ACTION_NEED_RESET (0x1 << 2)
+
+/* Different Recovery Action types, if the action is performed successfull=
y,
+ * REC_ACTION_RECOVERED flag will be returned.
+ */
+
+/* Page Offline Action */
+#define MC_ACTION_PAGE_OFFLINE (0x1 << 0)
+/* CPU offline Action */
+#define MC_ACTION_CPU_OFFLINE (0x1 << 1)
+/* L3 cache disable Action */
+#define MC_ACTION_CACHE_SHRINK (0x1 << 2)
+
+/* Below interface used between XEN/DOM0 for passing XEN's recovery action
+ * information to DOM0.
+ * usage Senario: After offlining broken page, XEN might pass its page off=
line
+ * recovery action result to DOM0. DOM0 will save the information in
+ * non-volatile memory for further proactive actions, such as offlining th=
e
+ * easy broken page earlier when doing next reboot.
+*/
+struct page_offline_action {
+	/* Params for passing the offlined page number to DOM0 */
+	uint64_t mfn;
+	uint64_t status;
+};
+
+struct cpu_offline_action {
+	/* Params for passing the identity of the offlined CPU to DOM0 */
+	uint32_t mc_socketid;
+	uint16_t mc_coreid;
+	uint16_t mc_core_threadid;
+};
+
+#define MAX_UNION_SIZE 16
+struct mcinfo_recovery {
+	struct mcinfo_common common;
+	uint16_t mc_bank; /* bank nr */
+	/* Recovery Action Flags defined above such as REC_ACTION_DONE */
+	uint8_t action_flags;
+	/* Recovery Action types defined above such as MC_ACTION_PAGE_OFFLINE */
+	uint8_t action_types;
+	/* In future if more than one recovery action permitted per error bank,
+	 * a mcinfo_recovery data array will be returned
+	 */
+	union {
+		struct page_offline_action page_retire;
+		struct cpu_offline_action cpu_offline;
+		uint8_t pad[MAX_UNION_SIZE];
+	} action_info;
+};
+
+
+#define MCINFO_HYPERCALLSIZE	1024
+#define MCINFO_MAXSIZE		768
+
+struct mc_info {
+	/* Number of mcinfo_* entries in mi_data */
+	uint32_t mi_nentries;
+	uint32_t _pad0;
+	uint64_t mi_data[(MCINFO_MAXSIZE - 1) / 8];
+};
+typedef struct mc_info mc_info_t;
+DEFINE_GUEST_HANDLE_STRUCT(mc_info);
+
+#define __MC_MSR_ARRAYSIZE 8
+#define __MC_NMSRS 1
+#define MC_NCAPS	7	/* 7 CPU feature flag words */
+#define MC_CAPS_STD_EDX	0	/* cpuid level 0x00000001 (%edx) */
+#define MC_CAPS_AMD_EDX	1	/* cpuid level 0x80000001 (%edx) */
+#define MC_CAPS_TM	2	/* cpuid level 0x80860001 (TransMeta) */
+#define MC_CAPS_LINUX	3	/* Linux-defined */
+#define MC_CAPS_STD_ECX	4	/* cpuid level 0x00000001 (%ecx) */
+#define MC_CAPS_VIA	5	/* cpuid level 0xc0000001 */
+#define MC_CAPS_AMD_ECX	6	/* cpuid level 0x80000001 (%ecx) */
+
+struct mcinfo_logical_cpu {
+	uint32_t mc_cpunr;
+	uint32_t mc_chipid;
+	uint16_t mc_coreid;
+	uint16_t mc_threadid;
+	uint32_t mc_apicid;
+	uint32_t mc_clusterid;
+	uint32_t mc_ncores;
+	uint32_t mc_ncores_active;
+	uint32_t mc_nthreads;
+	int32_t mc_cpuid_level;
+	uint32_t mc_family;
+	uint32_t mc_vendor;
+	uint32_t mc_model;
+	uint32_t mc_step;
+	char mc_vendorid[16];
+	char mc_brandid[64];
+	uint32_t mc_cpu_caps[MC_NCAPS];
+	uint32_t mc_cache_size;
+	uint32_t mc_cache_alignment;
+	int32_t mc_nmsrvals;
+	struct mcinfo_msr mc_msrvalues[__MC_MSR_ARRAYSIZE];
+};
+typedef struct mcinfo_logical_cpu mcinfo_logical_cpu_t;
+DEFINE_GUEST_HANDLE_STRUCT(mcinfo_logical_cpu);
+
+
+/*
+ * OS's should use these instead of writing their own lookup function
+ * each with its own bugs and drawbacks.
+ * We use macros instead of static inline functions to allow guests
+ * to include this header in assembly files (*.S).
+ */
+/* Prototype:
+ *    uint32_t x86_mcinfo_nentries(struct mc_info *mi);
+ */
+#define x86_mcinfo_nentries(_mi)    \
+    ((_mi)->mi_nentries)
+/* Prototype:
+ *    struct mcinfo_common *x86_mcinfo_first(struct mc_info *mi);
+ */
+#define x86_mcinfo_first(_mi)       \
+    ((struct mcinfo_common *)(_mi)->mi_data)
+/* Prototype:
+ *    struct mcinfo_common *x86_mcinfo_next(struct mcinfo_common *mic);
+ */
+#define x86_mcinfo_next(_mic)       \
+    ((struct mcinfo_common *)((uint8_t *)(_mic) + (_mic)->size))
+
+/* Prototype:
+ *    void x86_mcinfo_lookup(void *ret, struct mc_info *mi, uint16_t type)=
;
+ */
+
+static inline void x86_mcinfo_lookup
+	(struct mcinfo_common **ret, struct mc_info *mi, uint16_t type)
+{
+	uint32_t found =3D 0, i;
+	struct mcinfo_common *mic;
+
+	*ret =3D NULL;
+	if (!mi)
+		return;
+	mic =3D x86_mcinfo_first(mi);
+
+	for (i =3D 0; i < x86_mcinfo_nentries(mi); i++) {
+		if (mic->type =3D=3D type) {
+			found =3D 1;
+			break;
+		}
+		mic =3D x86_mcinfo_next(mic);
+	}
+
+	*ret =3D found ? mic : NULL;
+}
+/* Usecase 1
+ * Register machine check trap callback handler
+ *    (already done via "set_trap_table" hypercall)
+ */
+
+/* Usecase 2
+ * Dom0 registers machine check event callback handler
+ * done by EVTCHNOP_bind_virq
+ */
+
+/* Usecase 3
+ * Fetch machine check data from hypervisor.
+ * Note, this hypercall is special, because both Dom0 and DomU must use th=
is.
+ */
+#define XEN_MC_fetch            1
+struct xen_mc_fetch {
+    /* IN/OUT variables.
+	 * IN: XEN_MC_NONURGENT, XEN_MC_URGENT,
+	 * XEN_MC_ACK if ack'king an earlier fetch
+	 * OUT: XEN_MC_OK, XEN_MC_FETCHAILED,
+	 * XEN_MC_NODATA, XEN_MC_NOMATCH
+	*/
+	uint32_t flags;
+	uint32_t _pad0;
+	/* OUT: id for ack, IN: id we are ack'ing */
+	uint64_t fetch_id;
+
+	/* OUT variables. */
+	GUEST_HANDLE(mc_info) data;
+};
+typedef struct xen_mc_fetch xen_mc_fetch_t;
+DEFINE_GUEST_HANDLE_STRUCT(xen_mc_fetch);
+
+
+/* Usecase 4
+ * This tells the hypervisor to notify a DomU about the machine check erro=
r
+ */
+#define XEN_MC_notifydomain     2
+struct xen_mc_notifydomain {
+	/* IN variables. */
+	uint16_t mc_domid;/* The unprivileged domain to notify. */
+	uint16_t mc_vcpuid;/* The vcpu in mc_domid to notify.
+			* Usually echo'd value from the fetch hypercall. */
+
+	/* IN/OUT variables. */
+	uint32_t flags;
+
+/* OUT: XEN_MC_OK, XEN_MC_CANNOTHANDLE, XEN_MC_NOTDELIVERED, XEN_MC_NOMATC=
H */
+};
+typedef struct xen_mc_notifydomain xen_mc_notifydomain_t;
+DEFINE_GUEST_HANDLE_STRUCT(xen_mc_notifydomain);
+
+#define XEN_MC_physcpuinfo 3
+struct xen_mc_physcpuinfo {
+	/* IN/OUT */
+	uint32_t ncpus;
+	uint32_t _pad0;
+	/* OUT */
+	GUEST_HANDLE(mcinfo_logical_cpu) info;
+};
+
+#define XEN_MC_msrinject    4
+#define MC_MSRINJ_MAXMSRS       8
+struct xen_mc_msrinject {
+	/* IN */
+	uint32_t mcinj_cpunr;/* target processor id */
+	uint32_t mcinj_flags;/* see MC_MSRINJ_F_* below */
+	uint32_t mcinj_count;/* 0 .. count-1 in array are valid */
+	uint32_t _pad0;
+	struct mcinfo_msr mcinj_msr[MC_MSRINJ_MAXMSRS];
+};
+
+/* Flags for mcinj_flags above; bits 16-31 are reserved */
+#define MC_MSRINJ_F_INTERPOSE   0x1
+
+#define XEN_MC_mceinject    5
+struct xen_mc_mceinject {
+	unsigned int mceinj_cpunr;      /* target processor id */
+};
+
+struct xen_mc {
+	uint32_t cmd;
+	uint32_t interface_version; /* XEN_MCA_INTERFACE_VERSION */
+	union {
+		struct xen_mc_fetch        mc_fetch;
+		struct xen_mc_notifydomain mc_notifydomain;
+		struct xen_mc_physcpuinfo  mc_physcpuinfo;
+		struct xen_mc_msrinject    mc_msrinject;
+		struct xen_mc_mceinject    mc_mceinject;
+	} u;
+};
+typedef struct xen_mc xen_mc_t;
+DEFINE_GUEST_HANDLE_STRUCT(xen_mc);
+
+#endif /* __ASSEMBLY__ */
+
+#endif /* __XEN_PUBLIC_ARCH_X86_MCA_H__ */
--=20
1.6.5.6

--_002_DE8DF0795D48FD4CA783C40EC829233589D0SHSMSX101ccrcorpint_
Content-Type: application/octet-stream;
	name="0001-Add-mcelog-support-from-xen-platform.patch"
Content-Description: 0001-Add-mcelog-support-from-xen-platform.patch
Content-Disposition: attachment;
	filename="0001-Add-mcelog-support-from-xen-platform.patch"; size=25075;
	creation-date="Wed, 14 Dec 2011 15:20:15 GMT";
	modification-date="Wed, 14 Dec 2011 15:03:34 GMT"
Content-Transfer-Encoding: base64

RnJvbSAwZThkZTFjZTBmMTNhYTM0YWE2MDEzZTZhMzg3YWU1YmU3ODAzMWNhIE1vbiBTZXAgMTcg
MDA6MDA6MDAgMjAwMQpGcm9tOiBMaXUgSmluc29uZyA8amluc29uZy5saXVAaW50ZWwuY29tPgpE
YXRlOiBUdWUsIDYgRGVjIDIwMTEgMTg6MDg6MTIgKzA4MDAKU3ViamVjdDogW1BBVENIIDAxLzEw
XSBBZGQgbWNlbG9nIHN1cHBvcnQgZnJvbSB4ZW4gcGxhdGZvcm0KClRoaXMgcGF0Y2ggYmFja3Bv
cnQgZnJvbSBKZXJlbXkncyBwdm9wcyBjb21taXQgYTVlZDFmM2RhZTE3OTE1OGUzODVlOTM3MTQ2
MmRkNjVkNWUxMjVjNSwKd2hpY2ggaW4gdHVybiBiYWNrcG9ydCBmcm9tIHByZXZpb3VzIHhlbiBE
T00wKDIuNi4xOCkgY3M6IDc1ZTViZmE3ZmJkYwoKV2hlbiBhIE1DRS9DTUNJIGVycm9yIGhhcHBl
bnMgKG9yIGJ5IHBvbGxpbmcpLCB0aGUgcmVsYXRlZCBlcnJvcgppbmZvcm1hdGlvbiB3aWxsIGJl
IHNlbnQgdG8gcHJpdmlsZWdlZCBwdi1vcHMgZG9tYWluIGJ5IFhFTi4gVGhpcwpwYXRjaCB3aWxs
IGhlbHAgdG8gZmV0Y2ggdGhlIHhlbi1sb2dnZWQgaW5mb3JtYXRpb24gYnkgaHlwZXJjYWxsCmFu
ZCB0aGVuIGNvbnZlcnQgWEVOLWZvcm1hdCBsb2cgaW50byBMaW51eCBmb3JtYXQgTUNFTE9HLiBJ
dCBtYWtlcwp1c2luZyBjdXJyZW50IGF2YWlsYWJsZSBtY2Vsb2cgdG9vbHMgZm9yIG5hdGl2ZSBM
aW51eCBwb3NzaWJsZS4KCldpdGggdGhpcyBwYXRjaCwgYWZ0ZXIgbWNlL2NtY2kgZXJyb3IgbG9n
IGluZm9ybWF0aW9uIGlzIHNlbnQgdG8KcHYtb3BzIGd1ZXN0LCBSdW5uaW5nIG1jZWxvZyB0b29s
cyBpbiB0aGUgZ3Vlc3QsIHlvdSB3aWxsIGdldCBzYW1lCmRldGFpbGVkIGRlY29kZWQgbWNlIGlu
Zm9ybWF0aW9uIGFzIGluIE5hdGl2ZSBMaW51eC4KClNpZ25lZC1vZmYtYnk6IExpdSwgSmluc29u
ZyA8amluc29uZy5saXVAaW50ZWwuY29tPgpTaWduZWQtb2ZmLWJ5OiBLZSwgTGlwaW5nIDxsaXBp
bmcua2VAaW50ZWwuY29tPgpTaWduZWQtb2ZmLWJ5OiBKaWFuZywgWXVuaG9uZyA8eXVuaG9uZy5q
aWFuZ0BpbnRlbC5jb20+ClNpZ25lZC1vZmYtYnk6IEplcmVteSBGaXR6aGFyZGluZ2UgPGplcmVt
eS5maXR6aGFyZGluZ2VAY2l0cml4LmNvbT4KLS0tCiBhcmNoL3g4Ni9pbmNsdWRlL2FzbS94ZW4v
aHlwZXJjYWxsLmggfCAgICA4ICsKIGFyY2gveDg2L3hlbi9lbmxpZ2h0ZW4uYyAgICAgICAgICAg
ICB8ICAgIDggKy0KIGRyaXZlcnMveGVuL0tjb25maWcgICAgICAgICAgICAgICAgICB8ICAgIDgg
KwogZHJpdmVycy94ZW4vTWFrZWZpbGUgICAgICAgICAgICAgICAgIHwgICAgMSArCiBkcml2ZXJz
L3hlbi9tY2Vsb2cuYyAgICAgICAgICAgICAgICAgfCAgMjE3ICsrKysrKysrKysrKysrKysrCiBp
bmNsdWRlL3hlbi9pbnRlcmZhY2UveGVuLW1jYS5oICAgICAgfCAgNDI5ICsrKysrKysrKysrKysr
KysrKysrKysrKysrKysrKysrKysKIDYgZmlsZXMgY2hhbmdlZCwgNjY3IGluc2VydGlvbnMoKyks
IDQgZGVsZXRpb25zKC0pCiBjcmVhdGUgbW9kZSAxMDA2NDQgZHJpdmVycy94ZW4vbWNlbG9nLmMK
IGNyZWF0ZSBtb2RlIDEwMDY0NCBpbmNsdWRlL3hlbi9pbnRlcmZhY2UveGVuLW1jYS5oCgpkaWZm
IC0tZ2l0IGEvYXJjaC94ODYvaW5jbHVkZS9hc20veGVuL2h5cGVyY2FsbC5oIGIvYXJjaC94ODYv
aW5jbHVkZS9hc20veGVuL2h5cGVyY2FsbC5oCmluZGV4IDU3Mjg4NTIuLjU5YzIyNmQgMTAwNjQ0
Ci0tLSBhL2FyY2gveDg2L2luY2x1ZGUvYXNtL3hlbi9oeXBlcmNhbGwuaAorKysgYi9hcmNoL3g4
Ni9pbmNsdWRlL2FzbS94ZW4vaHlwZXJjYWxsLmgKQEAgLTQ4LDYgKzQ4LDcgQEAKICNpbmNsdWRl
IDx4ZW4vaW50ZXJmYWNlL3NjaGVkLmg+CiAjaW5jbHVkZSA8eGVuL2ludGVyZmFjZS9waHlzZGV2
Lmg+CiAjaW5jbHVkZSA8eGVuL2ludGVyZmFjZS9wbGF0Zm9ybS5oPgorI2luY2x1ZGUgPHhlbi9p
bnRlcmZhY2UveGVuLW1jYS5oPgogCiAvKgogICogVGhlIGh5cGVyY2FsbCBhc21zIGhhdmUgdG8g
bWVldCBzZXZlcmFsIGNvbnN0cmFpbnRzOgpAQCAtMzAyLDYgKzMwMywxMyBAQCBIWVBFUlZJU09S
X3NldF90aW1lcl9vcCh1NjQgdGltZW91dCkKIH0KIAogc3RhdGljIGlubGluZSBpbnQKK0hZUEVS
VklTT1JfbWNhKHN0cnVjdCB4ZW5fbWMgKm1jX29wKQoreworCW1jX29wLT5pbnRlcmZhY2VfdmVy
c2lvbiA9IFhFTl9NQ0FfSU5URVJGQUNFX1ZFUlNJT047CisJcmV0dXJuIF9oeXBlcmNhbGwxKGlu
dCwgbWNhLCBtY19vcCk7Cit9CisKK3N0YXRpYyBpbmxpbmUgaW50CiBIWVBFUlZJU09SX2RvbTBf
b3Aoc3RydWN0IHhlbl9wbGF0Zm9ybV9vcCAqcGxhdGZvcm1fb3ApCiB7CiAJcGxhdGZvcm1fb3At
PmludGVyZmFjZV92ZXJzaW9uID0gWEVOUEZfSU5URVJGQUNFX1ZFUlNJT047CmRpZmYgLS1naXQg
YS9hcmNoL3g4Ni94ZW4vZW5saWdodGVuLmMgYi9hcmNoL3g4Ni94ZW4vZW5saWdodGVuLmMKaW5k
ZXggOTMwNjMyMC4uYjA3M2U0YyAxMDA2NDQKLS0tIGEvYXJjaC94ODYveGVuL2VubGlnaHRlbi5j
CisrKyBiL2FyY2gveDg2L3hlbi9lbmxpZ2h0ZW4uYwpAQCAtMjQyLDE0ICsyNDIsMTQgQEAgc3Rh
dGljIHZvaWQgX19pbml0IHhlbl9pbml0X2NwdWlkX21hc2sodm9pZCkKIAl1bnNpZ25lZCBpbnQg
eHNhdmVfbWFzazsKIAogCWNwdWlkX2xlYWYxX2VkeF9tYXNrID0KLQkJfigoMSA8PCBYODZfRkVB
VFVSRV9NQ0UpICB8ICAvKiBkaXNhYmxlIE1DRSAqLwotCQkgICgxIDw8IFg4Nl9GRUFUVVJFX01D
QSkgIHwgIC8qIGRpc2FibGUgTUNBICovCi0JCSAgKDEgPDwgWDg2X0ZFQVRVUkVfTVRSUikgfCAg
LyogZGlzYWJsZSBNVFJSICovCisJCX4oKDEgPDwgWDg2X0ZFQVRVUkVfTVRSUikgfCAgLyogZGlz
YWJsZSBNVFJSICovCiAJCSAgKDEgPDwgWDg2X0ZFQVRVUkVfQUNDKSk7ICAgLyogdGhlcm1hbCBt
b25pdG9yaW5nICovCiAKIAlpZiAoIXhlbl9pbml0aWFsX2RvbWFpbigpKQogCQljcHVpZF9sZWFm
MV9lZHhfbWFzayAmPQotCQkJfigoMSA8PCBYODZfRkVBVFVSRV9BUElDKSB8ICAvKiBkaXNhYmxl
IGxvY2FsIEFQSUMgKi8KKwkJCX4oKDEgPDwgWDg2X0ZFQVRVUkVfTUNFKSAgfCAgLyogZGlzYWJs
ZSBNQ0UgKi8KKwkJCSAgKDEgPDwgWDg2X0ZFQVRVUkVfTUNBKSAgfCAgLyogZGlzYWJsZSBNQ0Eg
Ki8KKwkJCSAgKDEgPDwgWDg2X0ZFQVRVUkVfQVBJQykgfCAgLyogZGlzYWJsZSBsb2NhbCBBUElD
ICovCiAJCQkgICgxIDw8IFg4Nl9GRUFUVVJFX0FDUEkpKTsgIC8qIGRpc2FibGUgQUNQSSAqLwog
CWF4ID0gMTsKIAl4ZW5fY3B1aWQoJmF4LCAmYngsICZjeCwgJmR4KTsKZGlmZiAtLWdpdCBhL2Ry
aXZlcnMveGVuL0tjb25maWcgYi9kcml2ZXJzL3hlbi9LY29uZmlnCmluZGV4IGU4ZmI4NWYuLmVi
MmEzMjcgMTAwNjQ0Ci0tLSBhL2RyaXZlcnMveGVuL0tjb25maWcKKysrIGIvZHJpdmVycy94ZW4v
S2NvbmZpZwpAQCAtMTE3LDYgKzExNywxNCBAQCBjb25maWcgWEVOX1NZU19IWVBFUlZJU09SCiAJ
IHZpcnR1YWwgZW52aXJvbm1lbnQsIC9zeXMvaHlwZXJ2aXNvciB3aWxsIHN0aWxsIGJlIHByZXNl
bnQsCiAJIGJ1dCB3aWxsIGhhdmUgbm8geGVuIGNvbnRlbnRzLgogCitjb25maWcgWEVOX01DRV9M
T0cKKwlib29sICJYZW4gcGxhdGZvcm0gbWNlbG9nIgorCWRlcGVuZHMgb24gWEVOX0RPTTAgJiYg
WDg2XzY0ICYmIFg4Nl9NQ0UKKwlkZWZhdWx0IHkKKwloZWxwCisJICBBbGxvdyBrZXJuZWwgZmV0
Y2hpbmcgbWNlIGxvZyBmcm9tIHhlbiBwbGF0Zm9ybSBhbmQKKwkgIGNvbnZlcnRpbmcgaXQgaW50
byBsaW51eCBtY2Vsb2cgZm9ybWF0IGZvciBtY2Vsb2cgdG9vbHMKKwogY29uZmlnIEFDUElfUFJP
Q0VTU09SX1hFTgogCXRyaXN0YXRlCiAJZGVwZW5kcyBvbiBYRU5fRE9NMCAmJiBBQ1BJX1BST0NF
U1NPUiAmJiBDUFVfRlJFUQpkaWZmIC0tZ2l0IGEvZHJpdmVycy94ZW4vTWFrZWZpbGUgYi9kcml2
ZXJzL3hlbi9NYWtlZmlsZQppbmRleCBkNDJkYTUzLi40MDVjY2U5IDEwMDY0NAotLS0gYS9kcml2
ZXJzL3hlbi9NYWtlZmlsZQorKysgYi9kcml2ZXJzL3hlbi9NYWtlZmlsZQpAQCAtMTQsNiArMTQs
NyBAQCBvYmotJChDT05GSUdfWEVOX0dOVERFVikJCSs9IHhlbi1nbnRkZXYubwogb2JqLSQoQ09O
RklHX1hFTl9HUkFOVF9ERVZfQUxMT0MpCSs9IHhlbi1nbnRhbGxvYy5vCiBvYmotJChDT05GSUdf
WEVORlMpCQkJKz0geGVuZnMvCiBvYmotJChDT05GSUdfWEVOX1NZU19IWVBFUlZJU09SKQkrPSBz
eXMtaHlwZXJ2aXNvci5vCitvYmotJChDT05GSUdfWEVOX01DRV9MT0cpCQkrPSBtY2Vsb2cubwog
b2JqLSQoQ09ORklHX1hFTl9QTEFURk9STV9QQ0kpCQkrPSB4ZW4tcGxhdGZvcm0tcGNpLm8KIG9i
ai0kKENPTkZJR19YRU5fVE1FTSkJCQkrPSB0bWVtLm8KIG9iai0kKENPTkZJR19TV0lPVExCX1hF
TikJCSs9IHN3aW90bGIteGVuLm8KZGlmZiAtLWdpdCBhL2RyaXZlcnMveGVuL21jZWxvZy5jIGIv
ZHJpdmVycy94ZW4vbWNlbG9nLmMKbmV3IGZpbGUgbW9kZSAxMDA2NDQKaW5kZXggMDAwMDAwMC4u
ODkyY2E3YgotLS0gL2Rldi9udWxsCisrKyBiL2RyaXZlcnMveGVuL21jZWxvZy5jCkBAIC0wLDAg
KzEsMjE3IEBACisvKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqCisgKiBtY2Vsb2cuYworICogQWRkIE1h
Y2hpbmUgQ2hlY2sgZXZlbnQgTG9nZ2luZyBzdXBwb3J0IGluIERPTTAKKyAqCisgKiBEcml2ZXIg
Zm9yIHJlY2VpdmluZyBhbmQgbG9nZ2luZyBtYWNoaW5lIGNoZWNrIGV2ZW50CisgKgorICogQ29w
eXJpZ2h0IChjKSAyMDA4LCAyMDA5IEludGVsIENvcnBvcmF0aW9uCisgKgorICogVGhpcyBwcm9n
cmFtIGlzIGZyZWUgc29mdHdhcmU7IHlvdSBjYW4gcmVkaXN0cmlidXRlIGl0IGFuZC9vcgorICog
bW9kaWZ5IGl0IHVuZGVyIHRoZSB0ZXJtcyBvZiB0aGUgR05VIEdlbmVyYWwgUHVibGljIExpY2Vu
c2UgdmVyc2lvbiAyCisgKiBhcyBwdWJsaXNoZWQgYnkgdGhlIEZyZWUgU29mdHdhcmUgRm91bmRh
dGlvbjsgb3IsIHdoZW4gZGlzdHJpYnV0ZWQKKyAqIHNlcGFyYXRlbHkgZnJvbSB0aGUgTGludXgg
a2VybmVsIG9yIGluY29ycG9yYXRlZCBpbnRvIG90aGVyCisgKiBzb2Z0d2FyZSBwYWNrYWdlcywg
c3ViamVjdCB0byB0aGUgZm9sbG93aW5nIGxpY2Vuc2U6CisgKgorICogUGVybWlzc2lvbiBpcyBo
ZXJlYnkgZ3JhbnRlZCwgZnJlZSBvZiBjaGFyZ2UsIHRvIGFueSBwZXJzb24gb2J0YWluaW5nIGEg
Y29weQorICogb2YgdGhpcyBzb3VyY2UgZmlsZSAodGhlICJTb2Z0d2FyZSIpLCB0byBkZWFsIGlu
IHRoZSBTb2Z0d2FyZSB3aXRob3V0CisgKiByZXN0cmljdGlvbiwgaW5jbHVkaW5nIHdpdGhvdXQg
bGltaXRhdGlvbiB0aGUgcmlnaHRzIHRvIHVzZSwgY29weSwgbW9kaWZ5LAorICogbWVyZ2UsIHB1
Ymxpc2gsIGRpc3RyaWJ1dGUsIHN1YmxpY2Vuc2UsIGFuZC9vciBzZWxsIGNvcGllcyBvZiB0aGUg
U29mdHdhcmUsCisgKiBhbmQgdG8gcGVybWl0IHBlcnNvbnMgdG8gd2hvbSB0aGUgU29mdHdhcmUg
aXMgZnVybmlzaGVkIHRvIGRvIHNvLCBzdWJqZWN0IHRvCisgKiB0aGUgZm9sbG93aW5nIGNvbmRp
dGlvbnM6CisgKgorICogVGhlIGFib3ZlIGNvcHlyaWdodCBub3RpY2UgYW5kIHRoaXMgcGVybWlz
c2lvbiBub3RpY2Ugc2hhbGwgYmUgaW5jbHVkZWQgaW4KKyAqIGFsbCBjb3BpZXMgb3Igc3Vic3Rh
bnRpYWwgcG9ydGlvbnMgb2YgdGhlIFNvZnR3YXJlLgorICoKKyAqIFRIRSBTT0ZUV0FSRSBJUyBQ
Uk9WSURFRCAiQVMgSVMiLCBXSVRIT1VUIFdBUlJBTlRZIE9GIEFOWSBLSU5ELCBFWFBSRVNTIE9S
CisgKiBJTVBMSUVELCBJTkNMVURJTkcgQlVUIE5PVCBMSU1JVEVEIFRPIFRIRSBXQVJSQU5USUVT
IE9GIE1FUkNIQU5UQUJJTElUWSwKKyAqIEZJVE5FU1MgRk9SIEEgUEFSVElDVUxBUiBQVVJQT1NF
IEFORCBOT05JTkZSSU5HRU1FTlQuIElOIE5PIEVWRU5UIFNIQUxMIFRIRQorICogQVVUSE9SUyBP
UiBDT1BZUklHSFQgSE9MREVSUyBCRSBMSUFCTEUgRk9SIEFOWSBDTEFJTSwgREFNQUdFUyBPUiBP
VEhFUgorICogTElBQklMSVRZLCBXSEVUSEVSIElOIEFOIEFDVElPTiBPRiBDT05UUkFDVCwgVE9S
VCBPUiBPVEhFUldJU0UsIEFSSVNJTkcKKyAqIEZST00sIE9VVCBPRiBPUiBJTiBDT05ORUNUSU9O
IFdJVEggVEhFIFNPRlRXQVJFIE9SIFRIRSBVU0UgT1IgT1RIRVIgREVBTElOR1MKKyAqIElOIFRI
RSBTT0ZUV0FSRS4KKyAqLworCisjaW5jbHVkZSA8bGludXgvbW9kdWxlLmg+CisjaW5jbHVkZSA8
bGludXgvaW5pdC5oPgorI2luY2x1ZGUgPGxpbnV4L3R5cGVzLmg+CisjaW5jbHVkZSA8bGludXgv
a2VybmVsLmg+CisjaW5jbHVkZSA8bGludXgvc2xhYi5oPgorI2luY2x1ZGUgPHhlbi9pbnRlcmZh
Y2UveGVuLmg+CisjaW5jbHVkZSA8YXNtL3hlbi9oeXBlcnZpc29yLmg+CisjaW5jbHVkZSA8eGVu
L2V2ZW50cy5oPgorI2luY2x1ZGUgPHhlbi9pbnRlcmZhY2UvdmNwdS5oPgorI2luY2x1ZGUgPGFz
bS94ZW4vaHlwZXJjYWxsLmg+CisjaW5jbHVkZSA8YXNtL21jZS5oPgorI2luY2x1ZGUgPHhlbi94
ZW4uaD4KKworc3RhdGljIG1jX2luZm9fdCAqZ19taTsKK3N0YXRpYyBtY2luZm9fbG9naWNhbF9j
cHVfdCAqZ19waHlzaW5mbzsKK3N0YXRpYyB1aW50MzJfdCBuY3B1czsKKworc3RhdGljIGludCBj
b252ZXJ0X2xvZyhzdHJ1Y3QgbWNfaW5mbyAqbWkpCit7CisJc3RydWN0IG1jaW5mb19jb21tb24g
Km1pYyA9IE5VTEw7CisJc3RydWN0IG1jaW5mb19nbG9iYWwgKm1jX2dsb2JhbDsKKwlzdHJ1Y3Qg
bWNpbmZvX2JhbmsgKm1jX2Jhbms7CisJc3RydWN0IG1jZSBtOworCWludCBpLCBmb3VuZCA9IDA7
CisKKwl4ODZfbWNpbmZvX2xvb2t1cCgmbWljLCBtaSwgTUNfVFlQRV9HTE9CQUwpOworCVdBUk5f
T04oIW1pYyk7CisKKwltY2Vfc2V0dXAoJm0pOworCW1jX2dsb2JhbCA9IChzdHJ1Y3QgbWNpbmZv
X2dsb2JhbCAqKW1pYzsKKwltLm1jZ3N0YXR1cyA9IG1jX2dsb2JhbC0+bWNfZ3N0YXR1czsKKwlt
LmFwaWNpZCA9IG1jX2dsb2JhbC0+bWNfYXBpY2lkOworCWZvciAoaSA9IDA7IGkgPCBuY3B1czsg
aSsrKSB7CisJCWlmIChnX3BoeXNpbmZvW2ldLm1jX2FwaWNpZCA9PSBtLmFwaWNpZCkgeworCQkJ
Zm91bmQgPSAxOworCQkJYnJlYWs7CisJCX0KKwl9CisJV0FSTl9PTighZm91bmQpOworCisJbS5z
b2NrZXRpZCA9IGdfcGh5c2luZm9baV0ubWNfY2hpcGlkOworCW0uY3B1ID0gbS5leHRjcHUgPSBn
X3BoeXNpbmZvW2ldLm1jX2NwdW5yOworCW0uY3B1dmVuZG9yID0gKF9fdTgpZ19waHlzaW5mb1tp
XS5tY192ZW5kb3I7CisJbS5tY2djYXAgPSBnX3BoeXNpbmZvW2ldLm1jX21zcnZhbHVlc1swXS52
YWx1ZTsKKwl4ODZfbWNpbmZvX2xvb2t1cCgmbWljLCBtaSwgTUNfVFlQRV9CQU5LKTsKKwlkbyB7
CisJCWlmIChtaWMgPT0gTlVMTCB8fCBtaWMtPnNpemUgPT0gMCkKKwkJCWJyZWFrOworCQlpZiAo
bWljLT50eXBlID09IE1DX1RZUEVfQkFOSykgeworCQkJbWNfYmFuayA9IChzdHJ1Y3QgbWNpbmZv
X2JhbmsgKiltaWM7CisJCQltLm1pc2MgPSBtY19iYW5rLT5tY19taXNjOworCQkJbS5zdGF0dXMg
PSBtY19iYW5rLT5tY19zdGF0dXM7CisJCQltLmFkZHIgPSBtY19iYW5rLT5tY19hZGRyOworCQkJ
bS50c2MgPSBtY19iYW5rLT5tY190c2M7CisJCQltLmJhbmsgPSBtY19iYW5rLT5tY19iYW5rOwor
CQkJbS5maW5pc2hlZCA9IDE7CisJCQkvKmxvZyB0aGlzIHJlY29yZCovCisJCQltY2VfbG9nKCZt
KTsKKwkJfQorCQltaWMgPSB4ODZfbWNpbmZvX25leHQobWljKTsKKwl9IHdoaWxlICgxKTsKKwor
CXJldHVybiAwOworfQorCisvKnB2X29wcyBkb21haW4gbWNlIHZpcnEgaGFuZGxlciwgbG9nZ2lu
ZyBwaHlzaWNhbCBtY2UgZXJyb3IgaW5mbyovCitzdGF0aWMgaXJxcmV0dXJuX3QgbWNlX2RvbV9p
bnRlcnJ1cHQoaW50IGlycSwgdm9pZCAqZGV2X2lkKQoreworCXhlbl9tY190IG1jX29wOworCWlu
dCByZXN1bHQgPSAwOworCisJbWNfb3AuY21kID0gWEVOX01DX2ZldGNoOworCW1jX29wLmludGVy
ZmFjZV92ZXJzaW9uID0gWEVOX01DQV9JTlRFUkZBQ0VfVkVSU0lPTjsKKwlzZXRfeGVuX2d1ZXN0
X2hhbmRsZShtY19vcC51Lm1jX2ZldGNoLmRhdGEsIGdfbWkpOwordXJnZW50OgorCW1jX29wLnUu
bWNfZmV0Y2guZmxhZ3MgPSBYRU5fTUNfVVJHRU5UOworCXJlc3VsdCA9IEhZUEVSVklTT1JfbWNh
KCZtY19vcCk7CisJaWYgKHJlc3VsdCB8fCBtY19vcC51Lm1jX2ZldGNoLmZsYWdzICYgWEVOX01D
X05PREFUQSB8fAorCQkJbWNfb3AudS5tY19mZXRjaC5mbGFncyAmIFhFTl9NQ19GRVRDSEZBSUxF
RCkKKwkJZ290byBub251cmdlbnQ7CisJZWxzZSB7CisJCXJlc3VsdCA9IGNvbnZlcnRfbG9nKGdf
bWkpOworCQlpZiAocmVzdWx0KQorCQkJZ290byBlbmQ7CisJCS8qIEFmdGVyIGZldGNoaW5nIHRo
ZSBlcnJvciBldmVudCBsb2cgZW50cnkgZnJvbSBET00wLAorCQkgKiB3ZSBuZWVkIHRvIGRlYyB0
aGUgcmVmY250IGFuZCByZWxlYXNlIHRoZSBlbnRyeS4KKwkJICogVGhlIGVudHJ5IGlzIHJlc2Vy
dmVkIGFuZCBpbmMgcmVmY250IHdoZW4gZmlsbGluZworCQkgKiB0aGUgZXJyb3IgbG9nIGVudHJ5
LgorCQkgKi8KKwkJbWNfb3AudS5tY19mZXRjaC5mbGFncyA9IFhFTl9NQ19VUkdFTlQgfCBYRU5f
TUNfQUNLOworCQlyZXN1bHQgPSBIWVBFUlZJU09SX21jYSgmbWNfb3ApOworCQlnb3RvIHVyZ2Vu
dDsKKwl9Citub251cmdlbnQ6CisJbWNfb3AudS5tY19mZXRjaC5mbGFncyA9IFhFTl9NQ19OT05V
UkdFTlQ7CisJcmVzdWx0ID0gSFlQRVJWSVNPUl9tY2EoJm1jX29wKTsKKwlpZiAocmVzdWx0IHx8
IG1jX29wLnUubWNfZmV0Y2guZmxhZ3MgJiBYRU5fTUNfTk9EQVRBIHx8CisJCQltY19vcC51Lm1j
X2ZldGNoLmZsYWdzICYgWEVOX01DX0ZFVENIRkFJTEVEKQorCQlnb3RvIGVuZDsKKwllbHNlIHsK
KwkJcmVzdWx0ID0gY29udmVydF9sb2coZ19taSk7CisJCWlmIChyZXN1bHQpCisJCQlnb3RvIGVu
ZDsKKwkJLyogQWZ0ZXIgZmV0Y2hpbmcgdGhlIGVycm9yIGV2ZW50IGxvZyBlbnRyeSBmcm9tIERP
TTAsCisJCSAqIHdlIG5lZWQgdG8gZGVjIHRoZSByZWZjbnQgYW5kIHJlbGVhc2UgdGhlIGVudHJ5
LiBUaGUKKwkJICogZW50cnkgaXMgcmVzZXJ2ZWQgYW5kIGluYyByZWZjbnQgd2hlbiBmaWxsaW5n
IHRoZQorCQkgKiBlcnJvciBsb2cgZW50cnkuCisJCSAqLworCQltY19vcC51Lm1jX2ZldGNoLmZs
YWdzID0gWEVOX01DX05PTlVSR0VOVCB8IFhFTl9NQ19BQ0s7CisJCXJlc3VsdCA9IEhZUEVSVklT
T1JfbWNhKCZtY19vcCk7CisJCWdvdG8gbm9udXJnZW50OworCX0KK2VuZDoKKwlyZXR1cm4gSVJR
X0hBTkRMRUQ7Cit9CisKK3N0YXRpYyBpbnQgYmluZF92aXJxX2Zvcl9tY2Uodm9pZCkKK3sKKwlp
bnQgcmV0OworCXhlbl9tY190IG1jX29wOworCisJZ19taSA9IGttYWxsb2Moc2l6ZW9mKHN0cnVj
dCBtY19pbmZvKSwgR0ZQX0tFUk5FTCk7CisKKwlpZiAoIWdfbWkpCisJCXJldHVybiAtRU5PTUVN
OworCisJLyogRmV0Y2ggcGh5c2ljYWwgQ1BVIE51bWJlcnMgKi8KKwltY19vcC5jbWQgPSBYRU5f
TUNfcGh5c2NwdWluZm87CisJbWNfb3AuaW50ZXJmYWNlX3ZlcnNpb24gPSBYRU5fTUNBX0lOVEVS
RkFDRV9WRVJTSU9OOworCXNldF94ZW5fZ3Vlc3RfaGFuZGxlKG1jX29wLnUubWNfcGh5c2NwdWlu
Zm8uaW5mbywgZ19waHlzaW5mbyk7CisJcmV0ID0gSFlQRVJWSVNPUl9tY2EoJm1jX29wKTsKKwlp
ZiAocmV0KSB7CisJCXByaW50ayhLRVJOX0VSUiAiTUNFX0RPTTBfTE9HOiBGYWlsIHRvIGdldCBw
aHlzaWNhbCBDUFUgbnVtYmVyc1xuIik7CisJCWtmcmVlKGdfbWkpOworCQlyZXR1cm4gcmV0Owor
CX0KKworCS8qIEZldGNoIGVhY2ggQ1BVIFBoeXNpY2FsIEluZm8gZm9yIGxhdGVyIHJlZmVyZW5j
ZSovCisJbmNwdXMgPSBtY19vcC51Lm1jX3BoeXNjcHVpbmZvLm5jcHVzOworCWdfcGh5c2luZm8g
PSBrbWFsbG9jKHNpemVvZihzdHJ1Y3QgbWNpbmZvX2xvZ2ljYWxfY3B1KSpuY3B1cywKKwkJCQkJ
R0ZQX0tFUk5FTCk7CisJaWYgKCFnX3BoeXNpbmZvKSB7CisJCWtmcmVlKGdfbWkpOworCQlyZXR1
cm4gLUVOT01FTTsKKwl9CisJc2V0X3hlbl9ndWVzdF9oYW5kbGUobWNfb3AudS5tY19waHlzY3B1
aW5mby5pbmZvLCBnX3BoeXNpbmZvKTsKKwlyZXQgPSBIWVBFUlZJU09SX21jYSgmbWNfb3ApOwor
CWlmIChyZXQpIHsKKwkJcHJpbnRrKEtFUk5fRVJSICJNQ0VfRE9NMF9MT0c6IEZhaWwgdG8gZ2V0
IHBoeXNpY2FsIENQVXMgaW5mb1xuIik7CisJCWtmcmVlKGdfbWkpOworCQlrZnJlZShnX3BoeXNp
bmZvKTsKKwkJcmV0dXJuIHJldDsKKwl9CisKKwlyZXQgID0gYmluZF92aXJxX3RvX2lycWhhbmRs
ZXIoVklSUV9NQ0EsIDAsCisJCW1jZV9kb21faW50ZXJydXB0LCAwLCAibWNlIiwgTlVMTCk7CisK
KwlpZiAocmV0IDwgMCkgeworCQlwcmludGsoS0VSTl9FUlIgIk1DRV9ET00wX0xPRzogYmluZF92
aXJxIGZvciBET00wIGZhaWxlZFxuIik7CisJCXJldHVybiByZXQ7CisJfQorCisJcmV0dXJuIDA7
Cit9CisKK3N0YXRpYyBpbnQgX19pbml0IG1jZWxvZ19pbml0KHZvaWQpCit7CisJLyogT25seSBE
T00wIGlzIHJlc3BvbnNpYmxlIGZvciBNQ0UgbG9nZ2luZyAqLworCWlmICh4ZW5faW5pdGlhbF9k
b21haW4oKSkKKwkJcmV0dXJuIGJpbmRfdmlycV9mb3JfbWNlKCk7CisKKwlyZXR1cm4gMDsKK30K
KworCitzdGF0aWMgdm9pZCBfX2V4aXQgbWNlbG9nX2NsZWFudXAodm9pZCkKK3sKKwlrZnJlZShn
X21pKTsKKwlrZnJlZShnX3BoeXNpbmZvKTsKK30KK21vZHVsZV9pbml0KG1jZWxvZ19pbml0KTsK
K21vZHVsZV9leGl0KG1jZWxvZ19jbGVhbnVwKTsKKworTU9EVUxFX0xJQ0VOU0UoIkdQTCIpOwpk
aWZmIC0tZ2l0IGEvaW5jbHVkZS94ZW4vaW50ZXJmYWNlL3hlbi1tY2EuaCBiL2luY2x1ZGUveGVu
L2ludGVyZmFjZS94ZW4tbWNhLmgKbmV3IGZpbGUgbW9kZSAxMDA2NDQKaW5kZXggMDAwMDAwMC4u
ZjMxZmRhYgotLS0gL2Rldi9udWxsCisrKyBiL2luY2x1ZGUveGVuL2ludGVyZmFjZS94ZW4tbWNh
LmgKQEAgLTAsMCArMSw0MjkgQEAKKy8qKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioKKyAqIGFyY2gteDg2
L21jYS5oCisgKgorICogQ29udHJpYnV0ZWQgYnkgQWR2YW5jZWQgTWljcm8gRGV2aWNlcywgSW5j
LgorICogQXV0aG9yOiBDaHJpc3RvcGggRWdnZXIgPENocmlzdG9waC5FZ2dlckBhbWQuY29tPgor
ICoKKyAqIEd1ZXN0IE9TIG1hY2hpbmUgY2hlY2sgaW50ZXJmYWNlIHRvIHg4NiBYZW4uCisgKgor
ICogUGVybWlzc2lvbiBpcyBoZXJlYnkgZ3JhbnRlZCwgZnJlZSBvZiBjaGFyZ2UsIHRvIGFueSBw
ZXJzb24gb2J0YWluaW5nIGEgY29weQorICogb2YgdGhpcyBzb2Z0d2FyZSBhbmQgYXNzb2NpYXRl
ZCBkb2N1bWVudGF0aW9uIGZpbGVzICh0aGUgIlNvZnR3YXJlIiksIHRvCisgKiBkZWFsIGluIHRo
ZSBTb2Z0d2FyZSB3aXRob3V0IHJlc3RyaWN0aW9uLCBpbmNsdWRpbmcgd2l0aG91dCBsaW1pdGF0
aW9uIHRoZQorICogcmlnaHRzIHRvIHVzZSwgY29weSwgbW9kaWZ5LCBtZXJnZSwgcHVibGlzaCwg
ZGlzdHJpYnV0ZSwgc3VibGljZW5zZSwgYW5kL29yCisgKiBzZWxsIGNvcGllcyBvZiB0aGUgU29m
dHdhcmUsIGFuZCB0byBwZXJtaXQgcGVyc29ucyB0byB3aG9tIHRoZSBTb2Z0d2FyZSBpcworICog
ZnVybmlzaGVkIHRvIGRvIHNvLCBzdWJqZWN0IHRvIHRoZSBmb2xsb3dpbmcgY29uZGl0aW9uczoK
KyAqCisgKiBUaGUgYWJvdmUgY29weXJpZ2h0IG5vdGljZSBhbmQgdGhpcyBwZXJtaXNzaW9uIG5v
dGljZSBzaGFsbCBiZSBpbmNsdWRlZCBpbgorICogYWxsIGNvcGllcyBvciBzdWJzdGFudGlhbCBw
b3J0aW9ucyBvZiB0aGUgU29mdHdhcmUuCisgKgorICogVEhFIFNPRlRXQVJFIElTIFBST1ZJREVE
ICJBUyBJUyIsIFdJVEhPVVQgV0FSUkFOVFkgT0YgQU5ZIEtJTkQsIEVYUFJFU1MgT1IKKyAqIElN
UExJRUQsIElOQ0xVRElORyBCVVQgTk9UIExJTUlURUQgVE8gVEhFIFdBUlJBTlRJRVMgT0YgTUVS
Q0hBTlRBQklMSVRZLAorICogRklUTkVTUyBGT1IgQSBQQVJUSUNVTEFSIFBVUlBPU0UgQU5EIE5P
TklORlJJTkdFTUVOVC4gSU4gTk8gRVZFTlQgU0hBTEwgVEhFCisgKiBBVVRIT1JTIE9SIENPUFlS
SUdIVCBIT0xERVJTIEJFIExJQUJMRSBGT1IgQU5ZIENMQUlNLCBEQU1BR0VTIE9SIE9USEVSCisg
KiBMSUFCSUxJVFksIFdIRVRIRVIgSU4gQU4gQUNUSU9OIE9GIENPTlRSQUNULCBUT1JUIE9SIE9U
SEVSV0lTRSwgQVJJU0lORworICogRlJPTSwgT1VUIE9GIE9SIElOIENPTk5FQ1RJT04gV0lUSCBU
SEUgU09GVFdBUkUgT1IgVEhFIFVTRSBPUiBPVEhFUgorICogREVBTElOR1MgSU4gVEhFIFNPRlRX
QVJFLgorICovCisKKy8qIEZ1bGwgTUNBIGZ1bmN0aW9uYWxpdHkgaGFzIHRoZSBmb2xsb3dpbmcg
VXNlY2FzZXMgZnJvbSB0aGUgZ3Vlc3Qgc2lkZToKKyAqCisgKiBNdXN0IGhhdmUnczoKKyAqIDEu
IERvbTAgYW5kIERvbVUgcmVnaXN0ZXIgbWFjaGluZSBjaGVjayB0cmFwIGNhbGxiYWNrIGhhbmRs
ZXJzCisgKiAgICAoYWxyZWFkeSBkb25lIHZpYSAic2V0X3RyYXBfdGFibGUiIGh5cGVyY2FsbCkK
KyAqIDIuIERvbTAgcmVnaXN0ZXJzIG1hY2hpbmUgY2hlY2sgZXZlbnQgY2FsbGJhY2sgaGFuZGxl
cgorICogICAgKGRvYWJsZSB2aWEgRVZUQ0hOT1BfYmluZF92aXJxKQorICogMy4gRG9tMCBhbmQg
RG9tVSBmZXRjaGVzIG1hY2hpbmUgY2hlY2sgZGF0YQorICogNC4gRG9tMCB3YW50cyBYZW4gdG8g
bm90aWZ5IGEgRG9tVQorICogNS4gRG9tMCBnZXRzIERvbVUgSUQgZnJvbSBwaHlzaWNhbCBhZGRy
ZXNzCisgKiA2LiBEb20wIHdhbnRzIFhlbiB0byBraWxsIERvbVUgKGFscmVhZHkgZG9uZSBmb3Ig
InhtIGRlc3Ryb3kiKQorICoKKyAqIE5pY2UgdG8gaGF2ZSdzOgorICogNy4gRG9tMCB3YW50cyBY
ZW4gdG8gZGVhY3RpdmF0ZSBhIHBoeXNpY2FsIENQVQorICogICAgVGhpcyBpcyBiZXR0ZXIgZG9u
ZSBhcyBzZXBhcmF0ZSB0YXNrLCBwaHlzaWNhbCBDUFUgaG90cGx1Z2dpbmcsCisgKiAgICBhbmQg
aHlwZXJjYWxsKHMpIHNob3VsZCBiZSBzeXNjdGwncworICogOC4gUGFnZSBtaWdyYXRpb24gcHJv
cG9zZWQgZnJvbSBYZW4gTlVNQSB3b3JrLCB3aGVyZSBEb20wIGNhbiB0ZWxsIFhlbiB0bworICog
ICAgbW92ZSBhIERvbVUgKG9yIERvbTAgaXRzZWxmKSBhd2F5IGZyb20gYSBtYWxpY2lvdXMgcGFn
ZQorICogICAgcHJvZHVjaW5nIGNvcnJlY3RhYmxlIGVycm9ycy4KKyAqIDkuIG9mZmxpbmluZyBw
aHlzaWNhbCBwYWdlOgorICogICAgWGVuIGZyZWUncyBhbmQgbmV2ZXIgcmUtdXNlcyBhIGNlcnRh
aW4gcGh5c2ljYWwgcGFnZS4KKyAqIDEwLiBUZXN0ZmFjaWxpdHk6IEFsbG93IERvbTAgdG8gd3Jp
dGUgdmFsdWVzIGludG8gbWFjaGluZSBjaGVjayBNU1IncworICogICAgIGFuZCB0ZWxsIFhlbiB0
byB0cmlnZ2VyIGEgbWFjaGluZSBjaGVjaworICovCisKKyNpZm5kZWYgX19YRU5fUFVCTElDX0FS
Q0hfWDg2X01DQV9IX18KKyNkZWZpbmUgX19YRU5fUFVCTElDX0FSQ0hfWDg2X01DQV9IX18KKwor
LyogSHlwZXJjYWxsICovCisjZGVmaW5lIF9fSFlQRVJWSVNPUl9tY2EgX19IWVBFUlZJU09SX2Fy
Y2hfMAorCisvKgorICogVGhlIHhlbi11bnN0YWJsZSByZXBvIGhhcyBpbnRlcmZhY2UgdmVyc2lv
biAweDAzMDAwMDAxOyBvdXQgaW50ZXJmYWNlCisgKiBpcyBpbmNvbXBhdGlibGUgd2l0aCB0aGF0
IGFuZCBhbnkgZnV0dXJlIG1pbm9yIHJldmlzaW9ucywgc28gd2UKKyAqIGNob29zZSBhIGRpZmZl
cmVudCB2ZXJzaW9uIG51bWJlciByYW5nZSB0aGF0IGlzIG51bWVyaWNhbGx5IGxlc3MKKyAqIHRo
YW4gdGhhdCB1c2VkIGluIHhlbi11bnN0YWJsZS4KKyAqLworI2RlZmluZSBYRU5fTUNBX0lOVEVS
RkFDRV9WRVJTSU9OIDB4MDFlY2MwMDMKKworLyogSU46IERvbTAgY2FsbHMgaHlwZXJjYWxsIHRv
IHJldHJpZXZlIG5vbnVyZ2VudCBlcnJvciBsb2cgZW50cnkgKi8KKyNkZWZpbmUgWEVOX01DX05P
TlVSR0VOVCAgMHgwMDAxCisvKiBJTjogRG9tMC9Eb21VIGNhbGxzIGh5cGVyY2FsbCB0byByZXRy
aWV2ZSB1cmdlbnQgZXJyb3IgbG9nIGVudHJ5ICovCisjZGVmaW5lIFhFTl9NQ19VUkdFTlQgICAg
IDB4MDAwMgorLyogSU46IERvbTAgYWNrbm93bGVkZ2VzIHByZXZpb3NseS1mZXRjaGVkIGVycm9y
IGxvZyBlbnRyeSAqLworI2RlZmluZSBYRU5fTUNfQUNLICAgICAgICAweDAwMDQKKworLyogT1VU
OiBBbGwgaXMgb2sgKi8KKyNkZWZpbmUgWEVOX01DX09LICAgICAgICAgICAweDAKKy8qIE9VVDog
RG9tYWluIGNvdWxkIG5vdCBmZXRjaCBkYXRhLiAqLworI2RlZmluZSBYRU5fTUNfRkVUQ0hGQUlM
RUQgIDB4MQorLyogT1VUOiBUaGVyZSB3YXMgbm8gbWFjaGluZSBjaGVjayBkYXRhIHRvIGZldGNo
LiAqLworI2RlZmluZSBYRU5fTUNfTk9EQVRBICAgICAgIDB4MgorLyogT1VUOiBCZXR3ZWVuIG5v
dGlmaWNhdGlvbiB0aW1lIGFuZCB0aGlzIGh5cGVyY2FsbCBhbiBvdGhlcgorICogIChtb3N0IGxp
a2VseSkgY29ycmVjdGFibGUgZXJyb3IgaGFwcGVuZWQuIFRoZSBmZXRjaGVkIGRhdGEsCisgKiAg
ZG9lcyBub3QgbWF0Y2ggdGhlIG9yaWdpbmFsIG1hY2hpbmUgY2hlY2sgZGF0YS4gKi8KKyNkZWZp
bmUgWEVOX01DX05PTUFUQ0ggICAgICAweDQKKworLyogT1VUOiBEb21VIGRpZCBub3QgcmVnaXN0
ZXIgTUMgTk1JIGhhbmRsZXIuIFRyeSBzb21ldGhpbmcgZWxzZS4gKi8KKyNkZWZpbmUgWEVOX01D
X0NBTk5PVEhBTkRMRSAweDgKKy8qIE9VVDogTm90aWZ5aW5nIERvbVUgZmFpbGVkLiBSZXRyeSBs
YXRlciBvciB0cnkgc29tZXRoaW5nIGVsc2UuICovCisjZGVmaW5lIFhFTl9NQ19OT1RERUxJVkVS
RUQgMHgxMAorLyogTm90ZSwgWEVOX01DX0NBTk5PVEhBTkRMRSBhbmQgWEVOX01DX05PVERFTElW
RVJFRCBhcmUgbXV0dWFsbHkgZXhjbHVzaXZlLiAqLworCisKKyNpZm5kZWYgX19BU1NFTUJMWV9f
CisKKyNkZWZpbmUgVklSUV9NQ0EgVklSUV9BUkNIXzAgLyogRy4gKERPTTApIE1hY2hpbmUgQ2hl
Y2sgQXJjaGl0ZWN0dXJlICovCisKKy8qCisgKiBNYWNoaW5lIENoZWNrIEFyY2hpdGVjdXJlOgor
ICogc3RydWN0cyBhcmUgcmVhZC1vbmx5IGFuZCB1c2VkIHRvIHJlcG9ydCBhbGwga2luZHMgb2YK
KyAqIGNvcnJlY3RhYmxlIGFuZCB1bmNvcnJlY3RhYmxlIGVycm9ycyBkZXRlY3RlZCBieSB0aGUg
SFcuCisgKiBEb20wIGFuZCBEb21VOiByZWdpc3RlciBhIGhhbmRsZXIgdG8gZ2V0IG5vdGlmaWVk
LgorICogRG9tMCBvbmx5OiBDb3JyZWN0YWJsZSBlcnJvcnMgYXJlIHJlcG9ydGVkIHZpYSBWSVJR
X01DQQorICovCisjZGVmaW5lIE1DX1RZUEVfR0xPQkFMICAgICAgICAgIDAKKyNkZWZpbmUgTUNf
VFlQRV9CQU5LICAgICAgICAgICAgMQorI2RlZmluZSBNQ19UWVBFX0VYVEVOREVEICAgICAgICAy
CisjZGVmaW5lIE1DX1RZUEVfUkVDT1ZFUlkgICAgICAgIDMKKworc3RydWN0IG1jaW5mb19jb21t
b24geworCXVpbnQxNl90IHR5cGU7ICAgICAgLyogc3RydWN0dXJlIHR5cGUgKi8KKwl1aW50MTZf
dCBzaXplOyAgICAgIC8qIHNpemUgb2YgdGhpcyBzdHJ1Y3QgaW4gYnl0ZXMgKi8KK307CisKKwor
I2RlZmluZSBNQ19GTEFHX0NPUlJFQ1RBQkxFICAgICAoMSA8PCAwKQorI2RlZmluZSBNQ19GTEFH
X1VOQ09SUkVDVEFCTEUgICAoMSA8PCAxKQorI2RlZmluZSBNQ19GTEFHX1JFQ09WRVJBQkxFCSgx
IDw8IDIpCisjZGVmaW5lIE1DX0ZMQUdfUE9MTEVECQkoMSA8PCAzKQorI2RlZmluZSBNQ19GTEFH
X1JFU0VUCQkoMSA8PCA0KQorI2RlZmluZSBNQ19GTEFHX0NNQ0kJCSgxIDw8IDUpCisjZGVmaW5l
IE1DX0ZMQUdfTUNFCQkoMSA8PCA2KQorLyogY29udGFpbnMgZ2xvYmFsIHg4NiBtYyBpbmZvcm1h
dGlvbiAqLworc3RydWN0IG1jaW5mb19nbG9iYWwgeworCXN0cnVjdCBtY2luZm9fY29tbW9uIGNv
bW1vbjsKKworCS8qIHJ1bm5pbmcgZG9tYWluIGF0IHRoZSB0aW1lIGluIGVycm9yIChtb3N0IGxp
a2VseQorCSAqIHRoZSBpbXBhY3RlZCBvbmUpICovCisJdWludDE2X3QgbWNfZG9taWQ7CisJdWlu
dDE2X3QgbWNfdmNwdWlkOyAvKiB2aXJ0dWFsIGNwdSBzY2hlZHVsZWQgZm9yIG1jX2RvbWlkICov
CisJdWludDMyX3QgbWNfc29ja2V0aWQ7IC8qIHBoeXNpY2FsIHNvY2tldCBvZiB0aGUgcGh5c2lj
YWwgY29yZSAqLworCXVpbnQxNl90IG1jX2NvcmVpZDsgLyogcGh5c2ljYWwgaW1wYWN0ZWQgY29y
ZSAqLworCXVpbnQxNl90IG1jX2NvcmVfdGhyZWFkaWQ7IC8qIGNvcmUgdGhyZWFkIG9mIHBoeXNp
Y2FsIGNvcmUgKi8KKwl1aW50MzJfdCBtY19hcGljaWQ7CisJdWludDMyX3QgbWNfZmxhZ3M7CisJ
dWludDY0X3QgbWNfZ3N0YXR1czsgLyogZ2xvYmFsIHN0YXR1cyAqLworfTsKKworLyogY29udGFp
bnMgYmFuayBsb2NhbCB4ODYgbWMgaW5mb3JtYXRpb24gKi8KK3N0cnVjdCBtY2luZm9fYmFuayB7
CisJc3RydWN0IG1jaW5mb19jb21tb24gY29tbW9uOworCisJdWludDE2X3QgbWNfYmFuazsgLyog
YmFuayBuciAqLworCXVpbnQxNl90IG1jX2RvbWlkOyAvKiBVc2VjYXNlIDU6IGRvbWFpbiByZWZl
cmVuY2VkIGJ5IG1jX2FkZHIgb24KKwkJCSogcHJpdmlsZWdlZCBwdi1vcHMgZG9tIGFuZCBpZiBt
Y19hZGRyIGlzIHZhbGlkLgorCQkJKiBOZXZlciB2YWxpZCBvbiBEb21VLiAqLworCXVpbnQ2NF90
IG1jX3N0YXR1czsgLyogYmFuayBzdGF0dXMgKi8KKwl1aW50NjRfdCBtY19hZGRyOyAgIC8qIGJh
bmsgYWRkcmVzcywgb25seSB2YWxpZAorCQkJCQkgKiBpZiBhZGRyIGJpdCBpcyBzZXQgaW4gbWNf
c3RhdHVzICovCisJdWludDY0X3QgbWNfbWlzYzsKKwl1aW50NjRfdCBtY19jdHJsMjsKKwl1aW50
NjRfdCBtY190c2M7Cit9OworCisKK3N0cnVjdCBtY2luZm9fbXNyIHsKKwl1aW50NjRfdCByZWc7
ICAgLyogTVNSICovCisJdWludDY0X3QgdmFsdWU7IC8qIE1TUiB2YWx1ZSAqLworfTsKKworLyog
Y29udGFpbnMgbWMgaW5mb3JtYXRpb24gZnJvbSBvdGhlcgorICogb3IgYWRkaXRpb25hbCBtYyBN
U1JzICovCitzdHJ1Y3QgbWNpbmZvX2V4dGVuZGVkIHsKKwlzdHJ1Y3QgbWNpbmZvX2NvbW1vbiBj
b21tb247CisKKwkvKiBZb3UgY2FuIGZpbGwgdXAgdG8gZml2ZSByZWdpc3RlcnMuCisJICogSWYg
eW91IG5lZWQgbW9yZSwgdGhlbiB1c2UgdGhpcyBzdHJ1Y3R1cmUKKwkgKiBtdWx0aXBsZSB0aW1l
cy4gKi8KKworCXVpbnQzMl90IG1jX21zcnM7IC8qIE51bWJlciBvZiBtc3Igd2l0aCB2YWxpZCB2
YWx1ZXMuICovCisJLyoKKwkgKiBDdXJyZW50bHkgSW50ZWwgZXh0ZW5kZWQgTVNSICgzMi82NCkg
aW5jbHVkZSBhbGwgZ3AgcmVnaXN0ZXJzCisJICogYW5kIEUoUilGTEFHUywgRShSKUlQLCBFKFIp
TUlTQywgdXAgdG8gMTEvMTkgb2YgdGhlbSBtaWdodCBiZQorCSAqIHVzZWZ1bCBhdCBwcmVzZW50
LiBTbyBleHBhbmQgdGhpcyBhcnJheSB0byAxNi8zMiB0byBsZWF2ZSByb29tLgorCSAqLworCXN0
cnVjdCBtY2luZm9fbXNyIG1jX21zcltzaXplb2Yodm9pZCAqKSAqIDRdOworfTsKKworLyogUmVj
b3ZlcnkgQWN0aW9uIGZsYWdzLiBHaXZpbmcgcmVjb3ZlcnkgcmVzdWx0IGluZm9ybWF0aW9uIHRv
IERPTTAgKi8KKworLyogWGVuIHRha2VzIHN1Y2Nlc3NmdWwgcmVjb3ZlcnkgYWN0aW9uLCB0aGUg
ZXJyb3IgaXMgcmVjb3ZlcmVkICovCisjZGVmaW5lIFJFQ19BQ1RJT05fUkVDT1ZFUkVEICgweDEg
PDwgMCkKKy8qIE5vIGFjdGlvbiBpcyBwZXJmb3JtZWQgYnkgWEVOICovCisjZGVmaW5lIFJFQ19B
Q1RJT05fTk9ORSAoMHgxIDw8IDEpCisvKiBJdCdzIHBvc3NpYmxlIERPTTAgbWlnaHQgdGFrZSBh
Y3Rpb24gb3duZXJzaGlwIGluIHNvbWUgY2FzZSAqLworI2RlZmluZSBSRUNfQUNUSU9OX05FRURf
UkVTRVQgKDB4MSA8PCAyKQorCisvKiBEaWZmZXJlbnQgUmVjb3ZlcnkgQWN0aW9uIHR5cGVzLCBp
ZiB0aGUgYWN0aW9uIGlzIHBlcmZvcm1lZCBzdWNjZXNzZnVsbHksCisgKiBSRUNfQUNUSU9OX1JF
Q09WRVJFRCBmbGFnIHdpbGwgYmUgcmV0dXJuZWQuCisgKi8KKworLyogUGFnZSBPZmZsaW5lIEFj
dGlvbiAqLworI2RlZmluZSBNQ19BQ1RJT05fUEFHRV9PRkZMSU5FICgweDEgPDwgMCkKKy8qIENQ
VSBvZmZsaW5lIEFjdGlvbiAqLworI2RlZmluZSBNQ19BQ1RJT05fQ1BVX09GRkxJTkUgKDB4MSA8
PCAxKQorLyogTDMgY2FjaGUgZGlzYWJsZSBBY3Rpb24gKi8KKyNkZWZpbmUgTUNfQUNUSU9OX0NB
Q0hFX1NIUklOSyAoMHgxIDw8IDIpCisKKy8qIEJlbG93IGludGVyZmFjZSB1c2VkIGJldHdlZW4g
WEVOL0RPTTAgZm9yIHBhc3NpbmcgWEVOJ3MgcmVjb3ZlcnkgYWN0aW9uCisgKiBpbmZvcm1hdGlv
biB0byBET00wLgorICogdXNhZ2UgU2VuYXJpbzogQWZ0ZXIgb2ZmbGluaW5nIGJyb2tlbiBwYWdl
LCBYRU4gbWlnaHQgcGFzcyBpdHMgcGFnZSBvZmZsaW5lCisgKiByZWNvdmVyeSBhY3Rpb24gcmVz
dWx0IHRvIERPTTAuIERPTTAgd2lsbCBzYXZlIHRoZSBpbmZvcm1hdGlvbiBpbgorICogbm9uLXZv
bGF0aWxlIG1lbW9yeSBmb3IgZnVydGhlciBwcm9hY3RpdmUgYWN0aW9ucywgc3VjaCBhcyBvZmZs
aW5pbmcgdGhlCisgKiBlYXN5IGJyb2tlbiBwYWdlIGVhcmxpZXIgd2hlbiBkb2luZyBuZXh0IHJl
Ym9vdC4KKyovCitzdHJ1Y3QgcGFnZV9vZmZsaW5lX2FjdGlvbiB7CisJLyogUGFyYW1zIGZvciBw
YXNzaW5nIHRoZSBvZmZsaW5lZCBwYWdlIG51bWJlciB0byBET00wICovCisJdWludDY0X3QgbWZu
OworCXVpbnQ2NF90IHN0YXR1czsKK307CisKK3N0cnVjdCBjcHVfb2ZmbGluZV9hY3Rpb24gewor
CS8qIFBhcmFtcyBmb3IgcGFzc2luZyB0aGUgaWRlbnRpdHkgb2YgdGhlIG9mZmxpbmVkIENQVSB0
byBET00wICovCisJdWludDMyX3QgbWNfc29ja2V0aWQ7CisJdWludDE2X3QgbWNfY29yZWlkOwor
CXVpbnQxNl90IG1jX2NvcmVfdGhyZWFkaWQ7Cit9OworCisjZGVmaW5lIE1BWF9VTklPTl9TSVpF
IDE2CitzdHJ1Y3QgbWNpbmZvX3JlY292ZXJ5IHsKKwlzdHJ1Y3QgbWNpbmZvX2NvbW1vbiBjb21t
b247CisJdWludDE2X3QgbWNfYmFuazsgLyogYmFuayBuciAqLworCS8qIFJlY292ZXJ5IEFjdGlv
biBGbGFncyBkZWZpbmVkIGFib3ZlIHN1Y2ggYXMgUkVDX0FDVElPTl9ET05FICovCisJdWludDhf
dCBhY3Rpb25fZmxhZ3M7CisJLyogUmVjb3ZlcnkgQWN0aW9uIHR5cGVzIGRlZmluZWQgYWJvdmUg
c3VjaCBhcyBNQ19BQ1RJT05fUEFHRV9PRkZMSU5FICovCisJdWludDhfdCBhY3Rpb25fdHlwZXM7
CisJLyogSW4gZnV0dXJlIGlmIG1vcmUgdGhhbiBvbmUgcmVjb3ZlcnkgYWN0aW9uIHBlcm1pdHRl
ZCBwZXIgZXJyb3IgYmFuaywKKwkgKiBhIG1jaW5mb19yZWNvdmVyeSBkYXRhIGFycmF5IHdpbGwg
YmUgcmV0dXJuZWQKKwkgKi8KKwl1bmlvbiB7CisJCXN0cnVjdCBwYWdlX29mZmxpbmVfYWN0aW9u
IHBhZ2VfcmV0aXJlOworCQlzdHJ1Y3QgY3B1X29mZmxpbmVfYWN0aW9uIGNwdV9vZmZsaW5lOwor
CQl1aW50OF90IHBhZFtNQVhfVU5JT05fU0laRV07CisJfSBhY3Rpb25faW5mbzsKK307CisKKwor
I2RlZmluZSBNQ0lORk9fSFlQRVJDQUxMU0laRQkxMDI0CisjZGVmaW5lIE1DSU5GT19NQVhTSVpF
CQk3NjgKKworc3RydWN0IG1jX2luZm8geworCS8qIE51bWJlciBvZiBtY2luZm9fKiBlbnRyaWVz
IGluIG1pX2RhdGEgKi8KKwl1aW50MzJfdCBtaV9uZW50cmllczsKKwl1aW50MzJfdCBfcGFkMDsK
Kwl1aW50NjRfdCBtaV9kYXRhWyhNQ0lORk9fTUFYU0laRSAtIDEpIC8gOF07Cit9OwordHlwZWRl
ZiBzdHJ1Y3QgbWNfaW5mbyBtY19pbmZvX3Q7CitERUZJTkVfR1VFU1RfSEFORExFX1NUUlVDVCht
Y19pbmZvKTsKKworI2RlZmluZSBfX01DX01TUl9BUlJBWVNJWkUgOAorI2RlZmluZSBfX01DX05N
U1JTIDEKKyNkZWZpbmUgTUNfTkNBUFMJNwkvKiA3IENQVSBmZWF0dXJlIGZsYWcgd29yZHMgKi8K
KyNkZWZpbmUgTUNfQ0FQU19TVERfRURYCTAJLyogY3B1aWQgbGV2ZWwgMHgwMDAwMDAwMSAoJWVk
eCkgKi8KKyNkZWZpbmUgTUNfQ0FQU19BTURfRURYCTEJLyogY3B1aWQgbGV2ZWwgMHg4MDAwMDAw
MSAoJWVkeCkgKi8KKyNkZWZpbmUgTUNfQ0FQU19UTQkyCS8qIGNwdWlkIGxldmVsIDB4ODA4NjAw
MDEgKFRyYW5zTWV0YSkgKi8KKyNkZWZpbmUgTUNfQ0FQU19MSU5VWAkzCS8qIExpbnV4LWRlZmlu
ZWQgKi8KKyNkZWZpbmUgTUNfQ0FQU19TVERfRUNYCTQJLyogY3B1aWQgbGV2ZWwgMHgwMDAwMDAw
MSAoJWVjeCkgKi8KKyNkZWZpbmUgTUNfQ0FQU19WSUEJNQkvKiBjcHVpZCBsZXZlbCAweGMwMDAw
MDAxICovCisjZGVmaW5lIE1DX0NBUFNfQU1EX0VDWAk2CS8qIGNwdWlkIGxldmVsIDB4ODAwMDAw
MDEgKCVlY3gpICovCisKK3N0cnVjdCBtY2luZm9fbG9naWNhbF9jcHUgeworCXVpbnQzMl90IG1j
X2NwdW5yOworCXVpbnQzMl90IG1jX2NoaXBpZDsKKwl1aW50MTZfdCBtY19jb3JlaWQ7CisJdWlu
dDE2X3QgbWNfdGhyZWFkaWQ7CisJdWludDMyX3QgbWNfYXBpY2lkOworCXVpbnQzMl90IG1jX2Ns
dXN0ZXJpZDsKKwl1aW50MzJfdCBtY19uY29yZXM7CisJdWludDMyX3QgbWNfbmNvcmVzX2FjdGl2
ZTsKKwl1aW50MzJfdCBtY19udGhyZWFkczsKKwlpbnQzMl90IG1jX2NwdWlkX2xldmVsOworCXVp
bnQzMl90IG1jX2ZhbWlseTsKKwl1aW50MzJfdCBtY192ZW5kb3I7CisJdWludDMyX3QgbWNfbW9k
ZWw7CisJdWludDMyX3QgbWNfc3RlcDsKKwljaGFyIG1jX3ZlbmRvcmlkWzE2XTsKKwljaGFyIG1j
X2JyYW5kaWRbNjRdOworCXVpbnQzMl90IG1jX2NwdV9jYXBzW01DX05DQVBTXTsKKwl1aW50MzJf
dCBtY19jYWNoZV9zaXplOworCXVpbnQzMl90IG1jX2NhY2hlX2FsaWdubWVudDsKKwlpbnQzMl90
IG1jX25tc3J2YWxzOworCXN0cnVjdCBtY2luZm9fbXNyIG1jX21zcnZhbHVlc1tfX01DX01TUl9B
UlJBWVNJWkVdOworfTsKK3R5cGVkZWYgc3RydWN0IG1jaW5mb19sb2dpY2FsX2NwdSBtY2luZm9f
bG9naWNhbF9jcHVfdDsKK0RFRklORV9HVUVTVF9IQU5ETEVfU1RSVUNUKG1jaW5mb19sb2dpY2Fs
X2NwdSk7CisKKworLyoKKyAqIE9TJ3Mgc2hvdWxkIHVzZSB0aGVzZSBpbnN0ZWFkIG9mIHdyaXRp
bmcgdGhlaXIgb3duIGxvb2t1cCBmdW5jdGlvbgorICogZWFjaCB3aXRoIGl0cyBvd24gYnVncyBh
bmQgZHJhd2JhY2tzLgorICogV2UgdXNlIG1hY3JvcyBpbnN0ZWFkIG9mIHN0YXRpYyBpbmxpbmUg
ZnVuY3Rpb25zIHRvIGFsbG93IGd1ZXN0cworICogdG8gaW5jbHVkZSB0aGlzIGhlYWRlciBpbiBh
c3NlbWJseSBmaWxlcyAoKi5TKS4KKyAqLworLyogUHJvdG90eXBlOgorICogICAgdWludDMyX3Qg
eDg2X21jaW5mb19uZW50cmllcyhzdHJ1Y3QgbWNfaW5mbyAqbWkpOworICovCisjZGVmaW5lIHg4
Nl9tY2luZm9fbmVudHJpZXMoX21pKSAgICBcCisgICAgKChfbWkpLT5taV9uZW50cmllcykKKy8q
IFByb3RvdHlwZToKKyAqICAgIHN0cnVjdCBtY2luZm9fY29tbW9uICp4ODZfbWNpbmZvX2ZpcnN0
KHN0cnVjdCBtY19pbmZvICptaSk7CisgKi8KKyNkZWZpbmUgeDg2X21jaW5mb19maXJzdChfbWkp
ICAgICAgIFwKKyAgICAoKHN0cnVjdCBtY2luZm9fY29tbW9uICopKF9taSktPm1pX2RhdGEpCisv
KiBQcm90b3R5cGU6CisgKiAgICBzdHJ1Y3QgbWNpbmZvX2NvbW1vbiAqeDg2X21jaW5mb19uZXh0
KHN0cnVjdCBtY2luZm9fY29tbW9uICptaWMpOworICovCisjZGVmaW5lIHg4Nl9tY2luZm9fbmV4
dChfbWljKSAgICAgICBcCisgICAgKChzdHJ1Y3QgbWNpbmZvX2NvbW1vbiAqKSgodWludDhfdCAq
KShfbWljKSArIChfbWljKS0+c2l6ZSkpCisKKy8qIFByb3RvdHlwZToKKyAqICAgIHZvaWQgeDg2
X21jaW5mb19sb29rdXAodm9pZCAqcmV0LCBzdHJ1Y3QgbWNfaW5mbyAqbWksIHVpbnQxNl90IHR5
cGUpOworICovCisKK3N0YXRpYyBpbmxpbmUgdm9pZCB4ODZfbWNpbmZvX2xvb2t1cAorCShzdHJ1
Y3QgbWNpbmZvX2NvbW1vbiAqKnJldCwgc3RydWN0IG1jX2luZm8gKm1pLCB1aW50MTZfdCB0eXBl
KQoreworCXVpbnQzMl90IGZvdW5kID0gMCwgaTsKKwlzdHJ1Y3QgbWNpbmZvX2NvbW1vbiAqbWlj
OworCisJKnJldCA9IE5VTEw7CisJaWYgKCFtaSkKKwkJcmV0dXJuOworCW1pYyA9IHg4Nl9tY2lu
Zm9fZmlyc3QobWkpOworCisJZm9yIChpID0gMDsgaSA8IHg4Nl9tY2luZm9fbmVudHJpZXMobWkp
OyBpKyspIHsKKwkJaWYgKG1pYy0+dHlwZSA9PSB0eXBlKSB7CisJCQlmb3VuZCA9IDE7CisJCQli
cmVhazsKKwkJfQorCQltaWMgPSB4ODZfbWNpbmZvX25leHQobWljKTsKKwl9CisKKwkqcmV0ID0g
Zm91bmQgPyBtaWMgOiBOVUxMOworfQorLyogVXNlY2FzZSAxCisgKiBSZWdpc3RlciBtYWNoaW5l
IGNoZWNrIHRyYXAgY2FsbGJhY2sgaGFuZGxlcgorICogICAgKGFscmVhZHkgZG9uZSB2aWEgInNl
dF90cmFwX3RhYmxlIiBoeXBlcmNhbGwpCisgKi8KKworLyogVXNlY2FzZSAyCisgKiBEb20wIHJl
Z2lzdGVycyBtYWNoaW5lIGNoZWNrIGV2ZW50IGNhbGxiYWNrIGhhbmRsZXIKKyAqIGRvbmUgYnkg
RVZUQ0hOT1BfYmluZF92aXJxCisgKi8KKworLyogVXNlY2FzZSAzCisgKiBGZXRjaCBtYWNoaW5l
IGNoZWNrIGRhdGEgZnJvbSBoeXBlcnZpc29yLgorICogTm90ZSwgdGhpcyBoeXBlcmNhbGwgaXMg
c3BlY2lhbCwgYmVjYXVzZSBib3RoIERvbTAgYW5kIERvbVUgbXVzdCB1c2UgdGhpcy4KKyAqLwor
I2RlZmluZSBYRU5fTUNfZmV0Y2ggICAgICAgICAgICAxCitzdHJ1Y3QgeGVuX21jX2ZldGNoIHsK
KyAgICAvKiBJTi9PVVQgdmFyaWFibGVzLgorCSAqIElOOiBYRU5fTUNfTk9OVVJHRU5ULCBYRU5f
TUNfVVJHRU5ULAorCSAqIFhFTl9NQ19BQ0sgaWYgYWNrJ2tpbmcgYW4gZWFybGllciBmZXRjaAor
CSAqIE9VVDogWEVOX01DX09LLCBYRU5fTUNfRkVUQ0hBSUxFRCwKKwkgKiBYRU5fTUNfTk9EQVRB
LCBYRU5fTUNfTk9NQVRDSAorCSovCisJdWludDMyX3QgZmxhZ3M7CisJdWludDMyX3QgX3BhZDA7
CisJLyogT1VUOiBpZCBmb3IgYWNrLCBJTjogaWQgd2UgYXJlIGFjaydpbmcgKi8KKwl1aW50NjRf
dCBmZXRjaF9pZDsKKworCS8qIE9VVCB2YXJpYWJsZXMuICovCisJR1VFU1RfSEFORExFKG1jX2lu
Zm8pIGRhdGE7Cit9OwordHlwZWRlZiBzdHJ1Y3QgeGVuX21jX2ZldGNoIHhlbl9tY19mZXRjaF90
OworREVGSU5FX0dVRVNUX0hBTkRMRV9TVFJVQ1QoeGVuX21jX2ZldGNoKTsKKworCisvKiBVc2Vj
YXNlIDQKKyAqIFRoaXMgdGVsbHMgdGhlIGh5cGVydmlzb3IgdG8gbm90aWZ5IGEgRG9tVSBhYm91
dCB0aGUgbWFjaGluZSBjaGVjayBlcnJvcgorICovCisjZGVmaW5lIFhFTl9NQ19ub3RpZnlkb21h
aW4gICAgIDIKK3N0cnVjdCB4ZW5fbWNfbm90aWZ5ZG9tYWluIHsKKwkvKiBJTiB2YXJpYWJsZXMu
ICovCisJdWludDE2X3QgbWNfZG9taWQ7LyogVGhlIHVucHJpdmlsZWdlZCBkb21haW4gdG8gbm90
aWZ5LiAqLworCXVpbnQxNl90IG1jX3ZjcHVpZDsvKiBUaGUgdmNwdSBpbiBtY19kb21pZCB0byBu
b3RpZnkuCisJCQkqIFVzdWFsbHkgZWNobydkIHZhbHVlIGZyb20gdGhlIGZldGNoIGh5cGVyY2Fs
bC4gKi8KKworCS8qIElOL09VVCB2YXJpYWJsZXMuICovCisJdWludDMyX3QgZmxhZ3M7CisKKy8q
IE9VVDogWEVOX01DX09LLCBYRU5fTUNfQ0FOTk9USEFORExFLCBYRU5fTUNfTk9UREVMSVZFUkVE
LCBYRU5fTUNfTk9NQVRDSCAqLworfTsKK3R5cGVkZWYgc3RydWN0IHhlbl9tY19ub3RpZnlkb21h
aW4geGVuX21jX25vdGlmeWRvbWFpbl90OworREVGSU5FX0dVRVNUX0hBTkRMRV9TVFJVQ1QoeGVu
X21jX25vdGlmeWRvbWFpbik7CisKKyNkZWZpbmUgWEVOX01DX3BoeXNjcHVpbmZvIDMKK3N0cnVj
dCB4ZW5fbWNfcGh5c2NwdWluZm8geworCS8qIElOL09VVCAqLworCXVpbnQzMl90IG5jcHVzOwor
CXVpbnQzMl90IF9wYWQwOworCS8qIE9VVCAqLworCUdVRVNUX0hBTkRMRShtY2luZm9fbG9naWNh
bF9jcHUpIGluZm87Cit9OworCisjZGVmaW5lIFhFTl9NQ19tc3JpbmplY3QgICAgNAorI2RlZmlu
ZSBNQ19NU1JJTkpfTUFYTVNSUyAgICAgICA4CitzdHJ1Y3QgeGVuX21jX21zcmluamVjdCB7CisJ
LyogSU4gKi8KKwl1aW50MzJfdCBtY2lual9jcHVucjsvKiB0YXJnZXQgcHJvY2Vzc29yIGlkICov
CisJdWludDMyX3QgbWNpbmpfZmxhZ3M7Lyogc2VlIE1DX01TUklOSl9GXyogYmVsb3cgKi8KKwl1
aW50MzJfdCBtY2lual9jb3VudDsvKiAwIC4uIGNvdW50LTEgaW4gYXJyYXkgYXJlIHZhbGlkICov
CisJdWludDMyX3QgX3BhZDA7CisJc3RydWN0IG1jaW5mb19tc3IgbWNpbmpfbXNyW01DX01TUklO
Sl9NQVhNU1JTXTsKK307CisKKy8qIEZsYWdzIGZvciBtY2lual9mbGFncyBhYm92ZTsgYml0cyAx
Ni0zMSBhcmUgcmVzZXJ2ZWQgKi8KKyNkZWZpbmUgTUNfTVNSSU5KX0ZfSU5URVJQT1NFICAgMHgx
CisKKyNkZWZpbmUgWEVOX01DX21jZWluamVjdCAgICA1CitzdHJ1Y3QgeGVuX21jX21jZWluamVj
dCB7CisJdW5zaWduZWQgaW50IG1jZWlual9jcHVucjsgICAgICAvKiB0YXJnZXQgcHJvY2Vzc29y
IGlkICovCit9OworCitzdHJ1Y3QgeGVuX21jIHsKKwl1aW50MzJfdCBjbWQ7CisJdWludDMyX3Qg
aW50ZXJmYWNlX3ZlcnNpb247IC8qIFhFTl9NQ0FfSU5URVJGQUNFX1ZFUlNJT04gKi8KKwl1bmlv
biB7CisJCXN0cnVjdCB4ZW5fbWNfZmV0Y2ggICAgICAgIG1jX2ZldGNoOworCQlzdHJ1Y3QgeGVu
X21jX25vdGlmeWRvbWFpbiBtY19ub3RpZnlkb21haW47CisJCXN0cnVjdCB4ZW5fbWNfcGh5c2Nw
dWluZm8gIG1jX3BoeXNjcHVpbmZvOworCQlzdHJ1Y3QgeGVuX21jX21zcmluamVjdCAgICBtY19t
c3JpbmplY3Q7CisJCXN0cnVjdCB4ZW5fbWNfbWNlaW5qZWN0ICAgIG1jX21jZWluamVjdDsKKwl9
IHU7Cit9OwordHlwZWRlZiBzdHJ1Y3QgeGVuX21jIHhlbl9tY190OworREVGSU5FX0dVRVNUX0hB
TkRMRV9TVFJVQ1QoeGVuX21jKTsKKworI2VuZGlmIC8qIF9fQVNTRU1CTFlfXyAqLworCisjZW5k
aWYgLyogX19YRU5fUFVCTElDX0FSQ0hfWDg2X01DQV9IX18gKi8KLS0gCjEuNi41LjYKCg==

--_002_DE8DF0795D48FD4CA783C40EC829233589D0SHSMSX101ccrcorpint_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--_002_DE8DF0795D48FD4CA783C40EC829233589D0SHSMSX101ccrcorpint_--


From xen-devel-bounces@lists.xensource.com Thu Dec 22 10:01:40 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 Dec 2011 10:01:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdfSo-0004Oj-FD; Thu, 22 Dec 2011 10:01:26 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RdfSn-0004Np-At
	for xen-devel@lists.xensource.com; Thu, 22 Dec 2011 10:01:25 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-13.tower-21.messagelabs.com!1324548078!7250898!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 465 invoked from network); 22 Dec 2011 10:01:19 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-13.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 22 Dec 2011 10:01:19 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RdfSa-0000d4-GE; Thu, 22 Dec 2011 10:01:12 +0000
Date: Thu, 22 Dec 2011 10:01:12 +0000
From: Tim Deegan <tim@xen.org>
To: "Wei, Gang" <gang.wei@intel.com>
Message-ID: <20111222100112.GA1900@ocelot.phlegethon.org>
References: <F26D193E20BBDC42A43B611D1BDEDE7135CEEEAE56@shsmsx502.ccr.corp.intel.com>
	<CB177C28.365E3%keir@xen.org>
	<F26D193E20BBDC42A43B611D1BDEDE7135CEEEAE63@shsmsx502.ccr.corp.intel.com>
	<F26D193E20BBDC42A43B611D1BDEDE7135CEEEAE65@shsmsx502.ccr.corp.intel.com>
	<20111221170539.GA72385@ocelot.phlegethon.org>
	<D0B11485C64D4B47B66902F8A4E901BE9146@SHSMSX101.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <D0B11485C64D4B47B66902F8A4E901BE9146@SHSMSX101.ccr.corp.intel.com>
User-Agent: Mutt/1.4.2.1i
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	"Tim Deegan \(3P\)" <Tim.Deegan@citrix.com>, "Cihula,
	Joseph" <joseph.cihula@intel.com>,
	"tboot-devel@lists.sourceforge.net" <tboot-devel@lists.sourceforge.net>,
	Jan Beulich <jbeulich@suse.com>
Subject: Re: [Xen-devel] [patch] x86: Add a delay between INIT & SIPIs for
	AP bring-up in X2APIC case
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 01:32 +0000 on 22 Dec (1324517520), Wei, Gang wrote:
> Tim Deegan wrote on=A02011-12-22:
> > At 12:29 +0000 on 21 Dec (1324470582), Wei, Gang wrote:
> >> Without this delay, Xen could not bring APs up while working with
> >> TXT/tboot, because tboot need some time in APs to handle INIT before
> >> becoming ready for receiving SIPIs. (this delay was removed as part
> >> of c/s 23724 by Tim Deegan)
> > =

> > It was removed because I was seeing the opposite problem -- if there
> > was a delay, the AP did not come up.  Unfortunately I don;'t have
> > sucah a machine available any more, so I can't check whether this break=
s boot there.
> > =

> > Is this something that can be fixed in tboot?  If not, than this patch
> > is OK, provided it gets a code comment explaining _why_ tboot needs the=
 delay.
> =

> First, Linux kernel always place a delay between INIT & SIPIs.

Linux does a lot of things. :)  That delay is suggested in the manuals
too, but AIUI it's for older hardware that doesn't synchronously deliver
the INIT.  And there are machines where the delay causes the AP not to
come up.  But I suppose on such a machine tboot will already have
brought up the APs (or failed to) so there's no harm in the delay.

> Second, with tboot AP is actually spinning in a mini-guest before
> receiving INIT, upon receiving INIT ipi, AP need time to VMExit,
> update VMCS to tracking SIPIs and VMResume. After that SIPI is able to
> be trapped by APs. This is MUST if giving no change to current AP
> bring-up method(INIT-SIPI-SIPI) for tboot.

Oh I see - and the CPU blocks SIPIs in root mode; how inconvenient. =

Does tboot also need a delay between the two SIPIs then?

> I have provided a resent patch with code comment in a previous reply.

Your comment should say _why_ -- in particular that while tboot is in
root mode handling the INIT the CPU will drop any SIPIs. =


With that change, Ack. =


Tim.

> Jimmy
> =

> > =

> > Cheers,
> > =

> > Tim.
> > =

> >> diff -r d1aefee43af1 xen/arch/x86/smpboot.c
> >> --- a/xen/arch/x86/smpboot.c    Wed Dec 21 18:51:31 2011 +0800
> >> +++ b/xen/arch/x86/smpboot.c    Wed Dec 21 20:26:39 2011 +0800
> >> @@ -42,6 +42,7 @@
> >>  #include <asm/msr.h> #include <asm/mtrr.h> #include <asm/time.h>
> >>  +#include <asm/tboot.h> #include <mach_apic.h> #include
> >>  <mach_wakecpu.h> #include <smpboot_hooks.h>
> >> @@ -463,6 +464,10 @@ static int wakeup_secondary_cpu(int phys
> >>              send_status =3D apic_read(APIC_ICR) & APIC_ICR_BUSY;
> >>          } while ( send_status && (timeout++ < 1000) );
> >>      }
> >> +    else if ( tboot_in_measured_env() )
> >> +    {
> >> +        udelay(10);
> >> +    }
> >> =

> >>      /*
> >>       * Should we send STARTUP IPIs ?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 22 10:01:40 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 Dec 2011 10:01:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdfSo-0004Oj-FD; Thu, 22 Dec 2011 10:01:26 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RdfSn-0004Np-At
	for xen-devel@lists.xensource.com; Thu, 22 Dec 2011 10:01:25 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-13.tower-21.messagelabs.com!1324548078!7250898!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 465 invoked from network); 22 Dec 2011 10:01:19 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-13.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 22 Dec 2011 10:01:19 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RdfSa-0000d4-GE; Thu, 22 Dec 2011 10:01:12 +0000
Date: Thu, 22 Dec 2011 10:01:12 +0000
From: Tim Deegan <tim@xen.org>
To: "Wei, Gang" <gang.wei@intel.com>
Message-ID: <20111222100112.GA1900@ocelot.phlegethon.org>
References: <F26D193E20BBDC42A43B611D1BDEDE7135CEEEAE56@shsmsx502.ccr.corp.intel.com>
	<CB177C28.365E3%keir@xen.org>
	<F26D193E20BBDC42A43B611D1BDEDE7135CEEEAE63@shsmsx502.ccr.corp.intel.com>
	<F26D193E20BBDC42A43B611D1BDEDE7135CEEEAE65@shsmsx502.ccr.corp.intel.com>
	<20111221170539.GA72385@ocelot.phlegethon.org>
	<D0B11485C64D4B47B66902F8A4E901BE9146@SHSMSX101.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <D0B11485C64D4B47B66902F8A4E901BE9146@SHSMSX101.ccr.corp.intel.com>
User-Agent: Mutt/1.4.2.1i
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	"Tim Deegan \(3P\)" <Tim.Deegan@citrix.com>, "Cihula,
	Joseph" <joseph.cihula@intel.com>,
	"tboot-devel@lists.sourceforge.net" <tboot-devel@lists.sourceforge.net>,
	Jan Beulich <jbeulich@suse.com>
Subject: Re: [Xen-devel] [patch] x86: Add a delay between INIT & SIPIs for
	AP bring-up in X2APIC case
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 01:32 +0000 on 22 Dec (1324517520), Wei, Gang wrote:
> Tim Deegan wrote on=A02011-12-22:
> > At 12:29 +0000 on 21 Dec (1324470582), Wei, Gang wrote:
> >> Without this delay, Xen could not bring APs up while working with
> >> TXT/tboot, because tboot need some time in APs to handle INIT before
> >> becoming ready for receiving SIPIs. (this delay was removed as part
> >> of c/s 23724 by Tim Deegan)
> > =

> > It was removed because I was seeing the opposite problem -- if there
> > was a delay, the AP did not come up.  Unfortunately I don;'t have
> > sucah a machine available any more, so I can't check whether this break=
s boot there.
> > =

> > Is this something that can be fixed in tboot?  If not, than this patch
> > is OK, provided it gets a code comment explaining _why_ tboot needs the=
 delay.
> =

> First, Linux kernel always place a delay between INIT & SIPIs.

Linux does a lot of things. :)  That delay is suggested in the manuals
too, but AIUI it's for older hardware that doesn't synchronously deliver
the INIT.  And there are machines where the delay causes the AP not to
come up.  But I suppose on such a machine tboot will already have
brought up the APs (or failed to) so there's no harm in the delay.

> Second, with tboot AP is actually spinning in a mini-guest before
> receiving INIT, upon receiving INIT ipi, AP need time to VMExit,
> update VMCS to tracking SIPIs and VMResume. After that SIPI is able to
> be trapped by APs. This is MUST if giving no change to current AP
> bring-up method(INIT-SIPI-SIPI) for tboot.

Oh I see - and the CPU blocks SIPIs in root mode; how inconvenient. =

Does tboot also need a delay between the two SIPIs then?

> I have provided a resent patch with code comment in a previous reply.

Your comment should say _why_ -- in particular that while tboot is in
root mode handling the INIT the CPU will drop any SIPIs. =


With that change, Ack. =


Tim.

> Jimmy
> =

> > =

> > Cheers,
> > =

> > Tim.
> > =

> >> diff -r d1aefee43af1 xen/arch/x86/smpboot.c
> >> --- a/xen/arch/x86/smpboot.c    Wed Dec 21 18:51:31 2011 +0800
> >> +++ b/xen/arch/x86/smpboot.c    Wed Dec 21 20:26:39 2011 +0800
> >> @@ -42,6 +42,7 @@
> >>  #include <asm/msr.h> #include <asm/mtrr.h> #include <asm/time.h>
> >>  +#include <asm/tboot.h> #include <mach_apic.h> #include
> >>  <mach_wakecpu.h> #include <smpboot_hooks.h>
> >> @@ -463,6 +464,10 @@ static int wakeup_secondary_cpu(int phys
> >>              send_status =3D apic_read(APIC_ICR) & APIC_ICR_BUSY;
> >>          } while ( send_status && (timeout++ < 1000) );
> >>      }
> >> +    else if ( tboot_in_measured_env() )
> >> +    {
> >> +        udelay(10);
> >> +    }
> >> =

> >>      /*
> >>       * Should we send STARTUP IPIs ?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 22 10:01:56 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 Dec 2011 10:01:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdfT5-0004RU-TC; Thu, 22 Dec 2011 10:01:43 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1RdfT4-0004Q2-2V
	for xen-devel@lists.xensource.com; Thu, 22 Dec 2011 10:01:42 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1324548094!6501158!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMjkwMjgz\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12597 invoked from network); 22 Dec 2011 10:01:35 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-2.tower-174.messagelabs.com with SMTP;
	22 Dec 2011 10:01:35 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga101.jf.intel.com with ESMTP; 22 Dec 2011 02:01:31 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.67,352,1309762800"; d="scan'208,223";a="89279471"
Received: from pgsmsx601.gar.corp.intel.com ([10.221.43.69])
	by orsmga001.jf.intel.com with ESMTP; 22 Dec 2011 02:01:30 -0800
Received: from pgsmsx102.gar.corp.intel.com (10.221.44.80) by
	pgsmsx601.gar.corp.intel.com (10.221.43.69) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Thu, 22 Dec 2011 18:01:26 +0800
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	PGSMSX102.gar.corp.intel.com (10.221.44.80) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Thu, 22 Dec 2011 18:01:25 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.38]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.199]) with mapi id
	14.01.0355.002; Thu, 22 Dec 2011 18:01:24 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: "konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Thread-Topic: [PATCH 02/10] xen/mce: Change the machine check point
Thread-Index: AczAkKkEITegXyVHTuCwa305zIirPw==
Date: Thu, 22 Dec 2011 10:01:23 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC829233589F1@SHSMSX101.ccr.corp.intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
Content-Type: multipart/mixed;
	boundary="_002_DE8DF0795D48FD4CA783C40EC829233589F1SHSMSX101ccrcorpint_"
MIME-Version: 1.0
Cc: "Jiang, Yunhong" <yunhong.jiang@intel.com>,
	"jeremy.fitzhardinge@citrix.com" <jeremy.fitzhardinge@citrix.com>
Subject: [Xen-devel] [PATCH 02/10] xen/mce: Change the machine check point
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--_002_DE8DF0795D48FD4CA783C40EC829233589F1SHSMSX101ccrcorpint_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

>From 80221e743d1a693670d701f383da26c8e5d5bf98 Mon Sep 17 00:00:00 2001
From: Liu Jinsong <jinsong.liu@intel.com>
Date: Wed, 7 Dec 2011 05:26:16 +0800
Subject: [PATCH 02/10] xen/mce: Change the machine check point

This patch backport from Jeremy's pvops commit
073349667402682c997394b3fcdbbeb6707f368f

Enable MCE support in dom0, so that if a MCE happen and that MCE impact
dom0, dom0 can receive a vMCE.

Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
Signed-off-by: Ke, Liping <liping.ke@intel.com>
Signed-off-by: Jiang, Yunhong <yunhong.jiang@intel.com>
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
---
 arch/x86/xen/enlighten.c |    7 +++++--
 1 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index b073e4c..13e7a16 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -526,7 +526,7 @@ static int cvt_gate_to_trap(int vector, const gate_desc=
 *val,
 	 * Look for known traps using IST, and substitute them
 	 * appropriately.  The debugger ones are the only ones we care
 	 * about.  Xen will handle faults like double_fault and
-	 * machine_check, so we should never see them.  Warn if
+	 * nmi, so we should never see them.  Warn if
 	 * there's an unexpected IST-using fault handler.
 	 */
 	if (addr =3D=3D (unsigned long)debug)
@@ -541,7 +541,10 @@ static int cvt_gate_to_trap(int vector, const gate_des=
c *val,
 		return 0;
 #ifdef CONFIG_X86_MCE
 	} else if (addr =3D=3D (unsigned long)machine_check) {
-		return 0;
+		if (xen_initial_domain())
+			addr =3D (unsigned long)machine_check;
+		else
+			return 0;
 #endif
 	} else {
 		/* Some other trap using IST? */
--=20
1.6.5.6

--_002_DE8DF0795D48FD4CA783C40EC829233589F1SHSMSX101ccrcorpint_
Content-Type: application/octet-stream;
	name="0002-xen-mce-Change-the-machine-check-point.patch"
Content-Description: 0002-xen-mce-Change-the-machine-check-point.patch
Content-Disposition: attachment;
	filename="0002-xen-mce-Change-the-machine-check-point.patch"; size=1691;
	creation-date="Wed, 14 Dec 2011 15:20:15 GMT";
	modification-date="Wed, 14 Dec 2011 15:03:34 GMT"
Content-Transfer-Encoding: base64

RnJvbSA4MDIyMWU3NDNkMWE2OTM2NzBkNzAxZjM4M2RhMjZjOGU1ZDViZjk4IE1vbiBTZXAgMTcg
MDA6MDA6MDAgMjAwMQpGcm9tOiBMaXUgSmluc29uZyA8amluc29uZy5saXVAaW50ZWwuY29tPgpE
YXRlOiBXZWQsIDcgRGVjIDIwMTEgMDU6MjY6MTYgKzA4MDAKU3ViamVjdDogW1BBVENIIDAyLzEw
XSB4ZW4vbWNlOiBDaGFuZ2UgdGhlIG1hY2hpbmUgY2hlY2sgcG9pbnQKClRoaXMgcGF0Y2ggYmFj
a3BvcnQgZnJvbSBKZXJlbXkncyBwdm9wcyBjb21taXQKMDczMzQ5NjY3NDAyNjgyYzk5NzM5NGIz
ZmNkYmJlYjY3MDdmMzY4ZgoKRW5hYmxlIE1DRSBzdXBwb3J0IGluIGRvbTAsIHNvIHRoYXQgaWYg
YSBNQ0UgaGFwcGVuIGFuZCB0aGF0IE1DRSBpbXBhY3QKZG9tMCwgZG9tMCBjYW4gcmVjZWl2ZSBh
IHZNQ0UuCgpTaWduZWQtb2ZmLWJ5OiBMaXUsIEppbnNvbmcgPGppbnNvbmcubGl1QGludGVsLmNv
bT4KU2lnbmVkLW9mZi1ieTogS2UsIExpcGluZyA8bGlwaW5nLmtlQGludGVsLmNvbT4KU2lnbmVk
LW9mZi1ieTogSmlhbmcsIFl1bmhvbmcgPHl1bmhvbmcuamlhbmdAaW50ZWwuY29tPgpTaWduZWQt
b2ZmLWJ5OiBKZXJlbXkgRml0emhhcmRpbmdlIDxqZXJlbXkuZml0emhhcmRpbmdlQGNpdHJpeC5j
b20+Ci0tLQogYXJjaC94ODYveGVuL2VubGlnaHRlbi5jIHwgICAgNyArKysrKy0tCiAxIGZpbGVz
IGNoYW5nZWQsIDUgaW5zZXJ0aW9ucygrKSwgMiBkZWxldGlvbnMoLSkKCmRpZmYgLS1naXQgYS9h
cmNoL3g4Ni94ZW4vZW5saWdodGVuLmMgYi9hcmNoL3g4Ni94ZW4vZW5saWdodGVuLmMKaW5kZXgg
YjA3M2U0Yy4uMTNlN2ExNiAxMDA2NDQKLS0tIGEvYXJjaC94ODYveGVuL2VubGlnaHRlbi5jCisr
KyBiL2FyY2gveDg2L3hlbi9lbmxpZ2h0ZW4uYwpAQCAtNTI2LDcgKzUyNiw3IEBAIHN0YXRpYyBp
bnQgY3Z0X2dhdGVfdG9fdHJhcChpbnQgdmVjdG9yLCBjb25zdCBnYXRlX2Rlc2MgKnZhbCwKIAkg
KiBMb29rIGZvciBrbm93biB0cmFwcyB1c2luZyBJU1QsIGFuZCBzdWJzdGl0dXRlIHRoZW0KIAkg
KiBhcHByb3ByaWF0ZWx5LiAgVGhlIGRlYnVnZ2VyIG9uZXMgYXJlIHRoZSBvbmx5IG9uZXMgd2Ug
Y2FyZQogCSAqIGFib3V0LiAgWGVuIHdpbGwgaGFuZGxlIGZhdWx0cyBsaWtlIGRvdWJsZV9mYXVs
dCBhbmQKLQkgKiBtYWNoaW5lX2NoZWNrLCBzbyB3ZSBzaG91bGQgbmV2ZXIgc2VlIHRoZW0uICBX
YXJuIGlmCisJICogbm1pLCBzbyB3ZSBzaG91bGQgbmV2ZXIgc2VlIHRoZW0uICBXYXJuIGlmCiAJ
ICogdGhlcmUncyBhbiB1bmV4cGVjdGVkIElTVC11c2luZyBmYXVsdCBoYW5kbGVyLgogCSAqLwog
CWlmIChhZGRyID09ICh1bnNpZ25lZCBsb25nKWRlYnVnKQpAQCAtNTQxLDcgKzU0MSwxMCBAQCBz
dGF0aWMgaW50IGN2dF9nYXRlX3RvX3RyYXAoaW50IHZlY3RvciwgY29uc3QgZ2F0ZV9kZXNjICp2
YWwsCiAJCXJldHVybiAwOwogI2lmZGVmIENPTkZJR19YODZfTUNFCiAJfSBlbHNlIGlmIChhZGRy
ID09ICh1bnNpZ25lZCBsb25nKW1hY2hpbmVfY2hlY2spIHsKLQkJcmV0dXJuIDA7CisJCWlmICh4
ZW5faW5pdGlhbF9kb21haW4oKSkKKwkJCWFkZHIgPSAodW5zaWduZWQgbG9uZyltYWNoaW5lX2No
ZWNrOworCQllbHNlCisJCQlyZXR1cm4gMDsKICNlbmRpZgogCX0gZWxzZSB7CiAJCS8qIFNvbWUg
b3RoZXIgdHJhcCB1c2luZyBJU1Q/ICovCi0tIAoxLjYuNS42Cgo=

--_002_DE8DF0795D48FD4CA783C40EC829233589F1SHSMSX101ccrcorpint_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--_002_DE8DF0795D48FD4CA783C40EC829233589F1SHSMSX101ccrcorpint_--


From xen-devel-bounces@lists.xensource.com Thu Dec 22 10:01:56 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 Dec 2011 10:01:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdfT5-0004RU-TC; Thu, 22 Dec 2011 10:01:43 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1RdfT4-0004Q2-2V
	for xen-devel@lists.xensource.com; Thu, 22 Dec 2011 10:01:42 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1324548094!6501158!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMjkwMjgz\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12597 invoked from network); 22 Dec 2011 10:01:35 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-2.tower-174.messagelabs.com with SMTP;
	22 Dec 2011 10:01:35 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga101.jf.intel.com with ESMTP; 22 Dec 2011 02:01:31 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.67,352,1309762800"; d="scan'208,223";a="89279471"
Received: from pgsmsx601.gar.corp.intel.com ([10.221.43.69])
	by orsmga001.jf.intel.com with ESMTP; 22 Dec 2011 02:01:30 -0800
Received: from pgsmsx102.gar.corp.intel.com (10.221.44.80) by
	pgsmsx601.gar.corp.intel.com (10.221.43.69) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Thu, 22 Dec 2011 18:01:26 +0800
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	PGSMSX102.gar.corp.intel.com (10.221.44.80) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Thu, 22 Dec 2011 18:01:25 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.38]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.199]) with mapi id
	14.01.0355.002; Thu, 22 Dec 2011 18:01:24 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: "konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Thread-Topic: [PATCH 02/10] xen/mce: Change the machine check point
Thread-Index: AczAkKkEITegXyVHTuCwa305zIirPw==
Date: Thu, 22 Dec 2011 10:01:23 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC829233589F1@SHSMSX101.ccr.corp.intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
Content-Type: multipart/mixed;
	boundary="_002_DE8DF0795D48FD4CA783C40EC829233589F1SHSMSX101ccrcorpint_"
MIME-Version: 1.0
Cc: "Jiang, Yunhong" <yunhong.jiang@intel.com>,
	"jeremy.fitzhardinge@citrix.com" <jeremy.fitzhardinge@citrix.com>
Subject: [Xen-devel] [PATCH 02/10] xen/mce: Change the machine check point
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--_002_DE8DF0795D48FD4CA783C40EC829233589F1SHSMSX101ccrcorpint_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

>From 80221e743d1a693670d701f383da26c8e5d5bf98 Mon Sep 17 00:00:00 2001
From: Liu Jinsong <jinsong.liu@intel.com>
Date: Wed, 7 Dec 2011 05:26:16 +0800
Subject: [PATCH 02/10] xen/mce: Change the machine check point

This patch backport from Jeremy's pvops commit
073349667402682c997394b3fcdbbeb6707f368f

Enable MCE support in dom0, so that if a MCE happen and that MCE impact
dom0, dom0 can receive a vMCE.

Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
Signed-off-by: Ke, Liping <liping.ke@intel.com>
Signed-off-by: Jiang, Yunhong <yunhong.jiang@intel.com>
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
---
 arch/x86/xen/enlighten.c |    7 +++++--
 1 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index b073e4c..13e7a16 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -526,7 +526,7 @@ static int cvt_gate_to_trap(int vector, const gate_desc=
 *val,
 	 * Look for known traps using IST, and substitute them
 	 * appropriately.  The debugger ones are the only ones we care
 	 * about.  Xen will handle faults like double_fault and
-	 * machine_check, so we should never see them.  Warn if
+	 * nmi, so we should never see them.  Warn if
 	 * there's an unexpected IST-using fault handler.
 	 */
 	if (addr =3D=3D (unsigned long)debug)
@@ -541,7 +541,10 @@ static int cvt_gate_to_trap(int vector, const gate_des=
c *val,
 		return 0;
 #ifdef CONFIG_X86_MCE
 	} else if (addr =3D=3D (unsigned long)machine_check) {
-		return 0;
+		if (xen_initial_domain())
+			addr =3D (unsigned long)machine_check;
+		else
+			return 0;
 #endif
 	} else {
 		/* Some other trap using IST? */
--=20
1.6.5.6

--_002_DE8DF0795D48FD4CA783C40EC829233589F1SHSMSX101ccrcorpint_
Content-Type: application/octet-stream;
	name="0002-xen-mce-Change-the-machine-check-point.patch"
Content-Description: 0002-xen-mce-Change-the-machine-check-point.patch
Content-Disposition: attachment;
	filename="0002-xen-mce-Change-the-machine-check-point.patch"; size=1691;
	creation-date="Wed, 14 Dec 2011 15:20:15 GMT";
	modification-date="Wed, 14 Dec 2011 15:03:34 GMT"
Content-Transfer-Encoding: base64

RnJvbSA4MDIyMWU3NDNkMWE2OTM2NzBkNzAxZjM4M2RhMjZjOGU1ZDViZjk4IE1vbiBTZXAgMTcg
MDA6MDA6MDAgMjAwMQpGcm9tOiBMaXUgSmluc29uZyA8amluc29uZy5saXVAaW50ZWwuY29tPgpE
YXRlOiBXZWQsIDcgRGVjIDIwMTEgMDU6MjY6MTYgKzA4MDAKU3ViamVjdDogW1BBVENIIDAyLzEw
XSB4ZW4vbWNlOiBDaGFuZ2UgdGhlIG1hY2hpbmUgY2hlY2sgcG9pbnQKClRoaXMgcGF0Y2ggYmFj
a3BvcnQgZnJvbSBKZXJlbXkncyBwdm9wcyBjb21taXQKMDczMzQ5NjY3NDAyNjgyYzk5NzM5NGIz
ZmNkYmJlYjY3MDdmMzY4ZgoKRW5hYmxlIE1DRSBzdXBwb3J0IGluIGRvbTAsIHNvIHRoYXQgaWYg
YSBNQ0UgaGFwcGVuIGFuZCB0aGF0IE1DRSBpbXBhY3QKZG9tMCwgZG9tMCBjYW4gcmVjZWl2ZSBh
IHZNQ0UuCgpTaWduZWQtb2ZmLWJ5OiBMaXUsIEppbnNvbmcgPGppbnNvbmcubGl1QGludGVsLmNv
bT4KU2lnbmVkLW9mZi1ieTogS2UsIExpcGluZyA8bGlwaW5nLmtlQGludGVsLmNvbT4KU2lnbmVk
LW9mZi1ieTogSmlhbmcsIFl1bmhvbmcgPHl1bmhvbmcuamlhbmdAaW50ZWwuY29tPgpTaWduZWQt
b2ZmLWJ5OiBKZXJlbXkgRml0emhhcmRpbmdlIDxqZXJlbXkuZml0emhhcmRpbmdlQGNpdHJpeC5j
b20+Ci0tLQogYXJjaC94ODYveGVuL2VubGlnaHRlbi5jIHwgICAgNyArKysrKy0tCiAxIGZpbGVz
IGNoYW5nZWQsIDUgaW5zZXJ0aW9ucygrKSwgMiBkZWxldGlvbnMoLSkKCmRpZmYgLS1naXQgYS9h
cmNoL3g4Ni94ZW4vZW5saWdodGVuLmMgYi9hcmNoL3g4Ni94ZW4vZW5saWdodGVuLmMKaW5kZXgg
YjA3M2U0Yy4uMTNlN2ExNiAxMDA2NDQKLS0tIGEvYXJjaC94ODYveGVuL2VubGlnaHRlbi5jCisr
KyBiL2FyY2gveDg2L3hlbi9lbmxpZ2h0ZW4uYwpAQCAtNTI2LDcgKzUyNiw3IEBAIHN0YXRpYyBp
bnQgY3Z0X2dhdGVfdG9fdHJhcChpbnQgdmVjdG9yLCBjb25zdCBnYXRlX2Rlc2MgKnZhbCwKIAkg
KiBMb29rIGZvciBrbm93biB0cmFwcyB1c2luZyBJU1QsIGFuZCBzdWJzdGl0dXRlIHRoZW0KIAkg
KiBhcHByb3ByaWF0ZWx5LiAgVGhlIGRlYnVnZ2VyIG9uZXMgYXJlIHRoZSBvbmx5IG9uZXMgd2Ug
Y2FyZQogCSAqIGFib3V0LiAgWGVuIHdpbGwgaGFuZGxlIGZhdWx0cyBsaWtlIGRvdWJsZV9mYXVs
dCBhbmQKLQkgKiBtYWNoaW5lX2NoZWNrLCBzbyB3ZSBzaG91bGQgbmV2ZXIgc2VlIHRoZW0uICBX
YXJuIGlmCisJICogbm1pLCBzbyB3ZSBzaG91bGQgbmV2ZXIgc2VlIHRoZW0uICBXYXJuIGlmCiAJ
ICogdGhlcmUncyBhbiB1bmV4cGVjdGVkIElTVC11c2luZyBmYXVsdCBoYW5kbGVyLgogCSAqLwog
CWlmIChhZGRyID09ICh1bnNpZ25lZCBsb25nKWRlYnVnKQpAQCAtNTQxLDcgKzU0MSwxMCBAQCBz
dGF0aWMgaW50IGN2dF9nYXRlX3RvX3RyYXAoaW50IHZlY3RvciwgY29uc3QgZ2F0ZV9kZXNjICp2
YWwsCiAJCXJldHVybiAwOwogI2lmZGVmIENPTkZJR19YODZfTUNFCiAJfSBlbHNlIGlmIChhZGRy
ID09ICh1bnNpZ25lZCBsb25nKW1hY2hpbmVfY2hlY2spIHsKLQkJcmV0dXJuIDA7CisJCWlmICh4
ZW5faW5pdGlhbF9kb21haW4oKSkKKwkJCWFkZHIgPSAodW5zaWduZWQgbG9uZyltYWNoaW5lX2No
ZWNrOworCQllbHNlCisJCQlyZXR1cm4gMDsKICNlbmRpZgogCX0gZWxzZSB7CiAJCS8qIFNvbWUg
b3RoZXIgdHJhcCB1c2luZyBJU1Q/ICovCi0tIAoxLjYuNS42Cgo=

--_002_DE8DF0795D48FD4CA783C40EC829233589F1SHSMSX101ccrcorpint_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--_002_DE8DF0795D48FD4CA783C40EC829233589F1SHSMSX101ccrcorpint_--


From xen-devel-bounces@lists.xensource.com Thu Dec 22 10:02:42 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 Dec 2011 10:02:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdfTq-0004ZN-D4; Thu, 22 Dec 2011 10:02:30 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1RdfTo-0004YE-DS
	for xen-devel@lists.xensource.com; Thu, 22 Dec 2011 10:02:29 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1324548140!8273319!1
X-Originating-IP: [134.134.136.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjQgPT4gMzE5NDEx\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2563 invoked from network); 22 Dec 2011 10:02:20 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-12.tower-182.messagelabs.com with SMTP;
	22 Dec 2011 10:02:20 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga102.jf.intel.com with ESMTP; 22 Dec 2011 02:02:19 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.67,352,1309762800"; d="scan'208,223";a="89280015"
Received: from pgsmsx602.gar.corp.intel.com ([10.221.43.81])
	by orsmga001.jf.intel.com with ESMTP; 22 Dec 2011 02:02:18 -0800
Received: from pgsmsx104.gar.corp.intel.com (10.221.44.91) by
	pgsmsx602.gar.corp.intel.com (10.221.43.81) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Thu, 22 Dec 2011 18:02:17 +0800
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	PGSMSX104.gar.corp.intel.com (10.221.44.91) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Thu, 22 Dec 2011 18:02:16 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.38]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.199]) with mapi id
	14.01.0355.002; Thu, 22 Dec 2011 18:02:15 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: "konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Thread-Topic: [PATCH 03/10] Xen: Export host physical CPU information to dom0
Thread-Index: AczAkMeDvnoI6swkT+qbS+vbRI9caA==
Date: Thu, 22 Dec 2011 10:02:14 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC82923358A04@SHSMSX101.ccr.corp.intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
Content-Type: multipart/mixed;
	boundary="_002_DE8DF0795D48FD4CA783C40EC82923358A04SHSMSX101ccrcorpint_"
MIME-Version: 1.0
Cc: "Jiang, Yunhong" <yunhong.jiang@intel.com>,
	"jeremy.fitzhardinge@citrix.com" <jeremy.fitzhardinge@citrix.com>
Subject: [Xen-devel] [PATCH 03/10] Xen: Export host physical CPU information
	to dom0
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--_002_DE8DF0795D48FD4CA783C40EC82923358A04SHSMSX101ccrcorpint_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

>From 04151aa18b48a452cc9d0696f36aa96c690ca011 Mon Sep 17 00:00:00 2001
From: Liu Jinsong <jinsong.liu@intel.com>
Date: Thu, 8 Dec 2011 22:28:07 +0800
Subject: [PATCH 03/10] Xen: Export host physical CPU information to dom0

This patch rebased from Jeremy's pvops commit
3b34cd19627c6e191b15fd6cb59f997b8db21e19 and
68320323a51c2378aca433c76157d9e66104ff1e

This patch expose host's physical CPU information to dom0 in sysfs, so
that dom0's management tools can control the physical CPU if needed.

It also provides interface in sysfs to logical online/offline a physical CP=
U.

Notice: The information in dom0 is synced with xen hypervisor asynchronousl=
y.

Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
Signed-off-by: Jiang, Yunhong <yunhong.jiang@intel.com>
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
---
 drivers/xen/Makefile             |    2 +-
 drivers/xen/pcpu.c               |  452 ++++++++++++++++++++++++++++++++++=
++++
 include/xen/interface/platform.h |   28 +++
 include/xen/interface/xen.h      |    1 +
 include/xen/pcpu.h               |   32 +++
 5 files changed, 514 insertions(+), 1 deletions(-)
 create mode 100644 drivers/xen/pcpu.c
 create mode 100644 include/xen/pcpu.h

diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
index 405cce9..aedaf48 100644
--- a/drivers/xen/Makefile
+++ b/drivers/xen/Makefile
@@ -1,4 +1,4 @@
-obj-y	+=3D grant-table.o features.o events.o manage.o balloon.o
+obj-y	+=3D grant-table.o features.o events.o manage.o balloon.o pcpu.o
 obj-y	+=3D xenbus/
=20
 nostackp :=3D $(call cc-option, -fno-stack-protector)
diff --git a/drivers/xen/pcpu.c b/drivers/xen/pcpu.c
new file mode 100644
index 0000000..6d1a770
--- /dev/null
+++ b/drivers/xen/pcpu.c
@@ -0,0 +1,452 @@
+/*
+ * pcpu.c - management physical cpu in dom0 environment
+ */
+#include <linux/interrupt.h>
+#include <linux/spinlock.h>
+#include <asm/xen/hypervisor.h>
+#include <asm/xen/hypercall.h>
+#include <linux/cpu.h>
+#include <xen/xenbus.h>
+#include <xen/pcpu.h>
+#include <xen/events.h>
+#include <xen/acpi.h>
+
+static struct sysdev_class xen_pcpu_sysdev_class =3D {
+	.name =3D "xen_pcpu",
+};
+
+static DEFINE_MUTEX(xen_pcpu_lock);
+static RAW_NOTIFIER_HEAD(xen_pcpu_chain);
+
+/* No need for irq disable since hotplug notify is in workqueue context */
+#define get_pcpu_lock() mutex_lock(&xen_pcpu_lock);
+#define put_pcpu_lock() mutex_unlock(&xen_pcpu_lock);
+
+struct xen_pcpus {
+	struct list_head list;
+	int present;
+};
+static struct xen_pcpus xen_pcpus;
+
+int register_xen_pcpu_notifier(struct notifier_block *nb)
+{
+	int ret;
+
+	/* All refer to the chain notifier is protected by the pcpu_lock */
+	get_pcpu_lock();
+	ret =3D raw_notifier_chain_register(&xen_pcpu_chain, nb);
+	put_pcpu_lock();
+	return ret;
+}
+EXPORT_SYMBOL_GPL(register_xen_pcpu_notifier);
+
+void unregister_xen_pcpu_notifier(struct notifier_block *nb)
+{
+	get_pcpu_lock();
+	raw_notifier_chain_unregister(&xen_pcpu_chain, nb);
+	put_pcpu_lock();
+}
+EXPORT_SYMBOL_GPL(unregister_xen_pcpu_notifier);
+
+static int xen_pcpu_down(uint32_t xen_id)
+{
+	int ret;
+	xen_platform_op_t op =3D {
+		.cmd			=3D XENPF_cpu_offline,
+		.interface_version	=3D XENPF_INTERFACE_VERSION,
+		.u.cpu_ol.cpuid	=3D xen_id,
+	};
+
+	ret =3D HYPERVISOR_dom0_op(&op);
+	return ret;
+}
+
+static int xen_pcpu_up(uint32_t xen_id)
+{
+	int ret;
+	xen_platform_op_t op =3D {
+		.cmd			=3D XENPF_cpu_online,
+		.interface_version	=3D XENPF_INTERFACE_VERSION,
+		.u.cpu_ol.cpuid	=3D xen_id,
+	};
+
+	ret =3D HYPERVISOR_dom0_op(&op);
+	return ret;
+}
+
+static ssize_t show_online(struct sys_device *dev,
+			struct sysdev_attribute *attr,
+			char *buf)
+{
+	struct pcpu *cpu =3D container_of(dev, struct pcpu, sysdev);
+
+	return sprintf(buf, "%u\n", !!(cpu->flags & XEN_PCPU_FLAGS_ONLINE));
+}
+
+static ssize_t __ref store_online(struct sys_device *dev,
+				  struct sysdev_attribute *attr,
+				  const char *buf, size_t count)
+{
+	struct pcpu *cpu =3D container_of(dev, struct pcpu, sysdev);
+	ssize_t ret;
+
+	switch (buf[0]) {
+	case '0':
+		ret =3D xen_pcpu_down(cpu->xen_id);
+		break;
+	case '1':
+		ret =3D xen_pcpu_up(cpu->xen_id);
+		break;
+	default:
+		ret =3D -EINVAL;
+	}
+
+	if (ret >=3D 0)
+		ret =3D count;
+	return ret;
+}
+
+static SYSDEV_ATTR(online, 0644, show_online, store_online);
+
+static ssize_t show_apicid(struct sys_device *dev,
+			struct sysdev_attribute *attr,
+			char *buf)
+{
+	struct pcpu *cpu =3D container_of(dev, struct pcpu, sysdev);
+
+	return sprintf(buf, "%u\n", cpu->apic_id);
+}
+
+static ssize_t show_acpiid(struct sys_device *dev,
+			struct sysdev_attribute *attr,
+			char *buf)
+{
+	struct pcpu *cpu =3D container_of(dev, struct pcpu, sysdev);
+
+	return sprintf(buf, "%u\n", cpu->acpi_id);
+}
+static SYSDEV_ATTR(apic_id, 0444, show_apicid, NULL);
+static SYSDEV_ATTR(acpi_id, 0444, show_acpiid, NULL);
+
+static int xen_pcpu_free(struct pcpu *pcpu)
+{
+	if (!pcpu)
+		return 0;
+
+	sysdev_remove_file(&pcpu->sysdev, &attr_online);
+	sysdev_unregister(&pcpu->sysdev);
+	list_del(&pcpu->pcpu_list);
+	kfree(pcpu);
+
+	return 0;
+}
+
+static inline int same_pcpu(struct xenpf_pcpuinfo *info,
+			    struct pcpu *pcpu)
+{
+	return (pcpu->apic_id =3D=3D info->apic_id) &&
+		(pcpu->xen_id =3D=3D info->xen_cpuid);
+}
+
+/*
+ * Return 1 if online status changed
+ */
+static int xen_pcpu_online_check(struct xenpf_pcpuinfo *info,
+				 struct pcpu *pcpu)
+{
+	int result =3D 0;
+
+	if (info->xen_cpuid !=3D pcpu->xen_id)
+		return 0;
+
+	if (xen_pcpu_online(info->flags) && !xen_pcpu_online(pcpu->flags)) {
+		/* the pcpu is onlined */
+		pcpu->flags |=3D XEN_PCPU_FLAGS_ONLINE;
+		kobject_uevent(&pcpu->sysdev.kobj, KOBJ_ONLINE);
+		raw_notifier_call_chain(&xen_pcpu_chain,
+			XEN_PCPU_ONLINE, (void *)(long)pcpu->xen_id);
+		result =3D 1;
+	} else if (!xen_pcpu_online(info->flags) &&
+		 xen_pcpu_online(pcpu->flags))  {
+		/* The pcpu is offlined now */
+		pcpu->flags &=3D ~XEN_PCPU_FLAGS_ONLINE;
+		kobject_uevent(&pcpu->sysdev.kobj, KOBJ_OFFLINE);
+		raw_notifier_call_chain(&xen_pcpu_chain,
+			XEN_PCPU_OFFLINE, (void *)(long)pcpu->xen_id);
+		result =3D 1;
+	}
+
+	return result;
+}
+
+static int pcpu_sysdev_init(struct pcpu *cpu)
+{
+	int error;
+
+	error =3D sysdev_register(&cpu->sysdev);
+	if (error) {
+		printk(KERN_WARNING "xen_pcpu_add: Failed to register pcpu\n");
+		kfree(cpu);
+		return -1;
+	}
+	sysdev_create_file(&cpu->sysdev, &attr_online);
+	sysdev_create_file(&cpu->sysdev, &attr_apic_id);
+	sysdev_create_file(&cpu->sysdev, &attr_acpi_id);
+	return 0;
+}
+
+static struct pcpu *get_pcpu(int xen_id)
+{
+	struct pcpu *pcpu =3D NULL;
+
+	list_for_each_entry(pcpu, &xen_pcpus.list, pcpu_list) {
+		if (pcpu->xen_id =3D=3D xen_id)
+			return pcpu;
+	}
+	return NULL;
+}
+
+static struct pcpu *init_pcpu(struct xenpf_pcpuinfo *info)
+{
+	struct pcpu *pcpu;
+
+	if (info->flags & XEN_PCPU_FLAGS_INVALID)
+		return NULL;
+
+	/* The PCPU is just added */
+	pcpu =3D kzalloc(sizeof(struct pcpu), GFP_KERNEL);
+	if (!pcpu)
+		return NULL;
+
+	INIT_LIST_HEAD(&pcpu->pcpu_list);
+	pcpu->xen_id =3D info->xen_cpuid;
+	pcpu->apic_id =3D info->apic_id;
+	pcpu->acpi_id =3D info->acpi_id;
+	pcpu->flags =3D info->flags;
+
+	pcpu->sysdev.cls =3D &xen_pcpu_sysdev_class;
+	pcpu->sysdev.id =3D info->xen_cpuid;
+
+	if (pcpu_sysdev_init(pcpu)) {
+		kfree(pcpu);
+		return NULL;
+	}
+
+	list_add_tail(&pcpu->pcpu_list, &xen_pcpus.list);
+	raw_notifier_call_chain(&xen_pcpu_chain,
+				XEN_PCPU_ADD,
+				(void *)(long)pcpu->xen_id);
+	return pcpu;
+}
+
+#define PCPU_NO_CHANGE			0
+#define PCPU_ADDED			1
+#define PCPU_ONLINE_OFFLINE		2
+#define PCPU_REMOVED			3
+/*
+ * Caller should hold the pcpu lock
+ * < 0: Something wrong
+ * 0: No changes
+ * > 0: State changed
+ */
+static struct pcpu *_sync_pcpu(int cpu_num, int *max_id, int *result)
+{
+	struct pcpu *pcpu =3D NULL;
+	struct xenpf_pcpuinfo *info;
+	xen_platform_op_t op =3D {
+		.cmd            =3D XENPF_get_cpuinfo,
+		.interface_version  =3D XENPF_INTERFACE_VERSION,
+	};
+	int ret;
+
+	*result =3D -1;
+
+	info =3D &op.u.pcpu_info;
+	info->xen_cpuid =3D cpu_num;
+
+	ret =3D HYPERVISOR_dom0_op(&op);
+	if (ret)
+		return NULL;
+
+	if (max_id)
+		*max_id =3D op.u.pcpu_info.max_present;
+
+	pcpu =3D get_pcpu(cpu_num);
+
+	if (info->flags & XEN_PCPU_FLAGS_INVALID) {
+		/* The pcpu has been removed */
+		*result =3D PCPU_NO_CHANGE;
+		if (pcpu) {
+			raw_notifier_call_chain(&xen_pcpu_chain,
+			  XEN_PCPU_REMOVE,
+			  (void *)(long)pcpu->xen_id);
+			xen_pcpu_free(pcpu);
+			*result =3D PCPU_REMOVED;
+		}
+		return NULL;
+	}
+
+
+	if (!pcpu) {
+		*result =3D PCPU_ADDED;
+		pcpu =3D init_pcpu(info);
+		if (pcpu =3D=3D NULL) {
+			printk(KERN_WARNING "Failed to init pcpu %x\n",
+			  info->xen_cpuid);
+			  *result =3D -1;
+		}
+	} else {
+		*result =3D PCPU_NO_CHANGE;
+		/*
+		 * Old PCPU is replaced with a new pcpu, this means
+		 * several virq is missed, will it happen?
+		 */
+		if (!same_pcpu(info, pcpu)) {
+			printk(KERN_WARNING "Pcpu %x changed!\n",
+			  pcpu->xen_id);
+			pcpu->apic_id =3D info->apic_id;
+			pcpu->acpi_id =3D info->acpi_id;
+		}
+		if (xen_pcpu_online_check(info, pcpu))
+			*result =3D PCPU_ONLINE_OFFLINE;
+	}
+	return pcpu;
+}
+
+int xen_pcpu_index(uint32_t id, int is_acpiid)
+{
+	int cpu_num =3D 0, max_id =3D 0, ret;
+	xen_platform_op_t op =3D {
+		.cmd            =3D XENPF_get_cpuinfo,
+		.interface_version  =3D XENPF_INTERFACE_VERSION,
+	};
+	struct xenpf_pcpuinfo *info =3D &op.u.pcpu_info;
+
+	info->xen_cpuid =3D 0;
+	ret =3D HYPERVISOR_dom0_op(&op);
+	if (ret)
+		return -1;
+	max_id =3D op.u.pcpu_info.max_present;
+
+	while ((cpu_num <=3D max_id)) {
+		info->xen_cpuid =3D cpu_num;
+		ret =3D HYPERVISOR_dom0_op(&op);
+		if (ret)
+			continue;
+
+		if (op.u.pcpu_info.max_present > max_id)
+			max_id =3D op.u.pcpu_info.max_present;
+		if (id =3D=3D (is_acpiid ? info->acpi_id : info->apic_id))
+			return cpu_num;
+		cpu_num++;
+	}
+
+    return -1;
+}
+EXPORT_SYMBOL(xen_pcpu_index);
+
+/*
+ * Sync dom0's pcpu information with xen hypervisor's
+ */
+static int xen_sync_pcpus(void)
+{
+	/*
+	 * Boot cpu always have cpu_id 0 in xen
+	 */
+	int cpu_num =3D 0, max_id =3D 0, result =3D 0, present =3D 0;
+	struct list_head *elem, *tmp;
+	struct pcpu *pcpu;
+
+	get_pcpu_lock();
+
+	while ((result >=3D 0) && (cpu_num <=3D max_id)) {
+		pcpu =3D _sync_pcpu(cpu_num, &max_id, &result);
+
+		printk(KERN_DEBUG "sync cpu %x get result %x max_id %x\n",
+			cpu_num, result, max_id);
+
+		switch (result)	{
+		case PCPU_NO_CHANGE:
+			if (pcpu)
+				present++;
+			break;
+		case PCPU_ADDED:
+		case PCPU_ONLINE_OFFLINE:
+			present++;
+		case PCPU_REMOVED:
+			break;
+		default:
+			printk(KERN_WARNING "Failed to sync pcpu %x\n",
+			  cpu_num);
+			break;
+
+		}
+		cpu_num++;
+	}
+
+	if (result < 0) {
+		list_for_each_safe(elem, tmp, &xen_pcpus.list) {
+			pcpu =3D list_entry(elem, struct pcpu, pcpu_list);
+			xen_pcpu_free(pcpu);
+		}
+		present =3D 0;
+	}
+
+	xen_pcpus.present =3D present;
+
+	put_pcpu_lock();
+
+	return 0;
+}
+
+static void xen_pcpu_dpc(struct work_struct *work)
+{
+	if (xen_sync_pcpus() < 0)
+		printk(KERN_WARNING
+			"xen_pcpu_dpc: Failed to sync pcpu information\n");
+}
+static DECLARE_WORK(xen_pcpu_work, xen_pcpu_dpc);
+
+int xen_pcpu_hotplug(int type, uint32_t apic_id)
+{
+	schedule_work(&xen_pcpu_work);
+
+	return 0;
+}
+EXPORT_SYMBOL(xen_pcpu_hotplug);
+
+static irqreturn_t xen_pcpu_interrupt(int irq, void *dev_id)
+{
+	schedule_work(&xen_pcpu_work);
+	return IRQ_HANDLED;
+}
+
+static int __init xen_pcpu_init(void)
+{
+	int err;
+
+	if (!xen_initial_domain())
+		return 0;
+
+	err =3D sysdev_class_register(&xen_pcpu_sysdev_class);
+	if (err) {
+		printk(KERN_WARNING
+			"xen_pcpu_init: register xen_pcpu sysdev Failed!\n");
+		return err;
+	}
+
+	INIT_LIST_HEAD(&xen_pcpus.list);
+	xen_pcpus.present =3D 0;
+
+	xen_sync_pcpus();
+	if (xen_pcpus.present > 0)
+		err =3D bind_virq_to_irqhandler(VIRQ_PCPU_STATE,
+			0, xen_pcpu_interrupt, 0, "pcpu", NULL);
+	if (err < 0)
+		printk(KERN_WARNING "xen_pcpu_init: "
+			"Failed to bind pcpu_state virq\n"
+			"You will lost latest information! \n");
+	return err;
+}
+
+arch_initcall(xen_pcpu_init);
diff --git a/include/xen/interface/platform.h b/include/xen/interface/platf=
orm.h
index c168468..47ffe16 100644
--- a/include/xen/interface/platform.h
+++ b/include/xen/interface/platform.h
@@ -297,6 +297,31 @@ struct xenpf_set_processor_pminfo {
 };
 DEFINE_GUEST_HANDLE_STRUCT(xenpf_set_processor_pminfo);
=20
+#define XENPF_get_cpuinfo 55
+struct xenpf_pcpuinfo {
+	/* IN */
+	uint32_t xen_cpuid;
+	/* OUT */
+	/* The maxium cpu_id that is present */
+	uint32_t max_present;
+#define XEN_PCPU_FLAGS_ONLINE   1
+	/* Correponding xen_cpuid is not present*/
+#define XEN_PCPU_FLAGS_INVALID  2
+	uint32_t flags;
+	uint32_t apic_id;
+	uint32_t acpi_id;
+};
+typedef struct xenpf_pcpuinfo xenpf_pcpuinfo_t;
+DEFINE_GUEST_HANDLE_STRUCT(xenpf_pcpuinfo_t);
+
+#define XENPF_cpu_online    56
+#define XENPF_cpu_offline   57
+struct xenpf_cpu_ol {
+    uint32_t cpuid;
+};
+typedef struct xenpf_cpu_ol xenpf_cpu_ol_t;
+DEFINE_GUEST_HANDLE_STRUCT(xenpf_cpu_ol_t);
+
 struct xen_platform_op {
 	uint32_t cmd;
 	uint32_t interface_version; /* XENPF_INTERFACE_VERSION */
@@ -312,9 +337,12 @@ struct xen_platform_op {
 		struct xenpf_change_freq       change_freq;
 		struct xenpf_getidletime       getidletime;
 		struct xenpf_set_processor_pminfo set_pminfo;
+		struct xenpf_pcpuinfo          pcpu_info;
+		struct xenpf_cpu_ol            cpu_ol;
 		uint8_t                        pad[128];
 	} u;
 };
+typedef struct xen_platform_op xen_platform_op_t;
 DEFINE_GUEST_HANDLE_STRUCT(xen_platform_op_t);
=20
 #endif /* __XEN_PUBLIC_PLATFORM_H__ */
diff --git a/include/xen/interface/xen.h b/include/xen/interface/xen.h
index 6a6e914..5a91c66 100644
--- a/include/xen/interface/xen.h
+++ b/include/xen/interface/xen.h
@@ -80,6 +80,7 @@
 #define VIRQ_CONSOLE    2  /* (DOM0) Bytes received on emergency console. =
*/
 #define VIRQ_DOM_EXC    3  /* (DOM0) Exceptional event for some domain.   =
*/
 #define VIRQ_DEBUGGER   6  /* (DOM0) A domain has paused for debugging.   =
*/
+#define VIRQ_PCPU_STATE 9  /* (DOM0) PCPU state changed                   =
*/
=20
 /* Architecture-specific VIRQ definitions. */
 #define VIRQ_ARCH_0    16
diff --git a/include/xen/pcpu.h b/include/xen/pcpu.h
new file mode 100644
index 0000000..7e8f9d1
--- /dev/null
+++ b/include/xen/pcpu.h
@@ -0,0 +1,32 @@
+#ifndef _XEN_PCPU_H
+#define _XEN_PCPU_H
+
+#include <xen/interface/platform.h>
+#include <linux/sysdev.h>
+
+extern int xen_pcpu_hotplug(int type, uint32_t apic_id);
+#define XEN_PCPU_ONLINE     0x01
+#define XEN_PCPU_OFFLINE    0x02
+#define XEN_PCPU_ADD        0x04
+#define XEN_PCPU_REMOVE     0x08
+
+struct pcpu {
+	struct list_head pcpu_list;
+	struct sys_device sysdev;
+	uint32_t xen_id;
+	uint32_t apic_id;
+	uint32_t acpi_id;
+	uint32_t flags;
+};
+
+static inline int xen_pcpu_online(uint32_t flags)
+{
+	return !!(flags & XEN_PCPU_FLAGS_ONLINE);
+}
+
+extern int register_xen_pcpu_notifier(struct notifier_block *nb);
+
+extern void unregister_xen_pcpu_notifier(struct notifier_block *nb);
+
+extern int xen_pcpu_index(uint32_t acpi_id, int is_acpiid);
+#endif
--=20
1.6.5.6

--_002_DE8DF0795D48FD4CA783C40EC82923358A04SHSMSX101ccrcorpint_
Content-Type: application/octet-stream;
	name="0003-Xen-Export-host-physical-CPU-information-to-dom0.patch"
Content-Description: 0003-Xen-Export-host-physical-CPU-information-to-dom0.patch
Content-Disposition: attachment;
	filename="0003-Xen-Export-host-physical-CPU-information-to-dom0.patch";
	size=15036; creation-date="Wed, 14 Dec 2011 15:20:15 GMT";
	modification-date="Wed, 14 Dec 2011 15:03:34 GMT"
Content-Transfer-Encoding: base64

RnJvbSAwNDE1MWFhMThiNDhhNDUyY2M5ZDA2OTZmMzZhYTk2YzY5MGNhMDExIE1vbiBTZXAgMTcg
MDA6MDA6MDAgMjAwMQpGcm9tOiBMaXUgSmluc29uZyA8amluc29uZy5saXVAaW50ZWwuY29tPgpE
YXRlOiBUaHUsIDggRGVjIDIwMTEgMjI6Mjg6MDcgKzA4MDAKU3ViamVjdDogW1BBVENIIDAzLzEw
XSBYZW46IEV4cG9ydCBob3N0IHBoeXNpY2FsIENQVSBpbmZvcm1hdGlvbiB0byBkb20wCgpUaGlz
IHBhdGNoIHJlYmFzZWQgZnJvbSBKZXJlbXkncyBwdm9wcyBjb21taXQKM2IzNGNkMTk2MjdjNmUx
OTFiMTVmZDZjYjU5Zjk5N2I4ZGIyMWUxOSBhbmQKNjgzMjAzMjNhNTFjMjM3OGFjYTQzM2M3NjE1
N2Q5ZTY2MTA0ZmYxZQoKVGhpcyBwYXRjaCBleHBvc2UgaG9zdCdzIHBoeXNpY2FsIENQVSBpbmZv
cm1hdGlvbiB0byBkb20wIGluIHN5c2ZzLCBzbwp0aGF0IGRvbTAncyBtYW5hZ2VtZW50IHRvb2xz
IGNhbiBjb250cm9sIHRoZSBwaHlzaWNhbCBDUFUgaWYgbmVlZGVkLgoKSXQgYWxzbyBwcm92aWRl
cyBpbnRlcmZhY2UgaW4gc3lzZnMgdG8gbG9naWNhbCBvbmxpbmUvb2ZmbGluZSBhIHBoeXNpY2Fs
IENQVS4KCk5vdGljZTogVGhlIGluZm9ybWF0aW9uIGluIGRvbTAgaXMgc3luY2VkIHdpdGggeGVu
IGh5cGVydmlzb3IgYXN5bmNocm9ub3VzbHkuCgpTaWduZWQtb2ZmLWJ5OiBMaXUsIEppbnNvbmcg
PGppbnNvbmcubGl1QGludGVsLmNvbT4KU2lnbmVkLW9mZi1ieTogSmlhbmcsIFl1bmhvbmcgPHl1
bmhvbmcuamlhbmdAaW50ZWwuY29tPgpTaWduZWQtb2ZmLWJ5OiBKZXJlbXkgRml0emhhcmRpbmdl
IDxqZXJlbXkuZml0emhhcmRpbmdlQGNpdHJpeC5jb20+Ci0tLQogZHJpdmVycy94ZW4vTWFrZWZp
bGUgICAgICAgICAgICAgfCAgICAyICstCiBkcml2ZXJzL3hlbi9wY3B1LmMgICAgICAgICAgICAg
ICB8ICA0NTIgKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysKIGluY2x1ZGUv
eGVuL2ludGVyZmFjZS9wbGF0Zm9ybS5oIHwgICAyOCArKysKIGluY2x1ZGUveGVuL2ludGVyZmFj
ZS94ZW4uaCAgICAgIHwgICAgMSArCiBpbmNsdWRlL3hlbi9wY3B1LmggICAgICAgICAgICAgICB8
ICAgMzIgKysrCiA1IGZpbGVzIGNoYW5nZWQsIDUxNCBpbnNlcnRpb25zKCspLCAxIGRlbGV0aW9u
cygtKQogY3JlYXRlIG1vZGUgMTAwNjQ0IGRyaXZlcnMveGVuL3BjcHUuYwogY3JlYXRlIG1vZGUg
MTAwNjQ0IGluY2x1ZGUveGVuL3BjcHUuaAoKZGlmZiAtLWdpdCBhL2RyaXZlcnMveGVuL01ha2Vm
aWxlIGIvZHJpdmVycy94ZW4vTWFrZWZpbGUKaW5kZXggNDA1Y2NlOS4uYWVkYWY0OCAxMDA2NDQK
LS0tIGEvZHJpdmVycy94ZW4vTWFrZWZpbGUKKysrIGIvZHJpdmVycy94ZW4vTWFrZWZpbGUKQEAg
LTEsNCArMSw0IEBACi1vYmoteQkrPSBncmFudC10YWJsZS5vIGZlYXR1cmVzLm8gZXZlbnRzLm8g
bWFuYWdlLm8gYmFsbG9vbi5vCitvYmoteQkrPSBncmFudC10YWJsZS5vIGZlYXR1cmVzLm8gZXZl
bnRzLm8gbWFuYWdlLm8gYmFsbG9vbi5vIHBjcHUubwogb2JqLXkJKz0geGVuYnVzLwogCiBub3N0
YWNrcCA6PSAkKGNhbGwgY2Mtb3B0aW9uLCAtZm5vLXN0YWNrLXByb3RlY3RvcikKZGlmZiAtLWdp
dCBhL2RyaXZlcnMveGVuL3BjcHUuYyBiL2RyaXZlcnMveGVuL3BjcHUuYwpuZXcgZmlsZSBtb2Rl
IDEwMDY0NAppbmRleCAwMDAwMDAwLi42ZDFhNzcwCi0tLSAvZGV2L251bGwKKysrIGIvZHJpdmVy
cy94ZW4vcGNwdS5jCkBAIC0wLDAgKzEsNDUyIEBACisvKgorICogcGNwdS5jIC0gbWFuYWdlbWVu
dCBwaHlzaWNhbCBjcHUgaW4gZG9tMCBlbnZpcm9ubWVudAorICovCisjaW5jbHVkZSA8bGludXgv
aW50ZXJydXB0Lmg+CisjaW5jbHVkZSA8bGludXgvc3BpbmxvY2suaD4KKyNpbmNsdWRlIDxhc20v
eGVuL2h5cGVydmlzb3IuaD4KKyNpbmNsdWRlIDxhc20veGVuL2h5cGVyY2FsbC5oPgorI2luY2x1
ZGUgPGxpbnV4L2NwdS5oPgorI2luY2x1ZGUgPHhlbi94ZW5idXMuaD4KKyNpbmNsdWRlIDx4ZW4v
cGNwdS5oPgorI2luY2x1ZGUgPHhlbi9ldmVudHMuaD4KKyNpbmNsdWRlIDx4ZW4vYWNwaS5oPgor
CitzdGF0aWMgc3RydWN0IHN5c2Rldl9jbGFzcyB4ZW5fcGNwdV9zeXNkZXZfY2xhc3MgPSB7CisJ
Lm5hbWUgPSAieGVuX3BjcHUiLAorfTsKKworc3RhdGljIERFRklORV9NVVRFWCh4ZW5fcGNwdV9s
b2NrKTsKK3N0YXRpYyBSQVdfTk9USUZJRVJfSEVBRCh4ZW5fcGNwdV9jaGFpbik7CisKKy8qIE5v
IG5lZWQgZm9yIGlycSBkaXNhYmxlIHNpbmNlIGhvdHBsdWcgbm90aWZ5IGlzIGluIHdvcmtxdWV1
ZSBjb250ZXh0ICovCisjZGVmaW5lIGdldF9wY3B1X2xvY2soKSBtdXRleF9sb2NrKCZ4ZW5fcGNw
dV9sb2NrKTsKKyNkZWZpbmUgcHV0X3BjcHVfbG9jaygpIG11dGV4X3VubG9jaygmeGVuX3BjcHVf
bG9jayk7CisKK3N0cnVjdCB4ZW5fcGNwdXMgeworCXN0cnVjdCBsaXN0X2hlYWQgbGlzdDsKKwlp
bnQgcHJlc2VudDsKK307CitzdGF0aWMgc3RydWN0IHhlbl9wY3B1cyB4ZW5fcGNwdXM7CisKK2lu
dCByZWdpc3Rlcl94ZW5fcGNwdV9ub3RpZmllcihzdHJ1Y3Qgbm90aWZpZXJfYmxvY2sgKm5iKQor
eworCWludCByZXQ7CisKKwkvKiBBbGwgcmVmZXIgdG8gdGhlIGNoYWluIG5vdGlmaWVyIGlzIHBy
b3RlY3RlZCBieSB0aGUgcGNwdV9sb2NrICovCisJZ2V0X3BjcHVfbG9jaygpOworCXJldCA9IHJh
d19ub3RpZmllcl9jaGFpbl9yZWdpc3RlcigmeGVuX3BjcHVfY2hhaW4sIG5iKTsKKwlwdXRfcGNw
dV9sb2NrKCk7CisJcmV0dXJuIHJldDsKK30KK0VYUE9SVF9TWU1CT0xfR1BMKHJlZ2lzdGVyX3hl
bl9wY3B1X25vdGlmaWVyKTsKKwordm9pZCB1bnJlZ2lzdGVyX3hlbl9wY3B1X25vdGlmaWVyKHN0
cnVjdCBub3RpZmllcl9ibG9jayAqbmIpCit7CisJZ2V0X3BjcHVfbG9jaygpOworCXJhd19ub3Rp
Zmllcl9jaGFpbl91bnJlZ2lzdGVyKCZ4ZW5fcGNwdV9jaGFpbiwgbmIpOworCXB1dF9wY3B1X2xv
Y2soKTsKK30KK0VYUE9SVF9TWU1CT0xfR1BMKHVucmVnaXN0ZXJfeGVuX3BjcHVfbm90aWZpZXIp
OworCitzdGF0aWMgaW50IHhlbl9wY3B1X2Rvd24odWludDMyX3QgeGVuX2lkKQoreworCWludCBy
ZXQ7CisJeGVuX3BsYXRmb3JtX29wX3Qgb3AgPSB7CisJCS5jbWQJCQk9IFhFTlBGX2NwdV9vZmZs
aW5lLAorCQkuaW50ZXJmYWNlX3ZlcnNpb24JPSBYRU5QRl9JTlRFUkZBQ0VfVkVSU0lPTiwKKwkJ
LnUuY3B1X29sLmNwdWlkCT0geGVuX2lkLAorCX07CisKKwlyZXQgPSBIWVBFUlZJU09SX2RvbTBf
b3AoJm9wKTsKKwlyZXR1cm4gcmV0OworfQorCitzdGF0aWMgaW50IHhlbl9wY3B1X3VwKHVpbnQz
Ml90IHhlbl9pZCkKK3sKKwlpbnQgcmV0OworCXhlbl9wbGF0Zm9ybV9vcF90IG9wID0geworCQku
Y21kCQkJPSBYRU5QRl9jcHVfb25saW5lLAorCQkuaW50ZXJmYWNlX3ZlcnNpb24JPSBYRU5QRl9J
TlRFUkZBQ0VfVkVSU0lPTiwKKwkJLnUuY3B1X29sLmNwdWlkCT0geGVuX2lkLAorCX07CisKKwly
ZXQgPSBIWVBFUlZJU09SX2RvbTBfb3AoJm9wKTsKKwlyZXR1cm4gcmV0OworfQorCitzdGF0aWMg
c3NpemVfdCBzaG93X29ubGluZShzdHJ1Y3Qgc3lzX2RldmljZSAqZGV2LAorCQkJc3RydWN0IHN5
c2Rldl9hdHRyaWJ1dGUgKmF0dHIsCisJCQljaGFyICpidWYpCit7CisJc3RydWN0IHBjcHUgKmNw
dSA9IGNvbnRhaW5lcl9vZihkZXYsIHN0cnVjdCBwY3B1LCBzeXNkZXYpOworCisJcmV0dXJuIHNw
cmludGYoYnVmLCAiJXVcbiIsICEhKGNwdS0+ZmxhZ3MgJiBYRU5fUENQVV9GTEFHU19PTkxJTkUp
KTsKK30KKworc3RhdGljIHNzaXplX3QgX19yZWYgc3RvcmVfb25saW5lKHN0cnVjdCBzeXNfZGV2
aWNlICpkZXYsCisJCQkJICBzdHJ1Y3Qgc3lzZGV2X2F0dHJpYnV0ZSAqYXR0ciwKKwkJCQkgIGNv
bnN0IGNoYXIgKmJ1Ziwgc2l6ZV90IGNvdW50KQoreworCXN0cnVjdCBwY3B1ICpjcHUgPSBjb250
YWluZXJfb2YoZGV2LCBzdHJ1Y3QgcGNwdSwgc3lzZGV2KTsKKwlzc2l6ZV90IHJldDsKKworCXN3
aXRjaCAoYnVmWzBdKSB7CisJY2FzZSAnMCc6CisJCXJldCA9IHhlbl9wY3B1X2Rvd24oY3B1LT54
ZW5faWQpOworCQlicmVhazsKKwljYXNlICcxJzoKKwkJcmV0ID0geGVuX3BjcHVfdXAoY3B1LT54
ZW5faWQpOworCQlicmVhazsKKwlkZWZhdWx0OgorCQlyZXQgPSAtRUlOVkFMOworCX0KKworCWlm
IChyZXQgPj0gMCkKKwkJcmV0ID0gY291bnQ7CisJcmV0dXJuIHJldDsKK30KKworc3RhdGljIFNZ
U0RFVl9BVFRSKG9ubGluZSwgMDY0NCwgc2hvd19vbmxpbmUsIHN0b3JlX29ubGluZSk7CisKK3N0
YXRpYyBzc2l6ZV90IHNob3dfYXBpY2lkKHN0cnVjdCBzeXNfZGV2aWNlICpkZXYsCisJCQlzdHJ1
Y3Qgc3lzZGV2X2F0dHJpYnV0ZSAqYXR0ciwKKwkJCWNoYXIgKmJ1ZikKK3sKKwlzdHJ1Y3QgcGNw
dSAqY3B1ID0gY29udGFpbmVyX29mKGRldiwgc3RydWN0IHBjcHUsIHN5c2Rldik7CisKKwlyZXR1
cm4gc3ByaW50ZihidWYsICIldVxuIiwgY3B1LT5hcGljX2lkKTsKK30KKworc3RhdGljIHNzaXpl
X3Qgc2hvd19hY3BpaWQoc3RydWN0IHN5c19kZXZpY2UgKmRldiwKKwkJCXN0cnVjdCBzeXNkZXZf
YXR0cmlidXRlICphdHRyLAorCQkJY2hhciAqYnVmKQoreworCXN0cnVjdCBwY3B1ICpjcHUgPSBj
b250YWluZXJfb2YoZGV2LCBzdHJ1Y3QgcGNwdSwgc3lzZGV2KTsKKworCXJldHVybiBzcHJpbnRm
KGJ1ZiwgIiV1XG4iLCBjcHUtPmFjcGlfaWQpOworfQorc3RhdGljIFNZU0RFVl9BVFRSKGFwaWNf
aWQsIDA0NDQsIHNob3dfYXBpY2lkLCBOVUxMKTsKK3N0YXRpYyBTWVNERVZfQVRUUihhY3BpX2lk
LCAwNDQ0LCBzaG93X2FjcGlpZCwgTlVMTCk7CisKK3N0YXRpYyBpbnQgeGVuX3BjcHVfZnJlZShz
dHJ1Y3QgcGNwdSAqcGNwdSkKK3sKKwlpZiAoIXBjcHUpCisJCXJldHVybiAwOworCisJc3lzZGV2
X3JlbW92ZV9maWxlKCZwY3B1LT5zeXNkZXYsICZhdHRyX29ubGluZSk7CisJc3lzZGV2X3VucmVn
aXN0ZXIoJnBjcHUtPnN5c2Rldik7CisJbGlzdF9kZWwoJnBjcHUtPnBjcHVfbGlzdCk7CisJa2Zy
ZWUocGNwdSk7CisKKwlyZXR1cm4gMDsKK30KKworc3RhdGljIGlubGluZSBpbnQgc2FtZV9wY3B1
KHN0cnVjdCB4ZW5wZl9wY3B1aW5mbyAqaW5mbywKKwkJCSAgICBzdHJ1Y3QgcGNwdSAqcGNwdSkK
K3sKKwlyZXR1cm4gKHBjcHUtPmFwaWNfaWQgPT0gaW5mby0+YXBpY19pZCkgJiYKKwkJKHBjcHUt
Pnhlbl9pZCA9PSBpbmZvLT54ZW5fY3B1aWQpOworfQorCisvKgorICogUmV0dXJuIDEgaWYgb25s
aW5lIHN0YXR1cyBjaGFuZ2VkCisgKi8KK3N0YXRpYyBpbnQgeGVuX3BjcHVfb25saW5lX2NoZWNr
KHN0cnVjdCB4ZW5wZl9wY3B1aW5mbyAqaW5mbywKKwkJCQkgc3RydWN0IHBjcHUgKnBjcHUpCit7
CisJaW50IHJlc3VsdCA9IDA7CisKKwlpZiAoaW5mby0+eGVuX2NwdWlkICE9IHBjcHUtPnhlbl9p
ZCkKKwkJcmV0dXJuIDA7CisKKwlpZiAoeGVuX3BjcHVfb25saW5lKGluZm8tPmZsYWdzKSAmJiAh
eGVuX3BjcHVfb25saW5lKHBjcHUtPmZsYWdzKSkgeworCQkvKiB0aGUgcGNwdSBpcyBvbmxpbmVk
ICovCisJCXBjcHUtPmZsYWdzIHw9IFhFTl9QQ1BVX0ZMQUdTX09OTElORTsKKwkJa29iamVjdF91
ZXZlbnQoJnBjcHUtPnN5c2Rldi5rb2JqLCBLT0JKX09OTElORSk7CisJCXJhd19ub3RpZmllcl9j
YWxsX2NoYWluKCZ4ZW5fcGNwdV9jaGFpbiwKKwkJCVhFTl9QQ1BVX09OTElORSwgKHZvaWQgKiko
bG9uZylwY3B1LT54ZW5faWQpOworCQlyZXN1bHQgPSAxOworCX0gZWxzZSBpZiAoIXhlbl9wY3B1
X29ubGluZShpbmZvLT5mbGFncykgJiYKKwkJIHhlbl9wY3B1X29ubGluZShwY3B1LT5mbGFncykp
ICB7CisJCS8qIFRoZSBwY3B1IGlzIG9mZmxpbmVkIG5vdyAqLworCQlwY3B1LT5mbGFncyAmPSB+
WEVOX1BDUFVfRkxBR1NfT05MSU5FOworCQlrb2JqZWN0X3VldmVudCgmcGNwdS0+c3lzZGV2Lmtv
YmosIEtPQkpfT0ZGTElORSk7CisJCXJhd19ub3RpZmllcl9jYWxsX2NoYWluKCZ4ZW5fcGNwdV9j
aGFpbiwKKwkJCVhFTl9QQ1BVX09GRkxJTkUsICh2b2lkICopKGxvbmcpcGNwdS0+eGVuX2lkKTsK
KwkJcmVzdWx0ID0gMTsKKwl9CisKKwlyZXR1cm4gcmVzdWx0OworfQorCitzdGF0aWMgaW50IHBj
cHVfc3lzZGV2X2luaXQoc3RydWN0IHBjcHUgKmNwdSkKK3sKKwlpbnQgZXJyb3I7CisKKwllcnJv
ciA9IHN5c2Rldl9yZWdpc3RlcigmY3B1LT5zeXNkZXYpOworCWlmIChlcnJvcikgeworCQlwcmlu
dGsoS0VSTl9XQVJOSU5HICJ4ZW5fcGNwdV9hZGQ6IEZhaWxlZCB0byByZWdpc3RlciBwY3B1XG4i
KTsKKwkJa2ZyZWUoY3B1KTsKKwkJcmV0dXJuIC0xOworCX0KKwlzeXNkZXZfY3JlYXRlX2ZpbGUo
JmNwdS0+c3lzZGV2LCAmYXR0cl9vbmxpbmUpOworCXN5c2Rldl9jcmVhdGVfZmlsZSgmY3B1LT5z
eXNkZXYsICZhdHRyX2FwaWNfaWQpOworCXN5c2Rldl9jcmVhdGVfZmlsZSgmY3B1LT5zeXNkZXYs
ICZhdHRyX2FjcGlfaWQpOworCXJldHVybiAwOworfQorCitzdGF0aWMgc3RydWN0IHBjcHUgKmdl
dF9wY3B1KGludCB4ZW5faWQpCit7CisJc3RydWN0IHBjcHUgKnBjcHUgPSBOVUxMOworCisJbGlz
dF9mb3JfZWFjaF9lbnRyeShwY3B1LCAmeGVuX3BjcHVzLmxpc3QsIHBjcHVfbGlzdCkgeworCQlp
ZiAocGNwdS0+eGVuX2lkID09IHhlbl9pZCkKKwkJCXJldHVybiBwY3B1OworCX0KKwlyZXR1cm4g
TlVMTDsKK30KKworc3RhdGljIHN0cnVjdCBwY3B1ICppbml0X3BjcHUoc3RydWN0IHhlbnBmX3Bj
cHVpbmZvICppbmZvKQoreworCXN0cnVjdCBwY3B1ICpwY3B1OworCisJaWYgKGluZm8tPmZsYWdz
ICYgWEVOX1BDUFVfRkxBR1NfSU5WQUxJRCkKKwkJcmV0dXJuIE5VTEw7CisKKwkvKiBUaGUgUENQ
VSBpcyBqdXN0IGFkZGVkICovCisJcGNwdSA9IGt6YWxsb2Moc2l6ZW9mKHN0cnVjdCBwY3B1KSwg
R0ZQX0tFUk5FTCk7CisJaWYgKCFwY3B1KQorCQlyZXR1cm4gTlVMTDsKKworCUlOSVRfTElTVF9I
RUFEKCZwY3B1LT5wY3B1X2xpc3QpOworCXBjcHUtPnhlbl9pZCA9IGluZm8tPnhlbl9jcHVpZDsK
KwlwY3B1LT5hcGljX2lkID0gaW5mby0+YXBpY19pZDsKKwlwY3B1LT5hY3BpX2lkID0gaW5mby0+
YWNwaV9pZDsKKwlwY3B1LT5mbGFncyA9IGluZm8tPmZsYWdzOworCisJcGNwdS0+c3lzZGV2LmNs
cyA9ICZ4ZW5fcGNwdV9zeXNkZXZfY2xhc3M7CisJcGNwdS0+c3lzZGV2LmlkID0gaW5mby0+eGVu
X2NwdWlkOworCisJaWYgKHBjcHVfc3lzZGV2X2luaXQocGNwdSkpIHsKKwkJa2ZyZWUocGNwdSk7
CisJCXJldHVybiBOVUxMOworCX0KKworCWxpc3RfYWRkX3RhaWwoJnBjcHUtPnBjcHVfbGlzdCwg
Jnhlbl9wY3B1cy5saXN0KTsKKwlyYXdfbm90aWZpZXJfY2FsbF9jaGFpbigmeGVuX3BjcHVfY2hh
aW4sCisJCQkJWEVOX1BDUFVfQURELAorCQkJCSh2b2lkICopKGxvbmcpcGNwdS0+eGVuX2lkKTsK
KwlyZXR1cm4gcGNwdTsKK30KKworI2RlZmluZSBQQ1BVX05PX0NIQU5HRQkJCTAKKyNkZWZpbmUg
UENQVV9BRERFRAkJCTEKKyNkZWZpbmUgUENQVV9PTkxJTkVfT0ZGTElORQkJMgorI2RlZmluZSBQ
Q1BVX1JFTU9WRUQJCQkzCisvKgorICogQ2FsbGVyIHNob3VsZCBob2xkIHRoZSBwY3B1IGxvY2sK
KyAqIDwgMDogU29tZXRoaW5nIHdyb25nCisgKiAwOiBObyBjaGFuZ2VzCisgKiA+IDA6IFN0YXRl
IGNoYW5nZWQKKyAqLworc3RhdGljIHN0cnVjdCBwY3B1ICpfc3luY19wY3B1KGludCBjcHVfbnVt
LCBpbnQgKm1heF9pZCwgaW50ICpyZXN1bHQpCit7CisJc3RydWN0IHBjcHUgKnBjcHUgPSBOVUxM
OworCXN0cnVjdCB4ZW5wZl9wY3B1aW5mbyAqaW5mbzsKKwl4ZW5fcGxhdGZvcm1fb3BfdCBvcCA9
IHsKKwkJLmNtZCAgICAgICAgICAgID0gWEVOUEZfZ2V0X2NwdWluZm8sCisJCS5pbnRlcmZhY2Vf
dmVyc2lvbiAgPSBYRU5QRl9JTlRFUkZBQ0VfVkVSU0lPTiwKKwl9OworCWludCByZXQ7CisKKwkq
cmVzdWx0ID0gLTE7CisKKwlpbmZvID0gJm9wLnUucGNwdV9pbmZvOworCWluZm8tPnhlbl9jcHVp
ZCA9IGNwdV9udW07CisKKwlyZXQgPSBIWVBFUlZJU09SX2RvbTBfb3AoJm9wKTsKKwlpZiAocmV0
KQorCQlyZXR1cm4gTlVMTDsKKworCWlmIChtYXhfaWQpCisJCSptYXhfaWQgPSBvcC51LnBjcHVf
aW5mby5tYXhfcHJlc2VudDsKKworCXBjcHUgPSBnZXRfcGNwdShjcHVfbnVtKTsKKworCWlmIChp
bmZvLT5mbGFncyAmIFhFTl9QQ1BVX0ZMQUdTX0lOVkFMSUQpIHsKKwkJLyogVGhlIHBjcHUgaGFz
IGJlZW4gcmVtb3ZlZCAqLworCQkqcmVzdWx0ID0gUENQVV9OT19DSEFOR0U7CisJCWlmIChwY3B1
KSB7CisJCQlyYXdfbm90aWZpZXJfY2FsbF9jaGFpbigmeGVuX3BjcHVfY2hhaW4sCisJCQkgIFhF
Tl9QQ1BVX1JFTU9WRSwKKwkJCSAgKHZvaWQgKikobG9uZylwY3B1LT54ZW5faWQpOworCQkJeGVu
X3BjcHVfZnJlZShwY3B1KTsKKwkJCSpyZXN1bHQgPSBQQ1BVX1JFTU9WRUQ7CisJCX0KKwkJcmV0
dXJuIE5VTEw7CisJfQorCisKKwlpZiAoIXBjcHUpIHsKKwkJKnJlc3VsdCA9IFBDUFVfQURERUQ7
CisJCXBjcHUgPSBpbml0X3BjcHUoaW5mbyk7CisJCWlmIChwY3B1ID09IE5VTEwpIHsKKwkJCXBy
aW50ayhLRVJOX1dBUk5JTkcgIkZhaWxlZCB0byBpbml0IHBjcHUgJXhcbiIsCisJCQkgIGluZm8t
Pnhlbl9jcHVpZCk7CisJCQkgICpyZXN1bHQgPSAtMTsKKwkJfQorCX0gZWxzZSB7CisJCSpyZXN1
bHQgPSBQQ1BVX05PX0NIQU5HRTsKKwkJLyoKKwkJICogT2xkIFBDUFUgaXMgcmVwbGFjZWQgd2l0
aCBhIG5ldyBwY3B1LCB0aGlzIG1lYW5zCisJCSAqIHNldmVyYWwgdmlycSBpcyBtaXNzZWQsIHdp
bGwgaXQgaGFwcGVuPworCQkgKi8KKwkJaWYgKCFzYW1lX3BjcHUoaW5mbywgcGNwdSkpIHsKKwkJ
CXByaW50ayhLRVJOX1dBUk5JTkcgIlBjcHUgJXggY2hhbmdlZCFcbiIsCisJCQkgIHBjcHUtPnhl
bl9pZCk7CisJCQlwY3B1LT5hcGljX2lkID0gaW5mby0+YXBpY19pZDsKKwkJCXBjcHUtPmFjcGlf
aWQgPSBpbmZvLT5hY3BpX2lkOworCQl9CisJCWlmICh4ZW5fcGNwdV9vbmxpbmVfY2hlY2soaW5m
bywgcGNwdSkpCisJCQkqcmVzdWx0ID0gUENQVV9PTkxJTkVfT0ZGTElORTsKKwl9CisJcmV0dXJu
IHBjcHU7Cit9CisKK2ludCB4ZW5fcGNwdV9pbmRleCh1aW50MzJfdCBpZCwgaW50IGlzX2FjcGlp
ZCkKK3sKKwlpbnQgY3B1X251bSA9IDAsIG1heF9pZCA9IDAsIHJldDsKKwl4ZW5fcGxhdGZvcm1f
b3BfdCBvcCA9IHsKKwkJLmNtZCAgICAgICAgICAgID0gWEVOUEZfZ2V0X2NwdWluZm8sCisJCS5p
bnRlcmZhY2VfdmVyc2lvbiAgPSBYRU5QRl9JTlRFUkZBQ0VfVkVSU0lPTiwKKwl9OworCXN0cnVj
dCB4ZW5wZl9wY3B1aW5mbyAqaW5mbyA9ICZvcC51LnBjcHVfaW5mbzsKKworCWluZm8tPnhlbl9j
cHVpZCA9IDA7CisJcmV0ID0gSFlQRVJWSVNPUl9kb20wX29wKCZvcCk7CisJaWYgKHJldCkKKwkJ
cmV0dXJuIC0xOworCW1heF9pZCA9IG9wLnUucGNwdV9pbmZvLm1heF9wcmVzZW50OworCisJd2hp
bGUgKChjcHVfbnVtIDw9IG1heF9pZCkpIHsKKwkJaW5mby0+eGVuX2NwdWlkID0gY3B1X251bTsK
KwkJcmV0ID0gSFlQRVJWSVNPUl9kb20wX29wKCZvcCk7CisJCWlmIChyZXQpCisJCQljb250aW51
ZTsKKworCQlpZiAob3AudS5wY3B1X2luZm8ubWF4X3ByZXNlbnQgPiBtYXhfaWQpCisJCQltYXhf
aWQgPSBvcC51LnBjcHVfaW5mby5tYXhfcHJlc2VudDsKKwkJaWYgKGlkID09IChpc19hY3BpaWQg
PyBpbmZvLT5hY3BpX2lkIDogaW5mby0+YXBpY19pZCkpCisJCQlyZXR1cm4gY3B1X251bTsKKwkJ
Y3B1X251bSsrOworCX0KKworICAgIHJldHVybiAtMTsKK30KK0VYUE9SVF9TWU1CT0woeGVuX3Bj
cHVfaW5kZXgpOworCisvKgorICogU3luYyBkb20wJ3MgcGNwdSBpbmZvcm1hdGlvbiB3aXRoIHhl
biBoeXBlcnZpc29yJ3MKKyAqLworc3RhdGljIGludCB4ZW5fc3luY19wY3B1cyh2b2lkKQorewor
CS8qCisJICogQm9vdCBjcHUgYWx3YXlzIGhhdmUgY3B1X2lkIDAgaW4geGVuCisJICovCisJaW50
IGNwdV9udW0gPSAwLCBtYXhfaWQgPSAwLCByZXN1bHQgPSAwLCBwcmVzZW50ID0gMDsKKwlzdHJ1
Y3QgbGlzdF9oZWFkICplbGVtLCAqdG1wOworCXN0cnVjdCBwY3B1ICpwY3B1OworCisJZ2V0X3Bj
cHVfbG9jaygpOworCisJd2hpbGUgKChyZXN1bHQgPj0gMCkgJiYgKGNwdV9udW0gPD0gbWF4X2lk
KSkgeworCQlwY3B1ID0gX3N5bmNfcGNwdShjcHVfbnVtLCAmbWF4X2lkLCAmcmVzdWx0KTsKKwor
CQlwcmludGsoS0VSTl9ERUJVRyAic3luYyBjcHUgJXggZ2V0IHJlc3VsdCAleCBtYXhfaWQgJXhc
biIsCisJCQljcHVfbnVtLCByZXN1bHQsIG1heF9pZCk7CisKKwkJc3dpdGNoIChyZXN1bHQpCXsK
KwkJY2FzZSBQQ1BVX05PX0NIQU5HRToKKwkJCWlmIChwY3B1KQorCQkJCXByZXNlbnQrKzsKKwkJ
CWJyZWFrOworCQljYXNlIFBDUFVfQURERUQ6CisJCWNhc2UgUENQVV9PTkxJTkVfT0ZGTElORToK
KwkJCXByZXNlbnQrKzsKKwkJY2FzZSBQQ1BVX1JFTU9WRUQ6CisJCQlicmVhazsKKwkJZGVmYXVs
dDoKKwkJCXByaW50ayhLRVJOX1dBUk5JTkcgIkZhaWxlZCB0byBzeW5jIHBjcHUgJXhcbiIsCisJ
CQkgIGNwdV9udW0pOworCQkJYnJlYWs7CisKKwkJfQorCQljcHVfbnVtKys7CisJfQorCisJaWYg
KHJlc3VsdCA8IDApIHsKKwkJbGlzdF9mb3JfZWFjaF9zYWZlKGVsZW0sIHRtcCwgJnhlbl9wY3B1
cy5saXN0KSB7CisJCQlwY3B1ID0gbGlzdF9lbnRyeShlbGVtLCBzdHJ1Y3QgcGNwdSwgcGNwdV9s
aXN0KTsKKwkJCXhlbl9wY3B1X2ZyZWUocGNwdSk7CisJCX0KKwkJcHJlc2VudCA9IDA7CisJfQor
CisJeGVuX3BjcHVzLnByZXNlbnQgPSBwcmVzZW50OworCisJcHV0X3BjcHVfbG9jaygpOworCisJ
cmV0dXJuIDA7Cit9CisKK3N0YXRpYyB2b2lkIHhlbl9wY3B1X2RwYyhzdHJ1Y3Qgd29ya19zdHJ1
Y3QgKndvcmspCit7CisJaWYgKHhlbl9zeW5jX3BjcHVzKCkgPCAwKQorCQlwcmludGsoS0VSTl9X
QVJOSU5HCisJCQkieGVuX3BjcHVfZHBjOiBGYWlsZWQgdG8gc3luYyBwY3B1IGluZm9ybWF0aW9u
XG4iKTsKK30KK3N0YXRpYyBERUNMQVJFX1dPUksoeGVuX3BjcHVfd29yaywgeGVuX3BjcHVfZHBj
KTsKKworaW50IHhlbl9wY3B1X2hvdHBsdWcoaW50IHR5cGUsIHVpbnQzMl90IGFwaWNfaWQpCit7
CisJc2NoZWR1bGVfd29yaygmeGVuX3BjcHVfd29yayk7CisKKwlyZXR1cm4gMDsKK30KK0VYUE9S
VF9TWU1CT0woeGVuX3BjcHVfaG90cGx1Zyk7CisKK3N0YXRpYyBpcnFyZXR1cm5fdCB4ZW5fcGNw
dV9pbnRlcnJ1cHQoaW50IGlycSwgdm9pZCAqZGV2X2lkKQoreworCXNjaGVkdWxlX3dvcmsoJnhl
bl9wY3B1X3dvcmspOworCXJldHVybiBJUlFfSEFORExFRDsKK30KKworc3RhdGljIGludCBfX2lu
aXQgeGVuX3BjcHVfaW5pdCh2b2lkKQoreworCWludCBlcnI7CisKKwlpZiAoIXhlbl9pbml0aWFs
X2RvbWFpbigpKQorCQlyZXR1cm4gMDsKKworCWVyciA9IHN5c2Rldl9jbGFzc19yZWdpc3Rlcigm
eGVuX3BjcHVfc3lzZGV2X2NsYXNzKTsKKwlpZiAoZXJyKSB7CisJCXByaW50ayhLRVJOX1dBUk5J
TkcKKwkJCSJ4ZW5fcGNwdV9pbml0OiByZWdpc3RlciB4ZW5fcGNwdSBzeXNkZXYgRmFpbGVkIVxu
Iik7CisJCXJldHVybiBlcnI7CisJfQorCisJSU5JVF9MSVNUX0hFQUQoJnhlbl9wY3B1cy5saXN0
KTsKKwl4ZW5fcGNwdXMucHJlc2VudCA9IDA7CisKKwl4ZW5fc3luY19wY3B1cygpOworCWlmICh4
ZW5fcGNwdXMucHJlc2VudCA+IDApCisJCWVyciA9IGJpbmRfdmlycV90b19pcnFoYW5kbGVyKFZJ
UlFfUENQVV9TVEFURSwKKwkJCTAsIHhlbl9wY3B1X2ludGVycnVwdCwgMCwgInBjcHUiLCBOVUxM
KTsKKwlpZiAoZXJyIDwgMCkKKwkJcHJpbnRrKEtFUk5fV0FSTklORyAieGVuX3BjcHVfaW5pdDog
IgorCQkJIkZhaWxlZCB0byBiaW5kIHBjcHVfc3RhdGUgdmlycVxuIgorCQkJIllvdSB3aWxsIGxv
c3QgbGF0ZXN0IGluZm9ybWF0aW9uISBcbiIpOworCXJldHVybiBlcnI7Cit9CisKK2FyY2hfaW5p
dGNhbGwoeGVuX3BjcHVfaW5pdCk7CmRpZmYgLS1naXQgYS9pbmNsdWRlL3hlbi9pbnRlcmZhY2Uv
cGxhdGZvcm0uaCBiL2luY2x1ZGUveGVuL2ludGVyZmFjZS9wbGF0Zm9ybS5oCmluZGV4IGMxNjg0
NjguLjQ3ZmZlMTYgMTAwNjQ0Ci0tLSBhL2luY2x1ZGUveGVuL2ludGVyZmFjZS9wbGF0Zm9ybS5o
CisrKyBiL2luY2x1ZGUveGVuL2ludGVyZmFjZS9wbGF0Zm9ybS5oCkBAIC0yOTcsNiArMjk3LDMx
IEBAIHN0cnVjdCB4ZW5wZl9zZXRfcHJvY2Vzc29yX3BtaW5mbyB7CiB9OwogREVGSU5FX0dVRVNU
X0hBTkRMRV9TVFJVQ1QoeGVucGZfc2V0X3Byb2Nlc3Nvcl9wbWluZm8pOwogCisjZGVmaW5lIFhF
TlBGX2dldF9jcHVpbmZvIDU1CitzdHJ1Y3QgeGVucGZfcGNwdWluZm8geworCS8qIElOICovCisJ
dWludDMyX3QgeGVuX2NwdWlkOworCS8qIE9VVCAqLworCS8qIFRoZSBtYXhpdW0gY3B1X2lkIHRo
YXQgaXMgcHJlc2VudCAqLworCXVpbnQzMl90IG1heF9wcmVzZW50OworI2RlZmluZSBYRU5fUENQ
VV9GTEFHU19PTkxJTkUgICAxCisJLyogQ29ycmVwb25kaW5nIHhlbl9jcHVpZCBpcyBub3QgcHJl
c2VudCovCisjZGVmaW5lIFhFTl9QQ1BVX0ZMQUdTX0lOVkFMSUQgIDIKKwl1aW50MzJfdCBmbGFn
czsKKwl1aW50MzJfdCBhcGljX2lkOworCXVpbnQzMl90IGFjcGlfaWQ7Cit9OwordHlwZWRlZiBz
dHJ1Y3QgeGVucGZfcGNwdWluZm8geGVucGZfcGNwdWluZm9fdDsKK0RFRklORV9HVUVTVF9IQU5E
TEVfU1RSVUNUKHhlbnBmX3BjcHVpbmZvX3QpOworCisjZGVmaW5lIFhFTlBGX2NwdV9vbmxpbmUg
ICAgNTYKKyNkZWZpbmUgWEVOUEZfY3B1X29mZmxpbmUgICA1Nworc3RydWN0IHhlbnBmX2NwdV9v
bCB7CisgICAgdWludDMyX3QgY3B1aWQ7Cit9OwordHlwZWRlZiBzdHJ1Y3QgeGVucGZfY3B1X29s
IHhlbnBmX2NwdV9vbF90OworREVGSU5FX0dVRVNUX0hBTkRMRV9TVFJVQ1QoeGVucGZfY3B1X29s
X3QpOworCiBzdHJ1Y3QgeGVuX3BsYXRmb3JtX29wIHsKIAl1aW50MzJfdCBjbWQ7CiAJdWludDMy
X3QgaW50ZXJmYWNlX3ZlcnNpb247IC8qIFhFTlBGX0lOVEVSRkFDRV9WRVJTSU9OICovCkBAIC0z
MTIsOSArMzM3LDEyIEBAIHN0cnVjdCB4ZW5fcGxhdGZvcm1fb3AgewogCQlzdHJ1Y3QgeGVucGZf
Y2hhbmdlX2ZyZXEgICAgICAgY2hhbmdlX2ZyZXE7CiAJCXN0cnVjdCB4ZW5wZl9nZXRpZGxldGlt
ZSAgICAgICBnZXRpZGxldGltZTsKIAkJc3RydWN0IHhlbnBmX3NldF9wcm9jZXNzb3JfcG1pbmZv
IHNldF9wbWluZm87CisJCXN0cnVjdCB4ZW5wZl9wY3B1aW5mbyAgICAgICAgICBwY3B1X2luZm87
CisJCXN0cnVjdCB4ZW5wZl9jcHVfb2wgICAgICAgICAgICBjcHVfb2w7CiAJCXVpbnQ4X3QgICAg
ICAgICAgICAgICAgICAgICAgICBwYWRbMTI4XTsKIAl9IHU7CiB9OwordHlwZWRlZiBzdHJ1Y3Qg
eGVuX3BsYXRmb3JtX29wIHhlbl9wbGF0Zm9ybV9vcF90OwogREVGSU5FX0dVRVNUX0hBTkRMRV9T
VFJVQ1QoeGVuX3BsYXRmb3JtX29wX3QpOwogCiAjZW5kaWYgLyogX19YRU5fUFVCTElDX1BMQVRG
T1JNX0hfXyAqLwpkaWZmIC0tZ2l0IGEvaW5jbHVkZS94ZW4vaW50ZXJmYWNlL3hlbi5oIGIvaW5j
bHVkZS94ZW4vaW50ZXJmYWNlL3hlbi5oCmluZGV4IDZhNmU5MTQuLjVhOTFjNjYgMTAwNjQ0Ci0t
LSBhL2luY2x1ZGUveGVuL2ludGVyZmFjZS94ZW4uaAorKysgYi9pbmNsdWRlL3hlbi9pbnRlcmZh
Y2UveGVuLmgKQEAgLTgwLDYgKzgwLDcgQEAKICNkZWZpbmUgVklSUV9DT05TT0xFICAgIDIgIC8q
IChET00wKSBCeXRlcyByZWNlaXZlZCBvbiBlbWVyZ2VuY3kgY29uc29sZS4gKi8KICNkZWZpbmUg
VklSUV9ET01fRVhDICAgIDMgIC8qIChET00wKSBFeGNlcHRpb25hbCBldmVudCBmb3Igc29tZSBk
b21haW4uICAgKi8KICNkZWZpbmUgVklSUV9ERUJVR0dFUiAgIDYgIC8qIChET00wKSBBIGRvbWFp
biBoYXMgcGF1c2VkIGZvciBkZWJ1Z2dpbmcuICAgKi8KKyNkZWZpbmUgVklSUV9QQ1BVX1NUQVRF
IDkgIC8qIChET00wKSBQQ1BVIHN0YXRlIGNoYW5nZWQgICAgICAgICAgICAgICAgICAgKi8KIAog
LyogQXJjaGl0ZWN0dXJlLXNwZWNpZmljIFZJUlEgZGVmaW5pdGlvbnMuICovCiAjZGVmaW5lIFZJ
UlFfQVJDSF8wICAgIDE2CmRpZmYgLS1naXQgYS9pbmNsdWRlL3hlbi9wY3B1LmggYi9pbmNsdWRl
L3hlbi9wY3B1LmgKbmV3IGZpbGUgbW9kZSAxMDA2NDQKaW5kZXggMDAwMDAwMC4uN2U4ZjlkMQot
LS0gL2Rldi9udWxsCisrKyBiL2luY2x1ZGUveGVuL3BjcHUuaApAQCAtMCwwICsxLDMyIEBACisj
aWZuZGVmIF9YRU5fUENQVV9ICisjZGVmaW5lIF9YRU5fUENQVV9ICisKKyNpbmNsdWRlIDx4ZW4v
aW50ZXJmYWNlL3BsYXRmb3JtLmg+CisjaW5jbHVkZSA8bGludXgvc3lzZGV2Lmg+CisKK2V4dGVy
biBpbnQgeGVuX3BjcHVfaG90cGx1ZyhpbnQgdHlwZSwgdWludDMyX3QgYXBpY19pZCk7CisjZGVm
aW5lIFhFTl9QQ1BVX09OTElORSAgICAgMHgwMQorI2RlZmluZSBYRU5fUENQVV9PRkZMSU5FICAg
IDB4MDIKKyNkZWZpbmUgWEVOX1BDUFVfQUREICAgICAgICAweDA0CisjZGVmaW5lIFhFTl9QQ1BV
X1JFTU9WRSAgICAgMHgwOAorCitzdHJ1Y3QgcGNwdSB7CisJc3RydWN0IGxpc3RfaGVhZCBwY3B1
X2xpc3Q7CisJc3RydWN0IHN5c19kZXZpY2Ugc3lzZGV2OworCXVpbnQzMl90IHhlbl9pZDsKKwl1
aW50MzJfdCBhcGljX2lkOworCXVpbnQzMl90IGFjcGlfaWQ7CisJdWludDMyX3QgZmxhZ3M7Cit9
OworCitzdGF0aWMgaW5saW5lIGludCB4ZW5fcGNwdV9vbmxpbmUodWludDMyX3QgZmxhZ3MpCit7
CisJcmV0dXJuICEhKGZsYWdzICYgWEVOX1BDUFVfRkxBR1NfT05MSU5FKTsKK30KKworZXh0ZXJu
IGludCByZWdpc3Rlcl94ZW5fcGNwdV9ub3RpZmllcihzdHJ1Y3Qgbm90aWZpZXJfYmxvY2sgKm5i
KTsKKworZXh0ZXJuIHZvaWQgdW5yZWdpc3Rlcl94ZW5fcGNwdV9ub3RpZmllcihzdHJ1Y3Qgbm90
aWZpZXJfYmxvY2sgKm5iKTsKKworZXh0ZXJuIGludCB4ZW5fcGNwdV9pbmRleCh1aW50MzJfdCBh
Y3BpX2lkLCBpbnQgaXNfYWNwaWlkKTsKKyNlbmRpZgotLSAKMS42LjUuNgoK

--_002_DE8DF0795D48FD4CA783C40EC82923358A04SHSMSX101ccrcorpint_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--_002_DE8DF0795D48FD4CA783C40EC82923358A04SHSMSX101ccrcorpint_--


From xen-devel-bounces@lists.xensource.com Thu Dec 22 10:02:42 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 Dec 2011 10:02:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdfTq-0004ZN-D4; Thu, 22 Dec 2011 10:02:30 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1RdfTo-0004YE-DS
	for xen-devel@lists.xensource.com; Thu, 22 Dec 2011 10:02:29 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1324548140!8273319!1
X-Originating-IP: [134.134.136.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjQgPT4gMzE5NDEx\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2563 invoked from network); 22 Dec 2011 10:02:20 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-12.tower-182.messagelabs.com with SMTP;
	22 Dec 2011 10:02:20 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga102.jf.intel.com with ESMTP; 22 Dec 2011 02:02:19 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.67,352,1309762800"; d="scan'208,223";a="89280015"
Received: from pgsmsx602.gar.corp.intel.com ([10.221.43.81])
	by orsmga001.jf.intel.com with ESMTP; 22 Dec 2011 02:02:18 -0800
Received: from pgsmsx104.gar.corp.intel.com (10.221.44.91) by
	pgsmsx602.gar.corp.intel.com (10.221.43.81) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Thu, 22 Dec 2011 18:02:17 +0800
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	PGSMSX104.gar.corp.intel.com (10.221.44.91) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Thu, 22 Dec 2011 18:02:16 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.38]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.199]) with mapi id
	14.01.0355.002; Thu, 22 Dec 2011 18:02:15 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: "konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Thread-Topic: [PATCH 03/10] Xen: Export host physical CPU information to dom0
Thread-Index: AczAkMeDvnoI6swkT+qbS+vbRI9caA==
Date: Thu, 22 Dec 2011 10:02:14 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC82923358A04@SHSMSX101.ccr.corp.intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
Content-Type: multipart/mixed;
	boundary="_002_DE8DF0795D48FD4CA783C40EC82923358A04SHSMSX101ccrcorpint_"
MIME-Version: 1.0
Cc: "Jiang, Yunhong" <yunhong.jiang@intel.com>,
	"jeremy.fitzhardinge@citrix.com" <jeremy.fitzhardinge@citrix.com>
Subject: [Xen-devel] [PATCH 03/10] Xen: Export host physical CPU information
	to dom0
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--_002_DE8DF0795D48FD4CA783C40EC82923358A04SHSMSX101ccrcorpint_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

>From 04151aa18b48a452cc9d0696f36aa96c690ca011 Mon Sep 17 00:00:00 2001
From: Liu Jinsong <jinsong.liu@intel.com>
Date: Thu, 8 Dec 2011 22:28:07 +0800
Subject: [PATCH 03/10] Xen: Export host physical CPU information to dom0

This patch rebased from Jeremy's pvops commit
3b34cd19627c6e191b15fd6cb59f997b8db21e19 and
68320323a51c2378aca433c76157d9e66104ff1e

This patch expose host's physical CPU information to dom0 in sysfs, so
that dom0's management tools can control the physical CPU if needed.

It also provides interface in sysfs to logical online/offline a physical CP=
U.

Notice: The information in dom0 is synced with xen hypervisor asynchronousl=
y.

Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
Signed-off-by: Jiang, Yunhong <yunhong.jiang@intel.com>
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
---
 drivers/xen/Makefile             |    2 +-
 drivers/xen/pcpu.c               |  452 ++++++++++++++++++++++++++++++++++=
++++
 include/xen/interface/platform.h |   28 +++
 include/xen/interface/xen.h      |    1 +
 include/xen/pcpu.h               |   32 +++
 5 files changed, 514 insertions(+), 1 deletions(-)
 create mode 100644 drivers/xen/pcpu.c
 create mode 100644 include/xen/pcpu.h

diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
index 405cce9..aedaf48 100644
--- a/drivers/xen/Makefile
+++ b/drivers/xen/Makefile
@@ -1,4 +1,4 @@
-obj-y	+=3D grant-table.o features.o events.o manage.o balloon.o
+obj-y	+=3D grant-table.o features.o events.o manage.o balloon.o pcpu.o
 obj-y	+=3D xenbus/
=20
 nostackp :=3D $(call cc-option, -fno-stack-protector)
diff --git a/drivers/xen/pcpu.c b/drivers/xen/pcpu.c
new file mode 100644
index 0000000..6d1a770
--- /dev/null
+++ b/drivers/xen/pcpu.c
@@ -0,0 +1,452 @@
+/*
+ * pcpu.c - management physical cpu in dom0 environment
+ */
+#include <linux/interrupt.h>
+#include <linux/spinlock.h>
+#include <asm/xen/hypervisor.h>
+#include <asm/xen/hypercall.h>
+#include <linux/cpu.h>
+#include <xen/xenbus.h>
+#include <xen/pcpu.h>
+#include <xen/events.h>
+#include <xen/acpi.h>
+
+static struct sysdev_class xen_pcpu_sysdev_class =3D {
+	.name =3D "xen_pcpu",
+};
+
+static DEFINE_MUTEX(xen_pcpu_lock);
+static RAW_NOTIFIER_HEAD(xen_pcpu_chain);
+
+/* No need for irq disable since hotplug notify is in workqueue context */
+#define get_pcpu_lock() mutex_lock(&xen_pcpu_lock);
+#define put_pcpu_lock() mutex_unlock(&xen_pcpu_lock);
+
+struct xen_pcpus {
+	struct list_head list;
+	int present;
+};
+static struct xen_pcpus xen_pcpus;
+
+int register_xen_pcpu_notifier(struct notifier_block *nb)
+{
+	int ret;
+
+	/* All refer to the chain notifier is protected by the pcpu_lock */
+	get_pcpu_lock();
+	ret =3D raw_notifier_chain_register(&xen_pcpu_chain, nb);
+	put_pcpu_lock();
+	return ret;
+}
+EXPORT_SYMBOL_GPL(register_xen_pcpu_notifier);
+
+void unregister_xen_pcpu_notifier(struct notifier_block *nb)
+{
+	get_pcpu_lock();
+	raw_notifier_chain_unregister(&xen_pcpu_chain, nb);
+	put_pcpu_lock();
+}
+EXPORT_SYMBOL_GPL(unregister_xen_pcpu_notifier);
+
+static int xen_pcpu_down(uint32_t xen_id)
+{
+	int ret;
+	xen_platform_op_t op =3D {
+		.cmd			=3D XENPF_cpu_offline,
+		.interface_version	=3D XENPF_INTERFACE_VERSION,
+		.u.cpu_ol.cpuid	=3D xen_id,
+	};
+
+	ret =3D HYPERVISOR_dom0_op(&op);
+	return ret;
+}
+
+static int xen_pcpu_up(uint32_t xen_id)
+{
+	int ret;
+	xen_platform_op_t op =3D {
+		.cmd			=3D XENPF_cpu_online,
+		.interface_version	=3D XENPF_INTERFACE_VERSION,
+		.u.cpu_ol.cpuid	=3D xen_id,
+	};
+
+	ret =3D HYPERVISOR_dom0_op(&op);
+	return ret;
+}
+
+static ssize_t show_online(struct sys_device *dev,
+			struct sysdev_attribute *attr,
+			char *buf)
+{
+	struct pcpu *cpu =3D container_of(dev, struct pcpu, sysdev);
+
+	return sprintf(buf, "%u\n", !!(cpu->flags & XEN_PCPU_FLAGS_ONLINE));
+}
+
+static ssize_t __ref store_online(struct sys_device *dev,
+				  struct sysdev_attribute *attr,
+				  const char *buf, size_t count)
+{
+	struct pcpu *cpu =3D container_of(dev, struct pcpu, sysdev);
+	ssize_t ret;
+
+	switch (buf[0]) {
+	case '0':
+		ret =3D xen_pcpu_down(cpu->xen_id);
+		break;
+	case '1':
+		ret =3D xen_pcpu_up(cpu->xen_id);
+		break;
+	default:
+		ret =3D -EINVAL;
+	}
+
+	if (ret >=3D 0)
+		ret =3D count;
+	return ret;
+}
+
+static SYSDEV_ATTR(online, 0644, show_online, store_online);
+
+static ssize_t show_apicid(struct sys_device *dev,
+			struct sysdev_attribute *attr,
+			char *buf)
+{
+	struct pcpu *cpu =3D container_of(dev, struct pcpu, sysdev);
+
+	return sprintf(buf, "%u\n", cpu->apic_id);
+}
+
+static ssize_t show_acpiid(struct sys_device *dev,
+			struct sysdev_attribute *attr,
+			char *buf)
+{
+	struct pcpu *cpu =3D container_of(dev, struct pcpu, sysdev);
+
+	return sprintf(buf, "%u\n", cpu->acpi_id);
+}
+static SYSDEV_ATTR(apic_id, 0444, show_apicid, NULL);
+static SYSDEV_ATTR(acpi_id, 0444, show_acpiid, NULL);
+
+static int xen_pcpu_free(struct pcpu *pcpu)
+{
+	if (!pcpu)
+		return 0;
+
+	sysdev_remove_file(&pcpu->sysdev, &attr_online);
+	sysdev_unregister(&pcpu->sysdev);
+	list_del(&pcpu->pcpu_list);
+	kfree(pcpu);
+
+	return 0;
+}
+
+static inline int same_pcpu(struct xenpf_pcpuinfo *info,
+			    struct pcpu *pcpu)
+{
+	return (pcpu->apic_id =3D=3D info->apic_id) &&
+		(pcpu->xen_id =3D=3D info->xen_cpuid);
+}
+
+/*
+ * Return 1 if online status changed
+ */
+static int xen_pcpu_online_check(struct xenpf_pcpuinfo *info,
+				 struct pcpu *pcpu)
+{
+	int result =3D 0;
+
+	if (info->xen_cpuid !=3D pcpu->xen_id)
+		return 0;
+
+	if (xen_pcpu_online(info->flags) && !xen_pcpu_online(pcpu->flags)) {
+		/* the pcpu is onlined */
+		pcpu->flags |=3D XEN_PCPU_FLAGS_ONLINE;
+		kobject_uevent(&pcpu->sysdev.kobj, KOBJ_ONLINE);
+		raw_notifier_call_chain(&xen_pcpu_chain,
+			XEN_PCPU_ONLINE, (void *)(long)pcpu->xen_id);
+		result =3D 1;
+	} else if (!xen_pcpu_online(info->flags) &&
+		 xen_pcpu_online(pcpu->flags))  {
+		/* The pcpu is offlined now */
+		pcpu->flags &=3D ~XEN_PCPU_FLAGS_ONLINE;
+		kobject_uevent(&pcpu->sysdev.kobj, KOBJ_OFFLINE);
+		raw_notifier_call_chain(&xen_pcpu_chain,
+			XEN_PCPU_OFFLINE, (void *)(long)pcpu->xen_id);
+		result =3D 1;
+	}
+
+	return result;
+}
+
+static int pcpu_sysdev_init(struct pcpu *cpu)
+{
+	int error;
+
+	error =3D sysdev_register(&cpu->sysdev);
+	if (error) {
+		printk(KERN_WARNING "xen_pcpu_add: Failed to register pcpu\n");
+		kfree(cpu);
+		return -1;
+	}
+	sysdev_create_file(&cpu->sysdev, &attr_online);
+	sysdev_create_file(&cpu->sysdev, &attr_apic_id);
+	sysdev_create_file(&cpu->sysdev, &attr_acpi_id);
+	return 0;
+}
+
+static struct pcpu *get_pcpu(int xen_id)
+{
+	struct pcpu *pcpu =3D NULL;
+
+	list_for_each_entry(pcpu, &xen_pcpus.list, pcpu_list) {
+		if (pcpu->xen_id =3D=3D xen_id)
+			return pcpu;
+	}
+	return NULL;
+}
+
+static struct pcpu *init_pcpu(struct xenpf_pcpuinfo *info)
+{
+	struct pcpu *pcpu;
+
+	if (info->flags & XEN_PCPU_FLAGS_INVALID)
+		return NULL;
+
+	/* The PCPU is just added */
+	pcpu =3D kzalloc(sizeof(struct pcpu), GFP_KERNEL);
+	if (!pcpu)
+		return NULL;
+
+	INIT_LIST_HEAD(&pcpu->pcpu_list);
+	pcpu->xen_id =3D info->xen_cpuid;
+	pcpu->apic_id =3D info->apic_id;
+	pcpu->acpi_id =3D info->acpi_id;
+	pcpu->flags =3D info->flags;
+
+	pcpu->sysdev.cls =3D &xen_pcpu_sysdev_class;
+	pcpu->sysdev.id =3D info->xen_cpuid;
+
+	if (pcpu_sysdev_init(pcpu)) {
+		kfree(pcpu);
+		return NULL;
+	}
+
+	list_add_tail(&pcpu->pcpu_list, &xen_pcpus.list);
+	raw_notifier_call_chain(&xen_pcpu_chain,
+				XEN_PCPU_ADD,
+				(void *)(long)pcpu->xen_id);
+	return pcpu;
+}
+
+#define PCPU_NO_CHANGE			0
+#define PCPU_ADDED			1
+#define PCPU_ONLINE_OFFLINE		2
+#define PCPU_REMOVED			3
+/*
+ * Caller should hold the pcpu lock
+ * < 0: Something wrong
+ * 0: No changes
+ * > 0: State changed
+ */
+static struct pcpu *_sync_pcpu(int cpu_num, int *max_id, int *result)
+{
+	struct pcpu *pcpu =3D NULL;
+	struct xenpf_pcpuinfo *info;
+	xen_platform_op_t op =3D {
+		.cmd            =3D XENPF_get_cpuinfo,
+		.interface_version  =3D XENPF_INTERFACE_VERSION,
+	};
+	int ret;
+
+	*result =3D -1;
+
+	info =3D &op.u.pcpu_info;
+	info->xen_cpuid =3D cpu_num;
+
+	ret =3D HYPERVISOR_dom0_op(&op);
+	if (ret)
+		return NULL;
+
+	if (max_id)
+		*max_id =3D op.u.pcpu_info.max_present;
+
+	pcpu =3D get_pcpu(cpu_num);
+
+	if (info->flags & XEN_PCPU_FLAGS_INVALID) {
+		/* The pcpu has been removed */
+		*result =3D PCPU_NO_CHANGE;
+		if (pcpu) {
+			raw_notifier_call_chain(&xen_pcpu_chain,
+			  XEN_PCPU_REMOVE,
+			  (void *)(long)pcpu->xen_id);
+			xen_pcpu_free(pcpu);
+			*result =3D PCPU_REMOVED;
+		}
+		return NULL;
+	}
+
+
+	if (!pcpu) {
+		*result =3D PCPU_ADDED;
+		pcpu =3D init_pcpu(info);
+		if (pcpu =3D=3D NULL) {
+			printk(KERN_WARNING "Failed to init pcpu %x\n",
+			  info->xen_cpuid);
+			  *result =3D -1;
+		}
+	} else {
+		*result =3D PCPU_NO_CHANGE;
+		/*
+		 * Old PCPU is replaced with a new pcpu, this means
+		 * several virq is missed, will it happen?
+		 */
+		if (!same_pcpu(info, pcpu)) {
+			printk(KERN_WARNING "Pcpu %x changed!\n",
+			  pcpu->xen_id);
+			pcpu->apic_id =3D info->apic_id;
+			pcpu->acpi_id =3D info->acpi_id;
+		}
+		if (xen_pcpu_online_check(info, pcpu))
+			*result =3D PCPU_ONLINE_OFFLINE;
+	}
+	return pcpu;
+}
+
+int xen_pcpu_index(uint32_t id, int is_acpiid)
+{
+	int cpu_num =3D 0, max_id =3D 0, ret;
+	xen_platform_op_t op =3D {
+		.cmd            =3D XENPF_get_cpuinfo,
+		.interface_version  =3D XENPF_INTERFACE_VERSION,
+	};
+	struct xenpf_pcpuinfo *info =3D &op.u.pcpu_info;
+
+	info->xen_cpuid =3D 0;
+	ret =3D HYPERVISOR_dom0_op(&op);
+	if (ret)
+		return -1;
+	max_id =3D op.u.pcpu_info.max_present;
+
+	while ((cpu_num <=3D max_id)) {
+		info->xen_cpuid =3D cpu_num;
+		ret =3D HYPERVISOR_dom0_op(&op);
+		if (ret)
+			continue;
+
+		if (op.u.pcpu_info.max_present > max_id)
+			max_id =3D op.u.pcpu_info.max_present;
+		if (id =3D=3D (is_acpiid ? info->acpi_id : info->apic_id))
+			return cpu_num;
+		cpu_num++;
+	}
+
+    return -1;
+}
+EXPORT_SYMBOL(xen_pcpu_index);
+
+/*
+ * Sync dom0's pcpu information with xen hypervisor's
+ */
+static int xen_sync_pcpus(void)
+{
+	/*
+	 * Boot cpu always have cpu_id 0 in xen
+	 */
+	int cpu_num =3D 0, max_id =3D 0, result =3D 0, present =3D 0;
+	struct list_head *elem, *tmp;
+	struct pcpu *pcpu;
+
+	get_pcpu_lock();
+
+	while ((result >=3D 0) && (cpu_num <=3D max_id)) {
+		pcpu =3D _sync_pcpu(cpu_num, &max_id, &result);
+
+		printk(KERN_DEBUG "sync cpu %x get result %x max_id %x\n",
+			cpu_num, result, max_id);
+
+		switch (result)	{
+		case PCPU_NO_CHANGE:
+			if (pcpu)
+				present++;
+			break;
+		case PCPU_ADDED:
+		case PCPU_ONLINE_OFFLINE:
+			present++;
+		case PCPU_REMOVED:
+			break;
+		default:
+			printk(KERN_WARNING "Failed to sync pcpu %x\n",
+			  cpu_num);
+			break;
+
+		}
+		cpu_num++;
+	}
+
+	if (result < 0) {
+		list_for_each_safe(elem, tmp, &xen_pcpus.list) {
+			pcpu =3D list_entry(elem, struct pcpu, pcpu_list);
+			xen_pcpu_free(pcpu);
+		}
+		present =3D 0;
+	}
+
+	xen_pcpus.present =3D present;
+
+	put_pcpu_lock();
+
+	return 0;
+}
+
+static void xen_pcpu_dpc(struct work_struct *work)
+{
+	if (xen_sync_pcpus() < 0)
+		printk(KERN_WARNING
+			"xen_pcpu_dpc: Failed to sync pcpu information\n");
+}
+static DECLARE_WORK(xen_pcpu_work, xen_pcpu_dpc);
+
+int xen_pcpu_hotplug(int type, uint32_t apic_id)
+{
+	schedule_work(&xen_pcpu_work);
+
+	return 0;
+}
+EXPORT_SYMBOL(xen_pcpu_hotplug);
+
+static irqreturn_t xen_pcpu_interrupt(int irq, void *dev_id)
+{
+	schedule_work(&xen_pcpu_work);
+	return IRQ_HANDLED;
+}
+
+static int __init xen_pcpu_init(void)
+{
+	int err;
+
+	if (!xen_initial_domain())
+		return 0;
+
+	err =3D sysdev_class_register(&xen_pcpu_sysdev_class);
+	if (err) {
+		printk(KERN_WARNING
+			"xen_pcpu_init: register xen_pcpu sysdev Failed!\n");
+		return err;
+	}
+
+	INIT_LIST_HEAD(&xen_pcpus.list);
+	xen_pcpus.present =3D 0;
+
+	xen_sync_pcpus();
+	if (xen_pcpus.present > 0)
+		err =3D bind_virq_to_irqhandler(VIRQ_PCPU_STATE,
+			0, xen_pcpu_interrupt, 0, "pcpu", NULL);
+	if (err < 0)
+		printk(KERN_WARNING "xen_pcpu_init: "
+			"Failed to bind pcpu_state virq\n"
+			"You will lost latest information! \n");
+	return err;
+}
+
+arch_initcall(xen_pcpu_init);
diff --git a/include/xen/interface/platform.h b/include/xen/interface/platf=
orm.h
index c168468..47ffe16 100644
--- a/include/xen/interface/platform.h
+++ b/include/xen/interface/platform.h
@@ -297,6 +297,31 @@ struct xenpf_set_processor_pminfo {
 };
 DEFINE_GUEST_HANDLE_STRUCT(xenpf_set_processor_pminfo);
=20
+#define XENPF_get_cpuinfo 55
+struct xenpf_pcpuinfo {
+	/* IN */
+	uint32_t xen_cpuid;
+	/* OUT */
+	/* The maxium cpu_id that is present */
+	uint32_t max_present;
+#define XEN_PCPU_FLAGS_ONLINE   1
+	/* Correponding xen_cpuid is not present*/
+#define XEN_PCPU_FLAGS_INVALID  2
+	uint32_t flags;
+	uint32_t apic_id;
+	uint32_t acpi_id;
+};
+typedef struct xenpf_pcpuinfo xenpf_pcpuinfo_t;
+DEFINE_GUEST_HANDLE_STRUCT(xenpf_pcpuinfo_t);
+
+#define XENPF_cpu_online    56
+#define XENPF_cpu_offline   57
+struct xenpf_cpu_ol {
+    uint32_t cpuid;
+};
+typedef struct xenpf_cpu_ol xenpf_cpu_ol_t;
+DEFINE_GUEST_HANDLE_STRUCT(xenpf_cpu_ol_t);
+
 struct xen_platform_op {
 	uint32_t cmd;
 	uint32_t interface_version; /* XENPF_INTERFACE_VERSION */
@@ -312,9 +337,12 @@ struct xen_platform_op {
 		struct xenpf_change_freq       change_freq;
 		struct xenpf_getidletime       getidletime;
 		struct xenpf_set_processor_pminfo set_pminfo;
+		struct xenpf_pcpuinfo          pcpu_info;
+		struct xenpf_cpu_ol            cpu_ol;
 		uint8_t                        pad[128];
 	} u;
 };
+typedef struct xen_platform_op xen_platform_op_t;
 DEFINE_GUEST_HANDLE_STRUCT(xen_platform_op_t);
=20
 #endif /* __XEN_PUBLIC_PLATFORM_H__ */
diff --git a/include/xen/interface/xen.h b/include/xen/interface/xen.h
index 6a6e914..5a91c66 100644
--- a/include/xen/interface/xen.h
+++ b/include/xen/interface/xen.h
@@ -80,6 +80,7 @@
 #define VIRQ_CONSOLE    2  /* (DOM0) Bytes received on emergency console. =
*/
 #define VIRQ_DOM_EXC    3  /* (DOM0) Exceptional event for some domain.   =
*/
 #define VIRQ_DEBUGGER   6  /* (DOM0) A domain has paused for debugging.   =
*/
+#define VIRQ_PCPU_STATE 9  /* (DOM0) PCPU state changed                   =
*/
=20
 /* Architecture-specific VIRQ definitions. */
 #define VIRQ_ARCH_0    16
diff --git a/include/xen/pcpu.h b/include/xen/pcpu.h
new file mode 100644
index 0000000..7e8f9d1
--- /dev/null
+++ b/include/xen/pcpu.h
@@ -0,0 +1,32 @@
+#ifndef _XEN_PCPU_H
+#define _XEN_PCPU_H
+
+#include <xen/interface/platform.h>
+#include <linux/sysdev.h>
+
+extern int xen_pcpu_hotplug(int type, uint32_t apic_id);
+#define XEN_PCPU_ONLINE     0x01
+#define XEN_PCPU_OFFLINE    0x02
+#define XEN_PCPU_ADD        0x04
+#define XEN_PCPU_REMOVE     0x08
+
+struct pcpu {
+	struct list_head pcpu_list;
+	struct sys_device sysdev;
+	uint32_t xen_id;
+	uint32_t apic_id;
+	uint32_t acpi_id;
+	uint32_t flags;
+};
+
+static inline int xen_pcpu_online(uint32_t flags)
+{
+	return !!(flags & XEN_PCPU_FLAGS_ONLINE);
+}
+
+extern int register_xen_pcpu_notifier(struct notifier_block *nb);
+
+extern void unregister_xen_pcpu_notifier(struct notifier_block *nb);
+
+extern int xen_pcpu_index(uint32_t acpi_id, int is_acpiid);
+#endif
--=20
1.6.5.6

--_002_DE8DF0795D48FD4CA783C40EC82923358A04SHSMSX101ccrcorpint_
Content-Type: application/octet-stream;
	name="0003-Xen-Export-host-physical-CPU-information-to-dom0.patch"
Content-Description: 0003-Xen-Export-host-physical-CPU-information-to-dom0.patch
Content-Disposition: attachment;
	filename="0003-Xen-Export-host-physical-CPU-information-to-dom0.patch";
	size=15036; creation-date="Wed, 14 Dec 2011 15:20:15 GMT";
	modification-date="Wed, 14 Dec 2011 15:03:34 GMT"
Content-Transfer-Encoding: base64

RnJvbSAwNDE1MWFhMThiNDhhNDUyY2M5ZDA2OTZmMzZhYTk2YzY5MGNhMDExIE1vbiBTZXAgMTcg
MDA6MDA6MDAgMjAwMQpGcm9tOiBMaXUgSmluc29uZyA8amluc29uZy5saXVAaW50ZWwuY29tPgpE
YXRlOiBUaHUsIDggRGVjIDIwMTEgMjI6Mjg6MDcgKzA4MDAKU3ViamVjdDogW1BBVENIIDAzLzEw
XSBYZW46IEV4cG9ydCBob3N0IHBoeXNpY2FsIENQVSBpbmZvcm1hdGlvbiB0byBkb20wCgpUaGlz
IHBhdGNoIHJlYmFzZWQgZnJvbSBKZXJlbXkncyBwdm9wcyBjb21taXQKM2IzNGNkMTk2MjdjNmUx
OTFiMTVmZDZjYjU5Zjk5N2I4ZGIyMWUxOSBhbmQKNjgzMjAzMjNhNTFjMjM3OGFjYTQzM2M3NjE1
N2Q5ZTY2MTA0ZmYxZQoKVGhpcyBwYXRjaCBleHBvc2UgaG9zdCdzIHBoeXNpY2FsIENQVSBpbmZv
cm1hdGlvbiB0byBkb20wIGluIHN5c2ZzLCBzbwp0aGF0IGRvbTAncyBtYW5hZ2VtZW50IHRvb2xz
IGNhbiBjb250cm9sIHRoZSBwaHlzaWNhbCBDUFUgaWYgbmVlZGVkLgoKSXQgYWxzbyBwcm92aWRl
cyBpbnRlcmZhY2UgaW4gc3lzZnMgdG8gbG9naWNhbCBvbmxpbmUvb2ZmbGluZSBhIHBoeXNpY2Fs
IENQVS4KCk5vdGljZTogVGhlIGluZm9ybWF0aW9uIGluIGRvbTAgaXMgc3luY2VkIHdpdGggeGVu
IGh5cGVydmlzb3IgYXN5bmNocm9ub3VzbHkuCgpTaWduZWQtb2ZmLWJ5OiBMaXUsIEppbnNvbmcg
PGppbnNvbmcubGl1QGludGVsLmNvbT4KU2lnbmVkLW9mZi1ieTogSmlhbmcsIFl1bmhvbmcgPHl1
bmhvbmcuamlhbmdAaW50ZWwuY29tPgpTaWduZWQtb2ZmLWJ5OiBKZXJlbXkgRml0emhhcmRpbmdl
IDxqZXJlbXkuZml0emhhcmRpbmdlQGNpdHJpeC5jb20+Ci0tLQogZHJpdmVycy94ZW4vTWFrZWZp
bGUgICAgICAgICAgICAgfCAgICAyICstCiBkcml2ZXJzL3hlbi9wY3B1LmMgICAgICAgICAgICAg
ICB8ICA0NTIgKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysKIGluY2x1ZGUv
eGVuL2ludGVyZmFjZS9wbGF0Zm9ybS5oIHwgICAyOCArKysKIGluY2x1ZGUveGVuL2ludGVyZmFj
ZS94ZW4uaCAgICAgIHwgICAgMSArCiBpbmNsdWRlL3hlbi9wY3B1LmggICAgICAgICAgICAgICB8
ICAgMzIgKysrCiA1IGZpbGVzIGNoYW5nZWQsIDUxNCBpbnNlcnRpb25zKCspLCAxIGRlbGV0aW9u
cygtKQogY3JlYXRlIG1vZGUgMTAwNjQ0IGRyaXZlcnMveGVuL3BjcHUuYwogY3JlYXRlIG1vZGUg
MTAwNjQ0IGluY2x1ZGUveGVuL3BjcHUuaAoKZGlmZiAtLWdpdCBhL2RyaXZlcnMveGVuL01ha2Vm
aWxlIGIvZHJpdmVycy94ZW4vTWFrZWZpbGUKaW5kZXggNDA1Y2NlOS4uYWVkYWY0OCAxMDA2NDQK
LS0tIGEvZHJpdmVycy94ZW4vTWFrZWZpbGUKKysrIGIvZHJpdmVycy94ZW4vTWFrZWZpbGUKQEAg
LTEsNCArMSw0IEBACi1vYmoteQkrPSBncmFudC10YWJsZS5vIGZlYXR1cmVzLm8gZXZlbnRzLm8g
bWFuYWdlLm8gYmFsbG9vbi5vCitvYmoteQkrPSBncmFudC10YWJsZS5vIGZlYXR1cmVzLm8gZXZl
bnRzLm8gbWFuYWdlLm8gYmFsbG9vbi5vIHBjcHUubwogb2JqLXkJKz0geGVuYnVzLwogCiBub3N0
YWNrcCA6PSAkKGNhbGwgY2Mtb3B0aW9uLCAtZm5vLXN0YWNrLXByb3RlY3RvcikKZGlmZiAtLWdp
dCBhL2RyaXZlcnMveGVuL3BjcHUuYyBiL2RyaXZlcnMveGVuL3BjcHUuYwpuZXcgZmlsZSBtb2Rl
IDEwMDY0NAppbmRleCAwMDAwMDAwLi42ZDFhNzcwCi0tLSAvZGV2L251bGwKKysrIGIvZHJpdmVy
cy94ZW4vcGNwdS5jCkBAIC0wLDAgKzEsNDUyIEBACisvKgorICogcGNwdS5jIC0gbWFuYWdlbWVu
dCBwaHlzaWNhbCBjcHUgaW4gZG9tMCBlbnZpcm9ubWVudAorICovCisjaW5jbHVkZSA8bGludXgv
aW50ZXJydXB0Lmg+CisjaW5jbHVkZSA8bGludXgvc3BpbmxvY2suaD4KKyNpbmNsdWRlIDxhc20v
eGVuL2h5cGVydmlzb3IuaD4KKyNpbmNsdWRlIDxhc20veGVuL2h5cGVyY2FsbC5oPgorI2luY2x1
ZGUgPGxpbnV4L2NwdS5oPgorI2luY2x1ZGUgPHhlbi94ZW5idXMuaD4KKyNpbmNsdWRlIDx4ZW4v
cGNwdS5oPgorI2luY2x1ZGUgPHhlbi9ldmVudHMuaD4KKyNpbmNsdWRlIDx4ZW4vYWNwaS5oPgor
CitzdGF0aWMgc3RydWN0IHN5c2Rldl9jbGFzcyB4ZW5fcGNwdV9zeXNkZXZfY2xhc3MgPSB7CisJ
Lm5hbWUgPSAieGVuX3BjcHUiLAorfTsKKworc3RhdGljIERFRklORV9NVVRFWCh4ZW5fcGNwdV9s
b2NrKTsKK3N0YXRpYyBSQVdfTk9USUZJRVJfSEVBRCh4ZW5fcGNwdV9jaGFpbik7CisKKy8qIE5v
IG5lZWQgZm9yIGlycSBkaXNhYmxlIHNpbmNlIGhvdHBsdWcgbm90aWZ5IGlzIGluIHdvcmtxdWV1
ZSBjb250ZXh0ICovCisjZGVmaW5lIGdldF9wY3B1X2xvY2soKSBtdXRleF9sb2NrKCZ4ZW5fcGNw
dV9sb2NrKTsKKyNkZWZpbmUgcHV0X3BjcHVfbG9jaygpIG11dGV4X3VubG9jaygmeGVuX3BjcHVf
bG9jayk7CisKK3N0cnVjdCB4ZW5fcGNwdXMgeworCXN0cnVjdCBsaXN0X2hlYWQgbGlzdDsKKwlp
bnQgcHJlc2VudDsKK307CitzdGF0aWMgc3RydWN0IHhlbl9wY3B1cyB4ZW5fcGNwdXM7CisKK2lu
dCByZWdpc3Rlcl94ZW5fcGNwdV9ub3RpZmllcihzdHJ1Y3Qgbm90aWZpZXJfYmxvY2sgKm5iKQor
eworCWludCByZXQ7CisKKwkvKiBBbGwgcmVmZXIgdG8gdGhlIGNoYWluIG5vdGlmaWVyIGlzIHBy
b3RlY3RlZCBieSB0aGUgcGNwdV9sb2NrICovCisJZ2V0X3BjcHVfbG9jaygpOworCXJldCA9IHJh
d19ub3RpZmllcl9jaGFpbl9yZWdpc3RlcigmeGVuX3BjcHVfY2hhaW4sIG5iKTsKKwlwdXRfcGNw
dV9sb2NrKCk7CisJcmV0dXJuIHJldDsKK30KK0VYUE9SVF9TWU1CT0xfR1BMKHJlZ2lzdGVyX3hl
bl9wY3B1X25vdGlmaWVyKTsKKwordm9pZCB1bnJlZ2lzdGVyX3hlbl9wY3B1X25vdGlmaWVyKHN0
cnVjdCBub3RpZmllcl9ibG9jayAqbmIpCit7CisJZ2V0X3BjcHVfbG9jaygpOworCXJhd19ub3Rp
Zmllcl9jaGFpbl91bnJlZ2lzdGVyKCZ4ZW5fcGNwdV9jaGFpbiwgbmIpOworCXB1dF9wY3B1X2xv
Y2soKTsKK30KK0VYUE9SVF9TWU1CT0xfR1BMKHVucmVnaXN0ZXJfeGVuX3BjcHVfbm90aWZpZXIp
OworCitzdGF0aWMgaW50IHhlbl9wY3B1X2Rvd24odWludDMyX3QgeGVuX2lkKQoreworCWludCBy
ZXQ7CisJeGVuX3BsYXRmb3JtX29wX3Qgb3AgPSB7CisJCS5jbWQJCQk9IFhFTlBGX2NwdV9vZmZs
aW5lLAorCQkuaW50ZXJmYWNlX3ZlcnNpb24JPSBYRU5QRl9JTlRFUkZBQ0VfVkVSU0lPTiwKKwkJ
LnUuY3B1X29sLmNwdWlkCT0geGVuX2lkLAorCX07CisKKwlyZXQgPSBIWVBFUlZJU09SX2RvbTBf
b3AoJm9wKTsKKwlyZXR1cm4gcmV0OworfQorCitzdGF0aWMgaW50IHhlbl9wY3B1X3VwKHVpbnQz
Ml90IHhlbl9pZCkKK3sKKwlpbnQgcmV0OworCXhlbl9wbGF0Zm9ybV9vcF90IG9wID0geworCQku
Y21kCQkJPSBYRU5QRl9jcHVfb25saW5lLAorCQkuaW50ZXJmYWNlX3ZlcnNpb24JPSBYRU5QRl9J
TlRFUkZBQ0VfVkVSU0lPTiwKKwkJLnUuY3B1X29sLmNwdWlkCT0geGVuX2lkLAorCX07CisKKwly
ZXQgPSBIWVBFUlZJU09SX2RvbTBfb3AoJm9wKTsKKwlyZXR1cm4gcmV0OworfQorCitzdGF0aWMg
c3NpemVfdCBzaG93X29ubGluZShzdHJ1Y3Qgc3lzX2RldmljZSAqZGV2LAorCQkJc3RydWN0IHN5
c2Rldl9hdHRyaWJ1dGUgKmF0dHIsCisJCQljaGFyICpidWYpCit7CisJc3RydWN0IHBjcHUgKmNw
dSA9IGNvbnRhaW5lcl9vZihkZXYsIHN0cnVjdCBwY3B1LCBzeXNkZXYpOworCisJcmV0dXJuIHNw
cmludGYoYnVmLCAiJXVcbiIsICEhKGNwdS0+ZmxhZ3MgJiBYRU5fUENQVV9GTEFHU19PTkxJTkUp
KTsKK30KKworc3RhdGljIHNzaXplX3QgX19yZWYgc3RvcmVfb25saW5lKHN0cnVjdCBzeXNfZGV2
aWNlICpkZXYsCisJCQkJICBzdHJ1Y3Qgc3lzZGV2X2F0dHJpYnV0ZSAqYXR0ciwKKwkJCQkgIGNv
bnN0IGNoYXIgKmJ1Ziwgc2l6ZV90IGNvdW50KQoreworCXN0cnVjdCBwY3B1ICpjcHUgPSBjb250
YWluZXJfb2YoZGV2LCBzdHJ1Y3QgcGNwdSwgc3lzZGV2KTsKKwlzc2l6ZV90IHJldDsKKworCXN3
aXRjaCAoYnVmWzBdKSB7CisJY2FzZSAnMCc6CisJCXJldCA9IHhlbl9wY3B1X2Rvd24oY3B1LT54
ZW5faWQpOworCQlicmVhazsKKwljYXNlICcxJzoKKwkJcmV0ID0geGVuX3BjcHVfdXAoY3B1LT54
ZW5faWQpOworCQlicmVhazsKKwlkZWZhdWx0OgorCQlyZXQgPSAtRUlOVkFMOworCX0KKworCWlm
IChyZXQgPj0gMCkKKwkJcmV0ID0gY291bnQ7CisJcmV0dXJuIHJldDsKK30KKworc3RhdGljIFNZ
U0RFVl9BVFRSKG9ubGluZSwgMDY0NCwgc2hvd19vbmxpbmUsIHN0b3JlX29ubGluZSk7CisKK3N0
YXRpYyBzc2l6ZV90IHNob3dfYXBpY2lkKHN0cnVjdCBzeXNfZGV2aWNlICpkZXYsCisJCQlzdHJ1
Y3Qgc3lzZGV2X2F0dHJpYnV0ZSAqYXR0ciwKKwkJCWNoYXIgKmJ1ZikKK3sKKwlzdHJ1Y3QgcGNw
dSAqY3B1ID0gY29udGFpbmVyX29mKGRldiwgc3RydWN0IHBjcHUsIHN5c2Rldik7CisKKwlyZXR1
cm4gc3ByaW50ZihidWYsICIldVxuIiwgY3B1LT5hcGljX2lkKTsKK30KKworc3RhdGljIHNzaXpl
X3Qgc2hvd19hY3BpaWQoc3RydWN0IHN5c19kZXZpY2UgKmRldiwKKwkJCXN0cnVjdCBzeXNkZXZf
YXR0cmlidXRlICphdHRyLAorCQkJY2hhciAqYnVmKQoreworCXN0cnVjdCBwY3B1ICpjcHUgPSBj
b250YWluZXJfb2YoZGV2LCBzdHJ1Y3QgcGNwdSwgc3lzZGV2KTsKKworCXJldHVybiBzcHJpbnRm
KGJ1ZiwgIiV1XG4iLCBjcHUtPmFjcGlfaWQpOworfQorc3RhdGljIFNZU0RFVl9BVFRSKGFwaWNf
aWQsIDA0NDQsIHNob3dfYXBpY2lkLCBOVUxMKTsKK3N0YXRpYyBTWVNERVZfQVRUUihhY3BpX2lk
LCAwNDQ0LCBzaG93X2FjcGlpZCwgTlVMTCk7CisKK3N0YXRpYyBpbnQgeGVuX3BjcHVfZnJlZShz
dHJ1Y3QgcGNwdSAqcGNwdSkKK3sKKwlpZiAoIXBjcHUpCisJCXJldHVybiAwOworCisJc3lzZGV2
X3JlbW92ZV9maWxlKCZwY3B1LT5zeXNkZXYsICZhdHRyX29ubGluZSk7CisJc3lzZGV2X3VucmVn
aXN0ZXIoJnBjcHUtPnN5c2Rldik7CisJbGlzdF9kZWwoJnBjcHUtPnBjcHVfbGlzdCk7CisJa2Zy
ZWUocGNwdSk7CisKKwlyZXR1cm4gMDsKK30KKworc3RhdGljIGlubGluZSBpbnQgc2FtZV9wY3B1
KHN0cnVjdCB4ZW5wZl9wY3B1aW5mbyAqaW5mbywKKwkJCSAgICBzdHJ1Y3QgcGNwdSAqcGNwdSkK
K3sKKwlyZXR1cm4gKHBjcHUtPmFwaWNfaWQgPT0gaW5mby0+YXBpY19pZCkgJiYKKwkJKHBjcHUt
Pnhlbl9pZCA9PSBpbmZvLT54ZW5fY3B1aWQpOworfQorCisvKgorICogUmV0dXJuIDEgaWYgb25s
aW5lIHN0YXR1cyBjaGFuZ2VkCisgKi8KK3N0YXRpYyBpbnQgeGVuX3BjcHVfb25saW5lX2NoZWNr
KHN0cnVjdCB4ZW5wZl9wY3B1aW5mbyAqaW5mbywKKwkJCQkgc3RydWN0IHBjcHUgKnBjcHUpCit7
CisJaW50IHJlc3VsdCA9IDA7CisKKwlpZiAoaW5mby0+eGVuX2NwdWlkICE9IHBjcHUtPnhlbl9p
ZCkKKwkJcmV0dXJuIDA7CisKKwlpZiAoeGVuX3BjcHVfb25saW5lKGluZm8tPmZsYWdzKSAmJiAh
eGVuX3BjcHVfb25saW5lKHBjcHUtPmZsYWdzKSkgeworCQkvKiB0aGUgcGNwdSBpcyBvbmxpbmVk
ICovCisJCXBjcHUtPmZsYWdzIHw9IFhFTl9QQ1BVX0ZMQUdTX09OTElORTsKKwkJa29iamVjdF91
ZXZlbnQoJnBjcHUtPnN5c2Rldi5rb2JqLCBLT0JKX09OTElORSk7CisJCXJhd19ub3RpZmllcl9j
YWxsX2NoYWluKCZ4ZW5fcGNwdV9jaGFpbiwKKwkJCVhFTl9QQ1BVX09OTElORSwgKHZvaWQgKiko
bG9uZylwY3B1LT54ZW5faWQpOworCQlyZXN1bHQgPSAxOworCX0gZWxzZSBpZiAoIXhlbl9wY3B1
X29ubGluZShpbmZvLT5mbGFncykgJiYKKwkJIHhlbl9wY3B1X29ubGluZShwY3B1LT5mbGFncykp
ICB7CisJCS8qIFRoZSBwY3B1IGlzIG9mZmxpbmVkIG5vdyAqLworCQlwY3B1LT5mbGFncyAmPSB+
WEVOX1BDUFVfRkxBR1NfT05MSU5FOworCQlrb2JqZWN0X3VldmVudCgmcGNwdS0+c3lzZGV2Lmtv
YmosIEtPQkpfT0ZGTElORSk7CisJCXJhd19ub3RpZmllcl9jYWxsX2NoYWluKCZ4ZW5fcGNwdV9j
aGFpbiwKKwkJCVhFTl9QQ1BVX09GRkxJTkUsICh2b2lkICopKGxvbmcpcGNwdS0+eGVuX2lkKTsK
KwkJcmVzdWx0ID0gMTsKKwl9CisKKwlyZXR1cm4gcmVzdWx0OworfQorCitzdGF0aWMgaW50IHBj
cHVfc3lzZGV2X2luaXQoc3RydWN0IHBjcHUgKmNwdSkKK3sKKwlpbnQgZXJyb3I7CisKKwllcnJv
ciA9IHN5c2Rldl9yZWdpc3RlcigmY3B1LT5zeXNkZXYpOworCWlmIChlcnJvcikgeworCQlwcmlu
dGsoS0VSTl9XQVJOSU5HICJ4ZW5fcGNwdV9hZGQ6IEZhaWxlZCB0byByZWdpc3RlciBwY3B1XG4i
KTsKKwkJa2ZyZWUoY3B1KTsKKwkJcmV0dXJuIC0xOworCX0KKwlzeXNkZXZfY3JlYXRlX2ZpbGUo
JmNwdS0+c3lzZGV2LCAmYXR0cl9vbmxpbmUpOworCXN5c2Rldl9jcmVhdGVfZmlsZSgmY3B1LT5z
eXNkZXYsICZhdHRyX2FwaWNfaWQpOworCXN5c2Rldl9jcmVhdGVfZmlsZSgmY3B1LT5zeXNkZXYs
ICZhdHRyX2FjcGlfaWQpOworCXJldHVybiAwOworfQorCitzdGF0aWMgc3RydWN0IHBjcHUgKmdl
dF9wY3B1KGludCB4ZW5faWQpCit7CisJc3RydWN0IHBjcHUgKnBjcHUgPSBOVUxMOworCisJbGlz
dF9mb3JfZWFjaF9lbnRyeShwY3B1LCAmeGVuX3BjcHVzLmxpc3QsIHBjcHVfbGlzdCkgeworCQlp
ZiAocGNwdS0+eGVuX2lkID09IHhlbl9pZCkKKwkJCXJldHVybiBwY3B1OworCX0KKwlyZXR1cm4g
TlVMTDsKK30KKworc3RhdGljIHN0cnVjdCBwY3B1ICppbml0X3BjcHUoc3RydWN0IHhlbnBmX3Bj
cHVpbmZvICppbmZvKQoreworCXN0cnVjdCBwY3B1ICpwY3B1OworCisJaWYgKGluZm8tPmZsYWdz
ICYgWEVOX1BDUFVfRkxBR1NfSU5WQUxJRCkKKwkJcmV0dXJuIE5VTEw7CisKKwkvKiBUaGUgUENQ
VSBpcyBqdXN0IGFkZGVkICovCisJcGNwdSA9IGt6YWxsb2Moc2l6ZW9mKHN0cnVjdCBwY3B1KSwg
R0ZQX0tFUk5FTCk7CisJaWYgKCFwY3B1KQorCQlyZXR1cm4gTlVMTDsKKworCUlOSVRfTElTVF9I
RUFEKCZwY3B1LT5wY3B1X2xpc3QpOworCXBjcHUtPnhlbl9pZCA9IGluZm8tPnhlbl9jcHVpZDsK
KwlwY3B1LT5hcGljX2lkID0gaW5mby0+YXBpY19pZDsKKwlwY3B1LT5hY3BpX2lkID0gaW5mby0+
YWNwaV9pZDsKKwlwY3B1LT5mbGFncyA9IGluZm8tPmZsYWdzOworCisJcGNwdS0+c3lzZGV2LmNs
cyA9ICZ4ZW5fcGNwdV9zeXNkZXZfY2xhc3M7CisJcGNwdS0+c3lzZGV2LmlkID0gaW5mby0+eGVu
X2NwdWlkOworCisJaWYgKHBjcHVfc3lzZGV2X2luaXQocGNwdSkpIHsKKwkJa2ZyZWUocGNwdSk7
CisJCXJldHVybiBOVUxMOworCX0KKworCWxpc3RfYWRkX3RhaWwoJnBjcHUtPnBjcHVfbGlzdCwg
Jnhlbl9wY3B1cy5saXN0KTsKKwlyYXdfbm90aWZpZXJfY2FsbF9jaGFpbigmeGVuX3BjcHVfY2hh
aW4sCisJCQkJWEVOX1BDUFVfQURELAorCQkJCSh2b2lkICopKGxvbmcpcGNwdS0+eGVuX2lkKTsK
KwlyZXR1cm4gcGNwdTsKK30KKworI2RlZmluZSBQQ1BVX05PX0NIQU5HRQkJCTAKKyNkZWZpbmUg
UENQVV9BRERFRAkJCTEKKyNkZWZpbmUgUENQVV9PTkxJTkVfT0ZGTElORQkJMgorI2RlZmluZSBQ
Q1BVX1JFTU9WRUQJCQkzCisvKgorICogQ2FsbGVyIHNob3VsZCBob2xkIHRoZSBwY3B1IGxvY2sK
KyAqIDwgMDogU29tZXRoaW5nIHdyb25nCisgKiAwOiBObyBjaGFuZ2VzCisgKiA+IDA6IFN0YXRl
IGNoYW5nZWQKKyAqLworc3RhdGljIHN0cnVjdCBwY3B1ICpfc3luY19wY3B1KGludCBjcHVfbnVt
LCBpbnQgKm1heF9pZCwgaW50ICpyZXN1bHQpCit7CisJc3RydWN0IHBjcHUgKnBjcHUgPSBOVUxM
OworCXN0cnVjdCB4ZW5wZl9wY3B1aW5mbyAqaW5mbzsKKwl4ZW5fcGxhdGZvcm1fb3BfdCBvcCA9
IHsKKwkJLmNtZCAgICAgICAgICAgID0gWEVOUEZfZ2V0X2NwdWluZm8sCisJCS5pbnRlcmZhY2Vf
dmVyc2lvbiAgPSBYRU5QRl9JTlRFUkZBQ0VfVkVSU0lPTiwKKwl9OworCWludCByZXQ7CisKKwkq
cmVzdWx0ID0gLTE7CisKKwlpbmZvID0gJm9wLnUucGNwdV9pbmZvOworCWluZm8tPnhlbl9jcHVp
ZCA9IGNwdV9udW07CisKKwlyZXQgPSBIWVBFUlZJU09SX2RvbTBfb3AoJm9wKTsKKwlpZiAocmV0
KQorCQlyZXR1cm4gTlVMTDsKKworCWlmIChtYXhfaWQpCisJCSptYXhfaWQgPSBvcC51LnBjcHVf
aW5mby5tYXhfcHJlc2VudDsKKworCXBjcHUgPSBnZXRfcGNwdShjcHVfbnVtKTsKKworCWlmIChp
bmZvLT5mbGFncyAmIFhFTl9QQ1BVX0ZMQUdTX0lOVkFMSUQpIHsKKwkJLyogVGhlIHBjcHUgaGFz
IGJlZW4gcmVtb3ZlZCAqLworCQkqcmVzdWx0ID0gUENQVV9OT19DSEFOR0U7CisJCWlmIChwY3B1
KSB7CisJCQlyYXdfbm90aWZpZXJfY2FsbF9jaGFpbigmeGVuX3BjcHVfY2hhaW4sCisJCQkgIFhF
Tl9QQ1BVX1JFTU9WRSwKKwkJCSAgKHZvaWQgKikobG9uZylwY3B1LT54ZW5faWQpOworCQkJeGVu
X3BjcHVfZnJlZShwY3B1KTsKKwkJCSpyZXN1bHQgPSBQQ1BVX1JFTU9WRUQ7CisJCX0KKwkJcmV0
dXJuIE5VTEw7CisJfQorCisKKwlpZiAoIXBjcHUpIHsKKwkJKnJlc3VsdCA9IFBDUFVfQURERUQ7
CisJCXBjcHUgPSBpbml0X3BjcHUoaW5mbyk7CisJCWlmIChwY3B1ID09IE5VTEwpIHsKKwkJCXBy
aW50ayhLRVJOX1dBUk5JTkcgIkZhaWxlZCB0byBpbml0IHBjcHUgJXhcbiIsCisJCQkgIGluZm8t
Pnhlbl9jcHVpZCk7CisJCQkgICpyZXN1bHQgPSAtMTsKKwkJfQorCX0gZWxzZSB7CisJCSpyZXN1
bHQgPSBQQ1BVX05PX0NIQU5HRTsKKwkJLyoKKwkJICogT2xkIFBDUFUgaXMgcmVwbGFjZWQgd2l0
aCBhIG5ldyBwY3B1LCB0aGlzIG1lYW5zCisJCSAqIHNldmVyYWwgdmlycSBpcyBtaXNzZWQsIHdp
bGwgaXQgaGFwcGVuPworCQkgKi8KKwkJaWYgKCFzYW1lX3BjcHUoaW5mbywgcGNwdSkpIHsKKwkJ
CXByaW50ayhLRVJOX1dBUk5JTkcgIlBjcHUgJXggY2hhbmdlZCFcbiIsCisJCQkgIHBjcHUtPnhl
bl9pZCk7CisJCQlwY3B1LT5hcGljX2lkID0gaW5mby0+YXBpY19pZDsKKwkJCXBjcHUtPmFjcGlf
aWQgPSBpbmZvLT5hY3BpX2lkOworCQl9CisJCWlmICh4ZW5fcGNwdV9vbmxpbmVfY2hlY2soaW5m
bywgcGNwdSkpCisJCQkqcmVzdWx0ID0gUENQVV9PTkxJTkVfT0ZGTElORTsKKwl9CisJcmV0dXJu
IHBjcHU7Cit9CisKK2ludCB4ZW5fcGNwdV9pbmRleCh1aW50MzJfdCBpZCwgaW50IGlzX2FjcGlp
ZCkKK3sKKwlpbnQgY3B1X251bSA9IDAsIG1heF9pZCA9IDAsIHJldDsKKwl4ZW5fcGxhdGZvcm1f
b3BfdCBvcCA9IHsKKwkJLmNtZCAgICAgICAgICAgID0gWEVOUEZfZ2V0X2NwdWluZm8sCisJCS5p
bnRlcmZhY2VfdmVyc2lvbiAgPSBYRU5QRl9JTlRFUkZBQ0VfVkVSU0lPTiwKKwl9OworCXN0cnVj
dCB4ZW5wZl9wY3B1aW5mbyAqaW5mbyA9ICZvcC51LnBjcHVfaW5mbzsKKworCWluZm8tPnhlbl9j
cHVpZCA9IDA7CisJcmV0ID0gSFlQRVJWSVNPUl9kb20wX29wKCZvcCk7CisJaWYgKHJldCkKKwkJ
cmV0dXJuIC0xOworCW1heF9pZCA9IG9wLnUucGNwdV9pbmZvLm1heF9wcmVzZW50OworCisJd2hp
bGUgKChjcHVfbnVtIDw9IG1heF9pZCkpIHsKKwkJaW5mby0+eGVuX2NwdWlkID0gY3B1X251bTsK
KwkJcmV0ID0gSFlQRVJWSVNPUl9kb20wX29wKCZvcCk7CisJCWlmIChyZXQpCisJCQljb250aW51
ZTsKKworCQlpZiAob3AudS5wY3B1X2luZm8ubWF4X3ByZXNlbnQgPiBtYXhfaWQpCisJCQltYXhf
aWQgPSBvcC51LnBjcHVfaW5mby5tYXhfcHJlc2VudDsKKwkJaWYgKGlkID09IChpc19hY3BpaWQg
PyBpbmZvLT5hY3BpX2lkIDogaW5mby0+YXBpY19pZCkpCisJCQlyZXR1cm4gY3B1X251bTsKKwkJ
Y3B1X251bSsrOworCX0KKworICAgIHJldHVybiAtMTsKK30KK0VYUE9SVF9TWU1CT0woeGVuX3Bj
cHVfaW5kZXgpOworCisvKgorICogU3luYyBkb20wJ3MgcGNwdSBpbmZvcm1hdGlvbiB3aXRoIHhl
biBoeXBlcnZpc29yJ3MKKyAqLworc3RhdGljIGludCB4ZW5fc3luY19wY3B1cyh2b2lkKQorewor
CS8qCisJICogQm9vdCBjcHUgYWx3YXlzIGhhdmUgY3B1X2lkIDAgaW4geGVuCisJICovCisJaW50
IGNwdV9udW0gPSAwLCBtYXhfaWQgPSAwLCByZXN1bHQgPSAwLCBwcmVzZW50ID0gMDsKKwlzdHJ1
Y3QgbGlzdF9oZWFkICplbGVtLCAqdG1wOworCXN0cnVjdCBwY3B1ICpwY3B1OworCisJZ2V0X3Bj
cHVfbG9jaygpOworCisJd2hpbGUgKChyZXN1bHQgPj0gMCkgJiYgKGNwdV9udW0gPD0gbWF4X2lk
KSkgeworCQlwY3B1ID0gX3N5bmNfcGNwdShjcHVfbnVtLCAmbWF4X2lkLCAmcmVzdWx0KTsKKwor
CQlwcmludGsoS0VSTl9ERUJVRyAic3luYyBjcHUgJXggZ2V0IHJlc3VsdCAleCBtYXhfaWQgJXhc
biIsCisJCQljcHVfbnVtLCByZXN1bHQsIG1heF9pZCk7CisKKwkJc3dpdGNoIChyZXN1bHQpCXsK
KwkJY2FzZSBQQ1BVX05PX0NIQU5HRToKKwkJCWlmIChwY3B1KQorCQkJCXByZXNlbnQrKzsKKwkJ
CWJyZWFrOworCQljYXNlIFBDUFVfQURERUQ6CisJCWNhc2UgUENQVV9PTkxJTkVfT0ZGTElORToK
KwkJCXByZXNlbnQrKzsKKwkJY2FzZSBQQ1BVX1JFTU9WRUQ6CisJCQlicmVhazsKKwkJZGVmYXVs
dDoKKwkJCXByaW50ayhLRVJOX1dBUk5JTkcgIkZhaWxlZCB0byBzeW5jIHBjcHUgJXhcbiIsCisJ
CQkgIGNwdV9udW0pOworCQkJYnJlYWs7CisKKwkJfQorCQljcHVfbnVtKys7CisJfQorCisJaWYg
KHJlc3VsdCA8IDApIHsKKwkJbGlzdF9mb3JfZWFjaF9zYWZlKGVsZW0sIHRtcCwgJnhlbl9wY3B1
cy5saXN0KSB7CisJCQlwY3B1ID0gbGlzdF9lbnRyeShlbGVtLCBzdHJ1Y3QgcGNwdSwgcGNwdV9s
aXN0KTsKKwkJCXhlbl9wY3B1X2ZyZWUocGNwdSk7CisJCX0KKwkJcHJlc2VudCA9IDA7CisJfQor
CisJeGVuX3BjcHVzLnByZXNlbnQgPSBwcmVzZW50OworCisJcHV0X3BjcHVfbG9jaygpOworCisJ
cmV0dXJuIDA7Cit9CisKK3N0YXRpYyB2b2lkIHhlbl9wY3B1X2RwYyhzdHJ1Y3Qgd29ya19zdHJ1
Y3QgKndvcmspCit7CisJaWYgKHhlbl9zeW5jX3BjcHVzKCkgPCAwKQorCQlwcmludGsoS0VSTl9X
QVJOSU5HCisJCQkieGVuX3BjcHVfZHBjOiBGYWlsZWQgdG8gc3luYyBwY3B1IGluZm9ybWF0aW9u
XG4iKTsKK30KK3N0YXRpYyBERUNMQVJFX1dPUksoeGVuX3BjcHVfd29yaywgeGVuX3BjcHVfZHBj
KTsKKworaW50IHhlbl9wY3B1X2hvdHBsdWcoaW50IHR5cGUsIHVpbnQzMl90IGFwaWNfaWQpCit7
CisJc2NoZWR1bGVfd29yaygmeGVuX3BjcHVfd29yayk7CisKKwlyZXR1cm4gMDsKK30KK0VYUE9S
VF9TWU1CT0woeGVuX3BjcHVfaG90cGx1Zyk7CisKK3N0YXRpYyBpcnFyZXR1cm5fdCB4ZW5fcGNw
dV9pbnRlcnJ1cHQoaW50IGlycSwgdm9pZCAqZGV2X2lkKQoreworCXNjaGVkdWxlX3dvcmsoJnhl
bl9wY3B1X3dvcmspOworCXJldHVybiBJUlFfSEFORExFRDsKK30KKworc3RhdGljIGludCBfX2lu
aXQgeGVuX3BjcHVfaW5pdCh2b2lkKQoreworCWludCBlcnI7CisKKwlpZiAoIXhlbl9pbml0aWFs
X2RvbWFpbigpKQorCQlyZXR1cm4gMDsKKworCWVyciA9IHN5c2Rldl9jbGFzc19yZWdpc3Rlcigm
eGVuX3BjcHVfc3lzZGV2X2NsYXNzKTsKKwlpZiAoZXJyKSB7CisJCXByaW50ayhLRVJOX1dBUk5J
TkcKKwkJCSJ4ZW5fcGNwdV9pbml0OiByZWdpc3RlciB4ZW5fcGNwdSBzeXNkZXYgRmFpbGVkIVxu
Iik7CisJCXJldHVybiBlcnI7CisJfQorCisJSU5JVF9MSVNUX0hFQUQoJnhlbl9wY3B1cy5saXN0
KTsKKwl4ZW5fcGNwdXMucHJlc2VudCA9IDA7CisKKwl4ZW5fc3luY19wY3B1cygpOworCWlmICh4
ZW5fcGNwdXMucHJlc2VudCA+IDApCisJCWVyciA9IGJpbmRfdmlycV90b19pcnFoYW5kbGVyKFZJ
UlFfUENQVV9TVEFURSwKKwkJCTAsIHhlbl9wY3B1X2ludGVycnVwdCwgMCwgInBjcHUiLCBOVUxM
KTsKKwlpZiAoZXJyIDwgMCkKKwkJcHJpbnRrKEtFUk5fV0FSTklORyAieGVuX3BjcHVfaW5pdDog
IgorCQkJIkZhaWxlZCB0byBiaW5kIHBjcHVfc3RhdGUgdmlycVxuIgorCQkJIllvdSB3aWxsIGxv
c3QgbGF0ZXN0IGluZm9ybWF0aW9uISBcbiIpOworCXJldHVybiBlcnI7Cit9CisKK2FyY2hfaW5p
dGNhbGwoeGVuX3BjcHVfaW5pdCk7CmRpZmYgLS1naXQgYS9pbmNsdWRlL3hlbi9pbnRlcmZhY2Uv
cGxhdGZvcm0uaCBiL2luY2x1ZGUveGVuL2ludGVyZmFjZS9wbGF0Zm9ybS5oCmluZGV4IGMxNjg0
NjguLjQ3ZmZlMTYgMTAwNjQ0Ci0tLSBhL2luY2x1ZGUveGVuL2ludGVyZmFjZS9wbGF0Zm9ybS5o
CisrKyBiL2luY2x1ZGUveGVuL2ludGVyZmFjZS9wbGF0Zm9ybS5oCkBAIC0yOTcsNiArMjk3LDMx
IEBAIHN0cnVjdCB4ZW5wZl9zZXRfcHJvY2Vzc29yX3BtaW5mbyB7CiB9OwogREVGSU5FX0dVRVNU
X0hBTkRMRV9TVFJVQ1QoeGVucGZfc2V0X3Byb2Nlc3Nvcl9wbWluZm8pOwogCisjZGVmaW5lIFhF
TlBGX2dldF9jcHVpbmZvIDU1CitzdHJ1Y3QgeGVucGZfcGNwdWluZm8geworCS8qIElOICovCisJ
dWludDMyX3QgeGVuX2NwdWlkOworCS8qIE9VVCAqLworCS8qIFRoZSBtYXhpdW0gY3B1X2lkIHRo
YXQgaXMgcHJlc2VudCAqLworCXVpbnQzMl90IG1heF9wcmVzZW50OworI2RlZmluZSBYRU5fUENQ
VV9GTEFHU19PTkxJTkUgICAxCisJLyogQ29ycmVwb25kaW5nIHhlbl9jcHVpZCBpcyBub3QgcHJl
c2VudCovCisjZGVmaW5lIFhFTl9QQ1BVX0ZMQUdTX0lOVkFMSUQgIDIKKwl1aW50MzJfdCBmbGFn
czsKKwl1aW50MzJfdCBhcGljX2lkOworCXVpbnQzMl90IGFjcGlfaWQ7Cit9OwordHlwZWRlZiBz
dHJ1Y3QgeGVucGZfcGNwdWluZm8geGVucGZfcGNwdWluZm9fdDsKK0RFRklORV9HVUVTVF9IQU5E
TEVfU1RSVUNUKHhlbnBmX3BjcHVpbmZvX3QpOworCisjZGVmaW5lIFhFTlBGX2NwdV9vbmxpbmUg
ICAgNTYKKyNkZWZpbmUgWEVOUEZfY3B1X29mZmxpbmUgICA1Nworc3RydWN0IHhlbnBmX2NwdV9v
bCB7CisgICAgdWludDMyX3QgY3B1aWQ7Cit9OwordHlwZWRlZiBzdHJ1Y3QgeGVucGZfY3B1X29s
IHhlbnBmX2NwdV9vbF90OworREVGSU5FX0dVRVNUX0hBTkRMRV9TVFJVQ1QoeGVucGZfY3B1X29s
X3QpOworCiBzdHJ1Y3QgeGVuX3BsYXRmb3JtX29wIHsKIAl1aW50MzJfdCBjbWQ7CiAJdWludDMy
X3QgaW50ZXJmYWNlX3ZlcnNpb247IC8qIFhFTlBGX0lOVEVSRkFDRV9WRVJTSU9OICovCkBAIC0z
MTIsOSArMzM3LDEyIEBAIHN0cnVjdCB4ZW5fcGxhdGZvcm1fb3AgewogCQlzdHJ1Y3QgeGVucGZf
Y2hhbmdlX2ZyZXEgICAgICAgY2hhbmdlX2ZyZXE7CiAJCXN0cnVjdCB4ZW5wZl9nZXRpZGxldGlt
ZSAgICAgICBnZXRpZGxldGltZTsKIAkJc3RydWN0IHhlbnBmX3NldF9wcm9jZXNzb3JfcG1pbmZv
IHNldF9wbWluZm87CisJCXN0cnVjdCB4ZW5wZl9wY3B1aW5mbyAgICAgICAgICBwY3B1X2luZm87
CisJCXN0cnVjdCB4ZW5wZl9jcHVfb2wgICAgICAgICAgICBjcHVfb2w7CiAJCXVpbnQ4X3QgICAg
ICAgICAgICAgICAgICAgICAgICBwYWRbMTI4XTsKIAl9IHU7CiB9OwordHlwZWRlZiBzdHJ1Y3Qg
eGVuX3BsYXRmb3JtX29wIHhlbl9wbGF0Zm9ybV9vcF90OwogREVGSU5FX0dVRVNUX0hBTkRMRV9T
VFJVQ1QoeGVuX3BsYXRmb3JtX29wX3QpOwogCiAjZW5kaWYgLyogX19YRU5fUFVCTElDX1BMQVRG
T1JNX0hfXyAqLwpkaWZmIC0tZ2l0IGEvaW5jbHVkZS94ZW4vaW50ZXJmYWNlL3hlbi5oIGIvaW5j
bHVkZS94ZW4vaW50ZXJmYWNlL3hlbi5oCmluZGV4IDZhNmU5MTQuLjVhOTFjNjYgMTAwNjQ0Ci0t
LSBhL2luY2x1ZGUveGVuL2ludGVyZmFjZS94ZW4uaAorKysgYi9pbmNsdWRlL3hlbi9pbnRlcmZh
Y2UveGVuLmgKQEAgLTgwLDYgKzgwLDcgQEAKICNkZWZpbmUgVklSUV9DT05TT0xFICAgIDIgIC8q
IChET00wKSBCeXRlcyByZWNlaXZlZCBvbiBlbWVyZ2VuY3kgY29uc29sZS4gKi8KICNkZWZpbmUg
VklSUV9ET01fRVhDICAgIDMgIC8qIChET00wKSBFeGNlcHRpb25hbCBldmVudCBmb3Igc29tZSBk
b21haW4uICAgKi8KICNkZWZpbmUgVklSUV9ERUJVR0dFUiAgIDYgIC8qIChET00wKSBBIGRvbWFp
biBoYXMgcGF1c2VkIGZvciBkZWJ1Z2dpbmcuICAgKi8KKyNkZWZpbmUgVklSUV9QQ1BVX1NUQVRF
IDkgIC8qIChET00wKSBQQ1BVIHN0YXRlIGNoYW5nZWQgICAgICAgICAgICAgICAgICAgKi8KIAog
LyogQXJjaGl0ZWN0dXJlLXNwZWNpZmljIFZJUlEgZGVmaW5pdGlvbnMuICovCiAjZGVmaW5lIFZJ
UlFfQVJDSF8wICAgIDE2CmRpZmYgLS1naXQgYS9pbmNsdWRlL3hlbi9wY3B1LmggYi9pbmNsdWRl
L3hlbi9wY3B1LmgKbmV3IGZpbGUgbW9kZSAxMDA2NDQKaW5kZXggMDAwMDAwMC4uN2U4ZjlkMQot
LS0gL2Rldi9udWxsCisrKyBiL2luY2x1ZGUveGVuL3BjcHUuaApAQCAtMCwwICsxLDMyIEBACisj
aWZuZGVmIF9YRU5fUENQVV9ICisjZGVmaW5lIF9YRU5fUENQVV9ICisKKyNpbmNsdWRlIDx4ZW4v
aW50ZXJmYWNlL3BsYXRmb3JtLmg+CisjaW5jbHVkZSA8bGludXgvc3lzZGV2Lmg+CisKK2V4dGVy
biBpbnQgeGVuX3BjcHVfaG90cGx1ZyhpbnQgdHlwZSwgdWludDMyX3QgYXBpY19pZCk7CisjZGVm
aW5lIFhFTl9QQ1BVX09OTElORSAgICAgMHgwMQorI2RlZmluZSBYRU5fUENQVV9PRkZMSU5FICAg
IDB4MDIKKyNkZWZpbmUgWEVOX1BDUFVfQUREICAgICAgICAweDA0CisjZGVmaW5lIFhFTl9QQ1BV
X1JFTU9WRSAgICAgMHgwOAorCitzdHJ1Y3QgcGNwdSB7CisJc3RydWN0IGxpc3RfaGVhZCBwY3B1
X2xpc3Q7CisJc3RydWN0IHN5c19kZXZpY2Ugc3lzZGV2OworCXVpbnQzMl90IHhlbl9pZDsKKwl1
aW50MzJfdCBhcGljX2lkOworCXVpbnQzMl90IGFjcGlfaWQ7CisJdWludDMyX3QgZmxhZ3M7Cit9
OworCitzdGF0aWMgaW5saW5lIGludCB4ZW5fcGNwdV9vbmxpbmUodWludDMyX3QgZmxhZ3MpCit7
CisJcmV0dXJuICEhKGZsYWdzICYgWEVOX1BDUFVfRkxBR1NfT05MSU5FKTsKK30KKworZXh0ZXJu
IGludCByZWdpc3Rlcl94ZW5fcGNwdV9ub3RpZmllcihzdHJ1Y3Qgbm90aWZpZXJfYmxvY2sgKm5i
KTsKKworZXh0ZXJuIHZvaWQgdW5yZWdpc3Rlcl94ZW5fcGNwdV9ub3RpZmllcihzdHJ1Y3Qgbm90
aWZpZXJfYmxvY2sgKm5iKTsKKworZXh0ZXJuIGludCB4ZW5fcGNwdV9pbmRleCh1aW50MzJfdCBh
Y3BpX2lkLCBpbnQgaXNfYWNwaWlkKTsKKyNlbmRpZgotLSAKMS42LjUuNgoK

--_002_DE8DF0795D48FD4CA783C40EC82923358A04SHSMSX101ccrcorpint_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--_002_DE8DF0795D48FD4CA783C40EC82923358A04SHSMSX101ccrcorpint_--


From xen-devel-bounces@lists.xensource.com Thu Dec 22 10:05:05 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 Dec 2011 10:05:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdfWA-0004vk-As; Thu, 22 Dec 2011 10:04:54 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1RdfW8-0004um-Aa
	for xen-devel@lists.xensource.com; Thu, 22 Dec 2011 10:04:52 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1324548282!6501628!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMjkwMjgz\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22796 invoked from network); 22 Dec 2011 10:04:44 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-2.tower-174.messagelabs.com with SMTP;
	22 Dec 2011 10:04:44 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga101.jf.intel.com with ESMTP; 22 Dec 2011 02:04:41 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.67,352,1309762800"; d="scan'208,223";a="89281017"
Received: from pgsmsx602.gar.corp.intel.com ([10.221.43.81])
	by orsmga001.jf.intel.com with ESMTP; 22 Dec 2011 02:04:40 -0800
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	pgsmsx602.gar.corp.intel.com (10.221.43.81) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Thu, 22 Dec 2011 18:04:33 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.38]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.199]) with mapi id
	14.01.0355.002; Thu, 22 Dec 2011 18:04:32 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: "konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Thread-Topic: [PATCH 03/10] Xen: Export host physical CPU information to dom0
Thread-Index: AczAkRjYvN5ypRb3S/isdZfI5BO1QQ==
Date: Thu, 22 Dec 2011 10:04:31 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC82923358A24@SHSMSX101.ccr.corp.intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
Content-Type: multipart/mixed;
	boundary="_002_DE8DF0795D48FD4CA783C40EC82923358A24SHSMSX101ccrcorpint_"
MIME-Version: 1.0
Cc: "Jiang, Yunhong" <yunhong.jiang@intel.com>,
	"jeremy.fitzhardinge@citrix.com" <jeremy.fitzhardinge@citrix.com>
Subject: [Xen-devel] [PATCH 03/10] Xen: Export host physical CPU information
	to dom0
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--_002_DE8DF0795D48FD4CA783C40EC82923358A24SHSMSX101ccrcorpint_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

>From 04151aa18b48a452cc9d0696f36aa96c690ca011 Mon Sep 17 00:00:00 2001
From: Liu Jinsong <jinsong.liu@intel.com>
Date: Thu, 8 Dec 2011 22:28:07 +0800
Subject: [PATCH 03/10] Xen: Export host physical CPU information to dom0

This patch rebased from Jeremy's pvops commit
3b34cd19627c6e191b15fd6cb59f997b8db21e19 and
68320323a51c2378aca433c76157d9e66104ff1e

This patch expose host's physical CPU information to dom0 in sysfs, so
that dom0's management tools can control the physical CPU if needed.

It also provides interface in sysfs to logical online/offline a physical CP=
U.

Notice: The information in dom0 is synced with xen hypervisor asynchronousl=
y.

Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
Signed-off-by: Jiang, Yunhong <yunhong.jiang@intel.com>
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
---
 drivers/xen/Makefile             |    2 +-
 drivers/xen/pcpu.c               |  452 ++++++++++++++++++++++++++++++++++=
++++
 include/xen/interface/platform.h |   28 +++
 include/xen/interface/xen.h      |    1 +
 include/xen/pcpu.h               |   32 +++
 5 files changed, 514 insertions(+), 1 deletions(-)
 create mode 100644 drivers/xen/pcpu.c
 create mode 100644 include/xen/pcpu.h

diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
index 405cce9..aedaf48 100644
--- a/drivers/xen/Makefile
+++ b/drivers/xen/Makefile
@@ -1,4 +1,4 @@
-obj-y	+=3D grant-table.o features.o events.o manage.o balloon.o
+obj-y	+=3D grant-table.o features.o events.o manage.o balloon.o pcpu.o
 obj-y	+=3D xenbus/
=20
 nostackp :=3D $(call cc-option, -fno-stack-protector)
diff --git a/drivers/xen/pcpu.c b/drivers/xen/pcpu.c
new file mode 100644
index 0000000..6d1a770
--- /dev/null
+++ b/drivers/xen/pcpu.c
@@ -0,0 +1,452 @@
+/*
+ * pcpu.c - management physical cpu in dom0 environment
+ */
+#include <linux/interrupt.h>
+#include <linux/spinlock.h>
+#include <asm/xen/hypervisor.h>
+#include <asm/xen/hypercall.h>
+#include <linux/cpu.h>
+#include <xen/xenbus.h>
+#include <xen/pcpu.h>
+#include <xen/events.h>
+#include <xen/acpi.h>
+
+static struct sysdev_class xen_pcpu_sysdev_class =3D {
+	.name =3D "xen_pcpu",
+};
+
+static DEFINE_MUTEX(xen_pcpu_lock);
+static RAW_NOTIFIER_HEAD(xen_pcpu_chain);
+
+/* No need for irq disable since hotplug notify is in workqueue context */
+#define get_pcpu_lock() mutex_lock(&xen_pcpu_lock);
+#define put_pcpu_lock() mutex_unlock(&xen_pcpu_lock);
+
+struct xen_pcpus {
+	struct list_head list;
+	int present;
+};
+static struct xen_pcpus xen_pcpus;
+
+int register_xen_pcpu_notifier(struct notifier_block *nb)
+{
+	int ret;
+
+	/* All refer to the chain notifier is protected by the pcpu_lock */
+	get_pcpu_lock();
+	ret =3D raw_notifier_chain_register(&xen_pcpu_chain, nb);
+	put_pcpu_lock();
+	return ret;
+}
+EXPORT_SYMBOL_GPL(register_xen_pcpu_notifier);
+
+void unregister_xen_pcpu_notifier(struct notifier_block *nb)
+{
+	get_pcpu_lock();
+	raw_notifier_chain_unregister(&xen_pcpu_chain, nb);
+	put_pcpu_lock();
+}
+EXPORT_SYMBOL_GPL(unregister_xen_pcpu_notifier);
+
+static int xen_pcpu_down(uint32_t xen_id)
+{
+	int ret;
+	xen_platform_op_t op =3D {
+		.cmd			=3D XENPF_cpu_offline,
+		.interface_version	=3D XENPF_INTERFACE_VERSION,
+		.u.cpu_ol.cpuid	=3D xen_id,
+	};
+
+	ret =3D HYPERVISOR_dom0_op(&op);
+	return ret;
+}
+
+static int xen_pcpu_up(uint32_t xen_id)
+{
+	int ret;
+	xen_platform_op_t op =3D {
+		.cmd			=3D XENPF_cpu_online,
+		.interface_version	=3D XENPF_INTERFACE_VERSION,
+		.u.cpu_ol.cpuid	=3D xen_id,
+	};
+
+	ret =3D HYPERVISOR_dom0_op(&op);
+	return ret;
+}
+
+static ssize_t show_online(struct sys_device *dev,
+			struct sysdev_attribute *attr,
+			char *buf)
+{
+	struct pcpu *cpu =3D container_of(dev, struct pcpu, sysdev);
+
+	return sprintf(buf, "%u\n", !!(cpu->flags & XEN_PCPU_FLAGS_ONLINE));
+}
+
+static ssize_t __ref store_online(struct sys_device *dev,
+				  struct sysdev_attribute *attr,
+				  const char *buf, size_t count)
+{
+	struct pcpu *cpu =3D container_of(dev, struct pcpu, sysdev);
+	ssize_t ret;
+
+	switch (buf[0]) {
+	case '0':
+		ret =3D xen_pcpu_down(cpu->xen_id);
+		break;
+	case '1':
+		ret =3D xen_pcpu_up(cpu->xen_id);
+		break;
+	default:
+		ret =3D -EINVAL;
+	}
+
+	if (ret >=3D 0)
+		ret =3D count;
+	return ret;
+}
+
+static SYSDEV_ATTR(online, 0644, show_online, store_online);
+
+static ssize_t show_apicid(struct sys_device *dev,
+			struct sysdev_attribute *attr,
+			char *buf)
+{
+	struct pcpu *cpu =3D container_of(dev, struct pcpu, sysdev);
+
+	return sprintf(buf, "%u\n", cpu->apic_id);
+}
+
+static ssize_t show_acpiid(struct sys_device *dev,
+			struct sysdev_attribute *attr,
+			char *buf)
+{
+	struct pcpu *cpu =3D container_of(dev, struct pcpu, sysdev);
+
+	return sprintf(buf, "%u\n", cpu->acpi_id);
+}
+static SYSDEV_ATTR(apic_id, 0444, show_apicid, NULL);
+static SYSDEV_ATTR(acpi_id, 0444, show_acpiid, NULL);
+
+static int xen_pcpu_free(struct pcpu *pcpu)
+{
+	if (!pcpu)
+		return 0;
+
+	sysdev_remove_file(&pcpu->sysdev, &attr_online);
+	sysdev_unregister(&pcpu->sysdev);
+	list_del(&pcpu->pcpu_list);
+	kfree(pcpu);
+
+	return 0;
+}
+
+static inline int same_pcpu(struct xenpf_pcpuinfo *info,
+			    struct pcpu *pcpu)
+{
+	return (pcpu->apic_id =3D=3D info->apic_id) &&
+		(pcpu->xen_id =3D=3D info->xen_cpuid);
+}
+
+/*
+ * Return 1 if online status changed
+ */
+static int xen_pcpu_online_check(struct xenpf_pcpuinfo *info,
+				 struct pcpu *pcpu)
+{
+	int result =3D 0;
+
+	if (info->xen_cpuid !=3D pcpu->xen_id)
+		return 0;
+
+	if (xen_pcpu_online(info->flags) && !xen_pcpu_online(pcpu->flags)) {
+		/* the pcpu is onlined */
+		pcpu->flags |=3D XEN_PCPU_FLAGS_ONLINE;
+		kobject_uevent(&pcpu->sysdev.kobj, KOBJ_ONLINE);
+		raw_notifier_call_chain(&xen_pcpu_chain,
+			XEN_PCPU_ONLINE, (void *)(long)pcpu->xen_id);
+		result =3D 1;
+	} else if (!xen_pcpu_online(info->flags) &&
+		 xen_pcpu_online(pcpu->flags))  {
+		/* The pcpu is offlined now */
+		pcpu->flags &=3D ~XEN_PCPU_FLAGS_ONLINE;
+		kobject_uevent(&pcpu->sysdev.kobj, KOBJ_OFFLINE);
+		raw_notifier_call_chain(&xen_pcpu_chain,
+			XEN_PCPU_OFFLINE, (void *)(long)pcpu->xen_id);
+		result =3D 1;
+	}
+
+	return result;
+}
+
+static int pcpu_sysdev_init(struct pcpu *cpu)
+{
+	int error;
+
+	error =3D sysdev_register(&cpu->sysdev);
+	if (error) {
+		printk(KERN_WARNING "xen_pcpu_add: Failed to register pcpu\n");
+		kfree(cpu);
+		return -1;
+	}
+	sysdev_create_file(&cpu->sysdev, &attr_online);
+	sysdev_create_file(&cpu->sysdev, &attr_apic_id);
+	sysdev_create_file(&cpu->sysdev, &attr_acpi_id);
+	return 0;
+}
+
+static struct pcpu *get_pcpu(int xen_id)
+{
+	struct pcpu *pcpu =3D NULL;
+
+	list_for_each_entry(pcpu, &xen_pcpus.list, pcpu_list) {
+		if (pcpu->xen_id =3D=3D xen_id)
+			return pcpu;
+	}
+	return NULL;
+}
+
+static struct pcpu *init_pcpu(struct xenpf_pcpuinfo *info)
+{
+	struct pcpu *pcpu;
+
+	if (info->flags & XEN_PCPU_FLAGS_INVALID)
+		return NULL;
+
+	/* The PCPU is just added */
+	pcpu =3D kzalloc(sizeof(struct pcpu), GFP_KERNEL);
+	if (!pcpu)
+		return NULL;
+
+	INIT_LIST_HEAD(&pcpu->pcpu_list);
+	pcpu->xen_id =3D info->xen_cpuid;
+	pcpu->apic_id =3D info->apic_id;
+	pcpu->acpi_id =3D info->acpi_id;
+	pcpu->flags =3D info->flags;
+
+	pcpu->sysdev.cls =3D &xen_pcpu_sysdev_class;
+	pcpu->sysdev.id =3D info->xen_cpuid;
+
+	if (pcpu_sysdev_init(pcpu)) {
+		kfree(pcpu);
+		return NULL;
+	}
+
+	list_add_tail(&pcpu->pcpu_list, &xen_pcpus.list);
+	raw_notifier_call_chain(&xen_pcpu_chain,
+				XEN_PCPU_ADD,
+				(void *)(long)pcpu->xen_id);
+	return pcpu;
+}
+
+#define PCPU_NO_CHANGE			0
+#define PCPU_ADDED			1
+#define PCPU_ONLINE_OFFLINE		2
+#define PCPU_REMOVED			3
+/*
+ * Caller should hold the pcpu lock
+ * < 0: Something wrong
+ * 0: No changes
+ * > 0: State changed
+ */
+static struct pcpu *_sync_pcpu(int cpu_num, int *max_id, int *result)
+{
+	struct pcpu *pcpu =3D NULL;
+	struct xenpf_pcpuinfo *info;
+	xen_platform_op_t op =3D {
+		.cmd            =3D XENPF_get_cpuinfo,
+		.interface_version  =3D XENPF_INTERFACE_VERSION,
+	};
+	int ret;
+
+	*result =3D -1;
+
+	info =3D &op.u.pcpu_info;
+	info->xen_cpuid =3D cpu_num;
+
+	ret =3D HYPERVISOR_dom0_op(&op);
+	if (ret)
+		return NULL;
+
+	if (max_id)
+		*max_id =3D op.u.pcpu_info.max_present;
+
+	pcpu =3D get_pcpu(cpu_num);
+
+	if (info->flags & XEN_PCPU_FLAGS_INVALID) {
+		/* The pcpu has been removed */
+		*result =3D PCPU_NO_CHANGE;
+		if (pcpu) {
+			raw_notifier_call_chain(&xen_pcpu_chain,
+			  XEN_PCPU_REMOVE,
+			  (void *)(long)pcpu->xen_id);
+			xen_pcpu_free(pcpu);
+			*result =3D PCPU_REMOVED;
+		}
+		return NULL;
+	}
+
+
+	if (!pcpu) {
+		*result =3D PCPU_ADDED;
+		pcpu =3D init_pcpu(info);
+		if (pcpu =3D=3D NULL) {
+			printk(KERN_WARNING "Failed to init pcpu %x\n",
+			  info->xen_cpuid);
+			  *result =3D -1;
+		}
+	} else {
+		*result =3D PCPU_NO_CHANGE;
+		/*
+		 * Old PCPU is replaced with a new pcpu, this means
+		 * several virq is missed, will it happen?
+		 */
+		if (!same_pcpu(info, pcpu)) {
+			printk(KERN_WARNING "Pcpu %x changed!\n",
+			  pcpu->xen_id);
+			pcpu->apic_id =3D info->apic_id;
+			pcpu->acpi_id =3D info->acpi_id;
+		}
+		if (xen_pcpu_online_check(info, pcpu))
+			*result =3D PCPU_ONLINE_OFFLINE;
+	}
+	return pcpu;
+}
+
+int xen_pcpu_index(uint32_t id, int is_acpiid)
+{
+	int cpu_num =3D 0, max_id =3D 0, ret;
+	xen_platform_op_t op =3D {
+		.cmd            =3D XENPF_get_cpuinfo,
+		.interface_version  =3D XENPF_INTERFACE_VERSION,
+	};
+	struct xenpf_pcpuinfo *info =3D &op.u.pcpu_info;
+
+	info->xen_cpuid =3D 0;
+	ret =3D HYPERVISOR_dom0_op(&op);
+	if (ret)
+		return -1;
+	max_id =3D op.u.pcpu_info.max_present;
+
+	while ((cpu_num <=3D max_id)) {
+		info->xen_cpuid =3D cpu_num;
+		ret =3D HYPERVISOR_dom0_op(&op);
+		if (ret)
+			continue;
+
+		if (op.u.pcpu_info.max_present > max_id)
+			max_id =3D op.u.pcpu_info.max_present;
+		if (id =3D=3D (is_acpiid ? info->acpi_id : info->apic_id))
+			return cpu_num;
+		cpu_num++;
+	}
+
+    return -1;
+}
+EXPORT_SYMBOL(xen_pcpu_index);
+
+/*
+ * Sync dom0's pcpu information with xen hypervisor's
+ */
+static int xen_sync_pcpus(void)
+{
+	/*
+	 * Boot cpu always have cpu_id 0 in xen
+	 */
+	int cpu_num =3D 0, max_id =3D 0, result =3D 0, present =3D 0;
+	struct list_head *elem, *tmp;
+	struct pcpu *pcpu;
+
+	get_pcpu_lock();
+
+	while ((result >=3D 0) && (cpu_num <=3D max_id)) {
+		pcpu =3D _sync_pcpu(cpu_num, &max_id, &result);
+
+		printk(KERN_DEBUG "sync cpu %x get result %x max_id %x\n",
+			cpu_num, result, max_id);
+
+		switch (result)	{
+		case PCPU_NO_CHANGE:
+			if (pcpu)
+				present++;
+			break;
+		case PCPU_ADDED:
+		case PCPU_ONLINE_OFFLINE:
+			present++;
+		case PCPU_REMOVED:
+			break;
+		default:
+			printk(KERN_WARNING "Failed to sync pcpu %x\n",
+			  cpu_num);
+			break;
+
+		}
+		cpu_num++;
+	}
+
+	if (result < 0) {
+		list_for_each_safe(elem, tmp, &xen_pcpus.list) {
+			pcpu =3D list_entry(elem, struct pcpu, pcpu_list);
+			xen_pcpu_free(pcpu);
+		}
+		present =3D 0;
+	}
+
+	xen_pcpus.present =3D present;
+
+	put_pcpu_lock();
+
+	return 0;
+}
+
+static void xen_pcpu_dpc(struct work_struct *work)
+{
+	if (xen_sync_pcpus() < 0)
+		printk(KERN_WARNING
+			"xen_pcpu_dpc: Failed to sync pcpu information\n");
+}
+static DECLARE_WORK(xen_pcpu_work, xen_pcpu_dpc);
+
+int xen_pcpu_hotplug(int type, uint32_t apic_id)
+{
+	schedule_work(&xen_pcpu_work);
+
+	return 0;
+}
+EXPORT_SYMBOL(xen_pcpu_hotplug);
+
+static irqreturn_t xen_pcpu_interrupt(int irq, void *dev_id)
+{
+	schedule_work(&xen_pcpu_work);
+	return IRQ_HANDLED;
+}
+
+static int __init xen_pcpu_init(void)
+{
+	int err;
+
+	if (!xen_initial_domain())
+		return 0;
+
+	err =3D sysdev_class_register(&xen_pcpu_sysdev_class);
+	if (err) {
+		printk(KERN_WARNING
+			"xen_pcpu_init: register xen_pcpu sysdev Failed!\n");
+		return err;
+	}
+
+	INIT_LIST_HEAD(&xen_pcpus.list);
+	xen_pcpus.present =3D 0;
+
+	xen_sync_pcpus();
+	if (xen_pcpus.present > 0)
+		err =3D bind_virq_to_irqhandler(VIRQ_PCPU_STATE,
+			0, xen_pcpu_interrupt, 0, "pcpu", NULL);
+	if (err < 0)
+		printk(KERN_WARNING "xen_pcpu_init: "
+			"Failed to bind pcpu_state virq\n"
+			"You will lost latest information! \n");
+	return err;
+}
+
+arch_initcall(xen_pcpu_init);
diff --git a/include/xen/interface/platform.h b/include/xen/interface/platf=
orm.h
index c168468..47ffe16 100644
--- a/include/xen/interface/platform.h
+++ b/include/xen/interface/platform.h
@@ -297,6 +297,31 @@ struct xenpf_set_processor_pminfo {
 };
 DEFINE_GUEST_HANDLE_STRUCT(xenpf_set_processor_pminfo);
=20
+#define XENPF_get_cpuinfo 55
+struct xenpf_pcpuinfo {
+	/* IN */
+	uint32_t xen_cpuid;
+	/* OUT */
+	/* The maxium cpu_id that is present */
+	uint32_t max_present;
+#define XEN_PCPU_FLAGS_ONLINE   1
+	/* Correponding xen_cpuid is not present*/
+#define XEN_PCPU_FLAGS_INVALID  2
+	uint32_t flags;
+	uint32_t apic_id;
+	uint32_t acpi_id;
+};
+typedef struct xenpf_pcpuinfo xenpf_pcpuinfo_t;
+DEFINE_GUEST_HANDLE_STRUCT(xenpf_pcpuinfo_t);
+
+#define XENPF_cpu_online    56
+#define XENPF_cpu_offline   57
+struct xenpf_cpu_ol {
+    uint32_t cpuid;
+};
+typedef struct xenpf_cpu_ol xenpf_cpu_ol_t;
+DEFINE_GUEST_HANDLE_STRUCT(xenpf_cpu_ol_t);
+
 struct xen_platform_op {
 	uint32_t cmd;
 	uint32_t interface_version; /* XENPF_INTERFACE_VERSION */
@@ -312,9 +337,12 @@ struct xen_platform_op {
 		struct xenpf_change_freq       change_freq;
 		struct xenpf_getidletime       getidletime;
 		struct xenpf_set_processor_pminfo set_pminfo;
+		struct xenpf_pcpuinfo          pcpu_info;
+		struct xenpf_cpu_ol            cpu_ol;
 		uint8_t                        pad[128];
 	} u;
 };
+typedef struct xen_platform_op xen_platform_op_t;
 DEFINE_GUEST_HANDLE_STRUCT(xen_platform_op_t);
=20
 #endif /* __XEN_PUBLIC_PLATFORM_H__ */
diff --git a/include/xen/interface/xen.h b/include/xen/interface/xen.h
index 6a6e914..5a91c66 100644
--- a/include/xen/interface/xen.h
+++ b/include/xen/interface/xen.h
@@ -80,6 +80,7 @@
 #define VIRQ_CONSOLE    2  /* (DOM0) Bytes received on emergency console. =
*/
 #define VIRQ_DOM_EXC    3  /* (DOM0) Exceptional event for some domain.   =
*/
 #define VIRQ_DEBUGGER   6  /* (DOM0) A domain has paused for debugging.   =
*/
+#define VIRQ_PCPU_STATE 9  /* (DOM0) PCPU state changed                   =
*/
=20
 /* Architecture-specific VIRQ definitions. */
 #define VIRQ_ARCH_0    16
diff --git a/include/xen/pcpu.h b/include/xen/pcpu.h
new file mode 100644
index 0000000..7e8f9d1
--- /dev/null
+++ b/include/xen/pcpu.h
@@ -0,0 +1,32 @@
+#ifndef _XEN_PCPU_H
+#define _XEN_PCPU_H
+
+#include <xen/interface/platform.h>
+#include <linux/sysdev.h>
+
+extern int xen_pcpu_hotplug(int type, uint32_t apic_id);
+#define XEN_PCPU_ONLINE     0x01
+#define XEN_PCPU_OFFLINE    0x02
+#define XEN_PCPU_ADD        0x04
+#define XEN_PCPU_REMOVE     0x08
+
+struct pcpu {
+	struct list_head pcpu_list;
+	struct sys_device sysdev;
+	uint32_t xen_id;
+	uint32_t apic_id;
+	uint32_t acpi_id;
+	uint32_t flags;
+};
+
+static inline int xen_pcpu_online(uint32_t flags)
+{
+	return !!(flags & XEN_PCPU_FLAGS_ONLINE);
+}
+
+extern int register_xen_pcpu_notifier(struct notifier_block *nb);
+
+extern void unregister_xen_pcpu_notifier(struct notifier_block *nb);
+
+extern int xen_pcpu_index(uint32_t acpi_id, int is_acpiid);
+#endif
--=20
1.6.5.6

--_002_DE8DF0795D48FD4CA783C40EC82923358A24SHSMSX101ccrcorpint_
Content-Type: application/octet-stream;
	name="0003-Xen-Export-host-physical-CPU-information-to-dom0.patch"
Content-Description: 0003-Xen-Export-host-physical-CPU-information-to-dom0.patch
Content-Disposition: attachment;
	filename="0003-Xen-Export-host-physical-CPU-information-to-dom0.patch";
	size=15036; creation-date="Wed, 14 Dec 2011 15:20:15 GMT";
	modification-date="Wed, 14 Dec 2011 15:03:34 GMT"
Content-Transfer-Encoding: base64

RnJvbSAwNDE1MWFhMThiNDhhNDUyY2M5ZDA2OTZmMzZhYTk2YzY5MGNhMDExIE1vbiBTZXAgMTcg
MDA6MDA6MDAgMjAwMQpGcm9tOiBMaXUgSmluc29uZyA8amluc29uZy5saXVAaW50ZWwuY29tPgpE
YXRlOiBUaHUsIDggRGVjIDIwMTEgMjI6Mjg6MDcgKzA4MDAKU3ViamVjdDogW1BBVENIIDAzLzEw
XSBYZW46IEV4cG9ydCBob3N0IHBoeXNpY2FsIENQVSBpbmZvcm1hdGlvbiB0byBkb20wCgpUaGlz
IHBhdGNoIHJlYmFzZWQgZnJvbSBKZXJlbXkncyBwdm9wcyBjb21taXQKM2IzNGNkMTk2MjdjNmUx
OTFiMTVmZDZjYjU5Zjk5N2I4ZGIyMWUxOSBhbmQKNjgzMjAzMjNhNTFjMjM3OGFjYTQzM2M3NjE1
N2Q5ZTY2MTA0ZmYxZQoKVGhpcyBwYXRjaCBleHBvc2UgaG9zdCdzIHBoeXNpY2FsIENQVSBpbmZv
cm1hdGlvbiB0byBkb20wIGluIHN5c2ZzLCBzbwp0aGF0IGRvbTAncyBtYW5hZ2VtZW50IHRvb2xz
IGNhbiBjb250cm9sIHRoZSBwaHlzaWNhbCBDUFUgaWYgbmVlZGVkLgoKSXQgYWxzbyBwcm92aWRl
cyBpbnRlcmZhY2UgaW4gc3lzZnMgdG8gbG9naWNhbCBvbmxpbmUvb2ZmbGluZSBhIHBoeXNpY2Fs
IENQVS4KCk5vdGljZTogVGhlIGluZm9ybWF0aW9uIGluIGRvbTAgaXMgc3luY2VkIHdpdGggeGVu
IGh5cGVydmlzb3IgYXN5bmNocm9ub3VzbHkuCgpTaWduZWQtb2ZmLWJ5OiBMaXUsIEppbnNvbmcg
PGppbnNvbmcubGl1QGludGVsLmNvbT4KU2lnbmVkLW9mZi1ieTogSmlhbmcsIFl1bmhvbmcgPHl1
bmhvbmcuamlhbmdAaW50ZWwuY29tPgpTaWduZWQtb2ZmLWJ5OiBKZXJlbXkgRml0emhhcmRpbmdl
IDxqZXJlbXkuZml0emhhcmRpbmdlQGNpdHJpeC5jb20+Ci0tLQogZHJpdmVycy94ZW4vTWFrZWZp
bGUgICAgICAgICAgICAgfCAgICAyICstCiBkcml2ZXJzL3hlbi9wY3B1LmMgICAgICAgICAgICAg
ICB8ICA0NTIgKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysKIGluY2x1ZGUv
eGVuL2ludGVyZmFjZS9wbGF0Zm9ybS5oIHwgICAyOCArKysKIGluY2x1ZGUveGVuL2ludGVyZmFj
ZS94ZW4uaCAgICAgIHwgICAgMSArCiBpbmNsdWRlL3hlbi9wY3B1LmggICAgICAgICAgICAgICB8
ICAgMzIgKysrCiA1IGZpbGVzIGNoYW5nZWQsIDUxNCBpbnNlcnRpb25zKCspLCAxIGRlbGV0aW9u
cygtKQogY3JlYXRlIG1vZGUgMTAwNjQ0IGRyaXZlcnMveGVuL3BjcHUuYwogY3JlYXRlIG1vZGUg
MTAwNjQ0IGluY2x1ZGUveGVuL3BjcHUuaAoKZGlmZiAtLWdpdCBhL2RyaXZlcnMveGVuL01ha2Vm
aWxlIGIvZHJpdmVycy94ZW4vTWFrZWZpbGUKaW5kZXggNDA1Y2NlOS4uYWVkYWY0OCAxMDA2NDQK
LS0tIGEvZHJpdmVycy94ZW4vTWFrZWZpbGUKKysrIGIvZHJpdmVycy94ZW4vTWFrZWZpbGUKQEAg
LTEsNCArMSw0IEBACi1vYmoteQkrPSBncmFudC10YWJsZS5vIGZlYXR1cmVzLm8gZXZlbnRzLm8g
bWFuYWdlLm8gYmFsbG9vbi5vCitvYmoteQkrPSBncmFudC10YWJsZS5vIGZlYXR1cmVzLm8gZXZl
bnRzLm8gbWFuYWdlLm8gYmFsbG9vbi5vIHBjcHUubwogb2JqLXkJKz0geGVuYnVzLwogCiBub3N0
YWNrcCA6PSAkKGNhbGwgY2Mtb3B0aW9uLCAtZm5vLXN0YWNrLXByb3RlY3RvcikKZGlmZiAtLWdp
dCBhL2RyaXZlcnMveGVuL3BjcHUuYyBiL2RyaXZlcnMveGVuL3BjcHUuYwpuZXcgZmlsZSBtb2Rl
IDEwMDY0NAppbmRleCAwMDAwMDAwLi42ZDFhNzcwCi0tLSAvZGV2L251bGwKKysrIGIvZHJpdmVy
cy94ZW4vcGNwdS5jCkBAIC0wLDAgKzEsNDUyIEBACisvKgorICogcGNwdS5jIC0gbWFuYWdlbWVu
dCBwaHlzaWNhbCBjcHUgaW4gZG9tMCBlbnZpcm9ubWVudAorICovCisjaW5jbHVkZSA8bGludXgv
aW50ZXJydXB0Lmg+CisjaW5jbHVkZSA8bGludXgvc3BpbmxvY2suaD4KKyNpbmNsdWRlIDxhc20v
eGVuL2h5cGVydmlzb3IuaD4KKyNpbmNsdWRlIDxhc20veGVuL2h5cGVyY2FsbC5oPgorI2luY2x1
ZGUgPGxpbnV4L2NwdS5oPgorI2luY2x1ZGUgPHhlbi94ZW5idXMuaD4KKyNpbmNsdWRlIDx4ZW4v
cGNwdS5oPgorI2luY2x1ZGUgPHhlbi9ldmVudHMuaD4KKyNpbmNsdWRlIDx4ZW4vYWNwaS5oPgor
CitzdGF0aWMgc3RydWN0IHN5c2Rldl9jbGFzcyB4ZW5fcGNwdV9zeXNkZXZfY2xhc3MgPSB7CisJ
Lm5hbWUgPSAieGVuX3BjcHUiLAorfTsKKworc3RhdGljIERFRklORV9NVVRFWCh4ZW5fcGNwdV9s
b2NrKTsKK3N0YXRpYyBSQVdfTk9USUZJRVJfSEVBRCh4ZW5fcGNwdV9jaGFpbik7CisKKy8qIE5v
IG5lZWQgZm9yIGlycSBkaXNhYmxlIHNpbmNlIGhvdHBsdWcgbm90aWZ5IGlzIGluIHdvcmtxdWV1
ZSBjb250ZXh0ICovCisjZGVmaW5lIGdldF9wY3B1X2xvY2soKSBtdXRleF9sb2NrKCZ4ZW5fcGNw
dV9sb2NrKTsKKyNkZWZpbmUgcHV0X3BjcHVfbG9jaygpIG11dGV4X3VubG9jaygmeGVuX3BjcHVf
bG9jayk7CisKK3N0cnVjdCB4ZW5fcGNwdXMgeworCXN0cnVjdCBsaXN0X2hlYWQgbGlzdDsKKwlp
bnQgcHJlc2VudDsKK307CitzdGF0aWMgc3RydWN0IHhlbl9wY3B1cyB4ZW5fcGNwdXM7CisKK2lu
dCByZWdpc3Rlcl94ZW5fcGNwdV9ub3RpZmllcihzdHJ1Y3Qgbm90aWZpZXJfYmxvY2sgKm5iKQor
eworCWludCByZXQ7CisKKwkvKiBBbGwgcmVmZXIgdG8gdGhlIGNoYWluIG5vdGlmaWVyIGlzIHBy
b3RlY3RlZCBieSB0aGUgcGNwdV9sb2NrICovCisJZ2V0X3BjcHVfbG9jaygpOworCXJldCA9IHJh
d19ub3RpZmllcl9jaGFpbl9yZWdpc3RlcigmeGVuX3BjcHVfY2hhaW4sIG5iKTsKKwlwdXRfcGNw
dV9sb2NrKCk7CisJcmV0dXJuIHJldDsKK30KK0VYUE9SVF9TWU1CT0xfR1BMKHJlZ2lzdGVyX3hl
bl9wY3B1X25vdGlmaWVyKTsKKwordm9pZCB1bnJlZ2lzdGVyX3hlbl9wY3B1X25vdGlmaWVyKHN0
cnVjdCBub3RpZmllcl9ibG9jayAqbmIpCit7CisJZ2V0X3BjcHVfbG9jaygpOworCXJhd19ub3Rp
Zmllcl9jaGFpbl91bnJlZ2lzdGVyKCZ4ZW5fcGNwdV9jaGFpbiwgbmIpOworCXB1dF9wY3B1X2xv
Y2soKTsKK30KK0VYUE9SVF9TWU1CT0xfR1BMKHVucmVnaXN0ZXJfeGVuX3BjcHVfbm90aWZpZXIp
OworCitzdGF0aWMgaW50IHhlbl9wY3B1X2Rvd24odWludDMyX3QgeGVuX2lkKQoreworCWludCBy
ZXQ7CisJeGVuX3BsYXRmb3JtX29wX3Qgb3AgPSB7CisJCS5jbWQJCQk9IFhFTlBGX2NwdV9vZmZs
aW5lLAorCQkuaW50ZXJmYWNlX3ZlcnNpb24JPSBYRU5QRl9JTlRFUkZBQ0VfVkVSU0lPTiwKKwkJ
LnUuY3B1X29sLmNwdWlkCT0geGVuX2lkLAorCX07CisKKwlyZXQgPSBIWVBFUlZJU09SX2RvbTBf
b3AoJm9wKTsKKwlyZXR1cm4gcmV0OworfQorCitzdGF0aWMgaW50IHhlbl9wY3B1X3VwKHVpbnQz
Ml90IHhlbl9pZCkKK3sKKwlpbnQgcmV0OworCXhlbl9wbGF0Zm9ybV9vcF90IG9wID0geworCQku
Y21kCQkJPSBYRU5QRl9jcHVfb25saW5lLAorCQkuaW50ZXJmYWNlX3ZlcnNpb24JPSBYRU5QRl9J
TlRFUkZBQ0VfVkVSU0lPTiwKKwkJLnUuY3B1X29sLmNwdWlkCT0geGVuX2lkLAorCX07CisKKwly
ZXQgPSBIWVBFUlZJU09SX2RvbTBfb3AoJm9wKTsKKwlyZXR1cm4gcmV0OworfQorCitzdGF0aWMg
c3NpemVfdCBzaG93X29ubGluZShzdHJ1Y3Qgc3lzX2RldmljZSAqZGV2LAorCQkJc3RydWN0IHN5
c2Rldl9hdHRyaWJ1dGUgKmF0dHIsCisJCQljaGFyICpidWYpCit7CisJc3RydWN0IHBjcHUgKmNw
dSA9IGNvbnRhaW5lcl9vZihkZXYsIHN0cnVjdCBwY3B1LCBzeXNkZXYpOworCisJcmV0dXJuIHNw
cmludGYoYnVmLCAiJXVcbiIsICEhKGNwdS0+ZmxhZ3MgJiBYRU5fUENQVV9GTEFHU19PTkxJTkUp
KTsKK30KKworc3RhdGljIHNzaXplX3QgX19yZWYgc3RvcmVfb25saW5lKHN0cnVjdCBzeXNfZGV2
aWNlICpkZXYsCisJCQkJICBzdHJ1Y3Qgc3lzZGV2X2F0dHJpYnV0ZSAqYXR0ciwKKwkJCQkgIGNv
bnN0IGNoYXIgKmJ1Ziwgc2l6ZV90IGNvdW50KQoreworCXN0cnVjdCBwY3B1ICpjcHUgPSBjb250
YWluZXJfb2YoZGV2LCBzdHJ1Y3QgcGNwdSwgc3lzZGV2KTsKKwlzc2l6ZV90IHJldDsKKworCXN3
aXRjaCAoYnVmWzBdKSB7CisJY2FzZSAnMCc6CisJCXJldCA9IHhlbl9wY3B1X2Rvd24oY3B1LT54
ZW5faWQpOworCQlicmVhazsKKwljYXNlICcxJzoKKwkJcmV0ID0geGVuX3BjcHVfdXAoY3B1LT54
ZW5faWQpOworCQlicmVhazsKKwlkZWZhdWx0OgorCQlyZXQgPSAtRUlOVkFMOworCX0KKworCWlm
IChyZXQgPj0gMCkKKwkJcmV0ID0gY291bnQ7CisJcmV0dXJuIHJldDsKK30KKworc3RhdGljIFNZ
U0RFVl9BVFRSKG9ubGluZSwgMDY0NCwgc2hvd19vbmxpbmUsIHN0b3JlX29ubGluZSk7CisKK3N0
YXRpYyBzc2l6ZV90IHNob3dfYXBpY2lkKHN0cnVjdCBzeXNfZGV2aWNlICpkZXYsCisJCQlzdHJ1
Y3Qgc3lzZGV2X2F0dHJpYnV0ZSAqYXR0ciwKKwkJCWNoYXIgKmJ1ZikKK3sKKwlzdHJ1Y3QgcGNw
dSAqY3B1ID0gY29udGFpbmVyX29mKGRldiwgc3RydWN0IHBjcHUsIHN5c2Rldik7CisKKwlyZXR1
cm4gc3ByaW50ZihidWYsICIldVxuIiwgY3B1LT5hcGljX2lkKTsKK30KKworc3RhdGljIHNzaXpl
X3Qgc2hvd19hY3BpaWQoc3RydWN0IHN5c19kZXZpY2UgKmRldiwKKwkJCXN0cnVjdCBzeXNkZXZf
YXR0cmlidXRlICphdHRyLAorCQkJY2hhciAqYnVmKQoreworCXN0cnVjdCBwY3B1ICpjcHUgPSBj
b250YWluZXJfb2YoZGV2LCBzdHJ1Y3QgcGNwdSwgc3lzZGV2KTsKKworCXJldHVybiBzcHJpbnRm
KGJ1ZiwgIiV1XG4iLCBjcHUtPmFjcGlfaWQpOworfQorc3RhdGljIFNZU0RFVl9BVFRSKGFwaWNf
aWQsIDA0NDQsIHNob3dfYXBpY2lkLCBOVUxMKTsKK3N0YXRpYyBTWVNERVZfQVRUUihhY3BpX2lk
LCAwNDQ0LCBzaG93X2FjcGlpZCwgTlVMTCk7CisKK3N0YXRpYyBpbnQgeGVuX3BjcHVfZnJlZShz
dHJ1Y3QgcGNwdSAqcGNwdSkKK3sKKwlpZiAoIXBjcHUpCisJCXJldHVybiAwOworCisJc3lzZGV2
X3JlbW92ZV9maWxlKCZwY3B1LT5zeXNkZXYsICZhdHRyX29ubGluZSk7CisJc3lzZGV2X3VucmVn
aXN0ZXIoJnBjcHUtPnN5c2Rldik7CisJbGlzdF9kZWwoJnBjcHUtPnBjcHVfbGlzdCk7CisJa2Zy
ZWUocGNwdSk7CisKKwlyZXR1cm4gMDsKK30KKworc3RhdGljIGlubGluZSBpbnQgc2FtZV9wY3B1
KHN0cnVjdCB4ZW5wZl9wY3B1aW5mbyAqaW5mbywKKwkJCSAgICBzdHJ1Y3QgcGNwdSAqcGNwdSkK
K3sKKwlyZXR1cm4gKHBjcHUtPmFwaWNfaWQgPT0gaW5mby0+YXBpY19pZCkgJiYKKwkJKHBjcHUt
Pnhlbl9pZCA9PSBpbmZvLT54ZW5fY3B1aWQpOworfQorCisvKgorICogUmV0dXJuIDEgaWYgb25s
aW5lIHN0YXR1cyBjaGFuZ2VkCisgKi8KK3N0YXRpYyBpbnQgeGVuX3BjcHVfb25saW5lX2NoZWNr
KHN0cnVjdCB4ZW5wZl9wY3B1aW5mbyAqaW5mbywKKwkJCQkgc3RydWN0IHBjcHUgKnBjcHUpCit7
CisJaW50IHJlc3VsdCA9IDA7CisKKwlpZiAoaW5mby0+eGVuX2NwdWlkICE9IHBjcHUtPnhlbl9p
ZCkKKwkJcmV0dXJuIDA7CisKKwlpZiAoeGVuX3BjcHVfb25saW5lKGluZm8tPmZsYWdzKSAmJiAh
eGVuX3BjcHVfb25saW5lKHBjcHUtPmZsYWdzKSkgeworCQkvKiB0aGUgcGNwdSBpcyBvbmxpbmVk
ICovCisJCXBjcHUtPmZsYWdzIHw9IFhFTl9QQ1BVX0ZMQUdTX09OTElORTsKKwkJa29iamVjdF91
ZXZlbnQoJnBjcHUtPnN5c2Rldi5rb2JqLCBLT0JKX09OTElORSk7CisJCXJhd19ub3RpZmllcl9j
YWxsX2NoYWluKCZ4ZW5fcGNwdV9jaGFpbiwKKwkJCVhFTl9QQ1BVX09OTElORSwgKHZvaWQgKiko
bG9uZylwY3B1LT54ZW5faWQpOworCQlyZXN1bHQgPSAxOworCX0gZWxzZSBpZiAoIXhlbl9wY3B1
X29ubGluZShpbmZvLT5mbGFncykgJiYKKwkJIHhlbl9wY3B1X29ubGluZShwY3B1LT5mbGFncykp
ICB7CisJCS8qIFRoZSBwY3B1IGlzIG9mZmxpbmVkIG5vdyAqLworCQlwY3B1LT5mbGFncyAmPSB+
WEVOX1BDUFVfRkxBR1NfT05MSU5FOworCQlrb2JqZWN0X3VldmVudCgmcGNwdS0+c3lzZGV2Lmtv
YmosIEtPQkpfT0ZGTElORSk7CisJCXJhd19ub3RpZmllcl9jYWxsX2NoYWluKCZ4ZW5fcGNwdV9j
aGFpbiwKKwkJCVhFTl9QQ1BVX09GRkxJTkUsICh2b2lkICopKGxvbmcpcGNwdS0+eGVuX2lkKTsK
KwkJcmVzdWx0ID0gMTsKKwl9CisKKwlyZXR1cm4gcmVzdWx0OworfQorCitzdGF0aWMgaW50IHBj
cHVfc3lzZGV2X2luaXQoc3RydWN0IHBjcHUgKmNwdSkKK3sKKwlpbnQgZXJyb3I7CisKKwllcnJv
ciA9IHN5c2Rldl9yZWdpc3RlcigmY3B1LT5zeXNkZXYpOworCWlmIChlcnJvcikgeworCQlwcmlu
dGsoS0VSTl9XQVJOSU5HICJ4ZW5fcGNwdV9hZGQ6IEZhaWxlZCB0byByZWdpc3RlciBwY3B1XG4i
KTsKKwkJa2ZyZWUoY3B1KTsKKwkJcmV0dXJuIC0xOworCX0KKwlzeXNkZXZfY3JlYXRlX2ZpbGUo
JmNwdS0+c3lzZGV2LCAmYXR0cl9vbmxpbmUpOworCXN5c2Rldl9jcmVhdGVfZmlsZSgmY3B1LT5z
eXNkZXYsICZhdHRyX2FwaWNfaWQpOworCXN5c2Rldl9jcmVhdGVfZmlsZSgmY3B1LT5zeXNkZXYs
ICZhdHRyX2FjcGlfaWQpOworCXJldHVybiAwOworfQorCitzdGF0aWMgc3RydWN0IHBjcHUgKmdl
dF9wY3B1KGludCB4ZW5faWQpCit7CisJc3RydWN0IHBjcHUgKnBjcHUgPSBOVUxMOworCisJbGlz
dF9mb3JfZWFjaF9lbnRyeShwY3B1LCAmeGVuX3BjcHVzLmxpc3QsIHBjcHVfbGlzdCkgeworCQlp
ZiAocGNwdS0+eGVuX2lkID09IHhlbl9pZCkKKwkJCXJldHVybiBwY3B1OworCX0KKwlyZXR1cm4g
TlVMTDsKK30KKworc3RhdGljIHN0cnVjdCBwY3B1ICppbml0X3BjcHUoc3RydWN0IHhlbnBmX3Bj
cHVpbmZvICppbmZvKQoreworCXN0cnVjdCBwY3B1ICpwY3B1OworCisJaWYgKGluZm8tPmZsYWdz
ICYgWEVOX1BDUFVfRkxBR1NfSU5WQUxJRCkKKwkJcmV0dXJuIE5VTEw7CisKKwkvKiBUaGUgUENQ
VSBpcyBqdXN0IGFkZGVkICovCisJcGNwdSA9IGt6YWxsb2Moc2l6ZW9mKHN0cnVjdCBwY3B1KSwg
R0ZQX0tFUk5FTCk7CisJaWYgKCFwY3B1KQorCQlyZXR1cm4gTlVMTDsKKworCUlOSVRfTElTVF9I
RUFEKCZwY3B1LT5wY3B1X2xpc3QpOworCXBjcHUtPnhlbl9pZCA9IGluZm8tPnhlbl9jcHVpZDsK
KwlwY3B1LT5hcGljX2lkID0gaW5mby0+YXBpY19pZDsKKwlwY3B1LT5hY3BpX2lkID0gaW5mby0+
YWNwaV9pZDsKKwlwY3B1LT5mbGFncyA9IGluZm8tPmZsYWdzOworCisJcGNwdS0+c3lzZGV2LmNs
cyA9ICZ4ZW5fcGNwdV9zeXNkZXZfY2xhc3M7CisJcGNwdS0+c3lzZGV2LmlkID0gaW5mby0+eGVu
X2NwdWlkOworCisJaWYgKHBjcHVfc3lzZGV2X2luaXQocGNwdSkpIHsKKwkJa2ZyZWUocGNwdSk7
CisJCXJldHVybiBOVUxMOworCX0KKworCWxpc3RfYWRkX3RhaWwoJnBjcHUtPnBjcHVfbGlzdCwg
Jnhlbl9wY3B1cy5saXN0KTsKKwlyYXdfbm90aWZpZXJfY2FsbF9jaGFpbigmeGVuX3BjcHVfY2hh
aW4sCisJCQkJWEVOX1BDUFVfQURELAorCQkJCSh2b2lkICopKGxvbmcpcGNwdS0+eGVuX2lkKTsK
KwlyZXR1cm4gcGNwdTsKK30KKworI2RlZmluZSBQQ1BVX05PX0NIQU5HRQkJCTAKKyNkZWZpbmUg
UENQVV9BRERFRAkJCTEKKyNkZWZpbmUgUENQVV9PTkxJTkVfT0ZGTElORQkJMgorI2RlZmluZSBQ
Q1BVX1JFTU9WRUQJCQkzCisvKgorICogQ2FsbGVyIHNob3VsZCBob2xkIHRoZSBwY3B1IGxvY2sK
KyAqIDwgMDogU29tZXRoaW5nIHdyb25nCisgKiAwOiBObyBjaGFuZ2VzCisgKiA+IDA6IFN0YXRl
IGNoYW5nZWQKKyAqLworc3RhdGljIHN0cnVjdCBwY3B1ICpfc3luY19wY3B1KGludCBjcHVfbnVt
LCBpbnQgKm1heF9pZCwgaW50ICpyZXN1bHQpCit7CisJc3RydWN0IHBjcHUgKnBjcHUgPSBOVUxM
OworCXN0cnVjdCB4ZW5wZl9wY3B1aW5mbyAqaW5mbzsKKwl4ZW5fcGxhdGZvcm1fb3BfdCBvcCA9
IHsKKwkJLmNtZCAgICAgICAgICAgID0gWEVOUEZfZ2V0X2NwdWluZm8sCisJCS5pbnRlcmZhY2Vf
dmVyc2lvbiAgPSBYRU5QRl9JTlRFUkZBQ0VfVkVSU0lPTiwKKwl9OworCWludCByZXQ7CisKKwkq
cmVzdWx0ID0gLTE7CisKKwlpbmZvID0gJm9wLnUucGNwdV9pbmZvOworCWluZm8tPnhlbl9jcHVp
ZCA9IGNwdV9udW07CisKKwlyZXQgPSBIWVBFUlZJU09SX2RvbTBfb3AoJm9wKTsKKwlpZiAocmV0
KQorCQlyZXR1cm4gTlVMTDsKKworCWlmIChtYXhfaWQpCisJCSptYXhfaWQgPSBvcC51LnBjcHVf
aW5mby5tYXhfcHJlc2VudDsKKworCXBjcHUgPSBnZXRfcGNwdShjcHVfbnVtKTsKKworCWlmIChp
bmZvLT5mbGFncyAmIFhFTl9QQ1BVX0ZMQUdTX0lOVkFMSUQpIHsKKwkJLyogVGhlIHBjcHUgaGFz
IGJlZW4gcmVtb3ZlZCAqLworCQkqcmVzdWx0ID0gUENQVV9OT19DSEFOR0U7CisJCWlmIChwY3B1
KSB7CisJCQlyYXdfbm90aWZpZXJfY2FsbF9jaGFpbigmeGVuX3BjcHVfY2hhaW4sCisJCQkgIFhF
Tl9QQ1BVX1JFTU9WRSwKKwkJCSAgKHZvaWQgKikobG9uZylwY3B1LT54ZW5faWQpOworCQkJeGVu
X3BjcHVfZnJlZShwY3B1KTsKKwkJCSpyZXN1bHQgPSBQQ1BVX1JFTU9WRUQ7CisJCX0KKwkJcmV0
dXJuIE5VTEw7CisJfQorCisKKwlpZiAoIXBjcHUpIHsKKwkJKnJlc3VsdCA9IFBDUFVfQURERUQ7
CisJCXBjcHUgPSBpbml0X3BjcHUoaW5mbyk7CisJCWlmIChwY3B1ID09IE5VTEwpIHsKKwkJCXBy
aW50ayhLRVJOX1dBUk5JTkcgIkZhaWxlZCB0byBpbml0IHBjcHUgJXhcbiIsCisJCQkgIGluZm8t
Pnhlbl9jcHVpZCk7CisJCQkgICpyZXN1bHQgPSAtMTsKKwkJfQorCX0gZWxzZSB7CisJCSpyZXN1
bHQgPSBQQ1BVX05PX0NIQU5HRTsKKwkJLyoKKwkJICogT2xkIFBDUFUgaXMgcmVwbGFjZWQgd2l0
aCBhIG5ldyBwY3B1LCB0aGlzIG1lYW5zCisJCSAqIHNldmVyYWwgdmlycSBpcyBtaXNzZWQsIHdp
bGwgaXQgaGFwcGVuPworCQkgKi8KKwkJaWYgKCFzYW1lX3BjcHUoaW5mbywgcGNwdSkpIHsKKwkJ
CXByaW50ayhLRVJOX1dBUk5JTkcgIlBjcHUgJXggY2hhbmdlZCFcbiIsCisJCQkgIHBjcHUtPnhl
bl9pZCk7CisJCQlwY3B1LT5hcGljX2lkID0gaW5mby0+YXBpY19pZDsKKwkJCXBjcHUtPmFjcGlf
aWQgPSBpbmZvLT5hY3BpX2lkOworCQl9CisJCWlmICh4ZW5fcGNwdV9vbmxpbmVfY2hlY2soaW5m
bywgcGNwdSkpCisJCQkqcmVzdWx0ID0gUENQVV9PTkxJTkVfT0ZGTElORTsKKwl9CisJcmV0dXJu
IHBjcHU7Cit9CisKK2ludCB4ZW5fcGNwdV9pbmRleCh1aW50MzJfdCBpZCwgaW50IGlzX2FjcGlp
ZCkKK3sKKwlpbnQgY3B1X251bSA9IDAsIG1heF9pZCA9IDAsIHJldDsKKwl4ZW5fcGxhdGZvcm1f
b3BfdCBvcCA9IHsKKwkJLmNtZCAgICAgICAgICAgID0gWEVOUEZfZ2V0X2NwdWluZm8sCisJCS5p
bnRlcmZhY2VfdmVyc2lvbiAgPSBYRU5QRl9JTlRFUkZBQ0VfVkVSU0lPTiwKKwl9OworCXN0cnVj
dCB4ZW5wZl9wY3B1aW5mbyAqaW5mbyA9ICZvcC51LnBjcHVfaW5mbzsKKworCWluZm8tPnhlbl9j
cHVpZCA9IDA7CisJcmV0ID0gSFlQRVJWSVNPUl9kb20wX29wKCZvcCk7CisJaWYgKHJldCkKKwkJ
cmV0dXJuIC0xOworCW1heF9pZCA9IG9wLnUucGNwdV9pbmZvLm1heF9wcmVzZW50OworCisJd2hp
bGUgKChjcHVfbnVtIDw9IG1heF9pZCkpIHsKKwkJaW5mby0+eGVuX2NwdWlkID0gY3B1X251bTsK
KwkJcmV0ID0gSFlQRVJWSVNPUl9kb20wX29wKCZvcCk7CisJCWlmIChyZXQpCisJCQljb250aW51
ZTsKKworCQlpZiAob3AudS5wY3B1X2luZm8ubWF4X3ByZXNlbnQgPiBtYXhfaWQpCisJCQltYXhf
aWQgPSBvcC51LnBjcHVfaW5mby5tYXhfcHJlc2VudDsKKwkJaWYgKGlkID09IChpc19hY3BpaWQg
PyBpbmZvLT5hY3BpX2lkIDogaW5mby0+YXBpY19pZCkpCisJCQlyZXR1cm4gY3B1X251bTsKKwkJ
Y3B1X251bSsrOworCX0KKworICAgIHJldHVybiAtMTsKK30KK0VYUE9SVF9TWU1CT0woeGVuX3Bj
cHVfaW5kZXgpOworCisvKgorICogU3luYyBkb20wJ3MgcGNwdSBpbmZvcm1hdGlvbiB3aXRoIHhl
biBoeXBlcnZpc29yJ3MKKyAqLworc3RhdGljIGludCB4ZW5fc3luY19wY3B1cyh2b2lkKQorewor
CS8qCisJICogQm9vdCBjcHUgYWx3YXlzIGhhdmUgY3B1X2lkIDAgaW4geGVuCisJICovCisJaW50
IGNwdV9udW0gPSAwLCBtYXhfaWQgPSAwLCByZXN1bHQgPSAwLCBwcmVzZW50ID0gMDsKKwlzdHJ1
Y3QgbGlzdF9oZWFkICplbGVtLCAqdG1wOworCXN0cnVjdCBwY3B1ICpwY3B1OworCisJZ2V0X3Bj
cHVfbG9jaygpOworCisJd2hpbGUgKChyZXN1bHQgPj0gMCkgJiYgKGNwdV9udW0gPD0gbWF4X2lk
KSkgeworCQlwY3B1ID0gX3N5bmNfcGNwdShjcHVfbnVtLCAmbWF4X2lkLCAmcmVzdWx0KTsKKwor
CQlwcmludGsoS0VSTl9ERUJVRyAic3luYyBjcHUgJXggZ2V0IHJlc3VsdCAleCBtYXhfaWQgJXhc
biIsCisJCQljcHVfbnVtLCByZXN1bHQsIG1heF9pZCk7CisKKwkJc3dpdGNoIChyZXN1bHQpCXsK
KwkJY2FzZSBQQ1BVX05PX0NIQU5HRToKKwkJCWlmIChwY3B1KQorCQkJCXByZXNlbnQrKzsKKwkJ
CWJyZWFrOworCQljYXNlIFBDUFVfQURERUQ6CisJCWNhc2UgUENQVV9PTkxJTkVfT0ZGTElORToK
KwkJCXByZXNlbnQrKzsKKwkJY2FzZSBQQ1BVX1JFTU9WRUQ6CisJCQlicmVhazsKKwkJZGVmYXVs
dDoKKwkJCXByaW50ayhLRVJOX1dBUk5JTkcgIkZhaWxlZCB0byBzeW5jIHBjcHUgJXhcbiIsCisJ
CQkgIGNwdV9udW0pOworCQkJYnJlYWs7CisKKwkJfQorCQljcHVfbnVtKys7CisJfQorCisJaWYg
KHJlc3VsdCA8IDApIHsKKwkJbGlzdF9mb3JfZWFjaF9zYWZlKGVsZW0sIHRtcCwgJnhlbl9wY3B1
cy5saXN0KSB7CisJCQlwY3B1ID0gbGlzdF9lbnRyeShlbGVtLCBzdHJ1Y3QgcGNwdSwgcGNwdV9s
aXN0KTsKKwkJCXhlbl9wY3B1X2ZyZWUocGNwdSk7CisJCX0KKwkJcHJlc2VudCA9IDA7CisJfQor
CisJeGVuX3BjcHVzLnByZXNlbnQgPSBwcmVzZW50OworCisJcHV0X3BjcHVfbG9jaygpOworCisJ
cmV0dXJuIDA7Cit9CisKK3N0YXRpYyB2b2lkIHhlbl9wY3B1X2RwYyhzdHJ1Y3Qgd29ya19zdHJ1
Y3QgKndvcmspCit7CisJaWYgKHhlbl9zeW5jX3BjcHVzKCkgPCAwKQorCQlwcmludGsoS0VSTl9X
QVJOSU5HCisJCQkieGVuX3BjcHVfZHBjOiBGYWlsZWQgdG8gc3luYyBwY3B1IGluZm9ybWF0aW9u
XG4iKTsKK30KK3N0YXRpYyBERUNMQVJFX1dPUksoeGVuX3BjcHVfd29yaywgeGVuX3BjcHVfZHBj
KTsKKworaW50IHhlbl9wY3B1X2hvdHBsdWcoaW50IHR5cGUsIHVpbnQzMl90IGFwaWNfaWQpCit7
CisJc2NoZWR1bGVfd29yaygmeGVuX3BjcHVfd29yayk7CisKKwlyZXR1cm4gMDsKK30KK0VYUE9S
VF9TWU1CT0woeGVuX3BjcHVfaG90cGx1Zyk7CisKK3N0YXRpYyBpcnFyZXR1cm5fdCB4ZW5fcGNw
dV9pbnRlcnJ1cHQoaW50IGlycSwgdm9pZCAqZGV2X2lkKQoreworCXNjaGVkdWxlX3dvcmsoJnhl
bl9wY3B1X3dvcmspOworCXJldHVybiBJUlFfSEFORExFRDsKK30KKworc3RhdGljIGludCBfX2lu
aXQgeGVuX3BjcHVfaW5pdCh2b2lkKQoreworCWludCBlcnI7CisKKwlpZiAoIXhlbl9pbml0aWFs
X2RvbWFpbigpKQorCQlyZXR1cm4gMDsKKworCWVyciA9IHN5c2Rldl9jbGFzc19yZWdpc3Rlcigm
eGVuX3BjcHVfc3lzZGV2X2NsYXNzKTsKKwlpZiAoZXJyKSB7CisJCXByaW50ayhLRVJOX1dBUk5J
TkcKKwkJCSJ4ZW5fcGNwdV9pbml0OiByZWdpc3RlciB4ZW5fcGNwdSBzeXNkZXYgRmFpbGVkIVxu
Iik7CisJCXJldHVybiBlcnI7CisJfQorCisJSU5JVF9MSVNUX0hFQUQoJnhlbl9wY3B1cy5saXN0
KTsKKwl4ZW5fcGNwdXMucHJlc2VudCA9IDA7CisKKwl4ZW5fc3luY19wY3B1cygpOworCWlmICh4
ZW5fcGNwdXMucHJlc2VudCA+IDApCisJCWVyciA9IGJpbmRfdmlycV90b19pcnFoYW5kbGVyKFZJ
UlFfUENQVV9TVEFURSwKKwkJCTAsIHhlbl9wY3B1X2ludGVycnVwdCwgMCwgInBjcHUiLCBOVUxM
KTsKKwlpZiAoZXJyIDwgMCkKKwkJcHJpbnRrKEtFUk5fV0FSTklORyAieGVuX3BjcHVfaW5pdDog
IgorCQkJIkZhaWxlZCB0byBiaW5kIHBjcHVfc3RhdGUgdmlycVxuIgorCQkJIllvdSB3aWxsIGxv
c3QgbGF0ZXN0IGluZm9ybWF0aW9uISBcbiIpOworCXJldHVybiBlcnI7Cit9CisKK2FyY2hfaW5p
dGNhbGwoeGVuX3BjcHVfaW5pdCk7CmRpZmYgLS1naXQgYS9pbmNsdWRlL3hlbi9pbnRlcmZhY2Uv
cGxhdGZvcm0uaCBiL2luY2x1ZGUveGVuL2ludGVyZmFjZS9wbGF0Zm9ybS5oCmluZGV4IGMxNjg0
NjguLjQ3ZmZlMTYgMTAwNjQ0Ci0tLSBhL2luY2x1ZGUveGVuL2ludGVyZmFjZS9wbGF0Zm9ybS5o
CisrKyBiL2luY2x1ZGUveGVuL2ludGVyZmFjZS9wbGF0Zm9ybS5oCkBAIC0yOTcsNiArMjk3LDMx
IEBAIHN0cnVjdCB4ZW5wZl9zZXRfcHJvY2Vzc29yX3BtaW5mbyB7CiB9OwogREVGSU5FX0dVRVNU
X0hBTkRMRV9TVFJVQ1QoeGVucGZfc2V0X3Byb2Nlc3Nvcl9wbWluZm8pOwogCisjZGVmaW5lIFhF
TlBGX2dldF9jcHVpbmZvIDU1CitzdHJ1Y3QgeGVucGZfcGNwdWluZm8geworCS8qIElOICovCisJ
dWludDMyX3QgeGVuX2NwdWlkOworCS8qIE9VVCAqLworCS8qIFRoZSBtYXhpdW0gY3B1X2lkIHRo
YXQgaXMgcHJlc2VudCAqLworCXVpbnQzMl90IG1heF9wcmVzZW50OworI2RlZmluZSBYRU5fUENQ
VV9GTEFHU19PTkxJTkUgICAxCisJLyogQ29ycmVwb25kaW5nIHhlbl9jcHVpZCBpcyBub3QgcHJl
c2VudCovCisjZGVmaW5lIFhFTl9QQ1BVX0ZMQUdTX0lOVkFMSUQgIDIKKwl1aW50MzJfdCBmbGFn
czsKKwl1aW50MzJfdCBhcGljX2lkOworCXVpbnQzMl90IGFjcGlfaWQ7Cit9OwordHlwZWRlZiBz
dHJ1Y3QgeGVucGZfcGNwdWluZm8geGVucGZfcGNwdWluZm9fdDsKK0RFRklORV9HVUVTVF9IQU5E
TEVfU1RSVUNUKHhlbnBmX3BjcHVpbmZvX3QpOworCisjZGVmaW5lIFhFTlBGX2NwdV9vbmxpbmUg
ICAgNTYKKyNkZWZpbmUgWEVOUEZfY3B1X29mZmxpbmUgICA1Nworc3RydWN0IHhlbnBmX2NwdV9v
bCB7CisgICAgdWludDMyX3QgY3B1aWQ7Cit9OwordHlwZWRlZiBzdHJ1Y3QgeGVucGZfY3B1X29s
IHhlbnBmX2NwdV9vbF90OworREVGSU5FX0dVRVNUX0hBTkRMRV9TVFJVQ1QoeGVucGZfY3B1X29s
X3QpOworCiBzdHJ1Y3QgeGVuX3BsYXRmb3JtX29wIHsKIAl1aW50MzJfdCBjbWQ7CiAJdWludDMy
X3QgaW50ZXJmYWNlX3ZlcnNpb247IC8qIFhFTlBGX0lOVEVSRkFDRV9WRVJTSU9OICovCkBAIC0z
MTIsOSArMzM3LDEyIEBAIHN0cnVjdCB4ZW5fcGxhdGZvcm1fb3AgewogCQlzdHJ1Y3QgeGVucGZf
Y2hhbmdlX2ZyZXEgICAgICAgY2hhbmdlX2ZyZXE7CiAJCXN0cnVjdCB4ZW5wZl9nZXRpZGxldGlt
ZSAgICAgICBnZXRpZGxldGltZTsKIAkJc3RydWN0IHhlbnBmX3NldF9wcm9jZXNzb3JfcG1pbmZv
IHNldF9wbWluZm87CisJCXN0cnVjdCB4ZW5wZl9wY3B1aW5mbyAgICAgICAgICBwY3B1X2luZm87
CisJCXN0cnVjdCB4ZW5wZl9jcHVfb2wgICAgICAgICAgICBjcHVfb2w7CiAJCXVpbnQ4X3QgICAg
ICAgICAgICAgICAgICAgICAgICBwYWRbMTI4XTsKIAl9IHU7CiB9OwordHlwZWRlZiBzdHJ1Y3Qg
eGVuX3BsYXRmb3JtX29wIHhlbl9wbGF0Zm9ybV9vcF90OwogREVGSU5FX0dVRVNUX0hBTkRMRV9T
VFJVQ1QoeGVuX3BsYXRmb3JtX29wX3QpOwogCiAjZW5kaWYgLyogX19YRU5fUFVCTElDX1BMQVRG
T1JNX0hfXyAqLwpkaWZmIC0tZ2l0IGEvaW5jbHVkZS94ZW4vaW50ZXJmYWNlL3hlbi5oIGIvaW5j
bHVkZS94ZW4vaW50ZXJmYWNlL3hlbi5oCmluZGV4IDZhNmU5MTQuLjVhOTFjNjYgMTAwNjQ0Ci0t
LSBhL2luY2x1ZGUveGVuL2ludGVyZmFjZS94ZW4uaAorKysgYi9pbmNsdWRlL3hlbi9pbnRlcmZh
Y2UveGVuLmgKQEAgLTgwLDYgKzgwLDcgQEAKICNkZWZpbmUgVklSUV9DT05TT0xFICAgIDIgIC8q
IChET00wKSBCeXRlcyByZWNlaXZlZCBvbiBlbWVyZ2VuY3kgY29uc29sZS4gKi8KICNkZWZpbmUg
VklSUV9ET01fRVhDICAgIDMgIC8qIChET00wKSBFeGNlcHRpb25hbCBldmVudCBmb3Igc29tZSBk
b21haW4uICAgKi8KICNkZWZpbmUgVklSUV9ERUJVR0dFUiAgIDYgIC8qIChET00wKSBBIGRvbWFp
biBoYXMgcGF1c2VkIGZvciBkZWJ1Z2dpbmcuICAgKi8KKyNkZWZpbmUgVklSUV9QQ1BVX1NUQVRF
IDkgIC8qIChET00wKSBQQ1BVIHN0YXRlIGNoYW5nZWQgICAgICAgICAgICAgICAgICAgKi8KIAog
LyogQXJjaGl0ZWN0dXJlLXNwZWNpZmljIFZJUlEgZGVmaW5pdGlvbnMuICovCiAjZGVmaW5lIFZJ
UlFfQVJDSF8wICAgIDE2CmRpZmYgLS1naXQgYS9pbmNsdWRlL3hlbi9wY3B1LmggYi9pbmNsdWRl
L3hlbi9wY3B1LmgKbmV3IGZpbGUgbW9kZSAxMDA2NDQKaW5kZXggMDAwMDAwMC4uN2U4ZjlkMQot
LS0gL2Rldi9udWxsCisrKyBiL2luY2x1ZGUveGVuL3BjcHUuaApAQCAtMCwwICsxLDMyIEBACisj
aWZuZGVmIF9YRU5fUENQVV9ICisjZGVmaW5lIF9YRU5fUENQVV9ICisKKyNpbmNsdWRlIDx4ZW4v
aW50ZXJmYWNlL3BsYXRmb3JtLmg+CisjaW5jbHVkZSA8bGludXgvc3lzZGV2Lmg+CisKK2V4dGVy
biBpbnQgeGVuX3BjcHVfaG90cGx1ZyhpbnQgdHlwZSwgdWludDMyX3QgYXBpY19pZCk7CisjZGVm
aW5lIFhFTl9QQ1BVX09OTElORSAgICAgMHgwMQorI2RlZmluZSBYRU5fUENQVV9PRkZMSU5FICAg
IDB4MDIKKyNkZWZpbmUgWEVOX1BDUFVfQUREICAgICAgICAweDA0CisjZGVmaW5lIFhFTl9QQ1BV
X1JFTU9WRSAgICAgMHgwOAorCitzdHJ1Y3QgcGNwdSB7CisJc3RydWN0IGxpc3RfaGVhZCBwY3B1
X2xpc3Q7CisJc3RydWN0IHN5c19kZXZpY2Ugc3lzZGV2OworCXVpbnQzMl90IHhlbl9pZDsKKwl1
aW50MzJfdCBhcGljX2lkOworCXVpbnQzMl90IGFjcGlfaWQ7CisJdWludDMyX3QgZmxhZ3M7Cit9
OworCitzdGF0aWMgaW5saW5lIGludCB4ZW5fcGNwdV9vbmxpbmUodWludDMyX3QgZmxhZ3MpCit7
CisJcmV0dXJuICEhKGZsYWdzICYgWEVOX1BDUFVfRkxBR1NfT05MSU5FKTsKK30KKworZXh0ZXJu
IGludCByZWdpc3Rlcl94ZW5fcGNwdV9ub3RpZmllcihzdHJ1Y3Qgbm90aWZpZXJfYmxvY2sgKm5i
KTsKKworZXh0ZXJuIHZvaWQgdW5yZWdpc3Rlcl94ZW5fcGNwdV9ub3RpZmllcihzdHJ1Y3Qgbm90
aWZpZXJfYmxvY2sgKm5iKTsKKworZXh0ZXJuIGludCB4ZW5fcGNwdV9pbmRleCh1aW50MzJfdCBh
Y3BpX2lkLCBpbnQgaXNfYWNwaWlkKTsKKyNlbmRpZgotLSAKMS42LjUuNgoK

--_002_DE8DF0795D48FD4CA783C40EC82923358A24SHSMSX101ccrcorpint_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--_002_DE8DF0795D48FD4CA783C40EC82923358A24SHSMSX101ccrcorpint_--


From xen-devel-bounces@lists.xensource.com Thu Dec 22 10:05:05 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 Dec 2011 10:05:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdfWA-0004vk-As; Thu, 22 Dec 2011 10:04:54 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1RdfW8-0004um-Aa
	for xen-devel@lists.xensource.com; Thu, 22 Dec 2011 10:04:52 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1324548282!6501628!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMjkwMjgz\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22796 invoked from network); 22 Dec 2011 10:04:44 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-2.tower-174.messagelabs.com with SMTP;
	22 Dec 2011 10:04:44 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga101.jf.intel.com with ESMTP; 22 Dec 2011 02:04:41 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.67,352,1309762800"; d="scan'208,223";a="89281017"
Received: from pgsmsx602.gar.corp.intel.com ([10.221.43.81])
	by orsmga001.jf.intel.com with ESMTP; 22 Dec 2011 02:04:40 -0800
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	pgsmsx602.gar.corp.intel.com (10.221.43.81) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Thu, 22 Dec 2011 18:04:33 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.38]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.199]) with mapi id
	14.01.0355.002; Thu, 22 Dec 2011 18:04:32 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: "konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Thread-Topic: [PATCH 03/10] Xen: Export host physical CPU information to dom0
Thread-Index: AczAkRjYvN5ypRb3S/isdZfI5BO1QQ==
Date: Thu, 22 Dec 2011 10:04:31 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC82923358A24@SHSMSX101.ccr.corp.intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
Content-Type: multipart/mixed;
	boundary="_002_DE8DF0795D48FD4CA783C40EC82923358A24SHSMSX101ccrcorpint_"
MIME-Version: 1.0
Cc: "Jiang, Yunhong" <yunhong.jiang@intel.com>,
	"jeremy.fitzhardinge@citrix.com" <jeremy.fitzhardinge@citrix.com>
Subject: [Xen-devel] [PATCH 03/10] Xen: Export host physical CPU information
	to dom0
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--_002_DE8DF0795D48FD4CA783C40EC82923358A24SHSMSX101ccrcorpint_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

>From 04151aa18b48a452cc9d0696f36aa96c690ca011 Mon Sep 17 00:00:00 2001
From: Liu Jinsong <jinsong.liu@intel.com>
Date: Thu, 8 Dec 2011 22:28:07 +0800
Subject: [PATCH 03/10] Xen: Export host physical CPU information to dom0

This patch rebased from Jeremy's pvops commit
3b34cd19627c6e191b15fd6cb59f997b8db21e19 and
68320323a51c2378aca433c76157d9e66104ff1e

This patch expose host's physical CPU information to dom0 in sysfs, so
that dom0's management tools can control the physical CPU if needed.

It also provides interface in sysfs to logical online/offline a physical CP=
U.

Notice: The information in dom0 is synced with xen hypervisor asynchronousl=
y.

Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
Signed-off-by: Jiang, Yunhong <yunhong.jiang@intel.com>
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
---
 drivers/xen/Makefile             |    2 +-
 drivers/xen/pcpu.c               |  452 ++++++++++++++++++++++++++++++++++=
++++
 include/xen/interface/platform.h |   28 +++
 include/xen/interface/xen.h      |    1 +
 include/xen/pcpu.h               |   32 +++
 5 files changed, 514 insertions(+), 1 deletions(-)
 create mode 100644 drivers/xen/pcpu.c
 create mode 100644 include/xen/pcpu.h

diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
index 405cce9..aedaf48 100644
--- a/drivers/xen/Makefile
+++ b/drivers/xen/Makefile
@@ -1,4 +1,4 @@
-obj-y	+=3D grant-table.o features.o events.o manage.o balloon.o
+obj-y	+=3D grant-table.o features.o events.o manage.o balloon.o pcpu.o
 obj-y	+=3D xenbus/
=20
 nostackp :=3D $(call cc-option, -fno-stack-protector)
diff --git a/drivers/xen/pcpu.c b/drivers/xen/pcpu.c
new file mode 100644
index 0000000..6d1a770
--- /dev/null
+++ b/drivers/xen/pcpu.c
@@ -0,0 +1,452 @@
+/*
+ * pcpu.c - management physical cpu in dom0 environment
+ */
+#include <linux/interrupt.h>
+#include <linux/spinlock.h>
+#include <asm/xen/hypervisor.h>
+#include <asm/xen/hypercall.h>
+#include <linux/cpu.h>
+#include <xen/xenbus.h>
+#include <xen/pcpu.h>
+#include <xen/events.h>
+#include <xen/acpi.h>
+
+static struct sysdev_class xen_pcpu_sysdev_class =3D {
+	.name =3D "xen_pcpu",
+};
+
+static DEFINE_MUTEX(xen_pcpu_lock);
+static RAW_NOTIFIER_HEAD(xen_pcpu_chain);
+
+/* No need for irq disable since hotplug notify is in workqueue context */
+#define get_pcpu_lock() mutex_lock(&xen_pcpu_lock);
+#define put_pcpu_lock() mutex_unlock(&xen_pcpu_lock);
+
+struct xen_pcpus {
+	struct list_head list;
+	int present;
+};
+static struct xen_pcpus xen_pcpus;
+
+int register_xen_pcpu_notifier(struct notifier_block *nb)
+{
+	int ret;
+
+	/* All refer to the chain notifier is protected by the pcpu_lock */
+	get_pcpu_lock();
+	ret =3D raw_notifier_chain_register(&xen_pcpu_chain, nb);
+	put_pcpu_lock();
+	return ret;
+}
+EXPORT_SYMBOL_GPL(register_xen_pcpu_notifier);
+
+void unregister_xen_pcpu_notifier(struct notifier_block *nb)
+{
+	get_pcpu_lock();
+	raw_notifier_chain_unregister(&xen_pcpu_chain, nb);
+	put_pcpu_lock();
+}
+EXPORT_SYMBOL_GPL(unregister_xen_pcpu_notifier);
+
+static int xen_pcpu_down(uint32_t xen_id)
+{
+	int ret;
+	xen_platform_op_t op =3D {
+		.cmd			=3D XENPF_cpu_offline,
+		.interface_version	=3D XENPF_INTERFACE_VERSION,
+		.u.cpu_ol.cpuid	=3D xen_id,
+	};
+
+	ret =3D HYPERVISOR_dom0_op(&op);
+	return ret;
+}
+
+static int xen_pcpu_up(uint32_t xen_id)
+{
+	int ret;
+	xen_platform_op_t op =3D {
+		.cmd			=3D XENPF_cpu_online,
+		.interface_version	=3D XENPF_INTERFACE_VERSION,
+		.u.cpu_ol.cpuid	=3D xen_id,
+	};
+
+	ret =3D HYPERVISOR_dom0_op(&op);
+	return ret;
+}
+
+static ssize_t show_online(struct sys_device *dev,
+			struct sysdev_attribute *attr,
+			char *buf)
+{
+	struct pcpu *cpu =3D container_of(dev, struct pcpu, sysdev);
+
+	return sprintf(buf, "%u\n", !!(cpu->flags & XEN_PCPU_FLAGS_ONLINE));
+}
+
+static ssize_t __ref store_online(struct sys_device *dev,
+				  struct sysdev_attribute *attr,
+				  const char *buf, size_t count)
+{
+	struct pcpu *cpu =3D container_of(dev, struct pcpu, sysdev);
+	ssize_t ret;
+
+	switch (buf[0]) {
+	case '0':
+		ret =3D xen_pcpu_down(cpu->xen_id);
+		break;
+	case '1':
+		ret =3D xen_pcpu_up(cpu->xen_id);
+		break;
+	default:
+		ret =3D -EINVAL;
+	}
+
+	if (ret >=3D 0)
+		ret =3D count;
+	return ret;
+}
+
+static SYSDEV_ATTR(online, 0644, show_online, store_online);
+
+static ssize_t show_apicid(struct sys_device *dev,
+			struct sysdev_attribute *attr,
+			char *buf)
+{
+	struct pcpu *cpu =3D container_of(dev, struct pcpu, sysdev);
+
+	return sprintf(buf, "%u\n", cpu->apic_id);
+}
+
+static ssize_t show_acpiid(struct sys_device *dev,
+			struct sysdev_attribute *attr,
+			char *buf)
+{
+	struct pcpu *cpu =3D container_of(dev, struct pcpu, sysdev);
+
+	return sprintf(buf, "%u\n", cpu->acpi_id);
+}
+static SYSDEV_ATTR(apic_id, 0444, show_apicid, NULL);
+static SYSDEV_ATTR(acpi_id, 0444, show_acpiid, NULL);
+
+static int xen_pcpu_free(struct pcpu *pcpu)
+{
+	if (!pcpu)
+		return 0;
+
+	sysdev_remove_file(&pcpu->sysdev, &attr_online);
+	sysdev_unregister(&pcpu->sysdev);
+	list_del(&pcpu->pcpu_list);
+	kfree(pcpu);
+
+	return 0;
+}
+
+static inline int same_pcpu(struct xenpf_pcpuinfo *info,
+			    struct pcpu *pcpu)
+{
+	return (pcpu->apic_id =3D=3D info->apic_id) &&
+		(pcpu->xen_id =3D=3D info->xen_cpuid);
+}
+
+/*
+ * Return 1 if online status changed
+ */
+static int xen_pcpu_online_check(struct xenpf_pcpuinfo *info,
+				 struct pcpu *pcpu)
+{
+	int result =3D 0;
+
+	if (info->xen_cpuid !=3D pcpu->xen_id)
+		return 0;
+
+	if (xen_pcpu_online(info->flags) && !xen_pcpu_online(pcpu->flags)) {
+		/* the pcpu is onlined */
+		pcpu->flags |=3D XEN_PCPU_FLAGS_ONLINE;
+		kobject_uevent(&pcpu->sysdev.kobj, KOBJ_ONLINE);
+		raw_notifier_call_chain(&xen_pcpu_chain,
+			XEN_PCPU_ONLINE, (void *)(long)pcpu->xen_id);
+		result =3D 1;
+	} else if (!xen_pcpu_online(info->flags) &&
+		 xen_pcpu_online(pcpu->flags))  {
+		/* The pcpu is offlined now */
+		pcpu->flags &=3D ~XEN_PCPU_FLAGS_ONLINE;
+		kobject_uevent(&pcpu->sysdev.kobj, KOBJ_OFFLINE);
+		raw_notifier_call_chain(&xen_pcpu_chain,
+			XEN_PCPU_OFFLINE, (void *)(long)pcpu->xen_id);
+		result =3D 1;
+	}
+
+	return result;
+}
+
+static int pcpu_sysdev_init(struct pcpu *cpu)
+{
+	int error;
+
+	error =3D sysdev_register(&cpu->sysdev);
+	if (error) {
+		printk(KERN_WARNING "xen_pcpu_add: Failed to register pcpu\n");
+		kfree(cpu);
+		return -1;
+	}
+	sysdev_create_file(&cpu->sysdev, &attr_online);
+	sysdev_create_file(&cpu->sysdev, &attr_apic_id);
+	sysdev_create_file(&cpu->sysdev, &attr_acpi_id);
+	return 0;
+}
+
+static struct pcpu *get_pcpu(int xen_id)
+{
+	struct pcpu *pcpu =3D NULL;
+
+	list_for_each_entry(pcpu, &xen_pcpus.list, pcpu_list) {
+		if (pcpu->xen_id =3D=3D xen_id)
+			return pcpu;
+	}
+	return NULL;
+}
+
+static struct pcpu *init_pcpu(struct xenpf_pcpuinfo *info)
+{
+	struct pcpu *pcpu;
+
+	if (info->flags & XEN_PCPU_FLAGS_INVALID)
+		return NULL;
+
+	/* The PCPU is just added */
+	pcpu =3D kzalloc(sizeof(struct pcpu), GFP_KERNEL);
+	if (!pcpu)
+		return NULL;
+
+	INIT_LIST_HEAD(&pcpu->pcpu_list);
+	pcpu->xen_id =3D info->xen_cpuid;
+	pcpu->apic_id =3D info->apic_id;
+	pcpu->acpi_id =3D info->acpi_id;
+	pcpu->flags =3D info->flags;
+
+	pcpu->sysdev.cls =3D &xen_pcpu_sysdev_class;
+	pcpu->sysdev.id =3D info->xen_cpuid;
+
+	if (pcpu_sysdev_init(pcpu)) {
+		kfree(pcpu);
+		return NULL;
+	}
+
+	list_add_tail(&pcpu->pcpu_list, &xen_pcpus.list);
+	raw_notifier_call_chain(&xen_pcpu_chain,
+				XEN_PCPU_ADD,
+				(void *)(long)pcpu->xen_id);
+	return pcpu;
+}
+
+#define PCPU_NO_CHANGE			0
+#define PCPU_ADDED			1
+#define PCPU_ONLINE_OFFLINE		2
+#define PCPU_REMOVED			3
+/*
+ * Caller should hold the pcpu lock
+ * < 0: Something wrong
+ * 0: No changes
+ * > 0: State changed
+ */
+static struct pcpu *_sync_pcpu(int cpu_num, int *max_id, int *result)
+{
+	struct pcpu *pcpu =3D NULL;
+	struct xenpf_pcpuinfo *info;
+	xen_platform_op_t op =3D {
+		.cmd            =3D XENPF_get_cpuinfo,
+		.interface_version  =3D XENPF_INTERFACE_VERSION,
+	};
+	int ret;
+
+	*result =3D -1;
+
+	info =3D &op.u.pcpu_info;
+	info->xen_cpuid =3D cpu_num;
+
+	ret =3D HYPERVISOR_dom0_op(&op);
+	if (ret)
+		return NULL;
+
+	if (max_id)
+		*max_id =3D op.u.pcpu_info.max_present;
+
+	pcpu =3D get_pcpu(cpu_num);
+
+	if (info->flags & XEN_PCPU_FLAGS_INVALID) {
+		/* The pcpu has been removed */
+		*result =3D PCPU_NO_CHANGE;
+		if (pcpu) {
+			raw_notifier_call_chain(&xen_pcpu_chain,
+			  XEN_PCPU_REMOVE,
+			  (void *)(long)pcpu->xen_id);
+			xen_pcpu_free(pcpu);
+			*result =3D PCPU_REMOVED;
+		}
+		return NULL;
+	}
+
+
+	if (!pcpu) {
+		*result =3D PCPU_ADDED;
+		pcpu =3D init_pcpu(info);
+		if (pcpu =3D=3D NULL) {
+			printk(KERN_WARNING "Failed to init pcpu %x\n",
+			  info->xen_cpuid);
+			  *result =3D -1;
+		}
+	} else {
+		*result =3D PCPU_NO_CHANGE;
+		/*
+		 * Old PCPU is replaced with a new pcpu, this means
+		 * several virq is missed, will it happen?
+		 */
+		if (!same_pcpu(info, pcpu)) {
+			printk(KERN_WARNING "Pcpu %x changed!\n",
+			  pcpu->xen_id);
+			pcpu->apic_id =3D info->apic_id;
+			pcpu->acpi_id =3D info->acpi_id;
+		}
+		if (xen_pcpu_online_check(info, pcpu))
+			*result =3D PCPU_ONLINE_OFFLINE;
+	}
+	return pcpu;
+}
+
+int xen_pcpu_index(uint32_t id, int is_acpiid)
+{
+	int cpu_num =3D 0, max_id =3D 0, ret;
+	xen_platform_op_t op =3D {
+		.cmd            =3D XENPF_get_cpuinfo,
+		.interface_version  =3D XENPF_INTERFACE_VERSION,
+	};
+	struct xenpf_pcpuinfo *info =3D &op.u.pcpu_info;
+
+	info->xen_cpuid =3D 0;
+	ret =3D HYPERVISOR_dom0_op(&op);
+	if (ret)
+		return -1;
+	max_id =3D op.u.pcpu_info.max_present;
+
+	while ((cpu_num <=3D max_id)) {
+		info->xen_cpuid =3D cpu_num;
+		ret =3D HYPERVISOR_dom0_op(&op);
+		if (ret)
+			continue;
+
+		if (op.u.pcpu_info.max_present > max_id)
+			max_id =3D op.u.pcpu_info.max_present;
+		if (id =3D=3D (is_acpiid ? info->acpi_id : info->apic_id))
+			return cpu_num;
+		cpu_num++;
+	}
+
+    return -1;
+}
+EXPORT_SYMBOL(xen_pcpu_index);
+
+/*
+ * Sync dom0's pcpu information with xen hypervisor's
+ */
+static int xen_sync_pcpus(void)
+{
+	/*
+	 * Boot cpu always have cpu_id 0 in xen
+	 */
+	int cpu_num =3D 0, max_id =3D 0, result =3D 0, present =3D 0;
+	struct list_head *elem, *tmp;
+	struct pcpu *pcpu;
+
+	get_pcpu_lock();
+
+	while ((result >=3D 0) && (cpu_num <=3D max_id)) {
+		pcpu =3D _sync_pcpu(cpu_num, &max_id, &result);
+
+		printk(KERN_DEBUG "sync cpu %x get result %x max_id %x\n",
+			cpu_num, result, max_id);
+
+		switch (result)	{
+		case PCPU_NO_CHANGE:
+			if (pcpu)
+				present++;
+			break;
+		case PCPU_ADDED:
+		case PCPU_ONLINE_OFFLINE:
+			present++;
+		case PCPU_REMOVED:
+			break;
+		default:
+			printk(KERN_WARNING "Failed to sync pcpu %x\n",
+			  cpu_num);
+			break;
+
+		}
+		cpu_num++;
+	}
+
+	if (result < 0) {
+		list_for_each_safe(elem, tmp, &xen_pcpus.list) {
+			pcpu =3D list_entry(elem, struct pcpu, pcpu_list);
+			xen_pcpu_free(pcpu);
+		}
+		present =3D 0;
+	}
+
+	xen_pcpus.present =3D present;
+
+	put_pcpu_lock();
+
+	return 0;
+}
+
+static void xen_pcpu_dpc(struct work_struct *work)
+{
+	if (xen_sync_pcpus() < 0)
+		printk(KERN_WARNING
+			"xen_pcpu_dpc: Failed to sync pcpu information\n");
+}
+static DECLARE_WORK(xen_pcpu_work, xen_pcpu_dpc);
+
+int xen_pcpu_hotplug(int type, uint32_t apic_id)
+{
+	schedule_work(&xen_pcpu_work);
+
+	return 0;
+}
+EXPORT_SYMBOL(xen_pcpu_hotplug);
+
+static irqreturn_t xen_pcpu_interrupt(int irq, void *dev_id)
+{
+	schedule_work(&xen_pcpu_work);
+	return IRQ_HANDLED;
+}
+
+static int __init xen_pcpu_init(void)
+{
+	int err;
+
+	if (!xen_initial_domain())
+		return 0;
+
+	err =3D sysdev_class_register(&xen_pcpu_sysdev_class);
+	if (err) {
+		printk(KERN_WARNING
+			"xen_pcpu_init: register xen_pcpu sysdev Failed!\n");
+		return err;
+	}
+
+	INIT_LIST_HEAD(&xen_pcpus.list);
+	xen_pcpus.present =3D 0;
+
+	xen_sync_pcpus();
+	if (xen_pcpus.present > 0)
+		err =3D bind_virq_to_irqhandler(VIRQ_PCPU_STATE,
+			0, xen_pcpu_interrupt, 0, "pcpu", NULL);
+	if (err < 0)
+		printk(KERN_WARNING "xen_pcpu_init: "
+			"Failed to bind pcpu_state virq\n"
+			"You will lost latest information! \n");
+	return err;
+}
+
+arch_initcall(xen_pcpu_init);
diff --git a/include/xen/interface/platform.h b/include/xen/interface/platf=
orm.h
index c168468..47ffe16 100644
--- a/include/xen/interface/platform.h
+++ b/include/xen/interface/platform.h
@@ -297,6 +297,31 @@ struct xenpf_set_processor_pminfo {
 };
 DEFINE_GUEST_HANDLE_STRUCT(xenpf_set_processor_pminfo);
=20
+#define XENPF_get_cpuinfo 55
+struct xenpf_pcpuinfo {
+	/* IN */
+	uint32_t xen_cpuid;
+	/* OUT */
+	/* The maxium cpu_id that is present */
+	uint32_t max_present;
+#define XEN_PCPU_FLAGS_ONLINE   1
+	/* Correponding xen_cpuid is not present*/
+#define XEN_PCPU_FLAGS_INVALID  2
+	uint32_t flags;
+	uint32_t apic_id;
+	uint32_t acpi_id;
+};
+typedef struct xenpf_pcpuinfo xenpf_pcpuinfo_t;
+DEFINE_GUEST_HANDLE_STRUCT(xenpf_pcpuinfo_t);
+
+#define XENPF_cpu_online    56
+#define XENPF_cpu_offline   57
+struct xenpf_cpu_ol {
+    uint32_t cpuid;
+};
+typedef struct xenpf_cpu_ol xenpf_cpu_ol_t;
+DEFINE_GUEST_HANDLE_STRUCT(xenpf_cpu_ol_t);
+
 struct xen_platform_op {
 	uint32_t cmd;
 	uint32_t interface_version; /* XENPF_INTERFACE_VERSION */
@@ -312,9 +337,12 @@ struct xen_platform_op {
 		struct xenpf_change_freq       change_freq;
 		struct xenpf_getidletime       getidletime;
 		struct xenpf_set_processor_pminfo set_pminfo;
+		struct xenpf_pcpuinfo          pcpu_info;
+		struct xenpf_cpu_ol            cpu_ol;
 		uint8_t                        pad[128];
 	} u;
 };
+typedef struct xen_platform_op xen_platform_op_t;
 DEFINE_GUEST_HANDLE_STRUCT(xen_platform_op_t);
=20
 #endif /* __XEN_PUBLIC_PLATFORM_H__ */
diff --git a/include/xen/interface/xen.h b/include/xen/interface/xen.h
index 6a6e914..5a91c66 100644
--- a/include/xen/interface/xen.h
+++ b/include/xen/interface/xen.h
@@ -80,6 +80,7 @@
 #define VIRQ_CONSOLE    2  /* (DOM0) Bytes received on emergency console. =
*/
 #define VIRQ_DOM_EXC    3  /* (DOM0) Exceptional event for some domain.   =
*/
 #define VIRQ_DEBUGGER   6  /* (DOM0) A domain has paused for debugging.   =
*/
+#define VIRQ_PCPU_STATE 9  /* (DOM0) PCPU state changed                   =
*/
=20
 /* Architecture-specific VIRQ definitions. */
 #define VIRQ_ARCH_0    16
diff --git a/include/xen/pcpu.h b/include/xen/pcpu.h
new file mode 100644
index 0000000..7e8f9d1
--- /dev/null
+++ b/include/xen/pcpu.h
@@ -0,0 +1,32 @@
+#ifndef _XEN_PCPU_H
+#define _XEN_PCPU_H
+
+#include <xen/interface/platform.h>
+#include <linux/sysdev.h>
+
+extern int xen_pcpu_hotplug(int type, uint32_t apic_id);
+#define XEN_PCPU_ONLINE     0x01
+#define XEN_PCPU_OFFLINE    0x02
+#define XEN_PCPU_ADD        0x04
+#define XEN_PCPU_REMOVE     0x08
+
+struct pcpu {
+	struct list_head pcpu_list;
+	struct sys_device sysdev;
+	uint32_t xen_id;
+	uint32_t apic_id;
+	uint32_t acpi_id;
+	uint32_t flags;
+};
+
+static inline int xen_pcpu_online(uint32_t flags)
+{
+	return !!(flags & XEN_PCPU_FLAGS_ONLINE);
+}
+
+extern int register_xen_pcpu_notifier(struct notifier_block *nb);
+
+extern void unregister_xen_pcpu_notifier(struct notifier_block *nb);
+
+extern int xen_pcpu_index(uint32_t acpi_id, int is_acpiid);
+#endif
--=20
1.6.5.6

--_002_DE8DF0795D48FD4CA783C40EC82923358A24SHSMSX101ccrcorpint_
Content-Type: application/octet-stream;
	name="0003-Xen-Export-host-physical-CPU-information-to-dom0.patch"
Content-Description: 0003-Xen-Export-host-physical-CPU-information-to-dom0.patch
Content-Disposition: attachment;
	filename="0003-Xen-Export-host-physical-CPU-information-to-dom0.patch";
	size=15036; creation-date="Wed, 14 Dec 2011 15:20:15 GMT";
	modification-date="Wed, 14 Dec 2011 15:03:34 GMT"
Content-Transfer-Encoding: base64

RnJvbSAwNDE1MWFhMThiNDhhNDUyY2M5ZDA2OTZmMzZhYTk2YzY5MGNhMDExIE1vbiBTZXAgMTcg
MDA6MDA6MDAgMjAwMQpGcm9tOiBMaXUgSmluc29uZyA8amluc29uZy5saXVAaW50ZWwuY29tPgpE
YXRlOiBUaHUsIDggRGVjIDIwMTEgMjI6Mjg6MDcgKzA4MDAKU3ViamVjdDogW1BBVENIIDAzLzEw
XSBYZW46IEV4cG9ydCBob3N0IHBoeXNpY2FsIENQVSBpbmZvcm1hdGlvbiB0byBkb20wCgpUaGlz
IHBhdGNoIHJlYmFzZWQgZnJvbSBKZXJlbXkncyBwdm9wcyBjb21taXQKM2IzNGNkMTk2MjdjNmUx
OTFiMTVmZDZjYjU5Zjk5N2I4ZGIyMWUxOSBhbmQKNjgzMjAzMjNhNTFjMjM3OGFjYTQzM2M3NjE1
N2Q5ZTY2MTA0ZmYxZQoKVGhpcyBwYXRjaCBleHBvc2UgaG9zdCdzIHBoeXNpY2FsIENQVSBpbmZv
cm1hdGlvbiB0byBkb20wIGluIHN5c2ZzLCBzbwp0aGF0IGRvbTAncyBtYW5hZ2VtZW50IHRvb2xz
IGNhbiBjb250cm9sIHRoZSBwaHlzaWNhbCBDUFUgaWYgbmVlZGVkLgoKSXQgYWxzbyBwcm92aWRl
cyBpbnRlcmZhY2UgaW4gc3lzZnMgdG8gbG9naWNhbCBvbmxpbmUvb2ZmbGluZSBhIHBoeXNpY2Fs
IENQVS4KCk5vdGljZTogVGhlIGluZm9ybWF0aW9uIGluIGRvbTAgaXMgc3luY2VkIHdpdGggeGVu
IGh5cGVydmlzb3IgYXN5bmNocm9ub3VzbHkuCgpTaWduZWQtb2ZmLWJ5OiBMaXUsIEppbnNvbmcg
PGppbnNvbmcubGl1QGludGVsLmNvbT4KU2lnbmVkLW9mZi1ieTogSmlhbmcsIFl1bmhvbmcgPHl1
bmhvbmcuamlhbmdAaW50ZWwuY29tPgpTaWduZWQtb2ZmLWJ5OiBKZXJlbXkgRml0emhhcmRpbmdl
IDxqZXJlbXkuZml0emhhcmRpbmdlQGNpdHJpeC5jb20+Ci0tLQogZHJpdmVycy94ZW4vTWFrZWZp
bGUgICAgICAgICAgICAgfCAgICAyICstCiBkcml2ZXJzL3hlbi9wY3B1LmMgICAgICAgICAgICAg
ICB8ICA0NTIgKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysKIGluY2x1ZGUv
eGVuL2ludGVyZmFjZS9wbGF0Zm9ybS5oIHwgICAyOCArKysKIGluY2x1ZGUveGVuL2ludGVyZmFj
ZS94ZW4uaCAgICAgIHwgICAgMSArCiBpbmNsdWRlL3hlbi9wY3B1LmggICAgICAgICAgICAgICB8
ICAgMzIgKysrCiA1IGZpbGVzIGNoYW5nZWQsIDUxNCBpbnNlcnRpb25zKCspLCAxIGRlbGV0aW9u
cygtKQogY3JlYXRlIG1vZGUgMTAwNjQ0IGRyaXZlcnMveGVuL3BjcHUuYwogY3JlYXRlIG1vZGUg
MTAwNjQ0IGluY2x1ZGUveGVuL3BjcHUuaAoKZGlmZiAtLWdpdCBhL2RyaXZlcnMveGVuL01ha2Vm
aWxlIGIvZHJpdmVycy94ZW4vTWFrZWZpbGUKaW5kZXggNDA1Y2NlOS4uYWVkYWY0OCAxMDA2NDQK
LS0tIGEvZHJpdmVycy94ZW4vTWFrZWZpbGUKKysrIGIvZHJpdmVycy94ZW4vTWFrZWZpbGUKQEAg
LTEsNCArMSw0IEBACi1vYmoteQkrPSBncmFudC10YWJsZS5vIGZlYXR1cmVzLm8gZXZlbnRzLm8g
bWFuYWdlLm8gYmFsbG9vbi5vCitvYmoteQkrPSBncmFudC10YWJsZS5vIGZlYXR1cmVzLm8gZXZl
bnRzLm8gbWFuYWdlLm8gYmFsbG9vbi5vIHBjcHUubwogb2JqLXkJKz0geGVuYnVzLwogCiBub3N0
YWNrcCA6PSAkKGNhbGwgY2Mtb3B0aW9uLCAtZm5vLXN0YWNrLXByb3RlY3RvcikKZGlmZiAtLWdp
dCBhL2RyaXZlcnMveGVuL3BjcHUuYyBiL2RyaXZlcnMveGVuL3BjcHUuYwpuZXcgZmlsZSBtb2Rl
IDEwMDY0NAppbmRleCAwMDAwMDAwLi42ZDFhNzcwCi0tLSAvZGV2L251bGwKKysrIGIvZHJpdmVy
cy94ZW4vcGNwdS5jCkBAIC0wLDAgKzEsNDUyIEBACisvKgorICogcGNwdS5jIC0gbWFuYWdlbWVu
dCBwaHlzaWNhbCBjcHUgaW4gZG9tMCBlbnZpcm9ubWVudAorICovCisjaW5jbHVkZSA8bGludXgv
aW50ZXJydXB0Lmg+CisjaW5jbHVkZSA8bGludXgvc3BpbmxvY2suaD4KKyNpbmNsdWRlIDxhc20v
eGVuL2h5cGVydmlzb3IuaD4KKyNpbmNsdWRlIDxhc20veGVuL2h5cGVyY2FsbC5oPgorI2luY2x1
ZGUgPGxpbnV4L2NwdS5oPgorI2luY2x1ZGUgPHhlbi94ZW5idXMuaD4KKyNpbmNsdWRlIDx4ZW4v
cGNwdS5oPgorI2luY2x1ZGUgPHhlbi9ldmVudHMuaD4KKyNpbmNsdWRlIDx4ZW4vYWNwaS5oPgor
CitzdGF0aWMgc3RydWN0IHN5c2Rldl9jbGFzcyB4ZW5fcGNwdV9zeXNkZXZfY2xhc3MgPSB7CisJ
Lm5hbWUgPSAieGVuX3BjcHUiLAorfTsKKworc3RhdGljIERFRklORV9NVVRFWCh4ZW5fcGNwdV9s
b2NrKTsKK3N0YXRpYyBSQVdfTk9USUZJRVJfSEVBRCh4ZW5fcGNwdV9jaGFpbik7CisKKy8qIE5v
IG5lZWQgZm9yIGlycSBkaXNhYmxlIHNpbmNlIGhvdHBsdWcgbm90aWZ5IGlzIGluIHdvcmtxdWV1
ZSBjb250ZXh0ICovCisjZGVmaW5lIGdldF9wY3B1X2xvY2soKSBtdXRleF9sb2NrKCZ4ZW5fcGNw
dV9sb2NrKTsKKyNkZWZpbmUgcHV0X3BjcHVfbG9jaygpIG11dGV4X3VubG9jaygmeGVuX3BjcHVf
bG9jayk7CisKK3N0cnVjdCB4ZW5fcGNwdXMgeworCXN0cnVjdCBsaXN0X2hlYWQgbGlzdDsKKwlp
bnQgcHJlc2VudDsKK307CitzdGF0aWMgc3RydWN0IHhlbl9wY3B1cyB4ZW5fcGNwdXM7CisKK2lu
dCByZWdpc3Rlcl94ZW5fcGNwdV9ub3RpZmllcihzdHJ1Y3Qgbm90aWZpZXJfYmxvY2sgKm5iKQor
eworCWludCByZXQ7CisKKwkvKiBBbGwgcmVmZXIgdG8gdGhlIGNoYWluIG5vdGlmaWVyIGlzIHBy
b3RlY3RlZCBieSB0aGUgcGNwdV9sb2NrICovCisJZ2V0X3BjcHVfbG9jaygpOworCXJldCA9IHJh
d19ub3RpZmllcl9jaGFpbl9yZWdpc3RlcigmeGVuX3BjcHVfY2hhaW4sIG5iKTsKKwlwdXRfcGNw
dV9sb2NrKCk7CisJcmV0dXJuIHJldDsKK30KK0VYUE9SVF9TWU1CT0xfR1BMKHJlZ2lzdGVyX3hl
bl9wY3B1X25vdGlmaWVyKTsKKwordm9pZCB1bnJlZ2lzdGVyX3hlbl9wY3B1X25vdGlmaWVyKHN0
cnVjdCBub3RpZmllcl9ibG9jayAqbmIpCit7CisJZ2V0X3BjcHVfbG9jaygpOworCXJhd19ub3Rp
Zmllcl9jaGFpbl91bnJlZ2lzdGVyKCZ4ZW5fcGNwdV9jaGFpbiwgbmIpOworCXB1dF9wY3B1X2xv
Y2soKTsKK30KK0VYUE9SVF9TWU1CT0xfR1BMKHVucmVnaXN0ZXJfeGVuX3BjcHVfbm90aWZpZXIp
OworCitzdGF0aWMgaW50IHhlbl9wY3B1X2Rvd24odWludDMyX3QgeGVuX2lkKQoreworCWludCBy
ZXQ7CisJeGVuX3BsYXRmb3JtX29wX3Qgb3AgPSB7CisJCS5jbWQJCQk9IFhFTlBGX2NwdV9vZmZs
aW5lLAorCQkuaW50ZXJmYWNlX3ZlcnNpb24JPSBYRU5QRl9JTlRFUkZBQ0VfVkVSU0lPTiwKKwkJ
LnUuY3B1X29sLmNwdWlkCT0geGVuX2lkLAorCX07CisKKwlyZXQgPSBIWVBFUlZJU09SX2RvbTBf
b3AoJm9wKTsKKwlyZXR1cm4gcmV0OworfQorCitzdGF0aWMgaW50IHhlbl9wY3B1X3VwKHVpbnQz
Ml90IHhlbl9pZCkKK3sKKwlpbnQgcmV0OworCXhlbl9wbGF0Zm9ybV9vcF90IG9wID0geworCQku
Y21kCQkJPSBYRU5QRl9jcHVfb25saW5lLAorCQkuaW50ZXJmYWNlX3ZlcnNpb24JPSBYRU5QRl9J
TlRFUkZBQ0VfVkVSU0lPTiwKKwkJLnUuY3B1X29sLmNwdWlkCT0geGVuX2lkLAorCX07CisKKwly
ZXQgPSBIWVBFUlZJU09SX2RvbTBfb3AoJm9wKTsKKwlyZXR1cm4gcmV0OworfQorCitzdGF0aWMg
c3NpemVfdCBzaG93X29ubGluZShzdHJ1Y3Qgc3lzX2RldmljZSAqZGV2LAorCQkJc3RydWN0IHN5
c2Rldl9hdHRyaWJ1dGUgKmF0dHIsCisJCQljaGFyICpidWYpCit7CisJc3RydWN0IHBjcHUgKmNw
dSA9IGNvbnRhaW5lcl9vZihkZXYsIHN0cnVjdCBwY3B1LCBzeXNkZXYpOworCisJcmV0dXJuIHNw
cmludGYoYnVmLCAiJXVcbiIsICEhKGNwdS0+ZmxhZ3MgJiBYRU5fUENQVV9GTEFHU19PTkxJTkUp
KTsKK30KKworc3RhdGljIHNzaXplX3QgX19yZWYgc3RvcmVfb25saW5lKHN0cnVjdCBzeXNfZGV2
aWNlICpkZXYsCisJCQkJICBzdHJ1Y3Qgc3lzZGV2X2F0dHJpYnV0ZSAqYXR0ciwKKwkJCQkgIGNv
bnN0IGNoYXIgKmJ1Ziwgc2l6ZV90IGNvdW50KQoreworCXN0cnVjdCBwY3B1ICpjcHUgPSBjb250
YWluZXJfb2YoZGV2LCBzdHJ1Y3QgcGNwdSwgc3lzZGV2KTsKKwlzc2l6ZV90IHJldDsKKworCXN3
aXRjaCAoYnVmWzBdKSB7CisJY2FzZSAnMCc6CisJCXJldCA9IHhlbl9wY3B1X2Rvd24oY3B1LT54
ZW5faWQpOworCQlicmVhazsKKwljYXNlICcxJzoKKwkJcmV0ID0geGVuX3BjcHVfdXAoY3B1LT54
ZW5faWQpOworCQlicmVhazsKKwlkZWZhdWx0OgorCQlyZXQgPSAtRUlOVkFMOworCX0KKworCWlm
IChyZXQgPj0gMCkKKwkJcmV0ID0gY291bnQ7CisJcmV0dXJuIHJldDsKK30KKworc3RhdGljIFNZ
U0RFVl9BVFRSKG9ubGluZSwgMDY0NCwgc2hvd19vbmxpbmUsIHN0b3JlX29ubGluZSk7CisKK3N0
YXRpYyBzc2l6ZV90IHNob3dfYXBpY2lkKHN0cnVjdCBzeXNfZGV2aWNlICpkZXYsCisJCQlzdHJ1
Y3Qgc3lzZGV2X2F0dHJpYnV0ZSAqYXR0ciwKKwkJCWNoYXIgKmJ1ZikKK3sKKwlzdHJ1Y3QgcGNw
dSAqY3B1ID0gY29udGFpbmVyX29mKGRldiwgc3RydWN0IHBjcHUsIHN5c2Rldik7CisKKwlyZXR1
cm4gc3ByaW50ZihidWYsICIldVxuIiwgY3B1LT5hcGljX2lkKTsKK30KKworc3RhdGljIHNzaXpl
X3Qgc2hvd19hY3BpaWQoc3RydWN0IHN5c19kZXZpY2UgKmRldiwKKwkJCXN0cnVjdCBzeXNkZXZf
YXR0cmlidXRlICphdHRyLAorCQkJY2hhciAqYnVmKQoreworCXN0cnVjdCBwY3B1ICpjcHUgPSBj
b250YWluZXJfb2YoZGV2LCBzdHJ1Y3QgcGNwdSwgc3lzZGV2KTsKKworCXJldHVybiBzcHJpbnRm
KGJ1ZiwgIiV1XG4iLCBjcHUtPmFjcGlfaWQpOworfQorc3RhdGljIFNZU0RFVl9BVFRSKGFwaWNf
aWQsIDA0NDQsIHNob3dfYXBpY2lkLCBOVUxMKTsKK3N0YXRpYyBTWVNERVZfQVRUUihhY3BpX2lk
LCAwNDQ0LCBzaG93X2FjcGlpZCwgTlVMTCk7CisKK3N0YXRpYyBpbnQgeGVuX3BjcHVfZnJlZShz
dHJ1Y3QgcGNwdSAqcGNwdSkKK3sKKwlpZiAoIXBjcHUpCisJCXJldHVybiAwOworCisJc3lzZGV2
X3JlbW92ZV9maWxlKCZwY3B1LT5zeXNkZXYsICZhdHRyX29ubGluZSk7CisJc3lzZGV2X3VucmVn
aXN0ZXIoJnBjcHUtPnN5c2Rldik7CisJbGlzdF9kZWwoJnBjcHUtPnBjcHVfbGlzdCk7CisJa2Zy
ZWUocGNwdSk7CisKKwlyZXR1cm4gMDsKK30KKworc3RhdGljIGlubGluZSBpbnQgc2FtZV9wY3B1
KHN0cnVjdCB4ZW5wZl9wY3B1aW5mbyAqaW5mbywKKwkJCSAgICBzdHJ1Y3QgcGNwdSAqcGNwdSkK
K3sKKwlyZXR1cm4gKHBjcHUtPmFwaWNfaWQgPT0gaW5mby0+YXBpY19pZCkgJiYKKwkJKHBjcHUt
Pnhlbl9pZCA9PSBpbmZvLT54ZW5fY3B1aWQpOworfQorCisvKgorICogUmV0dXJuIDEgaWYgb25s
aW5lIHN0YXR1cyBjaGFuZ2VkCisgKi8KK3N0YXRpYyBpbnQgeGVuX3BjcHVfb25saW5lX2NoZWNr
KHN0cnVjdCB4ZW5wZl9wY3B1aW5mbyAqaW5mbywKKwkJCQkgc3RydWN0IHBjcHUgKnBjcHUpCit7
CisJaW50IHJlc3VsdCA9IDA7CisKKwlpZiAoaW5mby0+eGVuX2NwdWlkICE9IHBjcHUtPnhlbl9p
ZCkKKwkJcmV0dXJuIDA7CisKKwlpZiAoeGVuX3BjcHVfb25saW5lKGluZm8tPmZsYWdzKSAmJiAh
eGVuX3BjcHVfb25saW5lKHBjcHUtPmZsYWdzKSkgeworCQkvKiB0aGUgcGNwdSBpcyBvbmxpbmVk
ICovCisJCXBjcHUtPmZsYWdzIHw9IFhFTl9QQ1BVX0ZMQUdTX09OTElORTsKKwkJa29iamVjdF91
ZXZlbnQoJnBjcHUtPnN5c2Rldi5rb2JqLCBLT0JKX09OTElORSk7CisJCXJhd19ub3RpZmllcl9j
YWxsX2NoYWluKCZ4ZW5fcGNwdV9jaGFpbiwKKwkJCVhFTl9QQ1BVX09OTElORSwgKHZvaWQgKiko
bG9uZylwY3B1LT54ZW5faWQpOworCQlyZXN1bHQgPSAxOworCX0gZWxzZSBpZiAoIXhlbl9wY3B1
X29ubGluZShpbmZvLT5mbGFncykgJiYKKwkJIHhlbl9wY3B1X29ubGluZShwY3B1LT5mbGFncykp
ICB7CisJCS8qIFRoZSBwY3B1IGlzIG9mZmxpbmVkIG5vdyAqLworCQlwY3B1LT5mbGFncyAmPSB+
WEVOX1BDUFVfRkxBR1NfT05MSU5FOworCQlrb2JqZWN0X3VldmVudCgmcGNwdS0+c3lzZGV2Lmtv
YmosIEtPQkpfT0ZGTElORSk7CisJCXJhd19ub3RpZmllcl9jYWxsX2NoYWluKCZ4ZW5fcGNwdV9j
aGFpbiwKKwkJCVhFTl9QQ1BVX09GRkxJTkUsICh2b2lkICopKGxvbmcpcGNwdS0+eGVuX2lkKTsK
KwkJcmVzdWx0ID0gMTsKKwl9CisKKwlyZXR1cm4gcmVzdWx0OworfQorCitzdGF0aWMgaW50IHBj
cHVfc3lzZGV2X2luaXQoc3RydWN0IHBjcHUgKmNwdSkKK3sKKwlpbnQgZXJyb3I7CisKKwllcnJv
ciA9IHN5c2Rldl9yZWdpc3RlcigmY3B1LT5zeXNkZXYpOworCWlmIChlcnJvcikgeworCQlwcmlu
dGsoS0VSTl9XQVJOSU5HICJ4ZW5fcGNwdV9hZGQ6IEZhaWxlZCB0byByZWdpc3RlciBwY3B1XG4i
KTsKKwkJa2ZyZWUoY3B1KTsKKwkJcmV0dXJuIC0xOworCX0KKwlzeXNkZXZfY3JlYXRlX2ZpbGUo
JmNwdS0+c3lzZGV2LCAmYXR0cl9vbmxpbmUpOworCXN5c2Rldl9jcmVhdGVfZmlsZSgmY3B1LT5z
eXNkZXYsICZhdHRyX2FwaWNfaWQpOworCXN5c2Rldl9jcmVhdGVfZmlsZSgmY3B1LT5zeXNkZXYs
ICZhdHRyX2FjcGlfaWQpOworCXJldHVybiAwOworfQorCitzdGF0aWMgc3RydWN0IHBjcHUgKmdl
dF9wY3B1KGludCB4ZW5faWQpCit7CisJc3RydWN0IHBjcHUgKnBjcHUgPSBOVUxMOworCisJbGlz
dF9mb3JfZWFjaF9lbnRyeShwY3B1LCAmeGVuX3BjcHVzLmxpc3QsIHBjcHVfbGlzdCkgeworCQlp
ZiAocGNwdS0+eGVuX2lkID09IHhlbl9pZCkKKwkJCXJldHVybiBwY3B1OworCX0KKwlyZXR1cm4g
TlVMTDsKK30KKworc3RhdGljIHN0cnVjdCBwY3B1ICppbml0X3BjcHUoc3RydWN0IHhlbnBmX3Bj
cHVpbmZvICppbmZvKQoreworCXN0cnVjdCBwY3B1ICpwY3B1OworCisJaWYgKGluZm8tPmZsYWdz
ICYgWEVOX1BDUFVfRkxBR1NfSU5WQUxJRCkKKwkJcmV0dXJuIE5VTEw7CisKKwkvKiBUaGUgUENQ
VSBpcyBqdXN0IGFkZGVkICovCisJcGNwdSA9IGt6YWxsb2Moc2l6ZW9mKHN0cnVjdCBwY3B1KSwg
R0ZQX0tFUk5FTCk7CisJaWYgKCFwY3B1KQorCQlyZXR1cm4gTlVMTDsKKworCUlOSVRfTElTVF9I
RUFEKCZwY3B1LT5wY3B1X2xpc3QpOworCXBjcHUtPnhlbl9pZCA9IGluZm8tPnhlbl9jcHVpZDsK
KwlwY3B1LT5hcGljX2lkID0gaW5mby0+YXBpY19pZDsKKwlwY3B1LT5hY3BpX2lkID0gaW5mby0+
YWNwaV9pZDsKKwlwY3B1LT5mbGFncyA9IGluZm8tPmZsYWdzOworCisJcGNwdS0+c3lzZGV2LmNs
cyA9ICZ4ZW5fcGNwdV9zeXNkZXZfY2xhc3M7CisJcGNwdS0+c3lzZGV2LmlkID0gaW5mby0+eGVu
X2NwdWlkOworCisJaWYgKHBjcHVfc3lzZGV2X2luaXQocGNwdSkpIHsKKwkJa2ZyZWUocGNwdSk7
CisJCXJldHVybiBOVUxMOworCX0KKworCWxpc3RfYWRkX3RhaWwoJnBjcHUtPnBjcHVfbGlzdCwg
Jnhlbl9wY3B1cy5saXN0KTsKKwlyYXdfbm90aWZpZXJfY2FsbF9jaGFpbigmeGVuX3BjcHVfY2hh
aW4sCisJCQkJWEVOX1BDUFVfQURELAorCQkJCSh2b2lkICopKGxvbmcpcGNwdS0+eGVuX2lkKTsK
KwlyZXR1cm4gcGNwdTsKK30KKworI2RlZmluZSBQQ1BVX05PX0NIQU5HRQkJCTAKKyNkZWZpbmUg
UENQVV9BRERFRAkJCTEKKyNkZWZpbmUgUENQVV9PTkxJTkVfT0ZGTElORQkJMgorI2RlZmluZSBQ
Q1BVX1JFTU9WRUQJCQkzCisvKgorICogQ2FsbGVyIHNob3VsZCBob2xkIHRoZSBwY3B1IGxvY2sK
KyAqIDwgMDogU29tZXRoaW5nIHdyb25nCisgKiAwOiBObyBjaGFuZ2VzCisgKiA+IDA6IFN0YXRl
IGNoYW5nZWQKKyAqLworc3RhdGljIHN0cnVjdCBwY3B1ICpfc3luY19wY3B1KGludCBjcHVfbnVt
LCBpbnQgKm1heF9pZCwgaW50ICpyZXN1bHQpCit7CisJc3RydWN0IHBjcHUgKnBjcHUgPSBOVUxM
OworCXN0cnVjdCB4ZW5wZl9wY3B1aW5mbyAqaW5mbzsKKwl4ZW5fcGxhdGZvcm1fb3BfdCBvcCA9
IHsKKwkJLmNtZCAgICAgICAgICAgID0gWEVOUEZfZ2V0X2NwdWluZm8sCisJCS5pbnRlcmZhY2Vf
dmVyc2lvbiAgPSBYRU5QRl9JTlRFUkZBQ0VfVkVSU0lPTiwKKwl9OworCWludCByZXQ7CisKKwkq
cmVzdWx0ID0gLTE7CisKKwlpbmZvID0gJm9wLnUucGNwdV9pbmZvOworCWluZm8tPnhlbl9jcHVp
ZCA9IGNwdV9udW07CisKKwlyZXQgPSBIWVBFUlZJU09SX2RvbTBfb3AoJm9wKTsKKwlpZiAocmV0
KQorCQlyZXR1cm4gTlVMTDsKKworCWlmIChtYXhfaWQpCisJCSptYXhfaWQgPSBvcC51LnBjcHVf
aW5mby5tYXhfcHJlc2VudDsKKworCXBjcHUgPSBnZXRfcGNwdShjcHVfbnVtKTsKKworCWlmIChp
bmZvLT5mbGFncyAmIFhFTl9QQ1BVX0ZMQUdTX0lOVkFMSUQpIHsKKwkJLyogVGhlIHBjcHUgaGFz
IGJlZW4gcmVtb3ZlZCAqLworCQkqcmVzdWx0ID0gUENQVV9OT19DSEFOR0U7CisJCWlmIChwY3B1
KSB7CisJCQlyYXdfbm90aWZpZXJfY2FsbF9jaGFpbigmeGVuX3BjcHVfY2hhaW4sCisJCQkgIFhF
Tl9QQ1BVX1JFTU9WRSwKKwkJCSAgKHZvaWQgKikobG9uZylwY3B1LT54ZW5faWQpOworCQkJeGVu
X3BjcHVfZnJlZShwY3B1KTsKKwkJCSpyZXN1bHQgPSBQQ1BVX1JFTU9WRUQ7CisJCX0KKwkJcmV0
dXJuIE5VTEw7CisJfQorCisKKwlpZiAoIXBjcHUpIHsKKwkJKnJlc3VsdCA9IFBDUFVfQURERUQ7
CisJCXBjcHUgPSBpbml0X3BjcHUoaW5mbyk7CisJCWlmIChwY3B1ID09IE5VTEwpIHsKKwkJCXBy
aW50ayhLRVJOX1dBUk5JTkcgIkZhaWxlZCB0byBpbml0IHBjcHUgJXhcbiIsCisJCQkgIGluZm8t
Pnhlbl9jcHVpZCk7CisJCQkgICpyZXN1bHQgPSAtMTsKKwkJfQorCX0gZWxzZSB7CisJCSpyZXN1
bHQgPSBQQ1BVX05PX0NIQU5HRTsKKwkJLyoKKwkJICogT2xkIFBDUFUgaXMgcmVwbGFjZWQgd2l0
aCBhIG5ldyBwY3B1LCB0aGlzIG1lYW5zCisJCSAqIHNldmVyYWwgdmlycSBpcyBtaXNzZWQsIHdp
bGwgaXQgaGFwcGVuPworCQkgKi8KKwkJaWYgKCFzYW1lX3BjcHUoaW5mbywgcGNwdSkpIHsKKwkJ
CXByaW50ayhLRVJOX1dBUk5JTkcgIlBjcHUgJXggY2hhbmdlZCFcbiIsCisJCQkgIHBjcHUtPnhl
bl9pZCk7CisJCQlwY3B1LT5hcGljX2lkID0gaW5mby0+YXBpY19pZDsKKwkJCXBjcHUtPmFjcGlf
aWQgPSBpbmZvLT5hY3BpX2lkOworCQl9CisJCWlmICh4ZW5fcGNwdV9vbmxpbmVfY2hlY2soaW5m
bywgcGNwdSkpCisJCQkqcmVzdWx0ID0gUENQVV9PTkxJTkVfT0ZGTElORTsKKwl9CisJcmV0dXJu
IHBjcHU7Cit9CisKK2ludCB4ZW5fcGNwdV9pbmRleCh1aW50MzJfdCBpZCwgaW50IGlzX2FjcGlp
ZCkKK3sKKwlpbnQgY3B1X251bSA9IDAsIG1heF9pZCA9IDAsIHJldDsKKwl4ZW5fcGxhdGZvcm1f
b3BfdCBvcCA9IHsKKwkJLmNtZCAgICAgICAgICAgID0gWEVOUEZfZ2V0X2NwdWluZm8sCisJCS5p
bnRlcmZhY2VfdmVyc2lvbiAgPSBYRU5QRl9JTlRFUkZBQ0VfVkVSU0lPTiwKKwl9OworCXN0cnVj
dCB4ZW5wZl9wY3B1aW5mbyAqaW5mbyA9ICZvcC51LnBjcHVfaW5mbzsKKworCWluZm8tPnhlbl9j
cHVpZCA9IDA7CisJcmV0ID0gSFlQRVJWSVNPUl9kb20wX29wKCZvcCk7CisJaWYgKHJldCkKKwkJ
cmV0dXJuIC0xOworCW1heF9pZCA9IG9wLnUucGNwdV9pbmZvLm1heF9wcmVzZW50OworCisJd2hp
bGUgKChjcHVfbnVtIDw9IG1heF9pZCkpIHsKKwkJaW5mby0+eGVuX2NwdWlkID0gY3B1X251bTsK
KwkJcmV0ID0gSFlQRVJWSVNPUl9kb20wX29wKCZvcCk7CisJCWlmIChyZXQpCisJCQljb250aW51
ZTsKKworCQlpZiAob3AudS5wY3B1X2luZm8ubWF4X3ByZXNlbnQgPiBtYXhfaWQpCisJCQltYXhf
aWQgPSBvcC51LnBjcHVfaW5mby5tYXhfcHJlc2VudDsKKwkJaWYgKGlkID09IChpc19hY3BpaWQg
PyBpbmZvLT5hY3BpX2lkIDogaW5mby0+YXBpY19pZCkpCisJCQlyZXR1cm4gY3B1X251bTsKKwkJ
Y3B1X251bSsrOworCX0KKworICAgIHJldHVybiAtMTsKK30KK0VYUE9SVF9TWU1CT0woeGVuX3Bj
cHVfaW5kZXgpOworCisvKgorICogU3luYyBkb20wJ3MgcGNwdSBpbmZvcm1hdGlvbiB3aXRoIHhl
biBoeXBlcnZpc29yJ3MKKyAqLworc3RhdGljIGludCB4ZW5fc3luY19wY3B1cyh2b2lkKQorewor
CS8qCisJICogQm9vdCBjcHUgYWx3YXlzIGhhdmUgY3B1X2lkIDAgaW4geGVuCisJICovCisJaW50
IGNwdV9udW0gPSAwLCBtYXhfaWQgPSAwLCByZXN1bHQgPSAwLCBwcmVzZW50ID0gMDsKKwlzdHJ1
Y3QgbGlzdF9oZWFkICplbGVtLCAqdG1wOworCXN0cnVjdCBwY3B1ICpwY3B1OworCisJZ2V0X3Bj
cHVfbG9jaygpOworCisJd2hpbGUgKChyZXN1bHQgPj0gMCkgJiYgKGNwdV9udW0gPD0gbWF4X2lk
KSkgeworCQlwY3B1ID0gX3N5bmNfcGNwdShjcHVfbnVtLCAmbWF4X2lkLCAmcmVzdWx0KTsKKwor
CQlwcmludGsoS0VSTl9ERUJVRyAic3luYyBjcHUgJXggZ2V0IHJlc3VsdCAleCBtYXhfaWQgJXhc
biIsCisJCQljcHVfbnVtLCByZXN1bHQsIG1heF9pZCk7CisKKwkJc3dpdGNoIChyZXN1bHQpCXsK
KwkJY2FzZSBQQ1BVX05PX0NIQU5HRToKKwkJCWlmIChwY3B1KQorCQkJCXByZXNlbnQrKzsKKwkJ
CWJyZWFrOworCQljYXNlIFBDUFVfQURERUQ6CisJCWNhc2UgUENQVV9PTkxJTkVfT0ZGTElORToK
KwkJCXByZXNlbnQrKzsKKwkJY2FzZSBQQ1BVX1JFTU9WRUQ6CisJCQlicmVhazsKKwkJZGVmYXVs
dDoKKwkJCXByaW50ayhLRVJOX1dBUk5JTkcgIkZhaWxlZCB0byBzeW5jIHBjcHUgJXhcbiIsCisJ
CQkgIGNwdV9udW0pOworCQkJYnJlYWs7CisKKwkJfQorCQljcHVfbnVtKys7CisJfQorCisJaWYg
KHJlc3VsdCA8IDApIHsKKwkJbGlzdF9mb3JfZWFjaF9zYWZlKGVsZW0sIHRtcCwgJnhlbl9wY3B1
cy5saXN0KSB7CisJCQlwY3B1ID0gbGlzdF9lbnRyeShlbGVtLCBzdHJ1Y3QgcGNwdSwgcGNwdV9s
aXN0KTsKKwkJCXhlbl9wY3B1X2ZyZWUocGNwdSk7CisJCX0KKwkJcHJlc2VudCA9IDA7CisJfQor
CisJeGVuX3BjcHVzLnByZXNlbnQgPSBwcmVzZW50OworCisJcHV0X3BjcHVfbG9jaygpOworCisJ
cmV0dXJuIDA7Cit9CisKK3N0YXRpYyB2b2lkIHhlbl9wY3B1X2RwYyhzdHJ1Y3Qgd29ya19zdHJ1
Y3QgKndvcmspCit7CisJaWYgKHhlbl9zeW5jX3BjcHVzKCkgPCAwKQorCQlwcmludGsoS0VSTl9X
QVJOSU5HCisJCQkieGVuX3BjcHVfZHBjOiBGYWlsZWQgdG8gc3luYyBwY3B1IGluZm9ybWF0aW9u
XG4iKTsKK30KK3N0YXRpYyBERUNMQVJFX1dPUksoeGVuX3BjcHVfd29yaywgeGVuX3BjcHVfZHBj
KTsKKworaW50IHhlbl9wY3B1X2hvdHBsdWcoaW50IHR5cGUsIHVpbnQzMl90IGFwaWNfaWQpCit7
CisJc2NoZWR1bGVfd29yaygmeGVuX3BjcHVfd29yayk7CisKKwlyZXR1cm4gMDsKK30KK0VYUE9S
VF9TWU1CT0woeGVuX3BjcHVfaG90cGx1Zyk7CisKK3N0YXRpYyBpcnFyZXR1cm5fdCB4ZW5fcGNw
dV9pbnRlcnJ1cHQoaW50IGlycSwgdm9pZCAqZGV2X2lkKQoreworCXNjaGVkdWxlX3dvcmsoJnhl
bl9wY3B1X3dvcmspOworCXJldHVybiBJUlFfSEFORExFRDsKK30KKworc3RhdGljIGludCBfX2lu
aXQgeGVuX3BjcHVfaW5pdCh2b2lkKQoreworCWludCBlcnI7CisKKwlpZiAoIXhlbl9pbml0aWFs
X2RvbWFpbigpKQorCQlyZXR1cm4gMDsKKworCWVyciA9IHN5c2Rldl9jbGFzc19yZWdpc3Rlcigm
eGVuX3BjcHVfc3lzZGV2X2NsYXNzKTsKKwlpZiAoZXJyKSB7CisJCXByaW50ayhLRVJOX1dBUk5J
TkcKKwkJCSJ4ZW5fcGNwdV9pbml0OiByZWdpc3RlciB4ZW5fcGNwdSBzeXNkZXYgRmFpbGVkIVxu
Iik7CisJCXJldHVybiBlcnI7CisJfQorCisJSU5JVF9MSVNUX0hFQUQoJnhlbl9wY3B1cy5saXN0
KTsKKwl4ZW5fcGNwdXMucHJlc2VudCA9IDA7CisKKwl4ZW5fc3luY19wY3B1cygpOworCWlmICh4
ZW5fcGNwdXMucHJlc2VudCA+IDApCisJCWVyciA9IGJpbmRfdmlycV90b19pcnFoYW5kbGVyKFZJ
UlFfUENQVV9TVEFURSwKKwkJCTAsIHhlbl9wY3B1X2ludGVycnVwdCwgMCwgInBjcHUiLCBOVUxM
KTsKKwlpZiAoZXJyIDwgMCkKKwkJcHJpbnRrKEtFUk5fV0FSTklORyAieGVuX3BjcHVfaW5pdDog
IgorCQkJIkZhaWxlZCB0byBiaW5kIHBjcHVfc3RhdGUgdmlycVxuIgorCQkJIllvdSB3aWxsIGxv
c3QgbGF0ZXN0IGluZm9ybWF0aW9uISBcbiIpOworCXJldHVybiBlcnI7Cit9CisKK2FyY2hfaW5p
dGNhbGwoeGVuX3BjcHVfaW5pdCk7CmRpZmYgLS1naXQgYS9pbmNsdWRlL3hlbi9pbnRlcmZhY2Uv
cGxhdGZvcm0uaCBiL2luY2x1ZGUveGVuL2ludGVyZmFjZS9wbGF0Zm9ybS5oCmluZGV4IGMxNjg0
NjguLjQ3ZmZlMTYgMTAwNjQ0Ci0tLSBhL2luY2x1ZGUveGVuL2ludGVyZmFjZS9wbGF0Zm9ybS5o
CisrKyBiL2luY2x1ZGUveGVuL2ludGVyZmFjZS9wbGF0Zm9ybS5oCkBAIC0yOTcsNiArMjk3LDMx
IEBAIHN0cnVjdCB4ZW5wZl9zZXRfcHJvY2Vzc29yX3BtaW5mbyB7CiB9OwogREVGSU5FX0dVRVNU
X0hBTkRMRV9TVFJVQ1QoeGVucGZfc2V0X3Byb2Nlc3Nvcl9wbWluZm8pOwogCisjZGVmaW5lIFhF
TlBGX2dldF9jcHVpbmZvIDU1CitzdHJ1Y3QgeGVucGZfcGNwdWluZm8geworCS8qIElOICovCisJ
dWludDMyX3QgeGVuX2NwdWlkOworCS8qIE9VVCAqLworCS8qIFRoZSBtYXhpdW0gY3B1X2lkIHRo
YXQgaXMgcHJlc2VudCAqLworCXVpbnQzMl90IG1heF9wcmVzZW50OworI2RlZmluZSBYRU5fUENQ
VV9GTEFHU19PTkxJTkUgICAxCisJLyogQ29ycmVwb25kaW5nIHhlbl9jcHVpZCBpcyBub3QgcHJl
c2VudCovCisjZGVmaW5lIFhFTl9QQ1BVX0ZMQUdTX0lOVkFMSUQgIDIKKwl1aW50MzJfdCBmbGFn
czsKKwl1aW50MzJfdCBhcGljX2lkOworCXVpbnQzMl90IGFjcGlfaWQ7Cit9OwordHlwZWRlZiBz
dHJ1Y3QgeGVucGZfcGNwdWluZm8geGVucGZfcGNwdWluZm9fdDsKK0RFRklORV9HVUVTVF9IQU5E
TEVfU1RSVUNUKHhlbnBmX3BjcHVpbmZvX3QpOworCisjZGVmaW5lIFhFTlBGX2NwdV9vbmxpbmUg
ICAgNTYKKyNkZWZpbmUgWEVOUEZfY3B1X29mZmxpbmUgICA1Nworc3RydWN0IHhlbnBmX2NwdV9v
bCB7CisgICAgdWludDMyX3QgY3B1aWQ7Cit9OwordHlwZWRlZiBzdHJ1Y3QgeGVucGZfY3B1X29s
IHhlbnBmX2NwdV9vbF90OworREVGSU5FX0dVRVNUX0hBTkRMRV9TVFJVQ1QoeGVucGZfY3B1X29s
X3QpOworCiBzdHJ1Y3QgeGVuX3BsYXRmb3JtX29wIHsKIAl1aW50MzJfdCBjbWQ7CiAJdWludDMy
X3QgaW50ZXJmYWNlX3ZlcnNpb247IC8qIFhFTlBGX0lOVEVSRkFDRV9WRVJTSU9OICovCkBAIC0z
MTIsOSArMzM3LDEyIEBAIHN0cnVjdCB4ZW5fcGxhdGZvcm1fb3AgewogCQlzdHJ1Y3QgeGVucGZf
Y2hhbmdlX2ZyZXEgICAgICAgY2hhbmdlX2ZyZXE7CiAJCXN0cnVjdCB4ZW5wZl9nZXRpZGxldGlt
ZSAgICAgICBnZXRpZGxldGltZTsKIAkJc3RydWN0IHhlbnBmX3NldF9wcm9jZXNzb3JfcG1pbmZv
IHNldF9wbWluZm87CisJCXN0cnVjdCB4ZW5wZl9wY3B1aW5mbyAgICAgICAgICBwY3B1X2luZm87
CisJCXN0cnVjdCB4ZW5wZl9jcHVfb2wgICAgICAgICAgICBjcHVfb2w7CiAJCXVpbnQ4X3QgICAg
ICAgICAgICAgICAgICAgICAgICBwYWRbMTI4XTsKIAl9IHU7CiB9OwordHlwZWRlZiBzdHJ1Y3Qg
eGVuX3BsYXRmb3JtX29wIHhlbl9wbGF0Zm9ybV9vcF90OwogREVGSU5FX0dVRVNUX0hBTkRMRV9T
VFJVQ1QoeGVuX3BsYXRmb3JtX29wX3QpOwogCiAjZW5kaWYgLyogX19YRU5fUFVCTElDX1BMQVRG
T1JNX0hfXyAqLwpkaWZmIC0tZ2l0IGEvaW5jbHVkZS94ZW4vaW50ZXJmYWNlL3hlbi5oIGIvaW5j
bHVkZS94ZW4vaW50ZXJmYWNlL3hlbi5oCmluZGV4IDZhNmU5MTQuLjVhOTFjNjYgMTAwNjQ0Ci0t
LSBhL2luY2x1ZGUveGVuL2ludGVyZmFjZS94ZW4uaAorKysgYi9pbmNsdWRlL3hlbi9pbnRlcmZh
Y2UveGVuLmgKQEAgLTgwLDYgKzgwLDcgQEAKICNkZWZpbmUgVklSUV9DT05TT0xFICAgIDIgIC8q
IChET00wKSBCeXRlcyByZWNlaXZlZCBvbiBlbWVyZ2VuY3kgY29uc29sZS4gKi8KICNkZWZpbmUg
VklSUV9ET01fRVhDICAgIDMgIC8qIChET00wKSBFeGNlcHRpb25hbCBldmVudCBmb3Igc29tZSBk
b21haW4uICAgKi8KICNkZWZpbmUgVklSUV9ERUJVR0dFUiAgIDYgIC8qIChET00wKSBBIGRvbWFp
biBoYXMgcGF1c2VkIGZvciBkZWJ1Z2dpbmcuICAgKi8KKyNkZWZpbmUgVklSUV9QQ1BVX1NUQVRF
IDkgIC8qIChET00wKSBQQ1BVIHN0YXRlIGNoYW5nZWQgICAgICAgICAgICAgICAgICAgKi8KIAog
LyogQXJjaGl0ZWN0dXJlLXNwZWNpZmljIFZJUlEgZGVmaW5pdGlvbnMuICovCiAjZGVmaW5lIFZJ
UlFfQVJDSF8wICAgIDE2CmRpZmYgLS1naXQgYS9pbmNsdWRlL3hlbi9wY3B1LmggYi9pbmNsdWRl
L3hlbi9wY3B1LmgKbmV3IGZpbGUgbW9kZSAxMDA2NDQKaW5kZXggMDAwMDAwMC4uN2U4ZjlkMQot
LS0gL2Rldi9udWxsCisrKyBiL2luY2x1ZGUveGVuL3BjcHUuaApAQCAtMCwwICsxLDMyIEBACisj
aWZuZGVmIF9YRU5fUENQVV9ICisjZGVmaW5lIF9YRU5fUENQVV9ICisKKyNpbmNsdWRlIDx4ZW4v
aW50ZXJmYWNlL3BsYXRmb3JtLmg+CisjaW5jbHVkZSA8bGludXgvc3lzZGV2Lmg+CisKK2V4dGVy
biBpbnQgeGVuX3BjcHVfaG90cGx1ZyhpbnQgdHlwZSwgdWludDMyX3QgYXBpY19pZCk7CisjZGVm
aW5lIFhFTl9QQ1BVX09OTElORSAgICAgMHgwMQorI2RlZmluZSBYRU5fUENQVV9PRkZMSU5FICAg
IDB4MDIKKyNkZWZpbmUgWEVOX1BDUFVfQUREICAgICAgICAweDA0CisjZGVmaW5lIFhFTl9QQ1BV
X1JFTU9WRSAgICAgMHgwOAorCitzdHJ1Y3QgcGNwdSB7CisJc3RydWN0IGxpc3RfaGVhZCBwY3B1
X2xpc3Q7CisJc3RydWN0IHN5c19kZXZpY2Ugc3lzZGV2OworCXVpbnQzMl90IHhlbl9pZDsKKwl1
aW50MzJfdCBhcGljX2lkOworCXVpbnQzMl90IGFjcGlfaWQ7CisJdWludDMyX3QgZmxhZ3M7Cit9
OworCitzdGF0aWMgaW5saW5lIGludCB4ZW5fcGNwdV9vbmxpbmUodWludDMyX3QgZmxhZ3MpCit7
CisJcmV0dXJuICEhKGZsYWdzICYgWEVOX1BDUFVfRkxBR1NfT05MSU5FKTsKK30KKworZXh0ZXJu
IGludCByZWdpc3Rlcl94ZW5fcGNwdV9ub3RpZmllcihzdHJ1Y3Qgbm90aWZpZXJfYmxvY2sgKm5i
KTsKKworZXh0ZXJuIHZvaWQgdW5yZWdpc3Rlcl94ZW5fcGNwdV9ub3RpZmllcihzdHJ1Y3Qgbm90
aWZpZXJfYmxvY2sgKm5iKTsKKworZXh0ZXJuIGludCB4ZW5fcGNwdV9pbmRleCh1aW50MzJfdCBh
Y3BpX2lkLCBpbnQgaXNfYWNwaWlkKTsKKyNlbmRpZgotLSAKMS42LjUuNgoK

--_002_DE8DF0795D48FD4CA783C40EC82923358A24SHSMSX101ccrcorpint_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--_002_DE8DF0795D48FD4CA783C40EC82923358A24SHSMSX101ccrcorpint_--


From xen-devel-bounces@lists.xensource.com Thu Dec 22 10:05:43 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 Dec 2011 10:05:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdfWn-00051u-0q; Thu, 22 Dec 2011 10:05:33 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1RdfWl-00050v-1p
	for xen-devel@lists.xensource.com; Thu, 22 Dec 2011 10:05:31 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1324548322!8268192!1
X-Originating-IP: [143.182.124.37]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjE1ODY2\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22237 invoked from network); 22 Dec 2011 10:05:23 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37)
	by server-2.tower-182.messagelabs.com with SMTP;
	22 Dec 2011 10:05:23 -0000
Received: from azsmga002.ch.intel.com ([10.2.17.35])
	by azsmga102.ch.intel.com with ESMTP; 22 Dec 2011 02:05:21 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208,223";a="49700315"
Received: from pgsmsx603.gar.corp.intel.com ([10.221.43.87])
	by AZSMGA002.ch.intel.com with ESMTP; 22 Dec 2011 02:05:20 -0800
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	pgsmsx603.gar.corp.intel.com (10.221.43.87) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Thu, 22 Dec 2011 18:05:18 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.38]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.199]) with mapi id
	14.01.0355.002; Thu, 22 Dec 2011 18:05:16 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: "konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Thread-Topic: [PATCH 04/10] Xen: Add pcpu hotadd support to pvops dom0.
Thread-Index: AczAkTOfZhw6tXtFTauz70dtFp0JKA==
Date: Thu, 22 Dec 2011 10:05:16 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC82923358A3F@SHSMSX101.ccr.corp.intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
Content-Type: multipart/mixed;
	boundary="_002_DE8DF0795D48FD4CA783C40EC82923358A3FSHSMSX101ccrcorpint_"
MIME-Version: 1.0
Cc: "Jiang, Yunhong" <yunhong.jiang@intel.com>,
	"jeremy.fitzhardinge@citrix.com" <jeremy.fitzhardinge@citrix.com>
Subject: [Xen-devel] [PATCH 04/10] Xen: Add pcpu hotadd support to pvops
	dom0.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--_002_DE8DF0795D48FD4CA783C40EC82923358A3FSHSMSX101ccrcorpint_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

>From 5f5eb7bf950836edb4910173d3be2f26ad737093 Mon Sep 17 00:00:00 2001
From: Liu Jinsong <jinsong.liu@intel.com>
Date: Sun, 11 Dec 2011 15:42:03 +0800
Subject: [PATCH 04/10] Xen: Add pcpu hotadd support to pvops dom0.

This patch rebased from Jeremy's pvops commit
3129884bc75d7e6578be7499ac04a06d9fc5b31d

This patch implement CPU hotplug callback in xen acpi_processor. User
can later bring the pcpu online through sysfs interface.

xen_get_apic_id() is mostly duplicated with the get_cpu_id() in
driver/acpi/processor_core.c, but it should be ok since it has been
duplicated in arch directory already by upstream kernel.

One thing left is, currently the acpi_processor's id is quite
confusing (it is in fact with vcpu's dom0 cpu_id). Will update it with
xen's cpuid through the pcpu interface. But to achieve it, we need
investigate more on the pr->id, and also we need change the pcpu logic
to use spin_lock, instead of mutex for the pcpu list. That will be
next step.

Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
Signed-off-by: Jiang, Yunhong <yunhong.jiang@intel.com>
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
---
 drivers/xen/acpi_processor.c     |  114 ++++++++++++++++++++++++++++++++++=
+++-
 include/xen/interface/platform.h |   10 +++-
 2 files changed, 122 insertions(+), 2 deletions(-)

diff --git a/drivers/xen/acpi_processor.c b/drivers/xen/acpi_processor.c
index 327a56e..acab49b 100644
--- a/drivers/xen/acpi_processor.c
+++ b/drivers/xen/acpi_processor.c
@@ -22,12 +22,19 @@
 #include <linux/cpufreq.h>
 #include <acpi/processor.h>
 #include <xen/acpi.h>
+#include <xen/pcpu.h>
=20
 #include <xen/interface/platform.h>
 #include <asm/xen/hypercall.h>
 #include <asm/xen/hypervisor.h>
=20
-static struct processor_cntl_xen_ops xen_ops;
+static int xen_get_apic_id(acpi_handle handle);
+static int xen_cpu_hotplug_notifier(struct acpi_processor *pr, int event);
+
+static struct processor_cntl_xen_ops xen_ops =3D {
+	.hotplug =3D xen_cpu_hotplug_notifier,
+};
+
 int processor_cntl_xen_notify(struct acpi_processor *pr, int event, int ty=
pe)
 {
 	int ret =3D -EINVAL;
@@ -41,6 +48,18 @@ int processor_cntl_xen_notify(struct acpi_processor *pr,=
 int event, int type)
=20
 		ret =3D xen_ops.pm_ops[type](pr, event);
 		break;
+	case PROCESSOR_HOTPLUG:
+	{
+		int apic_id;
+
+		apic_id =3D xen_get_apic_id(pr->handle);
+		if (apic_id < 0)
+			break;
+		if (xen_ops.hotplug)
+			ret =3D xen_ops.hotplug(pr, type);
+		xen_pcpu_hotplug(type, apic_id);
+		break;
+	}
 	default:
 		printk(KERN_ERR "Unsupport processor events %d.\n", event);
 		break;
@@ -50,6 +69,49 @@ int processor_cntl_xen_notify(struct acpi_processor *pr,=
 int event, int type)
 }
 EXPORT_SYMBOL(processor_cntl_xen_notify);
=20
+#ifdef CONFIG_ACPI_HOTPLUG_CPU
+static int xen_get_apic_id(acpi_handle handle)
+{
+	struct acpi_buffer buffer =3D { ACPI_ALLOCATE_BUFFER, NULL };
+	union acpi_object *obj;
+	struct acpi_madt_local_apic *lapic;
+	u8 physid;
+
+	if (ACPI_FAILURE(acpi_evaluate_object(handle, "_MAT", NULL, &buffer)))
+		return -EINVAL;
+
+	if (!buffer.length || !buffer.pointer)
+		return -EINVAL;
+
+	obj =3D buffer.pointer;
+	if (obj->type !=3D ACPI_TYPE_BUFFER ||
+	    obj->buffer.length < sizeof(*lapic)) {
+		kfree(buffer.pointer);
+		return -EINVAL;
+	}
+
+	lapic =3D (struct acpi_madt_local_apic *)obj->buffer.pointer;
+
+	if (lapic->header.type !=3D ACPI_MADT_TYPE_LOCAL_APIC ||
+	    !(lapic->lapic_flags & ACPI_MADT_ENABLED)) {
+		kfree(buffer.pointer);
+		return -EINVAL;
+	}
+
+	physid =3D lapic->id;
+	kfree(buffer.pointer);
+	buffer.length =3D ACPI_ALLOCATE_BUFFER;
+	buffer.pointer =3D NULL;
+
+	return physid;
+}
+#else
+static int xen_get_apic_id(acpi_handle handle)
+{
+	return -1;
+}
+#endif
+
 static inline void xen_convert_pct_reg(struct xen_pct_register *xpct,
 	struct acpi_pct_register *apct)
 {
@@ -246,6 +308,56 @@ static int xen_px_notifier(struct acpi_processor *pr, =
int action)
 	return ret;
 }
=20
+#ifdef CONFIG_ACPI_HOTPLUG_CPU
+static int xen_cpu_hotplug_notifier(struct acpi_processor *pr, int event)
+{
+	int ret =3D -EINVAL;
+	uint32_t apic_id;
+	unsigned long long pxm;
+	acpi_status status =3D 0;
+
+	xen_platform_op_t op =3D {
+		.interface_version  =3D XENPF_INTERFACE_VERSION,
+	};
+
+	apic_id =3D xen_get_apic_id(pr->handle);
+	if (apic_id < 0) {
+		printk(KERN_WARNING "Can't get apic_id for acpi_id %x\n",
+		  pr->acpi_id);
+		return -1;
+	}
+
+	status =3D acpi_evaluate_integer(pr->handle, "_PXM",
+	  NULL, &pxm);
+	if (ACPI_FAILURE(status)) {
+		printk(KERN_WARNING "can't get pxm for acpi_id %x\n",
+		  pr->acpi_id);
+		return -1;
+	}
+
+	switch (event) {
+	case HOTPLUG_TYPE_ADD:
+		op.cmd =3D XENPF_cpu_hotadd;
+		op.u.cpu_add.apic_id =3D apic_id;
+		op.u.cpu_add.acpi_id =3D pr->acpi_id;
+		op.u.cpu_add.pxm =3D pxm;
+		ret =3D HYPERVISOR_dom0_op(&op);
+		break;
+	case HOTPLUG_TYPE_REMOVE:
+		printk(KERN_WARNING "Xen not support CPU hotremove\n");
+		ret =3D -ENOSYS;
+		break;
+	}
+
+	return ret;
+}
+#else
+static int xen_cpu_hotplug_notifier(struct acpi_processor *pr, int event)
+{
+	return -ENOSYS;
+}
+#endif
+
 static int __init xen_acpi_processor_extcntl_init(void)
 {
 	unsigned int pmbits;
diff --git a/include/xen/interface/platform.h b/include/xen/interface/platf=
orm.h
index 47ffe16..9fd6b07 100644
--- a/include/xen/interface/platform.h
+++ b/include/xen/interface/platform.h
@@ -317,11 +317,18 @@ DEFINE_GUEST_HANDLE_STRUCT(xenpf_pcpuinfo_t);
 #define XENPF_cpu_online    56
 #define XENPF_cpu_offline   57
 struct xenpf_cpu_ol {
-    uint32_t cpuid;
+	uint32_t cpuid;
 };
 typedef struct xenpf_cpu_ol xenpf_cpu_ol_t;
 DEFINE_GUEST_HANDLE_STRUCT(xenpf_cpu_ol_t);
=20
+#define XENPF_cpu_hotadd    58
+struct xenpf_cpu_hotadd {
+	uint32_t apic_id;
+	uint32_t acpi_id;
+	uint32_t pxm;
+};
+
 struct xen_platform_op {
 	uint32_t cmd;
 	uint32_t interface_version; /* XENPF_INTERFACE_VERSION */
@@ -339,6 +346,7 @@ struct xen_platform_op {
 		struct xenpf_set_processor_pminfo set_pminfo;
 		struct xenpf_pcpuinfo          pcpu_info;
 		struct xenpf_cpu_ol            cpu_ol;
+		struct xenpf_cpu_hotadd        cpu_add;
 		uint8_t                        pad[128];
 	} u;
 };
--=20
1.6.5.6

--_002_DE8DF0795D48FD4CA783C40EC82923358A3FSHSMSX101ccrcorpint_
Content-Type: application/octet-stream;
	name="0004-Xen-Add-pcpu-hotadd-support-to-pvops-dom0.patch"
Content-Description: 0004-Xen-Add-pcpu-hotadd-support-to-pvops-dom0.patch
Content-Disposition: attachment;
	filename="0004-Xen-Add-pcpu-hotadd-support-to-pvops-dom0.patch"; size=6111;
	creation-date="Wed, 14 Dec 2011 15:20:15 GMT";
	modification-date="Wed, 14 Dec 2011 15:03:34 GMT"
Content-Transfer-Encoding: base64

RnJvbSA1ZjVlYjdiZjk1MDgzNmVkYjQ5MTAxNzNkM2JlMmYyNmFkNzM3MDkzIE1vbiBTZXAgMTcg
MDA6MDA6MDAgMjAwMQpGcm9tOiBMaXUgSmluc29uZyA8amluc29uZy5saXVAaW50ZWwuY29tPgpE
YXRlOiBTdW4sIDExIERlYyAyMDExIDE1OjQyOjAzICswODAwClN1YmplY3Q6IFtQQVRDSCAwNC8x
MF0gWGVuOiBBZGQgcGNwdSBob3RhZGQgc3VwcG9ydCB0byBwdm9wcyBkb20wLgoKVGhpcyBwYXRj
aCByZWJhc2VkIGZyb20gSmVyZW15J3MgcHZvcHMgY29tbWl0CjMxMjk4ODRiYzc1ZDdlNjU3OGJl
NzQ5OWFjMDRhMDZkOWZjNWIzMWQKClRoaXMgcGF0Y2ggaW1wbGVtZW50IENQVSBob3RwbHVnIGNh
bGxiYWNrIGluIHhlbiBhY3BpX3Byb2Nlc3Nvci4gVXNlcgpjYW4gbGF0ZXIgYnJpbmcgdGhlIHBj
cHUgb25saW5lIHRocm91Z2ggc3lzZnMgaW50ZXJmYWNlLgoKeGVuX2dldF9hcGljX2lkKCkgaXMg
bW9zdGx5IGR1cGxpY2F0ZWQgd2l0aCB0aGUgZ2V0X2NwdV9pZCgpIGluCmRyaXZlci9hY3BpL3By
b2Nlc3Nvcl9jb3JlLmMsIGJ1dCBpdCBzaG91bGQgYmUgb2sgc2luY2UgaXQgaGFzIGJlZW4KZHVw
bGljYXRlZCBpbiBhcmNoIGRpcmVjdG9yeSBhbHJlYWR5IGJ5IHVwc3RyZWFtIGtlcm5lbC4KCk9u
ZSB0aGluZyBsZWZ0IGlzLCBjdXJyZW50bHkgdGhlIGFjcGlfcHJvY2Vzc29yJ3MgaWQgaXMgcXVp
dGUKY29uZnVzaW5nIChpdCBpcyBpbiBmYWN0IHdpdGggdmNwdSdzIGRvbTAgY3B1X2lkKS4gV2ls
bCB1cGRhdGUgaXQgd2l0aAp4ZW4ncyBjcHVpZCB0aHJvdWdoIHRoZSBwY3B1IGludGVyZmFjZS4g
QnV0IHRvIGFjaGlldmUgaXQsIHdlIG5lZWQKaW52ZXN0aWdhdGUgbW9yZSBvbiB0aGUgcHItPmlk
LCBhbmQgYWxzbyB3ZSBuZWVkIGNoYW5nZSB0aGUgcGNwdSBsb2dpYwp0byB1c2Ugc3Bpbl9sb2Nr
LCBpbnN0ZWFkIG9mIG11dGV4IGZvciB0aGUgcGNwdSBsaXN0LiBUaGF0IHdpbGwgYmUKbmV4dCBz
dGVwLgoKU2lnbmVkLW9mZi1ieTogTGl1LCBKaW5zb25nIDxqaW5zb25nLmxpdUBpbnRlbC5jb20+
ClNpZ25lZC1vZmYtYnk6IEppYW5nLCBZdW5ob25nIDx5dW5ob25nLmppYW5nQGludGVsLmNvbT4K
U2lnbmVkLW9mZi1ieTogSmVyZW15IEZpdHpoYXJkaW5nZSA8amVyZW15LmZpdHpoYXJkaW5nZUBj
aXRyaXguY29tPgotLS0KIGRyaXZlcnMveGVuL2FjcGlfcHJvY2Vzc29yLmMgICAgIHwgIDExNCAr
KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrLQogaW5jbHVkZS94ZW4vaW50ZXJm
YWNlL3BsYXRmb3JtLmggfCAgIDEwICsrKy0KIDIgZmlsZXMgY2hhbmdlZCwgMTIyIGluc2VydGlv
bnMoKyksIDIgZGVsZXRpb25zKC0pCgpkaWZmIC0tZ2l0IGEvZHJpdmVycy94ZW4vYWNwaV9wcm9j
ZXNzb3IuYyBiL2RyaXZlcnMveGVuL2FjcGlfcHJvY2Vzc29yLmMKaW5kZXggMzI3YTU2ZS4uYWNh
YjQ5YiAxMDA2NDQKLS0tIGEvZHJpdmVycy94ZW4vYWNwaV9wcm9jZXNzb3IuYworKysgYi9kcml2
ZXJzL3hlbi9hY3BpX3Byb2Nlc3Nvci5jCkBAIC0yMiwxMiArMjIsMTkgQEAKICNpbmNsdWRlIDxs
aW51eC9jcHVmcmVxLmg+CiAjaW5jbHVkZSA8YWNwaS9wcm9jZXNzb3IuaD4KICNpbmNsdWRlIDx4
ZW4vYWNwaS5oPgorI2luY2x1ZGUgPHhlbi9wY3B1Lmg+CiAKICNpbmNsdWRlIDx4ZW4vaW50ZXJm
YWNlL3BsYXRmb3JtLmg+CiAjaW5jbHVkZSA8YXNtL3hlbi9oeXBlcmNhbGwuaD4KICNpbmNsdWRl
IDxhc20veGVuL2h5cGVydmlzb3IuaD4KIAotc3RhdGljIHN0cnVjdCBwcm9jZXNzb3JfY250bF94
ZW5fb3BzIHhlbl9vcHM7CitzdGF0aWMgaW50IHhlbl9nZXRfYXBpY19pZChhY3BpX2hhbmRsZSBo
YW5kbGUpOworc3RhdGljIGludCB4ZW5fY3B1X2hvdHBsdWdfbm90aWZpZXIoc3RydWN0IGFjcGlf
cHJvY2Vzc29yICpwciwgaW50IGV2ZW50KTsKKworc3RhdGljIHN0cnVjdCBwcm9jZXNzb3JfY250
bF94ZW5fb3BzIHhlbl9vcHMgPSB7CisJLmhvdHBsdWcgPSB4ZW5fY3B1X2hvdHBsdWdfbm90aWZp
ZXIsCit9OworCiBpbnQgcHJvY2Vzc29yX2NudGxfeGVuX25vdGlmeShzdHJ1Y3QgYWNwaV9wcm9j
ZXNzb3IgKnByLCBpbnQgZXZlbnQsIGludCB0eXBlKQogewogCWludCByZXQgPSAtRUlOVkFMOwpA
QCAtNDEsNiArNDgsMTggQEAgaW50IHByb2Nlc3Nvcl9jbnRsX3hlbl9ub3RpZnkoc3RydWN0IGFj
cGlfcHJvY2Vzc29yICpwciwgaW50IGV2ZW50LCBpbnQgdHlwZSkKIAogCQlyZXQgPSB4ZW5fb3Bz
LnBtX29wc1t0eXBlXShwciwgZXZlbnQpOwogCQlicmVhazsKKwljYXNlIFBST0NFU1NPUl9IT1RQ
TFVHOgorCXsKKwkJaW50IGFwaWNfaWQ7CisKKwkJYXBpY19pZCA9IHhlbl9nZXRfYXBpY19pZChw
ci0+aGFuZGxlKTsKKwkJaWYgKGFwaWNfaWQgPCAwKQorCQkJYnJlYWs7CisJCWlmICh4ZW5fb3Bz
LmhvdHBsdWcpCisJCQlyZXQgPSB4ZW5fb3BzLmhvdHBsdWcocHIsIHR5cGUpOworCQl4ZW5fcGNw
dV9ob3RwbHVnKHR5cGUsIGFwaWNfaWQpOworCQlicmVhazsKKwl9CiAJZGVmYXVsdDoKIAkJcHJp
bnRrKEtFUk5fRVJSICJVbnN1cHBvcnQgcHJvY2Vzc29yIGV2ZW50cyAlZC5cbiIsIGV2ZW50KTsK
IAkJYnJlYWs7CkBAIC01MCw2ICs2OSw0OSBAQCBpbnQgcHJvY2Vzc29yX2NudGxfeGVuX25vdGlm
eShzdHJ1Y3QgYWNwaV9wcm9jZXNzb3IgKnByLCBpbnQgZXZlbnQsIGludCB0eXBlKQogfQogRVhQ
T1JUX1NZTUJPTChwcm9jZXNzb3JfY250bF94ZW5fbm90aWZ5KTsKIAorI2lmZGVmIENPTkZJR19B
Q1BJX0hPVFBMVUdfQ1BVCitzdGF0aWMgaW50IHhlbl9nZXRfYXBpY19pZChhY3BpX2hhbmRsZSBo
YW5kbGUpCit7CisJc3RydWN0IGFjcGlfYnVmZmVyIGJ1ZmZlciA9IHsgQUNQSV9BTExPQ0FURV9C
VUZGRVIsIE5VTEwgfTsKKwl1bmlvbiBhY3BpX29iamVjdCAqb2JqOworCXN0cnVjdCBhY3BpX21h
ZHRfbG9jYWxfYXBpYyAqbGFwaWM7CisJdTggcGh5c2lkOworCisJaWYgKEFDUElfRkFJTFVSRShh
Y3BpX2V2YWx1YXRlX29iamVjdChoYW5kbGUsICJfTUFUIiwgTlVMTCwgJmJ1ZmZlcikpKQorCQly
ZXR1cm4gLUVJTlZBTDsKKworCWlmICghYnVmZmVyLmxlbmd0aCB8fCAhYnVmZmVyLnBvaW50ZXIp
CisJCXJldHVybiAtRUlOVkFMOworCisJb2JqID0gYnVmZmVyLnBvaW50ZXI7CisJaWYgKG9iai0+
dHlwZSAhPSBBQ1BJX1RZUEVfQlVGRkVSIHx8CisJICAgIG9iai0+YnVmZmVyLmxlbmd0aCA8IHNp
emVvZigqbGFwaWMpKSB7CisJCWtmcmVlKGJ1ZmZlci5wb2ludGVyKTsKKwkJcmV0dXJuIC1FSU5W
QUw7CisJfQorCisJbGFwaWMgPSAoc3RydWN0IGFjcGlfbWFkdF9sb2NhbF9hcGljICopb2JqLT5i
dWZmZXIucG9pbnRlcjsKKworCWlmIChsYXBpYy0+aGVhZGVyLnR5cGUgIT0gQUNQSV9NQURUX1RZ
UEVfTE9DQUxfQVBJQyB8fAorCSAgICAhKGxhcGljLT5sYXBpY19mbGFncyAmIEFDUElfTUFEVF9F
TkFCTEVEKSkgeworCQlrZnJlZShidWZmZXIucG9pbnRlcik7CisJCXJldHVybiAtRUlOVkFMOwor
CX0KKworCXBoeXNpZCA9IGxhcGljLT5pZDsKKwlrZnJlZShidWZmZXIucG9pbnRlcik7CisJYnVm
ZmVyLmxlbmd0aCA9IEFDUElfQUxMT0NBVEVfQlVGRkVSOworCWJ1ZmZlci5wb2ludGVyID0gTlVM
TDsKKworCXJldHVybiBwaHlzaWQ7Cit9CisjZWxzZQorc3RhdGljIGludCB4ZW5fZ2V0X2FwaWNf
aWQoYWNwaV9oYW5kbGUgaGFuZGxlKQoreworCXJldHVybiAtMTsKK30KKyNlbmRpZgorCiBzdGF0
aWMgaW5saW5lIHZvaWQgeGVuX2NvbnZlcnRfcGN0X3JlZyhzdHJ1Y3QgeGVuX3BjdF9yZWdpc3Rl
ciAqeHBjdCwKIAlzdHJ1Y3QgYWNwaV9wY3RfcmVnaXN0ZXIgKmFwY3QpCiB7CkBAIC0yNDYsNiAr
MzA4LDU2IEBAIHN0YXRpYyBpbnQgeGVuX3B4X25vdGlmaWVyKHN0cnVjdCBhY3BpX3Byb2Nlc3Nv
ciAqcHIsIGludCBhY3Rpb24pCiAJcmV0dXJuIHJldDsKIH0KIAorI2lmZGVmIENPTkZJR19BQ1BJ
X0hPVFBMVUdfQ1BVCitzdGF0aWMgaW50IHhlbl9jcHVfaG90cGx1Z19ub3RpZmllcihzdHJ1Y3Qg
YWNwaV9wcm9jZXNzb3IgKnByLCBpbnQgZXZlbnQpCit7CisJaW50IHJldCA9IC1FSU5WQUw7CisJ
dWludDMyX3QgYXBpY19pZDsKKwl1bnNpZ25lZCBsb25nIGxvbmcgcHhtOworCWFjcGlfc3RhdHVz
IHN0YXR1cyA9IDA7CisKKwl4ZW5fcGxhdGZvcm1fb3BfdCBvcCA9IHsKKwkJLmludGVyZmFjZV92
ZXJzaW9uICA9IFhFTlBGX0lOVEVSRkFDRV9WRVJTSU9OLAorCX07CisKKwlhcGljX2lkID0geGVu
X2dldF9hcGljX2lkKHByLT5oYW5kbGUpOworCWlmIChhcGljX2lkIDwgMCkgeworCQlwcmludGso
S0VSTl9XQVJOSU5HICJDYW4ndCBnZXQgYXBpY19pZCBmb3IgYWNwaV9pZCAleFxuIiwKKwkJICBw
ci0+YWNwaV9pZCk7CisJCXJldHVybiAtMTsKKwl9CisKKwlzdGF0dXMgPSBhY3BpX2V2YWx1YXRl
X2ludGVnZXIocHItPmhhbmRsZSwgIl9QWE0iLAorCSAgTlVMTCwgJnB4bSk7CisJaWYgKEFDUElf
RkFJTFVSRShzdGF0dXMpKSB7CisJCXByaW50ayhLRVJOX1dBUk5JTkcgImNhbid0IGdldCBweG0g
Zm9yIGFjcGlfaWQgJXhcbiIsCisJCSAgcHItPmFjcGlfaWQpOworCQlyZXR1cm4gLTE7CisJfQor
CisJc3dpdGNoIChldmVudCkgeworCWNhc2UgSE9UUExVR19UWVBFX0FERDoKKwkJb3AuY21kID0g
WEVOUEZfY3B1X2hvdGFkZDsKKwkJb3AudS5jcHVfYWRkLmFwaWNfaWQgPSBhcGljX2lkOworCQlv
cC51LmNwdV9hZGQuYWNwaV9pZCA9IHByLT5hY3BpX2lkOworCQlvcC51LmNwdV9hZGQucHhtID0g
cHhtOworCQlyZXQgPSBIWVBFUlZJU09SX2RvbTBfb3AoJm9wKTsKKwkJYnJlYWs7CisJY2FzZSBI
T1RQTFVHX1RZUEVfUkVNT1ZFOgorCQlwcmludGsoS0VSTl9XQVJOSU5HICJYZW4gbm90IHN1cHBv
cnQgQ1BVIGhvdHJlbW92ZVxuIik7CisJCXJldCA9IC1FTk9TWVM7CisJCWJyZWFrOworCX0KKwor
CXJldHVybiByZXQ7Cit9CisjZWxzZQorc3RhdGljIGludCB4ZW5fY3B1X2hvdHBsdWdfbm90aWZp
ZXIoc3RydWN0IGFjcGlfcHJvY2Vzc29yICpwciwgaW50IGV2ZW50KQoreworCXJldHVybiAtRU5P
U1lTOworfQorI2VuZGlmCisKIHN0YXRpYyBpbnQgX19pbml0IHhlbl9hY3BpX3Byb2Nlc3Nvcl9l
eHRjbnRsX2luaXQodm9pZCkKIHsKIAl1bnNpZ25lZCBpbnQgcG1iaXRzOwpkaWZmIC0tZ2l0IGEv
aW5jbHVkZS94ZW4vaW50ZXJmYWNlL3BsYXRmb3JtLmggYi9pbmNsdWRlL3hlbi9pbnRlcmZhY2Uv
cGxhdGZvcm0uaAppbmRleCA0N2ZmZTE2Li45ZmQ2YjA3IDEwMDY0NAotLS0gYS9pbmNsdWRlL3hl
bi9pbnRlcmZhY2UvcGxhdGZvcm0uaAorKysgYi9pbmNsdWRlL3hlbi9pbnRlcmZhY2UvcGxhdGZv
cm0uaApAQCAtMzE3LDExICszMTcsMTggQEAgREVGSU5FX0dVRVNUX0hBTkRMRV9TVFJVQ1QoeGVu
cGZfcGNwdWluZm9fdCk7CiAjZGVmaW5lIFhFTlBGX2NwdV9vbmxpbmUgICAgNTYKICNkZWZpbmUg
WEVOUEZfY3B1X29mZmxpbmUgICA1Nwogc3RydWN0IHhlbnBmX2NwdV9vbCB7Ci0gICAgdWludDMy
X3QgY3B1aWQ7CisJdWludDMyX3QgY3B1aWQ7CiB9OwogdHlwZWRlZiBzdHJ1Y3QgeGVucGZfY3B1
X29sIHhlbnBmX2NwdV9vbF90OwogREVGSU5FX0dVRVNUX0hBTkRMRV9TVFJVQ1QoeGVucGZfY3B1
X29sX3QpOwogCisjZGVmaW5lIFhFTlBGX2NwdV9ob3RhZGQgICAgNTgKK3N0cnVjdCB4ZW5wZl9j
cHVfaG90YWRkIHsKKwl1aW50MzJfdCBhcGljX2lkOworCXVpbnQzMl90IGFjcGlfaWQ7CisJdWlu
dDMyX3QgcHhtOworfTsKKwogc3RydWN0IHhlbl9wbGF0Zm9ybV9vcCB7CiAJdWludDMyX3QgY21k
OwogCXVpbnQzMl90IGludGVyZmFjZV92ZXJzaW9uOyAvKiBYRU5QRl9JTlRFUkZBQ0VfVkVSU0lP
TiAqLwpAQCAtMzM5LDYgKzM0Niw3IEBAIHN0cnVjdCB4ZW5fcGxhdGZvcm1fb3AgewogCQlzdHJ1
Y3QgeGVucGZfc2V0X3Byb2Nlc3Nvcl9wbWluZm8gc2V0X3BtaW5mbzsKIAkJc3RydWN0IHhlbnBm
X3BjcHVpbmZvICAgICAgICAgIHBjcHVfaW5mbzsKIAkJc3RydWN0IHhlbnBmX2NwdV9vbCAgICAg
ICAgICAgIGNwdV9vbDsKKwkJc3RydWN0IHhlbnBmX2NwdV9ob3RhZGQgICAgICAgIGNwdV9hZGQ7
CiAJCXVpbnQ4X3QgICAgICAgICAgICAgICAgICAgICAgICBwYWRbMTI4XTsKIAl9IHU7CiB9Owot
LSAKMS42LjUuNgoK

--_002_DE8DF0795D48FD4CA783C40EC82923358A3FSHSMSX101ccrcorpint_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--_002_DE8DF0795D48FD4CA783C40EC82923358A3FSHSMSX101ccrcorpint_--


From xen-devel-bounces@lists.xensource.com Thu Dec 22 10:05:43 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 Dec 2011 10:05:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdfWn-00051u-0q; Thu, 22 Dec 2011 10:05:33 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1RdfWl-00050v-1p
	for xen-devel@lists.xensource.com; Thu, 22 Dec 2011 10:05:31 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1324548322!8268192!1
X-Originating-IP: [143.182.124.37]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjE1ODY2\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22237 invoked from network); 22 Dec 2011 10:05:23 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37)
	by server-2.tower-182.messagelabs.com with SMTP;
	22 Dec 2011 10:05:23 -0000
Received: from azsmga002.ch.intel.com ([10.2.17.35])
	by azsmga102.ch.intel.com with ESMTP; 22 Dec 2011 02:05:21 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208,223";a="49700315"
Received: from pgsmsx603.gar.corp.intel.com ([10.221.43.87])
	by AZSMGA002.ch.intel.com with ESMTP; 22 Dec 2011 02:05:20 -0800
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	pgsmsx603.gar.corp.intel.com (10.221.43.87) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Thu, 22 Dec 2011 18:05:18 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.38]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.199]) with mapi id
	14.01.0355.002; Thu, 22 Dec 2011 18:05:16 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: "konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Thread-Topic: [PATCH 04/10] Xen: Add pcpu hotadd support to pvops dom0.
Thread-Index: AczAkTOfZhw6tXtFTauz70dtFp0JKA==
Date: Thu, 22 Dec 2011 10:05:16 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC82923358A3F@SHSMSX101.ccr.corp.intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
Content-Type: multipart/mixed;
	boundary="_002_DE8DF0795D48FD4CA783C40EC82923358A3FSHSMSX101ccrcorpint_"
MIME-Version: 1.0
Cc: "Jiang, Yunhong" <yunhong.jiang@intel.com>,
	"jeremy.fitzhardinge@citrix.com" <jeremy.fitzhardinge@citrix.com>
Subject: [Xen-devel] [PATCH 04/10] Xen: Add pcpu hotadd support to pvops
	dom0.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--_002_DE8DF0795D48FD4CA783C40EC82923358A3FSHSMSX101ccrcorpint_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

>From 5f5eb7bf950836edb4910173d3be2f26ad737093 Mon Sep 17 00:00:00 2001
From: Liu Jinsong <jinsong.liu@intel.com>
Date: Sun, 11 Dec 2011 15:42:03 +0800
Subject: [PATCH 04/10] Xen: Add pcpu hotadd support to pvops dom0.

This patch rebased from Jeremy's pvops commit
3129884bc75d7e6578be7499ac04a06d9fc5b31d

This patch implement CPU hotplug callback in xen acpi_processor. User
can later bring the pcpu online through sysfs interface.

xen_get_apic_id() is mostly duplicated with the get_cpu_id() in
driver/acpi/processor_core.c, but it should be ok since it has been
duplicated in arch directory already by upstream kernel.

One thing left is, currently the acpi_processor's id is quite
confusing (it is in fact with vcpu's dom0 cpu_id). Will update it with
xen's cpuid through the pcpu interface. But to achieve it, we need
investigate more on the pr->id, and also we need change the pcpu logic
to use spin_lock, instead of mutex for the pcpu list. That will be
next step.

Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
Signed-off-by: Jiang, Yunhong <yunhong.jiang@intel.com>
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
---
 drivers/xen/acpi_processor.c     |  114 ++++++++++++++++++++++++++++++++++=
+++-
 include/xen/interface/platform.h |   10 +++-
 2 files changed, 122 insertions(+), 2 deletions(-)

diff --git a/drivers/xen/acpi_processor.c b/drivers/xen/acpi_processor.c
index 327a56e..acab49b 100644
--- a/drivers/xen/acpi_processor.c
+++ b/drivers/xen/acpi_processor.c
@@ -22,12 +22,19 @@
 #include <linux/cpufreq.h>
 #include <acpi/processor.h>
 #include <xen/acpi.h>
+#include <xen/pcpu.h>
=20
 #include <xen/interface/platform.h>
 #include <asm/xen/hypercall.h>
 #include <asm/xen/hypervisor.h>
=20
-static struct processor_cntl_xen_ops xen_ops;
+static int xen_get_apic_id(acpi_handle handle);
+static int xen_cpu_hotplug_notifier(struct acpi_processor *pr, int event);
+
+static struct processor_cntl_xen_ops xen_ops =3D {
+	.hotplug =3D xen_cpu_hotplug_notifier,
+};
+
 int processor_cntl_xen_notify(struct acpi_processor *pr, int event, int ty=
pe)
 {
 	int ret =3D -EINVAL;
@@ -41,6 +48,18 @@ int processor_cntl_xen_notify(struct acpi_processor *pr,=
 int event, int type)
=20
 		ret =3D xen_ops.pm_ops[type](pr, event);
 		break;
+	case PROCESSOR_HOTPLUG:
+	{
+		int apic_id;
+
+		apic_id =3D xen_get_apic_id(pr->handle);
+		if (apic_id < 0)
+			break;
+		if (xen_ops.hotplug)
+			ret =3D xen_ops.hotplug(pr, type);
+		xen_pcpu_hotplug(type, apic_id);
+		break;
+	}
 	default:
 		printk(KERN_ERR "Unsupport processor events %d.\n", event);
 		break;
@@ -50,6 +69,49 @@ int processor_cntl_xen_notify(struct acpi_processor *pr,=
 int event, int type)
 }
 EXPORT_SYMBOL(processor_cntl_xen_notify);
=20
+#ifdef CONFIG_ACPI_HOTPLUG_CPU
+static int xen_get_apic_id(acpi_handle handle)
+{
+	struct acpi_buffer buffer =3D { ACPI_ALLOCATE_BUFFER, NULL };
+	union acpi_object *obj;
+	struct acpi_madt_local_apic *lapic;
+	u8 physid;
+
+	if (ACPI_FAILURE(acpi_evaluate_object(handle, "_MAT", NULL, &buffer)))
+		return -EINVAL;
+
+	if (!buffer.length || !buffer.pointer)
+		return -EINVAL;
+
+	obj =3D buffer.pointer;
+	if (obj->type !=3D ACPI_TYPE_BUFFER ||
+	    obj->buffer.length < sizeof(*lapic)) {
+		kfree(buffer.pointer);
+		return -EINVAL;
+	}
+
+	lapic =3D (struct acpi_madt_local_apic *)obj->buffer.pointer;
+
+	if (lapic->header.type !=3D ACPI_MADT_TYPE_LOCAL_APIC ||
+	    !(lapic->lapic_flags & ACPI_MADT_ENABLED)) {
+		kfree(buffer.pointer);
+		return -EINVAL;
+	}
+
+	physid =3D lapic->id;
+	kfree(buffer.pointer);
+	buffer.length =3D ACPI_ALLOCATE_BUFFER;
+	buffer.pointer =3D NULL;
+
+	return physid;
+}
+#else
+static int xen_get_apic_id(acpi_handle handle)
+{
+	return -1;
+}
+#endif
+
 static inline void xen_convert_pct_reg(struct xen_pct_register *xpct,
 	struct acpi_pct_register *apct)
 {
@@ -246,6 +308,56 @@ static int xen_px_notifier(struct acpi_processor *pr, =
int action)
 	return ret;
 }
=20
+#ifdef CONFIG_ACPI_HOTPLUG_CPU
+static int xen_cpu_hotplug_notifier(struct acpi_processor *pr, int event)
+{
+	int ret =3D -EINVAL;
+	uint32_t apic_id;
+	unsigned long long pxm;
+	acpi_status status =3D 0;
+
+	xen_platform_op_t op =3D {
+		.interface_version  =3D XENPF_INTERFACE_VERSION,
+	};
+
+	apic_id =3D xen_get_apic_id(pr->handle);
+	if (apic_id < 0) {
+		printk(KERN_WARNING "Can't get apic_id for acpi_id %x\n",
+		  pr->acpi_id);
+		return -1;
+	}
+
+	status =3D acpi_evaluate_integer(pr->handle, "_PXM",
+	  NULL, &pxm);
+	if (ACPI_FAILURE(status)) {
+		printk(KERN_WARNING "can't get pxm for acpi_id %x\n",
+		  pr->acpi_id);
+		return -1;
+	}
+
+	switch (event) {
+	case HOTPLUG_TYPE_ADD:
+		op.cmd =3D XENPF_cpu_hotadd;
+		op.u.cpu_add.apic_id =3D apic_id;
+		op.u.cpu_add.acpi_id =3D pr->acpi_id;
+		op.u.cpu_add.pxm =3D pxm;
+		ret =3D HYPERVISOR_dom0_op(&op);
+		break;
+	case HOTPLUG_TYPE_REMOVE:
+		printk(KERN_WARNING "Xen not support CPU hotremove\n");
+		ret =3D -ENOSYS;
+		break;
+	}
+
+	return ret;
+}
+#else
+static int xen_cpu_hotplug_notifier(struct acpi_processor *pr, int event)
+{
+	return -ENOSYS;
+}
+#endif
+
 static int __init xen_acpi_processor_extcntl_init(void)
 {
 	unsigned int pmbits;
diff --git a/include/xen/interface/platform.h b/include/xen/interface/platf=
orm.h
index 47ffe16..9fd6b07 100644
--- a/include/xen/interface/platform.h
+++ b/include/xen/interface/platform.h
@@ -317,11 +317,18 @@ DEFINE_GUEST_HANDLE_STRUCT(xenpf_pcpuinfo_t);
 #define XENPF_cpu_online    56
 #define XENPF_cpu_offline   57
 struct xenpf_cpu_ol {
-    uint32_t cpuid;
+	uint32_t cpuid;
 };
 typedef struct xenpf_cpu_ol xenpf_cpu_ol_t;
 DEFINE_GUEST_HANDLE_STRUCT(xenpf_cpu_ol_t);
=20
+#define XENPF_cpu_hotadd    58
+struct xenpf_cpu_hotadd {
+	uint32_t apic_id;
+	uint32_t acpi_id;
+	uint32_t pxm;
+};
+
 struct xen_platform_op {
 	uint32_t cmd;
 	uint32_t interface_version; /* XENPF_INTERFACE_VERSION */
@@ -339,6 +346,7 @@ struct xen_platform_op {
 		struct xenpf_set_processor_pminfo set_pminfo;
 		struct xenpf_pcpuinfo          pcpu_info;
 		struct xenpf_cpu_ol            cpu_ol;
+		struct xenpf_cpu_hotadd        cpu_add;
 		uint8_t                        pad[128];
 	} u;
 };
--=20
1.6.5.6

--_002_DE8DF0795D48FD4CA783C40EC82923358A3FSHSMSX101ccrcorpint_
Content-Type: application/octet-stream;
	name="0004-Xen-Add-pcpu-hotadd-support-to-pvops-dom0.patch"
Content-Description: 0004-Xen-Add-pcpu-hotadd-support-to-pvops-dom0.patch
Content-Disposition: attachment;
	filename="0004-Xen-Add-pcpu-hotadd-support-to-pvops-dom0.patch"; size=6111;
	creation-date="Wed, 14 Dec 2011 15:20:15 GMT";
	modification-date="Wed, 14 Dec 2011 15:03:34 GMT"
Content-Transfer-Encoding: base64

RnJvbSA1ZjVlYjdiZjk1MDgzNmVkYjQ5MTAxNzNkM2JlMmYyNmFkNzM3MDkzIE1vbiBTZXAgMTcg
MDA6MDA6MDAgMjAwMQpGcm9tOiBMaXUgSmluc29uZyA8amluc29uZy5saXVAaW50ZWwuY29tPgpE
YXRlOiBTdW4sIDExIERlYyAyMDExIDE1OjQyOjAzICswODAwClN1YmplY3Q6IFtQQVRDSCAwNC8x
MF0gWGVuOiBBZGQgcGNwdSBob3RhZGQgc3VwcG9ydCB0byBwdm9wcyBkb20wLgoKVGhpcyBwYXRj
aCByZWJhc2VkIGZyb20gSmVyZW15J3MgcHZvcHMgY29tbWl0CjMxMjk4ODRiYzc1ZDdlNjU3OGJl
NzQ5OWFjMDRhMDZkOWZjNWIzMWQKClRoaXMgcGF0Y2ggaW1wbGVtZW50IENQVSBob3RwbHVnIGNh
bGxiYWNrIGluIHhlbiBhY3BpX3Byb2Nlc3Nvci4gVXNlcgpjYW4gbGF0ZXIgYnJpbmcgdGhlIHBj
cHUgb25saW5lIHRocm91Z2ggc3lzZnMgaW50ZXJmYWNlLgoKeGVuX2dldF9hcGljX2lkKCkgaXMg
bW9zdGx5IGR1cGxpY2F0ZWQgd2l0aCB0aGUgZ2V0X2NwdV9pZCgpIGluCmRyaXZlci9hY3BpL3By
b2Nlc3Nvcl9jb3JlLmMsIGJ1dCBpdCBzaG91bGQgYmUgb2sgc2luY2UgaXQgaGFzIGJlZW4KZHVw
bGljYXRlZCBpbiBhcmNoIGRpcmVjdG9yeSBhbHJlYWR5IGJ5IHVwc3RyZWFtIGtlcm5lbC4KCk9u
ZSB0aGluZyBsZWZ0IGlzLCBjdXJyZW50bHkgdGhlIGFjcGlfcHJvY2Vzc29yJ3MgaWQgaXMgcXVp
dGUKY29uZnVzaW5nIChpdCBpcyBpbiBmYWN0IHdpdGggdmNwdSdzIGRvbTAgY3B1X2lkKS4gV2ls
bCB1cGRhdGUgaXQgd2l0aAp4ZW4ncyBjcHVpZCB0aHJvdWdoIHRoZSBwY3B1IGludGVyZmFjZS4g
QnV0IHRvIGFjaGlldmUgaXQsIHdlIG5lZWQKaW52ZXN0aWdhdGUgbW9yZSBvbiB0aGUgcHItPmlk
LCBhbmQgYWxzbyB3ZSBuZWVkIGNoYW5nZSB0aGUgcGNwdSBsb2dpYwp0byB1c2Ugc3Bpbl9sb2Nr
LCBpbnN0ZWFkIG9mIG11dGV4IGZvciB0aGUgcGNwdSBsaXN0LiBUaGF0IHdpbGwgYmUKbmV4dCBz
dGVwLgoKU2lnbmVkLW9mZi1ieTogTGl1LCBKaW5zb25nIDxqaW5zb25nLmxpdUBpbnRlbC5jb20+
ClNpZ25lZC1vZmYtYnk6IEppYW5nLCBZdW5ob25nIDx5dW5ob25nLmppYW5nQGludGVsLmNvbT4K
U2lnbmVkLW9mZi1ieTogSmVyZW15IEZpdHpoYXJkaW5nZSA8amVyZW15LmZpdHpoYXJkaW5nZUBj
aXRyaXguY29tPgotLS0KIGRyaXZlcnMveGVuL2FjcGlfcHJvY2Vzc29yLmMgICAgIHwgIDExNCAr
KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrLQogaW5jbHVkZS94ZW4vaW50ZXJm
YWNlL3BsYXRmb3JtLmggfCAgIDEwICsrKy0KIDIgZmlsZXMgY2hhbmdlZCwgMTIyIGluc2VydGlv
bnMoKyksIDIgZGVsZXRpb25zKC0pCgpkaWZmIC0tZ2l0IGEvZHJpdmVycy94ZW4vYWNwaV9wcm9j
ZXNzb3IuYyBiL2RyaXZlcnMveGVuL2FjcGlfcHJvY2Vzc29yLmMKaW5kZXggMzI3YTU2ZS4uYWNh
YjQ5YiAxMDA2NDQKLS0tIGEvZHJpdmVycy94ZW4vYWNwaV9wcm9jZXNzb3IuYworKysgYi9kcml2
ZXJzL3hlbi9hY3BpX3Byb2Nlc3Nvci5jCkBAIC0yMiwxMiArMjIsMTkgQEAKICNpbmNsdWRlIDxs
aW51eC9jcHVmcmVxLmg+CiAjaW5jbHVkZSA8YWNwaS9wcm9jZXNzb3IuaD4KICNpbmNsdWRlIDx4
ZW4vYWNwaS5oPgorI2luY2x1ZGUgPHhlbi9wY3B1Lmg+CiAKICNpbmNsdWRlIDx4ZW4vaW50ZXJm
YWNlL3BsYXRmb3JtLmg+CiAjaW5jbHVkZSA8YXNtL3hlbi9oeXBlcmNhbGwuaD4KICNpbmNsdWRl
IDxhc20veGVuL2h5cGVydmlzb3IuaD4KIAotc3RhdGljIHN0cnVjdCBwcm9jZXNzb3JfY250bF94
ZW5fb3BzIHhlbl9vcHM7CitzdGF0aWMgaW50IHhlbl9nZXRfYXBpY19pZChhY3BpX2hhbmRsZSBo
YW5kbGUpOworc3RhdGljIGludCB4ZW5fY3B1X2hvdHBsdWdfbm90aWZpZXIoc3RydWN0IGFjcGlf
cHJvY2Vzc29yICpwciwgaW50IGV2ZW50KTsKKworc3RhdGljIHN0cnVjdCBwcm9jZXNzb3JfY250
bF94ZW5fb3BzIHhlbl9vcHMgPSB7CisJLmhvdHBsdWcgPSB4ZW5fY3B1X2hvdHBsdWdfbm90aWZp
ZXIsCit9OworCiBpbnQgcHJvY2Vzc29yX2NudGxfeGVuX25vdGlmeShzdHJ1Y3QgYWNwaV9wcm9j
ZXNzb3IgKnByLCBpbnQgZXZlbnQsIGludCB0eXBlKQogewogCWludCByZXQgPSAtRUlOVkFMOwpA
QCAtNDEsNiArNDgsMTggQEAgaW50IHByb2Nlc3Nvcl9jbnRsX3hlbl9ub3RpZnkoc3RydWN0IGFj
cGlfcHJvY2Vzc29yICpwciwgaW50IGV2ZW50LCBpbnQgdHlwZSkKIAogCQlyZXQgPSB4ZW5fb3Bz
LnBtX29wc1t0eXBlXShwciwgZXZlbnQpOwogCQlicmVhazsKKwljYXNlIFBST0NFU1NPUl9IT1RQ
TFVHOgorCXsKKwkJaW50IGFwaWNfaWQ7CisKKwkJYXBpY19pZCA9IHhlbl9nZXRfYXBpY19pZChw
ci0+aGFuZGxlKTsKKwkJaWYgKGFwaWNfaWQgPCAwKQorCQkJYnJlYWs7CisJCWlmICh4ZW5fb3Bz
LmhvdHBsdWcpCisJCQlyZXQgPSB4ZW5fb3BzLmhvdHBsdWcocHIsIHR5cGUpOworCQl4ZW5fcGNw
dV9ob3RwbHVnKHR5cGUsIGFwaWNfaWQpOworCQlicmVhazsKKwl9CiAJZGVmYXVsdDoKIAkJcHJp
bnRrKEtFUk5fRVJSICJVbnN1cHBvcnQgcHJvY2Vzc29yIGV2ZW50cyAlZC5cbiIsIGV2ZW50KTsK
IAkJYnJlYWs7CkBAIC01MCw2ICs2OSw0OSBAQCBpbnQgcHJvY2Vzc29yX2NudGxfeGVuX25vdGlm
eShzdHJ1Y3QgYWNwaV9wcm9jZXNzb3IgKnByLCBpbnQgZXZlbnQsIGludCB0eXBlKQogfQogRVhQ
T1JUX1NZTUJPTChwcm9jZXNzb3JfY250bF94ZW5fbm90aWZ5KTsKIAorI2lmZGVmIENPTkZJR19B
Q1BJX0hPVFBMVUdfQ1BVCitzdGF0aWMgaW50IHhlbl9nZXRfYXBpY19pZChhY3BpX2hhbmRsZSBo
YW5kbGUpCit7CisJc3RydWN0IGFjcGlfYnVmZmVyIGJ1ZmZlciA9IHsgQUNQSV9BTExPQ0FURV9C
VUZGRVIsIE5VTEwgfTsKKwl1bmlvbiBhY3BpX29iamVjdCAqb2JqOworCXN0cnVjdCBhY3BpX21h
ZHRfbG9jYWxfYXBpYyAqbGFwaWM7CisJdTggcGh5c2lkOworCisJaWYgKEFDUElfRkFJTFVSRShh
Y3BpX2V2YWx1YXRlX29iamVjdChoYW5kbGUsICJfTUFUIiwgTlVMTCwgJmJ1ZmZlcikpKQorCQly
ZXR1cm4gLUVJTlZBTDsKKworCWlmICghYnVmZmVyLmxlbmd0aCB8fCAhYnVmZmVyLnBvaW50ZXIp
CisJCXJldHVybiAtRUlOVkFMOworCisJb2JqID0gYnVmZmVyLnBvaW50ZXI7CisJaWYgKG9iai0+
dHlwZSAhPSBBQ1BJX1RZUEVfQlVGRkVSIHx8CisJICAgIG9iai0+YnVmZmVyLmxlbmd0aCA8IHNp
emVvZigqbGFwaWMpKSB7CisJCWtmcmVlKGJ1ZmZlci5wb2ludGVyKTsKKwkJcmV0dXJuIC1FSU5W
QUw7CisJfQorCisJbGFwaWMgPSAoc3RydWN0IGFjcGlfbWFkdF9sb2NhbF9hcGljICopb2JqLT5i
dWZmZXIucG9pbnRlcjsKKworCWlmIChsYXBpYy0+aGVhZGVyLnR5cGUgIT0gQUNQSV9NQURUX1RZ
UEVfTE9DQUxfQVBJQyB8fAorCSAgICAhKGxhcGljLT5sYXBpY19mbGFncyAmIEFDUElfTUFEVF9F
TkFCTEVEKSkgeworCQlrZnJlZShidWZmZXIucG9pbnRlcik7CisJCXJldHVybiAtRUlOVkFMOwor
CX0KKworCXBoeXNpZCA9IGxhcGljLT5pZDsKKwlrZnJlZShidWZmZXIucG9pbnRlcik7CisJYnVm
ZmVyLmxlbmd0aCA9IEFDUElfQUxMT0NBVEVfQlVGRkVSOworCWJ1ZmZlci5wb2ludGVyID0gTlVM
TDsKKworCXJldHVybiBwaHlzaWQ7Cit9CisjZWxzZQorc3RhdGljIGludCB4ZW5fZ2V0X2FwaWNf
aWQoYWNwaV9oYW5kbGUgaGFuZGxlKQoreworCXJldHVybiAtMTsKK30KKyNlbmRpZgorCiBzdGF0
aWMgaW5saW5lIHZvaWQgeGVuX2NvbnZlcnRfcGN0X3JlZyhzdHJ1Y3QgeGVuX3BjdF9yZWdpc3Rl
ciAqeHBjdCwKIAlzdHJ1Y3QgYWNwaV9wY3RfcmVnaXN0ZXIgKmFwY3QpCiB7CkBAIC0yNDYsNiAr
MzA4LDU2IEBAIHN0YXRpYyBpbnQgeGVuX3B4X25vdGlmaWVyKHN0cnVjdCBhY3BpX3Byb2Nlc3Nv
ciAqcHIsIGludCBhY3Rpb24pCiAJcmV0dXJuIHJldDsKIH0KIAorI2lmZGVmIENPTkZJR19BQ1BJ
X0hPVFBMVUdfQ1BVCitzdGF0aWMgaW50IHhlbl9jcHVfaG90cGx1Z19ub3RpZmllcihzdHJ1Y3Qg
YWNwaV9wcm9jZXNzb3IgKnByLCBpbnQgZXZlbnQpCit7CisJaW50IHJldCA9IC1FSU5WQUw7CisJ
dWludDMyX3QgYXBpY19pZDsKKwl1bnNpZ25lZCBsb25nIGxvbmcgcHhtOworCWFjcGlfc3RhdHVz
IHN0YXR1cyA9IDA7CisKKwl4ZW5fcGxhdGZvcm1fb3BfdCBvcCA9IHsKKwkJLmludGVyZmFjZV92
ZXJzaW9uICA9IFhFTlBGX0lOVEVSRkFDRV9WRVJTSU9OLAorCX07CisKKwlhcGljX2lkID0geGVu
X2dldF9hcGljX2lkKHByLT5oYW5kbGUpOworCWlmIChhcGljX2lkIDwgMCkgeworCQlwcmludGso
S0VSTl9XQVJOSU5HICJDYW4ndCBnZXQgYXBpY19pZCBmb3IgYWNwaV9pZCAleFxuIiwKKwkJICBw
ci0+YWNwaV9pZCk7CisJCXJldHVybiAtMTsKKwl9CisKKwlzdGF0dXMgPSBhY3BpX2V2YWx1YXRl
X2ludGVnZXIocHItPmhhbmRsZSwgIl9QWE0iLAorCSAgTlVMTCwgJnB4bSk7CisJaWYgKEFDUElf
RkFJTFVSRShzdGF0dXMpKSB7CisJCXByaW50ayhLRVJOX1dBUk5JTkcgImNhbid0IGdldCBweG0g
Zm9yIGFjcGlfaWQgJXhcbiIsCisJCSAgcHItPmFjcGlfaWQpOworCQlyZXR1cm4gLTE7CisJfQor
CisJc3dpdGNoIChldmVudCkgeworCWNhc2UgSE9UUExVR19UWVBFX0FERDoKKwkJb3AuY21kID0g
WEVOUEZfY3B1X2hvdGFkZDsKKwkJb3AudS5jcHVfYWRkLmFwaWNfaWQgPSBhcGljX2lkOworCQlv
cC51LmNwdV9hZGQuYWNwaV9pZCA9IHByLT5hY3BpX2lkOworCQlvcC51LmNwdV9hZGQucHhtID0g
cHhtOworCQlyZXQgPSBIWVBFUlZJU09SX2RvbTBfb3AoJm9wKTsKKwkJYnJlYWs7CisJY2FzZSBI
T1RQTFVHX1RZUEVfUkVNT1ZFOgorCQlwcmludGsoS0VSTl9XQVJOSU5HICJYZW4gbm90IHN1cHBv
cnQgQ1BVIGhvdHJlbW92ZVxuIik7CisJCXJldCA9IC1FTk9TWVM7CisJCWJyZWFrOworCX0KKwor
CXJldHVybiByZXQ7Cit9CisjZWxzZQorc3RhdGljIGludCB4ZW5fY3B1X2hvdHBsdWdfbm90aWZp
ZXIoc3RydWN0IGFjcGlfcHJvY2Vzc29yICpwciwgaW50IGV2ZW50KQoreworCXJldHVybiAtRU5P
U1lTOworfQorI2VuZGlmCisKIHN0YXRpYyBpbnQgX19pbml0IHhlbl9hY3BpX3Byb2Nlc3Nvcl9l
eHRjbnRsX2luaXQodm9pZCkKIHsKIAl1bnNpZ25lZCBpbnQgcG1iaXRzOwpkaWZmIC0tZ2l0IGEv
aW5jbHVkZS94ZW4vaW50ZXJmYWNlL3BsYXRmb3JtLmggYi9pbmNsdWRlL3hlbi9pbnRlcmZhY2Uv
cGxhdGZvcm0uaAppbmRleCA0N2ZmZTE2Li45ZmQ2YjA3IDEwMDY0NAotLS0gYS9pbmNsdWRlL3hl
bi9pbnRlcmZhY2UvcGxhdGZvcm0uaAorKysgYi9pbmNsdWRlL3hlbi9pbnRlcmZhY2UvcGxhdGZv
cm0uaApAQCAtMzE3LDExICszMTcsMTggQEAgREVGSU5FX0dVRVNUX0hBTkRMRV9TVFJVQ1QoeGVu
cGZfcGNwdWluZm9fdCk7CiAjZGVmaW5lIFhFTlBGX2NwdV9vbmxpbmUgICAgNTYKICNkZWZpbmUg
WEVOUEZfY3B1X29mZmxpbmUgICA1Nwogc3RydWN0IHhlbnBmX2NwdV9vbCB7Ci0gICAgdWludDMy
X3QgY3B1aWQ7CisJdWludDMyX3QgY3B1aWQ7CiB9OwogdHlwZWRlZiBzdHJ1Y3QgeGVucGZfY3B1
X29sIHhlbnBmX2NwdV9vbF90OwogREVGSU5FX0dVRVNUX0hBTkRMRV9TVFJVQ1QoeGVucGZfY3B1
X29sX3QpOwogCisjZGVmaW5lIFhFTlBGX2NwdV9ob3RhZGQgICAgNTgKK3N0cnVjdCB4ZW5wZl9j
cHVfaG90YWRkIHsKKwl1aW50MzJfdCBhcGljX2lkOworCXVpbnQzMl90IGFjcGlfaWQ7CisJdWlu
dDMyX3QgcHhtOworfTsKKwogc3RydWN0IHhlbl9wbGF0Zm9ybV9vcCB7CiAJdWludDMyX3QgY21k
OwogCXVpbnQzMl90IGludGVyZmFjZV92ZXJzaW9uOyAvKiBYRU5QRl9JTlRFUkZBQ0VfVkVSU0lP
TiAqLwpAQCAtMzM5LDYgKzM0Niw3IEBAIHN0cnVjdCB4ZW5fcGxhdGZvcm1fb3AgewogCQlzdHJ1
Y3QgeGVucGZfc2V0X3Byb2Nlc3Nvcl9wbWluZm8gc2V0X3BtaW5mbzsKIAkJc3RydWN0IHhlbnBm
X3BjcHVpbmZvICAgICAgICAgIHBjcHVfaW5mbzsKIAkJc3RydWN0IHhlbnBmX2NwdV9vbCAgICAg
ICAgICAgIGNwdV9vbDsKKwkJc3RydWN0IHhlbnBmX2NwdV9ob3RhZGQgICAgICAgIGNwdV9hZGQ7
CiAJCXVpbnQ4X3QgICAgICAgICAgICAgICAgICAgICAgICBwYWRbMTI4XTsKIAl9IHU7CiB9Owot
LSAKMS42LjUuNgoK

--_002_DE8DF0795D48FD4CA783C40EC82923358A3FSHSMSX101ccrcorpint_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--_002_DE8DF0795D48FD4CA783C40EC82923358A3FSHSMSX101ccrcorpint_--


From xen-devel-bounces@lists.xensource.com Thu Dec 22 10:06:30 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 Dec 2011 10:06:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdfXZ-0005AS-LF; Thu, 22 Dec 2011 10:06:21 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1RdfXX-00059S-W4
	for xen-devel@lists.xensource.com; Thu, 22 Dec 2011 10:06:20 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1324548372!6349764!1
X-Originating-IP: [143.182.124.37]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjE1ODY2\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11298 invoked from network); 22 Dec 2011 10:06:13 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37)
	by server-16.tower-174.messagelabs.com with SMTP;
	22 Dec 2011 10:06:13 -0000
Received: from azsmga002.ch.intel.com ([10.2.17.35])
	by azsmga102.ch.intel.com with ESMTP; 22 Dec 2011 02:06:12 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208,223";a="49700552"
Received: from pgsmsx603.gar.corp.intel.com ([10.221.43.87])
	by AZSMGA002.ch.intel.com with ESMTP; 22 Dec 2011 02:06:10 -0800
Received: from pgsmsx101.gar.corp.intel.com (10.221.44.78) by
	pgsmsx603.gar.corp.intel.com (10.221.43.87) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Thu, 22 Dec 2011 18:06:10 +0800
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	PGSMSX101.gar.corp.intel.com (10.221.44.78) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Thu, 22 Dec 2011 18:06:09 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.38]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.199]) with mapi id
	14.01.0355.002; Thu, 22 Dec 2011 18:06:08 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: "konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Thread-Topic: [PATCH 05/10] xen/acpi: Move acpi_memory_info definition to
	public
Thread-Index: AczAkVIpid07nRqpSD6SUyaJttGx8w==
Date: Thu, 22 Dec 2011 10:06:07 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC82923358A54@SHSMSX101.ccr.corp.intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
Content-Type: multipart/mixed;
	boundary="_002_DE8DF0795D48FD4CA783C40EC82923358A54SHSMSX101ccrcorpint_"
MIME-Version: 1.0
Cc: "Jiang, Yunhong" <yunhong.jiang@intel.com>,
	"jeremy.fitzhardinge@citrix.com" <jeremy.fitzhardinge@citrix.com>
Subject: [Xen-devel] [PATCH 05/10] xen/acpi: Move acpi_memory_info
	definition to public
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--_002_DE8DF0795D48FD4CA783C40EC82923358A54SHSMSX101ccrcorpint_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

>From 0172b1ce6a2ba70e739f968622d78ac1796813f9 Mon Sep 17 00:00:00 2001
From: Liu Jinsong <jinsong.liu@intel.com>
Date: Sun, 11 Dec 2011 17:25:35 +0800
Subject: [PATCH 05/10] xen/acpi: Move acpi_memory_info definition to public

This patch rebased from Jeremy's pvops commit
359e747e6260f105f750657917e1dc75f6427602

Move this definition to header file so that it can be used by dom0
memory hotadd logic also.

Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
Signed-off-by: Jiang, Yunhong <yunhong.jiang@intel.com>
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
---
 drivers/acpi/acpi_memhotplug.c |   15 ---------------
 include/acpi/acpi_drivers.h    |   21 +++++++++++++++++++++
 2 files changed, 21 insertions(+), 15 deletions(-)

diff --git a/drivers/acpi/acpi_memhotplug.c b/drivers/acpi/acpi_memhotplug.=
c
index d985713..e28e64d 100644
--- a/drivers/acpi/acpi_memhotplug.c
+++ b/drivers/acpi/acpi_memhotplug.c
@@ -71,21 +71,6 @@ static struct acpi_driver acpi_memory_device_driver =3D =
{
 		},
 };
=20
-struct acpi_memory_info {
-	struct list_head list;
-	u64 start_addr;		/* Memory Range start physical addr */
-	u64 length;		/* Memory Range length */
-	unsigned short caching;	/* memory cache attribute */
-	unsigned short write_protect;	/* memory read/write attribute */
-	unsigned int enabled:1;
-};
-
-struct acpi_memory_device {
-	struct acpi_device * device;
-	unsigned int state;	/* State of the memory device */
-	struct list_head res_list;
-};
-
 static int acpi_hotmem_initialized;
=20
 static acpi_status
diff --git a/include/acpi/acpi_drivers.h b/include/acpi/acpi_drivers.h
index e49c36d..833de75 100644
--- a/include/acpi/acpi_drivers.h
+++ b/include/acpi/acpi_drivers.h
@@ -154,4 +154,25 @@ static inline void unregister_hotplug_dock_device(acpi=
_handle handle)
 }
 #endif
=20
+/*------------------------------------------------------------------------=
--
+                                Memory
+  ------------------------------------------------------------------------=
-- */
+#if defined(CONFIG_ACPI_HOTPLUG_MEMORY) || \
+        defined(CONFIG_ACPI_HOTPLUG_MEMORY_MODULE)
+struct acpi_memory_info {
+        struct list_head list;
+        u64 start_addr;         /* Memory Range start physical addr */
+        u64 length;             /* Memory Range length */
+        unsigned short caching; /* memory cache attribute */
+        unsigned short write_protect;   /* memory read/write attribute */
+        unsigned int enabled:1;
+};
+
+struct acpi_memory_device {
+        struct acpi_device *device;
+        unsigned int state;     /* State of the memory device */
+        struct list_head res_list;
+};
+#endif
+
 #endif /*__ACPI_DRIVERS_H__*/
--=20
1.6.5.6

--_002_DE8DF0795D48FD4CA783C40EC82923358A54SHSMSX101ccrcorpint_
Content-Type: application/octet-stream;
	name="0005-xen-acpi-Move-acpi_memory_info-definition-to-public.patch"
Content-Description: 0005-xen-acpi-Move-acpi_memory_info-definition-to-public.patch
Content-Disposition: attachment;
	filename="0005-xen-acpi-Move-acpi_memory_info-definition-to-public.patch";
	size=2702; creation-date="Wed, 14 Dec 2011 15:20:15 GMT";
	modification-date="Wed, 14 Dec 2011 15:03:34 GMT"
Content-Transfer-Encoding: base64

RnJvbSAwMTcyYjFjZTZhMmJhNzBlNzM5Zjk2ODYyMmQ3OGFjMTc5NjgxM2Y5IE1vbiBTZXAgMTcg
MDA6MDA6MDAgMjAwMQpGcm9tOiBMaXUgSmluc29uZyA8amluc29uZy5saXVAaW50ZWwuY29tPgpE
YXRlOiBTdW4sIDExIERlYyAyMDExIDE3OjI1OjM1ICswODAwClN1YmplY3Q6IFtQQVRDSCAwNS8x
MF0geGVuL2FjcGk6IE1vdmUgYWNwaV9tZW1vcnlfaW5mbyBkZWZpbml0aW9uIHRvIHB1YmxpYwoK
VGhpcyBwYXRjaCByZWJhc2VkIGZyb20gSmVyZW15J3MgcHZvcHMgY29tbWl0CjM1OWU3NDdlNjI2
MGYxMDVmNzUwNjU3OTE3ZTFkYzc1ZjY0Mjc2MDIKCk1vdmUgdGhpcyBkZWZpbml0aW9uIHRvIGhl
YWRlciBmaWxlIHNvIHRoYXQgaXQgY2FuIGJlIHVzZWQgYnkgZG9tMAptZW1vcnkgaG90YWRkIGxv
Z2ljIGFsc28uCgpTaWduZWQtb2ZmLWJ5OiBMaXUsIEppbnNvbmcgPGppbnNvbmcubGl1QGludGVs
LmNvbT4KU2lnbmVkLW9mZi1ieTogSmlhbmcsIFl1bmhvbmcgPHl1bmhvbmcuamlhbmdAaW50ZWwu
Y29tPgpTaWduZWQtb2ZmLWJ5OiBKZXJlbXkgRml0emhhcmRpbmdlIDxqZXJlbXkuZml0emhhcmRp
bmdlQGNpdHJpeC5jb20+Ci0tLQogZHJpdmVycy9hY3BpL2FjcGlfbWVtaG90cGx1Zy5jIHwgICAx
NSAtLS0tLS0tLS0tLS0tLS0KIGluY2x1ZGUvYWNwaS9hY3BpX2RyaXZlcnMuaCAgICB8ICAgMjEg
KysrKysrKysrKysrKysrKysrKysrCiAyIGZpbGVzIGNoYW5nZWQsIDIxIGluc2VydGlvbnMoKyks
IDE1IGRlbGV0aW9ucygtKQoKZGlmZiAtLWdpdCBhL2RyaXZlcnMvYWNwaS9hY3BpX21lbWhvdHBs
dWcuYyBiL2RyaXZlcnMvYWNwaS9hY3BpX21lbWhvdHBsdWcuYwppbmRleCBkOTg1NzEzLi5lMjhl
NjRkIDEwMDY0NAotLS0gYS9kcml2ZXJzL2FjcGkvYWNwaV9tZW1ob3RwbHVnLmMKKysrIGIvZHJp
dmVycy9hY3BpL2FjcGlfbWVtaG90cGx1Zy5jCkBAIC03MSwyMSArNzEsNiBAQCBzdGF0aWMgc3Ry
dWN0IGFjcGlfZHJpdmVyIGFjcGlfbWVtb3J5X2RldmljZV9kcml2ZXIgPSB7CiAJCX0sCiB9Owog
Ci1zdHJ1Y3QgYWNwaV9tZW1vcnlfaW5mbyB7Ci0Jc3RydWN0IGxpc3RfaGVhZCBsaXN0OwotCXU2
NCBzdGFydF9hZGRyOwkJLyogTWVtb3J5IFJhbmdlIHN0YXJ0IHBoeXNpY2FsIGFkZHIgKi8KLQl1
NjQgbGVuZ3RoOwkJLyogTWVtb3J5IFJhbmdlIGxlbmd0aCAqLwotCXVuc2lnbmVkIHNob3J0IGNh
Y2hpbmc7CS8qIG1lbW9yeSBjYWNoZSBhdHRyaWJ1dGUgKi8KLQl1bnNpZ25lZCBzaG9ydCB3cml0
ZV9wcm90ZWN0OwkvKiBtZW1vcnkgcmVhZC93cml0ZSBhdHRyaWJ1dGUgKi8KLQl1bnNpZ25lZCBp
bnQgZW5hYmxlZDoxOwotfTsKLQotc3RydWN0IGFjcGlfbWVtb3J5X2RldmljZSB7Ci0Jc3RydWN0
IGFjcGlfZGV2aWNlICogZGV2aWNlOwotCXVuc2lnbmVkIGludCBzdGF0ZTsJLyogU3RhdGUgb2Yg
dGhlIG1lbW9yeSBkZXZpY2UgKi8KLQlzdHJ1Y3QgbGlzdF9oZWFkIHJlc19saXN0OwotfTsKLQog
c3RhdGljIGludCBhY3BpX2hvdG1lbV9pbml0aWFsaXplZDsKIAogc3RhdGljIGFjcGlfc3RhdHVz
CmRpZmYgLS1naXQgYS9pbmNsdWRlL2FjcGkvYWNwaV9kcml2ZXJzLmggYi9pbmNsdWRlL2FjcGkv
YWNwaV9kcml2ZXJzLmgKaW5kZXggZTQ5YzM2ZC4uODMzZGU3NSAxMDA2NDQKLS0tIGEvaW5jbHVk
ZS9hY3BpL2FjcGlfZHJpdmVycy5oCisrKyBiL2luY2x1ZGUvYWNwaS9hY3BpX2RyaXZlcnMuaApA
QCAtMTU0LDQgKzE1NCwyNSBAQCBzdGF0aWMgaW5saW5lIHZvaWQgdW5yZWdpc3Rlcl9ob3RwbHVn
X2RvY2tfZGV2aWNlKGFjcGlfaGFuZGxlIGhhbmRsZSkKIH0KICNlbmRpZgogCisvKi0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIE1lbW9yeQorICAtLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLSAqLworI2lmIGRlZmluZWQoQ09ORklHX0FDUElfSE9UUExVR19NRU1PUlkp
IHx8IFwKKyAgICAgICAgZGVmaW5lZChDT05GSUdfQUNQSV9IT1RQTFVHX01FTU9SWV9NT0RVTEUp
CitzdHJ1Y3QgYWNwaV9tZW1vcnlfaW5mbyB7CisgICAgICAgIHN0cnVjdCBsaXN0X2hlYWQgbGlz
dDsKKyAgICAgICAgdTY0IHN0YXJ0X2FkZHI7ICAgICAgICAgLyogTWVtb3J5IFJhbmdlIHN0YXJ0
IHBoeXNpY2FsIGFkZHIgKi8KKyAgICAgICAgdTY0IGxlbmd0aDsgICAgICAgICAgICAgLyogTWVt
b3J5IFJhbmdlIGxlbmd0aCAqLworICAgICAgICB1bnNpZ25lZCBzaG9ydCBjYWNoaW5nOyAvKiBt
ZW1vcnkgY2FjaGUgYXR0cmlidXRlICovCisgICAgICAgIHVuc2lnbmVkIHNob3J0IHdyaXRlX3By
b3RlY3Q7ICAgLyogbWVtb3J5IHJlYWQvd3JpdGUgYXR0cmlidXRlICovCisgICAgICAgIHVuc2ln
bmVkIGludCBlbmFibGVkOjE7Cit9OworCitzdHJ1Y3QgYWNwaV9tZW1vcnlfZGV2aWNlIHsKKyAg
ICAgICAgc3RydWN0IGFjcGlfZGV2aWNlICpkZXZpY2U7CisgICAgICAgIHVuc2lnbmVkIGludCBz
dGF0ZTsgICAgIC8qIFN0YXRlIG9mIHRoZSBtZW1vcnkgZGV2aWNlICovCisgICAgICAgIHN0cnVj
dCBsaXN0X2hlYWQgcmVzX2xpc3Q7Cit9OworI2VuZGlmCisKICNlbmRpZiAvKl9fQUNQSV9EUklW
RVJTX0hfXyovCi0tIAoxLjYuNS42Cgo=

--_002_DE8DF0795D48FD4CA783C40EC82923358A54SHSMSX101ccrcorpint_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--_002_DE8DF0795D48FD4CA783C40EC82923358A54SHSMSX101ccrcorpint_--


From xen-devel-bounces@lists.xensource.com Thu Dec 22 10:06:30 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 Dec 2011 10:06:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdfXZ-0005AS-LF; Thu, 22 Dec 2011 10:06:21 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1RdfXX-00059S-W4
	for xen-devel@lists.xensource.com; Thu, 22 Dec 2011 10:06:20 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1324548372!6349764!1
X-Originating-IP: [143.182.124.37]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjE1ODY2\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11298 invoked from network); 22 Dec 2011 10:06:13 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37)
	by server-16.tower-174.messagelabs.com with SMTP;
	22 Dec 2011 10:06:13 -0000
Received: from azsmga002.ch.intel.com ([10.2.17.35])
	by azsmga102.ch.intel.com with ESMTP; 22 Dec 2011 02:06:12 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208,223";a="49700552"
Received: from pgsmsx603.gar.corp.intel.com ([10.221.43.87])
	by AZSMGA002.ch.intel.com with ESMTP; 22 Dec 2011 02:06:10 -0800
Received: from pgsmsx101.gar.corp.intel.com (10.221.44.78) by
	pgsmsx603.gar.corp.intel.com (10.221.43.87) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Thu, 22 Dec 2011 18:06:10 +0800
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	PGSMSX101.gar.corp.intel.com (10.221.44.78) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Thu, 22 Dec 2011 18:06:09 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.38]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.199]) with mapi id
	14.01.0355.002; Thu, 22 Dec 2011 18:06:08 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: "konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Thread-Topic: [PATCH 05/10] xen/acpi: Move acpi_memory_info definition to
	public
Thread-Index: AczAkVIpid07nRqpSD6SUyaJttGx8w==
Date: Thu, 22 Dec 2011 10:06:07 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC82923358A54@SHSMSX101.ccr.corp.intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
Content-Type: multipart/mixed;
	boundary="_002_DE8DF0795D48FD4CA783C40EC82923358A54SHSMSX101ccrcorpint_"
MIME-Version: 1.0
Cc: "Jiang, Yunhong" <yunhong.jiang@intel.com>,
	"jeremy.fitzhardinge@citrix.com" <jeremy.fitzhardinge@citrix.com>
Subject: [Xen-devel] [PATCH 05/10] xen/acpi: Move acpi_memory_info
	definition to public
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--_002_DE8DF0795D48FD4CA783C40EC82923358A54SHSMSX101ccrcorpint_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

>From 0172b1ce6a2ba70e739f968622d78ac1796813f9 Mon Sep 17 00:00:00 2001
From: Liu Jinsong <jinsong.liu@intel.com>
Date: Sun, 11 Dec 2011 17:25:35 +0800
Subject: [PATCH 05/10] xen/acpi: Move acpi_memory_info definition to public

This patch rebased from Jeremy's pvops commit
359e747e6260f105f750657917e1dc75f6427602

Move this definition to header file so that it can be used by dom0
memory hotadd logic also.

Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
Signed-off-by: Jiang, Yunhong <yunhong.jiang@intel.com>
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
---
 drivers/acpi/acpi_memhotplug.c |   15 ---------------
 include/acpi/acpi_drivers.h    |   21 +++++++++++++++++++++
 2 files changed, 21 insertions(+), 15 deletions(-)

diff --git a/drivers/acpi/acpi_memhotplug.c b/drivers/acpi/acpi_memhotplug.=
c
index d985713..e28e64d 100644
--- a/drivers/acpi/acpi_memhotplug.c
+++ b/drivers/acpi/acpi_memhotplug.c
@@ -71,21 +71,6 @@ static struct acpi_driver acpi_memory_device_driver =3D =
{
 		},
 };
=20
-struct acpi_memory_info {
-	struct list_head list;
-	u64 start_addr;		/* Memory Range start physical addr */
-	u64 length;		/* Memory Range length */
-	unsigned short caching;	/* memory cache attribute */
-	unsigned short write_protect;	/* memory read/write attribute */
-	unsigned int enabled:1;
-};
-
-struct acpi_memory_device {
-	struct acpi_device * device;
-	unsigned int state;	/* State of the memory device */
-	struct list_head res_list;
-};
-
 static int acpi_hotmem_initialized;
=20
 static acpi_status
diff --git a/include/acpi/acpi_drivers.h b/include/acpi/acpi_drivers.h
index e49c36d..833de75 100644
--- a/include/acpi/acpi_drivers.h
+++ b/include/acpi/acpi_drivers.h
@@ -154,4 +154,25 @@ static inline void unregister_hotplug_dock_device(acpi=
_handle handle)
 }
 #endif
=20
+/*------------------------------------------------------------------------=
--
+                                Memory
+  ------------------------------------------------------------------------=
-- */
+#if defined(CONFIG_ACPI_HOTPLUG_MEMORY) || \
+        defined(CONFIG_ACPI_HOTPLUG_MEMORY_MODULE)
+struct acpi_memory_info {
+        struct list_head list;
+        u64 start_addr;         /* Memory Range start physical addr */
+        u64 length;             /* Memory Range length */
+        unsigned short caching; /* memory cache attribute */
+        unsigned short write_protect;   /* memory read/write attribute */
+        unsigned int enabled:1;
+};
+
+struct acpi_memory_device {
+        struct acpi_device *device;
+        unsigned int state;     /* State of the memory device */
+        struct list_head res_list;
+};
+#endif
+
 #endif /*__ACPI_DRIVERS_H__*/
--=20
1.6.5.6

--_002_DE8DF0795D48FD4CA783C40EC82923358A54SHSMSX101ccrcorpint_
Content-Type: application/octet-stream;
	name="0005-xen-acpi-Move-acpi_memory_info-definition-to-public.patch"
Content-Description: 0005-xen-acpi-Move-acpi_memory_info-definition-to-public.patch
Content-Disposition: attachment;
	filename="0005-xen-acpi-Move-acpi_memory_info-definition-to-public.patch";
	size=2702; creation-date="Wed, 14 Dec 2011 15:20:15 GMT";
	modification-date="Wed, 14 Dec 2011 15:03:34 GMT"
Content-Transfer-Encoding: base64

RnJvbSAwMTcyYjFjZTZhMmJhNzBlNzM5Zjk2ODYyMmQ3OGFjMTc5NjgxM2Y5IE1vbiBTZXAgMTcg
MDA6MDA6MDAgMjAwMQpGcm9tOiBMaXUgSmluc29uZyA8amluc29uZy5saXVAaW50ZWwuY29tPgpE
YXRlOiBTdW4sIDExIERlYyAyMDExIDE3OjI1OjM1ICswODAwClN1YmplY3Q6IFtQQVRDSCAwNS8x
MF0geGVuL2FjcGk6IE1vdmUgYWNwaV9tZW1vcnlfaW5mbyBkZWZpbml0aW9uIHRvIHB1YmxpYwoK
VGhpcyBwYXRjaCByZWJhc2VkIGZyb20gSmVyZW15J3MgcHZvcHMgY29tbWl0CjM1OWU3NDdlNjI2
MGYxMDVmNzUwNjU3OTE3ZTFkYzc1ZjY0Mjc2MDIKCk1vdmUgdGhpcyBkZWZpbml0aW9uIHRvIGhl
YWRlciBmaWxlIHNvIHRoYXQgaXQgY2FuIGJlIHVzZWQgYnkgZG9tMAptZW1vcnkgaG90YWRkIGxv
Z2ljIGFsc28uCgpTaWduZWQtb2ZmLWJ5OiBMaXUsIEppbnNvbmcgPGppbnNvbmcubGl1QGludGVs
LmNvbT4KU2lnbmVkLW9mZi1ieTogSmlhbmcsIFl1bmhvbmcgPHl1bmhvbmcuamlhbmdAaW50ZWwu
Y29tPgpTaWduZWQtb2ZmLWJ5OiBKZXJlbXkgRml0emhhcmRpbmdlIDxqZXJlbXkuZml0emhhcmRp
bmdlQGNpdHJpeC5jb20+Ci0tLQogZHJpdmVycy9hY3BpL2FjcGlfbWVtaG90cGx1Zy5jIHwgICAx
NSAtLS0tLS0tLS0tLS0tLS0KIGluY2x1ZGUvYWNwaS9hY3BpX2RyaXZlcnMuaCAgICB8ICAgMjEg
KysrKysrKysrKysrKysrKysrKysrCiAyIGZpbGVzIGNoYW5nZWQsIDIxIGluc2VydGlvbnMoKyks
IDE1IGRlbGV0aW9ucygtKQoKZGlmZiAtLWdpdCBhL2RyaXZlcnMvYWNwaS9hY3BpX21lbWhvdHBs
dWcuYyBiL2RyaXZlcnMvYWNwaS9hY3BpX21lbWhvdHBsdWcuYwppbmRleCBkOTg1NzEzLi5lMjhl
NjRkIDEwMDY0NAotLS0gYS9kcml2ZXJzL2FjcGkvYWNwaV9tZW1ob3RwbHVnLmMKKysrIGIvZHJp
dmVycy9hY3BpL2FjcGlfbWVtaG90cGx1Zy5jCkBAIC03MSwyMSArNzEsNiBAQCBzdGF0aWMgc3Ry
dWN0IGFjcGlfZHJpdmVyIGFjcGlfbWVtb3J5X2RldmljZV9kcml2ZXIgPSB7CiAJCX0sCiB9Owog
Ci1zdHJ1Y3QgYWNwaV9tZW1vcnlfaW5mbyB7Ci0Jc3RydWN0IGxpc3RfaGVhZCBsaXN0OwotCXU2
NCBzdGFydF9hZGRyOwkJLyogTWVtb3J5IFJhbmdlIHN0YXJ0IHBoeXNpY2FsIGFkZHIgKi8KLQl1
NjQgbGVuZ3RoOwkJLyogTWVtb3J5IFJhbmdlIGxlbmd0aCAqLwotCXVuc2lnbmVkIHNob3J0IGNh
Y2hpbmc7CS8qIG1lbW9yeSBjYWNoZSBhdHRyaWJ1dGUgKi8KLQl1bnNpZ25lZCBzaG9ydCB3cml0
ZV9wcm90ZWN0OwkvKiBtZW1vcnkgcmVhZC93cml0ZSBhdHRyaWJ1dGUgKi8KLQl1bnNpZ25lZCBp
bnQgZW5hYmxlZDoxOwotfTsKLQotc3RydWN0IGFjcGlfbWVtb3J5X2RldmljZSB7Ci0Jc3RydWN0
IGFjcGlfZGV2aWNlICogZGV2aWNlOwotCXVuc2lnbmVkIGludCBzdGF0ZTsJLyogU3RhdGUgb2Yg
dGhlIG1lbW9yeSBkZXZpY2UgKi8KLQlzdHJ1Y3QgbGlzdF9oZWFkIHJlc19saXN0OwotfTsKLQog
c3RhdGljIGludCBhY3BpX2hvdG1lbV9pbml0aWFsaXplZDsKIAogc3RhdGljIGFjcGlfc3RhdHVz
CmRpZmYgLS1naXQgYS9pbmNsdWRlL2FjcGkvYWNwaV9kcml2ZXJzLmggYi9pbmNsdWRlL2FjcGkv
YWNwaV9kcml2ZXJzLmgKaW5kZXggZTQ5YzM2ZC4uODMzZGU3NSAxMDA2NDQKLS0tIGEvaW5jbHVk
ZS9hY3BpL2FjcGlfZHJpdmVycy5oCisrKyBiL2luY2x1ZGUvYWNwaS9hY3BpX2RyaXZlcnMuaApA
QCAtMTU0LDQgKzE1NCwyNSBAQCBzdGF0aWMgaW5saW5lIHZvaWQgdW5yZWdpc3Rlcl9ob3RwbHVn
X2RvY2tfZGV2aWNlKGFjcGlfaGFuZGxlIGhhbmRsZSkKIH0KICNlbmRpZgogCisvKi0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIE1lbW9yeQorICAtLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLSAqLworI2lmIGRlZmluZWQoQ09ORklHX0FDUElfSE9UUExVR19NRU1PUlkp
IHx8IFwKKyAgICAgICAgZGVmaW5lZChDT05GSUdfQUNQSV9IT1RQTFVHX01FTU9SWV9NT0RVTEUp
CitzdHJ1Y3QgYWNwaV9tZW1vcnlfaW5mbyB7CisgICAgICAgIHN0cnVjdCBsaXN0X2hlYWQgbGlz
dDsKKyAgICAgICAgdTY0IHN0YXJ0X2FkZHI7ICAgICAgICAgLyogTWVtb3J5IFJhbmdlIHN0YXJ0
IHBoeXNpY2FsIGFkZHIgKi8KKyAgICAgICAgdTY0IGxlbmd0aDsgICAgICAgICAgICAgLyogTWVt
b3J5IFJhbmdlIGxlbmd0aCAqLworICAgICAgICB1bnNpZ25lZCBzaG9ydCBjYWNoaW5nOyAvKiBt
ZW1vcnkgY2FjaGUgYXR0cmlidXRlICovCisgICAgICAgIHVuc2lnbmVkIHNob3J0IHdyaXRlX3By
b3RlY3Q7ICAgLyogbWVtb3J5IHJlYWQvd3JpdGUgYXR0cmlidXRlICovCisgICAgICAgIHVuc2ln
bmVkIGludCBlbmFibGVkOjE7Cit9OworCitzdHJ1Y3QgYWNwaV9tZW1vcnlfZGV2aWNlIHsKKyAg
ICAgICAgc3RydWN0IGFjcGlfZGV2aWNlICpkZXZpY2U7CisgICAgICAgIHVuc2lnbmVkIGludCBz
dGF0ZTsgICAgIC8qIFN0YXRlIG9mIHRoZSBtZW1vcnkgZGV2aWNlICovCisgICAgICAgIHN0cnVj
dCBsaXN0X2hlYWQgcmVzX2xpc3Q7Cit9OworI2VuZGlmCisKICNlbmRpZiAvKl9fQUNQSV9EUklW
RVJTX0hfXyovCi0tIAoxLjYuNS42Cgo=

--_002_DE8DF0795D48FD4CA783C40EC82923358A54SHSMSX101ccrcorpint_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--_002_DE8DF0795D48FD4CA783C40EC82923358A54SHSMSX101ccrcorpint_--


From xen-devel-bounces@lists.xensource.com Thu Dec 22 10:08:01 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 Dec 2011 10:08:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdfYy-0005OE-S0; Thu, 22 Dec 2011 10:07:48 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1RdfYw-0005NG-T2
	for xen-devel@lists.xensource.com; Thu, 22 Dec 2011 10:07:47 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1324548459!6502160!1
X-Originating-IP: [134.134.136.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjQgPT4gMzE5NDEx\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1781 invoked from network); 22 Dec 2011 10:07:39 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-2.tower-174.messagelabs.com with SMTP;
	22 Dec 2011 10:07:39 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga102.jf.intel.com with ESMTP; 22 Dec 2011 02:07:38 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.67,352,1309762800"; d="scan'208,223";a="89282609"
Received: from pgsmsx601.gar.corp.intel.com ([10.221.43.69])
	by orsmga001.jf.intel.com with ESMTP; 22 Dec 2011 02:07:37 -0800
Received: from pgsmsx104.gar.corp.intel.com (10.221.44.91) by
	pgsmsx601.gar.corp.intel.com (10.221.43.69) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Thu, 22 Dec 2011 18:06:59 +0800
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	PGSMSX104.gar.corp.intel.com (10.221.44.91) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Thu, 22 Dec 2011 18:06:58 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.38]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.199]) with mapi id
	14.01.0355.002; Thu, 22 Dec 2011 18:06:57 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: "konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Thread-Topic: [PATCH 06/10] Xen: Add memory hotadd to pvops dom0
Thread-Index: AczAkW9qsmV2yLulS6yL5Y6v3LXZtw==
Date: Thu, 22 Dec 2011 10:06:56 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC82923358A61@SHSMSX101.ccr.corp.intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
Content-Type: multipart/mixed;
	boundary="_002_DE8DF0795D48FD4CA783C40EC82923358A61SHSMSX101ccrcorpint_"
MIME-Version: 1.0
Cc: "Jiang, Yunhong" <yunhong.jiang@intel.com>,
	"jeremy.fitzhardinge@citrix.com" <jeremy.fitzhardinge@citrix.com>
Subject: [Xen-devel] [PATCH 06/10] Xen: Add memory hotadd to pvops dom0
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--_002_DE8DF0795D48FD4CA783C40EC82923358A61SHSMSX101ccrcorpint_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

>From a5d21e2a01049eef6aa64406e71f6574e7a371c1 Mon Sep 17 00:00:00 2001
From: Liu Jinsong <jinsong.liu@intel.com>
Date: Sun, 11 Dec 2011 21:51:28 +0800
Subject: [PATCH 06/10] Xen: Add memory hotadd to pvops dom0

This patch rebased from Jeremy's pvops commit
fe3cb1ebf78399fd5176ff6aa1c9ab498f2d8bd7

When memory hotadd event happen, a Xen hook will be called, to notify
hypervisor of the new added memory.

Because xen hypervisor will use the new memory to setup frametable/m2p
table, so dom0 will always return success to acpi bios, and notify xen
hypervisor later.

It add a hook in driver/acpi/acpi_memhotplug.c, but that change is
quite small, not sure if it is acceptable. Other method is to provide
a xen specific acpi_memory_device_driver, but I'm not sure if it worth
to add so much changes, to simply avoid two hooks.

Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
Signed-off-by: Jiang, Yunhong <yunhong.jiang@intel.com>
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
---
 drivers/acpi/acpi_memhotplug.c    |    4 +
 drivers/xen/Makefile              |    1 +
 drivers/xen/xen_acpi_memhotplug.c |  209 +++++++++++++++++++++++++++++++++=
++++
 include/xen/acpi.h                |    5 +
 include/xen/interface/platform.h  |    9 ++
 5 files changed, 228 insertions(+), 0 deletions(-)
 create mode 100644 drivers/xen/xen_acpi_memhotplug.c

diff --git a/drivers/acpi/acpi_memhotplug.c b/drivers/acpi/acpi_memhotplug.=
c
index e28e64d..2f2169e 100644
--- a/drivers/acpi/acpi_memhotplug.c
+++ b/drivers/acpi/acpi_memhotplug.c
@@ -32,6 +32,7 @@
 #include <linux/memory_hotplug.h>
 #include <linux/slab.h>
 #include <acpi/acpi_drivers.h>
+#include <xen/acpi.h>
=20
 #define ACPI_MEMORY_DEVICE_CLASS		"memory"
 #define ACPI_MEMORY_DEVICE_HID			"PNP0C80"
@@ -214,6 +215,9 @@ static int acpi_memory_enable_device(struct acpi_memory=
_device *mem_device)
 		return result;
 	}
=20
+	if (xen_initial_domain())
+		return xen_hotadd_memory(mem_device);
+
 	node =3D acpi_get_node(mem_device->device->handle);
 	/*
 	 * Tell the VM there is more memory here...
diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
index aedaf48..7dc3c0b 100644
--- a/drivers/xen/Makefile
+++ b/drivers/xen/Makefile
@@ -20,6 +20,7 @@ obj-$(CONFIG_XEN_TMEM)			+=3D tmem.o
 obj-$(CONFIG_SWIOTLB_XEN)		+=3D swiotlb-xen.o
 obj-$(CONFIG_XEN_DOM0)			+=3D pci.o acpi.o
 obj-$(CONFIG_XEN_PCIDEV_BACKEND)	+=3D xen-pciback/
+obj-$(CONFIG_ACPI_HOTPLUG_MEMORY)	+=3D xen_acpi_memhotplug.o
 ifdef CONFIG_ACPI_PROCESSOR_XEN
 obj-$(CONFIG_ACPI_PROCESSOR)		+=3D acpi_processor.o
 endif
diff --git a/drivers/xen/xen_acpi_memhotplug.c b/drivers/xen/xen_acpi_memho=
tplug.c
new file mode 100644
index 0000000..0c4af99
--- /dev/null
+++ b/drivers/xen/xen_acpi_memhotplug.c
@@ -0,0 +1,209 @@
+/*
+ *  xen_acpi_memhotplug.c - interface to notify Xen on memory device hotad=
d
+ *
+ *  Copyright (C) 2008, Intel corporation
+ *
+ * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~=
~~~
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License as published by
+ *  the Free Software Foundation; either version 2 of the License, or (at
+ *  your option) any later version.
+ *
+ *  This program is distributed in the hope that it will be useful, but
+ *  WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ *  General Public License for more details.
+ *
+ *  You should have received a copy of the GNU General Public License alon=
g
+ *  with this program; if not, write to the Free Software Foundation, Inc.=
,
+ *  59 Temple Place, Suite 330, Boston, MA 02111-1307 USA.
+ *
+ */
+
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/init.h>
+#include <linux/types.h>
+#include <linux/memory_hotplug.h>
+#include <acpi/acpi_drivers.h>
+#include <xen/interface/platform.h>
+#include <linux/interrupt.h>
+#include <linux/spinlock.h>
+#include <asm/xen/hypervisor.h>
+#include <asm/xen/hypercall.h>
+#include <xen/acpi.h>
+
+struct xen_hotmem_entry {
+	struct list_head hotmem_list;
+	uint64_t start;
+	uint64_t end;
+	uint32_t flags;
+	uint32_t pxm;
+};
+
+struct xen_hotmem_list {
+	struct list_head list;
+	int entry_nr;
+} xen_hotmem;
+
+DEFINE_SPINLOCK(xen_hotmem_lock);
+
+static int xen_hyper_addmem(struct xen_hotmem_entry *entry)
+{
+	int ret;
+
+	xen_platform_op_t op =3D {
+		.cmd            =3D XENPF_mem_hotadd,
+		.interface_version  =3D XENPF_INTERFACE_VERSION,
+	};
+	op.u.mem_add.spfn =3D entry->start >> PAGE_SHIFT;
+	op.u.mem_add.epfn =3D entry->end >> PAGE_SHIFT;
+	op.u.mem_add.flags =3D entry->flags;
+	op.u.mem_add.pxm =3D entry->pxm;
+
+	ret =3D HYPERVISOR_dom0_op(&op);
+	return ret;
+}
+
+static int add_hotmem_entry(int pxm, uint64_t start,
+			uint64_t length, uint32_t flags)
+{
+	struct xen_hotmem_entry *entry;
+
+	if (pxm < 0 || !length)
+		return -EINVAL;
+
+	entry =3D kzalloc(sizeof(struct xen_hotmem_entry), GFP_ATOMIC);
+	if (!entry)
+		return -ENOMEM;
+
+	INIT_LIST_HEAD(&entry->hotmem_list);
+	entry->start =3D start;
+	entry->end =3D start + length;
+	entry->flags =3D flags;
+	entry->pxm =3D pxm;
+
+	spin_lock(&xen_hotmem_lock);
+
+	list_add_tail(&entry->hotmem_list, &xen_hotmem.list);
+	xen_hotmem.entry_nr++;
+
+	spin_unlock(&xen_hotmem_lock);
+
+	return 0;
+}
+
+static int free_hotmem_entry(struct xen_hotmem_entry *entry)
+{
+	list_del(&entry->hotmem_list);
+	kfree(entry);
+
+	return 0;
+}
+
+static void xen_hotadd_mem_dpc(struct work_struct *work)
+{
+	struct list_head *elem, *tmp;
+	struct xen_hotmem_entry *entry;
+	unsigned long flags;
+	int ret;
+
+	spin_lock_irqsave(&xen_hotmem_lock, flags);
+	list_for_each_safe(elem, tmp, &xen_hotmem.list) {
+		entry =3D list_entry(elem, struct xen_hotmem_entry, hotmem_list);
+		ret =3D xen_hyper_addmem(entry);
+		if (ret)
+			printk(KERN_WARNING "xen addmem failed with %x\n", ret);
+		free_hotmem_entry(entry);
+		xen_hotmem.entry_nr--;
+	}
+	spin_unlock_irqrestore(&xen_hotmem_lock, flags);
+}
+
+static DECLARE_WORK(xen_hotadd_mem_work, xen_hotadd_mem_dpc);
+
+static int xen_acpi_get_pxm(acpi_handle h)
+{
+	unsigned long long pxm;
+	acpi_status status;
+	acpi_handle handle;
+	acpi_handle phandle =3D h;
+
+	do {
+		handle =3D phandle;
+		status =3D acpi_evaluate_integer(handle, "_PXM", NULL, &pxm);
+		if (ACPI_SUCCESS(status))
+			return pxm;
+		status =3D acpi_get_parent(handle, &phandle);
+	} while (ACPI_SUCCESS(status));
+
+	return -1;
+}
+
+int xen_hotadd_memory(struct acpi_memory_device *mem_device)
+{
+	int pxm, result;
+	int num_enabled =3D 0;
+	struct acpi_memory_info *info;
+
+	if (!mem_device)
+		return -EINVAL;
+
+	pxm =3D xen_acpi_get_pxm(mem_device->device->handle);
+
+	if (pxm < 0)
+		return -EINVAL;
+
+	/*
+	 * Always return success to ACPI driver, and notify hypervisor later
+	 * because hypervisor will utilize the memory in memory hotadd hypercall
+	 */
+	list_for_each_entry(info, &mem_device->res_list, list) {
+		if (info->enabled) { /* just sanity check...*/
+			num_enabled++;
+			continue;
+		}
+		/*
+		 * If the memory block size is zero, please ignore it.
+		 * Don't try to do the following memory hotplug flowchart.
+		 */
+		if (!info->length)
+			continue;
+
+		result =3D add_hotmem_entry(pxm, info->start_addr,
+					info->length, 0);
+		if (result)
+			continue;
+		info->enabled =3D 1;
+		num_enabled++;
+	}
+
+	if (!num_enabled)
+		return -EINVAL;
+
+	schedule_work(&xen_hotadd_mem_work);
+
+	return 0;
+}
+EXPORT_SYMBOL(xen_hotadd_memory);
+
+static int xen_hotadd_mem_init(void)
+{
+	if (!xen_initial_domain())
+		return -ENODEV;
+
+	INIT_LIST_HEAD(&xen_hotmem.list);
+	xen_hotmem.entry_nr =3D 0;
+
+	return 0;
+}
+
+static void xen_hotadd_mem_exit(void)
+{
+	flush_scheduled_work();
+}
+
+module_init(xen_hotadd_mem_init);
+module_exit(xen_hotadd_mem_exit);
+MODULE_LICENSE("GPL");
diff --git a/include/xen/acpi.h b/include/xen/acpi.h
index 7aa282d..8b3462e 100644
--- a/include/xen/acpi.h
+++ b/include/xen/acpi.h
@@ -107,6 +107,11 @@ static inline int xen_acpi_processor_get_performance(s=
truct acpi_processor *pr)
 }
 #endif
=20
+#if defined(CONFIG_ACPI_HOTPLUG_MEMORY) || \
+defined(CONFIG_ACPI_HOTPLUG_MEMORY_MODULE)
+int xen_hotadd_memory(struct acpi_memory_device *mem_device);
+#endif
+
 #if defined(CONFIG_ACPI_PROCESSOR_XEN) || \
 defined(CONFIG_ACPI_PROCESSOR_XEN_MODULE)
=20
diff --git a/include/xen/interface/platform.h b/include/xen/interface/platf=
orm.h
index 9fd6b07..0787c68 100644
--- a/include/xen/interface/platform.h
+++ b/include/xen/interface/platform.h
@@ -329,6 +329,14 @@ struct xenpf_cpu_hotadd {
 	uint32_t pxm;
 };
=20
+#define XENPF_mem_hotadd    59
+struct xenpf_mem_hotadd {
+	uint64_t spfn;
+	uint64_t epfn;
+	uint32_t pxm;
+	uint32_t flags;
+};
+
 struct xen_platform_op {
 	uint32_t cmd;
 	uint32_t interface_version; /* XENPF_INTERFACE_VERSION */
@@ -347,6 +355,7 @@ struct xen_platform_op {
 		struct xenpf_pcpuinfo          pcpu_info;
 		struct xenpf_cpu_ol            cpu_ol;
 		struct xenpf_cpu_hotadd        cpu_add;
+		struct xenpf_mem_hotadd        mem_add;
 		uint8_t                        pad[128];
 	} u;
 };
--=20
1.6.5.6

--_002_DE8DF0795D48FD4CA783C40EC82923358A61SHSMSX101ccrcorpint_
Content-Type: application/octet-stream;
	name="0006-Xen-Add-memory-hotadd-to-pvops-dom0.patch"
Content-Description: 0006-Xen-Add-memory-hotadd-to-pvops-dom0.patch
Content-Disposition: attachment;
	filename="0006-Xen-Add-memory-hotadd-to-pvops-dom0.patch"; size=9113;
	creation-date="Wed, 14 Dec 2011 15:20:15 GMT";
	modification-date="Wed, 14 Dec 2011 15:03:34 GMT"
Content-Transfer-Encoding: base64

RnJvbSBhNWQyMWUyYTAxMDQ5ZWVmNmFhNjQ0MDZlNzFmNjU3NGU3YTM3MWMxIE1vbiBTZXAgMTcg
MDA6MDA6MDAgMjAwMQpGcm9tOiBMaXUgSmluc29uZyA8amluc29uZy5saXVAaW50ZWwuY29tPgpE
YXRlOiBTdW4sIDExIERlYyAyMDExIDIxOjUxOjI4ICswODAwClN1YmplY3Q6IFtQQVRDSCAwNi8x
MF0gWGVuOiBBZGQgbWVtb3J5IGhvdGFkZCB0byBwdm9wcyBkb20wCgpUaGlzIHBhdGNoIHJlYmFz
ZWQgZnJvbSBKZXJlbXkncyBwdm9wcyBjb21taXQKZmUzY2IxZWJmNzgzOTlmZDUxNzZmZjZhYTFj
OWFiNDk4ZjJkOGJkNwoKV2hlbiBtZW1vcnkgaG90YWRkIGV2ZW50IGhhcHBlbiwgYSBYZW4gaG9v
ayB3aWxsIGJlIGNhbGxlZCwgdG8gbm90aWZ5Cmh5cGVydmlzb3Igb2YgdGhlIG5ldyBhZGRlZCBt
ZW1vcnkuCgpCZWNhdXNlIHhlbiBoeXBlcnZpc29yIHdpbGwgdXNlIHRoZSBuZXcgbWVtb3J5IHRv
IHNldHVwIGZyYW1ldGFibGUvbTJwCnRhYmxlLCBzbyBkb20wIHdpbGwgYWx3YXlzIHJldHVybiBz
dWNjZXNzIHRvIGFjcGkgYmlvcywgYW5kIG5vdGlmeSB4ZW4KaHlwZXJ2aXNvciBsYXRlci4KCkl0
IGFkZCBhIGhvb2sgaW4gZHJpdmVyL2FjcGkvYWNwaV9tZW1ob3RwbHVnLmMsIGJ1dCB0aGF0IGNo
YW5nZSBpcwpxdWl0ZSBzbWFsbCwgbm90IHN1cmUgaWYgaXQgaXMgYWNjZXB0YWJsZS4gT3RoZXIg
bWV0aG9kIGlzIHRvIHByb3ZpZGUKYSB4ZW4gc3BlY2lmaWMgYWNwaV9tZW1vcnlfZGV2aWNlX2Ry
aXZlciwgYnV0IEknbSBub3Qgc3VyZSBpZiBpdCB3b3J0aAp0byBhZGQgc28gbXVjaCBjaGFuZ2Vz
LCB0byBzaW1wbHkgYXZvaWQgdHdvIGhvb2tzLgoKU2lnbmVkLW9mZi1ieTogTGl1LCBKaW5zb25n
IDxqaW5zb25nLmxpdUBpbnRlbC5jb20+ClNpZ25lZC1vZmYtYnk6IEppYW5nLCBZdW5ob25nIDx5
dW5ob25nLmppYW5nQGludGVsLmNvbT4KU2lnbmVkLW9mZi1ieTogSmVyZW15IEZpdHpoYXJkaW5n
ZSA8amVyZW15LmZpdHpoYXJkaW5nZUBjaXRyaXguY29tPgotLS0KIGRyaXZlcnMvYWNwaS9hY3Bp
X21lbWhvdHBsdWcuYyAgICB8ICAgIDQgKwogZHJpdmVycy94ZW4vTWFrZWZpbGUgICAgICAgICAg
ICAgIHwgICAgMSArCiBkcml2ZXJzL3hlbi94ZW5fYWNwaV9tZW1ob3RwbHVnLmMgfCAgMjA5ICsr
KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysKIGluY2x1ZGUveGVuL2FjcGkuaCAg
ICAgICAgICAgICAgICB8ICAgIDUgKwogaW5jbHVkZS94ZW4vaW50ZXJmYWNlL3BsYXRmb3JtLmgg
IHwgICAgOSArKwogNSBmaWxlcyBjaGFuZ2VkLCAyMjggaW5zZXJ0aW9ucygrKSwgMCBkZWxldGlv
bnMoLSkKIGNyZWF0ZSBtb2RlIDEwMDY0NCBkcml2ZXJzL3hlbi94ZW5fYWNwaV9tZW1ob3RwbHVn
LmMKCmRpZmYgLS1naXQgYS9kcml2ZXJzL2FjcGkvYWNwaV9tZW1ob3RwbHVnLmMgYi9kcml2ZXJz
L2FjcGkvYWNwaV9tZW1ob3RwbHVnLmMKaW5kZXggZTI4ZTY0ZC4uMmYyMTY5ZSAxMDA2NDQKLS0t
IGEvZHJpdmVycy9hY3BpL2FjcGlfbWVtaG90cGx1Zy5jCisrKyBiL2RyaXZlcnMvYWNwaS9hY3Bp
X21lbWhvdHBsdWcuYwpAQCAtMzIsNiArMzIsNyBAQAogI2luY2x1ZGUgPGxpbnV4L21lbW9yeV9o
b3RwbHVnLmg+CiAjaW5jbHVkZSA8bGludXgvc2xhYi5oPgogI2luY2x1ZGUgPGFjcGkvYWNwaV9k
cml2ZXJzLmg+CisjaW5jbHVkZSA8eGVuL2FjcGkuaD4KIAogI2RlZmluZSBBQ1BJX01FTU9SWV9E
RVZJQ0VfQ0xBU1MJCSJtZW1vcnkiCiAjZGVmaW5lIEFDUElfTUVNT1JZX0RFVklDRV9ISUQJCQki
UE5QMEM4MCIKQEAgLTIxNCw2ICsyMTUsOSBAQCBzdGF0aWMgaW50IGFjcGlfbWVtb3J5X2VuYWJs
ZV9kZXZpY2Uoc3RydWN0IGFjcGlfbWVtb3J5X2RldmljZSAqbWVtX2RldmljZSkKIAkJcmV0dXJu
IHJlc3VsdDsKIAl9CiAKKwlpZiAoeGVuX2luaXRpYWxfZG9tYWluKCkpCisJCXJldHVybiB4ZW5f
aG90YWRkX21lbW9yeShtZW1fZGV2aWNlKTsKKwogCW5vZGUgPSBhY3BpX2dldF9ub2RlKG1lbV9k
ZXZpY2UtPmRldmljZS0+aGFuZGxlKTsKIAkvKgogCSAqIFRlbGwgdGhlIFZNIHRoZXJlIGlzIG1v
cmUgbWVtb3J5IGhlcmUuLi4KZGlmZiAtLWdpdCBhL2RyaXZlcnMveGVuL01ha2VmaWxlIGIvZHJp
dmVycy94ZW4vTWFrZWZpbGUKaW5kZXggYWVkYWY0OC4uN2RjM2MwYiAxMDA2NDQKLS0tIGEvZHJp
dmVycy94ZW4vTWFrZWZpbGUKKysrIGIvZHJpdmVycy94ZW4vTWFrZWZpbGUKQEAgLTIwLDYgKzIw
LDcgQEAgb2JqLSQoQ09ORklHX1hFTl9UTUVNKQkJCSs9IHRtZW0ubwogb2JqLSQoQ09ORklHX1NX
SU9UTEJfWEVOKQkJKz0gc3dpb3RsYi14ZW4ubwogb2JqLSQoQ09ORklHX1hFTl9ET00wKQkJCSs9
IHBjaS5vIGFjcGkubwogb2JqLSQoQ09ORklHX1hFTl9QQ0lERVZfQkFDS0VORCkJKz0geGVuLXBj
aWJhY2svCitvYmotJChDT05GSUdfQUNQSV9IT1RQTFVHX01FTU9SWSkJKz0geGVuX2FjcGlfbWVt
aG90cGx1Zy5vCiBpZmRlZiBDT05GSUdfQUNQSV9QUk9DRVNTT1JfWEVOCiBvYmotJChDT05GSUdf
QUNQSV9QUk9DRVNTT1IpCQkrPSBhY3BpX3Byb2Nlc3Nvci5vCiBlbmRpZgpkaWZmIC0tZ2l0IGEv
ZHJpdmVycy94ZW4veGVuX2FjcGlfbWVtaG90cGx1Zy5jIGIvZHJpdmVycy94ZW4veGVuX2FjcGlf
bWVtaG90cGx1Zy5jCm5ldyBmaWxlIG1vZGUgMTAwNjQ0CmluZGV4IDAwMDAwMDAuLjBjNGFmOTkK
LS0tIC9kZXYvbnVsbAorKysgYi9kcml2ZXJzL3hlbi94ZW5fYWNwaV9tZW1ob3RwbHVnLmMKQEAg
LTAsMCArMSwyMDkgQEAKKy8qCisgKiAgeGVuX2FjcGlfbWVtaG90cGx1Zy5jIC0gaW50ZXJmYWNl
IHRvIG5vdGlmeSBYZW4gb24gbWVtb3J5IGRldmljZSBob3RhZGQKKyAqCisgKiAgQ29weXJpZ2h0
IChDKSAyMDA4LCBJbnRlbCBjb3Jwb3JhdGlvbgorICoKKyAqIH5+fn5+fn5+fn5+fn5+fn5+fn5+
fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+Cisg
KgorICogIFRoaXMgcHJvZ3JhbSBpcyBmcmVlIHNvZnR3YXJlOyB5b3UgY2FuIHJlZGlzdHJpYnV0
ZSBpdCBhbmQvb3IgbW9kaWZ5CisgKiAgaXQgdW5kZXIgdGhlIHRlcm1zIG9mIHRoZSBHTlUgR2Vu
ZXJhbCBQdWJsaWMgTGljZW5zZSBhcyBwdWJsaXNoZWQgYnkKKyAqICB0aGUgRnJlZSBTb2Z0d2Fy
ZSBGb3VuZGF0aW9uOyBlaXRoZXIgdmVyc2lvbiAyIG9mIHRoZSBMaWNlbnNlLCBvciAoYXQKKyAq
ICB5b3VyIG9wdGlvbikgYW55IGxhdGVyIHZlcnNpb24uCisgKgorICogIFRoaXMgcHJvZ3JhbSBp
cyBkaXN0cmlidXRlZCBpbiB0aGUgaG9wZSB0aGF0IGl0IHdpbGwgYmUgdXNlZnVsLCBidXQKKyAq
ICBXSVRIT1VUIEFOWSBXQVJSQU5UWTsgd2l0aG91dCBldmVuIHRoZSBpbXBsaWVkIHdhcnJhbnR5
IG9mCisgKiAgTUVSQ0hBTlRBQklMSVRZIG9yIEZJVE5FU1MgRk9SIEEgUEFSVElDVUxBUiBQVVJQ
T1NFLiAgU2VlIHRoZSBHTlUKKyAqICBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlIGZvciBtb3JlIGRl
dGFpbHMuCisgKgorICogIFlvdSBzaG91bGQgaGF2ZSByZWNlaXZlZCBhIGNvcHkgb2YgdGhlIEdO
VSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlIGFsb25nCisgKiAgd2l0aCB0aGlzIHByb2dyYW07IGlm
IG5vdCwgd3JpdGUgdG8gdGhlIEZyZWUgU29mdHdhcmUgRm91bmRhdGlvbiwgSW5jLiwKKyAqICA1
OSBUZW1wbGUgUGxhY2UsIFN1aXRlIDMzMCwgQm9zdG9uLCBNQSAwMjExMS0xMzA3IFVTQS4KKyAq
CisgKi8KKworI2luY2x1ZGUgPGxpbnV4L2tlcm5lbC5oPgorI2luY2x1ZGUgPGxpbnV4L21vZHVs
ZS5oPgorI2luY2x1ZGUgPGxpbnV4L2luaXQuaD4KKyNpbmNsdWRlIDxsaW51eC90eXBlcy5oPgor
I2luY2x1ZGUgPGxpbnV4L21lbW9yeV9ob3RwbHVnLmg+CisjaW5jbHVkZSA8YWNwaS9hY3BpX2Ry
aXZlcnMuaD4KKyNpbmNsdWRlIDx4ZW4vaW50ZXJmYWNlL3BsYXRmb3JtLmg+CisjaW5jbHVkZSA8
bGludXgvaW50ZXJydXB0Lmg+CisjaW5jbHVkZSA8bGludXgvc3BpbmxvY2suaD4KKyNpbmNsdWRl
IDxhc20veGVuL2h5cGVydmlzb3IuaD4KKyNpbmNsdWRlIDxhc20veGVuL2h5cGVyY2FsbC5oPgor
I2luY2x1ZGUgPHhlbi9hY3BpLmg+CisKK3N0cnVjdCB4ZW5faG90bWVtX2VudHJ5IHsKKwlzdHJ1
Y3QgbGlzdF9oZWFkIGhvdG1lbV9saXN0OworCXVpbnQ2NF90IHN0YXJ0OworCXVpbnQ2NF90IGVu
ZDsKKwl1aW50MzJfdCBmbGFnczsKKwl1aW50MzJfdCBweG07Cit9OworCitzdHJ1Y3QgeGVuX2hv
dG1lbV9saXN0IHsKKwlzdHJ1Y3QgbGlzdF9oZWFkIGxpc3Q7CisJaW50IGVudHJ5X25yOworfSB4
ZW5faG90bWVtOworCitERUZJTkVfU1BJTkxPQ0soeGVuX2hvdG1lbV9sb2NrKTsKKworc3RhdGlj
IGludCB4ZW5faHlwZXJfYWRkbWVtKHN0cnVjdCB4ZW5faG90bWVtX2VudHJ5ICplbnRyeSkKK3sK
KwlpbnQgcmV0OworCisJeGVuX3BsYXRmb3JtX29wX3Qgb3AgPSB7CisJCS5jbWQgICAgICAgICAg
ICA9IFhFTlBGX21lbV9ob3RhZGQsCisJCS5pbnRlcmZhY2VfdmVyc2lvbiAgPSBYRU5QRl9JTlRF
UkZBQ0VfVkVSU0lPTiwKKwl9OworCW9wLnUubWVtX2FkZC5zcGZuID0gZW50cnktPnN0YXJ0ID4+
IFBBR0VfU0hJRlQ7CisJb3AudS5tZW1fYWRkLmVwZm4gPSBlbnRyeS0+ZW5kID4+IFBBR0VfU0hJ
RlQ7CisJb3AudS5tZW1fYWRkLmZsYWdzID0gZW50cnktPmZsYWdzOworCW9wLnUubWVtX2FkZC5w
eG0gPSBlbnRyeS0+cHhtOworCisJcmV0ID0gSFlQRVJWSVNPUl9kb20wX29wKCZvcCk7CisJcmV0
dXJuIHJldDsKK30KKworc3RhdGljIGludCBhZGRfaG90bWVtX2VudHJ5KGludCBweG0sIHVpbnQ2
NF90IHN0YXJ0LAorCQkJdWludDY0X3QgbGVuZ3RoLCB1aW50MzJfdCBmbGFncykKK3sKKwlzdHJ1
Y3QgeGVuX2hvdG1lbV9lbnRyeSAqZW50cnk7CisKKwlpZiAocHhtIDwgMCB8fCAhbGVuZ3RoKQor
CQlyZXR1cm4gLUVJTlZBTDsKKworCWVudHJ5ID0ga3phbGxvYyhzaXplb2Yoc3RydWN0IHhlbl9o
b3RtZW1fZW50cnkpLCBHRlBfQVRPTUlDKTsKKwlpZiAoIWVudHJ5KQorCQlyZXR1cm4gLUVOT01F
TTsKKworCUlOSVRfTElTVF9IRUFEKCZlbnRyeS0+aG90bWVtX2xpc3QpOworCWVudHJ5LT5zdGFy
dCA9IHN0YXJ0OworCWVudHJ5LT5lbmQgPSBzdGFydCArIGxlbmd0aDsKKwllbnRyeS0+ZmxhZ3Mg
PSBmbGFnczsKKwllbnRyeS0+cHhtID0gcHhtOworCisJc3Bpbl9sb2NrKCZ4ZW5faG90bWVtX2xv
Y2spOworCisJbGlzdF9hZGRfdGFpbCgmZW50cnktPmhvdG1lbV9saXN0LCAmeGVuX2hvdG1lbS5s
aXN0KTsKKwl4ZW5faG90bWVtLmVudHJ5X25yKys7CisKKwlzcGluX3VubG9jaygmeGVuX2hvdG1l
bV9sb2NrKTsKKworCXJldHVybiAwOworfQorCitzdGF0aWMgaW50IGZyZWVfaG90bWVtX2VudHJ5
KHN0cnVjdCB4ZW5faG90bWVtX2VudHJ5ICplbnRyeSkKK3sKKwlsaXN0X2RlbCgmZW50cnktPmhv
dG1lbV9saXN0KTsKKwlrZnJlZShlbnRyeSk7CisKKwlyZXR1cm4gMDsKK30KKworc3RhdGljIHZv
aWQgeGVuX2hvdGFkZF9tZW1fZHBjKHN0cnVjdCB3b3JrX3N0cnVjdCAqd29yaykKK3sKKwlzdHJ1
Y3QgbGlzdF9oZWFkICplbGVtLCAqdG1wOworCXN0cnVjdCB4ZW5faG90bWVtX2VudHJ5ICplbnRy
eTsKKwl1bnNpZ25lZCBsb25nIGZsYWdzOworCWludCByZXQ7CisKKwlzcGluX2xvY2tfaXJxc2F2
ZSgmeGVuX2hvdG1lbV9sb2NrLCBmbGFncyk7CisJbGlzdF9mb3JfZWFjaF9zYWZlKGVsZW0sIHRt
cCwgJnhlbl9ob3RtZW0ubGlzdCkgeworCQllbnRyeSA9IGxpc3RfZW50cnkoZWxlbSwgc3RydWN0
IHhlbl9ob3RtZW1fZW50cnksIGhvdG1lbV9saXN0KTsKKwkJcmV0ID0geGVuX2h5cGVyX2FkZG1l
bShlbnRyeSk7CisJCWlmIChyZXQpCisJCQlwcmludGsoS0VSTl9XQVJOSU5HICJ4ZW4gYWRkbWVt
IGZhaWxlZCB3aXRoICV4XG4iLCByZXQpOworCQlmcmVlX2hvdG1lbV9lbnRyeShlbnRyeSk7CisJ
CXhlbl9ob3RtZW0uZW50cnlfbnItLTsKKwl9CisJc3Bpbl91bmxvY2tfaXJxcmVzdG9yZSgmeGVu
X2hvdG1lbV9sb2NrLCBmbGFncyk7Cit9CisKK3N0YXRpYyBERUNMQVJFX1dPUksoeGVuX2hvdGFk
ZF9tZW1fd29yaywgeGVuX2hvdGFkZF9tZW1fZHBjKTsKKworc3RhdGljIGludCB4ZW5fYWNwaV9n
ZXRfcHhtKGFjcGlfaGFuZGxlIGgpCit7CisJdW5zaWduZWQgbG9uZyBsb25nIHB4bTsKKwlhY3Bp
X3N0YXR1cyBzdGF0dXM7CisJYWNwaV9oYW5kbGUgaGFuZGxlOworCWFjcGlfaGFuZGxlIHBoYW5k
bGUgPSBoOworCisJZG8geworCQloYW5kbGUgPSBwaGFuZGxlOworCQlzdGF0dXMgPSBhY3BpX2V2
YWx1YXRlX2ludGVnZXIoaGFuZGxlLCAiX1BYTSIsIE5VTEwsICZweG0pOworCQlpZiAoQUNQSV9T
VUNDRVNTKHN0YXR1cykpCisJCQlyZXR1cm4gcHhtOworCQlzdGF0dXMgPSBhY3BpX2dldF9wYXJl
bnQoaGFuZGxlLCAmcGhhbmRsZSk7CisJfSB3aGlsZSAoQUNQSV9TVUNDRVNTKHN0YXR1cykpOwor
CisJcmV0dXJuIC0xOworfQorCitpbnQgeGVuX2hvdGFkZF9tZW1vcnkoc3RydWN0IGFjcGlfbWVt
b3J5X2RldmljZSAqbWVtX2RldmljZSkKK3sKKwlpbnQgcHhtLCByZXN1bHQ7CisJaW50IG51bV9l
bmFibGVkID0gMDsKKwlzdHJ1Y3QgYWNwaV9tZW1vcnlfaW5mbyAqaW5mbzsKKworCWlmICghbWVt
X2RldmljZSkKKwkJcmV0dXJuIC1FSU5WQUw7CisKKwlweG0gPSB4ZW5fYWNwaV9nZXRfcHhtKG1l
bV9kZXZpY2UtPmRldmljZS0+aGFuZGxlKTsKKworCWlmIChweG0gPCAwKQorCQlyZXR1cm4gLUVJ
TlZBTDsKKworCS8qCisJICogQWx3YXlzIHJldHVybiBzdWNjZXNzIHRvIEFDUEkgZHJpdmVyLCBh
bmQgbm90aWZ5IGh5cGVydmlzb3IgbGF0ZXIKKwkgKiBiZWNhdXNlIGh5cGVydmlzb3Igd2lsbCB1
dGlsaXplIHRoZSBtZW1vcnkgaW4gbWVtb3J5IGhvdGFkZCBoeXBlcmNhbGwKKwkgKi8KKwlsaXN0
X2Zvcl9lYWNoX2VudHJ5KGluZm8sICZtZW1fZGV2aWNlLT5yZXNfbGlzdCwgbGlzdCkgeworCQlp
ZiAoaW5mby0+ZW5hYmxlZCkgeyAvKiBqdXN0IHNhbml0eSBjaGVjay4uLiovCisJCQludW1fZW5h
YmxlZCsrOworCQkJY29udGludWU7CisJCX0KKwkJLyoKKwkJICogSWYgdGhlIG1lbW9yeSBibG9j
ayBzaXplIGlzIHplcm8sIHBsZWFzZSBpZ25vcmUgaXQuCisJCSAqIERvbid0IHRyeSB0byBkbyB0
aGUgZm9sbG93aW5nIG1lbW9yeSBob3RwbHVnIGZsb3djaGFydC4KKwkJICovCisJCWlmICghaW5m
by0+bGVuZ3RoKQorCQkJY29udGludWU7CisKKwkJcmVzdWx0ID0gYWRkX2hvdG1lbV9lbnRyeShw
eG0sIGluZm8tPnN0YXJ0X2FkZHIsCisJCQkJCWluZm8tPmxlbmd0aCwgMCk7CisJCWlmIChyZXN1
bHQpCisJCQljb250aW51ZTsKKwkJaW5mby0+ZW5hYmxlZCA9IDE7CisJCW51bV9lbmFibGVkKys7
CisJfQorCisJaWYgKCFudW1fZW5hYmxlZCkKKwkJcmV0dXJuIC1FSU5WQUw7CisKKwlzY2hlZHVs
ZV93b3JrKCZ4ZW5faG90YWRkX21lbV93b3JrKTsKKworCXJldHVybiAwOworfQorRVhQT1JUX1NZ
TUJPTCh4ZW5faG90YWRkX21lbW9yeSk7CisKK3N0YXRpYyBpbnQgeGVuX2hvdGFkZF9tZW1faW5p
dCh2b2lkKQoreworCWlmICgheGVuX2luaXRpYWxfZG9tYWluKCkpCisJCXJldHVybiAtRU5PREVW
OworCisJSU5JVF9MSVNUX0hFQUQoJnhlbl9ob3RtZW0ubGlzdCk7CisJeGVuX2hvdG1lbS5lbnRy
eV9uciA9IDA7CisKKwlyZXR1cm4gMDsKK30KKworc3RhdGljIHZvaWQgeGVuX2hvdGFkZF9tZW1f
ZXhpdCh2b2lkKQoreworCWZsdXNoX3NjaGVkdWxlZF93b3JrKCk7Cit9CisKK21vZHVsZV9pbml0
KHhlbl9ob3RhZGRfbWVtX2luaXQpOworbW9kdWxlX2V4aXQoeGVuX2hvdGFkZF9tZW1fZXhpdCk7
CitNT0RVTEVfTElDRU5TRSgiR1BMIik7CmRpZmYgLS1naXQgYS9pbmNsdWRlL3hlbi9hY3BpLmgg
Yi9pbmNsdWRlL3hlbi9hY3BpLmgKaW5kZXggN2FhMjgyZC4uOGIzNDYyZSAxMDA2NDQKLS0tIGEv
aW5jbHVkZS94ZW4vYWNwaS5oCisrKyBiL2luY2x1ZGUveGVuL2FjcGkuaApAQCAtMTA3LDYgKzEw
NywxMSBAQCBzdGF0aWMgaW5saW5lIGludCB4ZW5fYWNwaV9wcm9jZXNzb3JfZ2V0X3BlcmZvcm1h
bmNlKHN0cnVjdCBhY3BpX3Byb2Nlc3NvciAqcHIpCiB9CiAjZW5kaWYKIAorI2lmIGRlZmluZWQo
Q09ORklHX0FDUElfSE9UUExVR19NRU1PUlkpIHx8IFwKK2RlZmluZWQoQ09ORklHX0FDUElfSE9U
UExVR19NRU1PUllfTU9EVUxFKQoraW50IHhlbl9ob3RhZGRfbWVtb3J5KHN0cnVjdCBhY3BpX21l
bW9yeV9kZXZpY2UgKm1lbV9kZXZpY2UpOworI2VuZGlmCisKICNpZiBkZWZpbmVkKENPTkZJR19B
Q1BJX1BST0NFU1NPUl9YRU4pIHx8IFwKIGRlZmluZWQoQ09ORklHX0FDUElfUFJPQ0VTU09SX1hF
Tl9NT0RVTEUpCiAKZGlmZiAtLWdpdCBhL2luY2x1ZGUveGVuL2ludGVyZmFjZS9wbGF0Zm9ybS5o
IGIvaW5jbHVkZS94ZW4vaW50ZXJmYWNlL3BsYXRmb3JtLmgKaW5kZXggOWZkNmIwNy4uMDc4N2M2
OCAxMDA2NDQKLS0tIGEvaW5jbHVkZS94ZW4vaW50ZXJmYWNlL3BsYXRmb3JtLmgKKysrIGIvaW5j
bHVkZS94ZW4vaW50ZXJmYWNlL3BsYXRmb3JtLmgKQEAgLTMyOSw2ICszMjksMTQgQEAgc3RydWN0
IHhlbnBmX2NwdV9ob3RhZGQgewogCXVpbnQzMl90IHB4bTsKIH07CiAKKyNkZWZpbmUgWEVOUEZf
bWVtX2hvdGFkZCAgICA1OQorc3RydWN0IHhlbnBmX21lbV9ob3RhZGQgeworCXVpbnQ2NF90IHNw
Zm47CisJdWludDY0X3QgZXBmbjsKKwl1aW50MzJfdCBweG07CisJdWludDMyX3QgZmxhZ3M7Cit9
OworCiBzdHJ1Y3QgeGVuX3BsYXRmb3JtX29wIHsKIAl1aW50MzJfdCBjbWQ7CiAJdWludDMyX3Qg
aW50ZXJmYWNlX3ZlcnNpb247IC8qIFhFTlBGX0lOVEVSRkFDRV9WRVJTSU9OICovCkBAIC0zNDcs
NiArMzU1LDcgQEAgc3RydWN0IHhlbl9wbGF0Zm9ybV9vcCB7CiAJCXN0cnVjdCB4ZW5wZl9wY3B1
aW5mbyAgICAgICAgICBwY3B1X2luZm87CiAJCXN0cnVjdCB4ZW5wZl9jcHVfb2wgICAgICAgICAg
ICBjcHVfb2w7CiAJCXN0cnVjdCB4ZW5wZl9jcHVfaG90YWRkICAgICAgICBjcHVfYWRkOworCQlz
dHJ1Y3QgeGVucGZfbWVtX2hvdGFkZCAgICAgICAgbWVtX2FkZDsKIAkJdWludDhfdCAgICAgICAg
ICAgICAgICAgICAgICAgIHBhZFsxMjhdOwogCX0gdTsKIH07Ci0tIAoxLjYuNS42Cgo=

--_002_DE8DF0795D48FD4CA783C40EC82923358A61SHSMSX101ccrcorpint_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--_002_DE8DF0795D48FD4CA783C40EC82923358A61SHSMSX101ccrcorpint_--


From xen-devel-bounces@lists.xensource.com Thu Dec 22 10:08:01 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 Dec 2011 10:08:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdfYy-0005OE-S0; Thu, 22 Dec 2011 10:07:48 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1RdfYw-0005NG-T2
	for xen-devel@lists.xensource.com; Thu, 22 Dec 2011 10:07:47 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1324548459!6502160!1
X-Originating-IP: [134.134.136.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjQgPT4gMzE5NDEx\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1781 invoked from network); 22 Dec 2011 10:07:39 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-2.tower-174.messagelabs.com with SMTP;
	22 Dec 2011 10:07:39 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga102.jf.intel.com with ESMTP; 22 Dec 2011 02:07:38 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.67,352,1309762800"; d="scan'208,223";a="89282609"
Received: from pgsmsx601.gar.corp.intel.com ([10.221.43.69])
	by orsmga001.jf.intel.com with ESMTP; 22 Dec 2011 02:07:37 -0800
Received: from pgsmsx104.gar.corp.intel.com (10.221.44.91) by
	pgsmsx601.gar.corp.intel.com (10.221.43.69) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Thu, 22 Dec 2011 18:06:59 +0800
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	PGSMSX104.gar.corp.intel.com (10.221.44.91) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Thu, 22 Dec 2011 18:06:58 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.38]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.199]) with mapi id
	14.01.0355.002; Thu, 22 Dec 2011 18:06:57 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: "konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Thread-Topic: [PATCH 06/10] Xen: Add memory hotadd to pvops dom0
Thread-Index: AczAkW9qsmV2yLulS6yL5Y6v3LXZtw==
Date: Thu, 22 Dec 2011 10:06:56 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC82923358A61@SHSMSX101.ccr.corp.intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
Content-Type: multipart/mixed;
	boundary="_002_DE8DF0795D48FD4CA783C40EC82923358A61SHSMSX101ccrcorpint_"
MIME-Version: 1.0
Cc: "Jiang, Yunhong" <yunhong.jiang@intel.com>,
	"jeremy.fitzhardinge@citrix.com" <jeremy.fitzhardinge@citrix.com>
Subject: [Xen-devel] [PATCH 06/10] Xen: Add memory hotadd to pvops dom0
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--_002_DE8DF0795D48FD4CA783C40EC82923358A61SHSMSX101ccrcorpint_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

>From a5d21e2a01049eef6aa64406e71f6574e7a371c1 Mon Sep 17 00:00:00 2001
From: Liu Jinsong <jinsong.liu@intel.com>
Date: Sun, 11 Dec 2011 21:51:28 +0800
Subject: [PATCH 06/10] Xen: Add memory hotadd to pvops dom0

This patch rebased from Jeremy's pvops commit
fe3cb1ebf78399fd5176ff6aa1c9ab498f2d8bd7

When memory hotadd event happen, a Xen hook will be called, to notify
hypervisor of the new added memory.

Because xen hypervisor will use the new memory to setup frametable/m2p
table, so dom0 will always return success to acpi bios, and notify xen
hypervisor later.

It add a hook in driver/acpi/acpi_memhotplug.c, but that change is
quite small, not sure if it is acceptable. Other method is to provide
a xen specific acpi_memory_device_driver, but I'm not sure if it worth
to add so much changes, to simply avoid two hooks.

Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
Signed-off-by: Jiang, Yunhong <yunhong.jiang@intel.com>
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
---
 drivers/acpi/acpi_memhotplug.c    |    4 +
 drivers/xen/Makefile              |    1 +
 drivers/xen/xen_acpi_memhotplug.c |  209 +++++++++++++++++++++++++++++++++=
++++
 include/xen/acpi.h                |    5 +
 include/xen/interface/platform.h  |    9 ++
 5 files changed, 228 insertions(+), 0 deletions(-)
 create mode 100644 drivers/xen/xen_acpi_memhotplug.c

diff --git a/drivers/acpi/acpi_memhotplug.c b/drivers/acpi/acpi_memhotplug.=
c
index e28e64d..2f2169e 100644
--- a/drivers/acpi/acpi_memhotplug.c
+++ b/drivers/acpi/acpi_memhotplug.c
@@ -32,6 +32,7 @@
 #include <linux/memory_hotplug.h>
 #include <linux/slab.h>
 #include <acpi/acpi_drivers.h>
+#include <xen/acpi.h>
=20
 #define ACPI_MEMORY_DEVICE_CLASS		"memory"
 #define ACPI_MEMORY_DEVICE_HID			"PNP0C80"
@@ -214,6 +215,9 @@ static int acpi_memory_enable_device(struct acpi_memory=
_device *mem_device)
 		return result;
 	}
=20
+	if (xen_initial_domain())
+		return xen_hotadd_memory(mem_device);
+
 	node =3D acpi_get_node(mem_device->device->handle);
 	/*
 	 * Tell the VM there is more memory here...
diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
index aedaf48..7dc3c0b 100644
--- a/drivers/xen/Makefile
+++ b/drivers/xen/Makefile
@@ -20,6 +20,7 @@ obj-$(CONFIG_XEN_TMEM)			+=3D tmem.o
 obj-$(CONFIG_SWIOTLB_XEN)		+=3D swiotlb-xen.o
 obj-$(CONFIG_XEN_DOM0)			+=3D pci.o acpi.o
 obj-$(CONFIG_XEN_PCIDEV_BACKEND)	+=3D xen-pciback/
+obj-$(CONFIG_ACPI_HOTPLUG_MEMORY)	+=3D xen_acpi_memhotplug.o
 ifdef CONFIG_ACPI_PROCESSOR_XEN
 obj-$(CONFIG_ACPI_PROCESSOR)		+=3D acpi_processor.o
 endif
diff --git a/drivers/xen/xen_acpi_memhotplug.c b/drivers/xen/xen_acpi_memho=
tplug.c
new file mode 100644
index 0000000..0c4af99
--- /dev/null
+++ b/drivers/xen/xen_acpi_memhotplug.c
@@ -0,0 +1,209 @@
+/*
+ *  xen_acpi_memhotplug.c - interface to notify Xen on memory device hotad=
d
+ *
+ *  Copyright (C) 2008, Intel corporation
+ *
+ * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~=
~~~
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License as published by
+ *  the Free Software Foundation; either version 2 of the License, or (at
+ *  your option) any later version.
+ *
+ *  This program is distributed in the hope that it will be useful, but
+ *  WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ *  General Public License for more details.
+ *
+ *  You should have received a copy of the GNU General Public License alon=
g
+ *  with this program; if not, write to the Free Software Foundation, Inc.=
,
+ *  59 Temple Place, Suite 330, Boston, MA 02111-1307 USA.
+ *
+ */
+
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/init.h>
+#include <linux/types.h>
+#include <linux/memory_hotplug.h>
+#include <acpi/acpi_drivers.h>
+#include <xen/interface/platform.h>
+#include <linux/interrupt.h>
+#include <linux/spinlock.h>
+#include <asm/xen/hypervisor.h>
+#include <asm/xen/hypercall.h>
+#include <xen/acpi.h>
+
+struct xen_hotmem_entry {
+	struct list_head hotmem_list;
+	uint64_t start;
+	uint64_t end;
+	uint32_t flags;
+	uint32_t pxm;
+};
+
+struct xen_hotmem_list {
+	struct list_head list;
+	int entry_nr;
+} xen_hotmem;
+
+DEFINE_SPINLOCK(xen_hotmem_lock);
+
+static int xen_hyper_addmem(struct xen_hotmem_entry *entry)
+{
+	int ret;
+
+	xen_platform_op_t op =3D {
+		.cmd            =3D XENPF_mem_hotadd,
+		.interface_version  =3D XENPF_INTERFACE_VERSION,
+	};
+	op.u.mem_add.spfn =3D entry->start >> PAGE_SHIFT;
+	op.u.mem_add.epfn =3D entry->end >> PAGE_SHIFT;
+	op.u.mem_add.flags =3D entry->flags;
+	op.u.mem_add.pxm =3D entry->pxm;
+
+	ret =3D HYPERVISOR_dom0_op(&op);
+	return ret;
+}
+
+static int add_hotmem_entry(int pxm, uint64_t start,
+			uint64_t length, uint32_t flags)
+{
+	struct xen_hotmem_entry *entry;
+
+	if (pxm < 0 || !length)
+		return -EINVAL;
+
+	entry =3D kzalloc(sizeof(struct xen_hotmem_entry), GFP_ATOMIC);
+	if (!entry)
+		return -ENOMEM;
+
+	INIT_LIST_HEAD(&entry->hotmem_list);
+	entry->start =3D start;
+	entry->end =3D start + length;
+	entry->flags =3D flags;
+	entry->pxm =3D pxm;
+
+	spin_lock(&xen_hotmem_lock);
+
+	list_add_tail(&entry->hotmem_list, &xen_hotmem.list);
+	xen_hotmem.entry_nr++;
+
+	spin_unlock(&xen_hotmem_lock);
+
+	return 0;
+}
+
+static int free_hotmem_entry(struct xen_hotmem_entry *entry)
+{
+	list_del(&entry->hotmem_list);
+	kfree(entry);
+
+	return 0;
+}
+
+static void xen_hotadd_mem_dpc(struct work_struct *work)
+{
+	struct list_head *elem, *tmp;
+	struct xen_hotmem_entry *entry;
+	unsigned long flags;
+	int ret;
+
+	spin_lock_irqsave(&xen_hotmem_lock, flags);
+	list_for_each_safe(elem, tmp, &xen_hotmem.list) {
+		entry =3D list_entry(elem, struct xen_hotmem_entry, hotmem_list);
+		ret =3D xen_hyper_addmem(entry);
+		if (ret)
+			printk(KERN_WARNING "xen addmem failed with %x\n", ret);
+		free_hotmem_entry(entry);
+		xen_hotmem.entry_nr--;
+	}
+	spin_unlock_irqrestore(&xen_hotmem_lock, flags);
+}
+
+static DECLARE_WORK(xen_hotadd_mem_work, xen_hotadd_mem_dpc);
+
+static int xen_acpi_get_pxm(acpi_handle h)
+{
+	unsigned long long pxm;
+	acpi_status status;
+	acpi_handle handle;
+	acpi_handle phandle =3D h;
+
+	do {
+		handle =3D phandle;
+		status =3D acpi_evaluate_integer(handle, "_PXM", NULL, &pxm);
+		if (ACPI_SUCCESS(status))
+			return pxm;
+		status =3D acpi_get_parent(handle, &phandle);
+	} while (ACPI_SUCCESS(status));
+
+	return -1;
+}
+
+int xen_hotadd_memory(struct acpi_memory_device *mem_device)
+{
+	int pxm, result;
+	int num_enabled =3D 0;
+	struct acpi_memory_info *info;
+
+	if (!mem_device)
+		return -EINVAL;
+
+	pxm =3D xen_acpi_get_pxm(mem_device->device->handle);
+
+	if (pxm < 0)
+		return -EINVAL;
+
+	/*
+	 * Always return success to ACPI driver, and notify hypervisor later
+	 * because hypervisor will utilize the memory in memory hotadd hypercall
+	 */
+	list_for_each_entry(info, &mem_device->res_list, list) {
+		if (info->enabled) { /* just sanity check...*/
+			num_enabled++;
+			continue;
+		}
+		/*
+		 * If the memory block size is zero, please ignore it.
+		 * Don't try to do the following memory hotplug flowchart.
+		 */
+		if (!info->length)
+			continue;
+
+		result =3D add_hotmem_entry(pxm, info->start_addr,
+					info->length, 0);
+		if (result)
+			continue;
+		info->enabled =3D 1;
+		num_enabled++;
+	}
+
+	if (!num_enabled)
+		return -EINVAL;
+
+	schedule_work(&xen_hotadd_mem_work);
+
+	return 0;
+}
+EXPORT_SYMBOL(xen_hotadd_memory);
+
+static int xen_hotadd_mem_init(void)
+{
+	if (!xen_initial_domain())
+		return -ENODEV;
+
+	INIT_LIST_HEAD(&xen_hotmem.list);
+	xen_hotmem.entry_nr =3D 0;
+
+	return 0;
+}
+
+static void xen_hotadd_mem_exit(void)
+{
+	flush_scheduled_work();
+}
+
+module_init(xen_hotadd_mem_init);
+module_exit(xen_hotadd_mem_exit);
+MODULE_LICENSE("GPL");
diff --git a/include/xen/acpi.h b/include/xen/acpi.h
index 7aa282d..8b3462e 100644
--- a/include/xen/acpi.h
+++ b/include/xen/acpi.h
@@ -107,6 +107,11 @@ static inline int xen_acpi_processor_get_performance(s=
truct acpi_processor *pr)
 }
 #endif
=20
+#if defined(CONFIG_ACPI_HOTPLUG_MEMORY) || \
+defined(CONFIG_ACPI_HOTPLUG_MEMORY_MODULE)
+int xen_hotadd_memory(struct acpi_memory_device *mem_device);
+#endif
+
 #if defined(CONFIG_ACPI_PROCESSOR_XEN) || \
 defined(CONFIG_ACPI_PROCESSOR_XEN_MODULE)
=20
diff --git a/include/xen/interface/platform.h b/include/xen/interface/platf=
orm.h
index 9fd6b07..0787c68 100644
--- a/include/xen/interface/platform.h
+++ b/include/xen/interface/platform.h
@@ -329,6 +329,14 @@ struct xenpf_cpu_hotadd {
 	uint32_t pxm;
 };
=20
+#define XENPF_mem_hotadd    59
+struct xenpf_mem_hotadd {
+	uint64_t spfn;
+	uint64_t epfn;
+	uint32_t pxm;
+	uint32_t flags;
+};
+
 struct xen_platform_op {
 	uint32_t cmd;
 	uint32_t interface_version; /* XENPF_INTERFACE_VERSION */
@@ -347,6 +355,7 @@ struct xen_platform_op {
 		struct xenpf_pcpuinfo          pcpu_info;
 		struct xenpf_cpu_ol            cpu_ol;
 		struct xenpf_cpu_hotadd        cpu_add;
+		struct xenpf_mem_hotadd        mem_add;
 		uint8_t                        pad[128];
 	} u;
 };
--=20
1.6.5.6

--_002_DE8DF0795D48FD4CA783C40EC82923358A61SHSMSX101ccrcorpint_
Content-Type: application/octet-stream;
	name="0006-Xen-Add-memory-hotadd-to-pvops-dom0.patch"
Content-Description: 0006-Xen-Add-memory-hotadd-to-pvops-dom0.patch
Content-Disposition: attachment;
	filename="0006-Xen-Add-memory-hotadd-to-pvops-dom0.patch"; size=9113;
	creation-date="Wed, 14 Dec 2011 15:20:15 GMT";
	modification-date="Wed, 14 Dec 2011 15:03:34 GMT"
Content-Transfer-Encoding: base64

RnJvbSBhNWQyMWUyYTAxMDQ5ZWVmNmFhNjQ0MDZlNzFmNjU3NGU3YTM3MWMxIE1vbiBTZXAgMTcg
MDA6MDA6MDAgMjAwMQpGcm9tOiBMaXUgSmluc29uZyA8amluc29uZy5saXVAaW50ZWwuY29tPgpE
YXRlOiBTdW4sIDExIERlYyAyMDExIDIxOjUxOjI4ICswODAwClN1YmplY3Q6IFtQQVRDSCAwNi8x
MF0gWGVuOiBBZGQgbWVtb3J5IGhvdGFkZCB0byBwdm9wcyBkb20wCgpUaGlzIHBhdGNoIHJlYmFz
ZWQgZnJvbSBKZXJlbXkncyBwdm9wcyBjb21taXQKZmUzY2IxZWJmNzgzOTlmZDUxNzZmZjZhYTFj
OWFiNDk4ZjJkOGJkNwoKV2hlbiBtZW1vcnkgaG90YWRkIGV2ZW50IGhhcHBlbiwgYSBYZW4gaG9v
ayB3aWxsIGJlIGNhbGxlZCwgdG8gbm90aWZ5Cmh5cGVydmlzb3Igb2YgdGhlIG5ldyBhZGRlZCBt
ZW1vcnkuCgpCZWNhdXNlIHhlbiBoeXBlcnZpc29yIHdpbGwgdXNlIHRoZSBuZXcgbWVtb3J5IHRv
IHNldHVwIGZyYW1ldGFibGUvbTJwCnRhYmxlLCBzbyBkb20wIHdpbGwgYWx3YXlzIHJldHVybiBz
dWNjZXNzIHRvIGFjcGkgYmlvcywgYW5kIG5vdGlmeSB4ZW4KaHlwZXJ2aXNvciBsYXRlci4KCkl0
IGFkZCBhIGhvb2sgaW4gZHJpdmVyL2FjcGkvYWNwaV9tZW1ob3RwbHVnLmMsIGJ1dCB0aGF0IGNo
YW5nZSBpcwpxdWl0ZSBzbWFsbCwgbm90IHN1cmUgaWYgaXQgaXMgYWNjZXB0YWJsZS4gT3RoZXIg
bWV0aG9kIGlzIHRvIHByb3ZpZGUKYSB4ZW4gc3BlY2lmaWMgYWNwaV9tZW1vcnlfZGV2aWNlX2Ry
aXZlciwgYnV0IEknbSBub3Qgc3VyZSBpZiBpdCB3b3J0aAp0byBhZGQgc28gbXVjaCBjaGFuZ2Vz
LCB0byBzaW1wbHkgYXZvaWQgdHdvIGhvb2tzLgoKU2lnbmVkLW9mZi1ieTogTGl1LCBKaW5zb25n
IDxqaW5zb25nLmxpdUBpbnRlbC5jb20+ClNpZ25lZC1vZmYtYnk6IEppYW5nLCBZdW5ob25nIDx5
dW5ob25nLmppYW5nQGludGVsLmNvbT4KU2lnbmVkLW9mZi1ieTogSmVyZW15IEZpdHpoYXJkaW5n
ZSA8amVyZW15LmZpdHpoYXJkaW5nZUBjaXRyaXguY29tPgotLS0KIGRyaXZlcnMvYWNwaS9hY3Bp
X21lbWhvdHBsdWcuYyAgICB8ICAgIDQgKwogZHJpdmVycy94ZW4vTWFrZWZpbGUgICAgICAgICAg
ICAgIHwgICAgMSArCiBkcml2ZXJzL3hlbi94ZW5fYWNwaV9tZW1ob3RwbHVnLmMgfCAgMjA5ICsr
KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysKIGluY2x1ZGUveGVuL2FjcGkuaCAg
ICAgICAgICAgICAgICB8ICAgIDUgKwogaW5jbHVkZS94ZW4vaW50ZXJmYWNlL3BsYXRmb3JtLmgg
IHwgICAgOSArKwogNSBmaWxlcyBjaGFuZ2VkLCAyMjggaW5zZXJ0aW9ucygrKSwgMCBkZWxldGlv
bnMoLSkKIGNyZWF0ZSBtb2RlIDEwMDY0NCBkcml2ZXJzL3hlbi94ZW5fYWNwaV9tZW1ob3RwbHVn
LmMKCmRpZmYgLS1naXQgYS9kcml2ZXJzL2FjcGkvYWNwaV9tZW1ob3RwbHVnLmMgYi9kcml2ZXJz
L2FjcGkvYWNwaV9tZW1ob3RwbHVnLmMKaW5kZXggZTI4ZTY0ZC4uMmYyMTY5ZSAxMDA2NDQKLS0t
IGEvZHJpdmVycy9hY3BpL2FjcGlfbWVtaG90cGx1Zy5jCisrKyBiL2RyaXZlcnMvYWNwaS9hY3Bp
X21lbWhvdHBsdWcuYwpAQCAtMzIsNiArMzIsNyBAQAogI2luY2x1ZGUgPGxpbnV4L21lbW9yeV9o
b3RwbHVnLmg+CiAjaW5jbHVkZSA8bGludXgvc2xhYi5oPgogI2luY2x1ZGUgPGFjcGkvYWNwaV9k
cml2ZXJzLmg+CisjaW5jbHVkZSA8eGVuL2FjcGkuaD4KIAogI2RlZmluZSBBQ1BJX01FTU9SWV9E
RVZJQ0VfQ0xBU1MJCSJtZW1vcnkiCiAjZGVmaW5lIEFDUElfTUVNT1JZX0RFVklDRV9ISUQJCQki
UE5QMEM4MCIKQEAgLTIxNCw2ICsyMTUsOSBAQCBzdGF0aWMgaW50IGFjcGlfbWVtb3J5X2VuYWJs
ZV9kZXZpY2Uoc3RydWN0IGFjcGlfbWVtb3J5X2RldmljZSAqbWVtX2RldmljZSkKIAkJcmV0dXJu
IHJlc3VsdDsKIAl9CiAKKwlpZiAoeGVuX2luaXRpYWxfZG9tYWluKCkpCisJCXJldHVybiB4ZW5f
aG90YWRkX21lbW9yeShtZW1fZGV2aWNlKTsKKwogCW5vZGUgPSBhY3BpX2dldF9ub2RlKG1lbV9k
ZXZpY2UtPmRldmljZS0+aGFuZGxlKTsKIAkvKgogCSAqIFRlbGwgdGhlIFZNIHRoZXJlIGlzIG1v
cmUgbWVtb3J5IGhlcmUuLi4KZGlmZiAtLWdpdCBhL2RyaXZlcnMveGVuL01ha2VmaWxlIGIvZHJp
dmVycy94ZW4vTWFrZWZpbGUKaW5kZXggYWVkYWY0OC4uN2RjM2MwYiAxMDA2NDQKLS0tIGEvZHJp
dmVycy94ZW4vTWFrZWZpbGUKKysrIGIvZHJpdmVycy94ZW4vTWFrZWZpbGUKQEAgLTIwLDYgKzIw
LDcgQEAgb2JqLSQoQ09ORklHX1hFTl9UTUVNKQkJCSs9IHRtZW0ubwogb2JqLSQoQ09ORklHX1NX
SU9UTEJfWEVOKQkJKz0gc3dpb3RsYi14ZW4ubwogb2JqLSQoQ09ORklHX1hFTl9ET00wKQkJCSs9
IHBjaS5vIGFjcGkubwogb2JqLSQoQ09ORklHX1hFTl9QQ0lERVZfQkFDS0VORCkJKz0geGVuLXBj
aWJhY2svCitvYmotJChDT05GSUdfQUNQSV9IT1RQTFVHX01FTU9SWSkJKz0geGVuX2FjcGlfbWVt
aG90cGx1Zy5vCiBpZmRlZiBDT05GSUdfQUNQSV9QUk9DRVNTT1JfWEVOCiBvYmotJChDT05GSUdf
QUNQSV9QUk9DRVNTT1IpCQkrPSBhY3BpX3Byb2Nlc3Nvci5vCiBlbmRpZgpkaWZmIC0tZ2l0IGEv
ZHJpdmVycy94ZW4veGVuX2FjcGlfbWVtaG90cGx1Zy5jIGIvZHJpdmVycy94ZW4veGVuX2FjcGlf
bWVtaG90cGx1Zy5jCm5ldyBmaWxlIG1vZGUgMTAwNjQ0CmluZGV4IDAwMDAwMDAuLjBjNGFmOTkK
LS0tIC9kZXYvbnVsbAorKysgYi9kcml2ZXJzL3hlbi94ZW5fYWNwaV9tZW1ob3RwbHVnLmMKQEAg
LTAsMCArMSwyMDkgQEAKKy8qCisgKiAgeGVuX2FjcGlfbWVtaG90cGx1Zy5jIC0gaW50ZXJmYWNl
IHRvIG5vdGlmeSBYZW4gb24gbWVtb3J5IGRldmljZSBob3RhZGQKKyAqCisgKiAgQ29weXJpZ2h0
IChDKSAyMDA4LCBJbnRlbCBjb3Jwb3JhdGlvbgorICoKKyAqIH5+fn5+fn5+fn5+fn5+fn5+fn5+
fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+Cisg
KgorICogIFRoaXMgcHJvZ3JhbSBpcyBmcmVlIHNvZnR3YXJlOyB5b3UgY2FuIHJlZGlzdHJpYnV0
ZSBpdCBhbmQvb3IgbW9kaWZ5CisgKiAgaXQgdW5kZXIgdGhlIHRlcm1zIG9mIHRoZSBHTlUgR2Vu
ZXJhbCBQdWJsaWMgTGljZW5zZSBhcyBwdWJsaXNoZWQgYnkKKyAqICB0aGUgRnJlZSBTb2Z0d2Fy
ZSBGb3VuZGF0aW9uOyBlaXRoZXIgdmVyc2lvbiAyIG9mIHRoZSBMaWNlbnNlLCBvciAoYXQKKyAq
ICB5b3VyIG9wdGlvbikgYW55IGxhdGVyIHZlcnNpb24uCisgKgorICogIFRoaXMgcHJvZ3JhbSBp
cyBkaXN0cmlidXRlZCBpbiB0aGUgaG9wZSB0aGF0IGl0IHdpbGwgYmUgdXNlZnVsLCBidXQKKyAq
ICBXSVRIT1VUIEFOWSBXQVJSQU5UWTsgd2l0aG91dCBldmVuIHRoZSBpbXBsaWVkIHdhcnJhbnR5
IG9mCisgKiAgTUVSQ0hBTlRBQklMSVRZIG9yIEZJVE5FU1MgRk9SIEEgUEFSVElDVUxBUiBQVVJQ
T1NFLiAgU2VlIHRoZSBHTlUKKyAqICBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlIGZvciBtb3JlIGRl
dGFpbHMuCisgKgorICogIFlvdSBzaG91bGQgaGF2ZSByZWNlaXZlZCBhIGNvcHkgb2YgdGhlIEdO
VSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlIGFsb25nCisgKiAgd2l0aCB0aGlzIHByb2dyYW07IGlm
IG5vdCwgd3JpdGUgdG8gdGhlIEZyZWUgU29mdHdhcmUgRm91bmRhdGlvbiwgSW5jLiwKKyAqICA1
OSBUZW1wbGUgUGxhY2UsIFN1aXRlIDMzMCwgQm9zdG9uLCBNQSAwMjExMS0xMzA3IFVTQS4KKyAq
CisgKi8KKworI2luY2x1ZGUgPGxpbnV4L2tlcm5lbC5oPgorI2luY2x1ZGUgPGxpbnV4L21vZHVs
ZS5oPgorI2luY2x1ZGUgPGxpbnV4L2luaXQuaD4KKyNpbmNsdWRlIDxsaW51eC90eXBlcy5oPgor
I2luY2x1ZGUgPGxpbnV4L21lbW9yeV9ob3RwbHVnLmg+CisjaW5jbHVkZSA8YWNwaS9hY3BpX2Ry
aXZlcnMuaD4KKyNpbmNsdWRlIDx4ZW4vaW50ZXJmYWNlL3BsYXRmb3JtLmg+CisjaW5jbHVkZSA8
bGludXgvaW50ZXJydXB0Lmg+CisjaW5jbHVkZSA8bGludXgvc3BpbmxvY2suaD4KKyNpbmNsdWRl
IDxhc20veGVuL2h5cGVydmlzb3IuaD4KKyNpbmNsdWRlIDxhc20veGVuL2h5cGVyY2FsbC5oPgor
I2luY2x1ZGUgPHhlbi9hY3BpLmg+CisKK3N0cnVjdCB4ZW5faG90bWVtX2VudHJ5IHsKKwlzdHJ1
Y3QgbGlzdF9oZWFkIGhvdG1lbV9saXN0OworCXVpbnQ2NF90IHN0YXJ0OworCXVpbnQ2NF90IGVu
ZDsKKwl1aW50MzJfdCBmbGFnczsKKwl1aW50MzJfdCBweG07Cit9OworCitzdHJ1Y3QgeGVuX2hv
dG1lbV9saXN0IHsKKwlzdHJ1Y3QgbGlzdF9oZWFkIGxpc3Q7CisJaW50IGVudHJ5X25yOworfSB4
ZW5faG90bWVtOworCitERUZJTkVfU1BJTkxPQ0soeGVuX2hvdG1lbV9sb2NrKTsKKworc3RhdGlj
IGludCB4ZW5faHlwZXJfYWRkbWVtKHN0cnVjdCB4ZW5faG90bWVtX2VudHJ5ICplbnRyeSkKK3sK
KwlpbnQgcmV0OworCisJeGVuX3BsYXRmb3JtX29wX3Qgb3AgPSB7CisJCS5jbWQgICAgICAgICAg
ICA9IFhFTlBGX21lbV9ob3RhZGQsCisJCS5pbnRlcmZhY2VfdmVyc2lvbiAgPSBYRU5QRl9JTlRF
UkZBQ0VfVkVSU0lPTiwKKwl9OworCW9wLnUubWVtX2FkZC5zcGZuID0gZW50cnktPnN0YXJ0ID4+
IFBBR0VfU0hJRlQ7CisJb3AudS5tZW1fYWRkLmVwZm4gPSBlbnRyeS0+ZW5kID4+IFBBR0VfU0hJ
RlQ7CisJb3AudS5tZW1fYWRkLmZsYWdzID0gZW50cnktPmZsYWdzOworCW9wLnUubWVtX2FkZC5w
eG0gPSBlbnRyeS0+cHhtOworCisJcmV0ID0gSFlQRVJWSVNPUl9kb20wX29wKCZvcCk7CisJcmV0
dXJuIHJldDsKK30KKworc3RhdGljIGludCBhZGRfaG90bWVtX2VudHJ5KGludCBweG0sIHVpbnQ2
NF90IHN0YXJ0LAorCQkJdWludDY0X3QgbGVuZ3RoLCB1aW50MzJfdCBmbGFncykKK3sKKwlzdHJ1
Y3QgeGVuX2hvdG1lbV9lbnRyeSAqZW50cnk7CisKKwlpZiAocHhtIDwgMCB8fCAhbGVuZ3RoKQor
CQlyZXR1cm4gLUVJTlZBTDsKKworCWVudHJ5ID0ga3phbGxvYyhzaXplb2Yoc3RydWN0IHhlbl9o
b3RtZW1fZW50cnkpLCBHRlBfQVRPTUlDKTsKKwlpZiAoIWVudHJ5KQorCQlyZXR1cm4gLUVOT01F
TTsKKworCUlOSVRfTElTVF9IRUFEKCZlbnRyeS0+aG90bWVtX2xpc3QpOworCWVudHJ5LT5zdGFy
dCA9IHN0YXJ0OworCWVudHJ5LT5lbmQgPSBzdGFydCArIGxlbmd0aDsKKwllbnRyeS0+ZmxhZ3Mg
PSBmbGFnczsKKwllbnRyeS0+cHhtID0gcHhtOworCisJc3Bpbl9sb2NrKCZ4ZW5faG90bWVtX2xv
Y2spOworCisJbGlzdF9hZGRfdGFpbCgmZW50cnktPmhvdG1lbV9saXN0LCAmeGVuX2hvdG1lbS5s
aXN0KTsKKwl4ZW5faG90bWVtLmVudHJ5X25yKys7CisKKwlzcGluX3VubG9jaygmeGVuX2hvdG1l
bV9sb2NrKTsKKworCXJldHVybiAwOworfQorCitzdGF0aWMgaW50IGZyZWVfaG90bWVtX2VudHJ5
KHN0cnVjdCB4ZW5faG90bWVtX2VudHJ5ICplbnRyeSkKK3sKKwlsaXN0X2RlbCgmZW50cnktPmhv
dG1lbV9saXN0KTsKKwlrZnJlZShlbnRyeSk7CisKKwlyZXR1cm4gMDsKK30KKworc3RhdGljIHZv
aWQgeGVuX2hvdGFkZF9tZW1fZHBjKHN0cnVjdCB3b3JrX3N0cnVjdCAqd29yaykKK3sKKwlzdHJ1
Y3QgbGlzdF9oZWFkICplbGVtLCAqdG1wOworCXN0cnVjdCB4ZW5faG90bWVtX2VudHJ5ICplbnRy
eTsKKwl1bnNpZ25lZCBsb25nIGZsYWdzOworCWludCByZXQ7CisKKwlzcGluX2xvY2tfaXJxc2F2
ZSgmeGVuX2hvdG1lbV9sb2NrLCBmbGFncyk7CisJbGlzdF9mb3JfZWFjaF9zYWZlKGVsZW0sIHRt
cCwgJnhlbl9ob3RtZW0ubGlzdCkgeworCQllbnRyeSA9IGxpc3RfZW50cnkoZWxlbSwgc3RydWN0
IHhlbl9ob3RtZW1fZW50cnksIGhvdG1lbV9saXN0KTsKKwkJcmV0ID0geGVuX2h5cGVyX2FkZG1l
bShlbnRyeSk7CisJCWlmIChyZXQpCisJCQlwcmludGsoS0VSTl9XQVJOSU5HICJ4ZW4gYWRkbWVt
IGZhaWxlZCB3aXRoICV4XG4iLCByZXQpOworCQlmcmVlX2hvdG1lbV9lbnRyeShlbnRyeSk7CisJ
CXhlbl9ob3RtZW0uZW50cnlfbnItLTsKKwl9CisJc3Bpbl91bmxvY2tfaXJxcmVzdG9yZSgmeGVu
X2hvdG1lbV9sb2NrLCBmbGFncyk7Cit9CisKK3N0YXRpYyBERUNMQVJFX1dPUksoeGVuX2hvdGFk
ZF9tZW1fd29yaywgeGVuX2hvdGFkZF9tZW1fZHBjKTsKKworc3RhdGljIGludCB4ZW5fYWNwaV9n
ZXRfcHhtKGFjcGlfaGFuZGxlIGgpCit7CisJdW5zaWduZWQgbG9uZyBsb25nIHB4bTsKKwlhY3Bp
X3N0YXR1cyBzdGF0dXM7CisJYWNwaV9oYW5kbGUgaGFuZGxlOworCWFjcGlfaGFuZGxlIHBoYW5k
bGUgPSBoOworCisJZG8geworCQloYW5kbGUgPSBwaGFuZGxlOworCQlzdGF0dXMgPSBhY3BpX2V2
YWx1YXRlX2ludGVnZXIoaGFuZGxlLCAiX1BYTSIsIE5VTEwsICZweG0pOworCQlpZiAoQUNQSV9T
VUNDRVNTKHN0YXR1cykpCisJCQlyZXR1cm4gcHhtOworCQlzdGF0dXMgPSBhY3BpX2dldF9wYXJl
bnQoaGFuZGxlLCAmcGhhbmRsZSk7CisJfSB3aGlsZSAoQUNQSV9TVUNDRVNTKHN0YXR1cykpOwor
CisJcmV0dXJuIC0xOworfQorCitpbnQgeGVuX2hvdGFkZF9tZW1vcnkoc3RydWN0IGFjcGlfbWVt
b3J5X2RldmljZSAqbWVtX2RldmljZSkKK3sKKwlpbnQgcHhtLCByZXN1bHQ7CisJaW50IG51bV9l
bmFibGVkID0gMDsKKwlzdHJ1Y3QgYWNwaV9tZW1vcnlfaW5mbyAqaW5mbzsKKworCWlmICghbWVt
X2RldmljZSkKKwkJcmV0dXJuIC1FSU5WQUw7CisKKwlweG0gPSB4ZW5fYWNwaV9nZXRfcHhtKG1l
bV9kZXZpY2UtPmRldmljZS0+aGFuZGxlKTsKKworCWlmIChweG0gPCAwKQorCQlyZXR1cm4gLUVJ
TlZBTDsKKworCS8qCisJICogQWx3YXlzIHJldHVybiBzdWNjZXNzIHRvIEFDUEkgZHJpdmVyLCBh
bmQgbm90aWZ5IGh5cGVydmlzb3IgbGF0ZXIKKwkgKiBiZWNhdXNlIGh5cGVydmlzb3Igd2lsbCB1
dGlsaXplIHRoZSBtZW1vcnkgaW4gbWVtb3J5IGhvdGFkZCBoeXBlcmNhbGwKKwkgKi8KKwlsaXN0
X2Zvcl9lYWNoX2VudHJ5KGluZm8sICZtZW1fZGV2aWNlLT5yZXNfbGlzdCwgbGlzdCkgeworCQlp
ZiAoaW5mby0+ZW5hYmxlZCkgeyAvKiBqdXN0IHNhbml0eSBjaGVjay4uLiovCisJCQludW1fZW5h
YmxlZCsrOworCQkJY29udGludWU7CisJCX0KKwkJLyoKKwkJICogSWYgdGhlIG1lbW9yeSBibG9j
ayBzaXplIGlzIHplcm8sIHBsZWFzZSBpZ25vcmUgaXQuCisJCSAqIERvbid0IHRyeSB0byBkbyB0
aGUgZm9sbG93aW5nIG1lbW9yeSBob3RwbHVnIGZsb3djaGFydC4KKwkJICovCisJCWlmICghaW5m
by0+bGVuZ3RoKQorCQkJY29udGludWU7CisKKwkJcmVzdWx0ID0gYWRkX2hvdG1lbV9lbnRyeShw
eG0sIGluZm8tPnN0YXJ0X2FkZHIsCisJCQkJCWluZm8tPmxlbmd0aCwgMCk7CisJCWlmIChyZXN1
bHQpCisJCQljb250aW51ZTsKKwkJaW5mby0+ZW5hYmxlZCA9IDE7CisJCW51bV9lbmFibGVkKys7
CisJfQorCisJaWYgKCFudW1fZW5hYmxlZCkKKwkJcmV0dXJuIC1FSU5WQUw7CisKKwlzY2hlZHVs
ZV93b3JrKCZ4ZW5faG90YWRkX21lbV93b3JrKTsKKworCXJldHVybiAwOworfQorRVhQT1JUX1NZ
TUJPTCh4ZW5faG90YWRkX21lbW9yeSk7CisKK3N0YXRpYyBpbnQgeGVuX2hvdGFkZF9tZW1faW5p
dCh2b2lkKQoreworCWlmICgheGVuX2luaXRpYWxfZG9tYWluKCkpCisJCXJldHVybiAtRU5PREVW
OworCisJSU5JVF9MSVNUX0hFQUQoJnhlbl9ob3RtZW0ubGlzdCk7CisJeGVuX2hvdG1lbS5lbnRy
eV9uciA9IDA7CisKKwlyZXR1cm4gMDsKK30KKworc3RhdGljIHZvaWQgeGVuX2hvdGFkZF9tZW1f
ZXhpdCh2b2lkKQoreworCWZsdXNoX3NjaGVkdWxlZF93b3JrKCk7Cit9CisKK21vZHVsZV9pbml0
KHhlbl9ob3RhZGRfbWVtX2luaXQpOworbW9kdWxlX2V4aXQoeGVuX2hvdGFkZF9tZW1fZXhpdCk7
CitNT0RVTEVfTElDRU5TRSgiR1BMIik7CmRpZmYgLS1naXQgYS9pbmNsdWRlL3hlbi9hY3BpLmgg
Yi9pbmNsdWRlL3hlbi9hY3BpLmgKaW5kZXggN2FhMjgyZC4uOGIzNDYyZSAxMDA2NDQKLS0tIGEv
aW5jbHVkZS94ZW4vYWNwaS5oCisrKyBiL2luY2x1ZGUveGVuL2FjcGkuaApAQCAtMTA3LDYgKzEw
NywxMSBAQCBzdGF0aWMgaW5saW5lIGludCB4ZW5fYWNwaV9wcm9jZXNzb3JfZ2V0X3BlcmZvcm1h
bmNlKHN0cnVjdCBhY3BpX3Byb2Nlc3NvciAqcHIpCiB9CiAjZW5kaWYKIAorI2lmIGRlZmluZWQo
Q09ORklHX0FDUElfSE9UUExVR19NRU1PUlkpIHx8IFwKK2RlZmluZWQoQ09ORklHX0FDUElfSE9U
UExVR19NRU1PUllfTU9EVUxFKQoraW50IHhlbl9ob3RhZGRfbWVtb3J5KHN0cnVjdCBhY3BpX21l
bW9yeV9kZXZpY2UgKm1lbV9kZXZpY2UpOworI2VuZGlmCisKICNpZiBkZWZpbmVkKENPTkZJR19B
Q1BJX1BST0NFU1NPUl9YRU4pIHx8IFwKIGRlZmluZWQoQ09ORklHX0FDUElfUFJPQ0VTU09SX1hF
Tl9NT0RVTEUpCiAKZGlmZiAtLWdpdCBhL2luY2x1ZGUveGVuL2ludGVyZmFjZS9wbGF0Zm9ybS5o
IGIvaW5jbHVkZS94ZW4vaW50ZXJmYWNlL3BsYXRmb3JtLmgKaW5kZXggOWZkNmIwNy4uMDc4N2M2
OCAxMDA2NDQKLS0tIGEvaW5jbHVkZS94ZW4vaW50ZXJmYWNlL3BsYXRmb3JtLmgKKysrIGIvaW5j
bHVkZS94ZW4vaW50ZXJmYWNlL3BsYXRmb3JtLmgKQEAgLTMyOSw2ICszMjksMTQgQEAgc3RydWN0
IHhlbnBmX2NwdV9ob3RhZGQgewogCXVpbnQzMl90IHB4bTsKIH07CiAKKyNkZWZpbmUgWEVOUEZf
bWVtX2hvdGFkZCAgICA1OQorc3RydWN0IHhlbnBmX21lbV9ob3RhZGQgeworCXVpbnQ2NF90IHNw
Zm47CisJdWludDY0X3QgZXBmbjsKKwl1aW50MzJfdCBweG07CisJdWludDMyX3QgZmxhZ3M7Cit9
OworCiBzdHJ1Y3QgeGVuX3BsYXRmb3JtX29wIHsKIAl1aW50MzJfdCBjbWQ7CiAJdWludDMyX3Qg
aW50ZXJmYWNlX3ZlcnNpb247IC8qIFhFTlBGX0lOVEVSRkFDRV9WRVJTSU9OICovCkBAIC0zNDcs
NiArMzU1LDcgQEAgc3RydWN0IHhlbl9wbGF0Zm9ybV9vcCB7CiAJCXN0cnVjdCB4ZW5wZl9wY3B1
aW5mbyAgICAgICAgICBwY3B1X2luZm87CiAJCXN0cnVjdCB4ZW5wZl9jcHVfb2wgICAgICAgICAg
ICBjcHVfb2w7CiAJCXN0cnVjdCB4ZW5wZl9jcHVfaG90YWRkICAgICAgICBjcHVfYWRkOworCQlz
dHJ1Y3QgeGVucGZfbWVtX2hvdGFkZCAgICAgICAgbWVtX2FkZDsKIAkJdWludDhfdCAgICAgICAg
ICAgICAgICAgICAgICAgIHBhZFsxMjhdOwogCX0gdTsKIH07Ci0tIAoxLjYuNS42Cgo=

--_002_DE8DF0795D48FD4CA783C40EC82923358A61SHSMSX101ccrcorpint_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--_002_DE8DF0795D48FD4CA783C40EC82923358A61SHSMSX101ccrcorpint_--


From xen-devel-bounces@lists.xensource.com Thu Dec 22 10:08:04 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 Dec 2011 10:08:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdfZ7-0005QP-Gp; Thu, 22 Dec 2011 10:07:57 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1RdfZ6-0005Ot-HP
	for xen-devel@lists.xensource.com; Thu, 22 Dec 2011 10:07:56 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1324548469!2947597!1
X-Originating-IP: [143.182.124.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjE0OTQw\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15479 invoked from network); 22 Dec 2011 10:07:49 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-9.tower-21.messagelabs.com with SMTP;
	22 Dec 2011 10:07:49 -0000
Received: from azsmga002.ch.intel.com ([10.2.17.35])
	by azsmga101.ch.intel.com with ESMTP; 22 Dec 2011 02:07:48 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208,223";a="49700949"
Received: from pgsmsx603.gar.corp.intel.com ([10.221.43.87])
	by AZSMGA002.ch.intel.com with ESMTP; 22 Dec 2011 02:07:47 -0800
Received: from pgsmsx102.gar.corp.intel.com (10.221.44.80) by
	pgsmsx603.gar.corp.intel.com (10.221.43.87) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Thu, 22 Dec 2011 18:07:46 +0800
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	PGSMSX102.gar.corp.intel.com (10.221.44.80) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Thu, 22 Dec 2011 18:07:45 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.38]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.223]) with mapi id
	14.01.0355.002; Thu, 22 Dec 2011 18:07:44 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: "konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Thread-Topic: [PATCH 07/10] xen/acpi: Prepare for cpu hotplug
Thread-Index: AczAkYvY5eE6p+VISiSk5IjYgWWlyw==
Date: Thu, 22 Dec 2011 10:07:43 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC82923358A6E@SHSMSX101.ccr.corp.intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
Content-Type: multipart/mixed;
	boundary="_002_DE8DF0795D48FD4CA783C40EC82923358A6ESHSMSX101ccrcorpint_"
MIME-Version: 1.0
Cc: "Jiang, Yunhong" <yunhong.jiang@intel.com>,
	"jeremy.fitzhardinge@citrix.com" <jeremy.fitzhardinge@citrix.com>
Subject: [Xen-devel] [PATCH 07/10] xen/acpi: Prepare for cpu hotplug
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--_002_DE8DF0795D48FD4CA783C40EC82923358A6ESHSMSX101ccrcorpint_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

>From 0dad15c02d033d6be7e9447fbe5f645d97badc24 Mon Sep 17 00:00:00 2001
From: Liu Jinsong <jinsong.liu@intel.com>
Date: Tue, 13 Dec 2011 21:14:45 +0800
Subject: [PATCH 07/10] xen/acpi: Prepare for cpu hotplug

This patch rebased from Jeremy's pvops commit
68320323a51c2378aca433c76157d9e66104ff1e

It does some prepare work for cpu hotplug

Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
Signed-off-by: Jiang, Yunhong <yunhong.jiang@intel.com>
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
---
 drivers/acpi/processor_xen.c |   37 +++++++++++++++++++++++++++++++++++++
 1 files changed, 37 insertions(+), 0 deletions(-)

diff --git a/drivers/acpi/processor_xen.c b/drivers/acpi/processor_xen.c
index 029e10c..38a1c05 100644
--- a/drivers/acpi/processor_xen.c
+++ b/drivers/acpi/processor_xen.c
@@ -19,6 +19,7 @@
 #include <acpi/acpi_drivers.h>
 #include <acpi/processor.h>
 #include <xen/acpi.h>
+#include <xen/pcpu.h>
=20
 #define PREFIX "ACPI: "
=20
@@ -54,6 +55,42 @@ struct acpi_driver xen_acpi_processor_driver =3D {
 		},
 };
=20
+static int is_processor_present(acpi_handle handle)
+{
+	acpi_status status;
+	unsigned long long sta =3D 0;
+
+
+	status =3D acpi_evaluate_integer(handle, "_STA", NULL, &sta);
+
+	if (ACPI_SUCCESS(status) && (sta & ACPI_STA_DEVICE_PRESENT))
+		return 1;
+
+	/*
+	 * _STA is mandatory for a processor that supports hot plug
+	 */
+	if (status =3D=3D AE_NOT_FOUND)
+		ACPI_DEBUG_PRINT((ACPI_DB_INFO,
+				"Processor does not support hot plug\n"));
+	else
+		ACPI_EXCEPTION((AE_INFO, status,
+				"Processor Device is not present"));
+	return 0;
+}
+
+static acpi_status
+xen_acpi_processor_hotadd_init(struct acpi_processor *pr, int *p_cpu)
+{
+	if (!is_processor_present(pr->handle))
+		return AE_ERROR;
+
+	if (processor_cntl_xen_notify(pr,
+				PROCESSOR_HOTPLUG, HOTPLUG_TYPE_ADD))
+		return AE_ERROR;
+
+	return AE_OK;
+}
+
 #ifdef CONFIG_CPU_FREQ
 /*
  * Existing ACPI module does parse performance states at some point,
--=20
1.6.5.6

--_002_DE8DF0795D48FD4CA783C40EC82923358A6ESHSMSX101ccrcorpint_
Content-Type: application/octet-stream;
	name="0007-xen-acpi-Prepare-for-cpu-hotplug.patch"
Content-Description: 0007-xen-acpi-Prepare-for-cpu-hotplug.patch
Content-Disposition: attachment;
	filename="0007-xen-acpi-Prepare-for-cpu-hotplug.patch"; size=1986;
	creation-date="Wed, 14 Dec 2011 15:20:15 GMT";
	modification-date="Wed, 14 Dec 2011 15:03:34 GMT"
Content-Transfer-Encoding: base64

RnJvbSAwZGFkMTVjMDJkMDMzZDZiZTdlOTQ0N2ZiZTVmNjQ1ZDk3YmFkYzI0IE1vbiBTZXAgMTcg
MDA6MDA6MDAgMjAwMQpGcm9tOiBMaXUgSmluc29uZyA8amluc29uZy5saXVAaW50ZWwuY29tPgpE
YXRlOiBUdWUsIDEzIERlYyAyMDExIDIxOjE0OjQ1ICswODAwClN1YmplY3Q6IFtQQVRDSCAwNy8x
MF0geGVuL2FjcGk6IFByZXBhcmUgZm9yIGNwdSBob3RwbHVnCgpUaGlzIHBhdGNoIHJlYmFzZWQg
ZnJvbSBKZXJlbXkncyBwdm9wcyBjb21taXQKNjgzMjAzMjNhNTFjMjM3OGFjYTQzM2M3NjE1N2Q5
ZTY2MTA0ZmYxZQoKSXQgZG9lcyBzb21lIHByZXBhcmUgd29yayBmb3IgY3B1IGhvdHBsdWcKClNp
Z25lZC1vZmYtYnk6IExpdSwgSmluc29uZyA8amluc29uZy5saXVAaW50ZWwuY29tPgpTaWduZWQt
b2ZmLWJ5OiBKaWFuZywgWXVuaG9uZyA8eXVuaG9uZy5qaWFuZ0BpbnRlbC5jb20+ClNpZ25lZC1v
ZmYtYnk6IEplcmVteSBGaXR6aGFyZGluZ2UgPGplcmVteS5maXR6aGFyZGluZ2VAY2l0cml4LmNv
bT4KLS0tCiBkcml2ZXJzL2FjcGkvcHJvY2Vzc29yX3hlbi5jIHwgICAzNyArKysrKysrKysrKysr
KysrKysrKysrKysrKysrKysrKysrKysrCiAxIGZpbGVzIGNoYW5nZWQsIDM3IGluc2VydGlvbnMo
KyksIDAgZGVsZXRpb25zKC0pCgpkaWZmIC0tZ2l0IGEvZHJpdmVycy9hY3BpL3Byb2Nlc3Nvcl94
ZW4uYyBiL2RyaXZlcnMvYWNwaS9wcm9jZXNzb3JfeGVuLmMKaW5kZXggMDI5ZTEwYy4uMzhhMWMw
NSAxMDA2NDQKLS0tIGEvZHJpdmVycy9hY3BpL3Byb2Nlc3Nvcl94ZW4uYworKysgYi9kcml2ZXJz
L2FjcGkvcHJvY2Vzc29yX3hlbi5jCkBAIC0xOSw2ICsxOSw3IEBACiAjaW5jbHVkZSA8YWNwaS9h
Y3BpX2RyaXZlcnMuaD4KICNpbmNsdWRlIDxhY3BpL3Byb2Nlc3Nvci5oPgogI2luY2x1ZGUgPHhl
bi9hY3BpLmg+CisjaW5jbHVkZSA8eGVuL3BjcHUuaD4KIAogI2RlZmluZSBQUkVGSVggIkFDUEk6
ICIKIApAQCAtNTQsNiArNTUsNDIgQEAgc3RydWN0IGFjcGlfZHJpdmVyIHhlbl9hY3BpX3Byb2Nl
c3Nvcl9kcml2ZXIgPSB7CiAJCX0sCiB9OwogCitzdGF0aWMgaW50IGlzX3Byb2Nlc3Nvcl9wcmVz
ZW50KGFjcGlfaGFuZGxlIGhhbmRsZSkKK3sKKwlhY3BpX3N0YXR1cyBzdGF0dXM7CisJdW5zaWdu
ZWQgbG9uZyBsb25nIHN0YSA9IDA7CisKKworCXN0YXR1cyA9IGFjcGlfZXZhbHVhdGVfaW50ZWdl
cihoYW5kbGUsICJfU1RBIiwgTlVMTCwgJnN0YSk7CisKKwlpZiAoQUNQSV9TVUNDRVNTKHN0YXR1
cykgJiYgKHN0YSAmIEFDUElfU1RBX0RFVklDRV9QUkVTRU5UKSkKKwkJcmV0dXJuIDE7CisKKwkv
KgorCSAqIF9TVEEgaXMgbWFuZGF0b3J5IGZvciBhIHByb2Nlc3NvciB0aGF0IHN1cHBvcnRzIGhv
dCBwbHVnCisJICovCisJaWYgKHN0YXR1cyA9PSBBRV9OT1RfRk9VTkQpCisJCUFDUElfREVCVUdf
UFJJTlQoKEFDUElfREJfSU5GTywKKwkJCQkiUHJvY2Vzc29yIGRvZXMgbm90IHN1cHBvcnQgaG90
IHBsdWdcbiIpKTsKKwllbHNlCisJCUFDUElfRVhDRVBUSU9OKChBRV9JTkZPLCBzdGF0dXMsCisJ
CQkJIlByb2Nlc3NvciBEZXZpY2UgaXMgbm90IHByZXNlbnQiKSk7CisJcmV0dXJuIDA7Cit9CisK
K3N0YXRpYyBhY3BpX3N0YXR1cworeGVuX2FjcGlfcHJvY2Vzc29yX2hvdGFkZF9pbml0KHN0cnVj
dCBhY3BpX3Byb2Nlc3NvciAqcHIsIGludCAqcF9jcHUpCit7CisJaWYgKCFpc19wcm9jZXNzb3Jf
cHJlc2VudChwci0+aGFuZGxlKSkKKwkJcmV0dXJuIEFFX0VSUk9SOworCisJaWYgKHByb2Nlc3Nv
cl9jbnRsX3hlbl9ub3RpZnkocHIsCisJCQkJUFJPQ0VTU09SX0hPVFBMVUcsIEhPVFBMVUdfVFlQ
RV9BREQpKQorCQlyZXR1cm4gQUVfRVJST1I7CisKKwlyZXR1cm4gQUVfT0s7Cit9CisKICNpZmRl
ZiBDT05GSUdfQ1BVX0ZSRVEKIC8qCiAgKiBFeGlzdGluZyBBQ1BJIG1vZHVsZSBkb2VzIHBhcnNl
IHBlcmZvcm1hbmNlIHN0YXRlcyBhdCBzb21lIHBvaW50LAotLSAKMS42LjUuNgoK

--_002_DE8DF0795D48FD4CA783C40EC82923358A6ESHSMSX101ccrcorpint_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--_002_DE8DF0795D48FD4CA783C40EC82923358A6ESHSMSX101ccrcorpint_--


From xen-devel-bounces@lists.xensource.com Thu Dec 22 10:08:04 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 Dec 2011 10:08:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdfZ7-0005QP-Gp; Thu, 22 Dec 2011 10:07:57 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1RdfZ6-0005Ot-HP
	for xen-devel@lists.xensource.com; Thu, 22 Dec 2011 10:07:56 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1324548469!2947597!1
X-Originating-IP: [143.182.124.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjE0OTQw\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15479 invoked from network); 22 Dec 2011 10:07:49 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-9.tower-21.messagelabs.com with SMTP;
	22 Dec 2011 10:07:49 -0000
Received: from azsmga002.ch.intel.com ([10.2.17.35])
	by azsmga101.ch.intel.com with ESMTP; 22 Dec 2011 02:07:48 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208,223";a="49700949"
Received: from pgsmsx603.gar.corp.intel.com ([10.221.43.87])
	by AZSMGA002.ch.intel.com with ESMTP; 22 Dec 2011 02:07:47 -0800
Received: from pgsmsx102.gar.corp.intel.com (10.221.44.80) by
	pgsmsx603.gar.corp.intel.com (10.221.43.87) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Thu, 22 Dec 2011 18:07:46 +0800
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	PGSMSX102.gar.corp.intel.com (10.221.44.80) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Thu, 22 Dec 2011 18:07:45 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.38]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.223]) with mapi id
	14.01.0355.002; Thu, 22 Dec 2011 18:07:44 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: "konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Thread-Topic: [PATCH 07/10] xen/acpi: Prepare for cpu hotplug
Thread-Index: AczAkYvY5eE6p+VISiSk5IjYgWWlyw==
Date: Thu, 22 Dec 2011 10:07:43 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC82923358A6E@SHSMSX101.ccr.corp.intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
Content-Type: multipart/mixed;
	boundary="_002_DE8DF0795D48FD4CA783C40EC82923358A6ESHSMSX101ccrcorpint_"
MIME-Version: 1.0
Cc: "Jiang, Yunhong" <yunhong.jiang@intel.com>,
	"jeremy.fitzhardinge@citrix.com" <jeremy.fitzhardinge@citrix.com>
Subject: [Xen-devel] [PATCH 07/10] xen/acpi: Prepare for cpu hotplug
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--_002_DE8DF0795D48FD4CA783C40EC82923358A6ESHSMSX101ccrcorpint_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

>From 0dad15c02d033d6be7e9447fbe5f645d97badc24 Mon Sep 17 00:00:00 2001
From: Liu Jinsong <jinsong.liu@intel.com>
Date: Tue, 13 Dec 2011 21:14:45 +0800
Subject: [PATCH 07/10] xen/acpi: Prepare for cpu hotplug

This patch rebased from Jeremy's pvops commit
68320323a51c2378aca433c76157d9e66104ff1e

It does some prepare work for cpu hotplug

Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
Signed-off-by: Jiang, Yunhong <yunhong.jiang@intel.com>
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
---
 drivers/acpi/processor_xen.c |   37 +++++++++++++++++++++++++++++++++++++
 1 files changed, 37 insertions(+), 0 deletions(-)

diff --git a/drivers/acpi/processor_xen.c b/drivers/acpi/processor_xen.c
index 029e10c..38a1c05 100644
--- a/drivers/acpi/processor_xen.c
+++ b/drivers/acpi/processor_xen.c
@@ -19,6 +19,7 @@
 #include <acpi/acpi_drivers.h>
 #include <acpi/processor.h>
 #include <xen/acpi.h>
+#include <xen/pcpu.h>
=20
 #define PREFIX "ACPI: "
=20
@@ -54,6 +55,42 @@ struct acpi_driver xen_acpi_processor_driver =3D {
 		},
 };
=20
+static int is_processor_present(acpi_handle handle)
+{
+	acpi_status status;
+	unsigned long long sta =3D 0;
+
+
+	status =3D acpi_evaluate_integer(handle, "_STA", NULL, &sta);
+
+	if (ACPI_SUCCESS(status) && (sta & ACPI_STA_DEVICE_PRESENT))
+		return 1;
+
+	/*
+	 * _STA is mandatory for a processor that supports hot plug
+	 */
+	if (status =3D=3D AE_NOT_FOUND)
+		ACPI_DEBUG_PRINT((ACPI_DB_INFO,
+				"Processor does not support hot plug\n"));
+	else
+		ACPI_EXCEPTION((AE_INFO, status,
+				"Processor Device is not present"));
+	return 0;
+}
+
+static acpi_status
+xen_acpi_processor_hotadd_init(struct acpi_processor *pr, int *p_cpu)
+{
+	if (!is_processor_present(pr->handle))
+		return AE_ERROR;
+
+	if (processor_cntl_xen_notify(pr,
+				PROCESSOR_HOTPLUG, HOTPLUG_TYPE_ADD))
+		return AE_ERROR;
+
+	return AE_OK;
+}
+
 #ifdef CONFIG_CPU_FREQ
 /*
  * Existing ACPI module does parse performance states at some point,
--=20
1.6.5.6

--_002_DE8DF0795D48FD4CA783C40EC82923358A6ESHSMSX101ccrcorpint_
Content-Type: application/octet-stream;
	name="0007-xen-acpi-Prepare-for-cpu-hotplug.patch"
Content-Description: 0007-xen-acpi-Prepare-for-cpu-hotplug.patch
Content-Disposition: attachment;
	filename="0007-xen-acpi-Prepare-for-cpu-hotplug.patch"; size=1986;
	creation-date="Wed, 14 Dec 2011 15:20:15 GMT";
	modification-date="Wed, 14 Dec 2011 15:03:34 GMT"
Content-Transfer-Encoding: base64

RnJvbSAwZGFkMTVjMDJkMDMzZDZiZTdlOTQ0N2ZiZTVmNjQ1ZDk3YmFkYzI0IE1vbiBTZXAgMTcg
MDA6MDA6MDAgMjAwMQpGcm9tOiBMaXUgSmluc29uZyA8amluc29uZy5saXVAaW50ZWwuY29tPgpE
YXRlOiBUdWUsIDEzIERlYyAyMDExIDIxOjE0OjQ1ICswODAwClN1YmplY3Q6IFtQQVRDSCAwNy8x
MF0geGVuL2FjcGk6IFByZXBhcmUgZm9yIGNwdSBob3RwbHVnCgpUaGlzIHBhdGNoIHJlYmFzZWQg
ZnJvbSBKZXJlbXkncyBwdm9wcyBjb21taXQKNjgzMjAzMjNhNTFjMjM3OGFjYTQzM2M3NjE1N2Q5
ZTY2MTA0ZmYxZQoKSXQgZG9lcyBzb21lIHByZXBhcmUgd29yayBmb3IgY3B1IGhvdHBsdWcKClNp
Z25lZC1vZmYtYnk6IExpdSwgSmluc29uZyA8amluc29uZy5saXVAaW50ZWwuY29tPgpTaWduZWQt
b2ZmLWJ5OiBKaWFuZywgWXVuaG9uZyA8eXVuaG9uZy5qaWFuZ0BpbnRlbC5jb20+ClNpZ25lZC1v
ZmYtYnk6IEplcmVteSBGaXR6aGFyZGluZ2UgPGplcmVteS5maXR6aGFyZGluZ2VAY2l0cml4LmNv
bT4KLS0tCiBkcml2ZXJzL2FjcGkvcHJvY2Vzc29yX3hlbi5jIHwgICAzNyArKysrKysrKysrKysr
KysrKysrKysrKysrKysrKysrKysrKysrCiAxIGZpbGVzIGNoYW5nZWQsIDM3IGluc2VydGlvbnMo
KyksIDAgZGVsZXRpb25zKC0pCgpkaWZmIC0tZ2l0IGEvZHJpdmVycy9hY3BpL3Byb2Nlc3Nvcl94
ZW4uYyBiL2RyaXZlcnMvYWNwaS9wcm9jZXNzb3JfeGVuLmMKaW5kZXggMDI5ZTEwYy4uMzhhMWMw
NSAxMDA2NDQKLS0tIGEvZHJpdmVycy9hY3BpL3Byb2Nlc3Nvcl94ZW4uYworKysgYi9kcml2ZXJz
L2FjcGkvcHJvY2Vzc29yX3hlbi5jCkBAIC0xOSw2ICsxOSw3IEBACiAjaW5jbHVkZSA8YWNwaS9h
Y3BpX2RyaXZlcnMuaD4KICNpbmNsdWRlIDxhY3BpL3Byb2Nlc3Nvci5oPgogI2luY2x1ZGUgPHhl
bi9hY3BpLmg+CisjaW5jbHVkZSA8eGVuL3BjcHUuaD4KIAogI2RlZmluZSBQUkVGSVggIkFDUEk6
ICIKIApAQCAtNTQsNiArNTUsNDIgQEAgc3RydWN0IGFjcGlfZHJpdmVyIHhlbl9hY3BpX3Byb2Nl
c3Nvcl9kcml2ZXIgPSB7CiAJCX0sCiB9OwogCitzdGF0aWMgaW50IGlzX3Byb2Nlc3Nvcl9wcmVz
ZW50KGFjcGlfaGFuZGxlIGhhbmRsZSkKK3sKKwlhY3BpX3N0YXR1cyBzdGF0dXM7CisJdW5zaWdu
ZWQgbG9uZyBsb25nIHN0YSA9IDA7CisKKworCXN0YXR1cyA9IGFjcGlfZXZhbHVhdGVfaW50ZWdl
cihoYW5kbGUsICJfU1RBIiwgTlVMTCwgJnN0YSk7CisKKwlpZiAoQUNQSV9TVUNDRVNTKHN0YXR1
cykgJiYgKHN0YSAmIEFDUElfU1RBX0RFVklDRV9QUkVTRU5UKSkKKwkJcmV0dXJuIDE7CisKKwkv
KgorCSAqIF9TVEEgaXMgbWFuZGF0b3J5IGZvciBhIHByb2Nlc3NvciB0aGF0IHN1cHBvcnRzIGhv
dCBwbHVnCisJICovCisJaWYgKHN0YXR1cyA9PSBBRV9OT1RfRk9VTkQpCisJCUFDUElfREVCVUdf
UFJJTlQoKEFDUElfREJfSU5GTywKKwkJCQkiUHJvY2Vzc29yIGRvZXMgbm90IHN1cHBvcnQgaG90
IHBsdWdcbiIpKTsKKwllbHNlCisJCUFDUElfRVhDRVBUSU9OKChBRV9JTkZPLCBzdGF0dXMsCisJ
CQkJIlByb2Nlc3NvciBEZXZpY2UgaXMgbm90IHByZXNlbnQiKSk7CisJcmV0dXJuIDA7Cit9CisK
K3N0YXRpYyBhY3BpX3N0YXR1cworeGVuX2FjcGlfcHJvY2Vzc29yX2hvdGFkZF9pbml0KHN0cnVj
dCBhY3BpX3Byb2Nlc3NvciAqcHIsIGludCAqcF9jcHUpCit7CisJaWYgKCFpc19wcm9jZXNzb3Jf
cHJlc2VudChwci0+aGFuZGxlKSkKKwkJcmV0dXJuIEFFX0VSUk9SOworCisJaWYgKHByb2Nlc3Nv
cl9jbnRsX3hlbl9ub3RpZnkocHIsCisJCQkJUFJPQ0VTU09SX0hPVFBMVUcsIEhPVFBMVUdfVFlQ
RV9BREQpKQorCQlyZXR1cm4gQUVfRVJST1I7CisKKwlyZXR1cm4gQUVfT0s7Cit9CisKICNpZmRl
ZiBDT05GSUdfQ1BVX0ZSRVEKIC8qCiAgKiBFeGlzdGluZyBBQ1BJIG1vZHVsZSBkb2VzIHBhcnNl
IHBlcmZvcm1hbmNlIHN0YXRlcyBhdCBzb21lIHBvaW50LAotLSAKMS42LjUuNgoK

--_002_DE8DF0795D48FD4CA783C40EC82923358A6ESHSMSX101ccrcorpint_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--_002_DE8DF0795D48FD4CA783C40EC82923358A6ESHSMSX101ccrcorpint_--


From xen-devel-bounces@lists.xensource.com Thu Dec 22 10:08:56 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 Dec 2011 10: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.xensource.com>)
	id 1RdfZy-0005f1-1F; Thu, 22 Dec 2011 10:08:50 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1RdfZv-0005cc-RP
	for xen-devel@lists.xensource.com; Thu, 22 Dec 2011 10:08:48 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1324548518!8272694!1
X-Originating-IP: [143.182.124.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjE0OTQw\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14354 invoked from network); 22 Dec 2011 10:08:39 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-16.tower-216.messagelabs.com with SMTP;
	22 Dec 2011 10:08:39 -0000
Received: from azsmga002.ch.intel.com ([10.2.17.35])
	by azsmga101.ch.intel.com with ESMTP; 22 Dec 2011 02:08:38 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208,223";a="49701112"
Received: from pgsmsx603.gar.corp.intel.com ([10.221.43.87])
	by AZSMGA002.ch.intel.com with ESMTP; 22 Dec 2011 02:08:36 -0800
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	pgsmsx603.gar.corp.intel.com (10.221.43.87) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Thu, 22 Dec 2011 18:08:36 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.38]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.199]) with mapi id
	14.01.0355.002; Thu, 22 Dec 2011 18:08:34 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: "konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Thread-Topic: [PATCH 08/10] xen/acpi: add cpu hotadd support
Thread-Index: AczAkamqESM6qFDcSReYX5rCIgGotA==
Date: Thu, 22 Dec 2011 10:08:34 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC82923358A81@SHSMSX101.ccr.corp.intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
Content-Type: multipart/mixed;
	boundary="_002_DE8DF0795D48FD4CA783C40EC82923358A81SHSMSX101ccrcorpint_"
MIME-Version: 1.0
Cc: "Jiang, Yunhong" <yunhong.jiang@intel.com>,
	"jeremy.fitzhardinge@citrix.com" <jeremy.fitzhardinge@citrix.com>
Subject: [Xen-devel] [PATCH 08/10] xen/acpi: add cpu hotadd support
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--_002_DE8DF0795D48FD4CA783C40EC82923358A81SHSMSX101ccrcorpint_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

>From 282958be3a33b2f2b888e1ed3ac022bf8a199ec9 Mon Sep 17 00:00:00 2001
From: Liu Jinsong <jinsong.liu@intel.com>
Date: Wed, 14 Dec 2011 11:38:11 +0800
Subject: [PATCH 08/10] xen/acpi: add cpu hotadd support

This patch add cpu hotadd support.
It keep similar cpu hotadd logic as native, w/ some changes according
to xen requirement, hypercalling hypervisor related logic to hotadd cpu.

Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
Signed-off-by: Jiang, Yunhong <yunhong.jiang@intel.com>
---
 drivers/acpi/processor_driver.c |    4 +-
 drivers/acpi/processor_xen.c    |  242 +++++++++++++++++++++++++++++++++++=
+++-
 include/acpi/processor.h        |    2 +
 include/xen/pcpu.h              |    2 +
 4 files changed, 246 insertions(+), 4 deletions(-)

diff --git a/drivers/acpi/processor_driver.c b/drivers/acpi/processor_drive=
r.c
index 8a367d7..d473fd5 100644
--- a/drivers/acpi/processor_driver.c
+++ b/drivers/acpi/processor_driver.c
@@ -221,7 +221,7 @@ static int acpi_processor_errata_piix4(struct pci_dev *=
dev)
 	return 0;
 }
=20
-static int acpi_processor_errata(struct acpi_processor *pr)
+int acpi_processor_errata(struct acpi_processor *pr)
 {
 	int result =3D 0;
 	struct pci_dev *dev =3D NULL;
@@ -378,7 +378,7 @@ static int acpi_processor_get_info(struct acpi_device *=
device)
 	return 0;
 }
=20
-static DEFINE_PER_CPU(void *, processor_device_array);
+DEFINE_PER_CPU(void *, processor_device_array);
=20
 void acpi_processor_notify(struct acpi_device *device, u32 event)
 {
diff --git a/drivers/acpi/processor_xen.c b/drivers/acpi/processor_xen.c
index 38a1c05..3af1f73 100644
--- a/drivers/acpi/processor_xen.c
+++ b/drivers/acpi/processor_xen.c
@@ -24,6 +24,7 @@
 #define PREFIX "ACPI: "
=20
 #define ACPI_PROCESSOR_CLASS            "processor"
+#define ACPI_PROCESSOR_DEVICE_NAME      "Processor"
 #define ACPI_PROCESSOR_NOTIFY_PERFORMANCE 0x80
 #define ACPI_PROCESSOR_NOTIFY_POWER	0x81
 #define ACPI_PROCESSOR_NOTIFY_THROTTLING	0x82
@@ -88,6 +89,8 @@ xen_acpi_processor_hotadd_init(struct acpi_processor *pr,=
 int *p_cpu)
 				PROCESSOR_HOTPLUG, HOTPLUG_TYPE_ADD))
 		return AE_ERROR;
=20
+	*p_cpu =3D xen_pcpu_index(pr->acpi_id, 1);
+
 	return AE_OK;
 }
=20
@@ -149,13 +152,248 @@ err_out:
 }
 #endif /* CONFIG_CPU_FREQ */
=20
+static int xen_acpi_processor_get_info(struct acpi_device *device)
+{
+	acpi_status status =3D 0;
+	union acpi_object object =3D { 0 };
+	struct acpi_buffer buffer =3D { sizeof(union acpi_object), &object };
+	struct acpi_processor *pr;
+	int cpu_index, device_declaration =3D 0;
+	static int cpu0_initialized;
+
+	pr =3D acpi_driver_data(device);
+	if (!pr)
+		return -EINVAL;
+
+	if (num_online_cpus() > 1)
+		errata.smp =3D TRUE;
+
+	acpi_processor_errata(pr);
+
+	/*
+	 * Check to see if we have bus mastering arbitration control.  This
+	 * is required for proper C3 usage (to maintain cache coherency).
+	 */
+	if (acpi_gbl_FADT.pm2_control_block && acpi_gbl_FADT.pm2_control_length) =
{
+		pr->flags.bm_control =3D 1;
+		ACPI_DEBUG_PRINT((ACPI_DB_INFO,
+				  "Bus mastering arbitration control present\n"));
+	} else
+		ACPI_DEBUG_PRINT((ACPI_DB_INFO,
+				  "No bus mastering arbitration control\n"));
+
+	if (!strcmp(acpi_device_hid(device), ACPI_PROCESSOR_OBJECT_HID)) {
+		/* Declared with "Processor" statement; match ProcessorID */
+		status =3D acpi_evaluate_object(pr->handle, NULL, NULL, &buffer);
+		if (ACPI_FAILURE(status)) {
+			printk(KERN_ERR PREFIX "Evaluating processor object\n");
+			return -ENODEV;
+		}
+
+		/*
+		 * TBD: Synch processor ID (via LAPIC/LSAPIC structures) on SMP.
+		 *      >>> 'acpi_get_processor_id(acpi_id, &id)' in
+		 *      arch/xxx/acpi.c
+		 */
+		pr->acpi_id =3D object.processor.proc_id;
+	} else {
+		/*
+		 * Declared with "Device" statement; match _UID.
+		 * Note that we don't handle string _UIDs yet.
+		 */
+		unsigned long long value;
+		status =3D acpi_evaluate_integer(pr->handle, METHOD_NAME__UID,
+						NULL, &value);
+		if (ACPI_FAILURE(status)) {
+			printk(KERN_ERR PREFIX
+			    "Evaluating processor _UID [%#x]\n", status);
+			return -ENODEV;
+		}
+		device_declaration =3D 1;
+		pr->acpi_id =3D value;
+	}
+
+	cpu_index =3D xen_pcpu_index(pr->acpi_id, 1);
+
+	/* Handle UP system running SMP kernel, with no LAPIC in MADT */
+	if (!cpu0_initialized && (cpu_index =3D=3D -1) &&
+	    (num_online_cpus() =3D=3D 1)) {
+		cpu_index =3D 0;
+	}
+
+	cpu0_initialized =3D 1;
+
+	pr->id =3D cpu_index;
+
+	/*
+	 *  Extra Processor objects may be enumerated on MP systems with
+	 *  less than the max # of CPUs. They should be ignored _iff
+	 *  they are physically not present.
+	 */
+	if (pr->id =3D=3D -1) {
+		if (ACPI_FAILURE
+		    (xen_acpi_processor_hotadd_init(pr, &pr->id))) {
+			return -ENODEV;
+		}
+	}
+	/*
+	 * On some boxes several processors use the same processor bus id.
+	 * But they are located in different scope. For example:
+	 * \_SB.SCK0.CPU0
+	 * \_SB.SCK1.CPU0
+	 * Rename the processor device bus id. And the new bus id will be
+	 * generated as the following format:
+	 * CPU+CPU ID.
+	 */
+	sprintf(acpi_device_bid(device), "CPU%X", pr->id);
+	ACPI_DEBUG_PRINT((ACPI_DB_INFO, "Processor [%d:%d]\n", pr->id,
+			  pr->acpi_id));
+
+	if (!object.processor.pblk_address)
+		ACPI_DEBUG_PRINT((ACPI_DB_INFO, "No PBLK (NULL address)\n"));
+	else if (object.processor.pblk_length !=3D 6)
+		printk(KERN_ERR PREFIX "Invalid PBLK length [%d]\n",
+			    object.processor.pblk_length);
+	else {
+		pr->throttling.address =3D object.processor.pblk_address;
+		pr->throttling.duty_offset =3D acpi_gbl_FADT.duty_offset;
+		pr->throttling.duty_width =3D acpi_gbl_FADT.duty_width;
+
+		pr->pblk =3D object.processor.pblk_address;
+
+		/*
+		 * We don't care about error returns - we just try to mark
+		 * these reserved so that nobody else is confused into thinking
+		 * that this region might be unused..
+		 *
+		 * (In particular, allocating the IO range for Cardbus)
+		 */
+		request_region(pr->throttling.address, 6, "ACPI CPU throttle");
+	}
+
+	/*
+	 * If ACPI describes a slot number for this CPU, we can use it
+	 * ensure we get the right value in the "physical id" field
+	 * of /proc/cpuinfo
+	 */
+	status =3D acpi_evaluate_object(pr->handle, "_SUN", NULL, &buffer);
+	if (ACPI_SUCCESS(status))
+		arch_fix_phys_package_id(pr->id, object.integer.value);
+
+	return 0;
+}
+
+static int __cpuinit __xen_acpi_processor_add(struct acpi_device *device)
+{
+	struct acpi_processor *pr =3D NULL;
+	int result =3D 0;
+	struct sys_device *sysdev;
+
+	pr =3D kzalloc(sizeof(struct acpi_processor), GFP_KERNEL);
+	if (!pr)
+		return -ENOMEM;
+
+	if (!zalloc_cpumask_var(&pr->throttling.shared_cpu_map, GFP_KERNEL)) {
+		kfree(pr);
+		return -ENOMEM;
+	}
+
+	pr->handle =3D device->handle;
+	strcpy(acpi_device_name(device), ACPI_PROCESSOR_DEVICE_NAME);
+	strcpy(acpi_device_class(device), ACPI_PROCESSOR_CLASS);
+	device->driver_data =3D pr;
+
+	result =3D xen_acpi_processor_get_info(device);
+	if (result) {
+		/* Processor is physically not present */
+		return 0;
+	}
+
+#ifdef CONFIG_SMP
+	if (pr->id >=3D setup_max_cpus && pr->id !=3D 0)
+		return 0;
+#endif
+
+	BUG_ON((pr->id >=3D nr_cpu_ids) || (pr->id < 0));
+
+	/*
+	 * Buggy BIOS check
+	 * ACPI id of processors can be reported wrongly by the BIOS.
+	 * Don't trust it blindly
+	 */
+	if (per_cpu(processor_device_array, pr->id) !=3D NULL &&
+	    per_cpu(processor_device_array, pr->id) !=3D device) {
+		printk(KERN_WARNING "BIOS reported wrong ACPI id "
+			"for the processor\n");
+		result =3D -ENODEV;
+		goto err_free_cpumask;
+	}
+	per_cpu(processor_device_array, pr->id) =3D device;
+
+	per_cpu(processors, pr->id) =3D pr;
+
+	sysdev =3D get_cpu_sysdev(pr->id);
+	if (sysfs_create_link(&device->dev.kobj, &sysdev->kobj, "sysdev")) {
+		result =3D -EFAULT;
+		goto err_free_cpumask;
+	}
+
+#ifdef CONFIG_CPU_FREQ
+	acpi_processor_ppc_has_changed(pr, 0);
+#endif
+	acpi_processor_get_throttling_info(pr);
+	acpi_processor_get_limit_info(pr);
+
+
+	if (cpuidle_get_driver() =3D=3D &acpi_idle_driver)
+		acpi_processor_power_init(pr, device);
+
+	pr->cdev =3D thermal_cooling_device_register("Processor", device,
+						&processor_cooling_ops);
+	if (IS_ERR(pr->cdev)) {
+		result =3D PTR_ERR(pr->cdev);
+		goto err_power_exit;
+	}
+
+	dev_dbg(&device->dev, "registered as cooling_device%d\n",
+		 pr->cdev->id);
+
+	result =3D sysfs_create_link(&device->dev.kobj,
+				   &pr->cdev->device.kobj,
+				   "thermal_cooling");
+	if (result) {
+		printk(KERN_ERR PREFIX "Create sysfs link\n");
+		goto err_thermal_unregister;
+	}
+	result =3D sysfs_create_link(&pr->cdev->device.kobj,
+				   &device->dev.kobj,
+				   "device");
+	if (result) {
+		printk(KERN_ERR PREFIX "Create sysfs link\n");
+		goto err_remove_sysfs;
+	}
+
+	return 0;
+
+err_remove_sysfs:
+	sysfs_remove_link(&device->dev.kobj, "thermal_cooling");
+err_thermal_unregister:
+	thermal_cooling_device_unregister(pr->cdev);
+err_power_exit:
+	acpi_processor_power_exit(pr, device);
+err_free_cpumask:
+	free_cpumask_var(pr->throttling.shared_cpu_map);
+
+	return result;
+}
+
 static int __cpuinit xen_acpi_processor_add(struct acpi_device *device)
 {
 	struct acpi_processor *pr =3D NULL;
 	int result =3D 0;
=20
-	result =3D acpi_processor_add(device);
-	if (result < 0)
+	result =3D __xen_acpi_processor_add(device);
+	if (result)
 		return result;
=20
 	pr =3D acpi_driver_data(device);
diff --git a/include/acpi/processor.h b/include/acpi/processor.h
index c48e2f9..3a1ee01 100644
--- a/include/acpi/processor.h
+++ b/include/acpi/processor.h
@@ -225,6 +225,8 @@ struct acpi_processor_errata {
 	} piix4;
 };
=20
+extern int acpi_processor_errata(struct acpi_processor *pr);
+
 extern int acpi_processor_preregister_performance(struct
 						  acpi_processor_performance
 						  __percpu *performance);
diff --git a/include/xen/pcpu.h b/include/xen/pcpu.h
index 7e8f9d1..3e99db9 100644
--- a/include/xen/pcpu.h
+++ b/include/xen/pcpu.h
@@ -4,6 +4,8 @@
 #include <xen/interface/platform.h>
 #include <linux/sysdev.h>
=20
+extern DEFINE_PER_CPU(void *, processor_device_array);
+
 extern int xen_pcpu_hotplug(int type, uint32_t apic_id);
 #define XEN_PCPU_ONLINE     0x01
 #define XEN_PCPU_OFFLINE    0x02
--=20
1.6.5.6

--_002_DE8DF0795D48FD4CA783C40EC82923358A81SHSMSX101ccrcorpint_
Content-Type: application/octet-stream;
	name="0008-xen-acpi-add-cpu-hotadd-support.patch"
Content-Description: 0008-xen-acpi-add-cpu-hotadd-support.patch
Content-Disposition: attachment;
	filename="0008-xen-acpi-add-cpu-hotadd-support.patch"; size=10056;
	creation-date="Wed, 14 Dec 2011 15:20:15 GMT";
	modification-date="Wed, 14 Dec 2011 15:03:34 GMT"
Content-Transfer-Encoding: base64

RnJvbSAyODI5NThiZTNhMzNiMmYyYjg4OGUxZWQzYWMwMjJiZjhhMTk5ZWM5IE1vbiBTZXAgMTcg
MDA6MDA6MDAgMjAwMQpGcm9tOiBMaXUgSmluc29uZyA8amluc29uZy5saXVAaW50ZWwuY29tPgpE
YXRlOiBXZWQsIDE0IERlYyAyMDExIDExOjM4OjExICswODAwClN1YmplY3Q6IFtQQVRDSCAwOC8x
MF0geGVuL2FjcGk6IGFkZCBjcHUgaG90YWRkIHN1cHBvcnQKClRoaXMgcGF0Y2ggYWRkIGNwdSBo
b3RhZGQgc3VwcG9ydC4KSXQga2VlcCBzaW1pbGFyIGNwdSBob3RhZGQgbG9naWMgYXMgbmF0aXZl
LCB3LyBzb21lIGNoYW5nZXMgYWNjb3JkaW5nCnRvIHhlbiByZXF1aXJlbWVudCwgaHlwZXJjYWxs
aW5nIGh5cGVydmlzb3IgcmVsYXRlZCBsb2dpYyB0byBob3RhZGQgY3B1LgoKU2lnbmVkLW9mZi1i
eTogTGl1LCBKaW5zb25nIDxqaW5zb25nLmxpdUBpbnRlbC5jb20+ClNpZ25lZC1vZmYtYnk6IEpp
YW5nLCBZdW5ob25nIDx5dW5ob25nLmppYW5nQGludGVsLmNvbT4KLS0tCiBkcml2ZXJzL2FjcGkv
cHJvY2Vzc29yX2RyaXZlci5jIHwgICAgNCArLQogZHJpdmVycy9hY3BpL3Byb2Nlc3Nvcl94ZW4u
YyAgICB8ICAyNDIgKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKystCiBpbmNs
dWRlL2FjcGkvcHJvY2Vzc29yLmggICAgICAgIHwgICAgMiArCiBpbmNsdWRlL3hlbi9wY3B1Lmgg
ICAgICAgICAgICAgIHwgICAgMiArCiA0IGZpbGVzIGNoYW5nZWQsIDI0NiBpbnNlcnRpb25zKCsp
LCA0IGRlbGV0aW9ucygtKQoKZGlmZiAtLWdpdCBhL2RyaXZlcnMvYWNwaS9wcm9jZXNzb3JfZHJp
dmVyLmMgYi9kcml2ZXJzL2FjcGkvcHJvY2Vzc29yX2RyaXZlci5jCmluZGV4IDhhMzY3ZDcuLmQ0
NzNmZDUgMTAwNjQ0Ci0tLSBhL2RyaXZlcnMvYWNwaS9wcm9jZXNzb3JfZHJpdmVyLmMKKysrIGIv
ZHJpdmVycy9hY3BpL3Byb2Nlc3Nvcl9kcml2ZXIuYwpAQCAtMjIxLDcgKzIyMSw3IEBAIHN0YXRp
YyBpbnQgYWNwaV9wcm9jZXNzb3JfZXJyYXRhX3BpaXg0KHN0cnVjdCBwY2lfZGV2ICpkZXYpCiAJ
cmV0dXJuIDA7CiB9CiAKLXN0YXRpYyBpbnQgYWNwaV9wcm9jZXNzb3JfZXJyYXRhKHN0cnVjdCBh
Y3BpX3Byb2Nlc3NvciAqcHIpCitpbnQgYWNwaV9wcm9jZXNzb3JfZXJyYXRhKHN0cnVjdCBhY3Bp
X3Byb2Nlc3NvciAqcHIpCiB7CiAJaW50IHJlc3VsdCA9IDA7CiAJc3RydWN0IHBjaV9kZXYgKmRl
diA9IE5VTEw7CkBAIC0zNzgsNyArMzc4LDcgQEAgc3RhdGljIGludCBhY3BpX3Byb2Nlc3Nvcl9n
ZXRfaW5mbyhzdHJ1Y3QgYWNwaV9kZXZpY2UgKmRldmljZSkKIAlyZXR1cm4gMDsKIH0KIAotc3Rh
dGljIERFRklORV9QRVJfQ1BVKHZvaWQgKiwgcHJvY2Vzc29yX2RldmljZV9hcnJheSk7CitERUZJ
TkVfUEVSX0NQVSh2b2lkICosIHByb2Nlc3Nvcl9kZXZpY2VfYXJyYXkpOwogCiB2b2lkIGFjcGlf
cHJvY2Vzc29yX25vdGlmeShzdHJ1Y3QgYWNwaV9kZXZpY2UgKmRldmljZSwgdTMyIGV2ZW50KQog
ewpkaWZmIC0tZ2l0IGEvZHJpdmVycy9hY3BpL3Byb2Nlc3Nvcl94ZW4uYyBiL2RyaXZlcnMvYWNw
aS9wcm9jZXNzb3JfeGVuLmMKaW5kZXggMzhhMWMwNS4uM2FmMWY3MyAxMDA2NDQKLS0tIGEvZHJp
dmVycy9hY3BpL3Byb2Nlc3Nvcl94ZW4uYworKysgYi9kcml2ZXJzL2FjcGkvcHJvY2Vzc29yX3hl
bi5jCkBAIC0yNCw2ICsyNCw3IEBACiAjZGVmaW5lIFBSRUZJWCAiQUNQSTogIgogCiAjZGVmaW5l
IEFDUElfUFJPQ0VTU09SX0NMQVNTICAgICAgICAgICAgInByb2Nlc3NvciIKKyNkZWZpbmUgQUNQ
SV9QUk9DRVNTT1JfREVWSUNFX05BTUUgICAgICAiUHJvY2Vzc29yIgogI2RlZmluZSBBQ1BJX1BS
T0NFU1NPUl9OT1RJRllfUEVSRk9STUFOQ0UgMHg4MAogI2RlZmluZSBBQ1BJX1BST0NFU1NPUl9O
T1RJRllfUE9XRVIJMHg4MQogI2RlZmluZSBBQ1BJX1BST0NFU1NPUl9OT1RJRllfVEhST1RUTElO
RwkweDgyCkBAIC04OCw2ICs4OSw4IEBAIHhlbl9hY3BpX3Byb2Nlc3Nvcl9ob3RhZGRfaW5pdChz
dHJ1Y3QgYWNwaV9wcm9jZXNzb3IgKnByLCBpbnQgKnBfY3B1KQogCQkJCVBST0NFU1NPUl9IT1RQ
TFVHLCBIT1RQTFVHX1RZUEVfQUREKSkKIAkJcmV0dXJuIEFFX0VSUk9SOwogCisJKnBfY3B1ID0g
eGVuX3BjcHVfaW5kZXgocHItPmFjcGlfaWQsIDEpOworCiAJcmV0dXJuIEFFX09LOwogfQogCkBA
IC0xNDksMTMgKzE1MiwyNDggQEAgZXJyX291dDoKIH0KICNlbmRpZiAvKiBDT05GSUdfQ1BVX0ZS
RVEgKi8KIAorc3RhdGljIGludCB4ZW5fYWNwaV9wcm9jZXNzb3JfZ2V0X2luZm8oc3RydWN0IGFj
cGlfZGV2aWNlICpkZXZpY2UpCit7CisJYWNwaV9zdGF0dXMgc3RhdHVzID0gMDsKKwl1bmlvbiBh
Y3BpX29iamVjdCBvYmplY3QgPSB7IDAgfTsKKwlzdHJ1Y3QgYWNwaV9idWZmZXIgYnVmZmVyID0g
eyBzaXplb2YodW5pb24gYWNwaV9vYmplY3QpLCAmb2JqZWN0IH07CisJc3RydWN0IGFjcGlfcHJv
Y2Vzc29yICpwcjsKKwlpbnQgY3B1X2luZGV4LCBkZXZpY2VfZGVjbGFyYXRpb24gPSAwOworCXN0
YXRpYyBpbnQgY3B1MF9pbml0aWFsaXplZDsKKworCXByID0gYWNwaV9kcml2ZXJfZGF0YShkZXZp
Y2UpOworCWlmICghcHIpCisJCXJldHVybiAtRUlOVkFMOworCisJaWYgKG51bV9vbmxpbmVfY3B1
cygpID4gMSkKKwkJZXJyYXRhLnNtcCA9IFRSVUU7CisKKwlhY3BpX3Byb2Nlc3Nvcl9lcnJhdGEo
cHIpOworCisJLyoKKwkgKiBDaGVjayB0byBzZWUgaWYgd2UgaGF2ZSBidXMgbWFzdGVyaW5nIGFy
Yml0cmF0aW9uIGNvbnRyb2wuICBUaGlzCisJICogaXMgcmVxdWlyZWQgZm9yIHByb3BlciBDMyB1
c2FnZSAodG8gbWFpbnRhaW4gY2FjaGUgY29oZXJlbmN5KS4KKwkgKi8KKwlpZiAoYWNwaV9nYmxf
RkFEVC5wbTJfY29udHJvbF9ibG9jayAmJiBhY3BpX2dibF9GQURULnBtMl9jb250cm9sX2xlbmd0
aCkgeworCQlwci0+ZmxhZ3MuYm1fY29udHJvbCA9IDE7CisJCUFDUElfREVCVUdfUFJJTlQoKEFD
UElfREJfSU5GTywKKwkJCQkgICJCdXMgbWFzdGVyaW5nIGFyYml0cmF0aW9uIGNvbnRyb2wgcHJl
c2VudFxuIikpOworCX0gZWxzZQorCQlBQ1BJX0RFQlVHX1BSSU5UKChBQ1BJX0RCX0lORk8sCisJ
CQkJICAiTm8gYnVzIG1hc3RlcmluZyBhcmJpdHJhdGlvbiBjb250cm9sXG4iKSk7CisKKwlpZiAo
IXN0cmNtcChhY3BpX2RldmljZV9oaWQoZGV2aWNlKSwgQUNQSV9QUk9DRVNTT1JfT0JKRUNUX0hJ
RCkpIHsKKwkJLyogRGVjbGFyZWQgd2l0aCAiUHJvY2Vzc29yIiBzdGF0ZW1lbnQ7IG1hdGNoIFBy
b2Nlc3NvcklEICovCisJCXN0YXR1cyA9IGFjcGlfZXZhbHVhdGVfb2JqZWN0KHByLT5oYW5kbGUs
IE5VTEwsIE5VTEwsICZidWZmZXIpOworCQlpZiAoQUNQSV9GQUlMVVJFKHN0YXR1cykpIHsKKwkJ
CXByaW50ayhLRVJOX0VSUiBQUkVGSVggIkV2YWx1YXRpbmcgcHJvY2Vzc29yIG9iamVjdFxuIik7
CisJCQlyZXR1cm4gLUVOT0RFVjsKKwkJfQorCisJCS8qCisJCSAqIFRCRDogU3luY2ggcHJvY2Vz
c29yIElEICh2aWEgTEFQSUMvTFNBUElDIHN0cnVjdHVyZXMpIG9uIFNNUC4KKwkJICogICAgICA+
Pj4gJ2FjcGlfZ2V0X3Byb2Nlc3Nvcl9pZChhY3BpX2lkLCAmaWQpJyBpbgorCQkgKiAgICAgIGFy
Y2gveHh4L2FjcGkuYworCQkgKi8KKwkJcHItPmFjcGlfaWQgPSBvYmplY3QucHJvY2Vzc29yLnBy
b2NfaWQ7CisJfSBlbHNlIHsKKwkJLyoKKwkJICogRGVjbGFyZWQgd2l0aCAiRGV2aWNlIiBzdGF0
ZW1lbnQ7IG1hdGNoIF9VSUQuCisJCSAqIE5vdGUgdGhhdCB3ZSBkb24ndCBoYW5kbGUgc3RyaW5n
IF9VSURzIHlldC4KKwkJICovCisJCXVuc2lnbmVkIGxvbmcgbG9uZyB2YWx1ZTsKKwkJc3RhdHVz
ID0gYWNwaV9ldmFsdWF0ZV9pbnRlZ2VyKHByLT5oYW5kbGUsIE1FVEhPRF9OQU1FX19VSUQsCisJ
CQkJCQlOVUxMLCAmdmFsdWUpOworCQlpZiAoQUNQSV9GQUlMVVJFKHN0YXR1cykpIHsKKwkJCXBy
aW50ayhLRVJOX0VSUiBQUkVGSVgKKwkJCSAgICAiRXZhbHVhdGluZyBwcm9jZXNzb3IgX1VJRCBb
JSN4XVxuIiwgc3RhdHVzKTsKKwkJCXJldHVybiAtRU5PREVWOworCQl9CisJCWRldmljZV9kZWNs
YXJhdGlvbiA9IDE7CisJCXByLT5hY3BpX2lkID0gdmFsdWU7CisJfQorCisJY3B1X2luZGV4ID0g
eGVuX3BjcHVfaW5kZXgocHItPmFjcGlfaWQsIDEpOworCisJLyogSGFuZGxlIFVQIHN5c3RlbSBy
dW5uaW5nIFNNUCBrZXJuZWwsIHdpdGggbm8gTEFQSUMgaW4gTUFEVCAqLworCWlmICghY3B1MF9p
bml0aWFsaXplZCAmJiAoY3B1X2luZGV4ID09IC0xKSAmJgorCSAgICAobnVtX29ubGluZV9jcHVz
KCkgPT0gMSkpIHsKKwkJY3B1X2luZGV4ID0gMDsKKwl9CisKKwljcHUwX2luaXRpYWxpemVkID0g
MTsKKworCXByLT5pZCA9IGNwdV9pbmRleDsKKworCS8qCisJICogIEV4dHJhIFByb2Nlc3NvciBv
YmplY3RzIG1heSBiZSBlbnVtZXJhdGVkIG9uIE1QIHN5c3RlbXMgd2l0aAorCSAqICBsZXNzIHRo
YW4gdGhlIG1heCAjIG9mIENQVXMuIFRoZXkgc2hvdWxkIGJlIGlnbm9yZWQgX2lmZgorCSAqICB0
aGV5IGFyZSBwaHlzaWNhbGx5IG5vdCBwcmVzZW50LgorCSAqLworCWlmIChwci0+aWQgPT0gLTEp
IHsKKwkJaWYgKEFDUElfRkFJTFVSRQorCQkgICAgKHhlbl9hY3BpX3Byb2Nlc3Nvcl9ob3RhZGRf
aW5pdChwciwgJnByLT5pZCkpKSB7CisJCQlyZXR1cm4gLUVOT0RFVjsKKwkJfQorCX0KKwkvKgor
CSAqIE9uIHNvbWUgYm94ZXMgc2V2ZXJhbCBwcm9jZXNzb3JzIHVzZSB0aGUgc2FtZSBwcm9jZXNz
b3IgYnVzIGlkLgorCSAqIEJ1dCB0aGV5IGFyZSBsb2NhdGVkIGluIGRpZmZlcmVudCBzY29wZS4g
Rm9yIGV4YW1wbGU6CisJICogXF9TQi5TQ0swLkNQVTAKKwkgKiBcX1NCLlNDSzEuQ1BVMAorCSAq
IFJlbmFtZSB0aGUgcHJvY2Vzc29yIGRldmljZSBidXMgaWQuIEFuZCB0aGUgbmV3IGJ1cyBpZCB3
aWxsIGJlCisJICogZ2VuZXJhdGVkIGFzIHRoZSBmb2xsb3dpbmcgZm9ybWF0OgorCSAqIENQVStD
UFUgSUQuCisJICovCisJc3ByaW50ZihhY3BpX2RldmljZV9iaWQoZGV2aWNlKSwgIkNQVSVYIiwg
cHItPmlkKTsKKwlBQ1BJX0RFQlVHX1BSSU5UKChBQ1BJX0RCX0lORk8sICJQcm9jZXNzb3IgWyVk
OiVkXVxuIiwgcHItPmlkLAorCQkJICBwci0+YWNwaV9pZCkpOworCisJaWYgKCFvYmplY3QucHJv
Y2Vzc29yLnBibGtfYWRkcmVzcykKKwkJQUNQSV9ERUJVR19QUklOVCgoQUNQSV9EQl9JTkZPLCAi
Tm8gUEJMSyAoTlVMTCBhZGRyZXNzKVxuIikpOworCWVsc2UgaWYgKG9iamVjdC5wcm9jZXNzb3Iu
cGJsa19sZW5ndGggIT0gNikKKwkJcHJpbnRrKEtFUk5fRVJSIFBSRUZJWCAiSW52YWxpZCBQQkxL
IGxlbmd0aCBbJWRdXG4iLAorCQkJICAgIG9iamVjdC5wcm9jZXNzb3IucGJsa19sZW5ndGgpOwor
CWVsc2UgeworCQlwci0+dGhyb3R0bGluZy5hZGRyZXNzID0gb2JqZWN0LnByb2Nlc3Nvci5wYmxr
X2FkZHJlc3M7CisJCXByLT50aHJvdHRsaW5nLmR1dHlfb2Zmc2V0ID0gYWNwaV9nYmxfRkFEVC5k
dXR5X29mZnNldDsKKwkJcHItPnRocm90dGxpbmcuZHV0eV93aWR0aCA9IGFjcGlfZ2JsX0ZBRFQu
ZHV0eV93aWR0aDsKKworCQlwci0+cGJsayA9IG9iamVjdC5wcm9jZXNzb3IucGJsa19hZGRyZXNz
OworCisJCS8qCisJCSAqIFdlIGRvbid0IGNhcmUgYWJvdXQgZXJyb3IgcmV0dXJucyAtIHdlIGp1
c3QgdHJ5IHRvIG1hcmsKKwkJICogdGhlc2UgcmVzZXJ2ZWQgc28gdGhhdCBub2JvZHkgZWxzZSBp
cyBjb25mdXNlZCBpbnRvIHRoaW5raW5nCisJCSAqIHRoYXQgdGhpcyByZWdpb24gbWlnaHQgYmUg
dW51c2VkLi4KKwkJICoKKwkJICogKEluIHBhcnRpY3VsYXIsIGFsbG9jYXRpbmcgdGhlIElPIHJh
bmdlIGZvciBDYXJkYnVzKQorCQkgKi8KKwkJcmVxdWVzdF9yZWdpb24ocHItPnRocm90dGxpbmcu
YWRkcmVzcywgNiwgIkFDUEkgQ1BVIHRocm90dGxlIik7CisJfQorCisJLyoKKwkgKiBJZiBBQ1BJ
IGRlc2NyaWJlcyBhIHNsb3QgbnVtYmVyIGZvciB0aGlzIENQVSwgd2UgY2FuIHVzZSBpdAorCSAq
IGVuc3VyZSB3ZSBnZXQgdGhlIHJpZ2h0IHZhbHVlIGluIHRoZSAicGh5c2ljYWwgaWQiIGZpZWxk
CisJICogb2YgL3Byb2MvY3B1aW5mbworCSAqLworCXN0YXR1cyA9IGFjcGlfZXZhbHVhdGVfb2Jq
ZWN0KHByLT5oYW5kbGUsICJfU1VOIiwgTlVMTCwgJmJ1ZmZlcik7CisJaWYgKEFDUElfU1VDQ0VT
UyhzdGF0dXMpKQorCQlhcmNoX2ZpeF9waHlzX3BhY2thZ2VfaWQocHItPmlkLCBvYmplY3QuaW50
ZWdlci52YWx1ZSk7CisKKwlyZXR1cm4gMDsKK30KKworc3RhdGljIGludCBfX2NwdWluaXQgX194
ZW5fYWNwaV9wcm9jZXNzb3JfYWRkKHN0cnVjdCBhY3BpX2RldmljZSAqZGV2aWNlKQoreworCXN0
cnVjdCBhY3BpX3Byb2Nlc3NvciAqcHIgPSBOVUxMOworCWludCByZXN1bHQgPSAwOworCXN0cnVj
dCBzeXNfZGV2aWNlICpzeXNkZXY7CisKKwlwciA9IGt6YWxsb2Moc2l6ZW9mKHN0cnVjdCBhY3Bp
X3Byb2Nlc3NvciksIEdGUF9LRVJORUwpOworCWlmICghcHIpCisJCXJldHVybiAtRU5PTUVNOwor
CisJaWYgKCF6YWxsb2NfY3B1bWFza192YXIoJnByLT50aHJvdHRsaW5nLnNoYXJlZF9jcHVfbWFw
LCBHRlBfS0VSTkVMKSkgeworCQlrZnJlZShwcik7CisJCXJldHVybiAtRU5PTUVNOworCX0KKwor
CXByLT5oYW5kbGUgPSBkZXZpY2UtPmhhbmRsZTsKKwlzdHJjcHkoYWNwaV9kZXZpY2VfbmFtZShk
ZXZpY2UpLCBBQ1BJX1BST0NFU1NPUl9ERVZJQ0VfTkFNRSk7CisJc3RyY3B5KGFjcGlfZGV2aWNl
X2NsYXNzKGRldmljZSksIEFDUElfUFJPQ0VTU09SX0NMQVNTKTsKKwlkZXZpY2UtPmRyaXZlcl9k
YXRhID0gcHI7CisKKwlyZXN1bHQgPSB4ZW5fYWNwaV9wcm9jZXNzb3JfZ2V0X2luZm8oZGV2aWNl
KTsKKwlpZiAocmVzdWx0KSB7CisJCS8qIFByb2Nlc3NvciBpcyBwaHlzaWNhbGx5IG5vdCBwcmVz
ZW50ICovCisJCXJldHVybiAwOworCX0KKworI2lmZGVmIENPTkZJR19TTVAKKwlpZiAocHItPmlk
ID49IHNldHVwX21heF9jcHVzICYmIHByLT5pZCAhPSAwKQorCQlyZXR1cm4gMDsKKyNlbmRpZgor
CisJQlVHX09OKChwci0+aWQgPj0gbnJfY3B1X2lkcykgfHwgKHByLT5pZCA8IDApKTsKKworCS8q
CisJICogQnVnZ3kgQklPUyBjaGVjaworCSAqIEFDUEkgaWQgb2YgcHJvY2Vzc29ycyBjYW4gYmUg
cmVwb3J0ZWQgd3JvbmdseSBieSB0aGUgQklPUy4KKwkgKiBEb24ndCB0cnVzdCBpdCBibGluZGx5
CisJICovCisJaWYgKHBlcl9jcHUocHJvY2Vzc29yX2RldmljZV9hcnJheSwgcHItPmlkKSAhPSBO
VUxMICYmCisJICAgIHBlcl9jcHUocHJvY2Vzc29yX2RldmljZV9hcnJheSwgcHItPmlkKSAhPSBk
ZXZpY2UpIHsKKwkJcHJpbnRrKEtFUk5fV0FSTklORyAiQklPUyByZXBvcnRlZCB3cm9uZyBBQ1BJ
IGlkICIKKwkJCSJmb3IgdGhlIHByb2Nlc3NvclxuIik7CisJCXJlc3VsdCA9IC1FTk9ERVY7CisJ
CWdvdG8gZXJyX2ZyZWVfY3B1bWFzazsKKwl9CisJcGVyX2NwdShwcm9jZXNzb3JfZGV2aWNlX2Fy
cmF5LCBwci0+aWQpID0gZGV2aWNlOworCisJcGVyX2NwdShwcm9jZXNzb3JzLCBwci0+aWQpID0g
cHI7CisKKwlzeXNkZXYgPSBnZXRfY3B1X3N5c2Rldihwci0+aWQpOworCWlmIChzeXNmc19jcmVh
dGVfbGluaygmZGV2aWNlLT5kZXYua29iaiwgJnN5c2Rldi0+a29iaiwgInN5c2RldiIpKSB7CisJ
CXJlc3VsdCA9IC1FRkFVTFQ7CisJCWdvdG8gZXJyX2ZyZWVfY3B1bWFzazsKKwl9CisKKyNpZmRl
ZiBDT05GSUdfQ1BVX0ZSRVEKKwlhY3BpX3Byb2Nlc3Nvcl9wcGNfaGFzX2NoYW5nZWQocHIsIDAp
OworI2VuZGlmCisJYWNwaV9wcm9jZXNzb3JfZ2V0X3Rocm90dGxpbmdfaW5mbyhwcik7CisJYWNw
aV9wcm9jZXNzb3JfZ2V0X2xpbWl0X2luZm8ocHIpOworCisKKwlpZiAoY3B1aWRsZV9nZXRfZHJp
dmVyKCkgPT0gJmFjcGlfaWRsZV9kcml2ZXIpCisJCWFjcGlfcHJvY2Vzc29yX3Bvd2VyX2luaXQo
cHIsIGRldmljZSk7CisKKwlwci0+Y2RldiA9IHRoZXJtYWxfY29vbGluZ19kZXZpY2VfcmVnaXN0
ZXIoIlByb2Nlc3NvciIsIGRldmljZSwKKwkJCQkJCSZwcm9jZXNzb3JfY29vbGluZ19vcHMpOwor
CWlmIChJU19FUlIocHItPmNkZXYpKSB7CisJCXJlc3VsdCA9IFBUUl9FUlIocHItPmNkZXYpOwor
CQlnb3RvIGVycl9wb3dlcl9leGl0OworCX0KKworCWRldl9kYmcoJmRldmljZS0+ZGV2LCAicmVn
aXN0ZXJlZCBhcyBjb29saW5nX2RldmljZSVkXG4iLAorCQkgcHItPmNkZXYtPmlkKTsKKworCXJl
c3VsdCA9IHN5c2ZzX2NyZWF0ZV9saW5rKCZkZXZpY2UtPmRldi5rb2JqLAorCQkJCSAgICZwci0+
Y2Rldi0+ZGV2aWNlLmtvYmosCisJCQkJICAgInRoZXJtYWxfY29vbGluZyIpOworCWlmIChyZXN1
bHQpIHsKKwkJcHJpbnRrKEtFUk5fRVJSIFBSRUZJWCAiQ3JlYXRlIHN5c2ZzIGxpbmtcbiIpOwor
CQlnb3RvIGVycl90aGVybWFsX3VucmVnaXN0ZXI7CisJfQorCXJlc3VsdCA9IHN5c2ZzX2NyZWF0
ZV9saW5rKCZwci0+Y2Rldi0+ZGV2aWNlLmtvYmosCisJCQkJICAgJmRldmljZS0+ZGV2LmtvYmos
CisJCQkJICAgImRldmljZSIpOworCWlmIChyZXN1bHQpIHsKKwkJcHJpbnRrKEtFUk5fRVJSIFBS
RUZJWCAiQ3JlYXRlIHN5c2ZzIGxpbmtcbiIpOworCQlnb3RvIGVycl9yZW1vdmVfc3lzZnM7CisJ
fQorCisJcmV0dXJuIDA7CisKK2Vycl9yZW1vdmVfc3lzZnM6CisJc3lzZnNfcmVtb3ZlX2xpbmso
JmRldmljZS0+ZGV2LmtvYmosICJ0aGVybWFsX2Nvb2xpbmciKTsKK2Vycl90aGVybWFsX3VucmVn
aXN0ZXI6CisJdGhlcm1hbF9jb29saW5nX2RldmljZV91bnJlZ2lzdGVyKHByLT5jZGV2KTsKK2Vy
cl9wb3dlcl9leGl0OgorCWFjcGlfcHJvY2Vzc29yX3Bvd2VyX2V4aXQocHIsIGRldmljZSk7Citl
cnJfZnJlZV9jcHVtYXNrOgorCWZyZWVfY3B1bWFza192YXIocHItPnRocm90dGxpbmcuc2hhcmVk
X2NwdV9tYXApOworCisJcmV0dXJuIHJlc3VsdDsKK30KKwogc3RhdGljIGludCBfX2NwdWluaXQg
eGVuX2FjcGlfcHJvY2Vzc29yX2FkZChzdHJ1Y3QgYWNwaV9kZXZpY2UgKmRldmljZSkKIHsKIAlz
dHJ1Y3QgYWNwaV9wcm9jZXNzb3IgKnByID0gTlVMTDsKIAlpbnQgcmVzdWx0ID0gMDsKIAotCXJl
c3VsdCA9IGFjcGlfcHJvY2Vzc29yX2FkZChkZXZpY2UpOwotCWlmIChyZXN1bHQgPCAwKQorCXJl
c3VsdCA9IF9feGVuX2FjcGlfcHJvY2Vzc29yX2FkZChkZXZpY2UpOworCWlmIChyZXN1bHQpCiAJ
CXJldHVybiByZXN1bHQ7CiAKIAlwciA9IGFjcGlfZHJpdmVyX2RhdGEoZGV2aWNlKTsKZGlmZiAt
LWdpdCBhL2luY2x1ZGUvYWNwaS9wcm9jZXNzb3IuaCBiL2luY2x1ZGUvYWNwaS9wcm9jZXNzb3Iu
aAppbmRleCBjNDhlMmY5Li4zYTFlZTAxIDEwMDY0NAotLS0gYS9pbmNsdWRlL2FjcGkvcHJvY2Vz
c29yLmgKKysrIGIvaW5jbHVkZS9hY3BpL3Byb2Nlc3Nvci5oCkBAIC0yMjUsNiArMjI1LDggQEAg
c3RydWN0IGFjcGlfcHJvY2Vzc29yX2VycmF0YSB7CiAJfSBwaWl4NDsKIH07CiAKK2V4dGVybiBp
bnQgYWNwaV9wcm9jZXNzb3JfZXJyYXRhKHN0cnVjdCBhY3BpX3Byb2Nlc3NvciAqcHIpOworCiBl
eHRlcm4gaW50IGFjcGlfcHJvY2Vzc29yX3ByZXJlZ2lzdGVyX3BlcmZvcm1hbmNlKHN0cnVjdAog
CQkJCQkJICBhY3BpX3Byb2Nlc3Nvcl9wZXJmb3JtYW5jZQogCQkJCQkJICBfX3BlcmNwdSAqcGVy
Zm9ybWFuY2UpOwpkaWZmIC0tZ2l0IGEvaW5jbHVkZS94ZW4vcGNwdS5oIGIvaW5jbHVkZS94ZW4v
cGNwdS5oCmluZGV4IDdlOGY5ZDEuLjNlOTlkYjkgMTAwNjQ0Ci0tLSBhL2luY2x1ZGUveGVuL3Bj
cHUuaAorKysgYi9pbmNsdWRlL3hlbi9wY3B1LmgKQEAgLTQsNiArNCw4IEBACiAjaW5jbHVkZSA8
eGVuL2ludGVyZmFjZS9wbGF0Zm9ybS5oPgogI2luY2x1ZGUgPGxpbnV4L3N5c2Rldi5oPgogCitl
eHRlcm4gREVGSU5FX1BFUl9DUFUodm9pZCAqLCBwcm9jZXNzb3JfZGV2aWNlX2FycmF5KTsKKwog
ZXh0ZXJuIGludCB4ZW5fcGNwdV9ob3RwbHVnKGludCB0eXBlLCB1aW50MzJfdCBhcGljX2lkKTsK
ICNkZWZpbmUgWEVOX1BDUFVfT05MSU5FICAgICAweDAxCiAjZGVmaW5lIFhFTl9QQ1BVX09GRkxJ
TkUgICAgMHgwMgotLSAKMS42LjUuNgoK

--_002_DE8DF0795D48FD4CA783C40EC82923358A81SHSMSX101ccrcorpint_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--_002_DE8DF0795D48FD4CA783C40EC82923358A81SHSMSX101ccrcorpint_--


From xen-devel-bounces@lists.xensource.com Thu Dec 22 10:08:56 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 Dec 2011 10: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.xensource.com>)
	id 1RdfZy-0005f1-1F; Thu, 22 Dec 2011 10:08:50 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1RdfZv-0005cc-RP
	for xen-devel@lists.xensource.com; Thu, 22 Dec 2011 10:08:48 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1324548518!8272694!1
X-Originating-IP: [143.182.124.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjE0OTQw\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14354 invoked from network); 22 Dec 2011 10:08:39 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-16.tower-216.messagelabs.com with SMTP;
	22 Dec 2011 10:08:39 -0000
Received: from azsmga002.ch.intel.com ([10.2.17.35])
	by azsmga101.ch.intel.com with ESMTP; 22 Dec 2011 02:08:38 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208,223";a="49701112"
Received: from pgsmsx603.gar.corp.intel.com ([10.221.43.87])
	by AZSMGA002.ch.intel.com with ESMTP; 22 Dec 2011 02:08:36 -0800
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	pgsmsx603.gar.corp.intel.com (10.221.43.87) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Thu, 22 Dec 2011 18:08:36 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.38]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.199]) with mapi id
	14.01.0355.002; Thu, 22 Dec 2011 18:08:34 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: "konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Thread-Topic: [PATCH 08/10] xen/acpi: add cpu hotadd support
Thread-Index: AczAkamqESM6qFDcSReYX5rCIgGotA==
Date: Thu, 22 Dec 2011 10:08:34 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC82923358A81@SHSMSX101.ccr.corp.intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
Content-Type: multipart/mixed;
	boundary="_002_DE8DF0795D48FD4CA783C40EC82923358A81SHSMSX101ccrcorpint_"
MIME-Version: 1.0
Cc: "Jiang, Yunhong" <yunhong.jiang@intel.com>,
	"jeremy.fitzhardinge@citrix.com" <jeremy.fitzhardinge@citrix.com>
Subject: [Xen-devel] [PATCH 08/10] xen/acpi: add cpu hotadd support
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--_002_DE8DF0795D48FD4CA783C40EC82923358A81SHSMSX101ccrcorpint_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

>From 282958be3a33b2f2b888e1ed3ac022bf8a199ec9 Mon Sep 17 00:00:00 2001
From: Liu Jinsong <jinsong.liu@intel.com>
Date: Wed, 14 Dec 2011 11:38:11 +0800
Subject: [PATCH 08/10] xen/acpi: add cpu hotadd support

This patch add cpu hotadd support.
It keep similar cpu hotadd logic as native, w/ some changes according
to xen requirement, hypercalling hypervisor related logic to hotadd cpu.

Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
Signed-off-by: Jiang, Yunhong <yunhong.jiang@intel.com>
---
 drivers/acpi/processor_driver.c |    4 +-
 drivers/acpi/processor_xen.c    |  242 +++++++++++++++++++++++++++++++++++=
+++-
 include/acpi/processor.h        |    2 +
 include/xen/pcpu.h              |    2 +
 4 files changed, 246 insertions(+), 4 deletions(-)

diff --git a/drivers/acpi/processor_driver.c b/drivers/acpi/processor_drive=
r.c
index 8a367d7..d473fd5 100644
--- a/drivers/acpi/processor_driver.c
+++ b/drivers/acpi/processor_driver.c
@@ -221,7 +221,7 @@ static int acpi_processor_errata_piix4(struct pci_dev *=
dev)
 	return 0;
 }
=20
-static int acpi_processor_errata(struct acpi_processor *pr)
+int acpi_processor_errata(struct acpi_processor *pr)
 {
 	int result =3D 0;
 	struct pci_dev *dev =3D NULL;
@@ -378,7 +378,7 @@ static int acpi_processor_get_info(struct acpi_device *=
device)
 	return 0;
 }
=20
-static DEFINE_PER_CPU(void *, processor_device_array);
+DEFINE_PER_CPU(void *, processor_device_array);
=20
 void acpi_processor_notify(struct acpi_device *device, u32 event)
 {
diff --git a/drivers/acpi/processor_xen.c b/drivers/acpi/processor_xen.c
index 38a1c05..3af1f73 100644
--- a/drivers/acpi/processor_xen.c
+++ b/drivers/acpi/processor_xen.c
@@ -24,6 +24,7 @@
 #define PREFIX "ACPI: "
=20
 #define ACPI_PROCESSOR_CLASS            "processor"
+#define ACPI_PROCESSOR_DEVICE_NAME      "Processor"
 #define ACPI_PROCESSOR_NOTIFY_PERFORMANCE 0x80
 #define ACPI_PROCESSOR_NOTIFY_POWER	0x81
 #define ACPI_PROCESSOR_NOTIFY_THROTTLING	0x82
@@ -88,6 +89,8 @@ xen_acpi_processor_hotadd_init(struct acpi_processor *pr,=
 int *p_cpu)
 				PROCESSOR_HOTPLUG, HOTPLUG_TYPE_ADD))
 		return AE_ERROR;
=20
+	*p_cpu =3D xen_pcpu_index(pr->acpi_id, 1);
+
 	return AE_OK;
 }
=20
@@ -149,13 +152,248 @@ err_out:
 }
 #endif /* CONFIG_CPU_FREQ */
=20
+static int xen_acpi_processor_get_info(struct acpi_device *device)
+{
+	acpi_status status =3D 0;
+	union acpi_object object =3D { 0 };
+	struct acpi_buffer buffer =3D { sizeof(union acpi_object), &object };
+	struct acpi_processor *pr;
+	int cpu_index, device_declaration =3D 0;
+	static int cpu0_initialized;
+
+	pr =3D acpi_driver_data(device);
+	if (!pr)
+		return -EINVAL;
+
+	if (num_online_cpus() > 1)
+		errata.smp =3D TRUE;
+
+	acpi_processor_errata(pr);
+
+	/*
+	 * Check to see if we have bus mastering arbitration control.  This
+	 * is required for proper C3 usage (to maintain cache coherency).
+	 */
+	if (acpi_gbl_FADT.pm2_control_block && acpi_gbl_FADT.pm2_control_length) =
{
+		pr->flags.bm_control =3D 1;
+		ACPI_DEBUG_PRINT((ACPI_DB_INFO,
+				  "Bus mastering arbitration control present\n"));
+	} else
+		ACPI_DEBUG_PRINT((ACPI_DB_INFO,
+				  "No bus mastering arbitration control\n"));
+
+	if (!strcmp(acpi_device_hid(device), ACPI_PROCESSOR_OBJECT_HID)) {
+		/* Declared with "Processor" statement; match ProcessorID */
+		status =3D acpi_evaluate_object(pr->handle, NULL, NULL, &buffer);
+		if (ACPI_FAILURE(status)) {
+			printk(KERN_ERR PREFIX "Evaluating processor object\n");
+			return -ENODEV;
+		}
+
+		/*
+		 * TBD: Synch processor ID (via LAPIC/LSAPIC structures) on SMP.
+		 *      >>> 'acpi_get_processor_id(acpi_id, &id)' in
+		 *      arch/xxx/acpi.c
+		 */
+		pr->acpi_id =3D object.processor.proc_id;
+	} else {
+		/*
+		 * Declared with "Device" statement; match _UID.
+		 * Note that we don't handle string _UIDs yet.
+		 */
+		unsigned long long value;
+		status =3D acpi_evaluate_integer(pr->handle, METHOD_NAME__UID,
+						NULL, &value);
+		if (ACPI_FAILURE(status)) {
+			printk(KERN_ERR PREFIX
+			    "Evaluating processor _UID [%#x]\n", status);
+			return -ENODEV;
+		}
+		device_declaration =3D 1;
+		pr->acpi_id =3D value;
+	}
+
+	cpu_index =3D xen_pcpu_index(pr->acpi_id, 1);
+
+	/* Handle UP system running SMP kernel, with no LAPIC in MADT */
+	if (!cpu0_initialized && (cpu_index =3D=3D -1) &&
+	    (num_online_cpus() =3D=3D 1)) {
+		cpu_index =3D 0;
+	}
+
+	cpu0_initialized =3D 1;
+
+	pr->id =3D cpu_index;
+
+	/*
+	 *  Extra Processor objects may be enumerated on MP systems with
+	 *  less than the max # of CPUs. They should be ignored _iff
+	 *  they are physically not present.
+	 */
+	if (pr->id =3D=3D -1) {
+		if (ACPI_FAILURE
+		    (xen_acpi_processor_hotadd_init(pr, &pr->id))) {
+			return -ENODEV;
+		}
+	}
+	/*
+	 * On some boxes several processors use the same processor bus id.
+	 * But they are located in different scope. For example:
+	 * \_SB.SCK0.CPU0
+	 * \_SB.SCK1.CPU0
+	 * Rename the processor device bus id. And the new bus id will be
+	 * generated as the following format:
+	 * CPU+CPU ID.
+	 */
+	sprintf(acpi_device_bid(device), "CPU%X", pr->id);
+	ACPI_DEBUG_PRINT((ACPI_DB_INFO, "Processor [%d:%d]\n", pr->id,
+			  pr->acpi_id));
+
+	if (!object.processor.pblk_address)
+		ACPI_DEBUG_PRINT((ACPI_DB_INFO, "No PBLK (NULL address)\n"));
+	else if (object.processor.pblk_length !=3D 6)
+		printk(KERN_ERR PREFIX "Invalid PBLK length [%d]\n",
+			    object.processor.pblk_length);
+	else {
+		pr->throttling.address =3D object.processor.pblk_address;
+		pr->throttling.duty_offset =3D acpi_gbl_FADT.duty_offset;
+		pr->throttling.duty_width =3D acpi_gbl_FADT.duty_width;
+
+		pr->pblk =3D object.processor.pblk_address;
+
+		/*
+		 * We don't care about error returns - we just try to mark
+		 * these reserved so that nobody else is confused into thinking
+		 * that this region might be unused..
+		 *
+		 * (In particular, allocating the IO range for Cardbus)
+		 */
+		request_region(pr->throttling.address, 6, "ACPI CPU throttle");
+	}
+
+	/*
+	 * If ACPI describes a slot number for this CPU, we can use it
+	 * ensure we get the right value in the "physical id" field
+	 * of /proc/cpuinfo
+	 */
+	status =3D acpi_evaluate_object(pr->handle, "_SUN", NULL, &buffer);
+	if (ACPI_SUCCESS(status))
+		arch_fix_phys_package_id(pr->id, object.integer.value);
+
+	return 0;
+}
+
+static int __cpuinit __xen_acpi_processor_add(struct acpi_device *device)
+{
+	struct acpi_processor *pr =3D NULL;
+	int result =3D 0;
+	struct sys_device *sysdev;
+
+	pr =3D kzalloc(sizeof(struct acpi_processor), GFP_KERNEL);
+	if (!pr)
+		return -ENOMEM;
+
+	if (!zalloc_cpumask_var(&pr->throttling.shared_cpu_map, GFP_KERNEL)) {
+		kfree(pr);
+		return -ENOMEM;
+	}
+
+	pr->handle =3D device->handle;
+	strcpy(acpi_device_name(device), ACPI_PROCESSOR_DEVICE_NAME);
+	strcpy(acpi_device_class(device), ACPI_PROCESSOR_CLASS);
+	device->driver_data =3D pr;
+
+	result =3D xen_acpi_processor_get_info(device);
+	if (result) {
+		/* Processor is physically not present */
+		return 0;
+	}
+
+#ifdef CONFIG_SMP
+	if (pr->id >=3D setup_max_cpus && pr->id !=3D 0)
+		return 0;
+#endif
+
+	BUG_ON((pr->id >=3D nr_cpu_ids) || (pr->id < 0));
+
+	/*
+	 * Buggy BIOS check
+	 * ACPI id of processors can be reported wrongly by the BIOS.
+	 * Don't trust it blindly
+	 */
+	if (per_cpu(processor_device_array, pr->id) !=3D NULL &&
+	    per_cpu(processor_device_array, pr->id) !=3D device) {
+		printk(KERN_WARNING "BIOS reported wrong ACPI id "
+			"for the processor\n");
+		result =3D -ENODEV;
+		goto err_free_cpumask;
+	}
+	per_cpu(processor_device_array, pr->id) =3D device;
+
+	per_cpu(processors, pr->id) =3D pr;
+
+	sysdev =3D get_cpu_sysdev(pr->id);
+	if (sysfs_create_link(&device->dev.kobj, &sysdev->kobj, "sysdev")) {
+		result =3D -EFAULT;
+		goto err_free_cpumask;
+	}
+
+#ifdef CONFIG_CPU_FREQ
+	acpi_processor_ppc_has_changed(pr, 0);
+#endif
+	acpi_processor_get_throttling_info(pr);
+	acpi_processor_get_limit_info(pr);
+
+
+	if (cpuidle_get_driver() =3D=3D &acpi_idle_driver)
+		acpi_processor_power_init(pr, device);
+
+	pr->cdev =3D thermal_cooling_device_register("Processor", device,
+						&processor_cooling_ops);
+	if (IS_ERR(pr->cdev)) {
+		result =3D PTR_ERR(pr->cdev);
+		goto err_power_exit;
+	}
+
+	dev_dbg(&device->dev, "registered as cooling_device%d\n",
+		 pr->cdev->id);
+
+	result =3D sysfs_create_link(&device->dev.kobj,
+				   &pr->cdev->device.kobj,
+				   "thermal_cooling");
+	if (result) {
+		printk(KERN_ERR PREFIX "Create sysfs link\n");
+		goto err_thermal_unregister;
+	}
+	result =3D sysfs_create_link(&pr->cdev->device.kobj,
+				   &device->dev.kobj,
+				   "device");
+	if (result) {
+		printk(KERN_ERR PREFIX "Create sysfs link\n");
+		goto err_remove_sysfs;
+	}
+
+	return 0;
+
+err_remove_sysfs:
+	sysfs_remove_link(&device->dev.kobj, "thermal_cooling");
+err_thermal_unregister:
+	thermal_cooling_device_unregister(pr->cdev);
+err_power_exit:
+	acpi_processor_power_exit(pr, device);
+err_free_cpumask:
+	free_cpumask_var(pr->throttling.shared_cpu_map);
+
+	return result;
+}
+
 static int __cpuinit xen_acpi_processor_add(struct acpi_device *device)
 {
 	struct acpi_processor *pr =3D NULL;
 	int result =3D 0;
=20
-	result =3D acpi_processor_add(device);
-	if (result < 0)
+	result =3D __xen_acpi_processor_add(device);
+	if (result)
 		return result;
=20
 	pr =3D acpi_driver_data(device);
diff --git a/include/acpi/processor.h b/include/acpi/processor.h
index c48e2f9..3a1ee01 100644
--- a/include/acpi/processor.h
+++ b/include/acpi/processor.h
@@ -225,6 +225,8 @@ struct acpi_processor_errata {
 	} piix4;
 };
=20
+extern int acpi_processor_errata(struct acpi_processor *pr);
+
 extern int acpi_processor_preregister_performance(struct
 						  acpi_processor_performance
 						  __percpu *performance);
diff --git a/include/xen/pcpu.h b/include/xen/pcpu.h
index 7e8f9d1..3e99db9 100644
--- a/include/xen/pcpu.h
+++ b/include/xen/pcpu.h
@@ -4,6 +4,8 @@
 #include <xen/interface/platform.h>
 #include <linux/sysdev.h>
=20
+extern DEFINE_PER_CPU(void *, processor_device_array);
+
 extern int xen_pcpu_hotplug(int type, uint32_t apic_id);
 #define XEN_PCPU_ONLINE     0x01
 #define XEN_PCPU_OFFLINE    0x02
--=20
1.6.5.6

--_002_DE8DF0795D48FD4CA783C40EC82923358A81SHSMSX101ccrcorpint_
Content-Type: application/octet-stream;
	name="0008-xen-acpi-add-cpu-hotadd-support.patch"
Content-Description: 0008-xen-acpi-add-cpu-hotadd-support.patch
Content-Disposition: attachment;
	filename="0008-xen-acpi-add-cpu-hotadd-support.patch"; size=10056;
	creation-date="Wed, 14 Dec 2011 15:20:15 GMT";
	modification-date="Wed, 14 Dec 2011 15:03:34 GMT"
Content-Transfer-Encoding: base64

RnJvbSAyODI5NThiZTNhMzNiMmYyYjg4OGUxZWQzYWMwMjJiZjhhMTk5ZWM5IE1vbiBTZXAgMTcg
MDA6MDA6MDAgMjAwMQpGcm9tOiBMaXUgSmluc29uZyA8amluc29uZy5saXVAaW50ZWwuY29tPgpE
YXRlOiBXZWQsIDE0IERlYyAyMDExIDExOjM4OjExICswODAwClN1YmplY3Q6IFtQQVRDSCAwOC8x
MF0geGVuL2FjcGk6IGFkZCBjcHUgaG90YWRkIHN1cHBvcnQKClRoaXMgcGF0Y2ggYWRkIGNwdSBo
b3RhZGQgc3VwcG9ydC4KSXQga2VlcCBzaW1pbGFyIGNwdSBob3RhZGQgbG9naWMgYXMgbmF0aXZl
LCB3LyBzb21lIGNoYW5nZXMgYWNjb3JkaW5nCnRvIHhlbiByZXF1aXJlbWVudCwgaHlwZXJjYWxs
aW5nIGh5cGVydmlzb3IgcmVsYXRlZCBsb2dpYyB0byBob3RhZGQgY3B1LgoKU2lnbmVkLW9mZi1i
eTogTGl1LCBKaW5zb25nIDxqaW5zb25nLmxpdUBpbnRlbC5jb20+ClNpZ25lZC1vZmYtYnk6IEpp
YW5nLCBZdW5ob25nIDx5dW5ob25nLmppYW5nQGludGVsLmNvbT4KLS0tCiBkcml2ZXJzL2FjcGkv
cHJvY2Vzc29yX2RyaXZlci5jIHwgICAgNCArLQogZHJpdmVycy9hY3BpL3Byb2Nlc3Nvcl94ZW4u
YyAgICB8ICAyNDIgKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKystCiBpbmNs
dWRlL2FjcGkvcHJvY2Vzc29yLmggICAgICAgIHwgICAgMiArCiBpbmNsdWRlL3hlbi9wY3B1Lmgg
ICAgICAgICAgICAgIHwgICAgMiArCiA0IGZpbGVzIGNoYW5nZWQsIDI0NiBpbnNlcnRpb25zKCsp
LCA0IGRlbGV0aW9ucygtKQoKZGlmZiAtLWdpdCBhL2RyaXZlcnMvYWNwaS9wcm9jZXNzb3JfZHJp
dmVyLmMgYi9kcml2ZXJzL2FjcGkvcHJvY2Vzc29yX2RyaXZlci5jCmluZGV4IDhhMzY3ZDcuLmQ0
NzNmZDUgMTAwNjQ0Ci0tLSBhL2RyaXZlcnMvYWNwaS9wcm9jZXNzb3JfZHJpdmVyLmMKKysrIGIv
ZHJpdmVycy9hY3BpL3Byb2Nlc3Nvcl9kcml2ZXIuYwpAQCAtMjIxLDcgKzIyMSw3IEBAIHN0YXRp
YyBpbnQgYWNwaV9wcm9jZXNzb3JfZXJyYXRhX3BpaXg0KHN0cnVjdCBwY2lfZGV2ICpkZXYpCiAJ
cmV0dXJuIDA7CiB9CiAKLXN0YXRpYyBpbnQgYWNwaV9wcm9jZXNzb3JfZXJyYXRhKHN0cnVjdCBh
Y3BpX3Byb2Nlc3NvciAqcHIpCitpbnQgYWNwaV9wcm9jZXNzb3JfZXJyYXRhKHN0cnVjdCBhY3Bp
X3Byb2Nlc3NvciAqcHIpCiB7CiAJaW50IHJlc3VsdCA9IDA7CiAJc3RydWN0IHBjaV9kZXYgKmRl
diA9IE5VTEw7CkBAIC0zNzgsNyArMzc4LDcgQEAgc3RhdGljIGludCBhY3BpX3Byb2Nlc3Nvcl9n
ZXRfaW5mbyhzdHJ1Y3QgYWNwaV9kZXZpY2UgKmRldmljZSkKIAlyZXR1cm4gMDsKIH0KIAotc3Rh
dGljIERFRklORV9QRVJfQ1BVKHZvaWQgKiwgcHJvY2Vzc29yX2RldmljZV9hcnJheSk7CitERUZJ
TkVfUEVSX0NQVSh2b2lkICosIHByb2Nlc3Nvcl9kZXZpY2VfYXJyYXkpOwogCiB2b2lkIGFjcGlf
cHJvY2Vzc29yX25vdGlmeShzdHJ1Y3QgYWNwaV9kZXZpY2UgKmRldmljZSwgdTMyIGV2ZW50KQog
ewpkaWZmIC0tZ2l0IGEvZHJpdmVycy9hY3BpL3Byb2Nlc3Nvcl94ZW4uYyBiL2RyaXZlcnMvYWNw
aS9wcm9jZXNzb3JfeGVuLmMKaW5kZXggMzhhMWMwNS4uM2FmMWY3MyAxMDA2NDQKLS0tIGEvZHJp
dmVycy9hY3BpL3Byb2Nlc3Nvcl94ZW4uYworKysgYi9kcml2ZXJzL2FjcGkvcHJvY2Vzc29yX3hl
bi5jCkBAIC0yNCw2ICsyNCw3IEBACiAjZGVmaW5lIFBSRUZJWCAiQUNQSTogIgogCiAjZGVmaW5l
IEFDUElfUFJPQ0VTU09SX0NMQVNTICAgICAgICAgICAgInByb2Nlc3NvciIKKyNkZWZpbmUgQUNQ
SV9QUk9DRVNTT1JfREVWSUNFX05BTUUgICAgICAiUHJvY2Vzc29yIgogI2RlZmluZSBBQ1BJX1BS
T0NFU1NPUl9OT1RJRllfUEVSRk9STUFOQ0UgMHg4MAogI2RlZmluZSBBQ1BJX1BST0NFU1NPUl9O
T1RJRllfUE9XRVIJMHg4MQogI2RlZmluZSBBQ1BJX1BST0NFU1NPUl9OT1RJRllfVEhST1RUTElO
RwkweDgyCkBAIC04OCw2ICs4OSw4IEBAIHhlbl9hY3BpX3Byb2Nlc3Nvcl9ob3RhZGRfaW5pdChz
dHJ1Y3QgYWNwaV9wcm9jZXNzb3IgKnByLCBpbnQgKnBfY3B1KQogCQkJCVBST0NFU1NPUl9IT1RQ
TFVHLCBIT1RQTFVHX1RZUEVfQUREKSkKIAkJcmV0dXJuIEFFX0VSUk9SOwogCisJKnBfY3B1ID0g
eGVuX3BjcHVfaW5kZXgocHItPmFjcGlfaWQsIDEpOworCiAJcmV0dXJuIEFFX09LOwogfQogCkBA
IC0xNDksMTMgKzE1MiwyNDggQEAgZXJyX291dDoKIH0KICNlbmRpZiAvKiBDT05GSUdfQ1BVX0ZS
RVEgKi8KIAorc3RhdGljIGludCB4ZW5fYWNwaV9wcm9jZXNzb3JfZ2V0X2luZm8oc3RydWN0IGFj
cGlfZGV2aWNlICpkZXZpY2UpCit7CisJYWNwaV9zdGF0dXMgc3RhdHVzID0gMDsKKwl1bmlvbiBh
Y3BpX29iamVjdCBvYmplY3QgPSB7IDAgfTsKKwlzdHJ1Y3QgYWNwaV9idWZmZXIgYnVmZmVyID0g
eyBzaXplb2YodW5pb24gYWNwaV9vYmplY3QpLCAmb2JqZWN0IH07CisJc3RydWN0IGFjcGlfcHJv
Y2Vzc29yICpwcjsKKwlpbnQgY3B1X2luZGV4LCBkZXZpY2VfZGVjbGFyYXRpb24gPSAwOworCXN0
YXRpYyBpbnQgY3B1MF9pbml0aWFsaXplZDsKKworCXByID0gYWNwaV9kcml2ZXJfZGF0YShkZXZp
Y2UpOworCWlmICghcHIpCisJCXJldHVybiAtRUlOVkFMOworCisJaWYgKG51bV9vbmxpbmVfY3B1
cygpID4gMSkKKwkJZXJyYXRhLnNtcCA9IFRSVUU7CisKKwlhY3BpX3Byb2Nlc3Nvcl9lcnJhdGEo
cHIpOworCisJLyoKKwkgKiBDaGVjayB0byBzZWUgaWYgd2UgaGF2ZSBidXMgbWFzdGVyaW5nIGFy
Yml0cmF0aW9uIGNvbnRyb2wuICBUaGlzCisJICogaXMgcmVxdWlyZWQgZm9yIHByb3BlciBDMyB1
c2FnZSAodG8gbWFpbnRhaW4gY2FjaGUgY29oZXJlbmN5KS4KKwkgKi8KKwlpZiAoYWNwaV9nYmxf
RkFEVC5wbTJfY29udHJvbF9ibG9jayAmJiBhY3BpX2dibF9GQURULnBtMl9jb250cm9sX2xlbmd0
aCkgeworCQlwci0+ZmxhZ3MuYm1fY29udHJvbCA9IDE7CisJCUFDUElfREVCVUdfUFJJTlQoKEFD
UElfREJfSU5GTywKKwkJCQkgICJCdXMgbWFzdGVyaW5nIGFyYml0cmF0aW9uIGNvbnRyb2wgcHJl
c2VudFxuIikpOworCX0gZWxzZQorCQlBQ1BJX0RFQlVHX1BSSU5UKChBQ1BJX0RCX0lORk8sCisJ
CQkJICAiTm8gYnVzIG1hc3RlcmluZyBhcmJpdHJhdGlvbiBjb250cm9sXG4iKSk7CisKKwlpZiAo
IXN0cmNtcChhY3BpX2RldmljZV9oaWQoZGV2aWNlKSwgQUNQSV9QUk9DRVNTT1JfT0JKRUNUX0hJ
RCkpIHsKKwkJLyogRGVjbGFyZWQgd2l0aCAiUHJvY2Vzc29yIiBzdGF0ZW1lbnQ7IG1hdGNoIFBy
b2Nlc3NvcklEICovCisJCXN0YXR1cyA9IGFjcGlfZXZhbHVhdGVfb2JqZWN0KHByLT5oYW5kbGUs
IE5VTEwsIE5VTEwsICZidWZmZXIpOworCQlpZiAoQUNQSV9GQUlMVVJFKHN0YXR1cykpIHsKKwkJ
CXByaW50ayhLRVJOX0VSUiBQUkVGSVggIkV2YWx1YXRpbmcgcHJvY2Vzc29yIG9iamVjdFxuIik7
CisJCQlyZXR1cm4gLUVOT0RFVjsKKwkJfQorCisJCS8qCisJCSAqIFRCRDogU3luY2ggcHJvY2Vz
c29yIElEICh2aWEgTEFQSUMvTFNBUElDIHN0cnVjdHVyZXMpIG9uIFNNUC4KKwkJICogICAgICA+
Pj4gJ2FjcGlfZ2V0X3Byb2Nlc3Nvcl9pZChhY3BpX2lkLCAmaWQpJyBpbgorCQkgKiAgICAgIGFy
Y2gveHh4L2FjcGkuYworCQkgKi8KKwkJcHItPmFjcGlfaWQgPSBvYmplY3QucHJvY2Vzc29yLnBy
b2NfaWQ7CisJfSBlbHNlIHsKKwkJLyoKKwkJICogRGVjbGFyZWQgd2l0aCAiRGV2aWNlIiBzdGF0
ZW1lbnQ7IG1hdGNoIF9VSUQuCisJCSAqIE5vdGUgdGhhdCB3ZSBkb24ndCBoYW5kbGUgc3RyaW5n
IF9VSURzIHlldC4KKwkJICovCisJCXVuc2lnbmVkIGxvbmcgbG9uZyB2YWx1ZTsKKwkJc3RhdHVz
ID0gYWNwaV9ldmFsdWF0ZV9pbnRlZ2VyKHByLT5oYW5kbGUsIE1FVEhPRF9OQU1FX19VSUQsCisJ
CQkJCQlOVUxMLCAmdmFsdWUpOworCQlpZiAoQUNQSV9GQUlMVVJFKHN0YXR1cykpIHsKKwkJCXBy
aW50ayhLRVJOX0VSUiBQUkVGSVgKKwkJCSAgICAiRXZhbHVhdGluZyBwcm9jZXNzb3IgX1VJRCBb
JSN4XVxuIiwgc3RhdHVzKTsKKwkJCXJldHVybiAtRU5PREVWOworCQl9CisJCWRldmljZV9kZWNs
YXJhdGlvbiA9IDE7CisJCXByLT5hY3BpX2lkID0gdmFsdWU7CisJfQorCisJY3B1X2luZGV4ID0g
eGVuX3BjcHVfaW5kZXgocHItPmFjcGlfaWQsIDEpOworCisJLyogSGFuZGxlIFVQIHN5c3RlbSBy
dW5uaW5nIFNNUCBrZXJuZWwsIHdpdGggbm8gTEFQSUMgaW4gTUFEVCAqLworCWlmICghY3B1MF9p
bml0aWFsaXplZCAmJiAoY3B1X2luZGV4ID09IC0xKSAmJgorCSAgICAobnVtX29ubGluZV9jcHVz
KCkgPT0gMSkpIHsKKwkJY3B1X2luZGV4ID0gMDsKKwl9CisKKwljcHUwX2luaXRpYWxpemVkID0g
MTsKKworCXByLT5pZCA9IGNwdV9pbmRleDsKKworCS8qCisJICogIEV4dHJhIFByb2Nlc3NvciBv
YmplY3RzIG1heSBiZSBlbnVtZXJhdGVkIG9uIE1QIHN5c3RlbXMgd2l0aAorCSAqICBsZXNzIHRo
YW4gdGhlIG1heCAjIG9mIENQVXMuIFRoZXkgc2hvdWxkIGJlIGlnbm9yZWQgX2lmZgorCSAqICB0
aGV5IGFyZSBwaHlzaWNhbGx5IG5vdCBwcmVzZW50LgorCSAqLworCWlmIChwci0+aWQgPT0gLTEp
IHsKKwkJaWYgKEFDUElfRkFJTFVSRQorCQkgICAgKHhlbl9hY3BpX3Byb2Nlc3Nvcl9ob3RhZGRf
aW5pdChwciwgJnByLT5pZCkpKSB7CisJCQlyZXR1cm4gLUVOT0RFVjsKKwkJfQorCX0KKwkvKgor
CSAqIE9uIHNvbWUgYm94ZXMgc2V2ZXJhbCBwcm9jZXNzb3JzIHVzZSB0aGUgc2FtZSBwcm9jZXNz
b3IgYnVzIGlkLgorCSAqIEJ1dCB0aGV5IGFyZSBsb2NhdGVkIGluIGRpZmZlcmVudCBzY29wZS4g
Rm9yIGV4YW1wbGU6CisJICogXF9TQi5TQ0swLkNQVTAKKwkgKiBcX1NCLlNDSzEuQ1BVMAorCSAq
IFJlbmFtZSB0aGUgcHJvY2Vzc29yIGRldmljZSBidXMgaWQuIEFuZCB0aGUgbmV3IGJ1cyBpZCB3
aWxsIGJlCisJICogZ2VuZXJhdGVkIGFzIHRoZSBmb2xsb3dpbmcgZm9ybWF0OgorCSAqIENQVStD
UFUgSUQuCisJICovCisJc3ByaW50ZihhY3BpX2RldmljZV9iaWQoZGV2aWNlKSwgIkNQVSVYIiwg
cHItPmlkKTsKKwlBQ1BJX0RFQlVHX1BSSU5UKChBQ1BJX0RCX0lORk8sICJQcm9jZXNzb3IgWyVk
OiVkXVxuIiwgcHItPmlkLAorCQkJICBwci0+YWNwaV9pZCkpOworCisJaWYgKCFvYmplY3QucHJv
Y2Vzc29yLnBibGtfYWRkcmVzcykKKwkJQUNQSV9ERUJVR19QUklOVCgoQUNQSV9EQl9JTkZPLCAi
Tm8gUEJMSyAoTlVMTCBhZGRyZXNzKVxuIikpOworCWVsc2UgaWYgKG9iamVjdC5wcm9jZXNzb3Iu
cGJsa19sZW5ndGggIT0gNikKKwkJcHJpbnRrKEtFUk5fRVJSIFBSRUZJWCAiSW52YWxpZCBQQkxL
IGxlbmd0aCBbJWRdXG4iLAorCQkJICAgIG9iamVjdC5wcm9jZXNzb3IucGJsa19sZW5ndGgpOwor
CWVsc2UgeworCQlwci0+dGhyb3R0bGluZy5hZGRyZXNzID0gb2JqZWN0LnByb2Nlc3Nvci5wYmxr
X2FkZHJlc3M7CisJCXByLT50aHJvdHRsaW5nLmR1dHlfb2Zmc2V0ID0gYWNwaV9nYmxfRkFEVC5k
dXR5X29mZnNldDsKKwkJcHItPnRocm90dGxpbmcuZHV0eV93aWR0aCA9IGFjcGlfZ2JsX0ZBRFQu
ZHV0eV93aWR0aDsKKworCQlwci0+cGJsayA9IG9iamVjdC5wcm9jZXNzb3IucGJsa19hZGRyZXNz
OworCisJCS8qCisJCSAqIFdlIGRvbid0IGNhcmUgYWJvdXQgZXJyb3IgcmV0dXJucyAtIHdlIGp1
c3QgdHJ5IHRvIG1hcmsKKwkJICogdGhlc2UgcmVzZXJ2ZWQgc28gdGhhdCBub2JvZHkgZWxzZSBp
cyBjb25mdXNlZCBpbnRvIHRoaW5raW5nCisJCSAqIHRoYXQgdGhpcyByZWdpb24gbWlnaHQgYmUg
dW51c2VkLi4KKwkJICoKKwkJICogKEluIHBhcnRpY3VsYXIsIGFsbG9jYXRpbmcgdGhlIElPIHJh
bmdlIGZvciBDYXJkYnVzKQorCQkgKi8KKwkJcmVxdWVzdF9yZWdpb24ocHItPnRocm90dGxpbmcu
YWRkcmVzcywgNiwgIkFDUEkgQ1BVIHRocm90dGxlIik7CisJfQorCisJLyoKKwkgKiBJZiBBQ1BJ
IGRlc2NyaWJlcyBhIHNsb3QgbnVtYmVyIGZvciB0aGlzIENQVSwgd2UgY2FuIHVzZSBpdAorCSAq
IGVuc3VyZSB3ZSBnZXQgdGhlIHJpZ2h0IHZhbHVlIGluIHRoZSAicGh5c2ljYWwgaWQiIGZpZWxk
CisJICogb2YgL3Byb2MvY3B1aW5mbworCSAqLworCXN0YXR1cyA9IGFjcGlfZXZhbHVhdGVfb2Jq
ZWN0KHByLT5oYW5kbGUsICJfU1VOIiwgTlVMTCwgJmJ1ZmZlcik7CisJaWYgKEFDUElfU1VDQ0VT
UyhzdGF0dXMpKQorCQlhcmNoX2ZpeF9waHlzX3BhY2thZ2VfaWQocHItPmlkLCBvYmplY3QuaW50
ZWdlci52YWx1ZSk7CisKKwlyZXR1cm4gMDsKK30KKworc3RhdGljIGludCBfX2NwdWluaXQgX194
ZW5fYWNwaV9wcm9jZXNzb3JfYWRkKHN0cnVjdCBhY3BpX2RldmljZSAqZGV2aWNlKQoreworCXN0
cnVjdCBhY3BpX3Byb2Nlc3NvciAqcHIgPSBOVUxMOworCWludCByZXN1bHQgPSAwOworCXN0cnVj
dCBzeXNfZGV2aWNlICpzeXNkZXY7CisKKwlwciA9IGt6YWxsb2Moc2l6ZW9mKHN0cnVjdCBhY3Bp
X3Byb2Nlc3NvciksIEdGUF9LRVJORUwpOworCWlmICghcHIpCisJCXJldHVybiAtRU5PTUVNOwor
CisJaWYgKCF6YWxsb2NfY3B1bWFza192YXIoJnByLT50aHJvdHRsaW5nLnNoYXJlZF9jcHVfbWFw
LCBHRlBfS0VSTkVMKSkgeworCQlrZnJlZShwcik7CisJCXJldHVybiAtRU5PTUVNOworCX0KKwor
CXByLT5oYW5kbGUgPSBkZXZpY2UtPmhhbmRsZTsKKwlzdHJjcHkoYWNwaV9kZXZpY2VfbmFtZShk
ZXZpY2UpLCBBQ1BJX1BST0NFU1NPUl9ERVZJQ0VfTkFNRSk7CisJc3RyY3B5KGFjcGlfZGV2aWNl
X2NsYXNzKGRldmljZSksIEFDUElfUFJPQ0VTU09SX0NMQVNTKTsKKwlkZXZpY2UtPmRyaXZlcl9k
YXRhID0gcHI7CisKKwlyZXN1bHQgPSB4ZW5fYWNwaV9wcm9jZXNzb3JfZ2V0X2luZm8oZGV2aWNl
KTsKKwlpZiAocmVzdWx0KSB7CisJCS8qIFByb2Nlc3NvciBpcyBwaHlzaWNhbGx5IG5vdCBwcmVz
ZW50ICovCisJCXJldHVybiAwOworCX0KKworI2lmZGVmIENPTkZJR19TTVAKKwlpZiAocHItPmlk
ID49IHNldHVwX21heF9jcHVzICYmIHByLT5pZCAhPSAwKQorCQlyZXR1cm4gMDsKKyNlbmRpZgor
CisJQlVHX09OKChwci0+aWQgPj0gbnJfY3B1X2lkcykgfHwgKHByLT5pZCA8IDApKTsKKworCS8q
CisJICogQnVnZ3kgQklPUyBjaGVjaworCSAqIEFDUEkgaWQgb2YgcHJvY2Vzc29ycyBjYW4gYmUg
cmVwb3J0ZWQgd3JvbmdseSBieSB0aGUgQklPUy4KKwkgKiBEb24ndCB0cnVzdCBpdCBibGluZGx5
CisJICovCisJaWYgKHBlcl9jcHUocHJvY2Vzc29yX2RldmljZV9hcnJheSwgcHItPmlkKSAhPSBO
VUxMICYmCisJICAgIHBlcl9jcHUocHJvY2Vzc29yX2RldmljZV9hcnJheSwgcHItPmlkKSAhPSBk
ZXZpY2UpIHsKKwkJcHJpbnRrKEtFUk5fV0FSTklORyAiQklPUyByZXBvcnRlZCB3cm9uZyBBQ1BJ
IGlkICIKKwkJCSJmb3IgdGhlIHByb2Nlc3NvclxuIik7CisJCXJlc3VsdCA9IC1FTk9ERVY7CisJ
CWdvdG8gZXJyX2ZyZWVfY3B1bWFzazsKKwl9CisJcGVyX2NwdShwcm9jZXNzb3JfZGV2aWNlX2Fy
cmF5LCBwci0+aWQpID0gZGV2aWNlOworCisJcGVyX2NwdShwcm9jZXNzb3JzLCBwci0+aWQpID0g
cHI7CisKKwlzeXNkZXYgPSBnZXRfY3B1X3N5c2Rldihwci0+aWQpOworCWlmIChzeXNmc19jcmVh
dGVfbGluaygmZGV2aWNlLT5kZXYua29iaiwgJnN5c2Rldi0+a29iaiwgInN5c2RldiIpKSB7CisJ
CXJlc3VsdCA9IC1FRkFVTFQ7CisJCWdvdG8gZXJyX2ZyZWVfY3B1bWFzazsKKwl9CisKKyNpZmRl
ZiBDT05GSUdfQ1BVX0ZSRVEKKwlhY3BpX3Byb2Nlc3Nvcl9wcGNfaGFzX2NoYW5nZWQocHIsIDAp
OworI2VuZGlmCisJYWNwaV9wcm9jZXNzb3JfZ2V0X3Rocm90dGxpbmdfaW5mbyhwcik7CisJYWNw
aV9wcm9jZXNzb3JfZ2V0X2xpbWl0X2luZm8ocHIpOworCisKKwlpZiAoY3B1aWRsZV9nZXRfZHJp
dmVyKCkgPT0gJmFjcGlfaWRsZV9kcml2ZXIpCisJCWFjcGlfcHJvY2Vzc29yX3Bvd2VyX2luaXQo
cHIsIGRldmljZSk7CisKKwlwci0+Y2RldiA9IHRoZXJtYWxfY29vbGluZ19kZXZpY2VfcmVnaXN0
ZXIoIlByb2Nlc3NvciIsIGRldmljZSwKKwkJCQkJCSZwcm9jZXNzb3JfY29vbGluZ19vcHMpOwor
CWlmIChJU19FUlIocHItPmNkZXYpKSB7CisJCXJlc3VsdCA9IFBUUl9FUlIocHItPmNkZXYpOwor
CQlnb3RvIGVycl9wb3dlcl9leGl0OworCX0KKworCWRldl9kYmcoJmRldmljZS0+ZGV2LCAicmVn
aXN0ZXJlZCBhcyBjb29saW5nX2RldmljZSVkXG4iLAorCQkgcHItPmNkZXYtPmlkKTsKKworCXJl
c3VsdCA9IHN5c2ZzX2NyZWF0ZV9saW5rKCZkZXZpY2UtPmRldi5rb2JqLAorCQkJCSAgICZwci0+
Y2Rldi0+ZGV2aWNlLmtvYmosCisJCQkJICAgInRoZXJtYWxfY29vbGluZyIpOworCWlmIChyZXN1
bHQpIHsKKwkJcHJpbnRrKEtFUk5fRVJSIFBSRUZJWCAiQ3JlYXRlIHN5c2ZzIGxpbmtcbiIpOwor
CQlnb3RvIGVycl90aGVybWFsX3VucmVnaXN0ZXI7CisJfQorCXJlc3VsdCA9IHN5c2ZzX2NyZWF0
ZV9saW5rKCZwci0+Y2Rldi0+ZGV2aWNlLmtvYmosCisJCQkJICAgJmRldmljZS0+ZGV2LmtvYmos
CisJCQkJICAgImRldmljZSIpOworCWlmIChyZXN1bHQpIHsKKwkJcHJpbnRrKEtFUk5fRVJSIFBS
RUZJWCAiQ3JlYXRlIHN5c2ZzIGxpbmtcbiIpOworCQlnb3RvIGVycl9yZW1vdmVfc3lzZnM7CisJ
fQorCisJcmV0dXJuIDA7CisKK2Vycl9yZW1vdmVfc3lzZnM6CisJc3lzZnNfcmVtb3ZlX2xpbmso
JmRldmljZS0+ZGV2LmtvYmosICJ0aGVybWFsX2Nvb2xpbmciKTsKK2Vycl90aGVybWFsX3VucmVn
aXN0ZXI6CisJdGhlcm1hbF9jb29saW5nX2RldmljZV91bnJlZ2lzdGVyKHByLT5jZGV2KTsKK2Vy
cl9wb3dlcl9leGl0OgorCWFjcGlfcHJvY2Vzc29yX3Bvd2VyX2V4aXQocHIsIGRldmljZSk7Citl
cnJfZnJlZV9jcHVtYXNrOgorCWZyZWVfY3B1bWFza192YXIocHItPnRocm90dGxpbmcuc2hhcmVk
X2NwdV9tYXApOworCisJcmV0dXJuIHJlc3VsdDsKK30KKwogc3RhdGljIGludCBfX2NwdWluaXQg
eGVuX2FjcGlfcHJvY2Vzc29yX2FkZChzdHJ1Y3QgYWNwaV9kZXZpY2UgKmRldmljZSkKIHsKIAlz
dHJ1Y3QgYWNwaV9wcm9jZXNzb3IgKnByID0gTlVMTDsKIAlpbnQgcmVzdWx0ID0gMDsKIAotCXJl
c3VsdCA9IGFjcGlfcHJvY2Vzc29yX2FkZChkZXZpY2UpOwotCWlmIChyZXN1bHQgPCAwKQorCXJl
c3VsdCA9IF9feGVuX2FjcGlfcHJvY2Vzc29yX2FkZChkZXZpY2UpOworCWlmIChyZXN1bHQpCiAJ
CXJldHVybiByZXN1bHQ7CiAKIAlwciA9IGFjcGlfZHJpdmVyX2RhdGEoZGV2aWNlKTsKZGlmZiAt
LWdpdCBhL2luY2x1ZGUvYWNwaS9wcm9jZXNzb3IuaCBiL2luY2x1ZGUvYWNwaS9wcm9jZXNzb3Iu
aAppbmRleCBjNDhlMmY5Li4zYTFlZTAxIDEwMDY0NAotLS0gYS9pbmNsdWRlL2FjcGkvcHJvY2Vz
c29yLmgKKysrIGIvaW5jbHVkZS9hY3BpL3Byb2Nlc3Nvci5oCkBAIC0yMjUsNiArMjI1LDggQEAg
c3RydWN0IGFjcGlfcHJvY2Vzc29yX2VycmF0YSB7CiAJfSBwaWl4NDsKIH07CiAKK2V4dGVybiBp
bnQgYWNwaV9wcm9jZXNzb3JfZXJyYXRhKHN0cnVjdCBhY3BpX3Byb2Nlc3NvciAqcHIpOworCiBl
eHRlcm4gaW50IGFjcGlfcHJvY2Vzc29yX3ByZXJlZ2lzdGVyX3BlcmZvcm1hbmNlKHN0cnVjdAog
CQkJCQkJICBhY3BpX3Byb2Nlc3Nvcl9wZXJmb3JtYW5jZQogCQkJCQkJICBfX3BlcmNwdSAqcGVy
Zm9ybWFuY2UpOwpkaWZmIC0tZ2l0IGEvaW5jbHVkZS94ZW4vcGNwdS5oIGIvaW5jbHVkZS94ZW4v
cGNwdS5oCmluZGV4IDdlOGY5ZDEuLjNlOTlkYjkgMTAwNjQ0Ci0tLSBhL2luY2x1ZGUveGVuL3Bj
cHUuaAorKysgYi9pbmNsdWRlL3hlbi9wY3B1LmgKQEAgLTQsNiArNCw4IEBACiAjaW5jbHVkZSA8
eGVuL2ludGVyZmFjZS9wbGF0Zm9ybS5oPgogI2luY2x1ZGUgPGxpbnV4L3N5c2Rldi5oPgogCitl
eHRlcm4gREVGSU5FX1BFUl9DUFUodm9pZCAqLCBwcm9jZXNzb3JfZGV2aWNlX2FycmF5KTsKKwog
ZXh0ZXJuIGludCB4ZW5fcGNwdV9ob3RwbHVnKGludCB0eXBlLCB1aW50MzJfdCBhcGljX2lkKTsK
ICNkZWZpbmUgWEVOX1BDUFVfT05MSU5FICAgICAweDAxCiAjZGVmaW5lIFhFTl9QQ1BVX09GRkxJ
TkUgICAgMHgwMgotLSAKMS42LjUuNgoK

--_002_DE8DF0795D48FD4CA783C40EC82923358A81SHSMSX101ccrcorpint_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--_002_DE8DF0795D48FD4CA783C40EC82923358A81SHSMSX101ccrcorpint_--


From xen-devel-bounces@lists.xensource.com Thu Dec 22 10:10:27 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 Dec 2011 10:10:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdfbP-00062b-Dw; Thu, 22 Dec 2011 10:10:19 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1RdfbN-00061I-JO
	for xen-devel@lists.xensource.com; Thu, 22 Dec 2011 10:10:17 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1324548609!7252538!1
X-Originating-IP: [143.182.124.37]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjE1ODY2\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2330 invoked from network); 22 Dec 2011 10:10:10 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37)
	by server-13.tower-21.messagelabs.com with SMTP;
	22 Dec 2011 10:10:10 -0000
Received: from azsmga002.ch.intel.com ([10.2.17.35])
	by azsmga102.ch.intel.com with ESMTP; 22 Dec 2011 02:10:08 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208,223";a="49701548"
Received: from pgsmsx603.gar.corp.intel.com ([10.221.43.87])
	by AZSMGA002.ch.intel.com with ESMTP; 22 Dec 2011 02:10:07 -0800
Received: from pgsmsx104.gar.corp.intel.com (10.221.44.91) by
	pgsmsx603.gar.corp.intel.com (10.221.43.87) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Thu, 22 Dec 2011 18:10:01 +0800
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	PGSMSX104.gar.corp.intel.com (10.221.44.91) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Thu, 22 Dec 2011 18:10:00 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.38]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.199]) with mapi id
	14.01.0355.002; Thu, 22 Dec 2011 18:09:59 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: "konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Thread-Topic: [PATCH 10/10] Xen: update pcpu online/offline logic
Thread-Index: AczAkdxaoHqdTg3vQVCnxzYJrj0tPQ==
Date: Thu, 22 Dec 2011 10:09:59 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC82923358AB2@SHSMSX101.ccr.corp.intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
Content-Type: multipart/mixed;
	boundary="_002_DE8DF0795D48FD4CA783C40EC82923358AB2SHSMSX101ccrcorpint_"
MIME-Version: 1.0
Cc: "Jiang, Yunhong" <yunhong.jiang@intel.com>,
	"jeremy.fitzhardinge@citrix.com" <jeremy.fitzhardinge@citrix.com>
Subject: [Xen-devel] [PATCH 10/10] Xen: update pcpu online/offline logic
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--_002_DE8DF0795D48FD4CA783C40EC82923358AB2SHSMSX101ccrcorpint_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

>From 1e59d2ec2ff93b42c86d18c7cc9432ca2172a795 Mon Sep 17 00:00:00 2001
From: Liu Jinsong <jinsong.liu@intel.com>
Date: Wed, 14 Dec 2011 21:06:11 +0800
Subject: [PATCH 10/10] Xen: update pcpu online/offline logic

This patch update pcpu online/offline logic.

It closes cpu0's /sys/.../xen_pcpu0/online authority to user.
It also simplifies pcpu sync by removing redundant logic.

Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
Signed-off-by: Jiang, Yunhong <yunhong.jiang@intel.com>
---
 drivers/xen/pcpu.c |   71 ++++++++++++++----------------------------------=
----
 1 files changed, 19 insertions(+), 52 deletions(-)

diff --git a/drivers/xen/pcpu.c b/drivers/xen/pcpu.c
index 6d1a770..1d32784 100644
--- a/drivers/xen/pcpu.c
+++ b/drivers/xen/pcpu.c
@@ -24,7 +24,6 @@ static RAW_NOTIFIER_HEAD(xen_pcpu_chain);
=20
 struct xen_pcpus {
 	struct list_head list;
-	int present;
 };
 static struct xen_pcpus xen_pcpus;
=20
@@ -189,9 +188,13 @@ static int pcpu_sysdev_init(struct pcpu *cpu)
 		kfree(cpu);
 		return -1;
 	}
-	sysdev_create_file(&cpu->sysdev, &attr_online);
 	sysdev_create_file(&cpu->sysdev, &attr_apic_id);
 	sysdev_create_file(&cpu->sysdev, &attr_acpi_id);
+
+	/* Not open cpu0 online access to user */
+	if (cpu->sysdev.id)
+		sysdev_create_file(&cpu->sysdev, &attr_online);
+
 	return 0;
 }
=20
@@ -239,17 +242,10 @@ static struct pcpu *init_pcpu(struct xenpf_pcpuinfo *=
info)
 	return pcpu;
 }
=20
-#define PCPU_NO_CHANGE			0
-#define PCPU_ADDED			1
-#define PCPU_ONLINE_OFFLINE		2
-#define PCPU_REMOVED			3
 /*
  * Caller should hold the pcpu lock
- * < 0: Something wrong
- * 0: No changes
- * > 0: State changed
  */
-static struct pcpu *_sync_pcpu(int cpu_num, int *max_id, int *result)
+static int _sync_pcpu(int cpu_num, int *max_id)
 {
 	struct pcpu *pcpu =3D NULL;
 	struct xenpf_pcpuinfo *info;
@@ -259,14 +255,12 @@ static struct pcpu *_sync_pcpu(int cpu_num, int *max_=
id, int *result)
 	};
 	int ret;
=20
-	*result =3D -1;
-
 	info =3D &op.u.pcpu_info;
 	info->xen_cpuid =3D cpu_num;
=20
 	ret =3D HYPERVISOR_dom0_op(&op);
 	if (ret)
-		return NULL;
+		return -1;
=20
 	if (max_id)
 		*max_id =3D op.u.pcpu_info.max_present;
@@ -275,28 +269,24 @@ static struct pcpu *_sync_pcpu(int cpu_num, int *max_=
id, int *result)
=20
 	if (info->flags & XEN_PCPU_FLAGS_INVALID) {
 		/* The pcpu has been removed */
-		*result =3D PCPU_NO_CHANGE;
 		if (pcpu) {
 			raw_notifier_call_chain(&xen_pcpu_chain,
 			  XEN_PCPU_REMOVE,
 			  (void *)(long)pcpu->xen_id);
 			xen_pcpu_free(pcpu);
-			*result =3D PCPU_REMOVED;
 		}
-		return NULL;
+		return 0;
 	}
=20
=20
 	if (!pcpu) {
-		*result =3D PCPU_ADDED;
 		pcpu =3D init_pcpu(info);
 		if (pcpu =3D=3D NULL) {
 			printk(KERN_WARNING "Failed to init pcpu %x\n",
 			  info->xen_cpuid);
-			  *result =3D -1;
+			return -1;
 		}
 	} else {
-		*result =3D PCPU_NO_CHANGE;
 		/*
 		 * Old PCPU is replaced with a new pcpu, this means
 		 * several virq is missed, will it happen?
@@ -307,10 +297,10 @@ static struct pcpu *_sync_pcpu(int cpu_num, int *max_=
id, int *result)
 			pcpu->apic_id =3D info->apic_id;
 			pcpu->acpi_id =3D info->acpi_id;
 		}
-		if (xen_pcpu_online_check(info, pcpu))
-			*result =3D PCPU_ONLINE_OFFLINE;
+		xen_pcpu_online_check(info, pcpu);
 	}
-	return pcpu;
+
+	return 0;
 }
=20
 int xen_pcpu_index(uint32_t id, int is_acpiid)
@@ -353,50 +343,27 @@ static int xen_sync_pcpus(void)
 	/*
 	 * Boot cpu always have cpu_id 0 in xen
 	 */
-	int cpu_num =3D 0, max_id =3D 0, result =3D 0, present =3D 0;
+	int cpu_num =3D 0, max_id =3D 0, ret =3D 0;
 	struct list_head *elem, *tmp;
 	struct pcpu *pcpu;
=20
 	get_pcpu_lock();
=20
-	while ((result >=3D 0) && (cpu_num <=3D max_id)) {
-		pcpu =3D _sync_pcpu(cpu_num, &max_id, &result);
-
-		printk(KERN_DEBUG "sync cpu %x get result %x max_id %x\n",
-			cpu_num, result, max_id);
-
-		switch (result)	{
-		case PCPU_NO_CHANGE:
-			if (pcpu)
-				present++;
-			break;
-		case PCPU_ADDED:
-		case PCPU_ONLINE_OFFLINE:
-			present++;
-		case PCPU_REMOVED:
-			break;
-		default:
-			printk(KERN_WARNING "Failed to sync pcpu %x\n",
-			  cpu_num);
-			break;
-
-		}
+	while (!ret && (cpu_num <=3D max_id)) {
+		ret =3D _sync_pcpu(cpu_num, &max_id);
 		cpu_num++;
 	}
=20
-	if (result < 0) {
+	if (ret < 0) {
 		list_for_each_safe(elem, tmp, &xen_pcpus.list) {
 			pcpu =3D list_entry(elem, struct pcpu, pcpu_list);
 			xen_pcpu_free(pcpu);
 		}
-		present =3D 0;
 	}
=20
-	xen_pcpus.present =3D present;
-
 	put_pcpu_lock();
=20
-	return 0;
+	return ret;
 }
=20
 static void xen_pcpu_dpc(struct work_struct *work)
@@ -436,10 +403,10 @@ static int __init xen_pcpu_init(void)
 	}
=20
 	INIT_LIST_HEAD(&xen_pcpus.list);
-	xen_pcpus.present =3D 0;
=20
 	xen_sync_pcpus();
-	if (xen_pcpus.present > 0)
+
+	if (!list_empty(&xen_pcpus.list))
 		err =3D bind_virq_to_irqhandler(VIRQ_PCPU_STATE,
 			0, xen_pcpu_interrupt, 0, "pcpu", NULL);
 	if (err < 0)
--=20
1.6.5.6

--_002_DE8DF0795D48FD4CA783C40EC82923358AB2SHSMSX101ccrcorpint_
Content-Type: application/octet-stream;
	name="0010-Xen-update-pcpu-online-offline-logic.patch"
Content-Description: 0010-Xen-update-pcpu-online-offline-logic.patch
Content-Disposition: attachment;
	filename="0010-Xen-update-pcpu-online-offline-logic.patch"; size=4793;
	creation-date="Wed, 14 Dec 2011 15:20:15 GMT";
	modification-date="Wed, 14 Dec 2011 15:03:34 GMT"
Content-Transfer-Encoding: base64

RnJvbSAxZTU5ZDJlYzJmZjkzYjQyYzg2ZDE4YzdjYzk0MzJjYTIxNzJhNzk1IE1vbiBTZXAgMTcg
MDA6MDA6MDAgMjAwMQpGcm9tOiBMaXUgSmluc29uZyA8amluc29uZy5saXVAaW50ZWwuY29tPgpE
YXRlOiBXZWQsIDE0IERlYyAyMDExIDIxOjA2OjExICswODAwClN1YmplY3Q6IFtQQVRDSCAxMC8x
MF0gWGVuOiB1cGRhdGUgcGNwdSBvbmxpbmUvb2ZmbGluZSBsb2dpYwoKVGhpcyBwYXRjaCB1cGRh
dGUgcGNwdSBvbmxpbmUvb2ZmbGluZSBsb2dpYy4KCkl0IGNsb3NlcyBjcHUwJ3MgL3N5cy8uLi4v
eGVuX3BjcHUwL29ubGluZSBhdXRob3JpdHkgdG8gdXNlci4KSXQgYWxzbyBzaW1wbGlmaWVzIHBj
cHUgc3luYyBieSByZW1vdmluZyByZWR1bmRhbnQgbG9naWMuCgpTaWduZWQtb2ZmLWJ5OiBMaXUs
IEppbnNvbmcgPGppbnNvbmcubGl1QGludGVsLmNvbT4KU2lnbmVkLW9mZi1ieTogSmlhbmcsIFl1
bmhvbmcgPHl1bmhvbmcuamlhbmdAaW50ZWwuY29tPgotLS0KIGRyaXZlcnMveGVuL3BjcHUuYyB8
ICAgNzEgKysrKysrKysrKysrKystLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LQogMSBmaWxlcyBjaGFuZ2VkLCAxOSBpbnNlcnRpb25zKCspLCA1MiBkZWxldGlvbnMoLSkKCmRp
ZmYgLS1naXQgYS9kcml2ZXJzL3hlbi9wY3B1LmMgYi9kcml2ZXJzL3hlbi9wY3B1LmMKaW5kZXgg
NmQxYTc3MC4uMWQzMjc4NCAxMDA2NDQKLS0tIGEvZHJpdmVycy94ZW4vcGNwdS5jCisrKyBiL2Ry
aXZlcnMveGVuL3BjcHUuYwpAQCAtMjQsNyArMjQsNiBAQCBzdGF0aWMgUkFXX05PVElGSUVSX0hF
QUQoeGVuX3BjcHVfY2hhaW4pOwogCiBzdHJ1Y3QgeGVuX3BjcHVzIHsKIAlzdHJ1Y3QgbGlzdF9o
ZWFkIGxpc3Q7Ci0JaW50IHByZXNlbnQ7CiB9Owogc3RhdGljIHN0cnVjdCB4ZW5fcGNwdXMgeGVu
X3BjcHVzOwogCkBAIC0xODksOSArMTg4LDEzIEBAIHN0YXRpYyBpbnQgcGNwdV9zeXNkZXZfaW5p
dChzdHJ1Y3QgcGNwdSAqY3B1KQogCQlrZnJlZShjcHUpOwogCQlyZXR1cm4gLTE7CiAJfQotCXN5
c2Rldl9jcmVhdGVfZmlsZSgmY3B1LT5zeXNkZXYsICZhdHRyX29ubGluZSk7CiAJc3lzZGV2X2Ny
ZWF0ZV9maWxlKCZjcHUtPnN5c2RldiwgJmF0dHJfYXBpY19pZCk7CiAJc3lzZGV2X2NyZWF0ZV9m
aWxlKCZjcHUtPnN5c2RldiwgJmF0dHJfYWNwaV9pZCk7CisKKwkvKiBOb3Qgb3BlbiBjcHUwIG9u
bGluZSBhY2Nlc3MgdG8gdXNlciAqLworCWlmIChjcHUtPnN5c2Rldi5pZCkKKwkJc3lzZGV2X2Ny
ZWF0ZV9maWxlKCZjcHUtPnN5c2RldiwgJmF0dHJfb25saW5lKTsKKwogCXJldHVybiAwOwogfQog
CkBAIC0yMzksMTcgKzI0MiwxMCBAQCBzdGF0aWMgc3RydWN0IHBjcHUgKmluaXRfcGNwdShzdHJ1
Y3QgeGVucGZfcGNwdWluZm8gKmluZm8pCiAJcmV0dXJuIHBjcHU7CiB9CiAKLSNkZWZpbmUgUENQ
VV9OT19DSEFOR0UJCQkwCi0jZGVmaW5lIFBDUFVfQURERUQJCQkxCi0jZGVmaW5lIFBDUFVfT05M
SU5FX09GRkxJTkUJCTIKLSNkZWZpbmUgUENQVV9SRU1PVkVECQkJMwogLyoKICAqIENhbGxlciBz
aG91bGQgaG9sZCB0aGUgcGNwdSBsb2NrCi0gKiA8IDA6IFNvbWV0aGluZyB3cm9uZwotICogMDog
Tm8gY2hhbmdlcwotICogPiAwOiBTdGF0ZSBjaGFuZ2VkCiAgKi8KLXN0YXRpYyBzdHJ1Y3QgcGNw
dSAqX3N5bmNfcGNwdShpbnQgY3B1X251bSwgaW50ICptYXhfaWQsIGludCAqcmVzdWx0KQorc3Rh
dGljIGludCBfc3luY19wY3B1KGludCBjcHVfbnVtLCBpbnQgKm1heF9pZCkKIHsKIAlzdHJ1Y3Qg
cGNwdSAqcGNwdSA9IE5VTEw7CiAJc3RydWN0IHhlbnBmX3BjcHVpbmZvICppbmZvOwpAQCAtMjU5
LDE0ICsyNTUsMTIgQEAgc3RhdGljIHN0cnVjdCBwY3B1ICpfc3luY19wY3B1KGludCBjcHVfbnVt
LCBpbnQgKm1heF9pZCwgaW50ICpyZXN1bHQpCiAJfTsKIAlpbnQgcmV0OwogCi0JKnJlc3VsdCA9
IC0xOwotCiAJaW5mbyA9ICZvcC51LnBjcHVfaW5mbzsKIAlpbmZvLT54ZW5fY3B1aWQgPSBjcHVf
bnVtOwogCiAJcmV0ID0gSFlQRVJWSVNPUl9kb20wX29wKCZvcCk7CiAJaWYgKHJldCkKLQkJcmV0
dXJuIE5VTEw7CisJCXJldHVybiAtMTsKIAogCWlmIChtYXhfaWQpCiAJCSptYXhfaWQgPSBvcC51
LnBjcHVfaW5mby5tYXhfcHJlc2VudDsKQEAgLTI3NSwyOCArMjY5LDI0IEBAIHN0YXRpYyBzdHJ1
Y3QgcGNwdSAqX3N5bmNfcGNwdShpbnQgY3B1X251bSwgaW50ICptYXhfaWQsIGludCAqcmVzdWx0
KQogCiAJaWYgKGluZm8tPmZsYWdzICYgWEVOX1BDUFVfRkxBR1NfSU5WQUxJRCkgewogCQkvKiBU
aGUgcGNwdSBoYXMgYmVlbiByZW1vdmVkICovCi0JCSpyZXN1bHQgPSBQQ1BVX05PX0NIQU5HRTsK
IAkJaWYgKHBjcHUpIHsKIAkJCXJhd19ub3RpZmllcl9jYWxsX2NoYWluKCZ4ZW5fcGNwdV9jaGFp
biwKIAkJCSAgWEVOX1BDUFVfUkVNT1ZFLAogCQkJICAodm9pZCAqKShsb25nKXBjcHUtPnhlbl9p
ZCk7CiAJCQl4ZW5fcGNwdV9mcmVlKHBjcHUpOwotCQkJKnJlc3VsdCA9IFBDUFVfUkVNT1ZFRDsK
IAkJfQotCQlyZXR1cm4gTlVMTDsKKwkJcmV0dXJuIDA7CiAJfQogCiAKIAlpZiAoIXBjcHUpIHsK
LQkJKnJlc3VsdCA9IFBDUFVfQURERUQ7CiAJCXBjcHUgPSBpbml0X3BjcHUoaW5mbyk7CiAJCWlm
IChwY3B1ID09IE5VTEwpIHsKIAkJCXByaW50ayhLRVJOX1dBUk5JTkcgIkZhaWxlZCB0byBpbml0
IHBjcHUgJXhcbiIsCiAJCQkgIGluZm8tPnhlbl9jcHVpZCk7Ci0JCQkgICpyZXN1bHQgPSAtMTsK
KwkJCXJldHVybiAtMTsKIAkJfQogCX0gZWxzZSB7Ci0JCSpyZXN1bHQgPSBQQ1BVX05PX0NIQU5H
RTsKIAkJLyoKIAkJICogT2xkIFBDUFUgaXMgcmVwbGFjZWQgd2l0aCBhIG5ldyBwY3B1LCB0aGlz
IG1lYW5zCiAJCSAqIHNldmVyYWwgdmlycSBpcyBtaXNzZWQsIHdpbGwgaXQgaGFwcGVuPwpAQCAt
MzA3LDEwICsyOTcsMTAgQEAgc3RhdGljIHN0cnVjdCBwY3B1ICpfc3luY19wY3B1KGludCBjcHVf
bnVtLCBpbnQgKm1heF9pZCwgaW50ICpyZXN1bHQpCiAJCQlwY3B1LT5hcGljX2lkID0gaW5mby0+
YXBpY19pZDsKIAkJCXBjcHUtPmFjcGlfaWQgPSBpbmZvLT5hY3BpX2lkOwogCQl9Ci0JCWlmICh4
ZW5fcGNwdV9vbmxpbmVfY2hlY2soaW5mbywgcGNwdSkpCi0JCQkqcmVzdWx0ID0gUENQVV9PTkxJ
TkVfT0ZGTElORTsKKwkJeGVuX3BjcHVfb25saW5lX2NoZWNrKGluZm8sIHBjcHUpOwogCX0KLQly
ZXR1cm4gcGNwdTsKKworCXJldHVybiAwOwogfQogCiBpbnQgeGVuX3BjcHVfaW5kZXgodWludDMy
X3QgaWQsIGludCBpc19hY3BpaWQpCkBAIC0zNTMsNTAgKzM0MywyNyBAQCBzdGF0aWMgaW50IHhl
bl9zeW5jX3BjcHVzKHZvaWQpCiAJLyoKIAkgKiBCb290IGNwdSBhbHdheXMgaGF2ZSBjcHVfaWQg
MCBpbiB4ZW4KIAkgKi8KLQlpbnQgY3B1X251bSA9IDAsIG1heF9pZCA9IDAsIHJlc3VsdCA9IDAs
IHByZXNlbnQgPSAwOworCWludCBjcHVfbnVtID0gMCwgbWF4X2lkID0gMCwgcmV0ID0gMDsKIAlz
dHJ1Y3QgbGlzdF9oZWFkICplbGVtLCAqdG1wOwogCXN0cnVjdCBwY3B1ICpwY3B1OwogCiAJZ2V0
X3BjcHVfbG9jaygpOwogCi0Jd2hpbGUgKChyZXN1bHQgPj0gMCkgJiYgKGNwdV9udW0gPD0gbWF4
X2lkKSkgewotCQlwY3B1ID0gX3N5bmNfcGNwdShjcHVfbnVtLCAmbWF4X2lkLCAmcmVzdWx0KTsK
LQotCQlwcmludGsoS0VSTl9ERUJVRyAic3luYyBjcHUgJXggZ2V0IHJlc3VsdCAleCBtYXhfaWQg
JXhcbiIsCi0JCQljcHVfbnVtLCByZXN1bHQsIG1heF9pZCk7Ci0KLQkJc3dpdGNoIChyZXN1bHQp
CXsKLQkJY2FzZSBQQ1BVX05PX0NIQU5HRToKLQkJCWlmIChwY3B1KQotCQkJCXByZXNlbnQrKzsK
LQkJCWJyZWFrOwotCQljYXNlIFBDUFVfQURERUQ6Ci0JCWNhc2UgUENQVV9PTkxJTkVfT0ZGTElO
RToKLQkJCXByZXNlbnQrKzsKLQkJY2FzZSBQQ1BVX1JFTU9WRUQ6Ci0JCQlicmVhazsKLQkJZGVm
YXVsdDoKLQkJCXByaW50ayhLRVJOX1dBUk5JTkcgIkZhaWxlZCB0byBzeW5jIHBjcHUgJXhcbiIs
Ci0JCQkgIGNwdV9udW0pOwotCQkJYnJlYWs7Ci0KLQkJfQorCXdoaWxlICghcmV0ICYmIChjcHVf
bnVtIDw9IG1heF9pZCkpIHsKKwkJcmV0ID0gX3N5bmNfcGNwdShjcHVfbnVtLCAmbWF4X2lkKTsK
IAkJY3B1X251bSsrOwogCX0KIAotCWlmIChyZXN1bHQgPCAwKSB7CisJaWYgKHJldCA8IDApIHsK
IAkJbGlzdF9mb3JfZWFjaF9zYWZlKGVsZW0sIHRtcCwgJnhlbl9wY3B1cy5saXN0KSB7CiAJCQlw
Y3B1ID0gbGlzdF9lbnRyeShlbGVtLCBzdHJ1Y3QgcGNwdSwgcGNwdV9saXN0KTsKIAkJCXhlbl9w
Y3B1X2ZyZWUocGNwdSk7CiAJCX0KLQkJcHJlc2VudCA9IDA7CiAJfQogCi0JeGVuX3BjcHVzLnBy
ZXNlbnQgPSBwcmVzZW50OwotCiAJcHV0X3BjcHVfbG9jaygpOwogCi0JcmV0dXJuIDA7CisJcmV0
dXJuIHJldDsKIH0KIAogc3RhdGljIHZvaWQgeGVuX3BjcHVfZHBjKHN0cnVjdCB3b3JrX3N0cnVj
dCAqd29yaykKQEAgLTQzNiwxMCArNDAzLDEwIEBAIHN0YXRpYyBpbnQgX19pbml0IHhlbl9wY3B1
X2luaXQodm9pZCkKIAl9CiAKIAlJTklUX0xJU1RfSEVBRCgmeGVuX3BjcHVzLmxpc3QpOwotCXhl
bl9wY3B1cy5wcmVzZW50ID0gMDsKIAogCXhlbl9zeW5jX3BjcHVzKCk7Ci0JaWYgKHhlbl9wY3B1
cy5wcmVzZW50ID4gMCkKKworCWlmICghbGlzdF9lbXB0eSgmeGVuX3BjcHVzLmxpc3QpKQogCQll
cnIgPSBiaW5kX3ZpcnFfdG9faXJxaGFuZGxlcihWSVJRX1BDUFVfU1RBVEUsCiAJCQkwLCB4ZW5f
cGNwdV9pbnRlcnJ1cHQsIDAsICJwY3B1IiwgTlVMTCk7CiAJaWYgKGVyciA8IDApCi0tIAoxLjYu
NS42Cgo=

--_002_DE8DF0795D48FD4CA783C40EC82923358AB2SHSMSX101ccrcorpint_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--_002_DE8DF0795D48FD4CA783C40EC82923358AB2SHSMSX101ccrcorpint_--


From xen-devel-bounces@lists.xensource.com Thu Dec 22 10:10:27 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 Dec 2011 10:10:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdfbP-00062b-Dw; Thu, 22 Dec 2011 10:10:19 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1RdfbN-00061I-JO
	for xen-devel@lists.xensource.com; Thu, 22 Dec 2011 10:10:17 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1324548609!7252538!1
X-Originating-IP: [143.182.124.37]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjE1ODY2\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2330 invoked from network); 22 Dec 2011 10:10:10 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37)
	by server-13.tower-21.messagelabs.com with SMTP;
	22 Dec 2011 10:10:10 -0000
Received: from azsmga002.ch.intel.com ([10.2.17.35])
	by azsmga102.ch.intel.com with ESMTP; 22 Dec 2011 02:10:08 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208,223";a="49701548"
Received: from pgsmsx603.gar.corp.intel.com ([10.221.43.87])
	by AZSMGA002.ch.intel.com with ESMTP; 22 Dec 2011 02:10:07 -0800
Received: from pgsmsx104.gar.corp.intel.com (10.221.44.91) by
	pgsmsx603.gar.corp.intel.com (10.221.43.87) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Thu, 22 Dec 2011 18:10:01 +0800
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	PGSMSX104.gar.corp.intel.com (10.221.44.91) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Thu, 22 Dec 2011 18:10:00 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.38]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.199]) with mapi id
	14.01.0355.002; Thu, 22 Dec 2011 18:09:59 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: "konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Thread-Topic: [PATCH 10/10] Xen: update pcpu online/offline logic
Thread-Index: AczAkdxaoHqdTg3vQVCnxzYJrj0tPQ==
Date: Thu, 22 Dec 2011 10:09:59 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC82923358AB2@SHSMSX101.ccr.corp.intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
Content-Type: multipart/mixed;
	boundary="_002_DE8DF0795D48FD4CA783C40EC82923358AB2SHSMSX101ccrcorpint_"
MIME-Version: 1.0
Cc: "Jiang, Yunhong" <yunhong.jiang@intel.com>,
	"jeremy.fitzhardinge@citrix.com" <jeremy.fitzhardinge@citrix.com>
Subject: [Xen-devel] [PATCH 10/10] Xen: update pcpu online/offline logic
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--_002_DE8DF0795D48FD4CA783C40EC82923358AB2SHSMSX101ccrcorpint_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

>From 1e59d2ec2ff93b42c86d18c7cc9432ca2172a795 Mon Sep 17 00:00:00 2001
From: Liu Jinsong <jinsong.liu@intel.com>
Date: Wed, 14 Dec 2011 21:06:11 +0800
Subject: [PATCH 10/10] Xen: update pcpu online/offline logic

This patch update pcpu online/offline logic.

It closes cpu0's /sys/.../xen_pcpu0/online authority to user.
It also simplifies pcpu sync by removing redundant logic.

Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
Signed-off-by: Jiang, Yunhong <yunhong.jiang@intel.com>
---
 drivers/xen/pcpu.c |   71 ++++++++++++++----------------------------------=
----
 1 files changed, 19 insertions(+), 52 deletions(-)

diff --git a/drivers/xen/pcpu.c b/drivers/xen/pcpu.c
index 6d1a770..1d32784 100644
--- a/drivers/xen/pcpu.c
+++ b/drivers/xen/pcpu.c
@@ -24,7 +24,6 @@ static RAW_NOTIFIER_HEAD(xen_pcpu_chain);
=20
 struct xen_pcpus {
 	struct list_head list;
-	int present;
 };
 static struct xen_pcpus xen_pcpus;
=20
@@ -189,9 +188,13 @@ static int pcpu_sysdev_init(struct pcpu *cpu)
 		kfree(cpu);
 		return -1;
 	}
-	sysdev_create_file(&cpu->sysdev, &attr_online);
 	sysdev_create_file(&cpu->sysdev, &attr_apic_id);
 	sysdev_create_file(&cpu->sysdev, &attr_acpi_id);
+
+	/* Not open cpu0 online access to user */
+	if (cpu->sysdev.id)
+		sysdev_create_file(&cpu->sysdev, &attr_online);
+
 	return 0;
 }
=20
@@ -239,17 +242,10 @@ static struct pcpu *init_pcpu(struct xenpf_pcpuinfo *=
info)
 	return pcpu;
 }
=20
-#define PCPU_NO_CHANGE			0
-#define PCPU_ADDED			1
-#define PCPU_ONLINE_OFFLINE		2
-#define PCPU_REMOVED			3
 /*
  * Caller should hold the pcpu lock
- * < 0: Something wrong
- * 0: No changes
- * > 0: State changed
  */
-static struct pcpu *_sync_pcpu(int cpu_num, int *max_id, int *result)
+static int _sync_pcpu(int cpu_num, int *max_id)
 {
 	struct pcpu *pcpu =3D NULL;
 	struct xenpf_pcpuinfo *info;
@@ -259,14 +255,12 @@ static struct pcpu *_sync_pcpu(int cpu_num, int *max_=
id, int *result)
 	};
 	int ret;
=20
-	*result =3D -1;
-
 	info =3D &op.u.pcpu_info;
 	info->xen_cpuid =3D cpu_num;
=20
 	ret =3D HYPERVISOR_dom0_op(&op);
 	if (ret)
-		return NULL;
+		return -1;
=20
 	if (max_id)
 		*max_id =3D op.u.pcpu_info.max_present;
@@ -275,28 +269,24 @@ static struct pcpu *_sync_pcpu(int cpu_num, int *max_=
id, int *result)
=20
 	if (info->flags & XEN_PCPU_FLAGS_INVALID) {
 		/* The pcpu has been removed */
-		*result =3D PCPU_NO_CHANGE;
 		if (pcpu) {
 			raw_notifier_call_chain(&xen_pcpu_chain,
 			  XEN_PCPU_REMOVE,
 			  (void *)(long)pcpu->xen_id);
 			xen_pcpu_free(pcpu);
-			*result =3D PCPU_REMOVED;
 		}
-		return NULL;
+		return 0;
 	}
=20
=20
 	if (!pcpu) {
-		*result =3D PCPU_ADDED;
 		pcpu =3D init_pcpu(info);
 		if (pcpu =3D=3D NULL) {
 			printk(KERN_WARNING "Failed to init pcpu %x\n",
 			  info->xen_cpuid);
-			  *result =3D -1;
+			return -1;
 		}
 	} else {
-		*result =3D PCPU_NO_CHANGE;
 		/*
 		 * Old PCPU is replaced with a new pcpu, this means
 		 * several virq is missed, will it happen?
@@ -307,10 +297,10 @@ static struct pcpu *_sync_pcpu(int cpu_num, int *max_=
id, int *result)
 			pcpu->apic_id =3D info->apic_id;
 			pcpu->acpi_id =3D info->acpi_id;
 		}
-		if (xen_pcpu_online_check(info, pcpu))
-			*result =3D PCPU_ONLINE_OFFLINE;
+		xen_pcpu_online_check(info, pcpu);
 	}
-	return pcpu;
+
+	return 0;
 }
=20
 int xen_pcpu_index(uint32_t id, int is_acpiid)
@@ -353,50 +343,27 @@ static int xen_sync_pcpus(void)
 	/*
 	 * Boot cpu always have cpu_id 0 in xen
 	 */
-	int cpu_num =3D 0, max_id =3D 0, result =3D 0, present =3D 0;
+	int cpu_num =3D 0, max_id =3D 0, ret =3D 0;
 	struct list_head *elem, *tmp;
 	struct pcpu *pcpu;
=20
 	get_pcpu_lock();
=20
-	while ((result >=3D 0) && (cpu_num <=3D max_id)) {
-		pcpu =3D _sync_pcpu(cpu_num, &max_id, &result);
-
-		printk(KERN_DEBUG "sync cpu %x get result %x max_id %x\n",
-			cpu_num, result, max_id);
-
-		switch (result)	{
-		case PCPU_NO_CHANGE:
-			if (pcpu)
-				present++;
-			break;
-		case PCPU_ADDED:
-		case PCPU_ONLINE_OFFLINE:
-			present++;
-		case PCPU_REMOVED:
-			break;
-		default:
-			printk(KERN_WARNING "Failed to sync pcpu %x\n",
-			  cpu_num);
-			break;
-
-		}
+	while (!ret && (cpu_num <=3D max_id)) {
+		ret =3D _sync_pcpu(cpu_num, &max_id);
 		cpu_num++;
 	}
=20
-	if (result < 0) {
+	if (ret < 0) {
 		list_for_each_safe(elem, tmp, &xen_pcpus.list) {
 			pcpu =3D list_entry(elem, struct pcpu, pcpu_list);
 			xen_pcpu_free(pcpu);
 		}
-		present =3D 0;
 	}
=20
-	xen_pcpus.present =3D present;
-
 	put_pcpu_lock();
=20
-	return 0;
+	return ret;
 }
=20
 static void xen_pcpu_dpc(struct work_struct *work)
@@ -436,10 +403,10 @@ static int __init xen_pcpu_init(void)
 	}
=20
 	INIT_LIST_HEAD(&xen_pcpus.list);
-	xen_pcpus.present =3D 0;
=20
 	xen_sync_pcpus();
-	if (xen_pcpus.present > 0)
+
+	if (!list_empty(&xen_pcpus.list))
 		err =3D bind_virq_to_irqhandler(VIRQ_PCPU_STATE,
 			0, xen_pcpu_interrupt, 0, "pcpu", NULL);
 	if (err < 0)
--=20
1.6.5.6

--_002_DE8DF0795D48FD4CA783C40EC82923358AB2SHSMSX101ccrcorpint_
Content-Type: application/octet-stream;
	name="0010-Xen-update-pcpu-online-offline-logic.patch"
Content-Description: 0010-Xen-update-pcpu-online-offline-logic.patch
Content-Disposition: attachment;
	filename="0010-Xen-update-pcpu-online-offline-logic.patch"; size=4793;
	creation-date="Wed, 14 Dec 2011 15:20:15 GMT";
	modification-date="Wed, 14 Dec 2011 15:03:34 GMT"
Content-Transfer-Encoding: base64

RnJvbSAxZTU5ZDJlYzJmZjkzYjQyYzg2ZDE4YzdjYzk0MzJjYTIxNzJhNzk1IE1vbiBTZXAgMTcg
MDA6MDA6MDAgMjAwMQpGcm9tOiBMaXUgSmluc29uZyA8amluc29uZy5saXVAaW50ZWwuY29tPgpE
YXRlOiBXZWQsIDE0IERlYyAyMDExIDIxOjA2OjExICswODAwClN1YmplY3Q6IFtQQVRDSCAxMC8x
MF0gWGVuOiB1cGRhdGUgcGNwdSBvbmxpbmUvb2ZmbGluZSBsb2dpYwoKVGhpcyBwYXRjaCB1cGRh
dGUgcGNwdSBvbmxpbmUvb2ZmbGluZSBsb2dpYy4KCkl0IGNsb3NlcyBjcHUwJ3MgL3N5cy8uLi4v
eGVuX3BjcHUwL29ubGluZSBhdXRob3JpdHkgdG8gdXNlci4KSXQgYWxzbyBzaW1wbGlmaWVzIHBj
cHUgc3luYyBieSByZW1vdmluZyByZWR1bmRhbnQgbG9naWMuCgpTaWduZWQtb2ZmLWJ5OiBMaXUs
IEppbnNvbmcgPGppbnNvbmcubGl1QGludGVsLmNvbT4KU2lnbmVkLW9mZi1ieTogSmlhbmcsIFl1
bmhvbmcgPHl1bmhvbmcuamlhbmdAaW50ZWwuY29tPgotLS0KIGRyaXZlcnMveGVuL3BjcHUuYyB8
ICAgNzEgKysrKysrKysrKysrKystLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LQogMSBmaWxlcyBjaGFuZ2VkLCAxOSBpbnNlcnRpb25zKCspLCA1MiBkZWxldGlvbnMoLSkKCmRp
ZmYgLS1naXQgYS9kcml2ZXJzL3hlbi9wY3B1LmMgYi9kcml2ZXJzL3hlbi9wY3B1LmMKaW5kZXgg
NmQxYTc3MC4uMWQzMjc4NCAxMDA2NDQKLS0tIGEvZHJpdmVycy94ZW4vcGNwdS5jCisrKyBiL2Ry
aXZlcnMveGVuL3BjcHUuYwpAQCAtMjQsNyArMjQsNiBAQCBzdGF0aWMgUkFXX05PVElGSUVSX0hF
QUQoeGVuX3BjcHVfY2hhaW4pOwogCiBzdHJ1Y3QgeGVuX3BjcHVzIHsKIAlzdHJ1Y3QgbGlzdF9o
ZWFkIGxpc3Q7Ci0JaW50IHByZXNlbnQ7CiB9Owogc3RhdGljIHN0cnVjdCB4ZW5fcGNwdXMgeGVu
X3BjcHVzOwogCkBAIC0xODksOSArMTg4LDEzIEBAIHN0YXRpYyBpbnQgcGNwdV9zeXNkZXZfaW5p
dChzdHJ1Y3QgcGNwdSAqY3B1KQogCQlrZnJlZShjcHUpOwogCQlyZXR1cm4gLTE7CiAJfQotCXN5
c2Rldl9jcmVhdGVfZmlsZSgmY3B1LT5zeXNkZXYsICZhdHRyX29ubGluZSk7CiAJc3lzZGV2X2Ny
ZWF0ZV9maWxlKCZjcHUtPnN5c2RldiwgJmF0dHJfYXBpY19pZCk7CiAJc3lzZGV2X2NyZWF0ZV9m
aWxlKCZjcHUtPnN5c2RldiwgJmF0dHJfYWNwaV9pZCk7CisKKwkvKiBOb3Qgb3BlbiBjcHUwIG9u
bGluZSBhY2Nlc3MgdG8gdXNlciAqLworCWlmIChjcHUtPnN5c2Rldi5pZCkKKwkJc3lzZGV2X2Ny
ZWF0ZV9maWxlKCZjcHUtPnN5c2RldiwgJmF0dHJfb25saW5lKTsKKwogCXJldHVybiAwOwogfQog
CkBAIC0yMzksMTcgKzI0MiwxMCBAQCBzdGF0aWMgc3RydWN0IHBjcHUgKmluaXRfcGNwdShzdHJ1
Y3QgeGVucGZfcGNwdWluZm8gKmluZm8pCiAJcmV0dXJuIHBjcHU7CiB9CiAKLSNkZWZpbmUgUENQ
VV9OT19DSEFOR0UJCQkwCi0jZGVmaW5lIFBDUFVfQURERUQJCQkxCi0jZGVmaW5lIFBDUFVfT05M
SU5FX09GRkxJTkUJCTIKLSNkZWZpbmUgUENQVV9SRU1PVkVECQkJMwogLyoKICAqIENhbGxlciBz
aG91bGQgaG9sZCB0aGUgcGNwdSBsb2NrCi0gKiA8IDA6IFNvbWV0aGluZyB3cm9uZwotICogMDog
Tm8gY2hhbmdlcwotICogPiAwOiBTdGF0ZSBjaGFuZ2VkCiAgKi8KLXN0YXRpYyBzdHJ1Y3QgcGNw
dSAqX3N5bmNfcGNwdShpbnQgY3B1X251bSwgaW50ICptYXhfaWQsIGludCAqcmVzdWx0KQorc3Rh
dGljIGludCBfc3luY19wY3B1KGludCBjcHVfbnVtLCBpbnQgKm1heF9pZCkKIHsKIAlzdHJ1Y3Qg
cGNwdSAqcGNwdSA9IE5VTEw7CiAJc3RydWN0IHhlbnBmX3BjcHVpbmZvICppbmZvOwpAQCAtMjU5
LDE0ICsyNTUsMTIgQEAgc3RhdGljIHN0cnVjdCBwY3B1ICpfc3luY19wY3B1KGludCBjcHVfbnVt
LCBpbnQgKm1heF9pZCwgaW50ICpyZXN1bHQpCiAJfTsKIAlpbnQgcmV0OwogCi0JKnJlc3VsdCA9
IC0xOwotCiAJaW5mbyA9ICZvcC51LnBjcHVfaW5mbzsKIAlpbmZvLT54ZW5fY3B1aWQgPSBjcHVf
bnVtOwogCiAJcmV0ID0gSFlQRVJWSVNPUl9kb20wX29wKCZvcCk7CiAJaWYgKHJldCkKLQkJcmV0
dXJuIE5VTEw7CisJCXJldHVybiAtMTsKIAogCWlmIChtYXhfaWQpCiAJCSptYXhfaWQgPSBvcC51
LnBjcHVfaW5mby5tYXhfcHJlc2VudDsKQEAgLTI3NSwyOCArMjY5LDI0IEBAIHN0YXRpYyBzdHJ1
Y3QgcGNwdSAqX3N5bmNfcGNwdShpbnQgY3B1X251bSwgaW50ICptYXhfaWQsIGludCAqcmVzdWx0
KQogCiAJaWYgKGluZm8tPmZsYWdzICYgWEVOX1BDUFVfRkxBR1NfSU5WQUxJRCkgewogCQkvKiBU
aGUgcGNwdSBoYXMgYmVlbiByZW1vdmVkICovCi0JCSpyZXN1bHQgPSBQQ1BVX05PX0NIQU5HRTsK
IAkJaWYgKHBjcHUpIHsKIAkJCXJhd19ub3RpZmllcl9jYWxsX2NoYWluKCZ4ZW5fcGNwdV9jaGFp
biwKIAkJCSAgWEVOX1BDUFVfUkVNT1ZFLAogCQkJICAodm9pZCAqKShsb25nKXBjcHUtPnhlbl9p
ZCk7CiAJCQl4ZW5fcGNwdV9mcmVlKHBjcHUpOwotCQkJKnJlc3VsdCA9IFBDUFVfUkVNT1ZFRDsK
IAkJfQotCQlyZXR1cm4gTlVMTDsKKwkJcmV0dXJuIDA7CiAJfQogCiAKIAlpZiAoIXBjcHUpIHsK
LQkJKnJlc3VsdCA9IFBDUFVfQURERUQ7CiAJCXBjcHUgPSBpbml0X3BjcHUoaW5mbyk7CiAJCWlm
IChwY3B1ID09IE5VTEwpIHsKIAkJCXByaW50ayhLRVJOX1dBUk5JTkcgIkZhaWxlZCB0byBpbml0
IHBjcHUgJXhcbiIsCiAJCQkgIGluZm8tPnhlbl9jcHVpZCk7Ci0JCQkgICpyZXN1bHQgPSAtMTsK
KwkJCXJldHVybiAtMTsKIAkJfQogCX0gZWxzZSB7Ci0JCSpyZXN1bHQgPSBQQ1BVX05PX0NIQU5H
RTsKIAkJLyoKIAkJICogT2xkIFBDUFUgaXMgcmVwbGFjZWQgd2l0aCBhIG5ldyBwY3B1LCB0aGlz
IG1lYW5zCiAJCSAqIHNldmVyYWwgdmlycSBpcyBtaXNzZWQsIHdpbGwgaXQgaGFwcGVuPwpAQCAt
MzA3LDEwICsyOTcsMTAgQEAgc3RhdGljIHN0cnVjdCBwY3B1ICpfc3luY19wY3B1KGludCBjcHVf
bnVtLCBpbnQgKm1heF9pZCwgaW50ICpyZXN1bHQpCiAJCQlwY3B1LT5hcGljX2lkID0gaW5mby0+
YXBpY19pZDsKIAkJCXBjcHUtPmFjcGlfaWQgPSBpbmZvLT5hY3BpX2lkOwogCQl9Ci0JCWlmICh4
ZW5fcGNwdV9vbmxpbmVfY2hlY2soaW5mbywgcGNwdSkpCi0JCQkqcmVzdWx0ID0gUENQVV9PTkxJ
TkVfT0ZGTElORTsKKwkJeGVuX3BjcHVfb25saW5lX2NoZWNrKGluZm8sIHBjcHUpOwogCX0KLQly
ZXR1cm4gcGNwdTsKKworCXJldHVybiAwOwogfQogCiBpbnQgeGVuX3BjcHVfaW5kZXgodWludDMy
X3QgaWQsIGludCBpc19hY3BpaWQpCkBAIC0zNTMsNTAgKzM0MywyNyBAQCBzdGF0aWMgaW50IHhl
bl9zeW5jX3BjcHVzKHZvaWQpCiAJLyoKIAkgKiBCb290IGNwdSBhbHdheXMgaGF2ZSBjcHVfaWQg
MCBpbiB4ZW4KIAkgKi8KLQlpbnQgY3B1X251bSA9IDAsIG1heF9pZCA9IDAsIHJlc3VsdCA9IDAs
IHByZXNlbnQgPSAwOworCWludCBjcHVfbnVtID0gMCwgbWF4X2lkID0gMCwgcmV0ID0gMDsKIAlz
dHJ1Y3QgbGlzdF9oZWFkICplbGVtLCAqdG1wOwogCXN0cnVjdCBwY3B1ICpwY3B1OwogCiAJZ2V0
X3BjcHVfbG9jaygpOwogCi0Jd2hpbGUgKChyZXN1bHQgPj0gMCkgJiYgKGNwdV9udW0gPD0gbWF4
X2lkKSkgewotCQlwY3B1ID0gX3N5bmNfcGNwdShjcHVfbnVtLCAmbWF4X2lkLCAmcmVzdWx0KTsK
LQotCQlwcmludGsoS0VSTl9ERUJVRyAic3luYyBjcHUgJXggZ2V0IHJlc3VsdCAleCBtYXhfaWQg
JXhcbiIsCi0JCQljcHVfbnVtLCByZXN1bHQsIG1heF9pZCk7Ci0KLQkJc3dpdGNoIChyZXN1bHQp
CXsKLQkJY2FzZSBQQ1BVX05PX0NIQU5HRToKLQkJCWlmIChwY3B1KQotCQkJCXByZXNlbnQrKzsK
LQkJCWJyZWFrOwotCQljYXNlIFBDUFVfQURERUQ6Ci0JCWNhc2UgUENQVV9PTkxJTkVfT0ZGTElO
RToKLQkJCXByZXNlbnQrKzsKLQkJY2FzZSBQQ1BVX1JFTU9WRUQ6Ci0JCQlicmVhazsKLQkJZGVm
YXVsdDoKLQkJCXByaW50ayhLRVJOX1dBUk5JTkcgIkZhaWxlZCB0byBzeW5jIHBjcHUgJXhcbiIs
Ci0JCQkgIGNwdV9udW0pOwotCQkJYnJlYWs7Ci0KLQkJfQorCXdoaWxlICghcmV0ICYmIChjcHVf
bnVtIDw9IG1heF9pZCkpIHsKKwkJcmV0ID0gX3N5bmNfcGNwdShjcHVfbnVtLCAmbWF4X2lkKTsK
IAkJY3B1X251bSsrOwogCX0KIAotCWlmIChyZXN1bHQgPCAwKSB7CisJaWYgKHJldCA8IDApIHsK
IAkJbGlzdF9mb3JfZWFjaF9zYWZlKGVsZW0sIHRtcCwgJnhlbl9wY3B1cy5saXN0KSB7CiAJCQlw
Y3B1ID0gbGlzdF9lbnRyeShlbGVtLCBzdHJ1Y3QgcGNwdSwgcGNwdV9saXN0KTsKIAkJCXhlbl9w
Y3B1X2ZyZWUocGNwdSk7CiAJCX0KLQkJcHJlc2VudCA9IDA7CiAJfQogCi0JeGVuX3BjcHVzLnBy
ZXNlbnQgPSBwcmVzZW50OwotCiAJcHV0X3BjcHVfbG9jaygpOwogCi0JcmV0dXJuIDA7CisJcmV0
dXJuIHJldDsKIH0KIAogc3RhdGljIHZvaWQgeGVuX3BjcHVfZHBjKHN0cnVjdCB3b3JrX3N0cnVj
dCAqd29yaykKQEAgLTQzNiwxMCArNDAzLDEwIEBAIHN0YXRpYyBpbnQgX19pbml0IHhlbl9wY3B1
X2luaXQodm9pZCkKIAl9CiAKIAlJTklUX0xJU1RfSEVBRCgmeGVuX3BjcHVzLmxpc3QpOwotCXhl
bl9wY3B1cy5wcmVzZW50ID0gMDsKIAogCXhlbl9zeW5jX3BjcHVzKCk7Ci0JaWYgKHhlbl9wY3B1
cy5wcmVzZW50ID4gMCkKKworCWlmICghbGlzdF9lbXB0eSgmeGVuX3BjcHVzLmxpc3QpKQogCQll
cnIgPSBiaW5kX3ZpcnFfdG9faXJxaGFuZGxlcihWSVJRX1BDUFVfU1RBVEUsCiAJCQkwLCB4ZW5f
cGNwdV9pbnRlcnJ1cHQsIDAsICJwY3B1IiwgTlVMTCk7CiAJaWYgKGVyciA8IDApCi0tIAoxLjYu
NS42Cgo=

--_002_DE8DF0795D48FD4CA783C40EC82923358AB2SHSMSX101ccrcorpint_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--_002_DE8DF0795D48FD4CA783C40EC82923358AB2SHSMSX101ccrcorpint_--


From xen-devel-bounces@lists.xensource.com Thu Dec 22 10:10:50 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 Dec 2011 10: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.xensource.com>)
	id 1Rdfbm-00067n-IW; Thu, 22 Dec 2011 10:10:42 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1Rdfbl-00066X-28
	for xen-devel@lists.xensource.com; Thu, 22 Dec 2011 10:10:41 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1324548633!6532287!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMjkwMjgz\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4124 invoked from network); 22 Dec 2011 10:10:34 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-6.tower-174.messagelabs.com with SMTP;
	22 Dec 2011 10:10:34 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga101.jf.intel.com with ESMTP; 22 Dec 2011 02:10:32 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.67,352,1309762800"; d="scan'208,223";a="89284284"
Received: from pgsmsx602.gar.corp.intel.com ([10.221.43.81])
	by orsmga001.jf.intel.com with ESMTP; 22 Dec 2011 02:10:31 -0800
Received: from pgsmsx101.gar.corp.intel.com (10.221.44.78) by
	pgsmsx602.gar.corp.intel.com (10.221.43.81) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Thu, 22 Dec 2011 18:09:21 +0800
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	PGSMSX101.gar.corp.intel.com (10.221.44.78) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Thu, 22 Dec 2011 18:09:20 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.38]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.199]) with mapi id
	14.01.0355.002; Thu, 22 Dec 2011 18:09:20 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: "konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Thread-Topic: [PATCH 09/10] xen/acpi: Change Cx notify and add PPC handle
Thread-Index: AczAkcRwj5TL8WPVTsiYF9vCdqIbIg==
Date: Thu, 22 Dec 2011 10:09:19 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC82923358AA0@SHSMSX101.ccr.corp.intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
Content-Type: multipart/mixed;
	boundary="_002_DE8DF0795D48FD4CA783C40EC82923358AA0SHSMSX101ccrcorpint_"
MIME-Version: 1.0
Cc: "Jiang, Yunhong" <yunhong.jiang@intel.com>,
	"jeremy.fitzhardinge@citrix.com" <jeremy.fitzhardinge@citrix.com>
Subject: [Xen-devel] [PATCH 09/10] xen/acpi: Change Cx notify and add PPC
	handle
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--_002_DE8DF0795D48FD4CA783C40EC82923358AA0SHSMSX101ccrcorpint_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

>From ca403566e922dde51e8809d7489337be4a55adfc Mon Sep 17 00:00:00 2001
From: Liu Jinsong <jinsong.liu@intel.com>
Date: Wed, 14 Dec 2011 15:59:02 +0800
Subject: [PATCH 09/10] xen/acpi: Change Cx notify and add PPC handle

This patch update Xen Cx notify.
Current Cx notify has 2 potential trigger points w/ some logically redundan=
t.
We remove the Cx notify point which is outside __xen_acpi_processor_add,
merging its logic to the Cx notify point inside __xen_acpi_processor_add.
This would more clean, as what native Cx did.

This patch also add Xen PPC handle when cpu hotadd.

Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
---
 drivers/acpi/processor_xen.c |  103 +++++++++++++++++++++++---------------=
----
 1 files changed, 57 insertions(+), 46 deletions(-)

diff --git a/drivers/acpi/processor_xen.c b/drivers/acpi/processor_xen.c
index 3af1f73..083e2b1 100644
--- a/drivers/acpi/processor_xen.c
+++ b/drivers/acpi/processor_xen.c
@@ -283,6 +283,59 @@ static int xen_acpi_processor_get_info(struct acpi_dev=
ice *device)
 	return 0;
 }
=20
+static int xen_acpi_processor_get_platform_limit(struct acpi_processor *pr=
)
+{
+        acpi_status status =3D 0;
+        unsigned long long ppc =3D 0;
+
+        if (!pr)
+                return -EINVAL;
+
+        /*
+         * _PPC indicates the maximum state currently supported by the pla=
tform
+         * (e.g. 0 =3D states 0..n; 1 =3D states 1..n; etc.
+         */
+        status =3D acpi_evaluate_integer(pr->handle, "_PPC", NULL, &ppc);
+
+        if (ACPI_FAILURE(status) && status !=3D AE_NOT_FOUND) {
+                ACPI_EXCEPTION((AE_INFO, status, "Evaluating _PPC"));
+                return -ENODEV;
+        }
+
+        pr->performance_platform_limit =3D (int)ppc;
+
+        return 0;
+}
+
+static int xen_acpi_processor_ppc_has_changed(struct acpi_processor *pr)
+{
+	int ret;
+
+	ret =3D xen_acpi_processor_get_platform_limit(pr);
+
+	if (ret < 0)
+		return ret;
+	else
+		return processor_cntl_xen_notify(pr,
+			PROCESSOR_PM_CHANGE, PM_TYPE_PERF);
+}
+
+static void __cpuinit xen_acpi_processor_power_init(struct acpi_processor =
*pr,
+			      struct acpi_device *device)
+{
+	if (likely(!pr->flags.power_setup_done)) {
+		/* reset idle boot option which we don't care */
+		boot_option_idle_override =3D IDLE_NO_OVERRIDE;
+		acpi_processor_power_init(pr, device);
+		/* set to IDLE_HALT for trapping into Xen */
+		boot_option_idle_override =3D IDLE_HALT;
+
+		if (pr->flags.power)
+			processor_cntl_xen_notify(pr,
+					PROCESSOR_PM_INIT, PM_TYPE_IDLE);
+	}
+}
+
 static int __cpuinit __xen_acpi_processor_add(struct acpi_device *device)
 {
 	struct acpi_processor *pr =3D NULL;
@@ -339,14 +392,12 @@ static int __cpuinit __xen_acpi_processor_add(struct =
acpi_device *device)
 	}
=20
 #ifdef CONFIG_CPU_FREQ
-	acpi_processor_ppc_has_changed(pr, 0);
+	xen_acpi_processor_ppc_has_changed(pr);
 #endif
 	acpi_processor_get_throttling_info(pr);
 	acpi_processor_get_limit_info(pr);
=20
-
-	if (cpuidle_get_driver() =3D=3D &acpi_idle_driver)
-		acpi_processor_power_init(pr, device);
+	xen_acpi_processor_power_init(pr, device);
=20
 	pr->cdev =3D thermal_cooling_device_register("Processor", device,
 						&processor_cooling_ops);
@@ -400,48 +451,8 @@ static int __cpuinit xen_acpi_processor_add(struct acp=
i_device *device)
 	if (!pr)
 		return -EINVAL;
=20
-	if (pr->id =3D=3D -1) {
-		int device_declaration;
-		int apic_id =3D -1;
-
-		if (!strcmp(acpi_device_hid(device), ACPI_PROCESSOR_OBJECT_HID))
-			device_declaration =3D 0;
-		else
-			device_declaration =3D 1;
-
-		apic_id =3D acpi_get_cpuid(pr->handle,
-			device_declaration, pr->acpi_id);
-		if (apic_id =3D=3D -1) {
-			/* Processor is not present in MADT table */
-			return 0;
-		}
-
-		/*
-		 * It's possible to have pr->id as '-1' even when it's actually
-		 * present in MADT table, e.g. due to limiting dom0 max vcpus
-		 * less than physical present number. In such case we still want
-		 * to parse ACPI processor object information, so mimic the
-		 * pr->id to CPU-0. This should be safe because we only care
-		 * about raw ACPI information, which only relies on pr->acpi_id.
-		 * For other information relying on pr->id and gathered through
-		 * SMP function call, it's safe to let them run on CPU-0 since
-		 * underlying Xen will collect them. Only a valid pr->id can
-		 * make later invocations forward progress.
-		 */
-		pr->id =3D 0;
-	}
-
-	if (likely(!pr->flags.power_setup_done)) {
-		/* reset idle boot option which we don't care */
-		boot_option_idle_override =3D IDLE_NO_OVERRIDE;
-		acpi_processor_power_init(pr, device);
-		/* set to IDLE_HALT for trapping into Xen */
-		boot_option_idle_override =3D IDLE_HALT;
-
-		if (pr->flags.power)
-			processor_cntl_xen_notify(pr,
-					PROCESSOR_PM_INIT, PM_TYPE_IDLE);
-	}
+	if (pr->id =3D=3D -1)
+		return 0;
=20
 #ifdef CONFIG_CPU_FREQ
 	if (likely(!pr->performance))
--=20
1.6.5.6

--_002_DE8DF0795D48FD4CA783C40EC82923358AA0SHSMSX101ccrcorpint_
Content-Type: application/octet-stream;
	name="0009-xen-acpi-Change-Cx-notify-and-add-PPC-handle.patch"
Content-Description: 0009-xen-acpi-Change-Cx-notify-and-add-PPC-handle.patch
Content-Disposition: attachment;
	filename="0009-xen-acpi-Change-Cx-notify-and-add-PPC-handle.patch";
	size=4832; creation-date="Wed, 14 Dec 2011 15:20:15 GMT";
	modification-date="Wed, 14 Dec 2011 15:03:34 GMT"
Content-Transfer-Encoding: base64

RnJvbSBjYTQwMzU2NmU5MjJkZGU1MWU4ODA5ZDc0ODkzMzdiZTRhNTVhZGZjIE1vbiBTZXAgMTcg
MDA6MDA6MDAgMjAwMQpGcm9tOiBMaXUgSmluc29uZyA8amluc29uZy5saXVAaW50ZWwuY29tPgpE
YXRlOiBXZWQsIDE0IERlYyAyMDExIDE1OjU5OjAyICswODAwClN1YmplY3Q6IFtQQVRDSCAwOS8x
MF0geGVuL2FjcGk6IENoYW5nZSBDeCBub3RpZnkgYW5kIGFkZCBQUEMgaGFuZGxlCgpUaGlzIHBh
dGNoIHVwZGF0ZSBYZW4gQ3ggbm90aWZ5LgpDdXJyZW50IEN4IG5vdGlmeSBoYXMgMiBwb3RlbnRp
YWwgdHJpZ2dlciBwb2ludHMgdy8gc29tZSBsb2dpY2FsbHkgcmVkdW5kYW50LgpXZSByZW1vdmUg
dGhlIEN4IG5vdGlmeSBwb2ludCB3aGljaCBpcyBvdXRzaWRlIF9feGVuX2FjcGlfcHJvY2Vzc29y
X2FkZCwKbWVyZ2luZyBpdHMgbG9naWMgdG8gdGhlIEN4IG5vdGlmeSBwb2ludCBpbnNpZGUgX194
ZW5fYWNwaV9wcm9jZXNzb3JfYWRkLgpUaGlzIHdvdWxkIG1vcmUgY2xlYW4sIGFzIHdoYXQgbmF0
aXZlIEN4IGRpZC4KClRoaXMgcGF0Y2ggYWxzbyBhZGQgWGVuIFBQQyBoYW5kbGUgd2hlbiBjcHUg
aG90YWRkLgoKU2lnbmVkLW9mZi1ieTogTGl1LCBKaW5zb25nIDxqaW5zb25nLmxpdUBpbnRlbC5j
b20+Ci0tLQogZHJpdmVycy9hY3BpL3Byb2Nlc3Nvcl94ZW4uYyB8ICAxMDMgKysrKysrKysrKysr
KysrKysrKysrKystLS0tLS0tLS0tLS0tLS0tLS0tCiAxIGZpbGVzIGNoYW5nZWQsIDU3IGluc2Vy
dGlvbnMoKyksIDQ2IGRlbGV0aW9ucygtKQoKZGlmZiAtLWdpdCBhL2RyaXZlcnMvYWNwaS9wcm9j
ZXNzb3JfeGVuLmMgYi9kcml2ZXJzL2FjcGkvcHJvY2Vzc29yX3hlbi5jCmluZGV4IDNhZjFmNzMu
LjA4M2UyYjEgMTAwNjQ0Ci0tLSBhL2RyaXZlcnMvYWNwaS9wcm9jZXNzb3JfeGVuLmMKKysrIGIv
ZHJpdmVycy9hY3BpL3Byb2Nlc3Nvcl94ZW4uYwpAQCAtMjgzLDYgKzI4Myw1OSBAQCBzdGF0aWMg
aW50IHhlbl9hY3BpX3Byb2Nlc3Nvcl9nZXRfaW5mbyhzdHJ1Y3QgYWNwaV9kZXZpY2UgKmRldmlj
ZSkKIAlyZXR1cm4gMDsKIH0KIAorc3RhdGljIGludCB4ZW5fYWNwaV9wcm9jZXNzb3JfZ2V0X3Bs
YXRmb3JtX2xpbWl0KHN0cnVjdCBhY3BpX3Byb2Nlc3NvciAqcHIpCit7CisgICAgICAgIGFjcGlf
c3RhdHVzIHN0YXR1cyA9IDA7CisgICAgICAgIHVuc2lnbmVkIGxvbmcgbG9uZyBwcGMgPSAwOwor
CisgICAgICAgIGlmICghcHIpCisgICAgICAgICAgICAgICAgcmV0dXJuIC1FSU5WQUw7CisKKyAg
ICAgICAgLyoKKyAgICAgICAgICogX1BQQyBpbmRpY2F0ZXMgdGhlIG1heGltdW0gc3RhdGUgY3Vy
cmVudGx5IHN1cHBvcnRlZCBieSB0aGUgcGxhdGZvcm0KKyAgICAgICAgICogKGUuZy4gMCA9IHN0
YXRlcyAwLi5uOyAxID0gc3RhdGVzIDEuLm47IGV0Yy4KKyAgICAgICAgICovCisgICAgICAgIHN0
YXR1cyA9IGFjcGlfZXZhbHVhdGVfaW50ZWdlcihwci0+aGFuZGxlLCAiX1BQQyIsIE5VTEwsICZw
cGMpOworCisgICAgICAgIGlmIChBQ1BJX0ZBSUxVUkUoc3RhdHVzKSAmJiBzdGF0dXMgIT0gQUVf
Tk9UX0ZPVU5EKSB7CisgICAgICAgICAgICAgICAgQUNQSV9FWENFUFRJT04oKEFFX0lORk8sIHN0
YXR1cywgIkV2YWx1YXRpbmcgX1BQQyIpKTsKKyAgICAgICAgICAgICAgICByZXR1cm4gLUVOT0RF
VjsKKyAgICAgICAgfQorCisgICAgICAgIHByLT5wZXJmb3JtYW5jZV9wbGF0Zm9ybV9saW1pdCA9
IChpbnQpcHBjOworCisgICAgICAgIHJldHVybiAwOworfQorCitzdGF0aWMgaW50IHhlbl9hY3Bp
X3Byb2Nlc3Nvcl9wcGNfaGFzX2NoYW5nZWQoc3RydWN0IGFjcGlfcHJvY2Vzc29yICpwcikKK3sK
KwlpbnQgcmV0OworCisJcmV0ID0geGVuX2FjcGlfcHJvY2Vzc29yX2dldF9wbGF0Zm9ybV9saW1p
dChwcik7CisKKwlpZiAocmV0IDwgMCkKKwkJcmV0dXJuIHJldDsKKwllbHNlCisJCXJldHVybiBw
cm9jZXNzb3JfY250bF94ZW5fbm90aWZ5KHByLAorCQkJUFJPQ0VTU09SX1BNX0NIQU5HRSwgUE1f
VFlQRV9QRVJGKTsKK30KKworc3RhdGljIHZvaWQgX19jcHVpbml0IHhlbl9hY3BpX3Byb2Nlc3Nv
cl9wb3dlcl9pbml0KHN0cnVjdCBhY3BpX3Byb2Nlc3NvciAqcHIsCisJCQkgICAgICBzdHJ1Y3Qg
YWNwaV9kZXZpY2UgKmRldmljZSkKK3sKKwlpZiAobGlrZWx5KCFwci0+ZmxhZ3MucG93ZXJfc2V0
dXBfZG9uZSkpIHsKKwkJLyogcmVzZXQgaWRsZSBib290IG9wdGlvbiB3aGljaCB3ZSBkb24ndCBj
YXJlICovCisJCWJvb3Rfb3B0aW9uX2lkbGVfb3ZlcnJpZGUgPSBJRExFX05PX09WRVJSSURFOwor
CQlhY3BpX3Byb2Nlc3Nvcl9wb3dlcl9pbml0KHByLCBkZXZpY2UpOworCQkvKiBzZXQgdG8gSURM
RV9IQUxUIGZvciB0cmFwcGluZyBpbnRvIFhlbiAqLworCQlib290X29wdGlvbl9pZGxlX292ZXJy
aWRlID0gSURMRV9IQUxUOworCisJCWlmIChwci0+ZmxhZ3MucG93ZXIpCisJCQlwcm9jZXNzb3Jf
Y250bF94ZW5fbm90aWZ5KHByLAorCQkJCQlQUk9DRVNTT1JfUE1fSU5JVCwgUE1fVFlQRV9JRExF
KTsKKwl9Cit9CisKIHN0YXRpYyBpbnQgX19jcHVpbml0IF9feGVuX2FjcGlfcHJvY2Vzc29yX2Fk
ZChzdHJ1Y3QgYWNwaV9kZXZpY2UgKmRldmljZSkKIHsKIAlzdHJ1Y3QgYWNwaV9wcm9jZXNzb3Ig
KnByID0gTlVMTDsKQEAgLTMzOSwxNCArMzkyLDEyIEBAIHN0YXRpYyBpbnQgX19jcHVpbml0IF9f
eGVuX2FjcGlfcHJvY2Vzc29yX2FkZChzdHJ1Y3QgYWNwaV9kZXZpY2UgKmRldmljZSkKIAl9CiAK
ICNpZmRlZiBDT05GSUdfQ1BVX0ZSRVEKLQlhY3BpX3Byb2Nlc3Nvcl9wcGNfaGFzX2NoYW5nZWQo
cHIsIDApOworCXhlbl9hY3BpX3Byb2Nlc3Nvcl9wcGNfaGFzX2NoYW5nZWQocHIpOwogI2VuZGlm
CiAJYWNwaV9wcm9jZXNzb3JfZ2V0X3Rocm90dGxpbmdfaW5mbyhwcik7CiAJYWNwaV9wcm9jZXNz
b3JfZ2V0X2xpbWl0X2luZm8ocHIpOwogCi0KLQlpZiAoY3B1aWRsZV9nZXRfZHJpdmVyKCkgPT0g
JmFjcGlfaWRsZV9kcml2ZXIpCi0JCWFjcGlfcHJvY2Vzc29yX3Bvd2VyX2luaXQocHIsIGRldmlj
ZSk7CisJeGVuX2FjcGlfcHJvY2Vzc29yX3Bvd2VyX2luaXQocHIsIGRldmljZSk7CiAKIAlwci0+
Y2RldiA9IHRoZXJtYWxfY29vbGluZ19kZXZpY2VfcmVnaXN0ZXIoIlByb2Nlc3NvciIsIGRldmlj
ZSwKIAkJCQkJCSZwcm9jZXNzb3JfY29vbGluZ19vcHMpOwpAQCAtNDAwLDQ4ICs0NTEsOCBAQCBz
dGF0aWMgaW50IF9fY3B1aW5pdCB4ZW5fYWNwaV9wcm9jZXNzb3JfYWRkKHN0cnVjdCBhY3BpX2Rl
dmljZSAqZGV2aWNlKQogCWlmICghcHIpCiAJCXJldHVybiAtRUlOVkFMOwogCi0JaWYgKHByLT5p
ZCA9PSAtMSkgewotCQlpbnQgZGV2aWNlX2RlY2xhcmF0aW9uOwotCQlpbnQgYXBpY19pZCA9IC0x
OwotCi0JCWlmICghc3RyY21wKGFjcGlfZGV2aWNlX2hpZChkZXZpY2UpLCBBQ1BJX1BST0NFU1NP
Ul9PQkpFQ1RfSElEKSkKLQkJCWRldmljZV9kZWNsYXJhdGlvbiA9IDA7Ci0JCWVsc2UKLQkJCWRl
dmljZV9kZWNsYXJhdGlvbiA9IDE7Ci0KLQkJYXBpY19pZCA9IGFjcGlfZ2V0X2NwdWlkKHByLT5o
YW5kbGUsCi0JCQlkZXZpY2VfZGVjbGFyYXRpb24sIHByLT5hY3BpX2lkKTsKLQkJaWYgKGFwaWNf
aWQgPT0gLTEpIHsKLQkJCS8qIFByb2Nlc3NvciBpcyBub3QgcHJlc2VudCBpbiBNQURUIHRhYmxl
ICovCi0JCQlyZXR1cm4gMDsKLQkJfQotCi0JCS8qCi0JCSAqIEl0J3MgcG9zc2libGUgdG8gaGF2
ZSBwci0+aWQgYXMgJy0xJyBldmVuIHdoZW4gaXQncyBhY3R1YWxseQotCQkgKiBwcmVzZW50IGlu
IE1BRFQgdGFibGUsIGUuZy4gZHVlIHRvIGxpbWl0aW5nIGRvbTAgbWF4IHZjcHVzCi0JCSAqIGxl
c3MgdGhhbiBwaHlzaWNhbCBwcmVzZW50IG51bWJlci4gSW4gc3VjaCBjYXNlIHdlIHN0aWxsIHdh
bnQKLQkJICogdG8gcGFyc2UgQUNQSSBwcm9jZXNzb3Igb2JqZWN0IGluZm9ybWF0aW9uLCBzbyBt
aW1pYyB0aGUKLQkJICogcHItPmlkIHRvIENQVS0wLiBUaGlzIHNob3VsZCBiZSBzYWZlIGJlY2F1
c2Ugd2Ugb25seSBjYXJlCi0JCSAqIGFib3V0IHJhdyBBQ1BJIGluZm9ybWF0aW9uLCB3aGljaCBv
bmx5IHJlbGllcyBvbiBwci0+YWNwaV9pZC4KLQkJICogRm9yIG90aGVyIGluZm9ybWF0aW9uIHJl
bHlpbmcgb24gcHItPmlkIGFuZCBnYXRoZXJlZCB0aHJvdWdoCi0JCSAqIFNNUCBmdW5jdGlvbiBj
YWxsLCBpdCdzIHNhZmUgdG8gbGV0IHRoZW0gcnVuIG9uIENQVS0wIHNpbmNlCi0JCSAqIHVuZGVy
bHlpbmcgWGVuIHdpbGwgY29sbGVjdCB0aGVtLiBPbmx5IGEgdmFsaWQgcHItPmlkIGNhbgotCQkg
KiBtYWtlIGxhdGVyIGludm9jYXRpb25zIGZvcndhcmQgcHJvZ3Jlc3MuCi0JCSAqLwotCQlwci0+
aWQgPSAwOwotCX0KLQotCWlmIChsaWtlbHkoIXByLT5mbGFncy5wb3dlcl9zZXR1cF9kb25lKSkg
ewotCQkvKiByZXNldCBpZGxlIGJvb3Qgb3B0aW9uIHdoaWNoIHdlIGRvbid0IGNhcmUgKi8KLQkJ
Ym9vdF9vcHRpb25faWRsZV9vdmVycmlkZSA9IElETEVfTk9fT1ZFUlJJREU7Ci0JCWFjcGlfcHJv
Y2Vzc29yX3Bvd2VyX2luaXQocHIsIGRldmljZSk7Ci0JCS8qIHNldCB0byBJRExFX0hBTFQgZm9y
IHRyYXBwaW5nIGludG8gWGVuICovCi0JCWJvb3Rfb3B0aW9uX2lkbGVfb3ZlcnJpZGUgPSBJRExF
X0hBTFQ7Ci0KLQkJaWYgKHByLT5mbGFncy5wb3dlcikKLQkJCXByb2Nlc3Nvcl9jbnRsX3hlbl9u
b3RpZnkocHIsCi0JCQkJCVBST0NFU1NPUl9QTV9JTklULCBQTV9UWVBFX0lETEUpOwotCX0KKwlp
ZiAocHItPmlkID09IC0xKQorCQlyZXR1cm4gMDsKIAogI2lmZGVmIENPTkZJR19DUFVfRlJFUQog
CWlmIChsaWtlbHkoIXByLT5wZXJmb3JtYW5jZSkpCi0tIAoxLjYuNS42Cgo=

--_002_DE8DF0795D48FD4CA783C40EC82923358AA0SHSMSX101ccrcorpint_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--_002_DE8DF0795D48FD4CA783C40EC82923358AA0SHSMSX101ccrcorpint_--


From xen-devel-bounces@lists.xensource.com Thu Dec 22 10:10:50 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 Dec 2011 10: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.xensource.com>)
	id 1Rdfbm-00067n-IW; Thu, 22 Dec 2011 10:10:42 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1Rdfbl-00066X-28
	for xen-devel@lists.xensource.com; Thu, 22 Dec 2011 10:10:41 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1324548633!6532287!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMjkwMjgz\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4124 invoked from network); 22 Dec 2011 10:10:34 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-6.tower-174.messagelabs.com with SMTP;
	22 Dec 2011 10:10:34 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga101.jf.intel.com with ESMTP; 22 Dec 2011 02:10:32 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.67,352,1309762800"; d="scan'208,223";a="89284284"
Received: from pgsmsx602.gar.corp.intel.com ([10.221.43.81])
	by orsmga001.jf.intel.com with ESMTP; 22 Dec 2011 02:10:31 -0800
Received: from pgsmsx101.gar.corp.intel.com (10.221.44.78) by
	pgsmsx602.gar.corp.intel.com (10.221.43.81) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Thu, 22 Dec 2011 18:09:21 +0800
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	PGSMSX101.gar.corp.intel.com (10.221.44.78) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Thu, 22 Dec 2011 18:09:20 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.38]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.199]) with mapi id
	14.01.0355.002; Thu, 22 Dec 2011 18:09:20 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: "konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Thread-Topic: [PATCH 09/10] xen/acpi: Change Cx notify and add PPC handle
Thread-Index: AczAkcRwj5TL8WPVTsiYF9vCdqIbIg==
Date: Thu, 22 Dec 2011 10:09:19 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC82923358AA0@SHSMSX101.ccr.corp.intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
Content-Type: multipart/mixed;
	boundary="_002_DE8DF0795D48FD4CA783C40EC82923358AA0SHSMSX101ccrcorpint_"
MIME-Version: 1.0
Cc: "Jiang, Yunhong" <yunhong.jiang@intel.com>,
	"jeremy.fitzhardinge@citrix.com" <jeremy.fitzhardinge@citrix.com>
Subject: [Xen-devel] [PATCH 09/10] xen/acpi: Change Cx notify and add PPC
	handle
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--_002_DE8DF0795D48FD4CA783C40EC82923358AA0SHSMSX101ccrcorpint_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

>From ca403566e922dde51e8809d7489337be4a55adfc Mon Sep 17 00:00:00 2001
From: Liu Jinsong <jinsong.liu@intel.com>
Date: Wed, 14 Dec 2011 15:59:02 +0800
Subject: [PATCH 09/10] xen/acpi: Change Cx notify and add PPC handle

This patch update Xen Cx notify.
Current Cx notify has 2 potential trigger points w/ some logically redundan=
t.
We remove the Cx notify point which is outside __xen_acpi_processor_add,
merging its logic to the Cx notify point inside __xen_acpi_processor_add.
This would more clean, as what native Cx did.

This patch also add Xen PPC handle when cpu hotadd.

Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
---
 drivers/acpi/processor_xen.c |  103 +++++++++++++++++++++++---------------=
----
 1 files changed, 57 insertions(+), 46 deletions(-)

diff --git a/drivers/acpi/processor_xen.c b/drivers/acpi/processor_xen.c
index 3af1f73..083e2b1 100644
--- a/drivers/acpi/processor_xen.c
+++ b/drivers/acpi/processor_xen.c
@@ -283,6 +283,59 @@ static int xen_acpi_processor_get_info(struct acpi_dev=
ice *device)
 	return 0;
 }
=20
+static int xen_acpi_processor_get_platform_limit(struct acpi_processor *pr=
)
+{
+        acpi_status status =3D 0;
+        unsigned long long ppc =3D 0;
+
+        if (!pr)
+                return -EINVAL;
+
+        /*
+         * _PPC indicates the maximum state currently supported by the pla=
tform
+         * (e.g. 0 =3D states 0..n; 1 =3D states 1..n; etc.
+         */
+        status =3D acpi_evaluate_integer(pr->handle, "_PPC", NULL, &ppc);
+
+        if (ACPI_FAILURE(status) && status !=3D AE_NOT_FOUND) {
+                ACPI_EXCEPTION((AE_INFO, status, "Evaluating _PPC"));
+                return -ENODEV;
+        }
+
+        pr->performance_platform_limit =3D (int)ppc;
+
+        return 0;
+}
+
+static int xen_acpi_processor_ppc_has_changed(struct acpi_processor *pr)
+{
+	int ret;
+
+	ret =3D xen_acpi_processor_get_platform_limit(pr);
+
+	if (ret < 0)
+		return ret;
+	else
+		return processor_cntl_xen_notify(pr,
+			PROCESSOR_PM_CHANGE, PM_TYPE_PERF);
+}
+
+static void __cpuinit xen_acpi_processor_power_init(struct acpi_processor =
*pr,
+			      struct acpi_device *device)
+{
+	if (likely(!pr->flags.power_setup_done)) {
+		/* reset idle boot option which we don't care */
+		boot_option_idle_override =3D IDLE_NO_OVERRIDE;
+		acpi_processor_power_init(pr, device);
+		/* set to IDLE_HALT for trapping into Xen */
+		boot_option_idle_override =3D IDLE_HALT;
+
+		if (pr->flags.power)
+			processor_cntl_xen_notify(pr,
+					PROCESSOR_PM_INIT, PM_TYPE_IDLE);
+	}
+}
+
 static int __cpuinit __xen_acpi_processor_add(struct acpi_device *device)
 {
 	struct acpi_processor *pr =3D NULL;
@@ -339,14 +392,12 @@ static int __cpuinit __xen_acpi_processor_add(struct =
acpi_device *device)
 	}
=20
 #ifdef CONFIG_CPU_FREQ
-	acpi_processor_ppc_has_changed(pr, 0);
+	xen_acpi_processor_ppc_has_changed(pr);
 #endif
 	acpi_processor_get_throttling_info(pr);
 	acpi_processor_get_limit_info(pr);
=20
-
-	if (cpuidle_get_driver() =3D=3D &acpi_idle_driver)
-		acpi_processor_power_init(pr, device);
+	xen_acpi_processor_power_init(pr, device);
=20
 	pr->cdev =3D thermal_cooling_device_register("Processor", device,
 						&processor_cooling_ops);
@@ -400,48 +451,8 @@ static int __cpuinit xen_acpi_processor_add(struct acp=
i_device *device)
 	if (!pr)
 		return -EINVAL;
=20
-	if (pr->id =3D=3D -1) {
-		int device_declaration;
-		int apic_id =3D -1;
-
-		if (!strcmp(acpi_device_hid(device), ACPI_PROCESSOR_OBJECT_HID))
-			device_declaration =3D 0;
-		else
-			device_declaration =3D 1;
-
-		apic_id =3D acpi_get_cpuid(pr->handle,
-			device_declaration, pr->acpi_id);
-		if (apic_id =3D=3D -1) {
-			/* Processor is not present in MADT table */
-			return 0;
-		}
-
-		/*
-		 * It's possible to have pr->id as '-1' even when it's actually
-		 * present in MADT table, e.g. due to limiting dom0 max vcpus
-		 * less than physical present number. In such case we still want
-		 * to parse ACPI processor object information, so mimic the
-		 * pr->id to CPU-0. This should be safe because we only care
-		 * about raw ACPI information, which only relies on pr->acpi_id.
-		 * For other information relying on pr->id and gathered through
-		 * SMP function call, it's safe to let them run on CPU-0 since
-		 * underlying Xen will collect them. Only a valid pr->id can
-		 * make later invocations forward progress.
-		 */
-		pr->id =3D 0;
-	}
-
-	if (likely(!pr->flags.power_setup_done)) {
-		/* reset idle boot option which we don't care */
-		boot_option_idle_override =3D IDLE_NO_OVERRIDE;
-		acpi_processor_power_init(pr, device);
-		/* set to IDLE_HALT for trapping into Xen */
-		boot_option_idle_override =3D IDLE_HALT;
-
-		if (pr->flags.power)
-			processor_cntl_xen_notify(pr,
-					PROCESSOR_PM_INIT, PM_TYPE_IDLE);
-	}
+	if (pr->id =3D=3D -1)
+		return 0;
=20
 #ifdef CONFIG_CPU_FREQ
 	if (likely(!pr->performance))
--=20
1.6.5.6

--_002_DE8DF0795D48FD4CA783C40EC82923358AA0SHSMSX101ccrcorpint_
Content-Type: application/octet-stream;
	name="0009-xen-acpi-Change-Cx-notify-and-add-PPC-handle.patch"
Content-Description: 0009-xen-acpi-Change-Cx-notify-and-add-PPC-handle.patch
Content-Disposition: attachment;
	filename="0009-xen-acpi-Change-Cx-notify-and-add-PPC-handle.patch";
	size=4832; creation-date="Wed, 14 Dec 2011 15:20:15 GMT";
	modification-date="Wed, 14 Dec 2011 15:03:34 GMT"
Content-Transfer-Encoding: base64

RnJvbSBjYTQwMzU2NmU5MjJkZGU1MWU4ODA5ZDc0ODkzMzdiZTRhNTVhZGZjIE1vbiBTZXAgMTcg
MDA6MDA6MDAgMjAwMQpGcm9tOiBMaXUgSmluc29uZyA8amluc29uZy5saXVAaW50ZWwuY29tPgpE
YXRlOiBXZWQsIDE0IERlYyAyMDExIDE1OjU5OjAyICswODAwClN1YmplY3Q6IFtQQVRDSCAwOS8x
MF0geGVuL2FjcGk6IENoYW5nZSBDeCBub3RpZnkgYW5kIGFkZCBQUEMgaGFuZGxlCgpUaGlzIHBh
dGNoIHVwZGF0ZSBYZW4gQ3ggbm90aWZ5LgpDdXJyZW50IEN4IG5vdGlmeSBoYXMgMiBwb3RlbnRp
YWwgdHJpZ2dlciBwb2ludHMgdy8gc29tZSBsb2dpY2FsbHkgcmVkdW5kYW50LgpXZSByZW1vdmUg
dGhlIEN4IG5vdGlmeSBwb2ludCB3aGljaCBpcyBvdXRzaWRlIF9feGVuX2FjcGlfcHJvY2Vzc29y
X2FkZCwKbWVyZ2luZyBpdHMgbG9naWMgdG8gdGhlIEN4IG5vdGlmeSBwb2ludCBpbnNpZGUgX194
ZW5fYWNwaV9wcm9jZXNzb3JfYWRkLgpUaGlzIHdvdWxkIG1vcmUgY2xlYW4sIGFzIHdoYXQgbmF0
aXZlIEN4IGRpZC4KClRoaXMgcGF0Y2ggYWxzbyBhZGQgWGVuIFBQQyBoYW5kbGUgd2hlbiBjcHUg
aG90YWRkLgoKU2lnbmVkLW9mZi1ieTogTGl1LCBKaW5zb25nIDxqaW5zb25nLmxpdUBpbnRlbC5j
b20+Ci0tLQogZHJpdmVycy9hY3BpL3Byb2Nlc3Nvcl94ZW4uYyB8ICAxMDMgKysrKysrKysrKysr
KysrKysrKysrKystLS0tLS0tLS0tLS0tLS0tLS0tCiAxIGZpbGVzIGNoYW5nZWQsIDU3IGluc2Vy
dGlvbnMoKyksIDQ2IGRlbGV0aW9ucygtKQoKZGlmZiAtLWdpdCBhL2RyaXZlcnMvYWNwaS9wcm9j
ZXNzb3JfeGVuLmMgYi9kcml2ZXJzL2FjcGkvcHJvY2Vzc29yX3hlbi5jCmluZGV4IDNhZjFmNzMu
LjA4M2UyYjEgMTAwNjQ0Ci0tLSBhL2RyaXZlcnMvYWNwaS9wcm9jZXNzb3JfeGVuLmMKKysrIGIv
ZHJpdmVycy9hY3BpL3Byb2Nlc3Nvcl94ZW4uYwpAQCAtMjgzLDYgKzI4Myw1OSBAQCBzdGF0aWMg
aW50IHhlbl9hY3BpX3Byb2Nlc3Nvcl9nZXRfaW5mbyhzdHJ1Y3QgYWNwaV9kZXZpY2UgKmRldmlj
ZSkKIAlyZXR1cm4gMDsKIH0KIAorc3RhdGljIGludCB4ZW5fYWNwaV9wcm9jZXNzb3JfZ2V0X3Bs
YXRmb3JtX2xpbWl0KHN0cnVjdCBhY3BpX3Byb2Nlc3NvciAqcHIpCit7CisgICAgICAgIGFjcGlf
c3RhdHVzIHN0YXR1cyA9IDA7CisgICAgICAgIHVuc2lnbmVkIGxvbmcgbG9uZyBwcGMgPSAwOwor
CisgICAgICAgIGlmICghcHIpCisgICAgICAgICAgICAgICAgcmV0dXJuIC1FSU5WQUw7CisKKyAg
ICAgICAgLyoKKyAgICAgICAgICogX1BQQyBpbmRpY2F0ZXMgdGhlIG1heGltdW0gc3RhdGUgY3Vy
cmVudGx5IHN1cHBvcnRlZCBieSB0aGUgcGxhdGZvcm0KKyAgICAgICAgICogKGUuZy4gMCA9IHN0
YXRlcyAwLi5uOyAxID0gc3RhdGVzIDEuLm47IGV0Yy4KKyAgICAgICAgICovCisgICAgICAgIHN0
YXR1cyA9IGFjcGlfZXZhbHVhdGVfaW50ZWdlcihwci0+aGFuZGxlLCAiX1BQQyIsIE5VTEwsICZw
cGMpOworCisgICAgICAgIGlmIChBQ1BJX0ZBSUxVUkUoc3RhdHVzKSAmJiBzdGF0dXMgIT0gQUVf
Tk9UX0ZPVU5EKSB7CisgICAgICAgICAgICAgICAgQUNQSV9FWENFUFRJT04oKEFFX0lORk8sIHN0
YXR1cywgIkV2YWx1YXRpbmcgX1BQQyIpKTsKKyAgICAgICAgICAgICAgICByZXR1cm4gLUVOT0RF
VjsKKyAgICAgICAgfQorCisgICAgICAgIHByLT5wZXJmb3JtYW5jZV9wbGF0Zm9ybV9saW1pdCA9
IChpbnQpcHBjOworCisgICAgICAgIHJldHVybiAwOworfQorCitzdGF0aWMgaW50IHhlbl9hY3Bp
X3Byb2Nlc3Nvcl9wcGNfaGFzX2NoYW5nZWQoc3RydWN0IGFjcGlfcHJvY2Vzc29yICpwcikKK3sK
KwlpbnQgcmV0OworCisJcmV0ID0geGVuX2FjcGlfcHJvY2Vzc29yX2dldF9wbGF0Zm9ybV9saW1p
dChwcik7CisKKwlpZiAocmV0IDwgMCkKKwkJcmV0dXJuIHJldDsKKwllbHNlCisJCXJldHVybiBw
cm9jZXNzb3JfY250bF94ZW5fbm90aWZ5KHByLAorCQkJUFJPQ0VTU09SX1BNX0NIQU5HRSwgUE1f
VFlQRV9QRVJGKTsKK30KKworc3RhdGljIHZvaWQgX19jcHVpbml0IHhlbl9hY3BpX3Byb2Nlc3Nv
cl9wb3dlcl9pbml0KHN0cnVjdCBhY3BpX3Byb2Nlc3NvciAqcHIsCisJCQkgICAgICBzdHJ1Y3Qg
YWNwaV9kZXZpY2UgKmRldmljZSkKK3sKKwlpZiAobGlrZWx5KCFwci0+ZmxhZ3MucG93ZXJfc2V0
dXBfZG9uZSkpIHsKKwkJLyogcmVzZXQgaWRsZSBib290IG9wdGlvbiB3aGljaCB3ZSBkb24ndCBj
YXJlICovCisJCWJvb3Rfb3B0aW9uX2lkbGVfb3ZlcnJpZGUgPSBJRExFX05PX09WRVJSSURFOwor
CQlhY3BpX3Byb2Nlc3Nvcl9wb3dlcl9pbml0KHByLCBkZXZpY2UpOworCQkvKiBzZXQgdG8gSURM
RV9IQUxUIGZvciB0cmFwcGluZyBpbnRvIFhlbiAqLworCQlib290X29wdGlvbl9pZGxlX292ZXJy
aWRlID0gSURMRV9IQUxUOworCisJCWlmIChwci0+ZmxhZ3MucG93ZXIpCisJCQlwcm9jZXNzb3Jf
Y250bF94ZW5fbm90aWZ5KHByLAorCQkJCQlQUk9DRVNTT1JfUE1fSU5JVCwgUE1fVFlQRV9JRExF
KTsKKwl9Cit9CisKIHN0YXRpYyBpbnQgX19jcHVpbml0IF9feGVuX2FjcGlfcHJvY2Vzc29yX2Fk
ZChzdHJ1Y3QgYWNwaV9kZXZpY2UgKmRldmljZSkKIHsKIAlzdHJ1Y3QgYWNwaV9wcm9jZXNzb3Ig
KnByID0gTlVMTDsKQEAgLTMzOSwxNCArMzkyLDEyIEBAIHN0YXRpYyBpbnQgX19jcHVpbml0IF9f
eGVuX2FjcGlfcHJvY2Vzc29yX2FkZChzdHJ1Y3QgYWNwaV9kZXZpY2UgKmRldmljZSkKIAl9CiAK
ICNpZmRlZiBDT05GSUdfQ1BVX0ZSRVEKLQlhY3BpX3Byb2Nlc3Nvcl9wcGNfaGFzX2NoYW5nZWQo
cHIsIDApOworCXhlbl9hY3BpX3Byb2Nlc3Nvcl9wcGNfaGFzX2NoYW5nZWQocHIpOwogI2VuZGlm
CiAJYWNwaV9wcm9jZXNzb3JfZ2V0X3Rocm90dGxpbmdfaW5mbyhwcik7CiAJYWNwaV9wcm9jZXNz
b3JfZ2V0X2xpbWl0X2luZm8ocHIpOwogCi0KLQlpZiAoY3B1aWRsZV9nZXRfZHJpdmVyKCkgPT0g
JmFjcGlfaWRsZV9kcml2ZXIpCi0JCWFjcGlfcHJvY2Vzc29yX3Bvd2VyX2luaXQocHIsIGRldmlj
ZSk7CisJeGVuX2FjcGlfcHJvY2Vzc29yX3Bvd2VyX2luaXQocHIsIGRldmljZSk7CiAKIAlwci0+
Y2RldiA9IHRoZXJtYWxfY29vbGluZ19kZXZpY2VfcmVnaXN0ZXIoIlByb2Nlc3NvciIsIGRldmlj
ZSwKIAkJCQkJCSZwcm9jZXNzb3JfY29vbGluZ19vcHMpOwpAQCAtNDAwLDQ4ICs0NTEsOCBAQCBz
dGF0aWMgaW50IF9fY3B1aW5pdCB4ZW5fYWNwaV9wcm9jZXNzb3JfYWRkKHN0cnVjdCBhY3BpX2Rl
dmljZSAqZGV2aWNlKQogCWlmICghcHIpCiAJCXJldHVybiAtRUlOVkFMOwogCi0JaWYgKHByLT5p
ZCA9PSAtMSkgewotCQlpbnQgZGV2aWNlX2RlY2xhcmF0aW9uOwotCQlpbnQgYXBpY19pZCA9IC0x
OwotCi0JCWlmICghc3RyY21wKGFjcGlfZGV2aWNlX2hpZChkZXZpY2UpLCBBQ1BJX1BST0NFU1NP
Ul9PQkpFQ1RfSElEKSkKLQkJCWRldmljZV9kZWNsYXJhdGlvbiA9IDA7Ci0JCWVsc2UKLQkJCWRl
dmljZV9kZWNsYXJhdGlvbiA9IDE7Ci0KLQkJYXBpY19pZCA9IGFjcGlfZ2V0X2NwdWlkKHByLT5o
YW5kbGUsCi0JCQlkZXZpY2VfZGVjbGFyYXRpb24sIHByLT5hY3BpX2lkKTsKLQkJaWYgKGFwaWNf
aWQgPT0gLTEpIHsKLQkJCS8qIFByb2Nlc3NvciBpcyBub3QgcHJlc2VudCBpbiBNQURUIHRhYmxl
ICovCi0JCQlyZXR1cm4gMDsKLQkJfQotCi0JCS8qCi0JCSAqIEl0J3MgcG9zc2libGUgdG8gaGF2
ZSBwci0+aWQgYXMgJy0xJyBldmVuIHdoZW4gaXQncyBhY3R1YWxseQotCQkgKiBwcmVzZW50IGlu
IE1BRFQgdGFibGUsIGUuZy4gZHVlIHRvIGxpbWl0aW5nIGRvbTAgbWF4IHZjcHVzCi0JCSAqIGxl
c3MgdGhhbiBwaHlzaWNhbCBwcmVzZW50IG51bWJlci4gSW4gc3VjaCBjYXNlIHdlIHN0aWxsIHdh
bnQKLQkJICogdG8gcGFyc2UgQUNQSSBwcm9jZXNzb3Igb2JqZWN0IGluZm9ybWF0aW9uLCBzbyBt
aW1pYyB0aGUKLQkJICogcHItPmlkIHRvIENQVS0wLiBUaGlzIHNob3VsZCBiZSBzYWZlIGJlY2F1
c2Ugd2Ugb25seSBjYXJlCi0JCSAqIGFib3V0IHJhdyBBQ1BJIGluZm9ybWF0aW9uLCB3aGljaCBv
bmx5IHJlbGllcyBvbiBwci0+YWNwaV9pZC4KLQkJICogRm9yIG90aGVyIGluZm9ybWF0aW9uIHJl
bHlpbmcgb24gcHItPmlkIGFuZCBnYXRoZXJlZCB0aHJvdWdoCi0JCSAqIFNNUCBmdW5jdGlvbiBj
YWxsLCBpdCdzIHNhZmUgdG8gbGV0IHRoZW0gcnVuIG9uIENQVS0wIHNpbmNlCi0JCSAqIHVuZGVy
bHlpbmcgWGVuIHdpbGwgY29sbGVjdCB0aGVtLiBPbmx5IGEgdmFsaWQgcHItPmlkIGNhbgotCQkg
KiBtYWtlIGxhdGVyIGludm9jYXRpb25zIGZvcndhcmQgcHJvZ3Jlc3MuCi0JCSAqLwotCQlwci0+
aWQgPSAwOwotCX0KLQotCWlmIChsaWtlbHkoIXByLT5mbGFncy5wb3dlcl9zZXR1cF9kb25lKSkg
ewotCQkvKiByZXNldCBpZGxlIGJvb3Qgb3B0aW9uIHdoaWNoIHdlIGRvbid0IGNhcmUgKi8KLQkJ
Ym9vdF9vcHRpb25faWRsZV9vdmVycmlkZSA9IElETEVfTk9fT1ZFUlJJREU7Ci0JCWFjcGlfcHJv
Y2Vzc29yX3Bvd2VyX2luaXQocHIsIGRldmljZSk7Ci0JCS8qIHNldCB0byBJRExFX0hBTFQgZm9y
IHRyYXBwaW5nIGludG8gWGVuICovCi0JCWJvb3Rfb3B0aW9uX2lkbGVfb3ZlcnJpZGUgPSBJRExF
X0hBTFQ7Ci0KLQkJaWYgKHByLT5mbGFncy5wb3dlcikKLQkJCXByb2Nlc3Nvcl9jbnRsX3hlbl9u
b3RpZnkocHIsCi0JCQkJCVBST0NFU1NPUl9QTV9JTklULCBQTV9UWVBFX0lETEUpOwotCX0KKwlp
ZiAocHItPmlkID09IC0xKQorCQlyZXR1cm4gMDsKIAogI2lmZGVmIENPTkZJR19DUFVfRlJFUQog
CWlmIChsaWtlbHkoIXByLT5wZXJmb3JtYW5jZSkpCi0tIAoxLjYuNS42Cgo=

--_002_DE8DF0795D48FD4CA783C40EC82923358AA0SHSMSX101ccrcorpint_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--_002_DE8DF0795D48FD4CA783C40EC82923358AA0SHSMSX101ccrcorpint_--


From xen-devel-bounces@lists.xensource.com Thu Dec 22 10:27:25 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 Dec 2011 10:27:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rdfrk-0007sx-Qt; Thu, 22 Dec 2011 10:27:12 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Rdfrj-0007sk-CD
	for xen-devel@lists.xensource.com; Thu, 22 Dec 2011 10:27:11 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1324549624!8430503!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Nzk5NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18068 invoked from network); 22 Dec 2011 10:27:04 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Dec 2011 10:27:04 -0000
X-IronPort-AV: E=Sophos;i="4.71,392,1320624000"; 
   d="scan'208";a="9628323"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Dec 2011 10:27:03 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 22 Dec 2011 10:27:03 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1Rdfrb-00012L-Gr;
	Thu, 22 Dec 2011 10:27:03 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Rdfrb-0001Mb-GF;
	Thu, 22 Dec 2011 10:27:03 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10591-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 22 Dec 2011 10:27:03 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10591: regressions - trouble:
	broken/fail/pass
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10591 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10591/

Regressions :-(

Tests which did not succeed and are blocking,including tests which could not be run:
 test-i386-i386-pv            19 capture-logs(19)             broken
 test-amd64-amd64-xl-win7-amd64  7 windows-install         fail REGR. vs. 10564

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-pv          16 guest-start.2               fail pass in 10571
 test-amd64-i386-pv           16 guest-start.2               fail pass in 10571
 test-amd64-i386-xl-win7-amd64  7 windows-install            fail pass in 10571
 test-amd64-amd64-xl          16 guest-start.2               fail pass in 10585
 test-amd64-amd64-xl-sedf      7 debian-install              fail pass in 10585
 test-amd64-i386-win-vcpus1    7 windows-install             fail pass in 10585
 test-amd64-i386-xl-credit2    7 debian-install     fail in 10571 pass in 10591
 test-i386-i386-pv            16 guest-start.2      fail in 10571 pass in 10591
 test-i386-i386-xl            16 guest-start.2      fail in 10571 pass in 10591
 test-amd64-i386-rhel6hvm-intel  7 redhat-install   fail in 10585 pass in 10591
 test-amd64-i386-xl-multivcpu 16 guest-start.2      fail in 10585 pass in 10591
 test-amd64-amd64-xl-sedf-pin 16 guest-start.2      fail in 10585 pass in 10591
 test-amd64-i386-xl           16 guest-start.2      fail in 10585 pass in 10591
 test-amd64-i386-rhel6hvm-amd  7 redhat-install     fail in 10585 pass in 10591
 test-amd64-i386-xl-credit2   16 guest-start.2      fail in 10585 pass in 10591
 test-i386-i386-win            7 windows-install    fail in 10585 pass in 10591
 test-amd64-i386-xl-winxpsp3-vcpus1 7 windows-install fail in 10585 pass in 10591

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop           fail in 10571 never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check      fail in 10571 never pass
 test-amd64-amd64-xl-sedf    14 guest-localmigrate/x10 fail in 10585 like 10563

version targeted for testing:
 xen                  492914c65838
baseline version:
 xen                  e56500f95b6a

------------------------------------------------------------
People who touched revisions under test:
  Anthony PERARD <anthony.perard@citrix.com>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          fail    
 test-amd64-i386-pv                                           fail    
 test-i386-i386-pv                                            broken  
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   24445:492914c65838
tag:         tip
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Wed Dec 21 10:47:30 2011 +0000
    
    libxl: report failure to reboot/shutdown due to lackof PV interfaces to caller
    
    This allow the caller to react as they think is appropriate. xl now prints a
    message much like the library did previously, although hopefully somewhat more
    informative.
    
    Update the xl(1) man page to be similarly more informative.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Committed-by: Ian Jackson <ian.jackson.citrix.com>
    Acked-by: Ian Jackson <ian.jackson.citrix.com>
    
    
changeset:   24444:1c3f9cac204e
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Wed Dec 21 10:47:11 2011 +0000
    
    libxl: split libxl_domain_shutdown into libxl_domain_shutdown,..._reboot
    
    The other integer request types which shutdown supported are not
    useful. Specifically:
    
     * "suspend" is not usable via this interface since it requires other
       scaffolding, libxl_domain_suspend provides this already.
     * "halt" is the same as "poweroff".
     * "crash" is unused and at least Linux does not implement it. If a user
       steps forward then libxl_domain_crash is trivial to add.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Committed-by: Ian Jackson <ian.jackson.citrix.com>
    Acked-by: Ian Jackson <ian.jackson.citrix.com>
    
    
changeset:   24443:b3455a4d2298
user:        Anthony PERARD <anthony.perard@citrix.com>
date:        Wed Dec 21 14:47:26 2011 +0000
    
    libxl: Fix, specify open mode to QEMU state file.
    
    Reported-by: Olaf Hering <olaf@aepfle.de>
    Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24442:16dc2a1cd40f
user:        Jan Beulich <jbeulich@suse.com>
date:        Wed Dec 21 14:26:09 2011 +0100
    
    x86: reduce scope of some symbols used with reset_stack_and_jump()
    
    By making the macro properly advertise the use of the input symbol to
    the compiler, it is no longer necessary for them to be global if
    they're defined and used in just one source file.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24441:73ab77073140
user:        Jan Beulich <jbeulich@suse.com>
date:        Wed Dec 21 09:20:15 2011 +0100
    
    x86: move some function scope statics into .init.data
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24440:e56500f95b6a
user:        Daniel De Graaf <dgdegra@tycho.nsa.gov>
date:        Tue Dec 20 18:19:53 2011 +0000
    
    flask/policy: Update example policy
    
    Rewrite the example policy to make it easier to understand and
    demonstrate some of the security goals that FLASK can enforce.
    
    Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
    Committed-by: Ian Jackson <ian.jackson.citrix.com>
    
    
========================================
commit 54e24021005458ad0a361c1d83011b751726a94b
Author: Ian Jackson <ian.jackson@eu.citrix.com>
Date:   Thu Dec 8 16:38:06 2011 +0000

    qemu_get_timer: Provide a comment about the behaviour on ts==NULL
    
    Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 22 10:27:25 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 Dec 2011 10:27:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rdfrk-0007sx-Qt; Thu, 22 Dec 2011 10:27:12 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Rdfrj-0007sk-CD
	for xen-devel@lists.xensource.com; Thu, 22 Dec 2011 10:27:11 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1324549624!8430503!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Nzk5NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18068 invoked from network); 22 Dec 2011 10:27:04 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Dec 2011 10:27:04 -0000
X-IronPort-AV: E=Sophos;i="4.71,392,1320624000"; 
   d="scan'208";a="9628323"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Dec 2011 10:27:03 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 22 Dec 2011 10:27:03 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1Rdfrb-00012L-Gr;
	Thu, 22 Dec 2011 10:27:03 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Rdfrb-0001Mb-GF;
	Thu, 22 Dec 2011 10:27:03 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10591-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 22 Dec 2011 10:27:03 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10591: regressions - trouble:
	broken/fail/pass
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10591 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10591/

Regressions :-(

Tests which did not succeed and are blocking,including tests which could not be run:
 test-i386-i386-pv            19 capture-logs(19)             broken
 test-amd64-amd64-xl-win7-amd64  7 windows-install         fail REGR. vs. 10564

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-pv          16 guest-start.2               fail pass in 10571
 test-amd64-i386-pv           16 guest-start.2               fail pass in 10571
 test-amd64-i386-xl-win7-amd64  7 windows-install            fail pass in 10571
 test-amd64-amd64-xl          16 guest-start.2               fail pass in 10585
 test-amd64-amd64-xl-sedf      7 debian-install              fail pass in 10585
 test-amd64-i386-win-vcpus1    7 windows-install             fail pass in 10585
 test-amd64-i386-xl-credit2    7 debian-install     fail in 10571 pass in 10591
 test-i386-i386-pv            16 guest-start.2      fail in 10571 pass in 10591
 test-i386-i386-xl            16 guest-start.2      fail in 10571 pass in 10591
 test-amd64-i386-rhel6hvm-intel  7 redhat-install   fail in 10585 pass in 10591
 test-amd64-i386-xl-multivcpu 16 guest-start.2      fail in 10585 pass in 10591
 test-amd64-amd64-xl-sedf-pin 16 guest-start.2      fail in 10585 pass in 10591
 test-amd64-i386-xl           16 guest-start.2      fail in 10585 pass in 10591
 test-amd64-i386-rhel6hvm-amd  7 redhat-install     fail in 10585 pass in 10591
 test-amd64-i386-xl-credit2   16 guest-start.2      fail in 10585 pass in 10591
 test-i386-i386-win            7 windows-install    fail in 10585 pass in 10591
 test-amd64-i386-xl-winxpsp3-vcpus1 7 windows-install fail in 10585 pass in 10591

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop           fail in 10571 never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check      fail in 10571 never pass
 test-amd64-amd64-xl-sedf    14 guest-localmigrate/x10 fail in 10585 like 10563

version targeted for testing:
 xen                  492914c65838
baseline version:
 xen                  e56500f95b6a

------------------------------------------------------------
People who touched revisions under test:
  Anthony PERARD <anthony.perard@citrix.com>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          fail    
 test-amd64-i386-pv                                           fail    
 test-i386-i386-pv                                            broken  
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   24445:492914c65838
tag:         tip
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Wed Dec 21 10:47:30 2011 +0000
    
    libxl: report failure to reboot/shutdown due to lackof PV interfaces to caller
    
    This allow the caller to react as they think is appropriate. xl now prints a
    message much like the library did previously, although hopefully somewhat more
    informative.
    
    Update the xl(1) man page to be similarly more informative.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Committed-by: Ian Jackson <ian.jackson.citrix.com>
    Acked-by: Ian Jackson <ian.jackson.citrix.com>
    
    
changeset:   24444:1c3f9cac204e
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Wed Dec 21 10:47:11 2011 +0000
    
    libxl: split libxl_domain_shutdown into libxl_domain_shutdown,..._reboot
    
    The other integer request types which shutdown supported are not
    useful. Specifically:
    
     * "suspend" is not usable via this interface since it requires other
       scaffolding, libxl_domain_suspend provides this already.
     * "halt" is the same as "poweroff".
     * "crash" is unused and at least Linux does not implement it. If a user
       steps forward then libxl_domain_crash is trivial to add.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Committed-by: Ian Jackson <ian.jackson.citrix.com>
    Acked-by: Ian Jackson <ian.jackson.citrix.com>
    
    
changeset:   24443:b3455a4d2298
user:        Anthony PERARD <anthony.perard@citrix.com>
date:        Wed Dec 21 14:47:26 2011 +0000
    
    libxl: Fix, specify open mode to QEMU state file.
    
    Reported-by: Olaf Hering <olaf@aepfle.de>
    Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24442:16dc2a1cd40f
user:        Jan Beulich <jbeulich@suse.com>
date:        Wed Dec 21 14:26:09 2011 +0100
    
    x86: reduce scope of some symbols used with reset_stack_and_jump()
    
    By making the macro properly advertise the use of the input symbol to
    the compiler, it is no longer necessary for them to be global if
    they're defined and used in just one source file.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24441:73ab77073140
user:        Jan Beulich <jbeulich@suse.com>
date:        Wed Dec 21 09:20:15 2011 +0100
    
    x86: move some function scope statics into .init.data
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24440:e56500f95b6a
user:        Daniel De Graaf <dgdegra@tycho.nsa.gov>
date:        Tue Dec 20 18:19:53 2011 +0000
    
    flask/policy: Update example policy
    
    Rewrite the example policy to make it easier to understand and
    demonstrate some of the security goals that FLASK can enforce.
    
    Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
    Committed-by: Ian Jackson <ian.jackson.citrix.com>
    
    
========================================
commit 54e24021005458ad0a361c1d83011b751726a94b
Author: Ian Jackson <ian.jackson@eu.citrix.com>
Date:   Thu Dec 8 16:38:06 2011 +0000

    qemu_get_timer: Provide a comment about the behaviour on ts==NULL
    
    Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 22 10:32:16 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 Dec 2011 10:32:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdfwU-0008PJ-JT; Thu, 22 Dec 2011 10:32:06 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RdfwT-0008Ox-BJ
	for xen-devel@lists.xensource.com; Thu, 22 Dec 2011 10:32:05 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1324549919!8423291!1
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.7 required=7.0 tests=DATE_IN_PAST_48_96, RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12188 invoked from network); 22 Dec 2011 10:31:59 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Dec 2011 10:31:59 -0000
Received: by wgbds11 with SMTP id ds11so13384173wgb.24
	for <xen-devel@lists.xensource.com>;
	Thu, 22 Dec 2011 02:31:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:message-id:user-agent:date:from:to;
	bh=ZiQV+5IH/bpmkCcUNy0EZ9aYGPlH/+0HJEQuCS1Q5jw=;
	b=cvaiUIzesxIQin2JIfDTHHIJi0DeHZTN9lcdmQcPZ6ge6eYJCND57CUkqb8Z6H9sNF
	DyVymZV90vKwPOsWO4/wJvKLk8zulgOV0xbLiFPaAfV8A7S1SuVit7UlsC5qgFIdPNy3
	26Y/xpcNTQQSwiDEH++h+pKPNMEy3mfTVHnZM=
Received: by 10.227.60.135 with SMTP id p7mr9937578wbh.16.1324549919091;
	Thu, 22 Dec 2011 02:31:59 -0800 (PST)
Received: from alpine.localdomain (tina.upc.es. [147.83.39.243])
	by mx.google.com with ESMTPS id k5sm21270950wiz.9.2011.12.22.02.31.56
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 22 Dec 2011 02:31:57 -0800 (PST)
MIME-Version: 1.0
Message-Id: <patchbomb.1324370958@alpine.localdomain>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Tue, 20 Dec 2011 09:49:18 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 0 of 4 v3] build: various fixes for building
 with uclibc and libiconv
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This patch contains various fixes to the build system to allow
building xen under uclibc with libiconv. Has been tested with uclibc
0.9.32, gcc 4.6.2 and libiconv 1.12, from Alpine Linux 2.3.2.

Changes since v2:

 * Added explicit defined(__linux) in bswap.h for both blktap and 
   blktap2.

 * Changed the way to check for libiconv presence.

Please review, Roger.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 22 10:32:16 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 Dec 2011 10:32:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdfwU-0008PJ-JT; Thu, 22 Dec 2011 10:32:06 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RdfwT-0008Ox-BJ
	for xen-devel@lists.xensource.com; Thu, 22 Dec 2011 10:32:05 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1324549919!8423291!1
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.7 required=7.0 tests=DATE_IN_PAST_48_96, RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12188 invoked from network); 22 Dec 2011 10:31:59 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Dec 2011 10:31:59 -0000
Received: by wgbds11 with SMTP id ds11so13384173wgb.24
	for <xen-devel@lists.xensource.com>;
	Thu, 22 Dec 2011 02:31:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:message-id:user-agent:date:from:to;
	bh=ZiQV+5IH/bpmkCcUNy0EZ9aYGPlH/+0HJEQuCS1Q5jw=;
	b=cvaiUIzesxIQin2JIfDTHHIJi0DeHZTN9lcdmQcPZ6ge6eYJCND57CUkqb8Z6H9sNF
	DyVymZV90vKwPOsWO4/wJvKLk8zulgOV0xbLiFPaAfV8A7S1SuVit7UlsC5qgFIdPNy3
	26Y/xpcNTQQSwiDEH++h+pKPNMEy3mfTVHnZM=
Received: by 10.227.60.135 with SMTP id p7mr9937578wbh.16.1324549919091;
	Thu, 22 Dec 2011 02:31:59 -0800 (PST)
Received: from alpine.localdomain (tina.upc.es. [147.83.39.243])
	by mx.google.com with ESMTPS id k5sm21270950wiz.9.2011.12.22.02.31.56
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 22 Dec 2011 02:31:57 -0800 (PST)
MIME-Version: 1.0
Message-Id: <patchbomb.1324370958@alpine.localdomain>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Tue, 20 Dec 2011 09:49:18 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 0 of 4 v3] build: various fixes for building
 with uclibc and libiconv
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This patch contains various fixes to the build system to allow
building xen under uclibc with libiconv. Has been tested with uclibc
0.9.32, gcc 4.6.2 and libiconv 1.12, from Alpine Linux 2.3.2.

Changes since v2:

 * Added explicit defined(__linux) in bswap.h for both blktap and 
   blktap2.

 * Changed the way to check for libiconv presence.

Please review, Roger.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 22 10:32:20 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 Dec 2011 10:32:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdfwY-0008Pw-EI; Thu, 22 Dec 2011 10:32:10 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RdfwX-0008P7-EX
	for xen-devel@lists.xensource.com; Thu, 22 Dec 2011 10:32:09 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1324549891!45873428!1
X-Originating-IP: [209.85.212.171]
X-SpamReason: No, hits=0.7 required=7.0 tests=DATE_IN_PAST_48_96, RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16393 invoked from network); 22 Dec 2011 10:31:32 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Dec 2011 10:31:32 -0000
Received: by wico1 with SMTP id o1so6288371wic.30
	for <xen-devel@lists.xensource.com>;
	Thu, 22 Dec 2011 02:32:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=RGQhMf9NuKZyZVcKnnojPDS9Z3seWSRjtU+O+TL+yX0=;
	b=gEzndBPH/4wUD2MXVAitceo1PPbQJFDR5Ixxz3svBDx8plT70SgPMVWGw6W/Xb78ay
	Blo9S+NLXgItV2nvEPhCpnnulU+cKuWKNIeV6C2zxpodrWBlzDs+kY27pF3hwJeX5DER
	fbtHYmHP3UG8CMnBKx4zlYj4rNLHf7hEN8Kdw=
Received: by 10.180.101.35 with SMTP id fd3mr12192924wib.22.1324549923296;
	Thu, 22 Dec 2011 02:32:03 -0800 (PST)
Received: from alpine.localdomain (tina.upc.es. [147.83.39.243])
	by mx.google.com with ESMTPS id k5sm21270950wiz.9.2011.12.22.02.32.01
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 22 Dec 2011 02:32:02 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 2fd10f2605439da1541646eda7276c8ff390b9de
Message-Id: <2fd10f2605439da15416.1324370960@alpine.localdomain>
In-Reply-To: <patchbomb.1324370958@alpine.localdomain>
References: <patchbomb.1324370958@alpine.localdomain>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Tue, 20 Dec 2011 09:49:20 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 2 of 4 v3] blktap2: remove local definitions and
 include byteswap.h
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1324366300 -3600
# Node ID 2fd10f2605439da1541646eda7276c8ff390b9de
# Parent  32c735e9b6fc6250cb465d091e7fd30d95bf699e
blktap2: remove local definitions and include byteswap.h

Use the same approach as tools/blktap2/include/libvhd.h, remove local
definitions of bswap* and include byteswap.h. Also remove the
HAVE_BYTESWAP_H ifdef, since it was not defined in this context (it's
defined by QEMU).

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 32c735e9b6fc -r 2fd10f260543 tools/blktap2/drivers/bswap.h
--- a/tools/blktap2/drivers/bswap.h	Tue Dec 20 08:31:40 2011 +0100
+++ b/tools/blktap2/drivers/bswap.h	Tue Dec 20 08:31:40 2011 +0100
@@ -13,45 +13,10 @@
 #define bswap_16(x) swap16(x)
 #define bswap_32(x) swap32(x)
 #define bswap_64(x) swap64(x)
-#else
+#elif defined(__linux__)
 
-#ifdef HAVE_BYTESWAP_H
+#include <endian.h>
 #include <byteswap.h>
-#else
-
-#define bswap_16(x) \
-({ \
-	uint16_t __x = (x); \
-	((uint16_t)( \
-		(((uint16_t)(__x) & (uint16_t)0x00ffU) << 8) | \
-		(((uint16_t)(__x) & (uint16_t)0xff00U) >> 8) )); \
-})
-
-#define bswap_32(x) \
-({ \
-	uint32_t __x = (x); \
-	((uint32_t)( \
-		(((uint32_t)(__x) & (uint32_t)0x000000ffUL) << 24) | \
-		(((uint32_t)(__x) & (uint32_t)0x0000ff00UL) <<  8) | \
-		(((uint32_t)(__x) & (uint32_t)0x00ff0000UL) >>  8) | \
-		(((uint32_t)(__x) & (uint32_t)0xff000000UL) >> 24) )); \
-})
-
-#define bswap_64(x) \
-({ \
-	uint64_t __x = (x); \
-	((uint64_t)( \
-		(uint64_t)(((uint64_t)(__x) & (uint64_t)0x00000000000000ffULL) << 56) | \
-		(uint64_t)(((uint64_t)(__x) & (uint64_t)0x000000000000ff00ULL) << 40) | \
-		(uint64_t)(((uint64_t)(__x) & (uint64_t)0x0000000000ff0000ULL) << 24) | \
-		(uint64_t)(((uint64_t)(__x) & (uint64_t)0x00000000ff000000ULL) <<  8) | \
-	        (uint64_t)(((uint64_t)(__x) & (uint64_t)0x000000ff00000000ULL) >>  8) | \
-		(uint64_t)(((uint64_t)(__x) & (uint64_t)0x0000ff0000000000ULL) >> 24) | \
-		(uint64_t)(((uint64_t)(__x) & (uint64_t)0x00ff000000000000ULL) >> 40) | \
-		(uint64_t)(((uint64_t)(__x) & (uint64_t)0xff00000000000000ULL) >> 56) )); \
-})
-
-#endif /* !HAVE_BYTESWAP_H */
 
 static inline uint16_t bswap16(uint16_t x)
 {

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 22 10:32:20 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 Dec 2011 10:32:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdfwY-0008Pw-EI; Thu, 22 Dec 2011 10:32:10 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RdfwX-0008P7-EX
	for xen-devel@lists.xensource.com; Thu, 22 Dec 2011 10:32:09 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1324549891!45873428!1
X-Originating-IP: [209.85.212.171]
X-SpamReason: No, hits=0.7 required=7.0 tests=DATE_IN_PAST_48_96, RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16393 invoked from network); 22 Dec 2011 10:31:32 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Dec 2011 10:31:32 -0000
Received: by wico1 with SMTP id o1so6288371wic.30
	for <xen-devel@lists.xensource.com>;
	Thu, 22 Dec 2011 02:32:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=RGQhMf9NuKZyZVcKnnojPDS9Z3seWSRjtU+O+TL+yX0=;
	b=gEzndBPH/4wUD2MXVAitceo1PPbQJFDR5Ixxz3svBDx8plT70SgPMVWGw6W/Xb78ay
	Blo9S+NLXgItV2nvEPhCpnnulU+cKuWKNIeV6C2zxpodrWBlzDs+kY27pF3hwJeX5DER
	fbtHYmHP3UG8CMnBKx4zlYj4rNLHf7hEN8Kdw=
Received: by 10.180.101.35 with SMTP id fd3mr12192924wib.22.1324549923296;
	Thu, 22 Dec 2011 02:32:03 -0800 (PST)
Received: from alpine.localdomain (tina.upc.es. [147.83.39.243])
	by mx.google.com with ESMTPS id k5sm21270950wiz.9.2011.12.22.02.32.01
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 22 Dec 2011 02:32:02 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 2fd10f2605439da1541646eda7276c8ff390b9de
Message-Id: <2fd10f2605439da15416.1324370960@alpine.localdomain>
In-Reply-To: <patchbomb.1324370958@alpine.localdomain>
References: <patchbomb.1324370958@alpine.localdomain>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Tue, 20 Dec 2011 09:49:20 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 2 of 4 v3] blktap2: remove local definitions and
 include byteswap.h
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1324366300 -3600
# Node ID 2fd10f2605439da1541646eda7276c8ff390b9de
# Parent  32c735e9b6fc6250cb465d091e7fd30d95bf699e
blktap2: remove local definitions and include byteswap.h

Use the same approach as tools/blktap2/include/libvhd.h, remove local
definitions of bswap* and include byteswap.h. Also remove the
HAVE_BYTESWAP_H ifdef, since it was not defined in this context (it's
defined by QEMU).

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 32c735e9b6fc -r 2fd10f260543 tools/blktap2/drivers/bswap.h
--- a/tools/blktap2/drivers/bswap.h	Tue Dec 20 08:31:40 2011 +0100
+++ b/tools/blktap2/drivers/bswap.h	Tue Dec 20 08:31:40 2011 +0100
@@ -13,45 +13,10 @@
 #define bswap_16(x) swap16(x)
 #define bswap_32(x) swap32(x)
 #define bswap_64(x) swap64(x)
-#else
+#elif defined(__linux__)
 
-#ifdef HAVE_BYTESWAP_H
+#include <endian.h>
 #include <byteswap.h>
-#else
-
-#define bswap_16(x) \
-({ \
-	uint16_t __x = (x); \
-	((uint16_t)( \
-		(((uint16_t)(__x) & (uint16_t)0x00ffU) << 8) | \
-		(((uint16_t)(__x) & (uint16_t)0xff00U) >> 8) )); \
-})
-
-#define bswap_32(x) \
-({ \
-	uint32_t __x = (x); \
-	((uint32_t)( \
-		(((uint32_t)(__x) & (uint32_t)0x000000ffUL) << 24) | \
-		(((uint32_t)(__x) & (uint32_t)0x0000ff00UL) <<  8) | \
-		(((uint32_t)(__x) & (uint32_t)0x00ff0000UL) >>  8) | \
-		(((uint32_t)(__x) & (uint32_t)0xff000000UL) >> 24) )); \
-})
-
-#define bswap_64(x) \
-({ \
-	uint64_t __x = (x); \
-	((uint64_t)( \
-		(uint64_t)(((uint64_t)(__x) & (uint64_t)0x00000000000000ffULL) << 56) | \
-		(uint64_t)(((uint64_t)(__x) & (uint64_t)0x000000000000ff00ULL) << 40) | \
-		(uint64_t)(((uint64_t)(__x) & (uint64_t)0x0000000000ff0000ULL) << 24) | \
-		(uint64_t)(((uint64_t)(__x) & (uint64_t)0x00000000ff000000ULL) <<  8) | \
-	        (uint64_t)(((uint64_t)(__x) & (uint64_t)0x000000ff00000000ULL) >>  8) | \
-		(uint64_t)(((uint64_t)(__x) & (uint64_t)0x0000ff0000000000ULL) >> 24) | \
-		(uint64_t)(((uint64_t)(__x) & (uint64_t)0x00ff000000000000ULL) >> 40) | \
-		(uint64_t)(((uint64_t)(__x) & (uint64_t)0xff00000000000000ULL) >> 56) )); \
-})
-
-#endif /* !HAVE_BYTESWAP_H */
 
 static inline uint16_t bswap16(uint16_t x)
 {

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 22 10:32:20 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 Dec 2011 10:32:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdfwW-0008Pd-Vo; Thu, 22 Dec 2011 10:32:08 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RdfwV-0008P3-9a
	for xen-devel@lists.xensource.com; Thu, 22 Dec 2011 10:32:07 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1324549919!8423291!2
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.7 required=7.0 tests=DATE_IN_PAST_48_96, RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12311 invoked from network); 22 Dec 2011 10:32:01 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Dec 2011 10:32:01 -0000
Received: by mail-ww0-f43.google.com with SMTP id ds11so13384173wgb.24
	for <xen-devel@lists.xensource.com>;
	Thu, 22 Dec 2011 02:32:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=pZqCAg3NtU4pn9bQWA/Bgn1mekbXNxlHfH8PXfskvOM=;
	b=egkn0aMRlyoFP9mBxQFrHjzewurSyvfLYeu8hnD09OakeyuuAyZMfNrJWMpoOFCJBX
	WhtQE2DzwWi0sSN4M0iWNhZRHNXAAsTeYISdve5EEzPUY6VfuWn3iJpebB2MJoz8j1dD
	0QLKumoFFJJGBm+uxVVkZB1nrTes+BYpliYYs=
Received: by 10.227.208.13 with SMTP id ga13mr12341964wbb.4.1324549921110;
	Thu, 22 Dec 2011 02:32:01 -0800 (PST)
Received: from alpine.localdomain (tina.upc.es. [147.83.39.243])
	by mx.google.com with ESMTPS id k5sm21270950wiz.9.2011.12.22.02.31.59
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 22 Dec 2011 02:31:59 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 32c735e9b6fc6250cb465d091e7fd30d95bf699e
Message-Id: <32c735e9b6fc6250cb46.1324370959@alpine.localdomain>
In-Reply-To: <patchbomb.1324370958@alpine.localdomain>
References: <patchbomb.1324370958@alpine.localdomain>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Tue, 20 Dec 2011 09:49:19 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 1 of 4 v3] blktap: remove local definitions and
 include byteswap.h
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1324366300 -3600
# Node ID 32c735e9b6fc6250cb465d091e7fd30d95bf699e
# Parent  cf68eb390e1bf2fa4bb005ffeccfd41a01c3f81d
blktap: remove local definitions and include byteswap.h

Use the same approach as tools/blktap2/include/libvhd.h, remove local
definitions of bswap* and include byteswap.h. Also remove the
HAVE_BYTESWAP_H ifdef, since it was not defined in this context (it's
defined by QEMU).

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r cf68eb390e1b -r 32c735e9b6fc tools/blktap/drivers/bswap.h
--- a/tools/blktap/drivers/bswap.h	Tue Dec 20 08:21:11 2011 +0100
+++ b/tools/blktap/drivers/bswap.h	Tue Dec 20 08:31:40 2011 +0100
@@ -13,45 +13,9 @@
 #define bswap_16(x) swap16(x)
 #define bswap_32(x) swap32(x)
 #define bswap_64(x) swap64(x)
-#else
+#elif defined(__linux__)
 
-#ifdef HAVE_BYTESWAP_H
 #include <byteswap.h>
-#else
-
-#define bswap_16(x) \
-({ \
-	uint16_t __x = (x); \
-	((uint16_t)( \
-		(((uint16_t)(__x) & (uint16_t)0x00ffU) << 8) | \
-		(((uint16_t)(__x) & (uint16_t)0xff00U) >> 8) )); \
-})
-
-#define bswap_32(x) \
-({ \
-	uint32_t __x = (x); \
-	((uint32_t)( \
-		(((uint32_t)(__x) & (uint32_t)0x000000ffUL) << 24) | \
-		(((uint32_t)(__x) & (uint32_t)0x0000ff00UL) <<  8) | \
-		(((uint32_t)(__x) & (uint32_t)0x00ff0000UL) >>  8) | \
-		(((uint32_t)(__x) & (uint32_t)0xff000000UL) >> 24) )); \
-})
-
-#define bswap_64(x) \
-({ \
-	uint64_t __x = (x); \
-	((uint64_t)( \
-		(uint64_t)(((uint64_t)(__x) & (uint64_t)0x00000000000000ffULL) << 56) | \
-		(uint64_t)(((uint64_t)(__x) & (uint64_t)0x000000000000ff00ULL) << 40) | \
-		(uint64_t)(((uint64_t)(__x) & (uint64_t)0x0000000000ff0000ULL) << 24) | \
-		(uint64_t)(((uint64_t)(__x) & (uint64_t)0x00000000ff000000ULL) <<  8) | \
-	        (uint64_t)(((uint64_t)(__x) & (uint64_t)0x000000ff00000000ULL) >>  8) | \
-		(uint64_t)(((uint64_t)(__x) & (uint64_t)0x0000ff0000000000ULL) >> 24) | \
-		(uint64_t)(((uint64_t)(__x) & (uint64_t)0x00ff000000000000ULL) >> 40) | \
-		(uint64_t)(((uint64_t)(__x) & (uint64_t)0xff00000000000000ULL) >> 56) )); \
-})
-
-#endif /* !HAVE_BYTESWAP_H */
 
 static inline uint16_t bswap16(uint16_t x)
 {

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 22 10:32:20 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 Dec 2011 10:32:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdfwW-0008Pd-Vo; Thu, 22 Dec 2011 10:32:08 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RdfwV-0008P3-9a
	for xen-devel@lists.xensource.com; Thu, 22 Dec 2011 10:32:07 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1324549919!8423291!2
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.7 required=7.0 tests=DATE_IN_PAST_48_96, RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12311 invoked from network); 22 Dec 2011 10:32:01 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Dec 2011 10:32:01 -0000
Received: by mail-ww0-f43.google.com with SMTP id ds11so13384173wgb.24
	for <xen-devel@lists.xensource.com>;
	Thu, 22 Dec 2011 02:32:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=pZqCAg3NtU4pn9bQWA/Bgn1mekbXNxlHfH8PXfskvOM=;
	b=egkn0aMRlyoFP9mBxQFrHjzewurSyvfLYeu8hnD09OakeyuuAyZMfNrJWMpoOFCJBX
	WhtQE2DzwWi0sSN4M0iWNhZRHNXAAsTeYISdve5EEzPUY6VfuWn3iJpebB2MJoz8j1dD
	0QLKumoFFJJGBm+uxVVkZB1nrTes+BYpliYYs=
Received: by 10.227.208.13 with SMTP id ga13mr12341964wbb.4.1324549921110;
	Thu, 22 Dec 2011 02:32:01 -0800 (PST)
Received: from alpine.localdomain (tina.upc.es. [147.83.39.243])
	by mx.google.com with ESMTPS id k5sm21270950wiz.9.2011.12.22.02.31.59
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 22 Dec 2011 02:31:59 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 32c735e9b6fc6250cb465d091e7fd30d95bf699e
Message-Id: <32c735e9b6fc6250cb46.1324370959@alpine.localdomain>
In-Reply-To: <patchbomb.1324370958@alpine.localdomain>
References: <patchbomb.1324370958@alpine.localdomain>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Tue, 20 Dec 2011 09:49:19 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 1 of 4 v3] blktap: remove local definitions and
 include byteswap.h
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1324366300 -3600
# Node ID 32c735e9b6fc6250cb465d091e7fd30d95bf699e
# Parent  cf68eb390e1bf2fa4bb005ffeccfd41a01c3f81d
blktap: remove local definitions and include byteswap.h

Use the same approach as tools/blktap2/include/libvhd.h, remove local
definitions of bswap* and include byteswap.h. Also remove the
HAVE_BYTESWAP_H ifdef, since it was not defined in this context (it's
defined by QEMU).

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r cf68eb390e1b -r 32c735e9b6fc tools/blktap/drivers/bswap.h
--- a/tools/blktap/drivers/bswap.h	Tue Dec 20 08:21:11 2011 +0100
+++ b/tools/blktap/drivers/bswap.h	Tue Dec 20 08:31:40 2011 +0100
@@ -13,45 +13,9 @@
 #define bswap_16(x) swap16(x)
 #define bswap_32(x) swap32(x)
 #define bswap_64(x) swap64(x)
-#else
+#elif defined(__linux__)
 
-#ifdef HAVE_BYTESWAP_H
 #include <byteswap.h>
-#else
-
-#define bswap_16(x) \
-({ \
-	uint16_t __x = (x); \
-	((uint16_t)( \
-		(((uint16_t)(__x) & (uint16_t)0x00ffU) << 8) | \
-		(((uint16_t)(__x) & (uint16_t)0xff00U) >> 8) )); \
-})
-
-#define bswap_32(x) \
-({ \
-	uint32_t __x = (x); \
-	((uint32_t)( \
-		(((uint32_t)(__x) & (uint32_t)0x000000ffUL) << 24) | \
-		(((uint32_t)(__x) & (uint32_t)0x0000ff00UL) <<  8) | \
-		(((uint32_t)(__x) & (uint32_t)0x00ff0000UL) >>  8) | \
-		(((uint32_t)(__x) & (uint32_t)0xff000000UL) >> 24) )); \
-})
-
-#define bswap_64(x) \
-({ \
-	uint64_t __x = (x); \
-	((uint64_t)( \
-		(uint64_t)(((uint64_t)(__x) & (uint64_t)0x00000000000000ffULL) << 56) | \
-		(uint64_t)(((uint64_t)(__x) & (uint64_t)0x000000000000ff00ULL) << 40) | \
-		(uint64_t)(((uint64_t)(__x) & (uint64_t)0x0000000000ff0000ULL) << 24) | \
-		(uint64_t)(((uint64_t)(__x) & (uint64_t)0x00000000ff000000ULL) <<  8) | \
-	        (uint64_t)(((uint64_t)(__x) & (uint64_t)0x000000ff00000000ULL) >>  8) | \
-		(uint64_t)(((uint64_t)(__x) & (uint64_t)0x0000ff0000000000ULL) >> 24) | \
-		(uint64_t)(((uint64_t)(__x) & (uint64_t)0x00ff000000000000ULL) >> 40) | \
-		(uint64_t)(((uint64_t)(__x) & (uint64_t)0xff00000000000000ULL) >> 56) )); \
-})
-
-#endif /* !HAVE_BYTESWAP_H */
 
 static inline uint16_t bswap16(uint16_t x)
 {

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 22 10:32:21 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 Dec 2011 10:32:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rdfwd-0008RE-A7; Thu, 22 Dec 2011 10:32:15 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1Rdfwb-0008Pb-Ce
	for xen-devel@lists.xensource.com; Thu, 22 Dec 2011 10:32:13 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1324549919!8423291!4
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.7 required=7.0 tests=DATE_IN_PAST_48_96, RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13202 invoked from network); 22 Dec 2011 10:32:07 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Dec 2011 10:32:07 -0000
Received: by mail-ww0-f43.google.com with SMTP id ds11so13384173wgb.24
	for <xen-devel@lists.xensource.com>;
	Thu, 22 Dec 2011 02:32:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=7Oo3YkCChZMg9oPB3M8WIbjne6vrSq7W6HWAtVjGKMM=;
	b=YtqLD2/va+4bJTMeqe+DWYmXv9EH2uVNI/PHUO6Xr2nOeh5fPtt2L717cCJvqpv8AK
	gwyAJTuB+iftCe6+0NLIjOCIfqQBLsxtgBJcXaaw3LNVPTZU2p6IMU+wO6bZGLfiBcfr
	V5yCRpVco0vRtDHfNFrOww6+UO/Kh7560UeLo=
Received: by 10.227.206.78 with SMTP id ft14mr9893236wbb.24.1324549927376;
	Thu, 22 Dec 2011 02:32:07 -0800 (PST)
Received: from alpine.localdomain (tina.upc.es. [147.83.39.243])
	by mx.google.com with ESMTPS id k5sm21270950wiz.9.2011.12.22.02.32.05
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 22 Dec 2011 02:32:06 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: f72b99fccfca694674259cc1c03c526a827b67ec
Message-Id: <f72b99fccfca69467425.1324370962@alpine.localdomain>
In-Reply-To: <patchbomb.1324370958@alpine.localdomain>
References: <patchbomb.1324370958@alpine.localdomain>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Tue, 20 Dec 2011 09:49:22 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 4 of 4 v3] blktap2/vhd: add -liconv when linking
 if using libiconv
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1324366300 -3600
# Node ID f72b99fccfca694674259cc1c03c526a827b67ec
# Parent  023519bfc8964ba9de3521b458d05baa9c8bf4e0
blktap2/vhd: add -liconv when linking if using libiconv

If libiconv is detected on the system add -liconv when linking the
libvhd library.

If -liconv is not added when compiling libvhd with libiconv the
following error occours when linking vhd-util and vhd-update:

gcc     -o vhd-util vhd-util.o -Llib -lvhd
lib/libvhd.so: undefined reference to `libiconv_open'
lib/libvhd.so: undefined reference to `libiconv_close'
lib/libvhd.so: undefined reference to `libiconv'

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 023519bfc896 -r f72b99fccfca tools/blktap2/vhd/lib/Makefile
--- a/tools/blktap2/vhd/lib/Makefile	Tue Dec 20 08:31:40 2011 +0100
+++ b/tools/blktap2/vhd/lib/Makefile	Tue Dec 20 08:31:40 2011 +0100
@@ -23,6 +23,10 @@ ifeq ($(CONFIG_Linux),y)
 LIBS            := -luuid
 endif
 
+ifeq ($(CONFIG_LIBICONV),y)
+LIBS            += -liconv
+endif
+
 LIB-SRCS        := libvhd.c
 LIB-SRCS        += libvhd-journal.c
 LIB-SRCS        += vhd-util-coalesce.c

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 22 10:32:21 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 Dec 2011 10:32:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rdfwd-0008RE-A7; Thu, 22 Dec 2011 10:32:15 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1Rdfwb-0008Pb-Ce
	for xen-devel@lists.xensource.com; Thu, 22 Dec 2011 10:32:13 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1324549919!8423291!4
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.7 required=7.0 tests=DATE_IN_PAST_48_96, RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13202 invoked from network); 22 Dec 2011 10:32:07 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Dec 2011 10:32:07 -0000
Received: by mail-ww0-f43.google.com with SMTP id ds11so13384173wgb.24
	for <xen-devel@lists.xensource.com>;
	Thu, 22 Dec 2011 02:32:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=7Oo3YkCChZMg9oPB3M8WIbjne6vrSq7W6HWAtVjGKMM=;
	b=YtqLD2/va+4bJTMeqe+DWYmXv9EH2uVNI/PHUO6Xr2nOeh5fPtt2L717cCJvqpv8AK
	gwyAJTuB+iftCe6+0NLIjOCIfqQBLsxtgBJcXaaw3LNVPTZU2p6IMU+wO6bZGLfiBcfr
	V5yCRpVco0vRtDHfNFrOww6+UO/Kh7560UeLo=
Received: by 10.227.206.78 with SMTP id ft14mr9893236wbb.24.1324549927376;
	Thu, 22 Dec 2011 02:32:07 -0800 (PST)
Received: from alpine.localdomain (tina.upc.es. [147.83.39.243])
	by mx.google.com with ESMTPS id k5sm21270950wiz.9.2011.12.22.02.32.05
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 22 Dec 2011 02:32:06 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: f72b99fccfca694674259cc1c03c526a827b67ec
Message-Id: <f72b99fccfca69467425.1324370962@alpine.localdomain>
In-Reply-To: <patchbomb.1324370958@alpine.localdomain>
References: <patchbomb.1324370958@alpine.localdomain>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Tue, 20 Dec 2011 09:49:22 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 4 of 4 v3] blktap2/vhd: add -liconv when linking
 if using libiconv
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1324366300 -3600
# Node ID f72b99fccfca694674259cc1c03c526a827b67ec
# Parent  023519bfc8964ba9de3521b458d05baa9c8bf4e0
blktap2/vhd: add -liconv when linking if using libiconv

If libiconv is detected on the system add -liconv when linking the
libvhd library.

If -liconv is not added when compiling libvhd with libiconv the
following error occours when linking vhd-util and vhd-update:

gcc     -o vhd-util vhd-util.o -Llib -lvhd
lib/libvhd.so: undefined reference to `libiconv_open'
lib/libvhd.so: undefined reference to `libiconv_close'
lib/libvhd.so: undefined reference to `libiconv'

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 023519bfc896 -r f72b99fccfca tools/blktap2/vhd/lib/Makefile
--- a/tools/blktap2/vhd/lib/Makefile	Tue Dec 20 08:31:40 2011 +0100
+++ b/tools/blktap2/vhd/lib/Makefile	Tue Dec 20 08:31:40 2011 +0100
@@ -23,6 +23,10 @@ ifeq ($(CONFIG_Linux),y)
 LIBS            := -luuid
 endif
 
+ifeq ($(CONFIG_LIBICONV),y)
+LIBS            += -liconv
+endif
+
 LIB-SRCS        := libvhd.c
 LIB-SRCS        += libvhd-journal.c
 LIB-SRCS        += vhd-util-coalesce.c

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 22 10:32:21 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 Dec 2011 10:32:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rdfwa-0008Qa-Si; Thu, 22 Dec 2011 10:32:12 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RdfwZ-0008PG-9b
	for xen-devel@lists.xensource.com; Thu, 22 Dec 2011 10:32:11 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1324549919!8423291!3
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.7 required=7.0 tests=DATE_IN_PAST_48_96, RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12949 invoked from network); 22 Dec 2011 10:32:05 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Dec 2011 10:32:05 -0000
Received: by mail-ww0-f43.google.com with SMTP id ds11so13384173wgb.24
	for <xen-devel@lists.xensource.com>;
	Thu, 22 Dec 2011 02:32:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=I6tonGPWflgZAQmT1xels+KKNUxyQZ9bci77DjcnLVA=;
	b=k24h3IQWolvAKXzTx1CF3I/n8oR1pbgdZMuS9PydyCbYdz+pufcGXNqi4BfVRg4XsU
	YfuJhjLjIFybolvZzWJeAHPNefUB0fqUz6ac4T03NeE6tkRiMNKcHAQMls/52gmFqybd
	q2Y6pMnBeF3MrV08Y/8X/CZrdjq2XJZ+ECawA=
Received: by 10.227.198.19 with SMTP id em19mr12275623wbb.14.1324549925233;
	Thu, 22 Dec 2011 02:32:05 -0800 (PST)
Received: from alpine.localdomain (tina.upc.es. [147.83.39.243])
	by mx.google.com with ESMTPS id k5sm21270950wiz.9.2011.12.22.02.32.03
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 22 Dec 2011 02:32:04 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 023519bfc8964ba9de3521b458d05baa9c8bf4e0
Message-Id: <023519bfc8964ba9de35.1324370961@alpine.localdomain>
In-Reply-To: <patchbomb.1324370958@alpine.localdomain>
References: <patchbomb.1324370958@alpine.localdomain>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Tue, 20 Dec 2011 09:49:21 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 3 of 4 v3] build: detect is libiconv is present
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1324366300 -3600
# Node ID 023519bfc8964ba9de3521b458d05baa9c8bf4e0
# Parent  2fd10f2605439da1541646eda7276c8ff390b9de
build: detect is libiconv is present

Detect if libiconv is present in the system, since we will have to
link against it when using iconv.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 2fd10f260543 -r 023519bfc896 Config.mk
--- a/Config.mk	Tue Dec 20 08:31:40 2011 +0100
+++ b/Config.mk	Tue Dec 20 08:31:40 2011 +0100
@@ -181,6 +181,11 @@ CHECK_INCLUDES = $(EXTRA_INCLUDES) $(PRE
 EMBEDDED_EXTRA_CFLAGS := -nopie -fno-stack-protector -fno-stack-protector-all
 EMBEDDED_EXTRA_CFLAGS += -fno-exceptions
 
+CONFIG_LIBICONV   := $(shell export OS="`uname -s`"; \
+                       export CHECK_LIB="$(CHECK_LIB)"; \
+                       . $(XEN_ROOT)/tools/check/funcs.sh; \
+                       has_lib libiconv.so && echo 'y' || echo 'n')
+
 # Enable XSM security module (by default, Flask).
 XSM_ENABLE ?= n
 FLASK_ENABLE ?= $(XSM_ENABLE)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 22 10:32:21 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 Dec 2011 10:32:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rdfwa-0008Qa-Si; Thu, 22 Dec 2011 10:32:12 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RdfwZ-0008PG-9b
	for xen-devel@lists.xensource.com; Thu, 22 Dec 2011 10:32:11 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1324549919!8423291!3
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.7 required=7.0 tests=DATE_IN_PAST_48_96, RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12949 invoked from network); 22 Dec 2011 10:32:05 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Dec 2011 10:32:05 -0000
Received: by mail-ww0-f43.google.com with SMTP id ds11so13384173wgb.24
	for <xen-devel@lists.xensource.com>;
	Thu, 22 Dec 2011 02:32:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=I6tonGPWflgZAQmT1xels+KKNUxyQZ9bci77DjcnLVA=;
	b=k24h3IQWolvAKXzTx1CF3I/n8oR1pbgdZMuS9PydyCbYdz+pufcGXNqi4BfVRg4XsU
	YfuJhjLjIFybolvZzWJeAHPNefUB0fqUz6ac4T03NeE6tkRiMNKcHAQMls/52gmFqybd
	q2Y6pMnBeF3MrV08Y/8X/CZrdjq2XJZ+ECawA=
Received: by 10.227.198.19 with SMTP id em19mr12275623wbb.14.1324549925233;
	Thu, 22 Dec 2011 02:32:05 -0800 (PST)
Received: from alpine.localdomain (tina.upc.es. [147.83.39.243])
	by mx.google.com with ESMTPS id k5sm21270950wiz.9.2011.12.22.02.32.03
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 22 Dec 2011 02:32:04 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 023519bfc8964ba9de3521b458d05baa9c8bf4e0
Message-Id: <023519bfc8964ba9de35.1324370961@alpine.localdomain>
In-Reply-To: <patchbomb.1324370958@alpine.localdomain>
References: <patchbomb.1324370958@alpine.localdomain>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Tue, 20 Dec 2011 09:49:21 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 3 of 4 v3] build: detect is libiconv is present
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1324366300 -3600
# Node ID 023519bfc8964ba9de3521b458d05baa9c8bf4e0
# Parent  2fd10f2605439da1541646eda7276c8ff390b9de
build: detect is libiconv is present

Detect if libiconv is present in the system, since we will have to
link against it when using iconv.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 2fd10f260543 -r 023519bfc896 Config.mk
--- a/Config.mk	Tue Dec 20 08:31:40 2011 +0100
+++ b/Config.mk	Tue Dec 20 08:31:40 2011 +0100
@@ -181,6 +181,11 @@ CHECK_INCLUDES = $(EXTRA_INCLUDES) $(PRE
 EMBEDDED_EXTRA_CFLAGS := -nopie -fno-stack-protector -fno-stack-protector-all
 EMBEDDED_EXTRA_CFLAGS += -fno-exceptions
 
+CONFIG_LIBICONV   := $(shell export OS="`uname -s`"; \
+                       export CHECK_LIB="$(CHECK_LIB)"; \
+                       . $(XEN_ROOT)/tools/check/funcs.sh; \
+                       has_lib libiconv.so && echo 'y' || echo 'n')
+
 # Enable XSM security module (by default, Flask).
 XSM_ENABLE ?= n
 FLASK_ENABLE ?= $(XSM_ENABLE)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 22 11:34:50 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 Dec 2011 11:34:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rdguk-00030K-4X; Thu, 22 Dec 2011 11:34:22 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1Rdgui-000308-FV
	for xen-devel@lists.xensource.com; Thu, 22 Dec 2011 11:34:21 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-16.tower-216.messagelabs.com!1324553239!8285624!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2387 invoked from network); 22 Dec 2011 11:27:19 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-16.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 22 Dec 2011 11:27:19 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1Rdgnt-00016W-PS; Thu, 22 Dec 2011 11:27:17 +0000
Date: Thu, 22 Dec 2011 11:27:17 +0000
From: Tim Deegan <tim@xen.org>
To: Olaf Hering <olaf@aepfle.de>
Message-ID: <20111222112717.GA4094@ocelot.phlegethon.org>
References: <d910d738f31b4ee1a6b0.1324294786@probook.site>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <d910d738f31b4ee1a6b0.1324294786@probook.site>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] mem_event: use wait queue when ring is full
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 12:39 +0100 on 19 Dec (1324298386), Olaf Hering wrote:
> mem_event: use wait queue when ring is full
> 
> This change is based on an idea/patch from Adin Scannell.
> 
> If the ring is full, put the current vcpu to sleep if it belongs to the
> target domain. The wakeup happens in the p2m_*_resume functions. Wakeup
> will take the number of free slots into account.
> 
> A request from foreign domain has to succeed once a slot was claimed
> because such vcpus can not sleep.
> 
> This change fixes also a bug in p2m_mem_paging_drop_page(). Up to now a
> full ring will lead to harmless inconsistency in the pager.

Thanks.  As before, I'm happy to apply this when Adin or Andres acks it. 

Cheers,

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 22 11:34:50 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 Dec 2011 11:34:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rdguk-00030K-4X; Thu, 22 Dec 2011 11:34:22 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1Rdgui-000308-FV
	for xen-devel@lists.xensource.com; Thu, 22 Dec 2011 11:34:21 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-16.tower-216.messagelabs.com!1324553239!8285624!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2387 invoked from network); 22 Dec 2011 11:27:19 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-16.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 22 Dec 2011 11:27:19 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1Rdgnt-00016W-PS; Thu, 22 Dec 2011 11:27:17 +0000
Date: Thu, 22 Dec 2011 11:27:17 +0000
From: Tim Deegan <tim@xen.org>
To: Olaf Hering <olaf@aepfle.de>
Message-ID: <20111222112717.GA4094@ocelot.phlegethon.org>
References: <d910d738f31b4ee1a6b0.1324294786@probook.site>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <d910d738f31b4ee1a6b0.1324294786@probook.site>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] mem_event: use wait queue when ring is full
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 12:39 +0100 on 19 Dec (1324298386), Olaf Hering wrote:
> mem_event: use wait queue when ring is full
> 
> This change is based on an idea/patch from Adin Scannell.
> 
> If the ring is full, put the current vcpu to sleep if it belongs to the
> target domain. The wakeup happens in the p2m_*_resume functions. Wakeup
> will take the number of free slots into account.
> 
> A request from foreign domain has to succeed once a slot was claimed
> because such vcpus can not sleep.
> 
> This change fixes also a bug in p2m_mem_paging_drop_page(). Up to now a
> full ring will lead to harmless inconsistency in the pager.

Thanks.  As before, I'm happy to apply this when Adin or Andres acks it. 

Cheers,

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 22 11:35:40 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 Dec 2011 11:35:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rdgvc-00036M-J9; Thu, 22 Dec 2011 11:35:16 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1Rdgvb-00035y-2T
	for xen-devel@lists.xensource.com; Thu, 22 Dec 2011 11:35:15 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1324553708!8417933!1
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.7 required=7.0 tests=DATE_IN_PAST_48_96, RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32134 invoked from network); 22 Dec 2011 11:35:08 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Dec 2011 11:35:08 -0000
Received: by wgbds11 with SMTP id ds11so13467690wgb.24
	for <xen-devel@lists.xensource.com>;
	Thu, 22 Dec 2011 03:35:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:user-agent:date:from:to;
	bh=82WtBGmayBKFQQzMp3Cv1+yiXDIushGDNaGNxoPKNKU=;
	b=rqc/W+kZzPVBNL1xP6ALbaBsj3UQLmCBv+NmdrADYvmjxszX4UIIRrYP1XQfN5hzyf
	IC+CS+jahI2LsLu3VAdClz46q9SQklp7ufG52Lq+iDDFVDLIHRN2l+QYBTXuzy2fNC9p
	i8R3/gzn8FeSH83EthJigyF5QR1WwIdnDRXRE=
Received: by 10.227.205.203 with SMTP id fr11mr10049668wbb.18.1324553708112;
	Thu, 22 Dec 2011 03:35:08 -0800 (PST)
Received: from alpine.localdomain (tina.upc.es. [147.83.39.243])
	by mx.google.com with ESMTPS id k5sm21705478wiz.9.2011.12.22.03.35.06
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 22 Dec 2011 03:35:06 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: f4ff3ce53fd2286def61e22222154e3c0a408667
Message-Id: <f4ff3ce53fd2286def61.1324374813@alpine.localdomain>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Tue, 20 Dec 2011 10:53:33 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH] libxl: add support for yajl 2.x
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1324374796 -3600
# Node ID f4ff3ce53fd2286def61e22222154e3c0a408667
# Parent  f72b99fccfca694674259cc1c03c526a827b67ec
libxl: add support for yajl 2.x

This patch adds support for yajl versions 2.x, while retaining 1.x
compatibility. This patch adds quite a lot of #ifdefs all over the
json code, so I'm open to suggestions if there's a better way to
handle this.

Tested with yajl 2.0.3 and 1.0.12.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r f72b99fccfca -r f4ff3ce53fd2 tools/check/check_yajl_devel
--- a/tools/check/check_yajl_devel	Tue Dec 20 08:31:40 2011 +0100
+++ b/tools/check/check_yajl_devel	Tue Dec 20 10:53:16 2011 +0100
@@ -5,4 +5,5 @@
 
 has_header yajl/yajl_parse.h || fail "can't find yajl/yajl_parse.h"
 has_header yajl/yajl_gen.h || fail "can't find yajl/yajl_gen.h"
+has_header yajl/yajl_version.h || fail "can't find yajl/yajl_version.h"
 has_lib libyajl.so || fail "can't find libyajl.so"
diff -r f72b99fccfca -r f4ff3ce53fd2 tools/check/check_yajl_lib
--- a/tools/check/check_yajl_lib	Tue Dec 20 08:31:40 2011 +0100
+++ b/tools/check/check_yajl_lib	Tue Dec 20 10:53:16 2011 +0100
@@ -3,4 +3,4 @@
 
 . ./funcs.sh
 
-has_lib libyajl.so.1 || fail "can't find libyajl.so.1 version 1"
+has_lib libyajl.so.1 || has_lib libyajl.so.2 || fail "can't find libyajl.so.1 version 1 or libyajl.so.2 version 2"
diff -r f72b99fccfca -r f4ff3ce53fd2 tools/libxl/libxl_json.c
--- a/tools/libxl/libxl_json.c	Tue Dec 20 08:31:40 2011 +0100
+++ b/tools/libxl/libxl_json.c	Tue Dec 20 10:53:16 2011 +0100
@@ -519,7 +519,11 @@ static bool is_decimal(const char *s, un
     return false;
 }
 
+#ifdef HAVE_YAJL_V2
+static int json_callback_number(void *opaque, const char *s, size_t len)
+#else
 static int json_callback_number(void *opaque, const char *s, unsigned int len)
+#endif
 {
     libxl__yajl_ctx *ctx = opaque;
     libxl__json_object *obj = NULL;
@@ -575,8 +579,13 @@ out:
     return 1;
 }
 
+#ifdef HAVE_YAJL_V2
+static int json_callback_string(void *opaque, const unsigned char *str,
+                                size_t len)
+#else
 static int json_callback_string(void *opaque, const unsigned char *str,
                                 unsigned int len)
+#endif
 {
     libxl__yajl_ctx *ctx = opaque;
     char *t = NULL;
@@ -608,8 +617,13 @@ static int json_callback_string(void *op
     return 1;
 }
 
+#ifdef HAVE_YAJL_V2
+static int json_callback_map_key(void *opaque, const unsigned char *str,
+                                 size_t len)
+#else
 static int json_callback_map_key(void *opaque, const unsigned char *str,
                                  unsigned int len)
+#endif
 {
     libxl__yajl_ctx *ctx = opaque;
     char *t = NULL;
@@ -772,17 +786,26 @@ libxl__json_object *libxl__json_parse(li
     DEBUG_GEN_ALLOC(&yajl_ctx);
 
     if (yajl_ctx.hand == NULL) {
+#ifdef HAVE_YAJL_V2
+        yajl_ctx.hand = yajl_alloc(&callbacks, NULL, &yajl_ctx);
+#else
         yajl_parser_config cfg = {
             .allowComments = 1,
             .checkUTF8 = 1,
         };
         yajl_ctx.hand = yajl_alloc(&callbacks, &cfg, NULL, &yajl_ctx);
+#endif
     }
     status = yajl_parse(yajl_ctx.hand, (const unsigned char *)s, strlen(s));
     if (status != yajl_status_ok)
         goto out;
+    
+#ifdef HAVE_YAJL_V2
+    status = yajl_complete_parse(yajl_ctx.hand);
+#else
+    status = yajl_parse_complete(yajl_ctx.hand);
+#endif
 
-    status = yajl_parse_complete(yajl_ctx.hand);
     if (status != yajl_status_ok)
         goto out;
 
@@ -834,14 +857,25 @@ static const char *yajl_gen_status_to_st
 char *libxl__object_to_json(libxl_ctx *ctx, const char *type,
                             libxl__gen_json_callback gen, void *p)
 {
+#ifndef HAVE_YAJL_V2
     yajl_gen_config conf = { 1, "    " };
+#endif
     const unsigned char *buf;
     char *ret = NULL;
+#ifdef HAVE_YAJL_V2
+    size_t len = 0;
+#else
     unsigned int len = 0;
+#endif
     yajl_gen_status s;
     yajl_gen hand;
 
+#ifdef HAVE_YAJL_V2
+    hand = yajl_gen_alloc(NULL);
+#else
     hand = yajl_gen_alloc(&conf, NULL);
+#endif
+
     if (!hand)
         return NULL;
 
diff -r f72b99fccfca -r f4ff3ce53fd2 tools/libxl/libxl_json.h
--- a/tools/libxl/libxl_json.h	Tue Dec 20 08:31:40 2011 +0100
+++ b/tools/libxl/libxl_json.h	Tue Dec 20 10:53:16 2011 +0100
@@ -16,8 +16,14 @@
 #define LIBXL_JSON_H
 
 #include <yajl/yajl_gen.h>
+#include <yajl/yajl_version.h>
 
 #include <_libxl_types_json.h>
 #include <_libxl_types_internal_json.h>
 
+/* YAJL version check */
+#if defined(YAJL_MAJOR) && (YAJL_MAJOR > 1)
+#  define HAVE_YAJL_V2 1
+#endif
+
 #endif /* LIBXL_JSON_H */
diff -r f72b99fccfca -r f4ff3ce53fd2 tools/libxl/libxl_qmp.c
--- a/tools/libxl/libxl_qmp.c	Tue Dec 20 08:31:40 2011 +0100
+++ b/tools/libxl/libxl_qmp.c	Tue Dec 20 10:53:16 2011 +0100
@@ -453,15 +453,26 @@ static char *qmp_send_prepare(libxl__gc 
                               qmp_callback_t callback, void *opaque,
                               qmp_request_context *context)
 {
+#ifndef HAVE_YAJL_V2
     yajl_gen_config conf = { 0, NULL };
+#endif
     const unsigned char *buf = NULL;
     char *ret = NULL;
+#ifdef HAVE_YAJL_V2
+    size_t len = 0;
+#else
     unsigned int len = 0;
+#endif
     yajl_gen_status s;
     yajl_gen hand;
     callback_id_pair *elm = NULL;
 
+#ifdef HAVE_YAJL_V2
+    hand = yajl_gen_alloc(NULL);
+#else
     hand = yajl_gen_alloc(&conf, NULL);
+#endif
+
     if (!hand) {
         return NULL;
     }

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 22 11:35:40 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 Dec 2011 11:35:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rdgvc-00036M-J9; Thu, 22 Dec 2011 11:35:16 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1Rdgvb-00035y-2T
	for xen-devel@lists.xensource.com; Thu, 22 Dec 2011 11:35:15 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1324553708!8417933!1
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.7 required=7.0 tests=DATE_IN_PAST_48_96, RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32134 invoked from network); 22 Dec 2011 11:35:08 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Dec 2011 11:35:08 -0000
Received: by wgbds11 with SMTP id ds11so13467690wgb.24
	for <xen-devel@lists.xensource.com>;
	Thu, 22 Dec 2011 03:35:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:user-agent:date:from:to;
	bh=82WtBGmayBKFQQzMp3Cv1+yiXDIushGDNaGNxoPKNKU=;
	b=rqc/W+kZzPVBNL1xP6ALbaBsj3UQLmCBv+NmdrADYvmjxszX4UIIRrYP1XQfN5hzyf
	IC+CS+jahI2LsLu3VAdClz46q9SQklp7ufG52Lq+iDDFVDLIHRN2l+QYBTXuzy2fNC9p
	i8R3/gzn8FeSH83EthJigyF5QR1WwIdnDRXRE=
Received: by 10.227.205.203 with SMTP id fr11mr10049668wbb.18.1324553708112;
	Thu, 22 Dec 2011 03:35:08 -0800 (PST)
Received: from alpine.localdomain (tina.upc.es. [147.83.39.243])
	by mx.google.com with ESMTPS id k5sm21705478wiz.9.2011.12.22.03.35.06
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 22 Dec 2011 03:35:06 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: f4ff3ce53fd2286def61e22222154e3c0a408667
Message-Id: <f4ff3ce53fd2286def61.1324374813@alpine.localdomain>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Tue, 20 Dec 2011 10:53:33 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH] libxl: add support for yajl 2.x
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1324374796 -3600
# Node ID f4ff3ce53fd2286def61e22222154e3c0a408667
# Parent  f72b99fccfca694674259cc1c03c526a827b67ec
libxl: add support for yajl 2.x

This patch adds support for yajl versions 2.x, while retaining 1.x
compatibility. This patch adds quite a lot of #ifdefs all over the
json code, so I'm open to suggestions if there's a better way to
handle this.

Tested with yajl 2.0.3 and 1.0.12.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r f72b99fccfca -r f4ff3ce53fd2 tools/check/check_yajl_devel
--- a/tools/check/check_yajl_devel	Tue Dec 20 08:31:40 2011 +0100
+++ b/tools/check/check_yajl_devel	Tue Dec 20 10:53:16 2011 +0100
@@ -5,4 +5,5 @@
 
 has_header yajl/yajl_parse.h || fail "can't find yajl/yajl_parse.h"
 has_header yajl/yajl_gen.h || fail "can't find yajl/yajl_gen.h"
+has_header yajl/yajl_version.h || fail "can't find yajl/yajl_version.h"
 has_lib libyajl.so || fail "can't find libyajl.so"
diff -r f72b99fccfca -r f4ff3ce53fd2 tools/check/check_yajl_lib
--- a/tools/check/check_yajl_lib	Tue Dec 20 08:31:40 2011 +0100
+++ b/tools/check/check_yajl_lib	Tue Dec 20 10:53:16 2011 +0100
@@ -3,4 +3,4 @@
 
 . ./funcs.sh
 
-has_lib libyajl.so.1 || fail "can't find libyajl.so.1 version 1"
+has_lib libyajl.so.1 || has_lib libyajl.so.2 || fail "can't find libyajl.so.1 version 1 or libyajl.so.2 version 2"
diff -r f72b99fccfca -r f4ff3ce53fd2 tools/libxl/libxl_json.c
--- a/tools/libxl/libxl_json.c	Tue Dec 20 08:31:40 2011 +0100
+++ b/tools/libxl/libxl_json.c	Tue Dec 20 10:53:16 2011 +0100
@@ -519,7 +519,11 @@ static bool is_decimal(const char *s, un
     return false;
 }
 
+#ifdef HAVE_YAJL_V2
+static int json_callback_number(void *opaque, const char *s, size_t len)
+#else
 static int json_callback_number(void *opaque, const char *s, unsigned int len)
+#endif
 {
     libxl__yajl_ctx *ctx = opaque;
     libxl__json_object *obj = NULL;
@@ -575,8 +579,13 @@ out:
     return 1;
 }
 
+#ifdef HAVE_YAJL_V2
+static int json_callback_string(void *opaque, const unsigned char *str,
+                                size_t len)
+#else
 static int json_callback_string(void *opaque, const unsigned char *str,
                                 unsigned int len)
+#endif
 {
     libxl__yajl_ctx *ctx = opaque;
     char *t = NULL;
@@ -608,8 +617,13 @@ static int json_callback_string(void *op
     return 1;
 }
 
+#ifdef HAVE_YAJL_V2
+static int json_callback_map_key(void *opaque, const unsigned char *str,
+                                 size_t len)
+#else
 static int json_callback_map_key(void *opaque, const unsigned char *str,
                                  unsigned int len)
+#endif
 {
     libxl__yajl_ctx *ctx = opaque;
     char *t = NULL;
@@ -772,17 +786,26 @@ libxl__json_object *libxl__json_parse(li
     DEBUG_GEN_ALLOC(&yajl_ctx);
 
     if (yajl_ctx.hand == NULL) {
+#ifdef HAVE_YAJL_V2
+        yajl_ctx.hand = yajl_alloc(&callbacks, NULL, &yajl_ctx);
+#else
         yajl_parser_config cfg = {
             .allowComments = 1,
             .checkUTF8 = 1,
         };
         yajl_ctx.hand = yajl_alloc(&callbacks, &cfg, NULL, &yajl_ctx);
+#endif
     }
     status = yajl_parse(yajl_ctx.hand, (const unsigned char *)s, strlen(s));
     if (status != yajl_status_ok)
         goto out;
+    
+#ifdef HAVE_YAJL_V2
+    status = yajl_complete_parse(yajl_ctx.hand);
+#else
+    status = yajl_parse_complete(yajl_ctx.hand);
+#endif
 
-    status = yajl_parse_complete(yajl_ctx.hand);
     if (status != yajl_status_ok)
         goto out;
 
@@ -834,14 +857,25 @@ static const char *yajl_gen_status_to_st
 char *libxl__object_to_json(libxl_ctx *ctx, const char *type,
                             libxl__gen_json_callback gen, void *p)
 {
+#ifndef HAVE_YAJL_V2
     yajl_gen_config conf = { 1, "    " };
+#endif
     const unsigned char *buf;
     char *ret = NULL;
+#ifdef HAVE_YAJL_V2
+    size_t len = 0;
+#else
     unsigned int len = 0;
+#endif
     yajl_gen_status s;
     yajl_gen hand;
 
+#ifdef HAVE_YAJL_V2
+    hand = yajl_gen_alloc(NULL);
+#else
     hand = yajl_gen_alloc(&conf, NULL);
+#endif
+
     if (!hand)
         return NULL;
 
diff -r f72b99fccfca -r f4ff3ce53fd2 tools/libxl/libxl_json.h
--- a/tools/libxl/libxl_json.h	Tue Dec 20 08:31:40 2011 +0100
+++ b/tools/libxl/libxl_json.h	Tue Dec 20 10:53:16 2011 +0100
@@ -16,8 +16,14 @@
 #define LIBXL_JSON_H
 
 #include <yajl/yajl_gen.h>
+#include <yajl/yajl_version.h>
 
 #include <_libxl_types_json.h>
 #include <_libxl_types_internal_json.h>
 
+/* YAJL version check */
+#if defined(YAJL_MAJOR) && (YAJL_MAJOR > 1)
+#  define HAVE_YAJL_V2 1
+#endif
+
 #endif /* LIBXL_JSON_H */
diff -r f72b99fccfca -r f4ff3ce53fd2 tools/libxl/libxl_qmp.c
--- a/tools/libxl/libxl_qmp.c	Tue Dec 20 08:31:40 2011 +0100
+++ b/tools/libxl/libxl_qmp.c	Tue Dec 20 10:53:16 2011 +0100
@@ -453,15 +453,26 @@ static char *qmp_send_prepare(libxl__gc 
                               qmp_callback_t callback, void *opaque,
                               qmp_request_context *context)
 {
+#ifndef HAVE_YAJL_V2
     yajl_gen_config conf = { 0, NULL };
+#endif
     const unsigned char *buf = NULL;
     char *ret = NULL;
+#ifdef HAVE_YAJL_V2
+    size_t len = 0;
+#else
     unsigned int len = 0;
+#endif
     yajl_gen_status s;
     yajl_gen hand;
     callback_id_pair *elm = NULL;
 
+#ifdef HAVE_YAJL_V2
+    hand = yajl_gen_alloc(NULL);
+#else
     hand = yajl_gen_alloc(&conf, NULL);
+#endif
+
     if (!hand) {
         return NULL;
     }

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 22 11:51:21 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 Dec 2011 11:51:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdhAr-0003q2-8T; Thu, 22 Dec 2011 11:51:01 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RdhAp-0003pu-MJ
	for xen-devel@lists.xensource.com; Thu, 22 Dec 2011 11:50:59 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1324554653!3738381!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29840 invoked from network); 22 Dec 2011 11:50:53 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-2.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 22 Dec 2011 11:50:53 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 22 Dec 2011 11:50:52 +0000
Message-Id: <4EF327E2020000780006993E@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 22 Dec 2011 11:51:46 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
References: <4EF3018D020000780006986E@nat28.tlf.novell.com>
	<1324547820.7877.71.camel@zakaz.uk.xensource.com>
In-Reply-To: <1324547820.7877.71.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Jens Axboe <axboe@kernel.dk>, Jeremy Fitzhardinge <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"FlorianSchandinat@gmx.de" <FlorianSchandinat@gmx.de>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"dmitry.torokhov@gmail.com" <dmitry.torokhov@gmail.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Konrad Rzeszutek Wilk <konrad@darnok.org>,
	"davem@davemloft.net" <davem@davemloft.net>
Subject: Re: [Xen-devel] [PATCH,
 v2] Xen: consolidate and simplify struct xenbus_driver instantiation
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 22.12.11 at 10:57, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Thu, 2011-12-22 at 09:08 +0000, Jan Beulich wrote:
>> The 'name', 'owner', and 'mod_name' members are redundant with the
>> identically named fields in the 'driver' sub-structure. Rather than
>> switching each instance to specify these fields explicitly, introduce
>> a macro to simplify this.
>> 
>> Eliminate further redundancy by allowing the drvname argument to
>> DEFINE_XENBUS_DRIVER() to be blank (in which case the first entry from
>> the ID table will be used for .driver.name).
> 
> Any reason not to always use DRV_NAME here (which is generally a bit
> more specific e.g. "xen-foofront" rather than "foo") and rely on the id
> table for the shorter names used in xenstore?

That would imply that DRV_NAME is always defined, but I don't
see this being the case.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 22 11:51:21 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 Dec 2011 11:51:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdhAr-0003q2-8T; Thu, 22 Dec 2011 11:51:01 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RdhAp-0003pu-MJ
	for xen-devel@lists.xensource.com; Thu, 22 Dec 2011 11:50:59 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1324554653!3738381!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29840 invoked from network); 22 Dec 2011 11:50:53 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-2.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 22 Dec 2011 11:50:53 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 22 Dec 2011 11:50:52 +0000
Message-Id: <4EF327E2020000780006993E@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 22 Dec 2011 11:51:46 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
References: <4EF3018D020000780006986E@nat28.tlf.novell.com>
	<1324547820.7877.71.camel@zakaz.uk.xensource.com>
In-Reply-To: <1324547820.7877.71.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Jens Axboe <axboe@kernel.dk>, Jeremy Fitzhardinge <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"FlorianSchandinat@gmx.de" <FlorianSchandinat@gmx.de>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"dmitry.torokhov@gmail.com" <dmitry.torokhov@gmail.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Konrad Rzeszutek Wilk <konrad@darnok.org>,
	"davem@davemloft.net" <davem@davemloft.net>
Subject: Re: [Xen-devel] [PATCH,
 v2] Xen: consolidate and simplify struct xenbus_driver instantiation
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 22.12.11 at 10:57, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Thu, 2011-12-22 at 09:08 +0000, Jan Beulich wrote:
>> The 'name', 'owner', and 'mod_name' members are redundant with the
>> identically named fields in the 'driver' sub-structure. Rather than
>> switching each instance to specify these fields explicitly, introduce
>> a macro to simplify this.
>> 
>> Eliminate further redundancy by allowing the drvname argument to
>> DEFINE_XENBUS_DRIVER() to be blank (in which case the first entry from
>> the ID table will be used for .driver.name).
> 
> Any reason not to always use DRV_NAME here (which is generally a bit
> more specific e.g. "xen-foofront" rather than "foo") and rely on the id
> table for the shorter names used in xenstore?

That would imply that DRV_NAME is always defined, but I don't
see this being the case.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 22 11:58:07 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 Dec 2011 11:58:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdhHR-00040u-3i; Thu, 22 Dec 2011 11:57:49 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RdhHP-00040j-A4
	for xen-devel@lists.xensource.com; Thu, 22 Dec 2011 11:57:47 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1324555019!51644221!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Nzk5NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31211 invoked from network); 22 Dec 2011 11:56:59 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Dec 2011 11:56:59 -0000
X-IronPort-AV: E=Sophos;i="4.71,392,1320624000"; 
   d="scan'208";a="9631151"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Dec 2011 11:57:41 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 22 Dec 2011 11:57:41 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Thu, 22 Dec 2011 11:57:40 +0000
In-Reply-To: <4EF327E2020000780006993E@nat28.tlf.novell.com>
References: <4EF3018D020000780006986E@nat28.tlf.novell.com>
	<1324547820.7877.71.camel@zakaz.uk.xensource.com>
	<4EF327E2020000780006993E@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1324555060.7877.84.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Jens Axboe <axboe@kernel.dk>, Jeremy Fitzhardinge <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"FlorianSchandinat@gmx.de" <FlorianSchandinat@gmx.de>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"dmitry.torokhov@gmail.com" <dmitry.torokhov@gmail.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Konrad Rzeszutek Wilk <konrad@darnok.org>,
	"davem@davemloft.net" <davem@davemloft.net>
Subject: Re: [Xen-devel] [PATCH,
 v2] Xen: consolidate and simplify struct xenbus_driver instantiation
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2011-12-22 at 11:51 +0000, Jan Beulich wrote:
> >>> On 22.12.11 at 10:57, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > On Thu, 2011-12-22 at 09:08 +0000, Jan Beulich wrote:
> >> The 'name', 'owner', and 'mod_name' members are redundant with the
> >> identically named fields in the 'driver' sub-structure. Rather than
> >> switching each instance to specify these fields explicitly, introduce
> >> a macro to simplify this.
> >> 
> >> Eliminate further redundancy by allowing the drvname argument to
> >> DEFINE_XENBUS_DRIVER() to be blank (in which case the first entry from
> >> the ID table will be used for .driver.name).
> > 
> > Any reason not to always use DRV_NAME here (which is generally a bit
> > more specific e.g. "xen-foofront" rather than "foo") and rely on the id
> > table for the shorter names used in xenstore?
> 
> That would imply that DRV_NAME is always defined, but I don't
> see this being the case.

My mistake, I thought it was a Kbuild thing.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 22 11:58:07 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 Dec 2011 11:58:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdhHR-00040u-3i; Thu, 22 Dec 2011 11:57:49 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RdhHP-00040j-A4
	for xen-devel@lists.xensource.com; Thu, 22 Dec 2011 11:57:47 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1324555019!51644221!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Nzk5NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31211 invoked from network); 22 Dec 2011 11:56:59 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Dec 2011 11:56:59 -0000
X-IronPort-AV: E=Sophos;i="4.71,392,1320624000"; 
   d="scan'208";a="9631151"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Dec 2011 11:57:41 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 22 Dec 2011 11:57:41 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Thu, 22 Dec 2011 11:57:40 +0000
In-Reply-To: <4EF327E2020000780006993E@nat28.tlf.novell.com>
References: <4EF3018D020000780006986E@nat28.tlf.novell.com>
	<1324547820.7877.71.camel@zakaz.uk.xensource.com>
	<4EF327E2020000780006993E@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1324555060.7877.84.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Jens Axboe <axboe@kernel.dk>, Jeremy Fitzhardinge <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"FlorianSchandinat@gmx.de" <FlorianSchandinat@gmx.de>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"dmitry.torokhov@gmail.com" <dmitry.torokhov@gmail.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Konrad Rzeszutek Wilk <konrad@darnok.org>,
	"davem@davemloft.net" <davem@davemloft.net>
Subject: Re: [Xen-devel] [PATCH,
 v2] Xen: consolidate and simplify struct xenbus_driver instantiation
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2011-12-22 at 11:51 +0000, Jan Beulich wrote:
> >>> On 22.12.11 at 10:57, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > On Thu, 2011-12-22 at 09:08 +0000, Jan Beulich wrote:
> >> The 'name', 'owner', and 'mod_name' members are redundant with the
> >> identically named fields in the 'driver' sub-structure. Rather than
> >> switching each instance to specify these fields explicitly, introduce
> >> a macro to simplify this.
> >> 
> >> Eliminate further redundancy by allowing the drvname argument to
> >> DEFINE_XENBUS_DRIVER() to be blank (in which case the first entry from
> >> the ID table will be used for .driver.name).
> > 
> > Any reason not to always use DRV_NAME here (which is generally a bit
> > more specific e.g. "xen-foofront" rather than "foo") and rely on the id
> > table for the shorter names used in xenstore?
> 
> That would imply that DRV_NAME is always defined, but I don't
> see this being the case.

My mistake, I thought it was a Kbuild thing.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 22 12:27:39 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 Dec 2011 12:27:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rdhjv-00059o-Sk; Thu, 22 Dec 2011 12:27:15 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Rdhju-00059i-OL
	for xen-devel@lists.xensource.com; Thu, 22 Dec 2011 12:27:14 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1324556828!8292048!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11378 invoked from network); 22 Dec 2011 12:27:08 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-6.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 22 Dec 2011 12:27:08 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 22 Dec 2011 12:27:07 +0000
Message-Id: <4EF33062020000780006995E@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 22 Dec 2011 12:28:02 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Florian Manschwetus" <florianmanschwetus@gmx.de>
References: <4EF06B14.4070106@gmx.de> <4EF0B034.1090708@gmx.de>
	<4EF270A7.2010705@gmx.de>
	<4EF307540200007800069894@nat28.tlf.novell.com>
	<4EF2FCED.8010402@gmx.de>
In-Reply-To: <4EF2FCED.8010402@gmx.de>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [Xen-users] Problem booting xen 4.1.2 on Athlon 64
 X2
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 22.12.11 at 10:48, Florian Manschwetus <florianmanschwetus@gmx.de> wrote:
> Ok, I think I got the output. But I see nothing really helpful in there. 
> I have attached the boot-log, maybe it gives you the needed information.

[    0.028998] ..TIMER: vector=0x30 apic1=0 pin1=0 apic2=-1 pin2=-1
[    0.029997] ..MP-BIOS bug: 8254 timer not connected to IO-APIC
[    0.029997] ...trying to set up timer (IRQ0) through the 8259A ...
[    0.029997] ..... (found apic 0 pin 0) ...
[    0.040381] ....... works.

shows that the kernel has no pre-defined workaround (and you'd
likely be better of using the same command line option as I
recommended for Xen here too).

The question why what works on Linux doesn't work on Xen is not
very interesting unless the suggested command line option doesn't
help.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 22 12:27:39 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 Dec 2011 12:27:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rdhjv-00059o-Sk; Thu, 22 Dec 2011 12:27:15 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Rdhju-00059i-OL
	for xen-devel@lists.xensource.com; Thu, 22 Dec 2011 12:27:14 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1324556828!8292048!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11378 invoked from network); 22 Dec 2011 12:27:08 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-6.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 22 Dec 2011 12:27:08 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 22 Dec 2011 12:27:07 +0000
Message-Id: <4EF33062020000780006995E@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 22 Dec 2011 12:28:02 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Florian Manschwetus" <florianmanschwetus@gmx.de>
References: <4EF06B14.4070106@gmx.de> <4EF0B034.1090708@gmx.de>
	<4EF270A7.2010705@gmx.de>
	<4EF307540200007800069894@nat28.tlf.novell.com>
	<4EF2FCED.8010402@gmx.de>
In-Reply-To: <4EF2FCED.8010402@gmx.de>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [Xen-users] Problem booting xen 4.1.2 on Athlon 64
 X2
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 22.12.11 at 10:48, Florian Manschwetus <florianmanschwetus@gmx.de> wrote:
> Ok, I think I got the output. But I see nothing really helpful in there. 
> I have attached the boot-log, maybe it gives you the needed information.

[    0.028998] ..TIMER: vector=0x30 apic1=0 pin1=0 apic2=-1 pin2=-1
[    0.029997] ..MP-BIOS bug: 8254 timer not connected to IO-APIC
[    0.029997] ...trying to set up timer (IRQ0) through the 8259A ...
[    0.029997] ..... (found apic 0 pin 0) ...
[    0.040381] ....... works.

shows that the kernel has no pre-defined workaround (and you'd
likely be better of using the same command line option as I
recommended for Xen here too).

The question why what works on Linux doesn't work on Xen is not
very interesting unless the suggested command line option doesn't
help.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 22 12:47:28 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 Dec 2011 12:47:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rdi35-00066i-0N; Thu, 22 Dec 2011 12:47:03 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <mst@redhat.com>) id 1Rdi32-00066Y-Vy
	for xen-devel@lists.xensource.com; Thu, 22 Dec 2011 12:47:01 +0000
X-Env-Sender: mst@redhat.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1324558013!9229681!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDY3MzI=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10916 invoked from network); 22 Dec 2011 12:46:54 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-15.tower-21.messagelabs.com with SMTP;
	22 Dec 2011 12:46:54 -0000
Received: from int-mx12.intmail.prod.int.phx2.redhat.com
	(int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id pBMCknN0007756
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 22 Dec 2011 07:46:49 -0500
Received: from redhat.com (vpn-202-145.tlv.redhat.com [10.35.202.145])
	by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with SMTP
	id pBMCkkbX027903; Thu, 22 Dec 2011 07:46:47 -0500
Date: Thu, 22 Dec 2011 14:48:48 +0200
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Avi Kivity <avi@redhat.com>
Message-ID: <20111222124848.GA25538@redhat.com>
References: <1324304024-11220-1-git-send-email-avi@redhat.com>
	<1324304024-11220-21-git-send-email-avi@redhat.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1324304024-11220-21-git-send-email-avi@redhat.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.25
Cc: xen-devel@lists.xensource.com, qemu-devel@nongnu.org, kvm@vger.kernel.org,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 20/23] vhost: avoid
	cpu_get_physical_page_desc()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Dec 19, 2011 at 04:13:41PM +0200, Avi Kivity wrote:
> @@ -871,7 +899,10 @@ void vhost_dev_stop(struct vhost_dev *hdev, VirtIODevice *vdev)
>                                  hdev->vqs + i,
>                                  i);
>      }
> -    vhost_sync_dirty_bitmap(hdev, 0, (target_phys_addr_t)~0x0ull);
> +    for (i = 0; i < hdev->n_mem_sections; ++i) {
> +        vhost_sync_dirty_bitmap(hdev, &hdev->mem_sections[i],
> +                                0, (target_phys_addr_t)~0x0ull);
> +    }
>      r = vdev->binding->set_guest_notifiers(vdev->binding_opaque, false);
>      if (r < 0) {
>          fprintf(stderr, "vhost guest notifier cleanup failed: %d\n", r);
> diff --git a/hw/vhost.h b/hw/vhost.h
> index d1824ec..80e64df 100644
> --- a/hw/vhost.h
> +++ b/hw/vhost.h
> @@ -30,6 +30,8 @@ struct vhost_dev {
>      MemoryListener memory_listener;
>      int control;
>      struct vhost_memory *mem;
> +    int n_mem_sections;
> +    MemoryRegionSection *mem_sections;
>      struct vhost_virtqueue *vqs;
>      int nvqs;
>      unsigned long long features;

This adds need to track all sections which is unfortunate.
Couldn't the memory API get an extension e.g. to scan them all?

> -- 
> 1.7.7.1

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 22 12:47:28 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 Dec 2011 12:47:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rdi35-00066i-0N; Thu, 22 Dec 2011 12:47:03 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <mst@redhat.com>) id 1Rdi32-00066Y-Vy
	for xen-devel@lists.xensource.com; Thu, 22 Dec 2011 12:47:01 +0000
X-Env-Sender: mst@redhat.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1324558013!9229681!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDY3MzI=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10916 invoked from network); 22 Dec 2011 12:46:54 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-15.tower-21.messagelabs.com with SMTP;
	22 Dec 2011 12:46:54 -0000
Received: from int-mx12.intmail.prod.int.phx2.redhat.com
	(int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id pBMCknN0007756
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 22 Dec 2011 07:46:49 -0500
Received: from redhat.com (vpn-202-145.tlv.redhat.com [10.35.202.145])
	by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with SMTP
	id pBMCkkbX027903; Thu, 22 Dec 2011 07:46:47 -0500
Date: Thu, 22 Dec 2011 14:48:48 +0200
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Avi Kivity <avi@redhat.com>
Message-ID: <20111222124848.GA25538@redhat.com>
References: <1324304024-11220-1-git-send-email-avi@redhat.com>
	<1324304024-11220-21-git-send-email-avi@redhat.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1324304024-11220-21-git-send-email-avi@redhat.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.25
Cc: xen-devel@lists.xensource.com, qemu-devel@nongnu.org, kvm@vger.kernel.org,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 20/23] vhost: avoid
	cpu_get_physical_page_desc()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Dec 19, 2011 at 04:13:41PM +0200, Avi Kivity wrote:
> @@ -871,7 +899,10 @@ void vhost_dev_stop(struct vhost_dev *hdev, VirtIODevice *vdev)
>                                  hdev->vqs + i,
>                                  i);
>      }
> -    vhost_sync_dirty_bitmap(hdev, 0, (target_phys_addr_t)~0x0ull);
> +    for (i = 0; i < hdev->n_mem_sections; ++i) {
> +        vhost_sync_dirty_bitmap(hdev, &hdev->mem_sections[i],
> +                                0, (target_phys_addr_t)~0x0ull);
> +    }
>      r = vdev->binding->set_guest_notifiers(vdev->binding_opaque, false);
>      if (r < 0) {
>          fprintf(stderr, "vhost guest notifier cleanup failed: %d\n", r);
> diff --git a/hw/vhost.h b/hw/vhost.h
> index d1824ec..80e64df 100644
> --- a/hw/vhost.h
> +++ b/hw/vhost.h
> @@ -30,6 +30,8 @@ struct vhost_dev {
>      MemoryListener memory_listener;
>      int control;
>      struct vhost_memory *mem;
> +    int n_mem_sections;
> +    MemoryRegionSection *mem_sections;
>      struct vhost_virtqueue *vqs;
>      int nvqs;
>      unsigned long long features;

This adds need to track all sections which is unfortunate.
Couldn't the memory API get an extension e.g. to scan them all?

> -- 
> 1.7.7.1

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 22 12:48:42 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 Dec 2011 12:48:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rdi4M-0006Ay-FU; Thu, 22 Dec 2011 12:48:22 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <mst@redhat.com>) id 1Rdi4L-0006Ap-RJ
	for xen-devel@lists.xensource.com; Thu, 22 Dec 2011 12:48:22 +0000
X-Env-Sender: mst@redhat.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1324558048!58329116!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDY3MzI=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14571 invoked from network); 22 Dec 2011 12:47:29 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-2.tower-27.messagelabs.com with SMTP;
	22 Dec 2011 12:47:29 -0000
Received: from int-mx12.intmail.prod.int.phx2.redhat.com
	(int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id pBMCmIED019191
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 22 Dec 2011 07:48:18 -0500
Received: from redhat.com (vpn-202-145.tlv.redhat.com [10.35.202.145])
	by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with SMTP
	id pBMCmEe6028135; Thu, 22 Dec 2011 07:48:15 -0500
Date: Thu, 22 Dec 2011 14:50:16 +0200
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Avi Kivity <avi@redhat.com>
Message-ID: <20111222125016.GB25538@redhat.com>
References: <1324304024-11220-1-git-send-email-avi@redhat.com>
	<1324304024-11220-15-git-send-email-avi@redhat.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1324304024-11220-15-git-send-email-avi@redhat.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.25
Cc: xen-devel@lists.xensource.com, qemu-devel@nongnu.org, kvm@vger.kernel.org,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 14/23] vhost: convert to MemoryListener API
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Dec 19, 2011 at 04:13:35PM +0200, Avi Kivity wrote:
> +static void vhost_log_start(MemoryListener *listener,
> +                            MemoryRegionSection *section)
> +{
> +    /* FIXME: implement */
> +}
> +
> +static void vhost_log_stop(MemoryListener *listener,
> +                           MemoryRegionSection *section)
> +{
> +    /* FIXME: implement */
> +}
> +

What exactly do we need to fix here?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 22 12:48:42 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 Dec 2011 12:48:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rdi4M-0006Ay-FU; Thu, 22 Dec 2011 12:48:22 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <mst@redhat.com>) id 1Rdi4L-0006Ap-RJ
	for xen-devel@lists.xensource.com; Thu, 22 Dec 2011 12:48:22 +0000
X-Env-Sender: mst@redhat.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1324558048!58329116!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDY3MzI=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14571 invoked from network); 22 Dec 2011 12:47:29 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-2.tower-27.messagelabs.com with SMTP;
	22 Dec 2011 12:47:29 -0000
Received: from int-mx12.intmail.prod.int.phx2.redhat.com
	(int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id pBMCmIED019191
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 22 Dec 2011 07:48:18 -0500
Received: from redhat.com (vpn-202-145.tlv.redhat.com [10.35.202.145])
	by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with SMTP
	id pBMCmEe6028135; Thu, 22 Dec 2011 07:48:15 -0500
Date: Thu, 22 Dec 2011 14:50:16 +0200
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Avi Kivity <avi@redhat.com>
Message-ID: <20111222125016.GB25538@redhat.com>
References: <1324304024-11220-1-git-send-email-avi@redhat.com>
	<1324304024-11220-15-git-send-email-avi@redhat.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1324304024-11220-15-git-send-email-avi@redhat.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.25
Cc: xen-devel@lists.xensource.com, qemu-devel@nongnu.org, kvm@vger.kernel.org,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 14/23] vhost: convert to MemoryListener API
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Dec 19, 2011 at 04:13:35PM +0200, Avi Kivity wrote:
> +static void vhost_log_start(MemoryListener *listener,
> +                            MemoryRegionSection *section)
> +{
> +    /* FIXME: implement */
> +}
> +
> +static void vhost_log_stop(MemoryListener *listener,
> +                           MemoryRegionSection *section)
> +{
> +    /* FIXME: implement */
> +}
> +

What exactly do we need to fix here?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 22 12:49:38 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 Dec 2011 12:49:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rdi5K-0006Fr-UL; Thu, 22 Dec 2011 12:49:22 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <avi@redhat.com>) id 1Rdi5J-0006FO-8v
	for xen-devel@lists.xensource.com; Thu, 22 Dec 2011 12:49:21 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1324558154!978641!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDY3MzI=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4864 invoked from network); 22 Dec 2011 12:49:14 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-16.tower-182.messagelabs.com with SMTP;
	22 Dec 2011 12:49:14 -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 pBMCnCiJ008205
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 22 Dec 2011 07:49:12 -0500
Received: from balrog.usersys.redhat.com (dhcp-4-24.tlv.redhat.com
	[10.35.4.24])
	by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id pBMCnAhx026598; Thu, 22 Dec 2011 07:49:11 -0500
Message-ID: <4EF32746.3090706@redhat.com>
Date: Thu, 22 Dec 2011 14:49:10 +0200
From: Avi Kivity <avi@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:8.0) Gecko/20111115 Thunderbird/8.0
MIME-Version: 1.0
To: "Michael S. Tsirkin" <mst@redhat.com>
References: <1324304024-11220-1-git-send-email-avi@redhat.com>
	<1324304024-11220-21-git-send-email-avi@redhat.com>
	<20111222124848.GA25538@redhat.com>
In-Reply-To: <20111222124848.GA25538@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
Cc: xen-devel@lists.xensource.com, qemu-devel@nongnu.org, kvm@vger.kernel.org,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 20/23] vhost: avoid
	cpu_get_physical_page_desc()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 12/22/2011 02:48 PM, Michael S. Tsirkin wrote:
> On Mon, Dec 19, 2011 at 04:13:41PM +0200, Avi Kivity wrote:
> > @@ -871,7 +899,10 @@ void vhost_dev_stop(struct vhost_dev *hdev, VirtIODevice *vdev)
> >                                  hdev->vqs + i,
> >                                  i);
> >      }
> > -    vhost_sync_dirty_bitmap(hdev, 0, (target_phys_addr_t)~0x0ull);
> > +    for (i = 0; i < hdev->n_mem_sections; ++i) {
> > +        vhost_sync_dirty_bitmap(hdev, &hdev->mem_sections[i],
> > +                                0, (target_phys_addr_t)~0x0ull);
> > +    }
> >      r = vdev->binding->set_guest_notifiers(vdev->binding_opaque, false);
> >      if (r < 0) {
> >          fprintf(stderr, "vhost guest notifier cleanup failed: %d\n", r);
> > diff --git a/hw/vhost.h b/hw/vhost.h
> > index d1824ec..80e64df 100644
> > --- a/hw/vhost.h
> > +++ b/hw/vhost.h
> > @@ -30,6 +30,8 @@ struct vhost_dev {
> >      MemoryListener memory_listener;
> >      int control;
> >      struct vhost_memory *mem;
> > +    int n_mem_sections;
> > +    MemoryRegionSection *mem_sections;
> >      struct vhost_virtqueue *vqs;
> >      int nvqs;
> >      unsigned long long features;
>
> This adds need to track all sections which is unfortunate.
> Couldn't the memory API get an extension e.g. to scan them all?

I thought about it, it makes sense.

We even have memory_region_find() which can be used to implement it,
just need a FOR_EACH wrapper.

-- 
error compiling committee.c: too many arguments to function


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 22 12:49:38 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 Dec 2011 12:49:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rdi5K-0006Fr-UL; Thu, 22 Dec 2011 12:49:22 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <avi@redhat.com>) id 1Rdi5J-0006FO-8v
	for xen-devel@lists.xensource.com; Thu, 22 Dec 2011 12:49:21 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1324558154!978641!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDY3MzI=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4864 invoked from network); 22 Dec 2011 12:49:14 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-16.tower-182.messagelabs.com with SMTP;
	22 Dec 2011 12:49:14 -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 pBMCnCiJ008205
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 22 Dec 2011 07:49:12 -0500
Received: from balrog.usersys.redhat.com (dhcp-4-24.tlv.redhat.com
	[10.35.4.24])
	by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id pBMCnAhx026598; Thu, 22 Dec 2011 07:49:11 -0500
Message-ID: <4EF32746.3090706@redhat.com>
Date: Thu, 22 Dec 2011 14:49:10 +0200
From: Avi Kivity <avi@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:8.0) Gecko/20111115 Thunderbird/8.0
MIME-Version: 1.0
To: "Michael S. Tsirkin" <mst@redhat.com>
References: <1324304024-11220-1-git-send-email-avi@redhat.com>
	<1324304024-11220-21-git-send-email-avi@redhat.com>
	<20111222124848.GA25538@redhat.com>
In-Reply-To: <20111222124848.GA25538@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
Cc: xen-devel@lists.xensource.com, qemu-devel@nongnu.org, kvm@vger.kernel.org,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 20/23] vhost: avoid
	cpu_get_physical_page_desc()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 12/22/2011 02:48 PM, Michael S. Tsirkin wrote:
> On Mon, Dec 19, 2011 at 04:13:41PM +0200, Avi Kivity wrote:
> > @@ -871,7 +899,10 @@ void vhost_dev_stop(struct vhost_dev *hdev, VirtIODevice *vdev)
> >                                  hdev->vqs + i,
> >                                  i);
> >      }
> > -    vhost_sync_dirty_bitmap(hdev, 0, (target_phys_addr_t)~0x0ull);
> > +    for (i = 0; i < hdev->n_mem_sections; ++i) {
> > +        vhost_sync_dirty_bitmap(hdev, &hdev->mem_sections[i],
> > +                                0, (target_phys_addr_t)~0x0ull);
> > +    }
> >      r = vdev->binding->set_guest_notifiers(vdev->binding_opaque, false);
> >      if (r < 0) {
> >          fprintf(stderr, "vhost guest notifier cleanup failed: %d\n", r);
> > diff --git a/hw/vhost.h b/hw/vhost.h
> > index d1824ec..80e64df 100644
> > --- a/hw/vhost.h
> > +++ b/hw/vhost.h
> > @@ -30,6 +30,8 @@ struct vhost_dev {
> >      MemoryListener memory_listener;
> >      int control;
> >      struct vhost_memory *mem;
> > +    int n_mem_sections;
> > +    MemoryRegionSection *mem_sections;
> >      struct vhost_virtqueue *vqs;
> >      int nvqs;
> >      unsigned long long features;
>
> This adds need to track all sections which is unfortunate.
> Couldn't the memory API get an extension e.g. to scan them all?

I thought about it, it makes sense.

We even have memory_region_find() which can be used to implement it,
just need a FOR_EACH wrapper.

-- 
error compiling committee.c: too many arguments to function


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 22 12:50:54 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 Dec 2011 12:50:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rdi6a-0006NY-Ey; Thu, 22 Dec 2011 12:50:40 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <avi@redhat.com>) id 1Rdi6Z-0006Mu-Bn
	for xen-devel@lists.xensource.com; Thu, 22 Dec 2011 12:50:39 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1324558232!9193833!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDY3MzI=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21053 invoked from network); 22 Dec 2011 12:50:32 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-8.tower-21.messagelabs.com with SMTP;
	22 Dec 2011 12:50:32 -0000
Received: from int-mx10.intmail.prod.int.phx2.redhat.com
	(int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id pBMCoUAq025455
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 22 Dec 2011 07:50:30 -0500
Received: from balrog.usersys.redhat.com (dhcp-4-24.tlv.redhat.com
	[10.35.4.24])
	by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id pBMCoRax027280; Thu, 22 Dec 2011 07:50:28 -0500
Message-ID: <4EF32793.30108@redhat.com>
Date: Thu, 22 Dec 2011 14:50:27 +0200
From: Avi Kivity <avi@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:8.0) Gecko/20111115 Thunderbird/8.0
MIME-Version: 1.0
To: "Michael S. Tsirkin" <mst@redhat.com>
References: <1324304024-11220-1-git-send-email-avi@redhat.com>
	<1324304024-11220-15-git-send-email-avi@redhat.com>
	<20111222125016.GB25538@redhat.com>
In-Reply-To: <20111222125016.GB25538@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
Cc: xen-devel@lists.xensource.com, qemu-devel@nongnu.org, kvm@vger.kernel.org,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 14/23] vhost: convert to MemoryListener API
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 12/22/2011 02:50 PM, Michael S. Tsirkin wrote:
> On Mon, Dec 19, 2011 at 04:13:35PM +0200, Avi Kivity wrote:
> > +static void vhost_log_start(MemoryListener *listener,
> > +                            MemoryRegionSection *section)
> > +{
> > +    /* FIXME: implement */
> > +}
> > +
> > +static void vhost_log_stop(MemoryListener *listener,
> > +                           MemoryRegionSection *section)
> > +{
> > +    /* FIXME: implement */
> > +}
> > +
>
> What exactly do we need to fix here?

Tell vhost to start tracking those regions?

I guess you don't often read packets into the framebuffer, or we'd have
a lot of bug reports.

-- 
error compiling committee.c: too many arguments to function


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 22 12:50:54 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 Dec 2011 12:50:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rdi6a-0006NY-Ey; Thu, 22 Dec 2011 12:50:40 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <avi@redhat.com>) id 1Rdi6Z-0006Mu-Bn
	for xen-devel@lists.xensource.com; Thu, 22 Dec 2011 12:50:39 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1324558232!9193833!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDY3MzI=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21053 invoked from network); 22 Dec 2011 12:50:32 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-8.tower-21.messagelabs.com with SMTP;
	22 Dec 2011 12:50:32 -0000
Received: from int-mx10.intmail.prod.int.phx2.redhat.com
	(int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id pBMCoUAq025455
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 22 Dec 2011 07:50:30 -0500
Received: from balrog.usersys.redhat.com (dhcp-4-24.tlv.redhat.com
	[10.35.4.24])
	by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id pBMCoRax027280; Thu, 22 Dec 2011 07:50:28 -0500
Message-ID: <4EF32793.30108@redhat.com>
Date: Thu, 22 Dec 2011 14:50:27 +0200
From: Avi Kivity <avi@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:8.0) Gecko/20111115 Thunderbird/8.0
MIME-Version: 1.0
To: "Michael S. Tsirkin" <mst@redhat.com>
References: <1324304024-11220-1-git-send-email-avi@redhat.com>
	<1324304024-11220-15-git-send-email-avi@redhat.com>
	<20111222125016.GB25538@redhat.com>
In-Reply-To: <20111222125016.GB25538@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
Cc: xen-devel@lists.xensource.com, qemu-devel@nongnu.org, kvm@vger.kernel.org,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 14/23] vhost: convert to MemoryListener API
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 12/22/2011 02:50 PM, Michael S. Tsirkin wrote:
> On Mon, Dec 19, 2011 at 04:13:35PM +0200, Avi Kivity wrote:
> > +static void vhost_log_start(MemoryListener *listener,
> > +                            MemoryRegionSection *section)
> > +{
> > +    /* FIXME: implement */
> > +}
> > +
> > +static void vhost_log_stop(MemoryListener *listener,
> > +                           MemoryRegionSection *section)
> > +{
> > +    /* FIXME: implement */
> > +}
> > +
>
> What exactly do we need to fix here?

Tell vhost to start tracking those regions?

I guess you don't often read packets into the framebuffer, or we'd have
a lot of bug reports.

-- 
error compiling committee.c: too many arguments to function


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 22 12:55:20 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 Dec 2011 12: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.xensource.com>)
	id 1RdiAp-0006jN-6Z; Thu, 22 Dec 2011 12:55:03 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <imammedo@redhat.com>) id 1RdiAn-0006jF-SF
	for xen-devel@lists.xensource.com; Thu, 22 Dec 2011 12:55:02 +0000
X-Env-Sender: imammedo@redhat.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1324558494!8283882!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDY3MzI=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8206 invoked from network); 22 Dec 2011 12:54:55 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-9.tower-182.messagelabs.com with SMTP;
	22 Dec 2011 12:54:55 -0000
Received: from int-mx12.intmail.prod.int.phx2.redhat.com
	(int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id pBMCsrkI026217
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK)
	for <xen-devel@lists.xensource.com>; Thu, 22 Dec 2011 07:54:54 -0500
Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199])
	by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id pBMCsr0m029924
	for <xen-devel@lists.xensource.com>; Thu, 22 Dec 2011 07:54:53 -0500
Received: from nial.usersys.redhat.com (dhcp-1-247.brq.redhat.com
	[10.34.1.247])
	by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id pBMCsqZF023034
	for <xen-devel@lists.xensource.com>; Thu, 22 Dec 2011 07:54:53 -0500
Message-ID: <4EF3289C.60901@redhat.com>
Date: Thu, 22 Dec 2011 13:54:52 +0100
From: Igor Mammedov <imammedo@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:8.0) Gecko/20111115 Thunderbird/8.0
MIME-Version: 1.0
To: xen-devel@lists.xensource.com
References: <4EF06B14.4070106@gmx.de> <4EF0B034.1090708@gmx.de>
	<4EF270A7.2010705@gmx.de>
In-Reply-To: <4EF270A7.2010705@gmx.de>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.25
Subject: Re: [Xen-devel] [Xen-users] Problem booting xen 4.1.2 on Athlon 64
 X2
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 12/22/2011 12:49 AM, Florian Manschwetus wrote:
>> (XEN) AMD-Vi: IOMMU not found!
>> (XEN) I/O virtualisation disabled

I've seen the same issue on a AMD system with upstream xen and
host booted after iommu=off was added to xen's cmd line..
Although log says that there isn't iommu, but it worth the shot.

-- 
Thanks,
  Igor

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 22 12:55:20 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 Dec 2011 12: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.xensource.com>)
	id 1RdiAp-0006jN-6Z; Thu, 22 Dec 2011 12:55:03 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <imammedo@redhat.com>) id 1RdiAn-0006jF-SF
	for xen-devel@lists.xensource.com; Thu, 22 Dec 2011 12:55:02 +0000
X-Env-Sender: imammedo@redhat.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1324558494!8283882!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDY3MzI=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8206 invoked from network); 22 Dec 2011 12:54:55 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-9.tower-182.messagelabs.com with SMTP;
	22 Dec 2011 12:54:55 -0000
Received: from int-mx12.intmail.prod.int.phx2.redhat.com
	(int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id pBMCsrkI026217
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK)
	for <xen-devel@lists.xensource.com>; Thu, 22 Dec 2011 07:54:54 -0500
Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199])
	by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id pBMCsr0m029924
	for <xen-devel@lists.xensource.com>; Thu, 22 Dec 2011 07:54:53 -0500
Received: from nial.usersys.redhat.com (dhcp-1-247.brq.redhat.com
	[10.34.1.247])
	by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id pBMCsqZF023034
	for <xen-devel@lists.xensource.com>; Thu, 22 Dec 2011 07:54:53 -0500
Message-ID: <4EF3289C.60901@redhat.com>
Date: Thu, 22 Dec 2011 13:54:52 +0100
From: Igor Mammedov <imammedo@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:8.0) Gecko/20111115 Thunderbird/8.0
MIME-Version: 1.0
To: xen-devel@lists.xensource.com
References: <4EF06B14.4070106@gmx.de> <4EF0B034.1090708@gmx.de>
	<4EF270A7.2010705@gmx.de>
In-Reply-To: <4EF270A7.2010705@gmx.de>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.25
Subject: Re: [Xen-devel] [Xen-users] Problem booting xen 4.1.2 on Athlon 64
 X2
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 12/22/2011 12:49 AM, Florian Manschwetus wrote:
>> (XEN) AMD-Vi: IOMMU not found!
>> (XEN) I/O virtualisation disabled

I've seen the same issue on a AMD system with upstream xen and
host booted after iommu=off was added to xen's cmd line..
Although log says that there isn't iommu, but it worth the shot.

-- 
Thanks,
  Igor

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 22 12:55:59 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 Dec 2011 12:55:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdiBT-0006lu-8k; Thu, 22 Dec 2011 12:55:43 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <mst@redhat.com>) id 1RdiBQ-0006lg-U5
	for xen-devel@lists.xensource.com; Thu, 22 Dec 2011 12:55:41 +0000
X-Env-Sender: mst@redhat.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1324558502!57725657!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDY3MzI=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15123 invoked from network); 22 Dec 2011 12:55:02 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-9.tower-27.messagelabs.com with SMTP;
	22 Dec 2011 12:55:02 -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 pBMCtbWB010623
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 22 Dec 2011 07:55:37 -0500
Received: from redhat.com (vpn-202-145.tlv.redhat.com [10.35.202.145])
	by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with SMTP
	id pBMCtXPb028277; Thu, 22 Dec 2011 07:55:34 -0500
Date: Thu, 22 Dec 2011 14:57:35 +0200
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Avi Kivity <avi@redhat.com>
Message-ID: <20111222125734.GC25538@redhat.com>
References: <1324304024-11220-1-git-send-email-avi@redhat.com>
	<1324304024-11220-15-git-send-email-avi@redhat.com>
	<20111222125016.GB25538@redhat.com> <4EF32793.30108@redhat.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4EF32793.30108@redhat.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
Cc: xen-devel@lists.xensource.com, qemu-devel@nongnu.org, kvm@vger.kernel.org,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 14/23] vhost: convert to MemoryListener API
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Dec 22, 2011 at 02:50:27PM +0200, Avi Kivity wrote:
> On 12/22/2011 02:50 PM, Michael S. Tsirkin wrote:
> > On Mon, Dec 19, 2011 at 04:13:35PM +0200, Avi Kivity wrote:
> > > +static void vhost_log_start(MemoryListener *listener,
> > > +                            MemoryRegionSection *section)
> > > +{
> > > +    /* FIXME: implement */
> > > +}
> > > +
> > > +static void vhost_log_stop(MemoryListener *listener,
> > > +                           MemoryRegionSection *section)
> > > +{
> > > +    /* FIXME: implement */
> > > +}
> > > +
> >
> > What exactly do we need to fix here?
> 
> Tell vhost to start tracking those regions?
> 
> I guess you don't often read packets into the framebuffer, or we'd have
> a lot of bug reports.

Yes, we currently simply don't pass these regions to vhost.
It currently signals an error if such is
observed, so we could handle framebuffer in userspace
if we wanted to.

> -- 
> error compiling committee.c: too many arguments to function

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 22 12:55:59 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 Dec 2011 12:55:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdiBT-0006lu-8k; Thu, 22 Dec 2011 12:55:43 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <mst@redhat.com>) id 1RdiBQ-0006lg-U5
	for xen-devel@lists.xensource.com; Thu, 22 Dec 2011 12:55:41 +0000
X-Env-Sender: mst@redhat.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1324558502!57725657!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDY3MzI=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15123 invoked from network); 22 Dec 2011 12:55:02 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-9.tower-27.messagelabs.com with SMTP;
	22 Dec 2011 12:55:02 -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 pBMCtbWB010623
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 22 Dec 2011 07:55:37 -0500
Received: from redhat.com (vpn-202-145.tlv.redhat.com [10.35.202.145])
	by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with SMTP
	id pBMCtXPb028277; Thu, 22 Dec 2011 07:55:34 -0500
Date: Thu, 22 Dec 2011 14:57:35 +0200
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Avi Kivity <avi@redhat.com>
Message-ID: <20111222125734.GC25538@redhat.com>
References: <1324304024-11220-1-git-send-email-avi@redhat.com>
	<1324304024-11220-15-git-send-email-avi@redhat.com>
	<20111222125016.GB25538@redhat.com> <4EF32793.30108@redhat.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4EF32793.30108@redhat.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
Cc: xen-devel@lists.xensource.com, qemu-devel@nongnu.org, kvm@vger.kernel.org,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 14/23] vhost: convert to MemoryListener API
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Dec 22, 2011 at 02:50:27PM +0200, Avi Kivity wrote:
> On 12/22/2011 02:50 PM, Michael S. Tsirkin wrote:
> > On Mon, Dec 19, 2011 at 04:13:35PM +0200, Avi Kivity wrote:
> > > +static void vhost_log_start(MemoryListener *listener,
> > > +                            MemoryRegionSection *section)
> > > +{
> > > +    /* FIXME: implement */
> > > +}
> > > +
> > > +static void vhost_log_stop(MemoryListener *listener,
> > > +                           MemoryRegionSection *section)
> > > +{
> > > +    /* FIXME: implement */
> > > +}
> > > +
> >
> > What exactly do we need to fix here?
> 
> Tell vhost to start tracking those regions?
> 
> I guess you don't often read packets into the framebuffer, or we'd have
> a lot of bug reports.

Yes, we currently simply don't pass these regions to vhost.
It currently signals an error if such is
observed, so we could handle framebuffer in userspace
if we wanted to.

> -- 
> error compiling committee.c: too many arguments to function

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 22 12:58:17 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 Dec 2011 12:58:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdiDf-0006wk-4p; Thu, 22 Dec 2011 12:57:59 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <avi@redhat.com>) id 1RdiDd-0006wX-M4
	for xen-devel@lists.xensource.com; Thu, 22 Dec 2011 12:57:57 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1324558671!8426499!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDY3MzI=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24558 invoked from network); 22 Dec 2011 12:57:51 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-4.tower-216.messagelabs.com with SMTP;
	22 Dec 2011 12:57: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 pBMCvnxo021933
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 22 Dec 2011 07:57:49 -0500
Received: from balrog.usersys.redhat.com (dhcp-4-24.tlv.redhat.com
	[10.35.4.24])
	by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id pBMCvk0O027872; Thu, 22 Dec 2011 07:57:47 -0500
Message-ID: <4EF3294A.5050505@redhat.com>
Date: Thu, 22 Dec 2011 14:57:46 +0200
From: Avi Kivity <avi@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:8.0) Gecko/20111115 Thunderbird/8.0
MIME-Version: 1.0
To: "Michael S. Tsirkin" <mst@redhat.com>
References: <1324304024-11220-1-git-send-email-avi@redhat.com>
	<1324304024-11220-15-git-send-email-avi@redhat.com>
	<20111222125016.GB25538@redhat.com> <4EF32793.30108@redhat.com>
	<20111222125734.GC25538@redhat.com>
In-Reply-To: <20111222125734.GC25538@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
Cc: xen-devel@lists.xensource.com, qemu-devel@nongnu.org, kvm@vger.kernel.org,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 14/23] vhost: convert to MemoryListener API
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 12/22/2011 02:57 PM, Michael S. Tsirkin wrote:
> On Thu, Dec 22, 2011 at 02:50:27PM +0200, Avi Kivity wrote:
> > On 12/22/2011 02:50 PM, Michael S. Tsirkin wrote:
> > > On Mon, Dec 19, 2011 at 04:13:35PM +0200, Avi Kivity wrote:
> > > > +static void vhost_log_start(MemoryListener *listener,
> > > > +                            MemoryRegionSection *section)
> > > > +{
> > > > +    /* FIXME: implement */
> > > > +}
> > > > +
> > > > +static void vhost_log_stop(MemoryListener *listener,
> > > > +                           MemoryRegionSection *section)
> > > > +{
> > > > +    /* FIXME: implement */
> > > > +}
> > > > +
> > >
> > > What exactly do we need to fix here?
> > 
> > Tell vhost to start tracking those regions?
> > 
> > I guess you don't often read packets into the framebuffer, or we'd have
> > a lot of bug reports.
>
> Yes, we currently simply don't pass these regions to vhost.
> It currently signals an error if such is
> observed, so we could handle framebuffer in userspace
> if we wanted to.

I see, thanks.

-- 
error compiling committee.c: too many arguments to function


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 22 12:58:17 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 Dec 2011 12:58:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdiDf-0006wk-4p; Thu, 22 Dec 2011 12:57:59 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <avi@redhat.com>) id 1RdiDd-0006wX-M4
	for xen-devel@lists.xensource.com; Thu, 22 Dec 2011 12:57:57 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1324558671!8426499!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDY3MzI=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24558 invoked from network); 22 Dec 2011 12:57:51 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-4.tower-216.messagelabs.com with SMTP;
	22 Dec 2011 12:57: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 pBMCvnxo021933
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 22 Dec 2011 07:57:49 -0500
Received: from balrog.usersys.redhat.com (dhcp-4-24.tlv.redhat.com
	[10.35.4.24])
	by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id pBMCvk0O027872; Thu, 22 Dec 2011 07:57:47 -0500
Message-ID: <4EF3294A.5050505@redhat.com>
Date: Thu, 22 Dec 2011 14:57:46 +0200
From: Avi Kivity <avi@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:8.0) Gecko/20111115 Thunderbird/8.0
MIME-Version: 1.0
To: "Michael S. Tsirkin" <mst@redhat.com>
References: <1324304024-11220-1-git-send-email-avi@redhat.com>
	<1324304024-11220-15-git-send-email-avi@redhat.com>
	<20111222125016.GB25538@redhat.com> <4EF32793.30108@redhat.com>
	<20111222125734.GC25538@redhat.com>
In-Reply-To: <20111222125734.GC25538@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
Cc: xen-devel@lists.xensource.com, qemu-devel@nongnu.org, kvm@vger.kernel.org,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 14/23] vhost: convert to MemoryListener API
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 12/22/2011 02:57 PM, Michael S. Tsirkin wrote:
> On Thu, Dec 22, 2011 at 02:50:27PM +0200, Avi Kivity wrote:
> > On 12/22/2011 02:50 PM, Michael S. Tsirkin wrote:
> > > On Mon, Dec 19, 2011 at 04:13:35PM +0200, Avi Kivity wrote:
> > > > +static void vhost_log_start(MemoryListener *listener,
> > > > +                            MemoryRegionSection *section)
> > > > +{
> > > > +    /* FIXME: implement */
> > > > +}
> > > > +
> > > > +static void vhost_log_stop(MemoryListener *listener,
> > > > +                           MemoryRegionSection *section)
> > > > +{
> > > > +    /* FIXME: implement */
> > > > +}
> > > > +
> > >
> > > What exactly do we need to fix here?
> > 
> > Tell vhost to start tracking those regions?
> > 
> > I guess you don't often read packets into the framebuffer, or we'd have
> > a lot of bug reports.
>
> Yes, we currently simply don't pass these regions to vhost.
> It currently signals an error if such is
> observed, so we could handle framebuffer in userspace
> if we wanted to.

I see, thanks.

-- 
error compiling committee.c: too many arguments to function


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 22 13:13:15 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 Dec 2011 13:13:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdiS7-0007QJ-0e; Thu, 22 Dec 2011 13:12:55 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <florianmanschwetus@gmx.de>) id 1RdiS4-0007Q8-SH
	for xen-devel@lists.xensource.com; Thu, 22 Dec 2011 13:12:53 +0000
X-Env-Sender: florianmanschwetus@gmx.de
X-Msg-Ref: server-13.tower-174.messagelabs.com!1324559565!6545108!1
X-Originating-IP: [213.165.64.22]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMTMuMTY1LjY0LjIyID0+IDEwNTI0MQ==\n,sa_preprocessor: 
	QmFkIElQOiAyMTMuMTY1LjY0LjIyID0+IDEwNTI0MQ==\n, ML_RADAR_SPEW_LINKS_14, 
	spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16906 invoked from network); 22 Dec 2011 13:12:45 -0000
Received: from mailout-de.gmx.net (HELO mailout-de.gmx.net) (213.165.64.22)
	by server-13.tower-174.messagelabs.com with SMTP;
	22 Dec 2011 13:12:45 -0000
Received: (qmail invoked by alias); 22 Dec 2011 13:12:44 -0000
Received: from dslb-088-069-059-020.pools.arcor-ip.net (EHLO [192.168.222.23])
	[88.69.59.20]
	by mail.gmx.net (mp034) with SMTP; 22 Dec 2011 14:12:44 +0100
X-Authenticated: #7518697
X-Provags-ID: V01U2FsdGVkX190kY5vG6R07Q+Mr2u5CRKjdgLDhFIJHEoptILWE3
	JdmWZpoFbGf8LH
Message-ID: <4EF32C93.4040107@gmx.de>
Date: Thu, 22 Dec 2011 14:11:47 +0100
From: Florian Manschwetus <florianmanschwetus@gmx.de>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:8.0) Gecko/20111121 Thunderbird/8.0
MIME-Version: 1.0
To: xen-devel@lists.xensource.com
References: <4EF06B14.4070106@gmx.de> <4EF0B034.1090708@gmx.de>
	<4EF270A7.2010705@gmx.de>
	<4EF307540200007800069894@nat28.tlf.novell.com>
	<4EF2FCED.8010402@gmx.de>
	<4EF33062020000780006995E@nat28.tlf.novell.com>
In-Reply-To: <4EF33062020000780006995E@nat28.tlf.novell.com>
X-Y-GMX-Trusted: 0
Subject: Re: [Xen-devel] [Xen-users] Problem booting xen 4.1.2 on Athlon 64
 X2
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============5871928279902479562=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Dies ist eine kryptografisch unterzeichnete Nachricht im MIME-Format.

--===============5871928279902479562==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms010307090206060004090801"

Dies ist eine kryptografisch unterzeichnete Nachricht im MIME-Format.

--------------ms010307090206060004090801
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: quoted-printable

Looks acpi_skip_timer_override is not the solution:


Loading Xen 4.1.2 ...
Loading Linux x86_64-3.1.5-gentoo ...
Loading initial ramdisk ...
  __  __            _  _    _   ____
  \ \/ /___ _ __   | || |  / | |___ \
   \  // _ \ '_ \  | || |_ | |   __) |
   /  \  __/ | | | |__   _|| |_ / __/
  /_/\_\___|_| |_|    |_|(_)_(_)_____|

(XEN) Xen version 4.1.2 (@) (gcc-Version 4.6.2 (Gentoo 4.6.2 p1.0,=20
pie-0.4.5) ) Thu Dec 15 17:51:19 CET 2011
(XEN) Latest ChangeSet: unavailable
(XEN) Console output is synchronous.
(XEN) Bootloader: GRUB 1.99
(XEN) Command line: placeholder sync_console console_to_ring=20
com1=3D115200,8n1 console=3Dcom1,vga loglvl=3Dall lapic=3Ddebug=20
apic_verbosity=3Ddebug apic=3Ddebug acpi_skip_timer_override
(XEN) Video information:
(XEN)  VGA is text mode 80x25, font 8x16
(XEN)  VBE/DDC methods: none; EDID transfer time: 0 seconds
(XEN)  EDID info not retrieved because no DDC retrieval method detected
(XEN) Disc information:
(XEN)  Found 1 MBR signatures
(XEN)  Found 1 EDD information structures
(XEN) Xen-e820 RAM map:
(XEN)  0000000000000000 - 000000000009fc00 (usable)
(XEN)  000000000009fc00 - 00000000000a0000 (reserved)
(XEN)  00000000000e0000 - 0000000000100000 (reserved)
(XEN)  0000000000100000 - 00000000bffc0000 (usable)
(XEN)  00000000bffc0000 - 00000000bffce000 (ACPI data)
(XEN)  00000000bffce000 - 00000000bfff0000 (ACPI NVS)
(XEN)  00000000bfff0000 - 00000000c0000000 (reserved)
(XEN)  00000000fec00000 - 00000000fec01000 (reserved)
(XEN)  00000000fee00000 - 00000000fef00000 (reserved)
(XEN)  00000000ff780000 - 0000000100000000 (reserved)
(XEN)  0000000100000000 - 0000000140000000 (usable)
(XEN) ACPI: RSDP 000FB840, 0024 (r2 ACPIAM)
(XEN) ACPI: XSDT BFFC0100, 004C (r1 A_M_I_ OEMXSDT   3000826 MSFT       9=
7)
(XEN) ACPI: FACP BFFC0290, 00F4 (r3 A_M_I_ OEMFACP   3000826 MSFT       9=
7)
(XEN) ACPI: DSDT BFFC05C0, 4E38 (r1  A0557 A0557000        0 INTL 2005111=
7)
(XEN) ACPI: FACS BFFCE000, 0040
(XEN) ACPI: APIC BFFC0390, 0070 (r1 A_M_I_ OEMAPIC   3000826 MSFT       9=
7)
(XEN) ACPI: MCFG BFFC0400, 003C (r1 A_M_I_ OEMMCFG   3000826 MSFT       9=
7)
(XEN) ACPI: OEMB BFFCE040, 0060 (r1 A_M_I_ AMI_OEM   3000826 MSFT       9=
7)
(XEN) ACPI: HPET BFFC5400, 0038 (r1 A_M_I_ OEMHPET0  3000826 MSFT       9=
7)
(XEN) System RAM: 4095MB (4193660kB)
(XEN) No NUMA configuration found
(XEN) Faking a node at 0000000000000000-0000000140000000
(XEN) Domain heap initialised
(XEN) found SMP MP-table at 000ff780
(XEN) DMI present.
(XEN) APIC boot state is 'xapic'
(XEN) Using APIC driver default
(XEN) ACPI: PM-Timer IO Port: 0x508
(XEN) ACPI: ACPI SLEEP INFO: pm1x_cnt[504,0], pm1x_evt[500,0]
(XEN) ACPI:                  wakeup_vec[bffce00c], vec_size[20]
(XEN) ACPI: Local APIC address 0xfee00000
(XEN) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
(XEN) Processor #0 15:3 APIC version 16
(XEN) ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled)
(XEN) Processor #1 15:3 APIC version 16
(XEN) ACPI: IOAPIC (id[0x02] address[0xfec00000] gsi_base[0])
(XEN) IOAPIC[0]: apic_id 2, version 17, address 0xfec00000, GSI 0-23
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 0 dfl dfl)
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 14 global_irq 14 high edge)
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 15 global_irq 15 high edge)
(XEN) ACPI: IRQ0 used by override.
(XEN) ACPI: IRQ9 used by override.
(XEN) ACPI: IRQ14 used by override.
(XEN) ACPI: IRQ15 used by override.
(XEN) Enabling APIC mode:  Flat.  Using 1 I/O APICs
(XEN) ACPI: HPET id: 0x10de8201 base: 0xfed00000
(XEN) PCI: MCFG configuration 0: base e0000000 segment 0 buses 0 - 255
(XEN) PCI: Not using MMCONFIG.
(XEN) Table is not found!
(XEN) Using ACPI (MADT) for SMP configuration information
(XEN) mapped APIC to ffff82c3ffffe000 (fee00000)
(XEN) mapped IOAPIC to ffff82c3ffffd000 (fec00000)
(XEN) IRQ limits: 24 GSI, 376 MSI/MSI-X
(XEN) Using scheduler: SMP Credit Scheduler (credit)
(XEN) Detected 2611.923 MHz processor.
(XEN) Initing memory sharing.
(XEN) AMD K8 machine check reporting enabled
(XEN) AMD-Vi: IOMMU not found!
(XEN) I/O virtualisation disabled
(XEN) Getting VERSION: 80050010
(XEN) Getting VERSION: 80050010
(XEN) Getting ID: 0
(XEN) Getting LVT0: 700
(XEN) Getting LVT1: 400
(XEN) enabled ExtINT on CPU#0
(XEN) ESR value before enabling vector: 0x00000004  after: 0x00000000
(XEN) ENABLING IO-APIC IRQs
(XEN)  -> Using new ACK method
(XEN) init IO_APIC IRQs
(XEN)  IO-APIC (apicid-pin) 2-16, 2-17, 2-18, 2-19, 2-20, 2-21, 2-22,=20
2-23 not connected.
(XEN) ..TIMER: vector=3D0xF0 apic1=3D0 pin1=3D0 apic2=3D-1 pin2=3D-1
(XEN) ..MP-BIOS bug: 8254 timer not connected to IO-APIC
(XEN) ...trying to set up timer (IRQ0) through the 8259A ...  failed.
(XEN) ...trying to set up timer as Virtual Wire IRQ... failed.
(XEN) ...trying to set up timer as ExtINT IRQ... failed :(.
(XEN)
(XEN) ****************************************
(XEN) Panic on CPU 0:
(XEN) IO-APIC + timer doesn't work!  Boot with apic_verbosity=3Ddebug and=
=20
send a report.  Then try booting with the 'noapic'=20
option****************************************
(XEN)
(XEN) Reboot in five seconds...



Am 22.12.2011 13:28, schrieb Jan Beulich:
>>>> On 22.12.11 at 10:48, Florian Manschwetus<florianmanschwetus@gmx.de>=
  wrote:
>> Ok, I think I got the output. But I see nothing really helpful in ther=
e.
>> I have attached the boot-log, maybe it gives you the needed informatio=
n.
>
> [    0.028998] ..TIMER: vector=3D0x30 apic1=3D0 pin1=3D0 apic2=3D-1 pin=
2=3D-1
> [    0.029997] ..MP-BIOS bug: 8254 timer not connected to IO-APIC
> [    0.029997] ...trying to set up timer (IRQ0) through the 8259A ...
> [    0.029997] ..... (found apic 0 pin 0) ...
> [    0.040381] ....... works.
>
> shows that the kernel has no pre-defined workaround (and you'd
> likely be better of using the same command line option as I
> recommended for Xen here too).
>
> The question why what works on Linux doesn't work on Xen is not
> very interesting unless the suggested command line option doesn't
> help.
>
> Jan
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>



--------------ms010307090206060004090801
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Kryptografische Unterschrift

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFSjCC
BUYwggMuoAMCAQICAwhzEzANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4w
HAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmlu
ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMDA0
MDMxMjE2NDhaFw0xMjA0MDIxMjE2NDhaMEgxHDAaBgNVBAMTE0Zsb3JpYW4gTWFuc2Nod2V0
dXMxKDAmBgkqhkiG9w0BCQEWGUZsb3JpYW5NYW5zY2h3ZXR1c0BnbXguZGUwggEiMA0GCSqG
SIb3DQEBAQUAA4IBDwAwggEKAoIBAQDOx228LSNcMIRtatTC835J0dYDQbcsng06PdtewI0r
rwtxTSXndYotpjS257vzZOlIPMGRPUJL/FZgL7Nw8zaz2d/jCuQnzGgRukKefl2BZV4eW/xq
hrc5tStj1h7+jZyhtGtR1Jt4Y8TOXF/bjBFCoZRgrfo316LoP/zW1WY34UbW3E2hLpkbRkP7
4Tj6tgpH1TZl1UtA2skuL3GQ3+Mx/Wsh7hCNGAvrV+3BGkA5bZMrKRd1Trcz1Bla68m1WAas
xkNL/DbvgSWiIdyT7860wzcdKRS+ANlhtswsnwfj7arLNeBycQkiQeliFnQY2KBC9KZszkZ7
jdO1HgaEWKFLAgMBAAGjggEGMIIBAjAMBgNVHRMBAf8EAjAAMFYGCWCGSAGG+EIBDQRJFkdU
byBnZXQgeW91ciBvd24gY2VydGlmaWNhdGUgZm9yIEZSRUUgaGVhZCBvdmVyIHRvIGh0dHA6
Ly93d3cuQ0FjZXJ0Lm9yZzBABgNVHSUEOTA3BggrBgEFBQcDBAYIKwYBBQUHAwIGCisGAQQB
gjcKAwQGCisGAQQBgjcKAwMGCWCGSAGG+EIEATAyBggrBgEFBQcBAQQmMCQwIgYIKwYBBQUH
MAGGFmh0dHA6Ly9vY3NwLmNhY2VydC5vcmcwJAYDVR0RBB0wG4EZRmxvcmlhbk1hbnNjaHdl
dHVzQGdteC5kZTANBgkqhkiG9w0BAQUFAAOCAgEABTIxdlft8iVgfpvh+nR842ialjkFp5Fi
ow5HOGkTG1tcPczEOvApu8267JHwy390X8ZsOvxZt9QSNmGwKAeQuX1meNgRzXBWuGT5YjOH
2qtwLvXr2AIPaRB1U8Qu2iKEKqjOY8x9SBrU5cFqrN7iySlo7kvvq8DQub5BFLd6FMsCaxZI
Gyxd0FXVy57YEu/ZeknQutGS1NmGFc70hRe53DKILDh/bDO2r4yhvLOujJKjQf2kDkBoBZRI
MyACJiqxz7R+/Dog9zbqcqEiB2YCe1x8KFmgwfevrBH3+MyAhlg5lKA3DTq41kiwlpgC+unC
rgOfGoi1Y1IU/FoXgTil7G87L1IRrnVlcEcd6OiysFgwHsK6Y1ScVPoxJ3gmuqGsYDNlUxoH
U8wLRVexlTuQjCLr3kwbTUlrWfXw1b30Fkx1RludNrP8MO6vDFW4/8tOF9CApplTBZ/FpMhs
l2PF8suztvTobCuc7Z4DnqtfcqfPfcyNR610DaGOrp5eIjcn071z93qwzqOc0qxN1bcJZFM5
IAAKpvLLIlYzbK0fuHMb+xGFwCxjY6uQJrz77xpMu/bfS0LU5Xlzg+VfDFgpeUkY4tGS9e5v
qRyUN2es5+TRqNR0hmdRj3zxL1ogBtcLLHdvcxmna8n5yyHwU2eZkXEr0JW0uOT903skt/mC
/zUxggOUMIIDkAIBATCBgDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8v
d3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAf
BgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZwIDCHMTMAkGBSsOAwIaBQCgggHoMBgG
CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMTIyMjEzMTE0N1ow
IwYJKoZIhvcNAQkEMRYEFIYOHCurRUVWUlIy0QwrSODfYAyMMF8GCSqGSIb3DQEJDzFSMFAw
CwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIB
QDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBkQYJKwYBBAGCNxAEMYGDMIGAMHkxEDAOBgNV
BAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZ
Q0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNl
cnQub3JnAgMIcxMwgZMGCyqGSIb3DQEJEAILMYGDoIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0Ex
HjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWdu
aW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMIcxMw
DQYJKoZIhvcNAQEBBQAEggEAlTBoBDF4VnTaPoL25yBppHXvyppOWbjWZyjqJzJK010PWyIv
LUyXUFEu02Nsui7LVHwEHPxaZ8BCTnVbuPv/iJmycf5BVJPgQNmQhc3NYA45HEBCfLJ2KjqM
VBnd38hrC0eANG9FOELeGjSdHlCNzcRwpUOgSSnlIpZcI+bzQx/vaPtgJ+UBZBnu3va5PGXA
lDRu/odcJkMGh3ShbkNt9y8+T2Nx68BRvBqDp0Pn253eOG5l8wPPU0oUG+XVpwBwRzFoSaa0
C8c5Hdj3jDOBwBFZBWijeFeYvgGxzk1ISiolgwxYHM8vKdXteCd3wTztuS7+X3OGzxuRW9/O
5lr22AAAAAAAAA==
--------------ms010307090206060004090801--


--===============5871928279902479562==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============5871928279902479562==--


From xen-devel-bounces@lists.xensource.com Thu Dec 22 13:13:15 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 Dec 2011 13:13:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdiS7-0007QJ-0e; Thu, 22 Dec 2011 13:12:55 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <florianmanschwetus@gmx.de>) id 1RdiS4-0007Q8-SH
	for xen-devel@lists.xensource.com; Thu, 22 Dec 2011 13:12:53 +0000
X-Env-Sender: florianmanschwetus@gmx.de
X-Msg-Ref: server-13.tower-174.messagelabs.com!1324559565!6545108!1
X-Originating-IP: [213.165.64.22]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMTMuMTY1LjY0LjIyID0+IDEwNTI0MQ==\n,sa_preprocessor: 
	QmFkIElQOiAyMTMuMTY1LjY0LjIyID0+IDEwNTI0MQ==\n, ML_RADAR_SPEW_LINKS_14, 
	spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16906 invoked from network); 22 Dec 2011 13:12:45 -0000
Received: from mailout-de.gmx.net (HELO mailout-de.gmx.net) (213.165.64.22)
	by server-13.tower-174.messagelabs.com with SMTP;
	22 Dec 2011 13:12:45 -0000
Received: (qmail invoked by alias); 22 Dec 2011 13:12:44 -0000
Received: from dslb-088-069-059-020.pools.arcor-ip.net (EHLO [192.168.222.23])
	[88.69.59.20]
	by mail.gmx.net (mp034) with SMTP; 22 Dec 2011 14:12:44 +0100
X-Authenticated: #7518697
X-Provags-ID: V01U2FsdGVkX190kY5vG6R07Q+Mr2u5CRKjdgLDhFIJHEoptILWE3
	JdmWZpoFbGf8LH
Message-ID: <4EF32C93.4040107@gmx.de>
Date: Thu, 22 Dec 2011 14:11:47 +0100
From: Florian Manschwetus <florianmanschwetus@gmx.de>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:8.0) Gecko/20111121 Thunderbird/8.0
MIME-Version: 1.0
To: xen-devel@lists.xensource.com
References: <4EF06B14.4070106@gmx.de> <4EF0B034.1090708@gmx.de>
	<4EF270A7.2010705@gmx.de>
	<4EF307540200007800069894@nat28.tlf.novell.com>
	<4EF2FCED.8010402@gmx.de>
	<4EF33062020000780006995E@nat28.tlf.novell.com>
In-Reply-To: <4EF33062020000780006995E@nat28.tlf.novell.com>
X-Y-GMX-Trusted: 0
Subject: Re: [Xen-devel] [Xen-users] Problem booting xen 4.1.2 on Athlon 64
 X2
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============5871928279902479562=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Dies ist eine kryptografisch unterzeichnete Nachricht im MIME-Format.

--===============5871928279902479562==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms010307090206060004090801"

Dies ist eine kryptografisch unterzeichnete Nachricht im MIME-Format.

--------------ms010307090206060004090801
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: quoted-printable

Looks acpi_skip_timer_override is not the solution:


Loading Xen 4.1.2 ...
Loading Linux x86_64-3.1.5-gentoo ...
Loading initial ramdisk ...
  __  __            _  _    _   ____
  \ \/ /___ _ __   | || |  / | |___ \
   \  // _ \ '_ \  | || |_ | |   __) |
   /  \  __/ | | | |__   _|| |_ / __/
  /_/\_\___|_| |_|    |_|(_)_(_)_____|

(XEN) Xen version 4.1.2 (@) (gcc-Version 4.6.2 (Gentoo 4.6.2 p1.0,=20
pie-0.4.5) ) Thu Dec 15 17:51:19 CET 2011
(XEN) Latest ChangeSet: unavailable
(XEN) Console output is synchronous.
(XEN) Bootloader: GRUB 1.99
(XEN) Command line: placeholder sync_console console_to_ring=20
com1=3D115200,8n1 console=3Dcom1,vga loglvl=3Dall lapic=3Ddebug=20
apic_verbosity=3Ddebug apic=3Ddebug acpi_skip_timer_override
(XEN) Video information:
(XEN)  VGA is text mode 80x25, font 8x16
(XEN)  VBE/DDC methods: none; EDID transfer time: 0 seconds
(XEN)  EDID info not retrieved because no DDC retrieval method detected
(XEN) Disc information:
(XEN)  Found 1 MBR signatures
(XEN)  Found 1 EDD information structures
(XEN) Xen-e820 RAM map:
(XEN)  0000000000000000 - 000000000009fc00 (usable)
(XEN)  000000000009fc00 - 00000000000a0000 (reserved)
(XEN)  00000000000e0000 - 0000000000100000 (reserved)
(XEN)  0000000000100000 - 00000000bffc0000 (usable)
(XEN)  00000000bffc0000 - 00000000bffce000 (ACPI data)
(XEN)  00000000bffce000 - 00000000bfff0000 (ACPI NVS)
(XEN)  00000000bfff0000 - 00000000c0000000 (reserved)
(XEN)  00000000fec00000 - 00000000fec01000 (reserved)
(XEN)  00000000fee00000 - 00000000fef00000 (reserved)
(XEN)  00000000ff780000 - 0000000100000000 (reserved)
(XEN)  0000000100000000 - 0000000140000000 (usable)
(XEN) ACPI: RSDP 000FB840, 0024 (r2 ACPIAM)
(XEN) ACPI: XSDT BFFC0100, 004C (r1 A_M_I_ OEMXSDT   3000826 MSFT       9=
7)
(XEN) ACPI: FACP BFFC0290, 00F4 (r3 A_M_I_ OEMFACP   3000826 MSFT       9=
7)
(XEN) ACPI: DSDT BFFC05C0, 4E38 (r1  A0557 A0557000        0 INTL 2005111=
7)
(XEN) ACPI: FACS BFFCE000, 0040
(XEN) ACPI: APIC BFFC0390, 0070 (r1 A_M_I_ OEMAPIC   3000826 MSFT       9=
7)
(XEN) ACPI: MCFG BFFC0400, 003C (r1 A_M_I_ OEMMCFG   3000826 MSFT       9=
7)
(XEN) ACPI: OEMB BFFCE040, 0060 (r1 A_M_I_ AMI_OEM   3000826 MSFT       9=
7)
(XEN) ACPI: HPET BFFC5400, 0038 (r1 A_M_I_ OEMHPET0  3000826 MSFT       9=
7)
(XEN) System RAM: 4095MB (4193660kB)
(XEN) No NUMA configuration found
(XEN) Faking a node at 0000000000000000-0000000140000000
(XEN) Domain heap initialised
(XEN) found SMP MP-table at 000ff780
(XEN) DMI present.
(XEN) APIC boot state is 'xapic'
(XEN) Using APIC driver default
(XEN) ACPI: PM-Timer IO Port: 0x508
(XEN) ACPI: ACPI SLEEP INFO: pm1x_cnt[504,0], pm1x_evt[500,0]
(XEN) ACPI:                  wakeup_vec[bffce00c], vec_size[20]
(XEN) ACPI: Local APIC address 0xfee00000
(XEN) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
(XEN) Processor #0 15:3 APIC version 16
(XEN) ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled)
(XEN) Processor #1 15:3 APIC version 16
(XEN) ACPI: IOAPIC (id[0x02] address[0xfec00000] gsi_base[0])
(XEN) IOAPIC[0]: apic_id 2, version 17, address 0xfec00000, GSI 0-23
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 0 dfl dfl)
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 14 global_irq 14 high edge)
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 15 global_irq 15 high edge)
(XEN) ACPI: IRQ0 used by override.
(XEN) ACPI: IRQ9 used by override.
(XEN) ACPI: IRQ14 used by override.
(XEN) ACPI: IRQ15 used by override.
(XEN) Enabling APIC mode:  Flat.  Using 1 I/O APICs
(XEN) ACPI: HPET id: 0x10de8201 base: 0xfed00000
(XEN) PCI: MCFG configuration 0: base e0000000 segment 0 buses 0 - 255
(XEN) PCI: Not using MMCONFIG.
(XEN) Table is not found!
(XEN) Using ACPI (MADT) for SMP configuration information
(XEN) mapped APIC to ffff82c3ffffe000 (fee00000)
(XEN) mapped IOAPIC to ffff82c3ffffd000 (fec00000)
(XEN) IRQ limits: 24 GSI, 376 MSI/MSI-X
(XEN) Using scheduler: SMP Credit Scheduler (credit)
(XEN) Detected 2611.923 MHz processor.
(XEN) Initing memory sharing.
(XEN) AMD K8 machine check reporting enabled
(XEN) AMD-Vi: IOMMU not found!
(XEN) I/O virtualisation disabled
(XEN) Getting VERSION: 80050010
(XEN) Getting VERSION: 80050010
(XEN) Getting ID: 0
(XEN) Getting LVT0: 700
(XEN) Getting LVT1: 400
(XEN) enabled ExtINT on CPU#0
(XEN) ESR value before enabling vector: 0x00000004  after: 0x00000000
(XEN) ENABLING IO-APIC IRQs
(XEN)  -> Using new ACK method
(XEN) init IO_APIC IRQs
(XEN)  IO-APIC (apicid-pin) 2-16, 2-17, 2-18, 2-19, 2-20, 2-21, 2-22,=20
2-23 not connected.
(XEN) ..TIMER: vector=3D0xF0 apic1=3D0 pin1=3D0 apic2=3D-1 pin2=3D-1
(XEN) ..MP-BIOS bug: 8254 timer not connected to IO-APIC
(XEN) ...trying to set up timer (IRQ0) through the 8259A ...  failed.
(XEN) ...trying to set up timer as Virtual Wire IRQ... failed.
(XEN) ...trying to set up timer as ExtINT IRQ... failed :(.
(XEN)
(XEN) ****************************************
(XEN) Panic on CPU 0:
(XEN) IO-APIC + timer doesn't work!  Boot with apic_verbosity=3Ddebug and=
=20
send a report.  Then try booting with the 'noapic'=20
option****************************************
(XEN)
(XEN) Reboot in five seconds...



Am 22.12.2011 13:28, schrieb Jan Beulich:
>>>> On 22.12.11 at 10:48, Florian Manschwetus<florianmanschwetus@gmx.de>=
  wrote:
>> Ok, I think I got the output. But I see nothing really helpful in ther=
e.
>> I have attached the boot-log, maybe it gives you the needed informatio=
n.
>
> [    0.028998] ..TIMER: vector=3D0x30 apic1=3D0 pin1=3D0 apic2=3D-1 pin=
2=3D-1
> [    0.029997] ..MP-BIOS bug: 8254 timer not connected to IO-APIC
> [    0.029997] ...trying to set up timer (IRQ0) through the 8259A ...
> [    0.029997] ..... (found apic 0 pin 0) ...
> [    0.040381] ....... works.
>
> shows that the kernel has no pre-defined workaround (and you'd
> likely be better of using the same command line option as I
> recommended for Xen here too).
>
> The question why what works on Linux doesn't work on Xen is not
> very interesting unless the suggested command line option doesn't
> help.
>
> Jan
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>



--------------ms010307090206060004090801
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Kryptografische Unterschrift

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFSjCC
BUYwggMuoAMCAQICAwhzEzANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4w
HAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmlu
ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMDA0
MDMxMjE2NDhaFw0xMjA0MDIxMjE2NDhaMEgxHDAaBgNVBAMTE0Zsb3JpYW4gTWFuc2Nod2V0
dXMxKDAmBgkqhkiG9w0BCQEWGUZsb3JpYW5NYW5zY2h3ZXR1c0BnbXguZGUwggEiMA0GCSqG
SIb3DQEBAQUAA4IBDwAwggEKAoIBAQDOx228LSNcMIRtatTC835J0dYDQbcsng06PdtewI0r
rwtxTSXndYotpjS257vzZOlIPMGRPUJL/FZgL7Nw8zaz2d/jCuQnzGgRukKefl2BZV4eW/xq
hrc5tStj1h7+jZyhtGtR1Jt4Y8TOXF/bjBFCoZRgrfo316LoP/zW1WY34UbW3E2hLpkbRkP7
4Tj6tgpH1TZl1UtA2skuL3GQ3+Mx/Wsh7hCNGAvrV+3BGkA5bZMrKRd1Trcz1Bla68m1WAas
xkNL/DbvgSWiIdyT7860wzcdKRS+ANlhtswsnwfj7arLNeBycQkiQeliFnQY2KBC9KZszkZ7
jdO1HgaEWKFLAgMBAAGjggEGMIIBAjAMBgNVHRMBAf8EAjAAMFYGCWCGSAGG+EIBDQRJFkdU
byBnZXQgeW91ciBvd24gY2VydGlmaWNhdGUgZm9yIEZSRUUgaGVhZCBvdmVyIHRvIGh0dHA6
Ly93d3cuQ0FjZXJ0Lm9yZzBABgNVHSUEOTA3BggrBgEFBQcDBAYIKwYBBQUHAwIGCisGAQQB
gjcKAwQGCisGAQQBgjcKAwMGCWCGSAGG+EIEATAyBggrBgEFBQcBAQQmMCQwIgYIKwYBBQUH
MAGGFmh0dHA6Ly9vY3NwLmNhY2VydC5vcmcwJAYDVR0RBB0wG4EZRmxvcmlhbk1hbnNjaHdl
dHVzQGdteC5kZTANBgkqhkiG9w0BAQUFAAOCAgEABTIxdlft8iVgfpvh+nR842ialjkFp5Fi
ow5HOGkTG1tcPczEOvApu8267JHwy390X8ZsOvxZt9QSNmGwKAeQuX1meNgRzXBWuGT5YjOH
2qtwLvXr2AIPaRB1U8Qu2iKEKqjOY8x9SBrU5cFqrN7iySlo7kvvq8DQub5BFLd6FMsCaxZI
Gyxd0FXVy57YEu/ZeknQutGS1NmGFc70hRe53DKILDh/bDO2r4yhvLOujJKjQf2kDkBoBZRI
MyACJiqxz7R+/Dog9zbqcqEiB2YCe1x8KFmgwfevrBH3+MyAhlg5lKA3DTq41kiwlpgC+unC
rgOfGoi1Y1IU/FoXgTil7G87L1IRrnVlcEcd6OiysFgwHsK6Y1ScVPoxJ3gmuqGsYDNlUxoH
U8wLRVexlTuQjCLr3kwbTUlrWfXw1b30Fkx1RludNrP8MO6vDFW4/8tOF9CApplTBZ/FpMhs
l2PF8suztvTobCuc7Z4DnqtfcqfPfcyNR610DaGOrp5eIjcn071z93qwzqOc0qxN1bcJZFM5
IAAKpvLLIlYzbK0fuHMb+xGFwCxjY6uQJrz77xpMu/bfS0LU5Xlzg+VfDFgpeUkY4tGS9e5v
qRyUN2es5+TRqNR0hmdRj3zxL1ogBtcLLHdvcxmna8n5yyHwU2eZkXEr0JW0uOT903skt/mC
/zUxggOUMIIDkAIBATCBgDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8v
d3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAf
BgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZwIDCHMTMAkGBSsOAwIaBQCgggHoMBgG
CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMTIyMjEzMTE0N1ow
IwYJKoZIhvcNAQkEMRYEFIYOHCurRUVWUlIy0QwrSODfYAyMMF8GCSqGSIb3DQEJDzFSMFAw
CwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIB
QDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBkQYJKwYBBAGCNxAEMYGDMIGAMHkxEDAOBgNV
BAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZ
Q0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNl
cnQub3JnAgMIcxMwgZMGCyqGSIb3DQEJEAILMYGDoIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0Ex
HjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWdu
aW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMIcxMw
DQYJKoZIhvcNAQEBBQAEggEAlTBoBDF4VnTaPoL25yBppHXvyppOWbjWZyjqJzJK010PWyIv
LUyXUFEu02Nsui7LVHwEHPxaZ8BCTnVbuPv/iJmycf5BVJPgQNmQhc3NYA45HEBCfLJ2KjqM
VBnd38hrC0eANG9FOELeGjSdHlCNzcRwpUOgSSnlIpZcI+bzQx/vaPtgJ+UBZBnu3va5PGXA
lDRu/odcJkMGh3ShbkNt9y8+T2Nx68BRvBqDp0Pn253eOG5l8wPPU0oUG+XVpwBwRzFoSaa0
C8c5Hdj3jDOBwBFZBWijeFeYvgGxzk1ISiolgwxYHM8vKdXteCd3wTztuS7+X3OGzxuRW9/O
5lr22AAAAAAAAA==
--------------ms010307090206060004090801--


--===============5871928279902479562==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============5871928279902479562==--


From xen-devel-bounces@lists.xensource.com Thu Dec 22 13:18:00 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 Dec 2011 13: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.xensource.com>)
	id 1RdiWm-0007d3-0e; Thu, 22 Dec 2011 13:17:44 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <florianmanschwetus@gmx.de>) id 1RdiWk-0007cs-BB
	for xen-devel@lists.xensource.com; Thu, 22 Dec 2011 13:17:42 +0000
X-Env-Sender: florianmanschwetus@gmx.de
X-Msg-Ref: server-5.tower-182.messagelabs.com!1324559856!8321952!1
X-Originating-IP: [213.165.64.23]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjEzLjE2NS42NC4yMyA9PiAxMDUxNTQ=\n,
	ML_RADAR_SPEW_LINKS_14,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19229 invoked from network); 22 Dec 2011 13:17:36 -0000
Received: from mailout-de.gmx.net (HELO mailout-de.gmx.net) (213.165.64.23)
	by server-5.tower-182.messagelabs.com with SMTP;
	22 Dec 2011 13:17:36 -0000
Received: (qmail invoked by alias); 22 Dec 2011 13:17:35 -0000
Received: from dslb-088-069-059-020.pools.arcor-ip.net (EHLO [192.168.222.23])
	[88.69.59.20]
	by mail.gmx.net (mp007) with SMTP; 22 Dec 2011 14:17:35 +0100
X-Authenticated: #7518697
X-Provags-ID: V01U2FsdGVkX19i5Dk22iVi/FMMHdZxa39WwAQ8gqPAl8T2WnVWZ+
	wxc21gtG02IjDk
Message-ID: <4EF32DB6.3010108@gmx.de>
Date: Thu, 22 Dec 2011 14:16:38 +0100
From: Florian Manschwetus <florianmanschwetus@gmx.de>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:8.0) Gecko/20111121 Thunderbird/8.0
MIME-Version: 1.0
To: xen-devel@lists.xensource.com
References: <4EF06B14.4070106@gmx.de> <4EF0B034.1090708@gmx.de>
	<4EF270A7.2010705@gmx.de> <4EF3289C.60901@redhat.com>
In-Reply-To: <4EF3289C.60901@redhat.com>
X-Y-GMX-Trusted: 0
Subject: Re: [Xen-devel] [Xen-users] Problem booting xen 4.1.2 on Athlon 64
 X2
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0436087174413071945=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Dies ist eine kryptografisch unterzeichnete Nachricht im MIME-Format.

--===============0436087174413071945==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms000005060707030805040407"

Dies ist eine kryptografisch unterzeichnete Nachricht im MIME-Format.

--------------ms000005060707030805040407
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: quoted-printable

Am 22.12.2011 13:54, schrieb Igor Mammedov:
> On 12/22/2011 12:49 AM, Florian Manschwetus wrote:
>>> (XEN) AMD-Vi: IOMMU not found!
>>> (XEN) I/O virtualisation disabled
>
> I've seen the same issue on a AMD system with upstream xen and
> host booted after iommu=3Doff was added to xen's cmd line..
> Although log says that there isn't iommu, but it worth the shot.
>

Same, here doesn't fix :(

Thx,
Florian


Loading Xen 4.1.2 ...
Loading Linux x86_64-3.1.5-gentoo ...
Loading initial ramdisk ...
  __  __            _  _    _   ____
  \ \/ /___ _ __   | || |  / | |___ \
   \  // _ \ '_ \  | || |_ | |   __) |
   /  \  __/ | | | |__   _|| |_ / __/
  /_/\_\___|_| |_|    |_|(_)_(_)_____|

(XEN) Xen version 4.1.2 (@) (gcc-Version 4.6.2 (Gentoo 4.6.2 p1.0,=20
pie-0.4.5) ) Thu Dec 15 17:51:19 CET 2011
(XEN) Latest ChangeSet: unavailable
(XEN) Console output is synchronous.
(XEN) Bootloader: GRUB 1.99
(XEN) Command line: placeholder sync_console console_to_ring=20
com1=3D115200,8n1 console=3Dcom1,vga loglvl=3Dall lapic=3Ddebug=20
apic_verbosity=3Ddebug apic=3Ddebug iommu=3Doff
(XEN) Video information:
(XEN)  VGA is text mode 80x25, font 8x16
(XEN)  VBE/DDC methods: none; EDID transfer time: 0 seconds
(XEN)  EDID info not retrieved because no DDC retrieval method detected
(XEN) Disc information:
(XEN)  Found 1 MBR signatures
(XEN)  Found 1 EDD information structures
(XEN) Xen-e820 RAM map:
(XEN)  0000000000000000 - 000000000009fc00 (usable)
(XEN)  000000000009fc00 - 00000000000a0000 (reserved)
(XEN)  00000000000e0000 - 0000000000100000 (reserved)
(XEN)  0000000000100000 - 00000000bffc0000 (usable)
(XEN)  00000000bffc0000 - 00000000bffce000 (ACPI data)
(XEN)  00000000bffce000 - 00000000bfff0000 (ACPI NVS)
(XEN)  00000000bfff0000 - 00000000c0000000 (reserved)
(XEN)  00000000fec00000 - 00000000fec01000 (reserved)
(XEN)  00000000fee00000 - 00000000fef00000 (reserved)
(XEN)  00000000ff780000 - 0000000100000000 (reserved)
(XEN)  0000000100000000 - 0000000140000000 (usable)
(XEN) ACPI: RSDP 000FB840, 0024 (r2 ACPIAM)
(XEN) ACPI: XSDT BFFC0100, 004C (r1 A_M_I_ OEMXSDT   3000826 MSFT       9=
7)
(XEN) ACPI: FACP BFFC0290, 00F4 (r3 A_M_I_ OEMFACP   3000826 MSFT       9=
7)
(XEN) ACPI: DSDT BFFC05C0, 4E38 (r1  A0557 A0557000        0 INTL 2005111=
7)
(XEN) ACPI: FACS BFFCE000, 0040
(XEN) ACPI: APIC BFFC0390, 0070 (r1 A_M_I_ OEMAPIC   3000826 MSFT       9=
7)
(XEN) ACPI: MCFG BFFC0400, 003C (r1 A_M_I_ OEMMCFG   3000826 MSFT       9=
7)
(XEN) ACPI: OEMB BFFCE040, 0060 (r1 A_M_I_ AMI_OEM   3000826 MSFT       9=
7)
(XEN) ACPI: HPET BFFC5400, 0038 (r1 A_M_I_ OEMHPET0  3000826 MSFT       9=
7)
(XEN) System RAM: 4095MB (4193660kB)
(XEN) No NUMA configuration found
(XEN) Faking a node at 0000000000000000-0000000140000000
(XEN) Domain heap initialised
(XEN) found SMP MP-table at 000ff780
(XEN) DMI present.
(XEN) APIC boot state is 'xapic'
(XEN) Using APIC driver default
(XEN) ACPI: PM-Timer IO Port: 0x508
(XEN) ACPI: ACPI SLEEP INFO: pm1x_cnt[504,0], pm1x_evt[500,0]
(XEN) ACPI:                  wakeup_vec[bffce00c], vec_size[20]
(XEN) ACPI: Local APIC address 0xfee00000
(XEN) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
(XEN) Processor #0 15:3 APIC version 16
(XEN) ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled)
(XEN) Processor #1 15:3 APIC version 16
(XEN) ACPI: IOAPIC (id[0x02] address[0xfec00000] gsi_base[0])
(XEN) IOAPIC[0]: apic_id 2, version 17, address 0xfec00000, GSI 0-23
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 0 dfl dfl)
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 14 global_irq 14 high edge)
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 15 global_irq 15 high edge)
(XEN) ACPI: IRQ0 used by override.
(XEN) ACPI: IRQ9 used by override.
(XEN) ACPI: IRQ14 used by override.
(XEN) ACPI: IRQ15 used by override.
(XEN) Enabling APIC mode:  Flat.  Using 1 I/O APICs
(XEN) ACPI: HPET id: 0x10de8201 base: 0xfed00000
(XEN) PCI: MCFG configuration 0: base e0000000 segment 0 buses 0 - 255
(XEN) PCI: Not using MMCONFIG.
(XEN) Table is not found!
(XEN) Using ACPI (MADT) for SMP configuration information
(XEN) mapped APIC to ffff82c3ffffe000 (fee00000)
(XEN) mapped IOAPIC to ffff82c3ffffd000 (fec00000)
(XEN) IRQ limits: 24 GSI, 376 MSI/MSI-X
(XEN) Using scheduler: SMP Credit Scheduler (credit)
(XEN) Detected 2611.851 MHz processor.
(XEN) Initing memory sharing.
(XEN) AMD K8 machine check reporting enabled
(XEN) I/O virtualisation disabled
(XEN) Getting VERSION: 80050010
(XEN) Getting VERSION: 80050010
(XEN) Getting ID: 0
(XEN) Getting LVT0: 700
(XEN) Getting LVT1: 400
(XEN) enabled ExtINT on CPU#0
(XEN) ESR value before enabling vector: 0x00000004  after: 0x00000000
(XEN) ENABLING IO-APIC IRQs
(XEN)  -> Using new ACK method
(XEN) init IO_APIC IRQs
(XEN)  IO-APIC (apicid-pin) 2-16, 2-17, 2-18, 2-19, 2-20, 2-21, 2-22,=20
2-23 not connected.
(XEN) ..TIMER: vector=3D0xF0 apic1=3D0 pin1=3D0 apic2=3D-1 pin2=3D-1
(XEN) ..MP-BIOS bug: 8254 timer not connected to IO-APIC
(XEN) ...trying to set up timer (IRQ0) through the 8259A ...  failed.
(XEN) ...trying to set up timer as Virtual Wire IRQ... failed.
(XEN) ...trying to set up timer as ExtINT IRQ... failed :(.
(XEN)
(XEN) ****************************************
(XEN) Panic on CPU 0:
(XEN) IO-APIC + timer doesn't work!  Boot with apic_verbosity=3Ddebug and=
=20
send a report.  Then try booting with the 'noapic'=20
option****************************************
(XEN)
(XEN) Reboot in five seconds...


--------------ms000005060707030805040407
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Kryptografische Unterschrift

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFSjCC
BUYwggMuoAMCAQICAwhzEzANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4w
HAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmlu
ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMDA0
MDMxMjE2NDhaFw0xMjA0MDIxMjE2NDhaMEgxHDAaBgNVBAMTE0Zsb3JpYW4gTWFuc2Nod2V0
dXMxKDAmBgkqhkiG9w0BCQEWGUZsb3JpYW5NYW5zY2h3ZXR1c0BnbXguZGUwggEiMA0GCSqG
SIb3DQEBAQUAA4IBDwAwggEKAoIBAQDOx228LSNcMIRtatTC835J0dYDQbcsng06PdtewI0r
rwtxTSXndYotpjS257vzZOlIPMGRPUJL/FZgL7Nw8zaz2d/jCuQnzGgRukKefl2BZV4eW/xq
hrc5tStj1h7+jZyhtGtR1Jt4Y8TOXF/bjBFCoZRgrfo316LoP/zW1WY34UbW3E2hLpkbRkP7
4Tj6tgpH1TZl1UtA2skuL3GQ3+Mx/Wsh7hCNGAvrV+3BGkA5bZMrKRd1Trcz1Bla68m1WAas
xkNL/DbvgSWiIdyT7860wzcdKRS+ANlhtswsnwfj7arLNeBycQkiQeliFnQY2KBC9KZszkZ7
jdO1HgaEWKFLAgMBAAGjggEGMIIBAjAMBgNVHRMBAf8EAjAAMFYGCWCGSAGG+EIBDQRJFkdU
byBnZXQgeW91ciBvd24gY2VydGlmaWNhdGUgZm9yIEZSRUUgaGVhZCBvdmVyIHRvIGh0dHA6
Ly93d3cuQ0FjZXJ0Lm9yZzBABgNVHSUEOTA3BggrBgEFBQcDBAYIKwYBBQUHAwIGCisGAQQB
gjcKAwQGCisGAQQBgjcKAwMGCWCGSAGG+EIEATAyBggrBgEFBQcBAQQmMCQwIgYIKwYBBQUH
MAGGFmh0dHA6Ly9vY3NwLmNhY2VydC5vcmcwJAYDVR0RBB0wG4EZRmxvcmlhbk1hbnNjaHdl
dHVzQGdteC5kZTANBgkqhkiG9w0BAQUFAAOCAgEABTIxdlft8iVgfpvh+nR842ialjkFp5Fi
ow5HOGkTG1tcPczEOvApu8267JHwy390X8ZsOvxZt9QSNmGwKAeQuX1meNgRzXBWuGT5YjOH
2qtwLvXr2AIPaRB1U8Qu2iKEKqjOY8x9SBrU5cFqrN7iySlo7kvvq8DQub5BFLd6FMsCaxZI
Gyxd0FXVy57YEu/ZeknQutGS1NmGFc70hRe53DKILDh/bDO2r4yhvLOujJKjQf2kDkBoBZRI
MyACJiqxz7R+/Dog9zbqcqEiB2YCe1x8KFmgwfevrBH3+MyAhlg5lKA3DTq41kiwlpgC+unC
rgOfGoi1Y1IU/FoXgTil7G87L1IRrnVlcEcd6OiysFgwHsK6Y1ScVPoxJ3gmuqGsYDNlUxoH
U8wLRVexlTuQjCLr3kwbTUlrWfXw1b30Fkx1RludNrP8MO6vDFW4/8tOF9CApplTBZ/FpMhs
l2PF8suztvTobCuc7Z4DnqtfcqfPfcyNR610DaGOrp5eIjcn071z93qwzqOc0qxN1bcJZFM5
IAAKpvLLIlYzbK0fuHMb+xGFwCxjY6uQJrz77xpMu/bfS0LU5Xlzg+VfDFgpeUkY4tGS9e5v
qRyUN2es5+TRqNR0hmdRj3zxL1ogBtcLLHdvcxmna8n5yyHwU2eZkXEr0JW0uOT903skt/mC
/zUxggOUMIIDkAIBATCBgDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8v
d3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAf
BgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZwIDCHMTMAkGBSsOAwIaBQCgggHoMBgG
CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMTIyMjEzMTYzOFow
IwYJKoZIhvcNAQkEMRYEFAumjNNYc2QCsl4S7eFz564OezWhMF8GCSqGSIb3DQEJDzFSMFAw
CwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIB
QDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBkQYJKwYBBAGCNxAEMYGDMIGAMHkxEDAOBgNV
BAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZ
Q0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNl
cnQub3JnAgMIcxMwgZMGCyqGSIb3DQEJEAILMYGDoIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0Ex
HjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWdu
aW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMIcxMw
DQYJKoZIhvcNAQEBBQAEggEARRlWLkdjlQkOHQwckt/j8GZg218flc3KTrO5IO3jauj9U3tH
3knMXdw8yPZwoS0QvGdlsEEBSu/oIcskBrV4fASOgwRLpFu7DXQ2+DJV8wd4W6/evrkC/w09
Ds5mHn9GL3oYTc9qT00tcZTMMiHblJWwsAzXwYADMsGYhLWTxJVnuLV6G6E4NvTcrmb5T4H+
azi7WVdqQAEZBuD3/mBj+J0m/QSKinsAz1WKwdo6Harupr3b3jHSNeO7E8/A5sKbulmikwg+
hZKUDVkePybGAZoBukGU42BPCYOiFQXSmwTkZKgL9VGGxDeqBXXK4FwaO8AmTm24N0JNdkHn
/UGw1gAAAAAAAA==
--------------ms000005060707030805040407--


--===============0436087174413071945==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============0436087174413071945==--


From xen-devel-bounces@lists.xensource.com Thu Dec 22 13:18:00 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 Dec 2011 13: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.xensource.com>)
	id 1RdiWm-0007d3-0e; Thu, 22 Dec 2011 13:17:44 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <florianmanschwetus@gmx.de>) id 1RdiWk-0007cs-BB
	for xen-devel@lists.xensource.com; Thu, 22 Dec 2011 13:17:42 +0000
X-Env-Sender: florianmanschwetus@gmx.de
X-Msg-Ref: server-5.tower-182.messagelabs.com!1324559856!8321952!1
X-Originating-IP: [213.165.64.23]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjEzLjE2NS42NC4yMyA9PiAxMDUxNTQ=\n,
	ML_RADAR_SPEW_LINKS_14,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19229 invoked from network); 22 Dec 2011 13:17:36 -0000
Received: from mailout-de.gmx.net (HELO mailout-de.gmx.net) (213.165.64.23)
	by server-5.tower-182.messagelabs.com with SMTP;
	22 Dec 2011 13:17:36 -0000
Received: (qmail invoked by alias); 22 Dec 2011 13:17:35 -0000
Received: from dslb-088-069-059-020.pools.arcor-ip.net (EHLO [192.168.222.23])
	[88.69.59.20]
	by mail.gmx.net (mp007) with SMTP; 22 Dec 2011 14:17:35 +0100
X-Authenticated: #7518697
X-Provags-ID: V01U2FsdGVkX19i5Dk22iVi/FMMHdZxa39WwAQ8gqPAl8T2WnVWZ+
	wxc21gtG02IjDk
Message-ID: <4EF32DB6.3010108@gmx.de>
Date: Thu, 22 Dec 2011 14:16:38 +0100
From: Florian Manschwetus <florianmanschwetus@gmx.de>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:8.0) Gecko/20111121 Thunderbird/8.0
MIME-Version: 1.0
To: xen-devel@lists.xensource.com
References: <4EF06B14.4070106@gmx.de> <4EF0B034.1090708@gmx.de>
	<4EF270A7.2010705@gmx.de> <4EF3289C.60901@redhat.com>
In-Reply-To: <4EF3289C.60901@redhat.com>
X-Y-GMX-Trusted: 0
Subject: Re: [Xen-devel] [Xen-users] Problem booting xen 4.1.2 on Athlon 64
 X2
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0436087174413071945=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Dies ist eine kryptografisch unterzeichnete Nachricht im MIME-Format.

--===============0436087174413071945==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms000005060707030805040407"

Dies ist eine kryptografisch unterzeichnete Nachricht im MIME-Format.

--------------ms000005060707030805040407
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: quoted-printable

Am 22.12.2011 13:54, schrieb Igor Mammedov:
> On 12/22/2011 12:49 AM, Florian Manschwetus wrote:
>>> (XEN) AMD-Vi: IOMMU not found!
>>> (XEN) I/O virtualisation disabled
>
> I've seen the same issue on a AMD system with upstream xen and
> host booted after iommu=3Doff was added to xen's cmd line..
> Although log says that there isn't iommu, but it worth the shot.
>

Same, here doesn't fix :(

Thx,
Florian


Loading Xen 4.1.2 ...
Loading Linux x86_64-3.1.5-gentoo ...
Loading initial ramdisk ...
  __  __            _  _    _   ____
  \ \/ /___ _ __   | || |  / | |___ \
   \  // _ \ '_ \  | || |_ | |   __) |
   /  \  __/ | | | |__   _|| |_ / __/
  /_/\_\___|_| |_|    |_|(_)_(_)_____|

(XEN) Xen version 4.1.2 (@) (gcc-Version 4.6.2 (Gentoo 4.6.2 p1.0,=20
pie-0.4.5) ) Thu Dec 15 17:51:19 CET 2011
(XEN) Latest ChangeSet: unavailable
(XEN) Console output is synchronous.
(XEN) Bootloader: GRUB 1.99
(XEN) Command line: placeholder sync_console console_to_ring=20
com1=3D115200,8n1 console=3Dcom1,vga loglvl=3Dall lapic=3Ddebug=20
apic_verbosity=3Ddebug apic=3Ddebug iommu=3Doff
(XEN) Video information:
(XEN)  VGA is text mode 80x25, font 8x16
(XEN)  VBE/DDC methods: none; EDID transfer time: 0 seconds
(XEN)  EDID info not retrieved because no DDC retrieval method detected
(XEN) Disc information:
(XEN)  Found 1 MBR signatures
(XEN)  Found 1 EDD information structures
(XEN) Xen-e820 RAM map:
(XEN)  0000000000000000 - 000000000009fc00 (usable)
(XEN)  000000000009fc00 - 00000000000a0000 (reserved)
(XEN)  00000000000e0000 - 0000000000100000 (reserved)
(XEN)  0000000000100000 - 00000000bffc0000 (usable)
(XEN)  00000000bffc0000 - 00000000bffce000 (ACPI data)
(XEN)  00000000bffce000 - 00000000bfff0000 (ACPI NVS)
(XEN)  00000000bfff0000 - 00000000c0000000 (reserved)
(XEN)  00000000fec00000 - 00000000fec01000 (reserved)
(XEN)  00000000fee00000 - 00000000fef00000 (reserved)
(XEN)  00000000ff780000 - 0000000100000000 (reserved)
(XEN)  0000000100000000 - 0000000140000000 (usable)
(XEN) ACPI: RSDP 000FB840, 0024 (r2 ACPIAM)
(XEN) ACPI: XSDT BFFC0100, 004C (r1 A_M_I_ OEMXSDT   3000826 MSFT       9=
7)
(XEN) ACPI: FACP BFFC0290, 00F4 (r3 A_M_I_ OEMFACP   3000826 MSFT       9=
7)
(XEN) ACPI: DSDT BFFC05C0, 4E38 (r1  A0557 A0557000        0 INTL 2005111=
7)
(XEN) ACPI: FACS BFFCE000, 0040
(XEN) ACPI: APIC BFFC0390, 0070 (r1 A_M_I_ OEMAPIC   3000826 MSFT       9=
7)
(XEN) ACPI: MCFG BFFC0400, 003C (r1 A_M_I_ OEMMCFG   3000826 MSFT       9=
7)
(XEN) ACPI: OEMB BFFCE040, 0060 (r1 A_M_I_ AMI_OEM   3000826 MSFT       9=
7)
(XEN) ACPI: HPET BFFC5400, 0038 (r1 A_M_I_ OEMHPET0  3000826 MSFT       9=
7)
(XEN) System RAM: 4095MB (4193660kB)
(XEN) No NUMA configuration found
(XEN) Faking a node at 0000000000000000-0000000140000000
(XEN) Domain heap initialised
(XEN) found SMP MP-table at 000ff780
(XEN) DMI present.
(XEN) APIC boot state is 'xapic'
(XEN) Using APIC driver default
(XEN) ACPI: PM-Timer IO Port: 0x508
(XEN) ACPI: ACPI SLEEP INFO: pm1x_cnt[504,0], pm1x_evt[500,0]
(XEN) ACPI:                  wakeup_vec[bffce00c], vec_size[20]
(XEN) ACPI: Local APIC address 0xfee00000
(XEN) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
(XEN) Processor #0 15:3 APIC version 16
(XEN) ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled)
(XEN) Processor #1 15:3 APIC version 16
(XEN) ACPI: IOAPIC (id[0x02] address[0xfec00000] gsi_base[0])
(XEN) IOAPIC[0]: apic_id 2, version 17, address 0xfec00000, GSI 0-23
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 0 dfl dfl)
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 14 global_irq 14 high edge)
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 15 global_irq 15 high edge)
(XEN) ACPI: IRQ0 used by override.
(XEN) ACPI: IRQ9 used by override.
(XEN) ACPI: IRQ14 used by override.
(XEN) ACPI: IRQ15 used by override.
(XEN) Enabling APIC mode:  Flat.  Using 1 I/O APICs
(XEN) ACPI: HPET id: 0x10de8201 base: 0xfed00000
(XEN) PCI: MCFG configuration 0: base e0000000 segment 0 buses 0 - 255
(XEN) PCI: Not using MMCONFIG.
(XEN) Table is not found!
(XEN) Using ACPI (MADT) for SMP configuration information
(XEN) mapped APIC to ffff82c3ffffe000 (fee00000)
(XEN) mapped IOAPIC to ffff82c3ffffd000 (fec00000)
(XEN) IRQ limits: 24 GSI, 376 MSI/MSI-X
(XEN) Using scheduler: SMP Credit Scheduler (credit)
(XEN) Detected 2611.851 MHz processor.
(XEN) Initing memory sharing.
(XEN) AMD K8 machine check reporting enabled
(XEN) I/O virtualisation disabled
(XEN) Getting VERSION: 80050010
(XEN) Getting VERSION: 80050010
(XEN) Getting ID: 0
(XEN) Getting LVT0: 700
(XEN) Getting LVT1: 400
(XEN) enabled ExtINT on CPU#0
(XEN) ESR value before enabling vector: 0x00000004  after: 0x00000000
(XEN) ENABLING IO-APIC IRQs
(XEN)  -> Using new ACK method
(XEN) init IO_APIC IRQs
(XEN)  IO-APIC (apicid-pin) 2-16, 2-17, 2-18, 2-19, 2-20, 2-21, 2-22,=20
2-23 not connected.
(XEN) ..TIMER: vector=3D0xF0 apic1=3D0 pin1=3D0 apic2=3D-1 pin2=3D-1
(XEN) ..MP-BIOS bug: 8254 timer not connected to IO-APIC
(XEN) ...trying to set up timer (IRQ0) through the 8259A ...  failed.
(XEN) ...trying to set up timer as Virtual Wire IRQ... failed.
(XEN) ...trying to set up timer as ExtINT IRQ... failed :(.
(XEN)
(XEN) ****************************************
(XEN) Panic on CPU 0:
(XEN) IO-APIC + timer doesn't work!  Boot with apic_verbosity=3Ddebug and=
=20
send a report.  Then try booting with the 'noapic'=20
option****************************************
(XEN)
(XEN) Reboot in five seconds...


--------------ms000005060707030805040407
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Kryptografische Unterschrift

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFSjCC
BUYwggMuoAMCAQICAwhzEzANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4w
HAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmlu
ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMDA0
MDMxMjE2NDhaFw0xMjA0MDIxMjE2NDhaMEgxHDAaBgNVBAMTE0Zsb3JpYW4gTWFuc2Nod2V0
dXMxKDAmBgkqhkiG9w0BCQEWGUZsb3JpYW5NYW5zY2h3ZXR1c0BnbXguZGUwggEiMA0GCSqG
SIb3DQEBAQUAA4IBDwAwggEKAoIBAQDOx228LSNcMIRtatTC835J0dYDQbcsng06PdtewI0r
rwtxTSXndYotpjS257vzZOlIPMGRPUJL/FZgL7Nw8zaz2d/jCuQnzGgRukKefl2BZV4eW/xq
hrc5tStj1h7+jZyhtGtR1Jt4Y8TOXF/bjBFCoZRgrfo316LoP/zW1WY34UbW3E2hLpkbRkP7
4Tj6tgpH1TZl1UtA2skuL3GQ3+Mx/Wsh7hCNGAvrV+3BGkA5bZMrKRd1Trcz1Bla68m1WAas
xkNL/DbvgSWiIdyT7860wzcdKRS+ANlhtswsnwfj7arLNeBycQkiQeliFnQY2KBC9KZszkZ7
jdO1HgaEWKFLAgMBAAGjggEGMIIBAjAMBgNVHRMBAf8EAjAAMFYGCWCGSAGG+EIBDQRJFkdU
byBnZXQgeW91ciBvd24gY2VydGlmaWNhdGUgZm9yIEZSRUUgaGVhZCBvdmVyIHRvIGh0dHA6
Ly93d3cuQ0FjZXJ0Lm9yZzBABgNVHSUEOTA3BggrBgEFBQcDBAYIKwYBBQUHAwIGCisGAQQB
gjcKAwQGCisGAQQBgjcKAwMGCWCGSAGG+EIEATAyBggrBgEFBQcBAQQmMCQwIgYIKwYBBQUH
MAGGFmh0dHA6Ly9vY3NwLmNhY2VydC5vcmcwJAYDVR0RBB0wG4EZRmxvcmlhbk1hbnNjaHdl
dHVzQGdteC5kZTANBgkqhkiG9w0BAQUFAAOCAgEABTIxdlft8iVgfpvh+nR842ialjkFp5Fi
ow5HOGkTG1tcPczEOvApu8267JHwy390X8ZsOvxZt9QSNmGwKAeQuX1meNgRzXBWuGT5YjOH
2qtwLvXr2AIPaRB1U8Qu2iKEKqjOY8x9SBrU5cFqrN7iySlo7kvvq8DQub5BFLd6FMsCaxZI
Gyxd0FXVy57YEu/ZeknQutGS1NmGFc70hRe53DKILDh/bDO2r4yhvLOujJKjQf2kDkBoBZRI
MyACJiqxz7R+/Dog9zbqcqEiB2YCe1x8KFmgwfevrBH3+MyAhlg5lKA3DTq41kiwlpgC+unC
rgOfGoi1Y1IU/FoXgTil7G87L1IRrnVlcEcd6OiysFgwHsK6Y1ScVPoxJ3gmuqGsYDNlUxoH
U8wLRVexlTuQjCLr3kwbTUlrWfXw1b30Fkx1RludNrP8MO6vDFW4/8tOF9CApplTBZ/FpMhs
l2PF8suztvTobCuc7Z4DnqtfcqfPfcyNR610DaGOrp5eIjcn071z93qwzqOc0qxN1bcJZFM5
IAAKpvLLIlYzbK0fuHMb+xGFwCxjY6uQJrz77xpMu/bfS0LU5Xlzg+VfDFgpeUkY4tGS9e5v
qRyUN2es5+TRqNR0hmdRj3zxL1ogBtcLLHdvcxmna8n5yyHwU2eZkXEr0JW0uOT903skt/mC
/zUxggOUMIIDkAIBATCBgDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8v
d3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAf
BgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZwIDCHMTMAkGBSsOAwIaBQCgggHoMBgG
CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMTIyMjEzMTYzOFow
IwYJKoZIhvcNAQkEMRYEFAumjNNYc2QCsl4S7eFz564OezWhMF8GCSqGSIb3DQEJDzFSMFAw
CwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIB
QDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBkQYJKwYBBAGCNxAEMYGDMIGAMHkxEDAOBgNV
BAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZ
Q0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNl
cnQub3JnAgMIcxMwgZMGCyqGSIb3DQEJEAILMYGDoIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0Ex
HjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWdu
aW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMIcxMw
DQYJKoZIhvcNAQEBBQAEggEARRlWLkdjlQkOHQwckt/j8GZg218flc3KTrO5IO3jauj9U3tH
3knMXdw8yPZwoS0QvGdlsEEBSu/oIcskBrV4fASOgwRLpFu7DXQ2+DJV8wd4W6/evrkC/w09
Ds5mHn9GL3oYTc9qT00tcZTMMiHblJWwsAzXwYADMsGYhLWTxJVnuLV6G6E4NvTcrmb5T4H+
azi7WVdqQAEZBuD3/mBj+J0m/QSKinsAz1WKwdo6Harupr3b3jHSNeO7E8/A5sKbulmikwg+
hZKUDVkePybGAZoBukGU42BPCYOiFQXSmwTkZKgL9VGGxDeqBXXK4FwaO8AmTm24N0JNdkHn
/UGw1gAAAAAAAA==
--------------ms000005060707030805040407--


--===============0436087174413071945==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============0436087174413071945==--


From xen-devel-bounces@lists.xensource.com Thu Dec 22 13:27:45 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 Dec 2011 13:27:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdigE-0007ot-9N; Thu, 22 Dec 2011 13:27:30 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RdigC-0007oo-Qv
	for xen-devel@lists.xensource.com; Thu, 22 Dec 2011 13:27:29 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1324560442!8239722!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=UPPERCASE_25_50
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24367 invoked from network); 22 Dec 2011 13:27:22 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-15.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 22 Dec 2011 13:27:22 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 22 Dec 2011 13:27:22 +0000
Message-Id: <4EF33E7F02000078000699A2@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 22 Dec 2011 13:28:15 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Florian Manschwetus" <florianmanschwetus@gmx.de>
References: <4EF06B14.4070106@gmx.de> <4EF0B034.1090708@gmx.de>
	<4EF270A7.2010705@gmx.de>
	<4EF307540200007800069894@nat28.tlf.novell.com>
	<4EF2FCED.8010402@gmx.de>
	<4EF33062020000780006995E@nat28.tlf.novell.com>
	<4EF32C93.4040107@gmx.de>
In-Reply-To: <4EF32C93.4040107@gmx.de>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [Xen-users] Problem booting xen 4.1.2 on Athlon 64
 X2
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 22.12.11 at 14:11, Florian Manschwetus <florianmanschwetus@gmx.de> wrote:
> Looks acpi_skip_timer_override is not the solution:

That's unfortunate. Next thing for us to know is whether you have
been told any workaround on the native Linux side to make the
respective messages disappear (i.e. to consider porting over those
bits, if they exist).

If there's no solution known on native Linux, then some debugging
will need to be done with that system (a first guess would then be
that the system is actually reporting the wrong override

(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 0 dfl dfl)

meaning to actually specify global_irq as 2, which would be pretty
strait forward to hack in for an experiment).

Jan

> Loading Xen 4.1.2 ...
> Loading Linux x86_64-3.1.5-gentoo ...
> Loading initial ramdisk ...
>   __  __            _  _    _   ____
>   \ \/ /___ _ __   | || |  / | |___ \
>    \  // _ \ '_ \  | || |_ | |   __) |
>    /  \  __/ | | | |__   _|| |_ / __/
>   /_/\_\___|_| |_|    |_|(_)_(_)_____|
> 
> (XEN) Xen version 4.1.2 (@) (gcc-Version 4.6.2 (Gentoo 4.6.2 p1.0, 
> pie-0.4.5) ) Thu Dec 15 17:51:19 CET 2011
> (XEN) Latest ChangeSet: unavailable
> (XEN) Console output is synchronous.
> (XEN) Bootloader: GRUB 1.99
> (XEN) Command line: placeholder sync_console console_to_ring 
> com1=115200,8n1 console=com1,vga loglvl=all lapic=debug 
> apic_verbosity=debug apic=debug acpi_skip_timer_override
> (XEN) Video information:
> (XEN)  VGA is text mode 80x25, font 8x16
> (XEN)  VBE/DDC methods: none; EDID transfer time: 0 seconds
> (XEN)  EDID info not retrieved because no DDC retrieval method detected
> (XEN) Disc information:
> (XEN)  Found 1 MBR signatures
> (XEN)  Found 1 EDD information structures
> (XEN) Xen-e820 RAM map:
> (XEN)  0000000000000000 - 000000000009fc00 (usable)
> (XEN)  000000000009fc00 - 00000000000a0000 (reserved)
> (XEN)  00000000000e0000 - 0000000000100000 (reserved)
> (XEN)  0000000000100000 - 00000000bffc0000 (usable)
> (XEN)  00000000bffc0000 - 00000000bffce000 (ACPI data)
> (XEN)  00000000bffce000 - 00000000bfff0000 (ACPI NVS)
> (XEN)  00000000bfff0000 - 00000000c0000000 (reserved)
> (XEN)  00000000fec00000 - 00000000fec01000 (reserved)
> (XEN)  00000000fee00000 - 00000000fef00000 (reserved)
> (XEN)  00000000ff780000 - 0000000100000000 (reserved)
> (XEN)  0000000100000000 - 0000000140000000 (usable)
> (XEN) ACPI: RSDP 000FB840, 0024 (r2 ACPIAM)
> (XEN) ACPI: XSDT BFFC0100, 004C (r1 A_M_I_ OEMXSDT   3000826 MSFT       97)
> (XEN) ACPI: FACP BFFC0290, 00F4 (r3 A_M_I_ OEMFACP   3000826 MSFT       97)
> (XEN) ACPI: DSDT BFFC05C0, 4E38 (r1  A0557 A0557000        0 INTL 20051117)
> (XEN) ACPI: FACS BFFCE000, 0040
> (XEN) ACPI: APIC BFFC0390, 0070 (r1 A_M_I_ OEMAPIC   3000826 MSFT       97)
> (XEN) ACPI: MCFG BFFC0400, 003C (r1 A_M_I_ OEMMCFG   3000826 MSFT       97)
> (XEN) ACPI: OEMB BFFCE040, 0060 (r1 A_M_I_ AMI_OEM   3000826 MSFT       97)
> (XEN) ACPI: HPET BFFC5400, 0038 (r1 A_M_I_ OEMHPET0  3000826 MSFT       97)
> (XEN) System RAM: 4095MB (4193660kB)
> (XEN) No NUMA configuration found
> (XEN) Faking a node at 0000000000000000-0000000140000000
> (XEN) Domain heap initialised
> (XEN) found SMP MP-table at 000ff780
> (XEN) DMI present.
> (XEN) APIC boot state is 'xapic'
> (XEN) Using APIC driver default
> (XEN) ACPI: PM-Timer IO Port: 0x508
> (XEN) ACPI: ACPI SLEEP INFO: pm1x_cnt[504,0], pm1x_evt[500,0]
> (XEN) ACPI:                  wakeup_vec[bffce00c], vec_size[20]
> (XEN) ACPI: Local APIC address 0xfee00000
> (XEN) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
> (XEN) Processor #0 15:3 APIC version 16
> (XEN) ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled)
> (XEN) Processor #1 15:3 APIC version 16
> (XEN) ACPI: IOAPIC (id[0x02] address[0xfec00000] gsi_base[0])
> (XEN) IOAPIC[0]: apic_id 2, version 17, address 0xfec00000, GSI 0-23
> (XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 0 dfl dfl)
> (XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
> (XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 14 global_irq 14 high edge)
> (XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 15 global_irq 15 high edge)
> (XEN) ACPI: IRQ0 used by override.
> (XEN) ACPI: IRQ9 used by override.
> (XEN) ACPI: IRQ14 used by override.
> (XEN) ACPI: IRQ15 used by override.
> (XEN) Enabling APIC mode:  Flat.  Using 1 I/O APICs
> (XEN) ACPI: HPET id: 0x10de8201 base: 0xfed00000
> (XEN) PCI: MCFG configuration 0: base e0000000 segment 0 buses 0 - 255
> (XEN) PCI: Not using MMCONFIG.
> (XEN) Table is not found!
> (XEN) Using ACPI (MADT) for SMP configuration information
> (XEN) mapped APIC to ffff82c3ffffe000 (fee00000)
> (XEN) mapped IOAPIC to ffff82c3ffffd000 (fec00000)
> (XEN) IRQ limits: 24 GSI, 376 MSI/MSI-X
> (XEN) Using scheduler: SMP Credit Scheduler (credit)
> (XEN) Detected 2611.923 MHz processor.
> (XEN) Initing memory sharing.
> (XEN) AMD K8 machine check reporting enabled
> (XEN) AMD-Vi: IOMMU not found!
> (XEN) I/O virtualisation disabled
> (XEN) Getting VERSION: 80050010
> (XEN) Getting VERSION: 80050010
> (XEN) Getting ID: 0
> (XEN) Getting LVT0: 700
> (XEN) Getting LVT1: 400
> (XEN) enabled ExtINT on CPU#0
> (XEN) ESR value before enabling vector: 0x00000004  after: 0x00000000
> (XEN) ENABLING IO-APIC IRQs
> (XEN)  -> Using new ACK method
> (XEN) init IO_APIC IRQs
> (XEN)  IO-APIC (apicid-pin) 2-16, 2-17, 2-18, 2-19, 2-20, 2-21, 2-22, 
> 2-23 not connected.
> (XEN) ..TIMER: vector=0xF0 apic1=0 pin1=0 apic2=-1 pin2=-1
> (XEN) ..MP-BIOS bug: 8254 timer not connected to IO-APIC
> (XEN) ...trying to set up timer (IRQ0) through the 8259A ...  failed.
> (XEN) ...trying to set up timer as Virtual Wire IRQ... failed.
> (XEN) ...trying to set up timer as ExtINT IRQ... failed :(.
> (XEN)
> (XEN) ****************************************
> (XEN) Panic on CPU 0:
> (XEN) IO-APIC + timer doesn't work!  Boot with apic_verbosity=debug and 
> send a report.  Then try booting with the 'noapic' 
> option****************************************
> (XEN)
> (XEN) Reboot in five seconds...


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 22 13:27:45 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 Dec 2011 13:27:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdigE-0007ot-9N; Thu, 22 Dec 2011 13:27:30 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RdigC-0007oo-Qv
	for xen-devel@lists.xensource.com; Thu, 22 Dec 2011 13:27:29 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1324560442!8239722!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=UPPERCASE_25_50
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24367 invoked from network); 22 Dec 2011 13:27:22 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-15.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 22 Dec 2011 13:27:22 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 22 Dec 2011 13:27:22 +0000
Message-Id: <4EF33E7F02000078000699A2@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 22 Dec 2011 13:28:15 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Florian Manschwetus" <florianmanschwetus@gmx.de>
References: <4EF06B14.4070106@gmx.de> <4EF0B034.1090708@gmx.de>
	<4EF270A7.2010705@gmx.de>
	<4EF307540200007800069894@nat28.tlf.novell.com>
	<4EF2FCED.8010402@gmx.de>
	<4EF33062020000780006995E@nat28.tlf.novell.com>
	<4EF32C93.4040107@gmx.de>
In-Reply-To: <4EF32C93.4040107@gmx.de>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [Xen-users] Problem booting xen 4.1.2 on Athlon 64
 X2
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 22.12.11 at 14:11, Florian Manschwetus <florianmanschwetus@gmx.de> wrote:
> Looks acpi_skip_timer_override is not the solution:

That's unfortunate. Next thing for us to know is whether you have
been told any workaround on the native Linux side to make the
respective messages disappear (i.e. to consider porting over those
bits, if they exist).

If there's no solution known on native Linux, then some debugging
will need to be done with that system (a first guess would then be
that the system is actually reporting the wrong override

(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 0 dfl dfl)

meaning to actually specify global_irq as 2, which would be pretty
strait forward to hack in for an experiment).

Jan

> Loading Xen 4.1.2 ...
> Loading Linux x86_64-3.1.5-gentoo ...
> Loading initial ramdisk ...
>   __  __            _  _    _   ____
>   \ \/ /___ _ __   | || |  / | |___ \
>    \  // _ \ '_ \  | || |_ | |   __) |
>    /  \  __/ | | | |__   _|| |_ / __/
>   /_/\_\___|_| |_|    |_|(_)_(_)_____|
> 
> (XEN) Xen version 4.1.2 (@) (gcc-Version 4.6.2 (Gentoo 4.6.2 p1.0, 
> pie-0.4.5) ) Thu Dec 15 17:51:19 CET 2011
> (XEN) Latest ChangeSet: unavailable
> (XEN) Console output is synchronous.
> (XEN) Bootloader: GRUB 1.99
> (XEN) Command line: placeholder sync_console console_to_ring 
> com1=115200,8n1 console=com1,vga loglvl=all lapic=debug 
> apic_verbosity=debug apic=debug acpi_skip_timer_override
> (XEN) Video information:
> (XEN)  VGA is text mode 80x25, font 8x16
> (XEN)  VBE/DDC methods: none; EDID transfer time: 0 seconds
> (XEN)  EDID info not retrieved because no DDC retrieval method detected
> (XEN) Disc information:
> (XEN)  Found 1 MBR signatures
> (XEN)  Found 1 EDD information structures
> (XEN) Xen-e820 RAM map:
> (XEN)  0000000000000000 - 000000000009fc00 (usable)
> (XEN)  000000000009fc00 - 00000000000a0000 (reserved)
> (XEN)  00000000000e0000 - 0000000000100000 (reserved)
> (XEN)  0000000000100000 - 00000000bffc0000 (usable)
> (XEN)  00000000bffc0000 - 00000000bffce000 (ACPI data)
> (XEN)  00000000bffce000 - 00000000bfff0000 (ACPI NVS)
> (XEN)  00000000bfff0000 - 00000000c0000000 (reserved)
> (XEN)  00000000fec00000 - 00000000fec01000 (reserved)
> (XEN)  00000000fee00000 - 00000000fef00000 (reserved)
> (XEN)  00000000ff780000 - 0000000100000000 (reserved)
> (XEN)  0000000100000000 - 0000000140000000 (usable)
> (XEN) ACPI: RSDP 000FB840, 0024 (r2 ACPIAM)
> (XEN) ACPI: XSDT BFFC0100, 004C (r1 A_M_I_ OEMXSDT   3000826 MSFT       97)
> (XEN) ACPI: FACP BFFC0290, 00F4 (r3 A_M_I_ OEMFACP   3000826 MSFT       97)
> (XEN) ACPI: DSDT BFFC05C0, 4E38 (r1  A0557 A0557000        0 INTL 20051117)
> (XEN) ACPI: FACS BFFCE000, 0040
> (XEN) ACPI: APIC BFFC0390, 0070 (r1 A_M_I_ OEMAPIC   3000826 MSFT       97)
> (XEN) ACPI: MCFG BFFC0400, 003C (r1 A_M_I_ OEMMCFG   3000826 MSFT       97)
> (XEN) ACPI: OEMB BFFCE040, 0060 (r1 A_M_I_ AMI_OEM   3000826 MSFT       97)
> (XEN) ACPI: HPET BFFC5400, 0038 (r1 A_M_I_ OEMHPET0  3000826 MSFT       97)
> (XEN) System RAM: 4095MB (4193660kB)
> (XEN) No NUMA configuration found
> (XEN) Faking a node at 0000000000000000-0000000140000000
> (XEN) Domain heap initialised
> (XEN) found SMP MP-table at 000ff780
> (XEN) DMI present.
> (XEN) APIC boot state is 'xapic'
> (XEN) Using APIC driver default
> (XEN) ACPI: PM-Timer IO Port: 0x508
> (XEN) ACPI: ACPI SLEEP INFO: pm1x_cnt[504,0], pm1x_evt[500,0]
> (XEN) ACPI:                  wakeup_vec[bffce00c], vec_size[20]
> (XEN) ACPI: Local APIC address 0xfee00000
> (XEN) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
> (XEN) Processor #0 15:3 APIC version 16
> (XEN) ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled)
> (XEN) Processor #1 15:3 APIC version 16
> (XEN) ACPI: IOAPIC (id[0x02] address[0xfec00000] gsi_base[0])
> (XEN) IOAPIC[0]: apic_id 2, version 17, address 0xfec00000, GSI 0-23
> (XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 0 dfl dfl)
> (XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
> (XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 14 global_irq 14 high edge)
> (XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 15 global_irq 15 high edge)
> (XEN) ACPI: IRQ0 used by override.
> (XEN) ACPI: IRQ9 used by override.
> (XEN) ACPI: IRQ14 used by override.
> (XEN) ACPI: IRQ15 used by override.
> (XEN) Enabling APIC mode:  Flat.  Using 1 I/O APICs
> (XEN) ACPI: HPET id: 0x10de8201 base: 0xfed00000
> (XEN) PCI: MCFG configuration 0: base e0000000 segment 0 buses 0 - 255
> (XEN) PCI: Not using MMCONFIG.
> (XEN) Table is not found!
> (XEN) Using ACPI (MADT) for SMP configuration information
> (XEN) mapped APIC to ffff82c3ffffe000 (fee00000)
> (XEN) mapped IOAPIC to ffff82c3ffffd000 (fec00000)
> (XEN) IRQ limits: 24 GSI, 376 MSI/MSI-X
> (XEN) Using scheduler: SMP Credit Scheduler (credit)
> (XEN) Detected 2611.923 MHz processor.
> (XEN) Initing memory sharing.
> (XEN) AMD K8 machine check reporting enabled
> (XEN) AMD-Vi: IOMMU not found!
> (XEN) I/O virtualisation disabled
> (XEN) Getting VERSION: 80050010
> (XEN) Getting VERSION: 80050010
> (XEN) Getting ID: 0
> (XEN) Getting LVT0: 700
> (XEN) Getting LVT1: 400
> (XEN) enabled ExtINT on CPU#0
> (XEN) ESR value before enabling vector: 0x00000004  after: 0x00000000
> (XEN) ENABLING IO-APIC IRQs
> (XEN)  -> Using new ACK method
> (XEN) init IO_APIC IRQs
> (XEN)  IO-APIC (apicid-pin) 2-16, 2-17, 2-18, 2-19, 2-20, 2-21, 2-22, 
> 2-23 not connected.
> (XEN) ..TIMER: vector=0xF0 apic1=0 pin1=0 apic2=-1 pin2=-1
> (XEN) ..MP-BIOS bug: 8254 timer not connected to IO-APIC
> (XEN) ...trying to set up timer (IRQ0) through the 8259A ...  failed.
> (XEN) ...trying to set up timer as Virtual Wire IRQ... failed.
> (XEN) ...trying to set up timer as ExtINT IRQ... failed :(.
> (XEN)
> (XEN) ****************************************
> (XEN) Panic on CPU 0:
> (XEN) IO-APIC + timer doesn't work!  Boot with apic_verbosity=debug and 
> send a report.  Then try booting with the 'noapic' 
> option****************************************
> (XEN)
> (XEN) Reboot in five seconds...


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 22 13:30:31 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 Dec 2011 13: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.xensource.com>)
	id 1Rdiio-0007vl-SF; Thu, 22 Dec 2011 13:30:10 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Rdiin-0007vY-JA
	for xen-devel@lists.xensource.com; Thu, 22 Dec 2011 13:30:10 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1324560602!8435622!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Nzk5NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31513 invoked from network); 22 Dec 2011 13:30:03 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Dec 2011 13:30:03 -0000
X-IronPort-AV: E=Sophos;i="4.71,393,1320624000"; 
   d="scan'208";a="9634003"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Dec 2011 13:30:01 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 22 Dec 2011 13:30:01 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1Rdiif-0002B2-6U;
	Thu, 22 Dec 2011 13:30:01 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Rdiie-00006D-SI;
	Thu, 22 Dec 2011 13:30:00 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10593-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 22 Dec 2011 13:30:00 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux test] 10593: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10593 linux real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10593/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf     13 guest-localmigrate.2        fail pass in 10581
 test-i386-i386-pv            16 guest-start.2               fail pass in 10570
 test-amd64-i386-rhel6hvm-amd  7 redhat-install              fail pass in 10570
 test-amd64-amd64-xl-sedf     16 guest-start.2      fail in 10581 pass in 10570
 test-amd64-i386-xl-credit2   16 guest-start.2      fail in 10581 pass in 10593
 test-amd64-i386-rhel6hvm-intel  7 redhat-install   fail in 10581 pass in 10593
 test-i386-i386-xl            16 guest-start.2      fail in 10581 pass in 10593
 test-amd64-i386-xl-multivcpu 16 guest-start.2      fail in 10581 pass in 10593
 test-amd64-i386-xl           16 guest-start.2      fail in 10581 pass in 10593
 test-amd64-amd64-xl          16 guest-start.2      fail in 10581 pass in 10593
 test-amd64-i386-win-vcpus1    7 windows-install    fail in 10581 pass in 10593
 test-amd64-i386-win           7 windows-install    fail in 10570 pass in 10593
 test-amd64-amd64-xl-win       7 windows-install    fail in 10570 pass in 10593
 test-amd64-amd64-win          7 windows-install    fail in 10570 pass in 10593

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-amd64-xl-sedf-pin 16 guest-start.2             fail blocked in 9095
 test-amd64-i386-xl-win7-amd64  7 windows-install          fail blocked in 9095
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install     fail blocked in 9095
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3  7 windows-install           fail blocked in 9095
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop      fail in 10581 never pass
 test-amd64-amd64-xl-win7-amd64 7 windows-install fail in 10581 blocked in 9095
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2         fail in 10570 never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop           fail in 10570 never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop            fail in 10570 never pass
 test-i386-i386-xl-winxpsp3    7 windows-install  fail in 10570 blocked in 9095

version targeted for testing:
 linux                59b1ffe039ce366305d48176b7fccce29ce729d3
baseline version:
 linux                6bec8b4a4c14095d0b7ce424db9d583c3decae6c

------------------------------------------------------------
People who touched revisions under test:
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            fail    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=linux
+ revision=59b1ffe039ce366305d48176b7fccce29ce729d3
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push linux 59b1ffe039ce366305d48176b7fccce29ce729d3
+ branch=linux
+ revision=59b1ffe039ce366305d48176b7fccce29ce729d3
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ : xen@xenbits.xensource.com
+ : xen@xenbits.xensource.com:git/linux-pvops
+ : master
+ : tested/2.6.39.x
+ case "$branch" in
+ cd /export/home/osstest/repos/linux
+ git push xen@xenbits.xensource.com:git/linux-pvops 59b1ffe039ce366305d48176b7fccce29ce729d3:master
Counting objects: 1   
Counting objects: 265   
Counting objects: 1433, done.
Compressing objects:   0% (1/188)   
Compressing objects:   1% (2/188)   
Compressing objects:   2% (4/188)   
Compressing objects:   3% (6/188)   
Compressing objects:   4% (8/188)   
Compressing objects:   5% (10/188)   
Compressing objects:   6% (12/188)   
Compressing objects:   7% (14/188)   
Compressing objects:   8% (16/188)   
Compressing objects:   9% (17/188)   
Compressing objects:  10% (19/188)   
Compressing objects:  11% (21/188)   
Compressing objects:  12% (23/188)   
Compressing objects:  13% (25/188)   
Compressing objects:  14% (27/188)   
Compressing objects:  15% (29/188)   
Compressing objects:  16% (31/188)   
Compressing objects:  17% (32/188)   
Compressing objects:  18% (34/188)   
Compressing objects:  19% (36/188)   
Compressing objects:  20% (38/188)   
Compressing objects:  21% (40/188)   
Compressing objects:  22% (42/188)   
Compressing objects:  23% (44/188)   
Compressing objects:  24% (46/188)   
Compressing objects:  25% (47/188)   
Compressing objects:  26% (49/188)   
Compressing objects:  27% (51/188)   
Compressing objects:  28% (53/188)   
Compressing objects:  29% (55/188)   
Compressing objects:  30% (57/188)   
Compressing objects:  31% (59/188)   
Compressing objects:  32% (61/188)   
Compressing objects:  33% (63/188)   
Compressing objects:  34% (64/188)   
Compressing objects:  35% (66/188)   
Compressing objects:  36% (68/188)   
Compressing objects:  37% (70/188)   
Compressing objects:  38% (72/188)   
Compressing objects:  39% (74/188)   
Compressing objects:  40% (76/188)   
Compressing objects:  41% (78/188)   
Compressing objects:  42% (79/188)   
Compressing objects:  43% (81/188)   
Compressing objects:  44% (83/188)   
Compressing objects:  45% (85/188)   
Compressing objects:  46% (87/188)   
Compressing objects:  47% (89/188)   
Compressing objects:  48% (91/188)   
Compressing objects:  49% (93/188)   
Compressing objects:  50% (94/188)   
Compressing objects:  51% (96/188)   
Compressing objects:  52% (98/188)   
Compressing objects:  53% (100/188)   
Compressing objects:  54% (102/188)   
Compressing objects:  55% (104/188)   
Compressing objects:  56% (106/188)   
Compressing objects:  57% (108/188)   
Compressing objects:  58% (110/188)   
Compressing objects:  59% (111/188)   
Compressing objects:  60% (113/188)   
Compressing objects:  61% (115/188)   
Compressing objects:  62% (117/188)   
Compressing objects:  63% (119/188)   
Compressing objects:  64% (121/188)   
Compressing objects:  65% (123/188)   
Compressing objects:  66% (125/188)   
Compressing objects:  67% (126/188)   
Compressing objects:  68% (128/188)   
Compressing objects:  69% (130/188)   
Compressing objects:  70% (132/188)   
Compressing objects:  71% (134/188)   
Compressing objects:  72% (136/188)   
Compressing objects:  73% (138/188)   
Compressing objects:  74% (140/188)   
Compressing objects:  75% (141/188)   
Compressing objects:  76% (143/188)   
Compressing objects:  77% (145/188)   
Compressing objects:  78% (147/188)   
Compressing objects:  79% (149/188)   
Compressing objects:  80% (151/188)   
Compressing objects:  81% (153/188)   
Compressing objects:  82% (155/188)   
Compressing objects:  83% (157/188)   
Compressing objects:  84% (158/188)   
Compressing objects:  85% (160/188)   
Compressing objects:  86% (162/188)   
Compressing objects:  87% (164/188)   
Compressing objects:  88% (166/188)   
Compressing objects:  89% (168/188)   
Compressing objects:  90% (170/188)   
Compressing objects:  91% (172/188)   
Compressing objects:  92% (173/188)   
Compressing objects:  93% (175/188)   
Compressing objects:  94% (177/188)   
Compressing objects:  95% (179/188)   
Compressing objects:  96% (181/188)   
Compressing objects:  97% (183/188)   
Compressing objects:  98% (185/188)   
Compressing objects:  99% (187/188)   
Compressing objects: 100% (188/188)   
Compressing objects: 100% (188/188), done.
Writing objects:   0% (1/1085)   
Writing objects:   1% (11/1085)   
Writing objects:   2% (22/1085)   
Writing objects:   3% (33/1085)   
Writing objects:   4% (44/1085)   
Writing objects:   5% (55/1085)   
Writing objects:   6% (66/1085)   
Writing objects:   7% (76/1085)   
Writing objects:   8% (87/1085)   
Writing objects:   9% (98/1085)   
Writing objects:  10% (109/1085)   
Writing objects:  11% (120/1085)   
Writing objects:  12% (131/1085)   
Writing objects:  13% (142/1085)   
Writing objects:  14% (152/1085)   
Writing objects:  15% (163/1085)   
Writing objects:  16% (174/1085)   
Writing objects:  17% (186/1085)   
Writing objects:  18% (196/1085)   
Writing objects:  19% (207/1085)   
Writing objects:  20% (217/1085)   
Writing objects:  21% (229/1085)   
Writing objects:  22% (239/1085)   
Writing objects:  23% (250/1085)   
Writing objects:  24% (261/1085)   
Writing objects:  25% (272/1085)   
Writing objects:  26% (283/1085)   
Writing objects:  27% (293/1085)   
Writing objects:  28% (304/1085)   
Writing objects:  29% (315/1085)   
Writing objects:  30% (326/1085)   
Writing objects:  31% (337/1085)   
Writing objects:  32% (348/1085)   
Writing objects:  33% (359/1085)   
Writing objects:  34% (369/1085)   
Writing objects:  35% (380/1085)   
Writing objects:  36% (391/1085)   
Writing objects:  37% (402/1085)   
Writing objects:  38% (413/1085)   
Writing objects:  39% (424/1085)   
Writing objects:  40% (434/1085)   
Writing objects:  41% (446/1085)   
Writing objects:  42% (456/1085)   
Writing objects:  43% (467/1085)   
Writing objects:  44% (478/1085)   
Writing objects:  45% (489/1085)   
Writing objects:  46% (500/1085)   
Writing objects:  47% (511/1085)   
Writing objects:  48% (521/1085)   
Writing objects:  49% (532/1085)   
Writing objects:  50% (543/1085)   
Writing objects:  51% (554/1085)   
Writing objects:  52% (565/1085)   
Writing objects:  53% (576/1085)   
Writing objects:  54% (586/1085)   
Writing objects:  55% (597/1085)   
Writing objects:  56% (608/1085)   
Writing objects:  57% (619/1085)   
Writing objects:  58% (630/1085)   
Writing objects:  59% (641/1085)   
Writing objects:  60% (651/1085)   
Writing objects:  61% (662/1085)   
Writing objects:  62% (673/1085)   
Writing objects:  63% (684/1085)   
Writing objects:  64% (695/1085)   
Writing objects:  65% (706/1085)   
Writing objects:  66% (717/1085)   
Writing objects:  67% (727/1085)   
Writing objects:  68% (738/1085)   
Writing objects:  69% (749/1085)   
Writing objects:  70% (760/1085)   
Writing objects:  71% (771/1085)   
Writing objects:  72% (782/1085)   
Writing objects:  73% (793/1085)   
Writing objects:  74% (803/1085)   
Writing objects:  75% (814/1085)   
Writing objects:  76% (825/1085)   
Writing objects:  77% (836/1085)   
Writing objects:  78% (847/1085)   
Writing objects:  79% (858/1085)   
Writing objects:  80% (868/1085)   
Writing objects:  81% (879/1085)   
Writing objects:  82% (890/1085)   
Writing objects:  83% (901/1085)   
Writing objects:  84% (912/1085)   
Writing objects:  85% (923/1085)   
Writing objects:  86% (934/1085)   
Writing objects:  87% (944/1085)   
Writing objects:  88% (955/1085)   
Writing objects:  89% (966/1085)   
Writing objects:  90% (977/1085)   
Writing objects:  91% (988/1085)   
Writing objects:  92% (999/1085)   
Writing objects:  93% (1010/1085)   
Writing objects:  94% (1020/1085)   
Writing objects:  95% (1031/1085)   
Writing objects:  96% (1042/1085)   
Writing objects:  97% (1053/1085)   
Writing objects:  98% (1064/1085)   
Writing objects:  99% (1075/1085)   
Writing objects: 100% (1085/1085)   
Writing objects: 100% (1085/1085), 185.74 KiB, done.
Total 1085 (delta 893), reused 1082 (delta 891)
To xen@xenbits.xensource.com:git/linux-pvops
   6bec8b4..59b1ffe  59b1ffe039ce366305d48176b7fccce29ce729d3 -> master

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 22 13:30:31 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 Dec 2011 13: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.xensource.com>)
	id 1Rdiio-0007vl-SF; Thu, 22 Dec 2011 13:30:10 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Rdiin-0007vY-JA
	for xen-devel@lists.xensource.com; Thu, 22 Dec 2011 13:30:10 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1324560602!8435622!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Nzk5NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31513 invoked from network); 22 Dec 2011 13:30:03 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Dec 2011 13:30:03 -0000
X-IronPort-AV: E=Sophos;i="4.71,393,1320624000"; 
   d="scan'208";a="9634003"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Dec 2011 13:30:01 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 22 Dec 2011 13:30:01 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1Rdiif-0002B2-6U;
	Thu, 22 Dec 2011 13:30:01 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Rdiie-00006D-SI;
	Thu, 22 Dec 2011 13:30:00 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10593-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 22 Dec 2011 13:30:00 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux test] 10593: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10593 linux real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10593/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf     13 guest-localmigrate.2        fail pass in 10581
 test-i386-i386-pv            16 guest-start.2               fail pass in 10570
 test-amd64-i386-rhel6hvm-amd  7 redhat-install              fail pass in 10570
 test-amd64-amd64-xl-sedf     16 guest-start.2      fail in 10581 pass in 10570
 test-amd64-i386-xl-credit2   16 guest-start.2      fail in 10581 pass in 10593
 test-amd64-i386-rhel6hvm-intel  7 redhat-install   fail in 10581 pass in 10593
 test-i386-i386-xl            16 guest-start.2      fail in 10581 pass in 10593
 test-amd64-i386-xl-multivcpu 16 guest-start.2      fail in 10581 pass in 10593
 test-amd64-i386-xl           16 guest-start.2      fail in 10581 pass in 10593
 test-amd64-amd64-xl          16 guest-start.2      fail in 10581 pass in 10593
 test-amd64-i386-win-vcpus1    7 windows-install    fail in 10581 pass in 10593
 test-amd64-i386-win           7 windows-install    fail in 10570 pass in 10593
 test-amd64-amd64-xl-win       7 windows-install    fail in 10570 pass in 10593
 test-amd64-amd64-win          7 windows-install    fail in 10570 pass in 10593

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-amd64-xl-sedf-pin 16 guest-start.2             fail blocked in 9095
 test-amd64-i386-xl-win7-amd64  7 windows-install          fail blocked in 9095
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install     fail blocked in 9095
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3  7 windows-install           fail blocked in 9095
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop      fail in 10581 never pass
 test-amd64-amd64-xl-win7-amd64 7 windows-install fail in 10581 blocked in 9095
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2         fail in 10570 never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop           fail in 10570 never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop            fail in 10570 never pass
 test-i386-i386-xl-winxpsp3    7 windows-install  fail in 10570 blocked in 9095

version targeted for testing:
 linux                59b1ffe039ce366305d48176b7fccce29ce729d3
baseline version:
 linux                6bec8b4a4c14095d0b7ce424db9d583c3decae6c

------------------------------------------------------------
People who touched revisions under test:
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            fail    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=linux
+ revision=59b1ffe039ce366305d48176b7fccce29ce729d3
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push linux 59b1ffe039ce366305d48176b7fccce29ce729d3
+ branch=linux
+ revision=59b1ffe039ce366305d48176b7fccce29ce729d3
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ : xen@xenbits.xensource.com
+ : xen@xenbits.xensource.com:git/linux-pvops
+ : master
+ : tested/2.6.39.x
+ case "$branch" in
+ cd /export/home/osstest/repos/linux
+ git push xen@xenbits.xensource.com:git/linux-pvops 59b1ffe039ce366305d48176b7fccce29ce729d3:master
Counting objects: 1   
Counting objects: 265   
Counting objects: 1433, done.
Compressing objects:   0% (1/188)   
Compressing objects:   1% (2/188)   
Compressing objects:   2% (4/188)   
Compressing objects:   3% (6/188)   
Compressing objects:   4% (8/188)   
Compressing objects:   5% (10/188)   
Compressing objects:   6% (12/188)   
Compressing objects:   7% (14/188)   
Compressing objects:   8% (16/188)   
Compressing objects:   9% (17/188)   
Compressing objects:  10% (19/188)   
Compressing objects:  11% (21/188)   
Compressing objects:  12% (23/188)   
Compressing objects:  13% (25/188)   
Compressing objects:  14% (27/188)   
Compressing objects:  15% (29/188)   
Compressing objects:  16% (31/188)   
Compressing objects:  17% (32/188)   
Compressing objects:  18% (34/188)   
Compressing objects:  19% (36/188)   
Compressing objects:  20% (38/188)   
Compressing objects:  21% (40/188)   
Compressing objects:  22% (42/188)   
Compressing objects:  23% (44/188)   
Compressing objects:  24% (46/188)   
Compressing objects:  25% (47/188)   
Compressing objects:  26% (49/188)   
Compressing objects:  27% (51/188)   
Compressing objects:  28% (53/188)   
Compressing objects:  29% (55/188)   
Compressing objects:  30% (57/188)   
Compressing objects:  31% (59/188)   
Compressing objects:  32% (61/188)   
Compressing objects:  33% (63/188)   
Compressing objects:  34% (64/188)   
Compressing objects:  35% (66/188)   
Compressing objects:  36% (68/188)   
Compressing objects:  37% (70/188)   
Compressing objects:  38% (72/188)   
Compressing objects:  39% (74/188)   
Compressing objects:  40% (76/188)   
Compressing objects:  41% (78/188)   
Compressing objects:  42% (79/188)   
Compressing objects:  43% (81/188)   
Compressing objects:  44% (83/188)   
Compressing objects:  45% (85/188)   
Compressing objects:  46% (87/188)   
Compressing objects:  47% (89/188)   
Compressing objects:  48% (91/188)   
Compressing objects:  49% (93/188)   
Compressing objects:  50% (94/188)   
Compressing objects:  51% (96/188)   
Compressing objects:  52% (98/188)   
Compressing objects:  53% (100/188)   
Compressing objects:  54% (102/188)   
Compressing objects:  55% (104/188)   
Compressing objects:  56% (106/188)   
Compressing objects:  57% (108/188)   
Compressing objects:  58% (110/188)   
Compressing objects:  59% (111/188)   
Compressing objects:  60% (113/188)   
Compressing objects:  61% (115/188)   
Compressing objects:  62% (117/188)   
Compressing objects:  63% (119/188)   
Compressing objects:  64% (121/188)   
Compressing objects:  65% (123/188)   
Compressing objects:  66% (125/188)   
Compressing objects:  67% (126/188)   
Compressing objects:  68% (128/188)   
Compressing objects:  69% (130/188)   
Compressing objects:  70% (132/188)   
Compressing objects:  71% (134/188)   
Compressing objects:  72% (136/188)   
Compressing objects:  73% (138/188)   
Compressing objects:  74% (140/188)   
Compressing objects:  75% (141/188)   
Compressing objects:  76% (143/188)   
Compressing objects:  77% (145/188)   
Compressing objects:  78% (147/188)   
Compressing objects:  79% (149/188)   
Compressing objects:  80% (151/188)   
Compressing objects:  81% (153/188)   
Compressing objects:  82% (155/188)   
Compressing objects:  83% (157/188)   
Compressing objects:  84% (158/188)   
Compressing objects:  85% (160/188)   
Compressing objects:  86% (162/188)   
Compressing objects:  87% (164/188)   
Compressing objects:  88% (166/188)   
Compressing objects:  89% (168/188)   
Compressing objects:  90% (170/188)   
Compressing objects:  91% (172/188)   
Compressing objects:  92% (173/188)   
Compressing objects:  93% (175/188)   
Compressing objects:  94% (177/188)   
Compressing objects:  95% (179/188)   
Compressing objects:  96% (181/188)   
Compressing objects:  97% (183/188)   
Compressing objects:  98% (185/188)   
Compressing objects:  99% (187/188)   
Compressing objects: 100% (188/188)   
Compressing objects: 100% (188/188), done.
Writing objects:   0% (1/1085)   
Writing objects:   1% (11/1085)   
Writing objects:   2% (22/1085)   
Writing objects:   3% (33/1085)   
Writing objects:   4% (44/1085)   
Writing objects:   5% (55/1085)   
Writing objects:   6% (66/1085)   
Writing objects:   7% (76/1085)   
Writing objects:   8% (87/1085)   
Writing objects:   9% (98/1085)   
Writing objects:  10% (109/1085)   
Writing objects:  11% (120/1085)   
Writing objects:  12% (131/1085)   
Writing objects:  13% (142/1085)   
Writing objects:  14% (152/1085)   
Writing objects:  15% (163/1085)   
Writing objects:  16% (174/1085)   
Writing objects:  17% (186/1085)   
Writing objects:  18% (196/1085)   
Writing objects:  19% (207/1085)   
Writing objects:  20% (217/1085)   
Writing objects:  21% (229/1085)   
Writing objects:  22% (239/1085)   
Writing objects:  23% (250/1085)   
Writing objects:  24% (261/1085)   
Writing objects:  25% (272/1085)   
Writing objects:  26% (283/1085)   
Writing objects:  27% (293/1085)   
Writing objects:  28% (304/1085)   
Writing objects:  29% (315/1085)   
Writing objects:  30% (326/1085)   
Writing objects:  31% (337/1085)   
Writing objects:  32% (348/1085)   
Writing objects:  33% (359/1085)   
Writing objects:  34% (369/1085)   
Writing objects:  35% (380/1085)   
Writing objects:  36% (391/1085)   
Writing objects:  37% (402/1085)   
Writing objects:  38% (413/1085)   
Writing objects:  39% (424/1085)   
Writing objects:  40% (434/1085)   
Writing objects:  41% (446/1085)   
Writing objects:  42% (456/1085)   
Writing objects:  43% (467/1085)   
Writing objects:  44% (478/1085)   
Writing objects:  45% (489/1085)   
Writing objects:  46% (500/1085)   
Writing objects:  47% (511/1085)   
Writing objects:  48% (521/1085)   
Writing objects:  49% (532/1085)   
Writing objects:  50% (543/1085)   
Writing objects:  51% (554/1085)   
Writing objects:  52% (565/1085)   
Writing objects:  53% (576/1085)   
Writing objects:  54% (586/1085)   
Writing objects:  55% (597/1085)   
Writing objects:  56% (608/1085)   
Writing objects:  57% (619/1085)   
Writing objects:  58% (630/1085)   
Writing objects:  59% (641/1085)   
Writing objects:  60% (651/1085)   
Writing objects:  61% (662/1085)   
Writing objects:  62% (673/1085)   
Writing objects:  63% (684/1085)   
Writing objects:  64% (695/1085)   
Writing objects:  65% (706/1085)   
Writing objects:  66% (717/1085)   
Writing objects:  67% (727/1085)   
Writing objects:  68% (738/1085)   
Writing objects:  69% (749/1085)   
Writing objects:  70% (760/1085)   
Writing objects:  71% (771/1085)   
Writing objects:  72% (782/1085)   
Writing objects:  73% (793/1085)   
Writing objects:  74% (803/1085)   
Writing objects:  75% (814/1085)   
Writing objects:  76% (825/1085)   
Writing objects:  77% (836/1085)   
Writing objects:  78% (847/1085)   
Writing objects:  79% (858/1085)   
Writing objects:  80% (868/1085)   
Writing objects:  81% (879/1085)   
Writing objects:  82% (890/1085)   
Writing objects:  83% (901/1085)   
Writing objects:  84% (912/1085)   
Writing objects:  85% (923/1085)   
Writing objects:  86% (934/1085)   
Writing objects:  87% (944/1085)   
Writing objects:  88% (955/1085)   
Writing objects:  89% (966/1085)   
Writing objects:  90% (977/1085)   
Writing objects:  91% (988/1085)   
Writing objects:  92% (999/1085)   
Writing objects:  93% (1010/1085)   
Writing objects:  94% (1020/1085)   
Writing objects:  95% (1031/1085)   
Writing objects:  96% (1042/1085)   
Writing objects:  97% (1053/1085)   
Writing objects:  98% (1064/1085)   
Writing objects:  99% (1075/1085)   
Writing objects: 100% (1085/1085)   
Writing objects: 100% (1085/1085), 185.74 KiB, done.
Total 1085 (delta 893), reused 1082 (delta 891)
To xen@xenbits.xensource.com:git/linux-pvops
   6bec8b4..59b1ffe  59b1ffe039ce366305d48176b7fccce29ce729d3 -> master

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 22 13:34:07 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 Dec 2011 13:34:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdimL-00088m-QT; Thu, 22 Dec 2011 13:33:49 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <florianmanschwetus@gmx.de>) id 1RdimK-000880-5F
	for xen-devel@lists.xensource.com; Thu, 22 Dec 2011 13:33:48 +0000
X-Env-Sender: florianmanschwetus@gmx.de
X-Msg-Ref: server-5.tower-216.messagelabs.com!1324560821!8463165!1
X-Originating-IP: [213.165.64.22]
X-SpamReason: No, hits=0.5 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMTMuMTY1LjY0LjIyID0+IDEwNTI0MQ==\n,sa_preprocessor: 
	QmFkIElQOiAyMTMuMTY1LjY0LjIyID0+IDEwNTI0MQ==\n,BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11830 invoked from network); 22 Dec 2011 13:33:41 -0000
Received: from mailout-de.gmx.net (HELO mailout-de.gmx.net) (213.165.64.22)
	by server-5.tower-216.messagelabs.com with SMTP;
	22 Dec 2011 13:33:41 -0000
Received: (qmail invoked by alias); 22 Dec 2011 13:33:40 -0000
Received: from dslb-088-069-059-020.pools.arcor-ip.net (EHLO [192.168.222.23])
	[88.69.59.20]
	by mail.gmx.net (mp060) with SMTP; 22 Dec 2011 14:33:40 +0100
X-Authenticated: #7518697
X-Provags-ID: V01U2FsdGVkX19appU+I3xaViFp/JOUCcLVc6bVCgEqPAIOWO5Onh
	u253iA2Ppetvgo
Message-ID: <4EF3317B.9020204@gmx.de>
Date: Thu, 22 Dec 2011 14:32:43 +0100
From: Florian Manschwetus <florianmanschwetus@gmx.de>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:8.0) Gecko/20111121 Thunderbird/8.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <4EF06B14.4070106@gmx.de> <4EF0B034.1090708@gmx.de>
	<4EF270A7.2010705@gmx.de>
	<4EF307540200007800069894@nat28.tlf.novell.com>
	<4EF2FCED.8010402@gmx.de>
	<4EF33062020000780006995E@nat28.tlf.novell.com>
	<4EF32C93.4040107@gmx.de>
	<4EF33E7F02000078000699A2@nat28.tlf.novell.com>
In-Reply-To: <4EF33E7F02000078000699A2@nat28.tlf.novell.com>
X-Y-GMX-Trusted: 0
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [Xen-users] Problem booting xen 4.1.2 on Athlon 64
 X2
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0724326868963779280=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Dies ist eine kryptografisch unterzeichnete Nachricht im MIME-Format.

--===============0724326868963779280==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms070108090705030902020607"

Dies ist eine kryptografisch unterzeichnete Nachricht im MIME-Format.

--------------ms070108090705030902020607
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: quoted-printable

Am 22.12.2011 14:28, schrieb Jan Beulich:
>>>> On 22.12.11 at 14:11, Florian Manschwetus<florianmanschwetus@gmx.de>=
  wrote:
>> Looks acpi_skip_timer_override is not the solution:
>
> That's unfortunate. Next thing for us to know is whether you have
> been told any workaround on the native Linux side to make the
> respective messages disappear (i.e. to consider porting over those
> bits, if they exist).
I not used any workaround to get the linux booting, it is an kde sabayon =

amd64, where I installed using portage gentoo-sources, xen, xen-tools,=20
openvswitch
Then gentoo sources compiled following the sabayon custom kernel howto=20
using genkernel, with a slightly modified default config (read as the=20
config of the original sabayon kernel binary) to support dom0.

Thx,
Florian

>
> If there's no solution known on native Linux, then some debugging
> will need to be done with that system (a first guess would then be
> that the system is actually reporting the wrong override
>
> (XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 0 dfl dfl)
>
> meaning to actually specify global_irq as 2, which would be pretty
> strait forward to hack in for an experiment).
>
> Jan


--------------ms070108090705030902020607
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Kryptografische Unterschrift

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFSjCC
BUYwggMuoAMCAQICAwhzEzANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4w
HAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmlu
ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMDA0
MDMxMjE2NDhaFw0xMjA0MDIxMjE2NDhaMEgxHDAaBgNVBAMTE0Zsb3JpYW4gTWFuc2Nod2V0
dXMxKDAmBgkqhkiG9w0BCQEWGUZsb3JpYW5NYW5zY2h3ZXR1c0BnbXguZGUwggEiMA0GCSqG
SIb3DQEBAQUAA4IBDwAwggEKAoIBAQDOx228LSNcMIRtatTC835J0dYDQbcsng06PdtewI0r
rwtxTSXndYotpjS257vzZOlIPMGRPUJL/FZgL7Nw8zaz2d/jCuQnzGgRukKefl2BZV4eW/xq
hrc5tStj1h7+jZyhtGtR1Jt4Y8TOXF/bjBFCoZRgrfo316LoP/zW1WY34UbW3E2hLpkbRkP7
4Tj6tgpH1TZl1UtA2skuL3GQ3+Mx/Wsh7hCNGAvrV+3BGkA5bZMrKRd1Trcz1Bla68m1WAas
xkNL/DbvgSWiIdyT7860wzcdKRS+ANlhtswsnwfj7arLNeBycQkiQeliFnQY2KBC9KZszkZ7
jdO1HgaEWKFLAgMBAAGjggEGMIIBAjAMBgNVHRMBAf8EAjAAMFYGCWCGSAGG+EIBDQRJFkdU
byBnZXQgeW91ciBvd24gY2VydGlmaWNhdGUgZm9yIEZSRUUgaGVhZCBvdmVyIHRvIGh0dHA6
Ly93d3cuQ0FjZXJ0Lm9yZzBABgNVHSUEOTA3BggrBgEFBQcDBAYIKwYBBQUHAwIGCisGAQQB
gjcKAwQGCisGAQQBgjcKAwMGCWCGSAGG+EIEATAyBggrBgEFBQcBAQQmMCQwIgYIKwYBBQUH
MAGGFmh0dHA6Ly9vY3NwLmNhY2VydC5vcmcwJAYDVR0RBB0wG4EZRmxvcmlhbk1hbnNjaHdl
dHVzQGdteC5kZTANBgkqhkiG9w0BAQUFAAOCAgEABTIxdlft8iVgfpvh+nR842ialjkFp5Fi
ow5HOGkTG1tcPczEOvApu8267JHwy390X8ZsOvxZt9QSNmGwKAeQuX1meNgRzXBWuGT5YjOH
2qtwLvXr2AIPaRB1U8Qu2iKEKqjOY8x9SBrU5cFqrN7iySlo7kvvq8DQub5BFLd6FMsCaxZI
Gyxd0FXVy57YEu/ZeknQutGS1NmGFc70hRe53DKILDh/bDO2r4yhvLOujJKjQf2kDkBoBZRI
MyACJiqxz7R+/Dog9zbqcqEiB2YCe1x8KFmgwfevrBH3+MyAhlg5lKA3DTq41kiwlpgC+unC
rgOfGoi1Y1IU/FoXgTil7G87L1IRrnVlcEcd6OiysFgwHsK6Y1ScVPoxJ3gmuqGsYDNlUxoH
U8wLRVexlTuQjCLr3kwbTUlrWfXw1b30Fkx1RludNrP8MO6vDFW4/8tOF9CApplTBZ/FpMhs
l2PF8suztvTobCuc7Z4DnqtfcqfPfcyNR610DaGOrp5eIjcn071z93qwzqOc0qxN1bcJZFM5
IAAKpvLLIlYzbK0fuHMb+xGFwCxjY6uQJrz77xpMu/bfS0LU5Xlzg+VfDFgpeUkY4tGS9e5v
qRyUN2es5+TRqNR0hmdRj3zxL1ogBtcLLHdvcxmna8n5yyHwU2eZkXEr0JW0uOT903skt/mC
/zUxggOUMIIDkAIBATCBgDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8v
d3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAf
BgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZwIDCHMTMAkGBSsOAwIaBQCgggHoMBgG
CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMTIyMjEzMzI0M1ow
IwYJKoZIhvcNAQkEMRYEFO7xvEOtz2eg3qsTClCmcAGZZH2wMF8GCSqGSIb3DQEJDzFSMFAw
CwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIB
QDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBkQYJKwYBBAGCNxAEMYGDMIGAMHkxEDAOBgNV
BAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZ
Q0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNl
cnQub3JnAgMIcxMwgZMGCyqGSIb3DQEJEAILMYGDoIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0Ex
HjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWdu
aW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMIcxMw
DQYJKoZIhvcNAQEBBQAEggEACQOdE9Zv1bFinyohWeOXFls7wYfPEKs4lsa/vugU6a+bWYuH
LxY91429O1B2HgVeK0UFDe0eoiYft3sCK1dz8GAqLQBCCi5RDMIINxIw+OpMWegyKY7wcDJr
WUB+xOCswZOXBnoa8RcYyJWt7l/iugMp8X4E3Gq2zTdgiNibs1GYgUKVJrS7A2FKXMIrwoEa
5NMLzAXBDddN3WfYTcqYYN9Z2rU9RZ9nTAi9eakI+cg6rPMJhDp2OrhGhjcHMY4mYbGh62Lq
RZYe4E6tF8R6JbkRBbHRw3SjcsFGHpxhgSxPHvgTJ6+XayIrJ137YIqtfBnfLXN+jRA8c54F
C9HevAAAAAAAAA==
--------------ms070108090705030902020607--


--===============0724326868963779280==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============0724326868963779280==--


From xen-devel-bounces@lists.xensource.com Thu Dec 22 13:34:07 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 Dec 2011 13:34:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdimL-00088m-QT; Thu, 22 Dec 2011 13:33:49 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <florianmanschwetus@gmx.de>) id 1RdimK-000880-5F
	for xen-devel@lists.xensource.com; Thu, 22 Dec 2011 13:33:48 +0000
X-Env-Sender: florianmanschwetus@gmx.de
X-Msg-Ref: server-5.tower-216.messagelabs.com!1324560821!8463165!1
X-Originating-IP: [213.165.64.22]
X-SpamReason: No, hits=0.5 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMTMuMTY1LjY0LjIyID0+IDEwNTI0MQ==\n,sa_preprocessor: 
	QmFkIElQOiAyMTMuMTY1LjY0LjIyID0+IDEwNTI0MQ==\n,BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11830 invoked from network); 22 Dec 2011 13:33:41 -0000
Received: from mailout-de.gmx.net (HELO mailout-de.gmx.net) (213.165.64.22)
	by server-5.tower-216.messagelabs.com with SMTP;
	22 Dec 2011 13:33:41 -0000
Received: (qmail invoked by alias); 22 Dec 2011 13:33:40 -0000
Received: from dslb-088-069-059-020.pools.arcor-ip.net (EHLO [192.168.222.23])
	[88.69.59.20]
	by mail.gmx.net (mp060) with SMTP; 22 Dec 2011 14:33:40 +0100
X-Authenticated: #7518697
X-Provags-ID: V01U2FsdGVkX19appU+I3xaViFp/JOUCcLVc6bVCgEqPAIOWO5Onh
	u253iA2Ppetvgo
Message-ID: <4EF3317B.9020204@gmx.de>
Date: Thu, 22 Dec 2011 14:32:43 +0100
From: Florian Manschwetus <florianmanschwetus@gmx.de>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:8.0) Gecko/20111121 Thunderbird/8.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <4EF06B14.4070106@gmx.de> <4EF0B034.1090708@gmx.de>
	<4EF270A7.2010705@gmx.de>
	<4EF307540200007800069894@nat28.tlf.novell.com>
	<4EF2FCED.8010402@gmx.de>
	<4EF33062020000780006995E@nat28.tlf.novell.com>
	<4EF32C93.4040107@gmx.de>
	<4EF33E7F02000078000699A2@nat28.tlf.novell.com>
In-Reply-To: <4EF33E7F02000078000699A2@nat28.tlf.novell.com>
X-Y-GMX-Trusted: 0
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [Xen-users] Problem booting xen 4.1.2 on Athlon 64
 X2
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0724326868963779280=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Dies ist eine kryptografisch unterzeichnete Nachricht im MIME-Format.

--===============0724326868963779280==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms070108090705030902020607"

Dies ist eine kryptografisch unterzeichnete Nachricht im MIME-Format.

--------------ms070108090705030902020607
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: quoted-printable

Am 22.12.2011 14:28, schrieb Jan Beulich:
>>>> On 22.12.11 at 14:11, Florian Manschwetus<florianmanschwetus@gmx.de>=
  wrote:
>> Looks acpi_skip_timer_override is not the solution:
>
> That's unfortunate. Next thing for us to know is whether you have
> been told any workaround on the native Linux side to make the
> respective messages disappear (i.e. to consider porting over those
> bits, if they exist).
I not used any workaround to get the linux booting, it is an kde sabayon =

amd64, where I installed using portage gentoo-sources, xen, xen-tools,=20
openvswitch
Then gentoo sources compiled following the sabayon custom kernel howto=20
using genkernel, with a slightly modified default config (read as the=20
config of the original sabayon kernel binary) to support dom0.

Thx,
Florian

>
> If there's no solution known on native Linux, then some debugging
> will need to be done with that system (a first guess would then be
> that the system is actually reporting the wrong override
>
> (XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 0 dfl dfl)
>
> meaning to actually specify global_irq as 2, which would be pretty
> strait forward to hack in for an experiment).
>
> Jan


--------------ms070108090705030902020607
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Kryptografische Unterschrift

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFSjCC
BUYwggMuoAMCAQICAwhzEzANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4w
HAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmlu
ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMDA0
MDMxMjE2NDhaFw0xMjA0MDIxMjE2NDhaMEgxHDAaBgNVBAMTE0Zsb3JpYW4gTWFuc2Nod2V0
dXMxKDAmBgkqhkiG9w0BCQEWGUZsb3JpYW5NYW5zY2h3ZXR1c0BnbXguZGUwggEiMA0GCSqG
SIb3DQEBAQUAA4IBDwAwggEKAoIBAQDOx228LSNcMIRtatTC835J0dYDQbcsng06PdtewI0r
rwtxTSXndYotpjS257vzZOlIPMGRPUJL/FZgL7Nw8zaz2d/jCuQnzGgRukKefl2BZV4eW/xq
hrc5tStj1h7+jZyhtGtR1Jt4Y8TOXF/bjBFCoZRgrfo316LoP/zW1WY34UbW3E2hLpkbRkP7
4Tj6tgpH1TZl1UtA2skuL3GQ3+Mx/Wsh7hCNGAvrV+3BGkA5bZMrKRd1Trcz1Bla68m1WAas
xkNL/DbvgSWiIdyT7860wzcdKRS+ANlhtswsnwfj7arLNeBycQkiQeliFnQY2KBC9KZszkZ7
jdO1HgaEWKFLAgMBAAGjggEGMIIBAjAMBgNVHRMBAf8EAjAAMFYGCWCGSAGG+EIBDQRJFkdU
byBnZXQgeW91ciBvd24gY2VydGlmaWNhdGUgZm9yIEZSRUUgaGVhZCBvdmVyIHRvIGh0dHA6
Ly93d3cuQ0FjZXJ0Lm9yZzBABgNVHSUEOTA3BggrBgEFBQcDBAYIKwYBBQUHAwIGCisGAQQB
gjcKAwQGCisGAQQBgjcKAwMGCWCGSAGG+EIEATAyBggrBgEFBQcBAQQmMCQwIgYIKwYBBQUH
MAGGFmh0dHA6Ly9vY3NwLmNhY2VydC5vcmcwJAYDVR0RBB0wG4EZRmxvcmlhbk1hbnNjaHdl
dHVzQGdteC5kZTANBgkqhkiG9w0BAQUFAAOCAgEABTIxdlft8iVgfpvh+nR842ialjkFp5Fi
ow5HOGkTG1tcPczEOvApu8267JHwy390X8ZsOvxZt9QSNmGwKAeQuX1meNgRzXBWuGT5YjOH
2qtwLvXr2AIPaRB1U8Qu2iKEKqjOY8x9SBrU5cFqrN7iySlo7kvvq8DQub5BFLd6FMsCaxZI
Gyxd0FXVy57YEu/ZeknQutGS1NmGFc70hRe53DKILDh/bDO2r4yhvLOujJKjQf2kDkBoBZRI
MyACJiqxz7R+/Dog9zbqcqEiB2YCe1x8KFmgwfevrBH3+MyAhlg5lKA3DTq41kiwlpgC+unC
rgOfGoi1Y1IU/FoXgTil7G87L1IRrnVlcEcd6OiysFgwHsK6Y1ScVPoxJ3gmuqGsYDNlUxoH
U8wLRVexlTuQjCLr3kwbTUlrWfXw1b30Fkx1RludNrP8MO6vDFW4/8tOF9CApplTBZ/FpMhs
l2PF8suztvTobCuc7Z4DnqtfcqfPfcyNR610DaGOrp5eIjcn071z93qwzqOc0qxN1bcJZFM5
IAAKpvLLIlYzbK0fuHMb+xGFwCxjY6uQJrz77xpMu/bfS0LU5Xlzg+VfDFgpeUkY4tGS9e5v
qRyUN2es5+TRqNR0hmdRj3zxL1ogBtcLLHdvcxmna8n5yyHwU2eZkXEr0JW0uOT903skt/mC
/zUxggOUMIIDkAIBATCBgDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8v
d3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAf
BgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZwIDCHMTMAkGBSsOAwIaBQCgggHoMBgG
CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMTIyMjEzMzI0M1ow
IwYJKoZIhvcNAQkEMRYEFO7xvEOtz2eg3qsTClCmcAGZZH2wMF8GCSqGSIb3DQEJDzFSMFAw
CwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIB
QDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBkQYJKwYBBAGCNxAEMYGDMIGAMHkxEDAOBgNV
BAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZ
Q0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNl
cnQub3JnAgMIcxMwgZMGCyqGSIb3DQEJEAILMYGDoIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0Ex
HjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWdu
aW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMIcxMw
DQYJKoZIhvcNAQEBBQAEggEACQOdE9Zv1bFinyohWeOXFls7wYfPEKs4lsa/vugU6a+bWYuH
LxY91429O1B2HgVeK0UFDe0eoiYft3sCK1dz8GAqLQBCCi5RDMIINxIw+OpMWegyKY7wcDJr
WUB+xOCswZOXBnoa8RcYyJWt7l/iugMp8X4E3Gq2zTdgiNibs1GYgUKVJrS7A2FKXMIrwoEa
5NMLzAXBDddN3WfYTcqYYN9Z2rU9RZ9nTAi9eakI+cg6rPMJhDp2OrhGhjcHMY4mYbGh62Lq
RZYe4E6tF8R6JbkRBbHRw3SjcsFGHpxhgSxPHvgTJ6+XayIrJ137YIqtfBnfLXN+jRA8c54F
C9HevAAAAAAAAA==
--------------ms070108090705030902020607--


--===============0724326868963779280==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============0724326868963779280==--


From xen-devel-bounces@lists.xensource.com Thu Dec 22 13:54:15 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 Dec 2011 13:54:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rdj5j-0008Rx-Nd; Thu, 22 Dec 2011 13:53:51 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <wcohen@redhat.com>) id 1Rdj5i-0008Rp-UL
	for xen-devel@lists.xensource.com; Thu, 22 Dec 2011 13:53:51 +0000
X-Env-Sender: wcohen@redhat.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1324562024!8327770!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDY3MzI=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26807 invoked from network); 22 Dec 2011 13:53:44 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-5.tower-182.messagelabs.com with SMTP;
	22 Dec 2011 13:53:44 -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 pBMDqd3X004841
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 22 Dec 2011 08:52:39 -0500
Received: from [10.11.231.236] (deploy7.rdu.redhat.com [10.11.231.236])
	by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id pBMDqckW014791; Thu, 22 Dec 2011 08:52:38 -0500
Message-ID: <4EF33626.5090605@redhat.com>
Date: Thu, 22 Dec 2011 08:52:38 -0500
From: William Cohen <wcohen@redhat.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.24) Gecko/20111104 Red Hat/3.1.16-2.el6_1
	Thunderbird/3.1.16
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
References: <4ED4069E.7030307@redhat.com>
	<20111128224545.GA7821@andromeda.dapyr.net>
	<4ED54E66.7040209@redhat.com>
	<20111216210922.GA2295@andromeda.dapyr.net>
	<4EF101D5.20600@redhat.com>
	<20111221154350.GA26547@andromeda.dapyr.net>
In-Reply-To: <20111221154350.GA26547@andromeda.dapyr.net>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
Cc: xen-devel@lists.xensource.com,
	oprofile-list <oprofile-list@lists.sourceforge.net>
Subject: Re: [Xen-devel] xenoprof patch for oprofile-0.9.7
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 12/21/2011 10:43 AM, Konrad Rzeszutek Wilk wrote:
> On Tue, Dec 20, 2011 at 04:44:53PM -0500, William Cohen wrote:
>> On 12/16/2011 04:09 PM, Konrad Rzeszutek Wilk wrote:
>>> On Tue, Nov 29, 2011 at 04:28:06PM -0500, William Cohen wrote:
>>>> On 11/28/2011 05:45 PM, Konrad Rzeszutek Wilk wrote:
>>>>> On Mon, Nov 28, 2011 at 05:09:34PM -0500, William Cohen wrote:
>>>>>> I am rebasing Fedora rawhide oprofile package to oprofile-0.9.7. The xenoprof patches on http://xenoprof.sourceforge.net/#download look a bit dated. The newest version is for oprofile-0.9.5. 
>>>>>
>>>>> There was one posted some time ago.. Ah:
>>>>> http://www.flyn.org/patches/linux-xen-passive-oprofile/linux-3.0-xen-passive-oprofile.patch.gz
>>>>>
>>>>> I think that ones works , thought I haven't had a chance to test it
>>>>> myself.
>>>>>>
>>>>>> I massaged the patch oprofile-0.9.5-xen.patch to apply to oprofile-.0.9.7. Attached is that updated patch. Does this look reasonable? Is there a desire to get this into upstream oprofile? Or should the xenoprof patch be dropped?
>>>>>
>>>>> Well, the desire is to get a performance tool in upstream that works
>>>>> with Xen very very very much.
>>>>>
>>>>> The upstream is using the 'perf' framework which is different from oprofile
>>>>> and there hasn't been any patches to take advantage of it.
>>>>>
>>>>> So to answer your question:
>>>>>  1). Its awesome you have posted a patch. Will need to spend some time
>>>>>      with it and and with the version that was posted to see if there is
>>>>>      something missing. Sadly, the kernel patch is not very
>>>>>      upstream-compatible as is. But it will get to folks be able to
>>>>>      do some perf analysis instead of using benchmark tools.
>>>>
>>>> If anyone can exercise the patch and verify that it works well with the current upstream xen, that would be greatly appreciated.
>>>
>>> So I tried to do it today but running in trouble of compiling it on
>>> Fedora Core 16. You wouldn't have any patches floating around to make it
>>> compile? (I used first a virgin 0.9.7 version).
>>>
>>> Thanks!
>>
>> Hi Konrad,
>>
>> Sorry I didn't see this email earlier. 
> 
> That is OK.
>>
>> The patch applies cleanly to oprofile 0.9.7 and builds on fc17. What was the error you got?  How are you configuring it? You should be able to do something like:
> 
> Well, I was getting some errors about the wrong header files, but now
> that started it again the errors don't show up.
> 
> Could be that I had installed the required libraries/headers in between
> when I had the problem and now, but can't recall.
> 
> Should get you some details soon to your question. Thanks!

Hi Konrad,

Glad to hear that oprofile built successfully. One trick that I have done in the past is get the source rpm for a package and then do a "yum-builddep <path-to-srpm>" to make sure that everything needed is installed on the machine before doing development work on the package.

Look forward to the feedback on this version of oprofile.

-Will

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 22 13:54:15 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 Dec 2011 13:54:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rdj5j-0008Rx-Nd; Thu, 22 Dec 2011 13:53:51 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <wcohen@redhat.com>) id 1Rdj5i-0008Rp-UL
	for xen-devel@lists.xensource.com; Thu, 22 Dec 2011 13:53:51 +0000
X-Env-Sender: wcohen@redhat.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1324562024!8327770!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDY3MzI=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26807 invoked from network); 22 Dec 2011 13:53:44 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-5.tower-182.messagelabs.com with SMTP;
	22 Dec 2011 13:53:44 -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 pBMDqd3X004841
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 22 Dec 2011 08:52:39 -0500
Received: from [10.11.231.236] (deploy7.rdu.redhat.com [10.11.231.236])
	by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id pBMDqckW014791; Thu, 22 Dec 2011 08:52:38 -0500
Message-ID: <4EF33626.5090605@redhat.com>
Date: Thu, 22 Dec 2011 08:52:38 -0500
From: William Cohen <wcohen@redhat.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.24) Gecko/20111104 Red Hat/3.1.16-2.el6_1
	Thunderbird/3.1.16
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
References: <4ED4069E.7030307@redhat.com>
	<20111128224545.GA7821@andromeda.dapyr.net>
	<4ED54E66.7040209@redhat.com>
	<20111216210922.GA2295@andromeda.dapyr.net>
	<4EF101D5.20600@redhat.com>
	<20111221154350.GA26547@andromeda.dapyr.net>
In-Reply-To: <20111221154350.GA26547@andromeda.dapyr.net>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
Cc: xen-devel@lists.xensource.com,
	oprofile-list <oprofile-list@lists.sourceforge.net>
Subject: Re: [Xen-devel] xenoprof patch for oprofile-0.9.7
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 12/21/2011 10:43 AM, Konrad Rzeszutek Wilk wrote:
> On Tue, Dec 20, 2011 at 04:44:53PM -0500, William Cohen wrote:
>> On 12/16/2011 04:09 PM, Konrad Rzeszutek Wilk wrote:
>>> On Tue, Nov 29, 2011 at 04:28:06PM -0500, William Cohen wrote:
>>>> On 11/28/2011 05:45 PM, Konrad Rzeszutek Wilk wrote:
>>>>> On Mon, Nov 28, 2011 at 05:09:34PM -0500, William Cohen wrote:
>>>>>> I am rebasing Fedora rawhide oprofile package to oprofile-0.9.7. The xenoprof patches on http://xenoprof.sourceforge.net/#download look a bit dated. The newest version is for oprofile-0.9.5. 
>>>>>
>>>>> There was one posted some time ago.. Ah:
>>>>> http://www.flyn.org/patches/linux-xen-passive-oprofile/linux-3.0-xen-passive-oprofile.patch.gz
>>>>>
>>>>> I think that ones works , thought I haven't had a chance to test it
>>>>> myself.
>>>>>>
>>>>>> I massaged the patch oprofile-0.9.5-xen.patch to apply to oprofile-.0.9.7. Attached is that updated patch. Does this look reasonable? Is there a desire to get this into upstream oprofile? Or should the xenoprof patch be dropped?
>>>>>
>>>>> Well, the desire is to get a performance tool in upstream that works
>>>>> with Xen very very very much.
>>>>>
>>>>> The upstream is using the 'perf' framework which is different from oprofile
>>>>> and there hasn't been any patches to take advantage of it.
>>>>>
>>>>> So to answer your question:
>>>>>  1). Its awesome you have posted a patch. Will need to spend some time
>>>>>      with it and and with the version that was posted to see if there is
>>>>>      something missing. Sadly, the kernel patch is not very
>>>>>      upstream-compatible as is. But it will get to folks be able to
>>>>>      do some perf analysis instead of using benchmark tools.
>>>>
>>>> If anyone can exercise the patch and verify that it works well with the current upstream xen, that would be greatly appreciated.
>>>
>>> So I tried to do it today but running in trouble of compiling it on
>>> Fedora Core 16. You wouldn't have any patches floating around to make it
>>> compile? (I used first a virgin 0.9.7 version).
>>>
>>> Thanks!
>>
>> Hi Konrad,
>>
>> Sorry I didn't see this email earlier. 
> 
> That is OK.
>>
>> The patch applies cleanly to oprofile 0.9.7 and builds on fc17. What was the error you got?  How are you configuring it? You should be able to do something like:
> 
> Well, I was getting some errors about the wrong header files, but now
> that started it again the errors don't show up.
> 
> Could be that I had installed the required libraries/headers in between
> when I had the problem and now, but can't recall.
> 
> Should get you some details soon to your question. Thanks!

Hi Konrad,

Glad to hear that oprofile built successfully. One trick that I have done in the past is get the source rpm for a package and then do a "yum-builddep <path-to-srpm>" to make sure that everything needed is installed on the machine before doing development work on the package.

Look forward to the feedback on this version of oprofile.

-Will

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 22 14:20:19 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 Dec 2011 14:20:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdjUo-0000hN-K1; Thu, 22 Dec 2011 14:19:46 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RdjUn-0000hI-5x
	for xen-devel@lists.xensource.com; Thu, 22 Dec 2011 14:19:45 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1324563559!50340343!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Nzk5NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9194 invoked from network); 22 Dec 2011 14:19:19 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Dec 2011 14:19:19 -0000
X-IronPort-AV: E=Sophos;i="4.71,393,1320624000"; 
   d="scan'208";a="9635510"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Dec 2011 14:19:22 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 22 Dec 2011 14:19:22 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau Monne <roger.pau@entel.upc.edu>
Date: Thu, 22 Dec 2011 14:19:21 +0000
In-Reply-To: <f4ff3ce53fd2286def61.1324374813@alpine.localdomain>
References: <f4ff3ce53fd2286def61.1324374813@alpine.localdomain>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1324563561.7877.89.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] libxl: add support for yajl 2.x
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2011-12-20 at 09:53 +0000, Roger Pau Monne wrote:
> iff -r f72b99fccfca -r f4ff3ce53fd2 tools/check/check_yajl_lib
> --- a/tools/check/check_yajl_lib        Tue Dec 20 08:31:40 2011 +0100
> +++ b/tools/check/check_yajl_lib        Tue Dec 20 10:53:16 2011 +0100
> @@ -3,4 +3,4 @@
>  
>  . ./funcs.sh
>  
> -has_lib libyajl.so.1 || fail "can't find libyajl.so.1 version 1"
> +has_lib libyajl.so.1 || has_lib libyajl.so.2 || fail "can't find
> libyajl.so.1 version 1 or libyajl.so.2 version 2" 

The purpose of specifically checking for .so.1 was to avoid trying to
use v2. Since you've fixed this you can just make it check for
libyajl.so.


> diff -r f72b99fccfca -r f4ff3ce53fd2 tools/libxl/libxl_json.h
> --- a/tools/libxl/libxl_json.h  Tue Dec 20 08:31:40 2011 +0100
> +++ b/tools/libxl/libxl_json.h  Tue Dec 20 10:53:16 2011 +0100
> @@ -16,8 +16,14 @@
>  #define LIBXL_JSON_H
>  
>  #include <yajl/yajl_gen.h>
> +#include <yajl/yajl_version.h>

Sadly this isn't in the version of libyajl in Debian Stable which is
1.0.8-1. :-(

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 22 14:20:19 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 Dec 2011 14:20:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdjUo-0000hN-K1; Thu, 22 Dec 2011 14:19:46 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RdjUn-0000hI-5x
	for xen-devel@lists.xensource.com; Thu, 22 Dec 2011 14:19:45 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1324563559!50340343!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Nzk5NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9194 invoked from network); 22 Dec 2011 14:19:19 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Dec 2011 14:19:19 -0000
X-IronPort-AV: E=Sophos;i="4.71,393,1320624000"; 
   d="scan'208";a="9635510"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Dec 2011 14:19:22 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 22 Dec 2011 14:19:22 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau Monne <roger.pau@entel.upc.edu>
Date: Thu, 22 Dec 2011 14:19:21 +0000
In-Reply-To: <f4ff3ce53fd2286def61.1324374813@alpine.localdomain>
References: <f4ff3ce53fd2286def61.1324374813@alpine.localdomain>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1324563561.7877.89.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] libxl: add support for yajl 2.x
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2011-12-20 at 09:53 +0000, Roger Pau Monne wrote:
> iff -r f72b99fccfca -r f4ff3ce53fd2 tools/check/check_yajl_lib
> --- a/tools/check/check_yajl_lib        Tue Dec 20 08:31:40 2011 +0100
> +++ b/tools/check/check_yajl_lib        Tue Dec 20 10:53:16 2011 +0100
> @@ -3,4 +3,4 @@
>  
>  . ./funcs.sh
>  
> -has_lib libyajl.so.1 || fail "can't find libyajl.so.1 version 1"
> +has_lib libyajl.so.1 || has_lib libyajl.so.2 || fail "can't find
> libyajl.so.1 version 1 or libyajl.so.2 version 2" 

The purpose of specifically checking for .so.1 was to avoid trying to
use v2. Since you've fixed this you can just make it check for
libyajl.so.


> diff -r f72b99fccfca -r f4ff3ce53fd2 tools/libxl/libxl_json.h
> --- a/tools/libxl/libxl_json.h  Tue Dec 20 08:31:40 2011 +0100
> +++ b/tools/libxl/libxl_json.h  Tue Dec 20 10:53:16 2011 +0100
> @@ -16,8 +16,14 @@
>  #define LIBXL_JSON_H
>  
>  #include <yajl/yajl_gen.h>
> +#include <yajl/yajl_version.h>

Sadly this isn't in the version of libyajl in Debian Stable which is
1.0.8-1. :-(

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 22 14:24:49 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 Dec 2011 14:24:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdjZR-0000pF-BV; Thu, 22 Dec 2011 14:24:33 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RdjZQ-0000p3-5q
	for xen-devel@lists.xensource.com; Thu, 22 Dec 2011 14:24:32 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1324563864!1707210!1
X-Originating-IP: [209.85.210.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14398 invoked from network); 22 Dec 2011 14:24:26 -0000
Received: from mail-pz0-f43.google.com (HELO mail-pz0-f43.google.com)
	(209.85.210.43)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Dec 2011 14:24:26 -0000
Received: by daec6 with SMTP id c6so34243947dae.30
	for <xen-devel@lists.xensource.com>;
	Thu, 22 Dec 2011 06:24:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=1+NAU2pRYvoPEvTG2COSuujVh6vfwZoIdXjlYB2hau0=;
	b=NAbd1z09o3nkWIuMgW7S7jIP1rwZxVARYtG8s/pmGMGxcIYsuyWVPMuZE1/wd7Jaf4
	XEDzjn0ocIbq0Y/C/nij3ZEreLmiX2HrK2UY+r9xHgrWIzILvRbgsoZCZtND3nVKIym4
	Am0JmFFkv3U8FCBilFF2spl6xdY4AdtDidiRc=
MIME-Version: 1.0
Received: by 10.68.189.133 with SMTP id gi5mr23632705pbc.27.1324563864024;
	Thu, 22 Dec 2011 06:24:24 -0800 (PST)
Received: by 10.142.47.17 with HTTP; Thu, 22 Dec 2011 06:24:23 -0800 (PST)
In-Reply-To: <1324563561.7877.89.camel@zakaz.uk.xensource.com>
References: <f4ff3ce53fd2286def61.1324374813@alpine.localdomain>
	<1324563561.7877.89.camel@zakaz.uk.xensource.com>
Date: Thu, 22 Dec 2011 15:24:23 +0100
X-Google-Sender-Auth: 4kzvyW1sB318gn3BCRra75BjpzY
Message-ID: <CAPLaKK6QBfN0AQ3SfdSSiDJNzY2OCV+ZJymHoW3=BzLBLy5dgw@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] libxl: add support for yajl 2.x
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

MjAxMS8xMi8yMiBJYW4gQ2FtcGJlbGwgPElhbi5DYW1wYmVsbEBjaXRyaXguY29tPjoKPiBPbiBU
dWUsIDIwMTEtMTItMjAgYXQgMDk6NTMgKzAwMDAsIFJvZ2VyIFBhdSBNb25uZSB3cm90ZToKPj4g
aWZmIC1yIGY3MmI5OWZjY2ZjYSAtciBmNGZmM2NlNTNmZDIgdG9vbHMvY2hlY2svY2hlY2tfeWFq
bF9saWIKPj4gLS0tIGEvdG9vbHMvY2hlY2svY2hlY2tfeWFqbF9saWIgwqAgwqAgwqAgwqBUdWUg
RGVjIDIwIDA4OjMxOjQwIDIwMTEgKzAxMDAKPj4gKysrIGIvdG9vbHMvY2hlY2svY2hlY2tfeWFq
bF9saWIgwqAgwqAgwqAgwqBUdWUgRGVjIDIwIDEwOjUzOjE2IDIwMTEgKzAxMDAKPj4gQEAgLTMs
NCArMyw0IEBACj4+Cj4+IMKgLiAuL2Z1bmNzLnNoCj4+Cj4+IC1oYXNfbGliIGxpYnlhamwuc28u
MSB8fCBmYWlsICJjYW4ndCBmaW5kIGxpYnlhamwuc28uMSB2ZXJzaW9uIDEiCj4+ICtoYXNfbGli
IGxpYnlhamwuc28uMSB8fCBoYXNfbGliIGxpYnlhamwuc28uMiB8fCBmYWlsICJjYW4ndCBmaW5k
Cj4+IGxpYnlhamwuc28uMSB2ZXJzaW9uIDEgb3IgbGlieWFqbC5zby4yIHZlcnNpb24gMiIKPgo+
IFRoZSBwdXJwb3NlIG9mIHNwZWNpZmljYWxseSBjaGVja2luZyBmb3IgLnNvLjEgd2FzIHRvIGF2
b2lkIHRyeWluZyB0bwo+IHVzZSB2Mi4gU2luY2UgeW91J3ZlIGZpeGVkIHRoaXMgeW91IGNhbiBq
dXN0IG1ha2UgaXQgY2hlY2sgZm9yCj4gbGlieWFqbC5zby4KPgo+Cj4+IGRpZmYgLXIgZjcyYjk5
ZmNjZmNhIC1yIGY0ZmYzY2U1M2ZkMiB0b29scy9saWJ4bC9saWJ4bF9qc29uLmgKPj4gLS0tIGEv
dG9vbHMvbGlieGwvbGlieGxfanNvbi5oIMKgVHVlIERlYyAyMCAwODozMTo0MCAyMDExICswMTAw
Cj4+ICsrKyBiL3Rvb2xzL2xpYnhsL2xpYnhsX2pzb24uaCDCoFR1ZSBEZWMgMjAgMTA6NTM6MTYg
MjAxMSArMDEwMAo+PiBAQCAtMTYsOCArMTYsMTQgQEAKPj4gwqAjZGVmaW5lIExJQlhMX0pTT05f
SAo+Pgo+PiDCoCNpbmNsdWRlIDx5YWpsL3lhamxfZ2VuLmg+Cj4+ICsjaW5jbHVkZSA8eWFqbC95
YWpsX3ZlcnNpb24uaD4KPgo+IFNhZGx5IHRoaXMgaXNuJ3QgaW4gdGhlIHZlcnNpb24gb2YgbGli
eWFqbCBpbiBEZWJpYW4gU3RhYmxlIHdoaWNoIGlzCj4gMS4wLjgtMS4gOi0oCgpUaGlzIGlzIHdo
YXQgSSB3YXMgYWZyYWlkIG9mLCBvbGRlciB2ZXJzaW9ucyBvZiB5YWpsIGRvZXNuJ3QgaGF2ZQp5
YWpsX3ZlcnNpb24uaC4gU28gbm93IEkgd2lsbCBoYXZlIHRvIGNoZWNrIGlmIHlhamxfdmVyc2lv
bi5oIGlzCnByZXNlbnQgdG8gaW5jbHVkZSBpdC4gV2lsbCB0cnkgdG8gcHV0IGFuIHVwZGF0ZWQg
cGF0Y2ggdG9kYXkuCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29t
Cmh0dHA6Ly9saXN0cy54ZW5zb3VyY2UuY29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Thu Dec 22 14:24:49 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 Dec 2011 14:24:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdjZR-0000pF-BV; Thu, 22 Dec 2011 14:24:33 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RdjZQ-0000p3-5q
	for xen-devel@lists.xensource.com; Thu, 22 Dec 2011 14:24:32 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1324563864!1707210!1
X-Originating-IP: [209.85.210.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14398 invoked from network); 22 Dec 2011 14:24:26 -0000
Received: from mail-pz0-f43.google.com (HELO mail-pz0-f43.google.com)
	(209.85.210.43)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Dec 2011 14:24:26 -0000
Received: by daec6 with SMTP id c6so34243947dae.30
	for <xen-devel@lists.xensource.com>;
	Thu, 22 Dec 2011 06:24:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=1+NAU2pRYvoPEvTG2COSuujVh6vfwZoIdXjlYB2hau0=;
	b=NAbd1z09o3nkWIuMgW7S7jIP1rwZxVARYtG8s/pmGMGxcIYsuyWVPMuZE1/wd7Jaf4
	XEDzjn0ocIbq0Y/C/nij3ZEreLmiX2HrK2UY+r9xHgrWIzILvRbgsoZCZtND3nVKIym4
	Am0JmFFkv3U8FCBilFF2spl6xdY4AdtDidiRc=
MIME-Version: 1.0
Received: by 10.68.189.133 with SMTP id gi5mr23632705pbc.27.1324563864024;
	Thu, 22 Dec 2011 06:24:24 -0800 (PST)
Received: by 10.142.47.17 with HTTP; Thu, 22 Dec 2011 06:24:23 -0800 (PST)
In-Reply-To: <1324563561.7877.89.camel@zakaz.uk.xensource.com>
References: <f4ff3ce53fd2286def61.1324374813@alpine.localdomain>
	<1324563561.7877.89.camel@zakaz.uk.xensource.com>
Date: Thu, 22 Dec 2011 15:24:23 +0100
X-Google-Sender-Auth: 4kzvyW1sB318gn3BCRra75BjpzY
Message-ID: <CAPLaKK6QBfN0AQ3SfdSSiDJNzY2OCV+ZJymHoW3=BzLBLy5dgw@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] libxl: add support for yajl 2.x
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

MjAxMS8xMi8yMiBJYW4gQ2FtcGJlbGwgPElhbi5DYW1wYmVsbEBjaXRyaXguY29tPjoKPiBPbiBU
dWUsIDIwMTEtMTItMjAgYXQgMDk6NTMgKzAwMDAsIFJvZ2VyIFBhdSBNb25uZSB3cm90ZToKPj4g
aWZmIC1yIGY3MmI5OWZjY2ZjYSAtciBmNGZmM2NlNTNmZDIgdG9vbHMvY2hlY2svY2hlY2tfeWFq
bF9saWIKPj4gLS0tIGEvdG9vbHMvY2hlY2svY2hlY2tfeWFqbF9saWIgwqAgwqAgwqAgwqBUdWUg
RGVjIDIwIDA4OjMxOjQwIDIwMTEgKzAxMDAKPj4gKysrIGIvdG9vbHMvY2hlY2svY2hlY2tfeWFq
bF9saWIgwqAgwqAgwqAgwqBUdWUgRGVjIDIwIDEwOjUzOjE2IDIwMTEgKzAxMDAKPj4gQEAgLTMs
NCArMyw0IEBACj4+Cj4+IMKgLiAuL2Z1bmNzLnNoCj4+Cj4+IC1oYXNfbGliIGxpYnlhamwuc28u
MSB8fCBmYWlsICJjYW4ndCBmaW5kIGxpYnlhamwuc28uMSB2ZXJzaW9uIDEiCj4+ICtoYXNfbGli
IGxpYnlhamwuc28uMSB8fCBoYXNfbGliIGxpYnlhamwuc28uMiB8fCBmYWlsICJjYW4ndCBmaW5k
Cj4+IGxpYnlhamwuc28uMSB2ZXJzaW9uIDEgb3IgbGlieWFqbC5zby4yIHZlcnNpb24gMiIKPgo+
IFRoZSBwdXJwb3NlIG9mIHNwZWNpZmljYWxseSBjaGVja2luZyBmb3IgLnNvLjEgd2FzIHRvIGF2
b2lkIHRyeWluZyB0bwo+IHVzZSB2Mi4gU2luY2UgeW91J3ZlIGZpeGVkIHRoaXMgeW91IGNhbiBq
dXN0IG1ha2UgaXQgY2hlY2sgZm9yCj4gbGlieWFqbC5zby4KPgo+Cj4+IGRpZmYgLXIgZjcyYjk5
ZmNjZmNhIC1yIGY0ZmYzY2U1M2ZkMiB0b29scy9saWJ4bC9saWJ4bF9qc29uLmgKPj4gLS0tIGEv
dG9vbHMvbGlieGwvbGlieGxfanNvbi5oIMKgVHVlIERlYyAyMCAwODozMTo0MCAyMDExICswMTAw
Cj4+ICsrKyBiL3Rvb2xzL2xpYnhsL2xpYnhsX2pzb24uaCDCoFR1ZSBEZWMgMjAgMTA6NTM6MTYg
MjAxMSArMDEwMAo+PiBAQCAtMTYsOCArMTYsMTQgQEAKPj4gwqAjZGVmaW5lIExJQlhMX0pTT05f
SAo+Pgo+PiDCoCNpbmNsdWRlIDx5YWpsL3lhamxfZ2VuLmg+Cj4+ICsjaW5jbHVkZSA8eWFqbC95
YWpsX3ZlcnNpb24uaD4KPgo+IFNhZGx5IHRoaXMgaXNuJ3QgaW4gdGhlIHZlcnNpb24gb2YgbGli
eWFqbCBpbiBEZWJpYW4gU3RhYmxlIHdoaWNoIGlzCj4gMS4wLjgtMS4gOi0oCgpUaGlzIGlzIHdo
YXQgSSB3YXMgYWZyYWlkIG9mLCBvbGRlciB2ZXJzaW9ucyBvZiB5YWpsIGRvZXNuJ3QgaGF2ZQp5
YWpsX3ZlcnNpb24uaC4gU28gbm93IEkgd2lsbCBoYXZlIHRvIGNoZWNrIGlmIHlhamxfdmVyc2lv
bi5oIGlzCnByZXNlbnQgdG8gaW5jbHVkZSBpdC4gV2lsbCB0cnkgdG8gcHV0IGFuIHVwZGF0ZWQg
cGF0Y2ggdG9kYXkuCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29t
Cmh0dHA6Ly9saXN0cy54ZW5zb3VyY2UuY29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Thu Dec 22 14:35:26 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 Dec 2011 14:35:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rdjjb-00012E-Fk; Thu, 22 Dec 2011 14:35:03 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RdjjZ-000129-Bu
	for xen-devel@lists.xensource.com; Thu, 22 Dec 2011 14:35:01 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1324564475!59973656!1
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.7 required=7.0 tests=DATE_IN_PAST_48_96, RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2770 invoked from network); 22 Dec 2011 14:34:36 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Dec 2011 14:34:36 -0000
Received: by wgbds11 with SMTP id ds11so13711745wgb.24
	for <xen-devel@lists.xensource.com>;
	Thu, 22 Dec 2011 06:34:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:user-agent:date:from:to:cc;
	bh=vSJHfcTiWU6IF0PJ3QjcvQTmA29DFMZnB/ZufoqWIOM=;
	b=LkV1yrYR4BAPgdPr9diZUHa/xuvaKdeokTW3/UYVrtw2u413hnToFdWx8tvEK+7va3
	HdWWhGW9vheVoxxSqRY/oKWrivtvIq99c6G9eAkBLThpnMKgHJ7xb5b6xtP/kDqpOM4T
	aXfUBXxOaYIfnqY6pGbxofDEv7QWfoQ80RiUs=
Received: by 10.227.203.84 with SMTP id fh20mr10707143wbb.27.1324564494949;
	Thu, 22 Dec 2011 06:34:54 -0800 (PST)
Received: from alpine.localdomain (tina.upc.es. [147.83.39.243])
	by mx.google.com with ESMTPS id ep16sm9928641wbb.21.2011.12.22.06.34.52
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 22 Dec 2011 06:34:53 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 716d6d48e647d1d4352f7206e74e693152a4f8fa
Message-Id: <716d6d48e647d1d4352f.1324385606@alpine.localdomain>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Tue, 20 Dec 2011 13:53:26 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Cc: Ian.Campbell@citrix.com
Subject: [Xen-devel] [PATCH v2] libxl: add support for yajl 2.x
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1324385575 -3600
# Node ID 716d6d48e647d1d4352f7206e74e693152a4f8fa
# Parent  f72b99fccfca694674259cc1c03c526a827b67ec
libxl: add support for yajl 2.x

This patch adds support for yajl versions 2.x, while retaining 1.x
compatibility. This patch adds quite a lot of #ifdefs all over the
json code, so I'm open to suggestions if there's a better way to
handle this.

Tested with yajl 2.0.3 and 1.0.12.

Changes since v1:

 * Check if yajl_version.h is present before trying to include it.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r f72b99fccfca -r 716d6d48e647 Config.mk
--- a/Config.mk	Tue Dec 20 08:31:40 2011 +0100
+++ b/Config.mk	Tue Dec 20 13:52:55 2011 +0100
@@ -186,6 +186,11 @@ CONFIG_LIBICONV   := $(shell export OS="
                        . $(XEN_ROOT)/tools/check/funcs.sh; \
                        has_lib libiconv.so && echo 'y' || echo 'n')
 
+CONFIG_YAJL_VERSION := $(shell export OS="`uname -s`"; \
+                       export CHECK_INCLUDES="$(CHECK_INCLUDES)"; \
+                       . $(XEN_ROOT)/tools/check/funcs.sh; \
+                       has_header yajl/yajl_version.h && echo 'y' || echo 'n')
+
 # Enable XSM security module (by default, Flask).
 XSM_ENABLE ?= n
 FLASK_ENABLE ?= $(XSM_ENABLE)
diff -r f72b99fccfca -r 716d6d48e647 tools/check/check_yajl_lib
--- a/tools/check/check_yajl_lib	Tue Dec 20 08:31:40 2011 +0100
+++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
@@ -1,6 +0,0 @@
-#!/bin/sh
-# CHECK-BUILD CHECK-INSTALL
-
-. ./funcs.sh
-
-has_lib libyajl.so.1 || fail "can't find libyajl.so.1 version 1"
diff -r f72b99fccfca -r 716d6d48e647 tools/libxl/Makefile
--- a/tools/libxl/Makefile	Tue Dec 20 08:31:40 2011 +0100
+++ b/tools/libxl/Makefile	Tue Dec 20 13:52:55 2011 +0100
@@ -19,6 +19,10 @@ ifeq ($(CONFIG_Linux),y)
 LIBUUID_LIBS += -luuid
 endif
 
+ifeq ($(CONFIG_YAJL_VERSION),y)
+CFLAGS += -DHAVE_YAJL_VERSION
+endif
+
 LIBXL_LIBS =
 LIBXL_LIBS = $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) $(LDLIBS_libxenstore) $(LDLIBS_libblktapctl) $(UTIL_LIBS) $(LIBUUID_LIBS)
 
diff -r f72b99fccfca -r 716d6d48e647 tools/libxl/libxl_json.c
--- a/tools/libxl/libxl_json.c	Tue Dec 20 08:31:40 2011 +0100
+++ b/tools/libxl/libxl_json.c	Tue Dec 20 13:52:55 2011 +0100
@@ -519,7 +519,11 @@ static bool is_decimal(const char *s, un
     return false;
 }
 
+#ifdef HAVE_YAJL_V2
+static int json_callback_number(void *opaque, const char *s, size_t len)
+#else
 static int json_callback_number(void *opaque, const char *s, unsigned int len)
+#endif
 {
     libxl__yajl_ctx *ctx = opaque;
     libxl__json_object *obj = NULL;
@@ -575,8 +579,13 @@ out:
     return 1;
 }
 
+#ifdef HAVE_YAJL_V2
+static int json_callback_string(void *opaque, const unsigned char *str,
+                                size_t len)
+#else
 static int json_callback_string(void *opaque, const unsigned char *str,
                                 unsigned int len)
+#endif
 {
     libxl__yajl_ctx *ctx = opaque;
     char *t = NULL;
@@ -608,8 +617,13 @@ static int json_callback_string(void *op
     return 1;
 }
 
+#ifdef HAVE_YAJL_V2
+static int json_callback_map_key(void *opaque, const unsigned char *str,
+                                 size_t len)
+#else
 static int json_callback_map_key(void *opaque, const unsigned char *str,
                                  unsigned int len)
+#endif
 {
     libxl__yajl_ctx *ctx = opaque;
     char *t = NULL;
@@ -772,17 +786,26 @@ libxl__json_object *libxl__json_parse(li
     DEBUG_GEN_ALLOC(&yajl_ctx);
 
     if (yajl_ctx.hand == NULL) {
+#ifdef HAVE_YAJL_V2
+        yajl_ctx.hand = yajl_alloc(&callbacks, NULL, &yajl_ctx);
+#else
         yajl_parser_config cfg = {
             .allowComments = 1,
             .checkUTF8 = 1,
         };
         yajl_ctx.hand = yajl_alloc(&callbacks, &cfg, NULL, &yajl_ctx);
+#endif
     }
     status = yajl_parse(yajl_ctx.hand, (const unsigned char *)s, strlen(s));
     if (status != yajl_status_ok)
         goto out;
+    
+#ifdef HAVE_YAJL_V2
+    status = yajl_complete_parse(yajl_ctx.hand);
+#else
+    status = yajl_parse_complete(yajl_ctx.hand);
+#endif
 
-    status = yajl_parse_complete(yajl_ctx.hand);
     if (status != yajl_status_ok)
         goto out;
 
@@ -834,14 +857,25 @@ static const char *yajl_gen_status_to_st
 char *libxl__object_to_json(libxl_ctx *ctx, const char *type,
                             libxl__gen_json_callback gen, void *p)
 {
+#ifndef HAVE_YAJL_V2
     yajl_gen_config conf = { 1, "    " };
+#endif
     const unsigned char *buf;
     char *ret = NULL;
+#ifdef HAVE_YAJL_V2
+    size_t len = 0;
+#else
     unsigned int len = 0;
+#endif
     yajl_gen_status s;
     yajl_gen hand;
 
+#ifdef HAVE_YAJL_V2
+    hand = yajl_gen_alloc(NULL);
+#else
     hand = yajl_gen_alloc(&conf, NULL);
+#endif
+
     if (!hand)
         return NULL;
 
diff -r f72b99fccfca -r 716d6d48e647 tools/libxl/libxl_json.h
--- a/tools/libxl/libxl_json.h	Tue Dec 20 08:31:40 2011 +0100
+++ b/tools/libxl/libxl_json.h	Tue Dec 20 13:52:55 2011 +0100
@@ -17,7 +17,16 @@
 
 #include <yajl/yajl_gen.h>
 
+#ifdef HAVE_YAJL_VERSION
+#  include <yajl/yajl_version.h>
+#endif
+
 #include <_libxl_types_json.h>
 #include <_libxl_types_internal_json.h>
 
+/* YAJL version check */
+#if defined(YAJL_MAJOR) && (YAJL_MAJOR > 1)
+#  define HAVE_YAJL_V2 1
+#endif
+
 #endif /* LIBXL_JSON_H */
diff -r f72b99fccfca -r 716d6d48e647 tools/libxl/libxl_qmp.c
--- a/tools/libxl/libxl_qmp.c	Tue Dec 20 08:31:40 2011 +0100
+++ b/tools/libxl/libxl_qmp.c	Tue Dec 20 13:52:55 2011 +0100
@@ -453,15 +453,26 @@ static char *qmp_send_prepare(libxl__gc 
                               qmp_callback_t callback, void *opaque,
                               qmp_request_context *context)
 {
+#ifndef HAVE_YAJL_V2
     yajl_gen_config conf = { 0, NULL };
+#endif
     const unsigned char *buf = NULL;
     char *ret = NULL;
+#ifdef HAVE_YAJL_V2
+    size_t len = 0;
+#else
     unsigned int len = 0;
+#endif
     yajl_gen_status s;
     yajl_gen hand;
     callback_id_pair *elm = NULL;
 
+#ifdef HAVE_YAJL_V2
+    hand = yajl_gen_alloc(NULL);
+#else
     hand = yajl_gen_alloc(&conf, NULL);
+#endif
+
     if (!hand) {
         return NULL;
     }

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 22 14:35:26 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 Dec 2011 14:35:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rdjjb-00012E-Fk; Thu, 22 Dec 2011 14:35:03 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RdjjZ-000129-Bu
	for xen-devel@lists.xensource.com; Thu, 22 Dec 2011 14:35:01 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1324564475!59973656!1
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.7 required=7.0 tests=DATE_IN_PAST_48_96, RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2770 invoked from network); 22 Dec 2011 14:34:36 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Dec 2011 14:34:36 -0000
Received: by wgbds11 with SMTP id ds11so13711745wgb.24
	for <xen-devel@lists.xensource.com>;
	Thu, 22 Dec 2011 06:34:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:user-agent:date:from:to:cc;
	bh=vSJHfcTiWU6IF0PJ3QjcvQTmA29DFMZnB/ZufoqWIOM=;
	b=LkV1yrYR4BAPgdPr9diZUHa/xuvaKdeokTW3/UYVrtw2u413hnToFdWx8tvEK+7va3
	HdWWhGW9vheVoxxSqRY/oKWrivtvIq99c6G9eAkBLThpnMKgHJ7xb5b6xtP/kDqpOM4T
	aXfUBXxOaYIfnqY6pGbxofDEv7QWfoQ80RiUs=
Received: by 10.227.203.84 with SMTP id fh20mr10707143wbb.27.1324564494949;
	Thu, 22 Dec 2011 06:34:54 -0800 (PST)
Received: from alpine.localdomain (tina.upc.es. [147.83.39.243])
	by mx.google.com with ESMTPS id ep16sm9928641wbb.21.2011.12.22.06.34.52
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 22 Dec 2011 06:34:53 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 716d6d48e647d1d4352f7206e74e693152a4f8fa
Message-Id: <716d6d48e647d1d4352f.1324385606@alpine.localdomain>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Tue, 20 Dec 2011 13:53:26 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Cc: Ian.Campbell@citrix.com
Subject: [Xen-devel] [PATCH v2] libxl: add support for yajl 2.x
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1324385575 -3600
# Node ID 716d6d48e647d1d4352f7206e74e693152a4f8fa
# Parent  f72b99fccfca694674259cc1c03c526a827b67ec
libxl: add support for yajl 2.x

This patch adds support for yajl versions 2.x, while retaining 1.x
compatibility. This patch adds quite a lot of #ifdefs all over the
json code, so I'm open to suggestions if there's a better way to
handle this.

Tested with yajl 2.0.3 and 1.0.12.

Changes since v1:

 * Check if yajl_version.h is present before trying to include it.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r f72b99fccfca -r 716d6d48e647 Config.mk
--- a/Config.mk	Tue Dec 20 08:31:40 2011 +0100
+++ b/Config.mk	Tue Dec 20 13:52:55 2011 +0100
@@ -186,6 +186,11 @@ CONFIG_LIBICONV   := $(shell export OS="
                        . $(XEN_ROOT)/tools/check/funcs.sh; \
                        has_lib libiconv.so && echo 'y' || echo 'n')
 
+CONFIG_YAJL_VERSION := $(shell export OS="`uname -s`"; \
+                       export CHECK_INCLUDES="$(CHECK_INCLUDES)"; \
+                       . $(XEN_ROOT)/tools/check/funcs.sh; \
+                       has_header yajl/yajl_version.h && echo 'y' || echo 'n')
+
 # Enable XSM security module (by default, Flask).
 XSM_ENABLE ?= n
 FLASK_ENABLE ?= $(XSM_ENABLE)
diff -r f72b99fccfca -r 716d6d48e647 tools/check/check_yajl_lib
--- a/tools/check/check_yajl_lib	Tue Dec 20 08:31:40 2011 +0100
+++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
@@ -1,6 +0,0 @@
-#!/bin/sh
-# CHECK-BUILD CHECK-INSTALL
-
-. ./funcs.sh
-
-has_lib libyajl.so.1 || fail "can't find libyajl.so.1 version 1"
diff -r f72b99fccfca -r 716d6d48e647 tools/libxl/Makefile
--- a/tools/libxl/Makefile	Tue Dec 20 08:31:40 2011 +0100
+++ b/tools/libxl/Makefile	Tue Dec 20 13:52:55 2011 +0100
@@ -19,6 +19,10 @@ ifeq ($(CONFIG_Linux),y)
 LIBUUID_LIBS += -luuid
 endif
 
+ifeq ($(CONFIG_YAJL_VERSION),y)
+CFLAGS += -DHAVE_YAJL_VERSION
+endif
+
 LIBXL_LIBS =
 LIBXL_LIBS = $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) $(LDLIBS_libxenstore) $(LDLIBS_libblktapctl) $(UTIL_LIBS) $(LIBUUID_LIBS)
 
diff -r f72b99fccfca -r 716d6d48e647 tools/libxl/libxl_json.c
--- a/tools/libxl/libxl_json.c	Tue Dec 20 08:31:40 2011 +0100
+++ b/tools/libxl/libxl_json.c	Tue Dec 20 13:52:55 2011 +0100
@@ -519,7 +519,11 @@ static bool is_decimal(const char *s, un
     return false;
 }
 
+#ifdef HAVE_YAJL_V2
+static int json_callback_number(void *opaque, const char *s, size_t len)
+#else
 static int json_callback_number(void *opaque, const char *s, unsigned int len)
+#endif
 {
     libxl__yajl_ctx *ctx = opaque;
     libxl__json_object *obj = NULL;
@@ -575,8 +579,13 @@ out:
     return 1;
 }
 
+#ifdef HAVE_YAJL_V2
+static int json_callback_string(void *opaque, const unsigned char *str,
+                                size_t len)
+#else
 static int json_callback_string(void *opaque, const unsigned char *str,
                                 unsigned int len)
+#endif
 {
     libxl__yajl_ctx *ctx = opaque;
     char *t = NULL;
@@ -608,8 +617,13 @@ static int json_callback_string(void *op
     return 1;
 }
 
+#ifdef HAVE_YAJL_V2
+static int json_callback_map_key(void *opaque, const unsigned char *str,
+                                 size_t len)
+#else
 static int json_callback_map_key(void *opaque, const unsigned char *str,
                                  unsigned int len)
+#endif
 {
     libxl__yajl_ctx *ctx = opaque;
     char *t = NULL;
@@ -772,17 +786,26 @@ libxl__json_object *libxl__json_parse(li
     DEBUG_GEN_ALLOC(&yajl_ctx);
 
     if (yajl_ctx.hand == NULL) {
+#ifdef HAVE_YAJL_V2
+        yajl_ctx.hand = yajl_alloc(&callbacks, NULL, &yajl_ctx);
+#else
         yajl_parser_config cfg = {
             .allowComments = 1,
             .checkUTF8 = 1,
         };
         yajl_ctx.hand = yajl_alloc(&callbacks, &cfg, NULL, &yajl_ctx);
+#endif
     }
     status = yajl_parse(yajl_ctx.hand, (const unsigned char *)s, strlen(s));
     if (status != yajl_status_ok)
         goto out;
+    
+#ifdef HAVE_YAJL_V2
+    status = yajl_complete_parse(yajl_ctx.hand);
+#else
+    status = yajl_parse_complete(yajl_ctx.hand);
+#endif
 
-    status = yajl_parse_complete(yajl_ctx.hand);
     if (status != yajl_status_ok)
         goto out;
 
@@ -834,14 +857,25 @@ static const char *yajl_gen_status_to_st
 char *libxl__object_to_json(libxl_ctx *ctx, const char *type,
                             libxl__gen_json_callback gen, void *p)
 {
+#ifndef HAVE_YAJL_V2
     yajl_gen_config conf = { 1, "    " };
+#endif
     const unsigned char *buf;
     char *ret = NULL;
+#ifdef HAVE_YAJL_V2
+    size_t len = 0;
+#else
     unsigned int len = 0;
+#endif
     yajl_gen_status s;
     yajl_gen hand;
 
+#ifdef HAVE_YAJL_V2
+    hand = yajl_gen_alloc(NULL);
+#else
     hand = yajl_gen_alloc(&conf, NULL);
+#endif
+
     if (!hand)
         return NULL;
 
diff -r f72b99fccfca -r 716d6d48e647 tools/libxl/libxl_json.h
--- a/tools/libxl/libxl_json.h	Tue Dec 20 08:31:40 2011 +0100
+++ b/tools/libxl/libxl_json.h	Tue Dec 20 13:52:55 2011 +0100
@@ -17,7 +17,16 @@
 
 #include <yajl/yajl_gen.h>
 
+#ifdef HAVE_YAJL_VERSION
+#  include <yajl/yajl_version.h>
+#endif
+
 #include <_libxl_types_json.h>
 #include <_libxl_types_internal_json.h>
 
+/* YAJL version check */
+#if defined(YAJL_MAJOR) && (YAJL_MAJOR > 1)
+#  define HAVE_YAJL_V2 1
+#endif
+
 #endif /* LIBXL_JSON_H */
diff -r f72b99fccfca -r 716d6d48e647 tools/libxl/libxl_qmp.c
--- a/tools/libxl/libxl_qmp.c	Tue Dec 20 08:31:40 2011 +0100
+++ b/tools/libxl/libxl_qmp.c	Tue Dec 20 13:52:55 2011 +0100
@@ -453,15 +453,26 @@ static char *qmp_send_prepare(libxl__gc 
                               qmp_callback_t callback, void *opaque,
                               qmp_request_context *context)
 {
+#ifndef HAVE_YAJL_V2
     yajl_gen_config conf = { 0, NULL };
+#endif
     const unsigned char *buf = NULL;
     char *ret = NULL;
+#ifdef HAVE_YAJL_V2
+    size_t len = 0;
+#else
     unsigned int len = 0;
+#endif
     yajl_gen_status s;
     yajl_gen hand;
     callback_id_pair *elm = NULL;
 
+#ifdef HAVE_YAJL_V2
+    hand = yajl_gen_alloc(NULL);
+#else
     hand = yajl_gen_alloc(&conf, NULL);
+#endif
+
     if (!hand) {
         return NULL;
     }

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 22 14:45:09 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 Dec 2011 14:45:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rdjsz-0001DZ-Hl; Thu, 22 Dec 2011 14:44:45 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <bhutchings@solarflare.com>) id 1Rdjsx-0001DU-HO
	for xen-devel@lists.xensource.com; Thu, 22 Dec 2011 14:44:43 +0000
X-Env-Sender: bhutchings@solarflare.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1324565074!6522982!1
X-Originating-IP: [216.237.3.220]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11433 invoked from network); 22 Dec 2011 14:44:36 -0000
Received: from exchange.solarflare.com (HELO ocex02.SolarFlarecom.com)
	(216.237.3.220)
	by server-12.tower-174.messagelabs.com with AES128-SHA encrypted SMTP;
	22 Dec 2011 14:44:36 -0000
Received: from [10.17.20.137] (10.17.20.137) by ocex02.SolarFlarecom.com
	(10.20.40.31) with Microsoft SMTP Server (TLS) id 14.1.355.2;
	Thu, 22 Dec 2011 06:44:32 -0800
From: Ben Hutchings <bhutchings@solarflare.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1324555060.7877.84.camel@zakaz.uk.xensource.com>
References: <4EF3018D020000780006986E@nat28.tlf.novell.com>
	<1324547820.7877.71.camel@zakaz.uk.xensource.com>
	<4EF327E2020000780006993E@nat28.tlf.novell.com>
	<1324555060.7877.84.camel@zakaz.uk.xensource.com>
Organization: Solarflare Communications
Date: Thu, 22 Dec 2011 14:44:27 +0000
Message-ID: <1324565067.2897.2.camel@bwh-desktop>
MIME-Version: 1.0
X-Mailer: Evolution 2.32.2 (2.32.2-1.fc14) 
X-Originating-IP: [10.17.20.137]
X-TM-AS-Product-Ver: SMEX-10.0.0.1412-6.800.1017-18598.006
X-TM-AS-Result: No--22.548800-0.000000-31
X-TM-AS-User-Approved-Sender: Yes
X-TM-AS-User-Blocked-Sender: No
Cc: Jens Axboe <axboe@kernel.dk>, Jeremy Fitzhardinge <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"FlorianSchandinat@gmx.de" <FlorianSchandinat@gmx.de>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"dmitry.torokhov@gmail.com" <dmitry.torokhov@gmail.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Jan Beulich <JBeulich@suse.com>, Konrad Rzeszutek Wilk <konrad@darnok.org>,
	"davem@davemloft.net" <davem@davemloft.net>
Subject: Re: [Xen-devel] [PATCH,
 v2] Xen: consolidate and simplify struct xenbus_driver instantiation
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2011-12-22 at 11:57 +0000, Ian Campbell wrote:
> On Thu, 2011-12-22 at 11:51 +0000, Jan Beulich wrote:
> > >>> On 22.12.11 at 10:57, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > > On Thu, 2011-12-22 at 09:08 +0000, Jan Beulich wrote:
> > >> The 'name', 'owner', and 'mod_name' members are redundant with the
> > >> identically named fields in the 'driver' sub-structure. Rather than
> > >> switching each instance to specify these fields explicitly, introduce
> > >> a macro to simplify this.
> > >> 
> > >> Eliminate further redundancy by allowing the drvname argument to
> > >> DEFINE_XENBUS_DRIVER() to be blank (in which case the first entry from
> > >> the ID table will be used for .driver.name).
> > > 
> > > Any reason not to always use DRV_NAME here (which is generally a bit
> > > more specific e.g. "xen-foofront" rather than "foo") and rely on the id
> > > table for the shorter names used in xenstore?
> > 
> > That would imply that DRV_NAME is always defined, but I don't
> > see this being the case.
> 
> My mistake, I thought it was a Kbuild thing.

You're maybe thinking of KBUILD_MODNAME.

Ben.

-- 
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 22 14:45:09 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 Dec 2011 14:45:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rdjsz-0001DZ-Hl; Thu, 22 Dec 2011 14:44:45 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <bhutchings@solarflare.com>) id 1Rdjsx-0001DU-HO
	for xen-devel@lists.xensource.com; Thu, 22 Dec 2011 14:44:43 +0000
X-Env-Sender: bhutchings@solarflare.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1324565074!6522982!1
X-Originating-IP: [216.237.3.220]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11433 invoked from network); 22 Dec 2011 14:44:36 -0000
Received: from exchange.solarflare.com (HELO ocex02.SolarFlarecom.com)
	(216.237.3.220)
	by server-12.tower-174.messagelabs.com with AES128-SHA encrypted SMTP;
	22 Dec 2011 14:44:36 -0000
Received: from [10.17.20.137] (10.17.20.137) by ocex02.SolarFlarecom.com
	(10.20.40.31) with Microsoft SMTP Server (TLS) id 14.1.355.2;
	Thu, 22 Dec 2011 06:44:32 -0800
From: Ben Hutchings <bhutchings@solarflare.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1324555060.7877.84.camel@zakaz.uk.xensource.com>
References: <4EF3018D020000780006986E@nat28.tlf.novell.com>
	<1324547820.7877.71.camel@zakaz.uk.xensource.com>
	<4EF327E2020000780006993E@nat28.tlf.novell.com>
	<1324555060.7877.84.camel@zakaz.uk.xensource.com>
Organization: Solarflare Communications
Date: Thu, 22 Dec 2011 14:44:27 +0000
Message-ID: <1324565067.2897.2.camel@bwh-desktop>
MIME-Version: 1.0
X-Mailer: Evolution 2.32.2 (2.32.2-1.fc14) 
X-Originating-IP: [10.17.20.137]
X-TM-AS-Product-Ver: SMEX-10.0.0.1412-6.800.1017-18598.006
X-TM-AS-Result: No--22.548800-0.000000-31
X-TM-AS-User-Approved-Sender: Yes
X-TM-AS-User-Blocked-Sender: No
Cc: Jens Axboe <axboe@kernel.dk>, Jeremy Fitzhardinge <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"FlorianSchandinat@gmx.de" <FlorianSchandinat@gmx.de>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"dmitry.torokhov@gmail.com" <dmitry.torokhov@gmail.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Jan Beulich <JBeulich@suse.com>, Konrad Rzeszutek Wilk <konrad@darnok.org>,
	"davem@davemloft.net" <davem@davemloft.net>
Subject: Re: [Xen-devel] [PATCH,
 v2] Xen: consolidate and simplify struct xenbus_driver instantiation
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2011-12-22 at 11:57 +0000, Ian Campbell wrote:
> On Thu, 2011-12-22 at 11:51 +0000, Jan Beulich wrote:
> > >>> On 22.12.11 at 10:57, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > > On Thu, 2011-12-22 at 09:08 +0000, Jan Beulich wrote:
> > >> The 'name', 'owner', and 'mod_name' members are redundant with the
> > >> identically named fields in the 'driver' sub-structure. Rather than
> > >> switching each instance to specify these fields explicitly, introduce
> > >> a macro to simplify this.
> > >> 
> > >> Eliminate further redundancy by allowing the drvname argument to
> > >> DEFINE_XENBUS_DRIVER() to be blank (in which case the first entry from
> > >> the ID table will be used for .driver.name).
> > > 
> > > Any reason not to always use DRV_NAME here (which is generally a bit
> > > more specific e.g. "xen-foofront" rather than "foo") and rely on the id
> > > table for the shorter names used in xenstore?
> > 
> > That would imply that DRV_NAME is always defined, but I don't
> > see this being the case.
> 
> My mistake, I thought it was a Kbuild thing.

You're maybe thinking of KBUILD_MODNAME.

Ben.

-- 
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 22 14:49:04 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 Dec 2011 14:49:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rdjwf-0001MR-EC; Thu, 22 Dec 2011 14:48:33 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Rdjwd-0001MB-Lp
	for xen-devel@lists.xensource.com; Thu, 22 Dec 2011 14:48:31 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1324565305!6573459!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Nzk5NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25103 invoked from network); 22 Dec 2011 14:48:25 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Dec 2011 14:48:25 -0000
X-IronPort-AV: E=Sophos;i="4.71,393,1320624000"; 
   d="scan'208";a="9636325"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Dec 2011 14:48:25 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 22 Dec 2011 14:48:25 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RdjwX-0002bY-6W; Thu, 22 Dec 2011 14:48:25 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RdjwX-0005fI-4m;
	Thu, 22 Dec 2011 14:48:25 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20211.17204.506028.810982@mariner.uk.xensource.com>
Date: Thu, 22 Dec 2011 14:48:20 +0000
To: Jan Beulich <JBeulich@suse.com>
In-Reply-To: <4EDE367D0200007800065B6B@nat28.tlf.novell.com>
References: <CAFQ2Z+fpR1UkxFEAYTD6irBUBeA3c7eJ3x1bXE0jzpdfQtH64w@mail.gmail.com>
	<alpine.DEB.2.00.1112021223190.31179@kaball-desktop>
	<4EDE367D0200007800065B6B@nat28.tlf.novell.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Haitao Shan <maillists.shan@gmail.com>, "Keir \(Xen.org\)" <keir@xen.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Haitao Shan <haitao.shan@intel.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] Qemu MSI Cleaning Up
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Jan Beulich writes ("Re: [Xen-devel] [PATCH] Qemu MSI Cleaning Up"):
> qemu: clean up MSI-X table handling

Applied, thanks all.  Sorry for the delay.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 22 14:49:04 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 Dec 2011 14:49:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rdjwf-0001MR-EC; Thu, 22 Dec 2011 14:48:33 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Rdjwd-0001MB-Lp
	for xen-devel@lists.xensource.com; Thu, 22 Dec 2011 14:48:31 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1324565305!6573459!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Nzk5NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25103 invoked from network); 22 Dec 2011 14:48:25 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Dec 2011 14:48:25 -0000
X-IronPort-AV: E=Sophos;i="4.71,393,1320624000"; 
   d="scan'208";a="9636325"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Dec 2011 14:48:25 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 22 Dec 2011 14:48:25 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RdjwX-0002bY-6W; Thu, 22 Dec 2011 14:48:25 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RdjwX-0005fI-4m;
	Thu, 22 Dec 2011 14:48:25 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20211.17204.506028.810982@mariner.uk.xensource.com>
Date: Thu, 22 Dec 2011 14:48:20 +0000
To: Jan Beulich <JBeulich@suse.com>
In-Reply-To: <4EDE367D0200007800065B6B@nat28.tlf.novell.com>
References: <CAFQ2Z+fpR1UkxFEAYTD6irBUBeA3c7eJ3x1bXE0jzpdfQtH64w@mail.gmail.com>
	<alpine.DEB.2.00.1112021223190.31179@kaball-desktop>
	<4EDE367D0200007800065B6B@nat28.tlf.novell.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Haitao Shan <maillists.shan@gmail.com>, "Keir \(Xen.org\)" <keir@xen.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Haitao Shan <haitao.shan@intel.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] Qemu MSI Cleaning Up
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Jan Beulich writes ("Re: [Xen-devel] [PATCH] Qemu MSI Cleaning Up"):
> qemu: clean up MSI-X table handling

Applied, thanks all.  Sorry for the delay.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 22 15:24:48 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 Dec 2011 15:24:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdkVC-000270-EO; Thu, 22 Dec 2011 15:24:14 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RdkVA-00026s-Km
	for xen-devel@lists.xensource.com; Thu, 22 Dec 2011 15:24:12 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1324567446!8475063!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Nzk5NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19251 invoked from network); 22 Dec 2011 15:24:06 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Dec 2011 15:24:06 -0000
X-IronPort-AV: E=Sophos;i="4.71,393,1320624000"; 
   d="scan'208";a="9637338"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Dec 2011 15:24:06 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 22 Dec 2011 15:24:05 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RdkV3-0002nk-MO;
	Thu, 22 Dec 2011 15:24:05 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RdkV3-0006as-Fe;
	Thu, 22 Dec 2011 15:24:05 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10596-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 22 Dec 2011 15:24:05 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10596: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10596 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10596/

Regressions :-(

Tests which did not succeed and are blocking,including tests which could not be run:
 test-amd64-amd64-xl-win7-amd64  7 windows-install         fail REGR. vs. 10564
 test-i386-i386-pv            19 capture-logs(19)             broken   in 10591

Tests which are failing intermittently (not blocking):
 test-amd64-i386-rhel6hvm-intel  7 redhat-install            fail pass in 10591
 test-amd64-i386-pv           16 guest-start.2               fail pass in 10571
 test-amd64-amd64-xl-sedf-pin 16 guest-start.2               fail pass in 10591
 test-amd64-i386-rhel6hvm-amd  7 redhat-install              fail pass in 10591
 test-amd64-i386-xl-win7-amd64  7 windows-install            fail pass in 10571
 test-amd64-amd64-xl-sedf     13 guest-localmigrate.2        fail pass in 10585
 test-i386-i386-xl-winxpsp3    7 windows-install             fail pass in 10591
 test-amd64-amd64-pv          16 guest-start.2      fail in 10591 pass in 10596
 test-amd64-amd64-xl          16 guest-start.2      fail in 10591 pass in 10596
 test-amd64-amd64-xl-sedf      7 debian-install     fail in 10591 pass in 10596
 test-amd64-i386-win-vcpus1    7 windows-install    fail in 10591 pass in 10596
 test-amd64-i386-xl-credit2    7 debian-install     fail in 10571 pass in 10596
 test-i386-i386-pv            16 guest-start.2      fail in 10571 pass in 10596
 test-i386-i386-xl            16 guest-start.2      fail in 10571 pass in 10596
 test-amd64-i386-xl-multivcpu 16 guest-start.2      fail in 10585 pass in 10596
 test-amd64-i386-xl           16 guest-start.2      fail in 10585 pass in 10596
 test-amd64-i386-xl-credit2   16 guest-start.2      fail in 10585 pass in 10596
 test-i386-i386-win            7 windows-install    fail in 10585 pass in 10596
 test-amd64-i386-xl-winxpsp3-vcpus1 7 windows-install fail in 10585 pass in 10596

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2       fail in 10591 never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2         fail in 10591 never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop            fail in 10591 never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop           fail in 10571 never pass
 test-amd64-amd64-xl-sedf    14 guest-localmigrate/x10 fail in 10585 like 10563

version targeted for testing:
 xen                  492914c65838
baseline version:
 xen                  e56500f95b6a

------------------------------------------------------------
People who touched revisions under test:
  Anthony PERARD <anthony.perard@citrix.com>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           fail    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   24445:492914c65838
tag:         tip
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Wed Dec 21 10:47:30 2011 +0000
    
    libxl: report failure to reboot/shutdown due to lackof PV interfaces to caller
    
    This allow the caller to react as they think is appropriate. xl now prints a
    message much like the library did previously, although hopefully somewhat more
    informative.
    
    Update the xl(1) man page to be similarly more informative.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Committed-by: Ian Jackson <ian.jackson.citrix.com>
    Acked-by: Ian Jackson <ian.jackson.citrix.com>
    
    
changeset:   24444:1c3f9cac204e
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Wed Dec 21 10:47:11 2011 +0000
    
    libxl: split libxl_domain_shutdown into libxl_domain_shutdown,..._reboot
    
    The other integer request types which shutdown supported are not
    useful. Specifically:
    
     * "suspend" is not usable via this interface since it requires other
       scaffolding, libxl_domain_suspend provides this already.
     * "halt" is the same as "poweroff".
     * "crash" is unused and at least Linux does not implement it. If a user
       steps forward then libxl_domain_crash is trivial to add.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Committed-by: Ian Jackson <ian.jackson.citrix.com>
    Acked-by: Ian Jackson <ian.jackson.citrix.com>
    
    
changeset:   24443:b3455a4d2298
user:        Anthony PERARD <anthony.perard@citrix.com>
date:        Wed Dec 21 14:47:26 2011 +0000
    
    libxl: Fix, specify open mode to QEMU state file.
    
    Reported-by: Olaf Hering <olaf@aepfle.de>
    Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24442:16dc2a1cd40f
user:        Jan Beulich <jbeulich@suse.com>
date:        Wed Dec 21 14:26:09 2011 +0100
    
    x86: reduce scope of some symbols used with reset_stack_and_jump()
    
    By making the macro properly advertise the use of the input symbol to
    the compiler, it is no longer necessary for them to be global if
    they're defined and used in just one source file.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24441:73ab77073140
user:        Jan Beulich <jbeulich@suse.com>
date:        Wed Dec 21 09:20:15 2011 +0100
    
    x86: move some function scope statics into .init.data
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24440:e56500f95b6a
user:        Daniel De Graaf <dgdegra@tycho.nsa.gov>
date:        Tue Dec 20 18:19:53 2011 +0000
    
    flask/policy: Update example policy
    
    Rewrite the example policy to make it easier to understand and
    demonstrate some of the security goals that FLASK can enforce.
    
    Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
    Committed-by: Ian Jackson <ian.jackson.citrix.com>
    
    
========================================
commit 54e24021005458ad0a361c1d83011b751726a94b
Author: Ian Jackson <ian.jackson@eu.citrix.com>
Date:   Thu Dec 8 16:38:06 2011 +0000

    qemu_get_timer: Provide a comment about the behaviour on ts==NULL
    
    Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 22 15:24:48 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 Dec 2011 15:24:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdkVC-000270-EO; Thu, 22 Dec 2011 15:24:14 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RdkVA-00026s-Km
	for xen-devel@lists.xensource.com; Thu, 22 Dec 2011 15:24:12 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1324567446!8475063!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Nzk5NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19251 invoked from network); 22 Dec 2011 15:24:06 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Dec 2011 15:24:06 -0000
X-IronPort-AV: E=Sophos;i="4.71,393,1320624000"; 
   d="scan'208";a="9637338"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Dec 2011 15:24:06 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 22 Dec 2011 15:24:05 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RdkV3-0002nk-MO;
	Thu, 22 Dec 2011 15:24:05 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RdkV3-0006as-Fe;
	Thu, 22 Dec 2011 15:24:05 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10596-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 22 Dec 2011 15:24:05 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10596: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10596 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10596/

Regressions :-(

Tests which did not succeed and are blocking,including tests which could not be run:
 test-amd64-amd64-xl-win7-amd64  7 windows-install         fail REGR. vs. 10564
 test-i386-i386-pv            19 capture-logs(19)             broken   in 10591

Tests which are failing intermittently (not blocking):
 test-amd64-i386-rhel6hvm-intel  7 redhat-install            fail pass in 10591
 test-amd64-i386-pv           16 guest-start.2               fail pass in 10571
 test-amd64-amd64-xl-sedf-pin 16 guest-start.2               fail pass in 10591
 test-amd64-i386-rhel6hvm-amd  7 redhat-install              fail pass in 10591
 test-amd64-i386-xl-win7-amd64  7 windows-install            fail pass in 10571
 test-amd64-amd64-xl-sedf     13 guest-localmigrate.2        fail pass in 10585
 test-i386-i386-xl-winxpsp3    7 windows-install             fail pass in 10591
 test-amd64-amd64-pv          16 guest-start.2      fail in 10591 pass in 10596
 test-amd64-amd64-xl          16 guest-start.2      fail in 10591 pass in 10596
 test-amd64-amd64-xl-sedf      7 debian-install     fail in 10591 pass in 10596
 test-amd64-i386-win-vcpus1    7 windows-install    fail in 10591 pass in 10596
 test-amd64-i386-xl-credit2    7 debian-install     fail in 10571 pass in 10596
 test-i386-i386-pv            16 guest-start.2      fail in 10571 pass in 10596
 test-i386-i386-xl            16 guest-start.2      fail in 10571 pass in 10596
 test-amd64-i386-xl-multivcpu 16 guest-start.2      fail in 10585 pass in 10596
 test-amd64-i386-xl           16 guest-start.2      fail in 10585 pass in 10596
 test-amd64-i386-xl-credit2   16 guest-start.2      fail in 10585 pass in 10596
 test-i386-i386-win            7 windows-install    fail in 10585 pass in 10596
 test-amd64-i386-xl-winxpsp3-vcpus1 7 windows-install fail in 10585 pass in 10596

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2       fail in 10591 never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2         fail in 10591 never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop            fail in 10591 never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop           fail in 10571 never pass
 test-amd64-amd64-xl-sedf    14 guest-localmigrate/x10 fail in 10585 like 10563

version targeted for testing:
 xen                  492914c65838
baseline version:
 xen                  e56500f95b6a

------------------------------------------------------------
People who touched revisions under test:
  Anthony PERARD <anthony.perard@citrix.com>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           fail    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   24445:492914c65838
tag:         tip
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Wed Dec 21 10:47:30 2011 +0000
    
    libxl: report failure to reboot/shutdown due to lackof PV interfaces to caller
    
    This allow the caller to react as they think is appropriate. xl now prints a
    message much like the library did previously, although hopefully somewhat more
    informative.
    
    Update the xl(1) man page to be similarly more informative.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Committed-by: Ian Jackson <ian.jackson.citrix.com>
    Acked-by: Ian Jackson <ian.jackson.citrix.com>
    
    
changeset:   24444:1c3f9cac204e
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Wed Dec 21 10:47:11 2011 +0000
    
    libxl: split libxl_domain_shutdown into libxl_domain_shutdown,..._reboot
    
    The other integer request types which shutdown supported are not
    useful. Specifically:
    
     * "suspend" is not usable via this interface since it requires other
       scaffolding, libxl_domain_suspend provides this already.
     * "halt" is the same as "poweroff".
     * "crash" is unused and at least Linux does not implement it. If a user
       steps forward then libxl_domain_crash is trivial to add.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Committed-by: Ian Jackson <ian.jackson.citrix.com>
    Acked-by: Ian Jackson <ian.jackson.citrix.com>
    
    
changeset:   24443:b3455a4d2298
user:        Anthony PERARD <anthony.perard@citrix.com>
date:        Wed Dec 21 14:47:26 2011 +0000
    
    libxl: Fix, specify open mode to QEMU state file.
    
    Reported-by: Olaf Hering <olaf@aepfle.de>
    Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24442:16dc2a1cd40f
user:        Jan Beulich <jbeulich@suse.com>
date:        Wed Dec 21 14:26:09 2011 +0100
    
    x86: reduce scope of some symbols used with reset_stack_and_jump()
    
    By making the macro properly advertise the use of the input symbol to
    the compiler, it is no longer necessary for them to be global if
    they're defined and used in just one source file.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24441:73ab77073140
user:        Jan Beulich <jbeulich@suse.com>
date:        Wed Dec 21 09:20:15 2011 +0100
    
    x86: move some function scope statics into .init.data
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24440:e56500f95b6a
user:        Daniel De Graaf <dgdegra@tycho.nsa.gov>
date:        Tue Dec 20 18:19:53 2011 +0000
    
    flask/policy: Update example policy
    
    Rewrite the example policy to make it easier to understand and
    demonstrate some of the security goals that FLASK can enforce.
    
    Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
    Committed-by: Ian Jackson <ian.jackson.citrix.com>
    
    
========================================
commit 54e24021005458ad0a361c1d83011b751726a94b
Author: Ian Jackson <ian.jackson@eu.citrix.com>
Date:   Thu Dec 8 16:38:06 2011 +0000

    qemu_get_timer: Provide a comment about the behaviour on ts==NULL
    
    Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 22 15:28:37 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 Dec 2011 15:28:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdkZ4-0002EN-3h; Thu, 22 Dec 2011 15:28:14 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RdkZ2-0002EA-3N
	for xen-devel@lists.xensource.com; Thu, 22 Dec 2011 15:28:12 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1324567668!50351588!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Nzk5NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17833 invoked from network); 22 Dec 2011 15:27:48 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Dec 2011 15:27:48 -0000
X-IronPort-AV: E=Sophos;i="4.71,393,1320624000"; 
   d="scan'208";a="9637439"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Dec 2011 15:28:07 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 22 Dec 2011 15:28:07 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau Monne <roger.pau@entel.upc.edu>
Date: Thu, 22 Dec 2011 15:28:07 +0000
In-Reply-To: <716d6d48e647d1d4352f.1324385606@alpine.localdomain>
References: <716d6d48e647d1d4352f.1324385606@alpine.localdomain>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1324567687.7877.91.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH v2] libxl: add support for yajl 2.x
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2011-12-20 at 12:53 +0000, Roger Pau Monne wrote:
> # HG changeset patch
> # User Roger Pau Monne <roger.pau@entel.upc.edu>
> # Date 1324385575 -3600
> # Node ID 716d6d48e647d1d4352f7206e74e693152a4f8fa
> # Parent  f72b99fccfca694674259cc1c03c526a827b67ec
> libxl: add support for yajl 2.x
> 
> This patch adds support for yajl versions 2.x, while retaining 1.x
> compatibility. This patch adds quite a lot of #ifdefs all over the
> json code, so I'm open to suggestions if there's a better way to
> handle this.
> 
> Tested with yajl 2.0.3 and 1.0.12.
> 
> Changes since v1:
> 
>  * Check if yajl_version.h is present before trying to include it.
> 
> Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>
> 
> diff -r f72b99fccfca -r 716d6d48e647 Config.mk
> --- a/Config.mk	Tue Dec 20 08:31:40 2011 +0100
> +++ b/Config.mk	Tue Dec 20 13:52:55 2011 +0100
> @@ -186,6 +186,11 @@ CONFIG_LIBICONV   := $(shell export OS="
>                         . $(XEN_ROOT)/tools/check/funcs.sh; \
>                         has_lib libiconv.so && echo 'y' || echo 'n')
>  
> +CONFIG_YAJL_VERSION := $(shell export OS="`uname -s`"; \
> +                       export CHECK_INCLUDES="$(CHECK_INCLUDES)"; \
> +                       . $(XEN_ROOT)/tools/check/funcs.sh; \
> +                       has_header yajl/yajl_version.h && echo 'y' || echo 'n')

We've ended up with a few of this sort of thing recently. I wonder if it
is time to have a configuration/check phase which generates a config.h?

Ian.

>  # Enable XSM security module (by default, Flask).
>  XSM_ENABLE ?= n
>  FLASK_ENABLE ?= $(XSM_ENABLE)
> diff -r f72b99fccfca -r 716d6d48e647 tools/check/check_yajl_lib
> --- a/tools/check/check_yajl_lib	Tue Dec 20 08:31:40 2011 +0100
> +++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
> @@ -1,6 +0,0 @@
> -#!/bin/sh
> -# CHECK-BUILD CHECK-INSTALL
> -
> -. ./funcs.sh
> -
> -has_lib libyajl.so.1 || fail "can't find libyajl.so.1 version 1"
> diff -r f72b99fccfca -r 716d6d48e647 tools/libxl/Makefile
> --- a/tools/libxl/Makefile	Tue Dec 20 08:31:40 2011 +0100
> +++ b/tools/libxl/Makefile	Tue Dec 20 13:52:55 2011 +0100
> @@ -19,6 +19,10 @@ ifeq ($(CONFIG_Linux),y)
>  LIBUUID_LIBS += -luuid
>  endif
>  
> +ifeq ($(CONFIG_YAJL_VERSION),y)
> +CFLAGS += -DHAVE_YAJL_VERSION
> +endif
> +
>  LIBXL_LIBS =
>  LIBXL_LIBS = $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) $(LDLIBS_libxenstore) $(LDLIBS_libblktapctl) $(UTIL_LIBS) $(LIBUUID_LIBS)
>  
> diff -r f72b99fccfca -r 716d6d48e647 tools/libxl/libxl_json.c
> --- a/tools/libxl/libxl_json.c	Tue Dec 20 08:31:40 2011 +0100
> +++ b/tools/libxl/libxl_json.c	Tue Dec 20 13:52:55 2011 +0100
> @@ -519,7 +519,11 @@ static bool is_decimal(const char *s, un
>      return false;
>  }
>  
> +#ifdef HAVE_YAJL_V2
> +static int json_callback_number(void *opaque, const char *s, size_t len)
> +#else
>  static int json_callback_number(void *opaque, const char *s, unsigned int len)
> +#endif
>  {
>      libxl__yajl_ctx *ctx = opaque;
>      libxl__json_object *obj = NULL;
> @@ -575,8 +579,13 @@ out:
>      return 1;
>  }
>  
> +#ifdef HAVE_YAJL_V2
> +static int json_callback_string(void *opaque, const unsigned char *str,
> +                                size_t len)
> +#else
>  static int json_callback_string(void *opaque, const unsigned char *str,
>                                  unsigned int len)
> +#endif
>  {
>      libxl__yajl_ctx *ctx = opaque;
>      char *t = NULL;
> @@ -608,8 +617,13 @@ static int json_callback_string(void *op
>      return 1;
>  }
>  
> +#ifdef HAVE_YAJL_V2
> +static int json_callback_map_key(void *opaque, const unsigned char *str,
> +                                 size_t len)
> +#else
>  static int json_callback_map_key(void *opaque, const unsigned char *str,
>                                   unsigned int len)
> +#endif
>  {
>      libxl__yajl_ctx *ctx = opaque;
>      char *t = NULL;
> @@ -772,17 +786,26 @@ libxl__json_object *libxl__json_parse(li
>      DEBUG_GEN_ALLOC(&yajl_ctx);
>  
>      if (yajl_ctx.hand == NULL) {
> +#ifdef HAVE_YAJL_V2
> +        yajl_ctx.hand = yajl_alloc(&callbacks, NULL, &yajl_ctx);
> +#else
>          yajl_parser_config cfg = {
>              .allowComments = 1,
>              .checkUTF8 = 1,
>          };
>          yajl_ctx.hand = yajl_alloc(&callbacks, &cfg, NULL, &yajl_ctx);
> +#endif
>      }
>      status = yajl_parse(yajl_ctx.hand, (const unsigned char *)s, strlen(s));
>      if (status != yajl_status_ok)
>          goto out;
> +    
> +#ifdef HAVE_YAJL_V2
> +    status = yajl_complete_parse(yajl_ctx.hand);
> +#else
> +    status = yajl_parse_complete(yajl_ctx.hand);
> +#endif
>  
> -    status = yajl_parse_complete(yajl_ctx.hand);
>      if (status != yajl_status_ok)
>          goto out;
>  
> @@ -834,14 +857,25 @@ static const char *yajl_gen_status_to_st
>  char *libxl__object_to_json(libxl_ctx *ctx, const char *type,
>                              libxl__gen_json_callback gen, void *p)
>  {
> +#ifndef HAVE_YAJL_V2
>      yajl_gen_config conf = { 1, "    " };
> +#endif
>      const unsigned char *buf;
>      char *ret = NULL;
> +#ifdef HAVE_YAJL_V2
> +    size_t len = 0;
> +#else
>      unsigned int len = 0;
> +#endif
>      yajl_gen_status s;
>      yajl_gen hand;
>  
> +#ifdef HAVE_YAJL_V2
> +    hand = yajl_gen_alloc(NULL);
> +#else
>      hand = yajl_gen_alloc(&conf, NULL);
> +#endif
> +
>      if (!hand)
>          return NULL;
>  
> diff -r f72b99fccfca -r 716d6d48e647 tools/libxl/libxl_json.h
> --- a/tools/libxl/libxl_json.h	Tue Dec 20 08:31:40 2011 +0100
> +++ b/tools/libxl/libxl_json.h	Tue Dec 20 13:52:55 2011 +0100
> @@ -17,7 +17,16 @@
>  
>  #include <yajl/yajl_gen.h>
>  
> +#ifdef HAVE_YAJL_VERSION
> +#  include <yajl/yajl_version.h>
> +#endif
> +
>  #include <_libxl_types_json.h>
>  #include <_libxl_types_internal_json.h>
>  
> +/* YAJL version check */
> +#if defined(YAJL_MAJOR) && (YAJL_MAJOR > 1)
> +#  define HAVE_YAJL_V2 1
> +#endif
> +
>  #endif /* LIBXL_JSON_H */
> diff -r f72b99fccfca -r 716d6d48e647 tools/libxl/libxl_qmp.c
> --- a/tools/libxl/libxl_qmp.c	Tue Dec 20 08:31:40 2011 +0100
> +++ b/tools/libxl/libxl_qmp.c	Tue Dec 20 13:52:55 2011 +0100
> @@ -453,15 +453,26 @@ static char *qmp_send_prepare(libxl__gc 
>                                qmp_callback_t callback, void *opaque,
>                                qmp_request_context *context)
>  {
> +#ifndef HAVE_YAJL_V2
>      yajl_gen_config conf = { 0, NULL };
> +#endif
>      const unsigned char *buf = NULL;
>      char *ret = NULL;
> +#ifdef HAVE_YAJL_V2
> +    size_t len = 0;
> +#else
>      unsigned int len = 0;
> +#endif
>      yajl_gen_status s;
>      yajl_gen hand;
>      callback_id_pair *elm = NULL;
>  
> +#ifdef HAVE_YAJL_V2
> +    hand = yajl_gen_alloc(NULL);
> +#else
>      hand = yajl_gen_alloc(&conf, NULL);
> +#endif
> +
>      if (!hand) {
>          return NULL;
>      }



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 22 15:28:37 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 Dec 2011 15:28:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdkZ4-0002EN-3h; Thu, 22 Dec 2011 15:28:14 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RdkZ2-0002EA-3N
	for xen-devel@lists.xensource.com; Thu, 22 Dec 2011 15:28:12 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1324567668!50351588!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Nzk5NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17833 invoked from network); 22 Dec 2011 15:27:48 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Dec 2011 15:27:48 -0000
X-IronPort-AV: E=Sophos;i="4.71,393,1320624000"; 
   d="scan'208";a="9637439"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Dec 2011 15:28:07 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 22 Dec 2011 15:28:07 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau Monne <roger.pau@entel.upc.edu>
Date: Thu, 22 Dec 2011 15:28:07 +0000
In-Reply-To: <716d6d48e647d1d4352f.1324385606@alpine.localdomain>
References: <716d6d48e647d1d4352f.1324385606@alpine.localdomain>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1324567687.7877.91.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH v2] libxl: add support for yajl 2.x
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2011-12-20 at 12:53 +0000, Roger Pau Monne wrote:
> # HG changeset patch
> # User Roger Pau Monne <roger.pau@entel.upc.edu>
> # Date 1324385575 -3600
> # Node ID 716d6d48e647d1d4352f7206e74e693152a4f8fa
> # Parent  f72b99fccfca694674259cc1c03c526a827b67ec
> libxl: add support for yajl 2.x
> 
> This patch adds support for yajl versions 2.x, while retaining 1.x
> compatibility. This patch adds quite a lot of #ifdefs all over the
> json code, so I'm open to suggestions if there's a better way to
> handle this.
> 
> Tested with yajl 2.0.3 and 1.0.12.
> 
> Changes since v1:
> 
>  * Check if yajl_version.h is present before trying to include it.
> 
> Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>
> 
> diff -r f72b99fccfca -r 716d6d48e647 Config.mk
> --- a/Config.mk	Tue Dec 20 08:31:40 2011 +0100
> +++ b/Config.mk	Tue Dec 20 13:52:55 2011 +0100
> @@ -186,6 +186,11 @@ CONFIG_LIBICONV   := $(shell export OS="
>                         . $(XEN_ROOT)/tools/check/funcs.sh; \
>                         has_lib libiconv.so && echo 'y' || echo 'n')
>  
> +CONFIG_YAJL_VERSION := $(shell export OS="`uname -s`"; \
> +                       export CHECK_INCLUDES="$(CHECK_INCLUDES)"; \
> +                       . $(XEN_ROOT)/tools/check/funcs.sh; \
> +                       has_header yajl/yajl_version.h && echo 'y' || echo 'n')

We've ended up with a few of this sort of thing recently. I wonder if it
is time to have a configuration/check phase which generates a config.h?

Ian.

>  # Enable XSM security module (by default, Flask).
>  XSM_ENABLE ?= n
>  FLASK_ENABLE ?= $(XSM_ENABLE)
> diff -r f72b99fccfca -r 716d6d48e647 tools/check/check_yajl_lib
> --- a/tools/check/check_yajl_lib	Tue Dec 20 08:31:40 2011 +0100
> +++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
> @@ -1,6 +0,0 @@
> -#!/bin/sh
> -# CHECK-BUILD CHECK-INSTALL
> -
> -. ./funcs.sh
> -
> -has_lib libyajl.so.1 || fail "can't find libyajl.so.1 version 1"
> diff -r f72b99fccfca -r 716d6d48e647 tools/libxl/Makefile
> --- a/tools/libxl/Makefile	Tue Dec 20 08:31:40 2011 +0100
> +++ b/tools/libxl/Makefile	Tue Dec 20 13:52:55 2011 +0100
> @@ -19,6 +19,10 @@ ifeq ($(CONFIG_Linux),y)
>  LIBUUID_LIBS += -luuid
>  endif
>  
> +ifeq ($(CONFIG_YAJL_VERSION),y)
> +CFLAGS += -DHAVE_YAJL_VERSION
> +endif
> +
>  LIBXL_LIBS =
>  LIBXL_LIBS = $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) $(LDLIBS_libxenstore) $(LDLIBS_libblktapctl) $(UTIL_LIBS) $(LIBUUID_LIBS)
>  
> diff -r f72b99fccfca -r 716d6d48e647 tools/libxl/libxl_json.c
> --- a/tools/libxl/libxl_json.c	Tue Dec 20 08:31:40 2011 +0100
> +++ b/tools/libxl/libxl_json.c	Tue Dec 20 13:52:55 2011 +0100
> @@ -519,7 +519,11 @@ static bool is_decimal(const char *s, un
>      return false;
>  }
>  
> +#ifdef HAVE_YAJL_V2
> +static int json_callback_number(void *opaque, const char *s, size_t len)
> +#else
>  static int json_callback_number(void *opaque, const char *s, unsigned int len)
> +#endif
>  {
>      libxl__yajl_ctx *ctx = opaque;
>      libxl__json_object *obj = NULL;
> @@ -575,8 +579,13 @@ out:
>      return 1;
>  }
>  
> +#ifdef HAVE_YAJL_V2
> +static int json_callback_string(void *opaque, const unsigned char *str,
> +                                size_t len)
> +#else
>  static int json_callback_string(void *opaque, const unsigned char *str,
>                                  unsigned int len)
> +#endif
>  {
>      libxl__yajl_ctx *ctx = opaque;
>      char *t = NULL;
> @@ -608,8 +617,13 @@ static int json_callback_string(void *op
>      return 1;
>  }
>  
> +#ifdef HAVE_YAJL_V2
> +static int json_callback_map_key(void *opaque, const unsigned char *str,
> +                                 size_t len)
> +#else
>  static int json_callback_map_key(void *opaque, const unsigned char *str,
>                                   unsigned int len)
> +#endif
>  {
>      libxl__yajl_ctx *ctx = opaque;
>      char *t = NULL;
> @@ -772,17 +786,26 @@ libxl__json_object *libxl__json_parse(li
>      DEBUG_GEN_ALLOC(&yajl_ctx);
>  
>      if (yajl_ctx.hand == NULL) {
> +#ifdef HAVE_YAJL_V2
> +        yajl_ctx.hand = yajl_alloc(&callbacks, NULL, &yajl_ctx);
> +#else
>          yajl_parser_config cfg = {
>              .allowComments = 1,
>              .checkUTF8 = 1,
>          };
>          yajl_ctx.hand = yajl_alloc(&callbacks, &cfg, NULL, &yajl_ctx);
> +#endif
>      }
>      status = yajl_parse(yajl_ctx.hand, (const unsigned char *)s, strlen(s));
>      if (status != yajl_status_ok)
>          goto out;
> +    
> +#ifdef HAVE_YAJL_V2
> +    status = yajl_complete_parse(yajl_ctx.hand);
> +#else
> +    status = yajl_parse_complete(yajl_ctx.hand);
> +#endif
>  
> -    status = yajl_parse_complete(yajl_ctx.hand);
>      if (status != yajl_status_ok)
>          goto out;
>  
> @@ -834,14 +857,25 @@ static const char *yajl_gen_status_to_st
>  char *libxl__object_to_json(libxl_ctx *ctx, const char *type,
>                              libxl__gen_json_callback gen, void *p)
>  {
> +#ifndef HAVE_YAJL_V2
>      yajl_gen_config conf = { 1, "    " };
> +#endif
>      const unsigned char *buf;
>      char *ret = NULL;
> +#ifdef HAVE_YAJL_V2
> +    size_t len = 0;
> +#else
>      unsigned int len = 0;
> +#endif
>      yajl_gen_status s;
>      yajl_gen hand;
>  
> +#ifdef HAVE_YAJL_V2
> +    hand = yajl_gen_alloc(NULL);
> +#else
>      hand = yajl_gen_alloc(&conf, NULL);
> +#endif
> +
>      if (!hand)
>          return NULL;
>  
> diff -r f72b99fccfca -r 716d6d48e647 tools/libxl/libxl_json.h
> --- a/tools/libxl/libxl_json.h	Tue Dec 20 08:31:40 2011 +0100
> +++ b/tools/libxl/libxl_json.h	Tue Dec 20 13:52:55 2011 +0100
> @@ -17,7 +17,16 @@
>  
>  #include <yajl/yajl_gen.h>
>  
> +#ifdef HAVE_YAJL_VERSION
> +#  include <yajl/yajl_version.h>
> +#endif
> +
>  #include <_libxl_types_json.h>
>  #include <_libxl_types_internal_json.h>
>  
> +/* YAJL version check */
> +#if defined(YAJL_MAJOR) && (YAJL_MAJOR > 1)
> +#  define HAVE_YAJL_V2 1
> +#endif
> +
>  #endif /* LIBXL_JSON_H */
> diff -r f72b99fccfca -r 716d6d48e647 tools/libxl/libxl_qmp.c
> --- a/tools/libxl/libxl_qmp.c	Tue Dec 20 08:31:40 2011 +0100
> +++ b/tools/libxl/libxl_qmp.c	Tue Dec 20 13:52:55 2011 +0100
> @@ -453,15 +453,26 @@ static char *qmp_send_prepare(libxl__gc 
>                                qmp_callback_t callback, void *opaque,
>                                qmp_request_context *context)
>  {
> +#ifndef HAVE_YAJL_V2
>      yajl_gen_config conf = { 0, NULL };
> +#endif
>      const unsigned char *buf = NULL;
>      char *ret = NULL;
> +#ifdef HAVE_YAJL_V2
> +    size_t len = 0;
> +#else
>      unsigned int len = 0;
> +#endif
>      yajl_gen_status s;
>      yajl_gen hand;
>      callback_id_pair *elm = NULL;
>  
> +#ifdef HAVE_YAJL_V2
> +    hand = yajl_gen_alloc(NULL);
> +#else
>      hand = yajl_gen_alloc(&conf, NULL);
> +#endif
> +
>      if (!hand) {
>          return NULL;
>      }



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 22 15:49:07 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 Dec 2011 15:49:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rdksp-0002qO-LI; Thu, 22 Dec 2011 15:48:39 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1Rdksn-0002qJ-Ox
	for xen-devel@lists.xensource.com; Thu, 22 Dec 2011 15:48:37 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1324568857!61799834!1
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28618 invoked from network); 22 Dec 2011 15:47:37 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Dec 2011 15:47:37 -0000
Received: by werg1 with SMTP id g1so9080167wer.30
	for <xen-devel@lists.xensource.com>;
	Thu, 22 Dec 2011 07:48:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=0K3P3ASLfxX4UDK9vb6t/c1lISyy0WCqgRYSqO85eI8=;
	b=gY4rj944CV8C+5vDmKGzyXyHHFtuse5PPsKk5mceDZ4imdFIwXgzKLRchcnMuygKuf
	hU26Ihc0P9JyZcnWzb6o8sB/OOpHRP216Ol+xWIujNYjs6TZO19x3h/o0S5mtUs3kQIb
	XDgjdNDvbPwjmkCO0hWGMOaULL8ij+eqyxyC4=
Received: by 10.216.139.222 with SMTP id c72mr12004554wej.4.1324568913414;
	Thu, 22 Dec 2011 07:48:33 -0800 (PST)
Received: from [192.168.1.3] (host81-152-17-11.range81-152.btcentralplus.com.
	[81.152.17.11])
	by mx.google.com with ESMTPS id w8sm23534381wiz.4.2011.12.22.07.48.31
	(version=SSLv3 cipher=OTHER); Thu, 22 Dec 2011 07:48:32 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Thu, 22 Dec 2011 15:48:29 +0000
From: Keir Fraser <keir@xen.org>
To: Ian Campbell <Ian.Campbell@citrix.com>,
	Roger Pau Monne <roger.pau@entel.upc.edu>
Message-ID: <CB1901CD.36815%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH v2] libxl: add support for yajl 2.x
Thread-Index: AczAwSZCQR2TmZMkb0GOI2s/l/IMnw==
In-Reply-To: <1324567687.7877.91.camel@zakaz.uk.xensource.com>
Mime-version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH v2] libxl: add support for yajl 2.x
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 22/12/2011 15:28, "Ian Campbell" <Ian.Campbell@citrix.com> wrote:

>> diff -r f72b99fccfca -r 716d6d48e647 Config.mk
>> --- a/Config.mk Tue Dec 20 08:31:40 2011 +0100
>> +++ b/Config.mk Tue Dec 20 13:52:55 2011 +0100
>> @@ -186,6 +186,11 @@ CONFIG_LIBICONV   := $(shell export OS="
>>                         . $(XEN_ROOT)/tools/check/funcs.sh; \
>>                         has_lib libiconv.so && echo 'y' || echo 'n')
>>  
>> +CONFIG_YAJL_VERSION := $(shell export OS="`uname -s`"; \
>> +                       export CHECK_INCLUDES="$(CHECK_INCLUDES)"; \
>> +                       . $(XEN_ROOT)/tools/check/funcs.sh; \
>> +                       has_header yajl/yajl_version.h && echo 'y' || echo
>> 'n')
> 
> We've ended up with a few of this sort of thing recently. I wonder if it
> is time to have a configuration/check phase which generates a config.h?

Perhaps there should be autotools machinery at the root of the tree, in
place of Config.mk etc? It seems the popular choice.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 22 15:49:07 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 Dec 2011 15:49:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rdksp-0002qO-LI; Thu, 22 Dec 2011 15:48:39 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1Rdksn-0002qJ-Ox
	for xen-devel@lists.xensource.com; Thu, 22 Dec 2011 15:48:37 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1324568857!61799834!1
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28618 invoked from network); 22 Dec 2011 15:47:37 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Dec 2011 15:47:37 -0000
Received: by werg1 with SMTP id g1so9080167wer.30
	for <xen-devel@lists.xensource.com>;
	Thu, 22 Dec 2011 07:48:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=0K3P3ASLfxX4UDK9vb6t/c1lISyy0WCqgRYSqO85eI8=;
	b=gY4rj944CV8C+5vDmKGzyXyHHFtuse5PPsKk5mceDZ4imdFIwXgzKLRchcnMuygKuf
	hU26Ihc0P9JyZcnWzb6o8sB/OOpHRP216Ol+xWIujNYjs6TZO19x3h/o0S5mtUs3kQIb
	XDgjdNDvbPwjmkCO0hWGMOaULL8ij+eqyxyC4=
Received: by 10.216.139.222 with SMTP id c72mr12004554wej.4.1324568913414;
	Thu, 22 Dec 2011 07:48:33 -0800 (PST)
Received: from [192.168.1.3] (host81-152-17-11.range81-152.btcentralplus.com.
	[81.152.17.11])
	by mx.google.com with ESMTPS id w8sm23534381wiz.4.2011.12.22.07.48.31
	(version=SSLv3 cipher=OTHER); Thu, 22 Dec 2011 07:48:32 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Thu, 22 Dec 2011 15:48:29 +0000
From: Keir Fraser <keir@xen.org>
To: Ian Campbell <Ian.Campbell@citrix.com>,
	Roger Pau Monne <roger.pau@entel.upc.edu>
Message-ID: <CB1901CD.36815%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH v2] libxl: add support for yajl 2.x
Thread-Index: AczAwSZCQR2TmZMkb0GOI2s/l/IMnw==
In-Reply-To: <1324567687.7877.91.camel@zakaz.uk.xensource.com>
Mime-version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH v2] libxl: add support for yajl 2.x
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 22/12/2011 15:28, "Ian Campbell" <Ian.Campbell@citrix.com> wrote:

>> diff -r f72b99fccfca -r 716d6d48e647 Config.mk
>> --- a/Config.mk Tue Dec 20 08:31:40 2011 +0100
>> +++ b/Config.mk Tue Dec 20 13:52:55 2011 +0100
>> @@ -186,6 +186,11 @@ CONFIG_LIBICONV   := $(shell export OS="
>>                         . $(XEN_ROOT)/tools/check/funcs.sh; \
>>                         has_lib libiconv.so && echo 'y' || echo 'n')
>>  
>> +CONFIG_YAJL_VERSION := $(shell export OS="`uname -s`"; \
>> +                       export CHECK_INCLUDES="$(CHECK_INCLUDES)"; \
>> +                       . $(XEN_ROOT)/tools/check/funcs.sh; \
>> +                       has_header yajl/yajl_version.h && echo 'y' || echo
>> 'n')
> 
> We've ended up with a few of this sort of thing recently. I wonder if it
> is time to have a configuration/check phase which generates a config.h?

Perhaps there should be autotools machinery at the root of the tree, in
place of Config.mk etc? It seems the popular choice.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 22 15:53:23 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 Dec 2011 15:53:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rdkwy-0002y4-Be; Thu, 22 Dec 2011 15:52:56 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rdkww-0002xl-IB
	for xen-devel@lists.xensource.com; Thu, 22 Dec 2011 15:52:54 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1324569168!9811615!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Nzk5NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11390 invoked from network); 22 Dec 2011 15:52:48 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Dec 2011 15:52:48 -0000
X-IronPort-AV: E=Sophos;i="4.71,393,1320624000"; 
   d="scan'208";a="9638189"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Dec 2011 15:52:46 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 22 Dec 2011 15:52:46 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Keir Fraser <keir@xen.org>
Date: Thu, 22 Dec 2011 15:52:46 +0000
In-Reply-To: <CB1901CD.36815%keir@xen.org>
References: <CB1901CD.36815%keir@xen.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1324569166.7877.93.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Roger Pau Monne <roger.pau@entel.upc.edu>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH v2] libxl: add support for yajl 2.x
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2011-12-22 at 15:48 +0000, Keir Fraser wrote:
> On 22/12/2011 15:28, "Ian Campbell" <Ian.Campbell@citrix.com> wrote:
> 
> >> diff -r f72b99fccfca -r 716d6d48e647 Config.mk
> >> --- a/Config.mk Tue Dec 20 08:31:40 2011 +0100
> >> +++ b/Config.mk Tue Dec 20 13:52:55 2011 +0100
> >> @@ -186,6 +186,11 @@ CONFIG_LIBICONV   := $(shell export OS="
> >>                         . $(XEN_ROOT)/tools/check/funcs.sh; \
> >>                         has_lib libiconv.so && echo 'y' || echo 'n')
> >>  
> >> +CONFIG_YAJL_VERSION := $(shell export OS="`uname -s`"; \
> >> +                       export CHECK_INCLUDES="$(CHECK_INCLUDES)"; \
> >> +                       . $(XEN_ROOT)/tools/check/funcs.sh; \
> >> +                       has_header yajl/yajl_version.h && echo 'y' || echo
> >> 'n')
> > 
> > We've ended up with a few of this sort of thing recently. I wonder if it
> > is time to have a configuration/check phase which generates a config.h?
> 
> Perhaps there should be autotools machinery at the root of the tree, in
> place of Config.mk etc? It seems the popular choice.

"Popular" isn't quite the right word, "common" maybe. It's generally
pretty loathed. But, yes, something along those lines maybe.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 22 15:53:23 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 Dec 2011 15:53:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rdkwy-0002y4-Be; Thu, 22 Dec 2011 15:52:56 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rdkww-0002xl-IB
	for xen-devel@lists.xensource.com; Thu, 22 Dec 2011 15:52:54 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1324569168!9811615!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Nzk5NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11390 invoked from network); 22 Dec 2011 15:52:48 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Dec 2011 15:52:48 -0000
X-IronPort-AV: E=Sophos;i="4.71,393,1320624000"; 
   d="scan'208";a="9638189"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Dec 2011 15:52:46 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 22 Dec 2011 15:52:46 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Keir Fraser <keir@xen.org>
Date: Thu, 22 Dec 2011 15:52:46 +0000
In-Reply-To: <CB1901CD.36815%keir@xen.org>
References: <CB1901CD.36815%keir@xen.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1324569166.7877.93.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Roger Pau Monne <roger.pau@entel.upc.edu>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH v2] libxl: add support for yajl 2.x
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2011-12-22 at 15:48 +0000, Keir Fraser wrote:
> On 22/12/2011 15:28, "Ian Campbell" <Ian.Campbell@citrix.com> wrote:
> 
> >> diff -r f72b99fccfca -r 716d6d48e647 Config.mk
> >> --- a/Config.mk Tue Dec 20 08:31:40 2011 +0100
> >> +++ b/Config.mk Tue Dec 20 13:52:55 2011 +0100
> >> @@ -186,6 +186,11 @@ CONFIG_LIBICONV   := $(shell export OS="
> >>                         . $(XEN_ROOT)/tools/check/funcs.sh; \
> >>                         has_lib libiconv.so && echo 'y' || echo 'n')
> >>  
> >> +CONFIG_YAJL_VERSION := $(shell export OS="`uname -s`"; \
> >> +                       export CHECK_INCLUDES="$(CHECK_INCLUDES)"; \
> >> +                       . $(XEN_ROOT)/tools/check/funcs.sh; \
> >> +                       has_header yajl/yajl_version.h && echo 'y' || echo
> >> 'n')
> > 
> > We've ended up with a few of this sort of thing recently. I wonder if it
> > is time to have a configuration/check phase which generates a config.h?
> 
> Perhaps there should be autotools machinery at the root of the tree, in
> place of Config.mk etc? It seems the popular choice.

"Popular" isn't quite the right word, "common" maybe. It's generally
pretty loathed. But, yes, something along those lines maybe.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 22 16:41:52 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 Dec 2011 16:41:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rdlho-0003y5-4E; Thu, 22 Dec 2011 16:41:20 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1Rdlhl-0003xw-PO
	for xen-devel@lists.xensource.com; Thu, 22 Dec 2011 16:41:18 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1324572069!8352885!1
X-Originating-IP: [209.85.160.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29633 invoked from network); 22 Dec 2011 16:41:11 -0000
Received: from mail-pw0-f43.google.com (HELO mail-pw0-f43.google.com)
	(209.85.160.43)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Dec 2011 16:41:11 -0000
Received: by pbbb11 with SMTP id b11so29131981pbb.30
	for <xen-devel@lists.xensource.com>;
	Thu, 22 Dec 2011 08:41:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=cxHBheVwuPdI6uoeS9ehcUjSpTV7T/zwJvpFlGnpt3Q=;
	b=giLh8F27t49CC8t/QzAs/UrkKJZI2ORzc5aK02uiFVf4v1cw8YiCY3QuIa9GoNziU7
	xEJBqCPGkE9ZmLGLNy94hwD0fGZ7fWE3aCO3kQRrfEElIY85Ufwn1MSG4aCAH7X+qmU5
	rOt5HXPx78Eg47vU/zvFifVDqEso2zjnP0fgk=
MIME-Version: 1.0
Received: by 10.68.75.233 with SMTP id f9mr24485542pbw.10.1324572068857; Thu,
	22 Dec 2011 08:41:08 -0800 (PST)
Received: by 10.142.47.17 with HTTP; Thu, 22 Dec 2011 08:41:08 -0800 (PST)
In-Reply-To: <1324569166.7877.93.camel@zakaz.uk.xensource.com>
References: <CB1901CD.36815%keir@xen.org>
	<1324569166.7877.93.camel@zakaz.uk.xensource.com>
Date: Thu, 22 Dec 2011 17:41:08 +0100
X-Google-Sender-Auth: Ugg9tvZ81NpngR6ley-iMb6P1ik
Message-ID: <CAPLaKK7icOx97OcL=QTd=ciudso3TNFJWdsQagZHboSruQ2rYA@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Keir Fraser <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH v2] libxl: add support for yajl 2.x
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

2011/12/22 Ian Campbell <Ian.Campbell@citrix.com>:
>> Perhaps there should be autotools machinery at the root of the tree, in
>> place of Config.mk etc? It seems the popular choice.
>
> "Popular" isn't quite the right word, "common" maybe. It's generally
> pretty loathed. But, yes, something along those lines maybe.

Some autogoo stuff will be good, at least for the tools build. Can you
set up the basic structure Ian?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 22 16:41:52 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 Dec 2011 16:41:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rdlho-0003y5-4E; Thu, 22 Dec 2011 16:41:20 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1Rdlhl-0003xw-PO
	for xen-devel@lists.xensource.com; Thu, 22 Dec 2011 16:41:18 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1324572069!8352885!1
X-Originating-IP: [209.85.160.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29633 invoked from network); 22 Dec 2011 16:41:11 -0000
Received: from mail-pw0-f43.google.com (HELO mail-pw0-f43.google.com)
	(209.85.160.43)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Dec 2011 16:41:11 -0000
Received: by pbbb11 with SMTP id b11so29131981pbb.30
	for <xen-devel@lists.xensource.com>;
	Thu, 22 Dec 2011 08:41:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=cxHBheVwuPdI6uoeS9ehcUjSpTV7T/zwJvpFlGnpt3Q=;
	b=giLh8F27t49CC8t/QzAs/UrkKJZI2ORzc5aK02uiFVf4v1cw8YiCY3QuIa9GoNziU7
	xEJBqCPGkE9ZmLGLNy94hwD0fGZ7fWE3aCO3kQRrfEElIY85Ufwn1MSG4aCAH7X+qmU5
	rOt5HXPx78Eg47vU/zvFifVDqEso2zjnP0fgk=
MIME-Version: 1.0
Received: by 10.68.75.233 with SMTP id f9mr24485542pbw.10.1324572068857; Thu,
	22 Dec 2011 08:41:08 -0800 (PST)
Received: by 10.142.47.17 with HTTP; Thu, 22 Dec 2011 08:41:08 -0800 (PST)
In-Reply-To: <1324569166.7877.93.camel@zakaz.uk.xensource.com>
References: <CB1901CD.36815%keir@xen.org>
	<1324569166.7877.93.camel@zakaz.uk.xensource.com>
Date: Thu, 22 Dec 2011 17:41:08 +0100
X-Google-Sender-Auth: Ugg9tvZ81NpngR6ley-iMb6P1ik
Message-ID: <CAPLaKK7icOx97OcL=QTd=ciudso3TNFJWdsQagZHboSruQ2rYA@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Keir Fraser <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH v2] libxl: add support for yajl 2.x
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

2011/12/22 Ian Campbell <Ian.Campbell@citrix.com>:
>> Perhaps there should be autotools machinery at the root of the tree, in
>> place of Config.mk etc? It seems the popular choice.
>
> "Popular" isn't quite the right word, "common" maybe. It's generally
> pretty loathed. But, yes, something along those lines maybe.

Some autogoo stuff will be good, at least for the tools build. Can you
set up the basic structure Ian?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 22 17:03:43 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 Dec 2011 17:03:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rdm2z-0004KI-3s; Thu, 22 Dec 2011 17:03:13 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1Rdm2x-0004K4-JL
	for xen-devel@lists.xensource.com; Thu, 22 Dec 2011 17:03:11 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1324573382!6599152!1
X-Originating-IP: [209.85.160.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30674 invoked from network); 22 Dec 2011 17:03:04 -0000
Received: from mail-pw0-f43.google.com (HELO mail-pw0-f43.google.com)
	(209.85.160.43)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Dec 2011 17:03:04 -0000
Received: by pbbb11 with SMTP id b11so29190022pbb.30
	for <xen-devel@lists.xensource.com>;
	Thu, 22 Dec 2011 09:03:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:date:x-google-sender-auth:message-id:subject
	:from:to:content-type;
	bh=MrrN1myt6rLyj6uAazbFpRnkpQ79JE8L8umqqf8f+Ng=;
	b=SKkuCYk61LSWEsZoe9t1nqJaEn5bf7CpLFYW+vE5b7+ZNmogJOQiySByWu7fYe8Xzx
	hoKmD7tfAvfUjZC8ygYslsXSnu4qjFkss+/AEDZCbLkC/vyvF3k5zcPPZFyvvaJIxTZS
	DgL3XTHJBPwq9nxTwd9pZEGAxlEePNPoyGmdw=
MIME-Version: 1.0
Received: by 10.68.189.133 with SMTP id gi5mr24544979pbc.27.1324573381393;
	Thu, 22 Dec 2011 09:03:01 -0800 (PST)
Received: by 10.142.47.17 with HTTP; Thu, 22 Dec 2011 09:03:01 -0800 (PST)
Date: Thu, 22 Dec 2011 18:03:01 +0100
X-Google-Sender-Auth: KLwdD57qYY9dUkdfjeXRqKkipwc
Message-ID: <CAPLaKK506e57uCvSdkjCqkUs6AS6ty4Efa+Ekhrczu=OA+TCHw@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] Stubdom build problem in 4.1.2 but not in xen-unstable
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hello,

I've found the following problem while building Xen 4.1.2 stubdoms:

gcc -DCONFIG_QEMU -mno-red-zone -O1 -fno-omit-frame-pointer
-fno-optimize-sibling-calls  -m64 -mno-red-zone -fno-reorder-blocks
-fno-asynchronous-unwind-tables -m64 -g -fno-strict-aliasing
-std=gnu99 -Wall -Wstrict-prototypes -Wno-unused-value
-Wdeclaration-after-statement -Wno-unused-but-set-variable  -nopie
-fno-stack-protector -fno-exceptions -fno-builtin -Wall -Werror
-Wredundant-decls -Wno-format -Wno-redundant-decls
-fno-stack-protector -fgnu89-inline -Wstrict-prototypes
-Wnested-externs -Wpointer-arith -Winline -g -DGNT_DEBUG
-DGNTMAP_DEBUG -D__INSIDE_MINIOS__ -m64 -mno-red-zone
-fno-reorder-blocks -fno-asynchronous-unwind-tables -Os
-fomit-frame-pointer -isystem
/home/royger/aports/testing/xen/src/xen-4.1.2/stubdom/../extras/mini-os/include
-D__MINIOS__ -DHAVE_LIBC -isystem
/home/royger/aports/testing/xen/src/xen-4.1.2/stubdom/../extras/mini-os/include/posix
-isystem /home/royger/aports/testing/xen/src/xen-4.1.2/stubdom/../tools/xenstore
 -isystem /home/royger/aports/testing/xen/src/xen-4.1.2/stubdom/../extras/mini-os/include/x86
-isystem /home/royger/aports/testing/xen/src/xen-4.1.2/stubdom/../extras/mini-os/include/x86/x86_64
-U __linux__ -U __FreeBSD__ -U __sun__ -nostdinc -isystem
/home/royger/aports/testing/xen/src/xen-4.1.2/stubdom/../extras/mini-os/include/posix
-isystem /home/royger/aports/testing/xen/src/xen-4.1.2/stubdom/cross-root-x86_64/x86_64-xen-elf/include
-isystem /usr/lib/gcc/x86_64-alpine-linux-uclibc/4.6.2/include
-isystem /home/royger/aports/testing/xen/src/xen-4.1.2/stubdom/lwip-x86_64/src/include
-isystem /home/royger/aports/testing/xen/src/xen-4.1.2/stubdom/lwip-x86_64/src/include/ipv4
-I/home/royger/aports/testing/xen/src/xen-4.1.2/stubdom/include
-I/home/royger/aports/testing/xen/src/xen-4.1.2/stubdom/../xen/include
-isystem /home/royger/aports/testing/xen/src/xen-4.1.2/extras/mini-os/../../extras/mini-os/include
-D__MINIOS__ -DHAVE_LIBC -isystem
/home/royger/aports/testing/xen/src/xen-4.1.2/extras/mini-os/../../extras/mini-os/include/posix
-isystem /home/royger/aports/testing/xen/src/xen-4.1.2/extras/mini-os/../../tools/xenstore
-DHAVE_LWIP -isystem
/home/royger/aports/testing/xen/src/xen-4.1.2/stubdom/lwip-x86_64/src/include
-isystem /home/royger/aports/testing/xen/src/xen-4.1.2/stubdom/lwip-x86_64/src/include/ipv4
-D__XEN_INTERFACE_VERSION__=0x00030205  -isystem
/home/royger/aports/testing/xen/src/xen-4.1.2/extras/mini-os/../../extras/mini-os/include/x86
-isystem /home/royger/aports/testing/xen/src/xen-4.1.2/extras/mini-os/../../extras/mini-os/include/x86/x86_64
-c console/xencons_ring.c -o
/home/royger/aports/testing/xen/src/xen-4.1.2/stubdom/mini-os-x86_64-ioemu/console/xencons_ring.o
console/xencons_ring.c: In function 'xencons_ring_send_no_notify':
console/xencons_ring.c:26:41: error: inlining failed in call to
'xencons_interface': call is unlikely and code size would grow
[-Werror=inline]
console/xencons_ring.c:38:18: error: called from here [-Werror=inline]
cc1: all warnings being treated as errors

Although I can build xen-unstable without any problems on the same
machine. I've been trying to find the patch that solved this on
unstable, but so far I haven't found it. Anyone know which patch fixed
it? I would like to have it backported to xen-4.1.

Info about the system:

Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-alpine-linux-uclibc/4.6.2/lto-wrapper
Target: x86_64-alpine-linux-uclibc
Configured with:
/home/buildozer/aports/main/gcc/src/gcc-4.6.2/configure --prefix=/usr
--mandir=/usr/share/man --infodir=/usr/share/info
--build=x86_64-alpine-linux-uclibc --host=x86_64-alpine-linux-uclibc
--target=x86_64-alpine-linux-uclibc --with-pkgversion='Alpine
4.6.2-r1' --disable-altivec --disable-checking --disable-fixed-point
--disable-libssp --disable-libstdcxx-pch --disable-multilib
--disable-nls --disable-werror --enable-__cxa_atexit --enable-cld
--enable-esp --enable-cloog-backend
--enable-languages=c,c++,objc,java,go --enable-shared
--enable-target-optspace --enable-tls --enable-threads
--with-dynamic-linker=ld64-uClibc.so.0.9.32
--with-dynamic-linker-prefix=/lib --with-system-zlib
--without-system-libunwind
Thread model: posix
gcc version 4.6.2 (Alpine 4.6.2-r1)

Thanks, Roger!

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 22 17:03:43 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 Dec 2011 17:03:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rdm2z-0004KI-3s; Thu, 22 Dec 2011 17:03:13 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1Rdm2x-0004K4-JL
	for xen-devel@lists.xensource.com; Thu, 22 Dec 2011 17:03:11 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1324573382!6599152!1
X-Originating-IP: [209.85.160.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30674 invoked from network); 22 Dec 2011 17:03:04 -0000
Received: from mail-pw0-f43.google.com (HELO mail-pw0-f43.google.com)
	(209.85.160.43)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Dec 2011 17:03:04 -0000
Received: by pbbb11 with SMTP id b11so29190022pbb.30
	for <xen-devel@lists.xensource.com>;
	Thu, 22 Dec 2011 09:03:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:date:x-google-sender-auth:message-id:subject
	:from:to:content-type;
	bh=MrrN1myt6rLyj6uAazbFpRnkpQ79JE8L8umqqf8f+Ng=;
	b=SKkuCYk61LSWEsZoe9t1nqJaEn5bf7CpLFYW+vE5b7+ZNmogJOQiySByWu7fYe8Xzx
	hoKmD7tfAvfUjZC8ygYslsXSnu4qjFkss+/AEDZCbLkC/vyvF3k5zcPPZFyvvaJIxTZS
	DgL3XTHJBPwq9nxTwd9pZEGAxlEePNPoyGmdw=
MIME-Version: 1.0
Received: by 10.68.189.133 with SMTP id gi5mr24544979pbc.27.1324573381393;
	Thu, 22 Dec 2011 09:03:01 -0800 (PST)
Received: by 10.142.47.17 with HTTP; Thu, 22 Dec 2011 09:03:01 -0800 (PST)
Date: Thu, 22 Dec 2011 18:03:01 +0100
X-Google-Sender-Auth: KLwdD57qYY9dUkdfjeXRqKkipwc
Message-ID: <CAPLaKK506e57uCvSdkjCqkUs6AS6ty4Efa+Ekhrczu=OA+TCHw@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] Stubdom build problem in 4.1.2 but not in xen-unstable
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hello,

I've found the following problem while building Xen 4.1.2 stubdoms:

gcc -DCONFIG_QEMU -mno-red-zone -O1 -fno-omit-frame-pointer
-fno-optimize-sibling-calls  -m64 -mno-red-zone -fno-reorder-blocks
-fno-asynchronous-unwind-tables -m64 -g -fno-strict-aliasing
-std=gnu99 -Wall -Wstrict-prototypes -Wno-unused-value
-Wdeclaration-after-statement -Wno-unused-but-set-variable  -nopie
-fno-stack-protector -fno-exceptions -fno-builtin -Wall -Werror
-Wredundant-decls -Wno-format -Wno-redundant-decls
-fno-stack-protector -fgnu89-inline -Wstrict-prototypes
-Wnested-externs -Wpointer-arith -Winline -g -DGNT_DEBUG
-DGNTMAP_DEBUG -D__INSIDE_MINIOS__ -m64 -mno-red-zone
-fno-reorder-blocks -fno-asynchronous-unwind-tables -Os
-fomit-frame-pointer -isystem
/home/royger/aports/testing/xen/src/xen-4.1.2/stubdom/../extras/mini-os/include
-D__MINIOS__ -DHAVE_LIBC -isystem
/home/royger/aports/testing/xen/src/xen-4.1.2/stubdom/../extras/mini-os/include/posix
-isystem /home/royger/aports/testing/xen/src/xen-4.1.2/stubdom/../tools/xenstore
 -isystem /home/royger/aports/testing/xen/src/xen-4.1.2/stubdom/../extras/mini-os/include/x86
-isystem /home/royger/aports/testing/xen/src/xen-4.1.2/stubdom/../extras/mini-os/include/x86/x86_64
-U __linux__ -U __FreeBSD__ -U __sun__ -nostdinc -isystem
/home/royger/aports/testing/xen/src/xen-4.1.2/stubdom/../extras/mini-os/include/posix
-isystem /home/royger/aports/testing/xen/src/xen-4.1.2/stubdom/cross-root-x86_64/x86_64-xen-elf/include
-isystem /usr/lib/gcc/x86_64-alpine-linux-uclibc/4.6.2/include
-isystem /home/royger/aports/testing/xen/src/xen-4.1.2/stubdom/lwip-x86_64/src/include
-isystem /home/royger/aports/testing/xen/src/xen-4.1.2/stubdom/lwip-x86_64/src/include/ipv4
-I/home/royger/aports/testing/xen/src/xen-4.1.2/stubdom/include
-I/home/royger/aports/testing/xen/src/xen-4.1.2/stubdom/../xen/include
-isystem /home/royger/aports/testing/xen/src/xen-4.1.2/extras/mini-os/../../extras/mini-os/include
-D__MINIOS__ -DHAVE_LIBC -isystem
/home/royger/aports/testing/xen/src/xen-4.1.2/extras/mini-os/../../extras/mini-os/include/posix
-isystem /home/royger/aports/testing/xen/src/xen-4.1.2/extras/mini-os/../../tools/xenstore
-DHAVE_LWIP -isystem
/home/royger/aports/testing/xen/src/xen-4.1.2/stubdom/lwip-x86_64/src/include
-isystem /home/royger/aports/testing/xen/src/xen-4.1.2/stubdom/lwip-x86_64/src/include/ipv4
-D__XEN_INTERFACE_VERSION__=0x00030205  -isystem
/home/royger/aports/testing/xen/src/xen-4.1.2/extras/mini-os/../../extras/mini-os/include/x86
-isystem /home/royger/aports/testing/xen/src/xen-4.1.2/extras/mini-os/../../extras/mini-os/include/x86/x86_64
-c console/xencons_ring.c -o
/home/royger/aports/testing/xen/src/xen-4.1.2/stubdom/mini-os-x86_64-ioemu/console/xencons_ring.o
console/xencons_ring.c: In function 'xencons_ring_send_no_notify':
console/xencons_ring.c:26:41: error: inlining failed in call to
'xencons_interface': call is unlikely and code size would grow
[-Werror=inline]
console/xencons_ring.c:38:18: error: called from here [-Werror=inline]
cc1: all warnings being treated as errors

Although I can build xen-unstable without any problems on the same
machine. I've been trying to find the patch that solved this on
unstable, but so far I haven't found it. Anyone know which patch fixed
it? I would like to have it backported to xen-4.1.

Info about the system:

Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-alpine-linux-uclibc/4.6.2/lto-wrapper
Target: x86_64-alpine-linux-uclibc
Configured with:
/home/buildozer/aports/main/gcc/src/gcc-4.6.2/configure --prefix=/usr
--mandir=/usr/share/man --infodir=/usr/share/info
--build=x86_64-alpine-linux-uclibc --host=x86_64-alpine-linux-uclibc
--target=x86_64-alpine-linux-uclibc --with-pkgversion='Alpine
4.6.2-r1' --disable-altivec --disable-checking --disable-fixed-point
--disable-libssp --disable-libstdcxx-pch --disable-multilib
--disable-nls --disable-werror --enable-__cxa_atexit --enable-cld
--enable-esp --enable-cloog-backend
--enable-languages=c,c++,objc,java,go --enable-shared
--enable-target-optspace --enable-tls --enable-threads
--with-dynamic-linker=ld64-uClibc.so.0.9.32
--with-dynamic-linker-prefix=/lib --with-system-zlib
--without-system-libunwind
Thread model: posix
gcc version 4.6.2 (Alpine 4.6.2-r1)

Thanks, Roger!

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 22 17:27:37 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 Dec 2011 17:27:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdmQ6-00050x-V4; Thu, 22 Dec 2011 17:27:06 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RdmQ5-00050s-HW
	for xen-devel@lists.xensource.com; Thu, 22 Dec 2011 17:27:05 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1324574819!1818590!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Nzk5NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8858 invoked from network); 22 Dec 2011 17:26:59 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Dec 2011 17:26:59 -0000
X-IronPort-AV: E=Sophos;i="4.71,394,1320624000"; 
   d="scan'208";a="9640297"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Dec 2011 17:26:59 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 22 Dec 2011 17:26:59 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau =?ISO-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
In-Reply-To: <CAPLaKK7icOx97OcL=QTd=ciudso3TNFJWdsQagZHboSruQ2rYA@mail.gmail.com>
References: <CB1901CD.36815%keir@xen.org>
	<1324569166.7877.93.camel@zakaz.uk.xensource.com>
	<CAPLaKK7icOx97OcL=QTd=ciudso3TNFJWdsQagZHboSruQ2rYA@mail.gmail.com>
Organization: Citrix Systems, Inc.
Date: Thu, 22 Dec 2011 17:26:58 +0000
Message-ID: <1324574818.13113.0.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
X-Mailer: Evolution 2.32.3 
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH v2] libxl: add support for yajl 2.x
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2011-12-22 at 16:41 +0000, Roger Pau Monn=E9 wrote:
> 2011/12/22 Ian Campbell <Ian.Campbell@citrix.com>:
> >> Perhaps there should be autotools machinery at the root of the tree, in
> >> place of Config.mk etc? It seems the popular choice.
> >
> > "Popular" isn't quite the right word, "common" maybe. It's generally
> > pretty loathed. But, yes, something along those lines maybe.
> =

> Some autogoo stuff will be good, at least for the tools build. Can you
> set up the basic structure Ian?

I'm not going to have time in the near future.

Would it be sufficient to have the stuff in tools/check create a
config.h as well as doing the checks? Might need a bit of Makefile magic
to be sure that check is always run?

Ian.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 22 17:27:37 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 Dec 2011 17:27:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdmQ6-00050x-V4; Thu, 22 Dec 2011 17:27:06 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RdmQ5-00050s-HW
	for xen-devel@lists.xensource.com; Thu, 22 Dec 2011 17:27:05 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1324574819!1818590!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Nzk5NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8858 invoked from network); 22 Dec 2011 17:26:59 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Dec 2011 17:26:59 -0000
X-IronPort-AV: E=Sophos;i="4.71,394,1320624000"; 
   d="scan'208";a="9640297"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Dec 2011 17:26:59 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 22 Dec 2011 17:26:59 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau =?ISO-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
In-Reply-To: <CAPLaKK7icOx97OcL=QTd=ciudso3TNFJWdsQagZHboSruQ2rYA@mail.gmail.com>
References: <CB1901CD.36815%keir@xen.org>
	<1324569166.7877.93.camel@zakaz.uk.xensource.com>
	<CAPLaKK7icOx97OcL=QTd=ciudso3TNFJWdsQagZHboSruQ2rYA@mail.gmail.com>
Organization: Citrix Systems, Inc.
Date: Thu, 22 Dec 2011 17:26:58 +0000
Message-ID: <1324574818.13113.0.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
X-Mailer: Evolution 2.32.3 
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH v2] libxl: add support for yajl 2.x
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2011-12-22 at 16:41 +0000, Roger Pau Monn=E9 wrote:
> 2011/12/22 Ian Campbell <Ian.Campbell@citrix.com>:
> >> Perhaps there should be autotools machinery at the root of the tree, in
> >> place of Config.mk etc? It seems the popular choice.
> >
> > "Popular" isn't quite the right word, "common" maybe. It's generally
> > pretty loathed. But, yes, something along those lines maybe.
> =

> Some autogoo stuff will be good, at least for the tools build. Can you
> set up the basic structure Ian?

I'm not going to have time in the near future.

Would it be sufficient to have the stuff in tools/check create a
config.h as well as doing the checks? Might need a bit of Makefile magic
to be sure that check is always run?

Ian.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 22 17:42:06 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 Dec 2011 17:42:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdmeD-0005D2-Sk; Thu, 22 Dec 2011 17:41:41 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1RdmeA-0005CQ-PI
	for xen-devel@lists.xensource.com; Thu, 22 Dec 2011 17:41:39 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1324575692!8419607!4
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Nzk5NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14651 invoked from network); 22 Dec 2011 17:41:32 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Dec 2011 17:41:32 -0000
X-IronPort-AV: E=Sophos;i="4.71,394,1320624000"; 
   d="scan'208";a="9640551"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Dec 2011 17:41:32 +0000
Received: from andrewcoop.uk.xensource.com (10.80.2.18) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 22 Dec 2011 17:41:32 +0000
MIME-Version: 1.0
X-Mercurial-Node: 23c31d59ffb1590815bc8238d992b9a82b3dd6ec
Message-ID: <23c31d59ffb1590815bc.1324575385@andrewcoop.uk.xensource.com>
In-Reply-To: <patchbomb.1324575382@andrewcoop.uk.xensource.com>
References: <patchbomb.1324575382@andrewcoop.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.4.3
Date: Thu, 22 Dec 2011 17:36:25 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: <xen-devel@lists.xensource.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>
Subject: [Xen-devel] [PATCH 3 of 3] KEXEC: Allocate crash structures in low
	memory
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 64bit Xen with 32bit dom0 and crashkernel, xmalloc'ing items such
as the CPU crash notes will go into the xenheap, which tends to be in
upper memory.  This causes problems on machines with more than 64GB
(or 4GB if no PAE support) of ram as the crashkernel physically cant
access the crash notes.

The solution is to force Xen to allocate certain structures in lower
memory.  This is achieved by introducing two new command line
parameters; low_crashinfo and crashinfo_maxaddr.  Because of the
potential impact on 32bit PV guests, and that this problem does not
exist for 64bit dom0 on 64bit Xen, this new functionality defaults to
the codebase's previous behavior, requiring the user to explicitly
add extra command line parameters to change the behavior.

This patch consists of 3 logically distinct but closely related
changes.
 1) Add the two new command line parameters.
 2) Change crash note allocation to use lower memory when instructed.
 3) Change the conring buffer to use lower memory when instructed.

There result is that the crash notes and console ring will be placed
in lower memory so useful information can be recovered in the case of
a crash.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

diff -r 3da37c68284f -r 23c31d59ffb1 xen/arch/x86/setup.c
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -586,6 +586,10 @@ void __init __start_xen(unsigned long mb
     }
     cmdline_parse(cmdline);
 
+    /* Must be after command line argument parsing and before 
+     * allocing any xenheap structures wanted in lower memory. */
+    kexec_early_calculations();
+
     parse_video_info();
 
     set_current((struct vcpu *)0xfffff000); /* debug sanity */
diff -r 3da37c68284f -r 23c31d59ffb1 xen/common/kexec.c
--- a/xen/common/kexec.c
+++ b/xen/common/kexec.c
@@ -36,7 +36,9 @@ bool_t kexecing = FALSE;
 typedef struct { Elf_Note * start; size_t size; } crash_note_range_t;
 static crash_note_range_t * crash_notes;
 
-/* Lock to prevent race conditions when allocating the crash note buffers. */
+/* Lock to prevent race conditions when allocating the crash note buffers.
+ * It also serves to protect calls to alloc_from_crash_heap when allocating
+ * crash note buffers in lower memory. */
 static DEFINE_SPINLOCK(crash_notes_lock);
 
 static Elf_Note *xen_crash_note;
@@ -70,6 +72,23 @@ static struct {
     (_d_)->start = (_s_)->start; \
 } while (0)
 
+/* Low crashinfo mode.  Start as INVALID so serveral codepaths can set up
+ * defaults without needing to know the state of the others. */
+enum low_crashinfo low_crashinfo_mode = LOW_CRASHINFO_INVALID;
+
+/* This value is only considered if low_crash_mode is set to MIN or ALL, so
+ * setting a default here is safe. Default to 4GB.  This is because the current
+ * KEXEC_CMD_get_range compat hypercall trucates 64bit pointers to 32 bits. The
+ * typical usecase for crashinfo_maxaddr will be for 64bit Xen with 32bit dom0 
+ * and 32bit crash kernel. */
+static paddr_t crashinfo_maxaddr = 4ULL << 30;
+
+/* = log base 2 of crashinfo_maxaddr after checking for sanity. */
+paddr_t crashinfo_maxaddr_bits = 0;
+
+/* Pointers to keep track of the crash heap region. */
+static void *crash_heap_current = NULL, *crash_heap_end = NULL;
+
 /*
  * Parse command lines in the format
  *
@@ -148,6 +167,58 @@ static void __init parse_crashkernel(con
 }
 custom_param("crashkernel", parse_crashkernel);
 
+/* Parse command lines in the format:
+ *
+ *   low_crashinfo=[none,min,all]
+ * 
+ * - none disables the low allocation of crash info.
+ * - min will allocate enough low information for the crash kernel to be able
+ *       to extract the hypervisor and dom0 message ring buffers.
+ * - all will allocate additional structures such as domain and vcpu structs
+ *       low so the crash kernel can perform an extended analysis of state.
+ */
+static void __init parse_low_crashinfo(const char * str)
+{
+
+    if ( !strlen(str) )
+        /* default to min if user just specifies "low_crashinfo" */
+        low_crashinfo_mode = LOW_CRASHINFO_MIN;
+    else if ( !strcmp(str, "none" ) )
+        low_crashinfo_mode = LOW_CRASHINFO_NONE;
+    else if ( !strcmp(str, "min" ) )
+        low_crashinfo_mode = LOW_CRASHINFO_MIN;
+    else if ( !strcmp(str, "all" ) )
+        low_crashinfo_mode = LOW_CRASHINFO_ALL;
+    else
+    {
+        printk("Unknown low_crashinfo parameter '%s'.  Defaulting to min.\n", str);
+        low_crashinfo_mode = LOW_CRASHINFO_MIN;
+    }
+}
+custom_param("low_crashinfo", parse_low_crashinfo);
+
+/* Parse command lines in the format:
+ * 
+ *   crashinfo_maxaddr=<addr>
+ *
+ * <addr> will be rounded down to the nearest power of two.  Defaults to 64G
+ */
+static void __init parse_crashinfo_maxaddr(const char * str)
+{
+    u64 addr;
+
+    /* if low_crashinfo_mode is unset, default to min. */
+    if ( low_crashinfo_mode == LOW_CRASHINFO_INVALID )
+        low_crashinfo_mode = LOW_CRASHINFO_MIN;
+
+    if ( (addr = parse_size_and_unit(str, NULL)) )
+        crashinfo_maxaddr = addr;
+    else
+        printk("Unable to parse crashinfo_maxaddr. Defaulting to %p\n",
+               (void*)crashinfo_maxaddr);
+}
+custom_param("crashinfo_maxaddr", parse_crashinfo_maxaddr);
+
 void __init set_kexec_crash_area_size(u64 system_ram)
 {
     unsigned int idx;
@@ -306,6 +377,20 @@ static size_t sizeof_cpu_notes(const uns
     return bytes;
 }
 
+/* Allocate size_t bytes of space from the previously allocated
+ * crash heap if the user has requested that crash notes be allocated
+ * in lower memory.  There is currently no case where the crash notes
+ * should be free()'d. */
+static void * alloc_from_crash_heap(const size_t bytes)
+{
+    void * ret;
+    if ( crash_heap_current + bytes > crash_heap_end )
+        return NULL;
+    ret = (void*)crash_heap_current;
+    crash_heap_current += bytes;
+    return ret;
+}
+
 /* Allocate a crash note buffer for a newly onlined cpu. */
 static int kexec_init_cpu_notes(const unsigned long cpu)
 {
@@ -320,7 +405,10 @@ static int kexec_init_cpu_notes(const un
         return ret;
 
     nr_bytes = sizeof_cpu_notes(cpu);
-    note = xmalloc_bytes(nr_bytes);
+
+    /* If we dont care about the position of allocation, malloc. */
+    if ( low_crashinfo_mode == LOW_CRASHINFO_NONE )
+        note = xmalloc_bytes(nr_bytes);
 
     /* Protect the write into crash_notes[] with a spinlock, as this function
      * is on a hotplug path and a hypercall path. */
@@ -338,6 +426,11 @@ static int kexec_init_cpu_notes(const un
     }
     else
     {
+        /* If we care about memory possition, alloc from the crash heap,
+         * also protected by the crash_notes_lock. */
+        if ( low_crashinfo_mode > LOW_CRASHINFO_NONE )
+            note = alloc_from_crash_heap(nr_bytes);
+
         crash_notes[cpu].start = note;
         crash_notes[cpu].size = nr_bytes;
         spin_unlock(&crash_notes_lock);
@@ -397,6 +490,24 @@ static struct notifier_block cpu_nfb = {
     .notifier_call = cpu_callback
 };
 
+void __init kexec_early_calculations(void)
+{
+    /* If low_crashinfo_mode is still INVALID, neither "low_crashinfo" nor
+     * "crashinfo_maxaddr" have been specified on the command line, so
+     * explicitly set to NONE. */
+    if ( low_crashinfo_mode == LOW_CRASHINFO_INVALID )
+        low_crashinfo_mode = LOW_CRASHINFO_NONE;
+
+    crashinfo_maxaddr_bits = 0;
+    if ( low_crashinfo_mode > LOW_CRASHINFO_NONE )
+    {
+        paddr_t tmp = crashinfo_maxaddr;
+
+        while ( tmp >>= 1 )
+            crashinfo_maxaddr_bits++;
+    }
+}
+
 static int __init kexec_init(void)
 {
     void *cpu = (void *)(unsigned long)smp_processor_id();
@@ -407,6 +518,29 @@ static int __init kexec_init(void)
 
     register_keyhandler('C', &crashdump_trigger_keyhandler);
 
+    if ( low_crashinfo_mode > LOW_CRASHINFO_NONE )
+    {
+        size_t crash_heap_size;
+
+        /* This calculation is safe even if the machine is booted in 
+         * uniprocessor mode. */
+        crash_heap_size = sizeof_cpu_notes(0) +
+            sizeof_cpu_notes(1) * (nr_cpu_ids - 1);
+        crash_heap_size = PAGE_ALIGN(crash_heap_size);
+
+        crash_heap_current = alloc_xenheap_pages(
+            get_order_from_bytes(crash_heap_size),
+            MEMF_bits(crashinfo_maxaddr_bits) );
+
+        if ( crash_heap_current )
+            crash_heap_end = crash_heap_current + crash_heap_size;
+        else
+            return -ENOMEM;
+    }
+
+    /* crash_notes may be allocated anywhere Xen can reach in memory.
+       Only the individual CPU crash notes themselves must be allocated
+       in lower memory if requested. */
     crash_notes = xmalloc_array(crash_note_range_t, nr_cpu_ids);
     if ( ! crash_notes )
         return -ENOMEM;
diff -r 3da37c68284f -r 23c31d59ffb1 xen/drivers/char/console.c
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -584,6 +584,7 @@ void __init console_init_postirq(void)
 {
     char *ring;
     unsigned int i, order;
+    u64 memflags;
 
     serial_init_postirq();
 
@@ -591,7 +592,8 @@ void __init console_init_postirq(void)
         opt_conring_size = num_present_cpus() << (9 + xenlog_lower_thresh);
 
     order = get_order_from_bytes(max(opt_conring_size, conring_size));
-    while ( (ring = alloc_xenheap_pages(order, 0)) == NULL )
+    memflags = low_crashinfo_mode > LOW_CRASHINFO_NONE ? MEMF_bits(crashinfo_maxaddr_bits) : 0;
+    while ( (ring = alloc_xenheap_pages(order, memflags)) == NULL )
     {
         BUG_ON(order == 0);
         order--;
diff -r 3da37c68284f -r 23c31d59ffb1 xen/include/xen/kexec.h
--- a/xen/include/xen/kexec.h
+++ b/xen/include/xen/kexec.h
@@ -25,6 +25,19 @@ void set_kexec_crash_area_size(u64 syste
 #define KEXEC_IMAGE_CRASH_BASE   2
 #define KEXEC_IMAGE_NR           4
 
+enum low_crashinfo {
+    LOW_CRASHINFO_INVALID = 0,
+    LOW_CRASHINFO_NONE = 1,
+    LOW_CRASHINFO_MIN = 2,
+    LOW_CRASHINFO_ALL = 3
+};
+
+/* Low crashinfo mode.  Start as INVALID so serveral codepaths can set up
+ * defaults without needing to know the state of the others. */
+extern enum low_crashinfo low_crashinfo_mode;
+extern paddr_t crashinfo_maxaddr_bits;
+void kexec_early_calculations(void);
+
 int machine_kexec_load(int type, int slot, xen_kexec_image_t *image);
 void machine_kexec_unload(int type, int slot, xen_kexec_image_t *image);
 void machine_kexec_reserved(xen_kexec_reserve_t *reservation);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 22 17:42:06 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 Dec 2011 17:42:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdmeD-0005D2-Sk; Thu, 22 Dec 2011 17:41:41 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1RdmeA-0005CQ-PI
	for xen-devel@lists.xensource.com; Thu, 22 Dec 2011 17:41:39 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1324575692!8419607!4
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Nzk5NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14651 invoked from network); 22 Dec 2011 17:41:32 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Dec 2011 17:41:32 -0000
X-IronPort-AV: E=Sophos;i="4.71,394,1320624000"; 
   d="scan'208";a="9640551"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Dec 2011 17:41:32 +0000
Received: from andrewcoop.uk.xensource.com (10.80.2.18) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 22 Dec 2011 17:41:32 +0000
MIME-Version: 1.0
X-Mercurial-Node: 23c31d59ffb1590815bc8238d992b9a82b3dd6ec
Message-ID: <23c31d59ffb1590815bc.1324575385@andrewcoop.uk.xensource.com>
In-Reply-To: <patchbomb.1324575382@andrewcoop.uk.xensource.com>
References: <patchbomb.1324575382@andrewcoop.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.4.3
Date: Thu, 22 Dec 2011 17:36:25 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: <xen-devel@lists.xensource.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>
Subject: [Xen-devel] [PATCH 3 of 3] KEXEC: Allocate crash structures in low
	memory
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 64bit Xen with 32bit dom0 and crashkernel, xmalloc'ing items such
as the CPU crash notes will go into the xenheap, which tends to be in
upper memory.  This causes problems on machines with more than 64GB
(or 4GB if no PAE support) of ram as the crashkernel physically cant
access the crash notes.

The solution is to force Xen to allocate certain structures in lower
memory.  This is achieved by introducing two new command line
parameters; low_crashinfo and crashinfo_maxaddr.  Because of the
potential impact on 32bit PV guests, and that this problem does not
exist for 64bit dom0 on 64bit Xen, this new functionality defaults to
the codebase's previous behavior, requiring the user to explicitly
add extra command line parameters to change the behavior.

This patch consists of 3 logically distinct but closely related
changes.
 1) Add the two new command line parameters.
 2) Change crash note allocation to use lower memory when instructed.
 3) Change the conring buffer to use lower memory when instructed.

There result is that the crash notes and console ring will be placed
in lower memory so useful information can be recovered in the case of
a crash.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

diff -r 3da37c68284f -r 23c31d59ffb1 xen/arch/x86/setup.c
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -586,6 +586,10 @@ void __init __start_xen(unsigned long mb
     }
     cmdline_parse(cmdline);
 
+    /* Must be after command line argument parsing and before 
+     * allocing any xenheap structures wanted in lower memory. */
+    kexec_early_calculations();
+
     parse_video_info();
 
     set_current((struct vcpu *)0xfffff000); /* debug sanity */
diff -r 3da37c68284f -r 23c31d59ffb1 xen/common/kexec.c
--- a/xen/common/kexec.c
+++ b/xen/common/kexec.c
@@ -36,7 +36,9 @@ bool_t kexecing = FALSE;
 typedef struct { Elf_Note * start; size_t size; } crash_note_range_t;
 static crash_note_range_t * crash_notes;
 
-/* Lock to prevent race conditions when allocating the crash note buffers. */
+/* Lock to prevent race conditions when allocating the crash note buffers.
+ * It also serves to protect calls to alloc_from_crash_heap when allocating
+ * crash note buffers in lower memory. */
 static DEFINE_SPINLOCK(crash_notes_lock);
 
 static Elf_Note *xen_crash_note;
@@ -70,6 +72,23 @@ static struct {
     (_d_)->start = (_s_)->start; \
 } while (0)
 
+/* Low crashinfo mode.  Start as INVALID so serveral codepaths can set up
+ * defaults without needing to know the state of the others. */
+enum low_crashinfo low_crashinfo_mode = LOW_CRASHINFO_INVALID;
+
+/* This value is only considered if low_crash_mode is set to MIN or ALL, so
+ * setting a default here is safe. Default to 4GB.  This is because the current
+ * KEXEC_CMD_get_range compat hypercall trucates 64bit pointers to 32 bits. The
+ * typical usecase for crashinfo_maxaddr will be for 64bit Xen with 32bit dom0 
+ * and 32bit crash kernel. */
+static paddr_t crashinfo_maxaddr = 4ULL << 30;
+
+/* = log base 2 of crashinfo_maxaddr after checking for sanity. */
+paddr_t crashinfo_maxaddr_bits = 0;
+
+/* Pointers to keep track of the crash heap region. */
+static void *crash_heap_current = NULL, *crash_heap_end = NULL;
+
 /*
  * Parse command lines in the format
  *
@@ -148,6 +167,58 @@ static void __init parse_crashkernel(con
 }
 custom_param("crashkernel", parse_crashkernel);
 
+/* Parse command lines in the format:
+ *
+ *   low_crashinfo=[none,min,all]
+ * 
+ * - none disables the low allocation of crash info.
+ * - min will allocate enough low information for the crash kernel to be able
+ *       to extract the hypervisor and dom0 message ring buffers.
+ * - all will allocate additional structures such as domain and vcpu structs
+ *       low so the crash kernel can perform an extended analysis of state.
+ */
+static void __init parse_low_crashinfo(const char * str)
+{
+
+    if ( !strlen(str) )
+        /* default to min if user just specifies "low_crashinfo" */
+        low_crashinfo_mode = LOW_CRASHINFO_MIN;
+    else if ( !strcmp(str, "none" ) )
+        low_crashinfo_mode = LOW_CRASHINFO_NONE;
+    else if ( !strcmp(str, "min" ) )
+        low_crashinfo_mode = LOW_CRASHINFO_MIN;
+    else if ( !strcmp(str, "all" ) )
+        low_crashinfo_mode = LOW_CRASHINFO_ALL;
+    else
+    {
+        printk("Unknown low_crashinfo parameter '%s'.  Defaulting to min.\n", str);
+        low_crashinfo_mode = LOW_CRASHINFO_MIN;
+    }
+}
+custom_param("low_crashinfo", parse_low_crashinfo);
+
+/* Parse command lines in the format:
+ * 
+ *   crashinfo_maxaddr=<addr>
+ *
+ * <addr> will be rounded down to the nearest power of two.  Defaults to 64G
+ */
+static void __init parse_crashinfo_maxaddr(const char * str)
+{
+    u64 addr;
+
+    /* if low_crashinfo_mode is unset, default to min. */
+    if ( low_crashinfo_mode == LOW_CRASHINFO_INVALID )
+        low_crashinfo_mode = LOW_CRASHINFO_MIN;
+
+    if ( (addr = parse_size_and_unit(str, NULL)) )
+        crashinfo_maxaddr = addr;
+    else
+        printk("Unable to parse crashinfo_maxaddr. Defaulting to %p\n",
+               (void*)crashinfo_maxaddr);
+}
+custom_param("crashinfo_maxaddr", parse_crashinfo_maxaddr);
+
 void __init set_kexec_crash_area_size(u64 system_ram)
 {
     unsigned int idx;
@@ -306,6 +377,20 @@ static size_t sizeof_cpu_notes(const uns
     return bytes;
 }
 
+/* Allocate size_t bytes of space from the previously allocated
+ * crash heap if the user has requested that crash notes be allocated
+ * in lower memory.  There is currently no case where the crash notes
+ * should be free()'d. */
+static void * alloc_from_crash_heap(const size_t bytes)
+{
+    void * ret;
+    if ( crash_heap_current + bytes > crash_heap_end )
+        return NULL;
+    ret = (void*)crash_heap_current;
+    crash_heap_current += bytes;
+    return ret;
+}
+
 /* Allocate a crash note buffer for a newly onlined cpu. */
 static int kexec_init_cpu_notes(const unsigned long cpu)
 {
@@ -320,7 +405,10 @@ static int kexec_init_cpu_notes(const un
         return ret;
 
     nr_bytes = sizeof_cpu_notes(cpu);
-    note = xmalloc_bytes(nr_bytes);
+
+    /* If we dont care about the position of allocation, malloc. */
+    if ( low_crashinfo_mode == LOW_CRASHINFO_NONE )
+        note = xmalloc_bytes(nr_bytes);
 
     /* Protect the write into crash_notes[] with a spinlock, as this function
      * is on a hotplug path and a hypercall path. */
@@ -338,6 +426,11 @@ static int kexec_init_cpu_notes(const un
     }
     else
     {
+        /* If we care about memory possition, alloc from the crash heap,
+         * also protected by the crash_notes_lock. */
+        if ( low_crashinfo_mode > LOW_CRASHINFO_NONE )
+            note = alloc_from_crash_heap(nr_bytes);
+
         crash_notes[cpu].start = note;
         crash_notes[cpu].size = nr_bytes;
         spin_unlock(&crash_notes_lock);
@@ -397,6 +490,24 @@ static struct notifier_block cpu_nfb = {
     .notifier_call = cpu_callback
 };
 
+void __init kexec_early_calculations(void)
+{
+    /* If low_crashinfo_mode is still INVALID, neither "low_crashinfo" nor
+     * "crashinfo_maxaddr" have been specified on the command line, so
+     * explicitly set to NONE. */
+    if ( low_crashinfo_mode == LOW_CRASHINFO_INVALID )
+        low_crashinfo_mode = LOW_CRASHINFO_NONE;
+
+    crashinfo_maxaddr_bits = 0;
+    if ( low_crashinfo_mode > LOW_CRASHINFO_NONE )
+    {
+        paddr_t tmp = crashinfo_maxaddr;
+
+        while ( tmp >>= 1 )
+            crashinfo_maxaddr_bits++;
+    }
+}
+
 static int __init kexec_init(void)
 {
     void *cpu = (void *)(unsigned long)smp_processor_id();
@@ -407,6 +518,29 @@ static int __init kexec_init(void)
 
     register_keyhandler('C', &crashdump_trigger_keyhandler);
 
+    if ( low_crashinfo_mode > LOW_CRASHINFO_NONE )
+    {
+        size_t crash_heap_size;
+
+        /* This calculation is safe even if the machine is booted in 
+         * uniprocessor mode. */
+        crash_heap_size = sizeof_cpu_notes(0) +
+            sizeof_cpu_notes(1) * (nr_cpu_ids - 1);
+        crash_heap_size = PAGE_ALIGN(crash_heap_size);
+
+        crash_heap_current = alloc_xenheap_pages(
+            get_order_from_bytes(crash_heap_size),
+            MEMF_bits(crashinfo_maxaddr_bits) );
+
+        if ( crash_heap_current )
+            crash_heap_end = crash_heap_current + crash_heap_size;
+        else
+            return -ENOMEM;
+    }
+
+    /* crash_notes may be allocated anywhere Xen can reach in memory.
+       Only the individual CPU crash notes themselves must be allocated
+       in lower memory if requested. */
     crash_notes = xmalloc_array(crash_note_range_t, nr_cpu_ids);
     if ( ! crash_notes )
         return -ENOMEM;
diff -r 3da37c68284f -r 23c31d59ffb1 xen/drivers/char/console.c
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -584,6 +584,7 @@ void __init console_init_postirq(void)
 {
     char *ring;
     unsigned int i, order;
+    u64 memflags;
 
     serial_init_postirq();
 
@@ -591,7 +592,8 @@ void __init console_init_postirq(void)
         opt_conring_size = num_present_cpus() << (9 + xenlog_lower_thresh);
 
     order = get_order_from_bytes(max(opt_conring_size, conring_size));
-    while ( (ring = alloc_xenheap_pages(order, 0)) == NULL )
+    memflags = low_crashinfo_mode > LOW_CRASHINFO_NONE ? MEMF_bits(crashinfo_maxaddr_bits) : 0;
+    while ( (ring = alloc_xenheap_pages(order, memflags)) == NULL )
     {
         BUG_ON(order == 0);
         order--;
diff -r 3da37c68284f -r 23c31d59ffb1 xen/include/xen/kexec.h
--- a/xen/include/xen/kexec.h
+++ b/xen/include/xen/kexec.h
@@ -25,6 +25,19 @@ void set_kexec_crash_area_size(u64 syste
 #define KEXEC_IMAGE_CRASH_BASE   2
 #define KEXEC_IMAGE_NR           4
 
+enum low_crashinfo {
+    LOW_CRASHINFO_INVALID = 0,
+    LOW_CRASHINFO_NONE = 1,
+    LOW_CRASHINFO_MIN = 2,
+    LOW_CRASHINFO_ALL = 3
+};
+
+/* Low crashinfo mode.  Start as INVALID so serveral codepaths can set up
+ * defaults without needing to know the state of the others. */
+extern enum low_crashinfo low_crashinfo_mode;
+extern paddr_t crashinfo_maxaddr_bits;
+void kexec_early_calculations(void);
+
 int machine_kexec_load(int type, int slot, xen_kexec_image_t *image);
 void machine_kexec_unload(int type, int slot, xen_kexec_image_t *image);
 void machine_kexec_reserved(xen_kexec_reserve_t *reservation);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 22 17:42:09 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 Dec 2011 17: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.xensource.com>)
	id 1RdmeD-0005Cv-GQ; Thu, 22 Dec 2011 17:41:41 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1RdmeA-0005CP-Ne
	for xen-devel@lists.xensource.com; Thu, 22 Dec 2011 17:41:39 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1324575692!8419607!3
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Nzk5NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14642 invoked from network); 22 Dec 2011 17:41:32 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Dec 2011 17:41:32 -0000
X-IronPort-AV: E=Sophos;i="4.71,394,1320624000"; 
   d="scan'208";a="9640550"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Dec 2011 17:41:32 +0000
Received: from andrewcoop.uk.xensource.com (10.80.2.18) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 22 Dec 2011 17:41:32 +0000
MIME-Version: 1.0
X-Mercurial-Node: 3da37c68284f9fcf5f74812eb4b0aa59ae247186
Message-ID: <3da37c68284f9fcf5f74.1324575384@andrewcoop.uk.xensource.com>
In-Reply-To: <patchbomb.1324575382@andrewcoop.uk.xensource.com>
References: <patchbomb.1324575382@andrewcoop.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.4.3
Date: Thu, 22 Dec 2011 17:36:24 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: <xen-devel@lists.xensource.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>
Subject: [Xen-devel] [PATCH 2 of 3] KEXEC: Allocate crash notes on boot v6
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Currently, the buffers for crash notes are allocated per CPU when a
KEXEC_CMD_kexec_get_range hypercall is made, referencing the CPU in
question.

Although it certainly works in general, there are a few edge case problems:

1) There appears to be no guarentee that dom0 will make this hypercall
   for each pcpu on the system.  There appears to be variable
   behaviour depending on how many cpus dom0 is compiled for, and how
   many vcpus Xen gives to dom0.

2) The allocation of these buffers occur at the whim of dom0.  While
   this is typically very early on dom0 boot, but not guarenteed.

3) It is possible (although not sensible) for a crash
   kernel to be loaded without these (or some of these) hypercalls
   being made. Under these circumstances, a crash would cause the
   crash note code path will suffer a slew of null pointer deferences.

4) If the hypercalls are made after late in the day, it is possible
   for the hypercall to return -ENOMEM.  As code tends to be more
   fragile once memory is enhausted, the likelyhood of us needing the
   crash kernel is greater.

In addition, my forthcoming code to support 32bit kdump kernels on
64bit Xen on large (>64GB) boxes will require some guarentees as to
where the crash note buffers are actually allocated in physical
memory.  This is far easier to sort out at boot time, rather than
after dom0 has been booted and potentially using the physical memory
required.

Therefore, allocate the crash note buffers at boot time.

Changes since v5:
 *  Introduce sizeof_cpu_notes to move calculation of note size into a
    separate location.
 *  Tweak sizeof_note() to return size_t rather than int, as it is a
    function based upon sizeof().

Changes since v4:

 *  Replace the current cpu crash note scheme of using void pointers
    and hand calculating the size each time is needed, by a range
    structure containing a pointer and a size.  This removes duplicate
    times where the size is calculated.
 *  Tweak kexec_get_cpu().  Don't fail if a cpu is offline because it
    may already have crash notes, and may be up by the time a crash
    happens.  Split the error conditions up to return ERANGE for an
    out-of-range cpu request rather than EINVAL.  Finally, returning a
    range of zeros is acceptable, so do this in preference to failing.

Changes since v3:

 *  Alter the spinlocks to avoid calling xmalloc/xfree while holding
    the lock.
 *  Tidy up the coding style used.

Changes since v2:

 *  Allocate crash_notes dynamically using nr_cpu_ids at boot time,
    rather than statically using NR_CPUS.
 *  Fix the incorrect use of signed integers for cpu id.
 *  Fix collateral damage to do_crashdump_trigger() and
    crashdump_trigger_handler caused by reordering sizeof_note() and
    setup_note()
 *  Tweak the issue about returing -ENOMEM from kexec_init_cpu_note().
    No functional change.
 *  Change kexec_get_cpu() to attempt to allocate crash note buffers
    in case we have more free memory now than when the pcpu came up.
 *  Now that there are two codepaths possibly allocating crash notes,
    protect the allocation itself with a spinlock.

Changes since v1:

 *  Use cpu hotplug notifiers to handle allocating of the notes
    buffers rather than assuming the boot state of cpus will be the
    same as the crash state.
 *  Move crash_notes from being per_cpu.  This is because the kdump
    kernel elf binary put in the crash area is hard coded to physical
    addresses which the dom0 kernel typically obtains at boot time.
    If a cpu is offlined, its buffer should not be deallocated because
    the kdump kernel would read junk when trying to get the crash
    notes.  Similarly, the same problem would occur if the cpu was
    re-onlined later and its crash notes buffer was allocated elsewhere.
 *  Only attempt to allocate buffers if a crash area has been
    specified.  Else, allocating crash note buffers is a waste of
    space.  Along with this, change the test in kexec_get_cpu to
    return -EINVAL if no buffers have been allocated.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

diff -r f571dc8e4368 -r 3da37c68284f xen/common/kexec.c
--- a/xen/common/kexec.c
+++ b/xen/common/kexec.c
@@ -25,13 +25,19 @@
 #include <xen/kexec.h>
 #include <public/elfnote.h>
 #include <xsm/xsm.h>
+#include <xen/cpu.h>
 #ifdef CONFIG_COMPAT
 #include <compat/kexec.h>
 #endif
 
 bool_t kexecing = FALSE;
 
-static DEFINE_PER_CPU_READ_MOSTLY(void *, crash_notes);
+/* Memory regions to store the per cpu register state etc. on a crash. */
+typedef struct { Elf_Note * start; size_t size; } crash_note_range_t;
+static crash_note_range_t * crash_notes;
+
+/* Lock to prevent race conditions when allocating the crash note buffers. */
+static DEFINE_SPINLOCK(crash_notes_lock);
 
 static Elf_Note *xen_crash_note;
 
@@ -173,13 +179,17 @@ static void one_cpu_only(void)
 void kexec_crash_save_cpu(void)
 {
     int cpu = smp_processor_id();
-    Elf_Note *note = per_cpu(crash_notes, cpu);
+    Elf_Note *note;
     ELF_Prstatus *prstatus;
     crash_xen_core_t *xencore;
 
+    BUG_ON ( ! crash_notes );
+
     if ( cpumask_test_and_set_cpu(cpu, &crash_saved_cpus) )
         return;
 
+    note = crash_notes[cpu].start;
+
     prstatus = (ELF_Prstatus *)ELFNOTE_DESC(note);
 
     note = ELFNOTE_NEXT(note);
@@ -265,13 +275,6 @@ static struct keyhandler crashdump_trigg
     .desc = "trigger a crashdump"
 };
 
-static __init int register_crashdump_trigger(void)
-{
-    register_keyhandler('C', &crashdump_trigger_keyhandler);
-    return 0;
-}
-__initcall(register_crashdump_trigger);
-
 static void setup_note(Elf_Note *n, const char *name, int type, int descsz)
 {
     int l = strlen(name) + 1;
@@ -281,13 +284,144 @@ static void setup_note(Elf_Note *n, cons
     n->type = type;
 }
 
-static int sizeof_note(const char *name, int descsz)
+static size_t sizeof_note(const char *name, int descsz)
 {
     return (sizeof(Elf_Note) +
             ELFNOTE_ALIGN(strlen(name)+1) +
             ELFNOTE_ALIGN(descsz));
 }
 
+static size_t sizeof_cpu_notes(const unsigned long cpu)
+{
+    /* All CPUs present a PRSTATUS and crash_xen_core note. */
+    size_t bytes =
+        + sizeof_note("CORE", sizeof(ELF_Prstatus)) +
+        + sizeof_note("Xen", sizeof(crash_xen_core_t));
+
+    /* CPU0 also presents the crash_xen_info note. */
+    if ( ! cpu )
+        bytes = bytes +
+            sizeof_note("Xen", sizeof(crash_xen_info_t));
+
+    return bytes;
+}
+
+/* Allocate a crash note buffer for a newly onlined cpu. */
+static int kexec_init_cpu_notes(const unsigned long cpu)
+{
+    Elf_Note * note = NULL;
+    int ret = 0;
+    int nr_bytes = 0;
+
+    BUG_ON( cpu >= nr_cpu_ids || ! crash_notes );
+
+    /* If already allocated, nothing to do. */
+    if ( crash_notes[cpu].start )
+        return ret;
+
+    nr_bytes = sizeof_cpu_notes(cpu);
+    note = xmalloc_bytes(nr_bytes);
+
+    /* Protect the write into crash_notes[] with a spinlock, as this function
+     * is on a hotplug path and a hypercall path. */
+    spin_lock(&crash_notes_lock);
+
+    /* If we are racing with another CPU and it has beaten us, give up
+     * gracefully. */
+    if ( crash_notes[cpu].start )
+    {
+        spin_unlock(&crash_notes_lock);
+        /* Always return ok, because whether we successfully allocated or not,
+         * another CPU has successfully allocated. */
+        if ( note )
+            xfree(note);
+    }
+    else
+    {
+        crash_notes[cpu].start = note;
+        crash_notes[cpu].size = nr_bytes;
+        spin_unlock(&crash_notes_lock);
+
+        /* If the allocation failed, and another CPU did not beat us, give
+         * up with ENOMEM. */
+        if ( ! note )
+            ret = -ENOMEM;
+        /* else all is good so lets set up the notes. */
+        else
+        {
+            /* Set up CORE note. */
+            setup_note(note, "CORE", NT_PRSTATUS, sizeof(ELF_Prstatus));
+            note = ELFNOTE_NEXT(note);
+
+            /* Set up Xen CORE note. */
+            setup_note(note, "Xen", XEN_ELFNOTE_CRASH_REGS,
+                       sizeof(crash_xen_core_t));
+
+            if ( ! cpu )
+            {
+                /* Set up Xen Crash Info note. */
+                xen_crash_note = note = ELFNOTE_NEXT(note);
+                setup_note(note, "Xen", XEN_ELFNOTE_CRASH_INFO,
+                           sizeof(crash_xen_info_t));
+            }
+        }
+    }
+
+    return ret;
+}
+
+static int cpu_callback(
+    struct notifier_block *nfb, unsigned long action, void *hcpu)
+{
+    unsigned long cpu = (unsigned long)hcpu;
+
+    /* Only hook on CPU_UP_PREPARE because once a crash_note has been reported
+     * to dom0, it must keep it around in case of a crash, as the crash kernel
+     * will be hard coded to the original physical address reported. */
+    switch ( action )
+    {
+    case CPU_UP_PREPARE:
+        /* Ignore return value.  If this boot time, -ENOMEM will cause all
+         * manner of problems elsewhere very soon, and if it is during runtime,
+         * then failing to allocate crash notes is not a good enough reason to
+         * fail the CPU_UP_PREPARE */
+        kexec_init_cpu_notes(cpu);
+        break;
+    default:
+        break;
+    }
+    return NOTIFY_DONE;
+}
+
+static struct notifier_block cpu_nfb = {
+    .notifier_call = cpu_callback
+};
+
+static int __init kexec_init(void)
+{
+    void *cpu = (void *)(unsigned long)smp_processor_id();
+
+    /* If no crash area, no need to allocate space for notes. */
+    if ( !kexec_crash_area.size )
+        return 0;
+
+    register_keyhandler('C', &crashdump_trigger_keyhandler);
+
+    crash_notes = xmalloc_array(crash_note_range_t, nr_cpu_ids);
+    if ( ! crash_notes )
+        return -ENOMEM;
+
+    memset(crash_notes, 0, sizeof(crash_note_range_t) * nr_cpu_ids);
+
+    cpu_callback(&cpu_nfb, CPU_UP_PREPARE, cpu);
+    register_cpu_notifier(&cpu_nfb);
+    return 0;
+}
+/* The reason for this to be a presmp_initcall as opposed to a regular
+ * __initcall is to allow the setup of the cpu hotplug handler before APs are
+ * brought up. */
+presmp_initcall(kexec_init);
+
 static int kexec_get_reserve(xen_kexec64_range_t *range)
 {
     if ( kexec_crash_area.size > 0 && kexec_crash_area.start > 0) {
@@ -302,44 +436,29 @@ static int kexec_get_reserve(xen_kexec64
 static int kexec_get_cpu(xen_kexec64_range_t *range)
 {
     int nr = range->nr;
-    int nr_bytes = 0;
 
-    if ( nr < 0 || nr >= nr_cpu_ids || !cpu_online(nr) )
+    if ( nr < 0 || nr >= nr_cpu_ids )
+        return -ERANGE;
+
+    if ( ! crash_notes )
         return -EINVAL;
 
-    nr_bytes += sizeof_note("CORE", sizeof(ELF_Prstatus));
-    nr_bytes += sizeof_note("Xen", sizeof(crash_xen_core_t));
+    /* Try once again to allocate room for the crash notes.  It is just possible
+     * that more space has become available since we last tried.  If space has
+     * already been allocated, kexec_init_cpu_notes() will return early with 0.
+     */
+    kexec_init_cpu_notes(nr);
 
-    /* The Xen info note is included in CPU0's range. */
-    if ( nr == 0 )
-        nr_bytes += sizeof_note("Xen", sizeof(crash_xen_info_t));
+    /* In the case of still not having enough memory to allocate buffer room,
+     * returning a range of 0,0 is still valid. */
+    if ( crash_notes[nr].start )
+    {
+        range->start = __pa(crash_notes[nr].start);
+        range->size = crash_notes[nr].size;
+    }
+    else
+        range->start = range->size = 0;
 
-    if ( per_cpu(crash_notes, nr) == NULL )
-    {
-        Elf_Note *note;
-
-        note = per_cpu(crash_notes, nr) = xmalloc_bytes(nr_bytes);
-
-        if ( note == NULL )
-            return -ENOMEM;
-
-        /* Setup CORE note. */
-        setup_note(note, "CORE", NT_PRSTATUS, sizeof(ELF_Prstatus));
-
-        /* Setup Xen CORE note. */
-        note = ELFNOTE_NEXT(note);
-        setup_note(note, "Xen", XEN_ELFNOTE_CRASH_REGS, sizeof(crash_xen_core_t));
-
-        if (nr == 0)
-        {
-            /* Setup system wide Xen info note. */
-            xen_crash_note = note = ELFNOTE_NEXT(note);
-            setup_note(note, "Xen", XEN_ELFNOTE_CRASH_INFO, sizeof(crash_xen_info_t));
-        }
-    }
-
-    range->start = __pa((unsigned long)per_cpu(crash_notes, nr));
-    range->size = nr_bytes;
     return 0;
 }
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 22 17:42:09 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 Dec 2011 17: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.xensource.com>)
	id 1RdmeD-0005Cv-GQ; Thu, 22 Dec 2011 17:41:41 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1RdmeA-0005CP-Ne
	for xen-devel@lists.xensource.com; Thu, 22 Dec 2011 17:41:39 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1324575692!8419607!3
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Nzk5NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14642 invoked from network); 22 Dec 2011 17:41:32 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Dec 2011 17:41:32 -0000
X-IronPort-AV: E=Sophos;i="4.71,394,1320624000"; 
   d="scan'208";a="9640550"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Dec 2011 17:41:32 +0000
Received: from andrewcoop.uk.xensource.com (10.80.2.18) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 22 Dec 2011 17:41:32 +0000
MIME-Version: 1.0
X-Mercurial-Node: 3da37c68284f9fcf5f74812eb4b0aa59ae247186
Message-ID: <3da37c68284f9fcf5f74.1324575384@andrewcoop.uk.xensource.com>
In-Reply-To: <patchbomb.1324575382@andrewcoop.uk.xensource.com>
References: <patchbomb.1324575382@andrewcoop.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.4.3
Date: Thu, 22 Dec 2011 17:36:24 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: <xen-devel@lists.xensource.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>
Subject: [Xen-devel] [PATCH 2 of 3] KEXEC: Allocate crash notes on boot v6
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Currently, the buffers for crash notes are allocated per CPU when a
KEXEC_CMD_kexec_get_range hypercall is made, referencing the CPU in
question.

Although it certainly works in general, there are a few edge case problems:

1) There appears to be no guarentee that dom0 will make this hypercall
   for each pcpu on the system.  There appears to be variable
   behaviour depending on how many cpus dom0 is compiled for, and how
   many vcpus Xen gives to dom0.

2) The allocation of these buffers occur at the whim of dom0.  While
   this is typically very early on dom0 boot, but not guarenteed.

3) It is possible (although not sensible) for a crash
   kernel to be loaded without these (or some of these) hypercalls
   being made. Under these circumstances, a crash would cause the
   crash note code path will suffer a slew of null pointer deferences.

4) If the hypercalls are made after late in the day, it is possible
   for the hypercall to return -ENOMEM.  As code tends to be more
   fragile once memory is enhausted, the likelyhood of us needing the
   crash kernel is greater.

In addition, my forthcoming code to support 32bit kdump kernels on
64bit Xen on large (>64GB) boxes will require some guarentees as to
where the crash note buffers are actually allocated in physical
memory.  This is far easier to sort out at boot time, rather than
after dom0 has been booted and potentially using the physical memory
required.

Therefore, allocate the crash note buffers at boot time.

Changes since v5:
 *  Introduce sizeof_cpu_notes to move calculation of note size into a
    separate location.
 *  Tweak sizeof_note() to return size_t rather than int, as it is a
    function based upon sizeof().

Changes since v4:

 *  Replace the current cpu crash note scheme of using void pointers
    and hand calculating the size each time is needed, by a range
    structure containing a pointer and a size.  This removes duplicate
    times where the size is calculated.
 *  Tweak kexec_get_cpu().  Don't fail if a cpu is offline because it
    may already have crash notes, and may be up by the time a crash
    happens.  Split the error conditions up to return ERANGE for an
    out-of-range cpu request rather than EINVAL.  Finally, returning a
    range of zeros is acceptable, so do this in preference to failing.

Changes since v3:

 *  Alter the spinlocks to avoid calling xmalloc/xfree while holding
    the lock.
 *  Tidy up the coding style used.

Changes since v2:

 *  Allocate crash_notes dynamically using nr_cpu_ids at boot time,
    rather than statically using NR_CPUS.
 *  Fix the incorrect use of signed integers for cpu id.
 *  Fix collateral damage to do_crashdump_trigger() and
    crashdump_trigger_handler caused by reordering sizeof_note() and
    setup_note()
 *  Tweak the issue about returing -ENOMEM from kexec_init_cpu_note().
    No functional change.
 *  Change kexec_get_cpu() to attempt to allocate crash note buffers
    in case we have more free memory now than when the pcpu came up.
 *  Now that there are two codepaths possibly allocating crash notes,
    protect the allocation itself with a spinlock.

Changes since v1:

 *  Use cpu hotplug notifiers to handle allocating of the notes
    buffers rather than assuming the boot state of cpus will be the
    same as the crash state.
 *  Move crash_notes from being per_cpu.  This is because the kdump
    kernel elf binary put in the crash area is hard coded to physical
    addresses which the dom0 kernel typically obtains at boot time.
    If a cpu is offlined, its buffer should not be deallocated because
    the kdump kernel would read junk when trying to get the crash
    notes.  Similarly, the same problem would occur if the cpu was
    re-onlined later and its crash notes buffer was allocated elsewhere.
 *  Only attempt to allocate buffers if a crash area has been
    specified.  Else, allocating crash note buffers is a waste of
    space.  Along with this, change the test in kexec_get_cpu to
    return -EINVAL if no buffers have been allocated.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

diff -r f571dc8e4368 -r 3da37c68284f xen/common/kexec.c
--- a/xen/common/kexec.c
+++ b/xen/common/kexec.c
@@ -25,13 +25,19 @@
 #include <xen/kexec.h>
 #include <public/elfnote.h>
 #include <xsm/xsm.h>
+#include <xen/cpu.h>
 #ifdef CONFIG_COMPAT
 #include <compat/kexec.h>
 #endif
 
 bool_t kexecing = FALSE;
 
-static DEFINE_PER_CPU_READ_MOSTLY(void *, crash_notes);
+/* Memory regions to store the per cpu register state etc. on a crash. */
+typedef struct { Elf_Note * start; size_t size; } crash_note_range_t;
+static crash_note_range_t * crash_notes;
+
+/* Lock to prevent race conditions when allocating the crash note buffers. */
+static DEFINE_SPINLOCK(crash_notes_lock);
 
 static Elf_Note *xen_crash_note;
 
@@ -173,13 +179,17 @@ static void one_cpu_only(void)
 void kexec_crash_save_cpu(void)
 {
     int cpu = smp_processor_id();
-    Elf_Note *note = per_cpu(crash_notes, cpu);
+    Elf_Note *note;
     ELF_Prstatus *prstatus;
     crash_xen_core_t *xencore;
 
+    BUG_ON ( ! crash_notes );
+
     if ( cpumask_test_and_set_cpu(cpu, &crash_saved_cpus) )
         return;
 
+    note = crash_notes[cpu].start;
+
     prstatus = (ELF_Prstatus *)ELFNOTE_DESC(note);
 
     note = ELFNOTE_NEXT(note);
@@ -265,13 +275,6 @@ static struct keyhandler crashdump_trigg
     .desc = "trigger a crashdump"
 };
 
-static __init int register_crashdump_trigger(void)
-{
-    register_keyhandler('C', &crashdump_trigger_keyhandler);
-    return 0;
-}
-__initcall(register_crashdump_trigger);
-
 static void setup_note(Elf_Note *n, const char *name, int type, int descsz)
 {
     int l = strlen(name) + 1;
@@ -281,13 +284,144 @@ static void setup_note(Elf_Note *n, cons
     n->type = type;
 }
 
-static int sizeof_note(const char *name, int descsz)
+static size_t sizeof_note(const char *name, int descsz)
 {
     return (sizeof(Elf_Note) +
             ELFNOTE_ALIGN(strlen(name)+1) +
             ELFNOTE_ALIGN(descsz));
 }
 
+static size_t sizeof_cpu_notes(const unsigned long cpu)
+{
+    /* All CPUs present a PRSTATUS and crash_xen_core note. */
+    size_t bytes =
+        + sizeof_note("CORE", sizeof(ELF_Prstatus)) +
+        + sizeof_note("Xen", sizeof(crash_xen_core_t));
+
+    /* CPU0 also presents the crash_xen_info note. */
+    if ( ! cpu )
+        bytes = bytes +
+            sizeof_note("Xen", sizeof(crash_xen_info_t));
+
+    return bytes;
+}
+
+/* Allocate a crash note buffer for a newly onlined cpu. */
+static int kexec_init_cpu_notes(const unsigned long cpu)
+{
+    Elf_Note * note = NULL;
+    int ret = 0;
+    int nr_bytes = 0;
+
+    BUG_ON( cpu >= nr_cpu_ids || ! crash_notes );
+
+    /* If already allocated, nothing to do. */
+    if ( crash_notes[cpu].start )
+        return ret;
+
+    nr_bytes = sizeof_cpu_notes(cpu);
+    note = xmalloc_bytes(nr_bytes);
+
+    /* Protect the write into crash_notes[] with a spinlock, as this function
+     * is on a hotplug path and a hypercall path. */
+    spin_lock(&crash_notes_lock);
+
+    /* If we are racing with another CPU and it has beaten us, give up
+     * gracefully. */
+    if ( crash_notes[cpu].start )
+    {
+        spin_unlock(&crash_notes_lock);
+        /* Always return ok, because whether we successfully allocated or not,
+         * another CPU has successfully allocated. */
+        if ( note )
+            xfree(note);
+    }
+    else
+    {
+        crash_notes[cpu].start = note;
+        crash_notes[cpu].size = nr_bytes;
+        spin_unlock(&crash_notes_lock);
+
+        /* If the allocation failed, and another CPU did not beat us, give
+         * up with ENOMEM. */
+        if ( ! note )
+            ret = -ENOMEM;
+        /* else all is good so lets set up the notes. */
+        else
+        {
+            /* Set up CORE note. */
+            setup_note(note, "CORE", NT_PRSTATUS, sizeof(ELF_Prstatus));
+            note = ELFNOTE_NEXT(note);
+
+            /* Set up Xen CORE note. */
+            setup_note(note, "Xen", XEN_ELFNOTE_CRASH_REGS,
+                       sizeof(crash_xen_core_t));
+
+            if ( ! cpu )
+            {
+                /* Set up Xen Crash Info note. */
+                xen_crash_note = note = ELFNOTE_NEXT(note);
+                setup_note(note, "Xen", XEN_ELFNOTE_CRASH_INFO,
+                           sizeof(crash_xen_info_t));
+            }
+        }
+    }
+
+    return ret;
+}
+
+static int cpu_callback(
+    struct notifier_block *nfb, unsigned long action, void *hcpu)
+{
+    unsigned long cpu = (unsigned long)hcpu;
+
+    /* Only hook on CPU_UP_PREPARE because once a crash_note has been reported
+     * to dom0, it must keep it around in case of a crash, as the crash kernel
+     * will be hard coded to the original physical address reported. */
+    switch ( action )
+    {
+    case CPU_UP_PREPARE:
+        /* Ignore return value.  If this boot time, -ENOMEM will cause all
+         * manner of problems elsewhere very soon, and if it is during runtime,
+         * then failing to allocate crash notes is not a good enough reason to
+         * fail the CPU_UP_PREPARE */
+        kexec_init_cpu_notes(cpu);
+        break;
+    default:
+        break;
+    }
+    return NOTIFY_DONE;
+}
+
+static struct notifier_block cpu_nfb = {
+    .notifier_call = cpu_callback
+};
+
+static int __init kexec_init(void)
+{
+    void *cpu = (void *)(unsigned long)smp_processor_id();
+
+    /* If no crash area, no need to allocate space for notes. */
+    if ( !kexec_crash_area.size )
+        return 0;
+
+    register_keyhandler('C', &crashdump_trigger_keyhandler);
+
+    crash_notes = xmalloc_array(crash_note_range_t, nr_cpu_ids);
+    if ( ! crash_notes )
+        return -ENOMEM;
+
+    memset(crash_notes, 0, sizeof(crash_note_range_t) * nr_cpu_ids);
+
+    cpu_callback(&cpu_nfb, CPU_UP_PREPARE, cpu);
+    register_cpu_notifier(&cpu_nfb);
+    return 0;
+}
+/* The reason for this to be a presmp_initcall as opposed to a regular
+ * __initcall is to allow the setup of the cpu hotplug handler before APs are
+ * brought up. */
+presmp_initcall(kexec_init);
+
 static int kexec_get_reserve(xen_kexec64_range_t *range)
 {
     if ( kexec_crash_area.size > 0 && kexec_crash_area.start > 0) {
@@ -302,44 +436,29 @@ static int kexec_get_reserve(xen_kexec64
 static int kexec_get_cpu(xen_kexec64_range_t *range)
 {
     int nr = range->nr;
-    int nr_bytes = 0;
 
-    if ( nr < 0 || nr >= nr_cpu_ids || !cpu_online(nr) )
+    if ( nr < 0 || nr >= nr_cpu_ids )
+        return -ERANGE;
+
+    if ( ! crash_notes )
         return -EINVAL;
 
-    nr_bytes += sizeof_note("CORE", sizeof(ELF_Prstatus));
-    nr_bytes += sizeof_note("Xen", sizeof(crash_xen_core_t));
+    /* Try once again to allocate room for the crash notes.  It is just possible
+     * that more space has become available since we last tried.  If space has
+     * already been allocated, kexec_init_cpu_notes() will return early with 0.
+     */
+    kexec_init_cpu_notes(nr);
 
-    /* The Xen info note is included in CPU0's range. */
-    if ( nr == 0 )
-        nr_bytes += sizeof_note("Xen", sizeof(crash_xen_info_t));
+    /* In the case of still not having enough memory to allocate buffer room,
+     * returning a range of 0,0 is still valid. */
+    if ( crash_notes[nr].start )
+    {
+        range->start = __pa(crash_notes[nr].start);
+        range->size = crash_notes[nr].size;
+    }
+    else
+        range->start = range->size = 0;
 
-    if ( per_cpu(crash_notes, nr) == NULL )
-    {
-        Elf_Note *note;
-
-        note = per_cpu(crash_notes, nr) = xmalloc_bytes(nr_bytes);
-
-        if ( note == NULL )
-            return -ENOMEM;
-
-        /* Setup CORE note. */
-        setup_note(note, "CORE", NT_PRSTATUS, sizeof(ELF_Prstatus));
-
-        /* Setup Xen CORE note. */
-        note = ELFNOTE_NEXT(note);
-        setup_note(note, "Xen", XEN_ELFNOTE_CRASH_REGS, sizeof(crash_xen_core_t));
-
-        if (nr == 0)
-        {
-            /* Setup system wide Xen info note. */
-            xen_crash_note = note = ELFNOTE_NEXT(note);
-            setup_note(note, "Xen", XEN_ELFNOTE_CRASH_INFO, sizeof(crash_xen_info_t));
-        }
-    }
-
-    range->start = __pa((unsigned long)per_cpu(crash_notes, nr));
-    range->size = nr_bytes;
     return 0;
 }
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 22 17:42:09 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 Dec 2011 17: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.xensource.com>)
	id 1RdmeC-0005Co-Q8; Thu, 22 Dec 2011 17:41:40 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1RdmeA-0005CO-JE
	for xen-devel@lists.xensource.com; Thu, 22 Dec 2011 17:41:39 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1324575692!8419607!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Nzk5NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14637 invoked from network); 22 Dec 2011 17:41:32 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Dec 2011 17:41:32 -0000
X-IronPort-AV: E=Sophos;i="4.71,394,1320624000"; 
   d="scan'208";a="9640549"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Dec 2011 17:41:32 +0000
Received: from andrewcoop.uk.xensource.com (10.80.2.18) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 22 Dec 2011 17:41:32 +0000
MIME-Version: 1.0
X-Mercurial-Node: f571dc8e43687c6027d11f356cf0904a4674d7ba
Message-ID: <f571dc8e43687c6027d1.1324575383@andrewcoop.uk.xensource.com>
In-Reply-To: <patchbomb.1324575382@andrewcoop.uk.xensource.com>
References: <patchbomb.1324575382@andrewcoop.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.4.3
Date: Thu, 22 Dec 2011 17:36:23 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: <xen-devel@lists.xensource.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>
Subject: [Xen-devel] [PATCH 1 of 3] KEXEC: Add new hypercall to fix 64/32bit
	truncation	errors. v2
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Currently, KEXEC_CMD_kexec_get_range in compat mode, or with 32bit
Xen, will truncate 64bit pointers to 32bits, leading to problems on
machines with more than 4GiB of RAM.  As 32bit dom0 kernels tend to be
PAE capable, this is especially wasteful, as most structures currently
limited to <4GiB could easily be <64GiB instead.

Therefore, introduce a new hypercall 'KEXEC_CMD_kexec64_get_range'
which passes similar information as KEXEC_CMD_kexec_get_range, but
which uses a structure with explicitly specified field widths, causing
it to be identical in the compat and regular case.  This new
structure, xen_kexec64_range_t, will be the same as xen_kexec_range_t
if Xen is compiled for x86_64, but will still use 64bit integers if
Xen is compiled for x86_32.

To fix 32bit Xen which uses 32bit integers for addresses and sizes,
change the internals to use xen_kexec64_range_t which will use 64bit
integers instead.  This also involves changing several casts to
explicitly use uint64_ts rather than unsigned longs.

In addition, the hypercall entry points need updating to be able to
cater for all possibilities.

|Xen/dom0 bits|          Bit width of addresses in structure for        |
+------+------+---------------------------+-----------------------------+
| Xen  | dom0 | KEXEC_CMD_kexec_get_range | KEXEC_CMD_kexec64_get_range |
+------+------+---------------------------+-----------------------------+
|  32  |  32  |             32            |              64             |
|  64  |  32  |             32            |              64             |
|  64  |  64  |             64            |              64             |
+------+------+---------------------------+-----------------------------+

This has been solved by splitting do_kexec_op_internal back into
do_kexec_op{,_compat} and changing kexec_get_range{,_compat} to
kexec_get_range{32,64} which now exist irrespective of CONFIG_COMPAT
or not.

The knock-on effect of removing do_kexec_op_internal means that
kexec_load_unload_compat is only ever called from inside an #ifdef
CONFIG_COMPAT codepath, which does not exist on Xen x86_32.
Therefore, move the #ifdef CONFIG_COMPAT guards to include the entire
function.

Finally, and a little unrelatedly, fix KEXEC_CMD_kexec_{load,unload}
to return -EBUSY instead of EOK if a kexec is in progress.

Changes since v1:
 *  Fix check for pointer truncation to work when Xen is compiled for
    32 bit mode as well.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

diff -r e56500f95b6a -r f571dc8e4368 xen/arch/ia64/xen/machine_kexec.c
--- a/xen/arch/ia64/xen/machine_kexec.c
+++ b/xen/arch/ia64/xen/machine_kexec.c
@@ -102,10 +102,10 @@ void machine_reboot_kexec(xen_kexec_imag
 	machine_kexec(image);
 }
 
-int machine_kexec_get_xen(xen_kexec_range_t *range)
+int machine_kexec_get_xen(xen_kexec64_range_t *range)
 {
 	range->start = ia64_tpa(_text);
-	range->size = (unsigned long)_end - (unsigned long)_text;
+	range->size = (uint64_t)_end - (uint64_t)_text;
 	return 0;
 }
 
@@ -113,31 +113,31 @@ int machine_kexec_get_xen(xen_kexec_rang
 #define ELF_PAGE_SIZE  (__IA64_UL_CONST(1) << ELF_PAGE_SHIFT)
 #define ELF_PAGE_MASK  (~(ELF_PAGE_SIZE - 1))
 
-static int machine_kexec_get_xenheap(xen_kexec_range_t *range)
+static int machine_kexec_get_xenheap(xen_kexec64_range_t *range)
 {
 	range->start = (ia64_tpa(_end) + (ELF_PAGE_SIZE - 1)) & ELF_PAGE_MASK;
 	range->size =
-		(((unsigned long)range->start + KERNEL_TR_PAGE_SIZE) &
+		(((uint64_t)range->start + KERNEL_TR_PAGE_SIZE) &
          ~(KERNEL_TR_PAGE_SIZE - 1))
-		- (unsigned long)range->start;
+		- (uint64_t)range->start;
 	return 0;
 }
 
-static int machine_kexec_get_boot_param(xen_kexec_range_t *range)
+static int machine_kexec_get_boot_param(xen_kexec64_range_t *range)
 {
 	range->start = __pa(ia64_boot_param);
 	range->size = sizeof(*ia64_boot_param);
 	return 0;
 }
 
-static int machine_kexec_get_efi_memmap(xen_kexec_range_t *range)
+static int machine_kexec_get_efi_memmap(xen_kexec64_range_t *range)
 {
 	range->start = ia64_boot_param->efi_memmap;
 	range->size = ia64_boot_param->efi_memmap_size;
 	return 0;
 }
 
-int machine_kexec_get(xen_kexec_range_t *range)
+int machine_kexec_get(xen_kexec64_range_t *range)
 {
 	switch (range->range) {
 	case KEXEC_RANGE_MA_XEN:
diff -r e56500f95b6a -r f571dc8e4368 xen/arch/x86/machine_kexec.c
--- a/xen/arch/x86/machine_kexec.c
+++ b/xen/arch/x86/machine_kexec.c
@@ -120,7 +120,7 @@ void machine_kexec(xen_kexec_image_t *im
     }
 }
 
-int machine_kexec_get(xen_kexec_range_t *range)
+int machine_kexec_get(xen_kexec64_range_t *range)
 {
 	if (range->range != KEXEC_RANGE_MA_XEN)
 		return -EINVAL;
diff -r e56500f95b6a -r f571dc8e4368 xen/arch/x86/x86_32/machine_kexec.c
--- a/xen/arch/x86/x86_32/machine_kexec.c
+++ b/xen/arch/x86/x86_32/machine_kexec.c
@@ -11,11 +11,11 @@
 #include <asm/page.h>
 #include <public/kexec.h>
 
-int machine_kexec_get_xen(xen_kexec_range_t *range)
+int machine_kexec_get_xen(xen_kexec64_range_t *range)
 {
         range->start = virt_to_maddr(_start);
-        range->size = (unsigned long)xenheap_phys_end -
-                      (unsigned long)range->start;
+        range->size = (uint64_t)xenheap_phys_end -
+                      (uint64_t)range->start;
         return 0;
 }
 
diff -r e56500f95b6a -r f571dc8e4368 xen/arch/x86/x86_64/machine_kexec.c
--- a/xen/arch/x86/x86_64/machine_kexec.c
+++ b/xen/arch/x86/x86_64/machine_kexec.c
@@ -11,10 +11,10 @@
 #include <asm/page.h>
 #include <public/kexec.h>
 
-int machine_kexec_get_xen(xen_kexec_range_t *range)
+int machine_kexec_get_xen(xen_kexec64_range_t *range)
 {
         range->start = virt_to_maddr(_start);
-        range->size = virt_to_maddr(_end) - (unsigned long)range->start;
+        range->size = virt_to_maddr(_end) - (uint64_t)range->start;
         return 0;
 }
 
diff -r e56500f95b6a -r f571dc8e4368 xen/common/kexec.c
--- a/xen/common/kexec.c
+++ b/xen/common/kexec.c
@@ -56,6 +56,14 @@ static struct {
     unsigned long size;
 } ranges[16] __initdata;
 
+/* This XLAT macro is required now even without CONFIG_COMPAT. */
+#define TRANSLATE_kexec_range(_d_, _s_) do { \
+    (_d_)->range = (_s_)->range; \
+    (_d_)->nr = (_s_)->nr; \
+    (_d_)->size = (_s_)->size; \
+    (_d_)->start = (_s_)->start; \
+} while (0)
+
 /*
  * Parse command lines in the format
  *
@@ -280,7 +288,7 @@ static int sizeof_note(const char *name,
             ELFNOTE_ALIGN(descsz));
 }
 
-static int kexec_get_reserve(xen_kexec_range_t *range)
+static int kexec_get_reserve(xen_kexec64_range_t *range)
 {
     if ( kexec_crash_area.size > 0 && kexec_crash_area.start > 0) {
         range->start = kexec_crash_area.start;
@@ -291,7 +299,7 @@ static int kexec_get_reserve(xen_kexec_r
     return 0;
 }
 
-static int kexec_get_cpu(xen_kexec_range_t *range)
+static int kexec_get_cpu(xen_kexec64_range_t *range)
 {
     int nr = range->nr;
     int nr_bytes = 0;
@@ -335,14 +343,14 @@ static int kexec_get_cpu(xen_kexec_range
     return 0;
 }
 
-static int kexec_get_vmcoreinfo(xen_kexec_range_t *range)
+static int kexec_get_vmcoreinfo(xen_kexec64_range_t *range)
 {
     range->start = __pa((unsigned long)vmcoreinfo_data);
     range->size = VMCOREINFO_BYTES;
     return 0;
 }
 
-static int kexec_get_range_internal(xen_kexec_range_t *range)
+static int kexec_get_range_internal(xen_kexec64_range_t *range)
 {
     int ret = -EINVAL;
 
@@ -365,9 +373,14 @@ static int kexec_get_range_internal(xen_
     return ret;
 }
 
-static int kexec_get_range(XEN_GUEST_HANDLE(void) uarg)
+/* This function can be invoked from either a KEXEC_CMD_kexec64_get_range
+ * hypercall, or from a KEXEC_CMD_kexec_get_range hypercall with 64bit dom0
+ * on 64bit Xen.  In the first case, the guest structure is a 
+ * xen_kexec64_range_t, and in the second case, the xen_kexec_range_t guest
+ * structure is identical to xen_kexec64_range_t. */
+static int kexec_get_range64(XEN_GUEST_HANDLE(void) uarg)
 {
-    xen_kexec_range_t range;
+    xen_kexec64_range_t range;
     int ret = -EINVAL;
 
     if ( unlikely(copy_from_guest(&range, uarg, 1)) )
@@ -381,34 +394,40 @@ static int kexec_get_range(XEN_GUEST_HAN
     return ret;
 }
 
-static int kexec_get_range_compat(XEN_GUEST_HANDLE(void) uarg)
+/* This function can be invoked from either a KEXEC_CMD_kexec_get_range
+ * compat hypercall for 32bit dom0 on 64bit Xen, or from the same hypercall
+ * on 32bit Xen.  In both cases, the guest argument uses 32bit integers, so 
+ * translate them to 64bit for use by kexec_get_range_internal.  The
+ * preprocessor guards are to choose the correct 32bit structure, as the
+ * compat_* structures dont exist in 32bit Xen. */
+static int kexec_get_range32(XEN_GUEST_HANDLE(void) uarg)
 {
+    xen_kexec64_range_t range64;
 #ifdef CONFIG_COMPAT
-    xen_kexec_range_t range;
-    compat_kexec_range_t compat_range;
+    compat_kexec_range_t range32;
+#else
+    xen_kexec_range_t range32;
+#endif
     int ret = -EINVAL;
 
-    if ( unlikely(copy_from_guest(&compat_range, uarg, 1)) )
+    if ( unlikely(copy_from_guest(&range32, uarg, 1)) )
         return -EFAULT;
 
-    XLAT_kexec_range(&range, &compat_range);
+    TRANSLATE_kexec_range(&range64, &range32);
 
-    ret = kexec_get_range_internal(&range);
+    ret = kexec_get_range_internal(&range64);
 
     /* Dont silently truncate physical addresses or sizes. */
-    if ( (range.start | range.size) & ~(unsigned long)(~0u) )
+    if ( (range64.start | range64.size) & 0xffffffff00000000ULL )
         return -ERANGE;
 
     if ( ret == 0 ) {
-        XLAT_kexec_range(&compat_range, &range);
-        if ( unlikely(copy_to_guest(uarg, &compat_range, 1)) )
+        TRANSLATE_kexec_range(&range32, &range64);
+        if ( unlikely(copy_to_guest(uarg, &range32, 1)) )
              return -EFAULT;
     }
 
     return ret;
-#else /* CONFIG_COMPAT */
-    return 0;
-#endif /* CONFIG_COMPAT */
 }
 
 static int kexec_load_get_bits(int type, int *base, int *bit)
@@ -543,10 +562,10 @@ static int kexec_load_unload(unsigned lo
     return kexec_load_unload_internal(op, &load);
 }
 
+#ifdef CONFIG_COMPAT
 static int kexec_load_unload_compat(unsigned long op,
                                     XEN_GUEST_HANDLE(void) uarg)
 {
-#ifdef CONFIG_COMPAT
     compat_kexec_load_t compat_load;
     xen_kexec_load_t load;
 
@@ -564,10 +583,8 @@ static int kexec_load_unload_compat(unsi
     XLAT_kexec_image(&load.image, &compat_load.image);
 
     return kexec_load_unload_internal(op, &load);
-#else /* CONFIG_COMPAT */
-    return 0;
+}
 #endif /* CONFIG_COMPAT */
-}
 
 static int kexec_exec(XEN_GUEST_HANDLE(void) uarg)
 {
@@ -601,8 +618,51 @@ static int kexec_exec(XEN_GUEST_HANDLE(v
     return -EINVAL; /* never reached */
 }
 
-int do_kexec_op_internal(unsigned long op, XEN_GUEST_HANDLE(void) uarg,
-                           int compat)
+long do_kexec_op(unsigned long op, XEN_GUEST_HANDLE(void) uarg)
+{
+    unsigned long flags;
+    int ret = -EINVAL;
+
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+
+    ret = xsm_kexec();
+    if ( ret )
+        return ret;
+
+    switch ( op )
+    {
+#ifdef __i386__
+    case KEXEC_CMD_kexec_get_range:
+        ret = kexec_get_range32(uarg);
+        break;
+#else
+    case KEXEC_CMD_kexec_get_range:
+#endif
+    case KEXEC_CMD_kexec64_get_range:
+        ret = kexec_get_range64(uarg);
+        break;
+
+    case KEXEC_CMD_kexec_load:
+    case KEXEC_CMD_kexec_unload:
+        spin_lock_irqsave(&kexec_lock, flags);
+        if (!test_bit(KEXEC_FLAG_IN_PROGRESS, &kexec_flags))
+            ret = kexec_load_unload(op, uarg);
+        else
+            ret = -EBUSY;
+        spin_unlock_irqrestore(&kexec_lock, flags);
+        break;
+
+    case KEXEC_CMD_kexec:
+        ret = kexec_exec(uarg);
+        break;
+    }
+
+    return ret;
+}
+
+#ifdef CONFIG_COMPAT
+int compat_kexec_op(unsigned long op, XEN_GUEST_HANDLE(void) uarg)
 {
     unsigned long flags;
     int ret = -EINVAL;
@@ -617,23 +677,21 @@ int do_kexec_op_internal(unsigned long o
     switch ( op )
     {
     case KEXEC_CMD_kexec_get_range:
-        if (compat)
-                ret = kexec_get_range_compat(uarg);
-        else
-                ret = kexec_get_range(uarg);
+        ret = kexec_get_range32(uarg);
+        break;
+    case KEXEC_CMD_kexec64_get_range:
+        ret = kexec_get_range64(uarg);
         break;
     case KEXEC_CMD_kexec_load:
     case KEXEC_CMD_kexec_unload:
         spin_lock_irqsave(&kexec_lock, flags);
         if (!test_bit(KEXEC_FLAG_IN_PROGRESS, &kexec_flags))
-        {
-                if (compat)
-                        ret = kexec_load_unload_compat(op, uarg);
-                else
-                        ret = kexec_load_unload(op, uarg);
-        }
+            ret = kexec_load_unload_compat(op, uarg);
+        else
+            ret = -EBUSY;
         spin_unlock_irqrestore(&kexec_lock, flags);
         break;
+
     case KEXEC_CMD_kexec:
         ret = kexec_exec(uarg);
         break;
@@ -641,17 +699,6 @@ int do_kexec_op_internal(unsigned long o
 
     return ret;
 }
-
-long do_kexec_op(unsigned long op, XEN_GUEST_HANDLE(void) uarg)
-{
-    return do_kexec_op_internal(op, uarg, 0);
-}
-
-#ifdef CONFIG_COMPAT
-int compat_kexec_op(unsigned long op, XEN_GUEST_HANDLE(void) uarg)
-{
-    return do_kexec_op_internal(op, uarg, 1);
-}
 #endif
 
 /*
diff -r e56500f95b6a -r f571dc8e4368 xen/include/public/kexec.h
--- a/xen/include/public/kexec.h
+++ b/xen/include/public/kexec.h
@@ -155,6 +155,15 @@ typedef struct xen_kexec_range {
     unsigned long start;
 } xen_kexec_range_t;
 
+#define KEXEC_CMD_kexec64_get_range      4
+/* xen_kexec_range_t using explicit sizes for fields. */
+typedef struct xen_kexec64_range {
+    int32_t range;
+    int32_t nr;
+    uint64_t size;
+    uint64_t start;
+} xen_kexec64_range_t;
+
 #endif /* _XEN_PUBLIC_KEXEC_H */
 
 /*
diff -r e56500f95b6a -r f571dc8e4368 xen/include/xen/kexec.h
--- a/xen/include/xen/kexec.h
+++ b/xen/include/xen/kexec.h
@@ -34,8 +34,8 @@ void kexec_crash(void);
 void kexec_crash_save_cpu(void);
 crash_xen_info_t *kexec_crash_save_info(void);
 void machine_crash_shutdown(void);
-int machine_kexec_get(xen_kexec_range_t *range);
-int machine_kexec_get_xen(xen_kexec_range_t *range);
+int machine_kexec_get(xen_kexec64_range_t *range);
+int machine_kexec_get_xen(xen_kexec64_range_t *range);
 
 void compat_machine_kexec(unsigned long rnk,
                           unsigned long indirection_page,
diff -r e56500f95b6a -r f571dc8e4368 xen/include/xlat.lst
--- a/xen/include/xlat.lst
+++ b/xen/include/xlat.lst
@@ -50,9 +50,7 @@
 ?	grant_entry_v1			grant_table.h
 ?       grant_entry_header              grant_table.h
 ?	grant_entry_v2			grant_table.h
-?	kexec_exec			kexec.h
 !	kexec_image			kexec.h
-!	kexec_range			kexec.h
 !	add_to_physmap			memory.h
 !	foreign_memory_map		memory.h
 !	memory_exchange			memory.h

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 22 17:42:09 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 Dec 2011 17: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.xensource.com>)
	id 1RdmeC-0005Co-Q8; Thu, 22 Dec 2011 17:41:40 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1RdmeA-0005CO-JE
	for xen-devel@lists.xensource.com; Thu, 22 Dec 2011 17:41:39 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1324575692!8419607!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Nzk5NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14637 invoked from network); 22 Dec 2011 17:41:32 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Dec 2011 17:41:32 -0000
X-IronPort-AV: E=Sophos;i="4.71,394,1320624000"; 
   d="scan'208";a="9640549"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Dec 2011 17:41:32 +0000
Received: from andrewcoop.uk.xensource.com (10.80.2.18) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 22 Dec 2011 17:41:32 +0000
MIME-Version: 1.0
X-Mercurial-Node: f571dc8e43687c6027d11f356cf0904a4674d7ba
Message-ID: <f571dc8e43687c6027d1.1324575383@andrewcoop.uk.xensource.com>
In-Reply-To: <patchbomb.1324575382@andrewcoop.uk.xensource.com>
References: <patchbomb.1324575382@andrewcoop.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.4.3
Date: Thu, 22 Dec 2011 17:36:23 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: <xen-devel@lists.xensource.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>
Subject: [Xen-devel] [PATCH 1 of 3] KEXEC: Add new hypercall to fix 64/32bit
	truncation	errors. v2
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Currently, KEXEC_CMD_kexec_get_range in compat mode, or with 32bit
Xen, will truncate 64bit pointers to 32bits, leading to problems on
machines with more than 4GiB of RAM.  As 32bit dom0 kernels tend to be
PAE capable, this is especially wasteful, as most structures currently
limited to <4GiB could easily be <64GiB instead.

Therefore, introduce a new hypercall 'KEXEC_CMD_kexec64_get_range'
which passes similar information as KEXEC_CMD_kexec_get_range, but
which uses a structure with explicitly specified field widths, causing
it to be identical in the compat and regular case.  This new
structure, xen_kexec64_range_t, will be the same as xen_kexec_range_t
if Xen is compiled for x86_64, but will still use 64bit integers if
Xen is compiled for x86_32.

To fix 32bit Xen which uses 32bit integers for addresses and sizes,
change the internals to use xen_kexec64_range_t which will use 64bit
integers instead.  This also involves changing several casts to
explicitly use uint64_ts rather than unsigned longs.

In addition, the hypercall entry points need updating to be able to
cater for all possibilities.

|Xen/dom0 bits|          Bit width of addresses in structure for        |
+------+------+---------------------------+-----------------------------+
| Xen  | dom0 | KEXEC_CMD_kexec_get_range | KEXEC_CMD_kexec64_get_range |
+------+------+---------------------------+-----------------------------+
|  32  |  32  |             32            |              64             |
|  64  |  32  |             32            |              64             |
|  64  |  64  |             64            |              64             |
+------+------+---------------------------+-----------------------------+

This has been solved by splitting do_kexec_op_internal back into
do_kexec_op{,_compat} and changing kexec_get_range{,_compat} to
kexec_get_range{32,64} which now exist irrespective of CONFIG_COMPAT
or not.

The knock-on effect of removing do_kexec_op_internal means that
kexec_load_unload_compat is only ever called from inside an #ifdef
CONFIG_COMPAT codepath, which does not exist on Xen x86_32.
Therefore, move the #ifdef CONFIG_COMPAT guards to include the entire
function.

Finally, and a little unrelatedly, fix KEXEC_CMD_kexec_{load,unload}
to return -EBUSY instead of EOK if a kexec is in progress.

Changes since v1:
 *  Fix check for pointer truncation to work when Xen is compiled for
    32 bit mode as well.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

diff -r e56500f95b6a -r f571dc8e4368 xen/arch/ia64/xen/machine_kexec.c
--- a/xen/arch/ia64/xen/machine_kexec.c
+++ b/xen/arch/ia64/xen/machine_kexec.c
@@ -102,10 +102,10 @@ void machine_reboot_kexec(xen_kexec_imag
 	machine_kexec(image);
 }
 
-int machine_kexec_get_xen(xen_kexec_range_t *range)
+int machine_kexec_get_xen(xen_kexec64_range_t *range)
 {
 	range->start = ia64_tpa(_text);
-	range->size = (unsigned long)_end - (unsigned long)_text;
+	range->size = (uint64_t)_end - (uint64_t)_text;
 	return 0;
 }
 
@@ -113,31 +113,31 @@ int machine_kexec_get_xen(xen_kexec_rang
 #define ELF_PAGE_SIZE  (__IA64_UL_CONST(1) << ELF_PAGE_SHIFT)
 #define ELF_PAGE_MASK  (~(ELF_PAGE_SIZE - 1))
 
-static int machine_kexec_get_xenheap(xen_kexec_range_t *range)
+static int machine_kexec_get_xenheap(xen_kexec64_range_t *range)
 {
 	range->start = (ia64_tpa(_end) + (ELF_PAGE_SIZE - 1)) & ELF_PAGE_MASK;
 	range->size =
-		(((unsigned long)range->start + KERNEL_TR_PAGE_SIZE) &
+		(((uint64_t)range->start + KERNEL_TR_PAGE_SIZE) &
          ~(KERNEL_TR_PAGE_SIZE - 1))
-		- (unsigned long)range->start;
+		- (uint64_t)range->start;
 	return 0;
 }
 
-static int machine_kexec_get_boot_param(xen_kexec_range_t *range)
+static int machine_kexec_get_boot_param(xen_kexec64_range_t *range)
 {
 	range->start = __pa(ia64_boot_param);
 	range->size = sizeof(*ia64_boot_param);
 	return 0;
 }
 
-static int machine_kexec_get_efi_memmap(xen_kexec_range_t *range)
+static int machine_kexec_get_efi_memmap(xen_kexec64_range_t *range)
 {
 	range->start = ia64_boot_param->efi_memmap;
 	range->size = ia64_boot_param->efi_memmap_size;
 	return 0;
 }
 
-int machine_kexec_get(xen_kexec_range_t *range)
+int machine_kexec_get(xen_kexec64_range_t *range)
 {
 	switch (range->range) {
 	case KEXEC_RANGE_MA_XEN:
diff -r e56500f95b6a -r f571dc8e4368 xen/arch/x86/machine_kexec.c
--- a/xen/arch/x86/machine_kexec.c
+++ b/xen/arch/x86/machine_kexec.c
@@ -120,7 +120,7 @@ void machine_kexec(xen_kexec_image_t *im
     }
 }
 
-int machine_kexec_get(xen_kexec_range_t *range)
+int machine_kexec_get(xen_kexec64_range_t *range)
 {
 	if (range->range != KEXEC_RANGE_MA_XEN)
 		return -EINVAL;
diff -r e56500f95b6a -r f571dc8e4368 xen/arch/x86/x86_32/machine_kexec.c
--- a/xen/arch/x86/x86_32/machine_kexec.c
+++ b/xen/arch/x86/x86_32/machine_kexec.c
@@ -11,11 +11,11 @@
 #include <asm/page.h>
 #include <public/kexec.h>
 
-int machine_kexec_get_xen(xen_kexec_range_t *range)
+int machine_kexec_get_xen(xen_kexec64_range_t *range)
 {
         range->start = virt_to_maddr(_start);
-        range->size = (unsigned long)xenheap_phys_end -
-                      (unsigned long)range->start;
+        range->size = (uint64_t)xenheap_phys_end -
+                      (uint64_t)range->start;
         return 0;
 }
 
diff -r e56500f95b6a -r f571dc8e4368 xen/arch/x86/x86_64/machine_kexec.c
--- a/xen/arch/x86/x86_64/machine_kexec.c
+++ b/xen/arch/x86/x86_64/machine_kexec.c
@@ -11,10 +11,10 @@
 #include <asm/page.h>
 #include <public/kexec.h>
 
-int machine_kexec_get_xen(xen_kexec_range_t *range)
+int machine_kexec_get_xen(xen_kexec64_range_t *range)
 {
         range->start = virt_to_maddr(_start);
-        range->size = virt_to_maddr(_end) - (unsigned long)range->start;
+        range->size = virt_to_maddr(_end) - (uint64_t)range->start;
         return 0;
 }
 
diff -r e56500f95b6a -r f571dc8e4368 xen/common/kexec.c
--- a/xen/common/kexec.c
+++ b/xen/common/kexec.c
@@ -56,6 +56,14 @@ static struct {
     unsigned long size;
 } ranges[16] __initdata;
 
+/* This XLAT macro is required now even without CONFIG_COMPAT. */
+#define TRANSLATE_kexec_range(_d_, _s_) do { \
+    (_d_)->range = (_s_)->range; \
+    (_d_)->nr = (_s_)->nr; \
+    (_d_)->size = (_s_)->size; \
+    (_d_)->start = (_s_)->start; \
+} while (0)
+
 /*
  * Parse command lines in the format
  *
@@ -280,7 +288,7 @@ static int sizeof_note(const char *name,
             ELFNOTE_ALIGN(descsz));
 }
 
-static int kexec_get_reserve(xen_kexec_range_t *range)
+static int kexec_get_reserve(xen_kexec64_range_t *range)
 {
     if ( kexec_crash_area.size > 0 && kexec_crash_area.start > 0) {
         range->start = kexec_crash_area.start;
@@ -291,7 +299,7 @@ static int kexec_get_reserve(xen_kexec_r
     return 0;
 }
 
-static int kexec_get_cpu(xen_kexec_range_t *range)
+static int kexec_get_cpu(xen_kexec64_range_t *range)
 {
     int nr = range->nr;
     int nr_bytes = 0;
@@ -335,14 +343,14 @@ static int kexec_get_cpu(xen_kexec_range
     return 0;
 }
 
-static int kexec_get_vmcoreinfo(xen_kexec_range_t *range)
+static int kexec_get_vmcoreinfo(xen_kexec64_range_t *range)
 {
     range->start = __pa((unsigned long)vmcoreinfo_data);
     range->size = VMCOREINFO_BYTES;
     return 0;
 }
 
-static int kexec_get_range_internal(xen_kexec_range_t *range)
+static int kexec_get_range_internal(xen_kexec64_range_t *range)
 {
     int ret = -EINVAL;
 
@@ -365,9 +373,14 @@ static int kexec_get_range_internal(xen_
     return ret;
 }
 
-static int kexec_get_range(XEN_GUEST_HANDLE(void) uarg)
+/* This function can be invoked from either a KEXEC_CMD_kexec64_get_range
+ * hypercall, or from a KEXEC_CMD_kexec_get_range hypercall with 64bit dom0
+ * on 64bit Xen.  In the first case, the guest structure is a 
+ * xen_kexec64_range_t, and in the second case, the xen_kexec_range_t guest
+ * structure is identical to xen_kexec64_range_t. */
+static int kexec_get_range64(XEN_GUEST_HANDLE(void) uarg)
 {
-    xen_kexec_range_t range;
+    xen_kexec64_range_t range;
     int ret = -EINVAL;
 
     if ( unlikely(copy_from_guest(&range, uarg, 1)) )
@@ -381,34 +394,40 @@ static int kexec_get_range(XEN_GUEST_HAN
     return ret;
 }
 
-static int kexec_get_range_compat(XEN_GUEST_HANDLE(void) uarg)
+/* This function can be invoked from either a KEXEC_CMD_kexec_get_range
+ * compat hypercall for 32bit dom0 on 64bit Xen, or from the same hypercall
+ * on 32bit Xen.  In both cases, the guest argument uses 32bit integers, so 
+ * translate them to 64bit for use by kexec_get_range_internal.  The
+ * preprocessor guards are to choose the correct 32bit structure, as the
+ * compat_* structures dont exist in 32bit Xen. */
+static int kexec_get_range32(XEN_GUEST_HANDLE(void) uarg)
 {
+    xen_kexec64_range_t range64;
 #ifdef CONFIG_COMPAT
-    xen_kexec_range_t range;
-    compat_kexec_range_t compat_range;
+    compat_kexec_range_t range32;
+#else
+    xen_kexec_range_t range32;
+#endif
     int ret = -EINVAL;
 
-    if ( unlikely(copy_from_guest(&compat_range, uarg, 1)) )
+    if ( unlikely(copy_from_guest(&range32, uarg, 1)) )
         return -EFAULT;
 
-    XLAT_kexec_range(&range, &compat_range);
+    TRANSLATE_kexec_range(&range64, &range32);
 
-    ret = kexec_get_range_internal(&range);
+    ret = kexec_get_range_internal(&range64);
 
     /* Dont silently truncate physical addresses or sizes. */
-    if ( (range.start | range.size) & ~(unsigned long)(~0u) )
+    if ( (range64.start | range64.size) & 0xffffffff00000000ULL )
         return -ERANGE;
 
     if ( ret == 0 ) {
-        XLAT_kexec_range(&compat_range, &range);
-        if ( unlikely(copy_to_guest(uarg, &compat_range, 1)) )
+        TRANSLATE_kexec_range(&range32, &range64);
+        if ( unlikely(copy_to_guest(uarg, &range32, 1)) )
              return -EFAULT;
     }
 
     return ret;
-#else /* CONFIG_COMPAT */
-    return 0;
-#endif /* CONFIG_COMPAT */
 }
 
 static int kexec_load_get_bits(int type, int *base, int *bit)
@@ -543,10 +562,10 @@ static int kexec_load_unload(unsigned lo
     return kexec_load_unload_internal(op, &load);
 }
 
+#ifdef CONFIG_COMPAT
 static int kexec_load_unload_compat(unsigned long op,
                                     XEN_GUEST_HANDLE(void) uarg)
 {
-#ifdef CONFIG_COMPAT
     compat_kexec_load_t compat_load;
     xen_kexec_load_t load;
 
@@ -564,10 +583,8 @@ static int kexec_load_unload_compat(unsi
     XLAT_kexec_image(&load.image, &compat_load.image);
 
     return kexec_load_unload_internal(op, &load);
-#else /* CONFIG_COMPAT */
-    return 0;
+}
 #endif /* CONFIG_COMPAT */
-}
 
 static int kexec_exec(XEN_GUEST_HANDLE(void) uarg)
 {
@@ -601,8 +618,51 @@ static int kexec_exec(XEN_GUEST_HANDLE(v
     return -EINVAL; /* never reached */
 }
 
-int do_kexec_op_internal(unsigned long op, XEN_GUEST_HANDLE(void) uarg,
-                           int compat)
+long do_kexec_op(unsigned long op, XEN_GUEST_HANDLE(void) uarg)
+{
+    unsigned long flags;
+    int ret = -EINVAL;
+
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+
+    ret = xsm_kexec();
+    if ( ret )
+        return ret;
+
+    switch ( op )
+    {
+#ifdef __i386__
+    case KEXEC_CMD_kexec_get_range:
+        ret = kexec_get_range32(uarg);
+        break;
+#else
+    case KEXEC_CMD_kexec_get_range:
+#endif
+    case KEXEC_CMD_kexec64_get_range:
+        ret = kexec_get_range64(uarg);
+        break;
+
+    case KEXEC_CMD_kexec_load:
+    case KEXEC_CMD_kexec_unload:
+        spin_lock_irqsave(&kexec_lock, flags);
+        if (!test_bit(KEXEC_FLAG_IN_PROGRESS, &kexec_flags))
+            ret = kexec_load_unload(op, uarg);
+        else
+            ret = -EBUSY;
+        spin_unlock_irqrestore(&kexec_lock, flags);
+        break;
+
+    case KEXEC_CMD_kexec:
+        ret = kexec_exec(uarg);
+        break;
+    }
+
+    return ret;
+}
+
+#ifdef CONFIG_COMPAT
+int compat_kexec_op(unsigned long op, XEN_GUEST_HANDLE(void) uarg)
 {
     unsigned long flags;
     int ret = -EINVAL;
@@ -617,23 +677,21 @@ int do_kexec_op_internal(unsigned long o
     switch ( op )
     {
     case KEXEC_CMD_kexec_get_range:
-        if (compat)
-                ret = kexec_get_range_compat(uarg);
-        else
-                ret = kexec_get_range(uarg);
+        ret = kexec_get_range32(uarg);
+        break;
+    case KEXEC_CMD_kexec64_get_range:
+        ret = kexec_get_range64(uarg);
         break;
     case KEXEC_CMD_kexec_load:
     case KEXEC_CMD_kexec_unload:
         spin_lock_irqsave(&kexec_lock, flags);
         if (!test_bit(KEXEC_FLAG_IN_PROGRESS, &kexec_flags))
-        {
-                if (compat)
-                        ret = kexec_load_unload_compat(op, uarg);
-                else
-                        ret = kexec_load_unload(op, uarg);
-        }
+            ret = kexec_load_unload_compat(op, uarg);
+        else
+            ret = -EBUSY;
         spin_unlock_irqrestore(&kexec_lock, flags);
         break;
+
     case KEXEC_CMD_kexec:
         ret = kexec_exec(uarg);
         break;
@@ -641,17 +699,6 @@ int do_kexec_op_internal(unsigned long o
 
     return ret;
 }
-
-long do_kexec_op(unsigned long op, XEN_GUEST_HANDLE(void) uarg)
-{
-    return do_kexec_op_internal(op, uarg, 0);
-}
-
-#ifdef CONFIG_COMPAT
-int compat_kexec_op(unsigned long op, XEN_GUEST_HANDLE(void) uarg)
-{
-    return do_kexec_op_internal(op, uarg, 1);
-}
 #endif
 
 /*
diff -r e56500f95b6a -r f571dc8e4368 xen/include/public/kexec.h
--- a/xen/include/public/kexec.h
+++ b/xen/include/public/kexec.h
@@ -155,6 +155,15 @@ typedef struct xen_kexec_range {
     unsigned long start;
 } xen_kexec_range_t;
 
+#define KEXEC_CMD_kexec64_get_range      4
+/* xen_kexec_range_t using explicit sizes for fields. */
+typedef struct xen_kexec64_range {
+    int32_t range;
+    int32_t nr;
+    uint64_t size;
+    uint64_t start;
+} xen_kexec64_range_t;
+
 #endif /* _XEN_PUBLIC_KEXEC_H */
 
 /*
diff -r e56500f95b6a -r f571dc8e4368 xen/include/xen/kexec.h
--- a/xen/include/xen/kexec.h
+++ b/xen/include/xen/kexec.h
@@ -34,8 +34,8 @@ void kexec_crash(void);
 void kexec_crash_save_cpu(void);
 crash_xen_info_t *kexec_crash_save_info(void);
 void machine_crash_shutdown(void);
-int machine_kexec_get(xen_kexec_range_t *range);
-int machine_kexec_get_xen(xen_kexec_range_t *range);
+int machine_kexec_get(xen_kexec64_range_t *range);
+int machine_kexec_get_xen(xen_kexec64_range_t *range);
 
 void compat_machine_kexec(unsigned long rnk,
                           unsigned long indirection_page,
diff -r e56500f95b6a -r f571dc8e4368 xen/include/xlat.lst
--- a/xen/include/xlat.lst
+++ b/xen/include/xlat.lst
@@ -50,9 +50,7 @@
 ?	grant_entry_v1			grant_table.h
 ?       grant_entry_header              grant_table.h
 ?	grant_entry_v2			grant_table.h
-?	kexec_exec			kexec.h
 !	kexec_image			kexec.h
-!	kexec_range			kexec.h
 !	add_to_physmap			memory.h
 !	foreign_memory_map		memory.h
 !	memory_exchange			memory.h

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 22 17:42:10 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 Dec 2011 17:42:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdmeB-0005Ch-Cy; Thu, 22 Dec 2011 17:41:39 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1RdmeA-0005CN-DK
	for xen-devel@lists.xensource.com; Thu, 22 Dec 2011 17:41:38 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1324575692!8419607!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Nzk5NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14635 invoked from network); 22 Dec 2011 17:41:32 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Dec 2011 17:41:32 -0000
X-IronPort-AV: E=Sophos;i="4.71,394,1320624000"; 
   d="scan'208";a="9640548"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Dec 2011 17:41:32 +0000
Received: from andrewcoop.uk.xensource.com (10.80.2.18) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 22 Dec 2011 17:41:31 +0000
MIME-Version: 1.0
Message-ID: <patchbomb.1324575382@andrewcoop.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.4.3
Date: Thu, 22 Dec 2011 17:36:22 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: xen-devel@lists.xensource.com
Cc: Andrew Cooper <andrew.cooper3@citrix.com>
Subject: [Xen-devel] [PATCH 0 of 3] KEXEC fixes
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This set of 3 patches contain fixes and functional improvements to the
kexec path in Xen.  The first two have already been posted to the list
individually but are presented here as a group.

Patch 1 contains an implementation of a new hypercall which will not
truncate 64bit pointers to 32bit when in compatability mode.

Patch 2 changes the per cpu crash notes to be allocated on boot.

Patch 3 implements logic to allow Xen to specifically allocate the
crash notes and console buffer in lower memory because if 64/32bit issues
on machines with large quantities of RAM.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 22 17:42:10 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 Dec 2011 17:42:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdmeB-0005Ch-Cy; Thu, 22 Dec 2011 17:41:39 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1RdmeA-0005CN-DK
	for xen-devel@lists.xensource.com; Thu, 22 Dec 2011 17:41:38 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1324575692!8419607!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Nzk5NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14635 invoked from network); 22 Dec 2011 17:41:32 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Dec 2011 17:41:32 -0000
X-IronPort-AV: E=Sophos;i="4.71,394,1320624000"; 
   d="scan'208";a="9640548"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Dec 2011 17:41:32 +0000
Received: from andrewcoop.uk.xensource.com (10.80.2.18) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 22 Dec 2011 17:41:31 +0000
MIME-Version: 1.0
Message-ID: <patchbomb.1324575382@andrewcoop.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.4.3
Date: Thu, 22 Dec 2011 17:36:22 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: xen-devel@lists.xensource.com
Cc: Andrew Cooper <andrew.cooper3@citrix.com>
Subject: [Xen-devel] [PATCH 0 of 3] KEXEC fixes
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This set of 3 patches contain fixes and functional improvements to the
kexec path in Xen.  The first two have already been posted to the list
individually but are presented here as a group.

Patch 1 contains an implementation of a new hypercall which will not
truncate 64bit pointers to 32bit when in compatability mode.

Patch 2 changes the per cpu crash notes to be allocated on boot.

Patch 3 implements logic to allow Xen to specifically allocate the
crash notes and console buffer in lower memory because if 64/32bit issues
on machines with large quantities of RAM.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 22 18:09:57 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 Dec 2011 18: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.xensource.com>)
	id 1Rdn5C-0006Z1-FT; Thu, 22 Dec 2011 18:09:34 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1Rdn5A-0006Yw-PW
	for xen-devel@lists.xensource.com; Thu, 22 Dec 2011 18:09:32 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1324577365!8497198!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjUxOTM=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9472 invoked from network); 22 Dec 2011 18:09:26 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Dec 2011 18:09:26 -0000
X-IronPort-AV: E=Sophos;i="4.71,394,1320642000"; d="scan'208";a="175195976"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Dec 2011 13:09:24 -0500
Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX01.citrite.net
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Thu, 22 Dec 2011
	13:09:24 -0500
Message-ID: <4EF37253.9000903@citrix.com>
Date: Thu, 22 Dec 2011 18:09:23 +0000
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20111110 Icedove/3.0.11
MIME-Version: 1.0
To: Andrew Cooper <andrew.cooper3@citrix.com>
References: <patchbomb.1324575382@andrewcoop.uk.xensource.com>
	<23c31d59ffb1590815bc.1324575385@andrewcoop.uk.xensource.com>
In-Reply-To: <23c31d59ffb1590815bc.1324575385@andrewcoop.uk.xensource.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 3 of 3] KEXEC: Allocate crash structures in
 low	memory
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 22/12/11 17:36, Andrew Cooper wrote:
> On 64bit Xen with 32bit dom0 and crashkernel, xmalloc'ing items such
> as the CPU crash notes will go into the xenheap, which tends to be in
> upper memory.  This causes problems on machines with more than 64GB
> (or 4GB if no PAE support) of ram as the crashkernel physically cant
> access the crash notes.

I've never been entirely convinced that this was the correct approach.
It seems that using a 64-bit crash kernel would be an easier solution.

> @@ -320,7 +405,10 @@ static int kexec_init_cpu_notes(const un
>          return ret;
>  
>      nr_bytes = sizeof_cpu_notes(cpu);
> -    note = xmalloc_bytes(nr_bytes);
> +
> +    /* If we dont care about the position of allocation, malloc. */
> +    if ( low_crashinfo_mode == LOW_CRASHINFO_NONE )
> +        note = xmalloc_bytes(nr_bytes);

Suggest refactoring this (and the other similar places) so that the
check for the regular/crash head occurs in one wrapper alloc function.

>      /* Protect the write into crash_notes[] with a spinlock, as this function
>       * is on a hotplug path and a hypercall path. */
> @@ -338,6 +426,11 @@ static int kexec_init_cpu_notes(const un
>      }
>      else
>      {
> +        /* If we care about memory possition, alloc from the crash heap,
> +         * also protected by the crash_notes_lock. */
> +        if ( low_crashinfo_mode > LOW_CRASHINFO_NONE )
> +            note = alloc_from_crash_heap(nr_bytes);
> +
>          crash_notes[cpu].start = note;
>          crash_notes[cpu].size = nr_bytes;
>          spin_unlock(&crash_notes_lock);
> @@ -397,6 +490,24 @@ static struct notifier_block cpu_nfb = {
>      .notifier_call = cpu_callback
>  };
>  
> +void __init kexec_early_calculations(void)
> +{
> +    /* If low_crashinfo_mode is still INVALID, neither "low_crashinfo" nor
> +     * "crashinfo_maxaddr" have been specified on the command line, so
> +     * explicitly set to NONE. */
> +    if ( low_crashinfo_mode == LOW_CRASHINFO_INVALID )
> +        low_crashinfo_mode = LOW_CRASHINFO_NONE;

Why not initialize low_crash_info_mode to NONE?

> +
> +    crashinfo_maxaddr_bits = 0;
> +    if ( low_crashinfo_mode > LOW_CRASHINFO_NONE )
> +    {
> +        paddr_t tmp = crashinfo_maxaddr;
> +
> +        while ( tmp >>= 1 )
> +            crashinfo_maxaddr_bits++;
> +    }
> +}

Do these during the parsing of the command line?

These will allow you to remove this unhelpfully named function.

> +
>  static int __init kexec_init(void)
>  {
>      void *cpu = (void *)(unsigned long)smp_processor_id();
> @@ -407,6 +518,29 @@ static int __init kexec_init(void)
>  
>      register_keyhandler('C', &crashdump_trigger_keyhandler);
>  
> +    if ( low_crashinfo_mode > LOW_CRASHINFO_NONE )
> +    {
> +        size_t crash_heap_size;
> +
> +        /* This calculation is safe even if the machine is booted in 
> +         * uniprocessor mode. */
> +        crash_heap_size = sizeof_cpu_notes(0) +
> +            sizeof_cpu_notes(1) * (nr_cpu_ids - 1);
> +        crash_heap_size = PAGE_ALIGN(crash_heap_size);
> +
> +        crash_heap_current = alloc_xenheap_pages(
> +            get_order_from_bytes(crash_heap_size),
> +            MEMF_bits(crashinfo_maxaddr_bits) );
> +
> +        if ( crash_heap_current )
> +            crash_heap_end = crash_heap_current + crash_heap_size;
> +        else
> +            return -ENOMEM;
> +    }

Suggest moving this into a crash_heap_setup() function.

> +
> +    /* crash_notes may be allocated anywhere Xen can reach in memory.
> +       Only the individual CPU crash notes themselves must be allocated
> +       in lower memory if requested. */
>      crash_notes = xmalloc_array(crash_note_range_t, nr_cpu_ids);
>      if ( ! crash_notes )
>          return -ENOMEM;
> diff -r 3da37c68284f -r 23c31d59ffb1 xen/drivers/char/console.c
> --- a/xen/drivers/char/console.c
> +++ b/xen/drivers/char/console.c
> @@ -584,6 +584,7 @@ void __init console_init_postirq(void)
>  {
>      char *ring;
>      unsigned int i, order;
> +    u64 memflags;
>  
>      serial_init_postirq();
>  
> @@ -591,7 +592,8 @@ void __init console_init_postirq(void)
>          opt_conring_size = num_present_cpus() << (9 + xenlog_lower_thresh);
>  
>      order = get_order_from_bytes(max(opt_conring_size, conring_size));
> -    while ( (ring = alloc_xenheap_pages(order, 0)) == NULL )
> +    memflags = low_crashinfo_mode > LOW_CRASHINFO_NONE ? MEMF_bits(crashinfo_maxaddr_bits) : 0;

If you set crashinfo_maxaddr_bits to 64 if low_crashinfo_mode isn't used
you wouldn't need this test.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 22 18:09:57 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 Dec 2011 18: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.xensource.com>)
	id 1Rdn5C-0006Z1-FT; Thu, 22 Dec 2011 18:09:34 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1Rdn5A-0006Yw-PW
	for xen-devel@lists.xensource.com; Thu, 22 Dec 2011 18:09:32 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1324577365!8497198!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjUxOTM=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9472 invoked from network); 22 Dec 2011 18:09:26 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Dec 2011 18:09:26 -0000
X-IronPort-AV: E=Sophos;i="4.71,394,1320642000"; d="scan'208";a="175195976"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Dec 2011 13:09:24 -0500
Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX01.citrite.net
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Thu, 22 Dec 2011
	13:09:24 -0500
Message-ID: <4EF37253.9000903@citrix.com>
Date: Thu, 22 Dec 2011 18:09:23 +0000
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20111110 Icedove/3.0.11
MIME-Version: 1.0
To: Andrew Cooper <andrew.cooper3@citrix.com>
References: <patchbomb.1324575382@andrewcoop.uk.xensource.com>
	<23c31d59ffb1590815bc.1324575385@andrewcoop.uk.xensource.com>
In-Reply-To: <23c31d59ffb1590815bc.1324575385@andrewcoop.uk.xensource.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 3 of 3] KEXEC: Allocate crash structures in
 low	memory
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 22/12/11 17:36, Andrew Cooper wrote:
> On 64bit Xen with 32bit dom0 and crashkernel, xmalloc'ing items such
> as the CPU crash notes will go into the xenheap, which tends to be in
> upper memory.  This causes problems on machines with more than 64GB
> (or 4GB if no PAE support) of ram as the crashkernel physically cant
> access the crash notes.

I've never been entirely convinced that this was the correct approach.
It seems that using a 64-bit crash kernel would be an easier solution.

> @@ -320,7 +405,10 @@ static int kexec_init_cpu_notes(const un
>          return ret;
>  
>      nr_bytes = sizeof_cpu_notes(cpu);
> -    note = xmalloc_bytes(nr_bytes);
> +
> +    /* If we dont care about the position of allocation, malloc. */
> +    if ( low_crashinfo_mode == LOW_CRASHINFO_NONE )
> +        note = xmalloc_bytes(nr_bytes);

Suggest refactoring this (and the other similar places) so that the
check for the regular/crash head occurs in one wrapper alloc function.

>      /* Protect the write into crash_notes[] with a spinlock, as this function
>       * is on a hotplug path and a hypercall path. */
> @@ -338,6 +426,11 @@ static int kexec_init_cpu_notes(const un
>      }
>      else
>      {
> +        /* If we care about memory possition, alloc from the crash heap,
> +         * also protected by the crash_notes_lock. */
> +        if ( low_crashinfo_mode > LOW_CRASHINFO_NONE )
> +            note = alloc_from_crash_heap(nr_bytes);
> +
>          crash_notes[cpu].start = note;
>          crash_notes[cpu].size = nr_bytes;
>          spin_unlock(&crash_notes_lock);
> @@ -397,6 +490,24 @@ static struct notifier_block cpu_nfb = {
>      .notifier_call = cpu_callback
>  };
>  
> +void __init kexec_early_calculations(void)
> +{
> +    /* If low_crashinfo_mode is still INVALID, neither "low_crashinfo" nor
> +     * "crashinfo_maxaddr" have been specified on the command line, so
> +     * explicitly set to NONE. */
> +    if ( low_crashinfo_mode == LOW_CRASHINFO_INVALID )
> +        low_crashinfo_mode = LOW_CRASHINFO_NONE;

Why not initialize low_crash_info_mode to NONE?

> +
> +    crashinfo_maxaddr_bits = 0;
> +    if ( low_crashinfo_mode > LOW_CRASHINFO_NONE )
> +    {
> +        paddr_t tmp = crashinfo_maxaddr;
> +
> +        while ( tmp >>= 1 )
> +            crashinfo_maxaddr_bits++;
> +    }
> +}

Do these during the parsing of the command line?

These will allow you to remove this unhelpfully named function.

> +
>  static int __init kexec_init(void)
>  {
>      void *cpu = (void *)(unsigned long)smp_processor_id();
> @@ -407,6 +518,29 @@ static int __init kexec_init(void)
>  
>      register_keyhandler('C', &crashdump_trigger_keyhandler);
>  
> +    if ( low_crashinfo_mode > LOW_CRASHINFO_NONE )
> +    {
> +        size_t crash_heap_size;
> +
> +        /* This calculation is safe even if the machine is booted in 
> +         * uniprocessor mode. */
> +        crash_heap_size = sizeof_cpu_notes(0) +
> +            sizeof_cpu_notes(1) * (nr_cpu_ids - 1);
> +        crash_heap_size = PAGE_ALIGN(crash_heap_size);
> +
> +        crash_heap_current = alloc_xenheap_pages(
> +            get_order_from_bytes(crash_heap_size),
> +            MEMF_bits(crashinfo_maxaddr_bits) );
> +
> +        if ( crash_heap_current )
> +            crash_heap_end = crash_heap_current + crash_heap_size;
> +        else
> +            return -ENOMEM;
> +    }

Suggest moving this into a crash_heap_setup() function.

> +
> +    /* crash_notes may be allocated anywhere Xen can reach in memory.
> +       Only the individual CPU crash notes themselves must be allocated
> +       in lower memory if requested. */
>      crash_notes = xmalloc_array(crash_note_range_t, nr_cpu_ids);
>      if ( ! crash_notes )
>          return -ENOMEM;
> diff -r 3da37c68284f -r 23c31d59ffb1 xen/drivers/char/console.c
> --- a/xen/drivers/char/console.c
> +++ b/xen/drivers/char/console.c
> @@ -584,6 +584,7 @@ void __init console_init_postirq(void)
>  {
>      char *ring;
>      unsigned int i, order;
> +    u64 memflags;
>  
>      serial_init_postirq();
>  
> @@ -591,7 +592,8 @@ void __init console_init_postirq(void)
>          opt_conring_size = num_present_cpus() << (9 + xenlog_lower_thresh);
>  
>      order = get_order_from_bytes(max(opt_conring_size, conring_size));
> -    while ( (ring = alloc_xenheap_pages(order, 0)) == NULL )
> +    memflags = low_crashinfo_mode > LOW_CRASHINFO_NONE ? MEMF_bits(crashinfo_maxaddr_bits) : 0;

If you set crashinfo_maxaddr_bits to 64 if low_crashinfo_mode isn't used
you wouldn't need this test.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 22 18:45:17 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 Dec 2011 18:45:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdndE-0006ul-LA; Thu, 22 Dec 2011 18:44:44 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1RdndD-0006ug-Bn
	for xen-devel@lists.xensource.com; Thu, 22 Dec 2011 18:44:43 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1324579475!9109778!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTA2MTI=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4723 invoked from network); 22 Dec 2011 18:44:37 -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;
	22 Dec 2011 18:44:37 -0000
X-IronPort-AV: E=Sophos;i="4.71,394,1320642000"; d="scan'208";a="20232750"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Dec 2011 13:44:35 -0500
Received: from [10.80.2.18] (10.80.2.18) by FTLPMAILMX01.citrite.net
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Thu, 22 Dec 2011
	13:44:34 -0500
Message-ID: <4EF37A91.6000608@citrix.com>
Date: Thu, 22 Dec 2011 18:44:33 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.23) Gecko/20110921 Lightning/1.0b2 Thunderbird/3.1.15
MIME-Version: 1.0
To: David Vrabel <david.vrabel@citrix.com>
References: <patchbomb.1324575382@andrewcoop.uk.xensource.com>
	<23c31d59ffb1590815bc.1324575385@andrewcoop.uk.xensource.com>
	<4EF37253.9000903@citrix.com>
In-Reply-To: <4EF37253.9000903@citrix.com>
X-Enigmail-Version: 1.1.2
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Tim Deegan <tim@xen.org>
Subject: Re: [Xen-devel] [PATCH 3 of 3] KEXEC: Allocate crash structures in
 low memory
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 22/12/11 18:09, David Vrabel wrote:
> On 22/12/11 17:36, Andrew Cooper wrote:
>> On 64bit Xen with 32bit dom0 and crashkernel, xmalloc'ing items such
>> as the CPU crash notes will go into the xenheap, which tends to be in
>> upper memory.  This causes problems on machines with more than 64GB
>> (or 4GB if no PAE support) of ram as the crashkernel physically cant
>> access the crash notes.
> I've never been entirely convinced that this was the correct approach.
> It seems that using a 64-bit crash kernel would be an easier solution.

In an ideal world yes, but reality is that XS will stay with a 32bit
kernel for a while yet.

>> @@ -320,7 +405,10 @@ static int kexec_init_cpu_notes(const un
>>          return ret;
>>  
>>      nr_bytes = sizeof_cpu_notes(cpu);
>> -    note = xmalloc_bytes(nr_bytes);
>> +
>> +    /* If we dont care about the position of allocation, malloc. */
>> +    if ( low_crashinfo_mode == LOW_CRASHINFO_NONE )
>> +        note = xmalloc_bytes(nr_bytes);
> Suggest refactoring this (and the other similar places) so that the
> check for the regular/crash head occurs in one wrapper alloc function.

Can't refactor this as its other half is specifically inside the lock
while this is outside.

>>      /* Protect the write into crash_notes[] with a spinlock, as this function
>>       * is on a hotplug path and a hypercall path. */
>> @@ -338,6 +426,11 @@ static int kexec_init_cpu_notes(const un
>>      }
>>      else
>>      {
>> +        /* If we care about memory possition, alloc from the crash heap,
>> +         * also protected by the crash_notes_lock. */
>> +        if ( low_crashinfo_mode > LOW_CRASHINFO_NONE )
>> +            note = alloc_from_crash_heap(nr_bytes);
>> +
>>          crash_notes[cpu].start = note;
>>          crash_notes[cpu].size = nr_bytes;
>>          spin_unlock(&crash_notes_lock);
>> @@ -397,6 +490,24 @@ static struct notifier_block cpu_nfb = {
>>      .notifier_call = cpu_callback
>>  };
>>  
>> +void __init kexec_early_calculations(void)
>> +{
>> +    /* If low_crashinfo_mode is still INVALID, neither "low_crashinfo" nor
>> +     * "crashinfo_maxaddr" have been specified on the command line, so
>> +     * explicitly set to NONE. */
>> +    if ( low_crashinfo_mode == LOW_CRASHINFO_INVALID )
>> +        low_crashinfo_mode = LOW_CRASHINFO_NONE;
> Why not initialize low_crash_info_mode to NONE?

So there is not a dependency between the order of low_crashinfo and
crashinfo_maxaddr, while still allowing each option to set a sensible
default for the other if only a single one is specified on the command line.

>> +
>> +    crashinfo_maxaddr_bits = 0;
>> +    if ( low_crashinfo_mode > LOW_CRASHINFO_NONE )
>> +    {
>> +        paddr_t tmp = crashinfo_maxaddr;
>> +
>> +        while ( tmp >>= 1 )
>> +            crashinfo_maxaddr_bits++;
>> +    }
>> +}
> Do these during the parsing of the command line?

Argument along the same lines as above w.r.t two command line
arguments.  crashinfo_maxaddr_bits is always used.  Therefore it must be
0 in the case where no limits are applied, meaning that setting it to a
default of lg(4GB) will break things.  Setting it in the parsing
function would prevent a sensible default being set if the user only
specified low_crashinfo without making a combinational explosion of
logic in the parsing function.

> These will allow you to remove this unhelpfully named function.
>
>> +
>>  static int __init kexec_init(void)
>>  {
>>      void *cpu = (void *)(unsigned long)smp_processor_id();
>> @@ -407,6 +518,29 @@ static int __init kexec_init(void)
>>  
>>      register_keyhandler('C', &crashdump_trigger_keyhandler);
>>  
>> +    if ( low_crashinfo_mode > LOW_CRASHINFO_NONE )
>> +    {
>> +        size_t crash_heap_size;
>> +
>> +        /* This calculation is safe even if the machine is booted in 
>> +         * uniprocessor mode. */
>> +        crash_heap_size = sizeof_cpu_notes(0) +
>> +            sizeof_cpu_notes(1) * (nr_cpu_ids - 1);
>> +        crash_heap_size = PAGE_ALIGN(crash_heap_size);
>> +
>> +        crash_heap_current = alloc_xenheap_pages(
>> +            get_order_from_bytes(crash_heap_size),
>> +            MEMF_bits(crashinfo_maxaddr_bits) );
>> +
>> +        if ( crash_heap_current )
>> +            crash_heap_end = crash_heap_current + crash_heap_size;
>> +        else
>> +            return -ENOMEM;
>> +    }
> Suggest moving this into a crash_heap_setup() function.

Questionable.  I would argue that it is trading an extra indirection in
the source code for a gain of only a few lines, which will be inlined
back to here by the compiler.

>> +
>> +    /* crash_notes may be allocated anywhere Xen can reach in memory.
>> +       Only the individual CPU crash notes themselves must be allocated
>> +       in lower memory if requested. */
>>      crash_notes = xmalloc_array(crash_note_range_t, nr_cpu_ids);
>>      if ( ! crash_notes )
>>          return -ENOMEM;
>> diff -r 3da37c68284f -r 23c31d59ffb1 xen/drivers/char/console.c
>> --- a/xen/drivers/char/console.c
>> +++ b/xen/drivers/char/console.c
>> @@ -584,6 +584,7 @@ void __init console_init_postirq(void)
>>  {
>>      char *ring;
>>      unsigned int i, order;
>> +    u64 memflags;
>>  
>>      serial_init_postirq();
>>  
>> @@ -591,7 +592,8 @@ void __init console_init_postirq(void)
>>          opt_conring_size = num_present_cpus() << (9 + xenlog_lower_thresh);
>>  
>>      order = get_order_from_bytes(max(opt_conring_size, conring_size));
>> -    while ( (ring = alloc_xenheap_pages(order, 0)) == NULL )
>> +    memflags = low_crashinfo_mode > LOW_CRASHINFO_NONE ? MEMF_bits(crashinfo_maxaddr_bits) : 0;
> If you set crashinfo_maxaddr_bits to 64 if low_crashinfo_mode isn't used
> you wouldn't need this test.

I am not familiar enough with the intricacies of alloc_xenheap_pages to
know whether that is safe.  cc'ing Tim for his expertise.

> David

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 22 18:45:17 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 Dec 2011 18:45:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdndE-0006ul-LA; Thu, 22 Dec 2011 18:44:44 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1RdndD-0006ug-Bn
	for xen-devel@lists.xensource.com; Thu, 22 Dec 2011 18:44:43 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1324579475!9109778!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTA2MTI=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4723 invoked from network); 22 Dec 2011 18:44:37 -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;
	22 Dec 2011 18:44:37 -0000
X-IronPort-AV: E=Sophos;i="4.71,394,1320642000"; d="scan'208";a="20232750"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Dec 2011 13:44:35 -0500
Received: from [10.80.2.18] (10.80.2.18) by FTLPMAILMX01.citrite.net
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Thu, 22 Dec 2011
	13:44:34 -0500
Message-ID: <4EF37A91.6000608@citrix.com>
Date: Thu, 22 Dec 2011 18:44:33 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.23) Gecko/20110921 Lightning/1.0b2 Thunderbird/3.1.15
MIME-Version: 1.0
To: David Vrabel <david.vrabel@citrix.com>
References: <patchbomb.1324575382@andrewcoop.uk.xensource.com>
	<23c31d59ffb1590815bc.1324575385@andrewcoop.uk.xensource.com>
	<4EF37253.9000903@citrix.com>
In-Reply-To: <4EF37253.9000903@citrix.com>
X-Enigmail-Version: 1.1.2
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Tim Deegan <tim@xen.org>
Subject: Re: [Xen-devel] [PATCH 3 of 3] KEXEC: Allocate crash structures in
 low memory
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 22/12/11 18:09, David Vrabel wrote:
> On 22/12/11 17:36, Andrew Cooper wrote:
>> On 64bit Xen with 32bit dom0 and crashkernel, xmalloc'ing items such
>> as the CPU crash notes will go into the xenheap, which tends to be in
>> upper memory.  This causes problems on machines with more than 64GB
>> (or 4GB if no PAE support) of ram as the crashkernel physically cant
>> access the crash notes.
> I've never been entirely convinced that this was the correct approach.
> It seems that using a 64-bit crash kernel would be an easier solution.

In an ideal world yes, but reality is that XS will stay with a 32bit
kernel for a while yet.

>> @@ -320,7 +405,10 @@ static int kexec_init_cpu_notes(const un
>>          return ret;
>>  
>>      nr_bytes = sizeof_cpu_notes(cpu);
>> -    note = xmalloc_bytes(nr_bytes);
>> +
>> +    /* If we dont care about the position of allocation, malloc. */
>> +    if ( low_crashinfo_mode == LOW_CRASHINFO_NONE )
>> +        note = xmalloc_bytes(nr_bytes);
> Suggest refactoring this (and the other similar places) so that the
> check for the regular/crash head occurs in one wrapper alloc function.

Can't refactor this as its other half is specifically inside the lock
while this is outside.

>>      /* Protect the write into crash_notes[] with a spinlock, as this function
>>       * is on a hotplug path and a hypercall path. */
>> @@ -338,6 +426,11 @@ static int kexec_init_cpu_notes(const un
>>      }
>>      else
>>      {
>> +        /* If we care about memory possition, alloc from the crash heap,
>> +         * also protected by the crash_notes_lock. */
>> +        if ( low_crashinfo_mode > LOW_CRASHINFO_NONE )
>> +            note = alloc_from_crash_heap(nr_bytes);
>> +
>>          crash_notes[cpu].start = note;
>>          crash_notes[cpu].size = nr_bytes;
>>          spin_unlock(&crash_notes_lock);
>> @@ -397,6 +490,24 @@ static struct notifier_block cpu_nfb = {
>>      .notifier_call = cpu_callback
>>  };
>>  
>> +void __init kexec_early_calculations(void)
>> +{
>> +    /* If low_crashinfo_mode is still INVALID, neither "low_crashinfo" nor
>> +     * "crashinfo_maxaddr" have been specified on the command line, so
>> +     * explicitly set to NONE. */
>> +    if ( low_crashinfo_mode == LOW_CRASHINFO_INVALID )
>> +        low_crashinfo_mode = LOW_CRASHINFO_NONE;
> Why not initialize low_crash_info_mode to NONE?

So there is not a dependency between the order of low_crashinfo and
crashinfo_maxaddr, while still allowing each option to set a sensible
default for the other if only a single one is specified on the command line.

>> +
>> +    crashinfo_maxaddr_bits = 0;
>> +    if ( low_crashinfo_mode > LOW_CRASHINFO_NONE )
>> +    {
>> +        paddr_t tmp = crashinfo_maxaddr;
>> +
>> +        while ( tmp >>= 1 )
>> +            crashinfo_maxaddr_bits++;
>> +    }
>> +}
> Do these during the parsing of the command line?

Argument along the same lines as above w.r.t two command line
arguments.  crashinfo_maxaddr_bits is always used.  Therefore it must be
0 in the case where no limits are applied, meaning that setting it to a
default of lg(4GB) will break things.  Setting it in the parsing
function would prevent a sensible default being set if the user only
specified low_crashinfo without making a combinational explosion of
logic in the parsing function.

> These will allow you to remove this unhelpfully named function.
>
>> +
>>  static int __init kexec_init(void)
>>  {
>>      void *cpu = (void *)(unsigned long)smp_processor_id();
>> @@ -407,6 +518,29 @@ static int __init kexec_init(void)
>>  
>>      register_keyhandler('C', &crashdump_trigger_keyhandler);
>>  
>> +    if ( low_crashinfo_mode > LOW_CRASHINFO_NONE )
>> +    {
>> +        size_t crash_heap_size;
>> +
>> +        /* This calculation is safe even if the machine is booted in 
>> +         * uniprocessor mode. */
>> +        crash_heap_size = sizeof_cpu_notes(0) +
>> +            sizeof_cpu_notes(1) * (nr_cpu_ids - 1);
>> +        crash_heap_size = PAGE_ALIGN(crash_heap_size);
>> +
>> +        crash_heap_current = alloc_xenheap_pages(
>> +            get_order_from_bytes(crash_heap_size),
>> +            MEMF_bits(crashinfo_maxaddr_bits) );
>> +
>> +        if ( crash_heap_current )
>> +            crash_heap_end = crash_heap_current + crash_heap_size;
>> +        else
>> +            return -ENOMEM;
>> +    }
> Suggest moving this into a crash_heap_setup() function.

Questionable.  I would argue that it is trading an extra indirection in
the source code for a gain of only a few lines, which will be inlined
back to here by the compiler.

>> +
>> +    /* crash_notes may be allocated anywhere Xen can reach in memory.
>> +       Only the individual CPU crash notes themselves must be allocated
>> +       in lower memory if requested. */
>>      crash_notes = xmalloc_array(crash_note_range_t, nr_cpu_ids);
>>      if ( ! crash_notes )
>>          return -ENOMEM;
>> diff -r 3da37c68284f -r 23c31d59ffb1 xen/drivers/char/console.c
>> --- a/xen/drivers/char/console.c
>> +++ b/xen/drivers/char/console.c
>> @@ -584,6 +584,7 @@ void __init console_init_postirq(void)
>>  {
>>      char *ring;
>>      unsigned int i, order;
>> +    u64 memflags;
>>  
>>      serial_init_postirq();
>>  
>> @@ -591,7 +592,8 @@ void __init console_init_postirq(void)
>>          opt_conring_size = num_present_cpus() << (9 + xenlog_lower_thresh);
>>  
>>      order = get_order_from_bytes(max(opt_conring_size, conring_size));
>> -    while ( (ring = alloc_xenheap_pages(order, 0)) == NULL )
>> +    memflags = low_crashinfo_mode > LOW_CRASHINFO_NONE ? MEMF_bits(crashinfo_maxaddr_bits) : 0;
> If you set crashinfo_maxaddr_bits to 64 if low_crashinfo_mode isn't used
> you wouldn't need this test.

I am not familiar enough with the intricacies of alloc_xenheap_pages to
know whether that is safe.  cc'ing Tim for his expertise.

> David

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 22 19:40:29 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 Dec 2011 19: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.xensource.com>)
	id 1RdoUY-0007E4-79; Thu, 22 Dec 2011 19:39:50 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RdoUW-0007Ds-GF
	for xen-devel@lists.xensource.com; Thu, 22 Dec 2011 19:39:48 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1324582782!8347122!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Nzk5NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3568 invoked from network); 22 Dec 2011 19:39:42 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Dec 2011 19:39:42 -0000
X-IronPort-AV: E=Sophos;i="4.71,394,1320624000"; 
   d="scan'208";a="9641739"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Dec 2011 19:39:20 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 22 Dec 2011 19:39:20 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RdoU4-0004Cz-39;
	Thu, 22 Dec 2011 19:39:20 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RdoU3-0006T0-TW;
	Thu, 22 Dec 2011 19:39:19 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10598-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 22 Dec 2011 19:39:19 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10598: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10598 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10598/

Regressions :-(

Tests which did not succeed and are blocking,including tests which could not be run:
 test-amd64-i386-rhel6hvm-amd  7 redhat-install            fail REGR. vs. 10564
 test-amd64-i386-xl-win-vcpus1  7 windows-install          fail REGR. vs. 10564

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-sedf      5 xen-boot                  fail REGR. vs. 10564
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass

version targeted for testing:
 xen                  2863b2f43a3b
baseline version:
 xen                  e56500f95b6a

------------------------------------------------------------
People who touched revisions under test:
  Anthony PERARD <anthony.perard@citrix.com>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Haitao Shan <haitao.shan@intel.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Shan Haitao <maillists.shan@gmail.com>
  Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   24446:2863b2f43a3b
tag:         tip
user:        Ian Jackson <Ian.Jackson@eu.citrix.com>
date:        Thu Dec 22 14:49:38 2011 +0000
    
    Update QEMU_TAG
    
    
changeset:   24445:492914c65838
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Wed Dec 21 10:47:30 2011 +0000
    
    libxl: report failure to reboot/shutdown due to lackof PV interfaces to caller
    
    This allow the caller to react as they think is appropriate. xl now prints a
    message much like the library did previously, although hopefully somewhat more
    informative.
    
    Update the xl(1) man page to be similarly more informative.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Committed-by: Ian Jackson <ian.jackson.citrix.com>
    Acked-by: Ian Jackson <ian.jackson.citrix.com>
    
    
changeset:   24444:1c3f9cac204e
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Wed Dec 21 10:47:11 2011 +0000
    
    libxl: split libxl_domain_shutdown into libxl_domain_shutdown,..._reboot
    
    The other integer request types which shutdown supported are not
    useful. Specifically:
    
     * "suspend" is not usable via this interface since it requires other
       scaffolding, libxl_domain_suspend provides this already.
     * "halt" is the same as "poweroff".
     * "crash" is unused and at least Linux does not implement it. If a user
       steps forward then libxl_domain_crash is trivial to add.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Committed-by: Ian Jackson <ian.jackson.citrix.com>
    Acked-by: Ian Jackson <ian.jackson.citrix.com>
    
    
changeset:   24443:b3455a4d2298
user:        Anthony PERARD <anthony.perard@citrix.com>
date:        Wed Dec 21 14:47:26 2011 +0000
    
    libxl: Fix, specify open mode to QEMU state file.
    
    Reported-by: Olaf Hering <olaf@aepfle.de>
    Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24442:16dc2a1cd40f
user:        Jan Beulich <jbeulich@suse.com>
date:        Wed Dec 21 14:26:09 2011 +0100
    
    x86: reduce scope of some symbols used with reset_stack_and_jump()
    
    By making the macro properly advertise the use of the input symbol to
    the compiler, it is no longer necessary for them to be global if
    they're defined and used in just one source file.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24441:73ab77073140
user:        Jan Beulich <jbeulich@suse.com>
date:        Wed Dec 21 09:20:15 2011 +0100
    
    x86: move some function scope statics into .init.data
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24440:e56500f95b6a
user:        Daniel De Graaf <dgdegra@tycho.nsa.gov>
date:        Tue Dec 20 18:19:53 2011 +0000
    
    flask/policy: Update example policy
    
    Rewrite the example policy to make it easier to understand and
    demonstrate some of the security goals that FLASK can enforce.
    
    Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
    Committed-by: Ian Jackson <ian.jackson.citrix.com>
    
    
========================================
commit 56d7747a3cf811910c4cf865e1ebcb8b82502005
Author: Ian Jackson <ian.jackson@eu.citrix.com>
Date:   Thu Dec 22 14:46:31 2011 +0000

    qemu: clean up MSI-X table handling
    
    This patch does cleaning up of QEMU MSI handling. The fixes are:
    1. Changes made to MSI-X table mapping handling to eliminate the small
    windows in which guest could have access to physical MSI-X table.
    2. MSI-X table is mapped as read-only to QEMU, as masking of MSI-X is
    already in Xen now.
    3. For registers that coexists inside the MSI-X table (this could be
    only PBA I think), value read from physical page would be returned.
    
    Signed-off-by:  Shan Haitao <maillists.shan@gmail.com>
    
    Consolidated duplicate code into _pt_iomem_helper(). Fixed formatting.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    
    Acked-by: Haitao Shan <haitao.shan@intel.com>
    Acked-by: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 22 19:40:29 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 Dec 2011 19: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.xensource.com>)
	id 1RdoUY-0007E4-79; Thu, 22 Dec 2011 19:39:50 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RdoUW-0007Ds-GF
	for xen-devel@lists.xensource.com; Thu, 22 Dec 2011 19:39:48 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1324582782!8347122!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Nzk5NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3568 invoked from network); 22 Dec 2011 19:39:42 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Dec 2011 19:39:42 -0000
X-IronPort-AV: E=Sophos;i="4.71,394,1320624000"; 
   d="scan'208";a="9641739"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Dec 2011 19:39:20 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 22 Dec 2011 19:39:20 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RdoU4-0004Cz-39;
	Thu, 22 Dec 2011 19:39:20 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RdoU3-0006T0-TW;
	Thu, 22 Dec 2011 19:39:19 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10598-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 22 Dec 2011 19:39:19 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10598: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10598 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10598/

Regressions :-(

Tests which did not succeed and are blocking,including tests which could not be run:
 test-amd64-i386-rhel6hvm-amd  7 redhat-install            fail REGR. vs. 10564
 test-amd64-i386-xl-win-vcpus1  7 windows-install          fail REGR. vs. 10564

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-sedf      5 xen-boot                  fail REGR. vs. 10564
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass

version targeted for testing:
 xen                  2863b2f43a3b
baseline version:
 xen                  e56500f95b6a

------------------------------------------------------------
People who touched revisions under test:
  Anthony PERARD <anthony.perard@citrix.com>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Haitao Shan <haitao.shan@intel.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Shan Haitao <maillists.shan@gmail.com>
  Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   24446:2863b2f43a3b
tag:         tip
user:        Ian Jackson <Ian.Jackson@eu.citrix.com>
date:        Thu Dec 22 14:49:38 2011 +0000
    
    Update QEMU_TAG
    
    
changeset:   24445:492914c65838
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Wed Dec 21 10:47:30 2011 +0000
    
    libxl: report failure to reboot/shutdown due to lackof PV interfaces to caller
    
    This allow the caller to react as they think is appropriate. xl now prints a
    message much like the library did previously, although hopefully somewhat more
    informative.
    
    Update the xl(1) man page to be similarly more informative.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Committed-by: Ian Jackson <ian.jackson.citrix.com>
    Acked-by: Ian Jackson <ian.jackson.citrix.com>
    
    
changeset:   24444:1c3f9cac204e
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Wed Dec 21 10:47:11 2011 +0000
    
    libxl: split libxl_domain_shutdown into libxl_domain_shutdown,..._reboot
    
    The other integer request types which shutdown supported are not
    useful. Specifically:
    
     * "suspend" is not usable via this interface since it requires other
       scaffolding, libxl_domain_suspend provides this already.
     * "halt" is the same as "poweroff".
     * "crash" is unused and at least Linux does not implement it. If a user
       steps forward then libxl_domain_crash is trivial to add.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Committed-by: Ian Jackson <ian.jackson.citrix.com>
    Acked-by: Ian Jackson <ian.jackson.citrix.com>
    
    
changeset:   24443:b3455a4d2298
user:        Anthony PERARD <anthony.perard@citrix.com>
date:        Wed Dec 21 14:47:26 2011 +0000
    
    libxl: Fix, specify open mode to QEMU state file.
    
    Reported-by: Olaf Hering <olaf@aepfle.de>
    Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24442:16dc2a1cd40f
user:        Jan Beulich <jbeulich@suse.com>
date:        Wed Dec 21 14:26:09 2011 +0100
    
    x86: reduce scope of some symbols used with reset_stack_and_jump()
    
    By making the macro properly advertise the use of the input symbol to
    the compiler, it is no longer necessary for them to be global if
    they're defined and used in just one source file.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24441:73ab77073140
user:        Jan Beulich <jbeulich@suse.com>
date:        Wed Dec 21 09:20:15 2011 +0100
    
    x86: move some function scope statics into .init.data
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24440:e56500f95b6a
user:        Daniel De Graaf <dgdegra@tycho.nsa.gov>
date:        Tue Dec 20 18:19:53 2011 +0000
    
    flask/policy: Update example policy
    
    Rewrite the example policy to make it easier to understand and
    demonstrate some of the security goals that FLASK can enforce.
    
    Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
    Committed-by: Ian Jackson <ian.jackson.citrix.com>
    
    
========================================
commit 56d7747a3cf811910c4cf865e1ebcb8b82502005
Author: Ian Jackson <ian.jackson@eu.citrix.com>
Date:   Thu Dec 22 14:46:31 2011 +0000

    qemu: clean up MSI-X table handling
    
    This patch does cleaning up of QEMU MSI handling. The fixes are:
    1. Changes made to MSI-X table mapping handling to eliminate the small
    windows in which guest could have access to physical MSI-X table.
    2. MSI-X table is mapped as read-only to QEMU, as masking of MSI-X is
    already in Xen now.
    3. For registers that coexists inside the MSI-X table (this could be
    only PBA I think), value read from physical page would be returned.
    
    Signed-off-by:  Shan Haitao <maillists.shan@gmail.com>
    
    Consolidated duplicate code into _pt_iomem_helper(). Fixed formatting.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    
    Acked-by: Haitao Shan <haitao.shan@intel.com>
    Acked-by: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 22 20:39:05 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 Dec 2011 20:39:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdpPL-0007se-Il; Thu, 22 Dec 2011 20:38:31 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RdpPK-0007sR-6s
	for xen-devel@lists.xensource.com; Thu, 22 Dec 2011 20:38:30 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1324586303!6586346!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Nzk5NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7482 invoked from network); 22 Dec 2011 20:38:23 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Dec 2011 20:38:23 -0000
X-IronPort-AV: E=Sophos;i="4.71,395,1320624000"; 
   d="scan'208";a="9642152"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Dec 2011 20:38:22 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 22 Dec 2011 20:38:22 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ben Hutchings <bhutchings@solarflare.com>
In-Reply-To: <1324565067.2897.2.camel@bwh-desktop>
References: <4EF3018D020000780006986E@nat28.tlf.novell.com>
	<1324547820.7877.71.camel@zakaz.uk.xensource.com>
	<4EF327E2020000780006993E@nat28.tlf.novell.com>
	<1324555060.7877.84.camel@zakaz.uk.xensource.com>
	<1324565067.2897.2.camel@bwh-desktop>
Organization: Citrix Systems, Inc.
Date: Thu, 22 Dec 2011 20:38:21 +0000
Message-ID: <1324586301.13113.3.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
X-Mailer: Evolution 2.32.3 
Cc: Jens Axboe <axboe@kernel.dk>, Jeremy Fitzhardinge <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"FlorianSchandinat@gmx.de" <FlorianSchandinat@gmx.de>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"dmitry.torokhov@gmail.com" <dmitry.torokhov@gmail.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Jan Beulich <JBeulich@suse.com>, Konrad Rzeszutek Wilk <konrad@darnok.org>,
	"davem@davemloft.net" <davem@davemloft.net>
Subject: Re: [Xen-devel] [PATCH,
 v2] Xen: consolidate and simplify struct xenbus_driver instantiation
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2011-12-22 at 14:44 +0000, Ben Hutchings wrote:
> On Thu, 2011-12-22 at 11:57 +0000, Ian Campbell wrote:
> > On Thu, 2011-12-22 at 11:51 +0000, Jan Beulich wrote:
> > > >>> On 22.12.11 at 10:57, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > > > On Thu, 2011-12-22 at 09:08 +0000, Jan Beulich wrote:
> > > >> The 'name', 'owner', and 'mod_name' members are redundant with the
> > > >> identically named fields in the 'driver' sub-structure. Rather than
> > > >> switching each instance to specify these fields explicitly, introduce
> > > >> a macro to simplify this.
> > > >> 
> > > >> Eliminate further redundancy by allowing the drvname argument to
> > > >> DEFINE_XENBUS_DRIVER() to be blank (in which case the first entry from
> > > >> the ID table will be used for .driver.name).
> > > > 
> > > > Any reason not to always use DRV_NAME here (which is generally a bit
> > > > more specific e.g. "xen-foofront" rather than "foo") and rely on the id
> > > > table for the shorter names used in xenstore?
> > > 
> > > That would imply that DRV_NAME is always defined, but I don't
> > > see this being the case.
> > 
> > My mistake, I thought it was a Kbuild thing.
> 
> You're maybe thinking of KBUILD_MODNAME.

Yes, I think I was.

Thanks,
Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 22 20:39:05 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 Dec 2011 20:39:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdpPL-0007se-Il; Thu, 22 Dec 2011 20:38:31 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RdpPK-0007sR-6s
	for xen-devel@lists.xensource.com; Thu, 22 Dec 2011 20:38:30 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1324586303!6586346!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Nzk5NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7482 invoked from network); 22 Dec 2011 20:38:23 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Dec 2011 20:38:23 -0000
X-IronPort-AV: E=Sophos;i="4.71,395,1320624000"; 
   d="scan'208";a="9642152"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Dec 2011 20:38:22 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 22 Dec 2011 20:38:22 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ben Hutchings <bhutchings@solarflare.com>
In-Reply-To: <1324565067.2897.2.camel@bwh-desktop>
References: <4EF3018D020000780006986E@nat28.tlf.novell.com>
	<1324547820.7877.71.camel@zakaz.uk.xensource.com>
	<4EF327E2020000780006993E@nat28.tlf.novell.com>
	<1324555060.7877.84.camel@zakaz.uk.xensource.com>
	<1324565067.2897.2.camel@bwh-desktop>
Organization: Citrix Systems, Inc.
Date: Thu, 22 Dec 2011 20:38:21 +0000
Message-ID: <1324586301.13113.3.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
X-Mailer: Evolution 2.32.3 
Cc: Jens Axboe <axboe@kernel.dk>, Jeremy Fitzhardinge <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"FlorianSchandinat@gmx.de" <FlorianSchandinat@gmx.de>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"dmitry.torokhov@gmail.com" <dmitry.torokhov@gmail.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Jan Beulich <JBeulich@suse.com>, Konrad Rzeszutek Wilk <konrad@darnok.org>,
	"davem@davemloft.net" <davem@davemloft.net>
Subject: Re: [Xen-devel] [PATCH,
 v2] Xen: consolidate and simplify struct xenbus_driver instantiation
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2011-12-22 at 14:44 +0000, Ben Hutchings wrote:
> On Thu, 2011-12-22 at 11:57 +0000, Ian Campbell wrote:
> > On Thu, 2011-12-22 at 11:51 +0000, Jan Beulich wrote:
> > > >>> On 22.12.11 at 10:57, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > > > On Thu, 2011-12-22 at 09:08 +0000, Jan Beulich wrote:
> > > >> The 'name', 'owner', and 'mod_name' members are redundant with the
> > > >> identically named fields in the 'driver' sub-structure. Rather than
> > > >> switching each instance to specify these fields explicitly, introduce
> > > >> a macro to simplify this.
> > > >> 
> > > >> Eliminate further redundancy by allowing the drvname argument to
> > > >> DEFINE_XENBUS_DRIVER() to be blank (in which case the first entry from
> > > >> the ID table will be used for .driver.name).
> > > > 
> > > > Any reason not to always use DRV_NAME here (which is generally a bit
> > > > more specific e.g. "xen-foofront" rather than "foo") and rely on the id
> > > > table for the shorter names used in xenstore?
> > > 
> > > That would imply that DRV_NAME is always defined, but I don't
> > > see this being the case.
> > 
> > My mistake, I thought it was a Kbuild thing.
> 
> You're maybe thinking of KBUILD_MODNAME.

Yes, I think I was.

Thanks,
Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 23 00:15:28 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 Dec 2011 00: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.xensource.com>)
	id 1Rdsmd-0003Fn-Qw; Fri, 23 Dec 2011 00:14:47 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Rdsmc-0003Ff-Gf
	for xen-devel@lists.xensource.com; Fri, 23 Dec 2011 00:14:46 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1324599243!47820135!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODA5Ng==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4262 invoked from network); 23 Dec 2011 00:14:03 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Dec 2011 00:14:03 -0000
X-IronPort-AV: E=Sophos;i="4.71,396,1320624000"; 
   d="scan'208";a="9644030"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Dec 2011 00:14:45 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 23 Dec 2011 00:14:44 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1Rdsma-0005ha-L7;
	Fri, 23 Dec 2011 00:14:44 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Rdsma-00018R-K6;
	Fri, 23 Dec 2011 00:14:44 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10600-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 23 Dec 2011 00:14:44 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10600: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10600 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10600/

Regressions :-(

Tests which did not succeed and are blocking,including tests which could not be run:
 test-amd64-i386-xl-win-vcpus1 12 guest-localmigrate/x10   fail REGR. vs. 10564

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-multivcpu 16 guest-start.2               fail pass in 10598
 test-i386-i386-xl-win         7 windows-install             fail pass in 10598
 test-amd64-i386-rhel6hvm-amd  7 redhat-install     fail in 10598 pass in 10600
 test-amd64-amd64-xl-sedf      5 xen-boot           fail in 10598 pass in 10600
 test-amd64-i386-xl-win-vcpus1  7 windows-install   fail in 10598 pass in 10600

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-sedf     14 guest-localmigrate/x10       fail   like 10563
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-i386-i386-xl-win        13 guest-stop            fail in 10598 never pass

version targeted for testing:
 xen                  2863b2f43a3b
baseline version:
 xen                  e56500f95b6a

------------------------------------------------------------
People who touched revisions under test:
  Anthony PERARD <anthony.perard@citrix.com>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Haitao Shan <haitao.shan@intel.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Shan Haitao <maillists.shan@gmail.com>
  Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   24446:2863b2f43a3b
tag:         tip
user:        Ian Jackson <Ian.Jackson@eu.citrix.com>
date:        Thu Dec 22 14:49:38 2011 +0000
    
    Update QEMU_TAG
    
    
changeset:   24445:492914c65838
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Wed Dec 21 10:47:30 2011 +0000
    
    libxl: report failure to reboot/shutdown due to lackof PV interfaces to caller
    
    This allow the caller to react as they think is appropriate. xl now prints a
    message much like the library did previously, although hopefully somewhat more
    informative.
    
    Update the xl(1) man page to be similarly more informative.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Committed-by: Ian Jackson <ian.jackson.citrix.com>
    Acked-by: Ian Jackson <ian.jackson.citrix.com>
    
    
changeset:   24444:1c3f9cac204e
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Wed Dec 21 10:47:11 2011 +0000
    
    libxl: split libxl_domain_shutdown into libxl_domain_shutdown,..._reboot
    
    The other integer request types which shutdown supported are not
    useful. Specifically:
    
     * "suspend" is not usable via this interface since it requires other
       scaffolding, libxl_domain_suspend provides this already.
     * "halt" is the same as "poweroff".
     * "crash" is unused and at least Linux does not implement it. If a user
       steps forward then libxl_domain_crash is trivial to add.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Committed-by: Ian Jackson <ian.jackson.citrix.com>
    Acked-by: Ian Jackson <ian.jackson.citrix.com>
    
    
changeset:   24443:b3455a4d2298
user:        Anthony PERARD <anthony.perard@citrix.com>
date:        Wed Dec 21 14:47:26 2011 +0000
    
    libxl: Fix, specify open mode to QEMU state file.
    
    Reported-by: Olaf Hering <olaf@aepfle.de>
    Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24442:16dc2a1cd40f
user:        Jan Beulich <jbeulich@suse.com>
date:        Wed Dec 21 14:26:09 2011 +0100
    
    x86: reduce scope of some symbols used with reset_stack_and_jump()
    
    By making the macro properly advertise the use of the input symbol to
    the compiler, it is no longer necessary for them to be global if
    they're defined and used in just one source file.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24441:73ab77073140
user:        Jan Beulich <jbeulich@suse.com>
date:        Wed Dec 21 09:20:15 2011 +0100
    
    x86: move some function scope statics into .init.data
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24440:e56500f95b6a
user:        Daniel De Graaf <dgdegra@tycho.nsa.gov>
date:        Tue Dec 20 18:19:53 2011 +0000
    
    flask/policy: Update example policy
    
    Rewrite the example policy to make it easier to understand and
    demonstrate some of the security goals that FLASK can enforce.
    
    Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
    Committed-by: Ian Jackson <ian.jackson.citrix.com>
    
    
========================================
commit 56d7747a3cf811910c4cf865e1ebcb8b82502005
Author: Ian Jackson <ian.jackson@eu.citrix.com>
Date:   Thu Dec 22 14:46:31 2011 +0000

    qemu: clean up MSI-X table handling
    
    This patch does cleaning up of QEMU MSI handling. The fixes are:
    1. Changes made to MSI-X table mapping handling to eliminate the small
    windows in which guest could have access to physical MSI-X table.
    2. MSI-X table is mapped as read-only to QEMU, as masking of MSI-X is
    already in Xen now.
    3. For registers that coexists inside the MSI-X table (this could be
    only PBA I think), value read from physical page would be returned.
    
    Signed-off-by:  Shan Haitao <maillists.shan@gmail.com>
    
    Consolidated duplicate code into _pt_iomem_helper(). Fixed formatting.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    
    Acked-by: Haitao Shan <haitao.shan@intel.com>
    Acked-by: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 23 00:15:28 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 Dec 2011 00: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.xensource.com>)
	id 1Rdsmd-0003Fn-Qw; Fri, 23 Dec 2011 00:14:47 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Rdsmc-0003Ff-Gf
	for xen-devel@lists.xensource.com; Fri, 23 Dec 2011 00:14:46 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1324599243!47820135!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODA5Ng==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4262 invoked from network); 23 Dec 2011 00:14:03 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Dec 2011 00:14:03 -0000
X-IronPort-AV: E=Sophos;i="4.71,396,1320624000"; 
   d="scan'208";a="9644030"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Dec 2011 00:14:45 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 23 Dec 2011 00:14:44 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1Rdsma-0005ha-L7;
	Fri, 23 Dec 2011 00:14:44 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Rdsma-00018R-K6;
	Fri, 23 Dec 2011 00:14:44 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10600-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 23 Dec 2011 00:14:44 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10600: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10600 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10600/

Regressions :-(

Tests which did not succeed and are blocking,including tests which could not be run:
 test-amd64-i386-xl-win-vcpus1 12 guest-localmigrate/x10   fail REGR. vs. 10564

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-multivcpu 16 guest-start.2               fail pass in 10598
 test-i386-i386-xl-win         7 windows-install             fail pass in 10598
 test-amd64-i386-rhel6hvm-amd  7 redhat-install     fail in 10598 pass in 10600
 test-amd64-amd64-xl-sedf      5 xen-boot           fail in 10598 pass in 10600
 test-amd64-i386-xl-win-vcpus1  7 windows-install   fail in 10598 pass in 10600

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-sedf     14 guest-localmigrate/x10       fail   like 10563
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-i386-i386-xl-win        13 guest-stop            fail in 10598 never pass

version targeted for testing:
 xen                  2863b2f43a3b
baseline version:
 xen                  e56500f95b6a

------------------------------------------------------------
People who touched revisions under test:
  Anthony PERARD <anthony.perard@citrix.com>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Haitao Shan <haitao.shan@intel.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Shan Haitao <maillists.shan@gmail.com>
  Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   24446:2863b2f43a3b
tag:         tip
user:        Ian Jackson <Ian.Jackson@eu.citrix.com>
date:        Thu Dec 22 14:49:38 2011 +0000
    
    Update QEMU_TAG
    
    
changeset:   24445:492914c65838
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Wed Dec 21 10:47:30 2011 +0000
    
    libxl: report failure to reboot/shutdown due to lackof PV interfaces to caller
    
    This allow the caller to react as they think is appropriate. xl now prints a
    message much like the library did previously, although hopefully somewhat more
    informative.
    
    Update the xl(1) man page to be similarly more informative.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Committed-by: Ian Jackson <ian.jackson.citrix.com>
    Acked-by: Ian Jackson <ian.jackson.citrix.com>
    
    
changeset:   24444:1c3f9cac204e
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Wed Dec 21 10:47:11 2011 +0000
    
    libxl: split libxl_domain_shutdown into libxl_domain_shutdown,..._reboot
    
    The other integer request types which shutdown supported are not
    useful. Specifically:
    
     * "suspend" is not usable via this interface since it requires other
       scaffolding, libxl_domain_suspend provides this already.
     * "halt" is the same as "poweroff".
     * "crash" is unused and at least Linux does not implement it. If a user
       steps forward then libxl_domain_crash is trivial to add.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Committed-by: Ian Jackson <ian.jackson.citrix.com>
    Acked-by: Ian Jackson <ian.jackson.citrix.com>
    
    
changeset:   24443:b3455a4d2298
user:        Anthony PERARD <anthony.perard@citrix.com>
date:        Wed Dec 21 14:47:26 2011 +0000
    
    libxl: Fix, specify open mode to QEMU state file.
    
    Reported-by: Olaf Hering <olaf@aepfle.de>
    Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24442:16dc2a1cd40f
user:        Jan Beulich <jbeulich@suse.com>
date:        Wed Dec 21 14:26:09 2011 +0100
    
    x86: reduce scope of some symbols used with reset_stack_and_jump()
    
    By making the macro properly advertise the use of the input symbol to
    the compiler, it is no longer necessary for them to be global if
    they're defined and used in just one source file.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24441:73ab77073140
user:        Jan Beulich <jbeulich@suse.com>
date:        Wed Dec 21 09:20:15 2011 +0100
    
    x86: move some function scope statics into .init.data
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24440:e56500f95b6a
user:        Daniel De Graaf <dgdegra@tycho.nsa.gov>
date:        Tue Dec 20 18:19:53 2011 +0000
    
    flask/policy: Update example policy
    
    Rewrite the example policy to make it easier to understand and
    demonstrate some of the security goals that FLASK can enforce.
    
    Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
    Committed-by: Ian Jackson <ian.jackson.citrix.com>
    
    
========================================
commit 56d7747a3cf811910c4cf865e1ebcb8b82502005
Author: Ian Jackson <ian.jackson@eu.citrix.com>
Date:   Thu Dec 22 14:46:31 2011 +0000

    qemu: clean up MSI-X table handling
    
    This patch does cleaning up of QEMU MSI handling. The fixes are:
    1. Changes made to MSI-X table mapping handling to eliminate the small
    windows in which guest could have access to physical MSI-X table.
    2. MSI-X table is mapped as read-only to QEMU, as masking of MSI-X is
    already in Xen now.
    3. For registers that coexists inside the MSI-X table (this could be
    only PBA I think), value read from physical page would be returned.
    
    Signed-off-by:  Shan Haitao <maillists.shan@gmail.com>
    
    Consolidated duplicate code into _pt_iomem_helper(). Fixed formatting.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    
    Acked-by: Haitao Shan <haitao.shan@intel.com>
    Acked-by: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 23 02:46:01 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 Dec 2011 02:46:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rdv8E-0007uT-La; Fri, 23 Dec 2011 02:45:14 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <xiantao.zhang@intel.com>) id 1Rdv8C-0007uL-TT
	for xen-devel@lists.xensource.com; Fri, 23 Dec 2011 02:45:13 +0000
X-Env-Sender: xiantao.zhang@intel.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1324608305!9032098!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDMwMjEwMQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31183 invoked from network); 23 Dec 2011 02:45:06 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-10.tower-21.messagelabs.com with SMTP;
	23 Dec 2011 02:45:06 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga101.fm.intel.com with ESMTP; 22 Dec 2011 18:45:03 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="105323595"
Received: from pgsmsx601.gar.corp.intel.com ([10.221.43.69])
	by fmsmga002.fm.intel.com with ESMTP; 22 Dec 2011 18:45:03 -0800
Received: from pgsmsx102.gar.corp.intel.com (10.221.44.80) by
	pgsmsx601.gar.corp.intel.com (10.221.43.69) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Fri, 23 Dec 2011 10:44:15 +0800
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	PGSMSX102.gar.corp.intel.com (10.221.44.80) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Fri, 23 Dec 2011 10:44:15 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.38]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.223]) with mapi id
	14.01.0355.002; Fri, 23 Dec 2011 10:44:14 +0800
From: "Zhang, Xiantao" <xiantao.zhang@intel.com>
To: andrew thomas <andrew.thomas@oracle.com>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>
Thread-Topic: [Xen-devel] issue with PLE and/or scheduler
Thread-Index: Acy/2fmuB+fO6Wm2ThS+i7cJne3PaQBQox3Q
Date: Fri, 23 Dec 2011 02:44:13 +0000
Message-ID: <B6C2EB9186482D47BD0C5A9A48345644B646@SHSMSX101.ccr.corp.intel.com>
References: <4EEFC462.2020307@oracle.com>
In-Reply-To: <4EEFC462.2020307@oracle.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Subject: Re: [Xen-devel] issue with PLE and/or scheduler
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Andrew, 
   Can you try this patch to see whether to fix your  issue ? 
Xiantao

diff -r 381ab77db71a xen/arch/x86/hvm/vpt.c
--- a/xen/arch/x86/hvm/vpt.c    Mon Apr 18 10:10:02 2011 +0100
+++ b/xen/arch/x86/hvm/vpt.c    Thu Dec 22 11:35:36 2011 +0800
@@ -185,7 +185,7 @@

     list_for_each_entry ( pt, head, list )
     {
-        if ( pt->pending_intr_nr == 0 )
+        if ( pt->pending_intr_nr == 0 && !pt->do_not_freeze)
         {
             pt_process_missed_ticks(pt);
             set_timer(&pt->timer, pt->scheduled);


> -----Original Message-----
> From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-
> bounces@lists.xensource.com] On Behalf Of andrew thomas
> Sent: Tuesday, December 20, 2011 7:10 AM
> To: xen-devel@lists.xensource.com
> Cc: andrew.thomas@oracle.com
> Subject: [Xen-devel] issue with PLE and/or scheduler
> 
> This is with xen-4.1-testing cs 23201:1c89f7d29fbb and using the default
> "credit" scheduler.
> 
> I've run into an interesting issue with HVM guests which make use of Pause
> Loop Exiting (ie. on westmere systems; and also on romley systems):  after
> yielding the cpu, guests don't seem to receive timer interrupts correctly..
> 
> Some background: for historical reasons (ie old templates) we boot OL/RHEL
> guests with the following settings:
> 
> kernel parameters: clock=pit nohpet nopmtimer
> vm.cfg: timer_mode = 2
> 
> With PLE enabled, 2.6.32 guests will crash early on with:
>   ..MP-BIOS bug: 8254 timer not connected to IO-APIC
>   # a few lines omitted..
>   Kernel panic - not syncing: IO-APIC + timer doesn't work!  Boot with
> apic=debug
> 
> While 2.6.18-238 (ie OL/RHEL5u6) will fail to find the timer, but continue and
> lock up in the serial line initialization.
> 
>   ..MP-BIOS bug: 8254 timer not connected to IO-APIC
>   # continues until lock up here:
>   Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled
> 
> Instrumenting the 2.6.32 code (ie timer_irq_works()) shows that jiffies isn't
> advancing (or only 1 or 2 ticks are being received, which is insufficient for
> "working"). This is on a "quiet" system with no other activity.
> So, even though the guest has voluntarily yielded the cpu (through PLE), I
> would still expect it to receive every clock tick (even with timer_mode=2) as
> there is no other work to do on the system.
> 
> Disabling PLE allows both 2.6.18 and 2.6.32 guests to boot.. [As an aside, so
> does setting ple_gap to
> 41 (ie prior to 21355:727ccaaa6cce) -- the perf counters show no exits
> happening, so this is equivalent to disabling PLE.]
> 
> I'm hoping someone who knows the scheduler well will be able to quickly
> decide whether this is a bug or a feature...
> 
> Andrew
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 23 02:46:01 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 Dec 2011 02:46:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rdv8E-0007uT-La; Fri, 23 Dec 2011 02:45:14 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <xiantao.zhang@intel.com>) id 1Rdv8C-0007uL-TT
	for xen-devel@lists.xensource.com; Fri, 23 Dec 2011 02:45:13 +0000
X-Env-Sender: xiantao.zhang@intel.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1324608305!9032098!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDMwMjEwMQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31183 invoked from network); 23 Dec 2011 02:45:06 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-10.tower-21.messagelabs.com with SMTP;
	23 Dec 2011 02:45:06 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga101.fm.intel.com with ESMTP; 22 Dec 2011 18:45:03 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="105323595"
Received: from pgsmsx601.gar.corp.intel.com ([10.221.43.69])
	by fmsmga002.fm.intel.com with ESMTP; 22 Dec 2011 18:45:03 -0800
Received: from pgsmsx102.gar.corp.intel.com (10.221.44.80) by
	pgsmsx601.gar.corp.intel.com (10.221.43.69) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Fri, 23 Dec 2011 10:44:15 +0800
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	PGSMSX102.gar.corp.intel.com (10.221.44.80) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Fri, 23 Dec 2011 10:44:15 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.38]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.223]) with mapi id
	14.01.0355.002; Fri, 23 Dec 2011 10:44:14 +0800
From: "Zhang, Xiantao" <xiantao.zhang@intel.com>
To: andrew thomas <andrew.thomas@oracle.com>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>
Thread-Topic: [Xen-devel] issue with PLE and/or scheduler
Thread-Index: Acy/2fmuB+fO6Wm2ThS+i7cJne3PaQBQox3Q
Date: Fri, 23 Dec 2011 02:44:13 +0000
Message-ID: <B6C2EB9186482D47BD0C5A9A48345644B646@SHSMSX101.ccr.corp.intel.com>
References: <4EEFC462.2020307@oracle.com>
In-Reply-To: <4EEFC462.2020307@oracle.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Subject: Re: [Xen-devel] issue with PLE and/or scheduler
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Andrew, 
   Can you try this patch to see whether to fix your  issue ? 
Xiantao

diff -r 381ab77db71a xen/arch/x86/hvm/vpt.c
--- a/xen/arch/x86/hvm/vpt.c    Mon Apr 18 10:10:02 2011 +0100
+++ b/xen/arch/x86/hvm/vpt.c    Thu Dec 22 11:35:36 2011 +0800
@@ -185,7 +185,7 @@

     list_for_each_entry ( pt, head, list )
     {
-        if ( pt->pending_intr_nr == 0 )
+        if ( pt->pending_intr_nr == 0 && !pt->do_not_freeze)
         {
             pt_process_missed_ticks(pt);
             set_timer(&pt->timer, pt->scheduled);


> -----Original Message-----
> From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-
> bounces@lists.xensource.com] On Behalf Of andrew thomas
> Sent: Tuesday, December 20, 2011 7:10 AM
> To: xen-devel@lists.xensource.com
> Cc: andrew.thomas@oracle.com
> Subject: [Xen-devel] issue with PLE and/or scheduler
> 
> This is with xen-4.1-testing cs 23201:1c89f7d29fbb and using the default
> "credit" scheduler.
> 
> I've run into an interesting issue with HVM guests which make use of Pause
> Loop Exiting (ie. on westmere systems; and also on romley systems):  after
> yielding the cpu, guests don't seem to receive timer interrupts correctly..
> 
> Some background: for historical reasons (ie old templates) we boot OL/RHEL
> guests with the following settings:
> 
> kernel parameters: clock=pit nohpet nopmtimer
> vm.cfg: timer_mode = 2
> 
> With PLE enabled, 2.6.32 guests will crash early on with:
>   ..MP-BIOS bug: 8254 timer not connected to IO-APIC
>   # a few lines omitted..
>   Kernel panic - not syncing: IO-APIC + timer doesn't work!  Boot with
> apic=debug
> 
> While 2.6.18-238 (ie OL/RHEL5u6) will fail to find the timer, but continue and
> lock up in the serial line initialization.
> 
>   ..MP-BIOS bug: 8254 timer not connected to IO-APIC
>   # continues until lock up here:
>   Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled
> 
> Instrumenting the 2.6.32 code (ie timer_irq_works()) shows that jiffies isn't
> advancing (or only 1 or 2 ticks are being received, which is insufficient for
> "working"). This is on a "quiet" system with no other activity.
> So, even though the guest has voluntarily yielded the cpu (through PLE), I
> would still expect it to receive every clock tick (even with timer_mode=2) as
> there is no other work to do on the system.
> 
> Disabling PLE allows both 2.6.18 and 2.6.32 guests to boot.. [As an aside, so
> does setting ple_gap to
> 41 (ie prior to 21355:727ccaaa6cce) -- the perf counters show no exits
> happening, so this is equivalent to disabling PLE.]
> 
> I'm hoping someone who knows the scheduler well will be able to quickly
> decide whether this is a bug or a feature...
> 
> Andrew
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 23 02:49:31 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 Dec 2011 02:49:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdvBk-00080T-A3; Fri, 23 Dec 2011 02:48:52 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <gang.wei@intel.com>) id 1RdvBi-00080F-Kx
	for xen-devel@lists.xensource.com; Fri, 23 Dec 2011 02:48:50 +0000
X-Env-Sender: gang.wei@intel.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1324608523!8517487!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDMwMjEwMQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2398 invoked from network); 23 Dec 2011 02:48:43 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-7.tower-216.messagelabs.com with SMTP;
	23 Dec 2011 02:48:43 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga101.fm.intel.com with ESMTP; 22 Dec 2011 18:48:41 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="105324609"
Received: from pgsmsx601.gar.corp.intel.com ([10.221.43.69])
	by fmsmga002.fm.intel.com with ESMTP; 22 Dec 2011 18:48:40 -0800
Received: from pgsmsx103.gar.corp.intel.com (10.221.44.82) by
	pgsmsx601.gar.corp.intel.com (10.221.43.69) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Fri, 23 Dec 2011 10:48:39 +0800
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	PGSMSX103.gar.corp.intel.com (10.221.44.82) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Fri, 23 Dec 2011 10:48:39 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.38]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.223]) with mapi id
	14.01.0355.002; Fri, 23 Dec 2011 10:48:38 +0800
From: "Wei, Gang" <gang.wei@intel.com>
To: Tim Deegan <tim@xen.org>
Thread-Topic: [patch] x86: Add a delay between INIT & SIPIs for AP bring-up
	in X2APIC case
Thread-Index: AczAAslz2iL7OBXBT0+nwXPeOaB7qgARIT5gAAGReAAAMzbEEA==
Date: Fri, 23 Dec 2011 02:48:37 +0000
Message-ID: <D0B11485C64D4B47B66902F8A4E901BEA2B8@SHSMSX101.ccr.corp.intel.com>
References: <F26D193E20BBDC42A43B611D1BDEDE7135CEEEAE56@shsmsx502.ccr.corp.intel.com>
	<CB177C28.365E3%keir@xen.org>
	<F26D193E20BBDC42A43B611D1BDEDE7135CEEEAE63@shsmsx502.ccr.corp.intel.com>
	<F26D193E20BBDC42A43B611D1BDEDE7135CEEEAE65@shsmsx502.ccr.corp.intel.com>
	<20111221170539.GA72385@ocelot.phlegethon.org>
	<D0B11485C64D4B47B66902F8A4E901BE9146@SHSMSX101.ccr.corp.intel.com>
	<20111222100112.GA1900@ocelot.phlegethon.org>
In-Reply-To: <20111222100112.GA1900@ocelot.phlegethon.org>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, "Tim
	Deegan \(3P\)" <Tim.Deegan@citrix.com>, "Cihula,
	Joseph" <joseph.cihula@intel.com>,
	"tboot-devel@lists.sourceforge.net" <tboot-devel@lists.sourceforge.net>,
	Jan Beulich <jbeulich@suse.com>, "Wei, Gang" <gang.wei@intel.com>
Subject: Re: [Xen-devel] [patch] x86: Add a delay between INIT & SIPIs for
 AP bring-up in X2APIC case
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Tim Deegan wrote on=A02011-12-22:
>> Second, with tboot AP is actually spinning in a mini-guest before
>> receiving INIT, upon receiving INIT ipi, AP need time to VMExit,
>> update VMCS to tracking SIPIs and VMResume. After that SIPI is able
>> to be trapped by APs. This is MUST if giving no change to current AP
>> bring-up method(INIT-SIPI-SIPI) for tboot.
> =

> Oh I see - and the CPU blocks SIPIs in root mode; how inconvenient.
> Does tboot also need a delay between the two SIPIs then?

No. Tboot actually skip the second SIPI.

>> I have provided a resent patch with code comment in a previous reply.
> =

> Your comment should say _why_ -- in particular that while tboot is in
> root mode handling the INIT the CPU will drop any SIPIs.

Ok, I will add more words and resend it again.

> With that change, Ack.
> =

> Tim.

Jimmy

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 23 02:49:31 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 Dec 2011 02:49:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdvBk-00080T-A3; Fri, 23 Dec 2011 02:48:52 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <gang.wei@intel.com>) id 1RdvBi-00080F-Kx
	for xen-devel@lists.xensource.com; Fri, 23 Dec 2011 02:48:50 +0000
X-Env-Sender: gang.wei@intel.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1324608523!8517487!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDMwMjEwMQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2398 invoked from network); 23 Dec 2011 02:48:43 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-7.tower-216.messagelabs.com with SMTP;
	23 Dec 2011 02:48:43 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga101.fm.intel.com with ESMTP; 22 Dec 2011 18:48:41 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="105324609"
Received: from pgsmsx601.gar.corp.intel.com ([10.221.43.69])
	by fmsmga002.fm.intel.com with ESMTP; 22 Dec 2011 18:48:40 -0800
Received: from pgsmsx103.gar.corp.intel.com (10.221.44.82) by
	pgsmsx601.gar.corp.intel.com (10.221.43.69) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Fri, 23 Dec 2011 10:48:39 +0800
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	PGSMSX103.gar.corp.intel.com (10.221.44.82) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Fri, 23 Dec 2011 10:48:39 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.38]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.223]) with mapi id
	14.01.0355.002; Fri, 23 Dec 2011 10:48:38 +0800
From: "Wei, Gang" <gang.wei@intel.com>
To: Tim Deegan <tim@xen.org>
Thread-Topic: [patch] x86: Add a delay between INIT & SIPIs for AP bring-up
	in X2APIC case
Thread-Index: AczAAslz2iL7OBXBT0+nwXPeOaB7qgARIT5gAAGReAAAMzbEEA==
Date: Fri, 23 Dec 2011 02:48:37 +0000
Message-ID: <D0B11485C64D4B47B66902F8A4E901BEA2B8@SHSMSX101.ccr.corp.intel.com>
References: <F26D193E20BBDC42A43B611D1BDEDE7135CEEEAE56@shsmsx502.ccr.corp.intel.com>
	<CB177C28.365E3%keir@xen.org>
	<F26D193E20BBDC42A43B611D1BDEDE7135CEEEAE63@shsmsx502.ccr.corp.intel.com>
	<F26D193E20BBDC42A43B611D1BDEDE7135CEEEAE65@shsmsx502.ccr.corp.intel.com>
	<20111221170539.GA72385@ocelot.phlegethon.org>
	<D0B11485C64D4B47B66902F8A4E901BE9146@SHSMSX101.ccr.corp.intel.com>
	<20111222100112.GA1900@ocelot.phlegethon.org>
In-Reply-To: <20111222100112.GA1900@ocelot.phlegethon.org>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, "Tim
	Deegan \(3P\)" <Tim.Deegan@citrix.com>, "Cihula,
	Joseph" <joseph.cihula@intel.com>,
	"tboot-devel@lists.sourceforge.net" <tboot-devel@lists.sourceforge.net>,
	Jan Beulich <jbeulich@suse.com>, "Wei, Gang" <gang.wei@intel.com>
Subject: Re: [Xen-devel] [patch] x86: Add a delay between INIT & SIPIs for
 AP bring-up in X2APIC case
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Tim Deegan wrote on=A02011-12-22:
>> Second, with tboot AP is actually spinning in a mini-guest before
>> receiving INIT, upon receiving INIT ipi, AP need time to VMExit,
>> update VMCS to tracking SIPIs and VMResume. After that SIPI is able
>> to be trapped by APs. This is MUST if giving no change to current AP
>> bring-up method(INIT-SIPI-SIPI) for tboot.
> =

> Oh I see - and the CPU blocks SIPIs in root mode; how inconvenient.
> Does tboot also need a delay between the two SIPIs then?

No. Tboot actually skip the second SIPI.

>> I have provided a resent patch with code comment in a previous reply.
> =

> Your comment should say _why_ -- in particular that while tboot is in
> root mode handling the INIT the CPU will drop any SIPIs.

Ok, I will add more words and resend it again.

> With that change, Ack.
> =

> Tim.

Jimmy

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 23 03:01:58 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 Dec 2011 03:01:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdvNv-0008G5-J7; Fri, 23 Dec 2011 03:01:27 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1RdvNu-0008G0-LH
	for xen-devel@lists.xensource.com; Fri, 23 Dec 2011 03:01:26 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-15.tower-216.messagelabs.com!1324609278!8499168!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2303 invoked from network); 23 Dec 2011 03:01:20 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-15.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 23 Dec 2011 03:01:20 -0000
Received: from andromeda.dapyr.net (darnok@localhost [127.0.0.1])
	by andromeda.dapyr.net (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id
	pBN316hh007957
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Thu, 22 Dec 2011 22:01:06 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pBN313eu007951;
	Thu, 22 Dec 2011 22:01:03 -0500
Date: Thu, 22 Dec 2011 23:01:03 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: "Tian, Kevin" <kevin.tian@intel.com>
Message-ID: <20111223030103.GA7218@andromeda.dapyr.net>
References: <1322673664-14642-1-git-send-email-konrad.wilk@oracle.com>
	<1322673664-14642-4-git-send-email-konrad.wilk@oracle.com>
	<20111216220342.GC9832@phenom.dumpdata.com>
	<625BA99ED14B2D499DC4E29D8138F1506E01AABC7A@shsmsx502.ccr.corp.intel.com>
	<20111219142626.GB27772@andromeda.dapyr.net>
	<625BA99ED14B2D499DC4E29D8138F1506E01AAC03A@shsmsx502.ccr.corp.intel.com>
	<20111220153145.GB13253@andromeda.dapyr.net>
	<625BA99ED14B2D499DC4E29D8138F1506E01AAC469@shsmsx502.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <625BA99ED14B2D499DC4E29D8138F1506E01AAC469@shsmsx502.ccr.corp.intel.com>
User-Agent: Mutt/1.5.9i
Cc: "jeremy@goop.org" <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"mike.mcclurg@citrix.com" <mike.mcclurg@citrix.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"stefan.bader@canonical.com" <stefan.bader@canonical.com>,
	"rjw@sisk.pl" <rjw@sisk.pl>,
	"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
	"liang.tang@oracle.com" <liang.tang@oracle.com>, "Yu,
	Ke" <ke.yu@intel.com>, "konrad@kernel.org" <konrad@kernel.org>,
	"lenb@kernel.org" <lenb@kernel.org>
Subject: Re: [Xen-devel] [PATCH 3/8] ACPI: processor: add
	__acpi_processor_[un]register_driver helpers.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> > OK. Lets put the # VCPU != PCPU aside. Say dom0 will boot with all
> > CPUs and then later on the admin starts unplugging them.
> 
> This should be communicated to major Xen based distributions, so that it's
> an agreed approach since in majority case dom0 is configured as UP or
> a few VCPUs.

I am not saying that is it the agreed approach. There has to be
flexibility in supporting both. But what I want to understand whether
the requirement for VCPU != PCPU can be put aside and put in the drivers
later on.

So that the first approach is not changing the generic drivers (much).
The reason I am asking about this is two-fold:
 1). For new distros (Ubuntu, Fedora), the default is all VCPUs.
     Enterprising users might use dom0_max_vcpus to limit the VCPU count,
     but most won't.
     Which mean we can concentrate on bringing the _Pxx/_Cxx parsing
     up to the hypervisor. Which is really neccessary on any chipset
     which has the notion of TurboBoost (otherwise the Xen scheduler
     won't pick this up and won't engage this mode in certain
     workloads).
 2). The ACPI maintainers are busy with ACPI 5.0. I don't know how
     much work this is, but it probably means tons of stuff with
     embedded platforms and tons of regression testing. So if there
     is a patch that does not impact the generic code much (or any)
     it will make their life easier. Which also means we can built
     on top that for the VCPU != PCPU case.

That is what I am trying to understand.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 23 03:01:58 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 Dec 2011 03:01:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdvNv-0008G5-J7; Fri, 23 Dec 2011 03:01:27 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1RdvNu-0008G0-LH
	for xen-devel@lists.xensource.com; Fri, 23 Dec 2011 03:01:26 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-15.tower-216.messagelabs.com!1324609278!8499168!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2303 invoked from network); 23 Dec 2011 03:01:20 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-15.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 23 Dec 2011 03:01:20 -0000
Received: from andromeda.dapyr.net (darnok@localhost [127.0.0.1])
	by andromeda.dapyr.net (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id
	pBN316hh007957
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Thu, 22 Dec 2011 22:01:06 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pBN313eu007951;
	Thu, 22 Dec 2011 22:01:03 -0500
Date: Thu, 22 Dec 2011 23:01:03 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: "Tian, Kevin" <kevin.tian@intel.com>
Message-ID: <20111223030103.GA7218@andromeda.dapyr.net>
References: <1322673664-14642-1-git-send-email-konrad.wilk@oracle.com>
	<1322673664-14642-4-git-send-email-konrad.wilk@oracle.com>
	<20111216220342.GC9832@phenom.dumpdata.com>
	<625BA99ED14B2D499DC4E29D8138F1506E01AABC7A@shsmsx502.ccr.corp.intel.com>
	<20111219142626.GB27772@andromeda.dapyr.net>
	<625BA99ED14B2D499DC4E29D8138F1506E01AAC03A@shsmsx502.ccr.corp.intel.com>
	<20111220153145.GB13253@andromeda.dapyr.net>
	<625BA99ED14B2D499DC4E29D8138F1506E01AAC469@shsmsx502.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <625BA99ED14B2D499DC4E29D8138F1506E01AAC469@shsmsx502.ccr.corp.intel.com>
User-Agent: Mutt/1.5.9i
Cc: "jeremy@goop.org" <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"mike.mcclurg@citrix.com" <mike.mcclurg@citrix.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"stefan.bader@canonical.com" <stefan.bader@canonical.com>,
	"rjw@sisk.pl" <rjw@sisk.pl>,
	"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
	"liang.tang@oracle.com" <liang.tang@oracle.com>, "Yu,
	Ke" <ke.yu@intel.com>, "konrad@kernel.org" <konrad@kernel.org>,
	"lenb@kernel.org" <lenb@kernel.org>
Subject: Re: [Xen-devel] [PATCH 3/8] ACPI: processor: add
	__acpi_processor_[un]register_driver helpers.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> > OK. Lets put the # VCPU != PCPU aside. Say dom0 will boot with all
> > CPUs and then later on the admin starts unplugging them.
> 
> This should be communicated to major Xen based distributions, so that it's
> an agreed approach since in majority case dom0 is configured as UP or
> a few VCPUs.

I am not saying that is it the agreed approach. There has to be
flexibility in supporting both. But what I want to understand whether
the requirement for VCPU != PCPU can be put aside and put in the drivers
later on.

So that the first approach is not changing the generic drivers (much).
The reason I am asking about this is two-fold:
 1). For new distros (Ubuntu, Fedora), the default is all VCPUs.
     Enterprising users might use dom0_max_vcpus to limit the VCPU count,
     but most won't.
     Which mean we can concentrate on bringing the _Pxx/_Cxx parsing
     up to the hypervisor. Which is really neccessary on any chipset
     which has the notion of TurboBoost (otherwise the Xen scheduler
     won't pick this up and won't engage this mode in certain
     workloads).
 2). The ACPI maintainers are busy with ACPI 5.0. I don't know how
     much work this is, but it probably means tons of stuff with
     embedded platforms and tons of regression testing. So if there
     is a patch that does not impact the generic code much (or any)
     it will make their life easier. Which also means we can built
     on top that for the VCPU != PCPU case.

That is what I am trying to understand.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 23 03:06:43 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 Dec 2011 03:06:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdvSf-0008Ol-De; Fri, 23 Dec 2011 03:06:21 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1RdvSe-0008Oe-98
	for xen-devel@lists.xensource.com; Fri, 23 Dec 2011 03:06:20 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-9.tower-21.messagelabs.com!1324609571!3049516!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4776 invoked from network); 23 Dec 2011 03:06:13 -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; 23 Dec 2011 03:06:13 -0000
Received: from andromeda.dapyr.net (darnok@localhost [127.0.0.1])
	by andromeda.dapyr.net (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id
	pBN368J1008872
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Thu, 22 Dec 2011 22:06:08 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pBN368g0008870;
	Thu, 22 Dec 2011 22:06:08 -0500
Date: Thu, 22 Dec 2011 23:06:08 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: "Liu, Jinsong" <jinsong.liu@intel.com>
Message-ID: <20111223030608.GB7218@andromeda.dapyr.net>
References: <DE8DF0795D48FD4CA783C40EC829233587C7@SHSMSX101.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <DE8DF0795D48FD4CA783C40EC829233587C7@SHSMSX101.ccr.corp.intel.com>
User-Agent: Mutt/1.5.9i
Cc: "Jiang, Yunhong" <yunhong.jiang@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"jeremy.fitzhardinge@citrix.com" <jeremy.fitzhardinge@citrix.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] Linux 3.1.0 Xen RAS rebase
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Dec 22, 2011 at 09:57:55AM +0000, Liu, Jinsong wrote:
> Recently we did dom0 Xen RAS rebase work.

Hey Liu,

Thank you for posting this. Couple of questions:
 1). How does one test these patches?
 2). Please CC LKML and also the ACPI maintainer - since a majority
     of this also touch their tree. And the memory hotadd maintainer
     as well.
 3). Can any of this code (like the MCE) leverage the existing
     generic code?
 4). Have you guys talked with Len Brown (the ACPI maintainer)
     about some of this code and how to make it fit within his
     goals?

Thanks!
> 
> Basically it rebased from Jeremy's pvops (2.6.32), to Konrad's pvops (3.1.0, branch "devel/acpi-cpufreq.v3")
> patch 1: for mcelog logic
> patch 2: for dom0 vmce
> patch 3: for cpu sysfs and cpu online/offline
> patch 4: for cpu hotadd
> patch 5: for memory hotadd prepare work
> patch 6: for memory hotadd
> patch 7: for cpu hotadd prepare work
> patch 8: complement cpu hotadd lacked at Konrad's tree
> patch 9: update PM logic
> patch 10: upate cpu online/offline logic
> 
> 
> Thanks,
> Jinsong
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 23 03:06:43 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 Dec 2011 03:06:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdvSf-0008Ol-De; Fri, 23 Dec 2011 03:06:21 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1RdvSe-0008Oe-98
	for xen-devel@lists.xensource.com; Fri, 23 Dec 2011 03:06:20 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-9.tower-21.messagelabs.com!1324609571!3049516!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4776 invoked from network); 23 Dec 2011 03:06:13 -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; 23 Dec 2011 03:06:13 -0000
Received: from andromeda.dapyr.net (darnok@localhost [127.0.0.1])
	by andromeda.dapyr.net (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id
	pBN368J1008872
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Thu, 22 Dec 2011 22:06:08 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pBN368g0008870;
	Thu, 22 Dec 2011 22:06:08 -0500
Date: Thu, 22 Dec 2011 23:06:08 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: "Liu, Jinsong" <jinsong.liu@intel.com>
Message-ID: <20111223030608.GB7218@andromeda.dapyr.net>
References: <DE8DF0795D48FD4CA783C40EC829233587C7@SHSMSX101.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <DE8DF0795D48FD4CA783C40EC829233587C7@SHSMSX101.ccr.corp.intel.com>
User-Agent: Mutt/1.5.9i
Cc: "Jiang, Yunhong" <yunhong.jiang@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"jeremy.fitzhardinge@citrix.com" <jeremy.fitzhardinge@citrix.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] Linux 3.1.0 Xen RAS rebase
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Dec 22, 2011 at 09:57:55AM +0000, Liu, Jinsong wrote:
> Recently we did dom0 Xen RAS rebase work.

Hey Liu,

Thank you for posting this. Couple of questions:
 1). How does one test these patches?
 2). Please CC LKML and also the ACPI maintainer - since a majority
     of this also touch their tree. And the memory hotadd maintainer
     as well.
 3). Can any of this code (like the MCE) leverage the existing
     generic code?
 4). Have you guys talked with Len Brown (the ACPI maintainer)
     about some of this code and how to make it fit within his
     goals?

Thanks!
> 
> Basically it rebased from Jeremy's pvops (2.6.32), to Konrad's pvops (3.1.0, branch "devel/acpi-cpufreq.v3")
> patch 1: for mcelog logic
> patch 2: for dom0 vmce
> patch 3: for cpu sysfs and cpu online/offline
> patch 4: for cpu hotadd
> patch 5: for memory hotadd prepare work
> patch 6: for memory hotadd
> patch 7: for cpu hotadd prepare work
> patch 8: complement cpu hotadd lacked at Konrad's tree
> patch 9: update PM logic
> patch 10: upate cpu online/offline logic
> 
> 
> Thanks,
> Jinsong
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 23 03:15:29 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 Dec 2011 03:15:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rdvb3-00008t-Fk; Fri, 23 Dec 2011 03:15:01 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <gang.wei@intel.com>) id 1Rdvb0-00008m-Vb
	for xen-devel@lists.xensource.com; Fri, 23 Dec 2011 03:14:59 +0000
X-Env-Sender: gang.wei@intel.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1324610091!6637834!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDMwMjEwMQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9799 invoked from network); 23 Dec 2011 03:14:52 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-5.tower-174.messagelabs.com with SMTP;
	23 Dec 2011 03:14:52 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga101.fm.intel.com with ESMTP; 22 Dec 2011 19:14:51 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="99542871"
Received: from pgsmsx603.gar.corp.intel.com ([10.221.43.87])
	by fmsmga001.fm.intel.com with ESMTP; 22 Dec 2011 19:14:49 -0800
Received: from pgsmsx509.gar.corp.intel.com (172.30.13.17) by
	pgsmsx603.gar.corp.intel.com (10.221.43.87) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Fri, 23 Dec 2011 11:14:44 +0800
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	PGSMSX509.gar.corp.intel.com (172.30.13.17) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Fri, 23 Dec 2011 11:14:43 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.38]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.223]) with mapi id
	14.01.0355.002; Fri, 23 Dec 2011 11:14:42 +0800
From: "Wei, Gang" <gang.wei@intel.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Thread-Topic: [patch] x86: Add a delay between INIT & SIPIs for tboot AP
	bring-up in X2APIC case
Thread-Index: AczAAslz2iL7OBXBT0+nwXPeOaB7qgARIT5gAAGReAAAMzbEEAABRG/A
Date: Fri, 23 Dec 2011 03:14:41 +0000
Message-ID: <D0B11485C64D4B47B66902F8A4E901BEA302@SHSMSX101.ccr.corp.intel.com>
References: <F26D193E20BBDC42A43B611D1BDEDE7135CEEEAE56@shsmsx502.ccr.corp.intel.com>
	<CB177C28.365E3%keir@xen.org>
	<F26D193E20BBDC42A43B611D1BDEDE7135CEEEAE63@shsmsx502.ccr.corp.intel.com>
	<F26D193E20BBDC42A43B611D1BDEDE7135CEEEAE65@shsmsx502.ccr.corp.intel.com>
	<20111221170539.GA72385@ocelot.phlegethon.org>
	<D0B11485C64D4B47B66902F8A4E901BE9146@SHSMSX101.ccr.corp.intel.com>
	<20111222100112.GA1900@ocelot.phlegethon.org>
	<D0B11485C64D4B47B66902F8A4E901BEA2B8@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <D0B11485C64D4B47B66902F8A4E901BEA2B8@SHSMSX101.ccr.corp.intel.com>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
Content-Type: multipart/mixed;
	boundary="_002_D0B11485C64D4B47B66902F8A4E901BEA302SHSMSX101ccrcorpint_"
MIME-Version: 1.0
Cc: "Keir \(Xen.org\)" <keir@xen.org>, "Tim
	Deegan \(3P\)" <Tim.Deegan@citrix.com>, "Cihula,
	Joseph" <joseph.cihula@intel.com>, Tim Deegan <tim@xen.org>,
	"tboot-devel@lists.sourceforge.net" <tboot-devel@lists.sourceforge.net>,
	Jan Beulich <jbeulich@suse.com>, "Wei, Gang" <gang.wei@intel.com>
Subject: [Xen-devel] [patch] x86: Add a delay between INIT & SIPIs for tboot
 AP bring-up in X2APIC case
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--_002_D0B11485C64D4B47B66902F8A4E901BEA302SHSMSX101ccrcorpint_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Without this delay, Xen could not bring APs up while working with TXT/tboot=
, because tboot need some time in APs to handle INIT before becoming ready =
for receiving SIPIs.(this delay was removed as part of c/s 23724 by Tim Dee=
gan)

Signed-off-by: Gang Wei <gang.wei@intel.com>
Acked-by: Keir Fraser <keir@xen.org>
Acked-by: Tim Deegan <tim.deegan@citrix.com>

diff -r d1aefee43af1 xen/arch/x86/smpboot.c
--- a/xen/arch/x86/smpboot.c	Wed Dec 21 18:51:31 2011 +0800
+++ b/xen/arch/x86/smpboot.c	Fri Dec 23 11:01:10 2011 +0800
@@ -42,6 +42,7 @@
 #include <asm/msr.h>
 #include <asm/mtrr.h>
 #include <asm/time.h>
+#include <asm/tboot.h>
 #include <mach_apic.h>
 #include <mach_wakecpu.h>
 #include <smpboot_hooks.h>
@@ -463,6 +464,18 @@
             send_status =3D apic_read(APIC_ICR) & APIC_ICR_BUSY;
         } while ( send_status && (timeout++ < 1000) );
     }
+    else if ( tboot_in_measured_env() )
+    {
+        /*
+         * With tboot AP is actually spinning in a mini-guest before=20
+         * receiving INIT. Upon receiving INIT ipi, AP need time to VMExit=
,=20
+         * update VMCS to tracking SIPIs and VMResume.
+         *
+         * While AP is in root mode handling the INIT the CPU will drop
+         * any SIPIs
+         */
+        udelay(10);
+    }
=20
     /*
      * Should we send STARTUP IPIs ?

--_002_D0B11485C64D4B47B66902F8A4E901BEA302SHSMSX101ccrcorpint_
Content-Type: application/octet-stream; name="delay-btw-init-and-sipi.patch"
Content-Description: delay-btw-init-and-sipi.patch
Content-Disposition: attachment; filename="delay-btw-init-and-sipi.patch";
	size=1397; creation-date="Fri, 23 Dec 2011 03:05:03 GMT";
	modification-date="Fri, 23 Dec 2011 03:12:17 GMT"
Content-Transfer-Encoding: base64

WDg2OiBBZGQgYSBkZWxheSBiZXR3ZWVuIElOSVQgJiBTSVBJcyBmb3IgdGJvb3QgQVAgYnJpbmct
dXAgaW4gWDJBUElDIGNhc2UKCldpdGhvdXQgdGhpcyBkZWxheSwgWGVuIGNvdWxkIG5vdCBicmlu
ZyBBUHMgdXAgd2hpbGUgd29ya2luZyB3aXRoIFRYVC90Ym9vdCwgYmVjYXVzZSB0Ym9vdCBuZWVk
IHNvbWUgdGltZSBpbiBBUHMgdG8gaGFuZGxlIElOSVQgYmVmb3JlIGJlY29taW5nIHJlYWR5IGZv
ciByZWNlaXZpbmcgU0lQSXMuKHRoaXMgZGVsYXkgd2FzIHJlbW92ZWQgYXMgcGFydCBvZiBjL3Mg
MjM3MjQgYnkgVGltIERlZWdhbikKClNpZ25lZC1vZmYtYnk6IEdhbmcgV2VpIDxnYW5nLndlaUBp
bnRlbC5jb20+CkFja2VkLWJ5OiBLZWlyIEZyYXNlciA8a2VpckB4ZW4ub3JnPgpBY2tlZC1ieTog
VGltIERlZWdhbiA8dGltLmRlZWdhbkBjaXRyaXguY29tPgoKZGlmZiAtciBkMWFlZmVlNDNhZjEg
eGVuL2FyY2gveDg2L3NtcGJvb3QuYwotLS0gYS94ZW4vYXJjaC94ODYvc21wYm9vdC5jCVdlZCBE
ZWMgMjEgMTg6NTE6MzEgMjAxMSArMDgwMAorKysgYi94ZW4vYXJjaC94ODYvc21wYm9vdC5jCUZy
aSBEZWMgMjMgMTE6MDE6MTAgMjAxMSArMDgwMApAQCAtNDIsNiArNDIsNyBAQAogI2luY2x1ZGUg
PGFzbS9tc3IuaD4KICNpbmNsdWRlIDxhc20vbXRyci5oPgogI2luY2x1ZGUgPGFzbS90aW1lLmg+
CisjaW5jbHVkZSA8YXNtL3Rib290Lmg+CiAjaW5jbHVkZSA8bWFjaF9hcGljLmg+CiAjaW5jbHVk
ZSA8bWFjaF93YWtlY3B1Lmg+CiAjaW5jbHVkZSA8c21wYm9vdF9ob29rcy5oPgpAQCAtNDYzLDYg
KzQ2NCwxOCBAQAogICAgICAgICAgICAgc2VuZF9zdGF0dXMgPSBhcGljX3JlYWQoQVBJQ19JQ1Ip
ICYgQVBJQ19JQ1JfQlVTWTsKICAgICAgICAgfSB3aGlsZSAoIHNlbmRfc3RhdHVzICYmICh0aW1l
b3V0KysgPCAxMDAwKSApOwogICAgIH0KKyAgICBlbHNlIGlmICggdGJvb3RfaW5fbWVhc3VyZWRf
ZW52KCkgKQorICAgIHsKKyAgICAgICAgLyoKKyAgICAgICAgICogV2l0aCB0Ym9vdCBBUCBpcyBh
Y3R1YWxseSBzcGlubmluZyBpbiBhIG1pbmktZ3Vlc3QgYmVmb3JlIAorICAgICAgICAgKiByZWNl
aXZpbmcgSU5JVC4gVXBvbiByZWNlaXZpbmcgSU5JVCBpcGksIEFQIG5lZWQgdGltZSB0byBWTUV4
aXQsIAorICAgICAgICAgKiB1cGRhdGUgVk1DUyB0byB0cmFja2luZyBTSVBJcyBhbmQgVk1SZXN1
bWUuCisgICAgICAgICAqCisgICAgICAgICAqIFdoaWxlIEFQIGlzIGluIHJvb3QgbW9kZSBoYW5k
bGluZyB0aGUgSU5JVCB0aGUgQ1BVIHdpbGwgZHJvcAorICAgICAgICAgKiBhbnkgU0lQSXMKKyAg
ICAgICAgICovCisgICAgICAgIHVkZWxheSgxMCk7CisgICAgfQogCiAgICAgLyoKICAgICAgKiBT
aG91bGQgd2Ugc2VuZCBTVEFSVFVQIElQSXMgPwo=

--_002_D0B11485C64D4B47B66902F8A4E901BEA302SHSMSX101ccrcorpint_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--_002_D0B11485C64D4B47B66902F8A4E901BEA302SHSMSX101ccrcorpint_--


From xen-devel-bounces@lists.xensource.com Fri Dec 23 03:15:29 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 Dec 2011 03:15:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rdvb3-00008t-Fk; Fri, 23 Dec 2011 03:15:01 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <gang.wei@intel.com>) id 1Rdvb0-00008m-Vb
	for xen-devel@lists.xensource.com; Fri, 23 Dec 2011 03:14:59 +0000
X-Env-Sender: gang.wei@intel.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1324610091!6637834!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDMwMjEwMQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9799 invoked from network); 23 Dec 2011 03:14:52 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-5.tower-174.messagelabs.com with SMTP;
	23 Dec 2011 03:14:52 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga101.fm.intel.com with ESMTP; 22 Dec 2011 19:14:51 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="99542871"
Received: from pgsmsx603.gar.corp.intel.com ([10.221.43.87])
	by fmsmga001.fm.intel.com with ESMTP; 22 Dec 2011 19:14:49 -0800
Received: from pgsmsx509.gar.corp.intel.com (172.30.13.17) by
	pgsmsx603.gar.corp.intel.com (10.221.43.87) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Fri, 23 Dec 2011 11:14:44 +0800
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	PGSMSX509.gar.corp.intel.com (172.30.13.17) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Fri, 23 Dec 2011 11:14:43 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.38]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.223]) with mapi id
	14.01.0355.002; Fri, 23 Dec 2011 11:14:42 +0800
From: "Wei, Gang" <gang.wei@intel.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Thread-Topic: [patch] x86: Add a delay between INIT & SIPIs for tboot AP
	bring-up in X2APIC case
Thread-Index: AczAAslz2iL7OBXBT0+nwXPeOaB7qgARIT5gAAGReAAAMzbEEAABRG/A
Date: Fri, 23 Dec 2011 03:14:41 +0000
Message-ID: <D0B11485C64D4B47B66902F8A4E901BEA302@SHSMSX101.ccr.corp.intel.com>
References: <F26D193E20BBDC42A43B611D1BDEDE7135CEEEAE56@shsmsx502.ccr.corp.intel.com>
	<CB177C28.365E3%keir@xen.org>
	<F26D193E20BBDC42A43B611D1BDEDE7135CEEEAE63@shsmsx502.ccr.corp.intel.com>
	<F26D193E20BBDC42A43B611D1BDEDE7135CEEEAE65@shsmsx502.ccr.corp.intel.com>
	<20111221170539.GA72385@ocelot.phlegethon.org>
	<D0B11485C64D4B47B66902F8A4E901BE9146@SHSMSX101.ccr.corp.intel.com>
	<20111222100112.GA1900@ocelot.phlegethon.org>
	<D0B11485C64D4B47B66902F8A4E901BEA2B8@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <D0B11485C64D4B47B66902F8A4E901BEA2B8@SHSMSX101.ccr.corp.intel.com>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
Content-Type: multipart/mixed;
	boundary="_002_D0B11485C64D4B47B66902F8A4E901BEA302SHSMSX101ccrcorpint_"
MIME-Version: 1.0
Cc: "Keir \(Xen.org\)" <keir@xen.org>, "Tim
	Deegan \(3P\)" <Tim.Deegan@citrix.com>, "Cihula,
	Joseph" <joseph.cihula@intel.com>, Tim Deegan <tim@xen.org>,
	"tboot-devel@lists.sourceforge.net" <tboot-devel@lists.sourceforge.net>,
	Jan Beulich <jbeulich@suse.com>, "Wei, Gang" <gang.wei@intel.com>
Subject: [Xen-devel] [patch] x86: Add a delay between INIT & SIPIs for tboot
 AP bring-up in X2APIC case
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--_002_D0B11485C64D4B47B66902F8A4E901BEA302SHSMSX101ccrcorpint_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Without this delay, Xen could not bring APs up while working with TXT/tboot=
, because tboot need some time in APs to handle INIT before becoming ready =
for receiving SIPIs.(this delay was removed as part of c/s 23724 by Tim Dee=
gan)

Signed-off-by: Gang Wei <gang.wei@intel.com>
Acked-by: Keir Fraser <keir@xen.org>
Acked-by: Tim Deegan <tim.deegan@citrix.com>

diff -r d1aefee43af1 xen/arch/x86/smpboot.c
--- a/xen/arch/x86/smpboot.c	Wed Dec 21 18:51:31 2011 +0800
+++ b/xen/arch/x86/smpboot.c	Fri Dec 23 11:01:10 2011 +0800
@@ -42,6 +42,7 @@
 #include <asm/msr.h>
 #include <asm/mtrr.h>
 #include <asm/time.h>
+#include <asm/tboot.h>
 #include <mach_apic.h>
 #include <mach_wakecpu.h>
 #include <smpboot_hooks.h>
@@ -463,6 +464,18 @@
             send_status =3D apic_read(APIC_ICR) & APIC_ICR_BUSY;
         } while ( send_status && (timeout++ < 1000) );
     }
+    else if ( tboot_in_measured_env() )
+    {
+        /*
+         * With tboot AP is actually spinning in a mini-guest before=20
+         * receiving INIT. Upon receiving INIT ipi, AP need time to VMExit=
,=20
+         * update VMCS to tracking SIPIs and VMResume.
+         *
+         * While AP is in root mode handling the INIT the CPU will drop
+         * any SIPIs
+         */
+        udelay(10);
+    }
=20
     /*
      * Should we send STARTUP IPIs ?

--_002_D0B11485C64D4B47B66902F8A4E901BEA302SHSMSX101ccrcorpint_
Content-Type: application/octet-stream; name="delay-btw-init-and-sipi.patch"
Content-Description: delay-btw-init-and-sipi.patch
Content-Disposition: attachment; filename="delay-btw-init-and-sipi.patch";
	size=1397; creation-date="Fri, 23 Dec 2011 03:05:03 GMT";
	modification-date="Fri, 23 Dec 2011 03:12:17 GMT"
Content-Transfer-Encoding: base64

WDg2OiBBZGQgYSBkZWxheSBiZXR3ZWVuIElOSVQgJiBTSVBJcyBmb3IgdGJvb3QgQVAgYnJpbmct
dXAgaW4gWDJBUElDIGNhc2UKCldpdGhvdXQgdGhpcyBkZWxheSwgWGVuIGNvdWxkIG5vdCBicmlu
ZyBBUHMgdXAgd2hpbGUgd29ya2luZyB3aXRoIFRYVC90Ym9vdCwgYmVjYXVzZSB0Ym9vdCBuZWVk
IHNvbWUgdGltZSBpbiBBUHMgdG8gaGFuZGxlIElOSVQgYmVmb3JlIGJlY29taW5nIHJlYWR5IGZv
ciByZWNlaXZpbmcgU0lQSXMuKHRoaXMgZGVsYXkgd2FzIHJlbW92ZWQgYXMgcGFydCBvZiBjL3Mg
MjM3MjQgYnkgVGltIERlZWdhbikKClNpZ25lZC1vZmYtYnk6IEdhbmcgV2VpIDxnYW5nLndlaUBp
bnRlbC5jb20+CkFja2VkLWJ5OiBLZWlyIEZyYXNlciA8a2VpckB4ZW4ub3JnPgpBY2tlZC1ieTog
VGltIERlZWdhbiA8dGltLmRlZWdhbkBjaXRyaXguY29tPgoKZGlmZiAtciBkMWFlZmVlNDNhZjEg
eGVuL2FyY2gveDg2L3NtcGJvb3QuYwotLS0gYS94ZW4vYXJjaC94ODYvc21wYm9vdC5jCVdlZCBE
ZWMgMjEgMTg6NTE6MzEgMjAxMSArMDgwMAorKysgYi94ZW4vYXJjaC94ODYvc21wYm9vdC5jCUZy
aSBEZWMgMjMgMTE6MDE6MTAgMjAxMSArMDgwMApAQCAtNDIsNiArNDIsNyBAQAogI2luY2x1ZGUg
PGFzbS9tc3IuaD4KICNpbmNsdWRlIDxhc20vbXRyci5oPgogI2luY2x1ZGUgPGFzbS90aW1lLmg+
CisjaW5jbHVkZSA8YXNtL3Rib290Lmg+CiAjaW5jbHVkZSA8bWFjaF9hcGljLmg+CiAjaW5jbHVk
ZSA8bWFjaF93YWtlY3B1Lmg+CiAjaW5jbHVkZSA8c21wYm9vdF9ob29rcy5oPgpAQCAtNDYzLDYg
KzQ2NCwxOCBAQAogICAgICAgICAgICAgc2VuZF9zdGF0dXMgPSBhcGljX3JlYWQoQVBJQ19JQ1Ip
ICYgQVBJQ19JQ1JfQlVTWTsKICAgICAgICAgfSB3aGlsZSAoIHNlbmRfc3RhdHVzICYmICh0aW1l
b3V0KysgPCAxMDAwKSApOwogICAgIH0KKyAgICBlbHNlIGlmICggdGJvb3RfaW5fbWVhc3VyZWRf
ZW52KCkgKQorICAgIHsKKyAgICAgICAgLyoKKyAgICAgICAgICogV2l0aCB0Ym9vdCBBUCBpcyBh
Y3R1YWxseSBzcGlubmluZyBpbiBhIG1pbmktZ3Vlc3QgYmVmb3JlIAorICAgICAgICAgKiByZWNl
aXZpbmcgSU5JVC4gVXBvbiByZWNlaXZpbmcgSU5JVCBpcGksIEFQIG5lZWQgdGltZSB0byBWTUV4
aXQsIAorICAgICAgICAgKiB1cGRhdGUgVk1DUyB0byB0cmFja2luZyBTSVBJcyBhbmQgVk1SZXN1
bWUuCisgICAgICAgICAqCisgICAgICAgICAqIFdoaWxlIEFQIGlzIGluIHJvb3QgbW9kZSBoYW5k
bGluZyB0aGUgSU5JVCB0aGUgQ1BVIHdpbGwgZHJvcAorICAgICAgICAgKiBhbnkgU0lQSXMKKyAg
ICAgICAgICovCisgICAgICAgIHVkZWxheSgxMCk7CisgICAgfQogCiAgICAgLyoKICAgICAgKiBT
aG91bGQgd2Ugc2VuZCBTVEFSVFVQIElQSXMgPwo=

--_002_D0B11485C64D4B47B66902F8A4E901BEA302SHSMSX101ccrcorpint_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--_002_D0B11485C64D4B47B66902F8A4E901BEA302SHSMSX101ccrcorpint_--


From xen-devel-bounces@lists.xensource.com Fri Dec 23 04:04:23 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 Dec 2011 04:04:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdwMD-0000qc-UO; Fri, 23 Dec 2011 04:03:45 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RdwMC-0000qX-BQ
	for xen-devel@lists.xensource.com; Fri, 23 Dec 2011 04:03:44 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1324613018!6636387!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODA5Ng==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8839 invoked from network); 23 Dec 2011 04:03:38 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Dec 2011 04:03:38 -0000
X-IronPort-AV: E=Sophos;i="4.71,397,1320624000"; 
   d="scan'208";a="9644921"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Dec 2011 04:03:37 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 23 Dec 2011 04:03:37 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RdwM4-0006xd-Oc;
	Fri, 23 Dec 2011 04:03:36 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RdwM4-0007Uh-NS;
	Fri, 23 Dec 2011 04:03:36 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10603-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 23 Dec 2011 04:03:36 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10603: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10603 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10603/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-pv          16 guest-start.2               fail pass in 10600
 test-amd64-amd64-xl-sedf     13 guest-localmigrate.2        fail pass in 10600
 test-i386-i386-win            7 windows-install             fail pass in 10600
 test-amd64-i386-xl-multivcpu 16 guest-start.2      fail in 10600 pass in 10603
 test-i386-i386-xl-win         7 windows-install    fail in 10600 pass in 10603
 test-amd64-i386-xl-win-vcpus1 12 guest-localmigrate/x10 fail in 10600 pass in 10603

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf    14 guest-localmigrate/x10 fail in 10600 like 10563

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-i386-i386-win           16 leak-check/check      fail in 10600 never pass

version targeted for testing:
 xen                  2863b2f43a3b
baseline version:
 xen                  e56500f95b6a

------------------------------------------------------------
People who touched revisions under test:
  Anthony PERARD <anthony.perard@citrix.com>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Haitao Shan <haitao.shan@intel.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Shan Haitao <maillists.shan@gmail.com>
  Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          fail    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-unstable
+ revision=2863b2f43a3b
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-unstable 2863b2f43a3b
+ branch=xen-unstable
+ revision=2863b2f43a3b
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ : xen@xenbits.xensource.com
+ : xen@xenbits.xensource.com:git/linux-pvops
+ : master
+ : tested/2.6.39.x
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r 2863b2f43a3b ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 6 changesets with 17 changes to 13 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 23 04:04:23 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 Dec 2011 04:04:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdwMD-0000qc-UO; Fri, 23 Dec 2011 04:03:45 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RdwMC-0000qX-BQ
	for xen-devel@lists.xensource.com; Fri, 23 Dec 2011 04:03:44 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1324613018!6636387!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODA5Ng==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8839 invoked from network); 23 Dec 2011 04:03:38 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Dec 2011 04:03:38 -0000
X-IronPort-AV: E=Sophos;i="4.71,397,1320624000"; 
   d="scan'208";a="9644921"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Dec 2011 04:03:37 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 23 Dec 2011 04:03:37 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RdwM4-0006xd-Oc;
	Fri, 23 Dec 2011 04:03:36 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RdwM4-0007Uh-NS;
	Fri, 23 Dec 2011 04:03:36 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10603-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 23 Dec 2011 04:03:36 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10603: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10603 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10603/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-pv          16 guest-start.2               fail pass in 10600
 test-amd64-amd64-xl-sedf     13 guest-localmigrate.2        fail pass in 10600
 test-i386-i386-win            7 windows-install             fail pass in 10600
 test-amd64-i386-xl-multivcpu 16 guest-start.2      fail in 10600 pass in 10603
 test-i386-i386-xl-win         7 windows-install    fail in 10600 pass in 10603
 test-amd64-i386-xl-win-vcpus1 12 guest-localmigrate/x10 fail in 10600 pass in 10603

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf    14 guest-localmigrate/x10 fail in 10600 like 10563

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-i386-i386-win           16 leak-check/check      fail in 10600 never pass

version targeted for testing:
 xen                  2863b2f43a3b
baseline version:
 xen                  e56500f95b6a

------------------------------------------------------------
People who touched revisions under test:
  Anthony PERARD <anthony.perard@citrix.com>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Haitao Shan <haitao.shan@intel.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Shan Haitao <maillists.shan@gmail.com>
  Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          fail    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-unstable
+ revision=2863b2f43a3b
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-unstable 2863b2f43a3b
+ branch=xen-unstable
+ revision=2863b2f43a3b
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ : xen@xenbits.xensource.com
+ : xen@xenbits.xensource.com:git/linux-pvops
+ : master
+ : tested/2.6.39.x
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r 2863b2f43a3b ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 6 changesets with 17 changes to 13 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 23 05:17:59 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 Dec 2011 05: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.xensource.com>)
	id 1RdxVR-0001aB-GK; Fri, 23 Dec 2011 05:17:21 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <250716708@qq.com>) id 1RdxVQ-0001a6-DO
	for xen-devel@lists.xensource.com; Fri, 23 Dec 2011 05:17:20 +0000
X-Env-Sender: 250716708@qq.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1324617433!6428034!1
X-Originating-IP: [64.71.138.44]
X-SpamReason: No, hits=3.7 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA2NC43MS4xMzguNDQgPT4gMTk4ODM5\n,sa_preprocessor: 
	QmFkIElQOiA2NC43MS4xMzguNDQgPT4gMTk4ODM5\n,FROM_ALL_NUMS,
	FROM_STARTS_WITH_NUMS,HTML_50_60,HTML_MESSAGE,HTML_SHORT_LENGTH,
	MIME_BASE64_TEXT,MIME_BOUND_NEXTPART,received_headers: No Received 
	headers
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28743 invoked from network); 23 Dec 2011 05:17:13 -0000
Received: from smtpbg55.qq.com (HELO smtpbg55.qq.com) (64.71.138.44)
	by server-14.tower-174.messagelabs.com with SMTP;
	23 Dec 2011 05:17:13 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qq.com; s=s0907;
	t=1324617424; bh=y35jgMeBO5cBKjQAs3+vxllQlQrF3RgPbKAAC08OUZc=;
	h=X-QQ-SSF:X-HAS-ATTACH:X-QQ-BUSINESS-ORIGIN:X-Originating-IP:
	X-QQ-STYLE:X-QQ-mid:From:To:Subject:Mime-Version:Content-Type:
	Content-Transfer-Encoding:Date:X-Priority:Message-ID:X-QQ-MIME:
	X-Mailer:X-QQ-Mailer;
	b=GgewCFNn4mKtLO1heMpQSdbHZ7nNrBE1FCgGZFGZQraHI/k20lJYfyEnTnrPeahGd
	GY0mmbyGhZtu40cIsHz0s+bJXNQmTNZnfGS3IpxZI90YjcJhpiFcdk5xBflkO2v
X-QQ-SSF: 00000000000000F0000000000000000
X-HAS-ATTACH: no
X-QQ-BUSINESS-ORIGIN: 2
X-Originating-IP: 118.192.67.234
X-QQ-STYLE: 
X-QQ-mid: webmail155t1324617420t8426650
From: "=?gbk?B?oei9S+y2YXdhcmU=?=" <250716708@qq.com>
To: "=?gbk?B?cWVtdS1kZXZlbA==?=" <qemu-devel@nongnu.org>,
	"=?gbk?B?eGVuLWRldmVs?=" <xen-devel@lists.xensource.com>
Mime-Version: 1.0
Date: Fri, 23 Dec 2011 13:17:00 +0800
X-Priority: 3
Message-ID: <tencent_37EF499B2FBF40764715DEA6@qq.com>
X-QQ-MIME: TCMime 1.0 by Tencent
X-Mailer: QQMail 2.x
X-QQ-Mailer: QQMail 2.x
Subject: [Xen-devel] [help] QEMUFile's format
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============8549336261239327328=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a multi-part message in MIME format.

--===============8549336261239327328==
Content-Type: multipart/alternative;
	boundary="----=_NextPart_4EF40ECC_08600618_71DF00FC"
Content-Transfer-Encoding: 8Bit

This is a multi-part message in MIME format.

------=_NextPart_4EF40ECC_08600618_71DF00FC
Content-Type: text/plain;
	charset="gbk"
Content-Transfer-Encoding: base64

SGksDQogICAgIElzIGFueW9uZSBjbGVhciBhYm91dCB0aGUgZm9ybWF0IG9mIHFlbXUgZmls
ZSBmb3Igc2F2ZXZtIG9yIGxvYWR2bT8NCiAgICAgDQogYnJ1Y2U=

------=_NextPart_4EF40ECC_08600618_71DF00FC
Content-Type: text/html;
	charset="gbk"
Content-Transfer-Encoding: base64

PERJVj5IaSw8L0RJVj4NCjxESVY+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7SXMgYW55b25l
IGNsZWFyIGFib3V0IHRoZSBmb3JtYXQgb2YgcWVtdSBmaWxlIGZvciBzYXZldm0gb3IgbG9h
ZHZtPzwvRElWPg0KPERJVj4mbmJzcDsmbmJzcDsmbmJzcDsgPC9ESVY+DQo8RElWPmJydWNl
PC9ESVY+

------=_NextPart_4EF40ECC_08600618_71DF00FC--



--===============8549336261239327328==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============8549336261239327328==--



From xen-devel-bounces@lists.xensource.com Fri Dec 23 05:17:59 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 Dec 2011 05: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.xensource.com>)
	id 1RdxVR-0001aB-GK; Fri, 23 Dec 2011 05:17:21 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <250716708@qq.com>) id 1RdxVQ-0001a6-DO
	for xen-devel@lists.xensource.com; Fri, 23 Dec 2011 05:17:20 +0000
X-Env-Sender: 250716708@qq.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1324617433!6428034!1
X-Originating-IP: [64.71.138.44]
X-SpamReason: No, hits=3.7 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA2NC43MS4xMzguNDQgPT4gMTk4ODM5\n,sa_preprocessor: 
	QmFkIElQOiA2NC43MS4xMzguNDQgPT4gMTk4ODM5\n,FROM_ALL_NUMS,
	FROM_STARTS_WITH_NUMS,HTML_50_60,HTML_MESSAGE,HTML_SHORT_LENGTH,
	MIME_BASE64_TEXT,MIME_BOUND_NEXTPART,received_headers: No Received 
	headers
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28743 invoked from network); 23 Dec 2011 05:17:13 -0000
Received: from smtpbg55.qq.com (HELO smtpbg55.qq.com) (64.71.138.44)
	by server-14.tower-174.messagelabs.com with SMTP;
	23 Dec 2011 05:17:13 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qq.com; s=s0907;
	t=1324617424; bh=y35jgMeBO5cBKjQAs3+vxllQlQrF3RgPbKAAC08OUZc=;
	h=X-QQ-SSF:X-HAS-ATTACH:X-QQ-BUSINESS-ORIGIN:X-Originating-IP:
	X-QQ-STYLE:X-QQ-mid:From:To:Subject:Mime-Version:Content-Type:
	Content-Transfer-Encoding:Date:X-Priority:Message-ID:X-QQ-MIME:
	X-Mailer:X-QQ-Mailer;
	b=GgewCFNn4mKtLO1heMpQSdbHZ7nNrBE1FCgGZFGZQraHI/k20lJYfyEnTnrPeahGd
	GY0mmbyGhZtu40cIsHz0s+bJXNQmTNZnfGS3IpxZI90YjcJhpiFcdk5xBflkO2v
X-QQ-SSF: 00000000000000F0000000000000000
X-HAS-ATTACH: no
X-QQ-BUSINESS-ORIGIN: 2
X-Originating-IP: 118.192.67.234
X-QQ-STYLE: 
X-QQ-mid: webmail155t1324617420t8426650
From: "=?gbk?B?oei9S+y2YXdhcmU=?=" <250716708@qq.com>
To: "=?gbk?B?cWVtdS1kZXZlbA==?=" <qemu-devel@nongnu.org>,
	"=?gbk?B?eGVuLWRldmVs?=" <xen-devel@lists.xensource.com>
Mime-Version: 1.0
Date: Fri, 23 Dec 2011 13:17:00 +0800
X-Priority: 3
Message-ID: <tencent_37EF499B2FBF40764715DEA6@qq.com>
X-QQ-MIME: TCMime 1.0 by Tencent
X-Mailer: QQMail 2.x
X-QQ-Mailer: QQMail 2.x
Subject: [Xen-devel] [help] QEMUFile's format
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============8549336261239327328=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a multi-part message in MIME format.

--===============8549336261239327328==
Content-Type: multipart/alternative;
	boundary="----=_NextPart_4EF40ECC_08600618_71DF00FC"
Content-Transfer-Encoding: 8Bit

This is a multi-part message in MIME format.

------=_NextPart_4EF40ECC_08600618_71DF00FC
Content-Type: text/plain;
	charset="gbk"
Content-Transfer-Encoding: base64

SGksDQogICAgIElzIGFueW9uZSBjbGVhciBhYm91dCB0aGUgZm9ybWF0IG9mIHFlbXUgZmls
ZSBmb3Igc2F2ZXZtIG9yIGxvYWR2bT8NCiAgICAgDQogYnJ1Y2U=

------=_NextPart_4EF40ECC_08600618_71DF00FC
Content-Type: text/html;
	charset="gbk"
Content-Transfer-Encoding: base64

PERJVj5IaSw8L0RJVj4NCjxESVY+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7SXMgYW55b25l
IGNsZWFyIGFib3V0IHRoZSBmb3JtYXQgb2YgcWVtdSBmaWxlIGZvciBzYXZldm0gb3IgbG9h
ZHZtPzwvRElWPg0KPERJVj4mbmJzcDsmbmJzcDsmbmJzcDsgPC9ESVY+DQo8RElWPmJydWNl
PC9ESVY+

------=_NextPart_4EF40ECC_08600618_71DF00FC--



--===============8549336261239327328==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============8549336261239327328==--



From xen-devel-bounces@lists.xensource.com Fri Dec 23 06:56:07 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 Dec 2011 06: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.xensource.com>)
	id 1Rdz29-00021v-6U; Fri, 23 Dec 2011 06:55:13 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <250716708@qq.com>) id 1Rdz26-00021n-Jk
	for xen-devel@lists.xensource.com; Fri, 23 Dec 2011 06:55:11 +0000
X-Env-Sender: 250716708@qq.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1324623303!7961805!1
X-Originating-IP: [64.71.138.44]
X-SpamReason: No, hits=2.6 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA2NC43MS4xMzguNDQgPT4gMTk4ODM5\n,sa_preprocessor: 
	QmFkIElQOiA2NC43MS4xMzguNDQgPT4gMTk4ODM5\n,FROM_ALL_NUMS,
	FROM_STARTS_WITH_NUMS,HTML_40_50,HTML_MESSAGE,MIME_BASE64_TEXT,
	MIME_BOUND_NEXTPART,received_headers: No Received headers
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29739 invoked from network); 23 Dec 2011 06:55:03 -0000
Received: from smtpbg55.qq.com (HELO smtpbg55.qq.com) (64.71.138.44)
	by server-14.tower-216.messagelabs.com with SMTP;
	23 Dec 2011 06:55:03 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qq.com; s=s0907;
	t=1324623275; bh=gRPGG4iID0v54K5IlfDZZLCzqT+QvT0mze6+x1dv8ww=;
	h=X-QQ-SSF:X-HAS-ATTACH:X-QQ-BUSINESS-ORIGIN:X-Originating-IP:
	X-QQ-STYLE:X-QQ-mid:From:To:Cc:Subject:Mime-Version:Content-Type:
	Content-Transfer-Encoding:Date:X-Priority:Message-ID:X-QQ-MIME:
	X-Mailer:X-QQ-Mailer:X-QQ-ReplyHash;
	b=RfQWaWMADUTUm1KEvzOAWGaIpENQ5e4qGDwTqysjkz11AgoA01nyww1lAeZotJVeI
	ypimjcudsmahwdsDWEp/A61tsYXa4pNqIJhzZ/Ha9Ihs86jvAo1fCR7EeWdABup
X-QQ-SSF: 00000000000000F0000000000000000
X-HAS-ATTACH: no
X-QQ-BUSINESS-ORIGIN: 2
X-Originating-IP: 69.163.32.120
X-QQ-STYLE: 
X-QQ-mid: webmail501t1324623270t2658666
From: "=?gbk?B?oei9S+y2YXdhcmU=?=" <250716708@qq.com>
To: "=?gbk?B?6pDtZsjO?=" <chenwj@iis.sinica.edu.tw>
Mime-Version: 1.0
Date: Fri, 23 Dec 2011 14:54:30 +0800
X-Priority: 3
Message-ID: <tencent_03F1C900225982444270B589@qq.com>
X-QQ-MIME: TCMime 1.0 by Tencent
X-Mailer: QQMail 2.x
X-QQ-Mailer: QQMail 2.x
X-QQ-ReplyHash: 1005300655
Cc: =?gbk?B?eGVuLWRldmVs?= <xen-devel@lists.xensource.com>,
	=?gbk?B?cWVtdS1kZXZlbA==?= <qemu-devel@nongnu.org>
Subject: [Xen-devel] =?gbk?b?u9i4tKO6IFtRZW11LWRldmVsXSBbaGVscF0gUUVNVUZp?=
 =?gbk?q?le=27s_format?=
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1708978001405190154=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a multi-part message in MIME format.

--===============1708978001405190154==
Content-Type: multipart/alternative;
	boundary="----=_NextPart_4EF425A6_DD0AD848_74DDB7E9"
Content-Transfer-Encoding: 8Bit

This is a multi-part message in MIME format.

------=_NextPart_4EF425A6_DD0AD848_74DDB7E9
Content-Type: text/plain;
	charset="gbk"
Content-Transfer-Encoding: base64

1Np4ZW7E2rrL1tCjrHFlbXXKx8v7tcTSu7j219PPtc2zo6zM4bmp0OnE4snosbi3/s7xo6zU
2nhlbs/Cw+axo7TmtcTQ6cTiu/q/7NXVysfSu7j2tPPOxLz+LM7Sz+vBy73itcTKx9XiuPbO
xLz+tcS48cq9oaPE48u1tcRxY293MtOmuMPKx9a4tMXFzL61z/G48cq9o6wNCiAgW0B4ZW50
ZXN0IDp+L3hlbi94ZW4tMy40LjItcWVtdS90b29scy9pb2VtdS1xZW11LXhlbl0kIGZpbGUg
fi8xMDEuc2F2ZSAgDQogfi8xMDEuc2F2ZTogWGVuIHNhdmVkIGRvbWFpbiAobmFtZSB4cC0x
MDEpIChvbl9wb3dlcm9mZiBkZXN0cm95KSAoLi4uKSAgDQogIA0KICAtLS0tLS0tLS0tLS0t
LS0tLS0g1K3KvNPKvP4gLS0tLS0tLS0tLS0tLS0tLS0tDQogILeivP7IyzogIuqQ7WbIziI8
Y2hlbndqQGlpcy5zaW5pY2EuZWR1LnR3PjsNCiC3osvNyrG85DogMjAxMcTqMTLUwjIzyNUo
0MfG2s7lKSDPws7nMjo0MQ0KIMrVvP7IyzogIqHovUvstmF3YXJlIjwyNTA3MTY3MDhAcXEu
Y29tPjsgDQogDQog1vfM4jogUmU6IFtRZW11LWRldmVsXSBbaGVscF0gUUVNVUZpbGUncyBm
b3JtYXQNCg0KICANCk9uIEZyaSwgRGVjIDIzLCAyMDExIGF0IDAxOjE3OjAwUE0gKzA4MDAs
IKHovUvstmF3YXJlIHdyb3RlOg0KPiBIaSwNCj4gICAgICBJcyBhbnlvbmUgY2xlYXIgYWJv
dXQgdGhlIGZvcm1hdCBvZiBxZW11IGZpbGUgZm9yIHNhdmV2bSBvciBsb2Fkdm0/DQoNCiAg
UUVNVSC1xIaW7n2jrM7Sz+u/ycTcsrvfbbrPsGy1vSB4ZW4gbWFpbGluZyBsaXN0oaMNCg0K
LS0gDQpXZWktUmVuIENoZW4gKOqQ7WbIzikNCkNvbXB1dGVyIFN5c3RlbXMgTGFiLCBJbnN0
aXR1dGUgb2YgSW5mb3JtYXRpb24gU2NpZW5jZSwNCkFjYWRlbWlhIFNpbmljYSwgVGFpd2Fu
IChSLk8uQy4pDQpUZWw6ODg2LTItMjc4OC0zNzk5ICMxNjY3DQpIb21lcGFnZTogaHR0cDov
L3Blb3BsZS5jcy5uY3R1LmVkdS50dy9+Y2hlbndq

------=_NextPart_4EF425A6_DD0AD848_74DDB7E9
Content-Type: text/html;
	charset="gbk"
Content-Transfer-Encoding: base64

PERJVj7U2nhlbsTausvW0KOscWVtdcrHy/u1xNK7uPbX08+1zbOjrMzhuanQ6cTiyeixuLf+
zvGjrNTaeGVuz8LD5rGjtOa1xNDpxOK7+r/s1dXKx9K7uPa0887EvP4sztLP68HLveK1xMrH
1eK49s7EvP61xLjxyr2ho8Tjy7W1xHFjb3cy06a4w8rH1ri0xcXMvrXP8bjxyr2jrDwvRElW
Pg0KPERJVj48aW5jbHVkZXRhaWw+DQo8RElWPltAeGVudGVzdCA6fi94ZW4veGVuLTMuNC4y
LXFlbXUvdG9vbHMvaW9lbXUtcWVtdS14ZW5dJCBmaWxlIH4vMTAxLnNhdmUmbmJzcDsmbmJz
cDs8L0RJVj4NCjxESVY+fi8xMDEuc2F2ZTogWGVuIHNhdmVkIGRvbWFpbiAobmFtZSB4cC0x
MDEpIChvbl9wb3dlcm9mZiBkZXN0cm95KSAoLi4uKSZuYnNwOyA8L0RJVj4NCjxESVY+Jm5i
c3A7PC9ESVY+DQo8RElWIHN0eWxlPSJDT0xPUjogIzAwMCI+DQo8RElWIHN0eWxlPSJQQURE
SU5HLUJPVFRPTTogMnB4OyBQQURESU5HLUxFRlQ6IDBweDsgUEFERElORy1SSUdIVDogMHB4
OyBGT05ULUZBTUlMWTogQXJpYWwgTmFycm93OyBGT05ULVNJWkU6IDEycHg7IFBBRERJTkct
VE9QOiAycHgiPi0tLS0tLS0tLS0tLS0tLS0tLSZuYnNwO9StyrzTyrz+Jm5ic3A7LS0tLS0t
LS0tLS0tLS0tLS0tPC9ESVY+DQo8RElWIHN0eWxlPSJQQURESU5HLUJPVFRPTTogOHB4OyBQ
QURESU5HLUxFRlQ6IDhweDsgUEFERElORy1SSUdIVDogOHB4OyBCQUNLR1JPVU5EOiAjZWZl
ZmVmOyBGT05ULVNJWkU6IDEycHg7IFBBRERJTkctVE9QOiA4cHgiPg0KPERJViBpZD1tZW51
X3NlbmRlcj48Qj63orz+yMs6PC9CPiZuYnNwOyLqkO1myM4iJmx0O2NoZW53akBpaXMuc2lu
aWNhLmVkdS50dyZndDs7PC9ESVY+DQo8RElWPjxCPreiy83KsbzkOjwvQj4mbmJzcDsyMDEx
xOoxMtTCMjPI1SjQx8bazuUpIM/CzucyOjQxPC9ESVY+DQo8RElWPjxCPsrVvP7Iyzo8L0I+
Jm5ic3A7IqHovUvstmF3YXJlIiZsdDsyNTA3MTY3MDhAcXEuY29tJmd0OzsgPFdCUj48L0RJ
Vj4NCjxESVY+PC9ESVY+DQo8RElWPjxCPtb3zOI6PC9CPiZuYnNwO1JlOiBbUWVtdS1kZXZl
bF0gW2hlbHBdIFFFTVVGaWxlJ3MgZm9ybWF0PC9ESVY+PC9ESVY+DQo8RElWPiZuYnNwOzwv
RElWPk9uIEZyaSwgRGVjIDIzLCAyMDExIGF0IDAxOjE3OjAwUE0gKzA4MDAsIKHovUvstmF3
YXJlIHdyb3RlOjxCUj4mZ3Q7IEhpLDxCUj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7IElzIGFueW9uZSBjbGVhciBhYm91dCB0aGUgZm9ybWF0IG9mIHFlbXUgZmlsZSBm
b3Igc2F2ZXZtIG9yIGxvYWR2bT88QlI+PEJSPiZuYnNwOyBRRU1VILXEhpbufaOsztLP67/J
xNyyu99tus+wbLW9IHhlbiBtYWlsaW5nIGxpc3ShozxCUj48QlI+LS0gPEJSPldlaS1SZW4g
Q2hlbiAo6pDtZsjOKTxCUj5Db21wdXRlciBTeXN0ZW1zIExhYiwgSW5zdGl0dXRlIG9mIElu
Zm9ybWF0aW9uIFNjaWVuY2UsPEJSPkFjYWRlbWlhIFNpbmljYSwgVGFpd2FuIChSLk8uQy4p
PEJSPlRlbDo4ODYtMi0yNzg4LTM3OTkgIzE2Njc8QlI+SG9tZXBhZ2U6IGh0dHA6Ly9wZW9w
bGUuY3MubmN0dS5lZHUudHcvfmNoZW53ajxCUj48L0RJVj48L2luY2x1ZGV0YWlsPjwvRElW
Pg==

------=_NextPart_4EF425A6_DD0AD848_74DDB7E9--



--===============1708978001405190154==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============1708978001405190154==--



From xen-devel-bounces@lists.xensource.com Fri Dec 23 06:56:07 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 Dec 2011 06: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.xensource.com>)
	id 1Rdz29-00021v-6U; Fri, 23 Dec 2011 06:55:13 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <250716708@qq.com>) id 1Rdz26-00021n-Jk
	for xen-devel@lists.xensource.com; Fri, 23 Dec 2011 06:55:11 +0000
X-Env-Sender: 250716708@qq.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1324623303!7961805!1
X-Originating-IP: [64.71.138.44]
X-SpamReason: No, hits=2.6 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA2NC43MS4xMzguNDQgPT4gMTk4ODM5\n,sa_preprocessor: 
	QmFkIElQOiA2NC43MS4xMzguNDQgPT4gMTk4ODM5\n,FROM_ALL_NUMS,
	FROM_STARTS_WITH_NUMS,HTML_40_50,HTML_MESSAGE,MIME_BASE64_TEXT,
	MIME_BOUND_NEXTPART,received_headers: No Received headers
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29739 invoked from network); 23 Dec 2011 06:55:03 -0000
Received: from smtpbg55.qq.com (HELO smtpbg55.qq.com) (64.71.138.44)
	by server-14.tower-216.messagelabs.com with SMTP;
	23 Dec 2011 06:55:03 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qq.com; s=s0907;
	t=1324623275; bh=gRPGG4iID0v54K5IlfDZZLCzqT+QvT0mze6+x1dv8ww=;
	h=X-QQ-SSF:X-HAS-ATTACH:X-QQ-BUSINESS-ORIGIN:X-Originating-IP:
	X-QQ-STYLE:X-QQ-mid:From:To:Cc:Subject:Mime-Version:Content-Type:
	Content-Transfer-Encoding:Date:X-Priority:Message-ID:X-QQ-MIME:
	X-Mailer:X-QQ-Mailer:X-QQ-ReplyHash;
	b=RfQWaWMADUTUm1KEvzOAWGaIpENQ5e4qGDwTqysjkz11AgoA01nyww1lAeZotJVeI
	ypimjcudsmahwdsDWEp/A61tsYXa4pNqIJhzZ/Ha9Ihs86jvAo1fCR7EeWdABup
X-QQ-SSF: 00000000000000F0000000000000000
X-HAS-ATTACH: no
X-QQ-BUSINESS-ORIGIN: 2
X-Originating-IP: 69.163.32.120
X-QQ-STYLE: 
X-QQ-mid: webmail501t1324623270t2658666
From: "=?gbk?B?oei9S+y2YXdhcmU=?=" <250716708@qq.com>
To: "=?gbk?B?6pDtZsjO?=" <chenwj@iis.sinica.edu.tw>
Mime-Version: 1.0
Date: Fri, 23 Dec 2011 14:54:30 +0800
X-Priority: 3
Message-ID: <tencent_03F1C900225982444270B589@qq.com>
X-QQ-MIME: TCMime 1.0 by Tencent
X-Mailer: QQMail 2.x
X-QQ-Mailer: QQMail 2.x
X-QQ-ReplyHash: 1005300655
Cc: =?gbk?B?eGVuLWRldmVs?= <xen-devel@lists.xensource.com>,
	=?gbk?B?cWVtdS1kZXZlbA==?= <qemu-devel@nongnu.org>
Subject: [Xen-devel] =?gbk?b?u9i4tKO6IFtRZW11LWRldmVsXSBbaGVscF0gUUVNVUZp?=
 =?gbk?q?le=27s_format?=
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1708978001405190154=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a multi-part message in MIME format.

--===============1708978001405190154==
Content-Type: multipart/alternative;
	boundary="----=_NextPart_4EF425A6_DD0AD848_74DDB7E9"
Content-Transfer-Encoding: 8Bit

This is a multi-part message in MIME format.

------=_NextPart_4EF425A6_DD0AD848_74DDB7E9
Content-Type: text/plain;
	charset="gbk"
Content-Transfer-Encoding: base64

1Np4ZW7E2rrL1tCjrHFlbXXKx8v7tcTSu7j219PPtc2zo6zM4bmp0OnE4snosbi3/s7xo6zU
2nhlbs/Cw+axo7TmtcTQ6cTiu/q/7NXVysfSu7j2tPPOxLz+LM7Sz+vBy73itcTKx9XiuPbO
xLz+tcS48cq9oaPE48u1tcRxY293MtOmuMPKx9a4tMXFzL61z/G48cq9o6wNCiAgW0B4ZW50
ZXN0IDp+L3hlbi94ZW4tMy40LjItcWVtdS90b29scy9pb2VtdS1xZW11LXhlbl0kIGZpbGUg
fi8xMDEuc2F2ZSAgDQogfi8xMDEuc2F2ZTogWGVuIHNhdmVkIGRvbWFpbiAobmFtZSB4cC0x
MDEpIChvbl9wb3dlcm9mZiBkZXN0cm95KSAoLi4uKSAgDQogIA0KICAtLS0tLS0tLS0tLS0t
LS0tLS0g1K3KvNPKvP4gLS0tLS0tLS0tLS0tLS0tLS0tDQogILeivP7IyzogIuqQ7WbIziI8
Y2hlbndqQGlpcy5zaW5pY2EuZWR1LnR3PjsNCiC3osvNyrG85DogMjAxMcTqMTLUwjIzyNUo
0MfG2s7lKSDPws7nMjo0MQ0KIMrVvP7IyzogIqHovUvstmF3YXJlIjwyNTA3MTY3MDhAcXEu
Y29tPjsgDQogDQog1vfM4jogUmU6IFtRZW11LWRldmVsXSBbaGVscF0gUUVNVUZpbGUncyBm
b3JtYXQNCg0KICANCk9uIEZyaSwgRGVjIDIzLCAyMDExIGF0IDAxOjE3OjAwUE0gKzA4MDAs
IKHovUvstmF3YXJlIHdyb3RlOg0KPiBIaSwNCj4gICAgICBJcyBhbnlvbmUgY2xlYXIgYWJv
dXQgdGhlIGZvcm1hdCBvZiBxZW11IGZpbGUgZm9yIHNhdmV2bSBvciBsb2Fkdm0/DQoNCiAg
UUVNVSC1xIaW7n2jrM7Sz+u/ycTcsrvfbbrPsGy1vSB4ZW4gbWFpbGluZyBsaXN0oaMNCg0K
LS0gDQpXZWktUmVuIENoZW4gKOqQ7WbIzikNCkNvbXB1dGVyIFN5c3RlbXMgTGFiLCBJbnN0
aXR1dGUgb2YgSW5mb3JtYXRpb24gU2NpZW5jZSwNCkFjYWRlbWlhIFNpbmljYSwgVGFpd2Fu
IChSLk8uQy4pDQpUZWw6ODg2LTItMjc4OC0zNzk5ICMxNjY3DQpIb21lcGFnZTogaHR0cDov
L3Blb3BsZS5jcy5uY3R1LmVkdS50dy9+Y2hlbndq

------=_NextPart_4EF425A6_DD0AD848_74DDB7E9
Content-Type: text/html;
	charset="gbk"
Content-Transfer-Encoding: base64

PERJVj7U2nhlbsTausvW0KOscWVtdcrHy/u1xNK7uPbX08+1zbOjrMzhuanQ6cTiyeixuLf+
zvGjrNTaeGVuz8LD5rGjtOa1xNDpxOK7+r/s1dXKx9K7uPa0887EvP4sztLP68HLveK1xMrH
1eK49s7EvP61xLjxyr2ho8Tjy7W1xHFjb3cy06a4w8rH1ri0xcXMvrXP8bjxyr2jrDwvRElW
Pg0KPERJVj48aW5jbHVkZXRhaWw+DQo8RElWPltAeGVudGVzdCA6fi94ZW4veGVuLTMuNC4y
LXFlbXUvdG9vbHMvaW9lbXUtcWVtdS14ZW5dJCBmaWxlIH4vMTAxLnNhdmUmbmJzcDsmbmJz
cDs8L0RJVj4NCjxESVY+fi8xMDEuc2F2ZTogWGVuIHNhdmVkIGRvbWFpbiAobmFtZSB4cC0x
MDEpIChvbl9wb3dlcm9mZiBkZXN0cm95KSAoLi4uKSZuYnNwOyA8L0RJVj4NCjxESVY+Jm5i
c3A7PC9ESVY+DQo8RElWIHN0eWxlPSJDT0xPUjogIzAwMCI+DQo8RElWIHN0eWxlPSJQQURE
SU5HLUJPVFRPTTogMnB4OyBQQURESU5HLUxFRlQ6IDBweDsgUEFERElORy1SSUdIVDogMHB4
OyBGT05ULUZBTUlMWTogQXJpYWwgTmFycm93OyBGT05ULVNJWkU6IDEycHg7IFBBRERJTkct
VE9QOiAycHgiPi0tLS0tLS0tLS0tLS0tLS0tLSZuYnNwO9StyrzTyrz+Jm5ic3A7LS0tLS0t
LS0tLS0tLS0tLS0tPC9ESVY+DQo8RElWIHN0eWxlPSJQQURESU5HLUJPVFRPTTogOHB4OyBQ
QURESU5HLUxFRlQ6IDhweDsgUEFERElORy1SSUdIVDogOHB4OyBCQUNLR1JPVU5EOiAjZWZl
ZmVmOyBGT05ULVNJWkU6IDEycHg7IFBBRERJTkctVE9QOiA4cHgiPg0KPERJViBpZD1tZW51
X3NlbmRlcj48Qj63orz+yMs6PC9CPiZuYnNwOyLqkO1myM4iJmx0O2NoZW53akBpaXMuc2lu
aWNhLmVkdS50dyZndDs7PC9ESVY+DQo8RElWPjxCPreiy83KsbzkOjwvQj4mbmJzcDsyMDEx
xOoxMtTCMjPI1SjQx8bazuUpIM/CzucyOjQxPC9ESVY+DQo8RElWPjxCPsrVvP7Iyzo8L0I+
Jm5ic3A7IqHovUvstmF3YXJlIiZsdDsyNTA3MTY3MDhAcXEuY29tJmd0OzsgPFdCUj48L0RJ
Vj4NCjxESVY+PC9ESVY+DQo8RElWPjxCPtb3zOI6PC9CPiZuYnNwO1JlOiBbUWVtdS1kZXZl
bF0gW2hlbHBdIFFFTVVGaWxlJ3MgZm9ybWF0PC9ESVY+PC9ESVY+DQo8RElWPiZuYnNwOzwv
RElWPk9uIEZyaSwgRGVjIDIzLCAyMDExIGF0IDAxOjE3OjAwUE0gKzA4MDAsIKHovUvstmF3
YXJlIHdyb3RlOjxCUj4mZ3Q7IEhpLDxCUj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7IElzIGFueW9uZSBjbGVhciBhYm91dCB0aGUgZm9ybWF0IG9mIHFlbXUgZmlsZSBm
b3Igc2F2ZXZtIG9yIGxvYWR2bT88QlI+PEJSPiZuYnNwOyBRRU1VILXEhpbufaOsztLP67/J
xNyyu99tus+wbLW9IHhlbiBtYWlsaW5nIGxpc3ShozxCUj48QlI+LS0gPEJSPldlaS1SZW4g
Q2hlbiAo6pDtZsjOKTxCUj5Db21wdXRlciBTeXN0ZW1zIExhYiwgSW5zdGl0dXRlIG9mIElu
Zm9ybWF0aW9uIFNjaWVuY2UsPEJSPkFjYWRlbWlhIFNpbmljYSwgVGFpd2FuIChSLk8uQy4p
PEJSPlRlbDo4ODYtMi0yNzg4LTM3OTkgIzE2Njc8QlI+SG9tZXBhZ2U6IGh0dHA6Ly9wZW9w
bGUuY3MubmN0dS5lZHUudHcvfmNoZW53ajxCUj48L0RJVj48L2luY2x1ZGV0YWlsPjwvRElW
Pg==

------=_NextPart_4EF425A6_DD0AD848_74DDB7E9--



--===============1708978001405190154==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============1708978001405190154==--



From xen-devel-bounces@lists.xensource.com Fri Dec 23 07:40:30 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 Dec 2011 07:40:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdzjL-0002PH-AJ; Fri, 23 Dec 2011 07:39:51 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RdzjI-0002P9-Sb
	for xen-devel@lists.xensource.com; Fri, 23 Dec 2011 07:39:49 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1324625982!1074873!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODA5Ng==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17739 invoked from network); 23 Dec 2011 07:39:42 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Dec 2011 07:39:42 -0000
X-IronPort-AV: E=Sophos;i="4.71,397,1320624000"; 
   d="scan'208";a="9646442"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Dec 2011 07:39:27 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 23 Dec 2011 07:39:27 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1Rdzix-0008Bj-A8;
	Fri, 23 Dec 2011 07:39:27 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Rdzix-0000G1-4b;
	Fri, 23 Dec 2011 07:39:27 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10606-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 23 Dec 2011 07:39:27 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10606: tolerable FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10606 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10606/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl           16 guest-start.2               fail pass in 10603
 test-amd64-i386-xl-win7-amd64  7 windows-install            fail pass in 10603
 test-amd64-amd64-xl-sedf     11 guest-localmigrate          fail pass in 10603
 test-amd64-amd64-pv          16 guest-start.2      fail in 10603 pass in 10606
 test-amd64-amd64-xl-sedf   13 guest-localmigrate.2 fail in 10603 pass in 10600
 test-i386-i386-win            7 windows-install    fail in 10603 pass in 10606
 test-amd64-i386-xl-multivcpu 16 guest-start.2      fail in 10600 pass in 10606
 test-amd64-i386-xl-win-vcpus1 12 guest-localmigrate/x10 fail in 10600 pass in 10606

Regressions which are regarded as allowable (not blocking):
 test-i386-i386-xl-win         7 windows-install              fail   like 10600
 test-amd64-amd64-xl-sedf 14 guest-localmigrate/x10 fail in 10600 blocked in 10606

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop           fail in 10603 never pass
 test-i386-i386-xl-win        13 guest-stop            fail in 10603 never pass

version targeted for testing:
 xen                  2863b2f43a3b
baseline version:
 xen                  2863b2f43a3b

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           fail    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 23 07:40:30 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 Dec 2011 07:40:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RdzjL-0002PH-AJ; Fri, 23 Dec 2011 07:39:51 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RdzjI-0002P9-Sb
	for xen-devel@lists.xensource.com; Fri, 23 Dec 2011 07:39:49 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1324625982!1074873!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODA5Ng==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17739 invoked from network); 23 Dec 2011 07:39:42 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Dec 2011 07:39:42 -0000
X-IronPort-AV: E=Sophos;i="4.71,397,1320624000"; 
   d="scan'208";a="9646442"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Dec 2011 07:39:27 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 23 Dec 2011 07:39:27 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1Rdzix-0008Bj-A8;
	Fri, 23 Dec 2011 07:39:27 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Rdzix-0000G1-4b;
	Fri, 23 Dec 2011 07:39:27 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10606-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 23 Dec 2011 07:39:27 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10606: tolerable FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10606 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10606/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl           16 guest-start.2               fail pass in 10603
 test-amd64-i386-xl-win7-amd64  7 windows-install            fail pass in 10603
 test-amd64-amd64-xl-sedf     11 guest-localmigrate          fail pass in 10603
 test-amd64-amd64-pv          16 guest-start.2      fail in 10603 pass in 10606
 test-amd64-amd64-xl-sedf   13 guest-localmigrate.2 fail in 10603 pass in 10600
 test-i386-i386-win            7 windows-install    fail in 10603 pass in 10606
 test-amd64-i386-xl-multivcpu 16 guest-start.2      fail in 10600 pass in 10606
 test-amd64-i386-xl-win-vcpus1 12 guest-localmigrate/x10 fail in 10600 pass in 10606

Regressions which are regarded as allowable (not blocking):
 test-i386-i386-xl-win         7 windows-install              fail   like 10600
 test-amd64-amd64-xl-sedf 14 guest-localmigrate/x10 fail in 10600 blocked in 10606

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop           fail in 10603 never pass
 test-i386-i386-xl-win        13 guest-stop            fail in 10603 never pass

version targeted for testing:
 xen                  2863b2f43a3b
baseline version:
 xen                  2863b2f43a3b

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           fail    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 23 08:09:54 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 Dec 2011 08:09:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Re0Bo-00036m-5G; Fri, 23 Dec 2011 08:09:16 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1Re0Bm-00036e-Nw
	for xen-devel@lists.xensource.com; Fri, 23 Dec 2011 08:09:14 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1324627747!8391677!1
X-Originating-IP: [143.182.124.37]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjE2MTcz\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27256 invoked from network); 23 Dec 2011 08:09:08 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37)
	by server-4.tower-182.messagelabs.com with SMTP;
	23 Dec 2011 08:09:08 -0000
Received: from azsmga002.ch.intel.com ([10.2.17.35])
	by azsmga102.ch.intel.com with ESMTP; 23 Dec 2011 00:09:07 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="50029018"
Received: from pgsmsx603.gar.corp.intel.com ([10.221.43.87])
	by AZSMGA002.ch.intel.com with ESMTP; 23 Dec 2011 00:09:05 -0800
Received: from pgsmsx101.gar.corp.intel.com (10.221.44.78) by
	pgsmsx603.gar.corp.intel.com (10.221.43.87) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Fri, 23 Dec 2011 16:09:01 +0800
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	PGSMSX101.gar.corp.intel.com (10.221.44.78) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Fri, 23 Dec 2011 16:09:00 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.38]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.223]) with mapi id
	14.01.0355.002; Fri, 23 Dec 2011 16:08:59 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
Thread-Topic: [Xen-devel] Linux 3.1.0 Xen RAS rebase
Thread-Index: AQHMwR/TW8DpiUUASEeT9gUPm1anxpXo9axg
Date: Fri, 23 Dec 2011 08:08:58 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC8292335943F@SHSMSX101.ccr.corp.intel.com>
References: <DE8DF0795D48FD4CA783C40EC829233587C7@SHSMSX101.ccr.corp.intel.com>
	<20111223030608.GB7218@andromeda.dapyr.net>
In-Reply-To: <20111223030608.GB7218@andromeda.dapyr.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: "Brown, Len" <len.brown@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>, "Jiang, 
	Yunhong" <yunhong.jiang@intel.com>,
	Kernel development list <linux-kernel@vger.kernel.org>, "Zhao, 
	Yakui" <yakui.zhao@intel.com>,
	"jeremy.fitzhardinge@citrix.com" <jeremy.fitzhardinge@citrix.com>
Subject: Re: [Xen-devel] Linux 3.1.0 Xen RAS rebase
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Konrad Rzeszutek Wilk wrote:
> On Thu, Dec 22, 2011 at 09:57:55AM +0000, Liu, Jinsong wrote:
>> Recently we did dom0 Xen RAS rebase work.
> 
> Hey Liu,
> 
> Thank you for posting this. Couple of questions:
>  1). How does one test these patches?

These patches include mce, cpu online/offline, cpu hotadd, memory hotadd.
Testing method of these features are
1. mce: a normal way is to inject error through EINJ user interface, and getting mcelog at dom0 side
2. cpu online/offline: by echoing sysfs/.../xen_pcpu user interface, and getting result at sysfs/.../xen_pcpu
3. cpu hotadd: Intel has some new server, by pressing a button can add cpu. We can verify cpu hotadd by sysfs/.../xen_pcpu interface
4. memory hotadd: also by pressing a button to add memory, and can verify memory hotadd by 'xl info'

>  2). Please CC LKML and also the ACPI maintainer - since a majority
>      of this also touch their tree. And the memory hotadd maintainer
>      as well.

OK, cc
LKML
ACPI maintainer: len.brown@intel.com
memory hotadd maintianer: I'm not sure who is maintainer, but I will cc yakui.zhao@intel.com and len.brown@intel.com

I'll re-send the patches later, cc above people.

>  3). Can any of this code (like the MCE) leverage the existing
>      generic code?

Basically no, for mce, xen implement mce logic at hypervisor,
at dom0 side, it only add mcelog interface to get log from hypervisor and transfer to kernel mcelog format.

>  4). Have you guys talked with Len Brown (the ACPI maintainer)
>      about some of this code and how to make it fit within his
>      goals?

Not yet, but will.

Thanks,
Jinsong

> 
> Thanks!
>> 
>> Basically it rebased from Jeremy's pvops (2.6.32), to Konrad's pvops
>> (3.1.0, branch "devel/acpi-cpufreq.v3") patch 1: for mcelog logic
>> patch 2: for dom0 vmce 
>> patch 3: for cpu sysfs and cpu online/offline
>> patch 4: for cpu hotadd
>> patch 5: for memory hotadd prepare work
>> patch 6: for memory hotadd
>> patch 7: for cpu hotadd prepare work
>> patch 8: complement cpu hotadd lacked at Konrad's tree
>> patch 9: update PM logic
>> patch 10: upate cpu online/offline logic
>> 
>> 
>> Thanks,
>> Jinsong
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 23 08:09:54 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 Dec 2011 08:09:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Re0Bo-00036m-5G; Fri, 23 Dec 2011 08:09:16 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1Re0Bm-00036e-Nw
	for xen-devel@lists.xensource.com; Fri, 23 Dec 2011 08:09:14 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1324627747!8391677!1
X-Originating-IP: [143.182.124.37]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjE2MTcz\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27256 invoked from network); 23 Dec 2011 08:09:08 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37)
	by server-4.tower-182.messagelabs.com with SMTP;
	23 Dec 2011 08:09:08 -0000
Received: from azsmga002.ch.intel.com ([10.2.17.35])
	by azsmga102.ch.intel.com with ESMTP; 23 Dec 2011 00:09:07 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="50029018"
Received: from pgsmsx603.gar.corp.intel.com ([10.221.43.87])
	by AZSMGA002.ch.intel.com with ESMTP; 23 Dec 2011 00:09:05 -0800
Received: from pgsmsx101.gar.corp.intel.com (10.221.44.78) by
	pgsmsx603.gar.corp.intel.com (10.221.43.87) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Fri, 23 Dec 2011 16:09:01 +0800
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	PGSMSX101.gar.corp.intel.com (10.221.44.78) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Fri, 23 Dec 2011 16:09:00 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.38]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.223]) with mapi id
	14.01.0355.002; Fri, 23 Dec 2011 16:08:59 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
Thread-Topic: [Xen-devel] Linux 3.1.0 Xen RAS rebase
Thread-Index: AQHMwR/TW8DpiUUASEeT9gUPm1anxpXo9axg
Date: Fri, 23 Dec 2011 08:08:58 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC8292335943F@SHSMSX101.ccr.corp.intel.com>
References: <DE8DF0795D48FD4CA783C40EC829233587C7@SHSMSX101.ccr.corp.intel.com>
	<20111223030608.GB7218@andromeda.dapyr.net>
In-Reply-To: <20111223030608.GB7218@andromeda.dapyr.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: "Brown, Len" <len.brown@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>, "Jiang, 
	Yunhong" <yunhong.jiang@intel.com>,
	Kernel development list <linux-kernel@vger.kernel.org>, "Zhao, 
	Yakui" <yakui.zhao@intel.com>,
	"jeremy.fitzhardinge@citrix.com" <jeremy.fitzhardinge@citrix.com>
Subject: Re: [Xen-devel] Linux 3.1.0 Xen RAS rebase
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Konrad Rzeszutek Wilk wrote:
> On Thu, Dec 22, 2011 at 09:57:55AM +0000, Liu, Jinsong wrote:
>> Recently we did dom0 Xen RAS rebase work.
> 
> Hey Liu,
> 
> Thank you for posting this. Couple of questions:
>  1). How does one test these patches?

These patches include mce, cpu online/offline, cpu hotadd, memory hotadd.
Testing method of these features are
1. mce: a normal way is to inject error through EINJ user interface, and getting mcelog at dom0 side
2. cpu online/offline: by echoing sysfs/.../xen_pcpu user interface, and getting result at sysfs/.../xen_pcpu
3. cpu hotadd: Intel has some new server, by pressing a button can add cpu. We can verify cpu hotadd by sysfs/.../xen_pcpu interface
4. memory hotadd: also by pressing a button to add memory, and can verify memory hotadd by 'xl info'

>  2). Please CC LKML and also the ACPI maintainer - since a majority
>      of this also touch their tree. And the memory hotadd maintainer
>      as well.

OK, cc
LKML
ACPI maintainer: len.brown@intel.com
memory hotadd maintianer: I'm not sure who is maintainer, but I will cc yakui.zhao@intel.com and len.brown@intel.com

I'll re-send the patches later, cc above people.

>  3). Can any of this code (like the MCE) leverage the existing
>      generic code?

Basically no, for mce, xen implement mce logic at hypervisor,
at dom0 side, it only add mcelog interface to get log from hypervisor and transfer to kernel mcelog format.

>  4). Have you guys talked with Len Brown (the ACPI maintainer)
>      about some of this code and how to make it fit within his
>      goals?

Not yet, but will.

Thanks,
Jinsong

> 
> Thanks!
>> 
>> Basically it rebased from Jeremy's pvops (2.6.32), to Konrad's pvops
>> (3.1.0, branch "devel/acpi-cpufreq.v3") patch 1: for mcelog logic
>> patch 2: for dom0 vmce 
>> patch 3: for cpu sysfs and cpu online/offline
>> patch 4: for cpu hotadd
>> patch 5: for memory hotadd prepare work
>> patch 6: for memory hotadd
>> patch 7: for cpu hotadd prepare work
>> patch 8: complement cpu hotadd lacked at Konrad's tree
>> patch 9: update PM logic
>> patch 10: upate cpu online/offline logic
>> 
>> 
>> Thanks,
>> Jinsong
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 23 08:10:48 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 Dec 2011 08:10:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Re0Cn-00039H-Jt; Fri, 23 Dec 2011 08:10:17 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Re0Cm-00038t-TZ
	for xen-devel@lists.xensource.com; Fri, 23 Dec 2011 08:10:17 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1324627810!8496115!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4899 invoked from network); 23 Dec 2011 08:10:10 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-3.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 23 Dec 2011 08:10:10 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 23 Dec 2011 08:10:09 +0000
Message-Id: <4EF445A60200007800069B41@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 23 Dec 2011 08:11:02 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Gang Wei" <gang.wei@intel.com>
References: <F26D193E20BBDC42A43B611D1BDEDE7135CEEEAE56@shsmsx502.ccr.corp.intel.com>
	<CB177C28.365E3%keir@xen.org>
	<F26D193E20BBDC42A43B611D1BDEDE7135CEEEAE63@shsmsx502.ccr.corp.intel.com>
	<F26D193E20BBDC42A43B611D1BDEDE7135CEEEAE65@shsmsx502.ccr.corp.intel.com>
	<20111221170539.GA72385@ocelot.phlegethon.org>
	<D0B11485C64D4B47B66902F8A4E901BE9146@SHSMSX101.ccr.corp.intel.com>
	<20111222100112.GA1900@ocelot.phlegethon.org>
	<D0B11485C64D4B47B66902F8A4E901BEA2B8@SHSMSX101.ccr.corp.intel.com>
	<D0B11485C64D4B47B66902F8A4E901BEA302@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <D0B11485C64D4B47B66902F8A4E901BEA302@SHSMSX101.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	"TimDeegan \(3P\)" <Tim.Deegan@citrix.com>,
	Joseph Cihula <joseph.cihula@intel.com>, Tim Deegan <tim@xen.org>,
	"tboot-devel@lists.sourceforge.net" <tboot-devel@lists.sourceforge.net>
Subject: Re: [Xen-devel] [patch] x86: Add a delay between INIT & SIPIs for
 tboot AP bring-up in X2APIC case
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 23.12.11 at 04:14, "Wei, Gang" <gang.wei@intel.com> wrote:
> Without this delay, Xen could not bring APs up while working with TXT/tboot, 
> because tboot need some time in APs to handle INIT before becoming ready for 
> receiving SIPIs.(this delay was removed as part of c/s 23724 by Tim Deegan)
> 
> Signed-off-by: Gang Wei <gang.wei@intel.com>
> Acked-by: Keir Fraser <keir@xen.org>
> Acked-by: Tim Deegan <tim.deegan@citrix.com>
> 
> diff -r d1aefee43af1 xen/arch/x86/smpboot.c
> --- a/xen/arch/x86/smpboot.c	Wed Dec 21 18:51:31 2011 +0800
> +++ b/xen/arch/x86/smpboot.c	Fri Dec 23 11:01:10 2011 +0800
> @@ -42,6 +42,7 @@
>  #include <asm/msr.h>
>  #include <asm/mtrr.h>
>  #include <asm/time.h>
> +#include <asm/tboot.h>
>  #include <mach_apic.h>
>  #include <mach_wakecpu.h>
>  #include <smpboot_hooks.h>
> @@ -463,6 +464,18 @@
>              send_status = apic_read(APIC_ICR) & APIC_ICR_BUSY;
>          } while ( send_status && (timeout++ < 1000) );
>      }
> +    else if ( tboot_in_measured_env() )
> +    {
> +        /*
> +         * With tboot AP is actually spinning in a mini-guest before 
> +         * receiving INIT. Upon receiving INIT ipi, AP need time to VMExit, 
> 
> +         * update VMCS to tracking SIPIs and VMResume.
> +         *
> +         * While AP is in root mode handling the INIT the CPU will drop
> +         * any SIPIs
> +         */
> +        udelay(10);

So you jumped from 100ms to 10us - how was that value established?
Or in other words, how certain is it that this (or any other) timeout is
sufficient for all current and future systems implementing tboot?

Jan

> +    }
>  
>      /*
>       * Should we send STARTUP IPIs ?




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 23 08:10:48 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 Dec 2011 08:10:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Re0Cn-00039H-Jt; Fri, 23 Dec 2011 08:10:17 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Re0Cm-00038t-TZ
	for xen-devel@lists.xensource.com; Fri, 23 Dec 2011 08:10:17 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1324627810!8496115!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4899 invoked from network); 23 Dec 2011 08:10:10 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-3.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 23 Dec 2011 08:10:10 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 23 Dec 2011 08:10:09 +0000
Message-Id: <4EF445A60200007800069B41@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 23 Dec 2011 08:11:02 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Gang Wei" <gang.wei@intel.com>
References: <F26D193E20BBDC42A43B611D1BDEDE7135CEEEAE56@shsmsx502.ccr.corp.intel.com>
	<CB177C28.365E3%keir@xen.org>
	<F26D193E20BBDC42A43B611D1BDEDE7135CEEEAE63@shsmsx502.ccr.corp.intel.com>
	<F26D193E20BBDC42A43B611D1BDEDE7135CEEEAE65@shsmsx502.ccr.corp.intel.com>
	<20111221170539.GA72385@ocelot.phlegethon.org>
	<D0B11485C64D4B47B66902F8A4E901BE9146@SHSMSX101.ccr.corp.intel.com>
	<20111222100112.GA1900@ocelot.phlegethon.org>
	<D0B11485C64D4B47B66902F8A4E901BEA2B8@SHSMSX101.ccr.corp.intel.com>
	<D0B11485C64D4B47B66902F8A4E901BEA302@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <D0B11485C64D4B47B66902F8A4E901BEA302@SHSMSX101.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	"TimDeegan \(3P\)" <Tim.Deegan@citrix.com>,
	Joseph Cihula <joseph.cihula@intel.com>, Tim Deegan <tim@xen.org>,
	"tboot-devel@lists.sourceforge.net" <tboot-devel@lists.sourceforge.net>
Subject: Re: [Xen-devel] [patch] x86: Add a delay between INIT & SIPIs for
 tboot AP bring-up in X2APIC case
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 23.12.11 at 04:14, "Wei, Gang" <gang.wei@intel.com> wrote:
> Without this delay, Xen could not bring APs up while working with TXT/tboot, 
> because tboot need some time in APs to handle INIT before becoming ready for 
> receiving SIPIs.(this delay was removed as part of c/s 23724 by Tim Deegan)
> 
> Signed-off-by: Gang Wei <gang.wei@intel.com>
> Acked-by: Keir Fraser <keir@xen.org>
> Acked-by: Tim Deegan <tim.deegan@citrix.com>
> 
> diff -r d1aefee43af1 xen/arch/x86/smpboot.c
> --- a/xen/arch/x86/smpboot.c	Wed Dec 21 18:51:31 2011 +0800
> +++ b/xen/arch/x86/smpboot.c	Fri Dec 23 11:01:10 2011 +0800
> @@ -42,6 +42,7 @@
>  #include <asm/msr.h>
>  #include <asm/mtrr.h>
>  #include <asm/time.h>
> +#include <asm/tboot.h>
>  #include <mach_apic.h>
>  #include <mach_wakecpu.h>
>  #include <smpboot_hooks.h>
> @@ -463,6 +464,18 @@
>              send_status = apic_read(APIC_ICR) & APIC_ICR_BUSY;
>          } while ( send_status && (timeout++ < 1000) );
>      }
> +    else if ( tboot_in_measured_env() )
> +    {
> +        /*
> +         * With tboot AP is actually spinning in a mini-guest before 
> +         * receiving INIT. Upon receiving INIT ipi, AP need time to VMExit, 
> 
> +         * update VMCS to tracking SIPIs and VMResume.
> +         *
> +         * While AP is in root mode handling the INIT the CPU will drop
> +         * any SIPIs
> +         */
> +        udelay(10);

So you jumped from 100ms to 10us - how was that value established?
Or in other words, how certain is it that this (or any other) timeout is
sufficient for all current and future systems implementing tboot?

Jan

> +    }
>  
>      /*
>       * Should we send STARTUP IPIs ?




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 23 08:23:02 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 Dec 2011 08:23:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Re0Oa-0003Qa-Rf; Fri, 23 Dec 2011 08:22:28 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1Re0OZ-0003QV-8q
	for xen-devel@lists.xensource.com; Fri, 23 Dec 2011 08:22:27 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1324628539!6655714!1
X-Originating-IP: [209.85.210.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21797 invoked from network); 23 Dec 2011 08:22:21 -0000
Received: from mail-pz0-f43.google.com (HELO mail-pz0-f43.google.com)
	(209.85.210.43)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Dec 2011 08:22:21 -0000
Received: by daec6 with SMTP id c6so36768648dae.30
	for <xen-devel@lists.xensource.com>;
	Fri, 23 Dec 2011 00:22:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=cCun2aI9nExLojwzY1g4qkHbH0E9Qgsc3jG+jRYGolc=;
	b=GDnd3wdXzlVqRudWB2uePVi7bz1N+s6aHxubDd7uP3SDOch2JWr7sbM6rWERQ4iz5D
	wmDuM1of88qXzKuJMa0snJJLOH84MvpA0eHDyuo0wFbM6fOOmjOvFB/6YjXxywGXLuXi
	5W1k9wsaOzYQ+wr7HNVkcXujhxnda0T2RTxTA=
MIME-Version: 1.0
Received: by 10.68.75.233 with SMTP id f9mr30259310pbw.10.1324628538711; Fri,
	23 Dec 2011 00:22:18 -0800 (PST)
Received: by 10.142.47.17 with HTTP; Fri, 23 Dec 2011 00:22:18 -0800 (PST)
In-Reply-To: <1324574818.13113.0.camel@dagon.hellion.org.uk>
References: <CB1901CD.36815%keir@xen.org>
	<1324569166.7877.93.camel@zakaz.uk.xensource.com>
	<CAPLaKK7icOx97OcL=QTd=ciudso3TNFJWdsQagZHboSruQ2rYA@mail.gmail.com>
	<1324574818.13113.0.camel@dagon.hellion.org.uk>
Date: Fri, 23 Dec 2011 09:22:18 +0100
X-Google-Sender-Auth: _-Z_2zQGMMExUMXOO8EWQjJEr8E
Message-ID: <CAPLaKK5uXfXH7swFia21zkbNjuM+8Dfnk3OehFCNwvgfKzwn2A@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH v2] libxl: add support for yajl 2.x
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

2011/12/22 Ian Campbell <Ian.Campbell@citrix.com>:
> I'm not going to have time in the near future.

I will try to take a look at the autogoo stuff and set something up.

> Would it be sufficient to have the stuff in tools/check create a
> config.h as well as doing the checks? Might need a bit of Makefile magic
> to be sure that check is always run?

Since we have to change things, I'm not sure if it is best to move to
something more standard, like autotools.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 23 08:23:02 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 Dec 2011 08:23:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Re0Oa-0003Qa-Rf; Fri, 23 Dec 2011 08:22:28 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1Re0OZ-0003QV-8q
	for xen-devel@lists.xensource.com; Fri, 23 Dec 2011 08:22:27 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1324628539!6655714!1
X-Originating-IP: [209.85.210.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21797 invoked from network); 23 Dec 2011 08:22:21 -0000
Received: from mail-pz0-f43.google.com (HELO mail-pz0-f43.google.com)
	(209.85.210.43)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Dec 2011 08:22:21 -0000
Received: by daec6 with SMTP id c6so36768648dae.30
	for <xen-devel@lists.xensource.com>;
	Fri, 23 Dec 2011 00:22:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=cCun2aI9nExLojwzY1g4qkHbH0E9Qgsc3jG+jRYGolc=;
	b=GDnd3wdXzlVqRudWB2uePVi7bz1N+s6aHxubDd7uP3SDOch2JWr7sbM6rWERQ4iz5D
	wmDuM1of88qXzKuJMa0snJJLOH84MvpA0eHDyuo0wFbM6fOOmjOvFB/6YjXxywGXLuXi
	5W1k9wsaOzYQ+wr7HNVkcXujhxnda0T2RTxTA=
MIME-Version: 1.0
Received: by 10.68.75.233 with SMTP id f9mr30259310pbw.10.1324628538711; Fri,
	23 Dec 2011 00:22:18 -0800 (PST)
Received: by 10.142.47.17 with HTTP; Fri, 23 Dec 2011 00:22:18 -0800 (PST)
In-Reply-To: <1324574818.13113.0.camel@dagon.hellion.org.uk>
References: <CB1901CD.36815%keir@xen.org>
	<1324569166.7877.93.camel@zakaz.uk.xensource.com>
	<CAPLaKK7icOx97OcL=QTd=ciudso3TNFJWdsQagZHboSruQ2rYA@mail.gmail.com>
	<1324574818.13113.0.camel@dagon.hellion.org.uk>
Date: Fri, 23 Dec 2011 09:22:18 +0100
X-Google-Sender-Auth: _-Z_2zQGMMExUMXOO8EWQjJEr8E
Message-ID: <CAPLaKK5uXfXH7swFia21zkbNjuM+8Dfnk3OehFCNwvgfKzwn2A@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH v2] libxl: add support for yajl 2.x
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

2011/12/22 Ian Campbell <Ian.Campbell@citrix.com>:
> I'm not going to have time in the near future.

I will try to take a look at the autogoo stuff and set something up.

> Would it be sufficient to have the stuff in tools/check create a
> config.h as well as doing the checks? Might need a bit of Makefile magic
> to be sure that check is always run?

Since we have to change things, I'm not sure if it is best to move to
something more standard, like autotools.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 23 08:29:33 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 Dec 2011 08:29:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Re0Uz-0003c1-SK; Fri, 23 Dec 2011 08:29:05 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Re0Uy-0003bq-4S
	for xen-devel@lists.xensource.com; Fri, 23 Dec 2011 08:29:04 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1324628937!8524105!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1039 invoked from network); 23 Dec 2011 08:28:58 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-15.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 23 Dec 2011 08:28:58 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 23 Dec 2011 08:28:57 +0000
Message-Id: <4EF44A100200007800069B5A@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 23 Dec 2011 08:29:52 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "=?UTF-8?Q?Roger=20Pau=20Monn=C3=A9?=" <roger.pau@entel.upc.edu>
References: <CAPLaKK506e57uCvSdkjCqkUs6AS6ty4Efa+Ekhrczu=OA+TCHw@mail.gmail.com>
In-Reply-To: <CAPLaKK506e57uCvSdkjCqkUs6AS6ty4Efa+Ekhrczu=OA+TCHw@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Stubdom build problem in 4.1.2 but not in
 xen-unstable
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Pj4+IE9uIDIyLjEyLjExIGF0IDE4OjAzLCBSb2dlciBQYXUgTW9ubsOpPHJvZ2VyLnBhdUBlbnRl
bC51cGMuZWR1PiB3cm90ZToKPiBIZWxsbywKPiAKPiBJJ3ZlIGZvdW5kIHRoZSBmb2xsb3dpbmcg
cHJvYmxlbSB3aGlsZSBidWlsZGluZyBYZW4gNC4xLjIgc3R1YmRvbXM6Cj4gCj4gZ2NjIC1EQ09O
RklHX1FFTVUgLW1uby1yZWQtem9uZSAtTzEgLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIKPiAtZm5v
LW9wdGltaXplLXNpYmxpbmctY2FsbHMgIC1tNjQgLW1uby1yZWQtem9uZSAtZm5vLXJlb3JkZXIt
YmxvY2tzCj4gLWZuby1hc3luY2hyb25vdXMtdW53aW5kLXRhYmxlcyAtbTY0IC1nIC1mbm8tc3Ry
aWN0LWFsaWFzaW5nCj4gLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1Xbm8t
dW51c2VkLXZhbHVlCj4gLVdkZWNsYXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQgLVduby11bnVzZWQt
YnV0LXNldC12YXJpYWJsZSAgLW5vcGllCj4gLWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNl
cHRpb25zIC1mbm8tYnVpbHRpbiAtV2FsbCAtV2Vycm9yCj4gLVdyZWR1bmRhbnQtZGVjbHMgLVdu
by1mb3JtYXQgLVduby1yZWR1bmRhbnQtZGVjbHMKPiAtZm5vLXN0YWNrLXByb3RlY3RvciAtZmdu
dTg5LWlubGluZSAtV3N0cmljdC1wcm90b3R5cGVzCj4gLVduZXN0ZWQtZXh0ZXJucyAtV3BvaW50
ZXItYXJpdGggLVdpbmxpbmUgLWcgLURHTlRfREVCVUcKPiAtREdOVE1BUF9ERUJVRyAtRF9fSU5T
SURFX01JTklPU19fIC1tNjQgLW1uby1yZWQtem9uZQo+IC1mbm8tcmVvcmRlci1ibG9ja3MgLWZu
by1hc3luY2hyb25vdXMtdW53aW5kLXRhYmxlcyAtT3MKPiAtZm9taXQtZnJhbWUtcG9pbnRlciAt
aXN5c3RlbQo+IC9ob21lL3JveWdlci9hcG9ydHMvdGVzdGluZy94ZW4vc3JjL3hlbi00LjEuMi9z
dHViZG9tLy4uL2V4dHJhcy9taW5pLW9zL2luY2x1ZAo+IGUKPiAtRF9fTUlOSU9TX18gLURIQVZF
X0xJQkMgLWlzeXN0ZW0KPiAvaG9tZS9yb3lnZXIvYXBvcnRzL3Rlc3RpbmcveGVuL3NyYy94ZW4t
NC4xLjIvc3R1YmRvbS8uLi9leHRyYXMvbWluaS1vcy9pbmNsdWQKPiBlL3Bvc2l4Cj4gLWlzeXN0
ZW0gCj4gL2hvbWUvcm95Z2VyL2Fwb3J0cy90ZXN0aW5nL3hlbi9zcmMveGVuLTQuMS4yL3N0dWJk
b20vLi4vdG9vbHMveGVuc3RvcmUKPiAgLWlzeXN0ZW0gCj4gL2hvbWUvcm95Z2VyL2Fwb3J0cy90
ZXN0aW5nL3hlbi9zcmMveGVuLTQuMS4yL3N0dWJkb20vLi4vZXh0cmFzL21pbmktb3MvaW5jCj4g
bHVkZS94ODYKPiAtaXN5c3RlbSAKPiAvaG9tZS9yb3lnZXIvYXBvcnRzL3Rlc3RpbmcveGVuL3Ny
Yy94ZW4tNC4xLjIvc3R1YmRvbS8uLi9leHRyYXMvbWluaS1vcy9pbmMKPiBsdWRlL3g4Ni94ODZf
NjQKPiAtVSBfX2xpbnV4X18gLVUgX19GcmVlQlNEX18gLVUgX19zdW5fXyAtbm9zdGRpbmMgLWlz
eXN0ZW0KPiAvaG9tZS9yb3lnZXIvYXBvcnRzL3Rlc3RpbmcveGVuL3NyYy94ZW4tNC4xLjIvc3R1
YmRvbS8uLi9leHRyYXMvbWluaS1vcy9pbmNsdWQKPiBlL3Bvc2l4Cj4gLWlzeXN0ZW0gCj4gL2hv
bWUvcm95Z2VyL2Fwb3J0cy90ZXN0aW5nL3hlbi9zcmMveGVuLTQuMS4yL3N0dWJkb20vY3Jvc3Mt
cm9vdC14ODZfNjQveDgKPiA2XzY0LXhlbi1lbGYvaW5jbHVkZQo+IC1pc3lzdGVtIC91c3IvbGli
L2djYy94ODZfNjQtYWxwaW5lLWxpbnV4LXVjbGliYy80LjYuMi9pbmNsdWRlCj4gLWlzeXN0ZW0g
Cj4gL2hvbWUvcm95Z2VyL2Fwb3J0cy90ZXN0aW5nL3hlbi9zcmMveGVuLTQuMS4yL3N0dWJkb20v
bHdpcC14ODZfNjQvc3JjL2luY2x1Cj4gZGUKPiAtaXN5c3RlbSAKPiAvaG9tZS9yb3lnZXIvYXBv
cnRzL3Rlc3RpbmcveGVuL3NyYy94ZW4tNC4xLjIvc3R1YmRvbS9sd2lwLXg4Nl82NC9zcmMvaW5j
bHUKPiBkZS9pcHY0Cj4gLUkvaG9tZS9yb3lnZXIvYXBvcnRzL3Rlc3RpbmcveGVuL3NyYy94ZW4t
NC4xLjIvc3R1YmRvbS9pbmNsdWRlCj4gLUkvaG9tZS9yb3lnZXIvYXBvcnRzL3Rlc3RpbmcveGVu
L3NyYy94ZW4tNC4xLjIvc3R1YmRvbS8uLi94ZW4vaW5jbHVkZQo+IC1pc3lzdGVtIAo+IC9ob21l
L3JveWdlci9hcG9ydHMvdGVzdGluZy94ZW4vc3JjL3hlbi00LjEuMi9leHRyYXMvbWluaS1vcy8u
Li8uLi9leHRyYXMvbQo+IGluaS1vcy9pbmNsdWRlCj4gLURfX01JTklPU19fIC1ESEFWRV9MSUJD
IC1pc3lzdGVtCj4gL2hvbWUvcm95Z2VyL2Fwb3J0cy90ZXN0aW5nL3hlbi9zcmMveGVuLTQuMS4y
L2V4dHJhcy9taW5pLW9zLy4uLy4uL2V4dHJhcy9taW5pLQo+IG9zL2luY2x1ZGUvcG9zaXgKPiAt
aXN5c3RlbSAKPiAvaG9tZS9yb3lnZXIvYXBvcnRzL3Rlc3RpbmcveGVuL3NyYy94ZW4tNC4xLjIv
ZXh0cmFzL21pbmktb3MvLi4vLi4vdG9vbHMveGUKPiBuc3RvcmUKPiAtREhBVkVfTFdJUCAtaXN5
c3RlbQo+IC9ob21lL3JveWdlci9hcG9ydHMvdGVzdGluZy94ZW4vc3JjL3hlbi00LjEuMi9zdHVi
ZG9tL2x3aXAteDg2XzY0L3NyYy9pbmNsdWRlCj4gLWlzeXN0ZW0gCj4gL2hvbWUvcm95Z2VyL2Fw
b3J0cy90ZXN0aW5nL3hlbi9zcmMveGVuLTQuMS4yL3N0dWJkb20vbHdpcC14ODZfNjQvc3JjL2lu
Y2x1Cj4gZGUvaXB2NAo+IC1EX19YRU5fSU5URVJGQUNFX1ZFUlNJT05fXz0weDAwMDMwMjA1ICAt
aXN5c3RlbQo+IC9ob21lL3JveWdlci9hcG9ydHMvdGVzdGluZy94ZW4vc3JjL3hlbi00LjEuMi9l
eHRyYXMvbWluaS1vcy8uLi8uLi9leHRyYXMvbWluaS0KPiBvcy9pbmNsdWRlL3g4Ngo+IC1pc3lz
dGVtIAo+IC9ob21lL3JveWdlci9hcG9ydHMvdGVzdGluZy94ZW4vc3JjL3hlbi00LjEuMi9leHRy
YXMvbWluaS1vcy8uLi8uLi9leHRyYXMvbQo+IGluaS1vcy9pbmNsdWRlL3g4Ni94ODZfNjQKPiAt
YyBjb25zb2xlL3hlbmNvbnNfcmluZy5jIC1vCj4gL2hvbWUvcm95Z2VyL2Fwb3J0cy90ZXN0aW5n
L3hlbi9zcmMveGVuLTQuMS4yL3N0dWJkb20vbWluaS1vcy14ODZfNjQtaW9lbXUvY29uc28KPiBs
ZS94ZW5jb25zX3Jpbmcubwo+IGNvbnNvbGUveGVuY29uc19yaW5nLmM6IEluIGZ1bmN0aW9uICd4
ZW5jb25zX3Jpbmdfc2VuZF9ub19ub3RpZnknOgo+IGNvbnNvbGUveGVuY29uc19yaW5nLmM6MjY6
NDE6IGVycm9yOiBpbmxpbmluZyBmYWlsZWQgaW4gY2FsbCB0bwo+ICd4ZW5jb25zX2ludGVyZmFj
ZSc6IGNhbGwgaXMgdW5saWtlbHkgYW5kIGNvZGUgc2l6ZSB3b3VsZCBncm93Cj4gWy1XZXJyb3I9
aW5saW5lXQo+IGNvbnNvbGUveGVuY29uc19yaW5nLmM6Mzg6MTg6IGVycm9yOiBjYWxsZWQgZnJv
bSBoZXJlIFstV2Vycm9yPWlubGluZV0KPiBjYzE6IGFsbCB3YXJuaW5ncyBiZWluZyB0cmVhdGVk
IGFzIGVycm9ycwo+IAo+IEFsdGhvdWdoIEkgY2FuIGJ1aWxkIHhlbi11bnN0YWJsZSB3aXRob3V0
IGFueSBwcm9ibGVtcyBvbiB0aGUgc2FtZQo+IG1hY2hpbmUuIEkndmUgYmVlbiB0cnlpbmcgdG8g
ZmluZCB0aGUgcGF0Y2ggdGhhdCBzb2x2ZWQgdGhpcyBvbgo+IHVuc3RhYmxlLCBidXQgc28gZmFy
IEkgaGF2ZW4ndCBmb3VuZCBpdC4gQW55b25lIGtub3cgd2hpY2ggcGF0Y2ggZml4ZWQKPiBpdD8g
SSB3b3VsZCBsaWtlIHRvIGhhdmUgaXQgYmFja3BvcnRlZCB0byB4ZW4tNC4xLgoKSXQgbWF5IHdl
bGwgYmUgdGhhdCB0aGVyZSBpcyBubyBzdWNoIGNoYW5nZXNldCwgYnV0IHRoZSBjb21waWxlciBq
dXN0CmRlY2lkZXMgdG8gZXZhbHVhdGUgdGhlIGxpa2VsaWhvb2RzIGRpZmZlcmVudGx5LiBJJ20g
YXNzdW1pbmcgdGhhdCB0aGUKYnVpbGQgcHJvYmxlbSB3b3VsZCBnbyBhd2F5IGJ5IHJlbW92aW5n
IC1XaW5saW5lIGZyb20KZXh0cmFzL21pbmktb3MvbWluaW9zLm1rOkRFRl9DRkxBR1MgKHdoaWNo
IGlzIHF1ZXN0aW9uYWJsZSBpbgpjb25qdW5jdGlvbiB3aXRoIHRoZSAtV2Vycm9yIGZvcmNlZCB0
aGVyZSB0b28gLSBhIG1vcmUgcmVhc29uYWJseQphcHByb2FjaCB3b3VsZCBzZWVtIHRvIGJlIC1X
aW5saW5lIC1Xbm8tZXJyb3I9aW5saW5lLCBhcHBhcmVudGx5CmF2YWlsYWJsZSBzaW5jZSBnY2Mg
NC4yLngpLgoKSmFuCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29t
Cmh0dHA6Ly9saXN0cy54ZW5zb3VyY2UuY29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Fri Dec 23 08:29:33 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 Dec 2011 08:29:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Re0Uz-0003c1-SK; Fri, 23 Dec 2011 08:29:05 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Re0Uy-0003bq-4S
	for xen-devel@lists.xensource.com; Fri, 23 Dec 2011 08:29:04 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1324628937!8524105!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1039 invoked from network); 23 Dec 2011 08:28:58 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-15.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 23 Dec 2011 08:28:58 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 23 Dec 2011 08:28:57 +0000
Message-Id: <4EF44A100200007800069B5A@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 23 Dec 2011 08:29:52 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "=?UTF-8?Q?Roger=20Pau=20Monn=C3=A9?=" <roger.pau@entel.upc.edu>
References: <CAPLaKK506e57uCvSdkjCqkUs6AS6ty4Efa+Ekhrczu=OA+TCHw@mail.gmail.com>
In-Reply-To: <CAPLaKK506e57uCvSdkjCqkUs6AS6ty4Efa+Ekhrczu=OA+TCHw@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Stubdom build problem in 4.1.2 but not in
 xen-unstable
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Pj4+IE9uIDIyLjEyLjExIGF0IDE4OjAzLCBSb2dlciBQYXUgTW9ubsOpPHJvZ2VyLnBhdUBlbnRl
bC51cGMuZWR1PiB3cm90ZToKPiBIZWxsbywKPiAKPiBJJ3ZlIGZvdW5kIHRoZSBmb2xsb3dpbmcg
cHJvYmxlbSB3aGlsZSBidWlsZGluZyBYZW4gNC4xLjIgc3R1YmRvbXM6Cj4gCj4gZ2NjIC1EQ09O
RklHX1FFTVUgLW1uby1yZWQtem9uZSAtTzEgLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIKPiAtZm5v
LW9wdGltaXplLXNpYmxpbmctY2FsbHMgIC1tNjQgLW1uby1yZWQtem9uZSAtZm5vLXJlb3JkZXIt
YmxvY2tzCj4gLWZuby1hc3luY2hyb25vdXMtdW53aW5kLXRhYmxlcyAtbTY0IC1nIC1mbm8tc3Ry
aWN0LWFsaWFzaW5nCj4gLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1Xbm8t
dW51c2VkLXZhbHVlCj4gLVdkZWNsYXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQgLVduby11bnVzZWQt
YnV0LXNldC12YXJpYWJsZSAgLW5vcGllCj4gLWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNl
cHRpb25zIC1mbm8tYnVpbHRpbiAtV2FsbCAtV2Vycm9yCj4gLVdyZWR1bmRhbnQtZGVjbHMgLVdu
by1mb3JtYXQgLVduby1yZWR1bmRhbnQtZGVjbHMKPiAtZm5vLXN0YWNrLXByb3RlY3RvciAtZmdu
dTg5LWlubGluZSAtV3N0cmljdC1wcm90b3R5cGVzCj4gLVduZXN0ZWQtZXh0ZXJucyAtV3BvaW50
ZXItYXJpdGggLVdpbmxpbmUgLWcgLURHTlRfREVCVUcKPiAtREdOVE1BUF9ERUJVRyAtRF9fSU5T
SURFX01JTklPU19fIC1tNjQgLW1uby1yZWQtem9uZQo+IC1mbm8tcmVvcmRlci1ibG9ja3MgLWZu
by1hc3luY2hyb25vdXMtdW53aW5kLXRhYmxlcyAtT3MKPiAtZm9taXQtZnJhbWUtcG9pbnRlciAt
aXN5c3RlbQo+IC9ob21lL3JveWdlci9hcG9ydHMvdGVzdGluZy94ZW4vc3JjL3hlbi00LjEuMi9z
dHViZG9tLy4uL2V4dHJhcy9taW5pLW9zL2luY2x1ZAo+IGUKPiAtRF9fTUlOSU9TX18gLURIQVZF
X0xJQkMgLWlzeXN0ZW0KPiAvaG9tZS9yb3lnZXIvYXBvcnRzL3Rlc3RpbmcveGVuL3NyYy94ZW4t
NC4xLjIvc3R1YmRvbS8uLi9leHRyYXMvbWluaS1vcy9pbmNsdWQKPiBlL3Bvc2l4Cj4gLWlzeXN0
ZW0gCj4gL2hvbWUvcm95Z2VyL2Fwb3J0cy90ZXN0aW5nL3hlbi9zcmMveGVuLTQuMS4yL3N0dWJk
b20vLi4vdG9vbHMveGVuc3RvcmUKPiAgLWlzeXN0ZW0gCj4gL2hvbWUvcm95Z2VyL2Fwb3J0cy90
ZXN0aW5nL3hlbi9zcmMveGVuLTQuMS4yL3N0dWJkb20vLi4vZXh0cmFzL21pbmktb3MvaW5jCj4g
bHVkZS94ODYKPiAtaXN5c3RlbSAKPiAvaG9tZS9yb3lnZXIvYXBvcnRzL3Rlc3RpbmcveGVuL3Ny
Yy94ZW4tNC4xLjIvc3R1YmRvbS8uLi9leHRyYXMvbWluaS1vcy9pbmMKPiBsdWRlL3g4Ni94ODZf
NjQKPiAtVSBfX2xpbnV4X18gLVUgX19GcmVlQlNEX18gLVUgX19zdW5fXyAtbm9zdGRpbmMgLWlz
eXN0ZW0KPiAvaG9tZS9yb3lnZXIvYXBvcnRzL3Rlc3RpbmcveGVuL3NyYy94ZW4tNC4xLjIvc3R1
YmRvbS8uLi9leHRyYXMvbWluaS1vcy9pbmNsdWQKPiBlL3Bvc2l4Cj4gLWlzeXN0ZW0gCj4gL2hv
bWUvcm95Z2VyL2Fwb3J0cy90ZXN0aW5nL3hlbi9zcmMveGVuLTQuMS4yL3N0dWJkb20vY3Jvc3Mt
cm9vdC14ODZfNjQveDgKPiA2XzY0LXhlbi1lbGYvaW5jbHVkZQo+IC1pc3lzdGVtIC91c3IvbGli
L2djYy94ODZfNjQtYWxwaW5lLWxpbnV4LXVjbGliYy80LjYuMi9pbmNsdWRlCj4gLWlzeXN0ZW0g
Cj4gL2hvbWUvcm95Z2VyL2Fwb3J0cy90ZXN0aW5nL3hlbi9zcmMveGVuLTQuMS4yL3N0dWJkb20v
bHdpcC14ODZfNjQvc3JjL2luY2x1Cj4gZGUKPiAtaXN5c3RlbSAKPiAvaG9tZS9yb3lnZXIvYXBv
cnRzL3Rlc3RpbmcveGVuL3NyYy94ZW4tNC4xLjIvc3R1YmRvbS9sd2lwLXg4Nl82NC9zcmMvaW5j
bHUKPiBkZS9pcHY0Cj4gLUkvaG9tZS9yb3lnZXIvYXBvcnRzL3Rlc3RpbmcveGVuL3NyYy94ZW4t
NC4xLjIvc3R1YmRvbS9pbmNsdWRlCj4gLUkvaG9tZS9yb3lnZXIvYXBvcnRzL3Rlc3RpbmcveGVu
L3NyYy94ZW4tNC4xLjIvc3R1YmRvbS8uLi94ZW4vaW5jbHVkZQo+IC1pc3lzdGVtIAo+IC9ob21l
L3JveWdlci9hcG9ydHMvdGVzdGluZy94ZW4vc3JjL3hlbi00LjEuMi9leHRyYXMvbWluaS1vcy8u
Li8uLi9leHRyYXMvbQo+IGluaS1vcy9pbmNsdWRlCj4gLURfX01JTklPU19fIC1ESEFWRV9MSUJD
IC1pc3lzdGVtCj4gL2hvbWUvcm95Z2VyL2Fwb3J0cy90ZXN0aW5nL3hlbi9zcmMveGVuLTQuMS4y
L2V4dHJhcy9taW5pLW9zLy4uLy4uL2V4dHJhcy9taW5pLQo+IG9zL2luY2x1ZGUvcG9zaXgKPiAt
aXN5c3RlbSAKPiAvaG9tZS9yb3lnZXIvYXBvcnRzL3Rlc3RpbmcveGVuL3NyYy94ZW4tNC4xLjIv
ZXh0cmFzL21pbmktb3MvLi4vLi4vdG9vbHMveGUKPiBuc3RvcmUKPiAtREhBVkVfTFdJUCAtaXN5
c3RlbQo+IC9ob21lL3JveWdlci9hcG9ydHMvdGVzdGluZy94ZW4vc3JjL3hlbi00LjEuMi9zdHVi
ZG9tL2x3aXAteDg2XzY0L3NyYy9pbmNsdWRlCj4gLWlzeXN0ZW0gCj4gL2hvbWUvcm95Z2VyL2Fw
b3J0cy90ZXN0aW5nL3hlbi9zcmMveGVuLTQuMS4yL3N0dWJkb20vbHdpcC14ODZfNjQvc3JjL2lu
Y2x1Cj4gZGUvaXB2NAo+IC1EX19YRU5fSU5URVJGQUNFX1ZFUlNJT05fXz0weDAwMDMwMjA1ICAt
aXN5c3RlbQo+IC9ob21lL3JveWdlci9hcG9ydHMvdGVzdGluZy94ZW4vc3JjL3hlbi00LjEuMi9l
eHRyYXMvbWluaS1vcy8uLi8uLi9leHRyYXMvbWluaS0KPiBvcy9pbmNsdWRlL3g4Ngo+IC1pc3lz
dGVtIAo+IC9ob21lL3JveWdlci9hcG9ydHMvdGVzdGluZy94ZW4vc3JjL3hlbi00LjEuMi9leHRy
YXMvbWluaS1vcy8uLi8uLi9leHRyYXMvbQo+IGluaS1vcy9pbmNsdWRlL3g4Ni94ODZfNjQKPiAt
YyBjb25zb2xlL3hlbmNvbnNfcmluZy5jIC1vCj4gL2hvbWUvcm95Z2VyL2Fwb3J0cy90ZXN0aW5n
L3hlbi9zcmMveGVuLTQuMS4yL3N0dWJkb20vbWluaS1vcy14ODZfNjQtaW9lbXUvY29uc28KPiBs
ZS94ZW5jb25zX3Jpbmcubwo+IGNvbnNvbGUveGVuY29uc19yaW5nLmM6IEluIGZ1bmN0aW9uICd4
ZW5jb25zX3Jpbmdfc2VuZF9ub19ub3RpZnknOgo+IGNvbnNvbGUveGVuY29uc19yaW5nLmM6MjY6
NDE6IGVycm9yOiBpbmxpbmluZyBmYWlsZWQgaW4gY2FsbCB0bwo+ICd4ZW5jb25zX2ludGVyZmFj
ZSc6IGNhbGwgaXMgdW5saWtlbHkgYW5kIGNvZGUgc2l6ZSB3b3VsZCBncm93Cj4gWy1XZXJyb3I9
aW5saW5lXQo+IGNvbnNvbGUveGVuY29uc19yaW5nLmM6Mzg6MTg6IGVycm9yOiBjYWxsZWQgZnJv
bSBoZXJlIFstV2Vycm9yPWlubGluZV0KPiBjYzE6IGFsbCB3YXJuaW5ncyBiZWluZyB0cmVhdGVk
IGFzIGVycm9ycwo+IAo+IEFsdGhvdWdoIEkgY2FuIGJ1aWxkIHhlbi11bnN0YWJsZSB3aXRob3V0
IGFueSBwcm9ibGVtcyBvbiB0aGUgc2FtZQo+IG1hY2hpbmUuIEkndmUgYmVlbiB0cnlpbmcgdG8g
ZmluZCB0aGUgcGF0Y2ggdGhhdCBzb2x2ZWQgdGhpcyBvbgo+IHVuc3RhYmxlLCBidXQgc28gZmFy
IEkgaGF2ZW4ndCBmb3VuZCBpdC4gQW55b25lIGtub3cgd2hpY2ggcGF0Y2ggZml4ZWQKPiBpdD8g
SSB3b3VsZCBsaWtlIHRvIGhhdmUgaXQgYmFja3BvcnRlZCB0byB4ZW4tNC4xLgoKSXQgbWF5IHdl
bGwgYmUgdGhhdCB0aGVyZSBpcyBubyBzdWNoIGNoYW5nZXNldCwgYnV0IHRoZSBjb21waWxlciBq
dXN0CmRlY2lkZXMgdG8gZXZhbHVhdGUgdGhlIGxpa2VsaWhvb2RzIGRpZmZlcmVudGx5LiBJJ20g
YXNzdW1pbmcgdGhhdCB0aGUKYnVpbGQgcHJvYmxlbSB3b3VsZCBnbyBhd2F5IGJ5IHJlbW92aW5n
IC1XaW5saW5lIGZyb20KZXh0cmFzL21pbmktb3MvbWluaW9zLm1rOkRFRl9DRkxBR1MgKHdoaWNo
IGlzIHF1ZXN0aW9uYWJsZSBpbgpjb25qdW5jdGlvbiB3aXRoIHRoZSAtV2Vycm9yIGZvcmNlZCB0
aGVyZSB0b28gLSBhIG1vcmUgcmVhc29uYWJseQphcHByb2FjaCB3b3VsZCBzZWVtIHRvIGJlIC1X
aW5saW5lIC1Xbm8tZXJyb3I9aW5saW5lLCBhcHBhcmVudGx5CmF2YWlsYWJsZSBzaW5jZSBnY2Mg
NC4yLngpLgoKSmFuCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29t
Cmh0dHA6Ly9saXN0cy54ZW5zb3VyY2UuY29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Fri Dec 23 08:33:46 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 Dec 2011 08:33:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Re0ZE-0003kd-IP; Fri, 23 Dec 2011 08:33:28 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Re0ZC-0003kQ-CA
	for xen-devel@lists.xensource.com; Fri, 23 Dec 2011 08:33:26 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1324629199!8394342!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28709 invoked from network); 23 Dec 2011 08:33:19 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-16.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 23 Dec 2011 08:33:19 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 23 Dec 2011 08:33:18 +0000
Message-Id: <4EF44B130200007800069B5D@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 23 Dec 2011 08:34:11 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>
References: <patchbomb.1324575382@andrewcoop.uk.xensource.com>
	<f571dc8e43687c6027d1.1324575383@andrewcoop.uk.xensource.com>
In-Reply-To: <f571dc8e43687c6027d1.1324575383@andrewcoop.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 1 of 3] KEXEC: Add new hypercall to fix
 64/32bit truncation errors. v2
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 22.12.11 at 18:36, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
> Currently, KEXEC_CMD_kexec_get_range in compat mode, or with 32bit
> Xen, will truncate 64bit pointers to 32bits, leading to problems on
> machines with more than 4GiB of RAM.  As 32bit dom0 kernels tend to be
> PAE capable, this is especially wasteful, as most structures currently
> limited to <4GiB could easily be <64GiB instead.
> 
> Therefore, introduce a new hypercall 'KEXEC_CMD_kexec64_get_range'
> which passes similar information as KEXEC_CMD_kexec_get_range, but
> which uses a structure with explicitly specified field widths, causing
> it to be identical in the compat and regular case.  This new
> structure, xen_kexec64_range_t, will be the same as xen_kexec_range_t
> if Xen is compiled for x86_64, but will still use 64bit integers if
> Xen is compiled for x86_32.
> 
> To fix 32bit Xen which uses 32bit integers for addresses and sizes,
> change the internals to use xen_kexec64_range_t which will use 64bit
> integers instead.  This also involves changing several casts to
> explicitly use uint64_ts rather than unsigned longs.

Just for the record - I continue to be opposed to doing this for the
32-bit hypervisor. All relevant allocations are below 4G there, so
there's simply no need to decrease code readability for no benefit.

Jan

> In addition, the hypercall entry points need updating to be able to
> cater for all possibilities.
> 
> |Xen/dom0 bits|          Bit width of addresses in structure for        |
> +------+------+---------------------------+-----------------------------+
> | Xen  | dom0 | KEXEC_CMD_kexec_get_range | KEXEC_CMD_kexec64_get_range |
> +------+------+---------------------------+-----------------------------+
> |  32  |  32  |             32            |              64             |
> |  64  |  32  |             32            |              64             |
> |  64  |  64  |             64            |              64             |
> +------+------+---------------------------+-----------------------------+
> 
> This has been solved by splitting do_kexec_op_internal back into
> do_kexec_op{,_compat} and changing kexec_get_range{,_compat} to
> kexec_get_range{32,64} which now exist irrespective of CONFIG_COMPAT
> or not.
> 
> The knock-on effect of removing do_kexec_op_internal means that
> kexec_load_unload_compat is only ever called from inside an #ifdef
> CONFIG_COMPAT codepath, which does not exist on Xen x86_32.
> Therefore, move the #ifdef CONFIG_COMPAT guards to include the entire
> function.
> 
> Finally, and a little unrelatedly, fix KEXEC_CMD_kexec_{load,unload}
> to return -EBUSY instead of EOK if a kexec is in progress.
> 
> Changes since v1:
>  *  Fix check for pointer truncation to work when Xen is compiled for
>     32 bit mode as well.
> 
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
> 
> diff -r e56500f95b6a -r f571dc8e4368 xen/arch/ia64/xen/machine_kexec.c
> --- a/xen/arch/ia64/xen/machine_kexec.c
> +++ b/xen/arch/ia64/xen/machine_kexec.c
> @@ -102,10 +102,10 @@ void machine_reboot_kexec(xen_kexec_imag
>  	machine_kexec(image);
>  }
>  
> -int machine_kexec_get_xen(xen_kexec_range_t *range)
> +int machine_kexec_get_xen(xen_kexec64_range_t *range)
>  {
>  	range->start = ia64_tpa(_text);
> -	range->size = (unsigned long)_end - (unsigned long)_text;
> +	range->size = (uint64_t)_end - (uint64_t)_text;
>  	return 0;
>  }
>  
> @@ -113,31 +113,31 @@ int machine_kexec_get_xen(xen_kexec_rang
>  #define ELF_PAGE_SIZE  (__IA64_UL_CONST(1) << ELF_PAGE_SHIFT)
>  #define ELF_PAGE_MASK  (~(ELF_PAGE_SIZE - 1))
>  
> -static int machine_kexec_get_xenheap(xen_kexec_range_t *range)
> +static int machine_kexec_get_xenheap(xen_kexec64_range_t *range)
>  {
>  	range->start = (ia64_tpa(_end) + (ELF_PAGE_SIZE - 1)) & ELF_PAGE_MASK;
>  	range->size =
> -		(((unsigned long)range->start + KERNEL_TR_PAGE_SIZE) &
> +		(((uint64_t)range->start + KERNEL_TR_PAGE_SIZE) &
>           ~(KERNEL_TR_PAGE_SIZE - 1))
> -		- (unsigned long)range->start;
> +		- (uint64_t)range->start;
>  	return 0;
>  }
>  
> -static int machine_kexec_get_boot_param(xen_kexec_range_t *range)
> +static int machine_kexec_get_boot_param(xen_kexec64_range_t *range)
>  {
>  	range->start = __pa(ia64_boot_param);
>  	range->size = sizeof(*ia64_boot_param);
>  	return 0;
>  }
>  
> -static int machine_kexec_get_efi_memmap(xen_kexec_range_t *range)
> +static int machine_kexec_get_efi_memmap(xen_kexec64_range_t *range)
>  {
>  	range->start = ia64_boot_param->efi_memmap;
>  	range->size = ia64_boot_param->efi_memmap_size;
>  	return 0;
>  }
>  
> -int machine_kexec_get(xen_kexec_range_t *range)
> +int machine_kexec_get(xen_kexec64_range_t *range)
>  {
>  	switch (range->range) {
>  	case KEXEC_RANGE_MA_XEN:
> diff -r e56500f95b6a -r f571dc8e4368 xen/arch/x86/machine_kexec.c
> --- a/xen/arch/x86/machine_kexec.c
> +++ b/xen/arch/x86/machine_kexec.c
> @@ -120,7 +120,7 @@ void machine_kexec(xen_kexec_image_t *im
>      }
>  }
>  
> -int machine_kexec_get(xen_kexec_range_t *range)
> +int machine_kexec_get(xen_kexec64_range_t *range)
>  {
>  	if (range->range != KEXEC_RANGE_MA_XEN)
>  		return -EINVAL;
> diff -r e56500f95b6a -r f571dc8e4368 xen/arch/x86/x86_32/machine_kexec.c
> --- a/xen/arch/x86/x86_32/machine_kexec.c
> +++ b/xen/arch/x86/x86_32/machine_kexec.c
> @@ -11,11 +11,11 @@
>  #include <asm/page.h>
>  #include <public/kexec.h>
>  
> -int machine_kexec_get_xen(xen_kexec_range_t *range)
> +int machine_kexec_get_xen(xen_kexec64_range_t *range)
>  {
>          range->start = virt_to_maddr(_start);
> -        range->size = (unsigned long)xenheap_phys_end -
> -                      (unsigned long)range->start;
> +        range->size = (uint64_t)xenheap_phys_end -
> +                      (uint64_t)range->start;
>          return 0;
>  }
>  
> diff -r e56500f95b6a -r f571dc8e4368 xen/arch/x86/x86_64/machine_kexec.c
> --- a/xen/arch/x86/x86_64/machine_kexec.c
> +++ b/xen/arch/x86/x86_64/machine_kexec.c
> @@ -11,10 +11,10 @@
>  #include <asm/page.h>
>  #include <public/kexec.h>
>  
> -int machine_kexec_get_xen(xen_kexec_range_t *range)
> +int machine_kexec_get_xen(xen_kexec64_range_t *range)
>  {
>          range->start = virt_to_maddr(_start);
> -        range->size = virt_to_maddr(_end) - (unsigned long)range->start;
> +        range->size = virt_to_maddr(_end) - (uint64_t)range->start;
>          return 0;
>  }
>  
> diff -r e56500f95b6a -r f571dc8e4368 xen/common/kexec.c
> --- a/xen/common/kexec.c
> +++ b/xen/common/kexec.c
> @@ -56,6 +56,14 @@ static struct {
>      unsigned long size;
>  } ranges[16] __initdata;
>  
> +/* This XLAT macro is required now even without CONFIG_COMPAT. */
> +#define TRANSLATE_kexec_range(_d_, _s_) do { \
> +    (_d_)->range = (_s_)->range; \
> +    (_d_)->nr = (_s_)->nr; \
> +    (_d_)->size = (_s_)->size; \
> +    (_d_)->start = (_s_)->start; \
> +} while (0)
> +
>  /*
>   * Parse command lines in the format
>   *
> @@ -280,7 +288,7 @@ static int sizeof_note(const char *name,
>              ELFNOTE_ALIGN(descsz));
>  }
>  
> -static int kexec_get_reserve(xen_kexec_range_t *range)
> +static int kexec_get_reserve(xen_kexec64_range_t *range)
>  {
>      if ( kexec_crash_area.size > 0 && kexec_crash_area.start > 0) {
>          range->start = kexec_crash_area.start;
> @@ -291,7 +299,7 @@ static int kexec_get_reserve(xen_kexec_r
>      return 0;
>  }
>  
> -static int kexec_get_cpu(xen_kexec_range_t *range)
> +static int kexec_get_cpu(xen_kexec64_range_t *range)
>  {
>      int nr = range->nr;
>      int nr_bytes = 0;
> @@ -335,14 +343,14 @@ static int kexec_get_cpu(xen_kexec_range
>      return 0;
>  }
>  
> -static int kexec_get_vmcoreinfo(xen_kexec_range_t *range)
> +static int kexec_get_vmcoreinfo(xen_kexec64_range_t *range)
>  {
>      range->start = __pa((unsigned long)vmcoreinfo_data);
>      range->size = VMCOREINFO_BYTES;
>      return 0;
>  }
>  
> -static int kexec_get_range_internal(xen_kexec_range_t *range)
> +static int kexec_get_range_internal(xen_kexec64_range_t *range)
>  {
>      int ret = -EINVAL;
>  
> @@ -365,9 +373,14 @@ static int kexec_get_range_internal(xen_
>      return ret;
>  }
>  
> -static int kexec_get_range(XEN_GUEST_HANDLE(void) uarg)
> +/* This function can be invoked from either a KEXEC_CMD_kexec64_get_range
> + * hypercall, or from a KEXEC_CMD_kexec_get_range hypercall with 64bit dom0
> + * on 64bit Xen.  In the first case, the guest structure is a 
> + * xen_kexec64_range_t, and in the second case, the xen_kexec_range_t guest
> + * structure is identical to xen_kexec64_range_t. */
> +static int kexec_get_range64(XEN_GUEST_HANDLE(void) uarg)
>  {
> -    xen_kexec_range_t range;
> +    xen_kexec64_range_t range;
>      int ret = -EINVAL;
>  
>      if ( unlikely(copy_from_guest(&range, uarg, 1)) )
> @@ -381,34 +394,40 @@ static int kexec_get_range(XEN_GUEST_HAN
>      return ret;
>  }
>  
> -static int kexec_get_range_compat(XEN_GUEST_HANDLE(void) uarg)
> +/* This function can be invoked from either a KEXEC_CMD_kexec_get_range
> + * compat hypercall for 32bit dom0 on 64bit Xen, or from the same hypercall
> + * on 32bit Xen.  In both cases, the guest argument uses 32bit integers, so 
> 
> + * translate them to 64bit for use by kexec_get_range_internal.  The
> + * preprocessor guards are to choose the correct 32bit structure, as the
> + * compat_* structures dont exist in 32bit Xen. */
> +static int kexec_get_range32(XEN_GUEST_HANDLE(void) uarg)
>  {
> +    xen_kexec64_range_t range64;
>  #ifdef CONFIG_COMPAT
> -    xen_kexec_range_t range;
> -    compat_kexec_range_t compat_range;
> +    compat_kexec_range_t range32;
> +#else
> +    xen_kexec_range_t range32;
> +#endif
>      int ret = -EINVAL;
>  
> -    if ( unlikely(copy_from_guest(&compat_range, uarg, 1)) )
> +    if ( unlikely(copy_from_guest(&range32, uarg, 1)) )
>          return -EFAULT;
>  
> -    XLAT_kexec_range(&range, &compat_range);
> +    TRANSLATE_kexec_range(&range64, &range32);
>  
> -    ret = kexec_get_range_internal(&range);
> +    ret = kexec_get_range_internal(&range64);
>  
>      /* Dont silently truncate physical addresses or sizes. */
> -    if ( (range.start | range.size) & ~(unsigned long)(~0u) )
> +    if ( (range64.start | range64.size) & 0xffffffff00000000ULL )
>          return -ERANGE;
>  
>      if ( ret == 0 ) {
> -        XLAT_kexec_range(&compat_range, &range);
> -        if ( unlikely(copy_to_guest(uarg, &compat_range, 1)) )
> +        TRANSLATE_kexec_range(&range32, &range64);
> +        if ( unlikely(copy_to_guest(uarg, &range32, 1)) )
>               return -EFAULT;
>      }
>  
>      return ret;
> -#else /* CONFIG_COMPAT */
> -    return 0;
> -#endif /* CONFIG_COMPAT */
>  }
>  
>  static int kexec_load_get_bits(int type, int *base, int *bit)
> @@ -543,10 +562,10 @@ static int kexec_load_unload(unsigned lo
>      return kexec_load_unload_internal(op, &load);
>  }
>  
> +#ifdef CONFIG_COMPAT
>  static int kexec_load_unload_compat(unsigned long op,
>                                      XEN_GUEST_HANDLE(void) uarg)
>  {
> -#ifdef CONFIG_COMPAT
>      compat_kexec_load_t compat_load;
>      xen_kexec_load_t load;
>  
> @@ -564,10 +583,8 @@ static int kexec_load_unload_compat(unsi
>      XLAT_kexec_image(&load.image, &compat_load.image);
>  
>      return kexec_load_unload_internal(op, &load);
> -#else /* CONFIG_COMPAT */
> -    return 0;
> +}
>  #endif /* CONFIG_COMPAT */
> -}
>  
>  static int kexec_exec(XEN_GUEST_HANDLE(void) uarg)
>  {
> @@ -601,8 +618,51 @@ static int kexec_exec(XEN_GUEST_HANDLE(v
>      return -EINVAL; /* never reached */
>  }
>  
> -int do_kexec_op_internal(unsigned long op, XEN_GUEST_HANDLE(void) uarg,
> -                           int compat)
> +long do_kexec_op(unsigned long op, XEN_GUEST_HANDLE(void) uarg)
> +{
> +    unsigned long flags;
> +    int ret = -EINVAL;
> +
> +    if ( !IS_PRIV(current->domain) )
> +        return -EPERM;
> +
> +    ret = xsm_kexec();
> +    if ( ret )
> +        return ret;
> +
> +    switch ( op )
> +    {
> +#ifdef __i386__
> +    case KEXEC_CMD_kexec_get_range:
> +        ret = kexec_get_range32(uarg);
> +        break;
> +#else
> +    case KEXEC_CMD_kexec_get_range:
> +#endif
> +    case KEXEC_CMD_kexec64_get_range:
> +        ret = kexec_get_range64(uarg);
> +        break;
> +
> +    case KEXEC_CMD_kexec_load:
> +    case KEXEC_CMD_kexec_unload:
> +        spin_lock_irqsave(&kexec_lock, flags);
> +        if (!test_bit(KEXEC_FLAG_IN_PROGRESS, &kexec_flags))
> +            ret = kexec_load_unload(op, uarg);
> +        else
> +            ret = -EBUSY;
> +        spin_unlock_irqrestore(&kexec_lock, flags);
> +        break;
> +
> +    case KEXEC_CMD_kexec:
> +        ret = kexec_exec(uarg);
> +        break;
> +    }
> +
> +    return ret;
> +}
> +
> +#ifdef CONFIG_COMPAT
> +int compat_kexec_op(unsigned long op, XEN_GUEST_HANDLE(void) uarg)
>  {
>      unsigned long flags;
>      int ret = -EINVAL;
> @@ -617,23 +677,21 @@ int do_kexec_op_internal(unsigned long o
>      switch ( op )
>      {
>      case KEXEC_CMD_kexec_get_range:
> -        if (compat)
> -                ret = kexec_get_range_compat(uarg);
> -        else
> -                ret = kexec_get_range(uarg);
> +        ret = kexec_get_range32(uarg);
> +        break;
> +    case KEXEC_CMD_kexec64_get_range:
> +        ret = kexec_get_range64(uarg);
>          break;
>      case KEXEC_CMD_kexec_load:
>      case KEXEC_CMD_kexec_unload:
>          spin_lock_irqsave(&kexec_lock, flags);
>          if (!test_bit(KEXEC_FLAG_IN_PROGRESS, &kexec_flags))
> -        {
> -                if (compat)
> -                        ret = kexec_load_unload_compat(op, uarg);
> -                else
> -                        ret = kexec_load_unload(op, uarg);
> -        }
> +            ret = kexec_load_unload_compat(op, uarg);
> +        else
> +            ret = -EBUSY;
>          spin_unlock_irqrestore(&kexec_lock, flags);
>          break;
> +
>      case KEXEC_CMD_kexec:
>          ret = kexec_exec(uarg);
>          break;
> @@ -641,17 +699,6 @@ int do_kexec_op_internal(unsigned long o
>  
>      return ret;
>  }
> -
> -long do_kexec_op(unsigned long op, XEN_GUEST_HANDLE(void) uarg)
> -{
> -    return do_kexec_op_internal(op, uarg, 0);
> -}
> -
> -#ifdef CONFIG_COMPAT
> -int compat_kexec_op(unsigned long op, XEN_GUEST_HANDLE(void) uarg)
> -{
> -    return do_kexec_op_internal(op, uarg, 1);
> -}
>  #endif
>  
>  /*
> diff -r e56500f95b6a -r f571dc8e4368 xen/include/public/kexec.h
> --- a/xen/include/public/kexec.h
> +++ b/xen/include/public/kexec.h
> @@ -155,6 +155,15 @@ typedef struct xen_kexec_range {
>      unsigned long start;
>  } xen_kexec_range_t;
>  
> +#define KEXEC_CMD_kexec64_get_range      4
> +/* xen_kexec_range_t using explicit sizes for fields. */
> +typedef struct xen_kexec64_range {
> +    int32_t range;
> +    int32_t nr;
> +    uint64_t size;
> +    uint64_t start;
> +} xen_kexec64_range_t;
> +
>  #endif /* _XEN_PUBLIC_KEXEC_H */
>  
>  /*
> diff -r e56500f95b6a -r f571dc8e4368 xen/include/xen/kexec.h
> --- a/xen/include/xen/kexec.h
> +++ b/xen/include/xen/kexec.h
> @@ -34,8 +34,8 @@ void kexec_crash(void);
>  void kexec_crash_save_cpu(void);
>  crash_xen_info_t *kexec_crash_save_info(void);
>  void machine_crash_shutdown(void);
> -int machine_kexec_get(xen_kexec_range_t *range);
> -int machine_kexec_get_xen(xen_kexec_range_t *range);
> +int machine_kexec_get(xen_kexec64_range_t *range);
> +int machine_kexec_get_xen(xen_kexec64_range_t *range);
>  
>  void compat_machine_kexec(unsigned long rnk,
>                            unsigned long indirection_page,
> diff -r e56500f95b6a -r f571dc8e4368 xen/include/xlat.lst
> --- a/xen/include/xlat.lst
> +++ b/xen/include/xlat.lst
> @@ -50,9 +50,7 @@
>  ?	grant_entry_v1			grant_table.h
>  ?       grant_entry_header              grant_table.h
>  ?	grant_entry_v2			grant_table.h
> -?	kexec_exec			kexec.h
>  !	kexec_image			kexec.h
> -!	kexec_range			kexec.h
>  !	add_to_physmap			memory.h
>  !	foreign_memory_map		memory.h
>  !	memory_exchange			memory.h
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com 
> http://lists.xensource.com/xen-devel 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 23 08:33:46 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 Dec 2011 08:33:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Re0ZE-0003kd-IP; Fri, 23 Dec 2011 08:33:28 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Re0ZC-0003kQ-CA
	for xen-devel@lists.xensource.com; Fri, 23 Dec 2011 08:33:26 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1324629199!8394342!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28709 invoked from network); 23 Dec 2011 08:33:19 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-16.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 23 Dec 2011 08:33:19 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 23 Dec 2011 08:33:18 +0000
Message-Id: <4EF44B130200007800069B5D@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 23 Dec 2011 08:34:11 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>
References: <patchbomb.1324575382@andrewcoop.uk.xensource.com>
	<f571dc8e43687c6027d1.1324575383@andrewcoop.uk.xensource.com>
In-Reply-To: <f571dc8e43687c6027d1.1324575383@andrewcoop.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 1 of 3] KEXEC: Add new hypercall to fix
 64/32bit truncation errors. v2
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 22.12.11 at 18:36, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
> Currently, KEXEC_CMD_kexec_get_range in compat mode, or with 32bit
> Xen, will truncate 64bit pointers to 32bits, leading to problems on
> machines with more than 4GiB of RAM.  As 32bit dom0 kernels tend to be
> PAE capable, this is especially wasteful, as most structures currently
> limited to <4GiB could easily be <64GiB instead.
> 
> Therefore, introduce a new hypercall 'KEXEC_CMD_kexec64_get_range'
> which passes similar information as KEXEC_CMD_kexec_get_range, but
> which uses a structure with explicitly specified field widths, causing
> it to be identical in the compat and regular case.  This new
> structure, xen_kexec64_range_t, will be the same as xen_kexec_range_t
> if Xen is compiled for x86_64, but will still use 64bit integers if
> Xen is compiled for x86_32.
> 
> To fix 32bit Xen which uses 32bit integers for addresses and sizes,
> change the internals to use xen_kexec64_range_t which will use 64bit
> integers instead.  This also involves changing several casts to
> explicitly use uint64_ts rather than unsigned longs.

Just for the record - I continue to be opposed to doing this for the
32-bit hypervisor. All relevant allocations are below 4G there, so
there's simply no need to decrease code readability for no benefit.

Jan

> In addition, the hypercall entry points need updating to be able to
> cater for all possibilities.
> 
> |Xen/dom0 bits|          Bit width of addresses in structure for        |
> +------+------+---------------------------+-----------------------------+
> | Xen  | dom0 | KEXEC_CMD_kexec_get_range | KEXEC_CMD_kexec64_get_range |
> +------+------+---------------------------+-----------------------------+
> |  32  |  32  |             32            |              64             |
> |  64  |  32  |             32            |              64             |
> |  64  |  64  |             64            |              64             |
> +------+------+---------------------------+-----------------------------+
> 
> This has been solved by splitting do_kexec_op_internal back into
> do_kexec_op{,_compat} and changing kexec_get_range{,_compat} to
> kexec_get_range{32,64} which now exist irrespective of CONFIG_COMPAT
> or not.
> 
> The knock-on effect of removing do_kexec_op_internal means that
> kexec_load_unload_compat is only ever called from inside an #ifdef
> CONFIG_COMPAT codepath, which does not exist on Xen x86_32.
> Therefore, move the #ifdef CONFIG_COMPAT guards to include the entire
> function.
> 
> Finally, and a little unrelatedly, fix KEXEC_CMD_kexec_{load,unload}
> to return -EBUSY instead of EOK if a kexec is in progress.
> 
> Changes since v1:
>  *  Fix check for pointer truncation to work when Xen is compiled for
>     32 bit mode as well.
> 
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
> 
> diff -r e56500f95b6a -r f571dc8e4368 xen/arch/ia64/xen/machine_kexec.c
> --- a/xen/arch/ia64/xen/machine_kexec.c
> +++ b/xen/arch/ia64/xen/machine_kexec.c
> @@ -102,10 +102,10 @@ void machine_reboot_kexec(xen_kexec_imag
>  	machine_kexec(image);
>  }
>  
> -int machine_kexec_get_xen(xen_kexec_range_t *range)
> +int machine_kexec_get_xen(xen_kexec64_range_t *range)
>  {
>  	range->start = ia64_tpa(_text);
> -	range->size = (unsigned long)_end - (unsigned long)_text;
> +	range->size = (uint64_t)_end - (uint64_t)_text;
>  	return 0;
>  }
>  
> @@ -113,31 +113,31 @@ int machine_kexec_get_xen(xen_kexec_rang
>  #define ELF_PAGE_SIZE  (__IA64_UL_CONST(1) << ELF_PAGE_SHIFT)
>  #define ELF_PAGE_MASK  (~(ELF_PAGE_SIZE - 1))
>  
> -static int machine_kexec_get_xenheap(xen_kexec_range_t *range)
> +static int machine_kexec_get_xenheap(xen_kexec64_range_t *range)
>  {
>  	range->start = (ia64_tpa(_end) + (ELF_PAGE_SIZE - 1)) & ELF_PAGE_MASK;
>  	range->size =
> -		(((unsigned long)range->start + KERNEL_TR_PAGE_SIZE) &
> +		(((uint64_t)range->start + KERNEL_TR_PAGE_SIZE) &
>           ~(KERNEL_TR_PAGE_SIZE - 1))
> -		- (unsigned long)range->start;
> +		- (uint64_t)range->start;
>  	return 0;
>  }
>  
> -static int machine_kexec_get_boot_param(xen_kexec_range_t *range)
> +static int machine_kexec_get_boot_param(xen_kexec64_range_t *range)
>  {
>  	range->start = __pa(ia64_boot_param);
>  	range->size = sizeof(*ia64_boot_param);
>  	return 0;
>  }
>  
> -static int machine_kexec_get_efi_memmap(xen_kexec_range_t *range)
> +static int machine_kexec_get_efi_memmap(xen_kexec64_range_t *range)
>  {
>  	range->start = ia64_boot_param->efi_memmap;
>  	range->size = ia64_boot_param->efi_memmap_size;
>  	return 0;
>  }
>  
> -int machine_kexec_get(xen_kexec_range_t *range)
> +int machine_kexec_get(xen_kexec64_range_t *range)
>  {
>  	switch (range->range) {
>  	case KEXEC_RANGE_MA_XEN:
> diff -r e56500f95b6a -r f571dc8e4368 xen/arch/x86/machine_kexec.c
> --- a/xen/arch/x86/machine_kexec.c
> +++ b/xen/arch/x86/machine_kexec.c
> @@ -120,7 +120,7 @@ void machine_kexec(xen_kexec_image_t *im
>      }
>  }
>  
> -int machine_kexec_get(xen_kexec_range_t *range)
> +int machine_kexec_get(xen_kexec64_range_t *range)
>  {
>  	if (range->range != KEXEC_RANGE_MA_XEN)
>  		return -EINVAL;
> diff -r e56500f95b6a -r f571dc8e4368 xen/arch/x86/x86_32/machine_kexec.c
> --- a/xen/arch/x86/x86_32/machine_kexec.c
> +++ b/xen/arch/x86/x86_32/machine_kexec.c
> @@ -11,11 +11,11 @@
>  #include <asm/page.h>
>  #include <public/kexec.h>
>  
> -int machine_kexec_get_xen(xen_kexec_range_t *range)
> +int machine_kexec_get_xen(xen_kexec64_range_t *range)
>  {
>          range->start = virt_to_maddr(_start);
> -        range->size = (unsigned long)xenheap_phys_end -
> -                      (unsigned long)range->start;
> +        range->size = (uint64_t)xenheap_phys_end -
> +                      (uint64_t)range->start;
>          return 0;
>  }
>  
> diff -r e56500f95b6a -r f571dc8e4368 xen/arch/x86/x86_64/machine_kexec.c
> --- a/xen/arch/x86/x86_64/machine_kexec.c
> +++ b/xen/arch/x86/x86_64/machine_kexec.c
> @@ -11,10 +11,10 @@
>  #include <asm/page.h>
>  #include <public/kexec.h>
>  
> -int machine_kexec_get_xen(xen_kexec_range_t *range)
> +int machine_kexec_get_xen(xen_kexec64_range_t *range)
>  {
>          range->start = virt_to_maddr(_start);
> -        range->size = virt_to_maddr(_end) - (unsigned long)range->start;
> +        range->size = virt_to_maddr(_end) - (uint64_t)range->start;
>          return 0;
>  }
>  
> diff -r e56500f95b6a -r f571dc8e4368 xen/common/kexec.c
> --- a/xen/common/kexec.c
> +++ b/xen/common/kexec.c
> @@ -56,6 +56,14 @@ static struct {
>      unsigned long size;
>  } ranges[16] __initdata;
>  
> +/* This XLAT macro is required now even without CONFIG_COMPAT. */
> +#define TRANSLATE_kexec_range(_d_, _s_) do { \
> +    (_d_)->range = (_s_)->range; \
> +    (_d_)->nr = (_s_)->nr; \
> +    (_d_)->size = (_s_)->size; \
> +    (_d_)->start = (_s_)->start; \
> +} while (0)
> +
>  /*
>   * Parse command lines in the format
>   *
> @@ -280,7 +288,7 @@ static int sizeof_note(const char *name,
>              ELFNOTE_ALIGN(descsz));
>  }
>  
> -static int kexec_get_reserve(xen_kexec_range_t *range)
> +static int kexec_get_reserve(xen_kexec64_range_t *range)
>  {
>      if ( kexec_crash_area.size > 0 && kexec_crash_area.start > 0) {
>          range->start = kexec_crash_area.start;
> @@ -291,7 +299,7 @@ static int kexec_get_reserve(xen_kexec_r
>      return 0;
>  }
>  
> -static int kexec_get_cpu(xen_kexec_range_t *range)
> +static int kexec_get_cpu(xen_kexec64_range_t *range)
>  {
>      int nr = range->nr;
>      int nr_bytes = 0;
> @@ -335,14 +343,14 @@ static int kexec_get_cpu(xen_kexec_range
>      return 0;
>  }
>  
> -static int kexec_get_vmcoreinfo(xen_kexec_range_t *range)
> +static int kexec_get_vmcoreinfo(xen_kexec64_range_t *range)
>  {
>      range->start = __pa((unsigned long)vmcoreinfo_data);
>      range->size = VMCOREINFO_BYTES;
>      return 0;
>  }
>  
> -static int kexec_get_range_internal(xen_kexec_range_t *range)
> +static int kexec_get_range_internal(xen_kexec64_range_t *range)
>  {
>      int ret = -EINVAL;
>  
> @@ -365,9 +373,14 @@ static int kexec_get_range_internal(xen_
>      return ret;
>  }
>  
> -static int kexec_get_range(XEN_GUEST_HANDLE(void) uarg)
> +/* This function can be invoked from either a KEXEC_CMD_kexec64_get_range
> + * hypercall, or from a KEXEC_CMD_kexec_get_range hypercall with 64bit dom0
> + * on 64bit Xen.  In the first case, the guest structure is a 
> + * xen_kexec64_range_t, and in the second case, the xen_kexec_range_t guest
> + * structure is identical to xen_kexec64_range_t. */
> +static int kexec_get_range64(XEN_GUEST_HANDLE(void) uarg)
>  {
> -    xen_kexec_range_t range;
> +    xen_kexec64_range_t range;
>      int ret = -EINVAL;
>  
>      if ( unlikely(copy_from_guest(&range, uarg, 1)) )
> @@ -381,34 +394,40 @@ static int kexec_get_range(XEN_GUEST_HAN
>      return ret;
>  }
>  
> -static int kexec_get_range_compat(XEN_GUEST_HANDLE(void) uarg)
> +/* This function can be invoked from either a KEXEC_CMD_kexec_get_range
> + * compat hypercall for 32bit dom0 on 64bit Xen, or from the same hypercall
> + * on 32bit Xen.  In both cases, the guest argument uses 32bit integers, so 
> 
> + * translate them to 64bit for use by kexec_get_range_internal.  The
> + * preprocessor guards are to choose the correct 32bit structure, as the
> + * compat_* structures dont exist in 32bit Xen. */
> +static int kexec_get_range32(XEN_GUEST_HANDLE(void) uarg)
>  {
> +    xen_kexec64_range_t range64;
>  #ifdef CONFIG_COMPAT
> -    xen_kexec_range_t range;
> -    compat_kexec_range_t compat_range;
> +    compat_kexec_range_t range32;
> +#else
> +    xen_kexec_range_t range32;
> +#endif
>      int ret = -EINVAL;
>  
> -    if ( unlikely(copy_from_guest(&compat_range, uarg, 1)) )
> +    if ( unlikely(copy_from_guest(&range32, uarg, 1)) )
>          return -EFAULT;
>  
> -    XLAT_kexec_range(&range, &compat_range);
> +    TRANSLATE_kexec_range(&range64, &range32);
>  
> -    ret = kexec_get_range_internal(&range);
> +    ret = kexec_get_range_internal(&range64);
>  
>      /* Dont silently truncate physical addresses or sizes. */
> -    if ( (range.start | range.size) & ~(unsigned long)(~0u) )
> +    if ( (range64.start | range64.size) & 0xffffffff00000000ULL )
>          return -ERANGE;
>  
>      if ( ret == 0 ) {
> -        XLAT_kexec_range(&compat_range, &range);
> -        if ( unlikely(copy_to_guest(uarg, &compat_range, 1)) )
> +        TRANSLATE_kexec_range(&range32, &range64);
> +        if ( unlikely(copy_to_guest(uarg, &range32, 1)) )
>               return -EFAULT;
>      }
>  
>      return ret;
> -#else /* CONFIG_COMPAT */
> -    return 0;
> -#endif /* CONFIG_COMPAT */
>  }
>  
>  static int kexec_load_get_bits(int type, int *base, int *bit)
> @@ -543,10 +562,10 @@ static int kexec_load_unload(unsigned lo
>      return kexec_load_unload_internal(op, &load);
>  }
>  
> +#ifdef CONFIG_COMPAT
>  static int kexec_load_unload_compat(unsigned long op,
>                                      XEN_GUEST_HANDLE(void) uarg)
>  {
> -#ifdef CONFIG_COMPAT
>      compat_kexec_load_t compat_load;
>      xen_kexec_load_t load;
>  
> @@ -564,10 +583,8 @@ static int kexec_load_unload_compat(unsi
>      XLAT_kexec_image(&load.image, &compat_load.image);
>  
>      return kexec_load_unload_internal(op, &load);
> -#else /* CONFIG_COMPAT */
> -    return 0;
> +}
>  #endif /* CONFIG_COMPAT */
> -}
>  
>  static int kexec_exec(XEN_GUEST_HANDLE(void) uarg)
>  {
> @@ -601,8 +618,51 @@ static int kexec_exec(XEN_GUEST_HANDLE(v
>      return -EINVAL; /* never reached */
>  }
>  
> -int do_kexec_op_internal(unsigned long op, XEN_GUEST_HANDLE(void) uarg,
> -                           int compat)
> +long do_kexec_op(unsigned long op, XEN_GUEST_HANDLE(void) uarg)
> +{
> +    unsigned long flags;
> +    int ret = -EINVAL;
> +
> +    if ( !IS_PRIV(current->domain) )
> +        return -EPERM;
> +
> +    ret = xsm_kexec();
> +    if ( ret )
> +        return ret;
> +
> +    switch ( op )
> +    {
> +#ifdef __i386__
> +    case KEXEC_CMD_kexec_get_range:
> +        ret = kexec_get_range32(uarg);
> +        break;
> +#else
> +    case KEXEC_CMD_kexec_get_range:
> +#endif
> +    case KEXEC_CMD_kexec64_get_range:
> +        ret = kexec_get_range64(uarg);
> +        break;
> +
> +    case KEXEC_CMD_kexec_load:
> +    case KEXEC_CMD_kexec_unload:
> +        spin_lock_irqsave(&kexec_lock, flags);
> +        if (!test_bit(KEXEC_FLAG_IN_PROGRESS, &kexec_flags))
> +            ret = kexec_load_unload(op, uarg);
> +        else
> +            ret = -EBUSY;
> +        spin_unlock_irqrestore(&kexec_lock, flags);
> +        break;
> +
> +    case KEXEC_CMD_kexec:
> +        ret = kexec_exec(uarg);
> +        break;
> +    }
> +
> +    return ret;
> +}
> +
> +#ifdef CONFIG_COMPAT
> +int compat_kexec_op(unsigned long op, XEN_GUEST_HANDLE(void) uarg)
>  {
>      unsigned long flags;
>      int ret = -EINVAL;
> @@ -617,23 +677,21 @@ int do_kexec_op_internal(unsigned long o
>      switch ( op )
>      {
>      case KEXEC_CMD_kexec_get_range:
> -        if (compat)
> -                ret = kexec_get_range_compat(uarg);
> -        else
> -                ret = kexec_get_range(uarg);
> +        ret = kexec_get_range32(uarg);
> +        break;
> +    case KEXEC_CMD_kexec64_get_range:
> +        ret = kexec_get_range64(uarg);
>          break;
>      case KEXEC_CMD_kexec_load:
>      case KEXEC_CMD_kexec_unload:
>          spin_lock_irqsave(&kexec_lock, flags);
>          if (!test_bit(KEXEC_FLAG_IN_PROGRESS, &kexec_flags))
> -        {
> -                if (compat)
> -                        ret = kexec_load_unload_compat(op, uarg);
> -                else
> -                        ret = kexec_load_unload(op, uarg);
> -        }
> +            ret = kexec_load_unload_compat(op, uarg);
> +        else
> +            ret = -EBUSY;
>          spin_unlock_irqrestore(&kexec_lock, flags);
>          break;
> +
>      case KEXEC_CMD_kexec:
>          ret = kexec_exec(uarg);
>          break;
> @@ -641,17 +699,6 @@ int do_kexec_op_internal(unsigned long o
>  
>      return ret;
>  }
> -
> -long do_kexec_op(unsigned long op, XEN_GUEST_HANDLE(void) uarg)
> -{
> -    return do_kexec_op_internal(op, uarg, 0);
> -}
> -
> -#ifdef CONFIG_COMPAT
> -int compat_kexec_op(unsigned long op, XEN_GUEST_HANDLE(void) uarg)
> -{
> -    return do_kexec_op_internal(op, uarg, 1);
> -}
>  #endif
>  
>  /*
> diff -r e56500f95b6a -r f571dc8e4368 xen/include/public/kexec.h
> --- a/xen/include/public/kexec.h
> +++ b/xen/include/public/kexec.h
> @@ -155,6 +155,15 @@ typedef struct xen_kexec_range {
>      unsigned long start;
>  } xen_kexec_range_t;
>  
> +#define KEXEC_CMD_kexec64_get_range      4
> +/* xen_kexec_range_t using explicit sizes for fields. */
> +typedef struct xen_kexec64_range {
> +    int32_t range;
> +    int32_t nr;
> +    uint64_t size;
> +    uint64_t start;
> +} xen_kexec64_range_t;
> +
>  #endif /* _XEN_PUBLIC_KEXEC_H */
>  
>  /*
> diff -r e56500f95b6a -r f571dc8e4368 xen/include/xen/kexec.h
> --- a/xen/include/xen/kexec.h
> +++ b/xen/include/xen/kexec.h
> @@ -34,8 +34,8 @@ void kexec_crash(void);
>  void kexec_crash_save_cpu(void);
>  crash_xen_info_t *kexec_crash_save_info(void);
>  void machine_crash_shutdown(void);
> -int machine_kexec_get(xen_kexec_range_t *range);
> -int machine_kexec_get_xen(xen_kexec_range_t *range);
> +int machine_kexec_get(xen_kexec64_range_t *range);
> +int machine_kexec_get_xen(xen_kexec64_range_t *range);
>  
>  void compat_machine_kexec(unsigned long rnk,
>                            unsigned long indirection_page,
> diff -r e56500f95b6a -r f571dc8e4368 xen/include/xlat.lst
> --- a/xen/include/xlat.lst
> +++ b/xen/include/xlat.lst
> @@ -50,9 +50,7 @@
>  ?	grant_entry_v1			grant_table.h
>  ?       grant_entry_header              grant_table.h
>  ?	grant_entry_v2			grant_table.h
> -?	kexec_exec			kexec.h
>  !	kexec_image			kexec.h
> -!	kexec_range			kexec.h
>  !	add_to_physmap			memory.h
>  !	foreign_memory_map		memory.h
>  !	memory_exchange			memory.h
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com 
> http://lists.xensource.com/xen-devel 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 23 08:39:48 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 Dec 2011 08:39:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Re0f4-0003vo-EF; Fri, 23 Dec 2011 08:39:30 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1Re0f2-0003vY-Pf
	for xen-devel@lists.xensource.com; Fri, 23 Dec 2011 08:39:29 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1324629560!6639833!1
X-Originating-IP: [209.85.160.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9210 invoked from network); 23 Dec 2011 08:39:22 -0000
Received: from mail-pw0-f43.google.com (HELO mail-pw0-f43.google.com)
	(209.85.160.43)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Dec 2011 08:39:22 -0000
Received: by pbbb11 with SMTP id b11so31315964pbb.30
	for <xen-devel@lists.xensource.com>;
	Fri, 23 Dec 2011 00:39:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=m0FshM/cXpwdwNdp9tVdnX++UdwprEXa0K6+I7xrRaY=;
	b=lg0Z99Oi19s6c/TIurixGafaYZ6Xy5AnDgIoJg9vBcnFITu0WmXMHIRLLKIX9H4eET
	LeoJRCn7AqXgny2UwnAMDBV4tsi4RZEexM6BZbydYnrGMuzLPY4Blns2NSa4MmXMZeTq
	Wyagv1nxJe5xWWP9NBNj/lpwm545hynwOHYl0=
MIME-Version: 1.0
Received: by 10.68.189.196 with SMTP id gk4mr199076pbc.44.1324629559395; Fri,
	23 Dec 2011 00:39:19 -0800 (PST)
Received: by 10.142.47.17 with HTTP; Fri, 23 Dec 2011 00:39:19 -0800 (PST)
In-Reply-To: <4EF44A100200007800069B5A@nat28.tlf.novell.com>
References: <CAPLaKK506e57uCvSdkjCqkUs6AS6ty4Efa+Ekhrczu=OA+TCHw@mail.gmail.com>
	<4EF44A100200007800069B5A@nat28.tlf.novell.com>
Date: Fri, 23 Dec 2011 09:39:19 +0100
X-Google-Sender-Auth: ad7gSMUudcJhNinglu7nrtH-O0E
Message-ID: <CAPLaKK7+OOFvhD3zAyCpw=ye67NmVWUS-JMJty3LoNafSq5iyA@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Jan Beulich <JBeulich@suse.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Stubdom build problem in 4.1.2 but not in
	xen-unstable
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

MjAxMS8xMi8yMyBKYW4gQmV1bGljaCA8SkJldWxpY2hAc3VzZS5jb20+Ogo+Pj4+IE9uIDIyLjEy
LjExIGF0IDE4OjAzLCBSb2dlciBQYXUgTW9ubsOpPHJvZ2VyLnBhdUBlbnRlbC51cGMuZWR1PiB3
cm90ZToKPj4gSGVsbG8sCj4+Cj4+IEkndmUgZm91bmQgdGhlIGZvbGxvd2luZyBwcm9ibGVtIHdo
aWxlIGJ1aWxkaW5nIFhlbiA0LjEuMiBzdHViZG9tczoKPj4KPj4gZ2NjIC1EQ09ORklHX1FFTVUg
LW1uby1yZWQtem9uZSAtTzEgLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIKPj4gLWZuby1vcHRpbWl6
ZS1zaWJsaW5nLWNhbGxzIMKgLW02NCAtbW5vLXJlZC16b25lIC1mbm8tcmVvcmRlci1ibG9ja3MK
Pj4gLWZuby1hc3luY2hyb25vdXMtdW53aW5kLXRhYmxlcyAtbTY0IC1nIC1mbm8tc3RyaWN0LWFs
aWFzaW5nCj4+IC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90eXBlcyAtV25vLXVudXNl
ZC12YWx1ZQo+PiAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNlZC1idXQt
c2V0LXZhcmlhYmxlIMKgLW5vcGllCj4+IC1mbm8tc3RhY2stcHJvdGVjdG9yIC1mbm8tZXhjZXB0
aW9ucyAtZm5vLWJ1aWx0aW4gLVdhbGwgLVdlcnJvcgo+PiAtV3JlZHVuZGFudC1kZWNscyAtV25v
LWZvcm1hdCAtV25vLXJlZHVuZGFudC1kZWNscwo+PiAtZm5vLXN0YWNrLXByb3RlY3RvciAtZmdu
dTg5LWlubGluZSAtV3N0cmljdC1wcm90b3R5cGVzCj4+IC1XbmVzdGVkLWV4dGVybnMgLVdwb2lu
dGVyLWFyaXRoIC1XaW5saW5lIC1nIC1ER05UX0RFQlVHCj4+IC1ER05UTUFQX0RFQlVHIC1EX19J
TlNJREVfTUlOSU9TX18gLW02NCAtbW5vLXJlZC16b25lCj4+IC1mbm8tcmVvcmRlci1ibG9ja3Mg
LWZuby1hc3luY2hyb25vdXMtdW53aW5kLXRhYmxlcyAtT3MKPj4gLWZvbWl0LWZyYW1lLXBvaW50
ZXIgLWlzeXN0ZW0KPj4gL2hvbWUvcm95Z2VyL2Fwb3J0cy90ZXN0aW5nL3hlbi9zcmMveGVuLTQu
MS4yL3N0dWJkb20vLi4vZXh0cmFzL21pbmktb3MvaW5jbHVkCj4+IGUKPj4gLURfX01JTklPU19f
IC1ESEFWRV9MSUJDIC1pc3lzdGVtCj4+IC9ob21lL3JveWdlci9hcG9ydHMvdGVzdGluZy94ZW4v
c3JjL3hlbi00LjEuMi9zdHViZG9tLy4uL2V4dHJhcy9taW5pLW9zL2luY2x1ZAo+PiBlL3Bvc2l4
Cj4+IC1pc3lzdGVtCj4+IC9ob21lL3JveWdlci9hcG9ydHMvdGVzdGluZy94ZW4vc3JjL3hlbi00
LjEuMi9zdHViZG9tLy4uL3Rvb2xzL3hlbnN0b3JlCj4+IMKgLWlzeXN0ZW0KPj4gL2hvbWUvcm95
Z2VyL2Fwb3J0cy90ZXN0aW5nL3hlbi9zcmMveGVuLTQuMS4yL3N0dWJkb20vLi4vZXh0cmFzL21p
bmktb3MvaW5jCj4+IGx1ZGUveDg2Cj4+IC1pc3lzdGVtCj4+IC9ob21lL3JveWdlci9hcG9ydHMv
dGVzdGluZy94ZW4vc3JjL3hlbi00LjEuMi9zdHViZG9tLy4uL2V4dHJhcy9taW5pLW9zL2luYwo+
PiBsdWRlL3g4Ni94ODZfNjQKPj4gLVUgX19saW51eF9fIC1VIF9fRnJlZUJTRF9fIC1VIF9fc3Vu
X18gLW5vc3RkaW5jIC1pc3lzdGVtCj4+IC9ob21lL3JveWdlci9hcG9ydHMvdGVzdGluZy94ZW4v
c3JjL3hlbi00LjEuMi9zdHViZG9tLy4uL2V4dHJhcy9taW5pLW9zL2luY2x1ZAo+PiBlL3Bvc2l4
Cj4+IC1pc3lzdGVtCj4+IC9ob21lL3JveWdlci9hcG9ydHMvdGVzdGluZy94ZW4vc3JjL3hlbi00
LjEuMi9zdHViZG9tL2Nyb3NzLXJvb3QteDg2XzY0L3g4Cj4+IDZfNjQteGVuLWVsZi9pbmNsdWRl
Cj4+IC1pc3lzdGVtIC91c3IvbGliL2djYy94ODZfNjQtYWxwaW5lLWxpbnV4LXVjbGliYy80LjYu
Mi9pbmNsdWRlCj4+IC1pc3lzdGVtCj4+IC9ob21lL3JveWdlci9hcG9ydHMvdGVzdGluZy94ZW4v
c3JjL3hlbi00LjEuMi9zdHViZG9tL2x3aXAteDg2XzY0L3NyYy9pbmNsdQo+PiBkZQo+PiAtaXN5
c3RlbQo+PiAvaG9tZS9yb3lnZXIvYXBvcnRzL3Rlc3RpbmcveGVuL3NyYy94ZW4tNC4xLjIvc3R1
YmRvbS9sd2lwLXg4Nl82NC9zcmMvaW5jbHUKPj4gZGUvaXB2NAo+PiAtSS9ob21lL3JveWdlci9h
cG9ydHMvdGVzdGluZy94ZW4vc3JjL3hlbi00LjEuMi9zdHViZG9tL2luY2x1ZGUKPj4gLUkvaG9t
ZS9yb3lnZXIvYXBvcnRzL3Rlc3RpbmcveGVuL3NyYy94ZW4tNC4xLjIvc3R1YmRvbS8uLi94ZW4v
aW5jbHVkZQo+PiAtaXN5c3RlbQo+PiAvaG9tZS9yb3lnZXIvYXBvcnRzL3Rlc3RpbmcveGVuL3Ny
Yy94ZW4tNC4xLjIvZXh0cmFzL21pbmktb3MvLi4vLi4vZXh0cmFzL20KPj4gaW5pLW9zL2luY2x1
ZGUKPj4gLURfX01JTklPU19fIC1ESEFWRV9MSUJDIC1pc3lzdGVtCj4+IC9ob21lL3JveWdlci9h
cG9ydHMvdGVzdGluZy94ZW4vc3JjL3hlbi00LjEuMi9leHRyYXMvbWluaS1vcy8uLi8uLi9leHRy
YXMvbWluaS0KPj4gb3MvaW5jbHVkZS9wb3NpeAo+PiAtaXN5c3RlbQo+PiAvaG9tZS9yb3lnZXIv
YXBvcnRzL3Rlc3RpbmcveGVuL3NyYy94ZW4tNC4xLjIvZXh0cmFzL21pbmktb3MvLi4vLi4vdG9v
bHMveGUKPj4gbnN0b3JlCj4+IC1ESEFWRV9MV0lQIC1pc3lzdGVtCj4+IC9ob21lL3JveWdlci9h
cG9ydHMvdGVzdGluZy94ZW4vc3JjL3hlbi00LjEuMi9zdHViZG9tL2x3aXAteDg2XzY0L3NyYy9p
bmNsdWRlCj4+IC1pc3lzdGVtCj4+IC9ob21lL3JveWdlci9hcG9ydHMvdGVzdGluZy94ZW4vc3Jj
L3hlbi00LjEuMi9zdHViZG9tL2x3aXAteDg2XzY0L3NyYy9pbmNsdQo+PiBkZS9pcHY0Cj4+IC1E
X19YRU5fSU5URVJGQUNFX1ZFUlNJT05fXz0weDAwMDMwMjA1IMKgLWlzeXN0ZW0KPj4gL2hvbWUv
cm95Z2VyL2Fwb3J0cy90ZXN0aW5nL3hlbi9zcmMveGVuLTQuMS4yL2V4dHJhcy9taW5pLW9zLy4u
Ly4uL2V4dHJhcy9taW5pLQo+PiBvcy9pbmNsdWRlL3g4Ngo+PiAtaXN5c3RlbQo+PiAvaG9tZS9y
b3lnZXIvYXBvcnRzL3Rlc3RpbmcveGVuL3NyYy94ZW4tNC4xLjIvZXh0cmFzL21pbmktb3MvLi4v
Li4vZXh0cmFzL20KPj4gaW5pLW9zL2luY2x1ZGUveDg2L3g4Nl82NAo+PiAtYyBjb25zb2xlL3hl
bmNvbnNfcmluZy5jIC1vCj4+IC9ob21lL3JveWdlci9hcG9ydHMvdGVzdGluZy94ZW4vc3JjL3hl
bi00LjEuMi9zdHViZG9tL21pbmktb3MteDg2XzY0LWlvZW11L2NvbnNvCj4+IGxlL3hlbmNvbnNf
cmluZy5vCj4+IGNvbnNvbGUveGVuY29uc19yaW5nLmM6IEluIGZ1bmN0aW9uICd4ZW5jb25zX3Jp
bmdfc2VuZF9ub19ub3RpZnknOgo+PiBjb25zb2xlL3hlbmNvbnNfcmluZy5jOjI2OjQxOiBlcnJv
cjogaW5saW5pbmcgZmFpbGVkIGluIGNhbGwgdG8KPj4gJ3hlbmNvbnNfaW50ZXJmYWNlJzogY2Fs
bCBpcyB1bmxpa2VseSBhbmQgY29kZSBzaXplIHdvdWxkIGdyb3cKPj4gWy1XZXJyb3I9aW5saW5l
XQo+PiBjb25zb2xlL3hlbmNvbnNfcmluZy5jOjM4OjE4OiBlcnJvcjogY2FsbGVkIGZyb20gaGVy
ZSBbLVdlcnJvcj1pbmxpbmVdCj4+IGNjMTogYWxsIHdhcm5pbmdzIGJlaW5nIHRyZWF0ZWQgYXMg
ZXJyb3JzCj4+Cj4+IEFsdGhvdWdoIEkgY2FuIGJ1aWxkIHhlbi11bnN0YWJsZSB3aXRob3V0IGFu
eSBwcm9ibGVtcyBvbiB0aGUgc2FtZQo+PiBtYWNoaW5lLiBJJ3ZlIGJlZW4gdHJ5aW5nIHRvIGZp
bmQgdGhlIHBhdGNoIHRoYXQgc29sdmVkIHRoaXMgb24KPj4gdW5zdGFibGUsIGJ1dCBzbyBmYXIg
SSBoYXZlbid0IGZvdW5kIGl0LiBBbnlvbmUga25vdyB3aGljaCBwYXRjaCBmaXhlZAo+PiBpdD8g
SSB3b3VsZCBsaWtlIHRvIGhhdmUgaXQgYmFja3BvcnRlZCB0byB4ZW4tNC4xLgo+Cj4gSXQgbWF5
IHdlbGwgYmUgdGhhdCB0aGVyZSBpcyBubyBzdWNoIGNoYW5nZXNldCwgYnV0IHRoZSBjb21waWxl
ciBqdXN0Cj4gZGVjaWRlcyB0byBldmFsdWF0ZSB0aGUgbGlrZWxpaG9vZHMgZGlmZmVyZW50bHku
IEknbSBhc3N1bWluZyB0aGF0IHRoZQo+IGJ1aWxkIHByb2JsZW0gd291bGQgZ28gYXdheSBieSBy
ZW1vdmluZyAtV2lubGluZSBmcm9tCj4gZXh0cmFzL21pbmktb3MvbWluaW9zLm1rOkRFRl9DRkxB
R1MgKHdoaWNoIGlzIHF1ZXN0aW9uYWJsZSBpbgo+IGNvbmp1bmN0aW9uIHdpdGggdGhlIC1XZXJy
b3IgZm9yY2VkIHRoZXJlIHRvbyAtIGEgbW9yZSByZWFzb25hYmx5Cj4gYXBwcm9hY2ggd291bGQg
c2VlbSB0byBiZSAtV2lubGluZSAtV25vLWVycm9yPWlubGluZSwgYXBwYXJlbnRseQo+IGF2YWls
YWJsZSBzaW5jZSBnY2MgNC4yLngpLgoKSSd2ZSBlbmRlZCB1cCByZW1vdmluZyAtV2Vycm9yIGZy
b20gYWxsIHRoZSBNYWtlZmlsZXM6CgpmaW5kIC1uYW1lICcqLm1rJyAtbyAtbmFtZSAnTWFrZSon
IHwgeGFyZ3Mgc2VkIC1pIC1lICdzLy1XZXJyb3IvL2cnCgpOb3QgdGhlIHByZXR0aWVzdCBzb2x1
dGlvbiBidXQgaXQgd29ya3MuLi4KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbnNv
dXJjZS5jb20KaHR0cDovL2xpc3RzLnhlbnNvdXJjZS5jb20veGVuLWRldmVsCg==

From xen-devel-bounces@lists.xensource.com Fri Dec 23 08:39:48 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 Dec 2011 08:39:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Re0f4-0003vo-EF; Fri, 23 Dec 2011 08:39:30 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1Re0f2-0003vY-Pf
	for xen-devel@lists.xensource.com; Fri, 23 Dec 2011 08:39:29 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1324629560!6639833!1
X-Originating-IP: [209.85.160.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9210 invoked from network); 23 Dec 2011 08:39:22 -0000
Received: from mail-pw0-f43.google.com (HELO mail-pw0-f43.google.com)
	(209.85.160.43)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Dec 2011 08:39:22 -0000
Received: by pbbb11 with SMTP id b11so31315964pbb.30
	for <xen-devel@lists.xensource.com>;
	Fri, 23 Dec 2011 00:39:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=m0FshM/cXpwdwNdp9tVdnX++UdwprEXa0K6+I7xrRaY=;
	b=lg0Z99Oi19s6c/TIurixGafaYZ6Xy5AnDgIoJg9vBcnFITu0WmXMHIRLLKIX9H4eET
	LeoJRCn7AqXgny2UwnAMDBV4tsi4RZEexM6BZbydYnrGMuzLPY4Blns2NSa4MmXMZeTq
	Wyagv1nxJe5xWWP9NBNj/lpwm545hynwOHYl0=
MIME-Version: 1.0
Received: by 10.68.189.196 with SMTP id gk4mr199076pbc.44.1324629559395; Fri,
	23 Dec 2011 00:39:19 -0800 (PST)
Received: by 10.142.47.17 with HTTP; Fri, 23 Dec 2011 00:39:19 -0800 (PST)
In-Reply-To: <4EF44A100200007800069B5A@nat28.tlf.novell.com>
References: <CAPLaKK506e57uCvSdkjCqkUs6AS6ty4Efa+Ekhrczu=OA+TCHw@mail.gmail.com>
	<4EF44A100200007800069B5A@nat28.tlf.novell.com>
Date: Fri, 23 Dec 2011 09:39:19 +0100
X-Google-Sender-Auth: ad7gSMUudcJhNinglu7nrtH-O0E
Message-ID: <CAPLaKK7+OOFvhD3zAyCpw=ye67NmVWUS-JMJty3LoNafSq5iyA@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Jan Beulich <JBeulich@suse.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Stubdom build problem in 4.1.2 but not in
	xen-unstable
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

MjAxMS8xMi8yMyBKYW4gQmV1bGljaCA8SkJldWxpY2hAc3VzZS5jb20+Ogo+Pj4+IE9uIDIyLjEy
LjExIGF0IDE4OjAzLCBSb2dlciBQYXUgTW9ubsOpPHJvZ2VyLnBhdUBlbnRlbC51cGMuZWR1PiB3
cm90ZToKPj4gSGVsbG8sCj4+Cj4+IEkndmUgZm91bmQgdGhlIGZvbGxvd2luZyBwcm9ibGVtIHdo
aWxlIGJ1aWxkaW5nIFhlbiA0LjEuMiBzdHViZG9tczoKPj4KPj4gZ2NjIC1EQ09ORklHX1FFTVUg
LW1uby1yZWQtem9uZSAtTzEgLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIKPj4gLWZuby1vcHRpbWl6
ZS1zaWJsaW5nLWNhbGxzIMKgLW02NCAtbW5vLXJlZC16b25lIC1mbm8tcmVvcmRlci1ibG9ja3MK
Pj4gLWZuby1hc3luY2hyb25vdXMtdW53aW5kLXRhYmxlcyAtbTY0IC1nIC1mbm8tc3RyaWN0LWFs
aWFzaW5nCj4+IC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90eXBlcyAtV25vLXVudXNl
ZC12YWx1ZQo+PiAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNlZC1idXQt
c2V0LXZhcmlhYmxlIMKgLW5vcGllCj4+IC1mbm8tc3RhY2stcHJvdGVjdG9yIC1mbm8tZXhjZXB0
aW9ucyAtZm5vLWJ1aWx0aW4gLVdhbGwgLVdlcnJvcgo+PiAtV3JlZHVuZGFudC1kZWNscyAtV25v
LWZvcm1hdCAtV25vLXJlZHVuZGFudC1kZWNscwo+PiAtZm5vLXN0YWNrLXByb3RlY3RvciAtZmdu
dTg5LWlubGluZSAtV3N0cmljdC1wcm90b3R5cGVzCj4+IC1XbmVzdGVkLWV4dGVybnMgLVdwb2lu
dGVyLWFyaXRoIC1XaW5saW5lIC1nIC1ER05UX0RFQlVHCj4+IC1ER05UTUFQX0RFQlVHIC1EX19J
TlNJREVfTUlOSU9TX18gLW02NCAtbW5vLXJlZC16b25lCj4+IC1mbm8tcmVvcmRlci1ibG9ja3Mg
LWZuby1hc3luY2hyb25vdXMtdW53aW5kLXRhYmxlcyAtT3MKPj4gLWZvbWl0LWZyYW1lLXBvaW50
ZXIgLWlzeXN0ZW0KPj4gL2hvbWUvcm95Z2VyL2Fwb3J0cy90ZXN0aW5nL3hlbi9zcmMveGVuLTQu
MS4yL3N0dWJkb20vLi4vZXh0cmFzL21pbmktb3MvaW5jbHVkCj4+IGUKPj4gLURfX01JTklPU19f
IC1ESEFWRV9MSUJDIC1pc3lzdGVtCj4+IC9ob21lL3JveWdlci9hcG9ydHMvdGVzdGluZy94ZW4v
c3JjL3hlbi00LjEuMi9zdHViZG9tLy4uL2V4dHJhcy9taW5pLW9zL2luY2x1ZAo+PiBlL3Bvc2l4
Cj4+IC1pc3lzdGVtCj4+IC9ob21lL3JveWdlci9hcG9ydHMvdGVzdGluZy94ZW4vc3JjL3hlbi00
LjEuMi9zdHViZG9tLy4uL3Rvb2xzL3hlbnN0b3JlCj4+IMKgLWlzeXN0ZW0KPj4gL2hvbWUvcm95
Z2VyL2Fwb3J0cy90ZXN0aW5nL3hlbi9zcmMveGVuLTQuMS4yL3N0dWJkb20vLi4vZXh0cmFzL21p
bmktb3MvaW5jCj4+IGx1ZGUveDg2Cj4+IC1pc3lzdGVtCj4+IC9ob21lL3JveWdlci9hcG9ydHMv
dGVzdGluZy94ZW4vc3JjL3hlbi00LjEuMi9zdHViZG9tLy4uL2V4dHJhcy9taW5pLW9zL2luYwo+
PiBsdWRlL3g4Ni94ODZfNjQKPj4gLVUgX19saW51eF9fIC1VIF9fRnJlZUJTRF9fIC1VIF9fc3Vu
X18gLW5vc3RkaW5jIC1pc3lzdGVtCj4+IC9ob21lL3JveWdlci9hcG9ydHMvdGVzdGluZy94ZW4v
c3JjL3hlbi00LjEuMi9zdHViZG9tLy4uL2V4dHJhcy9taW5pLW9zL2luY2x1ZAo+PiBlL3Bvc2l4
Cj4+IC1pc3lzdGVtCj4+IC9ob21lL3JveWdlci9hcG9ydHMvdGVzdGluZy94ZW4vc3JjL3hlbi00
LjEuMi9zdHViZG9tL2Nyb3NzLXJvb3QteDg2XzY0L3g4Cj4+IDZfNjQteGVuLWVsZi9pbmNsdWRl
Cj4+IC1pc3lzdGVtIC91c3IvbGliL2djYy94ODZfNjQtYWxwaW5lLWxpbnV4LXVjbGliYy80LjYu
Mi9pbmNsdWRlCj4+IC1pc3lzdGVtCj4+IC9ob21lL3JveWdlci9hcG9ydHMvdGVzdGluZy94ZW4v
c3JjL3hlbi00LjEuMi9zdHViZG9tL2x3aXAteDg2XzY0L3NyYy9pbmNsdQo+PiBkZQo+PiAtaXN5
c3RlbQo+PiAvaG9tZS9yb3lnZXIvYXBvcnRzL3Rlc3RpbmcveGVuL3NyYy94ZW4tNC4xLjIvc3R1
YmRvbS9sd2lwLXg4Nl82NC9zcmMvaW5jbHUKPj4gZGUvaXB2NAo+PiAtSS9ob21lL3JveWdlci9h
cG9ydHMvdGVzdGluZy94ZW4vc3JjL3hlbi00LjEuMi9zdHViZG9tL2luY2x1ZGUKPj4gLUkvaG9t
ZS9yb3lnZXIvYXBvcnRzL3Rlc3RpbmcveGVuL3NyYy94ZW4tNC4xLjIvc3R1YmRvbS8uLi94ZW4v
aW5jbHVkZQo+PiAtaXN5c3RlbQo+PiAvaG9tZS9yb3lnZXIvYXBvcnRzL3Rlc3RpbmcveGVuL3Ny
Yy94ZW4tNC4xLjIvZXh0cmFzL21pbmktb3MvLi4vLi4vZXh0cmFzL20KPj4gaW5pLW9zL2luY2x1
ZGUKPj4gLURfX01JTklPU19fIC1ESEFWRV9MSUJDIC1pc3lzdGVtCj4+IC9ob21lL3JveWdlci9h
cG9ydHMvdGVzdGluZy94ZW4vc3JjL3hlbi00LjEuMi9leHRyYXMvbWluaS1vcy8uLi8uLi9leHRy
YXMvbWluaS0KPj4gb3MvaW5jbHVkZS9wb3NpeAo+PiAtaXN5c3RlbQo+PiAvaG9tZS9yb3lnZXIv
YXBvcnRzL3Rlc3RpbmcveGVuL3NyYy94ZW4tNC4xLjIvZXh0cmFzL21pbmktb3MvLi4vLi4vdG9v
bHMveGUKPj4gbnN0b3JlCj4+IC1ESEFWRV9MV0lQIC1pc3lzdGVtCj4+IC9ob21lL3JveWdlci9h
cG9ydHMvdGVzdGluZy94ZW4vc3JjL3hlbi00LjEuMi9zdHViZG9tL2x3aXAteDg2XzY0L3NyYy9p
bmNsdWRlCj4+IC1pc3lzdGVtCj4+IC9ob21lL3JveWdlci9hcG9ydHMvdGVzdGluZy94ZW4vc3Jj
L3hlbi00LjEuMi9zdHViZG9tL2x3aXAteDg2XzY0L3NyYy9pbmNsdQo+PiBkZS9pcHY0Cj4+IC1E
X19YRU5fSU5URVJGQUNFX1ZFUlNJT05fXz0weDAwMDMwMjA1IMKgLWlzeXN0ZW0KPj4gL2hvbWUv
cm95Z2VyL2Fwb3J0cy90ZXN0aW5nL3hlbi9zcmMveGVuLTQuMS4yL2V4dHJhcy9taW5pLW9zLy4u
Ly4uL2V4dHJhcy9taW5pLQo+PiBvcy9pbmNsdWRlL3g4Ngo+PiAtaXN5c3RlbQo+PiAvaG9tZS9y
b3lnZXIvYXBvcnRzL3Rlc3RpbmcveGVuL3NyYy94ZW4tNC4xLjIvZXh0cmFzL21pbmktb3MvLi4v
Li4vZXh0cmFzL20KPj4gaW5pLW9zL2luY2x1ZGUveDg2L3g4Nl82NAo+PiAtYyBjb25zb2xlL3hl
bmNvbnNfcmluZy5jIC1vCj4+IC9ob21lL3JveWdlci9hcG9ydHMvdGVzdGluZy94ZW4vc3JjL3hl
bi00LjEuMi9zdHViZG9tL21pbmktb3MteDg2XzY0LWlvZW11L2NvbnNvCj4+IGxlL3hlbmNvbnNf
cmluZy5vCj4+IGNvbnNvbGUveGVuY29uc19yaW5nLmM6IEluIGZ1bmN0aW9uICd4ZW5jb25zX3Jp
bmdfc2VuZF9ub19ub3RpZnknOgo+PiBjb25zb2xlL3hlbmNvbnNfcmluZy5jOjI2OjQxOiBlcnJv
cjogaW5saW5pbmcgZmFpbGVkIGluIGNhbGwgdG8KPj4gJ3hlbmNvbnNfaW50ZXJmYWNlJzogY2Fs
bCBpcyB1bmxpa2VseSBhbmQgY29kZSBzaXplIHdvdWxkIGdyb3cKPj4gWy1XZXJyb3I9aW5saW5l
XQo+PiBjb25zb2xlL3hlbmNvbnNfcmluZy5jOjM4OjE4OiBlcnJvcjogY2FsbGVkIGZyb20gaGVy
ZSBbLVdlcnJvcj1pbmxpbmVdCj4+IGNjMTogYWxsIHdhcm5pbmdzIGJlaW5nIHRyZWF0ZWQgYXMg
ZXJyb3JzCj4+Cj4+IEFsdGhvdWdoIEkgY2FuIGJ1aWxkIHhlbi11bnN0YWJsZSB3aXRob3V0IGFu
eSBwcm9ibGVtcyBvbiB0aGUgc2FtZQo+PiBtYWNoaW5lLiBJJ3ZlIGJlZW4gdHJ5aW5nIHRvIGZp
bmQgdGhlIHBhdGNoIHRoYXQgc29sdmVkIHRoaXMgb24KPj4gdW5zdGFibGUsIGJ1dCBzbyBmYXIg
SSBoYXZlbid0IGZvdW5kIGl0LiBBbnlvbmUga25vdyB3aGljaCBwYXRjaCBmaXhlZAo+PiBpdD8g
SSB3b3VsZCBsaWtlIHRvIGhhdmUgaXQgYmFja3BvcnRlZCB0byB4ZW4tNC4xLgo+Cj4gSXQgbWF5
IHdlbGwgYmUgdGhhdCB0aGVyZSBpcyBubyBzdWNoIGNoYW5nZXNldCwgYnV0IHRoZSBjb21waWxl
ciBqdXN0Cj4gZGVjaWRlcyB0byBldmFsdWF0ZSB0aGUgbGlrZWxpaG9vZHMgZGlmZmVyZW50bHku
IEknbSBhc3N1bWluZyB0aGF0IHRoZQo+IGJ1aWxkIHByb2JsZW0gd291bGQgZ28gYXdheSBieSBy
ZW1vdmluZyAtV2lubGluZSBmcm9tCj4gZXh0cmFzL21pbmktb3MvbWluaW9zLm1rOkRFRl9DRkxB
R1MgKHdoaWNoIGlzIHF1ZXN0aW9uYWJsZSBpbgo+IGNvbmp1bmN0aW9uIHdpdGggdGhlIC1XZXJy
b3IgZm9yY2VkIHRoZXJlIHRvbyAtIGEgbW9yZSByZWFzb25hYmx5Cj4gYXBwcm9hY2ggd291bGQg
c2VlbSB0byBiZSAtV2lubGluZSAtV25vLWVycm9yPWlubGluZSwgYXBwYXJlbnRseQo+IGF2YWls
YWJsZSBzaW5jZSBnY2MgNC4yLngpLgoKSSd2ZSBlbmRlZCB1cCByZW1vdmluZyAtV2Vycm9yIGZy
b20gYWxsIHRoZSBNYWtlZmlsZXM6CgpmaW5kIC1uYW1lICcqLm1rJyAtbyAtbmFtZSAnTWFrZSon
IHwgeGFyZ3Mgc2VkIC1pIC1lICdzLy1XZXJyb3IvL2cnCgpOb3QgdGhlIHByZXR0aWVzdCBzb2x1
dGlvbiBidXQgaXQgd29ya3MuLi4KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbnNv
dXJjZS5jb20KaHR0cDovL2xpc3RzLnhlbnNvdXJjZS5jb20veGVuLWRldmVsCg==

From xen-devel-bounces@lists.xensource.com Fri Dec 23 08:41:01 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 Dec 2011 08:41:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Re0gG-00041S-2b; Fri, 23 Dec 2011 08:40:44 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1Re0gE-000414-Gq
	for xen-devel@lists.xensource.com; Fri, 23 Dec 2011 08:40:42 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1324629613!53307379!1
X-Originating-IP: [209.85.212.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15877 invoked from network); 23 Dec 2011 08:40:13 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Dec 2011 08:40:13 -0000
Received: by wico1 with SMTP id o1so7721106wic.30
	for <xen-devel@lists.xensource.com>;
	Fri, 23 Dec 2011 00:40:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=CdJMbTGl48VNRuI/bj5wtJDspkJIuMYLjventteolmg=;
	b=WAcH+tVUwOWXvYURjGOH7Me5LeMlIqH+4rzD9Wp1QznBd7kAeE/b/5ofugNV0VrSqg
	1wbyYMu2NTsXBAuRCOE1k91cG4eqhR+YZVoysWKUwFopIfegCpK86Sb37dlx5kthBXqt
	7Fe+4HWpIE47KtPZ03ePn/FAK8Ye+epU1hOr8=
Received: by 10.180.8.229 with SMTP id u5mr30300348wia.9.1324629638087;
	Fri, 23 Dec 2011 00:40:38 -0800 (PST)
Received: from [192.168.1.70] (host81-152-17-11.range81-152.btcentralplus.com.
	[81.152.17.11]) by mx.google.com with ESMTPS id
	en20sm29498564wid.10.2011.12.23.00.40.36
	(version=SSLv3 cipher=OTHER); Fri, 23 Dec 2011 00:40:37 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Fri, 23 Dec 2011 08:40:36 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Roger Pau =?ISO-8859-1?B?TW9ubuk=?= <roger.pau@entel.upc.edu>,
	Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <CB19EF04.27B93%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH v2] libxl: add support for yajl 2.x
Thread-Index: AczBTopf2NiduYZI60OfuhzUbdjcnw==
In-Reply-To: <CAPLaKK5uXfXH7swFia21zkbNjuM+8Dfnk3OehFCNwvgfKzwn2A@mail.gmail.com>
Mime-version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH v2] libxl: add support for yajl 2.x
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 23/12/2011 08:22, "Roger Pau Monn=E9" <roger.pau@entel.upc.edu> wrote:

> 2011/12/22 Ian Campbell <Ian.Campbell@citrix.com>:
>> I'm not going to have time in the near future.
> =

> I will try to take a look at the autogoo stuff and set something up.
> =

>> Would it be sufficient to have the stuff in tools/check create a
>> config.h as well as doing the checks? Might need a bit of Makefile magic
>> to be sure that check is always run?
> =

> Since we have to change things, I'm not sure if it is best to move to
> something more standard, like autotools.

We should probably just do autotools, if someone has the time to invest in
the initial implementation work to use it.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 23 08:41:01 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 Dec 2011 08:41:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Re0gG-00041S-2b; Fri, 23 Dec 2011 08:40:44 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1Re0gE-000414-Gq
	for xen-devel@lists.xensource.com; Fri, 23 Dec 2011 08:40:42 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1324629613!53307379!1
X-Originating-IP: [209.85.212.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15877 invoked from network); 23 Dec 2011 08:40:13 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Dec 2011 08:40:13 -0000
Received: by wico1 with SMTP id o1so7721106wic.30
	for <xen-devel@lists.xensource.com>;
	Fri, 23 Dec 2011 00:40:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=CdJMbTGl48VNRuI/bj5wtJDspkJIuMYLjventteolmg=;
	b=WAcH+tVUwOWXvYURjGOH7Me5LeMlIqH+4rzD9Wp1QznBd7kAeE/b/5ofugNV0VrSqg
	1wbyYMu2NTsXBAuRCOE1k91cG4eqhR+YZVoysWKUwFopIfegCpK86Sb37dlx5kthBXqt
	7Fe+4HWpIE47KtPZ03ePn/FAK8Ye+epU1hOr8=
Received: by 10.180.8.229 with SMTP id u5mr30300348wia.9.1324629638087;
	Fri, 23 Dec 2011 00:40:38 -0800 (PST)
Received: from [192.168.1.70] (host81-152-17-11.range81-152.btcentralplus.com.
	[81.152.17.11]) by mx.google.com with ESMTPS id
	en20sm29498564wid.10.2011.12.23.00.40.36
	(version=SSLv3 cipher=OTHER); Fri, 23 Dec 2011 00:40:37 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Fri, 23 Dec 2011 08:40:36 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Roger Pau =?ISO-8859-1?B?TW9ubuk=?= <roger.pau@entel.upc.edu>,
	Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <CB19EF04.27B93%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH v2] libxl: add support for yajl 2.x
Thread-Index: AczBTopf2NiduYZI60OfuhzUbdjcnw==
In-Reply-To: <CAPLaKK5uXfXH7swFia21zkbNjuM+8Dfnk3OehFCNwvgfKzwn2A@mail.gmail.com>
Mime-version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH v2] libxl: add support for yajl 2.x
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 23/12/2011 08:22, "Roger Pau Monn=E9" <roger.pau@entel.upc.edu> wrote:

> 2011/12/22 Ian Campbell <Ian.Campbell@citrix.com>:
>> I'm not going to have time in the near future.
> =

> I will try to take a look at the autogoo stuff and set something up.
> =

>> Would it be sufficient to have the stuff in tools/check create a
>> config.h as well as doing the checks? Might need a bit of Makefile magic
>> to be sure that check is always run?
> =

> Since we have to change things, I'm not sure if it is best to move to
> something more standard, like autotools.

We should probably just do autotools, if someone has the time to invest in
the initial implementation work to use it.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 23 08:41:48 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 Dec 2011 08: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.xensource.com>)
	id 1Re0h3-00046i-HQ; Fri, 23 Dec 2011 08:41:33 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Re0h2-000466-H7
	for xen-devel@lists.xensource.com; Fri, 23 Dec 2011 08:41:32 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1324629643!47853834!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18102 invoked from network); 23 Dec 2011 08:40:44 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-5.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 23 Dec 2011 08:40:44 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 23 Dec 2011 08:41:25 +0000
Message-Id: <4EF44CFC0200007800069B6F@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 23 Dec 2011 08:42:20 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>
References: <patchbomb.1324575382@andrewcoop.uk.xensource.com>
	<3da37c68284f9fcf5f74.1324575384@andrewcoop.uk.xensource.com>
In-Reply-To: <3da37c68284f9fcf5f74.1324575384@andrewcoop.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 2 of 3] KEXEC: Allocate crash notes on boot
 v6
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 22.12.11 at 18:36, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
> Currently, the buffers for crash notes are allocated per CPU when a
> KEXEC_CMD_kexec_get_range hypercall is made, referencing the CPU in
> question.
> 
> Although it certainly works in general, there are a few edge case problems:
> 
> 1) There appears to be no guarentee that dom0 will make this hypercall
>    for each pcpu on the system.  There appears to be variable
>    behaviour depending on how many cpus dom0 is compiled for, and how
>    many vcpus Xen gives to dom0.
> 
> 2) The allocation of these buffers occur at the whim of dom0.  While
>    this is typically very early on dom0 boot, but not guarenteed.
> 
> 3) It is possible (although not sensible) for a crash
>    kernel to be loaded without these (or some of these) hypercalls
>    being made. Under these circumstances, a crash would cause the
>    crash note code path will suffer a slew of null pointer deferences.
> 
> 4) If the hypercalls are made after late in the day, it is possible
>    for the hypercall to return -ENOMEM.  As code tends to be more
>    fragile once memory is enhausted, the likelyhood of us needing the
>    crash kernel is greater.

Also for the record, I continue to believe that none of these warrant
the changes made here. Better error/NULL checking may instead be
required in a few places, plus possibly some Dom0 code adjustments
(see my recent 2.6.18 kernel changes, on top of which pCPU hot add
support was implemented [which can't go into the 2.6.18 kernel as it
lacks general pCPU hot add code]).

> In addition, my forthcoming code to support 32bit kdump kernels on
> 64bit Xen on large (>64GB) boxes will require some guarentees as to
> where the crash note buffers are actually allocated in physical
> memory.  This is far easier to sort out at boot time, rather than
> after dom0 has been booted and potentially using the physical memory
> required.

This one is the only part of the rationale for these changes that I
view as half way reasonable, though with allocation in Xen going
from top down, not being able to allocate these is about the same
as e.g. Dom0 not being able to set up its swiotlb. That's what the
(by default) 128M reservation is for. So if anything, the number
there may want some tweaking for the case of very many CPUs.

Jan

> Therefore, allocate the crash note buffers at boot time.
> 
> Changes since v5:
>  *  Introduce sizeof_cpu_notes to move calculation of note size into a
>     separate location.
>  *  Tweak sizeof_note() to return size_t rather than int, as it is a
>     function based upon sizeof().
> 
> Changes since v4:
> 
>  *  Replace the current cpu crash note scheme of using void pointers
>     and hand calculating the size each time is needed, by a range
>     structure containing a pointer and a size.  This removes duplicate
>     times where the size is calculated.
>  *  Tweak kexec_get_cpu().  Don't fail if a cpu is offline because it
>     may already have crash notes, and may be up by the time a crash
>     happens.  Split the error conditions up to return ERANGE for an
>     out-of-range cpu request rather than EINVAL.  Finally, returning a
>     range of zeros is acceptable, so do this in preference to failing.
> 
> Changes since v3:
> 
>  *  Alter the spinlocks to avoid calling xmalloc/xfree while holding
>     the lock.
>  *  Tidy up the coding style used.
> 
> Changes since v2:
> 
>  *  Allocate crash_notes dynamically using nr_cpu_ids at boot time,
>     rather than statically using NR_CPUS.
>  *  Fix the incorrect use of signed integers for cpu id.
>  *  Fix collateral damage to do_crashdump_trigger() and
>     crashdump_trigger_handler caused by reordering sizeof_note() and
>     setup_note()
>  *  Tweak the issue about returing -ENOMEM from kexec_init_cpu_note().
>     No functional change.
>  *  Change kexec_get_cpu() to attempt to allocate crash note buffers
>     in case we have more free memory now than when the pcpu came up.
>  *  Now that there are two codepaths possibly allocating crash notes,
>     protect the allocation itself with a spinlock.
> 
> Changes since v1:
> 
>  *  Use cpu hotplug notifiers to handle allocating of the notes
>     buffers rather than assuming the boot state of cpus will be the
>     same as the crash state.
>  *  Move crash_notes from being per_cpu.  This is because the kdump
>     kernel elf binary put in the crash area is hard coded to physical
>     addresses which the dom0 kernel typically obtains at boot time.
>     If a cpu is offlined, its buffer should not be deallocated because
>     the kdump kernel would read junk when trying to get the crash
>     notes.  Similarly, the same problem would occur if the cpu was
>     re-onlined later and its crash notes buffer was allocated elsewhere.
>  *  Only attempt to allocate buffers if a crash area has been
>     specified.  Else, allocating crash note buffers is a waste of
>     space.  Along with this, change the test in kexec_get_cpu to
>     return -EINVAL if no buffers have been allocated.
> 
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
> 
> diff -r f571dc8e4368 -r 3da37c68284f xen/common/kexec.c
> --- a/xen/common/kexec.c
> +++ b/xen/common/kexec.c
> @@ -25,13 +25,19 @@
>  #include <xen/kexec.h>
>  #include <public/elfnote.h>
>  #include <xsm/xsm.h>
> +#include <xen/cpu.h>
>  #ifdef CONFIG_COMPAT
>  #include <compat/kexec.h>
>  #endif
>  
>  bool_t kexecing = FALSE;
>  
> -static DEFINE_PER_CPU_READ_MOSTLY(void *, crash_notes);
> +/* Memory regions to store the per cpu register state etc. on a crash. */
> +typedef struct { Elf_Note * start; size_t size; } crash_note_range_t;
> +static crash_note_range_t * crash_notes;
> +
> +/* Lock to prevent race conditions when allocating the crash note buffers. 
> */
> +static DEFINE_SPINLOCK(crash_notes_lock);
>  
>  static Elf_Note *xen_crash_note;
>  
> @@ -173,13 +179,17 @@ static void one_cpu_only(void)
>  void kexec_crash_save_cpu(void)
>  {
>      int cpu = smp_processor_id();
> -    Elf_Note *note = per_cpu(crash_notes, cpu);
> +    Elf_Note *note;
>      ELF_Prstatus *prstatus;
>      crash_xen_core_t *xencore;
>  
> +    BUG_ON ( ! crash_notes );
> +
>      if ( cpumask_test_and_set_cpu(cpu, &crash_saved_cpus) )
>          return;
>  
> +    note = crash_notes[cpu].start;
> +
>      prstatus = (ELF_Prstatus *)ELFNOTE_DESC(note);
>  
>      note = ELFNOTE_NEXT(note);
> @@ -265,13 +275,6 @@ static struct keyhandler crashdump_trigg
>      .desc = "trigger a crashdump"
>  };
>  
> -static __init int register_crashdump_trigger(void)
> -{
> -    register_keyhandler('C', &crashdump_trigger_keyhandler);
> -    return 0;
> -}
> -__initcall(register_crashdump_trigger);
> -
>  static void setup_note(Elf_Note *n, const char *name, int type, int descsz)
>  {
>      int l = strlen(name) + 1;
> @@ -281,13 +284,144 @@ static void setup_note(Elf_Note *n, cons
>      n->type = type;
>  }
>  
> -static int sizeof_note(const char *name, int descsz)
> +static size_t sizeof_note(const char *name, int descsz)
>  {
>      return (sizeof(Elf_Note) +
>              ELFNOTE_ALIGN(strlen(name)+1) +
>              ELFNOTE_ALIGN(descsz));
>  }
>  
> +static size_t sizeof_cpu_notes(const unsigned long cpu)
> +{
> +    /* All CPUs present a PRSTATUS and crash_xen_core note. */
> +    size_t bytes =
> +        + sizeof_note("CORE", sizeof(ELF_Prstatus)) +
> +        + sizeof_note("Xen", sizeof(crash_xen_core_t));
> +
> +    /* CPU0 also presents the crash_xen_info note. */
> +    if ( ! cpu )
> +        bytes = bytes +
> +            sizeof_note("Xen", sizeof(crash_xen_info_t));
> +
> +    return bytes;
> +}
> +
> +/* Allocate a crash note buffer for a newly onlined cpu. */
> +static int kexec_init_cpu_notes(const unsigned long cpu)
> +{
> +    Elf_Note * note = NULL;
> +    int ret = 0;
> +    int nr_bytes = 0;
> +
> +    BUG_ON( cpu >= nr_cpu_ids || ! crash_notes );
> +
> +    /* If already allocated, nothing to do. */
> +    if ( crash_notes[cpu].start )
> +        return ret;
> +
> +    nr_bytes = sizeof_cpu_notes(cpu);
> +    note = xmalloc_bytes(nr_bytes);
> +
> +    /* Protect the write into crash_notes[] with a spinlock, as this 
> function
> +     * is on a hotplug path and a hypercall path. */
> +    spin_lock(&crash_notes_lock);
> +
> +    /* If we are racing with another CPU and it has beaten us, give up
> +     * gracefully. */
> +    if ( crash_notes[cpu].start )
> +    {
> +        spin_unlock(&crash_notes_lock);
> +        /* Always return ok, because whether we successfully allocated or 
> not,
> +         * another CPU has successfully allocated. */
> +        if ( note )
> +            xfree(note);
> +    }
> +    else
> +    {
> +        crash_notes[cpu].start = note;
> +        crash_notes[cpu].size = nr_bytes;
> +        spin_unlock(&crash_notes_lock);
> +
> +        /* If the allocation failed, and another CPU did not beat us, give
> +         * up with ENOMEM. */
> +        if ( ! note )
> +            ret = -ENOMEM;
> +        /* else all is good so lets set up the notes. */
> +        else
> +        {
> +            /* Set up CORE note. */
> +            setup_note(note, "CORE", NT_PRSTATUS, sizeof(ELF_Prstatus));
> +            note = ELFNOTE_NEXT(note);
> +
> +            /* Set up Xen CORE note. */
> +            setup_note(note, "Xen", XEN_ELFNOTE_CRASH_REGS,
> +                       sizeof(crash_xen_core_t));
> +
> +            if ( ! cpu )
> +            {
> +                /* Set up Xen Crash Info note. */
> +                xen_crash_note = note = ELFNOTE_NEXT(note);
> +                setup_note(note, "Xen", XEN_ELFNOTE_CRASH_INFO,
> +                           sizeof(crash_xen_info_t));
> +            }
> +        }
> +    }
> +
> +    return ret;
> +}
> +
> +static int cpu_callback(
> +    struct notifier_block *nfb, unsigned long action, void *hcpu)
> +{
> +    unsigned long cpu = (unsigned long)hcpu;
> +
> +    /* Only hook on CPU_UP_PREPARE because once a crash_note has been 
> reported
> +     * to dom0, it must keep it around in case of a crash, as the crash 
> kernel
> +     * will be hard coded to the original physical address reported. */
> +    switch ( action )
> +    {
> +    case CPU_UP_PREPARE:
> +        /* Ignore return value.  If this boot time, -ENOMEM will cause all
> +         * manner of problems elsewhere very soon, and if it is during 
> runtime,
> +         * then failing to allocate crash notes is not a good enough reason 
> to
> +         * fail the CPU_UP_PREPARE */
> +        kexec_init_cpu_notes(cpu);
> +        break;
> +    default:
> +        break;
> +    }
> +    return NOTIFY_DONE;
> +}
> +
> +static struct notifier_block cpu_nfb = {
> +    .notifier_call = cpu_callback
> +};
> +
> +static int __init kexec_init(void)
> +{
> +    void *cpu = (void *)(unsigned long)smp_processor_id();
> +
> +    /* If no crash area, no need to allocate space for notes. */
> +    if ( !kexec_crash_area.size )
> +        return 0;
> +
> +    register_keyhandler('C', &crashdump_trigger_keyhandler);
> +
> +    crash_notes = xmalloc_array(crash_note_range_t, nr_cpu_ids);
> +    if ( ! crash_notes )
> +        return -ENOMEM;
> +
> +    memset(crash_notes, 0, sizeof(crash_note_range_t) * nr_cpu_ids);
> +
> +    cpu_callback(&cpu_nfb, CPU_UP_PREPARE, cpu);
> +    register_cpu_notifier(&cpu_nfb);
> +    return 0;
> +}
> +/* The reason for this to be a presmp_initcall as opposed to a regular
> + * __initcall is to allow the setup of the cpu hotplug handler before APs 
> are
> + * brought up. */
> +presmp_initcall(kexec_init);
> +
>  static int kexec_get_reserve(xen_kexec64_range_t *range)
>  {
>      if ( kexec_crash_area.size > 0 && kexec_crash_area.start > 0) {
> @@ -302,44 +436,29 @@ static int kexec_get_reserve(xen_kexec64
>  static int kexec_get_cpu(xen_kexec64_range_t *range)
>  {
>      int nr = range->nr;
> -    int nr_bytes = 0;
>  
> -    if ( nr < 0 || nr >= nr_cpu_ids || !cpu_online(nr) )
> +    if ( nr < 0 || nr >= nr_cpu_ids )
> +        return -ERANGE;
> +
> +    if ( ! crash_notes )
>          return -EINVAL;
>  
> -    nr_bytes += sizeof_note("CORE", sizeof(ELF_Prstatus));
> -    nr_bytes += sizeof_note("Xen", sizeof(crash_xen_core_t));
> +    /* Try once again to allocate room for the crash notes.  It is just 
> possible
> +     * that more space has become available since we last tried.  If space 
> has
> +     * already been allocated, kexec_init_cpu_notes() will return early 
> with 0.
> +     */
> +    kexec_init_cpu_notes(nr);
>  
> -    /* The Xen info note is included in CPU0's range. */
> -    if ( nr == 0 )
> -        nr_bytes += sizeof_note("Xen", sizeof(crash_xen_info_t));
> +    /* In the case of still not having enough memory to allocate buffer 
> room,
> +     * returning a range of 0,0 is still valid. */
> +    if ( crash_notes[nr].start )
> +    {
> +        range->start = __pa(crash_notes[nr].start);
> +        range->size = crash_notes[nr].size;
> +    }
> +    else
> +        range->start = range->size = 0;
>  
> -    if ( per_cpu(crash_notes, nr) == NULL )
> -    {
> -        Elf_Note *note;
> -
> -        note = per_cpu(crash_notes, nr) = xmalloc_bytes(nr_bytes);
> -
> -        if ( note == NULL )
> -            return -ENOMEM;
> -
> -        /* Setup CORE note. */
> -        setup_note(note, "CORE", NT_PRSTATUS, sizeof(ELF_Prstatus));
> -
> -        /* Setup Xen CORE note. */
> -        note = ELFNOTE_NEXT(note);
> -        setup_note(note, "Xen", XEN_ELFNOTE_CRASH_REGS, 
> sizeof(crash_xen_core_t));
> -
> -        if (nr == 0)
> -        {
> -            /* Setup system wide Xen info note. */
> -            xen_crash_note = note = ELFNOTE_NEXT(note);
> -            setup_note(note, "Xen", XEN_ELFNOTE_CRASH_INFO, 
> sizeof(crash_xen_info_t));
> -        }
> -    }
> -
> -    range->start = __pa((unsigned long)per_cpu(crash_notes, nr));
> -    range->size = nr_bytes;
>      return 0;
>  }
>  
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com 
> http://lists.xensource.com/xen-devel 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 23 08:41:48 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 Dec 2011 08: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.xensource.com>)
	id 1Re0h3-00046i-HQ; Fri, 23 Dec 2011 08:41:33 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Re0h2-000466-H7
	for xen-devel@lists.xensource.com; Fri, 23 Dec 2011 08:41:32 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1324629643!47853834!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18102 invoked from network); 23 Dec 2011 08:40:44 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-5.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 23 Dec 2011 08:40:44 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 23 Dec 2011 08:41:25 +0000
Message-Id: <4EF44CFC0200007800069B6F@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 23 Dec 2011 08:42:20 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>
References: <patchbomb.1324575382@andrewcoop.uk.xensource.com>
	<3da37c68284f9fcf5f74.1324575384@andrewcoop.uk.xensource.com>
In-Reply-To: <3da37c68284f9fcf5f74.1324575384@andrewcoop.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 2 of 3] KEXEC: Allocate crash notes on boot
 v6
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 22.12.11 at 18:36, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
> Currently, the buffers for crash notes are allocated per CPU when a
> KEXEC_CMD_kexec_get_range hypercall is made, referencing the CPU in
> question.
> 
> Although it certainly works in general, there are a few edge case problems:
> 
> 1) There appears to be no guarentee that dom0 will make this hypercall
>    for each pcpu on the system.  There appears to be variable
>    behaviour depending on how many cpus dom0 is compiled for, and how
>    many vcpus Xen gives to dom0.
> 
> 2) The allocation of these buffers occur at the whim of dom0.  While
>    this is typically very early on dom0 boot, but not guarenteed.
> 
> 3) It is possible (although not sensible) for a crash
>    kernel to be loaded without these (or some of these) hypercalls
>    being made. Under these circumstances, a crash would cause the
>    crash note code path will suffer a slew of null pointer deferences.
> 
> 4) If the hypercalls are made after late in the day, it is possible
>    for the hypercall to return -ENOMEM.  As code tends to be more
>    fragile once memory is enhausted, the likelyhood of us needing the
>    crash kernel is greater.

Also for the record, I continue to believe that none of these warrant
the changes made here. Better error/NULL checking may instead be
required in a few places, plus possibly some Dom0 code adjustments
(see my recent 2.6.18 kernel changes, on top of which pCPU hot add
support was implemented [which can't go into the 2.6.18 kernel as it
lacks general pCPU hot add code]).

> In addition, my forthcoming code to support 32bit kdump kernels on
> 64bit Xen on large (>64GB) boxes will require some guarentees as to
> where the crash note buffers are actually allocated in physical
> memory.  This is far easier to sort out at boot time, rather than
> after dom0 has been booted and potentially using the physical memory
> required.

This one is the only part of the rationale for these changes that I
view as half way reasonable, though with allocation in Xen going
from top down, not being able to allocate these is about the same
as e.g. Dom0 not being able to set up its swiotlb. That's what the
(by default) 128M reservation is for. So if anything, the number
there may want some tweaking for the case of very many CPUs.

Jan

> Therefore, allocate the crash note buffers at boot time.
> 
> Changes since v5:
>  *  Introduce sizeof_cpu_notes to move calculation of note size into a
>     separate location.
>  *  Tweak sizeof_note() to return size_t rather than int, as it is a
>     function based upon sizeof().
> 
> Changes since v4:
> 
>  *  Replace the current cpu crash note scheme of using void pointers
>     and hand calculating the size each time is needed, by a range
>     structure containing a pointer and a size.  This removes duplicate
>     times where the size is calculated.
>  *  Tweak kexec_get_cpu().  Don't fail if a cpu is offline because it
>     may already have crash notes, and may be up by the time a crash
>     happens.  Split the error conditions up to return ERANGE for an
>     out-of-range cpu request rather than EINVAL.  Finally, returning a
>     range of zeros is acceptable, so do this in preference to failing.
> 
> Changes since v3:
> 
>  *  Alter the spinlocks to avoid calling xmalloc/xfree while holding
>     the lock.
>  *  Tidy up the coding style used.
> 
> Changes since v2:
> 
>  *  Allocate crash_notes dynamically using nr_cpu_ids at boot time,
>     rather than statically using NR_CPUS.
>  *  Fix the incorrect use of signed integers for cpu id.
>  *  Fix collateral damage to do_crashdump_trigger() and
>     crashdump_trigger_handler caused by reordering sizeof_note() and
>     setup_note()
>  *  Tweak the issue about returing -ENOMEM from kexec_init_cpu_note().
>     No functional change.
>  *  Change kexec_get_cpu() to attempt to allocate crash note buffers
>     in case we have more free memory now than when the pcpu came up.
>  *  Now that there are two codepaths possibly allocating crash notes,
>     protect the allocation itself with a spinlock.
> 
> Changes since v1:
> 
>  *  Use cpu hotplug notifiers to handle allocating of the notes
>     buffers rather than assuming the boot state of cpus will be the
>     same as the crash state.
>  *  Move crash_notes from being per_cpu.  This is because the kdump
>     kernel elf binary put in the crash area is hard coded to physical
>     addresses which the dom0 kernel typically obtains at boot time.
>     If a cpu is offlined, its buffer should not be deallocated because
>     the kdump kernel would read junk when trying to get the crash
>     notes.  Similarly, the same problem would occur if the cpu was
>     re-onlined later and its crash notes buffer was allocated elsewhere.
>  *  Only attempt to allocate buffers if a crash area has been
>     specified.  Else, allocating crash note buffers is a waste of
>     space.  Along with this, change the test in kexec_get_cpu to
>     return -EINVAL if no buffers have been allocated.
> 
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
> 
> diff -r f571dc8e4368 -r 3da37c68284f xen/common/kexec.c
> --- a/xen/common/kexec.c
> +++ b/xen/common/kexec.c
> @@ -25,13 +25,19 @@
>  #include <xen/kexec.h>
>  #include <public/elfnote.h>
>  #include <xsm/xsm.h>
> +#include <xen/cpu.h>
>  #ifdef CONFIG_COMPAT
>  #include <compat/kexec.h>
>  #endif
>  
>  bool_t kexecing = FALSE;
>  
> -static DEFINE_PER_CPU_READ_MOSTLY(void *, crash_notes);
> +/* Memory regions to store the per cpu register state etc. on a crash. */
> +typedef struct { Elf_Note * start; size_t size; } crash_note_range_t;
> +static crash_note_range_t * crash_notes;
> +
> +/* Lock to prevent race conditions when allocating the crash note buffers. 
> */
> +static DEFINE_SPINLOCK(crash_notes_lock);
>  
>  static Elf_Note *xen_crash_note;
>  
> @@ -173,13 +179,17 @@ static void one_cpu_only(void)
>  void kexec_crash_save_cpu(void)
>  {
>      int cpu = smp_processor_id();
> -    Elf_Note *note = per_cpu(crash_notes, cpu);
> +    Elf_Note *note;
>      ELF_Prstatus *prstatus;
>      crash_xen_core_t *xencore;
>  
> +    BUG_ON ( ! crash_notes );
> +
>      if ( cpumask_test_and_set_cpu(cpu, &crash_saved_cpus) )
>          return;
>  
> +    note = crash_notes[cpu].start;
> +
>      prstatus = (ELF_Prstatus *)ELFNOTE_DESC(note);
>  
>      note = ELFNOTE_NEXT(note);
> @@ -265,13 +275,6 @@ static struct keyhandler crashdump_trigg
>      .desc = "trigger a crashdump"
>  };
>  
> -static __init int register_crashdump_trigger(void)
> -{
> -    register_keyhandler('C', &crashdump_trigger_keyhandler);
> -    return 0;
> -}
> -__initcall(register_crashdump_trigger);
> -
>  static void setup_note(Elf_Note *n, const char *name, int type, int descsz)
>  {
>      int l = strlen(name) + 1;
> @@ -281,13 +284,144 @@ static void setup_note(Elf_Note *n, cons
>      n->type = type;
>  }
>  
> -static int sizeof_note(const char *name, int descsz)
> +static size_t sizeof_note(const char *name, int descsz)
>  {
>      return (sizeof(Elf_Note) +
>              ELFNOTE_ALIGN(strlen(name)+1) +
>              ELFNOTE_ALIGN(descsz));
>  }
>  
> +static size_t sizeof_cpu_notes(const unsigned long cpu)
> +{
> +    /* All CPUs present a PRSTATUS and crash_xen_core note. */
> +    size_t bytes =
> +        + sizeof_note("CORE", sizeof(ELF_Prstatus)) +
> +        + sizeof_note("Xen", sizeof(crash_xen_core_t));
> +
> +    /* CPU0 also presents the crash_xen_info note. */
> +    if ( ! cpu )
> +        bytes = bytes +
> +            sizeof_note("Xen", sizeof(crash_xen_info_t));
> +
> +    return bytes;
> +}
> +
> +/* Allocate a crash note buffer for a newly onlined cpu. */
> +static int kexec_init_cpu_notes(const unsigned long cpu)
> +{
> +    Elf_Note * note = NULL;
> +    int ret = 0;
> +    int nr_bytes = 0;
> +
> +    BUG_ON( cpu >= nr_cpu_ids || ! crash_notes );
> +
> +    /* If already allocated, nothing to do. */
> +    if ( crash_notes[cpu].start )
> +        return ret;
> +
> +    nr_bytes = sizeof_cpu_notes(cpu);
> +    note = xmalloc_bytes(nr_bytes);
> +
> +    /* Protect the write into crash_notes[] with a spinlock, as this 
> function
> +     * is on a hotplug path and a hypercall path. */
> +    spin_lock(&crash_notes_lock);
> +
> +    /* If we are racing with another CPU and it has beaten us, give up
> +     * gracefully. */
> +    if ( crash_notes[cpu].start )
> +    {
> +        spin_unlock(&crash_notes_lock);
> +        /* Always return ok, because whether we successfully allocated or 
> not,
> +         * another CPU has successfully allocated. */
> +        if ( note )
> +            xfree(note);
> +    }
> +    else
> +    {
> +        crash_notes[cpu].start = note;
> +        crash_notes[cpu].size = nr_bytes;
> +        spin_unlock(&crash_notes_lock);
> +
> +        /* If the allocation failed, and another CPU did not beat us, give
> +         * up with ENOMEM. */
> +        if ( ! note )
> +            ret = -ENOMEM;
> +        /* else all is good so lets set up the notes. */
> +        else
> +        {
> +            /* Set up CORE note. */
> +            setup_note(note, "CORE", NT_PRSTATUS, sizeof(ELF_Prstatus));
> +            note = ELFNOTE_NEXT(note);
> +
> +            /* Set up Xen CORE note. */
> +            setup_note(note, "Xen", XEN_ELFNOTE_CRASH_REGS,
> +                       sizeof(crash_xen_core_t));
> +
> +            if ( ! cpu )
> +            {
> +                /* Set up Xen Crash Info note. */
> +                xen_crash_note = note = ELFNOTE_NEXT(note);
> +                setup_note(note, "Xen", XEN_ELFNOTE_CRASH_INFO,
> +                           sizeof(crash_xen_info_t));
> +            }
> +        }
> +    }
> +
> +    return ret;
> +}
> +
> +static int cpu_callback(
> +    struct notifier_block *nfb, unsigned long action, void *hcpu)
> +{
> +    unsigned long cpu = (unsigned long)hcpu;
> +
> +    /* Only hook on CPU_UP_PREPARE because once a crash_note has been 
> reported
> +     * to dom0, it must keep it around in case of a crash, as the crash 
> kernel
> +     * will be hard coded to the original physical address reported. */
> +    switch ( action )
> +    {
> +    case CPU_UP_PREPARE:
> +        /* Ignore return value.  If this boot time, -ENOMEM will cause all
> +         * manner of problems elsewhere very soon, and if it is during 
> runtime,
> +         * then failing to allocate crash notes is not a good enough reason 
> to
> +         * fail the CPU_UP_PREPARE */
> +        kexec_init_cpu_notes(cpu);
> +        break;
> +    default:
> +        break;
> +    }
> +    return NOTIFY_DONE;
> +}
> +
> +static struct notifier_block cpu_nfb = {
> +    .notifier_call = cpu_callback
> +};
> +
> +static int __init kexec_init(void)
> +{
> +    void *cpu = (void *)(unsigned long)smp_processor_id();
> +
> +    /* If no crash area, no need to allocate space for notes. */
> +    if ( !kexec_crash_area.size )
> +        return 0;
> +
> +    register_keyhandler('C', &crashdump_trigger_keyhandler);
> +
> +    crash_notes = xmalloc_array(crash_note_range_t, nr_cpu_ids);
> +    if ( ! crash_notes )
> +        return -ENOMEM;
> +
> +    memset(crash_notes, 0, sizeof(crash_note_range_t) * nr_cpu_ids);
> +
> +    cpu_callback(&cpu_nfb, CPU_UP_PREPARE, cpu);
> +    register_cpu_notifier(&cpu_nfb);
> +    return 0;
> +}
> +/* The reason for this to be a presmp_initcall as opposed to a regular
> + * __initcall is to allow the setup of the cpu hotplug handler before APs 
> are
> + * brought up. */
> +presmp_initcall(kexec_init);
> +
>  static int kexec_get_reserve(xen_kexec64_range_t *range)
>  {
>      if ( kexec_crash_area.size > 0 && kexec_crash_area.start > 0) {
> @@ -302,44 +436,29 @@ static int kexec_get_reserve(xen_kexec64
>  static int kexec_get_cpu(xen_kexec64_range_t *range)
>  {
>      int nr = range->nr;
> -    int nr_bytes = 0;
>  
> -    if ( nr < 0 || nr >= nr_cpu_ids || !cpu_online(nr) )
> +    if ( nr < 0 || nr >= nr_cpu_ids )
> +        return -ERANGE;
> +
> +    if ( ! crash_notes )
>          return -EINVAL;
>  
> -    nr_bytes += sizeof_note("CORE", sizeof(ELF_Prstatus));
> -    nr_bytes += sizeof_note("Xen", sizeof(crash_xen_core_t));
> +    /* Try once again to allocate room for the crash notes.  It is just 
> possible
> +     * that more space has become available since we last tried.  If space 
> has
> +     * already been allocated, kexec_init_cpu_notes() will return early 
> with 0.
> +     */
> +    kexec_init_cpu_notes(nr);
>  
> -    /* The Xen info note is included in CPU0's range. */
> -    if ( nr == 0 )
> -        nr_bytes += sizeof_note("Xen", sizeof(crash_xen_info_t));
> +    /* In the case of still not having enough memory to allocate buffer 
> room,
> +     * returning a range of 0,0 is still valid. */
> +    if ( crash_notes[nr].start )
> +    {
> +        range->start = __pa(crash_notes[nr].start);
> +        range->size = crash_notes[nr].size;
> +    }
> +    else
> +        range->start = range->size = 0;
>  
> -    if ( per_cpu(crash_notes, nr) == NULL )
> -    {
> -        Elf_Note *note;
> -
> -        note = per_cpu(crash_notes, nr) = xmalloc_bytes(nr_bytes);
> -
> -        if ( note == NULL )
> -            return -ENOMEM;
> -
> -        /* Setup CORE note. */
> -        setup_note(note, "CORE", NT_PRSTATUS, sizeof(ELF_Prstatus));
> -
> -        /* Setup Xen CORE note. */
> -        note = ELFNOTE_NEXT(note);
> -        setup_note(note, "Xen", XEN_ELFNOTE_CRASH_REGS, 
> sizeof(crash_xen_core_t));
> -
> -        if (nr == 0)
> -        {
> -            /* Setup system wide Xen info note. */
> -            xen_crash_note = note = ELFNOTE_NEXT(note);
> -            setup_note(note, "Xen", XEN_ELFNOTE_CRASH_INFO, 
> sizeof(crash_xen_info_t));
> -        }
> -    }
> -
> -    range->start = __pa((unsigned long)per_cpu(crash_notes, nr));
> -    range->size = nr_bytes;
>      return 0;
>  }
>  
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com 
> http://lists.xensource.com/xen-devel 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 23 09:05:49 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 Dec 2011 09:05:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Re14B-0004WB-RN; Fri, 23 Dec 2011 09:05:27 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Re14A-0004W6-Kk
	for xen-devel@lists.xensource.com; Fri, 23 Dec 2011 09:05:26 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1324631119!8401485!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23647 invoked from network); 23 Dec 2011 09:05:19 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-2.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 23 Dec 2011 09:05:19 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 23 Dec 2011 09:05:18 +0000
Message-Id: <4EF452940200007800069B89@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 23 Dec 2011 09:06:12 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>
References: <patchbomb.1324575382@andrewcoop.uk.xensource.com>
	<23c31d59ffb1590815bc.1324575385@andrewcoop.uk.xensource.com>
In-Reply-To: <23c31d59ffb1590815bc.1324575385@andrewcoop.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 3 of 3] KEXEC: Allocate crash structures in
 low memory
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 22.12.11 at 18:36, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
> On 64bit Xen with 32bit dom0 and crashkernel, xmalloc'ing items such
> as the CPU crash notes will go into the xenheap, which tends to be in
> upper memory.  This causes problems on machines with more than 64GB
> (or 4GB if no PAE support) of ram as the crashkernel physically cant
> access the crash notes.

What use is a crash dump taken with a 32-bit kernel on a machine
with more than 64G (or more than 4G is the crash kernel doesn't
support PAE)?

> The solution is to force Xen to allocate certain structures in lower
> memory.  This is achieved by introducing two new command line
> parameters; low_crashinfo and crashinfo_maxaddr.  Because of the
> potential impact on 32bit PV guests, and that this problem does not
> exist for 64bit dom0 on 64bit Xen, this new functionality defaults to
> the codebase's previous behavior, requiring the user to explicitly
> add extra command line parameters to change the behavior.
> 
> This patch consists of 3 logically distinct but closely related
> changes.
>  1) Add the two new command line parameters.

Do you really need both? Just being able to set the max address
would seem sufficient...

>  2) Change crash note allocation to use lower memory when instructed.
>  3) Change the conring buffer to use lower memory when instructed.

Why does this one need moving, but none of the other Xen data
structures? If anything, I would have expected you to limit the Xen
heap altogether, so that automatically all allocations get done in a
way so that at least Xen's data structures are available in the
(truncated) dump.

> There result is that the crash notes and console ring will be placed
> in lower memory so useful information can be recovered in the case of
> a crash.
> 
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
> 
> diff -r 3da37c68284f -r 23c31d59ffb1 xen/arch/x86/setup.c
> --- a/xen/arch/x86/setup.c
> +++ b/xen/arch/x86/setup.c
> @@ -586,6 +586,10 @@ void __init __start_xen(unsigned long mb
>      }
>      cmdline_parse(cmdline);
>  
> +    /* Must be after command line argument parsing and before 
> +     * allocing any xenheap structures wanted in lower memory. */
> +    kexec_early_calculations();
> +

But does it really need to be *this* early?

>      parse_video_info();
>  
>      set_current((struct vcpu *)0xfffff000); /* debug sanity */
> diff -r 3da37c68284f -r 23c31d59ffb1 xen/common/kexec.c
> --- a/xen/common/kexec.c
> +++ b/xen/common/kexec.c
> @@ -36,7 +36,9 @@ bool_t kexecing = FALSE;
>  typedef struct { Elf_Note * start; size_t size; } crash_note_range_t;
>  static crash_note_range_t * crash_notes;
>  
> -/* Lock to prevent race conditions when allocating the crash note buffers. 
> */
> +/* Lock to prevent race conditions when allocating the crash note buffers.
> + * It also serves to protect calls to alloc_from_crash_heap when allocating
> + * crash note buffers in lower memory. */
>  static DEFINE_SPINLOCK(crash_notes_lock);
>  
>  static Elf_Note *xen_crash_note;
> @@ -70,6 +72,23 @@ static struct {
>      (_d_)->start = (_s_)->start; \
>  } while (0)
>  
> +/* Low crashinfo mode.  Start as INVALID so serveral codepaths can set up
> + * defaults without needing to know the state of the others. */
> +enum low_crashinfo low_crashinfo_mode = LOW_CRASHINFO_INVALID;
> +
> +/* This value is only considered if low_crash_mode is set to MIN or ALL, so
> + * setting a default here is safe. Default to 4GB.  This is because the 
> current
> + * KEXEC_CMD_get_range compat hypercall trucates 64bit pointers to 32 bits. 
> The
> + * typical usecase for crashinfo_maxaddr will be for 64bit Xen with 32bit 
> dom0 
> + * and 32bit crash kernel. */
> +static paddr_t crashinfo_maxaddr = 4ULL << 30;

__initdata

> +
> +/* = log base 2 of crashinfo_maxaddr after checking for sanity. */
> +paddr_t crashinfo_maxaddr_bits = 0;
> +
> +/* Pointers to keep track of the crash heap region. */
> +static void *crash_heap_current = NULL, *crash_heap_end = NULL;
> +
>  /*
>   * Parse command lines in the format
>   *
> @@ -148,6 +167,58 @@ static void __init parse_crashkernel(con
>  }
>  custom_param("crashkernel", parse_crashkernel);
>  
> +/* Parse command lines in the format:
> + *
> + *   low_crashinfo=[none,min,all]
> + * 
> + * - none disables the low allocation of crash info.
> + * - min will allocate enough low information for the crash kernel to be 
> able
> + *       to extract the hypervisor and dom0 message ring buffers.
> + * - all will allocate additional structures such as domain and vcpu structs
> + *       low so the crash kernel can perform an extended analysis of state.
> + */
> +static void __init parse_low_crashinfo(const char * str)
> +{
> +
> +    if ( !strlen(str) )
> +        /* default to min if user just specifies "low_crashinfo" */
> +        low_crashinfo_mode = LOW_CRASHINFO_MIN;
> +    else if ( !strcmp(str, "none" ) )
> +        low_crashinfo_mode = LOW_CRASHINFO_NONE;
> +    else if ( !strcmp(str, "min" ) )
> +        low_crashinfo_mode = LOW_CRASHINFO_MIN;
> +    else if ( !strcmp(str, "all" ) )
> +        low_crashinfo_mode = LOW_CRASHINFO_ALL;
> +    else
> +    {
> +        printk("Unknown low_crashinfo parameter '%s'.  Defaulting to 
> min.\n", str);
> +        low_crashinfo_mode = LOW_CRASHINFO_MIN;
> +    }
> +}
> +custom_param("low_crashinfo", parse_low_crashinfo);
> +
> +/* Parse command lines in the format:
> + * 
> + *   crashinfo_maxaddr=<addr>
> + *
> + * <addr> will be rounded down to the nearest power of two.  Defaults to 64G
> + */
> +static void __init parse_crashinfo_maxaddr(const char * str)
> +{
> +    u64 addr;
> +
> +    /* if low_crashinfo_mode is unset, default to min. */
> +    if ( low_crashinfo_mode == LOW_CRASHINFO_INVALID )
> +        low_crashinfo_mode = LOW_CRASHINFO_MIN;
> +
> +    if ( (addr = parse_size_and_unit(str, NULL)) )
> +        crashinfo_maxaddr = addr;
> +    else
> +        printk("Unable to parse crashinfo_maxaddr. Defaulting to %p\n",
> +               (void*)crashinfo_maxaddr);
> +}
> +custom_param("crashinfo_maxaddr", parse_crashinfo_maxaddr);
> +
>  void __init set_kexec_crash_area_size(u64 system_ram)
>  {
>      unsigned int idx;
> @@ -306,6 +377,20 @@ static size_t sizeof_cpu_notes(const uns
>      return bytes;
>  }
>  
> +/* Allocate size_t bytes of space from the previously allocated
> + * crash heap if the user has requested that crash notes be allocated
> + * in lower memory.  There is currently no case where the crash notes
> + * should be free()'d. */
> +static void * alloc_from_crash_heap(const size_t bytes)
> +{
> +    void * ret;
> +    if ( crash_heap_current + bytes > crash_heap_end )
> +        return NULL;
> +    ret = (void*)crash_heap_current;
> +    crash_heap_current += bytes;
> +    return ret;
> +}
> +
>  /* Allocate a crash note buffer for a newly onlined cpu. */
>  static int kexec_init_cpu_notes(const unsigned long cpu)
>  {
> @@ -320,7 +405,10 @@ static int kexec_init_cpu_notes(const un
>          return ret;
>  
>      nr_bytes = sizeof_cpu_notes(cpu);
> -    note = xmalloc_bytes(nr_bytes);
> +
> +    /* If we dont care about the position of allocation, malloc. */
> +    if ( low_crashinfo_mode == LOW_CRASHINFO_NONE )
> +        note = xmalloc_bytes(nr_bytes);
>  
>      /* Protect the write into crash_notes[] with a spinlock, as this 
> function
>       * is on a hotplug path and a hypercall path. */
> @@ -338,6 +426,11 @@ static int kexec_init_cpu_notes(const un
>      }
>      else
>      {
> +        /* If we care about memory possition, alloc from the crash heap,
> +         * also protected by the crash_notes_lock. */
> +        if ( low_crashinfo_mode > LOW_CRASHINFO_NONE )
> +            note = alloc_from_crash_heap(nr_bytes);
> +
>          crash_notes[cpu].start = note;
>          crash_notes[cpu].size = nr_bytes;
>          spin_unlock(&crash_notes_lock);
> @@ -397,6 +490,24 @@ static struct notifier_block cpu_nfb = {
>      .notifier_call = cpu_callback
>  };
>  
> +void __init kexec_early_calculations(void)
> +{
> +    /* If low_crashinfo_mode is still INVALID, neither "low_crashinfo" nor
> +     * "crashinfo_maxaddr" have been specified on the command line, so
> +     * explicitly set to NONE. */
> +    if ( low_crashinfo_mode == LOW_CRASHINFO_INVALID )
> +        low_crashinfo_mode = LOW_CRASHINFO_NONE;
> +
> +    crashinfo_maxaddr_bits = 0;
> +    if ( low_crashinfo_mode > LOW_CRASHINFO_NONE )
> +    {
> +        paddr_t tmp = crashinfo_maxaddr;
> +
> +        while ( tmp >>= 1 )
> +            crashinfo_maxaddr_bits++;

fls() or some of its cousins

> +    }
> +}
> +
>  static int __init kexec_init(void)
>  {
>      void *cpu = (void *)(unsigned long)smp_processor_id();
> @@ -407,6 +518,29 @@ static int __init kexec_init(void)
>  
>      register_keyhandler('C', &crashdump_trigger_keyhandler);
>  
> +    if ( low_crashinfo_mode > LOW_CRASHINFO_NONE )
> +    {
> +        size_t crash_heap_size;
> +
> +        /* This calculation is safe even if the machine is booted in 
> +         * uniprocessor mode. */
> +        crash_heap_size = sizeof_cpu_notes(0) +
> +            sizeof_cpu_notes(1) * (nr_cpu_ids - 1);
> +        crash_heap_size = PAGE_ALIGN(crash_heap_size);
> +
> +        crash_heap_current = alloc_xenheap_pages(
> +            get_order_from_bytes(crash_heap_size),
> +            MEMF_bits(crashinfo_maxaddr_bits) );
> +
> +        if ( crash_heap_current )
> +            crash_heap_end = crash_heap_current + crash_heap_size;
> +        else
> +            return -ENOMEM;

Constructs like this generally look bogus to me, as

        if ( !crash_heap_current )
            return -ENOMEM;
        ...

is shorter and (to me at least) more clear.

> +    }
> +
> +    /* crash_notes may be allocated anywhere Xen can reach in memory.
> +       Only the individual CPU crash notes themselves must be allocated
> +       in lower memory if requested. */
>      crash_notes = xmalloc_array(crash_note_range_t, nr_cpu_ids);
>      if ( ! crash_notes )
>          return -ENOMEM;
> diff -r 3da37c68284f -r 23c31d59ffb1 xen/drivers/char/console.c
> --- a/xen/drivers/char/console.c
> +++ b/xen/drivers/char/console.c
> @@ -584,6 +584,7 @@ void __init console_init_postirq(void)
>  {
>      char *ring;
>      unsigned int i, order;
> +    u64 memflags;
>  
>      serial_init_postirq();
>  
> @@ -591,7 +592,8 @@ void __init console_init_postirq(void)
>          opt_conring_size = num_present_cpus() << (9 + xenlog_lower_thresh);
>  
>      order = get_order_from_bytes(max(opt_conring_size, conring_size));
> -    while ( (ring = alloc_xenheap_pages(order, 0)) == NULL )
> +    memflags = low_crashinfo_mode > LOW_CRASHINFO_NONE ? 
> MEMF_bits(crashinfo_maxaddr_bits) : 0;
> +    while ( (ring = alloc_xenheap_pages(order, memflags)) == NULL )
>      {
>          BUG_ON(order == 0);
>          order--;
> diff -r 3da37c68284f -r 23c31d59ffb1 xen/include/xen/kexec.h
> --- a/xen/include/xen/kexec.h
> +++ b/xen/include/xen/kexec.h
> @@ -25,6 +25,19 @@ void set_kexec_crash_area_size(u64 syste
>  #define KEXEC_IMAGE_CRASH_BASE   2
>  #define KEXEC_IMAGE_NR           4
>  
> +enum low_crashinfo {
> +    LOW_CRASHINFO_INVALID = 0,
> +    LOW_CRASHINFO_NONE = 1,
> +    LOW_CRASHINFO_MIN = 2,
> +    LOW_CRASHINFO_ALL = 3
> +};
> +
> +/* Low crashinfo mode.  Start as INVALID so serveral codepaths can set up
> + * defaults without needing to know the state of the others. */
> +extern enum low_crashinfo low_crashinfo_mode;
> +extern paddr_t crashinfo_maxaddr_bits;
> +void kexec_early_calculations(void);
> +
>  int machine_kexec_load(int type, int slot, xen_kexec_image_t *image);
>  void machine_kexec_unload(int type, int slot, xen_kexec_image_t *image);
>  void machine_kexec_reserved(xen_kexec_reserve_t *reservation);
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com 
> http://lists.xensource.com/xen-devel 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 23 09:05:49 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 Dec 2011 09:05:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Re14B-0004WB-RN; Fri, 23 Dec 2011 09:05:27 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Re14A-0004W6-Kk
	for xen-devel@lists.xensource.com; Fri, 23 Dec 2011 09:05:26 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1324631119!8401485!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23647 invoked from network); 23 Dec 2011 09:05:19 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-2.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 23 Dec 2011 09:05:19 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 23 Dec 2011 09:05:18 +0000
Message-Id: <4EF452940200007800069B89@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 23 Dec 2011 09:06:12 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>
References: <patchbomb.1324575382@andrewcoop.uk.xensource.com>
	<23c31d59ffb1590815bc.1324575385@andrewcoop.uk.xensource.com>
In-Reply-To: <23c31d59ffb1590815bc.1324575385@andrewcoop.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 3 of 3] KEXEC: Allocate crash structures in
 low memory
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 22.12.11 at 18:36, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
> On 64bit Xen with 32bit dom0 and crashkernel, xmalloc'ing items such
> as the CPU crash notes will go into the xenheap, which tends to be in
> upper memory.  This causes problems on machines with more than 64GB
> (or 4GB if no PAE support) of ram as the crashkernel physically cant
> access the crash notes.

What use is a crash dump taken with a 32-bit kernel on a machine
with more than 64G (or more than 4G is the crash kernel doesn't
support PAE)?

> The solution is to force Xen to allocate certain structures in lower
> memory.  This is achieved by introducing two new command line
> parameters; low_crashinfo and crashinfo_maxaddr.  Because of the
> potential impact on 32bit PV guests, and that this problem does not
> exist for 64bit dom0 on 64bit Xen, this new functionality defaults to
> the codebase's previous behavior, requiring the user to explicitly
> add extra command line parameters to change the behavior.
> 
> This patch consists of 3 logically distinct but closely related
> changes.
>  1) Add the two new command line parameters.

Do you really need both? Just being able to set the max address
would seem sufficient...

>  2) Change crash note allocation to use lower memory when instructed.
>  3) Change the conring buffer to use lower memory when instructed.

Why does this one need moving, but none of the other Xen data
structures? If anything, I would have expected you to limit the Xen
heap altogether, so that automatically all allocations get done in a
way so that at least Xen's data structures are available in the
(truncated) dump.

> There result is that the crash notes and console ring will be placed
> in lower memory so useful information can be recovered in the case of
> a crash.
> 
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
> 
> diff -r 3da37c68284f -r 23c31d59ffb1 xen/arch/x86/setup.c
> --- a/xen/arch/x86/setup.c
> +++ b/xen/arch/x86/setup.c
> @@ -586,6 +586,10 @@ void __init __start_xen(unsigned long mb
>      }
>      cmdline_parse(cmdline);
>  
> +    /* Must be after command line argument parsing and before 
> +     * allocing any xenheap structures wanted in lower memory. */
> +    kexec_early_calculations();
> +

But does it really need to be *this* early?

>      parse_video_info();
>  
>      set_current((struct vcpu *)0xfffff000); /* debug sanity */
> diff -r 3da37c68284f -r 23c31d59ffb1 xen/common/kexec.c
> --- a/xen/common/kexec.c
> +++ b/xen/common/kexec.c
> @@ -36,7 +36,9 @@ bool_t kexecing = FALSE;
>  typedef struct { Elf_Note * start; size_t size; } crash_note_range_t;
>  static crash_note_range_t * crash_notes;
>  
> -/* Lock to prevent race conditions when allocating the crash note buffers. 
> */
> +/* Lock to prevent race conditions when allocating the crash note buffers.
> + * It also serves to protect calls to alloc_from_crash_heap when allocating
> + * crash note buffers in lower memory. */
>  static DEFINE_SPINLOCK(crash_notes_lock);
>  
>  static Elf_Note *xen_crash_note;
> @@ -70,6 +72,23 @@ static struct {
>      (_d_)->start = (_s_)->start; \
>  } while (0)
>  
> +/* Low crashinfo mode.  Start as INVALID so serveral codepaths can set up
> + * defaults without needing to know the state of the others. */
> +enum low_crashinfo low_crashinfo_mode = LOW_CRASHINFO_INVALID;
> +
> +/* This value is only considered if low_crash_mode is set to MIN or ALL, so
> + * setting a default here is safe. Default to 4GB.  This is because the 
> current
> + * KEXEC_CMD_get_range compat hypercall trucates 64bit pointers to 32 bits. 
> The
> + * typical usecase for crashinfo_maxaddr will be for 64bit Xen with 32bit 
> dom0 
> + * and 32bit crash kernel. */
> +static paddr_t crashinfo_maxaddr = 4ULL << 30;

__initdata

> +
> +/* = log base 2 of crashinfo_maxaddr after checking for sanity. */
> +paddr_t crashinfo_maxaddr_bits = 0;
> +
> +/* Pointers to keep track of the crash heap region. */
> +static void *crash_heap_current = NULL, *crash_heap_end = NULL;
> +
>  /*
>   * Parse command lines in the format
>   *
> @@ -148,6 +167,58 @@ static void __init parse_crashkernel(con
>  }
>  custom_param("crashkernel", parse_crashkernel);
>  
> +/* Parse command lines in the format:
> + *
> + *   low_crashinfo=[none,min,all]
> + * 
> + * - none disables the low allocation of crash info.
> + * - min will allocate enough low information for the crash kernel to be 
> able
> + *       to extract the hypervisor and dom0 message ring buffers.
> + * - all will allocate additional structures such as domain and vcpu structs
> + *       low so the crash kernel can perform an extended analysis of state.
> + */
> +static void __init parse_low_crashinfo(const char * str)
> +{
> +
> +    if ( !strlen(str) )
> +        /* default to min if user just specifies "low_crashinfo" */
> +        low_crashinfo_mode = LOW_CRASHINFO_MIN;
> +    else if ( !strcmp(str, "none" ) )
> +        low_crashinfo_mode = LOW_CRASHINFO_NONE;
> +    else if ( !strcmp(str, "min" ) )
> +        low_crashinfo_mode = LOW_CRASHINFO_MIN;
> +    else if ( !strcmp(str, "all" ) )
> +        low_crashinfo_mode = LOW_CRASHINFO_ALL;
> +    else
> +    {
> +        printk("Unknown low_crashinfo parameter '%s'.  Defaulting to 
> min.\n", str);
> +        low_crashinfo_mode = LOW_CRASHINFO_MIN;
> +    }
> +}
> +custom_param("low_crashinfo", parse_low_crashinfo);
> +
> +/* Parse command lines in the format:
> + * 
> + *   crashinfo_maxaddr=<addr>
> + *
> + * <addr> will be rounded down to the nearest power of two.  Defaults to 64G
> + */
> +static void __init parse_crashinfo_maxaddr(const char * str)
> +{
> +    u64 addr;
> +
> +    /* if low_crashinfo_mode is unset, default to min. */
> +    if ( low_crashinfo_mode == LOW_CRASHINFO_INVALID )
> +        low_crashinfo_mode = LOW_CRASHINFO_MIN;
> +
> +    if ( (addr = parse_size_and_unit(str, NULL)) )
> +        crashinfo_maxaddr = addr;
> +    else
> +        printk("Unable to parse crashinfo_maxaddr. Defaulting to %p\n",
> +               (void*)crashinfo_maxaddr);
> +}
> +custom_param("crashinfo_maxaddr", parse_crashinfo_maxaddr);
> +
>  void __init set_kexec_crash_area_size(u64 system_ram)
>  {
>      unsigned int idx;
> @@ -306,6 +377,20 @@ static size_t sizeof_cpu_notes(const uns
>      return bytes;
>  }
>  
> +/* Allocate size_t bytes of space from the previously allocated
> + * crash heap if the user has requested that crash notes be allocated
> + * in lower memory.  There is currently no case where the crash notes
> + * should be free()'d. */
> +static void * alloc_from_crash_heap(const size_t bytes)
> +{
> +    void * ret;
> +    if ( crash_heap_current + bytes > crash_heap_end )
> +        return NULL;
> +    ret = (void*)crash_heap_current;
> +    crash_heap_current += bytes;
> +    return ret;
> +}
> +
>  /* Allocate a crash note buffer for a newly onlined cpu. */
>  static int kexec_init_cpu_notes(const unsigned long cpu)
>  {
> @@ -320,7 +405,10 @@ static int kexec_init_cpu_notes(const un
>          return ret;
>  
>      nr_bytes = sizeof_cpu_notes(cpu);
> -    note = xmalloc_bytes(nr_bytes);
> +
> +    /* If we dont care about the position of allocation, malloc. */
> +    if ( low_crashinfo_mode == LOW_CRASHINFO_NONE )
> +        note = xmalloc_bytes(nr_bytes);
>  
>      /* Protect the write into crash_notes[] with a spinlock, as this 
> function
>       * is on a hotplug path and a hypercall path. */
> @@ -338,6 +426,11 @@ static int kexec_init_cpu_notes(const un
>      }
>      else
>      {
> +        /* If we care about memory possition, alloc from the crash heap,
> +         * also protected by the crash_notes_lock. */
> +        if ( low_crashinfo_mode > LOW_CRASHINFO_NONE )
> +            note = alloc_from_crash_heap(nr_bytes);
> +
>          crash_notes[cpu].start = note;
>          crash_notes[cpu].size = nr_bytes;
>          spin_unlock(&crash_notes_lock);
> @@ -397,6 +490,24 @@ static struct notifier_block cpu_nfb = {
>      .notifier_call = cpu_callback
>  };
>  
> +void __init kexec_early_calculations(void)
> +{
> +    /* If low_crashinfo_mode is still INVALID, neither "low_crashinfo" nor
> +     * "crashinfo_maxaddr" have been specified on the command line, so
> +     * explicitly set to NONE. */
> +    if ( low_crashinfo_mode == LOW_CRASHINFO_INVALID )
> +        low_crashinfo_mode = LOW_CRASHINFO_NONE;
> +
> +    crashinfo_maxaddr_bits = 0;
> +    if ( low_crashinfo_mode > LOW_CRASHINFO_NONE )
> +    {
> +        paddr_t tmp = crashinfo_maxaddr;
> +
> +        while ( tmp >>= 1 )
> +            crashinfo_maxaddr_bits++;

fls() or some of its cousins

> +    }
> +}
> +
>  static int __init kexec_init(void)
>  {
>      void *cpu = (void *)(unsigned long)smp_processor_id();
> @@ -407,6 +518,29 @@ static int __init kexec_init(void)
>  
>      register_keyhandler('C', &crashdump_trigger_keyhandler);
>  
> +    if ( low_crashinfo_mode > LOW_CRASHINFO_NONE )
> +    {
> +        size_t crash_heap_size;
> +
> +        /* This calculation is safe even if the machine is booted in 
> +         * uniprocessor mode. */
> +        crash_heap_size = sizeof_cpu_notes(0) +
> +            sizeof_cpu_notes(1) * (nr_cpu_ids - 1);
> +        crash_heap_size = PAGE_ALIGN(crash_heap_size);
> +
> +        crash_heap_current = alloc_xenheap_pages(
> +            get_order_from_bytes(crash_heap_size),
> +            MEMF_bits(crashinfo_maxaddr_bits) );
> +
> +        if ( crash_heap_current )
> +            crash_heap_end = crash_heap_current + crash_heap_size;
> +        else
> +            return -ENOMEM;

Constructs like this generally look bogus to me, as

        if ( !crash_heap_current )
            return -ENOMEM;
        ...

is shorter and (to me at least) more clear.

> +    }
> +
> +    /* crash_notes may be allocated anywhere Xen can reach in memory.
> +       Only the individual CPU crash notes themselves must be allocated
> +       in lower memory if requested. */
>      crash_notes = xmalloc_array(crash_note_range_t, nr_cpu_ids);
>      if ( ! crash_notes )
>          return -ENOMEM;
> diff -r 3da37c68284f -r 23c31d59ffb1 xen/drivers/char/console.c
> --- a/xen/drivers/char/console.c
> +++ b/xen/drivers/char/console.c
> @@ -584,6 +584,7 @@ void __init console_init_postirq(void)
>  {
>      char *ring;
>      unsigned int i, order;
> +    u64 memflags;
>  
>      serial_init_postirq();
>  
> @@ -591,7 +592,8 @@ void __init console_init_postirq(void)
>          opt_conring_size = num_present_cpus() << (9 + xenlog_lower_thresh);
>  
>      order = get_order_from_bytes(max(opt_conring_size, conring_size));
> -    while ( (ring = alloc_xenheap_pages(order, 0)) == NULL )
> +    memflags = low_crashinfo_mode > LOW_CRASHINFO_NONE ? 
> MEMF_bits(crashinfo_maxaddr_bits) : 0;
> +    while ( (ring = alloc_xenheap_pages(order, memflags)) == NULL )
>      {
>          BUG_ON(order == 0);
>          order--;
> diff -r 3da37c68284f -r 23c31d59ffb1 xen/include/xen/kexec.h
> --- a/xen/include/xen/kexec.h
> +++ b/xen/include/xen/kexec.h
> @@ -25,6 +25,19 @@ void set_kexec_crash_area_size(u64 syste
>  #define KEXEC_IMAGE_CRASH_BASE   2
>  #define KEXEC_IMAGE_NR           4
>  
> +enum low_crashinfo {
> +    LOW_CRASHINFO_INVALID = 0,
> +    LOW_CRASHINFO_NONE = 1,
> +    LOW_CRASHINFO_MIN = 2,
> +    LOW_CRASHINFO_ALL = 3
> +};
> +
> +/* Low crashinfo mode.  Start as INVALID so serveral codepaths can set up
> + * defaults without needing to know the state of the others. */
> +extern enum low_crashinfo low_crashinfo_mode;
> +extern paddr_t crashinfo_maxaddr_bits;
> +void kexec_early_calculations(void);
> +
>  int machine_kexec_load(int type, int slot, xen_kexec_image_t *image);
>  void machine_kexec_unload(int type, int slot, xen_kexec_image_t *image);
>  void machine_kexec_reserved(xen_kexec_reserve_t *reservation);
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com 
> http://lists.xensource.com/xen-devel 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 23 09:09:19 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 Dec 2011 09:09:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Re17c-0004eO-NK; Fri, 23 Dec 2011 09:09:00 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Re17a-0004eB-RE
	for xen-devel@lists.xensource.com; Fri, 23 Dec 2011 09:08:59 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1324631332!1085365!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17093 invoked from network); 23 Dec 2011 09:08:52 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-16.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 23 Dec 2011 09:08:52 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 23 Dec 2011 09:08:51 +0000
Message-Id: <4EF453690200007800069B8E@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 23 Dec 2011 09:09:45 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>
References: <patchbomb.1324575382@andrewcoop.uk.xensource.com>
	<23c31d59ffb1590815bc.1324575385@andrewcoop.uk.xensource.com>
	<4EF37253.9000903@citrix.com> <4EF37A91.6000608@citrix.com>
In-Reply-To: <4EF37A91.6000608@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Tim Deegan <tim@xen.org>, David Vrabel <david.vrabel@citrix.com>
Subject: Re: [Xen-devel] [PATCH 3 of 3] KEXEC: Allocate crash structures in
 low memory
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 22.12.11 at 19:44, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
> On 22/12/11 18:09, David Vrabel wrote:
>> On 22/12/11 17:36, Andrew Cooper wrote:
>>> +    memflags = low_crashinfo_mode > LOW_CRASHINFO_NONE ? 
> MEMF_bits(crashinfo_maxaddr_bits) : 0;
>> If you set crashinfo_maxaddr_bits to 64 if low_crashinfo_mode isn't used
>> you wouldn't need this test.
> 
> I am not familiar enough with the intricacies of alloc_xenheap_pages to
> know whether that is safe.  cc'ing Tim for his expertise.

Passing 0 for the bit width is equivalent to passing a value beyond
what is covering the maximum available address, so you can pick
whatever better serves the purpose.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 23 09:09:19 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 Dec 2011 09:09:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Re17c-0004eO-NK; Fri, 23 Dec 2011 09:09:00 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Re17a-0004eB-RE
	for xen-devel@lists.xensource.com; Fri, 23 Dec 2011 09:08:59 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1324631332!1085365!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17093 invoked from network); 23 Dec 2011 09:08:52 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-16.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 23 Dec 2011 09:08:52 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 23 Dec 2011 09:08:51 +0000
Message-Id: <4EF453690200007800069B8E@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 23 Dec 2011 09:09:45 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>
References: <patchbomb.1324575382@andrewcoop.uk.xensource.com>
	<23c31d59ffb1590815bc.1324575385@andrewcoop.uk.xensource.com>
	<4EF37253.9000903@citrix.com> <4EF37A91.6000608@citrix.com>
In-Reply-To: <4EF37A91.6000608@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Tim Deegan <tim@xen.org>, David Vrabel <david.vrabel@citrix.com>
Subject: Re: [Xen-devel] [PATCH 3 of 3] KEXEC: Allocate crash structures in
 low memory
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 22.12.11 at 19:44, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
> On 22/12/11 18:09, David Vrabel wrote:
>> On 22/12/11 17:36, Andrew Cooper wrote:
>>> +    memflags = low_crashinfo_mode > LOW_CRASHINFO_NONE ? 
> MEMF_bits(crashinfo_maxaddr_bits) : 0;
>> If you set crashinfo_maxaddr_bits to 64 if low_crashinfo_mode isn't used
>> you wouldn't need this test.
> 
> I am not familiar enough with the intricacies of alloc_xenheap_pages to
> know whether that is safe.  cc'ing Tim for his expertise.

Passing 0 for the bit width is equivalent to passing a value beyond
what is covering the maximum available address, so you can pick
whatever better serves the purpose.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 23 09:26:29 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 Dec 2011 09:26:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Re1O6-0004th-FI; Fri, 23 Dec 2011 09:26:02 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Re1O5-0004tb-Th
	for xen-devel@lists.xensource.com; Fri, 23 Dec 2011 09:26:02 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1324632355!8556621!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODA5Ng==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12985 invoked from network); 23 Dec 2011 09:25:56 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Dec 2011 09:25:56 -0000
X-IronPort-AV: E=Sophos;i="4.71,398,1320624000"; 
   d="scan'208";a="9648435"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Dec 2011 09:25:55 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 23 Dec 2011 09:25:55 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Fri, 23 Dec 2011 09:25:55 +0000
In-Reply-To: <4EF44A100200007800069B5A@nat28.tlf.novell.com>
References: <CAPLaKK506e57uCvSdkjCqkUs6AS6ty4Efa+Ekhrczu=OA+TCHw@mail.gmail.com>
	<4EF44A100200007800069B5A@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1324632355.7877.96.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Roger Pau =?ISO-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Stubdom build problem in 4.1.2 but not in
 xen-unstable
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gRnJpLCAyMDExLTEyLTIzIGF0IDA4OjI5ICswMDAwLCBKYW4gQmV1bGljaCB3cm90ZToKPiA+
Pj4gT24gMjIuMTIuMTEgYXQgMTg6MDMsIFJvZ2VyIFBhdSBNb25uw6k8cm9nZXIucGF1QGVudGVs
LnVwYy5lZHU+IHdyb3RlOgo+ID4gY29uc29sZS94ZW5jb25zX3JpbmcuYzogSW4gZnVuY3Rpb24g
J3hlbmNvbnNfcmluZ19zZW5kX25vX25vdGlmeSc6Cj4gPiBjb25zb2xlL3hlbmNvbnNfcmluZy5j
OjI2OjQxOiBlcnJvcjogaW5saW5pbmcgZmFpbGVkIGluIGNhbGwgdG8KPiA+ICd4ZW5jb25zX2lu
dGVyZmFjZSc6IGNhbGwgaXMgdW5saWtlbHkgYW5kIGNvZGUgc2l6ZSB3b3VsZCBncm93Cj4gPiBb
LVdlcnJvcj1pbmxpbmVdCj4gPiBjb25zb2xlL3hlbmNvbnNfcmluZy5jOjM4OjE4OiBlcnJvcjog
Y2FsbGVkIGZyb20gaGVyZSBbLVdlcnJvcj1pbmxpbmVdCj4gPiBjYzE6IGFsbCB3YXJuaW5ncyBi
ZWluZyB0cmVhdGVkIGFzIGVycm9ycwo+ID4gCj4gPiBBbHRob3VnaCBJIGNhbiBidWlsZCB4ZW4t
dW5zdGFibGUgd2l0aG91dCBhbnkgcHJvYmxlbXMgb24gdGhlIHNhbWUKPiA+IG1hY2hpbmUuIEkn
dmUgYmVlbiB0cnlpbmcgdG8gZmluZCB0aGUgcGF0Y2ggdGhhdCBzb2x2ZWQgdGhpcyBvbgo+ID4g
dW5zdGFibGUsIGJ1dCBzbyBmYXIgSSBoYXZlbid0IGZvdW5kIGl0LiBBbnlvbmUga25vdyB3aGlj
aCBwYXRjaCBmaXhlZAo+ID4gaXQ/IEkgd291bGQgbGlrZSB0byBoYXZlIGl0IGJhY2twb3J0ZWQg
dG8geGVuLTQuMS4KPiAKPiBJdCBtYXkgd2VsbCBiZSB0aGF0IHRoZXJlIGlzIG5vIHN1Y2ggY2hh
bmdlc2V0LCBidXQgdGhlIGNvbXBpbGVyIGp1c3QKPiBkZWNpZGVzIHRvIGV2YWx1YXRlIHRoZSBs
aWtlbGlob29kcyBkaWZmZXJlbnRseS4gSSdtIGFzc3VtaW5nIHRoYXQgdGhlCj4gYnVpbGQgcHJv
YmxlbSB3b3VsZCBnbyBhd2F5IGJ5IHJlbW92aW5nIC1XaW5saW5lIGZyb20KPiBleHRyYXMvbWlu
aS1vcy9taW5pb3MubWs6REVGX0NGTEFHUyAod2hpY2ggaXMgcXVlc3Rpb25hYmxlIGluCj4gY29u
anVuY3Rpb24gd2l0aCB0aGUgLVdlcnJvciBmb3JjZWQgdGhlcmUgdG9vIC0gYSBtb3JlIHJlYXNv
bmFibHkKPiBhcHByb2FjaCB3b3VsZCBzZWVtIHRvIGJlIC1XaW5saW5lIC1Xbm8tZXJyb3I9aW5s
aW5lLCBhcHBhcmVudGx5Cj4gYXZhaWxhYmxlIHNpbmNlIGdjYyA0LjIueCkuCgpBbHRob3VnaCBp
biB0aGlzIHNwZWNpZmljIGNhc2UgKGFuZCBsaWtlbHkgaW4gbWFueSBjYXNlcykgdGhlIHVzZSBv
ZgppbmxpbmUgb24geGVuY29uc19pbnRlcmZhY2Ugc2VlbXMgdW5uZWNlc3NhcnkgLS0gbGV0cyBq
dXN0IGxlYXZlIGl0IHVwCnRvIHRoZSBjb21waWxlci4KCkkgdGhvdWdodCAiaW5saW5lIiB3YXMg
anVzdCBhIGhpbnQgc28gaXQgc2VlbXMgb2RkIHRoYXQgZ2NjIHdvdWxkIGVycm9yCm91dC4KCklh
bi4KCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4t
ZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tCmh0dHA6Ly9s
aXN0cy54ZW5zb3VyY2UuY29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Fri Dec 23 09:26:29 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 Dec 2011 09:26:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Re1O6-0004th-FI; Fri, 23 Dec 2011 09:26:02 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Re1O5-0004tb-Th
	for xen-devel@lists.xensource.com; Fri, 23 Dec 2011 09:26:02 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1324632355!8556621!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODA5Ng==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12985 invoked from network); 23 Dec 2011 09:25:56 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Dec 2011 09:25:56 -0000
X-IronPort-AV: E=Sophos;i="4.71,398,1320624000"; 
   d="scan'208";a="9648435"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Dec 2011 09:25:55 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 23 Dec 2011 09:25:55 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Fri, 23 Dec 2011 09:25:55 +0000
In-Reply-To: <4EF44A100200007800069B5A@nat28.tlf.novell.com>
References: <CAPLaKK506e57uCvSdkjCqkUs6AS6ty4Efa+Ekhrczu=OA+TCHw@mail.gmail.com>
	<4EF44A100200007800069B5A@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1324632355.7877.96.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Roger Pau =?ISO-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Stubdom build problem in 4.1.2 but not in
 xen-unstable
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gRnJpLCAyMDExLTEyLTIzIGF0IDA4OjI5ICswMDAwLCBKYW4gQmV1bGljaCB3cm90ZToKPiA+
Pj4gT24gMjIuMTIuMTEgYXQgMTg6MDMsIFJvZ2VyIFBhdSBNb25uw6k8cm9nZXIucGF1QGVudGVs
LnVwYy5lZHU+IHdyb3RlOgo+ID4gY29uc29sZS94ZW5jb25zX3JpbmcuYzogSW4gZnVuY3Rpb24g
J3hlbmNvbnNfcmluZ19zZW5kX25vX25vdGlmeSc6Cj4gPiBjb25zb2xlL3hlbmNvbnNfcmluZy5j
OjI2OjQxOiBlcnJvcjogaW5saW5pbmcgZmFpbGVkIGluIGNhbGwgdG8KPiA+ICd4ZW5jb25zX2lu
dGVyZmFjZSc6IGNhbGwgaXMgdW5saWtlbHkgYW5kIGNvZGUgc2l6ZSB3b3VsZCBncm93Cj4gPiBb
LVdlcnJvcj1pbmxpbmVdCj4gPiBjb25zb2xlL3hlbmNvbnNfcmluZy5jOjM4OjE4OiBlcnJvcjog
Y2FsbGVkIGZyb20gaGVyZSBbLVdlcnJvcj1pbmxpbmVdCj4gPiBjYzE6IGFsbCB3YXJuaW5ncyBi
ZWluZyB0cmVhdGVkIGFzIGVycm9ycwo+ID4gCj4gPiBBbHRob3VnaCBJIGNhbiBidWlsZCB4ZW4t
dW5zdGFibGUgd2l0aG91dCBhbnkgcHJvYmxlbXMgb24gdGhlIHNhbWUKPiA+IG1hY2hpbmUuIEkn
dmUgYmVlbiB0cnlpbmcgdG8gZmluZCB0aGUgcGF0Y2ggdGhhdCBzb2x2ZWQgdGhpcyBvbgo+ID4g
dW5zdGFibGUsIGJ1dCBzbyBmYXIgSSBoYXZlbid0IGZvdW5kIGl0LiBBbnlvbmUga25vdyB3aGlj
aCBwYXRjaCBmaXhlZAo+ID4gaXQ/IEkgd291bGQgbGlrZSB0byBoYXZlIGl0IGJhY2twb3J0ZWQg
dG8geGVuLTQuMS4KPiAKPiBJdCBtYXkgd2VsbCBiZSB0aGF0IHRoZXJlIGlzIG5vIHN1Y2ggY2hh
bmdlc2V0LCBidXQgdGhlIGNvbXBpbGVyIGp1c3QKPiBkZWNpZGVzIHRvIGV2YWx1YXRlIHRoZSBs
aWtlbGlob29kcyBkaWZmZXJlbnRseS4gSSdtIGFzc3VtaW5nIHRoYXQgdGhlCj4gYnVpbGQgcHJv
YmxlbSB3b3VsZCBnbyBhd2F5IGJ5IHJlbW92aW5nIC1XaW5saW5lIGZyb20KPiBleHRyYXMvbWlu
aS1vcy9taW5pb3MubWs6REVGX0NGTEFHUyAod2hpY2ggaXMgcXVlc3Rpb25hYmxlIGluCj4gY29u
anVuY3Rpb24gd2l0aCB0aGUgLVdlcnJvciBmb3JjZWQgdGhlcmUgdG9vIC0gYSBtb3JlIHJlYXNv
bmFibHkKPiBhcHByb2FjaCB3b3VsZCBzZWVtIHRvIGJlIC1XaW5saW5lIC1Xbm8tZXJyb3I9aW5s
aW5lLCBhcHBhcmVudGx5Cj4gYXZhaWxhYmxlIHNpbmNlIGdjYyA0LjIueCkuCgpBbHRob3VnaCBp
biB0aGlzIHNwZWNpZmljIGNhc2UgKGFuZCBsaWtlbHkgaW4gbWFueSBjYXNlcykgdGhlIHVzZSBv
ZgppbmxpbmUgb24geGVuY29uc19pbnRlcmZhY2Ugc2VlbXMgdW5uZWNlc3NhcnkgLS0gbGV0cyBq
dXN0IGxlYXZlIGl0IHVwCnRvIHRoZSBjb21waWxlci4KCkkgdGhvdWdodCAiaW5saW5lIiB3YXMg
anVzdCBhIGhpbnQgc28gaXQgc2VlbXMgb2RkIHRoYXQgZ2NjIHdvdWxkIGVycm9yCm91dC4KCklh
bi4KCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4t
ZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tCmh0dHA6Ly9s
aXN0cy54ZW5zb3VyY2UuY29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Fri Dec 23 09:32:03 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 Dec 2011 09:32:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Re1TY-000556-Cd; Fri, 23 Dec 2011 09:31:40 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Re1TX-000551-DP
	for xen-devel@lists.xensource.com; Fri, 23 Dec 2011 09:31:39 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1324632693!6452749!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2402 invoked from network); 23 Dec 2011 09:31:33 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-14.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 23 Dec 2011 09:31:33 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 23 Dec 2011 09:31:32 +0000
Message-Id: <4EF458BA0200007800069BB4@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 23 Dec 2011 09:32:26 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
References: <CAPLaKK506e57uCvSdkjCqkUs6AS6ty4Efa+Ekhrczu=OA+TCHw@mail.gmail.com>
	<4EF44A100200007800069B5A@nat28.tlf.novell.com>
	<1324632355.7877.96.camel@zakaz.uk.xensource.com>
In-Reply-To: <1324632355.7877.96.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: roger.pau@entel.upc.edu,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Stubdom build problem in 4.1.2 but not in
 xen-unstable
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 23.12.11 at 10:25, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> I thought "inline" was just a hint so it seems odd that gcc would error
> out.

That's what -Winline is for - to tell you that your intention to have a
function inlined wasn't fulfilled. If one asks for this warning,
occasionally having the compiler emit it is the result. The question to
me is what the purpose was to enable that warning in the first place.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 23 09:32:03 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 Dec 2011 09:32:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Re1TY-000556-Cd; Fri, 23 Dec 2011 09:31:40 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Re1TX-000551-DP
	for xen-devel@lists.xensource.com; Fri, 23 Dec 2011 09:31:39 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1324632693!6452749!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2402 invoked from network); 23 Dec 2011 09:31:33 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-14.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 23 Dec 2011 09:31:33 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 23 Dec 2011 09:31:32 +0000
Message-Id: <4EF458BA0200007800069BB4@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 23 Dec 2011 09:32:26 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
References: <CAPLaKK506e57uCvSdkjCqkUs6AS6ty4Efa+Ekhrczu=OA+TCHw@mail.gmail.com>
	<4EF44A100200007800069B5A@nat28.tlf.novell.com>
	<1324632355.7877.96.camel@zakaz.uk.xensource.com>
In-Reply-To: <1324632355.7877.96.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: roger.pau@entel.upc.edu,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Stubdom build problem in 4.1.2 but not in
 xen-unstable
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 23.12.11 at 10:25, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> I thought "inline" was just a hint so it seems odd that gcc would error
> out.

That's what -Winline is for - to tell you that your intention to have a
function inlined wasn't fulfilled. If one asks for this warning,
occasionally having the compiler emit it is the result. The question to
me is what the purpose was to enable that warning in the first place.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 23 09:43:51 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 Dec 2011 09:43:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Re1ex-0005GV-K1; Fri, 23 Dec 2011 09:43:27 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Re1ew-0005GQ-6C
	for xen-devel@lists.xensource.com; Fri, 23 Dec 2011 09:43:26 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1324633399!8507276!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODA5Ng==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22238 invoked from network); 23 Dec 2011 09:43:19 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Dec 2011 09:43:19 -0000
X-IronPort-AV: E=Sophos;i="4.71,398,1320624000"; 
   d="scan'208";a="9649015"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Dec 2011 09:43:18 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 23 Dec 2011 09:43:18 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>, Samuel Thibault
	<samuel.thibault@ens-lyon.org>
Date: Fri, 23 Dec 2011 09:43:17 +0000
In-Reply-To: <4EF458BA0200007800069BB4@nat28.tlf.novell.com>
References: <CAPLaKK506e57uCvSdkjCqkUs6AS6ty4Efa+Ekhrczu=OA+TCHw@mail.gmail.com>
	<4EF44A100200007800069B5A@nat28.tlf.novell.com>
	<1324632355.7877.96.camel@zakaz.uk.xensource.com>
	<4EF458BA0200007800069BB4@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1324633398.7877.109.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "roger.pau@entel.upc.edu" <roger.pau@entel.upc.edu>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Stubdom build problem in 4.1.2 but not in
 xen-unstable
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2011-12-23 at 09:32 +0000, Jan Beulich wrote:
> >>> On 23.12.11 at 10:25, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > I thought "inline" was just a hint so it seems odd that gcc would error
> > out.
> 
> That's what -Winline is for - to tell you that your intention to have a
> function inlined wasn't fulfilled. If one asks for this warning,
> occasionally having the compiler emit it is the result. The question to
> me is what the purpose was to enable that warning in the first place.

It seems to be only extras/mini-os which uses it and it came from the
first changeset, copy Samuel in case he remembers why.

Whatever the reason this specific instance is surely not worth force
inlining.

Linux uses __attribute__((always_inline)) and various similar
constructs, presumably to work around varying behaviours across gcc's.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 23 09:43:51 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 Dec 2011 09:43:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Re1ex-0005GV-K1; Fri, 23 Dec 2011 09:43:27 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Re1ew-0005GQ-6C
	for xen-devel@lists.xensource.com; Fri, 23 Dec 2011 09:43:26 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1324633399!8507276!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODA5Ng==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22238 invoked from network); 23 Dec 2011 09:43:19 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Dec 2011 09:43:19 -0000
X-IronPort-AV: E=Sophos;i="4.71,398,1320624000"; 
   d="scan'208";a="9649015"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Dec 2011 09:43:18 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 23 Dec 2011 09:43:18 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>, Samuel Thibault
	<samuel.thibault@ens-lyon.org>
Date: Fri, 23 Dec 2011 09:43:17 +0000
In-Reply-To: <4EF458BA0200007800069BB4@nat28.tlf.novell.com>
References: <CAPLaKK506e57uCvSdkjCqkUs6AS6ty4Efa+Ekhrczu=OA+TCHw@mail.gmail.com>
	<4EF44A100200007800069B5A@nat28.tlf.novell.com>
	<1324632355.7877.96.camel@zakaz.uk.xensource.com>
	<4EF458BA0200007800069BB4@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1324633398.7877.109.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "roger.pau@entel.upc.edu" <roger.pau@entel.upc.edu>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Stubdom build problem in 4.1.2 but not in
 xen-unstable
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2011-12-23 at 09:32 +0000, Jan Beulich wrote:
> >>> On 23.12.11 at 10:25, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > I thought "inline" was just a hint so it seems odd that gcc would error
> > out.
> 
> That's what -Winline is for - to tell you that your intention to have a
> function inlined wasn't fulfilled. If one asks for this warning,
> occasionally having the compiler emit it is the result. The question to
> me is what the purpose was to enable that warning in the first place.

It seems to be only extras/mini-os which uses it and it came from the
first changeset, copy Samuel in case he remembers why.

Whatever the reason this specific instance is surely not worth force
inlining.

Linux uses __attribute__((always_inline)) and various similar
constructs, presumably to work around varying behaviours across gcc's.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 23 09:54:05 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 Dec 2011 09:54:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Re1oo-0005QT-Mo; Fri, 23 Dec 2011 09:53:38 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pankaj.kumarbiswas@citrix.com>) id 1Re1om-0005QO-Rj
	for xen-devel@lists.xensource.com; Fri, 23 Dec 2011 09:53:37 +0000
X-Env-Sender: pankaj.kumarbiswas@citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1324634006!6635738!1
X-Originating-IP: [203.166.19.134]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjAzLjE2Ni4xOS4xMzQgPT4gNDE5ODk=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1263 invoked from network); 23 Dec 2011 09:53:30 -0000
Received: from smtp.citrix.com.au (HELO SMTP.CITRIX.COM.AU) (203.166.19.134)
	by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Dec 2011 09:53:30 -0000
X-IronPort-AV: E=Sophos;i="4.71,398,1320624000"; d="scan'208,217";a="9705704"
Received: from banpmailmx01.citrite.net ([10.103.128.73])
	by SYDPIPO01.CITRIX.COM.AU with ESMTP/TLS/RC4-MD5;
	23 Dec 2011 09:53:25 +0000
Received: from BANPMAILBOX01.citrite.net ([10.103.128.71]) by
	BANPMAILMX01.citrite.net ([10.103.128.73]) with mapi; Fri, 23 Dec 2011
	15:23:24 +0530
From: Pankaj Kumar Biswas <pankaj.kumarbiswas@citrix.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Fri, 23 Dec 2011 15:23:23 +0530
Thread-Topic: Re: balloning errors by XENUTIL
Thread-Index: AczBWIEGuIWZ6ledQROsZ6VnfqJ55g==
Message-ID: <64FB1554ABC9B44FAA773FBD6CB889C2F91230DA02@BANPMAILBOX01.citrite.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Subject: Re: [Xen-devel] balloning errors by XENUTIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============4808273252432381724=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============4808273252432381724==
Content-Language: en-US
Content-Type: multipart/alternative;
	boundary="_000_64FB1554ABC9B44FAA773FBD6CB889C2F91230DA02BANPMAILBOX01_"

--_000_64FB1554ABC9B44FAA773FBD6CB889C2F91230DA02BANPMAILBOX01_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi team.

Can somebody explain what the following message indicates:

Dec 21 15:57:14 xc6 fe: qemu-dm-108[3198]:  XENUTIL  Warning  BalloonPodSwe=
ep: HYPERVISOR_memory_op(XENMEM_pod_sweep, ...) failed (ffffffda)


Thanks & Regards,
PANKAJ KUMAR BISWAS


--_000_64FB1554ABC9B44FAA773FBD6CB889C2F91230DA02BANPMAILBOX01_
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=3DGenerator content=3D"Micros=
oft Word 14 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
	{font-family:Cambria;
	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;}
/* 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=3DEN-US link=3Dblue vli=
nk=3Dpurple><div class=3DWordSection1><p class=3DMsoNormal>Hi team.<o:p></o=
:p></p><p class=3DMsoNormal><o:p>&nbsp;</o:p></p><p class=3DMsoNormal>Can s=
omebody explain what the following message indicates:<o:p></o:p></p><p clas=
s=3DMsoNormal><o:p>&nbsp;</o:p></p><p class=3DMsoNormal style=3D'text-autos=
pace:none'><b><i>Dec 21 15:57:14 xc6 fe: qemu-dm-108[3198]:&nbsp; XENUTIL&n=
bsp; Warning&nbsp; BalloonPodSweep: HYPERVISOR_memory_op(XENMEM_pod_sweep, =
...) failed (ffffffda)<o:p></o:p></i></b></p><p class=3DMsoNormal style=3D'=
text-autospace:none'><b><i><o:p>&nbsp;</o:p></i></b></p><p class=3DMsoNorma=
l><o:p>&nbsp;</o:p></p><p class=3DMsoNormal><b><span style=3D'font-family:"=
Cambria","serif"'>Thanks &amp; Regards,<o:p></o:p></span></b></p><p class=
=3DMsoNormal><b><span style=3D'font-family:"Cambria","serif"'>PANKAJ KUMAR =
BISWAS<o:p></o:p></span></b></p><p class=3DMsoNormal><b><span style=3D'font=
-family:"Cambria","serif"'><o:p>&nbsp;</o:p></span></b></p></div></body></h=
tml>=

--_000_64FB1554ABC9B44FAA773FBD6CB889C2F91230DA02BANPMAILBOX01_--


--===============4808273252432381724==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============4808273252432381724==--


From xen-devel-bounces@lists.xensource.com Fri Dec 23 09:54:05 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 Dec 2011 09:54:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Re1oo-0005QT-Mo; Fri, 23 Dec 2011 09:53:38 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pankaj.kumarbiswas@citrix.com>) id 1Re1om-0005QO-Rj
	for xen-devel@lists.xensource.com; Fri, 23 Dec 2011 09:53:37 +0000
X-Env-Sender: pankaj.kumarbiswas@citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1324634006!6635738!1
X-Originating-IP: [203.166.19.134]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjAzLjE2Ni4xOS4xMzQgPT4gNDE5ODk=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1263 invoked from network); 23 Dec 2011 09:53:30 -0000
Received: from smtp.citrix.com.au (HELO SMTP.CITRIX.COM.AU) (203.166.19.134)
	by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Dec 2011 09:53:30 -0000
X-IronPort-AV: E=Sophos;i="4.71,398,1320624000"; d="scan'208,217";a="9705704"
Received: from banpmailmx01.citrite.net ([10.103.128.73])
	by SYDPIPO01.CITRIX.COM.AU with ESMTP/TLS/RC4-MD5;
	23 Dec 2011 09:53:25 +0000
Received: from BANPMAILBOX01.citrite.net ([10.103.128.71]) by
	BANPMAILMX01.citrite.net ([10.103.128.73]) with mapi; Fri, 23 Dec 2011
	15:23:24 +0530
From: Pankaj Kumar Biswas <pankaj.kumarbiswas@citrix.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Fri, 23 Dec 2011 15:23:23 +0530
Thread-Topic: Re: balloning errors by XENUTIL
Thread-Index: AczBWIEGuIWZ6ledQROsZ6VnfqJ55g==
Message-ID: <64FB1554ABC9B44FAA773FBD6CB889C2F91230DA02@BANPMAILBOX01.citrite.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Subject: Re: [Xen-devel] balloning errors by XENUTIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============4808273252432381724=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============4808273252432381724==
Content-Language: en-US
Content-Type: multipart/alternative;
	boundary="_000_64FB1554ABC9B44FAA773FBD6CB889C2F91230DA02BANPMAILBOX01_"

--_000_64FB1554ABC9B44FAA773FBD6CB889C2F91230DA02BANPMAILBOX01_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi team.

Can somebody explain what the following message indicates:

Dec 21 15:57:14 xc6 fe: qemu-dm-108[3198]:  XENUTIL  Warning  BalloonPodSwe=
ep: HYPERVISOR_memory_op(XENMEM_pod_sweep, ...) failed (ffffffda)


Thanks & Regards,
PANKAJ KUMAR BISWAS


--_000_64FB1554ABC9B44FAA773FBD6CB889C2F91230DA02BANPMAILBOX01_
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=3DGenerator content=3D"Micros=
oft Word 14 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
	{font-family:Cambria;
	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;}
/* 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=3DEN-US link=3Dblue vli=
nk=3Dpurple><div class=3DWordSection1><p class=3DMsoNormal>Hi team.<o:p></o=
:p></p><p class=3DMsoNormal><o:p>&nbsp;</o:p></p><p class=3DMsoNormal>Can s=
omebody explain what the following message indicates:<o:p></o:p></p><p clas=
s=3DMsoNormal><o:p>&nbsp;</o:p></p><p class=3DMsoNormal style=3D'text-autos=
pace:none'><b><i>Dec 21 15:57:14 xc6 fe: qemu-dm-108[3198]:&nbsp; XENUTIL&n=
bsp; Warning&nbsp; BalloonPodSweep: HYPERVISOR_memory_op(XENMEM_pod_sweep, =
...) failed (ffffffda)<o:p></o:p></i></b></p><p class=3DMsoNormal style=3D'=
text-autospace:none'><b><i><o:p>&nbsp;</o:p></i></b></p><p class=3DMsoNorma=
l><o:p>&nbsp;</o:p></p><p class=3DMsoNormal><b><span style=3D'font-family:"=
Cambria","serif"'>Thanks &amp; Regards,<o:p></o:p></span></b></p><p class=
=3DMsoNormal><b><span style=3D'font-family:"Cambria","serif"'>PANKAJ KUMAR =
BISWAS<o:p></o:p></span></b></p><p class=3DMsoNormal><b><span style=3D'font=
-family:"Cambria","serif"'><o:p>&nbsp;</o:p></span></b></p></div></body></h=
tml>=

--_000_64FB1554ABC9B44FAA773FBD6CB889C2F91230DA02BANPMAILBOX01_--


--===============4808273252432381724==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============4808273252432381724==--


From xen-devel-bounces@lists.xensource.com Fri Dec 23 10:21:37 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 Dec 2011 10:21:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Re2FY-0005ig-2c; Fri, 23 Dec 2011 10:21:16 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1Re2FW-0005iY-Nn
	for xen-devel@lists.xensource.com; Fri, 23 Dec 2011 10:21:14 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1324635667!6671506!1
X-Originating-IP: [143.182.124.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjE1NTc5\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14737 invoked from network); 23 Dec 2011 10:21:08 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-7.tower-174.messagelabs.com with SMTP;
	23 Dec 2011 10:21:08 -0000
Received: from azsmga002.ch.intel.com ([10.2.17.35])
	by azsmga101.ch.intel.com with ESMTP; 23 Dec 2011 02:21:07 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="50054896"
Received: from pgsmsx601.gar.corp.intel.com ([10.221.43.69])
	by AZSMGA002.ch.intel.com with ESMTP; 23 Dec 2011 02:21:06 -0800
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	pgsmsx601.gar.corp.intel.com (10.221.43.69) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Fri, 23 Dec 2011 18:20:28 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.38]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.199]) with mapi id
	14.01.0355.002; Fri, 23 Dec 2011 18:20:26 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
Thread-Topic: [Xen-devel] Linux 3.1.0 Xen RAS rebase
Thread-Index: AQHMwR/TW8DpiUUASEeT9gUPm1anxpXo9axggABAbOA=
Date: Fri, 23 Dec 2011 10:20:26 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC82923359662@SHSMSX101.ccr.corp.intel.com>
References: <DE8DF0795D48FD4CA783C40EC829233587C7@SHSMSX101.ccr.corp.intel.com>
	<20111223030608.GB7218@andromeda.dapyr.net>
	<DE8DF0795D48FD4CA783C40EC8292335943F@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <DE8DF0795D48FD4CA783C40EC8292335943F@SHSMSX101.ccr.corp.intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "Luck, Tony" <tony.luck@intel.com>, "Brown, Len" <len.brown@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>, "Jiang, 
	Yunhong" <yunhong.jiang@intel.com>,
	Kernel development list <linux-kernel@vger.kernel.org>, "Zhao, 
	Yakui" <yakui.zhao@intel.com>,
	"jeremy.fitzhardinge@citrix.com" <jeremy.fitzhardinge@citrix.com>, "Kleen, 
	Andi" <andi.kleen@intel.com>
Subject: Re: [Xen-devel] Linux 3.1.0 Xen RAS rebase
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Liu, Jinsong wrote:
> Konrad Rzeszutek Wilk wrote:
>> On Thu, Dec 22, 2011 at 09:57:55AM +0000, Liu, Jinsong wrote:
>>> Recently we did dom0 Xen RAS rebase work.
>> 
>> Hey Liu,
>> 
>> Thank you for posting this. Couple of questions:
>>  1). How does one test these patches?
> 
> These patches include mce, cpu online/offline, cpu hotadd, memory
> hotadd. 
> Testing method of these features are
> 1. mce: a normal way is to inject error through EINJ user interface,
> and getting mcelog at dom0 side 
> 2. cpu online/offline: by echoing sysfs/.../xen_pcpu user interface,
> and getting result at sysfs/.../xen_pcpu 
> 3. cpu hotadd: Intel has some new server, by pressing a button can
> add cpu. We can verify cpu hotadd by sysfs/.../xen_pcpu interface 
> 4. memory hotadd: also by pressing a button to add memory, and can
> verify memory hotadd by 'xl info' 
> 
>>  2). Please CC LKML and also the ACPI maintainer - since a majority
>>      of this also touch their tree. And the memory hotadd maintainer
>>      as well.
> 
> OK, cc
> LKML
> ACPI maintainer: len.brown@intel.com
> memory hotadd maintianer: I'm not sure who is maintainer, but I will
> cc yakui.zhao@intel.com and len.brown@intel.com 

Will also cc Tony Luck and Andi Kleen, mce maintainers.

> 
> I'll re-send the patches later, cc above people.
> 
>>  3). Can any of this code (like the MCE) leverage the existing
>>      generic code?
> 
> Basically no, for mce, xen implement mce logic at hypervisor,
> at dom0 side, it only add mcelog interface to get log from hypervisor
> and transfer to kernel mcelog format. 
> 
>>  4). Have you guys talked with Len Brown (the ACPI maintainer)
>>      about some of this code and how to make it fit within his
>>      goals?
> 
> Not yet, but will.
> 
> Thanks,
> Jinsong
> 
>> 
>> Thanks!
>>> 
>>> Basically it rebased from Jeremy's pvops (2.6.32), to Konrad's pvops
>>> (3.1.0, branch "devel/acpi-cpufreq.v3") patch 1: for mcelog logic
>>> patch 2: for dom0 vmce patch 3: for cpu sysfs and cpu online/offline
>>> patch 4: for cpu hotadd
>>> patch 5: for memory hotadd prepare work
>>> patch 6: for memory hotadd
>>> patch 7: for cpu hotadd prepare work
>>> patch 8: complement cpu hotadd lacked at Konrad's tree
>>> patch 9: update PM logic
>>> patch 10: upate cpu online/offline logic
>>> 
>>> 
>>> Thanks,
>>> Jinsong
>>> _______________________________________________
>>> Xen-devel mailing list
>>> Xen-devel@lists.xensource.com
>>> http://lists.xensource.com/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 23 10:21:37 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 Dec 2011 10:21:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Re2FY-0005ig-2c; Fri, 23 Dec 2011 10:21:16 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1Re2FW-0005iY-Nn
	for xen-devel@lists.xensource.com; Fri, 23 Dec 2011 10:21:14 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1324635667!6671506!1
X-Originating-IP: [143.182.124.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjE1NTc5\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14737 invoked from network); 23 Dec 2011 10:21:08 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-7.tower-174.messagelabs.com with SMTP;
	23 Dec 2011 10:21:08 -0000
Received: from azsmga002.ch.intel.com ([10.2.17.35])
	by azsmga101.ch.intel.com with ESMTP; 23 Dec 2011 02:21:07 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="50054896"
Received: from pgsmsx601.gar.corp.intel.com ([10.221.43.69])
	by AZSMGA002.ch.intel.com with ESMTP; 23 Dec 2011 02:21:06 -0800
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	pgsmsx601.gar.corp.intel.com (10.221.43.69) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Fri, 23 Dec 2011 18:20:28 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.38]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.199]) with mapi id
	14.01.0355.002; Fri, 23 Dec 2011 18:20:26 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
Thread-Topic: [Xen-devel] Linux 3.1.0 Xen RAS rebase
Thread-Index: AQHMwR/TW8DpiUUASEeT9gUPm1anxpXo9axggABAbOA=
Date: Fri, 23 Dec 2011 10:20:26 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC82923359662@SHSMSX101.ccr.corp.intel.com>
References: <DE8DF0795D48FD4CA783C40EC829233587C7@SHSMSX101.ccr.corp.intel.com>
	<20111223030608.GB7218@andromeda.dapyr.net>
	<DE8DF0795D48FD4CA783C40EC8292335943F@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <DE8DF0795D48FD4CA783C40EC8292335943F@SHSMSX101.ccr.corp.intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "Luck, Tony" <tony.luck@intel.com>, "Brown, Len" <len.brown@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>, "Jiang, 
	Yunhong" <yunhong.jiang@intel.com>,
	Kernel development list <linux-kernel@vger.kernel.org>, "Zhao, 
	Yakui" <yakui.zhao@intel.com>,
	"jeremy.fitzhardinge@citrix.com" <jeremy.fitzhardinge@citrix.com>, "Kleen, 
	Andi" <andi.kleen@intel.com>
Subject: Re: [Xen-devel] Linux 3.1.0 Xen RAS rebase
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Liu, Jinsong wrote:
> Konrad Rzeszutek Wilk wrote:
>> On Thu, Dec 22, 2011 at 09:57:55AM +0000, Liu, Jinsong wrote:
>>> Recently we did dom0 Xen RAS rebase work.
>> 
>> Hey Liu,
>> 
>> Thank you for posting this. Couple of questions:
>>  1). How does one test these patches?
> 
> These patches include mce, cpu online/offline, cpu hotadd, memory
> hotadd. 
> Testing method of these features are
> 1. mce: a normal way is to inject error through EINJ user interface,
> and getting mcelog at dom0 side 
> 2. cpu online/offline: by echoing sysfs/.../xen_pcpu user interface,
> and getting result at sysfs/.../xen_pcpu 
> 3. cpu hotadd: Intel has some new server, by pressing a button can
> add cpu. We can verify cpu hotadd by sysfs/.../xen_pcpu interface 
> 4. memory hotadd: also by pressing a button to add memory, and can
> verify memory hotadd by 'xl info' 
> 
>>  2). Please CC LKML and also the ACPI maintainer - since a majority
>>      of this also touch their tree. And the memory hotadd maintainer
>>      as well.
> 
> OK, cc
> LKML
> ACPI maintainer: len.brown@intel.com
> memory hotadd maintianer: I'm not sure who is maintainer, but I will
> cc yakui.zhao@intel.com and len.brown@intel.com 

Will also cc Tony Luck and Andi Kleen, mce maintainers.

> 
> I'll re-send the patches later, cc above people.
> 
>>  3). Can any of this code (like the MCE) leverage the existing
>>      generic code?
> 
> Basically no, for mce, xen implement mce logic at hypervisor,
> at dom0 side, it only add mcelog interface to get log from hypervisor
> and transfer to kernel mcelog format. 
> 
>>  4). Have you guys talked with Len Brown (the ACPI maintainer)
>>      about some of this code and how to make it fit within his
>>      goals?
> 
> Not yet, but will.
> 
> Thanks,
> Jinsong
> 
>> 
>> Thanks!
>>> 
>>> Basically it rebased from Jeremy's pvops (2.6.32), to Konrad's pvops
>>> (3.1.0, branch "devel/acpi-cpufreq.v3") patch 1: for mcelog logic
>>> patch 2: for dom0 vmce patch 3: for cpu sysfs and cpu online/offline
>>> patch 4: for cpu hotadd
>>> patch 5: for memory hotadd prepare work
>>> patch 6: for memory hotadd
>>> patch 7: for cpu hotadd prepare work
>>> patch 8: complement cpu hotadd lacked at Konrad's tree
>>> patch 9: update PM logic
>>> patch 10: upate cpu online/offline logic
>>> 
>>> 
>>> Thanks,
>>> Jinsong
>>> _______________________________________________
>>> Xen-devel mailing list
>>> Xen-devel@lists.xensource.com
>>> http://lists.xensource.com/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 23 10:22:16 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 Dec 2011 10: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.xensource.com>)
	id 1Re2G9-0005kK-GQ; Fri, 23 Dec 2011 10:21:53 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1Re2G8-0005k4-Gm
	for xen-devel@lists.xensource.com; Fri, 23 Dec 2011 10:21:52 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1324635705!8401946!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMjkwNzg3\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30659 invoked from network); 23 Dec 2011 10:21:46 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-14.tower-182.messagelabs.com with SMTP;
	23 Dec 2011 10:21:46 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga101.jf.intel.com with ESMTP; 23 Dec 2011 02:21:45 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.67,351,1309762800"; d="scan'208";a="90820928"
Received: from pgsmsx603.gar.corp.intel.com ([10.221.43.87])
	by orsmga002.jf.intel.com with ESMTP; 23 Dec 2011 02:21:44 -0800
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	pgsmsx603.gar.corp.intel.com (10.221.43.87) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Fri, 23 Dec 2011 18:21:28 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.38]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.199]) with mapi id
	14.01.0355.002; Fri, 23 Dec 2011 18:21:26 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: "konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
Thread-Topic: [PATCH 00/10] Linux 3.1.0 Xen RAS rebase
Thread-Index: AczBXKB0mag++cqVSzS+PvJp33blKQ==
Date: Fri, 23 Dec 2011 10:21:26 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC82923359674@SHSMSX101.ccr.corp.intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "Brown, Len" <len.brown@intel.com>,
	"jeremy.fitzhardinge@citrix.com" <jeremy.fitzhardinge@citrix.com>,
	"Jiang, Yunhong" <yunhong.jiang@intel.com>, "Shan, 
	Haitao" <haitao.shan@intel.com>,
	Kernel development list <linux-kernel@vger.kernel.org>, "Zhao,
	Yakui" <yakui.zhao@intel.com>, "Luck, Tony" <tony.luck@intel.com>, "Kleen,
	Andi" <andi.kleen@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: [Xen-devel] [PATCH 00/10] Linux 3.1.0 Xen RAS rebase
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Recently we did dom0 Xen RAS rebase work, mainly involve xen interface at kernel for following features:
1). mce
2). cpu online/offline
3). cpu hotadd
4). memory hotadd

Basically it rebased from Jeremy's pvops (2.6.32), to Konrad's pvops (3.1.0, branch "devel/acpi-cpufreq.v3")
patch 1: for mcelog logic
patch 2: for dom0 vmce
patch 3: for cpu sysfs and cpu online/offline
patch 4: for cpu hotadd
patch 5: for memory hotadd prepare work
patch 6: for memory hotadd
patch 7: for cpu hotadd prepare work
patch 8: complement cpu hotadd lacked at Konrad's tree
patch 9: update PM logic
patch 10: upate cpu online/offline logic


Thanks,
Jinsong
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 23 10:22:16 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 Dec 2011 10: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.xensource.com>)
	id 1Re2G9-0005kK-GQ; Fri, 23 Dec 2011 10:21:53 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1Re2G8-0005k4-Gm
	for xen-devel@lists.xensource.com; Fri, 23 Dec 2011 10:21:52 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1324635705!8401946!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMjkwNzg3\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30659 invoked from network); 23 Dec 2011 10:21:46 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-14.tower-182.messagelabs.com with SMTP;
	23 Dec 2011 10:21:46 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga101.jf.intel.com with ESMTP; 23 Dec 2011 02:21:45 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.67,351,1309762800"; d="scan'208";a="90820928"
Received: from pgsmsx603.gar.corp.intel.com ([10.221.43.87])
	by orsmga002.jf.intel.com with ESMTP; 23 Dec 2011 02:21:44 -0800
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	pgsmsx603.gar.corp.intel.com (10.221.43.87) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Fri, 23 Dec 2011 18:21:28 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.38]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.199]) with mapi id
	14.01.0355.002; Fri, 23 Dec 2011 18:21:26 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: "konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
Thread-Topic: [PATCH 00/10] Linux 3.1.0 Xen RAS rebase
Thread-Index: AczBXKB0mag++cqVSzS+PvJp33blKQ==
Date: Fri, 23 Dec 2011 10:21:26 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC82923359674@SHSMSX101.ccr.corp.intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "Brown, Len" <len.brown@intel.com>,
	"jeremy.fitzhardinge@citrix.com" <jeremy.fitzhardinge@citrix.com>,
	"Jiang, Yunhong" <yunhong.jiang@intel.com>, "Shan, 
	Haitao" <haitao.shan@intel.com>,
	Kernel development list <linux-kernel@vger.kernel.org>, "Zhao,
	Yakui" <yakui.zhao@intel.com>, "Luck, Tony" <tony.luck@intel.com>, "Kleen,
	Andi" <andi.kleen@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: [Xen-devel] [PATCH 00/10] Linux 3.1.0 Xen RAS rebase
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Recently we did dom0 Xen RAS rebase work, mainly involve xen interface at kernel for following features:
1). mce
2). cpu online/offline
3). cpu hotadd
4). memory hotadd

Basically it rebased from Jeremy's pvops (2.6.32), to Konrad's pvops (3.1.0, branch "devel/acpi-cpufreq.v3")
patch 1: for mcelog logic
patch 2: for dom0 vmce
patch 3: for cpu sysfs and cpu online/offline
patch 4: for cpu hotadd
patch 5: for memory hotadd prepare work
patch 6: for memory hotadd
patch 7: for cpu hotadd prepare work
patch 8: complement cpu hotadd lacked at Konrad's tree
patch 9: update PM logic
patch 10: upate cpu online/offline logic


Thanks,
Jinsong
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 23 10:24:02 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 Dec 2011 10: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.xensource.com>)
	id 1Re2Hv-0005sJ-1B; Fri, 23 Dec 2011 10:23:43 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1Re2Ht-0005rl-7c
	for xen-devel@lists.xensource.com; Fri, 23 Dec 2011 10:23:41 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1324635812!8564672!1
X-Originating-IP: [143.182.124.37]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjE2NTAw\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7187 invoked from network); 23 Dec 2011 10:23:33 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37)
	by server-8.tower-216.messagelabs.com with SMTP;
	23 Dec 2011 10:23:33 -0000
Received: from azsmga002.ch.intel.com ([10.2.17.35])
	by azsmga102.ch.intel.com with ESMTP; 23 Dec 2011 02:23:32 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208,223";a="50055368"
Received: from pgsmsx601.gar.corp.intel.com ([10.221.43.69])
	by AZSMGA002.ch.intel.com with ESMTP; 23 Dec 2011 02:23:29 -0800
Received: from pgsmsx102.gar.corp.intel.com (10.221.44.80) by
	pgsmsx601.gar.corp.intel.com (10.221.43.69) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Fri, 23 Dec 2011 18:23:06 +0800
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	PGSMSX102.gar.corp.intel.com (10.221.44.80) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Fri, 23 Dec 2011 18:23:05 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.38]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.199]) with mapi id
	14.01.0355.002; Fri, 23 Dec 2011 18:23:04 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: "konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
Thread-Topic: [PATCH 01/10] Add mcelog support from xen platform
Thread-Index: AczBXNo5kd/dViAgSKaxIwYWg4rVzQ==
Date: Fri, 23 Dec 2011 10:23:03 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC82923359699@SHSMSX101.ccr.corp.intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
Content-Type: multipart/mixed;
	boundary="_002_DE8DF0795D48FD4CA783C40EC82923359699SHSMSX101ccrcorpint_"
MIME-Version: 1.0
Cc: "Brown, Len" <len.brown@intel.com>,
	"jeremy.fitzhardinge@citrix.com" <jeremy.fitzhardinge@citrix.com>,
	"Jiang, Yunhong" <yunhong.jiang@intel.com>, "Shan, 
	Haitao" <haitao.shan@intel.com>,
	Kernel development list <linux-kernel@vger.kernel.org>, "Zhao,
	Yakui" <yakui.zhao@intel.com>, "Luck, Tony" <tony.luck@intel.com>, "Kleen,
	Andi" <andi.kleen@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: [Xen-devel] [PATCH 01/10] Add mcelog support from xen platform
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--_002_DE8DF0795D48FD4CA783C40EC82923359699SHSMSX101ccrcorpint_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

>From 0e8de1ce0f13aa34aa6013e6a387ae5be78031ca Mon Sep 17 00:00:00 2001
From: Liu Jinsong <jinsong.liu@intel.com>
Date: Tue, 6 Dec 2011 18:08:12 +0800
Subject: [PATCH 01/10] Add mcelog support from xen platform

This patch backport from Jeremy's pvops commit a5ed1f3dae179158e385e9371462=
dd65d5e125c5,
which in turn backport from previous xen DOM0(2.6.18) cs: 75e5bfa7fbdc

When a MCE/CMCI error happens (or by polling), the related error
information will be sent to privileged pv-ops domain by XEN. This
patch will help to fetch the xen-logged information by hypercall
and then convert XEN-format log into Linux format MCELOG. It makes
using current available mcelog tools for native Linux possible.

With this patch, after mce/cmci error log information is sent to
pv-ops guest, Running mcelog tools in the guest, you will get same
detailed decoded mce information as in Native Linux.

Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
Signed-off-by: Ke, Liping <liping.ke@intel.com>
Signed-off-by: Jiang, Yunhong <yunhong.jiang@intel.com>
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
---
 arch/x86/include/asm/xen/hypercall.h |    8 +
 arch/x86/xen/enlighten.c             |    8 +-
 drivers/xen/Kconfig                  |    8 +
 drivers/xen/Makefile                 |    1 +
 drivers/xen/mcelog.c                 |  217 +++++++++++++++++
 include/xen/interface/xen-mca.h      |  429 ++++++++++++++++++++++++++++++=
++++
 6 files changed, 667 insertions(+), 4 deletions(-)
 create mode 100644 drivers/xen/mcelog.c
 create mode 100644 include/xen/interface/xen-mca.h

diff --git a/arch/x86/include/asm/xen/hypercall.h b/arch/x86/include/asm/xe=
n/hypercall.h
index 5728852..59c226d 100644
--- a/arch/x86/include/asm/xen/hypercall.h
+++ b/arch/x86/include/asm/xen/hypercall.h
@@ -48,6 +48,7 @@
 #include <xen/interface/sched.h>
 #include <xen/interface/physdev.h>
 #include <xen/interface/platform.h>
+#include <xen/interface/xen-mca.h>
=20
 /*
  * The hypercall asms have to meet several constraints:
@@ -302,6 +303,13 @@ HYPERVISOR_set_timer_op(u64 timeout)
 }
=20
 static inline int
+HYPERVISOR_mca(struct xen_mc *mc_op)
+{
+	mc_op->interface_version =3D XEN_MCA_INTERFACE_VERSION;
+	return _hypercall1(int, mca, mc_op);
+}
+
+static inline int
 HYPERVISOR_dom0_op(struct xen_platform_op *platform_op)
 {
 	platform_op->interface_version =3D XENPF_INTERFACE_VERSION;
diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index 9306320..b073e4c 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -242,14 +242,14 @@ static void __init xen_init_cpuid_mask(void)
 	unsigned int xsave_mask;
=20
 	cpuid_leaf1_edx_mask =3D
-		~((1 << X86_FEATURE_MCE)  |  /* disable MCE */
-		  (1 << X86_FEATURE_MCA)  |  /* disable MCA */
-		  (1 << X86_FEATURE_MTRR) |  /* disable MTRR */
+		~((1 << X86_FEATURE_MTRR) |  /* disable MTRR */
 		  (1 << X86_FEATURE_ACC));   /* thermal monitoring */
=20
 	if (!xen_initial_domain())
 		cpuid_leaf1_edx_mask &=3D
-			~((1 << X86_FEATURE_APIC) |  /* disable local APIC */
+			~((1 << X86_FEATURE_MCE)  |  /* disable MCE */
+			  (1 << X86_FEATURE_MCA)  |  /* disable MCA */
+			  (1 << X86_FEATURE_APIC) |  /* disable local APIC */
 			  (1 << X86_FEATURE_ACPI));  /* disable ACPI */
 	ax =3D 1;
 	xen_cpuid(&ax, &bx, &cx, &dx);
diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
index e8fb85f..eb2a327 100644
--- a/drivers/xen/Kconfig
+++ b/drivers/xen/Kconfig
@@ -117,6 +117,14 @@ config XEN_SYS_HYPERVISOR
 	 virtual environment, /sys/hypervisor will still be present,
 	 but will have no xen contents.
=20
+config XEN_MCE_LOG
+	bool "Xen platform mcelog"
+	depends on XEN_DOM0 && X86_64 && X86_MCE
+	default y
+	help
+	  Allow kernel fetching mce log from xen platform and
+	  converting it into linux mcelog format for mcelog tools
+
 config ACPI_PROCESSOR_XEN
 	tristate
 	depends on XEN_DOM0 && ACPI_PROCESSOR && CPU_FREQ
diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
index d42da53..405cce9 100644
--- a/drivers/xen/Makefile
+++ b/drivers/xen/Makefile
@@ -14,6 +14,7 @@ obj-$(CONFIG_XEN_GNTDEV)		+=3D xen-gntdev.o
 obj-$(CONFIG_XEN_GRANT_DEV_ALLOC)	+=3D xen-gntalloc.o
 obj-$(CONFIG_XENFS)			+=3D xenfs/
 obj-$(CONFIG_XEN_SYS_HYPERVISOR)	+=3D sys-hypervisor.o
+obj-$(CONFIG_XEN_MCE_LOG)		+=3D mcelog.o
 obj-$(CONFIG_XEN_PLATFORM_PCI)		+=3D xen-platform-pci.o
 obj-$(CONFIG_XEN_TMEM)			+=3D tmem.o
 obj-$(CONFIG_SWIOTLB_XEN)		+=3D swiotlb-xen.o
diff --git a/drivers/xen/mcelog.c b/drivers/xen/mcelog.c
new file mode 100644
index 0000000..892ca7b
--- /dev/null
+++ b/drivers/xen/mcelog.c
@@ -0,0 +1,217 @@
+/*************************************************************************=
*****
+ * mcelog.c
+ * Add Machine Check event Logging support in DOM0
+ *
+ * Driver for receiving and logging machine check event
+ *
+ * Copyright (c) 2008, 2009 Intel Corporation
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version 2
+ * as published by the Free Software Foundation; or, when distributed
+ * separately from the Linux kernel or incorporated into other
+ * software packages, subject to the following license:
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a=
 copy
+ * of this source file (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use, copy, modi=
fy,
+ * merge, publish, distribute, sublicense, and/or sell copies of the Softw=
are,
+ * and to permit persons to whom the Software is furnished to do so, subje=
ct to
+ * the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included=
 in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS=
 OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY=
,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL=
 THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEA=
LINGS
+ * IN THE SOFTWARE.
+ */
+
+#include <linux/module.h>
+#include <linux/init.h>
+#include <linux/types.h>
+#include <linux/kernel.h>
+#include <linux/slab.h>
+#include <xen/interface/xen.h>
+#include <asm/xen/hypervisor.h>
+#include <xen/events.h>
+#include <xen/interface/vcpu.h>
+#include <asm/xen/hypercall.h>
+#include <asm/mce.h>
+#include <xen/xen.h>
+
+static mc_info_t *g_mi;
+static mcinfo_logical_cpu_t *g_physinfo;
+static uint32_t ncpus;
+
+static int convert_log(struct mc_info *mi)
+{
+	struct mcinfo_common *mic =3D NULL;
+	struct mcinfo_global *mc_global;
+	struct mcinfo_bank *mc_bank;
+	struct mce m;
+	int i, found =3D 0;
+
+	x86_mcinfo_lookup(&mic, mi, MC_TYPE_GLOBAL);
+	WARN_ON(!mic);
+
+	mce_setup(&m);
+	mc_global =3D (struct mcinfo_global *)mic;
+	m.mcgstatus =3D mc_global->mc_gstatus;
+	m.apicid =3D mc_global->mc_apicid;
+	for (i =3D 0; i < ncpus; i++) {
+		if (g_physinfo[i].mc_apicid =3D=3D m.apicid) {
+			found =3D 1;
+			break;
+		}
+	}
+	WARN_ON(!found);
+
+	m.socketid =3D g_physinfo[i].mc_chipid;
+	m.cpu =3D m.extcpu =3D g_physinfo[i].mc_cpunr;
+	m.cpuvendor =3D (__u8)g_physinfo[i].mc_vendor;
+	m.mcgcap =3D g_physinfo[i].mc_msrvalues[0].value;
+	x86_mcinfo_lookup(&mic, mi, MC_TYPE_BANK);
+	do {
+		if (mic =3D=3D NULL || mic->size =3D=3D 0)
+			break;
+		if (mic->type =3D=3D MC_TYPE_BANK) {
+			mc_bank =3D (struct mcinfo_bank *)mic;
+			m.misc =3D mc_bank->mc_misc;
+			m.status =3D mc_bank->mc_status;
+			m.addr =3D mc_bank->mc_addr;
+			m.tsc =3D mc_bank->mc_tsc;
+			m.bank =3D mc_bank->mc_bank;
+			m.finished =3D 1;
+			/*log this record*/
+			mce_log(&m);
+		}
+		mic =3D x86_mcinfo_next(mic);
+	} while (1);
+
+	return 0;
+}
+
+/*pv_ops domain mce virq handler, logging physical mce error info*/
+static irqreturn_t mce_dom_interrupt(int irq, void *dev_id)
+{
+	xen_mc_t mc_op;
+	int result =3D 0;
+
+	mc_op.cmd =3D XEN_MC_fetch;
+	mc_op.interface_version =3D XEN_MCA_INTERFACE_VERSION;
+	set_xen_guest_handle(mc_op.u.mc_fetch.data, g_mi);
+urgent:
+	mc_op.u.mc_fetch.flags =3D XEN_MC_URGENT;
+	result =3D HYPERVISOR_mca(&mc_op);
+	if (result || mc_op.u.mc_fetch.flags & XEN_MC_NODATA ||
+			mc_op.u.mc_fetch.flags & XEN_MC_FETCHFAILED)
+		goto nonurgent;
+	else {
+		result =3D convert_log(g_mi);
+		if (result)
+			goto end;
+		/* After fetching the error event log entry from DOM0,
+		 * we need to dec the refcnt and release the entry.
+		 * The entry is reserved and inc refcnt when filling
+		 * the error log entry.
+		 */
+		mc_op.u.mc_fetch.flags =3D XEN_MC_URGENT | XEN_MC_ACK;
+		result =3D HYPERVISOR_mca(&mc_op);
+		goto urgent;
+	}
+nonurgent:
+	mc_op.u.mc_fetch.flags =3D XEN_MC_NONURGENT;
+	result =3D HYPERVISOR_mca(&mc_op);
+	if (result || mc_op.u.mc_fetch.flags & XEN_MC_NODATA ||
+			mc_op.u.mc_fetch.flags & XEN_MC_FETCHFAILED)
+		goto end;
+	else {
+		result =3D convert_log(g_mi);
+		if (result)
+			goto end;
+		/* After fetching the error event log entry from DOM0,
+		 * we need to dec the refcnt and release the entry. The
+		 * entry is reserved and inc refcnt when filling the
+		 * error log entry.
+		 */
+		mc_op.u.mc_fetch.flags =3D XEN_MC_NONURGENT | XEN_MC_ACK;
+		result =3D HYPERVISOR_mca(&mc_op);
+		goto nonurgent;
+	}
+end:
+	return IRQ_HANDLED;
+}
+
+static int bind_virq_for_mce(void)
+{
+	int ret;
+	xen_mc_t mc_op;
+
+	g_mi =3D kmalloc(sizeof(struct mc_info), GFP_KERNEL);
+
+	if (!g_mi)
+		return -ENOMEM;
+
+	/* Fetch physical CPU Numbers */
+	mc_op.cmd =3D XEN_MC_physcpuinfo;
+	mc_op.interface_version =3D XEN_MCA_INTERFACE_VERSION;
+	set_xen_guest_handle(mc_op.u.mc_physcpuinfo.info, g_physinfo);
+	ret =3D HYPERVISOR_mca(&mc_op);
+	if (ret) {
+		printk(KERN_ERR "MCE_DOM0_LOG: Fail to get physical CPU numbers\n");
+		kfree(g_mi);
+		return ret;
+	}
+
+	/* Fetch each CPU Physical Info for later reference*/
+	ncpus =3D mc_op.u.mc_physcpuinfo.ncpus;
+	g_physinfo =3D kmalloc(sizeof(struct mcinfo_logical_cpu)*ncpus,
+					GFP_KERNEL);
+	if (!g_physinfo) {
+		kfree(g_mi);
+		return -ENOMEM;
+	}
+	set_xen_guest_handle(mc_op.u.mc_physcpuinfo.info, g_physinfo);
+	ret =3D HYPERVISOR_mca(&mc_op);
+	if (ret) {
+		printk(KERN_ERR "MCE_DOM0_LOG: Fail to get physical CPUs info\n");
+		kfree(g_mi);
+		kfree(g_physinfo);
+		return ret;
+	}
+
+	ret  =3D bind_virq_to_irqhandler(VIRQ_MCA, 0,
+		mce_dom_interrupt, 0, "mce", NULL);
+
+	if (ret < 0) {
+		printk(KERN_ERR "MCE_DOM0_LOG: bind_virq for DOM0 failed\n");
+		return ret;
+	}
+
+	return 0;
+}
+
+static int __init mcelog_init(void)
+{
+	/* Only DOM0 is responsible for MCE logging */
+	if (xen_initial_domain())
+		return bind_virq_for_mce();
+
+	return 0;
+}
+
+
+static void __exit mcelog_cleanup(void)
+{
+	kfree(g_mi);
+	kfree(g_physinfo);
+}
+module_init(mcelog_init);
+module_exit(mcelog_cleanup);
+
+MODULE_LICENSE("GPL");
diff --git a/include/xen/interface/xen-mca.h b/include/xen/interface/xen-mc=
a.h
new file mode 100644
index 0000000..f31fdab
--- /dev/null
+++ b/include/xen/interface/xen-mca.h
@@ -0,0 +1,429 @@
+/*************************************************************************=
*****
+ * arch-x86/mca.h
+ *
+ * Contributed by Advanced Micro Devices, Inc.
+ * Author: Christoph Egger <Christoph.Egger@amd.com>
+ *
+ * Guest OS machine check interface to x86 Xen.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a=
 copy
+ * of this software and associated documentation files (the "Software"), t=
o
+ * deal in the Software without restriction, including without limitation =
the
+ * rights to use, copy, modify, merge, publish, distribute, sublicense, an=
d/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.
+ */
+
+/* Full MCA functionality has the following Usecases from the guest side:
+ *
+ * Must have's:
+ * 1. Dom0 and DomU register machine check trap callback handlers
+ *    (already done via "set_trap_table" hypercall)
+ * 2. Dom0 registers machine check event callback handler
+ *    (doable via EVTCHNOP_bind_virq)
+ * 3. Dom0 and DomU fetches machine check data
+ * 4. Dom0 wants Xen to notify a DomU
+ * 5. Dom0 gets DomU ID from physical address
+ * 6. Dom0 wants Xen to kill DomU (already done for "xm destroy")
+ *
+ * Nice to have's:
+ * 7. Dom0 wants Xen to deactivate a physical CPU
+ *    This is better done as separate task, physical CPU hotplugging,
+ *    and hypercall(s) should be sysctl's
+ * 8. Page migration proposed from Xen NUMA work, where Dom0 can tell Xen =
to
+ *    move a DomU (or Dom0 itself) away from a malicious page
+ *    producing correctable errors.
+ * 9. offlining physical page:
+ *    Xen free's and never re-uses a certain physical page.
+ * 10. Testfacility: Allow Dom0 to write values into machine check MSR's
+ *     and tell Xen to trigger a machine check
+ */
+
+#ifndef __XEN_PUBLIC_ARCH_X86_MCA_H__
+#define __XEN_PUBLIC_ARCH_X86_MCA_H__
+
+/* Hypercall */
+#define __HYPERVISOR_mca __HYPERVISOR_arch_0
+
+/*
+ * The xen-unstable repo has interface version 0x03000001; out interface
+ * is incompatible with that and any future minor revisions, so we
+ * choose a different version number range that is numerically less
+ * than that used in xen-unstable.
+ */
+#define XEN_MCA_INTERFACE_VERSION 0x01ecc003
+
+/* IN: Dom0 calls hypercall to retrieve nonurgent error log entry */
+#define XEN_MC_NONURGENT  0x0001
+/* IN: Dom0/DomU calls hypercall to retrieve urgent error log entry */
+#define XEN_MC_URGENT     0x0002
+/* IN: Dom0 acknowledges previosly-fetched error log entry */
+#define XEN_MC_ACK        0x0004
+
+/* OUT: All is ok */
+#define XEN_MC_OK           0x0
+/* OUT: Domain could not fetch data. */
+#define XEN_MC_FETCHFAILED  0x1
+/* OUT: There was no machine check data to fetch. */
+#define XEN_MC_NODATA       0x2
+/* OUT: Between notification time and this hypercall an other
+ *  (most likely) correctable error happened. The fetched data,
+ *  does not match the original machine check data. */
+#define XEN_MC_NOMATCH      0x4
+
+/* OUT: DomU did not register MC NMI handler. Try something else. */
+#define XEN_MC_CANNOTHANDLE 0x8
+/* OUT: Notifying DomU failed. Retry later or try something else. */
+#define XEN_MC_NOTDELIVERED 0x10
+/* Note, XEN_MC_CANNOTHANDLE and XEN_MC_NOTDELIVERED are mutually exclusiv=
e. */
+
+
+#ifndef __ASSEMBLY__
+
+#define VIRQ_MCA VIRQ_ARCH_0 /* G. (DOM0) Machine Check Architecture */
+
+/*
+ * Machine Check Architecure:
+ * structs are read-only and used to report all kinds of
+ * correctable and uncorrectable errors detected by the HW.
+ * Dom0 and DomU: register a handler to get notified.
+ * Dom0 only: Correctable errors are reported via VIRQ_MCA
+ */
+#define MC_TYPE_GLOBAL          0
+#define MC_TYPE_BANK            1
+#define MC_TYPE_EXTENDED        2
+#define MC_TYPE_RECOVERY        3
+
+struct mcinfo_common {
+	uint16_t type;      /* structure type */
+	uint16_t size;      /* size of this struct in bytes */
+};
+
+
+#define MC_FLAG_CORRECTABLE     (1 << 0)
+#define MC_FLAG_UNCORRECTABLE   (1 << 1)
+#define MC_FLAG_RECOVERABLE	(1 << 2)
+#define MC_FLAG_POLLED		(1 << 3)
+#define MC_FLAG_RESET		(1 << 4)
+#define MC_FLAG_CMCI		(1 << 5)
+#define MC_FLAG_MCE		(1 << 6)
+/* contains global x86 mc information */
+struct mcinfo_global {
+	struct mcinfo_common common;
+
+	/* running domain at the time in error (most likely
+	 * the impacted one) */
+	uint16_t mc_domid;
+	uint16_t mc_vcpuid; /* virtual cpu scheduled for mc_domid */
+	uint32_t mc_socketid; /* physical socket of the physical core */
+	uint16_t mc_coreid; /* physical impacted core */
+	uint16_t mc_core_threadid; /* core thread of physical core */
+	uint32_t mc_apicid;
+	uint32_t mc_flags;
+	uint64_t mc_gstatus; /* global status */
+};
+
+/* contains bank local x86 mc information */
+struct mcinfo_bank {
+	struct mcinfo_common common;
+
+	uint16_t mc_bank; /* bank nr */
+	uint16_t mc_domid; /* Usecase 5: domain referenced by mc_addr on
+			* privileged pv-ops dom and if mc_addr is valid.
+			* Never valid on DomU. */
+	uint64_t mc_status; /* bank status */
+	uint64_t mc_addr;   /* bank address, only valid
+					 * if addr bit is set in mc_status */
+	uint64_t mc_misc;
+	uint64_t mc_ctrl2;
+	uint64_t mc_tsc;
+};
+
+
+struct mcinfo_msr {
+	uint64_t reg;   /* MSR */
+	uint64_t value; /* MSR value */
+};
+
+/* contains mc information from other
+ * or additional mc MSRs */
+struct mcinfo_extended {
+	struct mcinfo_common common;
+
+	/* You can fill up to five registers.
+	 * If you need more, then use this structure
+	 * multiple times. */
+
+	uint32_t mc_msrs; /* Number of msr with valid values. */
+	/*
+	 * Currently Intel extended MSR (32/64) include all gp registers
+	 * and E(R)FLAGS, E(R)IP, E(R)MISC, up to 11/19 of them might be
+	 * useful at present. So expand this array to 16/32 to leave room.
+	 */
+	struct mcinfo_msr mc_msr[sizeof(void *) * 4];
+};
+
+/* Recovery Action flags. Giving recovery result information to DOM0 */
+
+/* Xen takes successful recovery action, the error is recovered */
+#define REC_ACTION_RECOVERED (0x1 << 0)
+/* No action is performed by XEN */
+#define REC_ACTION_NONE (0x1 << 1)
+/* It's possible DOM0 might take action ownership in some case */
+#define REC_ACTION_NEED_RESET (0x1 << 2)
+
+/* Different Recovery Action types, if the action is performed successfull=
y,
+ * REC_ACTION_RECOVERED flag will be returned.
+ */
+
+/* Page Offline Action */
+#define MC_ACTION_PAGE_OFFLINE (0x1 << 0)
+/* CPU offline Action */
+#define MC_ACTION_CPU_OFFLINE (0x1 << 1)
+/* L3 cache disable Action */
+#define MC_ACTION_CACHE_SHRINK (0x1 << 2)
+
+/* Below interface used between XEN/DOM0 for passing XEN's recovery action
+ * information to DOM0.
+ * usage Senario: After offlining broken page, XEN might pass its page off=
line
+ * recovery action result to DOM0. DOM0 will save the information in
+ * non-volatile memory for further proactive actions, such as offlining th=
e
+ * easy broken page earlier when doing next reboot.
+*/
+struct page_offline_action {
+	/* Params for passing the offlined page number to DOM0 */
+	uint64_t mfn;
+	uint64_t status;
+};
+
+struct cpu_offline_action {
+	/* Params for passing the identity of the offlined CPU to DOM0 */
+	uint32_t mc_socketid;
+	uint16_t mc_coreid;
+	uint16_t mc_core_threadid;
+};
+
+#define MAX_UNION_SIZE 16
+struct mcinfo_recovery {
+	struct mcinfo_common common;
+	uint16_t mc_bank; /* bank nr */
+	/* Recovery Action Flags defined above such as REC_ACTION_DONE */
+	uint8_t action_flags;
+	/* Recovery Action types defined above such as MC_ACTION_PAGE_OFFLINE */
+	uint8_t action_types;
+	/* In future if more than one recovery action permitted per error bank,
+	 * a mcinfo_recovery data array will be returned
+	 */
+	union {
+		struct page_offline_action page_retire;
+		struct cpu_offline_action cpu_offline;
+		uint8_t pad[MAX_UNION_SIZE];
+	} action_info;
+};
+
+
+#define MCINFO_HYPERCALLSIZE	1024
+#define MCINFO_MAXSIZE		768
+
+struct mc_info {
+	/* Number of mcinfo_* entries in mi_data */
+	uint32_t mi_nentries;
+	uint32_t _pad0;
+	uint64_t mi_data[(MCINFO_MAXSIZE - 1) / 8];
+};
+typedef struct mc_info mc_info_t;
+DEFINE_GUEST_HANDLE_STRUCT(mc_info);
+
+#define __MC_MSR_ARRAYSIZE 8
+#define __MC_NMSRS 1
+#define MC_NCAPS	7	/* 7 CPU feature flag words */
+#define MC_CAPS_STD_EDX	0	/* cpuid level 0x00000001 (%edx) */
+#define MC_CAPS_AMD_EDX	1	/* cpuid level 0x80000001 (%edx) */
+#define MC_CAPS_TM	2	/* cpuid level 0x80860001 (TransMeta) */
+#define MC_CAPS_LINUX	3	/* Linux-defined */
+#define MC_CAPS_STD_ECX	4	/* cpuid level 0x00000001 (%ecx) */
+#define MC_CAPS_VIA	5	/* cpuid level 0xc0000001 */
+#define MC_CAPS_AMD_ECX	6	/* cpuid level 0x80000001 (%ecx) */
+
+struct mcinfo_logical_cpu {
+	uint32_t mc_cpunr;
+	uint32_t mc_chipid;
+	uint16_t mc_coreid;
+	uint16_t mc_threadid;
+	uint32_t mc_apicid;
+	uint32_t mc_clusterid;
+	uint32_t mc_ncores;
+	uint32_t mc_ncores_active;
+	uint32_t mc_nthreads;
+	int32_t mc_cpuid_level;
+	uint32_t mc_family;
+	uint32_t mc_vendor;
+	uint32_t mc_model;
+	uint32_t mc_step;
+	char mc_vendorid[16];
+	char mc_brandid[64];
+	uint32_t mc_cpu_caps[MC_NCAPS];
+	uint32_t mc_cache_size;
+	uint32_t mc_cache_alignment;
+	int32_t mc_nmsrvals;
+	struct mcinfo_msr mc_msrvalues[__MC_MSR_ARRAYSIZE];
+};
+typedef struct mcinfo_logical_cpu mcinfo_logical_cpu_t;
+DEFINE_GUEST_HANDLE_STRUCT(mcinfo_logical_cpu);
+
+
+/*
+ * OS's should use these instead of writing their own lookup function
+ * each with its own bugs and drawbacks.
+ * We use macros instead of static inline functions to allow guests
+ * to include this header in assembly files (*.S).
+ */
+/* Prototype:
+ *    uint32_t x86_mcinfo_nentries(struct mc_info *mi);
+ */
+#define x86_mcinfo_nentries(_mi)    \
+    ((_mi)->mi_nentries)
+/* Prototype:
+ *    struct mcinfo_common *x86_mcinfo_first(struct mc_info *mi);
+ */
+#define x86_mcinfo_first(_mi)       \
+    ((struct mcinfo_common *)(_mi)->mi_data)
+/* Prototype:
+ *    struct mcinfo_common *x86_mcinfo_next(struct mcinfo_common *mic);
+ */
+#define x86_mcinfo_next(_mic)       \
+    ((struct mcinfo_common *)((uint8_t *)(_mic) + (_mic)->size))
+
+/* Prototype:
+ *    void x86_mcinfo_lookup(void *ret, struct mc_info *mi, uint16_t type)=
;
+ */
+
+static inline void x86_mcinfo_lookup
+	(struct mcinfo_common **ret, struct mc_info *mi, uint16_t type)
+{
+	uint32_t found =3D 0, i;
+	struct mcinfo_common *mic;
+
+	*ret =3D NULL;
+	if (!mi)
+		return;
+	mic =3D x86_mcinfo_first(mi);
+
+	for (i =3D 0; i < x86_mcinfo_nentries(mi); i++) {
+		if (mic->type =3D=3D type) {
+			found =3D 1;
+			break;
+		}
+		mic =3D x86_mcinfo_next(mic);
+	}
+
+	*ret =3D found ? mic : NULL;
+}
+/* Usecase 1
+ * Register machine check trap callback handler
+ *    (already done via "set_trap_table" hypercall)
+ */
+
+/* Usecase 2
+ * Dom0 registers machine check event callback handler
+ * done by EVTCHNOP_bind_virq
+ */
+
+/* Usecase 3
+ * Fetch machine check data from hypervisor.
+ * Note, this hypercall is special, because both Dom0 and DomU must use th=
is.
+ */
+#define XEN_MC_fetch            1
+struct xen_mc_fetch {
+    /* IN/OUT variables.
+	 * IN: XEN_MC_NONURGENT, XEN_MC_URGENT,
+	 * XEN_MC_ACK if ack'king an earlier fetch
+	 * OUT: XEN_MC_OK, XEN_MC_FETCHAILED,
+	 * XEN_MC_NODATA, XEN_MC_NOMATCH
+	*/
+	uint32_t flags;
+	uint32_t _pad0;
+	/* OUT: id for ack, IN: id we are ack'ing */
+	uint64_t fetch_id;
+
+	/* OUT variables. */
+	GUEST_HANDLE(mc_info) data;
+};
+typedef struct xen_mc_fetch xen_mc_fetch_t;
+DEFINE_GUEST_HANDLE_STRUCT(xen_mc_fetch);
+
+
+/* Usecase 4
+ * This tells the hypervisor to notify a DomU about the machine check erro=
r
+ */
+#define XEN_MC_notifydomain     2
+struct xen_mc_notifydomain {
+	/* IN variables. */
+	uint16_t mc_domid;/* The unprivileged domain to notify. */
+	uint16_t mc_vcpuid;/* The vcpu in mc_domid to notify.
+			* Usually echo'd value from the fetch hypercall. */
+
+	/* IN/OUT variables. */
+	uint32_t flags;
+
+/* OUT: XEN_MC_OK, XEN_MC_CANNOTHANDLE, XEN_MC_NOTDELIVERED, XEN_MC_NOMATC=
H */
+};
+typedef struct xen_mc_notifydomain xen_mc_notifydomain_t;
+DEFINE_GUEST_HANDLE_STRUCT(xen_mc_notifydomain);
+
+#define XEN_MC_physcpuinfo 3
+struct xen_mc_physcpuinfo {
+	/* IN/OUT */
+	uint32_t ncpus;
+	uint32_t _pad0;
+	/* OUT */
+	GUEST_HANDLE(mcinfo_logical_cpu) info;
+};
+
+#define XEN_MC_msrinject    4
+#define MC_MSRINJ_MAXMSRS       8
+struct xen_mc_msrinject {
+	/* IN */
+	uint32_t mcinj_cpunr;/* target processor id */
+	uint32_t mcinj_flags;/* see MC_MSRINJ_F_* below */
+	uint32_t mcinj_count;/* 0 .. count-1 in array are valid */
+	uint32_t _pad0;
+	struct mcinfo_msr mcinj_msr[MC_MSRINJ_MAXMSRS];
+};
+
+/* Flags for mcinj_flags above; bits 16-31 are reserved */
+#define MC_MSRINJ_F_INTERPOSE   0x1
+
+#define XEN_MC_mceinject    5
+struct xen_mc_mceinject {
+	unsigned int mceinj_cpunr;      /* target processor id */
+};
+
+struct xen_mc {
+	uint32_t cmd;
+	uint32_t interface_version; /* XEN_MCA_INTERFACE_VERSION */
+	union {
+		struct xen_mc_fetch        mc_fetch;
+		struct xen_mc_notifydomain mc_notifydomain;
+		struct xen_mc_physcpuinfo  mc_physcpuinfo;
+		struct xen_mc_msrinject    mc_msrinject;
+		struct xen_mc_mceinject    mc_mceinject;
+	} u;
+};
+typedef struct xen_mc xen_mc_t;
+DEFINE_GUEST_HANDLE_STRUCT(xen_mc);
+
+#endif /* __ASSEMBLY__ */
+
+#endif /* __XEN_PUBLIC_ARCH_X86_MCA_H__ */
--=20
1.6.5.6

--_002_DE8DF0795D48FD4CA783C40EC82923359699SHSMSX101ccrcorpint_
Content-Type: application/octet-stream;
	name="0001-Add-mcelog-support-from-xen-platform.patch"
Content-Description: 0001-Add-mcelog-support-from-xen-platform.patch
Content-Disposition: attachment;
	filename="0001-Add-mcelog-support-from-xen-platform.patch"; size=25075;
	creation-date="Wed, 14 Dec 2011 15:20:15 GMT";
	modification-date="Wed, 14 Dec 2011 15:03:34 GMT"
Content-Transfer-Encoding: base64

RnJvbSAwZThkZTFjZTBmMTNhYTM0YWE2MDEzZTZhMzg3YWU1YmU3ODAzMWNhIE1vbiBTZXAgMTcg
MDA6MDA6MDAgMjAwMQpGcm9tOiBMaXUgSmluc29uZyA8amluc29uZy5saXVAaW50ZWwuY29tPgpE
YXRlOiBUdWUsIDYgRGVjIDIwMTEgMTg6MDg6MTIgKzA4MDAKU3ViamVjdDogW1BBVENIIDAxLzEw
XSBBZGQgbWNlbG9nIHN1cHBvcnQgZnJvbSB4ZW4gcGxhdGZvcm0KClRoaXMgcGF0Y2ggYmFja3Bv
cnQgZnJvbSBKZXJlbXkncyBwdm9wcyBjb21taXQgYTVlZDFmM2RhZTE3OTE1OGUzODVlOTM3MTQ2
MmRkNjVkNWUxMjVjNSwKd2hpY2ggaW4gdHVybiBiYWNrcG9ydCBmcm9tIHByZXZpb3VzIHhlbiBE
T00wKDIuNi4xOCkgY3M6IDc1ZTViZmE3ZmJkYwoKV2hlbiBhIE1DRS9DTUNJIGVycm9yIGhhcHBl
bnMgKG9yIGJ5IHBvbGxpbmcpLCB0aGUgcmVsYXRlZCBlcnJvcgppbmZvcm1hdGlvbiB3aWxsIGJl
IHNlbnQgdG8gcHJpdmlsZWdlZCBwdi1vcHMgZG9tYWluIGJ5IFhFTi4gVGhpcwpwYXRjaCB3aWxs
IGhlbHAgdG8gZmV0Y2ggdGhlIHhlbi1sb2dnZWQgaW5mb3JtYXRpb24gYnkgaHlwZXJjYWxsCmFu
ZCB0aGVuIGNvbnZlcnQgWEVOLWZvcm1hdCBsb2cgaW50byBMaW51eCBmb3JtYXQgTUNFTE9HLiBJ
dCBtYWtlcwp1c2luZyBjdXJyZW50IGF2YWlsYWJsZSBtY2Vsb2cgdG9vbHMgZm9yIG5hdGl2ZSBM
aW51eCBwb3NzaWJsZS4KCldpdGggdGhpcyBwYXRjaCwgYWZ0ZXIgbWNlL2NtY2kgZXJyb3IgbG9n
IGluZm9ybWF0aW9uIGlzIHNlbnQgdG8KcHYtb3BzIGd1ZXN0LCBSdW5uaW5nIG1jZWxvZyB0b29s
cyBpbiB0aGUgZ3Vlc3QsIHlvdSB3aWxsIGdldCBzYW1lCmRldGFpbGVkIGRlY29kZWQgbWNlIGlu
Zm9ybWF0aW9uIGFzIGluIE5hdGl2ZSBMaW51eC4KClNpZ25lZC1vZmYtYnk6IExpdSwgSmluc29u
ZyA8amluc29uZy5saXVAaW50ZWwuY29tPgpTaWduZWQtb2ZmLWJ5OiBLZSwgTGlwaW5nIDxsaXBp
bmcua2VAaW50ZWwuY29tPgpTaWduZWQtb2ZmLWJ5OiBKaWFuZywgWXVuaG9uZyA8eXVuaG9uZy5q
aWFuZ0BpbnRlbC5jb20+ClNpZ25lZC1vZmYtYnk6IEplcmVteSBGaXR6aGFyZGluZ2UgPGplcmVt
eS5maXR6aGFyZGluZ2VAY2l0cml4LmNvbT4KLS0tCiBhcmNoL3g4Ni9pbmNsdWRlL2FzbS94ZW4v
aHlwZXJjYWxsLmggfCAgICA4ICsKIGFyY2gveDg2L3hlbi9lbmxpZ2h0ZW4uYyAgICAgICAgICAg
ICB8ICAgIDggKy0KIGRyaXZlcnMveGVuL0tjb25maWcgICAgICAgICAgICAgICAgICB8ICAgIDgg
KwogZHJpdmVycy94ZW4vTWFrZWZpbGUgICAgICAgICAgICAgICAgIHwgICAgMSArCiBkcml2ZXJz
L3hlbi9tY2Vsb2cuYyAgICAgICAgICAgICAgICAgfCAgMjE3ICsrKysrKysrKysrKysrKysrCiBp
bmNsdWRlL3hlbi9pbnRlcmZhY2UveGVuLW1jYS5oICAgICAgfCAgNDI5ICsrKysrKysrKysrKysr
KysrKysrKysrKysrKysrKysrKysKIDYgZmlsZXMgY2hhbmdlZCwgNjY3IGluc2VydGlvbnMoKyks
IDQgZGVsZXRpb25zKC0pCiBjcmVhdGUgbW9kZSAxMDA2NDQgZHJpdmVycy94ZW4vbWNlbG9nLmMK
IGNyZWF0ZSBtb2RlIDEwMDY0NCBpbmNsdWRlL3hlbi9pbnRlcmZhY2UveGVuLW1jYS5oCgpkaWZm
IC0tZ2l0IGEvYXJjaC94ODYvaW5jbHVkZS9hc20veGVuL2h5cGVyY2FsbC5oIGIvYXJjaC94ODYv
aW5jbHVkZS9hc20veGVuL2h5cGVyY2FsbC5oCmluZGV4IDU3Mjg4NTIuLjU5YzIyNmQgMTAwNjQ0
Ci0tLSBhL2FyY2gveDg2L2luY2x1ZGUvYXNtL3hlbi9oeXBlcmNhbGwuaAorKysgYi9hcmNoL3g4
Ni9pbmNsdWRlL2FzbS94ZW4vaHlwZXJjYWxsLmgKQEAgLTQ4LDYgKzQ4LDcgQEAKICNpbmNsdWRl
IDx4ZW4vaW50ZXJmYWNlL3NjaGVkLmg+CiAjaW5jbHVkZSA8eGVuL2ludGVyZmFjZS9waHlzZGV2
Lmg+CiAjaW5jbHVkZSA8eGVuL2ludGVyZmFjZS9wbGF0Zm9ybS5oPgorI2luY2x1ZGUgPHhlbi9p
bnRlcmZhY2UveGVuLW1jYS5oPgogCiAvKgogICogVGhlIGh5cGVyY2FsbCBhc21zIGhhdmUgdG8g
bWVldCBzZXZlcmFsIGNvbnN0cmFpbnRzOgpAQCAtMzAyLDYgKzMwMywxMyBAQCBIWVBFUlZJU09S
X3NldF90aW1lcl9vcCh1NjQgdGltZW91dCkKIH0KIAogc3RhdGljIGlubGluZSBpbnQKK0hZUEVS
VklTT1JfbWNhKHN0cnVjdCB4ZW5fbWMgKm1jX29wKQoreworCW1jX29wLT5pbnRlcmZhY2VfdmVy
c2lvbiA9IFhFTl9NQ0FfSU5URVJGQUNFX1ZFUlNJT047CisJcmV0dXJuIF9oeXBlcmNhbGwxKGlu
dCwgbWNhLCBtY19vcCk7Cit9CisKK3N0YXRpYyBpbmxpbmUgaW50CiBIWVBFUlZJU09SX2RvbTBf
b3Aoc3RydWN0IHhlbl9wbGF0Zm9ybV9vcCAqcGxhdGZvcm1fb3ApCiB7CiAJcGxhdGZvcm1fb3At
PmludGVyZmFjZV92ZXJzaW9uID0gWEVOUEZfSU5URVJGQUNFX1ZFUlNJT047CmRpZmYgLS1naXQg
YS9hcmNoL3g4Ni94ZW4vZW5saWdodGVuLmMgYi9hcmNoL3g4Ni94ZW4vZW5saWdodGVuLmMKaW5k
ZXggOTMwNjMyMC4uYjA3M2U0YyAxMDA2NDQKLS0tIGEvYXJjaC94ODYveGVuL2VubGlnaHRlbi5j
CisrKyBiL2FyY2gveDg2L3hlbi9lbmxpZ2h0ZW4uYwpAQCAtMjQyLDE0ICsyNDIsMTQgQEAgc3Rh
dGljIHZvaWQgX19pbml0IHhlbl9pbml0X2NwdWlkX21hc2sodm9pZCkKIAl1bnNpZ25lZCBpbnQg
eHNhdmVfbWFzazsKIAogCWNwdWlkX2xlYWYxX2VkeF9tYXNrID0KLQkJfigoMSA8PCBYODZfRkVB
VFVSRV9NQ0UpICB8ICAvKiBkaXNhYmxlIE1DRSAqLwotCQkgICgxIDw8IFg4Nl9GRUFUVVJFX01D
QSkgIHwgIC8qIGRpc2FibGUgTUNBICovCi0JCSAgKDEgPDwgWDg2X0ZFQVRVUkVfTVRSUikgfCAg
LyogZGlzYWJsZSBNVFJSICovCisJCX4oKDEgPDwgWDg2X0ZFQVRVUkVfTVRSUikgfCAgLyogZGlz
YWJsZSBNVFJSICovCiAJCSAgKDEgPDwgWDg2X0ZFQVRVUkVfQUNDKSk7ICAgLyogdGhlcm1hbCBt
b25pdG9yaW5nICovCiAKIAlpZiAoIXhlbl9pbml0aWFsX2RvbWFpbigpKQogCQljcHVpZF9sZWFm
MV9lZHhfbWFzayAmPQotCQkJfigoMSA8PCBYODZfRkVBVFVSRV9BUElDKSB8ICAvKiBkaXNhYmxl
IGxvY2FsIEFQSUMgKi8KKwkJCX4oKDEgPDwgWDg2X0ZFQVRVUkVfTUNFKSAgfCAgLyogZGlzYWJs
ZSBNQ0UgKi8KKwkJCSAgKDEgPDwgWDg2X0ZFQVRVUkVfTUNBKSAgfCAgLyogZGlzYWJsZSBNQ0Eg
Ki8KKwkJCSAgKDEgPDwgWDg2X0ZFQVRVUkVfQVBJQykgfCAgLyogZGlzYWJsZSBsb2NhbCBBUElD
ICovCiAJCQkgICgxIDw8IFg4Nl9GRUFUVVJFX0FDUEkpKTsgIC8qIGRpc2FibGUgQUNQSSAqLwog
CWF4ID0gMTsKIAl4ZW5fY3B1aWQoJmF4LCAmYngsICZjeCwgJmR4KTsKZGlmZiAtLWdpdCBhL2Ry
aXZlcnMveGVuL0tjb25maWcgYi9kcml2ZXJzL3hlbi9LY29uZmlnCmluZGV4IGU4ZmI4NWYuLmVi
MmEzMjcgMTAwNjQ0Ci0tLSBhL2RyaXZlcnMveGVuL0tjb25maWcKKysrIGIvZHJpdmVycy94ZW4v
S2NvbmZpZwpAQCAtMTE3LDYgKzExNywxNCBAQCBjb25maWcgWEVOX1NZU19IWVBFUlZJU09SCiAJ
IHZpcnR1YWwgZW52aXJvbm1lbnQsIC9zeXMvaHlwZXJ2aXNvciB3aWxsIHN0aWxsIGJlIHByZXNl
bnQsCiAJIGJ1dCB3aWxsIGhhdmUgbm8geGVuIGNvbnRlbnRzLgogCitjb25maWcgWEVOX01DRV9M
T0cKKwlib29sICJYZW4gcGxhdGZvcm0gbWNlbG9nIgorCWRlcGVuZHMgb24gWEVOX0RPTTAgJiYg
WDg2XzY0ICYmIFg4Nl9NQ0UKKwlkZWZhdWx0IHkKKwloZWxwCisJICBBbGxvdyBrZXJuZWwgZmV0
Y2hpbmcgbWNlIGxvZyBmcm9tIHhlbiBwbGF0Zm9ybSBhbmQKKwkgIGNvbnZlcnRpbmcgaXQgaW50
byBsaW51eCBtY2Vsb2cgZm9ybWF0IGZvciBtY2Vsb2cgdG9vbHMKKwogY29uZmlnIEFDUElfUFJP
Q0VTU09SX1hFTgogCXRyaXN0YXRlCiAJZGVwZW5kcyBvbiBYRU5fRE9NMCAmJiBBQ1BJX1BST0NF
U1NPUiAmJiBDUFVfRlJFUQpkaWZmIC0tZ2l0IGEvZHJpdmVycy94ZW4vTWFrZWZpbGUgYi9kcml2
ZXJzL3hlbi9NYWtlZmlsZQppbmRleCBkNDJkYTUzLi40MDVjY2U5IDEwMDY0NAotLS0gYS9kcml2
ZXJzL3hlbi9NYWtlZmlsZQorKysgYi9kcml2ZXJzL3hlbi9NYWtlZmlsZQpAQCAtMTQsNiArMTQs
NyBAQCBvYmotJChDT05GSUdfWEVOX0dOVERFVikJCSs9IHhlbi1nbnRkZXYubwogb2JqLSQoQ09O
RklHX1hFTl9HUkFOVF9ERVZfQUxMT0MpCSs9IHhlbi1nbnRhbGxvYy5vCiBvYmotJChDT05GSUdf
WEVORlMpCQkJKz0geGVuZnMvCiBvYmotJChDT05GSUdfWEVOX1NZU19IWVBFUlZJU09SKQkrPSBz
eXMtaHlwZXJ2aXNvci5vCitvYmotJChDT05GSUdfWEVOX01DRV9MT0cpCQkrPSBtY2Vsb2cubwog
b2JqLSQoQ09ORklHX1hFTl9QTEFURk9STV9QQ0kpCQkrPSB4ZW4tcGxhdGZvcm0tcGNpLm8KIG9i
ai0kKENPTkZJR19YRU5fVE1FTSkJCQkrPSB0bWVtLm8KIG9iai0kKENPTkZJR19TV0lPVExCX1hF
TikJCSs9IHN3aW90bGIteGVuLm8KZGlmZiAtLWdpdCBhL2RyaXZlcnMveGVuL21jZWxvZy5jIGIv
ZHJpdmVycy94ZW4vbWNlbG9nLmMKbmV3IGZpbGUgbW9kZSAxMDA2NDQKaW5kZXggMDAwMDAwMC4u
ODkyY2E3YgotLS0gL2Rldi9udWxsCisrKyBiL2RyaXZlcnMveGVuL21jZWxvZy5jCkBAIC0wLDAg
KzEsMjE3IEBACisvKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqCisgKiBtY2Vsb2cuYworICogQWRkIE1h
Y2hpbmUgQ2hlY2sgZXZlbnQgTG9nZ2luZyBzdXBwb3J0IGluIERPTTAKKyAqCisgKiBEcml2ZXIg
Zm9yIHJlY2VpdmluZyBhbmQgbG9nZ2luZyBtYWNoaW5lIGNoZWNrIGV2ZW50CisgKgorICogQ29w
eXJpZ2h0IChjKSAyMDA4LCAyMDA5IEludGVsIENvcnBvcmF0aW9uCisgKgorICogVGhpcyBwcm9n
cmFtIGlzIGZyZWUgc29mdHdhcmU7IHlvdSBjYW4gcmVkaXN0cmlidXRlIGl0IGFuZC9vcgorICog
bW9kaWZ5IGl0IHVuZGVyIHRoZSB0ZXJtcyBvZiB0aGUgR05VIEdlbmVyYWwgUHVibGljIExpY2Vu
c2UgdmVyc2lvbiAyCisgKiBhcyBwdWJsaXNoZWQgYnkgdGhlIEZyZWUgU29mdHdhcmUgRm91bmRh
dGlvbjsgb3IsIHdoZW4gZGlzdHJpYnV0ZWQKKyAqIHNlcGFyYXRlbHkgZnJvbSB0aGUgTGludXgg
a2VybmVsIG9yIGluY29ycG9yYXRlZCBpbnRvIG90aGVyCisgKiBzb2Z0d2FyZSBwYWNrYWdlcywg
c3ViamVjdCB0byB0aGUgZm9sbG93aW5nIGxpY2Vuc2U6CisgKgorICogUGVybWlzc2lvbiBpcyBo
ZXJlYnkgZ3JhbnRlZCwgZnJlZSBvZiBjaGFyZ2UsIHRvIGFueSBwZXJzb24gb2J0YWluaW5nIGEg
Y29weQorICogb2YgdGhpcyBzb3VyY2UgZmlsZSAodGhlICJTb2Z0d2FyZSIpLCB0byBkZWFsIGlu
IHRoZSBTb2Z0d2FyZSB3aXRob3V0CisgKiByZXN0cmljdGlvbiwgaW5jbHVkaW5nIHdpdGhvdXQg
bGltaXRhdGlvbiB0aGUgcmlnaHRzIHRvIHVzZSwgY29weSwgbW9kaWZ5LAorICogbWVyZ2UsIHB1
Ymxpc2gsIGRpc3RyaWJ1dGUsIHN1YmxpY2Vuc2UsIGFuZC9vciBzZWxsIGNvcGllcyBvZiB0aGUg
U29mdHdhcmUsCisgKiBhbmQgdG8gcGVybWl0IHBlcnNvbnMgdG8gd2hvbSB0aGUgU29mdHdhcmUg
aXMgZnVybmlzaGVkIHRvIGRvIHNvLCBzdWJqZWN0IHRvCisgKiB0aGUgZm9sbG93aW5nIGNvbmRp
dGlvbnM6CisgKgorICogVGhlIGFib3ZlIGNvcHlyaWdodCBub3RpY2UgYW5kIHRoaXMgcGVybWlz
c2lvbiBub3RpY2Ugc2hhbGwgYmUgaW5jbHVkZWQgaW4KKyAqIGFsbCBjb3BpZXMgb3Igc3Vic3Rh
bnRpYWwgcG9ydGlvbnMgb2YgdGhlIFNvZnR3YXJlLgorICoKKyAqIFRIRSBTT0ZUV0FSRSBJUyBQ
Uk9WSURFRCAiQVMgSVMiLCBXSVRIT1VUIFdBUlJBTlRZIE9GIEFOWSBLSU5ELCBFWFBSRVNTIE9S
CisgKiBJTVBMSUVELCBJTkNMVURJTkcgQlVUIE5PVCBMSU1JVEVEIFRPIFRIRSBXQVJSQU5USUVT
IE9GIE1FUkNIQU5UQUJJTElUWSwKKyAqIEZJVE5FU1MgRk9SIEEgUEFSVElDVUxBUiBQVVJQT1NF
IEFORCBOT05JTkZSSU5HRU1FTlQuIElOIE5PIEVWRU5UIFNIQUxMIFRIRQorICogQVVUSE9SUyBP
UiBDT1BZUklHSFQgSE9MREVSUyBCRSBMSUFCTEUgRk9SIEFOWSBDTEFJTSwgREFNQUdFUyBPUiBP
VEhFUgorICogTElBQklMSVRZLCBXSEVUSEVSIElOIEFOIEFDVElPTiBPRiBDT05UUkFDVCwgVE9S
VCBPUiBPVEhFUldJU0UsIEFSSVNJTkcKKyAqIEZST00sIE9VVCBPRiBPUiBJTiBDT05ORUNUSU9O
IFdJVEggVEhFIFNPRlRXQVJFIE9SIFRIRSBVU0UgT1IgT1RIRVIgREVBTElOR1MKKyAqIElOIFRI
RSBTT0ZUV0FSRS4KKyAqLworCisjaW5jbHVkZSA8bGludXgvbW9kdWxlLmg+CisjaW5jbHVkZSA8
bGludXgvaW5pdC5oPgorI2luY2x1ZGUgPGxpbnV4L3R5cGVzLmg+CisjaW5jbHVkZSA8bGludXgv
a2VybmVsLmg+CisjaW5jbHVkZSA8bGludXgvc2xhYi5oPgorI2luY2x1ZGUgPHhlbi9pbnRlcmZh
Y2UveGVuLmg+CisjaW5jbHVkZSA8YXNtL3hlbi9oeXBlcnZpc29yLmg+CisjaW5jbHVkZSA8eGVu
L2V2ZW50cy5oPgorI2luY2x1ZGUgPHhlbi9pbnRlcmZhY2UvdmNwdS5oPgorI2luY2x1ZGUgPGFz
bS94ZW4vaHlwZXJjYWxsLmg+CisjaW5jbHVkZSA8YXNtL21jZS5oPgorI2luY2x1ZGUgPHhlbi94
ZW4uaD4KKworc3RhdGljIG1jX2luZm9fdCAqZ19taTsKK3N0YXRpYyBtY2luZm9fbG9naWNhbF9j
cHVfdCAqZ19waHlzaW5mbzsKK3N0YXRpYyB1aW50MzJfdCBuY3B1czsKKworc3RhdGljIGludCBj
b252ZXJ0X2xvZyhzdHJ1Y3QgbWNfaW5mbyAqbWkpCit7CisJc3RydWN0IG1jaW5mb19jb21tb24g
Km1pYyA9IE5VTEw7CisJc3RydWN0IG1jaW5mb19nbG9iYWwgKm1jX2dsb2JhbDsKKwlzdHJ1Y3Qg
bWNpbmZvX2JhbmsgKm1jX2Jhbms7CisJc3RydWN0IG1jZSBtOworCWludCBpLCBmb3VuZCA9IDA7
CisKKwl4ODZfbWNpbmZvX2xvb2t1cCgmbWljLCBtaSwgTUNfVFlQRV9HTE9CQUwpOworCVdBUk5f
T04oIW1pYyk7CisKKwltY2Vfc2V0dXAoJm0pOworCW1jX2dsb2JhbCA9IChzdHJ1Y3QgbWNpbmZv
X2dsb2JhbCAqKW1pYzsKKwltLm1jZ3N0YXR1cyA9IG1jX2dsb2JhbC0+bWNfZ3N0YXR1czsKKwlt
LmFwaWNpZCA9IG1jX2dsb2JhbC0+bWNfYXBpY2lkOworCWZvciAoaSA9IDA7IGkgPCBuY3B1czsg
aSsrKSB7CisJCWlmIChnX3BoeXNpbmZvW2ldLm1jX2FwaWNpZCA9PSBtLmFwaWNpZCkgeworCQkJ
Zm91bmQgPSAxOworCQkJYnJlYWs7CisJCX0KKwl9CisJV0FSTl9PTighZm91bmQpOworCisJbS5z
b2NrZXRpZCA9IGdfcGh5c2luZm9baV0ubWNfY2hpcGlkOworCW0uY3B1ID0gbS5leHRjcHUgPSBn
X3BoeXNpbmZvW2ldLm1jX2NwdW5yOworCW0uY3B1dmVuZG9yID0gKF9fdTgpZ19waHlzaW5mb1tp
XS5tY192ZW5kb3I7CisJbS5tY2djYXAgPSBnX3BoeXNpbmZvW2ldLm1jX21zcnZhbHVlc1swXS52
YWx1ZTsKKwl4ODZfbWNpbmZvX2xvb2t1cCgmbWljLCBtaSwgTUNfVFlQRV9CQU5LKTsKKwlkbyB7
CisJCWlmIChtaWMgPT0gTlVMTCB8fCBtaWMtPnNpemUgPT0gMCkKKwkJCWJyZWFrOworCQlpZiAo
bWljLT50eXBlID09IE1DX1RZUEVfQkFOSykgeworCQkJbWNfYmFuayA9IChzdHJ1Y3QgbWNpbmZv
X2JhbmsgKiltaWM7CisJCQltLm1pc2MgPSBtY19iYW5rLT5tY19taXNjOworCQkJbS5zdGF0dXMg
PSBtY19iYW5rLT5tY19zdGF0dXM7CisJCQltLmFkZHIgPSBtY19iYW5rLT5tY19hZGRyOworCQkJ
bS50c2MgPSBtY19iYW5rLT5tY190c2M7CisJCQltLmJhbmsgPSBtY19iYW5rLT5tY19iYW5rOwor
CQkJbS5maW5pc2hlZCA9IDE7CisJCQkvKmxvZyB0aGlzIHJlY29yZCovCisJCQltY2VfbG9nKCZt
KTsKKwkJfQorCQltaWMgPSB4ODZfbWNpbmZvX25leHQobWljKTsKKwl9IHdoaWxlICgxKTsKKwor
CXJldHVybiAwOworfQorCisvKnB2X29wcyBkb21haW4gbWNlIHZpcnEgaGFuZGxlciwgbG9nZ2lu
ZyBwaHlzaWNhbCBtY2UgZXJyb3IgaW5mbyovCitzdGF0aWMgaXJxcmV0dXJuX3QgbWNlX2RvbV9p
bnRlcnJ1cHQoaW50IGlycSwgdm9pZCAqZGV2X2lkKQoreworCXhlbl9tY190IG1jX29wOworCWlu
dCByZXN1bHQgPSAwOworCisJbWNfb3AuY21kID0gWEVOX01DX2ZldGNoOworCW1jX29wLmludGVy
ZmFjZV92ZXJzaW9uID0gWEVOX01DQV9JTlRFUkZBQ0VfVkVSU0lPTjsKKwlzZXRfeGVuX2d1ZXN0
X2hhbmRsZShtY19vcC51Lm1jX2ZldGNoLmRhdGEsIGdfbWkpOwordXJnZW50OgorCW1jX29wLnUu
bWNfZmV0Y2guZmxhZ3MgPSBYRU5fTUNfVVJHRU5UOworCXJlc3VsdCA9IEhZUEVSVklTT1JfbWNh
KCZtY19vcCk7CisJaWYgKHJlc3VsdCB8fCBtY19vcC51Lm1jX2ZldGNoLmZsYWdzICYgWEVOX01D
X05PREFUQSB8fAorCQkJbWNfb3AudS5tY19mZXRjaC5mbGFncyAmIFhFTl9NQ19GRVRDSEZBSUxF
RCkKKwkJZ290byBub251cmdlbnQ7CisJZWxzZSB7CisJCXJlc3VsdCA9IGNvbnZlcnRfbG9nKGdf
bWkpOworCQlpZiAocmVzdWx0KQorCQkJZ290byBlbmQ7CisJCS8qIEFmdGVyIGZldGNoaW5nIHRo
ZSBlcnJvciBldmVudCBsb2cgZW50cnkgZnJvbSBET00wLAorCQkgKiB3ZSBuZWVkIHRvIGRlYyB0
aGUgcmVmY250IGFuZCByZWxlYXNlIHRoZSBlbnRyeS4KKwkJICogVGhlIGVudHJ5IGlzIHJlc2Vy
dmVkIGFuZCBpbmMgcmVmY250IHdoZW4gZmlsbGluZworCQkgKiB0aGUgZXJyb3IgbG9nIGVudHJ5
LgorCQkgKi8KKwkJbWNfb3AudS5tY19mZXRjaC5mbGFncyA9IFhFTl9NQ19VUkdFTlQgfCBYRU5f
TUNfQUNLOworCQlyZXN1bHQgPSBIWVBFUlZJU09SX21jYSgmbWNfb3ApOworCQlnb3RvIHVyZ2Vu
dDsKKwl9Citub251cmdlbnQ6CisJbWNfb3AudS5tY19mZXRjaC5mbGFncyA9IFhFTl9NQ19OT05V
UkdFTlQ7CisJcmVzdWx0ID0gSFlQRVJWSVNPUl9tY2EoJm1jX29wKTsKKwlpZiAocmVzdWx0IHx8
IG1jX29wLnUubWNfZmV0Y2guZmxhZ3MgJiBYRU5fTUNfTk9EQVRBIHx8CisJCQltY19vcC51Lm1j
X2ZldGNoLmZsYWdzICYgWEVOX01DX0ZFVENIRkFJTEVEKQorCQlnb3RvIGVuZDsKKwllbHNlIHsK
KwkJcmVzdWx0ID0gY29udmVydF9sb2coZ19taSk7CisJCWlmIChyZXN1bHQpCisJCQlnb3RvIGVu
ZDsKKwkJLyogQWZ0ZXIgZmV0Y2hpbmcgdGhlIGVycm9yIGV2ZW50IGxvZyBlbnRyeSBmcm9tIERP
TTAsCisJCSAqIHdlIG5lZWQgdG8gZGVjIHRoZSByZWZjbnQgYW5kIHJlbGVhc2UgdGhlIGVudHJ5
LiBUaGUKKwkJICogZW50cnkgaXMgcmVzZXJ2ZWQgYW5kIGluYyByZWZjbnQgd2hlbiBmaWxsaW5n
IHRoZQorCQkgKiBlcnJvciBsb2cgZW50cnkuCisJCSAqLworCQltY19vcC51Lm1jX2ZldGNoLmZs
YWdzID0gWEVOX01DX05PTlVSR0VOVCB8IFhFTl9NQ19BQ0s7CisJCXJlc3VsdCA9IEhZUEVSVklT
T1JfbWNhKCZtY19vcCk7CisJCWdvdG8gbm9udXJnZW50OworCX0KK2VuZDoKKwlyZXR1cm4gSVJR
X0hBTkRMRUQ7Cit9CisKK3N0YXRpYyBpbnQgYmluZF92aXJxX2Zvcl9tY2Uodm9pZCkKK3sKKwlp
bnQgcmV0OworCXhlbl9tY190IG1jX29wOworCisJZ19taSA9IGttYWxsb2Moc2l6ZW9mKHN0cnVj
dCBtY19pbmZvKSwgR0ZQX0tFUk5FTCk7CisKKwlpZiAoIWdfbWkpCisJCXJldHVybiAtRU5PTUVN
OworCisJLyogRmV0Y2ggcGh5c2ljYWwgQ1BVIE51bWJlcnMgKi8KKwltY19vcC5jbWQgPSBYRU5f
TUNfcGh5c2NwdWluZm87CisJbWNfb3AuaW50ZXJmYWNlX3ZlcnNpb24gPSBYRU5fTUNBX0lOVEVS
RkFDRV9WRVJTSU9OOworCXNldF94ZW5fZ3Vlc3RfaGFuZGxlKG1jX29wLnUubWNfcGh5c2NwdWlu
Zm8uaW5mbywgZ19waHlzaW5mbyk7CisJcmV0ID0gSFlQRVJWSVNPUl9tY2EoJm1jX29wKTsKKwlp
ZiAocmV0KSB7CisJCXByaW50ayhLRVJOX0VSUiAiTUNFX0RPTTBfTE9HOiBGYWlsIHRvIGdldCBw
aHlzaWNhbCBDUFUgbnVtYmVyc1xuIik7CisJCWtmcmVlKGdfbWkpOworCQlyZXR1cm4gcmV0Owor
CX0KKworCS8qIEZldGNoIGVhY2ggQ1BVIFBoeXNpY2FsIEluZm8gZm9yIGxhdGVyIHJlZmVyZW5j
ZSovCisJbmNwdXMgPSBtY19vcC51Lm1jX3BoeXNjcHVpbmZvLm5jcHVzOworCWdfcGh5c2luZm8g
PSBrbWFsbG9jKHNpemVvZihzdHJ1Y3QgbWNpbmZvX2xvZ2ljYWxfY3B1KSpuY3B1cywKKwkJCQkJ
R0ZQX0tFUk5FTCk7CisJaWYgKCFnX3BoeXNpbmZvKSB7CisJCWtmcmVlKGdfbWkpOworCQlyZXR1
cm4gLUVOT01FTTsKKwl9CisJc2V0X3hlbl9ndWVzdF9oYW5kbGUobWNfb3AudS5tY19waHlzY3B1
aW5mby5pbmZvLCBnX3BoeXNpbmZvKTsKKwlyZXQgPSBIWVBFUlZJU09SX21jYSgmbWNfb3ApOwor
CWlmIChyZXQpIHsKKwkJcHJpbnRrKEtFUk5fRVJSICJNQ0VfRE9NMF9MT0c6IEZhaWwgdG8gZ2V0
IHBoeXNpY2FsIENQVXMgaW5mb1xuIik7CisJCWtmcmVlKGdfbWkpOworCQlrZnJlZShnX3BoeXNp
bmZvKTsKKwkJcmV0dXJuIHJldDsKKwl9CisKKwlyZXQgID0gYmluZF92aXJxX3RvX2lycWhhbmRs
ZXIoVklSUV9NQ0EsIDAsCisJCW1jZV9kb21faW50ZXJydXB0LCAwLCAibWNlIiwgTlVMTCk7CisK
KwlpZiAocmV0IDwgMCkgeworCQlwcmludGsoS0VSTl9FUlIgIk1DRV9ET00wX0xPRzogYmluZF92
aXJxIGZvciBET00wIGZhaWxlZFxuIik7CisJCXJldHVybiByZXQ7CisJfQorCisJcmV0dXJuIDA7
Cit9CisKK3N0YXRpYyBpbnQgX19pbml0IG1jZWxvZ19pbml0KHZvaWQpCit7CisJLyogT25seSBE
T00wIGlzIHJlc3BvbnNpYmxlIGZvciBNQ0UgbG9nZ2luZyAqLworCWlmICh4ZW5faW5pdGlhbF9k
b21haW4oKSkKKwkJcmV0dXJuIGJpbmRfdmlycV9mb3JfbWNlKCk7CisKKwlyZXR1cm4gMDsKK30K
KworCitzdGF0aWMgdm9pZCBfX2V4aXQgbWNlbG9nX2NsZWFudXAodm9pZCkKK3sKKwlrZnJlZShn
X21pKTsKKwlrZnJlZShnX3BoeXNpbmZvKTsKK30KK21vZHVsZV9pbml0KG1jZWxvZ19pbml0KTsK
K21vZHVsZV9leGl0KG1jZWxvZ19jbGVhbnVwKTsKKworTU9EVUxFX0xJQ0VOU0UoIkdQTCIpOwpk
aWZmIC0tZ2l0IGEvaW5jbHVkZS94ZW4vaW50ZXJmYWNlL3hlbi1tY2EuaCBiL2luY2x1ZGUveGVu
L2ludGVyZmFjZS94ZW4tbWNhLmgKbmV3IGZpbGUgbW9kZSAxMDA2NDQKaW5kZXggMDAwMDAwMC4u
ZjMxZmRhYgotLS0gL2Rldi9udWxsCisrKyBiL2luY2x1ZGUveGVuL2ludGVyZmFjZS94ZW4tbWNh
LmgKQEAgLTAsMCArMSw0MjkgQEAKKy8qKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioKKyAqIGFyY2gteDg2
L21jYS5oCisgKgorICogQ29udHJpYnV0ZWQgYnkgQWR2YW5jZWQgTWljcm8gRGV2aWNlcywgSW5j
LgorICogQXV0aG9yOiBDaHJpc3RvcGggRWdnZXIgPENocmlzdG9waC5FZ2dlckBhbWQuY29tPgor
ICoKKyAqIEd1ZXN0IE9TIG1hY2hpbmUgY2hlY2sgaW50ZXJmYWNlIHRvIHg4NiBYZW4uCisgKgor
ICogUGVybWlzc2lvbiBpcyBoZXJlYnkgZ3JhbnRlZCwgZnJlZSBvZiBjaGFyZ2UsIHRvIGFueSBw
ZXJzb24gb2J0YWluaW5nIGEgY29weQorICogb2YgdGhpcyBzb2Z0d2FyZSBhbmQgYXNzb2NpYXRl
ZCBkb2N1bWVudGF0aW9uIGZpbGVzICh0aGUgIlNvZnR3YXJlIiksIHRvCisgKiBkZWFsIGluIHRo
ZSBTb2Z0d2FyZSB3aXRob3V0IHJlc3RyaWN0aW9uLCBpbmNsdWRpbmcgd2l0aG91dCBsaW1pdGF0
aW9uIHRoZQorICogcmlnaHRzIHRvIHVzZSwgY29weSwgbW9kaWZ5LCBtZXJnZSwgcHVibGlzaCwg
ZGlzdHJpYnV0ZSwgc3VibGljZW5zZSwgYW5kL29yCisgKiBzZWxsIGNvcGllcyBvZiB0aGUgU29m
dHdhcmUsIGFuZCB0byBwZXJtaXQgcGVyc29ucyB0byB3aG9tIHRoZSBTb2Z0d2FyZSBpcworICog
ZnVybmlzaGVkIHRvIGRvIHNvLCBzdWJqZWN0IHRvIHRoZSBmb2xsb3dpbmcgY29uZGl0aW9uczoK
KyAqCisgKiBUaGUgYWJvdmUgY29weXJpZ2h0IG5vdGljZSBhbmQgdGhpcyBwZXJtaXNzaW9uIG5v
dGljZSBzaGFsbCBiZSBpbmNsdWRlZCBpbgorICogYWxsIGNvcGllcyBvciBzdWJzdGFudGlhbCBw
b3J0aW9ucyBvZiB0aGUgU29mdHdhcmUuCisgKgorICogVEhFIFNPRlRXQVJFIElTIFBST1ZJREVE
ICJBUyBJUyIsIFdJVEhPVVQgV0FSUkFOVFkgT0YgQU5ZIEtJTkQsIEVYUFJFU1MgT1IKKyAqIElN
UExJRUQsIElOQ0xVRElORyBCVVQgTk9UIExJTUlURUQgVE8gVEhFIFdBUlJBTlRJRVMgT0YgTUVS
Q0hBTlRBQklMSVRZLAorICogRklUTkVTUyBGT1IgQSBQQVJUSUNVTEFSIFBVUlBPU0UgQU5EIE5P
TklORlJJTkdFTUVOVC4gSU4gTk8gRVZFTlQgU0hBTEwgVEhFCisgKiBBVVRIT1JTIE9SIENPUFlS
SUdIVCBIT0xERVJTIEJFIExJQUJMRSBGT1IgQU5ZIENMQUlNLCBEQU1BR0VTIE9SIE9USEVSCisg
KiBMSUFCSUxJVFksIFdIRVRIRVIgSU4gQU4gQUNUSU9OIE9GIENPTlRSQUNULCBUT1JUIE9SIE9U
SEVSV0lTRSwgQVJJU0lORworICogRlJPTSwgT1VUIE9GIE9SIElOIENPTk5FQ1RJT04gV0lUSCBU
SEUgU09GVFdBUkUgT1IgVEhFIFVTRSBPUiBPVEhFUgorICogREVBTElOR1MgSU4gVEhFIFNPRlRX
QVJFLgorICovCisKKy8qIEZ1bGwgTUNBIGZ1bmN0aW9uYWxpdHkgaGFzIHRoZSBmb2xsb3dpbmcg
VXNlY2FzZXMgZnJvbSB0aGUgZ3Vlc3Qgc2lkZToKKyAqCisgKiBNdXN0IGhhdmUnczoKKyAqIDEu
IERvbTAgYW5kIERvbVUgcmVnaXN0ZXIgbWFjaGluZSBjaGVjayB0cmFwIGNhbGxiYWNrIGhhbmRs
ZXJzCisgKiAgICAoYWxyZWFkeSBkb25lIHZpYSAic2V0X3RyYXBfdGFibGUiIGh5cGVyY2FsbCkK
KyAqIDIuIERvbTAgcmVnaXN0ZXJzIG1hY2hpbmUgY2hlY2sgZXZlbnQgY2FsbGJhY2sgaGFuZGxl
cgorICogICAgKGRvYWJsZSB2aWEgRVZUQ0hOT1BfYmluZF92aXJxKQorICogMy4gRG9tMCBhbmQg
RG9tVSBmZXRjaGVzIG1hY2hpbmUgY2hlY2sgZGF0YQorICogNC4gRG9tMCB3YW50cyBYZW4gdG8g
bm90aWZ5IGEgRG9tVQorICogNS4gRG9tMCBnZXRzIERvbVUgSUQgZnJvbSBwaHlzaWNhbCBhZGRy
ZXNzCisgKiA2LiBEb20wIHdhbnRzIFhlbiB0byBraWxsIERvbVUgKGFscmVhZHkgZG9uZSBmb3Ig
InhtIGRlc3Ryb3kiKQorICoKKyAqIE5pY2UgdG8gaGF2ZSdzOgorICogNy4gRG9tMCB3YW50cyBY
ZW4gdG8gZGVhY3RpdmF0ZSBhIHBoeXNpY2FsIENQVQorICogICAgVGhpcyBpcyBiZXR0ZXIgZG9u
ZSBhcyBzZXBhcmF0ZSB0YXNrLCBwaHlzaWNhbCBDUFUgaG90cGx1Z2dpbmcsCisgKiAgICBhbmQg
aHlwZXJjYWxsKHMpIHNob3VsZCBiZSBzeXNjdGwncworICogOC4gUGFnZSBtaWdyYXRpb24gcHJv
cG9zZWQgZnJvbSBYZW4gTlVNQSB3b3JrLCB3aGVyZSBEb20wIGNhbiB0ZWxsIFhlbiB0bworICog
ICAgbW92ZSBhIERvbVUgKG9yIERvbTAgaXRzZWxmKSBhd2F5IGZyb20gYSBtYWxpY2lvdXMgcGFn
ZQorICogICAgcHJvZHVjaW5nIGNvcnJlY3RhYmxlIGVycm9ycy4KKyAqIDkuIG9mZmxpbmluZyBw
aHlzaWNhbCBwYWdlOgorICogICAgWGVuIGZyZWUncyBhbmQgbmV2ZXIgcmUtdXNlcyBhIGNlcnRh
aW4gcGh5c2ljYWwgcGFnZS4KKyAqIDEwLiBUZXN0ZmFjaWxpdHk6IEFsbG93IERvbTAgdG8gd3Jp
dGUgdmFsdWVzIGludG8gbWFjaGluZSBjaGVjayBNU1IncworICogICAgIGFuZCB0ZWxsIFhlbiB0
byB0cmlnZ2VyIGEgbWFjaGluZSBjaGVjaworICovCisKKyNpZm5kZWYgX19YRU5fUFVCTElDX0FS
Q0hfWDg2X01DQV9IX18KKyNkZWZpbmUgX19YRU5fUFVCTElDX0FSQ0hfWDg2X01DQV9IX18KKwor
LyogSHlwZXJjYWxsICovCisjZGVmaW5lIF9fSFlQRVJWSVNPUl9tY2EgX19IWVBFUlZJU09SX2Fy
Y2hfMAorCisvKgorICogVGhlIHhlbi11bnN0YWJsZSByZXBvIGhhcyBpbnRlcmZhY2UgdmVyc2lv
biAweDAzMDAwMDAxOyBvdXQgaW50ZXJmYWNlCisgKiBpcyBpbmNvbXBhdGlibGUgd2l0aCB0aGF0
IGFuZCBhbnkgZnV0dXJlIG1pbm9yIHJldmlzaW9ucywgc28gd2UKKyAqIGNob29zZSBhIGRpZmZl
cmVudCB2ZXJzaW9uIG51bWJlciByYW5nZSB0aGF0IGlzIG51bWVyaWNhbGx5IGxlc3MKKyAqIHRo
YW4gdGhhdCB1c2VkIGluIHhlbi11bnN0YWJsZS4KKyAqLworI2RlZmluZSBYRU5fTUNBX0lOVEVS
RkFDRV9WRVJTSU9OIDB4MDFlY2MwMDMKKworLyogSU46IERvbTAgY2FsbHMgaHlwZXJjYWxsIHRv
IHJldHJpZXZlIG5vbnVyZ2VudCBlcnJvciBsb2cgZW50cnkgKi8KKyNkZWZpbmUgWEVOX01DX05P
TlVSR0VOVCAgMHgwMDAxCisvKiBJTjogRG9tMC9Eb21VIGNhbGxzIGh5cGVyY2FsbCB0byByZXRy
aWV2ZSB1cmdlbnQgZXJyb3IgbG9nIGVudHJ5ICovCisjZGVmaW5lIFhFTl9NQ19VUkdFTlQgICAg
IDB4MDAwMgorLyogSU46IERvbTAgYWNrbm93bGVkZ2VzIHByZXZpb3NseS1mZXRjaGVkIGVycm9y
IGxvZyBlbnRyeSAqLworI2RlZmluZSBYRU5fTUNfQUNLICAgICAgICAweDAwMDQKKworLyogT1VU
OiBBbGwgaXMgb2sgKi8KKyNkZWZpbmUgWEVOX01DX09LICAgICAgICAgICAweDAKKy8qIE9VVDog
RG9tYWluIGNvdWxkIG5vdCBmZXRjaCBkYXRhLiAqLworI2RlZmluZSBYRU5fTUNfRkVUQ0hGQUlM
RUQgIDB4MQorLyogT1VUOiBUaGVyZSB3YXMgbm8gbWFjaGluZSBjaGVjayBkYXRhIHRvIGZldGNo
LiAqLworI2RlZmluZSBYRU5fTUNfTk9EQVRBICAgICAgIDB4MgorLyogT1VUOiBCZXR3ZWVuIG5v
dGlmaWNhdGlvbiB0aW1lIGFuZCB0aGlzIGh5cGVyY2FsbCBhbiBvdGhlcgorICogIChtb3N0IGxp
a2VseSkgY29ycmVjdGFibGUgZXJyb3IgaGFwcGVuZWQuIFRoZSBmZXRjaGVkIGRhdGEsCisgKiAg
ZG9lcyBub3QgbWF0Y2ggdGhlIG9yaWdpbmFsIG1hY2hpbmUgY2hlY2sgZGF0YS4gKi8KKyNkZWZp
bmUgWEVOX01DX05PTUFUQ0ggICAgICAweDQKKworLyogT1VUOiBEb21VIGRpZCBub3QgcmVnaXN0
ZXIgTUMgTk1JIGhhbmRsZXIuIFRyeSBzb21ldGhpbmcgZWxzZS4gKi8KKyNkZWZpbmUgWEVOX01D
X0NBTk5PVEhBTkRMRSAweDgKKy8qIE9VVDogTm90aWZ5aW5nIERvbVUgZmFpbGVkLiBSZXRyeSBs
YXRlciBvciB0cnkgc29tZXRoaW5nIGVsc2UuICovCisjZGVmaW5lIFhFTl9NQ19OT1RERUxJVkVS
RUQgMHgxMAorLyogTm90ZSwgWEVOX01DX0NBTk5PVEhBTkRMRSBhbmQgWEVOX01DX05PVERFTElW
RVJFRCBhcmUgbXV0dWFsbHkgZXhjbHVzaXZlLiAqLworCisKKyNpZm5kZWYgX19BU1NFTUJMWV9f
CisKKyNkZWZpbmUgVklSUV9NQ0EgVklSUV9BUkNIXzAgLyogRy4gKERPTTApIE1hY2hpbmUgQ2hl
Y2sgQXJjaGl0ZWN0dXJlICovCisKKy8qCisgKiBNYWNoaW5lIENoZWNrIEFyY2hpdGVjdXJlOgor
ICogc3RydWN0cyBhcmUgcmVhZC1vbmx5IGFuZCB1c2VkIHRvIHJlcG9ydCBhbGwga2luZHMgb2YK
KyAqIGNvcnJlY3RhYmxlIGFuZCB1bmNvcnJlY3RhYmxlIGVycm9ycyBkZXRlY3RlZCBieSB0aGUg
SFcuCisgKiBEb20wIGFuZCBEb21VOiByZWdpc3RlciBhIGhhbmRsZXIgdG8gZ2V0IG5vdGlmaWVk
LgorICogRG9tMCBvbmx5OiBDb3JyZWN0YWJsZSBlcnJvcnMgYXJlIHJlcG9ydGVkIHZpYSBWSVJR
X01DQQorICovCisjZGVmaW5lIE1DX1RZUEVfR0xPQkFMICAgICAgICAgIDAKKyNkZWZpbmUgTUNf
VFlQRV9CQU5LICAgICAgICAgICAgMQorI2RlZmluZSBNQ19UWVBFX0VYVEVOREVEICAgICAgICAy
CisjZGVmaW5lIE1DX1RZUEVfUkVDT1ZFUlkgICAgICAgIDMKKworc3RydWN0IG1jaW5mb19jb21t
b24geworCXVpbnQxNl90IHR5cGU7ICAgICAgLyogc3RydWN0dXJlIHR5cGUgKi8KKwl1aW50MTZf
dCBzaXplOyAgICAgIC8qIHNpemUgb2YgdGhpcyBzdHJ1Y3QgaW4gYnl0ZXMgKi8KK307CisKKwor
I2RlZmluZSBNQ19GTEFHX0NPUlJFQ1RBQkxFICAgICAoMSA8PCAwKQorI2RlZmluZSBNQ19GTEFH
X1VOQ09SUkVDVEFCTEUgICAoMSA8PCAxKQorI2RlZmluZSBNQ19GTEFHX1JFQ09WRVJBQkxFCSgx
IDw8IDIpCisjZGVmaW5lIE1DX0ZMQUdfUE9MTEVECQkoMSA8PCAzKQorI2RlZmluZSBNQ19GTEFH
X1JFU0VUCQkoMSA8PCA0KQorI2RlZmluZSBNQ19GTEFHX0NNQ0kJCSgxIDw8IDUpCisjZGVmaW5l
IE1DX0ZMQUdfTUNFCQkoMSA8PCA2KQorLyogY29udGFpbnMgZ2xvYmFsIHg4NiBtYyBpbmZvcm1h
dGlvbiAqLworc3RydWN0IG1jaW5mb19nbG9iYWwgeworCXN0cnVjdCBtY2luZm9fY29tbW9uIGNv
bW1vbjsKKworCS8qIHJ1bm5pbmcgZG9tYWluIGF0IHRoZSB0aW1lIGluIGVycm9yIChtb3N0IGxp
a2VseQorCSAqIHRoZSBpbXBhY3RlZCBvbmUpICovCisJdWludDE2X3QgbWNfZG9taWQ7CisJdWlu
dDE2X3QgbWNfdmNwdWlkOyAvKiB2aXJ0dWFsIGNwdSBzY2hlZHVsZWQgZm9yIG1jX2RvbWlkICov
CisJdWludDMyX3QgbWNfc29ja2V0aWQ7IC8qIHBoeXNpY2FsIHNvY2tldCBvZiB0aGUgcGh5c2lj
YWwgY29yZSAqLworCXVpbnQxNl90IG1jX2NvcmVpZDsgLyogcGh5c2ljYWwgaW1wYWN0ZWQgY29y
ZSAqLworCXVpbnQxNl90IG1jX2NvcmVfdGhyZWFkaWQ7IC8qIGNvcmUgdGhyZWFkIG9mIHBoeXNp
Y2FsIGNvcmUgKi8KKwl1aW50MzJfdCBtY19hcGljaWQ7CisJdWludDMyX3QgbWNfZmxhZ3M7CisJ
dWludDY0X3QgbWNfZ3N0YXR1czsgLyogZ2xvYmFsIHN0YXR1cyAqLworfTsKKworLyogY29udGFp
bnMgYmFuayBsb2NhbCB4ODYgbWMgaW5mb3JtYXRpb24gKi8KK3N0cnVjdCBtY2luZm9fYmFuayB7
CisJc3RydWN0IG1jaW5mb19jb21tb24gY29tbW9uOworCisJdWludDE2X3QgbWNfYmFuazsgLyog
YmFuayBuciAqLworCXVpbnQxNl90IG1jX2RvbWlkOyAvKiBVc2VjYXNlIDU6IGRvbWFpbiByZWZl
cmVuY2VkIGJ5IG1jX2FkZHIgb24KKwkJCSogcHJpdmlsZWdlZCBwdi1vcHMgZG9tIGFuZCBpZiBt
Y19hZGRyIGlzIHZhbGlkLgorCQkJKiBOZXZlciB2YWxpZCBvbiBEb21VLiAqLworCXVpbnQ2NF90
IG1jX3N0YXR1czsgLyogYmFuayBzdGF0dXMgKi8KKwl1aW50NjRfdCBtY19hZGRyOyAgIC8qIGJh
bmsgYWRkcmVzcywgb25seSB2YWxpZAorCQkJCQkgKiBpZiBhZGRyIGJpdCBpcyBzZXQgaW4gbWNf
c3RhdHVzICovCisJdWludDY0X3QgbWNfbWlzYzsKKwl1aW50NjRfdCBtY19jdHJsMjsKKwl1aW50
NjRfdCBtY190c2M7Cit9OworCisKK3N0cnVjdCBtY2luZm9fbXNyIHsKKwl1aW50NjRfdCByZWc7
ICAgLyogTVNSICovCisJdWludDY0X3QgdmFsdWU7IC8qIE1TUiB2YWx1ZSAqLworfTsKKworLyog
Y29udGFpbnMgbWMgaW5mb3JtYXRpb24gZnJvbSBvdGhlcgorICogb3IgYWRkaXRpb25hbCBtYyBN
U1JzICovCitzdHJ1Y3QgbWNpbmZvX2V4dGVuZGVkIHsKKwlzdHJ1Y3QgbWNpbmZvX2NvbW1vbiBj
b21tb247CisKKwkvKiBZb3UgY2FuIGZpbGwgdXAgdG8gZml2ZSByZWdpc3RlcnMuCisJICogSWYg
eW91IG5lZWQgbW9yZSwgdGhlbiB1c2UgdGhpcyBzdHJ1Y3R1cmUKKwkgKiBtdWx0aXBsZSB0aW1l
cy4gKi8KKworCXVpbnQzMl90IG1jX21zcnM7IC8qIE51bWJlciBvZiBtc3Igd2l0aCB2YWxpZCB2
YWx1ZXMuICovCisJLyoKKwkgKiBDdXJyZW50bHkgSW50ZWwgZXh0ZW5kZWQgTVNSICgzMi82NCkg
aW5jbHVkZSBhbGwgZ3AgcmVnaXN0ZXJzCisJICogYW5kIEUoUilGTEFHUywgRShSKUlQLCBFKFIp
TUlTQywgdXAgdG8gMTEvMTkgb2YgdGhlbSBtaWdodCBiZQorCSAqIHVzZWZ1bCBhdCBwcmVzZW50
LiBTbyBleHBhbmQgdGhpcyBhcnJheSB0byAxNi8zMiB0byBsZWF2ZSByb29tLgorCSAqLworCXN0
cnVjdCBtY2luZm9fbXNyIG1jX21zcltzaXplb2Yodm9pZCAqKSAqIDRdOworfTsKKworLyogUmVj
b3ZlcnkgQWN0aW9uIGZsYWdzLiBHaXZpbmcgcmVjb3ZlcnkgcmVzdWx0IGluZm9ybWF0aW9uIHRv
IERPTTAgKi8KKworLyogWGVuIHRha2VzIHN1Y2Nlc3NmdWwgcmVjb3ZlcnkgYWN0aW9uLCB0aGUg
ZXJyb3IgaXMgcmVjb3ZlcmVkICovCisjZGVmaW5lIFJFQ19BQ1RJT05fUkVDT1ZFUkVEICgweDEg
PDwgMCkKKy8qIE5vIGFjdGlvbiBpcyBwZXJmb3JtZWQgYnkgWEVOICovCisjZGVmaW5lIFJFQ19B
Q1RJT05fTk9ORSAoMHgxIDw8IDEpCisvKiBJdCdzIHBvc3NpYmxlIERPTTAgbWlnaHQgdGFrZSBh
Y3Rpb24gb3duZXJzaGlwIGluIHNvbWUgY2FzZSAqLworI2RlZmluZSBSRUNfQUNUSU9OX05FRURf
UkVTRVQgKDB4MSA8PCAyKQorCisvKiBEaWZmZXJlbnQgUmVjb3ZlcnkgQWN0aW9uIHR5cGVzLCBp
ZiB0aGUgYWN0aW9uIGlzIHBlcmZvcm1lZCBzdWNjZXNzZnVsbHksCisgKiBSRUNfQUNUSU9OX1JF
Q09WRVJFRCBmbGFnIHdpbGwgYmUgcmV0dXJuZWQuCisgKi8KKworLyogUGFnZSBPZmZsaW5lIEFj
dGlvbiAqLworI2RlZmluZSBNQ19BQ1RJT05fUEFHRV9PRkZMSU5FICgweDEgPDwgMCkKKy8qIENQ
VSBvZmZsaW5lIEFjdGlvbiAqLworI2RlZmluZSBNQ19BQ1RJT05fQ1BVX09GRkxJTkUgKDB4MSA8
PCAxKQorLyogTDMgY2FjaGUgZGlzYWJsZSBBY3Rpb24gKi8KKyNkZWZpbmUgTUNfQUNUSU9OX0NB
Q0hFX1NIUklOSyAoMHgxIDw8IDIpCisKKy8qIEJlbG93IGludGVyZmFjZSB1c2VkIGJldHdlZW4g
WEVOL0RPTTAgZm9yIHBhc3NpbmcgWEVOJ3MgcmVjb3ZlcnkgYWN0aW9uCisgKiBpbmZvcm1hdGlv
biB0byBET00wLgorICogdXNhZ2UgU2VuYXJpbzogQWZ0ZXIgb2ZmbGluaW5nIGJyb2tlbiBwYWdl
LCBYRU4gbWlnaHQgcGFzcyBpdHMgcGFnZSBvZmZsaW5lCisgKiByZWNvdmVyeSBhY3Rpb24gcmVz
dWx0IHRvIERPTTAuIERPTTAgd2lsbCBzYXZlIHRoZSBpbmZvcm1hdGlvbiBpbgorICogbm9uLXZv
bGF0aWxlIG1lbW9yeSBmb3IgZnVydGhlciBwcm9hY3RpdmUgYWN0aW9ucywgc3VjaCBhcyBvZmZs
aW5pbmcgdGhlCisgKiBlYXN5IGJyb2tlbiBwYWdlIGVhcmxpZXIgd2hlbiBkb2luZyBuZXh0IHJl
Ym9vdC4KKyovCitzdHJ1Y3QgcGFnZV9vZmZsaW5lX2FjdGlvbiB7CisJLyogUGFyYW1zIGZvciBw
YXNzaW5nIHRoZSBvZmZsaW5lZCBwYWdlIG51bWJlciB0byBET00wICovCisJdWludDY0X3QgbWZu
OworCXVpbnQ2NF90IHN0YXR1czsKK307CisKK3N0cnVjdCBjcHVfb2ZmbGluZV9hY3Rpb24gewor
CS8qIFBhcmFtcyBmb3IgcGFzc2luZyB0aGUgaWRlbnRpdHkgb2YgdGhlIG9mZmxpbmVkIENQVSB0
byBET00wICovCisJdWludDMyX3QgbWNfc29ja2V0aWQ7CisJdWludDE2X3QgbWNfY29yZWlkOwor
CXVpbnQxNl90IG1jX2NvcmVfdGhyZWFkaWQ7Cit9OworCisjZGVmaW5lIE1BWF9VTklPTl9TSVpF
IDE2CitzdHJ1Y3QgbWNpbmZvX3JlY292ZXJ5IHsKKwlzdHJ1Y3QgbWNpbmZvX2NvbW1vbiBjb21t
b247CisJdWludDE2X3QgbWNfYmFuazsgLyogYmFuayBuciAqLworCS8qIFJlY292ZXJ5IEFjdGlv
biBGbGFncyBkZWZpbmVkIGFib3ZlIHN1Y2ggYXMgUkVDX0FDVElPTl9ET05FICovCisJdWludDhf
dCBhY3Rpb25fZmxhZ3M7CisJLyogUmVjb3ZlcnkgQWN0aW9uIHR5cGVzIGRlZmluZWQgYWJvdmUg
c3VjaCBhcyBNQ19BQ1RJT05fUEFHRV9PRkZMSU5FICovCisJdWludDhfdCBhY3Rpb25fdHlwZXM7
CisJLyogSW4gZnV0dXJlIGlmIG1vcmUgdGhhbiBvbmUgcmVjb3ZlcnkgYWN0aW9uIHBlcm1pdHRl
ZCBwZXIgZXJyb3IgYmFuaywKKwkgKiBhIG1jaW5mb19yZWNvdmVyeSBkYXRhIGFycmF5IHdpbGwg
YmUgcmV0dXJuZWQKKwkgKi8KKwl1bmlvbiB7CisJCXN0cnVjdCBwYWdlX29mZmxpbmVfYWN0aW9u
IHBhZ2VfcmV0aXJlOworCQlzdHJ1Y3QgY3B1X29mZmxpbmVfYWN0aW9uIGNwdV9vZmZsaW5lOwor
CQl1aW50OF90IHBhZFtNQVhfVU5JT05fU0laRV07CisJfSBhY3Rpb25faW5mbzsKK307CisKKwor
I2RlZmluZSBNQ0lORk9fSFlQRVJDQUxMU0laRQkxMDI0CisjZGVmaW5lIE1DSU5GT19NQVhTSVpF
CQk3NjgKKworc3RydWN0IG1jX2luZm8geworCS8qIE51bWJlciBvZiBtY2luZm9fKiBlbnRyaWVz
IGluIG1pX2RhdGEgKi8KKwl1aW50MzJfdCBtaV9uZW50cmllczsKKwl1aW50MzJfdCBfcGFkMDsK
Kwl1aW50NjRfdCBtaV9kYXRhWyhNQ0lORk9fTUFYU0laRSAtIDEpIC8gOF07Cit9OwordHlwZWRl
ZiBzdHJ1Y3QgbWNfaW5mbyBtY19pbmZvX3Q7CitERUZJTkVfR1VFU1RfSEFORExFX1NUUlVDVCht
Y19pbmZvKTsKKworI2RlZmluZSBfX01DX01TUl9BUlJBWVNJWkUgOAorI2RlZmluZSBfX01DX05N
U1JTIDEKKyNkZWZpbmUgTUNfTkNBUFMJNwkvKiA3IENQVSBmZWF0dXJlIGZsYWcgd29yZHMgKi8K
KyNkZWZpbmUgTUNfQ0FQU19TVERfRURYCTAJLyogY3B1aWQgbGV2ZWwgMHgwMDAwMDAwMSAoJWVk
eCkgKi8KKyNkZWZpbmUgTUNfQ0FQU19BTURfRURYCTEJLyogY3B1aWQgbGV2ZWwgMHg4MDAwMDAw
MSAoJWVkeCkgKi8KKyNkZWZpbmUgTUNfQ0FQU19UTQkyCS8qIGNwdWlkIGxldmVsIDB4ODA4NjAw
MDEgKFRyYW5zTWV0YSkgKi8KKyNkZWZpbmUgTUNfQ0FQU19MSU5VWAkzCS8qIExpbnV4LWRlZmlu
ZWQgKi8KKyNkZWZpbmUgTUNfQ0FQU19TVERfRUNYCTQJLyogY3B1aWQgbGV2ZWwgMHgwMDAwMDAw
MSAoJWVjeCkgKi8KKyNkZWZpbmUgTUNfQ0FQU19WSUEJNQkvKiBjcHVpZCBsZXZlbCAweGMwMDAw
MDAxICovCisjZGVmaW5lIE1DX0NBUFNfQU1EX0VDWAk2CS8qIGNwdWlkIGxldmVsIDB4ODAwMDAw
MDEgKCVlY3gpICovCisKK3N0cnVjdCBtY2luZm9fbG9naWNhbF9jcHUgeworCXVpbnQzMl90IG1j
X2NwdW5yOworCXVpbnQzMl90IG1jX2NoaXBpZDsKKwl1aW50MTZfdCBtY19jb3JlaWQ7CisJdWlu
dDE2X3QgbWNfdGhyZWFkaWQ7CisJdWludDMyX3QgbWNfYXBpY2lkOworCXVpbnQzMl90IG1jX2Ns
dXN0ZXJpZDsKKwl1aW50MzJfdCBtY19uY29yZXM7CisJdWludDMyX3QgbWNfbmNvcmVzX2FjdGl2
ZTsKKwl1aW50MzJfdCBtY19udGhyZWFkczsKKwlpbnQzMl90IG1jX2NwdWlkX2xldmVsOworCXVp
bnQzMl90IG1jX2ZhbWlseTsKKwl1aW50MzJfdCBtY192ZW5kb3I7CisJdWludDMyX3QgbWNfbW9k
ZWw7CisJdWludDMyX3QgbWNfc3RlcDsKKwljaGFyIG1jX3ZlbmRvcmlkWzE2XTsKKwljaGFyIG1j
X2JyYW5kaWRbNjRdOworCXVpbnQzMl90IG1jX2NwdV9jYXBzW01DX05DQVBTXTsKKwl1aW50MzJf
dCBtY19jYWNoZV9zaXplOworCXVpbnQzMl90IG1jX2NhY2hlX2FsaWdubWVudDsKKwlpbnQzMl90
IG1jX25tc3J2YWxzOworCXN0cnVjdCBtY2luZm9fbXNyIG1jX21zcnZhbHVlc1tfX01DX01TUl9B
UlJBWVNJWkVdOworfTsKK3R5cGVkZWYgc3RydWN0IG1jaW5mb19sb2dpY2FsX2NwdSBtY2luZm9f
bG9naWNhbF9jcHVfdDsKK0RFRklORV9HVUVTVF9IQU5ETEVfU1RSVUNUKG1jaW5mb19sb2dpY2Fs
X2NwdSk7CisKKworLyoKKyAqIE9TJ3Mgc2hvdWxkIHVzZSB0aGVzZSBpbnN0ZWFkIG9mIHdyaXRp
bmcgdGhlaXIgb3duIGxvb2t1cCBmdW5jdGlvbgorICogZWFjaCB3aXRoIGl0cyBvd24gYnVncyBh
bmQgZHJhd2JhY2tzLgorICogV2UgdXNlIG1hY3JvcyBpbnN0ZWFkIG9mIHN0YXRpYyBpbmxpbmUg
ZnVuY3Rpb25zIHRvIGFsbG93IGd1ZXN0cworICogdG8gaW5jbHVkZSB0aGlzIGhlYWRlciBpbiBh
c3NlbWJseSBmaWxlcyAoKi5TKS4KKyAqLworLyogUHJvdG90eXBlOgorICogICAgdWludDMyX3Qg
eDg2X21jaW5mb19uZW50cmllcyhzdHJ1Y3QgbWNfaW5mbyAqbWkpOworICovCisjZGVmaW5lIHg4
Nl9tY2luZm9fbmVudHJpZXMoX21pKSAgICBcCisgICAgKChfbWkpLT5taV9uZW50cmllcykKKy8q
IFByb3RvdHlwZToKKyAqICAgIHN0cnVjdCBtY2luZm9fY29tbW9uICp4ODZfbWNpbmZvX2ZpcnN0
KHN0cnVjdCBtY19pbmZvICptaSk7CisgKi8KKyNkZWZpbmUgeDg2X21jaW5mb19maXJzdChfbWkp
ICAgICAgIFwKKyAgICAoKHN0cnVjdCBtY2luZm9fY29tbW9uICopKF9taSktPm1pX2RhdGEpCisv
KiBQcm90b3R5cGU6CisgKiAgICBzdHJ1Y3QgbWNpbmZvX2NvbW1vbiAqeDg2X21jaW5mb19uZXh0
KHN0cnVjdCBtY2luZm9fY29tbW9uICptaWMpOworICovCisjZGVmaW5lIHg4Nl9tY2luZm9fbmV4
dChfbWljKSAgICAgICBcCisgICAgKChzdHJ1Y3QgbWNpbmZvX2NvbW1vbiAqKSgodWludDhfdCAq
KShfbWljKSArIChfbWljKS0+c2l6ZSkpCisKKy8qIFByb3RvdHlwZToKKyAqICAgIHZvaWQgeDg2
X21jaW5mb19sb29rdXAodm9pZCAqcmV0LCBzdHJ1Y3QgbWNfaW5mbyAqbWksIHVpbnQxNl90IHR5
cGUpOworICovCisKK3N0YXRpYyBpbmxpbmUgdm9pZCB4ODZfbWNpbmZvX2xvb2t1cAorCShzdHJ1
Y3QgbWNpbmZvX2NvbW1vbiAqKnJldCwgc3RydWN0IG1jX2luZm8gKm1pLCB1aW50MTZfdCB0eXBl
KQoreworCXVpbnQzMl90IGZvdW5kID0gMCwgaTsKKwlzdHJ1Y3QgbWNpbmZvX2NvbW1vbiAqbWlj
OworCisJKnJldCA9IE5VTEw7CisJaWYgKCFtaSkKKwkJcmV0dXJuOworCW1pYyA9IHg4Nl9tY2lu
Zm9fZmlyc3QobWkpOworCisJZm9yIChpID0gMDsgaSA8IHg4Nl9tY2luZm9fbmVudHJpZXMobWkp
OyBpKyspIHsKKwkJaWYgKG1pYy0+dHlwZSA9PSB0eXBlKSB7CisJCQlmb3VuZCA9IDE7CisJCQli
cmVhazsKKwkJfQorCQltaWMgPSB4ODZfbWNpbmZvX25leHQobWljKTsKKwl9CisKKwkqcmV0ID0g
Zm91bmQgPyBtaWMgOiBOVUxMOworfQorLyogVXNlY2FzZSAxCisgKiBSZWdpc3RlciBtYWNoaW5l
IGNoZWNrIHRyYXAgY2FsbGJhY2sgaGFuZGxlcgorICogICAgKGFscmVhZHkgZG9uZSB2aWEgInNl
dF90cmFwX3RhYmxlIiBoeXBlcmNhbGwpCisgKi8KKworLyogVXNlY2FzZSAyCisgKiBEb20wIHJl
Z2lzdGVycyBtYWNoaW5lIGNoZWNrIGV2ZW50IGNhbGxiYWNrIGhhbmRsZXIKKyAqIGRvbmUgYnkg
RVZUQ0hOT1BfYmluZF92aXJxCisgKi8KKworLyogVXNlY2FzZSAzCisgKiBGZXRjaCBtYWNoaW5l
IGNoZWNrIGRhdGEgZnJvbSBoeXBlcnZpc29yLgorICogTm90ZSwgdGhpcyBoeXBlcmNhbGwgaXMg
c3BlY2lhbCwgYmVjYXVzZSBib3RoIERvbTAgYW5kIERvbVUgbXVzdCB1c2UgdGhpcy4KKyAqLwor
I2RlZmluZSBYRU5fTUNfZmV0Y2ggICAgICAgICAgICAxCitzdHJ1Y3QgeGVuX21jX2ZldGNoIHsK
KyAgICAvKiBJTi9PVVQgdmFyaWFibGVzLgorCSAqIElOOiBYRU5fTUNfTk9OVVJHRU5ULCBYRU5f
TUNfVVJHRU5ULAorCSAqIFhFTl9NQ19BQ0sgaWYgYWNrJ2tpbmcgYW4gZWFybGllciBmZXRjaAor
CSAqIE9VVDogWEVOX01DX09LLCBYRU5fTUNfRkVUQ0hBSUxFRCwKKwkgKiBYRU5fTUNfTk9EQVRB
LCBYRU5fTUNfTk9NQVRDSAorCSovCisJdWludDMyX3QgZmxhZ3M7CisJdWludDMyX3QgX3BhZDA7
CisJLyogT1VUOiBpZCBmb3IgYWNrLCBJTjogaWQgd2UgYXJlIGFjaydpbmcgKi8KKwl1aW50NjRf
dCBmZXRjaF9pZDsKKworCS8qIE9VVCB2YXJpYWJsZXMuICovCisJR1VFU1RfSEFORExFKG1jX2lu
Zm8pIGRhdGE7Cit9OwordHlwZWRlZiBzdHJ1Y3QgeGVuX21jX2ZldGNoIHhlbl9tY19mZXRjaF90
OworREVGSU5FX0dVRVNUX0hBTkRMRV9TVFJVQ1QoeGVuX21jX2ZldGNoKTsKKworCisvKiBVc2Vj
YXNlIDQKKyAqIFRoaXMgdGVsbHMgdGhlIGh5cGVydmlzb3IgdG8gbm90aWZ5IGEgRG9tVSBhYm91
dCB0aGUgbWFjaGluZSBjaGVjayBlcnJvcgorICovCisjZGVmaW5lIFhFTl9NQ19ub3RpZnlkb21h
aW4gICAgIDIKK3N0cnVjdCB4ZW5fbWNfbm90aWZ5ZG9tYWluIHsKKwkvKiBJTiB2YXJpYWJsZXMu
ICovCisJdWludDE2X3QgbWNfZG9taWQ7LyogVGhlIHVucHJpdmlsZWdlZCBkb21haW4gdG8gbm90
aWZ5LiAqLworCXVpbnQxNl90IG1jX3ZjcHVpZDsvKiBUaGUgdmNwdSBpbiBtY19kb21pZCB0byBu
b3RpZnkuCisJCQkqIFVzdWFsbHkgZWNobydkIHZhbHVlIGZyb20gdGhlIGZldGNoIGh5cGVyY2Fs
bC4gKi8KKworCS8qIElOL09VVCB2YXJpYWJsZXMuICovCisJdWludDMyX3QgZmxhZ3M7CisKKy8q
IE9VVDogWEVOX01DX09LLCBYRU5fTUNfQ0FOTk9USEFORExFLCBYRU5fTUNfTk9UREVMSVZFUkVE
LCBYRU5fTUNfTk9NQVRDSCAqLworfTsKK3R5cGVkZWYgc3RydWN0IHhlbl9tY19ub3RpZnlkb21h
aW4geGVuX21jX25vdGlmeWRvbWFpbl90OworREVGSU5FX0dVRVNUX0hBTkRMRV9TVFJVQ1QoeGVu
X21jX25vdGlmeWRvbWFpbik7CisKKyNkZWZpbmUgWEVOX01DX3BoeXNjcHVpbmZvIDMKK3N0cnVj
dCB4ZW5fbWNfcGh5c2NwdWluZm8geworCS8qIElOL09VVCAqLworCXVpbnQzMl90IG5jcHVzOwor
CXVpbnQzMl90IF9wYWQwOworCS8qIE9VVCAqLworCUdVRVNUX0hBTkRMRShtY2luZm9fbG9naWNh
bF9jcHUpIGluZm87Cit9OworCisjZGVmaW5lIFhFTl9NQ19tc3JpbmplY3QgICAgNAorI2RlZmlu
ZSBNQ19NU1JJTkpfTUFYTVNSUyAgICAgICA4CitzdHJ1Y3QgeGVuX21jX21zcmluamVjdCB7CisJ
LyogSU4gKi8KKwl1aW50MzJfdCBtY2lual9jcHVucjsvKiB0YXJnZXQgcHJvY2Vzc29yIGlkICov
CisJdWludDMyX3QgbWNpbmpfZmxhZ3M7Lyogc2VlIE1DX01TUklOSl9GXyogYmVsb3cgKi8KKwl1
aW50MzJfdCBtY2lual9jb3VudDsvKiAwIC4uIGNvdW50LTEgaW4gYXJyYXkgYXJlIHZhbGlkICov
CisJdWludDMyX3QgX3BhZDA7CisJc3RydWN0IG1jaW5mb19tc3IgbWNpbmpfbXNyW01DX01TUklO
Sl9NQVhNU1JTXTsKK307CisKKy8qIEZsYWdzIGZvciBtY2lual9mbGFncyBhYm92ZTsgYml0cyAx
Ni0zMSBhcmUgcmVzZXJ2ZWQgKi8KKyNkZWZpbmUgTUNfTVNSSU5KX0ZfSU5URVJQT1NFICAgMHgx
CisKKyNkZWZpbmUgWEVOX01DX21jZWluamVjdCAgICA1CitzdHJ1Y3QgeGVuX21jX21jZWluamVj
dCB7CisJdW5zaWduZWQgaW50IG1jZWlual9jcHVucjsgICAgICAvKiB0YXJnZXQgcHJvY2Vzc29y
IGlkICovCit9OworCitzdHJ1Y3QgeGVuX21jIHsKKwl1aW50MzJfdCBjbWQ7CisJdWludDMyX3Qg
aW50ZXJmYWNlX3ZlcnNpb247IC8qIFhFTl9NQ0FfSU5URVJGQUNFX1ZFUlNJT04gKi8KKwl1bmlv
biB7CisJCXN0cnVjdCB4ZW5fbWNfZmV0Y2ggICAgICAgIG1jX2ZldGNoOworCQlzdHJ1Y3QgeGVu
X21jX25vdGlmeWRvbWFpbiBtY19ub3RpZnlkb21haW47CisJCXN0cnVjdCB4ZW5fbWNfcGh5c2Nw
dWluZm8gIG1jX3BoeXNjcHVpbmZvOworCQlzdHJ1Y3QgeGVuX21jX21zcmluamVjdCAgICBtY19t
c3JpbmplY3Q7CisJCXN0cnVjdCB4ZW5fbWNfbWNlaW5qZWN0ICAgIG1jX21jZWluamVjdDsKKwl9
IHU7Cit9OwordHlwZWRlZiBzdHJ1Y3QgeGVuX21jIHhlbl9tY190OworREVGSU5FX0dVRVNUX0hB
TkRMRV9TVFJVQ1QoeGVuX21jKTsKKworI2VuZGlmIC8qIF9fQVNTRU1CTFlfXyAqLworCisjZW5k
aWYgLyogX19YRU5fUFVCTElDX0FSQ0hfWDg2X01DQV9IX18gKi8KLS0gCjEuNi41LjYKCg==

--_002_DE8DF0795D48FD4CA783C40EC82923359699SHSMSX101ccrcorpint_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--_002_DE8DF0795D48FD4CA783C40EC82923359699SHSMSX101ccrcorpint_--


From xen-devel-bounces@lists.xensource.com Fri Dec 23 10:24:02 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 Dec 2011 10: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.xensource.com>)
	id 1Re2Hv-0005sJ-1B; Fri, 23 Dec 2011 10:23:43 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1Re2Ht-0005rl-7c
	for xen-devel@lists.xensource.com; Fri, 23 Dec 2011 10:23:41 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1324635812!8564672!1
X-Originating-IP: [143.182.124.37]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjE2NTAw\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7187 invoked from network); 23 Dec 2011 10:23:33 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37)
	by server-8.tower-216.messagelabs.com with SMTP;
	23 Dec 2011 10:23:33 -0000
Received: from azsmga002.ch.intel.com ([10.2.17.35])
	by azsmga102.ch.intel.com with ESMTP; 23 Dec 2011 02:23:32 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208,223";a="50055368"
Received: from pgsmsx601.gar.corp.intel.com ([10.221.43.69])
	by AZSMGA002.ch.intel.com with ESMTP; 23 Dec 2011 02:23:29 -0800
Received: from pgsmsx102.gar.corp.intel.com (10.221.44.80) by
	pgsmsx601.gar.corp.intel.com (10.221.43.69) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Fri, 23 Dec 2011 18:23:06 +0800
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	PGSMSX102.gar.corp.intel.com (10.221.44.80) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Fri, 23 Dec 2011 18:23:05 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.38]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.199]) with mapi id
	14.01.0355.002; Fri, 23 Dec 2011 18:23:04 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: "konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
Thread-Topic: [PATCH 01/10] Add mcelog support from xen platform
Thread-Index: AczBXNo5kd/dViAgSKaxIwYWg4rVzQ==
Date: Fri, 23 Dec 2011 10:23:03 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC82923359699@SHSMSX101.ccr.corp.intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
Content-Type: multipart/mixed;
	boundary="_002_DE8DF0795D48FD4CA783C40EC82923359699SHSMSX101ccrcorpint_"
MIME-Version: 1.0
Cc: "Brown, Len" <len.brown@intel.com>,
	"jeremy.fitzhardinge@citrix.com" <jeremy.fitzhardinge@citrix.com>,
	"Jiang, Yunhong" <yunhong.jiang@intel.com>, "Shan, 
	Haitao" <haitao.shan@intel.com>,
	Kernel development list <linux-kernel@vger.kernel.org>, "Zhao,
	Yakui" <yakui.zhao@intel.com>, "Luck, Tony" <tony.luck@intel.com>, "Kleen,
	Andi" <andi.kleen@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: [Xen-devel] [PATCH 01/10] Add mcelog support from xen platform
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--_002_DE8DF0795D48FD4CA783C40EC82923359699SHSMSX101ccrcorpint_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

>From 0e8de1ce0f13aa34aa6013e6a387ae5be78031ca Mon Sep 17 00:00:00 2001
From: Liu Jinsong <jinsong.liu@intel.com>
Date: Tue, 6 Dec 2011 18:08:12 +0800
Subject: [PATCH 01/10] Add mcelog support from xen platform

This patch backport from Jeremy's pvops commit a5ed1f3dae179158e385e9371462=
dd65d5e125c5,
which in turn backport from previous xen DOM0(2.6.18) cs: 75e5bfa7fbdc

When a MCE/CMCI error happens (or by polling), the related error
information will be sent to privileged pv-ops domain by XEN. This
patch will help to fetch the xen-logged information by hypercall
and then convert XEN-format log into Linux format MCELOG. It makes
using current available mcelog tools for native Linux possible.

With this patch, after mce/cmci error log information is sent to
pv-ops guest, Running mcelog tools in the guest, you will get same
detailed decoded mce information as in Native Linux.

Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
Signed-off-by: Ke, Liping <liping.ke@intel.com>
Signed-off-by: Jiang, Yunhong <yunhong.jiang@intel.com>
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
---
 arch/x86/include/asm/xen/hypercall.h |    8 +
 arch/x86/xen/enlighten.c             |    8 +-
 drivers/xen/Kconfig                  |    8 +
 drivers/xen/Makefile                 |    1 +
 drivers/xen/mcelog.c                 |  217 +++++++++++++++++
 include/xen/interface/xen-mca.h      |  429 ++++++++++++++++++++++++++++++=
++++
 6 files changed, 667 insertions(+), 4 deletions(-)
 create mode 100644 drivers/xen/mcelog.c
 create mode 100644 include/xen/interface/xen-mca.h

diff --git a/arch/x86/include/asm/xen/hypercall.h b/arch/x86/include/asm/xe=
n/hypercall.h
index 5728852..59c226d 100644
--- a/arch/x86/include/asm/xen/hypercall.h
+++ b/arch/x86/include/asm/xen/hypercall.h
@@ -48,6 +48,7 @@
 #include <xen/interface/sched.h>
 #include <xen/interface/physdev.h>
 #include <xen/interface/platform.h>
+#include <xen/interface/xen-mca.h>
=20
 /*
  * The hypercall asms have to meet several constraints:
@@ -302,6 +303,13 @@ HYPERVISOR_set_timer_op(u64 timeout)
 }
=20
 static inline int
+HYPERVISOR_mca(struct xen_mc *mc_op)
+{
+	mc_op->interface_version =3D XEN_MCA_INTERFACE_VERSION;
+	return _hypercall1(int, mca, mc_op);
+}
+
+static inline int
 HYPERVISOR_dom0_op(struct xen_platform_op *platform_op)
 {
 	platform_op->interface_version =3D XENPF_INTERFACE_VERSION;
diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index 9306320..b073e4c 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -242,14 +242,14 @@ static void __init xen_init_cpuid_mask(void)
 	unsigned int xsave_mask;
=20
 	cpuid_leaf1_edx_mask =3D
-		~((1 << X86_FEATURE_MCE)  |  /* disable MCE */
-		  (1 << X86_FEATURE_MCA)  |  /* disable MCA */
-		  (1 << X86_FEATURE_MTRR) |  /* disable MTRR */
+		~((1 << X86_FEATURE_MTRR) |  /* disable MTRR */
 		  (1 << X86_FEATURE_ACC));   /* thermal monitoring */
=20
 	if (!xen_initial_domain())
 		cpuid_leaf1_edx_mask &=3D
-			~((1 << X86_FEATURE_APIC) |  /* disable local APIC */
+			~((1 << X86_FEATURE_MCE)  |  /* disable MCE */
+			  (1 << X86_FEATURE_MCA)  |  /* disable MCA */
+			  (1 << X86_FEATURE_APIC) |  /* disable local APIC */
 			  (1 << X86_FEATURE_ACPI));  /* disable ACPI */
 	ax =3D 1;
 	xen_cpuid(&ax, &bx, &cx, &dx);
diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
index e8fb85f..eb2a327 100644
--- a/drivers/xen/Kconfig
+++ b/drivers/xen/Kconfig
@@ -117,6 +117,14 @@ config XEN_SYS_HYPERVISOR
 	 virtual environment, /sys/hypervisor will still be present,
 	 but will have no xen contents.
=20
+config XEN_MCE_LOG
+	bool "Xen platform mcelog"
+	depends on XEN_DOM0 && X86_64 && X86_MCE
+	default y
+	help
+	  Allow kernel fetching mce log from xen platform and
+	  converting it into linux mcelog format for mcelog tools
+
 config ACPI_PROCESSOR_XEN
 	tristate
 	depends on XEN_DOM0 && ACPI_PROCESSOR && CPU_FREQ
diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
index d42da53..405cce9 100644
--- a/drivers/xen/Makefile
+++ b/drivers/xen/Makefile
@@ -14,6 +14,7 @@ obj-$(CONFIG_XEN_GNTDEV)		+=3D xen-gntdev.o
 obj-$(CONFIG_XEN_GRANT_DEV_ALLOC)	+=3D xen-gntalloc.o
 obj-$(CONFIG_XENFS)			+=3D xenfs/
 obj-$(CONFIG_XEN_SYS_HYPERVISOR)	+=3D sys-hypervisor.o
+obj-$(CONFIG_XEN_MCE_LOG)		+=3D mcelog.o
 obj-$(CONFIG_XEN_PLATFORM_PCI)		+=3D xen-platform-pci.o
 obj-$(CONFIG_XEN_TMEM)			+=3D tmem.o
 obj-$(CONFIG_SWIOTLB_XEN)		+=3D swiotlb-xen.o
diff --git a/drivers/xen/mcelog.c b/drivers/xen/mcelog.c
new file mode 100644
index 0000000..892ca7b
--- /dev/null
+++ b/drivers/xen/mcelog.c
@@ -0,0 +1,217 @@
+/*************************************************************************=
*****
+ * mcelog.c
+ * Add Machine Check event Logging support in DOM0
+ *
+ * Driver for receiving and logging machine check event
+ *
+ * Copyright (c) 2008, 2009 Intel Corporation
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version 2
+ * as published by the Free Software Foundation; or, when distributed
+ * separately from the Linux kernel or incorporated into other
+ * software packages, subject to the following license:
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a=
 copy
+ * of this source file (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use, copy, modi=
fy,
+ * merge, publish, distribute, sublicense, and/or sell copies of the Softw=
are,
+ * and to permit persons to whom the Software is furnished to do so, subje=
ct to
+ * the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included=
 in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS=
 OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY=
,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL=
 THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEA=
LINGS
+ * IN THE SOFTWARE.
+ */
+
+#include <linux/module.h>
+#include <linux/init.h>
+#include <linux/types.h>
+#include <linux/kernel.h>
+#include <linux/slab.h>
+#include <xen/interface/xen.h>
+#include <asm/xen/hypervisor.h>
+#include <xen/events.h>
+#include <xen/interface/vcpu.h>
+#include <asm/xen/hypercall.h>
+#include <asm/mce.h>
+#include <xen/xen.h>
+
+static mc_info_t *g_mi;
+static mcinfo_logical_cpu_t *g_physinfo;
+static uint32_t ncpus;
+
+static int convert_log(struct mc_info *mi)
+{
+	struct mcinfo_common *mic =3D NULL;
+	struct mcinfo_global *mc_global;
+	struct mcinfo_bank *mc_bank;
+	struct mce m;
+	int i, found =3D 0;
+
+	x86_mcinfo_lookup(&mic, mi, MC_TYPE_GLOBAL);
+	WARN_ON(!mic);
+
+	mce_setup(&m);
+	mc_global =3D (struct mcinfo_global *)mic;
+	m.mcgstatus =3D mc_global->mc_gstatus;
+	m.apicid =3D mc_global->mc_apicid;
+	for (i =3D 0; i < ncpus; i++) {
+		if (g_physinfo[i].mc_apicid =3D=3D m.apicid) {
+			found =3D 1;
+			break;
+		}
+	}
+	WARN_ON(!found);
+
+	m.socketid =3D g_physinfo[i].mc_chipid;
+	m.cpu =3D m.extcpu =3D g_physinfo[i].mc_cpunr;
+	m.cpuvendor =3D (__u8)g_physinfo[i].mc_vendor;
+	m.mcgcap =3D g_physinfo[i].mc_msrvalues[0].value;
+	x86_mcinfo_lookup(&mic, mi, MC_TYPE_BANK);
+	do {
+		if (mic =3D=3D NULL || mic->size =3D=3D 0)
+			break;
+		if (mic->type =3D=3D MC_TYPE_BANK) {
+			mc_bank =3D (struct mcinfo_bank *)mic;
+			m.misc =3D mc_bank->mc_misc;
+			m.status =3D mc_bank->mc_status;
+			m.addr =3D mc_bank->mc_addr;
+			m.tsc =3D mc_bank->mc_tsc;
+			m.bank =3D mc_bank->mc_bank;
+			m.finished =3D 1;
+			/*log this record*/
+			mce_log(&m);
+		}
+		mic =3D x86_mcinfo_next(mic);
+	} while (1);
+
+	return 0;
+}
+
+/*pv_ops domain mce virq handler, logging physical mce error info*/
+static irqreturn_t mce_dom_interrupt(int irq, void *dev_id)
+{
+	xen_mc_t mc_op;
+	int result =3D 0;
+
+	mc_op.cmd =3D XEN_MC_fetch;
+	mc_op.interface_version =3D XEN_MCA_INTERFACE_VERSION;
+	set_xen_guest_handle(mc_op.u.mc_fetch.data, g_mi);
+urgent:
+	mc_op.u.mc_fetch.flags =3D XEN_MC_URGENT;
+	result =3D HYPERVISOR_mca(&mc_op);
+	if (result || mc_op.u.mc_fetch.flags & XEN_MC_NODATA ||
+			mc_op.u.mc_fetch.flags & XEN_MC_FETCHFAILED)
+		goto nonurgent;
+	else {
+		result =3D convert_log(g_mi);
+		if (result)
+			goto end;
+		/* After fetching the error event log entry from DOM0,
+		 * we need to dec the refcnt and release the entry.
+		 * The entry is reserved and inc refcnt when filling
+		 * the error log entry.
+		 */
+		mc_op.u.mc_fetch.flags =3D XEN_MC_URGENT | XEN_MC_ACK;
+		result =3D HYPERVISOR_mca(&mc_op);
+		goto urgent;
+	}
+nonurgent:
+	mc_op.u.mc_fetch.flags =3D XEN_MC_NONURGENT;
+	result =3D HYPERVISOR_mca(&mc_op);
+	if (result || mc_op.u.mc_fetch.flags & XEN_MC_NODATA ||
+			mc_op.u.mc_fetch.flags & XEN_MC_FETCHFAILED)
+		goto end;
+	else {
+		result =3D convert_log(g_mi);
+		if (result)
+			goto end;
+		/* After fetching the error event log entry from DOM0,
+		 * we need to dec the refcnt and release the entry. The
+		 * entry is reserved and inc refcnt when filling the
+		 * error log entry.
+		 */
+		mc_op.u.mc_fetch.flags =3D XEN_MC_NONURGENT | XEN_MC_ACK;
+		result =3D HYPERVISOR_mca(&mc_op);
+		goto nonurgent;
+	}
+end:
+	return IRQ_HANDLED;
+}
+
+static int bind_virq_for_mce(void)
+{
+	int ret;
+	xen_mc_t mc_op;
+
+	g_mi =3D kmalloc(sizeof(struct mc_info), GFP_KERNEL);
+
+	if (!g_mi)
+		return -ENOMEM;
+
+	/* Fetch physical CPU Numbers */
+	mc_op.cmd =3D XEN_MC_physcpuinfo;
+	mc_op.interface_version =3D XEN_MCA_INTERFACE_VERSION;
+	set_xen_guest_handle(mc_op.u.mc_physcpuinfo.info, g_physinfo);
+	ret =3D HYPERVISOR_mca(&mc_op);
+	if (ret) {
+		printk(KERN_ERR "MCE_DOM0_LOG: Fail to get physical CPU numbers\n");
+		kfree(g_mi);
+		return ret;
+	}
+
+	/* Fetch each CPU Physical Info for later reference*/
+	ncpus =3D mc_op.u.mc_physcpuinfo.ncpus;
+	g_physinfo =3D kmalloc(sizeof(struct mcinfo_logical_cpu)*ncpus,
+					GFP_KERNEL);
+	if (!g_physinfo) {
+		kfree(g_mi);
+		return -ENOMEM;
+	}
+	set_xen_guest_handle(mc_op.u.mc_physcpuinfo.info, g_physinfo);
+	ret =3D HYPERVISOR_mca(&mc_op);
+	if (ret) {
+		printk(KERN_ERR "MCE_DOM0_LOG: Fail to get physical CPUs info\n");
+		kfree(g_mi);
+		kfree(g_physinfo);
+		return ret;
+	}
+
+	ret  =3D bind_virq_to_irqhandler(VIRQ_MCA, 0,
+		mce_dom_interrupt, 0, "mce", NULL);
+
+	if (ret < 0) {
+		printk(KERN_ERR "MCE_DOM0_LOG: bind_virq for DOM0 failed\n");
+		return ret;
+	}
+
+	return 0;
+}
+
+static int __init mcelog_init(void)
+{
+	/* Only DOM0 is responsible for MCE logging */
+	if (xen_initial_domain())
+		return bind_virq_for_mce();
+
+	return 0;
+}
+
+
+static void __exit mcelog_cleanup(void)
+{
+	kfree(g_mi);
+	kfree(g_physinfo);
+}
+module_init(mcelog_init);
+module_exit(mcelog_cleanup);
+
+MODULE_LICENSE("GPL");
diff --git a/include/xen/interface/xen-mca.h b/include/xen/interface/xen-mc=
a.h
new file mode 100644
index 0000000..f31fdab
--- /dev/null
+++ b/include/xen/interface/xen-mca.h
@@ -0,0 +1,429 @@
+/*************************************************************************=
*****
+ * arch-x86/mca.h
+ *
+ * Contributed by Advanced Micro Devices, Inc.
+ * Author: Christoph Egger <Christoph.Egger@amd.com>
+ *
+ * Guest OS machine check interface to x86 Xen.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a=
 copy
+ * of this software and associated documentation files (the "Software"), t=
o
+ * deal in the Software without restriction, including without limitation =
the
+ * rights to use, copy, modify, merge, publish, distribute, sublicense, an=
d/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.
+ */
+
+/* Full MCA functionality has the following Usecases from the guest side:
+ *
+ * Must have's:
+ * 1. Dom0 and DomU register machine check trap callback handlers
+ *    (already done via "set_trap_table" hypercall)
+ * 2. Dom0 registers machine check event callback handler
+ *    (doable via EVTCHNOP_bind_virq)
+ * 3. Dom0 and DomU fetches machine check data
+ * 4. Dom0 wants Xen to notify a DomU
+ * 5. Dom0 gets DomU ID from physical address
+ * 6. Dom0 wants Xen to kill DomU (already done for "xm destroy")
+ *
+ * Nice to have's:
+ * 7. Dom0 wants Xen to deactivate a physical CPU
+ *    This is better done as separate task, physical CPU hotplugging,
+ *    and hypercall(s) should be sysctl's
+ * 8. Page migration proposed from Xen NUMA work, where Dom0 can tell Xen =
to
+ *    move a DomU (or Dom0 itself) away from a malicious page
+ *    producing correctable errors.
+ * 9. offlining physical page:
+ *    Xen free's and never re-uses a certain physical page.
+ * 10. Testfacility: Allow Dom0 to write values into machine check MSR's
+ *     and tell Xen to trigger a machine check
+ */
+
+#ifndef __XEN_PUBLIC_ARCH_X86_MCA_H__
+#define __XEN_PUBLIC_ARCH_X86_MCA_H__
+
+/* Hypercall */
+#define __HYPERVISOR_mca __HYPERVISOR_arch_0
+
+/*
+ * The xen-unstable repo has interface version 0x03000001; out interface
+ * is incompatible with that and any future minor revisions, so we
+ * choose a different version number range that is numerically less
+ * than that used in xen-unstable.
+ */
+#define XEN_MCA_INTERFACE_VERSION 0x01ecc003
+
+/* IN: Dom0 calls hypercall to retrieve nonurgent error log entry */
+#define XEN_MC_NONURGENT  0x0001
+/* IN: Dom0/DomU calls hypercall to retrieve urgent error log entry */
+#define XEN_MC_URGENT     0x0002
+/* IN: Dom0 acknowledges previosly-fetched error log entry */
+#define XEN_MC_ACK        0x0004
+
+/* OUT: All is ok */
+#define XEN_MC_OK           0x0
+/* OUT: Domain could not fetch data. */
+#define XEN_MC_FETCHFAILED  0x1
+/* OUT: There was no machine check data to fetch. */
+#define XEN_MC_NODATA       0x2
+/* OUT: Between notification time and this hypercall an other
+ *  (most likely) correctable error happened. The fetched data,
+ *  does not match the original machine check data. */
+#define XEN_MC_NOMATCH      0x4
+
+/* OUT: DomU did not register MC NMI handler. Try something else. */
+#define XEN_MC_CANNOTHANDLE 0x8
+/* OUT: Notifying DomU failed. Retry later or try something else. */
+#define XEN_MC_NOTDELIVERED 0x10
+/* Note, XEN_MC_CANNOTHANDLE and XEN_MC_NOTDELIVERED are mutually exclusiv=
e. */
+
+
+#ifndef __ASSEMBLY__
+
+#define VIRQ_MCA VIRQ_ARCH_0 /* G. (DOM0) Machine Check Architecture */
+
+/*
+ * Machine Check Architecure:
+ * structs are read-only and used to report all kinds of
+ * correctable and uncorrectable errors detected by the HW.
+ * Dom0 and DomU: register a handler to get notified.
+ * Dom0 only: Correctable errors are reported via VIRQ_MCA
+ */
+#define MC_TYPE_GLOBAL          0
+#define MC_TYPE_BANK            1
+#define MC_TYPE_EXTENDED        2
+#define MC_TYPE_RECOVERY        3
+
+struct mcinfo_common {
+	uint16_t type;      /* structure type */
+	uint16_t size;      /* size of this struct in bytes */
+};
+
+
+#define MC_FLAG_CORRECTABLE     (1 << 0)
+#define MC_FLAG_UNCORRECTABLE   (1 << 1)
+#define MC_FLAG_RECOVERABLE	(1 << 2)
+#define MC_FLAG_POLLED		(1 << 3)
+#define MC_FLAG_RESET		(1 << 4)
+#define MC_FLAG_CMCI		(1 << 5)
+#define MC_FLAG_MCE		(1 << 6)
+/* contains global x86 mc information */
+struct mcinfo_global {
+	struct mcinfo_common common;
+
+	/* running domain at the time in error (most likely
+	 * the impacted one) */
+	uint16_t mc_domid;
+	uint16_t mc_vcpuid; /* virtual cpu scheduled for mc_domid */
+	uint32_t mc_socketid; /* physical socket of the physical core */
+	uint16_t mc_coreid; /* physical impacted core */
+	uint16_t mc_core_threadid; /* core thread of physical core */
+	uint32_t mc_apicid;
+	uint32_t mc_flags;
+	uint64_t mc_gstatus; /* global status */
+};
+
+/* contains bank local x86 mc information */
+struct mcinfo_bank {
+	struct mcinfo_common common;
+
+	uint16_t mc_bank; /* bank nr */
+	uint16_t mc_domid; /* Usecase 5: domain referenced by mc_addr on
+			* privileged pv-ops dom and if mc_addr is valid.
+			* Never valid on DomU. */
+	uint64_t mc_status; /* bank status */
+	uint64_t mc_addr;   /* bank address, only valid
+					 * if addr bit is set in mc_status */
+	uint64_t mc_misc;
+	uint64_t mc_ctrl2;
+	uint64_t mc_tsc;
+};
+
+
+struct mcinfo_msr {
+	uint64_t reg;   /* MSR */
+	uint64_t value; /* MSR value */
+};
+
+/* contains mc information from other
+ * or additional mc MSRs */
+struct mcinfo_extended {
+	struct mcinfo_common common;
+
+	/* You can fill up to five registers.
+	 * If you need more, then use this structure
+	 * multiple times. */
+
+	uint32_t mc_msrs; /* Number of msr with valid values. */
+	/*
+	 * Currently Intel extended MSR (32/64) include all gp registers
+	 * and E(R)FLAGS, E(R)IP, E(R)MISC, up to 11/19 of them might be
+	 * useful at present. So expand this array to 16/32 to leave room.
+	 */
+	struct mcinfo_msr mc_msr[sizeof(void *) * 4];
+};
+
+/* Recovery Action flags. Giving recovery result information to DOM0 */
+
+/* Xen takes successful recovery action, the error is recovered */
+#define REC_ACTION_RECOVERED (0x1 << 0)
+/* No action is performed by XEN */
+#define REC_ACTION_NONE (0x1 << 1)
+/* It's possible DOM0 might take action ownership in some case */
+#define REC_ACTION_NEED_RESET (0x1 << 2)
+
+/* Different Recovery Action types, if the action is performed successfull=
y,
+ * REC_ACTION_RECOVERED flag will be returned.
+ */
+
+/* Page Offline Action */
+#define MC_ACTION_PAGE_OFFLINE (0x1 << 0)
+/* CPU offline Action */
+#define MC_ACTION_CPU_OFFLINE (0x1 << 1)
+/* L3 cache disable Action */
+#define MC_ACTION_CACHE_SHRINK (0x1 << 2)
+
+/* Below interface used between XEN/DOM0 for passing XEN's recovery action
+ * information to DOM0.
+ * usage Senario: After offlining broken page, XEN might pass its page off=
line
+ * recovery action result to DOM0. DOM0 will save the information in
+ * non-volatile memory for further proactive actions, such as offlining th=
e
+ * easy broken page earlier when doing next reboot.
+*/
+struct page_offline_action {
+	/* Params for passing the offlined page number to DOM0 */
+	uint64_t mfn;
+	uint64_t status;
+};
+
+struct cpu_offline_action {
+	/* Params for passing the identity of the offlined CPU to DOM0 */
+	uint32_t mc_socketid;
+	uint16_t mc_coreid;
+	uint16_t mc_core_threadid;
+};
+
+#define MAX_UNION_SIZE 16
+struct mcinfo_recovery {
+	struct mcinfo_common common;
+	uint16_t mc_bank; /* bank nr */
+	/* Recovery Action Flags defined above such as REC_ACTION_DONE */
+	uint8_t action_flags;
+	/* Recovery Action types defined above such as MC_ACTION_PAGE_OFFLINE */
+	uint8_t action_types;
+	/* In future if more than one recovery action permitted per error bank,
+	 * a mcinfo_recovery data array will be returned
+	 */
+	union {
+		struct page_offline_action page_retire;
+		struct cpu_offline_action cpu_offline;
+		uint8_t pad[MAX_UNION_SIZE];
+	} action_info;
+};
+
+
+#define MCINFO_HYPERCALLSIZE	1024
+#define MCINFO_MAXSIZE		768
+
+struct mc_info {
+	/* Number of mcinfo_* entries in mi_data */
+	uint32_t mi_nentries;
+	uint32_t _pad0;
+	uint64_t mi_data[(MCINFO_MAXSIZE - 1) / 8];
+};
+typedef struct mc_info mc_info_t;
+DEFINE_GUEST_HANDLE_STRUCT(mc_info);
+
+#define __MC_MSR_ARRAYSIZE 8
+#define __MC_NMSRS 1
+#define MC_NCAPS	7	/* 7 CPU feature flag words */
+#define MC_CAPS_STD_EDX	0	/* cpuid level 0x00000001 (%edx) */
+#define MC_CAPS_AMD_EDX	1	/* cpuid level 0x80000001 (%edx) */
+#define MC_CAPS_TM	2	/* cpuid level 0x80860001 (TransMeta) */
+#define MC_CAPS_LINUX	3	/* Linux-defined */
+#define MC_CAPS_STD_ECX	4	/* cpuid level 0x00000001 (%ecx) */
+#define MC_CAPS_VIA	5	/* cpuid level 0xc0000001 */
+#define MC_CAPS_AMD_ECX	6	/* cpuid level 0x80000001 (%ecx) */
+
+struct mcinfo_logical_cpu {
+	uint32_t mc_cpunr;
+	uint32_t mc_chipid;
+	uint16_t mc_coreid;
+	uint16_t mc_threadid;
+	uint32_t mc_apicid;
+	uint32_t mc_clusterid;
+	uint32_t mc_ncores;
+	uint32_t mc_ncores_active;
+	uint32_t mc_nthreads;
+	int32_t mc_cpuid_level;
+	uint32_t mc_family;
+	uint32_t mc_vendor;
+	uint32_t mc_model;
+	uint32_t mc_step;
+	char mc_vendorid[16];
+	char mc_brandid[64];
+	uint32_t mc_cpu_caps[MC_NCAPS];
+	uint32_t mc_cache_size;
+	uint32_t mc_cache_alignment;
+	int32_t mc_nmsrvals;
+	struct mcinfo_msr mc_msrvalues[__MC_MSR_ARRAYSIZE];
+};
+typedef struct mcinfo_logical_cpu mcinfo_logical_cpu_t;
+DEFINE_GUEST_HANDLE_STRUCT(mcinfo_logical_cpu);
+
+
+/*
+ * OS's should use these instead of writing their own lookup function
+ * each with its own bugs and drawbacks.
+ * We use macros instead of static inline functions to allow guests
+ * to include this header in assembly files (*.S).
+ */
+/* Prototype:
+ *    uint32_t x86_mcinfo_nentries(struct mc_info *mi);
+ */
+#define x86_mcinfo_nentries(_mi)    \
+    ((_mi)->mi_nentries)
+/* Prototype:
+ *    struct mcinfo_common *x86_mcinfo_first(struct mc_info *mi);
+ */
+#define x86_mcinfo_first(_mi)       \
+    ((struct mcinfo_common *)(_mi)->mi_data)
+/* Prototype:
+ *    struct mcinfo_common *x86_mcinfo_next(struct mcinfo_common *mic);
+ */
+#define x86_mcinfo_next(_mic)       \
+    ((struct mcinfo_common *)((uint8_t *)(_mic) + (_mic)->size))
+
+/* Prototype:
+ *    void x86_mcinfo_lookup(void *ret, struct mc_info *mi, uint16_t type)=
;
+ */
+
+static inline void x86_mcinfo_lookup
+	(struct mcinfo_common **ret, struct mc_info *mi, uint16_t type)
+{
+	uint32_t found =3D 0, i;
+	struct mcinfo_common *mic;
+
+	*ret =3D NULL;
+	if (!mi)
+		return;
+	mic =3D x86_mcinfo_first(mi);
+
+	for (i =3D 0; i < x86_mcinfo_nentries(mi); i++) {
+		if (mic->type =3D=3D type) {
+			found =3D 1;
+			break;
+		}
+		mic =3D x86_mcinfo_next(mic);
+	}
+
+	*ret =3D found ? mic : NULL;
+}
+/* Usecase 1
+ * Register machine check trap callback handler
+ *    (already done via "set_trap_table" hypercall)
+ */
+
+/* Usecase 2
+ * Dom0 registers machine check event callback handler
+ * done by EVTCHNOP_bind_virq
+ */
+
+/* Usecase 3
+ * Fetch machine check data from hypervisor.
+ * Note, this hypercall is special, because both Dom0 and DomU must use th=
is.
+ */
+#define XEN_MC_fetch            1
+struct xen_mc_fetch {
+    /* IN/OUT variables.
+	 * IN: XEN_MC_NONURGENT, XEN_MC_URGENT,
+	 * XEN_MC_ACK if ack'king an earlier fetch
+	 * OUT: XEN_MC_OK, XEN_MC_FETCHAILED,
+	 * XEN_MC_NODATA, XEN_MC_NOMATCH
+	*/
+	uint32_t flags;
+	uint32_t _pad0;
+	/* OUT: id for ack, IN: id we are ack'ing */
+	uint64_t fetch_id;
+
+	/* OUT variables. */
+	GUEST_HANDLE(mc_info) data;
+};
+typedef struct xen_mc_fetch xen_mc_fetch_t;
+DEFINE_GUEST_HANDLE_STRUCT(xen_mc_fetch);
+
+
+/* Usecase 4
+ * This tells the hypervisor to notify a DomU about the machine check erro=
r
+ */
+#define XEN_MC_notifydomain     2
+struct xen_mc_notifydomain {
+	/* IN variables. */
+	uint16_t mc_domid;/* The unprivileged domain to notify. */
+	uint16_t mc_vcpuid;/* The vcpu in mc_domid to notify.
+			* Usually echo'd value from the fetch hypercall. */
+
+	/* IN/OUT variables. */
+	uint32_t flags;
+
+/* OUT: XEN_MC_OK, XEN_MC_CANNOTHANDLE, XEN_MC_NOTDELIVERED, XEN_MC_NOMATC=
H */
+};
+typedef struct xen_mc_notifydomain xen_mc_notifydomain_t;
+DEFINE_GUEST_HANDLE_STRUCT(xen_mc_notifydomain);
+
+#define XEN_MC_physcpuinfo 3
+struct xen_mc_physcpuinfo {
+	/* IN/OUT */
+	uint32_t ncpus;
+	uint32_t _pad0;
+	/* OUT */
+	GUEST_HANDLE(mcinfo_logical_cpu) info;
+};
+
+#define XEN_MC_msrinject    4
+#define MC_MSRINJ_MAXMSRS       8
+struct xen_mc_msrinject {
+	/* IN */
+	uint32_t mcinj_cpunr;/* target processor id */
+	uint32_t mcinj_flags;/* see MC_MSRINJ_F_* below */
+	uint32_t mcinj_count;/* 0 .. count-1 in array are valid */
+	uint32_t _pad0;
+	struct mcinfo_msr mcinj_msr[MC_MSRINJ_MAXMSRS];
+};
+
+/* Flags for mcinj_flags above; bits 16-31 are reserved */
+#define MC_MSRINJ_F_INTERPOSE   0x1
+
+#define XEN_MC_mceinject    5
+struct xen_mc_mceinject {
+	unsigned int mceinj_cpunr;      /* target processor id */
+};
+
+struct xen_mc {
+	uint32_t cmd;
+	uint32_t interface_version; /* XEN_MCA_INTERFACE_VERSION */
+	union {
+		struct xen_mc_fetch        mc_fetch;
+		struct xen_mc_notifydomain mc_notifydomain;
+		struct xen_mc_physcpuinfo  mc_physcpuinfo;
+		struct xen_mc_msrinject    mc_msrinject;
+		struct xen_mc_mceinject    mc_mceinject;
+	} u;
+};
+typedef struct xen_mc xen_mc_t;
+DEFINE_GUEST_HANDLE_STRUCT(xen_mc);
+
+#endif /* __ASSEMBLY__ */
+
+#endif /* __XEN_PUBLIC_ARCH_X86_MCA_H__ */
--=20
1.6.5.6

--_002_DE8DF0795D48FD4CA783C40EC82923359699SHSMSX101ccrcorpint_
Content-Type: application/octet-stream;
	name="0001-Add-mcelog-support-from-xen-platform.patch"
Content-Description: 0001-Add-mcelog-support-from-xen-platform.patch
Content-Disposition: attachment;
	filename="0001-Add-mcelog-support-from-xen-platform.patch"; size=25075;
	creation-date="Wed, 14 Dec 2011 15:20:15 GMT";
	modification-date="Wed, 14 Dec 2011 15:03:34 GMT"
Content-Transfer-Encoding: base64

RnJvbSAwZThkZTFjZTBmMTNhYTM0YWE2MDEzZTZhMzg3YWU1YmU3ODAzMWNhIE1vbiBTZXAgMTcg
MDA6MDA6MDAgMjAwMQpGcm9tOiBMaXUgSmluc29uZyA8amluc29uZy5saXVAaW50ZWwuY29tPgpE
YXRlOiBUdWUsIDYgRGVjIDIwMTEgMTg6MDg6MTIgKzA4MDAKU3ViamVjdDogW1BBVENIIDAxLzEw
XSBBZGQgbWNlbG9nIHN1cHBvcnQgZnJvbSB4ZW4gcGxhdGZvcm0KClRoaXMgcGF0Y2ggYmFja3Bv
cnQgZnJvbSBKZXJlbXkncyBwdm9wcyBjb21taXQgYTVlZDFmM2RhZTE3OTE1OGUzODVlOTM3MTQ2
MmRkNjVkNWUxMjVjNSwKd2hpY2ggaW4gdHVybiBiYWNrcG9ydCBmcm9tIHByZXZpb3VzIHhlbiBE
T00wKDIuNi4xOCkgY3M6IDc1ZTViZmE3ZmJkYwoKV2hlbiBhIE1DRS9DTUNJIGVycm9yIGhhcHBl
bnMgKG9yIGJ5IHBvbGxpbmcpLCB0aGUgcmVsYXRlZCBlcnJvcgppbmZvcm1hdGlvbiB3aWxsIGJl
IHNlbnQgdG8gcHJpdmlsZWdlZCBwdi1vcHMgZG9tYWluIGJ5IFhFTi4gVGhpcwpwYXRjaCB3aWxs
IGhlbHAgdG8gZmV0Y2ggdGhlIHhlbi1sb2dnZWQgaW5mb3JtYXRpb24gYnkgaHlwZXJjYWxsCmFu
ZCB0aGVuIGNvbnZlcnQgWEVOLWZvcm1hdCBsb2cgaW50byBMaW51eCBmb3JtYXQgTUNFTE9HLiBJ
dCBtYWtlcwp1c2luZyBjdXJyZW50IGF2YWlsYWJsZSBtY2Vsb2cgdG9vbHMgZm9yIG5hdGl2ZSBM
aW51eCBwb3NzaWJsZS4KCldpdGggdGhpcyBwYXRjaCwgYWZ0ZXIgbWNlL2NtY2kgZXJyb3IgbG9n
IGluZm9ybWF0aW9uIGlzIHNlbnQgdG8KcHYtb3BzIGd1ZXN0LCBSdW5uaW5nIG1jZWxvZyB0b29s
cyBpbiB0aGUgZ3Vlc3QsIHlvdSB3aWxsIGdldCBzYW1lCmRldGFpbGVkIGRlY29kZWQgbWNlIGlu
Zm9ybWF0aW9uIGFzIGluIE5hdGl2ZSBMaW51eC4KClNpZ25lZC1vZmYtYnk6IExpdSwgSmluc29u
ZyA8amluc29uZy5saXVAaW50ZWwuY29tPgpTaWduZWQtb2ZmLWJ5OiBLZSwgTGlwaW5nIDxsaXBp
bmcua2VAaW50ZWwuY29tPgpTaWduZWQtb2ZmLWJ5OiBKaWFuZywgWXVuaG9uZyA8eXVuaG9uZy5q
aWFuZ0BpbnRlbC5jb20+ClNpZ25lZC1vZmYtYnk6IEplcmVteSBGaXR6aGFyZGluZ2UgPGplcmVt
eS5maXR6aGFyZGluZ2VAY2l0cml4LmNvbT4KLS0tCiBhcmNoL3g4Ni9pbmNsdWRlL2FzbS94ZW4v
aHlwZXJjYWxsLmggfCAgICA4ICsKIGFyY2gveDg2L3hlbi9lbmxpZ2h0ZW4uYyAgICAgICAgICAg
ICB8ICAgIDggKy0KIGRyaXZlcnMveGVuL0tjb25maWcgICAgICAgICAgICAgICAgICB8ICAgIDgg
KwogZHJpdmVycy94ZW4vTWFrZWZpbGUgICAgICAgICAgICAgICAgIHwgICAgMSArCiBkcml2ZXJz
L3hlbi9tY2Vsb2cuYyAgICAgICAgICAgICAgICAgfCAgMjE3ICsrKysrKysrKysrKysrKysrCiBp
bmNsdWRlL3hlbi9pbnRlcmZhY2UveGVuLW1jYS5oICAgICAgfCAgNDI5ICsrKysrKysrKysrKysr
KysrKysrKysrKysrKysrKysrKysKIDYgZmlsZXMgY2hhbmdlZCwgNjY3IGluc2VydGlvbnMoKyks
IDQgZGVsZXRpb25zKC0pCiBjcmVhdGUgbW9kZSAxMDA2NDQgZHJpdmVycy94ZW4vbWNlbG9nLmMK
IGNyZWF0ZSBtb2RlIDEwMDY0NCBpbmNsdWRlL3hlbi9pbnRlcmZhY2UveGVuLW1jYS5oCgpkaWZm
IC0tZ2l0IGEvYXJjaC94ODYvaW5jbHVkZS9hc20veGVuL2h5cGVyY2FsbC5oIGIvYXJjaC94ODYv
aW5jbHVkZS9hc20veGVuL2h5cGVyY2FsbC5oCmluZGV4IDU3Mjg4NTIuLjU5YzIyNmQgMTAwNjQ0
Ci0tLSBhL2FyY2gveDg2L2luY2x1ZGUvYXNtL3hlbi9oeXBlcmNhbGwuaAorKysgYi9hcmNoL3g4
Ni9pbmNsdWRlL2FzbS94ZW4vaHlwZXJjYWxsLmgKQEAgLTQ4LDYgKzQ4LDcgQEAKICNpbmNsdWRl
IDx4ZW4vaW50ZXJmYWNlL3NjaGVkLmg+CiAjaW5jbHVkZSA8eGVuL2ludGVyZmFjZS9waHlzZGV2
Lmg+CiAjaW5jbHVkZSA8eGVuL2ludGVyZmFjZS9wbGF0Zm9ybS5oPgorI2luY2x1ZGUgPHhlbi9p
bnRlcmZhY2UveGVuLW1jYS5oPgogCiAvKgogICogVGhlIGh5cGVyY2FsbCBhc21zIGhhdmUgdG8g
bWVldCBzZXZlcmFsIGNvbnN0cmFpbnRzOgpAQCAtMzAyLDYgKzMwMywxMyBAQCBIWVBFUlZJU09S
X3NldF90aW1lcl9vcCh1NjQgdGltZW91dCkKIH0KIAogc3RhdGljIGlubGluZSBpbnQKK0hZUEVS
VklTT1JfbWNhKHN0cnVjdCB4ZW5fbWMgKm1jX29wKQoreworCW1jX29wLT5pbnRlcmZhY2VfdmVy
c2lvbiA9IFhFTl9NQ0FfSU5URVJGQUNFX1ZFUlNJT047CisJcmV0dXJuIF9oeXBlcmNhbGwxKGlu
dCwgbWNhLCBtY19vcCk7Cit9CisKK3N0YXRpYyBpbmxpbmUgaW50CiBIWVBFUlZJU09SX2RvbTBf
b3Aoc3RydWN0IHhlbl9wbGF0Zm9ybV9vcCAqcGxhdGZvcm1fb3ApCiB7CiAJcGxhdGZvcm1fb3At
PmludGVyZmFjZV92ZXJzaW9uID0gWEVOUEZfSU5URVJGQUNFX1ZFUlNJT047CmRpZmYgLS1naXQg
YS9hcmNoL3g4Ni94ZW4vZW5saWdodGVuLmMgYi9hcmNoL3g4Ni94ZW4vZW5saWdodGVuLmMKaW5k
ZXggOTMwNjMyMC4uYjA3M2U0YyAxMDA2NDQKLS0tIGEvYXJjaC94ODYveGVuL2VubGlnaHRlbi5j
CisrKyBiL2FyY2gveDg2L3hlbi9lbmxpZ2h0ZW4uYwpAQCAtMjQyLDE0ICsyNDIsMTQgQEAgc3Rh
dGljIHZvaWQgX19pbml0IHhlbl9pbml0X2NwdWlkX21hc2sodm9pZCkKIAl1bnNpZ25lZCBpbnQg
eHNhdmVfbWFzazsKIAogCWNwdWlkX2xlYWYxX2VkeF9tYXNrID0KLQkJfigoMSA8PCBYODZfRkVB
VFVSRV9NQ0UpICB8ICAvKiBkaXNhYmxlIE1DRSAqLwotCQkgICgxIDw8IFg4Nl9GRUFUVVJFX01D
QSkgIHwgIC8qIGRpc2FibGUgTUNBICovCi0JCSAgKDEgPDwgWDg2X0ZFQVRVUkVfTVRSUikgfCAg
LyogZGlzYWJsZSBNVFJSICovCisJCX4oKDEgPDwgWDg2X0ZFQVRVUkVfTVRSUikgfCAgLyogZGlz
YWJsZSBNVFJSICovCiAJCSAgKDEgPDwgWDg2X0ZFQVRVUkVfQUNDKSk7ICAgLyogdGhlcm1hbCBt
b25pdG9yaW5nICovCiAKIAlpZiAoIXhlbl9pbml0aWFsX2RvbWFpbigpKQogCQljcHVpZF9sZWFm
MV9lZHhfbWFzayAmPQotCQkJfigoMSA8PCBYODZfRkVBVFVSRV9BUElDKSB8ICAvKiBkaXNhYmxl
IGxvY2FsIEFQSUMgKi8KKwkJCX4oKDEgPDwgWDg2X0ZFQVRVUkVfTUNFKSAgfCAgLyogZGlzYWJs
ZSBNQ0UgKi8KKwkJCSAgKDEgPDwgWDg2X0ZFQVRVUkVfTUNBKSAgfCAgLyogZGlzYWJsZSBNQ0Eg
Ki8KKwkJCSAgKDEgPDwgWDg2X0ZFQVRVUkVfQVBJQykgfCAgLyogZGlzYWJsZSBsb2NhbCBBUElD
ICovCiAJCQkgICgxIDw8IFg4Nl9GRUFUVVJFX0FDUEkpKTsgIC8qIGRpc2FibGUgQUNQSSAqLwog
CWF4ID0gMTsKIAl4ZW5fY3B1aWQoJmF4LCAmYngsICZjeCwgJmR4KTsKZGlmZiAtLWdpdCBhL2Ry
aXZlcnMveGVuL0tjb25maWcgYi9kcml2ZXJzL3hlbi9LY29uZmlnCmluZGV4IGU4ZmI4NWYuLmVi
MmEzMjcgMTAwNjQ0Ci0tLSBhL2RyaXZlcnMveGVuL0tjb25maWcKKysrIGIvZHJpdmVycy94ZW4v
S2NvbmZpZwpAQCAtMTE3LDYgKzExNywxNCBAQCBjb25maWcgWEVOX1NZU19IWVBFUlZJU09SCiAJ
IHZpcnR1YWwgZW52aXJvbm1lbnQsIC9zeXMvaHlwZXJ2aXNvciB3aWxsIHN0aWxsIGJlIHByZXNl
bnQsCiAJIGJ1dCB3aWxsIGhhdmUgbm8geGVuIGNvbnRlbnRzLgogCitjb25maWcgWEVOX01DRV9M
T0cKKwlib29sICJYZW4gcGxhdGZvcm0gbWNlbG9nIgorCWRlcGVuZHMgb24gWEVOX0RPTTAgJiYg
WDg2XzY0ICYmIFg4Nl9NQ0UKKwlkZWZhdWx0IHkKKwloZWxwCisJICBBbGxvdyBrZXJuZWwgZmV0
Y2hpbmcgbWNlIGxvZyBmcm9tIHhlbiBwbGF0Zm9ybSBhbmQKKwkgIGNvbnZlcnRpbmcgaXQgaW50
byBsaW51eCBtY2Vsb2cgZm9ybWF0IGZvciBtY2Vsb2cgdG9vbHMKKwogY29uZmlnIEFDUElfUFJP
Q0VTU09SX1hFTgogCXRyaXN0YXRlCiAJZGVwZW5kcyBvbiBYRU5fRE9NMCAmJiBBQ1BJX1BST0NF
U1NPUiAmJiBDUFVfRlJFUQpkaWZmIC0tZ2l0IGEvZHJpdmVycy94ZW4vTWFrZWZpbGUgYi9kcml2
ZXJzL3hlbi9NYWtlZmlsZQppbmRleCBkNDJkYTUzLi40MDVjY2U5IDEwMDY0NAotLS0gYS9kcml2
ZXJzL3hlbi9NYWtlZmlsZQorKysgYi9kcml2ZXJzL3hlbi9NYWtlZmlsZQpAQCAtMTQsNiArMTQs
NyBAQCBvYmotJChDT05GSUdfWEVOX0dOVERFVikJCSs9IHhlbi1nbnRkZXYubwogb2JqLSQoQ09O
RklHX1hFTl9HUkFOVF9ERVZfQUxMT0MpCSs9IHhlbi1nbnRhbGxvYy5vCiBvYmotJChDT05GSUdf
WEVORlMpCQkJKz0geGVuZnMvCiBvYmotJChDT05GSUdfWEVOX1NZU19IWVBFUlZJU09SKQkrPSBz
eXMtaHlwZXJ2aXNvci5vCitvYmotJChDT05GSUdfWEVOX01DRV9MT0cpCQkrPSBtY2Vsb2cubwog
b2JqLSQoQ09ORklHX1hFTl9QTEFURk9STV9QQ0kpCQkrPSB4ZW4tcGxhdGZvcm0tcGNpLm8KIG9i
ai0kKENPTkZJR19YRU5fVE1FTSkJCQkrPSB0bWVtLm8KIG9iai0kKENPTkZJR19TV0lPVExCX1hF
TikJCSs9IHN3aW90bGIteGVuLm8KZGlmZiAtLWdpdCBhL2RyaXZlcnMveGVuL21jZWxvZy5jIGIv
ZHJpdmVycy94ZW4vbWNlbG9nLmMKbmV3IGZpbGUgbW9kZSAxMDA2NDQKaW5kZXggMDAwMDAwMC4u
ODkyY2E3YgotLS0gL2Rldi9udWxsCisrKyBiL2RyaXZlcnMveGVuL21jZWxvZy5jCkBAIC0wLDAg
KzEsMjE3IEBACisvKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqCisgKiBtY2Vsb2cuYworICogQWRkIE1h
Y2hpbmUgQ2hlY2sgZXZlbnQgTG9nZ2luZyBzdXBwb3J0IGluIERPTTAKKyAqCisgKiBEcml2ZXIg
Zm9yIHJlY2VpdmluZyBhbmQgbG9nZ2luZyBtYWNoaW5lIGNoZWNrIGV2ZW50CisgKgorICogQ29w
eXJpZ2h0IChjKSAyMDA4LCAyMDA5IEludGVsIENvcnBvcmF0aW9uCisgKgorICogVGhpcyBwcm9n
cmFtIGlzIGZyZWUgc29mdHdhcmU7IHlvdSBjYW4gcmVkaXN0cmlidXRlIGl0IGFuZC9vcgorICog
bW9kaWZ5IGl0IHVuZGVyIHRoZSB0ZXJtcyBvZiB0aGUgR05VIEdlbmVyYWwgUHVibGljIExpY2Vu
c2UgdmVyc2lvbiAyCisgKiBhcyBwdWJsaXNoZWQgYnkgdGhlIEZyZWUgU29mdHdhcmUgRm91bmRh
dGlvbjsgb3IsIHdoZW4gZGlzdHJpYnV0ZWQKKyAqIHNlcGFyYXRlbHkgZnJvbSB0aGUgTGludXgg
a2VybmVsIG9yIGluY29ycG9yYXRlZCBpbnRvIG90aGVyCisgKiBzb2Z0d2FyZSBwYWNrYWdlcywg
c3ViamVjdCB0byB0aGUgZm9sbG93aW5nIGxpY2Vuc2U6CisgKgorICogUGVybWlzc2lvbiBpcyBo
ZXJlYnkgZ3JhbnRlZCwgZnJlZSBvZiBjaGFyZ2UsIHRvIGFueSBwZXJzb24gb2J0YWluaW5nIGEg
Y29weQorICogb2YgdGhpcyBzb3VyY2UgZmlsZSAodGhlICJTb2Z0d2FyZSIpLCB0byBkZWFsIGlu
IHRoZSBTb2Z0d2FyZSB3aXRob3V0CisgKiByZXN0cmljdGlvbiwgaW5jbHVkaW5nIHdpdGhvdXQg
bGltaXRhdGlvbiB0aGUgcmlnaHRzIHRvIHVzZSwgY29weSwgbW9kaWZ5LAorICogbWVyZ2UsIHB1
Ymxpc2gsIGRpc3RyaWJ1dGUsIHN1YmxpY2Vuc2UsIGFuZC9vciBzZWxsIGNvcGllcyBvZiB0aGUg
U29mdHdhcmUsCisgKiBhbmQgdG8gcGVybWl0IHBlcnNvbnMgdG8gd2hvbSB0aGUgU29mdHdhcmUg
aXMgZnVybmlzaGVkIHRvIGRvIHNvLCBzdWJqZWN0IHRvCisgKiB0aGUgZm9sbG93aW5nIGNvbmRp
dGlvbnM6CisgKgorICogVGhlIGFib3ZlIGNvcHlyaWdodCBub3RpY2UgYW5kIHRoaXMgcGVybWlz
c2lvbiBub3RpY2Ugc2hhbGwgYmUgaW5jbHVkZWQgaW4KKyAqIGFsbCBjb3BpZXMgb3Igc3Vic3Rh
bnRpYWwgcG9ydGlvbnMgb2YgdGhlIFNvZnR3YXJlLgorICoKKyAqIFRIRSBTT0ZUV0FSRSBJUyBQ
Uk9WSURFRCAiQVMgSVMiLCBXSVRIT1VUIFdBUlJBTlRZIE9GIEFOWSBLSU5ELCBFWFBSRVNTIE9S
CisgKiBJTVBMSUVELCBJTkNMVURJTkcgQlVUIE5PVCBMSU1JVEVEIFRPIFRIRSBXQVJSQU5USUVT
IE9GIE1FUkNIQU5UQUJJTElUWSwKKyAqIEZJVE5FU1MgRk9SIEEgUEFSVElDVUxBUiBQVVJQT1NF
IEFORCBOT05JTkZSSU5HRU1FTlQuIElOIE5PIEVWRU5UIFNIQUxMIFRIRQorICogQVVUSE9SUyBP
UiBDT1BZUklHSFQgSE9MREVSUyBCRSBMSUFCTEUgRk9SIEFOWSBDTEFJTSwgREFNQUdFUyBPUiBP
VEhFUgorICogTElBQklMSVRZLCBXSEVUSEVSIElOIEFOIEFDVElPTiBPRiBDT05UUkFDVCwgVE9S
VCBPUiBPVEhFUldJU0UsIEFSSVNJTkcKKyAqIEZST00sIE9VVCBPRiBPUiBJTiBDT05ORUNUSU9O
IFdJVEggVEhFIFNPRlRXQVJFIE9SIFRIRSBVU0UgT1IgT1RIRVIgREVBTElOR1MKKyAqIElOIFRI
RSBTT0ZUV0FSRS4KKyAqLworCisjaW5jbHVkZSA8bGludXgvbW9kdWxlLmg+CisjaW5jbHVkZSA8
bGludXgvaW5pdC5oPgorI2luY2x1ZGUgPGxpbnV4L3R5cGVzLmg+CisjaW5jbHVkZSA8bGludXgv
a2VybmVsLmg+CisjaW5jbHVkZSA8bGludXgvc2xhYi5oPgorI2luY2x1ZGUgPHhlbi9pbnRlcmZh
Y2UveGVuLmg+CisjaW5jbHVkZSA8YXNtL3hlbi9oeXBlcnZpc29yLmg+CisjaW5jbHVkZSA8eGVu
L2V2ZW50cy5oPgorI2luY2x1ZGUgPHhlbi9pbnRlcmZhY2UvdmNwdS5oPgorI2luY2x1ZGUgPGFz
bS94ZW4vaHlwZXJjYWxsLmg+CisjaW5jbHVkZSA8YXNtL21jZS5oPgorI2luY2x1ZGUgPHhlbi94
ZW4uaD4KKworc3RhdGljIG1jX2luZm9fdCAqZ19taTsKK3N0YXRpYyBtY2luZm9fbG9naWNhbF9j
cHVfdCAqZ19waHlzaW5mbzsKK3N0YXRpYyB1aW50MzJfdCBuY3B1czsKKworc3RhdGljIGludCBj
b252ZXJ0X2xvZyhzdHJ1Y3QgbWNfaW5mbyAqbWkpCit7CisJc3RydWN0IG1jaW5mb19jb21tb24g
Km1pYyA9IE5VTEw7CisJc3RydWN0IG1jaW5mb19nbG9iYWwgKm1jX2dsb2JhbDsKKwlzdHJ1Y3Qg
bWNpbmZvX2JhbmsgKm1jX2Jhbms7CisJc3RydWN0IG1jZSBtOworCWludCBpLCBmb3VuZCA9IDA7
CisKKwl4ODZfbWNpbmZvX2xvb2t1cCgmbWljLCBtaSwgTUNfVFlQRV9HTE9CQUwpOworCVdBUk5f
T04oIW1pYyk7CisKKwltY2Vfc2V0dXAoJm0pOworCW1jX2dsb2JhbCA9IChzdHJ1Y3QgbWNpbmZv
X2dsb2JhbCAqKW1pYzsKKwltLm1jZ3N0YXR1cyA9IG1jX2dsb2JhbC0+bWNfZ3N0YXR1czsKKwlt
LmFwaWNpZCA9IG1jX2dsb2JhbC0+bWNfYXBpY2lkOworCWZvciAoaSA9IDA7IGkgPCBuY3B1czsg
aSsrKSB7CisJCWlmIChnX3BoeXNpbmZvW2ldLm1jX2FwaWNpZCA9PSBtLmFwaWNpZCkgeworCQkJ
Zm91bmQgPSAxOworCQkJYnJlYWs7CisJCX0KKwl9CisJV0FSTl9PTighZm91bmQpOworCisJbS5z
b2NrZXRpZCA9IGdfcGh5c2luZm9baV0ubWNfY2hpcGlkOworCW0uY3B1ID0gbS5leHRjcHUgPSBn
X3BoeXNpbmZvW2ldLm1jX2NwdW5yOworCW0uY3B1dmVuZG9yID0gKF9fdTgpZ19waHlzaW5mb1tp
XS5tY192ZW5kb3I7CisJbS5tY2djYXAgPSBnX3BoeXNpbmZvW2ldLm1jX21zcnZhbHVlc1swXS52
YWx1ZTsKKwl4ODZfbWNpbmZvX2xvb2t1cCgmbWljLCBtaSwgTUNfVFlQRV9CQU5LKTsKKwlkbyB7
CisJCWlmIChtaWMgPT0gTlVMTCB8fCBtaWMtPnNpemUgPT0gMCkKKwkJCWJyZWFrOworCQlpZiAo
bWljLT50eXBlID09IE1DX1RZUEVfQkFOSykgeworCQkJbWNfYmFuayA9IChzdHJ1Y3QgbWNpbmZv
X2JhbmsgKiltaWM7CisJCQltLm1pc2MgPSBtY19iYW5rLT5tY19taXNjOworCQkJbS5zdGF0dXMg
PSBtY19iYW5rLT5tY19zdGF0dXM7CisJCQltLmFkZHIgPSBtY19iYW5rLT5tY19hZGRyOworCQkJ
bS50c2MgPSBtY19iYW5rLT5tY190c2M7CisJCQltLmJhbmsgPSBtY19iYW5rLT5tY19iYW5rOwor
CQkJbS5maW5pc2hlZCA9IDE7CisJCQkvKmxvZyB0aGlzIHJlY29yZCovCisJCQltY2VfbG9nKCZt
KTsKKwkJfQorCQltaWMgPSB4ODZfbWNpbmZvX25leHQobWljKTsKKwl9IHdoaWxlICgxKTsKKwor
CXJldHVybiAwOworfQorCisvKnB2X29wcyBkb21haW4gbWNlIHZpcnEgaGFuZGxlciwgbG9nZ2lu
ZyBwaHlzaWNhbCBtY2UgZXJyb3IgaW5mbyovCitzdGF0aWMgaXJxcmV0dXJuX3QgbWNlX2RvbV9p
bnRlcnJ1cHQoaW50IGlycSwgdm9pZCAqZGV2X2lkKQoreworCXhlbl9tY190IG1jX29wOworCWlu
dCByZXN1bHQgPSAwOworCisJbWNfb3AuY21kID0gWEVOX01DX2ZldGNoOworCW1jX29wLmludGVy
ZmFjZV92ZXJzaW9uID0gWEVOX01DQV9JTlRFUkZBQ0VfVkVSU0lPTjsKKwlzZXRfeGVuX2d1ZXN0
X2hhbmRsZShtY19vcC51Lm1jX2ZldGNoLmRhdGEsIGdfbWkpOwordXJnZW50OgorCW1jX29wLnUu
bWNfZmV0Y2guZmxhZ3MgPSBYRU5fTUNfVVJHRU5UOworCXJlc3VsdCA9IEhZUEVSVklTT1JfbWNh
KCZtY19vcCk7CisJaWYgKHJlc3VsdCB8fCBtY19vcC51Lm1jX2ZldGNoLmZsYWdzICYgWEVOX01D
X05PREFUQSB8fAorCQkJbWNfb3AudS5tY19mZXRjaC5mbGFncyAmIFhFTl9NQ19GRVRDSEZBSUxF
RCkKKwkJZ290byBub251cmdlbnQ7CisJZWxzZSB7CisJCXJlc3VsdCA9IGNvbnZlcnRfbG9nKGdf
bWkpOworCQlpZiAocmVzdWx0KQorCQkJZ290byBlbmQ7CisJCS8qIEFmdGVyIGZldGNoaW5nIHRo
ZSBlcnJvciBldmVudCBsb2cgZW50cnkgZnJvbSBET00wLAorCQkgKiB3ZSBuZWVkIHRvIGRlYyB0
aGUgcmVmY250IGFuZCByZWxlYXNlIHRoZSBlbnRyeS4KKwkJICogVGhlIGVudHJ5IGlzIHJlc2Vy
dmVkIGFuZCBpbmMgcmVmY250IHdoZW4gZmlsbGluZworCQkgKiB0aGUgZXJyb3IgbG9nIGVudHJ5
LgorCQkgKi8KKwkJbWNfb3AudS5tY19mZXRjaC5mbGFncyA9IFhFTl9NQ19VUkdFTlQgfCBYRU5f
TUNfQUNLOworCQlyZXN1bHQgPSBIWVBFUlZJU09SX21jYSgmbWNfb3ApOworCQlnb3RvIHVyZ2Vu
dDsKKwl9Citub251cmdlbnQ6CisJbWNfb3AudS5tY19mZXRjaC5mbGFncyA9IFhFTl9NQ19OT05V
UkdFTlQ7CisJcmVzdWx0ID0gSFlQRVJWSVNPUl9tY2EoJm1jX29wKTsKKwlpZiAocmVzdWx0IHx8
IG1jX29wLnUubWNfZmV0Y2guZmxhZ3MgJiBYRU5fTUNfTk9EQVRBIHx8CisJCQltY19vcC51Lm1j
X2ZldGNoLmZsYWdzICYgWEVOX01DX0ZFVENIRkFJTEVEKQorCQlnb3RvIGVuZDsKKwllbHNlIHsK
KwkJcmVzdWx0ID0gY29udmVydF9sb2coZ19taSk7CisJCWlmIChyZXN1bHQpCisJCQlnb3RvIGVu
ZDsKKwkJLyogQWZ0ZXIgZmV0Y2hpbmcgdGhlIGVycm9yIGV2ZW50IGxvZyBlbnRyeSBmcm9tIERP
TTAsCisJCSAqIHdlIG5lZWQgdG8gZGVjIHRoZSByZWZjbnQgYW5kIHJlbGVhc2UgdGhlIGVudHJ5
LiBUaGUKKwkJICogZW50cnkgaXMgcmVzZXJ2ZWQgYW5kIGluYyByZWZjbnQgd2hlbiBmaWxsaW5n
IHRoZQorCQkgKiBlcnJvciBsb2cgZW50cnkuCisJCSAqLworCQltY19vcC51Lm1jX2ZldGNoLmZs
YWdzID0gWEVOX01DX05PTlVSR0VOVCB8IFhFTl9NQ19BQ0s7CisJCXJlc3VsdCA9IEhZUEVSVklT
T1JfbWNhKCZtY19vcCk7CisJCWdvdG8gbm9udXJnZW50OworCX0KK2VuZDoKKwlyZXR1cm4gSVJR
X0hBTkRMRUQ7Cit9CisKK3N0YXRpYyBpbnQgYmluZF92aXJxX2Zvcl9tY2Uodm9pZCkKK3sKKwlp
bnQgcmV0OworCXhlbl9tY190IG1jX29wOworCisJZ19taSA9IGttYWxsb2Moc2l6ZW9mKHN0cnVj
dCBtY19pbmZvKSwgR0ZQX0tFUk5FTCk7CisKKwlpZiAoIWdfbWkpCisJCXJldHVybiAtRU5PTUVN
OworCisJLyogRmV0Y2ggcGh5c2ljYWwgQ1BVIE51bWJlcnMgKi8KKwltY19vcC5jbWQgPSBYRU5f
TUNfcGh5c2NwdWluZm87CisJbWNfb3AuaW50ZXJmYWNlX3ZlcnNpb24gPSBYRU5fTUNBX0lOVEVS
RkFDRV9WRVJTSU9OOworCXNldF94ZW5fZ3Vlc3RfaGFuZGxlKG1jX29wLnUubWNfcGh5c2NwdWlu
Zm8uaW5mbywgZ19waHlzaW5mbyk7CisJcmV0ID0gSFlQRVJWSVNPUl9tY2EoJm1jX29wKTsKKwlp
ZiAocmV0KSB7CisJCXByaW50ayhLRVJOX0VSUiAiTUNFX0RPTTBfTE9HOiBGYWlsIHRvIGdldCBw
aHlzaWNhbCBDUFUgbnVtYmVyc1xuIik7CisJCWtmcmVlKGdfbWkpOworCQlyZXR1cm4gcmV0Owor
CX0KKworCS8qIEZldGNoIGVhY2ggQ1BVIFBoeXNpY2FsIEluZm8gZm9yIGxhdGVyIHJlZmVyZW5j
ZSovCisJbmNwdXMgPSBtY19vcC51Lm1jX3BoeXNjcHVpbmZvLm5jcHVzOworCWdfcGh5c2luZm8g
PSBrbWFsbG9jKHNpemVvZihzdHJ1Y3QgbWNpbmZvX2xvZ2ljYWxfY3B1KSpuY3B1cywKKwkJCQkJ
R0ZQX0tFUk5FTCk7CisJaWYgKCFnX3BoeXNpbmZvKSB7CisJCWtmcmVlKGdfbWkpOworCQlyZXR1
cm4gLUVOT01FTTsKKwl9CisJc2V0X3hlbl9ndWVzdF9oYW5kbGUobWNfb3AudS5tY19waHlzY3B1
aW5mby5pbmZvLCBnX3BoeXNpbmZvKTsKKwlyZXQgPSBIWVBFUlZJU09SX21jYSgmbWNfb3ApOwor
CWlmIChyZXQpIHsKKwkJcHJpbnRrKEtFUk5fRVJSICJNQ0VfRE9NMF9MT0c6IEZhaWwgdG8gZ2V0
IHBoeXNpY2FsIENQVXMgaW5mb1xuIik7CisJCWtmcmVlKGdfbWkpOworCQlrZnJlZShnX3BoeXNp
bmZvKTsKKwkJcmV0dXJuIHJldDsKKwl9CisKKwlyZXQgID0gYmluZF92aXJxX3RvX2lycWhhbmRs
ZXIoVklSUV9NQ0EsIDAsCisJCW1jZV9kb21faW50ZXJydXB0LCAwLCAibWNlIiwgTlVMTCk7CisK
KwlpZiAocmV0IDwgMCkgeworCQlwcmludGsoS0VSTl9FUlIgIk1DRV9ET00wX0xPRzogYmluZF92
aXJxIGZvciBET00wIGZhaWxlZFxuIik7CisJCXJldHVybiByZXQ7CisJfQorCisJcmV0dXJuIDA7
Cit9CisKK3N0YXRpYyBpbnQgX19pbml0IG1jZWxvZ19pbml0KHZvaWQpCit7CisJLyogT25seSBE
T00wIGlzIHJlc3BvbnNpYmxlIGZvciBNQ0UgbG9nZ2luZyAqLworCWlmICh4ZW5faW5pdGlhbF9k
b21haW4oKSkKKwkJcmV0dXJuIGJpbmRfdmlycV9mb3JfbWNlKCk7CisKKwlyZXR1cm4gMDsKK30K
KworCitzdGF0aWMgdm9pZCBfX2V4aXQgbWNlbG9nX2NsZWFudXAodm9pZCkKK3sKKwlrZnJlZShn
X21pKTsKKwlrZnJlZShnX3BoeXNpbmZvKTsKK30KK21vZHVsZV9pbml0KG1jZWxvZ19pbml0KTsK
K21vZHVsZV9leGl0KG1jZWxvZ19jbGVhbnVwKTsKKworTU9EVUxFX0xJQ0VOU0UoIkdQTCIpOwpk
aWZmIC0tZ2l0IGEvaW5jbHVkZS94ZW4vaW50ZXJmYWNlL3hlbi1tY2EuaCBiL2luY2x1ZGUveGVu
L2ludGVyZmFjZS94ZW4tbWNhLmgKbmV3IGZpbGUgbW9kZSAxMDA2NDQKaW5kZXggMDAwMDAwMC4u
ZjMxZmRhYgotLS0gL2Rldi9udWxsCisrKyBiL2luY2x1ZGUveGVuL2ludGVyZmFjZS94ZW4tbWNh
LmgKQEAgLTAsMCArMSw0MjkgQEAKKy8qKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioKKyAqIGFyY2gteDg2
L21jYS5oCisgKgorICogQ29udHJpYnV0ZWQgYnkgQWR2YW5jZWQgTWljcm8gRGV2aWNlcywgSW5j
LgorICogQXV0aG9yOiBDaHJpc3RvcGggRWdnZXIgPENocmlzdG9waC5FZ2dlckBhbWQuY29tPgor
ICoKKyAqIEd1ZXN0IE9TIG1hY2hpbmUgY2hlY2sgaW50ZXJmYWNlIHRvIHg4NiBYZW4uCisgKgor
ICogUGVybWlzc2lvbiBpcyBoZXJlYnkgZ3JhbnRlZCwgZnJlZSBvZiBjaGFyZ2UsIHRvIGFueSBw
ZXJzb24gb2J0YWluaW5nIGEgY29weQorICogb2YgdGhpcyBzb2Z0d2FyZSBhbmQgYXNzb2NpYXRl
ZCBkb2N1bWVudGF0aW9uIGZpbGVzICh0aGUgIlNvZnR3YXJlIiksIHRvCisgKiBkZWFsIGluIHRo
ZSBTb2Z0d2FyZSB3aXRob3V0IHJlc3RyaWN0aW9uLCBpbmNsdWRpbmcgd2l0aG91dCBsaW1pdGF0
aW9uIHRoZQorICogcmlnaHRzIHRvIHVzZSwgY29weSwgbW9kaWZ5LCBtZXJnZSwgcHVibGlzaCwg
ZGlzdHJpYnV0ZSwgc3VibGljZW5zZSwgYW5kL29yCisgKiBzZWxsIGNvcGllcyBvZiB0aGUgU29m
dHdhcmUsIGFuZCB0byBwZXJtaXQgcGVyc29ucyB0byB3aG9tIHRoZSBTb2Z0d2FyZSBpcworICog
ZnVybmlzaGVkIHRvIGRvIHNvLCBzdWJqZWN0IHRvIHRoZSBmb2xsb3dpbmcgY29uZGl0aW9uczoK
KyAqCisgKiBUaGUgYWJvdmUgY29weXJpZ2h0IG5vdGljZSBhbmQgdGhpcyBwZXJtaXNzaW9uIG5v
dGljZSBzaGFsbCBiZSBpbmNsdWRlZCBpbgorICogYWxsIGNvcGllcyBvciBzdWJzdGFudGlhbCBw
b3J0aW9ucyBvZiB0aGUgU29mdHdhcmUuCisgKgorICogVEhFIFNPRlRXQVJFIElTIFBST1ZJREVE
ICJBUyBJUyIsIFdJVEhPVVQgV0FSUkFOVFkgT0YgQU5ZIEtJTkQsIEVYUFJFU1MgT1IKKyAqIElN
UExJRUQsIElOQ0xVRElORyBCVVQgTk9UIExJTUlURUQgVE8gVEhFIFdBUlJBTlRJRVMgT0YgTUVS
Q0hBTlRBQklMSVRZLAorICogRklUTkVTUyBGT1IgQSBQQVJUSUNVTEFSIFBVUlBPU0UgQU5EIE5P
TklORlJJTkdFTUVOVC4gSU4gTk8gRVZFTlQgU0hBTEwgVEhFCisgKiBBVVRIT1JTIE9SIENPUFlS
SUdIVCBIT0xERVJTIEJFIExJQUJMRSBGT1IgQU5ZIENMQUlNLCBEQU1BR0VTIE9SIE9USEVSCisg
KiBMSUFCSUxJVFksIFdIRVRIRVIgSU4gQU4gQUNUSU9OIE9GIENPTlRSQUNULCBUT1JUIE9SIE9U
SEVSV0lTRSwgQVJJU0lORworICogRlJPTSwgT1VUIE9GIE9SIElOIENPTk5FQ1RJT04gV0lUSCBU
SEUgU09GVFdBUkUgT1IgVEhFIFVTRSBPUiBPVEhFUgorICogREVBTElOR1MgSU4gVEhFIFNPRlRX
QVJFLgorICovCisKKy8qIEZ1bGwgTUNBIGZ1bmN0aW9uYWxpdHkgaGFzIHRoZSBmb2xsb3dpbmcg
VXNlY2FzZXMgZnJvbSB0aGUgZ3Vlc3Qgc2lkZToKKyAqCisgKiBNdXN0IGhhdmUnczoKKyAqIDEu
IERvbTAgYW5kIERvbVUgcmVnaXN0ZXIgbWFjaGluZSBjaGVjayB0cmFwIGNhbGxiYWNrIGhhbmRs
ZXJzCisgKiAgICAoYWxyZWFkeSBkb25lIHZpYSAic2V0X3RyYXBfdGFibGUiIGh5cGVyY2FsbCkK
KyAqIDIuIERvbTAgcmVnaXN0ZXJzIG1hY2hpbmUgY2hlY2sgZXZlbnQgY2FsbGJhY2sgaGFuZGxl
cgorICogICAgKGRvYWJsZSB2aWEgRVZUQ0hOT1BfYmluZF92aXJxKQorICogMy4gRG9tMCBhbmQg
RG9tVSBmZXRjaGVzIG1hY2hpbmUgY2hlY2sgZGF0YQorICogNC4gRG9tMCB3YW50cyBYZW4gdG8g
bm90aWZ5IGEgRG9tVQorICogNS4gRG9tMCBnZXRzIERvbVUgSUQgZnJvbSBwaHlzaWNhbCBhZGRy
ZXNzCisgKiA2LiBEb20wIHdhbnRzIFhlbiB0byBraWxsIERvbVUgKGFscmVhZHkgZG9uZSBmb3Ig
InhtIGRlc3Ryb3kiKQorICoKKyAqIE5pY2UgdG8gaGF2ZSdzOgorICogNy4gRG9tMCB3YW50cyBY
ZW4gdG8gZGVhY3RpdmF0ZSBhIHBoeXNpY2FsIENQVQorICogICAgVGhpcyBpcyBiZXR0ZXIgZG9u
ZSBhcyBzZXBhcmF0ZSB0YXNrLCBwaHlzaWNhbCBDUFUgaG90cGx1Z2dpbmcsCisgKiAgICBhbmQg
aHlwZXJjYWxsKHMpIHNob3VsZCBiZSBzeXNjdGwncworICogOC4gUGFnZSBtaWdyYXRpb24gcHJv
cG9zZWQgZnJvbSBYZW4gTlVNQSB3b3JrLCB3aGVyZSBEb20wIGNhbiB0ZWxsIFhlbiB0bworICog
ICAgbW92ZSBhIERvbVUgKG9yIERvbTAgaXRzZWxmKSBhd2F5IGZyb20gYSBtYWxpY2lvdXMgcGFn
ZQorICogICAgcHJvZHVjaW5nIGNvcnJlY3RhYmxlIGVycm9ycy4KKyAqIDkuIG9mZmxpbmluZyBw
aHlzaWNhbCBwYWdlOgorICogICAgWGVuIGZyZWUncyBhbmQgbmV2ZXIgcmUtdXNlcyBhIGNlcnRh
aW4gcGh5c2ljYWwgcGFnZS4KKyAqIDEwLiBUZXN0ZmFjaWxpdHk6IEFsbG93IERvbTAgdG8gd3Jp
dGUgdmFsdWVzIGludG8gbWFjaGluZSBjaGVjayBNU1IncworICogICAgIGFuZCB0ZWxsIFhlbiB0
byB0cmlnZ2VyIGEgbWFjaGluZSBjaGVjaworICovCisKKyNpZm5kZWYgX19YRU5fUFVCTElDX0FS
Q0hfWDg2X01DQV9IX18KKyNkZWZpbmUgX19YRU5fUFVCTElDX0FSQ0hfWDg2X01DQV9IX18KKwor
LyogSHlwZXJjYWxsICovCisjZGVmaW5lIF9fSFlQRVJWSVNPUl9tY2EgX19IWVBFUlZJU09SX2Fy
Y2hfMAorCisvKgorICogVGhlIHhlbi11bnN0YWJsZSByZXBvIGhhcyBpbnRlcmZhY2UgdmVyc2lv
biAweDAzMDAwMDAxOyBvdXQgaW50ZXJmYWNlCisgKiBpcyBpbmNvbXBhdGlibGUgd2l0aCB0aGF0
IGFuZCBhbnkgZnV0dXJlIG1pbm9yIHJldmlzaW9ucywgc28gd2UKKyAqIGNob29zZSBhIGRpZmZl
cmVudCB2ZXJzaW9uIG51bWJlciByYW5nZSB0aGF0IGlzIG51bWVyaWNhbGx5IGxlc3MKKyAqIHRo
YW4gdGhhdCB1c2VkIGluIHhlbi11bnN0YWJsZS4KKyAqLworI2RlZmluZSBYRU5fTUNBX0lOVEVS
RkFDRV9WRVJTSU9OIDB4MDFlY2MwMDMKKworLyogSU46IERvbTAgY2FsbHMgaHlwZXJjYWxsIHRv
IHJldHJpZXZlIG5vbnVyZ2VudCBlcnJvciBsb2cgZW50cnkgKi8KKyNkZWZpbmUgWEVOX01DX05P
TlVSR0VOVCAgMHgwMDAxCisvKiBJTjogRG9tMC9Eb21VIGNhbGxzIGh5cGVyY2FsbCB0byByZXRy
aWV2ZSB1cmdlbnQgZXJyb3IgbG9nIGVudHJ5ICovCisjZGVmaW5lIFhFTl9NQ19VUkdFTlQgICAg
IDB4MDAwMgorLyogSU46IERvbTAgYWNrbm93bGVkZ2VzIHByZXZpb3NseS1mZXRjaGVkIGVycm9y
IGxvZyBlbnRyeSAqLworI2RlZmluZSBYRU5fTUNfQUNLICAgICAgICAweDAwMDQKKworLyogT1VU
OiBBbGwgaXMgb2sgKi8KKyNkZWZpbmUgWEVOX01DX09LICAgICAgICAgICAweDAKKy8qIE9VVDog
RG9tYWluIGNvdWxkIG5vdCBmZXRjaCBkYXRhLiAqLworI2RlZmluZSBYRU5fTUNfRkVUQ0hGQUlM
RUQgIDB4MQorLyogT1VUOiBUaGVyZSB3YXMgbm8gbWFjaGluZSBjaGVjayBkYXRhIHRvIGZldGNo
LiAqLworI2RlZmluZSBYRU5fTUNfTk9EQVRBICAgICAgIDB4MgorLyogT1VUOiBCZXR3ZWVuIG5v
dGlmaWNhdGlvbiB0aW1lIGFuZCB0aGlzIGh5cGVyY2FsbCBhbiBvdGhlcgorICogIChtb3N0IGxp
a2VseSkgY29ycmVjdGFibGUgZXJyb3IgaGFwcGVuZWQuIFRoZSBmZXRjaGVkIGRhdGEsCisgKiAg
ZG9lcyBub3QgbWF0Y2ggdGhlIG9yaWdpbmFsIG1hY2hpbmUgY2hlY2sgZGF0YS4gKi8KKyNkZWZp
bmUgWEVOX01DX05PTUFUQ0ggICAgICAweDQKKworLyogT1VUOiBEb21VIGRpZCBub3QgcmVnaXN0
ZXIgTUMgTk1JIGhhbmRsZXIuIFRyeSBzb21ldGhpbmcgZWxzZS4gKi8KKyNkZWZpbmUgWEVOX01D
X0NBTk5PVEhBTkRMRSAweDgKKy8qIE9VVDogTm90aWZ5aW5nIERvbVUgZmFpbGVkLiBSZXRyeSBs
YXRlciBvciB0cnkgc29tZXRoaW5nIGVsc2UuICovCisjZGVmaW5lIFhFTl9NQ19OT1RERUxJVkVS
RUQgMHgxMAorLyogTm90ZSwgWEVOX01DX0NBTk5PVEhBTkRMRSBhbmQgWEVOX01DX05PVERFTElW
RVJFRCBhcmUgbXV0dWFsbHkgZXhjbHVzaXZlLiAqLworCisKKyNpZm5kZWYgX19BU1NFTUJMWV9f
CisKKyNkZWZpbmUgVklSUV9NQ0EgVklSUV9BUkNIXzAgLyogRy4gKERPTTApIE1hY2hpbmUgQ2hl
Y2sgQXJjaGl0ZWN0dXJlICovCisKKy8qCisgKiBNYWNoaW5lIENoZWNrIEFyY2hpdGVjdXJlOgor
ICogc3RydWN0cyBhcmUgcmVhZC1vbmx5IGFuZCB1c2VkIHRvIHJlcG9ydCBhbGwga2luZHMgb2YK
KyAqIGNvcnJlY3RhYmxlIGFuZCB1bmNvcnJlY3RhYmxlIGVycm9ycyBkZXRlY3RlZCBieSB0aGUg
SFcuCisgKiBEb20wIGFuZCBEb21VOiByZWdpc3RlciBhIGhhbmRsZXIgdG8gZ2V0IG5vdGlmaWVk
LgorICogRG9tMCBvbmx5OiBDb3JyZWN0YWJsZSBlcnJvcnMgYXJlIHJlcG9ydGVkIHZpYSBWSVJR
X01DQQorICovCisjZGVmaW5lIE1DX1RZUEVfR0xPQkFMICAgICAgICAgIDAKKyNkZWZpbmUgTUNf
VFlQRV9CQU5LICAgICAgICAgICAgMQorI2RlZmluZSBNQ19UWVBFX0VYVEVOREVEICAgICAgICAy
CisjZGVmaW5lIE1DX1RZUEVfUkVDT1ZFUlkgICAgICAgIDMKKworc3RydWN0IG1jaW5mb19jb21t
b24geworCXVpbnQxNl90IHR5cGU7ICAgICAgLyogc3RydWN0dXJlIHR5cGUgKi8KKwl1aW50MTZf
dCBzaXplOyAgICAgIC8qIHNpemUgb2YgdGhpcyBzdHJ1Y3QgaW4gYnl0ZXMgKi8KK307CisKKwor
I2RlZmluZSBNQ19GTEFHX0NPUlJFQ1RBQkxFICAgICAoMSA8PCAwKQorI2RlZmluZSBNQ19GTEFH
X1VOQ09SUkVDVEFCTEUgICAoMSA8PCAxKQorI2RlZmluZSBNQ19GTEFHX1JFQ09WRVJBQkxFCSgx
IDw8IDIpCisjZGVmaW5lIE1DX0ZMQUdfUE9MTEVECQkoMSA8PCAzKQorI2RlZmluZSBNQ19GTEFH
X1JFU0VUCQkoMSA8PCA0KQorI2RlZmluZSBNQ19GTEFHX0NNQ0kJCSgxIDw8IDUpCisjZGVmaW5l
IE1DX0ZMQUdfTUNFCQkoMSA8PCA2KQorLyogY29udGFpbnMgZ2xvYmFsIHg4NiBtYyBpbmZvcm1h
dGlvbiAqLworc3RydWN0IG1jaW5mb19nbG9iYWwgeworCXN0cnVjdCBtY2luZm9fY29tbW9uIGNv
bW1vbjsKKworCS8qIHJ1bm5pbmcgZG9tYWluIGF0IHRoZSB0aW1lIGluIGVycm9yIChtb3N0IGxp
a2VseQorCSAqIHRoZSBpbXBhY3RlZCBvbmUpICovCisJdWludDE2X3QgbWNfZG9taWQ7CisJdWlu
dDE2X3QgbWNfdmNwdWlkOyAvKiB2aXJ0dWFsIGNwdSBzY2hlZHVsZWQgZm9yIG1jX2RvbWlkICov
CisJdWludDMyX3QgbWNfc29ja2V0aWQ7IC8qIHBoeXNpY2FsIHNvY2tldCBvZiB0aGUgcGh5c2lj
YWwgY29yZSAqLworCXVpbnQxNl90IG1jX2NvcmVpZDsgLyogcGh5c2ljYWwgaW1wYWN0ZWQgY29y
ZSAqLworCXVpbnQxNl90IG1jX2NvcmVfdGhyZWFkaWQ7IC8qIGNvcmUgdGhyZWFkIG9mIHBoeXNp
Y2FsIGNvcmUgKi8KKwl1aW50MzJfdCBtY19hcGljaWQ7CisJdWludDMyX3QgbWNfZmxhZ3M7CisJ
dWludDY0X3QgbWNfZ3N0YXR1czsgLyogZ2xvYmFsIHN0YXR1cyAqLworfTsKKworLyogY29udGFp
bnMgYmFuayBsb2NhbCB4ODYgbWMgaW5mb3JtYXRpb24gKi8KK3N0cnVjdCBtY2luZm9fYmFuayB7
CisJc3RydWN0IG1jaW5mb19jb21tb24gY29tbW9uOworCisJdWludDE2X3QgbWNfYmFuazsgLyog
YmFuayBuciAqLworCXVpbnQxNl90IG1jX2RvbWlkOyAvKiBVc2VjYXNlIDU6IGRvbWFpbiByZWZl
cmVuY2VkIGJ5IG1jX2FkZHIgb24KKwkJCSogcHJpdmlsZWdlZCBwdi1vcHMgZG9tIGFuZCBpZiBt
Y19hZGRyIGlzIHZhbGlkLgorCQkJKiBOZXZlciB2YWxpZCBvbiBEb21VLiAqLworCXVpbnQ2NF90
IG1jX3N0YXR1czsgLyogYmFuayBzdGF0dXMgKi8KKwl1aW50NjRfdCBtY19hZGRyOyAgIC8qIGJh
bmsgYWRkcmVzcywgb25seSB2YWxpZAorCQkJCQkgKiBpZiBhZGRyIGJpdCBpcyBzZXQgaW4gbWNf
c3RhdHVzICovCisJdWludDY0X3QgbWNfbWlzYzsKKwl1aW50NjRfdCBtY19jdHJsMjsKKwl1aW50
NjRfdCBtY190c2M7Cit9OworCisKK3N0cnVjdCBtY2luZm9fbXNyIHsKKwl1aW50NjRfdCByZWc7
ICAgLyogTVNSICovCisJdWludDY0X3QgdmFsdWU7IC8qIE1TUiB2YWx1ZSAqLworfTsKKworLyog
Y29udGFpbnMgbWMgaW5mb3JtYXRpb24gZnJvbSBvdGhlcgorICogb3IgYWRkaXRpb25hbCBtYyBN
U1JzICovCitzdHJ1Y3QgbWNpbmZvX2V4dGVuZGVkIHsKKwlzdHJ1Y3QgbWNpbmZvX2NvbW1vbiBj
b21tb247CisKKwkvKiBZb3UgY2FuIGZpbGwgdXAgdG8gZml2ZSByZWdpc3RlcnMuCisJICogSWYg
eW91IG5lZWQgbW9yZSwgdGhlbiB1c2UgdGhpcyBzdHJ1Y3R1cmUKKwkgKiBtdWx0aXBsZSB0aW1l
cy4gKi8KKworCXVpbnQzMl90IG1jX21zcnM7IC8qIE51bWJlciBvZiBtc3Igd2l0aCB2YWxpZCB2
YWx1ZXMuICovCisJLyoKKwkgKiBDdXJyZW50bHkgSW50ZWwgZXh0ZW5kZWQgTVNSICgzMi82NCkg
aW5jbHVkZSBhbGwgZ3AgcmVnaXN0ZXJzCisJICogYW5kIEUoUilGTEFHUywgRShSKUlQLCBFKFIp
TUlTQywgdXAgdG8gMTEvMTkgb2YgdGhlbSBtaWdodCBiZQorCSAqIHVzZWZ1bCBhdCBwcmVzZW50
LiBTbyBleHBhbmQgdGhpcyBhcnJheSB0byAxNi8zMiB0byBsZWF2ZSByb29tLgorCSAqLworCXN0
cnVjdCBtY2luZm9fbXNyIG1jX21zcltzaXplb2Yodm9pZCAqKSAqIDRdOworfTsKKworLyogUmVj
b3ZlcnkgQWN0aW9uIGZsYWdzLiBHaXZpbmcgcmVjb3ZlcnkgcmVzdWx0IGluZm9ybWF0aW9uIHRv
IERPTTAgKi8KKworLyogWGVuIHRha2VzIHN1Y2Nlc3NmdWwgcmVjb3ZlcnkgYWN0aW9uLCB0aGUg
ZXJyb3IgaXMgcmVjb3ZlcmVkICovCisjZGVmaW5lIFJFQ19BQ1RJT05fUkVDT1ZFUkVEICgweDEg
PDwgMCkKKy8qIE5vIGFjdGlvbiBpcyBwZXJmb3JtZWQgYnkgWEVOICovCisjZGVmaW5lIFJFQ19B
Q1RJT05fTk9ORSAoMHgxIDw8IDEpCisvKiBJdCdzIHBvc3NpYmxlIERPTTAgbWlnaHQgdGFrZSBh
Y3Rpb24gb3duZXJzaGlwIGluIHNvbWUgY2FzZSAqLworI2RlZmluZSBSRUNfQUNUSU9OX05FRURf
UkVTRVQgKDB4MSA8PCAyKQorCisvKiBEaWZmZXJlbnQgUmVjb3ZlcnkgQWN0aW9uIHR5cGVzLCBp
ZiB0aGUgYWN0aW9uIGlzIHBlcmZvcm1lZCBzdWNjZXNzZnVsbHksCisgKiBSRUNfQUNUSU9OX1JF
Q09WRVJFRCBmbGFnIHdpbGwgYmUgcmV0dXJuZWQuCisgKi8KKworLyogUGFnZSBPZmZsaW5lIEFj
dGlvbiAqLworI2RlZmluZSBNQ19BQ1RJT05fUEFHRV9PRkZMSU5FICgweDEgPDwgMCkKKy8qIENQ
VSBvZmZsaW5lIEFjdGlvbiAqLworI2RlZmluZSBNQ19BQ1RJT05fQ1BVX09GRkxJTkUgKDB4MSA8
PCAxKQorLyogTDMgY2FjaGUgZGlzYWJsZSBBY3Rpb24gKi8KKyNkZWZpbmUgTUNfQUNUSU9OX0NB
Q0hFX1NIUklOSyAoMHgxIDw8IDIpCisKKy8qIEJlbG93IGludGVyZmFjZSB1c2VkIGJldHdlZW4g
WEVOL0RPTTAgZm9yIHBhc3NpbmcgWEVOJ3MgcmVjb3ZlcnkgYWN0aW9uCisgKiBpbmZvcm1hdGlv
biB0byBET00wLgorICogdXNhZ2UgU2VuYXJpbzogQWZ0ZXIgb2ZmbGluaW5nIGJyb2tlbiBwYWdl
LCBYRU4gbWlnaHQgcGFzcyBpdHMgcGFnZSBvZmZsaW5lCisgKiByZWNvdmVyeSBhY3Rpb24gcmVz
dWx0IHRvIERPTTAuIERPTTAgd2lsbCBzYXZlIHRoZSBpbmZvcm1hdGlvbiBpbgorICogbm9uLXZv
bGF0aWxlIG1lbW9yeSBmb3IgZnVydGhlciBwcm9hY3RpdmUgYWN0aW9ucywgc3VjaCBhcyBvZmZs
aW5pbmcgdGhlCisgKiBlYXN5IGJyb2tlbiBwYWdlIGVhcmxpZXIgd2hlbiBkb2luZyBuZXh0IHJl
Ym9vdC4KKyovCitzdHJ1Y3QgcGFnZV9vZmZsaW5lX2FjdGlvbiB7CisJLyogUGFyYW1zIGZvciBw
YXNzaW5nIHRoZSBvZmZsaW5lZCBwYWdlIG51bWJlciB0byBET00wICovCisJdWludDY0X3QgbWZu
OworCXVpbnQ2NF90IHN0YXR1czsKK307CisKK3N0cnVjdCBjcHVfb2ZmbGluZV9hY3Rpb24gewor
CS8qIFBhcmFtcyBmb3IgcGFzc2luZyB0aGUgaWRlbnRpdHkgb2YgdGhlIG9mZmxpbmVkIENQVSB0
byBET00wICovCisJdWludDMyX3QgbWNfc29ja2V0aWQ7CisJdWludDE2X3QgbWNfY29yZWlkOwor
CXVpbnQxNl90IG1jX2NvcmVfdGhyZWFkaWQ7Cit9OworCisjZGVmaW5lIE1BWF9VTklPTl9TSVpF
IDE2CitzdHJ1Y3QgbWNpbmZvX3JlY292ZXJ5IHsKKwlzdHJ1Y3QgbWNpbmZvX2NvbW1vbiBjb21t
b247CisJdWludDE2X3QgbWNfYmFuazsgLyogYmFuayBuciAqLworCS8qIFJlY292ZXJ5IEFjdGlv
biBGbGFncyBkZWZpbmVkIGFib3ZlIHN1Y2ggYXMgUkVDX0FDVElPTl9ET05FICovCisJdWludDhf
dCBhY3Rpb25fZmxhZ3M7CisJLyogUmVjb3ZlcnkgQWN0aW9uIHR5cGVzIGRlZmluZWQgYWJvdmUg
c3VjaCBhcyBNQ19BQ1RJT05fUEFHRV9PRkZMSU5FICovCisJdWludDhfdCBhY3Rpb25fdHlwZXM7
CisJLyogSW4gZnV0dXJlIGlmIG1vcmUgdGhhbiBvbmUgcmVjb3ZlcnkgYWN0aW9uIHBlcm1pdHRl
ZCBwZXIgZXJyb3IgYmFuaywKKwkgKiBhIG1jaW5mb19yZWNvdmVyeSBkYXRhIGFycmF5IHdpbGwg
YmUgcmV0dXJuZWQKKwkgKi8KKwl1bmlvbiB7CisJCXN0cnVjdCBwYWdlX29mZmxpbmVfYWN0aW9u
IHBhZ2VfcmV0aXJlOworCQlzdHJ1Y3QgY3B1X29mZmxpbmVfYWN0aW9uIGNwdV9vZmZsaW5lOwor
CQl1aW50OF90IHBhZFtNQVhfVU5JT05fU0laRV07CisJfSBhY3Rpb25faW5mbzsKK307CisKKwor
I2RlZmluZSBNQ0lORk9fSFlQRVJDQUxMU0laRQkxMDI0CisjZGVmaW5lIE1DSU5GT19NQVhTSVpF
CQk3NjgKKworc3RydWN0IG1jX2luZm8geworCS8qIE51bWJlciBvZiBtY2luZm9fKiBlbnRyaWVz
IGluIG1pX2RhdGEgKi8KKwl1aW50MzJfdCBtaV9uZW50cmllczsKKwl1aW50MzJfdCBfcGFkMDsK
Kwl1aW50NjRfdCBtaV9kYXRhWyhNQ0lORk9fTUFYU0laRSAtIDEpIC8gOF07Cit9OwordHlwZWRl
ZiBzdHJ1Y3QgbWNfaW5mbyBtY19pbmZvX3Q7CitERUZJTkVfR1VFU1RfSEFORExFX1NUUlVDVCht
Y19pbmZvKTsKKworI2RlZmluZSBfX01DX01TUl9BUlJBWVNJWkUgOAorI2RlZmluZSBfX01DX05N
U1JTIDEKKyNkZWZpbmUgTUNfTkNBUFMJNwkvKiA3IENQVSBmZWF0dXJlIGZsYWcgd29yZHMgKi8K
KyNkZWZpbmUgTUNfQ0FQU19TVERfRURYCTAJLyogY3B1aWQgbGV2ZWwgMHgwMDAwMDAwMSAoJWVk
eCkgKi8KKyNkZWZpbmUgTUNfQ0FQU19BTURfRURYCTEJLyogY3B1aWQgbGV2ZWwgMHg4MDAwMDAw
MSAoJWVkeCkgKi8KKyNkZWZpbmUgTUNfQ0FQU19UTQkyCS8qIGNwdWlkIGxldmVsIDB4ODA4NjAw
MDEgKFRyYW5zTWV0YSkgKi8KKyNkZWZpbmUgTUNfQ0FQU19MSU5VWAkzCS8qIExpbnV4LWRlZmlu
ZWQgKi8KKyNkZWZpbmUgTUNfQ0FQU19TVERfRUNYCTQJLyogY3B1aWQgbGV2ZWwgMHgwMDAwMDAw
MSAoJWVjeCkgKi8KKyNkZWZpbmUgTUNfQ0FQU19WSUEJNQkvKiBjcHVpZCBsZXZlbCAweGMwMDAw
MDAxICovCisjZGVmaW5lIE1DX0NBUFNfQU1EX0VDWAk2CS8qIGNwdWlkIGxldmVsIDB4ODAwMDAw
MDEgKCVlY3gpICovCisKK3N0cnVjdCBtY2luZm9fbG9naWNhbF9jcHUgeworCXVpbnQzMl90IG1j
X2NwdW5yOworCXVpbnQzMl90IG1jX2NoaXBpZDsKKwl1aW50MTZfdCBtY19jb3JlaWQ7CisJdWlu
dDE2X3QgbWNfdGhyZWFkaWQ7CisJdWludDMyX3QgbWNfYXBpY2lkOworCXVpbnQzMl90IG1jX2Ns
dXN0ZXJpZDsKKwl1aW50MzJfdCBtY19uY29yZXM7CisJdWludDMyX3QgbWNfbmNvcmVzX2FjdGl2
ZTsKKwl1aW50MzJfdCBtY19udGhyZWFkczsKKwlpbnQzMl90IG1jX2NwdWlkX2xldmVsOworCXVp
bnQzMl90IG1jX2ZhbWlseTsKKwl1aW50MzJfdCBtY192ZW5kb3I7CisJdWludDMyX3QgbWNfbW9k
ZWw7CisJdWludDMyX3QgbWNfc3RlcDsKKwljaGFyIG1jX3ZlbmRvcmlkWzE2XTsKKwljaGFyIG1j
X2JyYW5kaWRbNjRdOworCXVpbnQzMl90IG1jX2NwdV9jYXBzW01DX05DQVBTXTsKKwl1aW50MzJf
dCBtY19jYWNoZV9zaXplOworCXVpbnQzMl90IG1jX2NhY2hlX2FsaWdubWVudDsKKwlpbnQzMl90
IG1jX25tc3J2YWxzOworCXN0cnVjdCBtY2luZm9fbXNyIG1jX21zcnZhbHVlc1tfX01DX01TUl9B
UlJBWVNJWkVdOworfTsKK3R5cGVkZWYgc3RydWN0IG1jaW5mb19sb2dpY2FsX2NwdSBtY2luZm9f
bG9naWNhbF9jcHVfdDsKK0RFRklORV9HVUVTVF9IQU5ETEVfU1RSVUNUKG1jaW5mb19sb2dpY2Fs
X2NwdSk7CisKKworLyoKKyAqIE9TJ3Mgc2hvdWxkIHVzZSB0aGVzZSBpbnN0ZWFkIG9mIHdyaXRp
bmcgdGhlaXIgb3duIGxvb2t1cCBmdW5jdGlvbgorICogZWFjaCB3aXRoIGl0cyBvd24gYnVncyBh
bmQgZHJhd2JhY2tzLgorICogV2UgdXNlIG1hY3JvcyBpbnN0ZWFkIG9mIHN0YXRpYyBpbmxpbmUg
ZnVuY3Rpb25zIHRvIGFsbG93IGd1ZXN0cworICogdG8gaW5jbHVkZSB0aGlzIGhlYWRlciBpbiBh
c3NlbWJseSBmaWxlcyAoKi5TKS4KKyAqLworLyogUHJvdG90eXBlOgorICogICAgdWludDMyX3Qg
eDg2X21jaW5mb19uZW50cmllcyhzdHJ1Y3QgbWNfaW5mbyAqbWkpOworICovCisjZGVmaW5lIHg4
Nl9tY2luZm9fbmVudHJpZXMoX21pKSAgICBcCisgICAgKChfbWkpLT5taV9uZW50cmllcykKKy8q
IFByb3RvdHlwZToKKyAqICAgIHN0cnVjdCBtY2luZm9fY29tbW9uICp4ODZfbWNpbmZvX2ZpcnN0
KHN0cnVjdCBtY19pbmZvICptaSk7CisgKi8KKyNkZWZpbmUgeDg2X21jaW5mb19maXJzdChfbWkp
ICAgICAgIFwKKyAgICAoKHN0cnVjdCBtY2luZm9fY29tbW9uICopKF9taSktPm1pX2RhdGEpCisv
KiBQcm90b3R5cGU6CisgKiAgICBzdHJ1Y3QgbWNpbmZvX2NvbW1vbiAqeDg2X21jaW5mb19uZXh0
KHN0cnVjdCBtY2luZm9fY29tbW9uICptaWMpOworICovCisjZGVmaW5lIHg4Nl9tY2luZm9fbmV4
dChfbWljKSAgICAgICBcCisgICAgKChzdHJ1Y3QgbWNpbmZvX2NvbW1vbiAqKSgodWludDhfdCAq
KShfbWljKSArIChfbWljKS0+c2l6ZSkpCisKKy8qIFByb3RvdHlwZToKKyAqICAgIHZvaWQgeDg2
X21jaW5mb19sb29rdXAodm9pZCAqcmV0LCBzdHJ1Y3QgbWNfaW5mbyAqbWksIHVpbnQxNl90IHR5
cGUpOworICovCisKK3N0YXRpYyBpbmxpbmUgdm9pZCB4ODZfbWNpbmZvX2xvb2t1cAorCShzdHJ1
Y3QgbWNpbmZvX2NvbW1vbiAqKnJldCwgc3RydWN0IG1jX2luZm8gKm1pLCB1aW50MTZfdCB0eXBl
KQoreworCXVpbnQzMl90IGZvdW5kID0gMCwgaTsKKwlzdHJ1Y3QgbWNpbmZvX2NvbW1vbiAqbWlj
OworCisJKnJldCA9IE5VTEw7CisJaWYgKCFtaSkKKwkJcmV0dXJuOworCW1pYyA9IHg4Nl9tY2lu
Zm9fZmlyc3QobWkpOworCisJZm9yIChpID0gMDsgaSA8IHg4Nl9tY2luZm9fbmVudHJpZXMobWkp
OyBpKyspIHsKKwkJaWYgKG1pYy0+dHlwZSA9PSB0eXBlKSB7CisJCQlmb3VuZCA9IDE7CisJCQli
cmVhazsKKwkJfQorCQltaWMgPSB4ODZfbWNpbmZvX25leHQobWljKTsKKwl9CisKKwkqcmV0ID0g
Zm91bmQgPyBtaWMgOiBOVUxMOworfQorLyogVXNlY2FzZSAxCisgKiBSZWdpc3RlciBtYWNoaW5l
IGNoZWNrIHRyYXAgY2FsbGJhY2sgaGFuZGxlcgorICogICAgKGFscmVhZHkgZG9uZSB2aWEgInNl
dF90cmFwX3RhYmxlIiBoeXBlcmNhbGwpCisgKi8KKworLyogVXNlY2FzZSAyCisgKiBEb20wIHJl
Z2lzdGVycyBtYWNoaW5lIGNoZWNrIGV2ZW50IGNhbGxiYWNrIGhhbmRsZXIKKyAqIGRvbmUgYnkg
RVZUQ0hOT1BfYmluZF92aXJxCisgKi8KKworLyogVXNlY2FzZSAzCisgKiBGZXRjaCBtYWNoaW5l
IGNoZWNrIGRhdGEgZnJvbSBoeXBlcnZpc29yLgorICogTm90ZSwgdGhpcyBoeXBlcmNhbGwgaXMg
c3BlY2lhbCwgYmVjYXVzZSBib3RoIERvbTAgYW5kIERvbVUgbXVzdCB1c2UgdGhpcy4KKyAqLwor
I2RlZmluZSBYRU5fTUNfZmV0Y2ggICAgICAgICAgICAxCitzdHJ1Y3QgeGVuX21jX2ZldGNoIHsK
KyAgICAvKiBJTi9PVVQgdmFyaWFibGVzLgorCSAqIElOOiBYRU5fTUNfTk9OVVJHRU5ULCBYRU5f
TUNfVVJHRU5ULAorCSAqIFhFTl9NQ19BQ0sgaWYgYWNrJ2tpbmcgYW4gZWFybGllciBmZXRjaAor
CSAqIE9VVDogWEVOX01DX09LLCBYRU5fTUNfRkVUQ0hBSUxFRCwKKwkgKiBYRU5fTUNfTk9EQVRB
LCBYRU5fTUNfTk9NQVRDSAorCSovCisJdWludDMyX3QgZmxhZ3M7CisJdWludDMyX3QgX3BhZDA7
CisJLyogT1VUOiBpZCBmb3IgYWNrLCBJTjogaWQgd2UgYXJlIGFjaydpbmcgKi8KKwl1aW50NjRf
dCBmZXRjaF9pZDsKKworCS8qIE9VVCB2YXJpYWJsZXMuICovCisJR1VFU1RfSEFORExFKG1jX2lu
Zm8pIGRhdGE7Cit9OwordHlwZWRlZiBzdHJ1Y3QgeGVuX21jX2ZldGNoIHhlbl9tY19mZXRjaF90
OworREVGSU5FX0dVRVNUX0hBTkRMRV9TVFJVQ1QoeGVuX21jX2ZldGNoKTsKKworCisvKiBVc2Vj
YXNlIDQKKyAqIFRoaXMgdGVsbHMgdGhlIGh5cGVydmlzb3IgdG8gbm90aWZ5IGEgRG9tVSBhYm91
dCB0aGUgbWFjaGluZSBjaGVjayBlcnJvcgorICovCisjZGVmaW5lIFhFTl9NQ19ub3RpZnlkb21h
aW4gICAgIDIKK3N0cnVjdCB4ZW5fbWNfbm90aWZ5ZG9tYWluIHsKKwkvKiBJTiB2YXJpYWJsZXMu
ICovCisJdWludDE2X3QgbWNfZG9taWQ7LyogVGhlIHVucHJpdmlsZWdlZCBkb21haW4gdG8gbm90
aWZ5LiAqLworCXVpbnQxNl90IG1jX3ZjcHVpZDsvKiBUaGUgdmNwdSBpbiBtY19kb21pZCB0byBu
b3RpZnkuCisJCQkqIFVzdWFsbHkgZWNobydkIHZhbHVlIGZyb20gdGhlIGZldGNoIGh5cGVyY2Fs
bC4gKi8KKworCS8qIElOL09VVCB2YXJpYWJsZXMuICovCisJdWludDMyX3QgZmxhZ3M7CisKKy8q
IE9VVDogWEVOX01DX09LLCBYRU5fTUNfQ0FOTk9USEFORExFLCBYRU5fTUNfTk9UREVMSVZFUkVE
LCBYRU5fTUNfTk9NQVRDSCAqLworfTsKK3R5cGVkZWYgc3RydWN0IHhlbl9tY19ub3RpZnlkb21h
aW4geGVuX21jX25vdGlmeWRvbWFpbl90OworREVGSU5FX0dVRVNUX0hBTkRMRV9TVFJVQ1QoeGVu
X21jX25vdGlmeWRvbWFpbik7CisKKyNkZWZpbmUgWEVOX01DX3BoeXNjcHVpbmZvIDMKK3N0cnVj
dCB4ZW5fbWNfcGh5c2NwdWluZm8geworCS8qIElOL09VVCAqLworCXVpbnQzMl90IG5jcHVzOwor
CXVpbnQzMl90IF9wYWQwOworCS8qIE9VVCAqLworCUdVRVNUX0hBTkRMRShtY2luZm9fbG9naWNh
bF9jcHUpIGluZm87Cit9OworCisjZGVmaW5lIFhFTl9NQ19tc3JpbmplY3QgICAgNAorI2RlZmlu
ZSBNQ19NU1JJTkpfTUFYTVNSUyAgICAgICA4CitzdHJ1Y3QgeGVuX21jX21zcmluamVjdCB7CisJ
LyogSU4gKi8KKwl1aW50MzJfdCBtY2lual9jcHVucjsvKiB0YXJnZXQgcHJvY2Vzc29yIGlkICov
CisJdWludDMyX3QgbWNpbmpfZmxhZ3M7Lyogc2VlIE1DX01TUklOSl9GXyogYmVsb3cgKi8KKwl1
aW50MzJfdCBtY2lual9jb3VudDsvKiAwIC4uIGNvdW50LTEgaW4gYXJyYXkgYXJlIHZhbGlkICov
CisJdWludDMyX3QgX3BhZDA7CisJc3RydWN0IG1jaW5mb19tc3IgbWNpbmpfbXNyW01DX01TUklO
Sl9NQVhNU1JTXTsKK307CisKKy8qIEZsYWdzIGZvciBtY2lual9mbGFncyBhYm92ZTsgYml0cyAx
Ni0zMSBhcmUgcmVzZXJ2ZWQgKi8KKyNkZWZpbmUgTUNfTVNSSU5KX0ZfSU5URVJQT1NFICAgMHgx
CisKKyNkZWZpbmUgWEVOX01DX21jZWluamVjdCAgICA1CitzdHJ1Y3QgeGVuX21jX21jZWluamVj
dCB7CisJdW5zaWduZWQgaW50IG1jZWlual9jcHVucjsgICAgICAvKiB0YXJnZXQgcHJvY2Vzc29y
IGlkICovCit9OworCitzdHJ1Y3QgeGVuX21jIHsKKwl1aW50MzJfdCBjbWQ7CisJdWludDMyX3Qg
aW50ZXJmYWNlX3ZlcnNpb247IC8qIFhFTl9NQ0FfSU5URVJGQUNFX1ZFUlNJT04gKi8KKwl1bmlv
biB7CisJCXN0cnVjdCB4ZW5fbWNfZmV0Y2ggICAgICAgIG1jX2ZldGNoOworCQlzdHJ1Y3QgeGVu
X21jX25vdGlmeWRvbWFpbiBtY19ub3RpZnlkb21haW47CisJCXN0cnVjdCB4ZW5fbWNfcGh5c2Nw
dWluZm8gIG1jX3BoeXNjcHVpbmZvOworCQlzdHJ1Y3QgeGVuX21jX21zcmluamVjdCAgICBtY19t
c3JpbmplY3Q7CisJCXN0cnVjdCB4ZW5fbWNfbWNlaW5qZWN0ICAgIG1jX21jZWluamVjdDsKKwl9
IHU7Cit9OwordHlwZWRlZiBzdHJ1Y3QgeGVuX21jIHhlbl9tY190OworREVGSU5FX0dVRVNUX0hB
TkRMRV9TVFJVQ1QoeGVuX21jKTsKKworI2VuZGlmIC8qIF9fQVNTRU1CTFlfXyAqLworCisjZW5k
aWYgLyogX19YRU5fUFVCTElDX0FSQ0hfWDg2X01DQV9IX18gKi8KLS0gCjEuNi41LjYKCg==

--_002_DE8DF0795D48FD4CA783C40EC82923359699SHSMSX101ccrcorpint_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--_002_DE8DF0795D48FD4CA783C40EC82923359699SHSMSX101ccrcorpint_--


From xen-devel-bounces@lists.xensource.com Fri Dec 23 10:24:59 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 Dec 2011 10:24:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Re2Is-0005xy-QG; Fri, 23 Dec 2011 10:24:42 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1Re2Ir-0005xP-BY
	for xen-devel@lists.xensource.com; Fri, 23 Dec 2011 10:24:41 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1324635874!8410233!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDMwMDk1NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26334 invoked from network); 23 Dec 2011 10:24:34 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-4.tower-182.messagelabs.com with SMTP;
	23 Dec 2011 10:24:34 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga102.fm.intel.com with ESMTP; 23 Dec 2011 02:24:33 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; 
	d="scan'208,223";a="105418716"
Received: from pgsmsx602.gar.corp.intel.com ([10.221.43.81])
	by fmsmga002.fm.intel.com with ESMTP; 23 Dec 2011 02:24:32 -0800
Received: from pgsmsx151.gar.corp.intel.com (172.30.236.41) by
	pgsmsx602.gar.corp.intel.com (10.221.43.81) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Fri, 23 Dec 2011 18:24:32 +0800
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	PGSMSX151.gar.corp.intel.com (172.30.236.41) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Fri, 23 Dec 2011 18:24:31 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.38]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.199]) with mapi id
	14.01.0355.002; Fri, 23 Dec 2011 18:24:30 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: "konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
Thread-Topic: [PATCH 02/10] xen/mce: Change the machine check point
Thread-Index: AczBXQ1WSSmFa5n6TGeCtQd8p4HSYg==
Date: Fri, 23 Dec 2011 10:24:29 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC829233596B7@SHSMSX101.ccr.corp.intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
Content-Type: multipart/mixed;
	boundary="_002_DE8DF0795D48FD4CA783C40EC829233596B7SHSMSX101ccrcorpint_"
MIME-Version: 1.0
Cc: "Brown, Len" <len.brown@intel.com>,
	"jeremy.fitzhardinge@citrix.com" <jeremy.fitzhardinge@citrix.com>,
	"Jiang, Yunhong" <yunhong.jiang@intel.com>, "Shan, 
	Haitao" <haitao.shan@intel.com>,
	Kernel development list <linux-kernel@vger.kernel.org>, "Zhao,
	Yakui" <yakui.zhao@intel.com>, "Luck, Tony" <tony.luck@intel.com>, "Kleen,
	Andi" <andi.kleen@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: [Xen-devel] [PATCH 02/10] xen/mce: Change the machine check point
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--_002_DE8DF0795D48FD4CA783C40EC829233596B7SHSMSX101ccrcorpint_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

>From 80221e743d1a693670d701f383da26c8e5d5bf98 Mon Sep 17 00:00:00 2001
From: Liu Jinsong <jinsong.liu@intel.com>
Date: Wed, 7 Dec 2011 05:26:16 +0800
Subject: [PATCH 02/10] xen/mce: Change the machine check point

This patch backport from Jeremy's pvops commit
073349667402682c997394b3fcdbbeb6707f368f

Enable MCE support in dom0, so that if a MCE happen and that MCE impact
dom0, dom0 can receive a vMCE.

Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
Signed-off-by: Ke, Liping <liping.ke@intel.com>
Signed-off-by: Jiang, Yunhong <yunhong.jiang@intel.com>
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
---
 arch/x86/xen/enlighten.c |    7 +++++--
 1 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index b073e4c..13e7a16 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -526,7 +526,7 @@ static int cvt_gate_to_trap(int vector, const gate_desc=
 *val,
 	 * Look for known traps using IST, and substitute them
 	 * appropriately.  The debugger ones are the only ones we care
 	 * about.  Xen will handle faults like double_fault and
-	 * machine_check, so we should never see them.  Warn if
+	 * nmi, so we should never see them.  Warn if
 	 * there's an unexpected IST-using fault handler.
 	 */
 	if (addr =3D=3D (unsigned long)debug)
@@ -541,7 +541,10 @@ static int cvt_gate_to_trap(int vector, const gate_des=
c *val,
 		return 0;
 #ifdef CONFIG_X86_MCE
 	} else if (addr =3D=3D (unsigned long)machine_check) {
-		return 0;
+		if (xen_initial_domain())
+			addr =3D (unsigned long)machine_check;
+		else
+			return 0;
 #endif
 	} else {
 		/* Some other trap using IST? */
--=20
1.6.5.6

--_002_DE8DF0795D48FD4CA783C40EC829233596B7SHSMSX101ccrcorpint_
Content-Type: application/octet-stream;
	name="0002-xen-mce-Change-the-machine-check-point.patch"
Content-Description: 0002-xen-mce-Change-the-machine-check-point.patch
Content-Disposition: attachment;
	filename="0002-xen-mce-Change-the-machine-check-point.patch"; size=1691;
	creation-date="Wed, 14 Dec 2011 15:20:15 GMT";
	modification-date="Wed, 14 Dec 2011 15:03:34 GMT"
Content-Transfer-Encoding: base64

RnJvbSA4MDIyMWU3NDNkMWE2OTM2NzBkNzAxZjM4M2RhMjZjOGU1ZDViZjk4IE1vbiBTZXAgMTcg
MDA6MDA6MDAgMjAwMQpGcm9tOiBMaXUgSmluc29uZyA8amluc29uZy5saXVAaW50ZWwuY29tPgpE
YXRlOiBXZWQsIDcgRGVjIDIwMTEgMDU6MjY6MTYgKzA4MDAKU3ViamVjdDogW1BBVENIIDAyLzEw
XSB4ZW4vbWNlOiBDaGFuZ2UgdGhlIG1hY2hpbmUgY2hlY2sgcG9pbnQKClRoaXMgcGF0Y2ggYmFj
a3BvcnQgZnJvbSBKZXJlbXkncyBwdm9wcyBjb21taXQKMDczMzQ5NjY3NDAyNjgyYzk5NzM5NGIz
ZmNkYmJlYjY3MDdmMzY4ZgoKRW5hYmxlIE1DRSBzdXBwb3J0IGluIGRvbTAsIHNvIHRoYXQgaWYg
YSBNQ0UgaGFwcGVuIGFuZCB0aGF0IE1DRSBpbXBhY3QKZG9tMCwgZG9tMCBjYW4gcmVjZWl2ZSBh
IHZNQ0UuCgpTaWduZWQtb2ZmLWJ5OiBMaXUsIEppbnNvbmcgPGppbnNvbmcubGl1QGludGVsLmNv
bT4KU2lnbmVkLW9mZi1ieTogS2UsIExpcGluZyA8bGlwaW5nLmtlQGludGVsLmNvbT4KU2lnbmVk
LW9mZi1ieTogSmlhbmcsIFl1bmhvbmcgPHl1bmhvbmcuamlhbmdAaW50ZWwuY29tPgpTaWduZWQt
b2ZmLWJ5OiBKZXJlbXkgRml0emhhcmRpbmdlIDxqZXJlbXkuZml0emhhcmRpbmdlQGNpdHJpeC5j
b20+Ci0tLQogYXJjaC94ODYveGVuL2VubGlnaHRlbi5jIHwgICAgNyArKysrKy0tCiAxIGZpbGVz
IGNoYW5nZWQsIDUgaW5zZXJ0aW9ucygrKSwgMiBkZWxldGlvbnMoLSkKCmRpZmYgLS1naXQgYS9h
cmNoL3g4Ni94ZW4vZW5saWdodGVuLmMgYi9hcmNoL3g4Ni94ZW4vZW5saWdodGVuLmMKaW5kZXgg
YjA3M2U0Yy4uMTNlN2ExNiAxMDA2NDQKLS0tIGEvYXJjaC94ODYveGVuL2VubGlnaHRlbi5jCisr
KyBiL2FyY2gveDg2L3hlbi9lbmxpZ2h0ZW4uYwpAQCAtNTI2LDcgKzUyNiw3IEBAIHN0YXRpYyBp
bnQgY3Z0X2dhdGVfdG9fdHJhcChpbnQgdmVjdG9yLCBjb25zdCBnYXRlX2Rlc2MgKnZhbCwKIAkg
KiBMb29rIGZvciBrbm93biB0cmFwcyB1c2luZyBJU1QsIGFuZCBzdWJzdGl0dXRlIHRoZW0KIAkg
KiBhcHByb3ByaWF0ZWx5LiAgVGhlIGRlYnVnZ2VyIG9uZXMgYXJlIHRoZSBvbmx5IG9uZXMgd2Ug
Y2FyZQogCSAqIGFib3V0LiAgWGVuIHdpbGwgaGFuZGxlIGZhdWx0cyBsaWtlIGRvdWJsZV9mYXVs
dCBhbmQKLQkgKiBtYWNoaW5lX2NoZWNrLCBzbyB3ZSBzaG91bGQgbmV2ZXIgc2VlIHRoZW0uICBX
YXJuIGlmCisJICogbm1pLCBzbyB3ZSBzaG91bGQgbmV2ZXIgc2VlIHRoZW0uICBXYXJuIGlmCiAJ
ICogdGhlcmUncyBhbiB1bmV4cGVjdGVkIElTVC11c2luZyBmYXVsdCBoYW5kbGVyLgogCSAqLwog
CWlmIChhZGRyID09ICh1bnNpZ25lZCBsb25nKWRlYnVnKQpAQCAtNTQxLDcgKzU0MSwxMCBAQCBz
dGF0aWMgaW50IGN2dF9nYXRlX3RvX3RyYXAoaW50IHZlY3RvciwgY29uc3QgZ2F0ZV9kZXNjICp2
YWwsCiAJCXJldHVybiAwOwogI2lmZGVmIENPTkZJR19YODZfTUNFCiAJfSBlbHNlIGlmIChhZGRy
ID09ICh1bnNpZ25lZCBsb25nKW1hY2hpbmVfY2hlY2spIHsKLQkJcmV0dXJuIDA7CisJCWlmICh4
ZW5faW5pdGlhbF9kb21haW4oKSkKKwkJCWFkZHIgPSAodW5zaWduZWQgbG9uZyltYWNoaW5lX2No
ZWNrOworCQllbHNlCisJCQlyZXR1cm4gMDsKICNlbmRpZgogCX0gZWxzZSB7CiAJCS8qIFNvbWUg
b3RoZXIgdHJhcCB1c2luZyBJU1Q/ICovCi0tIAoxLjYuNS42Cgo=

--_002_DE8DF0795D48FD4CA783C40EC829233596B7SHSMSX101ccrcorpint_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--_002_DE8DF0795D48FD4CA783C40EC829233596B7SHSMSX101ccrcorpint_--


From xen-devel-bounces@lists.xensource.com Fri Dec 23 10:24:59 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 Dec 2011 10:24:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Re2Is-0005xy-QG; Fri, 23 Dec 2011 10:24:42 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1Re2Ir-0005xP-BY
	for xen-devel@lists.xensource.com; Fri, 23 Dec 2011 10:24:41 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1324635874!8410233!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDMwMDk1NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26334 invoked from network); 23 Dec 2011 10:24:34 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-4.tower-182.messagelabs.com with SMTP;
	23 Dec 2011 10:24:34 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga102.fm.intel.com with ESMTP; 23 Dec 2011 02:24:33 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; 
	d="scan'208,223";a="105418716"
Received: from pgsmsx602.gar.corp.intel.com ([10.221.43.81])
	by fmsmga002.fm.intel.com with ESMTP; 23 Dec 2011 02:24:32 -0800
Received: from pgsmsx151.gar.corp.intel.com (172.30.236.41) by
	pgsmsx602.gar.corp.intel.com (10.221.43.81) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Fri, 23 Dec 2011 18:24:32 +0800
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	PGSMSX151.gar.corp.intel.com (172.30.236.41) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Fri, 23 Dec 2011 18:24:31 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.38]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.199]) with mapi id
	14.01.0355.002; Fri, 23 Dec 2011 18:24:30 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: "konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
Thread-Topic: [PATCH 02/10] xen/mce: Change the machine check point
Thread-Index: AczBXQ1WSSmFa5n6TGeCtQd8p4HSYg==
Date: Fri, 23 Dec 2011 10:24:29 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC829233596B7@SHSMSX101.ccr.corp.intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
Content-Type: multipart/mixed;
	boundary="_002_DE8DF0795D48FD4CA783C40EC829233596B7SHSMSX101ccrcorpint_"
MIME-Version: 1.0
Cc: "Brown, Len" <len.brown@intel.com>,
	"jeremy.fitzhardinge@citrix.com" <jeremy.fitzhardinge@citrix.com>,
	"Jiang, Yunhong" <yunhong.jiang@intel.com>, "Shan, 
	Haitao" <haitao.shan@intel.com>,
	Kernel development list <linux-kernel@vger.kernel.org>, "Zhao,
	Yakui" <yakui.zhao@intel.com>, "Luck, Tony" <tony.luck@intel.com>, "Kleen,
	Andi" <andi.kleen@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: [Xen-devel] [PATCH 02/10] xen/mce: Change the machine check point
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--_002_DE8DF0795D48FD4CA783C40EC829233596B7SHSMSX101ccrcorpint_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

>From 80221e743d1a693670d701f383da26c8e5d5bf98 Mon Sep 17 00:00:00 2001
From: Liu Jinsong <jinsong.liu@intel.com>
Date: Wed, 7 Dec 2011 05:26:16 +0800
Subject: [PATCH 02/10] xen/mce: Change the machine check point

This patch backport from Jeremy's pvops commit
073349667402682c997394b3fcdbbeb6707f368f

Enable MCE support in dom0, so that if a MCE happen and that MCE impact
dom0, dom0 can receive a vMCE.

Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
Signed-off-by: Ke, Liping <liping.ke@intel.com>
Signed-off-by: Jiang, Yunhong <yunhong.jiang@intel.com>
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
---
 arch/x86/xen/enlighten.c |    7 +++++--
 1 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index b073e4c..13e7a16 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -526,7 +526,7 @@ static int cvt_gate_to_trap(int vector, const gate_desc=
 *val,
 	 * Look for known traps using IST, and substitute them
 	 * appropriately.  The debugger ones are the only ones we care
 	 * about.  Xen will handle faults like double_fault and
-	 * machine_check, so we should never see them.  Warn if
+	 * nmi, so we should never see them.  Warn if
 	 * there's an unexpected IST-using fault handler.
 	 */
 	if (addr =3D=3D (unsigned long)debug)
@@ -541,7 +541,10 @@ static int cvt_gate_to_trap(int vector, const gate_des=
c *val,
 		return 0;
 #ifdef CONFIG_X86_MCE
 	} else if (addr =3D=3D (unsigned long)machine_check) {
-		return 0;
+		if (xen_initial_domain())
+			addr =3D (unsigned long)machine_check;
+		else
+			return 0;
 #endif
 	} else {
 		/* Some other trap using IST? */
--=20
1.6.5.6

--_002_DE8DF0795D48FD4CA783C40EC829233596B7SHSMSX101ccrcorpint_
Content-Type: application/octet-stream;
	name="0002-xen-mce-Change-the-machine-check-point.patch"
Content-Description: 0002-xen-mce-Change-the-machine-check-point.patch
Content-Disposition: attachment;
	filename="0002-xen-mce-Change-the-machine-check-point.patch"; size=1691;
	creation-date="Wed, 14 Dec 2011 15:20:15 GMT";
	modification-date="Wed, 14 Dec 2011 15:03:34 GMT"
Content-Transfer-Encoding: base64

RnJvbSA4MDIyMWU3NDNkMWE2OTM2NzBkNzAxZjM4M2RhMjZjOGU1ZDViZjk4IE1vbiBTZXAgMTcg
MDA6MDA6MDAgMjAwMQpGcm9tOiBMaXUgSmluc29uZyA8amluc29uZy5saXVAaW50ZWwuY29tPgpE
YXRlOiBXZWQsIDcgRGVjIDIwMTEgMDU6MjY6MTYgKzA4MDAKU3ViamVjdDogW1BBVENIIDAyLzEw
XSB4ZW4vbWNlOiBDaGFuZ2UgdGhlIG1hY2hpbmUgY2hlY2sgcG9pbnQKClRoaXMgcGF0Y2ggYmFj
a3BvcnQgZnJvbSBKZXJlbXkncyBwdm9wcyBjb21taXQKMDczMzQ5NjY3NDAyNjgyYzk5NzM5NGIz
ZmNkYmJlYjY3MDdmMzY4ZgoKRW5hYmxlIE1DRSBzdXBwb3J0IGluIGRvbTAsIHNvIHRoYXQgaWYg
YSBNQ0UgaGFwcGVuIGFuZCB0aGF0IE1DRSBpbXBhY3QKZG9tMCwgZG9tMCBjYW4gcmVjZWl2ZSBh
IHZNQ0UuCgpTaWduZWQtb2ZmLWJ5OiBMaXUsIEppbnNvbmcgPGppbnNvbmcubGl1QGludGVsLmNv
bT4KU2lnbmVkLW9mZi1ieTogS2UsIExpcGluZyA8bGlwaW5nLmtlQGludGVsLmNvbT4KU2lnbmVk
LW9mZi1ieTogSmlhbmcsIFl1bmhvbmcgPHl1bmhvbmcuamlhbmdAaW50ZWwuY29tPgpTaWduZWQt
b2ZmLWJ5OiBKZXJlbXkgRml0emhhcmRpbmdlIDxqZXJlbXkuZml0emhhcmRpbmdlQGNpdHJpeC5j
b20+Ci0tLQogYXJjaC94ODYveGVuL2VubGlnaHRlbi5jIHwgICAgNyArKysrKy0tCiAxIGZpbGVz
IGNoYW5nZWQsIDUgaW5zZXJ0aW9ucygrKSwgMiBkZWxldGlvbnMoLSkKCmRpZmYgLS1naXQgYS9h
cmNoL3g4Ni94ZW4vZW5saWdodGVuLmMgYi9hcmNoL3g4Ni94ZW4vZW5saWdodGVuLmMKaW5kZXgg
YjA3M2U0Yy4uMTNlN2ExNiAxMDA2NDQKLS0tIGEvYXJjaC94ODYveGVuL2VubGlnaHRlbi5jCisr
KyBiL2FyY2gveDg2L3hlbi9lbmxpZ2h0ZW4uYwpAQCAtNTI2LDcgKzUyNiw3IEBAIHN0YXRpYyBp
bnQgY3Z0X2dhdGVfdG9fdHJhcChpbnQgdmVjdG9yLCBjb25zdCBnYXRlX2Rlc2MgKnZhbCwKIAkg
KiBMb29rIGZvciBrbm93biB0cmFwcyB1c2luZyBJU1QsIGFuZCBzdWJzdGl0dXRlIHRoZW0KIAkg
KiBhcHByb3ByaWF0ZWx5LiAgVGhlIGRlYnVnZ2VyIG9uZXMgYXJlIHRoZSBvbmx5IG9uZXMgd2Ug
Y2FyZQogCSAqIGFib3V0LiAgWGVuIHdpbGwgaGFuZGxlIGZhdWx0cyBsaWtlIGRvdWJsZV9mYXVs
dCBhbmQKLQkgKiBtYWNoaW5lX2NoZWNrLCBzbyB3ZSBzaG91bGQgbmV2ZXIgc2VlIHRoZW0uICBX
YXJuIGlmCisJICogbm1pLCBzbyB3ZSBzaG91bGQgbmV2ZXIgc2VlIHRoZW0uICBXYXJuIGlmCiAJ
ICogdGhlcmUncyBhbiB1bmV4cGVjdGVkIElTVC11c2luZyBmYXVsdCBoYW5kbGVyLgogCSAqLwog
CWlmIChhZGRyID09ICh1bnNpZ25lZCBsb25nKWRlYnVnKQpAQCAtNTQxLDcgKzU0MSwxMCBAQCBz
dGF0aWMgaW50IGN2dF9nYXRlX3RvX3RyYXAoaW50IHZlY3RvciwgY29uc3QgZ2F0ZV9kZXNjICp2
YWwsCiAJCXJldHVybiAwOwogI2lmZGVmIENPTkZJR19YODZfTUNFCiAJfSBlbHNlIGlmIChhZGRy
ID09ICh1bnNpZ25lZCBsb25nKW1hY2hpbmVfY2hlY2spIHsKLQkJcmV0dXJuIDA7CisJCWlmICh4
ZW5faW5pdGlhbF9kb21haW4oKSkKKwkJCWFkZHIgPSAodW5zaWduZWQgbG9uZyltYWNoaW5lX2No
ZWNrOworCQllbHNlCisJCQlyZXR1cm4gMDsKICNlbmRpZgogCX0gZWxzZSB7CiAJCS8qIFNvbWUg
b3RoZXIgdHJhcCB1c2luZyBJU1Q/ICovCi0tIAoxLjYuNS42Cgo=

--_002_DE8DF0795D48FD4CA783C40EC829233596B7SHSMSX101ccrcorpint_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--_002_DE8DF0795D48FD4CA783C40EC829233596B7SHSMSX101ccrcorpint_--


From xen-devel-bounces@lists.xensource.com Fri Dec 23 10:25:54 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 Dec 2011 10:25:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Re2Jn-00065e-B9; Fri, 23 Dec 2011 10:25:39 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1Re2Jl-00064h-KR
	for xen-devel@lists.xensource.com; Fri, 23 Dec 2011 10:25:38 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1324635892!57839106!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDMwMDk1NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16650 invoked from network); 23 Dec 2011 10:24:53 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-9.tower-27.messagelabs.com with SMTP;
	23 Dec 2011 10:24:53 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga102.fm.intel.com with ESMTP; 23 Dec 2011 02:25:29 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208,223";a="99638305"
Received: from pgsmsx601.gar.corp.intel.com ([10.221.43.69])
	by fmsmga001.fm.intel.com with ESMTP; 23 Dec 2011 02:25:27 -0800
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	pgsmsx601.gar.corp.intel.com (10.221.43.69) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Fri, 23 Dec 2011 18:25:26 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.38]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.199]) with mapi id
	14.01.0355.002; Fri, 23 Dec 2011 18:25:24 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: "konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
Thread-Topic: [PATCH 03/10] Xen: Export host physical CPU information to dom0
Thread-Index: AczBXS3xndCwjv8tTQC62IA/xc76Ag==
Date: Fri, 23 Dec 2011 10:25:23 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC829233596CC@SHSMSX101.ccr.corp.intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
Content-Type: multipart/mixed;
	boundary="_002_DE8DF0795D48FD4CA783C40EC829233596CCSHSMSX101ccrcorpint_"
MIME-Version: 1.0
Cc: "Brown, Len" <len.brown@intel.com>,
	"jeremy.fitzhardinge@citrix.com" <jeremy.fitzhardinge@citrix.com>,
	"Jiang, Yunhong" <yunhong.jiang@intel.com>, "Shan, 
	Haitao" <haitao.shan@intel.com>,
	Kernel development list <linux-kernel@vger.kernel.org>, "Zhao,
	Yakui" <yakui.zhao@intel.com>, "Luck, Tony" <tony.luck@intel.com>, "Kleen,
	Andi" <andi.kleen@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: [Xen-devel] [PATCH 03/10] Xen: Export host physical CPU information
	to dom0
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--_002_DE8DF0795D48FD4CA783C40EC829233596CCSHSMSX101ccrcorpint_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

>From 04151aa18b48a452cc9d0696f36aa96c690ca011 Mon Sep 17 00:00:00 2001
From: Liu Jinsong <jinsong.liu@intel.com>
Date: Thu, 8 Dec 2011 22:28:07 +0800
Subject: [PATCH 03/10] Xen: Export host physical CPU information to dom0

This patch rebased from Jeremy's pvops commit
3b34cd19627c6e191b15fd6cb59f997b8db21e19 and
68320323a51c2378aca433c76157d9e66104ff1e

This patch expose host's physical CPU information to dom0 in sysfs, so
that dom0's management tools can control the physical CPU if needed.

It also provides interface in sysfs to logical online/offline a physical CP=
U.

Notice: The information in dom0 is synced with xen hypervisor asynchronousl=
y.

Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
Signed-off-by: Jiang, Yunhong <yunhong.jiang@intel.com>
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
---
 drivers/xen/Makefile             |    2 +-
 drivers/xen/pcpu.c               |  452 ++++++++++++++++++++++++++++++++++=
++++
 include/xen/interface/platform.h |   28 +++
 include/xen/interface/xen.h      |    1 +
 include/xen/pcpu.h               |   32 +++
 5 files changed, 514 insertions(+), 1 deletions(-)
 create mode 100644 drivers/xen/pcpu.c
 create mode 100644 include/xen/pcpu.h

diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
index 405cce9..aedaf48 100644
--- a/drivers/xen/Makefile
+++ b/drivers/xen/Makefile
@@ -1,4 +1,4 @@
-obj-y	+=3D grant-table.o features.o events.o manage.o balloon.o
+obj-y	+=3D grant-table.o features.o events.o manage.o balloon.o pcpu.o
 obj-y	+=3D xenbus/
=20
 nostackp :=3D $(call cc-option, -fno-stack-protector)
diff --git a/drivers/xen/pcpu.c b/drivers/xen/pcpu.c
new file mode 100644
index 0000000..6d1a770
--- /dev/null
+++ b/drivers/xen/pcpu.c
@@ -0,0 +1,452 @@
+/*
+ * pcpu.c - management physical cpu in dom0 environment
+ */
+#include <linux/interrupt.h>
+#include <linux/spinlock.h>
+#include <asm/xen/hypervisor.h>
+#include <asm/xen/hypercall.h>
+#include <linux/cpu.h>
+#include <xen/xenbus.h>
+#include <xen/pcpu.h>
+#include <xen/events.h>
+#include <xen/acpi.h>
+
+static struct sysdev_class xen_pcpu_sysdev_class =3D {
+	.name =3D "xen_pcpu",
+};
+
+static DEFINE_MUTEX(xen_pcpu_lock);
+static RAW_NOTIFIER_HEAD(xen_pcpu_chain);
+
+/* No need for irq disable since hotplug notify is in workqueue context */
+#define get_pcpu_lock() mutex_lock(&xen_pcpu_lock);
+#define put_pcpu_lock() mutex_unlock(&xen_pcpu_lock);
+
+struct xen_pcpus {
+	struct list_head list;
+	int present;
+};
+static struct xen_pcpus xen_pcpus;
+
+int register_xen_pcpu_notifier(struct notifier_block *nb)
+{
+	int ret;
+
+	/* All refer to the chain notifier is protected by the pcpu_lock */
+	get_pcpu_lock();
+	ret =3D raw_notifier_chain_register(&xen_pcpu_chain, nb);
+	put_pcpu_lock();
+	return ret;
+}
+EXPORT_SYMBOL_GPL(register_xen_pcpu_notifier);
+
+void unregister_xen_pcpu_notifier(struct notifier_block *nb)
+{
+	get_pcpu_lock();
+	raw_notifier_chain_unregister(&xen_pcpu_chain, nb);
+	put_pcpu_lock();
+}
+EXPORT_SYMBOL_GPL(unregister_xen_pcpu_notifier);
+
+static int xen_pcpu_down(uint32_t xen_id)
+{
+	int ret;
+	xen_platform_op_t op =3D {
+		.cmd			=3D XENPF_cpu_offline,
+		.interface_version	=3D XENPF_INTERFACE_VERSION,
+		.u.cpu_ol.cpuid	=3D xen_id,
+	};
+
+	ret =3D HYPERVISOR_dom0_op(&op);
+	return ret;
+}
+
+static int xen_pcpu_up(uint32_t xen_id)
+{
+	int ret;
+	xen_platform_op_t op =3D {
+		.cmd			=3D XENPF_cpu_online,
+		.interface_version	=3D XENPF_INTERFACE_VERSION,
+		.u.cpu_ol.cpuid	=3D xen_id,
+	};
+
+	ret =3D HYPERVISOR_dom0_op(&op);
+	return ret;
+}
+
+static ssize_t show_online(struct sys_device *dev,
+			struct sysdev_attribute *attr,
+			char *buf)
+{
+	struct pcpu *cpu =3D container_of(dev, struct pcpu, sysdev);
+
+	return sprintf(buf, "%u\n", !!(cpu->flags & XEN_PCPU_FLAGS_ONLINE));
+}
+
+static ssize_t __ref store_online(struct sys_device *dev,
+				  struct sysdev_attribute *attr,
+				  const char *buf, size_t count)
+{
+	struct pcpu *cpu =3D container_of(dev, struct pcpu, sysdev);
+	ssize_t ret;
+
+	switch (buf[0]) {
+	case '0':
+		ret =3D xen_pcpu_down(cpu->xen_id);
+		break;
+	case '1':
+		ret =3D xen_pcpu_up(cpu->xen_id);
+		break;
+	default:
+		ret =3D -EINVAL;
+	}
+
+	if (ret >=3D 0)
+		ret =3D count;
+	return ret;
+}
+
+static SYSDEV_ATTR(online, 0644, show_online, store_online);
+
+static ssize_t show_apicid(struct sys_device *dev,
+			struct sysdev_attribute *attr,
+			char *buf)
+{
+	struct pcpu *cpu =3D container_of(dev, struct pcpu, sysdev);
+
+	return sprintf(buf, "%u\n", cpu->apic_id);
+}
+
+static ssize_t show_acpiid(struct sys_device *dev,
+			struct sysdev_attribute *attr,
+			char *buf)
+{
+	struct pcpu *cpu =3D container_of(dev, struct pcpu, sysdev);
+
+	return sprintf(buf, "%u\n", cpu->acpi_id);
+}
+static SYSDEV_ATTR(apic_id, 0444, show_apicid, NULL);
+static SYSDEV_ATTR(acpi_id, 0444, show_acpiid, NULL);
+
+static int xen_pcpu_free(struct pcpu *pcpu)
+{
+	if (!pcpu)
+		return 0;
+
+	sysdev_remove_file(&pcpu->sysdev, &attr_online);
+	sysdev_unregister(&pcpu->sysdev);
+	list_del(&pcpu->pcpu_list);
+	kfree(pcpu);
+
+	return 0;
+}
+
+static inline int same_pcpu(struct xenpf_pcpuinfo *info,
+			    struct pcpu *pcpu)
+{
+	return (pcpu->apic_id =3D=3D info->apic_id) &&
+		(pcpu->xen_id =3D=3D info->xen_cpuid);
+}
+
+/*
+ * Return 1 if online status changed
+ */
+static int xen_pcpu_online_check(struct xenpf_pcpuinfo *info,
+				 struct pcpu *pcpu)
+{
+	int result =3D 0;
+
+	if (info->xen_cpuid !=3D pcpu->xen_id)
+		return 0;
+
+	if (xen_pcpu_online(info->flags) && !xen_pcpu_online(pcpu->flags)) {
+		/* the pcpu is onlined */
+		pcpu->flags |=3D XEN_PCPU_FLAGS_ONLINE;
+		kobject_uevent(&pcpu->sysdev.kobj, KOBJ_ONLINE);
+		raw_notifier_call_chain(&xen_pcpu_chain,
+			XEN_PCPU_ONLINE, (void *)(long)pcpu->xen_id);
+		result =3D 1;
+	} else if (!xen_pcpu_online(info->flags) &&
+		 xen_pcpu_online(pcpu->flags))  {
+		/* The pcpu is offlined now */
+		pcpu->flags &=3D ~XEN_PCPU_FLAGS_ONLINE;
+		kobject_uevent(&pcpu->sysdev.kobj, KOBJ_OFFLINE);
+		raw_notifier_call_chain(&xen_pcpu_chain,
+			XEN_PCPU_OFFLINE, (void *)(long)pcpu->xen_id);
+		result =3D 1;
+	}
+
+	return result;
+}
+
+static int pcpu_sysdev_init(struct pcpu *cpu)
+{
+	int error;
+
+	error =3D sysdev_register(&cpu->sysdev);
+	if (error) {
+		printk(KERN_WARNING "xen_pcpu_add: Failed to register pcpu\n");
+		kfree(cpu);
+		return -1;
+	}
+	sysdev_create_file(&cpu->sysdev, &attr_online);
+	sysdev_create_file(&cpu->sysdev, &attr_apic_id);
+	sysdev_create_file(&cpu->sysdev, &attr_acpi_id);
+	return 0;
+}
+
+static struct pcpu *get_pcpu(int xen_id)
+{
+	struct pcpu *pcpu =3D NULL;
+
+	list_for_each_entry(pcpu, &xen_pcpus.list, pcpu_list) {
+		if (pcpu->xen_id =3D=3D xen_id)
+			return pcpu;
+	}
+	return NULL;
+}
+
+static struct pcpu *init_pcpu(struct xenpf_pcpuinfo *info)
+{
+	struct pcpu *pcpu;
+
+	if (info->flags & XEN_PCPU_FLAGS_INVALID)
+		return NULL;
+
+	/* The PCPU is just added */
+	pcpu =3D kzalloc(sizeof(struct pcpu), GFP_KERNEL);
+	if (!pcpu)
+		return NULL;
+
+	INIT_LIST_HEAD(&pcpu->pcpu_list);
+	pcpu->xen_id =3D info->xen_cpuid;
+	pcpu->apic_id =3D info->apic_id;
+	pcpu->acpi_id =3D info->acpi_id;
+	pcpu->flags =3D info->flags;
+
+	pcpu->sysdev.cls =3D &xen_pcpu_sysdev_class;
+	pcpu->sysdev.id =3D info->xen_cpuid;
+
+	if (pcpu_sysdev_init(pcpu)) {
+		kfree(pcpu);
+		return NULL;
+	}
+
+	list_add_tail(&pcpu->pcpu_list, &xen_pcpus.list);
+	raw_notifier_call_chain(&xen_pcpu_chain,
+				XEN_PCPU_ADD,
+				(void *)(long)pcpu->xen_id);
+	return pcpu;
+}
+
+#define PCPU_NO_CHANGE			0
+#define PCPU_ADDED			1
+#define PCPU_ONLINE_OFFLINE		2
+#define PCPU_REMOVED			3
+/*
+ * Caller should hold the pcpu lock
+ * < 0: Something wrong
+ * 0: No changes
+ * > 0: State changed
+ */
+static struct pcpu *_sync_pcpu(int cpu_num, int *max_id, int *result)
+{
+	struct pcpu *pcpu =3D NULL;
+	struct xenpf_pcpuinfo *info;
+	xen_platform_op_t op =3D {
+		.cmd            =3D XENPF_get_cpuinfo,
+		.interface_version  =3D XENPF_INTERFACE_VERSION,
+	};
+	int ret;
+
+	*result =3D -1;
+
+	info =3D &op.u.pcpu_info;
+	info->xen_cpuid =3D cpu_num;
+
+	ret =3D HYPERVISOR_dom0_op(&op);
+	if (ret)
+		return NULL;
+
+	if (max_id)
+		*max_id =3D op.u.pcpu_info.max_present;
+
+	pcpu =3D get_pcpu(cpu_num);
+
+	if (info->flags & XEN_PCPU_FLAGS_INVALID) {
+		/* The pcpu has been removed */
+		*result =3D PCPU_NO_CHANGE;
+		if (pcpu) {
+			raw_notifier_call_chain(&xen_pcpu_chain,
+			  XEN_PCPU_REMOVE,
+			  (void *)(long)pcpu->xen_id);
+			xen_pcpu_free(pcpu);
+			*result =3D PCPU_REMOVED;
+		}
+		return NULL;
+	}
+
+
+	if (!pcpu) {
+		*result =3D PCPU_ADDED;
+		pcpu =3D init_pcpu(info);
+		if (pcpu =3D=3D NULL) {
+			printk(KERN_WARNING "Failed to init pcpu %x\n",
+			  info->xen_cpuid);
+			  *result =3D -1;
+		}
+	} else {
+		*result =3D PCPU_NO_CHANGE;
+		/*
+		 * Old PCPU is replaced with a new pcpu, this means
+		 * several virq is missed, will it happen?
+		 */
+		if (!same_pcpu(info, pcpu)) {
+			printk(KERN_WARNING "Pcpu %x changed!\n",
+			  pcpu->xen_id);
+			pcpu->apic_id =3D info->apic_id;
+			pcpu->acpi_id =3D info->acpi_id;
+		}
+		if (xen_pcpu_online_check(info, pcpu))
+			*result =3D PCPU_ONLINE_OFFLINE;
+	}
+	return pcpu;
+}
+
+int xen_pcpu_index(uint32_t id, int is_acpiid)
+{
+	int cpu_num =3D 0, max_id =3D 0, ret;
+	xen_platform_op_t op =3D {
+		.cmd            =3D XENPF_get_cpuinfo,
+		.interface_version  =3D XENPF_INTERFACE_VERSION,
+	};
+	struct xenpf_pcpuinfo *info =3D &op.u.pcpu_info;
+
+	info->xen_cpuid =3D 0;
+	ret =3D HYPERVISOR_dom0_op(&op);
+	if (ret)
+		return -1;
+	max_id =3D op.u.pcpu_info.max_present;
+
+	while ((cpu_num <=3D max_id)) {
+		info->xen_cpuid =3D cpu_num;
+		ret =3D HYPERVISOR_dom0_op(&op);
+		if (ret)
+			continue;
+
+		if (op.u.pcpu_info.max_present > max_id)
+			max_id =3D op.u.pcpu_info.max_present;
+		if (id =3D=3D (is_acpiid ? info->acpi_id : info->apic_id))
+			return cpu_num;
+		cpu_num++;
+	}
+
+    return -1;
+}
+EXPORT_SYMBOL(xen_pcpu_index);
+
+/*
+ * Sync dom0's pcpu information with xen hypervisor's
+ */
+static int xen_sync_pcpus(void)
+{
+	/*
+	 * Boot cpu always have cpu_id 0 in xen
+	 */
+	int cpu_num =3D 0, max_id =3D 0, result =3D 0, present =3D 0;
+	struct list_head *elem, *tmp;
+	struct pcpu *pcpu;
+
+	get_pcpu_lock();
+
+	while ((result >=3D 0) && (cpu_num <=3D max_id)) {
+		pcpu =3D _sync_pcpu(cpu_num, &max_id, &result);
+
+		printk(KERN_DEBUG "sync cpu %x get result %x max_id %x\n",
+			cpu_num, result, max_id);
+
+		switch (result)	{
+		case PCPU_NO_CHANGE:
+			if (pcpu)
+				present++;
+			break;
+		case PCPU_ADDED:
+		case PCPU_ONLINE_OFFLINE:
+			present++;
+		case PCPU_REMOVED:
+			break;
+		default:
+			printk(KERN_WARNING "Failed to sync pcpu %x\n",
+			  cpu_num);
+			break;
+
+		}
+		cpu_num++;
+	}
+
+	if (result < 0) {
+		list_for_each_safe(elem, tmp, &xen_pcpus.list) {
+			pcpu =3D list_entry(elem, struct pcpu, pcpu_list);
+			xen_pcpu_free(pcpu);
+		}
+		present =3D 0;
+	}
+
+	xen_pcpus.present =3D present;
+
+	put_pcpu_lock();
+
+	return 0;
+}
+
+static void xen_pcpu_dpc(struct work_struct *work)
+{
+	if (xen_sync_pcpus() < 0)
+		printk(KERN_WARNING
+			"xen_pcpu_dpc: Failed to sync pcpu information\n");
+}
+static DECLARE_WORK(xen_pcpu_work, xen_pcpu_dpc);
+
+int xen_pcpu_hotplug(int type, uint32_t apic_id)
+{
+	schedule_work(&xen_pcpu_work);
+
+	return 0;
+}
+EXPORT_SYMBOL(xen_pcpu_hotplug);
+
+static irqreturn_t xen_pcpu_interrupt(int irq, void *dev_id)
+{
+	schedule_work(&xen_pcpu_work);
+	return IRQ_HANDLED;
+}
+
+static int __init xen_pcpu_init(void)
+{
+	int err;
+
+	if (!xen_initial_domain())
+		return 0;
+
+	err =3D sysdev_class_register(&xen_pcpu_sysdev_class);
+	if (err) {
+		printk(KERN_WARNING
+			"xen_pcpu_init: register xen_pcpu sysdev Failed!\n");
+		return err;
+	}
+
+	INIT_LIST_HEAD(&xen_pcpus.list);
+	xen_pcpus.present =3D 0;
+
+	xen_sync_pcpus();
+	if (xen_pcpus.present > 0)
+		err =3D bind_virq_to_irqhandler(VIRQ_PCPU_STATE,
+			0, xen_pcpu_interrupt, 0, "pcpu", NULL);
+	if (err < 0)
+		printk(KERN_WARNING "xen_pcpu_init: "
+			"Failed to bind pcpu_state virq\n"
+			"You will lost latest information! \n");
+	return err;
+}
+
+arch_initcall(xen_pcpu_init);
diff --git a/include/xen/interface/platform.h b/include/xen/interface/platf=
orm.h
index c168468..47ffe16 100644
--- a/include/xen/interface/platform.h
+++ b/include/xen/interface/platform.h
@@ -297,6 +297,31 @@ struct xenpf_set_processor_pminfo {
 };
 DEFINE_GUEST_HANDLE_STRUCT(xenpf_set_processor_pminfo);
=20
+#define XENPF_get_cpuinfo 55
+struct xenpf_pcpuinfo {
+	/* IN */
+	uint32_t xen_cpuid;
+	/* OUT */
+	/* The maxium cpu_id that is present */
+	uint32_t max_present;
+#define XEN_PCPU_FLAGS_ONLINE   1
+	/* Correponding xen_cpuid is not present*/
+#define XEN_PCPU_FLAGS_INVALID  2
+	uint32_t flags;
+	uint32_t apic_id;
+	uint32_t acpi_id;
+};
+typedef struct xenpf_pcpuinfo xenpf_pcpuinfo_t;
+DEFINE_GUEST_HANDLE_STRUCT(xenpf_pcpuinfo_t);
+
+#define XENPF_cpu_online    56
+#define XENPF_cpu_offline   57
+struct xenpf_cpu_ol {
+    uint32_t cpuid;
+};
+typedef struct xenpf_cpu_ol xenpf_cpu_ol_t;
+DEFINE_GUEST_HANDLE_STRUCT(xenpf_cpu_ol_t);
+
 struct xen_platform_op {
 	uint32_t cmd;
 	uint32_t interface_version; /* XENPF_INTERFACE_VERSION */
@@ -312,9 +337,12 @@ struct xen_platform_op {
 		struct xenpf_change_freq       change_freq;
 		struct xenpf_getidletime       getidletime;
 		struct xenpf_set_processor_pminfo set_pminfo;
+		struct xenpf_pcpuinfo          pcpu_info;
+		struct xenpf_cpu_ol            cpu_ol;
 		uint8_t                        pad[128];
 	} u;
 };
+typedef struct xen_platform_op xen_platform_op_t;
 DEFINE_GUEST_HANDLE_STRUCT(xen_platform_op_t);
=20
 #endif /* __XEN_PUBLIC_PLATFORM_H__ */
diff --git a/include/xen/interface/xen.h b/include/xen/interface/xen.h
index 6a6e914..5a91c66 100644
--- a/include/xen/interface/xen.h
+++ b/include/xen/interface/xen.h
@@ -80,6 +80,7 @@
 #define VIRQ_CONSOLE    2  /* (DOM0) Bytes received on emergency console. =
*/
 #define VIRQ_DOM_EXC    3  /* (DOM0) Exceptional event for some domain.   =
*/
 #define VIRQ_DEBUGGER   6  /* (DOM0) A domain has paused for debugging.   =
*/
+#define VIRQ_PCPU_STATE 9  /* (DOM0) PCPU state changed                   =
*/
=20
 /* Architecture-specific VIRQ definitions. */
 #define VIRQ_ARCH_0    16
diff --git a/include/xen/pcpu.h b/include/xen/pcpu.h
new file mode 100644
index 0000000..7e8f9d1
--- /dev/null
+++ b/include/xen/pcpu.h
@@ -0,0 +1,32 @@
+#ifndef _XEN_PCPU_H
+#define _XEN_PCPU_H
+
+#include <xen/interface/platform.h>
+#include <linux/sysdev.h>
+
+extern int xen_pcpu_hotplug(int type, uint32_t apic_id);
+#define XEN_PCPU_ONLINE     0x01
+#define XEN_PCPU_OFFLINE    0x02
+#define XEN_PCPU_ADD        0x04
+#define XEN_PCPU_REMOVE     0x08
+
+struct pcpu {
+	struct list_head pcpu_list;
+	struct sys_device sysdev;
+	uint32_t xen_id;
+	uint32_t apic_id;
+	uint32_t acpi_id;
+	uint32_t flags;
+};
+
+static inline int xen_pcpu_online(uint32_t flags)
+{
+	return !!(flags & XEN_PCPU_FLAGS_ONLINE);
+}
+
+extern int register_xen_pcpu_notifier(struct notifier_block *nb);
+
+extern void unregister_xen_pcpu_notifier(struct notifier_block *nb);
+
+extern int xen_pcpu_index(uint32_t acpi_id, int is_acpiid);
+#endif
--=20
1.6.5.6

--_002_DE8DF0795D48FD4CA783C40EC829233596CCSHSMSX101ccrcorpint_
Content-Type: application/octet-stream;
	name="0003-Xen-Export-host-physical-CPU-information-to-dom0.patch"
Content-Description: 0003-Xen-Export-host-physical-CPU-information-to-dom0.patch
Content-Disposition: attachment;
	filename="0003-Xen-Export-host-physical-CPU-information-to-dom0.patch";
	size=15036; creation-date="Wed, 14 Dec 2011 15:20:15 GMT";
	modification-date="Wed, 14 Dec 2011 15:03:34 GMT"
Content-Transfer-Encoding: base64

RnJvbSAwNDE1MWFhMThiNDhhNDUyY2M5ZDA2OTZmMzZhYTk2YzY5MGNhMDExIE1vbiBTZXAgMTcg
MDA6MDA6MDAgMjAwMQpGcm9tOiBMaXUgSmluc29uZyA8amluc29uZy5saXVAaW50ZWwuY29tPgpE
YXRlOiBUaHUsIDggRGVjIDIwMTEgMjI6Mjg6MDcgKzA4MDAKU3ViamVjdDogW1BBVENIIDAzLzEw
XSBYZW46IEV4cG9ydCBob3N0IHBoeXNpY2FsIENQVSBpbmZvcm1hdGlvbiB0byBkb20wCgpUaGlz
IHBhdGNoIHJlYmFzZWQgZnJvbSBKZXJlbXkncyBwdm9wcyBjb21taXQKM2IzNGNkMTk2MjdjNmUx
OTFiMTVmZDZjYjU5Zjk5N2I4ZGIyMWUxOSBhbmQKNjgzMjAzMjNhNTFjMjM3OGFjYTQzM2M3NjE1
N2Q5ZTY2MTA0ZmYxZQoKVGhpcyBwYXRjaCBleHBvc2UgaG9zdCdzIHBoeXNpY2FsIENQVSBpbmZv
cm1hdGlvbiB0byBkb20wIGluIHN5c2ZzLCBzbwp0aGF0IGRvbTAncyBtYW5hZ2VtZW50IHRvb2xz
IGNhbiBjb250cm9sIHRoZSBwaHlzaWNhbCBDUFUgaWYgbmVlZGVkLgoKSXQgYWxzbyBwcm92aWRl
cyBpbnRlcmZhY2UgaW4gc3lzZnMgdG8gbG9naWNhbCBvbmxpbmUvb2ZmbGluZSBhIHBoeXNpY2Fs
IENQVS4KCk5vdGljZTogVGhlIGluZm9ybWF0aW9uIGluIGRvbTAgaXMgc3luY2VkIHdpdGggeGVu
IGh5cGVydmlzb3IgYXN5bmNocm9ub3VzbHkuCgpTaWduZWQtb2ZmLWJ5OiBMaXUsIEppbnNvbmcg
PGppbnNvbmcubGl1QGludGVsLmNvbT4KU2lnbmVkLW9mZi1ieTogSmlhbmcsIFl1bmhvbmcgPHl1
bmhvbmcuamlhbmdAaW50ZWwuY29tPgpTaWduZWQtb2ZmLWJ5OiBKZXJlbXkgRml0emhhcmRpbmdl
IDxqZXJlbXkuZml0emhhcmRpbmdlQGNpdHJpeC5jb20+Ci0tLQogZHJpdmVycy94ZW4vTWFrZWZp
bGUgICAgICAgICAgICAgfCAgICAyICstCiBkcml2ZXJzL3hlbi9wY3B1LmMgICAgICAgICAgICAg
ICB8ICA0NTIgKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysKIGluY2x1ZGUv
eGVuL2ludGVyZmFjZS9wbGF0Zm9ybS5oIHwgICAyOCArKysKIGluY2x1ZGUveGVuL2ludGVyZmFj
ZS94ZW4uaCAgICAgIHwgICAgMSArCiBpbmNsdWRlL3hlbi9wY3B1LmggICAgICAgICAgICAgICB8
ICAgMzIgKysrCiA1IGZpbGVzIGNoYW5nZWQsIDUxNCBpbnNlcnRpb25zKCspLCAxIGRlbGV0aW9u
cygtKQogY3JlYXRlIG1vZGUgMTAwNjQ0IGRyaXZlcnMveGVuL3BjcHUuYwogY3JlYXRlIG1vZGUg
MTAwNjQ0IGluY2x1ZGUveGVuL3BjcHUuaAoKZGlmZiAtLWdpdCBhL2RyaXZlcnMveGVuL01ha2Vm
aWxlIGIvZHJpdmVycy94ZW4vTWFrZWZpbGUKaW5kZXggNDA1Y2NlOS4uYWVkYWY0OCAxMDA2NDQK
LS0tIGEvZHJpdmVycy94ZW4vTWFrZWZpbGUKKysrIGIvZHJpdmVycy94ZW4vTWFrZWZpbGUKQEAg
LTEsNCArMSw0IEBACi1vYmoteQkrPSBncmFudC10YWJsZS5vIGZlYXR1cmVzLm8gZXZlbnRzLm8g
bWFuYWdlLm8gYmFsbG9vbi5vCitvYmoteQkrPSBncmFudC10YWJsZS5vIGZlYXR1cmVzLm8gZXZl
bnRzLm8gbWFuYWdlLm8gYmFsbG9vbi5vIHBjcHUubwogb2JqLXkJKz0geGVuYnVzLwogCiBub3N0
YWNrcCA6PSAkKGNhbGwgY2Mtb3B0aW9uLCAtZm5vLXN0YWNrLXByb3RlY3RvcikKZGlmZiAtLWdp
dCBhL2RyaXZlcnMveGVuL3BjcHUuYyBiL2RyaXZlcnMveGVuL3BjcHUuYwpuZXcgZmlsZSBtb2Rl
IDEwMDY0NAppbmRleCAwMDAwMDAwLi42ZDFhNzcwCi0tLSAvZGV2L251bGwKKysrIGIvZHJpdmVy
cy94ZW4vcGNwdS5jCkBAIC0wLDAgKzEsNDUyIEBACisvKgorICogcGNwdS5jIC0gbWFuYWdlbWVu
dCBwaHlzaWNhbCBjcHUgaW4gZG9tMCBlbnZpcm9ubWVudAorICovCisjaW5jbHVkZSA8bGludXgv
aW50ZXJydXB0Lmg+CisjaW5jbHVkZSA8bGludXgvc3BpbmxvY2suaD4KKyNpbmNsdWRlIDxhc20v
eGVuL2h5cGVydmlzb3IuaD4KKyNpbmNsdWRlIDxhc20veGVuL2h5cGVyY2FsbC5oPgorI2luY2x1
ZGUgPGxpbnV4L2NwdS5oPgorI2luY2x1ZGUgPHhlbi94ZW5idXMuaD4KKyNpbmNsdWRlIDx4ZW4v
cGNwdS5oPgorI2luY2x1ZGUgPHhlbi9ldmVudHMuaD4KKyNpbmNsdWRlIDx4ZW4vYWNwaS5oPgor
CitzdGF0aWMgc3RydWN0IHN5c2Rldl9jbGFzcyB4ZW5fcGNwdV9zeXNkZXZfY2xhc3MgPSB7CisJ
Lm5hbWUgPSAieGVuX3BjcHUiLAorfTsKKworc3RhdGljIERFRklORV9NVVRFWCh4ZW5fcGNwdV9s
b2NrKTsKK3N0YXRpYyBSQVdfTk9USUZJRVJfSEVBRCh4ZW5fcGNwdV9jaGFpbik7CisKKy8qIE5v
IG5lZWQgZm9yIGlycSBkaXNhYmxlIHNpbmNlIGhvdHBsdWcgbm90aWZ5IGlzIGluIHdvcmtxdWV1
ZSBjb250ZXh0ICovCisjZGVmaW5lIGdldF9wY3B1X2xvY2soKSBtdXRleF9sb2NrKCZ4ZW5fcGNw
dV9sb2NrKTsKKyNkZWZpbmUgcHV0X3BjcHVfbG9jaygpIG11dGV4X3VubG9jaygmeGVuX3BjcHVf
bG9jayk7CisKK3N0cnVjdCB4ZW5fcGNwdXMgeworCXN0cnVjdCBsaXN0X2hlYWQgbGlzdDsKKwlp
bnQgcHJlc2VudDsKK307CitzdGF0aWMgc3RydWN0IHhlbl9wY3B1cyB4ZW5fcGNwdXM7CisKK2lu
dCByZWdpc3Rlcl94ZW5fcGNwdV9ub3RpZmllcihzdHJ1Y3Qgbm90aWZpZXJfYmxvY2sgKm5iKQor
eworCWludCByZXQ7CisKKwkvKiBBbGwgcmVmZXIgdG8gdGhlIGNoYWluIG5vdGlmaWVyIGlzIHBy
b3RlY3RlZCBieSB0aGUgcGNwdV9sb2NrICovCisJZ2V0X3BjcHVfbG9jaygpOworCXJldCA9IHJh
d19ub3RpZmllcl9jaGFpbl9yZWdpc3RlcigmeGVuX3BjcHVfY2hhaW4sIG5iKTsKKwlwdXRfcGNw
dV9sb2NrKCk7CisJcmV0dXJuIHJldDsKK30KK0VYUE9SVF9TWU1CT0xfR1BMKHJlZ2lzdGVyX3hl
bl9wY3B1X25vdGlmaWVyKTsKKwordm9pZCB1bnJlZ2lzdGVyX3hlbl9wY3B1X25vdGlmaWVyKHN0
cnVjdCBub3RpZmllcl9ibG9jayAqbmIpCit7CisJZ2V0X3BjcHVfbG9jaygpOworCXJhd19ub3Rp
Zmllcl9jaGFpbl91bnJlZ2lzdGVyKCZ4ZW5fcGNwdV9jaGFpbiwgbmIpOworCXB1dF9wY3B1X2xv
Y2soKTsKK30KK0VYUE9SVF9TWU1CT0xfR1BMKHVucmVnaXN0ZXJfeGVuX3BjcHVfbm90aWZpZXIp
OworCitzdGF0aWMgaW50IHhlbl9wY3B1X2Rvd24odWludDMyX3QgeGVuX2lkKQoreworCWludCBy
ZXQ7CisJeGVuX3BsYXRmb3JtX29wX3Qgb3AgPSB7CisJCS5jbWQJCQk9IFhFTlBGX2NwdV9vZmZs
aW5lLAorCQkuaW50ZXJmYWNlX3ZlcnNpb24JPSBYRU5QRl9JTlRFUkZBQ0VfVkVSU0lPTiwKKwkJ
LnUuY3B1X29sLmNwdWlkCT0geGVuX2lkLAorCX07CisKKwlyZXQgPSBIWVBFUlZJU09SX2RvbTBf
b3AoJm9wKTsKKwlyZXR1cm4gcmV0OworfQorCitzdGF0aWMgaW50IHhlbl9wY3B1X3VwKHVpbnQz
Ml90IHhlbl9pZCkKK3sKKwlpbnQgcmV0OworCXhlbl9wbGF0Zm9ybV9vcF90IG9wID0geworCQku
Y21kCQkJPSBYRU5QRl9jcHVfb25saW5lLAorCQkuaW50ZXJmYWNlX3ZlcnNpb24JPSBYRU5QRl9J
TlRFUkZBQ0VfVkVSU0lPTiwKKwkJLnUuY3B1X29sLmNwdWlkCT0geGVuX2lkLAorCX07CisKKwly
ZXQgPSBIWVBFUlZJU09SX2RvbTBfb3AoJm9wKTsKKwlyZXR1cm4gcmV0OworfQorCitzdGF0aWMg
c3NpemVfdCBzaG93X29ubGluZShzdHJ1Y3Qgc3lzX2RldmljZSAqZGV2LAorCQkJc3RydWN0IHN5
c2Rldl9hdHRyaWJ1dGUgKmF0dHIsCisJCQljaGFyICpidWYpCit7CisJc3RydWN0IHBjcHUgKmNw
dSA9IGNvbnRhaW5lcl9vZihkZXYsIHN0cnVjdCBwY3B1LCBzeXNkZXYpOworCisJcmV0dXJuIHNw
cmludGYoYnVmLCAiJXVcbiIsICEhKGNwdS0+ZmxhZ3MgJiBYRU5fUENQVV9GTEFHU19PTkxJTkUp
KTsKK30KKworc3RhdGljIHNzaXplX3QgX19yZWYgc3RvcmVfb25saW5lKHN0cnVjdCBzeXNfZGV2
aWNlICpkZXYsCisJCQkJICBzdHJ1Y3Qgc3lzZGV2X2F0dHJpYnV0ZSAqYXR0ciwKKwkJCQkgIGNv
bnN0IGNoYXIgKmJ1Ziwgc2l6ZV90IGNvdW50KQoreworCXN0cnVjdCBwY3B1ICpjcHUgPSBjb250
YWluZXJfb2YoZGV2LCBzdHJ1Y3QgcGNwdSwgc3lzZGV2KTsKKwlzc2l6ZV90IHJldDsKKworCXN3
aXRjaCAoYnVmWzBdKSB7CisJY2FzZSAnMCc6CisJCXJldCA9IHhlbl9wY3B1X2Rvd24oY3B1LT54
ZW5faWQpOworCQlicmVhazsKKwljYXNlICcxJzoKKwkJcmV0ID0geGVuX3BjcHVfdXAoY3B1LT54
ZW5faWQpOworCQlicmVhazsKKwlkZWZhdWx0OgorCQlyZXQgPSAtRUlOVkFMOworCX0KKworCWlm
IChyZXQgPj0gMCkKKwkJcmV0ID0gY291bnQ7CisJcmV0dXJuIHJldDsKK30KKworc3RhdGljIFNZ
U0RFVl9BVFRSKG9ubGluZSwgMDY0NCwgc2hvd19vbmxpbmUsIHN0b3JlX29ubGluZSk7CisKK3N0
YXRpYyBzc2l6ZV90IHNob3dfYXBpY2lkKHN0cnVjdCBzeXNfZGV2aWNlICpkZXYsCisJCQlzdHJ1
Y3Qgc3lzZGV2X2F0dHJpYnV0ZSAqYXR0ciwKKwkJCWNoYXIgKmJ1ZikKK3sKKwlzdHJ1Y3QgcGNw
dSAqY3B1ID0gY29udGFpbmVyX29mKGRldiwgc3RydWN0IHBjcHUsIHN5c2Rldik7CisKKwlyZXR1
cm4gc3ByaW50ZihidWYsICIldVxuIiwgY3B1LT5hcGljX2lkKTsKK30KKworc3RhdGljIHNzaXpl
X3Qgc2hvd19hY3BpaWQoc3RydWN0IHN5c19kZXZpY2UgKmRldiwKKwkJCXN0cnVjdCBzeXNkZXZf
YXR0cmlidXRlICphdHRyLAorCQkJY2hhciAqYnVmKQoreworCXN0cnVjdCBwY3B1ICpjcHUgPSBj
b250YWluZXJfb2YoZGV2LCBzdHJ1Y3QgcGNwdSwgc3lzZGV2KTsKKworCXJldHVybiBzcHJpbnRm
KGJ1ZiwgIiV1XG4iLCBjcHUtPmFjcGlfaWQpOworfQorc3RhdGljIFNZU0RFVl9BVFRSKGFwaWNf
aWQsIDA0NDQsIHNob3dfYXBpY2lkLCBOVUxMKTsKK3N0YXRpYyBTWVNERVZfQVRUUihhY3BpX2lk
LCAwNDQ0LCBzaG93X2FjcGlpZCwgTlVMTCk7CisKK3N0YXRpYyBpbnQgeGVuX3BjcHVfZnJlZShz
dHJ1Y3QgcGNwdSAqcGNwdSkKK3sKKwlpZiAoIXBjcHUpCisJCXJldHVybiAwOworCisJc3lzZGV2
X3JlbW92ZV9maWxlKCZwY3B1LT5zeXNkZXYsICZhdHRyX29ubGluZSk7CisJc3lzZGV2X3VucmVn
aXN0ZXIoJnBjcHUtPnN5c2Rldik7CisJbGlzdF9kZWwoJnBjcHUtPnBjcHVfbGlzdCk7CisJa2Zy
ZWUocGNwdSk7CisKKwlyZXR1cm4gMDsKK30KKworc3RhdGljIGlubGluZSBpbnQgc2FtZV9wY3B1
KHN0cnVjdCB4ZW5wZl9wY3B1aW5mbyAqaW5mbywKKwkJCSAgICBzdHJ1Y3QgcGNwdSAqcGNwdSkK
K3sKKwlyZXR1cm4gKHBjcHUtPmFwaWNfaWQgPT0gaW5mby0+YXBpY19pZCkgJiYKKwkJKHBjcHUt
Pnhlbl9pZCA9PSBpbmZvLT54ZW5fY3B1aWQpOworfQorCisvKgorICogUmV0dXJuIDEgaWYgb25s
aW5lIHN0YXR1cyBjaGFuZ2VkCisgKi8KK3N0YXRpYyBpbnQgeGVuX3BjcHVfb25saW5lX2NoZWNr
KHN0cnVjdCB4ZW5wZl9wY3B1aW5mbyAqaW5mbywKKwkJCQkgc3RydWN0IHBjcHUgKnBjcHUpCit7
CisJaW50IHJlc3VsdCA9IDA7CisKKwlpZiAoaW5mby0+eGVuX2NwdWlkICE9IHBjcHUtPnhlbl9p
ZCkKKwkJcmV0dXJuIDA7CisKKwlpZiAoeGVuX3BjcHVfb25saW5lKGluZm8tPmZsYWdzKSAmJiAh
eGVuX3BjcHVfb25saW5lKHBjcHUtPmZsYWdzKSkgeworCQkvKiB0aGUgcGNwdSBpcyBvbmxpbmVk
ICovCisJCXBjcHUtPmZsYWdzIHw9IFhFTl9QQ1BVX0ZMQUdTX09OTElORTsKKwkJa29iamVjdF91
ZXZlbnQoJnBjcHUtPnN5c2Rldi5rb2JqLCBLT0JKX09OTElORSk7CisJCXJhd19ub3RpZmllcl9j
YWxsX2NoYWluKCZ4ZW5fcGNwdV9jaGFpbiwKKwkJCVhFTl9QQ1BVX09OTElORSwgKHZvaWQgKiko
bG9uZylwY3B1LT54ZW5faWQpOworCQlyZXN1bHQgPSAxOworCX0gZWxzZSBpZiAoIXhlbl9wY3B1
X29ubGluZShpbmZvLT5mbGFncykgJiYKKwkJIHhlbl9wY3B1X29ubGluZShwY3B1LT5mbGFncykp
ICB7CisJCS8qIFRoZSBwY3B1IGlzIG9mZmxpbmVkIG5vdyAqLworCQlwY3B1LT5mbGFncyAmPSB+
WEVOX1BDUFVfRkxBR1NfT05MSU5FOworCQlrb2JqZWN0X3VldmVudCgmcGNwdS0+c3lzZGV2Lmtv
YmosIEtPQkpfT0ZGTElORSk7CisJCXJhd19ub3RpZmllcl9jYWxsX2NoYWluKCZ4ZW5fcGNwdV9j
aGFpbiwKKwkJCVhFTl9QQ1BVX09GRkxJTkUsICh2b2lkICopKGxvbmcpcGNwdS0+eGVuX2lkKTsK
KwkJcmVzdWx0ID0gMTsKKwl9CisKKwlyZXR1cm4gcmVzdWx0OworfQorCitzdGF0aWMgaW50IHBj
cHVfc3lzZGV2X2luaXQoc3RydWN0IHBjcHUgKmNwdSkKK3sKKwlpbnQgZXJyb3I7CisKKwllcnJv
ciA9IHN5c2Rldl9yZWdpc3RlcigmY3B1LT5zeXNkZXYpOworCWlmIChlcnJvcikgeworCQlwcmlu
dGsoS0VSTl9XQVJOSU5HICJ4ZW5fcGNwdV9hZGQ6IEZhaWxlZCB0byByZWdpc3RlciBwY3B1XG4i
KTsKKwkJa2ZyZWUoY3B1KTsKKwkJcmV0dXJuIC0xOworCX0KKwlzeXNkZXZfY3JlYXRlX2ZpbGUo
JmNwdS0+c3lzZGV2LCAmYXR0cl9vbmxpbmUpOworCXN5c2Rldl9jcmVhdGVfZmlsZSgmY3B1LT5z
eXNkZXYsICZhdHRyX2FwaWNfaWQpOworCXN5c2Rldl9jcmVhdGVfZmlsZSgmY3B1LT5zeXNkZXYs
ICZhdHRyX2FjcGlfaWQpOworCXJldHVybiAwOworfQorCitzdGF0aWMgc3RydWN0IHBjcHUgKmdl
dF9wY3B1KGludCB4ZW5faWQpCit7CisJc3RydWN0IHBjcHUgKnBjcHUgPSBOVUxMOworCisJbGlz
dF9mb3JfZWFjaF9lbnRyeShwY3B1LCAmeGVuX3BjcHVzLmxpc3QsIHBjcHVfbGlzdCkgeworCQlp
ZiAocGNwdS0+eGVuX2lkID09IHhlbl9pZCkKKwkJCXJldHVybiBwY3B1OworCX0KKwlyZXR1cm4g
TlVMTDsKK30KKworc3RhdGljIHN0cnVjdCBwY3B1ICppbml0X3BjcHUoc3RydWN0IHhlbnBmX3Bj
cHVpbmZvICppbmZvKQoreworCXN0cnVjdCBwY3B1ICpwY3B1OworCisJaWYgKGluZm8tPmZsYWdz
ICYgWEVOX1BDUFVfRkxBR1NfSU5WQUxJRCkKKwkJcmV0dXJuIE5VTEw7CisKKwkvKiBUaGUgUENQ
VSBpcyBqdXN0IGFkZGVkICovCisJcGNwdSA9IGt6YWxsb2Moc2l6ZW9mKHN0cnVjdCBwY3B1KSwg
R0ZQX0tFUk5FTCk7CisJaWYgKCFwY3B1KQorCQlyZXR1cm4gTlVMTDsKKworCUlOSVRfTElTVF9I
RUFEKCZwY3B1LT5wY3B1X2xpc3QpOworCXBjcHUtPnhlbl9pZCA9IGluZm8tPnhlbl9jcHVpZDsK
KwlwY3B1LT5hcGljX2lkID0gaW5mby0+YXBpY19pZDsKKwlwY3B1LT5hY3BpX2lkID0gaW5mby0+
YWNwaV9pZDsKKwlwY3B1LT5mbGFncyA9IGluZm8tPmZsYWdzOworCisJcGNwdS0+c3lzZGV2LmNs
cyA9ICZ4ZW5fcGNwdV9zeXNkZXZfY2xhc3M7CisJcGNwdS0+c3lzZGV2LmlkID0gaW5mby0+eGVu
X2NwdWlkOworCisJaWYgKHBjcHVfc3lzZGV2X2luaXQocGNwdSkpIHsKKwkJa2ZyZWUocGNwdSk7
CisJCXJldHVybiBOVUxMOworCX0KKworCWxpc3RfYWRkX3RhaWwoJnBjcHUtPnBjcHVfbGlzdCwg
Jnhlbl9wY3B1cy5saXN0KTsKKwlyYXdfbm90aWZpZXJfY2FsbF9jaGFpbigmeGVuX3BjcHVfY2hh
aW4sCisJCQkJWEVOX1BDUFVfQURELAorCQkJCSh2b2lkICopKGxvbmcpcGNwdS0+eGVuX2lkKTsK
KwlyZXR1cm4gcGNwdTsKK30KKworI2RlZmluZSBQQ1BVX05PX0NIQU5HRQkJCTAKKyNkZWZpbmUg
UENQVV9BRERFRAkJCTEKKyNkZWZpbmUgUENQVV9PTkxJTkVfT0ZGTElORQkJMgorI2RlZmluZSBQ
Q1BVX1JFTU9WRUQJCQkzCisvKgorICogQ2FsbGVyIHNob3VsZCBob2xkIHRoZSBwY3B1IGxvY2sK
KyAqIDwgMDogU29tZXRoaW5nIHdyb25nCisgKiAwOiBObyBjaGFuZ2VzCisgKiA+IDA6IFN0YXRl
IGNoYW5nZWQKKyAqLworc3RhdGljIHN0cnVjdCBwY3B1ICpfc3luY19wY3B1KGludCBjcHVfbnVt
LCBpbnQgKm1heF9pZCwgaW50ICpyZXN1bHQpCit7CisJc3RydWN0IHBjcHUgKnBjcHUgPSBOVUxM
OworCXN0cnVjdCB4ZW5wZl9wY3B1aW5mbyAqaW5mbzsKKwl4ZW5fcGxhdGZvcm1fb3BfdCBvcCA9
IHsKKwkJLmNtZCAgICAgICAgICAgID0gWEVOUEZfZ2V0X2NwdWluZm8sCisJCS5pbnRlcmZhY2Vf
dmVyc2lvbiAgPSBYRU5QRl9JTlRFUkZBQ0VfVkVSU0lPTiwKKwl9OworCWludCByZXQ7CisKKwkq
cmVzdWx0ID0gLTE7CisKKwlpbmZvID0gJm9wLnUucGNwdV9pbmZvOworCWluZm8tPnhlbl9jcHVp
ZCA9IGNwdV9udW07CisKKwlyZXQgPSBIWVBFUlZJU09SX2RvbTBfb3AoJm9wKTsKKwlpZiAocmV0
KQorCQlyZXR1cm4gTlVMTDsKKworCWlmIChtYXhfaWQpCisJCSptYXhfaWQgPSBvcC51LnBjcHVf
aW5mby5tYXhfcHJlc2VudDsKKworCXBjcHUgPSBnZXRfcGNwdShjcHVfbnVtKTsKKworCWlmIChp
bmZvLT5mbGFncyAmIFhFTl9QQ1BVX0ZMQUdTX0lOVkFMSUQpIHsKKwkJLyogVGhlIHBjcHUgaGFz
IGJlZW4gcmVtb3ZlZCAqLworCQkqcmVzdWx0ID0gUENQVV9OT19DSEFOR0U7CisJCWlmIChwY3B1
KSB7CisJCQlyYXdfbm90aWZpZXJfY2FsbF9jaGFpbigmeGVuX3BjcHVfY2hhaW4sCisJCQkgIFhF
Tl9QQ1BVX1JFTU9WRSwKKwkJCSAgKHZvaWQgKikobG9uZylwY3B1LT54ZW5faWQpOworCQkJeGVu
X3BjcHVfZnJlZShwY3B1KTsKKwkJCSpyZXN1bHQgPSBQQ1BVX1JFTU9WRUQ7CisJCX0KKwkJcmV0
dXJuIE5VTEw7CisJfQorCisKKwlpZiAoIXBjcHUpIHsKKwkJKnJlc3VsdCA9IFBDUFVfQURERUQ7
CisJCXBjcHUgPSBpbml0X3BjcHUoaW5mbyk7CisJCWlmIChwY3B1ID09IE5VTEwpIHsKKwkJCXBy
aW50ayhLRVJOX1dBUk5JTkcgIkZhaWxlZCB0byBpbml0IHBjcHUgJXhcbiIsCisJCQkgIGluZm8t
Pnhlbl9jcHVpZCk7CisJCQkgICpyZXN1bHQgPSAtMTsKKwkJfQorCX0gZWxzZSB7CisJCSpyZXN1
bHQgPSBQQ1BVX05PX0NIQU5HRTsKKwkJLyoKKwkJICogT2xkIFBDUFUgaXMgcmVwbGFjZWQgd2l0
aCBhIG5ldyBwY3B1LCB0aGlzIG1lYW5zCisJCSAqIHNldmVyYWwgdmlycSBpcyBtaXNzZWQsIHdp
bGwgaXQgaGFwcGVuPworCQkgKi8KKwkJaWYgKCFzYW1lX3BjcHUoaW5mbywgcGNwdSkpIHsKKwkJ
CXByaW50ayhLRVJOX1dBUk5JTkcgIlBjcHUgJXggY2hhbmdlZCFcbiIsCisJCQkgIHBjcHUtPnhl
bl9pZCk7CisJCQlwY3B1LT5hcGljX2lkID0gaW5mby0+YXBpY19pZDsKKwkJCXBjcHUtPmFjcGlf
aWQgPSBpbmZvLT5hY3BpX2lkOworCQl9CisJCWlmICh4ZW5fcGNwdV9vbmxpbmVfY2hlY2soaW5m
bywgcGNwdSkpCisJCQkqcmVzdWx0ID0gUENQVV9PTkxJTkVfT0ZGTElORTsKKwl9CisJcmV0dXJu
IHBjcHU7Cit9CisKK2ludCB4ZW5fcGNwdV9pbmRleCh1aW50MzJfdCBpZCwgaW50IGlzX2FjcGlp
ZCkKK3sKKwlpbnQgY3B1X251bSA9IDAsIG1heF9pZCA9IDAsIHJldDsKKwl4ZW5fcGxhdGZvcm1f
b3BfdCBvcCA9IHsKKwkJLmNtZCAgICAgICAgICAgID0gWEVOUEZfZ2V0X2NwdWluZm8sCisJCS5p
bnRlcmZhY2VfdmVyc2lvbiAgPSBYRU5QRl9JTlRFUkZBQ0VfVkVSU0lPTiwKKwl9OworCXN0cnVj
dCB4ZW5wZl9wY3B1aW5mbyAqaW5mbyA9ICZvcC51LnBjcHVfaW5mbzsKKworCWluZm8tPnhlbl9j
cHVpZCA9IDA7CisJcmV0ID0gSFlQRVJWSVNPUl9kb20wX29wKCZvcCk7CisJaWYgKHJldCkKKwkJ
cmV0dXJuIC0xOworCW1heF9pZCA9IG9wLnUucGNwdV9pbmZvLm1heF9wcmVzZW50OworCisJd2hp
bGUgKChjcHVfbnVtIDw9IG1heF9pZCkpIHsKKwkJaW5mby0+eGVuX2NwdWlkID0gY3B1X251bTsK
KwkJcmV0ID0gSFlQRVJWSVNPUl9kb20wX29wKCZvcCk7CisJCWlmIChyZXQpCisJCQljb250aW51
ZTsKKworCQlpZiAob3AudS5wY3B1X2luZm8ubWF4X3ByZXNlbnQgPiBtYXhfaWQpCisJCQltYXhf
aWQgPSBvcC51LnBjcHVfaW5mby5tYXhfcHJlc2VudDsKKwkJaWYgKGlkID09IChpc19hY3BpaWQg
PyBpbmZvLT5hY3BpX2lkIDogaW5mby0+YXBpY19pZCkpCisJCQlyZXR1cm4gY3B1X251bTsKKwkJ
Y3B1X251bSsrOworCX0KKworICAgIHJldHVybiAtMTsKK30KK0VYUE9SVF9TWU1CT0woeGVuX3Bj
cHVfaW5kZXgpOworCisvKgorICogU3luYyBkb20wJ3MgcGNwdSBpbmZvcm1hdGlvbiB3aXRoIHhl
biBoeXBlcnZpc29yJ3MKKyAqLworc3RhdGljIGludCB4ZW5fc3luY19wY3B1cyh2b2lkKQorewor
CS8qCisJICogQm9vdCBjcHUgYWx3YXlzIGhhdmUgY3B1X2lkIDAgaW4geGVuCisJICovCisJaW50
IGNwdV9udW0gPSAwLCBtYXhfaWQgPSAwLCByZXN1bHQgPSAwLCBwcmVzZW50ID0gMDsKKwlzdHJ1
Y3QgbGlzdF9oZWFkICplbGVtLCAqdG1wOworCXN0cnVjdCBwY3B1ICpwY3B1OworCisJZ2V0X3Bj
cHVfbG9jaygpOworCisJd2hpbGUgKChyZXN1bHQgPj0gMCkgJiYgKGNwdV9udW0gPD0gbWF4X2lk
KSkgeworCQlwY3B1ID0gX3N5bmNfcGNwdShjcHVfbnVtLCAmbWF4X2lkLCAmcmVzdWx0KTsKKwor
CQlwcmludGsoS0VSTl9ERUJVRyAic3luYyBjcHUgJXggZ2V0IHJlc3VsdCAleCBtYXhfaWQgJXhc
biIsCisJCQljcHVfbnVtLCByZXN1bHQsIG1heF9pZCk7CisKKwkJc3dpdGNoIChyZXN1bHQpCXsK
KwkJY2FzZSBQQ1BVX05PX0NIQU5HRToKKwkJCWlmIChwY3B1KQorCQkJCXByZXNlbnQrKzsKKwkJ
CWJyZWFrOworCQljYXNlIFBDUFVfQURERUQ6CisJCWNhc2UgUENQVV9PTkxJTkVfT0ZGTElORToK
KwkJCXByZXNlbnQrKzsKKwkJY2FzZSBQQ1BVX1JFTU9WRUQ6CisJCQlicmVhazsKKwkJZGVmYXVs
dDoKKwkJCXByaW50ayhLRVJOX1dBUk5JTkcgIkZhaWxlZCB0byBzeW5jIHBjcHUgJXhcbiIsCisJ
CQkgIGNwdV9udW0pOworCQkJYnJlYWs7CisKKwkJfQorCQljcHVfbnVtKys7CisJfQorCisJaWYg
KHJlc3VsdCA8IDApIHsKKwkJbGlzdF9mb3JfZWFjaF9zYWZlKGVsZW0sIHRtcCwgJnhlbl9wY3B1
cy5saXN0KSB7CisJCQlwY3B1ID0gbGlzdF9lbnRyeShlbGVtLCBzdHJ1Y3QgcGNwdSwgcGNwdV9s
aXN0KTsKKwkJCXhlbl9wY3B1X2ZyZWUocGNwdSk7CisJCX0KKwkJcHJlc2VudCA9IDA7CisJfQor
CisJeGVuX3BjcHVzLnByZXNlbnQgPSBwcmVzZW50OworCisJcHV0X3BjcHVfbG9jaygpOworCisJ
cmV0dXJuIDA7Cit9CisKK3N0YXRpYyB2b2lkIHhlbl9wY3B1X2RwYyhzdHJ1Y3Qgd29ya19zdHJ1
Y3QgKndvcmspCit7CisJaWYgKHhlbl9zeW5jX3BjcHVzKCkgPCAwKQorCQlwcmludGsoS0VSTl9X
QVJOSU5HCisJCQkieGVuX3BjcHVfZHBjOiBGYWlsZWQgdG8gc3luYyBwY3B1IGluZm9ybWF0aW9u
XG4iKTsKK30KK3N0YXRpYyBERUNMQVJFX1dPUksoeGVuX3BjcHVfd29yaywgeGVuX3BjcHVfZHBj
KTsKKworaW50IHhlbl9wY3B1X2hvdHBsdWcoaW50IHR5cGUsIHVpbnQzMl90IGFwaWNfaWQpCit7
CisJc2NoZWR1bGVfd29yaygmeGVuX3BjcHVfd29yayk7CisKKwlyZXR1cm4gMDsKK30KK0VYUE9S
VF9TWU1CT0woeGVuX3BjcHVfaG90cGx1Zyk7CisKK3N0YXRpYyBpcnFyZXR1cm5fdCB4ZW5fcGNw
dV9pbnRlcnJ1cHQoaW50IGlycSwgdm9pZCAqZGV2X2lkKQoreworCXNjaGVkdWxlX3dvcmsoJnhl
bl9wY3B1X3dvcmspOworCXJldHVybiBJUlFfSEFORExFRDsKK30KKworc3RhdGljIGludCBfX2lu
aXQgeGVuX3BjcHVfaW5pdCh2b2lkKQoreworCWludCBlcnI7CisKKwlpZiAoIXhlbl9pbml0aWFs
X2RvbWFpbigpKQorCQlyZXR1cm4gMDsKKworCWVyciA9IHN5c2Rldl9jbGFzc19yZWdpc3Rlcigm
eGVuX3BjcHVfc3lzZGV2X2NsYXNzKTsKKwlpZiAoZXJyKSB7CisJCXByaW50ayhLRVJOX1dBUk5J
TkcKKwkJCSJ4ZW5fcGNwdV9pbml0OiByZWdpc3RlciB4ZW5fcGNwdSBzeXNkZXYgRmFpbGVkIVxu
Iik7CisJCXJldHVybiBlcnI7CisJfQorCisJSU5JVF9MSVNUX0hFQUQoJnhlbl9wY3B1cy5saXN0
KTsKKwl4ZW5fcGNwdXMucHJlc2VudCA9IDA7CisKKwl4ZW5fc3luY19wY3B1cygpOworCWlmICh4
ZW5fcGNwdXMucHJlc2VudCA+IDApCisJCWVyciA9IGJpbmRfdmlycV90b19pcnFoYW5kbGVyKFZJ
UlFfUENQVV9TVEFURSwKKwkJCTAsIHhlbl9wY3B1X2ludGVycnVwdCwgMCwgInBjcHUiLCBOVUxM
KTsKKwlpZiAoZXJyIDwgMCkKKwkJcHJpbnRrKEtFUk5fV0FSTklORyAieGVuX3BjcHVfaW5pdDog
IgorCQkJIkZhaWxlZCB0byBiaW5kIHBjcHVfc3RhdGUgdmlycVxuIgorCQkJIllvdSB3aWxsIGxv
c3QgbGF0ZXN0IGluZm9ybWF0aW9uISBcbiIpOworCXJldHVybiBlcnI7Cit9CisKK2FyY2hfaW5p
dGNhbGwoeGVuX3BjcHVfaW5pdCk7CmRpZmYgLS1naXQgYS9pbmNsdWRlL3hlbi9pbnRlcmZhY2Uv
cGxhdGZvcm0uaCBiL2luY2x1ZGUveGVuL2ludGVyZmFjZS9wbGF0Zm9ybS5oCmluZGV4IGMxNjg0
NjguLjQ3ZmZlMTYgMTAwNjQ0Ci0tLSBhL2luY2x1ZGUveGVuL2ludGVyZmFjZS9wbGF0Zm9ybS5o
CisrKyBiL2luY2x1ZGUveGVuL2ludGVyZmFjZS9wbGF0Zm9ybS5oCkBAIC0yOTcsNiArMjk3LDMx
IEBAIHN0cnVjdCB4ZW5wZl9zZXRfcHJvY2Vzc29yX3BtaW5mbyB7CiB9OwogREVGSU5FX0dVRVNU
X0hBTkRMRV9TVFJVQ1QoeGVucGZfc2V0X3Byb2Nlc3Nvcl9wbWluZm8pOwogCisjZGVmaW5lIFhF
TlBGX2dldF9jcHVpbmZvIDU1CitzdHJ1Y3QgeGVucGZfcGNwdWluZm8geworCS8qIElOICovCisJ
dWludDMyX3QgeGVuX2NwdWlkOworCS8qIE9VVCAqLworCS8qIFRoZSBtYXhpdW0gY3B1X2lkIHRo
YXQgaXMgcHJlc2VudCAqLworCXVpbnQzMl90IG1heF9wcmVzZW50OworI2RlZmluZSBYRU5fUENQ
VV9GTEFHU19PTkxJTkUgICAxCisJLyogQ29ycmVwb25kaW5nIHhlbl9jcHVpZCBpcyBub3QgcHJl
c2VudCovCisjZGVmaW5lIFhFTl9QQ1BVX0ZMQUdTX0lOVkFMSUQgIDIKKwl1aW50MzJfdCBmbGFn
czsKKwl1aW50MzJfdCBhcGljX2lkOworCXVpbnQzMl90IGFjcGlfaWQ7Cit9OwordHlwZWRlZiBz
dHJ1Y3QgeGVucGZfcGNwdWluZm8geGVucGZfcGNwdWluZm9fdDsKK0RFRklORV9HVUVTVF9IQU5E
TEVfU1RSVUNUKHhlbnBmX3BjcHVpbmZvX3QpOworCisjZGVmaW5lIFhFTlBGX2NwdV9vbmxpbmUg
ICAgNTYKKyNkZWZpbmUgWEVOUEZfY3B1X29mZmxpbmUgICA1Nworc3RydWN0IHhlbnBmX2NwdV9v
bCB7CisgICAgdWludDMyX3QgY3B1aWQ7Cit9OwordHlwZWRlZiBzdHJ1Y3QgeGVucGZfY3B1X29s
IHhlbnBmX2NwdV9vbF90OworREVGSU5FX0dVRVNUX0hBTkRMRV9TVFJVQ1QoeGVucGZfY3B1X29s
X3QpOworCiBzdHJ1Y3QgeGVuX3BsYXRmb3JtX29wIHsKIAl1aW50MzJfdCBjbWQ7CiAJdWludDMy
X3QgaW50ZXJmYWNlX3ZlcnNpb247IC8qIFhFTlBGX0lOVEVSRkFDRV9WRVJTSU9OICovCkBAIC0z
MTIsOSArMzM3LDEyIEBAIHN0cnVjdCB4ZW5fcGxhdGZvcm1fb3AgewogCQlzdHJ1Y3QgeGVucGZf
Y2hhbmdlX2ZyZXEgICAgICAgY2hhbmdlX2ZyZXE7CiAJCXN0cnVjdCB4ZW5wZl9nZXRpZGxldGlt
ZSAgICAgICBnZXRpZGxldGltZTsKIAkJc3RydWN0IHhlbnBmX3NldF9wcm9jZXNzb3JfcG1pbmZv
IHNldF9wbWluZm87CisJCXN0cnVjdCB4ZW5wZl9wY3B1aW5mbyAgICAgICAgICBwY3B1X2luZm87
CisJCXN0cnVjdCB4ZW5wZl9jcHVfb2wgICAgICAgICAgICBjcHVfb2w7CiAJCXVpbnQ4X3QgICAg
ICAgICAgICAgICAgICAgICAgICBwYWRbMTI4XTsKIAl9IHU7CiB9OwordHlwZWRlZiBzdHJ1Y3Qg
eGVuX3BsYXRmb3JtX29wIHhlbl9wbGF0Zm9ybV9vcF90OwogREVGSU5FX0dVRVNUX0hBTkRMRV9T
VFJVQ1QoeGVuX3BsYXRmb3JtX29wX3QpOwogCiAjZW5kaWYgLyogX19YRU5fUFVCTElDX1BMQVRG
T1JNX0hfXyAqLwpkaWZmIC0tZ2l0IGEvaW5jbHVkZS94ZW4vaW50ZXJmYWNlL3hlbi5oIGIvaW5j
bHVkZS94ZW4vaW50ZXJmYWNlL3hlbi5oCmluZGV4IDZhNmU5MTQuLjVhOTFjNjYgMTAwNjQ0Ci0t
LSBhL2luY2x1ZGUveGVuL2ludGVyZmFjZS94ZW4uaAorKysgYi9pbmNsdWRlL3hlbi9pbnRlcmZh
Y2UveGVuLmgKQEAgLTgwLDYgKzgwLDcgQEAKICNkZWZpbmUgVklSUV9DT05TT0xFICAgIDIgIC8q
IChET00wKSBCeXRlcyByZWNlaXZlZCBvbiBlbWVyZ2VuY3kgY29uc29sZS4gKi8KICNkZWZpbmUg
VklSUV9ET01fRVhDICAgIDMgIC8qIChET00wKSBFeGNlcHRpb25hbCBldmVudCBmb3Igc29tZSBk
b21haW4uICAgKi8KICNkZWZpbmUgVklSUV9ERUJVR0dFUiAgIDYgIC8qIChET00wKSBBIGRvbWFp
biBoYXMgcGF1c2VkIGZvciBkZWJ1Z2dpbmcuICAgKi8KKyNkZWZpbmUgVklSUV9QQ1BVX1NUQVRF
IDkgIC8qIChET00wKSBQQ1BVIHN0YXRlIGNoYW5nZWQgICAgICAgICAgICAgICAgICAgKi8KIAog
LyogQXJjaGl0ZWN0dXJlLXNwZWNpZmljIFZJUlEgZGVmaW5pdGlvbnMuICovCiAjZGVmaW5lIFZJ
UlFfQVJDSF8wICAgIDE2CmRpZmYgLS1naXQgYS9pbmNsdWRlL3hlbi9wY3B1LmggYi9pbmNsdWRl
L3hlbi9wY3B1LmgKbmV3IGZpbGUgbW9kZSAxMDA2NDQKaW5kZXggMDAwMDAwMC4uN2U4ZjlkMQot
LS0gL2Rldi9udWxsCisrKyBiL2luY2x1ZGUveGVuL3BjcHUuaApAQCAtMCwwICsxLDMyIEBACisj
aWZuZGVmIF9YRU5fUENQVV9ICisjZGVmaW5lIF9YRU5fUENQVV9ICisKKyNpbmNsdWRlIDx4ZW4v
aW50ZXJmYWNlL3BsYXRmb3JtLmg+CisjaW5jbHVkZSA8bGludXgvc3lzZGV2Lmg+CisKK2V4dGVy
biBpbnQgeGVuX3BjcHVfaG90cGx1ZyhpbnQgdHlwZSwgdWludDMyX3QgYXBpY19pZCk7CisjZGVm
aW5lIFhFTl9QQ1BVX09OTElORSAgICAgMHgwMQorI2RlZmluZSBYRU5fUENQVV9PRkZMSU5FICAg
IDB4MDIKKyNkZWZpbmUgWEVOX1BDUFVfQUREICAgICAgICAweDA0CisjZGVmaW5lIFhFTl9QQ1BV
X1JFTU9WRSAgICAgMHgwOAorCitzdHJ1Y3QgcGNwdSB7CisJc3RydWN0IGxpc3RfaGVhZCBwY3B1
X2xpc3Q7CisJc3RydWN0IHN5c19kZXZpY2Ugc3lzZGV2OworCXVpbnQzMl90IHhlbl9pZDsKKwl1
aW50MzJfdCBhcGljX2lkOworCXVpbnQzMl90IGFjcGlfaWQ7CisJdWludDMyX3QgZmxhZ3M7Cit9
OworCitzdGF0aWMgaW5saW5lIGludCB4ZW5fcGNwdV9vbmxpbmUodWludDMyX3QgZmxhZ3MpCit7
CisJcmV0dXJuICEhKGZsYWdzICYgWEVOX1BDUFVfRkxBR1NfT05MSU5FKTsKK30KKworZXh0ZXJu
IGludCByZWdpc3Rlcl94ZW5fcGNwdV9ub3RpZmllcihzdHJ1Y3Qgbm90aWZpZXJfYmxvY2sgKm5i
KTsKKworZXh0ZXJuIHZvaWQgdW5yZWdpc3Rlcl94ZW5fcGNwdV9ub3RpZmllcihzdHJ1Y3Qgbm90
aWZpZXJfYmxvY2sgKm5iKTsKKworZXh0ZXJuIGludCB4ZW5fcGNwdV9pbmRleCh1aW50MzJfdCBh
Y3BpX2lkLCBpbnQgaXNfYWNwaWlkKTsKKyNlbmRpZgotLSAKMS42LjUuNgoK

--_002_DE8DF0795D48FD4CA783C40EC829233596CCSHSMSX101ccrcorpint_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--_002_DE8DF0795D48FD4CA783C40EC829233596CCSHSMSX101ccrcorpint_--


From xen-devel-bounces@lists.xensource.com Fri Dec 23 10:25:54 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 Dec 2011 10:25:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Re2Jn-00065e-B9; Fri, 23 Dec 2011 10:25:39 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1Re2Jl-00064h-KR
	for xen-devel@lists.xensource.com; Fri, 23 Dec 2011 10:25:38 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1324635892!57839106!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDMwMDk1NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16650 invoked from network); 23 Dec 2011 10:24:53 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-9.tower-27.messagelabs.com with SMTP;
	23 Dec 2011 10:24:53 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga102.fm.intel.com with ESMTP; 23 Dec 2011 02:25:29 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208,223";a="99638305"
Received: from pgsmsx601.gar.corp.intel.com ([10.221.43.69])
	by fmsmga001.fm.intel.com with ESMTP; 23 Dec 2011 02:25:27 -0800
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	pgsmsx601.gar.corp.intel.com (10.221.43.69) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Fri, 23 Dec 2011 18:25:26 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.38]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.199]) with mapi id
	14.01.0355.002; Fri, 23 Dec 2011 18:25:24 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: "konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
Thread-Topic: [PATCH 03/10] Xen: Export host physical CPU information to dom0
Thread-Index: AczBXS3xndCwjv8tTQC62IA/xc76Ag==
Date: Fri, 23 Dec 2011 10:25:23 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC829233596CC@SHSMSX101.ccr.corp.intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
Content-Type: multipart/mixed;
	boundary="_002_DE8DF0795D48FD4CA783C40EC829233596CCSHSMSX101ccrcorpint_"
MIME-Version: 1.0
Cc: "Brown, Len" <len.brown@intel.com>,
	"jeremy.fitzhardinge@citrix.com" <jeremy.fitzhardinge@citrix.com>,
	"Jiang, Yunhong" <yunhong.jiang@intel.com>, "Shan, 
	Haitao" <haitao.shan@intel.com>,
	Kernel development list <linux-kernel@vger.kernel.org>, "Zhao,
	Yakui" <yakui.zhao@intel.com>, "Luck, Tony" <tony.luck@intel.com>, "Kleen,
	Andi" <andi.kleen@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: [Xen-devel] [PATCH 03/10] Xen: Export host physical CPU information
	to dom0
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--_002_DE8DF0795D48FD4CA783C40EC829233596CCSHSMSX101ccrcorpint_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

>From 04151aa18b48a452cc9d0696f36aa96c690ca011 Mon Sep 17 00:00:00 2001
From: Liu Jinsong <jinsong.liu@intel.com>
Date: Thu, 8 Dec 2011 22:28:07 +0800
Subject: [PATCH 03/10] Xen: Export host physical CPU information to dom0

This patch rebased from Jeremy's pvops commit
3b34cd19627c6e191b15fd6cb59f997b8db21e19 and
68320323a51c2378aca433c76157d9e66104ff1e

This patch expose host's physical CPU information to dom0 in sysfs, so
that dom0's management tools can control the physical CPU if needed.

It also provides interface in sysfs to logical online/offline a physical CP=
U.

Notice: The information in dom0 is synced with xen hypervisor asynchronousl=
y.

Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
Signed-off-by: Jiang, Yunhong <yunhong.jiang@intel.com>
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
---
 drivers/xen/Makefile             |    2 +-
 drivers/xen/pcpu.c               |  452 ++++++++++++++++++++++++++++++++++=
++++
 include/xen/interface/platform.h |   28 +++
 include/xen/interface/xen.h      |    1 +
 include/xen/pcpu.h               |   32 +++
 5 files changed, 514 insertions(+), 1 deletions(-)
 create mode 100644 drivers/xen/pcpu.c
 create mode 100644 include/xen/pcpu.h

diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
index 405cce9..aedaf48 100644
--- a/drivers/xen/Makefile
+++ b/drivers/xen/Makefile
@@ -1,4 +1,4 @@
-obj-y	+=3D grant-table.o features.o events.o manage.o balloon.o
+obj-y	+=3D grant-table.o features.o events.o manage.o balloon.o pcpu.o
 obj-y	+=3D xenbus/
=20
 nostackp :=3D $(call cc-option, -fno-stack-protector)
diff --git a/drivers/xen/pcpu.c b/drivers/xen/pcpu.c
new file mode 100644
index 0000000..6d1a770
--- /dev/null
+++ b/drivers/xen/pcpu.c
@@ -0,0 +1,452 @@
+/*
+ * pcpu.c - management physical cpu in dom0 environment
+ */
+#include <linux/interrupt.h>
+#include <linux/spinlock.h>
+#include <asm/xen/hypervisor.h>
+#include <asm/xen/hypercall.h>
+#include <linux/cpu.h>
+#include <xen/xenbus.h>
+#include <xen/pcpu.h>
+#include <xen/events.h>
+#include <xen/acpi.h>
+
+static struct sysdev_class xen_pcpu_sysdev_class =3D {
+	.name =3D "xen_pcpu",
+};
+
+static DEFINE_MUTEX(xen_pcpu_lock);
+static RAW_NOTIFIER_HEAD(xen_pcpu_chain);
+
+/* No need for irq disable since hotplug notify is in workqueue context */
+#define get_pcpu_lock() mutex_lock(&xen_pcpu_lock);
+#define put_pcpu_lock() mutex_unlock(&xen_pcpu_lock);
+
+struct xen_pcpus {
+	struct list_head list;
+	int present;
+};
+static struct xen_pcpus xen_pcpus;
+
+int register_xen_pcpu_notifier(struct notifier_block *nb)
+{
+	int ret;
+
+	/* All refer to the chain notifier is protected by the pcpu_lock */
+	get_pcpu_lock();
+	ret =3D raw_notifier_chain_register(&xen_pcpu_chain, nb);
+	put_pcpu_lock();
+	return ret;
+}
+EXPORT_SYMBOL_GPL(register_xen_pcpu_notifier);
+
+void unregister_xen_pcpu_notifier(struct notifier_block *nb)
+{
+	get_pcpu_lock();
+	raw_notifier_chain_unregister(&xen_pcpu_chain, nb);
+	put_pcpu_lock();
+}
+EXPORT_SYMBOL_GPL(unregister_xen_pcpu_notifier);
+
+static int xen_pcpu_down(uint32_t xen_id)
+{
+	int ret;
+	xen_platform_op_t op =3D {
+		.cmd			=3D XENPF_cpu_offline,
+		.interface_version	=3D XENPF_INTERFACE_VERSION,
+		.u.cpu_ol.cpuid	=3D xen_id,
+	};
+
+	ret =3D HYPERVISOR_dom0_op(&op);
+	return ret;
+}
+
+static int xen_pcpu_up(uint32_t xen_id)
+{
+	int ret;
+	xen_platform_op_t op =3D {
+		.cmd			=3D XENPF_cpu_online,
+		.interface_version	=3D XENPF_INTERFACE_VERSION,
+		.u.cpu_ol.cpuid	=3D xen_id,
+	};
+
+	ret =3D HYPERVISOR_dom0_op(&op);
+	return ret;
+}
+
+static ssize_t show_online(struct sys_device *dev,
+			struct sysdev_attribute *attr,
+			char *buf)
+{
+	struct pcpu *cpu =3D container_of(dev, struct pcpu, sysdev);
+
+	return sprintf(buf, "%u\n", !!(cpu->flags & XEN_PCPU_FLAGS_ONLINE));
+}
+
+static ssize_t __ref store_online(struct sys_device *dev,
+				  struct sysdev_attribute *attr,
+				  const char *buf, size_t count)
+{
+	struct pcpu *cpu =3D container_of(dev, struct pcpu, sysdev);
+	ssize_t ret;
+
+	switch (buf[0]) {
+	case '0':
+		ret =3D xen_pcpu_down(cpu->xen_id);
+		break;
+	case '1':
+		ret =3D xen_pcpu_up(cpu->xen_id);
+		break;
+	default:
+		ret =3D -EINVAL;
+	}
+
+	if (ret >=3D 0)
+		ret =3D count;
+	return ret;
+}
+
+static SYSDEV_ATTR(online, 0644, show_online, store_online);
+
+static ssize_t show_apicid(struct sys_device *dev,
+			struct sysdev_attribute *attr,
+			char *buf)
+{
+	struct pcpu *cpu =3D container_of(dev, struct pcpu, sysdev);
+
+	return sprintf(buf, "%u\n", cpu->apic_id);
+}
+
+static ssize_t show_acpiid(struct sys_device *dev,
+			struct sysdev_attribute *attr,
+			char *buf)
+{
+	struct pcpu *cpu =3D container_of(dev, struct pcpu, sysdev);
+
+	return sprintf(buf, "%u\n", cpu->acpi_id);
+}
+static SYSDEV_ATTR(apic_id, 0444, show_apicid, NULL);
+static SYSDEV_ATTR(acpi_id, 0444, show_acpiid, NULL);
+
+static int xen_pcpu_free(struct pcpu *pcpu)
+{
+	if (!pcpu)
+		return 0;
+
+	sysdev_remove_file(&pcpu->sysdev, &attr_online);
+	sysdev_unregister(&pcpu->sysdev);
+	list_del(&pcpu->pcpu_list);
+	kfree(pcpu);
+
+	return 0;
+}
+
+static inline int same_pcpu(struct xenpf_pcpuinfo *info,
+			    struct pcpu *pcpu)
+{
+	return (pcpu->apic_id =3D=3D info->apic_id) &&
+		(pcpu->xen_id =3D=3D info->xen_cpuid);
+}
+
+/*
+ * Return 1 if online status changed
+ */
+static int xen_pcpu_online_check(struct xenpf_pcpuinfo *info,
+				 struct pcpu *pcpu)
+{
+	int result =3D 0;
+
+	if (info->xen_cpuid !=3D pcpu->xen_id)
+		return 0;
+
+	if (xen_pcpu_online(info->flags) && !xen_pcpu_online(pcpu->flags)) {
+		/* the pcpu is onlined */
+		pcpu->flags |=3D XEN_PCPU_FLAGS_ONLINE;
+		kobject_uevent(&pcpu->sysdev.kobj, KOBJ_ONLINE);
+		raw_notifier_call_chain(&xen_pcpu_chain,
+			XEN_PCPU_ONLINE, (void *)(long)pcpu->xen_id);
+		result =3D 1;
+	} else if (!xen_pcpu_online(info->flags) &&
+		 xen_pcpu_online(pcpu->flags))  {
+		/* The pcpu is offlined now */
+		pcpu->flags &=3D ~XEN_PCPU_FLAGS_ONLINE;
+		kobject_uevent(&pcpu->sysdev.kobj, KOBJ_OFFLINE);
+		raw_notifier_call_chain(&xen_pcpu_chain,
+			XEN_PCPU_OFFLINE, (void *)(long)pcpu->xen_id);
+		result =3D 1;
+	}
+
+	return result;
+}
+
+static int pcpu_sysdev_init(struct pcpu *cpu)
+{
+	int error;
+
+	error =3D sysdev_register(&cpu->sysdev);
+	if (error) {
+		printk(KERN_WARNING "xen_pcpu_add: Failed to register pcpu\n");
+		kfree(cpu);
+		return -1;
+	}
+	sysdev_create_file(&cpu->sysdev, &attr_online);
+	sysdev_create_file(&cpu->sysdev, &attr_apic_id);
+	sysdev_create_file(&cpu->sysdev, &attr_acpi_id);
+	return 0;
+}
+
+static struct pcpu *get_pcpu(int xen_id)
+{
+	struct pcpu *pcpu =3D NULL;
+
+	list_for_each_entry(pcpu, &xen_pcpus.list, pcpu_list) {
+		if (pcpu->xen_id =3D=3D xen_id)
+			return pcpu;
+	}
+	return NULL;
+}
+
+static struct pcpu *init_pcpu(struct xenpf_pcpuinfo *info)
+{
+	struct pcpu *pcpu;
+
+	if (info->flags & XEN_PCPU_FLAGS_INVALID)
+		return NULL;
+
+	/* The PCPU is just added */
+	pcpu =3D kzalloc(sizeof(struct pcpu), GFP_KERNEL);
+	if (!pcpu)
+		return NULL;
+
+	INIT_LIST_HEAD(&pcpu->pcpu_list);
+	pcpu->xen_id =3D info->xen_cpuid;
+	pcpu->apic_id =3D info->apic_id;
+	pcpu->acpi_id =3D info->acpi_id;
+	pcpu->flags =3D info->flags;
+
+	pcpu->sysdev.cls =3D &xen_pcpu_sysdev_class;
+	pcpu->sysdev.id =3D info->xen_cpuid;
+
+	if (pcpu_sysdev_init(pcpu)) {
+		kfree(pcpu);
+		return NULL;
+	}
+
+	list_add_tail(&pcpu->pcpu_list, &xen_pcpus.list);
+	raw_notifier_call_chain(&xen_pcpu_chain,
+				XEN_PCPU_ADD,
+				(void *)(long)pcpu->xen_id);
+	return pcpu;
+}
+
+#define PCPU_NO_CHANGE			0
+#define PCPU_ADDED			1
+#define PCPU_ONLINE_OFFLINE		2
+#define PCPU_REMOVED			3
+/*
+ * Caller should hold the pcpu lock
+ * < 0: Something wrong
+ * 0: No changes
+ * > 0: State changed
+ */
+static struct pcpu *_sync_pcpu(int cpu_num, int *max_id, int *result)
+{
+	struct pcpu *pcpu =3D NULL;
+	struct xenpf_pcpuinfo *info;
+	xen_platform_op_t op =3D {
+		.cmd            =3D XENPF_get_cpuinfo,
+		.interface_version  =3D XENPF_INTERFACE_VERSION,
+	};
+	int ret;
+
+	*result =3D -1;
+
+	info =3D &op.u.pcpu_info;
+	info->xen_cpuid =3D cpu_num;
+
+	ret =3D HYPERVISOR_dom0_op(&op);
+	if (ret)
+		return NULL;
+
+	if (max_id)
+		*max_id =3D op.u.pcpu_info.max_present;
+
+	pcpu =3D get_pcpu(cpu_num);
+
+	if (info->flags & XEN_PCPU_FLAGS_INVALID) {
+		/* The pcpu has been removed */
+		*result =3D PCPU_NO_CHANGE;
+		if (pcpu) {
+			raw_notifier_call_chain(&xen_pcpu_chain,
+			  XEN_PCPU_REMOVE,
+			  (void *)(long)pcpu->xen_id);
+			xen_pcpu_free(pcpu);
+			*result =3D PCPU_REMOVED;
+		}
+		return NULL;
+	}
+
+
+	if (!pcpu) {
+		*result =3D PCPU_ADDED;
+		pcpu =3D init_pcpu(info);
+		if (pcpu =3D=3D NULL) {
+			printk(KERN_WARNING "Failed to init pcpu %x\n",
+			  info->xen_cpuid);
+			  *result =3D -1;
+		}
+	} else {
+		*result =3D PCPU_NO_CHANGE;
+		/*
+		 * Old PCPU is replaced with a new pcpu, this means
+		 * several virq is missed, will it happen?
+		 */
+		if (!same_pcpu(info, pcpu)) {
+			printk(KERN_WARNING "Pcpu %x changed!\n",
+			  pcpu->xen_id);
+			pcpu->apic_id =3D info->apic_id;
+			pcpu->acpi_id =3D info->acpi_id;
+		}
+		if (xen_pcpu_online_check(info, pcpu))
+			*result =3D PCPU_ONLINE_OFFLINE;
+	}
+	return pcpu;
+}
+
+int xen_pcpu_index(uint32_t id, int is_acpiid)
+{
+	int cpu_num =3D 0, max_id =3D 0, ret;
+	xen_platform_op_t op =3D {
+		.cmd            =3D XENPF_get_cpuinfo,
+		.interface_version  =3D XENPF_INTERFACE_VERSION,
+	};
+	struct xenpf_pcpuinfo *info =3D &op.u.pcpu_info;
+
+	info->xen_cpuid =3D 0;
+	ret =3D HYPERVISOR_dom0_op(&op);
+	if (ret)
+		return -1;
+	max_id =3D op.u.pcpu_info.max_present;
+
+	while ((cpu_num <=3D max_id)) {
+		info->xen_cpuid =3D cpu_num;
+		ret =3D HYPERVISOR_dom0_op(&op);
+		if (ret)
+			continue;
+
+		if (op.u.pcpu_info.max_present > max_id)
+			max_id =3D op.u.pcpu_info.max_present;
+		if (id =3D=3D (is_acpiid ? info->acpi_id : info->apic_id))
+			return cpu_num;
+		cpu_num++;
+	}
+
+    return -1;
+}
+EXPORT_SYMBOL(xen_pcpu_index);
+
+/*
+ * Sync dom0's pcpu information with xen hypervisor's
+ */
+static int xen_sync_pcpus(void)
+{
+	/*
+	 * Boot cpu always have cpu_id 0 in xen
+	 */
+	int cpu_num =3D 0, max_id =3D 0, result =3D 0, present =3D 0;
+	struct list_head *elem, *tmp;
+	struct pcpu *pcpu;
+
+	get_pcpu_lock();
+
+	while ((result >=3D 0) && (cpu_num <=3D max_id)) {
+		pcpu =3D _sync_pcpu(cpu_num, &max_id, &result);
+
+		printk(KERN_DEBUG "sync cpu %x get result %x max_id %x\n",
+			cpu_num, result, max_id);
+
+		switch (result)	{
+		case PCPU_NO_CHANGE:
+			if (pcpu)
+				present++;
+			break;
+		case PCPU_ADDED:
+		case PCPU_ONLINE_OFFLINE:
+			present++;
+		case PCPU_REMOVED:
+			break;
+		default:
+			printk(KERN_WARNING "Failed to sync pcpu %x\n",
+			  cpu_num);
+			break;
+
+		}
+		cpu_num++;
+	}
+
+	if (result < 0) {
+		list_for_each_safe(elem, tmp, &xen_pcpus.list) {
+			pcpu =3D list_entry(elem, struct pcpu, pcpu_list);
+			xen_pcpu_free(pcpu);
+		}
+		present =3D 0;
+	}
+
+	xen_pcpus.present =3D present;
+
+	put_pcpu_lock();
+
+	return 0;
+}
+
+static void xen_pcpu_dpc(struct work_struct *work)
+{
+	if (xen_sync_pcpus() < 0)
+		printk(KERN_WARNING
+			"xen_pcpu_dpc: Failed to sync pcpu information\n");
+}
+static DECLARE_WORK(xen_pcpu_work, xen_pcpu_dpc);
+
+int xen_pcpu_hotplug(int type, uint32_t apic_id)
+{
+	schedule_work(&xen_pcpu_work);
+
+	return 0;
+}
+EXPORT_SYMBOL(xen_pcpu_hotplug);
+
+static irqreturn_t xen_pcpu_interrupt(int irq, void *dev_id)
+{
+	schedule_work(&xen_pcpu_work);
+	return IRQ_HANDLED;
+}
+
+static int __init xen_pcpu_init(void)
+{
+	int err;
+
+	if (!xen_initial_domain())
+		return 0;
+
+	err =3D sysdev_class_register(&xen_pcpu_sysdev_class);
+	if (err) {
+		printk(KERN_WARNING
+			"xen_pcpu_init: register xen_pcpu sysdev Failed!\n");
+		return err;
+	}
+
+	INIT_LIST_HEAD(&xen_pcpus.list);
+	xen_pcpus.present =3D 0;
+
+	xen_sync_pcpus();
+	if (xen_pcpus.present > 0)
+		err =3D bind_virq_to_irqhandler(VIRQ_PCPU_STATE,
+			0, xen_pcpu_interrupt, 0, "pcpu", NULL);
+	if (err < 0)
+		printk(KERN_WARNING "xen_pcpu_init: "
+			"Failed to bind pcpu_state virq\n"
+			"You will lost latest information! \n");
+	return err;
+}
+
+arch_initcall(xen_pcpu_init);
diff --git a/include/xen/interface/platform.h b/include/xen/interface/platf=
orm.h
index c168468..47ffe16 100644
--- a/include/xen/interface/platform.h
+++ b/include/xen/interface/platform.h
@@ -297,6 +297,31 @@ struct xenpf_set_processor_pminfo {
 };
 DEFINE_GUEST_HANDLE_STRUCT(xenpf_set_processor_pminfo);
=20
+#define XENPF_get_cpuinfo 55
+struct xenpf_pcpuinfo {
+	/* IN */
+	uint32_t xen_cpuid;
+	/* OUT */
+	/* The maxium cpu_id that is present */
+	uint32_t max_present;
+#define XEN_PCPU_FLAGS_ONLINE   1
+	/* Correponding xen_cpuid is not present*/
+#define XEN_PCPU_FLAGS_INVALID  2
+	uint32_t flags;
+	uint32_t apic_id;
+	uint32_t acpi_id;
+};
+typedef struct xenpf_pcpuinfo xenpf_pcpuinfo_t;
+DEFINE_GUEST_HANDLE_STRUCT(xenpf_pcpuinfo_t);
+
+#define XENPF_cpu_online    56
+#define XENPF_cpu_offline   57
+struct xenpf_cpu_ol {
+    uint32_t cpuid;
+};
+typedef struct xenpf_cpu_ol xenpf_cpu_ol_t;
+DEFINE_GUEST_HANDLE_STRUCT(xenpf_cpu_ol_t);
+
 struct xen_platform_op {
 	uint32_t cmd;
 	uint32_t interface_version; /* XENPF_INTERFACE_VERSION */
@@ -312,9 +337,12 @@ struct xen_platform_op {
 		struct xenpf_change_freq       change_freq;
 		struct xenpf_getidletime       getidletime;
 		struct xenpf_set_processor_pminfo set_pminfo;
+		struct xenpf_pcpuinfo          pcpu_info;
+		struct xenpf_cpu_ol            cpu_ol;
 		uint8_t                        pad[128];
 	} u;
 };
+typedef struct xen_platform_op xen_platform_op_t;
 DEFINE_GUEST_HANDLE_STRUCT(xen_platform_op_t);
=20
 #endif /* __XEN_PUBLIC_PLATFORM_H__ */
diff --git a/include/xen/interface/xen.h b/include/xen/interface/xen.h
index 6a6e914..5a91c66 100644
--- a/include/xen/interface/xen.h
+++ b/include/xen/interface/xen.h
@@ -80,6 +80,7 @@
 #define VIRQ_CONSOLE    2  /* (DOM0) Bytes received on emergency console. =
*/
 #define VIRQ_DOM_EXC    3  /* (DOM0) Exceptional event for some domain.   =
*/
 #define VIRQ_DEBUGGER   6  /* (DOM0) A domain has paused for debugging.   =
*/
+#define VIRQ_PCPU_STATE 9  /* (DOM0) PCPU state changed                   =
*/
=20
 /* Architecture-specific VIRQ definitions. */
 #define VIRQ_ARCH_0    16
diff --git a/include/xen/pcpu.h b/include/xen/pcpu.h
new file mode 100644
index 0000000..7e8f9d1
--- /dev/null
+++ b/include/xen/pcpu.h
@@ -0,0 +1,32 @@
+#ifndef _XEN_PCPU_H
+#define _XEN_PCPU_H
+
+#include <xen/interface/platform.h>
+#include <linux/sysdev.h>
+
+extern int xen_pcpu_hotplug(int type, uint32_t apic_id);
+#define XEN_PCPU_ONLINE     0x01
+#define XEN_PCPU_OFFLINE    0x02
+#define XEN_PCPU_ADD        0x04
+#define XEN_PCPU_REMOVE     0x08
+
+struct pcpu {
+	struct list_head pcpu_list;
+	struct sys_device sysdev;
+	uint32_t xen_id;
+	uint32_t apic_id;
+	uint32_t acpi_id;
+	uint32_t flags;
+};
+
+static inline int xen_pcpu_online(uint32_t flags)
+{
+	return !!(flags & XEN_PCPU_FLAGS_ONLINE);
+}
+
+extern int register_xen_pcpu_notifier(struct notifier_block *nb);
+
+extern void unregister_xen_pcpu_notifier(struct notifier_block *nb);
+
+extern int xen_pcpu_index(uint32_t acpi_id, int is_acpiid);
+#endif
--=20
1.6.5.6

--_002_DE8DF0795D48FD4CA783C40EC829233596CCSHSMSX101ccrcorpint_
Content-Type: application/octet-stream;
	name="0003-Xen-Export-host-physical-CPU-information-to-dom0.patch"
Content-Description: 0003-Xen-Export-host-physical-CPU-information-to-dom0.patch
Content-Disposition: attachment;
	filename="0003-Xen-Export-host-physical-CPU-information-to-dom0.patch";
	size=15036; creation-date="Wed, 14 Dec 2011 15:20:15 GMT";
	modification-date="Wed, 14 Dec 2011 15:03:34 GMT"
Content-Transfer-Encoding: base64

RnJvbSAwNDE1MWFhMThiNDhhNDUyY2M5ZDA2OTZmMzZhYTk2YzY5MGNhMDExIE1vbiBTZXAgMTcg
MDA6MDA6MDAgMjAwMQpGcm9tOiBMaXUgSmluc29uZyA8amluc29uZy5saXVAaW50ZWwuY29tPgpE
YXRlOiBUaHUsIDggRGVjIDIwMTEgMjI6Mjg6MDcgKzA4MDAKU3ViamVjdDogW1BBVENIIDAzLzEw
XSBYZW46IEV4cG9ydCBob3N0IHBoeXNpY2FsIENQVSBpbmZvcm1hdGlvbiB0byBkb20wCgpUaGlz
IHBhdGNoIHJlYmFzZWQgZnJvbSBKZXJlbXkncyBwdm9wcyBjb21taXQKM2IzNGNkMTk2MjdjNmUx
OTFiMTVmZDZjYjU5Zjk5N2I4ZGIyMWUxOSBhbmQKNjgzMjAzMjNhNTFjMjM3OGFjYTQzM2M3NjE1
N2Q5ZTY2MTA0ZmYxZQoKVGhpcyBwYXRjaCBleHBvc2UgaG9zdCdzIHBoeXNpY2FsIENQVSBpbmZv
cm1hdGlvbiB0byBkb20wIGluIHN5c2ZzLCBzbwp0aGF0IGRvbTAncyBtYW5hZ2VtZW50IHRvb2xz
IGNhbiBjb250cm9sIHRoZSBwaHlzaWNhbCBDUFUgaWYgbmVlZGVkLgoKSXQgYWxzbyBwcm92aWRl
cyBpbnRlcmZhY2UgaW4gc3lzZnMgdG8gbG9naWNhbCBvbmxpbmUvb2ZmbGluZSBhIHBoeXNpY2Fs
IENQVS4KCk5vdGljZTogVGhlIGluZm9ybWF0aW9uIGluIGRvbTAgaXMgc3luY2VkIHdpdGggeGVu
IGh5cGVydmlzb3IgYXN5bmNocm9ub3VzbHkuCgpTaWduZWQtb2ZmLWJ5OiBMaXUsIEppbnNvbmcg
PGppbnNvbmcubGl1QGludGVsLmNvbT4KU2lnbmVkLW9mZi1ieTogSmlhbmcsIFl1bmhvbmcgPHl1
bmhvbmcuamlhbmdAaW50ZWwuY29tPgpTaWduZWQtb2ZmLWJ5OiBKZXJlbXkgRml0emhhcmRpbmdl
IDxqZXJlbXkuZml0emhhcmRpbmdlQGNpdHJpeC5jb20+Ci0tLQogZHJpdmVycy94ZW4vTWFrZWZp
bGUgICAgICAgICAgICAgfCAgICAyICstCiBkcml2ZXJzL3hlbi9wY3B1LmMgICAgICAgICAgICAg
ICB8ICA0NTIgKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysKIGluY2x1ZGUv
eGVuL2ludGVyZmFjZS9wbGF0Zm9ybS5oIHwgICAyOCArKysKIGluY2x1ZGUveGVuL2ludGVyZmFj
ZS94ZW4uaCAgICAgIHwgICAgMSArCiBpbmNsdWRlL3hlbi9wY3B1LmggICAgICAgICAgICAgICB8
ICAgMzIgKysrCiA1IGZpbGVzIGNoYW5nZWQsIDUxNCBpbnNlcnRpb25zKCspLCAxIGRlbGV0aW9u
cygtKQogY3JlYXRlIG1vZGUgMTAwNjQ0IGRyaXZlcnMveGVuL3BjcHUuYwogY3JlYXRlIG1vZGUg
MTAwNjQ0IGluY2x1ZGUveGVuL3BjcHUuaAoKZGlmZiAtLWdpdCBhL2RyaXZlcnMveGVuL01ha2Vm
aWxlIGIvZHJpdmVycy94ZW4vTWFrZWZpbGUKaW5kZXggNDA1Y2NlOS4uYWVkYWY0OCAxMDA2NDQK
LS0tIGEvZHJpdmVycy94ZW4vTWFrZWZpbGUKKysrIGIvZHJpdmVycy94ZW4vTWFrZWZpbGUKQEAg
LTEsNCArMSw0IEBACi1vYmoteQkrPSBncmFudC10YWJsZS5vIGZlYXR1cmVzLm8gZXZlbnRzLm8g
bWFuYWdlLm8gYmFsbG9vbi5vCitvYmoteQkrPSBncmFudC10YWJsZS5vIGZlYXR1cmVzLm8gZXZl
bnRzLm8gbWFuYWdlLm8gYmFsbG9vbi5vIHBjcHUubwogb2JqLXkJKz0geGVuYnVzLwogCiBub3N0
YWNrcCA6PSAkKGNhbGwgY2Mtb3B0aW9uLCAtZm5vLXN0YWNrLXByb3RlY3RvcikKZGlmZiAtLWdp
dCBhL2RyaXZlcnMveGVuL3BjcHUuYyBiL2RyaXZlcnMveGVuL3BjcHUuYwpuZXcgZmlsZSBtb2Rl
IDEwMDY0NAppbmRleCAwMDAwMDAwLi42ZDFhNzcwCi0tLSAvZGV2L251bGwKKysrIGIvZHJpdmVy
cy94ZW4vcGNwdS5jCkBAIC0wLDAgKzEsNDUyIEBACisvKgorICogcGNwdS5jIC0gbWFuYWdlbWVu
dCBwaHlzaWNhbCBjcHUgaW4gZG9tMCBlbnZpcm9ubWVudAorICovCisjaW5jbHVkZSA8bGludXgv
aW50ZXJydXB0Lmg+CisjaW5jbHVkZSA8bGludXgvc3BpbmxvY2suaD4KKyNpbmNsdWRlIDxhc20v
eGVuL2h5cGVydmlzb3IuaD4KKyNpbmNsdWRlIDxhc20veGVuL2h5cGVyY2FsbC5oPgorI2luY2x1
ZGUgPGxpbnV4L2NwdS5oPgorI2luY2x1ZGUgPHhlbi94ZW5idXMuaD4KKyNpbmNsdWRlIDx4ZW4v
cGNwdS5oPgorI2luY2x1ZGUgPHhlbi9ldmVudHMuaD4KKyNpbmNsdWRlIDx4ZW4vYWNwaS5oPgor
CitzdGF0aWMgc3RydWN0IHN5c2Rldl9jbGFzcyB4ZW5fcGNwdV9zeXNkZXZfY2xhc3MgPSB7CisJ
Lm5hbWUgPSAieGVuX3BjcHUiLAorfTsKKworc3RhdGljIERFRklORV9NVVRFWCh4ZW5fcGNwdV9s
b2NrKTsKK3N0YXRpYyBSQVdfTk9USUZJRVJfSEVBRCh4ZW5fcGNwdV9jaGFpbik7CisKKy8qIE5v
IG5lZWQgZm9yIGlycSBkaXNhYmxlIHNpbmNlIGhvdHBsdWcgbm90aWZ5IGlzIGluIHdvcmtxdWV1
ZSBjb250ZXh0ICovCisjZGVmaW5lIGdldF9wY3B1X2xvY2soKSBtdXRleF9sb2NrKCZ4ZW5fcGNw
dV9sb2NrKTsKKyNkZWZpbmUgcHV0X3BjcHVfbG9jaygpIG11dGV4X3VubG9jaygmeGVuX3BjcHVf
bG9jayk7CisKK3N0cnVjdCB4ZW5fcGNwdXMgeworCXN0cnVjdCBsaXN0X2hlYWQgbGlzdDsKKwlp
bnQgcHJlc2VudDsKK307CitzdGF0aWMgc3RydWN0IHhlbl9wY3B1cyB4ZW5fcGNwdXM7CisKK2lu
dCByZWdpc3Rlcl94ZW5fcGNwdV9ub3RpZmllcihzdHJ1Y3Qgbm90aWZpZXJfYmxvY2sgKm5iKQor
eworCWludCByZXQ7CisKKwkvKiBBbGwgcmVmZXIgdG8gdGhlIGNoYWluIG5vdGlmaWVyIGlzIHBy
b3RlY3RlZCBieSB0aGUgcGNwdV9sb2NrICovCisJZ2V0X3BjcHVfbG9jaygpOworCXJldCA9IHJh
d19ub3RpZmllcl9jaGFpbl9yZWdpc3RlcigmeGVuX3BjcHVfY2hhaW4sIG5iKTsKKwlwdXRfcGNw
dV9sb2NrKCk7CisJcmV0dXJuIHJldDsKK30KK0VYUE9SVF9TWU1CT0xfR1BMKHJlZ2lzdGVyX3hl
bl9wY3B1X25vdGlmaWVyKTsKKwordm9pZCB1bnJlZ2lzdGVyX3hlbl9wY3B1X25vdGlmaWVyKHN0
cnVjdCBub3RpZmllcl9ibG9jayAqbmIpCit7CisJZ2V0X3BjcHVfbG9jaygpOworCXJhd19ub3Rp
Zmllcl9jaGFpbl91bnJlZ2lzdGVyKCZ4ZW5fcGNwdV9jaGFpbiwgbmIpOworCXB1dF9wY3B1X2xv
Y2soKTsKK30KK0VYUE9SVF9TWU1CT0xfR1BMKHVucmVnaXN0ZXJfeGVuX3BjcHVfbm90aWZpZXIp
OworCitzdGF0aWMgaW50IHhlbl9wY3B1X2Rvd24odWludDMyX3QgeGVuX2lkKQoreworCWludCBy
ZXQ7CisJeGVuX3BsYXRmb3JtX29wX3Qgb3AgPSB7CisJCS5jbWQJCQk9IFhFTlBGX2NwdV9vZmZs
aW5lLAorCQkuaW50ZXJmYWNlX3ZlcnNpb24JPSBYRU5QRl9JTlRFUkZBQ0VfVkVSU0lPTiwKKwkJ
LnUuY3B1X29sLmNwdWlkCT0geGVuX2lkLAorCX07CisKKwlyZXQgPSBIWVBFUlZJU09SX2RvbTBf
b3AoJm9wKTsKKwlyZXR1cm4gcmV0OworfQorCitzdGF0aWMgaW50IHhlbl9wY3B1X3VwKHVpbnQz
Ml90IHhlbl9pZCkKK3sKKwlpbnQgcmV0OworCXhlbl9wbGF0Zm9ybV9vcF90IG9wID0geworCQku
Y21kCQkJPSBYRU5QRl9jcHVfb25saW5lLAorCQkuaW50ZXJmYWNlX3ZlcnNpb24JPSBYRU5QRl9J
TlRFUkZBQ0VfVkVSU0lPTiwKKwkJLnUuY3B1X29sLmNwdWlkCT0geGVuX2lkLAorCX07CisKKwly
ZXQgPSBIWVBFUlZJU09SX2RvbTBfb3AoJm9wKTsKKwlyZXR1cm4gcmV0OworfQorCitzdGF0aWMg
c3NpemVfdCBzaG93X29ubGluZShzdHJ1Y3Qgc3lzX2RldmljZSAqZGV2LAorCQkJc3RydWN0IHN5
c2Rldl9hdHRyaWJ1dGUgKmF0dHIsCisJCQljaGFyICpidWYpCit7CisJc3RydWN0IHBjcHUgKmNw
dSA9IGNvbnRhaW5lcl9vZihkZXYsIHN0cnVjdCBwY3B1LCBzeXNkZXYpOworCisJcmV0dXJuIHNw
cmludGYoYnVmLCAiJXVcbiIsICEhKGNwdS0+ZmxhZ3MgJiBYRU5fUENQVV9GTEFHU19PTkxJTkUp
KTsKK30KKworc3RhdGljIHNzaXplX3QgX19yZWYgc3RvcmVfb25saW5lKHN0cnVjdCBzeXNfZGV2
aWNlICpkZXYsCisJCQkJICBzdHJ1Y3Qgc3lzZGV2X2F0dHJpYnV0ZSAqYXR0ciwKKwkJCQkgIGNv
bnN0IGNoYXIgKmJ1Ziwgc2l6ZV90IGNvdW50KQoreworCXN0cnVjdCBwY3B1ICpjcHUgPSBjb250
YWluZXJfb2YoZGV2LCBzdHJ1Y3QgcGNwdSwgc3lzZGV2KTsKKwlzc2l6ZV90IHJldDsKKworCXN3
aXRjaCAoYnVmWzBdKSB7CisJY2FzZSAnMCc6CisJCXJldCA9IHhlbl9wY3B1X2Rvd24oY3B1LT54
ZW5faWQpOworCQlicmVhazsKKwljYXNlICcxJzoKKwkJcmV0ID0geGVuX3BjcHVfdXAoY3B1LT54
ZW5faWQpOworCQlicmVhazsKKwlkZWZhdWx0OgorCQlyZXQgPSAtRUlOVkFMOworCX0KKworCWlm
IChyZXQgPj0gMCkKKwkJcmV0ID0gY291bnQ7CisJcmV0dXJuIHJldDsKK30KKworc3RhdGljIFNZ
U0RFVl9BVFRSKG9ubGluZSwgMDY0NCwgc2hvd19vbmxpbmUsIHN0b3JlX29ubGluZSk7CisKK3N0
YXRpYyBzc2l6ZV90IHNob3dfYXBpY2lkKHN0cnVjdCBzeXNfZGV2aWNlICpkZXYsCisJCQlzdHJ1
Y3Qgc3lzZGV2X2F0dHJpYnV0ZSAqYXR0ciwKKwkJCWNoYXIgKmJ1ZikKK3sKKwlzdHJ1Y3QgcGNw
dSAqY3B1ID0gY29udGFpbmVyX29mKGRldiwgc3RydWN0IHBjcHUsIHN5c2Rldik7CisKKwlyZXR1
cm4gc3ByaW50ZihidWYsICIldVxuIiwgY3B1LT5hcGljX2lkKTsKK30KKworc3RhdGljIHNzaXpl
X3Qgc2hvd19hY3BpaWQoc3RydWN0IHN5c19kZXZpY2UgKmRldiwKKwkJCXN0cnVjdCBzeXNkZXZf
YXR0cmlidXRlICphdHRyLAorCQkJY2hhciAqYnVmKQoreworCXN0cnVjdCBwY3B1ICpjcHUgPSBj
b250YWluZXJfb2YoZGV2LCBzdHJ1Y3QgcGNwdSwgc3lzZGV2KTsKKworCXJldHVybiBzcHJpbnRm
KGJ1ZiwgIiV1XG4iLCBjcHUtPmFjcGlfaWQpOworfQorc3RhdGljIFNZU0RFVl9BVFRSKGFwaWNf
aWQsIDA0NDQsIHNob3dfYXBpY2lkLCBOVUxMKTsKK3N0YXRpYyBTWVNERVZfQVRUUihhY3BpX2lk
LCAwNDQ0LCBzaG93X2FjcGlpZCwgTlVMTCk7CisKK3N0YXRpYyBpbnQgeGVuX3BjcHVfZnJlZShz
dHJ1Y3QgcGNwdSAqcGNwdSkKK3sKKwlpZiAoIXBjcHUpCisJCXJldHVybiAwOworCisJc3lzZGV2
X3JlbW92ZV9maWxlKCZwY3B1LT5zeXNkZXYsICZhdHRyX29ubGluZSk7CisJc3lzZGV2X3VucmVn
aXN0ZXIoJnBjcHUtPnN5c2Rldik7CisJbGlzdF9kZWwoJnBjcHUtPnBjcHVfbGlzdCk7CisJa2Zy
ZWUocGNwdSk7CisKKwlyZXR1cm4gMDsKK30KKworc3RhdGljIGlubGluZSBpbnQgc2FtZV9wY3B1
KHN0cnVjdCB4ZW5wZl9wY3B1aW5mbyAqaW5mbywKKwkJCSAgICBzdHJ1Y3QgcGNwdSAqcGNwdSkK
K3sKKwlyZXR1cm4gKHBjcHUtPmFwaWNfaWQgPT0gaW5mby0+YXBpY19pZCkgJiYKKwkJKHBjcHUt
Pnhlbl9pZCA9PSBpbmZvLT54ZW5fY3B1aWQpOworfQorCisvKgorICogUmV0dXJuIDEgaWYgb25s
aW5lIHN0YXR1cyBjaGFuZ2VkCisgKi8KK3N0YXRpYyBpbnQgeGVuX3BjcHVfb25saW5lX2NoZWNr
KHN0cnVjdCB4ZW5wZl9wY3B1aW5mbyAqaW5mbywKKwkJCQkgc3RydWN0IHBjcHUgKnBjcHUpCit7
CisJaW50IHJlc3VsdCA9IDA7CisKKwlpZiAoaW5mby0+eGVuX2NwdWlkICE9IHBjcHUtPnhlbl9p
ZCkKKwkJcmV0dXJuIDA7CisKKwlpZiAoeGVuX3BjcHVfb25saW5lKGluZm8tPmZsYWdzKSAmJiAh
eGVuX3BjcHVfb25saW5lKHBjcHUtPmZsYWdzKSkgeworCQkvKiB0aGUgcGNwdSBpcyBvbmxpbmVk
ICovCisJCXBjcHUtPmZsYWdzIHw9IFhFTl9QQ1BVX0ZMQUdTX09OTElORTsKKwkJa29iamVjdF91
ZXZlbnQoJnBjcHUtPnN5c2Rldi5rb2JqLCBLT0JKX09OTElORSk7CisJCXJhd19ub3RpZmllcl9j
YWxsX2NoYWluKCZ4ZW5fcGNwdV9jaGFpbiwKKwkJCVhFTl9QQ1BVX09OTElORSwgKHZvaWQgKiko
bG9uZylwY3B1LT54ZW5faWQpOworCQlyZXN1bHQgPSAxOworCX0gZWxzZSBpZiAoIXhlbl9wY3B1
X29ubGluZShpbmZvLT5mbGFncykgJiYKKwkJIHhlbl9wY3B1X29ubGluZShwY3B1LT5mbGFncykp
ICB7CisJCS8qIFRoZSBwY3B1IGlzIG9mZmxpbmVkIG5vdyAqLworCQlwY3B1LT5mbGFncyAmPSB+
WEVOX1BDUFVfRkxBR1NfT05MSU5FOworCQlrb2JqZWN0X3VldmVudCgmcGNwdS0+c3lzZGV2Lmtv
YmosIEtPQkpfT0ZGTElORSk7CisJCXJhd19ub3RpZmllcl9jYWxsX2NoYWluKCZ4ZW5fcGNwdV9j
aGFpbiwKKwkJCVhFTl9QQ1BVX09GRkxJTkUsICh2b2lkICopKGxvbmcpcGNwdS0+eGVuX2lkKTsK
KwkJcmVzdWx0ID0gMTsKKwl9CisKKwlyZXR1cm4gcmVzdWx0OworfQorCitzdGF0aWMgaW50IHBj
cHVfc3lzZGV2X2luaXQoc3RydWN0IHBjcHUgKmNwdSkKK3sKKwlpbnQgZXJyb3I7CisKKwllcnJv
ciA9IHN5c2Rldl9yZWdpc3RlcigmY3B1LT5zeXNkZXYpOworCWlmIChlcnJvcikgeworCQlwcmlu
dGsoS0VSTl9XQVJOSU5HICJ4ZW5fcGNwdV9hZGQ6IEZhaWxlZCB0byByZWdpc3RlciBwY3B1XG4i
KTsKKwkJa2ZyZWUoY3B1KTsKKwkJcmV0dXJuIC0xOworCX0KKwlzeXNkZXZfY3JlYXRlX2ZpbGUo
JmNwdS0+c3lzZGV2LCAmYXR0cl9vbmxpbmUpOworCXN5c2Rldl9jcmVhdGVfZmlsZSgmY3B1LT5z
eXNkZXYsICZhdHRyX2FwaWNfaWQpOworCXN5c2Rldl9jcmVhdGVfZmlsZSgmY3B1LT5zeXNkZXYs
ICZhdHRyX2FjcGlfaWQpOworCXJldHVybiAwOworfQorCitzdGF0aWMgc3RydWN0IHBjcHUgKmdl
dF9wY3B1KGludCB4ZW5faWQpCit7CisJc3RydWN0IHBjcHUgKnBjcHUgPSBOVUxMOworCisJbGlz
dF9mb3JfZWFjaF9lbnRyeShwY3B1LCAmeGVuX3BjcHVzLmxpc3QsIHBjcHVfbGlzdCkgeworCQlp
ZiAocGNwdS0+eGVuX2lkID09IHhlbl9pZCkKKwkJCXJldHVybiBwY3B1OworCX0KKwlyZXR1cm4g
TlVMTDsKK30KKworc3RhdGljIHN0cnVjdCBwY3B1ICppbml0X3BjcHUoc3RydWN0IHhlbnBmX3Bj
cHVpbmZvICppbmZvKQoreworCXN0cnVjdCBwY3B1ICpwY3B1OworCisJaWYgKGluZm8tPmZsYWdz
ICYgWEVOX1BDUFVfRkxBR1NfSU5WQUxJRCkKKwkJcmV0dXJuIE5VTEw7CisKKwkvKiBUaGUgUENQ
VSBpcyBqdXN0IGFkZGVkICovCisJcGNwdSA9IGt6YWxsb2Moc2l6ZW9mKHN0cnVjdCBwY3B1KSwg
R0ZQX0tFUk5FTCk7CisJaWYgKCFwY3B1KQorCQlyZXR1cm4gTlVMTDsKKworCUlOSVRfTElTVF9I
RUFEKCZwY3B1LT5wY3B1X2xpc3QpOworCXBjcHUtPnhlbl9pZCA9IGluZm8tPnhlbl9jcHVpZDsK
KwlwY3B1LT5hcGljX2lkID0gaW5mby0+YXBpY19pZDsKKwlwY3B1LT5hY3BpX2lkID0gaW5mby0+
YWNwaV9pZDsKKwlwY3B1LT5mbGFncyA9IGluZm8tPmZsYWdzOworCisJcGNwdS0+c3lzZGV2LmNs
cyA9ICZ4ZW5fcGNwdV9zeXNkZXZfY2xhc3M7CisJcGNwdS0+c3lzZGV2LmlkID0gaW5mby0+eGVu
X2NwdWlkOworCisJaWYgKHBjcHVfc3lzZGV2X2luaXQocGNwdSkpIHsKKwkJa2ZyZWUocGNwdSk7
CisJCXJldHVybiBOVUxMOworCX0KKworCWxpc3RfYWRkX3RhaWwoJnBjcHUtPnBjcHVfbGlzdCwg
Jnhlbl9wY3B1cy5saXN0KTsKKwlyYXdfbm90aWZpZXJfY2FsbF9jaGFpbigmeGVuX3BjcHVfY2hh
aW4sCisJCQkJWEVOX1BDUFVfQURELAorCQkJCSh2b2lkICopKGxvbmcpcGNwdS0+eGVuX2lkKTsK
KwlyZXR1cm4gcGNwdTsKK30KKworI2RlZmluZSBQQ1BVX05PX0NIQU5HRQkJCTAKKyNkZWZpbmUg
UENQVV9BRERFRAkJCTEKKyNkZWZpbmUgUENQVV9PTkxJTkVfT0ZGTElORQkJMgorI2RlZmluZSBQ
Q1BVX1JFTU9WRUQJCQkzCisvKgorICogQ2FsbGVyIHNob3VsZCBob2xkIHRoZSBwY3B1IGxvY2sK
KyAqIDwgMDogU29tZXRoaW5nIHdyb25nCisgKiAwOiBObyBjaGFuZ2VzCisgKiA+IDA6IFN0YXRl
IGNoYW5nZWQKKyAqLworc3RhdGljIHN0cnVjdCBwY3B1ICpfc3luY19wY3B1KGludCBjcHVfbnVt
LCBpbnQgKm1heF9pZCwgaW50ICpyZXN1bHQpCit7CisJc3RydWN0IHBjcHUgKnBjcHUgPSBOVUxM
OworCXN0cnVjdCB4ZW5wZl9wY3B1aW5mbyAqaW5mbzsKKwl4ZW5fcGxhdGZvcm1fb3BfdCBvcCA9
IHsKKwkJLmNtZCAgICAgICAgICAgID0gWEVOUEZfZ2V0X2NwdWluZm8sCisJCS5pbnRlcmZhY2Vf
dmVyc2lvbiAgPSBYRU5QRl9JTlRFUkZBQ0VfVkVSU0lPTiwKKwl9OworCWludCByZXQ7CisKKwkq
cmVzdWx0ID0gLTE7CisKKwlpbmZvID0gJm9wLnUucGNwdV9pbmZvOworCWluZm8tPnhlbl9jcHVp
ZCA9IGNwdV9udW07CisKKwlyZXQgPSBIWVBFUlZJU09SX2RvbTBfb3AoJm9wKTsKKwlpZiAocmV0
KQorCQlyZXR1cm4gTlVMTDsKKworCWlmIChtYXhfaWQpCisJCSptYXhfaWQgPSBvcC51LnBjcHVf
aW5mby5tYXhfcHJlc2VudDsKKworCXBjcHUgPSBnZXRfcGNwdShjcHVfbnVtKTsKKworCWlmIChp
bmZvLT5mbGFncyAmIFhFTl9QQ1BVX0ZMQUdTX0lOVkFMSUQpIHsKKwkJLyogVGhlIHBjcHUgaGFz
IGJlZW4gcmVtb3ZlZCAqLworCQkqcmVzdWx0ID0gUENQVV9OT19DSEFOR0U7CisJCWlmIChwY3B1
KSB7CisJCQlyYXdfbm90aWZpZXJfY2FsbF9jaGFpbigmeGVuX3BjcHVfY2hhaW4sCisJCQkgIFhF
Tl9QQ1BVX1JFTU9WRSwKKwkJCSAgKHZvaWQgKikobG9uZylwY3B1LT54ZW5faWQpOworCQkJeGVu
X3BjcHVfZnJlZShwY3B1KTsKKwkJCSpyZXN1bHQgPSBQQ1BVX1JFTU9WRUQ7CisJCX0KKwkJcmV0
dXJuIE5VTEw7CisJfQorCisKKwlpZiAoIXBjcHUpIHsKKwkJKnJlc3VsdCA9IFBDUFVfQURERUQ7
CisJCXBjcHUgPSBpbml0X3BjcHUoaW5mbyk7CisJCWlmIChwY3B1ID09IE5VTEwpIHsKKwkJCXBy
aW50ayhLRVJOX1dBUk5JTkcgIkZhaWxlZCB0byBpbml0IHBjcHUgJXhcbiIsCisJCQkgIGluZm8t
Pnhlbl9jcHVpZCk7CisJCQkgICpyZXN1bHQgPSAtMTsKKwkJfQorCX0gZWxzZSB7CisJCSpyZXN1
bHQgPSBQQ1BVX05PX0NIQU5HRTsKKwkJLyoKKwkJICogT2xkIFBDUFUgaXMgcmVwbGFjZWQgd2l0
aCBhIG5ldyBwY3B1LCB0aGlzIG1lYW5zCisJCSAqIHNldmVyYWwgdmlycSBpcyBtaXNzZWQsIHdp
bGwgaXQgaGFwcGVuPworCQkgKi8KKwkJaWYgKCFzYW1lX3BjcHUoaW5mbywgcGNwdSkpIHsKKwkJ
CXByaW50ayhLRVJOX1dBUk5JTkcgIlBjcHUgJXggY2hhbmdlZCFcbiIsCisJCQkgIHBjcHUtPnhl
bl9pZCk7CisJCQlwY3B1LT5hcGljX2lkID0gaW5mby0+YXBpY19pZDsKKwkJCXBjcHUtPmFjcGlf
aWQgPSBpbmZvLT5hY3BpX2lkOworCQl9CisJCWlmICh4ZW5fcGNwdV9vbmxpbmVfY2hlY2soaW5m
bywgcGNwdSkpCisJCQkqcmVzdWx0ID0gUENQVV9PTkxJTkVfT0ZGTElORTsKKwl9CisJcmV0dXJu
IHBjcHU7Cit9CisKK2ludCB4ZW5fcGNwdV9pbmRleCh1aW50MzJfdCBpZCwgaW50IGlzX2FjcGlp
ZCkKK3sKKwlpbnQgY3B1X251bSA9IDAsIG1heF9pZCA9IDAsIHJldDsKKwl4ZW5fcGxhdGZvcm1f
b3BfdCBvcCA9IHsKKwkJLmNtZCAgICAgICAgICAgID0gWEVOUEZfZ2V0X2NwdWluZm8sCisJCS5p
bnRlcmZhY2VfdmVyc2lvbiAgPSBYRU5QRl9JTlRFUkZBQ0VfVkVSU0lPTiwKKwl9OworCXN0cnVj
dCB4ZW5wZl9wY3B1aW5mbyAqaW5mbyA9ICZvcC51LnBjcHVfaW5mbzsKKworCWluZm8tPnhlbl9j
cHVpZCA9IDA7CisJcmV0ID0gSFlQRVJWSVNPUl9kb20wX29wKCZvcCk7CisJaWYgKHJldCkKKwkJ
cmV0dXJuIC0xOworCW1heF9pZCA9IG9wLnUucGNwdV9pbmZvLm1heF9wcmVzZW50OworCisJd2hp
bGUgKChjcHVfbnVtIDw9IG1heF9pZCkpIHsKKwkJaW5mby0+eGVuX2NwdWlkID0gY3B1X251bTsK
KwkJcmV0ID0gSFlQRVJWSVNPUl9kb20wX29wKCZvcCk7CisJCWlmIChyZXQpCisJCQljb250aW51
ZTsKKworCQlpZiAob3AudS5wY3B1X2luZm8ubWF4X3ByZXNlbnQgPiBtYXhfaWQpCisJCQltYXhf
aWQgPSBvcC51LnBjcHVfaW5mby5tYXhfcHJlc2VudDsKKwkJaWYgKGlkID09IChpc19hY3BpaWQg
PyBpbmZvLT5hY3BpX2lkIDogaW5mby0+YXBpY19pZCkpCisJCQlyZXR1cm4gY3B1X251bTsKKwkJ
Y3B1X251bSsrOworCX0KKworICAgIHJldHVybiAtMTsKK30KK0VYUE9SVF9TWU1CT0woeGVuX3Bj
cHVfaW5kZXgpOworCisvKgorICogU3luYyBkb20wJ3MgcGNwdSBpbmZvcm1hdGlvbiB3aXRoIHhl
biBoeXBlcnZpc29yJ3MKKyAqLworc3RhdGljIGludCB4ZW5fc3luY19wY3B1cyh2b2lkKQorewor
CS8qCisJICogQm9vdCBjcHUgYWx3YXlzIGhhdmUgY3B1X2lkIDAgaW4geGVuCisJICovCisJaW50
IGNwdV9udW0gPSAwLCBtYXhfaWQgPSAwLCByZXN1bHQgPSAwLCBwcmVzZW50ID0gMDsKKwlzdHJ1
Y3QgbGlzdF9oZWFkICplbGVtLCAqdG1wOworCXN0cnVjdCBwY3B1ICpwY3B1OworCisJZ2V0X3Bj
cHVfbG9jaygpOworCisJd2hpbGUgKChyZXN1bHQgPj0gMCkgJiYgKGNwdV9udW0gPD0gbWF4X2lk
KSkgeworCQlwY3B1ID0gX3N5bmNfcGNwdShjcHVfbnVtLCAmbWF4X2lkLCAmcmVzdWx0KTsKKwor
CQlwcmludGsoS0VSTl9ERUJVRyAic3luYyBjcHUgJXggZ2V0IHJlc3VsdCAleCBtYXhfaWQgJXhc
biIsCisJCQljcHVfbnVtLCByZXN1bHQsIG1heF9pZCk7CisKKwkJc3dpdGNoIChyZXN1bHQpCXsK
KwkJY2FzZSBQQ1BVX05PX0NIQU5HRToKKwkJCWlmIChwY3B1KQorCQkJCXByZXNlbnQrKzsKKwkJ
CWJyZWFrOworCQljYXNlIFBDUFVfQURERUQ6CisJCWNhc2UgUENQVV9PTkxJTkVfT0ZGTElORToK
KwkJCXByZXNlbnQrKzsKKwkJY2FzZSBQQ1BVX1JFTU9WRUQ6CisJCQlicmVhazsKKwkJZGVmYXVs
dDoKKwkJCXByaW50ayhLRVJOX1dBUk5JTkcgIkZhaWxlZCB0byBzeW5jIHBjcHUgJXhcbiIsCisJ
CQkgIGNwdV9udW0pOworCQkJYnJlYWs7CisKKwkJfQorCQljcHVfbnVtKys7CisJfQorCisJaWYg
KHJlc3VsdCA8IDApIHsKKwkJbGlzdF9mb3JfZWFjaF9zYWZlKGVsZW0sIHRtcCwgJnhlbl9wY3B1
cy5saXN0KSB7CisJCQlwY3B1ID0gbGlzdF9lbnRyeShlbGVtLCBzdHJ1Y3QgcGNwdSwgcGNwdV9s
aXN0KTsKKwkJCXhlbl9wY3B1X2ZyZWUocGNwdSk7CisJCX0KKwkJcHJlc2VudCA9IDA7CisJfQor
CisJeGVuX3BjcHVzLnByZXNlbnQgPSBwcmVzZW50OworCisJcHV0X3BjcHVfbG9jaygpOworCisJ
cmV0dXJuIDA7Cit9CisKK3N0YXRpYyB2b2lkIHhlbl9wY3B1X2RwYyhzdHJ1Y3Qgd29ya19zdHJ1
Y3QgKndvcmspCit7CisJaWYgKHhlbl9zeW5jX3BjcHVzKCkgPCAwKQorCQlwcmludGsoS0VSTl9X
QVJOSU5HCisJCQkieGVuX3BjcHVfZHBjOiBGYWlsZWQgdG8gc3luYyBwY3B1IGluZm9ybWF0aW9u
XG4iKTsKK30KK3N0YXRpYyBERUNMQVJFX1dPUksoeGVuX3BjcHVfd29yaywgeGVuX3BjcHVfZHBj
KTsKKworaW50IHhlbl9wY3B1X2hvdHBsdWcoaW50IHR5cGUsIHVpbnQzMl90IGFwaWNfaWQpCit7
CisJc2NoZWR1bGVfd29yaygmeGVuX3BjcHVfd29yayk7CisKKwlyZXR1cm4gMDsKK30KK0VYUE9S
VF9TWU1CT0woeGVuX3BjcHVfaG90cGx1Zyk7CisKK3N0YXRpYyBpcnFyZXR1cm5fdCB4ZW5fcGNw
dV9pbnRlcnJ1cHQoaW50IGlycSwgdm9pZCAqZGV2X2lkKQoreworCXNjaGVkdWxlX3dvcmsoJnhl
bl9wY3B1X3dvcmspOworCXJldHVybiBJUlFfSEFORExFRDsKK30KKworc3RhdGljIGludCBfX2lu
aXQgeGVuX3BjcHVfaW5pdCh2b2lkKQoreworCWludCBlcnI7CisKKwlpZiAoIXhlbl9pbml0aWFs
X2RvbWFpbigpKQorCQlyZXR1cm4gMDsKKworCWVyciA9IHN5c2Rldl9jbGFzc19yZWdpc3Rlcigm
eGVuX3BjcHVfc3lzZGV2X2NsYXNzKTsKKwlpZiAoZXJyKSB7CisJCXByaW50ayhLRVJOX1dBUk5J
TkcKKwkJCSJ4ZW5fcGNwdV9pbml0OiByZWdpc3RlciB4ZW5fcGNwdSBzeXNkZXYgRmFpbGVkIVxu
Iik7CisJCXJldHVybiBlcnI7CisJfQorCisJSU5JVF9MSVNUX0hFQUQoJnhlbl9wY3B1cy5saXN0
KTsKKwl4ZW5fcGNwdXMucHJlc2VudCA9IDA7CisKKwl4ZW5fc3luY19wY3B1cygpOworCWlmICh4
ZW5fcGNwdXMucHJlc2VudCA+IDApCisJCWVyciA9IGJpbmRfdmlycV90b19pcnFoYW5kbGVyKFZJ
UlFfUENQVV9TVEFURSwKKwkJCTAsIHhlbl9wY3B1X2ludGVycnVwdCwgMCwgInBjcHUiLCBOVUxM
KTsKKwlpZiAoZXJyIDwgMCkKKwkJcHJpbnRrKEtFUk5fV0FSTklORyAieGVuX3BjcHVfaW5pdDog
IgorCQkJIkZhaWxlZCB0byBiaW5kIHBjcHVfc3RhdGUgdmlycVxuIgorCQkJIllvdSB3aWxsIGxv
c3QgbGF0ZXN0IGluZm9ybWF0aW9uISBcbiIpOworCXJldHVybiBlcnI7Cit9CisKK2FyY2hfaW5p
dGNhbGwoeGVuX3BjcHVfaW5pdCk7CmRpZmYgLS1naXQgYS9pbmNsdWRlL3hlbi9pbnRlcmZhY2Uv
cGxhdGZvcm0uaCBiL2luY2x1ZGUveGVuL2ludGVyZmFjZS9wbGF0Zm9ybS5oCmluZGV4IGMxNjg0
NjguLjQ3ZmZlMTYgMTAwNjQ0Ci0tLSBhL2luY2x1ZGUveGVuL2ludGVyZmFjZS9wbGF0Zm9ybS5o
CisrKyBiL2luY2x1ZGUveGVuL2ludGVyZmFjZS9wbGF0Zm9ybS5oCkBAIC0yOTcsNiArMjk3LDMx
IEBAIHN0cnVjdCB4ZW5wZl9zZXRfcHJvY2Vzc29yX3BtaW5mbyB7CiB9OwogREVGSU5FX0dVRVNU
X0hBTkRMRV9TVFJVQ1QoeGVucGZfc2V0X3Byb2Nlc3Nvcl9wbWluZm8pOwogCisjZGVmaW5lIFhF
TlBGX2dldF9jcHVpbmZvIDU1CitzdHJ1Y3QgeGVucGZfcGNwdWluZm8geworCS8qIElOICovCisJ
dWludDMyX3QgeGVuX2NwdWlkOworCS8qIE9VVCAqLworCS8qIFRoZSBtYXhpdW0gY3B1X2lkIHRo
YXQgaXMgcHJlc2VudCAqLworCXVpbnQzMl90IG1heF9wcmVzZW50OworI2RlZmluZSBYRU5fUENQ
VV9GTEFHU19PTkxJTkUgICAxCisJLyogQ29ycmVwb25kaW5nIHhlbl9jcHVpZCBpcyBub3QgcHJl
c2VudCovCisjZGVmaW5lIFhFTl9QQ1BVX0ZMQUdTX0lOVkFMSUQgIDIKKwl1aW50MzJfdCBmbGFn
czsKKwl1aW50MzJfdCBhcGljX2lkOworCXVpbnQzMl90IGFjcGlfaWQ7Cit9OwordHlwZWRlZiBz
dHJ1Y3QgeGVucGZfcGNwdWluZm8geGVucGZfcGNwdWluZm9fdDsKK0RFRklORV9HVUVTVF9IQU5E
TEVfU1RSVUNUKHhlbnBmX3BjcHVpbmZvX3QpOworCisjZGVmaW5lIFhFTlBGX2NwdV9vbmxpbmUg
ICAgNTYKKyNkZWZpbmUgWEVOUEZfY3B1X29mZmxpbmUgICA1Nworc3RydWN0IHhlbnBmX2NwdV9v
bCB7CisgICAgdWludDMyX3QgY3B1aWQ7Cit9OwordHlwZWRlZiBzdHJ1Y3QgeGVucGZfY3B1X29s
IHhlbnBmX2NwdV9vbF90OworREVGSU5FX0dVRVNUX0hBTkRMRV9TVFJVQ1QoeGVucGZfY3B1X29s
X3QpOworCiBzdHJ1Y3QgeGVuX3BsYXRmb3JtX29wIHsKIAl1aW50MzJfdCBjbWQ7CiAJdWludDMy
X3QgaW50ZXJmYWNlX3ZlcnNpb247IC8qIFhFTlBGX0lOVEVSRkFDRV9WRVJTSU9OICovCkBAIC0z
MTIsOSArMzM3LDEyIEBAIHN0cnVjdCB4ZW5fcGxhdGZvcm1fb3AgewogCQlzdHJ1Y3QgeGVucGZf
Y2hhbmdlX2ZyZXEgICAgICAgY2hhbmdlX2ZyZXE7CiAJCXN0cnVjdCB4ZW5wZl9nZXRpZGxldGlt
ZSAgICAgICBnZXRpZGxldGltZTsKIAkJc3RydWN0IHhlbnBmX3NldF9wcm9jZXNzb3JfcG1pbmZv
IHNldF9wbWluZm87CisJCXN0cnVjdCB4ZW5wZl9wY3B1aW5mbyAgICAgICAgICBwY3B1X2luZm87
CisJCXN0cnVjdCB4ZW5wZl9jcHVfb2wgICAgICAgICAgICBjcHVfb2w7CiAJCXVpbnQ4X3QgICAg
ICAgICAgICAgICAgICAgICAgICBwYWRbMTI4XTsKIAl9IHU7CiB9OwordHlwZWRlZiBzdHJ1Y3Qg
eGVuX3BsYXRmb3JtX29wIHhlbl9wbGF0Zm9ybV9vcF90OwogREVGSU5FX0dVRVNUX0hBTkRMRV9T
VFJVQ1QoeGVuX3BsYXRmb3JtX29wX3QpOwogCiAjZW5kaWYgLyogX19YRU5fUFVCTElDX1BMQVRG
T1JNX0hfXyAqLwpkaWZmIC0tZ2l0IGEvaW5jbHVkZS94ZW4vaW50ZXJmYWNlL3hlbi5oIGIvaW5j
bHVkZS94ZW4vaW50ZXJmYWNlL3hlbi5oCmluZGV4IDZhNmU5MTQuLjVhOTFjNjYgMTAwNjQ0Ci0t
LSBhL2luY2x1ZGUveGVuL2ludGVyZmFjZS94ZW4uaAorKysgYi9pbmNsdWRlL3hlbi9pbnRlcmZh
Y2UveGVuLmgKQEAgLTgwLDYgKzgwLDcgQEAKICNkZWZpbmUgVklSUV9DT05TT0xFICAgIDIgIC8q
IChET00wKSBCeXRlcyByZWNlaXZlZCBvbiBlbWVyZ2VuY3kgY29uc29sZS4gKi8KICNkZWZpbmUg
VklSUV9ET01fRVhDICAgIDMgIC8qIChET00wKSBFeGNlcHRpb25hbCBldmVudCBmb3Igc29tZSBk
b21haW4uICAgKi8KICNkZWZpbmUgVklSUV9ERUJVR0dFUiAgIDYgIC8qIChET00wKSBBIGRvbWFp
biBoYXMgcGF1c2VkIGZvciBkZWJ1Z2dpbmcuICAgKi8KKyNkZWZpbmUgVklSUV9QQ1BVX1NUQVRF
IDkgIC8qIChET00wKSBQQ1BVIHN0YXRlIGNoYW5nZWQgICAgICAgICAgICAgICAgICAgKi8KIAog
LyogQXJjaGl0ZWN0dXJlLXNwZWNpZmljIFZJUlEgZGVmaW5pdGlvbnMuICovCiAjZGVmaW5lIFZJ
UlFfQVJDSF8wICAgIDE2CmRpZmYgLS1naXQgYS9pbmNsdWRlL3hlbi9wY3B1LmggYi9pbmNsdWRl
L3hlbi9wY3B1LmgKbmV3IGZpbGUgbW9kZSAxMDA2NDQKaW5kZXggMDAwMDAwMC4uN2U4ZjlkMQot
LS0gL2Rldi9udWxsCisrKyBiL2luY2x1ZGUveGVuL3BjcHUuaApAQCAtMCwwICsxLDMyIEBACisj
aWZuZGVmIF9YRU5fUENQVV9ICisjZGVmaW5lIF9YRU5fUENQVV9ICisKKyNpbmNsdWRlIDx4ZW4v
aW50ZXJmYWNlL3BsYXRmb3JtLmg+CisjaW5jbHVkZSA8bGludXgvc3lzZGV2Lmg+CisKK2V4dGVy
biBpbnQgeGVuX3BjcHVfaG90cGx1ZyhpbnQgdHlwZSwgdWludDMyX3QgYXBpY19pZCk7CisjZGVm
aW5lIFhFTl9QQ1BVX09OTElORSAgICAgMHgwMQorI2RlZmluZSBYRU5fUENQVV9PRkZMSU5FICAg
IDB4MDIKKyNkZWZpbmUgWEVOX1BDUFVfQUREICAgICAgICAweDA0CisjZGVmaW5lIFhFTl9QQ1BV
X1JFTU9WRSAgICAgMHgwOAorCitzdHJ1Y3QgcGNwdSB7CisJc3RydWN0IGxpc3RfaGVhZCBwY3B1
X2xpc3Q7CisJc3RydWN0IHN5c19kZXZpY2Ugc3lzZGV2OworCXVpbnQzMl90IHhlbl9pZDsKKwl1
aW50MzJfdCBhcGljX2lkOworCXVpbnQzMl90IGFjcGlfaWQ7CisJdWludDMyX3QgZmxhZ3M7Cit9
OworCitzdGF0aWMgaW5saW5lIGludCB4ZW5fcGNwdV9vbmxpbmUodWludDMyX3QgZmxhZ3MpCit7
CisJcmV0dXJuICEhKGZsYWdzICYgWEVOX1BDUFVfRkxBR1NfT05MSU5FKTsKK30KKworZXh0ZXJu
IGludCByZWdpc3Rlcl94ZW5fcGNwdV9ub3RpZmllcihzdHJ1Y3Qgbm90aWZpZXJfYmxvY2sgKm5i
KTsKKworZXh0ZXJuIHZvaWQgdW5yZWdpc3Rlcl94ZW5fcGNwdV9ub3RpZmllcihzdHJ1Y3Qgbm90
aWZpZXJfYmxvY2sgKm5iKTsKKworZXh0ZXJuIGludCB4ZW5fcGNwdV9pbmRleCh1aW50MzJfdCBh
Y3BpX2lkLCBpbnQgaXNfYWNwaWlkKTsKKyNlbmRpZgotLSAKMS42LjUuNgoK

--_002_DE8DF0795D48FD4CA783C40EC829233596CCSHSMSX101ccrcorpint_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--_002_DE8DF0795D48FD4CA783C40EC829233596CCSHSMSX101ccrcorpint_--


From xen-devel-bounces@lists.xensource.com Fri Dec 23 10:27:13 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 Dec 2011 10:27:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Re2L8-0006IR-6j; Fri, 23 Dec 2011 10:27:02 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1Re2L7-0006Ht-1c
	for xen-devel@lists.xensource.com; Fri, 23 Dec 2011 10:27:01 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1324636013!3090315!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDMwMDk1NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6717 invoked from network); 23 Dec 2011 10:26:53 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-9.tower-21.messagelabs.com with SMTP;
	23 Dec 2011 10:26:53 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga102.fm.intel.com with ESMTP; 23 Dec 2011 02:26:52 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208,223";a="99638597"
Received: from pgsmsx602.gar.corp.intel.com ([10.221.43.81])
	by fmsmga001.fm.intel.com with ESMTP; 23 Dec 2011 02:26:51 -0800
Received: from pgsmsx104.gar.corp.intel.com (10.221.44.91) by
	pgsmsx602.gar.corp.intel.com (10.221.43.81) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Fri, 23 Dec 2011 18:26:25 +0800
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	PGSMSX104.gar.corp.intel.com (10.221.44.91) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Fri, 23 Dec 2011 18:26:24 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.38]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.223]) with mapi id
	14.01.0355.002; Fri, 23 Dec 2011 18:26:22 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: "konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
Thread-Topic: [PATCH 04/10] Xen: Add pcpu hotadd support to pvops dom0.
Thread-Index: AczBXVB6uMUxR0YtT4yH9J/oEfJ7Ig==
Date: Fri, 23 Dec 2011 10:26:21 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC829233596DC@SHSMSX101.ccr.corp.intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
Content-Type: multipart/mixed;
	boundary="_002_DE8DF0795D48FD4CA783C40EC829233596DCSHSMSX101ccrcorpint_"
MIME-Version: 1.0
Cc: "Brown, Len" <len.brown@intel.com>,
	"jeremy.fitzhardinge@citrix.com" <jeremy.fitzhardinge@citrix.com>,
	"Jiang, Yunhong" <yunhong.jiang@intel.com>, "Shan, 
	Haitao" <haitao.shan@intel.com>,
	Kernel development list <linux-kernel@vger.kernel.org>, "Zhao,
	Yakui" <yakui.zhao@intel.com>, "Luck, Tony" <tony.luck@intel.com>, "Kleen,
	Andi" <andi.kleen@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: [Xen-devel] [PATCH 04/10] Xen: Add pcpu hotadd support to pvops
	dom0.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--_002_DE8DF0795D48FD4CA783C40EC829233596DCSHSMSX101ccrcorpint_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

>From 5f5eb7bf950836edb4910173d3be2f26ad737093 Mon Sep 17 00:00:00 2001
From: Liu Jinsong <jinsong.liu@intel.com>
Date: Sun, 11 Dec 2011 15:42:03 +0800
Subject: [PATCH 04/10] Xen: Add pcpu hotadd support to pvops dom0.

This patch rebased from Jeremy's pvops commit
3129884bc75d7e6578be7499ac04a06d9fc5b31d

This patch implement CPU hotplug callback in xen acpi_processor. User
can later bring the pcpu online through sysfs interface.

xen_get_apic_id() is mostly duplicated with the get_cpu_id() in
driver/acpi/processor_core.c, but it should be ok since it has been
duplicated in arch directory already by upstream kernel.

One thing left is, currently the acpi_processor's id is quite
confusing (it is in fact with vcpu's dom0 cpu_id). Will update it with
xen's cpuid through the pcpu interface. But to achieve it, we need
investigate more on the pr->id, and also we need change the pcpu logic
to use spin_lock, instead of mutex for the pcpu list. That will be
next step.

Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
Signed-off-by: Jiang, Yunhong <yunhong.jiang@intel.com>
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
---
 drivers/xen/acpi_processor.c     |  114 ++++++++++++++++++++++++++++++++++=
+++-
 include/xen/interface/platform.h |   10 +++-
 2 files changed, 122 insertions(+), 2 deletions(-)

diff --git a/drivers/xen/acpi_processor.c b/drivers/xen/acpi_processor.c
index 327a56e..acab49b 100644
--- a/drivers/xen/acpi_processor.c
+++ b/drivers/xen/acpi_processor.c
@@ -22,12 +22,19 @@
 #include <linux/cpufreq.h>
 #include <acpi/processor.h>
 #include <xen/acpi.h>
+#include <xen/pcpu.h>
=20
 #include <xen/interface/platform.h>
 #include <asm/xen/hypercall.h>
 #include <asm/xen/hypervisor.h>
=20
-static struct processor_cntl_xen_ops xen_ops;
+static int xen_get_apic_id(acpi_handle handle);
+static int xen_cpu_hotplug_notifier(struct acpi_processor *pr, int event);
+
+static struct processor_cntl_xen_ops xen_ops =3D {
+	.hotplug =3D xen_cpu_hotplug_notifier,
+};
+
 int processor_cntl_xen_notify(struct acpi_processor *pr, int event, int ty=
pe)
 {
 	int ret =3D -EINVAL;
@@ -41,6 +48,18 @@ int processor_cntl_xen_notify(struct acpi_processor *pr,=
 int event, int type)
=20
 		ret =3D xen_ops.pm_ops[type](pr, event);
 		break;
+	case PROCESSOR_HOTPLUG:
+	{
+		int apic_id;
+
+		apic_id =3D xen_get_apic_id(pr->handle);
+		if (apic_id < 0)
+			break;
+		if (xen_ops.hotplug)
+			ret =3D xen_ops.hotplug(pr, type);
+		xen_pcpu_hotplug(type, apic_id);
+		break;
+	}
 	default:
 		printk(KERN_ERR "Unsupport processor events %d.\n", event);
 		break;
@@ -50,6 +69,49 @@ int processor_cntl_xen_notify(struct acpi_processor *pr,=
 int event, int type)
 }
 EXPORT_SYMBOL(processor_cntl_xen_notify);
=20
+#ifdef CONFIG_ACPI_HOTPLUG_CPU
+static int xen_get_apic_id(acpi_handle handle)
+{
+	struct acpi_buffer buffer =3D { ACPI_ALLOCATE_BUFFER, NULL };
+	union acpi_object *obj;
+	struct acpi_madt_local_apic *lapic;
+	u8 physid;
+
+	if (ACPI_FAILURE(acpi_evaluate_object(handle, "_MAT", NULL, &buffer)))
+		return -EINVAL;
+
+	if (!buffer.length || !buffer.pointer)
+		return -EINVAL;
+
+	obj =3D buffer.pointer;
+	if (obj->type !=3D ACPI_TYPE_BUFFER ||
+	    obj->buffer.length < sizeof(*lapic)) {
+		kfree(buffer.pointer);
+		return -EINVAL;
+	}
+
+	lapic =3D (struct acpi_madt_local_apic *)obj->buffer.pointer;
+
+	if (lapic->header.type !=3D ACPI_MADT_TYPE_LOCAL_APIC ||
+	    !(lapic->lapic_flags & ACPI_MADT_ENABLED)) {
+		kfree(buffer.pointer);
+		return -EINVAL;
+	}
+
+	physid =3D lapic->id;
+	kfree(buffer.pointer);
+	buffer.length =3D ACPI_ALLOCATE_BUFFER;
+	buffer.pointer =3D NULL;
+
+	return physid;
+}
+#else
+static int xen_get_apic_id(acpi_handle handle)
+{
+	return -1;
+}
+#endif
+
 static inline void xen_convert_pct_reg(struct xen_pct_register *xpct,
 	struct acpi_pct_register *apct)
 {
@@ -246,6 +308,56 @@ static int xen_px_notifier(struct acpi_processor *pr, =
int action)
 	return ret;
 }
=20
+#ifdef CONFIG_ACPI_HOTPLUG_CPU
+static int xen_cpu_hotplug_notifier(struct acpi_processor *pr, int event)
+{
+	int ret =3D -EINVAL;
+	uint32_t apic_id;
+	unsigned long long pxm;
+	acpi_status status =3D 0;
+
+	xen_platform_op_t op =3D {
+		.interface_version  =3D XENPF_INTERFACE_VERSION,
+	};
+
+	apic_id =3D xen_get_apic_id(pr->handle);
+	if (apic_id < 0) {
+		printk(KERN_WARNING "Can't get apic_id for acpi_id %x\n",
+		  pr->acpi_id);
+		return -1;
+	}
+
+	status =3D acpi_evaluate_integer(pr->handle, "_PXM",
+	  NULL, &pxm);
+	if (ACPI_FAILURE(status)) {
+		printk(KERN_WARNING "can't get pxm for acpi_id %x\n",
+		  pr->acpi_id);
+		return -1;
+	}
+
+	switch (event) {
+	case HOTPLUG_TYPE_ADD:
+		op.cmd =3D XENPF_cpu_hotadd;
+		op.u.cpu_add.apic_id =3D apic_id;
+		op.u.cpu_add.acpi_id =3D pr->acpi_id;
+		op.u.cpu_add.pxm =3D pxm;
+		ret =3D HYPERVISOR_dom0_op(&op);
+		break;
+	case HOTPLUG_TYPE_REMOVE:
+		printk(KERN_WARNING "Xen not support CPU hotremove\n");
+		ret =3D -ENOSYS;
+		break;
+	}
+
+	return ret;
+}
+#else
+static int xen_cpu_hotplug_notifier(struct acpi_processor *pr, int event)
+{
+	return -ENOSYS;
+}
+#endif
+
 static int __init xen_acpi_processor_extcntl_init(void)
 {
 	unsigned int pmbits;
diff --git a/include/xen/interface/platform.h b/include/xen/interface/platf=
orm.h
index 47ffe16..9fd6b07 100644
--- a/include/xen/interface/platform.h
+++ b/include/xen/interface/platform.h
@@ -317,11 +317,18 @@ DEFINE_GUEST_HANDLE_STRUCT(xenpf_pcpuinfo_t);
 #define XENPF_cpu_online    56
 #define XENPF_cpu_offline   57
 struct xenpf_cpu_ol {
-    uint32_t cpuid;
+	uint32_t cpuid;
 };
 typedef struct xenpf_cpu_ol xenpf_cpu_ol_t;
 DEFINE_GUEST_HANDLE_STRUCT(xenpf_cpu_ol_t);
=20
+#define XENPF_cpu_hotadd    58
+struct xenpf_cpu_hotadd {
+	uint32_t apic_id;
+	uint32_t acpi_id;
+	uint32_t pxm;
+};
+
 struct xen_platform_op {
 	uint32_t cmd;
 	uint32_t interface_version; /* XENPF_INTERFACE_VERSION */
@@ -339,6 +346,7 @@ struct xen_platform_op {
 		struct xenpf_set_processor_pminfo set_pminfo;
 		struct xenpf_pcpuinfo          pcpu_info;
 		struct xenpf_cpu_ol            cpu_ol;
+		struct xenpf_cpu_hotadd        cpu_add;
 		uint8_t                        pad[128];
 	} u;
 };
--=20
1.6.5.6

--_002_DE8DF0795D48FD4CA783C40EC829233596DCSHSMSX101ccrcorpint_
Content-Type: application/octet-stream;
	name="0004-Xen-Add-pcpu-hotadd-support-to-pvops-dom0.patch"
Content-Description: 0004-Xen-Add-pcpu-hotadd-support-to-pvops-dom0.patch
Content-Disposition: attachment;
	filename="0004-Xen-Add-pcpu-hotadd-support-to-pvops-dom0.patch"; size=6111;
	creation-date="Wed, 14 Dec 2011 15:20:15 GMT";
	modification-date="Wed, 14 Dec 2011 15:03:34 GMT"
Content-Transfer-Encoding: base64

RnJvbSA1ZjVlYjdiZjk1MDgzNmVkYjQ5MTAxNzNkM2JlMmYyNmFkNzM3MDkzIE1vbiBTZXAgMTcg
MDA6MDA6MDAgMjAwMQpGcm9tOiBMaXUgSmluc29uZyA8amluc29uZy5saXVAaW50ZWwuY29tPgpE
YXRlOiBTdW4sIDExIERlYyAyMDExIDE1OjQyOjAzICswODAwClN1YmplY3Q6IFtQQVRDSCAwNC8x
MF0gWGVuOiBBZGQgcGNwdSBob3RhZGQgc3VwcG9ydCB0byBwdm9wcyBkb20wLgoKVGhpcyBwYXRj
aCByZWJhc2VkIGZyb20gSmVyZW15J3MgcHZvcHMgY29tbWl0CjMxMjk4ODRiYzc1ZDdlNjU3OGJl
NzQ5OWFjMDRhMDZkOWZjNWIzMWQKClRoaXMgcGF0Y2ggaW1wbGVtZW50IENQVSBob3RwbHVnIGNh
bGxiYWNrIGluIHhlbiBhY3BpX3Byb2Nlc3Nvci4gVXNlcgpjYW4gbGF0ZXIgYnJpbmcgdGhlIHBj
cHUgb25saW5lIHRocm91Z2ggc3lzZnMgaW50ZXJmYWNlLgoKeGVuX2dldF9hcGljX2lkKCkgaXMg
bW9zdGx5IGR1cGxpY2F0ZWQgd2l0aCB0aGUgZ2V0X2NwdV9pZCgpIGluCmRyaXZlci9hY3BpL3By
b2Nlc3Nvcl9jb3JlLmMsIGJ1dCBpdCBzaG91bGQgYmUgb2sgc2luY2UgaXQgaGFzIGJlZW4KZHVw
bGljYXRlZCBpbiBhcmNoIGRpcmVjdG9yeSBhbHJlYWR5IGJ5IHVwc3RyZWFtIGtlcm5lbC4KCk9u
ZSB0aGluZyBsZWZ0IGlzLCBjdXJyZW50bHkgdGhlIGFjcGlfcHJvY2Vzc29yJ3MgaWQgaXMgcXVp
dGUKY29uZnVzaW5nIChpdCBpcyBpbiBmYWN0IHdpdGggdmNwdSdzIGRvbTAgY3B1X2lkKS4gV2ls
bCB1cGRhdGUgaXQgd2l0aAp4ZW4ncyBjcHVpZCB0aHJvdWdoIHRoZSBwY3B1IGludGVyZmFjZS4g
QnV0IHRvIGFjaGlldmUgaXQsIHdlIG5lZWQKaW52ZXN0aWdhdGUgbW9yZSBvbiB0aGUgcHItPmlk
LCBhbmQgYWxzbyB3ZSBuZWVkIGNoYW5nZSB0aGUgcGNwdSBsb2dpYwp0byB1c2Ugc3Bpbl9sb2Nr
LCBpbnN0ZWFkIG9mIG11dGV4IGZvciB0aGUgcGNwdSBsaXN0LiBUaGF0IHdpbGwgYmUKbmV4dCBz
dGVwLgoKU2lnbmVkLW9mZi1ieTogTGl1LCBKaW5zb25nIDxqaW5zb25nLmxpdUBpbnRlbC5jb20+
ClNpZ25lZC1vZmYtYnk6IEppYW5nLCBZdW5ob25nIDx5dW5ob25nLmppYW5nQGludGVsLmNvbT4K
U2lnbmVkLW9mZi1ieTogSmVyZW15IEZpdHpoYXJkaW5nZSA8amVyZW15LmZpdHpoYXJkaW5nZUBj
aXRyaXguY29tPgotLS0KIGRyaXZlcnMveGVuL2FjcGlfcHJvY2Vzc29yLmMgICAgIHwgIDExNCAr
KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrLQogaW5jbHVkZS94ZW4vaW50ZXJm
YWNlL3BsYXRmb3JtLmggfCAgIDEwICsrKy0KIDIgZmlsZXMgY2hhbmdlZCwgMTIyIGluc2VydGlv
bnMoKyksIDIgZGVsZXRpb25zKC0pCgpkaWZmIC0tZ2l0IGEvZHJpdmVycy94ZW4vYWNwaV9wcm9j
ZXNzb3IuYyBiL2RyaXZlcnMveGVuL2FjcGlfcHJvY2Vzc29yLmMKaW5kZXggMzI3YTU2ZS4uYWNh
YjQ5YiAxMDA2NDQKLS0tIGEvZHJpdmVycy94ZW4vYWNwaV9wcm9jZXNzb3IuYworKysgYi9kcml2
ZXJzL3hlbi9hY3BpX3Byb2Nlc3Nvci5jCkBAIC0yMiwxMiArMjIsMTkgQEAKICNpbmNsdWRlIDxs
aW51eC9jcHVmcmVxLmg+CiAjaW5jbHVkZSA8YWNwaS9wcm9jZXNzb3IuaD4KICNpbmNsdWRlIDx4
ZW4vYWNwaS5oPgorI2luY2x1ZGUgPHhlbi9wY3B1Lmg+CiAKICNpbmNsdWRlIDx4ZW4vaW50ZXJm
YWNlL3BsYXRmb3JtLmg+CiAjaW5jbHVkZSA8YXNtL3hlbi9oeXBlcmNhbGwuaD4KICNpbmNsdWRl
IDxhc20veGVuL2h5cGVydmlzb3IuaD4KIAotc3RhdGljIHN0cnVjdCBwcm9jZXNzb3JfY250bF94
ZW5fb3BzIHhlbl9vcHM7CitzdGF0aWMgaW50IHhlbl9nZXRfYXBpY19pZChhY3BpX2hhbmRsZSBo
YW5kbGUpOworc3RhdGljIGludCB4ZW5fY3B1X2hvdHBsdWdfbm90aWZpZXIoc3RydWN0IGFjcGlf
cHJvY2Vzc29yICpwciwgaW50IGV2ZW50KTsKKworc3RhdGljIHN0cnVjdCBwcm9jZXNzb3JfY250
bF94ZW5fb3BzIHhlbl9vcHMgPSB7CisJLmhvdHBsdWcgPSB4ZW5fY3B1X2hvdHBsdWdfbm90aWZp
ZXIsCit9OworCiBpbnQgcHJvY2Vzc29yX2NudGxfeGVuX25vdGlmeShzdHJ1Y3QgYWNwaV9wcm9j
ZXNzb3IgKnByLCBpbnQgZXZlbnQsIGludCB0eXBlKQogewogCWludCByZXQgPSAtRUlOVkFMOwpA
QCAtNDEsNiArNDgsMTggQEAgaW50IHByb2Nlc3Nvcl9jbnRsX3hlbl9ub3RpZnkoc3RydWN0IGFj
cGlfcHJvY2Vzc29yICpwciwgaW50IGV2ZW50LCBpbnQgdHlwZSkKIAogCQlyZXQgPSB4ZW5fb3Bz
LnBtX29wc1t0eXBlXShwciwgZXZlbnQpOwogCQlicmVhazsKKwljYXNlIFBST0NFU1NPUl9IT1RQ
TFVHOgorCXsKKwkJaW50IGFwaWNfaWQ7CisKKwkJYXBpY19pZCA9IHhlbl9nZXRfYXBpY19pZChw
ci0+aGFuZGxlKTsKKwkJaWYgKGFwaWNfaWQgPCAwKQorCQkJYnJlYWs7CisJCWlmICh4ZW5fb3Bz
LmhvdHBsdWcpCisJCQlyZXQgPSB4ZW5fb3BzLmhvdHBsdWcocHIsIHR5cGUpOworCQl4ZW5fcGNw
dV9ob3RwbHVnKHR5cGUsIGFwaWNfaWQpOworCQlicmVhazsKKwl9CiAJZGVmYXVsdDoKIAkJcHJp
bnRrKEtFUk5fRVJSICJVbnN1cHBvcnQgcHJvY2Vzc29yIGV2ZW50cyAlZC5cbiIsIGV2ZW50KTsK
IAkJYnJlYWs7CkBAIC01MCw2ICs2OSw0OSBAQCBpbnQgcHJvY2Vzc29yX2NudGxfeGVuX25vdGlm
eShzdHJ1Y3QgYWNwaV9wcm9jZXNzb3IgKnByLCBpbnQgZXZlbnQsIGludCB0eXBlKQogfQogRVhQ
T1JUX1NZTUJPTChwcm9jZXNzb3JfY250bF94ZW5fbm90aWZ5KTsKIAorI2lmZGVmIENPTkZJR19B
Q1BJX0hPVFBMVUdfQ1BVCitzdGF0aWMgaW50IHhlbl9nZXRfYXBpY19pZChhY3BpX2hhbmRsZSBo
YW5kbGUpCit7CisJc3RydWN0IGFjcGlfYnVmZmVyIGJ1ZmZlciA9IHsgQUNQSV9BTExPQ0FURV9C
VUZGRVIsIE5VTEwgfTsKKwl1bmlvbiBhY3BpX29iamVjdCAqb2JqOworCXN0cnVjdCBhY3BpX21h
ZHRfbG9jYWxfYXBpYyAqbGFwaWM7CisJdTggcGh5c2lkOworCisJaWYgKEFDUElfRkFJTFVSRShh
Y3BpX2V2YWx1YXRlX29iamVjdChoYW5kbGUsICJfTUFUIiwgTlVMTCwgJmJ1ZmZlcikpKQorCQly
ZXR1cm4gLUVJTlZBTDsKKworCWlmICghYnVmZmVyLmxlbmd0aCB8fCAhYnVmZmVyLnBvaW50ZXIp
CisJCXJldHVybiAtRUlOVkFMOworCisJb2JqID0gYnVmZmVyLnBvaW50ZXI7CisJaWYgKG9iai0+
dHlwZSAhPSBBQ1BJX1RZUEVfQlVGRkVSIHx8CisJICAgIG9iai0+YnVmZmVyLmxlbmd0aCA8IHNp
emVvZigqbGFwaWMpKSB7CisJCWtmcmVlKGJ1ZmZlci5wb2ludGVyKTsKKwkJcmV0dXJuIC1FSU5W
QUw7CisJfQorCisJbGFwaWMgPSAoc3RydWN0IGFjcGlfbWFkdF9sb2NhbF9hcGljICopb2JqLT5i
dWZmZXIucG9pbnRlcjsKKworCWlmIChsYXBpYy0+aGVhZGVyLnR5cGUgIT0gQUNQSV9NQURUX1RZ
UEVfTE9DQUxfQVBJQyB8fAorCSAgICAhKGxhcGljLT5sYXBpY19mbGFncyAmIEFDUElfTUFEVF9F
TkFCTEVEKSkgeworCQlrZnJlZShidWZmZXIucG9pbnRlcik7CisJCXJldHVybiAtRUlOVkFMOwor
CX0KKworCXBoeXNpZCA9IGxhcGljLT5pZDsKKwlrZnJlZShidWZmZXIucG9pbnRlcik7CisJYnVm
ZmVyLmxlbmd0aCA9IEFDUElfQUxMT0NBVEVfQlVGRkVSOworCWJ1ZmZlci5wb2ludGVyID0gTlVM
TDsKKworCXJldHVybiBwaHlzaWQ7Cit9CisjZWxzZQorc3RhdGljIGludCB4ZW5fZ2V0X2FwaWNf
aWQoYWNwaV9oYW5kbGUgaGFuZGxlKQoreworCXJldHVybiAtMTsKK30KKyNlbmRpZgorCiBzdGF0
aWMgaW5saW5lIHZvaWQgeGVuX2NvbnZlcnRfcGN0X3JlZyhzdHJ1Y3QgeGVuX3BjdF9yZWdpc3Rl
ciAqeHBjdCwKIAlzdHJ1Y3QgYWNwaV9wY3RfcmVnaXN0ZXIgKmFwY3QpCiB7CkBAIC0yNDYsNiAr
MzA4LDU2IEBAIHN0YXRpYyBpbnQgeGVuX3B4X25vdGlmaWVyKHN0cnVjdCBhY3BpX3Byb2Nlc3Nv
ciAqcHIsIGludCBhY3Rpb24pCiAJcmV0dXJuIHJldDsKIH0KIAorI2lmZGVmIENPTkZJR19BQ1BJ
X0hPVFBMVUdfQ1BVCitzdGF0aWMgaW50IHhlbl9jcHVfaG90cGx1Z19ub3RpZmllcihzdHJ1Y3Qg
YWNwaV9wcm9jZXNzb3IgKnByLCBpbnQgZXZlbnQpCit7CisJaW50IHJldCA9IC1FSU5WQUw7CisJ
dWludDMyX3QgYXBpY19pZDsKKwl1bnNpZ25lZCBsb25nIGxvbmcgcHhtOworCWFjcGlfc3RhdHVz
IHN0YXR1cyA9IDA7CisKKwl4ZW5fcGxhdGZvcm1fb3BfdCBvcCA9IHsKKwkJLmludGVyZmFjZV92
ZXJzaW9uICA9IFhFTlBGX0lOVEVSRkFDRV9WRVJTSU9OLAorCX07CisKKwlhcGljX2lkID0geGVu
X2dldF9hcGljX2lkKHByLT5oYW5kbGUpOworCWlmIChhcGljX2lkIDwgMCkgeworCQlwcmludGso
S0VSTl9XQVJOSU5HICJDYW4ndCBnZXQgYXBpY19pZCBmb3IgYWNwaV9pZCAleFxuIiwKKwkJICBw
ci0+YWNwaV9pZCk7CisJCXJldHVybiAtMTsKKwl9CisKKwlzdGF0dXMgPSBhY3BpX2V2YWx1YXRl
X2ludGVnZXIocHItPmhhbmRsZSwgIl9QWE0iLAorCSAgTlVMTCwgJnB4bSk7CisJaWYgKEFDUElf
RkFJTFVSRShzdGF0dXMpKSB7CisJCXByaW50ayhLRVJOX1dBUk5JTkcgImNhbid0IGdldCBweG0g
Zm9yIGFjcGlfaWQgJXhcbiIsCisJCSAgcHItPmFjcGlfaWQpOworCQlyZXR1cm4gLTE7CisJfQor
CisJc3dpdGNoIChldmVudCkgeworCWNhc2UgSE9UUExVR19UWVBFX0FERDoKKwkJb3AuY21kID0g
WEVOUEZfY3B1X2hvdGFkZDsKKwkJb3AudS5jcHVfYWRkLmFwaWNfaWQgPSBhcGljX2lkOworCQlv
cC51LmNwdV9hZGQuYWNwaV9pZCA9IHByLT5hY3BpX2lkOworCQlvcC51LmNwdV9hZGQucHhtID0g
cHhtOworCQlyZXQgPSBIWVBFUlZJU09SX2RvbTBfb3AoJm9wKTsKKwkJYnJlYWs7CisJY2FzZSBI
T1RQTFVHX1RZUEVfUkVNT1ZFOgorCQlwcmludGsoS0VSTl9XQVJOSU5HICJYZW4gbm90IHN1cHBv
cnQgQ1BVIGhvdHJlbW92ZVxuIik7CisJCXJldCA9IC1FTk9TWVM7CisJCWJyZWFrOworCX0KKwor
CXJldHVybiByZXQ7Cit9CisjZWxzZQorc3RhdGljIGludCB4ZW5fY3B1X2hvdHBsdWdfbm90aWZp
ZXIoc3RydWN0IGFjcGlfcHJvY2Vzc29yICpwciwgaW50IGV2ZW50KQoreworCXJldHVybiAtRU5P
U1lTOworfQorI2VuZGlmCisKIHN0YXRpYyBpbnQgX19pbml0IHhlbl9hY3BpX3Byb2Nlc3Nvcl9l
eHRjbnRsX2luaXQodm9pZCkKIHsKIAl1bnNpZ25lZCBpbnQgcG1iaXRzOwpkaWZmIC0tZ2l0IGEv
aW5jbHVkZS94ZW4vaW50ZXJmYWNlL3BsYXRmb3JtLmggYi9pbmNsdWRlL3hlbi9pbnRlcmZhY2Uv
cGxhdGZvcm0uaAppbmRleCA0N2ZmZTE2Li45ZmQ2YjA3IDEwMDY0NAotLS0gYS9pbmNsdWRlL3hl
bi9pbnRlcmZhY2UvcGxhdGZvcm0uaAorKysgYi9pbmNsdWRlL3hlbi9pbnRlcmZhY2UvcGxhdGZv
cm0uaApAQCAtMzE3LDExICszMTcsMTggQEAgREVGSU5FX0dVRVNUX0hBTkRMRV9TVFJVQ1QoeGVu
cGZfcGNwdWluZm9fdCk7CiAjZGVmaW5lIFhFTlBGX2NwdV9vbmxpbmUgICAgNTYKICNkZWZpbmUg
WEVOUEZfY3B1X29mZmxpbmUgICA1Nwogc3RydWN0IHhlbnBmX2NwdV9vbCB7Ci0gICAgdWludDMy
X3QgY3B1aWQ7CisJdWludDMyX3QgY3B1aWQ7CiB9OwogdHlwZWRlZiBzdHJ1Y3QgeGVucGZfY3B1
X29sIHhlbnBmX2NwdV9vbF90OwogREVGSU5FX0dVRVNUX0hBTkRMRV9TVFJVQ1QoeGVucGZfY3B1
X29sX3QpOwogCisjZGVmaW5lIFhFTlBGX2NwdV9ob3RhZGQgICAgNTgKK3N0cnVjdCB4ZW5wZl9j
cHVfaG90YWRkIHsKKwl1aW50MzJfdCBhcGljX2lkOworCXVpbnQzMl90IGFjcGlfaWQ7CisJdWlu
dDMyX3QgcHhtOworfTsKKwogc3RydWN0IHhlbl9wbGF0Zm9ybV9vcCB7CiAJdWludDMyX3QgY21k
OwogCXVpbnQzMl90IGludGVyZmFjZV92ZXJzaW9uOyAvKiBYRU5QRl9JTlRFUkZBQ0VfVkVSU0lP
TiAqLwpAQCAtMzM5LDYgKzM0Niw3IEBAIHN0cnVjdCB4ZW5fcGxhdGZvcm1fb3AgewogCQlzdHJ1
Y3QgeGVucGZfc2V0X3Byb2Nlc3Nvcl9wbWluZm8gc2V0X3BtaW5mbzsKIAkJc3RydWN0IHhlbnBm
X3BjcHVpbmZvICAgICAgICAgIHBjcHVfaW5mbzsKIAkJc3RydWN0IHhlbnBmX2NwdV9vbCAgICAg
ICAgICAgIGNwdV9vbDsKKwkJc3RydWN0IHhlbnBmX2NwdV9ob3RhZGQgICAgICAgIGNwdV9hZGQ7
CiAJCXVpbnQ4X3QgICAgICAgICAgICAgICAgICAgICAgICBwYWRbMTI4XTsKIAl9IHU7CiB9Owot
LSAKMS42LjUuNgoK

--_002_DE8DF0795D48FD4CA783C40EC829233596DCSHSMSX101ccrcorpint_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--_002_DE8DF0795D48FD4CA783C40EC829233596DCSHSMSX101ccrcorpint_--


From xen-devel-bounces@lists.xensource.com Fri Dec 23 10:27:13 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 Dec 2011 10:27:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Re2L8-0006IR-6j; Fri, 23 Dec 2011 10:27:02 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1Re2L7-0006Ht-1c
	for xen-devel@lists.xensource.com; Fri, 23 Dec 2011 10:27:01 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1324636013!3090315!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDMwMDk1NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6717 invoked from network); 23 Dec 2011 10:26:53 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-9.tower-21.messagelabs.com with SMTP;
	23 Dec 2011 10:26:53 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga102.fm.intel.com with ESMTP; 23 Dec 2011 02:26:52 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208,223";a="99638597"
Received: from pgsmsx602.gar.corp.intel.com ([10.221.43.81])
	by fmsmga001.fm.intel.com with ESMTP; 23 Dec 2011 02:26:51 -0800
Received: from pgsmsx104.gar.corp.intel.com (10.221.44.91) by
	pgsmsx602.gar.corp.intel.com (10.221.43.81) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Fri, 23 Dec 2011 18:26:25 +0800
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	PGSMSX104.gar.corp.intel.com (10.221.44.91) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Fri, 23 Dec 2011 18:26:24 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.38]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.223]) with mapi id
	14.01.0355.002; Fri, 23 Dec 2011 18:26:22 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: "konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
Thread-Topic: [PATCH 04/10] Xen: Add pcpu hotadd support to pvops dom0.
Thread-Index: AczBXVB6uMUxR0YtT4yH9J/oEfJ7Ig==
Date: Fri, 23 Dec 2011 10:26:21 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC829233596DC@SHSMSX101.ccr.corp.intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
Content-Type: multipart/mixed;
	boundary="_002_DE8DF0795D48FD4CA783C40EC829233596DCSHSMSX101ccrcorpint_"
MIME-Version: 1.0
Cc: "Brown, Len" <len.brown@intel.com>,
	"jeremy.fitzhardinge@citrix.com" <jeremy.fitzhardinge@citrix.com>,
	"Jiang, Yunhong" <yunhong.jiang@intel.com>, "Shan, 
	Haitao" <haitao.shan@intel.com>,
	Kernel development list <linux-kernel@vger.kernel.org>, "Zhao,
	Yakui" <yakui.zhao@intel.com>, "Luck, Tony" <tony.luck@intel.com>, "Kleen,
	Andi" <andi.kleen@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: [Xen-devel] [PATCH 04/10] Xen: Add pcpu hotadd support to pvops
	dom0.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--_002_DE8DF0795D48FD4CA783C40EC829233596DCSHSMSX101ccrcorpint_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

>From 5f5eb7bf950836edb4910173d3be2f26ad737093 Mon Sep 17 00:00:00 2001
From: Liu Jinsong <jinsong.liu@intel.com>
Date: Sun, 11 Dec 2011 15:42:03 +0800
Subject: [PATCH 04/10] Xen: Add pcpu hotadd support to pvops dom0.

This patch rebased from Jeremy's pvops commit
3129884bc75d7e6578be7499ac04a06d9fc5b31d

This patch implement CPU hotplug callback in xen acpi_processor. User
can later bring the pcpu online through sysfs interface.

xen_get_apic_id() is mostly duplicated with the get_cpu_id() in
driver/acpi/processor_core.c, but it should be ok since it has been
duplicated in arch directory already by upstream kernel.

One thing left is, currently the acpi_processor's id is quite
confusing (it is in fact with vcpu's dom0 cpu_id). Will update it with
xen's cpuid through the pcpu interface. But to achieve it, we need
investigate more on the pr->id, and also we need change the pcpu logic
to use spin_lock, instead of mutex for the pcpu list. That will be
next step.

Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
Signed-off-by: Jiang, Yunhong <yunhong.jiang@intel.com>
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
---
 drivers/xen/acpi_processor.c     |  114 ++++++++++++++++++++++++++++++++++=
+++-
 include/xen/interface/platform.h |   10 +++-
 2 files changed, 122 insertions(+), 2 deletions(-)

diff --git a/drivers/xen/acpi_processor.c b/drivers/xen/acpi_processor.c
index 327a56e..acab49b 100644
--- a/drivers/xen/acpi_processor.c
+++ b/drivers/xen/acpi_processor.c
@@ -22,12 +22,19 @@
 #include <linux/cpufreq.h>
 #include <acpi/processor.h>
 #include <xen/acpi.h>
+#include <xen/pcpu.h>
=20
 #include <xen/interface/platform.h>
 #include <asm/xen/hypercall.h>
 #include <asm/xen/hypervisor.h>
=20
-static struct processor_cntl_xen_ops xen_ops;
+static int xen_get_apic_id(acpi_handle handle);
+static int xen_cpu_hotplug_notifier(struct acpi_processor *pr, int event);
+
+static struct processor_cntl_xen_ops xen_ops =3D {
+	.hotplug =3D xen_cpu_hotplug_notifier,
+};
+
 int processor_cntl_xen_notify(struct acpi_processor *pr, int event, int ty=
pe)
 {
 	int ret =3D -EINVAL;
@@ -41,6 +48,18 @@ int processor_cntl_xen_notify(struct acpi_processor *pr,=
 int event, int type)
=20
 		ret =3D xen_ops.pm_ops[type](pr, event);
 		break;
+	case PROCESSOR_HOTPLUG:
+	{
+		int apic_id;
+
+		apic_id =3D xen_get_apic_id(pr->handle);
+		if (apic_id < 0)
+			break;
+		if (xen_ops.hotplug)
+			ret =3D xen_ops.hotplug(pr, type);
+		xen_pcpu_hotplug(type, apic_id);
+		break;
+	}
 	default:
 		printk(KERN_ERR "Unsupport processor events %d.\n", event);
 		break;
@@ -50,6 +69,49 @@ int processor_cntl_xen_notify(struct acpi_processor *pr,=
 int event, int type)
 }
 EXPORT_SYMBOL(processor_cntl_xen_notify);
=20
+#ifdef CONFIG_ACPI_HOTPLUG_CPU
+static int xen_get_apic_id(acpi_handle handle)
+{
+	struct acpi_buffer buffer =3D { ACPI_ALLOCATE_BUFFER, NULL };
+	union acpi_object *obj;
+	struct acpi_madt_local_apic *lapic;
+	u8 physid;
+
+	if (ACPI_FAILURE(acpi_evaluate_object(handle, "_MAT", NULL, &buffer)))
+		return -EINVAL;
+
+	if (!buffer.length || !buffer.pointer)
+		return -EINVAL;
+
+	obj =3D buffer.pointer;
+	if (obj->type !=3D ACPI_TYPE_BUFFER ||
+	    obj->buffer.length < sizeof(*lapic)) {
+		kfree(buffer.pointer);
+		return -EINVAL;
+	}
+
+	lapic =3D (struct acpi_madt_local_apic *)obj->buffer.pointer;
+
+	if (lapic->header.type !=3D ACPI_MADT_TYPE_LOCAL_APIC ||
+	    !(lapic->lapic_flags & ACPI_MADT_ENABLED)) {
+		kfree(buffer.pointer);
+		return -EINVAL;
+	}
+
+	physid =3D lapic->id;
+	kfree(buffer.pointer);
+	buffer.length =3D ACPI_ALLOCATE_BUFFER;
+	buffer.pointer =3D NULL;
+
+	return physid;
+}
+#else
+static int xen_get_apic_id(acpi_handle handle)
+{
+	return -1;
+}
+#endif
+
 static inline void xen_convert_pct_reg(struct xen_pct_register *xpct,
 	struct acpi_pct_register *apct)
 {
@@ -246,6 +308,56 @@ static int xen_px_notifier(struct acpi_processor *pr, =
int action)
 	return ret;
 }
=20
+#ifdef CONFIG_ACPI_HOTPLUG_CPU
+static int xen_cpu_hotplug_notifier(struct acpi_processor *pr, int event)
+{
+	int ret =3D -EINVAL;
+	uint32_t apic_id;
+	unsigned long long pxm;
+	acpi_status status =3D 0;
+
+	xen_platform_op_t op =3D {
+		.interface_version  =3D XENPF_INTERFACE_VERSION,
+	};
+
+	apic_id =3D xen_get_apic_id(pr->handle);
+	if (apic_id < 0) {
+		printk(KERN_WARNING "Can't get apic_id for acpi_id %x\n",
+		  pr->acpi_id);
+		return -1;
+	}
+
+	status =3D acpi_evaluate_integer(pr->handle, "_PXM",
+	  NULL, &pxm);
+	if (ACPI_FAILURE(status)) {
+		printk(KERN_WARNING "can't get pxm for acpi_id %x\n",
+		  pr->acpi_id);
+		return -1;
+	}
+
+	switch (event) {
+	case HOTPLUG_TYPE_ADD:
+		op.cmd =3D XENPF_cpu_hotadd;
+		op.u.cpu_add.apic_id =3D apic_id;
+		op.u.cpu_add.acpi_id =3D pr->acpi_id;
+		op.u.cpu_add.pxm =3D pxm;
+		ret =3D HYPERVISOR_dom0_op(&op);
+		break;
+	case HOTPLUG_TYPE_REMOVE:
+		printk(KERN_WARNING "Xen not support CPU hotremove\n");
+		ret =3D -ENOSYS;
+		break;
+	}
+
+	return ret;
+}
+#else
+static int xen_cpu_hotplug_notifier(struct acpi_processor *pr, int event)
+{
+	return -ENOSYS;
+}
+#endif
+
 static int __init xen_acpi_processor_extcntl_init(void)
 {
 	unsigned int pmbits;
diff --git a/include/xen/interface/platform.h b/include/xen/interface/platf=
orm.h
index 47ffe16..9fd6b07 100644
--- a/include/xen/interface/platform.h
+++ b/include/xen/interface/platform.h
@@ -317,11 +317,18 @@ DEFINE_GUEST_HANDLE_STRUCT(xenpf_pcpuinfo_t);
 #define XENPF_cpu_online    56
 #define XENPF_cpu_offline   57
 struct xenpf_cpu_ol {
-    uint32_t cpuid;
+	uint32_t cpuid;
 };
 typedef struct xenpf_cpu_ol xenpf_cpu_ol_t;
 DEFINE_GUEST_HANDLE_STRUCT(xenpf_cpu_ol_t);
=20
+#define XENPF_cpu_hotadd    58
+struct xenpf_cpu_hotadd {
+	uint32_t apic_id;
+	uint32_t acpi_id;
+	uint32_t pxm;
+};
+
 struct xen_platform_op {
 	uint32_t cmd;
 	uint32_t interface_version; /* XENPF_INTERFACE_VERSION */
@@ -339,6 +346,7 @@ struct xen_platform_op {
 		struct xenpf_set_processor_pminfo set_pminfo;
 		struct xenpf_pcpuinfo          pcpu_info;
 		struct xenpf_cpu_ol            cpu_ol;
+		struct xenpf_cpu_hotadd        cpu_add;
 		uint8_t                        pad[128];
 	} u;
 };
--=20
1.6.5.6

--_002_DE8DF0795D48FD4CA783C40EC829233596DCSHSMSX101ccrcorpint_
Content-Type: application/octet-stream;
	name="0004-Xen-Add-pcpu-hotadd-support-to-pvops-dom0.patch"
Content-Description: 0004-Xen-Add-pcpu-hotadd-support-to-pvops-dom0.patch
Content-Disposition: attachment;
	filename="0004-Xen-Add-pcpu-hotadd-support-to-pvops-dom0.patch"; size=6111;
	creation-date="Wed, 14 Dec 2011 15:20:15 GMT";
	modification-date="Wed, 14 Dec 2011 15:03:34 GMT"
Content-Transfer-Encoding: base64

RnJvbSA1ZjVlYjdiZjk1MDgzNmVkYjQ5MTAxNzNkM2JlMmYyNmFkNzM3MDkzIE1vbiBTZXAgMTcg
MDA6MDA6MDAgMjAwMQpGcm9tOiBMaXUgSmluc29uZyA8amluc29uZy5saXVAaW50ZWwuY29tPgpE
YXRlOiBTdW4sIDExIERlYyAyMDExIDE1OjQyOjAzICswODAwClN1YmplY3Q6IFtQQVRDSCAwNC8x
MF0gWGVuOiBBZGQgcGNwdSBob3RhZGQgc3VwcG9ydCB0byBwdm9wcyBkb20wLgoKVGhpcyBwYXRj
aCByZWJhc2VkIGZyb20gSmVyZW15J3MgcHZvcHMgY29tbWl0CjMxMjk4ODRiYzc1ZDdlNjU3OGJl
NzQ5OWFjMDRhMDZkOWZjNWIzMWQKClRoaXMgcGF0Y2ggaW1wbGVtZW50IENQVSBob3RwbHVnIGNh
bGxiYWNrIGluIHhlbiBhY3BpX3Byb2Nlc3Nvci4gVXNlcgpjYW4gbGF0ZXIgYnJpbmcgdGhlIHBj
cHUgb25saW5lIHRocm91Z2ggc3lzZnMgaW50ZXJmYWNlLgoKeGVuX2dldF9hcGljX2lkKCkgaXMg
bW9zdGx5IGR1cGxpY2F0ZWQgd2l0aCB0aGUgZ2V0X2NwdV9pZCgpIGluCmRyaXZlci9hY3BpL3By
b2Nlc3Nvcl9jb3JlLmMsIGJ1dCBpdCBzaG91bGQgYmUgb2sgc2luY2UgaXQgaGFzIGJlZW4KZHVw
bGljYXRlZCBpbiBhcmNoIGRpcmVjdG9yeSBhbHJlYWR5IGJ5IHVwc3RyZWFtIGtlcm5lbC4KCk9u
ZSB0aGluZyBsZWZ0IGlzLCBjdXJyZW50bHkgdGhlIGFjcGlfcHJvY2Vzc29yJ3MgaWQgaXMgcXVp
dGUKY29uZnVzaW5nIChpdCBpcyBpbiBmYWN0IHdpdGggdmNwdSdzIGRvbTAgY3B1X2lkKS4gV2ls
bCB1cGRhdGUgaXQgd2l0aAp4ZW4ncyBjcHVpZCB0aHJvdWdoIHRoZSBwY3B1IGludGVyZmFjZS4g
QnV0IHRvIGFjaGlldmUgaXQsIHdlIG5lZWQKaW52ZXN0aWdhdGUgbW9yZSBvbiB0aGUgcHItPmlk
LCBhbmQgYWxzbyB3ZSBuZWVkIGNoYW5nZSB0aGUgcGNwdSBsb2dpYwp0byB1c2Ugc3Bpbl9sb2Nr
LCBpbnN0ZWFkIG9mIG11dGV4IGZvciB0aGUgcGNwdSBsaXN0LiBUaGF0IHdpbGwgYmUKbmV4dCBz
dGVwLgoKU2lnbmVkLW9mZi1ieTogTGl1LCBKaW5zb25nIDxqaW5zb25nLmxpdUBpbnRlbC5jb20+
ClNpZ25lZC1vZmYtYnk6IEppYW5nLCBZdW5ob25nIDx5dW5ob25nLmppYW5nQGludGVsLmNvbT4K
U2lnbmVkLW9mZi1ieTogSmVyZW15IEZpdHpoYXJkaW5nZSA8amVyZW15LmZpdHpoYXJkaW5nZUBj
aXRyaXguY29tPgotLS0KIGRyaXZlcnMveGVuL2FjcGlfcHJvY2Vzc29yLmMgICAgIHwgIDExNCAr
KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrLQogaW5jbHVkZS94ZW4vaW50ZXJm
YWNlL3BsYXRmb3JtLmggfCAgIDEwICsrKy0KIDIgZmlsZXMgY2hhbmdlZCwgMTIyIGluc2VydGlv
bnMoKyksIDIgZGVsZXRpb25zKC0pCgpkaWZmIC0tZ2l0IGEvZHJpdmVycy94ZW4vYWNwaV9wcm9j
ZXNzb3IuYyBiL2RyaXZlcnMveGVuL2FjcGlfcHJvY2Vzc29yLmMKaW5kZXggMzI3YTU2ZS4uYWNh
YjQ5YiAxMDA2NDQKLS0tIGEvZHJpdmVycy94ZW4vYWNwaV9wcm9jZXNzb3IuYworKysgYi9kcml2
ZXJzL3hlbi9hY3BpX3Byb2Nlc3Nvci5jCkBAIC0yMiwxMiArMjIsMTkgQEAKICNpbmNsdWRlIDxs
aW51eC9jcHVmcmVxLmg+CiAjaW5jbHVkZSA8YWNwaS9wcm9jZXNzb3IuaD4KICNpbmNsdWRlIDx4
ZW4vYWNwaS5oPgorI2luY2x1ZGUgPHhlbi9wY3B1Lmg+CiAKICNpbmNsdWRlIDx4ZW4vaW50ZXJm
YWNlL3BsYXRmb3JtLmg+CiAjaW5jbHVkZSA8YXNtL3hlbi9oeXBlcmNhbGwuaD4KICNpbmNsdWRl
IDxhc20veGVuL2h5cGVydmlzb3IuaD4KIAotc3RhdGljIHN0cnVjdCBwcm9jZXNzb3JfY250bF94
ZW5fb3BzIHhlbl9vcHM7CitzdGF0aWMgaW50IHhlbl9nZXRfYXBpY19pZChhY3BpX2hhbmRsZSBo
YW5kbGUpOworc3RhdGljIGludCB4ZW5fY3B1X2hvdHBsdWdfbm90aWZpZXIoc3RydWN0IGFjcGlf
cHJvY2Vzc29yICpwciwgaW50IGV2ZW50KTsKKworc3RhdGljIHN0cnVjdCBwcm9jZXNzb3JfY250
bF94ZW5fb3BzIHhlbl9vcHMgPSB7CisJLmhvdHBsdWcgPSB4ZW5fY3B1X2hvdHBsdWdfbm90aWZp
ZXIsCit9OworCiBpbnQgcHJvY2Vzc29yX2NudGxfeGVuX25vdGlmeShzdHJ1Y3QgYWNwaV9wcm9j
ZXNzb3IgKnByLCBpbnQgZXZlbnQsIGludCB0eXBlKQogewogCWludCByZXQgPSAtRUlOVkFMOwpA
QCAtNDEsNiArNDgsMTggQEAgaW50IHByb2Nlc3Nvcl9jbnRsX3hlbl9ub3RpZnkoc3RydWN0IGFj
cGlfcHJvY2Vzc29yICpwciwgaW50IGV2ZW50LCBpbnQgdHlwZSkKIAogCQlyZXQgPSB4ZW5fb3Bz
LnBtX29wc1t0eXBlXShwciwgZXZlbnQpOwogCQlicmVhazsKKwljYXNlIFBST0NFU1NPUl9IT1RQ
TFVHOgorCXsKKwkJaW50IGFwaWNfaWQ7CisKKwkJYXBpY19pZCA9IHhlbl9nZXRfYXBpY19pZChw
ci0+aGFuZGxlKTsKKwkJaWYgKGFwaWNfaWQgPCAwKQorCQkJYnJlYWs7CisJCWlmICh4ZW5fb3Bz
LmhvdHBsdWcpCisJCQlyZXQgPSB4ZW5fb3BzLmhvdHBsdWcocHIsIHR5cGUpOworCQl4ZW5fcGNw
dV9ob3RwbHVnKHR5cGUsIGFwaWNfaWQpOworCQlicmVhazsKKwl9CiAJZGVmYXVsdDoKIAkJcHJp
bnRrKEtFUk5fRVJSICJVbnN1cHBvcnQgcHJvY2Vzc29yIGV2ZW50cyAlZC5cbiIsIGV2ZW50KTsK
IAkJYnJlYWs7CkBAIC01MCw2ICs2OSw0OSBAQCBpbnQgcHJvY2Vzc29yX2NudGxfeGVuX25vdGlm
eShzdHJ1Y3QgYWNwaV9wcm9jZXNzb3IgKnByLCBpbnQgZXZlbnQsIGludCB0eXBlKQogfQogRVhQ
T1JUX1NZTUJPTChwcm9jZXNzb3JfY250bF94ZW5fbm90aWZ5KTsKIAorI2lmZGVmIENPTkZJR19B
Q1BJX0hPVFBMVUdfQ1BVCitzdGF0aWMgaW50IHhlbl9nZXRfYXBpY19pZChhY3BpX2hhbmRsZSBo
YW5kbGUpCit7CisJc3RydWN0IGFjcGlfYnVmZmVyIGJ1ZmZlciA9IHsgQUNQSV9BTExPQ0FURV9C
VUZGRVIsIE5VTEwgfTsKKwl1bmlvbiBhY3BpX29iamVjdCAqb2JqOworCXN0cnVjdCBhY3BpX21h
ZHRfbG9jYWxfYXBpYyAqbGFwaWM7CisJdTggcGh5c2lkOworCisJaWYgKEFDUElfRkFJTFVSRShh
Y3BpX2V2YWx1YXRlX29iamVjdChoYW5kbGUsICJfTUFUIiwgTlVMTCwgJmJ1ZmZlcikpKQorCQly
ZXR1cm4gLUVJTlZBTDsKKworCWlmICghYnVmZmVyLmxlbmd0aCB8fCAhYnVmZmVyLnBvaW50ZXIp
CisJCXJldHVybiAtRUlOVkFMOworCisJb2JqID0gYnVmZmVyLnBvaW50ZXI7CisJaWYgKG9iai0+
dHlwZSAhPSBBQ1BJX1RZUEVfQlVGRkVSIHx8CisJICAgIG9iai0+YnVmZmVyLmxlbmd0aCA8IHNp
emVvZigqbGFwaWMpKSB7CisJCWtmcmVlKGJ1ZmZlci5wb2ludGVyKTsKKwkJcmV0dXJuIC1FSU5W
QUw7CisJfQorCisJbGFwaWMgPSAoc3RydWN0IGFjcGlfbWFkdF9sb2NhbF9hcGljICopb2JqLT5i
dWZmZXIucG9pbnRlcjsKKworCWlmIChsYXBpYy0+aGVhZGVyLnR5cGUgIT0gQUNQSV9NQURUX1RZ
UEVfTE9DQUxfQVBJQyB8fAorCSAgICAhKGxhcGljLT5sYXBpY19mbGFncyAmIEFDUElfTUFEVF9F
TkFCTEVEKSkgeworCQlrZnJlZShidWZmZXIucG9pbnRlcik7CisJCXJldHVybiAtRUlOVkFMOwor
CX0KKworCXBoeXNpZCA9IGxhcGljLT5pZDsKKwlrZnJlZShidWZmZXIucG9pbnRlcik7CisJYnVm
ZmVyLmxlbmd0aCA9IEFDUElfQUxMT0NBVEVfQlVGRkVSOworCWJ1ZmZlci5wb2ludGVyID0gTlVM
TDsKKworCXJldHVybiBwaHlzaWQ7Cit9CisjZWxzZQorc3RhdGljIGludCB4ZW5fZ2V0X2FwaWNf
aWQoYWNwaV9oYW5kbGUgaGFuZGxlKQoreworCXJldHVybiAtMTsKK30KKyNlbmRpZgorCiBzdGF0
aWMgaW5saW5lIHZvaWQgeGVuX2NvbnZlcnRfcGN0X3JlZyhzdHJ1Y3QgeGVuX3BjdF9yZWdpc3Rl
ciAqeHBjdCwKIAlzdHJ1Y3QgYWNwaV9wY3RfcmVnaXN0ZXIgKmFwY3QpCiB7CkBAIC0yNDYsNiAr
MzA4LDU2IEBAIHN0YXRpYyBpbnQgeGVuX3B4X25vdGlmaWVyKHN0cnVjdCBhY3BpX3Byb2Nlc3Nv
ciAqcHIsIGludCBhY3Rpb24pCiAJcmV0dXJuIHJldDsKIH0KIAorI2lmZGVmIENPTkZJR19BQ1BJ
X0hPVFBMVUdfQ1BVCitzdGF0aWMgaW50IHhlbl9jcHVfaG90cGx1Z19ub3RpZmllcihzdHJ1Y3Qg
YWNwaV9wcm9jZXNzb3IgKnByLCBpbnQgZXZlbnQpCit7CisJaW50IHJldCA9IC1FSU5WQUw7CisJ
dWludDMyX3QgYXBpY19pZDsKKwl1bnNpZ25lZCBsb25nIGxvbmcgcHhtOworCWFjcGlfc3RhdHVz
IHN0YXR1cyA9IDA7CisKKwl4ZW5fcGxhdGZvcm1fb3BfdCBvcCA9IHsKKwkJLmludGVyZmFjZV92
ZXJzaW9uICA9IFhFTlBGX0lOVEVSRkFDRV9WRVJTSU9OLAorCX07CisKKwlhcGljX2lkID0geGVu
X2dldF9hcGljX2lkKHByLT5oYW5kbGUpOworCWlmIChhcGljX2lkIDwgMCkgeworCQlwcmludGso
S0VSTl9XQVJOSU5HICJDYW4ndCBnZXQgYXBpY19pZCBmb3IgYWNwaV9pZCAleFxuIiwKKwkJICBw
ci0+YWNwaV9pZCk7CisJCXJldHVybiAtMTsKKwl9CisKKwlzdGF0dXMgPSBhY3BpX2V2YWx1YXRl
X2ludGVnZXIocHItPmhhbmRsZSwgIl9QWE0iLAorCSAgTlVMTCwgJnB4bSk7CisJaWYgKEFDUElf
RkFJTFVSRShzdGF0dXMpKSB7CisJCXByaW50ayhLRVJOX1dBUk5JTkcgImNhbid0IGdldCBweG0g
Zm9yIGFjcGlfaWQgJXhcbiIsCisJCSAgcHItPmFjcGlfaWQpOworCQlyZXR1cm4gLTE7CisJfQor
CisJc3dpdGNoIChldmVudCkgeworCWNhc2UgSE9UUExVR19UWVBFX0FERDoKKwkJb3AuY21kID0g
WEVOUEZfY3B1X2hvdGFkZDsKKwkJb3AudS5jcHVfYWRkLmFwaWNfaWQgPSBhcGljX2lkOworCQlv
cC51LmNwdV9hZGQuYWNwaV9pZCA9IHByLT5hY3BpX2lkOworCQlvcC51LmNwdV9hZGQucHhtID0g
cHhtOworCQlyZXQgPSBIWVBFUlZJU09SX2RvbTBfb3AoJm9wKTsKKwkJYnJlYWs7CisJY2FzZSBI
T1RQTFVHX1RZUEVfUkVNT1ZFOgorCQlwcmludGsoS0VSTl9XQVJOSU5HICJYZW4gbm90IHN1cHBv
cnQgQ1BVIGhvdHJlbW92ZVxuIik7CisJCXJldCA9IC1FTk9TWVM7CisJCWJyZWFrOworCX0KKwor
CXJldHVybiByZXQ7Cit9CisjZWxzZQorc3RhdGljIGludCB4ZW5fY3B1X2hvdHBsdWdfbm90aWZp
ZXIoc3RydWN0IGFjcGlfcHJvY2Vzc29yICpwciwgaW50IGV2ZW50KQoreworCXJldHVybiAtRU5P
U1lTOworfQorI2VuZGlmCisKIHN0YXRpYyBpbnQgX19pbml0IHhlbl9hY3BpX3Byb2Nlc3Nvcl9l
eHRjbnRsX2luaXQodm9pZCkKIHsKIAl1bnNpZ25lZCBpbnQgcG1iaXRzOwpkaWZmIC0tZ2l0IGEv
aW5jbHVkZS94ZW4vaW50ZXJmYWNlL3BsYXRmb3JtLmggYi9pbmNsdWRlL3hlbi9pbnRlcmZhY2Uv
cGxhdGZvcm0uaAppbmRleCA0N2ZmZTE2Li45ZmQ2YjA3IDEwMDY0NAotLS0gYS9pbmNsdWRlL3hl
bi9pbnRlcmZhY2UvcGxhdGZvcm0uaAorKysgYi9pbmNsdWRlL3hlbi9pbnRlcmZhY2UvcGxhdGZv
cm0uaApAQCAtMzE3LDExICszMTcsMTggQEAgREVGSU5FX0dVRVNUX0hBTkRMRV9TVFJVQ1QoeGVu
cGZfcGNwdWluZm9fdCk7CiAjZGVmaW5lIFhFTlBGX2NwdV9vbmxpbmUgICAgNTYKICNkZWZpbmUg
WEVOUEZfY3B1X29mZmxpbmUgICA1Nwogc3RydWN0IHhlbnBmX2NwdV9vbCB7Ci0gICAgdWludDMy
X3QgY3B1aWQ7CisJdWludDMyX3QgY3B1aWQ7CiB9OwogdHlwZWRlZiBzdHJ1Y3QgeGVucGZfY3B1
X29sIHhlbnBmX2NwdV9vbF90OwogREVGSU5FX0dVRVNUX0hBTkRMRV9TVFJVQ1QoeGVucGZfY3B1
X29sX3QpOwogCisjZGVmaW5lIFhFTlBGX2NwdV9ob3RhZGQgICAgNTgKK3N0cnVjdCB4ZW5wZl9j
cHVfaG90YWRkIHsKKwl1aW50MzJfdCBhcGljX2lkOworCXVpbnQzMl90IGFjcGlfaWQ7CisJdWlu
dDMyX3QgcHhtOworfTsKKwogc3RydWN0IHhlbl9wbGF0Zm9ybV9vcCB7CiAJdWludDMyX3QgY21k
OwogCXVpbnQzMl90IGludGVyZmFjZV92ZXJzaW9uOyAvKiBYRU5QRl9JTlRFUkZBQ0VfVkVSU0lP
TiAqLwpAQCAtMzM5LDYgKzM0Niw3IEBAIHN0cnVjdCB4ZW5fcGxhdGZvcm1fb3AgewogCQlzdHJ1
Y3QgeGVucGZfc2V0X3Byb2Nlc3Nvcl9wbWluZm8gc2V0X3BtaW5mbzsKIAkJc3RydWN0IHhlbnBm
X3BjcHVpbmZvICAgICAgICAgIHBjcHVfaW5mbzsKIAkJc3RydWN0IHhlbnBmX2NwdV9vbCAgICAg
ICAgICAgIGNwdV9vbDsKKwkJc3RydWN0IHhlbnBmX2NwdV9ob3RhZGQgICAgICAgIGNwdV9hZGQ7
CiAJCXVpbnQ4X3QgICAgICAgICAgICAgICAgICAgICAgICBwYWRbMTI4XTsKIAl9IHU7CiB9Owot
LSAKMS42LjUuNgoK

--_002_DE8DF0795D48FD4CA783C40EC829233596DCSHSMSX101ccrcorpint_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--_002_DE8DF0795D48FD4CA783C40EC829233596DCSHSMSX101ccrcorpint_--


From xen-devel-bounces@lists.xensource.com Fri Dec 23 10:27:54 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 Dec 2011 10:27:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Re2Ld-0006MR-Lb; Fri, 23 Dec 2011 10:27:33 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1Re2Lc-0006Le-DQ
	for xen-devel@lists.xensource.com; Fri, 23 Dec 2011 10:27:32 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1324636045!8574670!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDMwMjM5MQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16048 invoked from network); 23 Dec 2011 10:27:25 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-9.tower-216.messagelabs.com with SMTP;
	23 Dec 2011 10:27:25 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga101.fm.intel.com with ESMTP; 23 Dec 2011 02:27:24 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208,223";a="99638726"
Received: from pgsmsx603.gar.corp.intel.com ([10.221.43.87])
	by fmsmga001.fm.intel.com with ESMTP; 23 Dec 2011 02:27:23 -0800
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	pgsmsx603.gar.corp.intel.com (10.221.43.87) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Fri, 23 Dec 2011 18:27:22 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.38]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.199]) with mapi id
	14.01.0355.002; Fri, 23 Dec 2011 18:27:20 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: "konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
Thread-Topic: [PATCH 05/10] xen/acpi: Move acpi_memory_info definition to
	public
Thread-Index: AczBXXLv8KWJMOqiSJa6QDuEP8Oy2g==
Date: Fri, 23 Dec 2011 10:27:19 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC829233596F0@SHSMSX101.ccr.corp.intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
Content-Type: multipart/mixed;
	boundary="_002_DE8DF0795D48FD4CA783C40EC829233596F0SHSMSX101ccrcorpint_"
MIME-Version: 1.0
Cc: "Brown, Len" <len.brown@intel.com>,
	"jeremy.fitzhardinge@citrix.com" <jeremy.fitzhardinge@citrix.com>,
	"Jiang, Yunhong" <yunhong.jiang@intel.com>, "Shan, 
	Haitao" <haitao.shan@intel.com>,
	Kernel development list <linux-kernel@vger.kernel.org>, "Zhao,
	Yakui" <yakui.zhao@intel.com>, "Luck, Tony" <tony.luck@intel.com>, "Kleen,
	Andi" <andi.kleen@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: [Xen-devel] [PATCH 05/10] xen/acpi: Move acpi_memory_info
	definition to public
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--_002_DE8DF0795D48FD4CA783C40EC829233596F0SHSMSX101ccrcorpint_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

>From 0172b1ce6a2ba70e739f968622d78ac1796813f9 Mon Sep 17 00:00:00 2001
From: Liu Jinsong <jinsong.liu@intel.com>
Date: Sun, 11 Dec 2011 17:25:35 +0800
Subject: [PATCH 05/10] xen/acpi: Move acpi_memory_info definition to public

This patch rebased from Jeremy's pvops commit
359e747e6260f105f750657917e1dc75f6427602

Move this definition to header file so that it can be used by dom0
memory hotadd logic also.

Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
Signed-off-by: Jiang, Yunhong <yunhong.jiang@intel.com>
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
---
 drivers/acpi/acpi_memhotplug.c |   15 ---------------
 include/acpi/acpi_drivers.h    |   21 +++++++++++++++++++++
 2 files changed, 21 insertions(+), 15 deletions(-)

diff --git a/drivers/acpi/acpi_memhotplug.c b/drivers/acpi/acpi_memhotplug.=
c
index d985713..e28e64d 100644
--- a/drivers/acpi/acpi_memhotplug.c
+++ b/drivers/acpi/acpi_memhotplug.c
@@ -71,21 +71,6 @@ static struct acpi_driver acpi_memory_device_driver =3D =
{
 		},
 };
=20
-struct acpi_memory_info {
-	struct list_head list;
-	u64 start_addr;		/* Memory Range start physical addr */
-	u64 length;		/* Memory Range length */
-	unsigned short caching;	/* memory cache attribute */
-	unsigned short write_protect;	/* memory read/write attribute */
-	unsigned int enabled:1;
-};
-
-struct acpi_memory_device {
-	struct acpi_device * device;
-	unsigned int state;	/* State of the memory device */
-	struct list_head res_list;
-};
-
 static int acpi_hotmem_initialized;
=20
 static acpi_status
diff --git a/include/acpi/acpi_drivers.h b/include/acpi/acpi_drivers.h
index e49c36d..833de75 100644
--- a/include/acpi/acpi_drivers.h
+++ b/include/acpi/acpi_drivers.h
@@ -154,4 +154,25 @@ static inline void unregister_hotplug_dock_device(acpi=
_handle handle)
 }
 #endif
=20
+/*------------------------------------------------------------------------=
--
+                                Memory
+  ------------------------------------------------------------------------=
-- */
+#if defined(CONFIG_ACPI_HOTPLUG_MEMORY) || \
+        defined(CONFIG_ACPI_HOTPLUG_MEMORY_MODULE)
+struct acpi_memory_info {
+        struct list_head list;
+        u64 start_addr;         /* Memory Range start physical addr */
+        u64 length;             /* Memory Range length */
+        unsigned short caching; /* memory cache attribute */
+        unsigned short write_protect;   /* memory read/write attribute */
+        unsigned int enabled:1;
+};
+
+struct acpi_memory_device {
+        struct acpi_device *device;
+        unsigned int state;     /* State of the memory device */
+        struct list_head res_list;
+};
+#endif
+
 #endif /*__ACPI_DRIVERS_H__*/
--=20
1.6.5.6

--_002_DE8DF0795D48FD4CA783C40EC829233596F0SHSMSX101ccrcorpint_
Content-Type: application/octet-stream;
	name="0005-xen-acpi-Move-acpi_memory_info-definition-to-public.patch"
Content-Description: 0005-xen-acpi-Move-acpi_memory_info-definition-to-public.patch
Content-Disposition: attachment;
	filename="0005-xen-acpi-Move-acpi_memory_info-definition-to-public.patch";
	size=2702; creation-date="Wed, 14 Dec 2011 15:20:15 GMT";
	modification-date="Wed, 14 Dec 2011 15:03:34 GMT"
Content-Transfer-Encoding: base64

RnJvbSAwMTcyYjFjZTZhMmJhNzBlNzM5Zjk2ODYyMmQ3OGFjMTc5NjgxM2Y5IE1vbiBTZXAgMTcg
MDA6MDA6MDAgMjAwMQpGcm9tOiBMaXUgSmluc29uZyA8amluc29uZy5saXVAaW50ZWwuY29tPgpE
YXRlOiBTdW4sIDExIERlYyAyMDExIDE3OjI1OjM1ICswODAwClN1YmplY3Q6IFtQQVRDSCAwNS8x
MF0geGVuL2FjcGk6IE1vdmUgYWNwaV9tZW1vcnlfaW5mbyBkZWZpbml0aW9uIHRvIHB1YmxpYwoK
VGhpcyBwYXRjaCByZWJhc2VkIGZyb20gSmVyZW15J3MgcHZvcHMgY29tbWl0CjM1OWU3NDdlNjI2
MGYxMDVmNzUwNjU3OTE3ZTFkYzc1ZjY0Mjc2MDIKCk1vdmUgdGhpcyBkZWZpbml0aW9uIHRvIGhl
YWRlciBmaWxlIHNvIHRoYXQgaXQgY2FuIGJlIHVzZWQgYnkgZG9tMAptZW1vcnkgaG90YWRkIGxv
Z2ljIGFsc28uCgpTaWduZWQtb2ZmLWJ5OiBMaXUsIEppbnNvbmcgPGppbnNvbmcubGl1QGludGVs
LmNvbT4KU2lnbmVkLW9mZi1ieTogSmlhbmcsIFl1bmhvbmcgPHl1bmhvbmcuamlhbmdAaW50ZWwu
Y29tPgpTaWduZWQtb2ZmLWJ5OiBKZXJlbXkgRml0emhhcmRpbmdlIDxqZXJlbXkuZml0emhhcmRp
bmdlQGNpdHJpeC5jb20+Ci0tLQogZHJpdmVycy9hY3BpL2FjcGlfbWVtaG90cGx1Zy5jIHwgICAx
NSAtLS0tLS0tLS0tLS0tLS0KIGluY2x1ZGUvYWNwaS9hY3BpX2RyaXZlcnMuaCAgICB8ICAgMjEg
KysrKysrKysrKysrKysrKysrKysrCiAyIGZpbGVzIGNoYW5nZWQsIDIxIGluc2VydGlvbnMoKyks
IDE1IGRlbGV0aW9ucygtKQoKZGlmZiAtLWdpdCBhL2RyaXZlcnMvYWNwaS9hY3BpX21lbWhvdHBs
dWcuYyBiL2RyaXZlcnMvYWNwaS9hY3BpX21lbWhvdHBsdWcuYwppbmRleCBkOTg1NzEzLi5lMjhl
NjRkIDEwMDY0NAotLS0gYS9kcml2ZXJzL2FjcGkvYWNwaV9tZW1ob3RwbHVnLmMKKysrIGIvZHJp
dmVycy9hY3BpL2FjcGlfbWVtaG90cGx1Zy5jCkBAIC03MSwyMSArNzEsNiBAQCBzdGF0aWMgc3Ry
dWN0IGFjcGlfZHJpdmVyIGFjcGlfbWVtb3J5X2RldmljZV9kcml2ZXIgPSB7CiAJCX0sCiB9Owog
Ci1zdHJ1Y3QgYWNwaV9tZW1vcnlfaW5mbyB7Ci0Jc3RydWN0IGxpc3RfaGVhZCBsaXN0OwotCXU2
NCBzdGFydF9hZGRyOwkJLyogTWVtb3J5IFJhbmdlIHN0YXJ0IHBoeXNpY2FsIGFkZHIgKi8KLQl1
NjQgbGVuZ3RoOwkJLyogTWVtb3J5IFJhbmdlIGxlbmd0aCAqLwotCXVuc2lnbmVkIHNob3J0IGNh
Y2hpbmc7CS8qIG1lbW9yeSBjYWNoZSBhdHRyaWJ1dGUgKi8KLQl1bnNpZ25lZCBzaG9ydCB3cml0
ZV9wcm90ZWN0OwkvKiBtZW1vcnkgcmVhZC93cml0ZSBhdHRyaWJ1dGUgKi8KLQl1bnNpZ25lZCBp
bnQgZW5hYmxlZDoxOwotfTsKLQotc3RydWN0IGFjcGlfbWVtb3J5X2RldmljZSB7Ci0Jc3RydWN0
IGFjcGlfZGV2aWNlICogZGV2aWNlOwotCXVuc2lnbmVkIGludCBzdGF0ZTsJLyogU3RhdGUgb2Yg
dGhlIG1lbW9yeSBkZXZpY2UgKi8KLQlzdHJ1Y3QgbGlzdF9oZWFkIHJlc19saXN0OwotfTsKLQog
c3RhdGljIGludCBhY3BpX2hvdG1lbV9pbml0aWFsaXplZDsKIAogc3RhdGljIGFjcGlfc3RhdHVz
CmRpZmYgLS1naXQgYS9pbmNsdWRlL2FjcGkvYWNwaV9kcml2ZXJzLmggYi9pbmNsdWRlL2FjcGkv
YWNwaV9kcml2ZXJzLmgKaW5kZXggZTQ5YzM2ZC4uODMzZGU3NSAxMDA2NDQKLS0tIGEvaW5jbHVk
ZS9hY3BpL2FjcGlfZHJpdmVycy5oCisrKyBiL2luY2x1ZGUvYWNwaS9hY3BpX2RyaXZlcnMuaApA
QCAtMTU0LDQgKzE1NCwyNSBAQCBzdGF0aWMgaW5saW5lIHZvaWQgdW5yZWdpc3Rlcl9ob3RwbHVn
X2RvY2tfZGV2aWNlKGFjcGlfaGFuZGxlIGhhbmRsZSkKIH0KICNlbmRpZgogCisvKi0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIE1lbW9yeQorICAtLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLSAqLworI2lmIGRlZmluZWQoQ09ORklHX0FDUElfSE9UUExVR19NRU1PUlkp
IHx8IFwKKyAgICAgICAgZGVmaW5lZChDT05GSUdfQUNQSV9IT1RQTFVHX01FTU9SWV9NT0RVTEUp
CitzdHJ1Y3QgYWNwaV9tZW1vcnlfaW5mbyB7CisgICAgICAgIHN0cnVjdCBsaXN0X2hlYWQgbGlz
dDsKKyAgICAgICAgdTY0IHN0YXJ0X2FkZHI7ICAgICAgICAgLyogTWVtb3J5IFJhbmdlIHN0YXJ0
IHBoeXNpY2FsIGFkZHIgKi8KKyAgICAgICAgdTY0IGxlbmd0aDsgICAgICAgICAgICAgLyogTWVt
b3J5IFJhbmdlIGxlbmd0aCAqLworICAgICAgICB1bnNpZ25lZCBzaG9ydCBjYWNoaW5nOyAvKiBt
ZW1vcnkgY2FjaGUgYXR0cmlidXRlICovCisgICAgICAgIHVuc2lnbmVkIHNob3J0IHdyaXRlX3By
b3RlY3Q7ICAgLyogbWVtb3J5IHJlYWQvd3JpdGUgYXR0cmlidXRlICovCisgICAgICAgIHVuc2ln
bmVkIGludCBlbmFibGVkOjE7Cit9OworCitzdHJ1Y3QgYWNwaV9tZW1vcnlfZGV2aWNlIHsKKyAg
ICAgICAgc3RydWN0IGFjcGlfZGV2aWNlICpkZXZpY2U7CisgICAgICAgIHVuc2lnbmVkIGludCBz
dGF0ZTsgICAgIC8qIFN0YXRlIG9mIHRoZSBtZW1vcnkgZGV2aWNlICovCisgICAgICAgIHN0cnVj
dCBsaXN0X2hlYWQgcmVzX2xpc3Q7Cit9OworI2VuZGlmCisKICNlbmRpZiAvKl9fQUNQSV9EUklW
RVJTX0hfXyovCi0tIAoxLjYuNS42Cgo=

--_002_DE8DF0795D48FD4CA783C40EC829233596F0SHSMSX101ccrcorpint_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--_002_DE8DF0795D48FD4CA783C40EC829233596F0SHSMSX101ccrcorpint_--


From xen-devel-bounces@lists.xensource.com Fri Dec 23 10:27:54 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 Dec 2011 10:27:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Re2Ld-0006MR-Lb; Fri, 23 Dec 2011 10:27:33 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1Re2Lc-0006Le-DQ
	for xen-devel@lists.xensource.com; Fri, 23 Dec 2011 10:27:32 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1324636045!8574670!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDMwMjM5MQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16048 invoked from network); 23 Dec 2011 10:27:25 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-9.tower-216.messagelabs.com with SMTP;
	23 Dec 2011 10:27:25 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga101.fm.intel.com with ESMTP; 23 Dec 2011 02:27:24 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208,223";a="99638726"
Received: from pgsmsx603.gar.corp.intel.com ([10.221.43.87])
	by fmsmga001.fm.intel.com with ESMTP; 23 Dec 2011 02:27:23 -0800
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	pgsmsx603.gar.corp.intel.com (10.221.43.87) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Fri, 23 Dec 2011 18:27:22 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.38]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.199]) with mapi id
	14.01.0355.002; Fri, 23 Dec 2011 18:27:20 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: "konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
Thread-Topic: [PATCH 05/10] xen/acpi: Move acpi_memory_info definition to
	public
Thread-Index: AczBXXLv8KWJMOqiSJa6QDuEP8Oy2g==
Date: Fri, 23 Dec 2011 10:27:19 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC829233596F0@SHSMSX101.ccr.corp.intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
Content-Type: multipart/mixed;
	boundary="_002_DE8DF0795D48FD4CA783C40EC829233596F0SHSMSX101ccrcorpint_"
MIME-Version: 1.0
Cc: "Brown, Len" <len.brown@intel.com>,
	"jeremy.fitzhardinge@citrix.com" <jeremy.fitzhardinge@citrix.com>,
	"Jiang, Yunhong" <yunhong.jiang@intel.com>, "Shan, 
	Haitao" <haitao.shan@intel.com>,
	Kernel development list <linux-kernel@vger.kernel.org>, "Zhao,
	Yakui" <yakui.zhao@intel.com>, "Luck, Tony" <tony.luck@intel.com>, "Kleen,
	Andi" <andi.kleen@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: [Xen-devel] [PATCH 05/10] xen/acpi: Move acpi_memory_info
	definition to public
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--_002_DE8DF0795D48FD4CA783C40EC829233596F0SHSMSX101ccrcorpint_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

>From 0172b1ce6a2ba70e739f968622d78ac1796813f9 Mon Sep 17 00:00:00 2001
From: Liu Jinsong <jinsong.liu@intel.com>
Date: Sun, 11 Dec 2011 17:25:35 +0800
Subject: [PATCH 05/10] xen/acpi: Move acpi_memory_info definition to public

This patch rebased from Jeremy's pvops commit
359e747e6260f105f750657917e1dc75f6427602

Move this definition to header file so that it can be used by dom0
memory hotadd logic also.

Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
Signed-off-by: Jiang, Yunhong <yunhong.jiang@intel.com>
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
---
 drivers/acpi/acpi_memhotplug.c |   15 ---------------
 include/acpi/acpi_drivers.h    |   21 +++++++++++++++++++++
 2 files changed, 21 insertions(+), 15 deletions(-)

diff --git a/drivers/acpi/acpi_memhotplug.c b/drivers/acpi/acpi_memhotplug.=
c
index d985713..e28e64d 100644
--- a/drivers/acpi/acpi_memhotplug.c
+++ b/drivers/acpi/acpi_memhotplug.c
@@ -71,21 +71,6 @@ static struct acpi_driver acpi_memory_device_driver =3D =
{
 		},
 };
=20
-struct acpi_memory_info {
-	struct list_head list;
-	u64 start_addr;		/* Memory Range start physical addr */
-	u64 length;		/* Memory Range length */
-	unsigned short caching;	/* memory cache attribute */
-	unsigned short write_protect;	/* memory read/write attribute */
-	unsigned int enabled:1;
-};
-
-struct acpi_memory_device {
-	struct acpi_device * device;
-	unsigned int state;	/* State of the memory device */
-	struct list_head res_list;
-};
-
 static int acpi_hotmem_initialized;
=20
 static acpi_status
diff --git a/include/acpi/acpi_drivers.h b/include/acpi/acpi_drivers.h
index e49c36d..833de75 100644
--- a/include/acpi/acpi_drivers.h
+++ b/include/acpi/acpi_drivers.h
@@ -154,4 +154,25 @@ static inline void unregister_hotplug_dock_device(acpi=
_handle handle)
 }
 #endif
=20
+/*------------------------------------------------------------------------=
--
+                                Memory
+  ------------------------------------------------------------------------=
-- */
+#if defined(CONFIG_ACPI_HOTPLUG_MEMORY) || \
+        defined(CONFIG_ACPI_HOTPLUG_MEMORY_MODULE)
+struct acpi_memory_info {
+        struct list_head list;
+        u64 start_addr;         /* Memory Range start physical addr */
+        u64 length;             /* Memory Range length */
+        unsigned short caching; /* memory cache attribute */
+        unsigned short write_protect;   /* memory read/write attribute */
+        unsigned int enabled:1;
+};
+
+struct acpi_memory_device {
+        struct acpi_device *device;
+        unsigned int state;     /* State of the memory device */
+        struct list_head res_list;
+};
+#endif
+
 #endif /*__ACPI_DRIVERS_H__*/
--=20
1.6.5.6

--_002_DE8DF0795D48FD4CA783C40EC829233596F0SHSMSX101ccrcorpint_
Content-Type: application/octet-stream;
	name="0005-xen-acpi-Move-acpi_memory_info-definition-to-public.patch"
Content-Description: 0005-xen-acpi-Move-acpi_memory_info-definition-to-public.patch
Content-Disposition: attachment;
	filename="0005-xen-acpi-Move-acpi_memory_info-definition-to-public.patch";
	size=2702; creation-date="Wed, 14 Dec 2011 15:20:15 GMT";
	modification-date="Wed, 14 Dec 2011 15:03:34 GMT"
Content-Transfer-Encoding: base64

RnJvbSAwMTcyYjFjZTZhMmJhNzBlNzM5Zjk2ODYyMmQ3OGFjMTc5NjgxM2Y5IE1vbiBTZXAgMTcg
MDA6MDA6MDAgMjAwMQpGcm9tOiBMaXUgSmluc29uZyA8amluc29uZy5saXVAaW50ZWwuY29tPgpE
YXRlOiBTdW4sIDExIERlYyAyMDExIDE3OjI1OjM1ICswODAwClN1YmplY3Q6IFtQQVRDSCAwNS8x
MF0geGVuL2FjcGk6IE1vdmUgYWNwaV9tZW1vcnlfaW5mbyBkZWZpbml0aW9uIHRvIHB1YmxpYwoK
VGhpcyBwYXRjaCByZWJhc2VkIGZyb20gSmVyZW15J3MgcHZvcHMgY29tbWl0CjM1OWU3NDdlNjI2
MGYxMDVmNzUwNjU3OTE3ZTFkYzc1ZjY0Mjc2MDIKCk1vdmUgdGhpcyBkZWZpbml0aW9uIHRvIGhl
YWRlciBmaWxlIHNvIHRoYXQgaXQgY2FuIGJlIHVzZWQgYnkgZG9tMAptZW1vcnkgaG90YWRkIGxv
Z2ljIGFsc28uCgpTaWduZWQtb2ZmLWJ5OiBMaXUsIEppbnNvbmcgPGppbnNvbmcubGl1QGludGVs
LmNvbT4KU2lnbmVkLW9mZi1ieTogSmlhbmcsIFl1bmhvbmcgPHl1bmhvbmcuamlhbmdAaW50ZWwu
Y29tPgpTaWduZWQtb2ZmLWJ5OiBKZXJlbXkgRml0emhhcmRpbmdlIDxqZXJlbXkuZml0emhhcmRp
bmdlQGNpdHJpeC5jb20+Ci0tLQogZHJpdmVycy9hY3BpL2FjcGlfbWVtaG90cGx1Zy5jIHwgICAx
NSAtLS0tLS0tLS0tLS0tLS0KIGluY2x1ZGUvYWNwaS9hY3BpX2RyaXZlcnMuaCAgICB8ICAgMjEg
KysrKysrKysrKysrKysrKysrKysrCiAyIGZpbGVzIGNoYW5nZWQsIDIxIGluc2VydGlvbnMoKyks
IDE1IGRlbGV0aW9ucygtKQoKZGlmZiAtLWdpdCBhL2RyaXZlcnMvYWNwaS9hY3BpX21lbWhvdHBs
dWcuYyBiL2RyaXZlcnMvYWNwaS9hY3BpX21lbWhvdHBsdWcuYwppbmRleCBkOTg1NzEzLi5lMjhl
NjRkIDEwMDY0NAotLS0gYS9kcml2ZXJzL2FjcGkvYWNwaV9tZW1ob3RwbHVnLmMKKysrIGIvZHJp
dmVycy9hY3BpL2FjcGlfbWVtaG90cGx1Zy5jCkBAIC03MSwyMSArNzEsNiBAQCBzdGF0aWMgc3Ry
dWN0IGFjcGlfZHJpdmVyIGFjcGlfbWVtb3J5X2RldmljZV9kcml2ZXIgPSB7CiAJCX0sCiB9Owog
Ci1zdHJ1Y3QgYWNwaV9tZW1vcnlfaW5mbyB7Ci0Jc3RydWN0IGxpc3RfaGVhZCBsaXN0OwotCXU2
NCBzdGFydF9hZGRyOwkJLyogTWVtb3J5IFJhbmdlIHN0YXJ0IHBoeXNpY2FsIGFkZHIgKi8KLQl1
NjQgbGVuZ3RoOwkJLyogTWVtb3J5IFJhbmdlIGxlbmd0aCAqLwotCXVuc2lnbmVkIHNob3J0IGNh
Y2hpbmc7CS8qIG1lbW9yeSBjYWNoZSBhdHRyaWJ1dGUgKi8KLQl1bnNpZ25lZCBzaG9ydCB3cml0
ZV9wcm90ZWN0OwkvKiBtZW1vcnkgcmVhZC93cml0ZSBhdHRyaWJ1dGUgKi8KLQl1bnNpZ25lZCBp
bnQgZW5hYmxlZDoxOwotfTsKLQotc3RydWN0IGFjcGlfbWVtb3J5X2RldmljZSB7Ci0Jc3RydWN0
IGFjcGlfZGV2aWNlICogZGV2aWNlOwotCXVuc2lnbmVkIGludCBzdGF0ZTsJLyogU3RhdGUgb2Yg
dGhlIG1lbW9yeSBkZXZpY2UgKi8KLQlzdHJ1Y3QgbGlzdF9oZWFkIHJlc19saXN0OwotfTsKLQog
c3RhdGljIGludCBhY3BpX2hvdG1lbV9pbml0aWFsaXplZDsKIAogc3RhdGljIGFjcGlfc3RhdHVz
CmRpZmYgLS1naXQgYS9pbmNsdWRlL2FjcGkvYWNwaV9kcml2ZXJzLmggYi9pbmNsdWRlL2FjcGkv
YWNwaV9kcml2ZXJzLmgKaW5kZXggZTQ5YzM2ZC4uODMzZGU3NSAxMDA2NDQKLS0tIGEvaW5jbHVk
ZS9hY3BpL2FjcGlfZHJpdmVycy5oCisrKyBiL2luY2x1ZGUvYWNwaS9hY3BpX2RyaXZlcnMuaApA
QCAtMTU0LDQgKzE1NCwyNSBAQCBzdGF0aWMgaW5saW5lIHZvaWQgdW5yZWdpc3Rlcl9ob3RwbHVn
X2RvY2tfZGV2aWNlKGFjcGlfaGFuZGxlIGhhbmRsZSkKIH0KICNlbmRpZgogCisvKi0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIE1lbW9yeQorICAtLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLSAqLworI2lmIGRlZmluZWQoQ09ORklHX0FDUElfSE9UUExVR19NRU1PUlkp
IHx8IFwKKyAgICAgICAgZGVmaW5lZChDT05GSUdfQUNQSV9IT1RQTFVHX01FTU9SWV9NT0RVTEUp
CitzdHJ1Y3QgYWNwaV9tZW1vcnlfaW5mbyB7CisgICAgICAgIHN0cnVjdCBsaXN0X2hlYWQgbGlz
dDsKKyAgICAgICAgdTY0IHN0YXJ0X2FkZHI7ICAgICAgICAgLyogTWVtb3J5IFJhbmdlIHN0YXJ0
IHBoeXNpY2FsIGFkZHIgKi8KKyAgICAgICAgdTY0IGxlbmd0aDsgICAgICAgICAgICAgLyogTWVt
b3J5IFJhbmdlIGxlbmd0aCAqLworICAgICAgICB1bnNpZ25lZCBzaG9ydCBjYWNoaW5nOyAvKiBt
ZW1vcnkgY2FjaGUgYXR0cmlidXRlICovCisgICAgICAgIHVuc2lnbmVkIHNob3J0IHdyaXRlX3By
b3RlY3Q7ICAgLyogbWVtb3J5IHJlYWQvd3JpdGUgYXR0cmlidXRlICovCisgICAgICAgIHVuc2ln
bmVkIGludCBlbmFibGVkOjE7Cit9OworCitzdHJ1Y3QgYWNwaV9tZW1vcnlfZGV2aWNlIHsKKyAg
ICAgICAgc3RydWN0IGFjcGlfZGV2aWNlICpkZXZpY2U7CisgICAgICAgIHVuc2lnbmVkIGludCBz
dGF0ZTsgICAgIC8qIFN0YXRlIG9mIHRoZSBtZW1vcnkgZGV2aWNlICovCisgICAgICAgIHN0cnVj
dCBsaXN0X2hlYWQgcmVzX2xpc3Q7Cit9OworI2VuZGlmCisKICNlbmRpZiAvKl9fQUNQSV9EUklW
RVJTX0hfXyovCi0tIAoxLjYuNS42Cgo=

--_002_DE8DF0795D48FD4CA783C40EC829233596F0SHSMSX101ccrcorpint_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--_002_DE8DF0795D48FD4CA783C40EC829233596F0SHSMSX101ccrcorpint_--


From xen-devel-bounces@lists.xensource.com Fri Dec 23 10:28:58 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 Dec 2011 10:28:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Re2Mm-0006ZF-62; Fri, 23 Dec 2011 10:28:44 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1Re2Mj-0006YM-KK
	for xen-devel@lists.xensource.com; Fri, 23 Dec 2011 10:28:42 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1324636113!8558543!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDMwMDk1NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29118 invoked from network); 23 Dec 2011 10:28:34 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-7.tower-216.messagelabs.com with SMTP;
	23 Dec 2011 10:28:34 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga102.fm.intel.com with ESMTP; 23 Dec 2011 02:28:28 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208,223";a="99638929"
Received: from pgsmsx603.gar.corp.intel.com ([10.221.43.87])
	by fmsmga001.fm.intel.com with ESMTP; 23 Dec 2011 02:28:27 -0800
Received: from pgsmsx102.gar.corp.intel.com (10.221.44.80) by
	pgsmsx603.gar.corp.intel.com (10.221.43.87) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Fri, 23 Dec 2011 18:28:24 +0800
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	PGSMSX102.gar.corp.intel.com (10.221.44.80) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Fri, 23 Dec 2011 18:28:23 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.38]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.223]) with mapi id
	14.01.0355.002; Fri, 23 Dec 2011 18:28:22 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: "konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
Thread-Topic: [PATCH 06/10] Xen: Add memory hotadd to pvops dom0
Thread-Index: AczBXZgPyRTMl0D9SUWZHviROKw3OQ==
Date: Fri, 23 Dec 2011 10:28:21 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC82923359700@SHSMSX101.ccr.corp.intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
Content-Type: multipart/mixed;
	boundary="_002_DE8DF0795D48FD4CA783C40EC82923359700SHSMSX101ccrcorpint_"
MIME-Version: 1.0
Cc: "Brown, Len" <len.brown@intel.com>,
	"jeremy.fitzhardinge@citrix.com" <jeremy.fitzhardinge@citrix.com>,
	"Jiang, Yunhong" <yunhong.jiang@intel.com>, "Shan, 
	Haitao" <haitao.shan@intel.com>,
	Kernel development list <linux-kernel@vger.kernel.org>, "Zhao,
	Yakui" <yakui.zhao@intel.com>, "Luck, Tony" <tony.luck@intel.com>, "Kleen,
	Andi" <andi.kleen@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: [Xen-devel] [PATCH 06/10] Xen: Add memory hotadd to pvops dom0
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--_002_DE8DF0795D48FD4CA783C40EC82923359700SHSMSX101ccrcorpint_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

>From a5d21e2a01049eef6aa64406e71f6574e7a371c1 Mon Sep 17 00:00:00 2001
From: Liu Jinsong <jinsong.liu@intel.com>
Date: Sun, 11 Dec 2011 21:51:28 +0800
Subject: [PATCH 06/10] Xen: Add memory hotadd to pvops dom0

This patch rebased from Jeremy's pvops commit
fe3cb1ebf78399fd5176ff6aa1c9ab498f2d8bd7

When memory hotadd event happen, a Xen hook will be called, to notify
hypervisor of the new added memory.

Because xen hypervisor will use the new memory to setup frametable/m2p
table, so dom0 will always return success to acpi bios, and notify xen
hypervisor later.

It add a hook in driver/acpi/acpi_memhotplug.c, but that change is
quite small, not sure if it is acceptable. Other method is to provide
a xen specific acpi_memory_device_driver, but I'm not sure if it worth
to add so much changes, to simply avoid two hooks.

Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
Signed-off-by: Jiang, Yunhong <yunhong.jiang@intel.com>
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
---
 drivers/acpi/acpi_memhotplug.c    |    4 +
 drivers/xen/Makefile              |    1 +
 drivers/xen/xen_acpi_memhotplug.c |  209 +++++++++++++++++++++++++++++++++=
++++
 include/xen/acpi.h                |    5 +
 include/xen/interface/platform.h  |    9 ++
 5 files changed, 228 insertions(+), 0 deletions(-)
 create mode 100644 drivers/xen/xen_acpi_memhotplug.c

diff --git a/drivers/acpi/acpi_memhotplug.c b/drivers/acpi/acpi_memhotplug.=
c
index e28e64d..2f2169e 100644
--- a/drivers/acpi/acpi_memhotplug.c
+++ b/drivers/acpi/acpi_memhotplug.c
@@ -32,6 +32,7 @@
 #include <linux/memory_hotplug.h>
 #include <linux/slab.h>
 #include <acpi/acpi_drivers.h>
+#include <xen/acpi.h>
=20
 #define ACPI_MEMORY_DEVICE_CLASS		"memory"
 #define ACPI_MEMORY_DEVICE_HID			"PNP0C80"
@@ -214,6 +215,9 @@ static int acpi_memory_enable_device(struct acpi_memory=
_device *mem_device)
 		return result;
 	}
=20
+	if (xen_initial_domain())
+		return xen_hotadd_memory(mem_device);
+
 	node =3D acpi_get_node(mem_device->device->handle);
 	/*
 	 * Tell the VM there is more memory here...
diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
index aedaf48..7dc3c0b 100644
--- a/drivers/xen/Makefile
+++ b/drivers/xen/Makefile
@@ -20,6 +20,7 @@ obj-$(CONFIG_XEN_TMEM)			+=3D tmem.o
 obj-$(CONFIG_SWIOTLB_XEN)		+=3D swiotlb-xen.o
 obj-$(CONFIG_XEN_DOM0)			+=3D pci.o acpi.o
 obj-$(CONFIG_XEN_PCIDEV_BACKEND)	+=3D xen-pciback/
+obj-$(CONFIG_ACPI_HOTPLUG_MEMORY)	+=3D xen_acpi_memhotplug.o
 ifdef CONFIG_ACPI_PROCESSOR_XEN
 obj-$(CONFIG_ACPI_PROCESSOR)		+=3D acpi_processor.o
 endif
diff --git a/drivers/xen/xen_acpi_memhotplug.c b/drivers/xen/xen_acpi_memho=
tplug.c
new file mode 100644
index 0000000..0c4af99
--- /dev/null
+++ b/drivers/xen/xen_acpi_memhotplug.c
@@ -0,0 +1,209 @@
+/*
+ *  xen_acpi_memhotplug.c - interface to notify Xen on memory device hotad=
d
+ *
+ *  Copyright (C) 2008, Intel corporation
+ *
+ * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~=
~~~
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License as published by
+ *  the Free Software Foundation; either version 2 of the License, or (at
+ *  your option) any later version.
+ *
+ *  This program is distributed in the hope that it will be useful, but
+ *  WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ *  General Public License for more details.
+ *
+ *  You should have received a copy of the GNU General Public License alon=
g
+ *  with this program; if not, write to the Free Software Foundation, Inc.=
,
+ *  59 Temple Place, Suite 330, Boston, MA 02111-1307 USA.
+ *
+ */
+
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/init.h>
+#include <linux/types.h>
+#include <linux/memory_hotplug.h>
+#include <acpi/acpi_drivers.h>
+#include <xen/interface/platform.h>
+#include <linux/interrupt.h>
+#include <linux/spinlock.h>
+#include <asm/xen/hypervisor.h>
+#include <asm/xen/hypercall.h>
+#include <xen/acpi.h>
+
+struct xen_hotmem_entry {
+	struct list_head hotmem_list;
+	uint64_t start;
+	uint64_t end;
+	uint32_t flags;
+	uint32_t pxm;
+};
+
+struct xen_hotmem_list {
+	struct list_head list;
+	int entry_nr;
+} xen_hotmem;
+
+DEFINE_SPINLOCK(xen_hotmem_lock);
+
+static int xen_hyper_addmem(struct xen_hotmem_entry *entry)
+{
+	int ret;
+
+	xen_platform_op_t op =3D {
+		.cmd            =3D XENPF_mem_hotadd,
+		.interface_version  =3D XENPF_INTERFACE_VERSION,
+	};
+	op.u.mem_add.spfn =3D entry->start >> PAGE_SHIFT;
+	op.u.mem_add.epfn =3D entry->end >> PAGE_SHIFT;
+	op.u.mem_add.flags =3D entry->flags;
+	op.u.mem_add.pxm =3D entry->pxm;
+
+	ret =3D HYPERVISOR_dom0_op(&op);
+	return ret;
+}
+
+static int add_hotmem_entry(int pxm, uint64_t start,
+			uint64_t length, uint32_t flags)
+{
+	struct xen_hotmem_entry *entry;
+
+	if (pxm < 0 || !length)
+		return -EINVAL;
+
+	entry =3D kzalloc(sizeof(struct xen_hotmem_entry), GFP_ATOMIC);
+	if (!entry)
+		return -ENOMEM;
+
+	INIT_LIST_HEAD(&entry->hotmem_list);
+	entry->start =3D start;
+	entry->end =3D start + length;
+	entry->flags =3D flags;
+	entry->pxm =3D pxm;
+
+	spin_lock(&xen_hotmem_lock);
+
+	list_add_tail(&entry->hotmem_list, &xen_hotmem.list);
+	xen_hotmem.entry_nr++;
+
+	spin_unlock(&xen_hotmem_lock);
+
+	return 0;
+}
+
+static int free_hotmem_entry(struct xen_hotmem_entry *entry)
+{
+	list_del(&entry->hotmem_list);
+	kfree(entry);
+
+	return 0;
+}
+
+static void xen_hotadd_mem_dpc(struct work_struct *work)
+{
+	struct list_head *elem, *tmp;
+	struct xen_hotmem_entry *entry;
+	unsigned long flags;
+	int ret;
+
+	spin_lock_irqsave(&xen_hotmem_lock, flags);
+	list_for_each_safe(elem, tmp, &xen_hotmem.list) {
+		entry =3D list_entry(elem, struct xen_hotmem_entry, hotmem_list);
+		ret =3D xen_hyper_addmem(entry);
+		if (ret)
+			printk(KERN_WARNING "xen addmem failed with %x\n", ret);
+		free_hotmem_entry(entry);
+		xen_hotmem.entry_nr--;
+	}
+	spin_unlock_irqrestore(&xen_hotmem_lock, flags);
+}
+
+static DECLARE_WORK(xen_hotadd_mem_work, xen_hotadd_mem_dpc);
+
+static int xen_acpi_get_pxm(acpi_handle h)
+{
+	unsigned long long pxm;
+	acpi_status status;
+	acpi_handle handle;
+	acpi_handle phandle =3D h;
+
+	do {
+		handle =3D phandle;
+		status =3D acpi_evaluate_integer(handle, "_PXM", NULL, &pxm);
+		if (ACPI_SUCCESS(status))
+			return pxm;
+		status =3D acpi_get_parent(handle, &phandle);
+	} while (ACPI_SUCCESS(status));
+
+	return -1;
+}
+
+int xen_hotadd_memory(struct acpi_memory_device *mem_device)
+{
+	int pxm, result;
+	int num_enabled =3D 0;
+	struct acpi_memory_info *info;
+
+	if (!mem_device)
+		return -EINVAL;
+
+	pxm =3D xen_acpi_get_pxm(mem_device->device->handle);
+
+	if (pxm < 0)
+		return -EINVAL;
+
+	/*
+	 * Always return success to ACPI driver, and notify hypervisor later
+	 * because hypervisor will utilize the memory in memory hotadd hypercall
+	 */
+	list_for_each_entry(info, &mem_device->res_list, list) {
+		if (info->enabled) { /* just sanity check...*/
+			num_enabled++;
+			continue;
+		}
+		/*
+		 * If the memory block size is zero, please ignore it.
+		 * Don't try to do the following memory hotplug flowchart.
+		 */
+		if (!info->length)
+			continue;
+
+		result =3D add_hotmem_entry(pxm, info->start_addr,
+					info->length, 0);
+		if (result)
+			continue;
+		info->enabled =3D 1;
+		num_enabled++;
+	}
+
+	if (!num_enabled)
+		return -EINVAL;
+
+	schedule_work(&xen_hotadd_mem_work);
+
+	return 0;
+}
+EXPORT_SYMBOL(xen_hotadd_memory);
+
+static int xen_hotadd_mem_init(void)
+{
+	if (!xen_initial_domain())
+		return -ENODEV;
+
+	INIT_LIST_HEAD(&xen_hotmem.list);
+	xen_hotmem.entry_nr =3D 0;
+
+	return 0;
+}
+
+static void xen_hotadd_mem_exit(void)
+{
+	flush_scheduled_work();
+}
+
+module_init(xen_hotadd_mem_init);
+module_exit(xen_hotadd_mem_exit);
+MODULE_LICENSE("GPL");
diff --git a/include/xen/acpi.h b/include/xen/acpi.h
index 7aa282d..8b3462e 100644
--- a/include/xen/acpi.h
+++ b/include/xen/acpi.h
@@ -107,6 +107,11 @@ static inline int xen_acpi_processor_get_performance(s=
truct acpi_processor *pr)
 }
 #endif
=20
+#if defined(CONFIG_ACPI_HOTPLUG_MEMORY) || \
+defined(CONFIG_ACPI_HOTPLUG_MEMORY_MODULE)
+int xen_hotadd_memory(struct acpi_memory_device *mem_device);
+#endif
+
 #if defined(CONFIG_ACPI_PROCESSOR_XEN) || \
 defined(CONFIG_ACPI_PROCESSOR_XEN_MODULE)
=20
diff --git a/include/xen/interface/platform.h b/include/xen/interface/platf=
orm.h
index 9fd6b07..0787c68 100644
--- a/include/xen/interface/platform.h
+++ b/include/xen/interface/platform.h
@@ -329,6 +329,14 @@ struct xenpf_cpu_hotadd {
 	uint32_t pxm;
 };
=20
+#define XENPF_mem_hotadd    59
+struct xenpf_mem_hotadd {
+	uint64_t spfn;
+	uint64_t epfn;
+	uint32_t pxm;
+	uint32_t flags;
+};
+
 struct xen_platform_op {
 	uint32_t cmd;
 	uint32_t interface_version; /* XENPF_INTERFACE_VERSION */
@@ -347,6 +355,7 @@ struct xen_platform_op {
 		struct xenpf_pcpuinfo          pcpu_info;
 		struct xenpf_cpu_ol            cpu_ol;
 		struct xenpf_cpu_hotadd        cpu_add;
+		struct xenpf_mem_hotadd        mem_add;
 		uint8_t                        pad[128];
 	} u;
 };
--=20
1.6.5.6

--_002_DE8DF0795D48FD4CA783C40EC82923359700SHSMSX101ccrcorpint_
Content-Type: application/octet-stream;
	name="0006-Xen-Add-memory-hotadd-to-pvops-dom0.patch"
Content-Description: 0006-Xen-Add-memory-hotadd-to-pvops-dom0.patch
Content-Disposition: attachment;
	filename="0006-Xen-Add-memory-hotadd-to-pvops-dom0.patch"; size=9113;
	creation-date="Wed, 14 Dec 2011 15:20:15 GMT";
	modification-date="Wed, 14 Dec 2011 15:03:34 GMT"
Content-Transfer-Encoding: base64

RnJvbSBhNWQyMWUyYTAxMDQ5ZWVmNmFhNjQ0MDZlNzFmNjU3NGU3YTM3MWMxIE1vbiBTZXAgMTcg
MDA6MDA6MDAgMjAwMQpGcm9tOiBMaXUgSmluc29uZyA8amluc29uZy5saXVAaW50ZWwuY29tPgpE
YXRlOiBTdW4sIDExIERlYyAyMDExIDIxOjUxOjI4ICswODAwClN1YmplY3Q6IFtQQVRDSCAwNi8x
MF0gWGVuOiBBZGQgbWVtb3J5IGhvdGFkZCB0byBwdm9wcyBkb20wCgpUaGlzIHBhdGNoIHJlYmFz
ZWQgZnJvbSBKZXJlbXkncyBwdm9wcyBjb21taXQKZmUzY2IxZWJmNzgzOTlmZDUxNzZmZjZhYTFj
OWFiNDk4ZjJkOGJkNwoKV2hlbiBtZW1vcnkgaG90YWRkIGV2ZW50IGhhcHBlbiwgYSBYZW4gaG9v
ayB3aWxsIGJlIGNhbGxlZCwgdG8gbm90aWZ5Cmh5cGVydmlzb3Igb2YgdGhlIG5ldyBhZGRlZCBt
ZW1vcnkuCgpCZWNhdXNlIHhlbiBoeXBlcnZpc29yIHdpbGwgdXNlIHRoZSBuZXcgbWVtb3J5IHRv
IHNldHVwIGZyYW1ldGFibGUvbTJwCnRhYmxlLCBzbyBkb20wIHdpbGwgYWx3YXlzIHJldHVybiBz
dWNjZXNzIHRvIGFjcGkgYmlvcywgYW5kIG5vdGlmeSB4ZW4KaHlwZXJ2aXNvciBsYXRlci4KCkl0
IGFkZCBhIGhvb2sgaW4gZHJpdmVyL2FjcGkvYWNwaV9tZW1ob3RwbHVnLmMsIGJ1dCB0aGF0IGNo
YW5nZSBpcwpxdWl0ZSBzbWFsbCwgbm90IHN1cmUgaWYgaXQgaXMgYWNjZXB0YWJsZS4gT3RoZXIg
bWV0aG9kIGlzIHRvIHByb3ZpZGUKYSB4ZW4gc3BlY2lmaWMgYWNwaV9tZW1vcnlfZGV2aWNlX2Ry
aXZlciwgYnV0IEknbSBub3Qgc3VyZSBpZiBpdCB3b3J0aAp0byBhZGQgc28gbXVjaCBjaGFuZ2Vz
LCB0byBzaW1wbHkgYXZvaWQgdHdvIGhvb2tzLgoKU2lnbmVkLW9mZi1ieTogTGl1LCBKaW5zb25n
IDxqaW5zb25nLmxpdUBpbnRlbC5jb20+ClNpZ25lZC1vZmYtYnk6IEppYW5nLCBZdW5ob25nIDx5
dW5ob25nLmppYW5nQGludGVsLmNvbT4KU2lnbmVkLW9mZi1ieTogSmVyZW15IEZpdHpoYXJkaW5n
ZSA8amVyZW15LmZpdHpoYXJkaW5nZUBjaXRyaXguY29tPgotLS0KIGRyaXZlcnMvYWNwaS9hY3Bp
X21lbWhvdHBsdWcuYyAgICB8ICAgIDQgKwogZHJpdmVycy94ZW4vTWFrZWZpbGUgICAgICAgICAg
ICAgIHwgICAgMSArCiBkcml2ZXJzL3hlbi94ZW5fYWNwaV9tZW1ob3RwbHVnLmMgfCAgMjA5ICsr
KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysKIGluY2x1ZGUveGVuL2FjcGkuaCAg
ICAgICAgICAgICAgICB8ICAgIDUgKwogaW5jbHVkZS94ZW4vaW50ZXJmYWNlL3BsYXRmb3JtLmgg
IHwgICAgOSArKwogNSBmaWxlcyBjaGFuZ2VkLCAyMjggaW5zZXJ0aW9ucygrKSwgMCBkZWxldGlv
bnMoLSkKIGNyZWF0ZSBtb2RlIDEwMDY0NCBkcml2ZXJzL3hlbi94ZW5fYWNwaV9tZW1ob3RwbHVn
LmMKCmRpZmYgLS1naXQgYS9kcml2ZXJzL2FjcGkvYWNwaV9tZW1ob3RwbHVnLmMgYi9kcml2ZXJz
L2FjcGkvYWNwaV9tZW1ob3RwbHVnLmMKaW5kZXggZTI4ZTY0ZC4uMmYyMTY5ZSAxMDA2NDQKLS0t
IGEvZHJpdmVycy9hY3BpL2FjcGlfbWVtaG90cGx1Zy5jCisrKyBiL2RyaXZlcnMvYWNwaS9hY3Bp
X21lbWhvdHBsdWcuYwpAQCAtMzIsNiArMzIsNyBAQAogI2luY2x1ZGUgPGxpbnV4L21lbW9yeV9o
b3RwbHVnLmg+CiAjaW5jbHVkZSA8bGludXgvc2xhYi5oPgogI2luY2x1ZGUgPGFjcGkvYWNwaV9k
cml2ZXJzLmg+CisjaW5jbHVkZSA8eGVuL2FjcGkuaD4KIAogI2RlZmluZSBBQ1BJX01FTU9SWV9E
RVZJQ0VfQ0xBU1MJCSJtZW1vcnkiCiAjZGVmaW5lIEFDUElfTUVNT1JZX0RFVklDRV9ISUQJCQki
UE5QMEM4MCIKQEAgLTIxNCw2ICsyMTUsOSBAQCBzdGF0aWMgaW50IGFjcGlfbWVtb3J5X2VuYWJs
ZV9kZXZpY2Uoc3RydWN0IGFjcGlfbWVtb3J5X2RldmljZSAqbWVtX2RldmljZSkKIAkJcmV0dXJu
IHJlc3VsdDsKIAl9CiAKKwlpZiAoeGVuX2luaXRpYWxfZG9tYWluKCkpCisJCXJldHVybiB4ZW5f
aG90YWRkX21lbW9yeShtZW1fZGV2aWNlKTsKKwogCW5vZGUgPSBhY3BpX2dldF9ub2RlKG1lbV9k
ZXZpY2UtPmRldmljZS0+aGFuZGxlKTsKIAkvKgogCSAqIFRlbGwgdGhlIFZNIHRoZXJlIGlzIG1v
cmUgbWVtb3J5IGhlcmUuLi4KZGlmZiAtLWdpdCBhL2RyaXZlcnMveGVuL01ha2VmaWxlIGIvZHJp
dmVycy94ZW4vTWFrZWZpbGUKaW5kZXggYWVkYWY0OC4uN2RjM2MwYiAxMDA2NDQKLS0tIGEvZHJp
dmVycy94ZW4vTWFrZWZpbGUKKysrIGIvZHJpdmVycy94ZW4vTWFrZWZpbGUKQEAgLTIwLDYgKzIw
LDcgQEAgb2JqLSQoQ09ORklHX1hFTl9UTUVNKQkJCSs9IHRtZW0ubwogb2JqLSQoQ09ORklHX1NX
SU9UTEJfWEVOKQkJKz0gc3dpb3RsYi14ZW4ubwogb2JqLSQoQ09ORklHX1hFTl9ET00wKQkJCSs9
IHBjaS5vIGFjcGkubwogb2JqLSQoQ09ORklHX1hFTl9QQ0lERVZfQkFDS0VORCkJKz0geGVuLXBj
aWJhY2svCitvYmotJChDT05GSUdfQUNQSV9IT1RQTFVHX01FTU9SWSkJKz0geGVuX2FjcGlfbWVt
aG90cGx1Zy5vCiBpZmRlZiBDT05GSUdfQUNQSV9QUk9DRVNTT1JfWEVOCiBvYmotJChDT05GSUdf
QUNQSV9QUk9DRVNTT1IpCQkrPSBhY3BpX3Byb2Nlc3Nvci5vCiBlbmRpZgpkaWZmIC0tZ2l0IGEv
ZHJpdmVycy94ZW4veGVuX2FjcGlfbWVtaG90cGx1Zy5jIGIvZHJpdmVycy94ZW4veGVuX2FjcGlf
bWVtaG90cGx1Zy5jCm5ldyBmaWxlIG1vZGUgMTAwNjQ0CmluZGV4IDAwMDAwMDAuLjBjNGFmOTkK
LS0tIC9kZXYvbnVsbAorKysgYi9kcml2ZXJzL3hlbi94ZW5fYWNwaV9tZW1ob3RwbHVnLmMKQEAg
LTAsMCArMSwyMDkgQEAKKy8qCisgKiAgeGVuX2FjcGlfbWVtaG90cGx1Zy5jIC0gaW50ZXJmYWNl
IHRvIG5vdGlmeSBYZW4gb24gbWVtb3J5IGRldmljZSBob3RhZGQKKyAqCisgKiAgQ29weXJpZ2h0
IChDKSAyMDA4LCBJbnRlbCBjb3Jwb3JhdGlvbgorICoKKyAqIH5+fn5+fn5+fn5+fn5+fn5+fn5+
fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+Cisg
KgorICogIFRoaXMgcHJvZ3JhbSBpcyBmcmVlIHNvZnR3YXJlOyB5b3UgY2FuIHJlZGlzdHJpYnV0
ZSBpdCBhbmQvb3IgbW9kaWZ5CisgKiAgaXQgdW5kZXIgdGhlIHRlcm1zIG9mIHRoZSBHTlUgR2Vu
ZXJhbCBQdWJsaWMgTGljZW5zZSBhcyBwdWJsaXNoZWQgYnkKKyAqICB0aGUgRnJlZSBTb2Z0d2Fy
ZSBGb3VuZGF0aW9uOyBlaXRoZXIgdmVyc2lvbiAyIG9mIHRoZSBMaWNlbnNlLCBvciAoYXQKKyAq
ICB5b3VyIG9wdGlvbikgYW55IGxhdGVyIHZlcnNpb24uCisgKgorICogIFRoaXMgcHJvZ3JhbSBp
cyBkaXN0cmlidXRlZCBpbiB0aGUgaG9wZSB0aGF0IGl0IHdpbGwgYmUgdXNlZnVsLCBidXQKKyAq
ICBXSVRIT1VUIEFOWSBXQVJSQU5UWTsgd2l0aG91dCBldmVuIHRoZSBpbXBsaWVkIHdhcnJhbnR5
IG9mCisgKiAgTUVSQ0hBTlRBQklMSVRZIG9yIEZJVE5FU1MgRk9SIEEgUEFSVElDVUxBUiBQVVJQ
T1NFLiAgU2VlIHRoZSBHTlUKKyAqICBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlIGZvciBtb3JlIGRl
dGFpbHMuCisgKgorICogIFlvdSBzaG91bGQgaGF2ZSByZWNlaXZlZCBhIGNvcHkgb2YgdGhlIEdO
VSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlIGFsb25nCisgKiAgd2l0aCB0aGlzIHByb2dyYW07IGlm
IG5vdCwgd3JpdGUgdG8gdGhlIEZyZWUgU29mdHdhcmUgRm91bmRhdGlvbiwgSW5jLiwKKyAqICA1
OSBUZW1wbGUgUGxhY2UsIFN1aXRlIDMzMCwgQm9zdG9uLCBNQSAwMjExMS0xMzA3IFVTQS4KKyAq
CisgKi8KKworI2luY2x1ZGUgPGxpbnV4L2tlcm5lbC5oPgorI2luY2x1ZGUgPGxpbnV4L21vZHVs
ZS5oPgorI2luY2x1ZGUgPGxpbnV4L2luaXQuaD4KKyNpbmNsdWRlIDxsaW51eC90eXBlcy5oPgor
I2luY2x1ZGUgPGxpbnV4L21lbW9yeV9ob3RwbHVnLmg+CisjaW5jbHVkZSA8YWNwaS9hY3BpX2Ry
aXZlcnMuaD4KKyNpbmNsdWRlIDx4ZW4vaW50ZXJmYWNlL3BsYXRmb3JtLmg+CisjaW5jbHVkZSA8
bGludXgvaW50ZXJydXB0Lmg+CisjaW5jbHVkZSA8bGludXgvc3BpbmxvY2suaD4KKyNpbmNsdWRl
IDxhc20veGVuL2h5cGVydmlzb3IuaD4KKyNpbmNsdWRlIDxhc20veGVuL2h5cGVyY2FsbC5oPgor
I2luY2x1ZGUgPHhlbi9hY3BpLmg+CisKK3N0cnVjdCB4ZW5faG90bWVtX2VudHJ5IHsKKwlzdHJ1
Y3QgbGlzdF9oZWFkIGhvdG1lbV9saXN0OworCXVpbnQ2NF90IHN0YXJ0OworCXVpbnQ2NF90IGVu
ZDsKKwl1aW50MzJfdCBmbGFnczsKKwl1aW50MzJfdCBweG07Cit9OworCitzdHJ1Y3QgeGVuX2hv
dG1lbV9saXN0IHsKKwlzdHJ1Y3QgbGlzdF9oZWFkIGxpc3Q7CisJaW50IGVudHJ5X25yOworfSB4
ZW5faG90bWVtOworCitERUZJTkVfU1BJTkxPQ0soeGVuX2hvdG1lbV9sb2NrKTsKKworc3RhdGlj
IGludCB4ZW5faHlwZXJfYWRkbWVtKHN0cnVjdCB4ZW5faG90bWVtX2VudHJ5ICplbnRyeSkKK3sK
KwlpbnQgcmV0OworCisJeGVuX3BsYXRmb3JtX29wX3Qgb3AgPSB7CisJCS5jbWQgICAgICAgICAg
ICA9IFhFTlBGX21lbV9ob3RhZGQsCisJCS5pbnRlcmZhY2VfdmVyc2lvbiAgPSBYRU5QRl9JTlRF
UkZBQ0VfVkVSU0lPTiwKKwl9OworCW9wLnUubWVtX2FkZC5zcGZuID0gZW50cnktPnN0YXJ0ID4+
IFBBR0VfU0hJRlQ7CisJb3AudS5tZW1fYWRkLmVwZm4gPSBlbnRyeS0+ZW5kID4+IFBBR0VfU0hJ
RlQ7CisJb3AudS5tZW1fYWRkLmZsYWdzID0gZW50cnktPmZsYWdzOworCW9wLnUubWVtX2FkZC5w
eG0gPSBlbnRyeS0+cHhtOworCisJcmV0ID0gSFlQRVJWSVNPUl9kb20wX29wKCZvcCk7CisJcmV0
dXJuIHJldDsKK30KKworc3RhdGljIGludCBhZGRfaG90bWVtX2VudHJ5KGludCBweG0sIHVpbnQ2
NF90IHN0YXJ0LAorCQkJdWludDY0X3QgbGVuZ3RoLCB1aW50MzJfdCBmbGFncykKK3sKKwlzdHJ1
Y3QgeGVuX2hvdG1lbV9lbnRyeSAqZW50cnk7CisKKwlpZiAocHhtIDwgMCB8fCAhbGVuZ3RoKQor
CQlyZXR1cm4gLUVJTlZBTDsKKworCWVudHJ5ID0ga3phbGxvYyhzaXplb2Yoc3RydWN0IHhlbl9o
b3RtZW1fZW50cnkpLCBHRlBfQVRPTUlDKTsKKwlpZiAoIWVudHJ5KQorCQlyZXR1cm4gLUVOT01F
TTsKKworCUlOSVRfTElTVF9IRUFEKCZlbnRyeS0+aG90bWVtX2xpc3QpOworCWVudHJ5LT5zdGFy
dCA9IHN0YXJ0OworCWVudHJ5LT5lbmQgPSBzdGFydCArIGxlbmd0aDsKKwllbnRyeS0+ZmxhZ3Mg
PSBmbGFnczsKKwllbnRyeS0+cHhtID0gcHhtOworCisJc3Bpbl9sb2NrKCZ4ZW5faG90bWVtX2xv
Y2spOworCisJbGlzdF9hZGRfdGFpbCgmZW50cnktPmhvdG1lbV9saXN0LCAmeGVuX2hvdG1lbS5s
aXN0KTsKKwl4ZW5faG90bWVtLmVudHJ5X25yKys7CisKKwlzcGluX3VubG9jaygmeGVuX2hvdG1l
bV9sb2NrKTsKKworCXJldHVybiAwOworfQorCitzdGF0aWMgaW50IGZyZWVfaG90bWVtX2VudHJ5
KHN0cnVjdCB4ZW5faG90bWVtX2VudHJ5ICplbnRyeSkKK3sKKwlsaXN0X2RlbCgmZW50cnktPmhv
dG1lbV9saXN0KTsKKwlrZnJlZShlbnRyeSk7CisKKwlyZXR1cm4gMDsKK30KKworc3RhdGljIHZv
aWQgeGVuX2hvdGFkZF9tZW1fZHBjKHN0cnVjdCB3b3JrX3N0cnVjdCAqd29yaykKK3sKKwlzdHJ1
Y3QgbGlzdF9oZWFkICplbGVtLCAqdG1wOworCXN0cnVjdCB4ZW5faG90bWVtX2VudHJ5ICplbnRy
eTsKKwl1bnNpZ25lZCBsb25nIGZsYWdzOworCWludCByZXQ7CisKKwlzcGluX2xvY2tfaXJxc2F2
ZSgmeGVuX2hvdG1lbV9sb2NrLCBmbGFncyk7CisJbGlzdF9mb3JfZWFjaF9zYWZlKGVsZW0sIHRt
cCwgJnhlbl9ob3RtZW0ubGlzdCkgeworCQllbnRyeSA9IGxpc3RfZW50cnkoZWxlbSwgc3RydWN0
IHhlbl9ob3RtZW1fZW50cnksIGhvdG1lbV9saXN0KTsKKwkJcmV0ID0geGVuX2h5cGVyX2FkZG1l
bShlbnRyeSk7CisJCWlmIChyZXQpCisJCQlwcmludGsoS0VSTl9XQVJOSU5HICJ4ZW4gYWRkbWVt
IGZhaWxlZCB3aXRoICV4XG4iLCByZXQpOworCQlmcmVlX2hvdG1lbV9lbnRyeShlbnRyeSk7CisJ
CXhlbl9ob3RtZW0uZW50cnlfbnItLTsKKwl9CisJc3Bpbl91bmxvY2tfaXJxcmVzdG9yZSgmeGVu
X2hvdG1lbV9sb2NrLCBmbGFncyk7Cit9CisKK3N0YXRpYyBERUNMQVJFX1dPUksoeGVuX2hvdGFk
ZF9tZW1fd29yaywgeGVuX2hvdGFkZF9tZW1fZHBjKTsKKworc3RhdGljIGludCB4ZW5fYWNwaV9n
ZXRfcHhtKGFjcGlfaGFuZGxlIGgpCit7CisJdW5zaWduZWQgbG9uZyBsb25nIHB4bTsKKwlhY3Bp
X3N0YXR1cyBzdGF0dXM7CisJYWNwaV9oYW5kbGUgaGFuZGxlOworCWFjcGlfaGFuZGxlIHBoYW5k
bGUgPSBoOworCisJZG8geworCQloYW5kbGUgPSBwaGFuZGxlOworCQlzdGF0dXMgPSBhY3BpX2V2
YWx1YXRlX2ludGVnZXIoaGFuZGxlLCAiX1BYTSIsIE5VTEwsICZweG0pOworCQlpZiAoQUNQSV9T
VUNDRVNTKHN0YXR1cykpCisJCQlyZXR1cm4gcHhtOworCQlzdGF0dXMgPSBhY3BpX2dldF9wYXJl
bnQoaGFuZGxlLCAmcGhhbmRsZSk7CisJfSB3aGlsZSAoQUNQSV9TVUNDRVNTKHN0YXR1cykpOwor
CisJcmV0dXJuIC0xOworfQorCitpbnQgeGVuX2hvdGFkZF9tZW1vcnkoc3RydWN0IGFjcGlfbWVt
b3J5X2RldmljZSAqbWVtX2RldmljZSkKK3sKKwlpbnQgcHhtLCByZXN1bHQ7CisJaW50IG51bV9l
bmFibGVkID0gMDsKKwlzdHJ1Y3QgYWNwaV9tZW1vcnlfaW5mbyAqaW5mbzsKKworCWlmICghbWVt
X2RldmljZSkKKwkJcmV0dXJuIC1FSU5WQUw7CisKKwlweG0gPSB4ZW5fYWNwaV9nZXRfcHhtKG1l
bV9kZXZpY2UtPmRldmljZS0+aGFuZGxlKTsKKworCWlmIChweG0gPCAwKQorCQlyZXR1cm4gLUVJ
TlZBTDsKKworCS8qCisJICogQWx3YXlzIHJldHVybiBzdWNjZXNzIHRvIEFDUEkgZHJpdmVyLCBh
bmQgbm90aWZ5IGh5cGVydmlzb3IgbGF0ZXIKKwkgKiBiZWNhdXNlIGh5cGVydmlzb3Igd2lsbCB1
dGlsaXplIHRoZSBtZW1vcnkgaW4gbWVtb3J5IGhvdGFkZCBoeXBlcmNhbGwKKwkgKi8KKwlsaXN0
X2Zvcl9lYWNoX2VudHJ5KGluZm8sICZtZW1fZGV2aWNlLT5yZXNfbGlzdCwgbGlzdCkgeworCQlp
ZiAoaW5mby0+ZW5hYmxlZCkgeyAvKiBqdXN0IHNhbml0eSBjaGVjay4uLiovCisJCQludW1fZW5h
YmxlZCsrOworCQkJY29udGludWU7CisJCX0KKwkJLyoKKwkJICogSWYgdGhlIG1lbW9yeSBibG9j
ayBzaXplIGlzIHplcm8sIHBsZWFzZSBpZ25vcmUgaXQuCisJCSAqIERvbid0IHRyeSB0byBkbyB0
aGUgZm9sbG93aW5nIG1lbW9yeSBob3RwbHVnIGZsb3djaGFydC4KKwkJICovCisJCWlmICghaW5m
by0+bGVuZ3RoKQorCQkJY29udGludWU7CisKKwkJcmVzdWx0ID0gYWRkX2hvdG1lbV9lbnRyeShw
eG0sIGluZm8tPnN0YXJ0X2FkZHIsCisJCQkJCWluZm8tPmxlbmd0aCwgMCk7CisJCWlmIChyZXN1
bHQpCisJCQljb250aW51ZTsKKwkJaW5mby0+ZW5hYmxlZCA9IDE7CisJCW51bV9lbmFibGVkKys7
CisJfQorCisJaWYgKCFudW1fZW5hYmxlZCkKKwkJcmV0dXJuIC1FSU5WQUw7CisKKwlzY2hlZHVs
ZV93b3JrKCZ4ZW5faG90YWRkX21lbV93b3JrKTsKKworCXJldHVybiAwOworfQorRVhQT1JUX1NZ
TUJPTCh4ZW5faG90YWRkX21lbW9yeSk7CisKK3N0YXRpYyBpbnQgeGVuX2hvdGFkZF9tZW1faW5p
dCh2b2lkKQoreworCWlmICgheGVuX2luaXRpYWxfZG9tYWluKCkpCisJCXJldHVybiAtRU5PREVW
OworCisJSU5JVF9MSVNUX0hFQUQoJnhlbl9ob3RtZW0ubGlzdCk7CisJeGVuX2hvdG1lbS5lbnRy
eV9uciA9IDA7CisKKwlyZXR1cm4gMDsKK30KKworc3RhdGljIHZvaWQgeGVuX2hvdGFkZF9tZW1f
ZXhpdCh2b2lkKQoreworCWZsdXNoX3NjaGVkdWxlZF93b3JrKCk7Cit9CisKK21vZHVsZV9pbml0
KHhlbl9ob3RhZGRfbWVtX2luaXQpOworbW9kdWxlX2V4aXQoeGVuX2hvdGFkZF9tZW1fZXhpdCk7
CitNT0RVTEVfTElDRU5TRSgiR1BMIik7CmRpZmYgLS1naXQgYS9pbmNsdWRlL3hlbi9hY3BpLmgg
Yi9pbmNsdWRlL3hlbi9hY3BpLmgKaW5kZXggN2FhMjgyZC4uOGIzNDYyZSAxMDA2NDQKLS0tIGEv
aW5jbHVkZS94ZW4vYWNwaS5oCisrKyBiL2luY2x1ZGUveGVuL2FjcGkuaApAQCAtMTA3LDYgKzEw
NywxMSBAQCBzdGF0aWMgaW5saW5lIGludCB4ZW5fYWNwaV9wcm9jZXNzb3JfZ2V0X3BlcmZvcm1h
bmNlKHN0cnVjdCBhY3BpX3Byb2Nlc3NvciAqcHIpCiB9CiAjZW5kaWYKIAorI2lmIGRlZmluZWQo
Q09ORklHX0FDUElfSE9UUExVR19NRU1PUlkpIHx8IFwKK2RlZmluZWQoQ09ORklHX0FDUElfSE9U
UExVR19NRU1PUllfTU9EVUxFKQoraW50IHhlbl9ob3RhZGRfbWVtb3J5KHN0cnVjdCBhY3BpX21l
bW9yeV9kZXZpY2UgKm1lbV9kZXZpY2UpOworI2VuZGlmCisKICNpZiBkZWZpbmVkKENPTkZJR19B
Q1BJX1BST0NFU1NPUl9YRU4pIHx8IFwKIGRlZmluZWQoQ09ORklHX0FDUElfUFJPQ0VTU09SX1hF
Tl9NT0RVTEUpCiAKZGlmZiAtLWdpdCBhL2luY2x1ZGUveGVuL2ludGVyZmFjZS9wbGF0Zm9ybS5o
IGIvaW5jbHVkZS94ZW4vaW50ZXJmYWNlL3BsYXRmb3JtLmgKaW5kZXggOWZkNmIwNy4uMDc4N2M2
OCAxMDA2NDQKLS0tIGEvaW5jbHVkZS94ZW4vaW50ZXJmYWNlL3BsYXRmb3JtLmgKKysrIGIvaW5j
bHVkZS94ZW4vaW50ZXJmYWNlL3BsYXRmb3JtLmgKQEAgLTMyOSw2ICszMjksMTQgQEAgc3RydWN0
IHhlbnBmX2NwdV9ob3RhZGQgewogCXVpbnQzMl90IHB4bTsKIH07CiAKKyNkZWZpbmUgWEVOUEZf
bWVtX2hvdGFkZCAgICA1OQorc3RydWN0IHhlbnBmX21lbV9ob3RhZGQgeworCXVpbnQ2NF90IHNw
Zm47CisJdWludDY0X3QgZXBmbjsKKwl1aW50MzJfdCBweG07CisJdWludDMyX3QgZmxhZ3M7Cit9
OworCiBzdHJ1Y3QgeGVuX3BsYXRmb3JtX29wIHsKIAl1aW50MzJfdCBjbWQ7CiAJdWludDMyX3Qg
aW50ZXJmYWNlX3ZlcnNpb247IC8qIFhFTlBGX0lOVEVSRkFDRV9WRVJTSU9OICovCkBAIC0zNDcs
NiArMzU1LDcgQEAgc3RydWN0IHhlbl9wbGF0Zm9ybV9vcCB7CiAJCXN0cnVjdCB4ZW5wZl9wY3B1
aW5mbyAgICAgICAgICBwY3B1X2luZm87CiAJCXN0cnVjdCB4ZW5wZl9jcHVfb2wgICAgICAgICAg
ICBjcHVfb2w7CiAJCXN0cnVjdCB4ZW5wZl9jcHVfaG90YWRkICAgICAgICBjcHVfYWRkOworCQlz
dHJ1Y3QgeGVucGZfbWVtX2hvdGFkZCAgICAgICAgbWVtX2FkZDsKIAkJdWludDhfdCAgICAgICAg
ICAgICAgICAgICAgICAgIHBhZFsxMjhdOwogCX0gdTsKIH07Ci0tIAoxLjYuNS42Cgo=

--_002_DE8DF0795D48FD4CA783C40EC82923359700SHSMSX101ccrcorpint_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--_002_DE8DF0795D48FD4CA783C40EC82923359700SHSMSX101ccrcorpint_--


From xen-devel-bounces@lists.xensource.com Fri Dec 23 10:28:58 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 Dec 2011 10:28:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Re2Mm-0006ZF-62; Fri, 23 Dec 2011 10:28:44 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1Re2Mj-0006YM-KK
	for xen-devel@lists.xensource.com; Fri, 23 Dec 2011 10:28:42 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1324636113!8558543!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDMwMDk1NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29118 invoked from network); 23 Dec 2011 10:28:34 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-7.tower-216.messagelabs.com with SMTP;
	23 Dec 2011 10:28:34 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga102.fm.intel.com with ESMTP; 23 Dec 2011 02:28:28 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208,223";a="99638929"
Received: from pgsmsx603.gar.corp.intel.com ([10.221.43.87])
	by fmsmga001.fm.intel.com with ESMTP; 23 Dec 2011 02:28:27 -0800
Received: from pgsmsx102.gar.corp.intel.com (10.221.44.80) by
	pgsmsx603.gar.corp.intel.com (10.221.43.87) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Fri, 23 Dec 2011 18:28:24 +0800
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	PGSMSX102.gar.corp.intel.com (10.221.44.80) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Fri, 23 Dec 2011 18:28:23 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.38]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.223]) with mapi id
	14.01.0355.002; Fri, 23 Dec 2011 18:28:22 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: "konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
Thread-Topic: [PATCH 06/10] Xen: Add memory hotadd to pvops dom0
Thread-Index: AczBXZgPyRTMl0D9SUWZHviROKw3OQ==
Date: Fri, 23 Dec 2011 10:28:21 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC82923359700@SHSMSX101.ccr.corp.intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
Content-Type: multipart/mixed;
	boundary="_002_DE8DF0795D48FD4CA783C40EC82923359700SHSMSX101ccrcorpint_"
MIME-Version: 1.0
Cc: "Brown, Len" <len.brown@intel.com>,
	"jeremy.fitzhardinge@citrix.com" <jeremy.fitzhardinge@citrix.com>,
	"Jiang, Yunhong" <yunhong.jiang@intel.com>, "Shan, 
	Haitao" <haitao.shan@intel.com>,
	Kernel development list <linux-kernel@vger.kernel.org>, "Zhao,
	Yakui" <yakui.zhao@intel.com>, "Luck, Tony" <tony.luck@intel.com>, "Kleen,
	Andi" <andi.kleen@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: [Xen-devel] [PATCH 06/10] Xen: Add memory hotadd to pvops dom0
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--_002_DE8DF0795D48FD4CA783C40EC82923359700SHSMSX101ccrcorpint_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

>From a5d21e2a01049eef6aa64406e71f6574e7a371c1 Mon Sep 17 00:00:00 2001
From: Liu Jinsong <jinsong.liu@intel.com>
Date: Sun, 11 Dec 2011 21:51:28 +0800
Subject: [PATCH 06/10] Xen: Add memory hotadd to pvops dom0

This patch rebased from Jeremy's pvops commit
fe3cb1ebf78399fd5176ff6aa1c9ab498f2d8bd7

When memory hotadd event happen, a Xen hook will be called, to notify
hypervisor of the new added memory.

Because xen hypervisor will use the new memory to setup frametable/m2p
table, so dom0 will always return success to acpi bios, and notify xen
hypervisor later.

It add a hook in driver/acpi/acpi_memhotplug.c, but that change is
quite small, not sure if it is acceptable. Other method is to provide
a xen specific acpi_memory_device_driver, but I'm not sure if it worth
to add so much changes, to simply avoid two hooks.

Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
Signed-off-by: Jiang, Yunhong <yunhong.jiang@intel.com>
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
---
 drivers/acpi/acpi_memhotplug.c    |    4 +
 drivers/xen/Makefile              |    1 +
 drivers/xen/xen_acpi_memhotplug.c |  209 +++++++++++++++++++++++++++++++++=
++++
 include/xen/acpi.h                |    5 +
 include/xen/interface/platform.h  |    9 ++
 5 files changed, 228 insertions(+), 0 deletions(-)
 create mode 100644 drivers/xen/xen_acpi_memhotplug.c

diff --git a/drivers/acpi/acpi_memhotplug.c b/drivers/acpi/acpi_memhotplug.=
c
index e28e64d..2f2169e 100644
--- a/drivers/acpi/acpi_memhotplug.c
+++ b/drivers/acpi/acpi_memhotplug.c
@@ -32,6 +32,7 @@
 #include <linux/memory_hotplug.h>
 #include <linux/slab.h>
 #include <acpi/acpi_drivers.h>
+#include <xen/acpi.h>
=20
 #define ACPI_MEMORY_DEVICE_CLASS		"memory"
 #define ACPI_MEMORY_DEVICE_HID			"PNP0C80"
@@ -214,6 +215,9 @@ static int acpi_memory_enable_device(struct acpi_memory=
_device *mem_device)
 		return result;
 	}
=20
+	if (xen_initial_domain())
+		return xen_hotadd_memory(mem_device);
+
 	node =3D acpi_get_node(mem_device->device->handle);
 	/*
 	 * Tell the VM there is more memory here...
diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
index aedaf48..7dc3c0b 100644
--- a/drivers/xen/Makefile
+++ b/drivers/xen/Makefile
@@ -20,6 +20,7 @@ obj-$(CONFIG_XEN_TMEM)			+=3D tmem.o
 obj-$(CONFIG_SWIOTLB_XEN)		+=3D swiotlb-xen.o
 obj-$(CONFIG_XEN_DOM0)			+=3D pci.o acpi.o
 obj-$(CONFIG_XEN_PCIDEV_BACKEND)	+=3D xen-pciback/
+obj-$(CONFIG_ACPI_HOTPLUG_MEMORY)	+=3D xen_acpi_memhotplug.o
 ifdef CONFIG_ACPI_PROCESSOR_XEN
 obj-$(CONFIG_ACPI_PROCESSOR)		+=3D acpi_processor.o
 endif
diff --git a/drivers/xen/xen_acpi_memhotplug.c b/drivers/xen/xen_acpi_memho=
tplug.c
new file mode 100644
index 0000000..0c4af99
--- /dev/null
+++ b/drivers/xen/xen_acpi_memhotplug.c
@@ -0,0 +1,209 @@
+/*
+ *  xen_acpi_memhotplug.c - interface to notify Xen on memory device hotad=
d
+ *
+ *  Copyright (C) 2008, Intel corporation
+ *
+ * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~=
~~~
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License as published by
+ *  the Free Software Foundation; either version 2 of the License, or (at
+ *  your option) any later version.
+ *
+ *  This program is distributed in the hope that it will be useful, but
+ *  WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ *  General Public License for more details.
+ *
+ *  You should have received a copy of the GNU General Public License alon=
g
+ *  with this program; if not, write to the Free Software Foundation, Inc.=
,
+ *  59 Temple Place, Suite 330, Boston, MA 02111-1307 USA.
+ *
+ */
+
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/init.h>
+#include <linux/types.h>
+#include <linux/memory_hotplug.h>
+#include <acpi/acpi_drivers.h>
+#include <xen/interface/platform.h>
+#include <linux/interrupt.h>
+#include <linux/spinlock.h>
+#include <asm/xen/hypervisor.h>
+#include <asm/xen/hypercall.h>
+#include <xen/acpi.h>
+
+struct xen_hotmem_entry {
+	struct list_head hotmem_list;
+	uint64_t start;
+	uint64_t end;
+	uint32_t flags;
+	uint32_t pxm;
+};
+
+struct xen_hotmem_list {
+	struct list_head list;
+	int entry_nr;
+} xen_hotmem;
+
+DEFINE_SPINLOCK(xen_hotmem_lock);
+
+static int xen_hyper_addmem(struct xen_hotmem_entry *entry)
+{
+	int ret;
+
+	xen_platform_op_t op =3D {
+		.cmd            =3D XENPF_mem_hotadd,
+		.interface_version  =3D XENPF_INTERFACE_VERSION,
+	};
+	op.u.mem_add.spfn =3D entry->start >> PAGE_SHIFT;
+	op.u.mem_add.epfn =3D entry->end >> PAGE_SHIFT;
+	op.u.mem_add.flags =3D entry->flags;
+	op.u.mem_add.pxm =3D entry->pxm;
+
+	ret =3D HYPERVISOR_dom0_op(&op);
+	return ret;
+}
+
+static int add_hotmem_entry(int pxm, uint64_t start,
+			uint64_t length, uint32_t flags)
+{
+	struct xen_hotmem_entry *entry;
+
+	if (pxm < 0 || !length)
+		return -EINVAL;
+
+	entry =3D kzalloc(sizeof(struct xen_hotmem_entry), GFP_ATOMIC);
+	if (!entry)
+		return -ENOMEM;
+
+	INIT_LIST_HEAD(&entry->hotmem_list);
+	entry->start =3D start;
+	entry->end =3D start + length;
+	entry->flags =3D flags;
+	entry->pxm =3D pxm;
+
+	spin_lock(&xen_hotmem_lock);
+
+	list_add_tail(&entry->hotmem_list, &xen_hotmem.list);
+	xen_hotmem.entry_nr++;
+
+	spin_unlock(&xen_hotmem_lock);
+
+	return 0;
+}
+
+static int free_hotmem_entry(struct xen_hotmem_entry *entry)
+{
+	list_del(&entry->hotmem_list);
+	kfree(entry);
+
+	return 0;
+}
+
+static void xen_hotadd_mem_dpc(struct work_struct *work)
+{
+	struct list_head *elem, *tmp;
+	struct xen_hotmem_entry *entry;
+	unsigned long flags;
+	int ret;
+
+	spin_lock_irqsave(&xen_hotmem_lock, flags);
+	list_for_each_safe(elem, tmp, &xen_hotmem.list) {
+		entry =3D list_entry(elem, struct xen_hotmem_entry, hotmem_list);
+		ret =3D xen_hyper_addmem(entry);
+		if (ret)
+			printk(KERN_WARNING "xen addmem failed with %x\n", ret);
+		free_hotmem_entry(entry);
+		xen_hotmem.entry_nr--;
+	}
+	spin_unlock_irqrestore(&xen_hotmem_lock, flags);
+}
+
+static DECLARE_WORK(xen_hotadd_mem_work, xen_hotadd_mem_dpc);
+
+static int xen_acpi_get_pxm(acpi_handle h)
+{
+	unsigned long long pxm;
+	acpi_status status;
+	acpi_handle handle;
+	acpi_handle phandle =3D h;
+
+	do {
+		handle =3D phandle;
+		status =3D acpi_evaluate_integer(handle, "_PXM", NULL, &pxm);
+		if (ACPI_SUCCESS(status))
+			return pxm;
+		status =3D acpi_get_parent(handle, &phandle);
+	} while (ACPI_SUCCESS(status));
+
+	return -1;
+}
+
+int xen_hotadd_memory(struct acpi_memory_device *mem_device)
+{
+	int pxm, result;
+	int num_enabled =3D 0;
+	struct acpi_memory_info *info;
+
+	if (!mem_device)
+		return -EINVAL;
+
+	pxm =3D xen_acpi_get_pxm(mem_device->device->handle);
+
+	if (pxm < 0)
+		return -EINVAL;
+
+	/*
+	 * Always return success to ACPI driver, and notify hypervisor later
+	 * because hypervisor will utilize the memory in memory hotadd hypercall
+	 */
+	list_for_each_entry(info, &mem_device->res_list, list) {
+		if (info->enabled) { /* just sanity check...*/
+			num_enabled++;
+			continue;
+		}
+		/*
+		 * If the memory block size is zero, please ignore it.
+		 * Don't try to do the following memory hotplug flowchart.
+		 */
+		if (!info->length)
+			continue;
+
+		result =3D add_hotmem_entry(pxm, info->start_addr,
+					info->length, 0);
+		if (result)
+			continue;
+		info->enabled =3D 1;
+		num_enabled++;
+	}
+
+	if (!num_enabled)
+		return -EINVAL;
+
+	schedule_work(&xen_hotadd_mem_work);
+
+	return 0;
+}
+EXPORT_SYMBOL(xen_hotadd_memory);
+
+static int xen_hotadd_mem_init(void)
+{
+	if (!xen_initial_domain())
+		return -ENODEV;
+
+	INIT_LIST_HEAD(&xen_hotmem.list);
+	xen_hotmem.entry_nr =3D 0;
+
+	return 0;
+}
+
+static void xen_hotadd_mem_exit(void)
+{
+	flush_scheduled_work();
+}
+
+module_init(xen_hotadd_mem_init);
+module_exit(xen_hotadd_mem_exit);
+MODULE_LICENSE("GPL");
diff --git a/include/xen/acpi.h b/include/xen/acpi.h
index 7aa282d..8b3462e 100644
--- a/include/xen/acpi.h
+++ b/include/xen/acpi.h
@@ -107,6 +107,11 @@ static inline int xen_acpi_processor_get_performance(s=
truct acpi_processor *pr)
 }
 #endif
=20
+#if defined(CONFIG_ACPI_HOTPLUG_MEMORY) || \
+defined(CONFIG_ACPI_HOTPLUG_MEMORY_MODULE)
+int xen_hotadd_memory(struct acpi_memory_device *mem_device);
+#endif
+
 #if defined(CONFIG_ACPI_PROCESSOR_XEN) || \
 defined(CONFIG_ACPI_PROCESSOR_XEN_MODULE)
=20
diff --git a/include/xen/interface/platform.h b/include/xen/interface/platf=
orm.h
index 9fd6b07..0787c68 100644
--- a/include/xen/interface/platform.h
+++ b/include/xen/interface/platform.h
@@ -329,6 +329,14 @@ struct xenpf_cpu_hotadd {
 	uint32_t pxm;
 };
=20
+#define XENPF_mem_hotadd    59
+struct xenpf_mem_hotadd {
+	uint64_t spfn;
+	uint64_t epfn;
+	uint32_t pxm;
+	uint32_t flags;
+};
+
 struct xen_platform_op {
 	uint32_t cmd;
 	uint32_t interface_version; /* XENPF_INTERFACE_VERSION */
@@ -347,6 +355,7 @@ struct xen_platform_op {
 		struct xenpf_pcpuinfo          pcpu_info;
 		struct xenpf_cpu_ol            cpu_ol;
 		struct xenpf_cpu_hotadd        cpu_add;
+		struct xenpf_mem_hotadd        mem_add;
 		uint8_t                        pad[128];
 	} u;
 };
--=20
1.6.5.6

--_002_DE8DF0795D48FD4CA783C40EC82923359700SHSMSX101ccrcorpint_
Content-Type: application/octet-stream;
	name="0006-Xen-Add-memory-hotadd-to-pvops-dom0.patch"
Content-Description: 0006-Xen-Add-memory-hotadd-to-pvops-dom0.patch
Content-Disposition: attachment;
	filename="0006-Xen-Add-memory-hotadd-to-pvops-dom0.patch"; size=9113;
	creation-date="Wed, 14 Dec 2011 15:20:15 GMT";
	modification-date="Wed, 14 Dec 2011 15:03:34 GMT"
Content-Transfer-Encoding: base64

RnJvbSBhNWQyMWUyYTAxMDQ5ZWVmNmFhNjQ0MDZlNzFmNjU3NGU3YTM3MWMxIE1vbiBTZXAgMTcg
MDA6MDA6MDAgMjAwMQpGcm9tOiBMaXUgSmluc29uZyA8amluc29uZy5saXVAaW50ZWwuY29tPgpE
YXRlOiBTdW4sIDExIERlYyAyMDExIDIxOjUxOjI4ICswODAwClN1YmplY3Q6IFtQQVRDSCAwNi8x
MF0gWGVuOiBBZGQgbWVtb3J5IGhvdGFkZCB0byBwdm9wcyBkb20wCgpUaGlzIHBhdGNoIHJlYmFz
ZWQgZnJvbSBKZXJlbXkncyBwdm9wcyBjb21taXQKZmUzY2IxZWJmNzgzOTlmZDUxNzZmZjZhYTFj
OWFiNDk4ZjJkOGJkNwoKV2hlbiBtZW1vcnkgaG90YWRkIGV2ZW50IGhhcHBlbiwgYSBYZW4gaG9v
ayB3aWxsIGJlIGNhbGxlZCwgdG8gbm90aWZ5Cmh5cGVydmlzb3Igb2YgdGhlIG5ldyBhZGRlZCBt
ZW1vcnkuCgpCZWNhdXNlIHhlbiBoeXBlcnZpc29yIHdpbGwgdXNlIHRoZSBuZXcgbWVtb3J5IHRv
IHNldHVwIGZyYW1ldGFibGUvbTJwCnRhYmxlLCBzbyBkb20wIHdpbGwgYWx3YXlzIHJldHVybiBz
dWNjZXNzIHRvIGFjcGkgYmlvcywgYW5kIG5vdGlmeSB4ZW4KaHlwZXJ2aXNvciBsYXRlci4KCkl0
IGFkZCBhIGhvb2sgaW4gZHJpdmVyL2FjcGkvYWNwaV9tZW1ob3RwbHVnLmMsIGJ1dCB0aGF0IGNo
YW5nZSBpcwpxdWl0ZSBzbWFsbCwgbm90IHN1cmUgaWYgaXQgaXMgYWNjZXB0YWJsZS4gT3RoZXIg
bWV0aG9kIGlzIHRvIHByb3ZpZGUKYSB4ZW4gc3BlY2lmaWMgYWNwaV9tZW1vcnlfZGV2aWNlX2Ry
aXZlciwgYnV0IEknbSBub3Qgc3VyZSBpZiBpdCB3b3J0aAp0byBhZGQgc28gbXVjaCBjaGFuZ2Vz
LCB0byBzaW1wbHkgYXZvaWQgdHdvIGhvb2tzLgoKU2lnbmVkLW9mZi1ieTogTGl1LCBKaW5zb25n
IDxqaW5zb25nLmxpdUBpbnRlbC5jb20+ClNpZ25lZC1vZmYtYnk6IEppYW5nLCBZdW5ob25nIDx5
dW5ob25nLmppYW5nQGludGVsLmNvbT4KU2lnbmVkLW9mZi1ieTogSmVyZW15IEZpdHpoYXJkaW5n
ZSA8amVyZW15LmZpdHpoYXJkaW5nZUBjaXRyaXguY29tPgotLS0KIGRyaXZlcnMvYWNwaS9hY3Bp
X21lbWhvdHBsdWcuYyAgICB8ICAgIDQgKwogZHJpdmVycy94ZW4vTWFrZWZpbGUgICAgICAgICAg
ICAgIHwgICAgMSArCiBkcml2ZXJzL3hlbi94ZW5fYWNwaV9tZW1ob3RwbHVnLmMgfCAgMjA5ICsr
KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysKIGluY2x1ZGUveGVuL2FjcGkuaCAg
ICAgICAgICAgICAgICB8ICAgIDUgKwogaW5jbHVkZS94ZW4vaW50ZXJmYWNlL3BsYXRmb3JtLmgg
IHwgICAgOSArKwogNSBmaWxlcyBjaGFuZ2VkLCAyMjggaW5zZXJ0aW9ucygrKSwgMCBkZWxldGlv
bnMoLSkKIGNyZWF0ZSBtb2RlIDEwMDY0NCBkcml2ZXJzL3hlbi94ZW5fYWNwaV9tZW1ob3RwbHVn
LmMKCmRpZmYgLS1naXQgYS9kcml2ZXJzL2FjcGkvYWNwaV9tZW1ob3RwbHVnLmMgYi9kcml2ZXJz
L2FjcGkvYWNwaV9tZW1ob3RwbHVnLmMKaW5kZXggZTI4ZTY0ZC4uMmYyMTY5ZSAxMDA2NDQKLS0t
IGEvZHJpdmVycy9hY3BpL2FjcGlfbWVtaG90cGx1Zy5jCisrKyBiL2RyaXZlcnMvYWNwaS9hY3Bp
X21lbWhvdHBsdWcuYwpAQCAtMzIsNiArMzIsNyBAQAogI2luY2x1ZGUgPGxpbnV4L21lbW9yeV9o
b3RwbHVnLmg+CiAjaW5jbHVkZSA8bGludXgvc2xhYi5oPgogI2luY2x1ZGUgPGFjcGkvYWNwaV9k
cml2ZXJzLmg+CisjaW5jbHVkZSA8eGVuL2FjcGkuaD4KIAogI2RlZmluZSBBQ1BJX01FTU9SWV9E
RVZJQ0VfQ0xBU1MJCSJtZW1vcnkiCiAjZGVmaW5lIEFDUElfTUVNT1JZX0RFVklDRV9ISUQJCQki
UE5QMEM4MCIKQEAgLTIxNCw2ICsyMTUsOSBAQCBzdGF0aWMgaW50IGFjcGlfbWVtb3J5X2VuYWJs
ZV9kZXZpY2Uoc3RydWN0IGFjcGlfbWVtb3J5X2RldmljZSAqbWVtX2RldmljZSkKIAkJcmV0dXJu
IHJlc3VsdDsKIAl9CiAKKwlpZiAoeGVuX2luaXRpYWxfZG9tYWluKCkpCisJCXJldHVybiB4ZW5f
aG90YWRkX21lbW9yeShtZW1fZGV2aWNlKTsKKwogCW5vZGUgPSBhY3BpX2dldF9ub2RlKG1lbV9k
ZXZpY2UtPmRldmljZS0+aGFuZGxlKTsKIAkvKgogCSAqIFRlbGwgdGhlIFZNIHRoZXJlIGlzIG1v
cmUgbWVtb3J5IGhlcmUuLi4KZGlmZiAtLWdpdCBhL2RyaXZlcnMveGVuL01ha2VmaWxlIGIvZHJp
dmVycy94ZW4vTWFrZWZpbGUKaW5kZXggYWVkYWY0OC4uN2RjM2MwYiAxMDA2NDQKLS0tIGEvZHJp
dmVycy94ZW4vTWFrZWZpbGUKKysrIGIvZHJpdmVycy94ZW4vTWFrZWZpbGUKQEAgLTIwLDYgKzIw
LDcgQEAgb2JqLSQoQ09ORklHX1hFTl9UTUVNKQkJCSs9IHRtZW0ubwogb2JqLSQoQ09ORklHX1NX
SU9UTEJfWEVOKQkJKz0gc3dpb3RsYi14ZW4ubwogb2JqLSQoQ09ORklHX1hFTl9ET00wKQkJCSs9
IHBjaS5vIGFjcGkubwogb2JqLSQoQ09ORklHX1hFTl9QQ0lERVZfQkFDS0VORCkJKz0geGVuLXBj
aWJhY2svCitvYmotJChDT05GSUdfQUNQSV9IT1RQTFVHX01FTU9SWSkJKz0geGVuX2FjcGlfbWVt
aG90cGx1Zy5vCiBpZmRlZiBDT05GSUdfQUNQSV9QUk9DRVNTT1JfWEVOCiBvYmotJChDT05GSUdf
QUNQSV9QUk9DRVNTT1IpCQkrPSBhY3BpX3Byb2Nlc3Nvci5vCiBlbmRpZgpkaWZmIC0tZ2l0IGEv
ZHJpdmVycy94ZW4veGVuX2FjcGlfbWVtaG90cGx1Zy5jIGIvZHJpdmVycy94ZW4veGVuX2FjcGlf
bWVtaG90cGx1Zy5jCm5ldyBmaWxlIG1vZGUgMTAwNjQ0CmluZGV4IDAwMDAwMDAuLjBjNGFmOTkK
LS0tIC9kZXYvbnVsbAorKysgYi9kcml2ZXJzL3hlbi94ZW5fYWNwaV9tZW1ob3RwbHVnLmMKQEAg
LTAsMCArMSwyMDkgQEAKKy8qCisgKiAgeGVuX2FjcGlfbWVtaG90cGx1Zy5jIC0gaW50ZXJmYWNl
IHRvIG5vdGlmeSBYZW4gb24gbWVtb3J5IGRldmljZSBob3RhZGQKKyAqCisgKiAgQ29weXJpZ2h0
IChDKSAyMDA4LCBJbnRlbCBjb3Jwb3JhdGlvbgorICoKKyAqIH5+fn5+fn5+fn5+fn5+fn5+fn5+
fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+Cisg
KgorICogIFRoaXMgcHJvZ3JhbSBpcyBmcmVlIHNvZnR3YXJlOyB5b3UgY2FuIHJlZGlzdHJpYnV0
ZSBpdCBhbmQvb3IgbW9kaWZ5CisgKiAgaXQgdW5kZXIgdGhlIHRlcm1zIG9mIHRoZSBHTlUgR2Vu
ZXJhbCBQdWJsaWMgTGljZW5zZSBhcyBwdWJsaXNoZWQgYnkKKyAqICB0aGUgRnJlZSBTb2Z0d2Fy
ZSBGb3VuZGF0aW9uOyBlaXRoZXIgdmVyc2lvbiAyIG9mIHRoZSBMaWNlbnNlLCBvciAoYXQKKyAq
ICB5b3VyIG9wdGlvbikgYW55IGxhdGVyIHZlcnNpb24uCisgKgorICogIFRoaXMgcHJvZ3JhbSBp
cyBkaXN0cmlidXRlZCBpbiB0aGUgaG9wZSB0aGF0IGl0IHdpbGwgYmUgdXNlZnVsLCBidXQKKyAq
ICBXSVRIT1VUIEFOWSBXQVJSQU5UWTsgd2l0aG91dCBldmVuIHRoZSBpbXBsaWVkIHdhcnJhbnR5
IG9mCisgKiAgTUVSQ0hBTlRBQklMSVRZIG9yIEZJVE5FU1MgRk9SIEEgUEFSVElDVUxBUiBQVVJQ
T1NFLiAgU2VlIHRoZSBHTlUKKyAqICBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlIGZvciBtb3JlIGRl
dGFpbHMuCisgKgorICogIFlvdSBzaG91bGQgaGF2ZSByZWNlaXZlZCBhIGNvcHkgb2YgdGhlIEdO
VSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlIGFsb25nCisgKiAgd2l0aCB0aGlzIHByb2dyYW07IGlm
IG5vdCwgd3JpdGUgdG8gdGhlIEZyZWUgU29mdHdhcmUgRm91bmRhdGlvbiwgSW5jLiwKKyAqICA1
OSBUZW1wbGUgUGxhY2UsIFN1aXRlIDMzMCwgQm9zdG9uLCBNQSAwMjExMS0xMzA3IFVTQS4KKyAq
CisgKi8KKworI2luY2x1ZGUgPGxpbnV4L2tlcm5lbC5oPgorI2luY2x1ZGUgPGxpbnV4L21vZHVs
ZS5oPgorI2luY2x1ZGUgPGxpbnV4L2luaXQuaD4KKyNpbmNsdWRlIDxsaW51eC90eXBlcy5oPgor
I2luY2x1ZGUgPGxpbnV4L21lbW9yeV9ob3RwbHVnLmg+CisjaW5jbHVkZSA8YWNwaS9hY3BpX2Ry
aXZlcnMuaD4KKyNpbmNsdWRlIDx4ZW4vaW50ZXJmYWNlL3BsYXRmb3JtLmg+CisjaW5jbHVkZSA8
bGludXgvaW50ZXJydXB0Lmg+CisjaW5jbHVkZSA8bGludXgvc3BpbmxvY2suaD4KKyNpbmNsdWRl
IDxhc20veGVuL2h5cGVydmlzb3IuaD4KKyNpbmNsdWRlIDxhc20veGVuL2h5cGVyY2FsbC5oPgor
I2luY2x1ZGUgPHhlbi9hY3BpLmg+CisKK3N0cnVjdCB4ZW5faG90bWVtX2VudHJ5IHsKKwlzdHJ1
Y3QgbGlzdF9oZWFkIGhvdG1lbV9saXN0OworCXVpbnQ2NF90IHN0YXJ0OworCXVpbnQ2NF90IGVu
ZDsKKwl1aW50MzJfdCBmbGFnczsKKwl1aW50MzJfdCBweG07Cit9OworCitzdHJ1Y3QgeGVuX2hv
dG1lbV9saXN0IHsKKwlzdHJ1Y3QgbGlzdF9oZWFkIGxpc3Q7CisJaW50IGVudHJ5X25yOworfSB4
ZW5faG90bWVtOworCitERUZJTkVfU1BJTkxPQ0soeGVuX2hvdG1lbV9sb2NrKTsKKworc3RhdGlj
IGludCB4ZW5faHlwZXJfYWRkbWVtKHN0cnVjdCB4ZW5faG90bWVtX2VudHJ5ICplbnRyeSkKK3sK
KwlpbnQgcmV0OworCisJeGVuX3BsYXRmb3JtX29wX3Qgb3AgPSB7CisJCS5jbWQgICAgICAgICAg
ICA9IFhFTlBGX21lbV9ob3RhZGQsCisJCS5pbnRlcmZhY2VfdmVyc2lvbiAgPSBYRU5QRl9JTlRF
UkZBQ0VfVkVSU0lPTiwKKwl9OworCW9wLnUubWVtX2FkZC5zcGZuID0gZW50cnktPnN0YXJ0ID4+
IFBBR0VfU0hJRlQ7CisJb3AudS5tZW1fYWRkLmVwZm4gPSBlbnRyeS0+ZW5kID4+IFBBR0VfU0hJ
RlQ7CisJb3AudS5tZW1fYWRkLmZsYWdzID0gZW50cnktPmZsYWdzOworCW9wLnUubWVtX2FkZC5w
eG0gPSBlbnRyeS0+cHhtOworCisJcmV0ID0gSFlQRVJWSVNPUl9kb20wX29wKCZvcCk7CisJcmV0
dXJuIHJldDsKK30KKworc3RhdGljIGludCBhZGRfaG90bWVtX2VudHJ5KGludCBweG0sIHVpbnQ2
NF90IHN0YXJ0LAorCQkJdWludDY0X3QgbGVuZ3RoLCB1aW50MzJfdCBmbGFncykKK3sKKwlzdHJ1
Y3QgeGVuX2hvdG1lbV9lbnRyeSAqZW50cnk7CisKKwlpZiAocHhtIDwgMCB8fCAhbGVuZ3RoKQor
CQlyZXR1cm4gLUVJTlZBTDsKKworCWVudHJ5ID0ga3phbGxvYyhzaXplb2Yoc3RydWN0IHhlbl9o
b3RtZW1fZW50cnkpLCBHRlBfQVRPTUlDKTsKKwlpZiAoIWVudHJ5KQorCQlyZXR1cm4gLUVOT01F
TTsKKworCUlOSVRfTElTVF9IRUFEKCZlbnRyeS0+aG90bWVtX2xpc3QpOworCWVudHJ5LT5zdGFy
dCA9IHN0YXJ0OworCWVudHJ5LT5lbmQgPSBzdGFydCArIGxlbmd0aDsKKwllbnRyeS0+ZmxhZ3Mg
PSBmbGFnczsKKwllbnRyeS0+cHhtID0gcHhtOworCisJc3Bpbl9sb2NrKCZ4ZW5faG90bWVtX2xv
Y2spOworCisJbGlzdF9hZGRfdGFpbCgmZW50cnktPmhvdG1lbV9saXN0LCAmeGVuX2hvdG1lbS5s
aXN0KTsKKwl4ZW5faG90bWVtLmVudHJ5X25yKys7CisKKwlzcGluX3VubG9jaygmeGVuX2hvdG1l
bV9sb2NrKTsKKworCXJldHVybiAwOworfQorCitzdGF0aWMgaW50IGZyZWVfaG90bWVtX2VudHJ5
KHN0cnVjdCB4ZW5faG90bWVtX2VudHJ5ICplbnRyeSkKK3sKKwlsaXN0X2RlbCgmZW50cnktPmhv
dG1lbV9saXN0KTsKKwlrZnJlZShlbnRyeSk7CisKKwlyZXR1cm4gMDsKK30KKworc3RhdGljIHZv
aWQgeGVuX2hvdGFkZF9tZW1fZHBjKHN0cnVjdCB3b3JrX3N0cnVjdCAqd29yaykKK3sKKwlzdHJ1
Y3QgbGlzdF9oZWFkICplbGVtLCAqdG1wOworCXN0cnVjdCB4ZW5faG90bWVtX2VudHJ5ICplbnRy
eTsKKwl1bnNpZ25lZCBsb25nIGZsYWdzOworCWludCByZXQ7CisKKwlzcGluX2xvY2tfaXJxc2F2
ZSgmeGVuX2hvdG1lbV9sb2NrLCBmbGFncyk7CisJbGlzdF9mb3JfZWFjaF9zYWZlKGVsZW0sIHRt
cCwgJnhlbl9ob3RtZW0ubGlzdCkgeworCQllbnRyeSA9IGxpc3RfZW50cnkoZWxlbSwgc3RydWN0
IHhlbl9ob3RtZW1fZW50cnksIGhvdG1lbV9saXN0KTsKKwkJcmV0ID0geGVuX2h5cGVyX2FkZG1l
bShlbnRyeSk7CisJCWlmIChyZXQpCisJCQlwcmludGsoS0VSTl9XQVJOSU5HICJ4ZW4gYWRkbWVt
IGZhaWxlZCB3aXRoICV4XG4iLCByZXQpOworCQlmcmVlX2hvdG1lbV9lbnRyeShlbnRyeSk7CisJ
CXhlbl9ob3RtZW0uZW50cnlfbnItLTsKKwl9CisJc3Bpbl91bmxvY2tfaXJxcmVzdG9yZSgmeGVu
X2hvdG1lbV9sb2NrLCBmbGFncyk7Cit9CisKK3N0YXRpYyBERUNMQVJFX1dPUksoeGVuX2hvdGFk
ZF9tZW1fd29yaywgeGVuX2hvdGFkZF9tZW1fZHBjKTsKKworc3RhdGljIGludCB4ZW5fYWNwaV9n
ZXRfcHhtKGFjcGlfaGFuZGxlIGgpCit7CisJdW5zaWduZWQgbG9uZyBsb25nIHB4bTsKKwlhY3Bp
X3N0YXR1cyBzdGF0dXM7CisJYWNwaV9oYW5kbGUgaGFuZGxlOworCWFjcGlfaGFuZGxlIHBoYW5k
bGUgPSBoOworCisJZG8geworCQloYW5kbGUgPSBwaGFuZGxlOworCQlzdGF0dXMgPSBhY3BpX2V2
YWx1YXRlX2ludGVnZXIoaGFuZGxlLCAiX1BYTSIsIE5VTEwsICZweG0pOworCQlpZiAoQUNQSV9T
VUNDRVNTKHN0YXR1cykpCisJCQlyZXR1cm4gcHhtOworCQlzdGF0dXMgPSBhY3BpX2dldF9wYXJl
bnQoaGFuZGxlLCAmcGhhbmRsZSk7CisJfSB3aGlsZSAoQUNQSV9TVUNDRVNTKHN0YXR1cykpOwor
CisJcmV0dXJuIC0xOworfQorCitpbnQgeGVuX2hvdGFkZF9tZW1vcnkoc3RydWN0IGFjcGlfbWVt
b3J5X2RldmljZSAqbWVtX2RldmljZSkKK3sKKwlpbnQgcHhtLCByZXN1bHQ7CisJaW50IG51bV9l
bmFibGVkID0gMDsKKwlzdHJ1Y3QgYWNwaV9tZW1vcnlfaW5mbyAqaW5mbzsKKworCWlmICghbWVt
X2RldmljZSkKKwkJcmV0dXJuIC1FSU5WQUw7CisKKwlweG0gPSB4ZW5fYWNwaV9nZXRfcHhtKG1l
bV9kZXZpY2UtPmRldmljZS0+aGFuZGxlKTsKKworCWlmIChweG0gPCAwKQorCQlyZXR1cm4gLUVJ
TlZBTDsKKworCS8qCisJICogQWx3YXlzIHJldHVybiBzdWNjZXNzIHRvIEFDUEkgZHJpdmVyLCBh
bmQgbm90aWZ5IGh5cGVydmlzb3IgbGF0ZXIKKwkgKiBiZWNhdXNlIGh5cGVydmlzb3Igd2lsbCB1
dGlsaXplIHRoZSBtZW1vcnkgaW4gbWVtb3J5IGhvdGFkZCBoeXBlcmNhbGwKKwkgKi8KKwlsaXN0
X2Zvcl9lYWNoX2VudHJ5KGluZm8sICZtZW1fZGV2aWNlLT5yZXNfbGlzdCwgbGlzdCkgeworCQlp
ZiAoaW5mby0+ZW5hYmxlZCkgeyAvKiBqdXN0IHNhbml0eSBjaGVjay4uLiovCisJCQludW1fZW5h
YmxlZCsrOworCQkJY29udGludWU7CisJCX0KKwkJLyoKKwkJICogSWYgdGhlIG1lbW9yeSBibG9j
ayBzaXplIGlzIHplcm8sIHBsZWFzZSBpZ25vcmUgaXQuCisJCSAqIERvbid0IHRyeSB0byBkbyB0
aGUgZm9sbG93aW5nIG1lbW9yeSBob3RwbHVnIGZsb3djaGFydC4KKwkJICovCisJCWlmICghaW5m
by0+bGVuZ3RoKQorCQkJY29udGludWU7CisKKwkJcmVzdWx0ID0gYWRkX2hvdG1lbV9lbnRyeShw
eG0sIGluZm8tPnN0YXJ0X2FkZHIsCisJCQkJCWluZm8tPmxlbmd0aCwgMCk7CisJCWlmIChyZXN1
bHQpCisJCQljb250aW51ZTsKKwkJaW5mby0+ZW5hYmxlZCA9IDE7CisJCW51bV9lbmFibGVkKys7
CisJfQorCisJaWYgKCFudW1fZW5hYmxlZCkKKwkJcmV0dXJuIC1FSU5WQUw7CisKKwlzY2hlZHVs
ZV93b3JrKCZ4ZW5faG90YWRkX21lbV93b3JrKTsKKworCXJldHVybiAwOworfQorRVhQT1JUX1NZ
TUJPTCh4ZW5faG90YWRkX21lbW9yeSk7CisKK3N0YXRpYyBpbnQgeGVuX2hvdGFkZF9tZW1faW5p
dCh2b2lkKQoreworCWlmICgheGVuX2luaXRpYWxfZG9tYWluKCkpCisJCXJldHVybiAtRU5PREVW
OworCisJSU5JVF9MSVNUX0hFQUQoJnhlbl9ob3RtZW0ubGlzdCk7CisJeGVuX2hvdG1lbS5lbnRy
eV9uciA9IDA7CisKKwlyZXR1cm4gMDsKK30KKworc3RhdGljIHZvaWQgeGVuX2hvdGFkZF9tZW1f
ZXhpdCh2b2lkKQoreworCWZsdXNoX3NjaGVkdWxlZF93b3JrKCk7Cit9CisKK21vZHVsZV9pbml0
KHhlbl9ob3RhZGRfbWVtX2luaXQpOworbW9kdWxlX2V4aXQoeGVuX2hvdGFkZF9tZW1fZXhpdCk7
CitNT0RVTEVfTElDRU5TRSgiR1BMIik7CmRpZmYgLS1naXQgYS9pbmNsdWRlL3hlbi9hY3BpLmgg
Yi9pbmNsdWRlL3hlbi9hY3BpLmgKaW5kZXggN2FhMjgyZC4uOGIzNDYyZSAxMDA2NDQKLS0tIGEv
aW5jbHVkZS94ZW4vYWNwaS5oCisrKyBiL2luY2x1ZGUveGVuL2FjcGkuaApAQCAtMTA3LDYgKzEw
NywxMSBAQCBzdGF0aWMgaW5saW5lIGludCB4ZW5fYWNwaV9wcm9jZXNzb3JfZ2V0X3BlcmZvcm1h
bmNlKHN0cnVjdCBhY3BpX3Byb2Nlc3NvciAqcHIpCiB9CiAjZW5kaWYKIAorI2lmIGRlZmluZWQo
Q09ORklHX0FDUElfSE9UUExVR19NRU1PUlkpIHx8IFwKK2RlZmluZWQoQ09ORklHX0FDUElfSE9U
UExVR19NRU1PUllfTU9EVUxFKQoraW50IHhlbl9ob3RhZGRfbWVtb3J5KHN0cnVjdCBhY3BpX21l
bW9yeV9kZXZpY2UgKm1lbV9kZXZpY2UpOworI2VuZGlmCisKICNpZiBkZWZpbmVkKENPTkZJR19B
Q1BJX1BST0NFU1NPUl9YRU4pIHx8IFwKIGRlZmluZWQoQ09ORklHX0FDUElfUFJPQ0VTU09SX1hF
Tl9NT0RVTEUpCiAKZGlmZiAtLWdpdCBhL2luY2x1ZGUveGVuL2ludGVyZmFjZS9wbGF0Zm9ybS5o
IGIvaW5jbHVkZS94ZW4vaW50ZXJmYWNlL3BsYXRmb3JtLmgKaW5kZXggOWZkNmIwNy4uMDc4N2M2
OCAxMDA2NDQKLS0tIGEvaW5jbHVkZS94ZW4vaW50ZXJmYWNlL3BsYXRmb3JtLmgKKysrIGIvaW5j
bHVkZS94ZW4vaW50ZXJmYWNlL3BsYXRmb3JtLmgKQEAgLTMyOSw2ICszMjksMTQgQEAgc3RydWN0
IHhlbnBmX2NwdV9ob3RhZGQgewogCXVpbnQzMl90IHB4bTsKIH07CiAKKyNkZWZpbmUgWEVOUEZf
bWVtX2hvdGFkZCAgICA1OQorc3RydWN0IHhlbnBmX21lbV9ob3RhZGQgeworCXVpbnQ2NF90IHNw
Zm47CisJdWludDY0X3QgZXBmbjsKKwl1aW50MzJfdCBweG07CisJdWludDMyX3QgZmxhZ3M7Cit9
OworCiBzdHJ1Y3QgeGVuX3BsYXRmb3JtX29wIHsKIAl1aW50MzJfdCBjbWQ7CiAJdWludDMyX3Qg
aW50ZXJmYWNlX3ZlcnNpb247IC8qIFhFTlBGX0lOVEVSRkFDRV9WRVJTSU9OICovCkBAIC0zNDcs
NiArMzU1LDcgQEAgc3RydWN0IHhlbl9wbGF0Zm9ybV9vcCB7CiAJCXN0cnVjdCB4ZW5wZl9wY3B1
aW5mbyAgICAgICAgICBwY3B1X2luZm87CiAJCXN0cnVjdCB4ZW5wZl9jcHVfb2wgICAgICAgICAg
ICBjcHVfb2w7CiAJCXN0cnVjdCB4ZW5wZl9jcHVfaG90YWRkICAgICAgICBjcHVfYWRkOworCQlz
dHJ1Y3QgeGVucGZfbWVtX2hvdGFkZCAgICAgICAgbWVtX2FkZDsKIAkJdWludDhfdCAgICAgICAg
ICAgICAgICAgICAgICAgIHBhZFsxMjhdOwogCX0gdTsKIH07Ci0tIAoxLjYuNS42Cgo=

--_002_DE8DF0795D48FD4CA783C40EC82923359700SHSMSX101ccrcorpint_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--_002_DE8DF0795D48FD4CA783C40EC82923359700SHSMSX101ccrcorpint_--


From xen-devel-bounces@lists.xensource.com Fri Dec 23 10:30:11 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 Dec 2011 10:30:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Re2Nw-0006nT-TU; Fri, 23 Dec 2011 10:29:56 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1Re2Nv-0006nH-Px
	for xen-devel@lists.xensource.com; Fri, 23 Dec 2011 10:29:56 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1324636141!58444587!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDMwMjM5MQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4365 invoked from network); 23 Dec 2011 10:29:02 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-2.tower-27.messagelabs.com with SMTP;
	23 Dec 2011 10:29:02 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga101.fm.intel.com with ESMTP; 23 Dec 2011 02:29:53 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208,223";a="99639265"
Received: from pgsmsx602.gar.corp.intel.com ([10.221.43.81])
	by fmsmga001.fm.intel.com with ESMTP; 23 Dec 2011 02:29:51 -0800
Received: from pgsmsx102.gar.corp.intel.com (10.221.44.80) by
	pgsmsx602.gar.corp.intel.com (10.221.43.81) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Fri, 23 Dec 2011 18:29:37 +0800
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	PGSMSX102.gar.corp.intel.com (10.221.44.80) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Fri, 23 Dec 2011 18:29:36 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.38]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.199]) with mapi id
	14.01.0355.002; Fri, 23 Dec 2011 18:29:35 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: "konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
Thread-Topic: [PATCH 07/10] xen/acpi: Prepare for cpu hotplug
Thread-Index: AczBXcPLVEQJuPy+S66ViENeEjagAA==
Date: Fri, 23 Dec 2011 10:29:35 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC8292335970B@SHSMSX101.ccr.corp.intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
Content-Type: multipart/mixed;
	boundary="_002_DE8DF0795D48FD4CA783C40EC8292335970BSHSMSX101ccrcorpint_"
MIME-Version: 1.0
Cc: "Brown, Len" <len.brown@intel.com>,
	"jeremy.fitzhardinge@citrix.com" <jeremy.fitzhardinge@citrix.com>,
	"Jiang, Yunhong" <yunhong.jiang@intel.com>, "Shan, 
	Haitao" <haitao.shan@intel.com>,
	Kernel development list <linux-kernel@vger.kernel.org>, "Zhao,
	Yakui" <yakui.zhao@intel.com>, "Luck, Tony" <tony.luck@intel.com>, "Kleen,
	Andi" <andi.kleen@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: [Xen-devel] [PATCH 07/10] xen/acpi: Prepare for cpu hotplug
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--_002_DE8DF0795D48FD4CA783C40EC8292335970BSHSMSX101ccrcorpint_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

>From 0dad15c02d033d6be7e9447fbe5f645d97badc24 Mon Sep 17 00:00:00 2001
From: Liu Jinsong <jinsong.liu@intel.com>
Date: Tue, 13 Dec 2011 21:14:45 +0800
Subject: [PATCH 07/10] xen/acpi: Prepare for cpu hotplug

This patch rebased from Jeremy's pvops commit
68320323a51c2378aca433c76157d9e66104ff1e

It does some prepare work for cpu hotplug

Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
Signed-off-by: Jiang, Yunhong <yunhong.jiang@intel.com>
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
---
 drivers/acpi/processor_xen.c |   37 +++++++++++++++++++++++++++++++++++++
 1 files changed, 37 insertions(+), 0 deletions(-)

diff --git a/drivers/acpi/processor_xen.c b/drivers/acpi/processor_xen.c
index 029e10c..38a1c05 100644
--- a/drivers/acpi/processor_xen.c
+++ b/drivers/acpi/processor_xen.c
@@ -19,6 +19,7 @@
 #include <acpi/acpi_drivers.h>
 #include <acpi/processor.h>
 #include <xen/acpi.h>
+#include <xen/pcpu.h>
=20
 #define PREFIX "ACPI: "
=20
@@ -54,6 +55,42 @@ struct acpi_driver xen_acpi_processor_driver =3D {
 		},
 };
=20
+static int is_processor_present(acpi_handle handle)
+{
+	acpi_status status;
+	unsigned long long sta =3D 0;
+
+
+	status =3D acpi_evaluate_integer(handle, "_STA", NULL, &sta);
+
+	if (ACPI_SUCCESS(status) && (sta & ACPI_STA_DEVICE_PRESENT))
+		return 1;
+
+	/*
+	 * _STA is mandatory for a processor that supports hot plug
+	 */
+	if (status =3D=3D AE_NOT_FOUND)
+		ACPI_DEBUG_PRINT((ACPI_DB_INFO,
+				"Processor does not support hot plug\n"));
+	else
+		ACPI_EXCEPTION((AE_INFO, status,
+				"Processor Device is not present"));
+	return 0;
+}
+
+static acpi_status
+xen_acpi_processor_hotadd_init(struct acpi_processor *pr, int *p_cpu)
+{
+	if (!is_processor_present(pr->handle))
+		return AE_ERROR;
+
+	if (processor_cntl_xen_notify(pr,
+				PROCESSOR_HOTPLUG, HOTPLUG_TYPE_ADD))
+		return AE_ERROR;
+
+	return AE_OK;
+}
+
 #ifdef CONFIG_CPU_FREQ
 /*
  * Existing ACPI module does parse performance states at some point,
--=20
1.6.5.6

--_002_DE8DF0795D48FD4CA783C40EC8292335970BSHSMSX101ccrcorpint_
Content-Type: application/octet-stream;
	name="0007-xen-acpi-Prepare-for-cpu-hotplug.patch"
Content-Description: 0007-xen-acpi-Prepare-for-cpu-hotplug.patch
Content-Disposition: attachment;
	filename="0007-xen-acpi-Prepare-for-cpu-hotplug.patch"; size=1986;
	creation-date="Wed, 14 Dec 2011 15:20:15 GMT";
	modification-date="Wed, 14 Dec 2011 15:03:34 GMT"
Content-Transfer-Encoding: base64

RnJvbSAwZGFkMTVjMDJkMDMzZDZiZTdlOTQ0N2ZiZTVmNjQ1ZDk3YmFkYzI0IE1vbiBTZXAgMTcg
MDA6MDA6MDAgMjAwMQpGcm9tOiBMaXUgSmluc29uZyA8amluc29uZy5saXVAaW50ZWwuY29tPgpE
YXRlOiBUdWUsIDEzIERlYyAyMDExIDIxOjE0OjQ1ICswODAwClN1YmplY3Q6IFtQQVRDSCAwNy8x
MF0geGVuL2FjcGk6IFByZXBhcmUgZm9yIGNwdSBob3RwbHVnCgpUaGlzIHBhdGNoIHJlYmFzZWQg
ZnJvbSBKZXJlbXkncyBwdm9wcyBjb21taXQKNjgzMjAzMjNhNTFjMjM3OGFjYTQzM2M3NjE1N2Q5
ZTY2MTA0ZmYxZQoKSXQgZG9lcyBzb21lIHByZXBhcmUgd29yayBmb3IgY3B1IGhvdHBsdWcKClNp
Z25lZC1vZmYtYnk6IExpdSwgSmluc29uZyA8amluc29uZy5saXVAaW50ZWwuY29tPgpTaWduZWQt
b2ZmLWJ5OiBKaWFuZywgWXVuaG9uZyA8eXVuaG9uZy5qaWFuZ0BpbnRlbC5jb20+ClNpZ25lZC1v
ZmYtYnk6IEplcmVteSBGaXR6aGFyZGluZ2UgPGplcmVteS5maXR6aGFyZGluZ2VAY2l0cml4LmNv
bT4KLS0tCiBkcml2ZXJzL2FjcGkvcHJvY2Vzc29yX3hlbi5jIHwgICAzNyArKysrKysrKysrKysr
KysrKysrKysrKysrKysrKysrKysrKysrCiAxIGZpbGVzIGNoYW5nZWQsIDM3IGluc2VydGlvbnMo
KyksIDAgZGVsZXRpb25zKC0pCgpkaWZmIC0tZ2l0IGEvZHJpdmVycy9hY3BpL3Byb2Nlc3Nvcl94
ZW4uYyBiL2RyaXZlcnMvYWNwaS9wcm9jZXNzb3JfeGVuLmMKaW5kZXggMDI5ZTEwYy4uMzhhMWMw
NSAxMDA2NDQKLS0tIGEvZHJpdmVycy9hY3BpL3Byb2Nlc3Nvcl94ZW4uYworKysgYi9kcml2ZXJz
L2FjcGkvcHJvY2Vzc29yX3hlbi5jCkBAIC0xOSw2ICsxOSw3IEBACiAjaW5jbHVkZSA8YWNwaS9h
Y3BpX2RyaXZlcnMuaD4KICNpbmNsdWRlIDxhY3BpL3Byb2Nlc3Nvci5oPgogI2luY2x1ZGUgPHhl
bi9hY3BpLmg+CisjaW5jbHVkZSA8eGVuL3BjcHUuaD4KIAogI2RlZmluZSBQUkVGSVggIkFDUEk6
ICIKIApAQCAtNTQsNiArNTUsNDIgQEAgc3RydWN0IGFjcGlfZHJpdmVyIHhlbl9hY3BpX3Byb2Nl
c3Nvcl9kcml2ZXIgPSB7CiAJCX0sCiB9OwogCitzdGF0aWMgaW50IGlzX3Byb2Nlc3Nvcl9wcmVz
ZW50KGFjcGlfaGFuZGxlIGhhbmRsZSkKK3sKKwlhY3BpX3N0YXR1cyBzdGF0dXM7CisJdW5zaWdu
ZWQgbG9uZyBsb25nIHN0YSA9IDA7CisKKworCXN0YXR1cyA9IGFjcGlfZXZhbHVhdGVfaW50ZWdl
cihoYW5kbGUsICJfU1RBIiwgTlVMTCwgJnN0YSk7CisKKwlpZiAoQUNQSV9TVUNDRVNTKHN0YXR1
cykgJiYgKHN0YSAmIEFDUElfU1RBX0RFVklDRV9QUkVTRU5UKSkKKwkJcmV0dXJuIDE7CisKKwkv
KgorCSAqIF9TVEEgaXMgbWFuZGF0b3J5IGZvciBhIHByb2Nlc3NvciB0aGF0IHN1cHBvcnRzIGhv
dCBwbHVnCisJICovCisJaWYgKHN0YXR1cyA9PSBBRV9OT1RfRk9VTkQpCisJCUFDUElfREVCVUdf
UFJJTlQoKEFDUElfREJfSU5GTywKKwkJCQkiUHJvY2Vzc29yIGRvZXMgbm90IHN1cHBvcnQgaG90
IHBsdWdcbiIpKTsKKwllbHNlCisJCUFDUElfRVhDRVBUSU9OKChBRV9JTkZPLCBzdGF0dXMsCisJ
CQkJIlByb2Nlc3NvciBEZXZpY2UgaXMgbm90IHByZXNlbnQiKSk7CisJcmV0dXJuIDA7Cit9CisK
K3N0YXRpYyBhY3BpX3N0YXR1cworeGVuX2FjcGlfcHJvY2Vzc29yX2hvdGFkZF9pbml0KHN0cnVj
dCBhY3BpX3Byb2Nlc3NvciAqcHIsIGludCAqcF9jcHUpCit7CisJaWYgKCFpc19wcm9jZXNzb3Jf
cHJlc2VudChwci0+aGFuZGxlKSkKKwkJcmV0dXJuIEFFX0VSUk9SOworCisJaWYgKHByb2Nlc3Nv
cl9jbnRsX3hlbl9ub3RpZnkocHIsCisJCQkJUFJPQ0VTU09SX0hPVFBMVUcsIEhPVFBMVUdfVFlQ
RV9BREQpKQorCQlyZXR1cm4gQUVfRVJST1I7CisKKwlyZXR1cm4gQUVfT0s7Cit9CisKICNpZmRl
ZiBDT05GSUdfQ1BVX0ZSRVEKIC8qCiAgKiBFeGlzdGluZyBBQ1BJIG1vZHVsZSBkb2VzIHBhcnNl
IHBlcmZvcm1hbmNlIHN0YXRlcyBhdCBzb21lIHBvaW50LAotLSAKMS42LjUuNgoK

--_002_DE8DF0795D48FD4CA783C40EC8292335970BSHSMSX101ccrcorpint_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--_002_DE8DF0795D48FD4CA783C40EC8292335970BSHSMSX101ccrcorpint_--


From xen-devel-bounces@lists.xensource.com Fri Dec 23 10:30:11 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 Dec 2011 10:30:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Re2Nw-0006nT-TU; Fri, 23 Dec 2011 10:29:56 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1Re2Nv-0006nH-Px
	for xen-devel@lists.xensource.com; Fri, 23 Dec 2011 10:29:56 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1324636141!58444587!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDMwMjM5MQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4365 invoked from network); 23 Dec 2011 10:29:02 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-2.tower-27.messagelabs.com with SMTP;
	23 Dec 2011 10:29:02 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga101.fm.intel.com with ESMTP; 23 Dec 2011 02:29:53 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208,223";a="99639265"
Received: from pgsmsx602.gar.corp.intel.com ([10.221.43.81])
	by fmsmga001.fm.intel.com with ESMTP; 23 Dec 2011 02:29:51 -0800
Received: from pgsmsx102.gar.corp.intel.com (10.221.44.80) by
	pgsmsx602.gar.corp.intel.com (10.221.43.81) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Fri, 23 Dec 2011 18:29:37 +0800
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	PGSMSX102.gar.corp.intel.com (10.221.44.80) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Fri, 23 Dec 2011 18:29:36 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.38]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.199]) with mapi id
	14.01.0355.002; Fri, 23 Dec 2011 18:29:35 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: "konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
Thread-Topic: [PATCH 07/10] xen/acpi: Prepare for cpu hotplug
Thread-Index: AczBXcPLVEQJuPy+S66ViENeEjagAA==
Date: Fri, 23 Dec 2011 10:29:35 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC8292335970B@SHSMSX101.ccr.corp.intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
Content-Type: multipart/mixed;
	boundary="_002_DE8DF0795D48FD4CA783C40EC8292335970BSHSMSX101ccrcorpint_"
MIME-Version: 1.0
Cc: "Brown, Len" <len.brown@intel.com>,
	"jeremy.fitzhardinge@citrix.com" <jeremy.fitzhardinge@citrix.com>,
	"Jiang, Yunhong" <yunhong.jiang@intel.com>, "Shan, 
	Haitao" <haitao.shan@intel.com>,
	Kernel development list <linux-kernel@vger.kernel.org>, "Zhao,
	Yakui" <yakui.zhao@intel.com>, "Luck, Tony" <tony.luck@intel.com>, "Kleen,
	Andi" <andi.kleen@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: [Xen-devel] [PATCH 07/10] xen/acpi: Prepare for cpu hotplug
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--_002_DE8DF0795D48FD4CA783C40EC8292335970BSHSMSX101ccrcorpint_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

>From 0dad15c02d033d6be7e9447fbe5f645d97badc24 Mon Sep 17 00:00:00 2001
From: Liu Jinsong <jinsong.liu@intel.com>
Date: Tue, 13 Dec 2011 21:14:45 +0800
Subject: [PATCH 07/10] xen/acpi: Prepare for cpu hotplug

This patch rebased from Jeremy's pvops commit
68320323a51c2378aca433c76157d9e66104ff1e

It does some prepare work for cpu hotplug

Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
Signed-off-by: Jiang, Yunhong <yunhong.jiang@intel.com>
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
---
 drivers/acpi/processor_xen.c |   37 +++++++++++++++++++++++++++++++++++++
 1 files changed, 37 insertions(+), 0 deletions(-)

diff --git a/drivers/acpi/processor_xen.c b/drivers/acpi/processor_xen.c
index 029e10c..38a1c05 100644
--- a/drivers/acpi/processor_xen.c
+++ b/drivers/acpi/processor_xen.c
@@ -19,6 +19,7 @@
 #include <acpi/acpi_drivers.h>
 #include <acpi/processor.h>
 #include <xen/acpi.h>
+#include <xen/pcpu.h>
=20
 #define PREFIX "ACPI: "
=20
@@ -54,6 +55,42 @@ struct acpi_driver xen_acpi_processor_driver =3D {
 		},
 };
=20
+static int is_processor_present(acpi_handle handle)
+{
+	acpi_status status;
+	unsigned long long sta =3D 0;
+
+
+	status =3D acpi_evaluate_integer(handle, "_STA", NULL, &sta);
+
+	if (ACPI_SUCCESS(status) && (sta & ACPI_STA_DEVICE_PRESENT))
+		return 1;
+
+	/*
+	 * _STA is mandatory for a processor that supports hot plug
+	 */
+	if (status =3D=3D AE_NOT_FOUND)
+		ACPI_DEBUG_PRINT((ACPI_DB_INFO,
+				"Processor does not support hot plug\n"));
+	else
+		ACPI_EXCEPTION((AE_INFO, status,
+				"Processor Device is not present"));
+	return 0;
+}
+
+static acpi_status
+xen_acpi_processor_hotadd_init(struct acpi_processor *pr, int *p_cpu)
+{
+	if (!is_processor_present(pr->handle))
+		return AE_ERROR;
+
+	if (processor_cntl_xen_notify(pr,
+				PROCESSOR_HOTPLUG, HOTPLUG_TYPE_ADD))
+		return AE_ERROR;
+
+	return AE_OK;
+}
+
 #ifdef CONFIG_CPU_FREQ
 /*
  * Existing ACPI module does parse performance states at some point,
--=20
1.6.5.6

--_002_DE8DF0795D48FD4CA783C40EC8292335970BSHSMSX101ccrcorpint_
Content-Type: application/octet-stream;
	name="0007-xen-acpi-Prepare-for-cpu-hotplug.patch"
Content-Description: 0007-xen-acpi-Prepare-for-cpu-hotplug.patch
Content-Disposition: attachment;
	filename="0007-xen-acpi-Prepare-for-cpu-hotplug.patch"; size=1986;
	creation-date="Wed, 14 Dec 2011 15:20:15 GMT";
	modification-date="Wed, 14 Dec 2011 15:03:34 GMT"
Content-Transfer-Encoding: base64

RnJvbSAwZGFkMTVjMDJkMDMzZDZiZTdlOTQ0N2ZiZTVmNjQ1ZDk3YmFkYzI0IE1vbiBTZXAgMTcg
MDA6MDA6MDAgMjAwMQpGcm9tOiBMaXUgSmluc29uZyA8amluc29uZy5saXVAaW50ZWwuY29tPgpE
YXRlOiBUdWUsIDEzIERlYyAyMDExIDIxOjE0OjQ1ICswODAwClN1YmplY3Q6IFtQQVRDSCAwNy8x
MF0geGVuL2FjcGk6IFByZXBhcmUgZm9yIGNwdSBob3RwbHVnCgpUaGlzIHBhdGNoIHJlYmFzZWQg
ZnJvbSBKZXJlbXkncyBwdm9wcyBjb21taXQKNjgzMjAzMjNhNTFjMjM3OGFjYTQzM2M3NjE1N2Q5
ZTY2MTA0ZmYxZQoKSXQgZG9lcyBzb21lIHByZXBhcmUgd29yayBmb3IgY3B1IGhvdHBsdWcKClNp
Z25lZC1vZmYtYnk6IExpdSwgSmluc29uZyA8amluc29uZy5saXVAaW50ZWwuY29tPgpTaWduZWQt
b2ZmLWJ5OiBKaWFuZywgWXVuaG9uZyA8eXVuaG9uZy5qaWFuZ0BpbnRlbC5jb20+ClNpZ25lZC1v
ZmYtYnk6IEplcmVteSBGaXR6aGFyZGluZ2UgPGplcmVteS5maXR6aGFyZGluZ2VAY2l0cml4LmNv
bT4KLS0tCiBkcml2ZXJzL2FjcGkvcHJvY2Vzc29yX3hlbi5jIHwgICAzNyArKysrKysrKysrKysr
KysrKysrKysrKysrKysrKysrKysrKysrCiAxIGZpbGVzIGNoYW5nZWQsIDM3IGluc2VydGlvbnMo
KyksIDAgZGVsZXRpb25zKC0pCgpkaWZmIC0tZ2l0IGEvZHJpdmVycy9hY3BpL3Byb2Nlc3Nvcl94
ZW4uYyBiL2RyaXZlcnMvYWNwaS9wcm9jZXNzb3JfeGVuLmMKaW5kZXggMDI5ZTEwYy4uMzhhMWMw
NSAxMDA2NDQKLS0tIGEvZHJpdmVycy9hY3BpL3Byb2Nlc3Nvcl94ZW4uYworKysgYi9kcml2ZXJz
L2FjcGkvcHJvY2Vzc29yX3hlbi5jCkBAIC0xOSw2ICsxOSw3IEBACiAjaW5jbHVkZSA8YWNwaS9h
Y3BpX2RyaXZlcnMuaD4KICNpbmNsdWRlIDxhY3BpL3Byb2Nlc3Nvci5oPgogI2luY2x1ZGUgPHhl
bi9hY3BpLmg+CisjaW5jbHVkZSA8eGVuL3BjcHUuaD4KIAogI2RlZmluZSBQUkVGSVggIkFDUEk6
ICIKIApAQCAtNTQsNiArNTUsNDIgQEAgc3RydWN0IGFjcGlfZHJpdmVyIHhlbl9hY3BpX3Byb2Nl
c3Nvcl9kcml2ZXIgPSB7CiAJCX0sCiB9OwogCitzdGF0aWMgaW50IGlzX3Byb2Nlc3Nvcl9wcmVz
ZW50KGFjcGlfaGFuZGxlIGhhbmRsZSkKK3sKKwlhY3BpX3N0YXR1cyBzdGF0dXM7CisJdW5zaWdu
ZWQgbG9uZyBsb25nIHN0YSA9IDA7CisKKworCXN0YXR1cyA9IGFjcGlfZXZhbHVhdGVfaW50ZWdl
cihoYW5kbGUsICJfU1RBIiwgTlVMTCwgJnN0YSk7CisKKwlpZiAoQUNQSV9TVUNDRVNTKHN0YXR1
cykgJiYgKHN0YSAmIEFDUElfU1RBX0RFVklDRV9QUkVTRU5UKSkKKwkJcmV0dXJuIDE7CisKKwkv
KgorCSAqIF9TVEEgaXMgbWFuZGF0b3J5IGZvciBhIHByb2Nlc3NvciB0aGF0IHN1cHBvcnRzIGhv
dCBwbHVnCisJICovCisJaWYgKHN0YXR1cyA9PSBBRV9OT1RfRk9VTkQpCisJCUFDUElfREVCVUdf
UFJJTlQoKEFDUElfREJfSU5GTywKKwkJCQkiUHJvY2Vzc29yIGRvZXMgbm90IHN1cHBvcnQgaG90
IHBsdWdcbiIpKTsKKwllbHNlCisJCUFDUElfRVhDRVBUSU9OKChBRV9JTkZPLCBzdGF0dXMsCisJ
CQkJIlByb2Nlc3NvciBEZXZpY2UgaXMgbm90IHByZXNlbnQiKSk7CisJcmV0dXJuIDA7Cit9CisK
K3N0YXRpYyBhY3BpX3N0YXR1cworeGVuX2FjcGlfcHJvY2Vzc29yX2hvdGFkZF9pbml0KHN0cnVj
dCBhY3BpX3Byb2Nlc3NvciAqcHIsIGludCAqcF9jcHUpCit7CisJaWYgKCFpc19wcm9jZXNzb3Jf
cHJlc2VudChwci0+aGFuZGxlKSkKKwkJcmV0dXJuIEFFX0VSUk9SOworCisJaWYgKHByb2Nlc3Nv
cl9jbnRsX3hlbl9ub3RpZnkocHIsCisJCQkJUFJPQ0VTU09SX0hPVFBMVUcsIEhPVFBMVUdfVFlQ
RV9BREQpKQorCQlyZXR1cm4gQUVfRVJST1I7CisKKwlyZXR1cm4gQUVfT0s7Cit9CisKICNpZmRl
ZiBDT05GSUdfQ1BVX0ZSRVEKIC8qCiAgKiBFeGlzdGluZyBBQ1BJIG1vZHVsZSBkb2VzIHBhcnNl
IHBlcmZvcm1hbmNlIHN0YXRlcyBhdCBzb21lIHBvaW50LAotLSAKMS42LjUuNgoK

--_002_DE8DF0795D48FD4CA783C40EC8292335970BSHSMSX101ccrcorpint_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--_002_DE8DF0795D48FD4CA783C40EC8292335970BSHSMSX101ccrcorpint_--


From xen-devel-bounces@lists.xensource.com Fri Dec 23 10:30:48 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 Dec 2011 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.xensource.com>)
	id 1Re2Oe-0006u1-CA; Fri, 23 Dec 2011 10:30:40 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1Re2Oc-0006tH-CM
	for xen-devel@lists.xensource.com; Fri, 23 Dec 2011 10:30:38 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1324636186!50159685!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDMwMDk1NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14171 invoked from network); 23 Dec 2011 10:29:47 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-3.tower-27.messagelabs.com with SMTP;
	23 Dec 2011 10:29:47 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga102.fm.intel.com with ESMTP; 23 Dec 2011 02:30:32 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208,223";a="99639487"
Received: from pgsmsx602.gar.corp.intel.com ([10.221.43.81])
	by fmsmga001.fm.intel.com with ESMTP; 23 Dec 2011 02:30:31 -0800
Received: from pgsmsx104.gar.corp.intel.com (10.221.44.91) by
	pgsmsx602.gar.corp.intel.com (10.221.43.81) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Fri, 23 Dec 2011 18:30:15 +0800
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	PGSMSX104.gar.corp.intel.com (10.221.44.91) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Fri, 23 Dec 2011 18:30:14 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.38]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.199]) with mapi id
	14.01.0355.002; Fri, 23 Dec 2011 18:30:12 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: "konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
Thread-Topic: [PATCH 08/10] xen/acpi: add cpu hotadd support
Thread-Index: AczBXdnxG/uZZT4gQla9H//97c2bRw==
Date: Fri, 23 Dec 2011 10:30:12 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC82923359720@SHSMSX101.ccr.corp.intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
Content-Type: multipart/mixed;
	boundary="_002_DE8DF0795D48FD4CA783C40EC82923359720SHSMSX101ccrcorpint_"
MIME-Version: 1.0
Cc: "Brown, Len" <len.brown@intel.com>,
	"jeremy.fitzhardinge@citrix.com" <jeremy.fitzhardinge@citrix.com>,
	"Jiang, Yunhong" <yunhong.jiang@intel.com>, "Shan, 
	Haitao" <haitao.shan@intel.com>,
	Kernel development list <linux-kernel@vger.kernel.org>, "Zhao,
	Yakui" <yakui.zhao@intel.com>, "Luck, Tony" <tony.luck@intel.com>, "Kleen,
	Andi" <andi.kleen@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: [Xen-devel] [PATCH 08/10] xen/acpi: add cpu hotadd support
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--_002_DE8DF0795D48FD4CA783C40EC82923359720SHSMSX101ccrcorpint_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

>From 282958be3a33b2f2b888e1ed3ac022bf8a199ec9 Mon Sep 17 00:00:00 2001
From: Liu Jinsong <jinsong.liu@intel.com>
Date: Wed, 14 Dec 2011 11:38:11 +0800
Subject: [PATCH 08/10] xen/acpi: add cpu hotadd support

This patch add cpu hotadd support.
It keep similar cpu hotadd logic as native, w/ some changes according
to xen requirement, hypercalling hypervisor related logic to hotadd cpu.

Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
Signed-off-by: Jiang, Yunhong <yunhong.jiang@intel.com>
---
 drivers/acpi/processor_driver.c |    4 +-
 drivers/acpi/processor_xen.c    |  242 +++++++++++++++++++++++++++++++++++=
+++-
 include/acpi/processor.h        |    2 +
 include/xen/pcpu.h              |    2 +
 4 files changed, 246 insertions(+), 4 deletions(-)

diff --git a/drivers/acpi/processor_driver.c b/drivers/acpi/processor_drive=
r.c
index 8a367d7..d473fd5 100644
--- a/drivers/acpi/processor_driver.c
+++ b/drivers/acpi/processor_driver.c
@@ -221,7 +221,7 @@ static int acpi_processor_errata_piix4(struct pci_dev *=
dev)
 	return 0;
 }
=20
-static int acpi_processor_errata(struct acpi_processor *pr)
+int acpi_processor_errata(struct acpi_processor *pr)
 {
 	int result =3D 0;
 	struct pci_dev *dev =3D NULL;
@@ -378,7 +378,7 @@ static int acpi_processor_get_info(struct acpi_device *=
device)
 	return 0;
 }
=20
-static DEFINE_PER_CPU(void *, processor_device_array);
+DEFINE_PER_CPU(void *, processor_device_array);
=20
 void acpi_processor_notify(struct acpi_device *device, u32 event)
 {
diff --git a/drivers/acpi/processor_xen.c b/drivers/acpi/processor_xen.c
index 38a1c05..3af1f73 100644
--- a/drivers/acpi/processor_xen.c
+++ b/drivers/acpi/processor_xen.c
@@ -24,6 +24,7 @@
 #define PREFIX "ACPI: "
=20
 #define ACPI_PROCESSOR_CLASS            "processor"
+#define ACPI_PROCESSOR_DEVICE_NAME      "Processor"
 #define ACPI_PROCESSOR_NOTIFY_PERFORMANCE 0x80
 #define ACPI_PROCESSOR_NOTIFY_POWER	0x81
 #define ACPI_PROCESSOR_NOTIFY_THROTTLING	0x82
@@ -88,6 +89,8 @@ xen_acpi_processor_hotadd_init(struct acpi_processor *pr,=
 int *p_cpu)
 				PROCESSOR_HOTPLUG, HOTPLUG_TYPE_ADD))
 		return AE_ERROR;
=20
+	*p_cpu =3D xen_pcpu_index(pr->acpi_id, 1);
+
 	return AE_OK;
 }
=20
@@ -149,13 +152,248 @@ err_out:
 }
 #endif /* CONFIG_CPU_FREQ */
=20
+static int xen_acpi_processor_get_info(struct acpi_device *device)
+{
+	acpi_status status =3D 0;
+	union acpi_object object =3D { 0 };
+	struct acpi_buffer buffer =3D { sizeof(union acpi_object), &object };
+	struct acpi_processor *pr;
+	int cpu_index, device_declaration =3D 0;
+	static int cpu0_initialized;
+
+	pr =3D acpi_driver_data(device);
+	if (!pr)
+		return -EINVAL;
+
+	if (num_online_cpus() > 1)
+		errata.smp =3D TRUE;
+
+	acpi_processor_errata(pr);
+
+	/*
+	 * Check to see if we have bus mastering arbitration control.  This
+	 * is required for proper C3 usage (to maintain cache coherency).
+	 */
+	if (acpi_gbl_FADT.pm2_control_block && acpi_gbl_FADT.pm2_control_length) =
{
+		pr->flags.bm_control =3D 1;
+		ACPI_DEBUG_PRINT((ACPI_DB_INFO,
+				  "Bus mastering arbitration control present\n"));
+	} else
+		ACPI_DEBUG_PRINT((ACPI_DB_INFO,
+				  "No bus mastering arbitration control\n"));
+
+	if (!strcmp(acpi_device_hid(device), ACPI_PROCESSOR_OBJECT_HID)) {
+		/* Declared with "Processor" statement; match ProcessorID */
+		status =3D acpi_evaluate_object(pr->handle, NULL, NULL, &buffer);
+		if (ACPI_FAILURE(status)) {
+			printk(KERN_ERR PREFIX "Evaluating processor object\n");
+			return -ENODEV;
+		}
+
+		/*
+		 * TBD: Synch processor ID (via LAPIC/LSAPIC structures) on SMP.
+		 *      >>> 'acpi_get_processor_id(acpi_id, &id)' in
+		 *      arch/xxx/acpi.c
+		 */
+		pr->acpi_id =3D object.processor.proc_id;
+	} else {
+		/*
+		 * Declared with "Device" statement; match _UID.
+		 * Note that we don't handle string _UIDs yet.
+		 */
+		unsigned long long value;
+		status =3D acpi_evaluate_integer(pr->handle, METHOD_NAME__UID,
+						NULL, &value);
+		if (ACPI_FAILURE(status)) {
+			printk(KERN_ERR PREFIX
+			    "Evaluating processor _UID [%#x]\n", status);
+			return -ENODEV;
+		}
+		device_declaration =3D 1;
+		pr->acpi_id =3D value;
+	}
+
+	cpu_index =3D xen_pcpu_index(pr->acpi_id, 1);
+
+	/* Handle UP system running SMP kernel, with no LAPIC in MADT */
+	if (!cpu0_initialized && (cpu_index =3D=3D -1) &&
+	    (num_online_cpus() =3D=3D 1)) {
+		cpu_index =3D 0;
+	}
+
+	cpu0_initialized =3D 1;
+
+	pr->id =3D cpu_index;
+
+	/*
+	 *  Extra Processor objects may be enumerated on MP systems with
+	 *  less than the max # of CPUs. They should be ignored _iff
+	 *  they are physically not present.
+	 */
+	if (pr->id =3D=3D -1) {
+		if (ACPI_FAILURE
+		    (xen_acpi_processor_hotadd_init(pr, &pr->id))) {
+			return -ENODEV;
+		}
+	}
+	/*
+	 * On some boxes several processors use the same processor bus id.
+	 * But they are located in different scope. For example:
+	 * \_SB.SCK0.CPU0
+	 * \_SB.SCK1.CPU0
+	 * Rename the processor device bus id. And the new bus id will be
+	 * generated as the following format:
+	 * CPU+CPU ID.
+	 */
+	sprintf(acpi_device_bid(device), "CPU%X", pr->id);
+	ACPI_DEBUG_PRINT((ACPI_DB_INFO, "Processor [%d:%d]\n", pr->id,
+			  pr->acpi_id));
+
+	if (!object.processor.pblk_address)
+		ACPI_DEBUG_PRINT((ACPI_DB_INFO, "No PBLK (NULL address)\n"));
+	else if (object.processor.pblk_length !=3D 6)
+		printk(KERN_ERR PREFIX "Invalid PBLK length [%d]\n",
+			    object.processor.pblk_length);
+	else {
+		pr->throttling.address =3D object.processor.pblk_address;
+		pr->throttling.duty_offset =3D acpi_gbl_FADT.duty_offset;
+		pr->throttling.duty_width =3D acpi_gbl_FADT.duty_width;
+
+		pr->pblk =3D object.processor.pblk_address;
+
+		/*
+		 * We don't care about error returns - we just try to mark
+		 * these reserved so that nobody else is confused into thinking
+		 * that this region might be unused..
+		 *
+		 * (In particular, allocating the IO range for Cardbus)
+		 */
+		request_region(pr->throttling.address, 6, "ACPI CPU throttle");
+	}
+
+	/*
+	 * If ACPI describes a slot number for this CPU, we can use it
+	 * ensure we get the right value in the "physical id" field
+	 * of /proc/cpuinfo
+	 */
+	status =3D acpi_evaluate_object(pr->handle, "_SUN", NULL, &buffer);
+	if (ACPI_SUCCESS(status))
+		arch_fix_phys_package_id(pr->id, object.integer.value);
+
+	return 0;
+}
+
+static int __cpuinit __xen_acpi_processor_add(struct acpi_device *device)
+{
+	struct acpi_processor *pr =3D NULL;
+	int result =3D 0;
+	struct sys_device *sysdev;
+
+	pr =3D kzalloc(sizeof(struct acpi_processor), GFP_KERNEL);
+	if (!pr)
+		return -ENOMEM;
+
+	if (!zalloc_cpumask_var(&pr->throttling.shared_cpu_map, GFP_KERNEL)) {
+		kfree(pr);
+		return -ENOMEM;
+	}
+
+	pr->handle =3D device->handle;
+	strcpy(acpi_device_name(device), ACPI_PROCESSOR_DEVICE_NAME);
+	strcpy(acpi_device_class(device), ACPI_PROCESSOR_CLASS);
+	device->driver_data =3D pr;
+
+	result =3D xen_acpi_processor_get_info(device);
+	if (result) {
+		/* Processor is physically not present */
+		return 0;
+	}
+
+#ifdef CONFIG_SMP
+	if (pr->id >=3D setup_max_cpus && pr->id !=3D 0)
+		return 0;
+#endif
+
+	BUG_ON((pr->id >=3D nr_cpu_ids) || (pr->id < 0));
+
+	/*
+	 * Buggy BIOS check
+	 * ACPI id of processors can be reported wrongly by the BIOS.
+	 * Don't trust it blindly
+	 */
+	if (per_cpu(processor_device_array, pr->id) !=3D NULL &&
+	    per_cpu(processor_device_array, pr->id) !=3D device) {
+		printk(KERN_WARNING "BIOS reported wrong ACPI id "
+			"for the processor\n");
+		result =3D -ENODEV;
+		goto err_free_cpumask;
+	}
+	per_cpu(processor_device_array, pr->id) =3D device;
+
+	per_cpu(processors, pr->id) =3D pr;
+
+	sysdev =3D get_cpu_sysdev(pr->id);
+	if (sysfs_create_link(&device->dev.kobj, &sysdev->kobj, "sysdev")) {
+		result =3D -EFAULT;
+		goto err_free_cpumask;
+	}
+
+#ifdef CONFIG_CPU_FREQ
+	acpi_processor_ppc_has_changed(pr, 0);
+#endif
+	acpi_processor_get_throttling_info(pr);
+	acpi_processor_get_limit_info(pr);
+
+
+	if (cpuidle_get_driver() =3D=3D &acpi_idle_driver)
+		acpi_processor_power_init(pr, device);
+
+	pr->cdev =3D thermal_cooling_device_register("Processor", device,
+						&processor_cooling_ops);
+	if (IS_ERR(pr->cdev)) {
+		result =3D PTR_ERR(pr->cdev);
+		goto err_power_exit;
+	}
+
+	dev_dbg(&device->dev, "registered as cooling_device%d\n",
+		 pr->cdev->id);
+
+	result =3D sysfs_create_link(&device->dev.kobj,
+				   &pr->cdev->device.kobj,
+				   "thermal_cooling");
+	if (result) {
+		printk(KERN_ERR PREFIX "Create sysfs link\n");
+		goto err_thermal_unregister;
+	}
+	result =3D sysfs_create_link(&pr->cdev->device.kobj,
+				   &device->dev.kobj,
+				   "device");
+	if (result) {
+		printk(KERN_ERR PREFIX "Create sysfs link\n");
+		goto err_remove_sysfs;
+	}
+
+	return 0;
+
+err_remove_sysfs:
+	sysfs_remove_link(&device->dev.kobj, "thermal_cooling");
+err_thermal_unregister:
+	thermal_cooling_device_unregister(pr->cdev);
+err_power_exit:
+	acpi_processor_power_exit(pr, device);
+err_free_cpumask:
+	free_cpumask_var(pr->throttling.shared_cpu_map);
+
+	return result;
+}
+
 static int __cpuinit xen_acpi_processor_add(struct acpi_device *device)
 {
 	struct acpi_processor *pr =3D NULL;
 	int result =3D 0;
=20
-	result =3D acpi_processor_add(device);
-	if (result < 0)
+	result =3D __xen_acpi_processor_add(device);
+	if (result)
 		return result;
=20
 	pr =3D acpi_driver_data(device);
diff --git a/include/acpi/processor.h b/include/acpi/processor.h
index c48e2f9..3a1ee01 100644
--- a/include/acpi/processor.h
+++ b/include/acpi/processor.h
@@ -225,6 +225,8 @@ struct acpi_processor_errata {
 	} piix4;
 };
=20
+extern int acpi_processor_errata(struct acpi_processor *pr);
+
 extern int acpi_processor_preregister_performance(struct
 						  acpi_processor_performance
 						  __percpu *performance);
diff --git a/include/xen/pcpu.h b/include/xen/pcpu.h
index 7e8f9d1..3e99db9 100644
--- a/include/xen/pcpu.h
+++ b/include/xen/pcpu.h
@@ -4,6 +4,8 @@
 #include <xen/interface/platform.h>
 #include <linux/sysdev.h>
=20
+extern DEFINE_PER_CPU(void *, processor_device_array);
+
 extern int xen_pcpu_hotplug(int type, uint32_t apic_id);
 #define XEN_PCPU_ONLINE     0x01
 #define XEN_PCPU_OFFLINE    0x02
--=20
1.6.5.6

--_002_DE8DF0795D48FD4CA783C40EC82923359720SHSMSX101ccrcorpint_
Content-Type: application/octet-stream;
	name="0008-xen-acpi-add-cpu-hotadd-support.patch"
Content-Description: 0008-xen-acpi-add-cpu-hotadd-support.patch
Content-Disposition: attachment;
	filename="0008-xen-acpi-add-cpu-hotadd-support.patch"; size=10056;
	creation-date="Wed, 14 Dec 2011 15:20:15 GMT";
	modification-date="Wed, 14 Dec 2011 15:03:34 GMT"
Content-Transfer-Encoding: base64

RnJvbSAyODI5NThiZTNhMzNiMmYyYjg4OGUxZWQzYWMwMjJiZjhhMTk5ZWM5IE1vbiBTZXAgMTcg
MDA6MDA6MDAgMjAwMQpGcm9tOiBMaXUgSmluc29uZyA8amluc29uZy5saXVAaW50ZWwuY29tPgpE
YXRlOiBXZWQsIDE0IERlYyAyMDExIDExOjM4OjExICswODAwClN1YmplY3Q6IFtQQVRDSCAwOC8x
MF0geGVuL2FjcGk6IGFkZCBjcHUgaG90YWRkIHN1cHBvcnQKClRoaXMgcGF0Y2ggYWRkIGNwdSBo
b3RhZGQgc3VwcG9ydC4KSXQga2VlcCBzaW1pbGFyIGNwdSBob3RhZGQgbG9naWMgYXMgbmF0aXZl
LCB3LyBzb21lIGNoYW5nZXMgYWNjb3JkaW5nCnRvIHhlbiByZXF1aXJlbWVudCwgaHlwZXJjYWxs
aW5nIGh5cGVydmlzb3IgcmVsYXRlZCBsb2dpYyB0byBob3RhZGQgY3B1LgoKU2lnbmVkLW9mZi1i
eTogTGl1LCBKaW5zb25nIDxqaW5zb25nLmxpdUBpbnRlbC5jb20+ClNpZ25lZC1vZmYtYnk6IEpp
YW5nLCBZdW5ob25nIDx5dW5ob25nLmppYW5nQGludGVsLmNvbT4KLS0tCiBkcml2ZXJzL2FjcGkv
cHJvY2Vzc29yX2RyaXZlci5jIHwgICAgNCArLQogZHJpdmVycy9hY3BpL3Byb2Nlc3Nvcl94ZW4u
YyAgICB8ICAyNDIgKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKystCiBpbmNs
dWRlL2FjcGkvcHJvY2Vzc29yLmggICAgICAgIHwgICAgMiArCiBpbmNsdWRlL3hlbi9wY3B1Lmgg
ICAgICAgICAgICAgIHwgICAgMiArCiA0IGZpbGVzIGNoYW5nZWQsIDI0NiBpbnNlcnRpb25zKCsp
LCA0IGRlbGV0aW9ucygtKQoKZGlmZiAtLWdpdCBhL2RyaXZlcnMvYWNwaS9wcm9jZXNzb3JfZHJp
dmVyLmMgYi9kcml2ZXJzL2FjcGkvcHJvY2Vzc29yX2RyaXZlci5jCmluZGV4IDhhMzY3ZDcuLmQ0
NzNmZDUgMTAwNjQ0Ci0tLSBhL2RyaXZlcnMvYWNwaS9wcm9jZXNzb3JfZHJpdmVyLmMKKysrIGIv
ZHJpdmVycy9hY3BpL3Byb2Nlc3Nvcl9kcml2ZXIuYwpAQCAtMjIxLDcgKzIyMSw3IEBAIHN0YXRp
YyBpbnQgYWNwaV9wcm9jZXNzb3JfZXJyYXRhX3BpaXg0KHN0cnVjdCBwY2lfZGV2ICpkZXYpCiAJ
cmV0dXJuIDA7CiB9CiAKLXN0YXRpYyBpbnQgYWNwaV9wcm9jZXNzb3JfZXJyYXRhKHN0cnVjdCBh
Y3BpX3Byb2Nlc3NvciAqcHIpCitpbnQgYWNwaV9wcm9jZXNzb3JfZXJyYXRhKHN0cnVjdCBhY3Bp
X3Byb2Nlc3NvciAqcHIpCiB7CiAJaW50IHJlc3VsdCA9IDA7CiAJc3RydWN0IHBjaV9kZXYgKmRl
diA9IE5VTEw7CkBAIC0zNzgsNyArMzc4LDcgQEAgc3RhdGljIGludCBhY3BpX3Byb2Nlc3Nvcl9n
ZXRfaW5mbyhzdHJ1Y3QgYWNwaV9kZXZpY2UgKmRldmljZSkKIAlyZXR1cm4gMDsKIH0KIAotc3Rh
dGljIERFRklORV9QRVJfQ1BVKHZvaWQgKiwgcHJvY2Vzc29yX2RldmljZV9hcnJheSk7CitERUZJ
TkVfUEVSX0NQVSh2b2lkICosIHByb2Nlc3Nvcl9kZXZpY2VfYXJyYXkpOwogCiB2b2lkIGFjcGlf
cHJvY2Vzc29yX25vdGlmeShzdHJ1Y3QgYWNwaV9kZXZpY2UgKmRldmljZSwgdTMyIGV2ZW50KQog
ewpkaWZmIC0tZ2l0IGEvZHJpdmVycy9hY3BpL3Byb2Nlc3Nvcl94ZW4uYyBiL2RyaXZlcnMvYWNw
aS9wcm9jZXNzb3JfeGVuLmMKaW5kZXggMzhhMWMwNS4uM2FmMWY3MyAxMDA2NDQKLS0tIGEvZHJp
dmVycy9hY3BpL3Byb2Nlc3Nvcl94ZW4uYworKysgYi9kcml2ZXJzL2FjcGkvcHJvY2Vzc29yX3hl
bi5jCkBAIC0yNCw2ICsyNCw3IEBACiAjZGVmaW5lIFBSRUZJWCAiQUNQSTogIgogCiAjZGVmaW5l
IEFDUElfUFJPQ0VTU09SX0NMQVNTICAgICAgICAgICAgInByb2Nlc3NvciIKKyNkZWZpbmUgQUNQ
SV9QUk9DRVNTT1JfREVWSUNFX05BTUUgICAgICAiUHJvY2Vzc29yIgogI2RlZmluZSBBQ1BJX1BS
T0NFU1NPUl9OT1RJRllfUEVSRk9STUFOQ0UgMHg4MAogI2RlZmluZSBBQ1BJX1BST0NFU1NPUl9O
T1RJRllfUE9XRVIJMHg4MQogI2RlZmluZSBBQ1BJX1BST0NFU1NPUl9OT1RJRllfVEhST1RUTElO
RwkweDgyCkBAIC04OCw2ICs4OSw4IEBAIHhlbl9hY3BpX3Byb2Nlc3Nvcl9ob3RhZGRfaW5pdChz
dHJ1Y3QgYWNwaV9wcm9jZXNzb3IgKnByLCBpbnQgKnBfY3B1KQogCQkJCVBST0NFU1NPUl9IT1RQ
TFVHLCBIT1RQTFVHX1RZUEVfQUREKSkKIAkJcmV0dXJuIEFFX0VSUk9SOwogCisJKnBfY3B1ID0g
eGVuX3BjcHVfaW5kZXgocHItPmFjcGlfaWQsIDEpOworCiAJcmV0dXJuIEFFX09LOwogfQogCkBA
IC0xNDksMTMgKzE1MiwyNDggQEAgZXJyX291dDoKIH0KICNlbmRpZiAvKiBDT05GSUdfQ1BVX0ZS
RVEgKi8KIAorc3RhdGljIGludCB4ZW5fYWNwaV9wcm9jZXNzb3JfZ2V0X2luZm8oc3RydWN0IGFj
cGlfZGV2aWNlICpkZXZpY2UpCit7CisJYWNwaV9zdGF0dXMgc3RhdHVzID0gMDsKKwl1bmlvbiBh
Y3BpX29iamVjdCBvYmplY3QgPSB7IDAgfTsKKwlzdHJ1Y3QgYWNwaV9idWZmZXIgYnVmZmVyID0g
eyBzaXplb2YodW5pb24gYWNwaV9vYmplY3QpLCAmb2JqZWN0IH07CisJc3RydWN0IGFjcGlfcHJv
Y2Vzc29yICpwcjsKKwlpbnQgY3B1X2luZGV4LCBkZXZpY2VfZGVjbGFyYXRpb24gPSAwOworCXN0
YXRpYyBpbnQgY3B1MF9pbml0aWFsaXplZDsKKworCXByID0gYWNwaV9kcml2ZXJfZGF0YShkZXZp
Y2UpOworCWlmICghcHIpCisJCXJldHVybiAtRUlOVkFMOworCisJaWYgKG51bV9vbmxpbmVfY3B1
cygpID4gMSkKKwkJZXJyYXRhLnNtcCA9IFRSVUU7CisKKwlhY3BpX3Byb2Nlc3Nvcl9lcnJhdGEo
cHIpOworCisJLyoKKwkgKiBDaGVjayB0byBzZWUgaWYgd2UgaGF2ZSBidXMgbWFzdGVyaW5nIGFy
Yml0cmF0aW9uIGNvbnRyb2wuICBUaGlzCisJICogaXMgcmVxdWlyZWQgZm9yIHByb3BlciBDMyB1
c2FnZSAodG8gbWFpbnRhaW4gY2FjaGUgY29oZXJlbmN5KS4KKwkgKi8KKwlpZiAoYWNwaV9nYmxf
RkFEVC5wbTJfY29udHJvbF9ibG9jayAmJiBhY3BpX2dibF9GQURULnBtMl9jb250cm9sX2xlbmd0
aCkgeworCQlwci0+ZmxhZ3MuYm1fY29udHJvbCA9IDE7CisJCUFDUElfREVCVUdfUFJJTlQoKEFD
UElfREJfSU5GTywKKwkJCQkgICJCdXMgbWFzdGVyaW5nIGFyYml0cmF0aW9uIGNvbnRyb2wgcHJl
c2VudFxuIikpOworCX0gZWxzZQorCQlBQ1BJX0RFQlVHX1BSSU5UKChBQ1BJX0RCX0lORk8sCisJ
CQkJICAiTm8gYnVzIG1hc3RlcmluZyBhcmJpdHJhdGlvbiBjb250cm9sXG4iKSk7CisKKwlpZiAo
IXN0cmNtcChhY3BpX2RldmljZV9oaWQoZGV2aWNlKSwgQUNQSV9QUk9DRVNTT1JfT0JKRUNUX0hJ
RCkpIHsKKwkJLyogRGVjbGFyZWQgd2l0aCAiUHJvY2Vzc29yIiBzdGF0ZW1lbnQ7IG1hdGNoIFBy
b2Nlc3NvcklEICovCisJCXN0YXR1cyA9IGFjcGlfZXZhbHVhdGVfb2JqZWN0KHByLT5oYW5kbGUs
IE5VTEwsIE5VTEwsICZidWZmZXIpOworCQlpZiAoQUNQSV9GQUlMVVJFKHN0YXR1cykpIHsKKwkJ
CXByaW50ayhLRVJOX0VSUiBQUkVGSVggIkV2YWx1YXRpbmcgcHJvY2Vzc29yIG9iamVjdFxuIik7
CisJCQlyZXR1cm4gLUVOT0RFVjsKKwkJfQorCisJCS8qCisJCSAqIFRCRDogU3luY2ggcHJvY2Vz
c29yIElEICh2aWEgTEFQSUMvTFNBUElDIHN0cnVjdHVyZXMpIG9uIFNNUC4KKwkJICogICAgICA+
Pj4gJ2FjcGlfZ2V0X3Byb2Nlc3Nvcl9pZChhY3BpX2lkLCAmaWQpJyBpbgorCQkgKiAgICAgIGFy
Y2gveHh4L2FjcGkuYworCQkgKi8KKwkJcHItPmFjcGlfaWQgPSBvYmplY3QucHJvY2Vzc29yLnBy
b2NfaWQ7CisJfSBlbHNlIHsKKwkJLyoKKwkJICogRGVjbGFyZWQgd2l0aCAiRGV2aWNlIiBzdGF0
ZW1lbnQ7IG1hdGNoIF9VSUQuCisJCSAqIE5vdGUgdGhhdCB3ZSBkb24ndCBoYW5kbGUgc3RyaW5n
IF9VSURzIHlldC4KKwkJICovCisJCXVuc2lnbmVkIGxvbmcgbG9uZyB2YWx1ZTsKKwkJc3RhdHVz
ID0gYWNwaV9ldmFsdWF0ZV9pbnRlZ2VyKHByLT5oYW5kbGUsIE1FVEhPRF9OQU1FX19VSUQsCisJ
CQkJCQlOVUxMLCAmdmFsdWUpOworCQlpZiAoQUNQSV9GQUlMVVJFKHN0YXR1cykpIHsKKwkJCXBy
aW50ayhLRVJOX0VSUiBQUkVGSVgKKwkJCSAgICAiRXZhbHVhdGluZyBwcm9jZXNzb3IgX1VJRCBb
JSN4XVxuIiwgc3RhdHVzKTsKKwkJCXJldHVybiAtRU5PREVWOworCQl9CisJCWRldmljZV9kZWNs
YXJhdGlvbiA9IDE7CisJCXByLT5hY3BpX2lkID0gdmFsdWU7CisJfQorCisJY3B1X2luZGV4ID0g
eGVuX3BjcHVfaW5kZXgocHItPmFjcGlfaWQsIDEpOworCisJLyogSGFuZGxlIFVQIHN5c3RlbSBy
dW5uaW5nIFNNUCBrZXJuZWwsIHdpdGggbm8gTEFQSUMgaW4gTUFEVCAqLworCWlmICghY3B1MF9p
bml0aWFsaXplZCAmJiAoY3B1X2luZGV4ID09IC0xKSAmJgorCSAgICAobnVtX29ubGluZV9jcHVz
KCkgPT0gMSkpIHsKKwkJY3B1X2luZGV4ID0gMDsKKwl9CisKKwljcHUwX2luaXRpYWxpemVkID0g
MTsKKworCXByLT5pZCA9IGNwdV9pbmRleDsKKworCS8qCisJICogIEV4dHJhIFByb2Nlc3NvciBv
YmplY3RzIG1heSBiZSBlbnVtZXJhdGVkIG9uIE1QIHN5c3RlbXMgd2l0aAorCSAqICBsZXNzIHRo
YW4gdGhlIG1heCAjIG9mIENQVXMuIFRoZXkgc2hvdWxkIGJlIGlnbm9yZWQgX2lmZgorCSAqICB0
aGV5IGFyZSBwaHlzaWNhbGx5IG5vdCBwcmVzZW50LgorCSAqLworCWlmIChwci0+aWQgPT0gLTEp
IHsKKwkJaWYgKEFDUElfRkFJTFVSRQorCQkgICAgKHhlbl9hY3BpX3Byb2Nlc3Nvcl9ob3RhZGRf
aW5pdChwciwgJnByLT5pZCkpKSB7CisJCQlyZXR1cm4gLUVOT0RFVjsKKwkJfQorCX0KKwkvKgor
CSAqIE9uIHNvbWUgYm94ZXMgc2V2ZXJhbCBwcm9jZXNzb3JzIHVzZSB0aGUgc2FtZSBwcm9jZXNz
b3IgYnVzIGlkLgorCSAqIEJ1dCB0aGV5IGFyZSBsb2NhdGVkIGluIGRpZmZlcmVudCBzY29wZS4g
Rm9yIGV4YW1wbGU6CisJICogXF9TQi5TQ0swLkNQVTAKKwkgKiBcX1NCLlNDSzEuQ1BVMAorCSAq
IFJlbmFtZSB0aGUgcHJvY2Vzc29yIGRldmljZSBidXMgaWQuIEFuZCB0aGUgbmV3IGJ1cyBpZCB3
aWxsIGJlCisJICogZ2VuZXJhdGVkIGFzIHRoZSBmb2xsb3dpbmcgZm9ybWF0OgorCSAqIENQVStD
UFUgSUQuCisJICovCisJc3ByaW50ZihhY3BpX2RldmljZV9iaWQoZGV2aWNlKSwgIkNQVSVYIiwg
cHItPmlkKTsKKwlBQ1BJX0RFQlVHX1BSSU5UKChBQ1BJX0RCX0lORk8sICJQcm9jZXNzb3IgWyVk
OiVkXVxuIiwgcHItPmlkLAorCQkJICBwci0+YWNwaV9pZCkpOworCisJaWYgKCFvYmplY3QucHJv
Y2Vzc29yLnBibGtfYWRkcmVzcykKKwkJQUNQSV9ERUJVR19QUklOVCgoQUNQSV9EQl9JTkZPLCAi
Tm8gUEJMSyAoTlVMTCBhZGRyZXNzKVxuIikpOworCWVsc2UgaWYgKG9iamVjdC5wcm9jZXNzb3Iu
cGJsa19sZW5ndGggIT0gNikKKwkJcHJpbnRrKEtFUk5fRVJSIFBSRUZJWCAiSW52YWxpZCBQQkxL
IGxlbmd0aCBbJWRdXG4iLAorCQkJICAgIG9iamVjdC5wcm9jZXNzb3IucGJsa19sZW5ndGgpOwor
CWVsc2UgeworCQlwci0+dGhyb3R0bGluZy5hZGRyZXNzID0gb2JqZWN0LnByb2Nlc3Nvci5wYmxr
X2FkZHJlc3M7CisJCXByLT50aHJvdHRsaW5nLmR1dHlfb2Zmc2V0ID0gYWNwaV9nYmxfRkFEVC5k
dXR5X29mZnNldDsKKwkJcHItPnRocm90dGxpbmcuZHV0eV93aWR0aCA9IGFjcGlfZ2JsX0ZBRFQu
ZHV0eV93aWR0aDsKKworCQlwci0+cGJsayA9IG9iamVjdC5wcm9jZXNzb3IucGJsa19hZGRyZXNz
OworCisJCS8qCisJCSAqIFdlIGRvbid0IGNhcmUgYWJvdXQgZXJyb3IgcmV0dXJucyAtIHdlIGp1
c3QgdHJ5IHRvIG1hcmsKKwkJICogdGhlc2UgcmVzZXJ2ZWQgc28gdGhhdCBub2JvZHkgZWxzZSBp
cyBjb25mdXNlZCBpbnRvIHRoaW5raW5nCisJCSAqIHRoYXQgdGhpcyByZWdpb24gbWlnaHQgYmUg
dW51c2VkLi4KKwkJICoKKwkJICogKEluIHBhcnRpY3VsYXIsIGFsbG9jYXRpbmcgdGhlIElPIHJh
bmdlIGZvciBDYXJkYnVzKQorCQkgKi8KKwkJcmVxdWVzdF9yZWdpb24ocHItPnRocm90dGxpbmcu
YWRkcmVzcywgNiwgIkFDUEkgQ1BVIHRocm90dGxlIik7CisJfQorCisJLyoKKwkgKiBJZiBBQ1BJ
IGRlc2NyaWJlcyBhIHNsb3QgbnVtYmVyIGZvciB0aGlzIENQVSwgd2UgY2FuIHVzZSBpdAorCSAq
IGVuc3VyZSB3ZSBnZXQgdGhlIHJpZ2h0IHZhbHVlIGluIHRoZSAicGh5c2ljYWwgaWQiIGZpZWxk
CisJICogb2YgL3Byb2MvY3B1aW5mbworCSAqLworCXN0YXR1cyA9IGFjcGlfZXZhbHVhdGVfb2Jq
ZWN0KHByLT5oYW5kbGUsICJfU1VOIiwgTlVMTCwgJmJ1ZmZlcik7CisJaWYgKEFDUElfU1VDQ0VT
UyhzdGF0dXMpKQorCQlhcmNoX2ZpeF9waHlzX3BhY2thZ2VfaWQocHItPmlkLCBvYmplY3QuaW50
ZWdlci52YWx1ZSk7CisKKwlyZXR1cm4gMDsKK30KKworc3RhdGljIGludCBfX2NwdWluaXQgX194
ZW5fYWNwaV9wcm9jZXNzb3JfYWRkKHN0cnVjdCBhY3BpX2RldmljZSAqZGV2aWNlKQoreworCXN0
cnVjdCBhY3BpX3Byb2Nlc3NvciAqcHIgPSBOVUxMOworCWludCByZXN1bHQgPSAwOworCXN0cnVj
dCBzeXNfZGV2aWNlICpzeXNkZXY7CisKKwlwciA9IGt6YWxsb2Moc2l6ZW9mKHN0cnVjdCBhY3Bp
X3Byb2Nlc3NvciksIEdGUF9LRVJORUwpOworCWlmICghcHIpCisJCXJldHVybiAtRU5PTUVNOwor
CisJaWYgKCF6YWxsb2NfY3B1bWFza192YXIoJnByLT50aHJvdHRsaW5nLnNoYXJlZF9jcHVfbWFw
LCBHRlBfS0VSTkVMKSkgeworCQlrZnJlZShwcik7CisJCXJldHVybiAtRU5PTUVNOworCX0KKwor
CXByLT5oYW5kbGUgPSBkZXZpY2UtPmhhbmRsZTsKKwlzdHJjcHkoYWNwaV9kZXZpY2VfbmFtZShk
ZXZpY2UpLCBBQ1BJX1BST0NFU1NPUl9ERVZJQ0VfTkFNRSk7CisJc3RyY3B5KGFjcGlfZGV2aWNl
X2NsYXNzKGRldmljZSksIEFDUElfUFJPQ0VTU09SX0NMQVNTKTsKKwlkZXZpY2UtPmRyaXZlcl9k
YXRhID0gcHI7CisKKwlyZXN1bHQgPSB4ZW5fYWNwaV9wcm9jZXNzb3JfZ2V0X2luZm8oZGV2aWNl
KTsKKwlpZiAocmVzdWx0KSB7CisJCS8qIFByb2Nlc3NvciBpcyBwaHlzaWNhbGx5IG5vdCBwcmVz
ZW50ICovCisJCXJldHVybiAwOworCX0KKworI2lmZGVmIENPTkZJR19TTVAKKwlpZiAocHItPmlk
ID49IHNldHVwX21heF9jcHVzICYmIHByLT5pZCAhPSAwKQorCQlyZXR1cm4gMDsKKyNlbmRpZgor
CisJQlVHX09OKChwci0+aWQgPj0gbnJfY3B1X2lkcykgfHwgKHByLT5pZCA8IDApKTsKKworCS8q
CisJICogQnVnZ3kgQklPUyBjaGVjaworCSAqIEFDUEkgaWQgb2YgcHJvY2Vzc29ycyBjYW4gYmUg
cmVwb3J0ZWQgd3JvbmdseSBieSB0aGUgQklPUy4KKwkgKiBEb24ndCB0cnVzdCBpdCBibGluZGx5
CisJICovCisJaWYgKHBlcl9jcHUocHJvY2Vzc29yX2RldmljZV9hcnJheSwgcHItPmlkKSAhPSBO
VUxMICYmCisJICAgIHBlcl9jcHUocHJvY2Vzc29yX2RldmljZV9hcnJheSwgcHItPmlkKSAhPSBk
ZXZpY2UpIHsKKwkJcHJpbnRrKEtFUk5fV0FSTklORyAiQklPUyByZXBvcnRlZCB3cm9uZyBBQ1BJ
IGlkICIKKwkJCSJmb3IgdGhlIHByb2Nlc3NvclxuIik7CisJCXJlc3VsdCA9IC1FTk9ERVY7CisJ
CWdvdG8gZXJyX2ZyZWVfY3B1bWFzazsKKwl9CisJcGVyX2NwdShwcm9jZXNzb3JfZGV2aWNlX2Fy
cmF5LCBwci0+aWQpID0gZGV2aWNlOworCisJcGVyX2NwdShwcm9jZXNzb3JzLCBwci0+aWQpID0g
cHI7CisKKwlzeXNkZXYgPSBnZXRfY3B1X3N5c2Rldihwci0+aWQpOworCWlmIChzeXNmc19jcmVh
dGVfbGluaygmZGV2aWNlLT5kZXYua29iaiwgJnN5c2Rldi0+a29iaiwgInN5c2RldiIpKSB7CisJ
CXJlc3VsdCA9IC1FRkFVTFQ7CisJCWdvdG8gZXJyX2ZyZWVfY3B1bWFzazsKKwl9CisKKyNpZmRl
ZiBDT05GSUdfQ1BVX0ZSRVEKKwlhY3BpX3Byb2Nlc3Nvcl9wcGNfaGFzX2NoYW5nZWQocHIsIDAp
OworI2VuZGlmCisJYWNwaV9wcm9jZXNzb3JfZ2V0X3Rocm90dGxpbmdfaW5mbyhwcik7CisJYWNw
aV9wcm9jZXNzb3JfZ2V0X2xpbWl0X2luZm8ocHIpOworCisKKwlpZiAoY3B1aWRsZV9nZXRfZHJp
dmVyKCkgPT0gJmFjcGlfaWRsZV9kcml2ZXIpCisJCWFjcGlfcHJvY2Vzc29yX3Bvd2VyX2luaXQo
cHIsIGRldmljZSk7CisKKwlwci0+Y2RldiA9IHRoZXJtYWxfY29vbGluZ19kZXZpY2VfcmVnaXN0
ZXIoIlByb2Nlc3NvciIsIGRldmljZSwKKwkJCQkJCSZwcm9jZXNzb3JfY29vbGluZ19vcHMpOwor
CWlmIChJU19FUlIocHItPmNkZXYpKSB7CisJCXJlc3VsdCA9IFBUUl9FUlIocHItPmNkZXYpOwor
CQlnb3RvIGVycl9wb3dlcl9leGl0OworCX0KKworCWRldl9kYmcoJmRldmljZS0+ZGV2LCAicmVn
aXN0ZXJlZCBhcyBjb29saW5nX2RldmljZSVkXG4iLAorCQkgcHItPmNkZXYtPmlkKTsKKworCXJl
c3VsdCA9IHN5c2ZzX2NyZWF0ZV9saW5rKCZkZXZpY2UtPmRldi5rb2JqLAorCQkJCSAgICZwci0+
Y2Rldi0+ZGV2aWNlLmtvYmosCisJCQkJICAgInRoZXJtYWxfY29vbGluZyIpOworCWlmIChyZXN1
bHQpIHsKKwkJcHJpbnRrKEtFUk5fRVJSIFBSRUZJWCAiQ3JlYXRlIHN5c2ZzIGxpbmtcbiIpOwor
CQlnb3RvIGVycl90aGVybWFsX3VucmVnaXN0ZXI7CisJfQorCXJlc3VsdCA9IHN5c2ZzX2NyZWF0
ZV9saW5rKCZwci0+Y2Rldi0+ZGV2aWNlLmtvYmosCisJCQkJICAgJmRldmljZS0+ZGV2LmtvYmos
CisJCQkJICAgImRldmljZSIpOworCWlmIChyZXN1bHQpIHsKKwkJcHJpbnRrKEtFUk5fRVJSIFBS
RUZJWCAiQ3JlYXRlIHN5c2ZzIGxpbmtcbiIpOworCQlnb3RvIGVycl9yZW1vdmVfc3lzZnM7CisJ
fQorCisJcmV0dXJuIDA7CisKK2Vycl9yZW1vdmVfc3lzZnM6CisJc3lzZnNfcmVtb3ZlX2xpbmso
JmRldmljZS0+ZGV2LmtvYmosICJ0aGVybWFsX2Nvb2xpbmciKTsKK2Vycl90aGVybWFsX3VucmVn
aXN0ZXI6CisJdGhlcm1hbF9jb29saW5nX2RldmljZV91bnJlZ2lzdGVyKHByLT5jZGV2KTsKK2Vy
cl9wb3dlcl9leGl0OgorCWFjcGlfcHJvY2Vzc29yX3Bvd2VyX2V4aXQocHIsIGRldmljZSk7Citl
cnJfZnJlZV9jcHVtYXNrOgorCWZyZWVfY3B1bWFza192YXIocHItPnRocm90dGxpbmcuc2hhcmVk
X2NwdV9tYXApOworCisJcmV0dXJuIHJlc3VsdDsKK30KKwogc3RhdGljIGludCBfX2NwdWluaXQg
eGVuX2FjcGlfcHJvY2Vzc29yX2FkZChzdHJ1Y3QgYWNwaV9kZXZpY2UgKmRldmljZSkKIHsKIAlz
dHJ1Y3QgYWNwaV9wcm9jZXNzb3IgKnByID0gTlVMTDsKIAlpbnQgcmVzdWx0ID0gMDsKIAotCXJl
c3VsdCA9IGFjcGlfcHJvY2Vzc29yX2FkZChkZXZpY2UpOwotCWlmIChyZXN1bHQgPCAwKQorCXJl
c3VsdCA9IF9feGVuX2FjcGlfcHJvY2Vzc29yX2FkZChkZXZpY2UpOworCWlmIChyZXN1bHQpCiAJ
CXJldHVybiByZXN1bHQ7CiAKIAlwciA9IGFjcGlfZHJpdmVyX2RhdGEoZGV2aWNlKTsKZGlmZiAt
LWdpdCBhL2luY2x1ZGUvYWNwaS9wcm9jZXNzb3IuaCBiL2luY2x1ZGUvYWNwaS9wcm9jZXNzb3Iu
aAppbmRleCBjNDhlMmY5Li4zYTFlZTAxIDEwMDY0NAotLS0gYS9pbmNsdWRlL2FjcGkvcHJvY2Vz
c29yLmgKKysrIGIvaW5jbHVkZS9hY3BpL3Byb2Nlc3Nvci5oCkBAIC0yMjUsNiArMjI1LDggQEAg
c3RydWN0IGFjcGlfcHJvY2Vzc29yX2VycmF0YSB7CiAJfSBwaWl4NDsKIH07CiAKK2V4dGVybiBp
bnQgYWNwaV9wcm9jZXNzb3JfZXJyYXRhKHN0cnVjdCBhY3BpX3Byb2Nlc3NvciAqcHIpOworCiBl
eHRlcm4gaW50IGFjcGlfcHJvY2Vzc29yX3ByZXJlZ2lzdGVyX3BlcmZvcm1hbmNlKHN0cnVjdAog
CQkJCQkJICBhY3BpX3Byb2Nlc3Nvcl9wZXJmb3JtYW5jZQogCQkJCQkJICBfX3BlcmNwdSAqcGVy
Zm9ybWFuY2UpOwpkaWZmIC0tZ2l0IGEvaW5jbHVkZS94ZW4vcGNwdS5oIGIvaW5jbHVkZS94ZW4v
cGNwdS5oCmluZGV4IDdlOGY5ZDEuLjNlOTlkYjkgMTAwNjQ0Ci0tLSBhL2luY2x1ZGUveGVuL3Bj
cHUuaAorKysgYi9pbmNsdWRlL3hlbi9wY3B1LmgKQEAgLTQsNiArNCw4IEBACiAjaW5jbHVkZSA8
eGVuL2ludGVyZmFjZS9wbGF0Zm9ybS5oPgogI2luY2x1ZGUgPGxpbnV4L3N5c2Rldi5oPgogCitl
eHRlcm4gREVGSU5FX1BFUl9DUFUodm9pZCAqLCBwcm9jZXNzb3JfZGV2aWNlX2FycmF5KTsKKwog
ZXh0ZXJuIGludCB4ZW5fcGNwdV9ob3RwbHVnKGludCB0eXBlLCB1aW50MzJfdCBhcGljX2lkKTsK
ICNkZWZpbmUgWEVOX1BDUFVfT05MSU5FICAgICAweDAxCiAjZGVmaW5lIFhFTl9QQ1BVX09GRkxJ
TkUgICAgMHgwMgotLSAKMS42LjUuNgoK

--_002_DE8DF0795D48FD4CA783C40EC82923359720SHSMSX101ccrcorpint_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--_002_DE8DF0795D48FD4CA783C40EC82923359720SHSMSX101ccrcorpint_--


From xen-devel-bounces@lists.xensource.com Fri Dec 23 10:30:48 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 Dec 2011 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.xensource.com>)
	id 1Re2Oe-0006u1-CA; Fri, 23 Dec 2011 10:30:40 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1Re2Oc-0006tH-CM
	for xen-devel@lists.xensource.com; Fri, 23 Dec 2011 10:30:38 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1324636186!50159685!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDMwMDk1NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14171 invoked from network); 23 Dec 2011 10:29:47 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-3.tower-27.messagelabs.com with SMTP;
	23 Dec 2011 10:29:47 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga102.fm.intel.com with ESMTP; 23 Dec 2011 02:30:32 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208,223";a="99639487"
Received: from pgsmsx602.gar.corp.intel.com ([10.221.43.81])
	by fmsmga001.fm.intel.com with ESMTP; 23 Dec 2011 02:30:31 -0800
Received: from pgsmsx104.gar.corp.intel.com (10.221.44.91) by
	pgsmsx602.gar.corp.intel.com (10.221.43.81) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Fri, 23 Dec 2011 18:30:15 +0800
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	PGSMSX104.gar.corp.intel.com (10.221.44.91) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Fri, 23 Dec 2011 18:30:14 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.38]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.199]) with mapi id
	14.01.0355.002; Fri, 23 Dec 2011 18:30:12 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: "konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
Thread-Topic: [PATCH 08/10] xen/acpi: add cpu hotadd support
Thread-Index: AczBXdnxG/uZZT4gQla9H//97c2bRw==
Date: Fri, 23 Dec 2011 10:30:12 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC82923359720@SHSMSX101.ccr.corp.intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
Content-Type: multipart/mixed;
	boundary="_002_DE8DF0795D48FD4CA783C40EC82923359720SHSMSX101ccrcorpint_"
MIME-Version: 1.0
Cc: "Brown, Len" <len.brown@intel.com>,
	"jeremy.fitzhardinge@citrix.com" <jeremy.fitzhardinge@citrix.com>,
	"Jiang, Yunhong" <yunhong.jiang@intel.com>, "Shan, 
	Haitao" <haitao.shan@intel.com>,
	Kernel development list <linux-kernel@vger.kernel.org>, "Zhao,
	Yakui" <yakui.zhao@intel.com>, "Luck, Tony" <tony.luck@intel.com>, "Kleen,
	Andi" <andi.kleen@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: [Xen-devel] [PATCH 08/10] xen/acpi: add cpu hotadd support
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--_002_DE8DF0795D48FD4CA783C40EC82923359720SHSMSX101ccrcorpint_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

>From 282958be3a33b2f2b888e1ed3ac022bf8a199ec9 Mon Sep 17 00:00:00 2001
From: Liu Jinsong <jinsong.liu@intel.com>
Date: Wed, 14 Dec 2011 11:38:11 +0800
Subject: [PATCH 08/10] xen/acpi: add cpu hotadd support

This patch add cpu hotadd support.
It keep similar cpu hotadd logic as native, w/ some changes according
to xen requirement, hypercalling hypervisor related logic to hotadd cpu.

Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
Signed-off-by: Jiang, Yunhong <yunhong.jiang@intel.com>
---
 drivers/acpi/processor_driver.c |    4 +-
 drivers/acpi/processor_xen.c    |  242 +++++++++++++++++++++++++++++++++++=
+++-
 include/acpi/processor.h        |    2 +
 include/xen/pcpu.h              |    2 +
 4 files changed, 246 insertions(+), 4 deletions(-)

diff --git a/drivers/acpi/processor_driver.c b/drivers/acpi/processor_drive=
r.c
index 8a367d7..d473fd5 100644
--- a/drivers/acpi/processor_driver.c
+++ b/drivers/acpi/processor_driver.c
@@ -221,7 +221,7 @@ static int acpi_processor_errata_piix4(struct pci_dev *=
dev)
 	return 0;
 }
=20
-static int acpi_processor_errata(struct acpi_processor *pr)
+int acpi_processor_errata(struct acpi_processor *pr)
 {
 	int result =3D 0;
 	struct pci_dev *dev =3D NULL;
@@ -378,7 +378,7 @@ static int acpi_processor_get_info(struct acpi_device *=
device)
 	return 0;
 }
=20
-static DEFINE_PER_CPU(void *, processor_device_array);
+DEFINE_PER_CPU(void *, processor_device_array);
=20
 void acpi_processor_notify(struct acpi_device *device, u32 event)
 {
diff --git a/drivers/acpi/processor_xen.c b/drivers/acpi/processor_xen.c
index 38a1c05..3af1f73 100644
--- a/drivers/acpi/processor_xen.c
+++ b/drivers/acpi/processor_xen.c
@@ -24,6 +24,7 @@
 #define PREFIX "ACPI: "
=20
 #define ACPI_PROCESSOR_CLASS            "processor"
+#define ACPI_PROCESSOR_DEVICE_NAME      "Processor"
 #define ACPI_PROCESSOR_NOTIFY_PERFORMANCE 0x80
 #define ACPI_PROCESSOR_NOTIFY_POWER	0x81
 #define ACPI_PROCESSOR_NOTIFY_THROTTLING	0x82
@@ -88,6 +89,8 @@ xen_acpi_processor_hotadd_init(struct acpi_processor *pr,=
 int *p_cpu)
 				PROCESSOR_HOTPLUG, HOTPLUG_TYPE_ADD))
 		return AE_ERROR;
=20
+	*p_cpu =3D xen_pcpu_index(pr->acpi_id, 1);
+
 	return AE_OK;
 }
=20
@@ -149,13 +152,248 @@ err_out:
 }
 #endif /* CONFIG_CPU_FREQ */
=20
+static int xen_acpi_processor_get_info(struct acpi_device *device)
+{
+	acpi_status status =3D 0;
+	union acpi_object object =3D { 0 };
+	struct acpi_buffer buffer =3D { sizeof(union acpi_object), &object };
+	struct acpi_processor *pr;
+	int cpu_index, device_declaration =3D 0;
+	static int cpu0_initialized;
+
+	pr =3D acpi_driver_data(device);
+	if (!pr)
+		return -EINVAL;
+
+	if (num_online_cpus() > 1)
+		errata.smp =3D TRUE;
+
+	acpi_processor_errata(pr);
+
+	/*
+	 * Check to see if we have bus mastering arbitration control.  This
+	 * is required for proper C3 usage (to maintain cache coherency).
+	 */
+	if (acpi_gbl_FADT.pm2_control_block && acpi_gbl_FADT.pm2_control_length) =
{
+		pr->flags.bm_control =3D 1;
+		ACPI_DEBUG_PRINT((ACPI_DB_INFO,
+				  "Bus mastering arbitration control present\n"));
+	} else
+		ACPI_DEBUG_PRINT((ACPI_DB_INFO,
+				  "No bus mastering arbitration control\n"));
+
+	if (!strcmp(acpi_device_hid(device), ACPI_PROCESSOR_OBJECT_HID)) {
+		/* Declared with "Processor" statement; match ProcessorID */
+		status =3D acpi_evaluate_object(pr->handle, NULL, NULL, &buffer);
+		if (ACPI_FAILURE(status)) {
+			printk(KERN_ERR PREFIX "Evaluating processor object\n");
+			return -ENODEV;
+		}
+
+		/*
+		 * TBD: Synch processor ID (via LAPIC/LSAPIC structures) on SMP.
+		 *      >>> 'acpi_get_processor_id(acpi_id, &id)' in
+		 *      arch/xxx/acpi.c
+		 */
+		pr->acpi_id =3D object.processor.proc_id;
+	} else {
+		/*
+		 * Declared with "Device" statement; match _UID.
+		 * Note that we don't handle string _UIDs yet.
+		 */
+		unsigned long long value;
+		status =3D acpi_evaluate_integer(pr->handle, METHOD_NAME__UID,
+						NULL, &value);
+		if (ACPI_FAILURE(status)) {
+			printk(KERN_ERR PREFIX
+			    "Evaluating processor _UID [%#x]\n", status);
+			return -ENODEV;
+		}
+		device_declaration =3D 1;
+		pr->acpi_id =3D value;
+	}
+
+	cpu_index =3D xen_pcpu_index(pr->acpi_id, 1);
+
+	/* Handle UP system running SMP kernel, with no LAPIC in MADT */
+	if (!cpu0_initialized && (cpu_index =3D=3D -1) &&
+	    (num_online_cpus() =3D=3D 1)) {
+		cpu_index =3D 0;
+	}
+
+	cpu0_initialized =3D 1;
+
+	pr->id =3D cpu_index;
+
+	/*
+	 *  Extra Processor objects may be enumerated on MP systems with
+	 *  less than the max # of CPUs. They should be ignored _iff
+	 *  they are physically not present.
+	 */
+	if (pr->id =3D=3D -1) {
+		if (ACPI_FAILURE
+		    (xen_acpi_processor_hotadd_init(pr, &pr->id))) {
+			return -ENODEV;
+		}
+	}
+	/*
+	 * On some boxes several processors use the same processor bus id.
+	 * But they are located in different scope. For example:
+	 * \_SB.SCK0.CPU0
+	 * \_SB.SCK1.CPU0
+	 * Rename the processor device bus id. And the new bus id will be
+	 * generated as the following format:
+	 * CPU+CPU ID.
+	 */
+	sprintf(acpi_device_bid(device), "CPU%X", pr->id);
+	ACPI_DEBUG_PRINT((ACPI_DB_INFO, "Processor [%d:%d]\n", pr->id,
+			  pr->acpi_id));
+
+	if (!object.processor.pblk_address)
+		ACPI_DEBUG_PRINT((ACPI_DB_INFO, "No PBLK (NULL address)\n"));
+	else if (object.processor.pblk_length !=3D 6)
+		printk(KERN_ERR PREFIX "Invalid PBLK length [%d]\n",
+			    object.processor.pblk_length);
+	else {
+		pr->throttling.address =3D object.processor.pblk_address;
+		pr->throttling.duty_offset =3D acpi_gbl_FADT.duty_offset;
+		pr->throttling.duty_width =3D acpi_gbl_FADT.duty_width;
+
+		pr->pblk =3D object.processor.pblk_address;
+
+		/*
+		 * We don't care about error returns - we just try to mark
+		 * these reserved so that nobody else is confused into thinking
+		 * that this region might be unused..
+		 *
+		 * (In particular, allocating the IO range for Cardbus)
+		 */
+		request_region(pr->throttling.address, 6, "ACPI CPU throttle");
+	}
+
+	/*
+	 * If ACPI describes a slot number for this CPU, we can use it
+	 * ensure we get the right value in the "physical id" field
+	 * of /proc/cpuinfo
+	 */
+	status =3D acpi_evaluate_object(pr->handle, "_SUN", NULL, &buffer);
+	if (ACPI_SUCCESS(status))
+		arch_fix_phys_package_id(pr->id, object.integer.value);
+
+	return 0;
+}
+
+static int __cpuinit __xen_acpi_processor_add(struct acpi_device *device)
+{
+	struct acpi_processor *pr =3D NULL;
+	int result =3D 0;
+	struct sys_device *sysdev;
+
+	pr =3D kzalloc(sizeof(struct acpi_processor), GFP_KERNEL);
+	if (!pr)
+		return -ENOMEM;
+
+	if (!zalloc_cpumask_var(&pr->throttling.shared_cpu_map, GFP_KERNEL)) {
+		kfree(pr);
+		return -ENOMEM;
+	}
+
+	pr->handle =3D device->handle;
+	strcpy(acpi_device_name(device), ACPI_PROCESSOR_DEVICE_NAME);
+	strcpy(acpi_device_class(device), ACPI_PROCESSOR_CLASS);
+	device->driver_data =3D pr;
+
+	result =3D xen_acpi_processor_get_info(device);
+	if (result) {
+		/* Processor is physically not present */
+		return 0;
+	}
+
+#ifdef CONFIG_SMP
+	if (pr->id >=3D setup_max_cpus && pr->id !=3D 0)
+		return 0;
+#endif
+
+	BUG_ON((pr->id >=3D nr_cpu_ids) || (pr->id < 0));
+
+	/*
+	 * Buggy BIOS check
+	 * ACPI id of processors can be reported wrongly by the BIOS.
+	 * Don't trust it blindly
+	 */
+	if (per_cpu(processor_device_array, pr->id) !=3D NULL &&
+	    per_cpu(processor_device_array, pr->id) !=3D device) {
+		printk(KERN_WARNING "BIOS reported wrong ACPI id "
+			"for the processor\n");
+		result =3D -ENODEV;
+		goto err_free_cpumask;
+	}
+	per_cpu(processor_device_array, pr->id) =3D device;
+
+	per_cpu(processors, pr->id) =3D pr;
+
+	sysdev =3D get_cpu_sysdev(pr->id);
+	if (sysfs_create_link(&device->dev.kobj, &sysdev->kobj, "sysdev")) {
+		result =3D -EFAULT;
+		goto err_free_cpumask;
+	}
+
+#ifdef CONFIG_CPU_FREQ
+	acpi_processor_ppc_has_changed(pr, 0);
+#endif
+	acpi_processor_get_throttling_info(pr);
+	acpi_processor_get_limit_info(pr);
+
+
+	if (cpuidle_get_driver() =3D=3D &acpi_idle_driver)
+		acpi_processor_power_init(pr, device);
+
+	pr->cdev =3D thermal_cooling_device_register("Processor", device,
+						&processor_cooling_ops);
+	if (IS_ERR(pr->cdev)) {
+		result =3D PTR_ERR(pr->cdev);
+		goto err_power_exit;
+	}
+
+	dev_dbg(&device->dev, "registered as cooling_device%d\n",
+		 pr->cdev->id);
+
+	result =3D sysfs_create_link(&device->dev.kobj,
+				   &pr->cdev->device.kobj,
+				   "thermal_cooling");
+	if (result) {
+		printk(KERN_ERR PREFIX "Create sysfs link\n");
+		goto err_thermal_unregister;
+	}
+	result =3D sysfs_create_link(&pr->cdev->device.kobj,
+				   &device->dev.kobj,
+				   "device");
+	if (result) {
+		printk(KERN_ERR PREFIX "Create sysfs link\n");
+		goto err_remove_sysfs;
+	}
+
+	return 0;
+
+err_remove_sysfs:
+	sysfs_remove_link(&device->dev.kobj, "thermal_cooling");
+err_thermal_unregister:
+	thermal_cooling_device_unregister(pr->cdev);
+err_power_exit:
+	acpi_processor_power_exit(pr, device);
+err_free_cpumask:
+	free_cpumask_var(pr->throttling.shared_cpu_map);
+
+	return result;
+}
+
 static int __cpuinit xen_acpi_processor_add(struct acpi_device *device)
 {
 	struct acpi_processor *pr =3D NULL;
 	int result =3D 0;
=20
-	result =3D acpi_processor_add(device);
-	if (result < 0)
+	result =3D __xen_acpi_processor_add(device);
+	if (result)
 		return result;
=20
 	pr =3D acpi_driver_data(device);
diff --git a/include/acpi/processor.h b/include/acpi/processor.h
index c48e2f9..3a1ee01 100644
--- a/include/acpi/processor.h
+++ b/include/acpi/processor.h
@@ -225,6 +225,8 @@ struct acpi_processor_errata {
 	} piix4;
 };
=20
+extern int acpi_processor_errata(struct acpi_processor *pr);
+
 extern int acpi_processor_preregister_performance(struct
 						  acpi_processor_performance
 						  __percpu *performance);
diff --git a/include/xen/pcpu.h b/include/xen/pcpu.h
index 7e8f9d1..3e99db9 100644
--- a/include/xen/pcpu.h
+++ b/include/xen/pcpu.h
@@ -4,6 +4,8 @@
 #include <xen/interface/platform.h>
 #include <linux/sysdev.h>
=20
+extern DEFINE_PER_CPU(void *, processor_device_array);
+
 extern int xen_pcpu_hotplug(int type, uint32_t apic_id);
 #define XEN_PCPU_ONLINE     0x01
 #define XEN_PCPU_OFFLINE    0x02
--=20
1.6.5.6

--_002_DE8DF0795D48FD4CA783C40EC82923359720SHSMSX101ccrcorpint_
Content-Type: application/octet-stream;
	name="0008-xen-acpi-add-cpu-hotadd-support.patch"
Content-Description: 0008-xen-acpi-add-cpu-hotadd-support.patch
Content-Disposition: attachment;
	filename="0008-xen-acpi-add-cpu-hotadd-support.patch"; size=10056;
	creation-date="Wed, 14 Dec 2011 15:20:15 GMT";
	modification-date="Wed, 14 Dec 2011 15:03:34 GMT"
Content-Transfer-Encoding: base64

RnJvbSAyODI5NThiZTNhMzNiMmYyYjg4OGUxZWQzYWMwMjJiZjhhMTk5ZWM5IE1vbiBTZXAgMTcg
MDA6MDA6MDAgMjAwMQpGcm9tOiBMaXUgSmluc29uZyA8amluc29uZy5saXVAaW50ZWwuY29tPgpE
YXRlOiBXZWQsIDE0IERlYyAyMDExIDExOjM4OjExICswODAwClN1YmplY3Q6IFtQQVRDSCAwOC8x
MF0geGVuL2FjcGk6IGFkZCBjcHUgaG90YWRkIHN1cHBvcnQKClRoaXMgcGF0Y2ggYWRkIGNwdSBo
b3RhZGQgc3VwcG9ydC4KSXQga2VlcCBzaW1pbGFyIGNwdSBob3RhZGQgbG9naWMgYXMgbmF0aXZl
LCB3LyBzb21lIGNoYW5nZXMgYWNjb3JkaW5nCnRvIHhlbiByZXF1aXJlbWVudCwgaHlwZXJjYWxs
aW5nIGh5cGVydmlzb3IgcmVsYXRlZCBsb2dpYyB0byBob3RhZGQgY3B1LgoKU2lnbmVkLW9mZi1i
eTogTGl1LCBKaW5zb25nIDxqaW5zb25nLmxpdUBpbnRlbC5jb20+ClNpZ25lZC1vZmYtYnk6IEpp
YW5nLCBZdW5ob25nIDx5dW5ob25nLmppYW5nQGludGVsLmNvbT4KLS0tCiBkcml2ZXJzL2FjcGkv
cHJvY2Vzc29yX2RyaXZlci5jIHwgICAgNCArLQogZHJpdmVycy9hY3BpL3Byb2Nlc3Nvcl94ZW4u
YyAgICB8ICAyNDIgKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKystCiBpbmNs
dWRlL2FjcGkvcHJvY2Vzc29yLmggICAgICAgIHwgICAgMiArCiBpbmNsdWRlL3hlbi9wY3B1Lmgg
ICAgICAgICAgICAgIHwgICAgMiArCiA0IGZpbGVzIGNoYW5nZWQsIDI0NiBpbnNlcnRpb25zKCsp
LCA0IGRlbGV0aW9ucygtKQoKZGlmZiAtLWdpdCBhL2RyaXZlcnMvYWNwaS9wcm9jZXNzb3JfZHJp
dmVyLmMgYi9kcml2ZXJzL2FjcGkvcHJvY2Vzc29yX2RyaXZlci5jCmluZGV4IDhhMzY3ZDcuLmQ0
NzNmZDUgMTAwNjQ0Ci0tLSBhL2RyaXZlcnMvYWNwaS9wcm9jZXNzb3JfZHJpdmVyLmMKKysrIGIv
ZHJpdmVycy9hY3BpL3Byb2Nlc3Nvcl9kcml2ZXIuYwpAQCAtMjIxLDcgKzIyMSw3IEBAIHN0YXRp
YyBpbnQgYWNwaV9wcm9jZXNzb3JfZXJyYXRhX3BpaXg0KHN0cnVjdCBwY2lfZGV2ICpkZXYpCiAJ
cmV0dXJuIDA7CiB9CiAKLXN0YXRpYyBpbnQgYWNwaV9wcm9jZXNzb3JfZXJyYXRhKHN0cnVjdCBh
Y3BpX3Byb2Nlc3NvciAqcHIpCitpbnQgYWNwaV9wcm9jZXNzb3JfZXJyYXRhKHN0cnVjdCBhY3Bp
X3Byb2Nlc3NvciAqcHIpCiB7CiAJaW50IHJlc3VsdCA9IDA7CiAJc3RydWN0IHBjaV9kZXYgKmRl
diA9IE5VTEw7CkBAIC0zNzgsNyArMzc4LDcgQEAgc3RhdGljIGludCBhY3BpX3Byb2Nlc3Nvcl9n
ZXRfaW5mbyhzdHJ1Y3QgYWNwaV9kZXZpY2UgKmRldmljZSkKIAlyZXR1cm4gMDsKIH0KIAotc3Rh
dGljIERFRklORV9QRVJfQ1BVKHZvaWQgKiwgcHJvY2Vzc29yX2RldmljZV9hcnJheSk7CitERUZJ
TkVfUEVSX0NQVSh2b2lkICosIHByb2Nlc3Nvcl9kZXZpY2VfYXJyYXkpOwogCiB2b2lkIGFjcGlf
cHJvY2Vzc29yX25vdGlmeShzdHJ1Y3QgYWNwaV9kZXZpY2UgKmRldmljZSwgdTMyIGV2ZW50KQog
ewpkaWZmIC0tZ2l0IGEvZHJpdmVycy9hY3BpL3Byb2Nlc3Nvcl94ZW4uYyBiL2RyaXZlcnMvYWNw
aS9wcm9jZXNzb3JfeGVuLmMKaW5kZXggMzhhMWMwNS4uM2FmMWY3MyAxMDA2NDQKLS0tIGEvZHJp
dmVycy9hY3BpL3Byb2Nlc3Nvcl94ZW4uYworKysgYi9kcml2ZXJzL2FjcGkvcHJvY2Vzc29yX3hl
bi5jCkBAIC0yNCw2ICsyNCw3IEBACiAjZGVmaW5lIFBSRUZJWCAiQUNQSTogIgogCiAjZGVmaW5l
IEFDUElfUFJPQ0VTU09SX0NMQVNTICAgICAgICAgICAgInByb2Nlc3NvciIKKyNkZWZpbmUgQUNQ
SV9QUk9DRVNTT1JfREVWSUNFX05BTUUgICAgICAiUHJvY2Vzc29yIgogI2RlZmluZSBBQ1BJX1BS
T0NFU1NPUl9OT1RJRllfUEVSRk9STUFOQ0UgMHg4MAogI2RlZmluZSBBQ1BJX1BST0NFU1NPUl9O
T1RJRllfUE9XRVIJMHg4MQogI2RlZmluZSBBQ1BJX1BST0NFU1NPUl9OT1RJRllfVEhST1RUTElO
RwkweDgyCkBAIC04OCw2ICs4OSw4IEBAIHhlbl9hY3BpX3Byb2Nlc3Nvcl9ob3RhZGRfaW5pdChz
dHJ1Y3QgYWNwaV9wcm9jZXNzb3IgKnByLCBpbnQgKnBfY3B1KQogCQkJCVBST0NFU1NPUl9IT1RQ
TFVHLCBIT1RQTFVHX1RZUEVfQUREKSkKIAkJcmV0dXJuIEFFX0VSUk9SOwogCisJKnBfY3B1ID0g
eGVuX3BjcHVfaW5kZXgocHItPmFjcGlfaWQsIDEpOworCiAJcmV0dXJuIEFFX09LOwogfQogCkBA
IC0xNDksMTMgKzE1MiwyNDggQEAgZXJyX291dDoKIH0KICNlbmRpZiAvKiBDT05GSUdfQ1BVX0ZS
RVEgKi8KIAorc3RhdGljIGludCB4ZW5fYWNwaV9wcm9jZXNzb3JfZ2V0X2luZm8oc3RydWN0IGFj
cGlfZGV2aWNlICpkZXZpY2UpCit7CisJYWNwaV9zdGF0dXMgc3RhdHVzID0gMDsKKwl1bmlvbiBh
Y3BpX29iamVjdCBvYmplY3QgPSB7IDAgfTsKKwlzdHJ1Y3QgYWNwaV9idWZmZXIgYnVmZmVyID0g
eyBzaXplb2YodW5pb24gYWNwaV9vYmplY3QpLCAmb2JqZWN0IH07CisJc3RydWN0IGFjcGlfcHJv
Y2Vzc29yICpwcjsKKwlpbnQgY3B1X2luZGV4LCBkZXZpY2VfZGVjbGFyYXRpb24gPSAwOworCXN0
YXRpYyBpbnQgY3B1MF9pbml0aWFsaXplZDsKKworCXByID0gYWNwaV9kcml2ZXJfZGF0YShkZXZp
Y2UpOworCWlmICghcHIpCisJCXJldHVybiAtRUlOVkFMOworCisJaWYgKG51bV9vbmxpbmVfY3B1
cygpID4gMSkKKwkJZXJyYXRhLnNtcCA9IFRSVUU7CisKKwlhY3BpX3Byb2Nlc3Nvcl9lcnJhdGEo
cHIpOworCisJLyoKKwkgKiBDaGVjayB0byBzZWUgaWYgd2UgaGF2ZSBidXMgbWFzdGVyaW5nIGFy
Yml0cmF0aW9uIGNvbnRyb2wuICBUaGlzCisJICogaXMgcmVxdWlyZWQgZm9yIHByb3BlciBDMyB1
c2FnZSAodG8gbWFpbnRhaW4gY2FjaGUgY29oZXJlbmN5KS4KKwkgKi8KKwlpZiAoYWNwaV9nYmxf
RkFEVC5wbTJfY29udHJvbF9ibG9jayAmJiBhY3BpX2dibF9GQURULnBtMl9jb250cm9sX2xlbmd0
aCkgeworCQlwci0+ZmxhZ3MuYm1fY29udHJvbCA9IDE7CisJCUFDUElfREVCVUdfUFJJTlQoKEFD
UElfREJfSU5GTywKKwkJCQkgICJCdXMgbWFzdGVyaW5nIGFyYml0cmF0aW9uIGNvbnRyb2wgcHJl
c2VudFxuIikpOworCX0gZWxzZQorCQlBQ1BJX0RFQlVHX1BSSU5UKChBQ1BJX0RCX0lORk8sCisJ
CQkJICAiTm8gYnVzIG1hc3RlcmluZyBhcmJpdHJhdGlvbiBjb250cm9sXG4iKSk7CisKKwlpZiAo
IXN0cmNtcChhY3BpX2RldmljZV9oaWQoZGV2aWNlKSwgQUNQSV9QUk9DRVNTT1JfT0JKRUNUX0hJ
RCkpIHsKKwkJLyogRGVjbGFyZWQgd2l0aCAiUHJvY2Vzc29yIiBzdGF0ZW1lbnQ7IG1hdGNoIFBy
b2Nlc3NvcklEICovCisJCXN0YXR1cyA9IGFjcGlfZXZhbHVhdGVfb2JqZWN0KHByLT5oYW5kbGUs
IE5VTEwsIE5VTEwsICZidWZmZXIpOworCQlpZiAoQUNQSV9GQUlMVVJFKHN0YXR1cykpIHsKKwkJ
CXByaW50ayhLRVJOX0VSUiBQUkVGSVggIkV2YWx1YXRpbmcgcHJvY2Vzc29yIG9iamVjdFxuIik7
CisJCQlyZXR1cm4gLUVOT0RFVjsKKwkJfQorCisJCS8qCisJCSAqIFRCRDogU3luY2ggcHJvY2Vz
c29yIElEICh2aWEgTEFQSUMvTFNBUElDIHN0cnVjdHVyZXMpIG9uIFNNUC4KKwkJICogICAgICA+
Pj4gJ2FjcGlfZ2V0X3Byb2Nlc3Nvcl9pZChhY3BpX2lkLCAmaWQpJyBpbgorCQkgKiAgICAgIGFy
Y2gveHh4L2FjcGkuYworCQkgKi8KKwkJcHItPmFjcGlfaWQgPSBvYmplY3QucHJvY2Vzc29yLnBy
b2NfaWQ7CisJfSBlbHNlIHsKKwkJLyoKKwkJICogRGVjbGFyZWQgd2l0aCAiRGV2aWNlIiBzdGF0
ZW1lbnQ7IG1hdGNoIF9VSUQuCisJCSAqIE5vdGUgdGhhdCB3ZSBkb24ndCBoYW5kbGUgc3RyaW5n
IF9VSURzIHlldC4KKwkJICovCisJCXVuc2lnbmVkIGxvbmcgbG9uZyB2YWx1ZTsKKwkJc3RhdHVz
ID0gYWNwaV9ldmFsdWF0ZV9pbnRlZ2VyKHByLT5oYW5kbGUsIE1FVEhPRF9OQU1FX19VSUQsCisJ
CQkJCQlOVUxMLCAmdmFsdWUpOworCQlpZiAoQUNQSV9GQUlMVVJFKHN0YXR1cykpIHsKKwkJCXBy
aW50ayhLRVJOX0VSUiBQUkVGSVgKKwkJCSAgICAiRXZhbHVhdGluZyBwcm9jZXNzb3IgX1VJRCBb
JSN4XVxuIiwgc3RhdHVzKTsKKwkJCXJldHVybiAtRU5PREVWOworCQl9CisJCWRldmljZV9kZWNs
YXJhdGlvbiA9IDE7CisJCXByLT5hY3BpX2lkID0gdmFsdWU7CisJfQorCisJY3B1X2luZGV4ID0g
eGVuX3BjcHVfaW5kZXgocHItPmFjcGlfaWQsIDEpOworCisJLyogSGFuZGxlIFVQIHN5c3RlbSBy
dW5uaW5nIFNNUCBrZXJuZWwsIHdpdGggbm8gTEFQSUMgaW4gTUFEVCAqLworCWlmICghY3B1MF9p
bml0aWFsaXplZCAmJiAoY3B1X2luZGV4ID09IC0xKSAmJgorCSAgICAobnVtX29ubGluZV9jcHVz
KCkgPT0gMSkpIHsKKwkJY3B1X2luZGV4ID0gMDsKKwl9CisKKwljcHUwX2luaXRpYWxpemVkID0g
MTsKKworCXByLT5pZCA9IGNwdV9pbmRleDsKKworCS8qCisJICogIEV4dHJhIFByb2Nlc3NvciBv
YmplY3RzIG1heSBiZSBlbnVtZXJhdGVkIG9uIE1QIHN5c3RlbXMgd2l0aAorCSAqICBsZXNzIHRo
YW4gdGhlIG1heCAjIG9mIENQVXMuIFRoZXkgc2hvdWxkIGJlIGlnbm9yZWQgX2lmZgorCSAqICB0
aGV5IGFyZSBwaHlzaWNhbGx5IG5vdCBwcmVzZW50LgorCSAqLworCWlmIChwci0+aWQgPT0gLTEp
IHsKKwkJaWYgKEFDUElfRkFJTFVSRQorCQkgICAgKHhlbl9hY3BpX3Byb2Nlc3Nvcl9ob3RhZGRf
aW5pdChwciwgJnByLT5pZCkpKSB7CisJCQlyZXR1cm4gLUVOT0RFVjsKKwkJfQorCX0KKwkvKgor
CSAqIE9uIHNvbWUgYm94ZXMgc2V2ZXJhbCBwcm9jZXNzb3JzIHVzZSB0aGUgc2FtZSBwcm9jZXNz
b3IgYnVzIGlkLgorCSAqIEJ1dCB0aGV5IGFyZSBsb2NhdGVkIGluIGRpZmZlcmVudCBzY29wZS4g
Rm9yIGV4YW1wbGU6CisJICogXF9TQi5TQ0swLkNQVTAKKwkgKiBcX1NCLlNDSzEuQ1BVMAorCSAq
IFJlbmFtZSB0aGUgcHJvY2Vzc29yIGRldmljZSBidXMgaWQuIEFuZCB0aGUgbmV3IGJ1cyBpZCB3
aWxsIGJlCisJICogZ2VuZXJhdGVkIGFzIHRoZSBmb2xsb3dpbmcgZm9ybWF0OgorCSAqIENQVStD
UFUgSUQuCisJICovCisJc3ByaW50ZihhY3BpX2RldmljZV9iaWQoZGV2aWNlKSwgIkNQVSVYIiwg
cHItPmlkKTsKKwlBQ1BJX0RFQlVHX1BSSU5UKChBQ1BJX0RCX0lORk8sICJQcm9jZXNzb3IgWyVk
OiVkXVxuIiwgcHItPmlkLAorCQkJICBwci0+YWNwaV9pZCkpOworCisJaWYgKCFvYmplY3QucHJv
Y2Vzc29yLnBibGtfYWRkcmVzcykKKwkJQUNQSV9ERUJVR19QUklOVCgoQUNQSV9EQl9JTkZPLCAi
Tm8gUEJMSyAoTlVMTCBhZGRyZXNzKVxuIikpOworCWVsc2UgaWYgKG9iamVjdC5wcm9jZXNzb3Iu
cGJsa19sZW5ndGggIT0gNikKKwkJcHJpbnRrKEtFUk5fRVJSIFBSRUZJWCAiSW52YWxpZCBQQkxL
IGxlbmd0aCBbJWRdXG4iLAorCQkJICAgIG9iamVjdC5wcm9jZXNzb3IucGJsa19sZW5ndGgpOwor
CWVsc2UgeworCQlwci0+dGhyb3R0bGluZy5hZGRyZXNzID0gb2JqZWN0LnByb2Nlc3Nvci5wYmxr
X2FkZHJlc3M7CisJCXByLT50aHJvdHRsaW5nLmR1dHlfb2Zmc2V0ID0gYWNwaV9nYmxfRkFEVC5k
dXR5X29mZnNldDsKKwkJcHItPnRocm90dGxpbmcuZHV0eV93aWR0aCA9IGFjcGlfZ2JsX0ZBRFQu
ZHV0eV93aWR0aDsKKworCQlwci0+cGJsayA9IG9iamVjdC5wcm9jZXNzb3IucGJsa19hZGRyZXNz
OworCisJCS8qCisJCSAqIFdlIGRvbid0IGNhcmUgYWJvdXQgZXJyb3IgcmV0dXJucyAtIHdlIGp1
c3QgdHJ5IHRvIG1hcmsKKwkJICogdGhlc2UgcmVzZXJ2ZWQgc28gdGhhdCBub2JvZHkgZWxzZSBp
cyBjb25mdXNlZCBpbnRvIHRoaW5raW5nCisJCSAqIHRoYXQgdGhpcyByZWdpb24gbWlnaHQgYmUg
dW51c2VkLi4KKwkJICoKKwkJICogKEluIHBhcnRpY3VsYXIsIGFsbG9jYXRpbmcgdGhlIElPIHJh
bmdlIGZvciBDYXJkYnVzKQorCQkgKi8KKwkJcmVxdWVzdF9yZWdpb24ocHItPnRocm90dGxpbmcu
YWRkcmVzcywgNiwgIkFDUEkgQ1BVIHRocm90dGxlIik7CisJfQorCisJLyoKKwkgKiBJZiBBQ1BJ
IGRlc2NyaWJlcyBhIHNsb3QgbnVtYmVyIGZvciB0aGlzIENQVSwgd2UgY2FuIHVzZSBpdAorCSAq
IGVuc3VyZSB3ZSBnZXQgdGhlIHJpZ2h0IHZhbHVlIGluIHRoZSAicGh5c2ljYWwgaWQiIGZpZWxk
CisJICogb2YgL3Byb2MvY3B1aW5mbworCSAqLworCXN0YXR1cyA9IGFjcGlfZXZhbHVhdGVfb2Jq
ZWN0KHByLT5oYW5kbGUsICJfU1VOIiwgTlVMTCwgJmJ1ZmZlcik7CisJaWYgKEFDUElfU1VDQ0VT
UyhzdGF0dXMpKQorCQlhcmNoX2ZpeF9waHlzX3BhY2thZ2VfaWQocHItPmlkLCBvYmplY3QuaW50
ZWdlci52YWx1ZSk7CisKKwlyZXR1cm4gMDsKK30KKworc3RhdGljIGludCBfX2NwdWluaXQgX194
ZW5fYWNwaV9wcm9jZXNzb3JfYWRkKHN0cnVjdCBhY3BpX2RldmljZSAqZGV2aWNlKQoreworCXN0
cnVjdCBhY3BpX3Byb2Nlc3NvciAqcHIgPSBOVUxMOworCWludCByZXN1bHQgPSAwOworCXN0cnVj
dCBzeXNfZGV2aWNlICpzeXNkZXY7CisKKwlwciA9IGt6YWxsb2Moc2l6ZW9mKHN0cnVjdCBhY3Bp
X3Byb2Nlc3NvciksIEdGUF9LRVJORUwpOworCWlmICghcHIpCisJCXJldHVybiAtRU5PTUVNOwor
CisJaWYgKCF6YWxsb2NfY3B1bWFza192YXIoJnByLT50aHJvdHRsaW5nLnNoYXJlZF9jcHVfbWFw
LCBHRlBfS0VSTkVMKSkgeworCQlrZnJlZShwcik7CisJCXJldHVybiAtRU5PTUVNOworCX0KKwor
CXByLT5oYW5kbGUgPSBkZXZpY2UtPmhhbmRsZTsKKwlzdHJjcHkoYWNwaV9kZXZpY2VfbmFtZShk
ZXZpY2UpLCBBQ1BJX1BST0NFU1NPUl9ERVZJQ0VfTkFNRSk7CisJc3RyY3B5KGFjcGlfZGV2aWNl
X2NsYXNzKGRldmljZSksIEFDUElfUFJPQ0VTU09SX0NMQVNTKTsKKwlkZXZpY2UtPmRyaXZlcl9k
YXRhID0gcHI7CisKKwlyZXN1bHQgPSB4ZW5fYWNwaV9wcm9jZXNzb3JfZ2V0X2luZm8oZGV2aWNl
KTsKKwlpZiAocmVzdWx0KSB7CisJCS8qIFByb2Nlc3NvciBpcyBwaHlzaWNhbGx5IG5vdCBwcmVz
ZW50ICovCisJCXJldHVybiAwOworCX0KKworI2lmZGVmIENPTkZJR19TTVAKKwlpZiAocHItPmlk
ID49IHNldHVwX21heF9jcHVzICYmIHByLT5pZCAhPSAwKQorCQlyZXR1cm4gMDsKKyNlbmRpZgor
CisJQlVHX09OKChwci0+aWQgPj0gbnJfY3B1X2lkcykgfHwgKHByLT5pZCA8IDApKTsKKworCS8q
CisJICogQnVnZ3kgQklPUyBjaGVjaworCSAqIEFDUEkgaWQgb2YgcHJvY2Vzc29ycyBjYW4gYmUg
cmVwb3J0ZWQgd3JvbmdseSBieSB0aGUgQklPUy4KKwkgKiBEb24ndCB0cnVzdCBpdCBibGluZGx5
CisJICovCisJaWYgKHBlcl9jcHUocHJvY2Vzc29yX2RldmljZV9hcnJheSwgcHItPmlkKSAhPSBO
VUxMICYmCisJICAgIHBlcl9jcHUocHJvY2Vzc29yX2RldmljZV9hcnJheSwgcHItPmlkKSAhPSBk
ZXZpY2UpIHsKKwkJcHJpbnRrKEtFUk5fV0FSTklORyAiQklPUyByZXBvcnRlZCB3cm9uZyBBQ1BJ
IGlkICIKKwkJCSJmb3IgdGhlIHByb2Nlc3NvclxuIik7CisJCXJlc3VsdCA9IC1FTk9ERVY7CisJ
CWdvdG8gZXJyX2ZyZWVfY3B1bWFzazsKKwl9CisJcGVyX2NwdShwcm9jZXNzb3JfZGV2aWNlX2Fy
cmF5LCBwci0+aWQpID0gZGV2aWNlOworCisJcGVyX2NwdShwcm9jZXNzb3JzLCBwci0+aWQpID0g
cHI7CisKKwlzeXNkZXYgPSBnZXRfY3B1X3N5c2Rldihwci0+aWQpOworCWlmIChzeXNmc19jcmVh
dGVfbGluaygmZGV2aWNlLT5kZXYua29iaiwgJnN5c2Rldi0+a29iaiwgInN5c2RldiIpKSB7CisJ
CXJlc3VsdCA9IC1FRkFVTFQ7CisJCWdvdG8gZXJyX2ZyZWVfY3B1bWFzazsKKwl9CisKKyNpZmRl
ZiBDT05GSUdfQ1BVX0ZSRVEKKwlhY3BpX3Byb2Nlc3Nvcl9wcGNfaGFzX2NoYW5nZWQocHIsIDAp
OworI2VuZGlmCisJYWNwaV9wcm9jZXNzb3JfZ2V0X3Rocm90dGxpbmdfaW5mbyhwcik7CisJYWNw
aV9wcm9jZXNzb3JfZ2V0X2xpbWl0X2luZm8ocHIpOworCisKKwlpZiAoY3B1aWRsZV9nZXRfZHJp
dmVyKCkgPT0gJmFjcGlfaWRsZV9kcml2ZXIpCisJCWFjcGlfcHJvY2Vzc29yX3Bvd2VyX2luaXQo
cHIsIGRldmljZSk7CisKKwlwci0+Y2RldiA9IHRoZXJtYWxfY29vbGluZ19kZXZpY2VfcmVnaXN0
ZXIoIlByb2Nlc3NvciIsIGRldmljZSwKKwkJCQkJCSZwcm9jZXNzb3JfY29vbGluZ19vcHMpOwor
CWlmIChJU19FUlIocHItPmNkZXYpKSB7CisJCXJlc3VsdCA9IFBUUl9FUlIocHItPmNkZXYpOwor
CQlnb3RvIGVycl9wb3dlcl9leGl0OworCX0KKworCWRldl9kYmcoJmRldmljZS0+ZGV2LCAicmVn
aXN0ZXJlZCBhcyBjb29saW5nX2RldmljZSVkXG4iLAorCQkgcHItPmNkZXYtPmlkKTsKKworCXJl
c3VsdCA9IHN5c2ZzX2NyZWF0ZV9saW5rKCZkZXZpY2UtPmRldi5rb2JqLAorCQkJCSAgICZwci0+
Y2Rldi0+ZGV2aWNlLmtvYmosCisJCQkJICAgInRoZXJtYWxfY29vbGluZyIpOworCWlmIChyZXN1
bHQpIHsKKwkJcHJpbnRrKEtFUk5fRVJSIFBSRUZJWCAiQ3JlYXRlIHN5c2ZzIGxpbmtcbiIpOwor
CQlnb3RvIGVycl90aGVybWFsX3VucmVnaXN0ZXI7CisJfQorCXJlc3VsdCA9IHN5c2ZzX2NyZWF0
ZV9saW5rKCZwci0+Y2Rldi0+ZGV2aWNlLmtvYmosCisJCQkJICAgJmRldmljZS0+ZGV2LmtvYmos
CisJCQkJICAgImRldmljZSIpOworCWlmIChyZXN1bHQpIHsKKwkJcHJpbnRrKEtFUk5fRVJSIFBS
RUZJWCAiQ3JlYXRlIHN5c2ZzIGxpbmtcbiIpOworCQlnb3RvIGVycl9yZW1vdmVfc3lzZnM7CisJ
fQorCisJcmV0dXJuIDA7CisKK2Vycl9yZW1vdmVfc3lzZnM6CisJc3lzZnNfcmVtb3ZlX2xpbmso
JmRldmljZS0+ZGV2LmtvYmosICJ0aGVybWFsX2Nvb2xpbmciKTsKK2Vycl90aGVybWFsX3VucmVn
aXN0ZXI6CisJdGhlcm1hbF9jb29saW5nX2RldmljZV91bnJlZ2lzdGVyKHByLT5jZGV2KTsKK2Vy
cl9wb3dlcl9leGl0OgorCWFjcGlfcHJvY2Vzc29yX3Bvd2VyX2V4aXQocHIsIGRldmljZSk7Citl
cnJfZnJlZV9jcHVtYXNrOgorCWZyZWVfY3B1bWFza192YXIocHItPnRocm90dGxpbmcuc2hhcmVk
X2NwdV9tYXApOworCisJcmV0dXJuIHJlc3VsdDsKK30KKwogc3RhdGljIGludCBfX2NwdWluaXQg
eGVuX2FjcGlfcHJvY2Vzc29yX2FkZChzdHJ1Y3QgYWNwaV9kZXZpY2UgKmRldmljZSkKIHsKIAlz
dHJ1Y3QgYWNwaV9wcm9jZXNzb3IgKnByID0gTlVMTDsKIAlpbnQgcmVzdWx0ID0gMDsKIAotCXJl
c3VsdCA9IGFjcGlfcHJvY2Vzc29yX2FkZChkZXZpY2UpOwotCWlmIChyZXN1bHQgPCAwKQorCXJl
c3VsdCA9IF9feGVuX2FjcGlfcHJvY2Vzc29yX2FkZChkZXZpY2UpOworCWlmIChyZXN1bHQpCiAJ
CXJldHVybiByZXN1bHQ7CiAKIAlwciA9IGFjcGlfZHJpdmVyX2RhdGEoZGV2aWNlKTsKZGlmZiAt
LWdpdCBhL2luY2x1ZGUvYWNwaS9wcm9jZXNzb3IuaCBiL2luY2x1ZGUvYWNwaS9wcm9jZXNzb3Iu
aAppbmRleCBjNDhlMmY5Li4zYTFlZTAxIDEwMDY0NAotLS0gYS9pbmNsdWRlL2FjcGkvcHJvY2Vz
c29yLmgKKysrIGIvaW5jbHVkZS9hY3BpL3Byb2Nlc3Nvci5oCkBAIC0yMjUsNiArMjI1LDggQEAg
c3RydWN0IGFjcGlfcHJvY2Vzc29yX2VycmF0YSB7CiAJfSBwaWl4NDsKIH07CiAKK2V4dGVybiBp
bnQgYWNwaV9wcm9jZXNzb3JfZXJyYXRhKHN0cnVjdCBhY3BpX3Byb2Nlc3NvciAqcHIpOworCiBl
eHRlcm4gaW50IGFjcGlfcHJvY2Vzc29yX3ByZXJlZ2lzdGVyX3BlcmZvcm1hbmNlKHN0cnVjdAog
CQkJCQkJICBhY3BpX3Byb2Nlc3Nvcl9wZXJmb3JtYW5jZQogCQkJCQkJICBfX3BlcmNwdSAqcGVy
Zm9ybWFuY2UpOwpkaWZmIC0tZ2l0IGEvaW5jbHVkZS94ZW4vcGNwdS5oIGIvaW5jbHVkZS94ZW4v
cGNwdS5oCmluZGV4IDdlOGY5ZDEuLjNlOTlkYjkgMTAwNjQ0Ci0tLSBhL2luY2x1ZGUveGVuL3Bj
cHUuaAorKysgYi9pbmNsdWRlL3hlbi9wY3B1LmgKQEAgLTQsNiArNCw4IEBACiAjaW5jbHVkZSA8
eGVuL2ludGVyZmFjZS9wbGF0Zm9ybS5oPgogI2luY2x1ZGUgPGxpbnV4L3N5c2Rldi5oPgogCitl
eHRlcm4gREVGSU5FX1BFUl9DUFUodm9pZCAqLCBwcm9jZXNzb3JfZGV2aWNlX2FycmF5KTsKKwog
ZXh0ZXJuIGludCB4ZW5fcGNwdV9ob3RwbHVnKGludCB0eXBlLCB1aW50MzJfdCBhcGljX2lkKTsK
ICNkZWZpbmUgWEVOX1BDUFVfT05MSU5FICAgICAweDAxCiAjZGVmaW5lIFhFTl9QQ1BVX09GRkxJ
TkUgICAgMHgwMgotLSAKMS42LjUuNgoK

--_002_DE8DF0795D48FD4CA783C40EC82923359720SHSMSX101ccrcorpint_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--_002_DE8DF0795D48FD4CA783C40EC82923359720SHSMSX101ccrcorpint_--


From xen-devel-bounces@lists.xensource.com Fri Dec 23 10:31:12 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 Dec 2011 10:31:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Re2Oz-0006zX-26; Fri, 23 Dec 2011 10:31:01 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1Re2Ox-0006yU-UL
	for xen-devel@lists.xensource.com; Fri, 23 Dec 2011 10:31:00 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1324636252!8352835!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDMwMjM5MQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27325 invoked from network); 23 Dec 2011 10:30:53 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-15.tower-182.messagelabs.com with SMTP;
	23 Dec 2011 10:30:53 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga101.fm.intel.com with ESMTP; 23 Dec 2011 02:30:51 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208,223";a="99639593"
Received: from pgsmsx602.gar.corp.intel.com ([10.221.43.81])
	by fmsmga001.fm.intel.com with ESMTP; 23 Dec 2011 02:30:50 -0800
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	pgsmsx602.gar.corp.intel.com (10.221.43.81) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Fri, 23 Dec 2011 18:30:50 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.38]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.223]) with mapi id
	14.01.0355.002; Fri, 23 Dec 2011 18:30:48 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: "konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
Thread-Topic: [PATCH 09/10] xen/acpi: Change Cx notify and add PPC handle
Thread-Index: AczBXe8v+3aspNmsQx2YiaRIU03xuw==
Date: Fri, 23 Dec 2011 10:30:48 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC82923359737@SHSMSX101.ccr.corp.intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
Content-Type: multipart/mixed;
	boundary="_002_DE8DF0795D48FD4CA783C40EC82923359737SHSMSX101ccrcorpint_"
MIME-Version: 1.0
Cc: "Brown, Len" <len.brown@intel.com>,
	"jeremy.fitzhardinge@citrix.com" <jeremy.fitzhardinge@citrix.com>,
	"Jiang, Yunhong" <yunhong.jiang@intel.com>, "Shan, 
	Haitao" <haitao.shan@intel.com>,
	Kernel development list <linux-kernel@vger.kernel.org>, "Zhao,
	Yakui" <yakui.zhao@intel.com>, "Luck, Tony" <tony.luck@intel.com>, "Kleen,
	Andi" <andi.kleen@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: [Xen-devel] [PATCH 09/10] xen/acpi: Change Cx notify and add PPC
	handle
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--_002_DE8DF0795D48FD4CA783C40EC82923359737SHSMSX101ccrcorpint_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

>From ca403566e922dde51e8809d7489337be4a55adfc Mon Sep 17 00:00:00 2001
From: Liu Jinsong <jinsong.liu@intel.com>
Date: Wed, 14 Dec 2011 15:59:02 +0800
Subject: [PATCH 09/10] xen/acpi: Change Cx notify and add PPC handle

This patch update Xen Cx notify.
Current Cx notify has 2 potential trigger points w/ some logically redundan=
t.
We remove the Cx notify point which is outside __xen_acpi_processor_add,
merging its logic to the Cx notify point inside __xen_acpi_processor_add.
This would more clean, as what native Cx did.

This patch also add Xen PPC handle when cpu hotadd.

Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
---
 drivers/acpi/processor_xen.c |  103 +++++++++++++++++++++++---------------=
----
 1 files changed, 57 insertions(+), 46 deletions(-)

diff --git a/drivers/acpi/processor_xen.c b/drivers/acpi/processor_xen.c
index 3af1f73..083e2b1 100644
--- a/drivers/acpi/processor_xen.c
+++ b/drivers/acpi/processor_xen.c
@@ -283,6 +283,59 @@ static int xen_acpi_processor_get_info(struct acpi_dev=
ice *device)
 	return 0;
 }
=20
+static int xen_acpi_processor_get_platform_limit(struct acpi_processor *pr=
)
+{
+        acpi_status status =3D 0;
+        unsigned long long ppc =3D 0;
+
+        if (!pr)
+                return -EINVAL;
+
+        /*
+         * _PPC indicates the maximum state currently supported by the pla=
tform
+         * (e.g. 0 =3D states 0..n; 1 =3D states 1..n; etc.
+         */
+        status =3D acpi_evaluate_integer(pr->handle, "_PPC", NULL, &ppc);
+
+        if (ACPI_FAILURE(status) && status !=3D AE_NOT_FOUND) {
+                ACPI_EXCEPTION((AE_INFO, status, "Evaluating _PPC"));
+                return -ENODEV;
+        }
+
+        pr->performance_platform_limit =3D (int)ppc;
+
+        return 0;
+}
+
+static int xen_acpi_processor_ppc_has_changed(struct acpi_processor *pr)
+{
+	int ret;
+
+	ret =3D xen_acpi_processor_get_platform_limit(pr);
+
+	if (ret < 0)
+		return ret;
+	else
+		return processor_cntl_xen_notify(pr,
+			PROCESSOR_PM_CHANGE, PM_TYPE_PERF);
+}
+
+static void __cpuinit xen_acpi_processor_power_init(struct acpi_processor =
*pr,
+			      struct acpi_device *device)
+{
+	if (likely(!pr->flags.power_setup_done)) {
+		/* reset idle boot option which we don't care */
+		boot_option_idle_override =3D IDLE_NO_OVERRIDE;
+		acpi_processor_power_init(pr, device);
+		/* set to IDLE_HALT for trapping into Xen */
+		boot_option_idle_override =3D IDLE_HALT;
+
+		if (pr->flags.power)
+			processor_cntl_xen_notify(pr,
+					PROCESSOR_PM_INIT, PM_TYPE_IDLE);
+	}
+}
+
 static int __cpuinit __xen_acpi_processor_add(struct acpi_device *device)
 {
 	struct acpi_processor *pr =3D NULL;
@@ -339,14 +392,12 @@ static int __cpuinit __xen_acpi_processor_add(struct =
acpi_device *device)
 	}
=20
 #ifdef CONFIG_CPU_FREQ
-	acpi_processor_ppc_has_changed(pr, 0);
+	xen_acpi_processor_ppc_has_changed(pr);
 #endif
 	acpi_processor_get_throttling_info(pr);
 	acpi_processor_get_limit_info(pr);
=20
-
-	if (cpuidle_get_driver() =3D=3D &acpi_idle_driver)
-		acpi_processor_power_init(pr, device);
+	xen_acpi_processor_power_init(pr, device);
=20
 	pr->cdev =3D thermal_cooling_device_register("Processor", device,
 						&processor_cooling_ops);
@@ -400,48 +451,8 @@ static int __cpuinit xen_acpi_processor_add(struct acp=
i_device *device)
 	if (!pr)
 		return -EINVAL;
=20
-	if (pr->id =3D=3D -1) {
-		int device_declaration;
-		int apic_id =3D -1;
-
-		if (!strcmp(acpi_device_hid(device), ACPI_PROCESSOR_OBJECT_HID))
-			device_declaration =3D 0;
-		else
-			device_declaration =3D 1;
-
-		apic_id =3D acpi_get_cpuid(pr->handle,
-			device_declaration, pr->acpi_id);
-		if (apic_id =3D=3D -1) {
-			/* Processor is not present in MADT table */
-			return 0;
-		}
-
-		/*
-		 * It's possible to have pr->id as '-1' even when it's actually
-		 * present in MADT table, e.g. due to limiting dom0 max vcpus
-		 * less than physical present number. In such case we still want
-		 * to parse ACPI processor object information, so mimic the
-		 * pr->id to CPU-0. This should be safe because we only care
-		 * about raw ACPI information, which only relies on pr->acpi_id.
-		 * For other information relying on pr->id and gathered through
-		 * SMP function call, it's safe to let them run on CPU-0 since
-		 * underlying Xen will collect them. Only a valid pr->id can
-		 * make later invocations forward progress.
-		 */
-		pr->id =3D 0;
-	}
-
-	if (likely(!pr->flags.power_setup_done)) {
-		/* reset idle boot option which we don't care */
-		boot_option_idle_override =3D IDLE_NO_OVERRIDE;
-		acpi_processor_power_init(pr, device);
-		/* set to IDLE_HALT for trapping into Xen */
-		boot_option_idle_override =3D IDLE_HALT;
-
-		if (pr->flags.power)
-			processor_cntl_xen_notify(pr,
-					PROCESSOR_PM_INIT, PM_TYPE_IDLE);
-	}
+	if (pr->id =3D=3D -1)
+		return 0;
=20
 #ifdef CONFIG_CPU_FREQ
 	if (likely(!pr->performance))
--=20
1.6.5.6

--_002_DE8DF0795D48FD4CA783C40EC82923359737SHSMSX101ccrcorpint_
Content-Type: application/octet-stream;
	name="0009-xen-acpi-Change-Cx-notify-and-add-PPC-handle.patch"
Content-Description: 0009-xen-acpi-Change-Cx-notify-and-add-PPC-handle.patch
Content-Disposition: attachment;
	filename="0009-xen-acpi-Change-Cx-notify-and-add-PPC-handle.patch";
	size=4832; creation-date="Wed, 14 Dec 2011 15:20:15 GMT";
	modification-date="Wed, 14 Dec 2011 15:03:34 GMT"
Content-Transfer-Encoding: base64

RnJvbSBjYTQwMzU2NmU5MjJkZGU1MWU4ODA5ZDc0ODkzMzdiZTRhNTVhZGZjIE1vbiBTZXAgMTcg
MDA6MDA6MDAgMjAwMQpGcm9tOiBMaXUgSmluc29uZyA8amluc29uZy5saXVAaW50ZWwuY29tPgpE
YXRlOiBXZWQsIDE0IERlYyAyMDExIDE1OjU5OjAyICswODAwClN1YmplY3Q6IFtQQVRDSCAwOS8x
MF0geGVuL2FjcGk6IENoYW5nZSBDeCBub3RpZnkgYW5kIGFkZCBQUEMgaGFuZGxlCgpUaGlzIHBh
dGNoIHVwZGF0ZSBYZW4gQ3ggbm90aWZ5LgpDdXJyZW50IEN4IG5vdGlmeSBoYXMgMiBwb3RlbnRp
YWwgdHJpZ2dlciBwb2ludHMgdy8gc29tZSBsb2dpY2FsbHkgcmVkdW5kYW50LgpXZSByZW1vdmUg
dGhlIEN4IG5vdGlmeSBwb2ludCB3aGljaCBpcyBvdXRzaWRlIF9feGVuX2FjcGlfcHJvY2Vzc29y
X2FkZCwKbWVyZ2luZyBpdHMgbG9naWMgdG8gdGhlIEN4IG5vdGlmeSBwb2ludCBpbnNpZGUgX194
ZW5fYWNwaV9wcm9jZXNzb3JfYWRkLgpUaGlzIHdvdWxkIG1vcmUgY2xlYW4sIGFzIHdoYXQgbmF0
aXZlIEN4IGRpZC4KClRoaXMgcGF0Y2ggYWxzbyBhZGQgWGVuIFBQQyBoYW5kbGUgd2hlbiBjcHUg
aG90YWRkLgoKU2lnbmVkLW9mZi1ieTogTGl1LCBKaW5zb25nIDxqaW5zb25nLmxpdUBpbnRlbC5j
b20+Ci0tLQogZHJpdmVycy9hY3BpL3Byb2Nlc3Nvcl94ZW4uYyB8ICAxMDMgKysrKysrKysrKysr
KysrKysrKysrKystLS0tLS0tLS0tLS0tLS0tLS0tCiAxIGZpbGVzIGNoYW5nZWQsIDU3IGluc2Vy
dGlvbnMoKyksIDQ2IGRlbGV0aW9ucygtKQoKZGlmZiAtLWdpdCBhL2RyaXZlcnMvYWNwaS9wcm9j
ZXNzb3JfeGVuLmMgYi9kcml2ZXJzL2FjcGkvcHJvY2Vzc29yX3hlbi5jCmluZGV4IDNhZjFmNzMu
LjA4M2UyYjEgMTAwNjQ0Ci0tLSBhL2RyaXZlcnMvYWNwaS9wcm9jZXNzb3JfeGVuLmMKKysrIGIv
ZHJpdmVycy9hY3BpL3Byb2Nlc3Nvcl94ZW4uYwpAQCAtMjgzLDYgKzI4Myw1OSBAQCBzdGF0aWMg
aW50IHhlbl9hY3BpX3Byb2Nlc3Nvcl9nZXRfaW5mbyhzdHJ1Y3QgYWNwaV9kZXZpY2UgKmRldmlj
ZSkKIAlyZXR1cm4gMDsKIH0KIAorc3RhdGljIGludCB4ZW5fYWNwaV9wcm9jZXNzb3JfZ2V0X3Bs
YXRmb3JtX2xpbWl0KHN0cnVjdCBhY3BpX3Byb2Nlc3NvciAqcHIpCit7CisgICAgICAgIGFjcGlf
c3RhdHVzIHN0YXR1cyA9IDA7CisgICAgICAgIHVuc2lnbmVkIGxvbmcgbG9uZyBwcGMgPSAwOwor
CisgICAgICAgIGlmICghcHIpCisgICAgICAgICAgICAgICAgcmV0dXJuIC1FSU5WQUw7CisKKyAg
ICAgICAgLyoKKyAgICAgICAgICogX1BQQyBpbmRpY2F0ZXMgdGhlIG1heGltdW0gc3RhdGUgY3Vy
cmVudGx5IHN1cHBvcnRlZCBieSB0aGUgcGxhdGZvcm0KKyAgICAgICAgICogKGUuZy4gMCA9IHN0
YXRlcyAwLi5uOyAxID0gc3RhdGVzIDEuLm47IGV0Yy4KKyAgICAgICAgICovCisgICAgICAgIHN0
YXR1cyA9IGFjcGlfZXZhbHVhdGVfaW50ZWdlcihwci0+aGFuZGxlLCAiX1BQQyIsIE5VTEwsICZw
cGMpOworCisgICAgICAgIGlmIChBQ1BJX0ZBSUxVUkUoc3RhdHVzKSAmJiBzdGF0dXMgIT0gQUVf
Tk9UX0ZPVU5EKSB7CisgICAgICAgICAgICAgICAgQUNQSV9FWENFUFRJT04oKEFFX0lORk8sIHN0
YXR1cywgIkV2YWx1YXRpbmcgX1BQQyIpKTsKKyAgICAgICAgICAgICAgICByZXR1cm4gLUVOT0RF
VjsKKyAgICAgICAgfQorCisgICAgICAgIHByLT5wZXJmb3JtYW5jZV9wbGF0Zm9ybV9saW1pdCA9
IChpbnQpcHBjOworCisgICAgICAgIHJldHVybiAwOworfQorCitzdGF0aWMgaW50IHhlbl9hY3Bp
X3Byb2Nlc3Nvcl9wcGNfaGFzX2NoYW5nZWQoc3RydWN0IGFjcGlfcHJvY2Vzc29yICpwcikKK3sK
KwlpbnQgcmV0OworCisJcmV0ID0geGVuX2FjcGlfcHJvY2Vzc29yX2dldF9wbGF0Zm9ybV9saW1p
dChwcik7CisKKwlpZiAocmV0IDwgMCkKKwkJcmV0dXJuIHJldDsKKwllbHNlCisJCXJldHVybiBw
cm9jZXNzb3JfY250bF94ZW5fbm90aWZ5KHByLAorCQkJUFJPQ0VTU09SX1BNX0NIQU5HRSwgUE1f
VFlQRV9QRVJGKTsKK30KKworc3RhdGljIHZvaWQgX19jcHVpbml0IHhlbl9hY3BpX3Byb2Nlc3Nv
cl9wb3dlcl9pbml0KHN0cnVjdCBhY3BpX3Byb2Nlc3NvciAqcHIsCisJCQkgICAgICBzdHJ1Y3Qg
YWNwaV9kZXZpY2UgKmRldmljZSkKK3sKKwlpZiAobGlrZWx5KCFwci0+ZmxhZ3MucG93ZXJfc2V0
dXBfZG9uZSkpIHsKKwkJLyogcmVzZXQgaWRsZSBib290IG9wdGlvbiB3aGljaCB3ZSBkb24ndCBj
YXJlICovCisJCWJvb3Rfb3B0aW9uX2lkbGVfb3ZlcnJpZGUgPSBJRExFX05PX09WRVJSSURFOwor
CQlhY3BpX3Byb2Nlc3Nvcl9wb3dlcl9pbml0KHByLCBkZXZpY2UpOworCQkvKiBzZXQgdG8gSURM
RV9IQUxUIGZvciB0cmFwcGluZyBpbnRvIFhlbiAqLworCQlib290X29wdGlvbl9pZGxlX292ZXJy
aWRlID0gSURMRV9IQUxUOworCisJCWlmIChwci0+ZmxhZ3MucG93ZXIpCisJCQlwcm9jZXNzb3Jf
Y250bF94ZW5fbm90aWZ5KHByLAorCQkJCQlQUk9DRVNTT1JfUE1fSU5JVCwgUE1fVFlQRV9JRExF
KTsKKwl9Cit9CisKIHN0YXRpYyBpbnQgX19jcHVpbml0IF9feGVuX2FjcGlfcHJvY2Vzc29yX2Fk
ZChzdHJ1Y3QgYWNwaV9kZXZpY2UgKmRldmljZSkKIHsKIAlzdHJ1Y3QgYWNwaV9wcm9jZXNzb3Ig
KnByID0gTlVMTDsKQEAgLTMzOSwxNCArMzkyLDEyIEBAIHN0YXRpYyBpbnQgX19jcHVpbml0IF9f
eGVuX2FjcGlfcHJvY2Vzc29yX2FkZChzdHJ1Y3QgYWNwaV9kZXZpY2UgKmRldmljZSkKIAl9CiAK
ICNpZmRlZiBDT05GSUdfQ1BVX0ZSRVEKLQlhY3BpX3Byb2Nlc3Nvcl9wcGNfaGFzX2NoYW5nZWQo
cHIsIDApOworCXhlbl9hY3BpX3Byb2Nlc3Nvcl9wcGNfaGFzX2NoYW5nZWQocHIpOwogI2VuZGlm
CiAJYWNwaV9wcm9jZXNzb3JfZ2V0X3Rocm90dGxpbmdfaW5mbyhwcik7CiAJYWNwaV9wcm9jZXNz
b3JfZ2V0X2xpbWl0X2luZm8ocHIpOwogCi0KLQlpZiAoY3B1aWRsZV9nZXRfZHJpdmVyKCkgPT0g
JmFjcGlfaWRsZV9kcml2ZXIpCi0JCWFjcGlfcHJvY2Vzc29yX3Bvd2VyX2luaXQocHIsIGRldmlj
ZSk7CisJeGVuX2FjcGlfcHJvY2Vzc29yX3Bvd2VyX2luaXQocHIsIGRldmljZSk7CiAKIAlwci0+
Y2RldiA9IHRoZXJtYWxfY29vbGluZ19kZXZpY2VfcmVnaXN0ZXIoIlByb2Nlc3NvciIsIGRldmlj
ZSwKIAkJCQkJCSZwcm9jZXNzb3JfY29vbGluZ19vcHMpOwpAQCAtNDAwLDQ4ICs0NTEsOCBAQCBz
dGF0aWMgaW50IF9fY3B1aW5pdCB4ZW5fYWNwaV9wcm9jZXNzb3JfYWRkKHN0cnVjdCBhY3BpX2Rl
dmljZSAqZGV2aWNlKQogCWlmICghcHIpCiAJCXJldHVybiAtRUlOVkFMOwogCi0JaWYgKHByLT5p
ZCA9PSAtMSkgewotCQlpbnQgZGV2aWNlX2RlY2xhcmF0aW9uOwotCQlpbnQgYXBpY19pZCA9IC0x
OwotCi0JCWlmICghc3RyY21wKGFjcGlfZGV2aWNlX2hpZChkZXZpY2UpLCBBQ1BJX1BST0NFU1NP
Ul9PQkpFQ1RfSElEKSkKLQkJCWRldmljZV9kZWNsYXJhdGlvbiA9IDA7Ci0JCWVsc2UKLQkJCWRl
dmljZV9kZWNsYXJhdGlvbiA9IDE7Ci0KLQkJYXBpY19pZCA9IGFjcGlfZ2V0X2NwdWlkKHByLT5o
YW5kbGUsCi0JCQlkZXZpY2VfZGVjbGFyYXRpb24sIHByLT5hY3BpX2lkKTsKLQkJaWYgKGFwaWNf
aWQgPT0gLTEpIHsKLQkJCS8qIFByb2Nlc3NvciBpcyBub3QgcHJlc2VudCBpbiBNQURUIHRhYmxl
ICovCi0JCQlyZXR1cm4gMDsKLQkJfQotCi0JCS8qCi0JCSAqIEl0J3MgcG9zc2libGUgdG8gaGF2
ZSBwci0+aWQgYXMgJy0xJyBldmVuIHdoZW4gaXQncyBhY3R1YWxseQotCQkgKiBwcmVzZW50IGlu
IE1BRFQgdGFibGUsIGUuZy4gZHVlIHRvIGxpbWl0aW5nIGRvbTAgbWF4IHZjcHVzCi0JCSAqIGxl
c3MgdGhhbiBwaHlzaWNhbCBwcmVzZW50IG51bWJlci4gSW4gc3VjaCBjYXNlIHdlIHN0aWxsIHdh
bnQKLQkJICogdG8gcGFyc2UgQUNQSSBwcm9jZXNzb3Igb2JqZWN0IGluZm9ybWF0aW9uLCBzbyBt
aW1pYyB0aGUKLQkJICogcHItPmlkIHRvIENQVS0wLiBUaGlzIHNob3VsZCBiZSBzYWZlIGJlY2F1
c2Ugd2Ugb25seSBjYXJlCi0JCSAqIGFib3V0IHJhdyBBQ1BJIGluZm9ybWF0aW9uLCB3aGljaCBv
bmx5IHJlbGllcyBvbiBwci0+YWNwaV9pZC4KLQkJICogRm9yIG90aGVyIGluZm9ybWF0aW9uIHJl
bHlpbmcgb24gcHItPmlkIGFuZCBnYXRoZXJlZCB0aHJvdWdoCi0JCSAqIFNNUCBmdW5jdGlvbiBj
YWxsLCBpdCdzIHNhZmUgdG8gbGV0IHRoZW0gcnVuIG9uIENQVS0wIHNpbmNlCi0JCSAqIHVuZGVy
bHlpbmcgWGVuIHdpbGwgY29sbGVjdCB0aGVtLiBPbmx5IGEgdmFsaWQgcHItPmlkIGNhbgotCQkg
KiBtYWtlIGxhdGVyIGludm9jYXRpb25zIGZvcndhcmQgcHJvZ3Jlc3MuCi0JCSAqLwotCQlwci0+
aWQgPSAwOwotCX0KLQotCWlmIChsaWtlbHkoIXByLT5mbGFncy5wb3dlcl9zZXR1cF9kb25lKSkg
ewotCQkvKiByZXNldCBpZGxlIGJvb3Qgb3B0aW9uIHdoaWNoIHdlIGRvbid0IGNhcmUgKi8KLQkJ
Ym9vdF9vcHRpb25faWRsZV9vdmVycmlkZSA9IElETEVfTk9fT1ZFUlJJREU7Ci0JCWFjcGlfcHJv
Y2Vzc29yX3Bvd2VyX2luaXQocHIsIGRldmljZSk7Ci0JCS8qIHNldCB0byBJRExFX0hBTFQgZm9y
IHRyYXBwaW5nIGludG8gWGVuICovCi0JCWJvb3Rfb3B0aW9uX2lkbGVfb3ZlcnJpZGUgPSBJRExF
X0hBTFQ7Ci0KLQkJaWYgKHByLT5mbGFncy5wb3dlcikKLQkJCXByb2Nlc3Nvcl9jbnRsX3hlbl9u
b3RpZnkocHIsCi0JCQkJCVBST0NFU1NPUl9QTV9JTklULCBQTV9UWVBFX0lETEUpOwotCX0KKwlp
ZiAocHItPmlkID09IC0xKQorCQlyZXR1cm4gMDsKIAogI2lmZGVmIENPTkZJR19DUFVfRlJFUQog
CWlmIChsaWtlbHkoIXByLT5wZXJmb3JtYW5jZSkpCi0tIAoxLjYuNS42Cgo=

--_002_DE8DF0795D48FD4CA783C40EC82923359737SHSMSX101ccrcorpint_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--_002_DE8DF0795D48FD4CA783C40EC82923359737SHSMSX101ccrcorpint_--


From xen-devel-bounces@lists.xensource.com Fri Dec 23 10:31:12 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 Dec 2011 10:31:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Re2Oz-0006zX-26; Fri, 23 Dec 2011 10:31:01 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1Re2Ox-0006yU-UL
	for xen-devel@lists.xensource.com; Fri, 23 Dec 2011 10:31:00 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1324636252!8352835!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDMwMjM5MQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27325 invoked from network); 23 Dec 2011 10:30:53 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-15.tower-182.messagelabs.com with SMTP;
	23 Dec 2011 10:30:53 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga101.fm.intel.com with ESMTP; 23 Dec 2011 02:30:51 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208,223";a="99639593"
Received: from pgsmsx602.gar.corp.intel.com ([10.221.43.81])
	by fmsmga001.fm.intel.com with ESMTP; 23 Dec 2011 02:30:50 -0800
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	pgsmsx602.gar.corp.intel.com (10.221.43.81) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Fri, 23 Dec 2011 18:30:50 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.38]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.223]) with mapi id
	14.01.0355.002; Fri, 23 Dec 2011 18:30:48 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: "konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
Thread-Topic: [PATCH 09/10] xen/acpi: Change Cx notify and add PPC handle
Thread-Index: AczBXe8v+3aspNmsQx2YiaRIU03xuw==
Date: Fri, 23 Dec 2011 10:30:48 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC82923359737@SHSMSX101.ccr.corp.intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
Content-Type: multipart/mixed;
	boundary="_002_DE8DF0795D48FD4CA783C40EC82923359737SHSMSX101ccrcorpint_"
MIME-Version: 1.0
Cc: "Brown, Len" <len.brown@intel.com>,
	"jeremy.fitzhardinge@citrix.com" <jeremy.fitzhardinge@citrix.com>,
	"Jiang, Yunhong" <yunhong.jiang@intel.com>, "Shan, 
	Haitao" <haitao.shan@intel.com>,
	Kernel development list <linux-kernel@vger.kernel.org>, "Zhao,
	Yakui" <yakui.zhao@intel.com>, "Luck, Tony" <tony.luck@intel.com>, "Kleen,
	Andi" <andi.kleen@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: [Xen-devel] [PATCH 09/10] xen/acpi: Change Cx notify and add PPC
	handle
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--_002_DE8DF0795D48FD4CA783C40EC82923359737SHSMSX101ccrcorpint_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

>From ca403566e922dde51e8809d7489337be4a55adfc Mon Sep 17 00:00:00 2001
From: Liu Jinsong <jinsong.liu@intel.com>
Date: Wed, 14 Dec 2011 15:59:02 +0800
Subject: [PATCH 09/10] xen/acpi: Change Cx notify and add PPC handle

This patch update Xen Cx notify.
Current Cx notify has 2 potential trigger points w/ some logically redundan=
t.
We remove the Cx notify point which is outside __xen_acpi_processor_add,
merging its logic to the Cx notify point inside __xen_acpi_processor_add.
This would more clean, as what native Cx did.

This patch also add Xen PPC handle when cpu hotadd.

Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
---
 drivers/acpi/processor_xen.c |  103 +++++++++++++++++++++++---------------=
----
 1 files changed, 57 insertions(+), 46 deletions(-)

diff --git a/drivers/acpi/processor_xen.c b/drivers/acpi/processor_xen.c
index 3af1f73..083e2b1 100644
--- a/drivers/acpi/processor_xen.c
+++ b/drivers/acpi/processor_xen.c
@@ -283,6 +283,59 @@ static int xen_acpi_processor_get_info(struct acpi_dev=
ice *device)
 	return 0;
 }
=20
+static int xen_acpi_processor_get_platform_limit(struct acpi_processor *pr=
)
+{
+        acpi_status status =3D 0;
+        unsigned long long ppc =3D 0;
+
+        if (!pr)
+                return -EINVAL;
+
+        /*
+         * _PPC indicates the maximum state currently supported by the pla=
tform
+         * (e.g. 0 =3D states 0..n; 1 =3D states 1..n; etc.
+         */
+        status =3D acpi_evaluate_integer(pr->handle, "_PPC", NULL, &ppc);
+
+        if (ACPI_FAILURE(status) && status !=3D AE_NOT_FOUND) {
+                ACPI_EXCEPTION((AE_INFO, status, "Evaluating _PPC"));
+                return -ENODEV;
+        }
+
+        pr->performance_platform_limit =3D (int)ppc;
+
+        return 0;
+}
+
+static int xen_acpi_processor_ppc_has_changed(struct acpi_processor *pr)
+{
+	int ret;
+
+	ret =3D xen_acpi_processor_get_platform_limit(pr);
+
+	if (ret < 0)
+		return ret;
+	else
+		return processor_cntl_xen_notify(pr,
+			PROCESSOR_PM_CHANGE, PM_TYPE_PERF);
+}
+
+static void __cpuinit xen_acpi_processor_power_init(struct acpi_processor =
*pr,
+			      struct acpi_device *device)
+{
+	if (likely(!pr->flags.power_setup_done)) {
+		/* reset idle boot option which we don't care */
+		boot_option_idle_override =3D IDLE_NO_OVERRIDE;
+		acpi_processor_power_init(pr, device);
+		/* set to IDLE_HALT for trapping into Xen */
+		boot_option_idle_override =3D IDLE_HALT;
+
+		if (pr->flags.power)
+			processor_cntl_xen_notify(pr,
+					PROCESSOR_PM_INIT, PM_TYPE_IDLE);
+	}
+}
+
 static int __cpuinit __xen_acpi_processor_add(struct acpi_device *device)
 {
 	struct acpi_processor *pr =3D NULL;
@@ -339,14 +392,12 @@ static int __cpuinit __xen_acpi_processor_add(struct =
acpi_device *device)
 	}
=20
 #ifdef CONFIG_CPU_FREQ
-	acpi_processor_ppc_has_changed(pr, 0);
+	xen_acpi_processor_ppc_has_changed(pr);
 #endif
 	acpi_processor_get_throttling_info(pr);
 	acpi_processor_get_limit_info(pr);
=20
-
-	if (cpuidle_get_driver() =3D=3D &acpi_idle_driver)
-		acpi_processor_power_init(pr, device);
+	xen_acpi_processor_power_init(pr, device);
=20
 	pr->cdev =3D thermal_cooling_device_register("Processor", device,
 						&processor_cooling_ops);
@@ -400,48 +451,8 @@ static int __cpuinit xen_acpi_processor_add(struct acp=
i_device *device)
 	if (!pr)
 		return -EINVAL;
=20
-	if (pr->id =3D=3D -1) {
-		int device_declaration;
-		int apic_id =3D -1;
-
-		if (!strcmp(acpi_device_hid(device), ACPI_PROCESSOR_OBJECT_HID))
-			device_declaration =3D 0;
-		else
-			device_declaration =3D 1;
-
-		apic_id =3D acpi_get_cpuid(pr->handle,
-			device_declaration, pr->acpi_id);
-		if (apic_id =3D=3D -1) {
-			/* Processor is not present in MADT table */
-			return 0;
-		}
-
-		/*
-		 * It's possible to have pr->id as '-1' even when it's actually
-		 * present in MADT table, e.g. due to limiting dom0 max vcpus
-		 * less than physical present number. In such case we still want
-		 * to parse ACPI processor object information, so mimic the
-		 * pr->id to CPU-0. This should be safe because we only care
-		 * about raw ACPI information, which only relies on pr->acpi_id.
-		 * For other information relying on pr->id and gathered through
-		 * SMP function call, it's safe to let them run on CPU-0 since
-		 * underlying Xen will collect them. Only a valid pr->id can
-		 * make later invocations forward progress.
-		 */
-		pr->id =3D 0;
-	}
-
-	if (likely(!pr->flags.power_setup_done)) {
-		/* reset idle boot option which we don't care */
-		boot_option_idle_override =3D IDLE_NO_OVERRIDE;
-		acpi_processor_power_init(pr, device);
-		/* set to IDLE_HALT for trapping into Xen */
-		boot_option_idle_override =3D IDLE_HALT;
-
-		if (pr->flags.power)
-			processor_cntl_xen_notify(pr,
-					PROCESSOR_PM_INIT, PM_TYPE_IDLE);
-	}
+	if (pr->id =3D=3D -1)
+		return 0;
=20
 #ifdef CONFIG_CPU_FREQ
 	if (likely(!pr->performance))
--=20
1.6.5.6

--_002_DE8DF0795D48FD4CA783C40EC82923359737SHSMSX101ccrcorpint_
Content-Type: application/octet-stream;
	name="0009-xen-acpi-Change-Cx-notify-and-add-PPC-handle.patch"
Content-Description: 0009-xen-acpi-Change-Cx-notify-and-add-PPC-handle.patch
Content-Disposition: attachment;
	filename="0009-xen-acpi-Change-Cx-notify-and-add-PPC-handle.patch";
	size=4832; creation-date="Wed, 14 Dec 2011 15:20:15 GMT";
	modification-date="Wed, 14 Dec 2011 15:03:34 GMT"
Content-Transfer-Encoding: base64

RnJvbSBjYTQwMzU2NmU5MjJkZGU1MWU4ODA5ZDc0ODkzMzdiZTRhNTVhZGZjIE1vbiBTZXAgMTcg
MDA6MDA6MDAgMjAwMQpGcm9tOiBMaXUgSmluc29uZyA8amluc29uZy5saXVAaW50ZWwuY29tPgpE
YXRlOiBXZWQsIDE0IERlYyAyMDExIDE1OjU5OjAyICswODAwClN1YmplY3Q6IFtQQVRDSCAwOS8x
MF0geGVuL2FjcGk6IENoYW5nZSBDeCBub3RpZnkgYW5kIGFkZCBQUEMgaGFuZGxlCgpUaGlzIHBh
dGNoIHVwZGF0ZSBYZW4gQ3ggbm90aWZ5LgpDdXJyZW50IEN4IG5vdGlmeSBoYXMgMiBwb3RlbnRp
YWwgdHJpZ2dlciBwb2ludHMgdy8gc29tZSBsb2dpY2FsbHkgcmVkdW5kYW50LgpXZSByZW1vdmUg
dGhlIEN4IG5vdGlmeSBwb2ludCB3aGljaCBpcyBvdXRzaWRlIF9feGVuX2FjcGlfcHJvY2Vzc29y
X2FkZCwKbWVyZ2luZyBpdHMgbG9naWMgdG8gdGhlIEN4IG5vdGlmeSBwb2ludCBpbnNpZGUgX194
ZW5fYWNwaV9wcm9jZXNzb3JfYWRkLgpUaGlzIHdvdWxkIG1vcmUgY2xlYW4sIGFzIHdoYXQgbmF0
aXZlIEN4IGRpZC4KClRoaXMgcGF0Y2ggYWxzbyBhZGQgWGVuIFBQQyBoYW5kbGUgd2hlbiBjcHUg
aG90YWRkLgoKU2lnbmVkLW9mZi1ieTogTGl1LCBKaW5zb25nIDxqaW5zb25nLmxpdUBpbnRlbC5j
b20+Ci0tLQogZHJpdmVycy9hY3BpL3Byb2Nlc3Nvcl94ZW4uYyB8ICAxMDMgKysrKysrKysrKysr
KysrKysrKysrKystLS0tLS0tLS0tLS0tLS0tLS0tCiAxIGZpbGVzIGNoYW5nZWQsIDU3IGluc2Vy
dGlvbnMoKyksIDQ2IGRlbGV0aW9ucygtKQoKZGlmZiAtLWdpdCBhL2RyaXZlcnMvYWNwaS9wcm9j
ZXNzb3JfeGVuLmMgYi9kcml2ZXJzL2FjcGkvcHJvY2Vzc29yX3hlbi5jCmluZGV4IDNhZjFmNzMu
LjA4M2UyYjEgMTAwNjQ0Ci0tLSBhL2RyaXZlcnMvYWNwaS9wcm9jZXNzb3JfeGVuLmMKKysrIGIv
ZHJpdmVycy9hY3BpL3Byb2Nlc3Nvcl94ZW4uYwpAQCAtMjgzLDYgKzI4Myw1OSBAQCBzdGF0aWMg
aW50IHhlbl9hY3BpX3Byb2Nlc3Nvcl9nZXRfaW5mbyhzdHJ1Y3QgYWNwaV9kZXZpY2UgKmRldmlj
ZSkKIAlyZXR1cm4gMDsKIH0KIAorc3RhdGljIGludCB4ZW5fYWNwaV9wcm9jZXNzb3JfZ2V0X3Bs
YXRmb3JtX2xpbWl0KHN0cnVjdCBhY3BpX3Byb2Nlc3NvciAqcHIpCit7CisgICAgICAgIGFjcGlf
c3RhdHVzIHN0YXR1cyA9IDA7CisgICAgICAgIHVuc2lnbmVkIGxvbmcgbG9uZyBwcGMgPSAwOwor
CisgICAgICAgIGlmICghcHIpCisgICAgICAgICAgICAgICAgcmV0dXJuIC1FSU5WQUw7CisKKyAg
ICAgICAgLyoKKyAgICAgICAgICogX1BQQyBpbmRpY2F0ZXMgdGhlIG1heGltdW0gc3RhdGUgY3Vy
cmVudGx5IHN1cHBvcnRlZCBieSB0aGUgcGxhdGZvcm0KKyAgICAgICAgICogKGUuZy4gMCA9IHN0
YXRlcyAwLi5uOyAxID0gc3RhdGVzIDEuLm47IGV0Yy4KKyAgICAgICAgICovCisgICAgICAgIHN0
YXR1cyA9IGFjcGlfZXZhbHVhdGVfaW50ZWdlcihwci0+aGFuZGxlLCAiX1BQQyIsIE5VTEwsICZw
cGMpOworCisgICAgICAgIGlmIChBQ1BJX0ZBSUxVUkUoc3RhdHVzKSAmJiBzdGF0dXMgIT0gQUVf
Tk9UX0ZPVU5EKSB7CisgICAgICAgICAgICAgICAgQUNQSV9FWENFUFRJT04oKEFFX0lORk8sIHN0
YXR1cywgIkV2YWx1YXRpbmcgX1BQQyIpKTsKKyAgICAgICAgICAgICAgICByZXR1cm4gLUVOT0RF
VjsKKyAgICAgICAgfQorCisgICAgICAgIHByLT5wZXJmb3JtYW5jZV9wbGF0Zm9ybV9saW1pdCA9
IChpbnQpcHBjOworCisgICAgICAgIHJldHVybiAwOworfQorCitzdGF0aWMgaW50IHhlbl9hY3Bp
X3Byb2Nlc3Nvcl9wcGNfaGFzX2NoYW5nZWQoc3RydWN0IGFjcGlfcHJvY2Vzc29yICpwcikKK3sK
KwlpbnQgcmV0OworCisJcmV0ID0geGVuX2FjcGlfcHJvY2Vzc29yX2dldF9wbGF0Zm9ybV9saW1p
dChwcik7CisKKwlpZiAocmV0IDwgMCkKKwkJcmV0dXJuIHJldDsKKwllbHNlCisJCXJldHVybiBw
cm9jZXNzb3JfY250bF94ZW5fbm90aWZ5KHByLAorCQkJUFJPQ0VTU09SX1BNX0NIQU5HRSwgUE1f
VFlQRV9QRVJGKTsKK30KKworc3RhdGljIHZvaWQgX19jcHVpbml0IHhlbl9hY3BpX3Byb2Nlc3Nv
cl9wb3dlcl9pbml0KHN0cnVjdCBhY3BpX3Byb2Nlc3NvciAqcHIsCisJCQkgICAgICBzdHJ1Y3Qg
YWNwaV9kZXZpY2UgKmRldmljZSkKK3sKKwlpZiAobGlrZWx5KCFwci0+ZmxhZ3MucG93ZXJfc2V0
dXBfZG9uZSkpIHsKKwkJLyogcmVzZXQgaWRsZSBib290IG9wdGlvbiB3aGljaCB3ZSBkb24ndCBj
YXJlICovCisJCWJvb3Rfb3B0aW9uX2lkbGVfb3ZlcnJpZGUgPSBJRExFX05PX09WRVJSSURFOwor
CQlhY3BpX3Byb2Nlc3Nvcl9wb3dlcl9pbml0KHByLCBkZXZpY2UpOworCQkvKiBzZXQgdG8gSURM
RV9IQUxUIGZvciB0cmFwcGluZyBpbnRvIFhlbiAqLworCQlib290X29wdGlvbl9pZGxlX292ZXJy
aWRlID0gSURMRV9IQUxUOworCisJCWlmIChwci0+ZmxhZ3MucG93ZXIpCisJCQlwcm9jZXNzb3Jf
Y250bF94ZW5fbm90aWZ5KHByLAorCQkJCQlQUk9DRVNTT1JfUE1fSU5JVCwgUE1fVFlQRV9JRExF
KTsKKwl9Cit9CisKIHN0YXRpYyBpbnQgX19jcHVpbml0IF9feGVuX2FjcGlfcHJvY2Vzc29yX2Fk
ZChzdHJ1Y3QgYWNwaV9kZXZpY2UgKmRldmljZSkKIHsKIAlzdHJ1Y3QgYWNwaV9wcm9jZXNzb3Ig
KnByID0gTlVMTDsKQEAgLTMzOSwxNCArMzkyLDEyIEBAIHN0YXRpYyBpbnQgX19jcHVpbml0IF9f
eGVuX2FjcGlfcHJvY2Vzc29yX2FkZChzdHJ1Y3QgYWNwaV9kZXZpY2UgKmRldmljZSkKIAl9CiAK
ICNpZmRlZiBDT05GSUdfQ1BVX0ZSRVEKLQlhY3BpX3Byb2Nlc3Nvcl9wcGNfaGFzX2NoYW5nZWQo
cHIsIDApOworCXhlbl9hY3BpX3Byb2Nlc3Nvcl9wcGNfaGFzX2NoYW5nZWQocHIpOwogI2VuZGlm
CiAJYWNwaV9wcm9jZXNzb3JfZ2V0X3Rocm90dGxpbmdfaW5mbyhwcik7CiAJYWNwaV9wcm9jZXNz
b3JfZ2V0X2xpbWl0X2luZm8ocHIpOwogCi0KLQlpZiAoY3B1aWRsZV9nZXRfZHJpdmVyKCkgPT0g
JmFjcGlfaWRsZV9kcml2ZXIpCi0JCWFjcGlfcHJvY2Vzc29yX3Bvd2VyX2luaXQocHIsIGRldmlj
ZSk7CisJeGVuX2FjcGlfcHJvY2Vzc29yX3Bvd2VyX2luaXQocHIsIGRldmljZSk7CiAKIAlwci0+
Y2RldiA9IHRoZXJtYWxfY29vbGluZ19kZXZpY2VfcmVnaXN0ZXIoIlByb2Nlc3NvciIsIGRldmlj
ZSwKIAkJCQkJCSZwcm9jZXNzb3JfY29vbGluZ19vcHMpOwpAQCAtNDAwLDQ4ICs0NTEsOCBAQCBz
dGF0aWMgaW50IF9fY3B1aW5pdCB4ZW5fYWNwaV9wcm9jZXNzb3JfYWRkKHN0cnVjdCBhY3BpX2Rl
dmljZSAqZGV2aWNlKQogCWlmICghcHIpCiAJCXJldHVybiAtRUlOVkFMOwogCi0JaWYgKHByLT5p
ZCA9PSAtMSkgewotCQlpbnQgZGV2aWNlX2RlY2xhcmF0aW9uOwotCQlpbnQgYXBpY19pZCA9IC0x
OwotCi0JCWlmICghc3RyY21wKGFjcGlfZGV2aWNlX2hpZChkZXZpY2UpLCBBQ1BJX1BST0NFU1NP
Ul9PQkpFQ1RfSElEKSkKLQkJCWRldmljZV9kZWNsYXJhdGlvbiA9IDA7Ci0JCWVsc2UKLQkJCWRl
dmljZV9kZWNsYXJhdGlvbiA9IDE7Ci0KLQkJYXBpY19pZCA9IGFjcGlfZ2V0X2NwdWlkKHByLT5o
YW5kbGUsCi0JCQlkZXZpY2VfZGVjbGFyYXRpb24sIHByLT5hY3BpX2lkKTsKLQkJaWYgKGFwaWNf
aWQgPT0gLTEpIHsKLQkJCS8qIFByb2Nlc3NvciBpcyBub3QgcHJlc2VudCBpbiBNQURUIHRhYmxl
ICovCi0JCQlyZXR1cm4gMDsKLQkJfQotCi0JCS8qCi0JCSAqIEl0J3MgcG9zc2libGUgdG8gaGF2
ZSBwci0+aWQgYXMgJy0xJyBldmVuIHdoZW4gaXQncyBhY3R1YWxseQotCQkgKiBwcmVzZW50IGlu
IE1BRFQgdGFibGUsIGUuZy4gZHVlIHRvIGxpbWl0aW5nIGRvbTAgbWF4IHZjcHVzCi0JCSAqIGxl
c3MgdGhhbiBwaHlzaWNhbCBwcmVzZW50IG51bWJlci4gSW4gc3VjaCBjYXNlIHdlIHN0aWxsIHdh
bnQKLQkJICogdG8gcGFyc2UgQUNQSSBwcm9jZXNzb3Igb2JqZWN0IGluZm9ybWF0aW9uLCBzbyBt
aW1pYyB0aGUKLQkJICogcHItPmlkIHRvIENQVS0wLiBUaGlzIHNob3VsZCBiZSBzYWZlIGJlY2F1
c2Ugd2Ugb25seSBjYXJlCi0JCSAqIGFib3V0IHJhdyBBQ1BJIGluZm9ybWF0aW9uLCB3aGljaCBv
bmx5IHJlbGllcyBvbiBwci0+YWNwaV9pZC4KLQkJICogRm9yIG90aGVyIGluZm9ybWF0aW9uIHJl
bHlpbmcgb24gcHItPmlkIGFuZCBnYXRoZXJlZCB0aHJvdWdoCi0JCSAqIFNNUCBmdW5jdGlvbiBj
YWxsLCBpdCdzIHNhZmUgdG8gbGV0IHRoZW0gcnVuIG9uIENQVS0wIHNpbmNlCi0JCSAqIHVuZGVy
bHlpbmcgWGVuIHdpbGwgY29sbGVjdCB0aGVtLiBPbmx5IGEgdmFsaWQgcHItPmlkIGNhbgotCQkg
KiBtYWtlIGxhdGVyIGludm9jYXRpb25zIGZvcndhcmQgcHJvZ3Jlc3MuCi0JCSAqLwotCQlwci0+
aWQgPSAwOwotCX0KLQotCWlmIChsaWtlbHkoIXByLT5mbGFncy5wb3dlcl9zZXR1cF9kb25lKSkg
ewotCQkvKiByZXNldCBpZGxlIGJvb3Qgb3B0aW9uIHdoaWNoIHdlIGRvbid0IGNhcmUgKi8KLQkJ
Ym9vdF9vcHRpb25faWRsZV9vdmVycmlkZSA9IElETEVfTk9fT1ZFUlJJREU7Ci0JCWFjcGlfcHJv
Y2Vzc29yX3Bvd2VyX2luaXQocHIsIGRldmljZSk7Ci0JCS8qIHNldCB0byBJRExFX0hBTFQgZm9y
IHRyYXBwaW5nIGludG8gWGVuICovCi0JCWJvb3Rfb3B0aW9uX2lkbGVfb3ZlcnJpZGUgPSBJRExF
X0hBTFQ7Ci0KLQkJaWYgKHByLT5mbGFncy5wb3dlcikKLQkJCXByb2Nlc3Nvcl9jbnRsX3hlbl9u
b3RpZnkocHIsCi0JCQkJCVBST0NFU1NPUl9QTV9JTklULCBQTV9UWVBFX0lETEUpOwotCX0KKwlp
ZiAocHItPmlkID09IC0xKQorCQlyZXR1cm4gMDsKIAogI2lmZGVmIENPTkZJR19DUFVfRlJFUQog
CWlmIChsaWtlbHkoIXByLT5wZXJmb3JtYW5jZSkpCi0tIAoxLjYuNS42Cgo=

--_002_DE8DF0795D48FD4CA783C40EC82923359737SHSMSX101ccrcorpint_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--_002_DE8DF0795D48FD4CA783C40EC82923359737SHSMSX101ccrcorpint_--


From xen-devel-bounces@lists.xensource.com Fri Dec 23 10:32:36 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 Dec 2011 10:32:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Re2QO-0007H5-KJ; Fri, 23 Dec 2011 10:32:28 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1Re2QM-0007GD-Ku
	for xen-devel@lists.xensource.com; Fri, 23 Dec 2011 10:32:27 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1324636309!46013271!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDMwMDk1NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20847 invoked from network); 23 Dec 2011 10:31:50 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-12.tower-27.messagelabs.com with SMTP;
	23 Dec 2011 10:31:50 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga102.fm.intel.com with ESMTP; 23 Dec 2011 02:32:20 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208,223";a="99639976"
Received: from pgsmsx603.gar.corp.intel.com ([10.221.43.87])
	by fmsmga001.fm.intel.com with ESMTP; 23 Dec 2011 02:32:19 -0800
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	pgsmsx603.gar.corp.intel.com (10.221.43.87) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Fri, 23 Dec 2011 18:32:15 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.38]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.199]) with mapi id
	14.01.0355.002; Fri, 23 Dec 2011 18:32:13 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: "konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
Thread-Topic: [PATCH 10/10] Xen: update pcpu online/offline logic
Thread-Index: AczBXiHCEJQO+tSfSs+gjKRmoi953Q==
Date: Fri, 23 Dec 2011 10:32:12 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC82923359771@SHSMSX101.ccr.corp.intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
Content-Type: multipart/mixed;
	boundary="_002_DE8DF0795D48FD4CA783C40EC82923359771SHSMSX101ccrcorpint_"
MIME-Version: 1.0
Cc: "Brown, Len" <len.brown@intel.com>,
	"jeremy.fitzhardinge@citrix.com" <jeremy.fitzhardinge@citrix.com>,
	"Jiang, Yunhong" <yunhong.jiang@intel.com>, "Shan, 
	Haitao" <haitao.shan@intel.com>,
	Kernel development list <linux-kernel@vger.kernel.org>, "Zhao,
	Yakui" <yakui.zhao@intel.com>, "Luck, Tony" <tony.luck@intel.com>, "Kleen,
	Andi" <andi.kleen@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: [Xen-devel] [PATCH 10/10] Xen: update pcpu online/offline logic
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--_002_DE8DF0795D48FD4CA783C40EC82923359771SHSMSX101ccrcorpint_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

>From 1e59d2ec2ff93b42c86d18c7cc9432ca2172a795 Mon Sep 17 00:00:00 2001
From: Liu Jinsong <jinsong.liu@intel.com>
Date: Wed, 14 Dec 2011 21:06:11 +0800
Subject: [PATCH 10/10] Xen: update pcpu online/offline logic

This patch update pcpu online/offline logic.

It closes cpu0's /sys/.../xen_pcpu0/online authority to user.
It also simplifies pcpu sync by removing redundant logic.

Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
Signed-off-by: Jiang, Yunhong <yunhong.jiang@intel.com>
---
 drivers/xen/pcpu.c |   71 ++++++++++++++----------------------------------=
----
 1 files changed, 19 insertions(+), 52 deletions(-)

diff --git a/drivers/xen/pcpu.c b/drivers/xen/pcpu.c
index 6d1a770..1d32784 100644
--- a/drivers/xen/pcpu.c
+++ b/drivers/xen/pcpu.c
@@ -24,7 +24,6 @@ static RAW_NOTIFIER_HEAD(xen_pcpu_chain);
=20
 struct xen_pcpus {
 	struct list_head list;
-	int present;
 };
 static struct xen_pcpus xen_pcpus;
=20
@@ -189,9 +188,13 @@ static int pcpu_sysdev_init(struct pcpu *cpu)
 		kfree(cpu);
 		return -1;
 	}
-	sysdev_create_file(&cpu->sysdev, &attr_online);
 	sysdev_create_file(&cpu->sysdev, &attr_apic_id);
 	sysdev_create_file(&cpu->sysdev, &attr_acpi_id);
+
+	/* Not open cpu0 online access to user */
+	if (cpu->sysdev.id)
+		sysdev_create_file(&cpu->sysdev, &attr_online);
+
 	return 0;
 }
=20
@@ -239,17 +242,10 @@ static struct pcpu *init_pcpu(struct xenpf_pcpuinfo *=
info)
 	return pcpu;
 }
=20
-#define PCPU_NO_CHANGE			0
-#define PCPU_ADDED			1
-#define PCPU_ONLINE_OFFLINE		2
-#define PCPU_REMOVED			3
 /*
  * Caller should hold the pcpu lock
- * < 0: Something wrong
- * 0: No changes
- * > 0: State changed
  */
-static struct pcpu *_sync_pcpu(int cpu_num, int *max_id, int *result)
+static int _sync_pcpu(int cpu_num, int *max_id)
 {
 	struct pcpu *pcpu =3D NULL;
 	struct xenpf_pcpuinfo *info;
@@ -259,14 +255,12 @@ static struct pcpu *_sync_pcpu(int cpu_num, int *max_=
id, int *result)
 	};
 	int ret;
=20
-	*result =3D -1;
-
 	info =3D &op.u.pcpu_info;
 	info->xen_cpuid =3D cpu_num;
=20
 	ret =3D HYPERVISOR_dom0_op(&op);
 	if (ret)
-		return NULL;
+		return -1;
=20
 	if (max_id)
 		*max_id =3D op.u.pcpu_info.max_present;
@@ -275,28 +269,24 @@ static struct pcpu *_sync_pcpu(int cpu_num, int *max_=
id, int *result)
=20
 	if (info->flags & XEN_PCPU_FLAGS_INVALID) {
 		/* The pcpu has been removed */
-		*result =3D PCPU_NO_CHANGE;
 		if (pcpu) {
 			raw_notifier_call_chain(&xen_pcpu_chain,
 			  XEN_PCPU_REMOVE,
 			  (void *)(long)pcpu->xen_id);
 			xen_pcpu_free(pcpu);
-			*result =3D PCPU_REMOVED;
 		}
-		return NULL;
+		return 0;
 	}
=20
=20
 	if (!pcpu) {
-		*result =3D PCPU_ADDED;
 		pcpu =3D init_pcpu(info);
 		if (pcpu =3D=3D NULL) {
 			printk(KERN_WARNING "Failed to init pcpu %x\n",
 			  info->xen_cpuid);
-			  *result =3D -1;
+			return -1;
 		}
 	} else {
-		*result =3D PCPU_NO_CHANGE;
 		/*
 		 * Old PCPU is replaced with a new pcpu, this means
 		 * several virq is missed, will it happen?
@@ -307,10 +297,10 @@ static struct pcpu *_sync_pcpu(int cpu_num, int *max_=
id, int *result)
 			pcpu->apic_id =3D info->apic_id;
 			pcpu->acpi_id =3D info->acpi_id;
 		}
-		if (xen_pcpu_online_check(info, pcpu))
-			*result =3D PCPU_ONLINE_OFFLINE;
+		xen_pcpu_online_check(info, pcpu);
 	}
-	return pcpu;
+
+	return 0;
 }
=20
 int xen_pcpu_index(uint32_t id, int is_acpiid)
@@ -353,50 +343,27 @@ static int xen_sync_pcpus(void)
 	/*
 	 * Boot cpu always have cpu_id 0 in xen
 	 */
-	int cpu_num =3D 0, max_id =3D 0, result =3D 0, present =3D 0;
+	int cpu_num =3D 0, max_id =3D 0, ret =3D 0;
 	struct list_head *elem, *tmp;
 	struct pcpu *pcpu;
=20
 	get_pcpu_lock();
=20
-	while ((result >=3D 0) && (cpu_num <=3D max_id)) {
-		pcpu =3D _sync_pcpu(cpu_num, &max_id, &result);
-
-		printk(KERN_DEBUG "sync cpu %x get result %x max_id %x\n",
-			cpu_num, result, max_id);
-
-		switch (result)	{
-		case PCPU_NO_CHANGE:
-			if (pcpu)
-				present++;
-			break;
-		case PCPU_ADDED:
-		case PCPU_ONLINE_OFFLINE:
-			present++;
-		case PCPU_REMOVED:
-			break;
-		default:
-			printk(KERN_WARNING "Failed to sync pcpu %x\n",
-			  cpu_num);
-			break;
-
-		}
+	while (!ret && (cpu_num <=3D max_id)) {
+		ret =3D _sync_pcpu(cpu_num, &max_id);
 		cpu_num++;
 	}
=20
-	if (result < 0) {
+	if (ret < 0) {
 		list_for_each_safe(elem, tmp, &xen_pcpus.list) {
 			pcpu =3D list_entry(elem, struct pcpu, pcpu_list);
 			xen_pcpu_free(pcpu);
 		}
-		present =3D 0;
 	}
=20
-	xen_pcpus.present =3D present;
-
 	put_pcpu_lock();
=20
-	return 0;
+	return ret;
 }
=20
 static void xen_pcpu_dpc(struct work_struct *work)
@@ -436,10 +403,10 @@ static int __init xen_pcpu_init(void)
 	}
=20
 	INIT_LIST_HEAD(&xen_pcpus.list);
-	xen_pcpus.present =3D 0;
=20
 	xen_sync_pcpus();
-	if (xen_pcpus.present > 0)
+
+	if (!list_empty(&xen_pcpus.list))
 		err =3D bind_virq_to_irqhandler(VIRQ_PCPU_STATE,
 			0, xen_pcpu_interrupt, 0, "pcpu", NULL);
 	if (err < 0)
--=20
1.6.5.6

--_002_DE8DF0795D48FD4CA783C40EC82923359771SHSMSX101ccrcorpint_
Content-Type: application/octet-stream;
	name="0010-Xen-update-pcpu-online-offline-logic.patch"
Content-Description: 0010-Xen-update-pcpu-online-offline-logic.patch
Content-Disposition: attachment;
	filename="0010-Xen-update-pcpu-online-offline-logic.patch"; size=4793;
	creation-date="Wed, 14 Dec 2011 15:20:15 GMT";
	modification-date="Wed, 14 Dec 2011 15:03:34 GMT"
Content-Transfer-Encoding: base64

RnJvbSAxZTU5ZDJlYzJmZjkzYjQyYzg2ZDE4YzdjYzk0MzJjYTIxNzJhNzk1IE1vbiBTZXAgMTcg
MDA6MDA6MDAgMjAwMQpGcm9tOiBMaXUgSmluc29uZyA8amluc29uZy5saXVAaW50ZWwuY29tPgpE
YXRlOiBXZWQsIDE0IERlYyAyMDExIDIxOjA2OjExICswODAwClN1YmplY3Q6IFtQQVRDSCAxMC8x
MF0gWGVuOiB1cGRhdGUgcGNwdSBvbmxpbmUvb2ZmbGluZSBsb2dpYwoKVGhpcyBwYXRjaCB1cGRh
dGUgcGNwdSBvbmxpbmUvb2ZmbGluZSBsb2dpYy4KCkl0IGNsb3NlcyBjcHUwJ3MgL3N5cy8uLi4v
eGVuX3BjcHUwL29ubGluZSBhdXRob3JpdHkgdG8gdXNlci4KSXQgYWxzbyBzaW1wbGlmaWVzIHBj
cHUgc3luYyBieSByZW1vdmluZyByZWR1bmRhbnQgbG9naWMuCgpTaWduZWQtb2ZmLWJ5OiBMaXUs
IEppbnNvbmcgPGppbnNvbmcubGl1QGludGVsLmNvbT4KU2lnbmVkLW9mZi1ieTogSmlhbmcsIFl1
bmhvbmcgPHl1bmhvbmcuamlhbmdAaW50ZWwuY29tPgotLS0KIGRyaXZlcnMveGVuL3BjcHUuYyB8
ICAgNzEgKysrKysrKysrKysrKystLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LQogMSBmaWxlcyBjaGFuZ2VkLCAxOSBpbnNlcnRpb25zKCspLCA1MiBkZWxldGlvbnMoLSkKCmRp
ZmYgLS1naXQgYS9kcml2ZXJzL3hlbi9wY3B1LmMgYi9kcml2ZXJzL3hlbi9wY3B1LmMKaW5kZXgg
NmQxYTc3MC4uMWQzMjc4NCAxMDA2NDQKLS0tIGEvZHJpdmVycy94ZW4vcGNwdS5jCisrKyBiL2Ry
aXZlcnMveGVuL3BjcHUuYwpAQCAtMjQsNyArMjQsNiBAQCBzdGF0aWMgUkFXX05PVElGSUVSX0hF
QUQoeGVuX3BjcHVfY2hhaW4pOwogCiBzdHJ1Y3QgeGVuX3BjcHVzIHsKIAlzdHJ1Y3QgbGlzdF9o
ZWFkIGxpc3Q7Ci0JaW50IHByZXNlbnQ7CiB9Owogc3RhdGljIHN0cnVjdCB4ZW5fcGNwdXMgeGVu
X3BjcHVzOwogCkBAIC0xODksOSArMTg4LDEzIEBAIHN0YXRpYyBpbnQgcGNwdV9zeXNkZXZfaW5p
dChzdHJ1Y3QgcGNwdSAqY3B1KQogCQlrZnJlZShjcHUpOwogCQlyZXR1cm4gLTE7CiAJfQotCXN5
c2Rldl9jcmVhdGVfZmlsZSgmY3B1LT5zeXNkZXYsICZhdHRyX29ubGluZSk7CiAJc3lzZGV2X2Ny
ZWF0ZV9maWxlKCZjcHUtPnN5c2RldiwgJmF0dHJfYXBpY19pZCk7CiAJc3lzZGV2X2NyZWF0ZV9m
aWxlKCZjcHUtPnN5c2RldiwgJmF0dHJfYWNwaV9pZCk7CisKKwkvKiBOb3Qgb3BlbiBjcHUwIG9u
bGluZSBhY2Nlc3MgdG8gdXNlciAqLworCWlmIChjcHUtPnN5c2Rldi5pZCkKKwkJc3lzZGV2X2Ny
ZWF0ZV9maWxlKCZjcHUtPnN5c2RldiwgJmF0dHJfb25saW5lKTsKKwogCXJldHVybiAwOwogfQog
CkBAIC0yMzksMTcgKzI0MiwxMCBAQCBzdGF0aWMgc3RydWN0IHBjcHUgKmluaXRfcGNwdShzdHJ1
Y3QgeGVucGZfcGNwdWluZm8gKmluZm8pCiAJcmV0dXJuIHBjcHU7CiB9CiAKLSNkZWZpbmUgUENQ
VV9OT19DSEFOR0UJCQkwCi0jZGVmaW5lIFBDUFVfQURERUQJCQkxCi0jZGVmaW5lIFBDUFVfT05M
SU5FX09GRkxJTkUJCTIKLSNkZWZpbmUgUENQVV9SRU1PVkVECQkJMwogLyoKICAqIENhbGxlciBz
aG91bGQgaG9sZCB0aGUgcGNwdSBsb2NrCi0gKiA8IDA6IFNvbWV0aGluZyB3cm9uZwotICogMDog
Tm8gY2hhbmdlcwotICogPiAwOiBTdGF0ZSBjaGFuZ2VkCiAgKi8KLXN0YXRpYyBzdHJ1Y3QgcGNw
dSAqX3N5bmNfcGNwdShpbnQgY3B1X251bSwgaW50ICptYXhfaWQsIGludCAqcmVzdWx0KQorc3Rh
dGljIGludCBfc3luY19wY3B1KGludCBjcHVfbnVtLCBpbnQgKm1heF9pZCkKIHsKIAlzdHJ1Y3Qg
cGNwdSAqcGNwdSA9IE5VTEw7CiAJc3RydWN0IHhlbnBmX3BjcHVpbmZvICppbmZvOwpAQCAtMjU5
LDE0ICsyNTUsMTIgQEAgc3RhdGljIHN0cnVjdCBwY3B1ICpfc3luY19wY3B1KGludCBjcHVfbnVt
LCBpbnQgKm1heF9pZCwgaW50ICpyZXN1bHQpCiAJfTsKIAlpbnQgcmV0OwogCi0JKnJlc3VsdCA9
IC0xOwotCiAJaW5mbyA9ICZvcC51LnBjcHVfaW5mbzsKIAlpbmZvLT54ZW5fY3B1aWQgPSBjcHVf
bnVtOwogCiAJcmV0ID0gSFlQRVJWSVNPUl9kb20wX29wKCZvcCk7CiAJaWYgKHJldCkKLQkJcmV0
dXJuIE5VTEw7CisJCXJldHVybiAtMTsKIAogCWlmIChtYXhfaWQpCiAJCSptYXhfaWQgPSBvcC51
LnBjcHVfaW5mby5tYXhfcHJlc2VudDsKQEAgLTI3NSwyOCArMjY5LDI0IEBAIHN0YXRpYyBzdHJ1
Y3QgcGNwdSAqX3N5bmNfcGNwdShpbnQgY3B1X251bSwgaW50ICptYXhfaWQsIGludCAqcmVzdWx0
KQogCiAJaWYgKGluZm8tPmZsYWdzICYgWEVOX1BDUFVfRkxBR1NfSU5WQUxJRCkgewogCQkvKiBU
aGUgcGNwdSBoYXMgYmVlbiByZW1vdmVkICovCi0JCSpyZXN1bHQgPSBQQ1BVX05PX0NIQU5HRTsK
IAkJaWYgKHBjcHUpIHsKIAkJCXJhd19ub3RpZmllcl9jYWxsX2NoYWluKCZ4ZW5fcGNwdV9jaGFp
biwKIAkJCSAgWEVOX1BDUFVfUkVNT1ZFLAogCQkJICAodm9pZCAqKShsb25nKXBjcHUtPnhlbl9p
ZCk7CiAJCQl4ZW5fcGNwdV9mcmVlKHBjcHUpOwotCQkJKnJlc3VsdCA9IFBDUFVfUkVNT1ZFRDsK
IAkJfQotCQlyZXR1cm4gTlVMTDsKKwkJcmV0dXJuIDA7CiAJfQogCiAKIAlpZiAoIXBjcHUpIHsK
LQkJKnJlc3VsdCA9IFBDUFVfQURERUQ7CiAJCXBjcHUgPSBpbml0X3BjcHUoaW5mbyk7CiAJCWlm
IChwY3B1ID09IE5VTEwpIHsKIAkJCXByaW50ayhLRVJOX1dBUk5JTkcgIkZhaWxlZCB0byBpbml0
IHBjcHUgJXhcbiIsCiAJCQkgIGluZm8tPnhlbl9jcHVpZCk7Ci0JCQkgICpyZXN1bHQgPSAtMTsK
KwkJCXJldHVybiAtMTsKIAkJfQogCX0gZWxzZSB7Ci0JCSpyZXN1bHQgPSBQQ1BVX05PX0NIQU5H
RTsKIAkJLyoKIAkJICogT2xkIFBDUFUgaXMgcmVwbGFjZWQgd2l0aCBhIG5ldyBwY3B1LCB0aGlz
IG1lYW5zCiAJCSAqIHNldmVyYWwgdmlycSBpcyBtaXNzZWQsIHdpbGwgaXQgaGFwcGVuPwpAQCAt
MzA3LDEwICsyOTcsMTAgQEAgc3RhdGljIHN0cnVjdCBwY3B1ICpfc3luY19wY3B1KGludCBjcHVf
bnVtLCBpbnQgKm1heF9pZCwgaW50ICpyZXN1bHQpCiAJCQlwY3B1LT5hcGljX2lkID0gaW5mby0+
YXBpY19pZDsKIAkJCXBjcHUtPmFjcGlfaWQgPSBpbmZvLT5hY3BpX2lkOwogCQl9Ci0JCWlmICh4
ZW5fcGNwdV9vbmxpbmVfY2hlY2soaW5mbywgcGNwdSkpCi0JCQkqcmVzdWx0ID0gUENQVV9PTkxJ
TkVfT0ZGTElORTsKKwkJeGVuX3BjcHVfb25saW5lX2NoZWNrKGluZm8sIHBjcHUpOwogCX0KLQly
ZXR1cm4gcGNwdTsKKworCXJldHVybiAwOwogfQogCiBpbnQgeGVuX3BjcHVfaW5kZXgodWludDMy
X3QgaWQsIGludCBpc19hY3BpaWQpCkBAIC0zNTMsNTAgKzM0MywyNyBAQCBzdGF0aWMgaW50IHhl
bl9zeW5jX3BjcHVzKHZvaWQpCiAJLyoKIAkgKiBCb290IGNwdSBhbHdheXMgaGF2ZSBjcHVfaWQg
MCBpbiB4ZW4KIAkgKi8KLQlpbnQgY3B1X251bSA9IDAsIG1heF9pZCA9IDAsIHJlc3VsdCA9IDAs
IHByZXNlbnQgPSAwOworCWludCBjcHVfbnVtID0gMCwgbWF4X2lkID0gMCwgcmV0ID0gMDsKIAlz
dHJ1Y3QgbGlzdF9oZWFkICplbGVtLCAqdG1wOwogCXN0cnVjdCBwY3B1ICpwY3B1OwogCiAJZ2V0
X3BjcHVfbG9jaygpOwogCi0Jd2hpbGUgKChyZXN1bHQgPj0gMCkgJiYgKGNwdV9udW0gPD0gbWF4
X2lkKSkgewotCQlwY3B1ID0gX3N5bmNfcGNwdShjcHVfbnVtLCAmbWF4X2lkLCAmcmVzdWx0KTsK
LQotCQlwcmludGsoS0VSTl9ERUJVRyAic3luYyBjcHUgJXggZ2V0IHJlc3VsdCAleCBtYXhfaWQg
JXhcbiIsCi0JCQljcHVfbnVtLCByZXN1bHQsIG1heF9pZCk7Ci0KLQkJc3dpdGNoIChyZXN1bHQp
CXsKLQkJY2FzZSBQQ1BVX05PX0NIQU5HRToKLQkJCWlmIChwY3B1KQotCQkJCXByZXNlbnQrKzsK
LQkJCWJyZWFrOwotCQljYXNlIFBDUFVfQURERUQ6Ci0JCWNhc2UgUENQVV9PTkxJTkVfT0ZGTElO
RToKLQkJCXByZXNlbnQrKzsKLQkJY2FzZSBQQ1BVX1JFTU9WRUQ6Ci0JCQlicmVhazsKLQkJZGVm
YXVsdDoKLQkJCXByaW50ayhLRVJOX1dBUk5JTkcgIkZhaWxlZCB0byBzeW5jIHBjcHUgJXhcbiIs
Ci0JCQkgIGNwdV9udW0pOwotCQkJYnJlYWs7Ci0KLQkJfQorCXdoaWxlICghcmV0ICYmIChjcHVf
bnVtIDw9IG1heF9pZCkpIHsKKwkJcmV0ID0gX3N5bmNfcGNwdShjcHVfbnVtLCAmbWF4X2lkKTsK
IAkJY3B1X251bSsrOwogCX0KIAotCWlmIChyZXN1bHQgPCAwKSB7CisJaWYgKHJldCA8IDApIHsK
IAkJbGlzdF9mb3JfZWFjaF9zYWZlKGVsZW0sIHRtcCwgJnhlbl9wY3B1cy5saXN0KSB7CiAJCQlw
Y3B1ID0gbGlzdF9lbnRyeShlbGVtLCBzdHJ1Y3QgcGNwdSwgcGNwdV9saXN0KTsKIAkJCXhlbl9w
Y3B1X2ZyZWUocGNwdSk7CiAJCX0KLQkJcHJlc2VudCA9IDA7CiAJfQogCi0JeGVuX3BjcHVzLnBy
ZXNlbnQgPSBwcmVzZW50OwotCiAJcHV0X3BjcHVfbG9jaygpOwogCi0JcmV0dXJuIDA7CisJcmV0
dXJuIHJldDsKIH0KIAogc3RhdGljIHZvaWQgeGVuX3BjcHVfZHBjKHN0cnVjdCB3b3JrX3N0cnVj
dCAqd29yaykKQEAgLTQzNiwxMCArNDAzLDEwIEBAIHN0YXRpYyBpbnQgX19pbml0IHhlbl9wY3B1
X2luaXQodm9pZCkKIAl9CiAKIAlJTklUX0xJU1RfSEVBRCgmeGVuX3BjcHVzLmxpc3QpOwotCXhl
bl9wY3B1cy5wcmVzZW50ID0gMDsKIAogCXhlbl9zeW5jX3BjcHVzKCk7Ci0JaWYgKHhlbl9wY3B1
cy5wcmVzZW50ID4gMCkKKworCWlmICghbGlzdF9lbXB0eSgmeGVuX3BjcHVzLmxpc3QpKQogCQll
cnIgPSBiaW5kX3ZpcnFfdG9faXJxaGFuZGxlcihWSVJRX1BDUFVfU1RBVEUsCiAJCQkwLCB4ZW5f
cGNwdV9pbnRlcnJ1cHQsIDAsICJwY3B1IiwgTlVMTCk7CiAJaWYgKGVyciA8IDApCi0tIAoxLjYu
NS42Cgo=

--_002_DE8DF0795D48FD4CA783C40EC82923359771SHSMSX101ccrcorpint_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--_002_DE8DF0795D48FD4CA783C40EC82923359771SHSMSX101ccrcorpint_--


From xen-devel-bounces@lists.xensource.com Fri Dec 23 10:32:36 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 Dec 2011 10:32:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Re2QO-0007H5-KJ; Fri, 23 Dec 2011 10:32:28 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1Re2QM-0007GD-Ku
	for xen-devel@lists.xensource.com; Fri, 23 Dec 2011 10:32:27 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1324636309!46013271!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDMwMDk1NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20847 invoked from network); 23 Dec 2011 10:31:50 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-12.tower-27.messagelabs.com with SMTP;
	23 Dec 2011 10:31:50 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga102.fm.intel.com with ESMTP; 23 Dec 2011 02:32:20 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208,223";a="99639976"
Received: from pgsmsx603.gar.corp.intel.com ([10.221.43.87])
	by fmsmga001.fm.intel.com with ESMTP; 23 Dec 2011 02:32:19 -0800
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	pgsmsx603.gar.corp.intel.com (10.221.43.87) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Fri, 23 Dec 2011 18:32:15 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.38]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.199]) with mapi id
	14.01.0355.002; Fri, 23 Dec 2011 18:32:13 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: "konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
Thread-Topic: [PATCH 10/10] Xen: update pcpu online/offline logic
Thread-Index: AczBXiHCEJQO+tSfSs+gjKRmoi953Q==
Date: Fri, 23 Dec 2011 10:32:12 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC82923359771@SHSMSX101.ccr.corp.intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
Content-Type: multipart/mixed;
	boundary="_002_DE8DF0795D48FD4CA783C40EC82923359771SHSMSX101ccrcorpint_"
MIME-Version: 1.0
Cc: "Brown, Len" <len.brown@intel.com>,
	"jeremy.fitzhardinge@citrix.com" <jeremy.fitzhardinge@citrix.com>,
	"Jiang, Yunhong" <yunhong.jiang@intel.com>, "Shan, 
	Haitao" <haitao.shan@intel.com>,
	Kernel development list <linux-kernel@vger.kernel.org>, "Zhao,
	Yakui" <yakui.zhao@intel.com>, "Luck, Tony" <tony.luck@intel.com>, "Kleen,
	Andi" <andi.kleen@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: [Xen-devel] [PATCH 10/10] Xen: update pcpu online/offline logic
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--_002_DE8DF0795D48FD4CA783C40EC82923359771SHSMSX101ccrcorpint_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

>From 1e59d2ec2ff93b42c86d18c7cc9432ca2172a795 Mon Sep 17 00:00:00 2001
From: Liu Jinsong <jinsong.liu@intel.com>
Date: Wed, 14 Dec 2011 21:06:11 +0800
Subject: [PATCH 10/10] Xen: update pcpu online/offline logic

This patch update pcpu online/offline logic.

It closes cpu0's /sys/.../xen_pcpu0/online authority to user.
It also simplifies pcpu sync by removing redundant logic.

Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
Signed-off-by: Jiang, Yunhong <yunhong.jiang@intel.com>
---
 drivers/xen/pcpu.c |   71 ++++++++++++++----------------------------------=
----
 1 files changed, 19 insertions(+), 52 deletions(-)

diff --git a/drivers/xen/pcpu.c b/drivers/xen/pcpu.c
index 6d1a770..1d32784 100644
--- a/drivers/xen/pcpu.c
+++ b/drivers/xen/pcpu.c
@@ -24,7 +24,6 @@ static RAW_NOTIFIER_HEAD(xen_pcpu_chain);
=20
 struct xen_pcpus {
 	struct list_head list;
-	int present;
 };
 static struct xen_pcpus xen_pcpus;
=20
@@ -189,9 +188,13 @@ static int pcpu_sysdev_init(struct pcpu *cpu)
 		kfree(cpu);
 		return -1;
 	}
-	sysdev_create_file(&cpu->sysdev, &attr_online);
 	sysdev_create_file(&cpu->sysdev, &attr_apic_id);
 	sysdev_create_file(&cpu->sysdev, &attr_acpi_id);
+
+	/* Not open cpu0 online access to user */
+	if (cpu->sysdev.id)
+		sysdev_create_file(&cpu->sysdev, &attr_online);
+
 	return 0;
 }
=20
@@ -239,17 +242,10 @@ static struct pcpu *init_pcpu(struct xenpf_pcpuinfo *=
info)
 	return pcpu;
 }
=20
-#define PCPU_NO_CHANGE			0
-#define PCPU_ADDED			1
-#define PCPU_ONLINE_OFFLINE		2
-#define PCPU_REMOVED			3
 /*
  * Caller should hold the pcpu lock
- * < 0: Something wrong
- * 0: No changes
- * > 0: State changed
  */
-static struct pcpu *_sync_pcpu(int cpu_num, int *max_id, int *result)
+static int _sync_pcpu(int cpu_num, int *max_id)
 {
 	struct pcpu *pcpu =3D NULL;
 	struct xenpf_pcpuinfo *info;
@@ -259,14 +255,12 @@ static struct pcpu *_sync_pcpu(int cpu_num, int *max_=
id, int *result)
 	};
 	int ret;
=20
-	*result =3D -1;
-
 	info =3D &op.u.pcpu_info;
 	info->xen_cpuid =3D cpu_num;
=20
 	ret =3D HYPERVISOR_dom0_op(&op);
 	if (ret)
-		return NULL;
+		return -1;
=20
 	if (max_id)
 		*max_id =3D op.u.pcpu_info.max_present;
@@ -275,28 +269,24 @@ static struct pcpu *_sync_pcpu(int cpu_num, int *max_=
id, int *result)
=20
 	if (info->flags & XEN_PCPU_FLAGS_INVALID) {
 		/* The pcpu has been removed */
-		*result =3D PCPU_NO_CHANGE;
 		if (pcpu) {
 			raw_notifier_call_chain(&xen_pcpu_chain,
 			  XEN_PCPU_REMOVE,
 			  (void *)(long)pcpu->xen_id);
 			xen_pcpu_free(pcpu);
-			*result =3D PCPU_REMOVED;
 		}
-		return NULL;
+		return 0;
 	}
=20
=20
 	if (!pcpu) {
-		*result =3D PCPU_ADDED;
 		pcpu =3D init_pcpu(info);
 		if (pcpu =3D=3D NULL) {
 			printk(KERN_WARNING "Failed to init pcpu %x\n",
 			  info->xen_cpuid);
-			  *result =3D -1;
+			return -1;
 		}
 	} else {
-		*result =3D PCPU_NO_CHANGE;
 		/*
 		 * Old PCPU is replaced with a new pcpu, this means
 		 * several virq is missed, will it happen?
@@ -307,10 +297,10 @@ static struct pcpu *_sync_pcpu(int cpu_num, int *max_=
id, int *result)
 			pcpu->apic_id =3D info->apic_id;
 			pcpu->acpi_id =3D info->acpi_id;
 		}
-		if (xen_pcpu_online_check(info, pcpu))
-			*result =3D PCPU_ONLINE_OFFLINE;
+		xen_pcpu_online_check(info, pcpu);
 	}
-	return pcpu;
+
+	return 0;
 }
=20
 int xen_pcpu_index(uint32_t id, int is_acpiid)
@@ -353,50 +343,27 @@ static int xen_sync_pcpus(void)
 	/*
 	 * Boot cpu always have cpu_id 0 in xen
 	 */
-	int cpu_num =3D 0, max_id =3D 0, result =3D 0, present =3D 0;
+	int cpu_num =3D 0, max_id =3D 0, ret =3D 0;
 	struct list_head *elem, *tmp;
 	struct pcpu *pcpu;
=20
 	get_pcpu_lock();
=20
-	while ((result >=3D 0) && (cpu_num <=3D max_id)) {
-		pcpu =3D _sync_pcpu(cpu_num, &max_id, &result);
-
-		printk(KERN_DEBUG "sync cpu %x get result %x max_id %x\n",
-			cpu_num, result, max_id);
-
-		switch (result)	{
-		case PCPU_NO_CHANGE:
-			if (pcpu)
-				present++;
-			break;
-		case PCPU_ADDED:
-		case PCPU_ONLINE_OFFLINE:
-			present++;
-		case PCPU_REMOVED:
-			break;
-		default:
-			printk(KERN_WARNING "Failed to sync pcpu %x\n",
-			  cpu_num);
-			break;
-
-		}
+	while (!ret && (cpu_num <=3D max_id)) {
+		ret =3D _sync_pcpu(cpu_num, &max_id);
 		cpu_num++;
 	}
=20
-	if (result < 0) {
+	if (ret < 0) {
 		list_for_each_safe(elem, tmp, &xen_pcpus.list) {
 			pcpu =3D list_entry(elem, struct pcpu, pcpu_list);
 			xen_pcpu_free(pcpu);
 		}
-		present =3D 0;
 	}
=20
-	xen_pcpus.present =3D present;
-
 	put_pcpu_lock();
=20
-	return 0;
+	return ret;
 }
=20
 static void xen_pcpu_dpc(struct work_struct *work)
@@ -436,10 +403,10 @@ static int __init xen_pcpu_init(void)
 	}
=20
 	INIT_LIST_HEAD(&xen_pcpus.list);
-	xen_pcpus.present =3D 0;
=20
 	xen_sync_pcpus();
-	if (xen_pcpus.present > 0)
+
+	if (!list_empty(&xen_pcpus.list))
 		err =3D bind_virq_to_irqhandler(VIRQ_PCPU_STATE,
 			0, xen_pcpu_interrupt, 0, "pcpu", NULL);
 	if (err < 0)
--=20
1.6.5.6

--_002_DE8DF0795D48FD4CA783C40EC82923359771SHSMSX101ccrcorpint_
Content-Type: application/octet-stream;
	name="0010-Xen-update-pcpu-online-offline-logic.patch"
Content-Description: 0010-Xen-update-pcpu-online-offline-logic.patch
Content-Disposition: attachment;
	filename="0010-Xen-update-pcpu-online-offline-logic.patch"; size=4793;
	creation-date="Wed, 14 Dec 2011 15:20:15 GMT";
	modification-date="Wed, 14 Dec 2011 15:03:34 GMT"
Content-Transfer-Encoding: base64

RnJvbSAxZTU5ZDJlYzJmZjkzYjQyYzg2ZDE4YzdjYzk0MzJjYTIxNzJhNzk1IE1vbiBTZXAgMTcg
MDA6MDA6MDAgMjAwMQpGcm9tOiBMaXUgSmluc29uZyA8amluc29uZy5saXVAaW50ZWwuY29tPgpE
YXRlOiBXZWQsIDE0IERlYyAyMDExIDIxOjA2OjExICswODAwClN1YmplY3Q6IFtQQVRDSCAxMC8x
MF0gWGVuOiB1cGRhdGUgcGNwdSBvbmxpbmUvb2ZmbGluZSBsb2dpYwoKVGhpcyBwYXRjaCB1cGRh
dGUgcGNwdSBvbmxpbmUvb2ZmbGluZSBsb2dpYy4KCkl0IGNsb3NlcyBjcHUwJ3MgL3N5cy8uLi4v
eGVuX3BjcHUwL29ubGluZSBhdXRob3JpdHkgdG8gdXNlci4KSXQgYWxzbyBzaW1wbGlmaWVzIHBj
cHUgc3luYyBieSByZW1vdmluZyByZWR1bmRhbnQgbG9naWMuCgpTaWduZWQtb2ZmLWJ5OiBMaXUs
IEppbnNvbmcgPGppbnNvbmcubGl1QGludGVsLmNvbT4KU2lnbmVkLW9mZi1ieTogSmlhbmcsIFl1
bmhvbmcgPHl1bmhvbmcuamlhbmdAaW50ZWwuY29tPgotLS0KIGRyaXZlcnMveGVuL3BjcHUuYyB8
ICAgNzEgKysrKysrKysrKysrKystLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LQogMSBmaWxlcyBjaGFuZ2VkLCAxOSBpbnNlcnRpb25zKCspLCA1MiBkZWxldGlvbnMoLSkKCmRp
ZmYgLS1naXQgYS9kcml2ZXJzL3hlbi9wY3B1LmMgYi9kcml2ZXJzL3hlbi9wY3B1LmMKaW5kZXgg
NmQxYTc3MC4uMWQzMjc4NCAxMDA2NDQKLS0tIGEvZHJpdmVycy94ZW4vcGNwdS5jCisrKyBiL2Ry
aXZlcnMveGVuL3BjcHUuYwpAQCAtMjQsNyArMjQsNiBAQCBzdGF0aWMgUkFXX05PVElGSUVSX0hF
QUQoeGVuX3BjcHVfY2hhaW4pOwogCiBzdHJ1Y3QgeGVuX3BjcHVzIHsKIAlzdHJ1Y3QgbGlzdF9o
ZWFkIGxpc3Q7Ci0JaW50IHByZXNlbnQ7CiB9Owogc3RhdGljIHN0cnVjdCB4ZW5fcGNwdXMgeGVu
X3BjcHVzOwogCkBAIC0xODksOSArMTg4LDEzIEBAIHN0YXRpYyBpbnQgcGNwdV9zeXNkZXZfaW5p
dChzdHJ1Y3QgcGNwdSAqY3B1KQogCQlrZnJlZShjcHUpOwogCQlyZXR1cm4gLTE7CiAJfQotCXN5
c2Rldl9jcmVhdGVfZmlsZSgmY3B1LT5zeXNkZXYsICZhdHRyX29ubGluZSk7CiAJc3lzZGV2X2Ny
ZWF0ZV9maWxlKCZjcHUtPnN5c2RldiwgJmF0dHJfYXBpY19pZCk7CiAJc3lzZGV2X2NyZWF0ZV9m
aWxlKCZjcHUtPnN5c2RldiwgJmF0dHJfYWNwaV9pZCk7CisKKwkvKiBOb3Qgb3BlbiBjcHUwIG9u
bGluZSBhY2Nlc3MgdG8gdXNlciAqLworCWlmIChjcHUtPnN5c2Rldi5pZCkKKwkJc3lzZGV2X2Ny
ZWF0ZV9maWxlKCZjcHUtPnN5c2RldiwgJmF0dHJfb25saW5lKTsKKwogCXJldHVybiAwOwogfQog
CkBAIC0yMzksMTcgKzI0MiwxMCBAQCBzdGF0aWMgc3RydWN0IHBjcHUgKmluaXRfcGNwdShzdHJ1
Y3QgeGVucGZfcGNwdWluZm8gKmluZm8pCiAJcmV0dXJuIHBjcHU7CiB9CiAKLSNkZWZpbmUgUENQ
VV9OT19DSEFOR0UJCQkwCi0jZGVmaW5lIFBDUFVfQURERUQJCQkxCi0jZGVmaW5lIFBDUFVfT05M
SU5FX09GRkxJTkUJCTIKLSNkZWZpbmUgUENQVV9SRU1PVkVECQkJMwogLyoKICAqIENhbGxlciBz
aG91bGQgaG9sZCB0aGUgcGNwdSBsb2NrCi0gKiA8IDA6IFNvbWV0aGluZyB3cm9uZwotICogMDog
Tm8gY2hhbmdlcwotICogPiAwOiBTdGF0ZSBjaGFuZ2VkCiAgKi8KLXN0YXRpYyBzdHJ1Y3QgcGNw
dSAqX3N5bmNfcGNwdShpbnQgY3B1X251bSwgaW50ICptYXhfaWQsIGludCAqcmVzdWx0KQorc3Rh
dGljIGludCBfc3luY19wY3B1KGludCBjcHVfbnVtLCBpbnQgKm1heF9pZCkKIHsKIAlzdHJ1Y3Qg
cGNwdSAqcGNwdSA9IE5VTEw7CiAJc3RydWN0IHhlbnBmX3BjcHVpbmZvICppbmZvOwpAQCAtMjU5
LDE0ICsyNTUsMTIgQEAgc3RhdGljIHN0cnVjdCBwY3B1ICpfc3luY19wY3B1KGludCBjcHVfbnVt
LCBpbnQgKm1heF9pZCwgaW50ICpyZXN1bHQpCiAJfTsKIAlpbnQgcmV0OwogCi0JKnJlc3VsdCA9
IC0xOwotCiAJaW5mbyA9ICZvcC51LnBjcHVfaW5mbzsKIAlpbmZvLT54ZW5fY3B1aWQgPSBjcHVf
bnVtOwogCiAJcmV0ID0gSFlQRVJWSVNPUl9kb20wX29wKCZvcCk7CiAJaWYgKHJldCkKLQkJcmV0
dXJuIE5VTEw7CisJCXJldHVybiAtMTsKIAogCWlmIChtYXhfaWQpCiAJCSptYXhfaWQgPSBvcC51
LnBjcHVfaW5mby5tYXhfcHJlc2VudDsKQEAgLTI3NSwyOCArMjY5LDI0IEBAIHN0YXRpYyBzdHJ1
Y3QgcGNwdSAqX3N5bmNfcGNwdShpbnQgY3B1X251bSwgaW50ICptYXhfaWQsIGludCAqcmVzdWx0
KQogCiAJaWYgKGluZm8tPmZsYWdzICYgWEVOX1BDUFVfRkxBR1NfSU5WQUxJRCkgewogCQkvKiBU
aGUgcGNwdSBoYXMgYmVlbiByZW1vdmVkICovCi0JCSpyZXN1bHQgPSBQQ1BVX05PX0NIQU5HRTsK
IAkJaWYgKHBjcHUpIHsKIAkJCXJhd19ub3RpZmllcl9jYWxsX2NoYWluKCZ4ZW5fcGNwdV9jaGFp
biwKIAkJCSAgWEVOX1BDUFVfUkVNT1ZFLAogCQkJICAodm9pZCAqKShsb25nKXBjcHUtPnhlbl9p
ZCk7CiAJCQl4ZW5fcGNwdV9mcmVlKHBjcHUpOwotCQkJKnJlc3VsdCA9IFBDUFVfUkVNT1ZFRDsK
IAkJfQotCQlyZXR1cm4gTlVMTDsKKwkJcmV0dXJuIDA7CiAJfQogCiAKIAlpZiAoIXBjcHUpIHsK
LQkJKnJlc3VsdCA9IFBDUFVfQURERUQ7CiAJCXBjcHUgPSBpbml0X3BjcHUoaW5mbyk7CiAJCWlm
IChwY3B1ID09IE5VTEwpIHsKIAkJCXByaW50ayhLRVJOX1dBUk5JTkcgIkZhaWxlZCB0byBpbml0
IHBjcHUgJXhcbiIsCiAJCQkgIGluZm8tPnhlbl9jcHVpZCk7Ci0JCQkgICpyZXN1bHQgPSAtMTsK
KwkJCXJldHVybiAtMTsKIAkJfQogCX0gZWxzZSB7Ci0JCSpyZXN1bHQgPSBQQ1BVX05PX0NIQU5H
RTsKIAkJLyoKIAkJICogT2xkIFBDUFUgaXMgcmVwbGFjZWQgd2l0aCBhIG5ldyBwY3B1LCB0aGlz
IG1lYW5zCiAJCSAqIHNldmVyYWwgdmlycSBpcyBtaXNzZWQsIHdpbGwgaXQgaGFwcGVuPwpAQCAt
MzA3LDEwICsyOTcsMTAgQEAgc3RhdGljIHN0cnVjdCBwY3B1ICpfc3luY19wY3B1KGludCBjcHVf
bnVtLCBpbnQgKm1heF9pZCwgaW50ICpyZXN1bHQpCiAJCQlwY3B1LT5hcGljX2lkID0gaW5mby0+
YXBpY19pZDsKIAkJCXBjcHUtPmFjcGlfaWQgPSBpbmZvLT5hY3BpX2lkOwogCQl9Ci0JCWlmICh4
ZW5fcGNwdV9vbmxpbmVfY2hlY2soaW5mbywgcGNwdSkpCi0JCQkqcmVzdWx0ID0gUENQVV9PTkxJ
TkVfT0ZGTElORTsKKwkJeGVuX3BjcHVfb25saW5lX2NoZWNrKGluZm8sIHBjcHUpOwogCX0KLQly
ZXR1cm4gcGNwdTsKKworCXJldHVybiAwOwogfQogCiBpbnQgeGVuX3BjcHVfaW5kZXgodWludDMy
X3QgaWQsIGludCBpc19hY3BpaWQpCkBAIC0zNTMsNTAgKzM0MywyNyBAQCBzdGF0aWMgaW50IHhl
bl9zeW5jX3BjcHVzKHZvaWQpCiAJLyoKIAkgKiBCb290IGNwdSBhbHdheXMgaGF2ZSBjcHVfaWQg
MCBpbiB4ZW4KIAkgKi8KLQlpbnQgY3B1X251bSA9IDAsIG1heF9pZCA9IDAsIHJlc3VsdCA9IDAs
IHByZXNlbnQgPSAwOworCWludCBjcHVfbnVtID0gMCwgbWF4X2lkID0gMCwgcmV0ID0gMDsKIAlz
dHJ1Y3QgbGlzdF9oZWFkICplbGVtLCAqdG1wOwogCXN0cnVjdCBwY3B1ICpwY3B1OwogCiAJZ2V0
X3BjcHVfbG9jaygpOwogCi0Jd2hpbGUgKChyZXN1bHQgPj0gMCkgJiYgKGNwdV9udW0gPD0gbWF4
X2lkKSkgewotCQlwY3B1ID0gX3N5bmNfcGNwdShjcHVfbnVtLCAmbWF4X2lkLCAmcmVzdWx0KTsK
LQotCQlwcmludGsoS0VSTl9ERUJVRyAic3luYyBjcHUgJXggZ2V0IHJlc3VsdCAleCBtYXhfaWQg
JXhcbiIsCi0JCQljcHVfbnVtLCByZXN1bHQsIG1heF9pZCk7Ci0KLQkJc3dpdGNoIChyZXN1bHQp
CXsKLQkJY2FzZSBQQ1BVX05PX0NIQU5HRToKLQkJCWlmIChwY3B1KQotCQkJCXByZXNlbnQrKzsK
LQkJCWJyZWFrOwotCQljYXNlIFBDUFVfQURERUQ6Ci0JCWNhc2UgUENQVV9PTkxJTkVfT0ZGTElO
RToKLQkJCXByZXNlbnQrKzsKLQkJY2FzZSBQQ1BVX1JFTU9WRUQ6Ci0JCQlicmVhazsKLQkJZGVm
YXVsdDoKLQkJCXByaW50ayhLRVJOX1dBUk5JTkcgIkZhaWxlZCB0byBzeW5jIHBjcHUgJXhcbiIs
Ci0JCQkgIGNwdV9udW0pOwotCQkJYnJlYWs7Ci0KLQkJfQorCXdoaWxlICghcmV0ICYmIChjcHVf
bnVtIDw9IG1heF9pZCkpIHsKKwkJcmV0ID0gX3N5bmNfcGNwdShjcHVfbnVtLCAmbWF4X2lkKTsK
IAkJY3B1X251bSsrOwogCX0KIAotCWlmIChyZXN1bHQgPCAwKSB7CisJaWYgKHJldCA8IDApIHsK
IAkJbGlzdF9mb3JfZWFjaF9zYWZlKGVsZW0sIHRtcCwgJnhlbl9wY3B1cy5saXN0KSB7CiAJCQlw
Y3B1ID0gbGlzdF9lbnRyeShlbGVtLCBzdHJ1Y3QgcGNwdSwgcGNwdV9saXN0KTsKIAkJCXhlbl9w
Y3B1X2ZyZWUocGNwdSk7CiAJCX0KLQkJcHJlc2VudCA9IDA7CiAJfQogCi0JeGVuX3BjcHVzLnBy
ZXNlbnQgPSBwcmVzZW50OwotCiAJcHV0X3BjcHVfbG9jaygpOwogCi0JcmV0dXJuIDA7CisJcmV0
dXJuIHJldDsKIH0KIAogc3RhdGljIHZvaWQgeGVuX3BjcHVfZHBjKHN0cnVjdCB3b3JrX3N0cnVj
dCAqd29yaykKQEAgLTQzNiwxMCArNDAzLDEwIEBAIHN0YXRpYyBpbnQgX19pbml0IHhlbl9wY3B1
X2luaXQodm9pZCkKIAl9CiAKIAlJTklUX0xJU1RfSEVBRCgmeGVuX3BjcHVzLmxpc3QpOwotCXhl
bl9wY3B1cy5wcmVzZW50ID0gMDsKIAogCXhlbl9zeW5jX3BjcHVzKCk7Ci0JaWYgKHhlbl9wY3B1
cy5wcmVzZW50ID4gMCkKKworCWlmICghbGlzdF9lbXB0eSgmeGVuX3BjcHVzLmxpc3QpKQogCQll
cnIgPSBiaW5kX3ZpcnFfdG9faXJxaGFuZGxlcihWSVJRX1BDUFVfU1RBVEUsCiAJCQkwLCB4ZW5f
cGNwdV9pbnRlcnJ1cHQsIDAsICJwY3B1IiwgTlVMTCk7CiAJaWYgKGVyciA8IDApCi0tIAoxLjYu
NS42Cgo=

--_002_DE8DF0795D48FD4CA783C40EC82923359771SHSMSX101ccrcorpint_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--_002_DE8DF0795D48FD4CA783C40EC82923359771SHSMSX101ccrcorpint_--


From xen-devel-bounces@lists.xensource.com Fri Dec 23 10:35:43 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 Dec 2011 10:35:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Re2TL-0007c7-8T; Fri, 23 Dec 2011 10:35:31 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1Re2TJ-0007bb-Ls
	for xen-devel@lists.xensource.com; Fri, 23 Dec 2011 10:35:30 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1324636521!9181152!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDMwMDk1NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6691 invoked from network); 23 Dec 2011 10:35:22 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-6.tower-21.messagelabs.com with SMTP;
	23 Dec 2011 10:35:22 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga102.fm.intel.com with ESMTP; 23 Dec 2011 02:35:21 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208,223";a="99640591"
Received: from pgsmsx601.gar.corp.intel.com ([10.221.43.69])
	by fmsmga001.fm.intel.com with ESMTP; 23 Dec 2011 02:35:20 -0800
Received: from pgsmsx103.gar.corp.intel.com (10.221.44.82) by
	pgsmsx601.gar.corp.intel.com (10.221.43.69) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Fri, 23 Dec 2011 18:35:13 +0800
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	PGSMSX103.gar.corp.intel.com (10.221.44.82) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Fri, 23 Dec 2011 18:35:13 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.38]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.223]) with mapi id
	14.01.0355.002; Fri, 23 Dec 2011 18:35:12 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: "konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
Thread-Topic: [PATCH 04/10] Xen: Add pcpu hotadd support to pvops dom0.
Thread-Index: AczBXovu0ls0uF11RuS8UuGQwN8UbA==
Date: Fri, 23 Dec 2011 10:35:10 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC8292335979F@SHSMSX101.ccr.corp.intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
Content-Type: multipart/mixed;
	boundary="_002_DE8DF0795D48FD4CA783C40EC8292335979FSHSMSX101ccrcorpint_"
MIME-Version: 1.0
Cc: "Brown, Len" <len.brown@intel.com>,
	"jeremy.fitzhardinge@citrix.com" <jeremy.fitzhardinge@citrix.com>,
	"Jiang, Yunhong" <yunhong.jiang@intel.com>, "Shan, 
	Haitao" <haitao.shan@intel.com>,
	Kernel development list <linux-kernel@vger.kernel.org>, "Zhao,
	Yakui" <yakui.zhao@intel.com>, "Luck, Tony" <tony.luck@intel.com>, "Kleen,
	Andi" <andi.kleen@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: [Xen-devel] [PATCH 04/10] Xen: Add pcpu hotadd support to pvops
	dom0.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--_002_DE8DF0795D48FD4CA783C40EC8292335979FSHSMSX101ccrcorpint_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

>From 5f5eb7bf950836edb4910173d3be2f26ad737093 Mon Sep 17 00:00:00 2001
From: Liu Jinsong <jinsong.liu@intel.com>
Date: Sun, 11 Dec 2011 15:42:03 +0800
Subject: [PATCH 04/10] Xen: Add pcpu hotadd support to pvops dom0.

This patch rebased from Jeremy's pvops commit
3129884bc75d7e6578be7499ac04a06d9fc5b31d

This patch implement CPU hotplug callback in xen acpi_processor. User
can later bring the pcpu online through sysfs interface.

xen_get_apic_id() is mostly duplicated with the get_cpu_id() in
driver/acpi/processor_core.c, but it should be ok since it has been
duplicated in arch directory already by upstream kernel.

One thing left is, currently the acpi_processor's id is quite
confusing (it is in fact with vcpu's dom0 cpu_id). Will update it with
xen's cpuid through the pcpu interface. But to achieve it, we need
investigate more on the pr->id, and also we need change the pcpu logic
to use spin_lock, instead of mutex for the pcpu list. That will be
next step.

Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
Signed-off-by: Jiang, Yunhong <yunhong.jiang@intel.com>
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
---
 drivers/xen/acpi_processor.c     |  114 ++++++++++++++++++++++++++++++++++=
+++-
 include/xen/interface/platform.h |   10 +++-
 2 files changed, 122 insertions(+), 2 deletions(-)

diff --git a/drivers/xen/acpi_processor.c b/drivers/xen/acpi_processor.c
index 327a56e..acab49b 100644
--- a/drivers/xen/acpi_processor.c
+++ b/drivers/xen/acpi_processor.c
@@ -22,12 +22,19 @@
 #include <linux/cpufreq.h>
 #include <acpi/processor.h>
 #include <xen/acpi.h>
+#include <xen/pcpu.h>
=20
 #include <xen/interface/platform.h>
 #include <asm/xen/hypercall.h>
 #include <asm/xen/hypervisor.h>
=20
-static struct processor_cntl_xen_ops xen_ops;
+static int xen_get_apic_id(acpi_handle handle);
+static int xen_cpu_hotplug_notifier(struct acpi_processor *pr, int event);
+
+static struct processor_cntl_xen_ops xen_ops =3D {
+	.hotplug =3D xen_cpu_hotplug_notifier,
+};
+
 int processor_cntl_xen_notify(struct acpi_processor *pr, int event, int ty=
pe)
 {
 	int ret =3D -EINVAL;
@@ -41,6 +48,18 @@ int processor_cntl_xen_notify(struct acpi_processor *pr,=
 int event, int type)
=20
 		ret =3D xen_ops.pm_ops[type](pr, event);
 		break;
+	case PROCESSOR_HOTPLUG:
+	{
+		int apic_id;
+
+		apic_id =3D xen_get_apic_id(pr->handle);
+		if (apic_id < 0)
+			break;
+		if (xen_ops.hotplug)
+			ret =3D xen_ops.hotplug(pr, type);
+		xen_pcpu_hotplug(type, apic_id);
+		break;
+	}
 	default:
 		printk(KERN_ERR "Unsupport processor events %d.\n", event);
 		break;
@@ -50,6 +69,49 @@ int processor_cntl_xen_notify(struct acpi_processor *pr,=
 int event, int type)
 }
 EXPORT_SYMBOL(processor_cntl_xen_notify);
=20
+#ifdef CONFIG_ACPI_HOTPLUG_CPU
+static int xen_get_apic_id(acpi_handle handle)
+{
+	struct acpi_buffer buffer =3D { ACPI_ALLOCATE_BUFFER, NULL };
+	union acpi_object *obj;
+	struct acpi_madt_local_apic *lapic;
+	u8 physid;
+
+	if (ACPI_FAILURE(acpi_evaluate_object(handle, "_MAT", NULL, &buffer)))
+		return -EINVAL;
+
+	if (!buffer.length || !buffer.pointer)
+		return -EINVAL;
+
+	obj =3D buffer.pointer;
+	if (obj->type !=3D ACPI_TYPE_BUFFER ||
+	    obj->buffer.length < sizeof(*lapic)) {
+		kfree(buffer.pointer);
+		return -EINVAL;
+	}
+
+	lapic =3D (struct acpi_madt_local_apic *)obj->buffer.pointer;
+
+	if (lapic->header.type !=3D ACPI_MADT_TYPE_LOCAL_APIC ||
+	    !(lapic->lapic_flags & ACPI_MADT_ENABLED)) {
+		kfree(buffer.pointer);
+		return -EINVAL;
+	}
+
+	physid =3D lapic->id;
+	kfree(buffer.pointer);
+	buffer.length =3D ACPI_ALLOCATE_BUFFER;
+	buffer.pointer =3D NULL;
+
+	return physid;
+}
+#else
+static int xen_get_apic_id(acpi_handle handle)
+{
+	return -1;
+}
+#endif
+
 static inline void xen_convert_pct_reg(struct xen_pct_register *xpct,
 	struct acpi_pct_register *apct)
 {
@@ -246,6 +308,56 @@ static int xen_px_notifier(struct acpi_processor *pr, =
int action)
 	return ret;
 }
=20
+#ifdef CONFIG_ACPI_HOTPLUG_CPU
+static int xen_cpu_hotplug_notifier(struct acpi_processor *pr, int event)
+{
+	int ret =3D -EINVAL;
+	uint32_t apic_id;
+	unsigned long long pxm;
+	acpi_status status =3D 0;
+
+	xen_platform_op_t op =3D {
+		.interface_version  =3D XENPF_INTERFACE_VERSION,
+	};
+
+	apic_id =3D xen_get_apic_id(pr->handle);
+	if (apic_id < 0) {
+		printk(KERN_WARNING "Can't get apic_id for acpi_id %x\n",
+		  pr->acpi_id);
+		return -1;
+	}
+
+	status =3D acpi_evaluate_integer(pr->handle, "_PXM",
+	  NULL, &pxm);
+	if (ACPI_FAILURE(status)) {
+		printk(KERN_WARNING "can't get pxm for acpi_id %x\n",
+		  pr->acpi_id);
+		return -1;
+	}
+
+	switch (event) {
+	case HOTPLUG_TYPE_ADD:
+		op.cmd =3D XENPF_cpu_hotadd;
+		op.u.cpu_add.apic_id =3D apic_id;
+		op.u.cpu_add.acpi_id =3D pr->acpi_id;
+		op.u.cpu_add.pxm =3D pxm;
+		ret =3D HYPERVISOR_dom0_op(&op);
+		break;
+	case HOTPLUG_TYPE_REMOVE:
+		printk(KERN_WARNING "Xen not support CPU hotremove\n");
+		ret =3D -ENOSYS;
+		break;
+	}
+
+	return ret;
+}
+#else
+static int xen_cpu_hotplug_notifier(struct acpi_processor *pr, int event)
+{
+	return -ENOSYS;
+}
+#endif
+
 static int __init xen_acpi_processor_extcntl_init(void)
 {
 	unsigned int pmbits;
diff --git a/include/xen/interface/platform.h b/include/xen/interface/platf=
orm.h
index 47ffe16..9fd6b07 100644
--- a/include/xen/interface/platform.h
+++ b/include/xen/interface/platform.h
@@ -317,11 +317,18 @@ DEFINE_GUEST_HANDLE_STRUCT(xenpf_pcpuinfo_t);
 #define XENPF_cpu_online    56
 #define XENPF_cpu_offline   57
 struct xenpf_cpu_ol {
-    uint32_t cpuid;
+	uint32_t cpuid;
 };
 typedef struct xenpf_cpu_ol xenpf_cpu_ol_t;
 DEFINE_GUEST_HANDLE_STRUCT(xenpf_cpu_ol_t);
=20
+#define XENPF_cpu_hotadd    58
+struct xenpf_cpu_hotadd {
+	uint32_t apic_id;
+	uint32_t acpi_id;
+	uint32_t pxm;
+};
+
 struct xen_platform_op {
 	uint32_t cmd;
 	uint32_t interface_version; /* XENPF_INTERFACE_VERSION */
@@ -339,6 +346,7 @@ struct xen_platform_op {
 		struct xenpf_set_processor_pminfo set_pminfo;
 		struct xenpf_pcpuinfo          pcpu_info;
 		struct xenpf_cpu_ol            cpu_ol;
+		struct xenpf_cpu_hotadd        cpu_add;
 		uint8_t                        pad[128];
 	} u;
 };
--=20
1.6.5.6

--_002_DE8DF0795D48FD4CA783C40EC8292335979FSHSMSX101ccrcorpint_
Content-Type: application/octet-stream;
	name="0004-Xen-Add-pcpu-hotadd-support-to-pvops-dom0.patch"
Content-Description: 0004-Xen-Add-pcpu-hotadd-support-to-pvops-dom0.patch
Content-Disposition: attachment;
	filename="0004-Xen-Add-pcpu-hotadd-support-to-pvops-dom0.patch"; size=6111;
	creation-date="Wed, 14 Dec 2011 15:20:15 GMT";
	modification-date="Wed, 14 Dec 2011 15:03:34 GMT"
Content-Transfer-Encoding: base64

RnJvbSA1ZjVlYjdiZjk1MDgzNmVkYjQ5MTAxNzNkM2JlMmYyNmFkNzM3MDkzIE1vbiBTZXAgMTcg
MDA6MDA6MDAgMjAwMQpGcm9tOiBMaXUgSmluc29uZyA8amluc29uZy5saXVAaW50ZWwuY29tPgpE
YXRlOiBTdW4sIDExIERlYyAyMDExIDE1OjQyOjAzICswODAwClN1YmplY3Q6IFtQQVRDSCAwNC8x
MF0gWGVuOiBBZGQgcGNwdSBob3RhZGQgc3VwcG9ydCB0byBwdm9wcyBkb20wLgoKVGhpcyBwYXRj
aCByZWJhc2VkIGZyb20gSmVyZW15J3MgcHZvcHMgY29tbWl0CjMxMjk4ODRiYzc1ZDdlNjU3OGJl
NzQ5OWFjMDRhMDZkOWZjNWIzMWQKClRoaXMgcGF0Y2ggaW1wbGVtZW50IENQVSBob3RwbHVnIGNh
bGxiYWNrIGluIHhlbiBhY3BpX3Byb2Nlc3Nvci4gVXNlcgpjYW4gbGF0ZXIgYnJpbmcgdGhlIHBj
cHUgb25saW5lIHRocm91Z2ggc3lzZnMgaW50ZXJmYWNlLgoKeGVuX2dldF9hcGljX2lkKCkgaXMg
bW9zdGx5IGR1cGxpY2F0ZWQgd2l0aCB0aGUgZ2V0X2NwdV9pZCgpIGluCmRyaXZlci9hY3BpL3By
b2Nlc3Nvcl9jb3JlLmMsIGJ1dCBpdCBzaG91bGQgYmUgb2sgc2luY2UgaXQgaGFzIGJlZW4KZHVw
bGljYXRlZCBpbiBhcmNoIGRpcmVjdG9yeSBhbHJlYWR5IGJ5IHVwc3RyZWFtIGtlcm5lbC4KCk9u
ZSB0aGluZyBsZWZ0IGlzLCBjdXJyZW50bHkgdGhlIGFjcGlfcHJvY2Vzc29yJ3MgaWQgaXMgcXVp
dGUKY29uZnVzaW5nIChpdCBpcyBpbiBmYWN0IHdpdGggdmNwdSdzIGRvbTAgY3B1X2lkKS4gV2ls
bCB1cGRhdGUgaXQgd2l0aAp4ZW4ncyBjcHVpZCB0aHJvdWdoIHRoZSBwY3B1IGludGVyZmFjZS4g
QnV0IHRvIGFjaGlldmUgaXQsIHdlIG5lZWQKaW52ZXN0aWdhdGUgbW9yZSBvbiB0aGUgcHItPmlk
LCBhbmQgYWxzbyB3ZSBuZWVkIGNoYW5nZSB0aGUgcGNwdSBsb2dpYwp0byB1c2Ugc3Bpbl9sb2Nr
LCBpbnN0ZWFkIG9mIG11dGV4IGZvciB0aGUgcGNwdSBsaXN0LiBUaGF0IHdpbGwgYmUKbmV4dCBz
dGVwLgoKU2lnbmVkLW9mZi1ieTogTGl1LCBKaW5zb25nIDxqaW5zb25nLmxpdUBpbnRlbC5jb20+
ClNpZ25lZC1vZmYtYnk6IEppYW5nLCBZdW5ob25nIDx5dW5ob25nLmppYW5nQGludGVsLmNvbT4K
U2lnbmVkLW9mZi1ieTogSmVyZW15IEZpdHpoYXJkaW5nZSA8amVyZW15LmZpdHpoYXJkaW5nZUBj
aXRyaXguY29tPgotLS0KIGRyaXZlcnMveGVuL2FjcGlfcHJvY2Vzc29yLmMgICAgIHwgIDExNCAr
KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrLQogaW5jbHVkZS94ZW4vaW50ZXJm
YWNlL3BsYXRmb3JtLmggfCAgIDEwICsrKy0KIDIgZmlsZXMgY2hhbmdlZCwgMTIyIGluc2VydGlv
bnMoKyksIDIgZGVsZXRpb25zKC0pCgpkaWZmIC0tZ2l0IGEvZHJpdmVycy94ZW4vYWNwaV9wcm9j
ZXNzb3IuYyBiL2RyaXZlcnMveGVuL2FjcGlfcHJvY2Vzc29yLmMKaW5kZXggMzI3YTU2ZS4uYWNh
YjQ5YiAxMDA2NDQKLS0tIGEvZHJpdmVycy94ZW4vYWNwaV9wcm9jZXNzb3IuYworKysgYi9kcml2
ZXJzL3hlbi9hY3BpX3Byb2Nlc3Nvci5jCkBAIC0yMiwxMiArMjIsMTkgQEAKICNpbmNsdWRlIDxs
aW51eC9jcHVmcmVxLmg+CiAjaW5jbHVkZSA8YWNwaS9wcm9jZXNzb3IuaD4KICNpbmNsdWRlIDx4
ZW4vYWNwaS5oPgorI2luY2x1ZGUgPHhlbi9wY3B1Lmg+CiAKICNpbmNsdWRlIDx4ZW4vaW50ZXJm
YWNlL3BsYXRmb3JtLmg+CiAjaW5jbHVkZSA8YXNtL3hlbi9oeXBlcmNhbGwuaD4KICNpbmNsdWRl
IDxhc20veGVuL2h5cGVydmlzb3IuaD4KIAotc3RhdGljIHN0cnVjdCBwcm9jZXNzb3JfY250bF94
ZW5fb3BzIHhlbl9vcHM7CitzdGF0aWMgaW50IHhlbl9nZXRfYXBpY19pZChhY3BpX2hhbmRsZSBo
YW5kbGUpOworc3RhdGljIGludCB4ZW5fY3B1X2hvdHBsdWdfbm90aWZpZXIoc3RydWN0IGFjcGlf
cHJvY2Vzc29yICpwciwgaW50IGV2ZW50KTsKKworc3RhdGljIHN0cnVjdCBwcm9jZXNzb3JfY250
bF94ZW5fb3BzIHhlbl9vcHMgPSB7CisJLmhvdHBsdWcgPSB4ZW5fY3B1X2hvdHBsdWdfbm90aWZp
ZXIsCit9OworCiBpbnQgcHJvY2Vzc29yX2NudGxfeGVuX25vdGlmeShzdHJ1Y3QgYWNwaV9wcm9j
ZXNzb3IgKnByLCBpbnQgZXZlbnQsIGludCB0eXBlKQogewogCWludCByZXQgPSAtRUlOVkFMOwpA
QCAtNDEsNiArNDgsMTggQEAgaW50IHByb2Nlc3Nvcl9jbnRsX3hlbl9ub3RpZnkoc3RydWN0IGFj
cGlfcHJvY2Vzc29yICpwciwgaW50IGV2ZW50LCBpbnQgdHlwZSkKIAogCQlyZXQgPSB4ZW5fb3Bz
LnBtX29wc1t0eXBlXShwciwgZXZlbnQpOwogCQlicmVhazsKKwljYXNlIFBST0NFU1NPUl9IT1RQ
TFVHOgorCXsKKwkJaW50IGFwaWNfaWQ7CisKKwkJYXBpY19pZCA9IHhlbl9nZXRfYXBpY19pZChw
ci0+aGFuZGxlKTsKKwkJaWYgKGFwaWNfaWQgPCAwKQorCQkJYnJlYWs7CisJCWlmICh4ZW5fb3Bz
LmhvdHBsdWcpCisJCQlyZXQgPSB4ZW5fb3BzLmhvdHBsdWcocHIsIHR5cGUpOworCQl4ZW5fcGNw
dV9ob3RwbHVnKHR5cGUsIGFwaWNfaWQpOworCQlicmVhazsKKwl9CiAJZGVmYXVsdDoKIAkJcHJp
bnRrKEtFUk5fRVJSICJVbnN1cHBvcnQgcHJvY2Vzc29yIGV2ZW50cyAlZC5cbiIsIGV2ZW50KTsK
IAkJYnJlYWs7CkBAIC01MCw2ICs2OSw0OSBAQCBpbnQgcHJvY2Vzc29yX2NudGxfeGVuX25vdGlm
eShzdHJ1Y3QgYWNwaV9wcm9jZXNzb3IgKnByLCBpbnQgZXZlbnQsIGludCB0eXBlKQogfQogRVhQ
T1JUX1NZTUJPTChwcm9jZXNzb3JfY250bF94ZW5fbm90aWZ5KTsKIAorI2lmZGVmIENPTkZJR19B
Q1BJX0hPVFBMVUdfQ1BVCitzdGF0aWMgaW50IHhlbl9nZXRfYXBpY19pZChhY3BpX2hhbmRsZSBo
YW5kbGUpCit7CisJc3RydWN0IGFjcGlfYnVmZmVyIGJ1ZmZlciA9IHsgQUNQSV9BTExPQ0FURV9C
VUZGRVIsIE5VTEwgfTsKKwl1bmlvbiBhY3BpX29iamVjdCAqb2JqOworCXN0cnVjdCBhY3BpX21h
ZHRfbG9jYWxfYXBpYyAqbGFwaWM7CisJdTggcGh5c2lkOworCisJaWYgKEFDUElfRkFJTFVSRShh
Y3BpX2V2YWx1YXRlX29iamVjdChoYW5kbGUsICJfTUFUIiwgTlVMTCwgJmJ1ZmZlcikpKQorCQly
ZXR1cm4gLUVJTlZBTDsKKworCWlmICghYnVmZmVyLmxlbmd0aCB8fCAhYnVmZmVyLnBvaW50ZXIp
CisJCXJldHVybiAtRUlOVkFMOworCisJb2JqID0gYnVmZmVyLnBvaW50ZXI7CisJaWYgKG9iai0+
dHlwZSAhPSBBQ1BJX1RZUEVfQlVGRkVSIHx8CisJICAgIG9iai0+YnVmZmVyLmxlbmd0aCA8IHNp
emVvZigqbGFwaWMpKSB7CisJCWtmcmVlKGJ1ZmZlci5wb2ludGVyKTsKKwkJcmV0dXJuIC1FSU5W
QUw7CisJfQorCisJbGFwaWMgPSAoc3RydWN0IGFjcGlfbWFkdF9sb2NhbF9hcGljICopb2JqLT5i
dWZmZXIucG9pbnRlcjsKKworCWlmIChsYXBpYy0+aGVhZGVyLnR5cGUgIT0gQUNQSV9NQURUX1RZ
UEVfTE9DQUxfQVBJQyB8fAorCSAgICAhKGxhcGljLT5sYXBpY19mbGFncyAmIEFDUElfTUFEVF9F
TkFCTEVEKSkgeworCQlrZnJlZShidWZmZXIucG9pbnRlcik7CisJCXJldHVybiAtRUlOVkFMOwor
CX0KKworCXBoeXNpZCA9IGxhcGljLT5pZDsKKwlrZnJlZShidWZmZXIucG9pbnRlcik7CisJYnVm
ZmVyLmxlbmd0aCA9IEFDUElfQUxMT0NBVEVfQlVGRkVSOworCWJ1ZmZlci5wb2ludGVyID0gTlVM
TDsKKworCXJldHVybiBwaHlzaWQ7Cit9CisjZWxzZQorc3RhdGljIGludCB4ZW5fZ2V0X2FwaWNf
aWQoYWNwaV9oYW5kbGUgaGFuZGxlKQoreworCXJldHVybiAtMTsKK30KKyNlbmRpZgorCiBzdGF0
aWMgaW5saW5lIHZvaWQgeGVuX2NvbnZlcnRfcGN0X3JlZyhzdHJ1Y3QgeGVuX3BjdF9yZWdpc3Rl
ciAqeHBjdCwKIAlzdHJ1Y3QgYWNwaV9wY3RfcmVnaXN0ZXIgKmFwY3QpCiB7CkBAIC0yNDYsNiAr
MzA4LDU2IEBAIHN0YXRpYyBpbnQgeGVuX3B4X25vdGlmaWVyKHN0cnVjdCBhY3BpX3Byb2Nlc3Nv
ciAqcHIsIGludCBhY3Rpb24pCiAJcmV0dXJuIHJldDsKIH0KIAorI2lmZGVmIENPTkZJR19BQ1BJ
X0hPVFBMVUdfQ1BVCitzdGF0aWMgaW50IHhlbl9jcHVfaG90cGx1Z19ub3RpZmllcihzdHJ1Y3Qg
YWNwaV9wcm9jZXNzb3IgKnByLCBpbnQgZXZlbnQpCit7CisJaW50IHJldCA9IC1FSU5WQUw7CisJ
dWludDMyX3QgYXBpY19pZDsKKwl1bnNpZ25lZCBsb25nIGxvbmcgcHhtOworCWFjcGlfc3RhdHVz
IHN0YXR1cyA9IDA7CisKKwl4ZW5fcGxhdGZvcm1fb3BfdCBvcCA9IHsKKwkJLmludGVyZmFjZV92
ZXJzaW9uICA9IFhFTlBGX0lOVEVSRkFDRV9WRVJTSU9OLAorCX07CisKKwlhcGljX2lkID0geGVu
X2dldF9hcGljX2lkKHByLT5oYW5kbGUpOworCWlmIChhcGljX2lkIDwgMCkgeworCQlwcmludGso
S0VSTl9XQVJOSU5HICJDYW4ndCBnZXQgYXBpY19pZCBmb3IgYWNwaV9pZCAleFxuIiwKKwkJICBw
ci0+YWNwaV9pZCk7CisJCXJldHVybiAtMTsKKwl9CisKKwlzdGF0dXMgPSBhY3BpX2V2YWx1YXRl
X2ludGVnZXIocHItPmhhbmRsZSwgIl9QWE0iLAorCSAgTlVMTCwgJnB4bSk7CisJaWYgKEFDUElf
RkFJTFVSRShzdGF0dXMpKSB7CisJCXByaW50ayhLRVJOX1dBUk5JTkcgImNhbid0IGdldCBweG0g
Zm9yIGFjcGlfaWQgJXhcbiIsCisJCSAgcHItPmFjcGlfaWQpOworCQlyZXR1cm4gLTE7CisJfQor
CisJc3dpdGNoIChldmVudCkgeworCWNhc2UgSE9UUExVR19UWVBFX0FERDoKKwkJb3AuY21kID0g
WEVOUEZfY3B1X2hvdGFkZDsKKwkJb3AudS5jcHVfYWRkLmFwaWNfaWQgPSBhcGljX2lkOworCQlv
cC51LmNwdV9hZGQuYWNwaV9pZCA9IHByLT5hY3BpX2lkOworCQlvcC51LmNwdV9hZGQucHhtID0g
cHhtOworCQlyZXQgPSBIWVBFUlZJU09SX2RvbTBfb3AoJm9wKTsKKwkJYnJlYWs7CisJY2FzZSBI
T1RQTFVHX1RZUEVfUkVNT1ZFOgorCQlwcmludGsoS0VSTl9XQVJOSU5HICJYZW4gbm90IHN1cHBv
cnQgQ1BVIGhvdHJlbW92ZVxuIik7CisJCXJldCA9IC1FTk9TWVM7CisJCWJyZWFrOworCX0KKwor
CXJldHVybiByZXQ7Cit9CisjZWxzZQorc3RhdGljIGludCB4ZW5fY3B1X2hvdHBsdWdfbm90aWZp
ZXIoc3RydWN0IGFjcGlfcHJvY2Vzc29yICpwciwgaW50IGV2ZW50KQoreworCXJldHVybiAtRU5P
U1lTOworfQorI2VuZGlmCisKIHN0YXRpYyBpbnQgX19pbml0IHhlbl9hY3BpX3Byb2Nlc3Nvcl9l
eHRjbnRsX2luaXQodm9pZCkKIHsKIAl1bnNpZ25lZCBpbnQgcG1iaXRzOwpkaWZmIC0tZ2l0IGEv
aW5jbHVkZS94ZW4vaW50ZXJmYWNlL3BsYXRmb3JtLmggYi9pbmNsdWRlL3hlbi9pbnRlcmZhY2Uv
cGxhdGZvcm0uaAppbmRleCA0N2ZmZTE2Li45ZmQ2YjA3IDEwMDY0NAotLS0gYS9pbmNsdWRlL3hl
bi9pbnRlcmZhY2UvcGxhdGZvcm0uaAorKysgYi9pbmNsdWRlL3hlbi9pbnRlcmZhY2UvcGxhdGZv
cm0uaApAQCAtMzE3LDExICszMTcsMTggQEAgREVGSU5FX0dVRVNUX0hBTkRMRV9TVFJVQ1QoeGVu
cGZfcGNwdWluZm9fdCk7CiAjZGVmaW5lIFhFTlBGX2NwdV9vbmxpbmUgICAgNTYKICNkZWZpbmUg
WEVOUEZfY3B1X29mZmxpbmUgICA1Nwogc3RydWN0IHhlbnBmX2NwdV9vbCB7Ci0gICAgdWludDMy
X3QgY3B1aWQ7CisJdWludDMyX3QgY3B1aWQ7CiB9OwogdHlwZWRlZiBzdHJ1Y3QgeGVucGZfY3B1
X29sIHhlbnBmX2NwdV9vbF90OwogREVGSU5FX0dVRVNUX0hBTkRMRV9TVFJVQ1QoeGVucGZfY3B1
X29sX3QpOwogCisjZGVmaW5lIFhFTlBGX2NwdV9ob3RhZGQgICAgNTgKK3N0cnVjdCB4ZW5wZl9j
cHVfaG90YWRkIHsKKwl1aW50MzJfdCBhcGljX2lkOworCXVpbnQzMl90IGFjcGlfaWQ7CisJdWlu
dDMyX3QgcHhtOworfTsKKwogc3RydWN0IHhlbl9wbGF0Zm9ybV9vcCB7CiAJdWludDMyX3QgY21k
OwogCXVpbnQzMl90IGludGVyZmFjZV92ZXJzaW9uOyAvKiBYRU5QRl9JTlRFUkZBQ0VfVkVSU0lP
TiAqLwpAQCAtMzM5LDYgKzM0Niw3IEBAIHN0cnVjdCB4ZW5fcGxhdGZvcm1fb3AgewogCQlzdHJ1
Y3QgeGVucGZfc2V0X3Byb2Nlc3Nvcl9wbWluZm8gc2V0X3BtaW5mbzsKIAkJc3RydWN0IHhlbnBm
X3BjcHVpbmZvICAgICAgICAgIHBjcHVfaW5mbzsKIAkJc3RydWN0IHhlbnBmX2NwdV9vbCAgICAg
ICAgICAgIGNwdV9vbDsKKwkJc3RydWN0IHhlbnBmX2NwdV9ob3RhZGQgICAgICAgIGNwdV9hZGQ7
CiAJCXVpbnQ4X3QgICAgICAgICAgICAgICAgICAgICAgICBwYWRbMTI4XTsKIAl9IHU7CiB9Owot
LSAKMS42LjUuNgoK

--_002_DE8DF0795D48FD4CA783C40EC8292335979FSHSMSX101ccrcorpint_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--_002_DE8DF0795D48FD4CA783C40EC8292335979FSHSMSX101ccrcorpint_--


From xen-devel-bounces@lists.xensource.com Fri Dec 23 10:35:43 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 Dec 2011 10:35:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Re2TL-0007c7-8T; Fri, 23 Dec 2011 10:35:31 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1Re2TJ-0007bb-Ls
	for xen-devel@lists.xensource.com; Fri, 23 Dec 2011 10:35:30 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1324636521!9181152!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDMwMDk1NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6691 invoked from network); 23 Dec 2011 10:35:22 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-6.tower-21.messagelabs.com with SMTP;
	23 Dec 2011 10:35:22 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga102.fm.intel.com with ESMTP; 23 Dec 2011 02:35:21 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208,223";a="99640591"
Received: from pgsmsx601.gar.corp.intel.com ([10.221.43.69])
	by fmsmga001.fm.intel.com with ESMTP; 23 Dec 2011 02:35:20 -0800
Received: from pgsmsx103.gar.corp.intel.com (10.221.44.82) by
	pgsmsx601.gar.corp.intel.com (10.221.43.69) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Fri, 23 Dec 2011 18:35:13 +0800
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	PGSMSX103.gar.corp.intel.com (10.221.44.82) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Fri, 23 Dec 2011 18:35:13 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.38]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.223]) with mapi id
	14.01.0355.002; Fri, 23 Dec 2011 18:35:12 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: "konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
Thread-Topic: [PATCH 04/10] Xen: Add pcpu hotadd support to pvops dom0.
Thread-Index: AczBXovu0ls0uF11RuS8UuGQwN8UbA==
Date: Fri, 23 Dec 2011 10:35:10 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC8292335979F@SHSMSX101.ccr.corp.intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
Content-Type: multipart/mixed;
	boundary="_002_DE8DF0795D48FD4CA783C40EC8292335979FSHSMSX101ccrcorpint_"
MIME-Version: 1.0
Cc: "Brown, Len" <len.brown@intel.com>,
	"jeremy.fitzhardinge@citrix.com" <jeremy.fitzhardinge@citrix.com>,
	"Jiang, Yunhong" <yunhong.jiang@intel.com>, "Shan, 
	Haitao" <haitao.shan@intel.com>,
	Kernel development list <linux-kernel@vger.kernel.org>, "Zhao,
	Yakui" <yakui.zhao@intel.com>, "Luck, Tony" <tony.luck@intel.com>, "Kleen,
	Andi" <andi.kleen@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: [Xen-devel] [PATCH 04/10] Xen: Add pcpu hotadd support to pvops
	dom0.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--_002_DE8DF0795D48FD4CA783C40EC8292335979FSHSMSX101ccrcorpint_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

>From 5f5eb7bf950836edb4910173d3be2f26ad737093 Mon Sep 17 00:00:00 2001
From: Liu Jinsong <jinsong.liu@intel.com>
Date: Sun, 11 Dec 2011 15:42:03 +0800
Subject: [PATCH 04/10] Xen: Add pcpu hotadd support to pvops dom0.

This patch rebased from Jeremy's pvops commit
3129884bc75d7e6578be7499ac04a06d9fc5b31d

This patch implement CPU hotplug callback in xen acpi_processor. User
can later bring the pcpu online through sysfs interface.

xen_get_apic_id() is mostly duplicated with the get_cpu_id() in
driver/acpi/processor_core.c, but it should be ok since it has been
duplicated in arch directory already by upstream kernel.

One thing left is, currently the acpi_processor's id is quite
confusing (it is in fact with vcpu's dom0 cpu_id). Will update it with
xen's cpuid through the pcpu interface. But to achieve it, we need
investigate more on the pr->id, and also we need change the pcpu logic
to use spin_lock, instead of mutex for the pcpu list. That will be
next step.

Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
Signed-off-by: Jiang, Yunhong <yunhong.jiang@intel.com>
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
---
 drivers/xen/acpi_processor.c     |  114 ++++++++++++++++++++++++++++++++++=
+++-
 include/xen/interface/platform.h |   10 +++-
 2 files changed, 122 insertions(+), 2 deletions(-)

diff --git a/drivers/xen/acpi_processor.c b/drivers/xen/acpi_processor.c
index 327a56e..acab49b 100644
--- a/drivers/xen/acpi_processor.c
+++ b/drivers/xen/acpi_processor.c
@@ -22,12 +22,19 @@
 #include <linux/cpufreq.h>
 #include <acpi/processor.h>
 #include <xen/acpi.h>
+#include <xen/pcpu.h>
=20
 #include <xen/interface/platform.h>
 #include <asm/xen/hypercall.h>
 #include <asm/xen/hypervisor.h>
=20
-static struct processor_cntl_xen_ops xen_ops;
+static int xen_get_apic_id(acpi_handle handle);
+static int xen_cpu_hotplug_notifier(struct acpi_processor *pr, int event);
+
+static struct processor_cntl_xen_ops xen_ops =3D {
+	.hotplug =3D xen_cpu_hotplug_notifier,
+};
+
 int processor_cntl_xen_notify(struct acpi_processor *pr, int event, int ty=
pe)
 {
 	int ret =3D -EINVAL;
@@ -41,6 +48,18 @@ int processor_cntl_xen_notify(struct acpi_processor *pr,=
 int event, int type)
=20
 		ret =3D xen_ops.pm_ops[type](pr, event);
 		break;
+	case PROCESSOR_HOTPLUG:
+	{
+		int apic_id;
+
+		apic_id =3D xen_get_apic_id(pr->handle);
+		if (apic_id < 0)
+			break;
+		if (xen_ops.hotplug)
+			ret =3D xen_ops.hotplug(pr, type);
+		xen_pcpu_hotplug(type, apic_id);
+		break;
+	}
 	default:
 		printk(KERN_ERR "Unsupport processor events %d.\n", event);
 		break;
@@ -50,6 +69,49 @@ int processor_cntl_xen_notify(struct acpi_processor *pr,=
 int event, int type)
 }
 EXPORT_SYMBOL(processor_cntl_xen_notify);
=20
+#ifdef CONFIG_ACPI_HOTPLUG_CPU
+static int xen_get_apic_id(acpi_handle handle)
+{
+	struct acpi_buffer buffer =3D { ACPI_ALLOCATE_BUFFER, NULL };
+	union acpi_object *obj;
+	struct acpi_madt_local_apic *lapic;
+	u8 physid;
+
+	if (ACPI_FAILURE(acpi_evaluate_object(handle, "_MAT", NULL, &buffer)))
+		return -EINVAL;
+
+	if (!buffer.length || !buffer.pointer)
+		return -EINVAL;
+
+	obj =3D buffer.pointer;
+	if (obj->type !=3D ACPI_TYPE_BUFFER ||
+	    obj->buffer.length < sizeof(*lapic)) {
+		kfree(buffer.pointer);
+		return -EINVAL;
+	}
+
+	lapic =3D (struct acpi_madt_local_apic *)obj->buffer.pointer;
+
+	if (lapic->header.type !=3D ACPI_MADT_TYPE_LOCAL_APIC ||
+	    !(lapic->lapic_flags & ACPI_MADT_ENABLED)) {
+		kfree(buffer.pointer);
+		return -EINVAL;
+	}
+
+	physid =3D lapic->id;
+	kfree(buffer.pointer);
+	buffer.length =3D ACPI_ALLOCATE_BUFFER;
+	buffer.pointer =3D NULL;
+
+	return physid;
+}
+#else
+static int xen_get_apic_id(acpi_handle handle)
+{
+	return -1;
+}
+#endif
+
 static inline void xen_convert_pct_reg(struct xen_pct_register *xpct,
 	struct acpi_pct_register *apct)
 {
@@ -246,6 +308,56 @@ static int xen_px_notifier(struct acpi_processor *pr, =
int action)
 	return ret;
 }
=20
+#ifdef CONFIG_ACPI_HOTPLUG_CPU
+static int xen_cpu_hotplug_notifier(struct acpi_processor *pr, int event)
+{
+	int ret =3D -EINVAL;
+	uint32_t apic_id;
+	unsigned long long pxm;
+	acpi_status status =3D 0;
+
+	xen_platform_op_t op =3D {
+		.interface_version  =3D XENPF_INTERFACE_VERSION,
+	};
+
+	apic_id =3D xen_get_apic_id(pr->handle);
+	if (apic_id < 0) {
+		printk(KERN_WARNING "Can't get apic_id for acpi_id %x\n",
+		  pr->acpi_id);
+		return -1;
+	}
+
+	status =3D acpi_evaluate_integer(pr->handle, "_PXM",
+	  NULL, &pxm);
+	if (ACPI_FAILURE(status)) {
+		printk(KERN_WARNING "can't get pxm for acpi_id %x\n",
+		  pr->acpi_id);
+		return -1;
+	}
+
+	switch (event) {
+	case HOTPLUG_TYPE_ADD:
+		op.cmd =3D XENPF_cpu_hotadd;
+		op.u.cpu_add.apic_id =3D apic_id;
+		op.u.cpu_add.acpi_id =3D pr->acpi_id;
+		op.u.cpu_add.pxm =3D pxm;
+		ret =3D HYPERVISOR_dom0_op(&op);
+		break;
+	case HOTPLUG_TYPE_REMOVE:
+		printk(KERN_WARNING "Xen not support CPU hotremove\n");
+		ret =3D -ENOSYS;
+		break;
+	}
+
+	return ret;
+}
+#else
+static int xen_cpu_hotplug_notifier(struct acpi_processor *pr, int event)
+{
+	return -ENOSYS;
+}
+#endif
+
 static int __init xen_acpi_processor_extcntl_init(void)
 {
 	unsigned int pmbits;
diff --git a/include/xen/interface/platform.h b/include/xen/interface/platf=
orm.h
index 47ffe16..9fd6b07 100644
--- a/include/xen/interface/platform.h
+++ b/include/xen/interface/platform.h
@@ -317,11 +317,18 @@ DEFINE_GUEST_HANDLE_STRUCT(xenpf_pcpuinfo_t);
 #define XENPF_cpu_online    56
 #define XENPF_cpu_offline   57
 struct xenpf_cpu_ol {
-    uint32_t cpuid;
+	uint32_t cpuid;
 };
 typedef struct xenpf_cpu_ol xenpf_cpu_ol_t;
 DEFINE_GUEST_HANDLE_STRUCT(xenpf_cpu_ol_t);
=20
+#define XENPF_cpu_hotadd    58
+struct xenpf_cpu_hotadd {
+	uint32_t apic_id;
+	uint32_t acpi_id;
+	uint32_t pxm;
+};
+
 struct xen_platform_op {
 	uint32_t cmd;
 	uint32_t interface_version; /* XENPF_INTERFACE_VERSION */
@@ -339,6 +346,7 @@ struct xen_platform_op {
 		struct xenpf_set_processor_pminfo set_pminfo;
 		struct xenpf_pcpuinfo          pcpu_info;
 		struct xenpf_cpu_ol            cpu_ol;
+		struct xenpf_cpu_hotadd        cpu_add;
 		uint8_t                        pad[128];
 	} u;
 };
--=20
1.6.5.6

--_002_DE8DF0795D48FD4CA783C40EC8292335979FSHSMSX101ccrcorpint_
Content-Type: application/octet-stream;
	name="0004-Xen-Add-pcpu-hotadd-support-to-pvops-dom0.patch"
Content-Description: 0004-Xen-Add-pcpu-hotadd-support-to-pvops-dom0.patch
Content-Disposition: attachment;
	filename="0004-Xen-Add-pcpu-hotadd-support-to-pvops-dom0.patch"; size=6111;
	creation-date="Wed, 14 Dec 2011 15:20:15 GMT";
	modification-date="Wed, 14 Dec 2011 15:03:34 GMT"
Content-Transfer-Encoding: base64

RnJvbSA1ZjVlYjdiZjk1MDgzNmVkYjQ5MTAxNzNkM2JlMmYyNmFkNzM3MDkzIE1vbiBTZXAgMTcg
MDA6MDA6MDAgMjAwMQpGcm9tOiBMaXUgSmluc29uZyA8amluc29uZy5saXVAaW50ZWwuY29tPgpE
YXRlOiBTdW4sIDExIERlYyAyMDExIDE1OjQyOjAzICswODAwClN1YmplY3Q6IFtQQVRDSCAwNC8x
MF0gWGVuOiBBZGQgcGNwdSBob3RhZGQgc3VwcG9ydCB0byBwdm9wcyBkb20wLgoKVGhpcyBwYXRj
aCByZWJhc2VkIGZyb20gSmVyZW15J3MgcHZvcHMgY29tbWl0CjMxMjk4ODRiYzc1ZDdlNjU3OGJl
NzQ5OWFjMDRhMDZkOWZjNWIzMWQKClRoaXMgcGF0Y2ggaW1wbGVtZW50IENQVSBob3RwbHVnIGNh
bGxiYWNrIGluIHhlbiBhY3BpX3Byb2Nlc3Nvci4gVXNlcgpjYW4gbGF0ZXIgYnJpbmcgdGhlIHBj
cHUgb25saW5lIHRocm91Z2ggc3lzZnMgaW50ZXJmYWNlLgoKeGVuX2dldF9hcGljX2lkKCkgaXMg
bW9zdGx5IGR1cGxpY2F0ZWQgd2l0aCB0aGUgZ2V0X2NwdV9pZCgpIGluCmRyaXZlci9hY3BpL3By
b2Nlc3Nvcl9jb3JlLmMsIGJ1dCBpdCBzaG91bGQgYmUgb2sgc2luY2UgaXQgaGFzIGJlZW4KZHVw
bGljYXRlZCBpbiBhcmNoIGRpcmVjdG9yeSBhbHJlYWR5IGJ5IHVwc3RyZWFtIGtlcm5lbC4KCk9u
ZSB0aGluZyBsZWZ0IGlzLCBjdXJyZW50bHkgdGhlIGFjcGlfcHJvY2Vzc29yJ3MgaWQgaXMgcXVp
dGUKY29uZnVzaW5nIChpdCBpcyBpbiBmYWN0IHdpdGggdmNwdSdzIGRvbTAgY3B1X2lkKS4gV2ls
bCB1cGRhdGUgaXQgd2l0aAp4ZW4ncyBjcHVpZCB0aHJvdWdoIHRoZSBwY3B1IGludGVyZmFjZS4g
QnV0IHRvIGFjaGlldmUgaXQsIHdlIG5lZWQKaW52ZXN0aWdhdGUgbW9yZSBvbiB0aGUgcHItPmlk
LCBhbmQgYWxzbyB3ZSBuZWVkIGNoYW5nZSB0aGUgcGNwdSBsb2dpYwp0byB1c2Ugc3Bpbl9sb2Nr
LCBpbnN0ZWFkIG9mIG11dGV4IGZvciB0aGUgcGNwdSBsaXN0LiBUaGF0IHdpbGwgYmUKbmV4dCBz
dGVwLgoKU2lnbmVkLW9mZi1ieTogTGl1LCBKaW5zb25nIDxqaW5zb25nLmxpdUBpbnRlbC5jb20+
ClNpZ25lZC1vZmYtYnk6IEppYW5nLCBZdW5ob25nIDx5dW5ob25nLmppYW5nQGludGVsLmNvbT4K
U2lnbmVkLW9mZi1ieTogSmVyZW15IEZpdHpoYXJkaW5nZSA8amVyZW15LmZpdHpoYXJkaW5nZUBj
aXRyaXguY29tPgotLS0KIGRyaXZlcnMveGVuL2FjcGlfcHJvY2Vzc29yLmMgICAgIHwgIDExNCAr
KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrLQogaW5jbHVkZS94ZW4vaW50ZXJm
YWNlL3BsYXRmb3JtLmggfCAgIDEwICsrKy0KIDIgZmlsZXMgY2hhbmdlZCwgMTIyIGluc2VydGlv
bnMoKyksIDIgZGVsZXRpb25zKC0pCgpkaWZmIC0tZ2l0IGEvZHJpdmVycy94ZW4vYWNwaV9wcm9j
ZXNzb3IuYyBiL2RyaXZlcnMveGVuL2FjcGlfcHJvY2Vzc29yLmMKaW5kZXggMzI3YTU2ZS4uYWNh
YjQ5YiAxMDA2NDQKLS0tIGEvZHJpdmVycy94ZW4vYWNwaV9wcm9jZXNzb3IuYworKysgYi9kcml2
ZXJzL3hlbi9hY3BpX3Byb2Nlc3Nvci5jCkBAIC0yMiwxMiArMjIsMTkgQEAKICNpbmNsdWRlIDxs
aW51eC9jcHVmcmVxLmg+CiAjaW5jbHVkZSA8YWNwaS9wcm9jZXNzb3IuaD4KICNpbmNsdWRlIDx4
ZW4vYWNwaS5oPgorI2luY2x1ZGUgPHhlbi9wY3B1Lmg+CiAKICNpbmNsdWRlIDx4ZW4vaW50ZXJm
YWNlL3BsYXRmb3JtLmg+CiAjaW5jbHVkZSA8YXNtL3hlbi9oeXBlcmNhbGwuaD4KICNpbmNsdWRl
IDxhc20veGVuL2h5cGVydmlzb3IuaD4KIAotc3RhdGljIHN0cnVjdCBwcm9jZXNzb3JfY250bF94
ZW5fb3BzIHhlbl9vcHM7CitzdGF0aWMgaW50IHhlbl9nZXRfYXBpY19pZChhY3BpX2hhbmRsZSBo
YW5kbGUpOworc3RhdGljIGludCB4ZW5fY3B1X2hvdHBsdWdfbm90aWZpZXIoc3RydWN0IGFjcGlf
cHJvY2Vzc29yICpwciwgaW50IGV2ZW50KTsKKworc3RhdGljIHN0cnVjdCBwcm9jZXNzb3JfY250
bF94ZW5fb3BzIHhlbl9vcHMgPSB7CisJLmhvdHBsdWcgPSB4ZW5fY3B1X2hvdHBsdWdfbm90aWZp
ZXIsCit9OworCiBpbnQgcHJvY2Vzc29yX2NudGxfeGVuX25vdGlmeShzdHJ1Y3QgYWNwaV9wcm9j
ZXNzb3IgKnByLCBpbnQgZXZlbnQsIGludCB0eXBlKQogewogCWludCByZXQgPSAtRUlOVkFMOwpA
QCAtNDEsNiArNDgsMTggQEAgaW50IHByb2Nlc3Nvcl9jbnRsX3hlbl9ub3RpZnkoc3RydWN0IGFj
cGlfcHJvY2Vzc29yICpwciwgaW50IGV2ZW50LCBpbnQgdHlwZSkKIAogCQlyZXQgPSB4ZW5fb3Bz
LnBtX29wc1t0eXBlXShwciwgZXZlbnQpOwogCQlicmVhazsKKwljYXNlIFBST0NFU1NPUl9IT1RQ
TFVHOgorCXsKKwkJaW50IGFwaWNfaWQ7CisKKwkJYXBpY19pZCA9IHhlbl9nZXRfYXBpY19pZChw
ci0+aGFuZGxlKTsKKwkJaWYgKGFwaWNfaWQgPCAwKQorCQkJYnJlYWs7CisJCWlmICh4ZW5fb3Bz
LmhvdHBsdWcpCisJCQlyZXQgPSB4ZW5fb3BzLmhvdHBsdWcocHIsIHR5cGUpOworCQl4ZW5fcGNw
dV9ob3RwbHVnKHR5cGUsIGFwaWNfaWQpOworCQlicmVhazsKKwl9CiAJZGVmYXVsdDoKIAkJcHJp
bnRrKEtFUk5fRVJSICJVbnN1cHBvcnQgcHJvY2Vzc29yIGV2ZW50cyAlZC5cbiIsIGV2ZW50KTsK
IAkJYnJlYWs7CkBAIC01MCw2ICs2OSw0OSBAQCBpbnQgcHJvY2Vzc29yX2NudGxfeGVuX25vdGlm
eShzdHJ1Y3QgYWNwaV9wcm9jZXNzb3IgKnByLCBpbnQgZXZlbnQsIGludCB0eXBlKQogfQogRVhQ
T1JUX1NZTUJPTChwcm9jZXNzb3JfY250bF94ZW5fbm90aWZ5KTsKIAorI2lmZGVmIENPTkZJR19B
Q1BJX0hPVFBMVUdfQ1BVCitzdGF0aWMgaW50IHhlbl9nZXRfYXBpY19pZChhY3BpX2hhbmRsZSBo
YW5kbGUpCit7CisJc3RydWN0IGFjcGlfYnVmZmVyIGJ1ZmZlciA9IHsgQUNQSV9BTExPQ0FURV9C
VUZGRVIsIE5VTEwgfTsKKwl1bmlvbiBhY3BpX29iamVjdCAqb2JqOworCXN0cnVjdCBhY3BpX21h
ZHRfbG9jYWxfYXBpYyAqbGFwaWM7CisJdTggcGh5c2lkOworCisJaWYgKEFDUElfRkFJTFVSRShh
Y3BpX2V2YWx1YXRlX29iamVjdChoYW5kbGUsICJfTUFUIiwgTlVMTCwgJmJ1ZmZlcikpKQorCQly
ZXR1cm4gLUVJTlZBTDsKKworCWlmICghYnVmZmVyLmxlbmd0aCB8fCAhYnVmZmVyLnBvaW50ZXIp
CisJCXJldHVybiAtRUlOVkFMOworCisJb2JqID0gYnVmZmVyLnBvaW50ZXI7CisJaWYgKG9iai0+
dHlwZSAhPSBBQ1BJX1RZUEVfQlVGRkVSIHx8CisJICAgIG9iai0+YnVmZmVyLmxlbmd0aCA8IHNp
emVvZigqbGFwaWMpKSB7CisJCWtmcmVlKGJ1ZmZlci5wb2ludGVyKTsKKwkJcmV0dXJuIC1FSU5W
QUw7CisJfQorCisJbGFwaWMgPSAoc3RydWN0IGFjcGlfbWFkdF9sb2NhbF9hcGljICopb2JqLT5i
dWZmZXIucG9pbnRlcjsKKworCWlmIChsYXBpYy0+aGVhZGVyLnR5cGUgIT0gQUNQSV9NQURUX1RZ
UEVfTE9DQUxfQVBJQyB8fAorCSAgICAhKGxhcGljLT5sYXBpY19mbGFncyAmIEFDUElfTUFEVF9F
TkFCTEVEKSkgeworCQlrZnJlZShidWZmZXIucG9pbnRlcik7CisJCXJldHVybiAtRUlOVkFMOwor
CX0KKworCXBoeXNpZCA9IGxhcGljLT5pZDsKKwlrZnJlZShidWZmZXIucG9pbnRlcik7CisJYnVm
ZmVyLmxlbmd0aCA9IEFDUElfQUxMT0NBVEVfQlVGRkVSOworCWJ1ZmZlci5wb2ludGVyID0gTlVM
TDsKKworCXJldHVybiBwaHlzaWQ7Cit9CisjZWxzZQorc3RhdGljIGludCB4ZW5fZ2V0X2FwaWNf
aWQoYWNwaV9oYW5kbGUgaGFuZGxlKQoreworCXJldHVybiAtMTsKK30KKyNlbmRpZgorCiBzdGF0
aWMgaW5saW5lIHZvaWQgeGVuX2NvbnZlcnRfcGN0X3JlZyhzdHJ1Y3QgeGVuX3BjdF9yZWdpc3Rl
ciAqeHBjdCwKIAlzdHJ1Y3QgYWNwaV9wY3RfcmVnaXN0ZXIgKmFwY3QpCiB7CkBAIC0yNDYsNiAr
MzA4LDU2IEBAIHN0YXRpYyBpbnQgeGVuX3B4X25vdGlmaWVyKHN0cnVjdCBhY3BpX3Byb2Nlc3Nv
ciAqcHIsIGludCBhY3Rpb24pCiAJcmV0dXJuIHJldDsKIH0KIAorI2lmZGVmIENPTkZJR19BQ1BJ
X0hPVFBMVUdfQ1BVCitzdGF0aWMgaW50IHhlbl9jcHVfaG90cGx1Z19ub3RpZmllcihzdHJ1Y3Qg
YWNwaV9wcm9jZXNzb3IgKnByLCBpbnQgZXZlbnQpCit7CisJaW50IHJldCA9IC1FSU5WQUw7CisJ
dWludDMyX3QgYXBpY19pZDsKKwl1bnNpZ25lZCBsb25nIGxvbmcgcHhtOworCWFjcGlfc3RhdHVz
IHN0YXR1cyA9IDA7CisKKwl4ZW5fcGxhdGZvcm1fb3BfdCBvcCA9IHsKKwkJLmludGVyZmFjZV92
ZXJzaW9uICA9IFhFTlBGX0lOVEVSRkFDRV9WRVJTSU9OLAorCX07CisKKwlhcGljX2lkID0geGVu
X2dldF9hcGljX2lkKHByLT5oYW5kbGUpOworCWlmIChhcGljX2lkIDwgMCkgeworCQlwcmludGso
S0VSTl9XQVJOSU5HICJDYW4ndCBnZXQgYXBpY19pZCBmb3IgYWNwaV9pZCAleFxuIiwKKwkJICBw
ci0+YWNwaV9pZCk7CisJCXJldHVybiAtMTsKKwl9CisKKwlzdGF0dXMgPSBhY3BpX2V2YWx1YXRl
X2ludGVnZXIocHItPmhhbmRsZSwgIl9QWE0iLAorCSAgTlVMTCwgJnB4bSk7CisJaWYgKEFDUElf
RkFJTFVSRShzdGF0dXMpKSB7CisJCXByaW50ayhLRVJOX1dBUk5JTkcgImNhbid0IGdldCBweG0g
Zm9yIGFjcGlfaWQgJXhcbiIsCisJCSAgcHItPmFjcGlfaWQpOworCQlyZXR1cm4gLTE7CisJfQor
CisJc3dpdGNoIChldmVudCkgeworCWNhc2UgSE9UUExVR19UWVBFX0FERDoKKwkJb3AuY21kID0g
WEVOUEZfY3B1X2hvdGFkZDsKKwkJb3AudS5jcHVfYWRkLmFwaWNfaWQgPSBhcGljX2lkOworCQlv
cC51LmNwdV9hZGQuYWNwaV9pZCA9IHByLT5hY3BpX2lkOworCQlvcC51LmNwdV9hZGQucHhtID0g
cHhtOworCQlyZXQgPSBIWVBFUlZJU09SX2RvbTBfb3AoJm9wKTsKKwkJYnJlYWs7CisJY2FzZSBI
T1RQTFVHX1RZUEVfUkVNT1ZFOgorCQlwcmludGsoS0VSTl9XQVJOSU5HICJYZW4gbm90IHN1cHBv
cnQgQ1BVIGhvdHJlbW92ZVxuIik7CisJCXJldCA9IC1FTk9TWVM7CisJCWJyZWFrOworCX0KKwor
CXJldHVybiByZXQ7Cit9CisjZWxzZQorc3RhdGljIGludCB4ZW5fY3B1X2hvdHBsdWdfbm90aWZp
ZXIoc3RydWN0IGFjcGlfcHJvY2Vzc29yICpwciwgaW50IGV2ZW50KQoreworCXJldHVybiAtRU5P
U1lTOworfQorI2VuZGlmCisKIHN0YXRpYyBpbnQgX19pbml0IHhlbl9hY3BpX3Byb2Nlc3Nvcl9l
eHRjbnRsX2luaXQodm9pZCkKIHsKIAl1bnNpZ25lZCBpbnQgcG1iaXRzOwpkaWZmIC0tZ2l0IGEv
aW5jbHVkZS94ZW4vaW50ZXJmYWNlL3BsYXRmb3JtLmggYi9pbmNsdWRlL3hlbi9pbnRlcmZhY2Uv
cGxhdGZvcm0uaAppbmRleCA0N2ZmZTE2Li45ZmQ2YjA3IDEwMDY0NAotLS0gYS9pbmNsdWRlL3hl
bi9pbnRlcmZhY2UvcGxhdGZvcm0uaAorKysgYi9pbmNsdWRlL3hlbi9pbnRlcmZhY2UvcGxhdGZv
cm0uaApAQCAtMzE3LDExICszMTcsMTggQEAgREVGSU5FX0dVRVNUX0hBTkRMRV9TVFJVQ1QoeGVu
cGZfcGNwdWluZm9fdCk7CiAjZGVmaW5lIFhFTlBGX2NwdV9vbmxpbmUgICAgNTYKICNkZWZpbmUg
WEVOUEZfY3B1X29mZmxpbmUgICA1Nwogc3RydWN0IHhlbnBmX2NwdV9vbCB7Ci0gICAgdWludDMy
X3QgY3B1aWQ7CisJdWludDMyX3QgY3B1aWQ7CiB9OwogdHlwZWRlZiBzdHJ1Y3QgeGVucGZfY3B1
X29sIHhlbnBmX2NwdV9vbF90OwogREVGSU5FX0dVRVNUX0hBTkRMRV9TVFJVQ1QoeGVucGZfY3B1
X29sX3QpOwogCisjZGVmaW5lIFhFTlBGX2NwdV9ob3RhZGQgICAgNTgKK3N0cnVjdCB4ZW5wZl9j
cHVfaG90YWRkIHsKKwl1aW50MzJfdCBhcGljX2lkOworCXVpbnQzMl90IGFjcGlfaWQ7CisJdWlu
dDMyX3QgcHhtOworfTsKKwogc3RydWN0IHhlbl9wbGF0Zm9ybV9vcCB7CiAJdWludDMyX3QgY21k
OwogCXVpbnQzMl90IGludGVyZmFjZV92ZXJzaW9uOyAvKiBYRU5QRl9JTlRFUkZBQ0VfVkVSU0lP
TiAqLwpAQCAtMzM5LDYgKzM0Niw3IEBAIHN0cnVjdCB4ZW5fcGxhdGZvcm1fb3AgewogCQlzdHJ1
Y3QgeGVucGZfc2V0X3Byb2Nlc3Nvcl9wbWluZm8gc2V0X3BtaW5mbzsKIAkJc3RydWN0IHhlbnBm
X3BjcHVpbmZvICAgICAgICAgIHBjcHVfaW5mbzsKIAkJc3RydWN0IHhlbnBmX2NwdV9vbCAgICAg
ICAgICAgIGNwdV9vbDsKKwkJc3RydWN0IHhlbnBmX2NwdV9ob3RhZGQgICAgICAgIGNwdV9hZGQ7
CiAJCXVpbnQ4X3QgICAgICAgICAgICAgICAgICAgICAgICBwYWRbMTI4XTsKIAl9IHU7CiB9Owot
LSAKMS42LjUuNgoK

--_002_DE8DF0795D48FD4CA783C40EC8292335979FSHSMSX101ccrcorpint_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--_002_DE8DF0795D48FD4CA783C40EC8292335979FSHSMSX101ccrcorpint_--


From xen-devel-bounces@lists.xensource.com Fri Dec 23 10:36:50 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 Dec 2011 10: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.xensource.com>)
	id 1Re2UT-0007jY-18; Fri, 23 Dec 2011 10:36:41 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1Re2US-0007jF-2T
	for xen-devel@lists.xensource.com; Fri, 23 Dec 2011 10:36:40 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1324636592!7749275!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDMwMDk1NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29550 invoked from network); 23 Dec 2011 10:36:33 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-12.tower-21.messagelabs.com with SMTP;
	23 Dec 2011 10:36:33 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga102.fm.intel.com with ESMTP; 23 Dec 2011 02:36:32 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208,223";a="99640813"
Received: from pgsmsx601.gar.corp.intel.com ([10.221.43.69])
	by fmsmga001.fm.intel.com with ESMTP; 23 Dec 2011 02:36:31 -0800
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	pgsmsx601.gar.corp.intel.com (10.221.43.69) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Fri, 23 Dec 2011 18:36:30 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.38]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.223]) with mapi id
	14.01.0355.002; Fri, 23 Dec 2011 18:36:29 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: "konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
Thread-Topic: [PATCH 05/10] xen/acpi: Move acpi_memory_info definition to
	public
Thread-Index: AczBXrpnWJj7owNBS3CwTrfqrXT0pA==
Date: Fri, 23 Dec 2011 10:36:28 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC829233597AA@SHSMSX101.ccr.corp.intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
Content-Type: multipart/mixed;
	boundary="_002_DE8DF0795D48FD4CA783C40EC829233597AASHSMSX101ccrcorpint_"
MIME-Version: 1.0
Cc: "Brown, Len" <len.brown@intel.com>,
	"jeremy.fitzhardinge@citrix.com" <jeremy.fitzhardinge@citrix.com>,
	"Jiang, Yunhong" <yunhong.jiang@intel.com>, "Shan, 
	Haitao" <haitao.shan@intel.com>,
	Kernel development list <linux-kernel@vger.kernel.org>, "Zhao,
	Yakui" <yakui.zhao@intel.com>, "Luck, Tony" <tony.luck@intel.com>, "Kleen,
	Andi" <andi.kleen@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: [Xen-devel] [PATCH 05/10] xen/acpi: Move acpi_memory_info
	definition to public
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--_002_DE8DF0795D48FD4CA783C40EC829233597AASHSMSX101ccrcorpint_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

>From 0172b1ce6a2ba70e739f968622d78ac1796813f9 Mon Sep 17 00:00:00 2001
From: Liu Jinsong <jinsong.liu@intel.com>
Date: Sun, 11 Dec 2011 17:25:35 +0800
Subject: [PATCH 05/10] xen/acpi: Move acpi_memory_info definition to public

This patch rebased from Jeremy's pvops commit
359e747e6260f105f750657917e1dc75f6427602

Move this definition to header file so that it can be used by dom0
memory hotadd logic also.

Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
Signed-off-by: Jiang, Yunhong <yunhong.jiang@intel.com>
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
---
 drivers/acpi/acpi_memhotplug.c |   15 ---------------
 include/acpi/acpi_drivers.h    |   21 +++++++++++++++++++++
 2 files changed, 21 insertions(+), 15 deletions(-)

diff --git a/drivers/acpi/acpi_memhotplug.c b/drivers/acpi/acpi_memhotplug.=
c
index d985713..e28e64d 100644
--- a/drivers/acpi/acpi_memhotplug.c
+++ b/drivers/acpi/acpi_memhotplug.c
@@ -71,21 +71,6 @@ static struct acpi_driver acpi_memory_device_driver =3D =
{
 		},
 };
=20
-struct acpi_memory_info {
-	struct list_head list;
-	u64 start_addr;		/* Memory Range start physical addr */
-	u64 length;		/* Memory Range length */
-	unsigned short caching;	/* memory cache attribute */
-	unsigned short write_protect;	/* memory read/write attribute */
-	unsigned int enabled:1;
-};
-
-struct acpi_memory_device {
-	struct acpi_device * device;
-	unsigned int state;	/* State of the memory device */
-	struct list_head res_list;
-};
-
 static int acpi_hotmem_initialized;
=20
 static acpi_status
diff --git a/include/acpi/acpi_drivers.h b/include/acpi/acpi_drivers.h
index e49c36d..833de75 100644
--- a/include/acpi/acpi_drivers.h
+++ b/include/acpi/acpi_drivers.h
@@ -154,4 +154,25 @@ static inline void unregister_hotplug_dock_device(acpi=
_handle handle)
 }
 #endif
=20
+/*------------------------------------------------------------------------=
--
+                                Memory
+  ------------------------------------------------------------------------=
-- */
+#if defined(CONFIG_ACPI_HOTPLUG_MEMORY) || \
+        defined(CONFIG_ACPI_HOTPLUG_MEMORY_MODULE)
+struct acpi_memory_info {
+        struct list_head list;
+        u64 start_addr;         /* Memory Range start physical addr */
+        u64 length;             /* Memory Range length */
+        unsigned short caching; /* memory cache attribute */
+        unsigned short write_protect;   /* memory read/write attribute */
+        unsigned int enabled:1;
+};
+
+struct acpi_memory_device {
+        struct acpi_device *device;
+        unsigned int state;     /* State of the memory device */
+        struct list_head res_list;
+};
+#endif
+
 #endif /*__ACPI_DRIVERS_H__*/
--=20
1.6.5.6

--_002_DE8DF0795D48FD4CA783C40EC829233597AASHSMSX101ccrcorpint_
Content-Type: application/octet-stream;
	name="0005-xen-acpi-Move-acpi_memory_info-definition-to-public.patch"
Content-Description: 0005-xen-acpi-Move-acpi_memory_info-definition-to-public.patch
Content-Disposition: attachment;
	filename="0005-xen-acpi-Move-acpi_memory_info-definition-to-public.patch";
	size=2702; creation-date="Wed, 14 Dec 2011 15:20:15 GMT";
	modification-date="Wed, 14 Dec 2011 15:03:34 GMT"
Content-Transfer-Encoding: base64

RnJvbSAwMTcyYjFjZTZhMmJhNzBlNzM5Zjk2ODYyMmQ3OGFjMTc5NjgxM2Y5IE1vbiBTZXAgMTcg
MDA6MDA6MDAgMjAwMQpGcm9tOiBMaXUgSmluc29uZyA8amluc29uZy5saXVAaW50ZWwuY29tPgpE
YXRlOiBTdW4sIDExIERlYyAyMDExIDE3OjI1OjM1ICswODAwClN1YmplY3Q6IFtQQVRDSCAwNS8x
MF0geGVuL2FjcGk6IE1vdmUgYWNwaV9tZW1vcnlfaW5mbyBkZWZpbml0aW9uIHRvIHB1YmxpYwoK
VGhpcyBwYXRjaCByZWJhc2VkIGZyb20gSmVyZW15J3MgcHZvcHMgY29tbWl0CjM1OWU3NDdlNjI2
MGYxMDVmNzUwNjU3OTE3ZTFkYzc1ZjY0Mjc2MDIKCk1vdmUgdGhpcyBkZWZpbml0aW9uIHRvIGhl
YWRlciBmaWxlIHNvIHRoYXQgaXQgY2FuIGJlIHVzZWQgYnkgZG9tMAptZW1vcnkgaG90YWRkIGxv
Z2ljIGFsc28uCgpTaWduZWQtb2ZmLWJ5OiBMaXUsIEppbnNvbmcgPGppbnNvbmcubGl1QGludGVs
LmNvbT4KU2lnbmVkLW9mZi1ieTogSmlhbmcsIFl1bmhvbmcgPHl1bmhvbmcuamlhbmdAaW50ZWwu
Y29tPgpTaWduZWQtb2ZmLWJ5OiBKZXJlbXkgRml0emhhcmRpbmdlIDxqZXJlbXkuZml0emhhcmRp
bmdlQGNpdHJpeC5jb20+Ci0tLQogZHJpdmVycy9hY3BpL2FjcGlfbWVtaG90cGx1Zy5jIHwgICAx
NSAtLS0tLS0tLS0tLS0tLS0KIGluY2x1ZGUvYWNwaS9hY3BpX2RyaXZlcnMuaCAgICB8ICAgMjEg
KysrKysrKysrKysrKysrKysrKysrCiAyIGZpbGVzIGNoYW5nZWQsIDIxIGluc2VydGlvbnMoKyks
IDE1IGRlbGV0aW9ucygtKQoKZGlmZiAtLWdpdCBhL2RyaXZlcnMvYWNwaS9hY3BpX21lbWhvdHBs
dWcuYyBiL2RyaXZlcnMvYWNwaS9hY3BpX21lbWhvdHBsdWcuYwppbmRleCBkOTg1NzEzLi5lMjhl
NjRkIDEwMDY0NAotLS0gYS9kcml2ZXJzL2FjcGkvYWNwaV9tZW1ob3RwbHVnLmMKKysrIGIvZHJp
dmVycy9hY3BpL2FjcGlfbWVtaG90cGx1Zy5jCkBAIC03MSwyMSArNzEsNiBAQCBzdGF0aWMgc3Ry
dWN0IGFjcGlfZHJpdmVyIGFjcGlfbWVtb3J5X2RldmljZV9kcml2ZXIgPSB7CiAJCX0sCiB9Owog
Ci1zdHJ1Y3QgYWNwaV9tZW1vcnlfaW5mbyB7Ci0Jc3RydWN0IGxpc3RfaGVhZCBsaXN0OwotCXU2
NCBzdGFydF9hZGRyOwkJLyogTWVtb3J5IFJhbmdlIHN0YXJ0IHBoeXNpY2FsIGFkZHIgKi8KLQl1
NjQgbGVuZ3RoOwkJLyogTWVtb3J5IFJhbmdlIGxlbmd0aCAqLwotCXVuc2lnbmVkIHNob3J0IGNh
Y2hpbmc7CS8qIG1lbW9yeSBjYWNoZSBhdHRyaWJ1dGUgKi8KLQl1bnNpZ25lZCBzaG9ydCB3cml0
ZV9wcm90ZWN0OwkvKiBtZW1vcnkgcmVhZC93cml0ZSBhdHRyaWJ1dGUgKi8KLQl1bnNpZ25lZCBp
bnQgZW5hYmxlZDoxOwotfTsKLQotc3RydWN0IGFjcGlfbWVtb3J5X2RldmljZSB7Ci0Jc3RydWN0
IGFjcGlfZGV2aWNlICogZGV2aWNlOwotCXVuc2lnbmVkIGludCBzdGF0ZTsJLyogU3RhdGUgb2Yg
dGhlIG1lbW9yeSBkZXZpY2UgKi8KLQlzdHJ1Y3QgbGlzdF9oZWFkIHJlc19saXN0OwotfTsKLQog
c3RhdGljIGludCBhY3BpX2hvdG1lbV9pbml0aWFsaXplZDsKIAogc3RhdGljIGFjcGlfc3RhdHVz
CmRpZmYgLS1naXQgYS9pbmNsdWRlL2FjcGkvYWNwaV9kcml2ZXJzLmggYi9pbmNsdWRlL2FjcGkv
YWNwaV9kcml2ZXJzLmgKaW5kZXggZTQ5YzM2ZC4uODMzZGU3NSAxMDA2NDQKLS0tIGEvaW5jbHVk
ZS9hY3BpL2FjcGlfZHJpdmVycy5oCisrKyBiL2luY2x1ZGUvYWNwaS9hY3BpX2RyaXZlcnMuaApA
QCAtMTU0LDQgKzE1NCwyNSBAQCBzdGF0aWMgaW5saW5lIHZvaWQgdW5yZWdpc3Rlcl9ob3RwbHVn
X2RvY2tfZGV2aWNlKGFjcGlfaGFuZGxlIGhhbmRsZSkKIH0KICNlbmRpZgogCisvKi0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIE1lbW9yeQorICAtLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLSAqLworI2lmIGRlZmluZWQoQ09ORklHX0FDUElfSE9UUExVR19NRU1PUlkp
IHx8IFwKKyAgICAgICAgZGVmaW5lZChDT05GSUdfQUNQSV9IT1RQTFVHX01FTU9SWV9NT0RVTEUp
CitzdHJ1Y3QgYWNwaV9tZW1vcnlfaW5mbyB7CisgICAgICAgIHN0cnVjdCBsaXN0X2hlYWQgbGlz
dDsKKyAgICAgICAgdTY0IHN0YXJ0X2FkZHI7ICAgICAgICAgLyogTWVtb3J5IFJhbmdlIHN0YXJ0
IHBoeXNpY2FsIGFkZHIgKi8KKyAgICAgICAgdTY0IGxlbmd0aDsgICAgICAgICAgICAgLyogTWVt
b3J5IFJhbmdlIGxlbmd0aCAqLworICAgICAgICB1bnNpZ25lZCBzaG9ydCBjYWNoaW5nOyAvKiBt
ZW1vcnkgY2FjaGUgYXR0cmlidXRlICovCisgICAgICAgIHVuc2lnbmVkIHNob3J0IHdyaXRlX3By
b3RlY3Q7ICAgLyogbWVtb3J5IHJlYWQvd3JpdGUgYXR0cmlidXRlICovCisgICAgICAgIHVuc2ln
bmVkIGludCBlbmFibGVkOjE7Cit9OworCitzdHJ1Y3QgYWNwaV9tZW1vcnlfZGV2aWNlIHsKKyAg
ICAgICAgc3RydWN0IGFjcGlfZGV2aWNlICpkZXZpY2U7CisgICAgICAgIHVuc2lnbmVkIGludCBz
dGF0ZTsgICAgIC8qIFN0YXRlIG9mIHRoZSBtZW1vcnkgZGV2aWNlICovCisgICAgICAgIHN0cnVj
dCBsaXN0X2hlYWQgcmVzX2xpc3Q7Cit9OworI2VuZGlmCisKICNlbmRpZiAvKl9fQUNQSV9EUklW
RVJTX0hfXyovCi0tIAoxLjYuNS42Cgo=

--_002_DE8DF0795D48FD4CA783C40EC829233597AASHSMSX101ccrcorpint_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--_002_DE8DF0795D48FD4CA783C40EC829233597AASHSMSX101ccrcorpint_--


From xen-devel-bounces@lists.xensource.com Fri Dec 23 10:36:50 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 Dec 2011 10: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.xensource.com>)
	id 1Re2UT-0007jY-18; Fri, 23 Dec 2011 10:36:41 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1Re2US-0007jF-2T
	for xen-devel@lists.xensource.com; Fri, 23 Dec 2011 10:36:40 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1324636592!7749275!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDMwMDk1NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29550 invoked from network); 23 Dec 2011 10:36:33 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-12.tower-21.messagelabs.com with SMTP;
	23 Dec 2011 10:36:33 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga102.fm.intel.com with ESMTP; 23 Dec 2011 02:36:32 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208,223";a="99640813"
Received: from pgsmsx601.gar.corp.intel.com ([10.221.43.69])
	by fmsmga001.fm.intel.com with ESMTP; 23 Dec 2011 02:36:31 -0800
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	pgsmsx601.gar.corp.intel.com (10.221.43.69) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Fri, 23 Dec 2011 18:36:30 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.38]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.223]) with mapi id
	14.01.0355.002; Fri, 23 Dec 2011 18:36:29 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: "konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
Thread-Topic: [PATCH 05/10] xen/acpi: Move acpi_memory_info definition to
	public
Thread-Index: AczBXrpnWJj7owNBS3CwTrfqrXT0pA==
Date: Fri, 23 Dec 2011 10:36:28 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC829233597AA@SHSMSX101.ccr.corp.intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
Content-Type: multipart/mixed;
	boundary="_002_DE8DF0795D48FD4CA783C40EC829233597AASHSMSX101ccrcorpint_"
MIME-Version: 1.0
Cc: "Brown, Len" <len.brown@intel.com>,
	"jeremy.fitzhardinge@citrix.com" <jeremy.fitzhardinge@citrix.com>,
	"Jiang, Yunhong" <yunhong.jiang@intel.com>, "Shan, 
	Haitao" <haitao.shan@intel.com>,
	Kernel development list <linux-kernel@vger.kernel.org>, "Zhao,
	Yakui" <yakui.zhao@intel.com>, "Luck, Tony" <tony.luck@intel.com>, "Kleen,
	Andi" <andi.kleen@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: [Xen-devel] [PATCH 05/10] xen/acpi: Move acpi_memory_info
	definition to public
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--_002_DE8DF0795D48FD4CA783C40EC829233597AASHSMSX101ccrcorpint_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

>From 0172b1ce6a2ba70e739f968622d78ac1796813f9 Mon Sep 17 00:00:00 2001
From: Liu Jinsong <jinsong.liu@intel.com>
Date: Sun, 11 Dec 2011 17:25:35 +0800
Subject: [PATCH 05/10] xen/acpi: Move acpi_memory_info definition to public

This patch rebased from Jeremy's pvops commit
359e747e6260f105f750657917e1dc75f6427602

Move this definition to header file so that it can be used by dom0
memory hotadd logic also.

Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
Signed-off-by: Jiang, Yunhong <yunhong.jiang@intel.com>
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
---
 drivers/acpi/acpi_memhotplug.c |   15 ---------------
 include/acpi/acpi_drivers.h    |   21 +++++++++++++++++++++
 2 files changed, 21 insertions(+), 15 deletions(-)

diff --git a/drivers/acpi/acpi_memhotplug.c b/drivers/acpi/acpi_memhotplug.=
c
index d985713..e28e64d 100644
--- a/drivers/acpi/acpi_memhotplug.c
+++ b/drivers/acpi/acpi_memhotplug.c
@@ -71,21 +71,6 @@ static struct acpi_driver acpi_memory_device_driver =3D =
{
 		},
 };
=20
-struct acpi_memory_info {
-	struct list_head list;
-	u64 start_addr;		/* Memory Range start physical addr */
-	u64 length;		/* Memory Range length */
-	unsigned short caching;	/* memory cache attribute */
-	unsigned short write_protect;	/* memory read/write attribute */
-	unsigned int enabled:1;
-};
-
-struct acpi_memory_device {
-	struct acpi_device * device;
-	unsigned int state;	/* State of the memory device */
-	struct list_head res_list;
-};
-
 static int acpi_hotmem_initialized;
=20
 static acpi_status
diff --git a/include/acpi/acpi_drivers.h b/include/acpi/acpi_drivers.h
index e49c36d..833de75 100644
--- a/include/acpi/acpi_drivers.h
+++ b/include/acpi/acpi_drivers.h
@@ -154,4 +154,25 @@ static inline void unregister_hotplug_dock_device(acpi=
_handle handle)
 }
 #endif
=20
+/*------------------------------------------------------------------------=
--
+                                Memory
+  ------------------------------------------------------------------------=
-- */
+#if defined(CONFIG_ACPI_HOTPLUG_MEMORY) || \
+        defined(CONFIG_ACPI_HOTPLUG_MEMORY_MODULE)
+struct acpi_memory_info {
+        struct list_head list;
+        u64 start_addr;         /* Memory Range start physical addr */
+        u64 length;             /* Memory Range length */
+        unsigned short caching; /* memory cache attribute */
+        unsigned short write_protect;   /* memory read/write attribute */
+        unsigned int enabled:1;
+};
+
+struct acpi_memory_device {
+        struct acpi_device *device;
+        unsigned int state;     /* State of the memory device */
+        struct list_head res_list;
+};
+#endif
+
 #endif /*__ACPI_DRIVERS_H__*/
--=20
1.6.5.6

--_002_DE8DF0795D48FD4CA783C40EC829233597AASHSMSX101ccrcorpint_
Content-Type: application/octet-stream;
	name="0005-xen-acpi-Move-acpi_memory_info-definition-to-public.patch"
Content-Description: 0005-xen-acpi-Move-acpi_memory_info-definition-to-public.patch
Content-Disposition: attachment;
	filename="0005-xen-acpi-Move-acpi_memory_info-definition-to-public.patch";
	size=2702; creation-date="Wed, 14 Dec 2011 15:20:15 GMT";
	modification-date="Wed, 14 Dec 2011 15:03:34 GMT"
Content-Transfer-Encoding: base64

RnJvbSAwMTcyYjFjZTZhMmJhNzBlNzM5Zjk2ODYyMmQ3OGFjMTc5NjgxM2Y5IE1vbiBTZXAgMTcg
MDA6MDA6MDAgMjAwMQpGcm9tOiBMaXUgSmluc29uZyA8amluc29uZy5saXVAaW50ZWwuY29tPgpE
YXRlOiBTdW4sIDExIERlYyAyMDExIDE3OjI1OjM1ICswODAwClN1YmplY3Q6IFtQQVRDSCAwNS8x
MF0geGVuL2FjcGk6IE1vdmUgYWNwaV9tZW1vcnlfaW5mbyBkZWZpbml0aW9uIHRvIHB1YmxpYwoK
VGhpcyBwYXRjaCByZWJhc2VkIGZyb20gSmVyZW15J3MgcHZvcHMgY29tbWl0CjM1OWU3NDdlNjI2
MGYxMDVmNzUwNjU3OTE3ZTFkYzc1ZjY0Mjc2MDIKCk1vdmUgdGhpcyBkZWZpbml0aW9uIHRvIGhl
YWRlciBmaWxlIHNvIHRoYXQgaXQgY2FuIGJlIHVzZWQgYnkgZG9tMAptZW1vcnkgaG90YWRkIGxv
Z2ljIGFsc28uCgpTaWduZWQtb2ZmLWJ5OiBMaXUsIEppbnNvbmcgPGppbnNvbmcubGl1QGludGVs
LmNvbT4KU2lnbmVkLW9mZi1ieTogSmlhbmcsIFl1bmhvbmcgPHl1bmhvbmcuamlhbmdAaW50ZWwu
Y29tPgpTaWduZWQtb2ZmLWJ5OiBKZXJlbXkgRml0emhhcmRpbmdlIDxqZXJlbXkuZml0emhhcmRp
bmdlQGNpdHJpeC5jb20+Ci0tLQogZHJpdmVycy9hY3BpL2FjcGlfbWVtaG90cGx1Zy5jIHwgICAx
NSAtLS0tLS0tLS0tLS0tLS0KIGluY2x1ZGUvYWNwaS9hY3BpX2RyaXZlcnMuaCAgICB8ICAgMjEg
KysrKysrKysrKysrKysrKysrKysrCiAyIGZpbGVzIGNoYW5nZWQsIDIxIGluc2VydGlvbnMoKyks
IDE1IGRlbGV0aW9ucygtKQoKZGlmZiAtLWdpdCBhL2RyaXZlcnMvYWNwaS9hY3BpX21lbWhvdHBs
dWcuYyBiL2RyaXZlcnMvYWNwaS9hY3BpX21lbWhvdHBsdWcuYwppbmRleCBkOTg1NzEzLi5lMjhl
NjRkIDEwMDY0NAotLS0gYS9kcml2ZXJzL2FjcGkvYWNwaV9tZW1ob3RwbHVnLmMKKysrIGIvZHJp
dmVycy9hY3BpL2FjcGlfbWVtaG90cGx1Zy5jCkBAIC03MSwyMSArNzEsNiBAQCBzdGF0aWMgc3Ry
dWN0IGFjcGlfZHJpdmVyIGFjcGlfbWVtb3J5X2RldmljZV9kcml2ZXIgPSB7CiAJCX0sCiB9Owog
Ci1zdHJ1Y3QgYWNwaV9tZW1vcnlfaW5mbyB7Ci0Jc3RydWN0IGxpc3RfaGVhZCBsaXN0OwotCXU2
NCBzdGFydF9hZGRyOwkJLyogTWVtb3J5IFJhbmdlIHN0YXJ0IHBoeXNpY2FsIGFkZHIgKi8KLQl1
NjQgbGVuZ3RoOwkJLyogTWVtb3J5IFJhbmdlIGxlbmd0aCAqLwotCXVuc2lnbmVkIHNob3J0IGNh
Y2hpbmc7CS8qIG1lbW9yeSBjYWNoZSBhdHRyaWJ1dGUgKi8KLQl1bnNpZ25lZCBzaG9ydCB3cml0
ZV9wcm90ZWN0OwkvKiBtZW1vcnkgcmVhZC93cml0ZSBhdHRyaWJ1dGUgKi8KLQl1bnNpZ25lZCBp
bnQgZW5hYmxlZDoxOwotfTsKLQotc3RydWN0IGFjcGlfbWVtb3J5X2RldmljZSB7Ci0Jc3RydWN0
IGFjcGlfZGV2aWNlICogZGV2aWNlOwotCXVuc2lnbmVkIGludCBzdGF0ZTsJLyogU3RhdGUgb2Yg
dGhlIG1lbW9yeSBkZXZpY2UgKi8KLQlzdHJ1Y3QgbGlzdF9oZWFkIHJlc19saXN0OwotfTsKLQog
c3RhdGljIGludCBhY3BpX2hvdG1lbV9pbml0aWFsaXplZDsKIAogc3RhdGljIGFjcGlfc3RhdHVz
CmRpZmYgLS1naXQgYS9pbmNsdWRlL2FjcGkvYWNwaV9kcml2ZXJzLmggYi9pbmNsdWRlL2FjcGkv
YWNwaV9kcml2ZXJzLmgKaW5kZXggZTQ5YzM2ZC4uODMzZGU3NSAxMDA2NDQKLS0tIGEvaW5jbHVk
ZS9hY3BpL2FjcGlfZHJpdmVycy5oCisrKyBiL2luY2x1ZGUvYWNwaS9hY3BpX2RyaXZlcnMuaApA
QCAtMTU0LDQgKzE1NCwyNSBAQCBzdGF0aWMgaW5saW5lIHZvaWQgdW5yZWdpc3Rlcl9ob3RwbHVn
X2RvY2tfZGV2aWNlKGFjcGlfaGFuZGxlIGhhbmRsZSkKIH0KICNlbmRpZgogCisvKi0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIE1lbW9yeQorICAtLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLSAqLworI2lmIGRlZmluZWQoQ09ORklHX0FDUElfSE9UUExVR19NRU1PUlkp
IHx8IFwKKyAgICAgICAgZGVmaW5lZChDT05GSUdfQUNQSV9IT1RQTFVHX01FTU9SWV9NT0RVTEUp
CitzdHJ1Y3QgYWNwaV9tZW1vcnlfaW5mbyB7CisgICAgICAgIHN0cnVjdCBsaXN0X2hlYWQgbGlz
dDsKKyAgICAgICAgdTY0IHN0YXJ0X2FkZHI7ICAgICAgICAgLyogTWVtb3J5IFJhbmdlIHN0YXJ0
IHBoeXNpY2FsIGFkZHIgKi8KKyAgICAgICAgdTY0IGxlbmd0aDsgICAgICAgICAgICAgLyogTWVt
b3J5IFJhbmdlIGxlbmd0aCAqLworICAgICAgICB1bnNpZ25lZCBzaG9ydCBjYWNoaW5nOyAvKiBt
ZW1vcnkgY2FjaGUgYXR0cmlidXRlICovCisgICAgICAgIHVuc2lnbmVkIHNob3J0IHdyaXRlX3By
b3RlY3Q7ICAgLyogbWVtb3J5IHJlYWQvd3JpdGUgYXR0cmlidXRlICovCisgICAgICAgIHVuc2ln
bmVkIGludCBlbmFibGVkOjE7Cit9OworCitzdHJ1Y3QgYWNwaV9tZW1vcnlfZGV2aWNlIHsKKyAg
ICAgICAgc3RydWN0IGFjcGlfZGV2aWNlICpkZXZpY2U7CisgICAgICAgIHVuc2lnbmVkIGludCBz
dGF0ZTsgICAgIC8qIFN0YXRlIG9mIHRoZSBtZW1vcnkgZGV2aWNlICovCisgICAgICAgIHN0cnVj
dCBsaXN0X2hlYWQgcmVzX2xpc3Q7Cit9OworI2VuZGlmCisKICNlbmRpZiAvKl9fQUNQSV9EUklW
RVJTX0hfXyovCi0tIAoxLjYuNS42Cgo=

--_002_DE8DF0795D48FD4CA783C40EC829233597AASHSMSX101ccrcorpint_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--_002_DE8DF0795D48FD4CA783C40EC829233597AASHSMSX101ccrcorpint_--


From xen-devel-bounces@lists.xensource.com Fri Dec 23 10:43:33 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 Dec 2011 10:43:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Re2at-00080s-1O; Fri, 23 Dec 2011 10:43:19 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1Re2ar-00080n-Qk
	for xen-devel@lists.xensource.com; Fri, 23 Dec 2011 10:43:18 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1324636991!8560567!1
X-Originating-IP: [134.134.136.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjQgPT4gMzE5NTY1\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9971 invoked from network); 23 Dec 2011 10:43:11 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-7.tower-216.messagelabs.com with SMTP;
	23 Dec 2011 10:43:11 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga102.jf.intel.com with ESMTP; 23 Dec 2011 02:43:10 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.67,352,1309762800"; d="scan'208";a="89714714"
Received: from pgsmsx601.gar.corp.intel.com ([10.221.43.69])
	by orsmga001.jf.intel.com with ESMTP; 23 Dec 2011 02:43:09 -0800
Received: from pgsmsx102.gar.corp.intel.com (10.221.44.80) by
	pgsmsx601.gar.corp.intel.com (10.221.43.69) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Fri, 23 Dec 2011 18:43:09 +0800
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	PGSMSX102.gar.corp.intel.com (10.221.44.80) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Fri, 23 Dec 2011 18:43:08 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.38]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.223]) with mapi id
	14.01.0355.002; Fri, 23 Dec 2011 18:43:07 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Thread-Topic: [PATCH 00/10] Linux 3.1.0 Xen RAS rebase
Thread-Index: AczBXKB0mag++cqVSzS+PvJp33blKQAAi9dg
Date: Fri, 23 Dec 2011 10:43:07 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC829233597FC@SHSMSX101.ccr.corp.intel.com>
References: <DE8DF0795D48FD4CA783C40EC82923359674@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <DE8DF0795D48FD4CA783C40EC82923359674@SHSMSX101.ccr.corp.intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH 00/10] Linux 3.1.0 Xen RAS rebase
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Re-send the patches, adding cc LKML, acpi, mca, cpu/memory hotadd maintainers/contributors according to Konrad's suggestions.
Sorry for bothering you, you can simply ignore my former patches.

Thanks,
Jinsong

Liu, Jinsong wrote:
> Recently we did dom0 Xen RAS rebase work, mainly involve xen
> interface at kernel for following features: 1). mce
> 2). cpu online/offline
> 3). cpu hotadd
> 4). memory hotadd
> 
> Basically it rebased from Jeremy's pvops (2.6.32), to Konrad's pvops
> (3.1.0, branch "devel/acpi-cpufreq.v3") patch 1: for mcelog logic
> patch 2: for dom0 vmce
> patch 3: for cpu sysfs and cpu online/offline
> patch 4: for cpu hotadd
> patch 5: for memory hotadd prepare work
> patch 6: for memory hotadd
> patch 7: for cpu hotadd prepare work
> patch 8: complement cpu hotadd lacked at Konrad's tree
> patch 9: update PM logic
> patch 10: upate cpu online/offline logic
> 
> 
> Thanks,
> Jinsong--
> To unsubscribe from this list: send the line "unsubscribe
> linux-kernel" in 
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 23 10:43:33 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 Dec 2011 10:43:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Re2at-00080s-1O; Fri, 23 Dec 2011 10:43:19 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1Re2ar-00080n-Qk
	for xen-devel@lists.xensource.com; Fri, 23 Dec 2011 10:43:18 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1324636991!8560567!1
X-Originating-IP: [134.134.136.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjQgPT4gMzE5NTY1\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9971 invoked from network); 23 Dec 2011 10:43:11 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-7.tower-216.messagelabs.com with SMTP;
	23 Dec 2011 10:43:11 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga102.jf.intel.com with ESMTP; 23 Dec 2011 02:43:10 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.67,352,1309762800"; d="scan'208";a="89714714"
Received: from pgsmsx601.gar.corp.intel.com ([10.221.43.69])
	by orsmga001.jf.intel.com with ESMTP; 23 Dec 2011 02:43:09 -0800
Received: from pgsmsx102.gar.corp.intel.com (10.221.44.80) by
	pgsmsx601.gar.corp.intel.com (10.221.43.69) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Fri, 23 Dec 2011 18:43:09 +0800
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	PGSMSX102.gar.corp.intel.com (10.221.44.80) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Fri, 23 Dec 2011 18:43:08 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.38]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.223]) with mapi id
	14.01.0355.002; Fri, 23 Dec 2011 18:43:07 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Thread-Topic: [PATCH 00/10] Linux 3.1.0 Xen RAS rebase
Thread-Index: AczBXKB0mag++cqVSzS+PvJp33blKQAAi9dg
Date: Fri, 23 Dec 2011 10:43:07 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC829233597FC@SHSMSX101.ccr.corp.intel.com>
References: <DE8DF0795D48FD4CA783C40EC82923359674@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <DE8DF0795D48FD4CA783C40EC82923359674@SHSMSX101.ccr.corp.intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH 00/10] Linux 3.1.0 Xen RAS rebase
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Re-send the patches, adding cc LKML, acpi, mca, cpu/memory hotadd maintainers/contributors according to Konrad's suggestions.
Sorry for bothering you, you can simply ignore my former patches.

Thanks,
Jinsong

Liu, Jinsong wrote:
> Recently we did dom0 Xen RAS rebase work, mainly involve xen
> interface at kernel for following features: 1). mce
> 2). cpu online/offline
> 3). cpu hotadd
> 4). memory hotadd
> 
> Basically it rebased from Jeremy's pvops (2.6.32), to Konrad's pvops
> (3.1.0, branch "devel/acpi-cpufreq.v3") patch 1: for mcelog logic
> patch 2: for dom0 vmce
> patch 3: for cpu sysfs and cpu online/offline
> patch 4: for cpu hotadd
> patch 5: for memory hotadd prepare work
> patch 6: for memory hotadd
> patch 7: for cpu hotadd prepare work
> patch 8: complement cpu hotadd lacked at Konrad's tree
> patch 9: update PM logic
> patch 10: upate cpu online/offline logic
> 
> 
> Thanks,
> Jinsong--
> To unsubscribe from this list: send the line "unsubscribe
> linux-kernel" in 
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 23 10:45:31 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 Dec 2011 10:45:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Re2co-00085x-KF; Fri, 23 Dec 2011 10:45:18 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Re2cm-00085f-R0
	for xen-devel@lists.xensource.com; Fri, 23 Dec 2011 10:45:17 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1324637110!8496951!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODI2MQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10200 invoked from network); 23 Dec 2011 10:45:10 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Dec 2011 10:45:10 -0000
X-IronPort-AV: E=Sophos;i="4.71,398,1320624000"; 
   d="scan'208";a="9651611"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Dec 2011 10:45:10 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 23 Dec 2011 10:45:10 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau =?ISO-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
Date: Fri, 23 Dec 2011 10:45:10 +0000
In-Reply-To: <CAPLaKK5uXfXH7swFia21zkbNjuM+8Dfnk3OehFCNwvgfKzwn2A@mail.gmail.com>
References: <CB1901CD.36815%keir@xen.org>
	<1324569166.7877.93.camel@zakaz.uk.xensource.com>
	<CAPLaKK7icOx97OcL=QTd=ciudso3TNFJWdsQagZHboSruQ2rYA@mail.gmail.com>
	<1324574818.13113.0.camel@dagon.hellion.org.uk>
	<CAPLaKK5uXfXH7swFia21zkbNjuM+8Dfnk3OehFCNwvgfKzwn2A@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1324637110.7877.139.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH v2] libxl: add support for yajl 2.x
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gRnJpLCAyMDExLTEyLTIzIGF0IDA4OjIyICswMDAwLCBSb2dlciBQYXUgTW9ubsOpIHdyb3Rl
Ogo+IDIwMTEvMTIvMjIgSWFuIENhbXBiZWxsIDxJYW4uQ2FtcGJlbGxAY2l0cml4LmNvbT46Cj4g
PiBJJ20gbm90IGdvaW5nIHRvIGhhdmUgdGltZSBpbiB0aGUgbmVhciBmdXR1cmUuCj4gCj4gSSB3
aWxsIHRyeSB0byB0YWtlIGEgbG9vayBhdCB0aGUgYXV0b2dvbyBzdHVmZiBhbmQgc2V0IHNvbWV0
aGluZyB1cC4KClRoYW5rcyEKCkknbSBub3Qgc3VyZSBpZiB3ZSBoYXZlIGFueSByZXNpZGVudCBh
dXRvdG9vbHMgZXhwZXJ0cyBidXQgSSdtIHN1cmUgd2UKY2FuIG11ZGRsZSB0aHJvdWdoLgoKSWFu
LgoKPiAKPiA+IFdvdWxkIGl0IGJlIHN1ZmZpY2llbnQgdG8gaGF2ZSB0aGUgc3R1ZmYgaW4gdG9v
bHMvY2hlY2sgY3JlYXRlIGEKPiA+IGNvbmZpZy5oIGFzIHdlbGwgYXMgZG9pbmcgdGhlIGNoZWNr
cz8gTWlnaHQgbmVlZCBhIGJpdCBvZiBNYWtlZmlsZSBtYWdpYwo+ID4gdG8gYmUgc3VyZSB0aGF0
IGNoZWNrIGlzIGFsd2F5cyBydW4/Cj4gCj4gU2luY2Ugd2UgaGF2ZSB0byBjaGFuZ2UgdGhpbmdz
LCBJJ20gbm90IHN1cmUgaWYgaXQgaXMgYmVzdCB0byBtb3ZlIHRvCj4gc29tZXRoaW5nIG1vcmUg
c3RhbmRhcmQsIGxpa2UgYXV0b3Rvb2xzLgoKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0
cy54ZW5zb3VyY2UuY29tCmh0dHA6Ly9saXN0cy54ZW5zb3VyY2UuY29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Fri Dec 23 10:45:31 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 Dec 2011 10:45:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Re2co-00085x-KF; Fri, 23 Dec 2011 10:45:18 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Re2cm-00085f-R0
	for xen-devel@lists.xensource.com; Fri, 23 Dec 2011 10:45:17 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1324637110!8496951!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODI2MQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10200 invoked from network); 23 Dec 2011 10:45:10 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Dec 2011 10:45:10 -0000
X-IronPort-AV: E=Sophos;i="4.71,398,1320624000"; 
   d="scan'208";a="9651611"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Dec 2011 10:45:10 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 23 Dec 2011 10:45:10 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau =?ISO-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
Date: Fri, 23 Dec 2011 10:45:10 +0000
In-Reply-To: <CAPLaKK5uXfXH7swFia21zkbNjuM+8Dfnk3OehFCNwvgfKzwn2A@mail.gmail.com>
References: <CB1901CD.36815%keir@xen.org>
	<1324569166.7877.93.camel@zakaz.uk.xensource.com>
	<CAPLaKK7icOx97OcL=QTd=ciudso3TNFJWdsQagZHboSruQ2rYA@mail.gmail.com>
	<1324574818.13113.0.camel@dagon.hellion.org.uk>
	<CAPLaKK5uXfXH7swFia21zkbNjuM+8Dfnk3OehFCNwvgfKzwn2A@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1324637110.7877.139.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH v2] libxl: add support for yajl 2.x
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gRnJpLCAyMDExLTEyLTIzIGF0IDA4OjIyICswMDAwLCBSb2dlciBQYXUgTW9ubsOpIHdyb3Rl
Ogo+IDIwMTEvMTIvMjIgSWFuIENhbXBiZWxsIDxJYW4uQ2FtcGJlbGxAY2l0cml4LmNvbT46Cj4g
PiBJJ20gbm90IGdvaW5nIHRvIGhhdmUgdGltZSBpbiB0aGUgbmVhciBmdXR1cmUuCj4gCj4gSSB3
aWxsIHRyeSB0byB0YWtlIGEgbG9vayBhdCB0aGUgYXV0b2dvbyBzdHVmZiBhbmQgc2V0IHNvbWV0
aGluZyB1cC4KClRoYW5rcyEKCkknbSBub3Qgc3VyZSBpZiB3ZSBoYXZlIGFueSByZXNpZGVudCBh
dXRvdG9vbHMgZXhwZXJ0cyBidXQgSSdtIHN1cmUgd2UKY2FuIG11ZGRsZSB0aHJvdWdoLgoKSWFu
LgoKPiAKPiA+IFdvdWxkIGl0IGJlIHN1ZmZpY2llbnQgdG8gaGF2ZSB0aGUgc3R1ZmYgaW4gdG9v
bHMvY2hlY2sgY3JlYXRlIGEKPiA+IGNvbmZpZy5oIGFzIHdlbGwgYXMgZG9pbmcgdGhlIGNoZWNr
cz8gTWlnaHQgbmVlZCBhIGJpdCBvZiBNYWtlZmlsZSBtYWdpYwo+ID4gdG8gYmUgc3VyZSB0aGF0
IGNoZWNrIGlzIGFsd2F5cyBydW4/Cj4gCj4gU2luY2Ugd2UgaGF2ZSB0byBjaGFuZ2UgdGhpbmdz
LCBJJ20gbm90IHN1cmUgaWYgaXQgaXMgYmVzdCB0byBtb3ZlIHRvCj4gc29tZXRoaW5nIG1vcmUg
c3RhbmRhcmQsIGxpa2UgYXV0b3Rvb2xzLgoKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0
cy54ZW5zb3VyY2UuY29tCmh0dHA6Ly9saXN0cy54ZW5zb3VyY2UuY29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Fri Dec 23 10:50:22 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 Dec 2011 10:50:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Re2hV-0008JG-Db; Fri, 23 Dec 2011 10:50:09 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Re2hU-0008J0-24
	for xen-devel@lists.xensource.com; Fri, 23 Dec 2011 10:50:08 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1324637401!8406126!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODI2MQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5132 invoked from network); 23 Dec 2011 10:50:02 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Dec 2011 10:50:02 -0000
X-IronPort-AV: E=Sophos;i="4.71,398,1320624000"; 
   d="scan'208";a="9651768"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Dec 2011 10:50:01 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 23 Dec 2011 10:50:01 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Keir Fraser <keir.xen@gmail.com>
Date: Fri, 23 Dec 2011 10:50:01 +0000
In-Reply-To: <CB19EF04.27B93%keir.xen@gmail.com>
References: <CB19EF04.27B93%keir.xen@gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1324637401.7877.144.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Roger Pau =?ISO-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Keir
	\(Xen.org\)" <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH v2] libxl: add support for yajl 2.x
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gRnJpLCAyMDExLTEyLTIzIGF0IDA4OjQwICswMDAwLCBLZWlyIEZyYXNlciB3cm90ZToKPiBP
biAyMy8xMi8yMDExIDA4OjIyLCAiUm9nZXIgUGF1IE1vbm7DqSIgPHJvZ2VyLnBhdUBlbnRlbC51
cGMuZWR1PiB3cm90ZToKPiAKPiA+IDIwMTEvMTIvMjIgSWFuIENhbXBiZWxsIDxJYW4uQ2FtcGJl
bGxAY2l0cml4LmNvbT46Cj4gPj4gSSdtIG5vdCBnb2luZyB0byBoYXZlIHRpbWUgaW4gdGhlIG5l
YXIgZnV0dXJlLgo+ID4gCj4gPiBJIHdpbGwgdHJ5IHRvIHRha2UgYSBsb29rIGF0IHRoZSBhdXRv
Z29vIHN0dWZmIGFuZCBzZXQgc29tZXRoaW5nIHVwLgo+ID4gCj4gPj4gV291bGQgaXQgYmUgc3Vm
ZmljaWVudCB0byBoYXZlIHRoZSBzdHVmZiBpbiB0b29scy9jaGVjayBjcmVhdGUgYQo+ID4+IGNv
bmZpZy5oIGFzIHdlbGwgYXMgZG9pbmcgdGhlIGNoZWNrcz8gTWlnaHQgbmVlZCBhIGJpdCBvZiBN
YWtlZmlsZSBtYWdpYwo+ID4+IHRvIGJlIHN1cmUgdGhhdCBjaGVjayBpcyBhbHdheXMgcnVuPwo+
ID4gCj4gPiBTaW5jZSB3ZSBoYXZlIHRvIGNoYW5nZSB0aGluZ3MsIEknbSBub3Qgc3VyZSBpZiBp
dCBpcyBiZXN0IHRvIG1vdmUgdG8KPiA+IHNvbWV0aGluZyBtb3JlIHN0YW5kYXJkLCBsaWtlIGF1
dG90b29scy4KPiAKPiBXZSBzaG91bGQgcHJvYmFibHkganVzdCBkbyBhdXRvdG9vbHMsIGlmIHNv
bWVvbmUgaGFzIHRoZSB0aW1lIHRvIGludmVzdCBpbgo+IHRoZSBpbml0aWFsIGltcGxlbWVudGF0
aW9uIHdvcmsgdG8gdXNlIGl0LgoKWW91IGFyZSB0aGlua2luZyBvZiBhdXRvY29uZiBvbmx5IHJp
Z2h0PyBXZSBkb24ndCB3YW50IHRvIGdvIHRoZSB3aG9sZQpob2cgYW5kIHN0YXJ0IHVzaW5nIGF1
dG9tYWtlIGFuZCBhbGwgdGhlIG90aGVyIGJvYmJpbnMgKGxpYnRvb2wgZXRjKSwgZG8Kd2U/CgpJ
YW4uCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVu
LWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuc291cmNlLmNvbQpodHRwOi8v
bGlzdHMueGVuc291cmNlLmNvbS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Fri Dec 23 10:50:22 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 Dec 2011 10:50:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Re2hV-0008JG-Db; Fri, 23 Dec 2011 10:50:09 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Re2hU-0008J0-24
	for xen-devel@lists.xensource.com; Fri, 23 Dec 2011 10:50:08 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1324637401!8406126!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODI2MQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5132 invoked from network); 23 Dec 2011 10:50:02 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Dec 2011 10:50:02 -0000
X-IronPort-AV: E=Sophos;i="4.71,398,1320624000"; 
   d="scan'208";a="9651768"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Dec 2011 10:50:01 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 23 Dec 2011 10:50:01 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Keir Fraser <keir.xen@gmail.com>
Date: Fri, 23 Dec 2011 10:50:01 +0000
In-Reply-To: <CB19EF04.27B93%keir.xen@gmail.com>
References: <CB19EF04.27B93%keir.xen@gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1324637401.7877.144.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Roger Pau =?ISO-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Keir
	\(Xen.org\)" <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH v2] libxl: add support for yajl 2.x
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gRnJpLCAyMDExLTEyLTIzIGF0IDA4OjQwICswMDAwLCBLZWlyIEZyYXNlciB3cm90ZToKPiBP
biAyMy8xMi8yMDExIDA4OjIyLCAiUm9nZXIgUGF1IE1vbm7DqSIgPHJvZ2VyLnBhdUBlbnRlbC51
cGMuZWR1PiB3cm90ZToKPiAKPiA+IDIwMTEvMTIvMjIgSWFuIENhbXBiZWxsIDxJYW4uQ2FtcGJl
bGxAY2l0cml4LmNvbT46Cj4gPj4gSSdtIG5vdCBnb2luZyB0byBoYXZlIHRpbWUgaW4gdGhlIG5l
YXIgZnV0dXJlLgo+ID4gCj4gPiBJIHdpbGwgdHJ5IHRvIHRha2UgYSBsb29rIGF0IHRoZSBhdXRv
Z29vIHN0dWZmIGFuZCBzZXQgc29tZXRoaW5nIHVwLgo+ID4gCj4gPj4gV291bGQgaXQgYmUgc3Vm
ZmljaWVudCB0byBoYXZlIHRoZSBzdHVmZiBpbiB0b29scy9jaGVjayBjcmVhdGUgYQo+ID4+IGNv
bmZpZy5oIGFzIHdlbGwgYXMgZG9pbmcgdGhlIGNoZWNrcz8gTWlnaHQgbmVlZCBhIGJpdCBvZiBN
YWtlZmlsZSBtYWdpYwo+ID4+IHRvIGJlIHN1cmUgdGhhdCBjaGVjayBpcyBhbHdheXMgcnVuPwo+
ID4gCj4gPiBTaW5jZSB3ZSBoYXZlIHRvIGNoYW5nZSB0aGluZ3MsIEknbSBub3Qgc3VyZSBpZiBp
dCBpcyBiZXN0IHRvIG1vdmUgdG8KPiA+IHNvbWV0aGluZyBtb3JlIHN0YW5kYXJkLCBsaWtlIGF1
dG90b29scy4KPiAKPiBXZSBzaG91bGQgcHJvYmFibHkganVzdCBkbyBhdXRvdG9vbHMsIGlmIHNv
bWVvbmUgaGFzIHRoZSB0aW1lIHRvIGludmVzdCBpbgo+IHRoZSBpbml0aWFsIGltcGxlbWVudGF0
aW9uIHdvcmsgdG8gdXNlIGl0LgoKWW91IGFyZSB0aGlua2luZyBvZiBhdXRvY29uZiBvbmx5IHJp
Z2h0PyBXZSBkb24ndCB3YW50IHRvIGdvIHRoZSB3aG9sZQpob2cgYW5kIHN0YXJ0IHVzaW5nIGF1
dG9tYWtlIGFuZCBhbGwgdGhlIG90aGVyIGJvYmJpbnMgKGxpYnRvb2wgZXRjKSwgZG8Kd2U/CgpJ
YW4uCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVu
LWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuc291cmNlLmNvbQpodHRwOi8v
bGlzdHMueGVuc291cmNlLmNvbS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Fri Dec 23 10:58:40 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 Dec 2011 10:58:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Re2pW-0008Un-D1; Fri, 23 Dec 2011 10:58:26 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1Re2pU-0008Ui-UP
	for xen-devel@lists.xensource.com; Fri, 23 Dec 2011 10:58:25 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1324637898!9902532!1
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6720 invoked from network); 23 Dec 2011 10:58:18 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Dec 2011 10:58:18 -0000
Received: by wgbds11 with SMTP id ds11so14791708wgb.24
	for <xen-devel@lists.xensource.com>;
	Fri, 23 Dec 2011 02:58:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=nE83q5aGqOx7GuTtcCH7ktsV3sINsXsgzMPGZi/Kg5M=;
	b=pW4VWa0ldrqofZNG+YyKaGpWBPxswNXYpiBLyo4Mn/1gdWDYvzBS4hx1xtfgenfWyQ
	h8Spnh3o9n14mCEBwd1xePRsIoiaPecbKAOVDKll3YInAEFwpOZeL8YInQ5DkUUtrDF8
	QZHeg/QBCQ4HO7rKsDLC0infivKOSpoYF8P3Q=
Received: by 10.227.204.66 with SMTP id fl2mr13878090wbb.16.1324637898375;
	Fri, 23 Dec 2011 02:58:18 -0800 (PST)
Received: from [192.168.1.3] (host81-152-17-11.range81-152.btcentralplus.com.
	[81.152.17.11])
	by mx.google.com with ESMTPS id ep13sm13156826wbb.8.2011.12.23.02.58.14
	(version=SSLv3 cipher=OTHER); Fri, 23 Dec 2011 02:58:17 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Fri, 23 Dec 2011 10:58:13 +0000
From: Keir Fraser <keir@xen.org>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <CB1A0F45.3685D%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH v2] libxl: add support for yajl 2.x
Thread-Index: AczBYcPtH0MTs1a3PUmOQr5gDFLS6A==
In-Reply-To: <1324637401.7877.144.camel@zakaz.uk.xensource.com>
Mime-version: 1.0
Cc: Roger Pau =?ISO-8859-1?B?TW9ubuk=?= <roger.pau@entel.upc.edu>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH v2] libxl: add support for yajl 2.x
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 23/12/2011 10:50, "Ian Campbell" <Ian.Campbell@citrix.com> wrote:

> On Fri, 2011-12-23 at 08:40 +0000, Keir Fraser wrote:
>> On 23/12/2011 08:22, "Roger Pau Monn=E9" <roger.pau@entel.upc.edu> wrote:
>> =

>>> 2011/12/22 Ian Campbell <Ian.Campbell@citrix.com>:
>>>> I'm not going to have time in the near future.
>>> =

>>> I will try to take a look at the autogoo stuff and set something up.
>>> =

>>>> Would it be sufficient to have the stuff in tools/check create a
>>>> config.h as well as doing the checks? Might need a bit of Makefile mag=
ic
>>>> to be sure that check is always run?
>>> =

>>> Since we have to change things, I'm not sure if it is best to move to
>>> something more standard, like autotools.
>> =

>> We should probably just do autotools, if someone has the time to invest =
in
>> the initial implementation work to use it.
> =

> You are thinking of autoconf only right? We don't want to go the whole
> hog and start using automake and all the other bobbins (libtool etc), do
> we?

You're probably right.

> Ian.
> =




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 23 10:58:40 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 Dec 2011 10:58:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Re2pW-0008Un-D1; Fri, 23 Dec 2011 10:58:26 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1Re2pU-0008Ui-UP
	for xen-devel@lists.xensource.com; Fri, 23 Dec 2011 10:58:25 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1324637898!9902532!1
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6720 invoked from network); 23 Dec 2011 10:58:18 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Dec 2011 10:58:18 -0000
Received: by wgbds11 with SMTP id ds11so14791708wgb.24
	for <xen-devel@lists.xensource.com>;
	Fri, 23 Dec 2011 02:58:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=nE83q5aGqOx7GuTtcCH7ktsV3sINsXsgzMPGZi/Kg5M=;
	b=pW4VWa0ldrqofZNG+YyKaGpWBPxswNXYpiBLyo4Mn/1gdWDYvzBS4hx1xtfgenfWyQ
	h8Spnh3o9n14mCEBwd1xePRsIoiaPecbKAOVDKll3YInAEFwpOZeL8YInQ5DkUUtrDF8
	QZHeg/QBCQ4HO7rKsDLC0infivKOSpoYF8P3Q=
Received: by 10.227.204.66 with SMTP id fl2mr13878090wbb.16.1324637898375;
	Fri, 23 Dec 2011 02:58:18 -0800 (PST)
Received: from [192.168.1.3] (host81-152-17-11.range81-152.btcentralplus.com.
	[81.152.17.11])
	by mx.google.com with ESMTPS id ep13sm13156826wbb.8.2011.12.23.02.58.14
	(version=SSLv3 cipher=OTHER); Fri, 23 Dec 2011 02:58:17 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Fri, 23 Dec 2011 10:58:13 +0000
From: Keir Fraser <keir@xen.org>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <CB1A0F45.3685D%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH v2] libxl: add support for yajl 2.x
Thread-Index: AczBYcPtH0MTs1a3PUmOQr5gDFLS6A==
In-Reply-To: <1324637401.7877.144.camel@zakaz.uk.xensource.com>
Mime-version: 1.0
Cc: Roger Pau =?ISO-8859-1?B?TW9ubuk=?= <roger.pau@entel.upc.edu>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH v2] libxl: add support for yajl 2.x
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 23/12/2011 10:50, "Ian Campbell" <Ian.Campbell@citrix.com> wrote:

> On Fri, 2011-12-23 at 08:40 +0000, Keir Fraser wrote:
>> On 23/12/2011 08:22, "Roger Pau Monn=E9" <roger.pau@entel.upc.edu> wrote:
>> =

>>> 2011/12/22 Ian Campbell <Ian.Campbell@citrix.com>:
>>>> I'm not going to have time in the near future.
>>> =

>>> I will try to take a look at the autogoo stuff and set something up.
>>> =

>>>> Would it be sufficient to have the stuff in tools/check create a
>>>> config.h as well as doing the checks? Might need a bit of Makefile mag=
ic
>>>> to be sure that check is always run?
>>> =

>>> Since we have to change things, I'm not sure if it is best to move to
>>> something more standard, like autotools.
>> =

>> We should probably just do autotools, if someone has the time to invest =
in
>> the initial implementation work to use it.
> =

> You are thinking of autoconf only right? We don't want to go the whole
> hog and start using automake and all the other bobbins (libtool etc), do
> we?

You're probably right.

> Ian.
> =




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 23 11:04:04 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 Dec 2011 11:04:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Re2ui-0000Il-AR; Fri, 23 Dec 2011 11:03:48 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <samuel.thibault@ens-lyon.org>) id 1Re2ug-0000If-Mg
	for xen-devel@lists.xensource.com; Fri, 23 Dec 2011 11:03:46 +0000
X-Env-Sender: samuel.thibault@ens-lyon.org
X-Msg-Ref: server-9.tower-27.messagelabs.com!1324638185!57844861!1
X-Originating-IP: [80.67.169.19]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12802 invoked from network); 23 Dec 2011 11:03:05 -0000
Received: from solo.fdn.fr (HELO solo.fdn.fr) (80.67.169.19)
	by server-9.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Dec 2011 11:03:05 -0000
Received: from type.ipv6 (youpi.is-a-geek.org [80.67.176.89])
	(using TLSv1 with cipher AES256-SHA (256/256 bits))
	(Client did not present a certificate)
	by solo.fdn.fr (Postfix) with ESMTPS id A462E442AB;
	Fri, 23 Dec 2011 12:03:41 +0100 (CET)
Received: from samy by type.ipv6 with local (Exim 4.77)
	(envelope-from <samuel.thibault@ens-lyon.org>)
	id 1Re2ua-0000yl-O6; Fri, 23 Dec 2011 12:03:40 +0100
Date: Fri, 23 Dec 2011 12:03:40 +0100
From: Samuel Thibault <samuel.thibault@ens-lyon.org>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20111223110340.GM4075@type.famille.thibault.fr>
Mail-Followup-To: Samuel Thibault <samuel.thibault@ens-lyon.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Jan Beulich <JBeulich@suse.com>,
	"roger.pau@entel.upc.edu" <roger.pau@entel.upc.edu>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
References: <CAPLaKK506e57uCvSdkjCqkUs6AS6ty4Efa+Ekhrczu=OA+TCHw@mail.gmail.com>
	<4EF44A100200007800069B5A@nat28.tlf.novell.com>
	<1324632355.7877.96.camel@zakaz.uk.xensource.com>
	<4EF458BA0200007800069BB4@nat28.tlf.novell.com>
	<1324633398.7877.109.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1324633398.7877.109.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21+34 (58baf7c9f32f) (2010-12-30)
Cc: "roger.pau@entel.upc.edu" <roger.pau@entel.upc.edu>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] Stubdom build problem in 4.1.2 but not in
 xen-unstable
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell, le Fri 23 Dec 2011 09:43:17 +0000, a =E9crit :
> On Fri, 2011-12-23 at 09:32 +0000, Jan Beulich wrote:
> > >>> On 23.12.11 at 10:25, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > > I thought "inline" was just a hint so it seems odd that gcc would err=
or
> > > out.
> > =

> > That's what -Winline is for - to tell you that your intention to have a
> > function inlined wasn't fulfilled. If one asks for this warning,
> > occasionally having the compiler emit it is the result. The question to
> > me is what the purpose was to enable that warning in the first place.
> =

> It seems to be only extras/mini-os which uses it and it came from the
> first changeset, copy Samuel in case he remembers why.

Well, I didn't even know Xen at the time :)

Sun Jan 25 03:00:54 2004
>From Kip Macy, we now are stricter when compiling the mini os.

So I don't think there is any particular reason, and it's probably not
worth the trouble keeping it.

Samuel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 23 11:04:04 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 Dec 2011 11:04:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Re2ui-0000Il-AR; Fri, 23 Dec 2011 11:03:48 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <samuel.thibault@ens-lyon.org>) id 1Re2ug-0000If-Mg
	for xen-devel@lists.xensource.com; Fri, 23 Dec 2011 11:03:46 +0000
X-Env-Sender: samuel.thibault@ens-lyon.org
X-Msg-Ref: server-9.tower-27.messagelabs.com!1324638185!57844861!1
X-Originating-IP: [80.67.169.19]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12802 invoked from network); 23 Dec 2011 11:03:05 -0000
Received: from solo.fdn.fr (HELO solo.fdn.fr) (80.67.169.19)
	by server-9.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Dec 2011 11:03:05 -0000
Received: from type.ipv6 (youpi.is-a-geek.org [80.67.176.89])
	(using TLSv1 with cipher AES256-SHA (256/256 bits))
	(Client did not present a certificate)
	by solo.fdn.fr (Postfix) with ESMTPS id A462E442AB;
	Fri, 23 Dec 2011 12:03:41 +0100 (CET)
Received: from samy by type.ipv6 with local (Exim 4.77)
	(envelope-from <samuel.thibault@ens-lyon.org>)
	id 1Re2ua-0000yl-O6; Fri, 23 Dec 2011 12:03:40 +0100
Date: Fri, 23 Dec 2011 12:03:40 +0100
From: Samuel Thibault <samuel.thibault@ens-lyon.org>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20111223110340.GM4075@type.famille.thibault.fr>
Mail-Followup-To: Samuel Thibault <samuel.thibault@ens-lyon.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Jan Beulich <JBeulich@suse.com>,
	"roger.pau@entel.upc.edu" <roger.pau@entel.upc.edu>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
References: <CAPLaKK506e57uCvSdkjCqkUs6AS6ty4Efa+Ekhrczu=OA+TCHw@mail.gmail.com>
	<4EF44A100200007800069B5A@nat28.tlf.novell.com>
	<1324632355.7877.96.camel@zakaz.uk.xensource.com>
	<4EF458BA0200007800069BB4@nat28.tlf.novell.com>
	<1324633398.7877.109.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1324633398.7877.109.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21+34 (58baf7c9f32f) (2010-12-30)
Cc: "roger.pau@entel.upc.edu" <roger.pau@entel.upc.edu>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] Stubdom build problem in 4.1.2 but not in
 xen-unstable
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell, le Fri 23 Dec 2011 09:43:17 +0000, a =E9crit :
> On Fri, 2011-12-23 at 09:32 +0000, Jan Beulich wrote:
> > >>> On 23.12.11 at 10:25, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > > I thought "inline" was just a hint so it seems odd that gcc would err=
or
> > > out.
> > =

> > That's what -Winline is for - to tell you that your intention to have a
> > function inlined wasn't fulfilled. If one asks for this warning,
> > occasionally having the compiler emit it is the result. The question to
> > me is what the purpose was to enable that warning in the first place.
> =

> It seems to be only extras/mini-os which uses it and it came from the
> first changeset, copy Samuel in case he remembers why.

Well, I didn't even know Xen at the time :)

Sun Jan 25 03:00:54 2004
>From Kip Macy, we now are stricter when compiling the mini os.

So I don't think there is any particular reason, and it's probably not
worth the trouble keeping it.

Samuel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 23 11:10:16 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 Dec 2011 11: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.xensource.com>)
	id 1Re30g-0000T8-5W; Fri, 23 Dec 2011 11:09:58 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Re30f-0000Sw-HO
	for xen-devel@lists.xensource.com; Fri, 23 Dec 2011 11:09:57 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1324638591!8357911!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODI2MQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13812 invoked from network); 23 Dec 2011 11:09:51 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Dec 2011 11:09:51 -0000
X-IronPort-AV: E=Sophos;i="4.71,398,1320624000"; 
   d="scan'208";a="9652719"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Dec 2011 11:09:40 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 23 Dec 2011 11:09:40 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Samuel Thibault <samuel.thibault@ens-lyon.org>
Date: Fri, 23 Dec 2011 11:09:40 +0000
In-Reply-To: <20111223110340.GM4075@type.famille.thibault.fr>
References: <CAPLaKK506e57uCvSdkjCqkUs6AS6ty4Efa+Ekhrczu=OA+TCHw@mail.gmail.com>
	<4EF44A100200007800069B5A@nat28.tlf.novell.com>
	<1324632355.7877.96.camel@zakaz.uk.xensource.com>
	<4EF458BA0200007800069BB4@nat28.tlf.novell.com>
	<1324633398.7877.109.camel@zakaz.uk.xensource.com>
	<20111223110340.GM4075@type.famille.thibault.fr>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1324638580.7877.150.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "roger.pau@entel.upc.edu" <roger.pau@entel.upc.edu>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] Stubdom build problem in 4.1.2 but not in
 xen-unstable
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gRnJpLCAyMDExLTEyLTIzIGF0IDExOjAzICswMDAwLCBTYW11ZWwgVGhpYmF1bHQgd3JvdGU6
Cj4gSWFuIENhbXBiZWxsLCBsZSBGcmkgMjMgRGVjIDIwMTEgMDk6NDM6MTcgKzAwMDAsIGEgw6lj
cml0IDoKPiA+IE9uIEZyaSwgMjAxMS0xMi0yMyBhdCAwOTozMiArMDAwMCwgSmFuIEJldWxpY2gg
d3JvdGU6Cj4gPiA+ID4+PiBPbiAyMy4xMi4xMSBhdCAxMDoyNSwgSWFuIENhbXBiZWxsIDxJYW4u
Q2FtcGJlbGxAY2l0cml4LmNvbT4gd3JvdGU6Cj4gPiA+ID4gSSB0aG91Z2h0ICJpbmxpbmUiIHdh
cyBqdXN0IGEgaGludCBzbyBpdCBzZWVtcyBvZGQgdGhhdCBnY2Mgd291bGQgZXJyb3IKPiA+ID4g
PiBvdXQuCj4gPiA+IAo+ID4gPiBUaGF0J3Mgd2hhdCAtV2lubGluZSBpcyBmb3IgLSB0byB0ZWxs
IHlvdSB0aGF0IHlvdXIgaW50ZW50aW9uIHRvIGhhdmUgYQo+ID4gPiBmdW5jdGlvbiBpbmxpbmVk
IHdhc24ndCBmdWxmaWxsZWQuIElmIG9uZSBhc2tzIGZvciB0aGlzIHdhcm5pbmcsCj4gPiA+IG9j
Y2FzaW9uYWxseSBoYXZpbmcgdGhlIGNvbXBpbGVyIGVtaXQgaXQgaXMgdGhlIHJlc3VsdC4gVGhl
IHF1ZXN0aW9uIHRvCj4gPiA+IG1lIGlzIHdoYXQgdGhlIHB1cnBvc2Ugd2FzIHRvIGVuYWJsZSB0
aGF0IHdhcm5pbmcgaW4gdGhlIGZpcnN0IHBsYWNlLgo+ID4gCj4gPiBJdCBzZWVtcyB0byBiZSBv
bmx5IGV4dHJhcy9taW5pLW9zIHdoaWNoIHVzZXMgaXQgYW5kIGl0IGNhbWUgZnJvbSB0aGUKPiA+
IGZpcnN0IGNoYW5nZXNldCwgY29weSBTYW11ZWwgaW4gY2FzZSBoZSByZW1lbWJlcnMgd2h5Lgo+
IAo+IFdlbGwsIEkgZGlkbid0IGV2ZW4ga25vdyBYZW4gYXQgdGhlIHRpbWUgOikKClNvcnJ5LCBJ
IGZvcmdvdCB0aGF0IHN0dWJkb21zICE9IG1pbmlvcy4KCj4gCj4gU3VuIEphbiAyNSAwMzowMDo1
NCAyMDA0Cj4gRnJvbSBLaXAgTWFjeSwgd2Ugbm93IGFyZSBzdHJpY3RlciB3aGVuIGNvbXBpbGlu
ZyB0aGUgbWluaSBvcy4KPiAKPiBTbyBJIGRvbid0IHRoaW5rIHRoZXJlIGlzIGFueSBwYXJ0aWN1
bGFyIHJlYXNvbiwgYW5kIGl0J3MgcHJvYmFibHkgbm90Cj4gd29ydGggdGhlIHRyb3VibGUga2Vl
cGluZyBpdC4KPiAKPiBTYW11ZWwKCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVu
c291cmNlLmNvbQpodHRwOi8vbGlzdHMueGVuc291cmNlLmNvbS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Fri Dec 23 11:10:16 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 Dec 2011 11: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.xensource.com>)
	id 1Re30g-0000T8-5W; Fri, 23 Dec 2011 11:09:58 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Re30f-0000Sw-HO
	for xen-devel@lists.xensource.com; Fri, 23 Dec 2011 11:09:57 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1324638591!8357911!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODI2MQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13812 invoked from network); 23 Dec 2011 11:09:51 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Dec 2011 11:09:51 -0000
X-IronPort-AV: E=Sophos;i="4.71,398,1320624000"; 
   d="scan'208";a="9652719"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Dec 2011 11:09:40 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 23 Dec 2011 11:09:40 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Samuel Thibault <samuel.thibault@ens-lyon.org>
Date: Fri, 23 Dec 2011 11:09:40 +0000
In-Reply-To: <20111223110340.GM4075@type.famille.thibault.fr>
References: <CAPLaKK506e57uCvSdkjCqkUs6AS6ty4Efa+Ekhrczu=OA+TCHw@mail.gmail.com>
	<4EF44A100200007800069B5A@nat28.tlf.novell.com>
	<1324632355.7877.96.camel@zakaz.uk.xensource.com>
	<4EF458BA0200007800069BB4@nat28.tlf.novell.com>
	<1324633398.7877.109.camel@zakaz.uk.xensource.com>
	<20111223110340.GM4075@type.famille.thibault.fr>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1324638580.7877.150.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "roger.pau@entel.upc.edu" <roger.pau@entel.upc.edu>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] Stubdom build problem in 4.1.2 but not in
 xen-unstable
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gRnJpLCAyMDExLTEyLTIzIGF0IDExOjAzICswMDAwLCBTYW11ZWwgVGhpYmF1bHQgd3JvdGU6
Cj4gSWFuIENhbXBiZWxsLCBsZSBGcmkgMjMgRGVjIDIwMTEgMDk6NDM6MTcgKzAwMDAsIGEgw6lj
cml0IDoKPiA+IE9uIEZyaSwgMjAxMS0xMi0yMyBhdCAwOTozMiArMDAwMCwgSmFuIEJldWxpY2gg
d3JvdGU6Cj4gPiA+ID4+PiBPbiAyMy4xMi4xMSBhdCAxMDoyNSwgSWFuIENhbXBiZWxsIDxJYW4u
Q2FtcGJlbGxAY2l0cml4LmNvbT4gd3JvdGU6Cj4gPiA+ID4gSSB0aG91Z2h0ICJpbmxpbmUiIHdh
cyBqdXN0IGEgaGludCBzbyBpdCBzZWVtcyBvZGQgdGhhdCBnY2Mgd291bGQgZXJyb3IKPiA+ID4g
PiBvdXQuCj4gPiA+IAo+ID4gPiBUaGF0J3Mgd2hhdCAtV2lubGluZSBpcyBmb3IgLSB0byB0ZWxs
IHlvdSB0aGF0IHlvdXIgaW50ZW50aW9uIHRvIGhhdmUgYQo+ID4gPiBmdW5jdGlvbiBpbmxpbmVk
IHdhc24ndCBmdWxmaWxsZWQuIElmIG9uZSBhc2tzIGZvciB0aGlzIHdhcm5pbmcsCj4gPiA+IG9j
Y2FzaW9uYWxseSBoYXZpbmcgdGhlIGNvbXBpbGVyIGVtaXQgaXQgaXMgdGhlIHJlc3VsdC4gVGhl
IHF1ZXN0aW9uIHRvCj4gPiA+IG1lIGlzIHdoYXQgdGhlIHB1cnBvc2Ugd2FzIHRvIGVuYWJsZSB0
aGF0IHdhcm5pbmcgaW4gdGhlIGZpcnN0IHBsYWNlLgo+ID4gCj4gPiBJdCBzZWVtcyB0byBiZSBv
bmx5IGV4dHJhcy9taW5pLW9zIHdoaWNoIHVzZXMgaXQgYW5kIGl0IGNhbWUgZnJvbSB0aGUKPiA+
IGZpcnN0IGNoYW5nZXNldCwgY29weSBTYW11ZWwgaW4gY2FzZSBoZSByZW1lbWJlcnMgd2h5Lgo+
IAo+IFdlbGwsIEkgZGlkbid0IGV2ZW4ga25vdyBYZW4gYXQgdGhlIHRpbWUgOikKClNvcnJ5LCBJ
IGZvcmdvdCB0aGF0IHN0dWJkb21zICE9IG1pbmlvcy4KCj4gCj4gU3VuIEphbiAyNSAwMzowMDo1
NCAyMDA0Cj4gRnJvbSBLaXAgTWFjeSwgd2Ugbm93IGFyZSBzdHJpY3RlciB3aGVuIGNvbXBpbGlu
ZyB0aGUgbWluaSBvcy4KPiAKPiBTbyBJIGRvbid0IHRoaW5rIHRoZXJlIGlzIGFueSBwYXJ0aWN1
bGFyIHJlYXNvbiwgYW5kIGl0J3MgcHJvYmFibHkgbm90Cj4gd29ydGggdGhlIHRyb3VibGUga2Vl
cGluZyBpdC4KPiAKPiBTYW11ZWwKCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVu
c291cmNlLmNvbQpodHRwOi8vbGlzdHMueGVuc291cmNlLmNvbS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Fri Dec 23 11:18:02 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 Dec 2011 11:18:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Re38G-0000gC-AM; Fri, 23 Dec 2011 11:17:48 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1Re38E-0000g7-Nw
	for xen-devel@lists.xensource.com; Fri, 23 Dec 2011 11:17:46 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1324639059!6625223!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjU2NjQ=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7030 invoked from network); 23 Dec 2011 11:17:40 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Dec 2011 11:17:40 -0000
X-IronPort-AV: E=Sophos;i="4.71,398,1320642000"; d="scan'208";a="175273348"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Dec 2011 06:17:38 -0500
Received: from [10.80.2.18] (10.80.2.18) by FTLPMAILMX01.citrite.net
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Fri, 23 Dec 2011
	06:17:38 -0500
Message-ID: <4EF46351.8080301@citrix.com>
Date: Fri, 23 Dec 2011 11:17:37 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.23) Gecko/20110921 Lightning/1.0b2 Thunderbird/3.1.15
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>, Keir Fraser <keir.xen@gmail.com>
References: <patchbomb.1324575382@andrewcoop.uk.xensource.com>
	<f571dc8e43687c6027d1.1324575383@andrewcoop.uk.xensource.com>
	<4EF44B130200007800069B5D@nat28.tlf.novell.com>
In-Reply-To: <4EF44B130200007800069B5D@nat28.tlf.novell.com>
X-Enigmail-Version: 1.1.2
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 1 of 3] KEXEC: Add new hypercall to fix
 64/32bit truncation errors. v2
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 23/12/11 08:34, Jan Beulich wrote:
>>>> On 22.12.11 at 18:36, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>> Currently, KEXEC_CMD_kexec_get_range in compat mode, or with 32bit
>> Xen, will truncate 64bit pointers to 32bits, leading to problems on
>> machines with more than 4GiB of RAM.  As 32bit dom0 kernels tend to be
>> PAE capable, this is especially wasteful, as most structures currently
>> limited to <4GiB could easily be <64GiB instead.
>>
>> Therefore, introduce a new hypercall 'KEXEC_CMD_kexec64_get_range'
>> which passes similar information as KEXEC_CMD_kexec_get_range, but
>> which uses a structure with explicitly specified field widths, causing
>> it to be identical in the compat and regular case.  This new
>> structure, xen_kexec64_range_t, will be the same as xen_kexec_range_t
>> if Xen is compiled for x86_64, but will still use 64bit integers if
>> Xen is compiled for x86_32.
>>
>> To fix 32bit Xen which uses 32bit integers for addresses and sizes,
>> change the internals to use xen_kexec64_range_t which will use 64bit
>> integers instead.  This also involves changing several casts to
>> explicitly use uint64_ts rather than unsigned longs.
> Just for the record - I continue to be opposed to doing this for the
> 32-bit hypervisor. All relevant allocations are below 4G there, so
> there's simply no need to decrease code readability for no benefit.
>
> Jan

I don't mind reducing the scope to ignore the 32bit Xen case.  Any
object Keir?

<snip>

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 23 11:18:02 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 Dec 2011 11:18:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Re38G-0000gC-AM; Fri, 23 Dec 2011 11:17:48 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1Re38E-0000g7-Nw
	for xen-devel@lists.xensource.com; Fri, 23 Dec 2011 11:17:46 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1324639059!6625223!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjU2NjQ=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7030 invoked from network); 23 Dec 2011 11:17:40 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Dec 2011 11:17:40 -0000
X-IronPort-AV: E=Sophos;i="4.71,398,1320642000"; d="scan'208";a="175273348"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Dec 2011 06:17:38 -0500
Received: from [10.80.2.18] (10.80.2.18) by FTLPMAILMX01.citrite.net
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Fri, 23 Dec 2011
	06:17:38 -0500
Message-ID: <4EF46351.8080301@citrix.com>
Date: Fri, 23 Dec 2011 11:17:37 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.23) Gecko/20110921 Lightning/1.0b2 Thunderbird/3.1.15
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>, Keir Fraser <keir.xen@gmail.com>
References: <patchbomb.1324575382@andrewcoop.uk.xensource.com>
	<f571dc8e43687c6027d1.1324575383@andrewcoop.uk.xensource.com>
	<4EF44B130200007800069B5D@nat28.tlf.novell.com>
In-Reply-To: <4EF44B130200007800069B5D@nat28.tlf.novell.com>
X-Enigmail-Version: 1.1.2
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 1 of 3] KEXEC: Add new hypercall to fix
 64/32bit truncation errors. v2
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 23/12/11 08:34, Jan Beulich wrote:
>>>> On 22.12.11 at 18:36, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>> Currently, KEXEC_CMD_kexec_get_range in compat mode, or with 32bit
>> Xen, will truncate 64bit pointers to 32bits, leading to problems on
>> machines with more than 4GiB of RAM.  As 32bit dom0 kernels tend to be
>> PAE capable, this is especially wasteful, as most structures currently
>> limited to <4GiB could easily be <64GiB instead.
>>
>> Therefore, introduce a new hypercall 'KEXEC_CMD_kexec64_get_range'
>> which passes similar information as KEXEC_CMD_kexec_get_range, but
>> which uses a structure with explicitly specified field widths, causing
>> it to be identical in the compat and regular case.  This new
>> structure, xen_kexec64_range_t, will be the same as xen_kexec_range_t
>> if Xen is compiled for x86_64, but will still use 64bit integers if
>> Xen is compiled for x86_32.
>>
>> To fix 32bit Xen which uses 32bit integers for addresses and sizes,
>> change the internals to use xen_kexec64_range_t which will use 64bit
>> integers instead.  This also involves changing several casts to
>> explicitly use uint64_ts rather than unsigned longs.
> Just for the record - I continue to be opposed to doing this for the
> 32-bit hypervisor. All relevant allocations are below 4G there, so
> there's simply no need to decrease code readability for no benefit.
>
> Jan

I don't mind reducing the scope to ignore the 32bit Xen case.  Any
object Keir?

<snip>

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 23 11:18:59 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 Dec 2011 11: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.xensource.com>)
	id 1Re399-0000j5-OX; Fri, 23 Dec 2011 11:18:43 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1Re397-0000ic-Uq
	for xen-devel@lists.xensource.com; Fri, 23 Dec 2011 11:18:42 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1324639114!6679192!1
X-Originating-IP: [209.85.210.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18165 invoked from network); 23 Dec 2011 11:18:35 -0000
Received: from mail-pz0-f43.google.com (HELO mail-pz0-f43.google.com)
	(209.85.210.43)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Dec 2011 11:18:35 -0000
Received: by daec6 with SMTP id c6so37133912dae.30
	for <xen-devel@lists.xensource.com>;
	Fri, 23 Dec 2011 03:18:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=q87nZP6b9x/Dz8a/QQo0VP08t0L9kzg0Fx8ua1AsMTE=;
	b=QOy1BFODXT5yo65v2JIC33OpBz0XQi+Lj7DNornd9l3CgV3bE2zj1EA36EIIHUWx+f
	PqvwWC5WeS5J9m6yW8t93kfLURZte50FUNVxYuwVxLXNsvj9kUoWeXknkf3FxmZlcM5f
	TeG6v4JsXcASp+Adz/FkzRaR2HMGmujseAZ1M=
MIME-Version: 1.0
Received: by 10.68.190.226 with SMTP id gt2mr30555266pbc.112.1324639113658;
	Fri, 23 Dec 2011 03:18:33 -0800 (PST)
Received: by 10.142.47.17 with HTTP; Fri, 23 Dec 2011 03:18:33 -0800 (PST)
In-Reply-To: <1324637401.7877.144.camel@zakaz.uk.xensource.com>
References: <CB19EF04.27B93%keir.xen@gmail.com>
	<1324637401.7877.144.camel@zakaz.uk.xensource.com>
Date: Fri, 23 Dec 2011 12:18:33 +0100
X-Google-Sender-Auth: MvjHHejbYxrNr_TDDJU7KE85nk8
Message-ID: <CAPLaKK636GZKTaM_VpbWKxZb8pz+LEh51SU2PbKAztL_TjWGgg@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Keir Fraser <keir.xen@gmail.com>, "Keir \(Xen.org\)" <keir@xen.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH v2] libxl: add support for yajl 2.x
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

MjAxMS8xMi8yMyBJYW4gQ2FtcGJlbGwgPElhbi5DYW1wYmVsbEBjaXRyaXguY29tPjoKPiBPbiBG
cmksIDIwMTEtMTItMjMgYXQgMDg6NDAgKzAwMDAsIEtlaXIgRnJhc2VyIHdyb3RlOgo+PiBPbiAy
My8xMi8yMDExIDA4OjIyLCAiUm9nZXIgUGF1IE1vbm7DqSIgPHJvZ2VyLnBhdUBlbnRlbC51cGMu
ZWR1PiB3cm90ZToKPj4KPj4gPiAyMDExLzEyLzIyIElhbiBDYW1wYmVsbCA8SWFuLkNhbXBiZWxs
QGNpdHJpeC5jb20+Ogo+PiA+PiBJJ20gbm90IGdvaW5nIHRvIGhhdmUgdGltZSBpbiB0aGUgbmVh
ciBmdXR1cmUuCj4+ID4KPj4gPiBJIHdpbGwgdHJ5IHRvIHRha2UgYSBsb29rIGF0IHRoZSBhdXRv
Z29vIHN0dWZmIGFuZCBzZXQgc29tZXRoaW5nIHVwLgo+PiA+Cj4+ID4+IFdvdWxkIGl0IGJlIHN1
ZmZpY2llbnQgdG8gaGF2ZSB0aGUgc3R1ZmYgaW4gdG9vbHMvY2hlY2sgY3JlYXRlIGEKPj4gPj4g
Y29uZmlnLmggYXMgd2VsbCBhcyBkb2luZyB0aGUgY2hlY2tzPyBNaWdodCBuZWVkIGEgYml0IG9m
IE1ha2VmaWxlIG1hZ2ljCj4+ID4+IHRvIGJlIHN1cmUgdGhhdCBjaGVjayBpcyBhbHdheXMgcnVu
Pwo+PiA+Cj4+ID4gU2luY2Ugd2UgaGF2ZSB0byBjaGFuZ2UgdGhpbmdzLCBJJ20gbm90IHN1cmUg
aWYgaXQgaXMgYmVzdCB0byBtb3ZlIHRvCj4+ID4gc29tZXRoaW5nIG1vcmUgc3RhbmRhcmQsIGxp
a2UgYXV0b3Rvb2xzLgo+Pgo+PiBXZSBzaG91bGQgcHJvYmFibHkganVzdCBkbyBhdXRvdG9vbHMs
IGlmIHNvbWVvbmUgaGFzIHRoZSB0aW1lIHRvIGludmVzdCBpbgo+PiB0aGUgaW5pdGlhbCBpbXBs
ZW1lbnRhdGlvbiB3b3JrIHRvIHVzZSBpdC4KPgo+IFlvdSBhcmUgdGhpbmtpbmcgb2YgYXV0b2Nv
bmYgb25seSByaWdodD8gV2UgZG9uJ3Qgd2FudCB0byBnbyB0aGUgd2hvbGUKPiBob2cgYW5kIHN0
YXJ0IHVzaW5nIGF1dG9tYWtlIGFuZCBhbGwgdGhlIG90aGVyIGJvYmJpbnMgKGxpYnRvb2wgZXRj
KSwgZG8KPiB3ZT8KCkkndmUgbmV2ZXIgdXNlZCBhdXRvdG9vbHMgYmVmb3JlLCBidXQgd2hhdCBJ
IHdhcyB0aGlua2luZyBvZiBpcyBhCnNpbXBsZSBjb25maWd1cmUgc2NyaXB0IHRoYXQgY3JlYXRl
cyBhIGNvbmZpZy5oIHdpdGggYWxsIHRoZSBuZWVkZWQKZGVmaW5lcyB0aGF0IHdlIGNhbiBpbmNs
dWRlIHdoZW4gbmVlZGVkLgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuc291cmNl
LmNvbQpodHRwOi8vbGlzdHMueGVuc291cmNlLmNvbS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Fri Dec 23 11:18:59 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 Dec 2011 11: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.xensource.com>)
	id 1Re399-0000j5-OX; Fri, 23 Dec 2011 11:18:43 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1Re397-0000ic-Uq
	for xen-devel@lists.xensource.com; Fri, 23 Dec 2011 11:18:42 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1324639114!6679192!1
X-Originating-IP: [209.85.210.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18165 invoked from network); 23 Dec 2011 11:18:35 -0000
Received: from mail-pz0-f43.google.com (HELO mail-pz0-f43.google.com)
	(209.85.210.43)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Dec 2011 11:18:35 -0000
Received: by daec6 with SMTP id c6so37133912dae.30
	for <xen-devel@lists.xensource.com>;
	Fri, 23 Dec 2011 03:18:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=q87nZP6b9x/Dz8a/QQo0VP08t0L9kzg0Fx8ua1AsMTE=;
	b=QOy1BFODXT5yo65v2JIC33OpBz0XQi+Lj7DNornd9l3CgV3bE2zj1EA36EIIHUWx+f
	PqvwWC5WeS5J9m6yW8t93kfLURZte50FUNVxYuwVxLXNsvj9kUoWeXknkf3FxmZlcM5f
	TeG6v4JsXcASp+Adz/FkzRaR2HMGmujseAZ1M=
MIME-Version: 1.0
Received: by 10.68.190.226 with SMTP id gt2mr30555266pbc.112.1324639113658;
	Fri, 23 Dec 2011 03:18:33 -0800 (PST)
Received: by 10.142.47.17 with HTTP; Fri, 23 Dec 2011 03:18:33 -0800 (PST)
In-Reply-To: <1324637401.7877.144.camel@zakaz.uk.xensource.com>
References: <CB19EF04.27B93%keir.xen@gmail.com>
	<1324637401.7877.144.camel@zakaz.uk.xensource.com>
Date: Fri, 23 Dec 2011 12:18:33 +0100
X-Google-Sender-Auth: MvjHHejbYxrNr_TDDJU7KE85nk8
Message-ID: <CAPLaKK636GZKTaM_VpbWKxZb8pz+LEh51SU2PbKAztL_TjWGgg@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Keir Fraser <keir.xen@gmail.com>, "Keir \(Xen.org\)" <keir@xen.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH v2] libxl: add support for yajl 2.x
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

MjAxMS8xMi8yMyBJYW4gQ2FtcGJlbGwgPElhbi5DYW1wYmVsbEBjaXRyaXguY29tPjoKPiBPbiBG
cmksIDIwMTEtMTItMjMgYXQgMDg6NDAgKzAwMDAsIEtlaXIgRnJhc2VyIHdyb3RlOgo+PiBPbiAy
My8xMi8yMDExIDA4OjIyLCAiUm9nZXIgUGF1IE1vbm7DqSIgPHJvZ2VyLnBhdUBlbnRlbC51cGMu
ZWR1PiB3cm90ZToKPj4KPj4gPiAyMDExLzEyLzIyIElhbiBDYW1wYmVsbCA8SWFuLkNhbXBiZWxs
QGNpdHJpeC5jb20+Ogo+PiA+PiBJJ20gbm90IGdvaW5nIHRvIGhhdmUgdGltZSBpbiB0aGUgbmVh
ciBmdXR1cmUuCj4+ID4KPj4gPiBJIHdpbGwgdHJ5IHRvIHRha2UgYSBsb29rIGF0IHRoZSBhdXRv
Z29vIHN0dWZmIGFuZCBzZXQgc29tZXRoaW5nIHVwLgo+PiA+Cj4+ID4+IFdvdWxkIGl0IGJlIHN1
ZmZpY2llbnQgdG8gaGF2ZSB0aGUgc3R1ZmYgaW4gdG9vbHMvY2hlY2sgY3JlYXRlIGEKPj4gPj4g
Y29uZmlnLmggYXMgd2VsbCBhcyBkb2luZyB0aGUgY2hlY2tzPyBNaWdodCBuZWVkIGEgYml0IG9m
IE1ha2VmaWxlIG1hZ2ljCj4+ID4+IHRvIGJlIHN1cmUgdGhhdCBjaGVjayBpcyBhbHdheXMgcnVu
Pwo+PiA+Cj4+ID4gU2luY2Ugd2UgaGF2ZSB0byBjaGFuZ2UgdGhpbmdzLCBJJ20gbm90IHN1cmUg
aWYgaXQgaXMgYmVzdCB0byBtb3ZlIHRvCj4+ID4gc29tZXRoaW5nIG1vcmUgc3RhbmRhcmQsIGxp
a2UgYXV0b3Rvb2xzLgo+Pgo+PiBXZSBzaG91bGQgcHJvYmFibHkganVzdCBkbyBhdXRvdG9vbHMs
IGlmIHNvbWVvbmUgaGFzIHRoZSB0aW1lIHRvIGludmVzdCBpbgo+PiB0aGUgaW5pdGlhbCBpbXBs
ZW1lbnRhdGlvbiB3b3JrIHRvIHVzZSBpdC4KPgo+IFlvdSBhcmUgdGhpbmtpbmcgb2YgYXV0b2Nv
bmYgb25seSByaWdodD8gV2UgZG9uJ3Qgd2FudCB0byBnbyB0aGUgd2hvbGUKPiBob2cgYW5kIHN0
YXJ0IHVzaW5nIGF1dG9tYWtlIGFuZCBhbGwgdGhlIG90aGVyIGJvYmJpbnMgKGxpYnRvb2wgZXRj
KSwgZG8KPiB3ZT8KCkkndmUgbmV2ZXIgdXNlZCBhdXRvdG9vbHMgYmVmb3JlLCBidXQgd2hhdCBJ
IHdhcyB0aGlua2luZyBvZiBpcyBhCnNpbXBsZSBjb25maWd1cmUgc2NyaXB0IHRoYXQgY3JlYXRl
cyBhIGNvbmZpZy5oIHdpdGggYWxsIHRoZSBuZWVkZWQKZGVmaW5lcyB0aGF0IHdlIGNhbiBpbmNs
dWRlIHdoZW4gbmVlZGVkLgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuc291cmNl
LmNvbQpodHRwOi8vbGlzdHMueGVuc291cmNlLmNvbS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Fri Dec 23 11:31:46 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 Dec 2011 11:31:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Re3LW-0001Aj-58; Fri, 23 Dec 2011 11:31:30 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Wang2@amd.com>) id 1Re3LT-00018I-R6
	for xen-devel@lists.xensource.com; Fri, 23 Dec 2011 11:31:28 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1324639881!8578587!1
X-Originating-IP: [213.199.154.144]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9133 invoked from network); 23 Dec 2011 11:31:21 -0000
Received: from db3ehsobe006.messaging.microsoft.com (HELO
	DB3EHSOBE006.bigfish.com) (213.199.154.144)
	by server-5.tower-216.messagelabs.com with AES128-SHA encrypted SMTP;
	23 Dec 2011 11:31:21 -0000
Received: from mail23-db3-R.bigfish.com (10.3.81.253) by
	DB3EHSOBE006.bigfish.com (10.3.84.26) with Microsoft SMTP Server id
	14.1.225.23; Fri, 23 Dec 2011 11:31:08 +0000
Received: from mail23-db3 (localhost [127.0.0.1])	by mail23-db3-R.bigfish.com
	(Postfix) with ESMTP id E7F7D60533;
	Fri, 23 Dec 2011 11:31:47 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzzz1202hzz8275bhz2dh668h839h944h)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
Received: from mail23-db3 (localhost.localdomain [127.0.0.1]) by mail23-db3
	(MessageSwitch) id 1324639907398226_30218;
	Fri, 23 Dec 2011 11:31:47 +0000 (UTC)
Received: from DB3EHSMHS007.bigfish.com (unknown [10.3.81.243])	by
	mail23-db3.bigfish.com (Postfix) with ESMTP id 487CB40045;
	Fri, 23 Dec 2011 11:31:47 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	DB3EHSMHS007.bigfish.com (10.3.87.107) with Microsoft SMTP Server id
	14.1.225.23; Fri, 23 Dec 2011 11:31:07 +0000
X-WSS-ID: 0LWNMO4-01-1GD-02
X-M-MSG: 
Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com
	[163.181.249.73])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2D9C1102809E;	Fri, 23 Dec 2011 05:31:15 -0600 (CST)
Received: from SAUSEXDAG02.amd.com (163.181.55.2) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Fri, 23 Dec 2011 05:31:34 -0600
Received: from storexhtp02.amd.com (172.24.4.4) by sausexdag02.amd.com
	(163.181.55.2) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Fri, 23 Dec 2011 05:31:16 -0600
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Fri, 23 Dec 2011
	06:30:43 -0500
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 02CE349C667; Fri, 23 Dec 2011
	11:30:43 +0000 (GMT)
Received: from gran.amd.com (gran.osrc.amd.com [165.204.15.57])	by
	mail.osrc.amd.com (Postfix) with ESMTP id A3752594882; Fri, 23 Dec 2011
	12:30:42 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: bb76ba2457e629d668c08e57f2168b13bdfb7930
Message-ID: <bb76ba2457e629d668c0.1324639761@gran.amd.com>
In-Reply-To: <patchbomb.1324639749@gran.amd.com>
References: <patchbomb.1324639749@gran.amd.com>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Fri, 23 Dec 2011 12:29:21 +0100
From: Wei Wang <wei.wang2@amd.com>
To: <JBeulich@suse.com>, <Ian.Jackson@eu.citrix.com>,
	<Ian.Campbell@citrix.com>, <keir@xen.org>
X-OriginatorOrg: amd.com
Cc: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 12 of 16] hvmloader: Build IVRS table
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Wei Wang <wei.wang2@amd.com>
# Date 1324569408 -3600
# Node ID bb76ba2457e629d668c08e57f2168b13bdfb7930
# Parent  b70cf1dcb110f79546f3efac3201a08d70c8b96e
hvmloader: Build IVRS table.
Signed-off-by: Wei Wang <wei.wang2@amd.com>

diff -r b70cf1dcb110 -r bb76ba2457e6 tools/firmware/hvmloader/acpi/acpi2_0.h
--- a/tools/firmware/hvmloader/acpi/acpi2_0.h	Thu Dec 22 16:56:45 2011 +0100
+++ b/tools/firmware/hvmloader/acpi/acpi2_0.h	Thu Dec 22 16:56:48 2011 +0100
@@ -389,6 +389,60 @@ struct acpi_20_madt_intsrcovr {
 #define ACPI_2_0_WAET_REVISION 0x01
 #define ACPI_1_0_FADT_REVISION 0x01
 
+#define IVRS_SIGNATURE ASCII32('I','V','R','S')
+#define IVRS_REVISION           1
+#define IVRS_VASIZE             64
+#define IVRS_PASIZE             52
+#define IVRS_GVASIZE            64
+
+#define IVHD_BLOCK_TYPE         0x10
+#define IVHD_FLAG_HTTUNEN       (1 << 0)
+#define IVHD_FLAG_PASSPW        (1 << 1)
+#define IVHD_FLAG_RESPASSPW     (1 << 2)
+#define IVHD_FLAG_ISOC          (1 << 3)
+#define IVHD_FLAG_IOTLBSUP      (1 << 4)
+#define IVHD_FLAG_COHERENT      (1 << 5)
+#define IVHD_FLAG_PREFSUP       (1 << 6)
+#define IVHD_FLAG_PPRSUP        (1 << 7)
+
+#define IVHD_EFR_GTSUP          (1 << 2)
+#define IVHD_EFR_IASUP          (1 << 5)
+
+#define IVHD_SELECT_4_BYTE      0x2
+
+struct ivrs_ivhd_block
+{
+    uint8_t    type;
+    uint8_t    flags;
+    uint16_t   length;
+    uint16_t   devid;
+    uint16_t   cap_offset;
+    uint64_t   iommu_base_addr;
+    uint16_t   pci_segment;
+    uint16_t   iommu_info;
+    uint32_t   reserved;
+};
+
+/* IVHD 4-byte device entries */
+struct ivrs_ivhd_device
+{
+   uint8_t  type;
+   uint16_t dev_id;
+   uint8_t  flags;
+};
+
+#define PT_DEV_MAX_NR           32
+#define IOMMU_CAP_OFFSET        0x40
+struct acpi_40_ivrs
+{
+    struct acpi_header                      header;
+    uint32_t                                iv_info;
+    uint32_t                                reserved[2];
+    struct ivrs_ivhd_block                  ivhd_block;
+    struct ivrs_ivhd_device                 ivhd_device[PT_DEV_MAX_NR];
+};
+
+
 #pragma pack ()
 
 struct acpi_config {
diff -r b70cf1dcb110 -r bb76ba2457e6 tools/firmware/hvmloader/acpi/build.c
--- a/tools/firmware/hvmloader/acpi/build.c	Thu Dec 22 16:56:45 2011 +0100
+++ b/tools/firmware/hvmloader/acpi/build.c	Thu Dec 22 16:56:48 2011 +0100
@@ -23,6 +23,8 @@
 #include "ssdt_pm.h"
 #include "../config.h"
 #include "../util.h"
+#include "../hypercall.h"
+#include <xen/hvm/params.h>
 
 #define align16(sz)        (((sz) + 15) & ~15)
 #define fixed_strcpy(d, s) strncpy((d), (s), sizeof(d))
@@ -198,6 +200,77 @@ static struct acpi_20_waet *construct_wa
     return waet;
 }
 
+extern uint32_t ptdev_bdf[PT_DEV_MAX_NR];
+extern uint32_t ptdev_nr;
+extern uint32_t iommu_bdf;
+static struct acpi_40_ivrs* construct_ivrs(void)
+{
+    struct acpi_40_ivrs *ivrs;
+    uint64_t mmio;
+    struct ivrs_ivhd_block *ivhd;
+    struct ivrs_ivhd_device *dev_entry;
+    struct xen_hvm_param p;
+
+    if (ptdev_nr == 0) return NULL;
+
+    ivrs = mem_alloc(sizeof(*ivrs), 16);
+    if (!ivrs) return NULL;
+
+    memset(ivrs, 0, sizeof(*ivrs));
+
+    /* initialize acpi header */
+    ivrs->header.signature = IVRS_SIGNATURE;
+    ivrs->header.revision = IVRS_REVISION;
+    fixed_strcpy(ivrs->header.oem_id, ACPI_OEM_ID);
+    fixed_strcpy(ivrs->header.oem_table_id, ACPI_OEM_TABLE_ID);
+
+    ivrs->header.oem_revision = ACPI_OEM_REVISION;
+    ivrs->header.creator_id   = ACPI_CREATOR_ID;
+    ivrs->header.creator_revision = ACPI_CREATOR_REVISION;
+
+    ivrs->header.length = sizeof(*ivrs);
+
+    /* initialize IVHD Block */
+    ivhd = &ivrs->ivhd_block;
+    ivrs->iv_info = (IVRS_VASIZE << 15) | (IVRS_PASIZE << 8) |
+                    (IVRS_GVASIZE << 5);
+
+    ivhd->type          = IVHD_BLOCK_TYPE;
+    ivhd->flags         = IVHD_FLAG_PPRSUP | IVHD_FLAG_IOTLBSUP;
+    ivhd->devid         = iommu_bdf;
+    ivhd->cap_offset    = IOMMU_CAP_OFFSET;
+
+    /*reserve 32K IOMMU MMIO space */
+    mmio = virt_to_phys(mem_alloc(0x8000, 0x1000));
+    if (!mmio) return NULL;
+
+    p.domid = DOMID_SELF;
+    p.index = HVM_PARAM_IOMMU_BASE;
+    p.value = mmio;
+
+    /* Return non-zero if IOMMUv2 hardware is not avaliable */
+    if ( hypercall_hvm_op(HVMOP_set_param, &p) )
+        return NULL;
+
+    ivhd->iommu_base_addr = mmio;
+    ivhd->reserved = IVHD_EFR_IASUP | IVHD_EFR_GTSUP;
+
+    /* Build IVHD device entries */
+    dev_entry = ivrs->ivhd_device;
+    for ( int i = 0; i < ptdev_nr; i++ )
+    {
+        dev_entry[i].type   = IVHD_SELECT_4_BYTE;
+        dev_entry[i].dev_id = ptdev_bdf[i];
+        dev_entry[i].flags  = 0;
+    }
+
+    ivhd->length = sizeof(*ivhd) + sizeof(*dev_entry) * PT_DEV_MAX_NR;
+    set_checksum(ivrs, offsetof(struct acpi_header, checksum), 
+                 ivrs->header.length);
+
+    return ivrs;
+}
+
 static int construct_secondary_tables(unsigned long *table_ptrs,
                                       struct acpi_info *info)
 {
@@ -206,6 +279,7 @@ static int construct_secondary_tables(un
     struct acpi_20_hpet *hpet;
     struct acpi_20_waet *waet;
     struct acpi_20_tcpa *tcpa;
+    struct acpi_40_ivrs *ivrs;
     unsigned char *ssdt;
     static const uint16_t tis_signature[] = {0x0001, 0x0001, 0x0001};
     uint16_t *tis_hdr;
@@ -293,6 +367,13 @@ static int construct_secondary_tables(un
         }
     }
 
+    if ( hvm_info->iommu_enabled )
+    {
+        ivrs = construct_ivrs();
+        if ( ivrs != NULL )
+            table_ptrs[nr_tables++] = (unsigned long)ivrs;
+    }
+
     table_ptrs[nr_tables] = 0;
     return nr_tables;
 }
diff -r b70cf1dcb110 -r bb76ba2457e6 tools/firmware/hvmloader/pci.c
--- a/tools/firmware/hvmloader/pci.c	Thu Dec 22 16:56:45 2011 +0100
+++ b/tools/firmware/hvmloader/pci.c	Thu Dec 22 16:56:48 2011 +0100
@@ -34,11 +34,17 @@ unsigned long pci_mem_end = PCI_MEM_END;
 enum virtual_vga virtual_vga = VGA_none;
 unsigned long igd_opregion_pgbase = 0;
 
+/* support up to 32 passthrough devices */
+#define PT_DEV_MAX_NR           32
+uint32_t ptdev_bdf[PT_DEV_MAX_NR];
+uint32_t ptdev_nr;
+uint32_t iommu_bdf;
+
 void pci_setup(void)
 {
     uint32_t base, devfn, bar_reg, bar_data, bar_sz, cmd, mmio_total = 0;
     uint32_t vga_devfn = 256;
-    uint16_t class, vendor_id, device_id;
+    uint16_t class, vendor_id, device_id, sub_vendor_id;
     unsigned int bar, pin, link, isa_irq;
 
     /* Resources assignable to PCI devices via BARs. */
@@ -72,12 +78,34 @@ void pci_setup(void)
         class     = pci_readw(devfn, PCI_CLASS_DEVICE);
         vendor_id = pci_readw(devfn, PCI_VENDOR_ID);
         device_id = pci_readw(devfn, PCI_DEVICE_ID);
+        sub_vendor_id = pci_readw(devfn, PCI_SUBSYSTEM_VENDOR_ID);
+
         if ( (vendor_id == 0xffff) && (device_id == 0xffff) )
             continue;
 
         ASSERT((devfn != PCI_ISA_DEVFN) ||
                ((vendor_id == 0x8086) && (device_id == 0x7000)));
 
+        /* Found amd iommu device. */
+        if ( class == 0x0806 && vendor_id == 0x1022 )
+        {
+            iommu_bdf = devfn;
+            continue;
+        }
+        /* IVRS: Detecting passthrough devices.
+         * sub_vendor_id != citrix && sub_vendor_id != qemu */
+        if ( sub_vendor_id != 0x5853 && sub_vendor_id != 0x1af4 )
+        {
+            /* found amd iommu device */
+            if ( ptdev_nr < PT_DEV_MAX_NR )
+            {
+                ptdev_bdf[ptdev_nr] = devfn;
+                ptdev_nr ++;
+            }
+            else
+                printf("Number of passthru devices > PT_DEV_MAX_NR \n");
+        }
+
         switch ( class )
         {
         case 0x0300:
diff -r b70cf1dcb110 -r bb76ba2457e6 xen/include/public/hvm/hvm_info_table.h
--- a/xen/include/public/hvm/hvm_info_table.h	Thu Dec 22 16:56:45 2011 +0100
+++ b/xen/include/public/hvm/hvm_info_table.h	Thu Dec 22 16:56:48 2011 +0100
@@ -67,6 +67,9 @@ struct hvm_info_table {
 
     /* Bitmap of which CPUs are online at boot time. */
     uint8_t     vcpu_online[(HVM_MAX_VCPUS + 7)/8];
+
+    /* guest iommu enabled */
+    uint8_t     iommu_enabled;
 };
 
 #endif /* __XEN_PUBLIC_HVM_HVM_INFO_TABLE_H__ */


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 23 11:31:46 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 Dec 2011 11:31:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Re3LU-00019t-Tg; Fri, 23 Dec 2011 11:31:28 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Wang2@amd.com>) id 1Re3LT-00018E-2A
	for xen-devel@lists.xensource.com; Fri, 23 Dec 2011 11:31:27 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1324639879!9317652!1
X-Originating-IP: [216.32.181.181]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16546 invoked from network); 23 Dec 2011 11:31:20 -0000
Received: from ch1ehsobe001.messaging.microsoft.com (HELO
	ch1outboundpool.messaging.microsoft.com) (216.32.181.181)
	by server-8.tower-21.messagelabs.com with AES128-SHA encrypted SMTP;
	23 Dec 2011 11:31:20 -0000
Received: from mail49-ch1-R.bigfish.com (10.43.68.249) by
	CH1EHSOBE002.bigfish.com (10.43.70.52) with Microsoft SMTP Server id
	14.1.225.23; Fri, 23 Dec 2011 11:31:06 +0000
Received: from mail49-ch1 (localhost [127.0.0.1])	by mail49-ch1-R.bigfish.com
	(Postfix) with ESMTP id 45017C057F;
	Fri, 23 Dec 2011 11:31:46 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzzz1202hzz8275bhz2dh668h839h944h)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
X-FB-SS: 13,
Received: from mail49-ch1 (localhost.localdomain [127.0.0.1]) by mail49-ch1
	(MessageSwitch) id 132463990612164_11575;
	Fri, 23 Dec 2011 11:31:46 +0000 (UTC)
Received: from CH1EHSMHS016.bigfish.com (snatpool1.int.messaging.microsoft.com
	[10.43.68.252])	by mail49-ch1.bigfish.com (Postfix) with ESMTP id
	E6F7F200042;	Fri, 23 Dec 2011 11:31:45 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	CH1EHSMHS016.bigfish.com (10.43.70.16) with Microsoft SMTP Server id
	14.1.225.23; Fri, 23 Dec 2011 11:31:04 +0000
X-WSS-ID: 0LWNMO2-01-1GA-02
X-M-MSG: 
Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com
	[163.181.249.73])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 202BB10280A2;	Fri, 23 Dec 2011 05:31:14 -0600 (CST)
Received: from SAUSEXDAG02.amd.com (163.181.55.2) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Fri, 23 Dec 2011 05:31:32 -0600
Received: from storexhtp02.amd.com (172.24.4.4) by sausexdag02.amd.com
	(163.181.55.2) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Fri, 23 Dec 2011 05:31:14 -0600
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Fri, 23 Dec 2011
	06:30:43 -0500
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id E8BD849C662; Fri, 23 Dec 2011
	11:30:41 +0000 (GMT)
Received: from gran.amd.com (gran.osrc.amd.com [165.204.15.57])	by
	mail.osrc.amd.com (Postfix) with ESMTP id E1C0B594883; Fri, 23 Dec 2011
	12:30:41 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 40d61d0390ec930cf53ce5cbf91faada8c7192bd
Message-ID: <40d61d0390ec930cf53c.1324639756@gran.amd.com>
In-Reply-To: <patchbomb.1324639749@gran.amd.com>
References: <patchbomb.1324639749@gran.amd.com>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Fri, 23 Dec 2011 12:29:16 +0100
From: Wei Wang <wei.wang2@amd.com>
To: <JBeulich@suse.com>, <Ian.Jackson@eu.citrix.com>,
	<Ian.Campbell@citrix.com>, <keir@xen.org>
X-OriginatorOrg: amd.com
Cc: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 07 of 16] amd iommu: Add 2 hypercalls for libxc
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Wei Wang <wei.wang2@amd.com>
# Date 1324569392 -3600
# Node ID 40d61d0390ec930cf53ce5cbf91faada8c7192bd
# Parent  bf9f21ad9a0ec245b409f3862a5a36c0e070f333
amd iommu: Add 2 hypercalls for libxc

iommu_set_msi: used by qemu to inform hypervisor iommu vector number in guest
space. Hypervisor needs this vector to inject msi into guest when PPR logging
happens.

iommu_bind_bdf: used by xl to bind guest bdf number to machine bdf number.
IOMMU emulations codes receives commands from guest iommu driver and forwards
them to host iommu. But virtual device id from guest should be converted into
physical before sending to real hardware.

Signed -off-by: Wei Wang <wei.wang2@amd.com>

diff -r bf9f21ad9a0e -r 40d61d0390ec xen/drivers/passthrough/amd/iommu_guest.c
--- a/xen/drivers/passthrough/amd/iommu_guest.c	Thu Dec 22 16:56:28 2011 +0100
+++ b/xen/drivers/passthrough/amd/iommu_guest.c	Thu Dec 22 16:56:32 2011 +0100
@@ -50,12 +50,27 @@
 
 static unsigned int machine_bdf(struct domain *d, uint16_t guest_bdf)
 {
-    return guest_bdf;
+    struct pci_dev *pdev;
+    uint16_t mbdf = 0;
+
+    for_each_pdev( d, pdev )
+    {
+        if ( pdev->gbdf == guest_bdf )
+        {
+            mbdf = PCI_BDF2(pdev->bus, pdev->devfn);
+            break;
+        }
+    }
+    return mbdf;
 }
 
 static uint16_t guest_bdf(struct domain *d, uint16_t machine_bdf)
 {
-    return machine_bdf;
+    struct pci_dev *pdev;
+
+    pdev = pci_get_pdev_by_domain(d, 0, PCI_BUS(machine_bdf),
+                                  PCI_DEVFN2(machine_bdf));
+    return pdev->gbdf;
 }
 
 static inline struct guest_iommu *domain_iommu(struct domain *d)
@@ -913,3 +928,43 @@ const struct hvm_mmio_handler iommu_mmio
     .read_handler = guest_iommu_mmio_read,
     .write_handler = guest_iommu_mmio_write
 };
+
+/* iommu hypercall handler */
+int iommu_bind_bdf(struct domain* d, uint16_t gbdf, uint16_t mbdf)
+{
+    struct pci_dev *pdev;
+    int ret = -ENODEV;
+
+    if ( !iommu_found() )
+        return 0;
+
+    spin_lock(&pcidevs_lock);
+
+    for_each_pdev( d, pdev )
+    {
+        if ( (pdev->bus != PCI_BUS(mbdf) ) || 
+             (pdev->devfn != PCI_DEVFN2(mbdf)) )
+            continue;
+
+        pdev->gbdf = gbdf;
+        ret = 0;
+    }
+
+    spin_unlock(&pcidevs_lock);
+    return ret;
+}
+
+void iommu_set_msi(struct domain* d, uint16_t vector, uint16_t dest,
+                   uint16_t dest_mode, uint16_t delivery_mode, 
+                   uint16_t trig_mode)
+{
+    struct guest_iommu *iommu = domain_iommu(d);
+
+    if ( !iommu_found() )
+        return;
+
+    iommu->msi.vector = vector;
+    iommu->msi.dest = dest;
+    iommu->msi.dest_mode = dest_mode;
+    iommu->msi.trig_mode = trig_mode;
+}
diff -r bf9f21ad9a0e -r 40d61d0390ec xen/drivers/passthrough/iommu.c
--- a/xen/drivers/passthrough/iommu.c	Thu Dec 22 16:56:28 2011 +0100
+++ b/xen/drivers/passthrough/iommu.c	Thu Dec 22 16:56:32 2011 +0100
@@ -648,6 +648,40 @@ int iommu_do_domctl(
         put_domain(d);
         break;
 
+#ifndef __ia64__ 
+    case XEN_DOMCTL_guest_iommu_op:
+    {
+        xen_domctl_guest_iommu_op_t * guest_op;
+
+        if ( unlikely((d = get_domain_by_id(domctl->domain)) == NULL) )
+        {
+            gdprintk(XENLOG_ERR,
+                    "XEN_DOMCTL_guest_iommu_op: get_domain_by_id() failed\n");
+            ret = -EINVAL;
+            break;
+        }
+
+        guest_op = &(domctl->u.guest_iommu_op);
+        switch ( guest_op->op )
+        {
+            case XEN_DOMCTL_GUEST_IOMMU_OP_SET_MSI:
+                iommu_set_msi(d, guest_op->u.msi.vector, 
+                              guest_op->u.msi.dest,
+                              guest_op->u.msi.dest_mode, 
+                              guest_op->u.msi.delivery_mode,
+                              guest_op->u.msi.trig_mode);
+                ret = 0;
+                break;
+            case XEN_DOMCTL_GUEST_IOMMU_OP_BIND_BDF:
+                ret = iommu_bind_bdf(d, guest_op->u.bdf_bind.g_bdf,
+                                     guest_op->u.bdf_bind.m_bdf);
+                break;
+        }
+        put_domain(d);
+        break;
+    }
+#endif
+
     default:
         ret = -ENOSYS;
         break;
diff -r bf9f21ad9a0e -r 40d61d0390ec xen/include/public/domctl.h
--- a/xen/include/public/domctl.h	Thu Dec 22 16:56:28 2011 +0100
+++ b/xen/include/public/domctl.h	Thu Dec 22 16:56:32 2011 +0100
@@ -848,6 +848,29 @@ struct xen_domctl_set_access_required {
 typedef struct xen_domctl_set_access_required xen_domctl_set_access_required_t;
 DEFINE_XEN_GUEST_HANDLE(xen_domctl_set_access_required_t);
 
+/* Support for guest iommu emulation */
+struct xen_domctl_guest_iommu_op {
+    /* XEN_DOMCTL_GUEST_IOMMU_OP_* */
+#define XEN_DOMCTL_GUEST_IOMMU_OP_SET_MSI               0
+#define XEN_DOMCTL_GUEST_IOMMU_OP_BIND_BDF              1
+    uint8_t op;
+    union {
+        struct iommu_msi {
+        uint8_t  vector;
+        uint8_t  dest;
+        uint8_t  dest_mode;
+        uint8_t  delivery_mode;
+        uint8_t  trig_mode;
+        } msi;
+        struct bdf_bind { 
+            uint32_t            g_bdf;
+            uint32_t            m_bdf;
+        } bdf_bind;
+    } u;
+};
+typedef struct xen_domctl_guest_iommu_op xen_domctl_guest_iommu_op_t;
+DEFINE_XEN_GUEST_HANDLE(xen_domctl_guest_iommu_op_t);
+
 struct xen_domctl {
     uint32_t cmd;
 #define XEN_DOMCTL_createdomain                   1
@@ -912,6 +935,7 @@ struct xen_domctl {
 #define XEN_DOMCTL_getvcpuextstate               63
 #define XEN_DOMCTL_set_access_required           64
 #define XEN_DOMCTL_audit_p2m                     65
+#define XEN_DOMCTL_guest_iommu_op                66
 #define XEN_DOMCTL_gdbsx_guestmemio            1000
 #define XEN_DOMCTL_gdbsx_pausevcpu             1001
 #define XEN_DOMCTL_gdbsx_unpausevcpu           1002
@@ -960,6 +984,7 @@ struct xen_domctl {
         struct xen_domctl_debug_op          debug_op;
         struct xen_domctl_mem_event_op      mem_event_op;
         struct xen_domctl_mem_sharing_op    mem_sharing_op;
+        struct xen_domctl_guest_iommu_op    guest_iommu_op;
 #if defined(__i386__) || defined(__x86_64__)
         struct xen_domctl_cpuid             cpuid;
         struct xen_domctl_vcpuextstate      vcpuextstate;
diff -r bf9f21ad9a0e -r 40d61d0390ec xen/include/xen/iommu.h
--- a/xen/include/xen/iommu.h	Thu Dec 22 16:56:28 2011 +0100
+++ b/xen/include/xen/iommu.h	Thu Dec 22 16:56:32 2011 +0100
@@ -164,6 +164,14 @@ int iommu_do_domctl(struct xen_domctl *,
 void iommu_iotlb_flush(struct domain *d, unsigned long gfn, unsigned int page_count);
 void iommu_iotlb_flush_all(struct domain *d);
 
+#ifndef __ia64_
+/* Only used by AMD IOMMU */
+void iommu_set_msi(struct domain* d, uint16_t vector, uint16_t dest,
+                   uint16_t dest_mode, uint16_t delivery_mode, 
+                   uint16_t trig_mode);
+int iommu_bind_bdf(struct domain* d, uint16_t gbdf, uint16_t mbdf);
+#endif
+
 /*
  * The purpose of the iommu_dont_flush_iotlb optional cpu flag is to
  * avoid unecessary iotlb_flush in the low level IOMMU code.
diff -r bf9f21ad9a0e -r 40d61d0390ec xen/include/xen/pci.h
--- a/xen/include/xen/pci.h	Thu Dec 22 16:56:28 2011 +0100
+++ b/xen/include/xen/pci.h	Thu Dec 22 16:56:32 2011 +0100
@@ -63,6 +63,9 @@ struct pci_dev {
     const u8 devfn;
     struct pci_dev_info info;
     u64 vf_rlen[6];
+
+    /* used by amd iomm to represent bdf value in guest space */
+    u16 gbdf;
 };
 
 #define for_each_pdev(domain, pdev) \


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 23 11:31:46 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 Dec 2011 11:31:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Re3LU-00019t-Tg; Fri, 23 Dec 2011 11:31:28 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Wang2@amd.com>) id 1Re3LT-00018E-2A
	for xen-devel@lists.xensource.com; Fri, 23 Dec 2011 11:31:27 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1324639879!9317652!1
X-Originating-IP: [216.32.181.181]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16546 invoked from network); 23 Dec 2011 11:31:20 -0000
Received: from ch1ehsobe001.messaging.microsoft.com (HELO
	ch1outboundpool.messaging.microsoft.com) (216.32.181.181)
	by server-8.tower-21.messagelabs.com with AES128-SHA encrypted SMTP;
	23 Dec 2011 11:31:20 -0000
Received: from mail49-ch1-R.bigfish.com (10.43.68.249) by
	CH1EHSOBE002.bigfish.com (10.43.70.52) with Microsoft SMTP Server id
	14.1.225.23; Fri, 23 Dec 2011 11:31:06 +0000
Received: from mail49-ch1 (localhost [127.0.0.1])	by mail49-ch1-R.bigfish.com
	(Postfix) with ESMTP id 45017C057F;
	Fri, 23 Dec 2011 11:31:46 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzzz1202hzz8275bhz2dh668h839h944h)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
X-FB-SS: 13,
Received: from mail49-ch1 (localhost.localdomain [127.0.0.1]) by mail49-ch1
	(MessageSwitch) id 132463990612164_11575;
	Fri, 23 Dec 2011 11:31:46 +0000 (UTC)
Received: from CH1EHSMHS016.bigfish.com (snatpool1.int.messaging.microsoft.com
	[10.43.68.252])	by mail49-ch1.bigfish.com (Postfix) with ESMTP id
	E6F7F200042;	Fri, 23 Dec 2011 11:31:45 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	CH1EHSMHS016.bigfish.com (10.43.70.16) with Microsoft SMTP Server id
	14.1.225.23; Fri, 23 Dec 2011 11:31:04 +0000
X-WSS-ID: 0LWNMO2-01-1GA-02
X-M-MSG: 
Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com
	[163.181.249.73])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 202BB10280A2;	Fri, 23 Dec 2011 05:31:14 -0600 (CST)
Received: from SAUSEXDAG02.amd.com (163.181.55.2) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Fri, 23 Dec 2011 05:31:32 -0600
Received: from storexhtp02.amd.com (172.24.4.4) by sausexdag02.amd.com
	(163.181.55.2) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Fri, 23 Dec 2011 05:31:14 -0600
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Fri, 23 Dec 2011
	06:30:43 -0500
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id E8BD849C662; Fri, 23 Dec 2011
	11:30:41 +0000 (GMT)
Received: from gran.amd.com (gran.osrc.amd.com [165.204.15.57])	by
	mail.osrc.amd.com (Postfix) with ESMTP id E1C0B594883; Fri, 23 Dec 2011
	12:30:41 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 40d61d0390ec930cf53ce5cbf91faada8c7192bd
Message-ID: <40d61d0390ec930cf53c.1324639756@gran.amd.com>
In-Reply-To: <patchbomb.1324639749@gran.amd.com>
References: <patchbomb.1324639749@gran.amd.com>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Fri, 23 Dec 2011 12:29:16 +0100
From: Wei Wang <wei.wang2@amd.com>
To: <JBeulich@suse.com>, <Ian.Jackson@eu.citrix.com>,
	<Ian.Campbell@citrix.com>, <keir@xen.org>
X-OriginatorOrg: amd.com
Cc: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 07 of 16] amd iommu: Add 2 hypercalls for libxc
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Wei Wang <wei.wang2@amd.com>
# Date 1324569392 -3600
# Node ID 40d61d0390ec930cf53ce5cbf91faada8c7192bd
# Parent  bf9f21ad9a0ec245b409f3862a5a36c0e070f333
amd iommu: Add 2 hypercalls for libxc

iommu_set_msi: used by qemu to inform hypervisor iommu vector number in guest
space. Hypervisor needs this vector to inject msi into guest when PPR logging
happens.

iommu_bind_bdf: used by xl to bind guest bdf number to machine bdf number.
IOMMU emulations codes receives commands from guest iommu driver and forwards
them to host iommu. But virtual device id from guest should be converted into
physical before sending to real hardware.

Signed -off-by: Wei Wang <wei.wang2@amd.com>

diff -r bf9f21ad9a0e -r 40d61d0390ec xen/drivers/passthrough/amd/iommu_guest.c
--- a/xen/drivers/passthrough/amd/iommu_guest.c	Thu Dec 22 16:56:28 2011 +0100
+++ b/xen/drivers/passthrough/amd/iommu_guest.c	Thu Dec 22 16:56:32 2011 +0100
@@ -50,12 +50,27 @@
 
 static unsigned int machine_bdf(struct domain *d, uint16_t guest_bdf)
 {
-    return guest_bdf;
+    struct pci_dev *pdev;
+    uint16_t mbdf = 0;
+
+    for_each_pdev( d, pdev )
+    {
+        if ( pdev->gbdf == guest_bdf )
+        {
+            mbdf = PCI_BDF2(pdev->bus, pdev->devfn);
+            break;
+        }
+    }
+    return mbdf;
 }
 
 static uint16_t guest_bdf(struct domain *d, uint16_t machine_bdf)
 {
-    return machine_bdf;
+    struct pci_dev *pdev;
+
+    pdev = pci_get_pdev_by_domain(d, 0, PCI_BUS(machine_bdf),
+                                  PCI_DEVFN2(machine_bdf));
+    return pdev->gbdf;
 }
 
 static inline struct guest_iommu *domain_iommu(struct domain *d)
@@ -913,3 +928,43 @@ const struct hvm_mmio_handler iommu_mmio
     .read_handler = guest_iommu_mmio_read,
     .write_handler = guest_iommu_mmio_write
 };
+
+/* iommu hypercall handler */
+int iommu_bind_bdf(struct domain* d, uint16_t gbdf, uint16_t mbdf)
+{
+    struct pci_dev *pdev;
+    int ret = -ENODEV;
+
+    if ( !iommu_found() )
+        return 0;
+
+    spin_lock(&pcidevs_lock);
+
+    for_each_pdev( d, pdev )
+    {
+        if ( (pdev->bus != PCI_BUS(mbdf) ) || 
+             (pdev->devfn != PCI_DEVFN2(mbdf)) )
+            continue;
+
+        pdev->gbdf = gbdf;
+        ret = 0;
+    }
+
+    spin_unlock(&pcidevs_lock);
+    return ret;
+}
+
+void iommu_set_msi(struct domain* d, uint16_t vector, uint16_t dest,
+                   uint16_t dest_mode, uint16_t delivery_mode, 
+                   uint16_t trig_mode)
+{
+    struct guest_iommu *iommu = domain_iommu(d);
+
+    if ( !iommu_found() )
+        return;
+
+    iommu->msi.vector = vector;
+    iommu->msi.dest = dest;
+    iommu->msi.dest_mode = dest_mode;
+    iommu->msi.trig_mode = trig_mode;
+}
diff -r bf9f21ad9a0e -r 40d61d0390ec xen/drivers/passthrough/iommu.c
--- a/xen/drivers/passthrough/iommu.c	Thu Dec 22 16:56:28 2011 +0100
+++ b/xen/drivers/passthrough/iommu.c	Thu Dec 22 16:56:32 2011 +0100
@@ -648,6 +648,40 @@ int iommu_do_domctl(
         put_domain(d);
         break;
 
+#ifndef __ia64__ 
+    case XEN_DOMCTL_guest_iommu_op:
+    {
+        xen_domctl_guest_iommu_op_t * guest_op;
+
+        if ( unlikely((d = get_domain_by_id(domctl->domain)) == NULL) )
+        {
+            gdprintk(XENLOG_ERR,
+                    "XEN_DOMCTL_guest_iommu_op: get_domain_by_id() failed\n");
+            ret = -EINVAL;
+            break;
+        }
+
+        guest_op = &(domctl->u.guest_iommu_op);
+        switch ( guest_op->op )
+        {
+            case XEN_DOMCTL_GUEST_IOMMU_OP_SET_MSI:
+                iommu_set_msi(d, guest_op->u.msi.vector, 
+                              guest_op->u.msi.dest,
+                              guest_op->u.msi.dest_mode, 
+                              guest_op->u.msi.delivery_mode,
+                              guest_op->u.msi.trig_mode);
+                ret = 0;
+                break;
+            case XEN_DOMCTL_GUEST_IOMMU_OP_BIND_BDF:
+                ret = iommu_bind_bdf(d, guest_op->u.bdf_bind.g_bdf,
+                                     guest_op->u.bdf_bind.m_bdf);
+                break;
+        }
+        put_domain(d);
+        break;
+    }
+#endif
+
     default:
         ret = -ENOSYS;
         break;
diff -r bf9f21ad9a0e -r 40d61d0390ec xen/include/public/domctl.h
--- a/xen/include/public/domctl.h	Thu Dec 22 16:56:28 2011 +0100
+++ b/xen/include/public/domctl.h	Thu Dec 22 16:56:32 2011 +0100
@@ -848,6 +848,29 @@ struct xen_domctl_set_access_required {
 typedef struct xen_domctl_set_access_required xen_domctl_set_access_required_t;
 DEFINE_XEN_GUEST_HANDLE(xen_domctl_set_access_required_t);
 
+/* Support for guest iommu emulation */
+struct xen_domctl_guest_iommu_op {
+    /* XEN_DOMCTL_GUEST_IOMMU_OP_* */
+#define XEN_DOMCTL_GUEST_IOMMU_OP_SET_MSI               0
+#define XEN_DOMCTL_GUEST_IOMMU_OP_BIND_BDF              1
+    uint8_t op;
+    union {
+        struct iommu_msi {
+        uint8_t  vector;
+        uint8_t  dest;
+        uint8_t  dest_mode;
+        uint8_t  delivery_mode;
+        uint8_t  trig_mode;
+        } msi;
+        struct bdf_bind { 
+            uint32_t            g_bdf;
+            uint32_t            m_bdf;
+        } bdf_bind;
+    } u;
+};
+typedef struct xen_domctl_guest_iommu_op xen_domctl_guest_iommu_op_t;
+DEFINE_XEN_GUEST_HANDLE(xen_domctl_guest_iommu_op_t);
+
 struct xen_domctl {
     uint32_t cmd;
 #define XEN_DOMCTL_createdomain                   1
@@ -912,6 +935,7 @@ struct xen_domctl {
 #define XEN_DOMCTL_getvcpuextstate               63
 #define XEN_DOMCTL_set_access_required           64
 #define XEN_DOMCTL_audit_p2m                     65
+#define XEN_DOMCTL_guest_iommu_op                66
 #define XEN_DOMCTL_gdbsx_guestmemio            1000
 #define XEN_DOMCTL_gdbsx_pausevcpu             1001
 #define XEN_DOMCTL_gdbsx_unpausevcpu           1002
@@ -960,6 +984,7 @@ struct xen_domctl {
         struct xen_domctl_debug_op          debug_op;
         struct xen_domctl_mem_event_op      mem_event_op;
         struct xen_domctl_mem_sharing_op    mem_sharing_op;
+        struct xen_domctl_guest_iommu_op    guest_iommu_op;
 #if defined(__i386__) || defined(__x86_64__)
         struct xen_domctl_cpuid             cpuid;
         struct xen_domctl_vcpuextstate      vcpuextstate;
diff -r bf9f21ad9a0e -r 40d61d0390ec xen/include/xen/iommu.h
--- a/xen/include/xen/iommu.h	Thu Dec 22 16:56:28 2011 +0100
+++ b/xen/include/xen/iommu.h	Thu Dec 22 16:56:32 2011 +0100
@@ -164,6 +164,14 @@ int iommu_do_domctl(struct xen_domctl *,
 void iommu_iotlb_flush(struct domain *d, unsigned long gfn, unsigned int page_count);
 void iommu_iotlb_flush_all(struct domain *d);
 
+#ifndef __ia64_
+/* Only used by AMD IOMMU */
+void iommu_set_msi(struct domain* d, uint16_t vector, uint16_t dest,
+                   uint16_t dest_mode, uint16_t delivery_mode, 
+                   uint16_t trig_mode);
+int iommu_bind_bdf(struct domain* d, uint16_t gbdf, uint16_t mbdf);
+#endif
+
 /*
  * The purpose of the iommu_dont_flush_iotlb optional cpu flag is to
  * avoid unecessary iotlb_flush in the low level IOMMU code.
diff -r bf9f21ad9a0e -r 40d61d0390ec xen/include/xen/pci.h
--- a/xen/include/xen/pci.h	Thu Dec 22 16:56:28 2011 +0100
+++ b/xen/include/xen/pci.h	Thu Dec 22 16:56:32 2011 +0100
@@ -63,6 +63,9 @@ struct pci_dev {
     const u8 devfn;
     struct pci_dev_info info;
     u64 vf_rlen[6];
+
+    /* used by amd iomm to represent bdf value in guest space */
+    u16 gbdf;
 };
 
 #define for_each_pdev(domain, pdev) \


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 23 11:31:46 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 Dec 2011 11:31:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Re3LW-0001Aj-58; Fri, 23 Dec 2011 11:31:30 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Wang2@amd.com>) id 1Re3LT-00018I-R6
	for xen-devel@lists.xensource.com; Fri, 23 Dec 2011 11:31:28 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1324639881!8578587!1
X-Originating-IP: [213.199.154.144]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9133 invoked from network); 23 Dec 2011 11:31:21 -0000
Received: from db3ehsobe006.messaging.microsoft.com (HELO
	DB3EHSOBE006.bigfish.com) (213.199.154.144)
	by server-5.tower-216.messagelabs.com with AES128-SHA encrypted SMTP;
	23 Dec 2011 11:31:21 -0000
Received: from mail23-db3-R.bigfish.com (10.3.81.253) by
	DB3EHSOBE006.bigfish.com (10.3.84.26) with Microsoft SMTP Server id
	14.1.225.23; Fri, 23 Dec 2011 11:31:08 +0000
Received: from mail23-db3 (localhost [127.0.0.1])	by mail23-db3-R.bigfish.com
	(Postfix) with ESMTP id E7F7D60533;
	Fri, 23 Dec 2011 11:31:47 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzzz1202hzz8275bhz2dh668h839h944h)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
Received: from mail23-db3 (localhost.localdomain [127.0.0.1]) by mail23-db3
	(MessageSwitch) id 1324639907398226_30218;
	Fri, 23 Dec 2011 11:31:47 +0000 (UTC)
Received: from DB3EHSMHS007.bigfish.com (unknown [10.3.81.243])	by
	mail23-db3.bigfish.com (Postfix) with ESMTP id 487CB40045;
	Fri, 23 Dec 2011 11:31:47 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	DB3EHSMHS007.bigfish.com (10.3.87.107) with Microsoft SMTP Server id
	14.1.225.23; Fri, 23 Dec 2011 11:31:07 +0000
X-WSS-ID: 0LWNMO4-01-1GD-02
X-M-MSG: 
Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com
	[163.181.249.73])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2D9C1102809E;	Fri, 23 Dec 2011 05:31:15 -0600 (CST)
Received: from SAUSEXDAG02.amd.com (163.181.55.2) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Fri, 23 Dec 2011 05:31:34 -0600
Received: from storexhtp02.amd.com (172.24.4.4) by sausexdag02.amd.com
	(163.181.55.2) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Fri, 23 Dec 2011 05:31:16 -0600
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Fri, 23 Dec 2011
	06:30:43 -0500
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 02CE349C667; Fri, 23 Dec 2011
	11:30:43 +0000 (GMT)
Received: from gran.amd.com (gran.osrc.amd.com [165.204.15.57])	by
	mail.osrc.amd.com (Postfix) with ESMTP id A3752594882; Fri, 23 Dec 2011
	12:30:42 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: bb76ba2457e629d668c08e57f2168b13bdfb7930
Message-ID: <bb76ba2457e629d668c0.1324639761@gran.amd.com>
In-Reply-To: <patchbomb.1324639749@gran.amd.com>
References: <patchbomb.1324639749@gran.amd.com>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Fri, 23 Dec 2011 12:29:21 +0100
From: Wei Wang <wei.wang2@amd.com>
To: <JBeulich@suse.com>, <Ian.Jackson@eu.citrix.com>,
	<Ian.Campbell@citrix.com>, <keir@xen.org>
X-OriginatorOrg: amd.com
Cc: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 12 of 16] hvmloader: Build IVRS table
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Wei Wang <wei.wang2@amd.com>
# Date 1324569408 -3600
# Node ID bb76ba2457e629d668c08e57f2168b13bdfb7930
# Parent  b70cf1dcb110f79546f3efac3201a08d70c8b96e
hvmloader: Build IVRS table.
Signed-off-by: Wei Wang <wei.wang2@amd.com>

diff -r b70cf1dcb110 -r bb76ba2457e6 tools/firmware/hvmloader/acpi/acpi2_0.h
--- a/tools/firmware/hvmloader/acpi/acpi2_0.h	Thu Dec 22 16:56:45 2011 +0100
+++ b/tools/firmware/hvmloader/acpi/acpi2_0.h	Thu Dec 22 16:56:48 2011 +0100
@@ -389,6 +389,60 @@ struct acpi_20_madt_intsrcovr {
 #define ACPI_2_0_WAET_REVISION 0x01
 #define ACPI_1_0_FADT_REVISION 0x01
 
+#define IVRS_SIGNATURE ASCII32('I','V','R','S')
+#define IVRS_REVISION           1
+#define IVRS_VASIZE             64
+#define IVRS_PASIZE             52
+#define IVRS_GVASIZE            64
+
+#define IVHD_BLOCK_TYPE         0x10
+#define IVHD_FLAG_HTTUNEN       (1 << 0)
+#define IVHD_FLAG_PASSPW        (1 << 1)
+#define IVHD_FLAG_RESPASSPW     (1 << 2)
+#define IVHD_FLAG_ISOC          (1 << 3)
+#define IVHD_FLAG_IOTLBSUP      (1 << 4)
+#define IVHD_FLAG_COHERENT      (1 << 5)
+#define IVHD_FLAG_PREFSUP       (1 << 6)
+#define IVHD_FLAG_PPRSUP        (1 << 7)
+
+#define IVHD_EFR_GTSUP          (1 << 2)
+#define IVHD_EFR_IASUP          (1 << 5)
+
+#define IVHD_SELECT_4_BYTE      0x2
+
+struct ivrs_ivhd_block
+{
+    uint8_t    type;
+    uint8_t    flags;
+    uint16_t   length;
+    uint16_t   devid;
+    uint16_t   cap_offset;
+    uint64_t   iommu_base_addr;
+    uint16_t   pci_segment;
+    uint16_t   iommu_info;
+    uint32_t   reserved;
+};
+
+/* IVHD 4-byte device entries */
+struct ivrs_ivhd_device
+{
+   uint8_t  type;
+   uint16_t dev_id;
+   uint8_t  flags;
+};
+
+#define PT_DEV_MAX_NR           32
+#define IOMMU_CAP_OFFSET        0x40
+struct acpi_40_ivrs
+{
+    struct acpi_header                      header;
+    uint32_t                                iv_info;
+    uint32_t                                reserved[2];
+    struct ivrs_ivhd_block                  ivhd_block;
+    struct ivrs_ivhd_device                 ivhd_device[PT_DEV_MAX_NR];
+};
+
+
 #pragma pack ()
 
 struct acpi_config {
diff -r b70cf1dcb110 -r bb76ba2457e6 tools/firmware/hvmloader/acpi/build.c
--- a/tools/firmware/hvmloader/acpi/build.c	Thu Dec 22 16:56:45 2011 +0100
+++ b/tools/firmware/hvmloader/acpi/build.c	Thu Dec 22 16:56:48 2011 +0100
@@ -23,6 +23,8 @@
 #include "ssdt_pm.h"
 #include "../config.h"
 #include "../util.h"
+#include "../hypercall.h"
+#include <xen/hvm/params.h>
 
 #define align16(sz)        (((sz) + 15) & ~15)
 #define fixed_strcpy(d, s) strncpy((d), (s), sizeof(d))
@@ -198,6 +200,77 @@ static struct acpi_20_waet *construct_wa
     return waet;
 }
 
+extern uint32_t ptdev_bdf[PT_DEV_MAX_NR];
+extern uint32_t ptdev_nr;
+extern uint32_t iommu_bdf;
+static struct acpi_40_ivrs* construct_ivrs(void)
+{
+    struct acpi_40_ivrs *ivrs;
+    uint64_t mmio;
+    struct ivrs_ivhd_block *ivhd;
+    struct ivrs_ivhd_device *dev_entry;
+    struct xen_hvm_param p;
+
+    if (ptdev_nr == 0) return NULL;
+
+    ivrs = mem_alloc(sizeof(*ivrs), 16);
+    if (!ivrs) return NULL;
+
+    memset(ivrs, 0, sizeof(*ivrs));
+
+    /* initialize acpi header */
+    ivrs->header.signature = IVRS_SIGNATURE;
+    ivrs->header.revision = IVRS_REVISION;
+    fixed_strcpy(ivrs->header.oem_id, ACPI_OEM_ID);
+    fixed_strcpy(ivrs->header.oem_table_id, ACPI_OEM_TABLE_ID);
+
+    ivrs->header.oem_revision = ACPI_OEM_REVISION;
+    ivrs->header.creator_id   = ACPI_CREATOR_ID;
+    ivrs->header.creator_revision = ACPI_CREATOR_REVISION;
+
+    ivrs->header.length = sizeof(*ivrs);
+
+    /* initialize IVHD Block */
+    ivhd = &ivrs->ivhd_block;
+    ivrs->iv_info = (IVRS_VASIZE << 15) | (IVRS_PASIZE << 8) |
+                    (IVRS_GVASIZE << 5);
+
+    ivhd->type          = IVHD_BLOCK_TYPE;
+    ivhd->flags         = IVHD_FLAG_PPRSUP | IVHD_FLAG_IOTLBSUP;
+    ivhd->devid         = iommu_bdf;
+    ivhd->cap_offset    = IOMMU_CAP_OFFSET;
+
+    /*reserve 32K IOMMU MMIO space */
+    mmio = virt_to_phys(mem_alloc(0x8000, 0x1000));
+    if (!mmio) return NULL;
+
+    p.domid = DOMID_SELF;
+    p.index = HVM_PARAM_IOMMU_BASE;
+    p.value = mmio;
+
+    /* Return non-zero if IOMMUv2 hardware is not avaliable */
+    if ( hypercall_hvm_op(HVMOP_set_param, &p) )
+        return NULL;
+
+    ivhd->iommu_base_addr = mmio;
+    ivhd->reserved = IVHD_EFR_IASUP | IVHD_EFR_GTSUP;
+
+    /* Build IVHD device entries */
+    dev_entry = ivrs->ivhd_device;
+    for ( int i = 0; i < ptdev_nr; i++ )
+    {
+        dev_entry[i].type   = IVHD_SELECT_4_BYTE;
+        dev_entry[i].dev_id = ptdev_bdf[i];
+        dev_entry[i].flags  = 0;
+    }
+
+    ivhd->length = sizeof(*ivhd) + sizeof(*dev_entry) * PT_DEV_MAX_NR;
+    set_checksum(ivrs, offsetof(struct acpi_header, checksum), 
+                 ivrs->header.length);
+
+    return ivrs;
+}
+
 static int construct_secondary_tables(unsigned long *table_ptrs,
                                       struct acpi_info *info)
 {
@@ -206,6 +279,7 @@ static int construct_secondary_tables(un
     struct acpi_20_hpet *hpet;
     struct acpi_20_waet *waet;
     struct acpi_20_tcpa *tcpa;
+    struct acpi_40_ivrs *ivrs;
     unsigned char *ssdt;
     static const uint16_t tis_signature[] = {0x0001, 0x0001, 0x0001};
     uint16_t *tis_hdr;
@@ -293,6 +367,13 @@ static int construct_secondary_tables(un
         }
     }
 
+    if ( hvm_info->iommu_enabled )
+    {
+        ivrs = construct_ivrs();
+        if ( ivrs != NULL )
+            table_ptrs[nr_tables++] = (unsigned long)ivrs;
+    }
+
     table_ptrs[nr_tables] = 0;
     return nr_tables;
 }
diff -r b70cf1dcb110 -r bb76ba2457e6 tools/firmware/hvmloader/pci.c
--- a/tools/firmware/hvmloader/pci.c	Thu Dec 22 16:56:45 2011 +0100
+++ b/tools/firmware/hvmloader/pci.c	Thu Dec 22 16:56:48 2011 +0100
@@ -34,11 +34,17 @@ unsigned long pci_mem_end = PCI_MEM_END;
 enum virtual_vga virtual_vga = VGA_none;
 unsigned long igd_opregion_pgbase = 0;
 
+/* support up to 32 passthrough devices */
+#define PT_DEV_MAX_NR           32
+uint32_t ptdev_bdf[PT_DEV_MAX_NR];
+uint32_t ptdev_nr;
+uint32_t iommu_bdf;
+
 void pci_setup(void)
 {
     uint32_t base, devfn, bar_reg, bar_data, bar_sz, cmd, mmio_total = 0;
     uint32_t vga_devfn = 256;
-    uint16_t class, vendor_id, device_id;
+    uint16_t class, vendor_id, device_id, sub_vendor_id;
     unsigned int bar, pin, link, isa_irq;
 
     /* Resources assignable to PCI devices via BARs. */
@@ -72,12 +78,34 @@ void pci_setup(void)
         class     = pci_readw(devfn, PCI_CLASS_DEVICE);
         vendor_id = pci_readw(devfn, PCI_VENDOR_ID);
         device_id = pci_readw(devfn, PCI_DEVICE_ID);
+        sub_vendor_id = pci_readw(devfn, PCI_SUBSYSTEM_VENDOR_ID);
+
         if ( (vendor_id == 0xffff) && (device_id == 0xffff) )
             continue;
 
         ASSERT((devfn != PCI_ISA_DEVFN) ||
                ((vendor_id == 0x8086) && (device_id == 0x7000)));
 
+        /* Found amd iommu device. */
+        if ( class == 0x0806 && vendor_id == 0x1022 )
+        {
+            iommu_bdf = devfn;
+            continue;
+        }
+        /* IVRS: Detecting passthrough devices.
+         * sub_vendor_id != citrix && sub_vendor_id != qemu */
+        if ( sub_vendor_id != 0x5853 && sub_vendor_id != 0x1af4 )
+        {
+            /* found amd iommu device */
+            if ( ptdev_nr < PT_DEV_MAX_NR )
+            {
+                ptdev_bdf[ptdev_nr] = devfn;
+                ptdev_nr ++;
+            }
+            else
+                printf("Number of passthru devices > PT_DEV_MAX_NR \n");
+        }
+
         switch ( class )
         {
         case 0x0300:
diff -r b70cf1dcb110 -r bb76ba2457e6 xen/include/public/hvm/hvm_info_table.h
--- a/xen/include/public/hvm/hvm_info_table.h	Thu Dec 22 16:56:45 2011 +0100
+++ b/xen/include/public/hvm/hvm_info_table.h	Thu Dec 22 16:56:48 2011 +0100
@@ -67,6 +67,9 @@ struct hvm_info_table {
 
     /* Bitmap of which CPUs are online at boot time. */
     uint8_t     vcpu_online[(HVM_MAX_VCPUS + 7)/8];
+
+    /* guest iommu enabled */
+    uint8_t     iommu_enabled;
 };
 
 #endif /* __XEN_PUBLIC_HVM_HVM_INFO_TABLE_H__ */


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 23 11:31:46 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 Dec 2011 11:31:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Re3LV-0001A7-Aw; Fri, 23 Dec 2011 11:31:29 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Wang2@amd.com>) id 1Re3LT-00018G-Ip
	for xen-devel@lists.xensource.com; Fri, 23 Dec 2011 11:31:27 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1324639880!5946815!1
X-Originating-IP: [216.32.181.185]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14261 invoked from network); 23 Dec 2011 11:31:21 -0000
Received: from ch1ehsobe005.messaging.microsoft.com (HELO
	ch1outboundpool.messaging.microsoft.com) (216.32.181.185)
	by server-13.tower-21.messagelabs.com with AES128-SHA encrypted SMTP;
	23 Dec 2011 11:31:21 -0000
Received: from mail191-ch1-R.bigfish.com (10.43.68.244) by
	CH1EHSOBE005.bigfish.com (10.43.70.55) with Microsoft SMTP Server id
	14.1.225.23; Fri, 23 Dec 2011 11:31:07 +0000
Received: from mail191-ch1 (localhost [127.0.0.1])	by
	mail191-ch1-R.bigfish.com (Postfix) with ESMTP id 92A96E041C;
	Fri, 23 Dec 2011 11:31:46 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzzz1202hzz8275bhz2dh668h839h944h)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
Received: from mail191-ch1 (localhost.localdomain [127.0.0.1]) by mail191-ch1
	(MessageSwitch) id 1324639904403232_15404;
	Fri, 23 Dec 2011 11:31:44 +0000 (UTC)
Received: from CH1EHSMHS017.bigfish.com (snatpool1.int.messaging.microsoft.com
	[10.43.68.252])	by mail191-ch1.bigfish.com (Postfix) with ESMTP id
	5D063480046;	Fri, 23 Dec 2011 11:31:44 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	CH1EHSMHS017.bigfish.com (10.43.70.17) with Microsoft SMTP Server id
	14.1.225.23; Fri, 23 Dec 2011 11:31:05 +0000
X-WSS-ID: 0LWNMO2-02-0X7-02
X-M-MSG: 
Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com
	[163.181.249.73])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp02.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2E70BFCC002;	Fri, 23 Dec 2011 05:31:14 -0600 (CST)
Received: from SAUSEXDAG02.amd.com (163.181.55.2) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Fri, 23 Dec 2011 05:31:33 -0600
Received: from storexhtp02.amd.com (172.24.4.4) by sausexdag02.amd.com
	(163.181.55.2) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Fri, 23 Dec 2011 05:31:15 -0600
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Fri, 23 Dec 2011
	06:30:43 -0500
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 6B2DD49C665; Fri, 23 Dec 2011
	11:30:42 +0000 (GMT)
Received: from gran.amd.com (gran.osrc.amd.com [165.204.15.57])	by
	mail.osrc.amd.com (Postfix) with ESMTP id 4A6475940FF; Fri, 23 Dec 2011
	12:30:42 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 30b1f434160d989be5e0bb6c6956bb7e3985db59
Message-ID: <30b1f434160d989be5e0.1324639759@gran.amd.com>
In-Reply-To: <patchbomb.1324639749@gran.amd.com>
References: <patchbomb.1324639749@gran.amd.com>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Fri, 23 Dec 2011 12:29:19 +0100
From: Wei Wang <wei.wang2@amd.com>
To: <JBeulich@suse.com>, <Ian.Jackson@eu.citrix.com>,
	<Ian.Campbell@citrix.com>, <keir@xen.org>
X-OriginatorOrg: amd.com
Cc: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 10 of 16] amd iommu: Enable FC bit in iommu host
	level PTE
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Wei Wang <wei.wang2@amd.com>
# Date 1324569401 -3600
# Node ID 30b1f434160d989be5e0bb6c6956bb7e3985db59
# Parent  dd808bdd61c581b041d5b7e816b18674de51da6f
amd iommu: Enable FC bit in iommu host level PTE

Signed-off-by: Wei Wang <wei.wang2@amd.com>

diff -r dd808bdd61c5 -r 30b1f434160d xen/drivers/passthrough/amd/iommu_map.c
--- a/xen/drivers/passthrough/amd/iommu_map.c	Thu Dec 22 16:56:38 2011 +0100
+++ b/xen/drivers/passthrough/amd/iommu_map.c	Thu Dec 22 16:56:41 2011 +0100
@@ -83,6 +83,11 @@ static bool_t set_iommu_pde_present(u32 
     set_field_in_reg_u32(ir, entry,
                          IOMMU_PDE_IO_READ_PERMISSION_MASK,
                          IOMMU_PDE_IO_READ_PERMISSION_SHIFT, &entry);
+
+    /* IOMMUv2 needs FC bit enabled  */
+    if ( next_level == IOMMU_PAGING_MODE_LEVEL_0 )
+        set_field_in_reg_u32(IOMMU_CONTROL_ENABLED, entry,
+                             IOMMU_PTE_FC_MASK, IOMMU_PTE_FC_SHIFT, &entry);
     pde[1] = entry;
 
     /* mark next level as 'present' */


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 23 11:31:46 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 Dec 2011 11:31:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Re3LV-0001A7-Aw; Fri, 23 Dec 2011 11:31:29 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Wang2@amd.com>) id 1Re3LT-00018G-Ip
	for xen-devel@lists.xensource.com; Fri, 23 Dec 2011 11:31:27 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1324639880!5946815!1
X-Originating-IP: [216.32.181.185]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14261 invoked from network); 23 Dec 2011 11:31:21 -0000
Received: from ch1ehsobe005.messaging.microsoft.com (HELO
	ch1outboundpool.messaging.microsoft.com) (216.32.181.185)
	by server-13.tower-21.messagelabs.com with AES128-SHA encrypted SMTP;
	23 Dec 2011 11:31:21 -0000
Received: from mail191-ch1-R.bigfish.com (10.43.68.244) by
	CH1EHSOBE005.bigfish.com (10.43.70.55) with Microsoft SMTP Server id
	14.1.225.23; Fri, 23 Dec 2011 11:31:07 +0000
Received: from mail191-ch1 (localhost [127.0.0.1])	by
	mail191-ch1-R.bigfish.com (Postfix) with ESMTP id 92A96E041C;
	Fri, 23 Dec 2011 11:31:46 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzzz1202hzz8275bhz2dh668h839h944h)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
Received: from mail191-ch1 (localhost.localdomain [127.0.0.1]) by mail191-ch1
	(MessageSwitch) id 1324639904403232_15404;
	Fri, 23 Dec 2011 11:31:44 +0000 (UTC)
Received: from CH1EHSMHS017.bigfish.com (snatpool1.int.messaging.microsoft.com
	[10.43.68.252])	by mail191-ch1.bigfish.com (Postfix) with ESMTP id
	5D063480046;	Fri, 23 Dec 2011 11:31:44 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	CH1EHSMHS017.bigfish.com (10.43.70.17) with Microsoft SMTP Server id
	14.1.225.23; Fri, 23 Dec 2011 11:31:05 +0000
X-WSS-ID: 0LWNMO2-02-0X7-02
X-M-MSG: 
Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com
	[163.181.249.73])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp02.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2E70BFCC002;	Fri, 23 Dec 2011 05:31:14 -0600 (CST)
Received: from SAUSEXDAG02.amd.com (163.181.55.2) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Fri, 23 Dec 2011 05:31:33 -0600
Received: from storexhtp02.amd.com (172.24.4.4) by sausexdag02.amd.com
	(163.181.55.2) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Fri, 23 Dec 2011 05:31:15 -0600
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Fri, 23 Dec 2011
	06:30:43 -0500
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 6B2DD49C665; Fri, 23 Dec 2011
	11:30:42 +0000 (GMT)
Received: from gran.amd.com (gran.osrc.amd.com [165.204.15.57])	by
	mail.osrc.amd.com (Postfix) with ESMTP id 4A6475940FF; Fri, 23 Dec 2011
	12:30:42 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 30b1f434160d989be5e0bb6c6956bb7e3985db59
Message-ID: <30b1f434160d989be5e0.1324639759@gran.amd.com>
In-Reply-To: <patchbomb.1324639749@gran.amd.com>
References: <patchbomb.1324639749@gran.amd.com>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Fri, 23 Dec 2011 12:29:19 +0100
From: Wei Wang <wei.wang2@amd.com>
To: <JBeulich@suse.com>, <Ian.Jackson@eu.citrix.com>,
	<Ian.Campbell@citrix.com>, <keir@xen.org>
X-OriginatorOrg: amd.com
Cc: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 10 of 16] amd iommu: Enable FC bit in iommu host
	level PTE
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Wei Wang <wei.wang2@amd.com>
# Date 1324569401 -3600
# Node ID 30b1f434160d989be5e0bb6c6956bb7e3985db59
# Parent  dd808bdd61c581b041d5b7e816b18674de51da6f
amd iommu: Enable FC bit in iommu host level PTE

Signed-off-by: Wei Wang <wei.wang2@amd.com>

diff -r dd808bdd61c5 -r 30b1f434160d xen/drivers/passthrough/amd/iommu_map.c
--- a/xen/drivers/passthrough/amd/iommu_map.c	Thu Dec 22 16:56:38 2011 +0100
+++ b/xen/drivers/passthrough/amd/iommu_map.c	Thu Dec 22 16:56:41 2011 +0100
@@ -83,6 +83,11 @@ static bool_t set_iommu_pde_present(u32 
     set_field_in_reg_u32(ir, entry,
                          IOMMU_PDE_IO_READ_PERMISSION_MASK,
                          IOMMU_PDE_IO_READ_PERMISSION_SHIFT, &entry);
+
+    /* IOMMUv2 needs FC bit enabled  */
+    if ( next_level == IOMMU_PAGING_MODE_LEVEL_0 )
+        set_field_in_reg_u32(IOMMU_CONTROL_ENABLED, entry,
+                             IOMMU_PTE_FC_MASK, IOMMU_PTE_FC_SHIFT, &entry);
     pde[1] = entry;
 
     /* mark next level as 'present' */


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 23 11:31:46 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 Dec 2011 11:31:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Re3LX-0001BS-6H; Fri, 23 Dec 2011 11:31:31 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Wang2@amd.com>) id 1Re3LV-00018S-Df
	for xen-devel@lists.xensource.com; Fri, 23 Dec 2011 11:31:29 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1324639881!8361623!1
X-Originating-IP: [216.32.181.186]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13213 invoked from network); 23 Dec 2011 11:31:23 -0000
Received: from ch1ehsobe006.messaging.microsoft.com (HELO
	ch1outboundpool.messaging.microsoft.com) (216.32.181.186)
	by server-15.tower-182.messagelabs.com with AES128-SHA encrypted SMTP;
	23 Dec 2011 11:31:23 -0000
Received: from mail189-ch1-R.bigfish.com (10.43.68.242) by
	CH1EHSOBE009.bigfish.com (10.43.70.59) with Microsoft SMTP Server id
	14.1.225.23; Fri, 23 Dec 2011 11:31:08 +0000
Received: from mail189-ch1 (localhost [127.0.0.1])	by
	mail189-ch1-R.bigfish.com (Postfix) with ESMTP id E895A62008B;
	Fri, 23 Dec 2011 11:31:48 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzzz1202hzz8275bhz2dh668h839h944h)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
Received: from mail189-ch1 (localhost.localdomain [127.0.0.1]) by mail189-ch1
	(MessageSwitch) id 1324639906647674_20335;
	Fri, 23 Dec 2011 11:31:46 +0000 (UTC)
Received: from CH1EHSMHS030.bigfish.com (snatpool1.int.messaging.microsoft.com
	[10.43.68.245])	by mail189-ch1.bigfish.com (Postfix) with ESMTP id
	9A30520112;	Fri, 23 Dec 2011 11:31:46 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	CH1EHSMHS030.bigfish.com (10.43.70.30) with Microsoft SMTP Server id
	14.1.225.23; Fri, 23 Dec 2011 11:31:06 +0000
X-WSS-ID: 0LWNMO4-01-1GE-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2FD19102809D;	Fri, 23 Dec 2011 05:31:15 -0600 (CST)
Received: from SAUSEXDAG02.amd.com (163.181.55.2) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Fri, 23 Dec 2011 05:31:34 -0600
Received: from storexhtp02.amd.com (172.24.4.4) by sausexdag02.amd.com
	(163.181.55.2) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Fri, 23 Dec 2011 05:31:16 -0600
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Fri, 23 Dec 2011
	06:30:43 -0500
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id A817649C65C; Fri, 23 Dec 2011
	11:30:42 +0000 (GMT)
Received: from gran.amd.com (gran.osrc.amd.com [165.204.15.57])	by
	mail.osrc.amd.com (Postfix) with ESMTP id 69320594884; Fri, 23 Dec 2011
	12:30:42 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: b70cf1dcb110f79546f3efac3201a08d70c8b96e
Message-ID: <b70cf1dcb110f79546f3.1324639760@gran.amd.com>
In-Reply-To: <patchbomb.1324639749@gran.amd.com>
References: <patchbomb.1324639749@gran.amd.com>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Fri, 23 Dec 2011 12:29:20 +0100
From: Wei Wang <wei.wang2@amd.com>
To: <JBeulich@suse.com>, <Ian.Jackson@eu.citrix.com>,
	<Ian.Campbell@citrix.com>, <keir@xen.org>
X-OriginatorOrg: amd.com
Cc: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 11 of 16] amd iommu: Add a new flag to
 indication iommuv2 feature enabled or not
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Wei Wang <wei.wang2@amd.com>
# Date 1324569405 -3600
# Node ID b70cf1dcb110f79546f3efac3201a08d70c8b96e
# Parent  30b1f434160d989be5e0bb6c6956bb7e3985db59
amd iommu: Add a new flag to indication iommuv2 feature enabled or not.
Hypercalls should return early on non-iommuv2 systems.

Signed-off-by: Wei Wang <wei.wang2@amd.com>

diff -r 30b1f434160d -r b70cf1dcb110 xen/drivers/passthrough/amd/iommu_guest.c
--- a/xen/drivers/passthrough/amd/iommu_guest.c	Thu Dec 22 16:56:41 2011 +0100
+++ b/xen/drivers/passthrough/amd/iommu_guest.c	Thu Dec 22 16:56:45 2011 +0100
@@ -48,6 +48,8 @@
         (reg)->hi = (val >> 32) & 0xFFFFFFFF; \
     } while(0)
 
+extern bool_t iommuv2_enabled;
+
 static unsigned int machine_bdf(struct domain *d, uint16_t guest_bdf)
 {
     struct pci_dev *pdev;
@@ -819,6 +821,9 @@ int guest_iommu_set_base(struct domain *
     p2m_type_t t;
     struct guest_iommu *iommu = domain_iommu(d);
 
+    if ( !is_hvm_domain(d) || !iommuv2_enabled )
+        return 1;
+
     iommu->mmio_base = base;
     base >>= PAGE_SHIFT;
 
@@ -878,7 +883,7 @@ int guest_iommu_init(struct domain* d)
     struct guest_iommu *iommu;
     struct hvm_iommu *hd  = domain_hvm_iommu(d);
 
-    if ( !is_hvm_domain(d) )
+    if ( !is_hvm_domain(d) || !iommuv2_enabled )
         return 0;
 
     iommu = xzalloc(struct guest_iommu);
@@ -902,13 +907,11 @@ int guest_iommu_init(struct domain* d)
 
 void guest_iommu_destroy(struct domain *d)
 {
-    struct guest_iommu *iommu;
+    struct guest_iommu *iommu = domain_iommu(d);
 
-    if ( !is_hvm_domain(d) )
+    if ( !is_hvm_domain(d) || !iommuv2_enabled )
         return;
 
-    iommu = domain_iommu(d);
-
     tasklet_kill(&iommu->cmd_buffer_tasklet);
     xfree(iommu);
 
@@ -919,6 +922,9 @@ static int guest_iommu_mmio_range(struct
 {
     struct guest_iommu *iommu = vcpu_iommu(v);
 
+    if ( !iommu_found() || !iommuv2_enabled )
+        return 0;
+
     return ( addr >= iommu->mmio_base && 
              addr < (iommu->mmio_base + IOMMU_MMIO_SIZE) );
 }
@@ -935,7 +941,7 @@ int iommu_bind_bdf(struct domain* d, uin
     struct pci_dev *pdev;
     int ret = -ENODEV;
 
-    if ( !iommu_found() )
+    if ( !iommu_found() || !iommuv2_enabled )
         return 0;
 
     spin_lock(&pcidevs_lock);
@@ -960,7 +966,7 @@ void iommu_set_msi(struct domain* d, uin
 {
     struct guest_iommu *iommu = domain_iommu(d);
 
-    if ( !iommu_found() )
+    if ( !iommu_found() || !iommuv2_enabled )
         return;
 
     iommu->msi.vector = vector;
diff -r 30b1f434160d -r b70cf1dcb110 xen/drivers/passthrough/amd/iommu_init.c
--- a/xen/drivers/passthrough/amd/iommu_init.c	Thu Dec 22 16:56:41 2011 +0100
+++ b/xen/drivers/passthrough/amd/iommu_init.c	Thu Dec 22 16:56:45 2011 +0100
@@ -36,6 +36,7 @@ unsigned short ivrs_bdf_entries;
 static struct radix_tree_root ivrs_maps;
 struct list_head amd_iommu_head;
 struct table_struct device_table;
+bool_t iommuv2_enabled;
 
 static int iommu_has_ht_flag(struct amd_iommu *iommu, u8 mask)
 {
@@ -759,6 +760,10 @@ static void enable_iommu(struct amd_iomm
         amd_iommu_flush_all_caches(iommu);
 
     iommu->enabled = 1;
+
+    if ( iommu->features )
+        iommuv2_enabled = 1;
+
     spin_unlock_irqrestore(&iommu->lock, flags);
 
 }


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 23 11:31:46 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 Dec 2011 11:31:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Re3LX-0001BS-6H; Fri, 23 Dec 2011 11:31:31 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Wang2@amd.com>) id 1Re3LV-00018S-Df
	for xen-devel@lists.xensource.com; Fri, 23 Dec 2011 11:31:29 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1324639881!8361623!1
X-Originating-IP: [216.32.181.186]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13213 invoked from network); 23 Dec 2011 11:31:23 -0000
Received: from ch1ehsobe006.messaging.microsoft.com (HELO
	ch1outboundpool.messaging.microsoft.com) (216.32.181.186)
	by server-15.tower-182.messagelabs.com with AES128-SHA encrypted SMTP;
	23 Dec 2011 11:31:23 -0000
Received: from mail189-ch1-R.bigfish.com (10.43.68.242) by
	CH1EHSOBE009.bigfish.com (10.43.70.59) with Microsoft SMTP Server id
	14.1.225.23; Fri, 23 Dec 2011 11:31:08 +0000
Received: from mail189-ch1 (localhost [127.0.0.1])	by
	mail189-ch1-R.bigfish.com (Postfix) with ESMTP id E895A62008B;
	Fri, 23 Dec 2011 11:31:48 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzzz1202hzz8275bhz2dh668h839h944h)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
Received: from mail189-ch1 (localhost.localdomain [127.0.0.1]) by mail189-ch1
	(MessageSwitch) id 1324639906647674_20335;
	Fri, 23 Dec 2011 11:31:46 +0000 (UTC)
Received: from CH1EHSMHS030.bigfish.com (snatpool1.int.messaging.microsoft.com
	[10.43.68.245])	by mail189-ch1.bigfish.com (Postfix) with ESMTP id
	9A30520112;	Fri, 23 Dec 2011 11:31:46 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	CH1EHSMHS030.bigfish.com (10.43.70.30) with Microsoft SMTP Server id
	14.1.225.23; Fri, 23 Dec 2011 11:31:06 +0000
X-WSS-ID: 0LWNMO4-01-1GE-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2FD19102809D;	Fri, 23 Dec 2011 05:31:15 -0600 (CST)
Received: from SAUSEXDAG02.amd.com (163.181.55.2) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Fri, 23 Dec 2011 05:31:34 -0600
Received: from storexhtp02.amd.com (172.24.4.4) by sausexdag02.amd.com
	(163.181.55.2) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Fri, 23 Dec 2011 05:31:16 -0600
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Fri, 23 Dec 2011
	06:30:43 -0500
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id A817649C65C; Fri, 23 Dec 2011
	11:30:42 +0000 (GMT)
Received: from gran.amd.com (gran.osrc.amd.com [165.204.15.57])	by
	mail.osrc.amd.com (Postfix) with ESMTP id 69320594884; Fri, 23 Dec 2011
	12:30:42 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: b70cf1dcb110f79546f3efac3201a08d70c8b96e
Message-ID: <b70cf1dcb110f79546f3.1324639760@gran.amd.com>
In-Reply-To: <patchbomb.1324639749@gran.amd.com>
References: <patchbomb.1324639749@gran.amd.com>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Fri, 23 Dec 2011 12:29:20 +0100
From: Wei Wang <wei.wang2@amd.com>
To: <JBeulich@suse.com>, <Ian.Jackson@eu.citrix.com>,
	<Ian.Campbell@citrix.com>, <keir@xen.org>
X-OriginatorOrg: amd.com
Cc: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 11 of 16] amd iommu: Add a new flag to
 indication iommuv2 feature enabled or not
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Wei Wang <wei.wang2@amd.com>
# Date 1324569405 -3600
# Node ID b70cf1dcb110f79546f3efac3201a08d70c8b96e
# Parent  30b1f434160d989be5e0bb6c6956bb7e3985db59
amd iommu: Add a new flag to indication iommuv2 feature enabled or not.
Hypercalls should return early on non-iommuv2 systems.

Signed-off-by: Wei Wang <wei.wang2@amd.com>

diff -r 30b1f434160d -r b70cf1dcb110 xen/drivers/passthrough/amd/iommu_guest.c
--- a/xen/drivers/passthrough/amd/iommu_guest.c	Thu Dec 22 16:56:41 2011 +0100
+++ b/xen/drivers/passthrough/amd/iommu_guest.c	Thu Dec 22 16:56:45 2011 +0100
@@ -48,6 +48,8 @@
         (reg)->hi = (val >> 32) & 0xFFFFFFFF; \
     } while(0)
 
+extern bool_t iommuv2_enabled;
+
 static unsigned int machine_bdf(struct domain *d, uint16_t guest_bdf)
 {
     struct pci_dev *pdev;
@@ -819,6 +821,9 @@ int guest_iommu_set_base(struct domain *
     p2m_type_t t;
     struct guest_iommu *iommu = domain_iommu(d);
 
+    if ( !is_hvm_domain(d) || !iommuv2_enabled )
+        return 1;
+
     iommu->mmio_base = base;
     base >>= PAGE_SHIFT;
 
@@ -878,7 +883,7 @@ int guest_iommu_init(struct domain* d)
     struct guest_iommu *iommu;
     struct hvm_iommu *hd  = domain_hvm_iommu(d);
 
-    if ( !is_hvm_domain(d) )
+    if ( !is_hvm_domain(d) || !iommuv2_enabled )
         return 0;
 
     iommu = xzalloc(struct guest_iommu);
@@ -902,13 +907,11 @@ int guest_iommu_init(struct domain* d)
 
 void guest_iommu_destroy(struct domain *d)
 {
-    struct guest_iommu *iommu;
+    struct guest_iommu *iommu = domain_iommu(d);
 
-    if ( !is_hvm_domain(d) )
+    if ( !is_hvm_domain(d) || !iommuv2_enabled )
         return;
 
-    iommu = domain_iommu(d);
-
     tasklet_kill(&iommu->cmd_buffer_tasklet);
     xfree(iommu);
 
@@ -919,6 +922,9 @@ static int guest_iommu_mmio_range(struct
 {
     struct guest_iommu *iommu = vcpu_iommu(v);
 
+    if ( !iommu_found() || !iommuv2_enabled )
+        return 0;
+
     return ( addr >= iommu->mmio_base && 
              addr < (iommu->mmio_base + IOMMU_MMIO_SIZE) );
 }
@@ -935,7 +941,7 @@ int iommu_bind_bdf(struct domain* d, uin
     struct pci_dev *pdev;
     int ret = -ENODEV;
 
-    if ( !iommu_found() )
+    if ( !iommu_found() || !iommuv2_enabled )
         return 0;
 
     spin_lock(&pcidevs_lock);
@@ -960,7 +966,7 @@ void iommu_set_msi(struct domain* d, uin
 {
     struct guest_iommu *iommu = domain_iommu(d);
 
-    if ( !iommu_found() )
+    if ( !iommu_found() || !iommuv2_enabled )
         return;
 
     iommu->msi.vector = vector;
diff -r 30b1f434160d -r b70cf1dcb110 xen/drivers/passthrough/amd/iommu_init.c
--- a/xen/drivers/passthrough/amd/iommu_init.c	Thu Dec 22 16:56:41 2011 +0100
+++ b/xen/drivers/passthrough/amd/iommu_init.c	Thu Dec 22 16:56:45 2011 +0100
@@ -36,6 +36,7 @@ unsigned short ivrs_bdf_entries;
 static struct radix_tree_root ivrs_maps;
 struct list_head amd_iommu_head;
 struct table_struct device_table;
+bool_t iommuv2_enabled;
 
 static int iommu_has_ht_flag(struct amd_iommu *iommu, u8 mask)
 {
@@ -759,6 +760,10 @@ static void enable_iommu(struct amd_iomm
         amd_iommu_flush_all_caches(iommu);
 
     iommu->enabled = 1;
+
+    if ( iommu->features )
+        iommuv2_enabled = 1;
+
     spin_unlock_irqrestore(&iommu->lock, flags);
 
 }


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 23 11:31:47 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 Dec 2011 11: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.xensource.com>)
	id 1Re3LX-0001Bn-Ir; Fri, 23 Dec 2011 11:31:31 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Wang2@amd.com>) id 1Re3LV-00018W-FZ
	for xen-devel@lists.xensource.com; Fri, 23 Dec 2011 11:31:30 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1324639881!7997090!1
X-Originating-IP: [213.199.154.144]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 640 invoked from network); 23 Dec 2011 11:31:22 -0000
Received: from db3ehsobe006.messaging.microsoft.com (HELO
	DB3EHSOBE006.bigfish.com) (213.199.154.144)
	by server-14.tower-216.messagelabs.com with AES128-SHA encrypted SMTP;
	23 Dec 2011 11:31:22 -0000
Received: from mail114-db3-R.bigfish.com (10.3.81.243) by
	DB3EHSOBE006.bigfish.com (10.3.84.26) with Microsoft SMTP Server id
	14.1.225.23; Fri, 23 Dec 2011 11:31:08 +0000
Received: from mail114-db3 (localhost [127.0.0.1])	by
	mail114-db3-R.bigfish.com (Postfix) with ESMTP id 68C0B20439;
	Fri, 23 Dec 2011 11:31:48 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzc8kzz1202hzz8275bh5eeeKz2dh668h839h944h)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
Received: from mail114-db3 (localhost.localdomain [127.0.0.1]) by mail114-db3
	(MessageSwitch) id 1324639907393695_7609;
	Fri, 23 Dec 2011 11:31:47 +0000 (UTC)
Received: from DB3EHSMHS008.bigfish.com (unknown [10.3.81.243])	by
	mail114-db3.bigfish.com (Postfix) with ESMTP id 59BA1600043;
	Fri, 23 Dec 2011 11:31:47 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	DB3EHSMHS008.bigfish.com (10.3.87.108) with Microsoft SMTP Server id
	14.1.225.23; Fri, 23 Dec 2011 11:31:06 +0000
X-WSS-ID: 0LWNMO3-02-0X9-02
X-M-MSG: 
Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com
	[163.181.249.73])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp02.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2FB69C80DA;	Fri, 23 Dec 2011 05:31:15 -0600 (CST)
Received: from SAUSEXDAG02.amd.com (163.181.55.2) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Fri, 23 Dec 2011 05:31:34 -0600
Received: from storexhtp01.amd.com (172.24.4.3) by sausexdag02.amd.com
	(163.181.55.2) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Fri, 23 Dec 2011 05:31:16 -0600
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp01.amd.com
	(172.24.4.3) with Microsoft SMTP Server id 8.3.213.0; Fri, 23 Dec 2011
	06:30:42 -0500
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 8230449C65E; Fri, 23 Dec 2011
	11:30:41 +0000 (GMT)
Received: from gran.amd.com (gran.osrc.amd.com [165.204.15.57])	by
	mail.osrc.amd.com (Postfix) with ESMTP id 65EE3594884; Fri, 23 Dec 2011
	12:30:41 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 07f338ae663242ba9080f1ab84298894783da3e2
Message-ID: <07f338ae663242ba9080.1324639752@gran.amd.com>
In-Reply-To: <patchbomb.1324639749@gran.amd.com>
References: <patchbomb.1324639749@gran.amd.com>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Fri, 23 Dec 2011 12:29:12 +0100
From: Wei Wang <wei.wang2@amd.com>
To: <JBeulich@suse.com>, <Ian.Jackson@eu.citrix.com>,
	<Ian.Campbell@citrix.com>, <keir@xen.org>
X-OriginatorOrg: amd.com
Cc: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 03 of 16] amd iommu: Add iommu emulation for hvm
	guest
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Wei Wang <wei.wang2@amd.com>
# Date 1324569377 -3600
# Node ID 07f338ae663242ba9080f1ab84298894783da3e2
# Parent  e15194f68f99a64b65046ba3d29a3f06ccdca950
amd iommu: Add iommu emulation for hvm guest
ATS device driver that support PASID [1] and PRI [2] capabilites needs to work with iommu driver
in OS. If we want passthru ATS device to hvm guests using unmodified OS, we have to expose iommu
functionality to HVM guest.

Signed-off-by: Wei Wang <wei.wang2@amd.com>


[1] http://www.pcisig.com/specifications/pciexpress/specifications/ECN-PASID-ATS-2011-03-31.pdf
[2] http://www.pcisig.com/members/downloads/specifications/iov/ats_r1.1_26Jan09.pdf

diff -r e15194f68f99 -r 07f338ae6632 xen/drivers/passthrough/amd/Makefile
--- a/xen/drivers/passthrough/amd/Makefile	Thu Dec 22 16:56:14 2011 +0100
+++ b/xen/drivers/passthrough/amd/Makefile	Thu Dec 22 16:56:17 2011 +0100
@@ -5,3 +5,4 @@ obj-y += pci_amd_iommu.o
 obj-bin-y += iommu_acpi.init.o
 obj-y += iommu_intr.o
 obj-y += iommu_cmd.o
+obj-y += iommu_guest.o
diff -r e15194f68f99 -r 07f338ae6632 xen/drivers/passthrough/amd/iommu_cmd.c
--- a/xen/drivers/passthrough/amd/iommu_cmd.c	Thu Dec 22 16:56:14 2011 +0100
+++ b/xen/drivers/passthrough/amd/iommu_cmd.c	Thu Dec 22 16:56:17 2011 +0100
@@ -398,3 +398,15 @@ void amd_iommu_flush_all_caches(struct a
     invalidate_iommu_all(iommu);
     flush_command_buffer(iommu);
 }
+
+void amd_iommu_send_guest_cmd(struct amd_iommu *iommu, u32 cmd[])
+{
+    unsigned long flags;
+
+    spin_lock_irqsave(&iommu->lock, flags);
+
+    send_iommu_command(iommu, cmd);
+    flush_command_buffer(iommu);
+
+    spin_unlock_irqrestore(&iommu->lock, flags);
+}
diff -r e15194f68f99 -r 07f338ae6632 xen/drivers/passthrough/amd/iommu_guest.c
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/drivers/passthrough/amd/iommu_guest.c	Thu Dec 22 16:56:17 2011 +0100
@@ -0,0 +1,915 @@
+/*
+ * Copyright (C) 2011 Advanced Micro Devices, Inc.
+ * Author: Wei Wang <wei.wang2@amd.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307 USA
+ */
+
+#include <xen/sched.h>
+#include <asm/p2m.h>
+#include <asm/hvm/iommu.h>
+#include <asm/amd-iommu.h>
+#include <asm/hvm/svm/amd-iommu-proto.h>
+
+
+#define IOMMU_MMIO_SIZE                         0x8000
+#define IOMMU_MMIO_PAGE_NR                      0x8
+#define RING_BF_LENGTH_MASK                     0x0F000000
+#define RING_BF_LENGTH_SHIFT                    24
+
+#define PASMAX_9_bit                            0x8
+#define GUEST_CR3_1_LEVEL                       0x0
+#define GUEST_ADDRESS_SIZE_6_LEVEL              0x2
+#define HOST_ADDRESS_SIZE_6_LEVEL               0x2
+
+#define guest_iommu_set_status(iommu, bit) \
+        iommu_set_bit(&((iommu)->reg_status.lo), bit)
+
+#define guest_iommu_clear_status(iommu, bit) \
+        iommu_clear_bit(&((iommu)->reg_status.lo), bit)
+
+#define reg_to_u64(reg) (((uint64_t)reg.hi << 32) | reg.lo )
+#define u64_to_reg(reg, val) \
+    do  \
+    {   \
+        (reg)->lo = val & 0xFFFFFFFF; \
+        (reg)->hi = (val >> 32) & 0xFFFFFFFF; \
+    } while(0)
+
+static unsigned int machine_bdf(struct domain *d, uint16_t guest_bdf)
+{
+    return guest_bdf;
+}
+
+static uint16_t guest_bdf(struct domain *d, uint16_t machine_bdf)
+{
+    return machine_bdf;
+}
+
+static inline struct guest_iommu *domain_iommu(struct domain *d)
+{
+    return domain_hvm_iommu(d)->g_iommu;
+}
+
+static inline struct guest_iommu *vcpu_iommu(struct vcpu *v)
+{
+    return domain_hvm_iommu(v->domain)->g_iommu;
+}
+
+static void guest_iommu_enable(struct guest_iommu *iommu)
+{
+    iommu->enabled = 1;
+}
+
+static void guest_iommu_disable(struct guest_iommu *iommu)
+{
+    iommu->enabled = 0;
+}
+
+static uint64_t get_guest_cr3_from_dte(dev_entry_t *dte)
+{
+    uint64_t gcr3_1, gcr3_2, gcr3_3;
+
+    gcr3_1 = get_field_from_reg_u32(dte->data[1],
+                                    IOMMU_DEV_TABLE_GCR3_1_MASK,
+                                    IOMMU_DEV_TABLE_GCR3_1_SHIFT);
+    gcr3_2 = get_field_from_reg_u32(dte->data[2],
+                                    IOMMU_DEV_TABLE_GCR3_2_MASK,
+                                    IOMMU_DEV_TABLE_GCR3_2_SHIFT);
+    gcr3_3 = get_field_from_reg_u32(dte->data[3],
+                                    IOMMU_DEV_TABLE_GCR3_3_MASK,
+                                    IOMMU_DEV_TABLE_GCR3_3_SHIFT);
+
+    return ((gcr3_3 << 31) | (gcr3_2 << 15 ) | (gcr3_1 << 12)) >> PAGE_SHIFT;
+}
+
+static uint16_t get_domid_from_dte(dev_entry_t *dte)
+{
+    return get_field_from_reg_u32(dte->data[2], IOMMU_DEV_TABLE_DOMAIN_ID_MASK, 
+                                  IOMMU_DEV_TABLE_DOMAIN_ID_SHIFT);
+}
+
+static uint16_t get_glx_from_dte(dev_entry_t *dte)
+{
+    return get_field_from_reg_u32(dte->data[1], IOMMU_DEV_TABLE_GLX_MASK,
+                                  IOMMU_DEV_TABLE_GLX_SHIFT);
+}
+
+static uint16_t get_gv_from_dte(dev_entry_t *dte)
+{
+    return get_field_from_reg_u32(dte->data[1],IOMMU_DEV_TABLE_GV_MASK,
+                                  IOMMU_DEV_TABLE_GV_SHIFT);
+}
+
+static unsigned int host_domid(struct domain *d, uint64_t g_domid)
+{
+    /* Only support one PPR device in guest for now */
+    return d->domain_id;
+}
+
+static unsigned long get_gfn_from_base_reg(uint64_t base_raw)
+{ 
+    uint64_t addr_lo, addr_hi, addr64;
+
+    addr_lo = iommu_get_addr_lo_from_reg(base_raw & DMA_32BIT_MASK);
+    addr_hi = iommu_get_addr_hi_from_reg(base_raw >> 32);
+    addr64 = (addr_hi << 32) | (addr_lo << PAGE_SHIFT);
+
+    ASSERT ( addr64 != 0 );
+
+    return addr64 >> PAGE_SHIFT;
+}
+
+static void guest_iommu_deliver_msi(struct domain *d)
+{
+    uint8_t vector, dest, dest_mode, delivery_mode, trig_mode;
+    struct guest_iommu *iommu = domain_iommu(d);
+
+    vector = iommu->msi.vector;
+    dest = iommu->msi.dest;
+    dest_mode = iommu->msi.dest_mode;
+    delivery_mode = iommu->msi.delivery_mode;
+    trig_mode = iommu->msi.trig_mode;
+
+    vmsi_deliver(d, vector, dest, dest_mode, delivery_mode, trig_mode);
+}
+
+static unsigned long guest_iommu_get_table_mfn(struct domain *d,
+                                               uint64_t base_raw,
+                                               unsigned int entry_size,
+                                               unsigned int pos)
+{
+    unsigned long idx, gfn, mfn;
+    p2m_type_t p2mt;
+
+    gfn = get_gfn_from_base_reg(base_raw);
+    idx = (pos * entry_size) >> PAGE_SHIFT;
+
+    mfn = mfn_x(get_gfn(d, gfn + idx, &p2mt));
+    put_gfn(d, gfn);
+
+    return mfn;
+}
+
+static void guest_iommu_enable_dev_table(struct guest_iommu *iommu)
+{
+    uint32_t length_raw = get_field_from_reg_u32(iommu->dev_table.reg_base.lo,
+                                                 IOMMU_DEV_TABLE_SIZE_MASK,
+                                                 IOMMU_DEV_TABLE_SIZE_SHIFT);
+    iommu->dev_table.size = (length_raw + 1) * PAGE_SIZE;
+}
+
+static void guest_iommu_enable_ring_buffer(struct guest_iommu *iommu,
+                                           struct guest_buffer *buffer,
+                                           uint32_t entry_size)
+{
+    uint32_t length_raw = get_field_from_reg_u32(buffer->reg_base.hi,
+                                                 RING_BF_LENGTH_MASK,
+                                                 RING_BF_LENGTH_SHIFT);
+    buffer->entries = 1 << length_raw;
+}
+
+void guest_iommu_add_ppr_log(struct domain *d, u32 entry[])
+{
+    uint16_t gdev_id;
+    unsigned long mfn, tail, head;
+    ppr_entry_t *log, *log_base;
+    struct guest_iommu *iommu;
+
+    iommu = domain_iommu(d);
+    tail = iommu_get_rb_pointer(iommu->ppr_log.reg_tail.lo);
+    head = iommu_get_rb_pointer(iommu->ppr_log.reg_head.lo);
+
+    if ( tail >= iommu->ppr_log.entries || head >= iommu->ppr_log.entries )
+    {
+        AMD_IOMMU_DEBUG("Error: guest iommu ppr log overflows\n");
+        guest_iommu_disable(iommu);
+        return;
+    }
+
+    mfn = guest_iommu_get_table_mfn(d, reg_to_u64(iommu->ppr_log.reg_base), 
+                                    sizeof(ppr_entry_t), tail);
+    ASSERT(mfn_valid(mfn));
+
+    log_base = map_domain_page(mfn);
+    log = log_base + tail % (PAGE_SIZE / sizeof(ppr_entry_t));
+
+    /* Convert physical device id back into virtual device id */
+    gdev_id = guest_bdf(d, iommu_get_devid_from_cmd(entry[0]));
+    iommu_set_devid_to_cmd(&entry[0], gdev_id);
+
+    memcpy(log, entry, sizeof(ppr_entry_t));
+
+    /* Now shift ppr log tail pointer */
+    if ( (++tail) >= iommu->ppr_log.entries )
+    {
+        tail = 0;
+        guest_iommu_set_status(iommu, IOMMU_STATUS_PPR_LOG_OVERFLOW_SHIFT);
+    }
+    iommu_set_rb_pointer(&iommu->ppr_log.reg_tail.lo, tail);
+    unmap_domain_page(log_base);
+
+    guest_iommu_deliver_msi(d);
+}
+
+void guest_iommu_add_event_log(struct domain *d, u32 entry[])
+{
+    uint16_t dev_id;
+    unsigned long mfn, tail, head;
+    event_entry_t *log, *log_base;
+    struct guest_iommu *iommu;
+
+    iommu = domain_iommu(d);
+    tail = iommu_get_rb_pointer(iommu->event_log.reg_tail.lo);
+    head = iommu_get_rb_pointer(iommu->event_log.reg_head.lo);
+
+    if ( tail >= iommu->event_log.entries || head >= iommu->event_log.entries )
+    {
+        AMD_IOMMU_DEBUG("Error: guest iommu event overflows\n");
+        guest_iommu_disable(iommu);
+        return;
+    }
+
+    mfn = guest_iommu_get_table_mfn(d, reg_to_u64(iommu->event_log.reg_base), 
+                                    sizeof(event_entry_t), tail);
+    ASSERT(mfn_valid(mfn));
+
+    log_base = map_domain_page(mfn);
+    log = log_base + tail % (PAGE_SIZE / sizeof(event_entry_t));
+
+    /* re-write physical device id into virtual device id */
+    dev_id = guest_bdf(d, iommu_get_devid_from_cmd(entry[0]));
+    iommu_set_devid_to_cmd(&entry[0], dev_id);
+    memcpy(log, entry, sizeof(event_entry_t));
+
+    /* Now shift event log tail pointer */
+    if ( (++tail) >= iommu->event_log.entries )
+    {
+        tail = 0;
+        guest_iommu_set_status(iommu, IOMMU_STATUS_EVENT_OVERFLOW_SHIFT);
+    }
+
+    iommu_set_rb_pointer(&iommu->event_log.reg_tail.lo, tail);
+    unmap_domain_page(log_base);
+
+    guest_iommu_deliver_msi(d);
+}
+
+static int do_complete_ppr_request(struct domain *d, cmd_entry_t *cmd)
+{
+    uint16_t dev_id;
+    struct amd_iommu *iommu;
+
+    dev_id = machine_bdf(d, iommu_get_devid_from_cmd(cmd->data[0]));
+    iommu = find_iommu_for_device(0, dev_id);
+
+    if ( !iommu )
+    {
+        AMD_IOMMU_DEBUG("%s Fail to find iommu for bdf %x\n", 
+                        __func__, dev_id);
+        return -ENODEV;
+    }
+
+    /* replace virtual device id into physical */
+    iommu_set_devid_to_cmd(&cmd->data[0], dev_id);
+    amd_iommu_send_guest_cmd(iommu, cmd->data);
+
+    return 0;
+}
+
+static int do_invalidate_pages(struct domain *d, cmd_entry_t *cmd)
+{
+    uint16_t gdom_id, hdom_id;
+    struct amd_iommu *iommu = NULL;
+
+    gdom_id = get_field_from_reg_u32(cmd->data[1],
+                                    IOMMU_INV_IOMMU_PAGES_DOMAIN_ID_MASK,
+                                    IOMMU_INV_IOMMU_PAGES_DOMAIN_ID_SHIFT);
+
+    hdom_id = host_domid(d, gdom_id);
+    set_field_in_reg_u32(hdom_id, cmd->data[1],
+                         IOMMU_INV_IOMMU_PAGES_DOMAIN_ID_MASK,
+                         IOMMU_INV_IOMMU_PAGES_DOMAIN_ID_SHIFT, &cmd->data[1]);
+
+    for_each_amd_iommu ( iommu )
+        amd_iommu_send_guest_cmd(iommu, cmd->data);
+
+    return 0;
+}
+
+static int do_invalidate_all(struct domain *d, cmd_entry_t *cmd)
+{
+    struct amd_iommu *iommu = NULL;
+
+    for_each_amd_iommu ( iommu )
+        amd_iommu_flush_all_pages(d);
+
+    return 0;
+}
+
+static int do_invalidate_iotlb_pages(struct domain *d, cmd_entry_t *cmd)
+{
+    struct amd_iommu *iommu;
+    uint16_t dev_id;
+
+    dev_id = machine_bdf(d, iommu_get_devid_from_cmd(cmd->data[0]));
+
+    iommu = find_iommu_for_device(0, dev_id);
+    if ( !iommu )
+    {
+        AMD_IOMMU_DEBUG("%s Fail to find iommu for bdf %x\n", 
+                         __func__, dev_id);
+        return -ENODEV;
+    }
+
+    iommu_set_devid_to_cmd(&cmd->data[0], dev_id);
+    amd_iommu_send_guest_cmd(iommu, cmd->data);
+
+    return 0;
+}
+
+static int do_completion_wait(struct domain *d, cmd_entry_t *cmd)
+{
+    bool_t com_wait_int_en, com_wait_int, i, s;
+    struct guest_iommu *iommu;
+    unsigned long gfn;
+    p2m_type_t p2mt;
+
+    iommu = domain_iommu(d);
+
+    i = iommu_get_bit(cmd->data[0], IOMMU_COMP_WAIT_I_FLAG_SHIFT);
+    s = iommu_get_bit(cmd->data[0], IOMMU_COMP_WAIT_S_FLAG_SHIFT);
+
+    if ( i )
+        guest_iommu_set_status(iommu, IOMMU_STATUS_COMP_WAIT_INT_SHIFT);
+
+    if ( s )
+    {
+        uint64_t gaddr_lo, gaddr_hi, gaddr_64, data;
+        void *vaddr;
+
+        data = (uint64_t) cmd->data[3] << 32 | cmd->data[2];
+        gaddr_lo = get_field_from_reg_u32(cmd->data[0],
+                                          IOMMU_COMP_WAIT_ADDR_LOW_MASK,
+                                          IOMMU_COMP_WAIT_ADDR_LOW_SHIFT);
+        gaddr_hi = get_field_from_reg_u32(cmd->data[1],
+                                          IOMMU_COMP_WAIT_ADDR_HIGH_MASK,
+                                          IOMMU_COMP_WAIT_ADDR_HIGH_SHIFT);
+
+        gaddr_64 = (gaddr_hi << 32) | (gaddr_lo << 3);
+
+        gfn = gaddr_64 >> PAGE_SHIFT;
+        vaddr = map_domain_page(mfn_x(get_gfn(d, gfn ,&p2mt)));
+        put_gfn(d, gfn);
+
+        write_u64_atomic((uint64_t*)(vaddr + (gaddr_64 & (PAGE_SIZE-1))), data);
+        unmap_domain_page(vaddr);
+    }
+
+    com_wait_int_en = iommu_get_bit(iommu->reg_ctrl.lo,
+                                    IOMMU_CONTROL_COMP_WAIT_INT_SHIFT);
+    com_wait_int = iommu_get_bit(iommu->reg_status.lo,
+                                 IOMMU_STATUS_COMP_WAIT_INT_SHIFT);
+
+    if ( com_wait_int_en && com_wait_int )
+        guest_iommu_deliver_msi(d);
+
+    return 0;
+}
+
+static int do_invalidate_dte(struct domain *d, cmd_entry_t *cmd)
+{
+    uint16_t gbdf, mbdf, req_id, gdom_id, hdom_id;
+    dev_entry_t *gdte, *mdte, *dte_base;
+    struct amd_iommu *iommu = NULL;
+    struct guest_iommu *g_iommu;
+    uint64_t gcr3_gfn, gcr3_mfn;
+    uint8_t glx, gv;
+    unsigned long dte_mfn, flags;
+    p2m_type_t p2mt;
+
+    g_iommu = domain_iommu(d);
+    gbdf = iommu_get_devid_from_cmd(cmd->data[0]);
+    mbdf = machine_bdf(d, gbdf);
+
+    /* Guest can only update DTEs for its passthru devices */
+    if ( mbdf == 0 || gbdf == 0 )
+        return 0;
+
+    /* Sometimes guest invalidates devices from non-exists dtes */
+    if ( (gbdf * sizeof(dev_entry_t)) > g_iommu->dev_table.size )
+        return 0;
+
+    dte_mfn = guest_iommu_get_table_mfn(d, 
+                                        reg_to_u64(g_iommu->dev_table.reg_base), 
+                                        sizeof(dev_entry_t), gbdf);
+    ASSERT(mfn_valid(dte_mfn));
+
+    dte_base = map_domain_page(dte_mfn);
+
+    gdte = dte_base + gbdf % (PAGE_SIZE / sizeof(dev_entry_t));
+
+    gdom_id  = get_domid_from_dte(gdte);
+    gcr3_gfn = get_guest_cr3_from_dte(gdte);
+
+    /* Do not update host dte before gcr3 has been set */
+    if ( gcr3_gfn == 0 )
+        return 0;
+
+    gcr3_mfn = mfn_x(get_gfn(d, gcr3_gfn, &p2mt));
+    put_gfn(d, gcr3_gfn);
+
+    ASSERT(mfn_valid(gcr3_mfn));
+
+    /* Read guest dte information */
+    iommu = find_iommu_for_device(0, mbdf);
+    if ( !iommu )
+    {
+        AMD_IOMMU_DEBUG("%s Fail to find iommu!\n",__func__);
+        return -ENODEV;
+    }
+
+    glx = get_glx_from_dte(gdte);
+    gv = get_gv_from_dte(gdte);
+
+    unmap_domain_page(dte_base);
+
+    /* Setup host device entry */
+    hdom_id = host_domid(d, gdom_id);
+    req_id = get_dma_requestor_id(iommu->seg, mbdf);
+    mdte = iommu->dev_table.buffer + (req_id * sizeof(dev_entry_t));
+
+    spin_lock_irqsave(&iommu->lock, flags);
+    iommu_dte_set_guest_cr3((u32*)mdte, hdom_id, 
+                            gcr3_mfn << PAGE_SHIFT, gv, glx);
+
+    amd_iommu_flush_device(iommu, req_id);
+    spin_unlock_irqrestore(&iommu->lock, flags);
+
+    return 0;
+}
+
+static void guest_iommu_process_command(unsigned long _d)
+{
+    unsigned long opcode, tail, head, entries_per_page, cmd_mfn;
+    cmd_entry_t *cmd, *cmd_base;
+    struct domain *d;
+    struct guest_iommu *iommu;
+
+    d = (struct domain*) _d;
+    iommu = domain_iommu(d);
+
+    if ( !iommu->enabled )
+        return;
+
+    head = iommu_get_rb_pointer(iommu->cmd_buffer.reg_head.lo);
+    tail = iommu_get_rb_pointer(iommu->cmd_buffer.reg_tail.lo);
+
+    /* Tail pointer is rolled over by guest driver, value outside
+     * cmd_buffer_entries cause iommu disabled 
+     */
+
+    if ( tail >= iommu->cmd_buffer.entries  || 
+         head >= iommu->cmd_buffer.entries )
+    {
+        AMD_IOMMU_DEBUG("Error: guest iommu cmd buffer overflows\n");
+        guest_iommu_disable(iommu);
+        return;
+    }
+
+    entries_per_page = PAGE_SIZE / sizeof(cmd_entry_t);
+
+    while ( head != tail )
+    {
+        int ret = 0;
+
+        cmd_mfn = guest_iommu_get_table_mfn(d, 
+                                        reg_to_u64(iommu->cmd_buffer.reg_base),
+                                        sizeof(cmd_entry_t), head);
+        ASSERT(mfn_valid(cmd_mfn));
+
+        cmd_base = map_domain_page(cmd_mfn);
+        cmd = cmd_base + head % entries_per_page;
+
+        opcode = get_field_from_reg_u32(cmd->data[1], 
+                                        IOMMU_CMD_OPCODE_MASK,
+                                        IOMMU_CMD_OPCODE_SHIFT);
+        switch ( opcode )
+        {
+            case IOMMU_CMD_COMPLETION_WAIT:
+                ret = do_completion_wait(d, cmd);
+                break;
+            case IOMMU_CMD_INVALIDATE_DEVTAB_ENTRY:
+                ret = do_invalidate_dte(d, cmd);
+                break;
+            case IOMMU_CMD_INVALIDATE_IOMMU_PAGES:
+                ret = do_invalidate_pages(d, cmd);
+                break;
+            case IOMMU_CMD_INVALIDATE_IOTLB_PAGES:
+                ret = do_invalidate_iotlb_pages(d, cmd);
+                break;
+            case IOMMU_CMD_INVALIDATE_INT_TABLE:
+                break;
+            case IOMMU_CMD_COMPLETE_PPR_REQUEST:
+                ret = do_complete_ppr_request(d, cmd);
+                break;
+            case IOMMU_CMD_INVALIDATE_IOMMU_ALL:
+                ret = do_invalidate_all(d, cmd);
+                break;
+            default:
+                AMD_IOMMU_DEBUG("CMD: Unknown command cmd_type = %lx "
+                                "head = %ld\n", opcode, head);
+                break;
+        }
+
+        unmap_domain_page(cmd_base);
+        if ( (++head) >= iommu->cmd_buffer.entries )
+            head = 0;
+        if ( ret )
+            guest_iommu_disable(iommu);
+    }
+
+    /* Now shift cmd buffer head pointer */ 
+    iommu_set_rb_pointer(&iommu->cmd_buffer.reg_head.lo, head);
+    return;
+}
+
+static int guest_iommu_write_ctrl(struct guest_iommu *iommu, uint64_t newctrl)
+{
+    bool_t cmd_en, event_en, iommu_en, ppr_en, ppr_log_en;
+    bool_t cmd_en_old, event_en_old, iommu_en_old;
+    bool_t cmd_run;
+
+    iommu_en = iommu_get_bit(newctrl, 
+                             IOMMU_CONTROL_TRANSLATION_ENABLE_SHIFT);
+    iommu_en_old = iommu_get_bit(iommu->reg_ctrl.lo,
+                                 IOMMU_CONTROL_TRANSLATION_ENABLE_SHIFT);
+
+    cmd_en = iommu_get_bit(newctrl, 
+                           IOMMU_CONTROL_COMMAND_BUFFER_ENABLE_SHIFT);
+    cmd_en_old = iommu_get_bit(iommu->reg_ctrl.lo,
+                               IOMMU_CONTROL_COMMAND_BUFFER_ENABLE_SHIFT);
+    cmd_run = iommu_get_bit(iommu->reg_status.lo, 
+
+                            IOMMU_STATUS_CMD_BUFFER_RUN_SHIFT);
+    event_en = iommu_get_bit(newctrl,
+                             IOMMU_CONTROL_EVENT_LOG_ENABLE_SHIFT);
+    event_en_old = iommu_get_bit(iommu->reg_ctrl.lo,
+                                 IOMMU_CONTROL_EVENT_LOG_ENABLE_SHIFT);
+
+    ppr_en = iommu_get_bit(newctrl, 
+                           IOMMU_CONTROL_PPR_ENABLE_SHIFT);
+    ppr_log_en = iommu_get_bit(newctrl,
+                               IOMMU_CONTROL_PPR_LOG_ENABLE_SHIFT);
+
+    if ( iommu_en )
+    {
+        guest_iommu_enable(iommu);
+        guest_iommu_enable_dev_table(iommu);
+    }
+
+    if ( iommu_en && cmd_en )
+    {
+        guest_iommu_enable_ring_buffer(iommu, &iommu->cmd_buffer,
+                                       sizeof(cmd_entry_t));
+        /* Enable iommu command processing */
+        tasklet_schedule(&iommu->cmd_buffer_tasklet);
+    }
+
+    if ( iommu_en && event_en )
+    {
+        guest_iommu_enable_ring_buffer(iommu, &iommu->event_log,
+                                       sizeof(event_entry_t));
+        guest_iommu_set_status(iommu, IOMMU_STATUS_EVENT_LOG_RUN_SHIFT);
+        guest_iommu_clear_status(iommu, IOMMU_STATUS_EVENT_OVERFLOW_SHIFT);
+    }
+
+    if ( iommu_en && ppr_en && ppr_log_en )
+    {
+        guest_iommu_enable_ring_buffer(iommu, &iommu->ppr_log,
+                                       sizeof(ppr_entry_t));
+        guest_iommu_set_status(iommu, IOMMU_STATUS_PPR_LOG_RUN_SHIFT);
+        guest_iommu_clear_status(iommu, IOMMU_STATUS_PPR_LOG_OVERFLOW_SHIFT);
+    }
+
+    if ( iommu_en && cmd_en_old && !cmd_en )
+    {
+        /* Disable iommu command processing */
+        tasklet_kill(&iommu->cmd_buffer_tasklet);
+    }
+
+    if ( event_en_old && !event_en )
+    {
+        guest_iommu_clear_status(iommu, IOMMU_STATUS_EVENT_LOG_RUN_SHIFT);
+    }
+
+    if ( !iommu_en && iommu_en_old )
+    {
+        guest_iommu_disable(iommu);
+    }
+
+    u64_to_reg(&iommu->reg_ctrl, newctrl);
+    return 0;
+}
+
+static uint64_t iommu_mmio_read64(struct guest_iommu *iommu, 
+                                  unsigned long offset)
+{
+    uint64_t val;
+
+    switch ( offset )
+    {
+        case IOMMU_DEV_TABLE_BASE_LOW_OFFSET:
+            val = reg_to_u64(iommu->dev_table.reg_base);
+            break;
+        case IOMMU_CMD_BUFFER_BASE_LOW_OFFSET:
+            val = reg_to_u64(iommu->cmd_buffer.reg_base);
+            break;
+        case IOMMU_EVENT_LOG_BASE_LOW_OFFSET:
+            val = reg_to_u64(iommu->event_log.reg_base);
+            break;
+        case IOMMU_PPR_LOG_BASE_LOW_OFFSET:
+            val = reg_to_u64(iommu->ppr_log.reg_base);
+            break;
+        case IOMMU_CMD_BUFFER_HEAD_OFFSET:
+            val = reg_to_u64(iommu->cmd_buffer.reg_head);
+            break;
+        case IOMMU_CMD_BUFFER_TAIL_OFFSET:
+            val = reg_to_u64(iommu->cmd_buffer.reg_tail);
+            break;
+        case IOMMU_EVENT_LOG_HEAD_OFFSET:;
+            val = reg_to_u64(iommu->event_log.reg_head);
+            break;
+        case IOMMU_EVENT_LOG_TAIL_OFFSET:
+            val = reg_to_u64(iommu->event_log.reg_tail);
+            break;
+        case IOMMU_PPR_LOG_HEAD_OFFSET:
+            val = reg_to_u64(iommu->ppr_log.reg_head);
+            break;
+        case IOMMU_PPR_LOG_TAIL_OFFSET:
+            val = reg_to_u64(iommu->ppr_log.reg_tail);
+            break;
+        case IOMMU_CONTROL_MMIO_OFFSET:
+            val = reg_to_u64(iommu->reg_ctrl);
+            break;
+        case IOMMU_STATUS_MMIO_OFFSET:
+            val = reg_to_u64(iommu->reg_status);
+            break;
+        case IOMMU_EXT_FEATURE_MMIO_OFFSET:
+            val = reg_to_u64(iommu->reg_ext_feature);
+            break;
+
+        default:
+            AMD_IOMMU_DEBUG("Guest reads unknown mmio offset = %lx\n", 
+                             offset);
+            val = 0;
+            break;
+    }
+
+    return val;
+}
+
+static int guest_iommu_mmio_read(struct vcpu *v, unsigned long addr,
+                                 unsigned long len, unsigned long *pval)
+{
+    struct guest_iommu *iommu = vcpu_iommu(v);
+    unsigned long offset;
+    uint64_t val;
+    uint32_t mmio, shift;
+    uint64_t mask = 0;
+
+    offset = addr - iommu->mmio_base;
+
+    if ( unlikely((offset & (len - 1 )) || (len > 8)) )
+    {
+        AMD_IOMMU_DEBUG("iommu mmio write access is not aligned." 
+                        "offset = %lx, len = %lx \n", offset, len);
+        return X86EMUL_UNHANDLEABLE;
+    }
+
+    mask = (len == 8) ? (~0ULL) : (1ULL << (len * 8)) - 1;
+    shift = (offset & 7u) * 8;
+
+    /* mmio access is always aligned on 8-byte boundary */
+    mmio = offset & (~7u);
+
+    spin_lock(&iommu->lock);
+    val = iommu_mmio_read64(iommu, mmio);
+    spin_unlock(&iommu->lock);
+
+    *pval = (val >> shift ) & mask;
+
+    return X86EMUL_OKAY;
+}
+
+static void guest_iommu_mmio_write64(struct guest_iommu *iommu, 
+                                    unsigned long offset, uint64_t val)
+{
+    switch ( offset )
+    {
+        case IOMMU_DEV_TABLE_BASE_LOW_OFFSET:
+            u64_to_reg(&iommu->dev_table.reg_base, val);
+            break;
+        case IOMMU_CMD_BUFFER_BASE_LOW_OFFSET: 
+            u64_to_reg(&iommu->cmd_buffer.reg_base, val);
+            break;
+        case IOMMU_EVENT_LOG_BASE_LOW_OFFSET:
+            u64_to_reg(&iommu->event_log.reg_base, val);
+        case IOMMU_PPR_LOG_BASE_LOW_OFFSET:
+            u64_to_reg(&iommu->ppr_log.reg_base, val);
+            break;
+        case IOMMU_CONTROL_MMIO_OFFSET:
+            guest_iommu_write_ctrl(iommu, val);
+            break;
+        case IOMMU_CMD_BUFFER_HEAD_OFFSET:
+            u64_to_reg(&iommu->cmd_buffer.reg_head, val);
+            break;
+        case IOMMU_CMD_BUFFER_TAIL_OFFSET:
+            u64_to_reg(&iommu->cmd_buffer.reg_tail, val);
+            tasklet_schedule(&iommu->cmd_buffer_tasklet);
+            break;
+        case IOMMU_EVENT_LOG_HEAD_OFFSET:
+            u64_to_reg(&iommu->event_log.reg_head, val);
+            break;
+        case IOMMU_EVENT_LOG_TAIL_OFFSET:
+            u64_to_reg(&iommu->event_log.reg_tail, val);
+            break;
+        case IOMMU_PPR_LOG_HEAD_OFFSET:
+            u64_to_reg(&iommu->ppr_log.reg_head, val);
+            break;
+        case IOMMU_PPR_LOG_TAIL_OFFSET:
+            u64_to_reg(&iommu->ppr_log.reg_tail, val);
+            break;
+        case IOMMU_STATUS_MMIO_OFFSET:
+            u64_to_reg(&iommu->reg_status, val);
+            break;
+
+        default:
+            AMD_IOMMU_DEBUG("guest writes unknown mmio offset = %lx, "
+                            "val = %lx\n", offset, val);
+            break;
+    }
+}
+
+static int guest_iommu_mmio_write(struct vcpu *v, unsigned long addr,
+                                  unsigned long len, unsigned long val)
+{
+    struct guest_iommu *iommu = vcpu_iommu(v);
+    unsigned long offset;
+    uint64_t reg_old, mmio;
+    uint32_t shift;
+    uint64_t mask = 0;
+
+    offset = addr - iommu->mmio_base;
+
+    if ( unlikely((offset & (len - 1 )) || (len > 8)) )
+    {
+        AMD_IOMMU_DEBUG("iommu mmio write access is not aligned." 
+                        "offset = %lx, len = %lx \n", offset, len);
+        return X86EMUL_UNHANDLEABLE;
+    }
+
+    mask = (len == 8) ? (~0ULL): (1ULL << (len * 8)) - 1;
+    shift = (offset & 7u) * 8;
+
+    /* mmio access is always aligned on 8-byte boundary */
+    mmio = offset & (~7u);
+
+    spin_lock(&iommu->lock);
+
+    reg_old = iommu_mmio_read64(iommu, mmio);
+    reg_old &= ~( mask << shift );
+    val = reg_old | ((val & mask) << shift );
+    guest_iommu_mmio_write64(iommu, mmio, val);
+
+    spin_unlock(&iommu->lock);
+
+    return X86EMUL_OKAY;
+}
+
+int guest_iommu_set_base(struct domain *d, uint64_t base)
+{
+    p2m_type_t t;
+    struct guest_iommu *iommu = domain_iommu(d);
+
+    iommu->mmio_base = base;
+    base >>= PAGE_SHIFT;
+
+    for ( int i = 0; i < IOMMU_MMIO_PAGE_NR; i++ )
+    {
+        unsigned long gfn = base + i;
+
+        get_gfn_query(d, gfn, &t);
+        p2m_change_type(d, gfn, t, p2m_mmio_dm);
+        put_gfn(d, gfn);
+    }
+
+    return 0;
+}
+
+/* Initialize mmio read only bits */
+static void guest_iommu_reg_init(struct guest_iommu *iommu)
+{
+    uint32_t lower, upper;
+
+    lower = upper = 0;
+    /* Support prefetch */
+    iommu_set_bit(&lower,IOMMU_EXT_FEATURE_PREFSUP_SHIFT);
+    /* Support PPR log */
+    iommu_set_bit(&lower,IOMMU_EXT_FEATURE_PPRSUP_SHIFT);
+    /* Support guest translation */
+    iommu_set_bit(&lower,IOMMU_EXT_FEATURE_GTSUP_SHIFT);
+    /* Support invalidate all command */
+    iommu_set_bit(&lower,IOMMU_EXT_FEATURE_IASUP_SHIFT);
+
+    /* Host translation size has 6 levels */
+    set_field_in_reg_u32(HOST_ADDRESS_SIZE_6_LEVEL, lower,
+                         IOMMU_EXT_FEATURE_HATS_MASK,
+                         IOMMU_EXT_FEATURE_HATS_SHIFT,
+                         &lower);
+    /* Guest translation size has 6 levels */
+    set_field_in_reg_u32(GUEST_ADDRESS_SIZE_6_LEVEL, lower,
+                         IOMMU_EXT_FEATURE_GATS_MASK,
+                         IOMMU_EXT_FEATURE_GATS_SHIFT,
+                         &lower);
+    /* Single level gCR3 */
+    set_field_in_reg_u32(GUEST_CR3_1_LEVEL, lower, 
+                         IOMMU_EXT_FEATURE_GLXSUP_MASK,
+                         IOMMU_EXT_FEATURE_GLXSUP_SHIFT, &lower);
+    /* 9 bit PASID */
+    set_field_in_reg_u32(PASMAX_9_bit, upper, 
+                         IOMMU_EXT_FEATURE_PASMAX_MASK,
+                         IOMMU_EXT_FEATURE_PASMAX_SHIFT, &upper);
+
+    iommu->reg_ext_feature.lo = lower;
+    iommu->reg_ext_feature.hi = upper;
+}
+
+/* Domain specific initialization */
+int guest_iommu_init(struct domain* d)
+{
+    struct guest_iommu *iommu;
+    struct hvm_iommu *hd  = domain_hvm_iommu(d);
+
+    if ( !is_hvm_domain(d) )
+        return 0;
+
+    iommu = xzalloc(struct guest_iommu);
+    if ( !iommu )
+    {
+        AMD_IOMMU_DEBUG("Error allocating guest iommu structure.\n");
+        return 1;
+    }
+
+    guest_iommu_reg_init(iommu);
+    iommu->domain = d;
+    hd->g_iommu = iommu;
+
+    tasklet_init(&iommu->cmd_buffer_tasklet,
+                 guest_iommu_process_command, (unsigned long)d);
+
+    spin_lock_init(&iommu->lock);
+
+    return 0;
+}
+
+void guest_iommu_destroy(struct domain *d)
+{
+    struct guest_iommu *iommu;
+
+    if ( !is_hvm_domain(d) )
+        return;
+
+    iommu = domain_iommu(d);
+
+    tasklet_kill(&iommu->cmd_buffer_tasklet);
+    xfree(iommu);
+
+    domain_hvm_iommu(d)->g_iommu = NULL;
+}
+
+static int guest_iommu_mmio_range(struct vcpu *v, unsigned long addr)
+{
+    struct guest_iommu *iommu = vcpu_iommu(v);
+
+    return ( addr >= iommu->mmio_base && 
+             addr < (iommu->mmio_base + IOMMU_MMIO_SIZE) );
+}
+
+const struct hvm_mmio_handler iommu_mmio_handler = {
+    .check_handler = guest_iommu_mmio_range,
+    .read_handler = guest_iommu_mmio_read,
+    .write_handler = guest_iommu_mmio_write
+};
diff -r e15194f68f99 -r 07f338ae6632 xen/drivers/passthrough/amd/iommu_map.c
--- a/xen/drivers/passthrough/amd/iommu_map.c	Thu Dec 22 16:56:14 2011 +0100
+++ b/xen/drivers/passthrough/amd/iommu_map.c	Thu Dec 22 16:56:17 2011 +0100
@@ -234,6 +234,53 @@ void __init iommu_dte_add_device_entry(u
     dte[3] = entry;
 }
 
+void iommu_dte_set_guest_cr3(u32 *dte, u16 dom_id, u64 gcr3, 
+                             int gv, unsigned int glx)
+{
+    u32 entry, gcr3_1, gcr3_2, gcr3_3;
+
+    gcr3_3 = gcr3 >> 31;
+    gcr3_2 = (gcr3 >> 15) & 0xFFFF;
+    gcr3_1 = (gcr3 >> PAGE_SHIFT) & 0x7;
+
+    /* I bit must be set when gcr3 is enabled */
+    entry = dte[3];
+    set_field_in_reg_u32(IOMMU_CONTROL_ENABLED, entry,
+                         IOMMU_DEV_TABLE_IOTLB_SUPPORT_MASK,
+                         IOMMU_DEV_TABLE_IOTLB_SUPPORT_SHIFT, &entry);
+    /* update gcr3 */
+    set_field_in_reg_u32(gcr3_3, entry,
+                         IOMMU_DEV_TABLE_GCR3_3_MASK,
+                         IOMMU_DEV_TABLE_GCR3_3_SHIFT, &entry);
+    dte[3] = entry;
+
+    set_field_in_reg_u32(dom_id, entry,
+                         IOMMU_DEV_TABLE_DOMAIN_ID_MASK,
+                         IOMMU_DEV_TABLE_DOMAIN_ID_SHIFT, &entry);
+    /* update gcr3 */
+    entry = dte[2];
+    set_field_in_reg_u32(gcr3_2, entry,
+                         IOMMU_DEV_TABLE_GCR3_2_MASK,
+                         IOMMU_DEV_TABLE_GCR3_2_SHIFT, &entry);
+    dte[2] = entry;
+
+    entry = dte[1];
+    /* Enable GV bit */
+    set_field_in_reg_u32(!!gv, entry,
+                         IOMMU_DEV_TABLE_GV_MASK,
+                         IOMMU_DEV_TABLE_GV_SHIFT, &entry);
+
+    /* 1 level guest cr3 table  */
+    set_field_in_reg_u32(glx, entry,
+                         IOMMU_DEV_TABLE_GLX_MASK,
+                         IOMMU_DEV_TABLE_GLX_SHIFT, &entry);
+    /* update gcr3 */
+    set_field_in_reg_u32(gcr3_1, entry,
+                         IOMMU_DEV_TABLE_GCR3_1_MASK,
+                         IOMMU_DEV_TABLE_GCR3_1_SHIFT, &entry);
+    dte[1] = entry;
+}
+
 u64 amd_iommu_get_next_table_from_pte(u32 *entry)
 {
     u64 addr_lo, addr_hi, ptr;
diff -r e15194f68f99 -r 07f338ae6632 xen/drivers/passthrough/amd/pci_amd_iommu.c
--- a/xen/drivers/passthrough/amd/pci_amd_iommu.c	Thu Dec 22 16:56:14 2011 +0100
+++ b/xen/drivers/passthrough/amd/pci_amd_iommu.c	Thu Dec 22 16:56:17 2011 +0100
@@ -260,6 +260,8 @@ static int amd_iommu_domain_init(struct 
 
     hd->domain_id = d->domain_id;
 
+    guest_iommu_init(d);
+
     return 0;
 }
 
@@ -443,6 +445,7 @@ static void deallocate_iommu_page_tables
 
 static void amd_iommu_domain_destroy(struct domain *d)
 {
+    guest_iommu_destroy(d);
     deallocate_iommu_page_tables(d);
     amd_iommu_flush_all_pages(d);
 }
diff -r e15194f68f99 -r 07f338ae6632 xen/include/asm-x86/amd-iommu.h
--- a/xen/include/asm-x86/amd-iommu.h	Thu Dec 22 16:56:14 2011 +0100
+++ b/xen/include/asm-x86/amd-iommu.h	Thu Dec 22 16:56:17 2011 +0100
@@ -24,6 +24,7 @@
 #include <xen/types.h>
 #include <xen/list.h>
 #include <xen/spinlock.h>
+#include <xen/tasklet.h>
 #include <asm/hvm/svm/amd-iommu-defs.h>
 
 #define iommu_found()           (!list_empty(&amd_iommu_head))
@@ -130,4 +131,55 @@ struct ivrs_mappings *get_ivrs_mappings(
 int iterate_ivrs_mappings(int (*)(u16 seg, struct ivrs_mappings *));
 int iterate_ivrs_entries(int (*)(u16 seg, struct ivrs_mappings *));
 
+/* iommu tables in guest space */
+struct mmio_reg {
+    uint32_t    lo;
+    uint32_t    hi;
+};
+
+struct guest_dev_table {
+    struct mmio_reg         reg_base;
+    uint32_t                size;
+};
+
+struct guest_buffer {
+    struct mmio_reg         reg_base;
+    struct mmio_reg         reg_tail;
+    struct mmio_reg         reg_head;
+    uint32_t                entries;
+};
+
+struct guest_iommu_msi {
+    uint8_t                 vector;
+    uint8_t                 dest;
+    uint8_t                 dest_mode;
+    uint8_t                 delivery_mode;
+    uint8_t                 trig_mode;
+};
+
+/* virtual IOMMU structure */
+struct guest_iommu {
+
+    struct domain          *domain;
+    spinlock_t              lock;
+    bool_t                  enabled;
+
+    struct guest_dev_table  dev_table;
+    struct guest_buffer     cmd_buffer;
+    struct guest_buffer     event_log;
+    struct guest_buffer     ppr_log;
+
+    struct tasklet          cmd_buffer_tasklet;
+
+    uint64_t                mmio_base;             /* MMIO base address */
+
+    /* MMIO regs */
+    struct mmio_reg         reg_ctrl;              /* MMIO offset 0018h */
+    struct mmio_reg         reg_status;            /* MMIO offset 2020h */
+    struct mmio_reg         reg_ext_feature;       /* MMIO offset 0030h */
+
+    /* guest interrupt settings */
+    struct guest_iommu_msi  msi;
+};
+
 #endif /* _ASM_X86_64_AMD_IOMMU_H */
diff -r e15194f68f99 -r 07f338ae6632 xen/include/asm-x86/hvm/svm/amd-iommu-defs.h
--- a/xen/include/asm-x86/hvm/svm/amd-iommu-defs.h	Thu Dec 22 16:56:14 2011 +0100
+++ b/xen/include/asm-x86/hvm/svm/amd-iommu-defs.h	Thu Dec 22 16:56:17 2011 +0100
@@ -117,6 +117,13 @@
 #define IOMMU_DEV_TABLE_PAGE_TABLE_PTR_LOW_SHIFT	12
 
 /* DeviceTable Entry[63:32] */
+#define IOMMU_DEV_TABLE_GV_SHIFT                    23
+#define IOMMU_DEV_TABLE_GV_MASK                     0x800000
+#define IOMMU_DEV_TABLE_GLX_SHIFT                   24
+#define IOMMU_DEV_TABLE_GLX_MASK                    0x3000000
+#define IOMMU_DEV_TABLE_GCR3_1_SHIFT                26
+#define IOMMU_DEV_TABLE_GCR3_1_MASK                 0x1c000000
+
 #define IOMMU_DEV_TABLE_PAGE_TABLE_PTR_HIGH_MASK	0x000FFFFF
 #define IOMMU_DEV_TABLE_PAGE_TABLE_PTR_HIGH_SHIFT	0
 #define IOMMU_DEV_TABLE_IO_READ_PERMISSION_MASK		0x20000000
@@ -127,6 +134,8 @@
 /* DeviceTable Entry[95:64] */
 #define IOMMU_DEV_TABLE_DOMAIN_ID_MASK	0x0000FFFF
 #define IOMMU_DEV_TABLE_DOMAIN_ID_SHIFT	0
+#define IOMMU_DEV_TABLE_GCR3_2_SHIFT                16
+#define IOMMU_DEV_TABLE_GCR3_2_MASK                 0xFFFF0000
 
 /* DeviceTable Entry[127:96] */
 #define IOMMU_DEV_TABLE_IOTLB_SUPPORT_MASK		0x00000001
@@ -155,6 +164,8 @@
 #define IOMMU_DEV_TABLE_INT_TABLE_IGN_UNMAPPED_SHIFT      5
 #define IOMMU_DEV_TABLE_INT_TABLE_PTR_LOW_MASK      0xFFFFFFC0
 #define IOMMU_DEV_TABLE_INT_TABLE_PTR_LOW_SHIFT     6
+#define IOMMU_DEV_TABLE_GCR3_3_SHIFT                11
+#define IOMMU_DEV_TABLE_GCR3_3_MASK                 0xfffff800
 
 /* DeviceTable Entry[191:160] */
 #define IOMMU_DEV_TABLE_INT_TABLE_PTR_HIGH_MASK     0x000FFFFF
@@ -164,7 +175,6 @@
 #define IOMMU_DEV_TABLE_INT_CONTROL_MASK        0x30000000
 #define IOMMU_DEV_TABLE_INT_CONTROL_SHIFT       28
 
-
 /* Command Buffer */
 #define IOMMU_CMD_BUFFER_BASE_LOW_OFFSET	0x08
 #define IOMMU_CMD_BUFFER_BASE_HIGH_OFFSET	0x0C
@@ -192,6 +202,7 @@
 #define IOMMU_CMD_INVALIDATE_IOMMU_PAGES	0x3
 #define IOMMU_CMD_INVALIDATE_IOTLB_PAGES	0x4
 #define IOMMU_CMD_INVALIDATE_INT_TABLE		0x5
+#define IOMMU_CMD_COMPLETE_PPR_REQUEST      0x7
 #define IOMMU_CMD_INVALIDATE_IOMMU_ALL      0x8
 
 /* COMPLETION_WAIT command */
@@ -282,6 +293,28 @@
 #define IOMMU_EVENT_DEVICE_ID_MASK           0x0000FFFF
 #define IOMMU_EVENT_DEVICE_ID_SHIFT          0
 
+/* PPR Log */
+#define IOMMU_PPR_LOG_ENTRY_SIZE                        16
+#define IOMMU_PPR_LOG_POWER_OF2_ENTRIES_PER_PAGE        8
+#define IOMMU_PPR_LOG_U32_PER_ENTRY   (IOMMU_PPR_LOG_ENTRY_SIZE / 4)
+
+#define IOMMU_PPR_LOG_BASE_LOW_OFFSET                   0x0038
+#define IOMMU_PPR_LOG_BASE_HIGH_OFFSET                  0x003C
+#define IOMMU_PPR_LOG_BASE_LOW_MASK                     0xFFFFF000
+#define IOMMU_PPR_LOG_BASE_LOW_SHIFT                    12
+#define IOMMU_PPR_LOG_BASE_HIGH_MASK                    0x000FFFFF
+#define IOMMU_PPR_LOG_BASE_HIGH_SHIFT                   0
+#define IOMMU_PPR_LOG_LENGTH_MASK                       0x0F000000
+#define IOMMU_PPR_LOG_LENGTH_SHIFT                      24
+#define IOMMU_PPR_LOG_HEAD_MASK                         0x0007FFF0
+#define IOMMU_PPR_LOG_HEAD_SHIFT                        4
+#define IOMMU_PPR_LOG_TAIL_MASK                         0x0007FFF0
+#define IOMMU_PPR_LOG_TAIL_SHIFT                        4
+#define IOMMU_PPR_LOG_HEAD_OFFSET                       0x2030
+#define IOMMU_PPR_LOG_TAIL_OFFSET                       0x2038
+#define IOMMU_PPR_LOG_DEVICE_ID_MASK                    0x0000FFFF
+#define IOMMU_PPR_LOG_DEVICE_ID_SHIFT                   0
+
 /* Control Register */
 #define IOMMU_CONTROL_MMIO_OFFSET			0x18
 #define IOMMU_CONTROL_TRANSLATION_ENABLE_MASK		0x00000001
@@ -309,6 +342,11 @@
 #define IOMMU_CONTROL_RESTART_MASK			0x80000000
 #define IOMMU_CONTROL_RESTART_SHIFT			31
 
+#define IOMMU_CONTROL_PPR_LOG_ENABLE_SHIFT      13
+#define IOMMU_CONTROL_PPR_INT_SHIFT             14
+#define IOMMU_CONTROL_PPR_ENABLE_SHIFT          15
+#define IOMMU_CONTROL_GT_ENABLE_SHIFT           16
+
 /* Exclusion Register */
 #define IOMMU_EXCLUSION_BASE_LOW_OFFSET		0x20
 #define IOMMU_EXCLUSION_BASE_HIGH_OFFSET	0x24
@@ -342,7 +380,8 @@
 #define IOMMU_EXT_FEATURE_HATS_MASK                     0x00000C00
 #define IOMMU_EXT_FEATURE_GATS_SHIFT                    0x12
 #define IOMMU_EXT_FEATURE_GATS_MASK                     0x00003000
-#define IOMMU_EXT_FEATURE_GLXSUP                        0x14
+#define IOMMU_EXT_FEATURE_GLXSUP_SHIFT                  0x14
+#define IOMMU_EXT_FEATURE_GLXSUP_MASK                   0x0000C000
 
 #define IOMMU_EXT_FEATURE_PASMAX_SHIFT                  0x0
 #define IOMMU_EXT_FEATURE_PASMAX_MASK                   0x0000001F
@@ -359,6 +398,9 @@
 #define IOMMU_STATUS_EVENT_LOG_RUN_SHIFT	3
 #define IOMMU_STATUS_CMD_BUFFER_RUN_MASK	0x00000010
 #define IOMMU_STATUS_CMD_BUFFER_RUN_SHIFT	4
+#define IOMMU_STATUS_PPR_LOG_OVERFLOW_SHIFT     5
+#define IOMMU_STATUS_PPR_LOG_INT_SHIFT          6
+#define IOMMU_STATUS_PPR_LOG_RUN_SHIFT          7
 
 /* I/O Page Table */
 #define IOMMU_PAGE_TABLE_ENTRY_SIZE	8
diff -r e15194f68f99 -r 07f338ae6632 xen/include/asm-x86/hvm/svm/amd-iommu-proto.h
--- a/xen/include/asm-x86/hvm/svm/amd-iommu-proto.h	Thu Dec 22 16:56:14 2011 +0100
+++ b/xen/include/asm-x86/hvm/svm/amd-iommu-proto.h	Thu Dec 22 16:56:17 2011 +0100
@@ -71,6 +71,8 @@ void amd_iommu_set_root_page_table(
     u32 *dte, u64 root_ptr, u16 domain_id, u8 paging_mode, u8 valid);
 void iommu_dte_set_iotlb(u32 *dte, u8 i);
 void iommu_dte_add_device_entry(u32 *dte, struct ivrs_mappings *ivrs_dev);
+void iommu_dte_set_guest_cr3(u32 *dte, u16 dom_id, u64 gcr3, 
+                             int gv, unsigned int glx);
 
 /* send cmd to iommu */
 void amd_iommu_flush_all_pages(struct domain *d);
@@ -106,6 +108,14 @@ void amd_iommu_resume(void);
 void amd_iommu_suspend(void);
 void amd_iommu_crash_shutdown(void);
 
+/* guest iommu support */
+void amd_iommu_send_guest_cmd(struct amd_iommu *iommu, u32 cmd[]);
+void guest_iommu_add_ppr_log(struct domain *d, u32 entry[]);
+void guest_iommu_add_event_log(struct domain *d, u32 entry[]);
+int guest_iommu_init(struct domain* d);
+void guest_iommu_destroy(struct domain *d);
+int guest_iommu_set_base(struct domain *d, uint64_t base);
+
 static inline u32 get_field_from_reg_u32(u32 reg_value, u32 mask, u32 shift)
 {
     u32 field;
diff -r e15194f68f99 -r 07f338ae6632 xen/include/xen/hvm/iommu.h
--- a/xen/include/xen/hvm/iommu.h	Thu Dec 22 16:56:14 2011 +0100
+++ b/xen/include/xen/hvm/iommu.h	Thu Dec 22 16:56:17 2011 +0100
@@ -47,6 +47,7 @@ struct hvm_iommu {
     int domain_id;
     int paging_mode;
     struct page_info *root_table;
+    struct guest_iommu *g_iommu;
 
     /* iommu_ops */
     const struct iommu_ops *platform_ops;


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 23 11:31:47 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 Dec 2011 11: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.xensource.com>)
	id 1Re3LX-0001Bn-Ir; Fri, 23 Dec 2011 11:31:31 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Wang2@amd.com>) id 1Re3LV-00018W-FZ
	for xen-devel@lists.xensource.com; Fri, 23 Dec 2011 11:31:30 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1324639881!7997090!1
X-Originating-IP: [213.199.154.144]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 640 invoked from network); 23 Dec 2011 11:31:22 -0000
Received: from db3ehsobe006.messaging.microsoft.com (HELO
	DB3EHSOBE006.bigfish.com) (213.199.154.144)
	by server-14.tower-216.messagelabs.com with AES128-SHA encrypted SMTP;
	23 Dec 2011 11:31:22 -0000
Received: from mail114-db3-R.bigfish.com (10.3.81.243) by
	DB3EHSOBE006.bigfish.com (10.3.84.26) with Microsoft SMTP Server id
	14.1.225.23; Fri, 23 Dec 2011 11:31:08 +0000
Received: from mail114-db3 (localhost [127.0.0.1])	by
	mail114-db3-R.bigfish.com (Postfix) with ESMTP id 68C0B20439;
	Fri, 23 Dec 2011 11:31:48 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzc8kzz1202hzz8275bh5eeeKz2dh668h839h944h)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
Received: from mail114-db3 (localhost.localdomain [127.0.0.1]) by mail114-db3
	(MessageSwitch) id 1324639907393695_7609;
	Fri, 23 Dec 2011 11:31:47 +0000 (UTC)
Received: from DB3EHSMHS008.bigfish.com (unknown [10.3.81.243])	by
	mail114-db3.bigfish.com (Postfix) with ESMTP id 59BA1600043;
	Fri, 23 Dec 2011 11:31:47 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	DB3EHSMHS008.bigfish.com (10.3.87.108) with Microsoft SMTP Server id
	14.1.225.23; Fri, 23 Dec 2011 11:31:06 +0000
X-WSS-ID: 0LWNMO3-02-0X9-02
X-M-MSG: 
Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com
	[163.181.249.73])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp02.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2FB69C80DA;	Fri, 23 Dec 2011 05:31:15 -0600 (CST)
Received: from SAUSEXDAG02.amd.com (163.181.55.2) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Fri, 23 Dec 2011 05:31:34 -0600
Received: from storexhtp01.amd.com (172.24.4.3) by sausexdag02.amd.com
	(163.181.55.2) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Fri, 23 Dec 2011 05:31:16 -0600
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp01.amd.com
	(172.24.4.3) with Microsoft SMTP Server id 8.3.213.0; Fri, 23 Dec 2011
	06:30:42 -0500
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 8230449C65E; Fri, 23 Dec 2011
	11:30:41 +0000 (GMT)
Received: from gran.amd.com (gran.osrc.amd.com [165.204.15.57])	by
	mail.osrc.amd.com (Postfix) with ESMTP id 65EE3594884; Fri, 23 Dec 2011
	12:30:41 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 07f338ae663242ba9080f1ab84298894783da3e2
Message-ID: <07f338ae663242ba9080.1324639752@gran.amd.com>
In-Reply-To: <patchbomb.1324639749@gran.amd.com>
References: <patchbomb.1324639749@gran.amd.com>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Fri, 23 Dec 2011 12:29:12 +0100
From: Wei Wang <wei.wang2@amd.com>
To: <JBeulich@suse.com>, <Ian.Jackson@eu.citrix.com>,
	<Ian.Campbell@citrix.com>, <keir@xen.org>
X-OriginatorOrg: amd.com
Cc: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 03 of 16] amd iommu: Add iommu emulation for hvm
	guest
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Wei Wang <wei.wang2@amd.com>
# Date 1324569377 -3600
# Node ID 07f338ae663242ba9080f1ab84298894783da3e2
# Parent  e15194f68f99a64b65046ba3d29a3f06ccdca950
amd iommu: Add iommu emulation for hvm guest
ATS device driver that support PASID [1] and PRI [2] capabilites needs to work with iommu driver
in OS. If we want passthru ATS device to hvm guests using unmodified OS, we have to expose iommu
functionality to HVM guest.

Signed-off-by: Wei Wang <wei.wang2@amd.com>


[1] http://www.pcisig.com/specifications/pciexpress/specifications/ECN-PASID-ATS-2011-03-31.pdf
[2] http://www.pcisig.com/members/downloads/specifications/iov/ats_r1.1_26Jan09.pdf

diff -r e15194f68f99 -r 07f338ae6632 xen/drivers/passthrough/amd/Makefile
--- a/xen/drivers/passthrough/amd/Makefile	Thu Dec 22 16:56:14 2011 +0100
+++ b/xen/drivers/passthrough/amd/Makefile	Thu Dec 22 16:56:17 2011 +0100
@@ -5,3 +5,4 @@ obj-y += pci_amd_iommu.o
 obj-bin-y += iommu_acpi.init.o
 obj-y += iommu_intr.o
 obj-y += iommu_cmd.o
+obj-y += iommu_guest.o
diff -r e15194f68f99 -r 07f338ae6632 xen/drivers/passthrough/amd/iommu_cmd.c
--- a/xen/drivers/passthrough/amd/iommu_cmd.c	Thu Dec 22 16:56:14 2011 +0100
+++ b/xen/drivers/passthrough/amd/iommu_cmd.c	Thu Dec 22 16:56:17 2011 +0100
@@ -398,3 +398,15 @@ void amd_iommu_flush_all_caches(struct a
     invalidate_iommu_all(iommu);
     flush_command_buffer(iommu);
 }
+
+void amd_iommu_send_guest_cmd(struct amd_iommu *iommu, u32 cmd[])
+{
+    unsigned long flags;
+
+    spin_lock_irqsave(&iommu->lock, flags);
+
+    send_iommu_command(iommu, cmd);
+    flush_command_buffer(iommu);
+
+    spin_unlock_irqrestore(&iommu->lock, flags);
+}
diff -r e15194f68f99 -r 07f338ae6632 xen/drivers/passthrough/amd/iommu_guest.c
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/drivers/passthrough/amd/iommu_guest.c	Thu Dec 22 16:56:17 2011 +0100
@@ -0,0 +1,915 @@
+/*
+ * Copyright (C) 2011 Advanced Micro Devices, Inc.
+ * Author: Wei Wang <wei.wang2@amd.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307 USA
+ */
+
+#include <xen/sched.h>
+#include <asm/p2m.h>
+#include <asm/hvm/iommu.h>
+#include <asm/amd-iommu.h>
+#include <asm/hvm/svm/amd-iommu-proto.h>
+
+
+#define IOMMU_MMIO_SIZE                         0x8000
+#define IOMMU_MMIO_PAGE_NR                      0x8
+#define RING_BF_LENGTH_MASK                     0x0F000000
+#define RING_BF_LENGTH_SHIFT                    24
+
+#define PASMAX_9_bit                            0x8
+#define GUEST_CR3_1_LEVEL                       0x0
+#define GUEST_ADDRESS_SIZE_6_LEVEL              0x2
+#define HOST_ADDRESS_SIZE_6_LEVEL               0x2
+
+#define guest_iommu_set_status(iommu, bit) \
+        iommu_set_bit(&((iommu)->reg_status.lo), bit)
+
+#define guest_iommu_clear_status(iommu, bit) \
+        iommu_clear_bit(&((iommu)->reg_status.lo), bit)
+
+#define reg_to_u64(reg) (((uint64_t)reg.hi << 32) | reg.lo )
+#define u64_to_reg(reg, val) \
+    do  \
+    {   \
+        (reg)->lo = val & 0xFFFFFFFF; \
+        (reg)->hi = (val >> 32) & 0xFFFFFFFF; \
+    } while(0)
+
+static unsigned int machine_bdf(struct domain *d, uint16_t guest_bdf)
+{
+    return guest_bdf;
+}
+
+static uint16_t guest_bdf(struct domain *d, uint16_t machine_bdf)
+{
+    return machine_bdf;
+}
+
+static inline struct guest_iommu *domain_iommu(struct domain *d)
+{
+    return domain_hvm_iommu(d)->g_iommu;
+}
+
+static inline struct guest_iommu *vcpu_iommu(struct vcpu *v)
+{
+    return domain_hvm_iommu(v->domain)->g_iommu;
+}
+
+static void guest_iommu_enable(struct guest_iommu *iommu)
+{
+    iommu->enabled = 1;
+}
+
+static void guest_iommu_disable(struct guest_iommu *iommu)
+{
+    iommu->enabled = 0;
+}
+
+static uint64_t get_guest_cr3_from_dte(dev_entry_t *dte)
+{
+    uint64_t gcr3_1, gcr3_2, gcr3_3;
+
+    gcr3_1 = get_field_from_reg_u32(dte->data[1],
+                                    IOMMU_DEV_TABLE_GCR3_1_MASK,
+                                    IOMMU_DEV_TABLE_GCR3_1_SHIFT);
+    gcr3_2 = get_field_from_reg_u32(dte->data[2],
+                                    IOMMU_DEV_TABLE_GCR3_2_MASK,
+                                    IOMMU_DEV_TABLE_GCR3_2_SHIFT);
+    gcr3_3 = get_field_from_reg_u32(dte->data[3],
+                                    IOMMU_DEV_TABLE_GCR3_3_MASK,
+                                    IOMMU_DEV_TABLE_GCR3_3_SHIFT);
+
+    return ((gcr3_3 << 31) | (gcr3_2 << 15 ) | (gcr3_1 << 12)) >> PAGE_SHIFT;
+}
+
+static uint16_t get_domid_from_dte(dev_entry_t *dte)
+{
+    return get_field_from_reg_u32(dte->data[2], IOMMU_DEV_TABLE_DOMAIN_ID_MASK, 
+                                  IOMMU_DEV_TABLE_DOMAIN_ID_SHIFT);
+}
+
+static uint16_t get_glx_from_dte(dev_entry_t *dte)
+{
+    return get_field_from_reg_u32(dte->data[1], IOMMU_DEV_TABLE_GLX_MASK,
+                                  IOMMU_DEV_TABLE_GLX_SHIFT);
+}
+
+static uint16_t get_gv_from_dte(dev_entry_t *dte)
+{
+    return get_field_from_reg_u32(dte->data[1],IOMMU_DEV_TABLE_GV_MASK,
+                                  IOMMU_DEV_TABLE_GV_SHIFT);
+}
+
+static unsigned int host_domid(struct domain *d, uint64_t g_domid)
+{
+    /* Only support one PPR device in guest for now */
+    return d->domain_id;
+}
+
+static unsigned long get_gfn_from_base_reg(uint64_t base_raw)
+{ 
+    uint64_t addr_lo, addr_hi, addr64;
+
+    addr_lo = iommu_get_addr_lo_from_reg(base_raw & DMA_32BIT_MASK);
+    addr_hi = iommu_get_addr_hi_from_reg(base_raw >> 32);
+    addr64 = (addr_hi << 32) | (addr_lo << PAGE_SHIFT);
+
+    ASSERT ( addr64 != 0 );
+
+    return addr64 >> PAGE_SHIFT;
+}
+
+static void guest_iommu_deliver_msi(struct domain *d)
+{
+    uint8_t vector, dest, dest_mode, delivery_mode, trig_mode;
+    struct guest_iommu *iommu = domain_iommu(d);
+
+    vector = iommu->msi.vector;
+    dest = iommu->msi.dest;
+    dest_mode = iommu->msi.dest_mode;
+    delivery_mode = iommu->msi.delivery_mode;
+    trig_mode = iommu->msi.trig_mode;
+
+    vmsi_deliver(d, vector, dest, dest_mode, delivery_mode, trig_mode);
+}
+
+static unsigned long guest_iommu_get_table_mfn(struct domain *d,
+                                               uint64_t base_raw,
+                                               unsigned int entry_size,
+                                               unsigned int pos)
+{
+    unsigned long idx, gfn, mfn;
+    p2m_type_t p2mt;
+
+    gfn = get_gfn_from_base_reg(base_raw);
+    idx = (pos * entry_size) >> PAGE_SHIFT;
+
+    mfn = mfn_x(get_gfn(d, gfn + idx, &p2mt));
+    put_gfn(d, gfn);
+
+    return mfn;
+}
+
+static void guest_iommu_enable_dev_table(struct guest_iommu *iommu)
+{
+    uint32_t length_raw = get_field_from_reg_u32(iommu->dev_table.reg_base.lo,
+                                                 IOMMU_DEV_TABLE_SIZE_MASK,
+                                                 IOMMU_DEV_TABLE_SIZE_SHIFT);
+    iommu->dev_table.size = (length_raw + 1) * PAGE_SIZE;
+}
+
+static void guest_iommu_enable_ring_buffer(struct guest_iommu *iommu,
+                                           struct guest_buffer *buffer,
+                                           uint32_t entry_size)
+{
+    uint32_t length_raw = get_field_from_reg_u32(buffer->reg_base.hi,
+                                                 RING_BF_LENGTH_MASK,
+                                                 RING_BF_LENGTH_SHIFT);
+    buffer->entries = 1 << length_raw;
+}
+
+void guest_iommu_add_ppr_log(struct domain *d, u32 entry[])
+{
+    uint16_t gdev_id;
+    unsigned long mfn, tail, head;
+    ppr_entry_t *log, *log_base;
+    struct guest_iommu *iommu;
+
+    iommu = domain_iommu(d);
+    tail = iommu_get_rb_pointer(iommu->ppr_log.reg_tail.lo);
+    head = iommu_get_rb_pointer(iommu->ppr_log.reg_head.lo);
+
+    if ( tail >= iommu->ppr_log.entries || head >= iommu->ppr_log.entries )
+    {
+        AMD_IOMMU_DEBUG("Error: guest iommu ppr log overflows\n");
+        guest_iommu_disable(iommu);
+        return;
+    }
+
+    mfn = guest_iommu_get_table_mfn(d, reg_to_u64(iommu->ppr_log.reg_base), 
+                                    sizeof(ppr_entry_t), tail);
+    ASSERT(mfn_valid(mfn));
+
+    log_base = map_domain_page(mfn);
+    log = log_base + tail % (PAGE_SIZE / sizeof(ppr_entry_t));
+
+    /* Convert physical device id back into virtual device id */
+    gdev_id = guest_bdf(d, iommu_get_devid_from_cmd(entry[0]));
+    iommu_set_devid_to_cmd(&entry[0], gdev_id);
+
+    memcpy(log, entry, sizeof(ppr_entry_t));
+
+    /* Now shift ppr log tail pointer */
+    if ( (++tail) >= iommu->ppr_log.entries )
+    {
+        tail = 0;
+        guest_iommu_set_status(iommu, IOMMU_STATUS_PPR_LOG_OVERFLOW_SHIFT);
+    }
+    iommu_set_rb_pointer(&iommu->ppr_log.reg_tail.lo, tail);
+    unmap_domain_page(log_base);
+
+    guest_iommu_deliver_msi(d);
+}
+
+void guest_iommu_add_event_log(struct domain *d, u32 entry[])
+{
+    uint16_t dev_id;
+    unsigned long mfn, tail, head;
+    event_entry_t *log, *log_base;
+    struct guest_iommu *iommu;
+
+    iommu = domain_iommu(d);
+    tail = iommu_get_rb_pointer(iommu->event_log.reg_tail.lo);
+    head = iommu_get_rb_pointer(iommu->event_log.reg_head.lo);
+
+    if ( tail >= iommu->event_log.entries || head >= iommu->event_log.entries )
+    {
+        AMD_IOMMU_DEBUG("Error: guest iommu event overflows\n");
+        guest_iommu_disable(iommu);
+        return;
+    }
+
+    mfn = guest_iommu_get_table_mfn(d, reg_to_u64(iommu->event_log.reg_base), 
+                                    sizeof(event_entry_t), tail);
+    ASSERT(mfn_valid(mfn));
+
+    log_base = map_domain_page(mfn);
+    log = log_base + tail % (PAGE_SIZE / sizeof(event_entry_t));
+
+    /* re-write physical device id into virtual device id */
+    dev_id = guest_bdf(d, iommu_get_devid_from_cmd(entry[0]));
+    iommu_set_devid_to_cmd(&entry[0], dev_id);
+    memcpy(log, entry, sizeof(event_entry_t));
+
+    /* Now shift event log tail pointer */
+    if ( (++tail) >= iommu->event_log.entries )
+    {
+        tail = 0;
+        guest_iommu_set_status(iommu, IOMMU_STATUS_EVENT_OVERFLOW_SHIFT);
+    }
+
+    iommu_set_rb_pointer(&iommu->event_log.reg_tail.lo, tail);
+    unmap_domain_page(log_base);
+
+    guest_iommu_deliver_msi(d);
+}
+
+static int do_complete_ppr_request(struct domain *d, cmd_entry_t *cmd)
+{
+    uint16_t dev_id;
+    struct amd_iommu *iommu;
+
+    dev_id = machine_bdf(d, iommu_get_devid_from_cmd(cmd->data[0]));
+    iommu = find_iommu_for_device(0, dev_id);
+
+    if ( !iommu )
+    {
+        AMD_IOMMU_DEBUG("%s Fail to find iommu for bdf %x\n", 
+                        __func__, dev_id);
+        return -ENODEV;
+    }
+
+    /* replace virtual device id into physical */
+    iommu_set_devid_to_cmd(&cmd->data[0], dev_id);
+    amd_iommu_send_guest_cmd(iommu, cmd->data);
+
+    return 0;
+}
+
+static int do_invalidate_pages(struct domain *d, cmd_entry_t *cmd)
+{
+    uint16_t gdom_id, hdom_id;
+    struct amd_iommu *iommu = NULL;
+
+    gdom_id = get_field_from_reg_u32(cmd->data[1],
+                                    IOMMU_INV_IOMMU_PAGES_DOMAIN_ID_MASK,
+                                    IOMMU_INV_IOMMU_PAGES_DOMAIN_ID_SHIFT);
+
+    hdom_id = host_domid(d, gdom_id);
+    set_field_in_reg_u32(hdom_id, cmd->data[1],
+                         IOMMU_INV_IOMMU_PAGES_DOMAIN_ID_MASK,
+                         IOMMU_INV_IOMMU_PAGES_DOMAIN_ID_SHIFT, &cmd->data[1]);
+
+    for_each_amd_iommu ( iommu )
+        amd_iommu_send_guest_cmd(iommu, cmd->data);
+
+    return 0;
+}
+
+static int do_invalidate_all(struct domain *d, cmd_entry_t *cmd)
+{
+    struct amd_iommu *iommu = NULL;
+
+    for_each_amd_iommu ( iommu )
+        amd_iommu_flush_all_pages(d);
+
+    return 0;
+}
+
+static int do_invalidate_iotlb_pages(struct domain *d, cmd_entry_t *cmd)
+{
+    struct amd_iommu *iommu;
+    uint16_t dev_id;
+
+    dev_id = machine_bdf(d, iommu_get_devid_from_cmd(cmd->data[0]));
+
+    iommu = find_iommu_for_device(0, dev_id);
+    if ( !iommu )
+    {
+        AMD_IOMMU_DEBUG("%s Fail to find iommu for bdf %x\n", 
+                         __func__, dev_id);
+        return -ENODEV;
+    }
+
+    iommu_set_devid_to_cmd(&cmd->data[0], dev_id);
+    amd_iommu_send_guest_cmd(iommu, cmd->data);
+
+    return 0;
+}
+
+static int do_completion_wait(struct domain *d, cmd_entry_t *cmd)
+{
+    bool_t com_wait_int_en, com_wait_int, i, s;
+    struct guest_iommu *iommu;
+    unsigned long gfn;
+    p2m_type_t p2mt;
+
+    iommu = domain_iommu(d);
+
+    i = iommu_get_bit(cmd->data[0], IOMMU_COMP_WAIT_I_FLAG_SHIFT);
+    s = iommu_get_bit(cmd->data[0], IOMMU_COMP_WAIT_S_FLAG_SHIFT);
+
+    if ( i )
+        guest_iommu_set_status(iommu, IOMMU_STATUS_COMP_WAIT_INT_SHIFT);
+
+    if ( s )
+    {
+        uint64_t gaddr_lo, gaddr_hi, gaddr_64, data;
+        void *vaddr;
+
+        data = (uint64_t) cmd->data[3] << 32 | cmd->data[2];
+        gaddr_lo = get_field_from_reg_u32(cmd->data[0],
+                                          IOMMU_COMP_WAIT_ADDR_LOW_MASK,
+                                          IOMMU_COMP_WAIT_ADDR_LOW_SHIFT);
+        gaddr_hi = get_field_from_reg_u32(cmd->data[1],
+                                          IOMMU_COMP_WAIT_ADDR_HIGH_MASK,
+                                          IOMMU_COMP_WAIT_ADDR_HIGH_SHIFT);
+
+        gaddr_64 = (gaddr_hi << 32) | (gaddr_lo << 3);
+
+        gfn = gaddr_64 >> PAGE_SHIFT;
+        vaddr = map_domain_page(mfn_x(get_gfn(d, gfn ,&p2mt)));
+        put_gfn(d, gfn);
+
+        write_u64_atomic((uint64_t*)(vaddr + (gaddr_64 & (PAGE_SIZE-1))), data);
+        unmap_domain_page(vaddr);
+    }
+
+    com_wait_int_en = iommu_get_bit(iommu->reg_ctrl.lo,
+                                    IOMMU_CONTROL_COMP_WAIT_INT_SHIFT);
+    com_wait_int = iommu_get_bit(iommu->reg_status.lo,
+                                 IOMMU_STATUS_COMP_WAIT_INT_SHIFT);
+
+    if ( com_wait_int_en && com_wait_int )
+        guest_iommu_deliver_msi(d);
+
+    return 0;
+}
+
+static int do_invalidate_dte(struct domain *d, cmd_entry_t *cmd)
+{
+    uint16_t gbdf, mbdf, req_id, gdom_id, hdom_id;
+    dev_entry_t *gdte, *mdte, *dte_base;
+    struct amd_iommu *iommu = NULL;
+    struct guest_iommu *g_iommu;
+    uint64_t gcr3_gfn, gcr3_mfn;
+    uint8_t glx, gv;
+    unsigned long dte_mfn, flags;
+    p2m_type_t p2mt;
+
+    g_iommu = domain_iommu(d);
+    gbdf = iommu_get_devid_from_cmd(cmd->data[0]);
+    mbdf = machine_bdf(d, gbdf);
+
+    /* Guest can only update DTEs for its passthru devices */
+    if ( mbdf == 0 || gbdf == 0 )
+        return 0;
+
+    /* Sometimes guest invalidates devices from non-exists dtes */
+    if ( (gbdf * sizeof(dev_entry_t)) > g_iommu->dev_table.size )
+        return 0;
+
+    dte_mfn = guest_iommu_get_table_mfn(d, 
+                                        reg_to_u64(g_iommu->dev_table.reg_base), 
+                                        sizeof(dev_entry_t), gbdf);
+    ASSERT(mfn_valid(dte_mfn));
+
+    dte_base = map_domain_page(dte_mfn);
+
+    gdte = dte_base + gbdf % (PAGE_SIZE / sizeof(dev_entry_t));
+
+    gdom_id  = get_domid_from_dte(gdte);
+    gcr3_gfn = get_guest_cr3_from_dte(gdte);
+
+    /* Do not update host dte before gcr3 has been set */
+    if ( gcr3_gfn == 0 )
+        return 0;
+
+    gcr3_mfn = mfn_x(get_gfn(d, gcr3_gfn, &p2mt));
+    put_gfn(d, gcr3_gfn);
+
+    ASSERT(mfn_valid(gcr3_mfn));
+
+    /* Read guest dte information */
+    iommu = find_iommu_for_device(0, mbdf);
+    if ( !iommu )
+    {
+        AMD_IOMMU_DEBUG("%s Fail to find iommu!\n",__func__);
+        return -ENODEV;
+    }
+
+    glx = get_glx_from_dte(gdte);
+    gv = get_gv_from_dte(gdte);
+
+    unmap_domain_page(dte_base);
+
+    /* Setup host device entry */
+    hdom_id = host_domid(d, gdom_id);
+    req_id = get_dma_requestor_id(iommu->seg, mbdf);
+    mdte = iommu->dev_table.buffer + (req_id * sizeof(dev_entry_t));
+
+    spin_lock_irqsave(&iommu->lock, flags);
+    iommu_dte_set_guest_cr3((u32*)mdte, hdom_id, 
+                            gcr3_mfn << PAGE_SHIFT, gv, glx);
+
+    amd_iommu_flush_device(iommu, req_id);
+    spin_unlock_irqrestore(&iommu->lock, flags);
+
+    return 0;
+}
+
+static void guest_iommu_process_command(unsigned long _d)
+{
+    unsigned long opcode, tail, head, entries_per_page, cmd_mfn;
+    cmd_entry_t *cmd, *cmd_base;
+    struct domain *d;
+    struct guest_iommu *iommu;
+
+    d = (struct domain*) _d;
+    iommu = domain_iommu(d);
+
+    if ( !iommu->enabled )
+        return;
+
+    head = iommu_get_rb_pointer(iommu->cmd_buffer.reg_head.lo);
+    tail = iommu_get_rb_pointer(iommu->cmd_buffer.reg_tail.lo);
+
+    /* Tail pointer is rolled over by guest driver, value outside
+     * cmd_buffer_entries cause iommu disabled 
+     */
+
+    if ( tail >= iommu->cmd_buffer.entries  || 
+         head >= iommu->cmd_buffer.entries )
+    {
+        AMD_IOMMU_DEBUG("Error: guest iommu cmd buffer overflows\n");
+        guest_iommu_disable(iommu);
+        return;
+    }
+
+    entries_per_page = PAGE_SIZE / sizeof(cmd_entry_t);
+
+    while ( head != tail )
+    {
+        int ret = 0;
+
+        cmd_mfn = guest_iommu_get_table_mfn(d, 
+                                        reg_to_u64(iommu->cmd_buffer.reg_base),
+                                        sizeof(cmd_entry_t), head);
+        ASSERT(mfn_valid(cmd_mfn));
+
+        cmd_base = map_domain_page(cmd_mfn);
+        cmd = cmd_base + head % entries_per_page;
+
+        opcode = get_field_from_reg_u32(cmd->data[1], 
+                                        IOMMU_CMD_OPCODE_MASK,
+                                        IOMMU_CMD_OPCODE_SHIFT);
+        switch ( opcode )
+        {
+            case IOMMU_CMD_COMPLETION_WAIT:
+                ret = do_completion_wait(d, cmd);
+                break;
+            case IOMMU_CMD_INVALIDATE_DEVTAB_ENTRY:
+                ret = do_invalidate_dte(d, cmd);
+                break;
+            case IOMMU_CMD_INVALIDATE_IOMMU_PAGES:
+                ret = do_invalidate_pages(d, cmd);
+                break;
+            case IOMMU_CMD_INVALIDATE_IOTLB_PAGES:
+                ret = do_invalidate_iotlb_pages(d, cmd);
+                break;
+            case IOMMU_CMD_INVALIDATE_INT_TABLE:
+                break;
+            case IOMMU_CMD_COMPLETE_PPR_REQUEST:
+                ret = do_complete_ppr_request(d, cmd);
+                break;
+            case IOMMU_CMD_INVALIDATE_IOMMU_ALL:
+                ret = do_invalidate_all(d, cmd);
+                break;
+            default:
+                AMD_IOMMU_DEBUG("CMD: Unknown command cmd_type = %lx "
+                                "head = %ld\n", opcode, head);
+                break;
+        }
+
+        unmap_domain_page(cmd_base);
+        if ( (++head) >= iommu->cmd_buffer.entries )
+            head = 0;
+        if ( ret )
+            guest_iommu_disable(iommu);
+    }
+
+    /* Now shift cmd buffer head pointer */ 
+    iommu_set_rb_pointer(&iommu->cmd_buffer.reg_head.lo, head);
+    return;
+}
+
+static int guest_iommu_write_ctrl(struct guest_iommu *iommu, uint64_t newctrl)
+{
+    bool_t cmd_en, event_en, iommu_en, ppr_en, ppr_log_en;
+    bool_t cmd_en_old, event_en_old, iommu_en_old;
+    bool_t cmd_run;
+
+    iommu_en = iommu_get_bit(newctrl, 
+                             IOMMU_CONTROL_TRANSLATION_ENABLE_SHIFT);
+    iommu_en_old = iommu_get_bit(iommu->reg_ctrl.lo,
+                                 IOMMU_CONTROL_TRANSLATION_ENABLE_SHIFT);
+
+    cmd_en = iommu_get_bit(newctrl, 
+                           IOMMU_CONTROL_COMMAND_BUFFER_ENABLE_SHIFT);
+    cmd_en_old = iommu_get_bit(iommu->reg_ctrl.lo,
+                               IOMMU_CONTROL_COMMAND_BUFFER_ENABLE_SHIFT);
+    cmd_run = iommu_get_bit(iommu->reg_status.lo, 
+
+                            IOMMU_STATUS_CMD_BUFFER_RUN_SHIFT);
+    event_en = iommu_get_bit(newctrl,
+                             IOMMU_CONTROL_EVENT_LOG_ENABLE_SHIFT);
+    event_en_old = iommu_get_bit(iommu->reg_ctrl.lo,
+                                 IOMMU_CONTROL_EVENT_LOG_ENABLE_SHIFT);
+
+    ppr_en = iommu_get_bit(newctrl, 
+                           IOMMU_CONTROL_PPR_ENABLE_SHIFT);
+    ppr_log_en = iommu_get_bit(newctrl,
+                               IOMMU_CONTROL_PPR_LOG_ENABLE_SHIFT);
+
+    if ( iommu_en )
+    {
+        guest_iommu_enable(iommu);
+        guest_iommu_enable_dev_table(iommu);
+    }
+
+    if ( iommu_en && cmd_en )
+    {
+        guest_iommu_enable_ring_buffer(iommu, &iommu->cmd_buffer,
+                                       sizeof(cmd_entry_t));
+        /* Enable iommu command processing */
+        tasklet_schedule(&iommu->cmd_buffer_tasklet);
+    }
+
+    if ( iommu_en && event_en )
+    {
+        guest_iommu_enable_ring_buffer(iommu, &iommu->event_log,
+                                       sizeof(event_entry_t));
+        guest_iommu_set_status(iommu, IOMMU_STATUS_EVENT_LOG_RUN_SHIFT);
+        guest_iommu_clear_status(iommu, IOMMU_STATUS_EVENT_OVERFLOW_SHIFT);
+    }
+
+    if ( iommu_en && ppr_en && ppr_log_en )
+    {
+        guest_iommu_enable_ring_buffer(iommu, &iommu->ppr_log,
+                                       sizeof(ppr_entry_t));
+        guest_iommu_set_status(iommu, IOMMU_STATUS_PPR_LOG_RUN_SHIFT);
+        guest_iommu_clear_status(iommu, IOMMU_STATUS_PPR_LOG_OVERFLOW_SHIFT);
+    }
+
+    if ( iommu_en && cmd_en_old && !cmd_en )
+    {
+        /* Disable iommu command processing */
+        tasklet_kill(&iommu->cmd_buffer_tasklet);
+    }
+
+    if ( event_en_old && !event_en )
+    {
+        guest_iommu_clear_status(iommu, IOMMU_STATUS_EVENT_LOG_RUN_SHIFT);
+    }
+
+    if ( !iommu_en && iommu_en_old )
+    {
+        guest_iommu_disable(iommu);
+    }
+
+    u64_to_reg(&iommu->reg_ctrl, newctrl);
+    return 0;
+}
+
+static uint64_t iommu_mmio_read64(struct guest_iommu *iommu, 
+                                  unsigned long offset)
+{
+    uint64_t val;
+
+    switch ( offset )
+    {
+        case IOMMU_DEV_TABLE_BASE_LOW_OFFSET:
+            val = reg_to_u64(iommu->dev_table.reg_base);
+            break;
+        case IOMMU_CMD_BUFFER_BASE_LOW_OFFSET:
+            val = reg_to_u64(iommu->cmd_buffer.reg_base);
+            break;
+        case IOMMU_EVENT_LOG_BASE_LOW_OFFSET:
+            val = reg_to_u64(iommu->event_log.reg_base);
+            break;
+        case IOMMU_PPR_LOG_BASE_LOW_OFFSET:
+            val = reg_to_u64(iommu->ppr_log.reg_base);
+            break;
+        case IOMMU_CMD_BUFFER_HEAD_OFFSET:
+            val = reg_to_u64(iommu->cmd_buffer.reg_head);
+            break;
+        case IOMMU_CMD_BUFFER_TAIL_OFFSET:
+            val = reg_to_u64(iommu->cmd_buffer.reg_tail);
+            break;
+        case IOMMU_EVENT_LOG_HEAD_OFFSET:;
+            val = reg_to_u64(iommu->event_log.reg_head);
+            break;
+        case IOMMU_EVENT_LOG_TAIL_OFFSET:
+            val = reg_to_u64(iommu->event_log.reg_tail);
+            break;
+        case IOMMU_PPR_LOG_HEAD_OFFSET:
+            val = reg_to_u64(iommu->ppr_log.reg_head);
+            break;
+        case IOMMU_PPR_LOG_TAIL_OFFSET:
+            val = reg_to_u64(iommu->ppr_log.reg_tail);
+            break;
+        case IOMMU_CONTROL_MMIO_OFFSET:
+            val = reg_to_u64(iommu->reg_ctrl);
+            break;
+        case IOMMU_STATUS_MMIO_OFFSET:
+            val = reg_to_u64(iommu->reg_status);
+            break;
+        case IOMMU_EXT_FEATURE_MMIO_OFFSET:
+            val = reg_to_u64(iommu->reg_ext_feature);
+            break;
+
+        default:
+            AMD_IOMMU_DEBUG("Guest reads unknown mmio offset = %lx\n", 
+                             offset);
+            val = 0;
+            break;
+    }
+
+    return val;
+}
+
+static int guest_iommu_mmio_read(struct vcpu *v, unsigned long addr,
+                                 unsigned long len, unsigned long *pval)
+{
+    struct guest_iommu *iommu = vcpu_iommu(v);
+    unsigned long offset;
+    uint64_t val;
+    uint32_t mmio, shift;
+    uint64_t mask = 0;
+
+    offset = addr - iommu->mmio_base;
+
+    if ( unlikely((offset & (len - 1 )) || (len > 8)) )
+    {
+        AMD_IOMMU_DEBUG("iommu mmio write access is not aligned." 
+                        "offset = %lx, len = %lx \n", offset, len);
+        return X86EMUL_UNHANDLEABLE;
+    }
+
+    mask = (len == 8) ? (~0ULL) : (1ULL << (len * 8)) - 1;
+    shift = (offset & 7u) * 8;
+
+    /* mmio access is always aligned on 8-byte boundary */
+    mmio = offset & (~7u);
+
+    spin_lock(&iommu->lock);
+    val = iommu_mmio_read64(iommu, mmio);
+    spin_unlock(&iommu->lock);
+
+    *pval = (val >> shift ) & mask;
+
+    return X86EMUL_OKAY;
+}
+
+static void guest_iommu_mmio_write64(struct guest_iommu *iommu, 
+                                    unsigned long offset, uint64_t val)
+{
+    switch ( offset )
+    {
+        case IOMMU_DEV_TABLE_BASE_LOW_OFFSET:
+            u64_to_reg(&iommu->dev_table.reg_base, val);
+            break;
+        case IOMMU_CMD_BUFFER_BASE_LOW_OFFSET: 
+            u64_to_reg(&iommu->cmd_buffer.reg_base, val);
+            break;
+        case IOMMU_EVENT_LOG_BASE_LOW_OFFSET:
+            u64_to_reg(&iommu->event_log.reg_base, val);
+        case IOMMU_PPR_LOG_BASE_LOW_OFFSET:
+            u64_to_reg(&iommu->ppr_log.reg_base, val);
+            break;
+        case IOMMU_CONTROL_MMIO_OFFSET:
+            guest_iommu_write_ctrl(iommu, val);
+            break;
+        case IOMMU_CMD_BUFFER_HEAD_OFFSET:
+            u64_to_reg(&iommu->cmd_buffer.reg_head, val);
+            break;
+        case IOMMU_CMD_BUFFER_TAIL_OFFSET:
+            u64_to_reg(&iommu->cmd_buffer.reg_tail, val);
+            tasklet_schedule(&iommu->cmd_buffer_tasklet);
+            break;
+        case IOMMU_EVENT_LOG_HEAD_OFFSET:
+            u64_to_reg(&iommu->event_log.reg_head, val);
+            break;
+        case IOMMU_EVENT_LOG_TAIL_OFFSET:
+            u64_to_reg(&iommu->event_log.reg_tail, val);
+            break;
+        case IOMMU_PPR_LOG_HEAD_OFFSET:
+            u64_to_reg(&iommu->ppr_log.reg_head, val);
+            break;
+        case IOMMU_PPR_LOG_TAIL_OFFSET:
+            u64_to_reg(&iommu->ppr_log.reg_tail, val);
+            break;
+        case IOMMU_STATUS_MMIO_OFFSET:
+            u64_to_reg(&iommu->reg_status, val);
+            break;
+
+        default:
+            AMD_IOMMU_DEBUG("guest writes unknown mmio offset = %lx, "
+                            "val = %lx\n", offset, val);
+            break;
+    }
+}
+
+static int guest_iommu_mmio_write(struct vcpu *v, unsigned long addr,
+                                  unsigned long len, unsigned long val)
+{
+    struct guest_iommu *iommu = vcpu_iommu(v);
+    unsigned long offset;
+    uint64_t reg_old, mmio;
+    uint32_t shift;
+    uint64_t mask = 0;
+
+    offset = addr - iommu->mmio_base;
+
+    if ( unlikely((offset & (len - 1 )) || (len > 8)) )
+    {
+        AMD_IOMMU_DEBUG("iommu mmio write access is not aligned." 
+                        "offset = %lx, len = %lx \n", offset, len);
+        return X86EMUL_UNHANDLEABLE;
+    }
+
+    mask = (len == 8) ? (~0ULL): (1ULL << (len * 8)) - 1;
+    shift = (offset & 7u) * 8;
+
+    /* mmio access is always aligned on 8-byte boundary */
+    mmio = offset & (~7u);
+
+    spin_lock(&iommu->lock);
+
+    reg_old = iommu_mmio_read64(iommu, mmio);
+    reg_old &= ~( mask << shift );
+    val = reg_old | ((val & mask) << shift );
+    guest_iommu_mmio_write64(iommu, mmio, val);
+
+    spin_unlock(&iommu->lock);
+
+    return X86EMUL_OKAY;
+}
+
+int guest_iommu_set_base(struct domain *d, uint64_t base)
+{
+    p2m_type_t t;
+    struct guest_iommu *iommu = domain_iommu(d);
+
+    iommu->mmio_base = base;
+    base >>= PAGE_SHIFT;
+
+    for ( int i = 0; i < IOMMU_MMIO_PAGE_NR; i++ )
+    {
+        unsigned long gfn = base + i;
+
+        get_gfn_query(d, gfn, &t);
+        p2m_change_type(d, gfn, t, p2m_mmio_dm);
+        put_gfn(d, gfn);
+    }
+
+    return 0;
+}
+
+/* Initialize mmio read only bits */
+static void guest_iommu_reg_init(struct guest_iommu *iommu)
+{
+    uint32_t lower, upper;
+
+    lower = upper = 0;
+    /* Support prefetch */
+    iommu_set_bit(&lower,IOMMU_EXT_FEATURE_PREFSUP_SHIFT);
+    /* Support PPR log */
+    iommu_set_bit(&lower,IOMMU_EXT_FEATURE_PPRSUP_SHIFT);
+    /* Support guest translation */
+    iommu_set_bit(&lower,IOMMU_EXT_FEATURE_GTSUP_SHIFT);
+    /* Support invalidate all command */
+    iommu_set_bit(&lower,IOMMU_EXT_FEATURE_IASUP_SHIFT);
+
+    /* Host translation size has 6 levels */
+    set_field_in_reg_u32(HOST_ADDRESS_SIZE_6_LEVEL, lower,
+                         IOMMU_EXT_FEATURE_HATS_MASK,
+                         IOMMU_EXT_FEATURE_HATS_SHIFT,
+                         &lower);
+    /* Guest translation size has 6 levels */
+    set_field_in_reg_u32(GUEST_ADDRESS_SIZE_6_LEVEL, lower,
+                         IOMMU_EXT_FEATURE_GATS_MASK,
+                         IOMMU_EXT_FEATURE_GATS_SHIFT,
+                         &lower);
+    /* Single level gCR3 */
+    set_field_in_reg_u32(GUEST_CR3_1_LEVEL, lower, 
+                         IOMMU_EXT_FEATURE_GLXSUP_MASK,
+                         IOMMU_EXT_FEATURE_GLXSUP_SHIFT, &lower);
+    /* 9 bit PASID */
+    set_field_in_reg_u32(PASMAX_9_bit, upper, 
+                         IOMMU_EXT_FEATURE_PASMAX_MASK,
+                         IOMMU_EXT_FEATURE_PASMAX_SHIFT, &upper);
+
+    iommu->reg_ext_feature.lo = lower;
+    iommu->reg_ext_feature.hi = upper;
+}
+
+/* Domain specific initialization */
+int guest_iommu_init(struct domain* d)
+{
+    struct guest_iommu *iommu;
+    struct hvm_iommu *hd  = domain_hvm_iommu(d);
+
+    if ( !is_hvm_domain(d) )
+        return 0;
+
+    iommu = xzalloc(struct guest_iommu);
+    if ( !iommu )
+    {
+        AMD_IOMMU_DEBUG("Error allocating guest iommu structure.\n");
+        return 1;
+    }
+
+    guest_iommu_reg_init(iommu);
+    iommu->domain = d;
+    hd->g_iommu = iommu;
+
+    tasklet_init(&iommu->cmd_buffer_tasklet,
+                 guest_iommu_process_command, (unsigned long)d);
+
+    spin_lock_init(&iommu->lock);
+
+    return 0;
+}
+
+void guest_iommu_destroy(struct domain *d)
+{
+    struct guest_iommu *iommu;
+
+    if ( !is_hvm_domain(d) )
+        return;
+
+    iommu = domain_iommu(d);
+
+    tasklet_kill(&iommu->cmd_buffer_tasklet);
+    xfree(iommu);
+
+    domain_hvm_iommu(d)->g_iommu = NULL;
+}
+
+static int guest_iommu_mmio_range(struct vcpu *v, unsigned long addr)
+{
+    struct guest_iommu *iommu = vcpu_iommu(v);
+
+    return ( addr >= iommu->mmio_base && 
+             addr < (iommu->mmio_base + IOMMU_MMIO_SIZE) );
+}
+
+const struct hvm_mmio_handler iommu_mmio_handler = {
+    .check_handler = guest_iommu_mmio_range,
+    .read_handler = guest_iommu_mmio_read,
+    .write_handler = guest_iommu_mmio_write
+};
diff -r e15194f68f99 -r 07f338ae6632 xen/drivers/passthrough/amd/iommu_map.c
--- a/xen/drivers/passthrough/amd/iommu_map.c	Thu Dec 22 16:56:14 2011 +0100
+++ b/xen/drivers/passthrough/amd/iommu_map.c	Thu Dec 22 16:56:17 2011 +0100
@@ -234,6 +234,53 @@ void __init iommu_dte_add_device_entry(u
     dte[3] = entry;
 }
 
+void iommu_dte_set_guest_cr3(u32 *dte, u16 dom_id, u64 gcr3, 
+                             int gv, unsigned int glx)
+{
+    u32 entry, gcr3_1, gcr3_2, gcr3_3;
+
+    gcr3_3 = gcr3 >> 31;
+    gcr3_2 = (gcr3 >> 15) & 0xFFFF;
+    gcr3_1 = (gcr3 >> PAGE_SHIFT) & 0x7;
+
+    /* I bit must be set when gcr3 is enabled */
+    entry = dte[3];
+    set_field_in_reg_u32(IOMMU_CONTROL_ENABLED, entry,
+                         IOMMU_DEV_TABLE_IOTLB_SUPPORT_MASK,
+                         IOMMU_DEV_TABLE_IOTLB_SUPPORT_SHIFT, &entry);
+    /* update gcr3 */
+    set_field_in_reg_u32(gcr3_3, entry,
+                         IOMMU_DEV_TABLE_GCR3_3_MASK,
+                         IOMMU_DEV_TABLE_GCR3_3_SHIFT, &entry);
+    dte[3] = entry;
+
+    set_field_in_reg_u32(dom_id, entry,
+                         IOMMU_DEV_TABLE_DOMAIN_ID_MASK,
+                         IOMMU_DEV_TABLE_DOMAIN_ID_SHIFT, &entry);
+    /* update gcr3 */
+    entry = dte[2];
+    set_field_in_reg_u32(gcr3_2, entry,
+                         IOMMU_DEV_TABLE_GCR3_2_MASK,
+                         IOMMU_DEV_TABLE_GCR3_2_SHIFT, &entry);
+    dte[2] = entry;
+
+    entry = dte[1];
+    /* Enable GV bit */
+    set_field_in_reg_u32(!!gv, entry,
+                         IOMMU_DEV_TABLE_GV_MASK,
+                         IOMMU_DEV_TABLE_GV_SHIFT, &entry);
+
+    /* 1 level guest cr3 table  */
+    set_field_in_reg_u32(glx, entry,
+                         IOMMU_DEV_TABLE_GLX_MASK,
+                         IOMMU_DEV_TABLE_GLX_SHIFT, &entry);
+    /* update gcr3 */
+    set_field_in_reg_u32(gcr3_1, entry,
+                         IOMMU_DEV_TABLE_GCR3_1_MASK,
+                         IOMMU_DEV_TABLE_GCR3_1_SHIFT, &entry);
+    dte[1] = entry;
+}
+
 u64 amd_iommu_get_next_table_from_pte(u32 *entry)
 {
     u64 addr_lo, addr_hi, ptr;
diff -r e15194f68f99 -r 07f338ae6632 xen/drivers/passthrough/amd/pci_amd_iommu.c
--- a/xen/drivers/passthrough/amd/pci_amd_iommu.c	Thu Dec 22 16:56:14 2011 +0100
+++ b/xen/drivers/passthrough/amd/pci_amd_iommu.c	Thu Dec 22 16:56:17 2011 +0100
@@ -260,6 +260,8 @@ static int amd_iommu_domain_init(struct 
 
     hd->domain_id = d->domain_id;
 
+    guest_iommu_init(d);
+
     return 0;
 }
 
@@ -443,6 +445,7 @@ static void deallocate_iommu_page_tables
 
 static void amd_iommu_domain_destroy(struct domain *d)
 {
+    guest_iommu_destroy(d);
     deallocate_iommu_page_tables(d);
     amd_iommu_flush_all_pages(d);
 }
diff -r e15194f68f99 -r 07f338ae6632 xen/include/asm-x86/amd-iommu.h
--- a/xen/include/asm-x86/amd-iommu.h	Thu Dec 22 16:56:14 2011 +0100
+++ b/xen/include/asm-x86/amd-iommu.h	Thu Dec 22 16:56:17 2011 +0100
@@ -24,6 +24,7 @@
 #include <xen/types.h>
 #include <xen/list.h>
 #include <xen/spinlock.h>
+#include <xen/tasklet.h>
 #include <asm/hvm/svm/amd-iommu-defs.h>
 
 #define iommu_found()           (!list_empty(&amd_iommu_head))
@@ -130,4 +131,55 @@ struct ivrs_mappings *get_ivrs_mappings(
 int iterate_ivrs_mappings(int (*)(u16 seg, struct ivrs_mappings *));
 int iterate_ivrs_entries(int (*)(u16 seg, struct ivrs_mappings *));
 
+/* iommu tables in guest space */
+struct mmio_reg {
+    uint32_t    lo;
+    uint32_t    hi;
+};
+
+struct guest_dev_table {
+    struct mmio_reg         reg_base;
+    uint32_t                size;
+};
+
+struct guest_buffer {
+    struct mmio_reg         reg_base;
+    struct mmio_reg         reg_tail;
+    struct mmio_reg         reg_head;
+    uint32_t                entries;
+};
+
+struct guest_iommu_msi {
+    uint8_t                 vector;
+    uint8_t                 dest;
+    uint8_t                 dest_mode;
+    uint8_t                 delivery_mode;
+    uint8_t                 trig_mode;
+};
+
+/* virtual IOMMU structure */
+struct guest_iommu {
+
+    struct domain          *domain;
+    spinlock_t              lock;
+    bool_t                  enabled;
+
+    struct guest_dev_table  dev_table;
+    struct guest_buffer     cmd_buffer;
+    struct guest_buffer     event_log;
+    struct guest_buffer     ppr_log;
+
+    struct tasklet          cmd_buffer_tasklet;
+
+    uint64_t                mmio_base;             /* MMIO base address */
+
+    /* MMIO regs */
+    struct mmio_reg         reg_ctrl;              /* MMIO offset 0018h */
+    struct mmio_reg         reg_status;            /* MMIO offset 2020h */
+    struct mmio_reg         reg_ext_feature;       /* MMIO offset 0030h */
+
+    /* guest interrupt settings */
+    struct guest_iommu_msi  msi;
+};
+
 #endif /* _ASM_X86_64_AMD_IOMMU_H */
diff -r e15194f68f99 -r 07f338ae6632 xen/include/asm-x86/hvm/svm/amd-iommu-defs.h
--- a/xen/include/asm-x86/hvm/svm/amd-iommu-defs.h	Thu Dec 22 16:56:14 2011 +0100
+++ b/xen/include/asm-x86/hvm/svm/amd-iommu-defs.h	Thu Dec 22 16:56:17 2011 +0100
@@ -117,6 +117,13 @@
 #define IOMMU_DEV_TABLE_PAGE_TABLE_PTR_LOW_SHIFT	12
 
 /* DeviceTable Entry[63:32] */
+#define IOMMU_DEV_TABLE_GV_SHIFT                    23
+#define IOMMU_DEV_TABLE_GV_MASK                     0x800000
+#define IOMMU_DEV_TABLE_GLX_SHIFT                   24
+#define IOMMU_DEV_TABLE_GLX_MASK                    0x3000000
+#define IOMMU_DEV_TABLE_GCR3_1_SHIFT                26
+#define IOMMU_DEV_TABLE_GCR3_1_MASK                 0x1c000000
+
 #define IOMMU_DEV_TABLE_PAGE_TABLE_PTR_HIGH_MASK	0x000FFFFF
 #define IOMMU_DEV_TABLE_PAGE_TABLE_PTR_HIGH_SHIFT	0
 #define IOMMU_DEV_TABLE_IO_READ_PERMISSION_MASK		0x20000000
@@ -127,6 +134,8 @@
 /* DeviceTable Entry[95:64] */
 #define IOMMU_DEV_TABLE_DOMAIN_ID_MASK	0x0000FFFF
 #define IOMMU_DEV_TABLE_DOMAIN_ID_SHIFT	0
+#define IOMMU_DEV_TABLE_GCR3_2_SHIFT                16
+#define IOMMU_DEV_TABLE_GCR3_2_MASK                 0xFFFF0000
 
 /* DeviceTable Entry[127:96] */
 #define IOMMU_DEV_TABLE_IOTLB_SUPPORT_MASK		0x00000001
@@ -155,6 +164,8 @@
 #define IOMMU_DEV_TABLE_INT_TABLE_IGN_UNMAPPED_SHIFT      5
 #define IOMMU_DEV_TABLE_INT_TABLE_PTR_LOW_MASK      0xFFFFFFC0
 #define IOMMU_DEV_TABLE_INT_TABLE_PTR_LOW_SHIFT     6
+#define IOMMU_DEV_TABLE_GCR3_3_SHIFT                11
+#define IOMMU_DEV_TABLE_GCR3_3_MASK                 0xfffff800
 
 /* DeviceTable Entry[191:160] */
 #define IOMMU_DEV_TABLE_INT_TABLE_PTR_HIGH_MASK     0x000FFFFF
@@ -164,7 +175,6 @@
 #define IOMMU_DEV_TABLE_INT_CONTROL_MASK        0x30000000
 #define IOMMU_DEV_TABLE_INT_CONTROL_SHIFT       28
 
-
 /* Command Buffer */
 #define IOMMU_CMD_BUFFER_BASE_LOW_OFFSET	0x08
 #define IOMMU_CMD_BUFFER_BASE_HIGH_OFFSET	0x0C
@@ -192,6 +202,7 @@
 #define IOMMU_CMD_INVALIDATE_IOMMU_PAGES	0x3
 #define IOMMU_CMD_INVALIDATE_IOTLB_PAGES	0x4
 #define IOMMU_CMD_INVALIDATE_INT_TABLE		0x5
+#define IOMMU_CMD_COMPLETE_PPR_REQUEST      0x7
 #define IOMMU_CMD_INVALIDATE_IOMMU_ALL      0x8
 
 /* COMPLETION_WAIT command */
@@ -282,6 +293,28 @@
 #define IOMMU_EVENT_DEVICE_ID_MASK           0x0000FFFF
 #define IOMMU_EVENT_DEVICE_ID_SHIFT          0
 
+/* PPR Log */
+#define IOMMU_PPR_LOG_ENTRY_SIZE                        16
+#define IOMMU_PPR_LOG_POWER_OF2_ENTRIES_PER_PAGE        8
+#define IOMMU_PPR_LOG_U32_PER_ENTRY   (IOMMU_PPR_LOG_ENTRY_SIZE / 4)
+
+#define IOMMU_PPR_LOG_BASE_LOW_OFFSET                   0x0038
+#define IOMMU_PPR_LOG_BASE_HIGH_OFFSET                  0x003C
+#define IOMMU_PPR_LOG_BASE_LOW_MASK                     0xFFFFF000
+#define IOMMU_PPR_LOG_BASE_LOW_SHIFT                    12
+#define IOMMU_PPR_LOG_BASE_HIGH_MASK                    0x000FFFFF
+#define IOMMU_PPR_LOG_BASE_HIGH_SHIFT                   0
+#define IOMMU_PPR_LOG_LENGTH_MASK                       0x0F000000
+#define IOMMU_PPR_LOG_LENGTH_SHIFT                      24
+#define IOMMU_PPR_LOG_HEAD_MASK                         0x0007FFF0
+#define IOMMU_PPR_LOG_HEAD_SHIFT                        4
+#define IOMMU_PPR_LOG_TAIL_MASK                         0x0007FFF0
+#define IOMMU_PPR_LOG_TAIL_SHIFT                        4
+#define IOMMU_PPR_LOG_HEAD_OFFSET                       0x2030
+#define IOMMU_PPR_LOG_TAIL_OFFSET                       0x2038
+#define IOMMU_PPR_LOG_DEVICE_ID_MASK                    0x0000FFFF
+#define IOMMU_PPR_LOG_DEVICE_ID_SHIFT                   0
+
 /* Control Register */
 #define IOMMU_CONTROL_MMIO_OFFSET			0x18
 #define IOMMU_CONTROL_TRANSLATION_ENABLE_MASK		0x00000001
@@ -309,6 +342,11 @@
 #define IOMMU_CONTROL_RESTART_MASK			0x80000000
 #define IOMMU_CONTROL_RESTART_SHIFT			31
 
+#define IOMMU_CONTROL_PPR_LOG_ENABLE_SHIFT      13
+#define IOMMU_CONTROL_PPR_INT_SHIFT             14
+#define IOMMU_CONTROL_PPR_ENABLE_SHIFT          15
+#define IOMMU_CONTROL_GT_ENABLE_SHIFT           16
+
 /* Exclusion Register */
 #define IOMMU_EXCLUSION_BASE_LOW_OFFSET		0x20
 #define IOMMU_EXCLUSION_BASE_HIGH_OFFSET	0x24
@@ -342,7 +380,8 @@
 #define IOMMU_EXT_FEATURE_HATS_MASK                     0x00000C00
 #define IOMMU_EXT_FEATURE_GATS_SHIFT                    0x12
 #define IOMMU_EXT_FEATURE_GATS_MASK                     0x00003000
-#define IOMMU_EXT_FEATURE_GLXSUP                        0x14
+#define IOMMU_EXT_FEATURE_GLXSUP_SHIFT                  0x14
+#define IOMMU_EXT_FEATURE_GLXSUP_MASK                   0x0000C000
 
 #define IOMMU_EXT_FEATURE_PASMAX_SHIFT                  0x0
 #define IOMMU_EXT_FEATURE_PASMAX_MASK                   0x0000001F
@@ -359,6 +398,9 @@
 #define IOMMU_STATUS_EVENT_LOG_RUN_SHIFT	3
 #define IOMMU_STATUS_CMD_BUFFER_RUN_MASK	0x00000010
 #define IOMMU_STATUS_CMD_BUFFER_RUN_SHIFT	4
+#define IOMMU_STATUS_PPR_LOG_OVERFLOW_SHIFT     5
+#define IOMMU_STATUS_PPR_LOG_INT_SHIFT          6
+#define IOMMU_STATUS_PPR_LOG_RUN_SHIFT          7
 
 /* I/O Page Table */
 #define IOMMU_PAGE_TABLE_ENTRY_SIZE	8
diff -r e15194f68f99 -r 07f338ae6632 xen/include/asm-x86/hvm/svm/amd-iommu-proto.h
--- a/xen/include/asm-x86/hvm/svm/amd-iommu-proto.h	Thu Dec 22 16:56:14 2011 +0100
+++ b/xen/include/asm-x86/hvm/svm/amd-iommu-proto.h	Thu Dec 22 16:56:17 2011 +0100
@@ -71,6 +71,8 @@ void amd_iommu_set_root_page_table(
     u32 *dte, u64 root_ptr, u16 domain_id, u8 paging_mode, u8 valid);
 void iommu_dte_set_iotlb(u32 *dte, u8 i);
 void iommu_dte_add_device_entry(u32 *dte, struct ivrs_mappings *ivrs_dev);
+void iommu_dte_set_guest_cr3(u32 *dte, u16 dom_id, u64 gcr3, 
+                             int gv, unsigned int glx);
 
 /* send cmd to iommu */
 void amd_iommu_flush_all_pages(struct domain *d);
@@ -106,6 +108,14 @@ void amd_iommu_resume(void);
 void amd_iommu_suspend(void);
 void amd_iommu_crash_shutdown(void);
 
+/* guest iommu support */
+void amd_iommu_send_guest_cmd(struct amd_iommu *iommu, u32 cmd[]);
+void guest_iommu_add_ppr_log(struct domain *d, u32 entry[]);
+void guest_iommu_add_event_log(struct domain *d, u32 entry[]);
+int guest_iommu_init(struct domain* d);
+void guest_iommu_destroy(struct domain *d);
+int guest_iommu_set_base(struct domain *d, uint64_t base);
+
 static inline u32 get_field_from_reg_u32(u32 reg_value, u32 mask, u32 shift)
 {
     u32 field;
diff -r e15194f68f99 -r 07f338ae6632 xen/include/xen/hvm/iommu.h
--- a/xen/include/xen/hvm/iommu.h	Thu Dec 22 16:56:14 2011 +0100
+++ b/xen/include/xen/hvm/iommu.h	Thu Dec 22 16:56:17 2011 +0100
@@ -47,6 +47,7 @@ struct hvm_iommu {
     int domain_id;
     int paging_mode;
     struct page_info *root_table;
+    struct guest_iommu *g_iommu;
 
     /* iommu_ops */
     const struct iommu_ops *platform_ops;


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 23 11:31:47 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 Dec 2011 11: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.xensource.com>)
	id 1Re3LS-00018x-9p; Fri, 23 Dec 2011 11:31:26 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Wang2@amd.com>) id 1Re3LR-00018F-EL
	for xen-devel@lists.xensource.com; Fri, 23 Dec 2011 11:31:25 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1324639754!49448683!1
X-Originating-IP: [213.199.154.140]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14581 invoked from network); 23 Dec 2011 11:29:14 -0000
Received: from db3ehsobe002.messaging.microsoft.com (HELO
	DB3EHSOBE002.bigfish.com) (213.199.154.140)
	by server-14.tower-27.messagelabs.com with AES128-SHA encrypted SMTP;
	23 Dec 2011 11:29:14 -0000
Received: from mail115-db3-R.bigfish.com (10.3.81.240) by
	DB3EHSOBE002.bigfish.com (10.3.84.22) with Microsoft SMTP Server id
	14.1.225.23; Fri, 23 Dec 2011 11:31:08 +0000
Received: from mail115-db3 (localhost [127.0.0.1])	by
	mail115-db3-R.bigfish.com (Postfix) with ESMTP id D81A23A041E;
	Fri, 23 Dec 2011 11:31:46 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzzz1202hzz8275bhz2dh668h839h944h)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
X-FB-SS: 13,
Received: from mail115-db3 (localhost.localdomain [127.0.0.1]) by mail115-db3
	(MessageSwitch) id 1324639906387966_13625;
	Fri, 23 Dec 2011 11:31:46 +0000 (UTC)
Received: from DB3EHSMHS008.bigfish.com (unknown [10.3.81.241])	by
	mail115-db3.bigfish.com (Postfix) with ESMTP id 53F33520243;
	Fri, 23 Dec 2011 11:31:46 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	DB3EHSMHS008.bigfish.com (10.3.87.108) with Microsoft SMTP Server id
	14.1.225.23; Fri, 23 Dec 2011 11:31:06 +0000
X-WSS-ID: 0LWNMO3-02-0XA-02
X-M-MSG: 
Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com
	[163.181.249.73])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp02.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2A361C80D1;	Fri, 23 Dec 2011 05:31:15 -0600 (CST)
Received: from SAUSEXDAG02.amd.com (163.181.55.2) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Fri, 23 Dec 2011 05:31:33 -0600
Received: from storexhtp01.amd.com (172.24.4.3) by sausexdag02.amd.com
	(163.181.55.2) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Fri, 23 Dec 2011 05:31:15 -0600
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp01.amd.com
	(172.24.4.3) with Microsoft SMTP Server id 8.3.213.0; Fri, 23 Dec 2011
	06:30:42 -0500
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 510C749C65C; Fri, 23 Dec 2011
	11:30:41 +0000 (GMT)
Received: from gran.amd.com (gran.osrc.amd.com [165.204.15.57])	by
	mail.osrc.amd.com (Postfix) with ESMTP id 3D1D9594882; Fri, 23 Dec 2011
	12:30:41 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 4c986253976d7efd19640500aa3bb69a5a534637
Message-ID: <4c986253976d7efd1964.1324639750@gran.amd.com>
In-Reply-To: <patchbomb.1324639749@gran.amd.com>
References: <patchbomb.1324639749@gran.amd.com>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Fri, 23 Dec 2011 12:29:10 +0100
From: Wei Wang <wei.wang2@amd.com>
To: <JBeulich@suse.com>, <Ian.Jackson@eu.citrix.com>,
	<Ian.Campbell@citrix.com>, <keir@xen.org>
X-OriginatorOrg: amd.com
Cc: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 01 of 16] amd iommu: Refactoring iommu ring
	buffer definition
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Wei Wang <wei.wang2@amd.com>
# Date 1324569370 -3600
# Node ID 4c986253976d7efd19640500aa3bb69a5a534637
# Parent  492914c658383e071bef2f907cb62ede69ba48a4
amd iommu: Refactoring iommu ring buffer definition.
Introduce struct ring_buffer to represent iommu cmd buffer, event log and ppr log

Signed-off-by: Wei Wang <wei.wang2@amd.com>

diff -r 492914c65838 -r 4c986253976d xen/drivers/passthrough/amd/iommu_cmd.c
--- a/xen/drivers/passthrough/amd/iommu_cmd.c	Wed Dec 21 10:47:30 2011 +0000
+++ b/xen/drivers/passthrough/amd/iommu_cmd.c	Thu Dec 22 16:56:10 2011 +0100
@@ -29,7 +29,7 @@ static int queue_iommu_command(struct am
     u32 tail, head, *cmd_buffer;
     int i;
 
-    tail = iommu->cmd_buffer_tail;
+    tail = iommu->cmd_buffer.tail;
     if ( ++tail == iommu->cmd_buffer.entries )
         tail = 0;
 
@@ -40,13 +40,13 @@ static int queue_iommu_command(struct am
     if ( head != tail )
     {
         cmd_buffer = (u32 *)(iommu->cmd_buffer.buffer +
-                             (iommu->cmd_buffer_tail *
+                             (iommu->cmd_buffer.tail *
                              IOMMU_CMD_BUFFER_ENTRY_SIZE));
 
         for ( i = 0; i < IOMMU_CMD_BUFFER_U32_PER_ENTRY; i++ )
             cmd_buffer[i] = cmd[i];
 
-        iommu->cmd_buffer_tail = tail;
+        iommu->cmd_buffer.tail = tail;
         return 1;
     }
 
@@ -57,7 +57,7 @@ static void commit_iommu_command_buffer(
 {
     u32 tail;
 
-    set_field_in_reg_u32(iommu->cmd_buffer_tail, 0,
+    set_field_in_reg_u32(iommu->cmd_buffer.tail, 0,
                          IOMMU_CMD_BUFFER_TAIL_MASK,
                          IOMMU_CMD_BUFFER_TAIL_SHIFT, &tail);
     writel(tail, iommu->mmio_base+IOMMU_CMD_BUFFER_TAIL_OFFSET);
diff -r 492914c65838 -r 4c986253976d xen/drivers/passthrough/amd/iommu_init.c
--- a/xen/drivers/passthrough/amd/iommu_init.c	Wed Dec 21 10:47:30 2011 +0000
+++ b/xen/drivers/passthrough/amd/iommu_init.c	Thu Dec 22 16:56:10 2011 +0100
@@ -294,20 +294,20 @@ static int amd_iommu_read_event_log(stru
                                   IOMMU_EVENT_LOG_TAIL_MASK,
                                   IOMMU_EVENT_LOG_TAIL_SHIFT);
 
-    while ( tail != iommu->event_log_head )
+    while ( tail != iommu->event_log.head )
     {
         /* read event log entry */
         event_log = (u32 *)(iommu->event_log.buffer +
-                           (iommu->event_log_head *
+                           (iommu->event_log.head *
                            IOMMU_EVENT_LOG_ENTRY_SIZE));
 
         parse_event_log_entry(iommu, event_log);
 
-        if ( ++iommu->event_log_head == iommu->event_log.entries )
-            iommu->event_log_head = 0;
+        if ( ++iommu->event_log.head == iommu->event_log.entries )
+            iommu->event_log.head = 0;
 
         /* update head pointer */
-        set_field_in_reg_u32(iommu->event_log_head, 0,
+        set_field_in_reg_u32(iommu->event_log.head, 0,
                              IOMMU_EVENT_LOG_HEAD_MASK,
                              IOMMU_EVENT_LOG_HEAD_SHIFT, &head);
         writel(head, iommu->mmio_base + IOMMU_EVENT_LOG_HEAD_OFFSET);
@@ -346,7 +346,7 @@ static void amd_iommu_reset_event_log(st
     writel(entry, iommu->mmio_base+IOMMU_STATUS_MMIO_OFFSET);
 
     /*reset event log base address */
-    iommu->event_log_head = 0;
+    iommu->event_log.head = 0;
 
     set_iommu_event_log_control(iommu, IOMMU_CONTROL_ENABLED);
 }
@@ -605,71 +605,83 @@ static void enable_iommu(struct amd_iomm
 
 }
 
-static void __init deallocate_iommu_table_struct(
-    struct table_struct *table)
+static void __init deallocate_buffer(void *buf, uint32_t sz)
 {
     int order = 0;
-    if ( table->buffer )
+    if ( buf )
     {
-        order = get_order_from_bytes(table->alloc_size);
-        __free_amd_iommu_tables(table->buffer, order);
-        table->buffer = NULL;
+        order = get_order_from_bytes(sz);
+        __free_amd_iommu_tables(buf, order);
     }
 }
 
-static int __init allocate_iommu_table_struct(struct table_struct *table,
-                                              const char *name)
+static void __init deallocate_device_table(struct table_struct *table)
 {
-    int order = 0;
-    if ( table->buffer == NULL )
-    {
-        order = get_order_from_bytes(table->alloc_size);
-        table->buffer = __alloc_amd_iommu_tables(order);
-
-        if ( table->buffer == NULL )
-        {
-            AMD_IOMMU_DEBUG("Error allocating %s\n", name);
-            return -ENOMEM;
-        }
-        memset(table->buffer, 0, PAGE_SIZE * (1UL << order));
-    }
-    return 0;
+    deallocate_buffer(table->buffer, table->alloc_size);
+    table->buffer = NULL;
 }
 
-static int __init allocate_cmd_buffer(struct amd_iommu *iommu)
+static void __init deallocate_ring_buffer(struct ring_buffer *ring_buf)
+{
+    deallocate_buffer(ring_buf->buffer, ring_buf->alloc_size);
+    ring_buf->buffer = NULL;
+    ring_buf->head = 0;
+    ring_buf->tail = 0;
+}
+
+static void * __init allocate_buffer(uint32_t alloc_size, const char *name)
+{
+    void * buffer;
+    int order = get_order_from_bytes(alloc_size);
+
+    buffer = __alloc_amd_iommu_tables(order);
+
+    if ( buffer == NULL )
+    {
+        AMD_IOMMU_DEBUG("Error allocating %s\n", name);
+        return NULL;
+    }
+
+    memset(buffer, 0, PAGE_SIZE * (1UL << order));
+    return buffer;
+}
+
+static void * __init allocate_ring_buffer(struct ring_buffer *ring_buf,
+                                          uint32_t entry_size, 
+                                          uint64_t entries, const char *name)
+{
+    ring_buf->head = 0;
+    ring_buf->tail = 0;
+
+    ring_buf->entry_size = entry_size;
+    ring_buf->alloc_size = PAGE_SIZE << get_order_from_bytes(entries * 
+                                                             entry_size);
+    ring_buf->entries = ring_buf->alloc_size / entry_size;
+    ring_buf->buffer = allocate_buffer(ring_buf->alloc_size, name);
+    return ring_buf->buffer;
+}
+
+static void * __init allocate_cmd_buffer(struct amd_iommu *iommu)
 {
     /* allocate 'command buffer' in power of 2 increments of 4K */
-    iommu->cmd_buffer_tail = 0;
-    iommu->cmd_buffer.alloc_size = PAGE_SIZE <<
-                                   get_order_from_bytes(
-                                   PAGE_ALIGN(IOMMU_CMD_BUFFER_DEFAULT_ENTRIES
-                                              * IOMMU_CMD_BUFFER_ENTRY_SIZE));
-    iommu->cmd_buffer.entries = iommu->cmd_buffer.alloc_size /
-                                IOMMU_CMD_BUFFER_ENTRY_SIZE;
-
-    return (allocate_iommu_table_struct(&iommu->cmd_buffer, "Command Buffer"));
+    return allocate_ring_buffer(&iommu->cmd_buffer, sizeof(cmd_entry_t),
+                                IOMMU_CMD_BUFFER_DEFAULT_ENTRIES, 
+                                "Command Buffer");
 }
 
-static int __init allocate_event_log(struct amd_iommu *iommu)
+static void * __init allocate_event_log(struct amd_iommu *iommu)
 {
-   /* allocate 'event log' in power of 2 increments of 4K */
-    iommu->event_log_head = 0;
-    iommu->event_log.alloc_size = PAGE_SIZE <<
-                                  get_order_from_bytes(
-                                  PAGE_ALIGN(IOMMU_EVENT_LOG_DEFAULT_ENTRIES *
-                                  IOMMU_EVENT_LOG_ENTRY_SIZE));
-    iommu->event_log.entries = iommu->event_log.alloc_size /
-                               IOMMU_EVENT_LOG_ENTRY_SIZE;
-
-    return (allocate_iommu_table_struct(&iommu->event_log, "Event Log"));
+    /* allocate 'event log' in power of 2 increments of 4K */
+    return allocate_ring_buffer(&iommu->event_log, sizeof(event_entry_t),
+                                IOMMU_EVENT_LOG_DEFAULT_ENTRIES, "Event Log");
 }
 
 static int __init amd_iommu_init_one(struct amd_iommu *iommu)
 {
-    if ( allocate_cmd_buffer(iommu) != 0 )
+    if ( allocate_cmd_buffer(iommu) == NULL )
         goto error_out;
 
-    if ( allocate_event_log(iommu) != 0 )
+    if ( allocate_event_log(iommu) == NULL )
         goto error_out;
 
     if ( map_iommu_mmio_region(iommu) != 0 )
@@ -708,8 +720,8 @@ static void __init amd_iommu_init_cleanu
         list_del(&iommu->list);
         if ( iommu->enabled )
         {
-            deallocate_iommu_table_struct(&iommu->cmd_buffer);
-            deallocate_iommu_table_struct(&iommu->event_log);
+            deallocate_ring_buffer(&iommu->cmd_buffer);
+            deallocate_ring_buffer(&iommu->event_log);
             unmap_iommu_mmio_region(iommu);
         }
         xfree(iommu);
@@ -719,7 +731,7 @@ static void __init amd_iommu_init_cleanu
     iterate_ivrs_entries(amd_iommu_free_intremap_table);
 
     /* free device table */
-    deallocate_iommu_table_struct(&device_table);
+    deallocate_device_table(&device_table);
 
     /* free ivrs_mappings[] */
     radix_tree_destroy(&ivrs_maps, xfree);
@@ -830,8 +842,10 @@ static int __init amd_iommu_setup_device
     device_table.entries = device_table.alloc_size /
                            IOMMU_DEV_TABLE_ENTRY_SIZE;
 
-    if ( allocate_iommu_table_struct(&device_table, "Device Table") != 0 )
-         return -ENOMEM;
+    device_table.buffer = allocate_buffer(device_table.alloc_size, 
+                                          "Device Table");
+    if  ( device_table.buffer == NULL )
+        return -ENOMEM;
 
     /* Add device table entries */
     for ( bdf = 0; bdf < ivrs_bdf_entries; bdf++ )
diff -r 492914c65838 -r 4c986253976d xen/include/asm-x86/amd-iommu.h
--- a/xen/include/asm-x86/amd-iommu.h	Wed Dec 21 10:47:30 2011 +0000
+++ b/xen/include/asm-x86/amd-iommu.h	Thu Dec 22 16:56:10 2011 +0100
@@ -30,12 +30,43 @@
 
 extern struct list_head amd_iommu_head;
 
+#pragma pack(1)
+typedef struct event_entry
+{
+    uint32_t data[4];
+} event_entry_t;
+
+typedef struct ppr_entry
+{
+    uint32_t data[4];
+} ppr_entry_t;
+
+typedef struct cmd_entry
+{
+    uint32_t data[4];
+} cmd_entry_t;
+
+typedef struct dev_entry
+{
+    uint32_t data[8];
+} dev_entry_t;
+#pragma pack()
+
 struct table_struct {
     void *buffer;
     unsigned long entries;
     unsigned long alloc_size;
 };
 
+struct ring_buffer {
+    void *buffer;
+    unsigned long entries;
+    unsigned long alloc_size;
+    unsigned long entry_size;
+    uint32_t tail;
+    uint32_t head;
+};
+
 typedef struct iommu_cap {
     uint32_t header;                    /* offset 00h */
     uint32_t base_low;                  /* offset 04h */
@@ -60,10 +91,8 @@ struct amd_iommu {
     unsigned long mmio_base_phys;
 
     struct table_struct dev_table;
-    struct table_struct cmd_buffer;
-    u32 cmd_buffer_tail;
-    struct table_struct event_log;
-    u32 event_log_head;
+    struct ring_buffer cmd_buffer;
+    struct ring_buffer event_log;
 
     int exclusion_enable;
     int exclusion_allow_all;


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 23 11:31:47 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 Dec 2011 11: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.xensource.com>)
	id 1Re3LS-00018x-9p; Fri, 23 Dec 2011 11:31:26 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Wang2@amd.com>) id 1Re3LR-00018F-EL
	for xen-devel@lists.xensource.com; Fri, 23 Dec 2011 11:31:25 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1324639754!49448683!1
X-Originating-IP: [213.199.154.140]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14581 invoked from network); 23 Dec 2011 11:29:14 -0000
Received: from db3ehsobe002.messaging.microsoft.com (HELO
	DB3EHSOBE002.bigfish.com) (213.199.154.140)
	by server-14.tower-27.messagelabs.com with AES128-SHA encrypted SMTP;
	23 Dec 2011 11:29:14 -0000
Received: from mail115-db3-R.bigfish.com (10.3.81.240) by
	DB3EHSOBE002.bigfish.com (10.3.84.22) with Microsoft SMTP Server id
	14.1.225.23; Fri, 23 Dec 2011 11:31:08 +0000
Received: from mail115-db3 (localhost [127.0.0.1])	by
	mail115-db3-R.bigfish.com (Postfix) with ESMTP id D81A23A041E;
	Fri, 23 Dec 2011 11:31:46 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzzz1202hzz8275bhz2dh668h839h944h)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
X-FB-SS: 13,
Received: from mail115-db3 (localhost.localdomain [127.0.0.1]) by mail115-db3
	(MessageSwitch) id 1324639906387966_13625;
	Fri, 23 Dec 2011 11:31:46 +0000 (UTC)
Received: from DB3EHSMHS008.bigfish.com (unknown [10.3.81.241])	by
	mail115-db3.bigfish.com (Postfix) with ESMTP id 53F33520243;
	Fri, 23 Dec 2011 11:31:46 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	DB3EHSMHS008.bigfish.com (10.3.87.108) with Microsoft SMTP Server id
	14.1.225.23; Fri, 23 Dec 2011 11:31:06 +0000
X-WSS-ID: 0LWNMO3-02-0XA-02
X-M-MSG: 
Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com
	[163.181.249.73])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp02.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2A361C80D1;	Fri, 23 Dec 2011 05:31:15 -0600 (CST)
Received: from SAUSEXDAG02.amd.com (163.181.55.2) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Fri, 23 Dec 2011 05:31:33 -0600
Received: from storexhtp01.amd.com (172.24.4.3) by sausexdag02.amd.com
	(163.181.55.2) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Fri, 23 Dec 2011 05:31:15 -0600
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp01.amd.com
	(172.24.4.3) with Microsoft SMTP Server id 8.3.213.0; Fri, 23 Dec 2011
	06:30:42 -0500
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 510C749C65C; Fri, 23 Dec 2011
	11:30:41 +0000 (GMT)
Received: from gran.amd.com (gran.osrc.amd.com [165.204.15.57])	by
	mail.osrc.amd.com (Postfix) with ESMTP id 3D1D9594882; Fri, 23 Dec 2011
	12:30:41 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 4c986253976d7efd19640500aa3bb69a5a534637
Message-ID: <4c986253976d7efd1964.1324639750@gran.amd.com>
In-Reply-To: <patchbomb.1324639749@gran.amd.com>
References: <patchbomb.1324639749@gran.amd.com>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Fri, 23 Dec 2011 12:29:10 +0100
From: Wei Wang <wei.wang2@amd.com>
To: <JBeulich@suse.com>, <Ian.Jackson@eu.citrix.com>,
	<Ian.Campbell@citrix.com>, <keir@xen.org>
X-OriginatorOrg: amd.com
Cc: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 01 of 16] amd iommu: Refactoring iommu ring
	buffer definition
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Wei Wang <wei.wang2@amd.com>
# Date 1324569370 -3600
# Node ID 4c986253976d7efd19640500aa3bb69a5a534637
# Parent  492914c658383e071bef2f907cb62ede69ba48a4
amd iommu: Refactoring iommu ring buffer definition.
Introduce struct ring_buffer to represent iommu cmd buffer, event log and ppr log

Signed-off-by: Wei Wang <wei.wang2@amd.com>

diff -r 492914c65838 -r 4c986253976d xen/drivers/passthrough/amd/iommu_cmd.c
--- a/xen/drivers/passthrough/amd/iommu_cmd.c	Wed Dec 21 10:47:30 2011 +0000
+++ b/xen/drivers/passthrough/amd/iommu_cmd.c	Thu Dec 22 16:56:10 2011 +0100
@@ -29,7 +29,7 @@ static int queue_iommu_command(struct am
     u32 tail, head, *cmd_buffer;
     int i;
 
-    tail = iommu->cmd_buffer_tail;
+    tail = iommu->cmd_buffer.tail;
     if ( ++tail == iommu->cmd_buffer.entries )
         tail = 0;
 
@@ -40,13 +40,13 @@ static int queue_iommu_command(struct am
     if ( head != tail )
     {
         cmd_buffer = (u32 *)(iommu->cmd_buffer.buffer +
-                             (iommu->cmd_buffer_tail *
+                             (iommu->cmd_buffer.tail *
                              IOMMU_CMD_BUFFER_ENTRY_SIZE));
 
         for ( i = 0; i < IOMMU_CMD_BUFFER_U32_PER_ENTRY; i++ )
             cmd_buffer[i] = cmd[i];
 
-        iommu->cmd_buffer_tail = tail;
+        iommu->cmd_buffer.tail = tail;
         return 1;
     }
 
@@ -57,7 +57,7 @@ static void commit_iommu_command_buffer(
 {
     u32 tail;
 
-    set_field_in_reg_u32(iommu->cmd_buffer_tail, 0,
+    set_field_in_reg_u32(iommu->cmd_buffer.tail, 0,
                          IOMMU_CMD_BUFFER_TAIL_MASK,
                          IOMMU_CMD_BUFFER_TAIL_SHIFT, &tail);
     writel(tail, iommu->mmio_base+IOMMU_CMD_BUFFER_TAIL_OFFSET);
diff -r 492914c65838 -r 4c986253976d xen/drivers/passthrough/amd/iommu_init.c
--- a/xen/drivers/passthrough/amd/iommu_init.c	Wed Dec 21 10:47:30 2011 +0000
+++ b/xen/drivers/passthrough/amd/iommu_init.c	Thu Dec 22 16:56:10 2011 +0100
@@ -294,20 +294,20 @@ static int amd_iommu_read_event_log(stru
                                   IOMMU_EVENT_LOG_TAIL_MASK,
                                   IOMMU_EVENT_LOG_TAIL_SHIFT);
 
-    while ( tail != iommu->event_log_head )
+    while ( tail != iommu->event_log.head )
     {
         /* read event log entry */
         event_log = (u32 *)(iommu->event_log.buffer +
-                           (iommu->event_log_head *
+                           (iommu->event_log.head *
                            IOMMU_EVENT_LOG_ENTRY_SIZE));
 
         parse_event_log_entry(iommu, event_log);
 
-        if ( ++iommu->event_log_head == iommu->event_log.entries )
-            iommu->event_log_head = 0;
+        if ( ++iommu->event_log.head == iommu->event_log.entries )
+            iommu->event_log.head = 0;
 
         /* update head pointer */
-        set_field_in_reg_u32(iommu->event_log_head, 0,
+        set_field_in_reg_u32(iommu->event_log.head, 0,
                              IOMMU_EVENT_LOG_HEAD_MASK,
                              IOMMU_EVENT_LOG_HEAD_SHIFT, &head);
         writel(head, iommu->mmio_base + IOMMU_EVENT_LOG_HEAD_OFFSET);
@@ -346,7 +346,7 @@ static void amd_iommu_reset_event_log(st
     writel(entry, iommu->mmio_base+IOMMU_STATUS_MMIO_OFFSET);
 
     /*reset event log base address */
-    iommu->event_log_head = 0;
+    iommu->event_log.head = 0;
 
     set_iommu_event_log_control(iommu, IOMMU_CONTROL_ENABLED);
 }
@@ -605,71 +605,83 @@ static void enable_iommu(struct amd_iomm
 
 }
 
-static void __init deallocate_iommu_table_struct(
-    struct table_struct *table)
+static void __init deallocate_buffer(void *buf, uint32_t sz)
 {
     int order = 0;
-    if ( table->buffer )
+    if ( buf )
     {
-        order = get_order_from_bytes(table->alloc_size);
-        __free_amd_iommu_tables(table->buffer, order);
-        table->buffer = NULL;
+        order = get_order_from_bytes(sz);
+        __free_amd_iommu_tables(buf, order);
     }
 }
 
-static int __init allocate_iommu_table_struct(struct table_struct *table,
-                                              const char *name)
+static void __init deallocate_device_table(struct table_struct *table)
 {
-    int order = 0;
-    if ( table->buffer == NULL )
-    {
-        order = get_order_from_bytes(table->alloc_size);
-        table->buffer = __alloc_amd_iommu_tables(order);
-
-        if ( table->buffer == NULL )
-        {
-            AMD_IOMMU_DEBUG("Error allocating %s\n", name);
-            return -ENOMEM;
-        }
-        memset(table->buffer, 0, PAGE_SIZE * (1UL << order));
-    }
-    return 0;
+    deallocate_buffer(table->buffer, table->alloc_size);
+    table->buffer = NULL;
 }
 
-static int __init allocate_cmd_buffer(struct amd_iommu *iommu)
+static void __init deallocate_ring_buffer(struct ring_buffer *ring_buf)
+{
+    deallocate_buffer(ring_buf->buffer, ring_buf->alloc_size);
+    ring_buf->buffer = NULL;
+    ring_buf->head = 0;
+    ring_buf->tail = 0;
+}
+
+static void * __init allocate_buffer(uint32_t alloc_size, const char *name)
+{
+    void * buffer;
+    int order = get_order_from_bytes(alloc_size);
+
+    buffer = __alloc_amd_iommu_tables(order);
+
+    if ( buffer == NULL )
+    {
+        AMD_IOMMU_DEBUG("Error allocating %s\n", name);
+        return NULL;
+    }
+
+    memset(buffer, 0, PAGE_SIZE * (1UL << order));
+    return buffer;
+}
+
+static void * __init allocate_ring_buffer(struct ring_buffer *ring_buf,
+                                          uint32_t entry_size, 
+                                          uint64_t entries, const char *name)
+{
+    ring_buf->head = 0;
+    ring_buf->tail = 0;
+
+    ring_buf->entry_size = entry_size;
+    ring_buf->alloc_size = PAGE_SIZE << get_order_from_bytes(entries * 
+                                                             entry_size);
+    ring_buf->entries = ring_buf->alloc_size / entry_size;
+    ring_buf->buffer = allocate_buffer(ring_buf->alloc_size, name);
+    return ring_buf->buffer;
+}
+
+static void * __init allocate_cmd_buffer(struct amd_iommu *iommu)
 {
     /* allocate 'command buffer' in power of 2 increments of 4K */
-    iommu->cmd_buffer_tail = 0;
-    iommu->cmd_buffer.alloc_size = PAGE_SIZE <<
-                                   get_order_from_bytes(
-                                   PAGE_ALIGN(IOMMU_CMD_BUFFER_DEFAULT_ENTRIES
-                                              * IOMMU_CMD_BUFFER_ENTRY_SIZE));
-    iommu->cmd_buffer.entries = iommu->cmd_buffer.alloc_size /
-                                IOMMU_CMD_BUFFER_ENTRY_SIZE;
-
-    return (allocate_iommu_table_struct(&iommu->cmd_buffer, "Command Buffer"));
+    return allocate_ring_buffer(&iommu->cmd_buffer, sizeof(cmd_entry_t),
+                                IOMMU_CMD_BUFFER_DEFAULT_ENTRIES, 
+                                "Command Buffer");
 }
 
-static int __init allocate_event_log(struct amd_iommu *iommu)
+static void * __init allocate_event_log(struct amd_iommu *iommu)
 {
-   /* allocate 'event log' in power of 2 increments of 4K */
-    iommu->event_log_head = 0;
-    iommu->event_log.alloc_size = PAGE_SIZE <<
-                                  get_order_from_bytes(
-                                  PAGE_ALIGN(IOMMU_EVENT_LOG_DEFAULT_ENTRIES *
-                                  IOMMU_EVENT_LOG_ENTRY_SIZE));
-    iommu->event_log.entries = iommu->event_log.alloc_size /
-                               IOMMU_EVENT_LOG_ENTRY_SIZE;
-
-    return (allocate_iommu_table_struct(&iommu->event_log, "Event Log"));
+    /* allocate 'event log' in power of 2 increments of 4K */
+    return allocate_ring_buffer(&iommu->event_log, sizeof(event_entry_t),
+                                IOMMU_EVENT_LOG_DEFAULT_ENTRIES, "Event Log");
 }
 
 static int __init amd_iommu_init_one(struct amd_iommu *iommu)
 {
-    if ( allocate_cmd_buffer(iommu) != 0 )
+    if ( allocate_cmd_buffer(iommu) == NULL )
         goto error_out;
 
-    if ( allocate_event_log(iommu) != 0 )
+    if ( allocate_event_log(iommu) == NULL )
         goto error_out;
 
     if ( map_iommu_mmio_region(iommu) != 0 )
@@ -708,8 +720,8 @@ static void __init amd_iommu_init_cleanu
         list_del(&iommu->list);
         if ( iommu->enabled )
         {
-            deallocate_iommu_table_struct(&iommu->cmd_buffer);
-            deallocate_iommu_table_struct(&iommu->event_log);
+            deallocate_ring_buffer(&iommu->cmd_buffer);
+            deallocate_ring_buffer(&iommu->event_log);
             unmap_iommu_mmio_region(iommu);
         }
         xfree(iommu);
@@ -719,7 +731,7 @@ static void __init amd_iommu_init_cleanu
     iterate_ivrs_entries(amd_iommu_free_intremap_table);
 
     /* free device table */
-    deallocate_iommu_table_struct(&device_table);
+    deallocate_device_table(&device_table);
 
     /* free ivrs_mappings[] */
     radix_tree_destroy(&ivrs_maps, xfree);
@@ -830,8 +842,10 @@ static int __init amd_iommu_setup_device
     device_table.entries = device_table.alloc_size /
                            IOMMU_DEV_TABLE_ENTRY_SIZE;
 
-    if ( allocate_iommu_table_struct(&device_table, "Device Table") != 0 )
-         return -ENOMEM;
+    device_table.buffer = allocate_buffer(device_table.alloc_size, 
+                                          "Device Table");
+    if  ( device_table.buffer == NULL )
+        return -ENOMEM;
 
     /* Add device table entries */
     for ( bdf = 0; bdf < ivrs_bdf_entries; bdf++ )
diff -r 492914c65838 -r 4c986253976d xen/include/asm-x86/amd-iommu.h
--- a/xen/include/asm-x86/amd-iommu.h	Wed Dec 21 10:47:30 2011 +0000
+++ b/xen/include/asm-x86/amd-iommu.h	Thu Dec 22 16:56:10 2011 +0100
@@ -30,12 +30,43 @@
 
 extern struct list_head amd_iommu_head;
 
+#pragma pack(1)
+typedef struct event_entry
+{
+    uint32_t data[4];
+} event_entry_t;
+
+typedef struct ppr_entry
+{
+    uint32_t data[4];
+} ppr_entry_t;
+
+typedef struct cmd_entry
+{
+    uint32_t data[4];
+} cmd_entry_t;
+
+typedef struct dev_entry
+{
+    uint32_t data[8];
+} dev_entry_t;
+#pragma pack()
+
 struct table_struct {
     void *buffer;
     unsigned long entries;
     unsigned long alloc_size;
 };
 
+struct ring_buffer {
+    void *buffer;
+    unsigned long entries;
+    unsigned long alloc_size;
+    unsigned long entry_size;
+    uint32_t tail;
+    uint32_t head;
+};
+
 typedef struct iommu_cap {
     uint32_t header;                    /* offset 00h */
     uint32_t base_low;                  /* offset 04h */
@@ -60,10 +91,8 @@ struct amd_iommu {
     unsigned long mmio_base_phys;
 
     struct table_struct dev_table;
-    struct table_struct cmd_buffer;
-    u32 cmd_buffer_tail;
-    struct table_struct event_log;
-    u32 event_log_head;
+    struct ring_buffer cmd_buffer;
+    struct ring_buffer event_log;
 
     int exclusion_enable;
     int exclusion_allow_all;


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 23 11:31:48 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 Dec 2011 11:31:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Re3LQ-00018b-El; Fri, 23 Dec 2011 11:31:24 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Wang2@amd.com>) id 1Re3LP-00018C-8k
	for xen-devel@lists.xensource.com; Fri, 23 Dec 2011 11:31:23 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1324639876!6498371!1
X-Originating-IP: [213.199.154.141]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26602 invoked from network); 23 Dec 2011 11:31:16 -0000
Received: from db3ehsobe003.messaging.microsoft.com (HELO
	DB3EHSOBE003.bigfish.com) (213.199.154.141)
	by server-16.tower-174.messagelabs.com with AES128-SHA encrypted SMTP;
	23 Dec 2011 11:31:16 -0000
Received: from mail104-db3-R.bigfish.com (10.3.81.245) by
	DB3EHSOBE003.bigfish.com (10.3.84.23) with Microsoft SMTP Server id
	14.1.225.23; Fri, 23 Dec 2011 11:31:04 +0000
Received: from mail104-db3 (localhost [127.0.0.1])	by
	mail104-db3-R.bigfish.com (Postfix) with ESMTP id A2170320614;
	Fri, 23 Dec 2011 11:31:43 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzzz1202hzz8275bhz2dh668h839h944h)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
Received: from mail104-db3 (localhost.localdomain [127.0.0.1]) by mail104-db3
	(MessageSwitch) id 132463990333658_26032;
	Fri, 23 Dec 2011 11:31:43 +0000 (UTC)
Received: from DB3EHSMHS011.bigfish.com (unknown [10.3.81.244])	by
	mail104-db3.bigfish.com (Postfix) with ESMTP id ECC8C6E0046;
	Fri, 23 Dec 2011 11:31:42 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	DB3EHSMHS011.bigfish.com (10.3.87.111) with Microsoft SMTP Server id
	14.1.225.23; Fri, 23 Dec 2011 11:31:02 +0000
X-WSS-ID: 0LWNMO0-02-0WW-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp02.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 20482C80D9;	Fri, 23 Dec 2011 05:31:12 -0600 (CST)
Received: from SAUSEXDAG02.amd.com (163.181.55.2) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Fri, 23 Dec 2011 05:31:31 -0600
Received: from storexhtp02.amd.com (172.24.4.4) by sausexdag02.amd.com
	(163.181.55.2) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Fri, 23 Dec 2011 05:31:12 -0600
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Fri, 23 Dec 2011
	06:30:42 -0500
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id A99DE49C65F; Fri, 23 Dec 2011
	11:30:41 +0000 (GMT)
Received: from gran.amd.com (gran.osrc.amd.com [165.204.15.57])	by
	mail.osrc.amd.com (Postfix) with ESMTP id 81D0D594885; Fri, 23 Dec 2011
	12:30:41 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 33f88c76776c318eea74b8fc1ba467389407ad57
Message-ID: <33f88c76776c318eea74.1324639753@gran.amd.com>
In-Reply-To: <patchbomb.1324639749@gran.amd.com>
References: <patchbomb.1324639749@gran.amd.com>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Fri, 23 Dec 2011 12:29:13 +0100
From: Wei Wang <wei.wang2@amd.com>
To: <JBeulich@suse.com>, <Ian.Jackson@eu.citrix.com>,
	<Ian.Campbell@citrix.com>, <keir@xen.org>
X-OriginatorOrg: amd.com
Cc: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 04 of 16] amd iommu: Enable ppr log
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Wei Wang <wei.wang2@amd.com>
# Date 1324569381 -3600
# Node ID 33f88c76776c318eea74b8fc1ba467389407ad57
# Parent  07f338ae663242ba9080f1ab84298894783da3e2
amd iommu: Enable ppr log.
IOMMUv2 writes peripheral page service request (PPR) records into ppr log
to report DMA page request from ATS devices to OS.

Signed-off-by: Wei Wang <wei.wang2@amd.com>

diff -r 07f338ae6632 -r 33f88c76776c xen/drivers/passthrough/amd/iommu_init.c
--- a/xen/drivers/passthrough/amd/iommu_init.c	Thu Dec 22 16:56:17 2011 +0100
+++ b/xen/drivers/passthrough/amd/iommu_init.c	Thu Dec 22 16:56:21 2011 +0100
@@ -178,6 +178,34 @@ static void register_iommu_event_log_in_
     writel(entry, iommu->mmio_base+IOMMU_EVENT_LOG_BASE_HIGH_OFFSET);
 }
 
+static void register_iommu_ppr_log_in_mmio_space(struct amd_iommu *iommu)
+{
+    u64 addr_64, addr_lo, addr_hi;
+    u32 power_of2_entries;
+    u32 entry;
+
+    ASSERT ( iommu->ppr_log.buffer );
+
+    addr_64 = (u64)virt_to_maddr(iommu->ppr_log.buffer);
+    addr_lo = addr_64 & DMA_32BIT_MASK;
+    addr_hi = addr_64 >> 32;
+
+    entry = 0;
+    iommu_set_addr_lo_to_reg(&entry, addr_lo >> PAGE_SHIFT);
+    writel(entry, iommu->mmio_base + IOMMU_PPR_LOG_BASE_LOW_OFFSET);
+
+    power_of2_entries = get_order_from_bytes(iommu->ppr_log.alloc_size) +
+                        IOMMU_PPR_LOG_POWER_OF2_ENTRIES_PER_PAGE;
+
+    entry = 0;
+    iommu_set_addr_hi_to_reg(&entry, addr_hi);
+    set_field_in_reg_u32(power_of2_entries, entry,
+                        IOMMU_PPR_LOG_LENGTH_MASK,
+                        IOMMU_PPR_LOG_LENGTH_SHIFT, &entry);
+    writel(entry, iommu->mmio_base + IOMMU_PPR_LOG_BASE_HIGH_OFFSET);
+}
+
+
 static void set_iommu_translation_control(struct amd_iommu *iommu,
                                                  int enable)
 {
@@ -278,6 +306,35 @@ static void set_iommu_event_log_control(
     writel(entry, iommu->mmio_base + IOMMU_CONTROL_MMIO_OFFSET);
 }
 
+static void set_iommu_ppr_log_control(struct amd_iommu *iommu,
+                                      int enable)
+{
+    u32 entry;
+
+    entry = readl(iommu->mmio_base + IOMMU_CONTROL_MMIO_OFFSET);
+
+    /*reset head and tail pointer manually before enablement */
+    if ( enable )
+    {
+        writel(0x0, iommu->mmio_base + IOMMU_PPR_LOG_HEAD_OFFSET);
+        writel(0x0, iommu->mmio_base + IOMMU_PPR_LOG_TAIL_OFFSET);
+
+        iommu_set_bit(&entry, IOMMU_CONTROL_PPR_ENABLE_SHIFT);
+        iommu_set_bit(&entry, IOMMU_CONTROL_PPR_INT_SHIFT);
+        iommu_set_bit(&entry, IOMMU_CONTROL_PPR_LOG_ENABLE_SHIFT);
+    }
+    else
+    {
+        iommu_clear_bit(&entry, IOMMU_CONTROL_PPR_ENABLE_SHIFT);
+        iommu_clear_bit(&entry, IOMMU_CONTROL_PPR_INT_SHIFT);
+        iommu_clear_bit(&entry, IOMMU_CONTROL_PPR_LOG_ENABLE_SHIFT);
+    }
+
+    writel(entry, iommu->mmio_base + IOMMU_CONTROL_MMIO_OFFSET);
+    if ( enable )
+        AMD_IOMMU_DEBUG("PPR Log Enabled.\n");
+}
+
 static void parse_event_log_entry(struct amd_iommu *, u32 entry[]);
 
 static int amd_iommu_read_event_log(struct amd_iommu *iommu)
@@ -585,12 +642,19 @@ static void enable_iommu(struct amd_iomm
     register_iommu_event_log_in_mmio_space(iommu);
     register_iommu_exclusion_range(iommu);
 
+    if ( iommu_has_feature(iommu, IOMMU_EXT_FEATURE_PPRSUP_SHIFT) )
+        register_iommu_ppr_log_in_mmio_space(iommu);
+
     iommu_msi_set_affinity(irq_to_desc(iommu->irq), &cpu_online_map);
     amd_iommu_msi_enable(iommu, IOMMU_CONTROL_ENABLED);
 
     set_iommu_ht_flags(iommu);
     set_iommu_command_buffer_control(iommu, IOMMU_CONTROL_ENABLED);
     set_iommu_event_log_control(iommu, IOMMU_CONTROL_ENABLED);
+
+    if ( iommu_has_feature(iommu, IOMMU_EXT_FEATURE_PPRSUP_SHIFT) )
+        set_iommu_ppr_log_control(iommu, IOMMU_CONTROL_ENABLED);
+
     set_iommu_translation_control(iommu, IOMMU_CONTROL_ENABLED);
 
     if ( iommu_has_feature(iommu, IOMMU_EXT_FEATURE_IASUP_SHIFT) )
@@ -672,16 +736,29 @@ static void * __init allocate_event_log(
                                 IOMMU_EVENT_LOG_DEFAULT_ENTRIES, "Event Log");
 }
 
+static void * __init allocate_ppr_log(struct amd_iommu *iommu)
+{
+    /* allocate 'ppr log' in power of 2 increments of 4K */
+    return allocate_ring_buffer(&iommu->ppr_log, sizeof(ppr_entry_t),
+                                IOMMU_PPR_LOG_DEFAULT_ENTRIES, "PPR Log");
+}
+
 static int __init amd_iommu_init_one(struct amd_iommu *iommu)
 {
+    if ( map_iommu_mmio_region(iommu) != 0 )
+        goto error_out;
+
+    get_iommu_features(iommu);
+
     if ( allocate_cmd_buffer(iommu) == NULL )
         goto error_out;
 
     if ( allocate_event_log(iommu) == NULL )
         goto error_out;
 
-    if ( map_iommu_mmio_region(iommu) != 0 )
-        goto error_out;
+    if ( iommu_has_feature(iommu, IOMMU_EXT_FEATURE_PPRSUP_SHIFT) )
+        if ( allocate_ppr_log(iommu) == NULL )
+            goto error_out;
 
     if ( set_iommu_interrupt_handler(iommu) == 0 )
         goto error_out;
@@ -694,8 +771,6 @@ static int __init amd_iommu_init_one(str
     iommu->dev_table.entries = device_table.entries;
     iommu->dev_table.buffer = device_table.buffer;
 
-    get_iommu_features(iommu);
-
     enable_iommu(iommu);
     printk("AMD-Vi: IOMMU %d Enabled.\n", nr_amd_iommus );
     nr_amd_iommus++;
@@ -718,6 +793,7 @@ static void __init amd_iommu_init_cleanu
         {
             deallocate_ring_buffer(&iommu->cmd_buffer);
             deallocate_ring_buffer(&iommu->event_log);
+            deallocate_ring_buffer(&iommu->ppr_log);
             unmap_iommu_mmio_region(iommu);
         }
         xfree(iommu);
@@ -916,6 +992,10 @@ static void disable_iommu(struct amd_iom
     amd_iommu_msi_enable(iommu, IOMMU_CONTROL_DISABLED);
     set_iommu_command_buffer_control(iommu, IOMMU_CONTROL_DISABLED);
     set_iommu_event_log_control(iommu, IOMMU_CONTROL_DISABLED);
+
+    if ( iommu_has_feature(iommu, IOMMU_EXT_FEATURE_PPRSUP_SHIFT) )
+        set_iommu_ppr_log_control(iommu, IOMMU_CONTROL_DISABLED);
+
     set_iommu_translation_control(iommu, IOMMU_CONTROL_DISABLED);
 
     iommu->enabled = 0;
diff -r 07f338ae6632 -r 33f88c76776c xen/include/asm-x86/amd-iommu.h
--- a/xen/include/asm-x86/amd-iommu.h	Thu Dec 22 16:56:17 2011 +0100
+++ b/xen/include/asm-x86/amd-iommu.h	Thu Dec 22 16:56:21 2011 +0100
@@ -94,6 +94,7 @@ struct amd_iommu {
     struct table_struct dev_table;
     struct ring_buffer cmd_buffer;
     struct ring_buffer event_log;
+    struct ring_buffer ppr_log;
 
     int exclusion_enable;
     int exclusion_allow_all;
diff -r 07f338ae6632 -r 33f88c76776c xen/include/asm-x86/hvm/svm/amd-iommu-defs.h
--- a/xen/include/asm-x86/hvm/svm/amd-iommu-defs.h	Thu Dec 22 16:56:17 2011 +0100
+++ b/xen/include/asm-x86/hvm/svm/amd-iommu-defs.h	Thu Dec 22 16:56:21 2011 +0100
@@ -27,6 +27,9 @@
 /* IOMMU Event Log entries: in power of 2 increments, minimum of 256 */
 #define IOMMU_EVENT_LOG_DEFAULT_ENTRIES     512
 
+/* IOMMU PPR Log entries: in power of 2 increments, minimum of 256 */
+#define IOMMU_PPR_LOG_DEFAULT_ENTRIES       512
+
 #define PTE_PER_TABLE_SHIFT		9
 #define PTE_PER_TABLE_SIZE		(1 << PTE_PER_TABLE_SHIFT)
 #define PTE_PER_TABLE_MASK		(~(PTE_PER_TABLE_SIZE - 1))


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 23 11:31:48 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 Dec 2011 11:31:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Re3LQ-00018b-El; Fri, 23 Dec 2011 11:31:24 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Wang2@amd.com>) id 1Re3LP-00018C-8k
	for xen-devel@lists.xensource.com; Fri, 23 Dec 2011 11:31:23 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1324639876!6498371!1
X-Originating-IP: [213.199.154.141]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26602 invoked from network); 23 Dec 2011 11:31:16 -0000
Received: from db3ehsobe003.messaging.microsoft.com (HELO
	DB3EHSOBE003.bigfish.com) (213.199.154.141)
	by server-16.tower-174.messagelabs.com with AES128-SHA encrypted SMTP;
	23 Dec 2011 11:31:16 -0000
Received: from mail104-db3-R.bigfish.com (10.3.81.245) by
	DB3EHSOBE003.bigfish.com (10.3.84.23) with Microsoft SMTP Server id
	14.1.225.23; Fri, 23 Dec 2011 11:31:04 +0000
Received: from mail104-db3 (localhost [127.0.0.1])	by
	mail104-db3-R.bigfish.com (Postfix) with ESMTP id A2170320614;
	Fri, 23 Dec 2011 11:31:43 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzzz1202hzz8275bhz2dh668h839h944h)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
Received: from mail104-db3 (localhost.localdomain [127.0.0.1]) by mail104-db3
	(MessageSwitch) id 132463990333658_26032;
	Fri, 23 Dec 2011 11:31:43 +0000 (UTC)
Received: from DB3EHSMHS011.bigfish.com (unknown [10.3.81.244])	by
	mail104-db3.bigfish.com (Postfix) with ESMTP id ECC8C6E0046;
	Fri, 23 Dec 2011 11:31:42 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	DB3EHSMHS011.bigfish.com (10.3.87.111) with Microsoft SMTP Server id
	14.1.225.23; Fri, 23 Dec 2011 11:31:02 +0000
X-WSS-ID: 0LWNMO0-02-0WW-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp02.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 20482C80D9;	Fri, 23 Dec 2011 05:31:12 -0600 (CST)
Received: from SAUSEXDAG02.amd.com (163.181.55.2) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Fri, 23 Dec 2011 05:31:31 -0600
Received: from storexhtp02.amd.com (172.24.4.4) by sausexdag02.amd.com
	(163.181.55.2) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Fri, 23 Dec 2011 05:31:12 -0600
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Fri, 23 Dec 2011
	06:30:42 -0500
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id A99DE49C65F; Fri, 23 Dec 2011
	11:30:41 +0000 (GMT)
Received: from gran.amd.com (gran.osrc.amd.com [165.204.15.57])	by
	mail.osrc.amd.com (Postfix) with ESMTP id 81D0D594885; Fri, 23 Dec 2011
	12:30:41 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 33f88c76776c318eea74b8fc1ba467389407ad57
Message-ID: <33f88c76776c318eea74.1324639753@gran.amd.com>
In-Reply-To: <patchbomb.1324639749@gran.amd.com>
References: <patchbomb.1324639749@gran.amd.com>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Fri, 23 Dec 2011 12:29:13 +0100
From: Wei Wang <wei.wang2@amd.com>
To: <JBeulich@suse.com>, <Ian.Jackson@eu.citrix.com>,
	<Ian.Campbell@citrix.com>, <keir@xen.org>
X-OriginatorOrg: amd.com
Cc: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 04 of 16] amd iommu: Enable ppr log
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Wei Wang <wei.wang2@amd.com>
# Date 1324569381 -3600
# Node ID 33f88c76776c318eea74b8fc1ba467389407ad57
# Parent  07f338ae663242ba9080f1ab84298894783da3e2
amd iommu: Enable ppr log.
IOMMUv2 writes peripheral page service request (PPR) records into ppr log
to report DMA page request from ATS devices to OS.

Signed-off-by: Wei Wang <wei.wang2@amd.com>

diff -r 07f338ae6632 -r 33f88c76776c xen/drivers/passthrough/amd/iommu_init.c
--- a/xen/drivers/passthrough/amd/iommu_init.c	Thu Dec 22 16:56:17 2011 +0100
+++ b/xen/drivers/passthrough/amd/iommu_init.c	Thu Dec 22 16:56:21 2011 +0100
@@ -178,6 +178,34 @@ static void register_iommu_event_log_in_
     writel(entry, iommu->mmio_base+IOMMU_EVENT_LOG_BASE_HIGH_OFFSET);
 }
 
+static void register_iommu_ppr_log_in_mmio_space(struct amd_iommu *iommu)
+{
+    u64 addr_64, addr_lo, addr_hi;
+    u32 power_of2_entries;
+    u32 entry;
+
+    ASSERT ( iommu->ppr_log.buffer );
+
+    addr_64 = (u64)virt_to_maddr(iommu->ppr_log.buffer);
+    addr_lo = addr_64 & DMA_32BIT_MASK;
+    addr_hi = addr_64 >> 32;
+
+    entry = 0;
+    iommu_set_addr_lo_to_reg(&entry, addr_lo >> PAGE_SHIFT);
+    writel(entry, iommu->mmio_base + IOMMU_PPR_LOG_BASE_LOW_OFFSET);
+
+    power_of2_entries = get_order_from_bytes(iommu->ppr_log.alloc_size) +
+                        IOMMU_PPR_LOG_POWER_OF2_ENTRIES_PER_PAGE;
+
+    entry = 0;
+    iommu_set_addr_hi_to_reg(&entry, addr_hi);
+    set_field_in_reg_u32(power_of2_entries, entry,
+                        IOMMU_PPR_LOG_LENGTH_MASK,
+                        IOMMU_PPR_LOG_LENGTH_SHIFT, &entry);
+    writel(entry, iommu->mmio_base + IOMMU_PPR_LOG_BASE_HIGH_OFFSET);
+}
+
+
 static void set_iommu_translation_control(struct amd_iommu *iommu,
                                                  int enable)
 {
@@ -278,6 +306,35 @@ static void set_iommu_event_log_control(
     writel(entry, iommu->mmio_base + IOMMU_CONTROL_MMIO_OFFSET);
 }
 
+static void set_iommu_ppr_log_control(struct amd_iommu *iommu,
+                                      int enable)
+{
+    u32 entry;
+
+    entry = readl(iommu->mmio_base + IOMMU_CONTROL_MMIO_OFFSET);
+
+    /*reset head and tail pointer manually before enablement */
+    if ( enable )
+    {
+        writel(0x0, iommu->mmio_base + IOMMU_PPR_LOG_HEAD_OFFSET);
+        writel(0x0, iommu->mmio_base + IOMMU_PPR_LOG_TAIL_OFFSET);
+
+        iommu_set_bit(&entry, IOMMU_CONTROL_PPR_ENABLE_SHIFT);
+        iommu_set_bit(&entry, IOMMU_CONTROL_PPR_INT_SHIFT);
+        iommu_set_bit(&entry, IOMMU_CONTROL_PPR_LOG_ENABLE_SHIFT);
+    }
+    else
+    {
+        iommu_clear_bit(&entry, IOMMU_CONTROL_PPR_ENABLE_SHIFT);
+        iommu_clear_bit(&entry, IOMMU_CONTROL_PPR_INT_SHIFT);
+        iommu_clear_bit(&entry, IOMMU_CONTROL_PPR_LOG_ENABLE_SHIFT);
+    }
+
+    writel(entry, iommu->mmio_base + IOMMU_CONTROL_MMIO_OFFSET);
+    if ( enable )
+        AMD_IOMMU_DEBUG("PPR Log Enabled.\n");
+}
+
 static void parse_event_log_entry(struct amd_iommu *, u32 entry[]);
 
 static int amd_iommu_read_event_log(struct amd_iommu *iommu)
@@ -585,12 +642,19 @@ static void enable_iommu(struct amd_iomm
     register_iommu_event_log_in_mmio_space(iommu);
     register_iommu_exclusion_range(iommu);
 
+    if ( iommu_has_feature(iommu, IOMMU_EXT_FEATURE_PPRSUP_SHIFT) )
+        register_iommu_ppr_log_in_mmio_space(iommu);
+
     iommu_msi_set_affinity(irq_to_desc(iommu->irq), &cpu_online_map);
     amd_iommu_msi_enable(iommu, IOMMU_CONTROL_ENABLED);
 
     set_iommu_ht_flags(iommu);
     set_iommu_command_buffer_control(iommu, IOMMU_CONTROL_ENABLED);
     set_iommu_event_log_control(iommu, IOMMU_CONTROL_ENABLED);
+
+    if ( iommu_has_feature(iommu, IOMMU_EXT_FEATURE_PPRSUP_SHIFT) )
+        set_iommu_ppr_log_control(iommu, IOMMU_CONTROL_ENABLED);
+
     set_iommu_translation_control(iommu, IOMMU_CONTROL_ENABLED);
 
     if ( iommu_has_feature(iommu, IOMMU_EXT_FEATURE_IASUP_SHIFT) )
@@ -672,16 +736,29 @@ static void * __init allocate_event_log(
                                 IOMMU_EVENT_LOG_DEFAULT_ENTRIES, "Event Log");
 }
 
+static void * __init allocate_ppr_log(struct amd_iommu *iommu)
+{
+    /* allocate 'ppr log' in power of 2 increments of 4K */
+    return allocate_ring_buffer(&iommu->ppr_log, sizeof(ppr_entry_t),
+                                IOMMU_PPR_LOG_DEFAULT_ENTRIES, "PPR Log");
+}
+
 static int __init amd_iommu_init_one(struct amd_iommu *iommu)
 {
+    if ( map_iommu_mmio_region(iommu) != 0 )
+        goto error_out;
+
+    get_iommu_features(iommu);
+
     if ( allocate_cmd_buffer(iommu) == NULL )
         goto error_out;
 
     if ( allocate_event_log(iommu) == NULL )
         goto error_out;
 
-    if ( map_iommu_mmio_region(iommu) != 0 )
-        goto error_out;
+    if ( iommu_has_feature(iommu, IOMMU_EXT_FEATURE_PPRSUP_SHIFT) )
+        if ( allocate_ppr_log(iommu) == NULL )
+            goto error_out;
 
     if ( set_iommu_interrupt_handler(iommu) == 0 )
         goto error_out;
@@ -694,8 +771,6 @@ static int __init amd_iommu_init_one(str
     iommu->dev_table.entries = device_table.entries;
     iommu->dev_table.buffer = device_table.buffer;
 
-    get_iommu_features(iommu);
-
     enable_iommu(iommu);
     printk("AMD-Vi: IOMMU %d Enabled.\n", nr_amd_iommus );
     nr_amd_iommus++;
@@ -718,6 +793,7 @@ static void __init amd_iommu_init_cleanu
         {
             deallocate_ring_buffer(&iommu->cmd_buffer);
             deallocate_ring_buffer(&iommu->event_log);
+            deallocate_ring_buffer(&iommu->ppr_log);
             unmap_iommu_mmio_region(iommu);
         }
         xfree(iommu);
@@ -916,6 +992,10 @@ static void disable_iommu(struct amd_iom
     amd_iommu_msi_enable(iommu, IOMMU_CONTROL_DISABLED);
     set_iommu_command_buffer_control(iommu, IOMMU_CONTROL_DISABLED);
     set_iommu_event_log_control(iommu, IOMMU_CONTROL_DISABLED);
+
+    if ( iommu_has_feature(iommu, IOMMU_EXT_FEATURE_PPRSUP_SHIFT) )
+        set_iommu_ppr_log_control(iommu, IOMMU_CONTROL_DISABLED);
+
     set_iommu_translation_control(iommu, IOMMU_CONTROL_DISABLED);
 
     iommu->enabled = 0;
diff -r 07f338ae6632 -r 33f88c76776c xen/include/asm-x86/amd-iommu.h
--- a/xen/include/asm-x86/amd-iommu.h	Thu Dec 22 16:56:17 2011 +0100
+++ b/xen/include/asm-x86/amd-iommu.h	Thu Dec 22 16:56:21 2011 +0100
@@ -94,6 +94,7 @@ struct amd_iommu {
     struct table_struct dev_table;
     struct ring_buffer cmd_buffer;
     struct ring_buffer event_log;
+    struct ring_buffer ppr_log;
 
     int exclusion_enable;
     int exclusion_allow_all;
diff -r 07f338ae6632 -r 33f88c76776c xen/include/asm-x86/hvm/svm/amd-iommu-defs.h
--- a/xen/include/asm-x86/hvm/svm/amd-iommu-defs.h	Thu Dec 22 16:56:17 2011 +0100
+++ b/xen/include/asm-x86/hvm/svm/amd-iommu-defs.h	Thu Dec 22 16:56:21 2011 +0100
@@ -27,6 +27,9 @@
 /* IOMMU Event Log entries: in power of 2 increments, minimum of 256 */
 #define IOMMU_EVENT_LOG_DEFAULT_ENTRIES     512
 
+/* IOMMU PPR Log entries: in power of 2 increments, minimum of 256 */
+#define IOMMU_PPR_LOG_DEFAULT_ENTRIES       512
+
 #define PTE_PER_TABLE_SHIFT		9
 #define PTE_PER_TABLE_SIZE		(1 << PTE_PER_TABLE_SHIFT)
 #define PTE_PER_TABLE_MASK		(~(PTE_PER_TABLE_SIZE - 1))


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 23 11:31:51 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 Dec 2011 11:31:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Re3LR-00018m-SP; Fri, 23 Dec 2011 11:31:25 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Wang2@amd.com>) id 1Re3LQ-00018D-C3
	for xen-devel@lists.xensource.com; Fri, 23 Dec 2011 11:31:24 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1324639877!7997082!1
X-Originating-IP: [213.199.154.139]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 487 invoked from network); 23 Dec 2011 11:31:18 -0000
Received: from db3ehsobe001.messaging.microsoft.com (HELO
	DB3EHSOBE001.bigfish.com) (213.199.154.139)
	by server-14.tower-216.messagelabs.com with AES128-SHA encrypted SMTP;
	23 Dec 2011 11:31:18 -0000
Received: from mail9-db3-R.bigfish.com (10.3.81.249) by
	DB3EHSOBE001.bigfish.com (10.3.84.21) with Microsoft SMTP Server id
	14.1.225.23; Fri, 23 Dec 2011 11:31:05 +0000
Received: from mail9-db3 (localhost [127.0.0.1])	by mail9-db3-R.bigfish.com
	(Postfix) with ESMTP id 232526A0561;
	Fri, 23 Dec 2011 11:31:45 +0000 (UTC)
X-SpamScore: -4
X-BigFish: VPS-4(zz4015Lzz1202hzzz2dh668h839h944h)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
Received: from mail9-db3 (localhost.localdomain [127.0.0.1]) by mail9-db3
	(MessageSwitch) id 1324639904971641_30547;
	Fri, 23 Dec 2011 11:31:44 +0000 (UTC)
Received: from DB3EHSMHS007.bigfish.com (unknown [10.3.81.254])	by
	mail9-db3.bigfish.com (Postfix) with ESMTP id E7CA41A004B;
	Fri, 23 Dec 2011 11:31:44 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	DB3EHSMHS007.bigfish.com (10.3.87.107) with Microsoft SMTP Server id
	14.1.225.23; Fri, 23 Dec 2011 11:31:04 +0000
X-WSS-ID: 0LWNMO0-02-0WX-02
X-M-MSG: 
Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com
	[163.181.249.73])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp02.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 26095C80D6;	Fri, 23 Dec 2011 05:31:12 -0600 (CST)
Received: from SAUSEXDAG02.amd.com (163.181.55.2) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Fri, 23 Dec 2011 05:31:30 -0600
Received: from storexhtp02.amd.com (172.24.4.4) by sausexdag02.amd.com
	(163.181.55.2) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Fri, 23 Dec 2011 05:31:12 -0600
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Fri, 23 Dec 2011
	06:30:41 -0500
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 4253B49C0F1; Fri, 23 Dec 2011
	11:30:41 +0000 (GMT)
Received: from gran.amd.com (gran.osrc.amd.com [165.204.15.57])	by
	mail.osrc.amd.com (Postfix) with ESMTP id 2BBE45940FF; Fri, 23 Dec 2011
	12:30:41 +0100 (CET)
MIME-Version: 1.0
Message-ID: <patchbomb.1324639749@gran.amd.com>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Fri, 23 Dec 2011 12:29:09 +0100
From: Wei Wang <wei.wang2@amd.com>
To: <JBeulich@suse.com>, <Ian.Jackson@eu.citrix.com>,
	<Ian.Campbell@citrix.com>, <keir@xen.org>
X-OriginatorOrg: amd.com
Cc: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 00 of 16] [V2] amd iommu: support ATS device
 passthru on IOMMUv2 systems
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

ATS devices with PRI and PASID capabilities can communicate with iommuv2 to 
perform two level (nested) address translation and demand paging for DMA. 
To passthru such devices, iommu driver has to been enabled in guest OS. 
This patch set adds initial iommu emulation for hvm guests to support ATS 
device passthru. 

Changes in v2:
* Do not use linked list to access guest iommu tables.
* Do not parse iommu parameter in libxl_device_model_info again.
* Fix incorrect logical calculation in patch 11.
* Fix hypercall definition for non-x86 systems.

Please review.
Thanks,

Wei


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 23 11:31:51 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 Dec 2011 11:31:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Re3LR-00018m-SP; Fri, 23 Dec 2011 11:31:25 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Wang2@amd.com>) id 1Re3LQ-00018D-C3
	for xen-devel@lists.xensource.com; Fri, 23 Dec 2011 11:31:24 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1324639877!7997082!1
X-Originating-IP: [213.199.154.139]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 487 invoked from network); 23 Dec 2011 11:31:18 -0000
Received: from db3ehsobe001.messaging.microsoft.com (HELO
	DB3EHSOBE001.bigfish.com) (213.199.154.139)
	by server-14.tower-216.messagelabs.com with AES128-SHA encrypted SMTP;
	23 Dec 2011 11:31:18 -0000
Received: from mail9-db3-R.bigfish.com (10.3.81.249) by
	DB3EHSOBE001.bigfish.com (10.3.84.21) with Microsoft SMTP Server id
	14.1.225.23; Fri, 23 Dec 2011 11:31:05 +0000
Received: from mail9-db3 (localhost [127.0.0.1])	by mail9-db3-R.bigfish.com
	(Postfix) with ESMTP id 232526A0561;
	Fri, 23 Dec 2011 11:31:45 +0000 (UTC)
X-SpamScore: -4
X-BigFish: VPS-4(zz4015Lzz1202hzzz2dh668h839h944h)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
Received: from mail9-db3 (localhost.localdomain [127.0.0.1]) by mail9-db3
	(MessageSwitch) id 1324639904971641_30547;
	Fri, 23 Dec 2011 11:31:44 +0000 (UTC)
Received: from DB3EHSMHS007.bigfish.com (unknown [10.3.81.254])	by
	mail9-db3.bigfish.com (Postfix) with ESMTP id E7CA41A004B;
	Fri, 23 Dec 2011 11:31:44 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	DB3EHSMHS007.bigfish.com (10.3.87.107) with Microsoft SMTP Server id
	14.1.225.23; Fri, 23 Dec 2011 11:31:04 +0000
X-WSS-ID: 0LWNMO0-02-0WX-02
X-M-MSG: 
Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com
	[163.181.249.73])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp02.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 26095C80D6;	Fri, 23 Dec 2011 05:31:12 -0600 (CST)
Received: from SAUSEXDAG02.amd.com (163.181.55.2) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Fri, 23 Dec 2011 05:31:30 -0600
Received: from storexhtp02.amd.com (172.24.4.4) by sausexdag02.amd.com
	(163.181.55.2) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Fri, 23 Dec 2011 05:31:12 -0600
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Fri, 23 Dec 2011
	06:30:41 -0500
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 4253B49C0F1; Fri, 23 Dec 2011
	11:30:41 +0000 (GMT)
Received: from gran.amd.com (gran.osrc.amd.com [165.204.15.57])	by
	mail.osrc.amd.com (Postfix) with ESMTP id 2BBE45940FF; Fri, 23 Dec 2011
	12:30:41 +0100 (CET)
MIME-Version: 1.0
Message-ID: <patchbomb.1324639749@gran.amd.com>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Fri, 23 Dec 2011 12:29:09 +0100
From: Wei Wang <wei.wang2@amd.com>
To: <JBeulich@suse.com>, <Ian.Jackson@eu.citrix.com>,
	<Ian.Campbell@citrix.com>, <keir@xen.org>
X-OriginatorOrg: amd.com
Cc: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 00 of 16] [V2] amd iommu: support ATS device
 passthru on IOMMUv2 systems
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

ATS devices with PRI and PASID capabilities can communicate with iommuv2 to 
perform two level (nested) address translation and demand paging for DMA. 
To passthru such devices, iommu driver has to been enabled in guest OS. 
This patch set adds initial iommu emulation for hvm guests to support ATS 
device passthru. 

Changes in v2:
* Do not use linked list to access guest iommu tables.
* Do not parse iommu parameter in libxl_device_model_info again.
* Fix incorrect logical calculation in patch 11.
* Fix hypercall definition for non-x86 systems.

Please review.
Thanks,

Wei


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 23 11:31:51 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 Dec 2011 11:31:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Re3LQ-00018T-2H; Fri, 23 Dec 2011 11:31:24 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Wang2@amd.com>) id 1Re3LO-00018B-O5
	for xen-devel@lists.xensource.com; Fri, 23 Dec 2011 11:31:22 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1324639830!50169071!1
X-Originating-IP: [213.199.154.140]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24443 invoked from network); 23 Dec 2011 11:30:30 -0000
Received: from db3ehsobe002.messaging.microsoft.com (HELO
	DB3EHSOBE002.bigfish.com) (213.199.154.140)
	by server-3.tower-27.messagelabs.com with AES128-SHA encrypted SMTP;
	23 Dec 2011 11:30:30 -0000
Received: from mail73-db3-R.bigfish.com (10.3.81.244) by
	DB3EHSOBE002.bigfish.com (10.3.84.22) with Microsoft SMTP Server id
	14.1.225.23; Fri, 23 Dec 2011 11:31:04 +0000
Received: from mail73-db3 (localhost [127.0.0.1])	by mail73-db3-R.bigfish.com
	(Postfix) with ESMTP id E40981E045F;
	Fri, 23 Dec 2011 11:31:45 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzzz1202hzz8275bhz2dh668h839h944h)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
Received: from mail73-db3 (localhost.localdomain [127.0.0.1]) by mail73-db3
	(MessageSwitch) id 1324639905767200_26647;
	Fri, 23 Dec 2011 11:31:45 +0000 (UTC)
Received: from DB3EHSMHS012.bigfish.com (unknown [10.3.81.250])	by
	mail73-db3.bigfish.com (Postfix) with ESMTP id 9825F80046;
	Fri, 23 Dec 2011 11:31:45 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	DB3EHSMHS012.bigfish.com (10.3.87.112) with Microsoft SMTP Server id
	14.1.225.23; Fri, 23 Dec 2011 11:31:03 +0000
X-WSS-ID: 0LWNMO1-01-1G9-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 25C66102809D;	Fri, 23 Dec 2011 05:31:13 -0600 (CST)
Received: from SAUSEXDAG02.amd.com (163.181.55.2) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Fri, 23 Dec 2011 05:31:32 -0600
Received: from storexhtp02.amd.com (172.24.4.4) by sausexdag02.amd.com
	(163.181.55.2) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Fri, 23 Dec 2011 05:31:13 -0600
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Fri, 23 Dec 2011
	06:30:43 -0500
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 1EE5F49C663; Fri, 23 Dec 2011
	11:30:42 +0000 (GMT)
Received: from gran.amd.com (gran.osrc.amd.com [165.204.15.57])	by
	mail.osrc.amd.com (Postfix) with ESMTP id E9D8A594884; Fri, 23 Dec 2011
	12:30:41 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 2329dad2786f6f20ea69c9609ab60208cad6fca9
Message-ID: <2329dad2786f6f20ea69.1324639757@gran.amd.com>
In-Reply-To: <patchbomb.1324639749@gran.amd.com>
References: <patchbomb.1324639749@gran.amd.com>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Fri, 23 Dec 2011 12:29:17 +0100
From: Wei Wang <wei.wang2@amd.com>
To: <JBeulich@suse.com>, <Ian.Jackson@eu.citrix.com>,
	<Ian.Campbell@citrix.com>, <keir@xen.org>
X-OriginatorOrg: amd.com
Cc: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 08 of 16] amd iommu: Add a hypercall for
	hvmloader
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Wei Wang <wei.wang2@amd.com>
# Date 1324569395 -3600
# Node ID 2329dad2786f6f20ea69c9609ab60208cad6fca9
# Parent  40d61d0390ec930cf53ce5cbf91faada8c7192bd
amd iommu: Add a hypercall for hvmloader.
IOMMU MMIO base address is dynamically allocated by firmware.
This patch allows hvmloader to notify hypervisor where the
iommu mmio pages are.

Signed-off-by: Wei Wang <wei.wang2@amd.com>

diff -r 40d61d0390ec -r 2329dad2786f xen/arch/x86/hvm/hvm.c
--- a/xen/arch/x86/hvm/hvm.c	Thu Dec 22 16:56:32 2011 +0100
+++ b/xen/arch/x86/hvm/hvm.c	Thu Dec 22 16:56:35 2011 +0100
@@ -65,6 +65,7 @@
 #include <public/memory.h>
 #include <asm/mem_event.h>
 #include <public/mem_event.h>
+#include <asm/hvm/svm/amd-iommu-proto.h>
 
 bool_t __read_mostly hvm_enabled;
 
@@ -3677,6 +3678,9 @@ long do_hvm_op(unsigned long op, XEN_GUE
             case HVM_PARAM_BUFIOREQ_EVTCHN:
                 rc = -EINVAL;
                 break;
+            case HVM_PARAM_IOMMU_BASE:
+                rc = guest_iommu_set_base(d, a.value);
+                break;
             }
 
             if ( rc == 0 ) 
diff -r 40d61d0390ec -r 2329dad2786f xen/include/public/hvm/params.h
--- a/xen/include/public/hvm/params.h	Thu Dec 22 16:56:32 2011 +0100
+++ b/xen/include/public/hvm/params.h	Thu Dec 22 16:56:35 2011 +0100
@@ -142,6 +142,10 @@
 /* Boolean: Enable nestedhvm (hvm only) */
 #define HVM_PARAM_NESTEDHVM    24
 
-#define HVM_NR_PARAMS          27
+#ifndef __ia64__
+#define HVM_PARAM_IOMMU_BASE   27
+#endif
+
+#define HVM_NR_PARAMS          28
 
 #endif /* __XEN_PUBLIC_HVM_PARAMS_H__ */


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 23 11:31:51 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 Dec 2011 11:31:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Re3LQ-00018T-2H; Fri, 23 Dec 2011 11:31:24 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Wang2@amd.com>) id 1Re3LO-00018B-O5
	for xen-devel@lists.xensource.com; Fri, 23 Dec 2011 11:31:22 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1324639830!50169071!1
X-Originating-IP: [213.199.154.140]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24443 invoked from network); 23 Dec 2011 11:30:30 -0000
Received: from db3ehsobe002.messaging.microsoft.com (HELO
	DB3EHSOBE002.bigfish.com) (213.199.154.140)
	by server-3.tower-27.messagelabs.com with AES128-SHA encrypted SMTP;
	23 Dec 2011 11:30:30 -0000
Received: from mail73-db3-R.bigfish.com (10.3.81.244) by
	DB3EHSOBE002.bigfish.com (10.3.84.22) with Microsoft SMTP Server id
	14.1.225.23; Fri, 23 Dec 2011 11:31:04 +0000
Received: from mail73-db3 (localhost [127.0.0.1])	by mail73-db3-R.bigfish.com
	(Postfix) with ESMTP id E40981E045F;
	Fri, 23 Dec 2011 11:31:45 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzzz1202hzz8275bhz2dh668h839h944h)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
Received: from mail73-db3 (localhost.localdomain [127.0.0.1]) by mail73-db3
	(MessageSwitch) id 1324639905767200_26647;
	Fri, 23 Dec 2011 11:31:45 +0000 (UTC)
Received: from DB3EHSMHS012.bigfish.com (unknown [10.3.81.250])	by
	mail73-db3.bigfish.com (Postfix) with ESMTP id 9825F80046;
	Fri, 23 Dec 2011 11:31:45 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	DB3EHSMHS012.bigfish.com (10.3.87.112) with Microsoft SMTP Server id
	14.1.225.23; Fri, 23 Dec 2011 11:31:03 +0000
X-WSS-ID: 0LWNMO1-01-1G9-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 25C66102809D;	Fri, 23 Dec 2011 05:31:13 -0600 (CST)
Received: from SAUSEXDAG02.amd.com (163.181.55.2) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Fri, 23 Dec 2011 05:31:32 -0600
Received: from storexhtp02.amd.com (172.24.4.4) by sausexdag02.amd.com
	(163.181.55.2) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Fri, 23 Dec 2011 05:31:13 -0600
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Fri, 23 Dec 2011
	06:30:43 -0500
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 1EE5F49C663; Fri, 23 Dec 2011
	11:30:42 +0000 (GMT)
Received: from gran.amd.com (gran.osrc.amd.com [165.204.15.57])	by
	mail.osrc.amd.com (Postfix) with ESMTP id E9D8A594884; Fri, 23 Dec 2011
	12:30:41 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 2329dad2786f6f20ea69c9609ab60208cad6fca9
Message-ID: <2329dad2786f6f20ea69.1324639757@gran.amd.com>
In-Reply-To: <patchbomb.1324639749@gran.amd.com>
References: <patchbomb.1324639749@gran.amd.com>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Fri, 23 Dec 2011 12:29:17 +0100
From: Wei Wang <wei.wang2@amd.com>
To: <JBeulich@suse.com>, <Ian.Jackson@eu.citrix.com>,
	<Ian.Campbell@citrix.com>, <keir@xen.org>
X-OriginatorOrg: amd.com
Cc: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 08 of 16] amd iommu: Add a hypercall for
	hvmloader
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Wei Wang <wei.wang2@amd.com>
# Date 1324569395 -3600
# Node ID 2329dad2786f6f20ea69c9609ab60208cad6fca9
# Parent  40d61d0390ec930cf53ce5cbf91faada8c7192bd
amd iommu: Add a hypercall for hvmloader.
IOMMU MMIO base address is dynamically allocated by firmware.
This patch allows hvmloader to notify hypervisor where the
iommu mmio pages are.

Signed-off-by: Wei Wang <wei.wang2@amd.com>

diff -r 40d61d0390ec -r 2329dad2786f xen/arch/x86/hvm/hvm.c
--- a/xen/arch/x86/hvm/hvm.c	Thu Dec 22 16:56:32 2011 +0100
+++ b/xen/arch/x86/hvm/hvm.c	Thu Dec 22 16:56:35 2011 +0100
@@ -65,6 +65,7 @@
 #include <public/memory.h>
 #include <asm/mem_event.h>
 #include <public/mem_event.h>
+#include <asm/hvm/svm/amd-iommu-proto.h>
 
 bool_t __read_mostly hvm_enabled;
 
@@ -3677,6 +3678,9 @@ long do_hvm_op(unsigned long op, XEN_GUE
             case HVM_PARAM_BUFIOREQ_EVTCHN:
                 rc = -EINVAL;
                 break;
+            case HVM_PARAM_IOMMU_BASE:
+                rc = guest_iommu_set_base(d, a.value);
+                break;
             }
 
             if ( rc == 0 ) 
diff -r 40d61d0390ec -r 2329dad2786f xen/include/public/hvm/params.h
--- a/xen/include/public/hvm/params.h	Thu Dec 22 16:56:32 2011 +0100
+++ b/xen/include/public/hvm/params.h	Thu Dec 22 16:56:35 2011 +0100
@@ -142,6 +142,10 @@
 /* Boolean: Enable nestedhvm (hvm only) */
 #define HVM_PARAM_NESTEDHVM    24
 
-#define HVM_NR_PARAMS          27
+#ifndef __ia64__
+#define HVM_PARAM_IOMMU_BASE   27
+#endif
+
+#define HVM_NR_PARAMS          28
 
 #endif /* __XEN_PUBLIC_HVM_PARAMS_H__ */


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 23 11:31:53 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 Dec 2011 11:31:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Re3Ll-0001KW-Ax; Fri, 23 Dec 2011 11:31:45 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Wang2@amd.com>) id 1Re3Lj-0001GQ-O7
	for xen-devel@lists.xensource.com; Fri, 23 Dec 2011 11:31:43 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1324639883!8416658!1
X-Originating-IP: [213.199.154.143]
X-SpamReason: No, hits=0.0 required=7.0 tests=UPPERCASE_25_50
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6326 invoked from network); 23 Dec 2011 11:31:23 -0000
Received: from db3ehsobe005.messaging.microsoft.com (HELO
	DB3EHSOBE005.bigfish.com) (213.199.154.143)
	by server-16.tower-216.messagelabs.com with AES128-SHA encrypted SMTP;
	23 Dec 2011 11:31:23 -0000
Received: from mail9-db3-R.bigfish.com (10.3.81.247) by
	DB3EHSOBE005.bigfish.com (10.3.84.25) with Microsoft SMTP Server id
	14.1.225.23; Fri, 23 Dec 2011 11:31:10 +0000
Received: from mail9-db3 (localhost [127.0.0.1])	by mail9-db3-R.bigfish.com
	(Postfix) with ESMTP id 6C8ED6A01A6;
	Fri, 23 Dec 2011 11:31:48 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzzz1202hzz8275bhz2dh668h839h944h)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
X-FB-SS: 13,
Received: from mail9-db3 (localhost.localdomain [127.0.0.1]) by mail9-db3
	(MessageSwitch) id 1324639908300961_30570;
	Fri, 23 Dec 2011 11:31:48 +0000 (UTC)
Received: from DB3EHSMHS011.bigfish.com (unknown [10.3.81.241])	by
	mail9-db3.bigfish.com (Postfix) with ESMTP id 3A99F1A0043;
	Fri, 23 Dec 2011 11:31:48 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	DB3EHSMHS011.bigfish.com (10.3.87.111) with Microsoft SMTP Server id
	14.1.225.23; Fri, 23 Dec 2011 11:31:07 +0000
X-WSS-ID: 0LWNMO5-01-1GF-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 23F1D10280A2;	Fri, 23 Dec 2011 05:31:16 -0600 (CST)
Received: from SAUSEXDAG02.amd.com (163.181.55.2) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Fri, 23 Dec 2011 05:31:34 -0600
Received: from storexhtp01.amd.com (172.24.4.3) by sausexdag02.amd.com
	(163.181.55.2) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Fri, 23 Dec 2011 05:31:16 -0600
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp01.amd.com
	(172.24.4.3) with Microsoft SMTP Server id 8.3.213.0; Fri, 23 Dec 2011
	06:30:43 -0500
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id C6ACF49C660; Fri, 23 Dec 2011
	11:30:41 +0000 (GMT)
Received: from gran.amd.com (gran.osrc.amd.com [165.204.15.57])	by
	mail.osrc.amd.com (Postfix) with ESMTP id A82F65940FF; Fri, 23 Dec 2011
	12:30:41 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 120144c1fac2dd26926b3b2a6362d30a4029620f
Message-ID: <120144c1fac2dd26926b.1324639754@gran.amd.com>
In-Reply-To: <patchbomb.1324639749@gran.amd.com>
References: <patchbomb.1324639749@gran.amd.com>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Fri, 23 Dec 2011 12:29:14 +0100
From: Wei Wang <wei.wang2@amd.com>
To: <JBeulich@suse.com>, <Ian.Jackson@eu.citrix.com>,
	<Ian.Campbell@citrix.com>, <keir@xen.org>
X-OriginatorOrg: amd.com
Cc: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 05 of 16] amd iommu: Enable guest level
	translation
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Wei Wang <wei.wang2@amd.com>
# Date 1324569385 -3600
# Node ID 120144c1fac2dd26926b3b2a6362d30a4029620f
# Parent  33f88c76776c318eea74b8fc1ba467389407ad57
amd iommu: Enable guest level translation.
Similar to nested paging for SVM, IOMMUv2 supports two level translations for
DMA. This patch enables this feature.

Signed-off-by: Wei Wang <wei.wang2@amd.com>

diff -r 33f88c76776c -r 120144c1fac2 xen/drivers/passthrough/amd/iommu_init.c
--- a/xen/drivers/passthrough/amd/iommu_init.c	Thu Dec 22 16:56:21 2011 +0100
+++ b/xen/drivers/passthrough/amd/iommu_init.c	Thu Dec 22 16:56:25 2011 +0100
@@ -220,6 +220,23 @@ static void set_iommu_translation_contro
     writel(entry, iommu->mmio_base+IOMMU_CONTROL_MMIO_OFFSET);
 }
 
+static void set_iommu_guest_translation_control(struct amd_iommu *iommu,
+                                                int enable)
+{
+    u32 entry;
+
+    entry = readl(iommu->mmio_base + IOMMU_CONTROL_MMIO_OFFSET);
+
+    enable ?
+        iommu_set_bit(&entry, IOMMU_CONTROL_GT_ENABLE_SHIFT):
+        iommu_clear_bit(&entry, IOMMU_CONTROL_GT_ENABLE_SHIFT);
+
+    writel(entry, iommu->mmio_base+IOMMU_CONTROL_MMIO_OFFSET);
+
+    if ( enable )
+        AMD_IOMMU_DEBUG("Guest Translation Enabled.\n");
+}
+
 static void set_iommu_command_buffer_control(struct amd_iommu *iommu,
                                                     int enable)
 {
@@ -655,6 +672,9 @@ static void enable_iommu(struct amd_iomm
     if ( iommu_has_feature(iommu, IOMMU_EXT_FEATURE_PPRSUP_SHIFT) )
         set_iommu_ppr_log_control(iommu, IOMMU_CONTROL_ENABLED);
 
+    if ( iommu_has_feature(iommu, IOMMU_EXT_FEATURE_GTSUP_SHIFT) )
+        set_iommu_guest_translation_control(iommu, IOMMU_CONTROL_ENABLED);
+
     set_iommu_translation_control(iommu, IOMMU_CONTROL_ENABLED);
 
     if ( iommu_has_feature(iommu, IOMMU_EXT_FEATURE_IASUP_SHIFT) )
@@ -996,6 +1016,9 @@ static void disable_iommu(struct amd_iom
     if ( iommu_has_feature(iommu, IOMMU_EXT_FEATURE_PPRSUP_SHIFT) )
         set_iommu_ppr_log_control(iommu, IOMMU_CONTROL_DISABLED);
 
+    if ( iommu_has_feature(iommu, IOMMU_EXT_FEATURE_GTSUP_SHIFT) )
+        set_iommu_guest_translation_control(iommu, IOMMU_CONTROL_DISABLED);
+
     set_iommu_translation_control(iommu, IOMMU_CONTROL_DISABLED);
 
     iommu->enabled = 0;


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 23 11:31:53 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 Dec 2011 11:31:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Re3Ll-0001KW-Ax; Fri, 23 Dec 2011 11:31:45 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Wang2@amd.com>) id 1Re3Lj-0001GQ-O7
	for xen-devel@lists.xensource.com; Fri, 23 Dec 2011 11:31:43 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1324639883!8416658!1
X-Originating-IP: [213.199.154.143]
X-SpamReason: No, hits=0.0 required=7.0 tests=UPPERCASE_25_50
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6326 invoked from network); 23 Dec 2011 11:31:23 -0000
Received: from db3ehsobe005.messaging.microsoft.com (HELO
	DB3EHSOBE005.bigfish.com) (213.199.154.143)
	by server-16.tower-216.messagelabs.com with AES128-SHA encrypted SMTP;
	23 Dec 2011 11:31:23 -0000
Received: from mail9-db3-R.bigfish.com (10.3.81.247) by
	DB3EHSOBE005.bigfish.com (10.3.84.25) with Microsoft SMTP Server id
	14.1.225.23; Fri, 23 Dec 2011 11:31:10 +0000
Received: from mail9-db3 (localhost [127.0.0.1])	by mail9-db3-R.bigfish.com
	(Postfix) with ESMTP id 6C8ED6A01A6;
	Fri, 23 Dec 2011 11:31:48 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzzz1202hzz8275bhz2dh668h839h944h)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
X-FB-SS: 13,
Received: from mail9-db3 (localhost.localdomain [127.0.0.1]) by mail9-db3
	(MessageSwitch) id 1324639908300961_30570;
	Fri, 23 Dec 2011 11:31:48 +0000 (UTC)
Received: from DB3EHSMHS011.bigfish.com (unknown [10.3.81.241])	by
	mail9-db3.bigfish.com (Postfix) with ESMTP id 3A99F1A0043;
	Fri, 23 Dec 2011 11:31:48 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	DB3EHSMHS011.bigfish.com (10.3.87.111) with Microsoft SMTP Server id
	14.1.225.23; Fri, 23 Dec 2011 11:31:07 +0000
X-WSS-ID: 0LWNMO5-01-1GF-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 23F1D10280A2;	Fri, 23 Dec 2011 05:31:16 -0600 (CST)
Received: from SAUSEXDAG02.amd.com (163.181.55.2) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Fri, 23 Dec 2011 05:31:34 -0600
Received: from storexhtp01.amd.com (172.24.4.3) by sausexdag02.amd.com
	(163.181.55.2) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Fri, 23 Dec 2011 05:31:16 -0600
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp01.amd.com
	(172.24.4.3) with Microsoft SMTP Server id 8.3.213.0; Fri, 23 Dec 2011
	06:30:43 -0500
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id C6ACF49C660; Fri, 23 Dec 2011
	11:30:41 +0000 (GMT)
Received: from gran.amd.com (gran.osrc.amd.com [165.204.15.57])	by
	mail.osrc.amd.com (Postfix) with ESMTP id A82F65940FF; Fri, 23 Dec 2011
	12:30:41 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 120144c1fac2dd26926b3b2a6362d30a4029620f
Message-ID: <120144c1fac2dd26926b.1324639754@gran.amd.com>
In-Reply-To: <patchbomb.1324639749@gran.amd.com>
References: <patchbomb.1324639749@gran.amd.com>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Fri, 23 Dec 2011 12:29:14 +0100
From: Wei Wang <wei.wang2@amd.com>
To: <JBeulich@suse.com>, <Ian.Jackson@eu.citrix.com>,
	<Ian.Campbell@citrix.com>, <keir@xen.org>
X-OriginatorOrg: amd.com
Cc: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 05 of 16] amd iommu: Enable guest level
	translation
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Wei Wang <wei.wang2@amd.com>
# Date 1324569385 -3600
# Node ID 120144c1fac2dd26926b3b2a6362d30a4029620f
# Parent  33f88c76776c318eea74b8fc1ba467389407ad57
amd iommu: Enable guest level translation.
Similar to nested paging for SVM, IOMMUv2 supports two level translations for
DMA. This patch enables this feature.

Signed-off-by: Wei Wang <wei.wang2@amd.com>

diff -r 33f88c76776c -r 120144c1fac2 xen/drivers/passthrough/amd/iommu_init.c
--- a/xen/drivers/passthrough/amd/iommu_init.c	Thu Dec 22 16:56:21 2011 +0100
+++ b/xen/drivers/passthrough/amd/iommu_init.c	Thu Dec 22 16:56:25 2011 +0100
@@ -220,6 +220,23 @@ static void set_iommu_translation_contro
     writel(entry, iommu->mmio_base+IOMMU_CONTROL_MMIO_OFFSET);
 }
 
+static void set_iommu_guest_translation_control(struct amd_iommu *iommu,
+                                                int enable)
+{
+    u32 entry;
+
+    entry = readl(iommu->mmio_base + IOMMU_CONTROL_MMIO_OFFSET);
+
+    enable ?
+        iommu_set_bit(&entry, IOMMU_CONTROL_GT_ENABLE_SHIFT):
+        iommu_clear_bit(&entry, IOMMU_CONTROL_GT_ENABLE_SHIFT);
+
+    writel(entry, iommu->mmio_base+IOMMU_CONTROL_MMIO_OFFSET);
+
+    if ( enable )
+        AMD_IOMMU_DEBUG("Guest Translation Enabled.\n");
+}
+
 static void set_iommu_command_buffer_control(struct amd_iommu *iommu,
                                                     int enable)
 {
@@ -655,6 +672,9 @@ static void enable_iommu(struct amd_iomm
     if ( iommu_has_feature(iommu, IOMMU_EXT_FEATURE_PPRSUP_SHIFT) )
         set_iommu_ppr_log_control(iommu, IOMMU_CONTROL_ENABLED);
 
+    if ( iommu_has_feature(iommu, IOMMU_EXT_FEATURE_GTSUP_SHIFT) )
+        set_iommu_guest_translation_control(iommu, IOMMU_CONTROL_ENABLED);
+
     set_iommu_translation_control(iommu, IOMMU_CONTROL_ENABLED);
 
     if ( iommu_has_feature(iommu, IOMMU_EXT_FEATURE_IASUP_SHIFT) )
@@ -996,6 +1016,9 @@ static void disable_iommu(struct amd_iom
     if ( iommu_has_feature(iommu, IOMMU_EXT_FEATURE_PPRSUP_SHIFT) )
         set_iommu_ppr_log_control(iommu, IOMMU_CONTROL_DISABLED);
 
+    if ( iommu_has_feature(iommu, IOMMU_EXT_FEATURE_GTSUP_SHIFT) )
+        set_iommu_guest_translation_control(iommu, IOMMU_CONTROL_DISABLED);
+
     set_iommu_translation_control(iommu, IOMMU_CONTROL_DISABLED);
 
     iommu->enabled = 0;


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 23 11:31:53 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 Dec 2011 11:31:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Re3LW-0001BE-Mo; Fri, 23 Dec 2011 11:31:30 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Wang2@amd.com>) id 1Re3LV-00018R-Bb
	for xen-devel@lists.xensource.com; Fri, 23 Dec 2011 11:31:29 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1324639882!6689038!1
X-Originating-IP: [213.199.154.141]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13444 invoked from network); 23 Dec 2011 11:31:23 -0000
Received: from db3ehsobe003.messaging.microsoft.com (HELO
	DB3EHSOBE003.bigfish.com) (213.199.154.141)
	by server-9.tower-174.messagelabs.com with AES128-SHA encrypted SMTP;
	23 Dec 2011 11:31:23 -0000
Received: from mail47-db3-R.bigfish.com (10.3.81.242) by
	DB3EHSOBE003.bigfish.com (10.3.84.23) with Microsoft SMTP Server id
	14.1.225.23; Fri, 23 Dec 2011 11:31:10 +0000
Received: from mail47-db3 (localhost [127.0.0.1])	by mail47-db3-R.bigfish.com
	(Postfix) with ESMTP id A3C6E240131;
	Fri, 23 Dec 2011 11:31:50 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzzz1202hzz8275bhz2dh668h839h944h)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
X-FB-SS: 13,
Received: from mail47-db3 (localhost.localdomain [127.0.0.1]) by mail47-db3
	(MessageSwitch) id 1324639909407705_32086;
	Fri, 23 Dec 2011 11:31:49 +0000 (UTC)
Received: from DB3EHSMHS008.bigfish.com (unknown [10.3.81.245])	by
	mail47-db3.bigfish.com (Postfix) with ESMTP id 5C4904E004C;
	Fri, 23 Dec 2011 11:31:49 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	DB3EHSMHS008.bigfish.com (10.3.87.108) with Microsoft SMTP Server id
	14.1.225.23; Fri, 23 Dec 2011 11:31:07 +0000
X-WSS-ID: 0LWNMO5-02-0XE-02
X-M-MSG: 
Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com
	[163.181.249.73])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp02.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2F862C80D4;	Fri, 23 Dec 2011 05:31:16 -0600 (CST)
Received: from SAUSEXDAG02.amd.com (163.181.55.2) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Fri, 23 Dec 2011 05:31:35 -0600
Received: from storexhtp02.amd.com (172.24.4.4) by sausexdag02.amd.com
	(163.181.55.2) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Fri, 23 Dec 2011 05:31:17 -0600
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Fri, 23 Dec 2011
	06:30:44 -0500
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 1F59649C65F; Fri, 23 Dec 2011
	11:30:43 +0000 (GMT)
Received: from gran.amd.com (gran.osrc.amd.com [165.204.15.57])	by
	mail.osrc.amd.com (Postfix) with ESMTP id 13521594886; Fri, 23 Dec 2011
	12:30:43 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 1aad019305172c4abca8c2c9d7e632fe3291fead
Message-ID: <1aad019305172c4abca8.1324639765@gran.amd.com>
In-Reply-To: <patchbomb.1324639749@gran.amd.com>
References: <patchbomb.1324639749@gran.amd.com>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Fri, 23 Dec 2011 12:29:25 +0100
From: Wei Wang <wei.wang2@amd.com>
To: <JBeulich@suse.com>, <Ian.Jackson@eu.citrix.com>,
	<Ian.Campbell@citrix.com>, <keir@xen.org>
X-OriginatorOrg: amd.com
Cc: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 16 of 16] libxl: pass iommu parameter to qemu-dm
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Wei Wang <wei.wang2@amd.com>
# Date 1324569422 -3600
# Node ID 1aad019305172c4abca8c2c9d7e632fe3291fead
# Parent  8ea73cd1a367b318f72026a02629c774d24f999f
libxl: pass iommu parameter to qemu-dm.
When iomm = 0, virtual iommu device will be disabled.

Signed-off-by: Wei Wang <wei.wang2@amd.com>

diff -r 8ea73cd1a367 -r 1aad01930517 tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Thu Dec 22 16:56:59 2011 +0100
+++ b/tools/libxl/libxl_create.c	Thu Dec 22 16:57:02 2011 +0100
@@ -559,7 +559,7 @@ static int do_domain_create(libxl__gc *g
         libxl_device_vkb_dispose(&vkb);
 
         dm_info->domid = domid;
-        ret = libxl__create_device_model(gc, dm_info,
+        ret = libxl__create_device_model(gc, dm_info, &d_config->b_info,
                                         d_config->disks, d_config->num_disks,
                                         d_config->vifs, d_config->num_vifs,
                                         &dm_starting);
diff -r 8ea73cd1a367 -r 1aad01930517 tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Thu Dec 22 16:56:59 2011 +0100
+++ b/tools/libxl/libxl_dm.c	Thu Dec 22 16:57:02 2011 +0100
@@ -84,6 +84,7 @@ static const char *libxl__domain_bios(li
 static char ** libxl__build_device_model_args_old(libxl__gc *gc,
                                                   const char *dm,
                                                   libxl_device_model_info *info,
+                                                  libxl_domain_build_info *b_info,
                                                   libxl_device_disk *disks, int num_disks,
                                                   libxl_device_nic *vifs, int num_vifs)
 {
@@ -199,6 +200,9 @@ static char ** libxl__build_device_model
         if (info->gfx_passthru) {
             flexarray_append(dm_args, "-gfx_passthru");
         }
+        if (b_info && b_info->u.hvm.iommu) {
+            flexarray_append(dm_args, "-iommu");
+        }
     }
     if (info->saved_state) {
         flexarray_vappend(dm_args, "-loadvm", info->saved_state, NULL);
@@ -237,6 +241,7 @@ static const char *qemu_disk_format_stri
 static char ** libxl__build_device_model_args_new(libxl__gc *gc,
                                                   const char *dm,
                                                   libxl_device_model_info *info,
+                                                  libxl_domain_build_info *b_info,
                                                   libxl_device_disk *disks, int num_disks,
                                                   libxl_device_nic *vifs, int num_vifs)
 {
@@ -409,6 +414,9 @@ static char ** libxl__build_device_model
         if (info->gfx_passthru) {
             flexarray_append(dm_args, "-gfx_passthru");
         }
+        if (b_info && b_info->u.hvm.iommu) {
+            flexarray_append(dm_args, "-iommu");
+        }
     }
     if (info->saved_state) {
         /* This file descriptor is meant to be used by QEMU */
@@ -500,6 +508,7 @@ static char ** libxl__build_device_model
 static char ** libxl__build_device_model_args(libxl__gc *gc,
                                               const char *dm,
                                               libxl_device_model_info *info,
+                                              libxl_domain_build_info *b_info,
                                               libxl_device_disk *disks, int num_disks,
                                               libxl_device_nic *vifs, int num_vifs)
 {
@@ -507,11 +516,11 @@ static char ** libxl__build_device_model
 
     switch (info->device_model_version) {
     case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL:
-        return libxl__build_device_model_args_old(gc, dm, info,
+        return libxl__build_device_model_args_old(gc, dm, info, b_info,
                                                   disks, num_disks,
                                                   vifs, num_vifs);
     case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
-        return libxl__build_device_model_args_new(gc, dm, info,
+        return libxl__build_device_model_args_new(gc, dm, info, b_info,
                                                   disks, num_disks,
                                                   vifs, num_vifs);
     default:
@@ -619,7 +628,7 @@ static int libxl__create_stubdom(libxl__
         goto out;
     }
 
-    args = libxl__build_device_model_args(gc, "stubdom-dm", info,
+    args = libxl__build_device_model_args(gc, "stubdom-dm", info, NULL,
                                           disks, num_disks,
                                           vifs, num_vifs);
     if (!args) {
@@ -782,6 +791,7 @@ out:
 
 int libxl__create_device_model(libxl__gc *gc,
                               libxl_device_model_info *info,
+                              libxl_domain_build_info *b_info,
                               libxl_device_disk *disks, int num_disks,
                               libxl_device_nic *vifs, int num_vifs,
                               libxl__spawner_starting **starting_r)
@@ -820,7 +830,7 @@ int libxl__create_device_model(libxl__gc
         rc = ERROR_FAIL;
         goto out;
     }
-    args = libxl__build_device_model_args(gc, dm, info, disks, num_disks,
+    args = libxl__build_device_model_args(gc, dm, info, b_info, disks, num_disks,
                                           vifs, num_vifs);
     if (!args) {
         rc = ERROR_FAIL;
@@ -1046,7 +1056,7 @@ int libxl__create_xenpv_qemu(libxl__gc *
                              libxl__spawner_starting **starting_r)
 {
     libxl__build_xenpv_qemu_args(gc, domid, vfb, info);
-    libxl__create_device_model(gc, info, NULL, 0, NULL, 0, starting_r);
+    libxl__create_device_model(gc, info, NULL, NULL, 0, NULL, 0, starting_r);
     return 0;
 }
 
diff -r 8ea73cd1a367 -r 1aad01930517 tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Thu Dec 22 16:56:59 2011 +0100
+++ b/tools/libxl/libxl_internal.h	Thu Dec 22 16:57:02 2011 +0100
@@ -466,6 +466,7 @@ _hidden const char *libxl__domain_device
                                                libxl_device_model_info *info);
 _hidden int libxl__create_device_model(libxl__gc *gc,
                               libxl_device_model_info *info,
+                              libxl_domain_build_info *b_info,
                               libxl_device_disk *disk, int num_disks,
                               libxl_device_nic *vifs, int num_vifs,
                               libxl__spawner_starting **starting_r);


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 23 11:31:53 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 Dec 2011 11:31:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Re3LW-0001BE-Mo; Fri, 23 Dec 2011 11:31:30 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Wang2@amd.com>) id 1Re3LV-00018R-Bb
	for xen-devel@lists.xensource.com; Fri, 23 Dec 2011 11:31:29 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1324639882!6689038!1
X-Originating-IP: [213.199.154.141]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13444 invoked from network); 23 Dec 2011 11:31:23 -0000
Received: from db3ehsobe003.messaging.microsoft.com (HELO
	DB3EHSOBE003.bigfish.com) (213.199.154.141)
	by server-9.tower-174.messagelabs.com with AES128-SHA encrypted SMTP;
	23 Dec 2011 11:31:23 -0000
Received: from mail47-db3-R.bigfish.com (10.3.81.242) by
	DB3EHSOBE003.bigfish.com (10.3.84.23) with Microsoft SMTP Server id
	14.1.225.23; Fri, 23 Dec 2011 11:31:10 +0000
Received: from mail47-db3 (localhost [127.0.0.1])	by mail47-db3-R.bigfish.com
	(Postfix) with ESMTP id A3C6E240131;
	Fri, 23 Dec 2011 11:31:50 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzzz1202hzz8275bhz2dh668h839h944h)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
X-FB-SS: 13,
Received: from mail47-db3 (localhost.localdomain [127.0.0.1]) by mail47-db3
	(MessageSwitch) id 1324639909407705_32086;
	Fri, 23 Dec 2011 11:31:49 +0000 (UTC)
Received: from DB3EHSMHS008.bigfish.com (unknown [10.3.81.245])	by
	mail47-db3.bigfish.com (Postfix) with ESMTP id 5C4904E004C;
	Fri, 23 Dec 2011 11:31:49 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	DB3EHSMHS008.bigfish.com (10.3.87.108) with Microsoft SMTP Server id
	14.1.225.23; Fri, 23 Dec 2011 11:31:07 +0000
X-WSS-ID: 0LWNMO5-02-0XE-02
X-M-MSG: 
Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com
	[163.181.249.73])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp02.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2F862C80D4;	Fri, 23 Dec 2011 05:31:16 -0600 (CST)
Received: from SAUSEXDAG02.amd.com (163.181.55.2) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Fri, 23 Dec 2011 05:31:35 -0600
Received: from storexhtp02.amd.com (172.24.4.4) by sausexdag02.amd.com
	(163.181.55.2) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Fri, 23 Dec 2011 05:31:17 -0600
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Fri, 23 Dec 2011
	06:30:44 -0500
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 1F59649C65F; Fri, 23 Dec 2011
	11:30:43 +0000 (GMT)
Received: from gran.amd.com (gran.osrc.amd.com [165.204.15.57])	by
	mail.osrc.amd.com (Postfix) with ESMTP id 13521594886; Fri, 23 Dec 2011
	12:30:43 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 1aad019305172c4abca8c2c9d7e632fe3291fead
Message-ID: <1aad019305172c4abca8.1324639765@gran.amd.com>
In-Reply-To: <patchbomb.1324639749@gran.amd.com>
References: <patchbomb.1324639749@gran.amd.com>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Fri, 23 Dec 2011 12:29:25 +0100
From: Wei Wang <wei.wang2@amd.com>
To: <JBeulich@suse.com>, <Ian.Jackson@eu.citrix.com>,
	<Ian.Campbell@citrix.com>, <keir@xen.org>
X-OriginatorOrg: amd.com
Cc: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 16 of 16] libxl: pass iommu parameter to qemu-dm
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Wei Wang <wei.wang2@amd.com>
# Date 1324569422 -3600
# Node ID 1aad019305172c4abca8c2c9d7e632fe3291fead
# Parent  8ea73cd1a367b318f72026a02629c774d24f999f
libxl: pass iommu parameter to qemu-dm.
When iomm = 0, virtual iommu device will be disabled.

Signed-off-by: Wei Wang <wei.wang2@amd.com>

diff -r 8ea73cd1a367 -r 1aad01930517 tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Thu Dec 22 16:56:59 2011 +0100
+++ b/tools/libxl/libxl_create.c	Thu Dec 22 16:57:02 2011 +0100
@@ -559,7 +559,7 @@ static int do_domain_create(libxl__gc *g
         libxl_device_vkb_dispose(&vkb);
 
         dm_info->domid = domid;
-        ret = libxl__create_device_model(gc, dm_info,
+        ret = libxl__create_device_model(gc, dm_info, &d_config->b_info,
                                         d_config->disks, d_config->num_disks,
                                         d_config->vifs, d_config->num_vifs,
                                         &dm_starting);
diff -r 8ea73cd1a367 -r 1aad01930517 tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Thu Dec 22 16:56:59 2011 +0100
+++ b/tools/libxl/libxl_dm.c	Thu Dec 22 16:57:02 2011 +0100
@@ -84,6 +84,7 @@ static const char *libxl__domain_bios(li
 static char ** libxl__build_device_model_args_old(libxl__gc *gc,
                                                   const char *dm,
                                                   libxl_device_model_info *info,
+                                                  libxl_domain_build_info *b_info,
                                                   libxl_device_disk *disks, int num_disks,
                                                   libxl_device_nic *vifs, int num_vifs)
 {
@@ -199,6 +200,9 @@ static char ** libxl__build_device_model
         if (info->gfx_passthru) {
             flexarray_append(dm_args, "-gfx_passthru");
         }
+        if (b_info && b_info->u.hvm.iommu) {
+            flexarray_append(dm_args, "-iommu");
+        }
     }
     if (info->saved_state) {
         flexarray_vappend(dm_args, "-loadvm", info->saved_state, NULL);
@@ -237,6 +241,7 @@ static const char *qemu_disk_format_stri
 static char ** libxl__build_device_model_args_new(libxl__gc *gc,
                                                   const char *dm,
                                                   libxl_device_model_info *info,
+                                                  libxl_domain_build_info *b_info,
                                                   libxl_device_disk *disks, int num_disks,
                                                   libxl_device_nic *vifs, int num_vifs)
 {
@@ -409,6 +414,9 @@ static char ** libxl__build_device_model
         if (info->gfx_passthru) {
             flexarray_append(dm_args, "-gfx_passthru");
         }
+        if (b_info && b_info->u.hvm.iommu) {
+            flexarray_append(dm_args, "-iommu");
+        }
     }
     if (info->saved_state) {
         /* This file descriptor is meant to be used by QEMU */
@@ -500,6 +508,7 @@ static char ** libxl__build_device_model
 static char ** libxl__build_device_model_args(libxl__gc *gc,
                                               const char *dm,
                                               libxl_device_model_info *info,
+                                              libxl_domain_build_info *b_info,
                                               libxl_device_disk *disks, int num_disks,
                                               libxl_device_nic *vifs, int num_vifs)
 {
@@ -507,11 +516,11 @@ static char ** libxl__build_device_model
 
     switch (info->device_model_version) {
     case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL:
-        return libxl__build_device_model_args_old(gc, dm, info,
+        return libxl__build_device_model_args_old(gc, dm, info, b_info,
                                                   disks, num_disks,
                                                   vifs, num_vifs);
     case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
-        return libxl__build_device_model_args_new(gc, dm, info,
+        return libxl__build_device_model_args_new(gc, dm, info, b_info,
                                                   disks, num_disks,
                                                   vifs, num_vifs);
     default:
@@ -619,7 +628,7 @@ static int libxl__create_stubdom(libxl__
         goto out;
     }
 
-    args = libxl__build_device_model_args(gc, "stubdom-dm", info,
+    args = libxl__build_device_model_args(gc, "stubdom-dm", info, NULL,
                                           disks, num_disks,
                                           vifs, num_vifs);
     if (!args) {
@@ -782,6 +791,7 @@ out:
 
 int libxl__create_device_model(libxl__gc *gc,
                               libxl_device_model_info *info,
+                              libxl_domain_build_info *b_info,
                               libxl_device_disk *disks, int num_disks,
                               libxl_device_nic *vifs, int num_vifs,
                               libxl__spawner_starting **starting_r)
@@ -820,7 +830,7 @@ int libxl__create_device_model(libxl__gc
         rc = ERROR_FAIL;
         goto out;
     }
-    args = libxl__build_device_model_args(gc, dm, info, disks, num_disks,
+    args = libxl__build_device_model_args(gc, dm, info, b_info, disks, num_disks,
                                           vifs, num_vifs);
     if (!args) {
         rc = ERROR_FAIL;
@@ -1046,7 +1056,7 @@ int libxl__create_xenpv_qemu(libxl__gc *
                              libxl__spawner_starting **starting_r)
 {
     libxl__build_xenpv_qemu_args(gc, domid, vfb, info);
-    libxl__create_device_model(gc, info, NULL, 0, NULL, 0, starting_r);
+    libxl__create_device_model(gc, info, NULL, NULL, 0, NULL, 0, starting_r);
     return 0;
 }
 
diff -r 8ea73cd1a367 -r 1aad01930517 tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Thu Dec 22 16:56:59 2011 +0100
+++ b/tools/libxl/libxl_internal.h	Thu Dec 22 16:57:02 2011 +0100
@@ -466,6 +466,7 @@ _hidden const char *libxl__domain_device
                                                libxl_device_model_info *info);
 _hidden int libxl__create_device_model(libxl__gc *gc,
                               libxl_device_model_info *info,
+                              libxl_domain_build_info *b_info,
                               libxl_device_disk *disk, int num_disks,
                               libxl_device_nic *vifs, int num_vifs,
                               libxl__spawner_starting **starting_r);


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 23 11:31:54 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 Dec 2011 11:31:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Re3LV-0001AJ-OB; Fri, 23 Dec 2011 11:31:29 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Wang2@amd.com>) id 1Re3LT-00018H-HP
	for xen-devel@lists.xensource.com; Fri, 23 Dec 2011 11:31:27 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1324639879!9317652!2
X-Originating-IP: [216.32.181.181]
X-SpamReason: No, hits=0.0 required=7.0 tests=UPPERCASE_25_50
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16562 invoked from network); 23 Dec 2011 11:31:20 -0000
Received: from ch1ehsobe001.messaging.microsoft.com (HELO
	ch1outboundpool.messaging.microsoft.com) (216.32.181.181)
	by server-8.tower-21.messagelabs.com with AES128-SHA encrypted SMTP;
	23 Dec 2011 11:31:20 -0000
Received: from mail104-ch1-R.bigfish.com (10.43.68.242) by
	CH1EHSOBE002.bigfish.com (10.43.70.52) with Microsoft SMTP Server id
	14.1.225.23; Fri, 23 Dec 2011 11:31:06 +0000
Received: from mail104-ch1 (localhost [127.0.0.1])	by
	mail104-ch1-R.bigfish.com (Postfix) with ESMTP id 184AA4C03A6;
	Fri, 23 Dec 2011 11:31:46 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzzz1202hzz8275bhz2dh668h839h944h)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
X-FB-SS: 13,
Received: from mail104-ch1 (localhost.localdomain [127.0.0.1]) by mail104-ch1
	(MessageSwitch) id 1324639905812152_5085;
	Fri, 23 Dec 2011 11:31:45 +0000 (UTC)
Received: from CH1EHSMHS011.bigfish.com (snatpool1.int.messaging.microsoft.com
	[10.43.68.248])	by mail104-ch1.bigfish.com (Postfix) with ESMTP id
	C024C480044;	Fri, 23 Dec 2011 11:31:45 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	CH1EHSMHS011.bigfish.com (10.43.70.11) with Microsoft SMTP Server id
	14.1.225.23; Fri, 23 Dec 2011 11:31:06 +0000
X-WSS-ID: 0LWNMO4-01-1GB-02
X-M-MSG: 
Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com
	[163.181.249.73])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2617C10280A0;	Fri, 23 Dec 2011 05:31:14 -0600 (CST)
Received: from SAUSEXDAG02.amd.com (163.181.55.2) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Fri, 23 Dec 2011 05:31:33 -0600
Received: from storexhtp01.amd.com (172.24.4.3) by sausexdag02.amd.com
	(163.181.55.2) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Fri, 23 Dec 2011 05:31:15 -0600
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp01.amd.com
	(172.24.4.3) with Microsoft SMTP Server id 8.3.213.0; Fri, 23 Dec 2011
	06:30:42 -0500
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 643AA49C65D; Fri, 23 Dec 2011
	11:30:41 +0000 (GMT)
Received: from gran.amd.com (gran.osrc.amd.com [165.204.15.57])	by
	mail.osrc.amd.com (Postfix) with ESMTP id 508A8594883; Fri, 23 Dec 2011
	12:30:41 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: e15194f68f99a64b65046ba3d29a3f06ccdca950
Message-ID: <e15194f68f99a64b6504.1324639751@gran.amd.com>
In-Reply-To: <patchbomb.1324639749@gran.amd.com>
References: <patchbomb.1324639749@gran.amd.com>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Fri, 23 Dec 2011 12:29:11 +0100
From: Wei Wang <wei.wang2@amd.com>
To: <JBeulich@suse.com>, <Ian.Jackson@eu.citrix.com>,
	<Ian.Campbell@citrix.com>, <keir@xen.org>
X-OriginatorOrg: amd.com
Cc: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 02 of 16] amd iommu: Introduces new helper
 functions to simplify iommu bitwise operations
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Wei Wang <wei.wang2@amd.com>
# Date 1324569374 -3600
# Node ID e15194f68f99a64b65046ba3d29a3f06ccdca950
# Parent  4c986253976d7efd19640500aa3bb69a5a534637
amd iommu: Introduces new helper functions to simplify iommu bitwise operations

Signed-off-by: Wei Wang <wei.wang2@amd.com>

diff -r 4c986253976d -r e15194f68f99 xen/drivers/passthrough/amd/iommu_cmd.c
--- a/xen/drivers/passthrough/amd/iommu_cmd.c	Thu Dec 22 16:56:10 2011 +0100
+++ b/xen/drivers/passthrough/amd/iommu_cmd.c	Thu Dec 22 16:56:14 2011 +0100
@@ -33,10 +33,8 @@ static int queue_iommu_command(struct am
     if ( ++tail == iommu->cmd_buffer.entries )
         tail = 0;
 
-    head = get_field_from_reg_u32(readl(iommu->mmio_base + 
-                                        IOMMU_CMD_BUFFER_HEAD_OFFSET),
-                                  IOMMU_CMD_BUFFER_HEAD_MASK,
-                                  IOMMU_CMD_BUFFER_HEAD_SHIFT);
+    head = iommu_get_rb_pointer(readl(iommu->mmio_base + 
+                                      IOMMU_CMD_BUFFER_HEAD_OFFSET));
     if ( head != tail )
     {
         cmd_buffer = (u32 *)(iommu->cmd_buffer.buffer +
@@ -55,11 +53,9 @@ static int queue_iommu_command(struct am
 
 static void commit_iommu_command_buffer(struct amd_iommu *iommu)
 {
-    u32 tail;
+    u32 tail = 0;
 
-    set_field_in_reg_u32(iommu->cmd_buffer.tail, 0,
-                         IOMMU_CMD_BUFFER_TAIL_MASK,
-                         IOMMU_CMD_BUFFER_TAIL_SHIFT, &tail);
+    iommu_set_rb_pointer(&tail, iommu->cmd_buffer.tail);
     writel(tail, iommu->mmio_base+IOMMU_CMD_BUFFER_TAIL_OFFSET);
 }
 
diff -r 4c986253976d -r e15194f68f99 xen/drivers/passthrough/amd/iommu_init.c
--- a/xen/drivers/passthrough/amd/iommu_init.c	Thu Dec 22 16:56:10 2011 +0100
+++ b/xen/drivers/passthrough/amd/iommu_init.c	Thu Dec 22 16:56:14 2011 +0100
@@ -106,21 +106,21 @@ static void register_iommu_dev_table_in_
     u64 addr_64, addr_lo, addr_hi;
     u32 entry;
 
+    ASSERT( iommu->dev_table.buffer );
+
     addr_64 = (u64)virt_to_maddr(iommu->dev_table.buffer);
     addr_lo = addr_64 & DMA_32BIT_MASK;
     addr_hi = addr_64 >> 32;
 
-    set_field_in_reg_u32((u32)addr_lo >> PAGE_SHIFT, 0,
-                         IOMMU_DEV_TABLE_BASE_LOW_MASK,
-                         IOMMU_DEV_TABLE_BASE_LOW_SHIFT, &entry);
+    entry = 0;
+    iommu_set_addr_lo_to_reg(&entry, addr_lo >> PAGE_SHIFT);
     set_field_in_reg_u32((iommu->dev_table.alloc_size / PAGE_SIZE) - 1,
                          entry, IOMMU_DEV_TABLE_SIZE_MASK,
                          IOMMU_DEV_TABLE_SIZE_SHIFT, &entry);
     writel(entry, iommu->mmio_base + IOMMU_DEV_TABLE_BASE_LOW_OFFSET);
 
-    set_field_in_reg_u32((u32)addr_hi, 0,
-                         IOMMU_DEV_TABLE_BASE_HIGH_MASK,
-                         IOMMU_DEV_TABLE_BASE_HIGH_SHIFT, &entry);
+    entry = 0;
+    iommu_set_addr_hi_to_reg(&entry, addr_hi);
     writel(entry, iommu->mmio_base + IOMMU_DEV_TABLE_BASE_HIGH_OFFSET);
 }
 
@@ -130,21 +130,21 @@ static void register_iommu_cmd_buffer_in
     u32 power_of2_entries;
     u32 entry;
 
+    ASSERT( iommu->dev_table.buffer );
+
     addr_64 = (u64)virt_to_maddr(iommu->cmd_buffer.buffer);
     addr_lo = addr_64 & DMA_32BIT_MASK;
     addr_hi = addr_64 >> 32;
 
-    set_field_in_reg_u32((u32)addr_lo >> PAGE_SHIFT, 0,
-                         IOMMU_CMD_BUFFER_BASE_LOW_MASK,
-                         IOMMU_CMD_BUFFER_BASE_LOW_SHIFT, &entry);
+    entry = 0;
+    iommu_set_addr_lo_to_reg(&entry, addr_lo >> PAGE_SHIFT);
     writel(entry, iommu->mmio_base + IOMMU_CMD_BUFFER_BASE_LOW_OFFSET);
 
     power_of2_entries = get_order_from_bytes(iommu->cmd_buffer.alloc_size) +
         IOMMU_CMD_BUFFER_POWER_OF2_ENTRIES_PER_PAGE;
 
-    set_field_in_reg_u32((u32)addr_hi, 0,
-                         IOMMU_CMD_BUFFER_BASE_HIGH_MASK,
-                         IOMMU_CMD_BUFFER_BASE_HIGH_SHIFT, &entry);
+    entry = 0;
+    iommu_set_addr_hi_to_reg(&entry, addr_hi);
     set_field_in_reg_u32(power_of2_entries, entry,
                          IOMMU_CMD_BUFFER_LENGTH_MASK,
                          IOMMU_CMD_BUFFER_LENGTH_SHIFT, &entry);
@@ -157,21 +157,21 @@ static void register_iommu_event_log_in_
     u32 power_of2_entries;
     u32 entry;
 
+    ASSERT( iommu->dev_table.buffer );
+
     addr_64 = (u64)virt_to_maddr(iommu->event_log.buffer);
     addr_lo = addr_64 & DMA_32BIT_MASK;
     addr_hi = addr_64 >> 32;
 
-    set_field_in_reg_u32((u32)addr_lo >> PAGE_SHIFT, 0,
-                         IOMMU_EVENT_LOG_BASE_LOW_MASK,
-                         IOMMU_EVENT_LOG_BASE_LOW_SHIFT, &entry);
+    entry = 0;
+    iommu_set_addr_lo_to_reg(&entry, addr_lo >> PAGE_SHIFT);
     writel(entry, iommu->mmio_base + IOMMU_EVENT_LOG_BASE_LOW_OFFSET);
 
     power_of2_entries = get_order_from_bytes(iommu->event_log.alloc_size) +
                         IOMMU_EVENT_LOG_POWER_OF2_ENTRIES_PER_PAGE;
 
-    set_field_in_reg_u32((u32)addr_hi, 0,
-                        IOMMU_EVENT_LOG_BASE_HIGH_MASK,
-                        IOMMU_EVENT_LOG_BASE_HIGH_SHIFT, &entry);
+    entry = 0;
+    iommu_set_addr_hi_to_reg(&entry, addr_hi);
     set_field_in_reg_u32(power_of2_entries, entry,
                         IOMMU_EVENT_LOG_LENGTH_MASK,
                         IOMMU_EVENT_LOG_LENGTH_SHIFT, &entry);
@@ -234,14 +234,12 @@ static void register_iommu_exclusion_ran
     addr_lo = iommu->exclusion_base & DMA_32BIT_MASK;
     addr_hi = iommu->exclusion_base >> 32;
 
-    set_field_in_reg_u32((u32)addr_hi, 0,
-                         IOMMU_EXCLUSION_BASE_HIGH_MASK,
-                         IOMMU_EXCLUSION_BASE_HIGH_SHIFT, &entry);
+    entry = 0;
+    iommu_set_addr_hi_to_reg(&entry, addr_hi);
     writel(entry, iommu->mmio_base+IOMMU_EXCLUSION_BASE_HIGH_OFFSET);
 
-    set_field_in_reg_u32((u32)addr_lo >> PAGE_SHIFT, 0,
-                         IOMMU_EXCLUSION_BASE_LOW_MASK,
-                         IOMMU_EXCLUSION_BASE_LOW_SHIFT, &entry);
+    entry = 0;
+    iommu_set_addr_lo_to_reg(&entry, addr_lo >> PAGE_SHIFT);
 
     set_field_in_reg_u32(iommu->exclusion_allow_all, entry,
                          IOMMU_EXCLUSION_ALLOW_ALL_MASK,
@@ -490,9 +488,7 @@ static void parse_event_log_entry(struct
 
     if ( code == IOMMU_EVENT_IO_PAGE_FAULT )
     {
-        device_id = get_field_from_reg_u32(entry[0],
-                                           IOMMU_EVENT_DEVICE_ID_MASK,
-                                           IOMMU_EVENT_DEVICE_ID_SHIFT);
+        device_id = iommu_get_devid_from_event(entry[0]);
         domain_id = get_field_from_reg_u32(entry[1],
                                            IOMMU_EVENT_DOMAIN_ID_MASK,
                                            IOMMU_EVENT_DOMAIN_ID_SHIFT);
diff -r 4c986253976d -r e15194f68f99 xen/include/asm-x86/hvm/svm/amd-iommu-proto.h
--- a/xen/include/asm-x86/hvm/svm/amd-iommu-proto.h	Thu Dec 22 16:56:10 2011 +0100
+++ b/xen/include/asm-x86/hvm/svm/amd-iommu-proto.h	Thu Dec 22 16:56:14 2011 +0100
@@ -191,5 +191,85 @@ static inline int iommu_has_feature(stru
         return 0;
     return !!(iommu->features & (1U << bit));
 }
+/* access tail or head pointer of ring buffer */
+#define IOMMU_RING_BUFFER_PTR_MASK                         0x0007FFF0
+#define IOMMU_RING_BUFFER_PTR_SHIFT                        4
+static inline uint32_t iommu_get_rb_pointer(uint32_t reg)
+{
+    return get_field_from_reg_u32(reg, IOMMU_RING_BUFFER_PTR_MASK, 
+                                  IOMMU_RING_BUFFER_PTR_SHIFT);
+}
+
+static inline void iommu_set_rb_pointer(uint32_t *reg, uint32_t val)
+{
+    set_field_in_reg_u32(val, *reg, IOMMU_RING_BUFFER_PTR_MASK, 
+                         IOMMU_RING_BUFFER_PTR_SHIFT, reg);
+}
+
+/* access device field from iommu cmd */
+#define IOMMU_CMD_DEVICE_ID_MASK           0x0000FFFF
+#define IOMMU_CMD_DEVICE_ID_SHIFT          0
+
+static inline uint16_t iommu_get_devid_from_cmd(uint32_t cmd)
+{
+    return get_field_from_reg_u32(cmd, IOMMU_CMD_DEVICE_ID_MASK, 
+                                  IOMMU_CMD_DEVICE_ID_SHIFT);
+}
+
+static inline void iommu_set_devid_to_cmd(uint32_t *cmd, uint16_t id)
+{
+    set_field_in_reg_u32(id, *cmd, IOMMU_CMD_DEVICE_ID_MASK, 
+                         IOMMU_CMD_DEVICE_ID_SHIFT, cmd);
+}
+
+/* access address field from iommu cmd */
+#define IOMMU_CMD_ADDR_LOW_MASK 0xFFFFF000
+#define IOMMU_CMD_ADDR_LOW_SHIFT    12
+#define IOMMU_CMD_ADDR_HIGH_MASK    0xFFFFFFFF
+#define IOMMU_CMD_ADDR_HIGH_SHIFT   0
+
+static inline uint32_t iommu_get_addr_lo_from_cmd(uint32_t cmd)
+{
+    return get_field_from_reg_u32(cmd, IOMMU_CMD_ADDR_LOW_MASK, 
+                                  IOMMU_CMD_ADDR_LOW_SHIFT);
+}
+
+static inline uint32_t iommu_get_addr_hi_from_cmd(uint32_t cmd)
+{
+    return get_field_from_reg_u32(cmd, IOMMU_CMD_ADDR_LOW_MASK, 
+                                  IOMMU_CMD_ADDR_HIGH_SHIFT);
+}
+
+#define iommu_get_devid_from_event          iommu_get_devid_from_cmd
+
+/* access iommu base addresses from mmio regs */
+#define IOMMU_REG_BASE_ADDR_BASE_LOW_MASK         0xFFFFF000
+#define IOMMU_REG_BASE_ADDR_LOW_SHIFT             12
+#define IOMMU_REG_BASE_ADDR_HIGH_MASK             0x000FFFFF
+#define IOMMU_REG_BASE_ADDR_HIGH_SHIFT            0
+
+static inline void iommu_set_addr_lo_to_reg(uint32_t *reg, uint32_t addr)
+{
+    set_field_in_reg_u32(addr, *reg, IOMMU_REG_BASE_ADDR_BASE_LOW_MASK, 
+                         IOMMU_REG_BASE_ADDR_LOW_SHIFT, reg);
+}
+
+static inline void iommu_set_addr_hi_to_reg(uint32_t *reg, uint32_t addr)
+{
+    set_field_in_reg_u32(addr, *reg, IOMMU_REG_BASE_ADDR_HIGH_MASK, 
+                         IOMMU_REG_BASE_ADDR_HIGH_SHIFT, reg);
+}
+
+static inline uint32_t iommu_get_addr_lo_from_reg(uint32_t reg)
+{
+    return get_field_from_reg_u32(reg, IOMMU_REG_BASE_ADDR_BASE_LOW_MASK, 
+                                  IOMMU_REG_BASE_ADDR_LOW_SHIFT);
+}
+
+static inline uint32_t iommu_get_addr_hi_from_reg(uint32_t reg)
+{
+    return get_field_from_reg_u32(reg, IOMMU_REG_BASE_ADDR_HIGH_MASK, 
+                                  IOMMU_REG_BASE_ADDR_HIGH_SHIFT);
+}
 
 #endif /* _ASM_X86_64_AMD_IOMMU_PROTO_H */


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 23 11:31:54 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 Dec 2011 11:31:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Re3LV-0001AJ-OB; Fri, 23 Dec 2011 11:31:29 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Wang2@amd.com>) id 1Re3LT-00018H-HP
	for xen-devel@lists.xensource.com; Fri, 23 Dec 2011 11:31:27 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1324639879!9317652!2
X-Originating-IP: [216.32.181.181]
X-SpamReason: No, hits=0.0 required=7.0 tests=UPPERCASE_25_50
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16562 invoked from network); 23 Dec 2011 11:31:20 -0000
Received: from ch1ehsobe001.messaging.microsoft.com (HELO
	ch1outboundpool.messaging.microsoft.com) (216.32.181.181)
	by server-8.tower-21.messagelabs.com with AES128-SHA encrypted SMTP;
	23 Dec 2011 11:31:20 -0000
Received: from mail104-ch1-R.bigfish.com (10.43.68.242) by
	CH1EHSOBE002.bigfish.com (10.43.70.52) with Microsoft SMTP Server id
	14.1.225.23; Fri, 23 Dec 2011 11:31:06 +0000
Received: from mail104-ch1 (localhost [127.0.0.1])	by
	mail104-ch1-R.bigfish.com (Postfix) with ESMTP id 184AA4C03A6;
	Fri, 23 Dec 2011 11:31:46 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzzz1202hzz8275bhz2dh668h839h944h)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
X-FB-SS: 13,
Received: from mail104-ch1 (localhost.localdomain [127.0.0.1]) by mail104-ch1
	(MessageSwitch) id 1324639905812152_5085;
	Fri, 23 Dec 2011 11:31:45 +0000 (UTC)
Received: from CH1EHSMHS011.bigfish.com (snatpool1.int.messaging.microsoft.com
	[10.43.68.248])	by mail104-ch1.bigfish.com (Postfix) with ESMTP id
	C024C480044;	Fri, 23 Dec 2011 11:31:45 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	CH1EHSMHS011.bigfish.com (10.43.70.11) with Microsoft SMTP Server id
	14.1.225.23; Fri, 23 Dec 2011 11:31:06 +0000
X-WSS-ID: 0LWNMO4-01-1GB-02
X-M-MSG: 
Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com
	[163.181.249.73])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2617C10280A0;	Fri, 23 Dec 2011 05:31:14 -0600 (CST)
Received: from SAUSEXDAG02.amd.com (163.181.55.2) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Fri, 23 Dec 2011 05:31:33 -0600
Received: from storexhtp01.amd.com (172.24.4.3) by sausexdag02.amd.com
	(163.181.55.2) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Fri, 23 Dec 2011 05:31:15 -0600
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp01.amd.com
	(172.24.4.3) with Microsoft SMTP Server id 8.3.213.0; Fri, 23 Dec 2011
	06:30:42 -0500
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 643AA49C65D; Fri, 23 Dec 2011
	11:30:41 +0000 (GMT)
Received: from gran.amd.com (gran.osrc.amd.com [165.204.15.57])	by
	mail.osrc.amd.com (Postfix) with ESMTP id 508A8594883; Fri, 23 Dec 2011
	12:30:41 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: e15194f68f99a64b65046ba3d29a3f06ccdca950
Message-ID: <e15194f68f99a64b6504.1324639751@gran.amd.com>
In-Reply-To: <patchbomb.1324639749@gran.amd.com>
References: <patchbomb.1324639749@gran.amd.com>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Fri, 23 Dec 2011 12:29:11 +0100
From: Wei Wang <wei.wang2@amd.com>
To: <JBeulich@suse.com>, <Ian.Jackson@eu.citrix.com>,
	<Ian.Campbell@citrix.com>, <keir@xen.org>
X-OriginatorOrg: amd.com
Cc: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 02 of 16] amd iommu: Introduces new helper
 functions to simplify iommu bitwise operations
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Wei Wang <wei.wang2@amd.com>
# Date 1324569374 -3600
# Node ID e15194f68f99a64b65046ba3d29a3f06ccdca950
# Parent  4c986253976d7efd19640500aa3bb69a5a534637
amd iommu: Introduces new helper functions to simplify iommu bitwise operations

Signed-off-by: Wei Wang <wei.wang2@amd.com>

diff -r 4c986253976d -r e15194f68f99 xen/drivers/passthrough/amd/iommu_cmd.c
--- a/xen/drivers/passthrough/amd/iommu_cmd.c	Thu Dec 22 16:56:10 2011 +0100
+++ b/xen/drivers/passthrough/amd/iommu_cmd.c	Thu Dec 22 16:56:14 2011 +0100
@@ -33,10 +33,8 @@ static int queue_iommu_command(struct am
     if ( ++tail == iommu->cmd_buffer.entries )
         tail = 0;
 
-    head = get_field_from_reg_u32(readl(iommu->mmio_base + 
-                                        IOMMU_CMD_BUFFER_HEAD_OFFSET),
-                                  IOMMU_CMD_BUFFER_HEAD_MASK,
-                                  IOMMU_CMD_BUFFER_HEAD_SHIFT);
+    head = iommu_get_rb_pointer(readl(iommu->mmio_base + 
+                                      IOMMU_CMD_BUFFER_HEAD_OFFSET));
     if ( head != tail )
     {
         cmd_buffer = (u32 *)(iommu->cmd_buffer.buffer +
@@ -55,11 +53,9 @@ static int queue_iommu_command(struct am
 
 static void commit_iommu_command_buffer(struct amd_iommu *iommu)
 {
-    u32 tail;
+    u32 tail = 0;
 
-    set_field_in_reg_u32(iommu->cmd_buffer.tail, 0,
-                         IOMMU_CMD_BUFFER_TAIL_MASK,
-                         IOMMU_CMD_BUFFER_TAIL_SHIFT, &tail);
+    iommu_set_rb_pointer(&tail, iommu->cmd_buffer.tail);
     writel(tail, iommu->mmio_base+IOMMU_CMD_BUFFER_TAIL_OFFSET);
 }
 
diff -r 4c986253976d -r e15194f68f99 xen/drivers/passthrough/amd/iommu_init.c
--- a/xen/drivers/passthrough/amd/iommu_init.c	Thu Dec 22 16:56:10 2011 +0100
+++ b/xen/drivers/passthrough/amd/iommu_init.c	Thu Dec 22 16:56:14 2011 +0100
@@ -106,21 +106,21 @@ static void register_iommu_dev_table_in_
     u64 addr_64, addr_lo, addr_hi;
     u32 entry;
 
+    ASSERT( iommu->dev_table.buffer );
+
     addr_64 = (u64)virt_to_maddr(iommu->dev_table.buffer);
     addr_lo = addr_64 & DMA_32BIT_MASK;
     addr_hi = addr_64 >> 32;
 
-    set_field_in_reg_u32((u32)addr_lo >> PAGE_SHIFT, 0,
-                         IOMMU_DEV_TABLE_BASE_LOW_MASK,
-                         IOMMU_DEV_TABLE_BASE_LOW_SHIFT, &entry);
+    entry = 0;
+    iommu_set_addr_lo_to_reg(&entry, addr_lo >> PAGE_SHIFT);
     set_field_in_reg_u32((iommu->dev_table.alloc_size / PAGE_SIZE) - 1,
                          entry, IOMMU_DEV_TABLE_SIZE_MASK,
                          IOMMU_DEV_TABLE_SIZE_SHIFT, &entry);
     writel(entry, iommu->mmio_base + IOMMU_DEV_TABLE_BASE_LOW_OFFSET);
 
-    set_field_in_reg_u32((u32)addr_hi, 0,
-                         IOMMU_DEV_TABLE_BASE_HIGH_MASK,
-                         IOMMU_DEV_TABLE_BASE_HIGH_SHIFT, &entry);
+    entry = 0;
+    iommu_set_addr_hi_to_reg(&entry, addr_hi);
     writel(entry, iommu->mmio_base + IOMMU_DEV_TABLE_BASE_HIGH_OFFSET);
 }
 
@@ -130,21 +130,21 @@ static void register_iommu_cmd_buffer_in
     u32 power_of2_entries;
     u32 entry;
 
+    ASSERT( iommu->dev_table.buffer );
+
     addr_64 = (u64)virt_to_maddr(iommu->cmd_buffer.buffer);
     addr_lo = addr_64 & DMA_32BIT_MASK;
     addr_hi = addr_64 >> 32;
 
-    set_field_in_reg_u32((u32)addr_lo >> PAGE_SHIFT, 0,
-                         IOMMU_CMD_BUFFER_BASE_LOW_MASK,
-                         IOMMU_CMD_BUFFER_BASE_LOW_SHIFT, &entry);
+    entry = 0;
+    iommu_set_addr_lo_to_reg(&entry, addr_lo >> PAGE_SHIFT);
     writel(entry, iommu->mmio_base + IOMMU_CMD_BUFFER_BASE_LOW_OFFSET);
 
     power_of2_entries = get_order_from_bytes(iommu->cmd_buffer.alloc_size) +
         IOMMU_CMD_BUFFER_POWER_OF2_ENTRIES_PER_PAGE;
 
-    set_field_in_reg_u32((u32)addr_hi, 0,
-                         IOMMU_CMD_BUFFER_BASE_HIGH_MASK,
-                         IOMMU_CMD_BUFFER_BASE_HIGH_SHIFT, &entry);
+    entry = 0;
+    iommu_set_addr_hi_to_reg(&entry, addr_hi);
     set_field_in_reg_u32(power_of2_entries, entry,
                          IOMMU_CMD_BUFFER_LENGTH_MASK,
                          IOMMU_CMD_BUFFER_LENGTH_SHIFT, &entry);
@@ -157,21 +157,21 @@ static void register_iommu_event_log_in_
     u32 power_of2_entries;
     u32 entry;
 
+    ASSERT( iommu->dev_table.buffer );
+
     addr_64 = (u64)virt_to_maddr(iommu->event_log.buffer);
     addr_lo = addr_64 & DMA_32BIT_MASK;
     addr_hi = addr_64 >> 32;
 
-    set_field_in_reg_u32((u32)addr_lo >> PAGE_SHIFT, 0,
-                         IOMMU_EVENT_LOG_BASE_LOW_MASK,
-                         IOMMU_EVENT_LOG_BASE_LOW_SHIFT, &entry);
+    entry = 0;
+    iommu_set_addr_lo_to_reg(&entry, addr_lo >> PAGE_SHIFT);
     writel(entry, iommu->mmio_base + IOMMU_EVENT_LOG_BASE_LOW_OFFSET);
 
     power_of2_entries = get_order_from_bytes(iommu->event_log.alloc_size) +
                         IOMMU_EVENT_LOG_POWER_OF2_ENTRIES_PER_PAGE;
 
-    set_field_in_reg_u32((u32)addr_hi, 0,
-                        IOMMU_EVENT_LOG_BASE_HIGH_MASK,
-                        IOMMU_EVENT_LOG_BASE_HIGH_SHIFT, &entry);
+    entry = 0;
+    iommu_set_addr_hi_to_reg(&entry, addr_hi);
     set_field_in_reg_u32(power_of2_entries, entry,
                         IOMMU_EVENT_LOG_LENGTH_MASK,
                         IOMMU_EVENT_LOG_LENGTH_SHIFT, &entry);
@@ -234,14 +234,12 @@ static void register_iommu_exclusion_ran
     addr_lo = iommu->exclusion_base & DMA_32BIT_MASK;
     addr_hi = iommu->exclusion_base >> 32;
 
-    set_field_in_reg_u32((u32)addr_hi, 0,
-                         IOMMU_EXCLUSION_BASE_HIGH_MASK,
-                         IOMMU_EXCLUSION_BASE_HIGH_SHIFT, &entry);
+    entry = 0;
+    iommu_set_addr_hi_to_reg(&entry, addr_hi);
     writel(entry, iommu->mmio_base+IOMMU_EXCLUSION_BASE_HIGH_OFFSET);
 
-    set_field_in_reg_u32((u32)addr_lo >> PAGE_SHIFT, 0,
-                         IOMMU_EXCLUSION_BASE_LOW_MASK,
-                         IOMMU_EXCLUSION_BASE_LOW_SHIFT, &entry);
+    entry = 0;
+    iommu_set_addr_lo_to_reg(&entry, addr_lo >> PAGE_SHIFT);
 
     set_field_in_reg_u32(iommu->exclusion_allow_all, entry,
                          IOMMU_EXCLUSION_ALLOW_ALL_MASK,
@@ -490,9 +488,7 @@ static void parse_event_log_entry(struct
 
     if ( code == IOMMU_EVENT_IO_PAGE_FAULT )
     {
-        device_id = get_field_from_reg_u32(entry[0],
-                                           IOMMU_EVENT_DEVICE_ID_MASK,
-                                           IOMMU_EVENT_DEVICE_ID_SHIFT);
+        device_id = iommu_get_devid_from_event(entry[0]);
         domain_id = get_field_from_reg_u32(entry[1],
                                            IOMMU_EVENT_DOMAIN_ID_MASK,
                                            IOMMU_EVENT_DOMAIN_ID_SHIFT);
diff -r 4c986253976d -r e15194f68f99 xen/include/asm-x86/hvm/svm/amd-iommu-proto.h
--- a/xen/include/asm-x86/hvm/svm/amd-iommu-proto.h	Thu Dec 22 16:56:10 2011 +0100
+++ b/xen/include/asm-x86/hvm/svm/amd-iommu-proto.h	Thu Dec 22 16:56:14 2011 +0100
@@ -191,5 +191,85 @@ static inline int iommu_has_feature(stru
         return 0;
     return !!(iommu->features & (1U << bit));
 }
+/* access tail or head pointer of ring buffer */
+#define IOMMU_RING_BUFFER_PTR_MASK                         0x0007FFF0
+#define IOMMU_RING_BUFFER_PTR_SHIFT                        4
+static inline uint32_t iommu_get_rb_pointer(uint32_t reg)
+{
+    return get_field_from_reg_u32(reg, IOMMU_RING_BUFFER_PTR_MASK, 
+                                  IOMMU_RING_BUFFER_PTR_SHIFT);
+}
+
+static inline void iommu_set_rb_pointer(uint32_t *reg, uint32_t val)
+{
+    set_field_in_reg_u32(val, *reg, IOMMU_RING_BUFFER_PTR_MASK, 
+                         IOMMU_RING_BUFFER_PTR_SHIFT, reg);
+}
+
+/* access device field from iommu cmd */
+#define IOMMU_CMD_DEVICE_ID_MASK           0x0000FFFF
+#define IOMMU_CMD_DEVICE_ID_SHIFT          0
+
+static inline uint16_t iommu_get_devid_from_cmd(uint32_t cmd)
+{
+    return get_field_from_reg_u32(cmd, IOMMU_CMD_DEVICE_ID_MASK, 
+                                  IOMMU_CMD_DEVICE_ID_SHIFT);
+}
+
+static inline void iommu_set_devid_to_cmd(uint32_t *cmd, uint16_t id)
+{
+    set_field_in_reg_u32(id, *cmd, IOMMU_CMD_DEVICE_ID_MASK, 
+                         IOMMU_CMD_DEVICE_ID_SHIFT, cmd);
+}
+
+/* access address field from iommu cmd */
+#define IOMMU_CMD_ADDR_LOW_MASK 0xFFFFF000
+#define IOMMU_CMD_ADDR_LOW_SHIFT    12
+#define IOMMU_CMD_ADDR_HIGH_MASK    0xFFFFFFFF
+#define IOMMU_CMD_ADDR_HIGH_SHIFT   0
+
+static inline uint32_t iommu_get_addr_lo_from_cmd(uint32_t cmd)
+{
+    return get_field_from_reg_u32(cmd, IOMMU_CMD_ADDR_LOW_MASK, 
+                                  IOMMU_CMD_ADDR_LOW_SHIFT);
+}
+
+static inline uint32_t iommu_get_addr_hi_from_cmd(uint32_t cmd)
+{
+    return get_field_from_reg_u32(cmd, IOMMU_CMD_ADDR_LOW_MASK, 
+                                  IOMMU_CMD_ADDR_HIGH_SHIFT);
+}
+
+#define iommu_get_devid_from_event          iommu_get_devid_from_cmd
+
+/* access iommu base addresses from mmio regs */
+#define IOMMU_REG_BASE_ADDR_BASE_LOW_MASK         0xFFFFF000
+#define IOMMU_REG_BASE_ADDR_LOW_SHIFT             12
+#define IOMMU_REG_BASE_ADDR_HIGH_MASK             0x000FFFFF
+#define IOMMU_REG_BASE_ADDR_HIGH_SHIFT            0
+
+static inline void iommu_set_addr_lo_to_reg(uint32_t *reg, uint32_t addr)
+{
+    set_field_in_reg_u32(addr, *reg, IOMMU_REG_BASE_ADDR_BASE_LOW_MASK, 
+                         IOMMU_REG_BASE_ADDR_LOW_SHIFT, reg);
+}
+
+static inline void iommu_set_addr_hi_to_reg(uint32_t *reg, uint32_t addr)
+{
+    set_field_in_reg_u32(addr, *reg, IOMMU_REG_BASE_ADDR_HIGH_MASK, 
+                         IOMMU_REG_BASE_ADDR_HIGH_SHIFT, reg);
+}
+
+static inline uint32_t iommu_get_addr_lo_from_reg(uint32_t reg)
+{
+    return get_field_from_reg_u32(reg, IOMMU_REG_BASE_ADDR_BASE_LOW_MASK, 
+                                  IOMMU_REG_BASE_ADDR_LOW_SHIFT);
+}
+
+static inline uint32_t iommu_get_addr_hi_from_reg(uint32_t reg)
+{
+    return get_field_from_reg_u32(reg, IOMMU_REG_BASE_ADDR_HIGH_MASK, 
+                                  IOMMU_REG_BASE_ADDR_HIGH_SHIFT);
+}
 
 #endif /* _ASM_X86_64_AMD_IOMMU_PROTO_H */


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 23 11:31:56 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 Dec 2011 11:31:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Re3Lq-0001OG-PR; Fri, 23 Dec 2011 11:31:50 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Wang2@amd.com>) id 1Re3Lo-0001Jh-US
	for xen-devel@lists.xensource.com; Fri, 23 Dec 2011 11:31:49 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1324639901!1815133!1
X-Originating-IP: [216.32.181.182]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23464 invoked from network); 23 Dec 2011 11:31:42 -0000
Received: from ch1ehsobe002.messaging.microsoft.com (HELO
	ch1outboundpool.messaging.microsoft.com) (216.32.181.182)
	by server-4.tower-21.messagelabs.com with AES128-SHA encrypted SMTP;
	23 Dec 2011 11:31:42 -0000
Received: from mail161-ch1-R.bigfish.com (10.43.68.245) by
	CH1EHSOBE018.bigfish.com (10.43.70.68) with Microsoft SMTP Server id
	14.1.225.23; Fri, 23 Dec 2011 11:31:28 +0000
Received: from mail161-ch1 (localhost [127.0.0.1])	by
	mail161-ch1-R.bigfish.com (Postfix) with ESMTP id 52A2B6003E7;
	Fri, 23 Dec 2011 11:32:07 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzzz1202hzz8275bhz2dh668h839h944h)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
X-FB-SS: 0,13,
Received: from mail161-ch1 (localhost.localdomain [127.0.0.1]) by mail161-ch1
	(MessageSwitch) id 1324639901933461_24831;
	Fri, 23 Dec 2011 11:31:41 +0000 (UTC)
Received: from CH1EHSMHS030.bigfish.com (snatpool1.int.messaging.microsoft.com
	[10.43.68.247])	by mail161-ch1.bigfish.com (Postfix) with ESMTP id
	D58F8500045;	Fri, 23 Dec 2011 11:31:41 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	CH1EHSMHS030.bigfish.com (10.43.70.30) with Microsoft SMTP Server id
	14.1.225.23; Fri, 23 Dec 2011 11:31:02 +0000
X-WSS-ID: 0LWNMO1-01-1G8-02
X-M-MSG: 
Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com
	[163.181.249.73])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 24CEC10280A1;	Fri, 23 Dec 2011 05:31:12 -0600 (CST)
Received: from SAUSEXDAG02.amd.com (163.181.55.2) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Fri, 23 Dec 2011 05:31:31 -0600
Received: from storexhtp02.amd.com (172.24.4.4) by sausexdag02.amd.com
	(163.181.55.2) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Fri, 23 Dec 2011 05:31:13 -0600
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Fri, 23 Dec 2011
	06:30:43 -0500
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 4BE0A49C664; Fri, 23 Dec 2011
	11:30:42 +0000 (GMT)
Received: from gran.amd.com (gran.osrc.amd.com [165.204.15.57])	by
	mail.osrc.amd.com (Postfix) with ESMTP id 1E59F594885; Fri, 23 Dec 2011
	12:30:42 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: dd808bdd61c581b041d5b7e816b18674de51da6f
Message-ID: <dd808bdd61c581b041d5.1324639758@gran.amd.com>
In-Reply-To: <patchbomb.1324639749@gran.amd.com>
References: <patchbomb.1324639749@gran.amd.com>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Fri, 23 Dec 2011 12:29:18 +0100
From: Wei Wang <wei.wang2@amd.com>
To: <JBeulich@suse.com>, <Ian.Jackson@eu.citrix.com>,
	<Ian.Campbell@citrix.com>, <keir@xen.org>
X-OriginatorOrg: amd.com
Cc: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 09 of 16] amd iommu: add iommu mmio handler
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Wei Wang <wei.wang2@amd.com>
# Date 1324569398 -3600
# Node ID dd808bdd61c581b041d5b7e816b18674de51da6f
# Parent  2329dad2786f6f20ea69c9609ab60208cad6fca9
amd iommu: add iommu mmio handler.

Signed-off-by: Wei Wang <wei.wang2@amd.com>

diff -r 2329dad2786f -r dd808bdd61c5 xen/arch/x86/hvm/intercept.c
--- a/xen/arch/x86/hvm/intercept.c	Thu Dec 22 16:56:35 2011 +0100
+++ b/xen/arch/x86/hvm/intercept.c	Thu Dec 22 16:56:38 2011 +0100
@@ -38,7 +38,8 @@ hvm_mmio_handlers[HVM_MMIO_HANDLER_NR] =
     &hpet_mmio_handler,
     &vlapic_mmio_handler,
     &vioapic_mmio_handler,
-    &msixtbl_mmio_handler
+    &msixtbl_mmio_handler,
+    &iommu_mmio_handler
 };
 
 static int hvm_mmio_access(struct vcpu *v,
diff -r 2329dad2786f -r dd808bdd61c5 xen/include/asm-x86/hvm/io.h
--- a/xen/include/asm-x86/hvm/io.h	Thu Dec 22 16:56:35 2011 +0100
+++ b/xen/include/asm-x86/hvm/io.h	Thu Dec 22 16:56:38 2011 +0100
@@ -69,8 +69,9 @@ extern const struct hvm_mmio_handler hpe
 extern const struct hvm_mmio_handler vlapic_mmio_handler;
 extern const struct hvm_mmio_handler vioapic_mmio_handler;
 extern const struct hvm_mmio_handler msixtbl_mmio_handler;
+extern const struct hvm_mmio_handler iommu_mmio_handler;
 
-#define HVM_MMIO_HANDLER_NR 4
+#define HVM_MMIO_HANDLER_NR 5
 
 int hvm_io_intercept(ioreq_t *p, int type);
 void register_io_handler(


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 23 11:31:56 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 Dec 2011 11:31:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Re3Lq-0001OG-PR; Fri, 23 Dec 2011 11:31:50 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Wang2@amd.com>) id 1Re3Lo-0001Jh-US
	for xen-devel@lists.xensource.com; Fri, 23 Dec 2011 11:31:49 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1324639901!1815133!1
X-Originating-IP: [216.32.181.182]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23464 invoked from network); 23 Dec 2011 11:31:42 -0000
Received: from ch1ehsobe002.messaging.microsoft.com (HELO
	ch1outboundpool.messaging.microsoft.com) (216.32.181.182)
	by server-4.tower-21.messagelabs.com with AES128-SHA encrypted SMTP;
	23 Dec 2011 11:31:42 -0000
Received: from mail161-ch1-R.bigfish.com (10.43.68.245) by
	CH1EHSOBE018.bigfish.com (10.43.70.68) with Microsoft SMTP Server id
	14.1.225.23; Fri, 23 Dec 2011 11:31:28 +0000
Received: from mail161-ch1 (localhost [127.0.0.1])	by
	mail161-ch1-R.bigfish.com (Postfix) with ESMTP id 52A2B6003E7;
	Fri, 23 Dec 2011 11:32:07 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzzz1202hzz8275bhz2dh668h839h944h)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
X-FB-SS: 0,13,
Received: from mail161-ch1 (localhost.localdomain [127.0.0.1]) by mail161-ch1
	(MessageSwitch) id 1324639901933461_24831;
	Fri, 23 Dec 2011 11:31:41 +0000 (UTC)
Received: from CH1EHSMHS030.bigfish.com (snatpool1.int.messaging.microsoft.com
	[10.43.68.247])	by mail161-ch1.bigfish.com (Postfix) with ESMTP id
	D58F8500045;	Fri, 23 Dec 2011 11:31:41 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	CH1EHSMHS030.bigfish.com (10.43.70.30) with Microsoft SMTP Server id
	14.1.225.23; Fri, 23 Dec 2011 11:31:02 +0000
X-WSS-ID: 0LWNMO1-01-1G8-02
X-M-MSG: 
Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com
	[163.181.249.73])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 24CEC10280A1;	Fri, 23 Dec 2011 05:31:12 -0600 (CST)
Received: from SAUSEXDAG02.amd.com (163.181.55.2) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Fri, 23 Dec 2011 05:31:31 -0600
Received: from storexhtp02.amd.com (172.24.4.4) by sausexdag02.amd.com
	(163.181.55.2) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Fri, 23 Dec 2011 05:31:13 -0600
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Fri, 23 Dec 2011
	06:30:43 -0500
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 4BE0A49C664; Fri, 23 Dec 2011
	11:30:42 +0000 (GMT)
Received: from gran.amd.com (gran.osrc.amd.com [165.204.15.57])	by
	mail.osrc.amd.com (Postfix) with ESMTP id 1E59F594885; Fri, 23 Dec 2011
	12:30:42 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: dd808bdd61c581b041d5b7e816b18674de51da6f
Message-ID: <dd808bdd61c581b041d5.1324639758@gran.amd.com>
In-Reply-To: <patchbomb.1324639749@gran.amd.com>
References: <patchbomb.1324639749@gran.amd.com>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Fri, 23 Dec 2011 12:29:18 +0100
From: Wei Wang <wei.wang2@amd.com>
To: <JBeulich@suse.com>, <Ian.Jackson@eu.citrix.com>,
	<Ian.Campbell@citrix.com>, <keir@xen.org>
X-OriginatorOrg: amd.com
Cc: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 09 of 16] amd iommu: add iommu mmio handler
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Wei Wang <wei.wang2@amd.com>
# Date 1324569398 -3600
# Node ID dd808bdd61c581b041d5b7e816b18674de51da6f
# Parent  2329dad2786f6f20ea69c9609ab60208cad6fca9
amd iommu: add iommu mmio handler.

Signed-off-by: Wei Wang <wei.wang2@amd.com>

diff -r 2329dad2786f -r dd808bdd61c5 xen/arch/x86/hvm/intercept.c
--- a/xen/arch/x86/hvm/intercept.c	Thu Dec 22 16:56:35 2011 +0100
+++ b/xen/arch/x86/hvm/intercept.c	Thu Dec 22 16:56:38 2011 +0100
@@ -38,7 +38,8 @@ hvm_mmio_handlers[HVM_MMIO_HANDLER_NR] =
     &hpet_mmio_handler,
     &vlapic_mmio_handler,
     &vioapic_mmio_handler,
-    &msixtbl_mmio_handler
+    &msixtbl_mmio_handler,
+    &iommu_mmio_handler
 };
 
 static int hvm_mmio_access(struct vcpu *v,
diff -r 2329dad2786f -r dd808bdd61c5 xen/include/asm-x86/hvm/io.h
--- a/xen/include/asm-x86/hvm/io.h	Thu Dec 22 16:56:35 2011 +0100
+++ b/xen/include/asm-x86/hvm/io.h	Thu Dec 22 16:56:38 2011 +0100
@@ -69,8 +69,9 @@ extern const struct hvm_mmio_handler hpe
 extern const struct hvm_mmio_handler vlapic_mmio_handler;
 extern const struct hvm_mmio_handler vioapic_mmio_handler;
 extern const struct hvm_mmio_handler msixtbl_mmio_handler;
+extern const struct hvm_mmio_handler iommu_mmio_handler;
 
-#define HVM_MMIO_HANDLER_NR 4
+#define HVM_MMIO_HANDLER_NR 5
 
 int hvm_io_intercept(ioreq_t *p, int type);
 void register_io_handler(


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 23 11:32:07 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 Dec 2011 11:32:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Re3M4-0001Vw-0z; Fri, 23 Dec 2011 11:32:04 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Wang2@amd.com>) id 1Re3M2-0001Sa-BN
	for xen-devel@lists.xensource.com; Fri, 23 Dec 2011 11:32:02 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1324639916!8404893!1
X-Originating-IP: [213.199.154.204]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10022 invoked from network); 23 Dec 2011 11:31:56 -0000
Received: from am1ehsobe001.messaging.microsoft.com (HELO
	AM1EHSOBE001.bigfish.com) (213.199.154.204)
	by server-11.tower-182.messagelabs.com with AES128-SHA encrypted SMTP;
	23 Dec 2011 11:31:56 -0000
Received: from mail90-am1-R.bigfish.com (10.3.201.253) by
	AM1EHSOBE001.bigfish.com (10.3.204.21) with Microsoft SMTP Server id
	14.1.225.23; Fri, 23 Dec 2011 11:31:43 +0000
Received: from mail90-am1 (localhost [127.0.0.1])	by mail90-am1-R.bigfish.com
	(Postfix) with ESMTP id 93FD764049C;
	Fri, 23 Dec 2011 11:32:44 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzzz1202hzz8275bhz2dh668h839h944h)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
Received: from mail90-am1 (localhost.localdomain [127.0.0.1]) by mail90-am1
	(MessageSwitch) id 1324639964462912_25092;
	Fri, 23 Dec 2011 11:32:44 +0000 (UTC)
Received: from AM1EHSMHS018.bigfish.com (unknown [10.3.201.246])	by
	mail90-am1.bigfish.com (Postfix) with ESMTP id 6A81D540042;
	Fri, 23 Dec 2011 11:32:44 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	AM1EHSMHS018.bigfish.com (10.3.206.21) with Microsoft SMTP Server id
	14.1.225.23; Fri, 23 Dec 2011 11:31:43 +0000
X-WSS-ID: 0LWNMP3-01-1HI-02
X-M-MSG: 
Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com
	[163.181.249.73])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2E733102809E;	Fri, 23 Dec 2011 05:31:50 -0600 (CST)
Received: from SAUSEXDAG02.amd.com (163.181.55.2) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Fri, 23 Dec 2011 05:32:09 -0600
Received: from storexhtp01.amd.com (172.24.4.3) by sausexdag02.amd.com
	(163.181.55.2) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Fri, 23 Dec 2011 05:31:51 -0600
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp01.amd.com
	(172.24.4.3) with Microsoft SMTP Server id 8.3.213.0; Fri, 23 Dec 2011
	06:30:44 -0500
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 0425749C668; Fri, 23 Dec 2011
	11:30:43 +0000 (GMT)
Received: from gran.amd.com (gran.osrc.amd.com [165.204.15.57])	by
	mail.osrc.amd.com (Postfix) with ESMTP id E051B594883; Fri, 23 Dec 2011
	12:30:42 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 00bdad5dfb7f5efd0b1cc54622b3ccb1b1b1b16f
Message-ID: <00bdad5dfb7f5efd0b1c.1324639762@gran.amd.com>
In-Reply-To: <patchbomb.1324639749@gran.amd.com>
References: <patchbomb.1324639749@gran.amd.com>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Fri, 23 Dec 2011 12:29:22 +0100
From: Wei Wang <wei.wang2@amd.com>
To: <JBeulich@suse.com>, <Ian.Jackson@eu.citrix.com>,
	<Ian.Campbell@citrix.com>, <keir@xen.org>
X-OriginatorOrg: amd.com
Cc: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 13 of 16] libxc: add wrappers for new hypercalls
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Wei Wang <wei.wang2@amd.com>
# Date 1324569412 -3600
# Node ID 00bdad5dfb7f5efd0b1cc54622b3ccb1b1b1b16f
# Parent  bb76ba2457e629d668c08e57f2168b13bdfb7930
libxc: add wrappers for new hypercalls

Signed-off-by: Wei Wang <wei.wang2@amd.com>

diff -r bb76ba2457e6 -r 00bdad5dfb7f tools/libxc/xc_domain.c
--- a/tools/libxc/xc_domain.c	Thu Dec 22 16:56:48 2011 +0100
+++ b/tools/libxc/xc_domain.c	Thu Dec 22 16:56:52 2011 +0100
@@ -1352,6 +1352,55 @@ int xc_domain_bind_pt_isa_irq(
                                   PT_IRQ_TYPE_ISA, 0, 0, 0, machine_irq));
 }
 
+int xc_domain_update_iommu_msi(
+    xc_interface *xch,
+    uint32_t domid,
+    uint8_t vector,
+    uint8_t dest,
+    uint8_t dest_mode,
+    uint8_t delivery_mode,
+    uint8_t trig_mode)
+{
+    int rc;
+    DECLARE_DOMCTL;
+    xen_domctl_guest_iommu_op_t * iommu_op;
+
+    domctl.cmd = XEN_DOMCTL_guest_iommu_op;
+    domctl.domain = (domid_t)domid;
+
+    iommu_op = &(domctl.u.guest_iommu_op);
+    iommu_op->op = XEN_DOMCTL_GUEST_IOMMU_OP_SET_MSI;
+    iommu_op->u.msi.vector = vector;
+    iommu_op->u.msi.dest = dest;
+    iommu_op->u.msi.dest_mode = dest_mode;
+    iommu_op->u.msi.delivery_mode = delivery_mode;
+    iommu_op->u.msi.trig_mode = trig_mode;
+
+    rc = do_domctl(xch, &domctl);
+    return rc;
+}
+
+int xc_domain_bind_pt_bdf(xc_interface *xch,
+                          uint32_t domid,
+                          uint32_t gbdf,
+                          uint32_t mbdf)
+{
+    int rc;
+    DECLARE_DOMCTL;
+    xen_domctl_guest_iommu_op_t * guest_op;
+
+    domctl.cmd = XEN_DOMCTL_guest_iommu_op;
+    domctl.domain = (domid_t)domid;
+
+    guest_op = &(domctl.u.guest_iommu_op);
+    guest_op->op = XEN_DOMCTL_GUEST_IOMMU_OP_BIND_BDF;
+    guest_op->u.bdf_bind.g_bdf = gbdf;
+    guest_op->u.bdf_bind.m_bdf = mbdf;
+
+    rc = do_domctl(xch, &domctl);
+    return rc;
+}
+
 int xc_domain_memory_mapping(
     xc_interface *xch,
     uint32_t domid,
diff -r bb76ba2457e6 -r 00bdad5dfb7f tools/libxc/xenctrl.h
--- a/tools/libxc/xenctrl.h	Thu Dec 22 16:56:48 2011 +0100
+++ b/tools/libxc/xenctrl.h	Thu Dec 22 16:56:52 2011 +0100
@@ -1697,6 +1697,19 @@ int xc_domain_bind_pt_isa_irq(xc_interfa
                               uint32_t domid,
                               uint8_t machine_irq);
 
+int xc_domain_bind_pt_bdf(xc_interface *xch,
+                          uint32_t domid,
+                          uint32_t gbdf,
+                          uint32_t mbdf);
+
+int xc_domain_update_iommu_msi(xc_interface *xch,
+                               uint32_t domid,
+                               uint8_t vector,
+                               uint8_t dest,
+                               uint8_t dest_mode,
+                               uint8_t delivery_mode,
+                               uint8_t trig_mode);
+
 int xc_domain_set_machine_address_size(xc_interface *xch,
 				       uint32_t domid,
 				       unsigned int width);


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 23 11:32:07 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 Dec 2011 11:32:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Re3M4-0001Vw-0z; Fri, 23 Dec 2011 11:32:04 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Wang2@amd.com>) id 1Re3M2-0001Sa-BN
	for xen-devel@lists.xensource.com; Fri, 23 Dec 2011 11:32:02 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1324639916!8404893!1
X-Originating-IP: [213.199.154.204]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10022 invoked from network); 23 Dec 2011 11:31:56 -0000
Received: from am1ehsobe001.messaging.microsoft.com (HELO
	AM1EHSOBE001.bigfish.com) (213.199.154.204)
	by server-11.tower-182.messagelabs.com with AES128-SHA encrypted SMTP;
	23 Dec 2011 11:31:56 -0000
Received: from mail90-am1-R.bigfish.com (10.3.201.253) by
	AM1EHSOBE001.bigfish.com (10.3.204.21) with Microsoft SMTP Server id
	14.1.225.23; Fri, 23 Dec 2011 11:31:43 +0000
Received: from mail90-am1 (localhost [127.0.0.1])	by mail90-am1-R.bigfish.com
	(Postfix) with ESMTP id 93FD764049C;
	Fri, 23 Dec 2011 11:32:44 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzzz1202hzz8275bhz2dh668h839h944h)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
Received: from mail90-am1 (localhost.localdomain [127.0.0.1]) by mail90-am1
	(MessageSwitch) id 1324639964462912_25092;
	Fri, 23 Dec 2011 11:32:44 +0000 (UTC)
Received: from AM1EHSMHS018.bigfish.com (unknown [10.3.201.246])	by
	mail90-am1.bigfish.com (Postfix) with ESMTP id 6A81D540042;
	Fri, 23 Dec 2011 11:32:44 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	AM1EHSMHS018.bigfish.com (10.3.206.21) with Microsoft SMTP Server id
	14.1.225.23; Fri, 23 Dec 2011 11:31:43 +0000
X-WSS-ID: 0LWNMP3-01-1HI-02
X-M-MSG: 
Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com
	[163.181.249.73])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2E733102809E;	Fri, 23 Dec 2011 05:31:50 -0600 (CST)
Received: from SAUSEXDAG02.amd.com (163.181.55.2) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Fri, 23 Dec 2011 05:32:09 -0600
Received: from storexhtp01.amd.com (172.24.4.3) by sausexdag02.amd.com
	(163.181.55.2) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Fri, 23 Dec 2011 05:31:51 -0600
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp01.amd.com
	(172.24.4.3) with Microsoft SMTP Server id 8.3.213.0; Fri, 23 Dec 2011
	06:30:44 -0500
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 0425749C668; Fri, 23 Dec 2011
	11:30:43 +0000 (GMT)
Received: from gran.amd.com (gran.osrc.amd.com [165.204.15.57])	by
	mail.osrc.amd.com (Postfix) with ESMTP id E051B594883; Fri, 23 Dec 2011
	12:30:42 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 00bdad5dfb7f5efd0b1cc54622b3ccb1b1b1b16f
Message-ID: <00bdad5dfb7f5efd0b1c.1324639762@gran.amd.com>
In-Reply-To: <patchbomb.1324639749@gran.amd.com>
References: <patchbomb.1324639749@gran.amd.com>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Fri, 23 Dec 2011 12:29:22 +0100
From: Wei Wang <wei.wang2@amd.com>
To: <JBeulich@suse.com>, <Ian.Jackson@eu.citrix.com>,
	<Ian.Campbell@citrix.com>, <keir@xen.org>
X-OriginatorOrg: amd.com
Cc: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 13 of 16] libxc: add wrappers for new hypercalls
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Wei Wang <wei.wang2@amd.com>
# Date 1324569412 -3600
# Node ID 00bdad5dfb7f5efd0b1cc54622b3ccb1b1b1b16f
# Parent  bb76ba2457e629d668c08e57f2168b13bdfb7930
libxc: add wrappers for new hypercalls

Signed-off-by: Wei Wang <wei.wang2@amd.com>

diff -r bb76ba2457e6 -r 00bdad5dfb7f tools/libxc/xc_domain.c
--- a/tools/libxc/xc_domain.c	Thu Dec 22 16:56:48 2011 +0100
+++ b/tools/libxc/xc_domain.c	Thu Dec 22 16:56:52 2011 +0100
@@ -1352,6 +1352,55 @@ int xc_domain_bind_pt_isa_irq(
                                   PT_IRQ_TYPE_ISA, 0, 0, 0, machine_irq));
 }
 
+int xc_domain_update_iommu_msi(
+    xc_interface *xch,
+    uint32_t domid,
+    uint8_t vector,
+    uint8_t dest,
+    uint8_t dest_mode,
+    uint8_t delivery_mode,
+    uint8_t trig_mode)
+{
+    int rc;
+    DECLARE_DOMCTL;
+    xen_domctl_guest_iommu_op_t * iommu_op;
+
+    domctl.cmd = XEN_DOMCTL_guest_iommu_op;
+    domctl.domain = (domid_t)domid;
+
+    iommu_op = &(domctl.u.guest_iommu_op);
+    iommu_op->op = XEN_DOMCTL_GUEST_IOMMU_OP_SET_MSI;
+    iommu_op->u.msi.vector = vector;
+    iommu_op->u.msi.dest = dest;
+    iommu_op->u.msi.dest_mode = dest_mode;
+    iommu_op->u.msi.delivery_mode = delivery_mode;
+    iommu_op->u.msi.trig_mode = trig_mode;
+
+    rc = do_domctl(xch, &domctl);
+    return rc;
+}
+
+int xc_domain_bind_pt_bdf(xc_interface *xch,
+                          uint32_t domid,
+                          uint32_t gbdf,
+                          uint32_t mbdf)
+{
+    int rc;
+    DECLARE_DOMCTL;
+    xen_domctl_guest_iommu_op_t * guest_op;
+
+    domctl.cmd = XEN_DOMCTL_guest_iommu_op;
+    domctl.domain = (domid_t)domid;
+
+    guest_op = &(domctl.u.guest_iommu_op);
+    guest_op->op = XEN_DOMCTL_GUEST_IOMMU_OP_BIND_BDF;
+    guest_op->u.bdf_bind.g_bdf = gbdf;
+    guest_op->u.bdf_bind.m_bdf = mbdf;
+
+    rc = do_domctl(xch, &domctl);
+    return rc;
+}
+
 int xc_domain_memory_mapping(
     xc_interface *xch,
     uint32_t domid,
diff -r bb76ba2457e6 -r 00bdad5dfb7f tools/libxc/xenctrl.h
--- a/tools/libxc/xenctrl.h	Thu Dec 22 16:56:48 2011 +0100
+++ b/tools/libxc/xenctrl.h	Thu Dec 22 16:56:52 2011 +0100
@@ -1697,6 +1697,19 @@ int xc_domain_bind_pt_isa_irq(xc_interfa
                               uint32_t domid,
                               uint8_t machine_irq);
 
+int xc_domain_bind_pt_bdf(xc_interface *xch,
+                          uint32_t domid,
+                          uint32_t gbdf,
+                          uint32_t mbdf);
+
+int xc_domain_update_iommu_msi(xc_interface *xch,
+                               uint32_t domid,
+                               uint8_t vector,
+                               uint8_t dest,
+                               uint8_t dest_mode,
+                               uint8_t delivery_mode,
+                               uint8_t trig_mode);
+
 int xc_domain_set_machine_address_size(xc_interface *xch,
 				       uint32_t domid,
 				       unsigned int width);


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 23 11:32:16 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 Dec 2011 11:32:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Re3M1-0001UP-JW; Fri, 23 Dec 2011 11:32:01 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Wang2@amd.com>) id 1Re3Lz-0001Ro-KA
	for xen-devel@lists.xensource.com; Fri, 23 Dec 2011 11:31:59 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1324639883!46022303!1
X-Originating-IP: [213.199.154.209]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22817 invoked from network); 23 Dec 2011 11:31:24 -0000
Received: from am1ehsobe006.messaging.microsoft.com (HELO
	AM1EHSOBE006.bigfish.com) (213.199.154.209)
	by server-12.tower-27.messagelabs.com with AES128-SHA encrypted SMTP;
	23 Dec 2011 11:31:24 -0000
Received: from mail57-am1-R.bigfish.com (10.3.201.254) by
	AM1EHSOBE006.bigfish.com (10.3.204.26) with Microsoft SMTP Server id
	14.1.225.23; Fri, 23 Dec 2011 11:31:43 +0000
Received: from mail57-am1 (localhost [127.0.0.1])	by mail57-am1-R.bigfish.com
	(Postfix) with ESMTP id 4A0356804CF;
	Fri, 23 Dec 2011 11:32:48 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzzz1202hzz8275bhz2dh668h839h944h)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
Received: from mail57-am1 (localhost.localdomain [127.0.0.1]) by mail57-am1
	(MessageSwitch) id 132463996849207_17046;
	Fri, 23 Dec 2011 11:32:48 +0000 (UTC)
Received: from AM1EHSMHS020.bigfish.com (unknown [10.3.201.254])	by
	mail57-am1.bigfish.com (Postfix) with ESMTP id 07AC3420042;
	Fri, 23 Dec 2011 11:32:48 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	AM1EHSMHS020.bigfish.com (10.3.206.23) with Microsoft SMTP Server id
	14.1.225.23; Fri, 23 Dec 2011 11:31:42 +0000
X-WSS-ID: 0LWNMP4-02-0YM-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp02.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2EC69C80D5;	Fri, 23 Dec 2011 05:31:51 -0600 (CST)
Received: from SAUSEXDAG02.amd.com (163.181.55.2) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Fri, 23 Dec 2011 05:32:10 -0600
Received: from storexhtp01.amd.com (172.24.4.3) by sausexdag02.amd.com
	(163.181.55.2) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Fri, 23 Dec 2011 05:31:52 -0600
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp01.amd.com
	(172.24.4.3) with Microsoft SMTP Server id 8.3.213.0; Fri, 23 Dec 2011
	06:30:44 -0500
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 07B7B49C66A; Fri, 23 Dec 2011
	11:30:43 +0000 (GMT)
Received: from gran.amd.com (gran.osrc.amd.com [165.204.15.57])	by
	mail.osrc.amd.com (Postfix) with ESMTP id EC3B15940FF; Fri, 23 Dec 2011
	12:30:42 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 7ac92c11a11a4dbdf85ef503445128be861cb400
Message-ID: <7ac92c11a11a4dbdf85e.1324639763@gran.amd.com>
In-Reply-To: <patchbomb.1324639749@gran.amd.com>
References: <patchbomb.1324639749@gran.amd.com>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Fri, 23 Dec 2011 12:29:23 +0100
From: Wei Wang <wei.wang2@amd.com>
To: <JBeulich@suse.com>, <Ian.Jackson@eu.citrix.com>,
	<Ian.Campbell@citrix.com>, <keir@xen.org>
X-OriginatorOrg: amd.com
Cc: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 14 of 16] libxl: bind virtual bdf to physical
 bdf after device assignment
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Wei Wang <wei.wang2@amd.com>
# Date 1324569415 -3600
# Node ID 7ac92c11a11a4dbdf85ef503445128be861cb400
# Parent  00bdad5dfb7f5efd0b1cc54622b3ccb1b1b1b16f
libxl: bind virtual bdf to physical bdf after device assignment

Signed-off-by: Wei Wang <wei.wang2@amd.com>

diff -r 00bdad5dfb7f -r 7ac92c11a11a tools/libxl/libxl_pci.c
--- a/tools/libxl/libxl_pci.c	Thu Dec 22 16:56:52 2011 +0100
+++ b/tools/libxl/libxl_pci.c	Thu Dec 22 16:56:55 2011 +0100
@@ -735,6 +735,13 @@ out:
             LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, rc, "xc_assign_device failed");
             return ERROR_FAIL;
         }
+        if (LIBXL__DOMAIN_IS_TYPE(gc,  domid, HVM)) {
+            rc = xc_domain_bind_pt_bdf(ctx->xch, domid, pcidev->vdevfn, pcidev_encode_bdf(pcidev));
+            if ( rc ) {
+            LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, rc, "xc_domain_bind_pt_bdf failed");
+            return ERROR_FAIL;
+            }
+        }
     }
 
     if (!starting)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 23 11:32:16 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 Dec 2011 11:32:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Re3M1-0001UP-JW; Fri, 23 Dec 2011 11:32:01 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Wang2@amd.com>) id 1Re3Lz-0001Ro-KA
	for xen-devel@lists.xensource.com; Fri, 23 Dec 2011 11:31:59 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1324639883!46022303!1
X-Originating-IP: [213.199.154.209]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22817 invoked from network); 23 Dec 2011 11:31:24 -0000
Received: from am1ehsobe006.messaging.microsoft.com (HELO
	AM1EHSOBE006.bigfish.com) (213.199.154.209)
	by server-12.tower-27.messagelabs.com with AES128-SHA encrypted SMTP;
	23 Dec 2011 11:31:24 -0000
Received: from mail57-am1-R.bigfish.com (10.3.201.254) by
	AM1EHSOBE006.bigfish.com (10.3.204.26) with Microsoft SMTP Server id
	14.1.225.23; Fri, 23 Dec 2011 11:31:43 +0000
Received: from mail57-am1 (localhost [127.0.0.1])	by mail57-am1-R.bigfish.com
	(Postfix) with ESMTP id 4A0356804CF;
	Fri, 23 Dec 2011 11:32:48 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzzz1202hzz8275bhz2dh668h839h944h)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
Received: from mail57-am1 (localhost.localdomain [127.0.0.1]) by mail57-am1
	(MessageSwitch) id 132463996849207_17046;
	Fri, 23 Dec 2011 11:32:48 +0000 (UTC)
Received: from AM1EHSMHS020.bigfish.com (unknown [10.3.201.254])	by
	mail57-am1.bigfish.com (Postfix) with ESMTP id 07AC3420042;
	Fri, 23 Dec 2011 11:32:48 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	AM1EHSMHS020.bigfish.com (10.3.206.23) with Microsoft SMTP Server id
	14.1.225.23; Fri, 23 Dec 2011 11:31:42 +0000
X-WSS-ID: 0LWNMP4-02-0YM-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp02.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2EC69C80D5;	Fri, 23 Dec 2011 05:31:51 -0600 (CST)
Received: from SAUSEXDAG02.amd.com (163.181.55.2) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Fri, 23 Dec 2011 05:32:10 -0600
Received: from storexhtp01.amd.com (172.24.4.3) by sausexdag02.amd.com
	(163.181.55.2) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Fri, 23 Dec 2011 05:31:52 -0600
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp01.amd.com
	(172.24.4.3) with Microsoft SMTP Server id 8.3.213.0; Fri, 23 Dec 2011
	06:30:44 -0500
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 07B7B49C66A; Fri, 23 Dec 2011
	11:30:43 +0000 (GMT)
Received: from gran.amd.com (gran.osrc.amd.com [165.204.15.57])	by
	mail.osrc.amd.com (Postfix) with ESMTP id EC3B15940FF; Fri, 23 Dec 2011
	12:30:42 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 7ac92c11a11a4dbdf85ef503445128be861cb400
Message-ID: <7ac92c11a11a4dbdf85e.1324639763@gran.amd.com>
In-Reply-To: <patchbomb.1324639749@gran.amd.com>
References: <patchbomb.1324639749@gran.amd.com>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Fri, 23 Dec 2011 12:29:23 +0100
From: Wei Wang <wei.wang2@amd.com>
To: <JBeulich@suse.com>, <Ian.Jackson@eu.citrix.com>,
	<Ian.Campbell@citrix.com>, <keir@xen.org>
X-OriginatorOrg: amd.com
Cc: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 14 of 16] libxl: bind virtual bdf to physical
 bdf after device assignment
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Wei Wang <wei.wang2@amd.com>
# Date 1324569415 -3600
# Node ID 7ac92c11a11a4dbdf85ef503445128be861cb400
# Parent  00bdad5dfb7f5efd0b1cc54622b3ccb1b1b1b16f
libxl: bind virtual bdf to physical bdf after device assignment

Signed-off-by: Wei Wang <wei.wang2@amd.com>

diff -r 00bdad5dfb7f -r 7ac92c11a11a tools/libxl/libxl_pci.c
--- a/tools/libxl/libxl_pci.c	Thu Dec 22 16:56:52 2011 +0100
+++ b/tools/libxl/libxl_pci.c	Thu Dec 22 16:56:55 2011 +0100
@@ -735,6 +735,13 @@ out:
             LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, rc, "xc_assign_device failed");
             return ERROR_FAIL;
         }
+        if (LIBXL__DOMAIN_IS_TYPE(gc,  domid, HVM)) {
+            rc = xc_domain_bind_pt_bdf(ctx->xch, domid, pcidev->vdevfn, pcidev_encode_bdf(pcidev));
+            if ( rc ) {
+            LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, rc, "xc_domain_bind_pt_bdf failed");
+            return ERROR_FAIL;
+            }
+        }
     }
 
     if (!starting)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 23 11:32:20 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 Dec 2011 11:32:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Re3MH-0001fn-2D; Fri, 23 Dec 2011 11:32:17 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Wang2@amd.com>) id 1Re3MF-0001aV-CH
	for xen-devel@lists.xensource.com; Fri, 23 Dec 2011 11:32:15 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1324639880!8549102!1
X-Originating-IP: [216.32.181.185]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18289 invoked from network); 23 Dec 2011 11:31:21 -0000
Received: from ch1ehsobe005.messaging.microsoft.com (HELO
	ch1outboundpool.messaging.microsoft.com) (216.32.181.185)
	by server-6.tower-216.messagelabs.com with AES128-SHA encrypted SMTP;
	23 Dec 2011 11:31:21 -0000
Received: from mail169-ch1-R.bigfish.com (10.43.68.247) by
	CH1EHSOBE003.bigfish.com (10.43.70.53) with Microsoft SMTP Server id
	14.1.225.23; Fri, 23 Dec 2011 11:31:08 +0000
Received: from mail169-ch1 (localhost [127.0.0.1])	by
	mail169-ch1-R.bigfish.com (Postfix) with ESMTP id BA0B118024C;
	Fri, 23 Dec 2011 11:31:47 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzzz1202hzz8275bhz2dh668h839h944h)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
X-FB-SS: 13,
Received: from mail169-ch1 (localhost.localdomain [127.0.0.1]) by mail169-ch1
	(MessageSwitch) id 1324639907357266_9934;
	Fri, 23 Dec 2011 11:31:47 +0000 (UTC)
Received: from CH1EHSMHS025.bigfish.com (snatpool1.int.messaging.microsoft.com
	[10.43.68.254])	by mail169-ch1.bigfish.com (Postfix) with ESMTP id
	4B235320048;	Fri, 23 Dec 2011 11:31:47 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	CH1EHSMHS025.bigfish.com (10.43.70.25) with Microsoft SMTP Server id
	14.1.225.23; Fri, 23 Dec 2011 11:31:07 +0000
X-WSS-ID: 0LWNMO5-02-0XC-02
X-M-MSG: 
Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com
	[163.181.249.73])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp02.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2D71AC80D7;	Fri, 23 Dec 2011 05:31:16 -0600 (CST)
Received: from SAUSEXDAG02.amd.com (163.181.55.2) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Fri, 23 Dec 2011 05:31:35 -0600
Received: from storexhtp01.amd.com (172.24.4.3) by sausexdag02.amd.com
	(163.181.55.2) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Fri, 23 Dec 2011 05:31:17 -0600
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp01.amd.com
	(172.24.4.3) with Microsoft SMTP Server id 8.3.213.0; Fri, 23 Dec 2011
	06:30:43 -0500
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id E30A249C661; Fri, 23 Dec 2011
	11:30:41 +0000 (GMT)
Received: from gran.amd.com (gran.osrc.amd.com [165.204.15.57])	by
	mail.osrc.amd.com (Postfix) with ESMTP id C67DF594882; Fri, 23 Dec 2011
	12:30:41 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: bf9f21ad9a0ec245b409f3862a5a36c0e070f333
Message-ID: <bf9f21ad9a0ec245b409.1324639755@gran.amd.com>
In-Reply-To: <patchbomb.1324639749@gran.amd.com>
References: <patchbomb.1324639749@gran.amd.com>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Fri, 23 Dec 2011 12:29:15 +0100
From: Wei Wang <wei.wang2@amd.com>
To: <JBeulich@suse.com>, <Ian.Jackson@eu.citrix.com>,
	<Ian.Campbell@citrix.com>, <keir@xen.org>
X-OriginatorOrg: amd.com
Cc: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 06 of 16] amd iommu: add ppr log processing into
 iommu interrupt handling
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Wei Wang <wei.wang2@amd.com>
# Date 1324569388 -3600
# Node ID bf9f21ad9a0ec245b409f3862a5a36c0e070f333
# Parent  120144c1fac2dd26926b3b2a6362d30a4029620f
amd iommu: add ppr log processing into iommu interrupt handling
PPR log and event log share the same interrupt source. Interrupt handler
should check both of them.

Signed-off-by: Wei Wang <wei.wang2@amd.com>

diff -r 120144c1fac2 -r bf9f21ad9a0e xen/drivers/passthrough/amd/iommu_init.c
--- a/xen/drivers/passthrough/amd/iommu_init.c	Thu Dec 22 16:56:25 2011 +0100
+++ b/xen/drivers/passthrough/amd/iommu_init.c	Thu Dec 22 16:56:28 2011 +0100
@@ -352,75 +352,91 @@ static void set_iommu_ppr_log_control(st
         AMD_IOMMU_DEBUG("PPR Log Enabled.\n");
 }
 
-static void parse_event_log_entry(struct amd_iommu *, u32 entry[]);
+/* read event log or ppr log from iommu ring buffer */
+static int iommu_read_log(struct amd_iommu *iommu, 
+                          struct ring_buffer *log,
+                          void (*parse_func)(struct amd_iommu *, u32 *))
+{
+    u32 tail, head, *entry, tail_offest, head_offset;
 
-static int amd_iommu_read_event_log(struct amd_iommu *iommu)
-{
-    u32 tail, head, *event_log;
-
-    BUG_ON( !iommu );
+    BUG_ON( !iommu || ((log != &iommu->event_log) && 
+            (log != &iommu->ppr_log)) );
 
     /* make sure there's an entry in the log */
-    tail = readl(iommu->mmio_base + IOMMU_EVENT_LOG_TAIL_OFFSET);
-    tail = get_field_from_reg_u32(tail,
-                                  IOMMU_EVENT_LOG_TAIL_MASK,
-                                  IOMMU_EVENT_LOG_TAIL_SHIFT);
+    tail_offest = ( log == &iommu->event_log ) ?
+        IOMMU_EVENT_LOG_TAIL_OFFSET:
+        IOMMU_PPR_LOG_TAIL_OFFSET;
 
-    while ( tail != iommu->event_log.head )
+    head_offset = ( log == &iommu->event_log ) ?
+        IOMMU_EVENT_LOG_HEAD_OFFSET:
+        IOMMU_PPR_LOG_HEAD_OFFSET;
+
+    tail = readl(iommu->mmio_base + tail_offest);
+    tail = iommu_get_rb_pointer(tail);
+
+    while ( tail != log->head )
     {
         /* read event log entry */
-        event_log = (u32 *)(iommu->event_log.buffer +
-                           (iommu->event_log.head *
-                           IOMMU_EVENT_LOG_ENTRY_SIZE));
+        entry = (u32 *)(log->buffer + log->head * log->entry_size);
 
-        parse_event_log_entry(iommu, event_log);
-
-        if ( ++iommu->event_log.head == iommu->event_log.entries )
-            iommu->event_log.head = 0;
+        parse_func(iommu, entry);
+        if ( ++log->head == log->entries )
+            log->head = 0;
 
         /* update head pointer */
-        set_field_in_reg_u32(iommu->event_log.head, 0,
-                             IOMMU_EVENT_LOG_HEAD_MASK,
-                             IOMMU_EVENT_LOG_HEAD_SHIFT, &head);
-        writel(head, iommu->mmio_base + IOMMU_EVENT_LOG_HEAD_OFFSET);
+        head = 0;
+        iommu_set_rb_pointer(&head, log->head);
+
+        writel(head, iommu->mmio_base + head_offset);
     }
 
     return 0;
 }
 
-static void amd_iommu_reset_event_log(struct amd_iommu *iommu)
+/* reset event log or ppr log when overflow */
+static void iommu_reset_log(struct amd_iommu *iommu,
+                            struct ring_buffer *log,
+                            void (*ctrl_func)(struct amd_iommu *iommu, int))
 {
     u32 entry;
-    int log_run;
+    int log_run, run_bit, of_bit;
     int loop_count = 1000;
 
+    BUG_ON( !iommu || ((log != &iommu->event_log) && 
+            (log != &iommu->ppr_log)) );
+
+    run_bit = ( log == &iommu->event_log ) ?
+        IOMMU_STATUS_EVENT_LOG_RUN_SHIFT:
+        IOMMU_STATUS_PPR_LOG_RUN_SHIFT;
+
+    of_bit = ( log == &iommu->event_log ) ?
+        IOMMU_STATUS_EVENT_OVERFLOW_SHIFT:
+        IOMMU_STATUS_PPR_LOG_OVERFLOW_SHIFT;
+
     /* wait until EventLogRun bit = 0 */
     do {
         entry = readl(iommu->mmio_base + IOMMU_STATUS_MMIO_OFFSET);
-        log_run = iommu_get_bit(entry, IOMMU_STATUS_EVENT_LOG_RUN_SHIFT);
+        log_run = iommu_get_bit(entry, run_bit);
         loop_count--;
     } while ( log_run && loop_count );
 
     if ( log_run )
     {
-        AMD_IOMMU_DEBUG("Warning: EventLogRun bit is not cleared"
-                        "before reset!\n");
+        AMD_IOMMU_DEBUG("Warning: Log Run bit %d is not cleared"
+                        "before reset! \n", run_bit);
         return;
     }
 
-    set_iommu_event_log_control(iommu, IOMMU_CONTROL_DISABLED);
+    ctrl_func(iommu, IOMMU_CONTROL_DISABLED);
 
-    /* read event log for debugging */
-    amd_iommu_read_event_log(iommu);
     /*clear overflow bit */
-    iommu_clear_bit(&entry, IOMMU_STATUS_EVENT_OVERFLOW_SHIFT);
-
-    writel(entry, iommu->mmio_base+IOMMU_STATUS_MMIO_OFFSET);
+    iommu_clear_bit(&entry, of_bit);
+    writel(entry, iommu->mmio_base + IOMMU_STATUS_MMIO_OFFSET);
 
     /*reset event log base address */
-    iommu->event_log.head = 0;
+    log->head = 0;
 
-    set_iommu_event_log_control(iommu, IOMMU_CONTROL_ENABLED);
+    ctrl_func(iommu, IOMMU_CONTROL_ENABLED);
 }
 
 static void iommu_msi_set_affinity(struct irq_desc *desc, const cpumask_t *mask)
@@ -592,30 +608,93 @@ static void parse_event_log_entry(struct
     }
 }
 
-static void amd_iommu_page_fault(int irq, void *dev_id,
-                             struct cpu_user_regs *regs)
+static void iommu_check_event_log(struct amd_iommu *iommu)
 {
     u32 entry;
     unsigned long flags;
-    struct amd_iommu *iommu = dev_id;
 
     spin_lock_irqsave(&iommu->lock, flags);
-    amd_iommu_read_event_log(iommu);
+
+    iommu_read_log(iommu, &iommu->event_log, parse_event_log_entry);
 
     /*check event overflow */
     entry = readl(iommu->mmio_base + IOMMU_STATUS_MMIO_OFFSET);
 
     if ( iommu_get_bit(entry, IOMMU_STATUS_EVENT_OVERFLOW_SHIFT) )
-        amd_iommu_reset_event_log(iommu);
+        iommu_reset_log(iommu, &iommu->event_log, set_iommu_event_log_control);
 
     /* reset interrupt status bit */
     entry = readl(iommu->mmio_base + IOMMU_STATUS_MMIO_OFFSET);
     iommu_set_bit(&entry, IOMMU_STATUS_EVENT_LOG_INT_SHIFT);
 
-    writel(entry, iommu->mmio_base+IOMMU_STATUS_MMIO_OFFSET);
+    writel(entry, iommu->mmio_base + IOMMU_STATUS_MMIO_OFFSET);
+
     spin_unlock_irqrestore(&iommu->lock, flags);
 }
 
+void parse_ppr_log_entry(struct amd_iommu *iommu, u32 entry[])
+{
+
+    u16 device_id;
+    u8 bus, devfn;
+    struct pci_dev *pdev;
+    struct domain *d;
+
+    /* here device_id is physical value */
+    device_id = iommu_get_devid_from_cmd(entry[0]);
+    bus = device_id >> 8;
+    devfn = device_id & 0xFF;
+
+    local_irq_enable();
+
+    spin_lock(&pcidevs_lock);
+    pdev = pci_get_pdev(0, bus, devfn);
+    spin_unlock(&pcidevs_lock);
+
+    local_irq_disable();
+
+    if ( pdev == NULL )
+        return; 
+
+    d = pdev->domain;
+
+    guest_iommu_add_ppr_log(d, entry);
+}
+
+static void iommu_check_ppr_log(struct amd_iommu *iommu)
+{
+    u32 entry;
+    unsigned long flags;
+
+    spin_lock_irqsave(&iommu->lock, flags);
+
+    iommu_read_log(iommu, &iommu->ppr_log, parse_ppr_log_entry);
+
+    /*check event overflow */
+    entry = readl(iommu->mmio_base + IOMMU_STATUS_MMIO_OFFSET);
+
+    if ( iommu_get_bit(entry, IOMMU_STATUS_PPR_LOG_OVERFLOW_SHIFT) )
+        iommu_reset_log(iommu, &iommu->ppr_log, set_iommu_ppr_log_control);
+
+    /* reset interrupt status bit */
+    entry = readl(iommu->mmio_base + IOMMU_STATUS_MMIO_OFFSET);
+    iommu_set_bit(&entry, IOMMU_STATUS_PPR_LOG_INT_SHIFT);
+
+    writel(entry, iommu->mmio_base + IOMMU_STATUS_MMIO_OFFSET);
+
+    spin_unlock_irqrestore(&iommu->lock, flags);
+}
+
+static void iommu_interrupt_handler(int irq, void *dev_id,
+                                    struct cpu_user_regs *regs)
+{
+    struct amd_iommu *iommu = dev_id;
+    iommu_check_event_log(iommu);
+
+    if ( iommu->ppr_log.buffer != NULL )
+        iommu_check_ppr_log(iommu);
+}
+
 static int __init set_iommu_interrupt_handler(struct amd_iommu *iommu)
 {
     int irq, ret;
@@ -628,8 +707,7 @@ static int __init set_iommu_interrupt_ha
     }
     
     irq_desc[irq].handler = &iommu_msi_type;
-    ret = request_irq(irq, amd_iommu_page_fault, 0,
-                             "amd_iommu", iommu);
+    ret = request_irq(irq, iommu_interrupt_handler, 0, "amd_iommu", iommu);
     if ( ret )
     {
         irq_desc[irq].handler = &no_irq_type;


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 23 11:32:20 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 Dec 2011 11:32:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Re3MH-0001fn-2D; Fri, 23 Dec 2011 11:32:17 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Wang2@amd.com>) id 1Re3MF-0001aV-CH
	for xen-devel@lists.xensource.com; Fri, 23 Dec 2011 11:32:15 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1324639880!8549102!1
X-Originating-IP: [216.32.181.185]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18289 invoked from network); 23 Dec 2011 11:31:21 -0000
Received: from ch1ehsobe005.messaging.microsoft.com (HELO
	ch1outboundpool.messaging.microsoft.com) (216.32.181.185)
	by server-6.tower-216.messagelabs.com with AES128-SHA encrypted SMTP;
	23 Dec 2011 11:31:21 -0000
Received: from mail169-ch1-R.bigfish.com (10.43.68.247) by
	CH1EHSOBE003.bigfish.com (10.43.70.53) with Microsoft SMTP Server id
	14.1.225.23; Fri, 23 Dec 2011 11:31:08 +0000
Received: from mail169-ch1 (localhost [127.0.0.1])	by
	mail169-ch1-R.bigfish.com (Postfix) with ESMTP id BA0B118024C;
	Fri, 23 Dec 2011 11:31:47 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzzz1202hzz8275bhz2dh668h839h944h)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
X-FB-SS: 13,
Received: from mail169-ch1 (localhost.localdomain [127.0.0.1]) by mail169-ch1
	(MessageSwitch) id 1324639907357266_9934;
	Fri, 23 Dec 2011 11:31:47 +0000 (UTC)
Received: from CH1EHSMHS025.bigfish.com (snatpool1.int.messaging.microsoft.com
	[10.43.68.254])	by mail169-ch1.bigfish.com (Postfix) with ESMTP id
	4B235320048;	Fri, 23 Dec 2011 11:31:47 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	CH1EHSMHS025.bigfish.com (10.43.70.25) with Microsoft SMTP Server id
	14.1.225.23; Fri, 23 Dec 2011 11:31:07 +0000
X-WSS-ID: 0LWNMO5-02-0XC-02
X-M-MSG: 
Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com
	[163.181.249.73])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp02.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2D71AC80D7;	Fri, 23 Dec 2011 05:31:16 -0600 (CST)
Received: from SAUSEXDAG02.amd.com (163.181.55.2) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Fri, 23 Dec 2011 05:31:35 -0600
Received: from storexhtp01.amd.com (172.24.4.3) by sausexdag02.amd.com
	(163.181.55.2) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Fri, 23 Dec 2011 05:31:17 -0600
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp01.amd.com
	(172.24.4.3) with Microsoft SMTP Server id 8.3.213.0; Fri, 23 Dec 2011
	06:30:43 -0500
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id E30A249C661; Fri, 23 Dec 2011
	11:30:41 +0000 (GMT)
Received: from gran.amd.com (gran.osrc.amd.com [165.204.15.57])	by
	mail.osrc.amd.com (Postfix) with ESMTP id C67DF594882; Fri, 23 Dec 2011
	12:30:41 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: bf9f21ad9a0ec245b409f3862a5a36c0e070f333
Message-ID: <bf9f21ad9a0ec245b409.1324639755@gran.amd.com>
In-Reply-To: <patchbomb.1324639749@gran.amd.com>
References: <patchbomb.1324639749@gran.amd.com>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Fri, 23 Dec 2011 12:29:15 +0100
From: Wei Wang <wei.wang2@amd.com>
To: <JBeulich@suse.com>, <Ian.Jackson@eu.citrix.com>,
	<Ian.Campbell@citrix.com>, <keir@xen.org>
X-OriginatorOrg: amd.com
Cc: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 06 of 16] amd iommu: add ppr log processing into
 iommu interrupt handling
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Wei Wang <wei.wang2@amd.com>
# Date 1324569388 -3600
# Node ID bf9f21ad9a0ec245b409f3862a5a36c0e070f333
# Parent  120144c1fac2dd26926b3b2a6362d30a4029620f
amd iommu: add ppr log processing into iommu interrupt handling
PPR log and event log share the same interrupt source. Interrupt handler
should check both of them.

Signed-off-by: Wei Wang <wei.wang2@amd.com>

diff -r 120144c1fac2 -r bf9f21ad9a0e xen/drivers/passthrough/amd/iommu_init.c
--- a/xen/drivers/passthrough/amd/iommu_init.c	Thu Dec 22 16:56:25 2011 +0100
+++ b/xen/drivers/passthrough/amd/iommu_init.c	Thu Dec 22 16:56:28 2011 +0100
@@ -352,75 +352,91 @@ static void set_iommu_ppr_log_control(st
         AMD_IOMMU_DEBUG("PPR Log Enabled.\n");
 }
 
-static void parse_event_log_entry(struct amd_iommu *, u32 entry[]);
+/* read event log or ppr log from iommu ring buffer */
+static int iommu_read_log(struct amd_iommu *iommu, 
+                          struct ring_buffer *log,
+                          void (*parse_func)(struct amd_iommu *, u32 *))
+{
+    u32 tail, head, *entry, tail_offest, head_offset;
 
-static int amd_iommu_read_event_log(struct amd_iommu *iommu)
-{
-    u32 tail, head, *event_log;
-
-    BUG_ON( !iommu );
+    BUG_ON( !iommu || ((log != &iommu->event_log) && 
+            (log != &iommu->ppr_log)) );
 
     /* make sure there's an entry in the log */
-    tail = readl(iommu->mmio_base + IOMMU_EVENT_LOG_TAIL_OFFSET);
-    tail = get_field_from_reg_u32(tail,
-                                  IOMMU_EVENT_LOG_TAIL_MASK,
-                                  IOMMU_EVENT_LOG_TAIL_SHIFT);
+    tail_offest = ( log == &iommu->event_log ) ?
+        IOMMU_EVENT_LOG_TAIL_OFFSET:
+        IOMMU_PPR_LOG_TAIL_OFFSET;
 
-    while ( tail != iommu->event_log.head )
+    head_offset = ( log == &iommu->event_log ) ?
+        IOMMU_EVENT_LOG_HEAD_OFFSET:
+        IOMMU_PPR_LOG_HEAD_OFFSET;
+
+    tail = readl(iommu->mmio_base + tail_offest);
+    tail = iommu_get_rb_pointer(tail);
+
+    while ( tail != log->head )
     {
         /* read event log entry */
-        event_log = (u32 *)(iommu->event_log.buffer +
-                           (iommu->event_log.head *
-                           IOMMU_EVENT_LOG_ENTRY_SIZE));
+        entry = (u32 *)(log->buffer + log->head * log->entry_size);
 
-        parse_event_log_entry(iommu, event_log);
-
-        if ( ++iommu->event_log.head == iommu->event_log.entries )
-            iommu->event_log.head = 0;
+        parse_func(iommu, entry);
+        if ( ++log->head == log->entries )
+            log->head = 0;
 
         /* update head pointer */
-        set_field_in_reg_u32(iommu->event_log.head, 0,
-                             IOMMU_EVENT_LOG_HEAD_MASK,
-                             IOMMU_EVENT_LOG_HEAD_SHIFT, &head);
-        writel(head, iommu->mmio_base + IOMMU_EVENT_LOG_HEAD_OFFSET);
+        head = 0;
+        iommu_set_rb_pointer(&head, log->head);
+
+        writel(head, iommu->mmio_base + head_offset);
     }
 
     return 0;
 }
 
-static void amd_iommu_reset_event_log(struct amd_iommu *iommu)
+/* reset event log or ppr log when overflow */
+static void iommu_reset_log(struct amd_iommu *iommu,
+                            struct ring_buffer *log,
+                            void (*ctrl_func)(struct amd_iommu *iommu, int))
 {
     u32 entry;
-    int log_run;
+    int log_run, run_bit, of_bit;
     int loop_count = 1000;
 
+    BUG_ON( !iommu || ((log != &iommu->event_log) && 
+            (log != &iommu->ppr_log)) );
+
+    run_bit = ( log == &iommu->event_log ) ?
+        IOMMU_STATUS_EVENT_LOG_RUN_SHIFT:
+        IOMMU_STATUS_PPR_LOG_RUN_SHIFT;
+
+    of_bit = ( log == &iommu->event_log ) ?
+        IOMMU_STATUS_EVENT_OVERFLOW_SHIFT:
+        IOMMU_STATUS_PPR_LOG_OVERFLOW_SHIFT;
+
     /* wait until EventLogRun bit = 0 */
     do {
         entry = readl(iommu->mmio_base + IOMMU_STATUS_MMIO_OFFSET);
-        log_run = iommu_get_bit(entry, IOMMU_STATUS_EVENT_LOG_RUN_SHIFT);
+        log_run = iommu_get_bit(entry, run_bit);
         loop_count--;
     } while ( log_run && loop_count );
 
     if ( log_run )
     {
-        AMD_IOMMU_DEBUG("Warning: EventLogRun bit is not cleared"
-                        "before reset!\n");
+        AMD_IOMMU_DEBUG("Warning: Log Run bit %d is not cleared"
+                        "before reset! \n", run_bit);
         return;
     }
 
-    set_iommu_event_log_control(iommu, IOMMU_CONTROL_DISABLED);
+    ctrl_func(iommu, IOMMU_CONTROL_DISABLED);
 
-    /* read event log for debugging */
-    amd_iommu_read_event_log(iommu);
     /*clear overflow bit */
-    iommu_clear_bit(&entry, IOMMU_STATUS_EVENT_OVERFLOW_SHIFT);
-
-    writel(entry, iommu->mmio_base+IOMMU_STATUS_MMIO_OFFSET);
+    iommu_clear_bit(&entry, of_bit);
+    writel(entry, iommu->mmio_base + IOMMU_STATUS_MMIO_OFFSET);
 
     /*reset event log base address */
-    iommu->event_log.head = 0;
+    log->head = 0;
 
-    set_iommu_event_log_control(iommu, IOMMU_CONTROL_ENABLED);
+    ctrl_func(iommu, IOMMU_CONTROL_ENABLED);
 }
 
 static void iommu_msi_set_affinity(struct irq_desc *desc, const cpumask_t *mask)
@@ -592,30 +608,93 @@ static void parse_event_log_entry(struct
     }
 }
 
-static void amd_iommu_page_fault(int irq, void *dev_id,
-                             struct cpu_user_regs *regs)
+static void iommu_check_event_log(struct amd_iommu *iommu)
 {
     u32 entry;
     unsigned long flags;
-    struct amd_iommu *iommu = dev_id;
 
     spin_lock_irqsave(&iommu->lock, flags);
-    amd_iommu_read_event_log(iommu);
+
+    iommu_read_log(iommu, &iommu->event_log, parse_event_log_entry);
 
     /*check event overflow */
     entry = readl(iommu->mmio_base + IOMMU_STATUS_MMIO_OFFSET);
 
     if ( iommu_get_bit(entry, IOMMU_STATUS_EVENT_OVERFLOW_SHIFT) )
-        amd_iommu_reset_event_log(iommu);
+        iommu_reset_log(iommu, &iommu->event_log, set_iommu_event_log_control);
 
     /* reset interrupt status bit */
     entry = readl(iommu->mmio_base + IOMMU_STATUS_MMIO_OFFSET);
     iommu_set_bit(&entry, IOMMU_STATUS_EVENT_LOG_INT_SHIFT);
 
-    writel(entry, iommu->mmio_base+IOMMU_STATUS_MMIO_OFFSET);
+    writel(entry, iommu->mmio_base + IOMMU_STATUS_MMIO_OFFSET);
+
     spin_unlock_irqrestore(&iommu->lock, flags);
 }
 
+void parse_ppr_log_entry(struct amd_iommu *iommu, u32 entry[])
+{
+
+    u16 device_id;
+    u8 bus, devfn;
+    struct pci_dev *pdev;
+    struct domain *d;
+
+    /* here device_id is physical value */
+    device_id = iommu_get_devid_from_cmd(entry[0]);
+    bus = device_id >> 8;
+    devfn = device_id & 0xFF;
+
+    local_irq_enable();
+
+    spin_lock(&pcidevs_lock);
+    pdev = pci_get_pdev(0, bus, devfn);
+    spin_unlock(&pcidevs_lock);
+
+    local_irq_disable();
+
+    if ( pdev == NULL )
+        return; 
+
+    d = pdev->domain;
+
+    guest_iommu_add_ppr_log(d, entry);
+}
+
+static void iommu_check_ppr_log(struct amd_iommu *iommu)
+{
+    u32 entry;
+    unsigned long flags;
+
+    spin_lock_irqsave(&iommu->lock, flags);
+
+    iommu_read_log(iommu, &iommu->ppr_log, parse_ppr_log_entry);
+
+    /*check event overflow */
+    entry = readl(iommu->mmio_base + IOMMU_STATUS_MMIO_OFFSET);
+
+    if ( iommu_get_bit(entry, IOMMU_STATUS_PPR_LOG_OVERFLOW_SHIFT) )
+        iommu_reset_log(iommu, &iommu->ppr_log, set_iommu_ppr_log_control);
+
+    /* reset interrupt status bit */
+    entry = readl(iommu->mmio_base + IOMMU_STATUS_MMIO_OFFSET);
+    iommu_set_bit(&entry, IOMMU_STATUS_PPR_LOG_INT_SHIFT);
+
+    writel(entry, iommu->mmio_base + IOMMU_STATUS_MMIO_OFFSET);
+
+    spin_unlock_irqrestore(&iommu->lock, flags);
+}
+
+static void iommu_interrupt_handler(int irq, void *dev_id,
+                                    struct cpu_user_regs *regs)
+{
+    struct amd_iommu *iommu = dev_id;
+    iommu_check_event_log(iommu);
+
+    if ( iommu->ppr_log.buffer != NULL )
+        iommu_check_ppr_log(iommu);
+}
+
 static int __init set_iommu_interrupt_handler(struct amd_iommu *iommu)
 {
     int irq, ret;
@@ -628,8 +707,7 @@ static int __init set_iommu_interrupt_ha
     }
     
     irq_desc[irq].handler = &iommu_msi_type;
-    ret = request_irq(irq, amd_iommu_page_fault, 0,
-                             "amd_iommu", iommu);
+    ret = request_irq(irq, iommu_interrupt_handler, 0, "amd_iommu", iommu);
     if ( ret )
     {
         irq_desc[irq].handler = &no_irq_type;


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 23 11:32:25 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 Dec 2011 11: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.xensource.com>)
	id 1Re3M8-0001Yz-Ee; Fri, 23 Dec 2011 11:32:08 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Wang2@amd.com>) id 1Re3M6-0001UB-4x
	for xen-devel@lists.xensource.com; Fri, 23 Dec 2011 11:32:06 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1324639918!8967840!1
X-Originating-IP: [216.32.181.181]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24453 invoked from network); 23 Dec 2011 11:31:59 -0000
Received: from ch1ehsobe001.messaging.microsoft.com (HELO
	ch1outboundpool.messaging.microsoft.com) (216.32.181.181)
	by server-11.tower-21.messagelabs.com with AES128-SHA encrypted SMTP;
	23 Dec 2011 11:31:59 -0000
Received: from mail187-ch1-R.bigfish.com (10.43.68.251) by
	CH1EHSOBE015.bigfish.com (10.43.70.65) with Microsoft SMTP Server id
	14.1.225.23; Fri, 23 Dec 2011 11:31:45 +0000
Received: from mail187-ch1 (localhost [127.0.0.1])	by
	mail187-ch1-R.bigfish.com (Postfix) with ESMTP id 470CB64009F;
	Fri, 23 Dec 2011 11:32:25 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzzz1202hzz8275bhz2dh668h839h944h)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
X-FB-SS: 0,
Received: from mail187-ch1 (localhost.localdomain [127.0.0.1]) by mail187-ch1
	(MessageSwitch) id 1324639905969764_820;
	Fri, 23 Dec 2011 11:31:45 +0000 (UTC)
Received: from CH1EHSMHS029.bigfish.com (snatpool1.int.messaging.microsoft.com
	[10.43.68.247])	by mail187-ch1.bigfish.com (Postfix) with ESMTP id
	E93AC140043;	Fri, 23 Dec 2011 11:31:45 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	CH1EHSMHS029.bigfish.com (10.43.70.29) with Microsoft SMTP Server id
	14.1.225.23; Fri, 23 Dec 2011 11:31:06 +0000
X-WSS-ID: 0LWNMO4-01-1GC-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 24EA610280A1;	Fri, 23 Dec 2011 05:31:14 -0600 (CST)
Received: from SAUSEXDAG02.amd.com (163.181.55.2) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Fri, 23 Dec 2011 05:31:33 -0600
Received: from storexhtp02.amd.com (172.24.4.4) by sausexdag02.amd.com
	(163.181.55.2) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Fri, 23 Dec 2011 05:31:15 -0600
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Fri, 23 Dec 2011
	06:30:43 -0500
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 0547E49C669; Fri, 23 Dec 2011
	11:30:43 +0000 (GMT)
Received: from gran.amd.com (gran.osrc.amd.com [165.204.15.57])	by
	mail.osrc.amd.com (Postfix) with ESMTP id F282D594885; Fri, 23 Dec 2011
	12:30:42 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 8ea73cd1a367b318f72026a02629c774d24f999f
Message-ID: <8ea73cd1a367b318f720.1324639764@gran.amd.com>
In-Reply-To: <patchbomb.1324639749@gran.amd.com>
References: <patchbomb.1324639749@gran.amd.com>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Fri, 23 Dec 2011 12:29:24 +0100
From: Wei Wang <wei.wang2@amd.com>
To: <JBeulich@suse.com>, <Ian.Jackson@eu.citrix.com>,
	<Ian.Campbell@citrix.com>, <keir@xen.org>
X-OriginatorOrg: amd.com
Cc: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 15 of 16] libxl: Introduce a new guest config
	file parameter
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Wei Wang <wei.wang2@amd.com>
# Date 1324569419 -3600
# Node ID 8ea73cd1a367b318f72026a02629c774d24f999f
# Parent  7ac92c11a11a4dbdf85ef503445128be861cb400
libxl: Introduce a new guest config file parameter
Use iommu = {1,0} to enable or disable guest iommu emulation.
Default value is 0.

Signed-off-by: Wei Wang <wei.wang2@amd.com>

diff -r 7ac92c11a11a -r 8ea73cd1a367 tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Thu Dec 22 16:56:55 2011 +0100
+++ b/tools/libxl/libxl_create.c	Thu Dec 22 16:56:59 2011 +0100
@@ -99,6 +99,7 @@ int libxl_init_build_info(libxl_ctx *ctx
         b_info->u.hvm.vpt_align = 1;
         b_info->u.hvm.timer_mode = 1;
         b_info->u.hvm.nested_hvm = 0;
+        b_info->u.hvm.iommu = 0;
         break;
     case LIBXL_DOMAIN_TYPE_PV:
         b_info->u.pv.slack_memkb = 8 * 1024;
diff -r 7ac92c11a11a -r 8ea73cd1a367 tools/libxl/libxl_dom.c
--- a/tools/libxl/libxl_dom.c	Thu Dec 22 16:56:55 2011 +0100
+++ b/tools/libxl/libxl_dom.c	Thu Dec 22 16:56:59 2011 +0100
@@ -266,6 +266,10 @@ static int hvm_build_set_params(xc_inter
     va_hvm = (struct hvm_info_table *)(va_map + HVM_INFO_OFFSET);
     va_hvm->apic_mode = info->u.hvm.apic;
     va_hvm->nr_vcpus = info->max_vcpus;
+
+    if ( info->u.hvm.iommu )
+         va_hvm->iommu_enabled = 1;
+
     memcpy(va_hvm->vcpu_online, &info->cur_vcpus, sizeof(info->cur_vcpus));
     for (i = 0, sum = 0; i < va_hvm->length; i++)
         sum += ((uint8_t *) va_hvm)[i];
diff -r 7ac92c11a11a -r 8ea73cd1a367 tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Thu Dec 22 16:56:55 2011 +0100
+++ b/tools/libxl/libxl_types.idl	Thu Dec 22 16:56:59 2011 +0100
@@ -184,6 +184,7 @@ libxl_domain_build_info = Struct("domain
                                        ("vpt_align", bool),
                                        ("timer_mode", integer),
                                        ("nested_hvm", bool),
+                                       ("iommu", bool),
                                        ])),
                  ("pv", Struct(None, [("kernel", libxl_file_reference),
                                       ("slack_memkb", uint32),
diff -r 7ac92c11a11a -r 8ea73cd1a367 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Thu Dec 22 16:56:55 2011 +0100
+++ b/tools/libxl/xl_cmdimpl.c	Thu Dec 22 16:56:59 2011 +0100
@@ -360,6 +360,7 @@ static void printf_info(int domid,
         printf("\t\t\t(vpt_align %d)\n", b_info->u.hvm.vpt_align);
         printf("\t\t\t(timer_mode %d)\n", b_info->u.hvm.timer_mode);
         printf("\t\t\t(nestedhvm %d)\n", b_info->u.hvm.nested_hvm);
+        printf("\t\t\t(iommu %d)\n", b_info->u.hvm.iommu);
 
         printf("\t\t\t(device_model %s)\n", dm_info->device_model ? : "default");
         printf("\t\t\t(videoram %d)\n", dm_info->videoram);
@@ -764,6 +765,8 @@ static void parse_config_data(const char
             b_info->u.hvm.timer_mode = l;
         if (!xlu_cfg_get_long (config, "nestedhvm", &l, 0))
             b_info->u.hvm.nested_hvm = l;
+        if (!xlu_cfg_get_long (config, "iommu", &l, 0))
+            b_info->u.hvm.iommu = l;
         break;
     case LIBXL_DOMAIN_TYPE_PV:
     {


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 23 11:32:25 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 Dec 2011 11: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.xensource.com>)
	id 1Re3M8-0001Yz-Ee; Fri, 23 Dec 2011 11:32:08 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Wang2@amd.com>) id 1Re3M6-0001UB-4x
	for xen-devel@lists.xensource.com; Fri, 23 Dec 2011 11:32:06 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1324639918!8967840!1
X-Originating-IP: [216.32.181.181]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24453 invoked from network); 23 Dec 2011 11:31:59 -0000
Received: from ch1ehsobe001.messaging.microsoft.com (HELO
	ch1outboundpool.messaging.microsoft.com) (216.32.181.181)
	by server-11.tower-21.messagelabs.com with AES128-SHA encrypted SMTP;
	23 Dec 2011 11:31:59 -0000
Received: from mail187-ch1-R.bigfish.com (10.43.68.251) by
	CH1EHSOBE015.bigfish.com (10.43.70.65) with Microsoft SMTP Server id
	14.1.225.23; Fri, 23 Dec 2011 11:31:45 +0000
Received: from mail187-ch1 (localhost [127.0.0.1])	by
	mail187-ch1-R.bigfish.com (Postfix) with ESMTP id 470CB64009F;
	Fri, 23 Dec 2011 11:32:25 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzzz1202hzz8275bhz2dh668h839h944h)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
X-FB-SS: 0,
Received: from mail187-ch1 (localhost.localdomain [127.0.0.1]) by mail187-ch1
	(MessageSwitch) id 1324639905969764_820;
	Fri, 23 Dec 2011 11:31:45 +0000 (UTC)
Received: from CH1EHSMHS029.bigfish.com (snatpool1.int.messaging.microsoft.com
	[10.43.68.247])	by mail187-ch1.bigfish.com (Postfix) with ESMTP id
	E93AC140043;	Fri, 23 Dec 2011 11:31:45 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	CH1EHSMHS029.bigfish.com (10.43.70.29) with Microsoft SMTP Server id
	14.1.225.23; Fri, 23 Dec 2011 11:31:06 +0000
X-WSS-ID: 0LWNMO4-01-1GC-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 24EA610280A1;	Fri, 23 Dec 2011 05:31:14 -0600 (CST)
Received: from SAUSEXDAG02.amd.com (163.181.55.2) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Fri, 23 Dec 2011 05:31:33 -0600
Received: from storexhtp02.amd.com (172.24.4.4) by sausexdag02.amd.com
	(163.181.55.2) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Fri, 23 Dec 2011 05:31:15 -0600
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Fri, 23 Dec 2011
	06:30:43 -0500
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 0547E49C669; Fri, 23 Dec 2011
	11:30:43 +0000 (GMT)
Received: from gran.amd.com (gran.osrc.amd.com [165.204.15.57])	by
	mail.osrc.amd.com (Postfix) with ESMTP id F282D594885; Fri, 23 Dec 2011
	12:30:42 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 8ea73cd1a367b318f72026a02629c774d24f999f
Message-ID: <8ea73cd1a367b318f720.1324639764@gran.amd.com>
In-Reply-To: <patchbomb.1324639749@gran.amd.com>
References: <patchbomb.1324639749@gran.amd.com>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Fri, 23 Dec 2011 12:29:24 +0100
From: Wei Wang <wei.wang2@amd.com>
To: <JBeulich@suse.com>, <Ian.Jackson@eu.citrix.com>,
	<Ian.Campbell@citrix.com>, <keir@xen.org>
X-OriginatorOrg: amd.com
Cc: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 15 of 16] libxl: Introduce a new guest config
	file parameter
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Wei Wang <wei.wang2@amd.com>
# Date 1324569419 -3600
# Node ID 8ea73cd1a367b318f72026a02629c774d24f999f
# Parent  7ac92c11a11a4dbdf85ef503445128be861cb400
libxl: Introduce a new guest config file parameter
Use iommu = {1,0} to enable or disable guest iommu emulation.
Default value is 0.

Signed-off-by: Wei Wang <wei.wang2@amd.com>

diff -r 7ac92c11a11a -r 8ea73cd1a367 tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Thu Dec 22 16:56:55 2011 +0100
+++ b/tools/libxl/libxl_create.c	Thu Dec 22 16:56:59 2011 +0100
@@ -99,6 +99,7 @@ int libxl_init_build_info(libxl_ctx *ctx
         b_info->u.hvm.vpt_align = 1;
         b_info->u.hvm.timer_mode = 1;
         b_info->u.hvm.nested_hvm = 0;
+        b_info->u.hvm.iommu = 0;
         break;
     case LIBXL_DOMAIN_TYPE_PV:
         b_info->u.pv.slack_memkb = 8 * 1024;
diff -r 7ac92c11a11a -r 8ea73cd1a367 tools/libxl/libxl_dom.c
--- a/tools/libxl/libxl_dom.c	Thu Dec 22 16:56:55 2011 +0100
+++ b/tools/libxl/libxl_dom.c	Thu Dec 22 16:56:59 2011 +0100
@@ -266,6 +266,10 @@ static int hvm_build_set_params(xc_inter
     va_hvm = (struct hvm_info_table *)(va_map + HVM_INFO_OFFSET);
     va_hvm->apic_mode = info->u.hvm.apic;
     va_hvm->nr_vcpus = info->max_vcpus;
+
+    if ( info->u.hvm.iommu )
+         va_hvm->iommu_enabled = 1;
+
     memcpy(va_hvm->vcpu_online, &info->cur_vcpus, sizeof(info->cur_vcpus));
     for (i = 0, sum = 0; i < va_hvm->length; i++)
         sum += ((uint8_t *) va_hvm)[i];
diff -r 7ac92c11a11a -r 8ea73cd1a367 tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Thu Dec 22 16:56:55 2011 +0100
+++ b/tools/libxl/libxl_types.idl	Thu Dec 22 16:56:59 2011 +0100
@@ -184,6 +184,7 @@ libxl_domain_build_info = Struct("domain
                                        ("vpt_align", bool),
                                        ("timer_mode", integer),
                                        ("nested_hvm", bool),
+                                       ("iommu", bool),
                                        ])),
                  ("pv", Struct(None, [("kernel", libxl_file_reference),
                                       ("slack_memkb", uint32),
diff -r 7ac92c11a11a -r 8ea73cd1a367 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Thu Dec 22 16:56:55 2011 +0100
+++ b/tools/libxl/xl_cmdimpl.c	Thu Dec 22 16:56:59 2011 +0100
@@ -360,6 +360,7 @@ static void printf_info(int domid,
         printf("\t\t\t(vpt_align %d)\n", b_info->u.hvm.vpt_align);
         printf("\t\t\t(timer_mode %d)\n", b_info->u.hvm.timer_mode);
         printf("\t\t\t(nestedhvm %d)\n", b_info->u.hvm.nested_hvm);
+        printf("\t\t\t(iommu %d)\n", b_info->u.hvm.iommu);
 
         printf("\t\t\t(device_model %s)\n", dm_info->device_model ? : "default");
         printf("\t\t\t(videoram %d)\n", dm_info->videoram);
@@ -764,6 +765,8 @@ static void parse_config_data(const char
             b_info->u.hvm.timer_mode = l;
         if (!xlu_cfg_get_long (config, "nestedhvm", &l, 0))
             b_info->u.hvm.nested_hvm = l;
+        if (!xlu_cfg_get_long (config, "iommu", &l, 0))
+            b_info->u.hvm.iommu = l;
         break;
     case LIBXL_DOMAIN_TYPE_PV:
     {


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 23 11:32:31 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 Dec 2011 11:32:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Re3MP-0001mC-H6; Fri, 23 Dec 2011 11:32:25 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Re3MN-0001gK-63
	for xen-devel@lists.xensource.com; Fri, 23 Dec 2011 11:32:23 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1324639935!8434070!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18293 invoked from network); 23 Dec 2011 11:32:16 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-3.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 23 Dec 2011 11:32:16 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 23 Dec 2011 11:32:15 +0000
Message-Id: <4EF475060200007800069C65@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 23 Dec 2011 11:33:10 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part527DE5E6.0__="
Subject: [Xen-devel] [PATCH] linux-2.6.18/blktap: fix locking (again)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__Part527DE5E6.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

c/s 1090 wasn't really helping much - I was doing that under the wrong
impression that the zap_pte() hook would be called with the mmap_sem
held. That being wrong, none of the uses of mmap_sem here actually are
write ones (they only look up vma information), so convert them all to
read acquires/releases.

A new spinlock needs to be introduced, protecting idx_map. This has to
nest inside mmap_sem, which requires some code movement.

--- a/drivers/xen/blktap/blktap.c
+++ b/drivers/xen/blktap/blktap.c
@@ -113,6 +113,7 @@ typedef struct tap_blkif {
 	pid_t pid;                    /*tapdisk process id                 =
  */
 	enum { RUNNING, CLEANSHUTDOWN } status; /*Detect a clean =
userspace=20
 						  shutdown                 =
  */
+	spinlock_t map_lock;          /*protects idx_map                   =
  */
 	struct idx_map {
 		u16 mem, req;
 	} *idx_map;                   /*Record the user ring id to kern
@@ -295,7 +296,7 @@ static pte_t blktap_clear_pte(struct vm_
 	pte_t copy;
 	tap_blkif_t *info =3D NULL;
 	unsigned int seg, usr_idx, pending_idx, mmap_idx, count =3D 0;
-	unsigned long offset, uvstart =3D 0;
+	unsigned long offset;
 	struct page *pg;
 	struct grant_handle_pair *khandle;
 	struct gnttab_unmap_grant_ref unmap[2];
@@ -304,25 +305,28 @@ static pte_t blktap_clear_pte(struct vm_
 	 * If the address is before the start of the grant mapped region =
or
 	 * if vm_file is NULL (meaning mmap failed and we have nothing to =
do)
 	 */
-	if (vma->vm_file !=3D NULL) {
+	if (vma->vm_file !=3D NULL)
 		info =3D vma->vm_file->private_data;
-		uvstart =3D info->rings_vstart + (RING_PAGES << PAGE_SHIFT)=
;
-	}
-	if (vma->vm_file =3D=3D NULL || uvaddr < uvstart)
+	if (info =3D=3D NULL || uvaddr < info->user_vstart)
 		return ptep_get_and_clear_full(vma->vm_mm, uvaddr,=20
 					       ptep, is_fullmm);
=20
-	/* TODO Should these be changed to if statements? */
-	BUG_ON(!info);
-	BUG_ON(!info->idx_map);
-
-	offset =3D (uvaddr - uvstart) >> PAGE_SHIFT;
+	offset =3D (uvaddr - info->user_vstart) >> PAGE_SHIFT;
 	usr_idx =3D OFFSET_TO_USR_IDX(offset);
 	seg =3D OFFSET_TO_SEG(offset);
=20
+	spin_lock(&info->map_lock);
+
 	pending_idx =3D info->idx_map[usr_idx].req;
 	mmap_idx =3D info->idx_map[usr_idx].mem;
=20
+	/* fast_flush_area() may already have cleared this entry */
+	if (mmap_idx =3D=3D INVALID_MIDX) {
+		spin_unlock(&info->map_lock);
+		return ptep_get_and_clear_full(vma->vm_mm, uvaddr, ptep,
+					       is_fullmm);
+	}
+
 	pg =3D idx_to_page(mmap_idx, pending_idx, seg);
 	ClearPageReserved(pg);
 	info->foreign_map.map[offset + RING_PAGES] =3D NULL;
@@ -365,6 +369,8 @@ static pte_t blktap_clear_pte(struct vm_
 			BUG();
 	}
=20
+	spin_unlock(&info->map_lock);
+
 	return copy;
 }
=20
@@ -489,6 +495,7 @@ found:
 		}
=20
 		info->minor =3D minor;
+		spin_lock_init(&info->map_lock);
 		/*
 		 * Make sure that we have a minor before others can
 		 * see us.
@@ -1029,25 +1036,30 @@ static void fast_flush_area(pending_req_
 			     unsigned int u_idx, tap_blkif_t *info)
 {
 	struct gnttab_unmap_grant_ref unmap[BLKIF_MAX_SEGMENTS_PER_REQUEST*=
2];
-	unsigned int i, mmap_idx, invcount =3D 0, locked =3D 0;
+	unsigned int i, mmap_idx, invcount =3D 0;
 	struct grant_handle_pair *khandle;
 	uint64_t ptep;
 	int ret;
 	unsigned long uvaddr;
 	struct mm_struct *mm =3D info->mm;
=20
+	if (mm !=3D NULL)
+		down_read(&mm->mmap_sem);
+
 	if (mm !=3D NULL && xen_feature(XENFEAT_auto_translated_physmap)) =
{
-		down_write(&mm->mmap_sem);
+ slow:
 		blktap_zap_page_range(mm,
 				      MMAP_VADDR(info->user_vstart, u_idx, =
0),
 				      req->nr_pages);
 		info->idx_map[u_idx].mem =3D INVALID_MIDX;
-		up_write(&mm->mmap_sem);
+		up_read(&mm->mmap_sem);
 		return;
 	}
=20
 	mmap_idx =3D req->mem_idx;
=20
+	spin_lock(&info->map_lock);
+
 	for (i =3D 0; i < req->nr_pages; i++) {
 		uvaddr =3D MMAP_VADDR(info->user_vstart, u_idx, i);
=20
@@ -1066,15 +1078,13 @@ static void fast_flush_area(pending_req_
=20
 		if (mm !=3D NULL && khandle->user !=3D INVALID_GRANT_HANDLE=
) {
 			BUG_ON(xen_feature(XENFEAT_auto_translated_physmap)=
);
-			if (!locked++)
-				down_write(&mm->mmap_sem);
 			if (create_lookup_pte_addr(
 				mm,
 				MMAP_VADDR(info->user_vstart, u_idx, i),
 				&ptep) !=3D0) {
-				up_write(&mm->mmap_sem);
+				spin_unlock(&info->map_lock);
 				WPRINTK("Couldn't get a pte addr!\n");
-				return;
+				goto slow;
 			}
=20
 			gnttab_set_unmap_op(&unmap[invcount], ptep,
@@ -1091,19 +1101,11 @@ static void fast_flush_area(pending_req_
 		GNTTABOP_unmap_grant_ref, unmap, invcount);
 	BUG_ON(ret);
 =09
-	if (mm !=3D NULL && !xen_feature(XENFEAT_auto_translated_physmap)) =
{
-		if (!locked++)
-			down_write(&mm->mmap_sem);
-		blktap_zap_page_range(mm,=20
-				      MMAP_VADDR(info->user_vstart, u_idx, =
0),=20
-				      req->nr_pages);
-	}
-
-	if (!locked && mm !=3D NULL)
-		down_write(&mm->mmap_sem);
 	info->idx_map[u_idx].mem =3D INVALID_MIDX;
+
+	spin_unlock(&info->map_lock);
 	if (mm !=3D NULL)
-		up_write(&mm->mmap_sem);
+		up_read(&mm->mmap_sem);
 }
=20
 /******************************************************************
@@ -1406,7 +1408,9 @@ static void dispatch_rw_block_io(blkif_t
 		goto fail_response;
=20
 	/* Check we have space on user ring - should never fail. */
+	spin_lock(&info->map_lock);
 	usr_idx =3D GET_NEXT_REQ(info->idx_map);
+	spin_unlock(&info->map_lock);
 	if (usr_idx >=3D MAX_PENDING_REQS) {
 		WARN_ON(1);
 		goto fail_response;
@@ -1445,7 +1449,7 @@ static void dispatch_rw_block_io(blkif_t
 	op =3D 0;
 	mm =3D info->mm;
 	if (!xen_feature(XENFEAT_auto_translated_physmap))
-		down_write(&mm->mmap_sem);
+		down_read(&mm->mmap_sem);
 	for (i =3D 0; i < nseg; i++) {
 		unsigned long uvaddr;
 		unsigned long kvaddr;
@@ -1462,9 +1466,9 @@ static void dispatch_rw_block_io(blkif_t
 			/* Now map it to user. */
 			ret =3D create_lookup_pte_addr(mm, uvaddr, &ptep);
 			if (ret) {
-				up_write(&mm->mmap_sem);
+				up_read(&mm->mmap_sem);
 				WPRINTK("Couldn't get a pte addr!\n");
-				goto fail_flush;
+				goto fail_response;
 			}
=20
 			gnttab_set_map_op(&map[op], ptep,
@@ -1478,12 +1482,15 @@ static void dispatch_rw_block_io(blkif_t
 			     req->seg[i].first_sect + 1);
 	}
=20
+	if (xen_feature(XENFEAT_auto_translated_physmap))
+		down_read(&mm->mmap_sem);
+
+	spin_lock(&info->map_lock);
+
 	ret =3D HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, map, =
op);
 	BUG_ON(ret);
=20
 	if (!xen_feature(XENFEAT_auto_translated_physmap)) {
-		up_write(&mm->mmap_sem);
-
 		for (i =3D 0; i < (nseg*2); i+=3D2) {
 			unsigned long uvaddr;
 			unsigned long offset;
@@ -1548,18 +1555,18 @@ static void dispatch_rw_block_io(blkif_t
 		}
 	}
=20
+	/*record [mmap_idx,pending_idx] to [usr_idx] mapping*/
+	info->idx_map[usr_idx].mem =3D mmap_idx;
+	info->idx_map[usr_idx].req =3D pending_idx;
+
+	spin_unlock(&info->map_lock);
+
 	if (ret)
 		goto fail_flush;
=20
-	if (xen_feature(XENFEAT_auto_translated_physmap))
-		down_write(&mm->mmap_sem);
-	/* Mark mapped pages as reserved: */
-	for (i =3D 0; i < req->nr_segments; i++) {
-		struct page *pg;
-
-		pg =3D idx_to_page(mmap_idx, pending_idx, i);
-		SetPageReserved(pg);
-		if (xen_feature(XENFEAT_auto_translated_physmap)) {
+	if (xen_feature(XENFEAT_auto_translated_physmap)) {
+		for (i =3D 0; i < nseg; i++) {
+			struct page *pg =3D idx_to_page(mmap_idx, =
pending_idx, i);
 			unsigned long uvaddr =3D MMAP_VADDR(info->user_vsta=
rt,
 							  usr_idx, i);
 			if (vma && uvaddr >=3D vma->vm_end) {
@@ -1577,18 +1584,12 @@ static void dispatch_rw_block_io(blkif_t
 					continue;
 			}
 			ret =3D vm_insert_page(vma, uvaddr, pg);
-			if (ret) {
-				up_write(&mm->mmap_sem);
+			if (ret)
 				goto fail_flush;
-			}
 		}
 	}
-	if (xen_feature(XENFEAT_auto_translated_physmap))
-		up_write(&mm->mmap_sem);
 =09
-	/*record [mmap_idx,pending_idx] to [usr_idx] mapping*/
-	info->idx_map[usr_idx].mem =3D mmap_idx;
-	info->idx_map[usr_idx].req =3D pending_idx;
+	up_read(&mm->mmap_sem);
=20
 	blkif_get(blkif);
 	/* Finally, write the request message to the user ring. */
@@ -1611,6 +1612,7 @@ static void dispatch_rw_block_io(blkif_t
 	return;
=20
  fail_flush:
+	up_read(&mm->mmap_sem);
 	WPRINTK("Reached Fail_flush\n");
 	fast_flush_area(pending_req, pending_idx, usr_idx, info);
  fail_response:


--=__Part527DE5E6.0__=
Content-Type: text/plain; name="xen-blktap-locking.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="xen-blktap-locking.patch"

blktap: fix locking (again)=0A=0Ac/s 1090 wasn't really helping much - I =
was doing that under the wrong=0Aimpression that the zap_pte() hook would =
be called with the mmap_sem=0Aheld. That being wrong, none of the uses of =
mmap_sem here actually are=0Awrite ones (they only look up vma information)=
, so convert them all to=0Aread acquires/releases.=0A=0AA new spinlock =
needs to be introduced, protecting idx_map. This has to=0Anest inside =
mmap_sem, which requires some code movement.=0A=0A--- a/drivers/xen/blktap/=
blktap.c=0A+++ b/drivers/xen/blktap/blktap.c=0A@@ -113,6 +113,7 @@ typedef =
struct tap_blkif {=0A 	pid_t pid;                    /*tapdisk process id =
                  */=0A 	enum { RUNNING, CLEANSHUTDOWN } status; =
/*Detect a clean userspace =0A 						  =
shutdown                   */=0A+	spinlock_t map_lock;          =
/*protects idx_map                     */=0A 	struct idx_map {=0A 		=
u16 mem, req;=0A 	} *idx_map;                   /*Record the user =
ring id to kern=0A@@ -295,7 +296,7 @@ static pte_t blktap_clear_pte(struct =
vm_=0A 	pte_t copy;=0A 	tap_blkif_t *info =3D NULL;=0A 	unsigned int seg, =
usr_idx, pending_idx, mmap_idx, count =3D 0;=0A-	unsigned long =
offset, uvstart =3D 0;=0A+	unsigned long offset;=0A 	struct =
page *pg;=0A 	struct grant_handle_pair *khandle;=0A 	struct gnttab_unmap=
_grant_ref unmap[2];=0A@@ -304,25 +305,28 @@ static pte_t blktap_clear_pte(=
struct vm_=0A 	 * If the address is before the start of the grant mapped =
region or=0A 	 * if vm_file is NULL (meaning mmap failed and we have =
nothing to do)=0A 	 */=0A-	if (vma->vm_file !=3D NULL) {=0A+	if =
(vma->vm_file !=3D NULL)=0A 		info =3D vma->vm_file->private_data=
;=0A-		uvstart =3D info->rings_vstart + (RING_PAGES << PAGE_SHIFT)=
;=0A-	}=0A-	if (vma->vm_file =3D=3D NULL || uvaddr < uvstart)=0A+	if =
(info =3D=3D NULL || uvaddr < info->user_vstart)=0A 		return =
ptep_get_and_clear_full(vma->vm_mm, uvaddr, =0A 				=
	       ptep, is_fullmm);=0A =0A-	/* TODO Should these be =
changed to if statements? */=0A-	BUG_ON(!info);=0A-	BUG_ON(!inf=
o->idx_map);=0A-=0A-	offset =3D (uvaddr - uvstart) >> PAGE_SHIFT;=0A+	=
offset =3D (uvaddr - info->user_vstart) >> PAGE_SHIFT;=0A 	usr_idx =
=3D OFFSET_TO_USR_IDX(offset);=0A 	seg =3D OFFSET_TO_SEG(offset);=0A =
=0A+	spin_lock(&info->map_lock);=0A+=0A 	pending_idx =3D info->idx_m=
ap[usr_idx].req;=0A 	mmap_idx =3D info->idx_map[usr_idx].mem;=0A =0A+	=
/* fast_flush_area() may already have cleared this entry */=0A+	if =
(mmap_idx =3D=3D INVALID_MIDX) {=0A+		spin_unlock(&info->map_lock=
);=0A+		return ptep_get_and_clear_full(vma->vm_mm, uvaddr, =
ptep,=0A+					       is_fullmm);=0A+	=
}=0A+=0A 	pg =3D idx_to_page(mmap_idx, pending_idx, seg);=0A 	=
ClearPageReserved(pg);=0A 	info->foreign_map.map[offset + RING_PAGES] =
=3D NULL;=0A@@ -365,6 +369,8 @@ static pte_t blktap_clear_pte(struct =
vm_=0A 			BUG();=0A 	}=0A =0A+	spin_unlock(&info->=
map_lock);=0A+=0A 	return copy;=0A }=0A =0A@@ -489,6 +495,7 @@ =
found:=0A 		}=0A =0A 		info->minor =3D minor;=0A+	=
	spin_lock_init(&info->map_lock);=0A 		/*=0A 		 * =
Make sure that we have a minor before others can=0A 		 * see =
us.=0A@@ -1029,25 +1036,30 @@ static void fast_flush_area(pending_req_=0A 	=
		     unsigned int u_idx, tap_blkif_t *info)=0A {=0A 	=
struct gnttab_unmap_grant_ref unmap[BLKIF_MAX_SEGMENTS_PER_REQUEST*2];=0A-	=
unsigned int i, mmap_idx, invcount =3D 0, locked =3D 0;=0A+	unsigned =
int i, mmap_idx, invcount =3D 0;=0A 	struct grant_handle_pair =
*khandle;=0A 	uint64_t ptep;=0A 	int ret;=0A 	unsigned long =
uvaddr;=0A 	struct mm_struct *mm =3D info->mm;=0A =0A+	if (mm =
!=3D NULL)=0A+		down_read(&mm->mmap_sem);=0A+=0A 	if (mm =
!=3D NULL && xen_feature(XENFEAT_auto_translated_physmap)) {=0A-		=
down_write(&mm->mmap_sem);=0A+ slow:=0A 		blktap_zap_page_ran=
ge(mm,=0A 				      MMAP_VADDR(info->user_vstart,=
 u_idx, 0),=0A 				      req->nr_pages);=0A 		=
info->idx_map[u_idx].mem =3D INVALID_MIDX;=0A-		up_write(&mm->mmap_=
sem);=0A+		up_read(&mm->mmap_sem);=0A 		return;=0A =
	}=0A =0A 	mmap_idx =3D req->mem_idx;=0A =0A+	spin_lock(&=
info->map_lock);=0A+=0A 	for (i =3D 0; i < req->nr_pages; i++) {=0A =
		uvaddr =3D MMAP_VADDR(info->user_vstart, u_idx, i);=0A =
=0A@@ -1066,15 +1078,13 @@ static void fast_flush_area(pending_req_=0A =0A =
		if (mm !=3D NULL && khandle->user !=3D INVALID_GRANT_HANDLE=
) {=0A 			BUG_ON(xen_feature(XENFEAT_auto_translated_physmap)=
);=0A-			if (!locked++)=0A-				=
down_write(&mm->mmap_sem);=0A 			if (create_lookup_pte_addr(=
=0A 				mm,=0A 				MMAP_VADDR(=
info->user_vstart, u_idx, i),=0A 				&ptep) =
!=3D0) {=0A-				up_write(&mm->mmap_sem);=0A+		=
		spin_unlock(&info->map_lock);=0A 				=
WPRINTK("Couldn't get a pte addr!\n");=0A-				=
return;=0A+				goto slow;=0A 			=
}=0A =0A 			gnttab_set_unmap_op(&unmap[invcount], =
ptep,=0A@@ -1091,19 +1101,11 @@ static void fast_flush_area(pending_req_=0A=
 		GNTTABOP_unmap_grant_ref, unmap, invcount);=0A 	BUG_ON(ret)=
;=0A 	=0A-	if (mm !=3D NULL && !xen_feature(XENFEAT_auto_translated_ph=
ysmap)) {=0A-		if (!locked++)=0A-			down_write(=
&mm->mmap_sem);=0A-		blktap_zap_page_range(mm, =0A-			=
	      MMAP_VADDR(info->user_vstart, u_idx, 0), =0A-			=
	      req->nr_pages);=0A-	}=0A-=0A-	if (!locked && mm =
!=3D NULL)=0A-		down_write(&mm->mmap_sem);=0A 	info->idx_map[u_idx=
].mem =3D INVALID_MIDX;=0A+=0A+	spin_unlock(&info->map_lock);=0A 	if =
(mm !=3D NULL)=0A-		up_write(&mm->mmap_sem);=0A+		=
up_read(&mm->mmap_sem);=0A }=0A =0A /**************************************=
****************************=0A@@ -1406,7 +1408,9 @@ static void dispatch_r=
w_block_io(blkif_t=0A 		goto fail_response;=0A =0A 	/* Check =
we have space on user ring - should never fail. */=0A+	spin_lock(&info->ma=
p_lock);=0A 	usr_idx =3D GET_NEXT_REQ(info->idx_map);=0A+	spin_unlock=
(&info->map_lock);=0A 	if (usr_idx >=3D MAX_PENDING_REQS) {=0A 		=
WARN_ON(1);=0A 		goto fail_response;=0A@@ -1445,7 +1449,7 @@ static =
void dispatch_rw_block_io(blkif_t=0A 	op =3D 0;=0A 	mm =3D info->mm;=0A=
 	if (!xen_feature(XENFEAT_auto_translated_physmap))=0A-		=
down_write(&mm->mmap_sem);=0A+		down_read(&mm->mmap_sem);=0A 	=
for (i =3D 0; i < nseg; i++) {=0A 		unsigned long uvaddr;=0A 	=
	unsigned long kvaddr;=0A@@ -1462,9 +1466,9 @@ static void =
dispatch_rw_block_io(blkif_t=0A 			/* Now map it to =
user. */=0A 			ret =3D create_lookup_pte_addr(mm, uvaddr, =
&ptep);=0A 			if (ret) {=0A-				=
up_write(&mm->mmap_sem);=0A+				up_read(&mm->mmap_s=
em);=0A 				WPRINTK("Couldn't get a pte =
addr!\n");=0A-				goto fail_flush;=0A+			=
	goto fail_response;=0A 			}=0A =0A 			=
gnttab_set_map_op(&map[op], ptep,=0A@@ -1478,12 +1482,15 @@ static void =
dispatch_rw_block_io(blkif_t=0A 			     req->seg[i].fi=
rst_sect + 1);=0A 	}=0A =0A+	if (xen_feature(XENFEAT_auto_transl=
ated_physmap))=0A+		down_read(&mm->mmap_sem);=0A+=0A+	=
spin_lock(&info->map_lock);=0A+=0A 	ret =3D HYPERVISOR_grant_table_op(G=
NTTABOP_map_grant_ref, map, op);=0A 	BUG_ON(ret);=0A =0A 	if =
(!xen_feature(XENFEAT_auto_translated_physmap)) {=0A-		up_write(&m=
m->mmap_sem);=0A-=0A 		for (i =3D 0; i < (nseg*2); i+=3D2) {=0A 	=
		unsigned long uvaddr;=0A 			unsigned =
long offset;=0A@@ -1548,18 +1555,18 @@ static void dispatch_rw_block_io(blk=
if_t=0A 		}=0A 	}=0A =0A+	/*record [mmap_idx,pending_=
idx] to [usr_idx] mapping*/=0A+	info->idx_map[usr_idx].mem =3D mmap_idx;=0A=
+	info->idx_map[usr_idx].req =3D pending_idx;=0A+=0A+	spin_unlock=
(&info->map_lock);=0A+=0A 	if (ret)=0A 		goto fail_flush;=0A=
 =0A-	if (xen_feature(XENFEAT_auto_translated_physmap))=0A-		=
down_write(&mm->mmap_sem);=0A-	/* Mark mapped pages as reserved: */=0A-	=
for (i =3D 0; i < req->nr_segments; i++) {=0A-		struct page =
*pg;=0A-=0A-		pg =3D idx_to_page(mmap_idx, pending_idx, i);=0A-	=
	SetPageReserved(pg);=0A-		if (xen_feature(XENFEAT_aut=
o_translated_physmap)) {=0A+	if (xen_feature(XENFEAT_auto_translated_phy=
smap)) {=0A+		for (i =3D 0; i < nseg; i++) {=0A+			=
struct page *pg =3D idx_to_page(mmap_idx, pending_idx, i);=0A 			=
unsigned long uvaddr =3D MMAP_VADDR(info->user_vstart,=0A 			=
				  usr_idx, i);=0A 			if =
(vma && uvaddr >=3D vma->vm_end) {=0A@@ -1577,18 +1584,12 @@ static void =
dispatch_rw_block_io(blkif_t=0A 					=
continue;=0A 			}=0A 			ret =3D vm_insert_p=
age(vma, uvaddr, pg);=0A-			if (ret) {=0A-			=
	up_write(&mm->mmap_sem);=0A+			if (ret)=0A 		=
		goto fail_flush;=0A-			}=0A 		=
}=0A 	}=0A-	if (xen_feature(XENFEAT_auto_translated_physmap))=0A-		=
up_write(&mm->mmap_sem);=0A 	=0A-	/*record [mmap_idx,pending_idx] to =
[usr_idx] mapping*/=0A-	info->idx_map[usr_idx].mem =3D mmap_idx;=0A-	=
info->idx_map[usr_idx].req =3D pending_idx;=0A+	up_read(&mm->mmap_sem);=0A =
=0A 	blkif_get(blkif);=0A 	/* Finally, write the request message to =
the user ring. */=0A@@ -1611,6 +1612,7 @@ static void dispatch_rw_block_io(=
blkif_t=0A 	return;=0A =0A  fail_flush:=0A+	up_read(&mm->mmap_sem);=0A =
	WPRINTK("Reached Fail_flush\n");=0A 	fast_flush_area(pending_req=
, pending_idx, usr_idx, info);=0A  fail_response:=0A
--=__Part527DE5E6.0__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--=__Part527DE5E6.0__=--


From xen-devel-bounces@lists.xensource.com Fri Dec 23 11:32:31 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 Dec 2011 11:32:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Re3MP-0001mC-H6; Fri, 23 Dec 2011 11:32:25 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Re3MN-0001gK-63
	for xen-devel@lists.xensource.com; Fri, 23 Dec 2011 11:32:23 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1324639935!8434070!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18293 invoked from network); 23 Dec 2011 11:32:16 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-3.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 23 Dec 2011 11:32:16 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 23 Dec 2011 11:32:15 +0000
Message-Id: <4EF475060200007800069C65@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 23 Dec 2011 11:33:10 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part527DE5E6.0__="
Subject: [Xen-devel] [PATCH] linux-2.6.18/blktap: fix locking (again)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__Part527DE5E6.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

c/s 1090 wasn't really helping much - I was doing that under the wrong
impression that the zap_pte() hook would be called with the mmap_sem
held. That being wrong, none of the uses of mmap_sem here actually are
write ones (they only look up vma information), so convert them all to
read acquires/releases.

A new spinlock needs to be introduced, protecting idx_map. This has to
nest inside mmap_sem, which requires some code movement.

--- a/drivers/xen/blktap/blktap.c
+++ b/drivers/xen/blktap/blktap.c
@@ -113,6 +113,7 @@ typedef struct tap_blkif {
 	pid_t pid;                    /*tapdisk process id                 =
  */
 	enum { RUNNING, CLEANSHUTDOWN } status; /*Detect a clean =
userspace=20
 						  shutdown                 =
  */
+	spinlock_t map_lock;          /*protects idx_map                   =
  */
 	struct idx_map {
 		u16 mem, req;
 	} *idx_map;                   /*Record the user ring id to kern
@@ -295,7 +296,7 @@ static pte_t blktap_clear_pte(struct vm_
 	pte_t copy;
 	tap_blkif_t *info =3D NULL;
 	unsigned int seg, usr_idx, pending_idx, mmap_idx, count =3D 0;
-	unsigned long offset, uvstart =3D 0;
+	unsigned long offset;
 	struct page *pg;
 	struct grant_handle_pair *khandle;
 	struct gnttab_unmap_grant_ref unmap[2];
@@ -304,25 +305,28 @@ static pte_t blktap_clear_pte(struct vm_
 	 * If the address is before the start of the grant mapped region =
or
 	 * if vm_file is NULL (meaning mmap failed and we have nothing to =
do)
 	 */
-	if (vma->vm_file !=3D NULL) {
+	if (vma->vm_file !=3D NULL)
 		info =3D vma->vm_file->private_data;
-		uvstart =3D info->rings_vstart + (RING_PAGES << PAGE_SHIFT)=
;
-	}
-	if (vma->vm_file =3D=3D NULL || uvaddr < uvstart)
+	if (info =3D=3D NULL || uvaddr < info->user_vstart)
 		return ptep_get_and_clear_full(vma->vm_mm, uvaddr,=20
 					       ptep, is_fullmm);
=20
-	/* TODO Should these be changed to if statements? */
-	BUG_ON(!info);
-	BUG_ON(!info->idx_map);
-
-	offset =3D (uvaddr - uvstart) >> PAGE_SHIFT;
+	offset =3D (uvaddr - info->user_vstart) >> PAGE_SHIFT;
 	usr_idx =3D OFFSET_TO_USR_IDX(offset);
 	seg =3D OFFSET_TO_SEG(offset);
=20
+	spin_lock(&info->map_lock);
+
 	pending_idx =3D info->idx_map[usr_idx].req;
 	mmap_idx =3D info->idx_map[usr_idx].mem;
=20
+	/* fast_flush_area() may already have cleared this entry */
+	if (mmap_idx =3D=3D INVALID_MIDX) {
+		spin_unlock(&info->map_lock);
+		return ptep_get_and_clear_full(vma->vm_mm, uvaddr, ptep,
+					       is_fullmm);
+	}
+
 	pg =3D idx_to_page(mmap_idx, pending_idx, seg);
 	ClearPageReserved(pg);
 	info->foreign_map.map[offset + RING_PAGES] =3D NULL;
@@ -365,6 +369,8 @@ static pte_t blktap_clear_pte(struct vm_
 			BUG();
 	}
=20
+	spin_unlock(&info->map_lock);
+
 	return copy;
 }
=20
@@ -489,6 +495,7 @@ found:
 		}
=20
 		info->minor =3D minor;
+		spin_lock_init(&info->map_lock);
 		/*
 		 * Make sure that we have a minor before others can
 		 * see us.
@@ -1029,25 +1036,30 @@ static void fast_flush_area(pending_req_
 			     unsigned int u_idx, tap_blkif_t *info)
 {
 	struct gnttab_unmap_grant_ref unmap[BLKIF_MAX_SEGMENTS_PER_REQUEST*=
2];
-	unsigned int i, mmap_idx, invcount =3D 0, locked =3D 0;
+	unsigned int i, mmap_idx, invcount =3D 0;
 	struct grant_handle_pair *khandle;
 	uint64_t ptep;
 	int ret;
 	unsigned long uvaddr;
 	struct mm_struct *mm =3D info->mm;
=20
+	if (mm !=3D NULL)
+		down_read(&mm->mmap_sem);
+
 	if (mm !=3D NULL && xen_feature(XENFEAT_auto_translated_physmap)) =
{
-		down_write(&mm->mmap_sem);
+ slow:
 		blktap_zap_page_range(mm,
 				      MMAP_VADDR(info->user_vstart, u_idx, =
0),
 				      req->nr_pages);
 		info->idx_map[u_idx].mem =3D INVALID_MIDX;
-		up_write(&mm->mmap_sem);
+		up_read(&mm->mmap_sem);
 		return;
 	}
=20
 	mmap_idx =3D req->mem_idx;
=20
+	spin_lock(&info->map_lock);
+
 	for (i =3D 0; i < req->nr_pages; i++) {
 		uvaddr =3D MMAP_VADDR(info->user_vstart, u_idx, i);
=20
@@ -1066,15 +1078,13 @@ static void fast_flush_area(pending_req_
=20
 		if (mm !=3D NULL && khandle->user !=3D INVALID_GRANT_HANDLE=
) {
 			BUG_ON(xen_feature(XENFEAT_auto_translated_physmap)=
);
-			if (!locked++)
-				down_write(&mm->mmap_sem);
 			if (create_lookup_pte_addr(
 				mm,
 				MMAP_VADDR(info->user_vstart, u_idx, i),
 				&ptep) !=3D0) {
-				up_write(&mm->mmap_sem);
+				spin_unlock(&info->map_lock);
 				WPRINTK("Couldn't get a pte addr!\n");
-				return;
+				goto slow;
 			}
=20
 			gnttab_set_unmap_op(&unmap[invcount], ptep,
@@ -1091,19 +1101,11 @@ static void fast_flush_area(pending_req_
 		GNTTABOP_unmap_grant_ref, unmap, invcount);
 	BUG_ON(ret);
 =09
-	if (mm !=3D NULL && !xen_feature(XENFEAT_auto_translated_physmap)) =
{
-		if (!locked++)
-			down_write(&mm->mmap_sem);
-		blktap_zap_page_range(mm,=20
-				      MMAP_VADDR(info->user_vstart, u_idx, =
0),=20
-				      req->nr_pages);
-	}
-
-	if (!locked && mm !=3D NULL)
-		down_write(&mm->mmap_sem);
 	info->idx_map[u_idx].mem =3D INVALID_MIDX;
+
+	spin_unlock(&info->map_lock);
 	if (mm !=3D NULL)
-		up_write(&mm->mmap_sem);
+		up_read(&mm->mmap_sem);
 }
=20
 /******************************************************************
@@ -1406,7 +1408,9 @@ static void dispatch_rw_block_io(blkif_t
 		goto fail_response;
=20
 	/* Check we have space on user ring - should never fail. */
+	spin_lock(&info->map_lock);
 	usr_idx =3D GET_NEXT_REQ(info->idx_map);
+	spin_unlock(&info->map_lock);
 	if (usr_idx >=3D MAX_PENDING_REQS) {
 		WARN_ON(1);
 		goto fail_response;
@@ -1445,7 +1449,7 @@ static void dispatch_rw_block_io(blkif_t
 	op =3D 0;
 	mm =3D info->mm;
 	if (!xen_feature(XENFEAT_auto_translated_physmap))
-		down_write(&mm->mmap_sem);
+		down_read(&mm->mmap_sem);
 	for (i =3D 0; i < nseg; i++) {
 		unsigned long uvaddr;
 		unsigned long kvaddr;
@@ -1462,9 +1466,9 @@ static void dispatch_rw_block_io(blkif_t
 			/* Now map it to user. */
 			ret =3D create_lookup_pte_addr(mm, uvaddr, &ptep);
 			if (ret) {
-				up_write(&mm->mmap_sem);
+				up_read(&mm->mmap_sem);
 				WPRINTK("Couldn't get a pte addr!\n");
-				goto fail_flush;
+				goto fail_response;
 			}
=20
 			gnttab_set_map_op(&map[op], ptep,
@@ -1478,12 +1482,15 @@ static void dispatch_rw_block_io(blkif_t
 			     req->seg[i].first_sect + 1);
 	}
=20
+	if (xen_feature(XENFEAT_auto_translated_physmap))
+		down_read(&mm->mmap_sem);
+
+	spin_lock(&info->map_lock);
+
 	ret =3D HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, map, =
op);
 	BUG_ON(ret);
=20
 	if (!xen_feature(XENFEAT_auto_translated_physmap)) {
-		up_write(&mm->mmap_sem);
-
 		for (i =3D 0; i < (nseg*2); i+=3D2) {
 			unsigned long uvaddr;
 			unsigned long offset;
@@ -1548,18 +1555,18 @@ static void dispatch_rw_block_io(blkif_t
 		}
 	}
=20
+	/*record [mmap_idx,pending_idx] to [usr_idx] mapping*/
+	info->idx_map[usr_idx].mem =3D mmap_idx;
+	info->idx_map[usr_idx].req =3D pending_idx;
+
+	spin_unlock(&info->map_lock);
+
 	if (ret)
 		goto fail_flush;
=20
-	if (xen_feature(XENFEAT_auto_translated_physmap))
-		down_write(&mm->mmap_sem);
-	/* Mark mapped pages as reserved: */
-	for (i =3D 0; i < req->nr_segments; i++) {
-		struct page *pg;
-
-		pg =3D idx_to_page(mmap_idx, pending_idx, i);
-		SetPageReserved(pg);
-		if (xen_feature(XENFEAT_auto_translated_physmap)) {
+	if (xen_feature(XENFEAT_auto_translated_physmap)) {
+		for (i =3D 0; i < nseg; i++) {
+			struct page *pg =3D idx_to_page(mmap_idx, =
pending_idx, i);
 			unsigned long uvaddr =3D MMAP_VADDR(info->user_vsta=
rt,
 							  usr_idx, i);
 			if (vma && uvaddr >=3D vma->vm_end) {
@@ -1577,18 +1584,12 @@ static void dispatch_rw_block_io(blkif_t
 					continue;
 			}
 			ret =3D vm_insert_page(vma, uvaddr, pg);
-			if (ret) {
-				up_write(&mm->mmap_sem);
+			if (ret)
 				goto fail_flush;
-			}
 		}
 	}
-	if (xen_feature(XENFEAT_auto_translated_physmap))
-		up_write(&mm->mmap_sem);
 =09
-	/*record [mmap_idx,pending_idx] to [usr_idx] mapping*/
-	info->idx_map[usr_idx].mem =3D mmap_idx;
-	info->idx_map[usr_idx].req =3D pending_idx;
+	up_read(&mm->mmap_sem);
=20
 	blkif_get(blkif);
 	/* Finally, write the request message to the user ring. */
@@ -1611,6 +1612,7 @@ static void dispatch_rw_block_io(blkif_t
 	return;
=20
  fail_flush:
+	up_read(&mm->mmap_sem);
 	WPRINTK("Reached Fail_flush\n");
 	fast_flush_area(pending_req, pending_idx, usr_idx, info);
  fail_response:


--=__Part527DE5E6.0__=
Content-Type: text/plain; name="xen-blktap-locking.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="xen-blktap-locking.patch"

blktap: fix locking (again)=0A=0Ac/s 1090 wasn't really helping much - I =
was doing that under the wrong=0Aimpression that the zap_pte() hook would =
be called with the mmap_sem=0Aheld. That being wrong, none of the uses of =
mmap_sem here actually are=0Awrite ones (they only look up vma information)=
, so convert them all to=0Aread acquires/releases.=0A=0AA new spinlock =
needs to be introduced, protecting idx_map. This has to=0Anest inside =
mmap_sem, which requires some code movement.=0A=0A--- a/drivers/xen/blktap/=
blktap.c=0A+++ b/drivers/xen/blktap/blktap.c=0A@@ -113,6 +113,7 @@ typedef =
struct tap_blkif {=0A 	pid_t pid;                    /*tapdisk process id =
                  */=0A 	enum { RUNNING, CLEANSHUTDOWN } status; =
/*Detect a clean userspace =0A 						  =
shutdown                   */=0A+	spinlock_t map_lock;          =
/*protects idx_map                     */=0A 	struct idx_map {=0A 		=
u16 mem, req;=0A 	} *idx_map;                   /*Record the user =
ring id to kern=0A@@ -295,7 +296,7 @@ static pte_t blktap_clear_pte(struct =
vm_=0A 	pte_t copy;=0A 	tap_blkif_t *info =3D NULL;=0A 	unsigned int seg, =
usr_idx, pending_idx, mmap_idx, count =3D 0;=0A-	unsigned long =
offset, uvstart =3D 0;=0A+	unsigned long offset;=0A 	struct =
page *pg;=0A 	struct grant_handle_pair *khandle;=0A 	struct gnttab_unmap=
_grant_ref unmap[2];=0A@@ -304,25 +305,28 @@ static pte_t blktap_clear_pte(=
struct vm_=0A 	 * If the address is before the start of the grant mapped =
region or=0A 	 * if vm_file is NULL (meaning mmap failed and we have =
nothing to do)=0A 	 */=0A-	if (vma->vm_file !=3D NULL) {=0A+	if =
(vma->vm_file !=3D NULL)=0A 		info =3D vma->vm_file->private_data=
;=0A-		uvstart =3D info->rings_vstart + (RING_PAGES << PAGE_SHIFT)=
;=0A-	}=0A-	if (vma->vm_file =3D=3D NULL || uvaddr < uvstart)=0A+	if =
(info =3D=3D NULL || uvaddr < info->user_vstart)=0A 		return =
ptep_get_and_clear_full(vma->vm_mm, uvaddr, =0A 				=
	       ptep, is_fullmm);=0A =0A-	/* TODO Should these be =
changed to if statements? */=0A-	BUG_ON(!info);=0A-	BUG_ON(!inf=
o->idx_map);=0A-=0A-	offset =3D (uvaddr - uvstart) >> PAGE_SHIFT;=0A+	=
offset =3D (uvaddr - info->user_vstart) >> PAGE_SHIFT;=0A 	usr_idx =
=3D OFFSET_TO_USR_IDX(offset);=0A 	seg =3D OFFSET_TO_SEG(offset);=0A =
=0A+	spin_lock(&info->map_lock);=0A+=0A 	pending_idx =3D info->idx_m=
ap[usr_idx].req;=0A 	mmap_idx =3D info->idx_map[usr_idx].mem;=0A =0A+	=
/* fast_flush_area() may already have cleared this entry */=0A+	if =
(mmap_idx =3D=3D INVALID_MIDX) {=0A+		spin_unlock(&info->map_lock=
);=0A+		return ptep_get_and_clear_full(vma->vm_mm, uvaddr, =
ptep,=0A+					       is_fullmm);=0A+	=
}=0A+=0A 	pg =3D idx_to_page(mmap_idx, pending_idx, seg);=0A 	=
ClearPageReserved(pg);=0A 	info->foreign_map.map[offset + RING_PAGES] =
=3D NULL;=0A@@ -365,6 +369,8 @@ static pte_t blktap_clear_pte(struct =
vm_=0A 			BUG();=0A 	}=0A =0A+	spin_unlock(&info->=
map_lock);=0A+=0A 	return copy;=0A }=0A =0A@@ -489,6 +495,7 @@ =
found:=0A 		}=0A =0A 		info->minor =3D minor;=0A+	=
	spin_lock_init(&info->map_lock);=0A 		/*=0A 		 * =
Make sure that we have a minor before others can=0A 		 * see =
us.=0A@@ -1029,25 +1036,30 @@ static void fast_flush_area(pending_req_=0A 	=
		     unsigned int u_idx, tap_blkif_t *info)=0A {=0A 	=
struct gnttab_unmap_grant_ref unmap[BLKIF_MAX_SEGMENTS_PER_REQUEST*2];=0A-	=
unsigned int i, mmap_idx, invcount =3D 0, locked =3D 0;=0A+	unsigned =
int i, mmap_idx, invcount =3D 0;=0A 	struct grant_handle_pair =
*khandle;=0A 	uint64_t ptep;=0A 	int ret;=0A 	unsigned long =
uvaddr;=0A 	struct mm_struct *mm =3D info->mm;=0A =0A+	if (mm =
!=3D NULL)=0A+		down_read(&mm->mmap_sem);=0A+=0A 	if (mm =
!=3D NULL && xen_feature(XENFEAT_auto_translated_physmap)) {=0A-		=
down_write(&mm->mmap_sem);=0A+ slow:=0A 		blktap_zap_page_ran=
ge(mm,=0A 				      MMAP_VADDR(info->user_vstart,=
 u_idx, 0),=0A 				      req->nr_pages);=0A 		=
info->idx_map[u_idx].mem =3D INVALID_MIDX;=0A-		up_write(&mm->mmap_=
sem);=0A+		up_read(&mm->mmap_sem);=0A 		return;=0A =
	}=0A =0A 	mmap_idx =3D req->mem_idx;=0A =0A+	spin_lock(&=
info->map_lock);=0A+=0A 	for (i =3D 0; i < req->nr_pages; i++) {=0A =
		uvaddr =3D MMAP_VADDR(info->user_vstart, u_idx, i);=0A =
=0A@@ -1066,15 +1078,13 @@ static void fast_flush_area(pending_req_=0A =0A =
		if (mm !=3D NULL && khandle->user !=3D INVALID_GRANT_HANDLE=
) {=0A 			BUG_ON(xen_feature(XENFEAT_auto_translated_physmap)=
);=0A-			if (!locked++)=0A-				=
down_write(&mm->mmap_sem);=0A 			if (create_lookup_pte_addr(=
=0A 				mm,=0A 				MMAP_VADDR(=
info->user_vstart, u_idx, i),=0A 				&ptep) =
!=3D0) {=0A-				up_write(&mm->mmap_sem);=0A+		=
		spin_unlock(&info->map_lock);=0A 				=
WPRINTK("Couldn't get a pte addr!\n");=0A-				=
return;=0A+				goto slow;=0A 			=
}=0A =0A 			gnttab_set_unmap_op(&unmap[invcount], =
ptep,=0A@@ -1091,19 +1101,11 @@ static void fast_flush_area(pending_req_=0A=
 		GNTTABOP_unmap_grant_ref, unmap, invcount);=0A 	BUG_ON(ret)=
;=0A 	=0A-	if (mm !=3D NULL && !xen_feature(XENFEAT_auto_translated_ph=
ysmap)) {=0A-		if (!locked++)=0A-			down_write(=
&mm->mmap_sem);=0A-		blktap_zap_page_range(mm, =0A-			=
	      MMAP_VADDR(info->user_vstart, u_idx, 0), =0A-			=
	      req->nr_pages);=0A-	}=0A-=0A-	if (!locked && mm =
!=3D NULL)=0A-		down_write(&mm->mmap_sem);=0A 	info->idx_map[u_idx=
].mem =3D INVALID_MIDX;=0A+=0A+	spin_unlock(&info->map_lock);=0A 	if =
(mm !=3D NULL)=0A-		up_write(&mm->mmap_sem);=0A+		=
up_read(&mm->mmap_sem);=0A }=0A =0A /**************************************=
****************************=0A@@ -1406,7 +1408,9 @@ static void dispatch_r=
w_block_io(blkif_t=0A 		goto fail_response;=0A =0A 	/* Check =
we have space on user ring - should never fail. */=0A+	spin_lock(&info->ma=
p_lock);=0A 	usr_idx =3D GET_NEXT_REQ(info->idx_map);=0A+	spin_unlock=
(&info->map_lock);=0A 	if (usr_idx >=3D MAX_PENDING_REQS) {=0A 		=
WARN_ON(1);=0A 		goto fail_response;=0A@@ -1445,7 +1449,7 @@ static =
void dispatch_rw_block_io(blkif_t=0A 	op =3D 0;=0A 	mm =3D info->mm;=0A=
 	if (!xen_feature(XENFEAT_auto_translated_physmap))=0A-		=
down_write(&mm->mmap_sem);=0A+		down_read(&mm->mmap_sem);=0A 	=
for (i =3D 0; i < nseg; i++) {=0A 		unsigned long uvaddr;=0A 	=
	unsigned long kvaddr;=0A@@ -1462,9 +1466,9 @@ static void =
dispatch_rw_block_io(blkif_t=0A 			/* Now map it to =
user. */=0A 			ret =3D create_lookup_pte_addr(mm, uvaddr, =
&ptep);=0A 			if (ret) {=0A-				=
up_write(&mm->mmap_sem);=0A+				up_read(&mm->mmap_s=
em);=0A 				WPRINTK("Couldn't get a pte =
addr!\n");=0A-				goto fail_flush;=0A+			=
	goto fail_response;=0A 			}=0A =0A 			=
gnttab_set_map_op(&map[op], ptep,=0A@@ -1478,12 +1482,15 @@ static void =
dispatch_rw_block_io(blkif_t=0A 			     req->seg[i].fi=
rst_sect + 1);=0A 	}=0A =0A+	if (xen_feature(XENFEAT_auto_transl=
ated_physmap))=0A+		down_read(&mm->mmap_sem);=0A+=0A+	=
spin_lock(&info->map_lock);=0A+=0A 	ret =3D HYPERVISOR_grant_table_op(G=
NTTABOP_map_grant_ref, map, op);=0A 	BUG_ON(ret);=0A =0A 	if =
(!xen_feature(XENFEAT_auto_translated_physmap)) {=0A-		up_write(&m=
m->mmap_sem);=0A-=0A 		for (i =3D 0; i < (nseg*2); i+=3D2) {=0A 	=
		unsigned long uvaddr;=0A 			unsigned =
long offset;=0A@@ -1548,18 +1555,18 @@ static void dispatch_rw_block_io(blk=
if_t=0A 		}=0A 	}=0A =0A+	/*record [mmap_idx,pending_=
idx] to [usr_idx] mapping*/=0A+	info->idx_map[usr_idx].mem =3D mmap_idx;=0A=
+	info->idx_map[usr_idx].req =3D pending_idx;=0A+=0A+	spin_unlock=
(&info->map_lock);=0A+=0A 	if (ret)=0A 		goto fail_flush;=0A=
 =0A-	if (xen_feature(XENFEAT_auto_translated_physmap))=0A-		=
down_write(&mm->mmap_sem);=0A-	/* Mark mapped pages as reserved: */=0A-	=
for (i =3D 0; i < req->nr_segments; i++) {=0A-		struct page =
*pg;=0A-=0A-		pg =3D idx_to_page(mmap_idx, pending_idx, i);=0A-	=
	SetPageReserved(pg);=0A-		if (xen_feature(XENFEAT_aut=
o_translated_physmap)) {=0A+	if (xen_feature(XENFEAT_auto_translated_phy=
smap)) {=0A+		for (i =3D 0; i < nseg; i++) {=0A+			=
struct page *pg =3D idx_to_page(mmap_idx, pending_idx, i);=0A 			=
unsigned long uvaddr =3D MMAP_VADDR(info->user_vstart,=0A 			=
				  usr_idx, i);=0A 			if =
(vma && uvaddr >=3D vma->vm_end) {=0A@@ -1577,18 +1584,12 @@ static void =
dispatch_rw_block_io(blkif_t=0A 					=
continue;=0A 			}=0A 			ret =3D vm_insert_p=
age(vma, uvaddr, pg);=0A-			if (ret) {=0A-			=
	up_write(&mm->mmap_sem);=0A+			if (ret)=0A 		=
		goto fail_flush;=0A-			}=0A 		=
}=0A 	}=0A-	if (xen_feature(XENFEAT_auto_translated_physmap))=0A-		=
up_write(&mm->mmap_sem);=0A 	=0A-	/*record [mmap_idx,pending_idx] to =
[usr_idx] mapping*/=0A-	info->idx_map[usr_idx].mem =3D mmap_idx;=0A-	=
info->idx_map[usr_idx].req =3D pending_idx;=0A+	up_read(&mm->mmap_sem);=0A =
=0A 	blkif_get(blkif);=0A 	/* Finally, write the request message to =
the user ring. */=0A@@ -1611,6 +1612,7 @@ static void dispatch_rw_block_io(=
blkif_t=0A 	return;=0A =0A  fail_flush:=0A+	up_read(&mm->mmap_sem);=0A =
	WPRINTK("Reached Fail_flush\n");=0A 	fast_flush_area(pending_req=
, pending_idx, usr_idx, info);=0A  fail_response:=0A
--=__Part527DE5E6.0__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--=__Part527DE5E6.0__=--


From xen-devel-bounces@lists.xensource.com Fri Dec 23 11:36:22 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 Dec 2011 11:36:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Re3Q6-0003ZM-J3; Fri, 23 Dec 2011 11:36:14 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Re3Q5-0003Xw-3u
	for xen-devel@lists.xensource.com; Fri, 23 Dec 2011 11:36:13 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1324640165!8420710!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31622 invoked from network); 23 Dec 2011 11:36:06 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-4.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 23 Dec 2011 11:36:06 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 23 Dec 2011 11:35:44 +0000
Message-Id: <4EF475D80200007800069C69@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 23 Dec 2011 11:36:40 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part6D42DAD8.0__="
Subject: [Xen-devel] [PATCH] linux-2.6.18/blktap: ensure mmap() is called
 only once per region
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__Part6D42DAD8.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/drivers/xen/blktap/blktap.c
+++ b/drivers/xen/blktap/blktap.c
@@ -635,6 +635,7 @@ static int blktap_release(struct inode *
=20
 	info->ring_ok =3D 0;
 	smp_wmb();
+	info->rings_vstart =3D 0;
=20
 	mm =3D xchg(&info->mm, NULL);
 	if (mm)
@@ -694,7 +695,13 @@ static int blktap_mmap(struct file *filp
 		WPRINTK("blktap: mmap, retrieving idx failed\n");
 		return -ENOMEM;
 	}
-=09
+
+	if (info->rings_vstart) {
+		WPRINTK("mmap already called on filp %p (minor %d)\n",
+			filp, info->minor);
+		return -EPERM;
+	}
+
 	vma->vm_flags |=3D VM_RESERVED;
 	vma->vm_ops =3D &blktap_vm_ops;
=20
@@ -746,6 +753,7 @@ static int blktap_mmap(struct file *filp
 	/* Clear any active mappings. */
 	zap_page_range(vma, vma->vm_start,=20
 		       vma->vm_end - vma->vm_start, NULL);
+	info->rings_vstart =3D 0;
=20
 	return -ENOMEM;
 }




--=__Part6D42DAD8.0__=
Content-Type: text/plain; name="xen-blktap-map-once.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="xen-blktap-map-once.patch"

blktap: ensure mmap() is called only once per region=0A=0ASigned-off-by: =
Jan Beulich <jbeulich@suse.com>=0A=0A--- a/drivers/xen/blktap/blktap.c=0A++=
+ b/drivers/xen/blktap/blktap.c=0A@@ -635,6 +635,7 @@ static int blktap_rel=
ease(struct inode *=0A =0A 	info->ring_ok =3D 0;=0A 	smp_wmb();=
=0A+	info->rings_vstart =3D 0;=0A =0A 	mm =3D xchg(&info->mm, =
NULL);=0A 	if (mm)=0A@@ -694,7 +695,13 @@ static int blktap_mmap(struc=
t file *filp=0A 		WPRINTK("blktap: mmap, retrieving idx =
failed\n");=0A 		return -ENOMEM;=0A 	}=0A-	=0A+=0A+	if =
(info->rings_vstart) {=0A+		WPRINTK("mmap already called on =
filp %p (minor %d)\n",=0A+			filp, info->minor);=0A+		=
return -EPERM;=0A+	}=0A+=0A 	vma->vm_flags |=3D VM_RESERVED;=0A =
	vma->vm_ops =3D &blktap_vm_ops;=0A =0A@@ -746,6 +753,7 @@ static =
int blktap_mmap(struct file *filp=0A 	/* Clear any active mappings. =
*/=0A 	zap_page_range(vma, vma->vm_start, =0A 		       vma->vm_end =
- vma->vm_start, NULL);=0A+	info->rings_vstart =3D 0;=0A =0A 	=
return -ENOMEM;=0A }=0A
--=__Part6D42DAD8.0__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--=__Part6D42DAD8.0__=--


From xen-devel-bounces@lists.xensource.com Fri Dec 23 11:36:22 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 Dec 2011 11:36:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Re3Q6-0003ZM-J3; Fri, 23 Dec 2011 11:36:14 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Re3Q5-0003Xw-3u
	for xen-devel@lists.xensource.com; Fri, 23 Dec 2011 11:36:13 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1324640165!8420710!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31622 invoked from network); 23 Dec 2011 11:36:06 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-4.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 23 Dec 2011 11:36:06 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 23 Dec 2011 11:35:44 +0000
Message-Id: <4EF475D80200007800069C69@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 23 Dec 2011 11:36:40 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part6D42DAD8.0__="
Subject: [Xen-devel] [PATCH] linux-2.6.18/blktap: ensure mmap() is called
 only once per region
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__Part6D42DAD8.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/drivers/xen/blktap/blktap.c
+++ b/drivers/xen/blktap/blktap.c
@@ -635,6 +635,7 @@ static int blktap_release(struct inode *
=20
 	info->ring_ok =3D 0;
 	smp_wmb();
+	info->rings_vstart =3D 0;
=20
 	mm =3D xchg(&info->mm, NULL);
 	if (mm)
@@ -694,7 +695,13 @@ static int blktap_mmap(struct file *filp
 		WPRINTK("blktap: mmap, retrieving idx failed\n");
 		return -ENOMEM;
 	}
-=09
+
+	if (info->rings_vstart) {
+		WPRINTK("mmap already called on filp %p (minor %d)\n",
+			filp, info->minor);
+		return -EPERM;
+	}
+
 	vma->vm_flags |=3D VM_RESERVED;
 	vma->vm_ops =3D &blktap_vm_ops;
=20
@@ -746,6 +753,7 @@ static int blktap_mmap(struct file *filp
 	/* Clear any active mappings. */
 	zap_page_range(vma, vma->vm_start,=20
 		       vma->vm_end - vma->vm_start, NULL);
+	info->rings_vstart =3D 0;
=20
 	return -ENOMEM;
 }




--=__Part6D42DAD8.0__=
Content-Type: text/plain; name="xen-blktap-map-once.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="xen-blktap-map-once.patch"

blktap: ensure mmap() is called only once per region=0A=0ASigned-off-by: =
Jan Beulich <jbeulich@suse.com>=0A=0A--- a/drivers/xen/blktap/blktap.c=0A++=
+ b/drivers/xen/blktap/blktap.c=0A@@ -635,6 +635,7 @@ static int blktap_rel=
ease(struct inode *=0A =0A 	info->ring_ok =3D 0;=0A 	smp_wmb();=
=0A+	info->rings_vstart =3D 0;=0A =0A 	mm =3D xchg(&info->mm, =
NULL);=0A 	if (mm)=0A@@ -694,7 +695,13 @@ static int blktap_mmap(struc=
t file *filp=0A 		WPRINTK("blktap: mmap, retrieving idx =
failed\n");=0A 		return -ENOMEM;=0A 	}=0A-	=0A+=0A+	if =
(info->rings_vstart) {=0A+		WPRINTK("mmap already called on =
filp %p (minor %d)\n",=0A+			filp, info->minor);=0A+		=
return -EPERM;=0A+	}=0A+=0A 	vma->vm_flags |=3D VM_RESERVED;=0A =
	vma->vm_ops =3D &blktap_vm_ops;=0A =0A@@ -746,6 +753,7 @@ static =
int blktap_mmap(struct file *filp=0A 	/* Clear any active mappings. =
*/=0A 	zap_page_range(vma, vma->vm_start, =0A 		       vma->vm_end =
- vma->vm_start, NULL);=0A+	info->rings_vstart =3D 0;=0A =0A 	=
return -ENOMEM;=0A }=0A
--=__Part6D42DAD8.0__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--=__Part6D42DAD8.0__=--


From xen-devel-bounces@lists.xensource.com Fri Dec 23 11:36:31 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 Dec 2011 11:36:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Re3QD-0003c1-W2; Fri, 23 Dec 2011 11:36:21 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Re3QC-0003ZX-Hx
	for xen-devel@lists.xensource.com; Fri, 23 Dec 2011 11:36:20 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1324640173!8420466!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24823 invoked from network); 23 Dec 2011 11:36:14 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-10.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 23 Dec 2011 11:36:14 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 23 Dec 2011 11:36:13 +0000
Message-Id: <4EF475F30200007800069CFC@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 23 Dec 2011 11:37:07 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
References: <4EF475060200007800069C65@nat28.tlf.novell.com>
In-Reply-To: <4EF475060200007800069C65@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
Subject: Re: [Xen-devel] [PATCH] linux-2.6.18/blktap: fix locking (again)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 23.12.11 at 12:33, "Jan Beulich" <JBeulich@suse.com> wrote:
> c/s 1090 wasn't really helping much - I was doing that under the wrong
> impression that the zap_pte() hook would be called with the mmap_sem
> held. That being wrong, none of the uses of mmap_sem here actually are
> write ones (they only look up vma information), so convert them all to
> read acquires/releases.
> 
> A new spinlock needs to be introduced, protecting idx_map. This has to
> nest inside mmap_sem, which requires some code movement.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

> --- a/drivers/xen/blktap/blktap.c
> +++ b/drivers/xen/blktap/blktap.c
> @@ -113,6 +113,7 @@ typedef struct tap_blkif {
>  	pid_t pid;                    /*tapdisk process id                   */
>  	enum { RUNNING, CLEANSHUTDOWN } status; /*Detect a clean userspace 
>  						  shutdown                   */
> +	spinlock_t map_lock;          /*protects idx_map                     */
>  	struct idx_map {
>  		u16 mem, req;
>  	} *idx_map;                   /*Record the user ring id to kern
> @@ -295,7 +296,7 @@ static pte_t blktap_clear_pte(struct vm_
>  	pte_t copy;
>  	tap_blkif_t *info = NULL;
>  	unsigned int seg, usr_idx, pending_idx, mmap_idx, count = 0;
> -	unsigned long offset, uvstart = 0;
> +	unsigned long offset;
>  	struct page *pg;
>  	struct grant_handle_pair *khandle;
>  	struct gnttab_unmap_grant_ref unmap[2];
> @@ -304,25 +305,28 @@ static pte_t blktap_clear_pte(struct vm_
>  	 * If the address is before the start of the grant mapped region or
>  	 * if vm_file is NULL (meaning mmap failed and we have nothing to do)
>  	 */
> -	if (vma->vm_file != NULL) {
> +	if (vma->vm_file != NULL)
>  		info = vma->vm_file->private_data;
> -		uvstart = info->rings_vstart + (RING_PAGES << PAGE_SHIFT);
> -	}
> -	if (vma->vm_file == NULL || uvaddr < uvstart)
> +	if (info == NULL || uvaddr < info->user_vstart)
>  		return ptep_get_and_clear_full(vma->vm_mm, uvaddr, 
>  					       ptep, is_fullmm);
>  
> -	/* TODO Should these be changed to if statements? */
> -	BUG_ON(!info);
> -	BUG_ON(!info->idx_map);
> -
> -	offset = (uvaddr - uvstart) >> PAGE_SHIFT;
> +	offset = (uvaddr - info->user_vstart) >> PAGE_SHIFT;
>  	usr_idx = OFFSET_TO_USR_IDX(offset);
>  	seg = OFFSET_TO_SEG(offset);
>  
> +	spin_lock(&info->map_lock);
> +
>  	pending_idx = info->idx_map[usr_idx].req;
>  	mmap_idx = info->idx_map[usr_idx].mem;
>  
> +	/* fast_flush_area() may already have cleared this entry */
> +	if (mmap_idx == INVALID_MIDX) {
> +		spin_unlock(&info->map_lock);
> +		return ptep_get_and_clear_full(vma->vm_mm, uvaddr, ptep,
> +					       is_fullmm);
> +	}
> +
>  	pg = idx_to_page(mmap_idx, pending_idx, seg);
>  	ClearPageReserved(pg);
>  	info->foreign_map.map[offset + RING_PAGES] = NULL;
> @@ -365,6 +369,8 @@ static pte_t blktap_clear_pte(struct vm_
>  			BUG();
>  	}
>  
> +	spin_unlock(&info->map_lock);
> +
>  	return copy;
>  }
>  
> @@ -489,6 +495,7 @@ found:
>  		}
>  
>  		info->minor = minor;
> +		spin_lock_init(&info->map_lock);
>  		/*
>  		 * Make sure that we have a minor before others can
>  		 * see us.
> @@ -1029,25 +1036,30 @@ static void fast_flush_area(pending_req_
>  			     unsigned int u_idx, tap_blkif_t *info)
>  {
>  	struct gnttab_unmap_grant_ref unmap[BLKIF_MAX_SEGMENTS_PER_REQUEST*2];
> -	unsigned int i, mmap_idx, invcount = 0, locked = 0;
> +	unsigned int i, mmap_idx, invcount = 0;
>  	struct grant_handle_pair *khandle;
>  	uint64_t ptep;
>  	int ret;
>  	unsigned long uvaddr;
>  	struct mm_struct *mm = info->mm;
>  
> +	if (mm != NULL)
> +		down_read(&mm->mmap_sem);
> +
>  	if (mm != NULL && xen_feature(XENFEAT_auto_translated_physmap)) {
> -		down_write(&mm->mmap_sem);
> + slow:
>  		blktap_zap_page_range(mm,
>  				      MMAP_VADDR(info->user_vstart, u_idx, 0),
>  				      req->nr_pages);
>  		info->idx_map[u_idx].mem = INVALID_MIDX;
> -		up_write(&mm->mmap_sem);
> +		up_read(&mm->mmap_sem);
>  		return;
>  	}
>  
>  	mmap_idx = req->mem_idx;
>  
> +	spin_lock(&info->map_lock);
> +
>  	for (i = 0; i < req->nr_pages; i++) {
>  		uvaddr = MMAP_VADDR(info->user_vstart, u_idx, i);
>  
> @@ -1066,15 +1078,13 @@ static void fast_flush_area(pending_req_
>  
>  		if (mm != NULL && khandle->user != INVALID_GRANT_HANDLE) {
>  			BUG_ON(xen_feature(XENFEAT_auto_translated_physmap));
> -			if (!locked++)
> -				down_write(&mm->mmap_sem);
>  			if (create_lookup_pte_addr(
>  				mm,
>  				MMAP_VADDR(info->user_vstart, u_idx, i),
>  				&ptep) !=0) {
> -				up_write(&mm->mmap_sem);
> +				spin_unlock(&info->map_lock);
>  				WPRINTK("Couldn't get a pte addr!\n");
> -				return;
> +				goto slow;
>  			}
>  
>  			gnttab_set_unmap_op(&unmap[invcount], ptep,
> @@ -1091,19 +1101,11 @@ static void fast_flush_area(pending_req_
>  		GNTTABOP_unmap_grant_ref, unmap, invcount);
>  	BUG_ON(ret);
>  	
> -	if (mm != NULL && !xen_feature(XENFEAT_auto_translated_physmap)) {
> -		if (!locked++)
> -			down_write(&mm->mmap_sem);
> -		blktap_zap_page_range(mm, 
> -				      MMAP_VADDR(info->user_vstart, u_idx, 0), 
> -				      req->nr_pages);
> -	}
> -
> -	if (!locked && mm != NULL)
> -		down_write(&mm->mmap_sem);
>  	info->idx_map[u_idx].mem = INVALID_MIDX;
> +
> +	spin_unlock(&info->map_lock);
>  	if (mm != NULL)
> -		up_write(&mm->mmap_sem);
> +		up_read(&mm->mmap_sem);
>  }
>  
>  /******************************************************************
> @@ -1406,7 +1408,9 @@ static void dispatch_rw_block_io(blkif_t
>  		goto fail_response;
>  
>  	/* Check we have space on user ring - should never fail. */
> +	spin_lock(&info->map_lock);
>  	usr_idx = GET_NEXT_REQ(info->idx_map);
> +	spin_unlock(&info->map_lock);
>  	if (usr_idx >= MAX_PENDING_REQS) {
>  		WARN_ON(1);
>  		goto fail_response;
> @@ -1445,7 +1449,7 @@ static void dispatch_rw_block_io(blkif_t
>  	op = 0;
>  	mm = info->mm;
>  	if (!xen_feature(XENFEAT_auto_translated_physmap))
> -		down_write(&mm->mmap_sem);
> +		down_read(&mm->mmap_sem);
>  	for (i = 0; i < nseg; i++) {
>  		unsigned long uvaddr;
>  		unsigned long kvaddr;
> @@ -1462,9 +1466,9 @@ static void dispatch_rw_block_io(blkif_t
>  			/* Now map it to user. */
>  			ret = create_lookup_pte_addr(mm, uvaddr, &ptep);
>  			if (ret) {
> -				up_write(&mm->mmap_sem);
> +				up_read(&mm->mmap_sem);
>  				WPRINTK("Couldn't get a pte addr!\n");
> -				goto fail_flush;
> +				goto fail_response;
>  			}
>  
>  			gnttab_set_map_op(&map[op], ptep,
> @@ -1478,12 +1482,15 @@ static void dispatch_rw_block_io(blkif_t
>  			     req->seg[i].first_sect + 1);
>  	}
>  
> +	if (xen_feature(XENFEAT_auto_translated_physmap))
> +		down_read(&mm->mmap_sem);
> +
> +	spin_lock(&info->map_lock);
> +
>  	ret = HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, map, op);
>  	BUG_ON(ret);
>  
>  	if (!xen_feature(XENFEAT_auto_translated_physmap)) {
> -		up_write(&mm->mmap_sem);
> -
>  		for (i = 0; i < (nseg*2); i+=2) {
>  			unsigned long uvaddr;
>  			unsigned long offset;
> @@ -1548,18 +1555,18 @@ static void dispatch_rw_block_io(blkif_t
>  		}
>  	}
>  
> +	/*record [mmap_idx,pending_idx] to [usr_idx] mapping*/
> +	info->idx_map[usr_idx].mem = mmap_idx;
> +	info->idx_map[usr_idx].req = pending_idx;
> +
> +	spin_unlock(&info->map_lock);
> +
>  	if (ret)
>  		goto fail_flush;
>  
> -	if (xen_feature(XENFEAT_auto_translated_physmap))
> -		down_write(&mm->mmap_sem);
> -	/* Mark mapped pages as reserved: */
> -	for (i = 0; i < req->nr_segments; i++) {
> -		struct page *pg;
> -
> -		pg = idx_to_page(mmap_idx, pending_idx, i);
> -		SetPageReserved(pg);
> -		if (xen_feature(XENFEAT_auto_translated_physmap)) {
> +	if (xen_feature(XENFEAT_auto_translated_physmap)) {
> +		for (i = 0; i < nseg; i++) {
> +			struct page *pg = idx_to_page(mmap_idx, pending_idx, i);
>  			unsigned long uvaddr = MMAP_VADDR(info->user_vstart,
>  							  usr_idx, i);
>  			if (vma && uvaddr >= vma->vm_end) {
> @@ -1577,18 +1584,12 @@ static void dispatch_rw_block_io(blkif_t
>  					continue;
>  			}
>  			ret = vm_insert_page(vma, uvaddr, pg);
> -			if (ret) {
> -				up_write(&mm->mmap_sem);
> +			if (ret)
>  				goto fail_flush;
> -			}
>  		}
>  	}
> -	if (xen_feature(XENFEAT_auto_translated_physmap))
> -		up_write(&mm->mmap_sem);
>  	
> -	/*record [mmap_idx,pending_idx] to [usr_idx] mapping*/
> -	info->idx_map[usr_idx].mem = mmap_idx;
> -	info->idx_map[usr_idx].req = pending_idx;
> +	up_read(&mm->mmap_sem);
>  
>  	blkif_get(blkif);
>  	/* Finally, write the request message to the user ring. */
> @@ -1611,6 +1612,7 @@ static void dispatch_rw_block_io(blkif_t
>  	return;
>  
>   fail_flush:
> +	up_read(&mm->mmap_sem);
>  	WPRINTK("Reached Fail_flush\n");
>  	fast_flush_area(pending_req, pending_idx, usr_idx, info);
>   fail_response:



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 23 11:36:31 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 Dec 2011 11:36:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Re3QD-0003c1-W2; Fri, 23 Dec 2011 11:36:21 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Re3QC-0003ZX-Hx
	for xen-devel@lists.xensource.com; Fri, 23 Dec 2011 11:36:20 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1324640173!8420466!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24823 invoked from network); 23 Dec 2011 11:36:14 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-10.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 23 Dec 2011 11:36:14 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 23 Dec 2011 11:36:13 +0000
Message-Id: <4EF475F30200007800069CFC@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 23 Dec 2011 11:37:07 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
References: <4EF475060200007800069C65@nat28.tlf.novell.com>
In-Reply-To: <4EF475060200007800069C65@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
Subject: Re: [Xen-devel] [PATCH] linux-2.6.18/blktap: fix locking (again)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 23.12.11 at 12:33, "Jan Beulich" <JBeulich@suse.com> wrote:
> c/s 1090 wasn't really helping much - I was doing that under the wrong
> impression that the zap_pte() hook would be called with the mmap_sem
> held. That being wrong, none of the uses of mmap_sem here actually are
> write ones (they only look up vma information), so convert them all to
> read acquires/releases.
> 
> A new spinlock needs to be introduced, protecting idx_map. This has to
> nest inside mmap_sem, which requires some code movement.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

> --- a/drivers/xen/blktap/blktap.c
> +++ b/drivers/xen/blktap/blktap.c
> @@ -113,6 +113,7 @@ typedef struct tap_blkif {
>  	pid_t pid;                    /*tapdisk process id                   */
>  	enum { RUNNING, CLEANSHUTDOWN } status; /*Detect a clean userspace 
>  						  shutdown                   */
> +	spinlock_t map_lock;          /*protects idx_map                     */
>  	struct idx_map {
>  		u16 mem, req;
>  	} *idx_map;                   /*Record the user ring id to kern
> @@ -295,7 +296,7 @@ static pte_t blktap_clear_pte(struct vm_
>  	pte_t copy;
>  	tap_blkif_t *info = NULL;
>  	unsigned int seg, usr_idx, pending_idx, mmap_idx, count = 0;
> -	unsigned long offset, uvstart = 0;
> +	unsigned long offset;
>  	struct page *pg;
>  	struct grant_handle_pair *khandle;
>  	struct gnttab_unmap_grant_ref unmap[2];
> @@ -304,25 +305,28 @@ static pte_t blktap_clear_pte(struct vm_
>  	 * If the address is before the start of the grant mapped region or
>  	 * if vm_file is NULL (meaning mmap failed and we have nothing to do)
>  	 */
> -	if (vma->vm_file != NULL) {
> +	if (vma->vm_file != NULL)
>  		info = vma->vm_file->private_data;
> -		uvstart = info->rings_vstart + (RING_PAGES << PAGE_SHIFT);
> -	}
> -	if (vma->vm_file == NULL || uvaddr < uvstart)
> +	if (info == NULL || uvaddr < info->user_vstart)
>  		return ptep_get_and_clear_full(vma->vm_mm, uvaddr, 
>  					       ptep, is_fullmm);
>  
> -	/* TODO Should these be changed to if statements? */
> -	BUG_ON(!info);
> -	BUG_ON(!info->idx_map);
> -
> -	offset = (uvaddr - uvstart) >> PAGE_SHIFT;
> +	offset = (uvaddr - info->user_vstart) >> PAGE_SHIFT;
>  	usr_idx = OFFSET_TO_USR_IDX(offset);
>  	seg = OFFSET_TO_SEG(offset);
>  
> +	spin_lock(&info->map_lock);
> +
>  	pending_idx = info->idx_map[usr_idx].req;
>  	mmap_idx = info->idx_map[usr_idx].mem;
>  
> +	/* fast_flush_area() may already have cleared this entry */
> +	if (mmap_idx == INVALID_MIDX) {
> +		spin_unlock(&info->map_lock);
> +		return ptep_get_and_clear_full(vma->vm_mm, uvaddr, ptep,
> +					       is_fullmm);
> +	}
> +
>  	pg = idx_to_page(mmap_idx, pending_idx, seg);
>  	ClearPageReserved(pg);
>  	info->foreign_map.map[offset + RING_PAGES] = NULL;
> @@ -365,6 +369,8 @@ static pte_t blktap_clear_pte(struct vm_
>  			BUG();
>  	}
>  
> +	spin_unlock(&info->map_lock);
> +
>  	return copy;
>  }
>  
> @@ -489,6 +495,7 @@ found:
>  		}
>  
>  		info->minor = minor;
> +		spin_lock_init(&info->map_lock);
>  		/*
>  		 * Make sure that we have a minor before others can
>  		 * see us.
> @@ -1029,25 +1036,30 @@ static void fast_flush_area(pending_req_
>  			     unsigned int u_idx, tap_blkif_t *info)
>  {
>  	struct gnttab_unmap_grant_ref unmap[BLKIF_MAX_SEGMENTS_PER_REQUEST*2];
> -	unsigned int i, mmap_idx, invcount = 0, locked = 0;
> +	unsigned int i, mmap_idx, invcount = 0;
>  	struct grant_handle_pair *khandle;
>  	uint64_t ptep;
>  	int ret;
>  	unsigned long uvaddr;
>  	struct mm_struct *mm = info->mm;
>  
> +	if (mm != NULL)
> +		down_read(&mm->mmap_sem);
> +
>  	if (mm != NULL && xen_feature(XENFEAT_auto_translated_physmap)) {
> -		down_write(&mm->mmap_sem);
> + slow:
>  		blktap_zap_page_range(mm,
>  				      MMAP_VADDR(info->user_vstart, u_idx, 0),
>  				      req->nr_pages);
>  		info->idx_map[u_idx].mem = INVALID_MIDX;
> -		up_write(&mm->mmap_sem);
> +		up_read(&mm->mmap_sem);
>  		return;
>  	}
>  
>  	mmap_idx = req->mem_idx;
>  
> +	spin_lock(&info->map_lock);
> +
>  	for (i = 0; i < req->nr_pages; i++) {
>  		uvaddr = MMAP_VADDR(info->user_vstart, u_idx, i);
>  
> @@ -1066,15 +1078,13 @@ static void fast_flush_area(pending_req_
>  
>  		if (mm != NULL && khandle->user != INVALID_GRANT_HANDLE) {
>  			BUG_ON(xen_feature(XENFEAT_auto_translated_physmap));
> -			if (!locked++)
> -				down_write(&mm->mmap_sem);
>  			if (create_lookup_pte_addr(
>  				mm,
>  				MMAP_VADDR(info->user_vstart, u_idx, i),
>  				&ptep) !=0) {
> -				up_write(&mm->mmap_sem);
> +				spin_unlock(&info->map_lock);
>  				WPRINTK("Couldn't get a pte addr!\n");
> -				return;
> +				goto slow;
>  			}
>  
>  			gnttab_set_unmap_op(&unmap[invcount], ptep,
> @@ -1091,19 +1101,11 @@ static void fast_flush_area(pending_req_
>  		GNTTABOP_unmap_grant_ref, unmap, invcount);
>  	BUG_ON(ret);
>  	
> -	if (mm != NULL && !xen_feature(XENFEAT_auto_translated_physmap)) {
> -		if (!locked++)
> -			down_write(&mm->mmap_sem);
> -		blktap_zap_page_range(mm, 
> -				      MMAP_VADDR(info->user_vstart, u_idx, 0), 
> -				      req->nr_pages);
> -	}
> -
> -	if (!locked && mm != NULL)
> -		down_write(&mm->mmap_sem);
>  	info->idx_map[u_idx].mem = INVALID_MIDX;
> +
> +	spin_unlock(&info->map_lock);
>  	if (mm != NULL)
> -		up_write(&mm->mmap_sem);
> +		up_read(&mm->mmap_sem);
>  }
>  
>  /******************************************************************
> @@ -1406,7 +1408,9 @@ static void dispatch_rw_block_io(blkif_t
>  		goto fail_response;
>  
>  	/* Check we have space on user ring - should never fail. */
> +	spin_lock(&info->map_lock);
>  	usr_idx = GET_NEXT_REQ(info->idx_map);
> +	spin_unlock(&info->map_lock);
>  	if (usr_idx >= MAX_PENDING_REQS) {
>  		WARN_ON(1);
>  		goto fail_response;
> @@ -1445,7 +1449,7 @@ static void dispatch_rw_block_io(blkif_t
>  	op = 0;
>  	mm = info->mm;
>  	if (!xen_feature(XENFEAT_auto_translated_physmap))
> -		down_write(&mm->mmap_sem);
> +		down_read(&mm->mmap_sem);
>  	for (i = 0; i < nseg; i++) {
>  		unsigned long uvaddr;
>  		unsigned long kvaddr;
> @@ -1462,9 +1466,9 @@ static void dispatch_rw_block_io(blkif_t
>  			/* Now map it to user. */
>  			ret = create_lookup_pte_addr(mm, uvaddr, &ptep);
>  			if (ret) {
> -				up_write(&mm->mmap_sem);
> +				up_read(&mm->mmap_sem);
>  				WPRINTK("Couldn't get a pte addr!\n");
> -				goto fail_flush;
> +				goto fail_response;
>  			}
>  
>  			gnttab_set_map_op(&map[op], ptep,
> @@ -1478,12 +1482,15 @@ static void dispatch_rw_block_io(blkif_t
>  			     req->seg[i].first_sect + 1);
>  	}
>  
> +	if (xen_feature(XENFEAT_auto_translated_physmap))
> +		down_read(&mm->mmap_sem);
> +
> +	spin_lock(&info->map_lock);
> +
>  	ret = HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, map, op);
>  	BUG_ON(ret);
>  
>  	if (!xen_feature(XENFEAT_auto_translated_physmap)) {
> -		up_write(&mm->mmap_sem);
> -
>  		for (i = 0; i < (nseg*2); i+=2) {
>  			unsigned long uvaddr;
>  			unsigned long offset;
> @@ -1548,18 +1555,18 @@ static void dispatch_rw_block_io(blkif_t
>  		}
>  	}
>  
> +	/*record [mmap_idx,pending_idx] to [usr_idx] mapping*/
> +	info->idx_map[usr_idx].mem = mmap_idx;
> +	info->idx_map[usr_idx].req = pending_idx;
> +
> +	spin_unlock(&info->map_lock);
> +
>  	if (ret)
>  		goto fail_flush;
>  
> -	if (xen_feature(XENFEAT_auto_translated_physmap))
> -		down_write(&mm->mmap_sem);
> -	/* Mark mapped pages as reserved: */
> -	for (i = 0; i < req->nr_segments; i++) {
> -		struct page *pg;
> -
> -		pg = idx_to_page(mmap_idx, pending_idx, i);
> -		SetPageReserved(pg);
> -		if (xen_feature(XENFEAT_auto_translated_physmap)) {
> +	if (xen_feature(XENFEAT_auto_translated_physmap)) {
> +		for (i = 0; i < nseg; i++) {
> +			struct page *pg = idx_to_page(mmap_idx, pending_idx, i);
>  			unsigned long uvaddr = MMAP_VADDR(info->user_vstart,
>  							  usr_idx, i);
>  			if (vma && uvaddr >= vma->vm_end) {
> @@ -1577,18 +1584,12 @@ static void dispatch_rw_block_io(blkif_t
>  					continue;
>  			}
>  			ret = vm_insert_page(vma, uvaddr, pg);
> -			if (ret) {
> -				up_write(&mm->mmap_sem);
> +			if (ret)
>  				goto fail_flush;
> -			}
>  		}
>  	}
> -	if (xen_feature(XENFEAT_auto_translated_physmap))
> -		up_write(&mm->mmap_sem);
>  	
> -	/*record [mmap_idx,pending_idx] to [usr_idx] mapping*/
> -	info->idx_map[usr_idx].mem = mmap_idx;
> -	info->idx_map[usr_idx].req = pending_idx;
> +	up_read(&mm->mmap_sem);
>  
>  	blkif_get(blkif);
>  	/* Finally, write the request message to the user ring. */
> @@ -1611,6 +1612,7 @@ static void dispatch_rw_block_io(blkif_t
>  	return;
>  
>   fail_flush:
> +	up_read(&mm->mmap_sem);
>  	WPRINTK("Reached Fail_flush\n");
>  	fast_flush_area(pending_req, pending_idx, usr_idx, info);
>   fail_response:



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 23 11:36:46 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 Dec 2011 11:36:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Re3QV-0003jJ-EX; Fri, 23 Dec 2011 11:36:39 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Re3QU-0003hD-Qg
	for xen-devel@lists.xensource.com; Fri, 23 Dec 2011 11:36:39 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1324640192!8446325!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODI2MQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24690 invoked from network); 23 Dec 2011 11:36:32 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Dec 2011 11:36:32 -0000
X-IronPort-AV: E=Sophos;i="4.71,398,1320624000"; 
   d="scan'208";a="9653485"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Dec 2011 11:36:32 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 23 Dec 2011 11:36:32 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Wei Wang <wei.wang2@amd.com>
Date: Fri, 23 Dec 2011 11:36:32 +0000
In-Reply-To: <bb76ba2457e629d668c0.1324639761@gran.amd.com>
References: <patchbomb.1324639749@gran.amd.com>
	<bb76ba2457e629d668c0.1324639761@gran.amd.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1324640192.7877.152.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "Keir \(Xen.org\)" <keir@xen.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"JBeulich@suse.com" <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 12 of 16] hvmloader: Build IVRS table
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2011-12-23 at 11:29 +0000, Wei Wang wrote:
> diff -r b70cf1dcb110 -r bb76ba2457e6
> xen/include/public/hvm/hvm_info_table.h
> --- a/xen/include/public/hvm/hvm_info_table.h   Thu Dec 22 16:56:45
> 2011 +0100
> +++ b/xen/include/public/hvm/hvm_info_table.h   Thu Dec 22 16:56:48
> 2011 +0100
> @@ -67,6 +67,9 @@ struct hvm_info_table {
>  
>      /* Bitmap of which CPUs are online at boot time. */
>      uint8_t     vcpu_online[(HVM_MAX_VCPUS + 7)/8];
> +
> +    /* guest iommu enabled */
> +    uint8_t     iommu_enabled;
>  };
>  
>  #endif /* __XEN_PUBLIC_HVM_HVM_INFO_TABLE_H__ */

Please can we avoid adding new things to this struct and use xenstore to
pass new configuration items instead. See Paul Durrant's recent patches
to make s3 optional via the platform/acpi_s3 node.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 23 11:36:46 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 Dec 2011 11:36:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Re3QV-0003jJ-EX; Fri, 23 Dec 2011 11:36:39 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Re3QU-0003hD-Qg
	for xen-devel@lists.xensource.com; Fri, 23 Dec 2011 11:36:39 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1324640192!8446325!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODI2MQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24690 invoked from network); 23 Dec 2011 11:36:32 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Dec 2011 11:36:32 -0000
X-IronPort-AV: E=Sophos;i="4.71,398,1320624000"; 
   d="scan'208";a="9653485"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Dec 2011 11:36:32 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 23 Dec 2011 11:36:32 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Wei Wang <wei.wang2@amd.com>
Date: Fri, 23 Dec 2011 11:36:32 +0000
In-Reply-To: <bb76ba2457e629d668c0.1324639761@gran.amd.com>
References: <patchbomb.1324639749@gran.amd.com>
	<bb76ba2457e629d668c0.1324639761@gran.amd.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1324640192.7877.152.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "Keir \(Xen.org\)" <keir@xen.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"JBeulich@suse.com" <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 12 of 16] hvmloader: Build IVRS table
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2011-12-23 at 11:29 +0000, Wei Wang wrote:
> diff -r b70cf1dcb110 -r bb76ba2457e6
> xen/include/public/hvm/hvm_info_table.h
> --- a/xen/include/public/hvm/hvm_info_table.h   Thu Dec 22 16:56:45
> 2011 +0100
> +++ b/xen/include/public/hvm/hvm_info_table.h   Thu Dec 22 16:56:48
> 2011 +0100
> @@ -67,6 +67,9 @@ struct hvm_info_table {
>  
>      /* Bitmap of which CPUs are online at boot time. */
>      uint8_t     vcpu_online[(HVM_MAX_VCPUS + 7)/8];
> +
> +    /* guest iommu enabled */
> +    uint8_t     iommu_enabled;
>  };
>  
>  #endif /* __XEN_PUBLIC_HVM_HVM_INFO_TABLE_H__ */

Please can we avoid adding new things to this struct and use xenstore to
pass new configuration items instead. See Paul Durrant's recent patches
to make s3 optional via the platform/acpi_s3 node.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 23 11:37:35 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 Dec 2011 11:37:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Re3RF-0003zs-TS; Fri, 23 Dec 2011 11:37:25 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Re3RE-0003wL-8M
	for xen-devel@lists.xensource.com; Fri, 23 Dec 2011 11:37:24 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1324640237!6469779!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODI2MQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18277 invoked from network); 23 Dec 2011 11:37:18 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Dec 2011 11:37:18 -0000
X-IronPort-AV: E=Sophos;i="4.71,398,1320624000"; 
   d="scan'208";a="9653506"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Dec 2011 11:37:17 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 23 Dec 2011 11:37:17 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Wei Wang <wei.wang2@amd.com>
Date: Fri, 23 Dec 2011 11:37:17 +0000
In-Reply-To: <7ac92c11a11a4dbdf85e.1324639763@gran.amd.com>
References: <patchbomb.1324639749@gran.amd.com>
	<7ac92c11a11a4dbdf85e.1324639763@gran.amd.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1324640237.7877.153.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "Keir \(Xen.org\)" <keir@xen.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"JBeulich@suse.com" <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 14 of 16] libxl: bind virtual bdf to
 physical bdf after device assignment
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2011-12-23 at 11:29 +0000, Wei Wang wrote:
> # HG changeset patch
> # User Wei Wang <wei.wang2@amd.com>
> # Date 1324569415 -3600
> # Node ID 7ac92c11a11a4dbdf85ef503445128be861cb400
> # Parent  00bdad5dfb7f5efd0b1cc54622b3ccb1b1b1b16f
> libxl: bind virtual bdf to physical bdf after device assignment
> 
> Signed-off-by: Wei Wang <wei.wang2@amd.com>
> 
> diff -r 00bdad5dfb7f -r 7ac92c11a11a tools/libxl/libxl_pci.c
> --- a/tools/libxl/libxl_pci.c	Thu Dec 22 16:56:52 2011 +0100
> +++ b/tools/libxl/libxl_pci.c	Thu Dec 22 16:56:55 2011 +0100
> @@ -735,6 +735,13 @@ out:
>              LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, rc, "xc_assign_device failed");
>              return ERROR_FAIL;
>          }
> +        if (LIBXL__DOMAIN_IS_TYPE(gc,  domid, HVM)) {
> +            rc = xc_domain_bind_pt_bdf(ctx->xch, domid, pcidev->vdevfn, pcidev_encode_bdf(pcidev));
> +            if ( rc ) {
> +            LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, rc, "xc_domain_bind_pt_bdf failed");
> +            return ERROR_FAIL;
> +            }
> +        }

Indentation is wrong here, or you've used hard tabs where you need 4
spaces.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 23 11:37:35 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 Dec 2011 11:37:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Re3RF-0003zs-TS; Fri, 23 Dec 2011 11:37:25 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Re3RE-0003wL-8M
	for xen-devel@lists.xensource.com; Fri, 23 Dec 2011 11:37:24 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1324640237!6469779!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODI2MQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18277 invoked from network); 23 Dec 2011 11:37:18 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Dec 2011 11:37:18 -0000
X-IronPort-AV: E=Sophos;i="4.71,398,1320624000"; 
   d="scan'208";a="9653506"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Dec 2011 11:37:17 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 23 Dec 2011 11:37:17 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Wei Wang <wei.wang2@amd.com>
Date: Fri, 23 Dec 2011 11:37:17 +0000
In-Reply-To: <7ac92c11a11a4dbdf85e.1324639763@gran.amd.com>
References: <patchbomb.1324639749@gran.amd.com>
	<7ac92c11a11a4dbdf85e.1324639763@gran.amd.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1324640237.7877.153.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "Keir \(Xen.org\)" <keir@xen.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"JBeulich@suse.com" <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 14 of 16] libxl: bind virtual bdf to
 physical bdf after device assignment
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2011-12-23 at 11:29 +0000, Wei Wang wrote:
> # HG changeset patch
> # User Wei Wang <wei.wang2@amd.com>
> # Date 1324569415 -3600
> # Node ID 7ac92c11a11a4dbdf85ef503445128be861cb400
> # Parent  00bdad5dfb7f5efd0b1cc54622b3ccb1b1b1b16f
> libxl: bind virtual bdf to physical bdf after device assignment
> 
> Signed-off-by: Wei Wang <wei.wang2@amd.com>
> 
> diff -r 00bdad5dfb7f -r 7ac92c11a11a tools/libxl/libxl_pci.c
> --- a/tools/libxl/libxl_pci.c	Thu Dec 22 16:56:52 2011 +0100
> +++ b/tools/libxl/libxl_pci.c	Thu Dec 22 16:56:55 2011 +0100
> @@ -735,6 +735,13 @@ out:
>              LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, rc, "xc_assign_device failed");
>              return ERROR_FAIL;
>          }
> +        if (LIBXL__DOMAIN_IS_TYPE(gc,  domid, HVM)) {
> +            rc = xc_domain_bind_pt_bdf(ctx->xch, domid, pcidev->vdevfn, pcidev_encode_bdf(pcidev));
> +            if ( rc ) {
> +            LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, rc, "xc_domain_bind_pt_bdf failed");
> +            return ERROR_FAIL;
> +            }
> +        }

Indentation is wrong here, or you've used hard tabs where you need 4
spaces.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 23 11:50:27 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 Dec 2011 11:50:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Re3de-0004b1-If; Fri, 23 Dec 2011 11:50:14 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Wang2@amd.com>) id 1Re3dc-0004at-Qn
	for xen-devel@lists.xensource.com; Fri, 23 Dec 2011 11:50:13 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1324640881!49449917!1
X-Originating-IP: [216.32.181.181]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13040 invoked from network); 23 Dec 2011 11:48:02 -0000
Received: from ch1ehsobe001.messaging.microsoft.com (HELO
	ch1outboundpool.messaging.microsoft.com) (216.32.181.181)
	by server-14.tower-27.messagelabs.com with AES128-SHA encrypted SMTP;
	23 Dec 2011 11:48:02 -0000
Received: from mail42-ch1-R.bigfish.com (10.43.68.244) by
	CH1EHSOBE002.bigfish.com (10.43.70.52) with Microsoft SMTP Server id
	14.1.225.23; Fri, 23 Dec 2011 11:49:54 +0000
Received: from mail42-ch1 (localhost [127.0.0.1])	by mail42-ch1-R.bigfish.com
	(Postfix) with ESMTP id CDFAF1C01AA;
	Fri, 23 Dec 2011 11:50:34 +0000 (UTC)
X-SpamScore: -16
X-BigFish: VPS-16(zz936eK1432N98dK4015Lzz1202hzzz2dh668h839h93fh)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
X-FB-SS: 13,
Received: from mail42-ch1 (localhost.localdomain [127.0.0.1]) by mail42-ch1
	(MessageSwitch) id 1324641034687043_7080;
	Fri, 23 Dec 2011 11:50:34 +0000 (UTC)
Received: from CH1EHSMHS030.bigfish.com (snatpool1.int.messaging.microsoft.com
	[10.43.68.245])	by mail42-ch1.bigfish.com (Postfix) with ESMTP id
	A1CC7540046;	Fri, 23 Dec 2011 11:50:34 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	CH1EHSMHS030.bigfish.com (10.43.70.30) with Microsoft SMTP Server id
	14.1.225.23; Fri, 23 Dec 2011 11:49:54 +0000
X-WSS-ID: 0LWNNJG-02-1KC-02
X-M-MSG: 
Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com
	[163.181.249.73])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp02.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2C60DC80D1;	Fri, 23 Dec 2011 05:50:03 -0600 (CST)
Received: from sausexhtp02.amd.com (163.181.3.152) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Fri, 23 Dec 2011 05:50:22 -0600
Received: from storexhtp01.amd.com (172.24.4.3) by sausexhtp02.amd.com
	(163.181.3.152) with Microsoft SMTP Server (TLS) id 8.3.213.0;
	Fri, 23 Dec 2011 05:50:04 -0600
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp01.amd.com
	(172.24.4.3) with Microsoft SMTP Server id 8.3.213.0; Fri, 23 Dec 2011
	06:49:30 -0500
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id DF88C49C0F1; Fri, 23 Dec 2011
	11:49:28 +0000 (GMT)
Received: from gran.osrc.amd.com (gran.osrc.amd.com [165.204.15.57])	by
	mail.osrc.amd.com (Postfix) with ESMTP id C9D045940FF; Fri, 23 Dec 2011
	12:49:28 +0100 (CET)
From: Wei Wang2 <wei.wang2@amd.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Fri, 23 Dec 2011 12:52:08 +0100
User-Agent: KMail/1.9.6 (enterprise 20070904.708012)
References: <patchbomb.1324639749@gran.amd.com>
	<bb76ba2457e629d668c0.1324639761@gran.amd.com>
	<1324640192.7877.152.camel@zakaz.uk.xensource.com>
In-Reply-To: <1324640192.7877.152.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
Message-ID: <201112231252.08628.wei.wang2@amd.com>
X-OriginatorOrg: amd.com
Cc: "Keir \(Xen.org\)" <keir@xen.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"JBeulich@suse.com" <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 12 of 16] hvmloader: Build IVRS table
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Friday 23 December 2011 12:36:32 Ian Campbell wrote:
> On Fri, 2011-12-23 at 11:29 +0000, Wei Wang wrote:
> > diff -r b70cf1dcb110 -r bb76ba2457e6
> > xen/include/public/hvm/hvm_info_table.h
> > --- a/xen/include/public/hvm/hvm_info_table.h   Thu Dec 22 16:56:45
> > 2011 +0100
> > +++ b/xen/include/public/hvm/hvm_info_table.h   Thu Dec 22 16:56:48
> > 2011 +0100
> > @@ -67,6 +67,9 @@ struct hvm_info_table {
> >
> >      /* Bitmap of which CPUs are online at boot time. */
> >      uint8_t     vcpu_online[(HVM_MAX_VCPUS + 7)/8];
> > +
> > +    /* guest iommu enabled */
> > +    uint8_t     iommu_enabled;
> >  };
> >
> >  #endif /* __XEN_PUBLIC_HVM_HVM_INFO_TABLE_H__ */
>
> Please can we avoid adding new things to this struct and use xenstore to
> pass new configuration items instead. See Paul Durrant's recent patches
> to make s3 optional via the platform/acpi_s3 node.
> Ian.
Good point, Will use xenstore_read in next try.
Thanks,
Wei


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 23 11:50:27 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 Dec 2011 11:50:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Re3de-0004b1-If; Fri, 23 Dec 2011 11:50:14 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Wang2@amd.com>) id 1Re3dc-0004at-Qn
	for xen-devel@lists.xensource.com; Fri, 23 Dec 2011 11:50:13 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1324640881!49449917!1
X-Originating-IP: [216.32.181.181]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13040 invoked from network); 23 Dec 2011 11:48:02 -0000
Received: from ch1ehsobe001.messaging.microsoft.com (HELO
	ch1outboundpool.messaging.microsoft.com) (216.32.181.181)
	by server-14.tower-27.messagelabs.com with AES128-SHA encrypted SMTP;
	23 Dec 2011 11:48:02 -0000
Received: from mail42-ch1-R.bigfish.com (10.43.68.244) by
	CH1EHSOBE002.bigfish.com (10.43.70.52) with Microsoft SMTP Server id
	14.1.225.23; Fri, 23 Dec 2011 11:49:54 +0000
Received: from mail42-ch1 (localhost [127.0.0.1])	by mail42-ch1-R.bigfish.com
	(Postfix) with ESMTP id CDFAF1C01AA;
	Fri, 23 Dec 2011 11:50:34 +0000 (UTC)
X-SpamScore: -16
X-BigFish: VPS-16(zz936eK1432N98dK4015Lzz1202hzzz2dh668h839h93fh)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
X-FB-SS: 13,
Received: from mail42-ch1 (localhost.localdomain [127.0.0.1]) by mail42-ch1
	(MessageSwitch) id 1324641034687043_7080;
	Fri, 23 Dec 2011 11:50:34 +0000 (UTC)
Received: from CH1EHSMHS030.bigfish.com (snatpool1.int.messaging.microsoft.com
	[10.43.68.245])	by mail42-ch1.bigfish.com (Postfix) with ESMTP id
	A1CC7540046;	Fri, 23 Dec 2011 11:50:34 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	CH1EHSMHS030.bigfish.com (10.43.70.30) with Microsoft SMTP Server id
	14.1.225.23; Fri, 23 Dec 2011 11:49:54 +0000
X-WSS-ID: 0LWNNJG-02-1KC-02
X-M-MSG: 
Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com
	[163.181.249.73])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp02.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2C60DC80D1;	Fri, 23 Dec 2011 05:50:03 -0600 (CST)
Received: from sausexhtp02.amd.com (163.181.3.152) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Fri, 23 Dec 2011 05:50:22 -0600
Received: from storexhtp01.amd.com (172.24.4.3) by sausexhtp02.amd.com
	(163.181.3.152) with Microsoft SMTP Server (TLS) id 8.3.213.0;
	Fri, 23 Dec 2011 05:50:04 -0600
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp01.amd.com
	(172.24.4.3) with Microsoft SMTP Server id 8.3.213.0; Fri, 23 Dec 2011
	06:49:30 -0500
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id DF88C49C0F1; Fri, 23 Dec 2011
	11:49:28 +0000 (GMT)
Received: from gran.osrc.amd.com (gran.osrc.amd.com [165.204.15.57])	by
	mail.osrc.amd.com (Postfix) with ESMTP id C9D045940FF; Fri, 23 Dec 2011
	12:49:28 +0100 (CET)
From: Wei Wang2 <wei.wang2@amd.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Fri, 23 Dec 2011 12:52:08 +0100
User-Agent: KMail/1.9.6 (enterprise 20070904.708012)
References: <patchbomb.1324639749@gran.amd.com>
	<bb76ba2457e629d668c0.1324639761@gran.amd.com>
	<1324640192.7877.152.camel@zakaz.uk.xensource.com>
In-Reply-To: <1324640192.7877.152.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
Message-ID: <201112231252.08628.wei.wang2@amd.com>
X-OriginatorOrg: amd.com
Cc: "Keir \(Xen.org\)" <keir@xen.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"JBeulich@suse.com" <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 12 of 16] hvmloader: Build IVRS table
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Friday 23 December 2011 12:36:32 Ian Campbell wrote:
> On Fri, 2011-12-23 at 11:29 +0000, Wei Wang wrote:
> > diff -r b70cf1dcb110 -r bb76ba2457e6
> > xen/include/public/hvm/hvm_info_table.h
> > --- a/xen/include/public/hvm/hvm_info_table.h   Thu Dec 22 16:56:45
> > 2011 +0100
> > +++ b/xen/include/public/hvm/hvm_info_table.h   Thu Dec 22 16:56:48
> > 2011 +0100
> > @@ -67,6 +67,9 @@ struct hvm_info_table {
> >
> >      /* Bitmap of which CPUs are online at boot time. */
> >      uint8_t     vcpu_online[(HVM_MAX_VCPUS + 7)/8];
> > +
> > +    /* guest iommu enabled */
> > +    uint8_t     iommu_enabled;
> >  };
> >
> >  #endif /* __XEN_PUBLIC_HVM_HVM_INFO_TABLE_H__ */
>
> Please can we avoid adding new things to this struct and use xenstore to
> pass new configuration items instead. See Paul Durrant's recent patches
> to make s3 optional via the platform/acpi_s3 node.
> Ian.
Good point, Will use xenstore_read in next try.
Thanks,
Wei


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 23 11:54:24 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 Dec 2011 11:54:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Re3hP-0004ka-7l; Fri, 23 Dec 2011 11:54:07 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Wang2@amd.com>) id 1Re3hN-0004kS-V6
	for xen-devel@lists.xensource.com; Fri, 23 Dec 2011 11:54:06 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1324641238!5949715!1
X-Originating-IP: [216.32.181.184]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21764 invoked from network); 23 Dec 2011 11:54:00 -0000
Received: from ch1ehsobe004.messaging.microsoft.com (HELO
	ch1outboundpool.messaging.microsoft.com) (216.32.181.184)
	by server-13.tower-21.messagelabs.com with AES128-SHA encrypted SMTP;
	23 Dec 2011 11:54:00 -0000
Received: from mail159-ch1-R.bigfish.com (10.43.68.244) by
	CH1EHSOBE014.bigfish.com (10.43.70.64) with Microsoft SMTP Server id
	14.1.225.23; Fri, 23 Dec 2011 11:53:46 +0000
Received: from mail159-ch1 (localhost [127.0.0.1])	by
	mail159-ch1-R.bigfish.com (Postfix) with ESMTP id 95E7E3C03C8;
	Fri, 23 Dec 2011 11:54:26 +0000 (UTC)
X-SpamScore: -16
X-BigFish: VPS-16(zz936eK1432N98dK4015Lzz1202hzz8275bhz2dh668h839h93fh)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
Received: from mail159-ch1 (localhost.localdomain [127.0.0.1]) by mail159-ch1
	(MessageSwitch) id 1324641264441776_14691;
	Fri, 23 Dec 2011 11:54:24 +0000 (UTC)
Received: from CH1EHSMHS001.bigfish.com (snatpool1.int.messaging.microsoft.com
	[10.43.68.242])	by mail159-ch1.bigfish.com (Postfix) with ESMTP id
	5D2BE5E022F;	Fri, 23 Dec 2011 11:54:24 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	CH1EHSMHS001.bigfish.com (10.43.70.1) with Microsoft SMTP Server id
	14.1.225.23; Fri, 23 Dec 2011 11:53:43 +0000
X-WSS-ID: 0LWNNPT-02-1O8-02
X-M-MSG: 
Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com
	[163.181.249.73])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp02.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 212EEC80D4;	Fri, 23 Dec 2011 05:53:53 -0600 (CST)
Received: from SAUSEXDAG02.amd.com (163.181.55.2) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Fri, 23 Dec 2011 05:54:11 -0600
Received: from storexhtp02.amd.com (172.24.4.4) by sausexdag02.amd.com
	(163.181.55.2) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Fri, 23 Dec 2011 05:53:53 -0600
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Fri, 23 Dec 2011
	06:53:52 -0500
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 8CF5C49C0F1; Fri, 23 Dec 2011
	11:53:51 +0000 (GMT)
Received: from gran.osrc.amd.com (gran.osrc.amd.com [165.204.15.57])	by
	mail.osrc.amd.com (Postfix) with ESMTP id 71AE65940FF; Fri, 23 Dec 2011
	12:53:51 +0100 (CET)
From: Wei Wang2 <wei.wang2@amd.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Fri, 23 Dec 2011 12:56:30 +0100
User-Agent: KMail/1.9.6 (enterprise 20070904.708012)
References: <patchbomb.1324639749@gran.amd.com>
	<7ac92c11a11a4dbdf85e.1324639763@gran.amd.com>
	<1324640237.7877.153.camel@zakaz.uk.xensource.com>
In-Reply-To: <1324640237.7877.153.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
Message-ID: <201112231256.31441.wei.wang2@amd.com>
X-OriginatorOrg: amd.com
Cc: "Keir \(Xen.org\)" <keir@xen.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"JBeulich@suse.com" <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 14 of 16] libxl: bind virtual bdf to
	physical bdf after device assignment
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Friday 23 December 2011 12:37:17 Ian Campbell wrote:
> On Fri, 2011-12-23 at 11:29 +0000, Wei Wang wrote:
> > # HG changeset patch
> > # User Wei Wang <wei.wang2@amd.com>
> > # Date 1324569415 -3600
> > # Node ID 7ac92c11a11a4dbdf85ef503445128be861cb400
> > # Parent  00bdad5dfb7f5efd0b1cc54622b3ccb1b1b1b16f
> > libxl: bind virtual bdf to physical bdf after device assignment
> >
> > Signed-off-by: Wei Wang <wei.wang2@amd.com>
> >
> > diff -r 00bdad5dfb7f -r 7ac92c11a11a tools/libxl/libxl_pci.c
> > --- a/tools/libxl/libxl_pci.c	Thu Dec 22 16:56:52 2011 +0100
> > +++ b/tools/libxl/libxl_pci.c	Thu Dec 22 16:56:55 2011 +0100
> > @@ -735,6 +735,13 @@ out:
> >              LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, rc,
> > "xc_assign_device failed"); return ERROR_FAIL;
> >          }
> > +        if (LIBXL__DOMAIN_IS_TYPE(gc,  domid, HVM)) {
> > +            rc = xc_domain_bind_pt_bdf(ctx->xch, domid, pcidev->vdevfn,
> > pcidev_encode_bdf(pcidev)); +            if ( rc ) {
> > +            LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, rc,
> > "xc_domain_bind_pt_bdf failed"); +            return ERROR_FAIL;
> > +            }
> > +        }
>
> Indentation is wrong here, or you've used hard tabs where you need 4
> spaces.
Yes, indeed. I will fix it.
Thanks,
Wei

> Ian.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 23 11:54:24 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 Dec 2011 11:54:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Re3hP-0004ka-7l; Fri, 23 Dec 2011 11:54:07 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Wang2@amd.com>) id 1Re3hN-0004kS-V6
	for xen-devel@lists.xensource.com; Fri, 23 Dec 2011 11:54:06 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1324641238!5949715!1
X-Originating-IP: [216.32.181.184]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21764 invoked from network); 23 Dec 2011 11:54:00 -0000
Received: from ch1ehsobe004.messaging.microsoft.com (HELO
	ch1outboundpool.messaging.microsoft.com) (216.32.181.184)
	by server-13.tower-21.messagelabs.com with AES128-SHA encrypted SMTP;
	23 Dec 2011 11:54:00 -0000
Received: from mail159-ch1-R.bigfish.com (10.43.68.244) by
	CH1EHSOBE014.bigfish.com (10.43.70.64) with Microsoft SMTP Server id
	14.1.225.23; Fri, 23 Dec 2011 11:53:46 +0000
Received: from mail159-ch1 (localhost [127.0.0.1])	by
	mail159-ch1-R.bigfish.com (Postfix) with ESMTP id 95E7E3C03C8;
	Fri, 23 Dec 2011 11:54:26 +0000 (UTC)
X-SpamScore: -16
X-BigFish: VPS-16(zz936eK1432N98dK4015Lzz1202hzz8275bhz2dh668h839h93fh)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
Received: from mail159-ch1 (localhost.localdomain [127.0.0.1]) by mail159-ch1
	(MessageSwitch) id 1324641264441776_14691;
	Fri, 23 Dec 2011 11:54:24 +0000 (UTC)
Received: from CH1EHSMHS001.bigfish.com (snatpool1.int.messaging.microsoft.com
	[10.43.68.242])	by mail159-ch1.bigfish.com (Postfix) with ESMTP id
	5D2BE5E022F;	Fri, 23 Dec 2011 11:54:24 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	CH1EHSMHS001.bigfish.com (10.43.70.1) with Microsoft SMTP Server id
	14.1.225.23; Fri, 23 Dec 2011 11:53:43 +0000
X-WSS-ID: 0LWNNPT-02-1O8-02
X-M-MSG: 
Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com
	[163.181.249.73])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp02.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 212EEC80D4;	Fri, 23 Dec 2011 05:53:53 -0600 (CST)
Received: from SAUSEXDAG02.amd.com (163.181.55.2) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Fri, 23 Dec 2011 05:54:11 -0600
Received: from storexhtp02.amd.com (172.24.4.4) by sausexdag02.amd.com
	(163.181.55.2) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Fri, 23 Dec 2011 05:53:53 -0600
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Fri, 23 Dec 2011
	06:53:52 -0500
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 8CF5C49C0F1; Fri, 23 Dec 2011
	11:53:51 +0000 (GMT)
Received: from gran.osrc.amd.com (gran.osrc.amd.com [165.204.15.57])	by
	mail.osrc.amd.com (Postfix) with ESMTP id 71AE65940FF; Fri, 23 Dec 2011
	12:53:51 +0100 (CET)
From: Wei Wang2 <wei.wang2@amd.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Fri, 23 Dec 2011 12:56:30 +0100
User-Agent: KMail/1.9.6 (enterprise 20070904.708012)
References: <patchbomb.1324639749@gran.amd.com>
	<7ac92c11a11a4dbdf85e.1324639763@gran.amd.com>
	<1324640237.7877.153.camel@zakaz.uk.xensource.com>
In-Reply-To: <1324640237.7877.153.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
Message-ID: <201112231256.31441.wei.wang2@amd.com>
X-OriginatorOrg: amd.com
Cc: "Keir \(Xen.org\)" <keir@xen.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"JBeulich@suse.com" <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 14 of 16] libxl: bind virtual bdf to
	physical bdf after device assignment
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Friday 23 December 2011 12:37:17 Ian Campbell wrote:
> On Fri, 2011-12-23 at 11:29 +0000, Wei Wang wrote:
> > # HG changeset patch
> > # User Wei Wang <wei.wang2@amd.com>
> > # Date 1324569415 -3600
> > # Node ID 7ac92c11a11a4dbdf85ef503445128be861cb400
> > # Parent  00bdad5dfb7f5efd0b1cc54622b3ccb1b1b1b16f
> > libxl: bind virtual bdf to physical bdf after device assignment
> >
> > Signed-off-by: Wei Wang <wei.wang2@amd.com>
> >
> > diff -r 00bdad5dfb7f -r 7ac92c11a11a tools/libxl/libxl_pci.c
> > --- a/tools/libxl/libxl_pci.c	Thu Dec 22 16:56:52 2011 +0100
> > +++ b/tools/libxl/libxl_pci.c	Thu Dec 22 16:56:55 2011 +0100
> > @@ -735,6 +735,13 @@ out:
> >              LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, rc,
> > "xc_assign_device failed"); return ERROR_FAIL;
> >          }
> > +        if (LIBXL__DOMAIN_IS_TYPE(gc,  domid, HVM)) {
> > +            rc = xc_domain_bind_pt_bdf(ctx->xch, domid, pcidev->vdevfn,
> > pcidev_encode_bdf(pcidev)); +            if ( rc ) {
> > +            LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, rc,
> > "xc_domain_bind_pt_bdf failed"); +            return ERROR_FAIL;
> > +            }
> > +        }
>
> Indentation is wrong here, or you've used hard tabs where you need 4
> spaces.
Yes, indeed. I will fix it.
Thanks,
Wei

> Ian.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 23 11:59:54 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 Dec 2011 11:59:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Re3mS-00052T-7H; Fri, 23 Dec 2011 11:59:20 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1Re3mR-00052L-5Z
	for xen-devel@lists.xensource.com; Fri, 23 Dec 2011 11:59:19 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1324641537!60085441!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjU2NjQ=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10779 invoked from network); 23 Dec 2011 11:58:58 -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;
	23 Dec 2011 11:58:58 -0000
X-IronPort-AV: E=Sophos;i="4.71,398,1320642000"; d="scan'208";a="175276634"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Dec 2011 06:59:16 -0500
Received: from [10.80.2.18] (10.80.2.18) by FTLPMAILMX02.citrite.net
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Fri, 23 Dec 2011
	06:59:15 -0500
Message-ID: <4EF46D12.6040100@citrix.com>
Date: Fri, 23 Dec 2011 11:59:14 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.23) Gecko/20110921 Lightning/1.0b2 Thunderbird/3.1.15
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <patchbomb.1324575382@andrewcoop.uk.xensource.com>
	<23c31d59ffb1590815bc.1324575385@andrewcoop.uk.xensource.com>
	<4EF452940200007800069B89@nat28.tlf.novell.com>
In-Reply-To: <4EF452940200007800069B89@nat28.tlf.novell.com>
X-Enigmail-Version: 1.1.2
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 3 of 3] KEXEC: Allocate crash structures in
 low memory
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 23/12/11 09:06, Jan Beulich wrote:
>>>> On 22.12.11 at 18:36, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>> On 64bit Xen with 32bit dom0 and crashkernel, xmalloc'ing items such
>> as the CPU crash notes will go into the xenheap, which tends to be in
>> upper memory.  This causes problems on machines with more than 64GB
>> (or 4GB if no PAE support) of ram as the crashkernel physically cant
>> access the crash notes.
> What use is a crash dump taken with a 32-bit kernel on a machine
> with more than 64G (or more than 4G is the crash kernel doesn't
> support PAE)?

Very little use at all, which is the reason for this change.  The
correct solution is indeed to use a 64bit dom0 kernel, but while
politics is preventing that from happening, another solution has to be
found.  I doubt that XenServer is the only product which would benifit,
which is why the changes are presented for upstreaming.

>> The solution is to force Xen to allocate certain structures in lower
>> memory.  This is achieved by introducing two new command line
>> parameters; low_crashinfo and crashinfo_maxaddr.  Because of the
>> potential impact on 32bit PV guests, and that this problem does not
>> exist for 64bit dom0 on 64bit Xen, this new functionality defaults to
>> the codebase's previous behavior, requiring the user to explicitly
>> add extra command line parameters to change the behavior.
>>
>> This patch consists of 3 logically distinct but closely related
>> changes.
>>  1) Add the two new command line parameters.
> Do you really need both? Just being able to set the max address
> would seem sufficient...

The plan, as explained in the comments, is for two (or perhaps more)
levels of low allocation.  "min" means "allocate enough stuff low for
the crash kernel to grab the Xen ring buffer" where "all" will include
extra things such as the page tables so the crash kernel can generate
full stack traces given the PT_STATUS notes.  The differentiation is
because "min" should not impact very much at all on other memory
restricted things such as 32bit PV guests, whereas "all" certainly will.

>>  2) Change crash note allocation to use lower memory when instructed.
>>  3) Change the conring buffer to use lower memory when instructed.
> Why does this one need moving, but none of the other Xen data
> structures? If anything, I would have expected you to limit the Xen
> heap altogether, so that automatically all allocations get done in a
> way so that at least Xen's data structures are available in the
> (truncated) dump.

This is part of the "min" option which is trying to have the least
possible impact.  The idea is to have this in low memory, use the
"console_to_ring" boot option to copy dom0 dmesg into conring, and pass
its physical address and size in a crash note, so that the crash kernel
environment grab it all.

>> There result is that the crash notes and console ring will be placed
>> in lower memory so useful information can be recovered in the case of
>> a crash.
>>
>> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
>>
>> diff -r 3da37c68284f -r 23c31d59ffb1 xen/arch/x86/setup.c
>> --- a/xen/arch/x86/setup.c
>> +++ b/xen/arch/x86/setup.c
>> @@ -586,6 +586,10 @@ void __init __start_xen(unsigned long mb
>>      }
>>      cmdline_parse(cmdline);
>>  
>> +    /* Must be after command line argument parsing and before 
>> +     * allocing any xenheap structures wanted in lower memory. */
>> +    kexec_early_calculations();
>> +
> But does it really need to be *this* early?

Possibly not, but it needs to be before console_preirq_init() which is
not much later.

>>      parse_video_info();
>>  
>>      set_current((struct vcpu *)0xfffff000); /* debug sanity */
>> diff -r 3da37c68284f -r 23c31d59ffb1 xen/common/kexec.c
>> --- a/xen/common/kexec.c
>> +++ b/xen/common/kexec.c
>> @@ -36,7 +36,9 @@ bool_t kexecing = FALSE;
>>  typedef struct { Elf_Note * start; size_t size; } crash_note_range_t;
>>  static crash_note_range_t * crash_notes;
>>  
>> -/* Lock to prevent race conditions when allocating the crash note buffers. 
>> */
>> +/* Lock to prevent race conditions when allocating the crash note buffers.
>> + * It also serves to protect calls to alloc_from_crash_heap when allocating
>> + * crash note buffers in lower memory. */
>>  static DEFINE_SPINLOCK(crash_notes_lock);
>>  
>>  static Elf_Note *xen_crash_note;
>> @@ -70,6 +72,23 @@ static struct {
>>      (_d_)->start = (_s_)->start; \
>>  } while (0)
>>  
>> +/* Low crashinfo mode.  Start as INVALID so serveral codepaths can set up
>> + * defaults without needing to know the state of the others. */
>> +enum low_crashinfo low_crashinfo_mode = LOW_CRASHINFO_INVALID;
>> +
>> +/* This value is only considered if low_crash_mode is set to MIN or ALL, so
>> + * setting a default here is safe. Default to 4GB.  This is because the 
>> current
>> + * KEXEC_CMD_get_range compat hypercall trucates 64bit pointers to 32 bits. 
>> The
>> + * typical usecase for crashinfo_maxaddr will be for 64bit Xen with 32bit 
>> dom0 
>> + * and 32bit crash kernel. */
>> +static paddr_t crashinfo_maxaddr = 4ULL << 30;
> __initdata

Good point

>> +
>> +/* = log base 2 of crashinfo_maxaddr after checking for sanity. */
>> +paddr_t crashinfo_maxaddr_bits = 0;
>> +
>> +/* Pointers to keep track of the crash heap region. */
>> +static void *crash_heap_current = NULL, *crash_heap_end = NULL;
>> +
>>  /*
>>   * Parse command lines in the format
>>   *
>> @@ -148,6 +167,58 @@ static void __init parse_crashkernel(con
>>  }
>>  custom_param("crashkernel", parse_crashkernel);
>>  
>> +/* Parse command lines in the format:
>> + *
>> + *   low_crashinfo=[none,min,all]
>> + * 
>> + * - none disables the low allocation of crash info.
>> + * - min will allocate enough low information for the crash kernel to be 
>> able
>> + *       to extract the hypervisor and dom0 message ring buffers.
>> + * - all will allocate additional structures such as domain and vcpu structs
>> + *       low so the crash kernel can perform an extended analysis of state.
>> + */
>> +static void __init parse_low_crashinfo(const char * str)
>> +{
>> +
>> +    if ( !strlen(str) )
>> +        /* default to min if user just specifies "low_crashinfo" */
>> +        low_crashinfo_mode = LOW_CRASHINFO_MIN;
>> +    else if ( !strcmp(str, "none" ) )
>> +        low_crashinfo_mode = LOW_CRASHINFO_NONE;
>> +    else if ( !strcmp(str, "min" ) )
>> +        low_crashinfo_mode = LOW_CRASHINFO_MIN;
>> +    else if ( !strcmp(str, "all" ) )
>> +        low_crashinfo_mode = LOW_CRASHINFO_ALL;
>> +    else
>> +    {
>> +        printk("Unknown low_crashinfo parameter '%s'.  Defaulting to 
>> min.\n", str);
>> +        low_crashinfo_mode = LOW_CRASHINFO_MIN;
>> +    }
>> +}
>> +custom_param("low_crashinfo", parse_low_crashinfo);
>> +
>> +/* Parse command lines in the format:
>> + * 
>> + *   crashinfo_maxaddr=<addr>
>> + *
>> + * <addr> will be rounded down to the nearest power of two.  Defaults to 64G
>> + */
>> +static void __init parse_crashinfo_maxaddr(const char * str)
>> +{
>> +    u64 addr;
>> +
>> +    /* if low_crashinfo_mode is unset, default to min. */
>> +    if ( low_crashinfo_mode == LOW_CRASHINFO_INVALID )
>> +        low_crashinfo_mode = LOW_CRASHINFO_MIN;
>> +
>> +    if ( (addr = parse_size_and_unit(str, NULL)) )
>> +        crashinfo_maxaddr = addr;
>> +    else
>> +        printk("Unable to parse crashinfo_maxaddr. Defaulting to %p\n",
>> +               (void*)crashinfo_maxaddr);
>> +}
>> +custom_param("crashinfo_maxaddr", parse_crashinfo_maxaddr);
>> +
>>  void __init set_kexec_crash_area_size(u64 system_ram)
>>  {
>>      unsigned int idx;
>> @@ -306,6 +377,20 @@ static size_t sizeof_cpu_notes(const uns
>>      return bytes;
>>  }
>>  
>> +/* Allocate size_t bytes of space from the previously allocated
>> + * crash heap if the user has requested that crash notes be allocated
>> + * in lower memory.  There is currently no case where the crash notes
>> + * should be free()'d. */
>> +static void * alloc_from_crash_heap(const size_t bytes)
>> +{
>> +    void * ret;
>> +    if ( crash_heap_current + bytes > crash_heap_end )
>> +        return NULL;
>> +    ret = (void*)crash_heap_current;
>> +    crash_heap_current += bytes;
>> +    return ret;
>> +}
>> +
>>  /* Allocate a crash note buffer for a newly onlined cpu. */
>>  static int kexec_init_cpu_notes(const unsigned long cpu)
>>  {
>> @@ -320,7 +405,10 @@ static int kexec_init_cpu_notes(const un
>>          return ret;
>>  
>>      nr_bytes = sizeof_cpu_notes(cpu);
>> -    note = xmalloc_bytes(nr_bytes);
>> +
>> +    /* If we dont care about the position of allocation, malloc. */
>> +    if ( low_crashinfo_mode == LOW_CRASHINFO_NONE )
>> +        note = xmalloc_bytes(nr_bytes);
>>  
>>      /* Protect the write into crash_notes[] with a spinlock, as this 
>> function
>>       * is on a hotplug path and a hypercall path. */
>> @@ -338,6 +426,11 @@ static int kexec_init_cpu_notes(const un
>>      }
>>      else
>>      {
>> +        /* If we care about memory possition, alloc from the crash heap,
>> +         * also protected by the crash_notes_lock. */
>> +        if ( low_crashinfo_mode > LOW_CRASHINFO_NONE )
>> +            note = alloc_from_crash_heap(nr_bytes);
>> +
>>          crash_notes[cpu].start = note;
>>          crash_notes[cpu].size = nr_bytes;
>>          spin_unlock(&crash_notes_lock);
>> @@ -397,6 +490,24 @@ static struct notifier_block cpu_nfb = {
>>      .notifier_call = cpu_callback
>>  };
>>  
>> +void __init kexec_early_calculations(void)
>> +{
>> +    /* If low_crashinfo_mode is still INVALID, neither "low_crashinfo" nor
>> +     * "crashinfo_maxaddr" have been specified on the command line, so
>> +     * explicitly set to NONE. */
>> +    if ( low_crashinfo_mode == LOW_CRASHINFO_INVALID )
>> +        low_crashinfo_mode = LOW_CRASHINFO_NONE;
>> +
>> +    crashinfo_maxaddr_bits = 0;
>> +    if ( low_crashinfo_mode > LOW_CRASHINFO_NONE )
>> +    {
>> +        paddr_t tmp = crashinfo_maxaddr;
>> +
>> +        while ( tmp >>= 1 )
>> +            crashinfo_maxaddr_bits++;
> fls() or some of its cousins

Ok

>> +    }
>> +}
>> +
>>  static int __init kexec_init(void)
>>  {
>>      void *cpu = (void *)(unsigned long)smp_processor_id();
>> @@ -407,6 +518,29 @@ static int __init kexec_init(void)
>>  
>>      register_keyhandler('C', &crashdump_trigger_keyhandler);
>>  
>> +    if ( low_crashinfo_mode > LOW_CRASHINFO_NONE )
>> +    {
>> +        size_t crash_heap_size;
>> +
>> +        /* This calculation is safe even if the machine is booted in 
>> +         * uniprocessor mode. */
>> +        crash_heap_size = sizeof_cpu_notes(0) +
>> +            sizeof_cpu_notes(1) * (nr_cpu_ids - 1);
>> +        crash_heap_size = PAGE_ALIGN(crash_heap_size);
>> +
>> +        crash_heap_current = alloc_xenheap_pages(
>> +            get_order_from_bytes(crash_heap_size),
>> +            MEMF_bits(crashinfo_maxaddr_bits) );
>> +
>> +        if ( crash_heap_current )
>> +            crash_heap_end = crash_heap_current + crash_heap_size;
>> +        else
>> +            return -ENOMEM;
> Constructs like this generally look bogus to me, as
>
>         if ( !crash_heap_current )
>             return -ENOMEM;
>         ...
>
> is shorter and (to me at least) more clear.

True - for a long time I was debating whether to return ENOMEM at this
point at not, so I clearly didn't consider clarity when deciding to add
it in.  I will fix this.

>> +    }
>> +
>> +    /* crash_notes may be allocated anywhere Xen can reach in memory.
>> +       Only the individual CPU crash notes themselves must be allocated
>> +       in lower memory if requested. */
>>      crash_notes = xmalloc_array(crash_note_range_t, nr_cpu_ids);
>>      if ( ! crash_notes )
>>          return -ENOMEM;
>> diff -r 3da37c68284f -r 23c31d59ffb1 xen/drivers/char/console.c
>> --- a/xen/drivers/char/console.c
>> +++ b/xen/drivers/char/console.c
>> @@ -584,6 +584,7 @@ void __init console_init_postirq(void)
>>  {
>>      char *ring;
>>      unsigned int i, order;
>> +    u64 memflags;
>>  
>>      serial_init_postirq();
>>  
>> @@ -591,7 +592,8 @@ void __init console_init_postirq(void)
>>          opt_conring_size = num_present_cpus() << (9 + xenlog_lower_thresh);
>>  
>>      order = get_order_from_bytes(max(opt_conring_size, conring_size));
>> -    while ( (ring = alloc_xenheap_pages(order, 0)) == NULL )
>> +    memflags = low_crashinfo_mode > LOW_CRASHINFO_NONE ? 
>> MEMF_bits(crashinfo_maxaddr_bits) : 0;
>> +    while ( (ring = alloc_xenheap_pages(order, memflags)) == NULL )
>>      {
>>          BUG_ON(order == 0);
>>          order--;
>> diff -r 3da37c68284f -r 23c31d59ffb1 xen/include/xen/kexec.h
>> --- a/xen/include/xen/kexec.h
>> +++ b/xen/include/xen/kexec.h
>> @@ -25,6 +25,19 @@ void set_kexec_crash_area_size(u64 syste
>>  #define KEXEC_IMAGE_CRASH_BASE   2
>>  #define KEXEC_IMAGE_NR           4
>>  
>> +enum low_crashinfo {
>> +    LOW_CRASHINFO_INVALID = 0,
>> +    LOW_CRASHINFO_NONE = 1,
>> +    LOW_CRASHINFO_MIN = 2,
>> +    LOW_CRASHINFO_ALL = 3
>> +};
>> +
>> +/* Low crashinfo mode.  Start as INVALID so serveral codepaths can set up
>> + * defaults without needing to know the state of the others. */
>> +extern enum low_crashinfo low_crashinfo_mode;
>> +extern paddr_t crashinfo_maxaddr_bits;
>> +void kexec_early_calculations(void);
>> +
>>  int machine_kexec_load(int type, int slot, xen_kexec_image_t *image);
>>  void machine_kexec_unload(int type, int slot, xen_kexec_image_t *image);
>>  void machine_kexec_reserved(xen_kexec_reserve_t *reservation);
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com 
>> http://lists.xensource.com/xen-devel 
>

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 23 11:59:54 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 Dec 2011 11:59:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Re3mS-00052T-7H; Fri, 23 Dec 2011 11:59:20 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1Re3mR-00052L-5Z
	for xen-devel@lists.xensource.com; Fri, 23 Dec 2011 11:59:19 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1324641537!60085441!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjU2NjQ=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10779 invoked from network); 23 Dec 2011 11:58:58 -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;
	23 Dec 2011 11:58:58 -0000
X-IronPort-AV: E=Sophos;i="4.71,398,1320642000"; d="scan'208";a="175276634"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Dec 2011 06:59:16 -0500
Received: from [10.80.2.18] (10.80.2.18) by FTLPMAILMX02.citrite.net
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Fri, 23 Dec 2011
	06:59:15 -0500
Message-ID: <4EF46D12.6040100@citrix.com>
Date: Fri, 23 Dec 2011 11:59:14 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.23) Gecko/20110921 Lightning/1.0b2 Thunderbird/3.1.15
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <patchbomb.1324575382@andrewcoop.uk.xensource.com>
	<23c31d59ffb1590815bc.1324575385@andrewcoop.uk.xensource.com>
	<4EF452940200007800069B89@nat28.tlf.novell.com>
In-Reply-To: <4EF452940200007800069B89@nat28.tlf.novell.com>
X-Enigmail-Version: 1.1.2
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 3 of 3] KEXEC: Allocate crash structures in
 low memory
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 23/12/11 09:06, Jan Beulich wrote:
>>>> On 22.12.11 at 18:36, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>> On 64bit Xen with 32bit dom0 and crashkernel, xmalloc'ing items such
>> as the CPU crash notes will go into the xenheap, which tends to be in
>> upper memory.  This causes problems on machines with more than 64GB
>> (or 4GB if no PAE support) of ram as the crashkernel physically cant
>> access the crash notes.
> What use is a crash dump taken with a 32-bit kernel on a machine
> with more than 64G (or more than 4G is the crash kernel doesn't
> support PAE)?

Very little use at all, which is the reason for this change.  The
correct solution is indeed to use a 64bit dom0 kernel, but while
politics is preventing that from happening, another solution has to be
found.  I doubt that XenServer is the only product which would benifit,
which is why the changes are presented for upstreaming.

>> The solution is to force Xen to allocate certain structures in lower
>> memory.  This is achieved by introducing two new command line
>> parameters; low_crashinfo and crashinfo_maxaddr.  Because of the
>> potential impact on 32bit PV guests, and that this problem does not
>> exist for 64bit dom0 on 64bit Xen, this new functionality defaults to
>> the codebase's previous behavior, requiring the user to explicitly
>> add extra command line parameters to change the behavior.
>>
>> This patch consists of 3 logically distinct but closely related
>> changes.
>>  1) Add the two new command line parameters.
> Do you really need both? Just being able to set the max address
> would seem sufficient...

The plan, as explained in the comments, is for two (or perhaps more)
levels of low allocation.  "min" means "allocate enough stuff low for
the crash kernel to grab the Xen ring buffer" where "all" will include
extra things such as the page tables so the crash kernel can generate
full stack traces given the PT_STATUS notes.  The differentiation is
because "min" should not impact very much at all on other memory
restricted things such as 32bit PV guests, whereas "all" certainly will.

>>  2) Change crash note allocation to use lower memory when instructed.
>>  3) Change the conring buffer to use lower memory when instructed.
> Why does this one need moving, but none of the other Xen data
> structures? If anything, I would have expected you to limit the Xen
> heap altogether, so that automatically all allocations get done in a
> way so that at least Xen's data structures are available in the
> (truncated) dump.

This is part of the "min" option which is trying to have the least
possible impact.  The idea is to have this in low memory, use the
"console_to_ring" boot option to copy dom0 dmesg into conring, and pass
its physical address and size in a crash note, so that the crash kernel
environment grab it all.

>> There result is that the crash notes and console ring will be placed
>> in lower memory so useful information can be recovered in the case of
>> a crash.
>>
>> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
>>
>> diff -r 3da37c68284f -r 23c31d59ffb1 xen/arch/x86/setup.c
>> --- a/xen/arch/x86/setup.c
>> +++ b/xen/arch/x86/setup.c
>> @@ -586,6 +586,10 @@ void __init __start_xen(unsigned long mb
>>      }
>>      cmdline_parse(cmdline);
>>  
>> +    /* Must be after command line argument parsing and before 
>> +     * allocing any xenheap structures wanted in lower memory. */
>> +    kexec_early_calculations();
>> +
> But does it really need to be *this* early?

Possibly not, but it needs to be before console_preirq_init() which is
not much later.

>>      parse_video_info();
>>  
>>      set_current((struct vcpu *)0xfffff000); /* debug sanity */
>> diff -r 3da37c68284f -r 23c31d59ffb1 xen/common/kexec.c
>> --- a/xen/common/kexec.c
>> +++ b/xen/common/kexec.c
>> @@ -36,7 +36,9 @@ bool_t kexecing = FALSE;
>>  typedef struct { Elf_Note * start; size_t size; } crash_note_range_t;
>>  static crash_note_range_t * crash_notes;
>>  
>> -/* Lock to prevent race conditions when allocating the crash note buffers. 
>> */
>> +/* Lock to prevent race conditions when allocating the crash note buffers.
>> + * It also serves to protect calls to alloc_from_crash_heap when allocating
>> + * crash note buffers in lower memory. */
>>  static DEFINE_SPINLOCK(crash_notes_lock);
>>  
>>  static Elf_Note *xen_crash_note;
>> @@ -70,6 +72,23 @@ static struct {
>>      (_d_)->start = (_s_)->start; \
>>  } while (0)
>>  
>> +/* Low crashinfo mode.  Start as INVALID so serveral codepaths can set up
>> + * defaults without needing to know the state of the others. */
>> +enum low_crashinfo low_crashinfo_mode = LOW_CRASHINFO_INVALID;
>> +
>> +/* This value is only considered if low_crash_mode is set to MIN or ALL, so
>> + * setting a default here is safe. Default to 4GB.  This is because the 
>> current
>> + * KEXEC_CMD_get_range compat hypercall trucates 64bit pointers to 32 bits. 
>> The
>> + * typical usecase for crashinfo_maxaddr will be for 64bit Xen with 32bit 
>> dom0 
>> + * and 32bit crash kernel. */
>> +static paddr_t crashinfo_maxaddr = 4ULL << 30;
> __initdata

Good point

>> +
>> +/* = log base 2 of crashinfo_maxaddr after checking for sanity. */
>> +paddr_t crashinfo_maxaddr_bits = 0;
>> +
>> +/* Pointers to keep track of the crash heap region. */
>> +static void *crash_heap_current = NULL, *crash_heap_end = NULL;
>> +
>>  /*
>>   * Parse command lines in the format
>>   *
>> @@ -148,6 +167,58 @@ static void __init parse_crashkernel(con
>>  }
>>  custom_param("crashkernel", parse_crashkernel);
>>  
>> +/* Parse command lines in the format:
>> + *
>> + *   low_crashinfo=[none,min,all]
>> + * 
>> + * - none disables the low allocation of crash info.
>> + * - min will allocate enough low information for the crash kernel to be 
>> able
>> + *       to extract the hypervisor and dom0 message ring buffers.
>> + * - all will allocate additional structures such as domain and vcpu structs
>> + *       low so the crash kernel can perform an extended analysis of state.
>> + */
>> +static void __init parse_low_crashinfo(const char * str)
>> +{
>> +
>> +    if ( !strlen(str) )
>> +        /* default to min if user just specifies "low_crashinfo" */
>> +        low_crashinfo_mode = LOW_CRASHINFO_MIN;
>> +    else if ( !strcmp(str, "none" ) )
>> +        low_crashinfo_mode = LOW_CRASHINFO_NONE;
>> +    else if ( !strcmp(str, "min" ) )
>> +        low_crashinfo_mode = LOW_CRASHINFO_MIN;
>> +    else if ( !strcmp(str, "all" ) )
>> +        low_crashinfo_mode = LOW_CRASHINFO_ALL;
>> +    else
>> +    {
>> +        printk("Unknown low_crashinfo parameter '%s'.  Defaulting to 
>> min.\n", str);
>> +        low_crashinfo_mode = LOW_CRASHINFO_MIN;
>> +    }
>> +}
>> +custom_param("low_crashinfo", parse_low_crashinfo);
>> +
>> +/* Parse command lines in the format:
>> + * 
>> + *   crashinfo_maxaddr=<addr>
>> + *
>> + * <addr> will be rounded down to the nearest power of two.  Defaults to 64G
>> + */
>> +static void __init parse_crashinfo_maxaddr(const char * str)
>> +{
>> +    u64 addr;
>> +
>> +    /* if low_crashinfo_mode is unset, default to min. */
>> +    if ( low_crashinfo_mode == LOW_CRASHINFO_INVALID )
>> +        low_crashinfo_mode = LOW_CRASHINFO_MIN;
>> +
>> +    if ( (addr = parse_size_and_unit(str, NULL)) )
>> +        crashinfo_maxaddr = addr;
>> +    else
>> +        printk("Unable to parse crashinfo_maxaddr. Defaulting to %p\n",
>> +               (void*)crashinfo_maxaddr);
>> +}
>> +custom_param("crashinfo_maxaddr", parse_crashinfo_maxaddr);
>> +
>>  void __init set_kexec_crash_area_size(u64 system_ram)
>>  {
>>      unsigned int idx;
>> @@ -306,6 +377,20 @@ static size_t sizeof_cpu_notes(const uns
>>      return bytes;
>>  }
>>  
>> +/* Allocate size_t bytes of space from the previously allocated
>> + * crash heap if the user has requested that crash notes be allocated
>> + * in lower memory.  There is currently no case where the crash notes
>> + * should be free()'d. */
>> +static void * alloc_from_crash_heap(const size_t bytes)
>> +{
>> +    void * ret;
>> +    if ( crash_heap_current + bytes > crash_heap_end )
>> +        return NULL;
>> +    ret = (void*)crash_heap_current;
>> +    crash_heap_current += bytes;
>> +    return ret;
>> +}
>> +
>>  /* Allocate a crash note buffer for a newly onlined cpu. */
>>  static int kexec_init_cpu_notes(const unsigned long cpu)
>>  {
>> @@ -320,7 +405,10 @@ static int kexec_init_cpu_notes(const un
>>          return ret;
>>  
>>      nr_bytes = sizeof_cpu_notes(cpu);
>> -    note = xmalloc_bytes(nr_bytes);
>> +
>> +    /* If we dont care about the position of allocation, malloc. */
>> +    if ( low_crashinfo_mode == LOW_CRASHINFO_NONE )
>> +        note = xmalloc_bytes(nr_bytes);
>>  
>>      /* Protect the write into crash_notes[] with a spinlock, as this 
>> function
>>       * is on a hotplug path and a hypercall path. */
>> @@ -338,6 +426,11 @@ static int kexec_init_cpu_notes(const un
>>      }
>>      else
>>      {
>> +        /* If we care about memory possition, alloc from the crash heap,
>> +         * also protected by the crash_notes_lock. */
>> +        if ( low_crashinfo_mode > LOW_CRASHINFO_NONE )
>> +            note = alloc_from_crash_heap(nr_bytes);
>> +
>>          crash_notes[cpu].start = note;
>>          crash_notes[cpu].size = nr_bytes;
>>          spin_unlock(&crash_notes_lock);
>> @@ -397,6 +490,24 @@ static struct notifier_block cpu_nfb = {
>>      .notifier_call = cpu_callback
>>  };
>>  
>> +void __init kexec_early_calculations(void)
>> +{
>> +    /* If low_crashinfo_mode is still INVALID, neither "low_crashinfo" nor
>> +     * "crashinfo_maxaddr" have been specified on the command line, so
>> +     * explicitly set to NONE. */
>> +    if ( low_crashinfo_mode == LOW_CRASHINFO_INVALID )
>> +        low_crashinfo_mode = LOW_CRASHINFO_NONE;
>> +
>> +    crashinfo_maxaddr_bits = 0;
>> +    if ( low_crashinfo_mode > LOW_CRASHINFO_NONE )
>> +    {
>> +        paddr_t tmp = crashinfo_maxaddr;
>> +
>> +        while ( tmp >>= 1 )
>> +            crashinfo_maxaddr_bits++;
> fls() or some of its cousins

Ok

>> +    }
>> +}
>> +
>>  static int __init kexec_init(void)
>>  {
>>      void *cpu = (void *)(unsigned long)smp_processor_id();
>> @@ -407,6 +518,29 @@ static int __init kexec_init(void)
>>  
>>      register_keyhandler('C', &crashdump_trigger_keyhandler);
>>  
>> +    if ( low_crashinfo_mode > LOW_CRASHINFO_NONE )
>> +    {
>> +        size_t crash_heap_size;
>> +
>> +        /* This calculation is safe even if the machine is booted in 
>> +         * uniprocessor mode. */
>> +        crash_heap_size = sizeof_cpu_notes(0) +
>> +            sizeof_cpu_notes(1) * (nr_cpu_ids - 1);
>> +        crash_heap_size = PAGE_ALIGN(crash_heap_size);
>> +
>> +        crash_heap_current = alloc_xenheap_pages(
>> +            get_order_from_bytes(crash_heap_size),
>> +            MEMF_bits(crashinfo_maxaddr_bits) );
>> +
>> +        if ( crash_heap_current )
>> +            crash_heap_end = crash_heap_current + crash_heap_size;
>> +        else
>> +            return -ENOMEM;
> Constructs like this generally look bogus to me, as
>
>         if ( !crash_heap_current )
>             return -ENOMEM;
>         ...
>
> is shorter and (to me at least) more clear.

True - for a long time I was debating whether to return ENOMEM at this
point at not, so I clearly didn't consider clarity when deciding to add
it in.  I will fix this.

>> +    }
>> +
>> +    /* crash_notes may be allocated anywhere Xen can reach in memory.
>> +       Only the individual CPU crash notes themselves must be allocated
>> +       in lower memory if requested. */
>>      crash_notes = xmalloc_array(crash_note_range_t, nr_cpu_ids);
>>      if ( ! crash_notes )
>>          return -ENOMEM;
>> diff -r 3da37c68284f -r 23c31d59ffb1 xen/drivers/char/console.c
>> --- a/xen/drivers/char/console.c
>> +++ b/xen/drivers/char/console.c
>> @@ -584,6 +584,7 @@ void __init console_init_postirq(void)
>>  {
>>      char *ring;
>>      unsigned int i, order;
>> +    u64 memflags;
>>  
>>      serial_init_postirq();
>>  
>> @@ -591,7 +592,8 @@ void __init console_init_postirq(void)
>>          opt_conring_size = num_present_cpus() << (9 + xenlog_lower_thresh);
>>  
>>      order = get_order_from_bytes(max(opt_conring_size, conring_size));
>> -    while ( (ring = alloc_xenheap_pages(order, 0)) == NULL )
>> +    memflags = low_crashinfo_mode > LOW_CRASHINFO_NONE ? 
>> MEMF_bits(crashinfo_maxaddr_bits) : 0;
>> +    while ( (ring = alloc_xenheap_pages(order, memflags)) == NULL )
>>      {
>>          BUG_ON(order == 0);
>>          order--;
>> diff -r 3da37c68284f -r 23c31d59ffb1 xen/include/xen/kexec.h
>> --- a/xen/include/xen/kexec.h
>> +++ b/xen/include/xen/kexec.h
>> @@ -25,6 +25,19 @@ void set_kexec_crash_area_size(u64 syste
>>  #define KEXEC_IMAGE_CRASH_BASE   2
>>  #define KEXEC_IMAGE_NR           4
>>  
>> +enum low_crashinfo {
>> +    LOW_CRASHINFO_INVALID = 0,
>> +    LOW_CRASHINFO_NONE = 1,
>> +    LOW_CRASHINFO_MIN = 2,
>> +    LOW_CRASHINFO_ALL = 3
>> +};
>> +
>> +/* Low crashinfo mode.  Start as INVALID so serveral codepaths can set up
>> + * defaults without needing to know the state of the others. */
>> +extern enum low_crashinfo low_crashinfo_mode;
>> +extern paddr_t crashinfo_maxaddr_bits;
>> +void kexec_early_calculations(void);
>> +
>>  int machine_kexec_load(int type, int slot, xen_kexec_image_t *image);
>>  void machine_kexec_unload(int type, int slot, xen_kexec_image_t *image);
>>  void machine_kexec_reserved(xen_kexec_reserve_t *reservation);
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com 
>> http://lists.xensource.com/xen-devel 
>

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 23 12:43:27 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 Dec 2011 12:43:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Re4S6-0005i4-JG; Fri, 23 Dec 2011 12:42:22 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1Re4S4-0005hz-VM
	for xen-devel@lists.xensource.com; Fri, 23 Dec 2011 12:42:21 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-7.tower-27.messagelabs.com!1324644079!61906011!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=1.9 required=7.0 tests=BODY_RANDOM_LONG,INFO_TLD
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28598 invoked from network); 23 Dec 2011 12:41:21 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-7.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 23 Dec 2011 12:41:21 -0000
Received: from andromeda.dapyr.net (darnok@localhost [127.0.0.1])
	by andromeda.dapyr.net (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id
	pBNCg8qM028472
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Fri, 23 Dec 2011 07:42:08 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pBNCg8BH028470;
	Fri, 23 Dec 2011 07:42:08 -0500
Date: Fri, 23 Dec 2011 08:42:08 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: "Liu, Jinsong" <jinsong.liu@intel.com>
Message-ID: <20111223124208.GA25286@andromeda.dapyr.net>
References: <DE8DF0795D48FD4CA783C40EC82923359699@SHSMSX101.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <DE8DF0795D48FD4CA783C40EC82923359699@SHSMSX101.ccr.corp.intel.com>
User-Agent: Mutt/1.5.9i
Cc: "Brown, Len" <len.brown@intel.com>,
	"jeremy.fitzhardinge@citrix.com" <jeremy.fitzhardinge@citrix.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>, "Jiang,
	Yunhong" <yunhong.jiang@intel.com>, "Shan, Haitao" <haitao.shan@intel.com>,
	Kernel development list <linux-kernel@vger.kernel.org>, "Zhao,
	Yakui" <yakui.zhao@intel.com>, "Luck, Tony" <tony.luck@intel.com>, "Kleen,
	Andi" <andi.kleen@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 01/10] Add mcelog support from xen platform
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Dec 23, 2011 at 10:23:03AM +0000, Liu, Jinsong wrote:
> >From 0e8de1ce0f13aa34aa6013e6a387ae5be78031ca Mon Sep 17 00:00:00 2001
> From: Liu Jinsong <jinsong.liu@intel.com>
> Date: Tue, 6 Dec 2011 18:08:12 +0800
> Subject: [PATCH 01/10] Add mcelog support from xen platform

.. for xen platform.
> 
> This patch backport from Jeremy's pvops commit a5ed1f3dae179158e385e9371462dd65d5e125c5,
> which in turn backport from previous xen DOM0(2.6.18) cs: 75e5bfa7fbdc

Ok. You should also include a link to the tree.

Is this patch by itself usuable? Meaning it can work without being
dependent on the ACPI patches?
> 
> When a MCE/CMCI error happens (or by polling), the related error

What does CMCI stand for? Can you include the full description of
what those are (both MCE and CMCI)?
> information will be sent to privileged pv-ops domain by XEN. This

No need to say 'pv-ops'. This patchset is _for_ the pv-ops kernel
and it is _only_ a pv-ops type kernel.

> patch will help to fetch the xen-logged information by hypercall

s/xen-logged/logged
> and then convert XEN-format log into Linux format MCELOG. It makes
> using current available mcelog tools for native Linux possible.

Excellent. Can you include in this section how to test it.
A step by step instruction? Or perhaps just point to documentation
if such exist?

> 
> With this patch, after mce/cmci error log information is sent to
> pv-ops guest, Running mcelog tools in the guest, you will get same

Priviliged guests or not-priviliged?
> detailed decoded mce information as in Native Linux.
> 
> Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
> Signed-off-by: Ke, Liping <liping.ke@intel.com>
> Signed-off-by: Jiang, Yunhong <yunhong.jiang@intel.com>
> Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
> ---
>  arch/x86/include/asm/xen/hypercall.h |    8 +
>  arch/x86/xen/enlighten.c             |    8 +-
>  drivers/xen/Kconfig                  |    8 +
>  drivers/xen/Makefile                 |    1 +
>  drivers/xen/mcelog.c                 |  217 +++++++++++++++++
>  include/xen/interface/xen-mca.h      |  429 ++++++++++++++++++++++++++++++++++

Make sure you run this patch through scripts/cleanpatch.pl.

I ran it through that and found 8 issues, please fix those.

>  6 files changed, 667 insertions(+), 4 deletions(-)
>  create mode 100644 drivers/xen/mcelog.c
>  create mode 100644 include/xen/interface/xen-mca.h
> 
> diff --git a/arch/x86/include/asm/xen/hypercall.h b/arch/x86/include/asm/xen/hypercall.h
> index 5728852..59c226d 100644
> --- a/arch/x86/include/asm/xen/hypercall.h
> +++ b/arch/x86/include/asm/xen/hypercall.h
> @@ -48,6 +48,7 @@
>  #include <xen/interface/sched.h>
>  #include <xen/interface/physdev.h>
>  #include <xen/interface/platform.h>
> +#include <xen/interface/xen-mca.h>
>  
>  /*
>   * The hypercall asms have to meet several constraints:
> @@ -302,6 +303,13 @@ HYPERVISOR_set_timer_op(u64 timeout)
>  }
>  
>  static inline int
> +HYPERVISOR_mca(struct xen_mc *mc_op)
> +{
> +	mc_op->interface_version = XEN_MCA_INTERFACE_VERSION;
> +	return _hypercall1(int, mca, mc_op);
> +}
> +
> +static inline int
>  HYPERVISOR_dom0_op(struct xen_platform_op *platform_op)
>  {
>  	platform_op->interface_version = XENPF_INTERFACE_VERSION;
> diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
> index 9306320..b073e4c 100644
> --- a/arch/x86/xen/enlighten.c
> +++ b/arch/x86/xen/enlighten.c
> @@ -242,14 +242,14 @@ static void __init xen_init_cpuid_mask(void)
>  	unsigned int xsave_mask;
>  
>  	cpuid_leaf1_edx_mask =
> -		~((1 << X86_FEATURE_MCE)  |  /* disable MCE */
> -		  (1 << X86_FEATURE_MCA)  |  /* disable MCA */
> -		  (1 << X86_FEATURE_MTRR) |  /* disable MTRR */
> +		~((1 << X86_FEATURE_MTRR) |  /* disable MTRR */
>  		  (1 << X86_FEATURE_ACC));   /* thermal monitoring */
>  
>  	if (!xen_initial_domain())
>  		cpuid_leaf1_edx_mask &=
> -			~((1 << X86_FEATURE_APIC) |  /* disable local APIC */
> +			~((1 << X86_FEATURE_MCE)  |  /* disable MCE */
> +			  (1 << X86_FEATURE_MCA)  |  /* disable MCA */
> +			  (1 << X86_FEATURE_APIC) |  /* disable local APIC */
>  			  (1 << X86_FEATURE_ACPI));  /* disable ACPI */
>  	ax = 1;
>  	xen_cpuid(&ax, &bx, &cx, &dx);
> diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
> index e8fb85f..eb2a327 100644
> --- a/drivers/xen/Kconfig
> +++ b/drivers/xen/Kconfig
> @@ -117,6 +117,14 @@ config XEN_SYS_HYPERVISOR
>  	 virtual environment, /sys/hypervisor will still be present,
>  	 but will have no xen contents.
>  
> +config XEN_MCE_LOG
> +	bool "Xen platform mcelog"
> +	depends on XEN_DOM0 && X86_64 && X86_MCE
> +	default y

That should 'n'.
> +	help
> +	  Allow kernel fetching mce log from xen platform and
> +	  converting it into linux mcelog format for mcelog tools
> +
>  config ACPI_PROCESSOR_XEN
>  	tristate
>  	depends on XEN_DOM0 && ACPI_PROCESSOR && CPU_FREQ
> diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
> index d42da53..405cce9 100644
> --- a/drivers/xen/Makefile
> +++ b/drivers/xen/Makefile
> @@ -14,6 +14,7 @@ obj-$(CONFIG_XEN_GNTDEV)		+= xen-gntdev.o
>  obj-$(CONFIG_XEN_GRANT_DEV_ALLOC)	+= xen-gntalloc.o
>  obj-$(CONFIG_XENFS)			+= xenfs/
>  obj-$(CONFIG_XEN_SYS_HYPERVISOR)	+= sys-hypervisor.o
> +obj-$(CONFIG_XEN_MCE_LOG)		+= mcelog.o
>  obj-$(CONFIG_XEN_PLATFORM_PCI)		+= xen-platform-pci.o
>  obj-$(CONFIG_XEN_TMEM)			+= tmem.o
>  obj-$(CONFIG_SWIOTLB_XEN)		+= swiotlb-xen.o
> diff --git a/drivers/xen/mcelog.c b/drivers/xen/mcelog.c
> new file mode 100644
> index 0000000..892ca7b
> --- /dev/null
> +++ b/drivers/xen/mcelog.c
> @@ -0,0 +1,217 @@
> +/******************************************************************************
> + * mcelog.c
> + * Add Machine Check event Logging support in DOM0
> + *
> + * Driver for receiving and logging machine check event

Uh, logging? I thought the logging would be handed of the generic MCElog
interface?

> + *
> + * Copyright (c) 2008, 2009 Intel Corporation
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License version 2
> + * as published by the Free Software Foundation; or, when distributed
> + * separately from the Linux kernel or incorporated into other
> + * software packages, subject to the following license:
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a copy
> + * of this source file (the "Software"), to deal in the Software without
> + * restriction, including without limitation the rights to use, copy, modify,
> + * merge, publish, distribute, sublicense, and/or sell copies of the Software,
> + * and to permit persons to whom the Software is furnished to do so, subject to
> + * the following conditions:
> + *
> + * The above copyright notice and this permission notice shall be included in
> + * all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
> + * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
> + * IN THE SOFTWARE.
> + */
> +
> +#include <linux/module.h>
> +#include <linux/init.h>
> +#include <linux/types.h>
> +#include <linux/kernel.h>
> +#include <linux/slab.h>
> +#include <xen/interface/xen.h>
> +#include <asm/xen/hypervisor.h>
> +#include <xen/events.h>
> +#include <xen/interface/vcpu.h>
> +#include <asm/xen/hypercall.h>
> +#include <asm/mce.h>
> +#include <xen/xen.h>
> +
> +static mc_info_t *g_mi;

Include a comment saying why you don't need locking for the 'g_mi'
structure.
> +static mcinfo_logical_cpu_t *g_physinfo;

.. and for this one too.

> +static uint32_t ncpus;
> +
> +static int convert_log(struct mc_info *mi)
> +{
> +	struct mcinfo_common *mic = NULL;
> +	struct mcinfo_global *mc_global;
> +	struct mcinfo_bank *mc_bank;
> +	struct mce m;
> +	int i, found = 0;

Make 'found' a bool please.
> +
> +	x86_mcinfo_lookup(&mic, mi, MC_TYPE_GLOBAL);
> +	WARN_ON(!mic);

Should there be some extra information? Say:

WARN_ON(!mic,"Was not able to find global MCE!")

Should you quit this routine if this happens?
> +
> +	mce_setup(&m);
> +	mc_global = (struct mcinfo_global *)mic;
> +	m.mcgstatus = mc_global->mc_gstatus;

So if mic=NULL, this would do mic->mc_gstatus which would trigger a NULL
pointer problem. Please rework this.
> +	m.apicid = mc_global->mc_apicid;

And this one too.

> +	for (i = 0; i < ncpus; i++) {
> +		if (g_physinfo[i].mc_apicid == m.apicid) {
> +			found = 1;
> +			break;
> +		}
> +	}
> +	WARN_ON(!found);

So... if we went through _all_ of the g_physinfo and
did not find the m.apicid, we would print a WARN_ON
and then here:
> +
> +	m.socketid = g_physinfo[i].mc_chipid;

we would use the last g_physinfo record. Shouldn't we just
abondon this instead and return from this function?

> +	m.cpu = m.extcpu = g_physinfo[i].mc_cpunr;
> +	m.cpuvendor = (__u8)g_physinfo[i].mc_vendor;

Why the casting?
> +	m.mcgcap = g_physinfo[i].mc_msrvalues[0].value;

Is it always going to 0? Should there be a define for the
entries in the array?

You ought to do this first:
	mic = NULL;

before calling this function. I know that the function does set
the *mic = NULL on entry but that is not obvious from this level
of the function. So either say it (one line comment) or just
do that 'mic = NULL'
> +	x86_mcinfo_lookup(&mic, mi, MC_TYPE_BANK);
> +	do {
> +		if (mic == NULL || mic->size == 0)
> +			break;
> +		if (mic->type == MC_TYPE_BANK) {
> +			mc_bank = (struct mcinfo_bank *)mic;
> +			m.misc = mc_bank->mc_misc;
> +			m.status = mc_bank->mc_status;
> +			m.addr = mc_bank->mc_addr;
> +			m.tsc = mc_bank->mc_tsc;
> +			m.bank = mc_bank->mc_bank;
> +			m.finished = 1;
> +			/*log this record*/
> +			mce_log(&m);
> +		}
> +		mic = x86_mcinfo_next(mic);
> +	} while (1);
> +
> +	return 0;
> +}
> +
> +/*pv_ops domain mce virq handler, logging physical mce error info*/

Get rid of the 'pv_ops' domain please.

Can you expand this a bit. Say when this interrupt happens, how often
it can happen, and whether it can only be sent to priviliged domains.

> +static irqreturn_t mce_dom_interrupt(int irq, void *dev_id)
> +{
> +	xen_mc_t mc_op;
> +	int result = 0;

int err = 0;

> +
> +	mc_op.cmd = XEN_MC_fetch;
> +	mc_op.interface_version = XEN_MCA_INTERFACE_VERSION;
> +	set_xen_guest_handle(mc_op.u.mc_fetch.data, g_mi);
> +urgent:
> +	mc_op.u.mc_fetch.flags = XEN_MC_URGENT;
> +	result = HYPERVISOR_mca(&mc_op);
> +	if (result || mc_op.u.mc_fetch.flags & XEN_MC_NODATA ||
> +			mc_op.u.mc_fetch.flags & XEN_MC_FETCHFAILED)

Please fix the spacing. They should be aligned.
> +		goto nonurgent;
> +	else {
> +		result = convert_log(g_mi);
> +		if (result)
> +			goto end;
> +		/* After fetching the error event log entry from DOM0,
> +		 * we need to dec the refcnt and release the entry.
> +		 * The entry is reserved and inc refcnt when filling
> +		 * the error log entry.

Uh? Which refcnt? Where is the refcnt? Can you explain this in more
details please?
> +		 */
> +		mc_op.u.mc_fetch.flags = XEN_MC_URGENT | XEN_MC_ACK;
> +		result = HYPERVISOR_mca(&mc_op);
> +		goto urgent;

Eww, this is a while loop using goto statements.

Can you restructure this to be a while loop please?

> +	}
> +nonurgent:
> +	mc_op.u.mc_fetch.flags = XEN_MC_NONURGENT;
> +	result = HYPERVISOR_mca(&mc_op);
> +	if (result || mc_op.u.mc_fetch.flags & XEN_MC_NODATA ||
> +			mc_op.u.mc_fetch.flags & XEN_MC_FETCHFAILED)
> +		goto end;
> +	else {
> +		result = convert_log(g_mi);
> +		if (result)
> +			goto end;
> +		/* After fetching the error event log entry from DOM0,
> +		 * we need to dec the refcnt and release the entry. The
> +		 * entry is reserved and inc refcnt when filling the
> +		 * error log entry.
> +		 */
> +		mc_op.u.mc_fetch.flags = XEN_MC_NONURGENT | XEN_MC_ACK;
> +		result = HYPERVISOR_mca(&mc_op);
> +		goto nonurgent;

This is the same as the previous code. Can you squash these together?
You could use a state flag to figure out if you are doing the urgent
vs the non-urgent part now.

Or you can move this 'while loop' in its own function and just call
it with the different flags.

> +	}
> +end:
> +	return IRQ_HANDLED;
> +}
> +
> +static int bind_virq_for_mce(void)
> +{
> +	int ret;
> +	xen_mc_t mc_op;
> +
> +	g_mi = kmalloc(sizeof(struct mc_info), GFP_KERNEL);

Most of the time 'kzalloc' is used just in case you do not end
up filling all of the fields of the mc_op. And this is especially true
if you run with CONFIG_DEBUG_PAGEALLOC which will them with garbage
and you can get interesting results when you have forgotton to set them
all.

So if you are sure that _all_ the fields of the 'mc_op' have been filled
then you don't need kmalloc. But otherwise please use 'kzalloc'.
> +
> +	if (!g_mi)
> +		return -ENOMEM;
> +
> +	/* Fetch physical CPU Numbers */
> +	mc_op.cmd = XEN_MC_physcpuinfo;
> +	mc_op.interface_version = XEN_MCA_INTERFACE_VERSION;
> +	set_xen_guest_handle(mc_op.u.mc_physcpuinfo.info, g_physinfo);
> +	ret = HYPERVISOR_mca(&mc_op);
> +	if (ret) {
> +		printk(KERN_ERR "MCE_DOM0_LOG: Fail to get physical CPU numbers\n");

..s/fail/failed.

Is the DOM0 part neccessary? The user knows he/she is running under xen
and what difference does it make it if its domU or dom0?

> +		kfree(g_mi);
> +		return ret;
> +	}
> +
> +	/* Fetch each CPU Physical Info for later reference*/
> +	ncpus = mc_op.u.mc_physcpuinfo.ncpus;
> +	g_physinfo = kmalloc(sizeof(struct mcinfo_logical_cpu)*ncpus,
> +					GFP_KERNEL);

Align the spacing please. And also put a space for the '*'
> +	if (!g_physinfo) {
> +		kfree(g_mi);
> +		return -ENOMEM;
> +	}
> +	set_xen_guest_handle(mc_op.u.mc_physcpuinfo.info, g_physinfo);
> +	ret = HYPERVISOR_mca(&mc_op);
> +	if (ret) {
> +		printk(KERN_ERR "MCE_DOM0_LOG: Fail to get physical CPUs info\n");

Some comment about the dom0, fail for this.
> +		kfree(g_mi);
> +		kfree(g_physinfo);
> +		return ret;
> +	}
> +
> +	ret  = bind_virq_to_irqhandler(VIRQ_MCA, 0,
> +		mce_dom_interrupt, 0, "mce", NULL);
Please tab/space align this properly.
> +
> +	if (ret < 0) {
> +		printk(KERN_ERR "MCE_DOM0_LOG: bind_virq for DOM0 failed\n");
> +		return ret;
> +	}
> +
> +	return 0;
> +}
> +
> +static int __init mcelog_init(void)
> +{
> +	/* Only DOM0 is responsible for MCE logging */
> +	if (xen_initial_domain())
> +		return bind_virq_for_mce();
> +
> +	return 0;

return -ENODEV;

for the non-initial-domain case. Otherwise you end up loading this
module for nothing.
> +}
> +
> +
> +static void __exit mcelog_cleanup(void)
> +{
> +	kfree(g_mi);
> +	kfree(g_physinfo);
> +}
> +module_init(mcelog_init);
> +module_exit(mcelog_cleanup);
> +
> +MODULE_LICENSE("GPL");
> diff --git a/include/xen/interface/xen-mca.h b/include/xen/interface/xen-mca.h
> new file mode 100644
> index 0000000..f31fdab
> --- /dev/null
> +++ b/include/xen/interface/xen-mca.h
> @@ -0,0 +1,429 @@
> +/******************************************************************************
> + * arch-x86/mca.h
> + *
> + * Contributed by Advanced Micro Devices, Inc.
> + * Author: Christoph Egger <Christoph.Egger@amd.com>
> + *
> + * Guest OS machine check interface to x86 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.
> + */
> +
> +/* Full MCA functionality has the following Usecases from the guest side:
> + *
> + * Must have's:
> + * 1. Dom0 and DomU register machine check trap callback handlers
> + *    (already done via "set_trap_table" hypercall)
> + * 2. Dom0 registers machine check event callback handler
> + *    (doable via EVTCHNOP_bind_virq)
> + * 3. Dom0 and DomU fetches machine check data

So the domU case is not covered here. is there another patch for that?
> + * 4. Dom0 wants Xen to notify a DomU
> + * 5. Dom0 gets DomU ID from physical address
> + * 6. Dom0 wants Xen to kill DomU (already done for "xm destroy")
> + *
> + * Nice to have's:
> + * 7. Dom0 wants Xen to deactivate a physical CPU
> + *    This is better done as separate task, physical CPU hotplugging,
> + *    and hypercall(s) should be sysctl's
> + * 8. Page migration proposed from Xen NUMA work, where Dom0 can tell Xen to
> + *    move a DomU (or Dom0 itself) away from a malicious page
> + *    producing correctable errors.
> + * 9. offlining physical page:
> + *    Xen free's and never re-uses a certain physical page.
> + * 10. Testfacility: Allow Dom0 to write values into machine check MSR's
> + *     and tell Xen to trigger a machine check
> + */
> +
> +#ifndef __XEN_PUBLIC_ARCH_X86_MCA_H__
> +#define __XEN_PUBLIC_ARCH_X86_MCA_H__
> +
> +/* Hypercall */
> +#define __HYPERVISOR_mca __HYPERVISOR_arch_0
> +
> +/*
> + * The xen-unstable repo has interface version 0x03000001; out interface
> + * is incompatible with that and any future minor revisions, so we
> + * choose a different version number range that is numerically less
> + * than that used in xen-unstable.

I don't understand that. Does it mean you can't use this with
xen-unstable? Or that it can't be used with 4.1? Can this be fixed
in the xen-unstable tree? Which xen-unstable tree? At what point was
this neccessary ? (include a c/s to denote _when_ so one has an idea if
this is truly true anymore).
> + */
> +#define XEN_MCA_INTERFACE_VERSION 0x01ecc003
> +
> +/* IN: Dom0 calls hypercall to retrieve nonurgent error log entry */
> +#define XEN_MC_NONURGENT  0x0001
> +/* IN: Dom0/DomU calls hypercall to retrieve urgent error log entry */
> +#define XEN_MC_URGENT     0x0002
> +/* IN: Dom0 acknowledges previosly-fetched error log entry */
> +#define XEN_MC_ACK        0x0004
> +
> +/* OUT: All is ok */
> +#define XEN_MC_OK           0x0
> +/* OUT: Domain could not fetch data. */
> +#define XEN_MC_FETCHFAILED  0x1
> +/* OUT: There was no machine check data to fetch. */
> +#define XEN_MC_NODATA       0x2
> +/* OUT: Between notification time and this hypercall an other
> + *  (most likely) correctable error happened. The fetched data,
> + *  does not match the original machine check data. */
> +#define XEN_MC_NOMATCH      0x4
> +
> +/* OUT: DomU did not register MC NMI handler. Try something else. */
> +#define XEN_MC_CANNOTHANDLE 0x8
> +/* OUT: Notifying DomU failed. Retry later or try something else. */
> +#define XEN_MC_NOTDELIVERED 0x10
> +/* Note, XEN_MC_CANNOTHANDLE and XEN_MC_NOTDELIVERED are mutually exclusive. */
> +
> +
> +#ifndef __ASSEMBLY__
> +
> +#define VIRQ_MCA VIRQ_ARCH_0 /* G. (DOM0) Machine Check Architecture */

What is the 'G.' for?
> +
> +/*
> + * Machine Check Architecure:
> + * structs are read-only and used to report all kinds of
> + * correctable and uncorrectable errors detected by the HW.
> + * Dom0 and DomU: register a handler to get notified.

Uhh. But your code does not do that? It only does it for the dom0 case?
Is this comment still valid?
> + * Dom0 only: Correctable errors are reported via VIRQ_MCA
> + */
> +#define MC_TYPE_GLOBAL          0

Can you describe what this means?
> +#define MC_TYPE_BANK            1

And this?
> +#define MC_TYPE_EXTENDED        2
And this?
> +#define MC_TYPE_RECOVERY        3

So are these Xen ABI specific or do they overlap with the Linux
idea of MC type checks? Please include that information in the
comment section.

> +
> +struct mcinfo_common {
> +	uint16_t type;      /* structure type */
> +	uint16_t size;      /* size of this struct in bytes */
> +};
> +
> +
> +#define MC_FLAG_CORRECTABLE     (1 << 0)
> +#define MC_FLAG_UNCORRECTABLE   (1 << 1)
> +#define MC_FLAG_RECOVERABLE	(1 << 2)
> +#define MC_FLAG_POLLED		(1 << 3)
> +#define MC_FLAG_RESET		(1 << 4)
> +#define MC_FLAG_CMCI		(1 << 5)
> +#define MC_FLAG_MCE		(1 << 6)

UGh, that looks out of alignemnt. Not sure if this my mailer or what but
please double check.
> +/* contains global x86 mc information */
> +struct mcinfo_global {
> +	struct mcinfo_common common;
> +
> +	/* running domain at the time in error (most likely
> +	 * the impacted one) */
> +	uint16_t mc_domid;
> +	uint16_t mc_vcpuid; /* virtual cpu scheduled for mc_domid */
> +	uint32_t mc_socketid; /* physical socket of the physical core */
> +	uint16_t mc_coreid; /* physical impacted core */
> +	uint16_t mc_core_threadid; /* core thread of physical core */
> +	uint32_t mc_apicid;
> +	uint32_t mc_flags;
> +	uint64_t mc_gstatus; /* global status */
> +};
> +
> +/* contains bank local x86 mc information */
> +struct mcinfo_bank {
> +	struct mcinfo_common common;
> +
> +	uint16_t mc_bank; /* bank nr */
> +	uint16_t mc_domid; /* Usecase 5: domain referenced by mc_addr on
> +			* privileged pv-ops dom and if mc_addr is valid.
> +			* Never valid on DomU. */
> +	uint64_t mc_status; /* bank status */
> +	uint64_t mc_addr;   /* bank address, only valid
> +					 * if addr bit is set in mc_status */

Please fix the spacing.
> +	uint64_t mc_misc;
> +	uint64_t mc_ctrl2;
> +	uint64_t mc_tsc;
> +};
> +
> +
> +struct mcinfo_msr {
> +	uint64_t reg;   /* MSR */
> +	uint64_t value; /* MSR value */
> +};
> +
> +/* contains mc information from other
> + * or additional mc MSRs */
> +struct mcinfo_extended {
> +	struct mcinfo_common common;
> +
> +	/* You can fill up to five registers.
> +	 * If you need more, then use this structure
> +	 * multiple times. */
> +
> +	uint32_t mc_msrs; /* Number of msr with valid values. */
> +	/*
> +	 * Currently Intel extended MSR (32/64) include all gp registers
> +	 * and E(R)FLAGS, E(R)IP, E(R)MISC, up to 11/19 of them might be
> +	 * useful at present. So expand this array to 16/32 to leave room.
> +	 */
> +	struct mcinfo_msr mc_msr[sizeof(void *) * 4];
> +};
> +
> +/* Recovery Action flags. Giving recovery result information to DOM0 */
> +
> +/* Xen takes successful recovery action, the error is recovered */
> +#define REC_ACTION_RECOVERED (0x1 << 0)
> +/* No action is performed by XEN */
> +#define REC_ACTION_NONE (0x1 << 1)
> +/* It's possible DOM0 might take action ownership in some case */
> +#define REC_ACTION_NEED_RESET (0x1 << 2)
> +
> +/* Different Recovery Action types, if the action is performed successfully,
> + * REC_ACTION_RECOVERED flag will be returned.
> + */
> +
> +/* Page Offline Action */
> +#define MC_ACTION_PAGE_OFFLINE (0x1 << 0)
> +/* CPU offline Action */
> +#define MC_ACTION_CPU_OFFLINE (0x1 << 1)
> +/* L3 cache disable Action */
> +#define MC_ACTION_CACHE_SHRINK (0x1 << 2)
> +
> +/* Below interface used between XEN/DOM0 for passing XEN's recovery action
> + * information to DOM0.
> + * usage Senario: After offlining broken page, XEN might pass its page offline
> + * recovery action result to DOM0. DOM0 will save the information in
> + * non-volatile memory for further proactive actions, such as offlining the
> + * easy broken page earlier when doing next reboot.

Can you rewrite the last paragraph please. It is not clear what you
mean.
> +*/
> +struct page_offline_action {
> +	/* Params for passing the offlined page number to DOM0 */
> +	uint64_t mfn;
> +	uint64_t status;
> +};
> +
> +struct cpu_offline_action {
> +	/* Params for passing the identity of the offlined CPU to DOM0 */
> +	uint32_t mc_socketid;
> +	uint16_t mc_coreid;
> +	uint16_t mc_core_threadid;
> +};
> +
> +#define MAX_UNION_SIZE 16
> +struct mcinfo_recovery {
> +	struct mcinfo_common common;
> +	uint16_t mc_bank; /* bank nr */
> +	/* Recovery Action Flags defined above such as REC_ACTION_DONE */
> +	uint8_t action_flags;
> +	/* Recovery Action types defined above such as MC_ACTION_PAGE_OFFLINE */
> +	uint8_t action_types;
> +	/* In future if more than one recovery action permitted per error bank,
> +	 * a mcinfo_recovery data array will be returned
> +	 */
> +	union {
> +		struct page_offline_action page_retire;
> +		struct cpu_offline_action cpu_offline;
> +		uint8_t pad[MAX_UNION_SIZE];
> +	} action_info;
> +};
> +
> +
> +#define MCINFO_HYPERCALLSIZE	1024
> +#define MCINFO_MAXSIZE		768
> +
> +struct mc_info {
> +	/* Number of mcinfo_* entries in mi_data */
> +	uint32_t mi_nentries;
> +	uint32_t _pad0;
> +	uint64_t mi_data[(MCINFO_MAXSIZE - 1) / 8];
> +};
> +typedef struct mc_info mc_info_t;
> +DEFINE_GUEST_HANDLE_STRUCT(mc_info);
> +
> +#define __MC_MSR_ARRAYSIZE 8
> +#define __MC_NMSRS 1
> +#define MC_NCAPS	7	/* 7 CPU feature flag words */
> +#define MC_CAPS_STD_EDX	0	/* cpuid level 0x00000001 (%edx) */
> +#define MC_CAPS_AMD_EDX	1	/* cpuid level 0x80000001 (%edx) */
> +#define MC_CAPS_TM	2	/* cpuid level 0x80860001 (TransMeta) */
> +#define MC_CAPS_LINUX	3	/* Linux-defined */
> +#define MC_CAPS_STD_ECX	4	/* cpuid level 0x00000001 (%ecx) */
> +#define MC_CAPS_VIA	5	/* cpuid level 0xc0000001 */
> +#define MC_CAPS_AMD_ECX	6	/* cpuid level 0x80000001 (%ecx) */
> +
> +struct mcinfo_logical_cpu {
> +	uint32_t mc_cpunr;
> +	uint32_t mc_chipid;
> +	uint16_t mc_coreid;
> +	uint16_t mc_threadid;
> +	uint32_t mc_apicid;
> +	uint32_t mc_clusterid;
> +	uint32_t mc_ncores;
> +	uint32_t mc_ncores_active;
> +	uint32_t mc_nthreads;
> +	int32_t mc_cpuid_level;

This looks odd? Can you explain why it is int32 instead of uint32?

> +	uint32_t mc_family;
> +	uint32_t mc_vendor;
> +	uint32_t mc_model;
> +	uint32_t mc_step;
> +	char mc_vendorid[16];
> +	char mc_brandid[64];
> +	uint32_t mc_cpu_caps[MC_NCAPS];
> +	uint32_t mc_cache_size;
> +	uint32_t mc_cache_alignment;
> +	int32_t mc_nmsrvals;

Ditto.
> +	struct mcinfo_msr mc_msrvalues[__MC_MSR_ARRAYSIZE];
> +};
> +typedef struct mcinfo_logical_cpu mcinfo_logical_cpu_t;

No typedefs.
> +DEFINE_GUEST_HANDLE_STRUCT(mcinfo_logical_cpu);
> +
> +
> +/*
> + * OS's should use these instead of writing their own lookup function
> + * each with its own bugs and drawbacks.

What are the drawbacks?
> + * We use macros instead of static inline functions to allow guests
> + * to include this header in assembly files (*.S).
> + */
> +/* Prototype:
> + *    uint32_t x86_mcinfo_nentries(struct mc_info *mi);
> + */
> +#define x86_mcinfo_nentries(_mi)    \
> +    ((_mi)->mi_nentries)
> +/* Prototype:
> + *    struct mcinfo_common *x86_mcinfo_first(struct mc_info *mi);
> + */
> +#define x86_mcinfo_first(_mi)       \
> +    ((struct mcinfo_common *)(_mi)->mi_data)
> +/* Prototype:
> + *    struct mcinfo_common *x86_mcinfo_next(struct mcinfo_common *mic);
> + */
> +#define x86_mcinfo_next(_mic)       \
> +    ((struct mcinfo_common *)((uint8_t *)(_mic) + (_mic)->size))
> +
> +/* Prototype:
> + *    void x86_mcinfo_lookup(void *ret, struct mc_info *mi, uint16_t type);
> + */
> +
> +static inline void x86_mcinfo_lookup
> +	(struct mcinfo_common **ret, struct mc_info *mi, uint16_t type)

Fix the argument list. It should be something like this:
static inline void x86_mcinfo_lookup(struct mcinfo_common *ret,
				     struct mc_info *mi, ...

> +{
> +	uint32_t found = 0, i;

Make found be a 'bool' please.

> +	struct mcinfo_common *mic;
> +
> +	*ret = NULL;

Check if ret is NULL first. Like:

	if (!ret)
		return

> +	if (!mi)
> +		return;

or you can merge them both together:
	if (!mi || !ret)
		return;
> +	mic = x86_mcinfo_first(mi);
> +
> +	for (i = 0; i < x86_mcinfo_nentries(mi); i++) {
> +		if (mic->type == type) {
> +			found = 1;
> +			break;
> +		}
> +		mic = x86_mcinfo_next(mic);
> +	}
> +
> +	*ret = found ? mic : NULL;
> +}
> +/* Usecase 1
> + * Register machine check trap callback handler
> + *    (already done via "set_trap_table" hypercall)
> + */
> +
> +/* Usecase 2
> + * Dom0 registers machine check event callback handler
> + * done by EVTCHNOP_bind_virq
> + */
> +
> +/* Usecase 3
> + * Fetch machine check data from hypervisor.
> + * Note, this hypercall is special, because both Dom0 and DomU must use this.
> + */
> +#define XEN_MC_fetch            1
> +struct xen_mc_fetch {
> +    /* IN/OUT variables.
> +	 * IN: XEN_MC_NONURGENT, XEN_MC_URGENT,
> +	 * XEN_MC_ACK if ack'king an earlier fetch
> +	 * OUT: XEN_MC_OK, XEN_MC_FETCHAILED,
> +	 * XEN_MC_NODATA, XEN_MC_NOMATCH
> +	*/
> +	uint32_t flags;
> +	uint32_t _pad0;
> +	/* OUT: id for ack, IN: id we are ack'ing */
> +	uint64_t fetch_id;
> +
> +	/* OUT variables. */
> +	GUEST_HANDLE(mc_info) data;
> +};
> +typedef struct xen_mc_fetch xen_mc_fetch_t;
> +DEFINE_GUEST_HANDLE_STRUCT(xen_mc_fetch);
> +
> +
> +/* Usecase 4
> + * This tells the hypervisor to notify a DomU about the machine check error
> + */
> +#define XEN_MC_notifydomain     2
> +struct xen_mc_notifydomain {
> +	/* IN variables. */
> +	uint16_t mc_domid;/* The unprivileged domain to notify. */
> +	uint16_t mc_vcpuid;/* The vcpu in mc_domid to notify.
> +			* Usually echo'd value from the fetch hypercall. */
> +
> +	/* IN/OUT variables. */
> +	uint32_t flags;
> +
> +/* OUT: XEN_MC_OK, XEN_MC_CANNOTHANDLE, XEN_MC_NOTDELIVERED, XEN_MC_NOMATCH */
> +};
> +typedef struct xen_mc_notifydomain xen_mc_notifydomain_t;
> +DEFINE_GUEST_HANDLE_STRUCT(xen_mc_notifydomain);
> +
> +#define XEN_MC_physcpuinfo 3
> +struct xen_mc_physcpuinfo {
> +	/* IN/OUT */
> +	uint32_t ncpus;
> +	uint32_t _pad0;
> +	/* OUT */
> +	GUEST_HANDLE(mcinfo_logical_cpu) info;
> +};
> +
> +#define XEN_MC_msrinject    4
> +#define MC_MSRINJ_MAXMSRS       8

These are a bit out of sync. Can you make them on aligned please.
> +struct xen_mc_msrinject {
> +	/* IN */
> +	uint32_t mcinj_cpunr;/* target processor id */
> +	uint32_t mcinj_flags;/* see MC_MSRINJ_F_* below */
> +	uint32_t mcinj_count;/* 0 .. count-1 in array are valid */
> +	uint32_t _pad0;
> +	struct mcinfo_msr mcinj_msr[MC_MSRINJ_MAXMSRS];
> +};
> +
> +/* Flags for mcinj_flags above; bits 16-31 are reserved */
> +#define MC_MSRINJ_F_INTERPOSE   0x1
> +
> +#define XEN_MC_mceinject    5

And these as well.
> +struct xen_mc_mceinject {
> +	unsigned int mceinj_cpunr;      /* target processor id */
> +};
> +
> +struct xen_mc {
> +	uint32_t cmd;
> +	uint32_t interface_version; /* XEN_MCA_INTERFACE_VERSION */
> +	union {
> +		struct xen_mc_fetch        mc_fetch;
> +		struct xen_mc_notifydomain mc_notifydomain;
> +		struct xen_mc_physcpuinfo  mc_physcpuinfo;
> +		struct xen_mc_msrinject    mc_msrinject;
> +		struct xen_mc_mceinject    mc_mceinject;
> +	} u;
> +};
> +typedef struct xen_mc xen_mc_t;

Ugh. No typedefs. Please rework this to get rid of that.
> +DEFINE_GUEST_HANDLE_STRUCT(xen_mc);
> +
> +#endif /* __ASSEMBLY__ */
> +
> +#endif /* __XEN_PUBLIC_ARCH_X86_MCA_H__ */
> -- 
> 1.6.5.6


> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 23 12:43:27 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 Dec 2011 12:43:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Re4S6-0005i4-JG; Fri, 23 Dec 2011 12:42:22 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1Re4S4-0005hz-VM
	for xen-devel@lists.xensource.com; Fri, 23 Dec 2011 12:42:21 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-7.tower-27.messagelabs.com!1324644079!61906011!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=1.9 required=7.0 tests=BODY_RANDOM_LONG,INFO_TLD
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28598 invoked from network); 23 Dec 2011 12:41:21 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-7.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 23 Dec 2011 12:41:21 -0000
Received: from andromeda.dapyr.net (darnok@localhost [127.0.0.1])
	by andromeda.dapyr.net (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id
	pBNCg8qM028472
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Fri, 23 Dec 2011 07:42:08 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pBNCg8BH028470;
	Fri, 23 Dec 2011 07:42:08 -0500
Date: Fri, 23 Dec 2011 08:42:08 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: "Liu, Jinsong" <jinsong.liu@intel.com>
Message-ID: <20111223124208.GA25286@andromeda.dapyr.net>
References: <DE8DF0795D48FD4CA783C40EC82923359699@SHSMSX101.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <DE8DF0795D48FD4CA783C40EC82923359699@SHSMSX101.ccr.corp.intel.com>
User-Agent: Mutt/1.5.9i
Cc: "Brown, Len" <len.brown@intel.com>,
	"jeremy.fitzhardinge@citrix.com" <jeremy.fitzhardinge@citrix.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>, "Jiang,
	Yunhong" <yunhong.jiang@intel.com>, "Shan, Haitao" <haitao.shan@intel.com>,
	Kernel development list <linux-kernel@vger.kernel.org>, "Zhao,
	Yakui" <yakui.zhao@intel.com>, "Luck, Tony" <tony.luck@intel.com>, "Kleen,
	Andi" <andi.kleen@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 01/10] Add mcelog support from xen platform
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Dec 23, 2011 at 10:23:03AM +0000, Liu, Jinsong wrote:
> >From 0e8de1ce0f13aa34aa6013e6a387ae5be78031ca Mon Sep 17 00:00:00 2001
> From: Liu Jinsong <jinsong.liu@intel.com>
> Date: Tue, 6 Dec 2011 18:08:12 +0800
> Subject: [PATCH 01/10] Add mcelog support from xen platform

.. for xen platform.
> 
> This patch backport from Jeremy's pvops commit a5ed1f3dae179158e385e9371462dd65d5e125c5,
> which in turn backport from previous xen DOM0(2.6.18) cs: 75e5bfa7fbdc

Ok. You should also include a link to the tree.

Is this patch by itself usuable? Meaning it can work without being
dependent on the ACPI patches?
> 
> When a MCE/CMCI error happens (or by polling), the related error

What does CMCI stand for? Can you include the full description of
what those are (both MCE and CMCI)?
> information will be sent to privileged pv-ops domain by XEN. This

No need to say 'pv-ops'. This patchset is _for_ the pv-ops kernel
and it is _only_ a pv-ops type kernel.

> patch will help to fetch the xen-logged information by hypercall

s/xen-logged/logged
> and then convert XEN-format log into Linux format MCELOG. It makes
> using current available mcelog tools for native Linux possible.

Excellent. Can you include in this section how to test it.
A step by step instruction? Or perhaps just point to documentation
if such exist?

> 
> With this patch, after mce/cmci error log information is sent to
> pv-ops guest, Running mcelog tools in the guest, you will get same

Priviliged guests or not-priviliged?
> detailed decoded mce information as in Native Linux.
> 
> Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
> Signed-off-by: Ke, Liping <liping.ke@intel.com>
> Signed-off-by: Jiang, Yunhong <yunhong.jiang@intel.com>
> Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
> ---
>  arch/x86/include/asm/xen/hypercall.h |    8 +
>  arch/x86/xen/enlighten.c             |    8 +-
>  drivers/xen/Kconfig                  |    8 +
>  drivers/xen/Makefile                 |    1 +
>  drivers/xen/mcelog.c                 |  217 +++++++++++++++++
>  include/xen/interface/xen-mca.h      |  429 ++++++++++++++++++++++++++++++++++

Make sure you run this patch through scripts/cleanpatch.pl.

I ran it through that and found 8 issues, please fix those.

>  6 files changed, 667 insertions(+), 4 deletions(-)
>  create mode 100644 drivers/xen/mcelog.c
>  create mode 100644 include/xen/interface/xen-mca.h
> 
> diff --git a/arch/x86/include/asm/xen/hypercall.h b/arch/x86/include/asm/xen/hypercall.h
> index 5728852..59c226d 100644
> --- a/arch/x86/include/asm/xen/hypercall.h
> +++ b/arch/x86/include/asm/xen/hypercall.h
> @@ -48,6 +48,7 @@
>  #include <xen/interface/sched.h>
>  #include <xen/interface/physdev.h>
>  #include <xen/interface/platform.h>
> +#include <xen/interface/xen-mca.h>
>  
>  /*
>   * The hypercall asms have to meet several constraints:
> @@ -302,6 +303,13 @@ HYPERVISOR_set_timer_op(u64 timeout)
>  }
>  
>  static inline int
> +HYPERVISOR_mca(struct xen_mc *mc_op)
> +{
> +	mc_op->interface_version = XEN_MCA_INTERFACE_VERSION;
> +	return _hypercall1(int, mca, mc_op);
> +}
> +
> +static inline int
>  HYPERVISOR_dom0_op(struct xen_platform_op *platform_op)
>  {
>  	platform_op->interface_version = XENPF_INTERFACE_VERSION;
> diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
> index 9306320..b073e4c 100644
> --- a/arch/x86/xen/enlighten.c
> +++ b/arch/x86/xen/enlighten.c
> @@ -242,14 +242,14 @@ static void __init xen_init_cpuid_mask(void)
>  	unsigned int xsave_mask;
>  
>  	cpuid_leaf1_edx_mask =
> -		~((1 << X86_FEATURE_MCE)  |  /* disable MCE */
> -		  (1 << X86_FEATURE_MCA)  |  /* disable MCA */
> -		  (1 << X86_FEATURE_MTRR) |  /* disable MTRR */
> +		~((1 << X86_FEATURE_MTRR) |  /* disable MTRR */
>  		  (1 << X86_FEATURE_ACC));   /* thermal monitoring */
>  
>  	if (!xen_initial_domain())
>  		cpuid_leaf1_edx_mask &=
> -			~((1 << X86_FEATURE_APIC) |  /* disable local APIC */
> +			~((1 << X86_FEATURE_MCE)  |  /* disable MCE */
> +			  (1 << X86_FEATURE_MCA)  |  /* disable MCA */
> +			  (1 << X86_FEATURE_APIC) |  /* disable local APIC */
>  			  (1 << X86_FEATURE_ACPI));  /* disable ACPI */
>  	ax = 1;
>  	xen_cpuid(&ax, &bx, &cx, &dx);
> diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
> index e8fb85f..eb2a327 100644
> --- a/drivers/xen/Kconfig
> +++ b/drivers/xen/Kconfig
> @@ -117,6 +117,14 @@ config XEN_SYS_HYPERVISOR
>  	 virtual environment, /sys/hypervisor will still be present,
>  	 but will have no xen contents.
>  
> +config XEN_MCE_LOG
> +	bool "Xen platform mcelog"
> +	depends on XEN_DOM0 && X86_64 && X86_MCE
> +	default y

That should 'n'.
> +	help
> +	  Allow kernel fetching mce log from xen platform and
> +	  converting it into linux mcelog format for mcelog tools
> +
>  config ACPI_PROCESSOR_XEN
>  	tristate
>  	depends on XEN_DOM0 && ACPI_PROCESSOR && CPU_FREQ
> diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
> index d42da53..405cce9 100644
> --- a/drivers/xen/Makefile
> +++ b/drivers/xen/Makefile
> @@ -14,6 +14,7 @@ obj-$(CONFIG_XEN_GNTDEV)		+= xen-gntdev.o
>  obj-$(CONFIG_XEN_GRANT_DEV_ALLOC)	+= xen-gntalloc.o
>  obj-$(CONFIG_XENFS)			+= xenfs/
>  obj-$(CONFIG_XEN_SYS_HYPERVISOR)	+= sys-hypervisor.o
> +obj-$(CONFIG_XEN_MCE_LOG)		+= mcelog.o
>  obj-$(CONFIG_XEN_PLATFORM_PCI)		+= xen-platform-pci.o
>  obj-$(CONFIG_XEN_TMEM)			+= tmem.o
>  obj-$(CONFIG_SWIOTLB_XEN)		+= swiotlb-xen.o
> diff --git a/drivers/xen/mcelog.c b/drivers/xen/mcelog.c
> new file mode 100644
> index 0000000..892ca7b
> --- /dev/null
> +++ b/drivers/xen/mcelog.c
> @@ -0,0 +1,217 @@
> +/******************************************************************************
> + * mcelog.c
> + * Add Machine Check event Logging support in DOM0
> + *
> + * Driver for receiving and logging machine check event

Uh, logging? I thought the logging would be handed of the generic MCElog
interface?

> + *
> + * Copyright (c) 2008, 2009 Intel Corporation
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License version 2
> + * as published by the Free Software Foundation; or, when distributed
> + * separately from the Linux kernel or incorporated into other
> + * software packages, subject to the following license:
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a copy
> + * of this source file (the "Software"), to deal in the Software without
> + * restriction, including without limitation the rights to use, copy, modify,
> + * merge, publish, distribute, sublicense, and/or sell copies of the Software,
> + * and to permit persons to whom the Software is furnished to do so, subject to
> + * the following conditions:
> + *
> + * The above copyright notice and this permission notice shall be included in
> + * all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
> + * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
> + * IN THE SOFTWARE.
> + */
> +
> +#include <linux/module.h>
> +#include <linux/init.h>
> +#include <linux/types.h>
> +#include <linux/kernel.h>
> +#include <linux/slab.h>
> +#include <xen/interface/xen.h>
> +#include <asm/xen/hypervisor.h>
> +#include <xen/events.h>
> +#include <xen/interface/vcpu.h>
> +#include <asm/xen/hypercall.h>
> +#include <asm/mce.h>
> +#include <xen/xen.h>
> +
> +static mc_info_t *g_mi;

Include a comment saying why you don't need locking for the 'g_mi'
structure.
> +static mcinfo_logical_cpu_t *g_physinfo;

.. and for this one too.

> +static uint32_t ncpus;
> +
> +static int convert_log(struct mc_info *mi)
> +{
> +	struct mcinfo_common *mic = NULL;
> +	struct mcinfo_global *mc_global;
> +	struct mcinfo_bank *mc_bank;
> +	struct mce m;
> +	int i, found = 0;

Make 'found' a bool please.
> +
> +	x86_mcinfo_lookup(&mic, mi, MC_TYPE_GLOBAL);
> +	WARN_ON(!mic);

Should there be some extra information? Say:

WARN_ON(!mic,"Was not able to find global MCE!")

Should you quit this routine if this happens?
> +
> +	mce_setup(&m);
> +	mc_global = (struct mcinfo_global *)mic;
> +	m.mcgstatus = mc_global->mc_gstatus;

So if mic=NULL, this would do mic->mc_gstatus which would trigger a NULL
pointer problem. Please rework this.
> +	m.apicid = mc_global->mc_apicid;

And this one too.

> +	for (i = 0; i < ncpus; i++) {
> +		if (g_physinfo[i].mc_apicid == m.apicid) {
> +			found = 1;
> +			break;
> +		}
> +	}
> +	WARN_ON(!found);

So... if we went through _all_ of the g_physinfo and
did not find the m.apicid, we would print a WARN_ON
and then here:
> +
> +	m.socketid = g_physinfo[i].mc_chipid;

we would use the last g_physinfo record. Shouldn't we just
abondon this instead and return from this function?

> +	m.cpu = m.extcpu = g_physinfo[i].mc_cpunr;
> +	m.cpuvendor = (__u8)g_physinfo[i].mc_vendor;

Why the casting?
> +	m.mcgcap = g_physinfo[i].mc_msrvalues[0].value;

Is it always going to 0? Should there be a define for the
entries in the array?

You ought to do this first:
	mic = NULL;

before calling this function. I know that the function does set
the *mic = NULL on entry but that is not obvious from this level
of the function. So either say it (one line comment) or just
do that 'mic = NULL'
> +	x86_mcinfo_lookup(&mic, mi, MC_TYPE_BANK);
> +	do {
> +		if (mic == NULL || mic->size == 0)
> +			break;
> +		if (mic->type == MC_TYPE_BANK) {
> +			mc_bank = (struct mcinfo_bank *)mic;
> +			m.misc = mc_bank->mc_misc;
> +			m.status = mc_bank->mc_status;
> +			m.addr = mc_bank->mc_addr;
> +			m.tsc = mc_bank->mc_tsc;
> +			m.bank = mc_bank->mc_bank;
> +			m.finished = 1;
> +			/*log this record*/
> +			mce_log(&m);
> +		}
> +		mic = x86_mcinfo_next(mic);
> +	} while (1);
> +
> +	return 0;
> +}
> +
> +/*pv_ops domain mce virq handler, logging physical mce error info*/

Get rid of the 'pv_ops' domain please.

Can you expand this a bit. Say when this interrupt happens, how often
it can happen, and whether it can only be sent to priviliged domains.

> +static irqreturn_t mce_dom_interrupt(int irq, void *dev_id)
> +{
> +	xen_mc_t mc_op;
> +	int result = 0;

int err = 0;

> +
> +	mc_op.cmd = XEN_MC_fetch;
> +	mc_op.interface_version = XEN_MCA_INTERFACE_VERSION;
> +	set_xen_guest_handle(mc_op.u.mc_fetch.data, g_mi);
> +urgent:
> +	mc_op.u.mc_fetch.flags = XEN_MC_URGENT;
> +	result = HYPERVISOR_mca(&mc_op);
> +	if (result || mc_op.u.mc_fetch.flags & XEN_MC_NODATA ||
> +			mc_op.u.mc_fetch.flags & XEN_MC_FETCHFAILED)

Please fix the spacing. They should be aligned.
> +		goto nonurgent;
> +	else {
> +		result = convert_log(g_mi);
> +		if (result)
> +			goto end;
> +		/* After fetching the error event log entry from DOM0,
> +		 * we need to dec the refcnt and release the entry.
> +		 * The entry is reserved and inc refcnt when filling
> +		 * the error log entry.

Uh? Which refcnt? Where is the refcnt? Can you explain this in more
details please?
> +		 */
> +		mc_op.u.mc_fetch.flags = XEN_MC_URGENT | XEN_MC_ACK;
> +		result = HYPERVISOR_mca(&mc_op);
> +		goto urgent;

Eww, this is a while loop using goto statements.

Can you restructure this to be a while loop please?

> +	}
> +nonurgent:
> +	mc_op.u.mc_fetch.flags = XEN_MC_NONURGENT;
> +	result = HYPERVISOR_mca(&mc_op);
> +	if (result || mc_op.u.mc_fetch.flags & XEN_MC_NODATA ||
> +			mc_op.u.mc_fetch.flags & XEN_MC_FETCHFAILED)
> +		goto end;
> +	else {
> +		result = convert_log(g_mi);
> +		if (result)
> +			goto end;
> +		/* After fetching the error event log entry from DOM0,
> +		 * we need to dec the refcnt and release the entry. The
> +		 * entry is reserved and inc refcnt when filling the
> +		 * error log entry.
> +		 */
> +		mc_op.u.mc_fetch.flags = XEN_MC_NONURGENT | XEN_MC_ACK;
> +		result = HYPERVISOR_mca(&mc_op);
> +		goto nonurgent;

This is the same as the previous code. Can you squash these together?
You could use a state flag to figure out if you are doing the urgent
vs the non-urgent part now.

Or you can move this 'while loop' in its own function and just call
it with the different flags.

> +	}
> +end:
> +	return IRQ_HANDLED;
> +}
> +
> +static int bind_virq_for_mce(void)
> +{
> +	int ret;
> +	xen_mc_t mc_op;
> +
> +	g_mi = kmalloc(sizeof(struct mc_info), GFP_KERNEL);

Most of the time 'kzalloc' is used just in case you do not end
up filling all of the fields of the mc_op. And this is especially true
if you run with CONFIG_DEBUG_PAGEALLOC which will them with garbage
and you can get interesting results when you have forgotton to set them
all.

So if you are sure that _all_ the fields of the 'mc_op' have been filled
then you don't need kmalloc. But otherwise please use 'kzalloc'.
> +
> +	if (!g_mi)
> +		return -ENOMEM;
> +
> +	/* Fetch physical CPU Numbers */
> +	mc_op.cmd = XEN_MC_physcpuinfo;
> +	mc_op.interface_version = XEN_MCA_INTERFACE_VERSION;
> +	set_xen_guest_handle(mc_op.u.mc_physcpuinfo.info, g_physinfo);
> +	ret = HYPERVISOR_mca(&mc_op);
> +	if (ret) {
> +		printk(KERN_ERR "MCE_DOM0_LOG: Fail to get physical CPU numbers\n");

..s/fail/failed.

Is the DOM0 part neccessary? The user knows he/she is running under xen
and what difference does it make it if its domU or dom0?

> +		kfree(g_mi);
> +		return ret;
> +	}
> +
> +	/* Fetch each CPU Physical Info for later reference*/
> +	ncpus = mc_op.u.mc_physcpuinfo.ncpus;
> +	g_physinfo = kmalloc(sizeof(struct mcinfo_logical_cpu)*ncpus,
> +					GFP_KERNEL);

Align the spacing please. And also put a space for the '*'
> +	if (!g_physinfo) {
> +		kfree(g_mi);
> +		return -ENOMEM;
> +	}
> +	set_xen_guest_handle(mc_op.u.mc_physcpuinfo.info, g_physinfo);
> +	ret = HYPERVISOR_mca(&mc_op);
> +	if (ret) {
> +		printk(KERN_ERR "MCE_DOM0_LOG: Fail to get physical CPUs info\n");

Some comment about the dom0, fail for this.
> +		kfree(g_mi);
> +		kfree(g_physinfo);
> +		return ret;
> +	}
> +
> +	ret  = bind_virq_to_irqhandler(VIRQ_MCA, 0,
> +		mce_dom_interrupt, 0, "mce", NULL);
Please tab/space align this properly.
> +
> +	if (ret < 0) {
> +		printk(KERN_ERR "MCE_DOM0_LOG: bind_virq for DOM0 failed\n");
> +		return ret;
> +	}
> +
> +	return 0;
> +}
> +
> +static int __init mcelog_init(void)
> +{
> +	/* Only DOM0 is responsible for MCE logging */
> +	if (xen_initial_domain())
> +		return bind_virq_for_mce();
> +
> +	return 0;

return -ENODEV;

for the non-initial-domain case. Otherwise you end up loading this
module for nothing.
> +}
> +
> +
> +static void __exit mcelog_cleanup(void)
> +{
> +	kfree(g_mi);
> +	kfree(g_physinfo);
> +}
> +module_init(mcelog_init);
> +module_exit(mcelog_cleanup);
> +
> +MODULE_LICENSE("GPL");
> diff --git a/include/xen/interface/xen-mca.h b/include/xen/interface/xen-mca.h
> new file mode 100644
> index 0000000..f31fdab
> --- /dev/null
> +++ b/include/xen/interface/xen-mca.h
> @@ -0,0 +1,429 @@
> +/******************************************************************************
> + * arch-x86/mca.h
> + *
> + * Contributed by Advanced Micro Devices, Inc.
> + * Author: Christoph Egger <Christoph.Egger@amd.com>
> + *
> + * Guest OS machine check interface to x86 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.
> + */
> +
> +/* Full MCA functionality has the following Usecases from the guest side:
> + *
> + * Must have's:
> + * 1. Dom0 and DomU register machine check trap callback handlers
> + *    (already done via "set_trap_table" hypercall)
> + * 2. Dom0 registers machine check event callback handler
> + *    (doable via EVTCHNOP_bind_virq)
> + * 3. Dom0 and DomU fetches machine check data

So the domU case is not covered here. is there another patch for that?
> + * 4. Dom0 wants Xen to notify a DomU
> + * 5. Dom0 gets DomU ID from physical address
> + * 6. Dom0 wants Xen to kill DomU (already done for "xm destroy")
> + *
> + * Nice to have's:
> + * 7. Dom0 wants Xen to deactivate a physical CPU
> + *    This is better done as separate task, physical CPU hotplugging,
> + *    and hypercall(s) should be sysctl's
> + * 8. Page migration proposed from Xen NUMA work, where Dom0 can tell Xen to
> + *    move a DomU (or Dom0 itself) away from a malicious page
> + *    producing correctable errors.
> + * 9. offlining physical page:
> + *    Xen free's and never re-uses a certain physical page.
> + * 10. Testfacility: Allow Dom0 to write values into machine check MSR's
> + *     and tell Xen to trigger a machine check
> + */
> +
> +#ifndef __XEN_PUBLIC_ARCH_X86_MCA_H__
> +#define __XEN_PUBLIC_ARCH_X86_MCA_H__
> +
> +/* Hypercall */
> +#define __HYPERVISOR_mca __HYPERVISOR_arch_0
> +
> +/*
> + * The xen-unstable repo has interface version 0x03000001; out interface
> + * is incompatible with that and any future minor revisions, so we
> + * choose a different version number range that is numerically less
> + * than that used in xen-unstable.

I don't understand that. Does it mean you can't use this with
xen-unstable? Or that it can't be used with 4.1? Can this be fixed
in the xen-unstable tree? Which xen-unstable tree? At what point was
this neccessary ? (include a c/s to denote _when_ so one has an idea if
this is truly true anymore).
> + */
> +#define XEN_MCA_INTERFACE_VERSION 0x01ecc003
> +
> +/* IN: Dom0 calls hypercall to retrieve nonurgent error log entry */
> +#define XEN_MC_NONURGENT  0x0001
> +/* IN: Dom0/DomU calls hypercall to retrieve urgent error log entry */
> +#define XEN_MC_URGENT     0x0002
> +/* IN: Dom0 acknowledges previosly-fetched error log entry */
> +#define XEN_MC_ACK        0x0004
> +
> +/* OUT: All is ok */
> +#define XEN_MC_OK           0x0
> +/* OUT: Domain could not fetch data. */
> +#define XEN_MC_FETCHFAILED  0x1
> +/* OUT: There was no machine check data to fetch. */
> +#define XEN_MC_NODATA       0x2
> +/* OUT: Between notification time and this hypercall an other
> + *  (most likely) correctable error happened. The fetched data,
> + *  does not match the original machine check data. */
> +#define XEN_MC_NOMATCH      0x4
> +
> +/* OUT: DomU did not register MC NMI handler. Try something else. */
> +#define XEN_MC_CANNOTHANDLE 0x8
> +/* OUT: Notifying DomU failed. Retry later or try something else. */
> +#define XEN_MC_NOTDELIVERED 0x10
> +/* Note, XEN_MC_CANNOTHANDLE and XEN_MC_NOTDELIVERED are mutually exclusive. */
> +
> +
> +#ifndef __ASSEMBLY__
> +
> +#define VIRQ_MCA VIRQ_ARCH_0 /* G. (DOM0) Machine Check Architecture */

What is the 'G.' for?
> +
> +/*
> + * Machine Check Architecure:
> + * structs are read-only and used to report all kinds of
> + * correctable and uncorrectable errors detected by the HW.
> + * Dom0 and DomU: register a handler to get notified.

Uhh. But your code does not do that? It only does it for the dom0 case?
Is this comment still valid?
> + * Dom0 only: Correctable errors are reported via VIRQ_MCA
> + */
> +#define MC_TYPE_GLOBAL          0

Can you describe what this means?
> +#define MC_TYPE_BANK            1

And this?
> +#define MC_TYPE_EXTENDED        2
And this?
> +#define MC_TYPE_RECOVERY        3

So are these Xen ABI specific or do they overlap with the Linux
idea of MC type checks? Please include that information in the
comment section.

> +
> +struct mcinfo_common {
> +	uint16_t type;      /* structure type */
> +	uint16_t size;      /* size of this struct in bytes */
> +};
> +
> +
> +#define MC_FLAG_CORRECTABLE     (1 << 0)
> +#define MC_FLAG_UNCORRECTABLE   (1 << 1)
> +#define MC_FLAG_RECOVERABLE	(1 << 2)
> +#define MC_FLAG_POLLED		(1 << 3)
> +#define MC_FLAG_RESET		(1 << 4)
> +#define MC_FLAG_CMCI		(1 << 5)
> +#define MC_FLAG_MCE		(1 << 6)

UGh, that looks out of alignemnt. Not sure if this my mailer or what but
please double check.
> +/* contains global x86 mc information */
> +struct mcinfo_global {
> +	struct mcinfo_common common;
> +
> +	/* running domain at the time in error (most likely
> +	 * the impacted one) */
> +	uint16_t mc_domid;
> +	uint16_t mc_vcpuid; /* virtual cpu scheduled for mc_domid */
> +	uint32_t mc_socketid; /* physical socket of the physical core */
> +	uint16_t mc_coreid; /* physical impacted core */
> +	uint16_t mc_core_threadid; /* core thread of physical core */
> +	uint32_t mc_apicid;
> +	uint32_t mc_flags;
> +	uint64_t mc_gstatus; /* global status */
> +};
> +
> +/* contains bank local x86 mc information */
> +struct mcinfo_bank {
> +	struct mcinfo_common common;
> +
> +	uint16_t mc_bank; /* bank nr */
> +	uint16_t mc_domid; /* Usecase 5: domain referenced by mc_addr on
> +			* privileged pv-ops dom and if mc_addr is valid.
> +			* Never valid on DomU. */
> +	uint64_t mc_status; /* bank status */
> +	uint64_t mc_addr;   /* bank address, only valid
> +					 * if addr bit is set in mc_status */

Please fix the spacing.
> +	uint64_t mc_misc;
> +	uint64_t mc_ctrl2;
> +	uint64_t mc_tsc;
> +};
> +
> +
> +struct mcinfo_msr {
> +	uint64_t reg;   /* MSR */
> +	uint64_t value; /* MSR value */
> +};
> +
> +/* contains mc information from other
> + * or additional mc MSRs */
> +struct mcinfo_extended {
> +	struct mcinfo_common common;
> +
> +	/* You can fill up to five registers.
> +	 * If you need more, then use this structure
> +	 * multiple times. */
> +
> +	uint32_t mc_msrs; /* Number of msr with valid values. */
> +	/*
> +	 * Currently Intel extended MSR (32/64) include all gp registers
> +	 * and E(R)FLAGS, E(R)IP, E(R)MISC, up to 11/19 of them might be
> +	 * useful at present. So expand this array to 16/32 to leave room.
> +	 */
> +	struct mcinfo_msr mc_msr[sizeof(void *) * 4];
> +};
> +
> +/* Recovery Action flags. Giving recovery result information to DOM0 */
> +
> +/* Xen takes successful recovery action, the error is recovered */
> +#define REC_ACTION_RECOVERED (0x1 << 0)
> +/* No action is performed by XEN */
> +#define REC_ACTION_NONE (0x1 << 1)
> +/* It's possible DOM0 might take action ownership in some case */
> +#define REC_ACTION_NEED_RESET (0x1 << 2)
> +
> +/* Different Recovery Action types, if the action is performed successfully,
> + * REC_ACTION_RECOVERED flag will be returned.
> + */
> +
> +/* Page Offline Action */
> +#define MC_ACTION_PAGE_OFFLINE (0x1 << 0)
> +/* CPU offline Action */
> +#define MC_ACTION_CPU_OFFLINE (0x1 << 1)
> +/* L3 cache disable Action */
> +#define MC_ACTION_CACHE_SHRINK (0x1 << 2)
> +
> +/* Below interface used between XEN/DOM0 for passing XEN's recovery action
> + * information to DOM0.
> + * usage Senario: After offlining broken page, XEN might pass its page offline
> + * recovery action result to DOM0. DOM0 will save the information in
> + * non-volatile memory for further proactive actions, such as offlining the
> + * easy broken page earlier when doing next reboot.

Can you rewrite the last paragraph please. It is not clear what you
mean.
> +*/
> +struct page_offline_action {
> +	/* Params for passing the offlined page number to DOM0 */
> +	uint64_t mfn;
> +	uint64_t status;
> +};
> +
> +struct cpu_offline_action {
> +	/* Params for passing the identity of the offlined CPU to DOM0 */
> +	uint32_t mc_socketid;
> +	uint16_t mc_coreid;
> +	uint16_t mc_core_threadid;
> +};
> +
> +#define MAX_UNION_SIZE 16
> +struct mcinfo_recovery {
> +	struct mcinfo_common common;
> +	uint16_t mc_bank; /* bank nr */
> +	/* Recovery Action Flags defined above such as REC_ACTION_DONE */
> +	uint8_t action_flags;
> +	/* Recovery Action types defined above such as MC_ACTION_PAGE_OFFLINE */
> +	uint8_t action_types;
> +	/* In future if more than one recovery action permitted per error bank,
> +	 * a mcinfo_recovery data array will be returned
> +	 */
> +	union {
> +		struct page_offline_action page_retire;
> +		struct cpu_offline_action cpu_offline;
> +		uint8_t pad[MAX_UNION_SIZE];
> +	} action_info;
> +};
> +
> +
> +#define MCINFO_HYPERCALLSIZE	1024
> +#define MCINFO_MAXSIZE		768
> +
> +struct mc_info {
> +	/* Number of mcinfo_* entries in mi_data */
> +	uint32_t mi_nentries;
> +	uint32_t _pad0;
> +	uint64_t mi_data[(MCINFO_MAXSIZE - 1) / 8];
> +};
> +typedef struct mc_info mc_info_t;
> +DEFINE_GUEST_HANDLE_STRUCT(mc_info);
> +
> +#define __MC_MSR_ARRAYSIZE 8
> +#define __MC_NMSRS 1
> +#define MC_NCAPS	7	/* 7 CPU feature flag words */
> +#define MC_CAPS_STD_EDX	0	/* cpuid level 0x00000001 (%edx) */
> +#define MC_CAPS_AMD_EDX	1	/* cpuid level 0x80000001 (%edx) */
> +#define MC_CAPS_TM	2	/* cpuid level 0x80860001 (TransMeta) */
> +#define MC_CAPS_LINUX	3	/* Linux-defined */
> +#define MC_CAPS_STD_ECX	4	/* cpuid level 0x00000001 (%ecx) */
> +#define MC_CAPS_VIA	5	/* cpuid level 0xc0000001 */
> +#define MC_CAPS_AMD_ECX	6	/* cpuid level 0x80000001 (%ecx) */
> +
> +struct mcinfo_logical_cpu {
> +	uint32_t mc_cpunr;
> +	uint32_t mc_chipid;
> +	uint16_t mc_coreid;
> +	uint16_t mc_threadid;
> +	uint32_t mc_apicid;
> +	uint32_t mc_clusterid;
> +	uint32_t mc_ncores;
> +	uint32_t mc_ncores_active;
> +	uint32_t mc_nthreads;
> +	int32_t mc_cpuid_level;

This looks odd? Can you explain why it is int32 instead of uint32?

> +	uint32_t mc_family;
> +	uint32_t mc_vendor;
> +	uint32_t mc_model;
> +	uint32_t mc_step;
> +	char mc_vendorid[16];
> +	char mc_brandid[64];
> +	uint32_t mc_cpu_caps[MC_NCAPS];
> +	uint32_t mc_cache_size;
> +	uint32_t mc_cache_alignment;
> +	int32_t mc_nmsrvals;

Ditto.
> +	struct mcinfo_msr mc_msrvalues[__MC_MSR_ARRAYSIZE];
> +};
> +typedef struct mcinfo_logical_cpu mcinfo_logical_cpu_t;

No typedefs.
> +DEFINE_GUEST_HANDLE_STRUCT(mcinfo_logical_cpu);
> +
> +
> +/*
> + * OS's should use these instead of writing their own lookup function
> + * each with its own bugs and drawbacks.

What are the drawbacks?
> + * We use macros instead of static inline functions to allow guests
> + * to include this header in assembly files (*.S).
> + */
> +/* Prototype:
> + *    uint32_t x86_mcinfo_nentries(struct mc_info *mi);
> + */
> +#define x86_mcinfo_nentries(_mi)    \
> +    ((_mi)->mi_nentries)
> +/* Prototype:
> + *    struct mcinfo_common *x86_mcinfo_first(struct mc_info *mi);
> + */
> +#define x86_mcinfo_first(_mi)       \
> +    ((struct mcinfo_common *)(_mi)->mi_data)
> +/* Prototype:
> + *    struct mcinfo_common *x86_mcinfo_next(struct mcinfo_common *mic);
> + */
> +#define x86_mcinfo_next(_mic)       \
> +    ((struct mcinfo_common *)((uint8_t *)(_mic) + (_mic)->size))
> +
> +/* Prototype:
> + *    void x86_mcinfo_lookup(void *ret, struct mc_info *mi, uint16_t type);
> + */
> +
> +static inline void x86_mcinfo_lookup
> +	(struct mcinfo_common **ret, struct mc_info *mi, uint16_t type)

Fix the argument list. It should be something like this:
static inline void x86_mcinfo_lookup(struct mcinfo_common *ret,
				     struct mc_info *mi, ...

> +{
> +	uint32_t found = 0, i;

Make found be a 'bool' please.

> +	struct mcinfo_common *mic;
> +
> +	*ret = NULL;

Check if ret is NULL first. Like:

	if (!ret)
		return

> +	if (!mi)
> +		return;

or you can merge them both together:
	if (!mi || !ret)
		return;
> +	mic = x86_mcinfo_first(mi);
> +
> +	for (i = 0; i < x86_mcinfo_nentries(mi); i++) {
> +		if (mic->type == type) {
> +			found = 1;
> +			break;
> +		}
> +		mic = x86_mcinfo_next(mic);
> +	}
> +
> +	*ret = found ? mic : NULL;
> +}
> +/* Usecase 1
> + * Register machine check trap callback handler
> + *    (already done via "set_trap_table" hypercall)
> + */
> +
> +/* Usecase 2
> + * Dom0 registers machine check event callback handler
> + * done by EVTCHNOP_bind_virq
> + */
> +
> +/* Usecase 3
> + * Fetch machine check data from hypervisor.
> + * Note, this hypercall is special, because both Dom0 and DomU must use this.
> + */
> +#define XEN_MC_fetch            1
> +struct xen_mc_fetch {
> +    /* IN/OUT variables.
> +	 * IN: XEN_MC_NONURGENT, XEN_MC_URGENT,
> +	 * XEN_MC_ACK if ack'king an earlier fetch
> +	 * OUT: XEN_MC_OK, XEN_MC_FETCHAILED,
> +	 * XEN_MC_NODATA, XEN_MC_NOMATCH
> +	*/
> +	uint32_t flags;
> +	uint32_t _pad0;
> +	/* OUT: id for ack, IN: id we are ack'ing */
> +	uint64_t fetch_id;
> +
> +	/* OUT variables. */
> +	GUEST_HANDLE(mc_info) data;
> +};
> +typedef struct xen_mc_fetch xen_mc_fetch_t;
> +DEFINE_GUEST_HANDLE_STRUCT(xen_mc_fetch);
> +
> +
> +/* Usecase 4
> + * This tells the hypervisor to notify a DomU about the machine check error
> + */
> +#define XEN_MC_notifydomain     2
> +struct xen_mc_notifydomain {
> +	/* IN variables. */
> +	uint16_t mc_domid;/* The unprivileged domain to notify. */
> +	uint16_t mc_vcpuid;/* The vcpu in mc_domid to notify.
> +			* Usually echo'd value from the fetch hypercall. */
> +
> +	/* IN/OUT variables. */
> +	uint32_t flags;
> +
> +/* OUT: XEN_MC_OK, XEN_MC_CANNOTHANDLE, XEN_MC_NOTDELIVERED, XEN_MC_NOMATCH */
> +};
> +typedef struct xen_mc_notifydomain xen_mc_notifydomain_t;
> +DEFINE_GUEST_HANDLE_STRUCT(xen_mc_notifydomain);
> +
> +#define XEN_MC_physcpuinfo 3
> +struct xen_mc_physcpuinfo {
> +	/* IN/OUT */
> +	uint32_t ncpus;
> +	uint32_t _pad0;
> +	/* OUT */
> +	GUEST_HANDLE(mcinfo_logical_cpu) info;
> +};
> +
> +#define XEN_MC_msrinject    4
> +#define MC_MSRINJ_MAXMSRS       8

These are a bit out of sync. Can you make them on aligned please.
> +struct xen_mc_msrinject {
> +	/* IN */
> +	uint32_t mcinj_cpunr;/* target processor id */
> +	uint32_t mcinj_flags;/* see MC_MSRINJ_F_* below */
> +	uint32_t mcinj_count;/* 0 .. count-1 in array are valid */
> +	uint32_t _pad0;
> +	struct mcinfo_msr mcinj_msr[MC_MSRINJ_MAXMSRS];
> +};
> +
> +/* Flags for mcinj_flags above; bits 16-31 are reserved */
> +#define MC_MSRINJ_F_INTERPOSE   0x1
> +
> +#define XEN_MC_mceinject    5

And these as well.
> +struct xen_mc_mceinject {
> +	unsigned int mceinj_cpunr;      /* target processor id */
> +};
> +
> +struct xen_mc {
> +	uint32_t cmd;
> +	uint32_t interface_version; /* XEN_MCA_INTERFACE_VERSION */
> +	union {
> +		struct xen_mc_fetch        mc_fetch;
> +		struct xen_mc_notifydomain mc_notifydomain;
> +		struct xen_mc_physcpuinfo  mc_physcpuinfo;
> +		struct xen_mc_msrinject    mc_msrinject;
> +		struct xen_mc_mceinject    mc_mceinject;
> +	} u;
> +};
> +typedef struct xen_mc xen_mc_t;

Ugh. No typedefs. Please rework this to get rid of that.
> +DEFINE_GUEST_HANDLE_STRUCT(xen_mc);
> +
> +#endif /* __ASSEMBLY__ */
> +
> +#endif /* __XEN_PUBLIC_ARCH_X86_MCA_H__ */
> -- 
> 1.6.5.6


> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 23 12:44:51 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 Dec 2011 12: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.xensource.com>)
	id 1Re4TO-0005li-95; Fri, 23 Dec 2011 12:43:42 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1Re4TM-0005lF-QZ
	for xen-devel@lists.xensource.com; Fri, 23 Dec 2011 12:43:41 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-7.tower-216.messagelabs.com!1324644213!8576401!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10157 invoked from network); 23 Dec 2011 12:43:34 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-7.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 23 Dec 2011 12:43:34 -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
	pBNChUA7028517
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Fri, 23 Dec 2011 07:43:30 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pBNChUgN028515;
	Fri, 23 Dec 2011 07:43:30 -0500
Date: Fri, 23 Dec 2011 08:43:30 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: "Liu, Jinsong" <jinsong.liu@intel.com>
Message-ID: <20111223124330.GB25286@andromeda.dapyr.net>
References: <DE8DF0795D48FD4CA783C40EC829233596B7@SHSMSX101.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <DE8DF0795D48FD4CA783C40EC829233596B7@SHSMSX101.ccr.corp.intel.com>
User-Agent: Mutt/1.5.9i
Cc: "Brown, Len" <len.brown@intel.com>,
	"jeremy.fitzhardinge@citrix.com" <jeremy.fitzhardinge@citrix.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>, "Jiang,
	Yunhong" <yunhong.jiang@intel.com>, "Shan, Haitao" <haitao.shan@intel.com>,
	Kernel development list <linux-kernel@vger.kernel.org>, "Zhao,
	Yakui" <yakui.zhao@intel.com>, "Luck, Tony" <tony.luck@intel.com>, "Kleen,
	Andi" <andi.kleen@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 02/10] xen/mce: Change the machine check
	point
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Dec 23, 2011 at 10:24:29AM +0000, Liu, Jinsong wrote:
> >From 80221e743d1a693670d701f383da26c8e5d5bf98 Mon Sep 17 00:00:00 2001
> From: Liu Jinsong <jinsong.liu@intel.com>
> Date: Wed, 7 Dec 2011 05:26:16 +0800
> Subject: [PATCH 02/10] xen/mce: Change the machine check point
> 
> This patch backport from Jeremy's pvops commit
> 073349667402682c997394b3fcdbbeb6707f368f

Include the git tree address please.
> 
> Enable MCE support in dom0, so that if a MCE happen and that MCE impact

impacts
> dom0, dom0 can receive a vMCE.
> 
> Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
> Signed-off-by: Ke, Liping <liping.ke@intel.com>
> Signed-off-by: Jiang, Yunhong <yunhong.jiang@intel.com>
> Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
> ---
>  arch/x86/xen/enlighten.c |    7 +++++--
>  1 files changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
> index b073e4c..13e7a16 100644
> --- a/arch/x86/xen/enlighten.c
> +++ b/arch/x86/xen/enlighten.c
> @@ -526,7 +526,7 @@ static int cvt_gate_to_trap(int vector, const gate_desc *val,
>  	 * Look for known traps using IST, and substitute them
>  	 * appropriately.  The debugger ones are the only ones we care
>  	 * about.  Xen will handle faults like double_fault and
> -	 * machine_check, so we should never see them.  Warn if
> +	 * nmi, so we should never see them.  Warn if
>  	 * there's an unexpected IST-using fault handler.
>  	 */
>  	if (addr == (unsigned long)debug)
> @@ -541,7 +541,10 @@ static int cvt_gate_to_trap(int vector, const gate_desc *val,
>  		return 0;
>  #ifdef CONFIG_X86_MCE
>  	} else if (addr == (unsigned long)machine_check) {
> -		return 0;
> +		if (xen_initial_domain())

Why can't this be done on DomU?
> +			addr = (unsigned long)machine_check;
> +		else
> +			return 0;
>  #endif
>  	} else {
>  		/* Some other trap using IST? */
> -- 
> 1.6.5.6


> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 23 12:44:51 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 Dec 2011 12: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.xensource.com>)
	id 1Re4TO-0005li-95; Fri, 23 Dec 2011 12:43:42 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1Re4TM-0005lF-QZ
	for xen-devel@lists.xensource.com; Fri, 23 Dec 2011 12:43:41 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-7.tower-216.messagelabs.com!1324644213!8576401!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10157 invoked from network); 23 Dec 2011 12:43:34 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-7.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 23 Dec 2011 12:43:34 -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
	pBNChUA7028517
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Fri, 23 Dec 2011 07:43:30 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pBNChUgN028515;
	Fri, 23 Dec 2011 07:43:30 -0500
Date: Fri, 23 Dec 2011 08:43:30 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: "Liu, Jinsong" <jinsong.liu@intel.com>
Message-ID: <20111223124330.GB25286@andromeda.dapyr.net>
References: <DE8DF0795D48FD4CA783C40EC829233596B7@SHSMSX101.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <DE8DF0795D48FD4CA783C40EC829233596B7@SHSMSX101.ccr.corp.intel.com>
User-Agent: Mutt/1.5.9i
Cc: "Brown, Len" <len.brown@intel.com>,
	"jeremy.fitzhardinge@citrix.com" <jeremy.fitzhardinge@citrix.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>, "Jiang,
	Yunhong" <yunhong.jiang@intel.com>, "Shan, Haitao" <haitao.shan@intel.com>,
	Kernel development list <linux-kernel@vger.kernel.org>, "Zhao,
	Yakui" <yakui.zhao@intel.com>, "Luck, Tony" <tony.luck@intel.com>, "Kleen,
	Andi" <andi.kleen@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 02/10] xen/mce: Change the machine check
	point
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Dec 23, 2011 at 10:24:29AM +0000, Liu, Jinsong wrote:
> >From 80221e743d1a693670d701f383da26c8e5d5bf98 Mon Sep 17 00:00:00 2001
> From: Liu Jinsong <jinsong.liu@intel.com>
> Date: Wed, 7 Dec 2011 05:26:16 +0800
> Subject: [PATCH 02/10] xen/mce: Change the machine check point
> 
> This patch backport from Jeremy's pvops commit
> 073349667402682c997394b3fcdbbeb6707f368f

Include the git tree address please.
> 
> Enable MCE support in dom0, so that if a MCE happen and that MCE impact

impacts
> dom0, dom0 can receive a vMCE.
> 
> Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
> Signed-off-by: Ke, Liping <liping.ke@intel.com>
> Signed-off-by: Jiang, Yunhong <yunhong.jiang@intel.com>
> Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
> ---
>  arch/x86/xen/enlighten.c |    7 +++++--
>  1 files changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
> index b073e4c..13e7a16 100644
> --- a/arch/x86/xen/enlighten.c
> +++ b/arch/x86/xen/enlighten.c
> @@ -526,7 +526,7 @@ static int cvt_gate_to_trap(int vector, const gate_desc *val,
>  	 * Look for known traps using IST, and substitute them
>  	 * appropriately.  The debugger ones are the only ones we care
>  	 * about.  Xen will handle faults like double_fault and
> -	 * machine_check, so we should never see them.  Warn if
> +	 * nmi, so we should never see them.  Warn if
>  	 * there's an unexpected IST-using fault handler.
>  	 */
>  	if (addr == (unsigned long)debug)
> @@ -541,7 +541,10 @@ static int cvt_gate_to_trap(int vector, const gate_desc *val,
>  		return 0;
>  #ifdef CONFIG_X86_MCE
>  	} else if (addr == (unsigned long)machine_check) {
> -		return 0;
> +		if (xen_initial_domain())

Why can't this be done on DomU?
> +			addr = (unsigned long)machine_check;
> +		else
> +			return 0;
>  #endif
>  	} else {
>  		/* Some other trap using IST? */
> -- 
> 1.6.5.6


> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 23 12:57:24 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 Dec 2011 12:57:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Re4g9-000672-KE; Fri, 23 Dec 2011 12:56:53 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1Re4g7-00066x-IH
	for xen-devel@lists.xensource.com; Fri, 23 Dec 2011 12:56:51 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1324644968!47962294!1
X-Originating-IP: [209.85.212.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28203 invoked from network); 23 Dec 2011 12:56:09 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Dec 2011 12:56:09 -0000
Received: by wico1 with SMTP id o1so8036041wic.30
	for <xen-devel@lists.xensource.com>;
	Fri, 23 Dec 2011 04:56:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=ih9VzP5vHwcep2vSlABKGf6mUQ9xsuP72NQkoXdsyGg=;
	b=T+ugVGtGL0kCU8pR1h5F8Udo4MzIK5KZvt7ZeYTYpWjs7ul6K+RCDT42gSqkSC+Ojs
	VtRU4Dw4gNJoQURnXX6T2IT4UYmSesqtXBojlgrI/8zOV6FYZKS8puKT2Wq+j6Cejh21
	QPqwArfhTEexhQqAmVFTXu31lyyjJ03IhtZUA=
Received: by 10.180.107.134 with SMTP id hc6mr29620903wib.21.1324645010330;
	Fri, 23 Dec 2011 04:56:50 -0800 (PST)
Received: from [192.168.1.70] (host81-152-17-11.range81-152.btcentralplus.com.
	[81.152.17.11])
	by mx.google.com with ESMTPS id m13sm13562789wbh.0.2011.12.23.04.56.48
	(version=SSLv3 cipher=OTHER); Fri, 23 Dec 2011 04:56:49 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Fri, 23 Dec 2011 12:56:46 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>, Jan Beulich <JBeulich@suse.com>
Message-ID: <CB1A2B0E.27C27%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH 1 of 3] KEXEC: Add new hypercall to fix
	64/32bit truncation errors. v2
Thread-Index: AczBclOaAIuBa1T6UkqPt7QfKsZCdQ==
In-Reply-To: <4EF46351.8080301@citrix.com>
Mime-version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 1 of 3] KEXEC: Add new hypercall to fix
 64/32bit truncation errors. v2
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 23/12/2011 11:17, "Andrew Cooper" <andrew.cooper3@citrix.com> wrote:

>> Just for the record - I continue to be opposed to doing this for the
>> 32-bit hypervisor. All relevant allocations are below 4G there, so
>> there's simply no need to decrease code readability for no benefit.
>> 
>> Jan
> 
> I don't mind reducing the scope to ignore the 32bit Xen case.  Any
> object Keir?

Fine by me.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 23 12:57:24 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 Dec 2011 12:57:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Re4g9-000672-KE; Fri, 23 Dec 2011 12:56:53 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1Re4g7-00066x-IH
	for xen-devel@lists.xensource.com; Fri, 23 Dec 2011 12:56:51 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1324644968!47962294!1
X-Originating-IP: [209.85.212.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28203 invoked from network); 23 Dec 2011 12:56:09 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Dec 2011 12:56:09 -0000
Received: by wico1 with SMTP id o1so8036041wic.30
	for <xen-devel@lists.xensource.com>;
	Fri, 23 Dec 2011 04:56:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=ih9VzP5vHwcep2vSlABKGf6mUQ9xsuP72NQkoXdsyGg=;
	b=T+ugVGtGL0kCU8pR1h5F8Udo4MzIK5KZvt7ZeYTYpWjs7ul6K+RCDT42gSqkSC+Ojs
	VtRU4Dw4gNJoQURnXX6T2IT4UYmSesqtXBojlgrI/8zOV6FYZKS8puKT2Wq+j6Cejh21
	QPqwArfhTEexhQqAmVFTXu31lyyjJ03IhtZUA=
Received: by 10.180.107.134 with SMTP id hc6mr29620903wib.21.1324645010330;
	Fri, 23 Dec 2011 04:56:50 -0800 (PST)
Received: from [192.168.1.70] (host81-152-17-11.range81-152.btcentralplus.com.
	[81.152.17.11])
	by mx.google.com with ESMTPS id m13sm13562789wbh.0.2011.12.23.04.56.48
	(version=SSLv3 cipher=OTHER); Fri, 23 Dec 2011 04:56:49 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Fri, 23 Dec 2011 12:56:46 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>, Jan Beulich <JBeulich@suse.com>
Message-ID: <CB1A2B0E.27C27%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH 1 of 3] KEXEC: Add new hypercall to fix
	64/32bit truncation errors. v2
Thread-Index: AczBclOaAIuBa1T6UkqPt7QfKsZCdQ==
In-Reply-To: <4EF46351.8080301@citrix.com>
Mime-version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 1 of 3] KEXEC: Add new hypercall to fix
 64/32bit truncation errors. v2
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 23/12/2011 11:17, "Andrew Cooper" <andrew.cooper3@citrix.com> wrote:

>> Just for the record - I continue to be opposed to doing this for the
>> 32-bit hypervisor. All relevant allocations are below 4G there, so
>> there's simply no need to decrease code readability for no benefit.
>> 
>> Jan
> 
> I don't mind reducing the scope to ignore the 32bit Xen case.  Any
> object Keir?

Fine by me.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 23 13:08:13 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 Dec 2011 13:08:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Re4qi-0006Lp-QV; Fri, 23 Dec 2011 13:07:48 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1Re4qh-0006Lf-Au
	for xen-devel@lists.xensource.com; Fri, 23 Dec 2011 13:07:47 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-13.tower-27.messagelabs.com!1324645635!53343245!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23344 invoked from network); 23 Dec 2011 13:07:16 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-13.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 23 Dec 2011 13:07:16 -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
	pBND7Zam031970
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Fri, 23 Dec 2011 08:07:36 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pBND7ZRF031967;
	Fri, 23 Dec 2011 08:07:35 -0500
Date: Fri, 23 Dec 2011 09:07:35 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: "Liu, Jinsong" <jinsong.liu@intel.com>
Message-ID: <20111223130735.GC25286@andromeda.dapyr.net>
References: <DE8DF0795D48FD4CA783C40EC829233596CC@SHSMSX101.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <DE8DF0795D48FD4CA783C40EC829233596CC@SHSMSX101.ccr.corp.intel.com>
User-Agent: Mutt/1.5.9i
Cc: "Brown, Len" <len.brown@intel.com>,
	"jeremy.fitzhardinge@citrix.com" <jeremy.fitzhardinge@citrix.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>, "Jiang,
	Yunhong" <yunhong.jiang@intel.com>, "Shan, Haitao" <haitao.shan@intel.com>,
	Kernel development list <linux-kernel@vger.kernel.org>, "Zhao,
	Yakui" <yakui.zhao@intel.com>, "Luck, Tony" <tony.luck@intel.com>, "Kleen,
	Andi" <andi.kleen@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 03/10] Xen: Export host physical CPU
	information to dom0
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Dec 23, 2011 at 10:25:23AM +0000, Liu, Jinsong wrote:
> >From 04151aa18b48a452cc9d0696f36aa96c690ca011 Mon Sep 17 00:00:00 2001
> From: Liu Jinsong <jinsong.liu@intel.com>
> Date: Thu, 8 Dec 2011 22:28:07 +0800
> Subject: [PATCH 03/10] Xen: Export host physical CPU information to dom0
> 
> This patch rebased from Jeremy's pvops commit
> 3b34cd19627c6e191b15fd6cb59f997b8db21e19 and
> 68320323a51c2378aca433c76157d9e66104ff1e
> 
> This patch expose host's physical CPU information to dom0 in sysfs, so
> that dom0's management tools can control the physical CPU if needed.

Please include an explanation of:
 what  is the benfit of this?
 why would anyone want to do this?

> 
> It also provides interface in sysfs to logical online/offline a physical CPU.

Then you also need Documentation/ABI/

Is there any generic API for doing this? Can that be used instead?
> 
> Notice: The information in dom0 is synced with xen hypervisor asynchronously.
> 
> Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
> Signed-off-by: Jiang, Yunhong <yunhong.jiang@intel.com>
> Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
> ---
>  drivers/xen/Makefile             |    2 +-
>  drivers/xen/pcpu.c               |  452 ++++++++++++++++++++++++++++++++++++++
>  include/xen/interface/platform.h |   28 +++
>  include/xen/interface/xen.h      |    1 +
>  include/xen/pcpu.h               |   32 +++
>  5 files changed, 514 insertions(+), 1 deletions(-)
>  create mode 100644 drivers/xen/pcpu.c
>  create mode 100644 include/xen/pcpu.h
> 
> diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
> index 405cce9..aedaf48 100644
> --- a/drivers/xen/Makefile
> +++ b/drivers/xen/Makefile
> @@ -1,4 +1,4 @@
> -obj-y	+= grant-table.o features.o events.o manage.o balloon.o
> +obj-y	+= grant-table.o features.o events.o manage.o balloon.o pcpu.o

You mentioned this is a dom0 type thing. So can this be wrapped with
CONFIG_XEN_DOM0? There is no point of running this in the guest right?

>  obj-y	+= xenbus/
>  
>  nostackp := $(call cc-option, -fno-stack-protector)
> diff --git a/drivers/xen/pcpu.c b/drivers/xen/pcpu.c
> new file mode 100644
> index 0000000..6d1a770
> --- /dev/null
> +++ b/drivers/xen/pcpu.c
> @@ -0,0 +1,452 @@
> +/*
> + * pcpu.c - management physical cpu in dom0 environment
> + */
> +#include <linux/interrupt.h>
> +#include <linux/spinlock.h>
> +#include <asm/xen/hypervisor.h>
> +#include <asm/xen/hypercall.h>
> +#include <linux/cpu.h>
> +#include <xen/xenbus.h>
> +#include <xen/pcpu.h>
> +#include <xen/events.h>
> +#include <xen/acpi.h>

You are missing
xen/xen.h

> +
> +static struct sysdev_class xen_pcpu_sysdev_class = {
> +	.name = "xen_pcpu",
> +};
> +
> +static DEFINE_MUTEX(xen_pcpu_lock);
> +static RAW_NOTIFIER_HEAD(xen_pcpu_chain);
> +
> +/* No need for irq disable since hotplug notify is in workqueue context */
> +#define get_pcpu_lock() mutex_lock(&xen_pcpu_lock);
> +#define put_pcpu_lock() mutex_unlock(&xen_pcpu_lock);
> +
> +struct xen_pcpus {
> +	struct list_head list;
> +	int present;

bool.
> +};
> +static struct xen_pcpus xen_pcpus;
> +
> +int register_xen_pcpu_notifier(struct notifier_block *nb)
> +{
> +	int ret;
> +
> +	/* All refer to the chain notifier is protected by the pcpu_lock */

Huh?
> +	get_pcpu_lock();
> +	ret = raw_notifier_chain_register(&xen_pcpu_chain, nb);
> +	put_pcpu_lock();
> +	return ret;
> +}
> +EXPORT_SYMBOL_GPL(register_xen_pcpu_notifier);
> +
> +void unregister_xen_pcpu_notifier(struct notifier_block *nb)
> +{
> +	get_pcpu_lock();
> +	raw_notifier_chain_unregister(&xen_pcpu_chain, nb);
> +	put_pcpu_lock();
> +}
> +EXPORT_SYMBOL_GPL(unregister_xen_pcpu_notifier);
> +
> +static int xen_pcpu_down(uint32_t xen_id)
> +{
> +	int ret;
> +	xen_platform_op_t op = {
> +		.cmd			= XENPF_cpu_offline,
> +		.interface_version	= XENPF_INTERFACE_VERSION,
> +		.u.cpu_ol.cpuid	= xen_id,
> +	};
> +
> +	ret = HYPERVISOR_dom0_op(&op);
> +	return ret;
> +}
> +
> +static int xen_pcpu_up(uint32_t xen_id)
> +{
> +	int ret;
> +	xen_platform_op_t op = {
> +		.cmd			= XENPF_cpu_online,
> +		.interface_version	= XENPF_INTERFACE_VERSION,
> +		.u.cpu_ol.cpuid	= xen_id,
> +	};
> +
> +	ret = HYPERVISOR_dom0_op(&op);
> +	return ret;
> +}
> +
> +static ssize_t show_online(struct sys_device *dev,
> +			struct sysdev_attribute *attr,
> +			char *buf)
> +{
> +	struct pcpu *cpu = container_of(dev, struct pcpu, sysdev);

Shouldn't you have a check like this:
 if (!capable(CAP_SYS_ADMIN))
	return -EACCESS;
> +
> +	return sprintf(buf, "%u\n", !!(cpu->flags & XEN_PCPU_FLAGS_ONLINE));
> +}
> +
> +static ssize_t __ref store_online(struct sys_device *dev,
> +				  struct sysdev_attribute *attr,
> +				  const char *buf, size_t count)
> +{
> +	struct pcpu *cpu = container_of(dev, struct pcpu, sysdev);
> +	ssize_t ret;
> +
Um, shouldn't you have a check

 if (!capable(CAP_SYS_ADMIN))
	return -EACCESS;
?
> +	switch (buf[0]) {
> +	case '0':
> +		ret = xen_pcpu_down(cpu->xen_id);
> +		break;
> +	case '1':
> +		ret = xen_pcpu_up(cpu->xen_id);
> +		break;
> +	default:
> +		ret = -EINVAL;
> +	}
> +
> +	if (ret >= 0)
> +		ret = count;
> +	return ret;
> +}
> +
> +static SYSDEV_ATTR(online, 0644, show_online, store_online);
> +
> +static ssize_t show_apicid(struct sys_device *dev,
> +			struct sysdev_attribute *attr,
> +			char *buf)
> +{
> +	struct pcpu *cpu = container_of(dev, struct pcpu, sysdev);
> +

The same priv check.
> +	return sprintf(buf, "%u\n", cpu->apic_id);
> +}
> +
> +static ssize_t show_acpiid(struct sys_device *dev,
> +			struct sysdev_attribute *attr,
> +			char *buf)
> +{
> +	struct pcpu *cpu = container_of(dev, struct pcpu, sysdev);
> +

And here.. But I am wondering. What is the purpose of the ACPI_ID
fields? Why do you want to expose them?

> +	return sprintf(buf, "%u\n", cpu->acpi_id);
> +}
> +static SYSDEV_ATTR(apic_id, 0444, show_apicid, NULL);
> +static SYSDEV_ATTR(acpi_id, 0444, show_acpiid, NULL);
> +
> +static int xen_pcpu_free(struct pcpu *pcpu)
> +{
> +	if (!pcpu)
> +		return 0;
> +
> +	sysdev_remove_file(&pcpu->sysdev, &attr_online);
> +	sysdev_unregister(&pcpu->sysdev);
> +	list_del(&pcpu->pcpu_list);
> +	kfree(pcpu);
> +
> +	return 0;
> +}
> +
> +static inline int same_pcpu(struct xenpf_pcpuinfo *info,
> +			    struct pcpu *pcpu)
> +{
> +	return (pcpu->apic_id == info->apic_id) &&
> +		(pcpu->xen_id == info->xen_cpuid);
> +}
> +
> +/*
> + * Return 1 if online status changed
> + */
> +static int xen_pcpu_online_check(struct xenpf_pcpuinfo *info,

Make it a bool please.
> +				 struct pcpu *pcpu)
> +{
> +	int result = 0;
> +
> +	if (info->xen_cpuid != pcpu->xen_id)
> +		return 0;
> +
> +	if (xen_pcpu_online(info->flags) && !xen_pcpu_online(pcpu->flags)) {
> +		/* the pcpu is onlined */
> +		pcpu->flags |= XEN_PCPU_FLAGS_ONLINE;
> +		kobject_uevent(&pcpu->sysdev.kobj, KOBJ_ONLINE);
> +		raw_notifier_call_chain(&xen_pcpu_chain,
> +			XEN_PCPU_ONLINE, (void *)(long)pcpu->xen_id);
> +		result = 1;
> +	} else if (!xen_pcpu_online(info->flags) &&
> +		 xen_pcpu_online(pcpu->flags))  {
> +		/* The pcpu is offlined now */
> +		pcpu->flags &= ~XEN_PCPU_FLAGS_ONLINE;
> +		kobject_uevent(&pcpu->sysdev.kobj, KOBJ_OFFLINE);
> +		raw_notifier_call_chain(&xen_pcpu_chain,
> +			XEN_PCPU_OFFLINE, (void *)(long)pcpu->xen_id);
> +		result = 1;
> +	}
> +
> +	return result;
> +}
> +
> +static int pcpu_sysdev_init(struct pcpu *cpu)
> +{
> +	int error;
> +
> +	error = sysdev_register(&cpu->sysdev);
> +	if (error) {
> +		printk(KERN_WARNING "xen_pcpu_add: Failed to register pcpu\n");
> +		kfree(cpu);
> +		return -1;

Why not return error?
> +	}
> +	sysdev_create_file(&cpu->sysdev, &attr_online);
> +	sysdev_create_file(&cpu->sysdev, &attr_apic_id);
> +	sysdev_create_file(&cpu->sysdev, &attr_acpi_id);
> +	return 0;
> +}
> +
> +static struct pcpu *get_pcpu(int xen_id)
> +{
> +	struct pcpu *pcpu = NULL;
> +
> +	list_for_each_entry(pcpu, &xen_pcpus.list, pcpu_list) {
> +		if (pcpu->xen_id == xen_id)
> +			return pcpu;
> +	}
> +	return NULL;
> +}
> +
> +static struct pcpu *init_pcpu(struct xenpf_pcpuinfo *info)
> +{
> +	struct pcpu *pcpu;
> +
> +	if (info->flags & XEN_PCPU_FLAGS_INVALID)
> +		return NULL;
> +
> +	/* The PCPU is just added */

Huh? Can you explain this a bit please?

> +	pcpu = kzalloc(sizeof(struct pcpu), GFP_KERNEL);
> +	if (!pcpu)
> +		return NULL;

Why not use ERR_PTR?
> +
> +	INIT_LIST_HEAD(&pcpu->pcpu_list);
> +	pcpu->xen_id = info->xen_cpuid;
> +	pcpu->apic_id = info->apic_id;
> +	pcpu->acpi_id = info->acpi_id;
> +	pcpu->flags = info->flags;
> +
> +	pcpu->sysdev.cls = &xen_pcpu_sysdev_class;
> +	pcpu->sysdev.id = info->xen_cpuid;
> +
> +	if (pcpu_sysdev_init(pcpu)) {
> +		kfree(pcpu);
> +		return NULL;

Why not use ERR_PTR?
> +	}
> +
> +	list_add_tail(&pcpu->pcpu_list, &xen_pcpus.list);
> +	raw_notifier_call_chain(&xen_pcpu_chain,
> +				XEN_PCPU_ADD,
> +				(void *)(long)pcpu->xen_id);
> +	return pcpu;
> +}
> +
> +#define PCPU_NO_CHANGE			0
> +#define PCPU_ADDED			1
> +#define PCPU_ONLINE_OFFLINE		2
> +#define PCPU_REMOVED			3

The space alignemtn looks odd.
> +/*
> + * Caller should hold the pcpu lock
> + * < 0: Something wrong
> + * 0: No changes
> + * > 0: State changed
> + */
> +static struct pcpu *_sync_pcpu(int cpu_num, int *max_id, int *result)
> +{
> +	struct pcpu *pcpu = NULL;
> +	struct xenpf_pcpuinfo *info;
> +	xen_platform_op_t op = {
> +		.cmd            = XENPF_get_cpuinfo,
> +		.interface_version  = XENPF_INTERFACE_VERSION,
> +	};
> +	int ret;
> +

Please check whether result it usable:
	if (result) ...
> +	*result = -1;
> +
> +	info = &op.u.pcpu_info;
> +	info->xen_cpuid = cpu_num;
> +
> +	ret = HYPERVISOR_dom0_op(&op);
> +	if (ret)
> +		return NULL;
> +
> +	if (max_id)
> +		*max_id = op.u.pcpu_info.max_present;
> +
> +	pcpu = get_pcpu(cpu_num);
> +
> +	if (info->flags & XEN_PCPU_FLAGS_INVALID) {
> +		/* The pcpu has been removed */
> +		*result = PCPU_NO_CHANGE;
> +		if (pcpu) {
> +			raw_notifier_call_chain(&xen_pcpu_chain,
> +			  XEN_PCPU_REMOVE,
> +			  (void *)(long)pcpu->xen_id);
> +			xen_pcpu_free(pcpu);
> +			*result = PCPU_REMOVED;
> +		}
> +		return NULL;
> +	}
> +
> +
> +	if (!pcpu) {
> +		*result = PCPU_ADDED;
> +		pcpu = init_pcpu(info);
> +		if (pcpu == NULL) {
> +			printk(KERN_WARNING "Failed to init pcpu %x\n",
> +			  info->xen_cpuid);
> +			  *result = -1;

Please use a #define for -1.

> +		}
> +	} else {
> +		*result = PCPU_NO_CHANGE;
> +		/*
> +		 * Old PCPU is replaced with a new pcpu, this means
> +		 * several virq is missed, will it happen?

s/is/are

"will it happen?" ?? What does that mean? Are in, does it ever happen?
Well sure, if somebody overwrote the event channel mask or such.

> +		 */
> +		if (!same_pcpu(info, pcpu)) {
> +			printk(KERN_WARNING "Pcpu %x changed!\n",
> +			  pcpu->xen_id);
> +			pcpu->apic_id = info->apic_id;
> +			pcpu->acpi_id = info->acpi_id;
> +		}
> +		if (xen_pcpu_online_check(info, pcpu))
> +			*result = PCPU_ONLINE_OFFLINE;
> +	}
> +	return pcpu;
> +}
> +
> +int xen_pcpu_index(uint32_t id, int is_acpiid)
> +{
> +	int cpu_num = 0, max_id = 0, ret;
> +	xen_platform_op_t op = {
> +		.cmd            = XENPF_get_cpuinfo,
> +		.interface_version  = XENPF_INTERFACE_VERSION,
> +	};
> +	struct xenpf_pcpuinfo *info = &op.u.pcpu_info;
> +
> +	info->xen_cpuid = 0;
> +	ret = HYPERVISOR_dom0_op(&op);
> +	if (ret)
> +		return -1;

Can you put a comment explainig why are returning -1?

> +	max_id = op.u.pcpu_info.max_present;
> +

So max_id is not ACPI ID? Right, so why don't you use a different
variable name. Like 'max_cpu_nr'

> +	while ((cpu_num <= max_id)) {
> +		info->xen_cpuid = cpu_num;
> +		ret = HYPERVISOR_dom0_op(&op);
> +		if (ret)
> +			continue;
> +
> +		if (op.u.pcpu_info.max_present > max_id)
> +			max_id = op.u.pcpu_info.max_present;
> +		if (id == (is_acpiid ? info->acpi_id : info->apic_id))
> +			return cpu_num;

Huh? Are you mingling ACPI_ID with logical CPU count number? That is not
correct as the ACPI_ID can be higher than the logical CPUs number.

> +		cpu_num++;
> +	}
> +
> +    return -1;

Why -1?
> +}
> +EXPORT_SYMBOL(xen_pcpu_index);

_GPL
> +
> +/*
> + * Sync dom0's pcpu information with xen hypervisor's
> + */
> +static int xen_sync_pcpus(void)
> +{
> +	/*
> +	 * Boot cpu always have cpu_id 0 in xen
> +	 */
> +	int cpu_num = 0, max_id = 0, result = 0, present = 0;
> +	struct list_head *elem, *tmp;
> +	struct pcpu *pcpu;
> +
> +	get_pcpu_lock();
> +
> +	while ((result >= 0) && (cpu_num <= max_id)) {
> +		pcpu = _sync_pcpu(cpu_num, &max_id, &result);
> +
> +		printk(KERN_DEBUG "sync cpu %x get result %x max_id %x\n",
> +			cpu_num, result, max_id);
> +
> +		switch (result)	{
> +		case PCPU_NO_CHANGE:
> +			if (pcpu)
> +				present++;
> +			break;
> +		case PCPU_ADDED:
> +		case PCPU_ONLINE_OFFLINE:
> +			present++;
> +		case PCPU_REMOVED:
> +			break;
> +		default:
> +			printk(KERN_WARNING "Failed to sync pcpu %x\n",
> +			  cpu_num);
> +			break;
> +
> +		}
> +		cpu_num++;
> +	}
> +
> +	if (result < 0) {
> +		list_for_each_safe(elem, tmp, &xen_pcpus.list) {
> +			pcpu = list_entry(elem, struct pcpu, pcpu_list);
> +			xen_pcpu_free(pcpu);
> +		}
> +		present = 0;
> +	}
> +
> +	xen_pcpus.present = present;
> +
> +	put_pcpu_lock();
> +
> +	return 0;
> +}
> +
> +static void xen_pcpu_dpc(struct work_struct *work)
> +{
> +	if (xen_sync_pcpus() < 0)
> +		printk(KERN_WARNING
> +			"xen_pcpu_dpc: Failed to sync pcpu information\n");
> +}
> +static DECLARE_WORK(xen_pcpu_work, xen_pcpu_dpc);
> +
> +int xen_pcpu_hotplug(int type, uint32_t apic_id)
> +{
> +	schedule_work(&xen_pcpu_work);
> +
> +	return 0;
> +}
> +EXPORT_SYMBOL(xen_pcpu_hotplug);

_GPL

> +
> +static irqreturn_t xen_pcpu_interrupt(int irq, void *dev_id)
> +{
> +	schedule_work(&xen_pcpu_work);
> +	return IRQ_HANDLED;
> +}
> +
> +static int __init xen_pcpu_init(void)
> +{
> +	int err;
> +
> +	if (!xen_initial_domain())
> +		return 0;

-ENODEV

> +
> +	err = sysdev_class_register(&xen_pcpu_sysdev_class);
> +	if (err) {
> +		printk(KERN_WARNING
> +			"xen_pcpu_init: register xen_pcpu sysdev Failed!\n");
> +		return err;
> +	}
> +
> +	INIT_LIST_HEAD(&xen_pcpus.list);
> +	xen_pcpus.present = 0;
> +
> +	xen_sync_pcpus();
> +	if (xen_pcpus.present > 0)
> +		err = bind_virq_to_irqhandler(VIRQ_PCPU_STATE,
> +			0, xen_pcpu_interrupt, 0, "pcpu", NULL);
> +	if (err < 0)
> +		printk(KERN_WARNING "xen_pcpu_init: "
> +			"Failed to bind pcpu_state virq\n"
> +			"You will lost latest information! \n");
> +	return err;
> +}
> +
> +arch_initcall(xen_pcpu_init);
> diff --git a/include/xen/interface/platform.h b/include/xen/interface/platform.h
> index c168468..47ffe16 100644
> --- a/include/xen/interface/platform.h
> +++ b/include/xen/interface/platform.h
> @@ -297,6 +297,31 @@ struct xenpf_set_processor_pminfo {
>  };
>  DEFINE_GUEST_HANDLE_STRUCT(xenpf_set_processor_pminfo);
>  
> +#define XENPF_get_cpuinfo 55
> +struct xenpf_pcpuinfo {
> +	/* IN */
> +	uint32_t xen_cpuid;
> +	/* OUT */
> +	/* The maxium cpu_id that is present */
> +	uint32_t max_present;
> +#define XEN_PCPU_FLAGS_ONLINE   1
> +	/* Correponding xen_cpuid is not present*/
> +#define XEN_PCPU_FLAGS_INVALID  2
> +	uint32_t flags;
> +	uint32_t apic_id;
> +	uint32_t acpi_id;
> +};
> +typedef struct xenpf_pcpuinfo xenpf_pcpuinfo_t;
> +DEFINE_GUEST_HANDLE_STRUCT(xenpf_pcpuinfo_t);
> +
> +#define XENPF_cpu_online    56
> +#define XENPF_cpu_offline   57
> +struct xenpf_cpu_ol {
> +    uint32_t cpuid;
> +};
> +typedef struct xenpf_cpu_ol xenpf_cpu_ol_t;
> +DEFINE_GUEST_HANDLE_STRUCT(xenpf_cpu_ol_t);
> +
>  struct xen_platform_op {
>  	uint32_t cmd;
>  	uint32_t interface_version; /* XENPF_INTERFACE_VERSION */
> @@ -312,9 +337,12 @@ struct xen_platform_op {
>  		struct xenpf_change_freq       change_freq;
>  		struct xenpf_getidletime       getidletime;
>  		struct xenpf_set_processor_pminfo set_pminfo;
> +		struct xenpf_pcpuinfo          pcpu_info;
> +		struct xenpf_cpu_ol            cpu_ol;
>  		uint8_t                        pad[128];
>  	} u;
>  };
> +typedef struct xen_platform_op xen_platform_op_t;
>  DEFINE_GUEST_HANDLE_STRUCT(xen_platform_op_t);
>  
>  #endif /* __XEN_PUBLIC_PLATFORM_H__ */
> diff --git a/include/xen/interface/xen.h b/include/xen/interface/xen.h
> index 6a6e914..5a91c66 100644
> --- a/include/xen/interface/xen.h
> +++ b/include/xen/interface/xen.h
> @@ -80,6 +80,7 @@
>  #define VIRQ_CONSOLE    2  /* (DOM0) Bytes received on emergency console. */
>  #define VIRQ_DOM_EXC    3  /* (DOM0) Exceptional event for some domain.   */
>  #define VIRQ_DEBUGGER   6  /* (DOM0) A domain has paused for debugging.   */
> +#define VIRQ_PCPU_STATE 9  /* (DOM0) PCPU state changed                   */
>  
>  /* Architecture-specific VIRQ definitions. */
>  #define VIRQ_ARCH_0    16
> diff --git a/include/xen/pcpu.h b/include/xen/pcpu.h
> new file mode 100644
> index 0000000..7e8f9d1
> --- /dev/null
> +++ b/include/xen/pcpu.h
> @@ -0,0 +1,32 @@
> +#ifndef _XEN_PCPU_H
> +#define _XEN_PCPU_H
> +
> +#include <xen/interface/platform.h>
> +#include <linux/sysdev.h>
> +
> +extern int xen_pcpu_hotplug(int type, uint32_t apic_id);

is this neccessary?
> +#define XEN_PCPU_ONLINE     0x01
> +#define XEN_PCPU_OFFLINE    0x02
> +#define XEN_PCPU_ADD        0x04
> +#define XEN_PCPU_REMOVE     0x08
> +
> +struct pcpu {
> +	struct list_head pcpu_list;
> +	struct sys_device sysdev;
> +	uint32_t xen_id;
> +	uint32_t apic_id;
> +	uint32_t acpi_id;
> +	uint32_t flags;
> +};
> +
> +static inline int xen_pcpu_online(uint32_t flags)
> +{
> +	return !!(flags & XEN_PCPU_FLAGS_ONLINE);
> +}
> +
> +extern int register_xen_pcpu_notifier(struct notifier_block *nb);
> +
> +extern void unregister_xen_pcpu_notifier(struct notifier_block *nb);
> +
> +extern int xen_pcpu_index(uint32_t acpi_id, int is_acpiid);
> +#endif
> -- 
> 1.6.5.6


> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 23 13:08:13 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 Dec 2011 13:08:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Re4qi-0006Lp-QV; Fri, 23 Dec 2011 13:07:48 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1Re4qh-0006Lf-Au
	for xen-devel@lists.xensource.com; Fri, 23 Dec 2011 13:07:47 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-13.tower-27.messagelabs.com!1324645635!53343245!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23344 invoked from network); 23 Dec 2011 13:07:16 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-13.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 23 Dec 2011 13:07:16 -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
	pBND7Zam031970
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Fri, 23 Dec 2011 08:07:36 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pBND7ZRF031967;
	Fri, 23 Dec 2011 08:07:35 -0500
Date: Fri, 23 Dec 2011 09:07:35 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: "Liu, Jinsong" <jinsong.liu@intel.com>
Message-ID: <20111223130735.GC25286@andromeda.dapyr.net>
References: <DE8DF0795D48FD4CA783C40EC829233596CC@SHSMSX101.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <DE8DF0795D48FD4CA783C40EC829233596CC@SHSMSX101.ccr.corp.intel.com>
User-Agent: Mutt/1.5.9i
Cc: "Brown, Len" <len.brown@intel.com>,
	"jeremy.fitzhardinge@citrix.com" <jeremy.fitzhardinge@citrix.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>, "Jiang,
	Yunhong" <yunhong.jiang@intel.com>, "Shan, Haitao" <haitao.shan@intel.com>,
	Kernel development list <linux-kernel@vger.kernel.org>, "Zhao,
	Yakui" <yakui.zhao@intel.com>, "Luck, Tony" <tony.luck@intel.com>, "Kleen,
	Andi" <andi.kleen@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 03/10] Xen: Export host physical CPU
	information to dom0
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Dec 23, 2011 at 10:25:23AM +0000, Liu, Jinsong wrote:
> >From 04151aa18b48a452cc9d0696f36aa96c690ca011 Mon Sep 17 00:00:00 2001
> From: Liu Jinsong <jinsong.liu@intel.com>
> Date: Thu, 8 Dec 2011 22:28:07 +0800
> Subject: [PATCH 03/10] Xen: Export host physical CPU information to dom0
> 
> This patch rebased from Jeremy's pvops commit
> 3b34cd19627c6e191b15fd6cb59f997b8db21e19 and
> 68320323a51c2378aca433c76157d9e66104ff1e
> 
> This patch expose host's physical CPU information to dom0 in sysfs, so
> that dom0's management tools can control the physical CPU if needed.

Please include an explanation of:
 what  is the benfit of this?
 why would anyone want to do this?

> 
> It also provides interface in sysfs to logical online/offline a physical CPU.

Then you also need Documentation/ABI/

Is there any generic API for doing this? Can that be used instead?
> 
> Notice: The information in dom0 is synced with xen hypervisor asynchronously.
> 
> Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
> Signed-off-by: Jiang, Yunhong <yunhong.jiang@intel.com>
> Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
> ---
>  drivers/xen/Makefile             |    2 +-
>  drivers/xen/pcpu.c               |  452 ++++++++++++++++++++++++++++++++++++++
>  include/xen/interface/platform.h |   28 +++
>  include/xen/interface/xen.h      |    1 +
>  include/xen/pcpu.h               |   32 +++
>  5 files changed, 514 insertions(+), 1 deletions(-)
>  create mode 100644 drivers/xen/pcpu.c
>  create mode 100644 include/xen/pcpu.h
> 
> diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
> index 405cce9..aedaf48 100644
> --- a/drivers/xen/Makefile
> +++ b/drivers/xen/Makefile
> @@ -1,4 +1,4 @@
> -obj-y	+= grant-table.o features.o events.o manage.o balloon.o
> +obj-y	+= grant-table.o features.o events.o manage.o balloon.o pcpu.o

You mentioned this is a dom0 type thing. So can this be wrapped with
CONFIG_XEN_DOM0? There is no point of running this in the guest right?

>  obj-y	+= xenbus/
>  
>  nostackp := $(call cc-option, -fno-stack-protector)
> diff --git a/drivers/xen/pcpu.c b/drivers/xen/pcpu.c
> new file mode 100644
> index 0000000..6d1a770
> --- /dev/null
> +++ b/drivers/xen/pcpu.c
> @@ -0,0 +1,452 @@
> +/*
> + * pcpu.c - management physical cpu in dom0 environment
> + */
> +#include <linux/interrupt.h>
> +#include <linux/spinlock.h>
> +#include <asm/xen/hypervisor.h>
> +#include <asm/xen/hypercall.h>
> +#include <linux/cpu.h>
> +#include <xen/xenbus.h>
> +#include <xen/pcpu.h>
> +#include <xen/events.h>
> +#include <xen/acpi.h>

You are missing
xen/xen.h

> +
> +static struct sysdev_class xen_pcpu_sysdev_class = {
> +	.name = "xen_pcpu",
> +};
> +
> +static DEFINE_MUTEX(xen_pcpu_lock);
> +static RAW_NOTIFIER_HEAD(xen_pcpu_chain);
> +
> +/* No need for irq disable since hotplug notify is in workqueue context */
> +#define get_pcpu_lock() mutex_lock(&xen_pcpu_lock);
> +#define put_pcpu_lock() mutex_unlock(&xen_pcpu_lock);
> +
> +struct xen_pcpus {
> +	struct list_head list;
> +	int present;

bool.
> +};
> +static struct xen_pcpus xen_pcpus;
> +
> +int register_xen_pcpu_notifier(struct notifier_block *nb)
> +{
> +	int ret;
> +
> +	/* All refer to the chain notifier is protected by the pcpu_lock */

Huh?
> +	get_pcpu_lock();
> +	ret = raw_notifier_chain_register(&xen_pcpu_chain, nb);
> +	put_pcpu_lock();
> +	return ret;
> +}
> +EXPORT_SYMBOL_GPL(register_xen_pcpu_notifier);
> +
> +void unregister_xen_pcpu_notifier(struct notifier_block *nb)
> +{
> +	get_pcpu_lock();
> +	raw_notifier_chain_unregister(&xen_pcpu_chain, nb);
> +	put_pcpu_lock();
> +}
> +EXPORT_SYMBOL_GPL(unregister_xen_pcpu_notifier);
> +
> +static int xen_pcpu_down(uint32_t xen_id)
> +{
> +	int ret;
> +	xen_platform_op_t op = {
> +		.cmd			= XENPF_cpu_offline,
> +		.interface_version	= XENPF_INTERFACE_VERSION,
> +		.u.cpu_ol.cpuid	= xen_id,
> +	};
> +
> +	ret = HYPERVISOR_dom0_op(&op);
> +	return ret;
> +}
> +
> +static int xen_pcpu_up(uint32_t xen_id)
> +{
> +	int ret;
> +	xen_platform_op_t op = {
> +		.cmd			= XENPF_cpu_online,
> +		.interface_version	= XENPF_INTERFACE_VERSION,
> +		.u.cpu_ol.cpuid	= xen_id,
> +	};
> +
> +	ret = HYPERVISOR_dom0_op(&op);
> +	return ret;
> +}
> +
> +static ssize_t show_online(struct sys_device *dev,
> +			struct sysdev_attribute *attr,
> +			char *buf)
> +{
> +	struct pcpu *cpu = container_of(dev, struct pcpu, sysdev);

Shouldn't you have a check like this:
 if (!capable(CAP_SYS_ADMIN))
	return -EACCESS;
> +
> +	return sprintf(buf, "%u\n", !!(cpu->flags & XEN_PCPU_FLAGS_ONLINE));
> +}
> +
> +static ssize_t __ref store_online(struct sys_device *dev,
> +				  struct sysdev_attribute *attr,
> +				  const char *buf, size_t count)
> +{
> +	struct pcpu *cpu = container_of(dev, struct pcpu, sysdev);
> +	ssize_t ret;
> +
Um, shouldn't you have a check

 if (!capable(CAP_SYS_ADMIN))
	return -EACCESS;
?
> +	switch (buf[0]) {
> +	case '0':
> +		ret = xen_pcpu_down(cpu->xen_id);
> +		break;
> +	case '1':
> +		ret = xen_pcpu_up(cpu->xen_id);
> +		break;
> +	default:
> +		ret = -EINVAL;
> +	}
> +
> +	if (ret >= 0)
> +		ret = count;
> +	return ret;
> +}
> +
> +static SYSDEV_ATTR(online, 0644, show_online, store_online);
> +
> +static ssize_t show_apicid(struct sys_device *dev,
> +			struct sysdev_attribute *attr,
> +			char *buf)
> +{
> +	struct pcpu *cpu = container_of(dev, struct pcpu, sysdev);
> +

The same priv check.
> +	return sprintf(buf, "%u\n", cpu->apic_id);
> +}
> +
> +static ssize_t show_acpiid(struct sys_device *dev,
> +			struct sysdev_attribute *attr,
> +			char *buf)
> +{
> +	struct pcpu *cpu = container_of(dev, struct pcpu, sysdev);
> +

And here.. But I am wondering. What is the purpose of the ACPI_ID
fields? Why do you want to expose them?

> +	return sprintf(buf, "%u\n", cpu->acpi_id);
> +}
> +static SYSDEV_ATTR(apic_id, 0444, show_apicid, NULL);
> +static SYSDEV_ATTR(acpi_id, 0444, show_acpiid, NULL);
> +
> +static int xen_pcpu_free(struct pcpu *pcpu)
> +{
> +	if (!pcpu)
> +		return 0;
> +
> +	sysdev_remove_file(&pcpu->sysdev, &attr_online);
> +	sysdev_unregister(&pcpu->sysdev);
> +	list_del(&pcpu->pcpu_list);
> +	kfree(pcpu);
> +
> +	return 0;
> +}
> +
> +static inline int same_pcpu(struct xenpf_pcpuinfo *info,
> +			    struct pcpu *pcpu)
> +{
> +	return (pcpu->apic_id == info->apic_id) &&
> +		(pcpu->xen_id == info->xen_cpuid);
> +}
> +
> +/*
> + * Return 1 if online status changed
> + */
> +static int xen_pcpu_online_check(struct xenpf_pcpuinfo *info,

Make it a bool please.
> +				 struct pcpu *pcpu)
> +{
> +	int result = 0;
> +
> +	if (info->xen_cpuid != pcpu->xen_id)
> +		return 0;
> +
> +	if (xen_pcpu_online(info->flags) && !xen_pcpu_online(pcpu->flags)) {
> +		/* the pcpu is onlined */
> +		pcpu->flags |= XEN_PCPU_FLAGS_ONLINE;
> +		kobject_uevent(&pcpu->sysdev.kobj, KOBJ_ONLINE);
> +		raw_notifier_call_chain(&xen_pcpu_chain,
> +			XEN_PCPU_ONLINE, (void *)(long)pcpu->xen_id);
> +		result = 1;
> +	} else if (!xen_pcpu_online(info->flags) &&
> +		 xen_pcpu_online(pcpu->flags))  {
> +		/* The pcpu is offlined now */
> +		pcpu->flags &= ~XEN_PCPU_FLAGS_ONLINE;
> +		kobject_uevent(&pcpu->sysdev.kobj, KOBJ_OFFLINE);
> +		raw_notifier_call_chain(&xen_pcpu_chain,
> +			XEN_PCPU_OFFLINE, (void *)(long)pcpu->xen_id);
> +		result = 1;
> +	}
> +
> +	return result;
> +}
> +
> +static int pcpu_sysdev_init(struct pcpu *cpu)
> +{
> +	int error;
> +
> +	error = sysdev_register(&cpu->sysdev);
> +	if (error) {
> +		printk(KERN_WARNING "xen_pcpu_add: Failed to register pcpu\n");
> +		kfree(cpu);
> +		return -1;

Why not return error?
> +	}
> +	sysdev_create_file(&cpu->sysdev, &attr_online);
> +	sysdev_create_file(&cpu->sysdev, &attr_apic_id);
> +	sysdev_create_file(&cpu->sysdev, &attr_acpi_id);
> +	return 0;
> +}
> +
> +static struct pcpu *get_pcpu(int xen_id)
> +{
> +	struct pcpu *pcpu = NULL;
> +
> +	list_for_each_entry(pcpu, &xen_pcpus.list, pcpu_list) {
> +		if (pcpu->xen_id == xen_id)
> +			return pcpu;
> +	}
> +	return NULL;
> +}
> +
> +static struct pcpu *init_pcpu(struct xenpf_pcpuinfo *info)
> +{
> +	struct pcpu *pcpu;
> +
> +	if (info->flags & XEN_PCPU_FLAGS_INVALID)
> +		return NULL;
> +
> +	/* The PCPU is just added */

Huh? Can you explain this a bit please?

> +	pcpu = kzalloc(sizeof(struct pcpu), GFP_KERNEL);
> +	if (!pcpu)
> +		return NULL;

Why not use ERR_PTR?
> +
> +	INIT_LIST_HEAD(&pcpu->pcpu_list);
> +	pcpu->xen_id = info->xen_cpuid;
> +	pcpu->apic_id = info->apic_id;
> +	pcpu->acpi_id = info->acpi_id;
> +	pcpu->flags = info->flags;
> +
> +	pcpu->sysdev.cls = &xen_pcpu_sysdev_class;
> +	pcpu->sysdev.id = info->xen_cpuid;
> +
> +	if (pcpu_sysdev_init(pcpu)) {
> +		kfree(pcpu);
> +		return NULL;

Why not use ERR_PTR?
> +	}
> +
> +	list_add_tail(&pcpu->pcpu_list, &xen_pcpus.list);
> +	raw_notifier_call_chain(&xen_pcpu_chain,
> +				XEN_PCPU_ADD,
> +				(void *)(long)pcpu->xen_id);
> +	return pcpu;
> +}
> +
> +#define PCPU_NO_CHANGE			0
> +#define PCPU_ADDED			1
> +#define PCPU_ONLINE_OFFLINE		2
> +#define PCPU_REMOVED			3

The space alignemtn looks odd.
> +/*
> + * Caller should hold the pcpu lock
> + * < 0: Something wrong
> + * 0: No changes
> + * > 0: State changed
> + */
> +static struct pcpu *_sync_pcpu(int cpu_num, int *max_id, int *result)
> +{
> +	struct pcpu *pcpu = NULL;
> +	struct xenpf_pcpuinfo *info;
> +	xen_platform_op_t op = {
> +		.cmd            = XENPF_get_cpuinfo,
> +		.interface_version  = XENPF_INTERFACE_VERSION,
> +	};
> +	int ret;
> +

Please check whether result it usable:
	if (result) ...
> +	*result = -1;
> +
> +	info = &op.u.pcpu_info;
> +	info->xen_cpuid = cpu_num;
> +
> +	ret = HYPERVISOR_dom0_op(&op);
> +	if (ret)
> +		return NULL;
> +
> +	if (max_id)
> +		*max_id = op.u.pcpu_info.max_present;
> +
> +	pcpu = get_pcpu(cpu_num);
> +
> +	if (info->flags & XEN_PCPU_FLAGS_INVALID) {
> +		/* The pcpu has been removed */
> +		*result = PCPU_NO_CHANGE;
> +		if (pcpu) {
> +			raw_notifier_call_chain(&xen_pcpu_chain,
> +			  XEN_PCPU_REMOVE,
> +			  (void *)(long)pcpu->xen_id);
> +			xen_pcpu_free(pcpu);
> +			*result = PCPU_REMOVED;
> +		}
> +		return NULL;
> +	}
> +
> +
> +	if (!pcpu) {
> +		*result = PCPU_ADDED;
> +		pcpu = init_pcpu(info);
> +		if (pcpu == NULL) {
> +			printk(KERN_WARNING "Failed to init pcpu %x\n",
> +			  info->xen_cpuid);
> +			  *result = -1;

Please use a #define for -1.

> +		}
> +	} else {
> +		*result = PCPU_NO_CHANGE;
> +		/*
> +		 * Old PCPU is replaced with a new pcpu, this means
> +		 * several virq is missed, will it happen?

s/is/are

"will it happen?" ?? What does that mean? Are in, does it ever happen?
Well sure, if somebody overwrote the event channel mask or such.

> +		 */
> +		if (!same_pcpu(info, pcpu)) {
> +			printk(KERN_WARNING "Pcpu %x changed!\n",
> +			  pcpu->xen_id);
> +			pcpu->apic_id = info->apic_id;
> +			pcpu->acpi_id = info->acpi_id;
> +		}
> +		if (xen_pcpu_online_check(info, pcpu))
> +			*result = PCPU_ONLINE_OFFLINE;
> +	}
> +	return pcpu;
> +}
> +
> +int xen_pcpu_index(uint32_t id, int is_acpiid)
> +{
> +	int cpu_num = 0, max_id = 0, ret;
> +	xen_platform_op_t op = {
> +		.cmd            = XENPF_get_cpuinfo,
> +		.interface_version  = XENPF_INTERFACE_VERSION,
> +	};
> +	struct xenpf_pcpuinfo *info = &op.u.pcpu_info;
> +
> +	info->xen_cpuid = 0;
> +	ret = HYPERVISOR_dom0_op(&op);
> +	if (ret)
> +		return -1;

Can you put a comment explainig why are returning -1?

> +	max_id = op.u.pcpu_info.max_present;
> +

So max_id is not ACPI ID? Right, so why don't you use a different
variable name. Like 'max_cpu_nr'

> +	while ((cpu_num <= max_id)) {
> +		info->xen_cpuid = cpu_num;
> +		ret = HYPERVISOR_dom0_op(&op);
> +		if (ret)
> +			continue;
> +
> +		if (op.u.pcpu_info.max_present > max_id)
> +			max_id = op.u.pcpu_info.max_present;
> +		if (id == (is_acpiid ? info->acpi_id : info->apic_id))
> +			return cpu_num;

Huh? Are you mingling ACPI_ID with logical CPU count number? That is not
correct as the ACPI_ID can be higher than the logical CPUs number.

> +		cpu_num++;
> +	}
> +
> +    return -1;

Why -1?
> +}
> +EXPORT_SYMBOL(xen_pcpu_index);

_GPL
> +
> +/*
> + * Sync dom0's pcpu information with xen hypervisor's
> + */
> +static int xen_sync_pcpus(void)
> +{
> +	/*
> +	 * Boot cpu always have cpu_id 0 in xen
> +	 */
> +	int cpu_num = 0, max_id = 0, result = 0, present = 0;
> +	struct list_head *elem, *tmp;
> +	struct pcpu *pcpu;
> +
> +	get_pcpu_lock();
> +
> +	while ((result >= 0) && (cpu_num <= max_id)) {
> +		pcpu = _sync_pcpu(cpu_num, &max_id, &result);
> +
> +		printk(KERN_DEBUG "sync cpu %x get result %x max_id %x\n",
> +			cpu_num, result, max_id);
> +
> +		switch (result)	{
> +		case PCPU_NO_CHANGE:
> +			if (pcpu)
> +				present++;
> +			break;
> +		case PCPU_ADDED:
> +		case PCPU_ONLINE_OFFLINE:
> +			present++;
> +		case PCPU_REMOVED:
> +			break;
> +		default:
> +			printk(KERN_WARNING "Failed to sync pcpu %x\n",
> +			  cpu_num);
> +			break;
> +
> +		}
> +		cpu_num++;
> +	}
> +
> +	if (result < 0) {
> +		list_for_each_safe(elem, tmp, &xen_pcpus.list) {
> +			pcpu = list_entry(elem, struct pcpu, pcpu_list);
> +			xen_pcpu_free(pcpu);
> +		}
> +		present = 0;
> +	}
> +
> +	xen_pcpus.present = present;
> +
> +	put_pcpu_lock();
> +
> +	return 0;
> +}
> +
> +static void xen_pcpu_dpc(struct work_struct *work)
> +{
> +	if (xen_sync_pcpus() < 0)
> +		printk(KERN_WARNING
> +			"xen_pcpu_dpc: Failed to sync pcpu information\n");
> +}
> +static DECLARE_WORK(xen_pcpu_work, xen_pcpu_dpc);
> +
> +int xen_pcpu_hotplug(int type, uint32_t apic_id)
> +{
> +	schedule_work(&xen_pcpu_work);
> +
> +	return 0;
> +}
> +EXPORT_SYMBOL(xen_pcpu_hotplug);

_GPL

> +
> +static irqreturn_t xen_pcpu_interrupt(int irq, void *dev_id)
> +{
> +	schedule_work(&xen_pcpu_work);
> +	return IRQ_HANDLED;
> +}
> +
> +static int __init xen_pcpu_init(void)
> +{
> +	int err;
> +
> +	if (!xen_initial_domain())
> +		return 0;

-ENODEV

> +
> +	err = sysdev_class_register(&xen_pcpu_sysdev_class);
> +	if (err) {
> +		printk(KERN_WARNING
> +			"xen_pcpu_init: register xen_pcpu sysdev Failed!\n");
> +		return err;
> +	}
> +
> +	INIT_LIST_HEAD(&xen_pcpus.list);
> +	xen_pcpus.present = 0;
> +
> +	xen_sync_pcpus();
> +	if (xen_pcpus.present > 0)
> +		err = bind_virq_to_irqhandler(VIRQ_PCPU_STATE,
> +			0, xen_pcpu_interrupt, 0, "pcpu", NULL);
> +	if (err < 0)
> +		printk(KERN_WARNING "xen_pcpu_init: "
> +			"Failed to bind pcpu_state virq\n"
> +			"You will lost latest information! \n");
> +	return err;
> +}
> +
> +arch_initcall(xen_pcpu_init);
> diff --git a/include/xen/interface/platform.h b/include/xen/interface/platform.h
> index c168468..47ffe16 100644
> --- a/include/xen/interface/platform.h
> +++ b/include/xen/interface/platform.h
> @@ -297,6 +297,31 @@ struct xenpf_set_processor_pminfo {
>  };
>  DEFINE_GUEST_HANDLE_STRUCT(xenpf_set_processor_pminfo);
>  
> +#define XENPF_get_cpuinfo 55
> +struct xenpf_pcpuinfo {
> +	/* IN */
> +	uint32_t xen_cpuid;
> +	/* OUT */
> +	/* The maxium cpu_id that is present */
> +	uint32_t max_present;
> +#define XEN_PCPU_FLAGS_ONLINE   1
> +	/* Correponding xen_cpuid is not present*/
> +#define XEN_PCPU_FLAGS_INVALID  2
> +	uint32_t flags;
> +	uint32_t apic_id;
> +	uint32_t acpi_id;
> +};
> +typedef struct xenpf_pcpuinfo xenpf_pcpuinfo_t;
> +DEFINE_GUEST_HANDLE_STRUCT(xenpf_pcpuinfo_t);
> +
> +#define XENPF_cpu_online    56
> +#define XENPF_cpu_offline   57
> +struct xenpf_cpu_ol {
> +    uint32_t cpuid;
> +};
> +typedef struct xenpf_cpu_ol xenpf_cpu_ol_t;
> +DEFINE_GUEST_HANDLE_STRUCT(xenpf_cpu_ol_t);
> +
>  struct xen_platform_op {
>  	uint32_t cmd;
>  	uint32_t interface_version; /* XENPF_INTERFACE_VERSION */
> @@ -312,9 +337,12 @@ struct xen_platform_op {
>  		struct xenpf_change_freq       change_freq;
>  		struct xenpf_getidletime       getidletime;
>  		struct xenpf_set_processor_pminfo set_pminfo;
> +		struct xenpf_pcpuinfo          pcpu_info;
> +		struct xenpf_cpu_ol            cpu_ol;
>  		uint8_t                        pad[128];
>  	} u;
>  };
> +typedef struct xen_platform_op xen_platform_op_t;
>  DEFINE_GUEST_HANDLE_STRUCT(xen_platform_op_t);
>  
>  #endif /* __XEN_PUBLIC_PLATFORM_H__ */
> diff --git a/include/xen/interface/xen.h b/include/xen/interface/xen.h
> index 6a6e914..5a91c66 100644
> --- a/include/xen/interface/xen.h
> +++ b/include/xen/interface/xen.h
> @@ -80,6 +80,7 @@
>  #define VIRQ_CONSOLE    2  /* (DOM0) Bytes received on emergency console. */
>  #define VIRQ_DOM_EXC    3  /* (DOM0) Exceptional event for some domain.   */
>  #define VIRQ_DEBUGGER   6  /* (DOM0) A domain has paused for debugging.   */
> +#define VIRQ_PCPU_STATE 9  /* (DOM0) PCPU state changed                   */
>  
>  /* Architecture-specific VIRQ definitions. */
>  #define VIRQ_ARCH_0    16
> diff --git a/include/xen/pcpu.h b/include/xen/pcpu.h
> new file mode 100644
> index 0000000..7e8f9d1
> --- /dev/null
> +++ b/include/xen/pcpu.h
> @@ -0,0 +1,32 @@
> +#ifndef _XEN_PCPU_H
> +#define _XEN_PCPU_H
> +
> +#include <xen/interface/platform.h>
> +#include <linux/sysdev.h>
> +
> +extern int xen_pcpu_hotplug(int type, uint32_t apic_id);

is this neccessary?
> +#define XEN_PCPU_ONLINE     0x01
> +#define XEN_PCPU_OFFLINE    0x02
> +#define XEN_PCPU_ADD        0x04
> +#define XEN_PCPU_REMOVE     0x08
> +
> +struct pcpu {
> +	struct list_head pcpu_list;
> +	struct sys_device sysdev;
> +	uint32_t xen_id;
> +	uint32_t apic_id;
> +	uint32_t acpi_id;
> +	uint32_t flags;
> +};
> +
> +static inline int xen_pcpu_online(uint32_t flags)
> +{
> +	return !!(flags & XEN_PCPU_FLAGS_ONLINE);
> +}
> +
> +extern int register_xen_pcpu_notifier(struct notifier_block *nb);
> +
> +extern void unregister_xen_pcpu_notifier(struct notifier_block *nb);
> +
> +extern int xen_pcpu_index(uint32_t acpi_id, int is_acpiid);
> +#endif
> -- 
> 1.6.5.6


> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 23 13:17:35 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 Dec 2011 13:17:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Re4zp-0006Xe-T9; Fri, 23 Dec 2011 13:17:13 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1Re4zo-0006XW-5J
	for xen-devel@lists.xensource.com; Fri, 23 Dec 2011 13:17:12 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-9.tower-174.messagelabs.com!1324646224!6702653!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21719 invoked from network); 23 Dec 2011 13:17:05 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-9.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 23 Dec 2011 13:17:05 -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
	pBNDH1R8032400
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Fri, 23 Dec 2011 08:17:01 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pBNDH1x4032398;
	Fri, 23 Dec 2011 08:17:01 -0500
Date: Fri, 23 Dec 2011 09:17:01 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: "Liu, Jinsong" <jinsong.liu@intel.com>
Message-ID: <20111223131701.GD25286@andromeda.dapyr.net>
References: <DE8DF0795D48FD4CA783C40EC829233596F0@SHSMSX101.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <DE8DF0795D48FD4CA783C40EC829233596F0@SHSMSX101.ccr.corp.intel.com>
User-Agent: Mutt/1.5.9i
Cc: "Brown, Len" <len.brown@intel.com>,
	"jeremy.fitzhardinge@citrix.com" <jeremy.fitzhardinge@citrix.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>, "Jiang,
	Yunhong" <yunhong.jiang@intel.com>, "Shan, Haitao" <haitao.shan@intel.com>,
	Kernel development list <linux-kernel@vger.kernel.org>, "Zhao,
	Yakui" <yakui.zhao@intel.com>, "Luck, Tony" <tony.luck@intel.com>, "Kleen,
	Andi" <andi.kleen@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 05/10] xen/acpi: Move acpi_memory_info
	definition to public
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Dec 23, 2011 at 10:27:19AM +0000, Liu, Jinsong wrote:
> >From 0172b1ce6a2ba70e739f968622d78ac1796813f9 Mon Sep 17 00:00:00 2001
> From: Liu Jinsong <jinsong.liu@intel.com>
> Date: Sun, 11 Dec 2011 17:25:35 +0800
> Subject: [PATCH 05/10] xen/acpi: Move acpi_memory_info definition to public

Take out the 'xen'. this patch touches the generic code, not the Xen
code.
> 
> This patch rebased from Jeremy's pvops commit
> 359e747e6260f105f750657917e1dc75f6427602

Not sure what relevance that has actually..
> 
> Move this definition to header file so that it can be used by dom0
> memory hotadd logic also.

And include the name of the patch that uses this so when somebody is
using 'gitk' or 'git gui blame' they can at least search for the patch
that leverages this.

> 
> Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
> Signed-off-by: Jiang, Yunhong <yunhong.jiang@intel.com>
> Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
> ---
>  drivers/acpi/acpi_memhotplug.c |   15 ---------------
>  include/acpi/acpi_drivers.h    |   21 +++++++++++++++++++++
>  2 files changed, 21 insertions(+), 15 deletions(-)
> 
> diff --git a/drivers/acpi/acpi_memhotplug.c b/drivers/acpi/acpi_memhotplug.c
> index d985713..e28e64d 100644
> --- a/drivers/acpi/acpi_memhotplug.c
> +++ b/drivers/acpi/acpi_memhotplug.c
> @@ -71,21 +71,6 @@ static struct acpi_driver acpi_memory_device_driver = {
>  		},
>  };
>  
> -struct acpi_memory_info {
> -	struct list_head list;
> -	u64 start_addr;		/* Memory Range start physical addr */
> -	u64 length;		/* Memory Range length */
> -	unsigned short caching;	/* memory cache attribute */
> -	unsigned short write_protect;	/* memory read/write attribute */
> -	unsigned int enabled:1;
> -};
> -
> -struct acpi_memory_device {
> -	struct acpi_device * device;
> -	unsigned int state;	/* State of the memory device */
> -	struct list_head res_list;
> -};
> -
>  static int acpi_hotmem_initialized;
>  
>  static acpi_status
> diff --git a/include/acpi/acpi_drivers.h b/include/acpi/acpi_drivers.h
> index e49c36d..833de75 100644
> --- a/include/acpi/acpi_drivers.h
> +++ b/include/acpi/acpi_drivers.h
> @@ -154,4 +154,25 @@ static inline void unregister_hotplug_dock_device(acpi_handle handle)
>  }
>  #endif
>  
> +/*--------------------------------------------------------------------------
> +                                Memory
> +  -------------------------------------------------------------------------- */
> +#if defined(CONFIG_ACPI_HOTPLUG_MEMORY) || \
> +        defined(CONFIG_ACPI_HOTPLUG_MEMORY_MODULE)
> +struct acpi_memory_info {
> +        struct list_head list;
> +        u64 start_addr;         /* Memory Range start physical addr */
> +        u64 length;             /* Memory Range length */
> +        unsigned short caching; /* memory cache attribute */
> +        unsigned short write_protect;   /* memory read/write attribute */
> +        unsigned int enabled:1;
> +};
> +
> +struct acpi_memory_device {
> +        struct acpi_device *device;
> +        unsigned int state;     /* State of the memory device */
> +        struct list_head res_list;
> +};
> +#endif
> +
>  #endif /*__ACPI_DRIVERS_H__*/
> -- 
> 1.6.5.6


> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 23 13:17:35 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 Dec 2011 13:17:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Re4zp-0006Xe-T9; Fri, 23 Dec 2011 13:17:13 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1Re4zo-0006XW-5J
	for xen-devel@lists.xensource.com; Fri, 23 Dec 2011 13:17:12 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-9.tower-174.messagelabs.com!1324646224!6702653!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21719 invoked from network); 23 Dec 2011 13:17:05 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-9.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 23 Dec 2011 13:17:05 -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
	pBNDH1R8032400
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Fri, 23 Dec 2011 08:17:01 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pBNDH1x4032398;
	Fri, 23 Dec 2011 08:17:01 -0500
Date: Fri, 23 Dec 2011 09:17:01 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: "Liu, Jinsong" <jinsong.liu@intel.com>
Message-ID: <20111223131701.GD25286@andromeda.dapyr.net>
References: <DE8DF0795D48FD4CA783C40EC829233596F0@SHSMSX101.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <DE8DF0795D48FD4CA783C40EC829233596F0@SHSMSX101.ccr.corp.intel.com>
User-Agent: Mutt/1.5.9i
Cc: "Brown, Len" <len.brown@intel.com>,
	"jeremy.fitzhardinge@citrix.com" <jeremy.fitzhardinge@citrix.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>, "Jiang,
	Yunhong" <yunhong.jiang@intel.com>, "Shan, Haitao" <haitao.shan@intel.com>,
	Kernel development list <linux-kernel@vger.kernel.org>, "Zhao,
	Yakui" <yakui.zhao@intel.com>, "Luck, Tony" <tony.luck@intel.com>, "Kleen,
	Andi" <andi.kleen@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 05/10] xen/acpi: Move acpi_memory_info
	definition to public
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Dec 23, 2011 at 10:27:19AM +0000, Liu, Jinsong wrote:
> >From 0172b1ce6a2ba70e739f968622d78ac1796813f9 Mon Sep 17 00:00:00 2001
> From: Liu Jinsong <jinsong.liu@intel.com>
> Date: Sun, 11 Dec 2011 17:25:35 +0800
> Subject: [PATCH 05/10] xen/acpi: Move acpi_memory_info definition to public

Take out the 'xen'. this patch touches the generic code, not the Xen
code.
> 
> This patch rebased from Jeremy's pvops commit
> 359e747e6260f105f750657917e1dc75f6427602

Not sure what relevance that has actually..
> 
> Move this definition to header file so that it can be used by dom0
> memory hotadd logic also.

And include the name of the patch that uses this so when somebody is
using 'gitk' or 'git gui blame' they can at least search for the patch
that leverages this.

> 
> Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
> Signed-off-by: Jiang, Yunhong <yunhong.jiang@intel.com>
> Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
> ---
>  drivers/acpi/acpi_memhotplug.c |   15 ---------------
>  include/acpi/acpi_drivers.h    |   21 +++++++++++++++++++++
>  2 files changed, 21 insertions(+), 15 deletions(-)
> 
> diff --git a/drivers/acpi/acpi_memhotplug.c b/drivers/acpi/acpi_memhotplug.c
> index d985713..e28e64d 100644
> --- a/drivers/acpi/acpi_memhotplug.c
> +++ b/drivers/acpi/acpi_memhotplug.c
> @@ -71,21 +71,6 @@ static struct acpi_driver acpi_memory_device_driver = {
>  		},
>  };
>  
> -struct acpi_memory_info {
> -	struct list_head list;
> -	u64 start_addr;		/* Memory Range start physical addr */
> -	u64 length;		/* Memory Range length */
> -	unsigned short caching;	/* memory cache attribute */
> -	unsigned short write_protect;	/* memory read/write attribute */
> -	unsigned int enabled:1;
> -};
> -
> -struct acpi_memory_device {
> -	struct acpi_device * device;
> -	unsigned int state;	/* State of the memory device */
> -	struct list_head res_list;
> -};
> -
>  static int acpi_hotmem_initialized;
>  
>  static acpi_status
> diff --git a/include/acpi/acpi_drivers.h b/include/acpi/acpi_drivers.h
> index e49c36d..833de75 100644
> --- a/include/acpi/acpi_drivers.h
> +++ b/include/acpi/acpi_drivers.h
> @@ -154,4 +154,25 @@ static inline void unregister_hotplug_dock_device(acpi_handle handle)
>  }
>  #endif
>  
> +/*--------------------------------------------------------------------------
> +                                Memory
> +  -------------------------------------------------------------------------- */
> +#if defined(CONFIG_ACPI_HOTPLUG_MEMORY) || \
> +        defined(CONFIG_ACPI_HOTPLUG_MEMORY_MODULE)
> +struct acpi_memory_info {
> +        struct list_head list;
> +        u64 start_addr;         /* Memory Range start physical addr */
> +        u64 length;             /* Memory Range length */
> +        unsigned short caching; /* memory cache attribute */
> +        unsigned short write_protect;   /* memory read/write attribute */
> +        unsigned int enabled:1;
> +};
> +
> +struct acpi_memory_device {
> +        struct acpi_device *device;
> +        unsigned int state;     /* State of the memory device */
> +        struct list_head res_list;
> +};
> +#endif
> +
>  #endif /*__ACPI_DRIVERS_H__*/
> -- 
> 1.6.5.6


> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 23 13:22:37 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 Dec 2011 13:22:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Re54g-0006i9-RW; Fri, 23 Dec 2011 13:22:14 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1Re54g-0006hx-2H
	for xen-devel@lists.xensource.com; Fri, 23 Dec 2011 13:22:14 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-4.tower-216.messagelabs.com!1324646525!8560365!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26960 invoked from network); 23 Dec 2011 13:22:07 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-4.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 23 Dec 2011 13:22:07 -0000
Received: from andromeda.dapyr.net (darnok@localhost [127.0.0.1])
	by andromeda.dapyr.net (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id
	pBNDM02W032649
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Fri, 23 Dec 2011 08:22:00 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pBNDM0MA032647;
	Fri, 23 Dec 2011 08:22:00 -0500
Date: Fri, 23 Dec 2011 09:22:00 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: "Liu, Jinsong" <jinsong.liu@intel.com>
Message-ID: <20111223132200.GE25286@andromeda.dapyr.net>
References: <DE8DF0795D48FD4CA783C40EC82923359700@SHSMSX101.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <DE8DF0795D48FD4CA783C40EC82923359700@SHSMSX101.ccr.corp.intel.com>
User-Agent: Mutt/1.5.9i
Cc: "Brown, Len" <len.brown@intel.com>,
	"jeremy.fitzhardinge@citrix.com" <jeremy.fitzhardinge@citrix.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>, "Jiang,
	Yunhong" <yunhong.jiang@intel.com>, "Shan, Haitao" <haitao.shan@intel.com>,
	Kernel development list <linux-kernel@vger.kernel.org>, "Zhao,
	Yakui" <yakui.zhao@intel.com>, "Luck, Tony" <tony.luck@intel.com>, "Kleen,
	Andi" <andi.kleen@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 06/10] Xen: Add memory hotadd to pvops dom0
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Dec 23, 2011 at 10:28:21AM +0000, Liu, Jinsong wrote:
> >From a5d21e2a01049eef6aa64406e71f6574e7a371c1 Mon Sep 17 00:00:00 2001
> From: Liu Jinsong <jinsong.liu@intel.com>
> Date: Sun, 11 Dec 2011 21:51:28 +0800
> Subject: [PATCH 06/10] Xen: Add memory hotadd to pvops dom0
> 
> This patch rebased from Jeremy's pvops commit
> fe3cb1ebf78399fd5176ff6aa1c9ab498f2d8bd7
> 
> When memory hotadd event happen, a Xen hook will be called, to notify
> hypervisor of the new added memory.
> 
> Because xen hypervisor will use the new memory to setup frametable/m2p
> table, so dom0 will always return success to acpi bios, and notify xen
> hypervisor later.
> 
> It add a hook in driver/acpi/acpi_memhotplug.c, but that change is
> quite small, not sure if it is acceptable. Other method is to provide
> a xen specific acpi_memory_device_driver, but I'm not sure if it worth
> to add so much changes, to simply avoid two hooks.

Have you looked at the balloon hotplug memory code? Daniel Kiper did a
bunch of work in this area to make the balloon code use the generic
hotplug mechanism to expand the memory. Can you leverage some of his
work for this functionality?? (search using 'git log --grep=Daniel'
to find his work).

Can you also provide details of what kind of hardware has this and how
one would test it? Would this work for example with the IBM x3850?

> 
> Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
> Signed-off-by: Jiang, Yunhong <yunhong.jiang@intel.com>
> Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
> ---
>  drivers/acpi/acpi_memhotplug.c    |    4 +
>  drivers/xen/Makefile              |    1 +
>  drivers/xen/xen_acpi_memhotplug.c |  209 +++++++++++++++++++++++++++++++++++++
>  include/xen/acpi.h                |    5 +
>  include/xen/interface/platform.h  |    9 ++
>  5 files changed, 228 insertions(+), 0 deletions(-)
>  create mode 100644 drivers/xen/xen_acpi_memhotplug.c
> 
> diff --git a/drivers/acpi/acpi_memhotplug.c b/drivers/acpi/acpi_memhotplug.c
> index e28e64d..2f2169e 100644
> --- a/drivers/acpi/acpi_memhotplug.c
> +++ b/drivers/acpi/acpi_memhotplug.c
> @@ -32,6 +32,7 @@
>  #include <linux/memory_hotplug.h>
>  #include <linux/slab.h>
>  #include <acpi/acpi_drivers.h>
> +#include <xen/acpi.h>
>  
>  #define ACPI_MEMORY_DEVICE_CLASS		"memory"
>  #define ACPI_MEMORY_DEVICE_HID			"PNP0C80"
> @@ -214,6 +215,9 @@ static int acpi_memory_enable_device(struct acpi_memory_device *mem_device)
>  		return result;
>  	}
>  
> +	if (xen_initial_domain())
> +		return xen_hotadd_memory(mem_device);
> +
>  	node = acpi_get_node(mem_device->device->handle);
>  	/*
>  	 * Tell the VM there is more memory here...
> diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
> index aedaf48..7dc3c0b 100644
> --- a/drivers/xen/Makefile
> +++ b/drivers/xen/Makefile
> @@ -20,6 +20,7 @@ obj-$(CONFIG_XEN_TMEM)			+= tmem.o
>  obj-$(CONFIG_SWIOTLB_XEN)		+= swiotlb-xen.o
>  obj-$(CONFIG_XEN_DOM0)			+= pci.o acpi.o
>  obj-$(CONFIG_XEN_PCIDEV_BACKEND)	+= xen-pciback/
> +obj-$(CONFIG_ACPI_HOTPLUG_MEMORY)	+= xen_acpi_memhotplug.o
>  ifdef CONFIG_ACPI_PROCESSOR_XEN
>  obj-$(CONFIG_ACPI_PROCESSOR)		+= acpi_processor.o
>  endif
> diff --git a/drivers/xen/xen_acpi_memhotplug.c b/drivers/xen/xen_acpi_memhotplug.c
> new file mode 100644
> index 0000000..0c4af99
> --- /dev/null
> +++ b/drivers/xen/xen_acpi_memhotplug.c
> @@ -0,0 +1,209 @@
> +/*
> + *  xen_acpi_memhotplug.c - interface to notify Xen on memory device hotadd
> + *
> + *  Copyright (C) 2008, Intel corporation
> + *
> + * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> + *
> + *  This program is free software; you can redistribute it and/or modify
> + *  it under the terms of the GNU General Public License as published by
> + *  the Free Software Foundation; either version 2 of the License, or (at
> + *  your option) any later version.
> + *
> + *  This program is distributed in the hope that it will be useful, but
> + *  WITHOUT ANY WARRANTY; without even the implied warranty of
> + *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> + *  General Public License for more details.
> + *
> + *  You should have received a copy of the GNU General Public License along
> + *  with this program; if not, write to the Free Software Foundation, Inc.,
> + *  59 Temple Place, Suite 330, Boston, MA 02111-1307 USA.

Get rid of that please. The address can change.

Hm, going to stop looking at the patch here - will wait until you take a
look at Daniel's work and see if you can use some of it.
> + *
> + */
> +
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/init.h>
> +#include <linux/types.h>
> +#include <linux/memory_hotplug.h>
> +#include <acpi/acpi_drivers.h>
> +#include <xen/interface/platform.h>
> +#include <linux/interrupt.h>
> +#include <linux/spinlock.h>
> +#include <asm/xen/hypervisor.h>
> +#include <asm/xen/hypercall.h>
> +#include <xen/acpi.h>
> +
> +struct xen_hotmem_entry {
> +	struct list_head hotmem_list;
> +	uint64_t start;
> +	uint64_t end;
> +	uint32_t flags;
> +	uint32_t pxm;
> +};
> +
> +struct xen_hotmem_list {
> +	struct list_head list;
> +	int entry_nr;
> +} xen_hotmem;
> +
> +DEFINE_SPINLOCK(xen_hotmem_lock);
> +
> +static int xen_hyper_addmem(struct xen_hotmem_entry *entry)
> +{
> +	int ret;
> +
> +	xen_platform_op_t op = {
> +		.cmd            = XENPF_mem_hotadd,
> +		.interface_version  = XENPF_INTERFACE_VERSION,
> +	};
> +	op.u.mem_add.spfn = entry->start >> PAGE_SHIFT;
> +	op.u.mem_add.epfn = entry->end >> PAGE_SHIFT;
> +	op.u.mem_add.flags = entry->flags;
> +	op.u.mem_add.pxm = entry->pxm;
> +
> +	ret = HYPERVISOR_dom0_op(&op);
> +	return ret;
> +}
> +
> +static int add_hotmem_entry(int pxm, uint64_t start,
> +			uint64_t length, uint32_t flags)
> +{
> +	struct xen_hotmem_entry *entry;
> +
> +	if (pxm < 0 || !length)
> +		return -EINVAL;
> +
> +	entry = kzalloc(sizeof(struct xen_hotmem_entry), GFP_ATOMIC);
> +	if (!entry)
> +		return -ENOMEM;
> +
> +	INIT_LIST_HEAD(&entry->hotmem_list);
> +	entry->start = start;
> +	entry->end = start + length;
> +	entry->flags = flags;
> +	entry->pxm = pxm;
> +
> +	spin_lock(&xen_hotmem_lock);
> +
> +	list_add_tail(&entry->hotmem_list, &xen_hotmem.list);
> +	xen_hotmem.entry_nr++;
> +
> +	spin_unlock(&xen_hotmem_lock);
> +
> +	return 0;
> +}
> +
> +static int free_hotmem_entry(struct xen_hotmem_entry *entry)
> +{
> +	list_del(&entry->hotmem_list);
> +	kfree(entry);
> +
> +	return 0;
> +}
> +
> +static void xen_hotadd_mem_dpc(struct work_struct *work)
> +{
> +	struct list_head *elem, *tmp;
> +	struct xen_hotmem_entry *entry;
> +	unsigned long flags;
> +	int ret;
> +
> +	spin_lock_irqsave(&xen_hotmem_lock, flags);
> +	list_for_each_safe(elem, tmp, &xen_hotmem.list) {
> +		entry = list_entry(elem, struct xen_hotmem_entry, hotmem_list);
> +		ret = xen_hyper_addmem(entry);
> +		if (ret)
> +			printk(KERN_WARNING "xen addmem failed with %x\n", ret);
> +		free_hotmem_entry(entry);
> +		xen_hotmem.entry_nr--;
> +	}
> +	spin_unlock_irqrestore(&xen_hotmem_lock, flags);
> +}
> +
> +static DECLARE_WORK(xen_hotadd_mem_work, xen_hotadd_mem_dpc);
> +
> +static int xen_acpi_get_pxm(acpi_handle h)
> +{
> +	unsigned long long pxm;
> +	acpi_status status;
> +	acpi_handle handle;
> +	acpi_handle phandle = h;
> +
> +	do {
> +		handle = phandle;
> +		status = acpi_evaluate_integer(handle, "_PXM", NULL, &pxm);
> +		if (ACPI_SUCCESS(status))
> +			return pxm;
> +		status = acpi_get_parent(handle, &phandle);
> +	} while (ACPI_SUCCESS(status));
> +
> +	return -1;
> +}
> +
> +int xen_hotadd_memory(struct acpi_memory_device *mem_device)
> +{
> +	int pxm, result;
> +	int num_enabled = 0;
> +	struct acpi_memory_info *info;
> +
> +	if (!mem_device)
> +		return -EINVAL;
> +
> +	pxm = xen_acpi_get_pxm(mem_device->device->handle);
> +
> +	if (pxm < 0)
> +		return -EINVAL;
> +
> +	/*
> +	 * Always return success to ACPI driver, and notify hypervisor later
> +	 * because hypervisor will utilize the memory in memory hotadd hypercall
> +	 */
> +	list_for_each_entry(info, &mem_device->res_list, list) {
> +		if (info->enabled) { /* just sanity check...*/
> +			num_enabled++;
> +			continue;
> +		}
> +		/*
> +		 * If the memory block size is zero, please ignore it.
> +		 * Don't try to do the following memory hotplug flowchart.
> +		 */
> +		if (!info->length)
> +			continue;
> +
> +		result = add_hotmem_entry(pxm, info->start_addr,
> +					info->length, 0);
> +		if (result)
> +			continue;
> +		info->enabled = 1;
> +		num_enabled++;
> +	}
> +
> +	if (!num_enabled)
> +		return -EINVAL;
> +
> +	schedule_work(&xen_hotadd_mem_work);
> +
> +	return 0;
> +}
> +EXPORT_SYMBOL(xen_hotadd_memory);
> +
> +static int xen_hotadd_mem_init(void)
> +{
> +	if (!xen_initial_domain())
> +		return -ENODEV;
> +
> +	INIT_LIST_HEAD(&xen_hotmem.list);
> +	xen_hotmem.entry_nr = 0;
> +
> +	return 0;
> +}
> +
> +static void xen_hotadd_mem_exit(void)
> +{
> +	flush_scheduled_work();
> +}
> +
> +module_init(xen_hotadd_mem_init);
> +module_exit(xen_hotadd_mem_exit);
> +MODULE_LICENSE("GPL");
> diff --git a/include/xen/acpi.h b/include/xen/acpi.h
> index 7aa282d..8b3462e 100644
> --- a/include/xen/acpi.h
> +++ b/include/xen/acpi.h
> @@ -107,6 +107,11 @@ static inline int xen_acpi_processor_get_performance(struct acpi_processor *pr)
>  }
>  #endif
>  
> +#if defined(CONFIG_ACPI_HOTPLUG_MEMORY) || \
> +defined(CONFIG_ACPI_HOTPLUG_MEMORY_MODULE)
> +int xen_hotadd_memory(struct acpi_memory_device *mem_device);
> +#endif
> +
>  #if defined(CONFIG_ACPI_PROCESSOR_XEN) || \
>  defined(CONFIG_ACPI_PROCESSOR_XEN_MODULE)
>  
> diff --git a/include/xen/interface/platform.h b/include/xen/interface/platform.h
> index 9fd6b07..0787c68 100644
> --- a/include/xen/interface/platform.h
> +++ b/include/xen/interface/platform.h
> @@ -329,6 +329,14 @@ struct xenpf_cpu_hotadd {
>  	uint32_t pxm;
>  };
>  
> +#define XENPF_mem_hotadd    59
> +struct xenpf_mem_hotadd {
> +	uint64_t spfn;
> +	uint64_t epfn;
> +	uint32_t pxm;
> +	uint32_t flags;
> +};
> +
>  struct xen_platform_op {
>  	uint32_t cmd;
>  	uint32_t interface_version; /* XENPF_INTERFACE_VERSION */
> @@ -347,6 +355,7 @@ struct xen_platform_op {
>  		struct xenpf_pcpuinfo          pcpu_info;
>  		struct xenpf_cpu_ol            cpu_ol;
>  		struct xenpf_cpu_hotadd        cpu_add;
> +		struct xenpf_mem_hotadd        mem_add;
>  		uint8_t                        pad[128];
>  	} u;
>  };
> -- 
> 1.6.5.6


> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 23 13:22:37 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 Dec 2011 13:22:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Re54g-0006i9-RW; Fri, 23 Dec 2011 13:22:14 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1Re54g-0006hx-2H
	for xen-devel@lists.xensource.com; Fri, 23 Dec 2011 13:22:14 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-4.tower-216.messagelabs.com!1324646525!8560365!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26960 invoked from network); 23 Dec 2011 13:22:07 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-4.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 23 Dec 2011 13:22:07 -0000
Received: from andromeda.dapyr.net (darnok@localhost [127.0.0.1])
	by andromeda.dapyr.net (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id
	pBNDM02W032649
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Fri, 23 Dec 2011 08:22:00 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pBNDM0MA032647;
	Fri, 23 Dec 2011 08:22:00 -0500
Date: Fri, 23 Dec 2011 09:22:00 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: "Liu, Jinsong" <jinsong.liu@intel.com>
Message-ID: <20111223132200.GE25286@andromeda.dapyr.net>
References: <DE8DF0795D48FD4CA783C40EC82923359700@SHSMSX101.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <DE8DF0795D48FD4CA783C40EC82923359700@SHSMSX101.ccr.corp.intel.com>
User-Agent: Mutt/1.5.9i
Cc: "Brown, Len" <len.brown@intel.com>,
	"jeremy.fitzhardinge@citrix.com" <jeremy.fitzhardinge@citrix.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>, "Jiang,
	Yunhong" <yunhong.jiang@intel.com>, "Shan, Haitao" <haitao.shan@intel.com>,
	Kernel development list <linux-kernel@vger.kernel.org>, "Zhao,
	Yakui" <yakui.zhao@intel.com>, "Luck, Tony" <tony.luck@intel.com>, "Kleen,
	Andi" <andi.kleen@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 06/10] Xen: Add memory hotadd to pvops dom0
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Dec 23, 2011 at 10:28:21AM +0000, Liu, Jinsong wrote:
> >From a5d21e2a01049eef6aa64406e71f6574e7a371c1 Mon Sep 17 00:00:00 2001
> From: Liu Jinsong <jinsong.liu@intel.com>
> Date: Sun, 11 Dec 2011 21:51:28 +0800
> Subject: [PATCH 06/10] Xen: Add memory hotadd to pvops dom0
> 
> This patch rebased from Jeremy's pvops commit
> fe3cb1ebf78399fd5176ff6aa1c9ab498f2d8bd7
> 
> When memory hotadd event happen, a Xen hook will be called, to notify
> hypervisor of the new added memory.
> 
> Because xen hypervisor will use the new memory to setup frametable/m2p
> table, so dom0 will always return success to acpi bios, and notify xen
> hypervisor later.
> 
> It add a hook in driver/acpi/acpi_memhotplug.c, but that change is
> quite small, not sure if it is acceptable. Other method is to provide
> a xen specific acpi_memory_device_driver, but I'm not sure if it worth
> to add so much changes, to simply avoid two hooks.

Have you looked at the balloon hotplug memory code? Daniel Kiper did a
bunch of work in this area to make the balloon code use the generic
hotplug mechanism to expand the memory. Can you leverage some of his
work for this functionality?? (search using 'git log --grep=Daniel'
to find his work).

Can you also provide details of what kind of hardware has this and how
one would test it? Would this work for example with the IBM x3850?

> 
> Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
> Signed-off-by: Jiang, Yunhong <yunhong.jiang@intel.com>
> Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
> ---
>  drivers/acpi/acpi_memhotplug.c    |    4 +
>  drivers/xen/Makefile              |    1 +
>  drivers/xen/xen_acpi_memhotplug.c |  209 +++++++++++++++++++++++++++++++++++++
>  include/xen/acpi.h                |    5 +
>  include/xen/interface/platform.h  |    9 ++
>  5 files changed, 228 insertions(+), 0 deletions(-)
>  create mode 100644 drivers/xen/xen_acpi_memhotplug.c
> 
> diff --git a/drivers/acpi/acpi_memhotplug.c b/drivers/acpi/acpi_memhotplug.c
> index e28e64d..2f2169e 100644
> --- a/drivers/acpi/acpi_memhotplug.c
> +++ b/drivers/acpi/acpi_memhotplug.c
> @@ -32,6 +32,7 @@
>  #include <linux/memory_hotplug.h>
>  #include <linux/slab.h>
>  #include <acpi/acpi_drivers.h>
> +#include <xen/acpi.h>
>  
>  #define ACPI_MEMORY_DEVICE_CLASS		"memory"
>  #define ACPI_MEMORY_DEVICE_HID			"PNP0C80"
> @@ -214,6 +215,9 @@ static int acpi_memory_enable_device(struct acpi_memory_device *mem_device)
>  		return result;
>  	}
>  
> +	if (xen_initial_domain())
> +		return xen_hotadd_memory(mem_device);
> +
>  	node = acpi_get_node(mem_device->device->handle);
>  	/*
>  	 * Tell the VM there is more memory here...
> diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
> index aedaf48..7dc3c0b 100644
> --- a/drivers/xen/Makefile
> +++ b/drivers/xen/Makefile
> @@ -20,6 +20,7 @@ obj-$(CONFIG_XEN_TMEM)			+= tmem.o
>  obj-$(CONFIG_SWIOTLB_XEN)		+= swiotlb-xen.o
>  obj-$(CONFIG_XEN_DOM0)			+= pci.o acpi.o
>  obj-$(CONFIG_XEN_PCIDEV_BACKEND)	+= xen-pciback/
> +obj-$(CONFIG_ACPI_HOTPLUG_MEMORY)	+= xen_acpi_memhotplug.o
>  ifdef CONFIG_ACPI_PROCESSOR_XEN
>  obj-$(CONFIG_ACPI_PROCESSOR)		+= acpi_processor.o
>  endif
> diff --git a/drivers/xen/xen_acpi_memhotplug.c b/drivers/xen/xen_acpi_memhotplug.c
> new file mode 100644
> index 0000000..0c4af99
> --- /dev/null
> +++ b/drivers/xen/xen_acpi_memhotplug.c
> @@ -0,0 +1,209 @@
> +/*
> + *  xen_acpi_memhotplug.c - interface to notify Xen on memory device hotadd
> + *
> + *  Copyright (C) 2008, Intel corporation
> + *
> + * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> + *
> + *  This program is free software; you can redistribute it and/or modify
> + *  it under the terms of the GNU General Public License as published by
> + *  the Free Software Foundation; either version 2 of the License, or (at
> + *  your option) any later version.
> + *
> + *  This program is distributed in the hope that it will be useful, but
> + *  WITHOUT ANY WARRANTY; without even the implied warranty of
> + *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> + *  General Public License for more details.
> + *
> + *  You should have received a copy of the GNU General Public License along
> + *  with this program; if not, write to the Free Software Foundation, Inc.,
> + *  59 Temple Place, Suite 330, Boston, MA 02111-1307 USA.

Get rid of that please. The address can change.

Hm, going to stop looking at the patch here - will wait until you take a
look at Daniel's work and see if you can use some of it.
> + *
> + */
> +
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/init.h>
> +#include <linux/types.h>
> +#include <linux/memory_hotplug.h>
> +#include <acpi/acpi_drivers.h>
> +#include <xen/interface/platform.h>
> +#include <linux/interrupt.h>
> +#include <linux/spinlock.h>
> +#include <asm/xen/hypervisor.h>
> +#include <asm/xen/hypercall.h>
> +#include <xen/acpi.h>
> +
> +struct xen_hotmem_entry {
> +	struct list_head hotmem_list;
> +	uint64_t start;
> +	uint64_t end;
> +	uint32_t flags;
> +	uint32_t pxm;
> +};
> +
> +struct xen_hotmem_list {
> +	struct list_head list;
> +	int entry_nr;
> +} xen_hotmem;
> +
> +DEFINE_SPINLOCK(xen_hotmem_lock);
> +
> +static int xen_hyper_addmem(struct xen_hotmem_entry *entry)
> +{
> +	int ret;
> +
> +	xen_platform_op_t op = {
> +		.cmd            = XENPF_mem_hotadd,
> +		.interface_version  = XENPF_INTERFACE_VERSION,
> +	};
> +	op.u.mem_add.spfn = entry->start >> PAGE_SHIFT;
> +	op.u.mem_add.epfn = entry->end >> PAGE_SHIFT;
> +	op.u.mem_add.flags = entry->flags;
> +	op.u.mem_add.pxm = entry->pxm;
> +
> +	ret = HYPERVISOR_dom0_op(&op);
> +	return ret;
> +}
> +
> +static int add_hotmem_entry(int pxm, uint64_t start,
> +			uint64_t length, uint32_t flags)
> +{
> +	struct xen_hotmem_entry *entry;
> +
> +	if (pxm < 0 || !length)
> +		return -EINVAL;
> +
> +	entry = kzalloc(sizeof(struct xen_hotmem_entry), GFP_ATOMIC);
> +	if (!entry)
> +		return -ENOMEM;
> +
> +	INIT_LIST_HEAD(&entry->hotmem_list);
> +	entry->start = start;
> +	entry->end = start + length;
> +	entry->flags = flags;
> +	entry->pxm = pxm;
> +
> +	spin_lock(&xen_hotmem_lock);
> +
> +	list_add_tail(&entry->hotmem_list, &xen_hotmem.list);
> +	xen_hotmem.entry_nr++;
> +
> +	spin_unlock(&xen_hotmem_lock);
> +
> +	return 0;
> +}
> +
> +static int free_hotmem_entry(struct xen_hotmem_entry *entry)
> +{
> +	list_del(&entry->hotmem_list);
> +	kfree(entry);
> +
> +	return 0;
> +}
> +
> +static void xen_hotadd_mem_dpc(struct work_struct *work)
> +{
> +	struct list_head *elem, *tmp;
> +	struct xen_hotmem_entry *entry;
> +	unsigned long flags;
> +	int ret;
> +
> +	spin_lock_irqsave(&xen_hotmem_lock, flags);
> +	list_for_each_safe(elem, tmp, &xen_hotmem.list) {
> +		entry = list_entry(elem, struct xen_hotmem_entry, hotmem_list);
> +		ret = xen_hyper_addmem(entry);
> +		if (ret)
> +			printk(KERN_WARNING "xen addmem failed with %x\n", ret);
> +		free_hotmem_entry(entry);
> +		xen_hotmem.entry_nr--;
> +	}
> +	spin_unlock_irqrestore(&xen_hotmem_lock, flags);
> +}
> +
> +static DECLARE_WORK(xen_hotadd_mem_work, xen_hotadd_mem_dpc);
> +
> +static int xen_acpi_get_pxm(acpi_handle h)
> +{
> +	unsigned long long pxm;
> +	acpi_status status;
> +	acpi_handle handle;
> +	acpi_handle phandle = h;
> +
> +	do {
> +		handle = phandle;
> +		status = acpi_evaluate_integer(handle, "_PXM", NULL, &pxm);
> +		if (ACPI_SUCCESS(status))
> +			return pxm;
> +		status = acpi_get_parent(handle, &phandle);
> +	} while (ACPI_SUCCESS(status));
> +
> +	return -1;
> +}
> +
> +int xen_hotadd_memory(struct acpi_memory_device *mem_device)
> +{
> +	int pxm, result;
> +	int num_enabled = 0;
> +	struct acpi_memory_info *info;
> +
> +	if (!mem_device)
> +		return -EINVAL;
> +
> +	pxm = xen_acpi_get_pxm(mem_device->device->handle);
> +
> +	if (pxm < 0)
> +		return -EINVAL;
> +
> +	/*
> +	 * Always return success to ACPI driver, and notify hypervisor later
> +	 * because hypervisor will utilize the memory in memory hotadd hypercall
> +	 */
> +	list_for_each_entry(info, &mem_device->res_list, list) {
> +		if (info->enabled) { /* just sanity check...*/
> +			num_enabled++;
> +			continue;
> +		}
> +		/*
> +		 * If the memory block size is zero, please ignore it.
> +		 * Don't try to do the following memory hotplug flowchart.
> +		 */
> +		if (!info->length)
> +			continue;
> +
> +		result = add_hotmem_entry(pxm, info->start_addr,
> +					info->length, 0);
> +		if (result)
> +			continue;
> +		info->enabled = 1;
> +		num_enabled++;
> +	}
> +
> +	if (!num_enabled)
> +		return -EINVAL;
> +
> +	schedule_work(&xen_hotadd_mem_work);
> +
> +	return 0;
> +}
> +EXPORT_SYMBOL(xen_hotadd_memory);
> +
> +static int xen_hotadd_mem_init(void)
> +{
> +	if (!xen_initial_domain())
> +		return -ENODEV;
> +
> +	INIT_LIST_HEAD(&xen_hotmem.list);
> +	xen_hotmem.entry_nr = 0;
> +
> +	return 0;
> +}
> +
> +static void xen_hotadd_mem_exit(void)
> +{
> +	flush_scheduled_work();
> +}
> +
> +module_init(xen_hotadd_mem_init);
> +module_exit(xen_hotadd_mem_exit);
> +MODULE_LICENSE("GPL");
> diff --git a/include/xen/acpi.h b/include/xen/acpi.h
> index 7aa282d..8b3462e 100644
> --- a/include/xen/acpi.h
> +++ b/include/xen/acpi.h
> @@ -107,6 +107,11 @@ static inline int xen_acpi_processor_get_performance(struct acpi_processor *pr)
>  }
>  #endif
>  
> +#if defined(CONFIG_ACPI_HOTPLUG_MEMORY) || \
> +defined(CONFIG_ACPI_HOTPLUG_MEMORY_MODULE)
> +int xen_hotadd_memory(struct acpi_memory_device *mem_device);
> +#endif
> +
>  #if defined(CONFIG_ACPI_PROCESSOR_XEN) || \
>  defined(CONFIG_ACPI_PROCESSOR_XEN_MODULE)
>  
> diff --git a/include/xen/interface/platform.h b/include/xen/interface/platform.h
> index 9fd6b07..0787c68 100644
> --- a/include/xen/interface/platform.h
> +++ b/include/xen/interface/platform.h
> @@ -329,6 +329,14 @@ struct xenpf_cpu_hotadd {
>  	uint32_t pxm;
>  };
>  
> +#define XENPF_mem_hotadd    59
> +struct xenpf_mem_hotadd {
> +	uint64_t spfn;
> +	uint64_t epfn;
> +	uint32_t pxm;
> +	uint32_t flags;
> +};
> +
>  struct xen_platform_op {
>  	uint32_t cmd;
>  	uint32_t interface_version; /* XENPF_INTERFACE_VERSION */
> @@ -347,6 +355,7 @@ struct xen_platform_op {
>  		struct xenpf_pcpuinfo          pcpu_info;
>  		struct xenpf_cpu_ol            cpu_ol;
>  		struct xenpf_cpu_hotadd        cpu_add;
> +		struct xenpf_mem_hotadd        mem_add;
>  		uint8_t                        pad[128];
>  	} u;
>  };
> -- 
> 1.6.5.6


> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 23 13:25:26 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 Dec 2011 13:25:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Re57S-0006pN-EH; Fri, 23 Dec 2011 13:25:06 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1Re57Q-0006p9-Rv
	for xen-devel@lists.xensource.com; Fri, 23 Dec 2011 13:25:05 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-9.tower-216.messagelabs.com!1324646697!8597247!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12294 invoked from network); 23 Dec 2011 13:24:58 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-9.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 23 Dec 2011 13:24:58 -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
	pBNDOsNw000328
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Fri, 23 Dec 2011 08:24:54 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pBNDOr0V000326;
	Fri, 23 Dec 2011 08:24:53 -0500
Date: Fri, 23 Dec 2011 09:24:53 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: "Liu, Jinsong" <jinsong.liu@intel.com>
Message-ID: <20111223132453.GF25286@andromeda.dapyr.net>
References: <DE8DF0795D48FD4CA783C40EC82923359771@SHSMSX101.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <DE8DF0795D48FD4CA783C40EC82923359771@SHSMSX101.ccr.corp.intel.com>
User-Agent: Mutt/1.5.9i
Cc: "Brown, Len" <len.brown@intel.com>,
	"jeremy.fitzhardinge@citrix.com" <jeremy.fitzhardinge@citrix.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>, "Jiang,
	Yunhong" <yunhong.jiang@intel.com>, "Shan, Haitao" <haitao.shan@intel.com>,
	Kernel development list <linux-kernel@vger.kernel.org>, "Zhao,
	Yakui" <yakui.zhao@intel.com>, "Luck, Tony" <tony.luck@intel.com>, "Kleen,
	Andi" <andi.kleen@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 10/10] Xen: update pcpu online/offline logic
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Dec 23, 2011 at 10:32:12AM +0000, Liu, Jinsong wrote:
> >From 1e59d2ec2ff93b42c86d18c7cc9432ca2172a795 Mon Sep 17 00:00:00 2001
> From: Liu Jinsong <jinsong.liu@intel.com>
> Date: Wed, 14 Dec 2011 21:06:11 +0800
> Subject: [PATCH 10/10] Xen: update pcpu online/offline logic
> 
> This patch update pcpu online/offline logic.

Roll them in the patch you posted please.
> 
> It closes cpu0's /sys/.../xen_pcpu0/online authority to user.
> It also simplifies pcpu sync by removing redundant logic.
> 
> Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
> Signed-off-by: Jiang, Yunhong <yunhong.jiang@intel.com>
> ---
>  drivers/xen/pcpu.c |   71 ++++++++++++++--------------------------------------
>  1 files changed, 19 insertions(+), 52 deletions(-)
> 
> diff --git a/drivers/xen/pcpu.c b/drivers/xen/pcpu.c
> index 6d1a770..1d32784 100644
> --- a/drivers/xen/pcpu.c
> +++ b/drivers/xen/pcpu.c
> @@ -24,7 +24,6 @@ static RAW_NOTIFIER_HEAD(xen_pcpu_chain);
>  
>  struct xen_pcpus {
>  	struct list_head list;
> -	int present;
>  };
>  static struct xen_pcpus xen_pcpus;
>  
> @@ -189,9 +188,13 @@ static int pcpu_sysdev_init(struct pcpu *cpu)
>  		kfree(cpu);
>  		return -1;
>  	}
> -	sysdev_create_file(&cpu->sysdev, &attr_online);
>  	sysdev_create_file(&cpu->sysdev, &attr_apic_id);
>  	sysdev_create_file(&cpu->sysdev, &attr_acpi_id);
> +
> +	/* Not open cpu0 online access to user */
> +	if (cpu->sysdev.id)
> +		sysdev_create_file(&cpu->sysdev, &attr_online);
> +
>  	return 0;
>  }
>  
> @@ -239,17 +242,10 @@ static struct pcpu *init_pcpu(struct xenpf_pcpuinfo *info)
>  	return pcpu;
>  }
>  
> -#define PCPU_NO_CHANGE			0
> -#define PCPU_ADDED			1
> -#define PCPU_ONLINE_OFFLINE		2
> -#define PCPU_REMOVED			3
>  /*
>   * Caller should hold the pcpu lock
> - * < 0: Something wrong
> - * 0: No changes
> - * > 0: State changed
>   */
> -static struct pcpu *_sync_pcpu(int cpu_num, int *max_id, int *result)
> +static int _sync_pcpu(int cpu_num, int *max_id)
>  {
>  	struct pcpu *pcpu = NULL;
>  	struct xenpf_pcpuinfo *info;
> @@ -259,14 +255,12 @@ static struct pcpu *_sync_pcpu(int cpu_num, int *max_id, int *result)
>  	};
>  	int ret;
>  
> -	*result = -1;
> -
>  	info = &op.u.pcpu_info;
>  	info->xen_cpuid = cpu_num;
>  
>  	ret = HYPERVISOR_dom0_op(&op);
>  	if (ret)
> -		return NULL;
> +		return -1;
>  
>  	if (max_id)
>  		*max_id = op.u.pcpu_info.max_present;
> @@ -275,28 +269,24 @@ static struct pcpu *_sync_pcpu(int cpu_num, int *max_id, int *result)
>  
>  	if (info->flags & XEN_PCPU_FLAGS_INVALID) {
>  		/* The pcpu has been removed */
> -		*result = PCPU_NO_CHANGE;
>  		if (pcpu) {
>  			raw_notifier_call_chain(&xen_pcpu_chain,
>  			  XEN_PCPU_REMOVE,
>  			  (void *)(long)pcpu->xen_id);
>  			xen_pcpu_free(pcpu);
> -			*result = PCPU_REMOVED;
>  		}
> -		return NULL;
> +		return 0;
>  	}
>  
>  
>  	if (!pcpu) {
> -		*result = PCPU_ADDED;
>  		pcpu = init_pcpu(info);
>  		if (pcpu == NULL) {
>  			printk(KERN_WARNING "Failed to init pcpu %x\n",
>  			  info->xen_cpuid);
> -			  *result = -1;
> +			return -1;
>  		}
>  	} else {
> -		*result = PCPU_NO_CHANGE;
>  		/*
>  		 * Old PCPU is replaced with a new pcpu, this means
>  		 * several virq is missed, will it happen?
> @@ -307,10 +297,10 @@ static struct pcpu *_sync_pcpu(int cpu_num, int *max_id, int *result)
>  			pcpu->apic_id = info->apic_id;
>  			pcpu->acpi_id = info->acpi_id;
>  		}
> -		if (xen_pcpu_online_check(info, pcpu))
> -			*result = PCPU_ONLINE_OFFLINE;
> +		xen_pcpu_online_check(info, pcpu);
>  	}
> -	return pcpu;
> +
> +	return 0;
>  }
>  
>  int xen_pcpu_index(uint32_t id, int is_acpiid)
> @@ -353,50 +343,27 @@ static int xen_sync_pcpus(void)
>  	/*
>  	 * Boot cpu always have cpu_id 0 in xen
>  	 */
> -	int cpu_num = 0, max_id = 0, result = 0, present = 0;
> +	int cpu_num = 0, max_id = 0, ret = 0;
>  	struct list_head *elem, *tmp;
>  	struct pcpu *pcpu;
>  
>  	get_pcpu_lock();
>  
> -	while ((result >= 0) && (cpu_num <= max_id)) {
> -		pcpu = _sync_pcpu(cpu_num, &max_id, &result);
> -
> -		printk(KERN_DEBUG "sync cpu %x get result %x max_id %x\n",
> -			cpu_num, result, max_id);
> -
> -		switch (result)	{
> -		case PCPU_NO_CHANGE:
> -			if (pcpu)
> -				present++;
> -			break;
> -		case PCPU_ADDED:
> -		case PCPU_ONLINE_OFFLINE:
> -			present++;
> -		case PCPU_REMOVED:
> -			break;
> -		default:
> -			printk(KERN_WARNING "Failed to sync pcpu %x\n",
> -			  cpu_num);
> -			break;
> -
> -		}
> +	while (!ret && (cpu_num <= max_id)) {
> +		ret = _sync_pcpu(cpu_num, &max_id);
>  		cpu_num++;
>  	}
>  
> -	if (result < 0) {
> +	if (ret < 0) {
>  		list_for_each_safe(elem, tmp, &xen_pcpus.list) {
>  			pcpu = list_entry(elem, struct pcpu, pcpu_list);
>  			xen_pcpu_free(pcpu);
>  		}
> -		present = 0;
>  	}
>  
> -	xen_pcpus.present = present;
> -
>  	put_pcpu_lock();
>  
> -	return 0;
> +	return ret;
>  }
>  
>  static void xen_pcpu_dpc(struct work_struct *work)
> @@ -436,10 +403,10 @@ static int __init xen_pcpu_init(void)
>  	}
>  
>  	INIT_LIST_HEAD(&xen_pcpus.list);
> -	xen_pcpus.present = 0;
>  
>  	xen_sync_pcpus();
> -	if (xen_pcpus.present > 0)
> +
> +	if (!list_empty(&xen_pcpus.list))
>  		err = bind_virq_to_irqhandler(VIRQ_PCPU_STATE,
>  			0, xen_pcpu_interrupt, 0, "pcpu", NULL);
>  	if (err < 0)
> -- 
> 1.6.5.6


> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 23 13:25:26 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 Dec 2011 13:25:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Re57S-0006pN-EH; Fri, 23 Dec 2011 13:25:06 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1Re57Q-0006p9-Rv
	for xen-devel@lists.xensource.com; Fri, 23 Dec 2011 13:25:05 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-9.tower-216.messagelabs.com!1324646697!8597247!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12294 invoked from network); 23 Dec 2011 13:24:58 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-9.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 23 Dec 2011 13:24:58 -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
	pBNDOsNw000328
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Fri, 23 Dec 2011 08:24:54 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pBNDOr0V000326;
	Fri, 23 Dec 2011 08:24:53 -0500
Date: Fri, 23 Dec 2011 09:24:53 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: "Liu, Jinsong" <jinsong.liu@intel.com>
Message-ID: <20111223132453.GF25286@andromeda.dapyr.net>
References: <DE8DF0795D48FD4CA783C40EC82923359771@SHSMSX101.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <DE8DF0795D48FD4CA783C40EC82923359771@SHSMSX101.ccr.corp.intel.com>
User-Agent: Mutt/1.5.9i
Cc: "Brown, Len" <len.brown@intel.com>,
	"jeremy.fitzhardinge@citrix.com" <jeremy.fitzhardinge@citrix.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>, "Jiang,
	Yunhong" <yunhong.jiang@intel.com>, "Shan, Haitao" <haitao.shan@intel.com>,
	Kernel development list <linux-kernel@vger.kernel.org>, "Zhao,
	Yakui" <yakui.zhao@intel.com>, "Luck, Tony" <tony.luck@intel.com>, "Kleen,
	Andi" <andi.kleen@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 10/10] Xen: update pcpu online/offline logic
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Dec 23, 2011 at 10:32:12AM +0000, Liu, Jinsong wrote:
> >From 1e59d2ec2ff93b42c86d18c7cc9432ca2172a795 Mon Sep 17 00:00:00 2001
> From: Liu Jinsong <jinsong.liu@intel.com>
> Date: Wed, 14 Dec 2011 21:06:11 +0800
> Subject: [PATCH 10/10] Xen: update pcpu online/offline logic
> 
> This patch update pcpu online/offline logic.

Roll them in the patch you posted please.
> 
> It closes cpu0's /sys/.../xen_pcpu0/online authority to user.
> It also simplifies pcpu sync by removing redundant logic.
> 
> Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
> Signed-off-by: Jiang, Yunhong <yunhong.jiang@intel.com>
> ---
>  drivers/xen/pcpu.c |   71 ++++++++++++++--------------------------------------
>  1 files changed, 19 insertions(+), 52 deletions(-)
> 
> diff --git a/drivers/xen/pcpu.c b/drivers/xen/pcpu.c
> index 6d1a770..1d32784 100644
> --- a/drivers/xen/pcpu.c
> +++ b/drivers/xen/pcpu.c
> @@ -24,7 +24,6 @@ static RAW_NOTIFIER_HEAD(xen_pcpu_chain);
>  
>  struct xen_pcpus {
>  	struct list_head list;
> -	int present;
>  };
>  static struct xen_pcpus xen_pcpus;
>  
> @@ -189,9 +188,13 @@ static int pcpu_sysdev_init(struct pcpu *cpu)
>  		kfree(cpu);
>  		return -1;
>  	}
> -	sysdev_create_file(&cpu->sysdev, &attr_online);
>  	sysdev_create_file(&cpu->sysdev, &attr_apic_id);
>  	sysdev_create_file(&cpu->sysdev, &attr_acpi_id);
> +
> +	/* Not open cpu0 online access to user */
> +	if (cpu->sysdev.id)
> +		sysdev_create_file(&cpu->sysdev, &attr_online);
> +
>  	return 0;
>  }
>  
> @@ -239,17 +242,10 @@ static struct pcpu *init_pcpu(struct xenpf_pcpuinfo *info)
>  	return pcpu;
>  }
>  
> -#define PCPU_NO_CHANGE			0
> -#define PCPU_ADDED			1
> -#define PCPU_ONLINE_OFFLINE		2
> -#define PCPU_REMOVED			3
>  /*
>   * Caller should hold the pcpu lock
> - * < 0: Something wrong
> - * 0: No changes
> - * > 0: State changed
>   */
> -static struct pcpu *_sync_pcpu(int cpu_num, int *max_id, int *result)
> +static int _sync_pcpu(int cpu_num, int *max_id)
>  {
>  	struct pcpu *pcpu = NULL;
>  	struct xenpf_pcpuinfo *info;
> @@ -259,14 +255,12 @@ static struct pcpu *_sync_pcpu(int cpu_num, int *max_id, int *result)
>  	};
>  	int ret;
>  
> -	*result = -1;
> -
>  	info = &op.u.pcpu_info;
>  	info->xen_cpuid = cpu_num;
>  
>  	ret = HYPERVISOR_dom0_op(&op);
>  	if (ret)
> -		return NULL;
> +		return -1;
>  
>  	if (max_id)
>  		*max_id = op.u.pcpu_info.max_present;
> @@ -275,28 +269,24 @@ static struct pcpu *_sync_pcpu(int cpu_num, int *max_id, int *result)
>  
>  	if (info->flags & XEN_PCPU_FLAGS_INVALID) {
>  		/* The pcpu has been removed */
> -		*result = PCPU_NO_CHANGE;
>  		if (pcpu) {
>  			raw_notifier_call_chain(&xen_pcpu_chain,
>  			  XEN_PCPU_REMOVE,
>  			  (void *)(long)pcpu->xen_id);
>  			xen_pcpu_free(pcpu);
> -			*result = PCPU_REMOVED;
>  		}
> -		return NULL;
> +		return 0;
>  	}
>  
>  
>  	if (!pcpu) {
> -		*result = PCPU_ADDED;
>  		pcpu = init_pcpu(info);
>  		if (pcpu == NULL) {
>  			printk(KERN_WARNING "Failed to init pcpu %x\n",
>  			  info->xen_cpuid);
> -			  *result = -1;
> +			return -1;
>  		}
>  	} else {
> -		*result = PCPU_NO_CHANGE;
>  		/*
>  		 * Old PCPU is replaced with a new pcpu, this means
>  		 * several virq is missed, will it happen?
> @@ -307,10 +297,10 @@ static struct pcpu *_sync_pcpu(int cpu_num, int *max_id, int *result)
>  			pcpu->apic_id = info->apic_id;
>  			pcpu->acpi_id = info->acpi_id;
>  		}
> -		if (xen_pcpu_online_check(info, pcpu))
> -			*result = PCPU_ONLINE_OFFLINE;
> +		xen_pcpu_online_check(info, pcpu);
>  	}
> -	return pcpu;
> +
> +	return 0;
>  }
>  
>  int xen_pcpu_index(uint32_t id, int is_acpiid)
> @@ -353,50 +343,27 @@ static int xen_sync_pcpus(void)
>  	/*
>  	 * Boot cpu always have cpu_id 0 in xen
>  	 */
> -	int cpu_num = 0, max_id = 0, result = 0, present = 0;
> +	int cpu_num = 0, max_id = 0, ret = 0;
>  	struct list_head *elem, *tmp;
>  	struct pcpu *pcpu;
>  
>  	get_pcpu_lock();
>  
> -	while ((result >= 0) && (cpu_num <= max_id)) {
> -		pcpu = _sync_pcpu(cpu_num, &max_id, &result);
> -
> -		printk(KERN_DEBUG "sync cpu %x get result %x max_id %x\n",
> -			cpu_num, result, max_id);
> -
> -		switch (result)	{
> -		case PCPU_NO_CHANGE:
> -			if (pcpu)
> -				present++;
> -			break;
> -		case PCPU_ADDED:
> -		case PCPU_ONLINE_OFFLINE:
> -			present++;
> -		case PCPU_REMOVED:
> -			break;
> -		default:
> -			printk(KERN_WARNING "Failed to sync pcpu %x\n",
> -			  cpu_num);
> -			break;
> -
> -		}
> +	while (!ret && (cpu_num <= max_id)) {
> +		ret = _sync_pcpu(cpu_num, &max_id);
>  		cpu_num++;
>  	}
>  
> -	if (result < 0) {
> +	if (ret < 0) {
>  		list_for_each_safe(elem, tmp, &xen_pcpus.list) {
>  			pcpu = list_entry(elem, struct pcpu, pcpu_list);
>  			xen_pcpu_free(pcpu);
>  		}
> -		present = 0;
>  	}
>  
> -	xen_pcpus.present = present;
> -
>  	put_pcpu_lock();
>  
> -	return 0;
> +	return ret;
>  }
>  
>  static void xen_pcpu_dpc(struct work_struct *work)
> @@ -436,10 +403,10 @@ static int __init xen_pcpu_init(void)
>  	}
>  
>  	INIT_LIST_HEAD(&xen_pcpus.list);
> -	xen_pcpus.present = 0;
>  
>  	xen_sync_pcpus();
> -	if (xen_pcpus.present > 0)
> +
> +	if (!list_empty(&xen_pcpus.list))
>  		err = bind_virq_to_irqhandler(VIRQ_PCPU_STATE,
>  			0, xen_pcpu_interrupt, 0, "pcpu", NULL);
>  	if (err < 0)
> -- 
> 1.6.5.6


> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 23 17:40:23 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 Dec 2011 17:40:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Re95s-0000SW-TF; Fri, 23 Dec 2011 17:39:44 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julia@diku.dk>) id 1Re95r-0000SR-3k
	for xen-devel@lists.xensource.com; Fri, 23 Dec 2011 17:39:43 +0000
X-Env-Sender: julia@diku.dk
X-Msg-Ref: server-10.tower-27.messagelabs.com!1324661940!47988832!1
X-Originating-IP: [130.225.96.92]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9566 invoked from network); 23 Dec 2011 17:39:00 -0000
Received: from mgw2.diku.dk (HELO mgw2.diku.dk) (130.225.96.92)
	by server-10.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Dec 2011 17:39:00 -0000
Received: from localhost (localhost [127.0.0.1])
	by mgw2.diku.dk (Postfix) with ESMTP id 8AFEB19BC5A;
	Fri, 23 Dec 2011 18:39:41 +0100 (CET)
Received: from mgw2.diku.dk ([127.0.0.1])
	by localhost (mgw2.diku.dk [127.0.0.1]) (amavisd-new,
	port 10024) with ESMTP
	id 11368-08; Fri, 23 Dec 2011 18:39:34 +0100 (CET)
Received: from palace.topps.diku.dk (palace.ekstranet.diku.dk [192.38.115.202])
	by mgw2.diku.dk (Postfix) with ESMTP id 790C519BC61;
	Fri, 23 Dec 2011 18:39:34 +0100 (CET)
From: Julia Lawall <julia@diku.dk>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Fri, 23 Dec 2011 18:39:29 +0100
Message-Id: <1324661974-17281-4-git-send-email-julia@diku.dk>
X-Mailer: git-send-email 1.7.3.4
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, xen-devel@lists.xensource.com,
	kernel-janitors@vger.kernel.org, linux-kernel@vger.kernel.org,
	virtualization@lists.linux-foundation.org
Subject: [Xen-devel] [PATCH 4/9] drivers/xen/gntalloc.c: introduce missing
	kfree
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Error handling code following a kmalloc should free the allocated data.
Out_unlock is used on both success and failure, so free vm_priv before
jumping to that label.

A simplified version of the semantic match that finds the problem is as
follows: (http://coccinelle.lip6.fr)

// <smpl>
@r exists@
local idexpression x;
statement S;
identifier f1;
position p1,p2;
expression *ptr != NULL;
@@

x@p1 = \(kmalloc\|kzalloc\|kcalloc\)(...);
...
if (x == NULL) S
<... when != x
     when != if (...) { <+...x...+> }
x->f1
...>
(
 return \(0\|<+...x...+>\|ptr\);
|
 return@p2 ...;
)

@script:python@
p1 << r.p1;
p2 << r.p2;
@@

print "* file: %s kmalloc %s return %s" % (p1[0].file,p1[0].line,p2[0].line)
// </smpl>

Signed-off-by: Julia Lawall <julia@diku.dk>

---
 drivers/xen/gntalloc.c |    1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/xen/gntalloc.c b/drivers/xen/gntalloc.c
index e2400c8..934985d 100644
--- a/drivers/xen/gntalloc.c
+++ b/drivers/xen/gntalloc.c
@@ -525,6 +525,7 @@ static int gntalloc_mmap(struct file *filp, struct vm_area_struct *vma)
 		rv = -ENOENT;
 		pr_debug("%s: Could not find grant reference",
 				__func__);
+		kfree(vm_priv);
 		goto out_unlock;
 	}
 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 23 17:40:23 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 Dec 2011 17:40:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Re95s-0000SW-TF; Fri, 23 Dec 2011 17:39:44 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julia@diku.dk>) id 1Re95r-0000SR-3k
	for xen-devel@lists.xensource.com; Fri, 23 Dec 2011 17:39:43 +0000
X-Env-Sender: julia@diku.dk
X-Msg-Ref: server-10.tower-27.messagelabs.com!1324661940!47988832!1
X-Originating-IP: [130.225.96.92]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9566 invoked from network); 23 Dec 2011 17:39:00 -0000
Received: from mgw2.diku.dk (HELO mgw2.diku.dk) (130.225.96.92)
	by server-10.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Dec 2011 17:39:00 -0000
Received: from localhost (localhost [127.0.0.1])
	by mgw2.diku.dk (Postfix) with ESMTP id 8AFEB19BC5A;
	Fri, 23 Dec 2011 18:39:41 +0100 (CET)
Received: from mgw2.diku.dk ([127.0.0.1])
	by localhost (mgw2.diku.dk [127.0.0.1]) (amavisd-new,
	port 10024) with ESMTP
	id 11368-08; Fri, 23 Dec 2011 18:39:34 +0100 (CET)
Received: from palace.topps.diku.dk (palace.ekstranet.diku.dk [192.38.115.202])
	by mgw2.diku.dk (Postfix) with ESMTP id 790C519BC61;
	Fri, 23 Dec 2011 18:39:34 +0100 (CET)
From: Julia Lawall <julia@diku.dk>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Fri, 23 Dec 2011 18:39:29 +0100
Message-Id: <1324661974-17281-4-git-send-email-julia@diku.dk>
X-Mailer: git-send-email 1.7.3.4
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, xen-devel@lists.xensource.com,
	kernel-janitors@vger.kernel.org, linux-kernel@vger.kernel.org,
	virtualization@lists.linux-foundation.org
Subject: [Xen-devel] [PATCH 4/9] drivers/xen/gntalloc.c: introduce missing
	kfree
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Error handling code following a kmalloc should free the allocated data.
Out_unlock is used on both success and failure, so free vm_priv before
jumping to that label.

A simplified version of the semantic match that finds the problem is as
follows: (http://coccinelle.lip6.fr)

// <smpl>
@r exists@
local idexpression x;
statement S;
identifier f1;
position p1,p2;
expression *ptr != NULL;
@@

x@p1 = \(kmalloc\|kzalloc\|kcalloc\)(...);
...
if (x == NULL) S
<... when != x
     when != if (...) { <+...x...+> }
x->f1
...>
(
 return \(0\|<+...x...+>\|ptr\);
|
 return@p2 ...;
)

@script:python@
p1 << r.p1;
p2 << r.p2;
@@

print "* file: %s kmalloc %s return %s" % (p1[0].file,p1[0].line,p2[0].line)
// </smpl>

Signed-off-by: Julia Lawall <julia@diku.dk>

---
 drivers/xen/gntalloc.c |    1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/xen/gntalloc.c b/drivers/xen/gntalloc.c
index e2400c8..934985d 100644
--- a/drivers/xen/gntalloc.c
+++ b/drivers/xen/gntalloc.c
@@ -525,6 +525,7 @@ static int gntalloc_mmap(struct file *filp, struct vm_area_struct *vma)
 		rv = -ENOENT;
 		pr_debug("%s: Could not find grant reference",
 				__func__);
+		kfree(vm_priv);
 		goto out_unlock;
 	}
 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Dec 24 05:29:18 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 24 Dec 2011 05: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.xensource.com>)
	id 1ReK9j-0000sS-Cq; Sat, 24 Dec 2011 05:28:27 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1ReK9h-0000sN-Rh
	for xen-devel@lists.xensource.com; Sat, 24 Dec 2011 05:28:26 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1324704463!51846782!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODM3MA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21694 invoked from network); 24 Dec 2011 05:27:43 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Dec 2011 05:27:43 -0000
X-IronPort-AV: E=Sophos;i="4.71,402,1320624000"; 
   d="scan'208";a="9665603"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Dec 2011 05:28:23 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sat, 24 Dec 2011 05:28:23 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1ReK9f-0007KB-7q;
	Sat, 24 Dec 2011 05:28:23 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1ReK9f-0006ZZ-0W;
	Sat, 24 Dec 2011 05:28:23 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10607-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 24 Dec 2011 05:28:23 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10607: tolerable FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10607 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10607/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf-pin 14 guest-localmigrate/x10      fail pass in 10606
 test-amd64-amd64-xl          16 guest-start.2               fail pass in 10606
 test-amd64-amd64-xl-win       7 windows-install             fail pass in 10606
 test-amd64-i386-xl           16 guest-start.2      fail in 10606 pass in 10607
 test-amd64-i386-xl-win7-amd64  7 windows-install   fail in 10606 pass in 10607
 test-amd64-amd64-xl-sedf     11 guest-localmigrate fail in 10606 pass in 10607

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf     14 guest-localmigrate/x10       fail   like 10600
 test-i386-i386-xl-win         7 windows-install       fail in 10606 like 10600

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win      13 guest-stop            fail in 10606 never pass

version targeted for testing:
 xen                  2863b2f43a3b
baseline version:
 xen                  2863b2f43a3b

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Dec 24 05:29:18 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 24 Dec 2011 05: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.xensource.com>)
	id 1ReK9j-0000sS-Cq; Sat, 24 Dec 2011 05:28:27 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1ReK9h-0000sN-Rh
	for xen-devel@lists.xensource.com; Sat, 24 Dec 2011 05:28:26 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1324704463!51846782!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODM3MA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21694 invoked from network); 24 Dec 2011 05:27:43 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Dec 2011 05:27:43 -0000
X-IronPort-AV: E=Sophos;i="4.71,402,1320624000"; 
   d="scan'208";a="9665603"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Dec 2011 05:28:23 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sat, 24 Dec 2011 05:28:23 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1ReK9f-0007KB-7q;
	Sat, 24 Dec 2011 05:28:23 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1ReK9f-0006ZZ-0W;
	Sat, 24 Dec 2011 05:28:23 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10607-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 24 Dec 2011 05:28:23 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10607: tolerable FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10607 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10607/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf-pin 14 guest-localmigrate/x10      fail pass in 10606
 test-amd64-amd64-xl          16 guest-start.2               fail pass in 10606
 test-amd64-amd64-xl-win       7 windows-install             fail pass in 10606
 test-amd64-i386-xl           16 guest-start.2      fail in 10606 pass in 10607
 test-amd64-i386-xl-win7-amd64  7 windows-install   fail in 10606 pass in 10607
 test-amd64-amd64-xl-sedf     11 guest-localmigrate fail in 10606 pass in 10607

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf     14 guest-localmigrate/x10       fail   like 10600
 test-i386-i386-xl-win         7 windows-install       fail in 10606 like 10600

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win      13 guest-stop            fail in 10606 never pass

version targeted for testing:
 xen                  2863b2f43a3b
baseline version:
 xen                  2863b2f43a3b

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Dec 24 11:09:45 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 24 Dec 2011 11:09:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RePT8-0002qQ-5F; Sat, 24 Dec 2011 11:08:50 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RePT6-0002qI-4q
	for xen-devel@lists.xensource.com; Sat, 24 Dec 2011 11:08:48 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1324724807!57413097!1
X-Originating-IP: [209.85.160.43]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15483 invoked from network); 24 Dec 2011 11:06:49 -0000
Received: from mail-pw0-f43.google.com (HELO mail-pw0-f43.google.com)
	(209.85.160.43)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Dec 2011 11:06:49 -0000
Received: by pbbb11 with SMTP id b11so35181891pbb.30
	for <xen-devel@lists.xensource.com>;
	Sat, 24 Dec 2011 03:08:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:date:x-google-sender-auth:message-id:subject
	:from:to:content-type;
	bh=/LQ1tb5qoC+pIhs3M4Ev86W5bq079S9yHvYSC0yHFAI=;
	b=k4ay2j4L61ApWGqIvqlCD9XkQFQt0aGkywRWQKWGJYyAEwCm+IJt33dN4vXFaL6+Ap
	8y1tSrHBlXChN1ENR5o2Zk4vlw0fJEMiQT9EbERlJGRFsyo8wHnpR6II8+qolGzLCIXH
	43jCjj6QPzqgfoQWWNjRwItz20iNSkV5WII04=
MIME-Version: 1.0
Received: by 10.68.74.41 with SMTP id q9mr39209601pbv.129.1324724919079; Sat,
	24 Dec 2011 03:08:39 -0800 (PST)
Received: by 10.142.47.17 with HTTP; Sat, 24 Dec 2011 03:08:39 -0800 (PST)
Date: Sat, 24 Dec 2011 12:08:39 +0100
X-Google-Sender-Auth: MvfDpW9B8_nsGJbWAJMFjQAByiI
Message-ID: <CAPLaKK7Oi2chcq0Ke2nCz6yqae-oL7fDTbBbWeGw4i2rV0g_XA@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] Dom0 LiveCD
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hello,

I'm trying to create a Xen Dom0 LiveCD/usb, based on Alpine Linux,
which has great support for this kind of stuff. I've been able to
successfully install and boot Xen kernel and tools from an HDD using
the same configuration, but when using a tmpfs based boot, the Linux
kernel 3.0.10 crashes while loading some modules (Xen kernel seems to
boot fine). Xen version is stable 4.1.2 and Linux kernel is
3.0.10-grsec. Here is the full output of the boot process:


 __  __            _  _    _   ____
 \ \/ /___ _ __   | || |  / | |___ \
  \  // _ \ '_ \  | || |_ | |   __) |
  /  \  __/ | | | |__   _|| |_ / __/
 /_/\_\___|_| |_|    |_|(_)_(_)_____|

(XEN) Xen version 4.1.2 (royger@localdomain) (gcc version 4.6.2
(Alpine 4.6.2-r1) ) Fri Dec 23 12:55:25 CET 2011
(XEN) Latest ChangeSet: unavailable
(XEN) Bootloader: SYSLINUX 4.04 2011-04-18
(XEN) Command line: dom0_max_vcpus=1 dom0_vcpus_pin guest_loglvl=all
com2=115200,8n1 console=com2
(XEN) Video information:
(XEN)  VGA is text mode 80x25, font 8x16
(XEN) Disc information:
(XEN)  Found 2 MBR signatures
(XEN)  Found 2 EDD information structures
(XEN) Xen-e820 RAM map:
(XEN)  0000000000000000 - 0000000000099000 (usable)
(XEN)  0000000000099000 - 00000000000a0000 (reserved)
(XEN)  00000000000ca000 - 00000000000cc000 (reserved)
(XEN)  00000000000dc000 - 0000000000100000 (reserved)
(XEN)  0000000000100000 - 000000003fee0000 (usable)
(XEN)  000000003fee0000 - 000000003feff000 (ACPI data)
(XEN)  000000003feff000 - 000000003ff00000 (ACPI NVS)
(XEN)  000000003ff00000 - 0000000040000000 (usable)
(XEN)  00000000e0000000 - 00000000f0000000 (reserved)
(XEN)  00000000fec00000 - 00000000fec10000 (reserved)
(XEN)  00000000fee00000 - 00000000fee01000 (reserved)
(XEN)  00000000fffe0000 - 0000000100000000 (reserved)
(XEN) System RAM: 1023MB (1048036kB)
(XEN) ACPI: RSDP 000F6B50, 0024 (r2 PTLTD )
(XEN) ACPI: XSDT 3FEEEC5C, 005C (r1 INTEL  440BX     6040000 VMW   1324272)
(XEN) ACPI: FACP 3FEFEE98, 00F4 (r4 INTEL  440BX     6040000 PTL     F4240)
(XEN) ACPI: DSDT 3FEEF327, FB71 (r1 PTLTD  Custom    6040000 MSFT  3000001)
(XEN) ACPI: FACS 3FEFFFC0, 0040
(XEN) ACPI: BOOT 3FEEF2FF, 0028 (r1 PTLTD  $SBFTBL$  6040000  LTP        1)
(XEN) ACPI: APIC 3FEEF0FD, 0202 (r1 PTLTD  	 APIC    6040000  LTP        0)
(XEN) ACPI: MCFG 3FEEF0C1, 003C (r1 PTLTD  $PCITBL$  6040000  LTP        1)
(XEN) ACPI: SRAT 3FEEED58, 02A8 (r2 VMWARE MEMPLUG   6040000 VMW         1)
(XEN) ACPI: HPET 3FEEED20, 0038 (r1 VMWARE VMW HPET  6040000 VMW         1)
(XEN) ACPI: WAET 3FEEECF8, 0028 (r1 VMWARE VMW WAET  6040000 VMW         1)
(XEN) Domain heap initialised
(XEN) Processor #0 7:7 APIC version 20
(XEN) Processor #1 7:7 APIC version 20
(XEN) IOAPIC[0]: apic_id 32, version 17, address 0xfec00000, GSI 0-23
(XEN) Enabling APIC mode:  Flat.  Using 1 I/O APICs
(XEN) Table is not found!
(XEN) Using scheduler: SMP Credit Scheduler (credit)
(XEN) Detected 2123.193 MHz processor.
(XEN) Initing memory sharing.
(XEN) I/O virtualisation disabled
(XEN) ENABLING IO-APIC IRQs
(XEN)  -> Using new ACK method
(XEN) Platform timer is 14.318MHz HPET
?(XEN) Allocated console ring of 16 KiB.
(XEN) Brought up 2 CPUs
(XEN) *** LOADING DOMAIN 0 ***
(XEN)  Xen  kernel: 64-bit, lsb, compat32
(XEN)  Dom0 kernel: 64-bit, PAE, lsb, paddr 0x1000000 -> 0x1800000
(XEN) PHYSICAL MEMORY ARRANGEMENT:
(XEN)  Dom0 alloc.:   000000003a000000->000000003c000000 (229467 pages
to be allocated)
(XEN)  Init. ramdisk: 000000003e8ca000->000000003f9ffe28
(XEN) VIRTUAL MEMORY ARRANGEMENT:
(XEN)  Loaded kernel: ffffffff81000000->ffffffff81800000
(XEN)  Init. ramdisk: ffffffff81800000->ffffffff82935e28
(XEN)  Phys-Mach map: ffffffff82936000->ffffffff82b0ec88
(XEN)  Start info:    ffffffff82b0f000->ffffffff82b0f4b4
(XEN)  Page tables:   ffffffff82b10000->ffffffff82b29000
(XEN)  Boot stack:    ffffffff82b29000->ffffffff82b2a000
(XEN)  TOTAL:         ffffffff80000000->ffffffff82c00000
(XEN)  ENTRY ADDRESS: ffffffff814bf010
(XEN) Dom0 has maximum 1 VCPUs
(XEN) Scrubbing Free RAM: done.
(XEN) Xen trace buffers: disabled
(XEN) Std. Loglevel: Errors and warnings
(XEN) Guest Loglevel: All
(XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch
input to Xen)
(XEN) Freed 216kB init memory.
mapping kernel into physical memory
Xen: setup ISA identity maps
about to get started...
[    0.000000] Initializing cgroup subsys cpuset
[    0.000000] Initializing cgroup subsys cpu
[    0.000000] Linux version 3.0.10-grsec (buildozer@build64-2-3) (gcc
version 4.6.2 (Alpine 4.6.2-r1) ) #1-Alpine SMP Tue Nov 22 13:07:04
UTC 2011
[    0.000000] Command line: alpine_dev=UUID=4EF4-5EFD:vfat
modules=loop,squashfs,sd-mod,usb-storage
modloop=/boot/grsec.modloop.squashfs console=hvc0 earlyprintk=xen
nomodeset
[    0.000000] Disabled fast string operations
[    0.000000] released 0 pages of unused memory
[    0.000000] Set 786567 page(s) to 1-1 mapping.
[    0.000000] BIOS-provided physical RAM map:
[    0.000000]  Xen: 0000000000000000 - 0000000000099000 (usable)
[    0.000000]  Xen: 0000000000099000 - 0000000000100000 (reserved)
[    0.000000]  Xen: 0000000000100000 - 000000003b191000 (usable)
[    0.000000]  Xen: 000000003b191000 - 000000003fee0000 (unusable)
[    0.000000]  Xen: 000000003fee0000 - 000000003feff000 (ACPI data)
[    0.000000]  Xen: 000000003feff000 - 000000003ff00000 (ACPI NVS)
[    0.000000]  Xen: 000000003ff00000 - 0000000040000000 (unusable)
[    0.000000]  Xen: 00000000e0000000 - 00000000f0000000 (reserved)
[    0.000000]  Xen: 00000000fec00000 - 00000000fec10000 (reserved)
[    0.000000]  Xen: 00000000fee00000 - 00000000fee01000 (reserved)
[    0.000000]  Xen: 00000000fffe0000 - 0000000100000000 (reserved)
[    0.000000]  Xen: 0000000100000000 - 0000000104e4f000 (usable)
[    0.000000] NX (Execute Disable) protection: active
[    0.000000] DMI present.
[    0.000000] No AGP bridge found
[    0.000000] last_pfn = 0x104e4f max_arch_pfn = 0x400000000
[    0.000000] last_pfn = 0x3b191 max_arch_pfn = 0x400000000
[    0.000000] found SMP MP-table at [ffff8800000f6bc0] f6bc0
[    0.000000] init_memory_mapping: 0000000000000000-000000003b191000
[    0.000000] init_memory_mapping: 0000000100000000-0000000104e4f000
[    0.000000] RAMDISK: 01800000 - 02936000
[    0.000000] ACPI: RSDP 00000000000f6b50 00024 (v02 PTLTD )
[    0.000000] ACPI: XSDT 000000003feeec5c 0005C (v01 INTEL  440BX
06040000 VMW  01324272)
[    0.000000] ACPI: FACP 000000003fefee98 000F4 (v04 INTEL  440BX
06040000 PTL  000F4240)
[    0.000000] ACPI: DSDT 000000003feef327 0FB71 (v01 PTLTD  Custom
06040000 MSFT 03000001)
[    0.000000] ACPI: FACS 000000003fefffc0 00040
[    0.000000] ACPI: BOOT 000000003feef2ff 00028 (v01 PTLTD  $SBFTBL$
06040000  LTP 00000001)
[    0.000000] ACPI: APIC 000000003feef0fd 00202 (v01 PTLTD  ? APIC
06040000  LTP 00000000)
[    0.000000] ACPI: MCFG 000000003feef0c1 0003C (v01 PTLTD  $PCITBL$
06040000  LTP 00000001)
[    0.000000] ACPI: SRAT 000000003feeed58 002A8 (v02 VMWARE MEMPLUG
06040000 VMW  00000001)
[    0.000000] ACPI: HPET 000000003feeed20 00038 (v01 VMWARE VMW HPET
06040000 VMW  00000001)
[    0.000000] ACPI: WAET 000000003feeecf8 00028 (v01 VMWARE VMW WAET
06040000 VMW  00000001)
[    0.000000] Zone PFN ranges:
[    0.000000]   DMA      0x00000010 -> 0x00001000
[    0.000000]   DMA32    0x00001000 -> 0x00100000
[    0.000000]   Normal   0x00100000 -> 0x00104e4f
[    0.000000] Movable zone start PFN for each node
[    0.000000] early_node_map[3] active PFN ranges
[    0.000000]     0: 0x00000010 -> 0x00000099
[    0.000000]     0: 0x00000100 -> 0x0003b191
[    0.000000]     0: 0x00100000 -> 0x00104e4f
[    0.000000] ACPI: PM-Timer IO Port: 0x1008
[    0.000000] ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
[    0.000000] BIOS bug: APIC version is 0 for CPU 0/0x0, fixing up to 0x10
[    0.000000] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x02] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x03] lapic_id[0x03] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x04] lapic_id[0x04] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x05] lapic_id[0x05] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x06] lapic_id[0x06] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x07] lapic_id[0x07] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x08] lapic_id[0x08] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x09] lapic_id[0x09] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x0a] lapic_id[0x0a] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x0b] lapic_id[0x0b] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x0c] lapic_id[0x0c] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x0d] lapic_id[0x0d] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x0e] lapic_id[0x0e] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x0f] lapic_id[0x0f] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x10] lapic_id[0x10] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x11] lapic_id[0x11] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x12] lapic_id[0x12] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x13] lapic_id[0x13] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x14] lapic_id[0x14] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x15] lapic_id[0x15] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x16] lapic_id[0x16] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x17] lapic_id[0x17] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x18] lapic_id[0x18] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x19] lapic_id[0x19] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x1a] lapic_id[0x1a] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x1b] lapic_id[0x1b] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x1c] lapic_id[0x1c] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x1d] lapic_id[0x1d] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x1e] lapic_id[0x1e] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x1f] lapic_id[0x1f] disabled)
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x02] high edge lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x03] high edge lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x04] high edge lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x05] high edge lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x06] high edge lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x07] high edge lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x08] high edge lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x09] high edge lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x0a] high edge lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x0b] high edge lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x0c] high edge lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x0d] high edge lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x0e] high edge lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x0f] high edge lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x10] high edge lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x11] high edge lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x12] high edge lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x13] high edge lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x14] high edge lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x15] high edge lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x16] high edge lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x17] high edge lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x18] high edge lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x19] high edge lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x1a] high edge lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x1b] high edge lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x1c] high edge lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x1d] high edge lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x1e] high edge lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x1f] high edge lint[0x1])
[    0.000000] ACPI: IOAPIC (id[0x20] address[0xfec00000] gsi_base[0])
[    0.000000] IOAPIC[0]: apic_id 32, version 255, address 0xfec00000, GSI 0-255
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 high edge)
[    0.000000] Using ACPI (MADT) for SMP configuration information
[    0.000000] ACPI: HPET id: 0x8086af01 base: 0xfed00000
[    0.000000] SMP: Allowing 32 CPUs, 30 hotplug CPUs
[    0.000000] Allocating PCI resources starting at 40000000 (gap:
40000000:a0000000)
[    0.000000] Booting paravirtualized kernel on Xen
[    0.000000] Xen version: 4.1.2 (preserve-AD)
[    0.000000] setup_percpu: NR_CPUS:32 nr_cpumask_bits:32
nr_cpu_ids:32 nr_node_ids:1
[    0.000000] PERCPU: Embedded 23 pages/cpu @ffff88003ae91000 s62912
r8192 d23104 u94208
[    0.969940] Built 1 zonelists in Zone order, mobility grouping on.
Total pages: 247377
[    0.969947] Kernel command line: alpine_dev=UUID=4EF4-5EFD:vfat
modules=loop,squashfs,sd-mod,usb-storage
modloop=/boot/grsec.modloop.squashfs console=hvc0 earlyprintk=xen
nomodeset
[    0.970021] PID hash table entries: 4096 (order: 3, 32768 bytes)
[    0.970140] Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes)
[    0.970258] Inode-cache hash table entries: 65536 (order: 7, 524288 bytes)
[    1.281122] Placing 64MB software IO TLB between ffff880035600000 -
ffff880039600000
[    1.281132] software IO TLB at phys 0x35600000 - 0x39600000
[    1.288058] Memory: 853380k/4274492k available (2757k kernel code,
3226520k absent, 194592k reserved, 2029k data, 504k init)
[    1.288176] SLUB: Genslabs=15, HWalign=64, Order=0-3, MinObjects=0,
CPUs=32, Nodes=1
[    1.288337] Hierarchical RCU implementation.
[    1.288342] 	CONFIG_RCU_FANOUT set to non-default value of 32
[    1.288346] 	RCU dyntick-idle grace-period acceleration is enabled.
[    1.288361] NR_IRQS:1280
[    1.291189] xen: sci override: global_irq=9 trigger=0 polarity=1
[    1.291305] xen: acpi sci 9
[    1.291378] xen_map_pirq_gsi: returning irq 9 for gsi 9
[    1.291561] Console: colour VGA+ 80x25
[    1.695888] console [hvc0] enabled
[    1.697085] installing Xen timer for CPU 0
[    1.697249] Detected 2123.192 MHz processor.
[    1.697376] Calibrating delay loop (skipped), value calculated
using timer frequency.. 4248.31 BogoMIPS (lpj=7077306)
[    1.700865] pid_max: default: 32768 minimum: 501
[    1.701150] Security Framework initialized
[    1.701268] Mount-cache hash table entries: 256
[    1.703780] Initializing cgroup subsys cpuacct
[    1.704696] Initializing cgroup subsys devices
[    1.706060] Initializing cgroup subsys freezer
[    1.706178] Initializing cgroup subsys blkio
[    1.706297] Disabled fast string operations
[    1.708319] SMP alternatives: switching to UP code
[    1.716227] Freeing SMP alternatives: 20k freed
[    1.716345] ACPI: Core revision 20110413
[    1.726738] Performance Events: unsupported p6 CPU model 23 no PMU
driver, software events only.
[    1.730340] Brought up 1 CPUs
[    1.731295] Grant table initialized
[    1.731701] print_constraints: dummy:
[    1.731819] NET: Registered protocol family 16
[    1.734499] ACPI: bus type pci registered
[    1.736933] PCI: MMCONFIG for domain 0000 [bus 00-ff] at [mem
0xe0000000-0xefffffff] (base 0xe0000000)
[    1.737269] PCI: MMCONFIG at [mem 0xe0000000-0xefffffff] reserved in E820
[    1.938462] PCI: Using configuration type 1 for base access
[    1.943498] bio: create slab <bio-0> at 0
[    1.959065] [Firmware Bug]: ACPI: BIOS _OSI(Linux) query ignored
[    1.969392] ACPI: Interpreter enabled
[    1.969471] ACPI: (supports S0 S1 S5)
[    1.969551] ACPI: Using IOAPIC for interrupt routing
[    2.022004] ACPI: No dock devices found.
[    2.022083] HEST: Table not found.
[    2.022163] PCI: Using host bridge windows from ACPI; if necessary,
use "pci=nocrs" and report a bug
[    2.022379] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff])
[    2.022589] pci_root PNP0A03:00: host bridge window [mem
0x000a0000-0x000bffff]
[    2.022669] pci_root PNP0A03:00: host bridge window [mem
0x000cc000-0x000cffff]
[    2.022749] pci_root PNP0A03:00: host bridge window [mem
0x000d0000-0x000d3fff]
[    2.022828] pci_root PNP0A03:00: host bridge window [mem
0x000d4000-0x000d7fff]
[    2.025872] pci_root PNP0A03:00: host bridge window [mem
0x000d8000-0x000dbfff]
[    2.028344] pci_root PNP0A03:00: host bridge window [mem
0xc0000000-0xfebfffff]
[    2.028423] pci_root PNP0A03:00: host bridge window [io  0x0000-0x0cf7]
[    2.028503] pci_root PNP0A03:00: host bridge window [io  0x0d00-0xfeff]
[    2.036122] pci 0000:00:07.3: quirk: [io  0x1000-0x103f] claimed by
PIIX4 ACPI
[    2.042328] pci 0000:00:07.3: quirk: [io  0x1040-0x104f] claimed by PIIX4 SMB
[    2.061249] pci 0000:00:01.0: PCI bridge to [bus 01-01]
[    2.067647] pci 0000:00:11.0: PCI bridge to [bus 02-02] (subtractive decode)
[    2.067983] pci 0000:00:15.0: PCI bridge to [bus 03-03]
[    2.068301] pci 0000:00:15.1: PCI bridge to [bus 04-04]
[    2.068598] pci 0000:00:15.2: PCI bridge to [bus 05-05]
[    2.073083] pci 0000:00:15.3: PCI bridge to [bus 06-06]
[    2.073363] pci 0000:00:15.4: PCI bridge to [bus 07-07]
[    2.073660] pci 0000:00:15.5: PCI bridge to [bus 08-08]
[    2.073941] pci 0000:00:15.6: PCI bridge to [bus 09-09]
[    2.074259] pci 0000:00:15.7: PCI bridge to [bus 0a-0a]
[    2.074540] pci 0000:00:16.0: PCI bridge to [bus 0b-0b]
[    2.074821] pci 0000:00:16.1: PCI bridge to [bus 0c-0c]
[    2.075116] pci 0000:00:16.2: PCI bridge to [bus 0d-0d]
[    2.075434] pci 0000:00:16.3: PCI bridge to [bus 0e-0e]
[    2.075717] pci 0000:00:16.4: PCI bridge to [bus 0f-0f]
[    2.076131] pci 0000:00:16.5: PCI bridge to [bus 10-10]
[    2.076412] pci 0000:00:16.6: PCI bridge to [bus 11-11]
[    2.076693] pci 0000:00:16.7: PCI bridge to [bus 12-12]
[    2.076976] pci 0000:00:17.0: PCI bridge to [bus 13-13]
[    2.077257] pci 0000:00:17.1: PCI bridge to [bus 14-14]
[    2.077573] pci 0000:00:17.2: PCI bridge to [bus 15-15]
[    2.079803] pci 0000:00:17.3: PCI bridge to [bus 16-16]
[    2.080100] pci 0000:00:17.4: PCI bridge to [bus 17-17]
[    2.080396] pci 0000:00:17.5: PCI bridge to [bus 18-18]
[    2.082988] pci 0000:00:17.6: PCI bridge to [bus 19-19]
[    2.083269] pci 0000:00:17.7: PCI bridge to [bus 1a-1a]
[    2.083551] pci 0000:00:18.0: PCI bridge to [bus 1b-1b]
[    2.083831] pci 0000:00:18.1: PCI bridge to [bus 1c-1c]
[    2.084113] pci 0000:00:18.2: PCI bridge to [bus 1d-1d]
[    2.084395] pci 0000:00:18.3: PCI bridge to [bus 1e-1e]
[    2.084678] pci 0000:00:18.4: PCI bridge to [bus 1f-1f]
[    2.084960] pci 0000:00:18.5: PCI bridge to [bus 20-20]
[    2.085244] pci 0000:00:18.6: PCI bridge to [bus 21-21]
[    2.085525] pci 0000:00:18.7: PCI bridge to [bus 22-22]
[    2.088738]  pci0000:00: Requesting ACPI _OSC control (0x15)
[    2.088818]  pci0000:00: ACPI _OSC control (0x15) granted
[    2.216629] ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 *9 10 11 14 15)
[    2.218708] ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 9 10 *11 14 15)
[    2.219072] ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 7 9 *10 11 14 15)
[    2.223302] ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 *5 6 7 9 10 11 14 15)
[    2.224412] xen/balloon: Initialising balloon driver.
[    2.224492] last_pfn = 0x104e4f max_arch_pfn = 0x400000000
[    2.224706] xen-balloon: Initialising balloon driver.
[    2.225402] PCI: Using ACPI for IRQ routing
[    2.345078] pci 0000:00:18.2: no compatible bridge window for [io
0xf000-0xffff]
[    2.345591] NetLabel: Initializing
[    2.345642] NetLabel:  domain hash size = 128
[    2.345694] NetLabel:  protocols = UNLABELED CIPSOv4
[    2.345745] NetLabel:  unlabeled traffic allowed by default
[    2.345797] Switching to clocksource xen
[    2.349081] pnp: PnP ACPI init
[    2.349132] ACPI: bus type pnp registered
[    2.349638] system 00:01: [io  0x1000-0x103f] has been reserved
[    2.352559] system 00:01: [io  0x1040-0x104f] has been reserved
[    2.355262] system 00:01: [io  0x0cf0-0x0cf1] has been reserved
[    2.355434] Switched to NOHz mode on CPU #0
[    2.356377] xen_map_pirq_gsi: returning irq 8 for gsi 8
[    2.359772] xen_map_pirq_gsi: returning irq 1 for gsi 1
[    2.365621] xen_map_pirq_gsi: returning irq 12 for gsi 12
[    2.366304] system 00:08: [mem 0xfed00000-0xfed003ff] has been reserved
[    2.386110] xen_map_pirq_gsi: returning irq 7 for gsi 7
[    2.386645] xen_map_pirq_gsi: returning irq 4 for gsi 4
[    2.389635] xen_map_pirq_gsi: returning irq 3 for gsi 3
[    2.389694] Already setup the GSI :3
[    2.392747] xen_map_pirq_gsi: returning irq 6 for gsi 6
[    2.396135] system 00:0d: [io  0x1060-0x107f] has been reserved
[    2.396187] system 00:0d: [mem 0xe0000000-0xefffffff] has been reserved
[    2.396238] system 00:0d: [mem 0xc8200000-0xc83fffff] has been reserved
[    2.405821] pnp: PnP ACPI: found 14 devices
[    2.405872] ACPI: ACPI bus type pnp unregistered
[    2.425809] PM-Timer failed consistency check  (0x0xffffff) - aborting.
[    2.429116] pci 0000:00:0f.0: BAR 6: assigned [mem
0xc0000000-0xc0007fff pref]
[    2.429168] pci 0000:00:10.0: BAR 6: assigned [mem
0xc0008000-0xc000bfff pref]
[    2.429220] pci 0000:00:18.7: BAR 7: can't assign io (size 0x1000)
[    2.429271] pci 0000:00:18.6: BAR 7: can't assign io (size 0x1000)
[    2.429323] pci 0000:00:18.5: BAR 7: can't assign io (size 0x1000)
[    2.429374] pci 0000:00:18.4: BAR 7: can't assign io (size 0x1000)
[    2.429426] pci 0000:00:18.3: BAR 7: can't assign io (size 0x1000)
[    2.429478] pci 0000:00:18.2: BAR 7: can't assign io (size 0x1000)
[    2.429529] pci 0000:00:17.7: BAR 7: can't assign io (size 0x1000)
[    2.429581] pci 0000:00:17.6: BAR 7: can't assign io (size 0x1000)
[    2.429632] pci 0000:00:17.5: BAR 7: can't assign io (size 0x1000)
[    2.429684] pci 0000:00:17.4: BAR 7: can't assign io (size 0x1000)
[    2.429735] pci 0000:00:17.3: BAR 7: can't assign io (size 0x1000)
[    2.429787] pci 0000:00:16.7: BAR 7: can't assign io (size 0x1000)
[    2.429839] pci 0000:00:16.6: BAR 7: can't assign io (size 0x1000)
[    2.429890] pci 0000:00:16.5: BAR 7: can't assign io (size 0x1000)
[    2.429942] pci 0000:00:16.4: BAR 7: can't assign io (size 0x1000)
[    2.429993] pci 0000:00:16.3: BAR 7: can't assign io (size 0x1000)
[    2.430045] pci 0000:00:15.7: BAR 7: can't assign io (size 0x1000)
[    2.430097] pci 0000:00:15.6: BAR 7: can't assign io (size 0x1000)
[    2.430148] pci 0000:00:15.5: BAR 7: can't assign io (size 0x1000)
[    2.430200] pci 0000:00:15.4: BAR 7: can't assign io (size 0x1000)
[    2.430251] pci 0000:00:15.3: BAR 7: can't assign io (size 0x1000)
[    2.430303] pci 0000:00:01.0: PCI bridge to [bus 01-01]
[    2.430354] pci 0000:00:01.0:   bridge window [io  disabled]
[    2.430406] pci 0000:00:01.0:   bridge window [mem disabled]
[    2.430458] pci 0000:00:01.0:   bridge window [mem pref disabled]
[    2.430509] pci 0000:02:01.0: BAR 6: assigned [mem
0xd8400000-0xd840ffff pref]
[    2.430561] pci 0000:00:11.0: PCI bridge to [bus 02-02]
[    2.430612] pci 0000:00:11.0:   bridge window [io  0x2000-0x3fff]
[    2.430664] pci 0000:00:11.0:   bridge window [mem 0xc9000000-0xca3fffff]
[    2.430716] pci 0000:00:11.0:   bridge window [mem
0xd8400000-0xd89fffff 64bit pref]
[    2.430767] pci 0000:00:15.0: PCI bridge to [bus 03-03]
[    2.430819] pci 0000:00:15.0:   bridge window [io  0x4000-0x4fff]
[    2.430870] pci 0000:00:15.0:   bridge window [mem 0xca400000-0xca4fffff]
[    2.430922] pci 0000:00:15.0:   bridge window [mem
0xd8a00000-0xd8afffff 64bit pref]
[    2.430973] pci 0000:00:15.1: PCI bridge to [bus 04-04]
[    2.431025] pci 0000:00:15.1:   bridge window [io  0x8000-0x8fff]
[    2.431077] pci 0000:00:15.1:   bridge window [mem 0xca800000-0xca8fffff]
[    2.431180] pci 0000:00:15.1:   bridge window [mem
0xd8e00000-0xd8efffff 64bit pref]
[    2.431231] pci 0000:00:15.2: PCI bridge to [bus 05-05]
[    2.431283] pci 0000:00:15.2:   bridge window [io  0xc000-0xcfff]
[    2.431335] pci 0000:00:15.2:   bridge window [mem 0xcac00000-0xcacfffff]
[    2.431386] pci 0000:00:15.2:   bridge window [mem
0xd9200000-0xd92fffff 64bit pref]
[    2.431438] pci 0000:00:15.3: PCI bridge to [bus 06-06]
[    2.435798] pci 0000:00:15.3:   bridge window [io  disabled]
[    2.435849] pci 0000:00:15.3:   bridge window [mem 0xcb000000-0xcb0fffff]
[    2.435901] pci 0000:00:15.3:   bridge window [mem
0xd9600000-0xd96fffff 64bit pref]
[    2.435952] pci 0000:00:15.4: PCI bridge to [bus 07-07]
[    2.436004] pci 0000:00:15.4:   bridge window [io  disabled]
[    2.436056] pci 0000:00:15.4:   bridge window [mem 0xcb400000-0xcb4fffff]
[    2.436107] pci 0000:00:15.4:   bridge window [mem
0xd9a00000-0xd9afffff 64bit pref]
[    2.436159] pci 0000:00:15.5: PCI bridge to [bus 08-08]
[    2.436210] pci 0000:00:15.5:   bridge window [io  disabled]
[    2.436262] pci 0000:00:15.5:   bridge window [mem 0xcb800000-0xcb8fffff]
[    2.436314] pci 0000:00:15.5:   bridge window [mem
0xd9e00000-0xd9efffff 64bit pref]
[    2.436365] pci 0000:00:15.6: PCI bridge to [bus 09-09]
[    2.436417] pci 0000:00:15.6:   bridge window [io  disabled]
[    2.436468] pci 0000:00:15.6:   bridge window [mem 0xcbc00000-0xcbcfffff]
[    2.436520] pci 0000:00:15.6:   bridge window [mem
0xda200000-0xda2fffff 64bit pref]
[    2.436571] pci 0000:00:15.7: PCI bridge to [bus 0a-0a]
[    2.436623] pci 0000:00:15.7:   bridge window [io  disabled]
[    2.436675] pci 0000:00:15.7:   bridge window [mem 0xcc000000-0xcc0fffff]
[    2.436726] pci 0000:00:15.7:   bridge window [mem
0xda600000-0xda6fffff 64bit pref]
[    2.436778] pci 0000:00:16.0: PCI bridge to [bus 0b-0b]
[    2.436829] pci 0000:00:16.0:   bridge window [io  0x5000-0x5fff]
[    2.436881] pci 0000:00:16.0:   bridge window [mem 0xca500000-0xca5fffff]
[    2.436933] pci 0000:00:16.0:   bridge window [mem
0xd8b00000-0xd8bfffff 64bit pref]
[    2.436984] pci 0000:00:16.1: PCI bridge to [bus 0c-0c]
[    2.437036] pci 0000:00:16.1:   bridge window [io  0x9000-0x9fff]
[    2.437087] pci 0000:00:16.1:   bridge window [mem 0xca900000-0xca9fffff]
[    2.437139] pci 0000:00:16.1:   bridge window [mem
0xd8f00000-0xd8ffffff 64bit pref]
[    2.437190] pci 0000:00:16.2: PCI bridge to [bus 0d-0d]
[    2.437242] pci 0000:00:16.2:   bridge window [io  0xd000-0xdfff]
[    2.437294] pci 0000:00:16.2:   bridge window [mem 0xcad00000-0xcadfffff]
[    2.437345] pci 0000:00:16.2:   bridge window [mem
0xd9300000-0xd93fffff 64bit pref]
[    2.437397] pci 0000:00:16.3: PCI bridge to [bus 0e-0e]
[    2.437448] pci 0000:00:16.3:   bridge window [io  disabled]
[    2.437500] pci 0000:00:16.3:   bridge window [mem 0xcb100000-0xcb1fffff]
[    2.437552] pci 0000:00:16.3:   bridge window [mem
0xd9700000-0xd97fffff 64bit pref]
[    2.437603] pci 0000:00:16.4: PCI bridge to [bus 0f-0f]
[    2.437655] pci 0000:00:16.4:   bridge window [io  disabled]
[    2.437706] pci 0000:00:16.4:   bridge window [mem 0xcb500000-0xcb5fffff]
[    2.437758] pci 0000:00:16.4:   bridge window [mem
0xd9b00000-0xd9bfffff 64bit pref]
[    2.437809] pci 0000:00:16.5: PCI bridge to [bus 10-10]
[    2.437861] pci 0000:00:16.5:   bridge window [io  disabled]
[    2.437913] pci 0000:00:16.5:   bridge window [mem 0xcb900000-0xcb9fffff]
[    2.437964] pci 0000:00:16.5:   bridge window [mem
0xd9f00000-0xd9ffffff 64bit pref]
[    2.438016] pci 0000:00:16.6: PCI bridge to [bus 11-11]
[    2.438067] pci 0000:00:16.6:   bridge window [io  disabled]
[    2.438119] pci 0000:00:16.6:   bridge window [mem 0xcbd00000-0xcbdfffff]
[    2.438171] pci 0000:00:16.6:   bridge window [mem
0xda300000-0xda3fffff 64bit pref]
[    2.438222] pci 0000:00:16.7: PCI bridge to [bus 12-12]
[    2.438274] pci 0000:00:16.7:   bridge window [io  disabled]
[    2.438325] pci 0000:00:16.7:   bridge window [mem 0xcc100000-0xcc1fffff]
[    2.438377] pci 0000:00:16.7:   bridge window [mem
0xda700000-0xda7fffff 64bit pref]
[    2.438428] pci 0000:00:17.0: PCI bridge to [bus 13-13]
[    2.438480] pci 0000:00:17.0:   bridge window [io  0x6000-0x6fff]
[    2.438532] pci 0000:00:17.0:   bridge window [mem 0xca600000-0xca6fffff]
[    2.438583] pci 0000:00:17.0:   bridge window [mem
0xd8c00000-0xd8cfffff 64bit pref]
[    2.438635] pci 0000:00:17.1: PCI bridge to [bus 14-14]
[    2.438686] pci 0000:00:17.1:   bridge window [io  0xa000-0xafff]
[    2.438738] pci 0000:00:17.1:   bridge window [mem 0xcaa00000-0xcaafffff]
[    2.438790] pci 0000:00:17.1:   bridge window [mem
0xd9000000-0xd90fffff 64bit pref]
[    2.438841] pci 0000:00:17.2: PCI bridge to [bus 15-15]
[    2.438893] pci 0000:00:17.2:   bridge window [io  0xe000-0xefff]
[    2.438944] pci 0000:00:17.2:   bridge window [mem 0xcae00000-0xcaefffff]
[    2.446013] pci 0000:00:17.2:   bridge window [mem
0xd9400000-0xd94fffff 64bit pref]
[    2.446065] pci 0000:00:17.3: PCI bridge to [bus 16-16]
[    2.446116] pci 0000:00:17.3:   bridge window [io  disabled]
[    2.446168] pci 0000:00:17.3:   bridge window [mem 0xcb200000-0xcb2fffff]
[    2.449249] pci 0000:00:17.3:   bridge window [mem
0xd9800000-0xd98fffff 64bit pref]
[    2.449946] pci 0000:00:17.4: PCI bridge to [bus 17-17]
[    2.449998] pci 0000:00:17.4:   bridge window [io  disabled]
[    2.450049] pci 0000:00:17.4:   bridge window [mem 0xcb600000-0xcb6fffff]
[    2.450101] pci 0000:00:17.4:   bridge window [mem
0xd9c00000-0xd9cfffff 64bit pref]
[    2.450153] pci 0000:00:17.5: PCI bridge to [bus 18-18]
[    2.450204] pci 0000:00:17.5:   bridge window [io  disabled]
[    2.450256] pci 0000:00:17.5:   bridge window [mem 0xcba00000-0xcbafffff]
[    2.450307] pci 0000:00:17.5:   bridge window [mem
0xda000000-0xda0fffff 64bit pref]
[    2.450359] pci 0000:00:17.6: PCI bridge to [bus 19-19]
[    2.450410] pci 0000:00:17.6:   bridge window [io  disabled]
[    2.450462] pci 0000:00:17.6:   bridge window [mem 0xcbe00000-0xcbefffff]
[    2.450514] pci 0000:00:17.6:   bridge window [mem
0xda400000-0xda4fffff 64bit pref]
[    2.450565] pci 0000:00:17.7: PCI bridge to [bus 1a-1a]
[    2.450617] pci 0000:00:17.7:   bridge window [io  disabled]
[    2.450668] pci 0000:00:17.7:   bridge window [mem 0xcc200000-0xcc2fffff]
[    2.450720] pci 0000:00:17.7:   bridge window [mem
0xda800000-0xda8fffff 64bit pref]
[    2.450772] pci 0000:00:18.0: PCI bridge to [bus 1b-1b]
[    2.450823] pci 0000:00:18.0:   bridge window [io  0x7000-0x7fff]
[    2.450875] pci 0000:00:18.0:   bridge window [mem 0xca700000-0xca7fffff]
[    2.450926] pci 0000:00:18.0:   bridge window [mem
0xd8d00000-0xd8dfffff 64bit pref]
[    2.450978] pci 0000:00:18.1: PCI bridge to [bus 1c-1c]
[    2.451029] pci 0000:00:18.1:   bridge window [io  0xb000-0xbfff]
[    2.451081] pci 0000:00:18.1:   bridge window [mem 0xcab00000-0xcabfffff]
[    2.451133] pci 0000:00:18.1:   bridge window [mem
0xd9100000-0xd91fffff 64bit pref]
[    2.451184] pci 0000:00:18.2: PCI bridge to [bus 1d-1d]
[    2.451236] pci 0000:00:18.2:   bridge window [io  disabled]
[    2.451287] pci 0000:00:18.2:   bridge window [mem 0xcaf00000-0xcaffffff]
[    2.451339] pci 0000:00:18.2:   bridge window [mem
0xd9500000-0xd95fffff 64bit pref]
[    2.451391] pci 0000:00:18.3: PCI bridge to [bus 1e-1e]
[    2.451442] pci 0000:00:18.3:   bridge window [io  disabled]
[    2.451494] pci 0000:00:18.3:   bridge window [mem 0xcb300000-0xcb3fffff]
[    2.451545] pci 0000:00:18.3:   bridge window [mem
0xd9900000-0xd99fffff 64bit pref]
[    2.451597] pci 0000:00:18.4: PCI bridge to [bus 1f-1f]
[    2.451648] pci 0000:00:18.4:   bridge window [io  disabled]
[    2.451700] pci 0000:00:18.4:   bridge window [mem 0xcb700000-0xcb7fffff]
[    2.451752] pci 0000:00:18.4:   bridge window [mem
0xd9d00000-0xd9dfffff 64bit pref]
[    2.451803] pci 0000:00:18.5: PCI bridge to [bus 20-20]
[    2.451855] pci 0000:00:18.5:   bridge window [io  disabled]
[    2.451906] pci 0000:00:18.5:   bridge window [mem 0xcbb00000-0xcbbfffff]
[    2.451958] pci 0000:00:18.5:   bridge window [mem
0xda100000-0xda1fffff 64bit pref]
[    2.452010] pci 0000:00:18.6: PCI bridge to [bus 21-21]
[    2.452061] pci 0000:00:18.6:   bridge window [io  disabled]
[    2.452113] pci 0000:00:18.6:   bridge window [mem 0xcbf00000-0xcbffffff]
[    2.456092] pci 0000:00:18.6:   bridge window [mem
0xda500000-0xda5fffff 64bit pref]
[    2.456144] pci 0000:00:18.7: PCI bridge to [bus 22-22]
[    2.456196] pci 0000:00:18.7:   bridge window [io  disabled]
[    2.456247] pci 0000:00:18.7:   bridge window [mem 0xcc300000-0xcc3fffff]
[    2.456299] pci 0000:00:18.7:   bridge window [mem
0xda900000-0xda9fffff 64bit pref]
[    2.458674] NET: Registered protocol family 2
[    2.459274] IP route cache hash table entries: 32768 (order: 6, 262144 bytes)
[    2.459435] TCP established hash table entries: 131072 (order: 9,
2097152 bytes)
[    2.465816] TCP bind hash table entries: 65536 (order: 8, 1048576 bytes)
[    2.466350] TCP: Hash tables configured (established 131072 bind 65536)
[    2.466401] TCP reno registered
[    2.466453] UDP hash table entries: 512 (order: 2, 16384 bytes)
[    2.466505] UDP-Lite hash table entries: 512 (order: 2, 16384 bytes)
[    2.466663] NET: Registered protocol family 1
[    2.466715] pci 0000:00:00.0: Limiting direct PCI/PCI transfers
[    2.469579] Trying to unpack rootfs image as initramfs...
[    2.576590] Freeing initrd memory: 17624k freed
[    2.592556] Simple Boot Flag at 0x36 set to 0x80
[    2.602854] VFS: Disk quotas dquot_6.5.2
[    2.602906] Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
[    2.605963] msgmni has been set to 1701
[    2.607923] Block layer SCSI generic (bsg) driver version 0.4
loaded (major 253)
[    2.609291] io scheduler noop registered
[    2.609343] io scheduler cfq registered (default)
[    2.623994] ERST: Table is not found!
[    2.624274] Event-channel device installed.
[    2.626858] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
[    2.660523] serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
[    2.688257] 00:0a: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
[    2.691245] hpet_acpi_add: no address or irqs in _CRS
[    2.701948] brd: module loaded
[    2.702940] i8042: PNP: PS/2 Controller [PNP0303:KBC,PNP0f13:MOUS]
at 0x60,0x64 irq 1,12
[    3.265863] serio: i8042 KBD port at 0x60,0x64 irq 1
[    3.267036] serio: i8042 AUX port at 0x60,0x64 irq 12
[    3.288259] rtc_cmos 00:04: rtc core: registered rtc_cmos as rtc0
[    3.289657] rtc0: alarms up to one month, y3k, 114 bytes nvram
[    3.291303] cpuidle: using governor ladder
[    3.292326] cpuidle: using governor menu
[    3.293337] GRE over IPv4 demultiplexor driver
[    3.293425] TCP cubic registered
[    3.293514] Registering the dns_resolver key type
[    3.299454] input: AT Translated Set 2 keyboard as
/devices/platform/i8042/serio0/input/input0
[    3.300116] rtc_cmos 00:04: setting system clock to 2011-12-24
11:55:32 UTC (1324727732)
[    3.302590] Freeing unused kernel memory: 504k freed
Alpine Init 2.4.2-r0
 * Starting mdev: ok.
 * Loading boot drivers: [    3.482784] loop: module loaded
[    3.489387] squashfs: version 4.0 (2009/01/31) Phillip Lougher
[    3.509343] SCSI subsystem initialized
[    3.535656] usbcore: registered new interface driver usbfs
[    3.543178] usbcore: registered new interface driver hub
[    3.549401] usbcore: registered new device driver usb
[    3.559302] usbcore: registered new interface driver libusual
[    3.569475] Initializing USB Mass Storage driver...
[    3.579155] usbcore: registered new interface driver usb-storage
[    3.582583] USB Mass Storage support registered.
[    3.715956] Floppy drive(s): fd0 is 1.44M
[    3.729542] FDC 0 is a post-1991 82077
[    3.744726] Fusion MPT base driver 3.04.19
[    3.745877] Copyright (c) 1999-2008 LSI Corporation
[    3.752729] Fusion MPT SPI Host driver 3.04.19
[    3.759153] mptspi 0000:00:10.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
[    3.759628] mptbase: ioc0: Initiating bringup
[    3.819265] ioc0: LSI53C1030 B0: Capabilities={Initiator}
[    3.953518] scsi0 : ioc0: LSI53C1030 B0, FwRev=01032920h, Ports=1,
MaxQ=128, IRQ=17
[    4.056224] scsi 0:0:0:0: Direct-Access     VMware,  VMware Virtual
S 1.0  PQ: 0 ANSI: 2
[    4.062443] scsi target0:0:0: Beginning Domain Validation
[    4.066185] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[    4.067178] xen_map_pirq_gsi: returning irq 17 for gsi 17
[    4.069313] Already setup the GSI :17
[    4.070740] ehci_hcd 0000:02:03.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
[    4.073792] ehci_hcd 0000:02:03.0: EHCI Host Controller
[    4.083639] scsi target0:0:0: Domain Validation skipping write tests
[    4.085899] scsi target0:0:0: Ending Domain Validation
[    4.091191] ehci_hcd 0000:02:03.0: new USB bus registered, assigned
bus number 1
[    4.092669] ehci_hcd 0000:02:03.0: irq 17, io mem 0xc9010000
[    4.097824] scsi target0:0:0: FAST-40 WIDE SCSI 80.0 MB/s ST (25
ns, offset 127)
[    4.099387] scsi: killing requests for dead queue
[    4.101385] scsi: killing requests for dead queue
[    4.103979] ehci_hcd 0000:02:03.0: USB 2.0 started, EHCI 1.00
[    4.105974] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
[    4.109224] usb usb1: New USB device strings: Mfr=3, Product=2,
SerialNumber=1
[    4.111473] usb usb1: Product: EHCI Host Controller
[    4.111506] usb usb1: Manufacturer: Linux 3.0.10-grsec ehci_hcd
[    4.111539] usb usb1: SerialNumber: 0000:02:03.0
[    4.111757] scsi: killing requests for dead queue
[    4.113136] scsi: killing requests for dead queue
[    4.114438] scsi: killing requests for dead queue
[    4.116253] scsi: killing requests for dead queue
[    4.117821] scsi: killing requests for dead queue
[    4.122604] scsi: killing requests for dead queue
[    4.126040] hub 1-0:1.0: USB hub found
[    4.126073] hub 1-0:1.0: 6 ports detected
[    4.139315] scsi: killing requests for dead queue
[    4.142064] scsi: killing requests for dead queue
[    4.143436] uhci_hcd: USB Universal Host Controller Interface driver
[    4.146357] uhci_hcd 0000:02:00.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18
[    4.152099] uhci_hcd 0000:02:00.0: UHCI Host Controller
[    4.152132] uhci_hcd 0000:02:00.0: new USB bus registered, assigned
bus number 2
[    4.158260] scsi: killing requests for dead queue
[    4.159641] scsi: killing requests for dead queue
[    4.160865] scsi: killing requests for dead queue
[    4.165792] uhci_hcd 0000:02:00.0: irq 18, io base 0x00002080
[    4.165825] usb usb2: New USB device found, idVendor=1d6b, idProduct=0001
[    4.169141] usb usb2: New USB device strings: Mfr=3, Product=2,
SerialNumber=1
[    4.169174] usb usb2: Product: UHCI Host Controller
[    4.172529] usb usb2: Manufacturer: Linux 3.0.10-grsec uhci_hcd
[    4.172562] usb usb2: SerialNumber: 0000:02:00.0
[    4.172927] scsi: killing requests for dead queue
[    4.174239] scsi: killing requests for dead queue
[    4.195935] hub 2-0:1.0: USB hub found
[    4.195968] hub 2-0:1.0: 2 ports detected
[    4.203022] sd 0:0:0:0: [sda] 16777216 512-byte logical blocks:
(8.58 GB/8.00 GiB)
[    4.206046] sd 0:0:0:0: [sda] Write Protect is off
[    4.207352] sd 0:0:0:0: [sda] Cache data unavailable
[    4.208560] sd 0:0:0:0: [sda] Assuming drive cache: write through
[    4.226139] sd 0:0:0:0: [sda] Cache data unavailable
[    4.227275] sd 0:0:0:0: [sda] Assuming drive cache: write through
[    4.236917]  sda: sda1 sda2 sda3
[    4.256216] sd 0:0:0:0: [sda] Cache data unavailable
[    4.257412] sd 0:0:0:0: [sda] Assuming drive cache: write through
[    4.257445] sd 0:0:0:0: [sda] Attached SCSI disk
[    4.389147] scsi1 : ata_piix
[    4.402479] scsi2 : ata_piix
[    4.417344] ata1: PATA max UDMA/33 cmd 0x1f0 ctl 0x3f6 bmdma 0x10c0 irq 14
[    4.419236] ata2: PATA max UDMA/33 cmd 0x170 ctl 0x376 bmdma 0x10c8 irq 15
[    4.432472] usb 1-1: new high speed USB device number 2 using ehci_hcd
[    4.662732] ata2.00: ATAPI: VMware Virtual IDE CDROM Drive,
00000001, max UDMA/33
[    4.679306] ata2.00: configured for UDMA/33
[    4.680353] scsi 2:0:0:0: CD-ROM            NECVMWar VMware IDE
CDR10 1.00 PQ: 0 ANSI: 5
[    4.803876] usb 1-1: New USB device found, idVendor=05ac, idProduct=8403
[    4.807533] usb 1-1: New USB device strings: Mfr=3, Product=4, SerialNumber=2
[    4.808425] usb 1-1: Product: Card Reader
[    4.808465] usb 1-1: Manufacturer: Apple
[    4.812250] usb 1-1: SerialNumber: 000000009833
[    4.833476] sr0: scsi3-mmc drive: 1x/1x writer dvd-ram cd/rw
xa/form2 cdda tray
[    4.835956] cdrom: Uniform CD-ROM driver Revision: 3.20
[    4.842435] scsi3 : usb-storage 1-1:1.0
ok.
 * Setting up framebuffer console: ok.
 * Mounting boot media: [    4.972499] usb 2-1: new full speed USB
device number 2 using uhci_hcd
[    5.108156] usb 2-1: New USB device found, idVendor=0e0f, idProduct=0003
[    5.111553] usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[    5.114070] usb 2-1: Product: VMware Virtual USB Mouse
[    5.115337] usb 2-1: Manufacturer: VMware
[    5.229114] usb 2-2: new full speed USB device number 3 using uhci_hcd
[    5.358748] usb 2-2: New USB device found, idVendor=0e0f, idProduct=0002
[    5.361617] usb 2-2: New USB device strings: Mfr=0, Product=1, SerialNumber=0
[    5.365356] usb 2-2: Product: VMware Virtual USB Hub
[    5.369735] hub 2-2:1.0: USB hub found
[    5.371020] hub 2-2:1.0: 7 ports detected
[    5.646073] usb 2-2.1: new full speed USB device number 4 using uhci_hcd
[    5.741642] usb 2-2.1: New USB device found, idVendor=0e0f, idProduct=0008
[    5.743733] usb 2-2.1: New USB device strings: Mfr=1, Product=2,
SerialNumber=3
[    5.746592] usb 2-2.1: Product: Virtual Bluetooth Adapter
[    5.749742] usb 2-2.1: Manufacturer: VMware
[    5.749747] usb 2-2.1: SerialNumber: 000650268328
[    5.859651] scsi 3:0:0:0: Direct-Access     APPLE    SD Card Reader
  1.00 PQ: 0 ANSI: 0
[    5.859740] scsi: killing requests for dead queue
[    5.859814] scsi: killing requests for dead queue
[    5.862242] scsi: killing requests for dead queue
[    5.862703] scsi: killing requests for dead queue
[    5.862779] scsi: killing requests for dead queue
[    5.862852] scsi: killing requests for dead queue
[    5.867651] scsi: killing requests for dead queue
[    5.872527] scsi: killing requests for dead queue
[    5.943255] sd 3:0:0:0: [sdb] 15548416 512-byte logical blocks:
(7.96 GB/7.41 GiB)
[    5.948616] sd 3:0:0:0: [sdb] Write Protect is off
[    5.954270] sd 3:0:0:0: [sdb] No Caching mode page present
[    5.955902] sd 3:0:0:0: [sdb] Assuming drive cache: write through
[    5.967194] sd 3:0:0:0: [sdb] No Caching mode page present
[    5.969206] sd 3:0:0:0: [sdb] Assuming drive cache: write through
[    5.971050]  sdb: sdb1
[    5.985108] sd 3:0:0:0: [sdb] No Caching mode page present
[    5.991589] sd 3:0:0:0: [sdb] Assuming drive cache: write through
[    5.991625] sd 3:0:0:0: [sdb] Attached SCSI removable disk
ok.
 * Loading user settings from /media/usb/loki.apkovl.tar.gz: ok.
 * Installing packages to root filesystem:
ok.


   OpenRC 0.9.7.58f1ef2 is starting up Linux 3.0.10-grsec (x86_64) [XENU]

 * /proc is already mounted, skipping
 * Mounting /run ... [ ok ]
 * /run/lock: creating directory
 * Mounting xenfs ... [ ok ]
 * Caching service dependencies ... [ ok ]
 * Mounting security filesystem ... [ ok ]
 * Mounting debug filesystem ... [ ok ]
 * Mounting cgroup filesystem ... [ ok ]
 * creating openrc control group ... [ ok ]
 * Starting busybox mdev ... [ ok ]
 * /dev is already mounted
 * Starting udevd ... [ ok ]
 * Populating /dev with existing devices through uevents ... [ ok ]
 * Waiting for uevents to be processed ... [ ok ]
 * Mounting modloop /media/usb/boot/grsec.modloop.squashfs ... [ ok ]
 * Loading hardware drivers ...Loading acpi:ACPI0003:
Loading acpi:LNXCPU:
Loading acpi:LNXPWRBN:
[   23.080837] BUG: unable to handle kernel paging request at ffffe8ffffd3bfc4
[   23.087991] IP: [<ffffffff81062026>] module_refcount+0x2e/0x99
[   23.091743] PGD 351d6067 PUD 351d7067 PMD 35288067 PTE 0
[   23.094530] Oops: 0000 [#1] SMP
[   23.095852] CPU 0
[   23.096561] Modules linked in: processor ac nls_iso8859_1 nls_cp437
vfat fat sr_mod cdrom ata_generic ata_piix pata_acpi libata uhci_hcd
ehci_hcd mptspi mptscsih mptbase scsi_transport_spi floppy usb_storage
usb_libusual usbcore sd_mod scsi_mod squashfs loop
[   23.121165]
[   23.121801] Pid: 1626, comm: modprobe Not tainted 3.0.10-grsec
#1-Alpine VMware, Inc. VMware Virtual Platform/440BX Desktop Reference
Platform
[   23.128242] RIP: e030:[<ffffffff81062026>]  [<ffffffff81062026>]
module_refcount+0x2e/0x99
[   23.134994] RSP: e02b:ffff8800351ddd88  EFLAGS: 00010287
[   23.136997] RAX: 0000000000000001 RBX: 0000000000000001 RCX: ffff88003aea8000
[   23.140113] RDX: 000060ffc4e93fc0 RSI: 0000000000000020 RDI: 0000000000000020
[   23.143939] RBP: ffff8800351ddda8 R08: 0000000000000000 R09: ffffffff814aa520
[   23.146656] R10: ffff8800345d5000 R11: 0000000000000000 R12: ffffffff814aa520
[   23.149354] R13: ffffffffa014b7a0 R14: 0000000000001000 R15: ffffffffa014b968
[   23.157673] FS:  00005fb0175646a0(0000) GS:ffff88003ae91000(0000)
knlGS:0000000000000000
[   23.162354] CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
[   23.164736] CR2: ffffe8ffffd3bfc4 CR3: 00000000339b3000 CR4: 0000000000000660
[   23.167954] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[   23.170719] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[   23.174109] Process modprobe (pid: 1626, threadinfo
ffff88003477ab58, task ffff88003477a760)
[   23.178661] Stack:
[   23.179466]  ffffffffa014b7a8 ffff880034334300 ffffffffa014b7a0
0000000000001000
[   23.182787]  ffff8800351dddf8 ffffffff8106211c ffff880035300420
00005fb016cffd10
[   23.189494]  ffff8800351dddf8 ffff880034334300 0000000000000000
00000fecda0bcd90
[   23.198618] Call Trace:
[   23.200624]  [<ffffffff8106211c>] m_show+0x54/0x16b
[   23.202512]  [<ffffffff810d1b5c>] seq_read+0x247/0x51f
[   23.204483]  [<ffffffff810fccc2>] proc_reg_read+0x6c/0x85
[   23.206543]  [<ffffffff810b614f>] vfs_read+0x104/0x198
[   23.208909]  [<ffffffff810b6228>] sys_read+0x45/0x6c
[   23.211075]  [<ffffffff812aa14b>] system_call_fastpath+0x16/0x1b
[   23.215796]  [<ffffffff812aa0e9>] ? system_call_after_swapgs+0x19/0x65
[   23.219196] Code: ff 48 89 e5 41 56 41 55 49 89 fd 41 54 4c 8b 25
79 12 29 00 53 31 db eb 16 48 63 c8 49 8b 95 f8 01 00 00 48 8b 0c cd
50 60 3a 81
[   23.228774]  5c 0a 04 ff c0 be 20 00 00 00 4c 89 e7 48 63 d0 e8 34 24 0e
[   23.235223] RIP  [<ffffffff81062026>] module_refcount+0x2e/0x99
[   23.240718]  RSP <ffff8800351ddd88>
[   23.243912] CR2: ffffe8ffffd3bfc4
[   23.245256] ---[ end trace 4763addd9fb226e5 ]---
Killed
Loading acpi:LNXSYSTM:

I've changed the init script to load each module separatedly, instead
of doing a modprobe -a <all modules>, if I loaded all the modules at
once the system crashed instead of freezing. The problem seems to be
related to acpi, and the modules are loaded from a squashfs image
mounted on loop0. Does anyone know what might be causing this issue or
if there is a possible fix?

Thanks, Roger.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Dec 24 11:09:45 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 24 Dec 2011 11:09:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RePT8-0002qQ-5F; Sat, 24 Dec 2011 11:08:50 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RePT6-0002qI-4q
	for xen-devel@lists.xensource.com; Sat, 24 Dec 2011 11:08:48 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1324724807!57413097!1
X-Originating-IP: [209.85.160.43]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15483 invoked from network); 24 Dec 2011 11:06:49 -0000
Received: from mail-pw0-f43.google.com (HELO mail-pw0-f43.google.com)
	(209.85.160.43)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Dec 2011 11:06:49 -0000
Received: by pbbb11 with SMTP id b11so35181891pbb.30
	for <xen-devel@lists.xensource.com>;
	Sat, 24 Dec 2011 03:08:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:date:x-google-sender-auth:message-id:subject
	:from:to:content-type;
	bh=/LQ1tb5qoC+pIhs3M4Ev86W5bq079S9yHvYSC0yHFAI=;
	b=k4ay2j4L61ApWGqIvqlCD9XkQFQt0aGkywRWQKWGJYyAEwCm+IJt33dN4vXFaL6+Ap
	8y1tSrHBlXChN1ENR5o2Zk4vlw0fJEMiQT9EbERlJGRFsyo8wHnpR6II8+qolGzLCIXH
	43jCjj6QPzqgfoQWWNjRwItz20iNSkV5WII04=
MIME-Version: 1.0
Received: by 10.68.74.41 with SMTP id q9mr39209601pbv.129.1324724919079; Sat,
	24 Dec 2011 03:08:39 -0800 (PST)
Received: by 10.142.47.17 with HTTP; Sat, 24 Dec 2011 03:08:39 -0800 (PST)
Date: Sat, 24 Dec 2011 12:08:39 +0100
X-Google-Sender-Auth: MvfDpW9B8_nsGJbWAJMFjQAByiI
Message-ID: <CAPLaKK7Oi2chcq0Ke2nCz6yqae-oL7fDTbBbWeGw4i2rV0g_XA@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] Dom0 LiveCD
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hello,

I'm trying to create a Xen Dom0 LiveCD/usb, based on Alpine Linux,
which has great support for this kind of stuff. I've been able to
successfully install and boot Xen kernel and tools from an HDD using
the same configuration, but when using a tmpfs based boot, the Linux
kernel 3.0.10 crashes while loading some modules (Xen kernel seems to
boot fine). Xen version is stable 4.1.2 and Linux kernel is
3.0.10-grsec. Here is the full output of the boot process:


 __  __            _  _    _   ____
 \ \/ /___ _ __   | || |  / | |___ \
  \  // _ \ '_ \  | || |_ | |   __) |
  /  \  __/ | | | |__   _|| |_ / __/
 /_/\_\___|_| |_|    |_|(_)_(_)_____|

(XEN) Xen version 4.1.2 (royger@localdomain) (gcc version 4.6.2
(Alpine 4.6.2-r1) ) Fri Dec 23 12:55:25 CET 2011
(XEN) Latest ChangeSet: unavailable
(XEN) Bootloader: SYSLINUX 4.04 2011-04-18
(XEN) Command line: dom0_max_vcpus=1 dom0_vcpus_pin guest_loglvl=all
com2=115200,8n1 console=com2
(XEN) Video information:
(XEN)  VGA is text mode 80x25, font 8x16
(XEN) Disc information:
(XEN)  Found 2 MBR signatures
(XEN)  Found 2 EDD information structures
(XEN) Xen-e820 RAM map:
(XEN)  0000000000000000 - 0000000000099000 (usable)
(XEN)  0000000000099000 - 00000000000a0000 (reserved)
(XEN)  00000000000ca000 - 00000000000cc000 (reserved)
(XEN)  00000000000dc000 - 0000000000100000 (reserved)
(XEN)  0000000000100000 - 000000003fee0000 (usable)
(XEN)  000000003fee0000 - 000000003feff000 (ACPI data)
(XEN)  000000003feff000 - 000000003ff00000 (ACPI NVS)
(XEN)  000000003ff00000 - 0000000040000000 (usable)
(XEN)  00000000e0000000 - 00000000f0000000 (reserved)
(XEN)  00000000fec00000 - 00000000fec10000 (reserved)
(XEN)  00000000fee00000 - 00000000fee01000 (reserved)
(XEN)  00000000fffe0000 - 0000000100000000 (reserved)
(XEN) System RAM: 1023MB (1048036kB)
(XEN) ACPI: RSDP 000F6B50, 0024 (r2 PTLTD )
(XEN) ACPI: XSDT 3FEEEC5C, 005C (r1 INTEL  440BX     6040000 VMW   1324272)
(XEN) ACPI: FACP 3FEFEE98, 00F4 (r4 INTEL  440BX     6040000 PTL     F4240)
(XEN) ACPI: DSDT 3FEEF327, FB71 (r1 PTLTD  Custom    6040000 MSFT  3000001)
(XEN) ACPI: FACS 3FEFFFC0, 0040
(XEN) ACPI: BOOT 3FEEF2FF, 0028 (r1 PTLTD  $SBFTBL$  6040000  LTP        1)
(XEN) ACPI: APIC 3FEEF0FD, 0202 (r1 PTLTD  	 APIC    6040000  LTP        0)
(XEN) ACPI: MCFG 3FEEF0C1, 003C (r1 PTLTD  $PCITBL$  6040000  LTP        1)
(XEN) ACPI: SRAT 3FEEED58, 02A8 (r2 VMWARE MEMPLUG   6040000 VMW         1)
(XEN) ACPI: HPET 3FEEED20, 0038 (r1 VMWARE VMW HPET  6040000 VMW         1)
(XEN) ACPI: WAET 3FEEECF8, 0028 (r1 VMWARE VMW WAET  6040000 VMW         1)
(XEN) Domain heap initialised
(XEN) Processor #0 7:7 APIC version 20
(XEN) Processor #1 7:7 APIC version 20
(XEN) IOAPIC[0]: apic_id 32, version 17, address 0xfec00000, GSI 0-23
(XEN) Enabling APIC mode:  Flat.  Using 1 I/O APICs
(XEN) Table is not found!
(XEN) Using scheduler: SMP Credit Scheduler (credit)
(XEN) Detected 2123.193 MHz processor.
(XEN) Initing memory sharing.
(XEN) I/O virtualisation disabled
(XEN) ENABLING IO-APIC IRQs
(XEN)  -> Using new ACK method
(XEN) Platform timer is 14.318MHz HPET
?(XEN) Allocated console ring of 16 KiB.
(XEN) Brought up 2 CPUs
(XEN) *** LOADING DOMAIN 0 ***
(XEN)  Xen  kernel: 64-bit, lsb, compat32
(XEN)  Dom0 kernel: 64-bit, PAE, lsb, paddr 0x1000000 -> 0x1800000
(XEN) PHYSICAL MEMORY ARRANGEMENT:
(XEN)  Dom0 alloc.:   000000003a000000->000000003c000000 (229467 pages
to be allocated)
(XEN)  Init. ramdisk: 000000003e8ca000->000000003f9ffe28
(XEN) VIRTUAL MEMORY ARRANGEMENT:
(XEN)  Loaded kernel: ffffffff81000000->ffffffff81800000
(XEN)  Init. ramdisk: ffffffff81800000->ffffffff82935e28
(XEN)  Phys-Mach map: ffffffff82936000->ffffffff82b0ec88
(XEN)  Start info:    ffffffff82b0f000->ffffffff82b0f4b4
(XEN)  Page tables:   ffffffff82b10000->ffffffff82b29000
(XEN)  Boot stack:    ffffffff82b29000->ffffffff82b2a000
(XEN)  TOTAL:         ffffffff80000000->ffffffff82c00000
(XEN)  ENTRY ADDRESS: ffffffff814bf010
(XEN) Dom0 has maximum 1 VCPUs
(XEN) Scrubbing Free RAM: done.
(XEN) Xen trace buffers: disabled
(XEN) Std. Loglevel: Errors and warnings
(XEN) Guest Loglevel: All
(XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch
input to Xen)
(XEN) Freed 216kB init memory.
mapping kernel into physical memory
Xen: setup ISA identity maps
about to get started...
[    0.000000] Initializing cgroup subsys cpuset
[    0.000000] Initializing cgroup subsys cpu
[    0.000000] Linux version 3.0.10-grsec (buildozer@build64-2-3) (gcc
version 4.6.2 (Alpine 4.6.2-r1) ) #1-Alpine SMP Tue Nov 22 13:07:04
UTC 2011
[    0.000000] Command line: alpine_dev=UUID=4EF4-5EFD:vfat
modules=loop,squashfs,sd-mod,usb-storage
modloop=/boot/grsec.modloop.squashfs console=hvc0 earlyprintk=xen
nomodeset
[    0.000000] Disabled fast string operations
[    0.000000] released 0 pages of unused memory
[    0.000000] Set 786567 page(s) to 1-1 mapping.
[    0.000000] BIOS-provided physical RAM map:
[    0.000000]  Xen: 0000000000000000 - 0000000000099000 (usable)
[    0.000000]  Xen: 0000000000099000 - 0000000000100000 (reserved)
[    0.000000]  Xen: 0000000000100000 - 000000003b191000 (usable)
[    0.000000]  Xen: 000000003b191000 - 000000003fee0000 (unusable)
[    0.000000]  Xen: 000000003fee0000 - 000000003feff000 (ACPI data)
[    0.000000]  Xen: 000000003feff000 - 000000003ff00000 (ACPI NVS)
[    0.000000]  Xen: 000000003ff00000 - 0000000040000000 (unusable)
[    0.000000]  Xen: 00000000e0000000 - 00000000f0000000 (reserved)
[    0.000000]  Xen: 00000000fec00000 - 00000000fec10000 (reserved)
[    0.000000]  Xen: 00000000fee00000 - 00000000fee01000 (reserved)
[    0.000000]  Xen: 00000000fffe0000 - 0000000100000000 (reserved)
[    0.000000]  Xen: 0000000100000000 - 0000000104e4f000 (usable)
[    0.000000] NX (Execute Disable) protection: active
[    0.000000] DMI present.
[    0.000000] No AGP bridge found
[    0.000000] last_pfn = 0x104e4f max_arch_pfn = 0x400000000
[    0.000000] last_pfn = 0x3b191 max_arch_pfn = 0x400000000
[    0.000000] found SMP MP-table at [ffff8800000f6bc0] f6bc0
[    0.000000] init_memory_mapping: 0000000000000000-000000003b191000
[    0.000000] init_memory_mapping: 0000000100000000-0000000104e4f000
[    0.000000] RAMDISK: 01800000 - 02936000
[    0.000000] ACPI: RSDP 00000000000f6b50 00024 (v02 PTLTD )
[    0.000000] ACPI: XSDT 000000003feeec5c 0005C (v01 INTEL  440BX
06040000 VMW  01324272)
[    0.000000] ACPI: FACP 000000003fefee98 000F4 (v04 INTEL  440BX
06040000 PTL  000F4240)
[    0.000000] ACPI: DSDT 000000003feef327 0FB71 (v01 PTLTD  Custom
06040000 MSFT 03000001)
[    0.000000] ACPI: FACS 000000003fefffc0 00040
[    0.000000] ACPI: BOOT 000000003feef2ff 00028 (v01 PTLTD  $SBFTBL$
06040000  LTP 00000001)
[    0.000000] ACPI: APIC 000000003feef0fd 00202 (v01 PTLTD  ? APIC
06040000  LTP 00000000)
[    0.000000] ACPI: MCFG 000000003feef0c1 0003C (v01 PTLTD  $PCITBL$
06040000  LTP 00000001)
[    0.000000] ACPI: SRAT 000000003feeed58 002A8 (v02 VMWARE MEMPLUG
06040000 VMW  00000001)
[    0.000000] ACPI: HPET 000000003feeed20 00038 (v01 VMWARE VMW HPET
06040000 VMW  00000001)
[    0.000000] ACPI: WAET 000000003feeecf8 00028 (v01 VMWARE VMW WAET
06040000 VMW  00000001)
[    0.000000] Zone PFN ranges:
[    0.000000]   DMA      0x00000010 -> 0x00001000
[    0.000000]   DMA32    0x00001000 -> 0x00100000
[    0.000000]   Normal   0x00100000 -> 0x00104e4f
[    0.000000] Movable zone start PFN for each node
[    0.000000] early_node_map[3] active PFN ranges
[    0.000000]     0: 0x00000010 -> 0x00000099
[    0.000000]     0: 0x00000100 -> 0x0003b191
[    0.000000]     0: 0x00100000 -> 0x00104e4f
[    0.000000] ACPI: PM-Timer IO Port: 0x1008
[    0.000000] ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
[    0.000000] BIOS bug: APIC version is 0 for CPU 0/0x0, fixing up to 0x10
[    0.000000] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x02] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x03] lapic_id[0x03] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x04] lapic_id[0x04] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x05] lapic_id[0x05] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x06] lapic_id[0x06] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x07] lapic_id[0x07] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x08] lapic_id[0x08] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x09] lapic_id[0x09] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x0a] lapic_id[0x0a] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x0b] lapic_id[0x0b] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x0c] lapic_id[0x0c] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x0d] lapic_id[0x0d] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x0e] lapic_id[0x0e] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x0f] lapic_id[0x0f] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x10] lapic_id[0x10] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x11] lapic_id[0x11] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x12] lapic_id[0x12] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x13] lapic_id[0x13] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x14] lapic_id[0x14] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x15] lapic_id[0x15] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x16] lapic_id[0x16] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x17] lapic_id[0x17] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x18] lapic_id[0x18] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x19] lapic_id[0x19] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x1a] lapic_id[0x1a] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x1b] lapic_id[0x1b] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x1c] lapic_id[0x1c] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x1d] lapic_id[0x1d] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x1e] lapic_id[0x1e] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x1f] lapic_id[0x1f] disabled)
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x02] high edge lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x03] high edge lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x04] high edge lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x05] high edge lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x06] high edge lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x07] high edge lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x08] high edge lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x09] high edge lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x0a] high edge lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x0b] high edge lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x0c] high edge lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x0d] high edge lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x0e] high edge lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x0f] high edge lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x10] high edge lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x11] high edge lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x12] high edge lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x13] high edge lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x14] high edge lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x15] high edge lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x16] high edge lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x17] high edge lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x18] high edge lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x19] high edge lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x1a] high edge lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x1b] high edge lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x1c] high edge lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x1d] high edge lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x1e] high edge lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x1f] high edge lint[0x1])
[    0.000000] ACPI: IOAPIC (id[0x20] address[0xfec00000] gsi_base[0])
[    0.000000] IOAPIC[0]: apic_id 32, version 255, address 0xfec00000, GSI 0-255
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 high edge)
[    0.000000] Using ACPI (MADT) for SMP configuration information
[    0.000000] ACPI: HPET id: 0x8086af01 base: 0xfed00000
[    0.000000] SMP: Allowing 32 CPUs, 30 hotplug CPUs
[    0.000000] Allocating PCI resources starting at 40000000 (gap:
40000000:a0000000)
[    0.000000] Booting paravirtualized kernel on Xen
[    0.000000] Xen version: 4.1.2 (preserve-AD)
[    0.000000] setup_percpu: NR_CPUS:32 nr_cpumask_bits:32
nr_cpu_ids:32 nr_node_ids:1
[    0.000000] PERCPU: Embedded 23 pages/cpu @ffff88003ae91000 s62912
r8192 d23104 u94208
[    0.969940] Built 1 zonelists in Zone order, mobility grouping on.
Total pages: 247377
[    0.969947] Kernel command line: alpine_dev=UUID=4EF4-5EFD:vfat
modules=loop,squashfs,sd-mod,usb-storage
modloop=/boot/grsec.modloop.squashfs console=hvc0 earlyprintk=xen
nomodeset
[    0.970021] PID hash table entries: 4096 (order: 3, 32768 bytes)
[    0.970140] Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes)
[    0.970258] Inode-cache hash table entries: 65536 (order: 7, 524288 bytes)
[    1.281122] Placing 64MB software IO TLB between ffff880035600000 -
ffff880039600000
[    1.281132] software IO TLB at phys 0x35600000 - 0x39600000
[    1.288058] Memory: 853380k/4274492k available (2757k kernel code,
3226520k absent, 194592k reserved, 2029k data, 504k init)
[    1.288176] SLUB: Genslabs=15, HWalign=64, Order=0-3, MinObjects=0,
CPUs=32, Nodes=1
[    1.288337] Hierarchical RCU implementation.
[    1.288342] 	CONFIG_RCU_FANOUT set to non-default value of 32
[    1.288346] 	RCU dyntick-idle grace-period acceleration is enabled.
[    1.288361] NR_IRQS:1280
[    1.291189] xen: sci override: global_irq=9 trigger=0 polarity=1
[    1.291305] xen: acpi sci 9
[    1.291378] xen_map_pirq_gsi: returning irq 9 for gsi 9
[    1.291561] Console: colour VGA+ 80x25
[    1.695888] console [hvc0] enabled
[    1.697085] installing Xen timer for CPU 0
[    1.697249] Detected 2123.192 MHz processor.
[    1.697376] Calibrating delay loop (skipped), value calculated
using timer frequency.. 4248.31 BogoMIPS (lpj=7077306)
[    1.700865] pid_max: default: 32768 minimum: 501
[    1.701150] Security Framework initialized
[    1.701268] Mount-cache hash table entries: 256
[    1.703780] Initializing cgroup subsys cpuacct
[    1.704696] Initializing cgroup subsys devices
[    1.706060] Initializing cgroup subsys freezer
[    1.706178] Initializing cgroup subsys blkio
[    1.706297] Disabled fast string operations
[    1.708319] SMP alternatives: switching to UP code
[    1.716227] Freeing SMP alternatives: 20k freed
[    1.716345] ACPI: Core revision 20110413
[    1.726738] Performance Events: unsupported p6 CPU model 23 no PMU
driver, software events only.
[    1.730340] Brought up 1 CPUs
[    1.731295] Grant table initialized
[    1.731701] print_constraints: dummy:
[    1.731819] NET: Registered protocol family 16
[    1.734499] ACPI: bus type pci registered
[    1.736933] PCI: MMCONFIG for domain 0000 [bus 00-ff] at [mem
0xe0000000-0xefffffff] (base 0xe0000000)
[    1.737269] PCI: MMCONFIG at [mem 0xe0000000-0xefffffff] reserved in E820
[    1.938462] PCI: Using configuration type 1 for base access
[    1.943498] bio: create slab <bio-0> at 0
[    1.959065] [Firmware Bug]: ACPI: BIOS _OSI(Linux) query ignored
[    1.969392] ACPI: Interpreter enabled
[    1.969471] ACPI: (supports S0 S1 S5)
[    1.969551] ACPI: Using IOAPIC for interrupt routing
[    2.022004] ACPI: No dock devices found.
[    2.022083] HEST: Table not found.
[    2.022163] PCI: Using host bridge windows from ACPI; if necessary,
use "pci=nocrs" and report a bug
[    2.022379] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff])
[    2.022589] pci_root PNP0A03:00: host bridge window [mem
0x000a0000-0x000bffff]
[    2.022669] pci_root PNP0A03:00: host bridge window [mem
0x000cc000-0x000cffff]
[    2.022749] pci_root PNP0A03:00: host bridge window [mem
0x000d0000-0x000d3fff]
[    2.022828] pci_root PNP0A03:00: host bridge window [mem
0x000d4000-0x000d7fff]
[    2.025872] pci_root PNP0A03:00: host bridge window [mem
0x000d8000-0x000dbfff]
[    2.028344] pci_root PNP0A03:00: host bridge window [mem
0xc0000000-0xfebfffff]
[    2.028423] pci_root PNP0A03:00: host bridge window [io  0x0000-0x0cf7]
[    2.028503] pci_root PNP0A03:00: host bridge window [io  0x0d00-0xfeff]
[    2.036122] pci 0000:00:07.3: quirk: [io  0x1000-0x103f] claimed by
PIIX4 ACPI
[    2.042328] pci 0000:00:07.3: quirk: [io  0x1040-0x104f] claimed by PIIX4 SMB
[    2.061249] pci 0000:00:01.0: PCI bridge to [bus 01-01]
[    2.067647] pci 0000:00:11.0: PCI bridge to [bus 02-02] (subtractive decode)
[    2.067983] pci 0000:00:15.0: PCI bridge to [bus 03-03]
[    2.068301] pci 0000:00:15.1: PCI bridge to [bus 04-04]
[    2.068598] pci 0000:00:15.2: PCI bridge to [bus 05-05]
[    2.073083] pci 0000:00:15.3: PCI bridge to [bus 06-06]
[    2.073363] pci 0000:00:15.4: PCI bridge to [bus 07-07]
[    2.073660] pci 0000:00:15.5: PCI bridge to [bus 08-08]
[    2.073941] pci 0000:00:15.6: PCI bridge to [bus 09-09]
[    2.074259] pci 0000:00:15.7: PCI bridge to [bus 0a-0a]
[    2.074540] pci 0000:00:16.0: PCI bridge to [bus 0b-0b]
[    2.074821] pci 0000:00:16.1: PCI bridge to [bus 0c-0c]
[    2.075116] pci 0000:00:16.2: PCI bridge to [bus 0d-0d]
[    2.075434] pci 0000:00:16.3: PCI bridge to [bus 0e-0e]
[    2.075717] pci 0000:00:16.4: PCI bridge to [bus 0f-0f]
[    2.076131] pci 0000:00:16.5: PCI bridge to [bus 10-10]
[    2.076412] pci 0000:00:16.6: PCI bridge to [bus 11-11]
[    2.076693] pci 0000:00:16.7: PCI bridge to [bus 12-12]
[    2.076976] pci 0000:00:17.0: PCI bridge to [bus 13-13]
[    2.077257] pci 0000:00:17.1: PCI bridge to [bus 14-14]
[    2.077573] pci 0000:00:17.2: PCI bridge to [bus 15-15]
[    2.079803] pci 0000:00:17.3: PCI bridge to [bus 16-16]
[    2.080100] pci 0000:00:17.4: PCI bridge to [bus 17-17]
[    2.080396] pci 0000:00:17.5: PCI bridge to [bus 18-18]
[    2.082988] pci 0000:00:17.6: PCI bridge to [bus 19-19]
[    2.083269] pci 0000:00:17.7: PCI bridge to [bus 1a-1a]
[    2.083551] pci 0000:00:18.0: PCI bridge to [bus 1b-1b]
[    2.083831] pci 0000:00:18.1: PCI bridge to [bus 1c-1c]
[    2.084113] pci 0000:00:18.2: PCI bridge to [bus 1d-1d]
[    2.084395] pci 0000:00:18.3: PCI bridge to [bus 1e-1e]
[    2.084678] pci 0000:00:18.4: PCI bridge to [bus 1f-1f]
[    2.084960] pci 0000:00:18.5: PCI bridge to [bus 20-20]
[    2.085244] pci 0000:00:18.6: PCI bridge to [bus 21-21]
[    2.085525] pci 0000:00:18.7: PCI bridge to [bus 22-22]
[    2.088738]  pci0000:00: Requesting ACPI _OSC control (0x15)
[    2.088818]  pci0000:00: ACPI _OSC control (0x15) granted
[    2.216629] ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 *9 10 11 14 15)
[    2.218708] ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 9 10 *11 14 15)
[    2.219072] ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 7 9 *10 11 14 15)
[    2.223302] ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 *5 6 7 9 10 11 14 15)
[    2.224412] xen/balloon: Initialising balloon driver.
[    2.224492] last_pfn = 0x104e4f max_arch_pfn = 0x400000000
[    2.224706] xen-balloon: Initialising balloon driver.
[    2.225402] PCI: Using ACPI for IRQ routing
[    2.345078] pci 0000:00:18.2: no compatible bridge window for [io
0xf000-0xffff]
[    2.345591] NetLabel: Initializing
[    2.345642] NetLabel:  domain hash size = 128
[    2.345694] NetLabel:  protocols = UNLABELED CIPSOv4
[    2.345745] NetLabel:  unlabeled traffic allowed by default
[    2.345797] Switching to clocksource xen
[    2.349081] pnp: PnP ACPI init
[    2.349132] ACPI: bus type pnp registered
[    2.349638] system 00:01: [io  0x1000-0x103f] has been reserved
[    2.352559] system 00:01: [io  0x1040-0x104f] has been reserved
[    2.355262] system 00:01: [io  0x0cf0-0x0cf1] has been reserved
[    2.355434] Switched to NOHz mode on CPU #0
[    2.356377] xen_map_pirq_gsi: returning irq 8 for gsi 8
[    2.359772] xen_map_pirq_gsi: returning irq 1 for gsi 1
[    2.365621] xen_map_pirq_gsi: returning irq 12 for gsi 12
[    2.366304] system 00:08: [mem 0xfed00000-0xfed003ff] has been reserved
[    2.386110] xen_map_pirq_gsi: returning irq 7 for gsi 7
[    2.386645] xen_map_pirq_gsi: returning irq 4 for gsi 4
[    2.389635] xen_map_pirq_gsi: returning irq 3 for gsi 3
[    2.389694] Already setup the GSI :3
[    2.392747] xen_map_pirq_gsi: returning irq 6 for gsi 6
[    2.396135] system 00:0d: [io  0x1060-0x107f] has been reserved
[    2.396187] system 00:0d: [mem 0xe0000000-0xefffffff] has been reserved
[    2.396238] system 00:0d: [mem 0xc8200000-0xc83fffff] has been reserved
[    2.405821] pnp: PnP ACPI: found 14 devices
[    2.405872] ACPI: ACPI bus type pnp unregistered
[    2.425809] PM-Timer failed consistency check  (0x0xffffff) - aborting.
[    2.429116] pci 0000:00:0f.0: BAR 6: assigned [mem
0xc0000000-0xc0007fff pref]
[    2.429168] pci 0000:00:10.0: BAR 6: assigned [mem
0xc0008000-0xc000bfff pref]
[    2.429220] pci 0000:00:18.7: BAR 7: can't assign io (size 0x1000)
[    2.429271] pci 0000:00:18.6: BAR 7: can't assign io (size 0x1000)
[    2.429323] pci 0000:00:18.5: BAR 7: can't assign io (size 0x1000)
[    2.429374] pci 0000:00:18.4: BAR 7: can't assign io (size 0x1000)
[    2.429426] pci 0000:00:18.3: BAR 7: can't assign io (size 0x1000)
[    2.429478] pci 0000:00:18.2: BAR 7: can't assign io (size 0x1000)
[    2.429529] pci 0000:00:17.7: BAR 7: can't assign io (size 0x1000)
[    2.429581] pci 0000:00:17.6: BAR 7: can't assign io (size 0x1000)
[    2.429632] pci 0000:00:17.5: BAR 7: can't assign io (size 0x1000)
[    2.429684] pci 0000:00:17.4: BAR 7: can't assign io (size 0x1000)
[    2.429735] pci 0000:00:17.3: BAR 7: can't assign io (size 0x1000)
[    2.429787] pci 0000:00:16.7: BAR 7: can't assign io (size 0x1000)
[    2.429839] pci 0000:00:16.6: BAR 7: can't assign io (size 0x1000)
[    2.429890] pci 0000:00:16.5: BAR 7: can't assign io (size 0x1000)
[    2.429942] pci 0000:00:16.4: BAR 7: can't assign io (size 0x1000)
[    2.429993] pci 0000:00:16.3: BAR 7: can't assign io (size 0x1000)
[    2.430045] pci 0000:00:15.7: BAR 7: can't assign io (size 0x1000)
[    2.430097] pci 0000:00:15.6: BAR 7: can't assign io (size 0x1000)
[    2.430148] pci 0000:00:15.5: BAR 7: can't assign io (size 0x1000)
[    2.430200] pci 0000:00:15.4: BAR 7: can't assign io (size 0x1000)
[    2.430251] pci 0000:00:15.3: BAR 7: can't assign io (size 0x1000)
[    2.430303] pci 0000:00:01.0: PCI bridge to [bus 01-01]
[    2.430354] pci 0000:00:01.0:   bridge window [io  disabled]
[    2.430406] pci 0000:00:01.0:   bridge window [mem disabled]
[    2.430458] pci 0000:00:01.0:   bridge window [mem pref disabled]
[    2.430509] pci 0000:02:01.0: BAR 6: assigned [mem
0xd8400000-0xd840ffff pref]
[    2.430561] pci 0000:00:11.0: PCI bridge to [bus 02-02]
[    2.430612] pci 0000:00:11.0:   bridge window [io  0x2000-0x3fff]
[    2.430664] pci 0000:00:11.0:   bridge window [mem 0xc9000000-0xca3fffff]
[    2.430716] pci 0000:00:11.0:   bridge window [mem
0xd8400000-0xd89fffff 64bit pref]
[    2.430767] pci 0000:00:15.0: PCI bridge to [bus 03-03]
[    2.430819] pci 0000:00:15.0:   bridge window [io  0x4000-0x4fff]
[    2.430870] pci 0000:00:15.0:   bridge window [mem 0xca400000-0xca4fffff]
[    2.430922] pci 0000:00:15.0:   bridge window [mem
0xd8a00000-0xd8afffff 64bit pref]
[    2.430973] pci 0000:00:15.1: PCI bridge to [bus 04-04]
[    2.431025] pci 0000:00:15.1:   bridge window [io  0x8000-0x8fff]
[    2.431077] pci 0000:00:15.1:   bridge window [mem 0xca800000-0xca8fffff]
[    2.431180] pci 0000:00:15.1:   bridge window [mem
0xd8e00000-0xd8efffff 64bit pref]
[    2.431231] pci 0000:00:15.2: PCI bridge to [bus 05-05]
[    2.431283] pci 0000:00:15.2:   bridge window [io  0xc000-0xcfff]
[    2.431335] pci 0000:00:15.2:   bridge window [mem 0xcac00000-0xcacfffff]
[    2.431386] pci 0000:00:15.2:   bridge window [mem
0xd9200000-0xd92fffff 64bit pref]
[    2.431438] pci 0000:00:15.3: PCI bridge to [bus 06-06]
[    2.435798] pci 0000:00:15.3:   bridge window [io  disabled]
[    2.435849] pci 0000:00:15.3:   bridge window [mem 0xcb000000-0xcb0fffff]
[    2.435901] pci 0000:00:15.3:   bridge window [mem
0xd9600000-0xd96fffff 64bit pref]
[    2.435952] pci 0000:00:15.4: PCI bridge to [bus 07-07]
[    2.436004] pci 0000:00:15.4:   bridge window [io  disabled]
[    2.436056] pci 0000:00:15.4:   bridge window [mem 0xcb400000-0xcb4fffff]
[    2.436107] pci 0000:00:15.4:   bridge window [mem
0xd9a00000-0xd9afffff 64bit pref]
[    2.436159] pci 0000:00:15.5: PCI bridge to [bus 08-08]
[    2.436210] pci 0000:00:15.5:   bridge window [io  disabled]
[    2.436262] pci 0000:00:15.5:   bridge window [mem 0xcb800000-0xcb8fffff]
[    2.436314] pci 0000:00:15.5:   bridge window [mem
0xd9e00000-0xd9efffff 64bit pref]
[    2.436365] pci 0000:00:15.6: PCI bridge to [bus 09-09]
[    2.436417] pci 0000:00:15.6:   bridge window [io  disabled]
[    2.436468] pci 0000:00:15.6:   bridge window [mem 0xcbc00000-0xcbcfffff]
[    2.436520] pci 0000:00:15.6:   bridge window [mem
0xda200000-0xda2fffff 64bit pref]
[    2.436571] pci 0000:00:15.7: PCI bridge to [bus 0a-0a]
[    2.436623] pci 0000:00:15.7:   bridge window [io  disabled]
[    2.436675] pci 0000:00:15.7:   bridge window [mem 0xcc000000-0xcc0fffff]
[    2.436726] pci 0000:00:15.7:   bridge window [mem
0xda600000-0xda6fffff 64bit pref]
[    2.436778] pci 0000:00:16.0: PCI bridge to [bus 0b-0b]
[    2.436829] pci 0000:00:16.0:   bridge window [io  0x5000-0x5fff]
[    2.436881] pci 0000:00:16.0:   bridge window [mem 0xca500000-0xca5fffff]
[    2.436933] pci 0000:00:16.0:   bridge window [mem
0xd8b00000-0xd8bfffff 64bit pref]
[    2.436984] pci 0000:00:16.1: PCI bridge to [bus 0c-0c]
[    2.437036] pci 0000:00:16.1:   bridge window [io  0x9000-0x9fff]
[    2.437087] pci 0000:00:16.1:   bridge window [mem 0xca900000-0xca9fffff]
[    2.437139] pci 0000:00:16.1:   bridge window [mem
0xd8f00000-0xd8ffffff 64bit pref]
[    2.437190] pci 0000:00:16.2: PCI bridge to [bus 0d-0d]
[    2.437242] pci 0000:00:16.2:   bridge window [io  0xd000-0xdfff]
[    2.437294] pci 0000:00:16.2:   bridge window [mem 0xcad00000-0xcadfffff]
[    2.437345] pci 0000:00:16.2:   bridge window [mem
0xd9300000-0xd93fffff 64bit pref]
[    2.437397] pci 0000:00:16.3: PCI bridge to [bus 0e-0e]
[    2.437448] pci 0000:00:16.3:   bridge window [io  disabled]
[    2.437500] pci 0000:00:16.3:   bridge window [mem 0xcb100000-0xcb1fffff]
[    2.437552] pci 0000:00:16.3:   bridge window [mem
0xd9700000-0xd97fffff 64bit pref]
[    2.437603] pci 0000:00:16.4: PCI bridge to [bus 0f-0f]
[    2.437655] pci 0000:00:16.4:   bridge window [io  disabled]
[    2.437706] pci 0000:00:16.4:   bridge window [mem 0xcb500000-0xcb5fffff]
[    2.437758] pci 0000:00:16.4:   bridge window [mem
0xd9b00000-0xd9bfffff 64bit pref]
[    2.437809] pci 0000:00:16.5: PCI bridge to [bus 10-10]
[    2.437861] pci 0000:00:16.5:   bridge window [io  disabled]
[    2.437913] pci 0000:00:16.5:   bridge window [mem 0xcb900000-0xcb9fffff]
[    2.437964] pci 0000:00:16.5:   bridge window [mem
0xd9f00000-0xd9ffffff 64bit pref]
[    2.438016] pci 0000:00:16.6: PCI bridge to [bus 11-11]
[    2.438067] pci 0000:00:16.6:   bridge window [io  disabled]
[    2.438119] pci 0000:00:16.6:   bridge window [mem 0xcbd00000-0xcbdfffff]
[    2.438171] pci 0000:00:16.6:   bridge window [mem
0xda300000-0xda3fffff 64bit pref]
[    2.438222] pci 0000:00:16.7: PCI bridge to [bus 12-12]
[    2.438274] pci 0000:00:16.7:   bridge window [io  disabled]
[    2.438325] pci 0000:00:16.7:   bridge window [mem 0xcc100000-0xcc1fffff]
[    2.438377] pci 0000:00:16.7:   bridge window [mem
0xda700000-0xda7fffff 64bit pref]
[    2.438428] pci 0000:00:17.0: PCI bridge to [bus 13-13]
[    2.438480] pci 0000:00:17.0:   bridge window [io  0x6000-0x6fff]
[    2.438532] pci 0000:00:17.0:   bridge window [mem 0xca600000-0xca6fffff]
[    2.438583] pci 0000:00:17.0:   bridge window [mem
0xd8c00000-0xd8cfffff 64bit pref]
[    2.438635] pci 0000:00:17.1: PCI bridge to [bus 14-14]
[    2.438686] pci 0000:00:17.1:   bridge window [io  0xa000-0xafff]
[    2.438738] pci 0000:00:17.1:   bridge window [mem 0xcaa00000-0xcaafffff]
[    2.438790] pci 0000:00:17.1:   bridge window [mem
0xd9000000-0xd90fffff 64bit pref]
[    2.438841] pci 0000:00:17.2: PCI bridge to [bus 15-15]
[    2.438893] pci 0000:00:17.2:   bridge window [io  0xe000-0xefff]
[    2.438944] pci 0000:00:17.2:   bridge window [mem 0xcae00000-0xcaefffff]
[    2.446013] pci 0000:00:17.2:   bridge window [mem
0xd9400000-0xd94fffff 64bit pref]
[    2.446065] pci 0000:00:17.3: PCI bridge to [bus 16-16]
[    2.446116] pci 0000:00:17.3:   bridge window [io  disabled]
[    2.446168] pci 0000:00:17.3:   bridge window [mem 0xcb200000-0xcb2fffff]
[    2.449249] pci 0000:00:17.3:   bridge window [mem
0xd9800000-0xd98fffff 64bit pref]
[    2.449946] pci 0000:00:17.4: PCI bridge to [bus 17-17]
[    2.449998] pci 0000:00:17.4:   bridge window [io  disabled]
[    2.450049] pci 0000:00:17.4:   bridge window [mem 0xcb600000-0xcb6fffff]
[    2.450101] pci 0000:00:17.4:   bridge window [mem
0xd9c00000-0xd9cfffff 64bit pref]
[    2.450153] pci 0000:00:17.5: PCI bridge to [bus 18-18]
[    2.450204] pci 0000:00:17.5:   bridge window [io  disabled]
[    2.450256] pci 0000:00:17.5:   bridge window [mem 0xcba00000-0xcbafffff]
[    2.450307] pci 0000:00:17.5:   bridge window [mem
0xda000000-0xda0fffff 64bit pref]
[    2.450359] pci 0000:00:17.6: PCI bridge to [bus 19-19]
[    2.450410] pci 0000:00:17.6:   bridge window [io  disabled]
[    2.450462] pci 0000:00:17.6:   bridge window [mem 0xcbe00000-0xcbefffff]
[    2.450514] pci 0000:00:17.6:   bridge window [mem
0xda400000-0xda4fffff 64bit pref]
[    2.450565] pci 0000:00:17.7: PCI bridge to [bus 1a-1a]
[    2.450617] pci 0000:00:17.7:   bridge window [io  disabled]
[    2.450668] pci 0000:00:17.7:   bridge window [mem 0xcc200000-0xcc2fffff]
[    2.450720] pci 0000:00:17.7:   bridge window [mem
0xda800000-0xda8fffff 64bit pref]
[    2.450772] pci 0000:00:18.0: PCI bridge to [bus 1b-1b]
[    2.450823] pci 0000:00:18.0:   bridge window [io  0x7000-0x7fff]
[    2.450875] pci 0000:00:18.0:   bridge window [mem 0xca700000-0xca7fffff]
[    2.450926] pci 0000:00:18.0:   bridge window [mem
0xd8d00000-0xd8dfffff 64bit pref]
[    2.450978] pci 0000:00:18.1: PCI bridge to [bus 1c-1c]
[    2.451029] pci 0000:00:18.1:   bridge window [io  0xb000-0xbfff]
[    2.451081] pci 0000:00:18.1:   bridge window [mem 0xcab00000-0xcabfffff]
[    2.451133] pci 0000:00:18.1:   bridge window [mem
0xd9100000-0xd91fffff 64bit pref]
[    2.451184] pci 0000:00:18.2: PCI bridge to [bus 1d-1d]
[    2.451236] pci 0000:00:18.2:   bridge window [io  disabled]
[    2.451287] pci 0000:00:18.2:   bridge window [mem 0xcaf00000-0xcaffffff]
[    2.451339] pci 0000:00:18.2:   bridge window [mem
0xd9500000-0xd95fffff 64bit pref]
[    2.451391] pci 0000:00:18.3: PCI bridge to [bus 1e-1e]
[    2.451442] pci 0000:00:18.3:   bridge window [io  disabled]
[    2.451494] pci 0000:00:18.3:   bridge window [mem 0xcb300000-0xcb3fffff]
[    2.451545] pci 0000:00:18.3:   bridge window [mem
0xd9900000-0xd99fffff 64bit pref]
[    2.451597] pci 0000:00:18.4: PCI bridge to [bus 1f-1f]
[    2.451648] pci 0000:00:18.4:   bridge window [io  disabled]
[    2.451700] pci 0000:00:18.4:   bridge window [mem 0xcb700000-0xcb7fffff]
[    2.451752] pci 0000:00:18.4:   bridge window [mem
0xd9d00000-0xd9dfffff 64bit pref]
[    2.451803] pci 0000:00:18.5: PCI bridge to [bus 20-20]
[    2.451855] pci 0000:00:18.5:   bridge window [io  disabled]
[    2.451906] pci 0000:00:18.5:   bridge window [mem 0xcbb00000-0xcbbfffff]
[    2.451958] pci 0000:00:18.5:   bridge window [mem
0xda100000-0xda1fffff 64bit pref]
[    2.452010] pci 0000:00:18.6: PCI bridge to [bus 21-21]
[    2.452061] pci 0000:00:18.6:   bridge window [io  disabled]
[    2.452113] pci 0000:00:18.6:   bridge window [mem 0xcbf00000-0xcbffffff]
[    2.456092] pci 0000:00:18.6:   bridge window [mem
0xda500000-0xda5fffff 64bit pref]
[    2.456144] pci 0000:00:18.7: PCI bridge to [bus 22-22]
[    2.456196] pci 0000:00:18.7:   bridge window [io  disabled]
[    2.456247] pci 0000:00:18.7:   bridge window [mem 0xcc300000-0xcc3fffff]
[    2.456299] pci 0000:00:18.7:   bridge window [mem
0xda900000-0xda9fffff 64bit pref]
[    2.458674] NET: Registered protocol family 2
[    2.459274] IP route cache hash table entries: 32768 (order: 6, 262144 bytes)
[    2.459435] TCP established hash table entries: 131072 (order: 9,
2097152 bytes)
[    2.465816] TCP bind hash table entries: 65536 (order: 8, 1048576 bytes)
[    2.466350] TCP: Hash tables configured (established 131072 bind 65536)
[    2.466401] TCP reno registered
[    2.466453] UDP hash table entries: 512 (order: 2, 16384 bytes)
[    2.466505] UDP-Lite hash table entries: 512 (order: 2, 16384 bytes)
[    2.466663] NET: Registered protocol family 1
[    2.466715] pci 0000:00:00.0: Limiting direct PCI/PCI transfers
[    2.469579] Trying to unpack rootfs image as initramfs...
[    2.576590] Freeing initrd memory: 17624k freed
[    2.592556] Simple Boot Flag at 0x36 set to 0x80
[    2.602854] VFS: Disk quotas dquot_6.5.2
[    2.602906] Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
[    2.605963] msgmni has been set to 1701
[    2.607923] Block layer SCSI generic (bsg) driver version 0.4
loaded (major 253)
[    2.609291] io scheduler noop registered
[    2.609343] io scheduler cfq registered (default)
[    2.623994] ERST: Table is not found!
[    2.624274] Event-channel device installed.
[    2.626858] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
[    2.660523] serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
[    2.688257] 00:0a: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
[    2.691245] hpet_acpi_add: no address or irqs in _CRS
[    2.701948] brd: module loaded
[    2.702940] i8042: PNP: PS/2 Controller [PNP0303:KBC,PNP0f13:MOUS]
at 0x60,0x64 irq 1,12
[    3.265863] serio: i8042 KBD port at 0x60,0x64 irq 1
[    3.267036] serio: i8042 AUX port at 0x60,0x64 irq 12
[    3.288259] rtc_cmos 00:04: rtc core: registered rtc_cmos as rtc0
[    3.289657] rtc0: alarms up to one month, y3k, 114 bytes nvram
[    3.291303] cpuidle: using governor ladder
[    3.292326] cpuidle: using governor menu
[    3.293337] GRE over IPv4 demultiplexor driver
[    3.293425] TCP cubic registered
[    3.293514] Registering the dns_resolver key type
[    3.299454] input: AT Translated Set 2 keyboard as
/devices/platform/i8042/serio0/input/input0
[    3.300116] rtc_cmos 00:04: setting system clock to 2011-12-24
11:55:32 UTC (1324727732)
[    3.302590] Freeing unused kernel memory: 504k freed
Alpine Init 2.4.2-r0
 * Starting mdev: ok.
 * Loading boot drivers: [    3.482784] loop: module loaded
[    3.489387] squashfs: version 4.0 (2009/01/31) Phillip Lougher
[    3.509343] SCSI subsystem initialized
[    3.535656] usbcore: registered new interface driver usbfs
[    3.543178] usbcore: registered new interface driver hub
[    3.549401] usbcore: registered new device driver usb
[    3.559302] usbcore: registered new interface driver libusual
[    3.569475] Initializing USB Mass Storage driver...
[    3.579155] usbcore: registered new interface driver usb-storage
[    3.582583] USB Mass Storage support registered.
[    3.715956] Floppy drive(s): fd0 is 1.44M
[    3.729542] FDC 0 is a post-1991 82077
[    3.744726] Fusion MPT base driver 3.04.19
[    3.745877] Copyright (c) 1999-2008 LSI Corporation
[    3.752729] Fusion MPT SPI Host driver 3.04.19
[    3.759153] mptspi 0000:00:10.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
[    3.759628] mptbase: ioc0: Initiating bringup
[    3.819265] ioc0: LSI53C1030 B0: Capabilities={Initiator}
[    3.953518] scsi0 : ioc0: LSI53C1030 B0, FwRev=01032920h, Ports=1,
MaxQ=128, IRQ=17
[    4.056224] scsi 0:0:0:0: Direct-Access     VMware,  VMware Virtual
S 1.0  PQ: 0 ANSI: 2
[    4.062443] scsi target0:0:0: Beginning Domain Validation
[    4.066185] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[    4.067178] xen_map_pirq_gsi: returning irq 17 for gsi 17
[    4.069313] Already setup the GSI :17
[    4.070740] ehci_hcd 0000:02:03.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
[    4.073792] ehci_hcd 0000:02:03.0: EHCI Host Controller
[    4.083639] scsi target0:0:0: Domain Validation skipping write tests
[    4.085899] scsi target0:0:0: Ending Domain Validation
[    4.091191] ehci_hcd 0000:02:03.0: new USB bus registered, assigned
bus number 1
[    4.092669] ehci_hcd 0000:02:03.0: irq 17, io mem 0xc9010000
[    4.097824] scsi target0:0:0: FAST-40 WIDE SCSI 80.0 MB/s ST (25
ns, offset 127)
[    4.099387] scsi: killing requests for dead queue
[    4.101385] scsi: killing requests for dead queue
[    4.103979] ehci_hcd 0000:02:03.0: USB 2.0 started, EHCI 1.00
[    4.105974] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
[    4.109224] usb usb1: New USB device strings: Mfr=3, Product=2,
SerialNumber=1
[    4.111473] usb usb1: Product: EHCI Host Controller
[    4.111506] usb usb1: Manufacturer: Linux 3.0.10-grsec ehci_hcd
[    4.111539] usb usb1: SerialNumber: 0000:02:03.0
[    4.111757] scsi: killing requests for dead queue
[    4.113136] scsi: killing requests for dead queue
[    4.114438] scsi: killing requests for dead queue
[    4.116253] scsi: killing requests for dead queue
[    4.117821] scsi: killing requests for dead queue
[    4.122604] scsi: killing requests for dead queue
[    4.126040] hub 1-0:1.0: USB hub found
[    4.126073] hub 1-0:1.0: 6 ports detected
[    4.139315] scsi: killing requests for dead queue
[    4.142064] scsi: killing requests for dead queue
[    4.143436] uhci_hcd: USB Universal Host Controller Interface driver
[    4.146357] uhci_hcd 0000:02:00.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18
[    4.152099] uhci_hcd 0000:02:00.0: UHCI Host Controller
[    4.152132] uhci_hcd 0000:02:00.0: new USB bus registered, assigned
bus number 2
[    4.158260] scsi: killing requests for dead queue
[    4.159641] scsi: killing requests for dead queue
[    4.160865] scsi: killing requests for dead queue
[    4.165792] uhci_hcd 0000:02:00.0: irq 18, io base 0x00002080
[    4.165825] usb usb2: New USB device found, idVendor=1d6b, idProduct=0001
[    4.169141] usb usb2: New USB device strings: Mfr=3, Product=2,
SerialNumber=1
[    4.169174] usb usb2: Product: UHCI Host Controller
[    4.172529] usb usb2: Manufacturer: Linux 3.0.10-grsec uhci_hcd
[    4.172562] usb usb2: SerialNumber: 0000:02:00.0
[    4.172927] scsi: killing requests for dead queue
[    4.174239] scsi: killing requests for dead queue
[    4.195935] hub 2-0:1.0: USB hub found
[    4.195968] hub 2-0:1.0: 2 ports detected
[    4.203022] sd 0:0:0:0: [sda] 16777216 512-byte logical blocks:
(8.58 GB/8.00 GiB)
[    4.206046] sd 0:0:0:0: [sda] Write Protect is off
[    4.207352] sd 0:0:0:0: [sda] Cache data unavailable
[    4.208560] sd 0:0:0:0: [sda] Assuming drive cache: write through
[    4.226139] sd 0:0:0:0: [sda] Cache data unavailable
[    4.227275] sd 0:0:0:0: [sda] Assuming drive cache: write through
[    4.236917]  sda: sda1 sda2 sda3
[    4.256216] sd 0:0:0:0: [sda] Cache data unavailable
[    4.257412] sd 0:0:0:0: [sda] Assuming drive cache: write through
[    4.257445] sd 0:0:0:0: [sda] Attached SCSI disk
[    4.389147] scsi1 : ata_piix
[    4.402479] scsi2 : ata_piix
[    4.417344] ata1: PATA max UDMA/33 cmd 0x1f0 ctl 0x3f6 bmdma 0x10c0 irq 14
[    4.419236] ata2: PATA max UDMA/33 cmd 0x170 ctl 0x376 bmdma 0x10c8 irq 15
[    4.432472] usb 1-1: new high speed USB device number 2 using ehci_hcd
[    4.662732] ata2.00: ATAPI: VMware Virtual IDE CDROM Drive,
00000001, max UDMA/33
[    4.679306] ata2.00: configured for UDMA/33
[    4.680353] scsi 2:0:0:0: CD-ROM            NECVMWar VMware IDE
CDR10 1.00 PQ: 0 ANSI: 5
[    4.803876] usb 1-1: New USB device found, idVendor=05ac, idProduct=8403
[    4.807533] usb 1-1: New USB device strings: Mfr=3, Product=4, SerialNumber=2
[    4.808425] usb 1-1: Product: Card Reader
[    4.808465] usb 1-1: Manufacturer: Apple
[    4.812250] usb 1-1: SerialNumber: 000000009833
[    4.833476] sr0: scsi3-mmc drive: 1x/1x writer dvd-ram cd/rw
xa/form2 cdda tray
[    4.835956] cdrom: Uniform CD-ROM driver Revision: 3.20
[    4.842435] scsi3 : usb-storage 1-1:1.0
ok.
 * Setting up framebuffer console: ok.
 * Mounting boot media: [    4.972499] usb 2-1: new full speed USB
device number 2 using uhci_hcd
[    5.108156] usb 2-1: New USB device found, idVendor=0e0f, idProduct=0003
[    5.111553] usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[    5.114070] usb 2-1: Product: VMware Virtual USB Mouse
[    5.115337] usb 2-1: Manufacturer: VMware
[    5.229114] usb 2-2: new full speed USB device number 3 using uhci_hcd
[    5.358748] usb 2-2: New USB device found, idVendor=0e0f, idProduct=0002
[    5.361617] usb 2-2: New USB device strings: Mfr=0, Product=1, SerialNumber=0
[    5.365356] usb 2-2: Product: VMware Virtual USB Hub
[    5.369735] hub 2-2:1.0: USB hub found
[    5.371020] hub 2-2:1.0: 7 ports detected
[    5.646073] usb 2-2.1: new full speed USB device number 4 using uhci_hcd
[    5.741642] usb 2-2.1: New USB device found, idVendor=0e0f, idProduct=0008
[    5.743733] usb 2-2.1: New USB device strings: Mfr=1, Product=2,
SerialNumber=3
[    5.746592] usb 2-2.1: Product: Virtual Bluetooth Adapter
[    5.749742] usb 2-2.1: Manufacturer: VMware
[    5.749747] usb 2-2.1: SerialNumber: 000650268328
[    5.859651] scsi 3:0:0:0: Direct-Access     APPLE    SD Card Reader
  1.00 PQ: 0 ANSI: 0
[    5.859740] scsi: killing requests for dead queue
[    5.859814] scsi: killing requests for dead queue
[    5.862242] scsi: killing requests for dead queue
[    5.862703] scsi: killing requests for dead queue
[    5.862779] scsi: killing requests for dead queue
[    5.862852] scsi: killing requests for dead queue
[    5.867651] scsi: killing requests for dead queue
[    5.872527] scsi: killing requests for dead queue
[    5.943255] sd 3:0:0:0: [sdb] 15548416 512-byte logical blocks:
(7.96 GB/7.41 GiB)
[    5.948616] sd 3:0:0:0: [sdb] Write Protect is off
[    5.954270] sd 3:0:0:0: [sdb] No Caching mode page present
[    5.955902] sd 3:0:0:0: [sdb] Assuming drive cache: write through
[    5.967194] sd 3:0:0:0: [sdb] No Caching mode page present
[    5.969206] sd 3:0:0:0: [sdb] Assuming drive cache: write through
[    5.971050]  sdb: sdb1
[    5.985108] sd 3:0:0:0: [sdb] No Caching mode page present
[    5.991589] sd 3:0:0:0: [sdb] Assuming drive cache: write through
[    5.991625] sd 3:0:0:0: [sdb] Attached SCSI removable disk
ok.
 * Loading user settings from /media/usb/loki.apkovl.tar.gz: ok.
 * Installing packages to root filesystem:
ok.


   OpenRC 0.9.7.58f1ef2 is starting up Linux 3.0.10-grsec (x86_64) [XENU]

 * /proc is already mounted, skipping
 * Mounting /run ... [ ok ]
 * /run/lock: creating directory
 * Mounting xenfs ... [ ok ]
 * Caching service dependencies ... [ ok ]
 * Mounting security filesystem ... [ ok ]
 * Mounting debug filesystem ... [ ok ]
 * Mounting cgroup filesystem ... [ ok ]
 * creating openrc control group ... [ ok ]
 * Starting busybox mdev ... [ ok ]
 * /dev is already mounted
 * Starting udevd ... [ ok ]
 * Populating /dev with existing devices through uevents ... [ ok ]
 * Waiting for uevents to be processed ... [ ok ]
 * Mounting modloop /media/usb/boot/grsec.modloop.squashfs ... [ ok ]
 * Loading hardware drivers ...Loading acpi:ACPI0003:
Loading acpi:LNXCPU:
Loading acpi:LNXPWRBN:
[   23.080837] BUG: unable to handle kernel paging request at ffffe8ffffd3bfc4
[   23.087991] IP: [<ffffffff81062026>] module_refcount+0x2e/0x99
[   23.091743] PGD 351d6067 PUD 351d7067 PMD 35288067 PTE 0
[   23.094530] Oops: 0000 [#1] SMP
[   23.095852] CPU 0
[   23.096561] Modules linked in: processor ac nls_iso8859_1 nls_cp437
vfat fat sr_mod cdrom ata_generic ata_piix pata_acpi libata uhci_hcd
ehci_hcd mptspi mptscsih mptbase scsi_transport_spi floppy usb_storage
usb_libusual usbcore sd_mod scsi_mod squashfs loop
[   23.121165]
[   23.121801] Pid: 1626, comm: modprobe Not tainted 3.0.10-grsec
#1-Alpine VMware, Inc. VMware Virtual Platform/440BX Desktop Reference
Platform
[   23.128242] RIP: e030:[<ffffffff81062026>]  [<ffffffff81062026>]
module_refcount+0x2e/0x99
[   23.134994] RSP: e02b:ffff8800351ddd88  EFLAGS: 00010287
[   23.136997] RAX: 0000000000000001 RBX: 0000000000000001 RCX: ffff88003aea8000
[   23.140113] RDX: 000060ffc4e93fc0 RSI: 0000000000000020 RDI: 0000000000000020
[   23.143939] RBP: ffff8800351ddda8 R08: 0000000000000000 R09: ffffffff814aa520
[   23.146656] R10: ffff8800345d5000 R11: 0000000000000000 R12: ffffffff814aa520
[   23.149354] R13: ffffffffa014b7a0 R14: 0000000000001000 R15: ffffffffa014b968
[   23.157673] FS:  00005fb0175646a0(0000) GS:ffff88003ae91000(0000)
knlGS:0000000000000000
[   23.162354] CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
[   23.164736] CR2: ffffe8ffffd3bfc4 CR3: 00000000339b3000 CR4: 0000000000000660
[   23.167954] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[   23.170719] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[   23.174109] Process modprobe (pid: 1626, threadinfo
ffff88003477ab58, task ffff88003477a760)
[   23.178661] Stack:
[   23.179466]  ffffffffa014b7a8 ffff880034334300 ffffffffa014b7a0
0000000000001000
[   23.182787]  ffff8800351dddf8 ffffffff8106211c ffff880035300420
00005fb016cffd10
[   23.189494]  ffff8800351dddf8 ffff880034334300 0000000000000000
00000fecda0bcd90
[   23.198618] Call Trace:
[   23.200624]  [<ffffffff8106211c>] m_show+0x54/0x16b
[   23.202512]  [<ffffffff810d1b5c>] seq_read+0x247/0x51f
[   23.204483]  [<ffffffff810fccc2>] proc_reg_read+0x6c/0x85
[   23.206543]  [<ffffffff810b614f>] vfs_read+0x104/0x198
[   23.208909]  [<ffffffff810b6228>] sys_read+0x45/0x6c
[   23.211075]  [<ffffffff812aa14b>] system_call_fastpath+0x16/0x1b
[   23.215796]  [<ffffffff812aa0e9>] ? system_call_after_swapgs+0x19/0x65
[   23.219196] Code: ff 48 89 e5 41 56 41 55 49 89 fd 41 54 4c 8b 25
79 12 29 00 53 31 db eb 16 48 63 c8 49 8b 95 f8 01 00 00 48 8b 0c cd
50 60 3a 81
[   23.228774]  5c 0a 04 ff c0 be 20 00 00 00 4c 89 e7 48 63 d0 e8 34 24 0e
[   23.235223] RIP  [<ffffffff81062026>] module_refcount+0x2e/0x99
[   23.240718]  RSP <ffff8800351ddd88>
[   23.243912] CR2: ffffe8ffffd3bfc4
[   23.245256] ---[ end trace 4763addd9fb226e5 ]---
Killed
Loading acpi:LNXSYSTM:

I've changed the init script to load each module separatedly, instead
of doing a modprobe -a <all modules>, if I loaded all the modules at
once the system crashed instead of freezing. The problem seems to be
related to acpi, and the modules are loaded from a squashfs image
mounted on loop0. Does anyone know what might be causing this issue or
if there is a possible fix?

Thanks, Roger.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Dec 24 12:31:53 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 24 Dec 2011 12: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.xensource.com>)
	id 1ReQkO-0003Ji-3y; Sat, 24 Dec 2011 12:30:44 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mmrezaie@gmail.com>) id 1ReQkN-0003Jd-5v
	for xen-devel@lists.xensource.com; Sat, 24 Dec 2011 12:30:43 +0000
X-Env-Sender: mmrezaie@gmail.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1324729792!50260029!1
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20360 invoked from network); 24 Dec 2011 12:29:52 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Dec 2011 12:29:52 -0000
Received: by wgbds11 with SMTP id ds11so15878908wgb.24
	for <xen-devel@lists.xensource.com>;
	Sat, 24 Dec 2011 04:30:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=message-id:date:from:user-agent:mime-version:to:subject
	:content-type:content-transfer-encoding;
	bh=B8zpy1Z4lM9Pw4/dfK60pHhm2Xky7UWqAQ236tSeQo4=;
	b=H0HSC5Q7hS2xXFKKp1g9mbb0l0a6VFPDPJ2bvl2912ouSMUEi2sgMAgccMX18HkhC1
	Nz2QH4Uf3bGBrm5kSiuPDt3s+M87EJgSVxQhCN3sT0/uw2HcBlv9GFDqdwI8+8BBEhZ9
	6tT9ckJkzaUex+65bNDOTYeCW/vTxAwNObhck=
Received: by 10.227.59.204 with SMTP id m12mr17717192wbh.10.1324729838987;
	Sat, 24 Dec 2011 04:30:38 -0800 (PST)
Received: from [192.168.50.99] ([81.28.34.226])
	by mx.google.com with ESMTPS id u5sm17178647wbm.2.2011.12.24.04.30.37
	(version=SSLv3 cipher=OTHER); Sat, 24 Dec 2011 04:30:38 -0800 (PST)
Message-ID: <4EF5C5EB.5090005@gmail.com>
Date: Sat, 24 Dec 2011 16:00:35 +0330
From: Mohamad Rezaei <mmrezaie@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:8.0) Gecko/20111124 Thunderbird/8.0
MIME-Version: 1.0
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] question about xen memory management when shadow paging
 is enabled in Dom0!
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

what is the relationship between virtual gdt in xen, and shadow page
table of vm in xen? I want to determine the type of a page (is it data,
or code) from xen. For this I have vtx, and shadow paging enabled in
Dom0. I don't have any domU running.
-- 
Best Regards,
Mohamad Rezaei

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Dec 24 12:31:53 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 24 Dec 2011 12: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.xensource.com>)
	id 1ReQkO-0003Ji-3y; Sat, 24 Dec 2011 12:30:44 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mmrezaie@gmail.com>) id 1ReQkN-0003Jd-5v
	for xen-devel@lists.xensource.com; Sat, 24 Dec 2011 12:30:43 +0000
X-Env-Sender: mmrezaie@gmail.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1324729792!50260029!1
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20360 invoked from network); 24 Dec 2011 12:29:52 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Dec 2011 12:29:52 -0000
Received: by wgbds11 with SMTP id ds11so15878908wgb.24
	for <xen-devel@lists.xensource.com>;
	Sat, 24 Dec 2011 04:30:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=message-id:date:from:user-agent:mime-version:to:subject
	:content-type:content-transfer-encoding;
	bh=B8zpy1Z4lM9Pw4/dfK60pHhm2Xky7UWqAQ236tSeQo4=;
	b=H0HSC5Q7hS2xXFKKp1g9mbb0l0a6VFPDPJ2bvl2912ouSMUEi2sgMAgccMX18HkhC1
	Nz2QH4Uf3bGBrm5kSiuPDt3s+M87EJgSVxQhCN3sT0/uw2HcBlv9GFDqdwI8+8BBEhZ9
	6tT9ckJkzaUex+65bNDOTYeCW/vTxAwNObhck=
Received: by 10.227.59.204 with SMTP id m12mr17717192wbh.10.1324729838987;
	Sat, 24 Dec 2011 04:30:38 -0800 (PST)
Received: from [192.168.50.99] ([81.28.34.226])
	by mx.google.com with ESMTPS id u5sm17178647wbm.2.2011.12.24.04.30.37
	(version=SSLv3 cipher=OTHER); Sat, 24 Dec 2011 04:30:38 -0800 (PST)
Message-ID: <4EF5C5EB.5090005@gmail.com>
Date: Sat, 24 Dec 2011 16:00:35 +0330
From: Mohamad Rezaei <mmrezaie@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:8.0) Gecko/20111124 Thunderbird/8.0
MIME-Version: 1.0
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] question about xen memory management when shadow paging
 is enabled in Dom0!
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

what is the relationship between virtual gdt in xen, and shadow page
table of vm in xen? I want to determine the type of a page (is it data,
or code) from xen. For this I have vtx, and shadow paging enabled in
Dom0. I don't have any domU running.
-- 
Best Regards,
Mohamad Rezaei

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Dec 24 12:37:41 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 24 Dec 2011 12:37:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1ReQqH-0003S5-UB; Sat, 24 Dec 2011 12:36:49 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mmrezaie@gmail.com>) id 1ReQqG-0003Rs-Aw
	for xen-devel@lists.xensource.com; Sat, 24 Dec 2011 12:36:48 +0000
X-Env-Sender: mmrezaie@gmail.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1324730201!9418433!1
X-Originating-IP: [209.85.212.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11114 invoked from network); 24 Dec 2011 12:36:42 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Dec 2011 12:36:42 -0000
Received: by wico1 with SMTP id o1so9467046wic.30
	for <xen-devel@lists.xensource.com>;
	Sat, 24 Dec 2011 04:36:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=message-id:date:from:user-agent:mime-version:to:subject
	:content-type:content-transfer-encoding;
	bh=UCkKlplSuMlJuuBWLbkbhefRGKlNDX9gZIGZwE8kOg8=;
	b=VoufJo0GtUEc8Oqqu2tFjwJ253dbQovgscVkyr46BbXRK0qokIn0x6qckEbteujEyJ
	veX5h043xMZ/vRcQl6G4IsRfydJx5ccKDOHJ80gLOIISO99oSHnyOj7ie7CQ+HpIFNor
	bN055kgchQ2Jo0WQIOZz35opWfvj/9jqpq6eQ=
Received: by 10.180.72.133 with SMTP id d5mr40080428wiv.7.1324730201604;
	Sat, 24 Dec 2011 04:36:41 -0800 (PST)
Received: from [192.168.50.99] ([81.28.34.226])
	by mx.google.com with ESMTPS id ez4sm4682441wbb.5.2011.12.24.04.36.40
	(version=SSLv3 cipher=OTHER); Sat, 24 Dec 2011 04:36:41 -0800 (PST)
Message-ID: <4EF5C756.4070403@gmail.com>
Date: Sat, 24 Dec 2011 16:06:38 +0330
From: Mohamad Rezaei <mmrezaie@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:8.0) Gecko/20111124 Thunderbird/8.0
MIME-Version: 1.0
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] mapping virtual address to corresponding shadow page in
	xen
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

hi,

How can I get corresponding shadowed page number of a virtual address in vm?

-- 
Best Regards,
Mohamad Rezaei

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Dec 24 12:37:41 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 24 Dec 2011 12:37:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1ReQqH-0003S5-UB; Sat, 24 Dec 2011 12:36:49 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mmrezaie@gmail.com>) id 1ReQqG-0003Rs-Aw
	for xen-devel@lists.xensource.com; Sat, 24 Dec 2011 12:36:48 +0000
X-Env-Sender: mmrezaie@gmail.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1324730201!9418433!1
X-Originating-IP: [209.85.212.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11114 invoked from network); 24 Dec 2011 12:36:42 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Dec 2011 12:36:42 -0000
Received: by wico1 with SMTP id o1so9467046wic.30
	for <xen-devel@lists.xensource.com>;
	Sat, 24 Dec 2011 04:36:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=message-id:date:from:user-agent:mime-version:to:subject
	:content-type:content-transfer-encoding;
	bh=UCkKlplSuMlJuuBWLbkbhefRGKlNDX9gZIGZwE8kOg8=;
	b=VoufJo0GtUEc8Oqqu2tFjwJ253dbQovgscVkyr46BbXRK0qokIn0x6qckEbteujEyJ
	veX5h043xMZ/vRcQl6G4IsRfydJx5ccKDOHJ80gLOIISO99oSHnyOj7ie7CQ+HpIFNor
	bN055kgchQ2Jo0WQIOZz35opWfvj/9jqpq6eQ=
Received: by 10.180.72.133 with SMTP id d5mr40080428wiv.7.1324730201604;
	Sat, 24 Dec 2011 04:36:41 -0800 (PST)
Received: from [192.168.50.99] ([81.28.34.226])
	by mx.google.com with ESMTPS id ez4sm4682441wbb.5.2011.12.24.04.36.40
	(version=SSLv3 cipher=OTHER); Sat, 24 Dec 2011 04:36:41 -0800 (PST)
Message-ID: <4EF5C756.4070403@gmail.com>
Date: Sat, 24 Dec 2011 16:06:38 +0330
From: Mohamad Rezaei <mmrezaie@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:8.0) Gecko/20111124 Thunderbird/8.0
MIME-Version: 1.0
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] mapping virtual address to corresponding shadow page in
	xen
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

hi,

How can I get corresponding shadowed page number of a virtual address in vm?

-- 
Best Regards,
Mohamad Rezaei

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Dec 24 12:50:36 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 24 Dec 2011 12: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.xensource.com>)
	id 1ReR2n-0003e8-92; Sat, 24 Dec 2011 12:49:45 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1ReR2m-0003e3-Is
	for xen-devel@lists.xensource.com; Sat, 24 Dec 2011 12:49:44 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-2.tower-216.messagelabs.com!1324730978!10005202!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15689 invoked from network); 24 Dec 2011 12:49:38 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-2.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Dec 2011 12:49:38 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1ReR2f-000HOM-BB; Sat, 24 Dec 2011 12:49:37 +0000
Date: Sat, 24 Dec 2011 12:49:37 +0000
From: Tim Deegan <tim@xen.org>
To: Mohamad Rezaei <mmrezaie@gmail.com>
Message-ID: <20111224124937.GB63360@ocelot.phlegethon.org>
References: <4EF5C756.4070403@gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4EF5C756.4070403@gmail.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] mapping virtual address to corresponding shadow
	page in xen
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 16:06 +0330 on 24 Dec (1324742798), Mohamad Rezaei wrote:
> hi,
> 
> How can I get corresponding shadowed page number of a virtual address in vm?

I'm afraid I don't know what you mean. 

Please read this: http://wiki.xen.org/wiki/AskingXenDevelQuestions
and try again.

Cheers,

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Dec 24 12:50:36 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 24 Dec 2011 12: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.xensource.com>)
	id 1ReR2n-0003e8-92; Sat, 24 Dec 2011 12:49:45 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1ReR2m-0003e3-Is
	for xen-devel@lists.xensource.com; Sat, 24 Dec 2011 12:49:44 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-2.tower-216.messagelabs.com!1324730978!10005202!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15689 invoked from network); 24 Dec 2011 12:49:38 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-2.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Dec 2011 12:49:38 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1ReR2f-000HOM-BB; Sat, 24 Dec 2011 12:49:37 +0000
Date: Sat, 24 Dec 2011 12:49:37 +0000
From: Tim Deegan <tim@xen.org>
To: Mohamad Rezaei <mmrezaie@gmail.com>
Message-ID: <20111224124937.GB63360@ocelot.phlegethon.org>
References: <4EF5C756.4070403@gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4EF5C756.4070403@gmail.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] mapping virtual address to corresponding shadow
	page in xen
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 16:06 +0330 on 24 Dec (1324742798), Mohamad Rezaei wrote:
> hi,
> 
> How can I get corresponding shadowed page number of a virtual address in vm?

I'm afraid I don't know what you mean. 

Please read this: http://wiki.xen.org/wiki/AskingXenDevelQuestions
and try again.

Cheers,

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Dec 24 12:57:53 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 24 Dec 2011 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.xensource.com>)
	id 1ReRA7-0003o9-5b; Sat, 24 Dec 2011 12:57:19 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mmrezaie@gmail.com>) id 1ReRA5-0003o2-Qx
	for xen-devel@lists.xensource.com; Sat, 24 Dec 2011 12:57:18 +0000
X-Env-Sender: mmrezaie@gmail.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1324731431!6566332!1
X-Originating-IP: [74.125.83.43]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25478 invoked from network); 24 Dec 2011 12:57:11 -0000
Received: from mail-ee0-f43.google.com (HELO mail-ee0-f43.google.com)
	(74.125.83.43)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Dec 2011 12:57:11 -0000
Received: by eekd4 with SMTP id d4so50495278eek.30
	for <xen-devel@lists.xensource.com>;
	Sat, 24 Dec 2011 04:57:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:content-type; bh=0p8rAbW+AuYvolposf1TpxnN/y4O/3U2VCnaIWptAMk=;
	b=xnljRr/90GwLJTjJGdaGePFPEYSqo2arZZotBuXovOF77s0WPkFYlrWMMq6vb8FHwp
	AOhOgtvIdPZ9JA0sVAybWpubiWaGFqnnNIYe6j7kWo95A2fWmK7pHcndn2h+SCzYXC9u
	Fh8PZGl/O+wEIbJKV5NIMI++EJHEnXcsz301s=
Received: by 10.213.114.80 with SMTP id d16mr6956919ebq.77.1324731430765; Sat,
	24 Dec 2011 04:57:10 -0800 (PST)
MIME-Version: 1.0
Received: by 10.213.100.3 with HTTP; Sat, 24 Dec 2011 04:56:49 -0800 (PST)
In-Reply-To: <20111224124937.GB63360@ocelot.phlegethon.org>
References: <4EF5C756.4070403@gmail.com>
	<20111224124937.GB63360@ocelot.phlegethon.org>
From: Mohamad Rezaei <mmrezaie@gmail.com>
Date: Sat, 24 Dec 2011 16:26:49 +0330
Message-ID: <CAK6aU6g1+wx4iVcO_9gtaGxXa-tnz50MuqW401TLdG2V=FK-8w@mail.gmail.com>
To: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] mapping virtual address to corresponding shadow
 page in xen
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

My question is when I want to read a data from domain, I use
copy_from_guest. but now I want to map that address in domain (guest)
to an address inside xen (hypervisor). I need to translate that
address. somehow like this: gva -> gpfn -> gmfn -> mfn. To do this I
have started a dom0 with dom0_shadow=1 option. So I presume that vtx
is enabled for dom0.

Best Regards
Mohamad Rezaei
--------------------
Distributed Systems Research Laboratory
Computer Engineering Department
Iran University of Science and Technology



On Sat, Dec 24, 2011 at 4:19 PM, Tim Deegan <tim@xen.org> wrote:
> At 16:06 +0330 on 24 Dec (1324742798), Mohamad Rezaei wrote:
>> hi,
>>
>> How can I get corresponding shadowed page number of a virtual address in vm?
>
> I'm afraid I don't know what you mean.
>
> Please read this: http://wiki.xen.org/wiki/AskingXenDevelQuestions
> and try again.
>
> Cheers,
>
> Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Dec 24 12:57:53 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 24 Dec 2011 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.xensource.com>)
	id 1ReRA7-0003o9-5b; Sat, 24 Dec 2011 12:57:19 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mmrezaie@gmail.com>) id 1ReRA5-0003o2-Qx
	for xen-devel@lists.xensource.com; Sat, 24 Dec 2011 12:57:18 +0000
X-Env-Sender: mmrezaie@gmail.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1324731431!6566332!1
X-Originating-IP: [74.125.83.43]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25478 invoked from network); 24 Dec 2011 12:57:11 -0000
Received: from mail-ee0-f43.google.com (HELO mail-ee0-f43.google.com)
	(74.125.83.43)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Dec 2011 12:57:11 -0000
Received: by eekd4 with SMTP id d4so50495278eek.30
	for <xen-devel@lists.xensource.com>;
	Sat, 24 Dec 2011 04:57:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:content-type; bh=0p8rAbW+AuYvolposf1TpxnN/y4O/3U2VCnaIWptAMk=;
	b=xnljRr/90GwLJTjJGdaGePFPEYSqo2arZZotBuXovOF77s0WPkFYlrWMMq6vb8FHwp
	AOhOgtvIdPZ9JA0sVAybWpubiWaGFqnnNIYe6j7kWo95A2fWmK7pHcndn2h+SCzYXC9u
	Fh8PZGl/O+wEIbJKV5NIMI++EJHEnXcsz301s=
Received: by 10.213.114.80 with SMTP id d16mr6956919ebq.77.1324731430765; Sat,
	24 Dec 2011 04:57:10 -0800 (PST)
MIME-Version: 1.0
Received: by 10.213.100.3 with HTTP; Sat, 24 Dec 2011 04:56:49 -0800 (PST)
In-Reply-To: <20111224124937.GB63360@ocelot.phlegethon.org>
References: <4EF5C756.4070403@gmail.com>
	<20111224124937.GB63360@ocelot.phlegethon.org>
From: Mohamad Rezaei <mmrezaie@gmail.com>
Date: Sat, 24 Dec 2011 16:26:49 +0330
Message-ID: <CAK6aU6g1+wx4iVcO_9gtaGxXa-tnz50MuqW401TLdG2V=FK-8w@mail.gmail.com>
To: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] mapping virtual address to corresponding shadow
 page in xen
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

My question is when I want to read a data from domain, I use
copy_from_guest. but now I want to map that address in domain (guest)
to an address inside xen (hypervisor). I need to translate that
address. somehow like this: gva -> gpfn -> gmfn -> mfn. To do this I
have started a dom0 with dom0_shadow=1 option. So I presume that vtx
is enabled for dom0.

Best Regards
Mohamad Rezaei
--------------------
Distributed Systems Research Laboratory
Computer Engineering Department
Iran University of Science and Technology



On Sat, Dec 24, 2011 at 4:19 PM, Tim Deegan <tim@xen.org> wrote:
> At 16:06 +0330 on 24 Dec (1324742798), Mohamad Rezaei wrote:
>> hi,
>>
>> How can I get corresponding shadowed page number of a virtual address in vm?
>
> I'm afraid I don't know what you mean.
>
> Please read this: http://wiki.xen.org/wiki/AskingXenDevelQuestions
> and try again.
>
> Cheers,
>
> Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Dec 25 04:49:34 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 25 Dec 2011 04:49:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Reg0n-0004aV-83; Sun, 25 Dec 2011 04:48:41 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Reg0m-0004aQ-F0
	for xen-devel@lists.xensource.com; Sun, 25 Dec 2011 04:48:40 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1324788462!62024806!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODQ5MA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32203 invoked from network); 25 Dec 2011 04:47:42 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Dec 2011 04:47:42 -0000
X-IronPort-AV: E=Sophos;i="4.71,406,1320624000"; 
   d="scan'208";a="9672579"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Dec 2011 04:48:38 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sun, 25 Dec 2011 04:48:38 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1Reg0k-0006fv-7z;
	Sun, 25 Dec 2011 04:48:38 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Reg0k-00048j-3I;
	Sun, 25 Dec 2011 04:48:38 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10608-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 25 Dec 2011 04:48:38 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10608: tolerable FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10608 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10608/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf      7 debian-install              fail pass in 10607
 test-amd64-amd64-xl-sedf-pin 14 guest-localmigrate/x10 fail in 10607 pass in 10608
 test-amd64-amd64-xl          16 guest-start.2      fail in 10607 pass in 10608
 test-amd64-amd64-xl-win       7 windows-install    fail in 10607 pass in 10608

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf    14 guest-localmigrate/x10 fail in 10607 like 10600

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass

version targeted for testing:
 xen                  2863b2f43a3b
baseline version:
 xen                  2863b2f43a3b

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Dec 25 04:49:34 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 25 Dec 2011 04:49:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Reg0n-0004aV-83; Sun, 25 Dec 2011 04:48:41 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Reg0m-0004aQ-F0
	for xen-devel@lists.xensource.com; Sun, 25 Dec 2011 04:48:40 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1324788462!62024806!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODQ5MA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32203 invoked from network); 25 Dec 2011 04:47:42 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Dec 2011 04:47:42 -0000
X-IronPort-AV: E=Sophos;i="4.71,406,1320624000"; 
   d="scan'208";a="9672579"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Dec 2011 04:48:38 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sun, 25 Dec 2011 04:48:38 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1Reg0k-0006fv-7z;
	Sun, 25 Dec 2011 04:48:38 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Reg0k-00048j-3I;
	Sun, 25 Dec 2011 04:48:38 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10608-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 25 Dec 2011 04:48:38 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10608: tolerable FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10608 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10608/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf      7 debian-install              fail pass in 10607
 test-amd64-amd64-xl-sedf-pin 14 guest-localmigrate/x10 fail in 10607 pass in 10608
 test-amd64-amd64-xl          16 guest-start.2      fail in 10607 pass in 10608
 test-amd64-amd64-xl-win       7 windows-install    fail in 10607 pass in 10608

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf    14 guest-localmigrate/x10 fail in 10607 like 10600

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass

version targeted for testing:
 xen                  2863b2f43a3b
baseline version:
 xen                  2863b2f43a3b

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Dec 25 12:20:32 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 25 Dec 2011 12:20:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ren38-0007W0-R8; Sun, 25 Dec 2011 12:19:34 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mmrezaie@gmail.com>) id 1Ren37-0007Vv-1X
	for xen-devel@lists.xensource.com; Sun, 25 Dec 2011 12:19:33 +0000
X-Env-Sender: mmrezaie@gmail.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1324815565!9137374!1
X-Originating-IP: [209.85.212.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5230 invoked from network); 25 Dec 2011 12:19:26 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Dec 2011 12:19:26 -0000
Received: by wico1 with SMTP id o1so10388303wic.30
	for <xen-devel@lists.xensource.com>;
	Sun, 25 Dec 2011 04:19:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=message-id:date:from:user-agent:mime-version:to:subject
	:content-type:content-transfer-encoding;
	bh=hytN6T6EAslRfPRAhctFaCNibNPdG2uMCi/sjeJ+4I4=;
	b=GDYUBUtpug9MVyDiYCskktsxX/fH/ThGmBo/WMADNF5Gpqm4xRgBT1WDjzw6mNu3Xh
	C/Hvl/bgdjuiEPMmzwzWSb/tlIQX2S1Fn4+ajPKLXbrkXW0da63626toim7APsU8SC1h
	lQCRkdQl9gEyNDmoZw399r7m9jilG5u6oADog=
Received: by 10.180.79.35 with SMTP id g3mr46104122wix.19.1324815565100;
	Sun, 25 Dec 2011 04:19:25 -0800 (PST)
Received: from [192.168.50.99] ([81.28.34.226])
	by mx.google.com with ESMTPS id em4sm20654792wbb.20.2011.12.25.04.19.23
	(version=SSLv3 cipher=OTHER); Sun, 25 Dec 2011 04:19:24 -0800 (PST)
Message-ID: <4EF714C9.5010007@gmail.com>
Date: Sun, 25 Dec 2011 15:49:21 +0330
From: Mohamad Rezaei <mmrezaie@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:8.0) Gecko/20111124 Thunderbird/8.0
MIME-Version: 1.0
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] how to debug xen itself?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

hi,

I am trying to debug xen hypervisor through gdb, and its kgdb. I have
compiled xen with these options: --> make debug=y optimize=0
crash_debug=y CMDLINE="console=com1 gdb=com1 earlygdb=y" -j8

I was expecting xen to stop, and wait for my gdb connection through
serial port, but it boots up flawlessly. I am not sure what is my
problem. Should I do something other than that.

I am doing this because I want to use debugger to get better view of xen
internals.

-- 
Best Regards,
Mohamad Rezaei

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Dec 25 12:20:32 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 25 Dec 2011 12:20:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ren38-0007W0-R8; Sun, 25 Dec 2011 12:19:34 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mmrezaie@gmail.com>) id 1Ren37-0007Vv-1X
	for xen-devel@lists.xensource.com; Sun, 25 Dec 2011 12:19:33 +0000
X-Env-Sender: mmrezaie@gmail.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1324815565!9137374!1
X-Originating-IP: [209.85.212.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5230 invoked from network); 25 Dec 2011 12:19:26 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Dec 2011 12:19:26 -0000
Received: by wico1 with SMTP id o1so10388303wic.30
	for <xen-devel@lists.xensource.com>;
	Sun, 25 Dec 2011 04:19:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=message-id:date:from:user-agent:mime-version:to:subject
	:content-type:content-transfer-encoding;
	bh=hytN6T6EAslRfPRAhctFaCNibNPdG2uMCi/sjeJ+4I4=;
	b=GDYUBUtpug9MVyDiYCskktsxX/fH/ThGmBo/WMADNF5Gpqm4xRgBT1WDjzw6mNu3Xh
	C/Hvl/bgdjuiEPMmzwzWSb/tlIQX2S1Fn4+ajPKLXbrkXW0da63626toim7APsU8SC1h
	lQCRkdQl9gEyNDmoZw399r7m9jilG5u6oADog=
Received: by 10.180.79.35 with SMTP id g3mr46104122wix.19.1324815565100;
	Sun, 25 Dec 2011 04:19:25 -0800 (PST)
Received: from [192.168.50.99] ([81.28.34.226])
	by mx.google.com with ESMTPS id em4sm20654792wbb.20.2011.12.25.04.19.23
	(version=SSLv3 cipher=OTHER); Sun, 25 Dec 2011 04:19:24 -0800 (PST)
Message-ID: <4EF714C9.5010007@gmail.com>
Date: Sun, 25 Dec 2011 15:49:21 +0330
From: Mohamad Rezaei <mmrezaie@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:8.0) Gecko/20111124 Thunderbird/8.0
MIME-Version: 1.0
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] how to debug xen itself?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

hi,

I am trying to debug xen hypervisor through gdb, and its kgdb. I have
compiled xen with these options: --> make debug=y optimize=0
crash_debug=y CMDLINE="console=com1 gdb=com1 earlygdb=y" -j8

I was expecting xen to stop, and wait for my gdb connection through
serial port, but it boots up flawlessly. I am not sure what is my
problem. Should I do something other than that.

I am doing this because I want to use debugger to get better view of xen
internals.

-- 
Best Regards,
Mohamad Rezaei

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 26 01:32:57 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 26 Dec 2011 01:32:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RezPw-00070t-6X; Mon, 26 Dec 2011 01:31:56 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <kevin.tian@intel.com>) id 1RezPu-00070o-K8
	for xen-devel@lists.xensource.com; Mon, 26 Dec 2011 01:31:54 +0000
X-Env-Sender: kevin.tian@intel.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1324863075!58025735!1
X-Originating-IP: [143.182.124.37]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjE2OTc0\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29099 invoked from network); 26 Dec 2011 01:31:16 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37)
	by server-9.tower-27.messagelabs.com with SMTP;
	26 Dec 2011 01:31:16 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga102.ch.intel.com with ESMTP; 25 Dec 2011 17:31:52 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="89435109"
Received: from pgsmsx603.gar.corp.intel.com ([10.221.43.87])
	by azsmga001.ch.intel.com with ESMTP; 25 Dec 2011 17:31:48 -0800
Received: from pgsmsx509.gar.corp.intel.com (172.30.13.17) by
	pgsmsx603.gar.corp.intel.com (10.221.43.87) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Mon, 26 Dec 2011 09:31:47 +0800
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	PGSMSX509.gar.corp.intel.com (172.30.13.17) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Mon, 26 Dec 2011 09:31:47 +0800
Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.199]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.223]) with mapi id
	14.01.0355.002; Mon, 26 Dec 2011 09:31:46 +0800
From: "Tian, Kevin" <kevin.tian@intel.com>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
Thread-Topic: [Xen-devel] [PATCH 3/8] ACPI: processor: add
	__acpi_processor_[un]register_driver helpers.
Thread-Index: AQHMwR8jSQj+OztfxUuz+mAW9L1uCZXtWRMw
Date: Mon, 26 Dec 2011 01:31:45 +0000
Message-ID: <AADFC41AFE54684AB9EE6CBC0274A5D10145B9@SHSMSX102.ccr.corp.intel.com>
References: <1322673664-14642-1-git-send-email-konrad.wilk@oracle.com>
	<1322673664-14642-4-git-send-email-konrad.wilk@oracle.com>
	<20111216220342.GC9832@phenom.dumpdata.com>
	<625BA99ED14B2D499DC4E29D8138F1506E01AABC7A@shsmsx502.ccr.corp.intel.com>
	<20111219142626.GB27772@andromeda.dapyr.net>
	<625BA99ED14B2D499DC4E29D8138F1506E01AAC03A@shsmsx502.ccr.corp.intel.com>
	<20111220153145.GB13253@andromeda.dapyr.net>
	<625BA99ED14B2D499DC4E29D8138F1506E01AAC469@shsmsx502.ccr.corp.intel.com>
	<20111223030103.GA7218@andromeda.dapyr.net>
In-Reply-To: <20111223030103.GA7218@andromeda.dapyr.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: "jeremy@goop.org" <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"mike.mcclurg@citrix.com" <mike.mcclurg@citrix.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"stefan.bader@canonical.com" <stefan.bader@canonical.com>,
	"rjw@sisk.pl" <rjw@sisk.pl>,
	"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
	"liang.tang@oracle.com" <liang.tang@oracle.com>, "Yu,
	Ke" <ke.yu@intel.com>, "konrad@kernel.org" <konrad@kernel.org>,
	"lenb@kernel.org" <lenb@kernel.org>
Subject: Re: [Xen-devel] [PATCH 3/8] ACPI: processor: add
 __acpi_processor_[un]register_driver helpers.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> From: Konrad Rzeszutek Wilk [mailto:konrad@darnok.org]
> Sent: Friday, December 23, 2011 11:01 AM
> 
> > > OK. Lets put the # VCPU != PCPU aside. Say dom0 will boot with all
> > > CPUs and then later on the admin starts unplugging them.
> >
> > This should be communicated to major Xen based distributions, so that it's
> > an agreed approach since in majority case dom0 is configured as UP or
> > a few VCPUs.
> 
> I am not saying that is it the agreed approach. There has to be
> flexibility in supporting both. But what I want to understand whether
> the requirement for VCPU != PCPU can be put aside and put in the drivers
> later on.

sure. VCPU!=PCPU requirement is orthogonal to the basic part for gearing
ACPI information to Xen.

> 
> So that the first approach is not changing the generic drivers (much).
> The reason I am asking about this is two-fold:
>  1). For new distros (Ubuntu, Fedora), the default is all VCPUs.

good to know that.

>      Enterprising users might use dom0_max_vcpus to limit the VCPU count,
>      but most won't.
>      Which mean we can concentrate on bringing the _Pxx/_Cxx parsing
>      up to the hypervisor. Which is really neccessary on any chipset
>      which has the notion of TurboBoost (otherwise the Xen scheduler
>      won't pick this up and won't engage this mode in certain
>      workloads).
>  2). The ACPI maintainers are busy with ACPI 5.0. I don't know how
>      much work this is, but it probably means tons of stuff with
>      embedded platforms and tons of regression testing. So if there
>      is a patch that does not impact the generic code much (or any)
>      it will make their life easier. Which also means we can built
>      on top that for the VCPU != PCPU case.
> 
> That is what I am trying to understand.

no problem. this incremental approach should work.

Thanks
Kevin

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 26 01:32:57 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 26 Dec 2011 01:32:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RezPw-00070t-6X; Mon, 26 Dec 2011 01:31:56 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <kevin.tian@intel.com>) id 1RezPu-00070o-K8
	for xen-devel@lists.xensource.com; Mon, 26 Dec 2011 01:31:54 +0000
X-Env-Sender: kevin.tian@intel.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1324863075!58025735!1
X-Originating-IP: [143.182.124.37]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjE2OTc0\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29099 invoked from network); 26 Dec 2011 01:31:16 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37)
	by server-9.tower-27.messagelabs.com with SMTP;
	26 Dec 2011 01:31:16 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga102.ch.intel.com with ESMTP; 25 Dec 2011 17:31:52 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="89435109"
Received: from pgsmsx603.gar.corp.intel.com ([10.221.43.87])
	by azsmga001.ch.intel.com with ESMTP; 25 Dec 2011 17:31:48 -0800
Received: from pgsmsx509.gar.corp.intel.com (172.30.13.17) by
	pgsmsx603.gar.corp.intel.com (10.221.43.87) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Mon, 26 Dec 2011 09:31:47 +0800
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	PGSMSX509.gar.corp.intel.com (172.30.13.17) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Mon, 26 Dec 2011 09:31:47 +0800
Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.199]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.223]) with mapi id
	14.01.0355.002; Mon, 26 Dec 2011 09:31:46 +0800
From: "Tian, Kevin" <kevin.tian@intel.com>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
Thread-Topic: [Xen-devel] [PATCH 3/8] ACPI: processor: add
	__acpi_processor_[un]register_driver helpers.
Thread-Index: AQHMwR8jSQj+OztfxUuz+mAW9L1uCZXtWRMw
Date: Mon, 26 Dec 2011 01:31:45 +0000
Message-ID: <AADFC41AFE54684AB9EE6CBC0274A5D10145B9@SHSMSX102.ccr.corp.intel.com>
References: <1322673664-14642-1-git-send-email-konrad.wilk@oracle.com>
	<1322673664-14642-4-git-send-email-konrad.wilk@oracle.com>
	<20111216220342.GC9832@phenom.dumpdata.com>
	<625BA99ED14B2D499DC4E29D8138F1506E01AABC7A@shsmsx502.ccr.corp.intel.com>
	<20111219142626.GB27772@andromeda.dapyr.net>
	<625BA99ED14B2D499DC4E29D8138F1506E01AAC03A@shsmsx502.ccr.corp.intel.com>
	<20111220153145.GB13253@andromeda.dapyr.net>
	<625BA99ED14B2D499DC4E29D8138F1506E01AAC469@shsmsx502.ccr.corp.intel.com>
	<20111223030103.GA7218@andromeda.dapyr.net>
In-Reply-To: <20111223030103.GA7218@andromeda.dapyr.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: "jeremy@goop.org" <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"mike.mcclurg@citrix.com" <mike.mcclurg@citrix.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"stefan.bader@canonical.com" <stefan.bader@canonical.com>,
	"rjw@sisk.pl" <rjw@sisk.pl>,
	"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
	"liang.tang@oracle.com" <liang.tang@oracle.com>, "Yu,
	Ke" <ke.yu@intel.com>, "konrad@kernel.org" <konrad@kernel.org>,
	"lenb@kernel.org" <lenb@kernel.org>
Subject: Re: [Xen-devel] [PATCH 3/8] ACPI: processor: add
 __acpi_processor_[un]register_driver helpers.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> From: Konrad Rzeszutek Wilk [mailto:konrad@darnok.org]
> Sent: Friday, December 23, 2011 11:01 AM
> 
> > > OK. Lets put the # VCPU != PCPU aside. Say dom0 will boot with all
> > > CPUs and then later on the admin starts unplugging them.
> >
> > This should be communicated to major Xen based distributions, so that it's
> > an agreed approach since in majority case dom0 is configured as UP or
> > a few VCPUs.
> 
> I am not saying that is it the agreed approach. There has to be
> flexibility in supporting both. But what I want to understand whether
> the requirement for VCPU != PCPU can be put aside and put in the drivers
> later on.

sure. VCPU!=PCPU requirement is orthogonal to the basic part for gearing
ACPI information to Xen.

> 
> So that the first approach is not changing the generic drivers (much).
> The reason I am asking about this is two-fold:
>  1). For new distros (Ubuntu, Fedora), the default is all VCPUs.

good to know that.

>      Enterprising users might use dom0_max_vcpus to limit the VCPU count,
>      but most won't.
>      Which mean we can concentrate on bringing the _Pxx/_Cxx parsing
>      up to the hypervisor. Which is really neccessary on any chipset
>      which has the notion of TurboBoost (otherwise the Xen scheduler
>      won't pick this up and won't engage this mode in certain
>      workloads).
>  2). The ACPI maintainers are busy with ACPI 5.0. I don't know how
>      much work this is, but it probably means tons of stuff with
>      embedded platforms and tons of regression testing. So if there
>      is a patch that does not impact the generic code much (or any)
>      it will make their life easier. Which also means we can built
>      on top that for the VCPU != PCPU case.
> 
> That is what I am trying to understand.

no problem. this incremental approach should work.

Thanks
Kevin

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 26 05:17:12 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 26 Dec 2011 05:17:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rf2v2-0000A8-Ab; Mon, 26 Dec 2011 05:16:16 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Rf2v1-0000A0-55
	for xen-devel@lists.xensource.com; Mon, 26 Dec 2011 05:16:15 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1324876568!8658673!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODQ5OA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10437 invoked from network); 26 Dec 2011 05:16:08 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Dec 2011 05:16:08 -0000
X-IronPort-AV: E=Sophos;i="4.71,410,1320624000"; 
   d="scan'208";a="9681583"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Dec 2011 05:16:07 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 26 Dec 2011 05:16:07 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1Rf2ut-0006P2-2x;
	Mon, 26 Dec 2011 05:16:07 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Rf2us-0003uJ-Qz;
	Mon, 26 Dec 2011 05:16:06 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10609-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 26 Dec 2011 05:16:06 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10609: tolerable FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10609 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10609/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 14 guest-localmigrate/x10       fail   like 10607
 test-amd64-amd64-xl          16 guest-start.2                fail   like 10607
 test-amd64-amd64-xl-sedf     14 guest-localmigrate/x10       fail   like 10607

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass

version targeted for testing:
 xen                  2863b2f43a3b
baseline version:
 xen                  2863b2f43a3b

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 26 05:17:12 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 26 Dec 2011 05:17:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rf2v2-0000A8-Ab; Mon, 26 Dec 2011 05:16:16 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Rf2v1-0000A0-55
	for xen-devel@lists.xensource.com; Mon, 26 Dec 2011 05:16:15 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1324876568!8658673!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODQ5OA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10437 invoked from network); 26 Dec 2011 05:16:08 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Dec 2011 05:16:08 -0000
X-IronPort-AV: E=Sophos;i="4.71,410,1320624000"; 
   d="scan'208";a="9681583"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Dec 2011 05:16:07 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 26 Dec 2011 05:16:07 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1Rf2ut-0006P2-2x;
	Mon, 26 Dec 2011 05:16:07 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Rf2us-0003uJ-Qz;
	Mon, 26 Dec 2011 05:16:06 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10609-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 26 Dec 2011 05:16:06 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10609: tolerable FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10609 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10609/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 14 guest-localmigrate/x10       fail   like 10607
 test-amd64-amd64-xl          16 guest-start.2                fail   like 10607
 test-amd64-amd64-xl-sedf     14 guest-localmigrate/x10       fail   like 10607

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass

version targeted for testing:
 xen                  2863b2f43a3b
baseline version:
 xen                  2863b2f43a3b

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 26 06:03:22 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 26 Dec 2011 06:03:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rf3dt-0000T5-1i; Mon, 26 Dec 2011 06:02:37 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mail.kai.huang@gmail.com>) id 1Rf3dr-0000T0-EB
	for Xen-devel@lists.xensource.com; Mon, 26 Dec 2011 06:02:35 +0000
X-Env-Sender: mail.kai.huang@gmail.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1324879329!53517345!1
X-Originating-IP: [209.85.212.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20658 invoked from network); 26 Dec 2011 06:02:09 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Dec 2011 06:02:09 -0000
Received: by wico1 with SMTP id o1so11034257wic.30
	for <Xen-devel@lists.xensource.com>;
	Sun, 25 Dec 2011 22:02:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=NXTmPwkdfgMw7dFYtnMEXDlrn2BkwOdHHnfqQQs8huc=;
	b=BXNyJZu5AvhnwJZzqPESGavNnl5qZR2VC+jP7iI9ab7wgE+E+cts+m0LXd3KfE+y1o
	ILDPW2aOb8J8RB4NwWE218D6FQoNw45i5Zhmc0oMYYRn3BbZMID150I8Oshk18If8ycA
	nUoFD5JJ7AFrNiVpTaTLGUdo4QunhxPgilpxo=
MIME-Version: 1.0
Received: by 10.216.136.234 with SMTP id w84mr18411582wei.9.1324879354200;
	Sun, 25 Dec 2011 22:02:34 -0800 (PST)
Received: by 10.227.173.77 with HTTP; Sun, 25 Dec 2011 22:02:34 -0800 (PST)
Date: Mon, 26 Dec 2011 14:02:34 +0800
Message-ID: <CANqQZNGrywjCoHO-h46J3zdPk+B4hw4HVe7dDdfcJjnsQLyzhA@mail.gmail.com>
From: Kai Huang <mail.kai.huang@gmail.com>
To: Xen-devel@lists.xensource.com
Subject: [Xen-devel] How does domU access PCI configure space?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi,

In my understanding, domU's PCI configure space access (ncluding
virtual device's and direct io's) is always trapped and emulated by
xen hypervisor. How did xen do it? Through exposing PCI configure
space area to domU as non-accessible memory? Where's the code to deal
of this? Thanks!

-cody

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 26 06:03:22 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 26 Dec 2011 06:03:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rf3dt-0000T5-1i; Mon, 26 Dec 2011 06:02:37 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mail.kai.huang@gmail.com>) id 1Rf3dr-0000T0-EB
	for Xen-devel@lists.xensource.com; Mon, 26 Dec 2011 06:02:35 +0000
X-Env-Sender: mail.kai.huang@gmail.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1324879329!53517345!1
X-Originating-IP: [209.85.212.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20658 invoked from network); 26 Dec 2011 06:02:09 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Dec 2011 06:02:09 -0000
Received: by wico1 with SMTP id o1so11034257wic.30
	for <Xen-devel@lists.xensource.com>;
	Sun, 25 Dec 2011 22:02:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=NXTmPwkdfgMw7dFYtnMEXDlrn2BkwOdHHnfqQQs8huc=;
	b=BXNyJZu5AvhnwJZzqPESGavNnl5qZR2VC+jP7iI9ab7wgE+E+cts+m0LXd3KfE+y1o
	ILDPW2aOb8J8RB4NwWE218D6FQoNw45i5Zhmc0oMYYRn3BbZMID150I8Oshk18If8ycA
	nUoFD5JJ7AFrNiVpTaTLGUdo4QunhxPgilpxo=
MIME-Version: 1.0
Received: by 10.216.136.234 with SMTP id w84mr18411582wei.9.1324879354200;
	Sun, 25 Dec 2011 22:02:34 -0800 (PST)
Received: by 10.227.173.77 with HTTP; Sun, 25 Dec 2011 22:02:34 -0800 (PST)
Date: Mon, 26 Dec 2011 14:02:34 +0800
Message-ID: <CANqQZNGrywjCoHO-h46J3zdPk+B4hw4HVe7dDdfcJjnsQLyzhA@mail.gmail.com>
From: Kai Huang <mail.kai.huang@gmail.com>
To: Xen-devel@lists.xensource.com
Subject: [Xen-devel] How does domU access PCI configure space?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi,

In my understanding, domU's PCI configure space access (ncluding
virtual device's and direct io's) is always trapped and emulated by
xen hypervisor. How did xen do it? Through exposing PCI configure
space area to domU as non-accessible memory? Where's the code to deal
of this? Thanks!

-cody

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 26 08:23:44 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 26 Dec 2011 08:23:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rf5pf-0001U5-Vz; Mon, 26 Dec 2011 08:22:55 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jean.guyader@gmail.com>) id 1Rf5pe-0001U0-Em
	for Xen-devel@lists.xensource.com; Mon, 26 Dec 2011 08:22:54 +0000
X-Env-Sender: jean.guyader@gmail.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1324887767!9196720!1
X-Originating-IP: [209.85.212.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4177 invoked from network); 26 Dec 2011 08:22:48 -0000
Received: from mail-vw0-f43.google.com (HELO mail-vw0-f43.google.com)
	(209.85.212.43)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Dec 2011 08:22:48 -0000
Received: by vbbfq11 with SMTP id fq11so34265242vbb.30
	for <Xen-devel@lists.xensource.com>;
	Mon, 26 Dec 2011 00:22:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type;
	bh=4gNvraSQjTCPAqktkotrQ3xtsaP/shNsxF+an7136S4=;
	b=w/Bs37TmHsmGyTC34fQrW88W/BHIqtvdkEcBxxf1f+ff8L1g5SdngoMp/nWPas0oN1
	xG1ijlnStD91KSog/opdoKnHF5/SdtWfLw7Ql0DKxDeiNYCJzHJTsMw1R6tsM2kKPdRU
	P4FyyKtg3Fj3XAIkgiDB+jGzteNrtkOJOjBSc=
Received: by 10.52.174.46 with SMTP id bp14mr12607091vdc.107.1324887767058;
	Mon, 26 Dec 2011 00:22:47 -0800 (PST)
MIME-Version: 1.0
Received: by 10.220.156.138 with HTTP; Mon, 26 Dec 2011 00:22:26 -0800 (PST)
In-Reply-To: <CANqQZNGrywjCoHO-h46J3zdPk+B4hw4HVe7dDdfcJjnsQLyzhA@mail.gmail.com>
References: <CANqQZNGrywjCoHO-h46J3zdPk+B4hw4HVe7dDdfcJjnsQLyzhA@mail.gmail.com>
From: Jean Guyader <jean.guyader@gmail.com>
Date: Mon, 26 Dec 2011 09:22:26 +0100
Message-ID: <CAEBdQ90Cmgv0RtqbrR=6R+9ecvVQbBdMP=WbMTOs5WKDZDyhbQ@mail.gmail.com>
To: Kai Huang <mail.kai.huang@gmail.com>
Cc: Xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] How does domU access PCI configure space?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 26 December 2011 07:02, Kai Huang <mail.kai.huang@gmail.com> wrote:
> Hi,
>
> In my understanding, domU's PCI configure space access (ncluding
> virtual device's and direct io's) is always trapped and emulated by
> xen hypervisor. How did xen do it? Through exposing PCI configure
> space area to domU as non-accessible memory? Where's the code to deal
> of this? Thanks!
>

Config space access happen through the IO port cf8 and cfc.
When a guest write to an io port that will cause a VMEXIT then xen will
forward the io port request to qemu. cf8 and cfc are owned by the PCI
BUS device model in qemu then this code will interpret the config
space request and send it to the right pci device model (code
qemu/i386-dm/helper2.c qemu/hw/pci.c)

Jean

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 26 08:23:44 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 26 Dec 2011 08:23:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rf5pf-0001U5-Vz; Mon, 26 Dec 2011 08:22:55 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jean.guyader@gmail.com>) id 1Rf5pe-0001U0-Em
	for Xen-devel@lists.xensource.com; Mon, 26 Dec 2011 08:22:54 +0000
X-Env-Sender: jean.guyader@gmail.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1324887767!9196720!1
X-Originating-IP: [209.85.212.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4177 invoked from network); 26 Dec 2011 08:22:48 -0000
Received: from mail-vw0-f43.google.com (HELO mail-vw0-f43.google.com)
	(209.85.212.43)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Dec 2011 08:22:48 -0000
Received: by vbbfq11 with SMTP id fq11so34265242vbb.30
	for <Xen-devel@lists.xensource.com>;
	Mon, 26 Dec 2011 00:22:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type;
	bh=4gNvraSQjTCPAqktkotrQ3xtsaP/shNsxF+an7136S4=;
	b=w/Bs37TmHsmGyTC34fQrW88W/BHIqtvdkEcBxxf1f+ff8L1g5SdngoMp/nWPas0oN1
	xG1ijlnStD91KSog/opdoKnHF5/SdtWfLw7Ql0DKxDeiNYCJzHJTsMw1R6tsM2kKPdRU
	P4FyyKtg3Fj3XAIkgiDB+jGzteNrtkOJOjBSc=
Received: by 10.52.174.46 with SMTP id bp14mr12607091vdc.107.1324887767058;
	Mon, 26 Dec 2011 00:22:47 -0800 (PST)
MIME-Version: 1.0
Received: by 10.220.156.138 with HTTP; Mon, 26 Dec 2011 00:22:26 -0800 (PST)
In-Reply-To: <CANqQZNGrywjCoHO-h46J3zdPk+B4hw4HVe7dDdfcJjnsQLyzhA@mail.gmail.com>
References: <CANqQZNGrywjCoHO-h46J3zdPk+B4hw4HVe7dDdfcJjnsQLyzhA@mail.gmail.com>
From: Jean Guyader <jean.guyader@gmail.com>
Date: Mon, 26 Dec 2011 09:22:26 +0100
Message-ID: <CAEBdQ90Cmgv0RtqbrR=6R+9ecvVQbBdMP=WbMTOs5WKDZDyhbQ@mail.gmail.com>
To: Kai Huang <mail.kai.huang@gmail.com>
Cc: Xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] How does domU access PCI configure space?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 26 December 2011 07:02, Kai Huang <mail.kai.huang@gmail.com> wrote:
> Hi,
>
> In my understanding, domU's PCI configure space access (ncluding
> virtual device's and direct io's) is always trapped and emulated by
> xen hypervisor. How did xen do it? Through exposing PCI configure
> space area to domU as non-accessible memory? Where's the code to deal
> of this? Thanks!
>

Config space access happen through the IO port cf8 and cfc.
When a guest write to an io port that will cause a VMEXIT then xen will
forward the io port request to qemu. cf8 and cfc are owned by the PCI
BUS device model in qemu then this code will interpret the config
space request and send it to the right pci device model (code
qemu/i386-dm/helper2.c qemu/hw/pci.c)

Jean

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 26 08:51:06 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 26 Dec 2011 08:51:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rf6GH-0001gd-As; Mon, 26 Dec 2011 08:50:25 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mail.kai.huang@gmail.com>) id 1Rf6GF-0001gY-IZ
	for Xen-devel@lists.xensource.com; Mon, 26 Dec 2011 08:50:24 +0000
X-Env-Sender: mail.kai.huang@gmail.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1324889416!8752605!1
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14705 invoked from network); 26 Dec 2011 08:50:17 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Dec 2011 08:50:17 -0000
Received: by wgbds11 with SMTP id ds11so16914107wgb.24
	for <Xen-devel@lists.xensource.com>;
	Mon, 26 Dec 2011 00:50:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=gzTRYI0J49gkU2erq6xeQbmot3HjeEj2/lINNE3Nw+I=;
	b=Cg9ocM/n6XAkF/u7DOO0ZfLnqZqnDFNYpIVrmoFSPPq3qCXx4tU+OhoqmsKaZ2pI5+
	afQlbcBx9gc5TNaJyM7BOz5F8X3mRLxqeE4CJkmhH+51YsMvvvIJQQM5XrB1iy25PKKO
	+AvtWX5MoNAVoeN2PWveayEblqEmvBxWp+akE=
MIME-Version: 1.0
Received: by 10.227.206.76 with SMTP id ft12mr23248429wbb.1.1324889416697;
	Mon, 26 Dec 2011 00:50:16 -0800 (PST)
Received: by 10.227.173.77 with HTTP; Mon, 26 Dec 2011 00:50:16 -0800 (PST)
In-Reply-To: <CAEBdQ90Cmgv0RtqbrR=6R+9ecvVQbBdMP=WbMTOs5WKDZDyhbQ@mail.gmail.com>
References: <CANqQZNGrywjCoHO-h46J3zdPk+B4hw4HVe7dDdfcJjnsQLyzhA@mail.gmail.com>
	<CAEBdQ90Cmgv0RtqbrR=6R+9ecvVQbBdMP=WbMTOs5WKDZDyhbQ@mail.gmail.com>
Date: Mon, 26 Dec 2011 16:50:16 +0800
Message-ID: <CANqQZNGnoHOH=SmNr48wW3P+QYyLzV-yZ0-1WXSJT3RyZFVMHw@mail.gmail.com>
From: Kai Huang <mail.kai.huang@gmail.com>
To: Jean Guyader <jean.guyader@gmail.com>
Cc: Xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] How does domU access PCI configure space?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Dec 26, 2011 at 4:22 PM, Jean Guyader <jean.guyader@gmail.com> wrote:
> On 26 December 2011 07:02, Kai Huang <mail.kai.huang@gmail.com> wrote:
>> Hi,
>>
>> In my understanding, domU's PCI configure space access (ncluding
>> virtual device's and direct io's) is always trapped and emulated by
>> xen hypervisor. How did xen do it? Through exposing PCI configure
>> space area to domU as non-accessible memory? Where's the code to deal
>> of this? Thanks!
>>
>
> Config space access happen through the IO port cf8 and cfc.
> When a guest write to an io port that will cause a VMEXIT then xen will
> forward the io port request to qemu. cf8 and cfc are owned by the PCI
> BUS device model in qemu then this code will interpret the config
> space request and send it to the right pci device model (code
> qemu/i386-dm/helper2.c qemu/hw/pci.c)
>
> Jean

IO port only works for PCI device, and in real system should only be
used during early boot phase. All PCIE devices must use MMIO mechanism
to access configure space.

Are you saying currently xen/qemu only exports PIO mechanism to domU,
and does not support PCIE devices emulation/passthrough?

Thanks.

-cody

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 26 08:51:06 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 26 Dec 2011 08:51:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rf6GH-0001gd-As; Mon, 26 Dec 2011 08:50:25 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mail.kai.huang@gmail.com>) id 1Rf6GF-0001gY-IZ
	for Xen-devel@lists.xensource.com; Mon, 26 Dec 2011 08:50:24 +0000
X-Env-Sender: mail.kai.huang@gmail.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1324889416!8752605!1
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14705 invoked from network); 26 Dec 2011 08:50:17 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Dec 2011 08:50:17 -0000
Received: by wgbds11 with SMTP id ds11so16914107wgb.24
	for <Xen-devel@lists.xensource.com>;
	Mon, 26 Dec 2011 00:50:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=gzTRYI0J49gkU2erq6xeQbmot3HjeEj2/lINNE3Nw+I=;
	b=Cg9ocM/n6XAkF/u7DOO0ZfLnqZqnDFNYpIVrmoFSPPq3qCXx4tU+OhoqmsKaZ2pI5+
	afQlbcBx9gc5TNaJyM7BOz5F8X3mRLxqeE4CJkmhH+51YsMvvvIJQQM5XrB1iy25PKKO
	+AvtWX5MoNAVoeN2PWveayEblqEmvBxWp+akE=
MIME-Version: 1.0
Received: by 10.227.206.76 with SMTP id ft12mr23248429wbb.1.1324889416697;
	Mon, 26 Dec 2011 00:50:16 -0800 (PST)
Received: by 10.227.173.77 with HTTP; Mon, 26 Dec 2011 00:50:16 -0800 (PST)
In-Reply-To: <CAEBdQ90Cmgv0RtqbrR=6R+9ecvVQbBdMP=WbMTOs5WKDZDyhbQ@mail.gmail.com>
References: <CANqQZNGrywjCoHO-h46J3zdPk+B4hw4HVe7dDdfcJjnsQLyzhA@mail.gmail.com>
	<CAEBdQ90Cmgv0RtqbrR=6R+9ecvVQbBdMP=WbMTOs5WKDZDyhbQ@mail.gmail.com>
Date: Mon, 26 Dec 2011 16:50:16 +0800
Message-ID: <CANqQZNGnoHOH=SmNr48wW3P+QYyLzV-yZ0-1WXSJT3RyZFVMHw@mail.gmail.com>
From: Kai Huang <mail.kai.huang@gmail.com>
To: Jean Guyader <jean.guyader@gmail.com>
Cc: Xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] How does domU access PCI configure space?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Dec 26, 2011 at 4:22 PM, Jean Guyader <jean.guyader@gmail.com> wrote:
> On 26 December 2011 07:02, Kai Huang <mail.kai.huang@gmail.com> wrote:
>> Hi,
>>
>> In my understanding, domU's PCI configure space access (ncluding
>> virtual device's and direct io's) is always trapped and emulated by
>> xen hypervisor. How did xen do it? Through exposing PCI configure
>> space area to domU as non-accessible memory? Where's the code to deal
>> of this? Thanks!
>>
>
> Config space access happen through the IO port cf8 and cfc.
> When a guest write to an io port that will cause a VMEXIT then xen will
> forward the io port request to qemu. cf8 and cfc are owned by the PCI
> BUS device model in qemu then this code will interpret the config
> space request and send it to the right pci device model (code
> qemu/i386-dm/helper2.c qemu/hw/pci.c)
>
> Jean

IO port only works for PCI device, and in real system should only be
used during early boot phase. All PCIE devices must use MMIO mechanism
to access configure space.

Are you saying currently xen/qemu only exports PIO mechanism to domU,
and does not support PCIE devices emulation/passthrough?

Thanks.

-cody

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 26 08:56:03 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 26 Dec 2011 08: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.xensource.com>)
	id 1Rf6KT-0001nl-11; Mon, 26 Dec 2011 08:54:45 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jean.guyader@gmail.com>) id 1Rf6KR-0001nV-L7
	for Xen-devel@lists.xensource.com; Mon, 26 Dec 2011 08:54:43 +0000
X-Env-Sender: jean.guyader@gmail.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1324889675!6849361!1
X-Originating-IP: [209.85.220.171]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14486 invoked from network); 26 Dec 2011 08:54:36 -0000
Received: from mail-vx0-f171.google.com (HELO mail-vx0-f171.google.com)
	(209.85.220.171)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Dec 2011 08:54:36 -0000
Received: by vcbfl11 with SMTP id fl11so30136311vcb.30
	for <Xen-devel@lists.xensource.com>;
	Mon, 26 Dec 2011 00:54:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type;
	bh=vm9gEyra2NGZ/qNlxcsNinv2kWE0xiKqesEqHnWxAxs=;
	b=uwoydTr4agz0f37K3ViLM0XG23vJhyWkwLSxT/KrdZgQfFnLQ6Cb5nvLeBaOzNS8cE
	UZwCo3TdRSRJD2NxtY/bZOQuAdDLEypP7waAI+f4rT+26RXThhKa2rHH9z0N9kaZUaOF
	yfy0H7EvxTc9CqDQIjP9hdBdU4gVJQl0FmcD0=
Received: by 10.220.149.10 with SMTP id r10mr13964299vcv.38.1324889675081;
	Mon, 26 Dec 2011 00:54:35 -0800 (PST)
MIME-Version: 1.0
Received: by 10.220.156.138 with HTTP; Mon, 26 Dec 2011 00:54:14 -0800 (PST)
In-Reply-To: <CANqQZNGnoHOH=SmNr48wW3P+QYyLzV-yZ0-1WXSJT3RyZFVMHw@mail.gmail.com>
References: <CANqQZNGrywjCoHO-h46J3zdPk+B4hw4HVe7dDdfcJjnsQLyzhA@mail.gmail.com>
	<CAEBdQ90Cmgv0RtqbrR=6R+9ecvVQbBdMP=WbMTOs5WKDZDyhbQ@mail.gmail.com>
	<CANqQZNGnoHOH=SmNr48wW3P+QYyLzV-yZ0-1WXSJT3RyZFVMHw@mail.gmail.com>
From: Jean Guyader <jean.guyader@gmail.com>
Date: Mon, 26 Dec 2011 09:54:14 +0100
Message-ID: <CAEBdQ93owbZL=wKs1s=obGKYPAKFhc2bB_XteTqX7JCxPPrNVg@mail.gmail.com>
To: Kai Huang <mail.kai.huang@gmail.com>
Cc: Xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] How does domU access PCI configure space?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 26 December 2011 09:50, Kai Huang <mail.kai.huang@gmail.com> wrote:
> On Mon, Dec 26, 2011 at 4:22 PM, Jean Guyader <jean.guyader@gmail.com> wrote:
>> On 26 December 2011 07:02, Kai Huang <mail.kai.huang@gmail.com> wrote:
>>> Hi,
>>>
>>> In my understanding, domU's PCI configure space access (ncluding
>>> virtual device's and direct io's) is always trapped and emulated by
>>> xen hypervisor. How did xen do it? Through exposing PCI configure
>>> space area to domU as non-accessible memory? Where's the code to deal
>>> of this? Thanks!
>>>
>>
>> Config space access happen through the IO port cf8 and cfc.
>> When a guest write to an io port that will cause a VMEXIT then xen will
>> forward the io port request to qemu. cf8 and cfc are owned by the PCI
>> BUS device model in qemu then this code will interpret the config
>> space request and send it to the right pci device model (code
>> qemu/i386-dm/helper2.c qemu/hw/pci.c)
>>
>> Jean
>
> IO port only works for PCI device, and in real system should only be
> used during early boot phase. All PCIE devices must use MMIO mechanism
> to access configure space.
>
> Are you saying currently xen/qemu only exports PIO mechanism to domU,
> and does not support PCIE devices emulation/passthrough?
>

xen/qemu doesn't emulate a PCIE bus, it only has PCI support.

Jean

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 26 08:56:03 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 26 Dec 2011 08: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.xensource.com>)
	id 1Rf6KT-0001nl-11; Mon, 26 Dec 2011 08:54:45 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jean.guyader@gmail.com>) id 1Rf6KR-0001nV-L7
	for Xen-devel@lists.xensource.com; Mon, 26 Dec 2011 08:54:43 +0000
X-Env-Sender: jean.guyader@gmail.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1324889675!6849361!1
X-Originating-IP: [209.85.220.171]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14486 invoked from network); 26 Dec 2011 08:54:36 -0000
Received: from mail-vx0-f171.google.com (HELO mail-vx0-f171.google.com)
	(209.85.220.171)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Dec 2011 08:54:36 -0000
Received: by vcbfl11 with SMTP id fl11so30136311vcb.30
	for <Xen-devel@lists.xensource.com>;
	Mon, 26 Dec 2011 00:54:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type;
	bh=vm9gEyra2NGZ/qNlxcsNinv2kWE0xiKqesEqHnWxAxs=;
	b=uwoydTr4agz0f37K3ViLM0XG23vJhyWkwLSxT/KrdZgQfFnLQ6Cb5nvLeBaOzNS8cE
	UZwCo3TdRSRJD2NxtY/bZOQuAdDLEypP7waAI+f4rT+26RXThhKa2rHH9z0N9kaZUaOF
	yfy0H7EvxTc9CqDQIjP9hdBdU4gVJQl0FmcD0=
Received: by 10.220.149.10 with SMTP id r10mr13964299vcv.38.1324889675081;
	Mon, 26 Dec 2011 00:54:35 -0800 (PST)
MIME-Version: 1.0
Received: by 10.220.156.138 with HTTP; Mon, 26 Dec 2011 00:54:14 -0800 (PST)
In-Reply-To: <CANqQZNGnoHOH=SmNr48wW3P+QYyLzV-yZ0-1WXSJT3RyZFVMHw@mail.gmail.com>
References: <CANqQZNGrywjCoHO-h46J3zdPk+B4hw4HVe7dDdfcJjnsQLyzhA@mail.gmail.com>
	<CAEBdQ90Cmgv0RtqbrR=6R+9ecvVQbBdMP=WbMTOs5WKDZDyhbQ@mail.gmail.com>
	<CANqQZNGnoHOH=SmNr48wW3P+QYyLzV-yZ0-1WXSJT3RyZFVMHw@mail.gmail.com>
From: Jean Guyader <jean.guyader@gmail.com>
Date: Mon, 26 Dec 2011 09:54:14 +0100
Message-ID: <CAEBdQ93owbZL=wKs1s=obGKYPAKFhc2bB_XteTqX7JCxPPrNVg@mail.gmail.com>
To: Kai Huang <mail.kai.huang@gmail.com>
Cc: Xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] How does domU access PCI configure space?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 26 December 2011 09:50, Kai Huang <mail.kai.huang@gmail.com> wrote:
> On Mon, Dec 26, 2011 at 4:22 PM, Jean Guyader <jean.guyader@gmail.com> wrote:
>> On 26 December 2011 07:02, Kai Huang <mail.kai.huang@gmail.com> wrote:
>>> Hi,
>>>
>>> In my understanding, domU's PCI configure space access (ncluding
>>> virtual device's and direct io's) is always trapped and emulated by
>>> xen hypervisor. How did xen do it? Through exposing PCI configure
>>> space area to domU as non-accessible memory? Where's the code to deal
>>> of this? Thanks!
>>>
>>
>> Config space access happen through the IO port cf8 and cfc.
>> When a guest write to an io port that will cause a VMEXIT then xen will
>> forward the io port request to qemu. cf8 and cfc are owned by the PCI
>> BUS device model in qemu then this code will interpret the config
>> space request and send it to the right pci device model (code
>> qemu/i386-dm/helper2.c qemu/hw/pci.c)
>>
>> Jean
>
> IO port only works for PCI device, and in real system should only be
> used during early boot phase. All PCIE devices must use MMIO mechanism
> to access configure space.
>
> Are you saying currently xen/qemu only exports PIO mechanism to domU,
> and does not support PCIE devices emulation/passthrough?
>

xen/qemu doesn't emulate a PCIE bus, it only has PCI support.

Jean

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 26 09:08:19 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 26 Dec 2011 09:08:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rf6WO-00023s-JQ; Mon, 26 Dec 2011 09:07:04 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mail.kai.huang@gmail.com>) id 1Rf6WN-00023n-2m
	for Xen-devel@lists.xensource.com; Mon, 26 Dec 2011 09:07:03 +0000
X-Env-Sender: mail.kai.huang@gmail.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1324890416!8770048!1
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12811 invoked from network); 26 Dec 2011 09:06:57 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Dec 2011 09:06:57 -0000
Received: by werg1 with SMTP id g1so12991793wer.30
	for <Xen-devel@lists.xensource.com>;
	Mon, 26 Dec 2011 01:06:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=1h9cGq3Hmvji9c8J2SMQIGcjEo8qs/ieGDG9M5X4DGQ=;
	b=LaIIqEEGuZL10dap2j9eV27FQ0oUpe6qsyH8fB1+x2lVH2xqvraGcZeGp9vopFxOKw
	qzbo0u+oO8i9FYm7zDH8YPPcbYDT+PF7phDXy94bVM9Pkjmu2GiUVd6q98QH1X8EOuEl
	MLCLY8xO4fin9sIXtprOGZE9mq/PZzh1xXSf8=
MIME-Version: 1.0
Received: by 10.216.131.153 with SMTP id m25mr13189455wei.9.1324890416779;
	Mon, 26 Dec 2011 01:06:56 -0800 (PST)
Received: by 10.227.173.77 with HTTP; Mon, 26 Dec 2011 01:06:56 -0800 (PST)
In-Reply-To: <CAEBdQ93owbZL=wKs1s=obGKYPAKFhc2bB_XteTqX7JCxPPrNVg@mail.gmail.com>
References: <CANqQZNGrywjCoHO-h46J3zdPk+B4hw4HVe7dDdfcJjnsQLyzhA@mail.gmail.com>
	<CAEBdQ90Cmgv0RtqbrR=6R+9ecvVQbBdMP=WbMTOs5WKDZDyhbQ@mail.gmail.com>
	<CANqQZNGnoHOH=SmNr48wW3P+QYyLzV-yZ0-1WXSJT3RyZFVMHw@mail.gmail.com>
	<CAEBdQ93owbZL=wKs1s=obGKYPAKFhc2bB_XteTqX7JCxPPrNVg@mail.gmail.com>
Date: Mon, 26 Dec 2011 17:06:56 +0800
Message-ID: <CANqQZNGfmD1Eu9d4pZbgf_pFUaJ5KqMrjzyvY32xXVSnvz=h+Q@mail.gmail.com>
From: Kai Huang <mail.kai.huang@gmail.com>
To: Jean Guyader <jean.guyader@gmail.com>
Cc: Xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] How does domU access PCI configure space?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Dec 26, 2011 at 4:54 PM, Jean Guyader <jean.guyader@gmail.com> wrote:
> On 26 December 2011 09:50, Kai Huang <mail.kai.huang@gmail.com> wrote:
>> On Mon, Dec 26, 2011 at 4:22 PM, Jean Guyader <jean.guyader@gmail.com> wrote:
>>> On 26 December 2011 07:02, Kai Huang <mail.kai.huang@gmail.com> wrote:
>>>> Hi,
>>>>
>>>> In my understanding, domU's PCI configure space access (ncluding
>>>> virtual device's and direct io's) is always trapped and emulated by
>>>> xen hypervisor. How did xen do it? Through exposing PCI configure
>>>> space area to domU as non-accessible memory? Where's the code to deal
>>>> of this? Thanks!
>>>>
>>>
>>> Config space access happen through the IO port cf8 and cfc.
>>> When a guest write to an io port that will cause a VMEXIT then xen will
>>> forward the io port request to qemu. cf8 and cfc are owned by the PCI
>>> BUS device model in qemu then this code will interpret the config
>>> space request and send it to the right pci device model (code
>>> qemu/i386-dm/helper2.c qemu/hw/pci.c)
>>>
>>> Jean
>>
>> IO port only works for PCI device, and in real system should only be
>> used during early boot phase. All PCIE devices must use MMIO mechanism
>> to access configure space.
>>
>> Are you saying currently xen/qemu only exports PIO mechanism to domU,
>> and does not support PCIE devices emulation/passthrough?
>>
>
> xen/qemu doesn't emulate a PCIE bus, it only has PCI support.
>
> Jean

Oh. Is there any plan, or code branch we are working on to support
PCIE bus in xen/qemu now?

-cody

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 26 09:08:19 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 26 Dec 2011 09:08:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rf6WO-00023s-JQ; Mon, 26 Dec 2011 09:07:04 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mail.kai.huang@gmail.com>) id 1Rf6WN-00023n-2m
	for Xen-devel@lists.xensource.com; Mon, 26 Dec 2011 09:07:03 +0000
X-Env-Sender: mail.kai.huang@gmail.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1324890416!8770048!1
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12811 invoked from network); 26 Dec 2011 09:06:57 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Dec 2011 09:06:57 -0000
Received: by werg1 with SMTP id g1so12991793wer.30
	for <Xen-devel@lists.xensource.com>;
	Mon, 26 Dec 2011 01:06:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=1h9cGq3Hmvji9c8J2SMQIGcjEo8qs/ieGDG9M5X4DGQ=;
	b=LaIIqEEGuZL10dap2j9eV27FQ0oUpe6qsyH8fB1+x2lVH2xqvraGcZeGp9vopFxOKw
	qzbo0u+oO8i9FYm7zDH8YPPcbYDT+PF7phDXy94bVM9Pkjmu2GiUVd6q98QH1X8EOuEl
	MLCLY8xO4fin9sIXtprOGZE9mq/PZzh1xXSf8=
MIME-Version: 1.0
Received: by 10.216.131.153 with SMTP id m25mr13189455wei.9.1324890416779;
	Mon, 26 Dec 2011 01:06:56 -0800 (PST)
Received: by 10.227.173.77 with HTTP; Mon, 26 Dec 2011 01:06:56 -0800 (PST)
In-Reply-To: <CAEBdQ93owbZL=wKs1s=obGKYPAKFhc2bB_XteTqX7JCxPPrNVg@mail.gmail.com>
References: <CANqQZNGrywjCoHO-h46J3zdPk+B4hw4HVe7dDdfcJjnsQLyzhA@mail.gmail.com>
	<CAEBdQ90Cmgv0RtqbrR=6R+9ecvVQbBdMP=WbMTOs5WKDZDyhbQ@mail.gmail.com>
	<CANqQZNGnoHOH=SmNr48wW3P+QYyLzV-yZ0-1WXSJT3RyZFVMHw@mail.gmail.com>
	<CAEBdQ93owbZL=wKs1s=obGKYPAKFhc2bB_XteTqX7JCxPPrNVg@mail.gmail.com>
Date: Mon, 26 Dec 2011 17:06:56 +0800
Message-ID: <CANqQZNGfmD1Eu9d4pZbgf_pFUaJ5KqMrjzyvY32xXVSnvz=h+Q@mail.gmail.com>
From: Kai Huang <mail.kai.huang@gmail.com>
To: Jean Guyader <jean.guyader@gmail.com>
Cc: Xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] How does domU access PCI configure space?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Dec 26, 2011 at 4:54 PM, Jean Guyader <jean.guyader@gmail.com> wrote:
> On 26 December 2011 09:50, Kai Huang <mail.kai.huang@gmail.com> wrote:
>> On Mon, Dec 26, 2011 at 4:22 PM, Jean Guyader <jean.guyader@gmail.com> wrote:
>>> On 26 December 2011 07:02, Kai Huang <mail.kai.huang@gmail.com> wrote:
>>>> Hi,
>>>>
>>>> In my understanding, domU's PCI configure space access (ncluding
>>>> virtual device's and direct io's) is always trapped and emulated by
>>>> xen hypervisor. How did xen do it? Through exposing PCI configure
>>>> space area to domU as non-accessible memory? Where's the code to deal
>>>> of this? Thanks!
>>>>
>>>
>>> Config space access happen through the IO port cf8 and cfc.
>>> When a guest write to an io port that will cause a VMEXIT then xen will
>>> forward the io port request to qemu. cf8 and cfc are owned by the PCI
>>> BUS device model in qemu then this code will interpret the config
>>> space request and send it to the right pci device model (code
>>> qemu/i386-dm/helper2.c qemu/hw/pci.c)
>>>
>>> Jean
>>
>> IO port only works for PCI device, and in real system should only be
>> used during early boot phase. All PCIE devices must use MMIO mechanism
>> to access configure space.
>>
>> Are you saying currently xen/qemu only exports PIO mechanism to domU,
>> and does not support PCIE devices emulation/passthrough?
>>
>
> xen/qemu doesn't emulate a PCIE bus, it only has PCI support.
>
> Jean

Oh. Is there any plan, or code branch we are working on to support
PCIE bus in xen/qemu now?

-cody

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 26 09:13:36 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 26 Dec 2011 09:13:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rf6bm-0002EF-HB; Mon, 26 Dec 2011 09:12:38 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jean.guyader@gmail.com>) id 1Rf6bl-0002E6-JL
	for Xen-devel@lists.xensource.com; Mon, 26 Dec 2011 09:12:37 +0000
X-Env-Sender: jean.guyader@gmail.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1324890750!8803149!1
X-Originating-IP: [209.85.220.171]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21162 invoked from network); 26 Dec 2011 09:12:31 -0000
Received: from mail-vx0-f171.google.com (HELO mail-vx0-f171.google.com)
	(209.85.220.171)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Dec 2011 09:12:31 -0000
Received: by vcbfl11 with SMTP id fl11so30147866vcb.30
	for <Xen-devel@lists.xensource.com>;
	Mon, 26 Dec 2011 01:12:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type;
	bh=DMrscRR9zr/xZ4rprwU+6KQ6rahnxCrJ87eqKuHvIk8=;
	b=K+6wocllPVaEzQblcDCLMiEX2EC/Huq/c/5lUCcsyyk4zxjveA/EThapUKSXAgIiVg
	kx4tUaKTThB9SFiDPG/1CPzL6YiYATkP0FbtGmDunCGJEqyj+6jLdg/SAytjMLRYhwE1
	c8Gi0sKFcHEW5zxsJHvJ7CCQYeWV77XSN6TGU=
Received: by 10.52.90.145 with SMTP id bw17mr12769723vdb.73.1324890750127;
	Mon, 26 Dec 2011 01:12:30 -0800 (PST)
MIME-Version: 1.0
Received: by 10.220.156.138 with HTTP; Mon, 26 Dec 2011 01:12:09 -0800 (PST)
In-Reply-To: <CANqQZNGfmD1Eu9d4pZbgf_pFUaJ5KqMrjzyvY32xXVSnvz=h+Q@mail.gmail.com>
References: <CANqQZNGrywjCoHO-h46J3zdPk+B4hw4HVe7dDdfcJjnsQLyzhA@mail.gmail.com>
	<CAEBdQ90Cmgv0RtqbrR=6R+9ecvVQbBdMP=WbMTOs5WKDZDyhbQ@mail.gmail.com>
	<CANqQZNGnoHOH=SmNr48wW3P+QYyLzV-yZ0-1WXSJT3RyZFVMHw@mail.gmail.com>
	<CAEBdQ93owbZL=wKs1s=obGKYPAKFhc2bB_XteTqX7JCxPPrNVg@mail.gmail.com>
	<CANqQZNGfmD1Eu9d4pZbgf_pFUaJ5KqMrjzyvY32xXVSnvz=h+Q@mail.gmail.com>
From: Jean Guyader <jean.guyader@gmail.com>
Date: Mon, 26 Dec 2011 10:12:09 +0100
Message-ID: <CAEBdQ91J0jTb3LiDU3R-VEdypCDMGpBkc+X4UcsBUzeDn+qXdg@mail.gmail.com>
To: Kai Huang <mail.kai.huang@gmail.com>
Cc: Anthony Perard <anthony.perard@citrix.com>, Xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] How does domU access PCI configure space?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 26 December 2011 10:06, Kai Huang <mail.kai.huang@gmail.com> wrote:
> On Mon, Dec 26, 2011 at 4:54 PM, Jean Guyader <jean.guyader@gmail.com> wrote:
>> On 26 December 2011 09:50, Kai Huang <mail.kai.huang@gmail.com> wrote:
>>> On Mon, Dec 26, 2011 at 4:22 PM, Jean Guyader <jean.guyader@gmail.com> wrote:
>>>> On 26 December 2011 07:02, Kai Huang <mail.kai.huang@gmail.com> wrote:
>>>>> Hi,
>>>>>
>>>>> In my understanding, domU's PCI configure space access (ncluding
>>>>> virtual device's and direct io's) is always trapped and emulated by
>>>>> xen hypervisor. How did xen do it? Through exposing PCI configure
>>>>> space area to domU as non-accessible memory? Where's the code to deal
>>>>> of this? Thanks!
>>>>>
>>>>
>>>> Config space access happen through the IO port cf8 and cfc.
>>>> When a guest write to an io port that will cause a VMEXIT then xen will
>>>> forward the io port request to qemu. cf8 and cfc are owned by the PCI
>>>> BUS device model in qemu then this code will interpret the config
>>>> space request and send it to the right pci device model (code
>>>> qemu/i386-dm/helper2.c qemu/hw/pci.c)
>>>>
>>>> Jean
>>>
>>> IO port only works for PCI device, and in real system should only be
>>> used during early boot phase. All PCIE devices must use MMIO mechanism
>>> to access configure space.
>>>
>>> Are you saying currently xen/qemu only exports PIO mechanism to domU,
>>> and does not support PCIE devices emulation/passthrough?
>>>
>>
>> xen/qemu doesn't emulate a PCIE bus, it only has PCI support.
>>
>> Jean
>
> Oh. Is there any plan, or code branch we are working on to support
> PCIE bus in xen/qemu now?
>

Someone can correct me if I'm wrong but I don't think qemu upstream
has pcie support yet.
When qemu upstream will have pcie support we will get it for free.

Jean

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 26 09:13:36 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 26 Dec 2011 09:13:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rf6bm-0002EF-HB; Mon, 26 Dec 2011 09:12:38 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jean.guyader@gmail.com>) id 1Rf6bl-0002E6-JL
	for Xen-devel@lists.xensource.com; Mon, 26 Dec 2011 09:12:37 +0000
X-Env-Sender: jean.guyader@gmail.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1324890750!8803149!1
X-Originating-IP: [209.85.220.171]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21162 invoked from network); 26 Dec 2011 09:12:31 -0000
Received: from mail-vx0-f171.google.com (HELO mail-vx0-f171.google.com)
	(209.85.220.171)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Dec 2011 09:12:31 -0000
Received: by vcbfl11 with SMTP id fl11so30147866vcb.30
	for <Xen-devel@lists.xensource.com>;
	Mon, 26 Dec 2011 01:12:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type;
	bh=DMrscRR9zr/xZ4rprwU+6KQ6rahnxCrJ87eqKuHvIk8=;
	b=K+6wocllPVaEzQblcDCLMiEX2EC/Huq/c/5lUCcsyyk4zxjveA/EThapUKSXAgIiVg
	kx4tUaKTThB9SFiDPG/1CPzL6YiYATkP0FbtGmDunCGJEqyj+6jLdg/SAytjMLRYhwE1
	c8Gi0sKFcHEW5zxsJHvJ7CCQYeWV77XSN6TGU=
Received: by 10.52.90.145 with SMTP id bw17mr12769723vdb.73.1324890750127;
	Mon, 26 Dec 2011 01:12:30 -0800 (PST)
MIME-Version: 1.0
Received: by 10.220.156.138 with HTTP; Mon, 26 Dec 2011 01:12:09 -0800 (PST)
In-Reply-To: <CANqQZNGfmD1Eu9d4pZbgf_pFUaJ5KqMrjzyvY32xXVSnvz=h+Q@mail.gmail.com>
References: <CANqQZNGrywjCoHO-h46J3zdPk+B4hw4HVe7dDdfcJjnsQLyzhA@mail.gmail.com>
	<CAEBdQ90Cmgv0RtqbrR=6R+9ecvVQbBdMP=WbMTOs5WKDZDyhbQ@mail.gmail.com>
	<CANqQZNGnoHOH=SmNr48wW3P+QYyLzV-yZ0-1WXSJT3RyZFVMHw@mail.gmail.com>
	<CAEBdQ93owbZL=wKs1s=obGKYPAKFhc2bB_XteTqX7JCxPPrNVg@mail.gmail.com>
	<CANqQZNGfmD1Eu9d4pZbgf_pFUaJ5KqMrjzyvY32xXVSnvz=h+Q@mail.gmail.com>
From: Jean Guyader <jean.guyader@gmail.com>
Date: Mon, 26 Dec 2011 10:12:09 +0100
Message-ID: <CAEBdQ91J0jTb3LiDU3R-VEdypCDMGpBkc+X4UcsBUzeDn+qXdg@mail.gmail.com>
To: Kai Huang <mail.kai.huang@gmail.com>
Cc: Anthony Perard <anthony.perard@citrix.com>, Xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] How does domU access PCI configure space?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 26 December 2011 10:06, Kai Huang <mail.kai.huang@gmail.com> wrote:
> On Mon, Dec 26, 2011 at 4:54 PM, Jean Guyader <jean.guyader@gmail.com> wrote:
>> On 26 December 2011 09:50, Kai Huang <mail.kai.huang@gmail.com> wrote:
>>> On Mon, Dec 26, 2011 at 4:22 PM, Jean Guyader <jean.guyader@gmail.com> wrote:
>>>> On 26 December 2011 07:02, Kai Huang <mail.kai.huang@gmail.com> wrote:
>>>>> Hi,
>>>>>
>>>>> In my understanding, domU's PCI configure space access (ncluding
>>>>> virtual device's and direct io's) is always trapped and emulated by
>>>>> xen hypervisor. How did xen do it? Through exposing PCI configure
>>>>> space area to domU as non-accessible memory? Where's the code to deal
>>>>> of this? Thanks!
>>>>>
>>>>
>>>> Config space access happen through the IO port cf8 and cfc.
>>>> When a guest write to an io port that will cause a VMEXIT then xen will
>>>> forward the io port request to qemu. cf8 and cfc are owned by the PCI
>>>> BUS device model in qemu then this code will interpret the config
>>>> space request and send it to the right pci device model (code
>>>> qemu/i386-dm/helper2.c qemu/hw/pci.c)
>>>>
>>>> Jean
>>>
>>> IO port only works for PCI device, and in real system should only be
>>> used during early boot phase. All PCIE devices must use MMIO mechanism
>>> to access configure space.
>>>
>>> Are you saying currently xen/qemu only exports PIO mechanism to domU,
>>> and does not support PCIE devices emulation/passthrough?
>>>
>>
>> xen/qemu doesn't emulate a PCIE bus, it only has PCI support.
>>
>> Jean
>
> Oh. Is there any plan, or code branch we are working on to support
> PCIE bus in xen/qemu now?
>

Someone can correct me if I'm wrong but I don't think qemu upstream
has pcie support yet.
When qemu upstream will have pcie support we will get it for free.

Jean

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 26 09:32:01 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 26 Dec 2011 09:32:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rf6tX-0002R1-90; Mon, 26 Dec 2011 09:30:59 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <250716708@qq.com>) id 1Rf6tV-0002Qw-Ha
	for xen-devel@lists.xensource.com; Mon, 26 Dec 2011 09:30:58 +0000
X-Env-Sender: 250716708@qq.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1324891849!6907577!1
X-Originating-IP: [64.71.138.43]
X-SpamReason: No, hits=2.6 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA2NC43MS4xMzguNDMgPT4gMjkwNjIw\n,sa_preprocessor: 
	QmFkIElQOiA2NC43MS4xMzguNDMgPT4gMjkwNjIw\n,FROM_ALL_NUMS,
	FROM_STARTS_WITH_NUMS,HTML_40_50,HTML_MESSAGE,MIME_BASE64_TEXT,
	MIME_BOUND_NEXTPART,received_headers: No Received headers
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28446 invoked from network); 26 Dec 2011 09:30:51 -0000
Received: from smtpbg52.qq.com (HELO smtpbg52.qq.com) (64.71.138.43)
	by server-7.tower-174.messagelabs.com with SMTP;
	26 Dec 2011 09:30:51 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qq.com; s=s0907;
	t=1324891848; bh=bH9pquywJuyIw7yd3NhXPOLtyHZr2yLzWAxCPXYOOm0=;
	h=X-QQ-SSF:X-HAS-ATTACH:X-QQ-BUSINESS-ORIGIN:X-Originating-IP:
	X-QQ-STYLE:X-QQ-mid:From:To:Subject:Mime-Version:Content-Type:
	Content-Transfer-Encoding:Date:X-Priority:Message-ID:X-QQ-MIME:
	X-Mailer:X-QQ-Mailer;
	b=h6Isfn1dRYs5cYiQzqVk2S6KQhle+4ofFTFPyeyyMqz/PLJgkWsBlAX4C6Ht6sjYJ
	IHrqGdOJiL6+MHmxLGLbT2BdoE0sYPm+FZQ7zdz5otJ75Pqu7/8dIaKPMZ4Jcse
X-QQ-SSF: 00000000000000F0000000000000000
X-HAS-ATTACH: no
X-QQ-BUSINESS-ORIGIN: 2
X-Originating-IP: 118.192.67.234
X-QQ-STYLE: 
X-QQ-mid: webmail594t1324891846t2950910
From: "=?gbk?B?oei9S+y2YXdhcmU=?=" <250716708@qq.com>
To: "=?gbk?B?eGVuLWRldmVs?=" <xen-devel@lists.xensource.com>
Mime-Version: 1.0
Date: Mon, 26 Dec 2011 17:30:46 +0800
X-Priority: 3
Message-ID: <tencent_0C4DB37648BB9859176328CB@qq.com>
X-QQ-MIME: TCMime 1.0 by Tencent
X-Mailer: QQMail 2.x
X-QQ-Mailer: QQMail 2.x
Subject: [Xen-devel] [help] what's the relationship between vif*.* and
	tap*.* in vm?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3583732808631699111=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a multi-part message in MIME format.

--===============3583732808631699111==
Content-Type: multipart/alternative;
	boundary="----=_NextPart_4EF83EC6_08556188_4D0E85C3"
Content-Transfer-Encoding: 8Bit

This is a multi-part message in MIME format.

------=_NextPart_4EF83EC6_08556188_4D0E85C3
Content-Type: text/plain;
	charset="gbk"
Content-Transfer-Encoding: base64

SGkgZXZlcnlvbmUsDQogICAgIEEgcGFpciBvZiBuZXR3b3JrIGludGVyZmFjZSwgdmlmIGFu
ZCB0YXAsIHdpbGwgY29ubmVjdCB0aGUgYnJpZGdlIHdoZW4gYSB2bSBzdGFydHMuIFdoYXQn
cyB0aGVpciByZWxhdGlvbnNoaXA/DQogICAgIHRoYW5rcyBmb3IgcmVwbHl+DQogIA0KIGNo
ZWVycw0KIGJydWNl

------=_NextPart_4EF83EC6_08556188_4D0E85C3
Content-Type: text/html;
	charset="gbk"
Content-Transfer-Encoding: base64

PERJVj5IaSBldmVyeW9uZSw8L0RJVj4NCjxESVY+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
QSBwYWlyIG9mIG5ldHdvcmsgaW50ZXJmYWNlLCB2aWYgYW5kIHRhcCwgd2lsbCBjb25uZWN0
IHRoZSBicmlkZ2Ugd2hlbiBhIHZtIHN0YXJ0cy4gV2hhdCdzJm5ic3A7dGhlaXIgcmVsYXRp
b25zaGlwPzwvRElWPg0KPERJVj4mbmJzcDsmbmJzcDsmbmJzcDsgdGhhbmtzIGZvciByZXBs
eX48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPmNoZWVyczwvRElWPg0KPERJVj5i
cnVjZSZuYnNwOyZuYnNwOyZuYnNwOzwvRElWPg==

------=_NextPart_4EF83EC6_08556188_4D0E85C3--



--===============3583732808631699111==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============3583732808631699111==--



From xen-devel-bounces@lists.xensource.com Mon Dec 26 09:32:01 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 26 Dec 2011 09:32:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rf6tX-0002R1-90; Mon, 26 Dec 2011 09:30:59 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <250716708@qq.com>) id 1Rf6tV-0002Qw-Ha
	for xen-devel@lists.xensource.com; Mon, 26 Dec 2011 09:30:58 +0000
X-Env-Sender: 250716708@qq.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1324891849!6907577!1
X-Originating-IP: [64.71.138.43]
X-SpamReason: No, hits=2.6 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA2NC43MS4xMzguNDMgPT4gMjkwNjIw\n,sa_preprocessor: 
	QmFkIElQOiA2NC43MS4xMzguNDMgPT4gMjkwNjIw\n,FROM_ALL_NUMS,
	FROM_STARTS_WITH_NUMS,HTML_40_50,HTML_MESSAGE,MIME_BASE64_TEXT,
	MIME_BOUND_NEXTPART,received_headers: No Received headers
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28446 invoked from network); 26 Dec 2011 09:30:51 -0000
Received: from smtpbg52.qq.com (HELO smtpbg52.qq.com) (64.71.138.43)
	by server-7.tower-174.messagelabs.com with SMTP;
	26 Dec 2011 09:30:51 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qq.com; s=s0907;
	t=1324891848; bh=bH9pquywJuyIw7yd3NhXPOLtyHZr2yLzWAxCPXYOOm0=;
	h=X-QQ-SSF:X-HAS-ATTACH:X-QQ-BUSINESS-ORIGIN:X-Originating-IP:
	X-QQ-STYLE:X-QQ-mid:From:To:Subject:Mime-Version:Content-Type:
	Content-Transfer-Encoding:Date:X-Priority:Message-ID:X-QQ-MIME:
	X-Mailer:X-QQ-Mailer;
	b=h6Isfn1dRYs5cYiQzqVk2S6KQhle+4ofFTFPyeyyMqz/PLJgkWsBlAX4C6Ht6sjYJ
	IHrqGdOJiL6+MHmxLGLbT2BdoE0sYPm+FZQ7zdz5otJ75Pqu7/8dIaKPMZ4Jcse
X-QQ-SSF: 00000000000000F0000000000000000
X-HAS-ATTACH: no
X-QQ-BUSINESS-ORIGIN: 2
X-Originating-IP: 118.192.67.234
X-QQ-STYLE: 
X-QQ-mid: webmail594t1324891846t2950910
From: "=?gbk?B?oei9S+y2YXdhcmU=?=" <250716708@qq.com>
To: "=?gbk?B?eGVuLWRldmVs?=" <xen-devel@lists.xensource.com>
Mime-Version: 1.0
Date: Mon, 26 Dec 2011 17:30:46 +0800
X-Priority: 3
Message-ID: <tencent_0C4DB37648BB9859176328CB@qq.com>
X-QQ-MIME: TCMime 1.0 by Tencent
X-Mailer: QQMail 2.x
X-QQ-Mailer: QQMail 2.x
Subject: [Xen-devel] [help] what's the relationship between vif*.* and
	tap*.* in vm?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3583732808631699111=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a multi-part message in MIME format.

--===============3583732808631699111==
Content-Type: multipart/alternative;
	boundary="----=_NextPart_4EF83EC6_08556188_4D0E85C3"
Content-Transfer-Encoding: 8Bit

This is a multi-part message in MIME format.

------=_NextPart_4EF83EC6_08556188_4D0E85C3
Content-Type: text/plain;
	charset="gbk"
Content-Transfer-Encoding: base64

SGkgZXZlcnlvbmUsDQogICAgIEEgcGFpciBvZiBuZXR3b3JrIGludGVyZmFjZSwgdmlmIGFu
ZCB0YXAsIHdpbGwgY29ubmVjdCB0aGUgYnJpZGdlIHdoZW4gYSB2bSBzdGFydHMuIFdoYXQn
cyB0aGVpciByZWxhdGlvbnNoaXA/DQogICAgIHRoYW5rcyBmb3IgcmVwbHl+DQogIA0KIGNo
ZWVycw0KIGJydWNl

------=_NextPart_4EF83EC6_08556188_4D0E85C3
Content-Type: text/html;
	charset="gbk"
Content-Transfer-Encoding: base64

PERJVj5IaSBldmVyeW9uZSw8L0RJVj4NCjxESVY+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
QSBwYWlyIG9mIG5ldHdvcmsgaW50ZXJmYWNlLCB2aWYgYW5kIHRhcCwgd2lsbCBjb25uZWN0
IHRoZSBicmlkZ2Ugd2hlbiBhIHZtIHN0YXJ0cy4gV2hhdCdzJm5ic3A7dGhlaXIgcmVsYXRp
b25zaGlwPzwvRElWPg0KPERJVj4mbmJzcDsmbmJzcDsmbmJzcDsgdGhhbmtzIGZvciByZXBs
eX48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPmNoZWVyczwvRElWPg0KPERJVj5i
cnVjZSZuYnNwOyZuYnNwOyZuYnNwOzwvRElWPg==

------=_NextPart_4EF83EC6_08556188_4D0E85C3--



--===============3583732808631699111==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============3583732808631699111==--



From xen-devel-bounces@lists.xensource.com Mon Dec 26 10:44:58 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 26 Dec 2011 10: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.xensource.com>)
	id 1Rf822-0002qL-V1; Mon, 26 Dec 2011 10:43:50 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <james.harper@bendigoit.com.au>) id 1Rf821-0002qD-3T
	for xen-devel@lists.xensource.com; Mon, 26 Dec 2011 10:43:49 +0000
X-Env-Sender: james.harper@bendigoit.com.au
X-Msg-Ref: server-7.tower-21.messagelabs.com!1324896220!8821903!1
X-Originating-IP: [203.16.224.4]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18353 invoked from network); 26 Dec 2011 10:43:42 -0000
Received: from smtp1.bendigoit.com.au (HELO smtp1.bendigoit.com.au)
	(203.16.224.4)
	by server-7.tower-21.messagelabs.com with AES256-SHA encrypted SMTP;
	26 Dec 2011 10:43:42 -0000
Received: from mail.bendigoit.com.au ([203.16.207.99])
	by smtp1.bendigoit.com.au with esmtp (Exim 4.69)
	(envelope-from <james.harper@bendigoit.com.au>) id 1Rf81o-0000Hi-PI
	for xen-devel@lists.xensource.com; Mon, 26 Dec 2011 21:43:36 +1100
Received: from BITCOM1.int.sbss.com.au ([192.168.200.237]) by
	mail.bendigoit.com.au with Microsoft SMTPSVC(6.0.3790.4675); 
	Mon, 26 Dec 2011 21:43:36 +1100
Received: from BITCOM1.int.sbss.com.au ([fe80::a5ca:4fd3:14f:ad5d]) by
	BITCOM1.int.sbss.com.au ([fe80::a5ca:4fd3:14f:ad5d%12]) with mapi;
	Mon, 26 Dec 2011 21:43:36 +1100
From: James Harper <james.harper@bendigoit.com.au>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Thread-Topic: linux 3.1.0 - no network offload
Thread-Index: AczDuyJ2nb9FZZZWSKmRXFrDXRv17A==
Date: Mon, 26 Dec 2011 10:43:34 +0000
Message-ID: <6035A0D088A63A46850C3988ED045A4B051250@BITCOM1.int.sbss.com.au>
Accept-Language: en-AU, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
MIME-Version: 1.0
X-OriginalArrivalTime: 26 Dec 2011 10:43:36.0825 (UTC)
	FILETIME=[38ECDE90:01CCC3BB]
X-Really-From-Bendigo-IT: magichashvalue
Subject: [Xen-devel] linux 3.1.0 - no network offload
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

I've just noticed that all the offloads on my vif interfaces are disabled and I can't enable them. Has something changed in the later kernels?

Thanks

James

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 26 10:44:58 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 26 Dec 2011 10: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.xensource.com>)
	id 1Rf822-0002qL-V1; Mon, 26 Dec 2011 10:43:50 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <james.harper@bendigoit.com.au>) id 1Rf821-0002qD-3T
	for xen-devel@lists.xensource.com; Mon, 26 Dec 2011 10:43:49 +0000
X-Env-Sender: james.harper@bendigoit.com.au
X-Msg-Ref: server-7.tower-21.messagelabs.com!1324896220!8821903!1
X-Originating-IP: [203.16.224.4]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18353 invoked from network); 26 Dec 2011 10:43:42 -0000
Received: from smtp1.bendigoit.com.au (HELO smtp1.bendigoit.com.au)
	(203.16.224.4)
	by server-7.tower-21.messagelabs.com with AES256-SHA encrypted SMTP;
	26 Dec 2011 10:43:42 -0000
Received: from mail.bendigoit.com.au ([203.16.207.99])
	by smtp1.bendigoit.com.au with esmtp (Exim 4.69)
	(envelope-from <james.harper@bendigoit.com.au>) id 1Rf81o-0000Hi-PI
	for xen-devel@lists.xensource.com; Mon, 26 Dec 2011 21:43:36 +1100
Received: from BITCOM1.int.sbss.com.au ([192.168.200.237]) by
	mail.bendigoit.com.au with Microsoft SMTPSVC(6.0.3790.4675); 
	Mon, 26 Dec 2011 21:43:36 +1100
Received: from BITCOM1.int.sbss.com.au ([fe80::a5ca:4fd3:14f:ad5d]) by
	BITCOM1.int.sbss.com.au ([fe80::a5ca:4fd3:14f:ad5d%12]) with mapi;
	Mon, 26 Dec 2011 21:43:36 +1100
From: James Harper <james.harper@bendigoit.com.au>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Thread-Topic: linux 3.1.0 - no network offload
Thread-Index: AczDuyJ2nb9FZZZWSKmRXFrDXRv17A==
Date: Mon, 26 Dec 2011 10:43:34 +0000
Message-ID: <6035A0D088A63A46850C3988ED045A4B051250@BITCOM1.int.sbss.com.au>
Accept-Language: en-AU, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
MIME-Version: 1.0
X-OriginalArrivalTime: 26 Dec 2011 10:43:36.0825 (UTC)
	FILETIME=[38ECDE90:01CCC3BB]
X-Really-From-Bendigo-IT: magichashvalue
Subject: [Xen-devel] linux 3.1.0 - no network offload
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

I've just noticed that all the offloads on my vif interfaces are disabled and I can't enable them. Has something changed in the later kernels?

Thanks

James

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 26 15:45:03 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 26 Dec 2011 15:45:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RfCi4-0003xf-N7; Mon, 26 Dec 2011 15:43:32 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <hui.lv@intel.com>) id 1RfCi2-0003xa-DG
	for xen-devel@lists.xensource.com; Mon, 26 Dec 2011 15:43:30 +0000
X-Env-Sender: hui.lv@intel.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1324914202!8676921!1
X-Originating-IP: [143.182.124.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjE2MTE2\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6922 invoked from network); 26 Dec 2011 15:43:23 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-2.tower-182.messagelabs.com with SMTP;
	26 Dec 2011 15:43:23 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga101.ch.intel.com with ESMTP; 26 Dec 2011 07:43:21 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="89612038"
Received: from unknown (HELO [127.0.0.1]) ([10.239.44.119])
	by azsmga001.ch.intel.com with ESMTP; 26 Dec 2011 07:43:20 -0800
MIME-Version: 1.0
X-Mercurial-Node: 18f40e1d027491964a88b43a4e2cc617ef39238b
Message-Id: <18f40e1d027491964a88.1324889181@wsm-ep-n0>
User-Agent: Mercurial-patchbomb/1.4
Date: Mon, 26 Dec 2011 03:46:21 -0500
From: Hui Lv <hui.lv@intel.com>
To: xen-devel@lists.xensource.com, George.Dunlap@eu.citrix.com,
	raistlin@linux.it, JBeulich@suse.com, Ian.Campbell@citrix.com
Cc: hui.lv@intel.com
Subject: [Xen-devel] [PATCH] xen/sched_credit: Use delay to control
	scheduling frequency
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Some modifications for this patch.
1.Based on George's proposal, added a ratelimit_us element to csched_priv to constrain prv->ratelimit_us <= 1000* prv->tslice_ms in csched_init.
2.Move the definition of sched_ratelimit_us to xen/sched.h
3.Remove the redundant "else" structure

See if you have any comment for such changes.


This patch can improve Xen performance:
1. Basically, the "delay method" can achieve 11% overall performance boost for SPECvirt than original credit scheduler.
2. We have tried 1ms delay and 10ms delay, there is no big difference between these two configurations. (1ms is enough to achieve a good performance)
3. We have compared different load level response time/latency (low, high, peak), "delay method" didn't bring very much response time increase.
4. 1ms delay can reduce 30% context switch at peak performance, where produces the benefits. (int sched_ratelimit_us = 1000 is the recommended setting)

Signed-off-by: Hui Lv <hui.lv@intel.com>
Signed-off-by: George Dunlap <George.Dunlap@eu.citrix.com>

diff -r a4bff36780a3 -r 18f40e1d0274 xen/common/sched_credit.c
--- a/xen/common/sched_credit.c	Fri Dec 16 18:46:27 2011 +0000
+++ b/xen/common/sched_credit.c	Mon Dec 26 03:44:39 2011 -0500
@@ -172,6 +172,7 @@ struct csched_private {
     uint32_t credit;
     int credit_balance;
     uint32_t runq_sort;
+    unsigned ratelimit_us;
     /* Period of master and tick in milliseconds */
     unsigned tslice_ms, tick_period_us, ticks_per_tslice;
     unsigned credits_per_tslice;
@@ -1297,10 +1298,15 @@ csched_schedule(
     struct csched_private *prv = CSCHED_PRIV(ops);
     struct csched_vcpu *snext;
     struct task_slice ret;
+    s_time_t runtime, tslice;
 
     CSCHED_STAT_CRANK(schedule);
     CSCHED_VCPU_CHECK(current);
 
+    runtime = now - current->runstate.state_entry_time;
+    if ( runtime < 0 ) /* Does this ever happen? */
+        runtime = 0;
+
     if ( !is_idle_vcpu(scurr->vcpu) )
     {
         /* Update credits of a non-idle VCPU. */
@@ -1313,6 +1319,35 @@ csched_schedule(
         scurr->pri = CSCHED_PRI_IDLE;
     }
 
+    /* Choices, choices:
+     * - If we have a tasklet, we need to run the idle vcpu no matter what.
+     * - If sched rate limiting is in effect, and the current vcpu has
+     *   run for less than that amount of time, continue the current one,
+     *   but with a shorter timeslice and return it immediately
+     * - Otherwise, chose the one with the highest priority (which may
+     *   be the one currently running)
+     * - If the currently running one is TS_OVER, see if there
+     *   is a higher priority one waiting on the runqueue of another
+     *   cpu and steal it.
+     */
+
+    /* If we have schedule rate limiting enabled, check to see
+     * how long we've run for. */
+    if ( !tasklet_work_scheduled
+         && prv->ratelimit_us
+         && vcpu_runnable(current)
+         && !is_idle_vcpu(current)
+         && runtime < MICROSECS(prv->ratelimit_us) )
+    {
+        snext = scurr;
+        snext->start_time += now;
+        perfc_incr(delay_ms);
+        tslice = MICROSECS(prv->ratelimit_us);
+        ret.migrated = 0;
+        goto out;
+    }
+    tslice = MILLISECS(prv->tslice_ms);
+
     /*
      * Select next runnable local VCPU (ie top of local runq)
      */
@@ -1367,11 +1402,12 @@ csched_schedule(
     if ( !is_idle_vcpu(snext->vcpu) )
         snext->start_time += now;
 
+out:
     /*
      * Return task to run next...
      */
     ret.time = (is_idle_vcpu(snext->vcpu) ?
-                -1 : MILLISECS(prv->tslice_ms));
+                -1 : tslice);
     ret.task = snext->vcpu;
 
     CSCHED_VCPU_CHECK(ret.task);
@@ -1533,6 +1569,15 @@ csched_init(struct scheduler *ops)
     prv->tick_period_us = prv->tslice_ms * 1000 / prv->ticks_per_tslice;
     prv->credits_per_tslice = CSCHED_CREDITS_PER_MSEC * prv->tslice_ms;
 
+    if ( MICROSECS(sched_ratelimit_us) > MILLISECS(sched_credit_tslice_ms) )
+    {
+        printk("WARNING: sched_ratelimit_us >" 
+               "sched_credit_tslice_ms is undefined\n"
+               "ratelimit_us is set to 1000 * tslice_ms forcely\n");
+        prv->ratelimit_us = 1000 * prv->tslice_ms;
+    }
+    else
+        prv->ratelimit_us = sched_ratelimit_us;
     return 0;
 }
 
diff -r a4bff36780a3 -r 18f40e1d0274 xen/common/schedule.c
--- a/xen/common/schedule.c	Fri Dec 16 18:46:27 2011 +0000
+++ b/xen/common/schedule.c	Mon Dec 26 03:44:39 2011 -0500
@@ -47,6 +47,11 @@ string_param("sched", opt_sched);
 bool_t sched_smt_power_savings = 0;
 boolean_param("sched_smt_power_savings", sched_smt_power_savings);
 
+/* Default scheduling rate limit: 1ms 
+ * The behavior when sched_ratelimit_us is greater than sched_credit_tslice_ms is undefined
+ * */
+int sched_ratelimit_us = 1000;
+integer_param("sched_ratelimit_us", sched_ratelimit_us);
 /* Various timer handlers. */
 static void s_timer_fn(void *unused);
 static void vcpu_periodic_timer_fn(void *data);
diff -r a4bff36780a3 -r 18f40e1d0274 xen/include/xen/perfc_defn.h
--- a/xen/include/xen/perfc_defn.h	Fri Dec 16 18:46:27 2011 +0000
+++ b/xen/include/xen/perfc_defn.h	Mon Dec 26 03:44:39 2011 -0500
@@ -16,6 +16,7 @@ PERFCOUNTER(sched_irq,              "sch
 PERFCOUNTER(sched_run,              "sched: runs through scheduler")
 PERFCOUNTER(sched_ctx,              "sched: context switches")
 
+PERFCOUNTER(delay_ms,               "csched: delay")
 PERFCOUNTER(vcpu_check,             "csched: vcpu_check")
 PERFCOUNTER(schedule,               "csched: schedule")
 PERFCOUNTER(acct_run,               "csched: acct_run")
diff -r a4bff36780a3 -r 18f40e1d0274 xen/include/xen/sched-if.h
--- a/xen/include/xen/sched-if.h	Fri Dec 16 18:46:27 2011 +0000
+++ b/xen/include/xen/sched-if.h	Mon Dec 26 03:44:39 2011 -0500
@@ -16,6 +16,11 @@ extern struct cpupool *cpupool0;
 /* cpus currently in no cpupool */
 extern cpumask_t cpupool_free_cpus;
 
+/* Scheduler generic parameters
+ * */
+extern int sched_ratelimit_us;
+
+
 /*
  * In order to allow a scheduler to remap the lock->cpu mapping,
  * we have a per-cpu pointer, along with a pre-allocated set of

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 26 15:45:03 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 26 Dec 2011 15:45:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RfCi4-0003xf-N7; Mon, 26 Dec 2011 15:43:32 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <hui.lv@intel.com>) id 1RfCi2-0003xa-DG
	for xen-devel@lists.xensource.com; Mon, 26 Dec 2011 15:43:30 +0000
X-Env-Sender: hui.lv@intel.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1324914202!8676921!1
X-Originating-IP: [143.182.124.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjE2MTE2\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6922 invoked from network); 26 Dec 2011 15:43:23 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-2.tower-182.messagelabs.com with SMTP;
	26 Dec 2011 15:43:23 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga101.ch.intel.com with ESMTP; 26 Dec 2011 07:43:21 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="89612038"
Received: from unknown (HELO [127.0.0.1]) ([10.239.44.119])
	by azsmga001.ch.intel.com with ESMTP; 26 Dec 2011 07:43:20 -0800
MIME-Version: 1.0
X-Mercurial-Node: 18f40e1d027491964a88b43a4e2cc617ef39238b
Message-Id: <18f40e1d027491964a88.1324889181@wsm-ep-n0>
User-Agent: Mercurial-patchbomb/1.4
Date: Mon, 26 Dec 2011 03:46:21 -0500
From: Hui Lv <hui.lv@intel.com>
To: xen-devel@lists.xensource.com, George.Dunlap@eu.citrix.com,
	raistlin@linux.it, JBeulich@suse.com, Ian.Campbell@citrix.com
Cc: hui.lv@intel.com
Subject: [Xen-devel] [PATCH] xen/sched_credit: Use delay to control
	scheduling frequency
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Some modifications for this patch.
1.Based on George's proposal, added a ratelimit_us element to csched_priv to constrain prv->ratelimit_us <= 1000* prv->tslice_ms in csched_init.
2.Move the definition of sched_ratelimit_us to xen/sched.h
3.Remove the redundant "else" structure

See if you have any comment for such changes.


This patch can improve Xen performance:
1. Basically, the "delay method" can achieve 11% overall performance boost for SPECvirt than original credit scheduler.
2. We have tried 1ms delay and 10ms delay, there is no big difference between these two configurations. (1ms is enough to achieve a good performance)
3. We have compared different load level response time/latency (low, high, peak), "delay method" didn't bring very much response time increase.
4. 1ms delay can reduce 30% context switch at peak performance, where produces the benefits. (int sched_ratelimit_us = 1000 is the recommended setting)

Signed-off-by: Hui Lv <hui.lv@intel.com>
Signed-off-by: George Dunlap <George.Dunlap@eu.citrix.com>

diff -r a4bff36780a3 -r 18f40e1d0274 xen/common/sched_credit.c
--- a/xen/common/sched_credit.c	Fri Dec 16 18:46:27 2011 +0000
+++ b/xen/common/sched_credit.c	Mon Dec 26 03:44:39 2011 -0500
@@ -172,6 +172,7 @@ struct csched_private {
     uint32_t credit;
     int credit_balance;
     uint32_t runq_sort;
+    unsigned ratelimit_us;
     /* Period of master and tick in milliseconds */
     unsigned tslice_ms, tick_period_us, ticks_per_tslice;
     unsigned credits_per_tslice;
@@ -1297,10 +1298,15 @@ csched_schedule(
     struct csched_private *prv = CSCHED_PRIV(ops);
     struct csched_vcpu *snext;
     struct task_slice ret;
+    s_time_t runtime, tslice;
 
     CSCHED_STAT_CRANK(schedule);
     CSCHED_VCPU_CHECK(current);
 
+    runtime = now - current->runstate.state_entry_time;
+    if ( runtime < 0 ) /* Does this ever happen? */
+        runtime = 0;
+
     if ( !is_idle_vcpu(scurr->vcpu) )
     {
         /* Update credits of a non-idle VCPU. */
@@ -1313,6 +1319,35 @@ csched_schedule(
         scurr->pri = CSCHED_PRI_IDLE;
     }
 
+    /* Choices, choices:
+     * - If we have a tasklet, we need to run the idle vcpu no matter what.
+     * - If sched rate limiting is in effect, and the current vcpu has
+     *   run for less than that amount of time, continue the current one,
+     *   but with a shorter timeslice and return it immediately
+     * - Otherwise, chose the one with the highest priority (which may
+     *   be the one currently running)
+     * - If the currently running one is TS_OVER, see if there
+     *   is a higher priority one waiting on the runqueue of another
+     *   cpu and steal it.
+     */
+
+    /* If we have schedule rate limiting enabled, check to see
+     * how long we've run for. */
+    if ( !tasklet_work_scheduled
+         && prv->ratelimit_us
+         && vcpu_runnable(current)
+         && !is_idle_vcpu(current)
+         && runtime < MICROSECS(prv->ratelimit_us) )
+    {
+        snext = scurr;
+        snext->start_time += now;
+        perfc_incr(delay_ms);
+        tslice = MICROSECS(prv->ratelimit_us);
+        ret.migrated = 0;
+        goto out;
+    }
+    tslice = MILLISECS(prv->tslice_ms);
+
     /*
      * Select next runnable local VCPU (ie top of local runq)
      */
@@ -1367,11 +1402,12 @@ csched_schedule(
     if ( !is_idle_vcpu(snext->vcpu) )
         snext->start_time += now;
 
+out:
     /*
      * Return task to run next...
      */
     ret.time = (is_idle_vcpu(snext->vcpu) ?
-                -1 : MILLISECS(prv->tslice_ms));
+                -1 : tslice);
     ret.task = snext->vcpu;
 
     CSCHED_VCPU_CHECK(ret.task);
@@ -1533,6 +1569,15 @@ csched_init(struct scheduler *ops)
     prv->tick_period_us = prv->tslice_ms * 1000 / prv->ticks_per_tslice;
     prv->credits_per_tslice = CSCHED_CREDITS_PER_MSEC * prv->tslice_ms;
 
+    if ( MICROSECS(sched_ratelimit_us) > MILLISECS(sched_credit_tslice_ms) )
+    {
+        printk("WARNING: sched_ratelimit_us >" 
+               "sched_credit_tslice_ms is undefined\n"
+               "ratelimit_us is set to 1000 * tslice_ms forcely\n");
+        prv->ratelimit_us = 1000 * prv->tslice_ms;
+    }
+    else
+        prv->ratelimit_us = sched_ratelimit_us;
     return 0;
 }
 
diff -r a4bff36780a3 -r 18f40e1d0274 xen/common/schedule.c
--- a/xen/common/schedule.c	Fri Dec 16 18:46:27 2011 +0000
+++ b/xen/common/schedule.c	Mon Dec 26 03:44:39 2011 -0500
@@ -47,6 +47,11 @@ string_param("sched", opt_sched);
 bool_t sched_smt_power_savings = 0;
 boolean_param("sched_smt_power_savings", sched_smt_power_savings);
 
+/* Default scheduling rate limit: 1ms 
+ * The behavior when sched_ratelimit_us is greater than sched_credit_tslice_ms is undefined
+ * */
+int sched_ratelimit_us = 1000;
+integer_param("sched_ratelimit_us", sched_ratelimit_us);
 /* Various timer handlers. */
 static void s_timer_fn(void *unused);
 static void vcpu_periodic_timer_fn(void *data);
diff -r a4bff36780a3 -r 18f40e1d0274 xen/include/xen/perfc_defn.h
--- a/xen/include/xen/perfc_defn.h	Fri Dec 16 18:46:27 2011 +0000
+++ b/xen/include/xen/perfc_defn.h	Mon Dec 26 03:44:39 2011 -0500
@@ -16,6 +16,7 @@ PERFCOUNTER(sched_irq,              "sch
 PERFCOUNTER(sched_run,              "sched: runs through scheduler")
 PERFCOUNTER(sched_ctx,              "sched: context switches")
 
+PERFCOUNTER(delay_ms,               "csched: delay")
 PERFCOUNTER(vcpu_check,             "csched: vcpu_check")
 PERFCOUNTER(schedule,               "csched: schedule")
 PERFCOUNTER(acct_run,               "csched: acct_run")
diff -r a4bff36780a3 -r 18f40e1d0274 xen/include/xen/sched-if.h
--- a/xen/include/xen/sched-if.h	Fri Dec 16 18:46:27 2011 +0000
+++ b/xen/include/xen/sched-if.h	Mon Dec 26 03:44:39 2011 -0500
@@ -16,6 +16,11 @@ extern struct cpupool *cpupool0;
 /* cpus currently in no cpupool */
 extern cpumask_t cpupool_free_cpus;
 
+/* Scheduler generic parameters
+ * */
+extern int sched_ratelimit_us;
+
+
 /*
  * In order to allow a scheduler to remap the lock->cpu mapping,
  * we have a per-cpu pointer, along with a pre-allocated set of

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 26 18:47:09 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 26 Dec 2011 18:47:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RfFYN-0004zo-91; Mon, 26 Dec 2011 18:45:43 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <thunderbird2k@gmail.com>) id 1RfFYL-0004zj-NC
	for xen-devel@lists.xensource.com; Mon, 26 Dec 2011 18:45:42 +0000
X-Env-Sender: thunderbird2k@gmail.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1324925132!6940615!1
X-Originating-IP: [209.85.213.171]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22217 invoked from network); 26 Dec 2011 18:45:34 -0000
Received: from mail-yx0-f171.google.com (HELO mail-yx0-f171.google.com)
	(209.85.213.171)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Dec 2011 18:45:34 -0000
Received: by yenr9 with SMTP id r9so166457569yen.30
	for <xen-devel@lists.xensource.com>;
	Mon, 26 Dec 2011 10:45:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=lHJ5MFCD0Xg/7LxQagX+f9psA86sgPynz3wx5K1OReA=;
	b=rjy6u+ltx7O5j6ICLWhaMwH/Kfz/ccfHicY7/orff0hOat8g/d6CIJps/UMQzsXYBo
	tiRk0FXZEneWDziC9WRVXIH7ul/QMXkgcyVDg5fwf49EaV7967r60AH+JVTpYxw3BUyn
	bvwwdmPe3OHKBrhBFz/GoYRfaStZw6oglUCWY=
MIME-Version: 1.0
Received: by 10.236.183.52 with SMTP id p40mr34420430yhm.19.1324925132251;
	Mon, 26 Dec 2011 10:45:32 -0800 (PST)
Received: by 10.100.27.35 with HTTP; Mon, 26 Dec 2011 10:45:32 -0800 (PST)
In-Reply-To: <CAEc3jaA8q1fLaH60MgtCtqMyUbE97cmtiERUFSOJsAY1HiK-ig@mail.gmail.com>
References: <CAEc3jaACffpr9D1Hq_012vHAGhPLEfvsZjh7YyJ=Q-3FdtHS0Q@mail.gmail.com>
	<CAPbh3rtOQ1HTPReqYcpE3vzk+-na0MTLLHZD15=Fg4yxB+ypaA@mail.gmail.com>
	<CAEc3jaBdQKmVJToNZRf+25GtJXqGc274ieHf_yHKRJ+YOKWdgA@mail.gmail.com>
	<20111208234624.GD32474@konrad-lan>
	<CAEc3jaC9=HiMoxSYZmXKRzoFcMYRaT9jrX3m1ZQO+M8CrH35Fg@mail.gmail.com>
	<CAEc3jaBBYBME0G3Ku_sTvzQz+oKQnpBPffA+bRUKxxRPABAeww@mail.gmail.com>
	<20111211125247.GQ12984@reaktio.net>
	<CAEc3jaCJ6wP27Ffm0wpOggWMgqcSNJiGxhtkszq6jgRD1nrZLg@mail.gmail.com>
	<CAEc3jaBS6WUB_oViMp=qT_0RP+LPjZuEV8Qko9Jabs6qaeSibQ@mail.gmail.com>
	<20111213020229.GB2730@konrad-lan>
	<20111213212031.GA8410@konrad-lan>
	<CAEc3jaA8q1fLaH60MgtCtqMyUbE97cmtiERUFSOJsAY1HiK-ig@mail.gmail.com>
Date: Mon, 26 Dec 2011 18:45:32 +0000
Message-ID: <CAEc3jaCwiKhxdJAGjQ4vL-s3sWVwmFbho7+BDH20OaSNQEPO8Q@mail.gmail.com>
From: Roderick Colenbrander <thunderbird2k@gmail.com>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
Cc: xen-devel@lists.xensource.com, Andreas Kinzler <ml-xen-devel@hfp.de>
Subject: Re: [Xen-devel] Questions about GPLPV stability tests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

I have finally got some results (the tests are still running). Let me
first summarize what tests were running.

In total I had 4 machines. All systems had at least Xen 4.1.2 + Linux
2.6.32.48 (and one had a Xen 4.1.3 snapshot). I divided the systems
into 2 groups and each group ran a different test. There are 2
differencess between the groups:
1) one was the use of blktap vs not using blktap. The main reason for
having the blktap systems in even though it adds noise, is that it
kept some of tests close to what they previously were.
2) the non-blktap systems used a different cpu pinning configuration.
Previously Dom0 was using 0-3 and DomU 4-7, but due to hyperthreading
both VMs used the same cores (0 and 4 are on the same physical core).

Now to the initial results.
- so far each machine has been up for 10 days.
- one machine failed early on due to a PCI device assignment issue. I
suspect that at some point due to a race condition, ownership of the
PCI device wasn't transferred correctly back from DomU to Dom0 on VM
shutdown. Xm and Xl respectively fail with 'Error: failed to assign
device 03:00.0: maybe it has already been assigned to other domain, or
maybe it doesn't exist.' From a quick glance at the logs it looks like
on shutdown of a previous VM, the 'unmap bdf' never happened. Not sure
why, but I guess due to a potential toolchain bug.

- One of the non-blktap machines had a kernel Oops. It happened on VM
shutdown and I wouldn't be surprised if it was similar to the crashes
we wanted to debug. The system is in a usable state though, but this
may have been due to the use of Linux 2.6.32.48 or the different CPU
pinning configuration. Some of the serial output:

Thu Dec 22 23:17:38 2011 - 1232   0: 87    113   365   blkif-backend
     525325sec

Thu Dec 22 23:30:07 2011 - 1259   0: 12    6     222   xenbus
     526065sec
Thu Dec 22 23:30:07 2011 - 1250   0: 62    42    1461  ahci
     526065sec
Thu Dec 22 23:30:07 2011 - 1249   0: 37    28    75    eth0-rx-0
     526065sec
Thu Dec 22 23:30:07 2011 - 1248   0: 71    305   933   eth0-tx-0
     526065sec
Thu Dec 22 23:30:07 2011 - 1243   0: 6     3     134
evtchn:xenstored     526065sec
Thu Dec 22 23:30:07 2011 - 1241   0: 6     3     87582
evtchn:xenstored     526065sec
Thu Dec 22 23:30:07 2011 - 1240   0: 256   261   54162 evtchn:qemu-dm
     526065sec
Thu Dec 22 23:30:07 2011 - 1239   0: 244   251   7219  evtchn:qemu-dm
     526065sec
Thu Dec 22 23:30:07 2011 - 1238   0: 289   273   5931  evtchn:qemu-dm
     526065sec
Thu Dec 22 23:30:07 2011 - 1237   0: 248   245   4279  evtchn:qemu-dm
     526065sec
Thu Dec 22 23:30:07 2011 - 1236   0: 12    7     315   blkif-backend
     526065sec
Thu Dec 22 23:30:07 2011 - 1234   0: 7     4     43    veth1
     526065sec
Thu Dec 22 23:30:07 2011 - 1232 CPU0 going backwards (-3304)!
Thu Dec 22 23:30:07 2011 -   19 CPU0 going backwards (-212)!
Thu Dec 22 23:30:07 2011 -   18   0: 35    17    35    ehci_hcd:usb1,
uhci_hcd:usb8 526065sec
Thu Dec 22 23:30:07 2011 -   16 CPU0 going backwards (-176)!
Thu Dec 22 23:30:07 2011 -   12 CPU0 going backwards (-4)!
Thu Dec 22 23:30:07 2011 -    4 CPU0 going backwards (-1)!
Thu Dec 22 23:30:12 2011 - 1250   0: 384   213   1461  ahci
     526070sec
Thu Dec 22 23:30:12 2011 - 1249   0: 14    21    75    eth0-rx-0
     526070sec
Thu Dec 22 23:30:12 2011 - 1240   0: 260   260   54162 evtchn:qemu-dm
     526070sec
Thu Dec 22 23:30:12 2011 - 1239   0: 279   265   7219  evtchn:qemu-dm
     526070sec
Thu Dec 22 23:30:13 2011 - 1238   0: 271   272   5931  evtchn:qemu-dm
     526070sec
Thu Dec 22 23:30:13 2011 - 1237   0: 261   253   4279  evtchn:qemu-dm
     526070sec
Thu Dec 22 23:30:13 2011 - 1236   0: 145   76    315   blkif-backend
     526070sec
Thu Dec 22 23:30:18 2011 - 1250   0: 372   293   1461  ahci
     526075sec
Thu Dec 22 23:30:18 2011 - 1249   0: 26    24    75    eth0-rx-0
     526075sec
Thu Dec 22 23:30:18 2011 - 1248   0: 16    86    933   eth0-tx-0
     526075sec
Thu Dec 22 23:30:18 2011 - 1240   0: 234   247   54162 evtchn:qemu-dm
     526075sec
Thu Dec 22 23:30:18 2011 - 1239   0: 234   249   7219  evtchn:qemu-dm
     526075sec
Thu Dec 22 23:30:18 2011 - 1238   0: 241   256   5931  evtchn:qemu-dm
     526075sec
Thu Dec 22 23:30:18 2011 - 1237   0: 224   239   4279  evtchn:qemu-dm
     526075sec
Thu Dec 22 23:30:18 2011 - 1236   0: 100   88    315   blkif-backend
     526075sec
Thu Dec 22 23:30:23 2011 - 1249   0: 16    20    75    eth0-rx-0
     526080sec
Thu Dec 22 23:30:23 2011 - 1248   0: 7     46    933   eth0-tx-0
     526080sec
Thu Dec 22 23:30:23 2011 - 1240   0: 8     128   54162 evtchn:qemu-dm
     526080sec
Thu Dec 22 23:30:23 2011 - 1239   0: 16    133   7219  evtchn:qemu-dm
     526080sec
Thu Dec 22 23:30:23 2011 - 1238   0: 28    142   5931  evtchn:qemu-dm
     526080sec
Thu Dec 22 23:30:23 2011 - 1233 CPU0 going backwards (-12648)!
Thu Dec 22 23:30:23 2011 -   19 CPU0 going backwards (-212)!
Thu Dec 22 23:30:23 2011 -   18   0: 35    17    42    ehci_hcd:usb1,
uhci_hcd:usb8 526080sec
Thu Dec 22 23:30:23 2011 -   16 CPU0 going backwards (-176)!
Thu Dec 22 23:30:23 2011 -   12 CPU0 going backwards (-4)!
Thu Dec 22 23:30:23 2011 -    4 CPU0 going backwards (-1)!

[533804.785589] BUG: unable to handle kernel NULL pointer dereference
at 0000000000000008
[533804.793913] IP: [<ffffffff814bdba9>] _spin_lock+0x5/0x15
[533804.799556] PGD 0
[533804.801896] Oops: 0002 [#1] SMP
[533804.805448] last sysfs file:
/sys/devices/pci0000:00/0000:00:03.0/0000:03:00.0/class
[533804.813736] CPU 0
[533804.816066] Modules linked in: dm_snapshot dm_mod ipmi_si ipmi_devintf
[533804.822914] Pid: 21632, comm: qemu-dm Not tainted 2.6.32.48 #1 X8STi
[533804.829595] RIP: e030:[<ffffffff814bdba9>]  [<ffffffff814bdba9>]
_spin_lock+0x5/0x15
[533804.837873] RSP: e02b:ffff88005f187c50  EFLAGS: 00010202
[533804.843513] RAX: 0000000000000100 RBX: ffff88007d6923c0 RCX:
0000000000000003
[533804.851192] RDX: ffff88007deb3180 RSI: ffff88007d6923c0 RDI:
0000000000000008
[533804.858871] RBP: ffff88007e260128 R08: 0000000000000000 R09:
0000000000000000
[533804.866552] R10: ffff88007121eb40 R11: ffffffff811b862b R12:
ffff88007fac1e40
[533804.874541] R13: ffff88007e3c3340 R14: ffff88007e3c3340 R15:
ffff88007fdfbc00
[533804.882243] FS:  00007f5cdcefe6f0(0000) GS:ffff880028038000(0000)
knlGS:0000000000000000
[533804.890874] CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
[533804.896948] CR2: 0000000000000008 CR3: 0000000001001000 CR4:
0000000000002660
[533804.904627] DR0: 0000000000000000 DR1: 0000000000000000 DR2:
0000000000000000
[533804.912306] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7:
0000000000000400
[533804.919985] Process qemu-dm (pid: 21632, threadinfo
ffff88005f186000, task ffff880074f4e270)
[533804.928971] Stack:
[533804.931312]  ffffffff810a9ad0 ffff88007deb3180 ffff88007e260100
ffff88007e260100
[533804.938762] <0> ffffffff8124222d 0000000000000008 0000000000000008
ffff88007deb3180
[533804.946900] <0> ffffffff810b245e ffff88007fac1e40 ffff88007deb3180
0000000000000000
[533804.955465] Call Trace:
[533804.958244]  [<ffffffff810a9ad0>] ? mmu_notifier_unregister+0x27/0xa5
[533804.965019]  [<ffffffff8124222d>] ? gntdev_release+0xc3/0xd1
[533804.971007]  [<ffffffff810b245e>] ? __fput+0x100/0x1af
[533804.976477]  [<ffffffff810af998>] ? filp_close+0x5b/0x62
[533804.982119]  [<ffffffff81042989>] ? put_files_struct+0x64/0xc1
[533804.988280]  [<ffffffff810441f0>] ? do_exit+0x209/0x68d
[533804.993836]  [<ffffffff810441f8>] ? do_exit+0x211/0x68d
[533804.999390]  [<ffffffff810446e9>] ? do_group_exit+0x75/0x9c
[533805.005294]  [<ffffffff8104cf1d>] ? get_signal_to_deliver+0x30d/0x338
[533805.012063]  [<ffffffff81010f7a>] ? do_notify_resume+0x8a/0x6b1
[533805.018310]  [<ffffffff810bdb3a>] ? poll_select_copy_remaining+0xd0/0xf3
[533805.025339]  [<ffffffff81011c8e>] ? int_signal+0x12/0x17
[533805.030980] Code: 00 00 00 01 74 05 e8 67 1c d2 ff 48 89 d0 5e c3
ff 14 25 20 2d 6a 81 f0 81 2f 00 00 00 01 74 05 e8 4d 1c d2 ff c3 b8
00 01 00 00 <f0> 66 0f c1 07 38 e0 74 06 f3 90 8a 07 eb f6 c3 f0 81 2f
00 00
[533805.050454] RIP  [<ffffffff814bdba9>] _spin_lock+0x5/0x15
[533805.056182]  RSP <ffff88005f187c50>
[533805.059997] CR2: 0000000000000008
[533805.063638] ---[ end trace 85ee7cbec9ce72ac ]---
[533805.068584] Fixing recursive fault but reboot is needed!

If I had to guess, some of the gnttab code in qemu triggered a bug in
the gntdev code? I have some experience with gnttab/gntdev, but don't
know the inner parts of it very well.

Roderick

On Fri, Dec 16, 2011 at 2:25 AM, Roderick Colenbrander
<thunderbird2k@gmail.com> wrote:
> Thanks. On Tuesday I set up your monitoring tool on the already
> running tests. Some of the systems were on the verge of showing
> results, but we just had a power outage and I have to restart the
> tests. It will probably take until the Holidays before there any
> results :(
>
> Roderick
>
> On Tue, Dec 13, 2011 at 9:20 PM, Konrad Rzeszutek Wilk
> <konrad@darnok.org> wrote:
>>> > Does this feel like blktap issues? Or is it more likely that something
>>> > else happened which causes blktap and the other things to fail?
>>>
>>> It looks like the interrupts stopped. Perhaps you can run the C code
>>> (attached) on the serial console and see _what_ (or perhaps _when_)
>>> the interrupts stops (and also verify that the timeouts and 'frozen'
>>> happen due to no interrupts being received).
>>
>> The C code is http://darnok.org/xen/read_interrupts.c
>>
>>>
>>> There are a couple of bugs that were discovered in the interrupt code
>>> (that had been there since 2.6.27!) that went to the stable tree - so
>>> they should been backported to 2.6.32.x tree - but I honestly don't
>>> recall the names. I can look them up tomorrow.
>>
>> xen: x86_32: do not enable iterrupts when returning from exception in
>> interrupt context (git commit d198d499148a0c64a41b3aba9e7dd43772832b91)
>>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Dec 26 18:47:09 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 26 Dec 2011 18:47:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RfFYN-0004zo-91; Mon, 26 Dec 2011 18:45:43 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <thunderbird2k@gmail.com>) id 1RfFYL-0004zj-NC
	for xen-devel@lists.xensource.com; Mon, 26 Dec 2011 18:45:42 +0000
X-Env-Sender: thunderbird2k@gmail.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1324925132!6940615!1
X-Originating-IP: [209.85.213.171]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22217 invoked from network); 26 Dec 2011 18:45:34 -0000
Received: from mail-yx0-f171.google.com (HELO mail-yx0-f171.google.com)
	(209.85.213.171)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Dec 2011 18:45:34 -0000
Received: by yenr9 with SMTP id r9so166457569yen.30
	for <xen-devel@lists.xensource.com>;
	Mon, 26 Dec 2011 10:45:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=lHJ5MFCD0Xg/7LxQagX+f9psA86sgPynz3wx5K1OReA=;
	b=rjy6u+ltx7O5j6ICLWhaMwH/Kfz/ccfHicY7/orff0hOat8g/d6CIJps/UMQzsXYBo
	tiRk0FXZEneWDziC9WRVXIH7ul/QMXkgcyVDg5fwf49EaV7967r60AH+JVTpYxw3BUyn
	bvwwdmPe3OHKBrhBFz/GoYRfaStZw6oglUCWY=
MIME-Version: 1.0
Received: by 10.236.183.52 with SMTP id p40mr34420430yhm.19.1324925132251;
	Mon, 26 Dec 2011 10:45:32 -0800 (PST)
Received: by 10.100.27.35 with HTTP; Mon, 26 Dec 2011 10:45:32 -0800 (PST)
In-Reply-To: <CAEc3jaA8q1fLaH60MgtCtqMyUbE97cmtiERUFSOJsAY1HiK-ig@mail.gmail.com>
References: <CAEc3jaACffpr9D1Hq_012vHAGhPLEfvsZjh7YyJ=Q-3FdtHS0Q@mail.gmail.com>
	<CAPbh3rtOQ1HTPReqYcpE3vzk+-na0MTLLHZD15=Fg4yxB+ypaA@mail.gmail.com>
	<CAEc3jaBdQKmVJToNZRf+25GtJXqGc274ieHf_yHKRJ+YOKWdgA@mail.gmail.com>
	<20111208234624.GD32474@konrad-lan>
	<CAEc3jaC9=HiMoxSYZmXKRzoFcMYRaT9jrX3m1ZQO+M8CrH35Fg@mail.gmail.com>
	<CAEc3jaBBYBME0G3Ku_sTvzQz+oKQnpBPffA+bRUKxxRPABAeww@mail.gmail.com>
	<20111211125247.GQ12984@reaktio.net>
	<CAEc3jaCJ6wP27Ffm0wpOggWMgqcSNJiGxhtkszq6jgRD1nrZLg@mail.gmail.com>
	<CAEc3jaBS6WUB_oViMp=qT_0RP+LPjZuEV8Qko9Jabs6qaeSibQ@mail.gmail.com>
	<20111213020229.GB2730@konrad-lan>
	<20111213212031.GA8410@konrad-lan>
	<CAEc3jaA8q1fLaH60MgtCtqMyUbE97cmtiERUFSOJsAY1HiK-ig@mail.gmail.com>
Date: Mon, 26 Dec 2011 18:45:32 +0000
Message-ID: <CAEc3jaCwiKhxdJAGjQ4vL-s3sWVwmFbho7+BDH20OaSNQEPO8Q@mail.gmail.com>
From: Roderick Colenbrander <thunderbird2k@gmail.com>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
Cc: xen-devel@lists.xensource.com, Andreas Kinzler <ml-xen-devel@hfp.de>
Subject: Re: [Xen-devel] Questions about GPLPV stability tests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

I have finally got some results (the tests are still running). Let me
first summarize what tests were running.

In total I had 4 machines. All systems had at least Xen 4.1.2 + Linux
2.6.32.48 (and one had a Xen 4.1.3 snapshot). I divided the systems
into 2 groups and each group ran a different test. There are 2
differencess between the groups:
1) one was the use of blktap vs not using blktap. The main reason for
having the blktap systems in even though it adds noise, is that it
kept some of tests close to what they previously were.
2) the non-blktap systems used a different cpu pinning configuration.
Previously Dom0 was using 0-3 and DomU 4-7, but due to hyperthreading
both VMs used the same cores (0 and 4 are on the same physical core).

Now to the initial results.
- so far each machine has been up for 10 days.
- one machine failed early on due to a PCI device assignment issue. I
suspect that at some point due to a race condition, ownership of the
PCI device wasn't transferred correctly back from DomU to Dom0 on VM
shutdown. Xm and Xl respectively fail with 'Error: failed to assign
device 03:00.0: maybe it has already been assigned to other domain, or
maybe it doesn't exist.' From a quick glance at the logs it looks like
on shutdown of a previous VM, the 'unmap bdf' never happened. Not sure
why, but I guess due to a potential toolchain bug.

- One of the non-blktap machines had a kernel Oops. It happened on VM
shutdown and I wouldn't be surprised if it was similar to the crashes
we wanted to debug. The system is in a usable state though, but this
may have been due to the use of Linux 2.6.32.48 or the different CPU
pinning configuration. Some of the serial output:

Thu Dec 22 23:17:38 2011 - 1232   0: 87    113   365   blkif-backend
     525325sec

Thu Dec 22 23:30:07 2011 - 1259   0: 12    6     222   xenbus
     526065sec
Thu Dec 22 23:30:07 2011 - 1250   0: 62    42    1461  ahci
     526065sec
Thu Dec 22 23:30:07 2011 - 1249   0: 37    28    75    eth0-rx-0
     526065sec
Thu Dec 22 23:30:07 2011 - 1248   0: 71    305   933   eth0-tx-0
     526065sec
Thu Dec 22 23:30:07 2011 - 1243   0: 6     3     134
evtchn:xenstored     526065sec
Thu Dec 22 23:30:07 2011 - 1241   0: 6     3     87582
evtchn:xenstored     526065sec
Thu Dec 22 23:30:07 2011 - 1240   0: 256   261   54162 evtchn:qemu-dm
     526065sec
Thu Dec 22 23:30:07 2011 - 1239   0: 244   251   7219  evtchn:qemu-dm
     526065sec
Thu Dec 22 23:30:07 2011 - 1238   0: 289   273   5931  evtchn:qemu-dm
     526065sec
Thu Dec 22 23:30:07 2011 - 1237   0: 248   245   4279  evtchn:qemu-dm
     526065sec
Thu Dec 22 23:30:07 2011 - 1236   0: 12    7     315   blkif-backend
     526065sec
Thu Dec 22 23:30:07 2011 - 1234   0: 7     4     43    veth1
     526065sec
Thu Dec 22 23:30:07 2011 - 1232 CPU0 going backwards (-3304)!
Thu Dec 22 23:30:07 2011 -   19 CPU0 going backwards (-212)!
Thu Dec 22 23:30:07 2011 -   18   0: 35    17    35    ehci_hcd:usb1,
uhci_hcd:usb8 526065sec
Thu Dec 22 23:30:07 2011 -   16 CPU0 going backwards (-176)!
Thu Dec 22 23:30:07 2011 -   12 CPU0 going backwards (-4)!
Thu Dec 22 23:30:07 2011 -    4 CPU0 going backwards (-1)!
Thu Dec 22 23:30:12 2011 - 1250   0: 384   213   1461  ahci
     526070sec
Thu Dec 22 23:30:12 2011 - 1249   0: 14    21    75    eth0-rx-0
     526070sec
Thu Dec 22 23:30:12 2011 - 1240   0: 260   260   54162 evtchn:qemu-dm
     526070sec
Thu Dec 22 23:30:12 2011 - 1239   0: 279   265   7219  evtchn:qemu-dm
     526070sec
Thu Dec 22 23:30:13 2011 - 1238   0: 271   272   5931  evtchn:qemu-dm
     526070sec
Thu Dec 22 23:30:13 2011 - 1237   0: 261   253   4279  evtchn:qemu-dm
     526070sec
Thu Dec 22 23:30:13 2011 - 1236   0: 145   76    315   blkif-backend
     526070sec
Thu Dec 22 23:30:18 2011 - 1250   0: 372   293   1461  ahci
     526075sec
Thu Dec 22 23:30:18 2011 - 1249   0: 26    24    75    eth0-rx-0
     526075sec
Thu Dec 22 23:30:18 2011 - 1248   0: 16    86    933   eth0-tx-0
     526075sec
Thu Dec 22 23:30:18 2011 - 1240   0: 234   247   54162 evtchn:qemu-dm
     526075sec
Thu Dec 22 23:30:18 2011 - 1239   0: 234   249   7219  evtchn:qemu-dm
     526075sec
Thu Dec 22 23:30:18 2011 - 1238   0: 241   256   5931  evtchn:qemu-dm
     526075sec
Thu Dec 22 23:30:18 2011 - 1237   0: 224   239   4279  evtchn:qemu-dm
     526075sec
Thu Dec 22 23:30:18 2011 - 1236   0: 100   88    315   blkif-backend
     526075sec
Thu Dec 22 23:30:23 2011 - 1249   0: 16    20    75    eth0-rx-0
     526080sec
Thu Dec 22 23:30:23 2011 - 1248   0: 7     46    933   eth0-tx-0
     526080sec
Thu Dec 22 23:30:23 2011 - 1240   0: 8     128   54162 evtchn:qemu-dm
     526080sec
Thu Dec 22 23:30:23 2011 - 1239   0: 16    133   7219  evtchn:qemu-dm
     526080sec
Thu Dec 22 23:30:23 2011 - 1238   0: 28    142   5931  evtchn:qemu-dm
     526080sec
Thu Dec 22 23:30:23 2011 - 1233 CPU0 going backwards (-12648)!
Thu Dec 22 23:30:23 2011 -   19 CPU0 going backwards (-212)!
Thu Dec 22 23:30:23 2011 -   18   0: 35    17    42    ehci_hcd:usb1,
uhci_hcd:usb8 526080sec
Thu Dec 22 23:30:23 2011 -   16 CPU0 going backwards (-176)!
Thu Dec 22 23:30:23 2011 -   12 CPU0 going backwards (-4)!
Thu Dec 22 23:30:23 2011 -    4 CPU0 going backwards (-1)!

[533804.785589] BUG: unable to handle kernel NULL pointer dereference
at 0000000000000008
[533804.793913] IP: [<ffffffff814bdba9>] _spin_lock+0x5/0x15
[533804.799556] PGD 0
[533804.801896] Oops: 0002 [#1] SMP
[533804.805448] last sysfs file:
/sys/devices/pci0000:00/0000:00:03.0/0000:03:00.0/class
[533804.813736] CPU 0
[533804.816066] Modules linked in: dm_snapshot dm_mod ipmi_si ipmi_devintf
[533804.822914] Pid: 21632, comm: qemu-dm Not tainted 2.6.32.48 #1 X8STi
[533804.829595] RIP: e030:[<ffffffff814bdba9>]  [<ffffffff814bdba9>]
_spin_lock+0x5/0x15
[533804.837873] RSP: e02b:ffff88005f187c50  EFLAGS: 00010202
[533804.843513] RAX: 0000000000000100 RBX: ffff88007d6923c0 RCX:
0000000000000003
[533804.851192] RDX: ffff88007deb3180 RSI: ffff88007d6923c0 RDI:
0000000000000008
[533804.858871] RBP: ffff88007e260128 R08: 0000000000000000 R09:
0000000000000000
[533804.866552] R10: ffff88007121eb40 R11: ffffffff811b862b R12:
ffff88007fac1e40
[533804.874541] R13: ffff88007e3c3340 R14: ffff88007e3c3340 R15:
ffff88007fdfbc00
[533804.882243] FS:  00007f5cdcefe6f0(0000) GS:ffff880028038000(0000)
knlGS:0000000000000000
[533804.890874] CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
[533804.896948] CR2: 0000000000000008 CR3: 0000000001001000 CR4:
0000000000002660
[533804.904627] DR0: 0000000000000000 DR1: 0000000000000000 DR2:
0000000000000000
[533804.912306] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7:
0000000000000400
[533804.919985] Process qemu-dm (pid: 21632, threadinfo
ffff88005f186000, task ffff880074f4e270)
[533804.928971] Stack:
[533804.931312]  ffffffff810a9ad0 ffff88007deb3180 ffff88007e260100
ffff88007e260100
[533804.938762] <0> ffffffff8124222d 0000000000000008 0000000000000008
ffff88007deb3180
[533804.946900] <0> ffffffff810b245e ffff88007fac1e40 ffff88007deb3180
0000000000000000
[533804.955465] Call Trace:
[533804.958244]  [<ffffffff810a9ad0>] ? mmu_notifier_unregister+0x27/0xa5
[533804.965019]  [<ffffffff8124222d>] ? gntdev_release+0xc3/0xd1
[533804.971007]  [<ffffffff810b245e>] ? __fput+0x100/0x1af
[533804.976477]  [<ffffffff810af998>] ? filp_close+0x5b/0x62
[533804.982119]  [<ffffffff81042989>] ? put_files_struct+0x64/0xc1
[533804.988280]  [<ffffffff810441f0>] ? do_exit+0x209/0x68d
[533804.993836]  [<ffffffff810441f8>] ? do_exit+0x211/0x68d
[533804.999390]  [<ffffffff810446e9>] ? do_group_exit+0x75/0x9c
[533805.005294]  [<ffffffff8104cf1d>] ? get_signal_to_deliver+0x30d/0x338
[533805.012063]  [<ffffffff81010f7a>] ? do_notify_resume+0x8a/0x6b1
[533805.018310]  [<ffffffff810bdb3a>] ? poll_select_copy_remaining+0xd0/0xf3
[533805.025339]  [<ffffffff81011c8e>] ? int_signal+0x12/0x17
[533805.030980] Code: 00 00 00 01 74 05 e8 67 1c d2 ff 48 89 d0 5e c3
ff 14 25 20 2d 6a 81 f0 81 2f 00 00 00 01 74 05 e8 4d 1c d2 ff c3 b8
00 01 00 00 <f0> 66 0f c1 07 38 e0 74 06 f3 90 8a 07 eb f6 c3 f0 81 2f
00 00
[533805.050454] RIP  [<ffffffff814bdba9>] _spin_lock+0x5/0x15
[533805.056182]  RSP <ffff88005f187c50>
[533805.059997] CR2: 0000000000000008
[533805.063638] ---[ end trace 85ee7cbec9ce72ac ]---
[533805.068584] Fixing recursive fault but reboot is needed!

If I had to guess, some of the gnttab code in qemu triggered a bug in
the gntdev code? I have some experience with gnttab/gntdev, but don't
know the inner parts of it very well.

Roderick

On Fri, Dec 16, 2011 at 2:25 AM, Roderick Colenbrander
<thunderbird2k@gmail.com> wrote:
> Thanks. On Tuesday I set up your monitoring tool on the already
> running tests. Some of the systems were on the verge of showing
> results, but we just had a power outage and I have to restart the
> tests. It will probably take until the Holidays before there any
> results :(
>
> Roderick
>
> On Tue, Dec 13, 2011 at 9:20 PM, Konrad Rzeszutek Wilk
> <konrad@darnok.org> wrote:
>>> > Does this feel like blktap issues? Or is it more likely that something
>>> > else happened which causes blktap and the other things to fail?
>>>
>>> It looks like the interrupts stopped. Perhaps you can run the C code
>>> (attached) on the serial console and see _what_ (or perhaps _when_)
>>> the interrupts stops (and also verify that the timeouts and 'frozen'
>>> happen due to no interrupts being received).
>>
>> The C code is http://darnok.org/xen/read_interrupts.c
>>
>>>
>>> There are a couple of bugs that were discovered in the interrupt code
>>> (that had been there since 2.6.27!) that went to the stable tree - so
>>> they should been backported to 2.6.32.x tree - but I honestly don't
>>> recall the names. I can look them up tomorrow.
>>
>> xen: x86_32: do not enable iterrupts when returning from exception in
>> interrupt context (git commit d198d499148a0c64a41b3aba9e7dd43772832b91)
>>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 27 00:56:35 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 27 Dec 2011 00:56:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RfLK7-0006dz-6G; Tue, 27 Dec 2011 00:55:23 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <mike.a.collins@ark-net.org>) id 1RfLK5-0006du-SS
	for xen-devel@lists.xensource.com; Tue, 27 Dec 2011 00:55:22 +0000
X-Env-Sender: mike.a.collins@ark-net.org
X-Msg-Ref: server-2.tower-216.messagelabs.com!1324947314!10185447!1
X-Originating-IP: [216.33.127.82]
X-SpamReason: No, hits=0.0 required=7.0 tests=SUBJECT_EXCESS_QP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4150 invoked from network); 27 Dec 2011 00:55:15 -0000
Received: from mta31.charter.net (HELO mta31.charter.net) (216.33.127.82)
	by server-2.tower-216.messagelabs.com with SMTP;
	27 Dec 2011 00:55:15 -0000
Received: from imp09 ([10.20.200.9]) by mta31.charter.net
	(InterMail vM.8.01.05.02 201-2260-151-103-20110920) with ESMTP
	id <20111227005514.BXBG4042.mta31.charter.net@imp09>
	for <xen-devel@lists.xensource.com>; Mon, 26 Dec 2011 19:55:14 -0500
Received: from mail.ark-net.org ([75.138.196.190])
	by imp09 with smtp.charter.net
	id E0vD1i00N46xN4z050vDk4; Mon, 26 Dec 2011 19:55:14 -0500
X-Authority-Analysis: v=1.1 cv=psWcb5N98119OaOi9bjyg15qVElTHlpKZyP+LUQnThs=
	c=1 sm=1 a=0bCt-fb661UA:10 a=aKVfsDUSyicA:10 a=VCxxn1A5iYMA:10
	a=NqYyV4q_xg0A:10 a=wPDyFdB5xvgA:10 a=IkcTkHD0fZMA:10
	a=vtmAIxR7S4RyHMe0h/1GdA==:17 a=yrMncs_yYLcB6Est2bkA:9
	a=QEXdDO2ut3YA:10 a=vtmAIxR7S4RyHMe0h/1GdA==:117
Received: from localhost (unknown [127.0.0.1])
	by mail.ark-net.org (Postfix) with ESMTP id 36BAF203B4
	for <xen-devel@lists.xensource.com>;
	Tue, 27 Dec 2011 01:06:19 +0000 (UTC)
X-Virus-Scanned: amavisd-new at ark-net.org
Received: from mail.ark-net.org ([127.0.0.1])
	by localhost (mail.ark-net.org [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id 68vaES-CxYg2 for <xen-devel@lists.xensource.com>;
	Mon, 26 Dec 2011 20:05:40 -0500 (EST)
Received: from 192.168.1.12 (unknown [192.168.1.12])
	by mail.ark-net.org (Postfix) with ESMTP id E74702033D
	for <xen-devel@lists.xensource.com>;
	Mon, 26 Dec 2011 20:05:39 -0500 (EST)
MIME-Version: 1.0
Date: Mon, 26 Dec 2011 20:01:00 -0500
From: "Michael A. Collins" <mike.a.collins@ark-net.org>
To: <xen-devel@lists.xensource.com>
Mail-Reply-To: <mike.a.collins@ark-net.org>
In-Reply-To: <tencent_0C4DB37648BB9859176328CB@qq.com>
References: <tencent_0C4DB37648BB9859176328CB@qq.com>
Message-ID: <581472472045fb578da81776fb6f1f00@192.168.1.11>
X-Sender: mike.a.collins@ark-net.org
User-Agent: Roundcube Webmail/0.6-beta
Subject: Re: [Xen-devel]
 =?utf-8?q?=5Bhelp=5D_what=27s_the_relationship_betwee?=
 =?utf-8?q?n_vif*=2E*_and_tap*=2E*_in_vm=3F?=
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: mike.a.collins@ark-net.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: base64
Content-Type: text/plain; charset="utf-8"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gMjYuMTIuMjAxMSAwNDozMCwgwqTntYLmlrxhd2FyZSB3cm90ZToKPiBIaSBldmVyeW9uZSwK
PiAgQSBwYWlyIG9mIG5ldHdvcmsgaW50ZXJmYWNlLCB2aWYgYW5kIHRhcCwgd2lsbCBjb25uZWN0
IHRoZSBicmlkZ2UKPiB3aGVuIGEgdm0gc3RhcnRzLiBXaGF0J3MgdGhlaXIgcmVsYXRpb25zaGlw
Pwo+ICB0aGFua3MgZm9yIHJlcGx5fgo+Cj4gY2hlZXJzCj4gYnJ1Y2UKCklmIEkgdW5kZXJzdGFu
ZCBjb3JyZWN0bHksIHRoZSB2aWYgaXMgYSB2aXJ0dWFsIGludGVyZmFjZSB0aGF0IHdvcmtzIAp3
aXRoIHB2IGRyaXZlcnMgaW4gZG9tVS4gIFRoZSB0YXAgaXMgYSBRZW11IGludGVyZmFjZSB0aGF0
IGlzIHVzZWQgd2l0aCAKSFZNcyB0aGF0IGRvbid0IGhhdmUgcHYgZHJpdmVycy4gIFNvLCBpZiB5
b3Ugc3RhcnQgYSBIVk0gZG9tVSwgeW91J2xsIApoYXZlIHRoZSB2aWYgdGhhdCBYZW4gY3JlYXRl
cyBhbmQgdGhlIHRhcCB0aGF0IFFlbXUgY3JlYXRlcywgaWYgcHYgCmRyaXZlcnMgYXJlIGF2YWls
YWJsZSwgdGhlbiBvbmNlIHRoZXkgYXJlIGxvYWRlZCBEb211IHVzZXMgdGhlbSBhbmQgdGhlIAp0
YXAgZ29lcyBhd2F5LCBidXQgaWYgbm90IHRoZW4gYm90aCByZW1haW4sIGJ1dCBvbmx5IHRoZSB0
YXAgaW50ZXJmYWNlIAppcyBiZWluZyB1c2VkLiAgT2J2aW91c2x5LCBpZiB5b3UgbmVlZCBtb3Jl
IGRldGFpbGVkIGV4cGxhaW5hdGlvbiwgdGhlbiAKSSdtIG9mIG5vIGZ1cnRoZXIgdXNlLjopCk1p
a2UKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1k
ZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbnNvdXJjZS5jb20KaHR0cDovL2xp
c3RzLnhlbnNvdXJjZS5jb20veGVuLWRldmVsCg==

From xen-devel-bounces@lists.xensource.com Tue Dec 27 00:56:35 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 27 Dec 2011 00:56:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RfLK7-0006dz-6G; Tue, 27 Dec 2011 00:55:23 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <mike.a.collins@ark-net.org>) id 1RfLK5-0006du-SS
	for xen-devel@lists.xensource.com; Tue, 27 Dec 2011 00:55:22 +0000
X-Env-Sender: mike.a.collins@ark-net.org
X-Msg-Ref: server-2.tower-216.messagelabs.com!1324947314!10185447!1
X-Originating-IP: [216.33.127.82]
X-SpamReason: No, hits=0.0 required=7.0 tests=SUBJECT_EXCESS_QP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4150 invoked from network); 27 Dec 2011 00:55:15 -0000
Received: from mta31.charter.net (HELO mta31.charter.net) (216.33.127.82)
	by server-2.tower-216.messagelabs.com with SMTP;
	27 Dec 2011 00:55:15 -0000
Received: from imp09 ([10.20.200.9]) by mta31.charter.net
	(InterMail vM.8.01.05.02 201-2260-151-103-20110920) with ESMTP
	id <20111227005514.BXBG4042.mta31.charter.net@imp09>
	for <xen-devel@lists.xensource.com>; Mon, 26 Dec 2011 19:55:14 -0500
Received: from mail.ark-net.org ([75.138.196.190])
	by imp09 with smtp.charter.net
	id E0vD1i00N46xN4z050vDk4; Mon, 26 Dec 2011 19:55:14 -0500
X-Authority-Analysis: v=1.1 cv=psWcb5N98119OaOi9bjyg15qVElTHlpKZyP+LUQnThs=
	c=1 sm=1 a=0bCt-fb661UA:10 a=aKVfsDUSyicA:10 a=VCxxn1A5iYMA:10
	a=NqYyV4q_xg0A:10 a=wPDyFdB5xvgA:10 a=IkcTkHD0fZMA:10
	a=vtmAIxR7S4RyHMe0h/1GdA==:17 a=yrMncs_yYLcB6Est2bkA:9
	a=QEXdDO2ut3YA:10 a=vtmAIxR7S4RyHMe0h/1GdA==:117
Received: from localhost (unknown [127.0.0.1])
	by mail.ark-net.org (Postfix) with ESMTP id 36BAF203B4
	for <xen-devel@lists.xensource.com>;
	Tue, 27 Dec 2011 01:06:19 +0000 (UTC)
X-Virus-Scanned: amavisd-new at ark-net.org
Received: from mail.ark-net.org ([127.0.0.1])
	by localhost (mail.ark-net.org [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id 68vaES-CxYg2 for <xen-devel@lists.xensource.com>;
	Mon, 26 Dec 2011 20:05:40 -0500 (EST)
Received: from 192.168.1.12 (unknown [192.168.1.12])
	by mail.ark-net.org (Postfix) with ESMTP id E74702033D
	for <xen-devel@lists.xensource.com>;
	Mon, 26 Dec 2011 20:05:39 -0500 (EST)
MIME-Version: 1.0
Date: Mon, 26 Dec 2011 20:01:00 -0500
From: "Michael A. Collins" <mike.a.collins@ark-net.org>
To: <xen-devel@lists.xensource.com>
Mail-Reply-To: <mike.a.collins@ark-net.org>
In-Reply-To: <tencent_0C4DB37648BB9859176328CB@qq.com>
References: <tencent_0C4DB37648BB9859176328CB@qq.com>
Message-ID: <581472472045fb578da81776fb6f1f00@192.168.1.11>
X-Sender: mike.a.collins@ark-net.org
User-Agent: Roundcube Webmail/0.6-beta
Subject: Re: [Xen-devel]
 =?utf-8?q?=5Bhelp=5D_what=27s_the_relationship_betwee?=
 =?utf-8?q?n_vif*=2E*_and_tap*=2E*_in_vm=3F?=
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: mike.a.collins@ark-net.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: base64
Content-Type: text/plain; charset="utf-8"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gMjYuMTIuMjAxMSAwNDozMCwgwqTntYLmlrxhd2FyZSB3cm90ZToKPiBIaSBldmVyeW9uZSwK
PiAgQSBwYWlyIG9mIG5ldHdvcmsgaW50ZXJmYWNlLCB2aWYgYW5kIHRhcCwgd2lsbCBjb25uZWN0
IHRoZSBicmlkZ2UKPiB3aGVuIGEgdm0gc3RhcnRzLiBXaGF0J3MgdGhlaXIgcmVsYXRpb25zaGlw
Pwo+ICB0aGFua3MgZm9yIHJlcGx5fgo+Cj4gY2hlZXJzCj4gYnJ1Y2UKCklmIEkgdW5kZXJzdGFu
ZCBjb3JyZWN0bHksIHRoZSB2aWYgaXMgYSB2aXJ0dWFsIGludGVyZmFjZSB0aGF0IHdvcmtzIAp3
aXRoIHB2IGRyaXZlcnMgaW4gZG9tVS4gIFRoZSB0YXAgaXMgYSBRZW11IGludGVyZmFjZSB0aGF0
IGlzIHVzZWQgd2l0aCAKSFZNcyB0aGF0IGRvbid0IGhhdmUgcHYgZHJpdmVycy4gIFNvLCBpZiB5
b3Ugc3RhcnQgYSBIVk0gZG9tVSwgeW91J2xsIApoYXZlIHRoZSB2aWYgdGhhdCBYZW4gY3JlYXRl
cyBhbmQgdGhlIHRhcCB0aGF0IFFlbXUgY3JlYXRlcywgaWYgcHYgCmRyaXZlcnMgYXJlIGF2YWls
YWJsZSwgdGhlbiBvbmNlIHRoZXkgYXJlIGxvYWRlZCBEb211IHVzZXMgdGhlbSBhbmQgdGhlIAp0
YXAgZ29lcyBhd2F5LCBidXQgaWYgbm90IHRoZW4gYm90aCByZW1haW4sIGJ1dCBvbmx5IHRoZSB0
YXAgaW50ZXJmYWNlIAppcyBiZWluZyB1c2VkLiAgT2J2aW91c2x5LCBpZiB5b3UgbmVlZCBtb3Jl
IGRldGFpbGVkIGV4cGxhaW5hdGlvbiwgdGhlbiAKSSdtIG9mIG5vIGZ1cnRoZXIgdXNlLjopCk1p
a2UKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1k
ZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbnNvdXJjZS5jb20KaHR0cDovL2xp
c3RzLnhlbnNvdXJjZS5jb20veGVuLWRldmVsCg==

From xen-devel-bounces@lists.xensource.com Tue Dec 27 05:07:07 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 27 Dec 2011 05:07:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RfPEI-0003Gb-4U; Tue, 27 Dec 2011 05:05:38 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RfPEG-0003GW-J8
	for xen-devel@lists.xensource.com; Tue, 27 Dec 2011 05:05:36 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1324962329!8713695!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODUwMw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16197 invoked from network); 27 Dec 2011 05:05:29 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Dec 2011 05:05:29 -0000
X-IronPort-AV: E=Sophos;i="4.71,414,1320624000"; 
   d="scan'208";a="9691821"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Dec 2011 05:05:28 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 27 Dec 2011 05:05:28 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RfPE8-000637-Al;
	Tue, 27 Dec 2011 05:05:28 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RfPE8-0004b9-0D;
	Tue, 27 Dec 2011 05:05:28 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10610-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 27 Dec 2011 05:05:28 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10610: tolerable FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10610 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10610/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-i386-pv           16 guest-start.2               fail pass in 10609
 test-amd64-amd64-xl-sedf-pin 13 guest-localmigrate.2        fail pass in 10609

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-pv          16 guest-start.2                fail   like 10603
 test-amd64-amd64-xl-sedf-pin 14 guest-localmigrate/x10 fail in 10609 like 10607
 test-amd64-amd64-xl          16 guest-start.2         fail in 10609 like 10607
 test-amd64-amd64-xl-sedf    14 guest-localmigrate/x10 fail in 10609 like 10607

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass

version targeted for testing:
 xen                  2863b2f43a3b
baseline version:
 xen                  2863b2f43a3b

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          fail    
 test-amd64-i386-pv                                           fail    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 27 05:07:07 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 27 Dec 2011 05:07:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RfPEI-0003Gb-4U; Tue, 27 Dec 2011 05:05:38 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RfPEG-0003GW-J8
	for xen-devel@lists.xensource.com; Tue, 27 Dec 2011 05:05:36 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1324962329!8713695!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODUwMw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16197 invoked from network); 27 Dec 2011 05:05:29 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Dec 2011 05:05:29 -0000
X-IronPort-AV: E=Sophos;i="4.71,414,1320624000"; 
   d="scan'208";a="9691821"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Dec 2011 05:05:28 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 27 Dec 2011 05:05:28 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RfPE8-000637-Al;
	Tue, 27 Dec 2011 05:05:28 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RfPE8-0004b9-0D;
	Tue, 27 Dec 2011 05:05:28 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10610-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 27 Dec 2011 05:05:28 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10610: tolerable FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10610 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10610/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-i386-pv           16 guest-start.2               fail pass in 10609
 test-amd64-amd64-xl-sedf-pin 13 guest-localmigrate.2        fail pass in 10609

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-pv          16 guest-start.2                fail   like 10603
 test-amd64-amd64-xl-sedf-pin 14 guest-localmigrate/x10 fail in 10609 like 10607
 test-amd64-amd64-xl          16 guest-start.2         fail in 10609 like 10607
 test-amd64-amd64-xl-sedf    14 guest-localmigrate/x10 fail in 10609 like 10607

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass

version targeted for testing:
 xen                  2863b2f43a3b
baseline version:
 xen                  2863b2f43a3b

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          fail    
 test-amd64-i386-pv                                           fail    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 27 06:35:44 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 27 Dec 2011 06:35:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RfQbv-0003hn-9c; Tue, 27 Dec 2011 06:34:07 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <250716708@qq.com>) id 1RfQbt-0003hi-C2
	for xen-devel@lists.xensource.com; Tue, 27 Dec 2011 06:34:05 +0000
X-Env-Sender: 250716708@qq.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1324967638!9273229!1
X-Originating-IP: [64.71.138.44]
X-SpamReason: No, hits=2.9 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA2NC43MS4xMzguNDQgPT4gMjAyNTc0\n,sa_preprocessor: 
	QmFkIElQOiA2NC43MS4xMzguNDQgPT4gMjAyNTc0\n,FROM_ALL_NUMS,
	FROM_STARTS_WITH_NUMS,HTML_20_30,HTML_MESSAGE,MIME_BASE64_TEXT,
	MIME_BOUND_NEXTPART,received_headers: No Received headers
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6445 invoked from network); 27 Dec 2011 06:33:58 -0000
Received: from smtpbg55.qq.com (HELO smtpbg55.qq.com) (64.71.138.44)
	by server-11.tower-21.messagelabs.com with SMTP;
	27 Dec 2011 06:33:58 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qq.com; s=s0907;
	t=1324967621; bh=R/H6wF5mJBQlMBFfArdcNOFoDnHCKhgqUFkYo6uszo0=;
	h=X-QQ-SSF:X-HAS-ATTACH:X-QQ-BUSINESS-ORIGIN:X-Originating-IP:
	X-QQ-STYLE:X-QQ-mid:From:To:Cc:Subject:Mime-Version:Content-Type:
	Content-Transfer-Encoding:Date:X-Priority:Message-ID:X-QQ-MIME:
	X-Mailer:X-QQ-Mailer;
	b=KykFAjg7dY6yyvcKSkttwRybV5czibsmUKPuu1BH9enABzM8Nj7GSgtY+VEzWd28H
	AQxGsB30B4oIJ4KdJZTOkxDKNf1vOMr82K6FBuDdBxpOHo93P7JFiPaMg11aqDK
X-QQ-SSF: 00000000000000F0000000000000000
X-HAS-ATTACH: no
X-QQ-BUSINESS-ORIGIN: 2
X-Originating-IP: 118.192.67.234
X-QQ-STYLE: 
X-QQ-mid: webmail501t1324967619t305324
From: "=?gbk?B?oei9S+y2YXdhcmU=?=" <250716708@qq.com>
To: "=?gbk?B?bWlrZS5hLmNvbGxpbnM=?=" <mike.a.collins@ark-net.org>
Mime-Version: 1.0
Date: Tue, 27 Dec 2011 14:33:39 +0800
X-Priority: 3
Message-ID: <tencent_63380F1C1F8B32955AD2D0A8@qq.com>
X-QQ-MIME: TCMime 1.0 by Tencent
X-Mailer: QQMail 2.x
X-QQ-Mailer: QQMail 2.x
Cc: =?gbk?B?eGVuLWRldmVs?= <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [help] what's the relationship between vif*.*
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0527016689741218537=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a multi-part message in MIME format.

--===============0527016689741218537==
Content-Type: multipart/alternative;
	boundary="----=_NextPart_4EF966C3_08117420_4D6D8F5F"
Content-Transfer-Encoding: 8Bit

This is a multi-part message in MIME format.

------=_NextPart_4EF966C3_08117420_4D6D8F5F
Content-Type: text/plain;
	charset="gbk"
Content-Transfer-Encoding: base64

dGhhbmtzLCB5b3UgbWVhbiB0aGF0IG9ubHkgdGhlIHRhcCBkZXZpY2UgIGlzIGVub3VnaCBm
b3IgSFZNIGRvbWFpblUgYW5kIHRoZSB2aWYgaXMgc3BlY2lhbGx5IGZvciBwYXJhdmlydHVs
aXphdGlvbi4gDQogIA0KIE9uIDI2LjEyLjIwMTEgMDQ6MzAsID8/P2F3YXJlIHdyb3RlOg0K
PiA+SGkgZXZlcnlvbmUsDQo+PiAgQSBwYWlyIG9mIG5ldHdvcmsgaW50ZXJmYWNlLCB2aWYg
YW5kIHRhcCwgd2lsbCBjb25uZWN0IHRoZSBicmlkZ2UNCj4gPndoZW4gYSB2bSBzdGFydHMu
IFdoYXQncyB0aGVpciByZWxhdGlvbnNoaXA/DQo+ID4gdGhhbmtzIGZvciByZXBseX4NCj4+
DQo+PiBjaGVlcnMNCj4+IGJydWNlDQoNCj5JZiBJIHVuZGVyc3RhbmQgY29ycmVjdGx5LCB0
aGUgdmlmIGlzIGEgdmlydHVhbCBpbnRlcmZhY2UgdGhhdCB3b3JrcyANCj53aXRoIHB2IGRy
aXZlcnMgaW4gZG9tVS4gIFRoZSB0YXAgaXMgYSBRZW11IGludGVyZmFjZSB0aGF0IGlzIHVz
ZWQgd2l0aCANCj5IVk1zIHRoYXQgZG9uJ3QgaGF2ZSBwdiBkcml2ZXJzLiAgU28sIGlmIHlv
dSBzdGFydCBhIEhWTSBkb21VLCB5b3UnbGwgDQo+aGF2ZSB0aGUgdmlmIHRoYXQgWGVuIGNy
ZWF0ZXMgYW5kIHRoZSB0YXAgdGhhdCBRZW11IGNyZWF0ZXMsIGlmIHB2IA0KPmRyaXZlcnMg
YXJlIGF2YWlsYWJsZSwgdGhlbiBvbmNlIHRoZXkgYXJlIGxvYWRlZCBEb211IHVzZXMgdGhl
bSBhbmQgdGhlIA0KPnRhcCBnb2VzIGF3YXksIGJ1dCBpZiBub3QgdGhlbiBib3RoIHJlbWFp
biwgYnV0IG9ubHkgdGhlIHRhcCBpbnRlcmZhY2UgDQo+aXMgYmVpbmcgdXNlZC4gIE9idmlv
dXNseSwgaWYgeW91IG5lZWQgbW9yZSBkZXRhaWxlZCBleHBsYWluYXRpb24sIHRoZW4gDQo+
SSdtIG9mIG5vIGZ1cnRoZXIgdXNlLjopDQo+TWlrZQ==

------=_NextPart_4EF966C3_08117420_4D6D8F5F
Content-Type: text/html;
	charset="gbk"
Content-Transfer-Encoding: base64

PERJVj50aGFua3MsIHlvdSBtZWFuIHRoYXQgb25seSZuYnNwO3RoZSB0YXAgZGV2aWNlICZu
YnNwO2lzIGVub3VnaCBmb3IgSFZNIGRvbWFpblUgYW5kIHRoZSB2aWYgaXMgc3BlY2lhbGx5
IGZvciBwYXJhdmlydHVsaXphdGlvbi4mbmJzcDs8L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+
DQo8RElWPk9uIDI2LjEyLjIwMTEgMDQ6MzAsID8/P2F3YXJlIHdyb3RlOjxCUj4mZ3Q7ICZn
dDtIaSBldmVyeW9uZSw8QlI+Jmd0OyZndDsmbmJzcDsgQSBwYWlyIG9mIG5ldHdvcmsgaW50
ZXJmYWNlLCB2aWYgYW5kIHRhcCwgd2lsbCBjb25uZWN0IHRoZSBicmlkZ2U8QlI+Jmd0OyAm
Z3Q7d2hlbiBhIHZtIHN0YXJ0cy4gV2hhdCdzIHRoZWlyIHJlbGF0aW9uc2hpcD88QlI+Jmd0
OyZuYnNwOyZndDsgdGhhbmtzIGZvciByZXBseX48QlI+Jmd0OyZndDs8QlI+Jmd0OyZndDsg
Y2hlZXJzPEJSPiZndDsmZ3Q7IGJydWNlPEJSPjxCUj4mZ3Q7SWYgSSB1bmRlcnN0YW5kIGNv
cnJlY3RseSwgdGhlIHZpZiBpcyBhIHZpcnR1YWwgaW50ZXJmYWNlIHRoYXQgd29ya3MgPEJS
PiZndDt3aXRoIHB2IGRyaXZlcnMgaW4gZG9tVS4mbmJzcDsgVGhlIHRhcCBpcyBhIFFlbXUg
aW50ZXJmYWNlIHRoYXQgaXMgdXNlZCB3aXRoIDxCUj4mZ3Q7SFZNcyB0aGF0IGRvbid0IGhh
dmUgcHYgZHJpdmVycy4mbmJzcDsgU28sIGlmIHlvdSBzdGFydCBhIEhWTSBkb21VLCB5b3Un
bGwgPEJSPiZndDtoYXZlIHRoZSB2aWYgdGhhdCBYZW4gY3JlYXRlcyBhbmQgdGhlIHRhcCB0
aGF0IFFlbXUgY3JlYXRlcywgaWYgcHYgPEJSPiZndDtkcml2ZXJzIGFyZSBhdmFpbGFibGUs
IHRoZW4gb25jZSB0aGV5IGFyZSBsb2FkZWQgRG9tdSB1c2VzIHRoZW0gYW5kIHRoZSA8QlI+
Jmd0O3RhcCBnb2VzIGF3YXksIGJ1dCBpZiBub3QgdGhlbiBib3RoIHJlbWFpbiwgYnV0IG9u
bHkgdGhlIHRhcCBpbnRlcmZhY2UgPEJSPiZndDtpcyBiZWluZyB1c2VkLiZuYnNwOyBPYnZp
b3VzbHksIGlmIHlvdSBuZWVkIG1vcmUgZGV0YWlsZWQgZXhwbGFpbmF0aW9uLCB0aGVuIDxC
Uj4mZ3Q7SSdtIG9mIG5vIGZ1cnRoZXIgdXNlLjopPEJSPiZndDtNaWtlPEJSPjxCUj48L0RJ
Vj4NCjxESVY+Jm5ic3A7PC9ESVY+

------=_NextPart_4EF966C3_08117420_4D6D8F5F--



--===============0527016689741218537==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============0527016689741218537==--



From xen-devel-bounces@lists.xensource.com Tue Dec 27 06:35:44 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 27 Dec 2011 06:35:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RfQbv-0003hn-9c; Tue, 27 Dec 2011 06:34:07 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <250716708@qq.com>) id 1RfQbt-0003hi-C2
	for xen-devel@lists.xensource.com; Tue, 27 Dec 2011 06:34:05 +0000
X-Env-Sender: 250716708@qq.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1324967638!9273229!1
X-Originating-IP: [64.71.138.44]
X-SpamReason: No, hits=2.9 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA2NC43MS4xMzguNDQgPT4gMjAyNTc0\n,sa_preprocessor: 
	QmFkIElQOiA2NC43MS4xMzguNDQgPT4gMjAyNTc0\n,FROM_ALL_NUMS,
	FROM_STARTS_WITH_NUMS,HTML_20_30,HTML_MESSAGE,MIME_BASE64_TEXT,
	MIME_BOUND_NEXTPART,received_headers: No Received headers
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6445 invoked from network); 27 Dec 2011 06:33:58 -0000
Received: from smtpbg55.qq.com (HELO smtpbg55.qq.com) (64.71.138.44)
	by server-11.tower-21.messagelabs.com with SMTP;
	27 Dec 2011 06:33:58 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qq.com; s=s0907;
	t=1324967621; bh=R/H6wF5mJBQlMBFfArdcNOFoDnHCKhgqUFkYo6uszo0=;
	h=X-QQ-SSF:X-HAS-ATTACH:X-QQ-BUSINESS-ORIGIN:X-Originating-IP:
	X-QQ-STYLE:X-QQ-mid:From:To:Cc:Subject:Mime-Version:Content-Type:
	Content-Transfer-Encoding:Date:X-Priority:Message-ID:X-QQ-MIME:
	X-Mailer:X-QQ-Mailer;
	b=KykFAjg7dY6yyvcKSkttwRybV5czibsmUKPuu1BH9enABzM8Nj7GSgtY+VEzWd28H
	AQxGsB30B4oIJ4KdJZTOkxDKNf1vOMr82K6FBuDdBxpOHo93P7JFiPaMg11aqDK
X-QQ-SSF: 00000000000000F0000000000000000
X-HAS-ATTACH: no
X-QQ-BUSINESS-ORIGIN: 2
X-Originating-IP: 118.192.67.234
X-QQ-STYLE: 
X-QQ-mid: webmail501t1324967619t305324
From: "=?gbk?B?oei9S+y2YXdhcmU=?=" <250716708@qq.com>
To: "=?gbk?B?bWlrZS5hLmNvbGxpbnM=?=" <mike.a.collins@ark-net.org>
Mime-Version: 1.0
Date: Tue, 27 Dec 2011 14:33:39 +0800
X-Priority: 3
Message-ID: <tencent_63380F1C1F8B32955AD2D0A8@qq.com>
X-QQ-MIME: TCMime 1.0 by Tencent
X-Mailer: QQMail 2.x
X-QQ-Mailer: QQMail 2.x
Cc: =?gbk?B?eGVuLWRldmVs?= <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [help] what's the relationship between vif*.*
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0527016689741218537=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a multi-part message in MIME format.

--===============0527016689741218537==
Content-Type: multipart/alternative;
	boundary="----=_NextPart_4EF966C3_08117420_4D6D8F5F"
Content-Transfer-Encoding: 8Bit

This is a multi-part message in MIME format.

------=_NextPart_4EF966C3_08117420_4D6D8F5F
Content-Type: text/plain;
	charset="gbk"
Content-Transfer-Encoding: base64

dGhhbmtzLCB5b3UgbWVhbiB0aGF0IG9ubHkgdGhlIHRhcCBkZXZpY2UgIGlzIGVub3VnaCBm
b3IgSFZNIGRvbWFpblUgYW5kIHRoZSB2aWYgaXMgc3BlY2lhbGx5IGZvciBwYXJhdmlydHVs
aXphdGlvbi4gDQogIA0KIE9uIDI2LjEyLjIwMTEgMDQ6MzAsID8/P2F3YXJlIHdyb3RlOg0K
PiA+SGkgZXZlcnlvbmUsDQo+PiAgQSBwYWlyIG9mIG5ldHdvcmsgaW50ZXJmYWNlLCB2aWYg
YW5kIHRhcCwgd2lsbCBjb25uZWN0IHRoZSBicmlkZ2UNCj4gPndoZW4gYSB2bSBzdGFydHMu
IFdoYXQncyB0aGVpciByZWxhdGlvbnNoaXA/DQo+ID4gdGhhbmtzIGZvciByZXBseX4NCj4+
DQo+PiBjaGVlcnMNCj4+IGJydWNlDQoNCj5JZiBJIHVuZGVyc3RhbmQgY29ycmVjdGx5LCB0
aGUgdmlmIGlzIGEgdmlydHVhbCBpbnRlcmZhY2UgdGhhdCB3b3JrcyANCj53aXRoIHB2IGRy
aXZlcnMgaW4gZG9tVS4gIFRoZSB0YXAgaXMgYSBRZW11IGludGVyZmFjZSB0aGF0IGlzIHVz
ZWQgd2l0aCANCj5IVk1zIHRoYXQgZG9uJ3QgaGF2ZSBwdiBkcml2ZXJzLiAgU28sIGlmIHlv
dSBzdGFydCBhIEhWTSBkb21VLCB5b3UnbGwgDQo+aGF2ZSB0aGUgdmlmIHRoYXQgWGVuIGNy
ZWF0ZXMgYW5kIHRoZSB0YXAgdGhhdCBRZW11IGNyZWF0ZXMsIGlmIHB2IA0KPmRyaXZlcnMg
YXJlIGF2YWlsYWJsZSwgdGhlbiBvbmNlIHRoZXkgYXJlIGxvYWRlZCBEb211IHVzZXMgdGhl
bSBhbmQgdGhlIA0KPnRhcCBnb2VzIGF3YXksIGJ1dCBpZiBub3QgdGhlbiBib3RoIHJlbWFp
biwgYnV0IG9ubHkgdGhlIHRhcCBpbnRlcmZhY2UgDQo+aXMgYmVpbmcgdXNlZC4gIE9idmlv
dXNseSwgaWYgeW91IG5lZWQgbW9yZSBkZXRhaWxlZCBleHBsYWluYXRpb24sIHRoZW4gDQo+
SSdtIG9mIG5vIGZ1cnRoZXIgdXNlLjopDQo+TWlrZQ==

------=_NextPart_4EF966C3_08117420_4D6D8F5F
Content-Type: text/html;
	charset="gbk"
Content-Transfer-Encoding: base64

PERJVj50aGFua3MsIHlvdSBtZWFuIHRoYXQgb25seSZuYnNwO3RoZSB0YXAgZGV2aWNlICZu
YnNwO2lzIGVub3VnaCBmb3IgSFZNIGRvbWFpblUgYW5kIHRoZSB2aWYgaXMgc3BlY2lhbGx5
IGZvciBwYXJhdmlydHVsaXphdGlvbi4mbmJzcDs8L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+
DQo8RElWPk9uIDI2LjEyLjIwMTEgMDQ6MzAsID8/P2F3YXJlIHdyb3RlOjxCUj4mZ3Q7ICZn
dDtIaSBldmVyeW9uZSw8QlI+Jmd0OyZndDsmbmJzcDsgQSBwYWlyIG9mIG5ldHdvcmsgaW50
ZXJmYWNlLCB2aWYgYW5kIHRhcCwgd2lsbCBjb25uZWN0IHRoZSBicmlkZ2U8QlI+Jmd0OyAm
Z3Q7d2hlbiBhIHZtIHN0YXJ0cy4gV2hhdCdzIHRoZWlyIHJlbGF0aW9uc2hpcD88QlI+Jmd0
OyZuYnNwOyZndDsgdGhhbmtzIGZvciByZXBseX48QlI+Jmd0OyZndDs8QlI+Jmd0OyZndDsg
Y2hlZXJzPEJSPiZndDsmZ3Q7IGJydWNlPEJSPjxCUj4mZ3Q7SWYgSSB1bmRlcnN0YW5kIGNv
cnJlY3RseSwgdGhlIHZpZiBpcyBhIHZpcnR1YWwgaW50ZXJmYWNlIHRoYXQgd29ya3MgPEJS
PiZndDt3aXRoIHB2IGRyaXZlcnMgaW4gZG9tVS4mbmJzcDsgVGhlIHRhcCBpcyBhIFFlbXUg
aW50ZXJmYWNlIHRoYXQgaXMgdXNlZCB3aXRoIDxCUj4mZ3Q7SFZNcyB0aGF0IGRvbid0IGhh
dmUgcHYgZHJpdmVycy4mbmJzcDsgU28sIGlmIHlvdSBzdGFydCBhIEhWTSBkb21VLCB5b3Un
bGwgPEJSPiZndDtoYXZlIHRoZSB2aWYgdGhhdCBYZW4gY3JlYXRlcyBhbmQgdGhlIHRhcCB0
aGF0IFFlbXUgY3JlYXRlcywgaWYgcHYgPEJSPiZndDtkcml2ZXJzIGFyZSBhdmFpbGFibGUs
IHRoZW4gb25jZSB0aGV5IGFyZSBsb2FkZWQgRG9tdSB1c2VzIHRoZW0gYW5kIHRoZSA8QlI+
Jmd0O3RhcCBnb2VzIGF3YXksIGJ1dCBpZiBub3QgdGhlbiBib3RoIHJlbWFpbiwgYnV0IG9u
bHkgdGhlIHRhcCBpbnRlcmZhY2UgPEJSPiZndDtpcyBiZWluZyB1c2VkLiZuYnNwOyBPYnZp
b3VzbHksIGlmIHlvdSBuZWVkIG1vcmUgZGV0YWlsZWQgZXhwbGFpbmF0aW9uLCB0aGVuIDxC
Uj4mZ3Q7SSdtIG9mIG5vIGZ1cnRoZXIgdXNlLjopPEJSPiZndDtNaWtlPEJSPjxCUj48L0RJ
Vj4NCjxESVY+Jm5ic3A7PC9ESVY+

------=_NextPart_4EF966C3_08117420_4D6D8F5F--



--===============0527016689741218537==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============0527016689741218537==--



From xen-devel-bounces@lists.xensource.com Tue Dec 27 06:44:45 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 27 Dec 2011 06:44:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RfQkz-0003qk-Av; Tue, 27 Dec 2011 06:43:29 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fajar@fajar.net>) id 1RfQkx-0003qb-Sb
	for xen-devel@lists.xensource.com; Tue, 27 Dec 2011 06:43:28 +0000
X-Env-Sender: fajar@fajar.net
X-Msg-Ref: server-5.tower-182.messagelabs.com!1324968200!8744515!1
X-Originating-IP: [209.85.160.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14552 invoked from network); 27 Dec 2011 06:43:21 -0000
Received: from mail-pw0-f43.google.com (HELO mail-pw0-f43.google.com)
	(209.85.160.43)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Dec 2011 06:43:21 -0000
Received: by pbbb11 with SMTP id b11so41302185pbb.30
	for <xen-devel@lists.xensource.com>;
	Mon, 26 Dec 2011 22:43:19 -0800 (PST)
MIME-Version: 1.0
Received: by 10.68.212.200 with SMTP id nm8mr62952448pbc.28.1324968199709;
	Mon, 26 Dec 2011 22:43:19 -0800 (PST)
Received: by 10.143.5.16 with HTTP; Mon, 26 Dec 2011 22:43:19 -0800 (PST)
In-Reply-To: <tencent_63380F1C1F8B32955AD2D0A8@qq.com>
References: <tencent_63380F1C1F8B32955AD2D0A8@qq.com>
Date: Tue, 27 Dec 2011 13:43:19 +0700
Message-ID: <CAG1y0sdX3fMix_nkoVt-_VQTFRiiDO4pf31m40LjtPCUTZ1Hzg@mail.gmail.com>
From: "Fajar A. Nugraha" <list@fajar.net>
To: =?UTF-8?B?wqTntYLmlrxhd2FyZQ==?= <250716708@qq.com>
Cc: xen-devel <xen-devel@lists.xensource.com>,
	"mike.a.collins" <mike.a.collins@ark-net.org>
Subject: Re: [Xen-devel] [help] what's the relationship between vif*.*
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

MjAxMS8xMi8yNyDCpOe1guaWvGF3YXJlIDwyNTA3MTY3MDhAcXEuY29tPjoKPiB0aGFua3MsIHlv
dSBtZWFuIHRoYXQgb25secKgdGhlIHRhcCBkZXZpY2UgwqBpcyBlbm91Z2ggZm9yIEhWTSBkb21h
aW5VIGFuZCB0aGUKClllcywgc29ydCBvZi4KCj4gdmlmIGlzIHNwZWNpYWxseSBmb3IgcGFyYXZp
cnR1bGl6YXRpb24uCgpZZXMsIGFzIGluIFBWIGRyaXZlcnMsIG5vdCBpbiBQViB2cyBIVk0gZG9t
VS4KCkFzIE1pa2Ugc2FpZCwgSFZNIGRvbVUgY2FuIGFsc28gdXNlIFBWIGRyaXZlcnMuIEV4YW1w
bGU6IG5ld2VyIGxpbnV4CmRpc3Ryb3MgKHdoaWNoIHVzZXMgeGVuLW5ldGZyb250IG1vZHVsZSks
IG9yIHdpbmRvd3Mgd2l0aCBQViBkcml2ZXJzCihlLmcuIHdpdGggR1BMUFYpLiBJbiB0aGlzIGNh
c2UgSFZNIGRvbVUgYWxzbyB1c2VzIHZpZiwgYW5kIHRoZSB0YXAKZGV2aWNlIHdpbGwgYmUgdW51
c2VkIChhbmQgaW4gc29tZSBjYXNlcywgcmVtb3ZlZCkuCgotLSAKRmFqYXIKCl9fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxp
c3QKWGVuLWRldmVsQGxpc3RzLnhlbnNvdXJjZS5jb20KaHR0cDovL2xpc3RzLnhlbnNvdXJjZS5j
b20veGVuLWRldmVsCg==

From xen-devel-bounces@lists.xensource.com Tue Dec 27 06:44:45 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 27 Dec 2011 06:44:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RfQkz-0003qk-Av; Tue, 27 Dec 2011 06:43:29 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fajar@fajar.net>) id 1RfQkx-0003qb-Sb
	for xen-devel@lists.xensource.com; Tue, 27 Dec 2011 06:43:28 +0000
X-Env-Sender: fajar@fajar.net
X-Msg-Ref: server-5.tower-182.messagelabs.com!1324968200!8744515!1
X-Originating-IP: [209.85.160.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14552 invoked from network); 27 Dec 2011 06:43:21 -0000
Received: from mail-pw0-f43.google.com (HELO mail-pw0-f43.google.com)
	(209.85.160.43)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Dec 2011 06:43:21 -0000
Received: by pbbb11 with SMTP id b11so41302185pbb.30
	for <xen-devel@lists.xensource.com>;
	Mon, 26 Dec 2011 22:43:19 -0800 (PST)
MIME-Version: 1.0
Received: by 10.68.212.200 with SMTP id nm8mr62952448pbc.28.1324968199709;
	Mon, 26 Dec 2011 22:43:19 -0800 (PST)
Received: by 10.143.5.16 with HTTP; Mon, 26 Dec 2011 22:43:19 -0800 (PST)
In-Reply-To: <tencent_63380F1C1F8B32955AD2D0A8@qq.com>
References: <tencent_63380F1C1F8B32955AD2D0A8@qq.com>
Date: Tue, 27 Dec 2011 13:43:19 +0700
Message-ID: <CAG1y0sdX3fMix_nkoVt-_VQTFRiiDO4pf31m40LjtPCUTZ1Hzg@mail.gmail.com>
From: "Fajar A. Nugraha" <list@fajar.net>
To: =?UTF-8?B?wqTntYLmlrxhd2FyZQ==?= <250716708@qq.com>
Cc: xen-devel <xen-devel@lists.xensource.com>,
	"mike.a.collins" <mike.a.collins@ark-net.org>
Subject: Re: [Xen-devel] [help] what's the relationship between vif*.*
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

MjAxMS8xMi8yNyDCpOe1guaWvGF3YXJlIDwyNTA3MTY3MDhAcXEuY29tPjoKPiB0aGFua3MsIHlv
dSBtZWFuIHRoYXQgb25secKgdGhlIHRhcCBkZXZpY2UgwqBpcyBlbm91Z2ggZm9yIEhWTSBkb21h
aW5VIGFuZCB0aGUKClllcywgc29ydCBvZi4KCj4gdmlmIGlzIHNwZWNpYWxseSBmb3IgcGFyYXZp
cnR1bGl6YXRpb24uCgpZZXMsIGFzIGluIFBWIGRyaXZlcnMsIG5vdCBpbiBQViB2cyBIVk0gZG9t
VS4KCkFzIE1pa2Ugc2FpZCwgSFZNIGRvbVUgY2FuIGFsc28gdXNlIFBWIGRyaXZlcnMuIEV4YW1w
bGU6IG5ld2VyIGxpbnV4CmRpc3Ryb3MgKHdoaWNoIHVzZXMgeGVuLW5ldGZyb250IG1vZHVsZSks
IG9yIHdpbmRvd3Mgd2l0aCBQViBkcml2ZXJzCihlLmcuIHdpdGggR1BMUFYpLiBJbiB0aGlzIGNh
c2UgSFZNIGRvbVUgYWxzbyB1c2VzIHZpZiwgYW5kIHRoZSB0YXAKZGV2aWNlIHdpbGwgYmUgdW51
c2VkIChhbmQgaW4gc29tZSBjYXNlcywgcmVtb3ZlZCkuCgotLSAKRmFqYXIKCl9fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxp
c3QKWGVuLWRldmVsQGxpc3RzLnhlbnNvdXJjZS5jb20KaHR0cDovL2xpc3RzLnhlbnNvdXJjZS5j
b20veGVuLWRldmVsCg==

From xen-devel-bounces@lists.xensource.com Tue Dec 27 06:49:29 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 27 Dec 2011 06:49:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RfQpX-0003zA-1c; Tue, 27 Dec 2011 06:48:11 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <kevin.tian@intel.com>) id 1RfQpU-0003z1-Qn
	for xen-devel@lists.xensource.com; Tue, 27 Dec 2011 06:48:09 +0000
X-Env-Sender: kevin.tian@intel.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1324968440!50429132!1
X-Originating-IP: [143.182.124.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjE2MTk5\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1310 invoked from network); 27 Dec 2011 06:47:20 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-3.tower-27.messagelabs.com with SMTP;
	27 Dec 2011 06:47:20 -0000
Received: from azsmga002.ch.intel.com ([10.2.17.35])
	by azsmga101.ch.intel.com with ESMTP; 26 Dec 2011 22:48:06 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="50880029"
Received: from pgsmsx603.gar.corp.intel.com ([10.221.43.87])
	by AZSMGA002.ch.intel.com with ESMTP; 26 Dec 2011 22:48:05 -0800
Received: from pgsmsx103.gar.corp.intel.com (10.221.44.82) by
	pgsmsx603.gar.corp.intel.com (10.221.43.87) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Tue, 27 Dec 2011 14:47:47 +0800
Received: from shsmsx101.ccr.corp.intel.com (10.239.4.153) by
	PGSMSX103.gar.corp.intel.com (10.221.44.82) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Tue, 27 Dec 2011 14:47:46 +0800
Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.199]) by
	SHSMSX101.ccr.corp.intel.com ([169.254.1.38]) with mapi id
	14.01.0355.002; Tue, 27 Dec 2011 14:47:44 +0800
From: "Tian, Kevin" <kevin.tian@intel.com>
To: "'Konrad Rzeszutek Wilk (konrad.wilk@oracle.com)'"
	<konrad.wilk@oracle.com>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>
Thread-Topic: question about i915 driver in dom0
Thread-Index: AczEYxGiaxw3o8ecRW2obuwyqnfvvw==
Date: Tue, 27 Dec 2011 06:47:44 +0000
Message-ID: <AADFC41AFE54684AB9EE6CBC0274A5D10158AE@SHSMSX102.ccr.corp.intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Subject: [Xen-devel] question about i915 driver in dom0
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi, Konrad

wiki page (http://wiki.xensource.com/xenwiki/XenPVOPSDRM.html#head-4da1a90049716207b9c672fd78187b0c77767be0)
says that "i915_hangcheck_eplased" error observed with i915 driver. 

Do you have a latest update on this issue? Is it still the outstanding issue, or fixed in
recent kernels?

I'm using Linux 3.2-rc4, with same error observed when trying to launch glxgear. So
want to understand whether it's due to my kernel version, or config option... :-)

Thanks
Kevin

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 27 06:49:29 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 27 Dec 2011 06:49:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RfQpX-0003zA-1c; Tue, 27 Dec 2011 06:48:11 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <kevin.tian@intel.com>) id 1RfQpU-0003z1-Qn
	for xen-devel@lists.xensource.com; Tue, 27 Dec 2011 06:48:09 +0000
X-Env-Sender: kevin.tian@intel.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1324968440!50429132!1
X-Originating-IP: [143.182.124.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjE2MTk5\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1310 invoked from network); 27 Dec 2011 06:47:20 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-3.tower-27.messagelabs.com with SMTP;
	27 Dec 2011 06:47:20 -0000
Received: from azsmga002.ch.intel.com ([10.2.17.35])
	by azsmga101.ch.intel.com with ESMTP; 26 Dec 2011 22:48:06 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="50880029"
Received: from pgsmsx603.gar.corp.intel.com ([10.221.43.87])
	by AZSMGA002.ch.intel.com with ESMTP; 26 Dec 2011 22:48:05 -0800
Received: from pgsmsx103.gar.corp.intel.com (10.221.44.82) by
	pgsmsx603.gar.corp.intel.com (10.221.43.87) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Tue, 27 Dec 2011 14:47:47 +0800
Received: from shsmsx101.ccr.corp.intel.com (10.239.4.153) by
	PGSMSX103.gar.corp.intel.com (10.221.44.82) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Tue, 27 Dec 2011 14:47:46 +0800
Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.199]) by
	SHSMSX101.ccr.corp.intel.com ([169.254.1.38]) with mapi id
	14.01.0355.002; Tue, 27 Dec 2011 14:47:44 +0800
From: "Tian, Kevin" <kevin.tian@intel.com>
To: "'Konrad Rzeszutek Wilk (konrad.wilk@oracle.com)'"
	<konrad.wilk@oracle.com>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>
Thread-Topic: question about i915 driver in dom0
Thread-Index: AczEYxGiaxw3o8ecRW2obuwyqnfvvw==
Date: Tue, 27 Dec 2011 06:47:44 +0000
Message-ID: <AADFC41AFE54684AB9EE6CBC0274A5D10158AE@SHSMSX102.ccr.corp.intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Subject: [Xen-devel] question about i915 driver in dom0
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi, Konrad

wiki page (http://wiki.xensource.com/xenwiki/XenPVOPSDRM.html#head-4da1a90049716207b9c672fd78187b0c77767be0)
says that "i915_hangcheck_eplased" error observed with i915 driver. 

Do you have a latest update on this issue? Is it still the outstanding issue, or fixed in
recent kernels?

I'm using Linux 3.2-rc4, with same error observed when trying to launch glxgear. So
want to understand whether it's due to my kernel version, or config option... :-)

Thanks
Kevin

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 27 08:44:58 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 27 Dec 2011 08: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.xensource.com>)
	id 1RfSdq-000526-GR; Tue, 27 Dec 2011 08:44:14 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mmrezaie@gmail.com>) id 1RfSdp-00051y-FW
	for xen-devel@lists.xensource.com; Tue, 27 Dec 2011 08:44:13 +0000
X-Env-Sender: mmrezaie@gmail.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1324975447!8884079!1
X-Originating-IP: [209.85.212.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9612 invoked from network); 27 Dec 2011 08:44:07 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Dec 2011 08:44:07 -0000
Received: by wico1 with SMTP id o1so12550449wic.30
	for <xen-devel@lists.xensource.com>;
	Tue, 27 Dec 2011 00:44:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=message-id:date:from:user-agent:mime-version:to:subject:references
	:in-reply-to:content-type:content-transfer-encoding;
	bh=ED2wRmD6NATB1f288j2zXU7amroMXKcEN6inTHMnr1g=;
	b=uvDbnPPmjzR26iYEBmsCG5LUVaQSNIsVeiKfsUd7Z7KlB1ZSDCEx7Dt9pMlpiRUc+x
	qM0Y7QjvSkWD7Qh3i9elNaC+z3JAoMUIz9d6WuYgdbyWDh1DFU8hWRsRtu6c5AvNeLX1
	cDlz0x9jhg8bckgIQwthXYFg/qKXSy4Sx45fk=
Received: by 10.180.81.72 with SMTP id y8mr59649556wix.14.1324975447264;
	Tue, 27 Dec 2011 00:44:07 -0800 (PST)
Received: from [192.168.50.99] ([81.28.34.226])
	by mx.google.com with ESMTPS id d17sm27191018wbh.19.2011.12.27.00.44.05
	(version=SSLv3 cipher=OTHER); Tue, 27 Dec 2011 00:44:06 -0800 (PST)
Message-ID: <4EF98552.9060205@gmail.com>
Date: Tue, 27 Dec 2011 12:14:02 +0330
From: Mohamad Rezaei <mmrezaie@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:8.0) Gecko/20111124 Thunderbird/8.0
MIME-Version: 1.0
To: xen-devel@lists.xensource.com
References: <4EF714C9.5010007@gmail.com>
In-Reply-To: <4EF714C9.5010007@gmail.com>
Subject: Re: [Xen-devel] how to debug xen itself?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 12/25/2011 03:49 PM, Mohamad Rezaei wrote:
> hi,
> 
> I am trying to debug xen hypervisor through gdb, and its kgdb. I have
> compiled xen with these options: --> make debug=y optimize=0
> crash_debug=y CMDLINE="console=com1 gdb=com1 earlygdb=y" -j8
> 
> I was expecting xen to stop, and wait for my gdb connection through
> serial port, but it boots up flawlessly. I am not sure what is my
> problem. Should I do something other than that.
> 
> I am doing this because I want to use debugger to get better view of xen
> internals.
> 
Can someone just let me know if I am doing something wrong?

-- 
Best Regards,
Mohamad Rezaei

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 27 08:44:58 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 27 Dec 2011 08: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.xensource.com>)
	id 1RfSdq-000526-GR; Tue, 27 Dec 2011 08:44:14 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mmrezaie@gmail.com>) id 1RfSdp-00051y-FW
	for xen-devel@lists.xensource.com; Tue, 27 Dec 2011 08:44:13 +0000
X-Env-Sender: mmrezaie@gmail.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1324975447!8884079!1
X-Originating-IP: [209.85.212.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9612 invoked from network); 27 Dec 2011 08:44:07 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Dec 2011 08:44:07 -0000
Received: by wico1 with SMTP id o1so12550449wic.30
	for <xen-devel@lists.xensource.com>;
	Tue, 27 Dec 2011 00:44:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=message-id:date:from:user-agent:mime-version:to:subject:references
	:in-reply-to:content-type:content-transfer-encoding;
	bh=ED2wRmD6NATB1f288j2zXU7amroMXKcEN6inTHMnr1g=;
	b=uvDbnPPmjzR26iYEBmsCG5LUVaQSNIsVeiKfsUd7Z7KlB1ZSDCEx7Dt9pMlpiRUc+x
	qM0Y7QjvSkWD7Qh3i9elNaC+z3JAoMUIz9d6WuYgdbyWDh1DFU8hWRsRtu6c5AvNeLX1
	cDlz0x9jhg8bckgIQwthXYFg/qKXSy4Sx45fk=
Received: by 10.180.81.72 with SMTP id y8mr59649556wix.14.1324975447264;
	Tue, 27 Dec 2011 00:44:07 -0800 (PST)
Received: from [192.168.50.99] ([81.28.34.226])
	by mx.google.com with ESMTPS id d17sm27191018wbh.19.2011.12.27.00.44.05
	(version=SSLv3 cipher=OTHER); Tue, 27 Dec 2011 00:44:06 -0800 (PST)
Message-ID: <4EF98552.9060205@gmail.com>
Date: Tue, 27 Dec 2011 12:14:02 +0330
From: Mohamad Rezaei <mmrezaie@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:8.0) Gecko/20111124 Thunderbird/8.0
MIME-Version: 1.0
To: xen-devel@lists.xensource.com
References: <4EF714C9.5010007@gmail.com>
In-Reply-To: <4EF714C9.5010007@gmail.com>
Subject: Re: [Xen-devel] how to debug xen itself?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 12/25/2011 03:49 PM, Mohamad Rezaei wrote:
> hi,
> 
> I am trying to debug xen hypervisor through gdb, and its kgdb. I have
> compiled xen with these options: --> make debug=y optimize=0
> crash_debug=y CMDLINE="console=com1 gdb=com1 earlygdb=y" -j8
> 
> I was expecting xen to stop, and wait for my gdb connection through
> serial port, but it boots up flawlessly. I am not sure what is my
> problem. Should I do something other than that.
> 
> I am doing this because I want to use debugger to get better view of xen
> internals.
> 
Can someone just let me know if I am doing something wrong?

-- 
Best Regards,
Mohamad Rezaei

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 27 10:06:46 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 27 Dec 2011 10:06:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RfTuy-0005V5-Ax; Tue, 27 Dec 2011 10:06:00 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <gang.wei@intel.com>) id 1RfTux-0005V0-4x
	for xen-devel@lists.xensource.com; Tue, 27 Dec 2011 10:05:59 +0000
X-Env-Sender: gang.wei@intel.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1324980351!8752382!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMjkxNDIx\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12316 invoked from network); 27 Dec 2011 10:05:52 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-3.tower-182.messagelabs.com with SMTP;
	27 Dec 2011 10:05:52 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga101.jf.intel.com with ESMTP; 27 Dec 2011 02:05:50 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.67,352,1309762800"; d="scan'208";a="90605911"
Received: from pgsmsx602.gar.corp.intel.com ([10.221.43.81])
	by orsmga001.jf.intel.com with ESMTP; 27 Dec 2011 02:05:49 -0800
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	pgsmsx602.gar.corp.intel.com (10.221.43.81) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Tue, 27 Dec 2011 18:05:48 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.38]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.199]) with mapi id
	14.01.0355.002; Tue, 27 Dec 2011 18:05:46 +0800
From: "Wei, Gang" <gang.wei@intel.com>
To: Jan Beulich <JBeulich@suse.com>
Thread-Topic: [patch] x86: Add a delay between INIT & SIPIs for tboot AP
	bring-up in X2APIC case
Thread-Index: AczAAslz2iL7OBXBT0+nwXPeOaB7qgARIT5gAAGReAAAMzbEEAABRG/A///PswD/+RVpQA==
Date: Tue, 27 Dec 2011 10:05:46 +0000
Message-ID: <D0B11485C64D4B47B66902F8A4E901BEB338@SHSMSX101.ccr.corp.intel.com>
References: <F26D193E20BBDC42A43B611D1BDEDE7135CEEEAE56@shsmsx502.ccr.corp.intel.com>
	<CB177C28.365E3%keir@xen.org>
	<F26D193E20BBDC42A43B611D1BDEDE7135CEEEAE63@shsmsx502.ccr.corp.intel.com>
	<F26D193E20BBDC42A43B611D1BDEDE7135CEEEAE65@shsmsx502.ccr.corp.intel.com>
	<20111221170539.GA72385@ocelot.phlegethon.org>
	<D0B11485C64D4B47B66902F8A4E901BE9146@SHSMSX101.ccr.corp.intel.com>
	<20111222100112.GA1900@ocelot.phlegethon.org>
	<D0B11485C64D4B47B66902F8A4E901BEA2B8@SHSMSX101.ccr.corp.intel.com>
	<D0B11485C64D4B47B66902F8A4E901BEA302@SHSMSX101.ccr.corp.intel.com>
	<4EF445A60200007800069B41@nat28.tlf.novell.com>
In-Reply-To: <4EF445A60200007800069B41@nat28.tlf.novell.com>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	"TimDeegan \(3P\)" <Tim.Deegan@citrix.com>, "Cihula,
	Joseph" <joseph.cihula@intel.com>, Tim Deegan <tim@xen.org>,
	"tboot-devel@lists.sourceforge.net" <tboot-devel@lists.sourceforge.net>,
	"Wei, Gang" <gang.wei@intel.com>
Subject: Re: [Xen-devel] [patch] x86: Add a delay between INIT & SIPIs for
 tboot AP bring-up in X2APIC case
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Jan Beulich wrote on=A02011-12-23:
>>>> On 23.12.11 at 04:14, "Wei, Gang" <gang.wei@intel.com> wrote:
>> Without this delay, Xen could not bring APs up while working with
>> TXT/tboot, because tboot need some time in APs to handle INIT before
>> becoming ready for receiving SIPIs.(this delay was removed as part
>> of c/s 23724 by Tim Deegan)
>> =

>> Signed-off-by: Gang Wei <gang.wei@intel.com>
>> Acked-by: Keir Fraser <keir@xen.org>
>> Acked-by: Tim Deegan <tim.deegan@citrix.com>
>> =

>> diff -r d1aefee43af1 xen/arch/x86/smpboot.c
>> --- a/xen/arch/x86/smpboot.c	Wed Dec 21 18:51:31 2011 +0800
>> +++ b/xen/arch/x86/smpboot.c	Fri Dec 23 11:01:10 2011 +0800
>> @@ -42,6 +42,7 @@
>>  #include <asm/msr.h> #include <asm/mtrr.h> #include <asm/time.h>
>>  +#include <asm/tboot.h> #include <mach_apic.h> #include
>>  <mach_wakecpu.h> #include <smpboot_hooks.h>
>> @@ -463,6 +464,18 @@
>>              send_status =3D apic_read(APIC_ICR) & APIC_ICR_BUSY;
>>          } while ( send_status && (timeout++ < 1000) );
>>      }
>> +    else if ( tboot_in_measured_env() )
>> +    {
>> +        /*
>> +         * With tboot AP is actually spinning in a mini-guest before
>> +         * receiving INIT. Upon receiving INIT ipi, AP need time to
>> + VMExit,
>> =

>> +         * update VMCS to tracking SIPIs and VMResume.
>> +         *
>> +         * While AP is in root mode handling the INIT the CPU will drop
>> +         * any SIPIs
>> +         */
>> +        udelay(10);
> =

> So you jumped from 100ms to 10us - how was that value established?
> Or in other words, how certain is it that this (or any other) timeout
> is sufficient for all current and future systems implementing tboot?

First way, code analysis. Tboot VMExitHandler only judge the condition, ena=
ble trapping SIPI, then VMResume. 10us means more than 10,000 cycles in Int=
el processors supporting TXT, it should be enough for this simple code path.

Second way, I tested it. The minimum value I tested is udelay(1). So I thin=
k udelay(10) should give enough margin.

Further, I am working on changing the SMP bring-up sequence for tboot path =
from INIT-SIPI-SIPI to MWAIT-memwrite style. It means tboot APs will wait i=
n MWAIT loops and Xen BSP will try to write the monitored memory to bring A=
Ps out of MWAIT loops.

Jimmy



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 27 10:06:46 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 27 Dec 2011 10:06:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RfTuy-0005V5-Ax; Tue, 27 Dec 2011 10:06:00 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <gang.wei@intel.com>) id 1RfTux-0005V0-4x
	for xen-devel@lists.xensource.com; Tue, 27 Dec 2011 10:05:59 +0000
X-Env-Sender: gang.wei@intel.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1324980351!8752382!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMjkxNDIx\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12316 invoked from network); 27 Dec 2011 10:05:52 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-3.tower-182.messagelabs.com with SMTP;
	27 Dec 2011 10:05:52 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga101.jf.intel.com with ESMTP; 27 Dec 2011 02:05:50 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.67,352,1309762800"; d="scan'208";a="90605911"
Received: from pgsmsx602.gar.corp.intel.com ([10.221.43.81])
	by orsmga001.jf.intel.com with ESMTP; 27 Dec 2011 02:05:49 -0800
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	pgsmsx602.gar.corp.intel.com (10.221.43.81) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Tue, 27 Dec 2011 18:05:48 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.38]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.199]) with mapi id
	14.01.0355.002; Tue, 27 Dec 2011 18:05:46 +0800
From: "Wei, Gang" <gang.wei@intel.com>
To: Jan Beulich <JBeulich@suse.com>
Thread-Topic: [patch] x86: Add a delay between INIT & SIPIs for tboot AP
	bring-up in X2APIC case
Thread-Index: AczAAslz2iL7OBXBT0+nwXPeOaB7qgARIT5gAAGReAAAMzbEEAABRG/A///PswD/+RVpQA==
Date: Tue, 27 Dec 2011 10:05:46 +0000
Message-ID: <D0B11485C64D4B47B66902F8A4E901BEB338@SHSMSX101.ccr.corp.intel.com>
References: <F26D193E20BBDC42A43B611D1BDEDE7135CEEEAE56@shsmsx502.ccr.corp.intel.com>
	<CB177C28.365E3%keir@xen.org>
	<F26D193E20BBDC42A43B611D1BDEDE7135CEEEAE63@shsmsx502.ccr.corp.intel.com>
	<F26D193E20BBDC42A43B611D1BDEDE7135CEEEAE65@shsmsx502.ccr.corp.intel.com>
	<20111221170539.GA72385@ocelot.phlegethon.org>
	<D0B11485C64D4B47B66902F8A4E901BE9146@SHSMSX101.ccr.corp.intel.com>
	<20111222100112.GA1900@ocelot.phlegethon.org>
	<D0B11485C64D4B47B66902F8A4E901BEA2B8@SHSMSX101.ccr.corp.intel.com>
	<D0B11485C64D4B47B66902F8A4E901BEA302@SHSMSX101.ccr.corp.intel.com>
	<4EF445A60200007800069B41@nat28.tlf.novell.com>
In-Reply-To: <4EF445A60200007800069B41@nat28.tlf.novell.com>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	"TimDeegan \(3P\)" <Tim.Deegan@citrix.com>, "Cihula,
	Joseph" <joseph.cihula@intel.com>, Tim Deegan <tim@xen.org>,
	"tboot-devel@lists.sourceforge.net" <tboot-devel@lists.sourceforge.net>,
	"Wei, Gang" <gang.wei@intel.com>
Subject: Re: [Xen-devel] [patch] x86: Add a delay between INIT & SIPIs for
 tboot AP bring-up in X2APIC case
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Jan Beulich wrote on=A02011-12-23:
>>>> On 23.12.11 at 04:14, "Wei, Gang" <gang.wei@intel.com> wrote:
>> Without this delay, Xen could not bring APs up while working with
>> TXT/tboot, because tboot need some time in APs to handle INIT before
>> becoming ready for receiving SIPIs.(this delay was removed as part
>> of c/s 23724 by Tim Deegan)
>> =

>> Signed-off-by: Gang Wei <gang.wei@intel.com>
>> Acked-by: Keir Fraser <keir@xen.org>
>> Acked-by: Tim Deegan <tim.deegan@citrix.com>
>> =

>> diff -r d1aefee43af1 xen/arch/x86/smpboot.c
>> --- a/xen/arch/x86/smpboot.c	Wed Dec 21 18:51:31 2011 +0800
>> +++ b/xen/arch/x86/smpboot.c	Fri Dec 23 11:01:10 2011 +0800
>> @@ -42,6 +42,7 @@
>>  #include <asm/msr.h> #include <asm/mtrr.h> #include <asm/time.h>
>>  +#include <asm/tboot.h> #include <mach_apic.h> #include
>>  <mach_wakecpu.h> #include <smpboot_hooks.h>
>> @@ -463,6 +464,18 @@
>>              send_status =3D apic_read(APIC_ICR) & APIC_ICR_BUSY;
>>          } while ( send_status && (timeout++ < 1000) );
>>      }
>> +    else if ( tboot_in_measured_env() )
>> +    {
>> +        /*
>> +         * With tboot AP is actually spinning in a mini-guest before
>> +         * receiving INIT. Upon receiving INIT ipi, AP need time to
>> + VMExit,
>> =

>> +         * update VMCS to tracking SIPIs and VMResume.
>> +         *
>> +         * While AP is in root mode handling the INIT the CPU will drop
>> +         * any SIPIs
>> +         */
>> +        udelay(10);
> =

> So you jumped from 100ms to 10us - how was that value established?
> Or in other words, how certain is it that this (or any other) timeout
> is sufficient for all current and future systems implementing tboot?

First way, code analysis. Tboot VMExitHandler only judge the condition, ena=
ble trapping SIPI, then VMResume. 10us means more than 10,000 cycles in Int=
el processors supporting TXT, it should be enough for this simple code path.

Second way, I tested it. The minimum value I tested is udelay(1). So I thin=
k udelay(10) should give enough margin.

Further, I am working on changing the SMP bring-up sequence for tboot path =
from INIT-SIPI-SIPI to MWAIT-memwrite style. It means tboot APs will wait i=
n MWAIT loops and Xen BSP will try to write the monitored memory to bring A=
Ps out of MWAIT loops.

Jimmy



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 27 10:48:19 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 27 Dec 2011 10:48:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RfUZ9-0005k7-BD; Tue, 27 Dec 2011 10:47:31 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RfUZ7-0005k2-Sm
	for xen-devel@lists.xensource.com; Tue, 27 Dec 2011 10:47:30 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-4.tower-174.messagelabs.com!1324982843!6984400!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28958 invoked from network); 27 Dec 2011 10:47:23 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-4.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Dec 2011 10:47:23 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RfUYp-000Bd5-LR; Tue, 27 Dec 2011 10:47:12 +0000
Date: Tue, 27 Dec 2011 10:47:10 +0000
From: Tim Deegan <tim@xen.org>
To: "Wei, Gang" <gang.wei@intel.com>
Message-ID: <20111227104710.GA44631@ocelot.phlegethon.org>
References: <CB177C28.365E3%keir@xen.org>
	<F26D193E20BBDC42A43B611D1BDEDE7135CEEEAE63@shsmsx502.ccr.corp.intel.com>
	<F26D193E20BBDC42A43B611D1BDEDE7135CEEEAE65@shsmsx502.ccr.corp.intel.com>
	<20111221170539.GA72385@ocelot.phlegethon.org>
	<D0B11485C64D4B47B66902F8A4E901BE9146@SHSMSX101.ccr.corp.intel.com>
	<20111222100112.GA1900@ocelot.phlegethon.org>
	<D0B11485C64D4B47B66902F8A4E901BEA2B8@SHSMSX101.ccr.corp.intel.com>
	<D0B11485C64D4B47B66902F8A4E901BEA302@SHSMSX101.ccr.corp.intel.com>
	<4EF445A60200007800069B41@nat28.tlf.novell.com>
	<D0B11485C64D4B47B66902F8A4E901BEB338@SHSMSX101.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <D0B11485C64D4B47B66902F8A4E901BEB338@SHSMSX101.ccr.corp.intel.com>
User-Agent: Mutt/1.4.2.1i
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	"TimDeegan \(3P\)" <Tim.Deegan@citrix.com>, "Cihula,
	Joseph" <joseph.cihula@intel.com>,
	"tboot-devel@lists.sourceforge.net" <tboot-devel@lists.sourceforge.net>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [patch] x86: Add a delay between INIT & SIPIs for
	tboot AP bring-up in X2APIC case
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 10:05 +0000 on 27 Dec (1324980346), Wei, Gang wrote:
> > So you jumped from 100ms to 10us - how was that value established?
> > Or in other words, how certain is it that this (or any other) timeout
> > is sufficient for all current and future systems implementing tboot?
> 
> First way, code analysis. Tboot VMExitHandler only judge the
> condition, enable trapping SIPI, then VMResume. 10us means more than
> 10,000 cycles in Intel processors supporting TXT, it should be enough
> for this simple code path.

Unless the BIOS does clever things in SMM of course. :)

> Further, I am working on changing the SMP bring-up sequence for tboot
> path from INIT-SIPI-SIPI to MWAIT-memwrite style. It means tboot APs
> will wait in MWAIT loops and Xen BSP will try to write the monitored
> memory to bring APs out of MWAIT loops.

That sounds like a very good idea.

Cheers,

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 27 10:48:19 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 27 Dec 2011 10:48:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RfUZ9-0005k7-BD; Tue, 27 Dec 2011 10:47:31 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RfUZ7-0005k2-Sm
	for xen-devel@lists.xensource.com; Tue, 27 Dec 2011 10:47:30 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-4.tower-174.messagelabs.com!1324982843!6984400!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28958 invoked from network); 27 Dec 2011 10:47:23 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-4.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Dec 2011 10:47:23 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RfUYp-000Bd5-LR; Tue, 27 Dec 2011 10:47:12 +0000
Date: Tue, 27 Dec 2011 10:47:10 +0000
From: Tim Deegan <tim@xen.org>
To: "Wei, Gang" <gang.wei@intel.com>
Message-ID: <20111227104710.GA44631@ocelot.phlegethon.org>
References: <CB177C28.365E3%keir@xen.org>
	<F26D193E20BBDC42A43B611D1BDEDE7135CEEEAE63@shsmsx502.ccr.corp.intel.com>
	<F26D193E20BBDC42A43B611D1BDEDE7135CEEEAE65@shsmsx502.ccr.corp.intel.com>
	<20111221170539.GA72385@ocelot.phlegethon.org>
	<D0B11485C64D4B47B66902F8A4E901BE9146@SHSMSX101.ccr.corp.intel.com>
	<20111222100112.GA1900@ocelot.phlegethon.org>
	<D0B11485C64D4B47B66902F8A4E901BEA2B8@SHSMSX101.ccr.corp.intel.com>
	<D0B11485C64D4B47B66902F8A4E901BEA302@SHSMSX101.ccr.corp.intel.com>
	<4EF445A60200007800069B41@nat28.tlf.novell.com>
	<D0B11485C64D4B47B66902F8A4E901BEB338@SHSMSX101.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <D0B11485C64D4B47B66902F8A4E901BEB338@SHSMSX101.ccr.corp.intel.com>
User-Agent: Mutt/1.4.2.1i
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	"TimDeegan \(3P\)" <Tim.Deegan@citrix.com>, "Cihula,
	Joseph" <joseph.cihula@intel.com>,
	"tboot-devel@lists.sourceforge.net" <tboot-devel@lists.sourceforge.net>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [patch] x86: Add a delay between INIT & SIPIs for
	tboot AP bring-up in X2APIC case
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 10:05 +0000 on 27 Dec (1324980346), Wei, Gang wrote:
> > So you jumped from 100ms to 10us - how was that value established?
> > Or in other words, how certain is it that this (or any other) timeout
> > is sufficient for all current and future systems implementing tboot?
> 
> First way, code analysis. Tboot VMExitHandler only judge the
> condition, enable trapping SIPI, then VMResume. 10us means more than
> 10,000 cycles in Intel processors supporting TXT, it should be enough
> for this simple code path.

Unless the BIOS does clever things in SMM of course. :)

> Further, I am working on changing the SMP bring-up sequence for tboot
> path from INIT-SIPI-SIPI to MWAIT-memwrite style. It means tboot APs
> will wait in MWAIT loops and Xen BSP will try to write the monitored
> memory to bring APs out of MWAIT loops.

That sounds like a very good idea.

Cheers,

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 27 10:58:58 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 27 Dec 2011 10:58:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RfUjh-0005uU-Gl; Tue, 27 Dec 2011 10:58:25 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RfUjf-0005uP-RM
	for xen-devel@lists.xensource.com; Tue, 27 Dec 2011 10:58:24 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-9.tower-27.messagelabs.com!1324983459!58137088!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22369 invoked from network); 27 Dec 2011 10:57:40 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-9.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Dec 2011 10:57:40 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RfUjX-000BhK-Mg; Tue, 27 Dec 2011 10:58:15 +0000
Date: Tue, 27 Dec 2011 10:58:14 +0000
From: Tim Deegan <tim@xen.org>
To: Mohamad Rezaei <mmrezaie@gmail.com>
Message-ID: <20111227105814.GB44631@ocelot.phlegethon.org>
References: <4EF5C756.4070403@gmail.com>
	<20111224124937.GB63360@ocelot.phlegethon.org>
	<CAK6aU6g1+wx4iVcO_9gtaGxXa-tnz50MuqW401TLdG2V=FK-8w@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAK6aU6g1+wx4iVcO_9gtaGxXa-tnz50MuqW401TLdG2V=FK-8w@mail.gmail.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] mapping virtual address to corresponding shadow
	page in xen
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi, 

At 16:26 +0330 on 24 Dec (1324744009), Mohamad Rezaei wrote:
> My question is when I want to read a data from domain, I use
> copy_from_guest. but now I want to map that address in domain (guest)
> to an address inside xen (hypervisor). I need to translate that
> address. somehow like this: gva -> gpfn -> gmfn -> mfn. To do this I
> have started a dom0 with dom0_shadow=1 option. So I presume that vtx
> is enabled for dom0.

Actually shadow pagetables are quite separate from VT-x (and predate it
- they were originally used for live migratoin of PV guests).  So no,
dom0_shadow=1 doesn't turn on VT-x for dom0.

Luckily, you don't need VT-x to map a page of dom0 memory (in fact it
wouldn't help).

Have a look at mem_event_enable() in xen/arch/x86/mm/mem_event.c - it
does exactly wat you need, starting with VA ring_addr and ending with a
mapping in med->ring_page.

Cheers, 

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 27 10:58:58 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 27 Dec 2011 10:58:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RfUjh-0005uU-Gl; Tue, 27 Dec 2011 10:58:25 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RfUjf-0005uP-RM
	for xen-devel@lists.xensource.com; Tue, 27 Dec 2011 10:58:24 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-9.tower-27.messagelabs.com!1324983459!58137088!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22369 invoked from network); 27 Dec 2011 10:57:40 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-9.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Dec 2011 10:57:40 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RfUjX-000BhK-Mg; Tue, 27 Dec 2011 10:58:15 +0000
Date: Tue, 27 Dec 2011 10:58:14 +0000
From: Tim Deegan <tim@xen.org>
To: Mohamad Rezaei <mmrezaie@gmail.com>
Message-ID: <20111227105814.GB44631@ocelot.phlegethon.org>
References: <4EF5C756.4070403@gmail.com>
	<20111224124937.GB63360@ocelot.phlegethon.org>
	<CAK6aU6g1+wx4iVcO_9gtaGxXa-tnz50MuqW401TLdG2V=FK-8w@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAK6aU6g1+wx4iVcO_9gtaGxXa-tnz50MuqW401TLdG2V=FK-8w@mail.gmail.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] mapping virtual address to corresponding shadow
	page in xen
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi, 

At 16:26 +0330 on 24 Dec (1324744009), Mohamad Rezaei wrote:
> My question is when I want to read a data from domain, I use
> copy_from_guest. but now I want to map that address in domain (guest)
> to an address inside xen (hypervisor). I need to translate that
> address. somehow like this: gva -> gpfn -> gmfn -> mfn. To do this I
> have started a dom0 with dom0_shadow=1 option. So I presume that vtx
> is enabled for dom0.

Actually shadow pagetables are quite separate from VT-x (and predate it
- they were originally used for live migratoin of PV guests).  So no,
dom0_shadow=1 doesn't turn on VT-x for dom0.

Luckily, you don't need VT-x to map a page of dom0 memory (in fact it
wouldn't help).

Have a look at mem_event_enable() in xen/arch/x86/mm/mem_event.c - it
does exactly wat you need, starting with VA ring_addr and ending with a
mapping in med->ring_page.

Cheers, 

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 27 11:01:17 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 27 Dec 2011 11: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.xensource.com>)
	id 1RfUlv-00062a-2L; Tue, 27 Dec 2011 11:00:43 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RfUlt-00062L-RR
	for xen-devel@lists.xensource.com; Tue, 27 Dec 2011 11:00:42 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-16.tower-216.messagelabs.com!1324983634!8735825!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16547 invoked from network); 27 Dec 2011 11:00:35 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-16.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Dec 2011 11:00:35 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RfUlk-000Bl9-LM; Tue, 27 Dec 2011 11:00:32 +0000
Date: Tue, 27 Dec 2011 11:00:32 +0000
From: Tim Deegan <tim@xen.org>
To: Mohamad Rezaei <mmrezaie@gmail.com>
Message-ID: <20111227110032.GC44631@ocelot.phlegethon.org>
References: <4EF714C9.5010007@gmail.com> <4EF98552.9060205@gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4EF98552.9060205@gmail.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] how to debug xen itself?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 12:14 +0330 on 27 Dec (1324988042), Mohamad Rezaei wrote:
> On 12/25/2011 03:49 PM, Mohamad Rezaei wrote:
> > hi,
> > 
> > I am trying to debug xen hypervisor through gdb, and its kgdb. I have
> > compiled xen with these options: --> make debug=y optimize=0
> > crash_debug=y CMDLINE="console=com1 gdb=com1 earlygdb=y" -j8
> > 
> > I was expecting xen to stop, and wait for my gdb connection through
> > serial port, but it boots up flawlessly. I am not sure what is my
> > problem. Should I do something other than that.
> > 
> > I am doing this because I want to use debugger to get better view of xen
> > internals.
> > 
> Can someone just let me know if I am doing something wrong?

You asked your question on Christmas Day - most people in Europe and the
USA are on holiday, so you shouldn't expect an answer to your question.

I don't use the gdb debugger so I can't help you; I don't think many
people do, so you may en up debugging the debugger yourself. 

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 27 11:01:17 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 27 Dec 2011 11: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.xensource.com>)
	id 1RfUlv-00062a-2L; Tue, 27 Dec 2011 11:00:43 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RfUlt-00062L-RR
	for xen-devel@lists.xensource.com; Tue, 27 Dec 2011 11:00:42 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-16.tower-216.messagelabs.com!1324983634!8735825!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16547 invoked from network); 27 Dec 2011 11:00:35 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-16.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Dec 2011 11:00:35 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RfUlk-000Bl9-LM; Tue, 27 Dec 2011 11:00:32 +0000
Date: Tue, 27 Dec 2011 11:00:32 +0000
From: Tim Deegan <tim@xen.org>
To: Mohamad Rezaei <mmrezaie@gmail.com>
Message-ID: <20111227110032.GC44631@ocelot.phlegethon.org>
References: <4EF714C9.5010007@gmail.com> <4EF98552.9060205@gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4EF98552.9060205@gmail.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] how to debug xen itself?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 12:14 +0330 on 27 Dec (1324988042), Mohamad Rezaei wrote:
> On 12/25/2011 03:49 PM, Mohamad Rezaei wrote:
> > hi,
> > 
> > I am trying to debug xen hypervisor through gdb, and its kgdb. I have
> > compiled xen with these options: --> make debug=y optimize=0
> > crash_debug=y CMDLINE="console=com1 gdb=com1 earlygdb=y" -j8
> > 
> > I was expecting xen to stop, and wait for my gdb connection through
> > serial port, but it boots up flawlessly. I am not sure what is my
> > problem. Should I do something other than that.
> > 
> > I am doing this because I want to use debugger to get better view of xen
> > internals.
> > 
> Can someone just let me know if I am doing something wrong?

You asked your question on Christmas Day - most people in Europe and the
USA are on holiday, so you shouldn't expect an answer to your question.

I don't use the gdb debugger so I can't help you; I don't think many
people do, so you may en up debugging the debugger yourself. 

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 27 11:51:37 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 27 Dec 2011 11:51:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RfVYc-0006Ov-Ad; Tue, 27 Dec 2011 11:51:02 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pasik@iki.fi>) id 1RfVYa-0006Oq-7q
	for xen-devel@lists.xensource.com; Tue, 27 Dec 2011 11:51:00 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-2.tower-174.messagelabs.com!1324986653!6970529!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiAzODgyNTI=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10634 invoked from network); 27 Dec 2011 11:50:54 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-2.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 27 Dec 2011 11:50:54 -0000
X-Originating-Ip: [194.89.68.22]
Received: from ydin.reaktio.net (reaktio.net [194.89.68.22])
	by smtp.tele.fi (Postfix) with ESMTP id 7BBDC152E;
	Tue, 27 Dec 2011 13:50:52 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id BEE6420058; Tue, 27 Dec 2011 13:50:51 +0200 (EET)
Date: Tue, 27 Dec 2011 13:50:51 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Tim Deegan <tim@xen.org>
Message-ID: <20111227115051.GJ12984@reaktio.net>
References: <4EF714C9.5010007@gmail.com> <4EF98552.9060205@gmail.com>
	<20111227110032.GC44631@ocelot.phlegethon.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20111227110032.GC44631@ocelot.phlegethon.org>
User-Agent: Mutt/1.5.18 (2008-05-17)
Cc: xen-devel@lists.xensource.com, Mohamad Rezaei <mmrezaie@gmail.com>
Subject: Re: [Xen-devel] how to debug xen itself?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Dec 27, 2011 at 11:00:32AM +0000, Tim Deegan wrote:
> At 12:14 +0330 on 27 Dec (1324988042), Mohamad Rezaei wrote:
> > On 12/25/2011 03:49 PM, Mohamad Rezaei wrote:
> > > hi,
> > > 
> > > I am trying to debug xen hypervisor through gdb, and its kgdb. I have
> > > compiled xen with these options: --> make debug=y optimize=0
> > > crash_debug=y CMDLINE="console=com1 gdb=com1 earlygdb=y" -j8
> > > 
> > > I was expecting xen to stop, and wait for my gdb connection through
> > > serial port, but it boots up flawlessly. I am not sure what is my
> > > problem. Should I do something other than that.
> > > 
> > > I am doing this because I want to use debugger to get better view of xen
> > > internals.
> > > 
> > Can someone just let me know if I am doing something wrong?
> 
> You asked your question on Christmas Day - most people in Europe and the
> USA are on holiday, so you shouldn't expect an answer to your question.
> 
> I don't use the gdb debugger so I can't help you; I don't think many
> people do, so you may en up debugging the debugger yourself. 
> 

Some google-hits:

"[Xen-devel] Debugging XEN Hypervisor":
http://old-list-archives.xen.org/archives/html/xen-devel/2009-10/msg00328.html

"[Xen-devel] Debugging XEN Hypervisor":
http://old-list-archives.xen.org/archives/html/xen-devel/2009-09/msg01064.html

"[Xen-devel] kdb does not support XEN?":
http://old-list-archives.xen.org/archives/html/xen-devel/2010-12/msg01519.html


Hopefully those help..

-- Pasi


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 27 11:51:37 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 27 Dec 2011 11:51:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RfVYc-0006Ov-Ad; Tue, 27 Dec 2011 11:51:02 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pasik@iki.fi>) id 1RfVYa-0006Oq-7q
	for xen-devel@lists.xensource.com; Tue, 27 Dec 2011 11:51:00 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-2.tower-174.messagelabs.com!1324986653!6970529!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiAzODgyNTI=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10634 invoked from network); 27 Dec 2011 11:50:54 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-2.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 27 Dec 2011 11:50:54 -0000
X-Originating-Ip: [194.89.68.22]
Received: from ydin.reaktio.net (reaktio.net [194.89.68.22])
	by smtp.tele.fi (Postfix) with ESMTP id 7BBDC152E;
	Tue, 27 Dec 2011 13:50:52 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id BEE6420058; Tue, 27 Dec 2011 13:50:51 +0200 (EET)
Date: Tue, 27 Dec 2011 13:50:51 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Tim Deegan <tim@xen.org>
Message-ID: <20111227115051.GJ12984@reaktio.net>
References: <4EF714C9.5010007@gmail.com> <4EF98552.9060205@gmail.com>
	<20111227110032.GC44631@ocelot.phlegethon.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20111227110032.GC44631@ocelot.phlegethon.org>
User-Agent: Mutt/1.5.18 (2008-05-17)
Cc: xen-devel@lists.xensource.com, Mohamad Rezaei <mmrezaie@gmail.com>
Subject: Re: [Xen-devel] how to debug xen itself?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Dec 27, 2011 at 11:00:32AM +0000, Tim Deegan wrote:
> At 12:14 +0330 on 27 Dec (1324988042), Mohamad Rezaei wrote:
> > On 12/25/2011 03:49 PM, Mohamad Rezaei wrote:
> > > hi,
> > > 
> > > I am trying to debug xen hypervisor through gdb, and its kgdb. I have
> > > compiled xen with these options: --> make debug=y optimize=0
> > > crash_debug=y CMDLINE="console=com1 gdb=com1 earlygdb=y" -j8
> > > 
> > > I was expecting xen to stop, and wait for my gdb connection through
> > > serial port, but it boots up flawlessly. I am not sure what is my
> > > problem. Should I do something other than that.
> > > 
> > > I am doing this because I want to use debugger to get better view of xen
> > > internals.
> > > 
> > Can someone just let me know if I am doing something wrong?
> 
> You asked your question on Christmas Day - most people in Europe and the
> USA are on holiday, so you shouldn't expect an answer to your question.
> 
> I don't use the gdb debugger so I can't help you; I don't think many
> people do, so you may en up debugging the debugger yourself. 
> 

Some google-hits:

"[Xen-devel] Debugging XEN Hypervisor":
http://old-list-archives.xen.org/archives/html/xen-devel/2009-10/msg00328.html

"[Xen-devel] Debugging XEN Hypervisor":
http://old-list-archives.xen.org/archives/html/xen-devel/2009-09/msg01064.html

"[Xen-devel] kdb does not support XEN?":
http://old-list-archives.xen.org/archives/html/xen-devel/2010-12/msg01519.html


Hopefully those help..

-- Pasi


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 27 12:28:45 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 27 Dec 2011 12:28:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RfW8Y-0006iO-OA; Tue, 27 Dec 2011 12:28:10 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RfW8W-0006iJ-Ug
	for xen-devel@lists.xensource.com; Tue, 27 Dec 2011 12:28:09 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1324988882!8875009!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODUxOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7105 invoked from network); 27 Dec 2011 12:28:02 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Dec 2011 12:28:02 -0000
X-IronPort-AV: E=Sophos;i="4.71,415,1320624000"; 
   d="scan'208";a="9698676"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Dec 2011 12:28:02 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 27 Dec 2011 12:28:02 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Pasi =?ISO-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
In-Reply-To: <20111227115051.GJ12984@reaktio.net>
References: <4EF714C9.5010007@gmail.com> <4EF98552.9060205@gmail.com>
	<20111227110032.GC44631@ocelot.phlegethon.org>
	<20111227115051.GJ12984@reaktio.net>
Organization: Citrix Systems, Inc.
Date: Tue, 27 Dec 2011 12:28:01 +0000
Message-ID: <1324988881.13909.3.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
X-Mailer: Evolution 2.32.3 
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Tim \(Xen.org\)" <tim@xen.org>, Mohamad Rezaei <mmrezaie@gmail.com>
Subject: Re: [Xen-devel] how to debug xen itself?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2011-12-27 at 11:50 +0000, Pasi K=E4rkk=E4inen wrote:
> On Tue, Dec 27, 2011 at 11:00:32AM +0000, Tim Deegan wrote:
> > At 12:14 +0330 on 27 Dec (1324988042), Mohamad Rezaei wrote:
> > > On 12/25/2011 03:49 PM, Mohamad Rezaei wrote:
> > > > hi,
> > > > =

> > > > I am trying to debug xen hypervisor through gdb, and its kgdb. I ha=
ve
> > > > compiled xen with these options: --> make debug=3Dy optimize=3D0
> > > > crash_debug=3Dy CMDLINE=3D"console=3Dcom1 gdb=3Dcom1 earlygdb=3Dy" =
-j8
> > > > =

> > > > I was expecting xen to stop, and wait for my gdb connection through
> > > > serial port, but it boots up flawlessly. I am not sure what is my
> > > > problem. Should I do something other than that.
> > > > =

> > > > I am doing this because I want to use debugger to get better view o=
f xen
> > > > internals.
> > > > =

> > > Can someone just let me know if I am doing something wrong?
> > =

> > You asked your question on Christmas Day - most people in Europe and the
> > USA are on holiday, so you shouldn't expect an answer to your question.
> > =

> > I don't use the gdb debugger so I can't help you; I don't think many
> > people do, so you may en up debugging the debugger yourself. =

> > =

> =

> Some google-hits:
> =

> "[Xen-devel] Debugging XEN Hypervisor":
> http://old-list-archives.xen.org/archives/html/xen-devel/2009-10/msg00328=
.html
> =

> "[Xen-devel] Debugging XEN Hypervisor":
> http://old-list-archives.xen.org/archives/html/xen-devel/2009-09/msg01064=
.html
> =

> "[Xen-devel] kdb does not support XEN?":
> http://old-list-archives.xen.org/archives/html/xen-devel/2010-12/msg01519=
.html
> =

> =

> Hopefully those help..

As might http://xenbits.xen.org/docs/unstable/misc/crashdb.txt.

Mohamad -- if you figure this out please consider updating the above
document by posting a patch against xen-unstable.hg
docs/misc/crashdb.txt or perhaps by creating a wiki page.

Ian.

> =

> -- Pasi
> =

> =

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Dec 27 12:28:45 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 27 Dec 2011 12:28:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RfW8Y-0006iO-OA; Tue, 27 Dec 2011 12:28:10 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RfW8W-0006iJ-Ug
	for xen-devel@lists.xensource.com; Tue, 27 Dec 2011 12:28:09 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1324988882!8875009!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODUxOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7105 invoked from network); 27 Dec 2011 12:28:02 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Dec 2011 12:28:02 -0000
X-IronPort-AV: E=Sophos;i="4.71,415,1320624000"; 
   d="scan'208";a="9698676"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Dec 2011 12:28:02 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 27 Dec 2011 12:28:02 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Pasi =?ISO-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
In-Reply-To: <20111227115051.GJ12984@reaktio.net>
References: <4EF714C9.5010007@gmail.com> <4EF98552.9060205@gmail.com>
	<20111227110032.GC44631@ocelot.phlegethon.org>
	<20111227115051.GJ12984@reaktio.net>
Organization: Citrix Systems, Inc.
Date: Tue, 27 Dec 2011 12:28:01 +0000
Message-ID: <1324988881.13909.3.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
X-Mailer: Evolution 2.32.3 
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Tim \(Xen.org\)" <tim@xen.org>, Mohamad Rezaei <mmrezaie@gmail.com>
Subject: Re: [Xen-devel] how to debug xen itself?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2011-12-27 at 11:50 +0000, Pasi K=E4rkk=E4inen wrote:
> On Tue, Dec 27, 2011 at 11:00:32AM +0000, Tim Deegan wrote:
> > At 12:14 +0330 on 27 Dec (1324988042), Mohamad Rezaei wrote:
> > > On 12/25/2011 03:49 PM, Mohamad Rezaei wrote:
> > > > hi,
> > > > =

> > > > I am trying to debug xen hypervisor through gdb, and its kgdb. I ha=
ve
> > > > compiled xen with these options: --> make debug=3Dy optimize=3D0
> > > > crash_debug=3Dy CMDLINE=3D"console=3Dcom1 gdb=3Dcom1 earlygdb=3Dy" =
-j8
> > > > =

> > > > I was expecting xen to stop, and wait for my gdb connection through
> > > > serial port, but it boots up flawlessly. I am not sure what is my
> > > > problem. Should I do something other than that.
> > > > =

> > > > I am doing this because I want to use debugger to get better view o=
f xen
> > > > internals.
> > > > =

> > > Can someone just let me know if I am doing something wrong?
> > =

> > You asked your question on Christmas Day - most people in Europe and the
> > USA are on holiday, so you shouldn't expect an answer to your question.
> > =

> > I don't use the gdb debugger so I can't help you; I don't think many
> > people do, so you may en up debugging the debugger yourself. =

> > =

> =

> Some google-hits:
> =

> "[Xen-devel] Debugging XEN Hypervisor":
> http://old-list-archives.xen.org/archives/html/xen-devel/2009-10/msg00328=
.html
> =

> "[Xen-devel] Debugging XEN Hypervisor":
> http://old-list-archives.xen.org/archives/html/xen-devel/2009-09/msg01064=
.html
> =

> "[Xen-devel] kdb does not support XEN?":
> http://old-list-archives.xen.org/archives/html/xen-devel/2010-12/msg01519=
.html
> =

> =

> Hopefully those help..

As might http://xenbits.xen.org/docs/unstable/misc/crashdb.txt.

Mohamad -- if you figure this out please consider updating the above
document by posting a patch against xen-unstable.hg
docs/misc/crashdb.txt or perhaps by creating a wiki page.

Ian.

> =

> -- Pasi
> =

> =

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 28 01:24:52 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 28 Dec 2011 01:24:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RfiFK-00079K-TX; Wed, 28 Dec 2011 01:23:58 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <gang.wei@intel.com>) id 1RfiFJ-00079F-9a
	for xen-devel@lists.xensource.com; Wed, 28 Dec 2011 01:23:57 +0000
X-Env-Sender: gang.wei@intel.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1325035430!1490167!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMjkxNTc5\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16932 invoked from network); 28 Dec 2011 01:23:51 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-16.tower-182.messagelabs.com with SMTP;
	28 Dec 2011 01:23:51 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga101.jf.intel.com with ESMTP; 27 Dec 2011 17:23:35 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.67,351,1309762800"; d="scan'208";a="92075901"
Received: from pgsmsx602.gar.corp.intel.com ([10.221.43.81])
	by orsmga002.jf.intel.com with ESMTP; 27 Dec 2011 17:23:34 -0800
Received: from pgsmsx509.gar.corp.intel.com (172.30.13.17) by
	pgsmsx602.gar.corp.intel.com (10.221.43.81) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Wed, 28 Dec 2011 09:22:50 +0800
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	PGSMSX509.gar.corp.intel.com (172.30.13.17) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Wed, 28 Dec 2011 09:22:50 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.38]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.223]) with mapi id
	14.01.0355.002; Wed, 28 Dec 2011 09:22:48 +0800
From: "Wei, Gang" <gang.wei@intel.com>
To: Tim Deegan <tim@xen.org>
Thread-Topic: [patch] x86: Add a delay between INIT & SIPIs for tboot AP
	bring-up in X2APIC case
Thread-Index: AczAAslz2iL7OBXBT0+nwXPeOaB7qgARIT5gAAGReAAAMzbEEAABRG/A///PswD/+RVpQIANX4oA//6HOSA=
Date: Wed, 28 Dec 2011 01:22:48 +0000
Message-ID: <D0B11485C64D4B47B66902F8A4E901BEB4E7@SHSMSX101.ccr.corp.intel.com>
References: <CB177C28.365E3%keir@xen.org>
	<F26D193E20BBDC42A43B611D1BDEDE7135CEEEAE63@shsmsx502.ccr.corp.intel.com>
	<F26D193E20BBDC42A43B611D1BDEDE7135CEEEAE65@shsmsx502.ccr.corp.intel.com>
	<20111221170539.GA72385@ocelot.phlegethon.org>
	<D0B11485C64D4B47B66902F8A4E901BE9146@SHSMSX101.ccr.corp.intel.com>
	<20111222100112.GA1900@ocelot.phlegethon.org>
	<D0B11485C64D4B47B66902F8A4E901BEA2B8@SHSMSX101.ccr.corp.intel.com>
	<D0B11485C64D4B47B66902F8A4E901BEA302@SHSMSX101.ccr.corp.intel.com>
	<4EF445A60200007800069B41@nat28.tlf.novell.com>
	<D0B11485C64D4B47B66902F8A4E901BEB338@SHSMSX101.ccr.corp.intel.com>
	<20111227104710.GA44631@ocelot.phlegethon.org>
In-Reply-To: <20111227104710.GA44631@ocelot.phlegethon.org>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Keir
	\(Xen.org\)" <keir@xen.org>, "TimDeegan \(3P\)" <Tim.Deegan@citrix.com>,
	"Cihula, Joseph" <joseph.cihula@intel.com>,
	"tboot-devel@lists.sourceforge.net" <tboot-devel@lists.sourceforge.net>,
	Jan Beulich <JBeulich@suse.com>, "Wei, Gang" <gang.wei@intel.com>
Subject: Re: [Xen-devel] [patch] x86: Add a delay between INIT & SIPIs for
 tboot AP bring-up in X2APIC case
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Tim Deegan wrote on=A02011-12-27:
> At 10:05 +0000 on 27 Dec (1324980346), Wei, Gang wrote:
>>> So you jumped from 100ms to 10us - how was that value established?
>>> Or in other words, how certain is it that this (or any other)
>>> timeout is sufficient for all current and future systems implementing t=
boot?
>> =

>> First way, code analysis. Tboot VMExitHandler only judge the
>> condition, enable trapping SIPI, then VMResume. 10us means more than
>> 10,000 cycles in Intel processors supporting TXT, it should be
>> enough for this simple code path.
> =

> Unless the BIOS does clever things in SMM of course. :)

If no further question on this patch from anyone else, could you help to ch=
eck it in?

> =

>> Further, I am working on changing the SMP bring-up sequence for
>> tboot path from INIT-SIPI-SIPI to MWAIT-memwrite style. It means
>> tboot APs will wait in MWAIT loops and Xen BSP will try to write the
>> monitored memory to bring APs out of MWAIT loops.
> =

> That sounds like a very good idea.

I will send out the patch for MWAIT SMP bring-up soon.

Jimmy

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 28 01:24:52 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 28 Dec 2011 01:24:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RfiFK-00079K-TX; Wed, 28 Dec 2011 01:23:58 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <gang.wei@intel.com>) id 1RfiFJ-00079F-9a
	for xen-devel@lists.xensource.com; Wed, 28 Dec 2011 01:23:57 +0000
X-Env-Sender: gang.wei@intel.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1325035430!1490167!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMjkxNTc5\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16932 invoked from network); 28 Dec 2011 01:23:51 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-16.tower-182.messagelabs.com with SMTP;
	28 Dec 2011 01:23:51 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga101.jf.intel.com with ESMTP; 27 Dec 2011 17:23:35 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.67,351,1309762800"; d="scan'208";a="92075901"
Received: from pgsmsx602.gar.corp.intel.com ([10.221.43.81])
	by orsmga002.jf.intel.com with ESMTP; 27 Dec 2011 17:23:34 -0800
Received: from pgsmsx509.gar.corp.intel.com (172.30.13.17) by
	pgsmsx602.gar.corp.intel.com (10.221.43.81) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Wed, 28 Dec 2011 09:22:50 +0800
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	PGSMSX509.gar.corp.intel.com (172.30.13.17) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Wed, 28 Dec 2011 09:22:50 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.38]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.223]) with mapi id
	14.01.0355.002; Wed, 28 Dec 2011 09:22:48 +0800
From: "Wei, Gang" <gang.wei@intel.com>
To: Tim Deegan <tim@xen.org>
Thread-Topic: [patch] x86: Add a delay between INIT & SIPIs for tboot AP
	bring-up in X2APIC case
Thread-Index: AczAAslz2iL7OBXBT0+nwXPeOaB7qgARIT5gAAGReAAAMzbEEAABRG/A///PswD/+RVpQIANX4oA//6HOSA=
Date: Wed, 28 Dec 2011 01:22:48 +0000
Message-ID: <D0B11485C64D4B47B66902F8A4E901BEB4E7@SHSMSX101.ccr.corp.intel.com>
References: <CB177C28.365E3%keir@xen.org>
	<F26D193E20BBDC42A43B611D1BDEDE7135CEEEAE63@shsmsx502.ccr.corp.intel.com>
	<F26D193E20BBDC42A43B611D1BDEDE7135CEEEAE65@shsmsx502.ccr.corp.intel.com>
	<20111221170539.GA72385@ocelot.phlegethon.org>
	<D0B11485C64D4B47B66902F8A4E901BE9146@SHSMSX101.ccr.corp.intel.com>
	<20111222100112.GA1900@ocelot.phlegethon.org>
	<D0B11485C64D4B47B66902F8A4E901BEA2B8@SHSMSX101.ccr.corp.intel.com>
	<D0B11485C64D4B47B66902F8A4E901BEA302@SHSMSX101.ccr.corp.intel.com>
	<4EF445A60200007800069B41@nat28.tlf.novell.com>
	<D0B11485C64D4B47B66902F8A4E901BEB338@SHSMSX101.ccr.corp.intel.com>
	<20111227104710.GA44631@ocelot.phlegethon.org>
In-Reply-To: <20111227104710.GA44631@ocelot.phlegethon.org>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Keir
	\(Xen.org\)" <keir@xen.org>, "TimDeegan \(3P\)" <Tim.Deegan@citrix.com>,
	"Cihula, Joseph" <joseph.cihula@intel.com>,
	"tboot-devel@lists.sourceforge.net" <tboot-devel@lists.sourceforge.net>,
	Jan Beulich <JBeulich@suse.com>, "Wei, Gang" <gang.wei@intel.com>
Subject: Re: [Xen-devel] [patch] x86: Add a delay between INIT & SIPIs for
 tboot AP bring-up in X2APIC case
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Tim Deegan wrote on=A02011-12-27:
> At 10:05 +0000 on 27 Dec (1324980346), Wei, Gang wrote:
>>> So you jumped from 100ms to 10us - how was that value established?
>>> Or in other words, how certain is it that this (or any other)
>>> timeout is sufficient for all current and future systems implementing t=
boot?
>> =

>> First way, code analysis. Tboot VMExitHandler only judge the
>> condition, enable trapping SIPI, then VMResume. 10us means more than
>> 10,000 cycles in Intel processors supporting TXT, it should be
>> enough for this simple code path.
> =

> Unless the BIOS does clever things in SMM of course. :)

If no further question on this patch from anyone else, could you help to ch=
eck it in?

> =

>> Further, I am working on changing the SMP bring-up sequence for
>> tboot path from INIT-SIPI-SIPI to MWAIT-memwrite style. It means
>> tboot APs will wait in MWAIT loops and Xen BSP will try to write the
>> monitored memory to bring APs out of MWAIT loops.
> =

> That sounds like a very good idea.

I will send out the patch for MWAIT SMP bring-up soon.

Jimmy

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 28 05:15:31 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 28 Dec 2011 05: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.xensource.com>)
	id 1Rflqa-0008Up-3c; Wed, 28 Dec 2011 05:14:40 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RflqY-0008Uk-D6
	for xen-devel@lists.xensource.com; Wed, 28 Dec 2011 05:14:38 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1325049272!7005872!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODU1Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30597 invoked from network); 28 Dec 2011 05:14:32 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Dec 2011 05:14:32 -0000
X-IronPort-AV: E=Sophos;i="4.71,418,1320624000"; 
   d="scan'208";a="9711038"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Dec 2011 05:14:31 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 28 Dec 2011 05:14:31 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RflqQ-0005zs-TB;
	Wed, 28 Dec 2011 05:14:30 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RflqQ-0005Vj-Oq;
	Wed, 28 Dec 2011 05:14:30 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10611-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 28 Dec 2011 05:14:30 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10611: tolerable FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10611 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10611/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-i386-i386-xl            16 guest-start.2               fail pass in 10610
 test-amd64-i386-pv           16 guest-start.2      fail in 10610 pass in 10611
 test-amd64-amd64-xl-sedf-pin 13 guest-localmigrate.2 fail in 10610 pass in 10611

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl           16 guest-start.2                fail   like 10606
 test-amd64-amd64-xl-sedf     14 guest-localmigrate/x10       fail   like 10609
 test-amd64-amd64-pv          16 guest-start.2         fail in 10610 like 10603

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass

version targeted for testing:
 xen                  2863b2f43a3b
baseline version:
 xen                  2863b2f43a3b

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           fail    
 test-i386-i386-xl                                            fail    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 28 05:15:31 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 28 Dec 2011 05: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.xensource.com>)
	id 1Rflqa-0008Up-3c; Wed, 28 Dec 2011 05:14:40 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RflqY-0008Uk-D6
	for xen-devel@lists.xensource.com; Wed, 28 Dec 2011 05:14:38 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1325049272!7005872!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODU1Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30597 invoked from network); 28 Dec 2011 05:14:32 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Dec 2011 05:14:32 -0000
X-IronPort-AV: E=Sophos;i="4.71,418,1320624000"; 
   d="scan'208";a="9711038"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Dec 2011 05:14:31 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 28 Dec 2011 05:14:31 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RflqQ-0005zs-TB;
	Wed, 28 Dec 2011 05:14:30 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RflqQ-0005Vj-Oq;
	Wed, 28 Dec 2011 05:14:30 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10611-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 28 Dec 2011 05:14:30 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10611: tolerable FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10611 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10611/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-i386-i386-xl            16 guest-start.2               fail pass in 10610
 test-amd64-i386-pv           16 guest-start.2      fail in 10610 pass in 10611
 test-amd64-amd64-xl-sedf-pin 13 guest-localmigrate.2 fail in 10610 pass in 10611

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl           16 guest-start.2                fail   like 10606
 test-amd64-amd64-xl-sedf     14 guest-localmigrate/x10       fail   like 10609
 test-amd64-amd64-pv          16 guest-start.2         fail in 10610 like 10603

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass

version targeted for testing:
 xen                  2863b2f43a3b
baseline version:
 xen                  2863b2f43a3b

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           fail    
 test-i386-i386-xl                                            fail    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 28 11:15:07 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 28 Dec 2011 11:15:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RfrSV-0001pr-Bh; Wed, 28 Dec 2011 11:14:11 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pasik@iki.fi>)
	id 1RfrSU-0001pj-8d; Wed, 28 Dec 2011 11:14:10 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-2.tower-21.messagelabs.com!1325070843!2114045!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiAzODk3NDQ=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18121 invoked from network); 28 Dec 2011 11:14:04 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-2.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 28 Dec 2011 11:14:04 -0000
X-Originating-Ip: [194.89.68.22]
Received: from ydin.reaktio.net (reaktio.net [194.89.68.22])
	by smtp.tele.fi (Postfix) with ESMTP id B04CB1D07;
	Wed, 28 Dec 2011 13:14:02 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 590A420058; Wed, 28 Dec 2011 13:14:02 +0200 (EET)
Date: Wed, 28 Dec 2011 13:14:02 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Tim Evers <it@niemail.de>
Message-ID: <20111228111402.GM12984@reaktio.net>
References: <4ECD6191.4080201@niemail.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4ECD6191.4080201@niemail.de>
User-Agent: Mutt/1.5.18 (2008-05-17)
Cc: xen-devel@lists.xensource.com, xen-users@lists.xensource.com
Subject: Re: [Xen-devel] [Xen-users] Xen + pv_ops + migration + hotadd vcpus
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Nov 23, 2011 at 10:11:45PM +0100, Tim Evers wrote:
> Hope I don't annoy you but I'm totally stuck.
> 

Hello,

I added xen-devel to CC list..

> Here is my question to all xen users:
> 
> Is there anyone who has a running pv_ops kernel (like 2.6.32.x or
> 2.6.35.x or 2.6.38.x or 3.x) which supports the following operations
> without a crash:
> 
> - boot with maxvcpus > vcpus
> - then migrate from one dom0 to another
> - raise the vcpus (via xm vcpu-set)
> - take the cpus online in the domu
> 
> either on xen 4.0.x or 4.1.x with pv_ops dom0 OR patch dom0 (like
> 2.6.26.x) with or without pv_spinlock enabled.
> 

Please be more exact about your kernel versions:
- What dom0 kernel version? 
- What domU kernel version? 
- And what Xen version? 

> While I've been doing this for more than a year now with a 2.6.26 kernel
> with xen patches without one single crash, I've not been able to do it
> in any way with newer pv_ops kernel.
> 
> Taking the cpus online crashes the domu whith "cpu stuck" messages and
> silly timestamps like 10,000s.
> 
> Anyone, please :)
> 
> Regards,
> 
> Tim
> 

-- Pasi


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 28 11:15:07 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 28 Dec 2011 11:15:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RfrSV-0001pr-Bh; Wed, 28 Dec 2011 11:14:11 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pasik@iki.fi>)
	id 1RfrSU-0001pj-8d; Wed, 28 Dec 2011 11:14:10 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-2.tower-21.messagelabs.com!1325070843!2114045!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiAzODk3NDQ=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18121 invoked from network); 28 Dec 2011 11:14:04 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-2.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 28 Dec 2011 11:14:04 -0000
X-Originating-Ip: [194.89.68.22]
Received: from ydin.reaktio.net (reaktio.net [194.89.68.22])
	by smtp.tele.fi (Postfix) with ESMTP id B04CB1D07;
	Wed, 28 Dec 2011 13:14:02 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 590A420058; Wed, 28 Dec 2011 13:14:02 +0200 (EET)
Date: Wed, 28 Dec 2011 13:14:02 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Tim Evers <it@niemail.de>
Message-ID: <20111228111402.GM12984@reaktio.net>
References: <4ECD6191.4080201@niemail.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4ECD6191.4080201@niemail.de>
User-Agent: Mutt/1.5.18 (2008-05-17)
Cc: xen-devel@lists.xensource.com, xen-users@lists.xensource.com
Subject: Re: [Xen-devel] [Xen-users] Xen + pv_ops + migration + hotadd vcpus
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Nov 23, 2011 at 10:11:45PM +0100, Tim Evers wrote:
> Hope I don't annoy you but I'm totally stuck.
> 

Hello,

I added xen-devel to CC list..

> Here is my question to all xen users:
> 
> Is there anyone who has a running pv_ops kernel (like 2.6.32.x or
> 2.6.35.x or 2.6.38.x or 3.x) which supports the following operations
> without a crash:
> 
> - boot with maxvcpus > vcpus
> - then migrate from one dom0 to another
> - raise the vcpus (via xm vcpu-set)
> - take the cpus online in the domu
> 
> either on xen 4.0.x or 4.1.x with pv_ops dom0 OR patch dom0 (like
> 2.6.26.x) with or without pv_spinlock enabled.
> 

Please be more exact about your kernel versions:
- What dom0 kernel version? 
- What domU kernel version? 
- And what Xen version? 

> While I've been doing this for more than a year now with a 2.6.26 kernel
> with xen patches without one single crash, I've not been able to do it
> in any way with newer pv_ops kernel.
> 
> Taking the cpus online crashes the domu whith "cpu stuck" messages and
> silly timestamps like 10,000s.
> 
> Anyone, please :)
> 
> Regards,
> 
> Tim
> 

-- Pasi


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 28 11:20:16 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 28 Dec 2011 11:20:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RfrXb-00029H-Pm; Wed, 28 Dec 2011 11:19:27 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pasik@iki.fi>)
	id 1RfrXa-00028g-Iq; Wed, 28 Dec 2011 11:19:26 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-2.tower-21.messagelabs.com!1325071160!2114576!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiAzODk3NDQ=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29256 invoked from network); 28 Dec 2011 11:19:20 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-2.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 28 Dec 2011 11:19:20 -0000
X-Originating-Ip: [194.89.68.22]
Received: from ydin.reaktio.net (reaktio.net [194.89.68.22])
	by smtp.tele.fi (Postfix) with ESMTP id 3DBF41F2A;
	Wed, 28 Dec 2011 13:19:18 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 1EFB620058; Wed, 28 Dec 2011 13:19:18 +0200 (EET)
Date: Wed, 28 Dec 2011 13:19:18 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Florian Heigl <florian.heigl@gmail.com>
Message-ID: <20111228111918.GN12984@reaktio.net>
References: <20111217135342.DDB9E3806B9@mx1.internecto.net>
	<CAFivhP=Uw=e8M_JsE2_fRpT5KtqYuKEf_Jdm2aEQz17iT_vHMw@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAFivhP=Uw=e8M_JsE2_fRpT5KtqYuKEf_Jdm2aEQz17iT_vHMw@mail.gmail.com>
User-Agent: Mutt/1.5.18 (2008-05-17)
Cc: xen-devel@lists.xensource.com, xen-users@lists.xensource.com,
	mark@internecto.net
Subject: Re: [Xen-devel] [Xen-users] xl and vifname
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Dec 19, 2011 at 12:57:43PM +0100, Florian Heigl wrote:
> Hi,
> 

Hello,

> 2011/12/17  <mark@internecto.net>:
> > While using xen 4.1-testing.hg (r23202) I noticed that the 'vifname'
> > config value is not handled by xl, but is handled by xm. Is there a
> > workaround or patch for this? My firewall and scripts depend on static
> > vifnames.
> 
> xl does not support vifname as of now.
> Except for one type of HVM domU, where it does support vifname.
> 
> You might want to communicate to xen-devel that you rely on it and all that.
> 

Added xen-devel to CC list ..

> I also think I need vifname support - it's unbearable to work without
> vifnames if you run a setup with potentially many 100 vifs + vlans +
> brides + bonds.
> (I guess thats how the whole UUID disaster in XenServer happened)
> 
> I said "think I need" because I DO rely on them, but maybe something
> happens that makes me suddenly understand that it's better to script
> against some API to get the information reliably without any problem
> by changing domIDs and always being up-to-date.
> Oh wait, that would be like setting vifname and just looking at the
> ifconfig output :)
> 
> 
> Florian
> 
> -- 
> the purpose of libvirt is to provide an abstraction layer hiding all
> xen features added since 2006 until they were finally understood and
> copied by the kvm devs.
> 

-- Pasi


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 28 11:20:16 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 28 Dec 2011 11:20:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RfrXb-00029H-Pm; Wed, 28 Dec 2011 11:19:27 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pasik@iki.fi>)
	id 1RfrXa-00028g-Iq; Wed, 28 Dec 2011 11:19:26 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-2.tower-21.messagelabs.com!1325071160!2114576!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiAzODk3NDQ=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29256 invoked from network); 28 Dec 2011 11:19:20 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-2.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 28 Dec 2011 11:19:20 -0000
X-Originating-Ip: [194.89.68.22]
Received: from ydin.reaktio.net (reaktio.net [194.89.68.22])
	by smtp.tele.fi (Postfix) with ESMTP id 3DBF41F2A;
	Wed, 28 Dec 2011 13:19:18 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 1EFB620058; Wed, 28 Dec 2011 13:19:18 +0200 (EET)
Date: Wed, 28 Dec 2011 13:19:18 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Florian Heigl <florian.heigl@gmail.com>
Message-ID: <20111228111918.GN12984@reaktio.net>
References: <20111217135342.DDB9E3806B9@mx1.internecto.net>
	<CAFivhP=Uw=e8M_JsE2_fRpT5KtqYuKEf_Jdm2aEQz17iT_vHMw@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAFivhP=Uw=e8M_JsE2_fRpT5KtqYuKEf_Jdm2aEQz17iT_vHMw@mail.gmail.com>
User-Agent: Mutt/1.5.18 (2008-05-17)
Cc: xen-devel@lists.xensource.com, xen-users@lists.xensource.com,
	mark@internecto.net
Subject: Re: [Xen-devel] [Xen-users] xl and vifname
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Dec 19, 2011 at 12:57:43PM +0100, Florian Heigl wrote:
> Hi,
> 

Hello,

> 2011/12/17  <mark@internecto.net>:
> > While using xen 4.1-testing.hg (r23202) I noticed that the 'vifname'
> > config value is not handled by xl, but is handled by xm. Is there a
> > workaround or patch for this? My firewall and scripts depend on static
> > vifnames.
> 
> xl does not support vifname as of now.
> Except for one type of HVM domU, where it does support vifname.
> 
> You might want to communicate to xen-devel that you rely on it and all that.
> 

Added xen-devel to CC list ..

> I also think I need vifname support - it's unbearable to work without
> vifnames if you run a setup with potentially many 100 vifs + vlans +
> brides + bonds.
> (I guess thats how the whole UUID disaster in XenServer happened)
> 
> I said "think I need" because I DO rely on them, but maybe something
> happens that makes me suddenly understand that it's better to script
> against some API to get the information reliably without any problem
> by changing domIDs and always being up-to-date.
> Oh wait, that would be like setting vifname and just looking at the
> ifconfig output :)
> 
> 
> Florian
> 
> -- 
> the purpose of libvirt is to provide an abstraction layer hiding all
> xen features added since 2006 until they were finally understood and
> copied by the kvm devs.
> 

-- Pasi


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 28 11:30:00 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 28 Dec 2011 11:30:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RfrhL-0003Hj-Kf; Wed, 28 Dec 2011 11:29:31 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mmrezaie@gmail.com>) id 1RfrhK-0003Fl-1P
	for xen-devel@lists.xensource.com; Wed, 28 Dec 2011 11:29:30 +0000
X-Env-Sender: mmrezaie@gmail.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1325071763!8792237!1
X-Originating-IP: [209.85.216.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5474 invoked from network); 28 Dec 2011 11:29:24 -0000
Received: from mail-qy0-f171.google.com (HELO mail-qy0-f171.google.com)
	(209.85.216.171)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Dec 2011 11:29:24 -0000
Received: by qcsc20 with SMTP id c20so90516721qcs.30
	for <xen-devel@lists.xensource.com>;
	Wed, 28 Dec 2011 03:29:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=message-id:date:from:user-agent:mime-version:to:subject
	:content-type:content-transfer-encoding;
	bh=JYlcB/XmleJe8Ne7s5GB/dUyQZsIwYjYrXvcZWOD4hI=;
	b=Pd8cdqgCC4+dRY93rKtRBAiQe/ju41/H/qjGN2FIwix2EwUEy+tTdZ1o9t0Ua8+20D
	D9p8ko41Afnw8KJHf9mkooL7E8yLD36GcesB5uZa68FIX0Pji6ETHIIeefxmoCnKnc7P
	1pR8RA1DlVTJRwpgR/oEbXtjuHH2Q/RJtRRD4=
Received: by 10.224.105.196 with SMTP id u4mr38188014qao.47.1325071762870;
	Wed, 28 Dec 2011 03:29:22 -0800 (PST)
Received: from [192.168.50.99] ([81.28.34.226])
	by mx.google.com with ESMTPS id dj9sm57524751qab.18.2011.12.28.03.29.20
	(version=SSLv3 cipher=OTHER); Wed, 28 Dec 2011 03:29:22 -0800 (PST)
Message-ID: <4EFAFD8C.2050502@gmail.com>
Date: Wed, 28 Dec 2011 14:59:16 +0330
From: Mohamad Rezaei <mmrezaie@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:8.0) Gecko/20111124 Thunderbird/8.0
MIME-Version: 1.0
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] enabling VT-x for Dom0?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Thanks for previous helps. I am working on them.

Is there any way to enable vt-x[EPT] for Dom0. I am trying to do
something like what bitvisor has done, but using vastly helpful
functionalities of xen. And I need to ask; would we see any performance
improvement if we do this?

I know that virtual memory mechanism like shadow paging will isolate
dom0, and xen from each other. Implementation of virtual BIOS also will
help to prevent to use something like INT 15 to pass it through. In the
other words, Do we have isolation of xen, and Dom0 without even using VT-x?

-- 
Best Regards,
Mohamad Rezaei


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 28 11:30:00 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 28 Dec 2011 11:30:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RfrhL-0003Hj-Kf; Wed, 28 Dec 2011 11:29:31 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mmrezaie@gmail.com>) id 1RfrhK-0003Fl-1P
	for xen-devel@lists.xensource.com; Wed, 28 Dec 2011 11:29:30 +0000
X-Env-Sender: mmrezaie@gmail.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1325071763!8792237!1
X-Originating-IP: [209.85.216.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5474 invoked from network); 28 Dec 2011 11:29:24 -0000
Received: from mail-qy0-f171.google.com (HELO mail-qy0-f171.google.com)
	(209.85.216.171)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Dec 2011 11:29:24 -0000
Received: by qcsc20 with SMTP id c20so90516721qcs.30
	for <xen-devel@lists.xensource.com>;
	Wed, 28 Dec 2011 03:29:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=message-id:date:from:user-agent:mime-version:to:subject
	:content-type:content-transfer-encoding;
	bh=JYlcB/XmleJe8Ne7s5GB/dUyQZsIwYjYrXvcZWOD4hI=;
	b=Pd8cdqgCC4+dRY93rKtRBAiQe/ju41/H/qjGN2FIwix2EwUEy+tTdZ1o9t0Ua8+20D
	D9p8ko41Afnw8KJHf9mkooL7E8yLD36GcesB5uZa68FIX0Pji6ETHIIeefxmoCnKnc7P
	1pR8RA1DlVTJRwpgR/oEbXtjuHH2Q/RJtRRD4=
Received: by 10.224.105.196 with SMTP id u4mr38188014qao.47.1325071762870;
	Wed, 28 Dec 2011 03:29:22 -0800 (PST)
Received: from [192.168.50.99] ([81.28.34.226])
	by mx.google.com with ESMTPS id dj9sm57524751qab.18.2011.12.28.03.29.20
	(version=SSLv3 cipher=OTHER); Wed, 28 Dec 2011 03:29:22 -0800 (PST)
Message-ID: <4EFAFD8C.2050502@gmail.com>
Date: Wed, 28 Dec 2011 14:59:16 +0330
From: Mohamad Rezaei <mmrezaie@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:8.0) Gecko/20111124 Thunderbird/8.0
MIME-Version: 1.0
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] enabling VT-x for Dom0?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Thanks for previous helps. I am working on them.

Is there any way to enable vt-x[EPT] for Dom0. I am trying to do
something like what bitvisor has done, but using vastly helpful
functionalities of xen. And I need to ask; would we see any performance
improvement if we do this?

I know that virtual memory mechanism like shadow paging will isolate
dom0, and xen from each other. Implementation of virtual BIOS also will
help to prevent to use something like INT 15 to pass it through. In the
other words, Do we have isolation of xen, and Dom0 without even using VT-x?

-- 
Best Regards,
Mohamad Rezaei


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 28 14:00:52 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 28 Dec 2011 14:00:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rfu34-0004lA-N6; Wed, 28 Dec 2011 14:00:06 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tknchris@gmail.com>)
	id 1Rfu33-0004h9-Ds; Wed, 28 Dec 2011 14:00:05 +0000
X-Env-Sender: tknchris@gmail.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1325080744!58850965!1
X-Originating-IP: [209.85.214.171]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29225 invoked from network); 28 Dec 2011 13:59:06 -0000
Received: from mail-tul01m020-f171.google.com (HELO
	mail-tul01m020-f171.google.com) (209.85.214.171)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Dec 2011 13:59:06 -0000
Received: by obbwd20 with SMTP id wd20so33847312obb.30
	for <multiple recipients>; Wed, 28 Dec 2011 05:59:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=2iiUwgunYByUN7zMDHR6+cqVdsmYCflfCK7FVM0+Pqo=;
	b=XUPvNTJYpWFlktPRtBUnEWSYXZ7HGIBhHvAGIgRJNamIQ2GPivXJgGL4OswrS/wdEF
	cN6bRPo549e6FU5ntBtvREeAaoUoKlvXF2JU290h3CbzKxlBWoyfkZVo9cG7Lf3SY5eo
	zVtFEULN2iiyanfD33KwCfInUxWJKOALn6IsY=
MIME-Version: 1.0
Received: by 10.50.182.130 with SMTP id ee2mr35970386igc.30.1325080797332;
	Wed, 28 Dec 2011 05:59:57 -0800 (PST)
Received: by 10.42.144.197 with HTTP; Wed, 28 Dec 2011 05:59:57 -0800 (PST)
In-Reply-To: <20111228111918.GN12984@reaktio.net>
References: <20111217135342.DDB9E3806B9@mx1.internecto.net>
	<CAFivhP=Uw=e8M_JsE2_fRpT5KtqYuKEf_Jdm2aEQz17iT_vHMw@mail.gmail.com>
	<20111228111918.GN12984@reaktio.net>
Date: Wed, 28 Dec 2011 08:59:57 -0500
Message-ID: <CAKnNFz8sHNvKEyF=oRci6rwO6a82XS3x9AJMACPdu3_qTSx8Dg@mail.gmail.com>
From: chris <tknchris@gmail.com>
To: =?ISO-8859-1?Q?Pasi_K=E4rkk=E4inen?= <pasik@iki.fi>
Cc: Florian Heigl <florian.heigl@gmail.com>, xen-devel@lists.xensource.com,
	xen-users@lists.xensource.com, mark@internecto.net
Subject: Re: [Xen-devel] [Xen-users] xl and vifname
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============9082571629766551714=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============9082571629766551714==
Content-Type: multipart/alternative; boundary=14dae9340e6539440704b5276ab0

--14dae9340e6539440704b5276ab0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

+1 to using vifname pretty heavily, sure you can get the job done without
but why suffer needlessly? :)

On Wed, Dec 28, 2011 at 6:19 AM, Pasi K=E4rkk=E4inen <pasik@iki.fi> wrote:

> On Mon, Dec 19, 2011 at 12:57:43PM +0100, Florian Heigl wrote:
> > Hi,
> >
>
> Hello,
>
> > 2011/12/17  <mark@internecto.net>:
> > > While using xen 4.1-testing.hg (r23202) I noticed that the 'vifname'
> > > config value is not handled by xl, but is handled by xm. Is there a
> > > workaround or patch for this? My firewall and scripts depend on stati=
c
> > > vifnames.
> >
> > xl does not support vifname as of now.
> > Except for one type of HVM domU, where it does support vifname.
> >
> > You might want to communicate to xen-devel that you rely on it and all
> that.
> >
>
> Added xen-devel to CC list ..
>
> > I also think I need vifname support - it's unbearable to work without
> > vifnames if you run a setup with potentially many 100 vifs + vlans +
> > brides + bonds.
> > (I guess thats how the whole UUID disaster in XenServer happened)
> >
> > I said "think I need" because I DO rely on them, but maybe something
> > happens that makes me suddenly understand that it's better to script
> > against some API to get the information reliably without any problem
> > by changing domIDs and always being up-to-date.
> > Oh wait, that would be like setting vifname and just looking at the
> > ifconfig output :)
> >
> >
> > Florian
> >
> > --
> > the purpose of libvirt is to provide an abstraction layer hiding all
> > xen features added since 2006 until they were finally understood and
> > copied by the kvm devs.
> >
>
> -- Pasi
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>

--14dae9340e6539440704b5276ab0
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

+1 to using vifname pretty heavily, sure you can get the job done without b=
ut why suffer needlessly? :)<br><br><div class=3D"gmail_quote">On Wed, Dec =
28, 2011 at 6:19 AM, Pasi K=E4rkk=E4inen <span dir=3D"ltr">&lt;<a href=3D"m=
ailto:pasik@iki.fi">pasik@iki.fi</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">On Mon, Dec 19, 2011 at 12:57:43PM +0100, Fl=
orian Heigl wrote:<br>
&gt; Hi,<br>
&gt;<br>
<br>
Hello,<br>
<div class=3D"im"><br>
&gt; 2011/12/17 =A0&lt;<a href=3D"mailto:mark@internecto.net">mark@internec=
to.net</a>&gt;:<br>
&gt; &gt; While using xen 4.1-testing.hg (r23202) I noticed that the &#39;v=
ifname&#39;<br>
&gt; &gt; config value is not handled by xl, but is handled by xm. Is there=
 a<br>
&gt; &gt; workaround or patch for this? My firewall and scripts depend on s=
tatic<br>
&gt; &gt; vifnames.<br>
&gt;<br>
&gt; xl does not support vifname as of now.<br>
&gt; Except for one type of HVM domU, where it does support vifname.<br>
&gt;<br>
&gt; You might want to communicate to xen-devel that you rely on it and all=
 that.<br>
&gt;<br>
<br>
</div>Added xen-devel to CC list ..<br>
<div class=3D"im"><br>
&gt; I also think I need vifname support - it&#39;s unbearable to work with=
out<br>
&gt; vifnames if you run a setup with potentially many 100 vifs + vlans +<b=
r>
&gt; brides + bonds.<br>
&gt; (I guess thats how the whole UUID disaster in XenServer happened)<br>
&gt;<br>
&gt; I said &quot;think I need&quot; because I DO rely on them, but maybe s=
omething<br>
&gt; happens that makes me suddenly understand that it&#39;s better to scri=
pt<br>
&gt; against some API to get the information reliably without any problem<b=
r>
&gt; by changing domIDs and always being up-to-date.<br>
&gt; Oh wait, that would be like setting vifname and just looking at the<br=
>
&gt; ifconfig output :)<br>
&gt;<br>
&gt;<br>
&gt; Florian<br>
&gt;<br>
&gt; --<br>
&gt; the purpose of libvirt is to provide an abstraction layer hiding all<b=
r>
&gt; xen features added since 2006 until they were finally understood and<b=
r>
&gt; copied by the kvm devs.<br>
&gt;<br>
<br>
</div>-- Pasi<br>
<br>
<br>
_______________________________________________<br>
Xen-devel mailing list<br>
<a href=3D"mailto:Xen-devel@lists.xensource.com">Xen-devel@lists.xensource.=
com</a><br>
<a href=3D"http://lists.xensource.com/xen-devel" target=3D"_blank">http://l=
ists.xensource.com/xen-devel</a><br>
</blockquote></div><br>

--14dae9340e6539440704b5276ab0--


--===============9082571629766551714==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============9082571629766551714==--


From xen-devel-bounces@lists.xensource.com Wed Dec 28 14:00:52 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 28 Dec 2011 14:00:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rfu34-0004lA-N6; Wed, 28 Dec 2011 14:00:06 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tknchris@gmail.com>)
	id 1Rfu33-0004h9-Ds; Wed, 28 Dec 2011 14:00:05 +0000
X-Env-Sender: tknchris@gmail.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1325080744!58850965!1
X-Originating-IP: [209.85.214.171]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29225 invoked from network); 28 Dec 2011 13:59:06 -0000
Received: from mail-tul01m020-f171.google.com (HELO
	mail-tul01m020-f171.google.com) (209.85.214.171)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Dec 2011 13:59:06 -0000
Received: by obbwd20 with SMTP id wd20so33847312obb.30
	for <multiple recipients>; Wed, 28 Dec 2011 05:59:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=2iiUwgunYByUN7zMDHR6+cqVdsmYCflfCK7FVM0+Pqo=;
	b=XUPvNTJYpWFlktPRtBUnEWSYXZ7HGIBhHvAGIgRJNamIQ2GPivXJgGL4OswrS/wdEF
	cN6bRPo549e6FU5ntBtvREeAaoUoKlvXF2JU290h3CbzKxlBWoyfkZVo9cG7Lf3SY5eo
	zVtFEULN2iiyanfD33KwCfInUxWJKOALn6IsY=
MIME-Version: 1.0
Received: by 10.50.182.130 with SMTP id ee2mr35970386igc.30.1325080797332;
	Wed, 28 Dec 2011 05:59:57 -0800 (PST)
Received: by 10.42.144.197 with HTTP; Wed, 28 Dec 2011 05:59:57 -0800 (PST)
In-Reply-To: <20111228111918.GN12984@reaktio.net>
References: <20111217135342.DDB9E3806B9@mx1.internecto.net>
	<CAFivhP=Uw=e8M_JsE2_fRpT5KtqYuKEf_Jdm2aEQz17iT_vHMw@mail.gmail.com>
	<20111228111918.GN12984@reaktio.net>
Date: Wed, 28 Dec 2011 08:59:57 -0500
Message-ID: <CAKnNFz8sHNvKEyF=oRci6rwO6a82XS3x9AJMACPdu3_qTSx8Dg@mail.gmail.com>
From: chris <tknchris@gmail.com>
To: =?ISO-8859-1?Q?Pasi_K=E4rkk=E4inen?= <pasik@iki.fi>
Cc: Florian Heigl <florian.heigl@gmail.com>, xen-devel@lists.xensource.com,
	xen-users@lists.xensource.com, mark@internecto.net
Subject: Re: [Xen-devel] [Xen-users] xl and vifname
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============9082571629766551714=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============9082571629766551714==
Content-Type: multipart/alternative; boundary=14dae9340e6539440704b5276ab0

--14dae9340e6539440704b5276ab0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

+1 to using vifname pretty heavily, sure you can get the job done without
but why suffer needlessly? :)

On Wed, Dec 28, 2011 at 6:19 AM, Pasi K=E4rkk=E4inen <pasik@iki.fi> wrote:

> On Mon, Dec 19, 2011 at 12:57:43PM +0100, Florian Heigl wrote:
> > Hi,
> >
>
> Hello,
>
> > 2011/12/17  <mark@internecto.net>:
> > > While using xen 4.1-testing.hg (r23202) I noticed that the 'vifname'
> > > config value is not handled by xl, but is handled by xm. Is there a
> > > workaround or patch for this? My firewall and scripts depend on stati=
c
> > > vifnames.
> >
> > xl does not support vifname as of now.
> > Except for one type of HVM domU, where it does support vifname.
> >
> > You might want to communicate to xen-devel that you rely on it and all
> that.
> >
>
> Added xen-devel to CC list ..
>
> > I also think I need vifname support - it's unbearable to work without
> > vifnames if you run a setup with potentially many 100 vifs + vlans +
> > brides + bonds.
> > (I guess thats how the whole UUID disaster in XenServer happened)
> >
> > I said "think I need" because I DO rely on them, but maybe something
> > happens that makes me suddenly understand that it's better to script
> > against some API to get the information reliably without any problem
> > by changing domIDs and always being up-to-date.
> > Oh wait, that would be like setting vifname and just looking at the
> > ifconfig output :)
> >
> >
> > Florian
> >
> > --
> > the purpose of libvirt is to provide an abstraction layer hiding all
> > xen features added since 2006 until they were finally understood and
> > copied by the kvm devs.
> >
>
> -- Pasi
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>

--14dae9340e6539440704b5276ab0
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

+1 to using vifname pretty heavily, sure you can get the job done without b=
ut why suffer needlessly? :)<br><br><div class=3D"gmail_quote">On Wed, Dec =
28, 2011 at 6:19 AM, Pasi K=E4rkk=E4inen <span dir=3D"ltr">&lt;<a href=3D"m=
ailto:pasik@iki.fi">pasik@iki.fi</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">On Mon, Dec 19, 2011 at 12:57:43PM +0100, Fl=
orian Heigl wrote:<br>
&gt; Hi,<br>
&gt;<br>
<br>
Hello,<br>
<div class=3D"im"><br>
&gt; 2011/12/17 =A0&lt;<a href=3D"mailto:mark@internecto.net">mark@internec=
to.net</a>&gt;:<br>
&gt; &gt; While using xen 4.1-testing.hg (r23202) I noticed that the &#39;v=
ifname&#39;<br>
&gt; &gt; config value is not handled by xl, but is handled by xm. Is there=
 a<br>
&gt; &gt; workaround or patch for this? My firewall and scripts depend on s=
tatic<br>
&gt; &gt; vifnames.<br>
&gt;<br>
&gt; xl does not support vifname as of now.<br>
&gt; Except for one type of HVM domU, where it does support vifname.<br>
&gt;<br>
&gt; You might want to communicate to xen-devel that you rely on it and all=
 that.<br>
&gt;<br>
<br>
</div>Added xen-devel to CC list ..<br>
<div class=3D"im"><br>
&gt; I also think I need vifname support - it&#39;s unbearable to work with=
out<br>
&gt; vifnames if you run a setup with potentially many 100 vifs + vlans +<b=
r>
&gt; brides + bonds.<br>
&gt; (I guess thats how the whole UUID disaster in XenServer happened)<br>
&gt;<br>
&gt; I said &quot;think I need&quot; because I DO rely on them, but maybe s=
omething<br>
&gt; happens that makes me suddenly understand that it&#39;s better to scri=
pt<br>
&gt; against some API to get the information reliably without any problem<b=
r>
&gt; by changing domIDs and always being up-to-date.<br>
&gt; Oh wait, that would be like setting vifname and just looking at the<br=
>
&gt; ifconfig output :)<br>
&gt;<br>
&gt;<br>
&gt; Florian<br>
&gt;<br>
&gt; --<br>
&gt; the purpose of libvirt is to provide an abstraction layer hiding all<b=
r>
&gt; xen features added since 2006 until they were finally understood and<b=
r>
&gt; copied by the kvm devs.<br>
&gt;<br>
<br>
</div>-- Pasi<br>
<br>
<br>
_______________________________________________<br>
Xen-devel mailing list<br>
<a href=3D"mailto:Xen-devel@lists.xensource.com">Xen-devel@lists.xensource.=
com</a><br>
<a href=3D"http://lists.xensource.com/xen-devel" target=3D"_blank">http://l=
ists.xensource.com/xen-devel</a><br>
</blockquote></div><br>

--14dae9340e6539440704b5276ab0--


--===============9082571629766551714==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============9082571629766551714==--


From xen-devel-bounces@lists.xensource.com Wed Dec 28 14:20:52 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 28 Dec 2011 14:20:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RfuMY-0005IM-85; Wed, 28 Dec 2011 14:20:14 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <gang.wei@intel.com>) id 1RfuMV-0005IE-WA
	for xen-devel@lists.xensource.com; Wed, 28 Dec 2011 14:20:12 +0000
X-Env-Sender: gang.wei@intel.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1325081960!50569717!1
X-Originating-IP: [143.182.124.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjE2Njkw\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14184 invoked from network); 28 Dec 2011 14:19:20 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-3.tower-27.messagelabs.com with SMTP;
	28 Dec 2011 14:19:20 -0000
Received: from azsmga002.ch.intel.com ([10.2.17.35])
	by azsmga101.ch.intel.com with ESMTP; 28 Dec 2011 06:20:07 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="51295675"
Received: from pgsmsx601.gar.corp.intel.com ([10.221.43.69])
	by AZSMGA002.ch.intel.com with ESMTP; 28 Dec 2011 06:20:06 -0800
Received: from pgsmsx151.gar.corp.intel.com (172.30.236.41) by
	pgsmsx601.gar.corp.intel.com (10.221.43.69) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Wed, 28 Dec 2011 22:20:01 +0800
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	PGSMSX151.gar.corp.intel.com (172.30.236.41) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Wed, 28 Dec 2011 22:20:01 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.38]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.223]) with mapi id
	14.01.0355.002; Wed, 28 Dec 2011 22:19:59 +0800
From: "Wei, Gang" <gang.wei@intel.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Thread-Topic: [PATCH] Update the maitainer list for Intel(R) TXT
Thread-Index: AczFa8dziatnF1BmRGqd9SBrsEQILw==
Date: Wed, 28 Dec 2011 14:19:59 +0000
Message-ID: <D0B11485C64D4B47B66902F8A4E901BEB622@SHSMSX101.ccr.corp.intel.com>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "Wang, Shane" <shane.wang@intel.com>, "Cihula,
	Joseph" <joseph.cihula@intel.com>, "Keir \(Xen.org\)" <keir@xen.org>, "Wei,
	Gang" <gang.wei@intel.com>
Subject: [Xen-devel] [PATCH] Update the maitainer list for Intel(R) TXT
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Update the maitainer list for Intel(R) TXT.

Signed-off-by: Gang Wei <gang.wei@intel.com>

diff -r db5f46d49b9c MAINTAINERS
--- a/MAINTAINERS	Wed Dec 28 14:40:13 2011 +0800
+++ b/MAINTAINERS	Wed Dec 28 22:08:09 2011 +0800
@@ -131,6 +131,7 @@
 
 INTEL(R) TRUSTED EXECUTION TECHNOLOGY (TXT)
 M:	Joseph Cihula <joseph.cihula@intel.com>
+M:	Gang Wei <gang.wei@intel.com>
 M:	Shane Wang <shane.wang@intel.com>
 S:	Supported
 F:	xen/arch/x86/tboot.c

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 28 14:20:52 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 28 Dec 2011 14:20:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RfuMY-0005IM-85; Wed, 28 Dec 2011 14:20:14 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <gang.wei@intel.com>) id 1RfuMV-0005IE-WA
	for xen-devel@lists.xensource.com; Wed, 28 Dec 2011 14:20:12 +0000
X-Env-Sender: gang.wei@intel.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1325081960!50569717!1
X-Originating-IP: [143.182.124.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjE2Njkw\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14184 invoked from network); 28 Dec 2011 14:19:20 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-3.tower-27.messagelabs.com with SMTP;
	28 Dec 2011 14:19:20 -0000
Received: from azsmga002.ch.intel.com ([10.2.17.35])
	by azsmga101.ch.intel.com with ESMTP; 28 Dec 2011 06:20:07 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="51295675"
Received: from pgsmsx601.gar.corp.intel.com ([10.221.43.69])
	by AZSMGA002.ch.intel.com with ESMTP; 28 Dec 2011 06:20:06 -0800
Received: from pgsmsx151.gar.corp.intel.com (172.30.236.41) by
	pgsmsx601.gar.corp.intel.com (10.221.43.69) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Wed, 28 Dec 2011 22:20:01 +0800
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	PGSMSX151.gar.corp.intel.com (172.30.236.41) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Wed, 28 Dec 2011 22:20:01 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.38]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.223]) with mapi id
	14.01.0355.002; Wed, 28 Dec 2011 22:19:59 +0800
From: "Wei, Gang" <gang.wei@intel.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Thread-Topic: [PATCH] Update the maitainer list for Intel(R) TXT
Thread-Index: AczFa8dziatnF1BmRGqd9SBrsEQILw==
Date: Wed, 28 Dec 2011 14:19:59 +0000
Message-ID: <D0B11485C64D4B47B66902F8A4E901BEB622@SHSMSX101.ccr.corp.intel.com>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "Wang, Shane" <shane.wang@intel.com>, "Cihula,
	Joseph" <joseph.cihula@intel.com>, "Keir \(Xen.org\)" <keir@xen.org>, "Wei,
	Gang" <gang.wei@intel.com>
Subject: [Xen-devel] [PATCH] Update the maitainer list for Intel(R) TXT
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Update the maitainer list for Intel(R) TXT.

Signed-off-by: Gang Wei <gang.wei@intel.com>

diff -r db5f46d49b9c MAINTAINERS
--- a/MAINTAINERS	Wed Dec 28 14:40:13 2011 +0800
+++ b/MAINTAINERS	Wed Dec 28 22:08:09 2011 +0800
@@ -131,6 +131,7 @@
 
 INTEL(R) TRUSTED EXECUTION TECHNOLOGY (TXT)
 M:	Joseph Cihula <joseph.cihula@intel.com>
+M:	Gang Wei <gang.wei@intel.com>
 M:	Shane Wang <shane.wang@intel.com>
 S:	Supported
 F:	xen/arch/x86/tboot.c

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 28 14:28:04 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 28 Dec 2011 14: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.xensource.com>)
	id 1RfuTZ-0005RI-4c; Wed, 28 Dec 2011 14:27:29 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <gang.wei@intel.com>) id 1RfuTY-0005RB-1t
	for xen-devel@lists.xensource.com; Wed, 28 Dec 2011 14:27:28 +0000
X-Env-Sender: gang.wei@intel.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1325082440!8987832!1
X-Originating-IP: [143.182.124.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjE2Njkw\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1162 invoked from network); 28 Dec 2011 14:27:21 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-6.tower-216.messagelabs.com with SMTP;
	28 Dec 2011 14:27:21 -0000
Received: from azsmga002.ch.intel.com ([10.2.17.35])
	by azsmga101.ch.intel.com with ESMTP; 28 Dec 2011 06:27:19 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="51297120"
Received: from pgsmsx601.gar.corp.intel.com ([10.221.43.69])
	by AZSMGA002.ch.intel.com with ESMTP; 28 Dec 2011 06:27:18 -0800
Received: from pgsmsx101.gar.corp.intel.com (10.221.44.78) by
	pgsmsx601.gar.corp.intel.com (10.221.43.69) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Wed, 28 Dec 2011 22:24:08 +0800
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	PGSMSX101.gar.corp.intel.com (10.221.44.78) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Wed, 28 Dec 2011 22:24:07 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.38]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.223]) with mapi id
	14.01.0355.002; Wed, 28 Dec 2011 22:24:06 +0800
From: "Wei, Gang" <gang.wei@intel.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Thread-Topic: [PATCH] x86: fix some coding style issues in tboot.c
Thread-Index: AczFbE/i585dAT8qTvql3Of5x97N1A==
Date: Wed, 28 Dec 2011 14:24:06 +0000
Message-ID: <D0B11485C64D4B47B66902F8A4E901BEB646@SHSMSX101.ccr.corp.intel.com>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
Content-Type: multipart/mixed;
	boundary="_002_D0B11485C64D4B47B66902F8A4E901BEB646SHSMSX101ccrcorpint_"
MIME-Version: 1.0
Cc: "Cihula, Joseph" <joseph.cihula@intel.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, "Wei, Gang" <gang.wei@intel.com>
Subject: [Xen-devel] [PATCH] x86: fix some coding style issues in tboot.c
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--_002_D0B11485C64D4B47B66902F8A4E901BEB646SHSMSX101ccrcorpint_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

x86: fix some coding style issues in tboot.c

Signed-off-by: Gang Wei <gang.wei@intel.com>

diff -r fdcd30bf37b4 xen/arch/x86/tboot.c
--- a/xen/arch/x86/tboot.c	Wed Dec 28 10:10:59 2011 +0800
+++ b/xen/arch/x86/tboot.c	Wed Dec 28 10:29:58 2011 +0800
@@ -110,7 +110,8 @@
=20
     /* new tboot_shared (w/ GAS support, integrity, etc.) is not backwards
        compatible */
-    if ( tboot_shared->version < 4 ) {
+    if ( tboot_shared->version < 4 )
+    {
         printk("unsupported version of tboot (%u)\n", tboot_shared->versio=
n);
         return;
     }
@@ -188,8 +189,10 @@
=20
         if ( !mfn_valid(mfn) )
             continue;
-        if ( is_page_in_use(page) && !is_xen_heap_page(page) ) {
-            if ( page->count_info & PGC_page_table ) {
+        if ( is_page_in_use(page) && !is_xen_heap_page(page) )
+        {
+            if ( page->count_info & PGC_page_table )
+            {
                 void *pg =3D map_domain_page(mfn);
                 vmac_update(pg, PAGE_SIZE, ctx);
                 unmap_domain_page(pg);
@@ -283,7 +286,8 @@
                               + 3 * PAGE_SIZE)) )
             continue; /* skip tboot and its page tables */
=20
-        if ( is_page_in_use(page) && is_xen_heap_page(page) ) {
+        if ( is_page_in_use(page) && is_xen_heap_page(page) )
+        {
             void *pg;
=20
             if ( mfn_in_guarded_stack(mfn) )
@@ -344,14 +348,16 @@
=20
     err =3D map_pages_to_xen(map_base << PAGE_SHIFT, map_base, map_size,
                            __PAGE_HYPERVISOR);
-    if ( err !=3D 0 ) {
+    if ( err !=3D 0 )
+    {
         printk("error (0x%x) mapping tboot pages (mfns) @ 0x%x, 0x%x\n", e=
rr,
                map_base, map_size);
         return;
     }
=20
     /* if this is S3 then set regions to MAC */
-    if ( shutdown_type =3D=3D TB_SHUTDOWN_S3 ) {
+    if ( shutdown_type =3D=3D TB_SHUTDOWN_S3 )
+    {
         /*
          * Xen regions for tboot to MAC
          */
@@ -400,26 +406,25 @@
     /* TXT Heap */
     if ( txt_heap_base =3D=3D 0 )
         return 0;
-    rc =3D e820_change_range_type(
-        &e820, txt_heap_base, txt_heap_base + txt_heap_size,
-        E820_RESERVED, E820_UNUSABLE);
+    rc =3D e820_change_range_type(&e820, txt_heap_base,
+                                txt_heap_base + txt_heap_size,
+                                E820_RESERVED, E820_UNUSABLE);
     if ( !rc )
         return 0;
=20
     /* SINIT */
     if ( sinit_base =3D=3D 0 )
         return 0;
-    rc =3D e820_change_range_type(
-        &e820, sinit_base, sinit_base + sinit_size,
-        E820_RESERVED, E820_UNUSABLE);
+    rc =3D e820_change_range_type(&e820, sinit_base,
+                                sinit_base + sinit_size,
+                                E820_RESERVED, E820_UNUSABLE);
     if ( !rc )
         return 0;
=20
     /* TXT Private Space */
-    rc =3D e820_change_range_type(
-        &e820, TXT_PRIV_CONFIG_REGS_BASE,
-        TXT_PRIV_CONFIG_REGS_BASE + NR_TXT_CONFIG_PAGES * PAGE_SIZE,
-        E820_RESERVED, E820_UNUSABLE);
+    rc =3D e820_change_range_type(&e820, TXT_PRIV_CONFIG_REGS_BASE,
+                 TXT_PRIV_CONFIG_REGS_BASE + NR_TXT_CONFIG_PAGES * PAGE_SI=
ZE,
+                 E820_RESERVED, E820_UNUSABLE);
     if ( !rc )
         return 0;
=20
@@ -436,7 +441,6 @@
     sinit_mle_data_t sinit_mle_data;
     unsigned char *dmar_table_raw;
=20
-
     if ( !tboot_in_measured_env() )
         return acpi_table_parse(ACPI_SIG_DMAR, dmar_handler);


--_002_D0B11485C64D4B47B66902F8A4E901BEB646SHSMSX101ccrcorpint_
Content-Type: application/octet-stream; name="tboot-codestyle-fix.patch"
Content-Description: tboot-codestyle-fix.patch
Content-Disposition: attachment; filename="tboot-codestyle-fix.patch";
	size=3432; creation-date="Wed, 28 Dec 2011 14:14:21 GMT";
	modification-date="Wed, 28 Dec 2011 14:05:58 GMT"
Content-Transfer-Encoding: base64

eDg2OiBmaXggc29tZSBjb2Rpbmcgc3R5bGUgaXNzdWVzIGluIHRib290LmMKClNpZ25lZC1vZmYt
Ynk6IEdhbmcgV2VpIDxnYW5nLndlaUBpbnRlbC5jb20+CgpkaWZmIC1yIGZkY2QzMGJmMzdiNCB4
ZW4vYXJjaC94ODYvdGJvb3QuYwotLS0gYS94ZW4vYXJjaC94ODYvdGJvb3QuYwlXZWQgRGVjIDI4
IDEwOjEwOjU5IDIwMTEgKzA4MDAKKysrIGIveGVuL2FyY2gveDg2L3Rib290LmMJV2VkIERlYyAy
OCAxMDoyOTo1OCAyMDExICswODAwCkBAIC0xMTAsNyArMTEwLDggQEAKIAogICAgIC8qIG5ldyB0
Ym9vdF9zaGFyZWQgKHcvIEdBUyBzdXBwb3J0LCBpbnRlZ3JpdHksIGV0Yy4pIGlzIG5vdCBiYWNr
d2FyZHMKICAgICAgICBjb21wYXRpYmxlICovCi0gICAgaWYgKCB0Ym9vdF9zaGFyZWQtPnZlcnNp
b24gPCA0ICkgeworICAgIGlmICggdGJvb3Rfc2hhcmVkLT52ZXJzaW9uIDwgNCApCisgICAgewog
ICAgICAgICBwcmludGsoInVuc3VwcG9ydGVkIHZlcnNpb24gb2YgdGJvb3QgKCV1KVxuIiwgdGJv
b3Rfc2hhcmVkLT52ZXJzaW9uKTsKICAgICAgICAgcmV0dXJuOwogICAgIH0KQEAgLTE4OCw4ICsx
ODksMTAgQEAKIAogICAgICAgICBpZiAoICFtZm5fdmFsaWQobWZuKSApCiAgICAgICAgICAgICBj
b250aW51ZTsKLSAgICAgICAgaWYgKCBpc19wYWdlX2luX3VzZShwYWdlKSAmJiAhaXNfeGVuX2hl
YXBfcGFnZShwYWdlKSApIHsKLSAgICAgICAgICAgIGlmICggcGFnZS0+Y291bnRfaW5mbyAmIFBH
Q19wYWdlX3RhYmxlICkgeworICAgICAgICBpZiAoIGlzX3BhZ2VfaW5fdXNlKHBhZ2UpICYmICFp
c194ZW5faGVhcF9wYWdlKHBhZ2UpICkKKyAgICAgICAgeworICAgICAgICAgICAgaWYgKCBwYWdl
LT5jb3VudF9pbmZvICYgUEdDX3BhZ2VfdGFibGUgKQorICAgICAgICAgICAgewogICAgICAgICAg
ICAgICAgIHZvaWQgKnBnID0gbWFwX2RvbWFpbl9wYWdlKG1mbik7CiAgICAgICAgICAgICAgICAg
dm1hY191cGRhdGUocGcsIFBBR0VfU0laRSwgY3R4KTsKICAgICAgICAgICAgICAgICB1bm1hcF9k
b21haW5fcGFnZShwZyk7CkBAIC0yODMsNyArMjg2LDggQEAKICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICsgMyAqIFBBR0VfU0laRSkpICkKICAgICAgICAgICAgIGNvbnRpbnVlOyAvKiBz
a2lwIHRib290IGFuZCBpdHMgcGFnZSB0YWJsZXMgKi8KIAotICAgICAgICBpZiAoIGlzX3BhZ2Vf
aW5fdXNlKHBhZ2UpICYmIGlzX3hlbl9oZWFwX3BhZ2UocGFnZSkgKSB7CisgICAgICAgIGlmICgg
aXNfcGFnZV9pbl91c2UocGFnZSkgJiYgaXNfeGVuX2hlYXBfcGFnZShwYWdlKSApCisgICAgICAg
IHsKICAgICAgICAgICAgIHZvaWQgKnBnOwogCiAgICAgICAgICAgICBpZiAoIG1mbl9pbl9ndWFy
ZGVkX3N0YWNrKG1mbikgKQpAQCAtMzQ0LDE0ICszNDgsMTYgQEAKIAogICAgIGVyciA9IG1hcF9w
YWdlc190b194ZW4obWFwX2Jhc2UgPDwgUEFHRV9TSElGVCwgbWFwX2Jhc2UsIG1hcF9zaXplLAog
ICAgICAgICAgICAgICAgICAgICAgICAgICAgX19QQUdFX0hZUEVSVklTT1IpOwotICAgIGlmICgg
ZXJyICE9IDAgKSB7CisgICAgaWYgKCBlcnIgIT0gMCApCisgICAgewogICAgICAgICBwcmludGso
ImVycm9yICgweCV4KSBtYXBwaW5nIHRib290IHBhZ2VzIChtZm5zKSBAIDB4JXgsIDB4JXhcbiIs
IGVyciwKICAgICAgICAgICAgICAgIG1hcF9iYXNlLCBtYXBfc2l6ZSk7CiAgICAgICAgIHJldHVy
bjsKICAgICB9CiAKICAgICAvKiBpZiB0aGlzIGlzIFMzIHRoZW4gc2V0IHJlZ2lvbnMgdG8gTUFD
ICovCi0gICAgaWYgKCBzaHV0ZG93bl90eXBlID09IFRCX1NIVVRET1dOX1MzICkgeworICAgIGlm
ICggc2h1dGRvd25fdHlwZSA9PSBUQl9TSFVURE9XTl9TMyApCisgICAgewogICAgICAgICAvKgog
ICAgICAgICAgKiBYZW4gcmVnaW9ucyBmb3IgdGJvb3QgdG8gTUFDCiAgICAgICAgICAqLwpAQCAt
NDAwLDI2ICs0MDYsMjUgQEAKICAgICAvKiBUWFQgSGVhcCAqLwogICAgIGlmICggdHh0X2hlYXBf
YmFzZSA9PSAwICkKICAgICAgICAgcmV0dXJuIDA7Ci0gICAgcmMgPSBlODIwX2NoYW5nZV9yYW5n
ZV90eXBlKAotICAgICAgICAmZTgyMCwgdHh0X2hlYXBfYmFzZSwgdHh0X2hlYXBfYmFzZSArIHR4
dF9oZWFwX3NpemUsCi0gICAgICAgIEU4MjBfUkVTRVJWRUQsIEU4MjBfVU5VU0FCTEUpOworICAg
IHJjID0gZTgyMF9jaGFuZ2VfcmFuZ2VfdHlwZSgmZTgyMCwgdHh0X2hlYXBfYmFzZSwKKyAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgdHh0X2hlYXBfYmFzZSArIHR4dF9oZWFwX3NpemUs
CisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEU4MjBfUkVTRVJWRUQsIEU4MjBfVU5V
U0FCTEUpOwogICAgIGlmICggIXJjICkKICAgICAgICAgcmV0dXJuIDA7CiAKICAgICAvKiBTSU5J
VCAqLwogICAgIGlmICggc2luaXRfYmFzZSA9PSAwICkKICAgICAgICAgcmV0dXJuIDA7Ci0gICAg
cmMgPSBlODIwX2NoYW5nZV9yYW5nZV90eXBlKAotICAgICAgICAmZTgyMCwgc2luaXRfYmFzZSwg
c2luaXRfYmFzZSArIHNpbml0X3NpemUsCi0gICAgICAgIEU4MjBfUkVTRVJWRUQsIEU4MjBfVU5V
U0FCTEUpOworICAgIHJjID0gZTgyMF9jaGFuZ2VfcmFuZ2VfdHlwZSgmZTgyMCwgc2luaXRfYmFz
ZSwKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgc2luaXRfYmFzZSArIHNpbml0X3Np
emUsCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEU4MjBfUkVTRVJWRUQsIEU4MjBf
VU5VU0FCTEUpOwogICAgIGlmICggIXJjICkKICAgICAgICAgcmV0dXJuIDA7CiAKICAgICAvKiBU
WFQgUHJpdmF0ZSBTcGFjZSAqLwotICAgIHJjID0gZTgyMF9jaGFuZ2VfcmFuZ2VfdHlwZSgKLSAg
ICAgICAgJmU4MjAsIFRYVF9QUklWX0NPTkZJR19SRUdTX0JBU0UsCi0gICAgICAgIFRYVF9QUklW
X0NPTkZJR19SRUdTX0JBU0UgKyBOUl9UWFRfQ09ORklHX1BBR0VTICogUEFHRV9TSVpFLAotICAg
ICAgICBFODIwX1JFU0VSVkVELCBFODIwX1VOVVNBQkxFKTsKKyAgICByYyA9IGU4MjBfY2hhbmdl
X3JhbmdlX3R5cGUoJmU4MjAsIFRYVF9QUklWX0NPTkZJR19SRUdTX0JBU0UsCisgICAgICAgICAg
ICAgICAgIFRYVF9QUklWX0NPTkZJR19SRUdTX0JBU0UgKyBOUl9UWFRfQ09ORklHX1BBR0VTICog
UEFHRV9TSVpFLAorICAgICAgICAgICAgICAgICBFODIwX1JFU0VSVkVELCBFODIwX1VOVVNBQkxF
KTsKICAgICBpZiAoICFyYyApCiAgICAgICAgIHJldHVybiAwOwogCkBAIC00MzYsNyArNDQxLDYg
QEAKICAgICBzaW5pdF9tbGVfZGF0YV90IHNpbml0X21sZV9kYXRhOwogICAgIHVuc2lnbmVkIGNo
YXIgKmRtYXJfdGFibGVfcmF3OwogCi0KICAgICBpZiAoICF0Ym9vdF9pbl9tZWFzdXJlZF9lbnYo
KSApCiAgICAgICAgIHJldHVybiBhY3BpX3RhYmxlX3BhcnNlKEFDUElfU0lHX0RNQVIsIGRtYXJf
aGFuZGxlcik7CiAK

--_002_D0B11485C64D4B47B66902F8A4E901BEB646SHSMSX101ccrcorpint_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--_002_D0B11485C64D4B47B66902F8A4E901BEB646SHSMSX101ccrcorpint_--


From xen-devel-bounces@lists.xensource.com Wed Dec 28 14:28:04 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 28 Dec 2011 14: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.xensource.com>)
	id 1RfuTZ-0005RI-4c; Wed, 28 Dec 2011 14:27:29 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <gang.wei@intel.com>) id 1RfuTY-0005RB-1t
	for xen-devel@lists.xensource.com; Wed, 28 Dec 2011 14:27:28 +0000
X-Env-Sender: gang.wei@intel.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1325082440!8987832!1
X-Originating-IP: [143.182.124.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjE2Njkw\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1162 invoked from network); 28 Dec 2011 14:27:21 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-6.tower-216.messagelabs.com with SMTP;
	28 Dec 2011 14:27:21 -0000
Received: from azsmga002.ch.intel.com ([10.2.17.35])
	by azsmga101.ch.intel.com with ESMTP; 28 Dec 2011 06:27:19 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="51297120"
Received: from pgsmsx601.gar.corp.intel.com ([10.221.43.69])
	by AZSMGA002.ch.intel.com with ESMTP; 28 Dec 2011 06:27:18 -0800
Received: from pgsmsx101.gar.corp.intel.com (10.221.44.78) by
	pgsmsx601.gar.corp.intel.com (10.221.43.69) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Wed, 28 Dec 2011 22:24:08 +0800
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	PGSMSX101.gar.corp.intel.com (10.221.44.78) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Wed, 28 Dec 2011 22:24:07 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.38]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.223]) with mapi id
	14.01.0355.002; Wed, 28 Dec 2011 22:24:06 +0800
From: "Wei, Gang" <gang.wei@intel.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Thread-Topic: [PATCH] x86: fix some coding style issues in tboot.c
Thread-Index: AczFbE/i585dAT8qTvql3Of5x97N1A==
Date: Wed, 28 Dec 2011 14:24:06 +0000
Message-ID: <D0B11485C64D4B47B66902F8A4E901BEB646@SHSMSX101.ccr.corp.intel.com>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
Content-Type: multipart/mixed;
	boundary="_002_D0B11485C64D4B47B66902F8A4E901BEB646SHSMSX101ccrcorpint_"
MIME-Version: 1.0
Cc: "Cihula, Joseph" <joseph.cihula@intel.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, "Wei, Gang" <gang.wei@intel.com>
Subject: [Xen-devel] [PATCH] x86: fix some coding style issues in tboot.c
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--_002_D0B11485C64D4B47B66902F8A4E901BEB646SHSMSX101ccrcorpint_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

x86: fix some coding style issues in tboot.c

Signed-off-by: Gang Wei <gang.wei@intel.com>

diff -r fdcd30bf37b4 xen/arch/x86/tboot.c
--- a/xen/arch/x86/tboot.c	Wed Dec 28 10:10:59 2011 +0800
+++ b/xen/arch/x86/tboot.c	Wed Dec 28 10:29:58 2011 +0800
@@ -110,7 +110,8 @@
=20
     /* new tboot_shared (w/ GAS support, integrity, etc.) is not backwards
        compatible */
-    if ( tboot_shared->version < 4 ) {
+    if ( tboot_shared->version < 4 )
+    {
         printk("unsupported version of tboot (%u)\n", tboot_shared->versio=
n);
         return;
     }
@@ -188,8 +189,10 @@
=20
         if ( !mfn_valid(mfn) )
             continue;
-        if ( is_page_in_use(page) && !is_xen_heap_page(page) ) {
-            if ( page->count_info & PGC_page_table ) {
+        if ( is_page_in_use(page) && !is_xen_heap_page(page) )
+        {
+            if ( page->count_info & PGC_page_table )
+            {
                 void *pg =3D map_domain_page(mfn);
                 vmac_update(pg, PAGE_SIZE, ctx);
                 unmap_domain_page(pg);
@@ -283,7 +286,8 @@
                               + 3 * PAGE_SIZE)) )
             continue; /* skip tboot and its page tables */
=20
-        if ( is_page_in_use(page) && is_xen_heap_page(page) ) {
+        if ( is_page_in_use(page) && is_xen_heap_page(page) )
+        {
             void *pg;
=20
             if ( mfn_in_guarded_stack(mfn) )
@@ -344,14 +348,16 @@
=20
     err =3D map_pages_to_xen(map_base << PAGE_SHIFT, map_base, map_size,
                            __PAGE_HYPERVISOR);
-    if ( err !=3D 0 ) {
+    if ( err !=3D 0 )
+    {
         printk("error (0x%x) mapping tboot pages (mfns) @ 0x%x, 0x%x\n", e=
rr,
                map_base, map_size);
         return;
     }
=20
     /* if this is S3 then set regions to MAC */
-    if ( shutdown_type =3D=3D TB_SHUTDOWN_S3 ) {
+    if ( shutdown_type =3D=3D TB_SHUTDOWN_S3 )
+    {
         /*
          * Xen regions for tboot to MAC
          */
@@ -400,26 +406,25 @@
     /* TXT Heap */
     if ( txt_heap_base =3D=3D 0 )
         return 0;
-    rc =3D e820_change_range_type(
-        &e820, txt_heap_base, txt_heap_base + txt_heap_size,
-        E820_RESERVED, E820_UNUSABLE);
+    rc =3D e820_change_range_type(&e820, txt_heap_base,
+                                txt_heap_base + txt_heap_size,
+                                E820_RESERVED, E820_UNUSABLE);
     if ( !rc )
         return 0;
=20
     /* SINIT */
     if ( sinit_base =3D=3D 0 )
         return 0;
-    rc =3D e820_change_range_type(
-        &e820, sinit_base, sinit_base + sinit_size,
-        E820_RESERVED, E820_UNUSABLE);
+    rc =3D e820_change_range_type(&e820, sinit_base,
+                                sinit_base + sinit_size,
+                                E820_RESERVED, E820_UNUSABLE);
     if ( !rc )
         return 0;
=20
     /* TXT Private Space */
-    rc =3D e820_change_range_type(
-        &e820, TXT_PRIV_CONFIG_REGS_BASE,
-        TXT_PRIV_CONFIG_REGS_BASE + NR_TXT_CONFIG_PAGES * PAGE_SIZE,
-        E820_RESERVED, E820_UNUSABLE);
+    rc =3D e820_change_range_type(&e820, TXT_PRIV_CONFIG_REGS_BASE,
+                 TXT_PRIV_CONFIG_REGS_BASE + NR_TXT_CONFIG_PAGES * PAGE_SI=
ZE,
+                 E820_RESERVED, E820_UNUSABLE);
     if ( !rc )
         return 0;
=20
@@ -436,7 +441,6 @@
     sinit_mle_data_t sinit_mle_data;
     unsigned char *dmar_table_raw;
=20
-
     if ( !tboot_in_measured_env() )
         return acpi_table_parse(ACPI_SIG_DMAR, dmar_handler);


--_002_D0B11485C64D4B47B66902F8A4E901BEB646SHSMSX101ccrcorpint_
Content-Type: application/octet-stream; name="tboot-codestyle-fix.patch"
Content-Description: tboot-codestyle-fix.patch
Content-Disposition: attachment; filename="tboot-codestyle-fix.patch";
	size=3432; creation-date="Wed, 28 Dec 2011 14:14:21 GMT";
	modification-date="Wed, 28 Dec 2011 14:05:58 GMT"
Content-Transfer-Encoding: base64

eDg2OiBmaXggc29tZSBjb2Rpbmcgc3R5bGUgaXNzdWVzIGluIHRib290LmMKClNpZ25lZC1vZmYt
Ynk6IEdhbmcgV2VpIDxnYW5nLndlaUBpbnRlbC5jb20+CgpkaWZmIC1yIGZkY2QzMGJmMzdiNCB4
ZW4vYXJjaC94ODYvdGJvb3QuYwotLS0gYS94ZW4vYXJjaC94ODYvdGJvb3QuYwlXZWQgRGVjIDI4
IDEwOjEwOjU5IDIwMTEgKzA4MDAKKysrIGIveGVuL2FyY2gveDg2L3Rib290LmMJV2VkIERlYyAy
OCAxMDoyOTo1OCAyMDExICswODAwCkBAIC0xMTAsNyArMTEwLDggQEAKIAogICAgIC8qIG5ldyB0
Ym9vdF9zaGFyZWQgKHcvIEdBUyBzdXBwb3J0LCBpbnRlZ3JpdHksIGV0Yy4pIGlzIG5vdCBiYWNr
d2FyZHMKICAgICAgICBjb21wYXRpYmxlICovCi0gICAgaWYgKCB0Ym9vdF9zaGFyZWQtPnZlcnNp
b24gPCA0ICkgeworICAgIGlmICggdGJvb3Rfc2hhcmVkLT52ZXJzaW9uIDwgNCApCisgICAgewog
ICAgICAgICBwcmludGsoInVuc3VwcG9ydGVkIHZlcnNpb24gb2YgdGJvb3QgKCV1KVxuIiwgdGJv
b3Rfc2hhcmVkLT52ZXJzaW9uKTsKICAgICAgICAgcmV0dXJuOwogICAgIH0KQEAgLTE4OCw4ICsx
ODksMTAgQEAKIAogICAgICAgICBpZiAoICFtZm5fdmFsaWQobWZuKSApCiAgICAgICAgICAgICBj
b250aW51ZTsKLSAgICAgICAgaWYgKCBpc19wYWdlX2luX3VzZShwYWdlKSAmJiAhaXNfeGVuX2hl
YXBfcGFnZShwYWdlKSApIHsKLSAgICAgICAgICAgIGlmICggcGFnZS0+Y291bnRfaW5mbyAmIFBH
Q19wYWdlX3RhYmxlICkgeworICAgICAgICBpZiAoIGlzX3BhZ2VfaW5fdXNlKHBhZ2UpICYmICFp
c194ZW5faGVhcF9wYWdlKHBhZ2UpICkKKyAgICAgICAgeworICAgICAgICAgICAgaWYgKCBwYWdl
LT5jb3VudF9pbmZvICYgUEdDX3BhZ2VfdGFibGUgKQorICAgICAgICAgICAgewogICAgICAgICAg
ICAgICAgIHZvaWQgKnBnID0gbWFwX2RvbWFpbl9wYWdlKG1mbik7CiAgICAgICAgICAgICAgICAg
dm1hY191cGRhdGUocGcsIFBBR0VfU0laRSwgY3R4KTsKICAgICAgICAgICAgICAgICB1bm1hcF9k
b21haW5fcGFnZShwZyk7CkBAIC0yODMsNyArMjg2LDggQEAKICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICsgMyAqIFBBR0VfU0laRSkpICkKICAgICAgICAgICAgIGNvbnRpbnVlOyAvKiBz
a2lwIHRib290IGFuZCBpdHMgcGFnZSB0YWJsZXMgKi8KIAotICAgICAgICBpZiAoIGlzX3BhZ2Vf
aW5fdXNlKHBhZ2UpICYmIGlzX3hlbl9oZWFwX3BhZ2UocGFnZSkgKSB7CisgICAgICAgIGlmICgg
aXNfcGFnZV9pbl91c2UocGFnZSkgJiYgaXNfeGVuX2hlYXBfcGFnZShwYWdlKSApCisgICAgICAg
IHsKICAgICAgICAgICAgIHZvaWQgKnBnOwogCiAgICAgICAgICAgICBpZiAoIG1mbl9pbl9ndWFy
ZGVkX3N0YWNrKG1mbikgKQpAQCAtMzQ0LDE0ICszNDgsMTYgQEAKIAogICAgIGVyciA9IG1hcF9w
YWdlc190b194ZW4obWFwX2Jhc2UgPDwgUEFHRV9TSElGVCwgbWFwX2Jhc2UsIG1hcF9zaXplLAog
ICAgICAgICAgICAgICAgICAgICAgICAgICAgX19QQUdFX0hZUEVSVklTT1IpOwotICAgIGlmICgg
ZXJyICE9IDAgKSB7CisgICAgaWYgKCBlcnIgIT0gMCApCisgICAgewogICAgICAgICBwcmludGso
ImVycm9yICgweCV4KSBtYXBwaW5nIHRib290IHBhZ2VzIChtZm5zKSBAIDB4JXgsIDB4JXhcbiIs
IGVyciwKICAgICAgICAgICAgICAgIG1hcF9iYXNlLCBtYXBfc2l6ZSk7CiAgICAgICAgIHJldHVy
bjsKICAgICB9CiAKICAgICAvKiBpZiB0aGlzIGlzIFMzIHRoZW4gc2V0IHJlZ2lvbnMgdG8gTUFD
ICovCi0gICAgaWYgKCBzaHV0ZG93bl90eXBlID09IFRCX1NIVVRET1dOX1MzICkgeworICAgIGlm
ICggc2h1dGRvd25fdHlwZSA9PSBUQl9TSFVURE9XTl9TMyApCisgICAgewogICAgICAgICAvKgog
ICAgICAgICAgKiBYZW4gcmVnaW9ucyBmb3IgdGJvb3QgdG8gTUFDCiAgICAgICAgICAqLwpAQCAt
NDAwLDI2ICs0MDYsMjUgQEAKICAgICAvKiBUWFQgSGVhcCAqLwogICAgIGlmICggdHh0X2hlYXBf
YmFzZSA9PSAwICkKICAgICAgICAgcmV0dXJuIDA7Ci0gICAgcmMgPSBlODIwX2NoYW5nZV9yYW5n
ZV90eXBlKAotICAgICAgICAmZTgyMCwgdHh0X2hlYXBfYmFzZSwgdHh0X2hlYXBfYmFzZSArIHR4
dF9oZWFwX3NpemUsCi0gICAgICAgIEU4MjBfUkVTRVJWRUQsIEU4MjBfVU5VU0FCTEUpOworICAg
IHJjID0gZTgyMF9jaGFuZ2VfcmFuZ2VfdHlwZSgmZTgyMCwgdHh0X2hlYXBfYmFzZSwKKyAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgdHh0X2hlYXBfYmFzZSArIHR4dF9oZWFwX3NpemUs
CisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEU4MjBfUkVTRVJWRUQsIEU4MjBfVU5V
U0FCTEUpOwogICAgIGlmICggIXJjICkKICAgICAgICAgcmV0dXJuIDA7CiAKICAgICAvKiBTSU5J
VCAqLwogICAgIGlmICggc2luaXRfYmFzZSA9PSAwICkKICAgICAgICAgcmV0dXJuIDA7Ci0gICAg
cmMgPSBlODIwX2NoYW5nZV9yYW5nZV90eXBlKAotICAgICAgICAmZTgyMCwgc2luaXRfYmFzZSwg
c2luaXRfYmFzZSArIHNpbml0X3NpemUsCi0gICAgICAgIEU4MjBfUkVTRVJWRUQsIEU4MjBfVU5V
U0FCTEUpOworICAgIHJjID0gZTgyMF9jaGFuZ2VfcmFuZ2VfdHlwZSgmZTgyMCwgc2luaXRfYmFz
ZSwKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgc2luaXRfYmFzZSArIHNpbml0X3Np
emUsCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEU4MjBfUkVTRVJWRUQsIEU4MjBf
VU5VU0FCTEUpOwogICAgIGlmICggIXJjICkKICAgICAgICAgcmV0dXJuIDA7CiAKICAgICAvKiBU
WFQgUHJpdmF0ZSBTcGFjZSAqLwotICAgIHJjID0gZTgyMF9jaGFuZ2VfcmFuZ2VfdHlwZSgKLSAg
ICAgICAgJmU4MjAsIFRYVF9QUklWX0NPTkZJR19SRUdTX0JBU0UsCi0gICAgICAgIFRYVF9QUklW
X0NPTkZJR19SRUdTX0JBU0UgKyBOUl9UWFRfQ09ORklHX1BBR0VTICogUEFHRV9TSVpFLAotICAg
ICAgICBFODIwX1JFU0VSVkVELCBFODIwX1VOVVNBQkxFKTsKKyAgICByYyA9IGU4MjBfY2hhbmdl
X3JhbmdlX3R5cGUoJmU4MjAsIFRYVF9QUklWX0NPTkZJR19SRUdTX0JBU0UsCisgICAgICAgICAg
ICAgICAgIFRYVF9QUklWX0NPTkZJR19SRUdTX0JBU0UgKyBOUl9UWFRfQ09ORklHX1BBR0VTICog
UEFHRV9TSVpFLAorICAgICAgICAgICAgICAgICBFODIwX1JFU0VSVkVELCBFODIwX1VOVVNBQkxF
KTsKICAgICBpZiAoICFyYyApCiAgICAgICAgIHJldHVybiAwOwogCkBAIC00MzYsNyArNDQxLDYg
QEAKICAgICBzaW5pdF9tbGVfZGF0YV90IHNpbml0X21sZV9kYXRhOwogICAgIHVuc2lnbmVkIGNo
YXIgKmRtYXJfdGFibGVfcmF3OwogCi0KICAgICBpZiAoICF0Ym9vdF9pbl9tZWFzdXJlZF9lbnYo
KSApCiAgICAgICAgIHJldHVybiBhY3BpX3RhYmxlX3BhcnNlKEFDUElfU0lHX0RNQVIsIGRtYXJf
aGFuZGxlcik7CiAK

--_002_D0B11485C64D4B47B66902F8A4E901BEB646SHSMSX101ccrcorpint_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--_002_D0B11485C64D4B47B66902F8A4E901BEB646SHSMSX101ccrcorpint_--


From xen-devel-bounces@lists.xensource.com Wed Dec 28 14:31:58 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 28 Dec 2011 14: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.xensource.com>)
	id 1RfuXU-0005fK-VS; Wed, 28 Dec 2011 14:31:32 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andy@strugglers.net>) id 1RfuXS-0005f8-TV
	for xen-devel@lists.xensource.com; Wed, 28 Dec 2011 14:31:31 +0000
X-Env-Sender: andy@strugglers.net
X-Msg-Ref: server-13.tower-182.messagelabs.com!1325082684!8337194!1
X-Originating-IP: [85.119.80.223]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17891 invoked from network); 28 Dec 2011 14:31:25 -0000
Received: from bitfolk.com (HELO mail.bitfolk.com) (85.119.80.223)
	by server-13.tower-182.messagelabs.com with AES256-SHA encrypted SMTP;
	28 Dec 2011 14:31:25 -0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bitfolk.com;
	s=alpha; 
	h=Subject:In-Reply-To:Content-Transfer-Encoding:Content-Type:MIME-Version:References:Message-ID:To:From:Date;
	bh=6UZW+G6wrpFR8m26nJ0SSLSlJv/4+EPdmlKNOdBRKYE=; 
	b=Q2STylug0Z0V2RFmDV9sZ4qKJZSpPMru1tyKRFK7XIg1NgxgNvMfK2fi0grm75Cz0OMSSL1PC7s5BgkzTfaqxoNGM3NOAmA2MPA/xG8QdFU3xi/tdvSoAmC8U1iRJ/8t;
Received: from andy by mail.bitfolk.com with local (Exim 4.72)
	(envelope-from <andy@strugglers.net>) id 1RfuXM-0000aJ-Bk
	for xen-devel@lists.xensource.com; Wed, 28 Dec 2011 14:31:24 +0000
Date: Wed, 28 Dec 2011 14:31:24 +0000
From: Andy Smith <andy@strugglers.net>
To: xen-devel@lists.xensource.com
Message-ID: <20111228143123.GB4221@bitfolk.com>
References: <20111217135342.DDB9E3806B9@mx1.internecto.net>
	<CAFivhP=Uw=e8M_JsE2_fRpT5KtqYuKEf_Jdm2aEQz17iT_vHMw@mail.gmail.com>
	<20111228111918.GN12984@reaktio.net>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20111228111918.GN12984@reaktio.net>
OpenPGP: id=BF15490B; url=http://strugglers.net/~andy/pubkey.asc
X-URL: http://strugglers.net/wiki/User:Andy
User-Agent: Mutt/1.5.18 (2008-05-17)
X-Virus-Scanner: Scanned by ClamAV on mail.bitfolk.com at Wed,
	28 Dec 2011 14:31:24 +0000
X-SA-Exim-Connect-IP: <locally generated>
X-SA-Exim-Mail-From: andy@strugglers.net
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	spamd3.lon.bitfolk.com
X-Spam-Level: 
X-Spam-ASN: 
X-Spam-Status: No, score=-0.0 required=5.0 tests=NO_RELAYS shortcircuit=no
	autolearn=disabled version=3.3.1
X-Spam-Report: * -0.0 NO_RELAYS Informational: message was not relayed via SMTP
X-SA-Exim-Version: 4.2.1 (built Wed, 25 Jun 2008 17:14:11 +0000)
X-SA-Exim-Scanned: Yes (on mail.bitfolk.com)
Subject: Re: [Xen-devel] [Xen-users] xl and vifname
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hello,

On Wed, Dec 28, 2011 at 01:19:18PM +0200, Pasi K=E4rkk=E4inen wrote:
> On Mon, Dec 19, 2011 at 12:57:43PM +0100, Florian Heigl wrote:
> > xl does not support vifname as of now.
> > Except for one type of HVM domU, where it does support vifname.
> > =

> > You might want to communicate to xen-devel that you rely on it and all =
that.

Ditto here, being able to give a vif a specific name is required.

Cheers,
Andy

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 28 14:31:58 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 28 Dec 2011 14: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.xensource.com>)
	id 1RfuXU-0005fK-VS; Wed, 28 Dec 2011 14:31:32 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andy@strugglers.net>) id 1RfuXS-0005f8-TV
	for xen-devel@lists.xensource.com; Wed, 28 Dec 2011 14:31:31 +0000
X-Env-Sender: andy@strugglers.net
X-Msg-Ref: server-13.tower-182.messagelabs.com!1325082684!8337194!1
X-Originating-IP: [85.119.80.223]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17891 invoked from network); 28 Dec 2011 14:31:25 -0000
Received: from bitfolk.com (HELO mail.bitfolk.com) (85.119.80.223)
	by server-13.tower-182.messagelabs.com with AES256-SHA encrypted SMTP;
	28 Dec 2011 14:31:25 -0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bitfolk.com;
	s=alpha; 
	h=Subject:In-Reply-To:Content-Transfer-Encoding:Content-Type:MIME-Version:References:Message-ID:To:From:Date;
	bh=6UZW+G6wrpFR8m26nJ0SSLSlJv/4+EPdmlKNOdBRKYE=; 
	b=Q2STylug0Z0V2RFmDV9sZ4qKJZSpPMru1tyKRFK7XIg1NgxgNvMfK2fi0grm75Cz0OMSSL1PC7s5BgkzTfaqxoNGM3NOAmA2MPA/xG8QdFU3xi/tdvSoAmC8U1iRJ/8t;
Received: from andy by mail.bitfolk.com with local (Exim 4.72)
	(envelope-from <andy@strugglers.net>) id 1RfuXM-0000aJ-Bk
	for xen-devel@lists.xensource.com; Wed, 28 Dec 2011 14:31:24 +0000
Date: Wed, 28 Dec 2011 14:31:24 +0000
From: Andy Smith <andy@strugglers.net>
To: xen-devel@lists.xensource.com
Message-ID: <20111228143123.GB4221@bitfolk.com>
References: <20111217135342.DDB9E3806B9@mx1.internecto.net>
	<CAFivhP=Uw=e8M_JsE2_fRpT5KtqYuKEf_Jdm2aEQz17iT_vHMw@mail.gmail.com>
	<20111228111918.GN12984@reaktio.net>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20111228111918.GN12984@reaktio.net>
OpenPGP: id=BF15490B; url=http://strugglers.net/~andy/pubkey.asc
X-URL: http://strugglers.net/wiki/User:Andy
User-Agent: Mutt/1.5.18 (2008-05-17)
X-Virus-Scanner: Scanned by ClamAV on mail.bitfolk.com at Wed,
	28 Dec 2011 14:31:24 +0000
X-SA-Exim-Connect-IP: <locally generated>
X-SA-Exim-Mail-From: andy@strugglers.net
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	spamd3.lon.bitfolk.com
X-Spam-Level: 
X-Spam-ASN: 
X-Spam-Status: No, score=-0.0 required=5.0 tests=NO_RELAYS shortcircuit=no
	autolearn=disabled version=3.3.1
X-Spam-Report: * -0.0 NO_RELAYS Informational: message was not relayed via SMTP
X-SA-Exim-Version: 4.2.1 (built Wed, 25 Jun 2008 17:14:11 +0000)
X-SA-Exim-Scanned: Yes (on mail.bitfolk.com)
Subject: Re: [Xen-devel] [Xen-users] xl and vifname
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hello,

On Wed, Dec 28, 2011 at 01:19:18PM +0200, Pasi K=E4rkk=E4inen wrote:
> On Mon, Dec 19, 2011 at 12:57:43PM +0100, Florian Heigl wrote:
> > xl does not support vifname as of now.
> > Except for one type of HVM domU, where it does support vifname.
> > =

> > You might want to communicate to xen-devel that you rely on it and all =
that.

Ditto here, being able to give a vif a specific name is required.

Cheers,
Andy

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 28 15:03:37 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 28 Dec 2011 15:03:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rfv20-0005ym-NC; Wed, 28 Dec 2011 15:03:04 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1Rfv1z-0005yb-CR
	for xen-devel@lists.xensource.com; Wed, 28 Dec 2011 15:03:03 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1325084576!7859858!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwMQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18342 invoked from network); 28 Dec 2011 15:02:57 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Dec 2011 15:02:57 -0000
X-IronPort-AV: E=Sophos;i="4.71,421,1320624000"; 
   d="scan'208";a="9721798"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Dec 2011 15:02:56 +0000
Received: from [10.80.2.50] (10.80.2.50) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 28 Dec 2011 15:02:56 +0000
Message-ID: <1325084532.24422.8.camel@liuw-desktop>
From: Wei Liu <wei.liu2@citrix.com>
To: Andy Smith <andy@strugglers.net>
Date: Wed, 28 Dec 2011 15:02:12 +0000
In-Reply-To: <20111228143123.GB4221@bitfolk.com>
References: <20111217135342.DDB9E3806B9@mx1.internecto.net>
	<CAFivhP=Uw=e8M_JsE2_fRpT5KtqYuKEf_Jdm2aEQz17iT_vHMw@mail.gmail.com>
	<20111228111918.GN12984@reaktio.net>
	<20111228143123.GB4221@bitfolk.com>
X-Mailer: Evolution 3.2.1- 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	wei.liu2@citrix.com
Subject: Re: [Xen-devel] [Xen-users] xl and vifname
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gV2VkLCAyMDExLTEyLTI4IGF0IDE0OjMxICswMDAwLCBBbmR5IFNtaXRoIHdyb3RlOgo+IEhl
bGxvLAo+IAo+IE9uIFdlZCwgRGVjIDI4LCAyMDExIGF0IDAxOjE5OjE4UE0gKzAyMDAsIFBhc2kg
S8Okcmtrw6RpbmVuIHdyb3RlOgo+ID4gT24gTW9uLCBEZWMgMTksIDIwMTEgYXQgMTI6NTc6NDNQ
TSArMDEwMCwgRmxvcmlhbiBIZWlnbCB3cm90ZToKPiA+ID4geGwgZG9lcyBub3Qgc3VwcG9ydCB2
aWZuYW1lIGFzIG9mIG5vdy4KPiA+ID4gRXhjZXB0IGZvciBvbmUgdHlwZSBvZiBIVk0gZG9tVSwg
d2hlcmUgaXQgZG9lcyBzdXBwb3J0IHZpZm5hbWUuCj4gPiA+IAo+ID4gPiBZb3UgbWlnaHQgd2Fu
dCB0byBjb21tdW5pY2F0ZSB0byB4ZW4tZGV2ZWwgdGhhdCB5b3UgcmVseSBvbiBpdCBhbmQgYWxs
IHRoYXQuCj4gCj4gRGl0dG8gaGVyZSwgYmVpbmcgYWJsZSB0byBnaXZlIGEgdmlmIGEgc3BlY2lm
aWMgbmFtZSBpcyByZXF1aXJlZC4KCkknbSBhIGJpdCBjb25mdXNlZC4geGwgcGFyc2VzICd2aWYn
IG5hbWVzIGZvciBib3RoIEhWTSBhbmQgUFYgZ3Vlc3QuIEkKdGhpbmsgeW91J3JlIHVzaW5nIFFF
TVUgYXMgbmV0d29yayBiYWNrZW5kIHdoZW4geW91IHJ1biBIVk0gZ3Vlc3Q/CgpXZWxsIGlmIGJh
Y2tlbmQgaXMgbmV0YmFjaywgdGhlIHZpZiBuYW1lIGlzIGhhcmRjb2RlZCBhcyAidmlmJWQuJWQi
IC0tCnNlZSAkS0VSTkVML2RyaXZlcnMvbmV0L3hlbi1uZXRiYWNrL2ludGVyZmFjZS5jOnhlbnZp
Zl9hbGxvYy4geGwgaGFzCm5vdGhpbmcgdG8gZG8gd2l0aCB0aGlzIGJlY2F1c2UgdGhlIGNyZWF0
aW9uIG9mIHZpZiBpcyBhdXRvbWF0aWNhbGx5CmRvbmUgd2hlbiBGRSBjb25uZWN0cyB0byBCRS4K
CkEgcG9zc2libGUgc29sdXRpb24gaXMgdGhhdCB3ZSB3cml0ZSB1c2VyLXNwZWNpZmllZCB2aWZu
YW1lIGluIHhlbnN0b3JlCmVudHJ5IHRoZW4gQkUgcmV0cmlldmUgdGhlIHZhbHVlIGFuZCB1c2Ug
dGhlIHZhbHVlIGFzIHZpZiBuYW1lLgoKCldlaS4KCgpfX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBs
aXN0cy54ZW5zb3VyY2UuY29tCmh0dHA6Ly9saXN0cy54ZW5zb3VyY2UuY29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Wed Dec 28 15:03:37 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 28 Dec 2011 15:03:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rfv20-0005ym-NC; Wed, 28 Dec 2011 15:03:04 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1Rfv1z-0005yb-CR
	for xen-devel@lists.xensource.com; Wed, 28 Dec 2011 15:03:03 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1325084576!7859858!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwMQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18342 invoked from network); 28 Dec 2011 15:02:57 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Dec 2011 15:02:57 -0000
X-IronPort-AV: E=Sophos;i="4.71,421,1320624000"; 
   d="scan'208";a="9721798"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Dec 2011 15:02:56 +0000
Received: from [10.80.2.50] (10.80.2.50) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 28 Dec 2011 15:02:56 +0000
Message-ID: <1325084532.24422.8.camel@liuw-desktop>
From: Wei Liu <wei.liu2@citrix.com>
To: Andy Smith <andy@strugglers.net>
Date: Wed, 28 Dec 2011 15:02:12 +0000
In-Reply-To: <20111228143123.GB4221@bitfolk.com>
References: <20111217135342.DDB9E3806B9@mx1.internecto.net>
	<CAFivhP=Uw=e8M_JsE2_fRpT5KtqYuKEf_Jdm2aEQz17iT_vHMw@mail.gmail.com>
	<20111228111918.GN12984@reaktio.net>
	<20111228143123.GB4221@bitfolk.com>
X-Mailer: Evolution 3.2.1- 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	wei.liu2@citrix.com
Subject: Re: [Xen-devel] [Xen-users] xl and vifname
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gV2VkLCAyMDExLTEyLTI4IGF0IDE0OjMxICswMDAwLCBBbmR5IFNtaXRoIHdyb3RlOgo+IEhl
bGxvLAo+IAo+IE9uIFdlZCwgRGVjIDI4LCAyMDExIGF0IDAxOjE5OjE4UE0gKzAyMDAsIFBhc2kg
S8Okcmtrw6RpbmVuIHdyb3RlOgo+ID4gT24gTW9uLCBEZWMgMTksIDIwMTEgYXQgMTI6NTc6NDNQ
TSArMDEwMCwgRmxvcmlhbiBIZWlnbCB3cm90ZToKPiA+ID4geGwgZG9lcyBub3Qgc3VwcG9ydCB2
aWZuYW1lIGFzIG9mIG5vdy4KPiA+ID4gRXhjZXB0IGZvciBvbmUgdHlwZSBvZiBIVk0gZG9tVSwg
d2hlcmUgaXQgZG9lcyBzdXBwb3J0IHZpZm5hbWUuCj4gPiA+IAo+ID4gPiBZb3UgbWlnaHQgd2Fu
dCB0byBjb21tdW5pY2F0ZSB0byB4ZW4tZGV2ZWwgdGhhdCB5b3UgcmVseSBvbiBpdCBhbmQgYWxs
IHRoYXQuCj4gCj4gRGl0dG8gaGVyZSwgYmVpbmcgYWJsZSB0byBnaXZlIGEgdmlmIGEgc3BlY2lm
aWMgbmFtZSBpcyByZXF1aXJlZC4KCkknbSBhIGJpdCBjb25mdXNlZC4geGwgcGFyc2VzICd2aWYn
IG5hbWVzIGZvciBib3RoIEhWTSBhbmQgUFYgZ3Vlc3QuIEkKdGhpbmsgeW91J3JlIHVzaW5nIFFF
TVUgYXMgbmV0d29yayBiYWNrZW5kIHdoZW4geW91IHJ1biBIVk0gZ3Vlc3Q/CgpXZWxsIGlmIGJh
Y2tlbmQgaXMgbmV0YmFjaywgdGhlIHZpZiBuYW1lIGlzIGhhcmRjb2RlZCBhcyAidmlmJWQuJWQi
IC0tCnNlZSAkS0VSTkVML2RyaXZlcnMvbmV0L3hlbi1uZXRiYWNrL2ludGVyZmFjZS5jOnhlbnZp
Zl9hbGxvYy4geGwgaGFzCm5vdGhpbmcgdG8gZG8gd2l0aCB0aGlzIGJlY2F1c2UgdGhlIGNyZWF0
aW9uIG9mIHZpZiBpcyBhdXRvbWF0aWNhbGx5CmRvbmUgd2hlbiBGRSBjb25uZWN0cyB0byBCRS4K
CkEgcG9zc2libGUgc29sdXRpb24gaXMgdGhhdCB3ZSB3cml0ZSB1c2VyLXNwZWNpZmllZCB2aWZu
YW1lIGluIHhlbnN0b3JlCmVudHJ5IHRoZW4gQkUgcmV0cmlldmUgdGhlIHZhbHVlIGFuZCB1c2Ug
dGhlIHZhbHVlIGFzIHZpZiBuYW1lLgoKCldlaS4KCgpfX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBs
aXN0cy54ZW5zb3VyY2UuY29tCmh0dHA6Ly9saXN0cy54ZW5zb3VyY2UuY29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Wed Dec 28 15:11:31 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 28 Dec 2011 15: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.xensource.com>)
	id 1Rfv9h-00068W-LR; Wed, 28 Dec 2011 15:11:01 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andy@strugglers.net>) id 1Rfv9g-00068M-In
	for xen-devel@lists.xensource.com; Wed, 28 Dec 2011 15:11:00 +0000
X-Env-Sender: andy@strugglers.net
X-Msg-Ref: server-9.tower-27.messagelabs.com!1325085018!58254990!1
X-Originating-IP: [85.119.80.223]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6387 invoked from network); 28 Dec 2011 15:10:18 -0000
Received: from bitfolk.com (HELO mail.bitfolk.com) (85.119.80.223)
	by server-9.tower-27.messagelabs.com with AES256-SHA encrypted SMTP;
	28 Dec 2011 15:10:18 -0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bitfolk.com;
	s=alpha; 
	h=Subject:In-Reply-To:Content-Type:MIME-Version:References:Message-ID:To:From:Date;
	bh=VNcLLCOlXZsQJWHR47gyneE2vk8Hfwbk77ThMLgiLIY=; 
	b=dJ4yPvY218RrwIiC2v6udcQ7xoaXCmaB3ESf0/IBCTf8jCM6JGZf8vhSuy1n/u7PWzXUYSQt8dSFKb+pgruq0h3btJhMRTXyLUA/1jp4uUmNFy3I2OFExPVt2ZDxS/nX;
Received: from andy by mail.bitfolk.com with local (Exim 4.72)
	(envelope-from <andy@strugglers.net>) id 1Rfv9a-0001hI-Ln
	for xen-devel@lists.xensource.com; Wed, 28 Dec 2011 15:10:54 +0000
Date: Wed, 28 Dec 2011 15:10:54 +0000
From: Andy Smith <andy@strugglers.net>
To: xen-devel@lists.xensource.com
Message-ID: <20111228151054.GC4221@bitfolk.com>
References: <20111217135342.DDB9E3806B9@mx1.internecto.net>
	<CAFivhP=Uw=e8M_JsE2_fRpT5KtqYuKEf_Jdm2aEQz17iT_vHMw@mail.gmail.com>
	<20111228111918.GN12984@reaktio.net>
	<20111228143123.GB4221@bitfolk.com>
	<1325084532.24422.8.camel@liuw-desktop>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1325084532.24422.8.camel@liuw-desktop>
OpenPGP: id=BF15490B; url=http://strugglers.net/~andy/pubkey.asc
X-URL: http://strugglers.net/wiki/User:Andy
User-Agent: Mutt/1.5.18 (2008-05-17)
X-Virus-Scanner: Scanned by ClamAV on mail.bitfolk.com at Wed,
	28 Dec 2011 15:10:54 +0000
X-SA-Exim-Connect-IP: <locally generated>
X-SA-Exim-Mail-From: andy@strugglers.net
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	spamd2.lon.bitfolk.com
X-Spam-Level: 
X-Spam-ASN: 
X-Spam-Status: No, score=-0.0 required=5.0 tests=NO_RELAYS shortcircuit=no
	autolearn=disabled version=3.3.1
X-Spam-Report: * -0.0 NO_RELAYS Informational: message was not relayed via SMTP
X-SA-Exim-Version: 4.2.1 (built Wed, 25 Jun 2008 17:14:11 +0000)
X-SA-Exim-Scanned: Yes (on mail.bitfolk.com)
Subject: Re: [Xen-devel] [Xen-users] xl and vifname
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi Wei,

On Wed, Dec 28, 2011 at 03:02:12PM +0000, Wei Liu wrote:
> On Wed, 2011-12-28 at 14:31 +0000, Andy Smith wrote:
> > Ditto here, being able to give a vif a specific name is required.
> 
> I'm a bit confused. xl parses 'vif' names for both HVM and PV guest. I
> think you're using QEMU as network backend when you run HVM guest?
> 
> Well if backend is netback, the vif name is hardcoded as "vif%d.%d" --
> see $KERNEL/drivers/net/xen-netback/interface.c:xenvif_alloc. xl has
> nothing to do with this because the creation of vif is automatically
> done when FE connects to BE.

I haven't followed the thread; I just saw it here on xen-devel that:

"You might want to communicate to xen-devel that you rely on
[vifname support]"

Currently we use xm and xend, specify vifname in the PV guest's
config in order to get a dom0 network interface of a given name.
That functionality is required for us.

If I misunderstood then I apologise; it seemed that it was being
indicated that this functionality didn't exist with xm and there
were no plans to provide it.

Cheers,
Andy

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 28 15:11:31 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 28 Dec 2011 15: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.xensource.com>)
	id 1Rfv9h-00068W-LR; Wed, 28 Dec 2011 15:11:01 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andy@strugglers.net>) id 1Rfv9g-00068M-In
	for xen-devel@lists.xensource.com; Wed, 28 Dec 2011 15:11:00 +0000
X-Env-Sender: andy@strugglers.net
X-Msg-Ref: server-9.tower-27.messagelabs.com!1325085018!58254990!1
X-Originating-IP: [85.119.80.223]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6387 invoked from network); 28 Dec 2011 15:10:18 -0000
Received: from bitfolk.com (HELO mail.bitfolk.com) (85.119.80.223)
	by server-9.tower-27.messagelabs.com with AES256-SHA encrypted SMTP;
	28 Dec 2011 15:10:18 -0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bitfolk.com;
	s=alpha; 
	h=Subject:In-Reply-To:Content-Type:MIME-Version:References:Message-ID:To:From:Date;
	bh=VNcLLCOlXZsQJWHR47gyneE2vk8Hfwbk77ThMLgiLIY=; 
	b=dJ4yPvY218RrwIiC2v6udcQ7xoaXCmaB3ESf0/IBCTf8jCM6JGZf8vhSuy1n/u7PWzXUYSQt8dSFKb+pgruq0h3btJhMRTXyLUA/1jp4uUmNFy3I2OFExPVt2ZDxS/nX;
Received: from andy by mail.bitfolk.com with local (Exim 4.72)
	(envelope-from <andy@strugglers.net>) id 1Rfv9a-0001hI-Ln
	for xen-devel@lists.xensource.com; Wed, 28 Dec 2011 15:10:54 +0000
Date: Wed, 28 Dec 2011 15:10:54 +0000
From: Andy Smith <andy@strugglers.net>
To: xen-devel@lists.xensource.com
Message-ID: <20111228151054.GC4221@bitfolk.com>
References: <20111217135342.DDB9E3806B9@mx1.internecto.net>
	<CAFivhP=Uw=e8M_JsE2_fRpT5KtqYuKEf_Jdm2aEQz17iT_vHMw@mail.gmail.com>
	<20111228111918.GN12984@reaktio.net>
	<20111228143123.GB4221@bitfolk.com>
	<1325084532.24422.8.camel@liuw-desktop>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1325084532.24422.8.camel@liuw-desktop>
OpenPGP: id=BF15490B; url=http://strugglers.net/~andy/pubkey.asc
X-URL: http://strugglers.net/wiki/User:Andy
User-Agent: Mutt/1.5.18 (2008-05-17)
X-Virus-Scanner: Scanned by ClamAV on mail.bitfolk.com at Wed,
	28 Dec 2011 15:10:54 +0000
X-SA-Exim-Connect-IP: <locally generated>
X-SA-Exim-Mail-From: andy@strugglers.net
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	spamd2.lon.bitfolk.com
X-Spam-Level: 
X-Spam-ASN: 
X-Spam-Status: No, score=-0.0 required=5.0 tests=NO_RELAYS shortcircuit=no
	autolearn=disabled version=3.3.1
X-Spam-Report: * -0.0 NO_RELAYS Informational: message was not relayed via SMTP
X-SA-Exim-Version: 4.2.1 (built Wed, 25 Jun 2008 17:14:11 +0000)
X-SA-Exim-Scanned: Yes (on mail.bitfolk.com)
Subject: Re: [Xen-devel] [Xen-users] xl and vifname
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi Wei,

On Wed, Dec 28, 2011 at 03:02:12PM +0000, Wei Liu wrote:
> On Wed, 2011-12-28 at 14:31 +0000, Andy Smith wrote:
> > Ditto here, being able to give a vif a specific name is required.
> 
> I'm a bit confused. xl parses 'vif' names for both HVM and PV guest. I
> think you're using QEMU as network backend when you run HVM guest?
> 
> Well if backend is netback, the vif name is hardcoded as "vif%d.%d" --
> see $KERNEL/drivers/net/xen-netback/interface.c:xenvif_alloc. xl has
> nothing to do with this because the creation of vif is automatically
> done when FE connects to BE.

I haven't followed the thread; I just saw it here on xen-devel that:

"You might want to communicate to xen-devel that you rely on
[vifname support]"

Currently we use xm and xend, specify vifname in the PV guest's
config in order to get a dom0 network interface of a given name.
That functionality is required for us.

If I misunderstood then I apologise; it seemed that it was being
indicated that this functionality didn't exist with xm and there
were no plans to provide it.

Cheers,
Andy

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 28 15:15:20 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 28 Dec 2011 15:15:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RfvDO-0006He-L8; Wed, 28 Dec 2011 15:14:50 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andy@strugglers.net>) id 1RfvDN-0006HL-6V
	for xen-devel@lists.xensource.com; Wed, 28 Dec 2011 15:14:49 +0000
X-Env-Sender: andy@strugglers.net
X-Msg-Ref: server-16.tower-21.messagelabs.com!1325085282!3093699!1
X-Originating-IP: [85.119.80.223]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4758 invoked from network); 28 Dec 2011 15:14:42 -0000
Received: from bitfolk.com (HELO mail.bitfolk.com) (85.119.80.223)
	by server-16.tower-21.messagelabs.com with AES256-SHA encrypted SMTP;
	28 Dec 2011 15:14:42 -0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bitfolk.com;
	s=alpha; 
	h=Subject:In-Reply-To:Content-Type:MIME-Version:References:Message-ID:To:From:Date;
	bh=+b8hPuoB3mLlajGZevSEjdmusCe/BUyQyakqbodRC1U=; 
	b=PR6S41F0evdtTa4M2qL531JA8cHr42/dt11SA7uYdMXBsz6TD+OOOumML5fCkFxjG5j04dA+LSvF2Cuy/Wr9UuCrZfC+KxwPUWyYOikCEYNLwmYAg2NJWTPr/76iHKPb;
Received: from andy by mail.bitfolk.com with local (Exim 4.72)
	(envelope-from <andy@strugglers.net>) id 1RfvDG-0002JZ-1u
	for xen-devel@lists.xensource.com; Wed, 28 Dec 2011 15:14:42 +0000
Date: Wed, 28 Dec 2011 15:14:42 +0000
From: Andy Smith <andy@strugglers.net>
To: xen-devel@lists.xensource.com
Message-ID: <20111228151441.GD4221@bitfolk.com>
References: <20111217135342.DDB9E3806B9@mx1.internecto.net>
	<CAFivhP=Uw=e8M_JsE2_fRpT5KtqYuKEf_Jdm2aEQz17iT_vHMw@mail.gmail.com>
	<20111228111918.GN12984@reaktio.net>
	<20111228143123.GB4221@bitfolk.com>
	<1325084532.24422.8.camel@liuw-desktop>
	<20111228151054.GC4221@bitfolk.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20111228151054.GC4221@bitfolk.com>
OpenPGP: id=BF15490B; url=http://strugglers.net/~andy/pubkey.asc
X-URL: http://strugglers.net/wiki/User:Andy
User-Agent: Mutt/1.5.18 (2008-05-17)
X-Virus-Scanner: Scanned by ClamAV on mail.bitfolk.com at Wed,
	28 Dec 2011 15:14:42 +0000
X-SA-Exim-Connect-IP: <locally generated>
X-SA-Exim-Mail-From: andy@strugglers.net
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	spamd3.lon.bitfolk.com
X-Spam-Level: 
X-Spam-ASN: 
X-Spam-Status: No, score=-0.0 required=5.0 tests=NO_RELAYS shortcircuit=no
	autolearn=disabled version=3.3.1
X-Spam-Report: * -0.0 NO_RELAYS Informational: message was not relayed via SMTP
X-SA-Exim-Version: 4.2.1 (built Wed, 25 Jun 2008 17:14:11 +0000)
X-SA-Exim-Scanned: Yes (on mail.bitfolk.com)
Subject: Re: [Xen-devel] [Xen-users] xl and vifname
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Dec 28, 2011 at 03:10:54PM +0000, Andy Smith wrote:
> If I misunderstood then I apologise; it seemed that it was being
> indicated that this functionality didn't exist with xm and there
                                                     ^^xl
> were no plans to provide it.

sigh. :)

Cheers,
Andy, nursing a post Christmas cold.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 28 15:15:20 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 28 Dec 2011 15:15:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RfvDO-0006He-L8; Wed, 28 Dec 2011 15:14:50 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andy@strugglers.net>) id 1RfvDN-0006HL-6V
	for xen-devel@lists.xensource.com; Wed, 28 Dec 2011 15:14:49 +0000
X-Env-Sender: andy@strugglers.net
X-Msg-Ref: server-16.tower-21.messagelabs.com!1325085282!3093699!1
X-Originating-IP: [85.119.80.223]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4758 invoked from network); 28 Dec 2011 15:14:42 -0000
Received: from bitfolk.com (HELO mail.bitfolk.com) (85.119.80.223)
	by server-16.tower-21.messagelabs.com with AES256-SHA encrypted SMTP;
	28 Dec 2011 15:14:42 -0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bitfolk.com;
	s=alpha; 
	h=Subject:In-Reply-To:Content-Type:MIME-Version:References:Message-ID:To:From:Date;
	bh=+b8hPuoB3mLlajGZevSEjdmusCe/BUyQyakqbodRC1U=; 
	b=PR6S41F0evdtTa4M2qL531JA8cHr42/dt11SA7uYdMXBsz6TD+OOOumML5fCkFxjG5j04dA+LSvF2Cuy/Wr9UuCrZfC+KxwPUWyYOikCEYNLwmYAg2NJWTPr/76iHKPb;
Received: from andy by mail.bitfolk.com with local (Exim 4.72)
	(envelope-from <andy@strugglers.net>) id 1RfvDG-0002JZ-1u
	for xen-devel@lists.xensource.com; Wed, 28 Dec 2011 15:14:42 +0000
Date: Wed, 28 Dec 2011 15:14:42 +0000
From: Andy Smith <andy@strugglers.net>
To: xen-devel@lists.xensource.com
Message-ID: <20111228151441.GD4221@bitfolk.com>
References: <20111217135342.DDB9E3806B9@mx1.internecto.net>
	<CAFivhP=Uw=e8M_JsE2_fRpT5KtqYuKEf_Jdm2aEQz17iT_vHMw@mail.gmail.com>
	<20111228111918.GN12984@reaktio.net>
	<20111228143123.GB4221@bitfolk.com>
	<1325084532.24422.8.camel@liuw-desktop>
	<20111228151054.GC4221@bitfolk.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20111228151054.GC4221@bitfolk.com>
OpenPGP: id=BF15490B; url=http://strugglers.net/~andy/pubkey.asc
X-URL: http://strugglers.net/wiki/User:Andy
User-Agent: Mutt/1.5.18 (2008-05-17)
X-Virus-Scanner: Scanned by ClamAV on mail.bitfolk.com at Wed,
	28 Dec 2011 15:14:42 +0000
X-SA-Exim-Connect-IP: <locally generated>
X-SA-Exim-Mail-From: andy@strugglers.net
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	spamd3.lon.bitfolk.com
X-Spam-Level: 
X-Spam-ASN: 
X-Spam-Status: No, score=-0.0 required=5.0 tests=NO_RELAYS shortcircuit=no
	autolearn=disabled version=3.3.1
X-Spam-Report: * -0.0 NO_RELAYS Informational: message was not relayed via SMTP
X-SA-Exim-Version: 4.2.1 (built Wed, 25 Jun 2008 17:14:11 +0000)
X-SA-Exim-Scanned: Yes (on mail.bitfolk.com)
Subject: Re: [Xen-devel] [Xen-users] xl and vifname
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Dec 28, 2011 at 03:10:54PM +0000, Andy Smith wrote:
> If I misunderstood then I apologise; it seemed that it was being
> indicated that this functionality didn't exist with xm and there
                                                     ^^xl
> were no plans to provide it.

sigh. :)

Cheers,
Andy, nursing a post Christmas cold.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 28 15:27:14 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 28 Dec 2011 15:27:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RfvOy-0006UM-Uk; Wed, 28 Dec 2011 15:26:48 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1RfvOx-0006UE-Ns
	for xen-devel@lists.xensource.com; Wed, 28 Dec 2011 15:26:47 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1325086001!8948261!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwMQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17097 invoked from network); 28 Dec 2011 15:26:41 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Dec 2011 15:26:41 -0000
X-IronPort-AV: E=Sophos;i="4.71,421,1320624000"; 
   d="scan'208";a="9722196"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Dec 2011 15:26:41 +0000
Received: from [10.80.2.50] (10.80.2.50) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 28 Dec 2011 15:26:41 +0000
Message-ID: <1325085957.24422.17.camel@liuw-desktop>
From: Wei Liu <wei.liu2@citrix.com>
To: Andy Smith <andy@strugglers.net>
Date: Wed, 28 Dec 2011 15:25:57 +0000
In-Reply-To: <20111228151054.GC4221@bitfolk.com>
References: <20111217135342.DDB9E3806B9@mx1.internecto.net>
	<CAFivhP=Uw=e8M_JsE2_fRpT5KtqYuKEf_Jdm2aEQz17iT_vHMw@mail.gmail.com>
	<20111228111918.GN12984@reaktio.net>	<20111228143123.GB4221@bitfolk.com>
	<1325084532.24422.8.camel@liuw-desktop>
	<20111228151054.GC4221@bitfolk.com>
X-Mailer: Evolution 3.2.1- 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	wei.liu2@citrix.com
Subject: Re: [Xen-devel] [Xen-users] xl and vifname
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2011-12-28 at 15:10 +0000, Andy Smith wrote:
> Hi Wei,
> 
> On Wed, Dec 28, 2011 at 03:02:12PM +0000, Wei Liu wrote:
> > On Wed, 2011-12-28 at 14:31 +0000, Andy Smith wrote:
> > > Ditto here, being able to give a vif a specific name is required.
> > 
> > I'm a bit confused. xl parses 'vif' names for both HVM and PV guest. I
> > think you're using QEMU as network backend when you run HVM guest?
> > 
> > Well if backend is netback, the vif name is hardcoded as "vif%d.%d" --
> > see $KERNEL/drivers/net/xen-netback/interface.c:xenvif_alloc. xl has
> > nothing to do with this because the creation of vif is automatically
> > done when FE connects to BE.
> 
> I haven't followed the thread; I just saw it here on xen-devel that:
> 
> "You might want to communicate to xen-devel that you rely on
> [vifname support]"
> 
> Currently we use xm and xend, specify vifname in the PV guest's
> config in order to get a dom0 network interface of a given name.
> That functionality is required for us.
> 

(Well I'm not very familiar with xm code.)

Does xm serve your purpose -- specifying dom0 network interface of a
given name (rather then using vifX.X)?

If it can serve you purpose, can you verify which network backend you
are using by running following command:

$ ps aux | egrep '(qemu|net)'

If you get qemu-dm in the result, you're running QEMU. If you get
netback/0 in the result, you're running netback.

If you're running netback and you can use you preferred name for the
interface, then a similar fix for xl should be possible.

> If I misunderstood then I apologise; it seemed that it was being
> indicated that this functionality didn't exist with xm and there
> were no plans to provide it.
> 

I guess "xm" should be "xl". :)

I'm not a toolstack maintainer, I'm only trying to help. Maybe we can
wait for a proper answer from the maintainer.


Wei.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 28 15:27:14 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 28 Dec 2011 15:27:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RfvOy-0006UM-Uk; Wed, 28 Dec 2011 15:26:48 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1RfvOx-0006UE-Ns
	for xen-devel@lists.xensource.com; Wed, 28 Dec 2011 15:26:47 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1325086001!8948261!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwMQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17097 invoked from network); 28 Dec 2011 15:26:41 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Dec 2011 15:26:41 -0000
X-IronPort-AV: E=Sophos;i="4.71,421,1320624000"; 
   d="scan'208";a="9722196"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Dec 2011 15:26:41 +0000
Received: from [10.80.2.50] (10.80.2.50) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 28 Dec 2011 15:26:41 +0000
Message-ID: <1325085957.24422.17.camel@liuw-desktop>
From: Wei Liu <wei.liu2@citrix.com>
To: Andy Smith <andy@strugglers.net>
Date: Wed, 28 Dec 2011 15:25:57 +0000
In-Reply-To: <20111228151054.GC4221@bitfolk.com>
References: <20111217135342.DDB9E3806B9@mx1.internecto.net>
	<CAFivhP=Uw=e8M_JsE2_fRpT5KtqYuKEf_Jdm2aEQz17iT_vHMw@mail.gmail.com>
	<20111228111918.GN12984@reaktio.net>	<20111228143123.GB4221@bitfolk.com>
	<1325084532.24422.8.camel@liuw-desktop>
	<20111228151054.GC4221@bitfolk.com>
X-Mailer: Evolution 3.2.1- 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	wei.liu2@citrix.com
Subject: Re: [Xen-devel] [Xen-users] xl and vifname
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2011-12-28 at 15:10 +0000, Andy Smith wrote:
> Hi Wei,
> 
> On Wed, Dec 28, 2011 at 03:02:12PM +0000, Wei Liu wrote:
> > On Wed, 2011-12-28 at 14:31 +0000, Andy Smith wrote:
> > > Ditto here, being able to give a vif a specific name is required.
> > 
> > I'm a bit confused. xl parses 'vif' names for both HVM and PV guest. I
> > think you're using QEMU as network backend when you run HVM guest?
> > 
> > Well if backend is netback, the vif name is hardcoded as "vif%d.%d" --
> > see $KERNEL/drivers/net/xen-netback/interface.c:xenvif_alloc. xl has
> > nothing to do with this because the creation of vif is automatically
> > done when FE connects to BE.
> 
> I haven't followed the thread; I just saw it here on xen-devel that:
> 
> "You might want to communicate to xen-devel that you rely on
> [vifname support]"
> 
> Currently we use xm and xend, specify vifname in the PV guest's
> config in order to get a dom0 network interface of a given name.
> That functionality is required for us.
> 

(Well I'm not very familiar with xm code.)

Does xm serve your purpose -- specifying dom0 network interface of a
given name (rather then using vifX.X)?

If it can serve you purpose, can you verify which network backend you
are using by running following command:

$ ps aux | egrep '(qemu|net)'

If you get qemu-dm in the result, you're running QEMU. If you get
netback/0 in the result, you're running netback.

If you're running netback and you can use you preferred name for the
interface, then a similar fix for xl should be possible.

> If I misunderstood then I apologise; it seemed that it was being
> indicated that this functionality didn't exist with xm and there
> were no plans to provide it.
> 

I guess "xm" should be "xl". :)

I'm not a toolstack maintainer, I'm only trying to help. Maybe we can
wait for a proper answer from the maintainer.


Wei.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 28 15:38:32 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 28 Dec 2011 15: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.xensource.com>)
	id 1RfvZv-0006hL-59; Wed, 28 Dec 2011 15:38:07 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andy@strugglers.net>) id 1RfvZt-0006hG-Ss
	for xen-devel@lists.xensource.com; Wed, 28 Dec 2011 15:38:06 +0000
X-Env-Sender: andy@strugglers.net
X-Msg-Ref: server-9.tower-21.messagelabs.com!1325086679!3562759!1
X-Originating-IP: [85.119.80.223]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27799 invoked from network); 28 Dec 2011 15:37:59 -0000
Received: from bitfolk.com (HELO mail.bitfolk.com) (85.119.80.223)
	by server-9.tower-21.messagelabs.com with AES256-SHA encrypted SMTP;
	28 Dec 2011 15:37:59 -0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bitfolk.com;
	s=alpha; 
	h=Subject:In-Reply-To:Content-Type:MIME-Version:References:Message-ID:To:From:Date;
	bh=Uy5OIN0Io3YhphgTs2DbjDkeuRbLNfTzaGacso9jgf4=; 
	b=yfUMVDfqXbBYK3PUF/LIFuVEhseqwuNko/+fa9P6wyYr4JRpgkcYpV970rjC+4Wub4R6LJbU/u7igXpPD/nMnqyaRB68oFMk6rxKXKpGjj3podz1QG7+DTF3uiJ8KZit;
Received: from andy by mail.bitfolk.com with local (Exim 4.72)
	(envelope-from <andy@strugglers.net>) id 1RfvZm-0003F3-Tz
	for xen-devel@lists.xensource.com; Wed, 28 Dec 2011 15:37:59 +0000
Date: Wed, 28 Dec 2011 15:37:58 +0000
From: Andy Smith <andy@strugglers.net>
To: xen-devel@lists.xensource.com
Message-ID: <20111228153758.GE4221@bitfolk.com>
References: <20111217135342.DDB9E3806B9@mx1.internecto.net>
	<CAFivhP=Uw=e8M_JsE2_fRpT5KtqYuKEf_Jdm2aEQz17iT_vHMw@mail.gmail.com>
	<20111228111918.GN12984@reaktio.net>
	<20111228143123.GB4221@bitfolk.com>
	<1325084532.24422.8.camel@liuw-desktop>
	<20111228151054.GC4221@bitfolk.com>
	<1325085957.24422.17.camel@liuw-desktop>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1325085957.24422.17.camel@liuw-desktop>
OpenPGP: id=BF15490B; url=http://strugglers.net/~andy/pubkey.asc
X-URL: http://strugglers.net/wiki/User:Andy
User-Agent: Mutt/1.5.18 (2008-05-17)
X-Virus-Scanner: Scanned by ClamAV on mail.bitfolk.com at Wed,
	28 Dec 2011 15:37:58 +0000
X-SA-Exim-Connect-IP: <locally generated>
X-SA-Exim-Mail-From: andy@strugglers.net
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	spamd0.lon.bitfolk.com
X-Spam-Level: 
X-Spam-ASN: 
X-Spam-Status: No, score=-0.0 required=5.0 tests=NO_RELAYS shortcircuit=no
	autolearn=disabled version=3.3.1
X-Spam-Report: * -0.0 NO_RELAYS Informational: message was not relayed via SMTP
X-SA-Exim-Version: 4.2.1 (built Wed, 25 Jun 2008 17:14:11 +0000)
X-SA-Exim-Scanned: Yes (on mail.bitfolk.com)
Subject: Re: [Xen-devel] [Xen-users] xl and vifname
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi Wei,

On Wed, Dec 28, 2011 at 03:25:57PM +0000, Wei Liu wrote:
> Does xm serve your purpose -- specifying dom0 network interface of a
> given name (rather then using vifX.X)?

Yes. We need to statically configure the vif names in order to have
them be the same every time, and to know which virtual machine
configuration they belong to. Not have them change every time the VM
is restarted.

(Yes I am aware that it would be possible to translate the vifX.Y
string into a domU name and go from there, but that adds a lot of
complexity)

> If it can serve you purpose, can you verify which network backend you
> are using by running following command:
> 
> $ ps aux | egrep '(qemu|net)'

This didn't match anything. These are PV domUs and there isn't a
process in dom0 for each domU's netback. This is 4.0.1 on Debian
stable.

> If you're running netback and you can use you preferred name for the
> interface, then a similar fix for xl should be possible.

Something like:

    vif = [ "mac=00:16:3e:8e:ac:0a, ip=192.168.82.198, vifname=vm-85" ]

has worked for us for ~5 years through Xen 3.x and 4.x.

Cheers,
Andy

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 28 15:38:32 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 28 Dec 2011 15: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.xensource.com>)
	id 1RfvZv-0006hL-59; Wed, 28 Dec 2011 15:38:07 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andy@strugglers.net>) id 1RfvZt-0006hG-Ss
	for xen-devel@lists.xensource.com; Wed, 28 Dec 2011 15:38:06 +0000
X-Env-Sender: andy@strugglers.net
X-Msg-Ref: server-9.tower-21.messagelabs.com!1325086679!3562759!1
X-Originating-IP: [85.119.80.223]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27799 invoked from network); 28 Dec 2011 15:37:59 -0000
Received: from bitfolk.com (HELO mail.bitfolk.com) (85.119.80.223)
	by server-9.tower-21.messagelabs.com with AES256-SHA encrypted SMTP;
	28 Dec 2011 15:37:59 -0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bitfolk.com;
	s=alpha; 
	h=Subject:In-Reply-To:Content-Type:MIME-Version:References:Message-ID:To:From:Date;
	bh=Uy5OIN0Io3YhphgTs2DbjDkeuRbLNfTzaGacso9jgf4=; 
	b=yfUMVDfqXbBYK3PUF/LIFuVEhseqwuNko/+fa9P6wyYr4JRpgkcYpV970rjC+4Wub4R6LJbU/u7igXpPD/nMnqyaRB68oFMk6rxKXKpGjj3podz1QG7+DTF3uiJ8KZit;
Received: from andy by mail.bitfolk.com with local (Exim 4.72)
	(envelope-from <andy@strugglers.net>) id 1RfvZm-0003F3-Tz
	for xen-devel@lists.xensource.com; Wed, 28 Dec 2011 15:37:59 +0000
Date: Wed, 28 Dec 2011 15:37:58 +0000
From: Andy Smith <andy@strugglers.net>
To: xen-devel@lists.xensource.com
Message-ID: <20111228153758.GE4221@bitfolk.com>
References: <20111217135342.DDB9E3806B9@mx1.internecto.net>
	<CAFivhP=Uw=e8M_JsE2_fRpT5KtqYuKEf_Jdm2aEQz17iT_vHMw@mail.gmail.com>
	<20111228111918.GN12984@reaktio.net>
	<20111228143123.GB4221@bitfolk.com>
	<1325084532.24422.8.camel@liuw-desktop>
	<20111228151054.GC4221@bitfolk.com>
	<1325085957.24422.17.camel@liuw-desktop>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1325085957.24422.17.camel@liuw-desktop>
OpenPGP: id=BF15490B; url=http://strugglers.net/~andy/pubkey.asc
X-URL: http://strugglers.net/wiki/User:Andy
User-Agent: Mutt/1.5.18 (2008-05-17)
X-Virus-Scanner: Scanned by ClamAV on mail.bitfolk.com at Wed,
	28 Dec 2011 15:37:58 +0000
X-SA-Exim-Connect-IP: <locally generated>
X-SA-Exim-Mail-From: andy@strugglers.net
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	spamd0.lon.bitfolk.com
X-Spam-Level: 
X-Spam-ASN: 
X-Spam-Status: No, score=-0.0 required=5.0 tests=NO_RELAYS shortcircuit=no
	autolearn=disabled version=3.3.1
X-Spam-Report: * -0.0 NO_RELAYS Informational: message was not relayed via SMTP
X-SA-Exim-Version: 4.2.1 (built Wed, 25 Jun 2008 17:14:11 +0000)
X-SA-Exim-Scanned: Yes (on mail.bitfolk.com)
Subject: Re: [Xen-devel] [Xen-users] xl and vifname
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi Wei,

On Wed, Dec 28, 2011 at 03:25:57PM +0000, Wei Liu wrote:
> Does xm serve your purpose -- specifying dom0 network interface of a
> given name (rather then using vifX.X)?

Yes. We need to statically configure the vif names in order to have
them be the same every time, and to know which virtual machine
configuration they belong to. Not have them change every time the VM
is restarted.

(Yes I am aware that it would be possible to translate the vifX.Y
string into a domU name and go from there, but that adds a lot of
complexity)

> If it can serve you purpose, can you verify which network backend you
> are using by running following command:
> 
> $ ps aux | egrep '(qemu|net)'

This didn't match anything. These are PV domUs and there isn't a
process in dom0 for each domU's netback. This is 4.0.1 on Debian
stable.

> If you're running netback and you can use you preferred name for the
> interface, then a similar fix for xl should be possible.

Something like:

    vif = [ "mac=00:16:3e:8e:ac:0a, ip=192.168.82.198, vifname=vm-85" ]

has worked for us for ~5 years through Xen 3.x and 4.x.

Cheers,
Andy

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 28 15:57:36 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 28 Dec 2011 15:57:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RfvsJ-0006sI-TU; Wed, 28 Dec 2011 15:57:07 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1RfvsI-0006sD-Gs
	for xen-devel@lists.xensource.com; Wed, 28 Dec 2011 15:57:06 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1325087819!7132456!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwMQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14221 invoked from network); 28 Dec 2011 15:57:00 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Dec 2011 15:57:00 -0000
X-IronPort-AV: E=Sophos;i="4.71,421,1320624000"; 
   d="scan'208";a="9723187"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Dec 2011 15:56:59 +0000
Received: from [10.80.2.50] (10.80.2.50) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 28 Dec 2011 15:56:59 +0000
Message-ID: <1325087775.24422.25.camel@liuw-desktop>
From: Wei Liu <wei.liu2@citrix.com>
To: Andy Smith <andy@strugglers.net>
Date: Wed, 28 Dec 2011 15:56:15 +0000
In-Reply-To: <20111228153758.GE4221@bitfolk.com>
References: <20111217135342.DDB9E3806B9@mx1.internecto.net>
	<CAFivhP=Uw=e8M_JsE2_fRpT5KtqYuKEf_Jdm2aEQz17iT_vHMw@mail.gmail.com>
	<20111228111918.GN12984@reaktio.net>	<20111228143123.GB4221@bitfolk.com>
	<1325084532.24422.8.camel@liuw-desktop>	<20111228151054.GC4221@bitfolk.com>
	<1325085957.24422.17.camel@liuw-desktop>
	<20111228153758.GE4221@bitfolk.com>
X-Mailer: Evolution 3.2.1- 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	wei.liu2@citrix.com
Subject: Re: [Xen-devel] [Xen-users] xl and vifname
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2011-12-28 at 15:37 +0000, Andy Smith wrote:
> Hi Wei,
> 
> On Wed, Dec 28, 2011 at 03:25:57PM +0000, Wei Liu wrote:
> > Does xm serve your purpose -- specifying dom0 network interface of a
> > given name (rather then using vifX.X)?
> 
> Yes. We need to statically configure the vif names in order to have
> them be the same every time, and to know which virtual machine
> configuration they belong to. Not have them change every time the VM
> is restarted.
> 
> (Yes I am aware that it would be possible to translate the vifX.Y
> string into a domU name and go from there, but that adds a lot of
> complexity)
> 
> > If it can serve you purpose, can you verify which network backend you
> > are using by running following command:
> > 
> > $ ps aux | egrep '(qemu|net)'
> 
> This didn't match anything. These are PV domUs and there isn't a
> process in dom0 for each domU's netback. This is 4.0.1 on Debian
> stable.
> 

What's your dom0 kernel version? The newer kernel (2.6.32 3.X) should
have something like netback/0. However, historical kernel doesn't have
that.

Hmm... Maybe I misunderstood something here. I skimmed code from 2.6.18
to 3.0, it all hardcodes vif names. Maybe the toolstack alters interface
name after creation.

I will spend some time on this and get back to you later.

> > If you're running netback and you can use you preferred name for the
> > interface, then a similar fix for xl should be possible.
> 
> Something like:
> 
>     vif = [ "mac=00:16:3e:8e:ac:0a, ip=192.168.82.198, vifname=vm-85" ]
> 
> has worked for us for ~5 years through Xen 3.x and 4.x.
> 

Alright, got it.


Wei.

> Cheers,
> Andy
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Dec 28 15:57:36 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 28 Dec 2011 15:57:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RfvsJ-0006sI-TU; Wed, 28 Dec 2011 15:57:07 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1RfvsI-0006sD-Gs
	for xen-devel@lists.xensource.com; Wed, 28 Dec 2011 15:57:06 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1325087819!7132456!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwMQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14221 invoked from network); 28 Dec 2011 15:57:00 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Dec 2011 15:57:00 -0000
X-IronPort-AV: E=Sophos;i="4.71,421,1320624000"; 
   d="scan'208";a="9723187"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Dec 2011 15:56:59 +0000
Received: from [10.80.2.50] (10.80.2.50) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 28 Dec 2011 15:56:59 +0000
Message-ID: <1325087775.24422.25.camel@liuw-desktop>
From: Wei Liu <wei.liu2@citrix.com>
To: Andy Smith <andy@strugglers.net>
Date: Wed, 28 Dec 2011 15:56:15 +0000
In-Reply-To: <20111228153758.GE4221@bitfolk.com>
References: <20111217135342.DDB9E3806B9@mx1.internecto.net>
	<CAFivhP=Uw=e8M_JsE2_fRpT5KtqYuKEf_Jdm2aEQz17iT_vHMw@mail.gmail.com>
	<20111228111918.GN12984@reaktio.net>	<20111228143123.GB4221@bitfolk.com>
	<1325084532.24422.8.camel@liuw-desktop>	<20111228151054.GC4221@bitfolk.com>
	<1325085957.24422.17.camel@liuw-desktop>
	<20111228153758.GE4221@bitfolk.com>
X-Mailer: Evolution 3.2.1- 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	wei.liu2@citrix.com
Subject: Re: [Xen-devel] [Xen-users] xl and vifname
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2011-12-28 at 15:37 +0000, Andy Smith wrote:
> Hi Wei,
> 
> On Wed, Dec 28, 2011 at 03:25:57PM +0000, Wei Liu wrote:
> > Does xm serve your purpose -- specifying dom0 network interface of a
> > given name (rather then using vifX.X)?
> 
> Yes. We need to statically configure the vif names in order to have
> them be the same every time, and to know which virtual machine
> configuration they belong to. Not have them change every time the VM
> is restarted.
> 
> (Yes I am aware that it would be possible to translate the vifX.Y
> string into a domU name and go from there, but that adds a lot of
> complexity)
> 
> > If it can serve you purpose, can you verify which network backend you
> > are using by running following command:
> > 
> > $ ps aux | egrep '(qemu|net)'
> 
> This didn't match anything. These are PV domUs and there isn't a
> process in dom0 for each domU's netback. This is 4.0.1 on Debian
> stable.
> 

What's your dom0 kernel version? The newer kernel (2.6.32 3.X) should
have something like netback/0. However, historical kernel doesn't have
that.

Hmm... Maybe I misunderstood something here. I skimmed code from 2.6.18
to 3.0, it all hardcodes vif names. Maybe the toolstack alters interface
name after creation.

I will spend some time on this and get back to you later.

> > If you're running netback and you can use you preferred name for the
> > interface, then a similar fix for xl should be possible.
> 
> Something like:
> 
>     vif = [ "mac=00:16:3e:8e:ac:0a, ip=192.168.82.198, vifname=vm-85" ]
> 
> has worked for us for ~5 years through Xen 3.x and 4.x.
> 

Alright, got it.


Wei.

> Cheers,
> Andy
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 29 05:34:17 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 29 Dec 2011 05: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.xensource.com>)
	id 1Rg8cM-0000de-27; Thu, 29 Dec 2011 05:33:30 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Rg8cK-0000dZ-HV
	for xen-devel@lists.xensource.com; Thu, 29 Dec 2011 05:33:28 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1325136801!7141185!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODY3MA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11875 invoked from network); 29 Dec 2011 05:33:21 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Dec 2011 05:33:21 -0000
X-IronPort-AV: E=Sophos;i="4.71,425,1320624000"; 
   d="scan'208";a="9729119"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Dec 2011 05:33:20 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 29 Dec 2011 05:33:18 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1Rg8cA-0005mf-Ef;
	Thu, 29 Dec 2011 05:33:18 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Rg8cA-0008TO-AD;
	Thu, 29 Dec 2011 05:33:18 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10612-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 29 Dec 2011 05:33:18 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10612: tolerable FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10612 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10612/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install       fail pass in 10611
 test-i386-i386-xl            16 guest-start.2      fail in 10611 pass in 10612

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-multivcpu 16 guest-start.2                fail   like 10600
 test-amd64-amd64-xl-sedf     14 guest-localmigrate/x10       fail   like 10611
 test-amd64-i386-xl           16 guest-start.2         fail in 10611 like 10606

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop      fail in 10611 never pass

version targeted for testing:
 xen                  2863b2f43a3b
baseline version:
 xen                  2863b2f43a3b

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 29 05:34:17 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 29 Dec 2011 05: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.xensource.com>)
	id 1Rg8cM-0000de-27; Thu, 29 Dec 2011 05:33:30 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Rg8cK-0000dZ-HV
	for xen-devel@lists.xensource.com; Thu, 29 Dec 2011 05:33:28 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1325136801!7141185!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODY3MA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11875 invoked from network); 29 Dec 2011 05:33:21 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Dec 2011 05:33:21 -0000
X-IronPort-AV: E=Sophos;i="4.71,425,1320624000"; 
   d="scan'208";a="9729119"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Dec 2011 05:33:20 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 29 Dec 2011 05:33:18 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1Rg8cA-0005mf-Ef;
	Thu, 29 Dec 2011 05:33:18 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Rg8cA-0008TO-AD;
	Thu, 29 Dec 2011 05:33:18 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10612-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 29 Dec 2011 05:33:18 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10612: tolerable FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10612 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10612/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install       fail pass in 10611
 test-i386-i386-xl            16 guest-start.2      fail in 10611 pass in 10612

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-multivcpu 16 guest-start.2                fail   like 10600
 test-amd64-amd64-xl-sedf     14 guest-localmigrate/x10       fail   like 10611
 test-amd64-i386-xl           16 guest-start.2         fail in 10611 like 10606

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop      fail in 10611 never pass

version targeted for testing:
 xen                  2863b2f43a3b
baseline version:
 xen                  2863b2f43a3b

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 29 07:40:52 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 29 Dec 2011 07:40:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RgAat-0001No-0Z; Thu, 29 Dec 2011 07:40:07 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <joseph.cihula@intel.com>) id 1RgAar-0001Nf-MS
	for xen-devel@lists.xensource.com; Thu, 29 Dec 2011 07:40:05 +0000
X-Env-Sender: joseph.cihula@intel.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1325144398!5324361!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDMwMTk3Mw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1310 invoked from network); 29 Dec 2011 07:39:59 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-15.tower-174.messagelabs.com with SMTP;
	29 Dec 2011 07:39:59 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga102.fm.intel.com with ESMTP; 28 Dec 2011 23:39:57 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="106906560"
Received: from orsmsx602.amr.corp.intel.com ([10.22.226.211])
	by fmsmga002.fm.intel.com with ESMTP; 28 Dec 2011 23:39:57 -0800
Received: from orsmsx103.amr.corp.intel.com (10.22.225.130) by
	orsmsx602.amr.corp.intel.com (10.22.226.211) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Wed, 28 Dec 2011 23:39:57 -0800
Received: from orsmsx102.amr.corp.intel.com ([169.254.1.40]) by
	ORSMSX103.amr.corp.intel.com ([169.254.2.47]) with mapi id
	14.01.0355.002; Wed, 28 Dec 2011 23:39:56 -0800
From: "Cihula, Joseph" <joseph.cihula@intel.com>
To: "Wei, Gang" <gang.wei@intel.com>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>
Thread-Topic: [PATCH] x86: fix some coding style issues in tboot.c
Thread-Index: AczFbE/i585dAT8qTvql3Of5x97N1AAkKv7Q
Date: Thu, 29 Dec 2011 07:39:56 +0000
Message-ID: <9F57BF860713DF4BA3EFA4F8C6DFEDAC241DCE15@ORSMSX102.amr.corp.intel.com>
References: <D0B11485C64D4B47B66902F8A4E901BEB646@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <D0B11485C64D4B47B66902F8A4E901BEB646@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.22.254.140]
MIME-Version: 1.0
Cc: "Keir \(Xen.org\)" <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH] x86: fix some coding style issues in tboot.c
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

ACKed-by:  Joseph Cihula <joseph.cihula@intel.com>

> -----Original Message-----
> From: Wei, Gang
> Sent: Wednesday, December 28, 2011 6:24 AM
> To: xen-devel@lists.xensource.com
> Cc: Cihula, Joseph; Keir (Xen.org); Wei, Gang
> Subject: [PATCH] x86: fix some coding style issues in tboot.c
> 
> x86: fix some coding style issues in tboot.c
> 
> Signed-off-by: Gang Wei <gang.wei@intel.com>
> 
> diff -r fdcd30bf37b4 xen/arch/x86/tboot.c
> --- a/xen/arch/x86/tboot.c	Wed Dec 28 10:10:59 2011 +0800
> +++ b/xen/arch/x86/tboot.c	Wed Dec 28 10:29:58 2011 +0800
> @@ -110,7 +110,8 @@
> 
>      /* new tboot_shared (w/ GAS support, integrity, etc.) is not backwards
>         compatible */
> -    if ( tboot_shared->version < 4 ) {
> +    if ( tboot_shared->version < 4 )
> +    {
>          printk("unsupported version of tboot (%u)\n", tboot_shared->version);
>          return;
>      }
> @@ -188,8 +189,10 @@
> 
>          if ( !mfn_valid(mfn) )
>              continue;
> -        if ( is_page_in_use(page) && !is_xen_heap_page(page) ) {
> -            if ( page->count_info & PGC_page_table ) {
> +        if ( is_page_in_use(page) && !is_xen_heap_page(page) )
> +        {
> +            if ( page->count_info & PGC_page_table )
> +            {
>                  void *pg = map_domain_page(mfn);
>                  vmac_update(pg, PAGE_SIZE, ctx);
>                  unmap_domain_page(pg);
> @@ -283,7 +286,8 @@
>                                + 3 * PAGE_SIZE)) )
>              continue; /* skip tboot and its page tables */
> 
> -        if ( is_page_in_use(page) && is_xen_heap_page(page) ) {
> +        if ( is_page_in_use(page) && is_xen_heap_page(page) )
> +        {
>              void *pg;
> 
>              if ( mfn_in_guarded_stack(mfn) ) @@ -344,14 +348,16 @@
> 
>      err = map_pages_to_xen(map_base << PAGE_SHIFT, map_base, map_size,
>                             __PAGE_HYPERVISOR);
> -    if ( err != 0 ) {
> +    if ( err != 0 )
> +    {
>          printk("error (0x%x) mapping tboot pages (mfns) @ 0x%x, 0x%x\n", err,
>                 map_base, map_size);
>          return;
>      }
> 
>      /* if this is S3 then set regions to MAC */
> -    if ( shutdown_type == TB_SHUTDOWN_S3 ) {
> +    if ( shutdown_type == TB_SHUTDOWN_S3 )
> +    {
>          /*
>           * Xen regions for tboot to MAC
>           */
> @@ -400,26 +406,25 @@
>      /* TXT Heap */
>      if ( txt_heap_base == 0 )
>          return 0;
> -    rc = e820_change_range_type(
> -        &e820, txt_heap_base, txt_heap_base + txt_heap_size,
> -        E820_RESERVED, E820_UNUSABLE);
> +    rc = e820_change_range_type(&e820, txt_heap_base,
> +                                txt_heap_base + txt_heap_size,
> +                                E820_RESERVED, E820_UNUSABLE);
>      if ( !rc )
>          return 0;
> 
>      /* SINIT */
>      if ( sinit_base == 0 )
>          return 0;
> -    rc = e820_change_range_type(
> -        &e820, sinit_base, sinit_base + sinit_size,
> -        E820_RESERVED, E820_UNUSABLE);
> +    rc = e820_change_range_type(&e820, sinit_base,
> +                                sinit_base + sinit_size,
> +                                E820_RESERVED, E820_UNUSABLE);
>      if ( !rc )
>          return 0;
> 
>      /* TXT Private Space */
> -    rc = e820_change_range_type(
> -        &e820, TXT_PRIV_CONFIG_REGS_BASE,
> -        TXT_PRIV_CONFIG_REGS_BASE + NR_TXT_CONFIG_PAGES * PAGE_SIZE,
> -        E820_RESERVED, E820_UNUSABLE);
> +    rc = e820_change_range_type(&e820, TXT_PRIV_CONFIG_REGS_BASE,
> +                 TXT_PRIV_CONFIG_REGS_BASE + NR_TXT_CONFIG_PAGES * PAGE_SIZE,
> +                 E820_RESERVED, E820_UNUSABLE);
>      if ( !rc )
>          return 0;
> 
> @@ -436,7 +441,6 @@
>      sinit_mle_data_t sinit_mle_data;
>      unsigned char *dmar_table_raw;
> 
> -
>      if ( !tboot_in_measured_env() )
>          return acpi_table_parse(ACPI_SIG_DMAR, dmar_handler);


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 29 07:40:52 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 29 Dec 2011 07:40:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RgAat-0001No-0Z; Thu, 29 Dec 2011 07:40:07 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <joseph.cihula@intel.com>) id 1RgAar-0001Nf-MS
	for xen-devel@lists.xensource.com; Thu, 29 Dec 2011 07:40:05 +0000
X-Env-Sender: joseph.cihula@intel.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1325144398!5324361!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDMwMTk3Mw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1310 invoked from network); 29 Dec 2011 07:39:59 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-15.tower-174.messagelabs.com with SMTP;
	29 Dec 2011 07:39:59 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga102.fm.intel.com with ESMTP; 28 Dec 2011 23:39:57 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="106906560"
Received: from orsmsx602.amr.corp.intel.com ([10.22.226.211])
	by fmsmga002.fm.intel.com with ESMTP; 28 Dec 2011 23:39:57 -0800
Received: from orsmsx103.amr.corp.intel.com (10.22.225.130) by
	orsmsx602.amr.corp.intel.com (10.22.226.211) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Wed, 28 Dec 2011 23:39:57 -0800
Received: from orsmsx102.amr.corp.intel.com ([169.254.1.40]) by
	ORSMSX103.amr.corp.intel.com ([169.254.2.47]) with mapi id
	14.01.0355.002; Wed, 28 Dec 2011 23:39:56 -0800
From: "Cihula, Joseph" <joseph.cihula@intel.com>
To: "Wei, Gang" <gang.wei@intel.com>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>
Thread-Topic: [PATCH] x86: fix some coding style issues in tboot.c
Thread-Index: AczFbE/i585dAT8qTvql3Of5x97N1AAkKv7Q
Date: Thu, 29 Dec 2011 07:39:56 +0000
Message-ID: <9F57BF860713DF4BA3EFA4F8C6DFEDAC241DCE15@ORSMSX102.amr.corp.intel.com>
References: <D0B11485C64D4B47B66902F8A4E901BEB646@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <D0B11485C64D4B47B66902F8A4E901BEB646@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.22.254.140]
MIME-Version: 1.0
Cc: "Keir \(Xen.org\)" <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH] x86: fix some coding style issues in tboot.c
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

ACKed-by:  Joseph Cihula <joseph.cihula@intel.com>

> -----Original Message-----
> From: Wei, Gang
> Sent: Wednesday, December 28, 2011 6:24 AM
> To: xen-devel@lists.xensource.com
> Cc: Cihula, Joseph; Keir (Xen.org); Wei, Gang
> Subject: [PATCH] x86: fix some coding style issues in tboot.c
> 
> x86: fix some coding style issues in tboot.c
> 
> Signed-off-by: Gang Wei <gang.wei@intel.com>
> 
> diff -r fdcd30bf37b4 xen/arch/x86/tboot.c
> --- a/xen/arch/x86/tboot.c	Wed Dec 28 10:10:59 2011 +0800
> +++ b/xen/arch/x86/tboot.c	Wed Dec 28 10:29:58 2011 +0800
> @@ -110,7 +110,8 @@
> 
>      /* new tboot_shared (w/ GAS support, integrity, etc.) is not backwards
>         compatible */
> -    if ( tboot_shared->version < 4 ) {
> +    if ( tboot_shared->version < 4 )
> +    {
>          printk("unsupported version of tboot (%u)\n", tboot_shared->version);
>          return;
>      }
> @@ -188,8 +189,10 @@
> 
>          if ( !mfn_valid(mfn) )
>              continue;
> -        if ( is_page_in_use(page) && !is_xen_heap_page(page) ) {
> -            if ( page->count_info & PGC_page_table ) {
> +        if ( is_page_in_use(page) && !is_xen_heap_page(page) )
> +        {
> +            if ( page->count_info & PGC_page_table )
> +            {
>                  void *pg = map_domain_page(mfn);
>                  vmac_update(pg, PAGE_SIZE, ctx);
>                  unmap_domain_page(pg);
> @@ -283,7 +286,8 @@
>                                + 3 * PAGE_SIZE)) )
>              continue; /* skip tboot and its page tables */
> 
> -        if ( is_page_in_use(page) && is_xen_heap_page(page) ) {
> +        if ( is_page_in_use(page) && is_xen_heap_page(page) )
> +        {
>              void *pg;
> 
>              if ( mfn_in_guarded_stack(mfn) ) @@ -344,14 +348,16 @@
> 
>      err = map_pages_to_xen(map_base << PAGE_SHIFT, map_base, map_size,
>                             __PAGE_HYPERVISOR);
> -    if ( err != 0 ) {
> +    if ( err != 0 )
> +    {
>          printk("error (0x%x) mapping tboot pages (mfns) @ 0x%x, 0x%x\n", err,
>                 map_base, map_size);
>          return;
>      }
> 
>      /* if this is S3 then set regions to MAC */
> -    if ( shutdown_type == TB_SHUTDOWN_S3 ) {
> +    if ( shutdown_type == TB_SHUTDOWN_S3 )
> +    {
>          /*
>           * Xen regions for tboot to MAC
>           */
> @@ -400,26 +406,25 @@
>      /* TXT Heap */
>      if ( txt_heap_base == 0 )
>          return 0;
> -    rc = e820_change_range_type(
> -        &e820, txt_heap_base, txt_heap_base + txt_heap_size,
> -        E820_RESERVED, E820_UNUSABLE);
> +    rc = e820_change_range_type(&e820, txt_heap_base,
> +                                txt_heap_base + txt_heap_size,
> +                                E820_RESERVED, E820_UNUSABLE);
>      if ( !rc )
>          return 0;
> 
>      /* SINIT */
>      if ( sinit_base == 0 )
>          return 0;
> -    rc = e820_change_range_type(
> -        &e820, sinit_base, sinit_base + sinit_size,
> -        E820_RESERVED, E820_UNUSABLE);
> +    rc = e820_change_range_type(&e820, sinit_base,
> +                                sinit_base + sinit_size,
> +                                E820_RESERVED, E820_UNUSABLE);
>      if ( !rc )
>          return 0;
> 
>      /* TXT Private Space */
> -    rc = e820_change_range_type(
> -        &e820, TXT_PRIV_CONFIG_REGS_BASE,
> -        TXT_PRIV_CONFIG_REGS_BASE + NR_TXT_CONFIG_PAGES * PAGE_SIZE,
> -        E820_RESERVED, E820_UNUSABLE);
> +    rc = e820_change_range_type(&e820, TXT_PRIV_CONFIG_REGS_BASE,
> +                 TXT_PRIV_CONFIG_REGS_BASE + NR_TXT_CONFIG_PAGES * PAGE_SIZE,
> +                 E820_RESERVED, E820_UNUSABLE);
>      if ( !rc )
>          return 0;
> 
> @@ -436,7 +441,6 @@
>      sinit_mle_data_t sinit_mle_data;
>      unsigned char *dmar_table_raw;
> 
> -
>      if ( !tboot_in_measured_env() )
>          return acpi_table_parse(ACPI_SIG_DMAR, dmar_handler);


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 29 08:44:58 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 29 Dec 2011 08: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.xensource.com>)
	id 1RgBau-0002Cs-SV; Thu, 29 Dec 2011 08:44:12 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <chao.zhou@intel.com>) id 1RgBat-0002Ck-2a
	for xen-devel@lists.xensource.com; Thu, 29 Dec 2011 08:44:11 +0000
X-Env-Sender: chao.zhou@intel.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1325148243!8924220!1
X-Originating-IP: [143.182.124.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjE2ODU0\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3237 invoked from network); 29 Dec 2011 08:44:03 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-16.tower-216.messagelabs.com with SMTP;
	29 Dec 2011 08:44:03 -0000
Received: from azsmga002.ch.intel.com ([10.2.17.35])
	by azsmga101.ch.intel.com with ESMTP; 29 Dec 2011 00:44:02 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="51517719"
Received: from pgsmsx602.gar.corp.intel.com ([10.221.43.81])
	by AZSMGA002.ch.intel.com with ESMTP; 29 Dec 2011 00:44:02 -0800
Received: from shsmsx101.ccr.corp.intel.com (10.239.4.153) by
	pgsmsx602.gar.corp.intel.com (10.221.43.81) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Thu, 29 Dec 2011 16:42:19 +0800
Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.199]) by
	SHSMSX101.ccr.corp.intel.com ([169.254.1.38]) with mapi id
	14.01.0355.002; Thu, 29 Dec 2011 16:42:18 +0800
From: "Zhou, Chao" <chao.zhou@intel.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Thread-Topic: VMX status report. Xen:24446 & Dom0: 20a27c1e...
Thread-Index: AczGBcUjUkf17+1JROyP/8LOiVD90Q==
Date: Thu, 29 Dec 2011 08:42:17 +0000
Message-ID: <40352EBA8B4DF841A9907B883F22B59BDD99@SHSMSX102.ccr.corp.intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Subject: [Xen-devel] VMX status report. Xen:24446 & Dom0: 20a27c1e...
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi all,

This is the test report of xen-unstable tree. There is one issue which has existed in xen upstream since CS #22415 but was found recently.
After we hotplug a VF or NIC to guest for several times(about 10 times) the guest can't get ip address. The old CS #22402 doesn't have this issue, but it exists in latest xen upstream.


Version Info
=================================================================
xen-changeset:   24446:2863b2f43a3b
pvops git: Jeremy's tree
commit 20a27c1e25b8550066902c9d6ca91631e656dfa3
=================================================================

New issue(1)
==============
1. VF doesn't work after hot-plug for many times
http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1798


Old issues(6)
==============
1. [ACPI] System cann't resume after do suspend
http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1707
2.[XL]"xl vcpu-set" causes dom0 crash or panic 
http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1730
3.[VT-D]fail to detach NIC from guest
http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1736
4.Dom0 crash on power-off
http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1740
5.Sometimes Xen panic on ia32pae Sandybridge when restore guest
http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1747
6.[VT-D] device reset fail when create/destroy guest
http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1752




Thanks,
Zhou, Chao




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 29 08:44:58 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 29 Dec 2011 08: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.xensource.com>)
	id 1RgBau-0002Cs-SV; Thu, 29 Dec 2011 08:44:12 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <chao.zhou@intel.com>) id 1RgBat-0002Ck-2a
	for xen-devel@lists.xensource.com; Thu, 29 Dec 2011 08:44:11 +0000
X-Env-Sender: chao.zhou@intel.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1325148243!8924220!1
X-Originating-IP: [143.182.124.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjE2ODU0\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3237 invoked from network); 29 Dec 2011 08:44:03 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-16.tower-216.messagelabs.com with SMTP;
	29 Dec 2011 08:44:03 -0000
Received: from azsmga002.ch.intel.com ([10.2.17.35])
	by azsmga101.ch.intel.com with ESMTP; 29 Dec 2011 00:44:02 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="51517719"
Received: from pgsmsx602.gar.corp.intel.com ([10.221.43.81])
	by AZSMGA002.ch.intel.com with ESMTP; 29 Dec 2011 00:44:02 -0800
Received: from shsmsx101.ccr.corp.intel.com (10.239.4.153) by
	pgsmsx602.gar.corp.intel.com (10.221.43.81) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Thu, 29 Dec 2011 16:42:19 +0800
Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.199]) by
	SHSMSX101.ccr.corp.intel.com ([169.254.1.38]) with mapi id
	14.01.0355.002; Thu, 29 Dec 2011 16:42:18 +0800
From: "Zhou, Chao" <chao.zhou@intel.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Thread-Topic: VMX status report. Xen:24446 & Dom0: 20a27c1e...
Thread-Index: AczGBcUjUkf17+1JROyP/8LOiVD90Q==
Date: Thu, 29 Dec 2011 08:42:17 +0000
Message-ID: <40352EBA8B4DF841A9907B883F22B59BDD99@SHSMSX102.ccr.corp.intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Subject: [Xen-devel] VMX status report. Xen:24446 & Dom0: 20a27c1e...
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi all,

This is the test report of xen-unstable tree. There is one issue which has existed in xen upstream since CS #22415 but was found recently.
After we hotplug a VF or NIC to guest for several times(about 10 times) the guest can't get ip address. The old CS #22402 doesn't have this issue, but it exists in latest xen upstream.


Version Info
=================================================================
xen-changeset:   24446:2863b2f43a3b
pvops git: Jeremy's tree
commit 20a27c1e25b8550066902c9d6ca91631e656dfa3
=================================================================

New issue(1)
==============
1. VF doesn't work after hot-plug for many times
http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1798


Old issues(6)
==============
1. [ACPI] System cann't resume after do suspend
http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1707
2.[XL]"xl vcpu-set" causes dom0 crash or panic 
http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1730
3.[VT-D]fail to detach NIC from guest
http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1736
4.Dom0 crash on power-off
http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1740
5.Sometimes Xen panic on ia32pae Sandybridge when restore guest
http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1747
6.[VT-D] device reset fail when create/destroy guest
http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1752




Thanks,
Zhou, Chao




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 29 10:03:47 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 29 Dec 2011 10:03:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RgCpA-0002i6-2f; Thu, 29 Dec 2011 10:03:00 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rolf.neugebauer@gmail.com>) id 1RgCp9-0002i1-8b
	for Xen-devel@lists.xensource.com; Thu, 29 Dec 2011 10:02:59 +0000
X-Env-Sender: rolf.neugebauer@gmail.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1325152864!57794570!1
X-Originating-IP: [209.85.220.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13830 invoked from network); 29 Dec 2011 10:01:05 -0000
Received: from mail-vx0-f171.google.com (HELO mail-vx0-f171.google.com)
	(209.85.220.171)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Dec 2011 10:01:05 -0000
Received: by vcbfl11 with SMTP id fl11so34509964vcb.30
	for <Xen-devel@lists.xensource.com>;
	Thu, 29 Dec 2011 02:02:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=LQwrEaLqN7Ol+m6stI/lpRZHJ01vzn06DN+c6RUMOXU=;
	b=AEZfXfeo9YKPiTyPqtsoWZEoRCCNLA0bpD1w0rA/4er1a4uMorazNZNOAiiqh/dGc2
	3L7IA9/SIqm7b/+59IyXleI8QvfYhhGOavnhoT+9SRdHG55YIoGFZWvEwrY+FPMp2Y1I
	MSbZwAAyyBVIAnMaWsKV5bKzXxYfzH7vLyJic=
MIME-Version: 1.0
Received: by 10.220.149.198 with SMTP id u6mr20215657vcv.29.1325152976884;
	Thu, 29 Dec 2011 02:02:56 -0800 (PST)
Received: by 10.52.29.4 with HTTP; Thu, 29 Dec 2011 02:02:56 -0800 (PST)
In-Reply-To: <CANqQZNGrywjCoHO-h46J3zdPk+B4hw4HVe7dDdfcJjnsQLyzhA@mail.gmail.com>
References: <CANqQZNGrywjCoHO-h46J3zdPk+B4hw4HVe7dDdfcJjnsQLyzhA@mail.gmail.com>
Date: Thu, 29 Dec 2011 10:02:56 +0000
X-Google-Sender-Auth: LFh_a5a15n_RpHH1Xehfu6BZU5k
Message-ID: <CAAiAs2D8wvuNptW0whq7AoTQR9zKfbuwJAxnunMN5SHwfyXxdQ@mail.gmail.com>
From: Rolf Neugebauer <rn@acm.org>
To: Kai Huang <mail.kai.huang@gmail.com>
Cc: Xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] How does domU access PCI configure space?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 26 December 2011 06:02, Kai Huang <mail.kai.huang@gmail.com> wrote:
> Hi,
>
> In my understanding, domU's PCI configure space access (ncluding
> virtual device's and direct io's) is always trapped and emulated by
> xen hypervisor. How did xen do it? Through exposing PCI configure
> space area to domU as non-accessible memory? Where's the code to deal
> of this? Thanks!

For PV domU an alternative access method for accessing the PCI config
space is used in the kernel. The code for this is in
drivers/pci/xen-pcifront.c in recent linux kernels. The dom0 backend
code is in drivers/xen/xen-pciback/*

Rolf

>
> -cody
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 29 10:03:47 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 29 Dec 2011 10:03:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RgCpA-0002i6-2f; Thu, 29 Dec 2011 10:03:00 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rolf.neugebauer@gmail.com>) id 1RgCp9-0002i1-8b
	for Xen-devel@lists.xensource.com; Thu, 29 Dec 2011 10:02:59 +0000
X-Env-Sender: rolf.neugebauer@gmail.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1325152864!57794570!1
X-Originating-IP: [209.85.220.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13830 invoked from network); 29 Dec 2011 10:01:05 -0000
Received: from mail-vx0-f171.google.com (HELO mail-vx0-f171.google.com)
	(209.85.220.171)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Dec 2011 10:01:05 -0000
Received: by vcbfl11 with SMTP id fl11so34509964vcb.30
	for <Xen-devel@lists.xensource.com>;
	Thu, 29 Dec 2011 02:02:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=LQwrEaLqN7Ol+m6stI/lpRZHJ01vzn06DN+c6RUMOXU=;
	b=AEZfXfeo9YKPiTyPqtsoWZEoRCCNLA0bpD1w0rA/4er1a4uMorazNZNOAiiqh/dGc2
	3L7IA9/SIqm7b/+59IyXleI8QvfYhhGOavnhoT+9SRdHG55YIoGFZWvEwrY+FPMp2Y1I
	MSbZwAAyyBVIAnMaWsKV5bKzXxYfzH7vLyJic=
MIME-Version: 1.0
Received: by 10.220.149.198 with SMTP id u6mr20215657vcv.29.1325152976884;
	Thu, 29 Dec 2011 02:02:56 -0800 (PST)
Received: by 10.52.29.4 with HTTP; Thu, 29 Dec 2011 02:02:56 -0800 (PST)
In-Reply-To: <CANqQZNGrywjCoHO-h46J3zdPk+B4hw4HVe7dDdfcJjnsQLyzhA@mail.gmail.com>
References: <CANqQZNGrywjCoHO-h46J3zdPk+B4hw4HVe7dDdfcJjnsQLyzhA@mail.gmail.com>
Date: Thu, 29 Dec 2011 10:02:56 +0000
X-Google-Sender-Auth: LFh_a5a15n_RpHH1Xehfu6BZU5k
Message-ID: <CAAiAs2D8wvuNptW0whq7AoTQR9zKfbuwJAxnunMN5SHwfyXxdQ@mail.gmail.com>
From: Rolf Neugebauer <rn@acm.org>
To: Kai Huang <mail.kai.huang@gmail.com>
Cc: Xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] How does domU access PCI configure space?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 26 December 2011 06:02, Kai Huang <mail.kai.huang@gmail.com> wrote:
> Hi,
>
> In my understanding, domU's PCI configure space access (ncluding
> virtual device's and direct io's) is always trapped and emulated by
> xen hypervisor. How did xen do it? Through exposing PCI configure
> space area to domU as non-accessible memory? Where's the code to deal
> of this? Thanks!

For PV domU an alternative access method for accessing the PCI config
space is used in the kernel. The code for this is in
drivers/pci/xen-pcifront.c in recent linux kernels. The dom0 backend
code is in drivers/xen/xen-pciback/*

Rolf

>
> -cody
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 29 10:11:56 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 29 Dec 2011 10:11:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RgCxE-0002s3-1m; Thu, 29 Dec 2011 10:11:20 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RgCxC-0002rt-ME
	for xen-devel@lists.xensource.com; Thu, 29 Dec 2011 10:11:18 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-13.tower-216.messagelabs.com!1325153472!8482856!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31176 invoked from network); 29 Dec 2011 10:11:12 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-13.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 29 Dec 2011 10:11:12 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RgCx0-000Pgs-Io; Thu, 29 Dec 2011 10:11:06 +0000
Date: Thu, 29 Dec 2011 10:11:06 +0000
From: Tim Deegan <tim@xen.org>
To: "Wei, Gang" <gang.wei@intel.com>
Message-ID: <20111229101106.GA98533@ocelot.phlegethon.org>
References: <F26D193E20BBDC42A43B611D1BDEDE7135CEEEAE65@shsmsx502.ccr.corp.intel.com>
	<20111221170539.GA72385@ocelot.phlegethon.org>
	<D0B11485C64D4B47B66902F8A4E901BE9146@SHSMSX101.ccr.corp.intel.com>
	<20111222100112.GA1900@ocelot.phlegethon.org>
	<D0B11485C64D4B47B66902F8A4E901BEA2B8@SHSMSX101.ccr.corp.intel.com>
	<D0B11485C64D4B47B66902F8A4E901BEA302@SHSMSX101.ccr.corp.intel.com>
	<4EF445A60200007800069B41@nat28.tlf.novell.com>
	<D0B11485C64D4B47B66902F8A4E901BEB338@SHSMSX101.ccr.corp.intel.com>
	<20111227104710.GA44631@ocelot.phlegethon.org>
	<D0B11485C64D4B47B66902F8A4E901BEB4E7@SHSMSX101.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <D0B11485C64D4B47B66902F8A4E901BEB4E7@SHSMSX101.ccr.corp.intel.com>
User-Agent: Mutt/1.4.2.1i
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	"TimDeegan \(3P\)" <Tim.Deegan@citrix.com>, "Cihula,
	Joseph" <joseph.cihula@intel.com>,
	"tboot-devel@lists.sourceforge.net" <tboot-devel@lists.sourceforge.net>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [patch] x86: Add a delay between INIT & SIPIs for
	tboot AP bring-up in X2APIC case
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 01:22 +0000 on 28 Dec (1325035368), Wei, Gang wrote:
> If no further question on this patch from anyone else, could you help
> to check it in?

Done.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 29 10:11:56 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 29 Dec 2011 10:11:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RgCxE-0002s3-1m; Thu, 29 Dec 2011 10:11:20 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RgCxC-0002rt-ME
	for xen-devel@lists.xensource.com; Thu, 29 Dec 2011 10:11:18 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-13.tower-216.messagelabs.com!1325153472!8482856!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31176 invoked from network); 29 Dec 2011 10:11:12 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-13.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 29 Dec 2011 10:11:12 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RgCx0-000Pgs-Io; Thu, 29 Dec 2011 10:11:06 +0000
Date: Thu, 29 Dec 2011 10:11:06 +0000
From: Tim Deegan <tim@xen.org>
To: "Wei, Gang" <gang.wei@intel.com>
Message-ID: <20111229101106.GA98533@ocelot.phlegethon.org>
References: <F26D193E20BBDC42A43B611D1BDEDE7135CEEEAE65@shsmsx502.ccr.corp.intel.com>
	<20111221170539.GA72385@ocelot.phlegethon.org>
	<D0B11485C64D4B47B66902F8A4E901BE9146@SHSMSX101.ccr.corp.intel.com>
	<20111222100112.GA1900@ocelot.phlegethon.org>
	<D0B11485C64D4B47B66902F8A4E901BEA2B8@SHSMSX101.ccr.corp.intel.com>
	<D0B11485C64D4B47B66902F8A4E901BEA302@SHSMSX101.ccr.corp.intel.com>
	<4EF445A60200007800069B41@nat28.tlf.novell.com>
	<D0B11485C64D4B47B66902F8A4E901BEB338@SHSMSX101.ccr.corp.intel.com>
	<20111227104710.GA44631@ocelot.phlegethon.org>
	<D0B11485C64D4B47B66902F8A4E901BEB4E7@SHSMSX101.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <D0B11485C64D4B47B66902F8A4E901BEB4E7@SHSMSX101.ccr.corp.intel.com>
User-Agent: Mutt/1.4.2.1i
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	"TimDeegan \(3P\)" <Tim.Deegan@citrix.com>, "Cihula,
	Joseph" <joseph.cihula@intel.com>,
	"tboot-devel@lists.sourceforge.net" <tboot-devel@lists.sourceforge.net>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [patch] x86: Add a delay between INIT & SIPIs for
	tboot AP bring-up in X2APIC case
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 01:22 +0000 on 28 Dec (1325035368), Wei, Gang wrote:
> If no further question on this patch from anyone else, could you help
> to check it in?

Done.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 29 11:15:49 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 29 Dec 2011 11:15:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RgDx3-0003Dc-Ag; Thu, 29 Dec 2011 11:15:13 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1RgDx1-0003DH-4D
	for xen-devel@lists.xensource.com; Thu, 29 Dec 2011 11:15:11 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1325157302!5346186!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTIzMDQ=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18436 invoked from network); 29 Dec 2011 11:15:04 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Dec 2011 11:15:04 -0000
X-IronPort-AV: E=Sophos;i="4.71,426,1320642000"; d="scan'208";a="20389541"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Dec 2011 06:15:04 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Thu, 29 Dec 2011 06:15:04 -0500
Received: from testbox64.uk.xensource.com ([10.80.237.153])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pBTBExvZ009251;
	Thu, 29 Dec 2011 03:15:02 -0800
From: Wei Liu <wei.liu2@citrix.com>
To: xen-devel@lists.xensource.com
Date: Thu, 29 Dec 2011 11:14:36 +0000
Message-ID: <1325157276-4847-3-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1325157276-4847-1-git-send-email-wei.liu2@citrix.com>
References: <1325157276-4847-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: andy@strugglers.net, florian.heigl@gmail.com, wei.liu2@citrix.com
Subject: [Xen-devel] [PATCH 2/2] libxl: write vifname in xenstore if set.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Simple fix to enable user to specify vif names.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 tools/libxl/libxl.c |    6 ++++++
 1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 2b8f8f4..3c086d5 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -1534,6 +1534,12 @@ int libxl_device_nic_add(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic)
                                           libxl_xen_script_dir_path(),
                                           nic->script));
     }
+
+    if (nic->ifname) {
+        flexarray_append(back, "vifname");
+        flexarray_append(back, nic->ifname);
+    }
+
     flexarray_append(back, "mac");
     flexarray_append(back,libxl__sprintf(gc,
                                     LIBXL_MAC_FMT, LIBXL_MAC_BYTES(nic->mac)));
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 29 11:15:49 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 29 Dec 2011 11:15:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RgDx3-0003Dc-Ag; Thu, 29 Dec 2011 11:15:13 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1RgDx1-0003DH-4D
	for xen-devel@lists.xensource.com; Thu, 29 Dec 2011 11:15:11 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1325157302!5346186!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTIzMDQ=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18436 invoked from network); 29 Dec 2011 11:15:04 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Dec 2011 11:15:04 -0000
X-IronPort-AV: E=Sophos;i="4.71,426,1320642000"; d="scan'208";a="20389541"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Dec 2011 06:15:04 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Thu, 29 Dec 2011 06:15:04 -0500
Received: from testbox64.uk.xensource.com ([10.80.237.153])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pBTBExvZ009251;
	Thu, 29 Dec 2011 03:15:02 -0800
From: Wei Liu <wei.liu2@citrix.com>
To: xen-devel@lists.xensource.com
Date: Thu, 29 Dec 2011 11:14:36 +0000
Message-ID: <1325157276-4847-3-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1325157276-4847-1-git-send-email-wei.liu2@citrix.com>
References: <1325157276-4847-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: andy@strugglers.net, florian.heigl@gmail.com, wei.liu2@citrix.com
Subject: [Xen-devel] [PATCH 2/2] libxl: write vifname in xenstore if set.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Simple fix to enable user to specify vif names.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 tools/libxl/libxl.c |    6 ++++++
 1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 2b8f8f4..3c086d5 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -1534,6 +1534,12 @@ int libxl_device_nic_add(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic)
                                           libxl_xen_script_dir_path(),
                                           nic->script));
     }
+
+    if (nic->ifname) {
+        flexarray_append(back, "vifname");
+        flexarray_append(back, nic->ifname);
+    }
+
     flexarray_append(back, "mac");
     flexarray_append(back,libxl__sprintf(gc,
                                     LIBXL_MAC_FMT, LIBXL_MAC_BYTES(nic->mac)));
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 29 11:15:50 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 29 Dec 2011 11:15:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RgDx3-0003Dj-M3; Thu, 29 Dec 2011 11:15:13 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1RgDx1-0003DI-AQ
	for xen-devel@lists.xensource.com; Thu, 29 Dec 2011 11:15:11 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1325157303!9109492!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjY3NTM=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4957 invoked from network); 29 Dec 2011 11:15:04 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Dec 2011 11:15:04 -0000
X-IronPort-AV: E=Sophos;i="4.71,426,1320642000"; d="scan'208";a="175722909"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Dec 2011 06:15:03 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Thu, 29 Dec 2011 06:15:03 -0500
Received: from testbox64.uk.xensource.com ([10.80.237.153])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pBTBExvY009251;
	Thu, 29 Dec 2011 03:15:01 -0800
From: Wei Liu <wei.liu2@citrix.com>
To: xen-devel@lists.xensource.com
Date: Thu, 29 Dec 2011 11:14:35 +0000
Message-ID: <1325157276-4847-2-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1325157276-4847-1-git-send-email-wei.liu2@citrix.com>
References: <1325157276-4847-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: andy@strugglers.net, florian.heigl@gmail.com, wei.liu2@citrix.com
Subject: [Xen-devel] [PATCH 1/2] libxl: print out vifname in create dryrun.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 tools/libxl/xl_cmdimpl.c |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 8270f34..8da8b88 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -419,6 +419,8 @@ static void printf_info(int domid,
     for (i = 0; i < d_config->num_vifs; i++) {
         printf("\t(device\n");
         printf("\t\t(vif\n");
+        if (d_config->vifs[i].ifname)
+            printf("\t\t\t(vifname %s)\n", d_config->vifs[i].ifname);
         printf("\t\t\t(backend_domid %d)\n", d_config->vifs[i].backend_domid);
         printf("\t\t\t(frontend_domid %d)\n", domid);
         printf("\t\t\t(devid %d)\n", d_config->vifs[i].devid);
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 29 11:15:50 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 29 Dec 2011 11:15:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RgDx3-0003Dj-M3; Thu, 29 Dec 2011 11:15:13 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1RgDx1-0003DI-AQ
	for xen-devel@lists.xensource.com; Thu, 29 Dec 2011 11:15:11 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1325157303!9109492!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjY3NTM=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4957 invoked from network); 29 Dec 2011 11:15:04 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Dec 2011 11:15:04 -0000
X-IronPort-AV: E=Sophos;i="4.71,426,1320642000"; d="scan'208";a="175722909"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Dec 2011 06:15:03 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Thu, 29 Dec 2011 06:15:03 -0500
Received: from testbox64.uk.xensource.com ([10.80.237.153])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pBTBExvY009251;
	Thu, 29 Dec 2011 03:15:01 -0800
From: Wei Liu <wei.liu2@citrix.com>
To: xen-devel@lists.xensource.com
Date: Thu, 29 Dec 2011 11:14:35 +0000
Message-ID: <1325157276-4847-2-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1325157276-4847-1-git-send-email-wei.liu2@citrix.com>
References: <1325157276-4847-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: andy@strugglers.net, florian.heigl@gmail.com, wei.liu2@citrix.com
Subject: [Xen-devel] [PATCH 1/2] libxl: print out vifname in create dryrun.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 tools/libxl/xl_cmdimpl.c |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 8270f34..8da8b88 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -419,6 +419,8 @@ static void printf_info(int domid,
     for (i = 0; i < d_config->num_vifs; i++) {
         printf("\t(device\n");
         printf("\t\t(vif\n");
+        if (d_config->vifs[i].ifname)
+            printf("\t\t\t(vifname %s)\n", d_config->vifs[i].ifname);
         printf("\t\t\t(backend_domid %d)\n", d_config->vifs[i].backend_domid);
         printf("\t\t\t(frontend_domid %d)\n", domid);
         printf("\t\t\t(devid %d)\n", d_config->vifs[i].devid);
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 29 11:15:50 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 29 Dec 2011 11:15:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RgDx1-0003DV-Ue; Thu, 29 Dec 2011 11:15:11 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1RgDx0-0003DG-98
	for xen-devel@lists.xensource.com; Thu, 29 Dec 2011 11:15:10 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1325157302!5346186!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTIzMDQ=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18413 invoked from network); 29 Dec 2011 11:15:03 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Dec 2011 11:15:03 -0000
X-IronPort-AV: E=Sophos;i="4.71,426,1320642000"; d="scan'208";a="20389539"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Dec 2011 06:15:02 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Thu, 29 Dec 2011 06:15:01 -0500
Received: from testbox64.uk.xensource.com ([10.80.237.153])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pBTBExvX009251;
	Thu, 29 Dec 2011 03:15:00 -0800
From: Wei Liu <wei.liu2@citrix.com>
To: xen-devel@lists.xensource.com
Date: Thu, 29 Dec 2011 11:14:34 +0000
Message-ID: <1325157276-4847-1-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Cc: andy@strugglers.net, florian.heigl@gmail.com, wei.liu2@citrix.com
Subject: [Xen-devel] libxl: simple fix to enable user to configure vif names
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This feature is required by some of our users.

Reported-by: Andy Smith <andy@strugglers.net>
Reported-by: Florian Heigl <florian.heigl@gmail.com>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 29 11:15:50 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 29 Dec 2011 11:15:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RgDx1-0003DV-Ue; Thu, 29 Dec 2011 11:15:11 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1RgDx0-0003DG-98
	for xen-devel@lists.xensource.com; Thu, 29 Dec 2011 11:15:10 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1325157302!5346186!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTIzMDQ=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18413 invoked from network); 29 Dec 2011 11:15:03 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Dec 2011 11:15:03 -0000
X-IronPort-AV: E=Sophos;i="4.71,426,1320642000"; d="scan'208";a="20389539"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Dec 2011 06:15:02 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Thu, 29 Dec 2011 06:15:01 -0500
Received: from testbox64.uk.xensource.com ([10.80.237.153])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pBTBExvX009251;
	Thu, 29 Dec 2011 03:15:00 -0800
From: Wei Liu <wei.liu2@citrix.com>
To: xen-devel@lists.xensource.com
Date: Thu, 29 Dec 2011 11:14:34 +0000
Message-ID: <1325157276-4847-1-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Cc: andy@strugglers.net, florian.heigl@gmail.com, wei.liu2@citrix.com
Subject: [Xen-devel] libxl: simple fix to enable user to configure vif names
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This feature is required by some of our users.

Reported-by: Andy Smith <andy@strugglers.net>
Reported-by: Florian Heigl <florian.heigl@gmail.com>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 29 11:25:46 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 29 Dec 2011 11:25:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RgE6m-0003fg-Sn; Thu, 29 Dec 2011 11:25:16 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <gang.wei@intel.com>) id 1RgE6l-0003fY-VU
	for xen-devel@lists.xensource.com; Thu, 29 Dec 2011 11:25:16 +0000
X-Env-Sender: gang.wei@intel.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1325157909!9110641!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDMwMzU3Mg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5466 invoked from network); 29 Dec 2011 11:25:09 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-9.tower-216.messagelabs.com with SMTP;
	29 Dec 2011 11:25:09 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga101.fm.intel.com with ESMTP; 29 Dec 2011 03:25:08 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="101293867"
Received: from pgsmsx603.gar.corp.intel.com ([10.221.43.87])
	by fmsmga001.fm.intel.com with ESMTP; 29 Dec 2011 03:25:06 -0800
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	pgsmsx603.gar.corp.intel.com (10.221.43.87) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Thu, 29 Dec 2011 19:25:06 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.38]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.199]) with mapi id
	14.01.0355.002; Thu, 29 Dec 2011 19:25:04 +0800
From: "Wei, Gang" <gang.wei@intel.com>
To: Tim Deegan <tim@xen.org>
Thread-Topic: [Xen-devel] [patch] x86: Add a delay between INIT & SIPIs for
	tboot AP bring-up in X2APIC case
Thread-Index: AczAAslz2iL7OBXBT0+nwXPeOaB7qgARIT5gAAGReAAAMzbEEAABRG/A///PswD/+RVpQIANX4oA//6HOSCABJNdAP//Zhrw
Date: Thu, 29 Dec 2011 11:25:03 +0000
Message-ID: <D0B11485C64D4B47B66902F8A4E901BEC710@SHSMSX101.ccr.corp.intel.com>
References: <F26D193E20BBDC42A43B611D1BDEDE7135CEEEAE65@shsmsx502.ccr.corp.intel.com>
	<20111221170539.GA72385@ocelot.phlegethon.org>
	<D0B11485C64D4B47B66902F8A4E901BE9146@SHSMSX101.ccr.corp.intel.com>
	<20111222100112.GA1900@ocelot.phlegethon.org>
	<D0B11485C64D4B47B66902F8A4E901BEA2B8@SHSMSX101.ccr.corp.intel.com>
	<D0B11485C64D4B47B66902F8A4E901BEA302@SHSMSX101.ccr.corp.intel.com>
	<4EF445A60200007800069B41@nat28.tlf.novell.com>
	<D0B11485C64D4B47B66902F8A4E901BEB338@SHSMSX101.ccr.corp.intel.com>
	<20111227104710.GA44631@ocelot.phlegethon.org>
	<D0B11485C64D4B47B66902F8A4E901BEB4E7@SHSMSX101.ccr.corp.intel.com>
	<20111229101106.GA98533@ocelot.phlegethon.org>
In-Reply-To: <20111229101106.GA98533@ocelot.phlegethon.org>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Keir
	\(Xen.org\)" <keir@xen.org>, "TimDeegan \(3P\)" <Tim.Deegan@citrix.com>,
	"Cihula, Joseph" <joseph.cihula@intel.com>,
	"tboot-devel@lists.sourceforge.net" <tboot-devel@lists.sourceforge.net>,
	Jan Beulich <JBeulich@suse.com>, "Wei, Gang" <gang.wei@intel.com>
Subject: Re: [Xen-devel] [patch] x86: Add a delay between INIT & SIPIs for
 tboot AP bring-up in X2APIC case
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Tim Deegan wrote on=A02011-12-29:
> At 01:22 +0000 on 28 Dec (1325035368), Wei, Gang wrote:
>> If no further question on this patch from anyone else, could you
>> help to check it in?
> =

> Done.

Thanks. And I have already be ready to send the MWAIT AP bring-up patch for=
 tboot case, but it might be better to send it out after the New Year, isn'=
t it?

Jimmy



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 29 11:25:46 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 29 Dec 2011 11:25:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RgE6m-0003fg-Sn; Thu, 29 Dec 2011 11:25:16 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <gang.wei@intel.com>) id 1RgE6l-0003fY-VU
	for xen-devel@lists.xensource.com; Thu, 29 Dec 2011 11:25:16 +0000
X-Env-Sender: gang.wei@intel.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1325157909!9110641!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDMwMzU3Mg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5466 invoked from network); 29 Dec 2011 11:25:09 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-9.tower-216.messagelabs.com with SMTP;
	29 Dec 2011 11:25:09 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga101.fm.intel.com with ESMTP; 29 Dec 2011 03:25:08 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="101293867"
Received: from pgsmsx603.gar.corp.intel.com ([10.221.43.87])
	by fmsmga001.fm.intel.com with ESMTP; 29 Dec 2011 03:25:06 -0800
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	pgsmsx603.gar.corp.intel.com (10.221.43.87) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Thu, 29 Dec 2011 19:25:06 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.38]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.199]) with mapi id
	14.01.0355.002; Thu, 29 Dec 2011 19:25:04 +0800
From: "Wei, Gang" <gang.wei@intel.com>
To: Tim Deegan <tim@xen.org>
Thread-Topic: [Xen-devel] [patch] x86: Add a delay between INIT & SIPIs for
	tboot AP bring-up in X2APIC case
Thread-Index: AczAAslz2iL7OBXBT0+nwXPeOaB7qgARIT5gAAGReAAAMzbEEAABRG/A///PswD/+RVpQIANX4oA//6HOSCABJNdAP//Zhrw
Date: Thu, 29 Dec 2011 11:25:03 +0000
Message-ID: <D0B11485C64D4B47B66902F8A4E901BEC710@SHSMSX101.ccr.corp.intel.com>
References: <F26D193E20BBDC42A43B611D1BDEDE7135CEEEAE65@shsmsx502.ccr.corp.intel.com>
	<20111221170539.GA72385@ocelot.phlegethon.org>
	<D0B11485C64D4B47B66902F8A4E901BE9146@SHSMSX101.ccr.corp.intel.com>
	<20111222100112.GA1900@ocelot.phlegethon.org>
	<D0B11485C64D4B47B66902F8A4E901BEA2B8@SHSMSX101.ccr.corp.intel.com>
	<D0B11485C64D4B47B66902F8A4E901BEA302@SHSMSX101.ccr.corp.intel.com>
	<4EF445A60200007800069B41@nat28.tlf.novell.com>
	<D0B11485C64D4B47B66902F8A4E901BEB338@SHSMSX101.ccr.corp.intel.com>
	<20111227104710.GA44631@ocelot.phlegethon.org>
	<D0B11485C64D4B47B66902F8A4E901BEB4E7@SHSMSX101.ccr.corp.intel.com>
	<20111229101106.GA98533@ocelot.phlegethon.org>
In-Reply-To: <20111229101106.GA98533@ocelot.phlegethon.org>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Keir
	\(Xen.org\)" <keir@xen.org>, "TimDeegan \(3P\)" <Tim.Deegan@citrix.com>,
	"Cihula, Joseph" <joseph.cihula@intel.com>,
	"tboot-devel@lists.sourceforge.net" <tboot-devel@lists.sourceforge.net>,
	Jan Beulich <JBeulich@suse.com>, "Wei, Gang" <gang.wei@intel.com>
Subject: Re: [Xen-devel] [patch] x86: Add a delay between INIT & SIPIs for
 tboot AP bring-up in X2APIC case
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Tim Deegan wrote on=A02011-12-29:
> At 01:22 +0000 on 28 Dec (1325035368), Wei, Gang wrote:
>> If no further question on this patch from anyone else, could you
>> help to check it in?
> =

> Done.

Thanks. And I have already be ready to send the MWAIT AP bring-up patch for=
 tboot case, but it might be better to send it out after the New Year, isn'=
t it?

Jimmy



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 29 14:09:12 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 29 Dec 2011 14:09:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RgGec-0004bl-47; Thu, 29 Dec 2011 14:08:22 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andreas.olsowski@leuphana.de>) id 1RgGeb-0004bg-EB
	for xen-devel@lists.xensource.com; Thu, 29 Dec 2011 14:08:21 +0000
X-Env-Sender: andreas.olsowski@leuphana.de
X-Msg-Ref: server-16.tower-174.messagelabs.com!1325167694!7042935!1
X-Originating-IP: [193.174.46.71]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28307 invoked from network); 29 Dec 2011 14:08:14 -0000
Received: from mailhost.leuphana.de (HELO leuphana.de) (193.174.46.71)
	by server-16.tower-174.messagelabs.com with SMTP;
	29 Dec 2011 14:08:14 -0000
Received: from [93.200.123.211] (account aolsowsk@leuphana.de HELO
	[192.168.1.15]) by leuphana.de (CommuniGate Pro SMTP 5.4.1e)
	with ESMTPSA id 49041914; Thu, 29 Dec 2011 15:08:12 +0100
Message-ID: <4EFC7444.2040502@leuphana.de>
Date: Thu, 29 Dec 2011 15:08:04 +0100
From: Andreas Olsowski <andreas.olsowski@leuphana.de>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <4E786015.80603@leuphana.de>
	<1316546879.5182.26.camel@dagon.hellion.org.uk>
	<4E7C37BD.2000706@leuphana.de>
	<1316764045.23371.100.camel@zakaz.uk.xensource.com>
	<4E7C4E44.70508@leuphana.de>
	<1317225159.26672.87.camel@zakaz.uk.xensource.com>
	<4E98DF51.9070907@leuphana.de>
	<1318657499.11016.12.camel@dagon.hellion.org.uk>
	<4E996206.4050500@leuphana.de>
	<1318691569.11016.42.camel@dagon.hellion.org.uk>
In-Reply-To: <1318691569.11016.42.camel@dagon.hellion.org.uk>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] pv guests die after failed migration
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============7638457666854576789=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Dies ist eine kryptografisch unterzeichnete Nachricht im MIME-Format.

--===============7638457666854576789==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms080209020200030700040708"

Dies ist eine kryptografisch unterzeichnete Nachricht im MIME-Format.

--------------ms080209020200030700040708
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

Has any progress been made regarding this issue?



> On Sat, 2011-10-15 at 11:35 +0100, Andreas Olsowski wrote:
>> On 10/15/2011 07:44 AM, Ian Campbell wrote:
>>> On Sat, 2011-10-15 at 02:18 +0100, Andreas Olsowski wrote:
>>>> It seems this still has not made it into 4.1-testing.
>>> I'm afraid I've not had time to "figure out how to automatically sele=
ct
>>> which guests are capable of a cooperative resume and which are not." =
so
>>> it hasn't been fixed in xen-unstable either AFAIK.
>>>
>> Wouldnt just assuming all of them do fix a bigger percentage of system=
s
>> than leaving it the way it is?
> I don't know -- that's really the point.
>
>>> I'm also still interested in confirmation to the question I asked in =
the
>>> mail you just replied to.
>>>
>> Oh, i thought i allready did.
>>
>>   >  Are you saying that you don't see the "failed for domain %u" mess=
age
>>   >  immediately after the xc_domain_resume call?
>>   >
>>   >  +    if (xc_domain_resume(ctx->xch, domid, 1)) {
>>   >             LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
>>   >                             "xc_domain_resume failed for domain %u=
",
>>   >                             domid);
>>   >
>>   >  That would be pretty odd...
>>
>> Yes that is what i am saying:
> Oh wait, that's right -- as far as the toolstack is concerned the resum=
e
> was successful -- the subsequent crash is within the guest.
>
> Ian.
>
Andreas


--------------ms080209020200030700040708
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Kryptografische Unterschrift

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPMjCC
BCEwggMJoAMCAQICAgDHMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK
ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy
MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNjEyMTkxMDI5MDBa
Fw0xOTA2MzAyMzU5MDBaMFoxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpERk4tVmVyZWluMRAw
DgYDVQQLEwdERk4tUEtJMSQwIgYDVQQDExtERk4tVmVyZWluIFBDQSBHbG9iYWwgLSBHMDEw
ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDpm8NnhfkNrvWNVMOWUDU9YuluTO2U
1wBblSJ01CDrNI/W7MAxBAuZgeKmFNJSoCgjhIt0iQReW+DieMF4yxbLKDU5ey2QRdDtoAB6
fL9KDhsAw4bpXCsxEXsM84IkQ4wcOItqaACa7txPeKvSxhObdq3u3ibo7wGvdA/BCaL2a869
080UME/15eOkyGKbghoDJzANAmVgTe3RCSMqljVYJ9N2xnG2kB3E7f81hn1vM7PbD8URwoqD
oZRdQWvY0hD1TP3KUazZve+Sg7va64sWVlZDz+HVEz2mHycwzUlU28kTNJpxdcVs6qcLmPkh
nSevPqM5OUhqjK3JmfvDEvK9AgMBAAGjgdkwgdYwcAYDVR0fBGkwZzBloGOgYYZfaHR0cDov
L3BraS50ZWxlc2VjLmRlL2NnaS1iaW4vc2VydmljZS9hZl9Eb3dubG9hZEFSTC5jcmw/LWNy
bF9mb3JtYXQ9WF81MDkmLWlzc3Vlcj1EVF9ST09UX0NBXzIwHQYDVR0OBBYEFEm3xs/oPR9/
6kR7Eyn38QpwPt5kMB8GA1UdIwQYMBaAFDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB
/wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/AgECMA0GCSqGSIb3DQEBBQUAA4IBAQA74Vp3wEgX
3KkY7IGvWonwvSiSpspZGBJw7Cjy565/lizn8l0ZMfYTK3S9vYCyufdnyTmieTvhERHua3iR
M347XyYndVNljjNj7s9zw7CSI0khUHUjoR8Y4pSFPT8z6XcgjaK95qGFKUD2P3MyWA0Ja6ba
hWzAP7uNZmRWJE6uDT8yNQFb6YyC2XJZT7GGhfF0hVblw/hc843uR7NTBXDn5U2KaYMo4RMJ
hp5eyOpYHgwf+aTUWgRo/Sg+iwK2WLX2oSw3VwBnqyNojWOl75lrXP1LVvarQIc01BGSbOyH
xQoLBzNytG8MHVQs2FHHzL8w00Ny8TK/jM5JY6gA9/IcMIIFXjCCBEagAwIBAgIEC8pR1jAN
BgkqhkiG9w0BAQUFADBaMQswCQYDVQQGEwJERTETMBEGA1UEChMKREZOLVZlcmVpbjEQMA4G
A1UECxMHREZOLVBLSTEkMCIGA1UEAxMbREZOLVZlcmVpbiBQQ0EgR2xvYmFsIC0gRzAxMB4X
DTA4MDIwNzA5NTAwMFoXDTE5MDYzMDAwMDAwMFowgdMxCzAJBgNVBAYTAkRFMRYwFAYDVQQI
Ew1OaWVkZXJzYWNoc2VuMRIwEAYDVQQHEwlMdWVuZWJ1cmcxKDAmBgNVBAoTH0xldXBoYW5h
IFVuaXZlcnNpdGFldCBMdWVuZWJ1cmcxIjAgBgNVBAsTGVJlY2hlbi0gdW5kIE1lZGllbnpl
bnRydW0xKzApBgNVBAMTIkxldXBoYW5hIFVuaXZlcnNpdGFldCBMdWVuZWJ1cmcgQ0ExHTAb
BgkqhkiG9w0BCQEWDmNhQGxldXBoYW5hLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB
CgKCAQEAqJ+JpHih32+icKiQ2IkbhmFLjAcnK0vrnyOKbn7+1xywhvL3zkraqhQlrqEltTDy
711vIEadOVfhIx8xZYYJ/zg1OCwKUxNbIbjcsIFiOKNbWxI3/yMOsaZpXsCLW7GfHLlLADW1
Cv2gUAdnjJUATcUF3a25Bgr9Lbv+GI+3bY9ydMkGnhFYSL96LLqLxAXzGXL/MAM5t/xK8cc8
+6+mWxHAqO+85Jn+UvS1khVTtZfACrYZKFnAsVHOMM/WRugohq4ue6Jfp65exMM7HKWNPrKn
UV0hotcInKFBYywcZrIa2r/6m63nOxl1gHrewxiFWEBvpgMkQ+a7PHhXsMkPdQIDAQABo4IB
sDCCAawwEgYDVR0TAQH/BAgwBgEB/wIBATALBgNVHQ8EBAMCAQYwHQYDVR0OBBYEFPThaBk7
GUPHATbRNGKW8/UDoQeMMB8GA1UdIwQYMBaAFEm3xs/oPR9/6kR7Eyn38QpwPt5kMBkGA1Ud
EQQSMBCBDmNhQGxldXBoYW5hLmRlMIGIBgNVHR8EgYAwfjA9oDugOYY3aHR0cDovL2NkcDEu
cGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIvY3JsL2NhY3JsLmNybDA9oDugOYY3aHR0
cDovL2NkcDIucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIvY3JsL2NhY3JsLmNybDCB
ogYIKwYBBQUHAQEEgZUwgZIwRwYIKwYBBQUHMAKGO2h0dHA6Ly9jZHAxLnBjYS5kZm4uZGUv
Z2xvYmFsLXJvb3QtY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MEcGCCsGAQUFBzAChjtodHRw
Oi8vY2RwMi5wY2EuZGZuLmRlL2dsb2JhbC1yb290LWNhL3B1Yi9jYWNlcnQvY2FjZXJ0LmNy
dDANBgkqhkiG9w0BAQUFAAOCAQEAmSFLUEnTM1zmNRfF4TTDRB53iHmBY0OYTlaPJvXXy4f7
jc1Dpz00HiVyFohY9gqo+jbIAm5avSCmhbL9glEWubE/BNZz9l9lyTCMMxFES0TCiC6W86Ev
o9E4C5IEqxZAOlvRyM3w3u8ItBO9cG190/XMi1Ouk3iBfwRVvFINy9Favq+/8HWFwkFrphpy
6JR90AbbjtE7b7owcMxusgFtPi8A1uyc3cpR21f51K7qgmGbsyXso+U9c/8Fak0IM0qQTN7p
GPmI1lfJ0x1r/QusHVYSFojAT2vQamfGeCNVELg/gH4tlTGkDbHW5QhInkASQv4obBYewNfR
rLG4wgPz5TCCBacwggSPoAMCAQICBBDuKTAwDQYJKoZIhvcNAQEFBQAwgdMxCzAJBgNVBAYT
AkRFMRYwFAYDVQQIEw1OaWVkZXJzYWNoc2VuMRIwEAYDVQQHEwlMdWVuZWJ1cmcxKDAmBgNV
BAoTH0xldXBoYW5hIFVuaXZlcnNpdGFldCBMdWVuZWJ1cmcxIjAgBgNVBAsTGVJlY2hlbi0g
dW5kIE1lZGllbnplbnRydW0xKzApBgNVBAMTIkxldXBoYW5hIFVuaXZlcnNpdGFldCBMdWVu
ZWJ1cmcgQ0ExHTAbBgkqhkiG9w0BCQEWDmNhQGxldXBoYW5hLmRlMB4XDTEwMTEwMTExNTky
OVoXDTEzMTAzMTExNTkyOVowajELMAkGA1UEBhMCREUxKDAmBgNVBAoTH0xldXBoYW5hIFVu
aXZlcnNpdGFldCBMdWVuZWJ1cmcxFjAUBgNVBAsTDVJlY2hlbnplbnRydW0xGTAXBgNVBAMT
EEFuZHJlYXMgT2xzb3dza2kwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDBzfnZ
7pbsecrmresa6JNTMmgoBFpwyr7k7U5O+j7QlFvMlePF/Tz7TeULaEevf7H68IiA/6oGZQvg
NReD/64PYXxbKfsJydY6W1K+jq2karofhW5bk5p210DEQv4qyV6M+aJRKxW0Hp32OeLk5QUH
9T2780PELXGn222r+NCSmBKLP0MHsUa6CFI+jRqztB60v+wc9TD6crMEB37ddckq7mS3QWk1
m2/68bmCsHWRLTpWn9hT4S8eBSL/3YLR9DF8kfWl0wEgy8/tJY1nz5IlSI3S2v1ys7rwXBAp
YHRpeHM/WNNNV4kiH09g2vlxFebQN0xTyoO1+PX6iPeAh0NbAgMBAAGjggHpMIIB5TAJBgNV
HRMEAjAAMAsGA1UdDwQEAwIF4DApBgNVHSUEIjAgBggrBgEFBQcDAgYIKwYBBQUHAwQGCisG
AQQBgjcUAgIwHQYDVR0OBBYEFMrca499fLnPczMLjRm2Nck06YCyMB8GA1UdIwQYMBaAFPTh
aBk7GUPHATbRNGKW8/UDoQeMMCcGA1UdEQQgMB6BHGFuZHJlYXMub2xzb3dza2lAbGV1cGhh
bmEuZGUwgY0GA1UdHwSBhTCBgjA/oD2gO4Y5aHR0cDovL2NkcDEucGNhLmRmbi5kZS91bmkt
bHVlbmVidXJnLWNhL3B1Yi9jcmwvY2FjcmwuY3JsMD+gPaA7hjlodHRwOi8vY2RwMi5wY2Eu
ZGZuLmRlL3VuaS1sdWVuZWJ1cmctY2EvcHViL2NybC9jYWNybC5jcmwwgaYGCCsGAQUFBwEB
BIGZMIGWMEkGCCsGAQUFBzAChj1odHRwOi8vY2RwMS5wY2EuZGZuLmRlL3VuaS1sdWVuZWJ1
cmctY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MEkGCCsGAQUFBzAChj1odHRwOi8vY2RwMi5w
Y2EuZGZuLmRlL3VuaS1sdWVuZWJ1cmctY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MA0GCSqG
SIb3DQEBBQUAA4IBAQANa3ZG/UAmpRcAXqOFOKXBfzN9vZilIdAUxSaXzN9gmXBNptDEcLfD
ccoA228Qc0BSdpvqMdE/21ahqE6oYI1CTfqbuYdoi/cmGoXo6+MdKCKxAD9LokkHdZFhr8re
NrsVkqxyY++Cek777HKZWn1Ft9864LA6vDar3K/sUHlBNxO6VhVzt09NQIFrA50lCkNd6iCG
7Hji624SI49aWjzysBOBdcP68tzSYM+nJLod1NZ3S/W3v+IlPlMeu1JZ5hRnzoTC5qHKKdoQ
kwSmQmv8/uXD46TXutmLXxH3SyBUIM4ks6RN8+VbJ9+61nOQjtazZzvgz9cnYquQC9Dm2s+q
MYIEqDCCBKQCAQEwgdwwgdMxCzAJBgNVBAYTAkRFMRYwFAYDVQQIEw1OaWVkZXJzYWNoc2Vu
MRIwEAYDVQQHEwlMdWVuZWJ1cmcxKDAmBgNVBAoTH0xldXBoYW5hIFVuaXZlcnNpdGFldCBM
dWVuZWJ1cmcxIjAgBgNVBAsTGVJlY2hlbi0gdW5kIE1lZGllbnplbnRydW0xKzApBgNVBAMT
IkxldXBoYW5hIFVuaXZlcnNpdGFldCBMdWVuZWJ1cmcgQ0ExHTAbBgkqhkiG9w0BCQEWDmNh
QGxldXBoYW5hLmRlAgQQ7ikwMAkGBSsOAwIaBQCgggKgMBgGCSqGSIb3DQEJAzELBgkqhkiG
9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMTIyOTE0MDgwNFowIwYJKoZIhvcNAQkEMRYEFD4z
LFXoEsY/kEN2P/7ZuBmwf8/QMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqG
SIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG
9w0DAgIBKDCB7QYJKwYBBAGCNxAEMYHfMIHcMIHTMQswCQYDVQQGEwJERTEWMBQGA1UECBMN
TmllZGVyc2FjaHNlbjESMBAGA1UEBxMJTHVlbmVidXJnMSgwJgYDVQQKEx9MZXVwaGFuYSBV
bml2ZXJzaXRhZXQgTHVlbmVidXJnMSIwIAYDVQQLExlSZWNoZW4tIHVuZCBNZWRpZW56ZW50
cnVtMSswKQYDVQQDEyJMZXVwaGFuYSBVbml2ZXJzaXRhZXQgTHVlbmVidXJnIENBMR0wGwYJ
KoZIhvcNAQkBFg5jYUBsZXVwaGFuYS5kZQIEEO4pMDCB7wYLKoZIhvcNAQkQAgsxgd+ggdww
gdMxCzAJBgNVBAYTAkRFMRYwFAYDVQQIEw1OaWVkZXJzYWNoc2VuMRIwEAYDVQQHEwlMdWVu
ZWJ1cmcxKDAmBgNVBAoTH0xldXBoYW5hIFVuaXZlcnNpdGFldCBMdWVuZWJ1cmcxIjAgBgNV
BAsTGVJlY2hlbi0gdW5kIE1lZGllbnplbnRydW0xKzApBgNVBAMTIkxldXBoYW5hIFVuaXZl
cnNpdGFldCBMdWVuZWJ1cmcgQ0ExHTAbBgkqhkiG9w0BCQEWDmNhQGxldXBoYW5hLmRlAgQQ
7ikwMA0GCSqGSIb3DQEBAQUABIIBALwxmRubk3Y1fPxIo8WEC+lDiwGY8JrzljCbg696vB2e
sUP1E+d70O+wajrk+5YAZvgEEY0LyJOIU4ybszSx4OEIUDAg0BXqTUbGjfB6YD3I2cXG9hw1
oq44zkSOtS962PWe2aGvmzQ0TZKOQj98IWcIzRpghtfqEN84Y77oIEplXIdGBMvIr001bk/Q
btgwvGIm83JJcR+JccMTSNZxHnycyn457IMdOy/Ed9PHjN78FHFr1gjOnPmSYtX8Dy/R/5nt
7CPVHlZ79QTs+vykz888tWBJRITEW+RuLZ4S48m+7wozEfd1x7fI06Ypn8ZEpsmdV9DE1Zou
hywO1cLOX0oAAAAAAAA=
--------------ms080209020200030700040708--


--===============7638457666854576789==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============7638457666854576789==--


From xen-devel-bounces@lists.xensource.com Thu Dec 29 14:09:12 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 29 Dec 2011 14:09:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RgGec-0004bl-47; Thu, 29 Dec 2011 14:08:22 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andreas.olsowski@leuphana.de>) id 1RgGeb-0004bg-EB
	for xen-devel@lists.xensource.com; Thu, 29 Dec 2011 14:08:21 +0000
X-Env-Sender: andreas.olsowski@leuphana.de
X-Msg-Ref: server-16.tower-174.messagelabs.com!1325167694!7042935!1
X-Originating-IP: [193.174.46.71]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28307 invoked from network); 29 Dec 2011 14:08:14 -0000
Received: from mailhost.leuphana.de (HELO leuphana.de) (193.174.46.71)
	by server-16.tower-174.messagelabs.com with SMTP;
	29 Dec 2011 14:08:14 -0000
Received: from [93.200.123.211] (account aolsowsk@leuphana.de HELO
	[192.168.1.15]) by leuphana.de (CommuniGate Pro SMTP 5.4.1e)
	with ESMTPSA id 49041914; Thu, 29 Dec 2011 15:08:12 +0100
Message-ID: <4EFC7444.2040502@leuphana.de>
Date: Thu, 29 Dec 2011 15:08:04 +0100
From: Andreas Olsowski <andreas.olsowski@leuphana.de>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <4E786015.80603@leuphana.de>
	<1316546879.5182.26.camel@dagon.hellion.org.uk>
	<4E7C37BD.2000706@leuphana.de>
	<1316764045.23371.100.camel@zakaz.uk.xensource.com>
	<4E7C4E44.70508@leuphana.de>
	<1317225159.26672.87.camel@zakaz.uk.xensource.com>
	<4E98DF51.9070907@leuphana.de>
	<1318657499.11016.12.camel@dagon.hellion.org.uk>
	<4E996206.4050500@leuphana.de>
	<1318691569.11016.42.camel@dagon.hellion.org.uk>
In-Reply-To: <1318691569.11016.42.camel@dagon.hellion.org.uk>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] pv guests die after failed migration
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============7638457666854576789=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Dies ist eine kryptografisch unterzeichnete Nachricht im MIME-Format.

--===============7638457666854576789==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms080209020200030700040708"

Dies ist eine kryptografisch unterzeichnete Nachricht im MIME-Format.

--------------ms080209020200030700040708
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

Has any progress been made regarding this issue?



> On Sat, 2011-10-15 at 11:35 +0100, Andreas Olsowski wrote:
>> On 10/15/2011 07:44 AM, Ian Campbell wrote:
>>> On Sat, 2011-10-15 at 02:18 +0100, Andreas Olsowski wrote:
>>>> It seems this still has not made it into 4.1-testing.
>>> I'm afraid I've not had time to "figure out how to automatically sele=
ct
>>> which guests are capable of a cooperative resume and which are not." =
so
>>> it hasn't been fixed in xen-unstable either AFAIK.
>>>
>> Wouldnt just assuming all of them do fix a bigger percentage of system=
s
>> than leaving it the way it is?
> I don't know -- that's really the point.
>
>>> I'm also still interested in confirmation to the question I asked in =
the
>>> mail you just replied to.
>>>
>> Oh, i thought i allready did.
>>
>>   >  Are you saying that you don't see the "failed for domain %u" mess=
age
>>   >  immediately after the xc_domain_resume call?
>>   >
>>   >  +    if (xc_domain_resume(ctx->xch, domid, 1)) {
>>   >             LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
>>   >                             "xc_domain_resume failed for domain %u=
",
>>   >                             domid);
>>   >
>>   >  That would be pretty odd...
>>
>> Yes that is what i am saying:
> Oh wait, that's right -- as far as the toolstack is concerned the resum=
e
> was successful -- the subsequent crash is within the guest.
>
> Ian.
>
Andreas


--------------ms080209020200030700040708
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Kryptografische Unterschrift

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPMjCC
BCEwggMJoAMCAQICAgDHMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK
ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy
MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNjEyMTkxMDI5MDBa
Fw0xOTA2MzAyMzU5MDBaMFoxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpERk4tVmVyZWluMRAw
DgYDVQQLEwdERk4tUEtJMSQwIgYDVQQDExtERk4tVmVyZWluIFBDQSBHbG9iYWwgLSBHMDEw
ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDpm8NnhfkNrvWNVMOWUDU9YuluTO2U
1wBblSJ01CDrNI/W7MAxBAuZgeKmFNJSoCgjhIt0iQReW+DieMF4yxbLKDU5ey2QRdDtoAB6
fL9KDhsAw4bpXCsxEXsM84IkQ4wcOItqaACa7txPeKvSxhObdq3u3ibo7wGvdA/BCaL2a869
080UME/15eOkyGKbghoDJzANAmVgTe3RCSMqljVYJ9N2xnG2kB3E7f81hn1vM7PbD8URwoqD
oZRdQWvY0hD1TP3KUazZve+Sg7va64sWVlZDz+HVEz2mHycwzUlU28kTNJpxdcVs6qcLmPkh
nSevPqM5OUhqjK3JmfvDEvK9AgMBAAGjgdkwgdYwcAYDVR0fBGkwZzBloGOgYYZfaHR0cDov
L3BraS50ZWxlc2VjLmRlL2NnaS1iaW4vc2VydmljZS9hZl9Eb3dubG9hZEFSTC5jcmw/LWNy
bF9mb3JtYXQ9WF81MDkmLWlzc3Vlcj1EVF9ST09UX0NBXzIwHQYDVR0OBBYEFEm3xs/oPR9/
6kR7Eyn38QpwPt5kMB8GA1UdIwQYMBaAFDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB
/wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/AgECMA0GCSqGSIb3DQEBBQUAA4IBAQA74Vp3wEgX
3KkY7IGvWonwvSiSpspZGBJw7Cjy565/lizn8l0ZMfYTK3S9vYCyufdnyTmieTvhERHua3iR
M347XyYndVNljjNj7s9zw7CSI0khUHUjoR8Y4pSFPT8z6XcgjaK95qGFKUD2P3MyWA0Ja6ba
hWzAP7uNZmRWJE6uDT8yNQFb6YyC2XJZT7GGhfF0hVblw/hc843uR7NTBXDn5U2KaYMo4RMJ
hp5eyOpYHgwf+aTUWgRo/Sg+iwK2WLX2oSw3VwBnqyNojWOl75lrXP1LVvarQIc01BGSbOyH
xQoLBzNytG8MHVQs2FHHzL8w00Ny8TK/jM5JY6gA9/IcMIIFXjCCBEagAwIBAgIEC8pR1jAN
BgkqhkiG9w0BAQUFADBaMQswCQYDVQQGEwJERTETMBEGA1UEChMKREZOLVZlcmVpbjEQMA4G
A1UECxMHREZOLVBLSTEkMCIGA1UEAxMbREZOLVZlcmVpbiBQQ0EgR2xvYmFsIC0gRzAxMB4X
DTA4MDIwNzA5NTAwMFoXDTE5MDYzMDAwMDAwMFowgdMxCzAJBgNVBAYTAkRFMRYwFAYDVQQI
Ew1OaWVkZXJzYWNoc2VuMRIwEAYDVQQHEwlMdWVuZWJ1cmcxKDAmBgNVBAoTH0xldXBoYW5h
IFVuaXZlcnNpdGFldCBMdWVuZWJ1cmcxIjAgBgNVBAsTGVJlY2hlbi0gdW5kIE1lZGllbnpl
bnRydW0xKzApBgNVBAMTIkxldXBoYW5hIFVuaXZlcnNpdGFldCBMdWVuZWJ1cmcgQ0ExHTAb
BgkqhkiG9w0BCQEWDmNhQGxldXBoYW5hLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB
CgKCAQEAqJ+JpHih32+icKiQ2IkbhmFLjAcnK0vrnyOKbn7+1xywhvL3zkraqhQlrqEltTDy
711vIEadOVfhIx8xZYYJ/zg1OCwKUxNbIbjcsIFiOKNbWxI3/yMOsaZpXsCLW7GfHLlLADW1
Cv2gUAdnjJUATcUF3a25Bgr9Lbv+GI+3bY9ydMkGnhFYSL96LLqLxAXzGXL/MAM5t/xK8cc8
+6+mWxHAqO+85Jn+UvS1khVTtZfACrYZKFnAsVHOMM/WRugohq4ue6Jfp65exMM7HKWNPrKn
UV0hotcInKFBYywcZrIa2r/6m63nOxl1gHrewxiFWEBvpgMkQ+a7PHhXsMkPdQIDAQABo4IB
sDCCAawwEgYDVR0TAQH/BAgwBgEB/wIBATALBgNVHQ8EBAMCAQYwHQYDVR0OBBYEFPThaBk7
GUPHATbRNGKW8/UDoQeMMB8GA1UdIwQYMBaAFEm3xs/oPR9/6kR7Eyn38QpwPt5kMBkGA1Ud
EQQSMBCBDmNhQGxldXBoYW5hLmRlMIGIBgNVHR8EgYAwfjA9oDugOYY3aHR0cDovL2NkcDEu
cGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIvY3JsL2NhY3JsLmNybDA9oDugOYY3aHR0
cDovL2NkcDIucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIvY3JsL2NhY3JsLmNybDCB
ogYIKwYBBQUHAQEEgZUwgZIwRwYIKwYBBQUHMAKGO2h0dHA6Ly9jZHAxLnBjYS5kZm4uZGUv
Z2xvYmFsLXJvb3QtY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MEcGCCsGAQUFBzAChjtodHRw
Oi8vY2RwMi5wY2EuZGZuLmRlL2dsb2JhbC1yb290LWNhL3B1Yi9jYWNlcnQvY2FjZXJ0LmNy
dDANBgkqhkiG9w0BAQUFAAOCAQEAmSFLUEnTM1zmNRfF4TTDRB53iHmBY0OYTlaPJvXXy4f7
jc1Dpz00HiVyFohY9gqo+jbIAm5avSCmhbL9glEWubE/BNZz9l9lyTCMMxFES0TCiC6W86Ev
o9E4C5IEqxZAOlvRyM3w3u8ItBO9cG190/XMi1Ouk3iBfwRVvFINy9Favq+/8HWFwkFrphpy
6JR90AbbjtE7b7owcMxusgFtPi8A1uyc3cpR21f51K7qgmGbsyXso+U9c/8Fak0IM0qQTN7p
GPmI1lfJ0x1r/QusHVYSFojAT2vQamfGeCNVELg/gH4tlTGkDbHW5QhInkASQv4obBYewNfR
rLG4wgPz5TCCBacwggSPoAMCAQICBBDuKTAwDQYJKoZIhvcNAQEFBQAwgdMxCzAJBgNVBAYT
AkRFMRYwFAYDVQQIEw1OaWVkZXJzYWNoc2VuMRIwEAYDVQQHEwlMdWVuZWJ1cmcxKDAmBgNV
BAoTH0xldXBoYW5hIFVuaXZlcnNpdGFldCBMdWVuZWJ1cmcxIjAgBgNVBAsTGVJlY2hlbi0g
dW5kIE1lZGllbnplbnRydW0xKzApBgNVBAMTIkxldXBoYW5hIFVuaXZlcnNpdGFldCBMdWVu
ZWJ1cmcgQ0ExHTAbBgkqhkiG9w0BCQEWDmNhQGxldXBoYW5hLmRlMB4XDTEwMTEwMTExNTky
OVoXDTEzMTAzMTExNTkyOVowajELMAkGA1UEBhMCREUxKDAmBgNVBAoTH0xldXBoYW5hIFVu
aXZlcnNpdGFldCBMdWVuZWJ1cmcxFjAUBgNVBAsTDVJlY2hlbnplbnRydW0xGTAXBgNVBAMT
EEFuZHJlYXMgT2xzb3dza2kwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDBzfnZ
7pbsecrmresa6JNTMmgoBFpwyr7k7U5O+j7QlFvMlePF/Tz7TeULaEevf7H68IiA/6oGZQvg
NReD/64PYXxbKfsJydY6W1K+jq2karofhW5bk5p210DEQv4qyV6M+aJRKxW0Hp32OeLk5QUH
9T2780PELXGn222r+NCSmBKLP0MHsUa6CFI+jRqztB60v+wc9TD6crMEB37ddckq7mS3QWk1
m2/68bmCsHWRLTpWn9hT4S8eBSL/3YLR9DF8kfWl0wEgy8/tJY1nz5IlSI3S2v1ys7rwXBAp
YHRpeHM/WNNNV4kiH09g2vlxFebQN0xTyoO1+PX6iPeAh0NbAgMBAAGjggHpMIIB5TAJBgNV
HRMEAjAAMAsGA1UdDwQEAwIF4DApBgNVHSUEIjAgBggrBgEFBQcDAgYIKwYBBQUHAwQGCisG
AQQBgjcUAgIwHQYDVR0OBBYEFMrca499fLnPczMLjRm2Nck06YCyMB8GA1UdIwQYMBaAFPTh
aBk7GUPHATbRNGKW8/UDoQeMMCcGA1UdEQQgMB6BHGFuZHJlYXMub2xzb3dza2lAbGV1cGhh
bmEuZGUwgY0GA1UdHwSBhTCBgjA/oD2gO4Y5aHR0cDovL2NkcDEucGNhLmRmbi5kZS91bmkt
bHVlbmVidXJnLWNhL3B1Yi9jcmwvY2FjcmwuY3JsMD+gPaA7hjlodHRwOi8vY2RwMi5wY2Eu
ZGZuLmRlL3VuaS1sdWVuZWJ1cmctY2EvcHViL2NybC9jYWNybC5jcmwwgaYGCCsGAQUFBwEB
BIGZMIGWMEkGCCsGAQUFBzAChj1odHRwOi8vY2RwMS5wY2EuZGZuLmRlL3VuaS1sdWVuZWJ1
cmctY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MEkGCCsGAQUFBzAChj1odHRwOi8vY2RwMi5w
Y2EuZGZuLmRlL3VuaS1sdWVuZWJ1cmctY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MA0GCSqG
SIb3DQEBBQUAA4IBAQANa3ZG/UAmpRcAXqOFOKXBfzN9vZilIdAUxSaXzN9gmXBNptDEcLfD
ccoA228Qc0BSdpvqMdE/21ahqE6oYI1CTfqbuYdoi/cmGoXo6+MdKCKxAD9LokkHdZFhr8re
NrsVkqxyY++Cek777HKZWn1Ft9864LA6vDar3K/sUHlBNxO6VhVzt09NQIFrA50lCkNd6iCG
7Hji624SI49aWjzysBOBdcP68tzSYM+nJLod1NZ3S/W3v+IlPlMeu1JZ5hRnzoTC5qHKKdoQ
kwSmQmv8/uXD46TXutmLXxH3SyBUIM4ks6RN8+VbJ9+61nOQjtazZzvgz9cnYquQC9Dm2s+q
MYIEqDCCBKQCAQEwgdwwgdMxCzAJBgNVBAYTAkRFMRYwFAYDVQQIEw1OaWVkZXJzYWNoc2Vu
MRIwEAYDVQQHEwlMdWVuZWJ1cmcxKDAmBgNVBAoTH0xldXBoYW5hIFVuaXZlcnNpdGFldCBM
dWVuZWJ1cmcxIjAgBgNVBAsTGVJlY2hlbi0gdW5kIE1lZGllbnplbnRydW0xKzApBgNVBAMT
IkxldXBoYW5hIFVuaXZlcnNpdGFldCBMdWVuZWJ1cmcgQ0ExHTAbBgkqhkiG9w0BCQEWDmNh
QGxldXBoYW5hLmRlAgQQ7ikwMAkGBSsOAwIaBQCgggKgMBgGCSqGSIb3DQEJAzELBgkqhkiG
9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMTIyOTE0MDgwNFowIwYJKoZIhvcNAQkEMRYEFD4z
LFXoEsY/kEN2P/7ZuBmwf8/QMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqG
SIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG
9w0DAgIBKDCB7QYJKwYBBAGCNxAEMYHfMIHcMIHTMQswCQYDVQQGEwJERTEWMBQGA1UECBMN
TmllZGVyc2FjaHNlbjESMBAGA1UEBxMJTHVlbmVidXJnMSgwJgYDVQQKEx9MZXVwaGFuYSBV
bml2ZXJzaXRhZXQgTHVlbmVidXJnMSIwIAYDVQQLExlSZWNoZW4tIHVuZCBNZWRpZW56ZW50
cnVtMSswKQYDVQQDEyJMZXVwaGFuYSBVbml2ZXJzaXRhZXQgTHVlbmVidXJnIENBMR0wGwYJ
KoZIhvcNAQkBFg5jYUBsZXVwaGFuYS5kZQIEEO4pMDCB7wYLKoZIhvcNAQkQAgsxgd+ggdww
gdMxCzAJBgNVBAYTAkRFMRYwFAYDVQQIEw1OaWVkZXJzYWNoc2VuMRIwEAYDVQQHEwlMdWVu
ZWJ1cmcxKDAmBgNVBAoTH0xldXBoYW5hIFVuaXZlcnNpdGFldCBMdWVuZWJ1cmcxIjAgBgNV
BAsTGVJlY2hlbi0gdW5kIE1lZGllbnplbnRydW0xKzApBgNVBAMTIkxldXBoYW5hIFVuaXZl
cnNpdGFldCBMdWVuZWJ1cmcgQ0ExHTAbBgkqhkiG9w0BCQEWDmNhQGxldXBoYW5hLmRlAgQQ
7ikwMA0GCSqGSIb3DQEBAQUABIIBALwxmRubk3Y1fPxIo8WEC+lDiwGY8JrzljCbg696vB2e
sUP1E+d70O+wajrk+5YAZvgEEY0LyJOIU4ybszSx4OEIUDAg0BXqTUbGjfB6YD3I2cXG9hw1
oq44zkSOtS962PWe2aGvmzQ0TZKOQj98IWcIzRpghtfqEN84Y77oIEplXIdGBMvIr001bk/Q
btgwvGIm83JJcR+JccMTSNZxHnycyn457IMdOy/Ed9PHjN78FHFr1gjOnPmSYtX8Dy/R/5nt
7CPVHlZ79QTs+vykz888tWBJRITEW+RuLZ4S48m+7wozEfd1x7fI06Ypn8ZEpsmdV9DE1Zou
hywO1cLOX0oAAAAAAAA=
--------------ms080209020200030700040708--


--===============7638457666854576789==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============7638457666854576789==--


From xen-devel-bounces@lists.xensource.com Thu Dec 29 15:36:28 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 29 Dec 2011 15:36:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RgI13-0005N1-9x; Thu, 29 Dec 2011 15:35:37 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RgI11-0005Mw-M1
	for xen-devel@lists.xensource.com; Thu, 29 Dec 2011 15:35:35 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1325172928!9117938!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODcwNA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16692 invoked from network); 29 Dec 2011 15:35:28 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Dec 2011 15:35:28 -0000
X-IronPort-AV: E=Sophos;i="4.71,427,1320624000"; 
   d="scan'208";a="9738552"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Dec 2011 15:35:03 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 29 Dec 2011 15:35:03 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RgI0V-0000kw-Am;
	Thu, 29 Dec 2011 15:35:03 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RgI0U-0005rC-V4;
	Thu, 29 Dec 2011 15:35:03 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10613-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 29 Dec 2011 15:35:03 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10613: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10613 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10613/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-i386-i386-xl-winxpsp3    7 windows-install           fail REGR. vs. 10612
 test-amd64-amd64-win          7 windows-install           fail REGR. vs. 10612

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-rhel6hvm-amd  7 redhat-install               fail   like 10598

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass

version targeted for testing:
 xen                  a7b2610b8e5c
baseline version:
 xen                  2863b2f43a3b

------------------------------------------------------------
People who touched revisions under test:
  Gang Wei <gang.wei@intel.com>
  Haitao Shan <haitao.shan@intel.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Shan Haitao <maillists.shan@gmail.com>
  Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   24447:a7b2610b8e5c
tag:         tip
user:        Gang Wei <gang.wei@intel.com>
date:        Thu Dec 29 10:07:54 2011 +0000
    
    X86: Add a delay between INIT & SIPIs for tboot AP bring-up in X2APIC case
    
    Without this delay, Xen could not bring APs up while working with
    TXT/tboot, because tboot needs some time in APs to handle INIT before
    becoming ready for receiving SIPIs (this delay was removed as part of
    c/s 23724 by Tim Deegan).
    
    Signed-off-by: Gang Wei <gang.wei@intel.com>
    Acked-by: Keir Fraser <keir@xen.org>
    Acked-by: Tim Deegan <tim@xen.org>
    Committed-by: Tim Deegan <tim@xen.org>
    
    
changeset:   24446:2863b2f43a3b
user:        Ian Jackson <Ian.Jackson@eu.citrix.com>
date:        Thu Dec 22 14:49:38 2011 +0000
    
    Update QEMU_TAG
    
    
========================================
commit 56d7747a3cf811910c4cf865e1ebcb8b82502005
Author: Ian Jackson <ian.jackson@eu.citrix.com>
Date:   Thu Dec 22 14:46:31 2011 +0000

    qemu: clean up MSI-X table handling
    
    This patch does cleaning up of QEMU MSI handling. The fixes are:
    1. Changes made to MSI-X table mapping handling to eliminate the small
    windows in which guest could have access to physical MSI-X table.
    2. MSI-X table is mapped as read-only to QEMU, as masking of MSI-X is
    already in Xen now.
    3. For registers that coexists inside the MSI-X table (this could be
    only PBA I think), value read from physical page would be returned.
    
    Signed-off-by:  Shan Haitao <maillists.shan@gmail.com>
    
    Consolidated duplicate code into _pt_iomem_helper(). Fixed formatting.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    
    Acked-by: Haitao Shan <haitao.shan@intel.com>
    Acked-by: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 29 15:36:28 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 29 Dec 2011 15:36:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RgI13-0005N1-9x; Thu, 29 Dec 2011 15:35:37 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RgI11-0005Mw-M1
	for xen-devel@lists.xensource.com; Thu, 29 Dec 2011 15:35:35 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1325172928!9117938!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODcwNA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16692 invoked from network); 29 Dec 2011 15:35:28 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Dec 2011 15:35:28 -0000
X-IronPort-AV: E=Sophos;i="4.71,427,1320624000"; 
   d="scan'208";a="9738552"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Dec 2011 15:35:03 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 29 Dec 2011 15:35:03 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RgI0V-0000kw-Am;
	Thu, 29 Dec 2011 15:35:03 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RgI0U-0005rC-V4;
	Thu, 29 Dec 2011 15:35:03 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10613-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 29 Dec 2011 15:35:03 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10613: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10613 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10613/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-i386-i386-xl-winxpsp3    7 windows-install           fail REGR. vs. 10612
 test-amd64-amd64-win          7 windows-install           fail REGR. vs. 10612

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-rhel6hvm-amd  7 redhat-install               fail   like 10598

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass

version targeted for testing:
 xen                  a7b2610b8e5c
baseline version:
 xen                  2863b2f43a3b

------------------------------------------------------------
People who touched revisions under test:
  Gang Wei <gang.wei@intel.com>
  Haitao Shan <haitao.shan@intel.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Shan Haitao <maillists.shan@gmail.com>
  Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   24447:a7b2610b8e5c
tag:         tip
user:        Gang Wei <gang.wei@intel.com>
date:        Thu Dec 29 10:07:54 2011 +0000
    
    X86: Add a delay between INIT & SIPIs for tboot AP bring-up in X2APIC case
    
    Without this delay, Xen could not bring APs up while working with
    TXT/tboot, because tboot needs some time in APs to handle INIT before
    becoming ready for receiving SIPIs (this delay was removed as part of
    c/s 23724 by Tim Deegan).
    
    Signed-off-by: Gang Wei <gang.wei@intel.com>
    Acked-by: Keir Fraser <keir@xen.org>
    Acked-by: Tim Deegan <tim@xen.org>
    Committed-by: Tim Deegan <tim@xen.org>
    
    
changeset:   24446:2863b2f43a3b
user:        Ian Jackson <Ian.Jackson@eu.citrix.com>
date:        Thu Dec 22 14:49:38 2011 +0000
    
    Update QEMU_TAG
    
    
========================================
commit 56d7747a3cf811910c4cf865e1ebcb8b82502005
Author: Ian Jackson <ian.jackson@eu.citrix.com>
Date:   Thu Dec 22 14:46:31 2011 +0000

    qemu: clean up MSI-X table handling
    
    This patch does cleaning up of QEMU MSI handling. The fixes are:
    1. Changes made to MSI-X table mapping handling to eliminate the small
    windows in which guest could have access to physical MSI-X table.
    2. MSI-X table is mapped as read-only to QEMU, as masking of MSI-X is
    already in Xen now.
    3. For registers that coexists inside the MSI-X table (this could be
    only PBA I think), value read from physical page would be returned.
    
    Signed-off-by:  Shan Haitao <maillists.shan@gmail.com>
    
    Consolidated duplicate code into _pt_iomem_helper(). Fixed formatting.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    
    Acked-by: Haitao Shan <haitao.shan@intel.com>
    Acked-by: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 29 15:52:08 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 29 Dec 2011 15:52:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RgIGM-0005YT-PX; Thu, 29 Dec 2011 15:51:26 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jbeulich@suse.com>) id 1RgIGL-0005YO-0s
	for xen-devel@lists.xensource.com; Thu, 29 Dec 2011 15:51:25 +0000
X-Env-Sender: jbeulich@suse.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1325173878!8516595!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 451 invoked from network); 29 Dec 2011 15:51:18 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-13.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 29 Dec 2011 15:51:18 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 29 Dec 2011 15:51:17 +0000
Message-Id: <4EFC8C73020000780007C160@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 29 Dec 2011 15:51:15 +0000
From: "Jan Beulich" <jbeulich@suse.com>
To: <andrew.cooper3@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 3 of 3] KEXEC: Allocate crash structures in
 low memory
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> Andrew Cooper  12/23/11 12:59 PM >>>
>On 23/12/11 09:06, Jan Beulich wrote:
>>>>> On 22.12.11 at 18:36, Andrew Cooper  wrote:
>>> On 64bit Xen with 32bit dom0 and crashkernel, xmalloc'ing items such
>>> as the CPU crash notes will go into the xenheap, which tends to be in
>>> upper memory.  This causes problems on machines with more than 64GB
>>> (or 4GB if no PAE support) of ram as the crashkernel physically cant
>>> access the crash notes.
>> What use is a crash dump taken with a 32-bit kernel on a machine
>> with more than 64G (or more than 4G is the crash kernel doesn't
>> support PAE)?
>
>Very little use at all, which is the reason for this change.

With this change, the usefulness doesn't significantly increase imo.

>The correct solution is indeed to use a 64bit dom0 kernel, but while
>politics is preventing that from happening, another solution has to be
>found.  I doubt that XenServer is the only product which would benifit,
>which is why the changes are presented for upstreaming.
>
>>>  3) Change the conring buffer to use lower memory when instructed.
>> Why does this one need moving, but none of the other Xen data
>> structures? If anything, I would have expected you to limit the Xen
>> heap altogether, so that automatically all allocations get done in a
>> way so that at least Xen's data structures are available in the
>> (truncated) dump.
>
>This is part of the "min" option which is trying to have the least
>possible impact.  The idea is to have this in low memory, use the
>"console_to_ring" boot option to copy dom0 dmesg into conring, and pass
>its physical address and size in a crash note, so that the crash kernel
>environment grab it all.

Why is the console ring *that* important? I would have thought
that proper register values and stack contents are much more
significant for analysis of a crash.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 29 15:52:08 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 29 Dec 2011 15:52:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RgIGM-0005YT-PX; Thu, 29 Dec 2011 15:51:26 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jbeulich@suse.com>) id 1RgIGL-0005YO-0s
	for xen-devel@lists.xensource.com; Thu, 29 Dec 2011 15:51:25 +0000
X-Env-Sender: jbeulich@suse.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1325173878!8516595!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 451 invoked from network); 29 Dec 2011 15:51:18 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-13.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 29 Dec 2011 15:51:18 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 29 Dec 2011 15:51:17 +0000
Message-Id: <4EFC8C73020000780007C160@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 29 Dec 2011 15:51:15 +0000
From: "Jan Beulich" <jbeulich@suse.com>
To: <andrew.cooper3@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 3 of 3] KEXEC: Allocate crash structures in
 low memory
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> Andrew Cooper  12/23/11 12:59 PM >>>
>On 23/12/11 09:06, Jan Beulich wrote:
>>>>> On 22.12.11 at 18:36, Andrew Cooper  wrote:
>>> On 64bit Xen with 32bit dom0 and crashkernel, xmalloc'ing items such
>>> as the CPU crash notes will go into the xenheap, which tends to be in
>>> upper memory.  This causes problems on machines with more than 64GB
>>> (or 4GB if no PAE support) of ram as the crashkernel physically cant
>>> access the crash notes.
>> What use is a crash dump taken with a 32-bit kernel on a machine
>> with more than 64G (or more than 4G is the crash kernel doesn't
>> support PAE)?
>
>Very little use at all, which is the reason for this change.

With this change, the usefulness doesn't significantly increase imo.

>The correct solution is indeed to use a 64bit dom0 kernel, but while
>politics is preventing that from happening, another solution has to be
>found.  I doubt that XenServer is the only product which would benifit,
>which is why the changes are presented for upstreaming.
>
>>>  3) Change the conring buffer to use lower memory when instructed.
>> Why does this one need moving, but none of the other Xen data
>> structures? If anything, I would have expected you to limit the Xen
>> heap altogether, so that automatically all allocations get done in a
>> way so that at least Xen's data structures are available in the
>> (truncated) dump.
>
>This is part of the "min" option which is trying to have the least
>possible impact.  The idea is to have this in low memory, use the
>"console_to_ring" boot option to copy dom0 dmesg into conring, and pass
>its physical address and size in a crash note, so that the crash kernel
>environment grab it all.

Why is the console ring *that* important? I would have thought
that proper register values and stack contents are much more
significant for analysis of a crash.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 29 15:55:03 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 29 Dec 2011 15:55:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RgIJJ-0005eG-Cz; Thu, 29 Dec 2011 15:54:29 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jbeulich@suse.com>) id 1RgIJI-0005e4-K9
	for xen-devel@lists.xensource.com; Thu, 29 Dec 2011 15:54:28 +0000
X-Env-Sender: jbeulich@suse.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1325174062!9100274!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3493 invoked from network); 29 Dec 2011 15:54:22 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-6.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 29 Dec 2011 15:54:22 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 29 Dec 2011 15:54:21 +0000
Message-Id: <4EFC8D2B020000780007C165@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 29 Dec 2011 15:54:19 +0000
From: "Jan Beulich" <jbeulich@suse.com>
To: <gang.wei@intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com, keir@xen.org, Tim.Deegan@citrix.com,
	joseph.cihula@intel.com, tim@xen.org, tboot-devel@lists.sourceforge.net
Subject: Re: [Xen-devel] [patch] x86: Add a delay between INIT & SIPIs for
 tboot AP bring-up in X2APIC case
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> "Wei, Gang"  12/27/11 11:07 AM >>>
>Second way, I tested it. The minimum value I tested is udelay(1). So I think udelay(10) should give enough margin.

Ah, that's what I was after. Worth stating in the code comment perhaps.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 29 15:55:03 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 29 Dec 2011 15:55:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RgIJJ-0005eG-Cz; Thu, 29 Dec 2011 15:54:29 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jbeulich@suse.com>) id 1RgIJI-0005e4-K9
	for xen-devel@lists.xensource.com; Thu, 29 Dec 2011 15:54:28 +0000
X-Env-Sender: jbeulich@suse.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1325174062!9100274!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3493 invoked from network); 29 Dec 2011 15:54:22 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-6.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 29 Dec 2011 15:54:22 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 29 Dec 2011 15:54:21 +0000
Message-Id: <4EFC8D2B020000780007C165@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 29 Dec 2011 15:54:19 +0000
From: "Jan Beulich" <jbeulich@suse.com>
To: <gang.wei@intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com, keir@xen.org, Tim.Deegan@citrix.com,
	joseph.cihula@intel.com, tim@xen.org, tboot-devel@lists.sourceforge.net
Subject: Re: [Xen-devel] [patch] x86: Add a delay between INIT & SIPIs for
 tboot AP bring-up in X2APIC case
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> "Wei, Gang"  12/27/11 11:07 AM >>>
>Second way, I tested it. The minimum value I tested is udelay(1). So I think udelay(10) should give enough margin.

Ah, that's what I was after. Worth stating in the code comment perhaps.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 29 17:59:54 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 29 Dec 2011 17:59:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RgKFs-00080L-1k; Thu, 29 Dec 2011 17:59:04 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <torushikeshj@gmail.com>)
	id 1RgKFq-000805-Ji; Thu, 29 Dec 2011 17:59:03 +0000
X-Env-Sender: torushikeshj@gmail.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1325181520!60598383!1
X-Originating-IP: [74.125.83.43]
X-SpamReason: No, hits=1.7 required=7.0 tests=BODY_RANDOM_LONG,
	HTML_10_20, HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,
	spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31261 invoked from network); 29 Dec 2011 17:58:40 -0000
Received: from mail-ee0-f43.google.com (HELO mail-ee0-f43.google.com)
	(74.125.83.43)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Dec 2011 17:58:40 -0000
Received: by eekd4 with SMTP id d4so70933592eek.30
	for <multiple recipients>; Thu, 29 Dec 2011 09:58:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=hGoUF+vZbGKWE8tFoq9EJuH7Hd1/Cn0mUY3Xl8IjB5c=;
	b=a3PB1everLeOpwTaQOsoR8KFEJGEGOjDvrxlI7qJhT+TKS/Wacs2+aXXvQeKNMqpyK
	aU9Uoj4K55nn9pTNNehTKoTuZ/I1lh9SjovgXQBJLsfrp/djuQDlbE9tIR4cy/kjXFXe
	e3CRV1F1Nb1LfbdtjDMSx6WkDdoOsIvX0H/dY=
MIME-Version: 1.0
Received: by 10.14.9.150 with SMTP id 22mr15109070eet.17.1325181539387; Thu,
	29 Dec 2011 09:58:59 -0800 (PST)
Received: by 10.14.130.145 with HTTP; Thu, 29 Dec 2011 09:58:59 -0800 (PST)
Date: Thu, 29 Dec 2011 23:28:59 +0530
Message-ID: <CAO14VsO7N4LAOtnuTokrhZUy8dO4BLOw165V2F9E3LxJ=ojzyA@mail.gmail.com>
From: R J <torushikeshj@gmail.com>
To: xen-devel@lists.xensource.com, xen-users@lists.xensource.com, 
	xen-api@lists.xensource.com
Content-Type: multipart/mixed; boundary=0016364c78d1eb08b604b53ede35
Subject: [Xen-devel] BalloonWorkerThread issue
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--0016364c78d1eb08b604b53ede35
Content-Type: multipart/alternative; boundary=0016364c78d1eb08b104b53ede33

--0016364c78d1eb08b104b53ede33
Content-Type: text/plain; charset=ISO-8859-1

Hello List,

Merry Christmas to all !!

Basically I'm trying to boot a Windows 2008R2 DC HVM with 90GB static max
memory and 32GB static min.

The node config is Dell M610 with X5660 and 96GB RAM and its running XCP 1.1

Many times the node crashes while booting HVM. Sometimes I get success.
I have attached the HVM boot log of successful start. Many times the node
hangs as soon as the BalloonWorkerThread is activated.

In attached txt the ballon inflation rate is constant 4090
*XENUTIL: BalloonWorkerThread: inflated balloon by 4090 page(s) in 7924ms
(2064k/s)  *

till the time it starts, the inflation rate shoots to 12554884 and the VM
is live.
*XENUTIL: BalloonWorkerThread: inflated balloon by 12554884 page(s) in
32604ms (91243k/s) *
*XENUTIL: BalloonWorkerThread: de-activating *
*XENUTIL: XenevtchnMapResources setting callback irq to 11 *


Can some one help me understand the *BalloonWorkerThread *behavior ?*


*Many thanks,
Rushi

--0016364c78d1eb08b104b53ede33
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hello List,<br><br>Merry Christmas to all !!<br><br>Basically I&#39;m tryin=
g to boot a Windows 2008R2 DC HVM with 90GB static max memory and 32GB stat=
ic min.<br><br>The node config is Dell M610 with X5660 and 96GB RAM and its=
 running XCP 1.1<br>
<br>Many times the node crashes while booting HVM. Sometimes I get success.=
<br>I have attached the HVM boot log of successful start. Many times the no=
de hangs as soon as the BalloonWorkerThread is activated.<br><br>In attache=
d txt the ballon inflation rate is constant 4090 <br>
<i>XENUTIL: BalloonWorkerThread: inflated balloon by 4090 page(s) in 7924ms=
 (2064k/s)=A0 </i><br><br>till the time it starts, the inflation rate shoot=
s to 12554884 and the VM is live.<br><i>XENUTIL: BalloonWorkerThread: infla=
ted balloon by 12554884 page(s) in 32604ms (91243k/s) </i><br>
<i>XENUTIL: BalloonWorkerThread: de-activating </i><br><i>XENUTIL: Xenevtch=
nMapResources setting callback irq to 11 </i><br><br><br>Can some one help =
me understand the <i>BalloonWorkerThread </i>behavior ?<i><br><br><br></i>M=
any thanks,<br>
Rushi<br><br>

--0016364c78d1eb08b104b53ede33--
--0016364c78d1eb08b604b53ede35
Content-Type: text/plain; charset=US-ASCII; name="HVM.txt"
Content-Disposition: attachment; filename="HVM.txt"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_gws2v8ci0

RGVjIDI5IDIzOjA4OjAxIG40IHhlbmd1ZXN0OiBEZXRlcm1pbmVkIHRoZSBmb2xsb3dpbmcgcGFy
YW1ldGVycyBmcm9tIHhlbnN0b3JlOg0KRGVjIDI5IDIzOjA4OjAxIG40IHhlbmd1ZXN0OiB2Y3B1
L251bWJlcjoxNiB2Y3B1L3dlaWdodDowIHZjcHUvY2FwOjAgbng6IDEgdmlyaWRpYW46IDEgYXBp
YzogMSBhY3BpOiAxIHBhZTogMSBhY3BpX3M0OiAwIGFjcGlfczM6IDANCkRlYyAyOSAyMzowODow
MSBuNCB4ZW5ndWVzdDogdmNwdS8wL2FmZmluaXR5OjANCkRlYyAyOSAyMzowODowMSBuNCB4ZW5n
dWVzdDogdmNwdS8xL2FmZmluaXR5OjANCkRlYyAyOSAyMzowODowMSBuNCB4ZW5ndWVzdDogdmNw
dS8yL2FmZmluaXR5OjANCkRlYyAyOSAyMzowODowMSBuNCB4ZW5ndWVzdDogdmNwdS8zL2FmZmlu
aXR5OjANCkRlYyAyOSAyMzowODowMSBuNCB4ZW5ndWVzdDogdmNwdS80L2FmZmluaXR5OjANCkRl
YyAyOSAyMzowODowMSBuNCB4ZW5ndWVzdDogdmNwdS81L2FmZmluaXR5OjANCkRlYyAyOSAyMzow
ODowMSBuNCB4ZW5ndWVzdDogdmNwdS82L2FmZmluaXR5OjANCkRlYyAyOSAyMzowODowMSBuNCB4
ZW5ndWVzdDogdmNwdS83L2FmZmluaXR5OjANCkRlYyAyOSAyMzowODowMSBuNCB4ZW5ndWVzdDog
dmNwdS84L2FmZmluaXR5OjANCkRlYyAyOSAyMzowODowMSBuNCB4ZW5ndWVzdDogdmNwdS85L2Fm
ZmluaXR5OjANCkRlYyAyOSAyMzowODowMSBuNCB4ZW5ndWVzdDogdmNwdS8xMC9hZmZpbml0eTow
DQpEZWMgMjkgMjM6MDg6MDEgbjQgeGVuZ3Vlc3Q6IHZjcHUvMTEvYWZmaW5pdHk6MA0KRGVjIDI5
IDIzOjA4OjAxIG40IHhlbmd1ZXN0OiB2Y3B1LzEyL2FmZmluaXR5OjANCkRlYyAyOSAyMzowODow
MSBuNCB4ZW5ndWVzdDogdmNwdS8xMy9hZmZpbml0eTowDQpEZWMgMjkgMjM6MDg6MDEgbjQgeGVu
Z3Vlc3Q6IHZjcHUvMTQvYWZmaW5pdHk6MA0KRGVjIDI5IDIzOjA4OjAxIG40IHhlbmd1ZXN0OiB2
Y3B1LzE1L2FmZmluaXR5OjANCkRlYyAyOSAyMzowODoxNCBuNCB0YXBkaXNrWzE4MjA0XTogdGFw
ZGlzay1jb250cm9sOiBpbml0LCAxMCB4IDRrIGJ1ZmZlcnMgDQpEZWMgMjkgMjM6MDg6MTQgbjQg
dGFwZGlza1sxODIwNF06IEkvTyBxdWV1ZSBkcml2ZXI6IGxpbyANCkRlYyAyOSAyMzowODoxNCBu
NCB0YXBkaXNrWzE4MjA0XTogdGFwZGlzay1sb2c6IHN0YXJ0ZWQsIGxldmVsIDAgDQpEZWMgMjkg
MjM6MDg6MTQgbjQgdGFwZGlza1sxODIwNF06IHJlY2VpdmVkICdhdHRhY2gnIG1lc3NhZ2UgKHV1
aWQgPSAwKSANCkRlYyAyOSAyMzowODoxNCBuNCB0YXBkaXNrWzE4MjA0XTogc2VuZGluZyAnYXR0
YWNoIHJlc3BvbnNlJyBtZXNzYWdlICh1dWlkID0gMCkgDQpEZWMgMjkgMjM6MDg6MTQgbjQgdGFw
ZGlza1sxODIwNF06IHJlY2VpdmVkICdvcGVuJyBtZXNzYWdlICh1dWlkID0gMCkgDQpEZWMgMjkg
MjM6MDg6MTQgbjQgdGFwZGlza1sxODIwNF06IExvYWRpbmcgZHJpdmVyICd2aGQnIGZvciB2YmQg
MCAvZGV2L1ZHX1hlblN0b3JhZ2UtNDk3NDA4NDEtODA1Ni0wNmUyLTM3M2ItZWM3MjA4NGY2ZmIw
L1ZIRC02MmM1YTUwMS1kNjYyLTRkMzgtYTc1Yy1hMjgwZTI5MjkyOTcgMHgwMDAwMDAwMCANCkRl
YyAyOSAyMzowODoxNCBuNCB0YXBkaXNrWzE4MjA0XTogL2Rldi9WR19YZW5TdG9yYWdlLTQ5NzQw
ODQxLTgwNTYtMDZlMi0zNzNiLWVjNzIwODRmNmZiMC9WSEQtNjJjNWE1MDEtZDY2Mi00ZDM4LWE3
NWMtYTI4MGUyOTI5Mjk3IHZlcnNpb246IHRhcCAweDAwMDEwMDAzLCBiOiAxNTM2MCwgYTogMzA3
LCBmOiAyNiwgbjogMTI2ODM3NiANCkRlYyAyOSAyMzowODoxNCBuNCB0YXBkaXNrWzE4MjA0XTog
b3BlbmVkIGltYWdlIC9kZXYvVkdfWGVuU3RvcmFnZS00OTc0MDg0MS04MDU2LTA2ZTItMzczYi1l
YzcyMDg0ZjZmYjAvVkhELTYyYzVhNTAxLWQ2NjItNGQzOC1hNzVjLWEyODBlMjkyOTI5NyAoMSB1
c2Vycywgc3RhdGU6IDB4MDAwMDAwMDEsIHR5cGU6IDQpIA0KRGVjIDI5IDIzOjA4OjE0IG40IHRh
cGRpc2tbMTgyMDRdOiAvZGV2L21hcHBlci9WR19YZW5TdG9yYWdlLS00OTc0MDg0MS0tODA1Ni0t
MDZlMi0tMzczYi0tZWM3MjA4NGY2ZmIwLVZIRC0tOGVhZTkwNmMtLThmNDQtLTQ2MTgtLWE4NTAt
LTNhYWE1MjkzNDA4YiB2ZXJzaW9uOiB0YXAgMHgwMDAxMDAwMywgYjogMTUzNjAsIGE6IDMzMzEs
IGY6IDMzMDcsIG46IDAgDQpEZWMgMjkgMjM6MDg6MTQgbjQgdGFwZGlza1sxODIwNF06IG9wZW5l
ZCBpbWFnZSAvZGV2L21hcHBlci9WR19YZW5TdG9yYWdlLS00OTc0MDg0MS0tODA1Ni0tMDZlMi0t
MzczYi0tZWM3MjA4NGY2ZmIwLVZIRC0tOGVhZTkwNmMtLThmNDQtLTQ2MTgtLWE4NTAtLTNhYWE1
MjkzNDA4YiAoMSB1c2Vycywgc3RhdGU6IDB4MDAwMDAwMDMsIHR5cGU6IDQpIA0KRGVjIDI5IDIz
OjA4OjE0IG40IHRhcGRpc2tbMTgyMDRdOiBWQkQgQ0hBSU46IA0KRGVjIDI5IDIzOjA4OjE0IG40
IHRhcGRpc2tbMTgyMDRdOiAvZGV2L1ZHX1hlblN0b3JhZ2UtNDk3NDA4NDEtODA1Ni0wNmUyLTM3
M2ItZWM3MjA4NGY2ZmIwL1ZIRC02MmM1YTUwMS1kNjYyLTRkMzgtYTc1Yy1hMjgwZTI5MjkyOTc6
IHR5cGU6dmhkKDQpIHN0b3JhZ2U6bHZtKDMpIA0KRGVjIDI5IDIzOjA4OjE0IG40IHRhcGRpc2tb
MTgyMDRdOiAvZGV2L21hcHBlci9WR19YZW5TdG9yYWdlLS00OTc0MDg0MS0tODA1Ni0tMDZlMi0t
MzczYi0tZWM3MjA4NGY2ZmIwLVZIRC0tOGVhZTkwNmMtLThmNDQtLTQ2MTgtLWE4NTAtLTNhYWE1
MjkzNDA4YjogdHlwZTp2aGQoNCkgc3RvcmFnZTpsdm0oMykgDQpEZWMgMjkgMjM6MDg6MTQgbjQg
dGFwZGlza1sxODIwNF06IHNlbmRpbmcgJ29wZW4gcmVzcG9uc2UnIG1lc3NhZ2UgKHV1aWQgPSAw
KSANCkRlYyAyOSAyMzowODoxNCBuNCB2YmQudWV2ZW50W2FkZF0oYmFja2VuZC92YmQvMTgvNzY4
KTogd3JvdGUgL3hhcGkvMTgvaG90cGx1Zy92YmQvNzY4L2hvdHBsdWcgPSAnb25saW5lJw0KRGVj
IDI5IDIzOjA4OjE1IG40IHZiZC51ZXZlbnRbYWRkXShiYWNrZW5kL3ZiZC8xOC81Njk2KTogd3Jv
dGUgL3hhcGkvMTgvaG90cGx1Zy92YmQvNTY5Ni9ob3RwbHVnID0gJ29ubGluZScNCkRlYyAyOSAy
MzowODoxNSBuNCBvdnMtdnNjdGw6IDAwMDAxfHZzY3RsfElORk98Q2FsbGVkIGFzIC91c3IvYmlu
L292cy12c2N0bCBsaXN0LXBvcnRzIHhhcGk5DQpEZWMgMjkgMjM6MDg6MTUgbjQgb3ZzLXZzY3Rs
OiAwMDAwMXx2c2N0bHxJTkZPfENhbGxlZCBhcyAvdXNyL2Jpbi9vdnMtdnNjdGwgLS10aW1lb3V0
PTMwIC0tIC0taWYtZXhpc3RzIGRlbC1wb3J0IHZpZjE4LjAgLS0gYWRkLXBvcnQgeGFwaTkgdmlm
MTguMCAtLSBzZXQgaW50ZXJmYWNlIHZpZjE4LjAgImV4dGVybmFsLWlkczpcInhzLXZtLXV1aWRc
Ij1cIjY1OTFhNDAzLTBlYmEtMzBiNC05NmE2LWUwMmE3ZGIwNjA3YVwiIiAtLSBzZXQgaW50ZXJm
YWNlIHZpZjE4LjAgImV4dGVybmFsLWlkczpcInhzLXZpZi11dWlkXCI9XCIzYmU1NGU2ZC02ZDEz
LWIwNGItNjczNS0yNDgzMWU1MTY5ZTVcIiIgLS0gc2V0IGludGVyZmFjZSB2aWYxOC4wICJleHRl
cm5hbC1pZHM6XCJ4cy1uZXR3b3JrLXV1aWRcIj1cIjcwNTFlZjk5LTRmY2ItZmE2MS1hMTBlLWY5
ODQ1NmUxMmU5MFwiIiAtLSBzZXQgaW50ZXJmYWNlIHZpZjE4LjAgImV4dGVybmFsLWlkczpcImF0
dGFjaGVkLW1hY1wiPVwiZDY6NmQ6NjA6N2U6NDU6NTJcIiINCkRlYyAyOSAyMzowODoxNSBuNCBx
ZW11LjE4OiBkb21pZDogMTggDQpEZWMgMjkgMjM6MDg6MTUgbjQgcWVtdS4xODogcWVtdTogdGhl
IG51bWJlciBvZiBjcHVzIGlzIDE2IA0KRGVjIDI5IDIzOjA4OjE1IG40IHFlbXUuMTg6IC12aWRl
b3JhbSBvcHRpb24gZG9lcyBub3Qgd29yayB3aXRoIGNpcnJ1cyB2Z2EgZGV2aWNlIG1vZGVsLiBW
aWRlb3JhbSBzZXQgdG8gNE0uIA0KRGVjIDI5IDIzOjA4OjE1IG40IEhWTTE4WzE4MzAyXTogR3Vl
c3QgdXVpZCA9IDY1OTFhNDAzLTBlYmEtMzBiNC05NmE2LWUwMmE3ZGIwNjA3YSANCkRlYyAyOSAy
MzowODoxNSBuNCBIVk0xOFsxODMwMl06IFdhdGNoaW5nIC9sb2NhbC9kb21haW4vMTgvbG9nZGly
dHkvbmV4dC1hY3RpdmUgDQpEZWMgMjkgMjM6MDg6MTUgbjQgSFZNMThbMTgzMDJdOiBXYXRjaGlu
ZyAvbG9jYWwvZG9tYWluLzAvZGV2aWNlLW1vZGVsLzE4L2NvbW1hbmQgDQpEZWMgMjkgMjM6MDg6
MTUgbjQgSFZNMThbMTgzMDJdOiBjaGFyIGRldmljZSByZWRpcmVjdGVkIHRvIC9kZXYvcHRzLzIg
DQpEZWMgMjkgMjM6MDg6MTUgbjQgSFZNMThbMTgzMDJdOiBjaGFyIGRldmljZSByZWRpcmVjdGVk
IHRvIC9kZXYvcHRzLzMgDQpEZWMgMjkgMjM6MDg6MTUgbjQgSFZNMThbMTgzMDJdOiBxZW11X21h
cF9jYWNoZV9pbml0IG5yX2J1Y2tldHMgPSA0MDAwIHNpemUgMzI3NjgwIA0KRGVjIDI5IDIzOjA4
OjE1IG40IEhWTTE4WzE4MzAyXTogc2hhcmVkIHBhZ2UgYXQgcGZuIGZlZmZkIA0KRGVjIDI5IDIz
OjA4OjE1IG40IEhWTTE4WzE4MzAyXTogYnVmZmVyZWQgaW8gcGFnZSBhdCBwZm4gZmVmZmIgDQpE
ZWMgMjkgMjM6MDg6MTUgbjQgSFZNMThbMTgzMDJdOiBUaW1lIG9mZnNldCBzZXQgMCANCkRlYyAy
OSAyMzowODoxNSBuNCBIVk0xOFsxODMwMl06IHBjaV9yZWdpc3Rlcl9kZXZpY2U6IDAwOjAwOjAw
IChpNDQwRlgpIA0KRGVjIDI5IDIzOjA4OjE1IG40IEhWTTE4WzE4MzAyXTogcGNpX3JlZ2lzdGVy
X2RldmljZTogMDA6MDE6MDAgKFBJSVgzKSANCkRlYyAyOSAyMzowODoxNSBuNCBIVk0xOFsxODMw
Ml06IHBjaV9yZWdpc3Rlcl9kZXZpY2U6IDAwOjAyOjAwIChDaXJydXMgVkdBKSANCkRlYyAyOSAy
MzowODoxNSBuNCBIVk0xOFsxODMwMl06IHBvcHVsYXRpbmcgdmlkZW8gUkFNIGF0IGZmMDAwMDAw
IA0KRGVjIDI5IDIzOjA4OjE1IG40IEhWTTE4WzE4MzAyXTogbWFwcGluZyB2aWRlbyBSQU0gZnJv
bSBmZjAwMDAwMCANCkRlYyAyOSAyMzowODoxNSBuNCBIVk0xOFsxODMwMl06IHBjaV9yZWdpc3Rl
cl9kZXZpY2U6IDAwOjAzOjAwICh4ZW4tcGxhdGZvcm0pIA0KRGVjIDI5IDIzOjA4OjE1IG40IEhW
TTE4WzE4MzAyXTogeHNfcmVhZCgvdm0vNjU5MWE0MDMtMGViYS0zMGI0LTk2YTYtZTAyYTdkYjA2
MDdhL2xvZy10aHJvdHRsaW5nKTogcmVhZCBlcnJvciANCkRlYyAyOSAyMzowODoxNSBuNCBIVk0x
OFsxODMwMl06IFJPTSBtZW1vcnkgYXJlYSBub3cgUlcgDQpEZWMgMjkgMjM6MDg6MTUgbjQgSFZN
MThbMTgzMDJdOiBwY2lfcmVnaXN0ZXJfZGV2aWNlOiAwMDowNDowMCAoUlRMODEzOSkgDQpEZWMg
MjkgMjM6MDg6MTUgbjQgSFZNMThbMTgzMDJdOiBwY2lfcmVnaXN0ZXJfZGV2aWNlOiAwMDowMTow
MSAoUElJWDMgSURFKSANCkRlYyAyOSAyMzowODoxNSBuNCBIVk0xOFsxODMwMl06IHBjaV9yZWdp
c3Rlcl9kZXZpY2U6IDAwOjAxOjAyIChVU0ItVUhDSSkgDQpEZWMgMjkgMjM6MDg6MTUgbjQgSFZN
MThbMTgzMDJdOiBwY2lfcmVnaXN0ZXJfZGV2aWNlOiAwMDowMTowMyAoUElJWDQgQUNQSSkgDQpE
ZWMgMjkgMjM6MDg6MTUgbjQgSFZNMThbMTgzMDJdOiB4c19yZWFkKC9sb2NhbC9kb21haW4vMC9k
ZXZpY2UtbW9kZWwvMTgveGVuX2V4dGVuZGVkX3Bvd2VyX21nbXQpOiByZWFkIGVycm9yIA0KRGVj
IDI5IDIzOjA4OjE1IG40IEhWTTE4WzE4MzAyXTogcmVsZWFzaW5nIFZNIA0KRGVjIDI5IDIzOjA4
OjE1IG40IEhWTTE4WzE4MzAyXTogeHNfcmVhZCgpOiB2bmNwYXNzd2QgZ2V0IGVycm9yLiAvdm0v
NjU5MWE0MDMtMGViYS0zMGI0LTk2YTYtZTAyYTdkYjA2MDdhL3ZuY3Bhc3N3ZC4gDQpEZWMgMjkg
MjM6MDg6MTUgbjQgSFZNMThbMTgzMDJdOiBJL08gcmVxdWVzdCBub3QgcmVhZHk6IDAsIHB0cjog
MCwgcG9ydDogMCwgZGF0YTogMCwgY291bnQ6IDAsIHNpemU6IDAgDQpEZWMgMjkgMTc6Mzg6MTUg
bjQgbGFzdCBtZXNzYWdlIHJlcGVhdGVkIDIgdGltZXMNCkRlYyAyOSAxNzozODoxNSBuNCBIVk0x
OFsxODMwMl06IFRyaWdnZXJlZCBsb2ctZGlydHkgYnVmZmVyIHN3aXRjaCANCkRlYyAyOSAxNzoz
ODoxNSBuNCBIVk0xOFsxODMwMl06IEkvTyByZXF1ZXN0IG5vdCByZWFkeTogMCwgcHRyOiAwLCBw
b3J0OiAwLCBkYXRhOiAwLCBjb3VudDogMCwgc2l6ZTogMCANCkRlYyAyOSAxNzozODoxNSBuNCBI
Vk0xOFsxODMwMl06IG1lZGl1bSBjaGFuZ2Ugd2F0Y2ggb24gYGhkZCcgKGluZGV4OiAxKTogIA0K
RGVjIDI5IDE3OjM4OjE1IG40IEhWTTE4WzE4MzAyXTogSS9PIHJlcXVlc3Qgbm90IHJlYWR5OiAw
LCBwdHI6IDAsIHBvcnQ6IDAsIGRhdGE6IDAsIGNvdW50OiAwLCBzaXplOiAwIA0KRGVjIDI5IDE3
OjM4OjE1IG40IGxhc3QgbWVzc2FnZSByZXBlYXRlZCAxMSB0aW1lcw0KRGVjIDI5IDE3OjM4OjE2
IG40IEhWTTE4WzE4MzAyXTogY2lycnVzIHZnYSBtYXAgY2hhbmdlIHdoaWxlIG9uIGxmYiBtb2Rl
IA0KRGVjIDI5IDIzOjA4OjE2IG40IG92cy12c2N0bDogMDAwMDF8dnNjdGx8SU5GT3xDYWxsZWQg
YXMgL3Vzci9iaW4vb3ZzLXZzY3RsIC0tdGltZW91dD0zMCAtLSAtLWlmLWV4aXN0cyBkZWwtcG9y
dCB0YXAxOC4wIC0tIGFkZC1wb3J0IHhhcGk5IHRhcDE4LjANCkRlYyAyOSAxNzozODoxNiBuNCBI
Vk0xOFsxODMwMl06IG1hcHBpbmcgdnJhbSB0byBmMDAwMDAwMCAtIGYwNDAwMDAwIA0KRGVjIDI5
IDE3OjM4OjE3IG40IEhWTTE4WzE4MzAyXTogUk9NIG1lbW9yeSBhcmVhIG5vdyBSVyANCkRlYyAy
OSAxNzozODoxNyBuNCBIVk0xOFsxODMwMl06IFJPTSBtZW1vcnkgYXJlYSBub3cgUk8gDQpEZWMg
MjkgMTc6Mzg6MTggbjQgSFZNMThbMTgzMDJdOiBjaXJydXM6IGJsYW5raW5nIHRoZSBzY3JlZW4g
bGluZV9vZmZzZXQ9MzA3MiBoZWlnaHQ9NzY4IA0KRGVjIDI5IDE3OjM4OjM0IG40IEhWTTE4WzE4
MzAyXTogY2lycnVzOiBibGFua2luZyB0aGUgc2NyZWVuIGxpbmVfb2Zmc2V0PTEwMjQgaGVpZ2h0
PTc2OCANCkRlYyAyOSAxNzozODozNyBuNCBIVk0xOFsxODMwMl06IFVOUExVRzogcHJvdG9jb2wg
dmVyc2lvbiBzZXQgdG8gMSAoZHJpdmVycyBub3QgYmxhY2tsaXN0ZWQpIA0KRGVjIDI5IDE3OjM4
OjM3IG40IEhWTTE4WzE4MzAyXTogVU5QTFVHOiBwcm90b2NvbCAxIGFjdGl2ZSANCkRlYyAyOSAx
NzozODozNyBuNCBIVk0xOFsxODMwMl06IFVOUExVRzogcHJvZHVjdF9pZDogMSBidWlsZF9udW1i
ZXI6IDMwODc2IA0KRGVjIDI5IDE3OjM4OjM3IG40IEhWTTE4WzE4MzAyXTogVU5QTFVHOiBkcml2
ZXJzIG5vdCBibGFja2xpc3RlZCANCkRlYyAyOSAxNzozODozNyBuNCBIVk0xOFsxODMwMl06IGlk
ZV91bnBsdWdfaGFyZGRpc2s6IGRyaXZlIDAgDQpEZWMgMjkgMTc6Mzg6MzcgbjQgSFZNMThbMTgz
MDJdOiBwY2lfZGV2X3VucGx1ZzogMDA6MDQ6MDAgDQpEZWMgMjkgMTc6Mzg6MzcgbjQgSFZNMThb
MTgzMDJdOiBuZXRfdGFwX3NodXRkb3duOiBtb2RlbD10YXAsbmFtZT10YXAuMCANCkRlYyAyOSAy
MzowODozOCBuNCBvdnMtdnNjdGw6IDAwMDAxfHZzY3RsfElORk98Q2FsbGVkIGFzIC91c3IvYmlu
L292cy12c2N0bCAtLXRpbWVvdXQ9MzAgLS0gLS1pZi1leGlzdHMgZGVsLXBvcnQgdGFwMTguMA0K
RGVjIDI5IDE3OjM4OjM4IG40IEhWTTE4WzE4MzAyXTogIFhFVlRDSE46IEluc3RhbGxEdW1wRGV2
aWNlQ2FsbGJhY2s6IHZlcnNpb24gbWlzbWF0Y2ggKDI1NSAhPSAxKSANCkRlYyAyOSAxNzozODoz
OCBuNCBIVk0xOFsxODMwMl06ICAgWEVWVENITjogWGVuZXZ0Y2huQWRkRGV2aWNlOiBGRE8gPSAw
eEZGRkZGQTgwNDQzMjM5NzAgDQpEZWMgMjkgMTc6Mzg6MzggbjQgSFZNMThbMTgzMDJdOiAgIFhF
VlRDSE46IEluaXRpYWxpemVkIHRyYWNpbmcgcHJvdmlkZXIgDQpEZWMgMjkgMTc6Mzg6MzggbjQg
SFZNMThbMTgzMDJdOiAgIFhFVlRDSE46IFN0YXJ0RGV2aWNlRmRvOiA9PT09PiANCkRlYyAyOSAx
NzozODozOCBuNCBIVk0xOFsxODMwMl06ICAgWEVOVVRJTDogWEVWVENITjogSU8gaG9sZTogWzAw
MDAwMDAwZmJmYTYwMDAsMDAwMDAwMDBmYzAwMDAwMCkgbWFwcGVkIGF0IEZGRkZGODgwMDI5NjUw
MDAgDQpEZWMgMjkgMTc6Mzg6MzggbjQgSFZNMThbMTgzMDJdOiBuZXRfdGFwX3NodXRkb3duOiBt
b2RlbD10YXAsbmFtZT10YXAuMCANCkRlYyAyOSAxNzozODozOCBuNCBIVk0xOFsxODMwMl06ICAg
WEVOVVRJTDogS0VSTkVMOiA2LjEgKGJ1aWxkIDc2MDApIHBsYXRmb3JtIFdJTjMyX05UIA0KRGVj
IDI5IDE3OjM4OjM4IG40IEhWTTE4WzE4MzAyXTogICBYRU5VVElMOiBTUDogTk9ORSANCkRlYyAy
OSAxNzozODozOCBuNCBIVk0xOFsxODMwMl06ICAgWEVOVVRJTDogU1VJVEVTOiANCkRlYyAyOSAx
NzozODozOCBuNCBIVk0xOFsxODMwMl06ICAgWEVOVVRJTDogLSBURVJNSU5BTCANCkRlYyAyOSAx
NzozODozOCBuNCBIVk0xOFsxODMwMl06ICAgWEVOVVRJTDogLSBEQVRBQ0VOVEVSIA0KRGVjIDI5
IDE3OjM4OjM4IG40IEhWTTE4WzE4MzAyXTogICBYRU5VVElMOiAtIFNJTkdMRVVTRVJUUyANCkRl
YyAyOSAxNzozODozOCBuNCBIVk0xOFsxODMwMl06ICAgWEVOVVRJTDogVFlQRTogU0VSVkVSIA0K
RGVjIDI5IDE3OjM4OjM4IG40IEhWTTE4WzE4MzAyXTogICBYRU5VVElMOiBQViBEUklWRVJTOiBW
RVJTSU9OOiA1LjYuMCBCVUlMRDogMzA4NzYgKEFwciAzMCAyMDEwLjA2OjU3OjAxKSANCkRlYyAy
OSAxNzozODozOCBuNCBIVk0xOFsxODMwMl06ICAgWEVOVVRJTDogNjQtYml0IEhWTSANCkRlYyAy
OSAxNzozODozOCBuNCBIVk0xOFsxODMwMl06IG5ldF90YXBfc2h1dGRvd246IG1vZGVsPXRhcCxu
YW1lPXRhcC4wIA0KRGVjIDI5IDE3OjM4OjM4IG40IEhWTTE4WzE4MzAyXTogICBYRU5VVElMOiBF
eHBhbmRHcmFudFRhYmxlOiBHUkFOVCBUQUJMRSAwOiAoMCAtIDUxMSkgYXQgRkZGRkY4ODAwMjk2
NjAwMCAoZmJmYTcwMDApIA0KRGVjIDI5IDE3OjM4OjM4IG40IEhWTTE4WzE4MzAyXTogICBYRU5V
VElMOiBYZW5FbnRlcnByaXNlIHByb2R1Y3Qgc3RyaW5nIGlzIHByZXNlbnQgDQpEZWMgMjkgMTc6
Mzg6MzkgbjQgSFZNMThbMTgzMDJdOiAgIFhFTlVUSUw6IFBIWVNJQ0FMIE1FTU9SWTogVE9QID0g
MDAwMDAwMTYuOGZjMDAwMDAgDQpEZWMgMjkgMTc6Mzg6MzkgbjQgSFZNMThbMTgzMDJdOiAgIFhF
TlVUSUw6IEJhbGxvb25UYXJnZXRDaGFuZ2VkOiA5NDM3MTg0MGsgLT4gNDM3OTIzODRrIA0KRGVj
IDI5IDE3OjM4OjM5IG40IEhWTTE4WzE4MzAyXTogICBYRU5VVElMOiBCYWxsb29uV29ya2VyVGhy
ZWFkOiBhY3RpdmF0aW5nIA0KRGVjIDI5IDE3OjM4OjQ3IG40IEhWTTE4WzE4MzAyXTogICBYRU5V
VElMOiBXQVJOSU5HOiBCYWxsb29uUmVsZWFzZVBmbkFycmF5OiByYW4gZm9yIG1vcmUgdGhhbiAy
MjMwbXMgDQpEZWMgMjkgMTc6Mzg6NDcgbjQgSFZNMThbMTgzMDJdOiAgIFhFTlVUSUw6IEJhbGxv
b25Xb3JrZXJUaHJlYWQ6IGluZmxhdGVkIGJhbGxvb24gYnkgNDA5MCBwYWdlKHMpIGluIDc5MjRt
cyAoMjA2NGsvcykgDQpEZWMgMjkgMTc6Mzg6NDcgbjQgSFZNMThbMTgzMDJdOiAgIFhFTlVUSUw6
IEJhbGxvb25Xb3JrZXJUaHJlYWQ6IHBhdXNpbmcgZm9yIDFzICh0YXJnZXQgPSA0Mzc5MjM4NGss
IGN1cnJlbnQgPSA5NDM1NTQ4MGspIA0KRGVjIDI5IDE3OjM4OjU3IG40IEhWTTE4WzE4MzAyXTog
ICBYRU5VVElMOiBXQVJOSU5HOiBCYWxsb29uUmVsZWFzZVBmbkFycmF5OiByYW4gZm9yIG1vcmUg
dGhhbiAxNzk0bXMgDQpEZWMgMjkgMTc6Mzg6NTcgbjQgSFZNMThbMTgzMDJdOiAgIFhFTlVUSUw6
IEJhbGxvb25Xb3JrZXJUaHJlYWQ6IGluZmxhdGVkIGJhbGxvb24gYnkgNDA5MCBwYWdlKHMpIGlu
IDkxNTdtcyAoMTc4NmsvcykgDQpEZWMgMjkgMTc6Mzg6NTcgbjQgSFZNMThbMTgzMDJdOiAgIFhF
TlVUSUw6IEJhbGxvb25Xb3JrZXJUaHJlYWQ6IHBhdXNpbmcgZm9yIDFzICh0YXJnZXQgPSA0Mzc5
MjM4NGssIGN1cnJlbnQgPSA5NDMzOTEyMGspIA0KRGVjIDI5IDE3OjM5OjEzIG40IEhWTTE4WzE4
MzAyXTogICBYRU5VVElMOiBXQVJOSU5HOiBCYWxsb29uUmVsZWFzZVBmbkFycmF5OiByYW4gZm9y
IG1vcmUgdGhhbiA1MDcwbXMgDQpEZWMgMjkgMTc6Mzk6MTMgbjQgSFZNMThbMTgzMDJdOiAgIFhF
TlVUSUw6IEJhbGxvb25Xb3JrZXJUaHJlYWQ6IGluZmxhdGVkIGJhbGxvb24gYnkgNDA5MCBwYWdl
KHMpIGluIDE0NjAxbXMgKDExMjBrL3MpIA0KRGVjIDI5IDE3OjM5OjEzIG40IEhWTTE4WzE4MzAy
XTogICBYRU5VVElMOiBCYWxsb29uV29ya2VyVGhyZWFkOiBwYXVzaW5nIGZvciAxcyAodGFyZ2V0
ID0gNDM3OTIzODRrLCBjdXJyZW50ID0gOTQzMjI3NjBrKSANCkRlYyAyOSAxNzozOTozMCBuNCBI
Vk0xOFsxODMwMl06ICAgWEVOVVRJTDogV0FSTklORzogQmFsbG9vblJlbGVhc2VQZm5BcnJheTog
cmFuIGZvciBtb3JlIHRoYW4gNDMyMW1zIA0KRGVjIDI5IDE3OjM5OjMwIG40IEhWTTE4WzE4MzAy
XTogICBYRU5VVElMOiBCYWxsb29uV29ya2VyVGhyZWFkOiBpbmZsYXRlZCBiYWxsb29uIGJ5IDQw
OTAgcGFnZShzKSBpbiAxNjA1Mm1zICgxMDE5ay9zKSANCkRlYyAyOSAxNzozOTozMCBuNCBIVk0x
OFsxODMwMl06ICAgWEVOVVRJTDogQmFsbG9vbldvcmtlclRocmVhZDogcGF1c2luZyBmb3IgMXMg
KHRhcmdldCA9IDQzNzkyMzg0aywgY3VycmVudCA9IDk0MzA2NDAwaykgDQpEZWMgMjkgMTc6Mzk6
NDAgbjQgSFZNMThbMTgzMDJdOiAgIFhFTlVUSUw6IFdBUk5JTkc6IEJhbGxvb25Qb2RTd2VlcDog
SFlQRVJWSVNPUl9tZW1vcnlfb3AoWEVOTUVNX3BvZF9zd2VlcCwgLi4uKSBmYWlsZWQgKGZmZmZm
ZmY0KSANCkRlYyAyOSAxNzozOTo0NiBuNCBIVk0xOFsxODMwMl06ICAgWEVOVVRJTDogV0FSTklO
RzogQmFsbG9vblJlbGVhc2VQZm5BcnJheTogcmFuIGZvciBtb3JlIHRoYW4gNjA5OW1zIA0KRGVj
IDI5IDE3OjM5OjQ2IG40IEhWTTE4WzE4MzAyXTogICBYRU5VVElMOiBCYWxsb29uV29ya2VyVGhy
ZWFkOiBpbmZsYXRlZCBiYWxsb29uIGJ5IDQwOTAgcGFnZShzKSBpbiAxNTEzMm1zICgxMDgxay9z
KSANCkRlYyAyOSAxNzozOTo0NiBuNCBIVk0xOFsxODMwMl06ICAgWEVOVVRJTDogQmFsbG9vbldv
cmtlclRocmVhZDogcGF1c2luZyBmb3IgMXMgKHRhcmdldCA9IDQzNzkyMzg0aywgY3VycmVudCA9
IDk0MjkwMDQwaykgDQpEZWMgMjkgMTc6NDA6MDQgbjQgSFZNMThbMTgzMDJdOiAgIFhFTlVUSUw6
IFdBUk5JTkc6IEJhbGxvb25SZWxlYXNlUGZuQXJyYXk6IHJhbiBmb3IgbW9yZSB0aGFuIDQ0OTJt
cyANCkRlYyAyOSAxNzo0MDowNCBuNCBIVk0xOFsxODMwMl06ICAgWEVOVVRJTDogQmFsbG9vbldv
cmtlclRocmVhZDogaW5mbGF0ZWQgYmFsbG9vbiBieSA0MDkwIHBhZ2UocykgaW4gMTcyMDZtcyAo
OTUway9zKSANCkRlYyAyOSAxNzo0MDowNCBuNCBIVk0xOFsxODMwMl06ICAgWEVOVVRJTDogQmFs
bG9vbldvcmtlclRocmVhZDogcGF1c2luZyBmb3IgMXMgKHRhcmdldCA9IDQzNzkyMzg0aywgY3Vy
cmVudCA9IDk0MjczNjgwaykgDQpEZWMgMjkgMTc6NDA6MTYgbjQgSFZNMThbMTgzMDJdOiAgIFhF
TlVUSUw6IFdBUk5JTkc6IEJhbGxvb25SZWxlYXNlUGZuQXJyYXk6IHJhbiBmb3IgbW9yZSB0aGFu
IDIwNDNtcyANCkRlYyAyOSAxNzo0MDoxNiBuNCBIVk0xOFsxODMwMl06ICAgWEVOVVRJTDogQmFs
bG9vbldvcmtlclRocmVhZDogaW5mbGF0ZWQgYmFsbG9vbiBieSA0MDkwIHBhZ2UocykgaW4gMTEy
OTRtcyAoMTQ0OGsvcykgDQpEZWMgMjkgMTc6NDA6MTYgbjQgSFZNMThbMTgzMDJdOiAgIFhFTlVU
SUw6IEJhbGxvb25Xb3JrZXJUaHJlYWQ6IHBhdXNpbmcgZm9yIDFzICh0YXJnZXQgPSA0Mzc5MjM4
NGssIGN1cnJlbnQgPSA5NDI1NzMyMGspIA0KRGVjIDI5IDE3OjQwOjI3IG40IEhWTTE4WzE4MzAy
XTogICBYRU5VVElMOiBXQVJOSU5HOiBCYWxsb29uUG9kU3dlZXA6IEhZUEVSVklTT1JfbWVtb3J5
X29wKFhFTk1FTV9wb2Rfc3dlZXAsIC4uLikgZmFpbGVkIChmZmZmZmZmNCkgDQpEZWMgMjkgMTc6
NDA6MzIgbjQgSFZNMThbMTgzMDJdOiAgIFhFTlVUSUw6IFdBUk5JTkc6IEJhbGxvb25SZWxlYXNl
UGZuQXJyYXk6IHJhbiBmb3IgbW9yZSB0aGFuIDUxNzltcyANCkRlYyAyOSAxNzo0MDozMiBuNCBI
Vk0xOFsxODMwMl06ICAgWEVOVVRJTDogQmFsbG9vbldvcmtlclRocmVhZDogaW5mbGF0ZWQgYmFs
bG9vbiBieSA0MDkwIHBhZ2UocykgaW4gMTUxMDBtcyAoMTA4M2svcykgDQpEZWMgMjkgMTc6NDA6
MzIgbjQgSFZNMThbMTgzMDJdOiAgIFhFTlVUSUw6IEJhbGxvb25Xb3JrZXJUaHJlYWQ6IHBhdXNp
bmcgZm9yIDFzICh0YXJnZXQgPSA0Mzc5MjM4NGssIGN1cnJlbnQgPSA5NDI0MDk2MGspIA0KRGVj
IDI5IDE3OjQwOjQ2IG40IEhWTTE4WzE4MzAyXTogICBYRU5VVElMOiBXQVJOSU5HOiBCYWxsb29u
UmVsZWFzZVBmbkFycmF5OiByYW4gZm9yIG1vcmUgdGhhbiAyMjMwbXMgDQpEZWMgMjkgMTc6NDA6
NDYgbjQgSFZNMThbMTgzMDJdOiAgIFhFTlVUSUw6IEJhbGxvb25Xb3JrZXJUaHJlYWQ6IGluZmxh
dGVkIGJhbGxvb24gYnkgNDA5MCBwYWdlKHMpIGluIDEyODcwbXMgKDEyNzFrL3MpIA0KRGVjIDI5
IDE3OjQwOjQ2IG40IEhWTTE4WzE4MzAyXTogICBYRU5VVElMOiBCYWxsb29uV29ya2VyVGhyZWFk
OiBwYXVzaW5nIGZvciAxcyAodGFyZ2V0ID0gNDM3OTIzODRrLCBjdXJyZW50ID0gOTQyMjQ2MDBr
KSANCkRlYyAyOSAxNzo0MTowMSBuNCBIVk0xOFsxODMwMl06ICAgWEVOVVRJTDogV0FSTklORzog
QmFsbG9vblJlbGVhc2VQZm5BcnJheTogcmFuIGZvciBtb3JlIHRoYW4gNTM1MG1zIA0KRGVjIDI5
IDE3OjQxOjAxIG40IEhWTTE4WzE4MzAyXTogICBYRU5VVElMOiBCYWxsb29uV29ya2VyVGhyZWFk
OiBpbmZsYXRlZCBiYWxsb29uIGJ5IDQwOTAgcGFnZShzKSBpbiAxMzIyOG1zICgxMjM2ay9zKSAN
CkRlYyAyOSAxNzo0MTowMSBuNCBIVk0xOFsxODMwMl06ICAgWEVOVVRJTDogQmFsbG9vbldvcmtl
clRocmVhZDogcGF1c2luZyBmb3IgMXMgKHRhcmdldCA9IDQzNzkyMzg0aywgY3VycmVudCA9IDk0
MjA4MjQwaykgDQpEZWMgMjkgMTc6NDE6MTQgbjQgSFZNMThbMTgzMDJdOiAgIFhFTlVUSUw6IFdB
Uk5JTkc6IEJhbGxvb25Qb2RTd2VlcDogSFlQRVJWSVNPUl9tZW1vcnlfb3AoWEVOTUVNX3BvZF9z
d2VlcCwgLi4uKSBmYWlsZWQgKGZmZmZmZmY0KSANCkRlYyAyOSAxNzo0MToxNyBuNCBIVk0xOFsx
ODMwMl06ICAgWEVOVVRJTDogV0FSTklORzogQmFsbG9vblJlbGVhc2VQZm5BcnJheTogcmFuIGZv
ciBtb3JlIHRoYW4gMzAyNm1zIA0KRGVjIDI5IDE3OjQxOjE3IG40IEhWTTE4WzE4MzAyXTogICBY
RU5VVElMOiBCYWxsb29uV29ya2VyVGhyZWFkOiBpbmZsYXRlZCBiYWxsb29uIGJ5IDQwOTAgcGFn
ZShzKSBpbiAxNTQ5MG1zICgxMDU2ay9zKSANCkRlYyAyOSAxNzo0MToxNyBuNCBIVk0xOFsxODMw
Ml06ICAgWEVOVVRJTDogQmFsbG9vbldvcmtlclRocmVhZDogcGF1c2luZyBmb3IgMXMgKHRhcmdl
dCA9IDQzNzkyMzg0aywgY3VycmVudCA9IDk0MTkxODgwaykgDQpEZWMgMjkgMTc6NDE6MzEgbjQg
SFZNMThbMTgzMDJdOiAgIFhFTlVUSUw6IFdBUk5JTkc6IEJhbGxvb25SZWxlYXNlUGZuQXJyYXk6
IHJhbiBmb3IgbW9yZSB0aGFuIDMxNTFtcyANCkRlYyAyOSAxNzo0MTozMSBuNCBIVk0xOFsxODMw
Ml06ICAgWEVOVVRJTDogQmFsbG9vbldvcmtlclRocmVhZDogaW5mbGF0ZWQgYmFsbG9vbiBieSA0
MDkwIHBhZ2UocykgaW4gMTMyOTFtcyAoMTIzMGsvcykgDQpEZWMgMjkgMTc6NDE6MzEgbjQgSFZN
MThbMTgzMDJdOiAgIFhFTlVUSUw6IEJhbGxvb25Xb3JrZXJUaHJlYWQ6IHBhdXNpbmcgZm9yIDFz
ICh0YXJnZXQgPSA0Mzc5MjM4NGssIGN1cnJlbnQgPSA5NDE3NTUyMGspIA0KRGVjIDI5IDE3OjQx
OjQ5IG40IEhWTTE4WzE4MzAyXTogICBYRU5VVElMOiBXQVJOSU5HOiBCYWxsb29uUmVsZWFzZVBm
bkFycmF5OiByYW4gZm9yIG1vcmUgdGhhbiA1NTUzbXMgDQpEZWMgMjkgMTc6NDE6NDkgbjQgSFZN
MThbMTgzMDJdOiAgIFhFTlVUSUw6IEJhbGxvb25Xb3JrZXJUaHJlYWQ6IGluZmxhdGVkIGJhbGxv
b24gYnkgNDA5MCBwYWdlKHMpIGluIDE2ODMybXMgKDk3MWsvcykgDQpEZWMgMjkgMTc6NDE6NDkg
bjQgSFZNMThbMTgzMDJdOiAgIFhFTlVUSUw6IEJhbGxvb25Xb3JrZXJUaHJlYWQ6IHBhdXNpbmcg
Zm9yIDFzICh0YXJnZXQgPSA0Mzc5MjM4NGssIGN1cnJlbnQgPSA5NDE1OTE2MGspIA0KRGVjIDI5
IDE3OjQyOjA4IG40IEhWTTE4WzE4MzAyXTogICBYRU5VVElMOiBXQVJOSU5HOiBCYWxsb29uUmVs
ZWFzZVBmbkFycmF5OiByYW4gZm9yIG1vcmUgdGhhbiA2NzU0bXMgDQpEZWMgMjkgMTc6NDI6MDgg
bjQgSFZNMThbMTgzMDJdOiAgIFhFTlVUSUw6IEJhbGxvb25Xb3JrZXJUaHJlYWQ6IGluZmxhdGVk
IGJhbGxvb24gYnkgNDA5MCBwYWdlKHMpIGluIDE4MTExbXMgKDkwM2svcykgDQpEZWMgMjkgMTc6
NDI6MDggbjQgSFZNMThbMTgzMDJdOiAgIFhFTlVUSUw6IEJhbGxvb25Xb3JrZXJUaHJlYWQ6IHBh
dXNpbmcgZm9yIDFzICh0YXJnZXQgPSA0Mzc5MjM4NGssIGN1cnJlbnQgPSA5NDE0MjgwMGspIA0K
RGVjIDI5IDE3OjQyOjI4IG40IEhWTTE4WzE4MzAyXTogICBYRU5VVElMOiBXQVJOSU5HOiBCYWxs
b29uUmVsZWFzZVBmbkFycmF5OiByYW4gZm9yIG1vcmUgdGhhbiAzMjQ0bXMgDQpEZWMgMjkgMTc6
NDI6MjggbjQgSFZNMThbMTgzMDJdOiAgIFhFTlVUSUw6IEJhbGxvb25Xb3JrZXJUaHJlYWQ6IGlu
ZmxhdGVkIGJhbGxvb24gYnkgNDA5MCBwYWdlKHMpIGluIDE4MzkybXMgKDg4OWsvcykgDQpEZWMg
MjkgMTc6NDI6MjggbjQgSFZNMThbMTgzMDJdOiAgIFhFTlVUSUw6IEJhbGxvb25Xb3JrZXJUaHJl
YWQ6IHBhdXNpbmcgZm9yIDFzICh0YXJnZXQgPSA0Mzc5MjM4NGssIGN1cnJlbnQgPSA5NDEyNjQ0
MGspIA0KRGVjIDI5IDE3OjQyOjQ3IG40IEhWTTE4WzE4MzAyXTogICBYRU5VVElMOiBXQVJOSU5H
OiBCYWxsb29uUmVsZWFzZVBmbkFycmF5OiByYW4gZm9yIG1vcmUgdGhhbiA1NzI1bXMgDQpEZWMg
MjkgMTc6NDI6NDcgbjQgSFZNMThbMTgzMDJdOiAgIFhFTlVUSUw6IEJhbGxvb25Xb3JrZXJUaHJl
YWQ6IGluZmxhdGVkIGJhbGxvb24gYnkgNDA5MCBwYWdlKHMpIGluIDE4NDU0bXMgKDg4Nmsvcykg
DQpEZWMgMjkgMTc6NDI6NDcgbjQgSFZNMThbMTgzMDJdOiAgIFhFTlVUSUw6IEJhbGxvb25Xb3Jr
ZXJUaHJlYWQ6IHBhdXNpbmcgZm9yIDFzICh0YXJnZXQgPSA0Mzc5MjM4NGssIGN1cnJlbnQgPSA5
NDExMDA4MGspIA0KRGVjIDI5IDE3OjQzOjA4IG40IEhWTTE4WzE4MzAyXTogICBYRU5VVElMOiBX
QVJOSU5HOiBCYWxsb29uUmVsZWFzZVBmbkFycmF5OiByYW4gZm9yIG1vcmUgdGhhbiA0MjQzbXMg
DQpEZWMgMjkgMTc6NDM6MDggbjQgSFZNMThbMTgzMDJdOiAgIFhFTlVUSUw6IEJhbGxvb25Xb3Jr
ZXJUaHJlYWQ6IGluZmxhdGVkIGJhbGxvb24gYnkgNDA5MCBwYWdlKHMpIGluIDE5NDUzbXMgKDg0
MWsvcykgDQpEZWMgMjkgMTc6NDM6MDggbjQgSFZNMThbMTgzMDJdOiAgIFhFTlVUSUw6IEJhbGxv
b25Xb3JrZXJUaHJlYWQ6IHBhdXNpbmcgZm9yIDFzICh0YXJnZXQgPSA0Mzc5MjM4NGssIGN1cnJl
bnQgPSA5NDA5MzcyMGspIA0KRGVjIDI5IDE3OjQzOjI2IG40IEhWTTE4WzE4MzAyXTogICBYRU5V
VElMOiBXQVJOSU5HOiBCYWxsb29uUmVsZWFzZVBmbkFycmF5OiByYW4gZm9yIG1vcmUgdGhhbiA1
MjQxbXMgDQpEZWMgMjkgMTc6NDM6MjYgbjQgSFZNMThbMTgzMDJdOiAgIFhFTlVUSUw6IEJhbGxv
b25Xb3JrZXJUaHJlYWQ6IGluZmxhdGVkIGJhbGxvb24gYnkgNDA5MCBwYWdlKHMpIGluIDE3MjA2
bXMgKDk1MGsvcykgDQpEZWMgMjkgMTc6NDM6MjYgbjQgSFZNMThbMTgzMDJdOiAgIFhFTlVUSUw6
IEJhbGxvb25Xb3JrZXJUaHJlYWQ6IHBhdXNpbmcgZm9yIDFzICh0YXJnZXQgPSA0Mzc5MjM4NGss
IGN1cnJlbnQgPSA5NDA3NzM2MGspIA0KRGVjIDI5IDE3OjQzOjQ0IG40IEhWTTE4WzE4MzAyXTog
ICBYRU5VVElMOiBXQVJOSU5HOiBCYWxsb29uUmVsZWFzZVBmbkFycmF5OiByYW4gZm9yIG1vcmUg
dGhhbiAxOTk2bXMgDQpEZWMgMjkgMTc6NDM6NDQgbjQgSFZNMThbMTgzMDJdOiAgIFhFTlVUSUw6
IEJhbGxvb25Xb3JrZXJUaHJlYWQ6IGluZmxhdGVkIGJhbGxvb24gYnkgNDA5MCBwYWdlKHMpIGlu
IDE3MjUzbXMgKDk0OGsvcykgDQpEZWMgMjkgMTc6NDM6NDQgbjQgSFZNMThbMTgzMDJdOiAgIFhF
TlVUSUw6IEJhbGxvb25Xb3JrZXJUaHJlYWQ6IHBhdXNpbmcgZm9yIDFzICh0YXJnZXQgPSA0Mzc5
MjM4NGssIGN1cnJlbnQgPSA5NDA2MTAwMGspIA0KRGVjIDI5IDE3OjQ0OjAyIG40IEhWTTE4WzE4
MzAyXTogICBYRU5VVElMOiBXQVJOSU5HOiBCYWxsb29uUmVsZWFzZVBmbkFycmF5OiByYW4gZm9y
IG1vcmUgdGhhbiA0NzczbXMgDQpEZWMgMjkgMTc6NDQ6MDIgbjQgSFZNMThbMTgzMDJdOiAgIFhF
TlVUSUw6IEJhbGxvb25Xb3JrZXJUaHJlYWQ6IGluZmxhdGVkIGJhbGxvb24gYnkgNDA5MCBwYWdl
KHMpIGluIDE2Mjg2bXMgKDEwMDRrL3MpIA0KRGVjIDI5IDE3OjQ0OjAyIG40IEhWTTE4WzE4MzAy
XTogICBYRU5VVElMOiBCYWxsb29uV29ya2VyVGhyZWFkOiBwYXVzaW5nIGZvciAxcyAodGFyZ2V0
ID0gNDM3OTIzODRrLCBjdXJyZW50ID0gOTQwNDQ2NDBrKSANCkRlYyAyOSAxNzo0NDoyNCBuNCBI
Vk0xOFsxODMwMl06ICAgWEVOVVRJTDogV0FSTklORzogQmFsbG9vblJlbGVhc2VQZm5BcnJheTog
cmFuIGZvciBtb3JlIHRoYW4gMjE1Mm1zIA0KRGVjIDI5IDE3OjQ0OjI0IG40IEhWTTE4WzE4MzAy
XTogICBYRU5VVElMOiBCYWxsb29uV29ya2VyVGhyZWFkOiBpbmZsYXRlZCBiYWxsb29uIGJ5IDQw
OTAgcGFnZShzKSBpbiAyMTIzMW1zICg3NzBrL3MpIA0KRGVjIDI5IDE3OjQ0OjI0IG40IEhWTTE4
WzE4MzAyXTogICBYRU5VVElMOiBCYWxsb29uV29ya2VyVGhyZWFkOiBwYXVzaW5nIGZvciAxcyAo
dGFyZ2V0ID0gNDM3OTIzODRrLCBjdXJyZW50ID0gOTQwMjgyODBrKSANCkRlYyAyOSAxNzo0NDo0
MCBuNCBIVk0xOFsxODMwMl06ICAgWEVOVVRJTDogV0FSTklORzogQmFsbG9vblBvZFN3ZWVwOiBI
WVBFUlZJU09SX21lbW9yeV9vcChYRU5NRU1fcG9kX3N3ZWVwLCAuLi4pIGZhaWxlZCAoZmZmZmZm
ZjQpIA0KRGVjIDI5IDE3OjQ0OjQyIG40IEhWTTE4WzE4MzAyXTogICBYRU5VVElMOiBXQVJOSU5H
OiBCYWxsb29uUmVsZWFzZVBmbkFycmF5OiByYW4gZm9yIG1vcmUgdGhhbiAyMTk5bXMgDQpEZWMg
MjkgMTc6NDQ6NDIgbjQgSFZNMThbMTgzMDJdOiAgIFhFTlVUSUw6IEJhbGxvb25Xb3JrZXJUaHJl
YWQ6IGluZmxhdGVkIGJhbGxvb24gYnkgNDA5MCBwYWdlKHMpIGluIDE3MzMxbXMgKDk0M2svcykg
DQpEZWMgMjkgMTc6NDQ6NDIgbjQgSFZNMThbMTgzMDJdOiAgIFhFTlVUSUw6IEJhbGxvb25Xb3Jr
ZXJUaHJlYWQ6IHBhdXNpbmcgZm9yIDFzICh0YXJnZXQgPSA0Mzc5MjM4NGssIGN1cnJlbnQgPSA5
NDAxMTkyMGspIA0KRGVjIDI5IDE3OjQ1OjE2IG40IEhWTTE4WzE4MzAyXTogICBYRU5VVElMOiBC
YWxsb29uV29ya2VyVGhyZWFkOiBpbmZsYXRlZCBiYWxsb29uIGJ5IDEyNTU0ODg0IHBhZ2Uocykg
aW4gMzI2MDRtcyAoOTEyNDNrL3MpIA0KRGVjIDI5IDE3OjQ1OjE2IG40IEhWTTE4WzE4MzAyXTog
ICBYRU5VVElMOiBCYWxsb29uV29ya2VyVGhyZWFkOiBkZS1hY3RpdmF0aW5nIA0KRGVjIDI5IDE3
OjQ1OjE2IG40IEhWTTE4WzE4MzAyXTogICBYRU5VVElMOiBYZW5ldnRjaG5NYXBSZXNvdXJjZXMg
c2V0dGluZyBjYWxsYmFjayBpcnEgdG8gMTEgDQpEZWMgMjkgMTc6NDU6MTYgbjQgSFZNMThbMTgz
MDJdOiAgIFhFVlRDSE46IFBWIGluaXQuIGRvbmUgDQpEZWMgMjkgMTc6NDU6MTYgbjQgSFZNMThb
MTgzMDJdOiAgIFhFTlVUSUw6IEJhbGxvb25UYXJnZXRDaGFuZ2VkOiA0Mzc5MjM4NGsgLT4gNDg5
MTEzNjBrIA0KRGVjIDI5IDE3OjQ1OjE2IG40IEhWTTE4WzE4MzAyXTogICBYRU5VVElMOiBCYWxs
b29uV29ya2VyVGhyZWFkOiBhY3RpdmF0aW5nIA0KRGVjIDI5IDE3OjQ1OjE2IG40IEhWTTE4WzE4
MzAyXTogICBYRVZUQ0hOOiBEZXRlY3RlZCBuZXcgZGV2aWNlIHZpZi8wLiANCkRlYyAyOSAxNzo0
NToxNiBuNCBIVk0xOFsxODMwMl06ICAgWEVWVENITjogY2xvc2luZyBkZXZpY2UvdmlmLzAuLi4g
DQpEZWMgMjkgMTc6NDU6MTYgbjQgSFZNMThbMTgzMDJdOiAgIFhFVlRDSE46IGRldmljZS92aWYv
MCBjbG9zZWQgDQpEZWMgMjkgMTc6NDU6MTYgbjQgSFZNMThbMTgzMDJdOiAgIFhFVlRDSE46IFN0
YXJ0RGV2aWNlRmRvOiA8PT09PSAoMDAwMDAwMDApIA0KRGVjIDI5IDE3OjQ1OjE3IG40IEhWTTE4
WzE4MzAyXTogICBYRU5VVElMOiBCYWxsb29uV29ya2VyVGhyZWFkOiBkZWZsYXRlZCBiYWxsb29u
IGJ5IDEyNzk3NDQgcGFnZShzKSBpbiA5OThtcyAoODI1NjYway9zKSANCkRlYyAyOSAxNzo0NTox
NyBuNCBIVk0xOFsxODMwMl06ICAgWEVOVVRJTDogQmFsbG9vbldvcmtlclRocmVhZDogZGUtYWN0
aXZhdGluZyANCkRlYyAyOSAxNzo0NToxOCBuNCBIVk0xOFsxODMwMl06ICAgIFhFTlZCRDogWEVO
VkJEIGluIE5PUk1BTCBtb2RlLiANCkRlYyAyOSAxNzo0NToxOCBuNCBIVk0xOFsxODMwMl06ICAg
IFhFTlZCRDogWGVudmJkQWRkRGV2aWNlOiBGRE8gPSAweEZGRkZGQTgwNDQzNEIwNjAgDQpEZWMg
MjkgMTc6NDU6MTggbjQgSFZNMThbMTgzMDJdOiAgIFhFTlVUSUw6IFdBUk5JTkc6IElPIGhvbGUg
YWxyZWFkeSBpbml0aWFsaXplZCBieSBYRVZUQ0hOIA0KRGVjIDI5IDE3OjQ1OjE4IG40IEhWTTE4
WzE4MzAyXTogICBYRU5VVElMOiBXQVJOSU5HOiBCdWdjaGVjayBjYWxsYmFjayBhbHJlYWR5IGlu
c3RhbGxlZCANCkRlYyAyOSAxNzo0NToxOCBuNCBIVk0xOFsxODMwMl06ICAgWEVOVVRJTDogV0FS
TklORzogQnVnY2hlY2sgcmVhc29uIGNhbGxiYWNrIGFscmVhZHkgaW5zdGFsbGVkIA0KRGVjIDI5
IDE3OjQ1OjE4IG40IEhWTTE4WzE4MzAyXTogICAgWEVOVkJEOiBSZXNjYW5UaHJlYWQ6IHN0YXJ0
aW5nIA0KRGVjIDI5IDE3OjQ1OjE4IG40IEhWTTE4WzE4MzAyXTogICBYRU5VVElMOiBYZW52YmRI
d0luaXRpYWxpemUgc2V0dGluZyBjYWxsYmFjayBpcnEgdG8gMzAgDQpEZWMgMjkgMTc6NDU6MTkg
bjQgSFZNMThbMTgzMDJdOiAgICBYRU5WQkQ6IERldmljZVJlbGF0aW9uc0Zkbzogc2Nhbm5pbmcg
dGFyZ2V0cy4uLiANCkRlYyAyOSAxNzo0NToxOSBuNCBIVk0xOFsxODMwMl06ICAgIFhFTlZCRDog
WGVuYnVzRmluZFZiZHM6IGZvdW5kIG5ldyBkaXNrIChWQkQgNzY4KSANCkRlYyAyOSAxNzo0NTox
OSBuNCBIVk0xOFsxODMwMl06ICAgIFhFTlZCRDogWGVuYnVzRmluZFZiZHM6IGlnbm9yaW5nIGNk
cm9tIChWQkQgNTY5NikgDQpEZWMgMjkgMTc6NDU6MTkgbjQgSFZNMThbMTgzMDJdOiAgICBYRU5W
QkQ6IHRhcmdldCAwOiBjbGFpbWluZyBmcm9udGVuZC4uLiANCkRlYyAyOSAxNzo0NToxOSBuNCBI
Vk0xOFsxODMwMl06ICAgIFhFTlZCRDogdGFyZ2V0IDA6IHN1Y2Nlc3NmdWx5IGNsYWltZWQgZGV2
aWNlL3ZiZC83NjggDQpEZWMgMjkgMTc6NDU6MTkgbjQgSFZNMThbMTgzMDJdOiAgICBYRU5WQkQ6
IHRhcmdldCAwOiBzeW50aGVzaXNpbmcgaW5xdWlyeSBkYXRhOiBkZWZhdWx0IHBhZ2UgDQpEZWMg
MjkgMTc6NDU6MTkgbjQgSFZNMThbMTgzMDJdOiAgICBYRU5WQkQ6IHRhcmdldCAwOiB1bml0IHNl
cmlhbCBudW1iZXIgPSAnNjJjNWE1MDEtZDY2Mi00ZCAgJyANCkRlYyAyOSAxNzo0NToxOSBuNCBI
Vk0xOFsxODMwMl06ICAgIFhFTlZCRDogdGFyZ2V0IDA6IGRldmljZSBpZGVudGlmaWVyWzBdOiBD
b2RlU2V0OiAnQXNjaWknIFR5cGU6ICdWZW5kb3JJZCcgQXNzb2NhdGlvbjogJ0RldmljZScgDQpE
ZWMgMjkgMTc6NDU6MTkgbjQgSFZNMThbMTgzMDJdOiAgICBYRU5WQkQ6IHRhcmdldCAwOiBkZXZp
Y2UgaWRlbnRpZmllclswXTogTGVuZ3RoID0gNDUgRGF0YSA9ICdYRU5TUkMgIDYyYzVhNTAxLWQ2
NjItNGQzOC1hNzVjLWEyODBlMjkyOTI5NyAnIA0KRGVjIDI5IDE3OjQ1OjE5IG40IEhWTTE4WzE4
MzAyXTogICAgWEVOVkJEOiB0YXJnZXQgMDogY2xvc2luZyBmcm9udGVuZC4uLiANCkRlYyAyOSAx
Nzo0NToxOSBuNCBIVk0xOFsxODMwMl06ICAgIFhFTlZCRDogdGFyZ2V0IDA6IGJhY2tlbmQgaXMg
Y2xvc2VkIA0KRGVjIDI5IDE3OjQ1OjE5IG40IEhWTTE4WzE4MzAyXTogICAgWEVOVkJEOiB0YXJn
ZXQgMDogY3JlYXRlZCANCg==
--0016364c78d1eb08b604b53ede35
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--0016364c78d1eb08b604b53ede35--


From xen-devel-bounces@lists.xensource.com Thu Dec 29 17:59:54 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 29 Dec 2011 17:59:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RgKFs-00080L-1k; Thu, 29 Dec 2011 17:59:04 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <torushikeshj@gmail.com>)
	id 1RgKFq-000805-Ji; Thu, 29 Dec 2011 17:59:03 +0000
X-Env-Sender: torushikeshj@gmail.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1325181520!60598383!1
X-Originating-IP: [74.125.83.43]
X-SpamReason: No, hits=1.7 required=7.0 tests=BODY_RANDOM_LONG,
	HTML_10_20, HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,
	spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31261 invoked from network); 29 Dec 2011 17:58:40 -0000
Received: from mail-ee0-f43.google.com (HELO mail-ee0-f43.google.com)
	(74.125.83.43)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Dec 2011 17:58:40 -0000
Received: by eekd4 with SMTP id d4so70933592eek.30
	for <multiple recipients>; Thu, 29 Dec 2011 09:58:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=hGoUF+vZbGKWE8tFoq9EJuH7Hd1/Cn0mUY3Xl8IjB5c=;
	b=a3PB1everLeOpwTaQOsoR8KFEJGEGOjDvrxlI7qJhT+TKS/Wacs2+aXXvQeKNMqpyK
	aU9Uoj4K55nn9pTNNehTKoTuZ/I1lh9SjovgXQBJLsfrp/djuQDlbE9tIR4cy/kjXFXe
	e3CRV1F1Nb1LfbdtjDMSx6WkDdoOsIvX0H/dY=
MIME-Version: 1.0
Received: by 10.14.9.150 with SMTP id 22mr15109070eet.17.1325181539387; Thu,
	29 Dec 2011 09:58:59 -0800 (PST)
Received: by 10.14.130.145 with HTTP; Thu, 29 Dec 2011 09:58:59 -0800 (PST)
Date: Thu, 29 Dec 2011 23:28:59 +0530
Message-ID: <CAO14VsO7N4LAOtnuTokrhZUy8dO4BLOw165V2F9E3LxJ=ojzyA@mail.gmail.com>
From: R J <torushikeshj@gmail.com>
To: xen-devel@lists.xensource.com, xen-users@lists.xensource.com, 
	xen-api@lists.xensource.com
Content-Type: multipart/mixed; boundary=0016364c78d1eb08b604b53ede35
Subject: [Xen-devel] BalloonWorkerThread issue
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--0016364c78d1eb08b604b53ede35
Content-Type: multipart/alternative; boundary=0016364c78d1eb08b104b53ede33

--0016364c78d1eb08b104b53ede33
Content-Type: text/plain; charset=ISO-8859-1

Hello List,

Merry Christmas to all !!

Basically I'm trying to boot a Windows 2008R2 DC HVM with 90GB static max
memory and 32GB static min.

The node config is Dell M610 with X5660 and 96GB RAM and its running XCP 1.1

Many times the node crashes while booting HVM. Sometimes I get success.
I have attached the HVM boot log of successful start. Many times the node
hangs as soon as the BalloonWorkerThread is activated.

In attached txt the ballon inflation rate is constant 4090
*XENUTIL: BalloonWorkerThread: inflated balloon by 4090 page(s) in 7924ms
(2064k/s)  *

till the time it starts, the inflation rate shoots to 12554884 and the VM
is live.
*XENUTIL: BalloonWorkerThread: inflated balloon by 12554884 page(s) in
32604ms (91243k/s) *
*XENUTIL: BalloonWorkerThread: de-activating *
*XENUTIL: XenevtchnMapResources setting callback irq to 11 *


Can some one help me understand the *BalloonWorkerThread *behavior ?*


*Many thanks,
Rushi

--0016364c78d1eb08b104b53ede33
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hello List,<br><br>Merry Christmas to all !!<br><br>Basically I&#39;m tryin=
g to boot a Windows 2008R2 DC HVM with 90GB static max memory and 32GB stat=
ic min.<br><br>The node config is Dell M610 with X5660 and 96GB RAM and its=
 running XCP 1.1<br>
<br>Many times the node crashes while booting HVM. Sometimes I get success.=
<br>I have attached the HVM boot log of successful start. Many times the no=
de hangs as soon as the BalloonWorkerThread is activated.<br><br>In attache=
d txt the ballon inflation rate is constant 4090 <br>
<i>XENUTIL: BalloonWorkerThread: inflated balloon by 4090 page(s) in 7924ms=
 (2064k/s)=A0 </i><br><br>till the time it starts, the inflation rate shoot=
s to 12554884 and the VM is live.<br><i>XENUTIL: BalloonWorkerThread: infla=
ted balloon by 12554884 page(s) in 32604ms (91243k/s) </i><br>
<i>XENUTIL: BalloonWorkerThread: de-activating </i><br><i>XENUTIL: Xenevtch=
nMapResources setting callback irq to 11 </i><br><br><br>Can some one help =
me understand the <i>BalloonWorkerThread </i>behavior ?<i><br><br><br></i>M=
any thanks,<br>
Rushi<br><br>

--0016364c78d1eb08b104b53ede33--
--0016364c78d1eb08b604b53ede35
Content-Type: text/plain; charset=US-ASCII; name="HVM.txt"
Content-Disposition: attachment; filename="HVM.txt"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_gws2v8ci0

RGVjIDI5IDIzOjA4OjAxIG40IHhlbmd1ZXN0OiBEZXRlcm1pbmVkIHRoZSBmb2xsb3dpbmcgcGFy
YW1ldGVycyBmcm9tIHhlbnN0b3JlOg0KRGVjIDI5IDIzOjA4OjAxIG40IHhlbmd1ZXN0OiB2Y3B1
L251bWJlcjoxNiB2Y3B1L3dlaWdodDowIHZjcHUvY2FwOjAgbng6IDEgdmlyaWRpYW46IDEgYXBp
YzogMSBhY3BpOiAxIHBhZTogMSBhY3BpX3M0OiAwIGFjcGlfczM6IDANCkRlYyAyOSAyMzowODow
MSBuNCB4ZW5ndWVzdDogdmNwdS8wL2FmZmluaXR5OjANCkRlYyAyOSAyMzowODowMSBuNCB4ZW5n
dWVzdDogdmNwdS8xL2FmZmluaXR5OjANCkRlYyAyOSAyMzowODowMSBuNCB4ZW5ndWVzdDogdmNw
dS8yL2FmZmluaXR5OjANCkRlYyAyOSAyMzowODowMSBuNCB4ZW5ndWVzdDogdmNwdS8zL2FmZmlu
aXR5OjANCkRlYyAyOSAyMzowODowMSBuNCB4ZW5ndWVzdDogdmNwdS80L2FmZmluaXR5OjANCkRl
YyAyOSAyMzowODowMSBuNCB4ZW5ndWVzdDogdmNwdS81L2FmZmluaXR5OjANCkRlYyAyOSAyMzow
ODowMSBuNCB4ZW5ndWVzdDogdmNwdS82L2FmZmluaXR5OjANCkRlYyAyOSAyMzowODowMSBuNCB4
ZW5ndWVzdDogdmNwdS83L2FmZmluaXR5OjANCkRlYyAyOSAyMzowODowMSBuNCB4ZW5ndWVzdDog
dmNwdS84L2FmZmluaXR5OjANCkRlYyAyOSAyMzowODowMSBuNCB4ZW5ndWVzdDogdmNwdS85L2Fm
ZmluaXR5OjANCkRlYyAyOSAyMzowODowMSBuNCB4ZW5ndWVzdDogdmNwdS8xMC9hZmZpbml0eTow
DQpEZWMgMjkgMjM6MDg6MDEgbjQgeGVuZ3Vlc3Q6IHZjcHUvMTEvYWZmaW5pdHk6MA0KRGVjIDI5
IDIzOjA4OjAxIG40IHhlbmd1ZXN0OiB2Y3B1LzEyL2FmZmluaXR5OjANCkRlYyAyOSAyMzowODow
MSBuNCB4ZW5ndWVzdDogdmNwdS8xMy9hZmZpbml0eTowDQpEZWMgMjkgMjM6MDg6MDEgbjQgeGVu
Z3Vlc3Q6IHZjcHUvMTQvYWZmaW5pdHk6MA0KRGVjIDI5IDIzOjA4OjAxIG40IHhlbmd1ZXN0OiB2
Y3B1LzE1L2FmZmluaXR5OjANCkRlYyAyOSAyMzowODoxNCBuNCB0YXBkaXNrWzE4MjA0XTogdGFw
ZGlzay1jb250cm9sOiBpbml0LCAxMCB4IDRrIGJ1ZmZlcnMgDQpEZWMgMjkgMjM6MDg6MTQgbjQg
dGFwZGlza1sxODIwNF06IEkvTyBxdWV1ZSBkcml2ZXI6IGxpbyANCkRlYyAyOSAyMzowODoxNCBu
NCB0YXBkaXNrWzE4MjA0XTogdGFwZGlzay1sb2c6IHN0YXJ0ZWQsIGxldmVsIDAgDQpEZWMgMjkg
MjM6MDg6MTQgbjQgdGFwZGlza1sxODIwNF06IHJlY2VpdmVkICdhdHRhY2gnIG1lc3NhZ2UgKHV1
aWQgPSAwKSANCkRlYyAyOSAyMzowODoxNCBuNCB0YXBkaXNrWzE4MjA0XTogc2VuZGluZyAnYXR0
YWNoIHJlc3BvbnNlJyBtZXNzYWdlICh1dWlkID0gMCkgDQpEZWMgMjkgMjM6MDg6MTQgbjQgdGFw
ZGlza1sxODIwNF06IHJlY2VpdmVkICdvcGVuJyBtZXNzYWdlICh1dWlkID0gMCkgDQpEZWMgMjkg
MjM6MDg6MTQgbjQgdGFwZGlza1sxODIwNF06IExvYWRpbmcgZHJpdmVyICd2aGQnIGZvciB2YmQg
MCAvZGV2L1ZHX1hlblN0b3JhZ2UtNDk3NDA4NDEtODA1Ni0wNmUyLTM3M2ItZWM3MjA4NGY2ZmIw
L1ZIRC02MmM1YTUwMS1kNjYyLTRkMzgtYTc1Yy1hMjgwZTI5MjkyOTcgMHgwMDAwMDAwMCANCkRl
YyAyOSAyMzowODoxNCBuNCB0YXBkaXNrWzE4MjA0XTogL2Rldi9WR19YZW5TdG9yYWdlLTQ5NzQw
ODQxLTgwNTYtMDZlMi0zNzNiLWVjNzIwODRmNmZiMC9WSEQtNjJjNWE1MDEtZDY2Mi00ZDM4LWE3
NWMtYTI4MGUyOTI5Mjk3IHZlcnNpb246IHRhcCAweDAwMDEwMDAzLCBiOiAxNTM2MCwgYTogMzA3
LCBmOiAyNiwgbjogMTI2ODM3NiANCkRlYyAyOSAyMzowODoxNCBuNCB0YXBkaXNrWzE4MjA0XTog
b3BlbmVkIGltYWdlIC9kZXYvVkdfWGVuU3RvcmFnZS00OTc0MDg0MS04MDU2LTA2ZTItMzczYi1l
YzcyMDg0ZjZmYjAvVkhELTYyYzVhNTAxLWQ2NjItNGQzOC1hNzVjLWEyODBlMjkyOTI5NyAoMSB1
c2Vycywgc3RhdGU6IDB4MDAwMDAwMDEsIHR5cGU6IDQpIA0KRGVjIDI5IDIzOjA4OjE0IG40IHRh
cGRpc2tbMTgyMDRdOiAvZGV2L21hcHBlci9WR19YZW5TdG9yYWdlLS00OTc0MDg0MS0tODA1Ni0t
MDZlMi0tMzczYi0tZWM3MjA4NGY2ZmIwLVZIRC0tOGVhZTkwNmMtLThmNDQtLTQ2MTgtLWE4NTAt
LTNhYWE1MjkzNDA4YiB2ZXJzaW9uOiB0YXAgMHgwMDAxMDAwMywgYjogMTUzNjAsIGE6IDMzMzEs
IGY6IDMzMDcsIG46IDAgDQpEZWMgMjkgMjM6MDg6MTQgbjQgdGFwZGlza1sxODIwNF06IG9wZW5l
ZCBpbWFnZSAvZGV2L21hcHBlci9WR19YZW5TdG9yYWdlLS00OTc0MDg0MS0tODA1Ni0tMDZlMi0t
MzczYi0tZWM3MjA4NGY2ZmIwLVZIRC0tOGVhZTkwNmMtLThmNDQtLTQ2MTgtLWE4NTAtLTNhYWE1
MjkzNDA4YiAoMSB1c2Vycywgc3RhdGU6IDB4MDAwMDAwMDMsIHR5cGU6IDQpIA0KRGVjIDI5IDIz
OjA4OjE0IG40IHRhcGRpc2tbMTgyMDRdOiBWQkQgQ0hBSU46IA0KRGVjIDI5IDIzOjA4OjE0IG40
IHRhcGRpc2tbMTgyMDRdOiAvZGV2L1ZHX1hlblN0b3JhZ2UtNDk3NDA4NDEtODA1Ni0wNmUyLTM3
M2ItZWM3MjA4NGY2ZmIwL1ZIRC02MmM1YTUwMS1kNjYyLTRkMzgtYTc1Yy1hMjgwZTI5MjkyOTc6
IHR5cGU6dmhkKDQpIHN0b3JhZ2U6bHZtKDMpIA0KRGVjIDI5IDIzOjA4OjE0IG40IHRhcGRpc2tb
MTgyMDRdOiAvZGV2L21hcHBlci9WR19YZW5TdG9yYWdlLS00OTc0MDg0MS0tODA1Ni0tMDZlMi0t
MzczYi0tZWM3MjA4NGY2ZmIwLVZIRC0tOGVhZTkwNmMtLThmNDQtLTQ2MTgtLWE4NTAtLTNhYWE1
MjkzNDA4YjogdHlwZTp2aGQoNCkgc3RvcmFnZTpsdm0oMykgDQpEZWMgMjkgMjM6MDg6MTQgbjQg
dGFwZGlza1sxODIwNF06IHNlbmRpbmcgJ29wZW4gcmVzcG9uc2UnIG1lc3NhZ2UgKHV1aWQgPSAw
KSANCkRlYyAyOSAyMzowODoxNCBuNCB2YmQudWV2ZW50W2FkZF0oYmFja2VuZC92YmQvMTgvNzY4
KTogd3JvdGUgL3hhcGkvMTgvaG90cGx1Zy92YmQvNzY4L2hvdHBsdWcgPSAnb25saW5lJw0KRGVj
IDI5IDIzOjA4OjE1IG40IHZiZC51ZXZlbnRbYWRkXShiYWNrZW5kL3ZiZC8xOC81Njk2KTogd3Jv
dGUgL3hhcGkvMTgvaG90cGx1Zy92YmQvNTY5Ni9ob3RwbHVnID0gJ29ubGluZScNCkRlYyAyOSAy
MzowODoxNSBuNCBvdnMtdnNjdGw6IDAwMDAxfHZzY3RsfElORk98Q2FsbGVkIGFzIC91c3IvYmlu
L292cy12c2N0bCBsaXN0LXBvcnRzIHhhcGk5DQpEZWMgMjkgMjM6MDg6MTUgbjQgb3ZzLXZzY3Rs
OiAwMDAwMXx2c2N0bHxJTkZPfENhbGxlZCBhcyAvdXNyL2Jpbi9vdnMtdnNjdGwgLS10aW1lb3V0
PTMwIC0tIC0taWYtZXhpc3RzIGRlbC1wb3J0IHZpZjE4LjAgLS0gYWRkLXBvcnQgeGFwaTkgdmlm
MTguMCAtLSBzZXQgaW50ZXJmYWNlIHZpZjE4LjAgImV4dGVybmFsLWlkczpcInhzLXZtLXV1aWRc
Ij1cIjY1OTFhNDAzLTBlYmEtMzBiNC05NmE2LWUwMmE3ZGIwNjA3YVwiIiAtLSBzZXQgaW50ZXJm
YWNlIHZpZjE4LjAgImV4dGVybmFsLWlkczpcInhzLXZpZi11dWlkXCI9XCIzYmU1NGU2ZC02ZDEz
LWIwNGItNjczNS0yNDgzMWU1MTY5ZTVcIiIgLS0gc2V0IGludGVyZmFjZSB2aWYxOC4wICJleHRl
cm5hbC1pZHM6XCJ4cy1uZXR3b3JrLXV1aWRcIj1cIjcwNTFlZjk5LTRmY2ItZmE2MS1hMTBlLWY5
ODQ1NmUxMmU5MFwiIiAtLSBzZXQgaW50ZXJmYWNlIHZpZjE4LjAgImV4dGVybmFsLWlkczpcImF0
dGFjaGVkLW1hY1wiPVwiZDY6NmQ6NjA6N2U6NDU6NTJcIiINCkRlYyAyOSAyMzowODoxNSBuNCBx
ZW11LjE4OiBkb21pZDogMTggDQpEZWMgMjkgMjM6MDg6MTUgbjQgcWVtdS4xODogcWVtdTogdGhl
IG51bWJlciBvZiBjcHVzIGlzIDE2IA0KRGVjIDI5IDIzOjA4OjE1IG40IHFlbXUuMTg6IC12aWRl
b3JhbSBvcHRpb24gZG9lcyBub3Qgd29yayB3aXRoIGNpcnJ1cyB2Z2EgZGV2aWNlIG1vZGVsLiBW
aWRlb3JhbSBzZXQgdG8gNE0uIA0KRGVjIDI5IDIzOjA4OjE1IG40IEhWTTE4WzE4MzAyXTogR3Vl
c3QgdXVpZCA9IDY1OTFhNDAzLTBlYmEtMzBiNC05NmE2LWUwMmE3ZGIwNjA3YSANCkRlYyAyOSAy
MzowODoxNSBuNCBIVk0xOFsxODMwMl06IFdhdGNoaW5nIC9sb2NhbC9kb21haW4vMTgvbG9nZGly
dHkvbmV4dC1hY3RpdmUgDQpEZWMgMjkgMjM6MDg6MTUgbjQgSFZNMThbMTgzMDJdOiBXYXRjaGlu
ZyAvbG9jYWwvZG9tYWluLzAvZGV2aWNlLW1vZGVsLzE4L2NvbW1hbmQgDQpEZWMgMjkgMjM6MDg6
MTUgbjQgSFZNMThbMTgzMDJdOiBjaGFyIGRldmljZSByZWRpcmVjdGVkIHRvIC9kZXYvcHRzLzIg
DQpEZWMgMjkgMjM6MDg6MTUgbjQgSFZNMThbMTgzMDJdOiBjaGFyIGRldmljZSByZWRpcmVjdGVk
IHRvIC9kZXYvcHRzLzMgDQpEZWMgMjkgMjM6MDg6MTUgbjQgSFZNMThbMTgzMDJdOiBxZW11X21h
cF9jYWNoZV9pbml0IG5yX2J1Y2tldHMgPSA0MDAwIHNpemUgMzI3NjgwIA0KRGVjIDI5IDIzOjA4
OjE1IG40IEhWTTE4WzE4MzAyXTogc2hhcmVkIHBhZ2UgYXQgcGZuIGZlZmZkIA0KRGVjIDI5IDIz
OjA4OjE1IG40IEhWTTE4WzE4MzAyXTogYnVmZmVyZWQgaW8gcGFnZSBhdCBwZm4gZmVmZmIgDQpE
ZWMgMjkgMjM6MDg6MTUgbjQgSFZNMThbMTgzMDJdOiBUaW1lIG9mZnNldCBzZXQgMCANCkRlYyAy
OSAyMzowODoxNSBuNCBIVk0xOFsxODMwMl06IHBjaV9yZWdpc3Rlcl9kZXZpY2U6IDAwOjAwOjAw
IChpNDQwRlgpIA0KRGVjIDI5IDIzOjA4OjE1IG40IEhWTTE4WzE4MzAyXTogcGNpX3JlZ2lzdGVy
X2RldmljZTogMDA6MDE6MDAgKFBJSVgzKSANCkRlYyAyOSAyMzowODoxNSBuNCBIVk0xOFsxODMw
Ml06IHBjaV9yZWdpc3Rlcl9kZXZpY2U6IDAwOjAyOjAwIChDaXJydXMgVkdBKSANCkRlYyAyOSAy
MzowODoxNSBuNCBIVk0xOFsxODMwMl06IHBvcHVsYXRpbmcgdmlkZW8gUkFNIGF0IGZmMDAwMDAw
IA0KRGVjIDI5IDIzOjA4OjE1IG40IEhWTTE4WzE4MzAyXTogbWFwcGluZyB2aWRlbyBSQU0gZnJv
bSBmZjAwMDAwMCANCkRlYyAyOSAyMzowODoxNSBuNCBIVk0xOFsxODMwMl06IHBjaV9yZWdpc3Rl
cl9kZXZpY2U6IDAwOjAzOjAwICh4ZW4tcGxhdGZvcm0pIA0KRGVjIDI5IDIzOjA4OjE1IG40IEhW
TTE4WzE4MzAyXTogeHNfcmVhZCgvdm0vNjU5MWE0MDMtMGViYS0zMGI0LTk2YTYtZTAyYTdkYjA2
MDdhL2xvZy10aHJvdHRsaW5nKTogcmVhZCBlcnJvciANCkRlYyAyOSAyMzowODoxNSBuNCBIVk0x
OFsxODMwMl06IFJPTSBtZW1vcnkgYXJlYSBub3cgUlcgDQpEZWMgMjkgMjM6MDg6MTUgbjQgSFZN
MThbMTgzMDJdOiBwY2lfcmVnaXN0ZXJfZGV2aWNlOiAwMDowNDowMCAoUlRMODEzOSkgDQpEZWMg
MjkgMjM6MDg6MTUgbjQgSFZNMThbMTgzMDJdOiBwY2lfcmVnaXN0ZXJfZGV2aWNlOiAwMDowMTow
MSAoUElJWDMgSURFKSANCkRlYyAyOSAyMzowODoxNSBuNCBIVk0xOFsxODMwMl06IHBjaV9yZWdp
c3Rlcl9kZXZpY2U6IDAwOjAxOjAyIChVU0ItVUhDSSkgDQpEZWMgMjkgMjM6MDg6MTUgbjQgSFZN
MThbMTgzMDJdOiBwY2lfcmVnaXN0ZXJfZGV2aWNlOiAwMDowMTowMyAoUElJWDQgQUNQSSkgDQpE
ZWMgMjkgMjM6MDg6MTUgbjQgSFZNMThbMTgzMDJdOiB4c19yZWFkKC9sb2NhbC9kb21haW4vMC9k
ZXZpY2UtbW9kZWwvMTgveGVuX2V4dGVuZGVkX3Bvd2VyX21nbXQpOiByZWFkIGVycm9yIA0KRGVj
IDI5IDIzOjA4OjE1IG40IEhWTTE4WzE4MzAyXTogcmVsZWFzaW5nIFZNIA0KRGVjIDI5IDIzOjA4
OjE1IG40IEhWTTE4WzE4MzAyXTogeHNfcmVhZCgpOiB2bmNwYXNzd2QgZ2V0IGVycm9yLiAvdm0v
NjU5MWE0MDMtMGViYS0zMGI0LTk2YTYtZTAyYTdkYjA2MDdhL3ZuY3Bhc3N3ZC4gDQpEZWMgMjkg
MjM6MDg6MTUgbjQgSFZNMThbMTgzMDJdOiBJL08gcmVxdWVzdCBub3QgcmVhZHk6IDAsIHB0cjog
MCwgcG9ydDogMCwgZGF0YTogMCwgY291bnQ6IDAsIHNpemU6IDAgDQpEZWMgMjkgMTc6Mzg6MTUg
bjQgbGFzdCBtZXNzYWdlIHJlcGVhdGVkIDIgdGltZXMNCkRlYyAyOSAxNzozODoxNSBuNCBIVk0x
OFsxODMwMl06IFRyaWdnZXJlZCBsb2ctZGlydHkgYnVmZmVyIHN3aXRjaCANCkRlYyAyOSAxNzoz
ODoxNSBuNCBIVk0xOFsxODMwMl06IEkvTyByZXF1ZXN0IG5vdCByZWFkeTogMCwgcHRyOiAwLCBw
b3J0OiAwLCBkYXRhOiAwLCBjb3VudDogMCwgc2l6ZTogMCANCkRlYyAyOSAxNzozODoxNSBuNCBI
Vk0xOFsxODMwMl06IG1lZGl1bSBjaGFuZ2Ugd2F0Y2ggb24gYGhkZCcgKGluZGV4OiAxKTogIA0K
RGVjIDI5IDE3OjM4OjE1IG40IEhWTTE4WzE4MzAyXTogSS9PIHJlcXVlc3Qgbm90IHJlYWR5OiAw
LCBwdHI6IDAsIHBvcnQ6IDAsIGRhdGE6IDAsIGNvdW50OiAwLCBzaXplOiAwIA0KRGVjIDI5IDE3
OjM4OjE1IG40IGxhc3QgbWVzc2FnZSByZXBlYXRlZCAxMSB0aW1lcw0KRGVjIDI5IDE3OjM4OjE2
IG40IEhWTTE4WzE4MzAyXTogY2lycnVzIHZnYSBtYXAgY2hhbmdlIHdoaWxlIG9uIGxmYiBtb2Rl
IA0KRGVjIDI5IDIzOjA4OjE2IG40IG92cy12c2N0bDogMDAwMDF8dnNjdGx8SU5GT3xDYWxsZWQg
YXMgL3Vzci9iaW4vb3ZzLXZzY3RsIC0tdGltZW91dD0zMCAtLSAtLWlmLWV4aXN0cyBkZWwtcG9y
dCB0YXAxOC4wIC0tIGFkZC1wb3J0IHhhcGk5IHRhcDE4LjANCkRlYyAyOSAxNzozODoxNiBuNCBI
Vk0xOFsxODMwMl06IG1hcHBpbmcgdnJhbSB0byBmMDAwMDAwMCAtIGYwNDAwMDAwIA0KRGVjIDI5
IDE3OjM4OjE3IG40IEhWTTE4WzE4MzAyXTogUk9NIG1lbW9yeSBhcmVhIG5vdyBSVyANCkRlYyAy
OSAxNzozODoxNyBuNCBIVk0xOFsxODMwMl06IFJPTSBtZW1vcnkgYXJlYSBub3cgUk8gDQpEZWMg
MjkgMTc6Mzg6MTggbjQgSFZNMThbMTgzMDJdOiBjaXJydXM6IGJsYW5raW5nIHRoZSBzY3JlZW4g
bGluZV9vZmZzZXQ9MzA3MiBoZWlnaHQ9NzY4IA0KRGVjIDI5IDE3OjM4OjM0IG40IEhWTTE4WzE4
MzAyXTogY2lycnVzOiBibGFua2luZyB0aGUgc2NyZWVuIGxpbmVfb2Zmc2V0PTEwMjQgaGVpZ2h0
PTc2OCANCkRlYyAyOSAxNzozODozNyBuNCBIVk0xOFsxODMwMl06IFVOUExVRzogcHJvdG9jb2wg
dmVyc2lvbiBzZXQgdG8gMSAoZHJpdmVycyBub3QgYmxhY2tsaXN0ZWQpIA0KRGVjIDI5IDE3OjM4
OjM3IG40IEhWTTE4WzE4MzAyXTogVU5QTFVHOiBwcm90b2NvbCAxIGFjdGl2ZSANCkRlYyAyOSAx
NzozODozNyBuNCBIVk0xOFsxODMwMl06IFVOUExVRzogcHJvZHVjdF9pZDogMSBidWlsZF9udW1i
ZXI6IDMwODc2IA0KRGVjIDI5IDE3OjM4OjM3IG40IEhWTTE4WzE4MzAyXTogVU5QTFVHOiBkcml2
ZXJzIG5vdCBibGFja2xpc3RlZCANCkRlYyAyOSAxNzozODozNyBuNCBIVk0xOFsxODMwMl06IGlk
ZV91bnBsdWdfaGFyZGRpc2s6IGRyaXZlIDAgDQpEZWMgMjkgMTc6Mzg6MzcgbjQgSFZNMThbMTgz
MDJdOiBwY2lfZGV2X3VucGx1ZzogMDA6MDQ6MDAgDQpEZWMgMjkgMTc6Mzg6MzcgbjQgSFZNMThb
MTgzMDJdOiBuZXRfdGFwX3NodXRkb3duOiBtb2RlbD10YXAsbmFtZT10YXAuMCANCkRlYyAyOSAy
MzowODozOCBuNCBvdnMtdnNjdGw6IDAwMDAxfHZzY3RsfElORk98Q2FsbGVkIGFzIC91c3IvYmlu
L292cy12c2N0bCAtLXRpbWVvdXQ9MzAgLS0gLS1pZi1leGlzdHMgZGVsLXBvcnQgdGFwMTguMA0K
RGVjIDI5IDE3OjM4OjM4IG40IEhWTTE4WzE4MzAyXTogIFhFVlRDSE46IEluc3RhbGxEdW1wRGV2
aWNlQ2FsbGJhY2s6IHZlcnNpb24gbWlzbWF0Y2ggKDI1NSAhPSAxKSANCkRlYyAyOSAxNzozODoz
OCBuNCBIVk0xOFsxODMwMl06ICAgWEVWVENITjogWGVuZXZ0Y2huQWRkRGV2aWNlOiBGRE8gPSAw
eEZGRkZGQTgwNDQzMjM5NzAgDQpEZWMgMjkgMTc6Mzg6MzggbjQgSFZNMThbMTgzMDJdOiAgIFhF
VlRDSE46IEluaXRpYWxpemVkIHRyYWNpbmcgcHJvdmlkZXIgDQpEZWMgMjkgMTc6Mzg6MzggbjQg
SFZNMThbMTgzMDJdOiAgIFhFVlRDSE46IFN0YXJ0RGV2aWNlRmRvOiA9PT09PiANCkRlYyAyOSAx
NzozODozOCBuNCBIVk0xOFsxODMwMl06ICAgWEVOVVRJTDogWEVWVENITjogSU8gaG9sZTogWzAw
MDAwMDAwZmJmYTYwMDAsMDAwMDAwMDBmYzAwMDAwMCkgbWFwcGVkIGF0IEZGRkZGODgwMDI5NjUw
MDAgDQpEZWMgMjkgMTc6Mzg6MzggbjQgSFZNMThbMTgzMDJdOiBuZXRfdGFwX3NodXRkb3duOiBt
b2RlbD10YXAsbmFtZT10YXAuMCANCkRlYyAyOSAxNzozODozOCBuNCBIVk0xOFsxODMwMl06ICAg
WEVOVVRJTDogS0VSTkVMOiA2LjEgKGJ1aWxkIDc2MDApIHBsYXRmb3JtIFdJTjMyX05UIA0KRGVj
IDI5IDE3OjM4OjM4IG40IEhWTTE4WzE4MzAyXTogICBYRU5VVElMOiBTUDogTk9ORSANCkRlYyAy
OSAxNzozODozOCBuNCBIVk0xOFsxODMwMl06ICAgWEVOVVRJTDogU1VJVEVTOiANCkRlYyAyOSAx
NzozODozOCBuNCBIVk0xOFsxODMwMl06ICAgWEVOVVRJTDogLSBURVJNSU5BTCANCkRlYyAyOSAx
NzozODozOCBuNCBIVk0xOFsxODMwMl06ICAgWEVOVVRJTDogLSBEQVRBQ0VOVEVSIA0KRGVjIDI5
IDE3OjM4OjM4IG40IEhWTTE4WzE4MzAyXTogICBYRU5VVElMOiAtIFNJTkdMRVVTRVJUUyANCkRl
YyAyOSAxNzozODozOCBuNCBIVk0xOFsxODMwMl06ICAgWEVOVVRJTDogVFlQRTogU0VSVkVSIA0K
RGVjIDI5IDE3OjM4OjM4IG40IEhWTTE4WzE4MzAyXTogICBYRU5VVElMOiBQViBEUklWRVJTOiBW
RVJTSU9OOiA1LjYuMCBCVUlMRDogMzA4NzYgKEFwciAzMCAyMDEwLjA2OjU3OjAxKSANCkRlYyAy
OSAxNzozODozOCBuNCBIVk0xOFsxODMwMl06ICAgWEVOVVRJTDogNjQtYml0IEhWTSANCkRlYyAy
OSAxNzozODozOCBuNCBIVk0xOFsxODMwMl06IG5ldF90YXBfc2h1dGRvd246IG1vZGVsPXRhcCxu
YW1lPXRhcC4wIA0KRGVjIDI5IDE3OjM4OjM4IG40IEhWTTE4WzE4MzAyXTogICBYRU5VVElMOiBF
eHBhbmRHcmFudFRhYmxlOiBHUkFOVCBUQUJMRSAwOiAoMCAtIDUxMSkgYXQgRkZGRkY4ODAwMjk2
NjAwMCAoZmJmYTcwMDApIA0KRGVjIDI5IDE3OjM4OjM4IG40IEhWTTE4WzE4MzAyXTogICBYRU5V
VElMOiBYZW5FbnRlcnByaXNlIHByb2R1Y3Qgc3RyaW5nIGlzIHByZXNlbnQgDQpEZWMgMjkgMTc6
Mzg6MzkgbjQgSFZNMThbMTgzMDJdOiAgIFhFTlVUSUw6IFBIWVNJQ0FMIE1FTU9SWTogVE9QID0g
MDAwMDAwMTYuOGZjMDAwMDAgDQpEZWMgMjkgMTc6Mzg6MzkgbjQgSFZNMThbMTgzMDJdOiAgIFhF
TlVUSUw6IEJhbGxvb25UYXJnZXRDaGFuZ2VkOiA5NDM3MTg0MGsgLT4gNDM3OTIzODRrIA0KRGVj
IDI5IDE3OjM4OjM5IG40IEhWTTE4WzE4MzAyXTogICBYRU5VVElMOiBCYWxsb29uV29ya2VyVGhy
ZWFkOiBhY3RpdmF0aW5nIA0KRGVjIDI5IDE3OjM4OjQ3IG40IEhWTTE4WzE4MzAyXTogICBYRU5V
VElMOiBXQVJOSU5HOiBCYWxsb29uUmVsZWFzZVBmbkFycmF5OiByYW4gZm9yIG1vcmUgdGhhbiAy
MjMwbXMgDQpEZWMgMjkgMTc6Mzg6NDcgbjQgSFZNMThbMTgzMDJdOiAgIFhFTlVUSUw6IEJhbGxv
b25Xb3JrZXJUaHJlYWQ6IGluZmxhdGVkIGJhbGxvb24gYnkgNDA5MCBwYWdlKHMpIGluIDc5MjRt
cyAoMjA2NGsvcykgDQpEZWMgMjkgMTc6Mzg6NDcgbjQgSFZNMThbMTgzMDJdOiAgIFhFTlVUSUw6
IEJhbGxvb25Xb3JrZXJUaHJlYWQ6IHBhdXNpbmcgZm9yIDFzICh0YXJnZXQgPSA0Mzc5MjM4NGss
IGN1cnJlbnQgPSA5NDM1NTQ4MGspIA0KRGVjIDI5IDE3OjM4OjU3IG40IEhWTTE4WzE4MzAyXTog
ICBYRU5VVElMOiBXQVJOSU5HOiBCYWxsb29uUmVsZWFzZVBmbkFycmF5OiByYW4gZm9yIG1vcmUg
dGhhbiAxNzk0bXMgDQpEZWMgMjkgMTc6Mzg6NTcgbjQgSFZNMThbMTgzMDJdOiAgIFhFTlVUSUw6
IEJhbGxvb25Xb3JrZXJUaHJlYWQ6IGluZmxhdGVkIGJhbGxvb24gYnkgNDA5MCBwYWdlKHMpIGlu
IDkxNTdtcyAoMTc4NmsvcykgDQpEZWMgMjkgMTc6Mzg6NTcgbjQgSFZNMThbMTgzMDJdOiAgIFhF
TlVUSUw6IEJhbGxvb25Xb3JrZXJUaHJlYWQ6IHBhdXNpbmcgZm9yIDFzICh0YXJnZXQgPSA0Mzc5
MjM4NGssIGN1cnJlbnQgPSA5NDMzOTEyMGspIA0KRGVjIDI5IDE3OjM5OjEzIG40IEhWTTE4WzE4
MzAyXTogICBYRU5VVElMOiBXQVJOSU5HOiBCYWxsb29uUmVsZWFzZVBmbkFycmF5OiByYW4gZm9y
IG1vcmUgdGhhbiA1MDcwbXMgDQpEZWMgMjkgMTc6Mzk6MTMgbjQgSFZNMThbMTgzMDJdOiAgIFhF
TlVUSUw6IEJhbGxvb25Xb3JrZXJUaHJlYWQ6IGluZmxhdGVkIGJhbGxvb24gYnkgNDA5MCBwYWdl
KHMpIGluIDE0NjAxbXMgKDExMjBrL3MpIA0KRGVjIDI5IDE3OjM5OjEzIG40IEhWTTE4WzE4MzAy
XTogICBYRU5VVElMOiBCYWxsb29uV29ya2VyVGhyZWFkOiBwYXVzaW5nIGZvciAxcyAodGFyZ2V0
ID0gNDM3OTIzODRrLCBjdXJyZW50ID0gOTQzMjI3NjBrKSANCkRlYyAyOSAxNzozOTozMCBuNCBI
Vk0xOFsxODMwMl06ICAgWEVOVVRJTDogV0FSTklORzogQmFsbG9vblJlbGVhc2VQZm5BcnJheTog
cmFuIGZvciBtb3JlIHRoYW4gNDMyMW1zIA0KRGVjIDI5IDE3OjM5OjMwIG40IEhWTTE4WzE4MzAy
XTogICBYRU5VVElMOiBCYWxsb29uV29ya2VyVGhyZWFkOiBpbmZsYXRlZCBiYWxsb29uIGJ5IDQw
OTAgcGFnZShzKSBpbiAxNjA1Mm1zICgxMDE5ay9zKSANCkRlYyAyOSAxNzozOTozMCBuNCBIVk0x
OFsxODMwMl06ICAgWEVOVVRJTDogQmFsbG9vbldvcmtlclRocmVhZDogcGF1c2luZyBmb3IgMXMg
KHRhcmdldCA9IDQzNzkyMzg0aywgY3VycmVudCA9IDk0MzA2NDAwaykgDQpEZWMgMjkgMTc6Mzk6
NDAgbjQgSFZNMThbMTgzMDJdOiAgIFhFTlVUSUw6IFdBUk5JTkc6IEJhbGxvb25Qb2RTd2VlcDog
SFlQRVJWSVNPUl9tZW1vcnlfb3AoWEVOTUVNX3BvZF9zd2VlcCwgLi4uKSBmYWlsZWQgKGZmZmZm
ZmY0KSANCkRlYyAyOSAxNzozOTo0NiBuNCBIVk0xOFsxODMwMl06ICAgWEVOVVRJTDogV0FSTklO
RzogQmFsbG9vblJlbGVhc2VQZm5BcnJheTogcmFuIGZvciBtb3JlIHRoYW4gNjA5OW1zIA0KRGVj
IDI5IDE3OjM5OjQ2IG40IEhWTTE4WzE4MzAyXTogICBYRU5VVElMOiBCYWxsb29uV29ya2VyVGhy
ZWFkOiBpbmZsYXRlZCBiYWxsb29uIGJ5IDQwOTAgcGFnZShzKSBpbiAxNTEzMm1zICgxMDgxay9z
KSANCkRlYyAyOSAxNzozOTo0NiBuNCBIVk0xOFsxODMwMl06ICAgWEVOVVRJTDogQmFsbG9vbldv
cmtlclRocmVhZDogcGF1c2luZyBmb3IgMXMgKHRhcmdldCA9IDQzNzkyMzg0aywgY3VycmVudCA9
IDk0MjkwMDQwaykgDQpEZWMgMjkgMTc6NDA6MDQgbjQgSFZNMThbMTgzMDJdOiAgIFhFTlVUSUw6
IFdBUk5JTkc6IEJhbGxvb25SZWxlYXNlUGZuQXJyYXk6IHJhbiBmb3IgbW9yZSB0aGFuIDQ0OTJt
cyANCkRlYyAyOSAxNzo0MDowNCBuNCBIVk0xOFsxODMwMl06ICAgWEVOVVRJTDogQmFsbG9vbldv
cmtlclRocmVhZDogaW5mbGF0ZWQgYmFsbG9vbiBieSA0MDkwIHBhZ2UocykgaW4gMTcyMDZtcyAo
OTUway9zKSANCkRlYyAyOSAxNzo0MDowNCBuNCBIVk0xOFsxODMwMl06ICAgWEVOVVRJTDogQmFs
bG9vbldvcmtlclRocmVhZDogcGF1c2luZyBmb3IgMXMgKHRhcmdldCA9IDQzNzkyMzg0aywgY3Vy
cmVudCA9IDk0MjczNjgwaykgDQpEZWMgMjkgMTc6NDA6MTYgbjQgSFZNMThbMTgzMDJdOiAgIFhF
TlVUSUw6IFdBUk5JTkc6IEJhbGxvb25SZWxlYXNlUGZuQXJyYXk6IHJhbiBmb3IgbW9yZSB0aGFu
IDIwNDNtcyANCkRlYyAyOSAxNzo0MDoxNiBuNCBIVk0xOFsxODMwMl06ICAgWEVOVVRJTDogQmFs
bG9vbldvcmtlclRocmVhZDogaW5mbGF0ZWQgYmFsbG9vbiBieSA0MDkwIHBhZ2UocykgaW4gMTEy
OTRtcyAoMTQ0OGsvcykgDQpEZWMgMjkgMTc6NDA6MTYgbjQgSFZNMThbMTgzMDJdOiAgIFhFTlVU
SUw6IEJhbGxvb25Xb3JrZXJUaHJlYWQ6IHBhdXNpbmcgZm9yIDFzICh0YXJnZXQgPSA0Mzc5MjM4
NGssIGN1cnJlbnQgPSA5NDI1NzMyMGspIA0KRGVjIDI5IDE3OjQwOjI3IG40IEhWTTE4WzE4MzAy
XTogICBYRU5VVElMOiBXQVJOSU5HOiBCYWxsb29uUG9kU3dlZXA6IEhZUEVSVklTT1JfbWVtb3J5
X29wKFhFTk1FTV9wb2Rfc3dlZXAsIC4uLikgZmFpbGVkIChmZmZmZmZmNCkgDQpEZWMgMjkgMTc6
NDA6MzIgbjQgSFZNMThbMTgzMDJdOiAgIFhFTlVUSUw6IFdBUk5JTkc6IEJhbGxvb25SZWxlYXNl
UGZuQXJyYXk6IHJhbiBmb3IgbW9yZSB0aGFuIDUxNzltcyANCkRlYyAyOSAxNzo0MDozMiBuNCBI
Vk0xOFsxODMwMl06ICAgWEVOVVRJTDogQmFsbG9vbldvcmtlclRocmVhZDogaW5mbGF0ZWQgYmFs
bG9vbiBieSA0MDkwIHBhZ2UocykgaW4gMTUxMDBtcyAoMTA4M2svcykgDQpEZWMgMjkgMTc6NDA6
MzIgbjQgSFZNMThbMTgzMDJdOiAgIFhFTlVUSUw6IEJhbGxvb25Xb3JrZXJUaHJlYWQ6IHBhdXNp
bmcgZm9yIDFzICh0YXJnZXQgPSA0Mzc5MjM4NGssIGN1cnJlbnQgPSA5NDI0MDk2MGspIA0KRGVj
IDI5IDE3OjQwOjQ2IG40IEhWTTE4WzE4MzAyXTogICBYRU5VVElMOiBXQVJOSU5HOiBCYWxsb29u
UmVsZWFzZVBmbkFycmF5OiByYW4gZm9yIG1vcmUgdGhhbiAyMjMwbXMgDQpEZWMgMjkgMTc6NDA6
NDYgbjQgSFZNMThbMTgzMDJdOiAgIFhFTlVUSUw6IEJhbGxvb25Xb3JrZXJUaHJlYWQ6IGluZmxh
dGVkIGJhbGxvb24gYnkgNDA5MCBwYWdlKHMpIGluIDEyODcwbXMgKDEyNzFrL3MpIA0KRGVjIDI5
IDE3OjQwOjQ2IG40IEhWTTE4WzE4MzAyXTogICBYRU5VVElMOiBCYWxsb29uV29ya2VyVGhyZWFk
OiBwYXVzaW5nIGZvciAxcyAodGFyZ2V0ID0gNDM3OTIzODRrLCBjdXJyZW50ID0gOTQyMjQ2MDBr
KSANCkRlYyAyOSAxNzo0MTowMSBuNCBIVk0xOFsxODMwMl06ICAgWEVOVVRJTDogV0FSTklORzog
QmFsbG9vblJlbGVhc2VQZm5BcnJheTogcmFuIGZvciBtb3JlIHRoYW4gNTM1MG1zIA0KRGVjIDI5
IDE3OjQxOjAxIG40IEhWTTE4WzE4MzAyXTogICBYRU5VVElMOiBCYWxsb29uV29ya2VyVGhyZWFk
OiBpbmZsYXRlZCBiYWxsb29uIGJ5IDQwOTAgcGFnZShzKSBpbiAxMzIyOG1zICgxMjM2ay9zKSAN
CkRlYyAyOSAxNzo0MTowMSBuNCBIVk0xOFsxODMwMl06ICAgWEVOVVRJTDogQmFsbG9vbldvcmtl
clRocmVhZDogcGF1c2luZyBmb3IgMXMgKHRhcmdldCA9IDQzNzkyMzg0aywgY3VycmVudCA9IDk0
MjA4MjQwaykgDQpEZWMgMjkgMTc6NDE6MTQgbjQgSFZNMThbMTgzMDJdOiAgIFhFTlVUSUw6IFdB
Uk5JTkc6IEJhbGxvb25Qb2RTd2VlcDogSFlQRVJWSVNPUl9tZW1vcnlfb3AoWEVOTUVNX3BvZF9z
d2VlcCwgLi4uKSBmYWlsZWQgKGZmZmZmZmY0KSANCkRlYyAyOSAxNzo0MToxNyBuNCBIVk0xOFsx
ODMwMl06ICAgWEVOVVRJTDogV0FSTklORzogQmFsbG9vblJlbGVhc2VQZm5BcnJheTogcmFuIGZv
ciBtb3JlIHRoYW4gMzAyNm1zIA0KRGVjIDI5IDE3OjQxOjE3IG40IEhWTTE4WzE4MzAyXTogICBY
RU5VVElMOiBCYWxsb29uV29ya2VyVGhyZWFkOiBpbmZsYXRlZCBiYWxsb29uIGJ5IDQwOTAgcGFn
ZShzKSBpbiAxNTQ5MG1zICgxMDU2ay9zKSANCkRlYyAyOSAxNzo0MToxNyBuNCBIVk0xOFsxODMw
Ml06ICAgWEVOVVRJTDogQmFsbG9vbldvcmtlclRocmVhZDogcGF1c2luZyBmb3IgMXMgKHRhcmdl
dCA9IDQzNzkyMzg0aywgY3VycmVudCA9IDk0MTkxODgwaykgDQpEZWMgMjkgMTc6NDE6MzEgbjQg
SFZNMThbMTgzMDJdOiAgIFhFTlVUSUw6IFdBUk5JTkc6IEJhbGxvb25SZWxlYXNlUGZuQXJyYXk6
IHJhbiBmb3IgbW9yZSB0aGFuIDMxNTFtcyANCkRlYyAyOSAxNzo0MTozMSBuNCBIVk0xOFsxODMw
Ml06ICAgWEVOVVRJTDogQmFsbG9vbldvcmtlclRocmVhZDogaW5mbGF0ZWQgYmFsbG9vbiBieSA0
MDkwIHBhZ2UocykgaW4gMTMyOTFtcyAoMTIzMGsvcykgDQpEZWMgMjkgMTc6NDE6MzEgbjQgSFZN
MThbMTgzMDJdOiAgIFhFTlVUSUw6IEJhbGxvb25Xb3JrZXJUaHJlYWQ6IHBhdXNpbmcgZm9yIDFz
ICh0YXJnZXQgPSA0Mzc5MjM4NGssIGN1cnJlbnQgPSA5NDE3NTUyMGspIA0KRGVjIDI5IDE3OjQx
OjQ5IG40IEhWTTE4WzE4MzAyXTogICBYRU5VVElMOiBXQVJOSU5HOiBCYWxsb29uUmVsZWFzZVBm
bkFycmF5OiByYW4gZm9yIG1vcmUgdGhhbiA1NTUzbXMgDQpEZWMgMjkgMTc6NDE6NDkgbjQgSFZN
MThbMTgzMDJdOiAgIFhFTlVUSUw6IEJhbGxvb25Xb3JrZXJUaHJlYWQ6IGluZmxhdGVkIGJhbGxv
b24gYnkgNDA5MCBwYWdlKHMpIGluIDE2ODMybXMgKDk3MWsvcykgDQpEZWMgMjkgMTc6NDE6NDkg
bjQgSFZNMThbMTgzMDJdOiAgIFhFTlVUSUw6IEJhbGxvb25Xb3JrZXJUaHJlYWQ6IHBhdXNpbmcg
Zm9yIDFzICh0YXJnZXQgPSA0Mzc5MjM4NGssIGN1cnJlbnQgPSA5NDE1OTE2MGspIA0KRGVjIDI5
IDE3OjQyOjA4IG40IEhWTTE4WzE4MzAyXTogICBYRU5VVElMOiBXQVJOSU5HOiBCYWxsb29uUmVs
ZWFzZVBmbkFycmF5OiByYW4gZm9yIG1vcmUgdGhhbiA2NzU0bXMgDQpEZWMgMjkgMTc6NDI6MDgg
bjQgSFZNMThbMTgzMDJdOiAgIFhFTlVUSUw6IEJhbGxvb25Xb3JrZXJUaHJlYWQ6IGluZmxhdGVk
IGJhbGxvb24gYnkgNDA5MCBwYWdlKHMpIGluIDE4MTExbXMgKDkwM2svcykgDQpEZWMgMjkgMTc6
NDI6MDggbjQgSFZNMThbMTgzMDJdOiAgIFhFTlVUSUw6IEJhbGxvb25Xb3JrZXJUaHJlYWQ6IHBh
dXNpbmcgZm9yIDFzICh0YXJnZXQgPSA0Mzc5MjM4NGssIGN1cnJlbnQgPSA5NDE0MjgwMGspIA0K
RGVjIDI5IDE3OjQyOjI4IG40IEhWTTE4WzE4MzAyXTogICBYRU5VVElMOiBXQVJOSU5HOiBCYWxs
b29uUmVsZWFzZVBmbkFycmF5OiByYW4gZm9yIG1vcmUgdGhhbiAzMjQ0bXMgDQpEZWMgMjkgMTc6
NDI6MjggbjQgSFZNMThbMTgzMDJdOiAgIFhFTlVUSUw6IEJhbGxvb25Xb3JrZXJUaHJlYWQ6IGlu
ZmxhdGVkIGJhbGxvb24gYnkgNDA5MCBwYWdlKHMpIGluIDE4MzkybXMgKDg4OWsvcykgDQpEZWMg
MjkgMTc6NDI6MjggbjQgSFZNMThbMTgzMDJdOiAgIFhFTlVUSUw6IEJhbGxvb25Xb3JrZXJUaHJl
YWQ6IHBhdXNpbmcgZm9yIDFzICh0YXJnZXQgPSA0Mzc5MjM4NGssIGN1cnJlbnQgPSA5NDEyNjQ0
MGspIA0KRGVjIDI5IDE3OjQyOjQ3IG40IEhWTTE4WzE4MzAyXTogICBYRU5VVElMOiBXQVJOSU5H
OiBCYWxsb29uUmVsZWFzZVBmbkFycmF5OiByYW4gZm9yIG1vcmUgdGhhbiA1NzI1bXMgDQpEZWMg
MjkgMTc6NDI6NDcgbjQgSFZNMThbMTgzMDJdOiAgIFhFTlVUSUw6IEJhbGxvb25Xb3JrZXJUaHJl
YWQ6IGluZmxhdGVkIGJhbGxvb24gYnkgNDA5MCBwYWdlKHMpIGluIDE4NDU0bXMgKDg4Nmsvcykg
DQpEZWMgMjkgMTc6NDI6NDcgbjQgSFZNMThbMTgzMDJdOiAgIFhFTlVUSUw6IEJhbGxvb25Xb3Jr
ZXJUaHJlYWQ6IHBhdXNpbmcgZm9yIDFzICh0YXJnZXQgPSA0Mzc5MjM4NGssIGN1cnJlbnQgPSA5
NDExMDA4MGspIA0KRGVjIDI5IDE3OjQzOjA4IG40IEhWTTE4WzE4MzAyXTogICBYRU5VVElMOiBX
QVJOSU5HOiBCYWxsb29uUmVsZWFzZVBmbkFycmF5OiByYW4gZm9yIG1vcmUgdGhhbiA0MjQzbXMg
DQpEZWMgMjkgMTc6NDM6MDggbjQgSFZNMThbMTgzMDJdOiAgIFhFTlVUSUw6IEJhbGxvb25Xb3Jr
ZXJUaHJlYWQ6IGluZmxhdGVkIGJhbGxvb24gYnkgNDA5MCBwYWdlKHMpIGluIDE5NDUzbXMgKDg0
MWsvcykgDQpEZWMgMjkgMTc6NDM6MDggbjQgSFZNMThbMTgzMDJdOiAgIFhFTlVUSUw6IEJhbGxv
b25Xb3JrZXJUaHJlYWQ6IHBhdXNpbmcgZm9yIDFzICh0YXJnZXQgPSA0Mzc5MjM4NGssIGN1cnJl
bnQgPSA5NDA5MzcyMGspIA0KRGVjIDI5IDE3OjQzOjI2IG40IEhWTTE4WzE4MzAyXTogICBYRU5V
VElMOiBXQVJOSU5HOiBCYWxsb29uUmVsZWFzZVBmbkFycmF5OiByYW4gZm9yIG1vcmUgdGhhbiA1
MjQxbXMgDQpEZWMgMjkgMTc6NDM6MjYgbjQgSFZNMThbMTgzMDJdOiAgIFhFTlVUSUw6IEJhbGxv
b25Xb3JrZXJUaHJlYWQ6IGluZmxhdGVkIGJhbGxvb24gYnkgNDA5MCBwYWdlKHMpIGluIDE3MjA2
bXMgKDk1MGsvcykgDQpEZWMgMjkgMTc6NDM6MjYgbjQgSFZNMThbMTgzMDJdOiAgIFhFTlVUSUw6
IEJhbGxvb25Xb3JrZXJUaHJlYWQ6IHBhdXNpbmcgZm9yIDFzICh0YXJnZXQgPSA0Mzc5MjM4NGss
IGN1cnJlbnQgPSA5NDA3NzM2MGspIA0KRGVjIDI5IDE3OjQzOjQ0IG40IEhWTTE4WzE4MzAyXTog
ICBYRU5VVElMOiBXQVJOSU5HOiBCYWxsb29uUmVsZWFzZVBmbkFycmF5OiByYW4gZm9yIG1vcmUg
dGhhbiAxOTk2bXMgDQpEZWMgMjkgMTc6NDM6NDQgbjQgSFZNMThbMTgzMDJdOiAgIFhFTlVUSUw6
IEJhbGxvb25Xb3JrZXJUaHJlYWQ6IGluZmxhdGVkIGJhbGxvb24gYnkgNDA5MCBwYWdlKHMpIGlu
IDE3MjUzbXMgKDk0OGsvcykgDQpEZWMgMjkgMTc6NDM6NDQgbjQgSFZNMThbMTgzMDJdOiAgIFhF
TlVUSUw6IEJhbGxvb25Xb3JrZXJUaHJlYWQ6IHBhdXNpbmcgZm9yIDFzICh0YXJnZXQgPSA0Mzc5
MjM4NGssIGN1cnJlbnQgPSA5NDA2MTAwMGspIA0KRGVjIDI5IDE3OjQ0OjAyIG40IEhWTTE4WzE4
MzAyXTogICBYRU5VVElMOiBXQVJOSU5HOiBCYWxsb29uUmVsZWFzZVBmbkFycmF5OiByYW4gZm9y
IG1vcmUgdGhhbiA0NzczbXMgDQpEZWMgMjkgMTc6NDQ6MDIgbjQgSFZNMThbMTgzMDJdOiAgIFhF
TlVUSUw6IEJhbGxvb25Xb3JrZXJUaHJlYWQ6IGluZmxhdGVkIGJhbGxvb24gYnkgNDA5MCBwYWdl
KHMpIGluIDE2Mjg2bXMgKDEwMDRrL3MpIA0KRGVjIDI5IDE3OjQ0OjAyIG40IEhWTTE4WzE4MzAy
XTogICBYRU5VVElMOiBCYWxsb29uV29ya2VyVGhyZWFkOiBwYXVzaW5nIGZvciAxcyAodGFyZ2V0
ID0gNDM3OTIzODRrLCBjdXJyZW50ID0gOTQwNDQ2NDBrKSANCkRlYyAyOSAxNzo0NDoyNCBuNCBI
Vk0xOFsxODMwMl06ICAgWEVOVVRJTDogV0FSTklORzogQmFsbG9vblJlbGVhc2VQZm5BcnJheTog
cmFuIGZvciBtb3JlIHRoYW4gMjE1Mm1zIA0KRGVjIDI5IDE3OjQ0OjI0IG40IEhWTTE4WzE4MzAy
XTogICBYRU5VVElMOiBCYWxsb29uV29ya2VyVGhyZWFkOiBpbmZsYXRlZCBiYWxsb29uIGJ5IDQw
OTAgcGFnZShzKSBpbiAyMTIzMW1zICg3NzBrL3MpIA0KRGVjIDI5IDE3OjQ0OjI0IG40IEhWTTE4
WzE4MzAyXTogICBYRU5VVElMOiBCYWxsb29uV29ya2VyVGhyZWFkOiBwYXVzaW5nIGZvciAxcyAo
dGFyZ2V0ID0gNDM3OTIzODRrLCBjdXJyZW50ID0gOTQwMjgyODBrKSANCkRlYyAyOSAxNzo0NDo0
MCBuNCBIVk0xOFsxODMwMl06ICAgWEVOVVRJTDogV0FSTklORzogQmFsbG9vblBvZFN3ZWVwOiBI
WVBFUlZJU09SX21lbW9yeV9vcChYRU5NRU1fcG9kX3N3ZWVwLCAuLi4pIGZhaWxlZCAoZmZmZmZm
ZjQpIA0KRGVjIDI5IDE3OjQ0OjQyIG40IEhWTTE4WzE4MzAyXTogICBYRU5VVElMOiBXQVJOSU5H
OiBCYWxsb29uUmVsZWFzZVBmbkFycmF5OiByYW4gZm9yIG1vcmUgdGhhbiAyMTk5bXMgDQpEZWMg
MjkgMTc6NDQ6NDIgbjQgSFZNMThbMTgzMDJdOiAgIFhFTlVUSUw6IEJhbGxvb25Xb3JrZXJUaHJl
YWQ6IGluZmxhdGVkIGJhbGxvb24gYnkgNDA5MCBwYWdlKHMpIGluIDE3MzMxbXMgKDk0M2svcykg
DQpEZWMgMjkgMTc6NDQ6NDIgbjQgSFZNMThbMTgzMDJdOiAgIFhFTlVUSUw6IEJhbGxvb25Xb3Jr
ZXJUaHJlYWQ6IHBhdXNpbmcgZm9yIDFzICh0YXJnZXQgPSA0Mzc5MjM4NGssIGN1cnJlbnQgPSA5
NDAxMTkyMGspIA0KRGVjIDI5IDE3OjQ1OjE2IG40IEhWTTE4WzE4MzAyXTogICBYRU5VVElMOiBC
YWxsb29uV29ya2VyVGhyZWFkOiBpbmZsYXRlZCBiYWxsb29uIGJ5IDEyNTU0ODg0IHBhZ2Uocykg
aW4gMzI2MDRtcyAoOTEyNDNrL3MpIA0KRGVjIDI5IDE3OjQ1OjE2IG40IEhWTTE4WzE4MzAyXTog
ICBYRU5VVElMOiBCYWxsb29uV29ya2VyVGhyZWFkOiBkZS1hY3RpdmF0aW5nIA0KRGVjIDI5IDE3
OjQ1OjE2IG40IEhWTTE4WzE4MzAyXTogICBYRU5VVElMOiBYZW5ldnRjaG5NYXBSZXNvdXJjZXMg
c2V0dGluZyBjYWxsYmFjayBpcnEgdG8gMTEgDQpEZWMgMjkgMTc6NDU6MTYgbjQgSFZNMThbMTgz
MDJdOiAgIFhFVlRDSE46IFBWIGluaXQuIGRvbmUgDQpEZWMgMjkgMTc6NDU6MTYgbjQgSFZNMThb
MTgzMDJdOiAgIFhFTlVUSUw6IEJhbGxvb25UYXJnZXRDaGFuZ2VkOiA0Mzc5MjM4NGsgLT4gNDg5
MTEzNjBrIA0KRGVjIDI5IDE3OjQ1OjE2IG40IEhWTTE4WzE4MzAyXTogICBYRU5VVElMOiBCYWxs
b29uV29ya2VyVGhyZWFkOiBhY3RpdmF0aW5nIA0KRGVjIDI5IDE3OjQ1OjE2IG40IEhWTTE4WzE4
MzAyXTogICBYRVZUQ0hOOiBEZXRlY3RlZCBuZXcgZGV2aWNlIHZpZi8wLiANCkRlYyAyOSAxNzo0
NToxNiBuNCBIVk0xOFsxODMwMl06ICAgWEVWVENITjogY2xvc2luZyBkZXZpY2UvdmlmLzAuLi4g
DQpEZWMgMjkgMTc6NDU6MTYgbjQgSFZNMThbMTgzMDJdOiAgIFhFVlRDSE46IGRldmljZS92aWYv
MCBjbG9zZWQgDQpEZWMgMjkgMTc6NDU6MTYgbjQgSFZNMThbMTgzMDJdOiAgIFhFVlRDSE46IFN0
YXJ0RGV2aWNlRmRvOiA8PT09PSAoMDAwMDAwMDApIA0KRGVjIDI5IDE3OjQ1OjE3IG40IEhWTTE4
WzE4MzAyXTogICBYRU5VVElMOiBCYWxsb29uV29ya2VyVGhyZWFkOiBkZWZsYXRlZCBiYWxsb29u
IGJ5IDEyNzk3NDQgcGFnZShzKSBpbiA5OThtcyAoODI1NjYway9zKSANCkRlYyAyOSAxNzo0NTox
NyBuNCBIVk0xOFsxODMwMl06ICAgWEVOVVRJTDogQmFsbG9vbldvcmtlclRocmVhZDogZGUtYWN0
aXZhdGluZyANCkRlYyAyOSAxNzo0NToxOCBuNCBIVk0xOFsxODMwMl06ICAgIFhFTlZCRDogWEVO
VkJEIGluIE5PUk1BTCBtb2RlLiANCkRlYyAyOSAxNzo0NToxOCBuNCBIVk0xOFsxODMwMl06ICAg
IFhFTlZCRDogWGVudmJkQWRkRGV2aWNlOiBGRE8gPSAweEZGRkZGQTgwNDQzNEIwNjAgDQpEZWMg
MjkgMTc6NDU6MTggbjQgSFZNMThbMTgzMDJdOiAgIFhFTlVUSUw6IFdBUk5JTkc6IElPIGhvbGUg
YWxyZWFkeSBpbml0aWFsaXplZCBieSBYRVZUQ0hOIA0KRGVjIDI5IDE3OjQ1OjE4IG40IEhWTTE4
WzE4MzAyXTogICBYRU5VVElMOiBXQVJOSU5HOiBCdWdjaGVjayBjYWxsYmFjayBhbHJlYWR5IGlu
c3RhbGxlZCANCkRlYyAyOSAxNzo0NToxOCBuNCBIVk0xOFsxODMwMl06ICAgWEVOVVRJTDogV0FS
TklORzogQnVnY2hlY2sgcmVhc29uIGNhbGxiYWNrIGFscmVhZHkgaW5zdGFsbGVkIA0KRGVjIDI5
IDE3OjQ1OjE4IG40IEhWTTE4WzE4MzAyXTogICAgWEVOVkJEOiBSZXNjYW5UaHJlYWQ6IHN0YXJ0
aW5nIA0KRGVjIDI5IDE3OjQ1OjE4IG40IEhWTTE4WzE4MzAyXTogICBYRU5VVElMOiBYZW52YmRI
d0luaXRpYWxpemUgc2V0dGluZyBjYWxsYmFjayBpcnEgdG8gMzAgDQpEZWMgMjkgMTc6NDU6MTkg
bjQgSFZNMThbMTgzMDJdOiAgICBYRU5WQkQ6IERldmljZVJlbGF0aW9uc0Zkbzogc2Nhbm5pbmcg
dGFyZ2V0cy4uLiANCkRlYyAyOSAxNzo0NToxOSBuNCBIVk0xOFsxODMwMl06ICAgIFhFTlZCRDog
WGVuYnVzRmluZFZiZHM6IGZvdW5kIG5ldyBkaXNrIChWQkQgNzY4KSANCkRlYyAyOSAxNzo0NTox
OSBuNCBIVk0xOFsxODMwMl06ICAgIFhFTlZCRDogWGVuYnVzRmluZFZiZHM6IGlnbm9yaW5nIGNk
cm9tIChWQkQgNTY5NikgDQpEZWMgMjkgMTc6NDU6MTkgbjQgSFZNMThbMTgzMDJdOiAgICBYRU5W
QkQ6IHRhcmdldCAwOiBjbGFpbWluZyBmcm9udGVuZC4uLiANCkRlYyAyOSAxNzo0NToxOSBuNCBI
Vk0xOFsxODMwMl06ICAgIFhFTlZCRDogdGFyZ2V0IDA6IHN1Y2Nlc3NmdWx5IGNsYWltZWQgZGV2
aWNlL3ZiZC83NjggDQpEZWMgMjkgMTc6NDU6MTkgbjQgSFZNMThbMTgzMDJdOiAgICBYRU5WQkQ6
IHRhcmdldCAwOiBzeW50aGVzaXNpbmcgaW5xdWlyeSBkYXRhOiBkZWZhdWx0IHBhZ2UgDQpEZWMg
MjkgMTc6NDU6MTkgbjQgSFZNMThbMTgzMDJdOiAgICBYRU5WQkQ6IHRhcmdldCAwOiB1bml0IHNl
cmlhbCBudW1iZXIgPSAnNjJjNWE1MDEtZDY2Mi00ZCAgJyANCkRlYyAyOSAxNzo0NToxOSBuNCBI
Vk0xOFsxODMwMl06ICAgIFhFTlZCRDogdGFyZ2V0IDA6IGRldmljZSBpZGVudGlmaWVyWzBdOiBD
b2RlU2V0OiAnQXNjaWknIFR5cGU6ICdWZW5kb3JJZCcgQXNzb2NhdGlvbjogJ0RldmljZScgDQpE
ZWMgMjkgMTc6NDU6MTkgbjQgSFZNMThbMTgzMDJdOiAgICBYRU5WQkQ6IHRhcmdldCAwOiBkZXZp
Y2UgaWRlbnRpZmllclswXTogTGVuZ3RoID0gNDUgRGF0YSA9ICdYRU5TUkMgIDYyYzVhNTAxLWQ2
NjItNGQzOC1hNzVjLWEyODBlMjkyOTI5NyAnIA0KRGVjIDI5IDE3OjQ1OjE5IG40IEhWTTE4WzE4
MzAyXTogICAgWEVOVkJEOiB0YXJnZXQgMDogY2xvc2luZyBmcm9udGVuZC4uLiANCkRlYyAyOSAx
Nzo0NToxOSBuNCBIVk0xOFsxODMwMl06ICAgIFhFTlZCRDogdGFyZ2V0IDA6IGJhY2tlbmQgaXMg
Y2xvc2VkIA0KRGVjIDI5IDE3OjQ1OjE5IG40IEhWTTE4WzE4MzAyXTogICAgWEVOVkJEOiB0YXJn
ZXQgMDogY3JlYXRlZCANCg==
--0016364c78d1eb08b604b53ede35
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--0016364c78d1eb08b604b53ede35--


From xen-devel-bounces@lists.xensource.com Thu Dec 29 18:58:35 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 29 Dec 2011 18:58:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RgLAm-0000OK-UR; Thu, 29 Dec 2011 18:57:52 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RgLAk-0000OC-Vr
	for xen-devel@lists.xensource.com; Thu, 29 Dec 2011 18:57:51 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1325185064!1682738!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODcwNA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2238 invoked from network); 29 Dec 2011 18:57:44 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Dec 2011 18:57:44 -0000
X-IronPort-AV: E=Sophos;i="4.71,428,1320624000"; 
   d="scan'208";a="9741585"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Dec 2011 18:57:44 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 29 Dec 2011 18:57:37 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RgLAW-0001rK-S8;
	Thu, 29 Dec 2011 18:57:36 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RgLAW-0001ZW-R7;
	Thu, 29 Dec 2011 18:57:36 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10614-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 29 Dec 2011 18:57:36 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10614: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10614 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10614/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-i386-i386-pv            16 guest-start.2               fail pass in 10613
 test-i386-i386-xl-winxpsp3    7 windows-install    fail in 10613 pass in 10614
 test-amd64-amd64-win          7 windows-install    fail in 10613 pass in 10614

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 14 guest-localmigrate/x10       fail   like 10609
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 10598
 test-amd64-i386-rhel6hvm-amd  7 redhat-install        fail in 10613 like 10598

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  a7b2610b8e5c
baseline version:
 xen                  2863b2f43a3b

------------------------------------------------------------
People who touched revisions under test:
  Gang Wei <gang.wei@intel.com>
  Haitao Shan <haitao.shan@intel.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Shan Haitao <maillists.shan@gmail.com>
  Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            fail    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-unstable
+ revision=a7b2610b8e5c
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-unstable a7b2610b8e5c
+ branch=xen-unstable
+ revision=a7b2610b8e5c
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ : xen@xenbits.xensource.com
+ : xen@xenbits.xensource.com:git/linux-pvops
+ : master
+ : tested/2.6.39.x
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r a7b2610b8e5c ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 1 changesets with 1 changes to 1 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Dec 29 18:58:35 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 29 Dec 2011 18:58:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RgLAm-0000OK-UR; Thu, 29 Dec 2011 18:57:52 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RgLAk-0000OC-Vr
	for xen-devel@lists.xensource.com; Thu, 29 Dec 2011 18:57:51 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1325185064!1682738!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODcwNA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2238 invoked from network); 29 Dec 2011 18:57:44 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Dec 2011 18:57:44 -0000
X-IronPort-AV: E=Sophos;i="4.71,428,1320624000"; 
   d="scan'208";a="9741585"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Dec 2011 18:57:44 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 29 Dec 2011 18:57:37 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RgLAW-0001rK-S8;
	Thu, 29 Dec 2011 18:57:36 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RgLAW-0001ZW-R7;
	Thu, 29 Dec 2011 18:57:36 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10614-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 29 Dec 2011 18:57:36 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10614: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10614 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10614/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-i386-i386-pv            16 guest-start.2               fail pass in 10613
 test-i386-i386-xl-winxpsp3    7 windows-install    fail in 10613 pass in 10614
 test-amd64-amd64-win          7 windows-install    fail in 10613 pass in 10614

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 14 guest-localmigrate/x10       fail   like 10609
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 10598
 test-amd64-i386-rhel6hvm-amd  7 redhat-install        fail in 10613 like 10598

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  a7b2610b8e5c
baseline version:
 xen                  2863b2f43a3b

------------------------------------------------------------
People who touched revisions under test:
  Gang Wei <gang.wei@intel.com>
  Haitao Shan <haitao.shan@intel.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Shan Haitao <maillists.shan@gmail.com>
  Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            fail    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-unstable
+ revision=a7b2610b8e5c
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-unstable a7b2610b8e5c
+ branch=xen-unstable
+ revision=a7b2610b8e5c
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ : xen@xenbits.xensource.com
+ : xen@xenbits.xensource.com:git/linux-pvops
+ : master
+ : tested/2.6.39.x
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r a7b2610b8e5c ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 1 changesets with 1 changes to 1 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 30 05:11:54 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 30 Dec 2011 05:11:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RgUkA-0007Sy-MI; Fri, 30 Dec 2011 05:11:02 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RgUk9-0007St-27
	for xen-devel@lists.xensource.com; Fri, 30 Dec 2011 05:11:01 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1325221854!7211281!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODc2Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32596 invoked from network); 30 Dec 2011 05:10:55 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Dec 2011 05:10:55 -0000
X-IronPort-AV: E=Sophos;i="4.71,430,1320624000"; 
   d="scan'208";a="9745583"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Dec 2011 05:10:54 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 30 Dec 2011 05:10:53 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RgUk1-0005C5-R2;
	Fri, 30 Dec 2011 05:10:53 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RgUk1-0000Oi-Kf;
	Fri, 30 Dec 2011 05:10:53 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10618-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 30 Dec 2011 05:10:53 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10618: tolerable FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10618 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10618/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-credit2   16 guest-start.2               fail pass in 10614
 test-amd64-amd64-xl-sedf     14 guest-localmigrate/x10      fail pass in 10613
 test-amd64-i386-win           7 windows-install             fail pass in 10614
 test-amd64-amd64-xl-winxpsp3  7 windows-install             fail pass in 10614
 test-amd64-amd64-xl-sedf-pin 14 guest-localmigrate/x10 fail in 10614 pass in 10618
 test-amd64-amd64-xl-sedf      5 xen-boot           fail in 10614 pass in 10618
 test-amd64-i386-rhel6hvm-amd  7 redhat-install     fail in 10613 pass in 10618
 test-i386-i386-xl-winxpsp3    7 windows-install    fail in 10613 pass in 10618
 test-amd64-amd64-win          7 windows-install    fail in 10613 pass in 10618

Regressions which are regarded as allowable (not blocking):
 test-i386-i386-pv            16 guest-start.2                fail   like 10614

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check      fail in 10614 never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop            fail in 10614 never pass

version targeted for testing:
 xen                  a7b2610b8e5c
baseline version:
 xen                  a7b2610b8e5c

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            fail    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 30 05:11:54 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 30 Dec 2011 05:11:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RgUkA-0007Sy-MI; Fri, 30 Dec 2011 05:11:02 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RgUk9-0007St-27
	for xen-devel@lists.xensource.com; Fri, 30 Dec 2011 05:11:01 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1325221854!7211281!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODc2Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32596 invoked from network); 30 Dec 2011 05:10:55 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Dec 2011 05:10:55 -0000
X-IronPort-AV: E=Sophos;i="4.71,430,1320624000"; 
   d="scan'208";a="9745583"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Dec 2011 05:10:54 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 30 Dec 2011 05:10:53 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RgUk1-0005C5-R2;
	Fri, 30 Dec 2011 05:10:53 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RgUk1-0000Oi-Kf;
	Fri, 30 Dec 2011 05:10:53 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10618-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 30 Dec 2011 05:10:53 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10618: tolerable FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10618 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10618/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-credit2   16 guest-start.2               fail pass in 10614
 test-amd64-amd64-xl-sedf     14 guest-localmigrate/x10      fail pass in 10613
 test-amd64-i386-win           7 windows-install             fail pass in 10614
 test-amd64-amd64-xl-winxpsp3  7 windows-install             fail pass in 10614
 test-amd64-amd64-xl-sedf-pin 14 guest-localmigrate/x10 fail in 10614 pass in 10618
 test-amd64-amd64-xl-sedf      5 xen-boot           fail in 10614 pass in 10618
 test-amd64-i386-rhel6hvm-amd  7 redhat-install     fail in 10613 pass in 10618
 test-i386-i386-xl-winxpsp3    7 windows-install    fail in 10613 pass in 10618
 test-amd64-amd64-win          7 windows-install    fail in 10613 pass in 10618

Regressions which are regarded as allowable (not blocking):
 test-i386-i386-pv            16 guest-start.2                fail   like 10614

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check      fail in 10614 never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop            fail in 10614 never pass

version targeted for testing:
 xen                  a7b2610b8e5c
baseline version:
 xen                  a7b2610b8e5c

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            fail    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 30 11:20:42 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 30 Dec 2011 11:20:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RgaV9-0002ul-1z; Fri, 30 Dec 2011 11:19:55 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RgaV7-0002ug-Vi
	for xen-devel@lists.xensource.com; Fri, 30 Dec 2011 11:19:54 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-9.tower-27.messagelabs.com!1325243954!58427323!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30235 invoked from network); 30 Dec 2011 11:19:14 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-9.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 30 Dec 2011 11:19:14 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RgaUy-0007Ce-HO; Fri, 30 Dec 2011 11:19:44 +0000
Date: Fri, 30 Dec 2011 11:19:43 +0000
From: Tim Deegan <tim@xen.org>
To: Jan Beulich <jbeulich@suse.com>
Message-ID: <20111230111943.GA27359@ocelot.phlegethon.org>
References: <4EFC8C73020000780007C160@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4EFC8C73020000780007C160@nat28.tlf.novell.com>
User-Agent: Mutt/1.4.2.1i
Cc: andrew.cooper3@citrix.com, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 3 of 3] KEXEC: Allocate crash structures in
	low memory
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 15:51 +0000 on 29 Dec (1325173875), Jan Beulich wrote:
> >This is part of the "min" option which is trying to have the least
> >possible impact.  The idea is to have this in low memory, use the
> >"console_to_ring" boot option to copy dom0 dmesg into conring, and pass
> >its physical address and size in a crash note, so that the crash kernel
> >environment grab it all.
> 
> Why is the console ring *that* important? I would have thought
> that proper register values and stack contents are much more
> significant for analysis of a crash.

The console ring has been _very_ useful in diagnosing bugs from field
reports, especially things like guest-level watchdog timeouts and
refcounting errors that cause a crash after the interesting event has
passed.  If nothing else it lets you verify the user's description of
the system, and saves a round-trip of 'please try to set up a serial
logger and reproduce the bug').

(I agree, though, that using a 64-bit crash kernel would be a much
better idea).

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 30 11:20:42 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 30 Dec 2011 11:20:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RgaV9-0002ul-1z; Fri, 30 Dec 2011 11:19:55 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RgaV7-0002ug-Vi
	for xen-devel@lists.xensource.com; Fri, 30 Dec 2011 11:19:54 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-9.tower-27.messagelabs.com!1325243954!58427323!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30235 invoked from network); 30 Dec 2011 11:19:14 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-9.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 30 Dec 2011 11:19:14 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RgaUy-0007Ce-HO; Fri, 30 Dec 2011 11:19:44 +0000
Date: Fri, 30 Dec 2011 11:19:43 +0000
From: Tim Deegan <tim@xen.org>
To: Jan Beulich <jbeulich@suse.com>
Message-ID: <20111230111943.GA27359@ocelot.phlegethon.org>
References: <4EFC8C73020000780007C160@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4EFC8C73020000780007C160@nat28.tlf.novell.com>
User-Agent: Mutt/1.4.2.1i
Cc: andrew.cooper3@citrix.com, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 3 of 3] KEXEC: Allocate crash structures in
	low memory
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 15:51 +0000 on 29 Dec (1325173875), Jan Beulich wrote:
> >This is part of the "min" option which is trying to have the least
> >possible impact.  The idea is to have this in low memory, use the
> >"console_to_ring" boot option to copy dom0 dmesg into conring, and pass
> >its physical address and size in a crash note, so that the crash kernel
> >environment grab it all.
> 
> Why is the console ring *that* important? I would have thought
> that proper register values and stack contents are much more
> significant for analysis of a crash.

The console ring has been _very_ useful in diagnosing bugs from field
reports, especially things like guest-level watchdog timeouts and
refcounting errors that cause a crash after the interesting event has
passed.  If nothing else it lets you verify the user's description of
the system, and saves a round-trip of 'please try to set up a serial
logger and reproduce the bug').

(I agree, though, that using a 64-bit crash kernel would be a much
better idea).

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 30 12:07:51 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 30 Dec 2011 12:07:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RgbEy-000493-G7; Fri, 30 Dec 2011 12:07:16 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <james.harper@bendigoit.com.au>) id 1RgbEw-00048v-9R
	for xen-devel@lists.xensource.com; Fri, 30 Dec 2011 12:07:14 +0000
X-Env-Sender: james.harper@bendigoit.com.au
X-Msg-Ref: server-15.tower-21.messagelabs.com!1325246825!10004640!1
X-Originating-IP: [203.16.207.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6855 invoked from network); 30 Dec 2011 12:07:08 -0000
Received: from mail.bendigoit.com.au (HELO smtp2.bendigoit.com.au)
	(203.16.207.99)
	by server-15.tower-21.messagelabs.com with AES256-SHA encrypted SMTP;
	30 Dec 2011 12:07:08 -0000
Received: from trantor.int.sbss.com.au ([192.168.200.206]
	helo=mail.bendigoit.com.au)
	by smtp2.bendigoit.com.au with esmtp (Exim 4.72)
	(envelope-from <james.harper@bendigoit.com.au>) id 1RgbEk-00021L-8d
	for xen-devel@lists.xensource.com; Fri, 30 Dec 2011 23:07:02 +1100
Received: from BITCOM1.int.sbss.com.au ([192.168.200.237]) by
	mail.bendigoit.com.au with Microsoft SMTPSVC(6.0.3790.4675); 
	Fri, 30 Dec 2011 23:07:01 +1100
Received: from BITCOM1.int.sbss.com.au ([fe80::a5ca:4fd3:14f:ad5d]) by
	BITCOM1.int.sbss.com.au ([fe80::a5ca:4fd3:14f:ad5d%12]) with mapi;
	Fri, 30 Dec 2011 23:07:00 +1100
From: James Harper <james.harper@bendigoit.com.au>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Thread-Topic: set_phys_to_machine not exported?
Thread-Index: AczG6u80khz7vVHcT2yyVywy4y+SeQ==
Date: Fri, 30 Dec 2011 12:06:58 +0000
Message-ID: <6035A0D088A63A46850C3988ED045A4B0594FA@BITCOM1.int.sbss.com.au>
Accept-Language: en-AU, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
MIME-Version: 1.0
X-OriginalArrivalTime: 30 Dec 2011 12:07:01.0810 (UTC)
	FILETIME=[89C7F920:01CCC6EB]
X-Really-From-Bendigo-IT: magichashvalue
Subject: [Xen-devel] set_phys_to_machine not exported?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

I'm trying to compile pvscsi out-of-tree, and I'm getting an error that set_phys_to_machine is not defined when I try to load the module (with the warning to that effect at compile time too). This used to work fine in pvops.

It seems that netfront uses that symbol in a module so I'm confused as to why pvscsi can't... any suggestions? Is it one of the virtues of netfront being an in-tree driver?

Is there another call I can use instead or does that symbol need to be exported?

Thanks

James

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Dec 30 12:07:51 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 30 Dec 2011 12:07:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RgbEy-000493-G7; Fri, 30 Dec 2011 12:07:16 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <james.harper@bendigoit.com.au>) id 1RgbEw-00048v-9R
	for xen-devel@lists.xensource.com; Fri, 30 Dec 2011 12:07:14 +0000
X-Env-Sender: james.harper@bendigoit.com.au
X-Msg-Ref: server-15.tower-21.messagelabs.com!1325246825!10004640!1
X-Originating-IP: [203.16.207.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6855 invoked from network); 30 Dec 2011 12:07:08 -0000
Received: from mail.bendigoit.com.au (HELO smtp2.bendigoit.com.au)
	(203.16.207.99)
	by server-15.tower-21.messagelabs.com with AES256-SHA encrypted SMTP;
	30 Dec 2011 12:07:08 -0000
Received: from trantor.int.sbss.com.au ([192.168.200.206]
	helo=mail.bendigoit.com.au)
	by smtp2.bendigoit.com.au with esmtp (Exim 4.72)
	(envelope-from <james.harper@bendigoit.com.au>) id 1RgbEk-00021L-8d
	for xen-devel@lists.xensource.com; Fri, 30 Dec 2011 23:07:02 +1100
Received: from BITCOM1.int.sbss.com.au ([192.168.200.237]) by
	mail.bendigoit.com.au with Microsoft SMTPSVC(6.0.3790.4675); 
	Fri, 30 Dec 2011 23:07:01 +1100
Received: from BITCOM1.int.sbss.com.au ([fe80::a5ca:4fd3:14f:ad5d]) by
	BITCOM1.int.sbss.com.au ([fe80::a5ca:4fd3:14f:ad5d%12]) with mapi;
	Fri, 30 Dec 2011 23:07:00 +1100
From: James Harper <james.harper@bendigoit.com.au>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Thread-Topic: set_phys_to_machine not exported?
Thread-Index: AczG6u80khz7vVHcT2yyVywy4y+SeQ==
Date: Fri, 30 Dec 2011 12:06:58 +0000
Message-ID: <6035A0D088A63A46850C3988ED045A4B0594FA@BITCOM1.int.sbss.com.au>
Accept-Language: en-AU, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
MIME-Version: 1.0
X-OriginalArrivalTime: 30 Dec 2011 12:07:01.0810 (UTC)
	FILETIME=[89C7F920:01CCC6EB]
X-Really-From-Bendigo-IT: magichashvalue
Subject: [Xen-devel] set_phys_to_machine not exported?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

I'm trying to compile pvscsi out-of-tree, and I'm getting an error that set_phys_to_machine is not defined when I try to load the module (with the warning to that effect at compile time too). This used to work fine in pvops.

It seems that netfront uses that symbol in a module so I'm confused as to why pvscsi can't... any suggestions? Is it one of the virtues of netfront being an in-tree driver?

Is there another call I can use instead or does that symbol need to be exported?

Thanks

James

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Dec 31 00:13:13 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 31 Dec 2011 00:13:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RgmYa-0000q7-Fh; Sat, 31 Dec 2011 00:12:16 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1RgmYY-0000pz-55
	for xen-devel@lists.xensource.com; Sat, 31 Dec 2011 00:12:14 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1325290327!9136190!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODg0OQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15528 invoked from network); 31 Dec 2011 00:12:07 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	31 Dec 2011 00:12:07 -0000
X-IronPort-AV: E=Sophos;i="4.71,435,1320624000"; 
   d="scan'208";a="9759264"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	31 Dec 2011 00:12:06 +0000
Received: from [10.30.248.173] (10.30.248.173) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Sat, 31 Dec 2011 00:12:06 +0000
Message-ID: <4EFE533D.5020307@citrix.com>
Date: Sat, 31 Dec 2011 00:11:41 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0.1
MIME-Version: 1.0
To: Jan Beulich <jbeulich@suse.com>
References: <4EFC8C73020000780007C160@nat28.tlf.novell.com>
In-Reply-To: <4EFC8C73020000780007C160@nat28.tlf.novell.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 3 of 3] KEXEC: Allocate crash structures in
 low memory
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 29/12/2011 15:51, Jan Beulich wrote:
>>>> Andrew Cooper  12/23/11 12:59 PM >>>
>> On 23/12/11 09:06, Jan Beulich wrote:
>>>>>> On 22.12.11 at 18:36, Andrew Cooper  wrote:
>>>> On 64bit Xen with 32bit dom0 and crashkernel, xmalloc'ing items such
>>>> as the CPU crash notes will go into the xenheap, which tends to be in
>>>> upper memory.  This causes problems on machines with more than 64GB
>>>> (or 4GB if no PAE support) of ram as the crashkernel physically cant
>>>> access the crash notes.
>>> What use is a crash dump taken with a 32-bit kernel on a machine
>>> with more than 64G (or more than 4G is the crash kernel doesn't
>>> support PAE)?
>> Very little use at all, which is the reason for this change.
> With this change, the usefulness doesn't significantly increase imo.

But it does make it possible for a 32bit crashkernel to get information
useful for debugging a problem, which is the point of the patch.  If you
honestly thing that this change is not worth the effort then that is
fine, but as far as I am aware, there are still several good reasons to
use a 32bit dom0 over a 64bit dom0.  Following this reasoning is why I
believe that this feature may be useful to other projects, as well as
XenServer.

>> The correct solution is indeed to use a 64bit dom0 kernel, but while
>> politics is preventing that from happening, another solution has to be
>> found.  I doubt that XenServer is the only product which would benifit,
>> which is why the changes are presented for upstreaming.
>>
>>>>  3) Change the conring buffer to use lower memory when instructed.
>>> Why does this one need moving, but none of the other Xen data
>>> structures? If anything, I would have expected you to limit the Xen
>>> heap altogether, so that automatically all allocations get done in a
>>> way so that at least Xen's data structures are available in the
>>> (truncated) dump.
>> This is part of the "min" option which is trying to have the least
>> possible impact.  The idea is to have this in low memory, use the
>> "console_to_ring" boot option to copy dom0 dmesg into conring, and pass
>> its physical address and size in a crash note, so that the crash kernel
>> environment grab it all.
> Why is the console ring *that* important? I would have thought
> that proper register values and stack contents are much more
> significant for analysis of a crash.
>
> Jan

In combination with "console_to_ring" on the Xen command line, the dom0
serial console will be copied into xen console ring.  In the case of a
crash, it is highly likely that one or other of them have panic()'d into
their respective console rings.  It is not a foolproof solution, but in
will work in the general case.

The register contents of the pcpus which were running will be available
in the PR_STATUS notes which are also deliberately allocated in low
memory by this patch.  To the best of my understanding; to get to the
dom0 vcpu state, the crashkernel needs access to the domain structs and
vcpu structs (which I believe are actually allocated below 4GiB) and the
Xen page tables which dom0 uses (which inspecting CR3 from the crash
notes is certainly not in lower memory).  I suspect that there is also
more which needs to be allocated in lower memory to get a full register
dump, stack dump, stack trace etc.

The plan is to also have the "all" option from the command line which
will also allocate the page tables (and other structures where relevant)
in lower memory, but this is rather more of an overhead than just the
console ring and crash notes, which will have a more visible impact to
customers running 32bit PV guests.  This is the reason for separating
the two via a command line argument.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Dec 31 00:13:13 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 31 Dec 2011 00:13:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RgmYa-0000q7-Fh; Sat, 31 Dec 2011 00:12:16 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1RgmYY-0000pz-55
	for xen-devel@lists.xensource.com; Sat, 31 Dec 2011 00:12:14 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1325290327!9136190!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODg0OQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15528 invoked from network); 31 Dec 2011 00:12:07 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	31 Dec 2011 00:12:07 -0000
X-IronPort-AV: E=Sophos;i="4.71,435,1320624000"; 
   d="scan'208";a="9759264"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	31 Dec 2011 00:12:06 +0000
Received: from [10.30.248.173] (10.30.248.173) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Sat, 31 Dec 2011 00:12:06 +0000
Message-ID: <4EFE533D.5020307@citrix.com>
Date: Sat, 31 Dec 2011 00:11:41 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0.1
MIME-Version: 1.0
To: Jan Beulich <jbeulich@suse.com>
References: <4EFC8C73020000780007C160@nat28.tlf.novell.com>
In-Reply-To: <4EFC8C73020000780007C160@nat28.tlf.novell.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 3 of 3] KEXEC: Allocate crash structures in
 low memory
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 29/12/2011 15:51, Jan Beulich wrote:
>>>> Andrew Cooper  12/23/11 12:59 PM >>>
>> On 23/12/11 09:06, Jan Beulich wrote:
>>>>>> On 22.12.11 at 18:36, Andrew Cooper  wrote:
>>>> On 64bit Xen with 32bit dom0 and crashkernel, xmalloc'ing items such
>>>> as the CPU crash notes will go into the xenheap, which tends to be in
>>>> upper memory.  This causes problems on machines with more than 64GB
>>>> (or 4GB if no PAE support) of ram as the crashkernel physically cant
>>>> access the crash notes.
>>> What use is a crash dump taken with a 32-bit kernel on a machine
>>> with more than 64G (or more than 4G is the crash kernel doesn't
>>> support PAE)?
>> Very little use at all, which is the reason for this change.
> With this change, the usefulness doesn't significantly increase imo.

But it does make it possible for a 32bit crashkernel to get information
useful for debugging a problem, which is the point of the patch.  If you
honestly thing that this change is not worth the effort then that is
fine, but as far as I am aware, there are still several good reasons to
use a 32bit dom0 over a 64bit dom0.  Following this reasoning is why I
believe that this feature may be useful to other projects, as well as
XenServer.

>> The correct solution is indeed to use a 64bit dom0 kernel, but while
>> politics is preventing that from happening, another solution has to be
>> found.  I doubt that XenServer is the only product which would benifit,
>> which is why the changes are presented for upstreaming.
>>
>>>>  3) Change the conring buffer to use lower memory when instructed.
>>> Why does this one need moving, but none of the other Xen data
>>> structures? If anything, I would have expected you to limit the Xen
>>> heap altogether, so that automatically all allocations get done in a
>>> way so that at least Xen's data structures are available in the
>>> (truncated) dump.
>> This is part of the "min" option which is trying to have the least
>> possible impact.  The idea is to have this in low memory, use the
>> "console_to_ring" boot option to copy dom0 dmesg into conring, and pass
>> its physical address and size in a crash note, so that the crash kernel
>> environment grab it all.
> Why is the console ring *that* important? I would have thought
> that proper register values and stack contents are much more
> significant for analysis of a crash.
>
> Jan

In combination with "console_to_ring" on the Xen command line, the dom0
serial console will be copied into xen console ring.  In the case of a
crash, it is highly likely that one or other of them have panic()'d into
their respective console rings.  It is not a foolproof solution, but in
will work in the general case.

The register contents of the pcpus which were running will be available
in the PR_STATUS notes which are also deliberately allocated in low
memory by this patch.  To the best of my understanding; to get to the
dom0 vcpu state, the crashkernel needs access to the domain structs and
vcpu structs (which I believe are actually allocated below 4GiB) and the
Xen page tables which dom0 uses (which inspecting CR3 from the crash
notes is certainly not in lower memory).  I suspect that there is also
more which needs to be allocated in lower memory to get a full register
dump, stack dump, stack trace etc.

The plan is to also have the "all" option from the command line which
will also allocate the page tables (and other structures where relevant)
in lower memory, but this is rather more of an overhead than just the
console ring and crash notes, which will have a more visible impact to
customers running 32bit PV guests.  This is the reason for separating
the two via a command line argument.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Dec 31 02:56:30 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 31 Dec 2011 02: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.xensource.com>)
	id 1Rgp6d-0005Yg-JS; Sat, 31 Dec 2011 02:55:35 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <liu.yi24@zte.com.cn>) id 1Rgp6c-0005Yb-RC
	for xen-devel@lists.xensource.com; Sat, 31 Dec 2011 02:55:35 +0000
X-Env-Sender: liu.yi24@zte.com.cn
X-Msg-Ref: server-2.tower-182.messagelabs.com!1325300126!9117416!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4833 invoked from network); 31 Dec 2011 02:55:27 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-2.tower-182.messagelabs.com with AES256-SHA encrypted SMTP;
	31 Dec 2011 02:55:27 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <liu.yi24@zte.com.cn>) id 1Rgp6T-0002MH-Lm
	for xen-devel@lists.xensource.com; Fri, 30 Dec 2011 18:55:25 -0800
Date: Fri, 30 Dec 2011 18:55:25 -0800 (PST)
From: "Liu.yi" <liu.yi24@zte.com.cn>
To: xen-devel@lists.xensource.com
Message-ID: <1325300125668-5111504.post@n5.nabble.com>
MIME-Version: 1.0
Subject: [Xen-devel] credit scheduler svc->flags access race?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

hi,all
In my HP DL380G7 server, csched_vcpu_yield and csched_acct may access
svc->flags at the same time, when this happens vms stop running because
csched_vcpu_yield overwrites svc->flags which csched_acct set to
CSCHED_FLAG_VCPU_PARKED (My vm's schedule cap values is not 0).
Vms run fine if I modified schedule_credit.c as follows:

--- xen/common/sched_credit.c   2010-12-10 10:19:45.000000000 +0800
+++ ../../xen-4.1.0/xen/common/sched_credit.c   2010-12-31
10:47:39.000000000 +0800
@@ -135,7 +135,7 @@ struct csched_vcpu {
     struct vcpu *vcpu;
     atomic_t credit;
     s_time_t start_time;   /* When we were scheduled (used for credit) */
-    uint16_t flags;
+    uint32_t flags;
     int16_t pri;
 #ifdef CSCHED_STATS
     struct {
@@ -787,7 +787,7 @@ csched_vcpu_yield(const struct scheduler
     if ( !sched_credit_default_yield )
     {
         /* Let the scheduler know that this vcpu is trying to yield */
-        sv->flags |= CSCHED_FLAG_VCPU_YIELD;
+        set_bit(1, &sv->flags);
     }
 }
 
@@ -1086,7 +1086,7 @@ csched_acct(void* dummy)
                 {
                     CSCHED_STAT_CRANK(vcpu_park);
                     vcpu_pause_nosync(svc->vcpu);
-                    svc->flags |= CSCHED_FLAG_VCPU_PARKED;
+                    set_bit(0, &svc->flags);
                 }
 
                 /* Lower bound on credits */
@@ -1111,7 +1111,7 @@ csched_acct(void* dummy)
                      */
                     CSCHED_STAT_CRANK(vcpu_unpark);
                     vcpu_unpause(svc->vcpu);
-                    svc->flags &= ~CSCHED_FLAG_VCPU_PARKED;
+                    clear_bit(0, &svc->flags);
                 }
 
                 /* Upper bound on credits means VCPU stops earning */
@@ -1337,7 +1337,7 @@ csched_schedule(
      * Clear YIELD flag before scheduling out
      */
     if ( scurr->flags & CSCHED_FLAG_VCPU_YIELD )
-        scurr->flags &= ~(CSCHED_FLAG_VCPU_YIELD);
+        clear_bit(1, &scurr->flags);

Are these modification correct? Another interesting thing is that vms run
fine on other server even if these vms's credit cap value is not 0. I don't
know why.
My xen version is 4.1.0, dom0 kernel version is 2.6.32.41 from jerry's git a
few months before.

Thanks

liuyi


--
View this message in context: http://xen.1045712.n5.nabble.com/credit-scheduler-svc-flags-access-race-tp5111504p5111504.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Dec 31 02:56:30 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 31 Dec 2011 02: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.xensource.com>)
	id 1Rgp6d-0005Yg-JS; Sat, 31 Dec 2011 02:55:35 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <liu.yi24@zte.com.cn>) id 1Rgp6c-0005Yb-RC
	for xen-devel@lists.xensource.com; Sat, 31 Dec 2011 02:55:35 +0000
X-Env-Sender: liu.yi24@zte.com.cn
X-Msg-Ref: server-2.tower-182.messagelabs.com!1325300126!9117416!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4833 invoked from network); 31 Dec 2011 02:55:27 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-2.tower-182.messagelabs.com with AES256-SHA encrypted SMTP;
	31 Dec 2011 02:55:27 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <liu.yi24@zte.com.cn>) id 1Rgp6T-0002MH-Lm
	for xen-devel@lists.xensource.com; Fri, 30 Dec 2011 18:55:25 -0800
Date: Fri, 30 Dec 2011 18:55:25 -0800 (PST)
From: "Liu.yi" <liu.yi24@zte.com.cn>
To: xen-devel@lists.xensource.com
Message-ID: <1325300125668-5111504.post@n5.nabble.com>
MIME-Version: 1.0
Subject: [Xen-devel] credit scheduler svc->flags access race?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

hi,all
In my HP DL380G7 server, csched_vcpu_yield and csched_acct may access
svc->flags at the same time, when this happens vms stop running because
csched_vcpu_yield overwrites svc->flags which csched_acct set to
CSCHED_FLAG_VCPU_PARKED (My vm's schedule cap values is not 0).
Vms run fine if I modified schedule_credit.c as follows:

--- xen/common/sched_credit.c   2010-12-10 10:19:45.000000000 +0800
+++ ../../xen-4.1.0/xen/common/sched_credit.c   2010-12-31
10:47:39.000000000 +0800
@@ -135,7 +135,7 @@ struct csched_vcpu {
     struct vcpu *vcpu;
     atomic_t credit;
     s_time_t start_time;   /* When we were scheduled (used for credit) */
-    uint16_t flags;
+    uint32_t flags;
     int16_t pri;
 #ifdef CSCHED_STATS
     struct {
@@ -787,7 +787,7 @@ csched_vcpu_yield(const struct scheduler
     if ( !sched_credit_default_yield )
     {
         /* Let the scheduler know that this vcpu is trying to yield */
-        sv->flags |= CSCHED_FLAG_VCPU_YIELD;
+        set_bit(1, &sv->flags);
     }
 }
 
@@ -1086,7 +1086,7 @@ csched_acct(void* dummy)
                 {
                     CSCHED_STAT_CRANK(vcpu_park);
                     vcpu_pause_nosync(svc->vcpu);
-                    svc->flags |= CSCHED_FLAG_VCPU_PARKED;
+                    set_bit(0, &svc->flags);
                 }
 
                 /* Lower bound on credits */
@@ -1111,7 +1111,7 @@ csched_acct(void* dummy)
                      */
                     CSCHED_STAT_CRANK(vcpu_unpark);
                     vcpu_unpause(svc->vcpu);
-                    svc->flags &= ~CSCHED_FLAG_VCPU_PARKED;
+                    clear_bit(0, &svc->flags);
                 }
 
                 /* Upper bound on credits means VCPU stops earning */
@@ -1337,7 +1337,7 @@ csched_schedule(
      * Clear YIELD flag before scheduling out
      */
     if ( scurr->flags & CSCHED_FLAG_VCPU_YIELD )
-        scurr->flags &= ~(CSCHED_FLAG_VCPU_YIELD);
+        clear_bit(1, &scurr->flags);

Are these modification correct? Another interesting thing is that vms run
fine on other server even if these vms's credit cap value is not 0. I don't
know why.
My xen version is 4.1.0, dom0 kernel version is 2.6.32.41 from jerry's git a
few months before.

Thanks

liuyi


--
View this message in context: http://xen.1045712.n5.nabble.com/credit-scheduler-svc-flags-access-race-tp5111504p5111504.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Dec 31 05:44:46 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 31 Dec 2011 05: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.xensource.com>)
	id 1Rgrjc-0007H8-G4; Sat, 31 Dec 2011 05:44:00 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Rgrja-0007H3-Hu
	for xen-devel@lists.xensource.com; Sat, 31 Dec 2011 05:43:58 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1325310232!7357788!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODkwMA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8741 invoked from network); 31 Dec 2011 05:43:52 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	31 Dec 2011 05:43:52 -0000
X-IronPort-AV: E=Sophos;i="4.71,436,1320624000"; 
   d="scan'208";a="9760038"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	31 Dec 2011 05:43:51 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sat, 31 Dec 2011 05:43:51 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RgrjT-00053E-4I;
	Sat, 31 Dec 2011 05:43:51 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RgrjS-0006pv-Ow;
	Sat, 31 Dec 2011 05:43:50 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10619-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 31 Dec 2011 05:43:50 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10619: tolerable FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10619 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10619/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-pv          16 guest-start.2               fail pass in 10618
 test-i386-i386-xl            16 guest-start.2               fail pass in 10618
 test-amd64-i386-xend-winxpsp3  7 windows-install            fail pass in 10618
 test-amd64-i386-xl-win7-amd64  7 windows-install            fail pass in 10618
 test-amd64-i386-win           7 windows-install    fail in 10618 pass in 10619
 test-amd64-amd64-xl-winxpsp3  7 windows-install    fail in 10618 pass in 10619

Regressions which are regarded as allowable (not blocking):
 test-i386-i386-pv            16 guest-start.2                fail   like 10618
 test-amd64-amd64-xl-sedf     14 guest-localmigrate/x10       fail   like 10618
 test-amd64-i386-xl-credit2   16 guest-start.2                fail   like 10618

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check     fail in 10618 never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop           fail in 10618 never pass

version targeted for testing:
 xen                  a7b2610b8e5c
baseline version:
 xen                  a7b2610b8e5c

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            fail    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          fail    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            fail    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Dec 31 05:44:46 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 31 Dec 2011 05: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.xensource.com>)
	id 1Rgrjc-0007H8-G4; Sat, 31 Dec 2011 05:44:00 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Rgrja-0007H3-Hu
	for xen-devel@lists.xensource.com; Sat, 31 Dec 2011 05:43:58 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1325310232!7357788!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODkwMA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8741 invoked from network); 31 Dec 2011 05:43:52 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	31 Dec 2011 05:43:52 -0000
X-IronPort-AV: E=Sophos;i="4.71,436,1320624000"; 
   d="scan'208";a="9760038"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	31 Dec 2011 05:43:51 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sat, 31 Dec 2011 05:43:51 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RgrjT-00053E-4I;
	Sat, 31 Dec 2011 05:43:51 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RgrjS-0006pv-Ow;
	Sat, 31 Dec 2011 05:43:50 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10619-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 31 Dec 2011 05:43:50 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10619: tolerable FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10619 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10619/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-pv          16 guest-start.2               fail pass in 10618
 test-i386-i386-xl            16 guest-start.2               fail pass in 10618
 test-amd64-i386-xend-winxpsp3  7 windows-install            fail pass in 10618
 test-amd64-i386-xl-win7-amd64  7 windows-install            fail pass in 10618
 test-amd64-i386-win           7 windows-install    fail in 10618 pass in 10619
 test-amd64-amd64-xl-winxpsp3  7 windows-install    fail in 10618 pass in 10619

Regressions which are regarded as allowable (not blocking):
 test-i386-i386-pv            16 guest-start.2                fail   like 10618
 test-amd64-amd64-xl-sedf     14 guest-localmigrate/x10       fail   like 10618
 test-amd64-i386-xl-credit2   16 guest-start.2                fail   like 10618

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check     fail in 10618 never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop           fail in 10618 never pass

version targeted for testing:
 xen                  a7b2610b8e5c
baseline version:
 xen                  a7b2610b8e5c

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            fail    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          fail    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            fail    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Dec 31 07:39:10 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 31 Dec 2011 07:39:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RgtWF-0007w6-6r; Sat, 31 Dec 2011 07:38:19 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jbeulich@suse.com>) id 1RgtWC-0007vy-Vg
	for xen-devel@lists.xensource.com; Sat, 31 Dec 2011 07:38:17 +0000
X-Env-Sender: jbeulich@suse.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1325317090!9144947!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18489 invoked from network); 31 Dec 2011 07:38:10 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-3.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 31 Dec 2011 07:38:10 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Sat, 31 Dec 2011 07:38:40 +0000
Message-Id: <4EFEBBDD020000780007C25E@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Sat, 31 Dec 2011 07:38:05 +0000
From: "Jan Beulich" <jbeulich@suse.com>
To: <andrew.cooper3@citrix.com>
References: <4EFC8C73020000780007C160@nat28.tlf.novell.com>
	<4EFE533D.5020307@citrix.com>
In-Reply-To: <4EFE533D.5020307@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 3 of 3] KEXEC: Allocate crash structures in
 low memory
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> Andrew Cooper <andrew.cooper3@citrix.com> 12/31/11 1:12 AM >>>
>The register contents of the pcpus which were running will be available
>in the PR_STATUS notes which are also deliberately allocated in low
>memory by this patch.  To the best of my understanding; to get to the
>dom0 vcpu state, the crashkernel needs access to the domain structs and
>vcpu structs (which I believe are actually allocated below 4GiB) and the

The vCPU ones are, while the domain one isn't.

>Xen page tables which dom0 uses (which inspecting CR3 from the crash
>notes is certainly not in lower memory).  I suspect that there is also
>more which needs to be allocated in lower memory to get a full register
>dump, stack dump, stack trace etc.
>
>The plan is to also have the "all" option from the command line which
>will also allocate the page tables (and other structures where relevant)
>in lower memory, but this is rather more of an overhead than just the
>console ring and crash notes, which will have a more visible impact to
>customers running 32bit PV guests.  This is the reason for separating
>the two via a command line argument.

I'm wondering whether, with much less impact on existing code, and as
already pointed out, restricting the allocation range of
alloc_xenheap_pages() (by way of a command line option) wouldn't get
you what you want.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Dec 31 07:39:10 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 31 Dec 2011 07:39:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RgtWF-0007w6-6r; Sat, 31 Dec 2011 07:38:19 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jbeulich@suse.com>) id 1RgtWC-0007vy-Vg
	for xen-devel@lists.xensource.com; Sat, 31 Dec 2011 07:38:17 +0000
X-Env-Sender: jbeulich@suse.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1325317090!9144947!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18489 invoked from network); 31 Dec 2011 07:38:10 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-3.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 31 Dec 2011 07:38:10 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Sat, 31 Dec 2011 07:38:40 +0000
Message-Id: <4EFEBBDD020000780007C25E@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Sat, 31 Dec 2011 07:38:05 +0000
From: "Jan Beulich" <jbeulich@suse.com>
To: <andrew.cooper3@citrix.com>
References: <4EFC8C73020000780007C160@nat28.tlf.novell.com>
	<4EFE533D.5020307@citrix.com>
In-Reply-To: <4EFE533D.5020307@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 3 of 3] KEXEC: Allocate crash structures in
 low memory
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> Andrew Cooper <andrew.cooper3@citrix.com> 12/31/11 1:12 AM >>>
>The register contents of the pcpus which were running will be available
>in the PR_STATUS notes which are also deliberately allocated in low
>memory by this patch.  To the best of my understanding; to get to the
>dom0 vcpu state, the crashkernel needs access to the domain structs and
>vcpu structs (which I believe are actually allocated below 4GiB) and the

The vCPU ones are, while the domain one isn't.

>Xen page tables which dom0 uses (which inspecting CR3 from the crash
>notes is certainly not in lower memory).  I suspect that there is also
>more which needs to be allocated in lower memory to get a full register
>dump, stack dump, stack trace etc.
>
>The plan is to also have the "all" option from the command line which
>will also allocate the page tables (and other structures where relevant)
>in lower memory, but this is rather more of an overhead than just the
>console ring and crash notes, which will have a more visible impact to
>customers running 32bit PV guests.  This is the reason for separating
>the two via a command line argument.

I'm wondering whether, with much less impact on existing code, and as
already pointed out, restricting the allocation range of
alloc_xenheap_pages() (by way of a command line option) wouldn't get
you what you want.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Dec 31 11:59:16 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 31 Dec 2011 11: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.xensource.com>)
	id 1RgxZk-0001vF-UO; Sat, 31 Dec 2011 11:58:12 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <250716708@qq.com>) id 1RgxZi-0001vA-SH
	for xen-devel@lists.xensource.com; Sat, 31 Dec 2011 11:58:11 +0000
X-Env-Sender: 250716708@qq.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1325332651!54243689!1
X-Originating-IP: [64.71.138.44]
X-SpamReason: No, hits=2.1 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA2NC43MS4xMzguNDQgPT4gMjA3NTYz\n,sa_preprocessor: 
	QmFkIElQOiA2NC43MS4xMzguNDQgPT4gMjA3NTYz\n,FROM_ALL_NUMS,
	FROM_STARTS_WITH_NUMS,HTML_30_40,HTML_MESSAGE,MIME_BASE64_TEXT,
	MIME_BOUND_NEXTPART,received_headers: No Received headers
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29724 invoked from network); 31 Dec 2011 11:57:32 -0000
Received: from smtpbg55.qq.com (HELO smtpbg55.qq.com) (64.71.138.44)
	by server-4.tower-27.messagelabs.com with SMTP;
	31 Dec 2011 11:57:32 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qq.com; s=s0907;
	t=1325332686; bh=8ySjCHcWPQDT32XjzSQPU01IAkqP9V6bfzerThF8V18=;
	h=X-QQ-SSF:X-HAS-ATTACH:X-QQ-BUSINESS-ORIGIN:X-Originating-IP:
	X-QQ-STYLE:X-QQ-mid:From:To:Subject:Mime-Version:Content-Type:
	Content-Transfer-Encoding:Date:X-Priority:Message-ID:X-QQ-MIME:
	X-Mailer:X-QQ-Mailer;
	b=gcM0Vs4qE9SrRRWu1WcSCd2XWw83yoJIoj/l/mFqhxLJwhKQ5HkRBcrdFFI9FUeGq
	Cp5CG+nz0f4atWKcIpLmT8yDIKx/DdxiUEgUEEyAxRsyNcKME5Om9F7NqkRuZNt
X-QQ-SSF: 00000000000000F0000000000000000
X-HAS-ATTACH: no
X-QQ-BUSINESS-ORIGIN: 2
X-Originating-IP: 69.163.32.120
X-QQ-STYLE: 
X-QQ-mid: webmail501t1325332684t1276678
From: "=?gbk?B?oei9S+y2YXdhcmU=?=" <250716708@qq.com>
To: "=?gbk?B?eGVuLWRldmVs?=" <xen-devel@lists.xensource.com>
Mime-Version: 1.0
Date: Sat, 31 Dec 2011 19:58:03 +0800
X-Priority: 3
Message-ID: <tencent_47FAD1C91256BB8566380A6B@qq.com>
X-QQ-MIME: TCMime 1.0 by Tencent
X-Mailer: QQMail 2.x
X-QQ-Mailer: QQMail 2.x
Subject: [Xen-devel] [help] Who's the author of libxc? I don't know how to
	start with it
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6366461952056841258=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a multi-part message in MIME format.

--===============6366461952056841258==
Content-Type: multipart/alternative;
	boundary="----=_NextPart_4EFEF8CC_08250B08_1112A034"
Content-Transfer-Encoding: 8Bit

This is a multi-part message in MIME format.

------=_NextPart_4EFEF8CC_08250B08_1112A034
Content-Type: text/plain;
	charset="gbk"
Content-Transfer-Encoding: base64

SGksDQogICAgIEkgd2FubmEgdHJ5IG15IGJlc3QgdG8gdW5kZXJzdGFuZCB0aGUgbGlieGMg
aW4geGVudG9vbHMsIGJ1dCBpdCdzIGRpZmZpY3VsdCBmb3IgbWUsIGEgbmV3ZXIsdG8gY29t
cHJlaGVuZCBpdCdzIHByaW5jaXBsZSENCiAgICAgQmVnZ2luZyBhZHZpY2UsdGhhbmtzIGEg
bG90IGFoZWFkIQ0KICANCiBiZXN0IHJlZ2FyZHMNCiBicnVjZQ==

------=_NextPart_4EFEF8CC_08250B08_1112A034
Content-Type: text/html;
	charset="gbk"
Content-Transfer-Encoding: base64

PERJVj5IaSw8L0RJVj4NCjxESVY+Jm5ic3A7Jm5ic3A7Jm5ic3A7IEkgd2FubmEgdHJ5IG15
IGJlc3QgdG8gdW5kZXJzdGFuZCB0aGUgbGlieGMgaW4geGVudG9vbHMsIGJ1dCBpdCdzIGRp
ZmZpY3VsdCBmb3IgbWUsIGEgbmV3ZXIsdG8gY29tcHJlaGVuZCBpdCdzIHByaW5jaXBsZSE8
L0RJVj4NCjxESVY+Jm5ic3A7Jm5ic3A7Jm5ic3A7IEJlZ2dpbmcgYWR2aWNlLHRoYW5rcyBh
IGxvdCBhaGVhZCE8L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPmJlc3QgcmVnYXJk
czwvRElWPg0KPERJVj5icnVjZTwvRElWPg==

------=_NextPart_4EFEF8CC_08250B08_1112A034--



--===============6366461952056841258==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============6366461952056841258==--



From xen-devel-bounces@lists.xensource.com Sat Dec 31 11:59:16 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 31 Dec 2011 11: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.xensource.com>)
	id 1RgxZk-0001vF-UO; Sat, 31 Dec 2011 11:58:12 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <250716708@qq.com>) id 1RgxZi-0001vA-SH
	for xen-devel@lists.xensource.com; Sat, 31 Dec 2011 11:58:11 +0000
X-Env-Sender: 250716708@qq.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1325332651!54243689!1
X-Originating-IP: [64.71.138.44]
X-SpamReason: No, hits=2.1 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA2NC43MS4xMzguNDQgPT4gMjA3NTYz\n,sa_preprocessor: 
	QmFkIElQOiA2NC43MS4xMzguNDQgPT4gMjA3NTYz\n,FROM_ALL_NUMS,
	FROM_STARTS_WITH_NUMS,HTML_30_40,HTML_MESSAGE,MIME_BASE64_TEXT,
	MIME_BOUND_NEXTPART,received_headers: No Received headers
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29724 invoked from network); 31 Dec 2011 11:57:32 -0000
Received: from smtpbg55.qq.com (HELO smtpbg55.qq.com) (64.71.138.44)
	by server-4.tower-27.messagelabs.com with SMTP;
	31 Dec 2011 11:57:32 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qq.com; s=s0907;
	t=1325332686; bh=8ySjCHcWPQDT32XjzSQPU01IAkqP9V6bfzerThF8V18=;
	h=X-QQ-SSF:X-HAS-ATTACH:X-QQ-BUSINESS-ORIGIN:X-Originating-IP:
	X-QQ-STYLE:X-QQ-mid:From:To:Subject:Mime-Version:Content-Type:
	Content-Transfer-Encoding:Date:X-Priority:Message-ID:X-QQ-MIME:
	X-Mailer:X-QQ-Mailer;
	b=gcM0Vs4qE9SrRRWu1WcSCd2XWw83yoJIoj/l/mFqhxLJwhKQ5HkRBcrdFFI9FUeGq
	Cp5CG+nz0f4atWKcIpLmT8yDIKx/DdxiUEgUEEyAxRsyNcKME5Om9F7NqkRuZNt
X-QQ-SSF: 00000000000000F0000000000000000
X-HAS-ATTACH: no
X-QQ-BUSINESS-ORIGIN: 2
X-Originating-IP: 69.163.32.120
X-QQ-STYLE: 
X-QQ-mid: webmail501t1325332684t1276678
From: "=?gbk?B?oei9S+y2YXdhcmU=?=" <250716708@qq.com>
To: "=?gbk?B?eGVuLWRldmVs?=" <xen-devel@lists.xensource.com>
Mime-Version: 1.0
Date: Sat, 31 Dec 2011 19:58:03 +0800
X-Priority: 3
Message-ID: <tencent_47FAD1C91256BB8566380A6B@qq.com>
X-QQ-MIME: TCMime 1.0 by Tencent
X-Mailer: QQMail 2.x
X-QQ-Mailer: QQMail 2.x
Subject: [Xen-devel] [help] Who's the author of libxc? I don't know how to
	start with it
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6366461952056841258=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a multi-part message in MIME format.

--===============6366461952056841258==
Content-Type: multipart/alternative;
	boundary="----=_NextPart_4EFEF8CC_08250B08_1112A034"
Content-Transfer-Encoding: 8Bit

This is a multi-part message in MIME format.

------=_NextPart_4EFEF8CC_08250B08_1112A034
Content-Type: text/plain;
	charset="gbk"
Content-Transfer-Encoding: base64

SGksDQogICAgIEkgd2FubmEgdHJ5IG15IGJlc3QgdG8gdW5kZXJzdGFuZCB0aGUgbGlieGMg
aW4geGVudG9vbHMsIGJ1dCBpdCdzIGRpZmZpY3VsdCBmb3IgbWUsIGEgbmV3ZXIsdG8gY29t
cHJlaGVuZCBpdCdzIHByaW5jaXBsZSENCiAgICAgQmVnZ2luZyBhZHZpY2UsdGhhbmtzIGEg
bG90IGFoZWFkIQ0KICANCiBiZXN0IHJlZ2FyZHMNCiBicnVjZQ==

------=_NextPart_4EFEF8CC_08250B08_1112A034
Content-Type: text/html;
	charset="gbk"
Content-Transfer-Encoding: base64

PERJVj5IaSw8L0RJVj4NCjxESVY+Jm5ic3A7Jm5ic3A7Jm5ic3A7IEkgd2FubmEgdHJ5IG15
IGJlc3QgdG8gdW5kZXJzdGFuZCB0aGUgbGlieGMgaW4geGVudG9vbHMsIGJ1dCBpdCdzIGRp
ZmZpY3VsdCBmb3IgbWUsIGEgbmV3ZXIsdG8gY29tcHJlaGVuZCBpdCdzIHByaW5jaXBsZSE8
L0RJVj4NCjxESVY+Jm5ic3A7Jm5ic3A7Jm5ic3A7IEJlZ2dpbmcgYWR2aWNlLHRoYW5rcyBh
IGxvdCBhaGVhZCE8L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPmJlc3QgcmVnYXJk
czwvRElWPg0KPERJVj5icnVjZTwvRElWPg==

------=_NextPart_4EFEF8CC_08250B08_1112A034--



--===============6366461952056841258==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============6366461952056841258==--



From xen-devel-bounces@lists.xensource.com Sat Dec 31 12:07:57 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 31 Dec 2011 12:07:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RgxiR-0002FO-Fl; Sat, 31 Dec 2011 12:07:11 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <250716708@qq.com>) id 1RgxiQ-0002FG-Df
	for xen-devel@lists.xensource.com; Sat, 31 Dec 2011 12:07:10 +0000
X-Env-Sender: 250716708@qq.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1325333222!9149092!1
X-Originating-IP: [64.71.138.43]
X-SpamReason: No, hits=1.9 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA2NC43MS4xMzguNDMgPT4gMjkwOTY1\n,sa_preprocessor: 
	QmFkIElQOiA2NC43MS4xMzguNDMgPT4gMjkwOTY1\n,FROM_ALL_NUMS,
	FROM_STARTS_WITH_NUMS, HTML_MESSAGE, MIME_BASE64_TEXT,
	MIME_BOUND_NEXTPART, received_headers: No Received headers
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3041 invoked from network); 31 Dec 2011 12:07:03 -0000
Received: from smtpbg52.qq.com (HELO smtpbg52.qq.com) (64.71.138.43)
	by server-6.tower-182.messagelabs.com with SMTP;
	31 Dec 2011 12:07:03 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qq.com; s=s0907;
	t=1325333221; bh=onbQH9IEs7wxou1OWflOT1VENM2BewN0d0JEoyQVM1Y=;
	h=X-QQ-SSF:X-HAS-ATTACH:X-QQ-BUSINESS-ORIGIN:X-Originating-IP:
	X-QQ-STYLE:X-QQ-mid:From:To:Subject:Mime-Version:Content-Type:
	Content-Transfer-Encoding:Date:X-Priority:Message-ID:X-QQ-MIME:
	X-Mailer:X-QQ-Mailer;
	b=BU8Xy9uE2hfSW2GdlnqLqUC6lMg3D79yGYbVReJBohqhBiblmb38oQ126rP4HUxFr
	YezlLf7bGEm2WsZfBaNhEcnuVTuTuS2E0Ikn7cYb1id4/f2iSM+irlmHYSCdR/h
X-QQ-SSF: 00000000000000F0000000000000000
X-HAS-ATTACH: no
X-QQ-BUSINESS-ORIGIN: 2
X-Originating-IP: 69.163.32.120
X-QQ-STYLE: 
X-QQ-mid: webmail501t1325333219t3683677
From: "=?gbk?B?oei9S+y2YXdhcmU=?=" <250716708@qq.com>
To: "=?gbk?B?eGVuLWRldmVs?=" <xen-devel@lists.xensource.com>
Mime-Version: 1.0
Date: Sat, 31 Dec 2011 20:06:59 +0800
X-Priority: 3
Message-ID: <tencent_139A0A6F06168A7D7DAAA6A0@qq.com>
X-QQ-MIME: TCMime 1.0 by Tencent
X-Mailer: QQMail 2.x
X-QQ-Mailer: QQMail 2.x
Subject: [Xen-devel] [help] problem with debuging
	/tools/ioemu-qemu-xen/xen-vl-extra.c
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1330395285898889554=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a multi-part message in MIME format.

--===============1330395285898889554==
Content-Type: multipart/alternative;
	boundary="----=_NextPart_4EFEFAE3_083EE2E8_5CE1DAE3"
Content-Transfer-Encoding: 8Bit

This is a multi-part message in MIME format.

------=_NextPart_4EFEFAE3_083EE2E8_5CE1DAE3
Content-Type: text/plain;
	charset="gbk"
Content-Transfer-Encoding: base64

SGkgZXZlcnlvbmUsDQogICAgIEkgYWRkZWQgZGVidWcgaW5mbyBpbiB0aGUgZnVuY3Rpb24g
ZG9fc2F2ZXZtIG9mIC90b29scy9pb2VtdS1xZW11LXhlbi94ZW4tdmwtZXh0cmEuYyBhcyBm
b2xsb3c6DQogIA0KICANCiBEQkcoImdvaW5nIHRvIHNhdmUuLi4iKTsgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgDQpyZXQgPSBxZW11X3NhdmV2bV9zdGF0ZShmKTsgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgDQogREJHKCJzYXZlIGZpbmlzaC4uLiIpOyAg
DQogIA0KIG9ubHkgdG8gc2VlICJnb2luZyB0byBzYXZlLi4uIiBhbmQgInNhdmUgZmluaXNo
Li4uIiBpbiB0aGUgbG9nIGZpbGUsYnV0IEkgY291bGRuJ3QgZ2V0IHRoZSBkZWJ1ZyBvdXRw
dXQgaW4gcWVtdV9zYXZldm1fc3RhdGUoZikgY2FsbGVkIGJ5ICJkb19zYXZldm0iLiBXaHkg
bm90Pw0KICANCiBiZXN0IHJlZ2FyZHMNCiBicnVjZQ==

------=_NextPart_4EFEFAE3_083EE2E8_5CE1DAE3
Content-Type: text/html;
	charset="gbk"
Content-Transfer-Encoding: base64

PERJVj5IaSBldmVyeW9uZSw8L0RJVj4NCjxESVY+Jm5ic3A7Jm5ic3A7Jm5ic3A7IEkgYWRk
ZWQgZGVidWcgaW5mbyBpbiB0aGUgZnVuY3Rpb24gZG9fc2F2ZXZtJm5ic3A7b2YgL3Rvb2xz
L2lvZW11LXFlbXUteGVuL3hlbi12bC1leHRyYS5jIGFzIGZvbGxvdzo8L0RJVj4NCjxESVY+
Jm5ic3A7PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj5EQkcoImdvaW5nIHRvIHNh
dmUuLi4iKTsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8QlI+
cmV0ID0gcWVtdV9zYXZldm1fc3RhdGUoZik7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PEJS
PiBEQkcoInNhdmUgZmluaXNoLi4uIik7Jm5ic3A7IDwvRElWPg0KPERJVj4mbmJzcDs8L0RJ
Vj4NCjxESVY+b25seSB0byBzZWUgImdvaW5nIHRvIHNhdmUuLi4iIGFuZCAic2F2ZSBmaW5p
c2guLi4iIGluIHRoZSBsb2cgZmlsZSxidXQgSSBjb3VsZG4ndCBnZXQgdGhlIGRlYnVnIG91
dHB1dCBpbiBxZW11X3NhdmV2bV9zdGF0ZShmKSBjYWxsZWQgYnkgImRvX3NhdmV2bSIuIFdo
eSBub3Q/PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj5iZXN0IHJlZ2FyZHM8L0RJ
Vj4NCjxESVY+YnJ1Y2U8L0RJVj4=

------=_NextPart_4EFEFAE3_083EE2E8_5CE1DAE3--



--===============1330395285898889554==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============1330395285898889554==--



From xen-devel-bounces@lists.xensource.com Sat Dec 31 12:07:57 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 31 Dec 2011 12:07:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RgxiR-0002FO-Fl; Sat, 31 Dec 2011 12:07:11 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <250716708@qq.com>) id 1RgxiQ-0002FG-Df
	for xen-devel@lists.xensource.com; Sat, 31 Dec 2011 12:07:10 +0000
X-Env-Sender: 250716708@qq.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1325333222!9149092!1
X-Originating-IP: [64.71.138.43]
X-SpamReason: No, hits=1.9 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA2NC43MS4xMzguNDMgPT4gMjkwOTY1\n,sa_preprocessor: 
	QmFkIElQOiA2NC43MS4xMzguNDMgPT4gMjkwOTY1\n,FROM_ALL_NUMS,
	FROM_STARTS_WITH_NUMS, HTML_MESSAGE, MIME_BASE64_TEXT,
	MIME_BOUND_NEXTPART, received_headers: No Received headers
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3041 invoked from network); 31 Dec 2011 12:07:03 -0000
Received: from smtpbg52.qq.com (HELO smtpbg52.qq.com) (64.71.138.43)
	by server-6.tower-182.messagelabs.com with SMTP;
	31 Dec 2011 12:07:03 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qq.com; s=s0907;
	t=1325333221; bh=onbQH9IEs7wxou1OWflOT1VENM2BewN0d0JEoyQVM1Y=;
	h=X-QQ-SSF:X-HAS-ATTACH:X-QQ-BUSINESS-ORIGIN:X-Originating-IP:
	X-QQ-STYLE:X-QQ-mid:From:To:Subject:Mime-Version:Content-Type:
	Content-Transfer-Encoding:Date:X-Priority:Message-ID:X-QQ-MIME:
	X-Mailer:X-QQ-Mailer;
	b=BU8Xy9uE2hfSW2GdlnqLqUC6lMg3D79yGYbVReJBohqhBiblmb38oQ126rP4HUxFr
	YezlLf7bGEm2WsZfBaNhEcnuVTuTuS2E0Ikn7cYb1id4/f2iSM+irlmHYSCdR/h
X-QQ-SSF: 00000000000000F0000000000000000
X-HAS-ATTACH: no
X-QQ-BUSINESS-ORIGIN: 2
X-Originating-IP: 69.163.32.120
X-QQ-STYLE: 
X-QQ-mid: webmail501t1325333219t3683677
From: "=?gbk?B?oei9S+y2YXdhcmU=?=" <250716708@qq.com>
To: "=?gbk?B?eGVuLWRldmVs?=" <xen-devel@lists.xensource.com>
Mime-Version: 1.0
Date: Sat, 31 Dec 2011 20:06:59 +0800
X-Priority: 3
Message-ID: <tencent_139A0A6F06168A7D7DAAA6A0@qq.com>
X-QQ-MIME: TCMime 1.0 by Tencent
X-Mailer: QQMail 2.x
X-QQ-Mailer: QQMail 2.x
Subject: [Xen-devel] [help] problem with debuging
	/tools/ioemu-qemu-xen/xen-vl-extra.c
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1330395285898889554=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a multi-part message in MIME format.

--===============1330395285898889554==
Content-Type: multipart/alternative;
	boundary="----=_NextPart_4EFEFAE3_083EE2E8_5CE1DAE3"
Content-Transfer-Encoding: 8Bit

This is a multi-part message in MIME format.

------=_NextPart_4EFEFAE3_083EE2E8_5CE1DAE3
Content-Type: text/plain;
	charset="gbk"
Content-Transfer-Encoding: base64

SGkgZXZlcnlvbmUsDQogICAgIEkgYWRkZWQgZGVidWcgaW5mbyBpbiB0aGUgZnVuY3Rpb24g
ZG9fc2F2ZXZtIG9mIC90b29scy9pb2VtdS1xZW11LXhlbi94ZW4tdmwtZXh0cmEuYyBhcyBm
b2xsb3c6DQogIA0KICANCiBEQkcoImdvaW5nIHRvIHNhdmUuLi4iKTsgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgDQpyZXQgPSBxZW11X3NhdmV2bV9zdGF0ZShmKTsgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgDQogREJHKCJzYXZlIGZpbmlzaC4uLiIpOyAg
DQogIA0KIG9ubHkgdG8gc2VlICJnb2luZyB0byBzYXZlLi4uIiBhbmQgInNhdmUgZmluaXNo
Li4uIiBpbiB0aGUgbG9nIGZpbGUsYnV0IEkgY291bGRuJ3QgZ2V0IHRoZSBkZWJ1ZyBvdXRw
dXQgaW4gcWVtdV9zYXZldm1fc3RhdGUoZikgY2FsbGVkIGJ5ICJkb19zYXZldm0iLiBXaHkg
bm90Pw0KICANCiBiZXN0IHJlZ2FyZHMNCiBicnVjZQ==

------=_NextPart_4EFEFAE3_083EE2E8_5CE1DAE3
Content-Type: text/html;
	charset="gbk"
Content-Transfer-Encoding: base64

PERJVj5IaSBldmVyeW9uZSw8L0RJVj4NCjxESVY+Jm5ic3A7Jm5ic3A7Jm5ic3A7IEkgYWRk
ZWQgZGVidWcgaW5mbyBpbiB0aGUgZnVuY3Rpb24gZG9fc2F2ZXZtJm5ic3A7b2YgL3Rvb2xz
L2lvZW11LXFlbXUteGVuL3hlbi12bC1leHRyYS5jIGFzIGZvbGxvdzo8L0RJVj4NCjxESVY+
Jm5ic3A7PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj5EQkcoImdvaW5nIHRvIHNh
dmUuLi4iKTsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8QlI+
cmV0ID0gcWVtdV9zYXZldm1fc3RhdGUoZik7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PEJS
PiBEQkcoInNhdmUgZmluaXNoLi4uIik7Jm5ic3A7IDwvRElWPg0KPERJVj4mbmJzcDs8L0RJ
Vj4NCjxESVY+b25seSB0byBzZWUgImdvaW5nIHRvIHNhdmUuLi4iIGFuZCAic2F2ZSBmaW5p
c2guLi4iIGluIHRoZSBsb2cgZmlsZSxidXQgSSBjb3VsZG4ndCBnZXQgdGhlIGRlYnVnIG91
dHB1dCBpbiBxZW11X3NhdmV2bV9zdGF0ZShmKSBjYWxsZWQgYnkgImRvX3NhdmV2bSIuIFdo
eSBub3Q/PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj5iZXN0IHJlZ2FyZHM8L0RJ
Vj4NCjxESVY+YnJ1Y2U8L0RJVj4=

------=_NextPart_4EFEFAE3_083EE2E8_5CE1DAE3--



--===============1330395285898889554==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============1330395285898889554==--



From xen-devel-bounces@lists.xensource.com Sat Dec 31 15:02:30 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 31 Dec 2011 15:02:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rh0RL-0003KJ-D0; Sat, 31 Dec 2011 15:01:43 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <florian.heigl@gmail.com>) id 1Rh0RK-0003KE-4F
	for xen-devel@lists.xensource.com; Sat, 31 Dec 2011 15:01:42 +0000
X-Env-Sender: florian.heigl@gmail.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1325343694!8717713!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15440 invoked from network); 31 Dec 2011 15:01:36 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	31 Dec 2011 15:01:36 -0000
Received: by iagw33 with SMTP id w33so125335678iag.30
	for <xen-devel@lists.xensource.com>;
	Sat, 31 Dec 2011 07:01:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=8/SQGSCas8q/4KLoKyY0jiQuUuyS9fI/W5W8JZ1otSA=;
	b=l7Rp08EOQbxUf0uPmQLCCqlcmjj62Ok0Sjy4YhZUd2NUpPkchHXvIy9lQTww0Ma20Z
	6kO+AnceCesZXvHy+Oqt6mW2Fn99+SLLxlyfCKwEielTLyUC2/u73uVI3T9U5vmgL9G1
	06jeJnWWOS5vz3kPqTbMNo+mBAcIm/XMODVl4=
MIME-Version: 1.0
Received: by 10.50.100.164 with SMTP id ez4mr31209885igb.12.1325343694499;
	Sat, 31 Dec 2011 07:01:34 -0800 (PST)
Received: by 10.231.229.7 with HTTP; Sat, 31 Dec 2011 07:01:34 -0800 (PST)
In-Reply-To: <1325157276-4847-1-git-send-email-wei.liu2@citrix.com>
References: <1325157276-4847-1-git-send-email-wei.liu2@citrix.com>
Date: Sat, 31 Dec 2011 16:01:34 +0100
Message-ID: <CAFivhPmSQLEFaG5XBZg6TWrPDd5U82keMfgbEo8OR8ErG516vw@mail.gmail.com>
From: Florian Heigl <florian.heigl@gmail.com>
To: Wei Liu <wei.liu2@citrix.com>
Cc: andy@strugglers.net, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] libxl: simple fix to enable user to configure vif
	names
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi Wei,

2011/12/29 Wei Liu <wei.liu2@citrix.com>:
> This feature is required by some of our users.
>
> Reported-by: Andy Smith <andy@strugglers.net>
> Reported-by: Florian Heigl <florian.heigl@gmail.com>

Wow, thank you! :))


-- 
the purpose of libvirt is to provide an abstraction layer hiding all
xen features added since 2006 until they were finally understood and
copied by the kvm devs.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Dec 31 15:02:30 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 31 Dec 2011 15:02:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rh0RL-0003KJ-D0; Sat, 31 Dec 2011 15:01:43 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <florian.heigl@gmail.com>) id 1Rh0RK-0003KE-4F
	for xen-devel@lists.xensource.com; Sat, 31 Dec 2011 15:01:42 +0000
X-Env-Sender: florian.heigl@gmail.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1325343694!8717713!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15440 invoked from network); 31 Dec 2011 15:01:36 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	31 Dec 2011 15:01:36 -0000
Received: by iagw33 with SMTP id w33so125335678iag.30
	for <xen-devel@lists.xensource.com>;
	Sat, 31 Dec 2011 07:01:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=8/SQGSCas8q/4KLoKyY0jiQuUuyS9fI/W5W8JZ1otSA=;
	b=l7Rp08EOQbxUf0uPmQLCCqlcmjj62Ok0Sjy4YhZUd2NUpPkchHXvIy9lQTww0Ma20Z
	6kO+AnceCesZXvHy+Oqt6mW2Fn99+SLLxlyfCKwEielTLyUC2/u73uVI3T9U5vmgL9G1
	06jeJnWWOS5vz3kPqTbMNo+mBAcIm/XMODVl4=
MIME-Version: 1.0
Received: by 10.50.100.164 with SMTP id ez4mr31209885igb.12.1325343694499;
	Sat, 31 Dec 2011 07:01:34 -0800 (PST)
Received: by 10.231.229.7 with HTTP; Sat, 31 Dec 2011 07:01:34 -0800 (PST)
In-Reply-To: <1325157276-4847-1-git-send-email-wei.liu2@citrix.com>
References: <1325157276-4847-1-git-send-email-wei.liu2@citrix.com>
Date: Sat, 31 Dec 2011 16:01:34 +0100
Message-ID: <CAFivhPmSQLEFaG5XBZg6TWrPDd5U82keMfgbEo8OR8ErG516vw@mail.gmail.com>
From: Florian Heigl <florian.heigl@gmail.com>
To: Wei Liu <wei.liu2@citrix.com>
Cc: andy@strugglers.net, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] libxl: simple fix to enable user to configure vif
	names
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi Wei,

2011/12/29 Wei Liu <wei.liu2@citrix.com>:
> This feature is required by some of our users.
>
> Reported-by: Andy Smith <andy@strugglers.net>
> Reported-by: Florian Heigl <florian.heigl@gmail.com>

Wow, thank you! :))


-- 
the purpose of libvirt is to provide an abstraction layer hiding all
xen features added since 2006 until they were finally understood and
copied by the kvm devs.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Dec 31 21:53:19 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 31 Dec 2011 21:53:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rh6qn-00054d-HZ; Sat, 31 Dec 2011 21:52:25 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ming.Aaron.Liu@gmail.com>) id 1Rh6ql-00054Y-LG
	for xen-devel@lists.xensource.com; Sat, 31 Dec 2011 21:52:23 +0000
X-Env-Sender: Ming.Aaron.Liu@gmail.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1325368336!9262748!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13421 invoked from network); 31 Dec 2011 21:52:17 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-3.tower-216.messagelabs.com with AES256-SHA encrypted SMTP;
	31 Dec 2011 21:52:17 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <Ming.Aaron.Liu@gmail.com>) id 1Rh6qe-00074l-0s
	for xen-devel@lists.xensource.com; Sat, 31 Dec 2011 13:52:16 -0800
Date: Sat, 31 Dec 2011 13:52:16 -0800 (PST)
From: lmingcsce <Ming.Aaron.Liu@gmail.com>
To: xen-devel@lists.xensource.com
Message-ID: <1325368336020-5112670.post@n5.nabble.com>
MIME-Version: 1.0
Subject: [Xen-devel] Translate virtual address to physical address
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi everyone, I'm working on a research project now and encounter a problem
like this:
I establish a new array in the tools directory and pass the address of this
array to the hypervisor. I want to know how can I translate the virtual
address of the array to the machine address. In this way, the hypervisor can
modify the values in this array. 
Thanks for your help. 


--
View this message in context: http://xen.1045712.n5.nabble.com/Translate-virtual-address-to-physical-address-tp5112670p5112670.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Dec 31 21:53:19 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 31 Dec 2011 21:53:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rh6qn-00054d-HZ; Sat, 31 Dec 2011 21:52:25 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ming.Aaron.Liu@gmail.com>) id 1Rh6ql-00054Y-LG
	for xen-devel@lists.xensource.com; Sat, 31 Dec 2011 21:52:23 +0000
X-Env-Sender: Ming.Aaron.Liu@gmail.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1325368336!9262748!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13421 invoked from network); 31 Dec 2011 21:52:17 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-3.tower-216.messagelabs.com with AES256-SHA encrypted SMTP;
	31 Dec 2011 21:52:17 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <Ming.Aaron.Liu@gmail.com>) id 1Rh6qe-00074l-0s
	for xen-devel@lists.xensource.com; Sat, 31 Dec 2011 13:52:16 -0800
Date: Sat, 31 Dec 2011 13:52:16 -0800 (PST)
From: lmingcsce <Ming.Aaron.Liu@gmail.com>
To: xen-devel@lists.xensource.com
Message-ID: <1325368336020-5112670.post@n5.nabble.com>
MIME-Version: 1.0
Subject: [Xen-devel] Translate virtual address to physical address
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi everyone, I'm working on a research project now and encounter a problem
like this:
I establish a new array in the tools directory and pass the address of this
array to the hypervisor. I want to know how can I translate the virtual
address of the array to the machine address. In this way, the hypervisor can
modify the values in this array. 
Thanks for your help. 


--
View this message in context: http://xen.1045712.n5.nabble.com/Translate-virtual-address-to-physical-address-tp5112670p5112670.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Dec 31 23:31:33 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 31 Dec 2011 23: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.xensource.com>)
	id 1Rh8O1-0005Xa-4P; Sat, 31 Dec 2011 23:30:49 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <Stefan.Kuhne@gmx.net>) id 1Rh8Nz-0005XS-7j
	for xen-devel@lists.xensource.com; Sat, 31 Dec 2011 23:30:47 +0000
X-Env-Sender: Stefan.Kuhne@gmx.net
X-Msg-Ref: server-13.tower-21.messagelabs.com!1325374240!6714776!1
X-Originating-IP: [213.165.64.22]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMTMuMTY1LjY0LjIyID0+IDEzNTAzMw==\n,sa_preprocessor: 
	QmFkIElQOiAyMTMuMTY1LjY0LjIyID0+IDEzNTAzMw==\n, ML_RADAR_SPEW_LINKS_14, 
	spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4115 invoked from network); 31 Dec 2011 23:30:41 -0000
Received: from mailout-de.gmx.net (HELO mailout-de.gmx.net) (213.165.64.22)
	by server-13.tower-21.messagelabs.com with SMTP;
	31 Dec 2011 23:30:41 -0000
Received: (qmail invoked by alias); 31 Dec 2011 23:30:38 -0000
Received: from xdsl-87-79-144-126.netcologne.de (EHLO Earth.access.denied)
	[87.79.144.126]
	by mail.gmx.net (mp014) with SMTP; 01 Jan 2012 00:30:38 +0100
X-Authenticated: #6997022
X-Provags-ID: V01U2FsdGVkX19M+cs0FdxM9Yb5ewYOfPAQWz6vJYd4gp9UfqRvoS
	ebYzp52vgcR5/K
Received: from blackbox.access.denied ([192.168.200.212])
	by Earth.access.denied with esmtpa (Exim 4.77)
	(envelope-from <bloebl@access.denied>) id 1Rh8RA-0001Kb-FL
	for xen-devel@lists.xensource.com; Sun, 01 Jan 2012 00:34:04 +0100
Message-ID: <4EFF9AF5.1070404@access.denied>
Date: Sun, 01 Jan 2012 00:29:57 +0100
From: "Stefan Kuhne" <stefan.kuhne@gmx.net>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0.1
MIME-Version: 1.0
To: xen-devel@lists.xensource.com
X-Enigmail-Version: 1.3.4
X-Y-GMX-Trusted: 0
Subject: [Xen-devel] linux-3.1.5 and xen-4.0.3
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6013066490945735586=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--===============6013066490945735586==
Content-Type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature";
 boundary="------------enigA8C3FC26DA11A4B9BFC9891D"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigA8C3FC26DA11A4B9BFC9891D
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: quoted-printable

Hello,

I try to run xen-4.0.3 (and 4.0.2) with linux-3.1.5.
I've all beckends and frontends build in kernel, but the system can't
bring up vif and vbd devices.

Error message:

Internal error: Device 769 (vbd) could not be connected. Hotplug scripts
not working..

Where can i look for a failure?

Regards,
Stefan Kuhne


--------------enigA8C3FC26DA11A4B9BFC9891D
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJO/5r6AAoJEFLNPgL3IBVXk/EIALbwdqI4Z+/6/vQOa6pMaEnW
+kwK3nyy/iPmmS39R8RwOzB/KsTukmTke2ZLw26DNJh5bQ0c0csZG+9i1gBzhLcO
dB4lz7qmyVDvOLbNkyvcU+P3O/2hyPbX9yQAZiHrNn/Ts2He7AewyDnC38Vnd8gm
kBrl3Yuvm60QV1vNQklmnme4Qu5CAA6Whkkrq30B6nfPDnmYvD8NrGflfa3B6M2r
NTnKG5tVLdEYg+Tkh5DkGw9wxyQUWjTgSMTXn1oTtkKi9rvuLSfXFCxhJGbHyV1e
r7GCQjHtq7FDRMlfjZy7e3tANuRMTksgC8R+3CuGB8QvTgHseesPQFi5gPKwlNA=
=DmDB
-----END PGP SIGNATURE-----

--------------enigA8C3FC26DA11A4B9BFC9891D--


--===============6013066490945735586==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============6013066490945735586==--


From xen-devel-bounces@lists.xensource.com Sat Dec 31 23:31:33 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 31 Dec 2011 23: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.xensource.com>)
	id 1Rh8O1-0005Xa-4P; Sat, 31 Dec 2011 23:30:49 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <Stefan.Kuhne@gmx.net>) id 1Rh8Nz-0005XS-7j
	for xen-devel@lists.xensource.com; Sat, 31 Dec 2011 23:30:47 +0000
X-Env-Sender: Stefan.Kuhne@gmx.net
X-Msg-Ref: server-13.tower-21.messagelabs.com!1325374240!6714776!1
X-Originating-IP: [213.165.64.22]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMTMuMTY1LjY0LjIyID0+IDEzNTAzMw==\n,sa_preprocessor: 
	QmFkIElQOiAyMTMuMTY1LjY0LjIyID0+IDEzNTAzMw==\n, ML_RADAR_SPEW_LINKS_14, 
	spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4115 invoked from network); 31 Dec 2011 23:30:41 -0000
Received: from mailout-de.gmx.net (HELO mailout-de.gmx.net) (213.165.64.22)
	by server-13.tower-21.messagelabs.com with SMTP;
	31 Dec 2011 23:30:41 -0000
Received: (qmail invoked by alias); 31 Dec 2011 23:30:38 -0000
Received: from xdsl-87-79-144-126.netcologne.de (EHLO Earth.access.denied)
	[87.79.144.126]
	by mail.gmx.net (mp014) with SMTP; 01 Jan 2012 00:30:38 +0100
X-Authenticated: #6997022
X-Provags-ID: V01U2FsdGVkX19M+cs0FdxM9Yb5ewYOfPAQWz6vJYd4gp9UfqRvoS
	ebYzp52vgcR5/K
Received: from blackbox.access.denied ([192.168.200.212])
	by Earth.access.denied with esmtpa (Exim 4.77)
	(envelope-from <bloebl@access.denied>) id 1Rh8RA-0001Kb-FL
	for xen-devel@lists.xensource.com; Sun, 01 Jan 2012 00:34:04 +0100
Message-ID: <4EFF9AF5.1070404@access.denied>
Date: Sun, 01 Jan 2012 00:29:57 +0100
From: "Stefan Kuhne" <stefan.kuhne@gmx.net>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0.1
MIME-Version: 1.0
To: xen-devel@lists.xensource.com
X-Enigmail-Version: 1.3.4
X-Y-GMX-Trusted: 0
Subject: [Xen-devel] linux-3.1.5 and xen-4.0.3
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6013066490945735586=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--===============6013066490945735586==
Content-Type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature";
 boundary="------------enigA8C3FC26DA11A4B9BFC9891D"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigA8C3FC26DA11A4B9BFC9891D
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: quoted-printable

Hello,

I try to run xen-4.0.3 (and 4.0.2) with linux-3.1.5.
I've all beckends and frontends build in kernel, but the system can't
bring up vif and vbd devices.

Error message:

Internal error: Device 769 (vbd) could not be connected. Hotplug scripts
not working..

Where can i look for a failure?

Regards,
Stefan Kuhne


--------------enigA8C3FC26DA11A4B9BFC9891D
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJO/5r6AAoJEFLNPgL3IBVXk/EIALbwdqI4Z+/6/vQOa6pMaEnW
+kwK3nyy/iPmmS39R8RwOzB/KsTukmTke2ZLw26DNJh5bQ0c0csZG+9i1gBzhLcO
dB4lz7qmyVDvOLbNkyvcU+P3O/2hyPbX9yQAZiHrNn/Ts2He7AewyDnC38Vnd8gm
kBrl3Yuvm60QV1vNQklmnme4Qu5CAA6Whkkrq30B6nfPDnmYvD8NrGflfa3B6M2r
NTnKG5tVLdEYg+Tkh5DkGw9wxyQUWjTgSMTXn1oTtkKi9rvuLSfXFCxhJGbHyV1e
r7GCQjHtq7FDRMlfjZy7e3tANuRMTksgC8R+3CuGB8QvTgHseesPQFi5gPKwlNA=
=DmDB
-----END PGP SIGNATURE-----

--------------enigA8C3FC26DA11A4B9BFC9891D--


--===============6013066490945735586==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============6013066490945735586==--